System and method for configuring sell bids

A system and method for configuring sell bids. The system and method use rules and inference engines in order to configure sell bids in view of Request for Quotes (RFQs). The system and method include a data aggregator that integrates data from two or more enterprise data sources into an aggregated enterprise database and a knowledge base database. A bid configurator constructs one or more sell bid candidates for one or more target RFQs by using at least one inference engine and the extracted facts and rules from the knowledge database.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention generally relates to online selling of products or services over a computer network, and more particularly, to a method for purchasing and selling products or services in a networked environment using a request for quotation process and a rule-based system for configuring sell bids having multiple attributes.

2. Background Description

Commerce over networks, particularly electronic commerce (e-commerce) over the Internet, has increased significantly over the past few years. In e-commerce models, buyers and sellers make trades, e.g., buy and sell services or products, over the World Wide Web portion of the Internet. In one example, one or more web pages, typically referred to as an electronic marketplace (e-marketplace), provide one or more different forms of trading mechanisms including auctions, reverse auctions and exchanges. In an auction, one seller receives bids from one or more buyers for one or more products before making a transaction. In contrast, a reverse auction allows one buyer to receive bids from one or more potential sellers. In an exchange, multiple buyers and multiple sellers submit asks and bids, respectively, to a marketplace. The marketplace then makes matches between the asks and bids of the buyers and sellers, either continuously or periodically.

It is known, of course, that these trading models have many different variations. These auction variations may include English (buyers call ascending prices), Dutch (market manager calls descending prices to obtain buy bids), Japanese (market manager calls ascending prices to obtain buy bids) and sealed bid (buyers place sealed bids) auctions. In still other variations of auctions, there is an open Request for Bids and a sealed Request For Bids. In the open Request for Bids, buyers may call ascending prices and a seller manually selects the winning price. In the sealed Request for Bids, buyers submit sealed bids and a seller manually selects the winning bid.

There are also variations on reverse auctions which include reverse English (sellers call descending prices), reverse Dutch (market manager call ascending prices to obtain sell bids), reverse Japanese (market manager calls descending prices to obtain sell bids) and reverse sealed bid (sellers place sealed bids) auctions. Reverse auctions further include open Request For Quotes and sealed Request For Quotes. In the open Request for Quotes, the sellers call descending prices and a buyer manually selects a winning price, and in the sealed Request for Quotes the sellers submit sealed bids and a buyer manually selects the winning quote. Exchanges also include variations. These variations include continuously clearing exchanges and periodically clearing exchanges.

The Request for Quotation (RFQ) is used often in the e-marketplace. In this type of environment, a request is submitted by a buyer to an e-marketplace to invite potential sellers to bid on specific products or services needed by the buyer. The RFQ process is useful in all markets that depend upon attributes other than price such as delivery time, quantity discounts, warranty, seller qualification and other factors. In these RFQ processes, the buyers are permitted to manually select one or more bids from sellers after examining and comparing submitted sell bids. In this manner, the RFQ process allows the sellers to match exactly the buyers' requirements (including the attributes of price, delivery time, warranty, seller qualification and other factors) thus leading to a strong rate of return and high satisfaction ratings.

Depending on the needs of the organization in which a buyer represents, a buyer can submit multiple requests on one or more products or services to one or more electronic marketplaces. Likewise, a seller can find multiple requests on products and services that the seller can fulfill in one or more e-marketplace existing in the Internet. In this situation, a seller needs strategies and tactics for deciding, for example, (i) what requests available in e-marketplaces the seller wants to submit bids to and (ii) what offers the seller wants to make in bids for each of the selected requests. Decisions for these questions need to maximize the revenue and/or profit of the seller and minimize administration cost for RFQ processes, while considering various constraints such as limited inventory, manufacturing capacity, delivery capability and others. The decision-making problem thus becomes one of optimization with objectives, constraints, and a number of unknown variables. Also, it becomes an information search problem.

Rule-based systems, or more generally knowledge-based expert systems, use human knowledge to solve problems that normally would require human intelligence. These expert systems represent the expertise knowledge as data or rules within the computer. These rules and data can be called upon when needed to solve problems. Conventional computer programs perform tasks using conventional decision-making logic containing little knowledge other than the basic algorithm for solving that specific problem and the necessary boundary conditions. This program knowledge is often embedded as part of the programming code, so that as the knowledge changes the program has to be changed and then rebuilt. Knowledge-based systems collect the small fragments of human know-how into a knowledge base which is used to reason through a problem, using the knowledge that is appropriate.

Rule-based programming is one of the most commonly used techniques for developing expert systems. In this programming paradigm, rules are used to represent heuristics, or “rules of thumb,” which specify a set of actions to be performed for a given situation. A rule is composed of an “if ” portion and a “then ” portion. The “if” portion of a rule is a series of patterns which specify the facts (or data) which cause the rule to be applicable. (The process of matching facts to patterns is called pattern matching.) The expert system tool provides a mechanism, called the inference engine or the shell, which automatically matches facts against patterns and determines which rules are applicable. The “if” portion of a rule can actually be thought of as the “whenever” portion of a rule since pattern matching always occurs whenever changes are made to facts. The “then” portion of a rule is the set of actions to be executed when the rule is applicable. The actions of applicable rules are executed when the inference engine is instructed to begin execution. The inference engine selects a rule and then the actions of the selected rule are executed (which may affect the list of applicable rules by adding or removing facts). The inference engine then selects another rule and executes its actions. This process continues until no applicable rules remain.

Problems with the Prior Art

One problem with the prior art for deciding what offers to make in bids for selected requests for quotation from buyers is that it requires a seller to manually decide and specify the details of offers the seller makes for individual requests. This approach requires the seller to understand and remember a large amount of detailed information such as inventory data, fulfillment system data, buyer data, historical data about RFQ processes, and the current and historical market data that involves in the realization of the seller's objectives such as maximizing revenue/profit while minimizing administration cost, and to apply the information to configuring individual sell bids. This approach is not effective nor realistic due to the amount of involved information and the complexity of the optimization for achieving the objectives. Although it is possible to achieve relatively effective results with this manual ad hoc approach, it does not explain different results that would be caused by taking alternative options.

SUMMARY OF THE INVENTION

An object of the present invention is to provide a system and method for configuring sell bids for Request for Quotes (RFQ) processes over a network.

An object of the present invention is to provide a system and method for configuring sell bids having two or more attributes over the network.

An object of the present invention is to provide a system and method for configuring sell bids having two or more attributes over the network while not requiring the seller to manually understand and remember a large amount of detailed information that involves the realization of the seller's objectives such as maximizing revenue/profit while minimizing administration cost.

An object of the present invention is to provide a system and method for configuring sell bids having two or more attributes over the network while considering constraints such as limited inventory, manufacturing capacity, delivery capability and others.

An object of the present invention is to provide a system and method for creating, adding to, and/or modifying knowledge bases by using aggregated data from various enterprise systems such as inventory systems, fulfillment systems, logistics systems, supply chain systems, procurement systems and others.

An object of the present invention is to provide a system and method for configuring sell bids by using inference engines, suggested attribute values of a request for quotation under consideration and knowledge base systems that provides facts (or data) and rules about the seller's enterprise and markets.

An object of the present invention is to provide a system and method for allowing sellers to revise the content of sell bids automatically configured by the system.

The present invention focuses on RFQ process, i.e., the creation of one or more bids by a seller in response to requests. The present invention further focuses on the problem of decision-making for what offers to make in bids for each of the selected requests for products or services. This invention presents a system and method for automatically configuring a sell bid by using a rule-based system.

In one aspect of the present invention, a computer system is provided for ranking one or more objects having two or more attributes. The system includes a data aggregator that integrates data from two or more enterprise data sources into an aggregated enterprise database, and a knowledge base generator that constructs a knowledge base by extracting facts and/or rules from the aggregated enterprise database and stores the facts and rules in a knowledge base database. A did configurator is also provided which constructs sell bid candidates for target RFQs by using inference engines and the extracted facts and rules from the knowledge base database. In embodiments, the sell bid may be revised using a bid revision module.

The present invention also includes a method for configuring one or more sell bids. The method may be implemented via a machine readable medium containing code. The steps for implementing the method of the present invention include aggregating data from one or more enterprise data sources and storing the aggregated enterprise data in an integrated database system. The method extracts one or more facts useful for bid configuration from the integrated database system and derives one or more rules useful for bid configuration from the integrated database system. One or more knowledge base systems are constructed by storing the facts and rules in a form that is understood by an inference engine. The sell bid candidates are then constructed for one or more target RFQs by running one or more facts and rules from the target RFQs and the knowledge base system to the inference engine.

In embodiments, the method may further review and revise the content of one or more of the sell bid candidates, if necessary. Also, the inference engine may match facts against patterns and determine which rules are applicable. It is also contemplated by the present invention to construct the one or more knowledge base systems from business rules, as well as storing and filtering facts and creating and storing rules.

Referring now to the drawings,FIG. 1shows a block diagram of a system architecture of an electronic marketplace in accordance with the present invention. In particular, the architecture of the e-marketplace includes one or more buyers110accessing Web browser programs112via one or more computers111. The buyers110submit Request for Quotes (RFQ)300via the web browser programs112over a network160to an e-marketplace140preferably implemented by a web server141. The web server141stores the RFQ200as well as other information such as, for example, product catalogs, seller and buyer information and the like in one or more database system150. A market maker130may operate the e-marketplace140via a computer131. Once the RFQ300is submitted, the e-marketplace140will post the RFQ300on the web server141.

Still referring toFIG. 1, one or more sellers120may access the e-marketplace140over the network160via a web browser program122residing on a seller computer121. The web browser programs112and122as well as the web server141preferably use HyperText Transfer Protocol (HTTP). The sellers120may find and access the posted RFQ300via the web browser program122, and thereafter submit one or more sell bids400having attribute values to the e-marketplace140via the network160. The sell bid400and associated attribute values may be stored in the database150as well as transmitted to the buyer's web browser112over the network160. Also, the web pages associated with both of the web browser programs112and122may provide a structured form for entering the appropriate information such as, for example, the RFQ and the submitted bids. The buyer110who made the RFQ300selects winners among the submitted sell bids300.

FIG. 2is a flow chart showing the method of the present invention implemented using the system architecture of FIG.1. It should be understood by those of skill in the art that the e-marketplace as well as the other components ofFIG. 1are adapted to implement the steps of FIG.2. Also,FIG. 2may equally represent a high level block diagram capable of implementing the steps provided therein.

At step205, the buyer110submits one or more RFQs300for one or more products or services having one or more attribute preferences to one or more electronic marketplaces140over a network160. At step210, the market maker130allows the submitted RFQ300to be posted on the e-marketplace140for a period of time specified by the buyer110. While RFQs300are posted in the e-marketplace140, the seller120examines and evaluates the RFQs300and decides whether to submit sell bids to the RFQs300, at step215. For selecting one or more RFQs to submit bids to, a seller120may use a scoring function520for multi-attribute decision analysis515as shown in FIG.5. At step220, the seller120creates offers for each of the selected RFQs300by configuring the details of the offers using inference engines671, the suggested attribute values of the RFQ300under consideration, and knowledge base systems660that provides facts (or data) and rules about the seller's enterprise and market. The system for performing the method of automatically configuring sell bids is described in detail in FIG.6. Once the seller creates one or more bids400for an RFQ300, it sends them to the marketplace140, at step of225.

Next, at step230, when the market maker130of the marketplace140receives the bids400from sellers120, the market maker130records them in the database150and also displays them to buyers110, who submitted the RFQs300for the bids400, so that the buyers may find matches between RFQs300and submitted sell bids400. At step235, the buyers110examine and evaluate the submitted bids400to the RFQs300to decide one or more winning bids. For selecting winning bids among the submitted bids, buyers may use a method similar to one presented inFIG. 5that uses one or more scoring functions520for multi-attribute decision analysis515. Also the buyers110may use other decision making methods for the bid selection. At step240, if necessary, the buyer110may make requests for more information about one or more submitted sell bids400to their sellers120. The market maker130can allow such communications between buyers110and sellers120as a function of the marketplace140so that all the communication may be performed online over the network160and the marketplace140without depending on off-line communication methods such as facsimile, telephone, telegrams and postal mails. At step245, the buyer110selects one or more winning bids among the submitted bids.

Negotiation and settlement is still left to complete the RFQ process. As specified at step250, the buyer and one or more sellers of the winning sell bids may negotiate further on various items that may be specified in the RFQ and then bid or not bid. The communication between buyers and sellers may be performed either on-line in the marketplace140over the network160or off-line by using such methods as facsimile, telephone, telegrams and postal mails. Once the negotiation is completed, the buyer110and the sellers120settle the deal (step255); that is, payment is made by the buyer110and shipment or fulfillment of the purchased products or services is made by the sellers120.

FIG. 3is an example of an RFQ having multiple attributes. An RFQ is submitted by a buyer110to an electronic marketplace140. An RFQ has an identification number305and comprises one or more attributes that may belong to one or more categories. Attributes are either numeric or categorical. Each attribute consists of a pair of name and value range315. The value range of a numeric attribute specifies the lower and upper limits of desirable attribute values. On the other hand, the value range of a categorical attribute specifies the names that are acceptable for the category. In the example ofFIG. 3, there are three attribute categories: product specification310(that includes attributes such as price, material quality and properties, color and size); service specification320(that includes delivery time and cost, and warranty); and supplier qualification340(that includes trading history, experience and reputation. Each category is composed of three attributes.

FIG. 4is an example of bids having multiple attributes. Bids are submitted by the sellers120in response to RFQs300in an electronic marketplace140. A sell bid has an identification number405and comprises one or more attributes (and their values) that are specified in the RFQ300which this particular bid is submitted thereto. As in RFQ300, attributes may be divided into several categories. Also, each attribute includes a name and value pair415. In the example ofFIG. 4, there are three attribute categories, i.e., product specification410, service specification420, and supplier qualification430, each of which is composed of three attributes.

FIG. 5is a block diagram of a RFQ selection process. The RFQ selection process receives two pieces of input data: a set of RFQs300, where individual RFQs have two or more attributes, and a set of attribute weights510, where each weight specifies the importance of the corresponding attribute in the task of RFQ selection. Receiving the input data300and510, the multi-criteria decision analysis module515computes the score of the input RFQs, one for each, by using a scoring function520that takes into account the attribute values of individual RFQs300and the weights of attributes510. An example of a scoring function520for the multi-criteria decision analysis module is a linear combination of the weighted values of the attributes, i.e.,
Si=Σjwjf(aij), for alli,
where Sidenotes the score of object i, wjthe weight of the attribute j, aijthe value of attributed j of object i, and f( ) a transformation of attribute value aij. The value of an attribute for an RFQ is selected from the value range315of the attribute given in the RFQ. The output of the multi-criteria decision analysis module is a set of RFQs with scores525, where each RFQ in the input set300has a score given by the module.

FIG. 6is a block diagram of a bid configuration system in accordance with the present invention.FIG. 6may also represent a flow chart implementing the steps of a bid configuration in accordance with the present invention. A feature of the system is the bid configurator component670that automatically configures one or more sell bids that will achieve the seller's objectives (such as maximizing the revenue and/or profit, and minimizing the administration cost) under various constraints (such as limited inventory capacity, customer service capability, and fulfillment capability) by using a rule-based system. To achieve this goal of the bid configurator670, an effective inference engine671and a knowledge base system660(that contains an effective set of facts and rules), along with the enterprises objectives and constraints may be required by the system and method of the present invention.

Examples of the rules and facts that may be necessary for effectively configuring sell bids400for RFQs will be presented inFIGS. 7 and 8, respectively. In the present invention, the rules and facts will be extracted from various enterprise systems and other data sources, which include inventory systems610, fulfillment systems611, database containing buyer information612, database containing historical information of RFQ processes and sales613, and database containing market information614. In embodiments, other data sources such as product information, supply chain information, customer service information, and information from trading partners (e.g., distributors, and logistics providers) may be included as rules and facts. Before extracting facts and rules for bid configuration, the information from these data sources should be aggregated into a single data model in a data warehouse630(also known as aggregated enterprise database or integrated database system) to clean up noises and contradictory information out of the database, and provide a consistent and integrated view over the aggregated enterprise database630. The data aggregator module620creates and updates the content of the integrated database system630by using the information from the data sources610,611,612,613, and614.

From the information stored in the integrated database630, a knowledge base system660is constructed. The knowledge base generator640has two components: the fact collector641and the rule generator642. The fact collector641identifies and filters data (or facts) that will be useful for bid configuration from the integrated database630, and stores the facts in the knowledge base system660in the form that is understood by the inference engine671used by the bid configurator670. The rule generator642searches for the integrated database630, creates useful rules out of given data, and stores them in the knowledge base system660in the form that is understood by the inference engine671. A rule is composed of an “if” portion and a “then” portion. The “if” portion of a rule is a series of patterns which specify the facts (or data) which cause the rule to be applicable. The process of matching facts to patterns is called pattern matching. The “if” portion of a rule may be thought of as the “whenever” portion of a rule since pattern matching always occurs whenever changes are made to facts. The “then” portion of a rule is the set of actions to be executed when the rule is applicable. To create such rules out of plain data stored in the integrated database630, the process requires certain understanding to the data and how it is used by the system. An example of a method that may be used to automatically generate rules out of data is to use one or more data mining techniques that identifies certain patterns out of given historical data. The patterns identified by data mining algorithms may be turned into rules, if identified useful for bid configuration. In addition to facts and rules extracted from the integrated database630, the knowledge base system660may contain other business rules650such as selling policies and trading partner agreement of the seller's organization that are not found in the integrated database630.

Once the knowledge base system660that provides facts and rules stored in the form understood by the inference engine671is given, the bid configurator670is ready to automatically construct one or more sell bids400for RFQs300. When the bid configurator300receives one or more RFQs (and their accompanying attributes and their value ranges) as input, it constructs one or more offerings by identifying particular values for individual attributes given by the RFQs, aiming to realize the objectives of the seller's enterprise such as maximizing the revenue and/or profit, and minimizing the administration cost under certain constraints such as limited inventory capacity, customer service capability, and fulfillment capability. Once the bid configurator670provides one or more candidates680for sell bids for target RFQs, the system allows the seller to review and manually revise the bid candidates680to fine-tune and finalize the sell bids400.

FIG. 7shows examples of rules for bid configuration. As described above, the rules used for bid configuration are derived from the integrated database system630that provides a consistent view over various sources of enterprise data610,611,612,613, and614. In the example ofFIG. 7, rules are categorized by the types of attribute values they are used to be created for, i.e., there are rules used for creating the values of attribute belonging to the product specification710, service specification720, buyer qualification730, and selling policies740.

More specifically, the rules for product specification include rules that consider gross margin or the current inventory level to decide products to offer in sell bids711,712,713, and714. Also, there is a rule that adjusts the price of products or services by a discount rate considering the buyer's reputation715. An example of rules for service specification is a rule which adjusts the warranty period of products considering the buyer's reputation721. An example of rules for buyer qualification is a rule used to select an RFQ to submit bids to by considering the change of the buyer's stock price in the market731. Examples of the selling policies are limiting the minimum and/or maximum number of buyers741, or no buyer receiving more than 40% of the seller's business to avoid dependency on business742. Of course other rules may also be used with the present invention.

FIG. 8shows examples of facts for bid configuration. As described above, the facts used for bid configuration are derived from the integrated database system630that provides a consistent view over various sources of enterprise data610,611,612,613, and614, and stored in the knowledge base system660in the form that is understood by the inference engine671. In the example ofFIG. 8, a number of facts that are related to the rules inFIG. 7include, for example,facts about gross margin and the current inventory level of particular products805,810,815, and820facts about reputation rate, stock value, supplier relationship length in year, the amount of the business deals in a particular year of a particular buyer825,830,835,840, and850facts about stock market index value845, and facts about bid submission due and value range of a product attribute of a particular RFQ855and860.