WO2001099003A1

WO2001099003A1 - System and method for sourcing, purchasing and analysis across multiple commercial marketplace

Info

Publication number: WO2001099003A1
Application number: PCT/US2001/019287
Authority: WO
Original assignee: Commercescout, Inc.
Priority date: 2000-06-16
Filing date: 2001-06-15
Publication date: 2001-12-27
Also published as: AU2001266957A1

Abstract

A transaction management and decision support system is adapted for communication between vendors and purchasers over a wide area network. A method for identifying desired goods and services offered across a plurality of disjoint brick and mortar marketplaces, digital marketplaces, including electronic marketplaces, includes aggregating the disjoint marketplaces into a substantially aggregate marketplace database. A first set of parametric criteria, including product identification criteria, for example, is developed. The first set of criteria defines a particular product or service targeted for purchase. The aggregate marketplace is searched for a product or service meeting the first set of parametric criteria. Purchase metrics corresponding to found products or services meeting the first set of parametric criteria is displayed to a user. A second set of parametric criteria is developed, which defines a threshold value for at least one purchase metric corresponding to found products or services meeting the first set of parametric criteria. The aggregate marketplace database is automatically searched, on a periodic basis, for the product or service meeting the first set of parametric criteria and the second set of parametric criteria.

Description

SYSTEM AND METHOD FOR SOURCING, PURCHASING AND ANALYSIS ACROSS MULTIPLE COMMERCIAL MARKETPLACE

CROSS-REFERENCE TO RELATED APPLICATIONS The present application is related to and takes priority from previously filed provisional application Serial No. 60/212,330, entitled System and Method for Multiple Commercial Marketplace Management and Transactional Analysis, filed June 16, 2000, the entire contents of which are expressly incorporated herein by reference.

FIELD OF THE INVENTION The present invention relates generally to electronic marketplace management systems and, more particularly, to systems and methods for electronic marketplace aggregation, and direct materials sourcing, purchasing, transactional detailing, analysis and reporting of transactional metrics.

BACKGROUND OF THE INVENTION Electronic commerce is rapidly transforming business activities as enterprises of all sizes join the burgeoning Internet economy. Various companies use the Internet to establish new markets, increase supply-chain efficiency, and create additional value chains and address the challenges associated with increased competition within a global marketplace.

However, the business transaction capabilities of the global Internet, as presently implemented, are particularly deficient in regards to their inability to efficiently collate and automate the various purchasing decisions that must be made by any particular business enterprise, especially in the direct materials realm. For example, the global Internet has established a proliferation of suppliers of various goods and services, each of which implements product offering and selection through one or more of a number of different electronic marketplace sources. Buyers are forced to travel across a bewildering number of product offering sites that are established in accordance with inconsistent principles and which support interaction in accordance with a number of generally inconsistent protocols.

The current state of the business-to-business global Internet is illustrated in a simplified semi-schematic form in FIG. 1. Goods and/or services are offered by vendors through catalog portals, exchanges portals or auction portals, each of which require a different transaction protocol to be used in order to effect a purchase. A catalog portal, for example, is merely an electronic catalog which is accessed by different buyers and which might include a simplified search engine such that a buyer can go directly to a desired product in order to determine its current price and availability characteristics. While this is a reasonably simple approach, it should be understood that various products offered by various manufacturers have slightly different product codes, which are often inconsistent from manufacturer to manufacturer, making it difficult to perform a canonical search over multiple electronic catalogs. Further, in order to perform a complete search, a buyer must at least be aware of, or have access to, a great number of electronic catalogs, in order to assure themselves of obtaining the best possible price for any particular desired item. Additionally, to purchase direct materials, a buyer needs to use purchase orders, be able to search on a list of substitutable parts, and be able to schedule deliveries into the future.

Exchange portals allow both buyers and sellers to interact with the exchange's product listing, but also suffer from the inconsistent product descriptor problems exhibited by electronic catalogs. Similarly, both buyers and sellers should have access to a large number of electronic exchanges, in order to maximize their potential sales or to maximize the possibility of obtaining a desired product at a desired price or at a desired quantity level. For buyers, particularly, there are now an additional number of sites that they must access in order to assure themselves of an appropriately economic transaction. The inclusion of auctions into the mix further complicates the transaction process, by further populating the site list and by defining a further transaction protocol that both buyers and sellers must be aware of in order to avail themselves of an auction. Although they might offer the opportunity of acquiring a particular product at a desired price or quantity level, auctions require a great deal more of a buyer or seller's time and attention during the purchasing process and are particularly disadvantageous in this regard when it is recognized that both buyers and sellers have better things to do with their time than sit before a display screen bidding on products.

In order to make the global electronic marketplace truly efficient, business-to- business procurement solutions must somehow manage or consolidate the proliferation of suppliers, even across the various electronic marketplaces. The ability to consolidate and include more suppliers in the sourcing process thereby increases competitive pricing opportunities.

On the buyer-side, a business-to-business procurement solution should be able to automate the procurement process so as to allow a buyer to search, quote and/or procure a particular product or service from the global electronic marketplace, without regard to the specific form of the electronic marketplace in which the purchasing transaction is effected. This type of procurement solution should be able to automate the planning and procurement processes typically found in Advanced Planning and Scheduling (APS), Materials Resource Planning (MRP) and Enterprise Resource Planning (ERP) systems and link those process results to the electronic marketplace. By providing this form of connectivity between enterprise design, MRP, ERP, and APS systems, a desirable business-to-business procurement solution will allow a buyer or resource planner to make more informed sourcing decisions, enable rapid adjustments to sourcing plans and execute replenishment efficiently.

Conventionally, product and source selection is an intensive manual process, with purchasers determining a requirement set of part numbers and substitutes, and then submitting a request for quote (RFQ) to a limited set of suppliers. Suppliers review the contents of the RFQ, filter out parts they don't supply, determine a price and submit their responses, with purchasers selecting or otherwise identifying potential suppliers with which to participate. The manual nature of the RFQ typically drives companies to limit participation to known suppliers, denying other suppliers potential business opportunities and limiting the buyer's ability to ensure the best possible price, delivery dates and quantity. An effective business-to-business procurement solution will integrate information from various digital marketplace databases, (conventionally hosted in electronic catalogs, electronic exchanges or on auctions), into an aggregate electronic database, directly accessible to a registered user or users. Real-time integration of such databases will enable a purchaser to research current alternative products or alternative suppliers. Centralization of the purchasing process will enable spot, as well as production buying and selling of inventory or capacity, allowing various enterprises to continually optimize their asset utilization. Buyers and sellers will be able to quickly select a particular product or supplier, based on a limited set of requirements, criteria or parametrics, and immediately quote and execute the purchasing transaction. A business-to-business procurement solution should define a transaction management and decision support system that provides interoperability with all forms of electronic marketplace site-based portals, linking those portals together into an aggregate electronic marketplace so as to create a single virtual community. Buyers and sellers would be able to invoke such a transaction management and decision support system in order to take advantage of services provided through all of the portals comprising the aggregate electronic marketplace, without having to recreate their infrastructures.

SUMMARY OF THE INVENTION In a transaction management and decision support system of the type adapted for communication between vendors and purchasers over a wide area network, a method for identifying desired goods and services offered across a plurality of disjoint brick and mortar marketplaces, digital marketplaces, including electronic marketplaces, electronic catalog sites, electronic product exchanges and auction sites, includes the step of aggregating the disjoint marketplaces into a substantially aggregate marketplace database. A first set of parametric criteria, including product identification criteria, for example, is developed, the first set of criteria defining a particular product or service targeted for purchase. The aggregate marketplace is searched for a product or service meeting the first set of parametric criteria. Purchase metrics corresponding to found products or services meeting the first set of parametric criteria is displayed to a user. A second set of parametric criteria is developed, the second set of criteria defining a threshold value for at least one purchase metric corresponding to found products or services meeting the first set of parametric criteria. The aggregate marketplace database is automatically searched, on a periodic basis, for the product or service meeting the first set of parametric criteria and the second set of parametric criteria. In a further aspect of the invention, a set of pre-established user notification rules is developed, along with a set of pre-established additional action rules. A user is notified, in accordance with the pre-established notification rules, when a product or service having purchase metrics satisfying both the first and second sets of parametric criteria has been found. Further, an additional action may be initiated in accordance with the pre-established additional action rules, when a product or service having purchase metrics satisfying both the first and second sets of parametric criteria has been found, and a particular site within the aggregate marketplace, at which the product or service was found, is accessed, in order to effect electronic purchase of said product or service.

In particular, the first set of parametric criteria are selected from the group consisting of a product identifier, an industry indicia, a product category indicia, a product sub-category indicia, a keyword indicia, and a manufacturers part number, while the purchase metrics corresponding to found products or services are selected from the group consisting of product price, on-hand quantity, vendor, manufacturer, marketplace, and delivery date. A current result may be stored, for each periodic search of the aggregate marketplace database, for the product or service meeting the first set of parametric criteria and the second set of parametric criteria, and a purchase metric comparison between the initial search result and the current search result may be displayed.

In a further aspect of the invention, the method includes the steps of statistically analyzing the purchase metrics contained within the stored results, developing trend data for purchase metrics, and displaying the trend data to a user.

In a transaction management and sourcing decision support system of the type adapted for communication between vendors and purchasers over a wide area network, over which goods and services are offered across a plurality of disjoint electronic marketplaces, including electronic catalog sites, electronic product exchanges and auction sites, a method for effecting purchases comprises identifying a desired good or service in accordance with a pre-defined categorical taxonomy, defining a first set of purchase metrics for said desired good or service, initiating a purchase metric query for the desired good or service to an electronic aggregate of the disjoint electronic marketplaces, receiving at least a result of the purchase metric query, establishing a set of threshold criteria for at least one of the purchase metrics, and initiating a repetitive query, on a periodic basis, for the desired good or service, until such time as the query is satisfied with a desired good or service having the at least one purchase metric meet the set of threshold criteria.

In an additional aspect of the invention, the method includes storing the identified desired good or service in a database accessible to the user, and displaying a purchase metric comparison between an initial query result and a current query result to the user. A user is notified, in accordance with the pre-established notification rules, when a product or service having at least one purchase metric meet the set of threshold criteria has been found.

In particular, the first set of purchase metrics are selected from the group consisting of a product identifier, an industry indicia, a product category indicia, a product sub-category indicia, a keyword indicia, and a manufacturers part number. The at least one purchase metric corresponding to found products or services is selected from the group consisting of product price, on-hand quantity, vendor, manufacturer, marketplace, and delivery date. In a transaction management and sourcing decision support system, in which purchase metrics of desired goods or services are extracted from an aggregate electronic marketplace on the basis of a categorical taxonomic search for said good or service, a method for dynamically persistently querying the aggregate marketplace comprises the establishment of a set of threshold criteria for at least one of the purchase metrics, and initiating a repetitive query, on a periodic basis, for the desired good or service, until such time as the query is satisfied by identifying a desired good or service having at least one purchase metric meet the set of threshold criteria.

BRIEF DESCRIPTION OF THE DRAWINGS These and other features, aspects and advantages of the present invention will be more fully understood when considered with respect to the following specification, appended claims and accompanying drawings, wherein:

FIG. 1 is a simplified, semi-schematic diagram illustrating the present state of electronic commerce implementations; FIG. 2 is a simplified, semi-schematic diagram of an expert transactional management system for effecting purchases across aggregate electronic marketplaces in accordance with principles of the present invention;

FIG. 3(a) is a simplified, semi-schematic diagram of the layer implementation of the expert transactional management system of FIG. 2; FIG. 3(b) is a simplified, semi-schematic diagram of the presentation layer implementation of the expert transactional management system of FIG. 2;

FIG. 3(c) is a simplified, semi-schematic diagram of exemplary components of the presentation layer of the expert transactional management system of FIG. 2;

FIG. 4(a) is a simplified, semi-schematic diagram of exemplary components of the application layer of the expert transactional management system of FIG. 2;

FIG. 4(b) is a simplified, semi-schematic diagram of exemplary components of the aggregation engine of the expert transactional management system's application layer;

FIG. 5 is an illustration of an exemplary search screen which supports the search functionality of the inventive system; FIG. 6 is a simplified flow diagram of the operational steps performed in implementing a search;

FIG. 7 is an illustration of an exemplary search result screen, showing the data organization of search results; FIG. 8 is an illustration of an exemplary quote screen, in accordance with principles of the invention;

FIG. 9 is an illustration of an exemplary presentation screen, showing the data input organization of a track; FIG. 10 is an exemplary of database field values for implementing a track in accordance with the invention;

FIG. 11 is a simplified flow diagram of the operational steps performed in implementing a track;

FIG. 12 is an illustration of an exemplary presentation screen, showing the data output organization of a track management function;

FIG. 13 is an illustration of an exemplary presentation screen, showing the data output organization of a track watch function.

DETAILED DESCRIPTION OF THE INVENTION Conceptually, the present invention may be thought of as a system and method for procurement and transactional decision support and execution involving, not only a conduit to an aggregate of multiple, generally inconsistent marketplace implementations, but also the preparation and delivering of transactions on behalf of the buyer or seller. Information and analytics are dynamically passed across user and eMarketplace boundaries and used to analyze user sourcing requirements and effect transactions based on particular user criteria, such as price, availability and quantity, for example.

Functionally, the system according to the invention suitably includes various task- based components which serve to search, track, watch, negotiate and analyze trading data and further to effect transaction by procurement. In particular, a task-based search engine, also termed an active content engine (ACE), 'logs into' the specific digital marketplaces as the user and performs multi-parametric, multi-criteria searches, accessing real-time product information from aggregated supplier catalog, emarket, auction and electronic exchange listings (digital marketplaces). A task-based tracking component suitably performs scheduled multi-parametric, multi-criteria searches that execute periodically throughout a user defined time horizon. The tracking component looks for selected products based on specification, price, quantity and availability criteria selected by a user. Once found, the tracking component either affirmatively alerts the user, or invokes an automatic purchase using authorization information contained in a user profile database file. A watching task-based functional component is implemented as a monitoring system which displays dynamic product pricing, availability and buy/sell activity across selected user-registered emarket and auction sites periodically throughout a user-defined time horizon. Negotiation involves a task-based component which might dynamically participate in product pricing and buy/sell activities across selected user registered auction sites. A task-based procurement component uses the output from the search, track or watch functional components, such that selected products that match the initially input search criteria can be either saved as quotes, for future action, or purchased on-line at the option of a user. Analysis involves a task-based component which uses aggregated content and the inventive system's transaction log data to provide users with access to industry trend information and user transaction data, whether the user is a buyer or seller.

As depicted in a simplified, semi-schematic conceptual layout diagram of FIG. 2, the system might be characterized as an expert data retrieval and transactional management engine 10 that defines an interface system between buyers 12, sellers 14, and an aggregate eMarketplace set 16, for the purpose of effecting sourcing research and procurement transactions between and among various component parts and eMarketplaces. In accordance with practice of the invention, the database within the invention representing the aggregate eMarketplace set 16, suitably includes a multiplicity of disjoint market choices. Principle among these, but by no means exhaustive of the range of choices, are electronic auctions, or portals thereto, electronic exchanges and electronic catalogs which might be hosted either directly by a vendor or by third party distributors, and the like. Because the aggregated eMarketplace database is represented, in its component parts, by particular web sites implemented on the World Wide Web, it should be understood that the expert sourcing and transactional system of the invention is a web based system, with all of the attendant interface functionality commonly associated with such systems. As illustrated in FIG. 3(a), the transactional management system may be viewed as a functional system interposed between a user (a user's web access device) 18 and the electronic space known as the World Wide Web, of the Global Internet 20. Conceptually, the system may be thought of as comprising a presentation layer 22 which controls a graphical interface between a user and the remainder of the system. An application layer 24 controls the novel functionality of the transaction management engine; receiving user commands and input from the presentation layer and providing result information to the presentation layer 22 for delivery to the user in a suitable form. An aggregate marketplace database 26 and a system metrics database 28 (or data warehouse) are also provided in the sourcing / transaction management system and function to hold and manipulate the various forms of source provided, and user provided, information, respectively, that prompts and informs the various transaction management functions of the invention, as will be described in greater detail subsequently.

As shown in the semi-schematic illustration of FIG. 3(b), the presentation layer 22 offers various types and degrees of functionality to a user system 18 through a graphical user interface (i.e., a web browser application) which collects information from the user and presents information to the user through a series of screens 30. Screens 30 might be implemented as proprietary GUI screens in the case of a dedicated client-side application, but most advantageously are implemented as a set of web pages hosted by a central server system to which a user may gain access.

In particular, and as depicted in the semi-schematic illustration of FIG. 3(c), the presentation layer interacts with a user system 18 through a presentation controller application 32. Various user-upload applications are coupled through the presentation controller which is, in turn, coupled to a database manager application 34 which controls access to a system database 36. The database manager application 34 further interfaces with the rules and criteria function engine, as will be described in greater detail below, as well as to the active content engine (ACE). In a manner common to many commercial applications, certain user sensitive information needs to be collected in order that a user might become registered to use the system and that certain analytical parameter information might be collected in order to further simplify the purchasing process and enhance the efficiency of the system. Users must have an ability to gain access to the system by interactively using system resources to register and must further be able to identify themselves to the system (i.e., login), once registered. Appropriate web pages (screens) are provided for such purpose by the system, along with appropriate application routines driven by data entered in those pages. Thus, a user wishing to avail themselves of the functionality of the transactional management system according to the invention, is able to access the system's web site, access a registration page and enter registration information into the appropriate fields.

In order to make the most efficient use of the system, an amount of personalization/profile information is input by the user, on an appropriate page, and is maintained in the system database as a profile script file for use in uploading data during sourcing requests and when making purchase transactions, as will be described in greater detail below. Once registered, a user may subsequently login, and use the various functional elements of the application layer of the invention in order to initiate uploads, request sourcing information and make informed purchasing decisions, and indeed to effect electronic transactions in an efficient and automated manner. Prior to proceeding with a detailed description of various functional elements of the application layer of the invention, it will be useful to provide some contextual information regarding marketplace aggregation techniques and methods. While the state of this particular art is relatively new, and applications and methodologies are constantly evolving, various aggregation techniques are known in the art and might be exemplified by the iMerge product information system, offered by Mergent Systems, Inc. of Mountain View, California. Use of such systems allow buyers and sellers the ability to accurately assess, aggregate and maintain product data across disparate product categories within multiple, disjoint marketplaces. Conceptually, an aggregation system extracts content automatically from source systems and provides such extracted content to host subscriber database managers, for example, at appropriate intervals. Depending on the construction of the aggregation system, content files might be updated on a regular basis, or only changed content might be selected and transmitted for maximum efficiency.

In the system of the present invention, the aggregation engine is unique in its ability to address a multitude of cataloging issues relating to aggregation and searching. As indicated in the simplified block level diagram of FIG. 4(b), an exemplary content and data management system 40 is suitably configured as a product suite, and includes various functional subsystems which allow various product metrics to be tabularized in a form suitable for incorporation into a database system.

In particular, an Active Content Engine (ACE) 40 would necessarily include a data aggregator 42, and might be characterized as defining the ability to log into a digital marketplace web site, access the web site's data for a specific user, search across various disjoint marketplaces relating to particular product categories, and gather and cache content in accordance with a predefined hierarchical algorithm. The Active Content Engine 40 is thus responsible for retrieving, unifying, cleansing and normalizing content from various eMarketplaces, such as catalogs, exchanges and auctions, so as to make it available in a more efficient and monolithic form for either further processing or use by an eventual end user. Suitably, the Active Content Engine comprises a number of functional components. The Active Content Engine 40 also includes a data categorizer 44 which performs the normalization operations to allocate aggregated content into rational, logical sets, with each set pertaining to a particular industry or product type. Data might be allocated to particular industry group, such as chemicals, electronics, hardware and building products, specialty steels and the like, with product category types represented by diodes, transistors, operational amplifiers, and the like, all residing in sub-categories beneath the general industrial category "electronics", for example.

A data controller 46 is able to adapt data from heterogeneous sources to any format recognized by a receiver. In particular, content can either be pulled by the system according to the invention, utilizing the Active Content Engine 40, or content can be pushed by content providers, depending on the particular business environment. The Active Content Engine 40 supports a data architecture that is flexible enough to extract data from virtually any content provider system, be it files, databases, catalogs, web publishing sources, and the like and delivered in reliable standard formats with no loss of integrity. Content acquisition may also be made periodically in FTP batch transfers, through uploads through the system's web site, by email, or transferred under control of a dynamic "Bot" process, depending on the particular operational parameters of the specific content source.

A data cleaner 48 functions in conjunction with a data normalizer 50 to perform the data cleansing operations and logically repair certain data items such as catalog part numbers and quantity pricing so as to make the resultant data sets internally self consistent and intelligible to a user. Since many disparate content providers choose to identify certain catalog items with identifying tags, prefixes and/or suffixes specific to the provider, the data normalizer 50 serves to present all content relating to specific product or part number in a standardized (normalized) form such that database queries may be made against uniquely identified items.

All the different functional elements of the Active Content Engine 40 will necessarily function in accordance with a set of procedures and algorithms defined by the system's data rules engine 52, provided as a utility application or program. As various pieces of data are received from particular content providers, the data rules engine 52 sets up the standards and conventions against which data is characterized, cleaned and normalized.

Once acquired and processed, aggregate content information is stored in the system's database 54 in accordance with a hierarchical data scheme, driven by the industry specific product identification and/or the taxonomy of each individual product. A database management application 56 controls data flow into and out of the database 54, as well as data formatting, tracking and interfacing with other application routines comprising the system of the invention. It should therefore be mentioned, at this juncture, that the Active Content Engine

40 forms a portion of an application suite, also termed an application layer, which also includes the various functional subsystems that relate to practice of principles of the invention. As illustrated in the simplified, block level diagram of FIG. 4(a), a set of additional function elements provides the novel system with the capability to search a database constructed from content aggregated over multiple disparate marketplaces for specific items in accordance with a set of user defined sourcing and purchasing requirement parametrics, preferably expressed in terms of user defined rules and criteria.

As will be described in greater detail below, a search engine, implemented as a search application routine 58 allows a user to search for products using an industry specific product identification and/or taxonomy that dynamically makes different product identification and/or specification criteria available to the user, depending on specific user selections. The search engine 58 also allows user to receive details for product results obtained during a canonical search through products obtained from the various marketplaces and further allows the user to compare the results using a cross tab table. The level of detail is determined by the amount of detail maintained by the marketplace on specific products and the number of criteria available in the industry specific product identification methodology and/or taxonomy. The content is aggregated by the Active Content Engine 40, filtered and sorted by the search engine based on user rules and criteria selections, and displayed to the user over a graphical user interface, such as a web browser screen.

Product specifications may also be accessed through the search engine 58. Product specifications might be embedded in data provided by a digital marketplace, a vendor site or a third party specification provider, such as QuestLink.com. Necessarily, product specification locations would be marketplace dependent; and for those marketplaces that do not maintain specifications, the user might well be linked directly to a product vendor or a content provider site, at an appropriate URL, to search for specific product specifications in background.

Product information is pulled from or pushed by marketplaces according to regular schedules maintained by the marketplace data managers. Certain marketplaces, i.e., various electronic catalogs, typically update their content on a daily basis, and make that content available to search engines through routine nightly FTP batch transfer processes. Content files are downloaded by the aggregation engine, processed and maintained in a database for access by users of the system according to the invention. A search engine 58 -performs a comprehensive search of supplier catalog, digital marketplace, auction and exchange listings maintained in the inventive system's database, in accordance with a set of user defined rules and criteria. The search engine searches for and finds product matches within the database based on rules, criteria and logic entered by a user, in order to locate a particular product by part number, a range of products or a particular product grouping. Alternatively, products may be found on the basis of a set of purchasing parameters or product criteria established as search engine filter elements.

Tracking functionality is provided by a software application, identified as a track engine 60-, which also forms part of the application suite in accordance with the invention. Conceptually, tracking functionality allows a user to rigorously organize the searching function, by specifying certain product search tracking rules and criteria which interacts with the search engine 58 to enable the system to persistently search for a particular product item, or a set of items defined by a set of search criteria within a time horizon specified by the user, and allows the user to select an action or multiple actions which should occur when the track locates a rules/criteria/product match. Users can be notified when the track criteria have been met in accordance with communication preferences that have been predefined by the user for such purpose, and actions such as automatically adding the product to a quote (shopping cart) or automatically purchasing the matching item can also be selected by the user . With regard to the notification function, the track engine 60 is also logically coupled to a communication or notification engine 62 which, in turn, interfaces with various forms of communication instruments so as to provide alerts, notifications, and other information to the user.

Depending on the communication preferences defined by the user, the communication engine 62 is able to communicate various types and forms of information scripts over a number of IP-based, general broadband, and wireless communication systems. Information scripts might be directed to a user by e-mail, by wireless cellular communication, or by directing an information script to a user having a palm-type hand held computer system with wireless capability. It will be understood, by those having skill in the art, that the communication engine 62 is not limited to any particular communication technique. Indeed, most communication techniques prevalent today are capable of being coupled to virtually any interface bus implemented by modern computer-based technology. Accordingly, the communication engine 62 need only be capable of providing notification alerts to a user in accordance with any communication preferences defined by the user.

Watching functionality is incorporated in a software application identified as a watch engine 64 which allows a user to view, in real time, the most current results for ongoing tracking activity, as compared to the criteria specified for the track. In watch mode, the watch engine is able to display the specified item along with the item's currently. found price, quantity, date code, and the like, as well as the desired price, quantity, date code, and the like specified in the track criteria.

In summary, the search, track and watch engines define a core set of functionality that, in accordance with the invention, enables a user to adaptably source product and/or inform a transaction decision based upon dynamically changing market conditions. Transactions are effected by a purchasing engine, implemented as a purchase application routine 66, in turn linked to the other functional blocks of the system of the invention. If any of the other functional blocks identify a suitable product candidate for purchase, the purchasing engine can be invoked, in either foreground or background, to access the specific source site containing the target product to consummate the transaction.

Each of the foregoing applications operates upon aggregated marketplace data contained in the system's database initially, with various ones of the applications, particularly the purchase engine 66 able to go off-site to selected source sites, in order to effect particular purchase transactions. Searching, tracking and watching are done on aggregated marketplace content, with search, track and watch results provided in as timely a fashion as data is updated within the various source marketplace sites. Although not all of the individual applications are capable of maintaining real-time connections to electronic auction sites, certain functional elements of the transaction management system are contemplated as being particularly suitable for operation within an auction environment, in particular, the watch application 64.

In operation, the method according to the invention might be thought of as being initiated when a user initially subscribes to the sourcing and transaction management system. Initiation of the process takes place when the user is issued a user identification index and a password, which will allow the user to access the specialized functionality of the transaction management system. Once a user has subscribed, the user (whether individual buyer or seller, or institutional purchaser or vendor) is requested to complete a user profile script (also termed personalization information) which consists of a set of demographic fields and personal choice preferences, the portions of which will be used by the transaction management system as user reconfigureble default values in furtherance of efficient transaction management.

For example, an institutional purchaser might be requested to enter such information as the institution's name, business address, contact information such as telephone numbers, fax numbers, cell numbers and/or other contact preferences and also indicate the ranking order in which communication methodologies should be used, i.e., e- mail first, then cell, and the like. Further institution specific information requested by the profile form might include a category code, relating to the type of business in which the organization is engaged. Notionally, a computer motherboard assembly house would not necessarily be interested in receiving information pertaining to specialty steel vendors. Accordingly, such an institution would identify themselves in the computer hardware and/or marketplace. A particular choice of institutional type might be made from a dropdown menu which includes listings corresponding to the industrial and categorical allocations of the transaction management system's search algorithms, such that particular personal, commercial or industrial users can more readily select a set of appropriate codes and industry categories so as to make their transactions more efficient. Necessarily, users will be able to select multiple categories and subcategories from the list in order to more completely define the scope of their market participation and interest.

In addition to commercial demographic information, user profiles include an identification of the individual or individuals who have been granted authority to effect transactions using the transaction management system. Limiting this authority to commit assists particularly an institutional purchaser in maintaining the security of their purchasing system. As will be described in greater detail below, initially designating authorized purchasers does not necessarily limit the number of transactors; those users so authorized have the ability to access the transaction management system and designate additional "transaction associates" who will be enabled to have access to certain functionality of the system, but are otherwise limited in the commitment actions which they might take on behalf of the institution. Purchasing payment methodologies are also captured by request fields in a user profile. Purchasing methodologies might involve a user's identifying a ranking order of approved vendors, on the one hand, or a ranking order of vendors or marketplaces with which the purchaser will not do business. A user might even select, in ranking order, the types of marketplaces with which the user desires to interface; a user might designate direct dealer catalogs, third party catalog vendors, and electronic exchanges as desirable marketplaces in which to participate, but designate auctions as being totally undesirable. Under payment methodologies, a user might select their most common payment practices, again from a drop down list, and enter certain requisite information relating to credit card numbers, line-of-credit accounts, purchase orders, and the like. It should be evident that the types and forms of information described above in connection with a user profile is necessarily not exhaustive. Any type of information that will allow the transaction management system to better identify a particular user on a demographic or other basis will consequently allow the transaction management system to provide particular configurations of decision support mechanisms so as to ease the transaction process for that specific user.

It should also be mentioned that personalization information can also be used to develop and customize a user specific "home page", which resides on the host system of the invention and which is initially accessed by a user whenever they login to the system. Since the exemplary system of the invention is described in terms of a web-based application, it would be advantageous to allow users to arrange the configuration and presentation of their initial screen into whatever form and format they are comfortable with. A customized home page provides the initial point of entry for a user into the remaining functionality of the system.

Once a user has registered and completed a profile script, the sourcing and transaction management system may be used in order to develop particularized searches for specific product items, track a particular product or products by performing repetitive searches on the basis of specified user criteria, and manage both the searching and tracking functions by evaluating current results for searches and tracks against their initially input criteria. Using any of these particular functions, the user is also able to be notified after the results of a successful search, or track or the user can instruct the transaction system to execute an action, such as automatically adding a particular product to a quote, or automatically generating a purchase transaction with the source marketplace in accordance with their communication preferences, defined in the initially prepared user profile. With regard to searching, the user accesses the search functionality of the system through a series of browser screens or pages provided by the system's presentation layer. On a browser, or other GUI application, search elements, rules and criteria, are accessible through conventional tool bars or drop down menus, each of which provide the user with various configurable options for performing a search. An exemplary search screen (or page), illustrated in FIG. 5, gives the user an option to search for various products using an industry specific product identification methodology and/or taxonomy. For instance, if the user is looking for a product according to a particular industry product identification methodology, which requires a single part number (such as electronic components), the user can simply input the part number or a portion of the part number, depending on whether the user wants only a single part number or a family of part numbers to be included in the search. If the user is looking for a product according to a particular industry, category and sub-category, the search page might well display the most important specification criteria, as defined within the taxometric parameters, for that specific sub-category. The user may then select particular populated available specifications from each criteria drop down field. In addition to specification criteria, purchase criteria are also included, where the user may enter the criteria to be met form them to make a purchase, such as vendor, marketplace source, price, availability and quantity available. In contrast to specification criteria, purchase criteria fields are not contemplated to be dynamic and will therefore be the same for every search within a particular industry. For registered users, information such as vendor preferences will be defaulted with from the user's profile, as described above.

Once the user has selected the product by inputting their own item identifier with associated industry product identifiers, the industry product identifier, or industry, category, and subcategory they wish to search, they may save the search, including key words, industry, category and all associated specifications and criteria. To save the search, the user need only identify the saved search or 'item' with a name or some other identifying indicia, and direct the search to be stored to the system's database by taking appropriate action. Users may upload a list of their own items, with associated manufacturer part number / manufacturer mapping (termed AVL, Approved Vendor/Manufacturer List) and other information such as target price, and they will be stored as 'saved items' within the inventive system's database for use in future searches and tracks. To access the saved search or item during a later session, the user might access a "saved search or item" drop down box or screen, containing a list of all searches saved by that particular user. Upon selection of a particular saved search, the search screen or page appears with all of the requisite fields filled with information previously entered by that user. In order to delete or update a saved search or item, the user might select a saved search or item from the "saved search" drop down box or screen, at which time update and delete become active.

As a user prepares a search, the event flow is substantially similar to actions taken in preparation of a request for quote (RFQ). When a user prepares an RFQ or quote they would nominally make certain mental decisions and choices with regard to how a particular transaction should proceed. Similarly when a user prepares a "quote" with the assistance of the transactional management system according to the invention, the same sorts of conceptual steps and events take place, although in a more particular and structure format in order to ease the transaction. Following the example of FIG. 5, and with regard to the exemplary flow diagram of FIG. 6, the following is a generalized description of the actions a user might take in order to develop a search. Since the search functionality is provided by the aggregation and search engine, the field table is necessarily driven by the categorization topology defined by the searching algorithm. In the exemplary embodiment of FIG. 5, suitable fields that a user might fill out are identified by their caption and are further identified in terms of their entry type and general default condition. Accordingly, key word search is performed by a user entering any keyword or product identifier that they may wish to search on into a text box, for example. Key word search is well known in the art and requires no further explanation here. It should be mentioned, however, that the particular key word or key words used should contain sufficient information such that the search engine is able to make an adequate determination as to the kinds of marketplaces to address in order to find information relating to subject matter pertaining to the key word.

In a different form of search, a hierarchical industry-based search, a user selects an industry that they wish to search within by activating a drop down menu and selecting from any one of the various industries contained within the menu. Pertinent such listings might include computers, electronics, chemicals, specialty steels, and the like, with each item on the list identifying a particular industrial category of goods and/or services which the aggregation/search engine is configured to interface with. Once a particular industry is selected, a further drop down menu allows a user to select a product identifier or product category, from within that industry, in order to further narrow the search parameters. Sub-industry options contained within this particular menu are necessarily based on the particular industry selected in the "select industry" step. Particular sub-industry options might include hardware, software or components as categories if the user had selected computers as the main industry grouping. Similarly, boards, chips and processors might represent categories offered by the drop down menu within the electronics industry. The process continues with sub- category selection, again on the basis of options presented in a drop down menu, based upon the user's category selection. Exemplary sub-categories that might be offered for selection would be DRAM, SRAM, FIFO, EPROM, and ROM if the user had selected the category "chips" within the industry "electronics". Similar sub-categorical definitions can easily be contemplated by one having skill in the art given an identification of an industry and a definition of a particular category within the industry in the manner based on the examples given above. Recall, however, that the aggregation/search engine will necessarily drive the specific taxonomy.

Following categorical selection, the user may enter a manufacturing part number into the system in a free form field provided for such purpose. Because the field is free form, the default condition will be blank. The user is also able to identify the marketplace sources for the product or products they wish to purchase. Marketplace source designation is again taken from a drop down menu, from which the user may specify any combination of catalogs, auctions or exchanges, for example with the default condition being set to all of the foregoing marketplace sources.

Price, quantity and availability all have their separate free form fields for data entry by the user. A purchaser enters a particular unit price, chosen on the basis of whatever decision criteria is driving the purchase and indicates the quantity (the number) of each product desired at that price. The purchaser is also able to mandate an availability date, defining a particular time frame by which a vendor must be able to deliver the particular unit quantity at the particular unit price defined in the cost/quantity fields. Availability can be interface with a calendar function so as to make it easier for a user to identify a specific calendar date by which delivery must be completed, or the availability field may be free form requiring either a date input (12/01/02 or September 2, 2001) or a period input (three weeks, for example). A field which further refines the pricing portion is a unit cost delimiter field through which a user may specify certain unit cost delimiters such as "less than", "equal to", "greater than", "around (+/- 10%)", or all of the above from a drop down menu. Thus, a purchaser is able to specify a quote for 3000 pieces of widgets, part number Wl 11 , at a desired unit price of "less than" $1.15 per widget. The purchaser may further indicate that they are unconcerned as to the source of the widgets, thereby informing the aggregation/search engine that Wil l widgets may be searched for across the entire spectrum of marketplace sources.

The foregoing represents sufficient information to allow the Active Content Engine to access one or multiple digital marketplaces in order to retrieve appropriate product information and further to initiate the search engine to proceed to the aggregated marketplace database and search for "Wl 11 widgets" to determine if any vendor or combination of vendors are able to deliver 3000 of said article at a price of less than $1.15, within the next three weeks, for example. However, although sufficient to effect a search, the foregoing information might indeed be expanded upon to further inform the process in accordance with a purchaser's or purchasing organization's commercial preferences.

Additional search parameters, rules and criteria might typically include a search result sorting order, by which target offerings matching the other search parameters would be sorted, during presentation to the purchaser, in an order ranking determined by the purchaser. Such order ranking might include a ranking by price, availability, quality, quantity, percent sign specification match or by vendor or source rating. Selections can be made by indicating a particular ranking order, from ,for example, from a drop down menu. In conformance with generally accepted practice, search results are typically displayed in a ranking order according to price as a default value. Vendor source rating is a further optional field which takes a default value from any vendor or source rating information provided by the user in the user's initially defined profile information. Vendors may be rated by a purchaser according to any particular criteria desired by the purchaser, but might be rated in accordance with the perceived quality of their product offerings, the quality of their customer service, the responsiveness to delivery "pushes" and "pulls", and the like. Vendor or source ranking is done on a sliding numerical basis, with a 1 representing a vendor having the least desirable characteristics and the top of the scale, i.e., a 5 or 10 or whatever, representing a vendor or source having the highest rating. For any particular product defined by a quote a purchaser is able to identify a "not less than" source rating for the vendor pool.

In this particular example, purchasers would be encouraged to heavily populate the desired vendor fields of their personal or institutional profile scripts in order to give substance and meaning to the source rating field of the search parameter page. However, since products by a single vendor are often offered through multiple marketplace sources, it is conceivable that a purchaser wishing to acquire 3000 widgets manufactured by Best Widgets, Inc. would be able to locate a multiplicity of marketplace sources for these items. Best Widgets, Inc. products might be offered directly from a Best Widgets electronic catalog hosted on the Best Widgets' web site, through third party distribution channel electronic catalogs like Avnet or Arrow, or through an on-line intermediary such as Virtual Chip Exchange, Digital Market, or NecX. Thus, even though the purchaser specified a limited number of vendors in their profile script, the search "quote" functionality of the invention would nevertheless be able to return a significant number of results, so long as the other search criteria (price, quantity, availability, etc.) were met by vendors in the aggregate marketplace. Needless to say, the source rating field is optional and indeed defaults to "all" if a purchaser is not concerned as to the ultimate source of the goods they wish to purchase.

Following development of the search parameter list, or the "search", a purchaser has the option to either submit the search to the application level or to save the search for further modification or for later submission. Saved searches (and/or items) are identified by a "search name" and stored a system's relational database where it is mapped to any number of corresponding identifiers or preferences relating to the particular user who saved the "search" or "item". Through the particular set of "search" screens developed by the presentation layer for this activity, the user might also fetch one or more search results that were returned by the system following previous searches, retrieve stored searches or items for submission, delete stored searches or items, or update the various criteria associated with recalled stored searches or items.

On the first conceptual level, a rules and criteria (parameter) list pertaining to a particular product to be searched, is passed to the application layer where a query is initiated against the contents of the aggregate marketplace database for items satisfying the search criteria defined by the user. As results are obtained, items which satisfy the conditions of the search parameters are initially listed on a "search result" screen or page, as depicted in generalized form in FIG. 7. Search results give as much information to the user as to each searched product as is available in the marketplace database and would include all pertinent and necessary data with which a sourcing or purchase decision may be made. Users are given the option to purchase an item directly or to add a particular product result detail to a database file, which is subsequently stored in the system's relational database where collections of such items satisfying a particular search criteria are denoted as a "quote". Quotes allow a user to collect multiple items in one area in order to evaluate total cost of the goods before purchasing. Quotes are available to the user and are displayed through the presentation layer on a screen or set of screens on a web browser, for example. The quotation presentation screen allows a user to view any quotes developed for the current session as well as allows the user to access, load and view saved quotes from previous sessions. Quotes are presented in canonical form and contain information such as that depicted in the simplified exemplary quote (result) screen or page of FIG. 8.

As can be seen from FIG. 8, item summaries are listed along with total cost information. Each of the item entries is individually accessible by a user such that items comprising a quote, or the total quote, may be saved, purchased or deleted. For items on quote, where the user has purchased access rights, the user may elect to purchase a particular item by selecting a "purchase" action, at which time the transaction system will log into the selected digital marketplace or marketplaces, or link to the particular marketplace at which that item was found by other electronic transaction technology, such as email, EDI, and the like,, in order to consummate the transaction. That particular item status on the quote will change from "pending" to "purchased" and a confirmation of the purchase transaction will be communicated to the user when the transaction system receives a confirmation from the source(s). Accordingly, it should be understood that the search function offers a robust methodology by which to prepare a context sensitive keyword parametric list for searching through the aggregate marketplace database for specific product items or groups of products. The search function might also be viewed as a presentation engine which ranks recovered results in accordance with a set of user defined criteria or purchasing parameters and offers a user the ability to select particular items from the list or to select the entire list (quote) for purchase. In a manner to be described in greater detail below, purchasing may be done either in an affirmative manner, i.e., by a user selecting an item or quote and invoking a purchasing routine, or by the system automatically invoking a purchasing routine in the event the search returns a result that satisfies all of the initially input criteria set. Needless to say, the decision, as to whether the system automatically makes the purchase or whether the user must affirmatively invoke the purchasing routine, may be made by either setting a "flag" value in the user's profile file, or by setting a "flag" in an appropriate field of the quote form. In the event that a search of the aggregate marketplace database does not return a suitable result, the system includes the ability to track the aggregate marketplace for a period of time in order to attempt to eventually match a product or products with a parameter or criteria set. Tracking is particularly useful in those situations where a specific part is temporarily unavailable, where a user wishes to wait for a price to drop to a particular level, or wishes to track price or availability over a specified time range.

The tracking functionality of the transaction management system in accordance with the invention will now be described with reference to FIG. 9, 10 and 11, which illustrate an exemplary top level screen page, a field table/parameter list and a simplified operational flow diagram pertaining to the operational implementation of an application termed "track". As illustrated in the top level track screen page of FIG. 9, "track" allows a user to periodically and persistently query the aggregate market place for information pertaining to a specific product or set of products by specifying certain tracking criteria against which marketplace results are to be compared and to further allow the user to be notified in accordance with predetermined communication preferences, or initiate an additional action, such as automatically adding the matching track product to a quote, or automatically purchasing the matching track product, when a particular subset of the criteria have been met, or when results are obtained from the aggregate marketplace that satisfy all of the track criteria.

Conceptually, the tracking function might be considered as a persistent search, with the user or purchaser specifying the time duration of the search and the notification criteria. This particular function can be seen to be very advantageous to a purchaser of commodities whose price, quantity and availability are subject to rapid and dynamic fluctuations. In contrast to a simple "search", the tracking ability of the system of the present invention allows a user to define certain target parametrics for purchasing and command a repetitive, persistent search that continues either until the pre-set time duration has expired or until the particular criteria have been met. A simple search is expected to return results that satisfy all of the search parameters on a one-time basis. Search queries are developed and submitted to the application layer which in turn, searches the aggregate marketplace in accordance with those criteria. Results are obtained, bundled and returned to the user; the search process then ceases.

In performing a track, the user is able to specify maxima or minima with respect to any one of the parametrics associated with a product search and command the system to notify the user at any that a product or products achieve the maxima or minima, without regard to any other parameters.

The top level page illustration of FIG. 9 shows the main descriptive areas of an exemplary track function of the system according to the invention; "items to track", "track criteria" and "notify". "Items to track" gives the user the option of identifying which item or items will be subject to the track function. Options available to the user are generally similar to the system's search options, with the addition of certain user selected rules and criteria, particularly in the area of notification and "next step actions" that might be initiated when the "track" is found. Other options available to a user might be the item or items in the current selection, an item specified in a current search, or an item specified in a stored search. A drop down menu gives the user access to the names or identifiers of all searches stored by that user. Once an item's track is selected, track criteria are identified and a notification tag is set, again from a drop down menu, indicating which of the track criteria are to be target criteria for user notification. A user posts the type of notification means and the desired notification timeframe into field provided for such purpose in the "notify" section of the top level "track" page.

Tracking is performed with regard to a field table or parameter list maintained in the system's relational database, a simplified form of which is illustrated in FIG. 10. The field table is divided in to three rational subgroupings of information; a first grouping pertaining to information relating to the current status for the item for which tracking is to be established. The second grouping relating to the criteria to be used for the instant track, and a third grouping relating to criteria match notification of the user. The first grouping includes the track identification assigned by the system, the part number of the item to be tracked, product manufacturer name, if available, and possibly the marketplace source (i.e., an electronic catalog, an exchange, an auction, or the like). In addition, the field table or parameter list includes the current unit price for the item when the track is established as well as the current quantity available and current available shipping date, if such information is indeed available.

It should further be mentioned that current item status information does not represent a necessary condition for performing the tracking function in accordance with the invention. Rather, current item status information is included in the track field table or parameter list as a benchmark or baseline, such that the initial status of an item may be displayed to a user along with any "hits" developed during a particular track. In this manner, a user can immediately compare a track result to an initial item search result so as to make more informed purchasing decisions. For example, if the initial status of an item indicated that only limited quantities were available at the desired price, but the track result indicated that significant quantities were available at a higher price and that the desired quantity was available from the sum of multiple vendors at a still higher price, the buyer could make an immediate visual comparison of the price, quantity and source equation and conclude how to proceed.

Since the track functionality is implemented in database driven form, it should also be understood that the various features and results of a track can be dynamically viewed or managed by a user. As illustrated in the exemplary presentation screen of FIG. 12, A track status may be developed which allows a user to view which tracks have been found and which tracks are still running. The system is also able to display the time stamps of each track such that a user can determine the time remaining on each track and modify the time stamps if desired. Track maintains a running result of any found items, whether or not the criteria set is satisfied. Thus a user is able to view the most current results of each track, whether matched or unmatched, in order to make a purchasing decision. A user might decide to purchase a particular quantity of an item, notwithstanding the desire to purchase a greater quantity, or might decide to purchase at a higher than desired price just to acquire some inventory. Track management functions also give the user the ability to access any of the track criteria or any of the notification communication settings so as to modify these dynamically. An enhancement to track management functionality of the system is provided by a

"watch" application, by which a user may access dynamic product price, availability and auction activity on multiple products over multiple electronic marketplaces. The watch application delivers product purchasing information directly from a source site, at periodic refresh intervals defined by the source site, for any product specified by a user and for any time period.

The watch functionality of the transaction management system in accordance with the invention will now be described with reference to FIG. 13, which illustrates an exemplary top level presentation screen page of an operation termed "watch". As illustrated at a top level screen page of FIG. 13, "watch" allows a user to view the most current results for any of their currently established tracks, and compares those current results to the previously established set of user parameters or criteria, specified for that track. The search application displays the item or search description with the currently posted price, quantity and availability date as well as the desired price, quantity and delivery date specified in the track criteria. If a user wishes to purchase a particular item from that track, they need only "click" the appropriate screen location or link in order to have the tracking engine display the current results for that track. The user may then add the desired item to a quote for purchasing.

Conceptually, the watch function might be considered as a persistent search, in a manner generally similar to a track, but unlike the tracking function, "watch" is not limited in its results by a user defined criteria set. Specifically, the watch functionality is particularly suitable for use in data tracking, such as identifying price, availability and delivery date trends and is most particularly suitable in situations where various tracks have not developed a satisfactory product result and a user wishes to dynamically participate in tracking activity.

As in the previously described search and track functions, the watch function also gives the user the opportunity to make immediate purchase decisions by merely adding a particular track result to a quote and enabling that quote for purchasing.

In the procurement context, the system according to the invention includes a procurement application, by which once a quote is approved, and a purchase is decided upon, the search, track or watch result makes the particular source site directly available to a user, for user access and conventional purchase. Once it is determined that an item on a quote is ready for purchase, the user can enter specific purchase information , such as shipment method, purchase order number, shipping terms, and the like, and merely select the "purchase" action. In one particular embodiment, the procurement application is provided as an HTTP/Bot-based commerce connector that is implemented as a "plug-in" routine in conventional fashion. Alternatively, the procurement application is provided as a link to the source site, which might be presented as a URL script or a banner portal that a user need only "click" on in order to gain access to the source site and effect the transaction. Other embodiments of procurement plug-ins are also advantageously implemented by the system of the invention and include XML, CGI, OBI document transfers, and the like. These other embodiments are particularly useful when using the system to communicate with particular destination sites or commerce engines to effect contract pricing, purchase order data transfer, and so on. Alternatively, the purchasing application is able to automatically make a purchase transaction if that form of activity is authorized by the user's personalization information or profile file. In this particular aspect, the system is able to open communication with the source site identify itself as a proxy for the user (by logging in to the digital marketplace web site, for example), pass the purchasing information to the source site and make payment by any particular payment methodology defined by the user in the profile script. In effect, the system of the invention functions as a virtual shopping cart which the user might either affirmatively fill or which might fill itself depending on a user's initial instructions. It should be further understood that the system's virtual shopping cart functionality is not necessarily limited to effecting purchase transactions with any one particular source site. Indeed, a user might develop a quote which lists several product items sourced from a variety of sites from each of which a purchase is desired. In this particular instance, the system's virtual shopping cart accesses the various sites, in turn, makes the appropriate purchase transaction and goes on to the next site listed in the quote in order to make the next purchase. Thus, the system need only present a single "shopping cart" to the user, in the context of the system application, with the user filling the shopping cart with a variety of products. The system then takes all of the multiplicity of steps required to access all of the selected sites in order to purchase all of the selected items on behalf of the user. When in automated mode, the system significantly reduces the amount of time that need be spent by a user traveling from site to site in order to make individual purchase transactions from each site. The system can take care of all of these transactions in background, in a fashion totally transparent to the user, who is then free to continue with other tasks.

In like manner, the system includes an application which is configured to give a user immediate access to any information gathered in any scheduled track or watch activities. When the track or watch applications develop a product or products which match any of the user's established criteria, the system automatically notifies the user of a matched result. Notification is performed in accordance with any one of a number of communication methodologies which are identified in the user's personalization information or profile file. When establishing a track or watch activity, the user indicates which of the communication preferences are to be used for notification. It is within the contemplation of the system of the invention that notification be performed via cellular telephone service, notification pagers, hand-held computer devices, personal digital assistants, by e-mail, or any other established point-to-point communication media. Necessarily, the system according to the invention will include the appropriate communication I/O devices which are offered as communication alternatives in the user profile script. Notification might be as simple as the system issuing a textual script message, such as "track 16152 satisfied". Alternatively, when the communication media identified for notification has significant content capturing capability, such as a PDA or computer system, the notification message might include additional detail, such as a price indicator, quantity indicator, or whatever parametric criteria was set up by the user to govern the track results.

Accordingly, in terms of functionality, the system of the invention might be viewed as a combination of linked applications, collected together and interacting with one another so as to be able to search an aggregate electronic marketplace for specified products and/or services in accordance with a particular industry product identification methodology or taxonomy. Search results are presented to a user in a form suitable for inclusion into an electronic quote form or file which may be either passed to a source site for purchasing or saved in a relational database for future use. In the event that a search result is unsatisfactory, in terms of price, quantity, availability, or any other criteria important to a user, the system tracks the aggregate electronic marketplace for such products and/or services in accordance with a particular criteria set defined by the user. Tracking is performed offline, in the sense that a user need not be involved in the tracking activity. Satisfied tracks are presented to the user in substantially the same manner as search results, i.e., presented in a form suitable for inclusion in a quote form or file which can be directed to a source site for purchasing or which can be stored for future action.

In the event that the tracking application does not return satisfactory results to the user, the tracking process may be dynamically watched, with the current price, quantity or availability being displayed to a user on a substantially real-time basis. Thus, even though a particular product and/or service does not necessarily meet the user's established criteria, the user is able to see the degree of difference between the established criteria and the present actual market conditions.

Efficiency is enhanced by the system's ability to notify a user when any "flagged" event occurs, such as a particular track satisfaction, using any one of a number of established communication methodologies. Searching, tracking, watching and communicating in accordance with the invention, provides a degree of time sensitivity and efficiency heretofore unrealized in electronic marketplace purchasing applications or systems. These functions are implemented as linked software routines, accessible on a central server system by any user registered to participate. Registered users are able to designate proxies (termed associates herein) to which they may allocate a full set of decision making powers or a designated subset of decision making powers, through which the proxy might interact with the system to make purchasing decisions. To do so, a user establishes an associates list which provides proxies that are identified on it access to the owner's stored searches and/or quotes. The owner may grant read-only, update or purchase access to quotes and read-only or update access to stored searches, for example. In order to maintain data integrity, a proxy may not delete a quote or stored search owned by the registered user or anyone else. If a particular quote or stored search is designated as updateable (or purchasable in the context of a quote) and a proxy updates a quote or stored search, the data in those files changes for both the proxy and the registered owner. Thus, there will be only one instance of a quote or stored search.

It should further be understood that since purchasing metrics are created and maintained in database files, and since the aggregate electronic marketplace is also maintained in database files, the system is further able to provide a unique source of both supply side and demand side analytical information.

With many companies making purchase transactions across multiple marketplaces, in order to meet their procurement needs, it is very difficult to set up and maintain the various tracking structures required to obtain meaningful purchasing metrics across those multiple marketplaces. In addition, due to the relatively incompatible nature of various electronic marketplaces, purchasing metric information does not efficiently flow into ERP systems for trending analysis or other metric processing. Since the system according to the invention is contemplated as a central point of entry into an aggregate electronic marketplace, the system is ideally suited to collect a company's procurement metrics when that company is purchasing across multiple marketplaces. Certain demand trends, as might be established by a collection of tracks, can be acquired by the system and rigorously statistically processed in order to define numerous bi-side criteria which might be used by buyers and sellers alike. On the supply-side, the system is uniquely positioned to collect various supply-side metrics, by virtue of collecting and maintaining availability and pricing information on virtually thousands of items, on a periodic basis. Specifically, the system is uniquely positioned to capture the additional opportunity demand which is currently unmeasurable by present systems which only log executed transactions. Opportunity demand is defined by the system as unmatched tracks and/or searches and indicates a particular volume of goods and/or services that were not purchased because their supply metrics were not what buyers might be looking for in terms of price and/or availability. Indeed, opportunity demand might represent an unmeasured demand that could be satisfied if the price on a particular product were reduced by some percent, or an unmet demand that could be satisfied if volume production were to be ramped-up to some degree.

Necessarily, all of the analytical metrics (supply, demand and opportunity) need to be mapped to the system taxonomy (industry product identification methodology), in order to be able to make meaningful observations and comparisons between and among products, categories and industries. Information is obtained and mapped each time the aggregate marketplace database is updated. This would imply at least daily data processing in the case of multi- vendor catalogs and exchanges.

Even though the system of the invention has been described in terms of a user interacting with a data entry presentation screen, it should be understood that the system is not limited to individual entry techniques. As the system is software based, and is implemented as a collection of linked applications, additional data I/O and format recognition applets are provided as enhancements to the search, track, watch, application input modules, as one having skill in the art is able to immediately understand. Searching, tracking and watching can be performed, not only on user selected input parameters, but also on enterprise generated inputs. Bill of Materials (BOM) uploads (*.csv, *.txt, *.tdt), ERP feeds (SAP, ORCL, PSFT, and the like) and XML based files (cXML, xCBL, RosettaNet, and the like) can all be used as initial inputs for searching, tracking and watching, in accordance with the invention, in addition to the web-based data entry modes described above. All that is required to implement this additional functionality is to provide an appropriate rule/formatting engine as an input filter. Once the data arrangement of a particular input source is understood, the data can be easily manipulated and rearranged into a structure that conforms to the database file structure used by the application suite of the invention. Further efficiency and ease of use is thereby provided. Accordingly, it will be seen that the system according to the invention provides a unique transactional decision support system which defines a conduit to an aggregate of multiple, generally inconsistent electronic marketplace implementations and also supports preparation and delivering transactions on behalf of the buyer and/or seller. Purchase information and analytics are dynamically passed across marketplace boundaries and used to effect transactions based on particular user criteria, such as price, availability and quantity, for example. Transactions are dynamically maintained in an active condition until such time as either the marketplace responds satisfactorily to the demand, the maintenance period times-out, or some other purchasing decision is affirmatively taken. The system accordingly to the invention is suitably implemented as a multiplicity of task-based software application components which are linked together in order to search, track, watch, negotiate and analyze trading data and further to effect transactions by procurement. Although the various components of the system have been described in connection with a particular data structure and implementation sequence, it will be understood that the specific forms, formats and links are provided for exemplary purposes and for ease of illustration and description. The actual layout and content of any of the field tables and, indeed the sequence of events steps that access any of the database field names, can be modified, reordered, combined or even further granulized by any reasonably skilled software engineer, once the concept of the invention is understood. Accordingly, it should be recognized that one having skill in the art may make various modifications and/or additions to the exemplary embodiments of the foregoing detailed description, without departing from the scope or spirit of the present invention. It is to be understood that the subject matter sought to be afforded protection hereby should be deemed to extend to the subject matter defined in the appended claims, including all equivalents thereof.

Claims

1. In a transaction management and decision support system of the type adapted for communication between vendors and purchasers over a wide area network, a method for identifying desired goods and services offered across a plurality of disjoint marketplaces, including electronic marketplaces, electronic catalog sites, electronic product exchanges and auction sites, the method comprising: aggregating the disjoint marketplaces into a substantially aggregate marketplace database; developing a first set of parametric criteria, the first set of criteria defining a particular product or service targeted for purchase; performing a search of an aggregate marketplace for a product or service meeting the first set of parametric criteria; displaying the search result, the search result including purchase metrics corresponding to found products or services meeting the first set of parametric criteria; developing a second set of parametric criteria, the second set of criteria defining a threshold value for at least one purchase metric corresponding to found products or services meeting the first set of parametric criteria; and automatically searching the aggregate marketplace database, on a periodic basis, for the product or service meeting the first set of parametric criteria and the second set of parametric criteria.

2. The method according to claim 1, further comprising: developing a set of pre-established user notification rules; developing a set of pre-established additional action rules; and notifying a user, in accordance with the pre-established notification rules, when a product or service having purchase metrics satisfying both the first and second sets of parametric criteria has been found.

3. The method according to claim 2, further comprising: initiating an additional action in accordance with the pre- established additional action rules, when a product or service having purchase metrics satisfying both the first and second sets of parametric criteria has been found; and accessing a particular site within the aggregate marketplace, at which the product or service was found , in order to effect electronic purchase of said product or service.

4. The method according to claim 3, wherein the first set of parametric criteria are selected from the group consisting of a product identifier, an industry indicia, a product category indicia, a product sub-category indicia, a keyword indicia, and a manufacturers part number.

5. The method according to claim 4, wherein the purchase metrics corresponding to found products or services are selected from the group consisting of product price, on-hand quantity, vendor, manufacturer, marketplace, and delivery date.

6. The method according to claim 3, further comprising: automatically storing a current result for each periodic search of the aggregate marketplace database, for the product or service meeting the first set of parametric criteria and the second set of parametric criteria; and displaying a purchase metric comparison between the initial search result and the current search result.

7. The method according to claim 6, further comprising: statistically analyzing the purchase metrics contained within the stored results; developing trend data for purchase metrics; and displaying the trend data to a user.

8. The method according to claim 6, further comprising the step of automatically storing at least the first and second parametric criteria for each periodic search of the aggregate marketplace database, for the product or service meeting the first set of parametric criteria and the second set of parametric criteria

9. The method according to claim 1, wherein searching is performed by a search engine acting as an agent of the user, and wherein product information for a product or service satisfying the first set of parametric criteria is retrieved and stored in the aggregate marketplace database.

11. In a transaction management and sourcing decision support system of the type adapted for communication between vendors and purchasers over a wide area network, over which goods and services are offered across a plurality of disjoint electronic marketplaces, including electronic catalog sites, electronic product exchanges and auction sites, the method comprising: identifying a desired good or service in accordance with a predefined categorical taxonomy; defining a first set of purchase metrics for said desired good or service; initiating a purchase metric query for the desired good or service to an electronic aggregate of the disjoint electronic marketplaces; receiving at least a result of the purchase metric query; establishing a set of threshold criteria for at least one of the purchase metrics; and initiating a repetitive query, on a periodic basis, for the desired good or service, until such time as the query is satisfied with a desired good or service having the at least one purchase metric meet the set of threshold criteria.

12. The method according to claim 11, further comprising: storing the identified desired good or service in a database accessible to the user; and displaying a purchase metric comparison between an initial query result and a current query result.

13. The method according to claim 11 , wherein the first set of purchase metrics are selected from the group consisting of a product identifier, an industry indicia, a product category indicia, a product sub-category indicia, a keyword indicia, and a manufacturers part number.

14. The method according to claim 13, further comprising the step of notifying a user, in accordance with the pre-established notification rules, when a product or service having at least one purchase metric meet the set of threshold criteria has been found.

15. The method according to claim 14, wherein the at least one purchase metric corresponding to found products or services is selected from the group consisting of product price, on-hand quantity, vendor, manufacturer, marketplace, and delivery date.

16. In a transaction management and sourcing decision support system, in which purchase metrics of desired goods or services are extracted from an aggregate electronic marketplace on the basis of a categorical taxonomic search for said good or service, a method for dynamically persistently querying the aggregate marketplace comprising: establishing a set of threshold criteria for at least one of the purchase metrics; and initiating a repetitive query, on a periodic basis, for the desired good or service, until such time as the query is satisfied by identifying a desired good or service having at least one purchase metric meet the set of threshold criteria.

17. The method according to claim 16, wherein the purchase metrics are selected from the group consisting of a product identifier, an industry indicia, a product category indicia, a product sub-category indicia, a keyword indicia, and a manufacturers part number.

18. The method according to claim 17, further comprising the step of notifying a user, in accordance with the pre-established notification rules, when a product or service having at least one purchase metric meet the set of threshold criteria has been found.

19. The method according to claim 18, wherein the at least one purchase metric corresponding to found products or services is selected from the group consisting of product price, on-hand quantity, vendor, manufacturer, marketplace, and delivery date.