WO2001027840A1 - Apparatus for and method of implementing business transactions - Google Patents

Abstract

An apparatus for and a method of implementing business transactions is provided. In accordance with a preferred embodiment of the invention, buyers and sellers of goods and services are linked together over a network (e.g., the Internet) (14) to facilitate resolution of business transactions (e.g., auctions, negotiations, markets). Transaction owners interface (12) with a transaction server (10) control processing of the business transaction. Bidders (13a, 13b, 13c) desiring to enter into a business transaction with the business transaction owner preferably request recommended or suggested competitive offers (e.g., bid prices) which will allow the bidders to be 'active' in the business transaction. In a preferred embodiment, the transaction server can be placed in one of a plurality of different operational modes such as an automatic mode for automatically generating suggested offers. A manual mode of the server allows transaction owners the ability to directly communicate with a bidder to provide manual recommendations or suggestions for competitive offers to be among the 'active' winners of the business transaction.

Description

APPARATUS FOR AND METHOD OF IMPLEMENTING BUSINESS TRANSACTIONS

This application claims priority to U.S. Provisional Patent Application No.

60/158,396, filed October 12, 1999, U.S. Provisional Patent Application No.

60/162,098, filed October 29, 1999, and U.S. Provisional Patent Application No.

60/189,463, filed March 15, 2000, which are each hereby incorporated by reference

in its entirety.

BACKGROUND

The e-commerce business to business market is expected to reach $1.3

trillion by 2003 (according to Forrester Research). The businesses and public sector

entities that comprise this enormous business-to-business (B2B) market are the

hundreds of thousands of firms, cities, states, hospitals, prisons, schools, etc. that buy

primary and finished goods and services. Efficient solutions to replace the

"traditional," inefficient purchasing methodologies are required. Current

inefficiencies result from several realities of purchasing:

• Buyers often have personal relationships with suppliers that result in sub-optimal purchasing decisions;

• Traditional sealed bid procurements simply do not push the price as low as a real-time, on-going auction; • Buyers often deal with so many variables in purchasing decisions that they simply cannot weigh each issue against the strengths of each supplier;

• Often, professionals who become buyers are not the highest skilled people in the firm or organization;

• Negotiations between buyers and potential suppliers are often extremely time-consuming and waste huge amounts of money in staff time alone;

• Current online solutions do not offer buyers a simple means to build in issues other than price that are important to the buyer; and

• Current online purchasing solutions are often too expensive in terms of up-front costs.

SUMMARY

An apparatus for and a method of implementing business transactions is provided. In accordance with a preferred embodiment of the invention, buyers and sellers of goods and services are linked together over a network (e.g., the Internet) to facilitate resolution of business transactions (e.g., auctions, negotiations, markets).

Transaction owners interface with a transaction server control processing of the business transaction. Bidders desiring to enter into a business transaction with the business transaction owner preferably request recommended or suggested competitive offers (e.g., bid prices) which will allow the bidders to be "active" in the business transaction. In a preferred embodiment, the transaction server can be placed in one of a plurality of different operational modes such as an automatic mode for automatically generating suggested offers. A manual mode of t e server allows transaction owners the ability to directly communicate with a bidder to provide manual recommendations or suggestions for competitive offers to be among the "active" winners of the business transaction.

BRIEF DESCRIPTION OF DRAWINGS

Figs, la and lb are block diagrams illustrating exemplary systems used to operate business transactions in accordance with a preferred embodiment of the invention;

Figs. 2-4 are flow charts illustrating bidding processes in accordance with preferred embodiments of the invention;

Figs. 5-17 are screen images of an exemplary commercial implementation of a business transaction in accordance with a preferred embodiment of the invention;

Figs. 18a-18e collectively represent the process flow for an auction owner in an exemplary commercial implementation of a negotiauction transaction in accordance with a preferred embodiment of the invention;

Figs. 19a and 19b collectively represent the process flow for an bidder in an exemplary commercial implementation of a negotiauction transaction in accordance with a preferred embodiment of the invention; Figs. 20a-20c collectively represent the process flow of an exemplary commercial implementation of a negotiauction transaction in accordance with a preferred embodiment of the invention; and

Figs. 21-45 are screen images of an exemplary commercial implementation of a business transaction in accordance with a preferred embodiment of the invention.

DETAILED DESCRIPTION

Preferred embodiments and applications of the invention will now be described. Other embodiments may be reahzed and structural or logical changes may be made to the disclosed embodiments without departing from the spirit or scope of the invention. Although the preferred embodiments disclosed herein have been particularly described as applied to implementation of auction transactions over the Internet, it should be readily apparent that the invention may be embodied to implement any transactions having the same or similar problems.

The system illustrated in Fig. la may be provided in accordance with a preferred embodiment of the invention to facilitate business transactions such as auction transactions, negotiation transactions, market transactions, etc. The system may be used to link buyers and sellers of goods and services in local or geographically remote regions around the world. As shown in Fig. la, business transactions can be easily initiated and conducted between a transaction owner over interface 12 and one or more bidders using bidder interfaces 13a, 13b, 13c connected through a network 14 (e.g., the Internet).

Business transaction server 10 is provided to store the transaction details (e.g., name, address, subject item, price, quantity, etc.) and execute the transaction processes under control of the transaction owner through transaction owner inter 12. As will be described in more detail below, in accordance with preferred embodiments of the invention, business transaction server 10 is capable of operating and supporting a variety of business transactions such as auction transactions, negotiation transactions, market transactions, request for quote (RFQ) transactions, etc.

Transaction server 10 is particularly useful in operating and supporting negotiauction transactions, which, in accordance with a preferred embodiment of the invention, combine features of auction and negotiauction transactions, as will be described in detail below.

In accordance with a preferred embodiment, business transaction server 10 may include one or more central processing units (CPU) 100 used to provide processing of input/output data between transaction owner interface 12 and network 14, and among the different modules (all connected together via system bus 109) within transaction server 10. CPU 100 typically executes one or more computer programs stored in the one or more memory devices graphically represented as memory module 102. A mode controller 104 is provided to switch from among a plurality of operational modes within the processing of a given business transaction (as will be described below). A bid calculation device 106 may be included within business transaction server 10 to calculate recommended or suggested bids for output to one or more of the bidder interfaces 13a, 13b, 13c, as will be described in more detail below. A transaction criteria detector 108 may also be included to review bids (and their respective bidders) for compliance with one or more sets of criteria that may be applicable to a given business transaction, as will be described below. The data sets representing applicable criteria are typically stored in a memory such as memory module 102 or any other remote or local memory structure.

Fig. lb depicts an exemplary commercial implementation of the business transaction system shown in Fig. la. The system shown in Fig. lb is a Java-coded system that uses Web-based distributed computing as its platform. A database 19, operating under control of database SQL server 18, is used to store information concerning the business transaction (e.g., auction), its users, bids, etc. A Java application server 17 is provided as the main communication center. Application server 17 is coupled to SQL server 18 (directly or indirectly through Internet 16) to process all connections and requests from users (e.g., bidders, transaction owners, etc.) through client devices 15.

In this implementation, Java application server 17 houses the processing device(s) and programmed algorithm used to operate the business transaction (e.g., auction). Client devices 15, in this implementation, are Java-enabled client devices gaining access to the Java application server 17 over Internet 16 using Java Remote Method Invocation (RMI) technology. The business transaction systems described above and illustrated in Figs, la and lb may be used to effectuate the business transactions and business methods described in (and apparent from) the specific embodiments, implementations, and illustrations provided below.

Initially, the business transaction owner defines the metes and bounds of the business transaction. The owner may, for example, describe the subject or item of the transaction (e.g., good, product, service, etc.), the time period for conducting the transaction, etc.. The transaction owner may specify whether the transaction is to be "closed" or "open." For a "closed" transaction, the transaction owner may provide a fist of qualified bidders. As will be described below, the transaction owner may assign bid premiums (or discounts) to each of the bidders. For an "open" transaction, the transaction is generally open to any bidder having access to the system. For that reason, the transaction owner may define a set of bidder attributes that must be met before a bidder is qualified to bid on the transaction. In a preferred embodiment, the transaction owner may assign weight to the different attributes and rank bidders (e.g., using a simple weighted average scale) according to the attributes met. Bid premiums (or discounts) could similarly be assigned to different bidders based on ranking.

In defining the transaction, the transaction owner may also define a set of issues to be resolved in the transaction (sometimes referred to herein as "Negotiable

Bid Issues (NBIs)"). NBI issues such as price, quantity, quality, delivery, warranty, payment terms, or any known parameter impacting the parties in the transaction may be explicitly resolved (e.g., auctioned, negotiated, etc.), or implicitly resolved through the use of offer or bid premiums, discounts, etc. NBI discounts, for example, on bid prices may be awarded to individual bids (or bidders) based on the extent (or level) to which NBI issues are met (e.g., different delivery dates may be awarded different NBI discounts). The transaction owner may also define criteria for the transaction that effectively place limits on the bidding and resolution of the transaction. For example, constraints may be placed generally on elements of the issues, NBIs or levels of NBIs, attributes of the bidders, quantity limits (e.g., maximum of 50% from risky suppliers, or 5,000 units for new suppliers), etc. Constraints may also specify that the transaction must be such that revenue must increase at every iteration, or that ties in bids are broken by making the most recent bidder inactive, etc. The transaction owner may also set reservation prices, beginning bids, quantity discounts, and other parameters of the bidding or overall transaction process. The definitions of the transaction as input by the transaction owner are then stored in the system for reference (e.g., by calculation device 106 (Fig. la)) during the processing of the transaction.

A buyer, seller, or other entity desiring to provide a competitive offer (e.g., a bid) in a business transaction (e.g., an auction), in accordance with a preferred embodiment of the invention, to an owner of the business transaction typically steps through the process depicted in Fig. 2. For example, after first "qualifying" to bid by meeting the transaction owners minimum requirements (e.g., regarding bidder attributes, etc.), a bidder desiring to enter into a business transaction with a transaction owner enters the process (at step 20). In accordance with a preferred embodiment of the invention, the bidder requests a recommended or suggested bid (at step 22). By requesting a suggested bid, the bidder need not determine for itself what form (e.g., price, quantity, quality, terms, etc.) the bid must take to gain a high probability of obtaining a winning position in the business transaction. In a preferred embodiment, many of the elements or issues constituting the bid (e.g., quantity, delivery, other NBI levels, etc.) are selected by the bidder for which any remaining bid issues (e.g., price) are then calculated taking into account the bidder selected issues, constraints, and other transaction definition criteria.

In accordance with a preferred embodiment, the suggested bid will be calculated (e.g., by bid calculation device 106 (Fig. la)) and received by the bidder (at step 24). Preferably, the suggested bid is calculated such that the bidder would be placed in an "active" position in the business transaction if the suggested bid were adopted or accepted by the bidder. In accordance with a preferred embodiment, a bidder with an "active" status or position at the time of closing of the business transaction would be deemed the winner (or at least in a group of winners) of the business transaction. Conversely, a bidder in an "inactive" position at the time of closing would not win (or be among the winners) of the business transaction. In certain cases, a designation of "semi-active" status or position would be designated as such where parts of its bid (e.g., a partial quantity in a multiple quantity auction transaction) were considered "active" for purposes of determining winners of the business transaction, and the remaining parts of the bid were considered "inactive." In a preferred embodiment, the suggested bid is calculated (e.g., using calculation device 106 (Fig. la)) based on all of the criteria initially input by the transaction owner in defining the transaction (e.g., bid premiums/discounts, constraints, quantity discounts, bidder attributes, NBI discounts, reservation prices, etc.), as well as on factors such as previous bids. For example, in an auction transaction where price per quantity is the primary bid issue, in accordance with a preferred embodiment, the suggested bid price would be calculated assigning price premiums (or discounts) based on the extent to which the bidder met (e.g., as determined by criteria detector 108 (Fig. la)) the different auction definitions (e.g., delivery terms, warranty length, etc.).

Having received the suggested bid, the bidder is in a position to accept or reject the bid (at step 26). If electing to accept the suggested bid (or enhancing the bid further), the bid is output (at step- 28) to the transaction owner. If the bid is not accepted, no bid is output by the bidder. In either case, the process returns (at step 29) to other processing in the business transaction. Bidders may enter or re-enter (at step 20) for additional bids at any time while the business transaction remains open for bids.

In accordance with a preferred embodiment of the invention, bids are accepted sequentially, and when a bidder is outbid by another, the bidder is informed and invited to re-enter the process to post another bid. In this preferred embodiment, the bidders will not see each others bids. The process is simplified in that the bidders do not have to decide the constitution of their next bid (e.g., what amount to bid to make their bid "active"), relying instead on a bid being

recommended or suggested (e.g., from bid calculation device 106 (Fig. la), or at

step 24 (Fig. 2)). Additional features can be added to further simplify the process

such as the "autobid" feature that allows a bidder who is outbid to automatically

accept the latest suggested bid (until a specified bid Umit is reached). The process is

somewhat advantageous for the transaction owner as well because the bidder does

not know if it is outbidding previous bidders or meeting a reservation bid

composition (e.g., reservation price for a given quantity).

Fig. 3 is provided as an illustration of one exemplary implementation of a

preferred embodiment of the invention. In this illustration, the business transaction

is an auction intended to maximize revenue with each successive bid, and a bid is

composed of two issues (i.e., quantity of units, and price per unit). The following

notation will be used in describing this illustration:

S,: (p„ q,), be the ith bid, where p, = per unit price for bid i, and q,

= quantity desired in bid i, (i = 1, . . ., ) n: number of existing bids, and index associated with highest bid price n + 1 = entering bid

D: number of units of good for sale SP: Suggested Price to make a bid active

-RP: Reservation Price q„: quantity for the semi-active bid ε: minimum increment in bid price /: index associated with lowest active bid price; if tied, it is associated with the latest entered bid

/- 1: index associated with semi-active bid price if one exists

A: set of active bids (possibly empty), corresponding to indexes i = 1, . . ., n when bids are ordered from lowest to highest

A/k: the set of active bids reduced by k lowest priced active bids

SA: set of one semi-active bid (possibly empty), corresponding to i l- l

I set of inactive bids (possibly empty), corresponding to i = 1, . . ., /- 2 (or 1, . . ., /- 1 if SA empty)

The operation of the auction transaction is initiated (at step 30), and the

Auction owner specifies D, RP, ε, and the closing time of the auction (at step 31).

One of the potential bidders (32a, 32b, 32c, . . . 32n) presents a bid query * = n + 1

by specifying a desired quantity q_t. That bidder requests (at step 33) calculation of a

recommended or suggested bid (i.e., rice for #,), and the price is calculated (e.g.,

using bid calculation device 106 (Fig. la)), as follows:

iCase 1 : Suggested Price is the Reservation Price. SP

Case 2: Suggested Price is calculated, a) SP = >,_ , + ε i^f ?»+ι + ∑;e_A 9> ^■ « D; if not, b) SP = p, + ε if 9-+i + ∑i _Λ/i q, ^• « D if not, c) SP = p,_{+ l} + ε if ?»+ι + ∑,_{ie Λ/} <Ii « or gencricaliy, d) SP = p_{t+ t}-ι + ε if tf»+i + ∑_{ie Λ/ i}qi « D, where k = 0, 1, 2, etc. until the above condition is met. ^; - In case 1 , the suggested bid price is simply calculated as the reservation

price because all bids do not exceed the supply. In case 2, however, the suggested

price is calculated as an ε amount above the last not active (in- or semi-active) bid

price (2a) or an ε above the lowest active bid price (2b), or an ε above the second

lowest active bid price (2c), etc. (2d), until the demand does not exceed the supply of the good.

After the bid calculation (at step 33), the bidder submits (at step 34) its

bid S, = (SP, q_t) or (p_h q_t) where pi ≥ SP; update n = n + 1 (assuming it accepts the

suggested bid); or the bidder drops out (at step 37) of the auction (assuming the

bidder rejects the suggested bid). If, as a result of the submitted bid, the status of the bidder (and any other bidders) change, the bidders are notified of the status

change (at step 35). Bidders whose status changes, for example, from A to SA or I,

of from SA to J, or whose q„ changes are informed and requested to make a decision.

The bids are then reorder from low to high (at step 36). The process is then repeated until auction closes (at step 38).

The revenue, which is intended to increase at every iteration, can be

calculated as follows:

TotaJ revenue = P_{q, + _qtr p_lt it A where s refers to the semi-active bid. The residual quantity for the semi- active bid s is: ^{D ~} z ^,{fzZ 1' + 1, > D, otherwise_?,, = 0.

As an example, assume a seller has 100 units of a homogeneous good to auction, with a reservation price of $10 per unit, and bid increment (ε) is $1. At time 1, Bidder 1 enters the auction, specifies a quantity of 40 and requests a price from the auction mechanism. Since there are no other bids, the reservation price is suggested to the bidder (case 1). He/she makes his/her bid (10, 40) and it becomes active in status. At time 2, Bidder 2 enters, specifies a quantity of 30 and requests a price. Again the reservation price of $10 is suggested (case 1), because the supply has not yet been depleted. Bidder 2 makes his/her bid (10, 30) and it becomes active in status. At time 3, bidder 3 enters the auction, and specifies a quantity of 50. At this point the supply is depleted and a new price must be calculated. The auction mechanism calculates a price at the bid increment ($1) above the latest price, and a price of $11 is suggested to the bidder (case 2, rule b). He/she then makes his/her bid (11, 50). Bidder two then is outbid and thus becomes semi-active with a quantity of 10 units, because he/she was the last one to bid at the price of $10.

Bidder one remains active. At time 4, bidder two has three options. He/she can withdraw from the auction completely, stay semi-active in status, or re-bid. Assume he/she decides to re-bid at the same quantity of 30 units, and requests a price. The price $11 is suggested by the mechanism because at that price the quantities of bidders 2 and 3 would be met by the supply (case 2, rule b). Bidder 2 then makes his/her bid (11, 30). Bidder 3 remains active in status and bidder 1 becomes semi- active with a quantity of 20 units. At time 5, bidder 1 has, again, three options, i.e. withdraw, remain semi-active or re-bid. Assume he/she decides to re-bid and requests a price. The mechanism then returns a price of $12 because at $11 the demand is greater than the supply. Therefore the new price must be calculated $1 above the most recent price suggested ($11) (case 2, rule b). If he/she makes this bid (12, 40), he/she will become active in status, bidder 3 will remain active, and bidder 2 will become semi-active with a quantity of 10. The process repeats until the auction closes. The sequence of bids in this example are provided below in Table 1.

Table 1. Sequence of Bids

time bidder/bid # q p status of bid/in time

1 1/1 40 ^" 10 A\l SA\4 1\5

2 2/1 30 10 A\2 SA\3 1\4

3 3/1 50 11 A\3

4 2/2 30 11 A\4 SA\5

5 1/2 40 12 A\5

In accordance with a preferred embodiment of the invention, the reservation price levels can play varied roles in the process. For example, where the auction owner has 100 units of good available, he/she specifies reservation levels as follows: RP(for bids between 1-30 units) = $10; RP(31-40) = 9.50; RP(41 and above) = 9.25. These reservation levels then function as a quantity discount provided to individual large quantity bidders. Bidder 1 specifies a quantity of 40, and the suggested price is 9.5, the reservation level for that quantity. Bidder 2 specifies a quantity of 30 and the suggested price is at the reservation level of 10. Bidder 3 specifies a quantity of 50, but because he/she must outbid bidder 1, the suggested price is 10. The algorithm mechanism then performs the same as above for the bids that follow since they now are above the reservation prices, as reflected in Table 2 below.

Table 2. Use of Many Reservation Prices

time bidder/bid # status/in time

1/1 40 9.5 A\l S\3 1\4

2/1 30 10 A\2 S\5

3/1 50 10 A\3 S\4 1\5

1/2 40 11 A\4 SA\5

3/2 50 11 A\5 In accordance with a preferred embodiment of the invention, the operation illustrated in Fig. 2 can be further enhanced by adding a plurality of additional operational modes, as illustrated in Fig. 4. In the embodiment, the operational modes can be controlled (e.g., with mode controller 104 (Fig. la)) by the transaction owner to facilitate a resolution of the transaction. In the embodiment illustrated in Fig. 4, three operational modes are depicted: automatic, manual, and pause. In operation, a bidder enters (or re-enters) the bidding process (at step 40) of the business transaction and requests a bid (at step 42), in a manner similar to the process described above with respect to Fig. 2. Depending on the mode selected by the transaction owner (e.g., using mode controller 104 (Fig. la)), the process enters into one of the plurality of modes (at step 43).

In the automatic mode, the process of calculating a recommended or suggested bid (at step 44) is the same as in the process of Fig. 2. The bidder then has an opportunity to accept or reject the bid (at step 46), output the bid (at step 48) to the transaction owner, and return (at step 49) to the remaining processing of the business transaction. In the pause mode, however, the bidder is essentially suspended from receiving a suggested bid (and from making any bids at all). The pause mode may remain in effect for a predetermined period (e.g., given time period, given number of bid cycles, etc.), or indefinitely until the transaction owner moves the operational mode to another mode.

In the manual mode, the transaction owner itself (or another entity) manually interacts with the bidder directly (at step 45). In accordance with a preferred embodiment, the transaction owner utilizes instant messaging systems, chat (text/video/audio) services, or other (real-time/non-real-time) communication devices to relay information to the bidder concerning a suggested bid that would be acceptable to the transaction owner. Once the information is conveyed to the bidder, the bidder has the option of accepting the bid (at step 46) and outputting the bid (at step 48), as in the automatic mode. In either event, the bidder is returned (at step 49) to the remaining business transaction processing.

In accordance with a preferred embodiment, in the manual mode, the information conveyed to the bidder from the transaction owner may involve a series of exchanges of information, offers, counteroffers, etc. that allows the transaction owner to effectively negotiate the terms with the bidder directly (in real-time, if preferred) during the processing of the transaction (e.g., auction). The transaction owner is also provided with the ability to "lock-in" a manual mode bid. The "lock- in" election commits the transaction owner to the bidder prior to the end of the transaction resolution period (e.g., before an auction ends). Thus, if a certain quantity is "locked-in," the locked-in bidder is the winner (i.e., cannot be outbid) for the specified quantity. The total quantity available for bidding by others is thus reduced. If the transaction owner elects not to "lock-in" the bid (i.e., effectively putting it in a normal or "un-locked" state), the bid (if accepted at step 46 by the bidder) will be compared to other bids forthcoming in the auction, and can be outbid in the manner described above. The recommended or suggested bid calculation performed (e.g., using bid calculation device 106 (Fig. la), at step 24 (Fig. 2), at step 44 (Fig. 4), etc.) during the processing of the business transaction is performed in a manner that maximizes the benefit (e.g., increased revenue, decreased cost, etc.) received by the transaction owner in accepting another "active" bidder.

In accordance with a preferred embodiment, the process may be optimized by formulating and solving the following:

1. Determining which bids are active, inactive, and semi-active.

2. Calculating recommended price for a new bid.

Let Q_, be the total quantity demanded in the auction. Assume Nbids.

Each bid is represented by a pair (p, q) - - price per unit, quantity supplied in a reverse auction.

Determination of Bid Status

It is desired to find

* = (*_/, • • • , *„), *,^■ ε [0, 1]

describing which bids are active (^*, ^{_ 1}), inactive (^{* "}°)_> ^or semi-active (^{O !},-^<1) in the auction.

Hence, total cost for AO for procuring Q units of the good can be calculated as follows: R = <x, pq>, where (pq)_s = pfl,

In a reverse auction, for example, total cost is minimized under condition

<x, q> ≥ β (*)

M additional criteria for each bid will also hold:

~M

These criteria, q and x can be used to define L additional constraints. Constraints that only concern a particular bidder or each bidder in some particular group can be checked at the time the bid is entered and need not be considered in the calculation. Only such constraints are considered which restrict the number of bids, the quantity or other criterion values for a group of bids.

For example, if a criterion is present which describes whether a supplier is trustworthy or not: ^c~ - ^l

a supplier i is trustworthy, and c-^l i ≡ 0 , if a supplier is not trustworthy. Consequently, a condition such as "not less than 3 trustworthy suppUers should be active" may be represented as:

<x, c¹ >> 3

On the other hand, a constraint stating that "quantity suppUed by trustworthy suppUers should be greater than 50% of the total requested quantity" can be represented as: < x, c¹ q>≥0.5Q

Generally, each constraint can be represented in the foUowing format

< x, a >≥ A

To determine which bids are active or not, the foUowing linear optimization problem is solved:

< x, pq > → m in

<x,q>≥Q

<x,a^l>≥A^l (1)

< x, a^L >≥ A^L

with the additional condition

0≤x_{≤l,i=l..N (2)

If bidders do not accept partial quantities, a linear integer optimization problem is presented, where

To solve this optimization problem, the simplex method is used in the continuous case, and the Lend-Doyg method in the integer variable case. If there is no optimal solution, the nearest solution provided by the optimization method is checked. Two different cases are distinguished:

1. Only the quantity constraint is not satisfied < x, q >< Q. This means that there are not enough bids in the auction yet. The AO is informed that the current quantity suppUed is less than the requested quantity.

2. Some other constraints are not satisfied. This means that the constraints are too tight or maybe there are not enough bids to satisfy them. In this case all bids are inactive. The AO is informed.

Calculating Kecommended rice

Assume that the new bidder N+l requests the price for quantity ^ϊN+1 to make him/her active in the auction. Two cases arise:

1. < x, q > + q_N+l ≤ Q

In this case the recommended price is the auction reservation price set by the AO.

2. < x, q > + #_N+1 > Q

In this case, a sUghtly changed LP- problem is solved. It is required that each new bid decreases total cost. Denote the current total cost by R. The following problem is solved:

< X ,a^L >> A¹ -a«₊ι 1

This is equivalent to the linear optimization problem:

p_w+1 <— (*-<*^» "?>)-> ^max

< χ,a^l >≥ A¹ -a_N ^l _+i

< x >≥ A^l 'W+l or

< x,pq >→ min

< χ,a >> A¹ -a_N ^l _+i

< χ,a >≥ A¹ -a_N ^L _+l

To aU these systems of equations, condition (2) or (2') should be added.

With x- solution of (4) - the recommended price can be calculated as: PN_*I = {R- < x, pq >) - δ, δ > Q (5)

where δ is a minimum price change. ^⁺¹ can be zero or even negative implying that this bid cannot participate in the auction. Sometimes, especiaUy in the integer case, this formula can give very low price values. In this case an alternative formula can be used. Again, let Λ; denote the solution of (4). Then

The advantage of this formula is that it can be calculated in any case.

Bid Premiums/Discounts

In accordance with a preferred embodiment of the invention, the business transaction owner (e.g., auction owner (AO)) can specify for a particular bidder, a score across bidder attributes, resulting in a ranked Ust of bidders. Based on this ranked Ust, for each bidder, the transaction owner has the option of inserting a "bid premium," which allows price discrimination across bidders. For example, in a business transaction in the form of an auction, let b = (b_λ, . . . , b_N) be the vector of bid premiums (bid discounts, if b is negative). Assume two bids with equal prices p_± = p_j = p and the foUowing (unequal) bid premiums &, = 0 and b_j = 1. This means that the second bid is less preferable. Thus the auction calculation transforms to:

< x, (p + b) q > — > min

< x, q > ≥ Q

< x, af > ≥ A^L

To become active the recommended or suggested bid for the new bidder

(assigned a bid premium) wiU calculate a suggested bid that is less than (in a reverse auction) a the calculation for a bidder without such a premium. Therefore, the recommended price calculation transforms to:

< x, (p+b) q >— min

< x, q >≥ Q- q_N+1 (4')

< x,a^x >≥ A^l a.

< x,a^L >> A^l - a_N ^L _+l (5')

/>_*♦. = (^R~ < *λp + b)q >)-b_Htl - δ,δ > 0

or

(6')

For example, if an auction owner wants to receive bids that include the

issue deUvery, then the auction owner can indicate that he wiU not give any discount

if deUvery is made in 60 days, but wiU give a $5 discount if it arrives within 30 days

and a $10 discount if it arrives within 15 days. If it is a reverse auction, bid

premiums raise the price, if it is a forward auction, the discounts decrease the price by

that amount. The calculation of recommended or suggested bids (e.g., using bid

calculation device 106 (Fig. la)) wiU thus consider the bidders indication of deUvery

terms in calculating the appropriate suggested bid for each bidder.

Business transaction owners also have the option of requesting bids across

multiple issues (i.e., NBIs). Associated with the levels within these NBIs, the

business transaction owner can attach "NBI discounts" to which the owner is

indifferent. The bidder then selects which NBI level and associated discount

according to its own preferences. EXAMPLE 1

To further Ulustrate preferred embodiments of the invention, a commercial implementation of a preferred embodiment in computer software form (referred to as " NegotiAuction" ) is described below and iUustrated in Fig. 5-17.

The Nef otiAuction™ software depicted allows corporate and government buyers to b ld multiple issues into the bidding process such as a suppUers' defect history, warranty, brand value, deUvery time, quality level, etc. Buyers wiU also rate suppUers on any number of attributes such as ISO 9000, minority ownership, etc. Based upon the "non-price" criteria, called "Bidder Attributes (BAs)," buyers require some bidders to beat other bidders by an inflated level by applying "bid premiums" based upon ratings across BAs, and rankings of the bidders. Buyers are able to push the whole set of bidders to lower prices in real-time via open price competition. In Manual Mode, buyers can "NEGOTIATE WITH" individual bidders.

While the software is designed to help buyers end up with a diverse set of suppUers and receive the lowest price at the shortest time expenditure, Nej otiAuction also provides benefits to suppUers. SuppUers are constantly informed of the amount that they must bid to be "active" in the auction. This eliminates the guessing game that suppUers must often play when bidding on RFQ's. If a suppUer is active at the close of the auction, he wiU not be pushed further in price, deUvery terms, or any other issues. Since the procurement event takes place in real time, there wiU be no waiting period for suppUers to learn whether they have won the bid. And, suppUers wiU reduce their sales and marketing costs and the sales cycle since the NegotiAuction™ onUne procurement process reduces the need for extensive person- to-person negotiation.

Screen images from a sample operation of the software are depicted in Figs. 5-17, as described below.

Fig. 5 shows the first screen an auction owner would see upon entering the system and specifying <<New Auction>>. The name of the auction is Example, the product descriptions is CD drives subject to standard, previously negotiated contract terms. The product must be deUvered within 30 days. The auction type is reverse, as opposed to forward. The auction is not open to the world, the AO wiU invite aU bidders to the auction.

The AO further defines the auction in Fig. 6. The quantity is specified, as weU as the currency and units of the bid. The bid increment is also Usted under price delta. The AO also indicates the closing time, and that he wiU be using bid premiums and at least one constraint. Also, the reserve price for the beginning bid is input.

In Fig. 7, the AO defines one of the two Bidder Attributes (BAs). This one refers to whether or not the bidder is ISO 9000 certified or not. The second attribute is a subjective rating on quaUty risk. Both BAs are input by the AO, although the system aUows an option for the bidders to input the data. The AO then invites and registers three bidders into the auction. GS, TS, and SS all receive an invitation along with their usernames and passwords and a description of the auction.

The AO inserts the data for the BAs in Fig. 8. Here, the Bidder GS is scored a risk rating of 40, and GS is not ISO 9000. In addition, a Umiting constraint on quantity is indicated in this screen. GS may not supply more than 100000 units.

The ranking screen is shown in Fig. 9. The AO provides weights on the BAs, then selects sort by rank. The system uses a simple weighted average to calculate a score which is then ranked. Once the ranks are in, the job of assigning Bid Premiums to the bidders is easier. Notice the top ranked bidder, TS has a 0 premium, and GS, the bottom ranked bidder has a premium of 1. This means that aU things being equal, GS must beat TS by $1 in a bid.

Once aU the information regarding constraints, bid premiums, BAs are all defined and inserted, the auction is ready to begin and the bidders are moved from pause mode to Automatic mode in Fig. 10.

The AO's min screen is shown in Fig. 11, the bidders are aU Usted in the center, the NegotiAuction open at this time is in the upper left, and no bids have arrived yet in the positions window. The NegotiAuction has begun.

Bidders TS enters the auction, selects <<New Bid>>, the bid screen pops. She enters a Quantity of 200,000. Since this is the first bid, the reserve price of $80 is returned. She agrees, hits yes, and her bid is shown active in her mainscreen in Fig. 12.

Bidder GS enters the auction, inserts a bid quantity of 120000 units, but since GS is constrained to 100,000 units, she receives the message in Fig. 13. She hits YES, and receives a price of $78.5 generated by the system. This price is the difference of the bid increment ($.50) combined with her $1 bid premium off the $80 price of TS. This bid makes TS semi-active.

The auction owner's screen is updated to show the current position in Fig. 14. Notice bidder TS is semi-active with 100,000 units in parentheses. At this point the AO beUeves he can push bidder TS a Uttle more by going into manual mode. He places TS in manual mode. When TS notices she has gone semi-active and wiU probably be outbid when the next bid arrives, she revises her bid. Fig. 15 shows her screen with the message window attached. She enters a lower bid ($79) and goes back to the original quantity of 200,000. She also includes a message.

The manual mode bid arrives in RED and AO's screen in Fig. 16 shows the status «U» for Under consideration. The AO repUes with a price push of $78. The counter-offer then goes RED in TS's screen. She opens the bid window, reads the message, then agrees to the $78.

The AO's main screen in Fig. 17 shows that TS is now active at $78 and GS has gone inactive at 78.5. The auction continues on until the close. EXAMPLE 2

Three flow charts (represented by Figs. 18a-18e, 19a, 19b, and Figs. 20a- 20c) and the corresponding description (appearing in the Appendix) of the operational flow depicted are provided as another exemplary commercial implementation of a preferred embodiment of the invention.

EXAMPLE 3

To further illustrate preferred embodiments of the invention, another commercial implementation of a preferred embodiment in computer software form is described below and iUustrated in Fig. 21-45.

The auction owner, upon entering the system, first defines the auction. In this example, the Government (AO) is purchasing non-defective chemical weapons protection suits. In Fig. 21, the Government describes the product and specifies that the auction type is reverse, as opposed to forward. The auction is open to the world however the government first qualifies bidders before aUowing them to bid.

In Fig. 22, the AO further defines the quantity demanded, as weU as the currency and units of the bid. The bid increment is also Usted under price delta. The AO also indicates the closing time, and that he wiU be using bid premiums and at least one constraint. In Fig. 23, the reserve price for the beginning bid (assuming no Bid Premiums and no NBI discounts) is input. In Figs. 24 and 25, the AO defines the two Bidder Attributes (BAs). The first BA refers to whether the bidder is ISO 9000 certified or not. The other attribute is a subjective rating on quaUty risk.. With this example, the data for both BAs are input by the AO, although the system aUows an option for the bidders to input the data, which could be the case if the set of bidders is large and the data is objective rather than subjective ratings.

In Figs. 26 and 28, the AO defines the two Negotiable Bid Issues (NBI), warranty years and deUvery in days. In Figs. 27 and 29, the AO defines the discount levels appUed to the levels in the NBI, warranty and deUvery respectively. These NBI discounts aUow the bidders to receive a better (higher) price when preferred levels of the NBI are placed in a bid. They are automaticaUy calculated into a requested price when the bidder selects the request price button after entering an NBI level. We assume the auction owner is indifferent between NBI level/discount combinations, so for example, in NBI warranty, the AO is indifferent to a warranty level of 2 years with a discount of $0, to a warranty level of 3 years with a discount of $3 per unit, and so on. In Fig. 30, aU attributes of the auction, bidder attribute and NBIs are summarized for the auction owner.

Next, in Figs. 31, 32, and 33, the AO defines a constraint on the NBI deUvery, where the deUvery must be in 90 days or less. Fig. 34 summarizes three constraints for the AO, one for each of the NBIs, and one "group" constraint on the bidder attribute ISO 9000. The group of bidders, together, without certification may not be assigned more than 450,000 suits. Later on, the AO wiU also specify constraints Umiting each individual bidder to a maximum of 400,000 units. The simplex method is underlying in the NegotiAuction algorithm to calculate an optimal solution, minimizing (maximizing) revenue, subject to the constraint set.

In this example, the AO invites and registers three bidders into the auction: GS, TS, and SS. They all receive an invitation along with their usernames and passwords and a description of the auction. The AO rates each bidder on the BA quaUty risk, and they specify whether the bidders are ISO 9000 certified or not. In Fig. 35, the AO switches the bidders from Pause mode (the default), to Automatic mode.

In Fig. 36, The AO provides weights on the BAs, then selects 'sort by rank' . The system uses a simple weighted average to calculate a score, which is then ranked. Once the ranks are in, the job of assigning Bid Premiums to the bidders is easier. In our example, the top ranked bidder (GS) is assigned $0 premium, SS is assigned a $12 bid premium, and the bottom ranked bidder (TS) is assigned a premium of 20. This means that aU things being equal, TS must beat GS by $20

(plus perhaps the bid increment) in a bid to become active in the auction.

Once all the information regarding constraints, bid premiums, and BAs are defined and inserted and the bidders moved from pause mode to Automatic mode, the NegotiAuction is set to begin. The participants summary information is suppUed to the AO in Fig. 37. In Fig. 38, bidder GS enters the auction, selects 'New Bid¹, the bid screen pops. She enters an infeasible quantity of 500,000. The quantity is automaticaUy revised downward to a feasible quantity of 400,000 and since this is the first bid, the reserve price of $500 is returned. Recall bidder GS has a 0 bid premium, and the NBI levels selected by GS offer no discounts off the requested price. GS agrees to the requested price and hits yes; her bid is then shown active in her main screen. AU bidders have access to the NBI discount level information provided in Fig. 39, they select the level which provides the highest utiUty for the price/NBI level combination.

Bidder SS enters the auction in Fig. 40, inserts a bid quantity of 400,000 units, a warranty of 4 years and delivery of 60 days. Her total for both NBI discounts is $6. Because the quantity of 400,000 together with GS's quantity of 400,000 surpasses the total quantity requested of 700,000; the bid increment is appUed. Her requested price is calculated by the foUowing formula: Requested Price = "Working price" of bid to beat (GS in this case) + total NBI discounts - Bid premium - Bid

Increment = 500 + 6 - 12 - 1 = 493. SS agrees to this requested price and becomes active in the auction. GS becomes semi-active with a quantity of 300,000 units.

The "working price" of a bid is defined as: working price = Requested Price - Total NBI discounts + Bid Premium making the working price of the GS bid = 500 - 0 + 0 = 500 and the working price for the SS bid = 493 - 6 + 12 = 499.

The calculation of the working price makes possible an "apples to apples" comparison possible between bids from bidders with different bid premiums and different NBI levels.

In Fig. 41, bidder TS enters a quantity of 400,000 with warranty of 2 years and deUvery of 90 days (therefore total NBI discount = 0). Because both bidder TS and SS are not ISO 9000 certified, the group constraint defined earUer which restricts this group to have less than 450,000 units appUes. For TS to become active with this bid, both SS and GS must be reduced from their current quantities. Since SS has a more aggressive working price than GS, (499 vs. 500), the working price of 499 is used in the calculation of the requested price for TS and the bid increment appUes. The requested price for TS= 499 + 0 - 20 -1 = 478. Assume TS agrees, making TS active with a quantity of 400,000; SS semi-active with a quantity of 50,000 units; and GS semi-active with 250,000 units. This bid stream is displayed for the auction owner in Fig. 42.

Assume bidder SS is placed into manual mode at this point by the AO. Bidder SS enters a manual mode bid in Fig. 43 with a request to "Lock-in" this bid.

Lock-in simply means that the AO agrees to the bid, and commits that quantity with the terms of the bid prior to the official close of the auction (thus the quantity avaUable in the auction is reduced by the amount of the locked-in bid). In Fig. 44 the AO makes a counter offer to bidder SS. SS responds to the counteroffer in Fig. 45 and restates her request to lock-in the bid. Her bid then becomes active and the

AO decides whether or not to lock-in. The NegotiAuction continues in a simUar manner until the close. While preferred embodiments of the invention have been described and iUustrated, it should be apparent that many modifications to the embodiments and implementations of the invention can be made without departing from the spirit or scope of the invention. For example, while a business-to-business-type auction transaction has been specificaUy iUustrated, the invention may easUy be deployed in consumer- to -business, or consumer-to-consumer (forward or reverse) auction, negotiation, negotiauction, market, and RFQ transactions. While the iUustrated embodiments have implemented the invention utilizing Internet communications, it should be readily apparent that other communication systems or (wired/wireless) networks (e.g., intranets, private buUetin boards, individual local or wide area networks, proprietary chat rooms, ICQ, IRC channels, instant messaging systems, etc.) using real-time or non-real-time systems in Ueu of or in addition to the disclosed Internet resources may also be utiUzed. The auction transactions contemplated herein may be processed sequentiaUy or in paraUel by one or more processing devices.

Additional modules may be added to interact with the auction processing system.

Although only three operational modes (i.e., automatic, manual, pause) were iUustrated in the description of preferred embodiments given above, it should readily apparent that one or more additional operational modes added (or one or more removed) without departing from the scope of the invention. The operational modes when implemented described may contain more or less functionaUty than described herein. In accordance with a preferred embodiment, one or more user interfaces (e.g., transaction owner interface 12, bidder interfaces 13a-13c, and cUent devices 15 in Figs, la and lb) are provided as part of (or in conjunction with) the illustrated systems to permit users to interact with the systems. Individual ones of a plurality of devices (e.g., network/stand-alone computers, personal digital assistants (PDAs),

WebTV (or other Internet-only) terminals, set-top boxes, cellular/PCS phones, screenphones, pagers, kiosks, or other known (wired or wireless) communication devices, etc.) may similarly be used to execute one or more computer programs (e.g., universal Internet browser programs, dedicated interface programs, etc.) to aUow users to interface with the systems in the manner described.

The modules described herein, particularly those iUustrated or inherent in the instant disclosure (including Appendix), may be one or more hardware, software, or hybrid components residing in (or distributed among) one or more local or remote computer systems. Although the modules are shown or described as physically separated components, it should be readily apparent that the modules may be combined or further separated into a variety of different components, sharing different resources (including processing units, memory, clock devices, software routines, etc.) as required for the particular implementation of the embodiments disclosed herein. Indeed, even a single general purpose computer executing a computer program stored on an article of manufacture (e.g., recording medium) to produce the functionaUty and any other memory devices referred to herein may be utiUzed to implement the illustrated embodiments. User interface devices may be any device used to input and/or output information. The user interface device may be implemented as a graphical user interface (GUI) containing a display or the like, or may be a link to other user input/output devices known in the art. Discrete functionaUty of the system may be separated (logically or physicaUy) to more efficiently operate the system.

In addition, memory units described herein may be any one or more of the known storage devices (e.g., Random Access Memory (RAM), Read Only Memory (ROM), hard disk drive (HDD), floppy drive, zip drive, compact disk- ROM, DVD, bubble memory, redundant array of independent disks (RAID), etc.), and may also be one or more memory devices embedded within a CPU, or shared with one or more of the other components. The computer programs or algorithms described herein may easUy be configured as one or more hardware modules, and the hardware modules shown may easUy be configured as one or more software modules without departing from the invention. Accordingly, the invention is not limited by the foregoing description or drawings.

What is claimed as new and desired to be protected by Letters Patent of the United States is as foUows: APPENDIX

Auction owner enters

1.1 Are they registered yet?

1.1.1 If no, AO registers and is logged in

1.1.2 If yes, al logs in

1.2 AO specifies "new Auction" from menu

1.2.1 Does a Previously save auction file exist?

1.2.1.1 if yes, retrieve the file and go to edit auction step 1.5

1.2.1.2 If No, system generates auction definition form

1.3 Auction definition form

1.3.1 AO defines auction, product description, hard requirements (rfq) and whether or not auction is open to the world of bidders or closed to a defined set

1.3.2 AO fills next form that includes

1.3.2.1 Forward or reverse auction

1.3.2.2 Closing date and time

1.3.2.3 Lot size requirements (e.g. PaUets with a specified number of units)

1.3.2.4 Currency and units of bids, e.g., doUars per unit, or batch

1.3.2.5 Units of product, tons, gaUons etc.

1.3.2.6 Reserve prices where bidding starts, with an option for varying quantities and prices

1.3.2.7 Bidder Attributes (BA) exist or not, e.g., ISO 9000, or risk levels

1.3.2.8 Negotiable Bid Issues (NBI) beyond price and quantity exist or not e.g., DeUvery time, warranty time,

1.3.2.9 Total quantity required

1.3.2.10 Whether constraints exist, e.g., Limits for bidders, Umits for groups of bidders, minimum levels of nbi, if thens

1.3.2.11 Whether AO wiU specify none, some, or aU bidders (if auction is closed to the world, aU is the default)

1.3.3 Attributes to be used?

1.3.3.1 If yes, AO defines attributes

1.3.3.1.1 Name

1.3.3.1.2 Type of attribute, whether bidder or AO inputs the attribute data

1.3.3.1.3 Type of Units within attribute

1.3.3.1.3.1 Yes/no

1.3.3.1.3.2 0-100 scored

1.3.3.1.3.3 other numerical

1.3.4 Negotiable Bid issues to be used in auction?

1.3.4.1 If yes, AO defines NBIs

1.3.4.1.1 Name

1.3.4.1.2 # of levels within NBI and definition of levels 1.3.4.1.2.1 if NBI price bonuses are to be used, AO inputs bonus for each level APPENDIX

1.3.4.1.2.1.1 whether bonuses are reported to bidders

1.3.5 Are constraints used in the auction?

1.3.5.1 If yes , AO defines constraints

1.3.5.1.1.1 Max/min for aU bidders

1.3.5.1.1.2 If/thens concerning any two of the foUowing

1.3.5.1.1.2.1 Bidder attributes

1.3.5.1.1.2.2 NBI

1.3.5.1.1.2.3 Quantity level

1.3.5.1.1.2.4 Bidder attributes

1.3.5.1.1.2.5 NBIs

1.3.5.1.1.2.6 quantity

1.3.5.1.1.3 Group constraints, e.g., group of nonlSO 9000 restricted to a max of 50% total quantity

1.3.6 Does AO define some/aU bidders?

1.3.6.1 If yes, is the bidder new in the system? 1.3.6.1.1 If yes, AO registers new bidder

1.3.6.1.1.1 Userid

1.3.6.1.1.2 Initial password

1.3.6.1.1.3 Email

1.3.6.2 If yes, System sends emaU to bidder with invitation to enter auction, auction description (rfq) and information

1.3.6.3 If yes, Bidder is placed in pause mode

1.3.7 Are there more than two attributes?

1.3.7.1 If yes, AO specifies weights on aU attributes

1.3.7.2 If no attributes, go to 1.3.10

1.3.8 If new bidders (undefined attributes) have registered in the auction, and if AO enters data for at least one attribute, AO inputs the attribute data for bidders

1.3.9 Are there current bidders registered in the auction?

1.3.9.1 If yes, are aU attribute data available for them?

1.3.9.1.1 If no, system waits for bidders to enter BA data before ranking

1.3.9.1.2 If yes, system ranks bidders based on BA and weights, summation of weight* scaled BA.

1.3.10 Are bid premiums being used in the auction?

1.3.10.1 If no, go to 1.4

1.3.10.2 If yes, are there new bidders with unassigned bid premiums?

1.3.10.2.1 If yes, does AO use auto generated bid premiums

1.3.10.2.1.1 If yes, AO inserts range of BP 0-hibp 1.3.10.2.1.1.1 If auto procedure is score based, BPS = (l-score)*hipb for aU bidders APPENDIX

1.3.10.2.1.1.2 If auto procedure is rank based, AO inputs functional form, linear, non-linear concave or convex (with a GUI) BPS are calculated based on rank for each bidder.

1.3.10.2.1.2 If no, AO inputs BPS for aU new bidders

1.4 Bidders default from pause mode to auto mode

1.5 Auction begins

1.5.1 Edit Auction Definitions?

1.5.1.1 If yes, go to appropriate subroutine and return

1.5.1.1.1 Quantity, change , inform bidders

1.5.1.1.2 NBI, change, inform bidders

1.5.1.1.3 Bidder attributes

1.5.1.1.4 Bid Premiums

1.5.1.1.5 Bidder definitions

1.5.2 New bidders from world enter?

1.5.2.1 Go to subroutine for attribute data entry and bid premiums entry and return switch from pause to auto mode

1.5.3 Change mode of bidders ?

1.5.3.1 Auto

1.5.3.2 Pause

1.5.3.3 Manual

1.5.4 Bids stream in from auto mode bidders

1.5.5 AO may use messaging system to send any bidder a note

1.5.6 Bid requests from manual mode bidders arrive?

1.5.6.1 AO either

1.5.6.1.1 Accepts offer, can send message 1.5.6.1.1.1 Lock-in mode option?

1.5.6.1.1.1.1 If yes, quantity reduces by amount in bid, if all, auction closes

1.5.6.1.1.1.2 If no, Unlock mode defaults, bid can be outbid in auction

1.5.6.1.2 Makes counter offer, lower p,q, and/or message with other individuaUzed issue

1.5.6.1.3 Ignores offer

1.6 Auction closes

1.6.1 Save auction definition?

1.6.1.1 If yes, filename.

1.6.2 Results of auction reported and mailed.

Bidder enters

2.1 Bidder registers or logs in, option to change password

2.2 Bidder sees participating in or enters an auction

2.3 Bidder views rfq info and price bonuses for nbi if existing

2.4 AU bidder attribute data available?

2.4.1 If no, bidder inputs attribute data APPENDIX

2.5 Pause mode?

2.6 If yes, option to send message to AO with request for manual or auto mode

2.7 Select 'New Bid"

2.8 Auto mode?

2.8.1 If yes, bidder inserts Quantity they wish to bid on, and NBI levels

2.8.1.1 Bidder hits " request price "

2.8.1.2 System returns price

2.8.1.3 Bidder has option to accept, reject and exit, or change nbi levels and request price again

2.9 If bid is accepted, bid becomes Active

2.10 Manual Mode ?

2.10.1 Bidder inserts Q, NBI levels if existing, P optional

2.10.2 Bidder sends bid to AO, become u status (under consideration)

2.10.3 AO either counters with a waiting (w) status bid, with a p,q, NBI levels and optional message or AO accepts initial and bid becomes active

2.10.4 If AO counters Bidder can

2.10.4.1 Counter, optional message submits status u bid go to 2.10.3

2.10.4.2 Accept, bid becomes active

2.11 More new bids? Go to 2.5

2.12 System notified of semiactive bid (PARTIAL Q)?

2.12.1 If yes, bidder has option to

2.12.1.1 EDIT BID

2.12.1.2 REJECT PARTIAL QUANTITY BID

2.12.1.3 WAIT, IMPLICITLY ACCEPT PARTIAL Q

2.13 System notified of inactive bid

2.13.1.1 Edit bid

2.13.1.2 Or Exit 2.13.1.3

Logic of underlying algorithm

3.1 System receive auction definitions, bidder attributes, bid premiums, price bonus levels aU available

3.2 First QuaUfied Bidder enters.

3.3 Auto mode bid?

3.3.1 Feasible Q, NBI levels? system checks aU constraints (simplex algorithm)

3.3.1.1 If no, system informs bidder of a reduced Q (maximum possible) or NBI and reason, and asks if they wish to continue with that q or NBI level, if no bidder exits

3.3.2 Price with feasible bid?

3.3.2.1 If yes, system checks reserve price and compares to "working price" of bid. Working price = bid price - NBI bid level price bonuses + bid premium

3.3.2.1.1 If working price <= reserve price, bid active

3.3.2.1.2 If working price >= reserve price, system calculates a requested price for bid APPENDIX

3.3.3 No price with feasible bid, bidder "requests price"

3.3.3.1 Request price = reserve price + NBI bid level price bonuses - bid premium

3.3.3.2 Bidder accepts requested price, bid becomes active, or rejects and exit

3.4 Manual Mode bid?

3.4.1.1 Confirms feasible Q, System waits until both parties accept offers

3.4.1.2 When accepts, "lock-in" option?

3.4.1.3 If yes, total quantity is reduced by quantity of this bid, bid is active, if total quantity is now zero, auction closes early

3.4.1.4 If no, "working price" of bid is calculated using formula in 3.3.2.1, bid becomes active if it's working price merits it

3.5 At least one bid is active, another bid is entered

3.5.1 If bidder in manual mode, go to 3.4

3.5.2 Auto mode bid enters

3.5.2.1 If Q of new bid plus total Q of existing bids is < = total quantity avail, go to 3.3.1

3.5.3 Feasible Q, NBI levels? system checks aU constraints (simplex algorithm)

3.5.3.1 If no, system informs bidder of a reduced Q or NBI and reason, and asks if they wish to continue with that q or NBI level, if no bidder exits

3.5.4 Price with feasible bid?

3.5.4.1 If yes, system checks Q with Existing Qs and finds the combination which meets the total quantity. The lowest working price (associated with potentiaUy "beat out" bid" is compare to "working price" of this bid. Working price = bid price - NBI bid level price bonuses + bid premium

3.5.4.1.1 If working price <= working price of potentiaUy beat out bid, new bid is active

3.5.4.1.2 If working price >= working price of potentiaUy beat out bid, system calculates a requested price for bid

3.5.5 No price with feasible bid, bidder "requests price"

3.5.5.1 Request price = working price of potentiaUy beat out bid (see 3.5.4.1) + NBI bid level price bonuses - bid premium - price delta

3.5.5.2 Bidder accepts requested price, bid becomes active, or rejects and exits

Auction closes

Claims

1. A negotiauction system linking buyers and seUers of goods and services together over a network, wherein the buyers and seUers are participants in a negotiauction transaction formed by a combination of an auction and negotiation for desired goods and services utilizing the network to communicate offers for sale, purchase, and exchange of the desired goods and services, the negotiauction system comprising:

at least one bidder interface, coupled to the network, wherein at least one bidder issues bids and receives bid responses through said bidder interface;

a transaction server, coupled to the network, wherein said transaction server executes negotiauction transactions between at least one bidder and at least one transaction owner; and

a transaction owner interface, coupled to said transaction server, wherein at least one transaction owner controls a negotiauction transaction by issuing commands to said transaction server through said transaction interface;

wherein said transaction server comprises:

a central processing unit performing input/output processing of data into and out of said transaction server; a program memory storing a computer program controlling operation of said transaction server;

a criteria detector accessing transaction criteria data stored in a database memory and evaluating submitted bids based on the stored criteria data; and

a bid calculation device, wherein said bid calculation device calculates a minimum bid level that must be accepted by a subsequent bidder based on the stored criteria data and previously submitted bids.

2. The negotiauction system as recited in claim 1, wherein the transaction server further comprises:

a mode controUer, wherein said mode controUer controls operational modes of said transaction server relative to any one of a pluraUty of bidders;

wherein the operational modes controUed by said mode controUer comprise:

an automatic mode, wherein bidders receive recommended bids automatically generated by said bid calculation device;

a manual mode, wherein bidders receive recommended bids manuaUy from the transaction owner, resulting in a negotiation with offers and counteroffers; and a pause mode, wherein bidders are temporarily suspended from receiving recommended bids.

3. The negotiauction system as recited in claim 2, wherein said calculation device calculates a recommended bid in the form of a recommended bid price.

4. The negotiauction system as recited in claim 3, wherein said calculation device calculates a recommended bid price based on input from said criteria detector concerning criteria data, including minimum bid increments, bidder attributes, reservation prices, bid premiums, and negotiable bid issue discounts.

5. The negotiauction system as recited in claim 2, wherein the system faciUtates business-to-business transactions of products over the Internet, and wherein said bidder interface is a cUenfdevice accessing the system using a Web browser.

6. The negotiauction system as recited in claim 3, wherein the transaction server is a Java-appUcation server, and the database is accessed by the Java-appUcation server through an SQL database server.

7. The negotiauction system as recited in claim 6, wherein said auction interface is a Java-enabled cUent rxinning a Web browser, said auction interface being coupled to said transaction server via the network.

8. The negotiauction system as recited in claim 2, wherein said central processing unit provides a communications channel between the transaction owner and a bidder to communicate in real-time with each other while said mode controUer has placed said transaction server in a manual mode.

9. A business method of providing a competitive offer, the business method comprising the steps of:

requesting a recommendation for a competitive offer;

receiving the recommended competitive offer;

determining an outcome with respect to whether to accept, reject, or supplement the competitive offer; and

providing an indication of the outcome of said determining step regarding the recommended competitive offer.

10. The business method of claim 9, wherein the competitive offer is being made as a bid in an auction transaction, wherein the recommended competitive offer is determined based on factors including bid constraints, bid premiums, previous bids, and negotiable bid issue discounts.

11. The business method of claim 10, wherein the recommended competitive offer is determined based on factors including a pluraUty of different reservation prices, the reservation prices respectively corresponding to different bid quantities.

12. The business method of claim 9, the method further comprising the step of determining one of a pluraUty of operational modes, wherein the plurality of operational modes include:

an automatic mode, wherein recommended competitive offers are automatically generated upon request; and

a manual mode, wherein recommended competitive offers are generated manually by a user sponsoring a competition for offers.

13. The business method of claim 12, wherein the step of determining one of a pluraUty of operational modes, further includes a pause mode, wherein the generation of recommended competitive offers are selectively suspended.

14. The business method of claim 13, wherein the competitive offer is one of a pluraUty of offers made in bidding for purchase of products in a forward auction.

15. The business method of claim 14, wherein the recommended competitive offer is calculated based on attributes of the bidder requesting the recommended offer, and bid premiums assigned to the bidder.

16. The business method of claim 15, wherein the bidder attributes considered in calculating different competitive offers include factors of quaUty, risk, and negotiable bid issues, including warranty, deUvery, and payment terms.

17. A process of conducting an auction, wherein: a bidder requests a suggested bid;

a suggested bid is calculated and offered to the bidder; and

upon acceptance of the bid, the bidder becomes an active participant in the auction, wherein bids from other bidders cannot be viewed by the bidder, and wherein any active participant remaining at auction closing is deemed a winner of the auction.

18. The process of conducting an auction as recited in claim 17, wherein the bidder is subjected to one of three auction modes:

an automatic mode, in which the bidder's request for a suggested bid is satisfied with an automaticaUy calculated suggested bid;

a manual mode, in-which the bidder is provided with manuaUy generated suggested bids, and wherein the bidder can be locked-in on a bid in said manual mode to win the auction during the process; and

a pause mode, in which the bidders is suspended from a making bids for a period of time.

19. The process of conducting an auction as recited in claim 18, wherein the suggested bid is calculated based on the bidder's ability to meet requirements of a minimum set of negotiable bid issues, including price, quantity, warranty, delivery, and quality of goods offered by the bidder, and provided discounts attached to the negotiable bid issues which the bidders select.

0. An auction transaction in which an auction owner specifies a pluraUty of underlying constraints for each one of a pluraUty of bidders, the auction owner defining criteria to be met by members of a group of winners of the auction transaction, wherein the auction owner selectively states required bids to bidders, the bidders accepting the stated required bid remain active in the auction transaction, wherein the auction owner restates the required bid for bidder acceptances repeatedly until the auction transaction closes, wherein at the close of the auction transaction, any active bidders become members of a group of winners of the auction transaction.