Method and apparatus for forming expressive combinatorial auctions and exchanges

CROSS REFERENCE TO RELATED APPLICATION

The present invention claims priority from United States Provisional Patent Application Serial No. 60/371,451, filed April 10, 2002, entitled "Side Constraints And Non-Price Attributes In Combinatorial Markets".

BACKGROUND OF THE INVENTION

1.

Field of the Invention

The present invention relates to combinatorial exchanges, and more specifically, to associating one or more processing features with one or more bids or one or more bid groups, wherein each processing feature modifies the processing of the one or more bids or the one or more bid groups.

2.

Description of the Prior Art

Various systems have been proposed and constructed to support online exchanges, forward auctions and reverse auctions. The most general of these market types is an exchange, which permits one or more bidders to offer to sell and/or purchase one or more items. An item may be any entity of value, such as a good or service. A forward auction is a special case of an exchange with a single seller. A reverse auction is a special case of an exchange with single buyer.

Combinatorial exchanges support advanced exchange designs and expressive bidding. These features permit an exchange to be designed to achieve best economic efficiency.

One example of expressive bidding is combinatorial bids. Combinatorial bids allow bidders to bid on multiple items with a single bid. The combination, or bundle of items, is determined by the bidder. This is advantageous when the items exhibit complementarity, i.e., when the value of the bundle of items is worth more to the bidder than the sum of the separate item values, or substitutability, i.e., where different items are interchangeable to the bidder. Combinatorial bids allow bidders to express their true preference, resulting in the best economic allocation.

A drawback of combinatorial exchanges is that determination of winning bids that optimizes the objective is computationally intractable (NP complete). For example, the exchange objective could be to maximize the number of items traded, or to maximize surplus, that is, the difference between ask bid revenue and pay bid cost

It is, therefore, an object of the present invention to provide an input specification mechanism that supports efficient processing in a way to maximize seller revenue while minimizing buyer cost. Still other objects of the invention will become apparent to those of ordinary skill in the art upon reading and understanding the following detailed description.

SUMMARY OF THE INVENTION

The invention is a method of processing an exchange. The method includes providing a solver/analyzer responsive to at least one bid for determining at least one of an infeasible allocation, a winning allocation and a feasible allocation, with each allocation including at least one allocation value. At least one bid is received at the solver/analyzer, with each bid including at least one item and an associated price. Exchange description data (EDD) is associated with the at least one bid. The EDD includes at least one of the features of reserve price, free disposal, bid attribute, item attribute, adjustment, objective, counting constraint, counting requirement, homogeneity constraint, mixture constraint, feasibility obtainer, constraint relaxer, conditional pricing and quote request. The associated EDD is received at the solver/analyzer and the at least one bid is processed by the solver/analyzer in accordance with at least one feature included in the associated EDD.

The invention is also a computer readable medium having stored thereon instructions, which, when executed by a processor, cause the processor to receive a plurality of bids, with each bid including at least one item and an associated price, and associate exchange description data (EDD) with at least one of the bids. The EDD includes at least one of the features of reserve price, free disposal, bid attribute, item attribute, adjustment, objective, counting constraint, counting requirement, homogeneity constraint, mixture constraint, feasibility obtainer, constraint relaxer, conditional pricing and quote request. The at least one bid is processed in accordance with the at least one feature included in the associated EDD to obtain an allocation for the exchange.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a diagrammatic illustration of an exemplary computer system that can execute computer readable program code that embodies the present invention;

Fig. 2 is a generalized block diagram of a communication medium connecting entities participating in an exchange;

Fig. 3 is a detailed block diagram of the generalized block diagram shown in Fig. 2;

Fig. 4 is a diagrammatic illustration of an exemplary bid having exchange description data associated therewith;

Fig 5 is a list of exchange description data (EDD) features of the present invention;

Fig. 6 is a diagrammatic illustration of a bid including an associated EDD having the features of free disposal, reserve price, action, item attribute and item adjustment associated therewith;

Fig. 7 is a diagrammatic illustration of a bid including an associated EDD having the features of bid attributes and bid adjustments;

Fig. 8a is a diagrammatic illustration of a cost constraint feature of an EDD;

Fig. 8b is a diagrammatic illustration of a cost requirement feature of an EDD;

Fig. 9a is a diagrammatic illustration of a unit constraint feature of an EDD;

Fig. 9b is a diagrammatic illustration of a unit requirement feature of an EDD;

Fig. 10a is a diagrammatic illustration of a counting constraint feature of an EDD;

Fig. 10a is a diagrammatic illustration of a counting requirement feature of an EDD;

Fig. 11 is a diagrammatic illustration of a homogeneity constraint feature of an EDD;

Fig. 12 is a diagrammatic illustration of a mixture constraint feature of an EDD;

Fig. 13 is a diagrammatic illustration of a constraint relaxation feature of an EDD;

Fig. 14 is a diagrammatic illustration of allocations that occur in response to the constraint relaxation solutions shown in Fig. 13;

Fig. 15 is a diagrammatic illustration of an objective feature of an EDD;

Fig. 16 is a diagrammatic illustration of a cost conditional pricing feature of a EDD; and

Fig. 17 is a diagrammatic illustration of a unit conditional pricing feature of an EDD.

DETAILED DESCRIPTION OF THE INVENTION

The present invention is generally directed to a method of solving an exchange and, more particularly, to a method of processing one or more bids in a forward auction or exchange or one or more "asks" in a reverse auction or exchange in accordance with exchange description data associated with each bid or ask to achieve a desired exchange outcome.

With reference to Fig. 1, the present invention is embodied in computer-readable program code which executes on one or more computer systems 2. Each computer system 2 includes a microprocessor 4, a computer storage 6 and an input/output system 8. Each computer system 2 can also include a media drive 10, such as a disk drive, CD-ROM drive, and the like. Media drive 10 can operate with a computer-usable storage medium 12 capable of storing the computer software that embodies the present invention, which computer-readable program code is able to configure and operate computer system 2 in a manner to implement the present invention. Input/output system 8 can include a keyboard 14, a mouse 16 and/or a display 18. Computer system 2 is exemplary of a computer system capable of executing the computer-readable program code of the present invention and is not to be construed as limiting the invention.

In use, the computer-readable program code of the present invention enables a bidder, a seller or an exchange manager to associate processing instructions with one or more pay bids or ask bids. These processing instructions modify the manner in which a solver/analyzer (discussed hereinafter) processes the pay bids or ask bids.

Each pay bid or ask bid includes exchange data and can include associated processing instructions, "exchange description data" (EDD), which can be formed using the Extensible Markup Language (XML). However, the use of XML is not to be construed as limiting the present invention since the use of any other suitable computer language is envisioned.

For simplicity of description, the present invention will be described in connection with one or more pay bids issued in connection with a forward auction, one or more ask bids issued in connection with a reverse auction and/or one or more pay bids and/or ask bids issued in connection with an exchange.

With reference to Figs. 2 and 3, and with continuing reference to Fig. 1, one or more bids are conveyed from one or more bidders 22 to an exchange manager 24 via a suitable communication medium 26, such as the Internet, a local area network, a wide area network, etc. A bidder can be an agent acting on behalf of an actual bidder. More specifically, utilizing a computer system 2-2, exchange manager 24 inputs the items for the exchange into an exchange set up database 30 residing on computer system 2-2. Exchange manager 24 also includes the EDD (described in greater detail hereinafter) in exchange setup database 30. Exchange setup database 30 is not to be construed as limiting the invention since the use of a suitable database residing on computer system 2-2 or at a location other than computer system 2-2 is envisioned.

At a suitable time, bidder 22 downloads the exchange items from exchange setup database 30 into a bid forming module 32 and downloads some or all of the features of the EDD from exchange setup database 30 into a Bidder EDD database 34 residing on computer system 2-1. Utilizing bid forming module 32, bidder 22 forms one or more bids and/or or one or more bid groups for items that bidder 22 desires to buy and/or sell. A bid group includes a plurality of associated bids, where the associated bids can be selected randomly or the associated bids can be selected based on one or more attributes (discussed hereinafter). For example, an attribute can be utilized to restrict the bids forming a bid group to only those bids that are generated by a particular bidder and/or generated by bidders in a particular city. However, this is not to be construed as limiting the invention since the use of one or more additional or different attributes to qualify the bids of a bid group are envisioned.

If desired, prior to transmitting the formed bid or bid group to computer 2-2, bidder 22 can associate a feature from the EDD stored in Bidder EDD database 34 with each bid or bid group. Each EDD feature represents an instruction that a solver/analyzer 42 (discussed hereinafter) can utilize for processing the bid or bid group to achieve a desired outcome. Bidder EDD database 34 is not to be construed as limiting the present invention since a suitable database residing on computer system 2-1 or at a location other than computer system 2-1 is envisioned.

Once prepared, each bid or bid group and associated EDD feature(s), if any, is transmitted to computer 2-2 for processing. Computer 2-2 includes a parser module 36 that-computer 2-2 utilizes to determine if the exchange data forming each bid or bid group and any associated EDD feature received from computer 2-2 is well-formatted, and, if a document type definition (DTD) or schema is referenced, determines if the exchange data forming each bid or bid group and any associated EDD feature is valid. If the bid, bid group or any associated EDD feature is not well-formatted or is invalid, parser module 36 rejects the bid or bid group and causes computer system 2-2 to issue a suitable error message. Otherwise, the bid or bid group and any associated EDD feature is parsed as validated exchange data and validated EDD feature(s) to an exchange server 38 for winner determination processing. Exchange server 38 can be a separate application running on computer system 2-2 or a separate server.

Exchange server 38 includes a model builder 40 which constructs a mathematical model of the exchange based on the validated exchange data and validated EDD feature(s) received from parser module 36. The form of this mathematical model depends on the capabilities of a solver/analyzer 42 that is utilized to process the model. For example, if solver/analyzer 42 is a linear or mixed integer program solver, then the model would include decision variables, with each variable having one or more associated bounds and/or constraints. For example, if solver/analyzer 42 is based on the method, apparatus and data structures for optimal anytime winner determination described in United States Patent No. 6,272,473, incorporated herein by reference, then the mathematical model would include the binary tree structured search described therein. However, this is not to be construed as limiting the invention.

Solver/analyzer 42 determines the best allocation for validated exchange data and validated EDD feature(s). More specifically, solver/analyzer 42 determines feasible solutions, e.g., which bids should be awarded, and performs consistency checks against any EDD features. If the consistency checks are successful, solver/analyzer 42 outputs one or more feasible solutions. Each feasible solution includes an allocation value, winning bids and constraint values. Each feasible solution is then processed and/or formatted as necessary and forwarded to computer system 2-1.

In the foregoing description, bidder 22 associated one or more EDD feature(s) with one or more bids or bid groups transmitted to computer 2-2 for processing. However, exchange manager 24 can also or alternatively associate one or more EDD feature(s) with the one or more bids or bid groups received from bidder 22. This later association of one or more EDD feature(s) with one or more bids or bid groups received from bidder 22 is illustrated in Fig. 3 by dashed line 44.

With reference to Fig. 4, and with continuing reference to Figs. 1-3, an exemplary bid 50 input into parser module 10 includes one or more items 52-1, 52-2, 52-3 .. 52-N having associated quantities 54-1, 54-2, 54-3... 54N, respectively, and an associated bid price 56. In accordance with the present invention, bid 50 can also have EDD 58 associated therewith.

With reference to Fig. 5, the EDD included in exchange setup database 30 includes bid EDD 60, item EDD 62 and global EDD 64. Bid EDD 60 includes the features of bid attributes and bid adjustments. Item EDD 62 includes the features of item attributes, item adjustments, free disposal, reserve price and action. Global EDD 64 includes the feature(s) of cost constraint/requirement, unit constraint/requirement, counting constraints/requirement, homogeneity constraint, mixture constraint, objective, cost/unit condition pricing, constraint relaxers, feasibility obtainers and quote request. Each of these feature(s) will now be described in greater detail.

Item EDD

:

With reference to Fig. 6, and with continuing reference to Figs. 4, and 5, suppose that bid 50 only includes item 52-1 having a quantity 54-1 of 10 and a price 56 of $10.00. If bid 50 is created by a buyer, price 56 indicates the amount the buyer is willing to pay for the quantity 54-1 of item 52-1. In contrast, if bid 50 is created by a seller, price 56 is an amount the seller would like to receive for the quantity 54-1 of the item 52-1. However, bid 50 can include price 56 for a plurality of items 52, each of which has its own associated quantity. In Fig. 6, bid 50 has an Item EDD 76 associated therewith. EDD 76 can include the features of free disposal 70, reserve price 72 and/or action 74.

Action

:

Action 74 has two settings; buy and sell. In a forward auction or exchange, action 74 is set to sell when item 52-1 is being sold. In a reverse auction or exchange, action 74 is set to buy when item 52-1 is being bought. In Fig. 6, action 74 is set to sell, indicating that item 52-1 is for sale. Quantity 54-1 associated with bid 50 specifies the total number of units for sale if action 44 is set to sell. However, if action 74 is set to buy, quantity 54-1 associated with bid 50 specifies the total number of units to purchase.

Free Disposal

:

When a bidder is a seller, free disposal 70 enables the bidder to indicate a willingness to sell less than the specified item quantity 54-1, or when the bidder is a buyer, enables the buyer to a indicate a willingness to accept more than the specified item quantity 54-1, without affecting the bid price 56. Free disposal 70 may be used on both the supply side and demand side of all exchange formats, including forward auctions and reverse auctions. In bid 50 a seller offers a quantity 54-1 often of item 52-1 for sale and includes in EDD 76 associated with bid 50 a quantity of five in the free disposal feature 70 of bid 50. The combination of quantity 54-1 and free disposal feature 70 indicates that the seller is willing to sell between five and ten items.

Reserve Price

:

Reserve price 72 of EDD 76 can be used to set the maximum price above which item 52-1 will not be bought, or minimum price below which item 52-1 will not be sold. In bid 50, a value of$7 is associated with the reserve price feature 72. This indicates that a seller or buyer does not wish to sell or buy any quantity of item 52-1 of bid 50 at a price below or above, respectively, $7.

Item Attribute(s)

:

EDD 76 can also or alternatively include for bid 50 item attributes that can be used by the bidder to complete or refine the specification for each item 52 of bid 50. For example, EDD 76 includes three item attributes: color 78, weight 80 and city 82 for item 52-1. For color item attribute 78, suppose that the only acceptable color values are red, green and blue. Weight item attribute 80 is defined to be a decimal numeric with minimum and maximum values, for example, of 10.0 and 14.0, respectively. City item attribute 82 is an alphanumeric string that can receive the name of any city. Other item attributes can include width, height, purity, concentration, pH, brand, hue, intensity, saturation, shade, reflectance, origin, destination, volume, earliest pickup time, latest pickup time, earliest dropoff time, latest dropoff time, production facility, packaging and flexibility.

If a bid specifies a color not listed in the color item attribute 78, a weight outside the range listed in weight item attribute 80 or a city not listed in city item attribute 82, the bid will be rejected by solver/analyzer 42. Otherwise, the bid will be processed by solver/analyzer 42

Item Adjustment(s)

:

EDD 76 can also or alternatively include for each item 52 of bid 50 any number of item adjustments. Each item adjustment includes a condition and value whereupon, if the condition holds, then the value is applied to the bid. In the example shown in Fig. 6, EDD 76 includes two item adjustments 84 and 86. Item adjustment 84 specifies that a value of $2 should be applied to a bid that is bidding on green colored item 54-1. Item adjustment 86 is a per unit additive adjustment. It specifies that a value of $1 should be applied to a bid for each unit of item 54-1 in a single unit bid where the item has a weight greater than or equal to 11.0.

Bid EDD

:

With reference to Fig. 7, bid 50 can also or alternatively include a Bid EDD 90 associated therewith. In contrast to the features of Item EDD 70, the features of Bid EDD 90 operate on the bid as a whole versus each item of a bid. EDD 90 is a specific example of Bid EDD 60 shown in Fig. 5. EDD 90 and EDD 76 include the features of bid adjustment(s) 98 - 102 and item adjustment(s) 84 -86, respectively, that quantify the effects of non-price attributes, e.g., item attribute(s), discussed above, and bid attributes, discussed hereinafter. These attributes can be properties that allow incomplete item specification and, therefore, more economically efficient and participant-friendly marketplaces. Any measurable, quantifiable or qualitative attribute can be defined by the exchange manager or bidder to determine the parameters and character of the exchange.

Bid Attribute(s)

:

As items have attributes, so do bids. However, a bid attribute behaves a little differently. Where item attributes are used by buyers to complete or refine the specification of an item, bid attributes are used by potential acceptors of bids to differentiate among bids.

In Fig. 7, EDD 90 is associated with bid 50 and is processed by solver/analyzer 42 along with bid 50 and one or more other bid(s) (not shown). EDD 90 includes the features of bid attributes and bid adjustments. Exemplary bid attribute(s) include credit worthiness 92, bidder location 94 and shipping cost 96. Credit worthiness 92 has three exemplary selections by which bid 50 can be set to a level of credit worthiness of the bidder. If the attribute for credit worthiness is set to "Poor" 104-1, it tells solver/analyzer 42 that the bidder of bid 50 has bad credit. Likewise, the bid attributes for credit worthiness 104 of "Good" 104-2 and "Excellent" 104-3 signifying their respective rankings of the bidder's credit worthiness. The selection of credit worthiness in EDD 90 is typically made by exchange manager 24 instead of the bidder of bid 50 to avoid falsification of this selection.

The bid attribute for bidder location 94 provides the location of the bidder. This is given as an alphanumeric string so that any possible string combination can be entered. The bid attribute shipping cost 96 stores the cost of shipping those items that the bidder has bid on. Bid attribute shipping cost 96 is a decimal field in which the amount of the shipping cost can be entered. Other exemplary bid attributes can include bidder reliability, bidder reputation, bidder timeliness, freight terms and conditions, insurance terms and conditions, bidder distance and bidder flexibility.

Bid Adjustment(s):

EDD 90 can also include bid adjustments 98, 100 and 102 that are similar syntactically to the item adjustments previously described. The following numerical examples of bid adjustments 98 and 100 are for the purpose of illustration and are not to be construed as limiting the invention. Bid adjustment 98 is for $50 and depends on whether the bid attribute for credit worthiness 92 is set to "Excellent" 104-3. If solver/analyzer 42 determines that the bid attribute for credit worthiness 92 is set to "Excellent" 104-3, the price of bid 50 is decreased (or increased) by $50. If the bid attribute for credit worthiness 92 is set to "Poor" 104-1 or "Good" 104-2, the price of bid 50 remains unchanged. Bid adjustment 100 has a value of$25 that is applied when the bid attribute for shipping cost 96 is between $50 and $100. In this example, the only time a bid adjustment value is applied to bid 50 is when shipping cost attribute 96 is greater than $50 and less than $100. Bid adjustment 96 also illustrates the use of the logical operator AND as a connector between an attribute and an adjustment. In addition to AND, the logical operators OR and NOT can also be utilized as connectors. Moreover, logical operators may be nested within other logical operators.

In bid adjustment 100, the determination of whether the actual shipping cost falls between a range is made using tests. The first test is based on the actual shipping cost being less than a first value, in this example $100. The second test is based on the actual shipping cost being greater than a second value, in this case $50. Each of these tests, i.e., "less than" and "greater than", are from a group of operators over non-price attributes. These operators include "equal to" "less than" "less than" or "equal to" "greater than" "greater than or equal to" and "contains item".

Each bid adjustment 98, 100 and 102 is expressed as a conditional test. Namely, if the condition holds, then the specified adjustment is applied. More complex expressions allow dependence of whether the adjustment is applied based on multiple attributes.

Bid adjustment 102 demonstrates the "contains item" adjustment. This adjustment serves two purposes. The first is obvious from its name: it tests whether or not a bid contains an item. It should be appreciated that the contains item adjustment can only be used in a bid adjustment. In the example shown in Fig. 7, bid adjustment 102 specifies that any bid that contains Item I3 should have a value of $10 dollars applied to the value of the bid price. The second use for the "contains item" adjustment is for referencing item attributes inside of a bid adjustment. In the example shown in Fig. 7, bid adjustment 102 specifies that a value of $10 should be applied to bid 50, which contains Item I3. In addition, an item adjustment of bid adjustment 102 specifies that the color of Item I3 must be blue for the value of $10 to be applied to bid 50.

Each bid adjustment is typically one of two exemplary types: additive or multiplicative. Additive adjustments apply a positive (or negative) amount to a bid if the condition holds for that bid. Additive adjustments can either be absolute or per unit. Absolute additive adjustments are simply applied to the bid if the condition holds. Per unit additive item adjustments are multiplied by the number of units of the item in the bid before application to the bid. Multiplicative adjustments can only be used with bid adjustments, they cannot be used with item adjustments. Multiplicative adjustments apply a specified percentage correction to a bid if the condition holds. If the percentage is positive, the correction increases the value of the bid. If the percentage is negative, the correction decreases the value of the bid. These particular adjustments are not to be construed as limiting the invention since other suitable adjustments can also be utilized.

Global EDD

:

As shown in Fig. 5, global EDD 64 can include constraint features, requirement features, objectives, cost/unit condition pricing, constraint relaxers, feasibility obtainers and quote requests which will be now be described in greater detail.

Constraint(s):

There are several broad categories of constraint features including cost constraints, unit constraints, counting constraints, homogeneity constraints and mixture constraints. Generally, constraints are limits imposed on some aspect of the outcome of an allocation. For example, a constraint can limit the maximum number of winning buyers in a forward auction or the maximum number of winning sellers in a reverse auction. Another constraint can limit the currency volume sold to any one bidder. Still further, another constraint can limit the quantity of an item that a single supplier can supply. The purpose of constraints is to facilitate the management of solver/analyzer 42 so that feasible solutions are returned which meet the objectives of the market. To this end, constraint features of global EDD 64 are typically associated with a bid or bid group by exchange manager 24. However, this is not to be construed as limiting the invention. Constraints ensure that the allocation conforms to minimum and/or maximum specified limits.

Cost Constraint(s):

With reference to Fig. 8(a), a cost constraint feature 110 of global EDD 64 restricts the winning allocation by establishing a limit that is based on winning bid prices and quantities. In an example of establishing this limit, two bid groups 112 and 114 are created. Bid group 112 is the constrained group and bid group 114 is the control group. Bid group 114 is shown in Fig. 8(a) for illustration purpose, but it is assumed to be an empty group. There can be many reasons to constrain a group of bids. For example, an exchange may have a need to limit the sum of the prices all of the bids from bidders of a first city. Accordingly, a bid group is established with all of the bidders from the first city. It may also be desirable to limit the bidders from the first city as compared to a second city.

Cost constraint 110 causes solver/analyzer 42 to compare the two bid groups with respect to the sums of the prices of their winning bids. If the comparison is based on percentage, then the sum of the prices of the winning bids of the first bid group divided by that of the second bid group must be less than the constraint maximum limit, if any, and greater than the constraint minimum limit, if any. If the comparison is absolute, then the sum of the prices of the winning bids of the first bid group must be at least the minimum limit, if any, more than that of the second bid group, and at most the maximum limit, if any, less than that of the second bid group. For a comparison based on percentage, to avoid division by zero (0) when the second bid group 146 does not exist, an imaginary second bid group (not shown) is created that contains all of the winning bids. The comparison based on percentage is then determined by dividing the sum of the quantity of items of the winning bids of bid group 144 by that of the imaginary second bid group and comparing the solution to the maximum percentage constraint, if any, and/or the minimum percentage constraint, if any.

For example, suppose that a forward auction includes a plurality of bids where four bids 116-1 - 116-4 are made by bidders who fall into a group of interest where it is desirable to limit, based on cost, the value of the bids of this group. Suppose that the four bidders are from Tucson and, for this auction, there is a rule that bidders from Tucson may only be allocated a maximum limit of 25% of the total value of the auction. In this example, because it is desired to limit the auction solution as to the value of the bids of the Tucson bidders, cost constraint 110 includes bids 116-1 - 116-4 forming bid group 112 which is limited by maximum limit constraint 118 to 25% of the total allocation value. In other words, if the value of bid group 112 is over 25% of the total allocation value, the solution is infeasible. If desired, cost constraint 110 can also or alternatively include a minimum limit constraint 102 which is utilized to establish a lower limit on the total allocation value.

Cost constraints are strict constraints. A strict constraint must be satisfied or the allocation is infeasible. For example, a cost constraint can limit a bidder to receive at least 50% of the total allocation value. For example, suppose a bidder places a bid having a value of $11 in an exchange where the total allocation value of the exchange is $21. Then, the value of the constraint is $11/$21 or 52.38%. Since 52.38% is greater than the cost constraint of 50%, the allocation is feasible. However, if the cost constraint is raised to 60%, the allocation is infeasible because 52.38% is less than 60%. In some situations, it may be desirable for the bidder to be required to win at least 50% of the allocation, or else be awarded no allocation.

Cost Requirement(s):

With reference to Fig. 8(b), a cost requirement feature 130 of global EDD 64 enables solver/analyzer 42 to withhold a bid or bid group from an allocation if the limitation is not satisfied. Cost requirement 130 is syntactically similar to a cost constraint. However, where a cost constraint makes the solution infeasible, a cost requirement enables solver/analyzer 42 to construct an allocation, where a bid or bid group that otherwise would be allocated is withheld from the allocation because a limitation on the bid or bid group is not satisfied. In other words, the difference is in the scope of the limit. For a cost constraint, in the event that the limit is not met, the whole allocation is infeasible. In contrast, a cost requirement only directly affects the bid or bid group under the constraint. There is still the all or nothing limitation as in the cost constraint. However, in the case of a cost requirement, if a limit is placed and not met, then the bidder receives nothing, but the allocation not necessarily infeasible.

For example, assume that a forward auction includes a plurality of bids where four bids 132-1 - 132-4 are made by bidders who fall into a group of interest where it is desired to limit, based on cost, the value of the bids of the particular bidders. Suppose that the four bidders are from Tucson and for this auction there is a rule that bidders from Tucson may only be allocated 25% of the total value of the auction, or else the Tucson bidders get nothing at all. In this example, because it is desired to limit the auction solution as to the value of the bids of the Tucson bidders, cost requirement 130 includes bids 132-1 - 132-4 forming bid group 134 which is limited by a maximum limit constraint 136 to 25% of the total allocation value. In other words, if the sum of the values of bids 132-1 - 132-4 exceeds 25% of the total allocation value, the Tucson bidders receive nothing in the winning allocation. In order for bid group 134 to be allocated the items associated with bids 132-1 - 132-4, the sum of the values of these bids must be less than the maximum limit constraint 136. If desired, cost requirement 130 can also or alternatively include a minimum limit constraint 138 which is utilized to establish a lower limit on the total allocation value.

Unit Constraint(s):

With reference to Fig. 9(a), a unit constraint feature 142 of global EDD 64 restricts the winning allocation by setting up a limit which is based on a quantity of items that are bought and/or sold in winning bids. In an example of setting this limit, bid groups 144 and 146 and an item group 148 are created. Unit constraint 142 causes solver/analyzer 42 to compare bid group 144 and bid group 146 with respect to the sums of the number of items listed in the respective item group 148 of their winning bids.

For example, suppose that a forward auction includes a plurality of bids where three bids 150-1 - 150-3 are made by a particular bidder where it is desired to limit the quantity of items awarded to that bidder. In this example, suppose that the bidder is a buyer from a very large computer discount sales company and that each of the three bids is for as many units as are available of the new computer. Moreover, suppose that 2000 of these computers are available and that there is a need to distribute some of the computers to other buyers in order to facilitate the development of a wide customer base. Lastly, suppose that it is desired to limit the quantity of computers awarded to the bidder to one-half of the available computers, or 1000 computers. Since it is desired to limit the bidder, unit constraint 142 is formed with bid group 144 including bids 150-1 - 150-3. The item of bid group 144, e.g., new computers, is added to item group 148. A value, e.g., 1000, associated with item group 148 is designated as a maximum limit constraint 152 of unit constraint 142 for limiting the maximum quantity of computers bid group 144 can be awarded to no more than 1000 units. When the winning allocation is returned, the computer discount sales company is allocated no more than 1000 units by solver/analyzer 42. In this example, item group 148 included only computers. However, any part or item that would be useful to limit in such a manner can also or alternatively be included in item group 148.

As in cost constraints, there are two types of comparisons that can be made for a unit constraint. Namely, an absolute comparison, as in the foregoing example of limiting the number of computers to a computer discount sales company, and a comparison based on percentage. In a comparison based on percentage, the sum of the number of items in the winning bids of bid group 144 must be at most a maximum limit, if any, different than that of bid group 146. In this example, bid group 146 is empty. This means that the quantity of items awarded to bid group 144 is limited to no more than 1000. However, a suitable value can be included in a minimum limit constraint 154 for limiting the minimum quantity of computers bid group 144 can be allocated to at least 1000 units. For a comparison based on percentage, the sum of the quantity of items of the winning bids of bid group 144 divided by that of the bid group 146 must be less than a maximum percentage constraint (not shown) if any, and/or greater than a minimum percentage constraint (not shown) if any. The maximum percentage constraint and the minimum percentage constraint can also be the same. For a comparison based on percentage, to avoid division by zero (0) when the second bid group 146 does not exist, an imaginary second bid group (not shown) is created that contains all of the winning bids. The comparison based on percentage is then determined by dividing the sum of the quantity of items of the winning bids of bid group 144 by that of the imaginary second bid group and comparing the solution to the maximum percentage constraint, if any, and/or the minimum percentage constraint, if any.

For example, assume it is desired to limit the quantity of items awarded the bidder associated with bid group 144. Accordingly, unit constraint 142 would include a maximum percentage constraint (not shown) that solver/analyzer 42 utilizes to limit the quantity of computers awarded the bidder to no more than one-half of the available quantity. Since the items for this example are included in bids 150-1 - 150-3, item group 148 is not needed.

Unit constraints, like cost constraints, are strict constraints. Namely, a strict constraint must be satisfied or the allocation will be infeasible. For example, a unit constraint can limit a bidder to receive at least 1000 units of an item in an auction. This forces the bidder to have at least 1000 units in the auction. Thus, if a bidder places two bids that are awarded 500 units of an item and 1000 units of the item, since this bidder satisfied the limit of at least 1000 units of an item, the allocation is feasible. However, if the bidder places the same bids, but the total quantity of the item of all the bids did not add to 1000 units, then the solution is said to be infeasible, and there is no solution.

Unit Requirement(s):

With reference to Fig. 9(b), a unit requirement feature 160 of global EDD 64 does not contain the same restriction as a unit constraint. A unit requirement allows for a quantity of zero to be allocated to a bidder to provide a winning allocation. The difference is in the scope of the limit. A unit requirement is syntactically similar to a unit constraint. However, where a unit constraint makes the solution infeasible, a unit requirement allows a quantity of zero to be allocated. Stated differently, for a unit constraint, where the limit is not met, the whole allocation is infeasible. In contrast, for a unit requirement, where the limit is not met, only the bid group associated with the unit constraint is not allocated.

For example, suppose a forward auction includes a plurality of bids where three bids are made by a particular bidder to whom it is desired to limit the quantity of items awarded the bidder. Suppose that the bidder is a buyer from a very large computer discount sales company and the three bids are for a new computer. For this exchange, there is a need to sell all the computers as quickly as possible. Accordingly, it is desired to sell a large quantity of the available computers to the computer discounter because this is a large company that can resell many computers. Therefore, unit requirement 160 of global EDD 64 is created such that the bidder (discounter) must be awarded at least 1000 computers. Since it is desired to limit the bidder, a bid group 162 is formed that includes bids 168-1 - 168-3. The items for this example, i.e., new computers, are added to item group 166. Bid group 162 is then limited to at least 1000 units of item group 166 it can be awarded by including the value 1000 as a minimum limit constraint 170 and by including the value of zero as a maximum limit constraint 172. In this example, the bidder will be allocated 1000 or more computers, or no computers. If the bidder is allocated no computers, however, this is still a feasible solution.

Counting Constraint(s):

With reference to Fig. 10(a), a counting constraint feature 180 of global EDD 64 involves outcome parameters. Outcome parameters are those besides bid and item allocations and net exchange revenue. An example is a legally imposed constraint, such as an award of a minimum percentage of an allocation to minority firms. There may also be a market domination concern that compels an award of a maximum percentage of an allocation to one or a group of firms that may be specified. Another common example is to ensure that a certain percentage of the business goes to a specific firm, because of a long-standing business relationship. Still another example would be to condition an award to a bidder to at least a certain percentage of the allocation to avoid giving the bidder such a small amount of business that it does not cover operating expenses.

For example, counting constraint 180 of global EDD 64 includes a value of four as a maximum limit constraint 182 on the number of winning bidders. In this example, there are six bidders and it is assumed, but not shown, that each bidder has placed a number of bids in the auction. The bids of each bidder are formed into bid groups 184-1 - 184-6, with bid group 184-1 including all the bids that placed by bidder 1, with bid group 184-2 including all the bids placed by bidder 2, and so forth. The value of four as maximum limit constraint 182 constrains the allocation made by solver/analyzer 42 to four bid groups out of the six that were created. Maximum limit constraint 182 causes solver/analyzer 42 to form a winning allocation that has no more than four of bid groups 184-1 - 184-6. Since bid groups 184 in this example represent bidders, the counting constraint has effectively limited the number of winners.

With continuing reference to Fig. 10(a), suppose that the value of maximum limit constraint 182 is set to zero and a value of four is included in a minimum limit constraint 186. This will cause the winning allocation to include at least four of the bidders 184 included in counting constraint 180. Moreover, both maximum limit constraint 182 and minimum limit constraint 186 may be set to values wherein the desired number of winners falls within the range of values.

Counting Requirement(s):

With reference to Fig. 10(b), a counting requirement feature 190 of Global EDD 64 has the same syntax as a counting constraint, but differs in outcome. The difference between a counting constraint and a counting requirement is that the counting requirement with a minimum limit constraint value greater than zero will also allow a value of zero. For example, suppose that counting constraint 180 in Fig. 10(a) has a value of four included as its minimum limit constraint 182. Then, four or more of bid groups 184-1 - 184-6 must win or the solution is infeasible. In contrast, suppose a counting requirement feature 190 shown in Fig. 10(b) has a value of four as its minimum limit constraint 192. Then, at least four of the bid groups 194-1 - 194-6 must win or none of these bid groups win. Hence, the solution is still feasible.

Homogeneity Constraint(s):

With reference to Fig. 11, a homogeneity constraint feature 200 of global EDD 64 enables limits to be placed on bids. With a homogeneity constraint, a limit based on an item attribute or a bid attribute can be placed on a bid. For example, in Fig. 6, item 52-1 has an item attribute color 78. Suppose a homogeneity constraint of global EDD 64 is needed in addition to the features of EDD 76 to limit the number of represented colors in all of the specified items of awarded bids, where the award of an item of green color is irrelevant, even though it is one of the colors for that item attribute. Accordingly, homogeneity constraint 200 of global EDD 64 can be created having color limit maximum constraint 202 value of one. Color limit maximum constraint 202 causes solver/analyzer 42 to limit to a quantity of one the items that are listed in item attribute descriptions 204 and 206, where item attribute description 204 limits the homogeneity constraint of an Item 1 to the color blue and item attribute description 206 limits the homogeneity constraint of Item 1 to the color red. In response to homogeneity constraint 200, the allocation would not exceed one of the two colors of blue and red items, but any number of green items could be awarded since green was not included in homogeneity constraint 200. Thus, one blue item- or one red item, and/or any number of green items may be allocated. As can be seen, the homogeneity constraint ensures that no more than one of the specified colors will appear in the allocation. Since only the colors specified in homogeneity constraint 200 are considered for purposes of homogeneity, any other color, in this example green, included in color item attribute 78 in Fig. 6 can also appear in the allocation. A limit minimum can also or alternatively be included in homogeneity constraint 202 for limiting the minimum quantity for an item awarded in an allocation or to establish a range of an item awarded in an allocation.

The foregoing example shows one item per item attribute description 204, 206. However, multiple items may appear in each item attribute description 204, 206. These items form an equivalence class for the purpose of homogeneity. For example, to consider cyan to be the same as blue when assessing homogeneity, it can be added to the item group that contains blue.

Mixture Constraint(s):

With reference to Fig. 12, a mixture constraint feature 210 of global (EDD) 64 allows for mixing of attributes of interest. In the previous example, a homogeneity constraint limited by maximum or minimum the different colors represented in all of the specified items of all of the specified winning bids. A mixture constraint will still limit by attribute, similar to homogeneity constraint 200, but it also allows any combination of bids or items to be selected in fulfilling that limit. For example, mixture constraint 210 of global EDD 64 can be created that includes a value of twelve for a weight limit 212 of an Item 1 listed in a mixture constraint description 214. Weight limit 212 causes solver/analyzer 42 to limit the weight of all quantities of item 1 to an average of on more than (or no less than) twelve pounds. Mixture constraint 210 allows heterogeneity in an allocation providing the average is within specified limits. Therefore, in this example, suppose it is desired to have a mixture of weights, providing the average weight is no more than (or no less than) twelve pounds. With mixture constraint 210, it does not matter how the various weights are mixed. The average value which is constrained by mixture constraint 210 may be determined by any one or a combination of items. Mixture constraints may also be price weighted, i.e., the prices of each bid will weight the average. For example, an attribute, e.g., item weight, on a $2 bid will have twice the effect of the same attribute has on a $1 bid.

In the foregoing example, a mixture constraint 210 is described as being operative on an item attribute, i.e., weight. A mixture constraint, however, can also be operative on a bid attribute of a bid group. Examples of exemplary bid attributes that a mixture constraint can operate on are described above in connection with Fig. 7.

Objective(s):

With reference to Fig. 13, an objective feature 257 of global EDD 64 establishes a maximization or minimization goal that solver/analyzer 42 utilizes to determine an allocation value for an exchange. Each maximization goal has one specific meaning for forward auctions, reverse auctions, and exchanges. Each minimization goal has one specific meaning for a reverse auction.

An objective can be: surplus, traded bid volume, traded ask volume or traded average volume. Each objective expresses a maximization goal for forward auctions and exchanges or a minimization goal for reverse auctions. The following table shows the meanings for each of these objectives. <tables id="tabl0001" num="0001"><table frame="all"><tgroup cols="4" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="39.37mm" /><colspec colnum="2" colname="col2" colwidth="39.37mm" /><colspec colnum="3" colname="col3" colwidth="39.37mm" /><colspec colnum="4" colname="col4" colwidth="39.37mm" /><thead valign="top"><row><entry namest="col1" nameend="col1" align="left">Objective</entry><entry namest="col2" nameend="col2" align="left">Forward Auction</entry><entry namest="col3" nameend="col3" align="left">Reverse Auction</entry><entry namest="col4" nameend="col4" align="left">Exchange</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">Surplus</entry><entry namest="col2" nameend="col2" align="left">sum of accepted bids less the sum of their item reserve prices</entry><entry namest="col3" nameend="col3" align="left">N/A</entry><entry namest="col4" nameend="col4" align="left">sum of accepted bids less sum of accepted asks</entry></row><row><entry namest="col1" nameend="col1" align="left">Traded bid</entry><entry namest="col2" nameend="col2" align="left">sum of accepted bids</entry><entry namest="col3" nameend="col3" align="left">N/A</entry><entry namest="col4" nameend="col4" align="left">sum of accepted bids</entry></row><row><entry namest="col1" nameend="col1" align="left">Traded ask volume</entry><entry namest="col2" nameend="col2" align="left">sum of item reserve prices of accepted bids</entry><entry namest="col3" nameend="col3" align="left">sum of accepted asks</entry><entry namest="col4" nameend="col4" align="left">sum of accepted asks</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">Traded average</entry><entry namest="col2" nameend="col2" align="left">average of the sum of accepted bids and sum of their item reserve prices</entry><entry namest="col3" nameend="col3" align="left">N/A</entry><entry namest="col4" nameend="col4" align="left">Average of the sum of accepted bids and sum of accepted asks</entry></row></tbody></tgroup></table></tables>

The meaning associated with each of the foregoing objectives causes solver/analyzer 42 to perform a specific optimization. An objective is useful because it enables specification of exactly what is wanted in a forward auction or exchange. For example, suppose a seller has three items for sale: item A 260, item B 262 and item C 264 for $100 dollars, $45 dollars and $45 dollars, respectively. These are ask bids since the seller is asking to sell these three items. Moreover, suppose there are three buy bids: Bid 1 266 for Item A 260 at a cost of $100; Bid 2 268 for Items B and C 262 and 264 at a cost of $105; and Bid 3 270 for Item C 264 at a cost of $70. Furthermore, suppose that these three buy bids are logically connected by an XOR (exclusive OR) logical operator whereupon only one of Bids 266, 268 and 270 will be allocated by solver/analyzer 42.

If an exchange objective 258 included in objective feature 257 associated with one or more bids or bid groups is "traded ask", Bid 266 is allocated by solver/analyzer 42 since it has the maximum ask value. In contrast, if the exchange objective is "traded bid", Bid 2 268 is selected since it has the maximum bid value. If the exchange objective is a "surplus", Bid 3 270 is allocated since the values associated with bids A and B 266 and 268 have the maximum surplus value. Lastly, if the exchange objective is "traded average", either Bid 1 for Item A 260 at $100 or Bid 2 for Items B and C 262 and 264 at $105 is selected. An objective can also be the number of winning bidders or the number of losing bidders in an allocation.

Constraint Relaxer(s):

With reference to Figs. 14 and 15, all of the constraints that have been described thus far have the capacity to be relaxed. This is implemented using a constraint relaxer feature 220 of global EDD 64. The ability to relax a constraint has two purposes. Namely, to obtain candidate allocations when the original, constrained problem does not have a feasible allocation, and to search for alternative allocations when there is a feasible solution. Such alternative allocations illustrate the impact on a solution value as more important constraints are relaxed. The importance of each constraint depends on the relative constraint relaxation importance weight assigned thereto. These weights are dependent on the weights and types of each constraint in an exchange.

Fig. 14 depicts a constraint relaxation feature list 220 of global EDD 64 that includes desired solutions 222, 224 and 226 that apply to constraints specified for an exchange. For example, constrained solution 222 is a request for solver/analyzer 42 to search for an allocation with all the constraints in place, while unconstrained solution 226 is a request for solver/analyzer 42 to search for an allocation with no constraints in place. Between constrained and unconstrained solutions 222 and 226, there is relaxation solution 224. Relaxation solution 224 is a request for solver/analyzer 42 to search for one or more allocations as a function of soft and/or hard properties for each constraint. For example, in Figs. 8(a) and 10(a) soft properties 228 and 236 are set for cost constraint 110 and counting constraint 180, respectively, while in Fig. 9(a), a hard property 232 is set for unit constraint 142. When relaxation solution 224 is selected in constraint relaxation feature list 220, these properties cause solver/analyzer 42 to obtain a feasible solution by relaxing the soft constraints in Figs. 8(a) and Fig. 10(a) while maintaining the hard constraint in Fig. 9(a). In this example, the hard constraint is so important that to relax it will create a useless allocation.

More specifically, constrained solution 222 causes solver/analyzer 42 to create constrained allocation 240, namely, a fully constrained allocation for which either a feasible, market desirable solution or an infeasible solution exists. In other words, constrained allocation 240 shows the bids that should be awarded given all of the input conditions and constraints. In the example shown in Fig. 15, constrained allocation 240 shows three winning bids with an allocation value of $1,000.

In contrast, relaxation solution 224 causes solver/analyzer 42 to relax soft constraints to obtain one or more relaxed allocations 242, with the final relaxation being an unconstrained allocation 244. Unconstrained solution 226 causes solver/analyzer 42 to disable both hard and soft constraints, so that the solution can be viewed as to the effects of the constraints. Relaxed allocation 242 and unconstrained allocation 244 can show other useful allocations that do not necessarily meet all of the constraints. For example, relaxed allocation 242 shows a total of five winning bids with an allocation value of$4,000 and unconstrained allocation 242 shows a total of six bids with an allocation value of $5,000. Unconstrained allocation 244 illustrates the effect of imposing no constraints on the allocation of bids by solver/analyzer 42.

With reference back to Figs. 8(a), 8(b), 10(a) and 10(b), a relaxation importance can be associated with soft constraints. For example, cost constraint 110 can include relaxation importance 250 associated therewith, cost requirement 130 can include relaxation importance 252 associated therewith, counting constraint 180 can include relaxation importance 254 associated therewith and counting requirement 190 can include relaxation importance 256 associated therewith. Unit constraint 142 and unit requirement 160 can also include a relaxation importance if desired. The use of these relaxation importances will now be described.

In Fig. 8(a), cost constraint 110 has a value of ten for its relaxation importance 250. In Fig. 10(a), counting constraint 180 has a value of twenty for its relaxation importance 254. Cost constraint 110 and counting constraint 180 have soft property 228 and soft property 236, respectively, which enable solver/analyzer 42 to relax cost constraint 110 and counting constraint 180. In use of relaxation importance 250 and 254, if solver/analyzer 42 determines that cost constraint 110 or counting constraint 180 can be relaxed to obtain a feasible allocation, but it is not necessary to relax both, then cost constraint 110 having a value of ten for its relaxation importance 250 would be relaxed instead of relaxing counting constraint 180 having a value of twenty for its relaxation importance 254.

When constraint relaxation feature list 220 includes relaxation solution 224, solver/analyzer 42 interprets relaxation solution 224 as a request to find feasible allocations while relaxing constraints according their relaxation importance. The higher the relaxation importance, the less likely the constraint is to be relaxed, relative to other constraints. Relaxation solution 222 can also have an associated relaxation cost, e.g., 1000, which specifies the weight of the relaxation to be supplied solver/analyzer 42. The relaxation cost is calculated by aggregating, over all relaxed constraints, the amount by which the constraint is violated multiplied by its relaxation importance. The constraint relaxer feature causes solver/analyzer 42 to maximize or minimize an objective feature, discussed above, minus this relaxation cost. For example, if constraint relaxation feature list 220 included first relaxation solution 224 having a cost of 1000 and a second relaxation solution (not shown) having a cost of 2,000, solver/analyzer 42 relaxes constraints associated with the second relaxation list more than the constraints of the first relaxation list. Thus, in this example, solver/analyzer 42 would attempt to find a solution with a higher value for the second relaxation solution than the for the first relaxation solution 224.

Feasibility Obtainer:

A feasibility obtainer feature (not shown) operates like the constraint relaxer. However, it attempts to minimize the relaxation cost, instead of minimizing or maximizing an objective feature, discussed above, minus the relaxation cost. More specifically, a feasibility obtainer causes solver/analyzer 42 to generate feasible allocations when a winning allocation based constrained solution 222 is unavailable. For example, suppose that constraint relaxation feature list 220 only includes a request for a constrained solution 222 in the EDD associated with one or more bids or bid groups. Because only a constrained solution 222 has been requested, solver/analyzer 42 will only attempt to generate a winning allocation. However, if the EDD associated with the one or more bids or bid groups includes a feasibility obtainer, when solver/analyzer 42 determines that a feasible, constrained allocation cannot be found, solver/analyzer 42 relaxes one or more constraints in an attempt to find a feasible allocation.

Cost Conditional Pricing(s):

With reference to Fig. 16, a cost conditional pricing feature 272 of global EDD 64 modifies an outcome of a forward auction, a reverse auction or an exchange based on value limit(s). In an example of setting these limits, two bid groups 274 and 276 are created. Bid group 274 is a constrained group and bid group 276 is a control group. Bid group 276 is created for illustration purposes but it is assumed that it is an empty group. Cost conditional pricing is similar in form to cost constraints, except that cost conditional pricing 272 utilizes one or more modification constraints 278 to adjust the solution rather than forcing the solution to obey the constraints. Advantages of changing the price outcome of an exchange include, for example, giving a rebate of $20 if a buyer in a forward auction spends more than $1000 or a rebate of $50 if the buyer spends more than $2000. For example, bid group 274 is formed including all of the bids associated with buyer A. Cost conditional pricing 272 uses the difference in the volume of bid groups 274 and 276. In this example, since bid group 276 includes no bids, its volume defaults to empty and the difference is the volume of the bids of bid group 274 for buyer A. Modification constraint 278 causes solver/analyzer 42 to discount the bid of bid group 274 by $20 if the value of first bid group 274 is $1,000 or above. Moreover, modification constraint 278 causes solver/analyzer 42 to discount bid group 274 by $50 if the bid price of bid group 274 is $2,000 or above.

Unit Conditional Pricing(s):

With reference to Fig. 17, a unit conditional pricing feature 280 of global EDD 64 modifies the price outcome of a forward auction, a reverse auction or an exchange based on a difference in volume of units of two or more bids or bid groups of two or more bidders. In an example of setting the limit of unit conditional pricing 280, two bid groups 282 and 284 are created. Bid group 280 is the constrained group and bid group 284 is the control group. In this example, Bid group 284 is created for illustration purposes, but it is assumed that it is an empty group. Unit conditional pricing is similar in form to a unit constraint, except that unit conditional pricing 280 adjusts the solution rather than forcing the solution to obey the constraints. For example, suppose bid group 282 is formed including all of the bids associated with buyer A and condition modifiers 286 and 288 are formed. Solver/analyzer 42 then determines a difference in unit volume between items of an item group A 290 traded by bid group 280 and items of an item group 292 traded by bid group 284. If this difference is greater than the volume included in condition modifier 286, a discount of $20 is given to the bid group 282 or 284 having the greater volume. Similarly, if the difference in unit volume is greater than the value of the volume included in condition modifier 282, a discount of $50 included in condition modifier 288 is given to the bid group 282 or 284 having the greater volume. In the example shown in Fig. 17, since item group 292 and bid group 294 are empty, the volume is the number of units of item A listed in item group A 290 traded by bid group 282. Unit conditional pricing 280 uses the difference in the volume of the bid groups 282 and 284. In this example, since bid group 284 includes no bids, its volume defaults to empty and the difference is the volume of bid group 282 for buyer A. If the volume of bid group 282 is 1000 units or more than the volume of bid group 284, solver/analyzer 42 determines that condition modifier 286 is applicable and a discount of $20.00 is given. Similarly, if the volume of bid group 282 is 2000 units or more than the volume of bid group 284, solver/analyzer 42 determines that condition modifier 288 is applicable and a discount of $50.00 is given.

Quote Request:

A quote request feature (not shown) can be utilized to cause solver/analyzer 42 to treat a bid as a "quote request", whereupon solver/analyzer returns a price where the bid would just be included in an allocation, i.e., the least competitive price. In use, a quote request is enabled in an EDD associated with a bid. In response to receiving this bid and the associated EDD, solver/analyzer 42 determines a price where the bid would just be included in an allocation and outputs this price in association with the bid for consideration by the entity initiating the quote request, e.g., buyer, seller or exchange manager. Thereafter, if the entity initiating the quote request wishes to place one or more bids or associate one or more bids with a bid group that solver/analyzer 42 considers for inclusion into an allocation, such bid is made or such bid group is formed separately from the quote request. As can be seen, solver/analyzer 42 treats a quote request like a bid.

As can be seen, the features of EDDs 60, 62 and 64 enable a buyer, a seller or an exchange manager to modify the processing of one or more bids or bid groups by solver/analyzer 42 to generate different, feasible allocations that may be desirable in the winner determination process. This may be performed iteratively in order to see the effects of these modifications on the winning allocations.

Solver/analyzer 42 can include suitable software controls for terminating the processing of bids related to determination of an allocation. One control is a maximum processing time whereupon, when the maximum processing time is reached, solver/analyzer 42 terminates processing and reports the best allocation found. Another control compares the best allocation found at any point in time with an optimal allocation, i.e., an allocation with all integer constraints relaxed. If the difference between those two allocations reaches a predetermined value, solver/analyzer 42 terminates processing and reports the best allocation found. Another control is a manual abort command that can be issued by, for example, the exchange manager. In response to receiving this manual abort command, solver/analyzer 42 terminates processing and reports the best allocation found.

The invention has been described with reference to the preferred embodiments. Obvious modifications and alterations will occur to others upon reading and understanding the preceding detailed description. For example, the foregoing examples are for the purpose of illustration and are not to be construed in any way as limiting the invention. Moreover, while the currency values in some of the foregoing examples are expressed in United States dollars, the use of the present invention with other currencies is envisioned. It is intended that the invention be construed as including all such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.