Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: A Replicable web-based negotiation server for e-commerce
Full Citation
Permanent Link:
 Material Information
Title: A Replicable web-based negotiation server for e-commerce
Series Title: Department of Computer and Information Science and Engineering Technical Reports
Physical Description: Book
Language: English
Creator: Su, Stanley Y.W.
Huang, Chunbo
Hammer, Joachim
Publisher: Department of Computer and Information Science and Engineering, University of Florida
Place of Publication: Gainesville, Fla.
Copyright Date: 1999
 Record Information
Bibliographic ID: UF00095442
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.


This item has the following downloads:

1999378 ( PDF )

Full Text


Stanley Y. W. Su, Chunbo Huang, Joachim Hammer
Database Systems R&D Center
University of Florida, Gainesville, FL 32611-6125
{su, chuang, jhammer}

This paper describes an ongoing R&D effort in developing a replicable, Web-
based negotiation server to conduct bargaining-type negotiations between clients
(i.e., buyers and sellers) in e-commerce. Multiple copies of this server can be
installed as plug-ins to existing Web-servers. Each client can select a trusted
negotiation server to represent his/her interests. Web-based GUI tools are used by
clients in a build-time registration process to specify the requirements, constraints,
strategic negotiation rules, and preference scoring methods and aggregation
functions related to the buying or selling of a product. The registration information
is used by the negotiation servers to conduct negotiations automatically on behalf
of the clients. In this paper, we present the architecture of the negotiation server
and the framework for automated negotiations and describe a number of
communication primitives, which make up the negotiation protocol. A constraint
satisfaction processor (CSP) has been developed to evaluate a negotiation proposal
against the registered constraints. If a violation of constraint is detected, a violation
event is posted. An Event-Trigger-Rule (ETR) server is used to manage events and
trigger the execution of strategic rules, which may relax constraints, inform clients,
or perform other operations. A cost-benefit analysis component is used to perform
quantitative analysis of alternative negotiation conditions. The negotiation server
has been implemented and demonstrated.

1 Introduction
In recent years, we have witnessed a dramatic increase in the number of
companies doing business on the Internet. Electronic commerce (e-commerce) has
been adopted by companies of all sizes ranging from multinational corporations to
small mom-and-pop operations. It has been predicted that, by the year 2000, nearly
80 percent of all Fortune 500 companies will be doing their core business through the
Internet. Today, there are more than 30 million Internet users and the number is
projected to grow to 90 million in the near future. Since these users are potential
consumers, there are many incentives for companies of all sizes to publish information
about their goods and services on the Internet. Any company can become a global
publisher by establishing an information site on the Internet's World Wide Web (Web).
The Web provides customers and businesses with ubiquitous interactive access to
text, sound, images, and even video data published on each site. In the e-commerce

* Work funded by a NIST/ATP grant.
Database Center University of Florida

paradigm, companies can receive purchase orders from individual consumers or
business partners, deliver goods and/or services, and accept payments, all in an
electronic fashion.

In ordinary, non-electronic business transactions, individual consumers and
companies often want to negotiate the price, the delivery date, the quality of goods
and services, as well as other purchase conditions; particularly if the order is large.
Traditionally, negotiations are conducted by people involved in business transactions.
In both consumer-to-business and business-to-business e-commerce, it is desirable to
carry out this negotiation process either automatically or at least semi-automatically
with human interventions only when necessary. Given the recent interest in e-
commerce, a considerable amount of research work on automated negotiation
systems is already available. Muller [MUL96] provides a thorough description on the
principle of negotiation based on the investigations of the distributed artificial
intelligence group. Beam and Segev [BEA97] also give an insightful overview of the
existing research efforts on this topic.

There are several forms of negotiations: bidding, auction, and bargaining.
Bidding is the simplest form of negotiation, in which a buyer specifies the product or
service he1 wants to acquire from suppliers and asks for their bids. Based on the bids,
the buyer selects the suppliers) from whom to order the goods or services. The
Contract Net Protocol (CNP) of Davis and Smith [SMI80] is a good example of bidding.

Auction is another form of negotiation, in which a fixed auction protocol is
followed. There are several negotiation Web sites, which use auction protocols.
Yahoo's auction service, Cathay Pacific's sealed-bid auction to sell airline tickets, and
Onsale's high tech goods auction [BEA97] are some examples. [KUM98] explores a
variation of auction and [BEA96] discusses optimization issues. [LEE97] incorporates
several typical auction protocols as a part of an intelligent EC framework with
negotiation capabilities. Wurman et al. [WUR99] present a configurable, flexible
auction server architecture that accepts bids by both humans and software agents.

Bargaining is the most complex form of negotiation, which involves issuing
proposal and counterproposal between negotiation parties until a mutual agreement
or disagreement is reached. Researchers in distributed artificial intelligence have used
negotiation for conflict resolution and coordination among multiple agents [MUL96].

Database Center University of Florida

For example, [SAN95] discusses a "self-interest agent" to design an optimized
evaluation/decision function and suggests several elements that should be considered
in negotiation: commitment level, local deliberation, and linking negotiation items.
Using ideas borrowed from game theory, [ZL096] treats negotiation as a type of
interaction among distributed computer systems. In order to make the overall system
more efficient, interaction rules (called negotiation mechanisms) are followed by each
component system. [SIE97] addresses the searching property of negotiation and
discusses issues related to negotiation strategy, tactics, and search convergence.
[KOI98] uses a service constraint satisfaction technique and a worth-based evaluation
function to determine the final deal in a quality-of-service negotiation. [OLI97] shows
that any pre-programmed negotiation strategy will not be effective in real negotiation
cases and shows that a system of artificial adaptive agents, using a genetic algorithm,
can learn strategies that enable the system to effectively participate in business
negotiations. However, [BEA97] points out that genetic programming requires too
many trials to obtain good negotiation strategies.

Our work focuses on bi-lateral and multi-lateral bargaining, which are very
challenging problems in negotiation. It is founded on the concepts and issues
addressed in the previous work mentioned above. However, we take an object-
oriented database approach instead of the agent approach in the development of a
Web-based negotiation server, which can be replicated and installed as plug-ins to
existing Web servers. Buyers and sellers (henceforth referred to as clients) can select
their own trusted negotiation servers to conduct negotiations on their behalf; the
same way as lawyers are asked to represent their clients in legal matters. Similar to
Web servers, which provide many useful Web services, negotiation servers provide
negotiation services to their clients. Each negotiation server provides the following
four negotiation services:

* A registration service to allow a buyer to specify the requirements and constraints
of the goods or services he wants to acquire and a seller to specify the information
and constraints related to the goods and services he provides. A client can also
register a set of negotiation rules, which specify the negotiation strategies/tactics
to be followed when constraints are violated during the negotiation phase.
Additionally, he/she can specify the preference scoring and aggregation methods to

1 The terms he, his, etc. are used throughout this paper to refer either to an individual (male or female) or a company.

Database Center University of Florida

be used for the cost-benefit analyses of alternative combinations of negotiation
conditions. A number of Web-based GUI tools are developed for the registration
purpose. The specification of a product or service and the specification of a
negotiation proposal or counter-proposal are posed in a content specification
language whose underlying object model is an extended object model (EOM),
which represents all objects of interest in terms of attributes, operations
(methods), events, rules, and triggers. The rule specification part of the language
is an extension of the Event-Condition-Action (ECA) rule paradigm. The registered
information are stored in a persistent store.

* A negotiation proposal processing service to evaluate proposals and generate
counter-proposals, explanations, messages, etc. by following a negotiation protocol
until an agreement or disagreement is reached or the negotiation is terminated
unilaterally by a client. A constraint satisfaction processing component is used to
evaluate a negotiation proposal or counter-proposal against pre-registered
requirements and constraints. An event is posted to signal the detection of a
constraint violation.

* An event and rule management service to detect and manage events and to trigger
rules that are relevant to the posted events. These rules may automatically relax
some constraints, call for human interventions or perform other operations. The
relaxed constraints and/or human inputs are used as the basis to form counter-
proposals. This service is provided by an Event-Trigger-Rule (ETR) server [LS98].

* A cost-benefit analysis service to allow a client to perform quantitative analysis on
alternative negotiation proposals and obtain their relative, quantitative cost-benefit
measures. For this service, we have adopted the cost-benefit decision model
presented in [SU87].

The paper is organized as follows. The architecture for the Web-based
negotiation server and a framework for conducting automated negotiation are
described in Section 2. Some registration examples posed in a content specification
language are given in Section 3. Section 4 explains the negotiation process and the
negotiation protocol in more detail. Section 5 briefly outlines our cost-benefit decision
model. A conclusion and discussion is given in Section 6.

Database Center University of Florida

2 Negotiation Server Architecture and Negotiation Framework
Figure 1 shows the relationships between negotiation servers, Web servers, client
computers, and humans in the negotiation process. In addition, some of the clients
may have application systems to maintain the inventories of goods or the information
about the services they provide. To simplify our presentation of the negotiation
process, we shall use the symbols EA, UA, and NSA to denote the expert, user, and
negotiation server of the negotiation party A, respectively. The corresponding
symbols EB, UB, and NSB are used to denote those of negotiation party B.

In the proposed framework of Web-based negotiation, potential sellers can
publish information about the goods and services they provide on their home pages,
which can be browsed by the potential buyers using Web browsers and search
engines. Through searching and browsing, or other available trader services, a buyer
can identify potential sellers with whom the buyer wants to conduct negotiations. In
order for buyers and sellers to make use of the automated negotiation service, each
must register with a negotiation server of their choice and provide the information
that is necessary to conduct the negotiation (see Section 3 below).

A client (i.e., UA in Figure 1) initiates the negotiation process by submitting an
initial negotiation proposal to his negotiation server. The negotiation server (NSA)
carries out the negotiation process by sending a computerized, XML-wrapped call-for-
proposal to NSB, which represents the seller (UB). NSB checks the information and
constraints specified in the initial proposal against the registered information of UB.
In the event that a conflict or constraint violation is found, relevant strategic rules,
which have been provided by a negotiation expert EB, are applied to either (1) reject
the proposal, (2) consult with UB for decision-making, (3) suggest possible changes
to NSA, or (4) generate a counter-proposal to be returned to NSA. If UB maintains an
inventory of goods or recorded information on services (e.g., a database system with
a public interface), NSB can use the data and constraints of the proposal to query the
database to verify the availability of the goods or services in question. When a
proposal contains multiple alternatives (see Section 4), a cost-benefit analysis
component is called to perform a quantitative analysis and provide a cost-benefit
rating of the alternatives. The highest ranked alternative will be sent back to UA
together with UB's constraints as the counter-proposal, which starts another round of
negotiation. The counter-proposal is evaluated in the same way by NSA against its

Database Center University of Florida 5

client's constraints. This process will continue until an agreement is reached or either

side terminates the negotiation process.

Proposal / Counter Proposal
I nternet ..-----.-----.----- ----------.--------.. ----.

Wl b Server W ( eb Ser er
Negotiation Negoti at on
Sever A NSA Sava B NSB
Registration Registration t
NSAs Other NSBs Other
Exert(EA) register d E t(EB) registered
Buyer Clents S ler Clents
Use UA) rCilent IUser (UB) Clent


Figure 1: An Overview of Web-Based Negotiation.

3 Registration and Content Specification Language

Before an automated negotiation can take place, a client must first inform the

corresponding negotiation server, and indirectly the other parties involved, of the

goods and services he provides (in the case of a supplier) or wishes to acquire (in the

case of a consumer) as well as any special requirements that may influence the

negotiation (e.g., delivery constraints or special discounts for large orders). For

suppliers, part of this registration procedure is done in the form of advertisements,

which are published as Web pages. The contents of these advertisements can be

indexed and catalogued (for example, by application domains) and are searchable just

like regular Web pages. We assume that negotiation servers either maintain their

own index of relevant advertisements or use a third-party tool such as search engines

(e.g., AltaVista) or yellow page services (e.g., Yahoo) to help locate the

advertisements (i.e., information pull model). Alternatively, one can also envision a

scenario in which suppliers actively inform the relevant negotiation servers of their

goods and services by sending the advertisements directly to the servers (i.e.,

information push model). The approach to negotiation described in this paper is

independent of the particular paradigm (i.e., either push or pull) used by suppliers. In

our current implementation, the information push model is used. For consumers, the

registration is done by specifying a set of requirements and constraints for describing

Database Center University of Florida

the desired goods or services and rules for expressing negotiation strategies to a
negotiation server of their choice.

As the number of Internet users continues to grow, multiple negotiation servers
must be made available on the Internet for scalability. A description of the procedure
and criteria for selecting a negotiation server is beyond the scope of this paper. In
this section, we focus on the registration procedure and supporting facilities.

First, in order for an arbitrary negotiation server to communicate with its clients
and process their registration information, both the sellers' and the buyers'
information, as well as the subsequent negotiations, must be formulated in a common
language using a vocabulary that is understood by all parties involved. In order to
satisfy the first requirement, we have developed a content specification language and
its accompanying Web-based GUI tools for expressing the registration information,
i.e., attributes, data values, constraint, and strategic rules. In order to satisfy the
second requirement, we need an ontology [FG94] for describing the terms and their
relationships that are used during registration and those used in the actual negotiation
process. In this work, we assume that a common ontology exists and is used by
negotiation participants, i.e., sellers, buyers, and negotiation servers. Another
important part of registration information is the data to be used by the cost-benefit
decision model, which will be discussed in Section 5.

3.1 Data and Constraint Specification
Registration forms provided by servlets are used by both suppliers and buyers to
specify their requirements and constraints, which are used by negotiation servers to
conduct automated negotiation processes. The registered information is stored as
objects in a persistent repository. For example, a product or service offered by a
supplier or to be acquired by a buyer is represented as an object, which has some
attributes describing its properties and some constraints describing the attribute and
inter-attribute constraints. The following example depicts a sample advertisement of a
computer system offered by a fictitious supplier. Consumer registration information
can be represented analogously.

ENTITY Computer_System {
model String ENUMERATION{PII350, PII400} priority [3]
memory Integer ENUMERATION {32m,64m, 96m} priority [4]
monitor Integer ENUMERATION {17, 19} priority [5]
harddrive Integer ENUMERATION {4g, 6g, 8g} priority [6]
unit_price Float DERIVED priority [2]

Database Center University of Florida

deliver dayInteger RANGE[14..21] priority [1]
quantity Integer RANGE [250..550] NotNegotiable
quantity_deliver_day_l quantity >= 400 implies deliverday >= 16 priority [1]
model memory_l model = 'PII400' implies memory >=64m priority [2]
In this example, the supplier advertises a computer system, which is specified as
an ENTITY object class named Computer_System. The advertised entity class is
available in many different configurations as described by the attributes. Each
attribute value is of a particular (atomic) type (e.g., String, Integer). An attribute
constraint is specified by enumerating a set of possible values (note that a single
value is a special case of an enumeration) or by a value range. In addition, attributes
whose values depend on other values and cannot be determined until the negotiation
is under way are marked as DERIVED. All attribute values are negotiable unless
marked by the special keyword NOTNEGOTIABLE. Inter-attribute constraints describe
the relationships between two or more attributes. The syntax for inter-attribute
constraints is:

constraint-name antecedence or
constraint-name antecedence implies consequence
In the example above, the constraint called modelmemory_l specifies that if a
customer opts for a computer system with 'PII400' as its model, the corresponding
memory size must be at least 64MB. The priority numbers are used for determining
the order in which constraints are validated starting from the smallest; however, any
constraint marked as NotNegotiable will always be checked first.

3.2 Rules for Specifying Negotiation Strategies
So far, we have described the format of advertisements and requests for goods
including various constraints using our content specification language. As mentioned
before, an important part of the registration procedure is the specification of
negotiation strategies to be used by the negotiation server on behalf of its client. In
our negotiation system, we adopt a declarative approach. Each strategy is expressed
in terms of an ETR rule, which specifies the condition to be checked and the actions to
be taken by the negotiation server. Rules are activated upon the occurrence of
specific events during the negotiation process. More specifically, a strategic rule has
three parts: (1) the condition under which the subsequent action is to be taken (e.g.,
the proposed sales price is below manufacturing cost); (2) the particular actions) to
be taken when the condition is met (e.g., the modification of the current constraint);

Database Center University of Florida

(3) an optional alternative actions) to be taken when the condition is not met (e.g., a
request for human intervention). The relationships between events and rules are
specified by triggers. A trigger specifies that, upon the occurrence of any number of
alternative events (i.e., trigger events), a composite event or event history should be
checked and a structure of rules should be activated if the composite event
verification is successful. This separation of events, rules, and triggers allows more
flexibility in pairing events with rules or rule structures. Furthermore, it makes a
more explicit semantic distinction between trigger events, the verification of
composite events or event history, and the rule structure than the traditional Event-
Condition-Action (ECA) rules.

The following two strategic rules on the supplier side outline the specification of a

negotiation strategy in the ETR format. We refer to the entity class Computer_System

in the sample advertisement given above as the context. In the example, events are
posted by the constraint satisfaction processing component of the negotiation server
upon detecting a conflict or violation of an attribute constraint or an inter-attribute
constraint. The event names are generated by extending the corresponding constraint
and attribute names. Since the sample negotiation rules are very simple (no
composite events) we only show the trigger events and rules that constitute trigger
specifications instead of using the full syntax of our content specification language.

Strategic Rule 1: If deliver_day is out of range, check the lower bound of the

constraint for attribute deliver_day. If the lower bound is still greater than 10 (i.e., the
bottom line), shorten the delivery time by two days. Otherwise, the constraint is
considered unresolvable and human intervention is required.
TriggerEvent SupplierComputer Systemdeliver_day
SR1: Condition: getLowBound("deliver day") > 10
Action: downLowBound("deliveryda", 2);
Alternative: unResolvable("deliver day cannot be satisfied");

Strategic Rule 2: If the quantity_deliver day_ 1 constraint is violated, check if this
constraint has already been relaxed. If not, relax the constraint to: "quantity >= 500
implies delivery_period>=15" and change the relaxation flag to true to prevent a
further relaxation. Otherwise, the constraint is considered unresolvable and human
intervention is required.
TriggerEvent SupplierComputer_Systemquantity_deliver_day_l
SR2: Condition: getIACStatus("quantity_deliver_day_l") = "NOCHANGE"
Action: setIAC("quantity_deliver_day_l", "quantity >= 500", "deliver_day>=15");
setIACStatus("quantity deliver day 1", "RELAXED");

Database Center University of Florida

Alternative: unResolvable("deliverday cannot be satisfied");

4 Negotiation Process
We now describe three important aspects of the negotiation process: (1) the
negotiation primitives, which define messages passed between negotiation parties; (2)
the negotiation proposal, which expresses negotiation conditions and constraints;l and
(3) the procedure for processing the proposal and for generating a counter-proposal,
which includes constraint checking, triggering of strategic rules, inventory verification,
and cost-benefit analysis.

4.1 Negotiation Primitives
Table 1 shows a list of negotiation primitives used in our system. It is a subset of
the primitives given in [MUL96]. Many other primitives stemming from work in agent
communication languages are not germane to this work.

CFP Initiate a proposal ("call for proposal")
Propose Send a proposal or a counter-proposal
Accept Accept the terms and conditions specified in a proposal without further
Terminate End current negotiation process and terminate session
Reject Reject the current proposal with or without an attached explanation
Acknowledge Acknowledgement after receiving a message
Modify Modification to the proposal that was sent last
Withdraw Withdraw the last proposal
Table 1: Negotiation Primitives.

4.2 Negotiation Proposal
A client initiates a negotiation process by sending a proposal via its server to
inform the other side about his intentions, requirements, and constraints with respect
to a planned purchase. The proposal will be evaluated, modified, and returned as a
counter-proposal. Several counter-proposals can go between two negotiation servers
until a final agreement is reached. Existing negotiation systems allow only constant
values to be specified in a proposal. For example, in a proposal describing a task
allocation scenario, the negotiated task must have fixed values for resource
requirements, time deadline, cost, etc. When buying a TV, for example, the proposal
must provide values for the TV's size, brand name, price, etc. The disadvantages of
this restriction are obvious. First, a client may not have the domain knowledge to give
a value for a certain attribute. In our example below, the computer buyer has no idea

Database Center University of Florida

about the particular warranty contract that is available for the desired product and

should be allowed to leave this value unspecified. Second, a client may not have

enough knowledge to compute values that depend on other (unknown) values. For

instance, determining the proper CPU/memory configuration is a complicated decision

task for most customers. Instead, clients should be allowed to specify ranges of values

or enumerate alternatives for these attributes. In our approach, a call-for-proposal or

a counter-proposal contains the specification of data conditions and constraints

associated with the goods/service, under which a buyer or seller wants to buy/acquire

or sell/provide. We use the same content specification language to specify proposals

and counter-proposals as it is used in the registration phase for specifying general

requirements and constraints. Proposals are translated into XML documents for

transmission to the other negotiation server.

The following example shows an initial proposal issued by a buyer to purchase

computers (XML tags not shown):

Entity Proposal{
model String ENUMERATION{ "PII350"
monitor Integer ENUMERATION{15, 17, 19}
memory Integer RANGE[16m..64m]
hard drive Integer RANGE [1g.. 12g]
unitprice Float RANGE[0.0..1700.00]
deliverday Integer RANGE[3..10]
quantity Integer RANGE[300..400]
Constraintl memory < 64m implies hard dirve < 4g
Constraint2 monitor = 15 implies unitprice < 1500

In a more general structure, a proposal can be specified as a tree of attributes

and constraints. Each composite attribute is represented by a substructure of

attributes and their constraints. Since range and enumeration are used to specify the

constraints of some or all of the attributes, a proposal specifies many combinations of

data values. In this work, a proposal is treated and stored as an instance of a proposal

object class. The data, attribute, and inter-attribute constraints of the proposal

instance are processed by the constraint satisfaction processing component of the

negotiation server against the registered data and constraints of the recipient of the

proposal. Comparison operators for range and enumeration are introduced for

processing the data. During processing, conflicts or violations of constraints will result

in the posting of the corresponding violation events. Note that the proposal and

registration information differ mainly in the fact that proposals do not include any

Database Center University of Florida

strategic rules. Also note that the constraints in a proposal must be consistent with

the registered constraints of the client issuing the proposal.

4.3 Negotiation Procedure
After receiving a proposal, a negotiation server has the following choices: accept

it, respond with a counter-proposal, reject it with an optional explanation, or
terminate the negotiation. In order to arrive at a decision, the negotiation server

follows the general proposal processing procedure shown in Figure 2.

Incoming Proposal Registered Constraints
r ------ ------------------ k^ ..
Attribute Constraint
Verification Verification

Inter Attribute Constraint

Constraints Satisi Constraint Violation(s)
Cost-Benefit Analysis Constraint Relaxation
Generate Combinations Report Conflicts
Evaluate Relax
I Evaluate | RelaxStrategic
Final Agreement Counter Proposal Ru

Figure 2 Proposal Processing Flow

We shall explain the above procedure using examples. The buyer's proposal is

processed by the negotiation server NSB against the supplier's registration

information given in Section 3. First, attribute-constraints are checked. According to

the priority, the NotNegotiable constraint for quantity is checked first. NSB finds that

the user's Quantity constraint is satisfied. Then, the delivery_day constraint is checked

and NSB finds a violation since the supplier specifies the delivery_day constraint in the

range of [14..21] whereas the buyer requires a delivery day range of [3..10]. As a

result, NSB posts a violation event "SupplierComputer_Systemdeliver_day" and

triggers rule SR1 to relax the Supplier's deliver_day constraint. According to the

action part of the rule, NSB changes the supplier's deliver_day constraint from

RANGE[14..21] to RANGE[12..21].

Database Center University of Florida

No other constraints are violated and the outgoing counter-proposal to the Buyer

is as follows. Note: the outgoing counter-proposal does not contain priorities since

the buyer has his own constraint evaluation order.

ENTITY Computer_System {
model String ENUMERATION{PII350}
memory Integer ENUMERATION {32m,64m, 96m}
monitor Integer ENUMERATION {17, 19}
harddrive Integer ENUMERATION {4g, 6g, 8g}
unit_price Float DERIVED
deliver day Integer RANGE[12..21]
quantity Integer RANGE[250..550]
quantity_deliver_day_l quantity >= 400 implies deliverday >= 16
model memory_l model = 'PII400' implies memory >=64m

As illustrated by the supplier's negotiation rules, the supplier uses a combination

of cooperative and competitive negotiation strategies. The same assumption is made

on the buyer's side. In this context, "cooperative" means that they are willing to relax

their constraints when constraint violations are detected. "Competitive" means that

their bottom-line values specified in their negotiation rules will not be made known to

their counterpart and, if a bottom-line value is reached and the violation still exists,

the proposal being evaluated will be rejected. The other side will be informed of the

reason for the rejection. It is the other side's turn to decide if a concession should be


When the counter-proposal arrives at the buyer's NSA, it will go through the

same processing procedure except that the registered constraints, strategic rules, and

the cost-benefit evaluation model of the buyer are used. After the constraint

evaluation, NSA may decide to reject or accept the counter-proposal, or generate

another counter-proposal to be sent back to NSB. This back-and-forth process

continues until a mutual agreement is achieved or either side terminates the

negotiation process. The negotiation protocol is shown in the finite state diagram in

Figure 3.

Database Center University of Florida

nd Reje
------cv Proposm--
end Acce

Send Terminate
Send Propo e Recv Terminate
ecv Propose Recv Accept

Send CFP v Termim

Send Accept
ecv Reject

Se d Terminate
Send Propose /

Figure 3: Finite State Diagram for the Negotiation Process.

In this finite state diagram, so to S6 represent the different states of a

negotiation server during a negotiation process. E is the terminal state in which an

agreement or disagreement is reached. The send (Send) and receive (Recv)

primitives specify the interactions between negotiation servers and cause state

transitions. For example, the sequence of transitions, SOS1- >S2>S4->S2->S6-E,

can be interpreted as follows: NSA sends a call-for-proposal (CFP) to NSB (SO->S1)

and receives a counter-proposal from NSB (S1->S2). After evaluation, NSA rejects the

counter-proposal (S2->S4) but receives a second counter-proposal from NSB

(S4->S2). NSA decides to accept the second proposal (S2->S6) and sends out an

acceptance message. In return, it receives an acceptance message from NSB

(S6->E). A mutual agreement is therefore reached and the negotiation process


We stress here that the above procedure and protocol is only one of many

possible negotiation procedures and protocols. We are investigating other alternatives.

5 Quantitative Cost-Benefit Decision Model

Negotiation is a complex decision making process. The decisions may include not

only the rejection or acceptance of a proposal, but also the evaluation of and the

selection from multiple choices. The latter is needed in the following situations:

* A client receives a proposal, which specifies a number of alternative negotiation


Database Center University of Florida

* A client may conduct negotiations simultaneously with multiple parties.

* A single proposal may contain a large number of value combinations, which need
to be evaluated to make the optimal selection when determining the final
agreement or forming a counter-proposal (we note here that a proposal uses
range, enumeration, and constraints to specify purchase or sales requirements).

A systematic, quantitative, and justifiable cost-benefit evaluation model is
needed for implementing an automated negotiation system. In this work, we have
adapted the cost-benefit decision model (CBDM) reported in [SU87]. In this model,
the contents of each proposal instance are divided into two structures: the cost
structure, which contains all the attributes to which costs can be assigned, and the
preference structure, which contains all the attributes to which preference scores can
be assigned subjectively (note: these two sets of attributes may overlap). The
structures are separately analyzed to obtain two aggregated values: an aggregated
cost value and the global preference score. These two values are then combined to
derive a global cost-preference indicator for each proposal instance. The costs,
preference scores associated with all the attributes as well as the aggregation
functions are specified by clients during the registration process. Forms accessible
through Web browsers are provided for this registration purpose.

In the preference analysis based on the preference structure, preference scores
in the range of zero to one are assigned to all the attribute-value pairs using a set of
"elementary criteria." The elementary preference scores are then weighted and
aggregated into a global preference rating using a spectrum of "preference
aggregation functions", which are derived from a weighted power mean:

r r r 1/r
E=(w .e1 +w2.e2+...+wn.en)r

By varying the value of r, a spectrum of aggregation functions is generated,
including functions such as min, max, weighted arithmetic mean, etc. Some commonly
used functions are given in Table 2 below.

Minimum E= min(el, e2, ... ,en) r = -oo
Harmonic mean E=1 / (wl/el+w2/e2+... + wn/en) r = -1
Geometric mean E =(e .(e2w2 r=O

Weighted arithmetic E=wl*el + w2*e2 +... wn*en r=l

Database Center University of Florida

Square mean E= 2 2r=2
E= -w^ *e1 +W2 *e2+...
Maximum E= max(el, e2, ...., en) r=+oo
Table 2: Aggregate Function Spectrum.

These alternative aggregation functions represent different degrees of
conjunction and disjunction of negotiation conditions. They can be selected by clients
to suit different decision situations and for the selection of different products and
services. For example, the maximum aggregation function is suitable when one or
more of the negotiation conditions is acceptable to a client. In that case, the maximal
value among all the preference scores derived for the negotiation conditions will be
used as the global preference score.

6 Conclusion
In this paper, we have presented an architecture and the services provided by
a replicable Web-based negotiation server. A content specification language for
information registration, a negotiation protocol, a negotiation procedure, and a cost-
benefit decision model were described. In contrast to most of the existing work on
negotiation, which is based on a distributed agent technology, our work makes use of
an object-oriented, active database technology. We introduce an object-oriented
content specification language, which is based on an extended object model. The
language and its accompanying GUI tools are used, for example, by buyers to specify
the data characteristics and constraints of goods and services in which they are
interested in, and by sellers to publish information about the goods and services they
provide. Negotiation experts also use this language and GUI tools to specify
negotiation strategies in terms of active negotiation rules. The same language is used
by clients to define proposals and counter-proposals, which are wrapped in XML and
transmitted between negotiation servers. The constraint, event, rule, and trigger
specification facilities of the language and its object model are extensions of the
traditional object definition language and model, in which objects are defined only in
terms of attributes and methods. The added semantics in the specifications of goods
and services and negotiation proposals and counter-proposals allow negotiation
servers to carry out constraint verification, activation of negotiation strategic rules,
and generation of counter-proposals in an automated fashion. In our research, we
have found that existing work on auctions and bargaining-type negotiations focuses

Database Center University of Florida

mainly on single negotiation items (e.g., price alone) and uses a single element
scoring function or a single aggregation function [SIE97] to evaluate proposals. In
distinction, our work tackles negotiation problems that involve multiple negotiation
items and uses a number of elementary scoring criteria and a spectrum of aggregation
functions to conduct cost-benefit analyses.

The negotiation server described in this paper has been implemented. Two copies
of the server were integrated with several supply chain management components
provided by other members of a joint industrial and university consortium. The four
negotiation services described in Section 2 were demonstrated in a recent project
meeting (May 18-21, 1999). All these services can be accessed through the Web
without any client programming. A Web-based run-time monitoring and human
intervention facility is also implemented using applet and servlet technology. We also
make use of an existing object manager to provide the meta-data management and
persistence support for the registration service. The Event-Trigger-Rule server used in
this work is a modified, Web-enabled version of an existing server which was designed
to run in a CORBA-based environment.

[BEA96] C. Beam, A. Segev, and J.G. Shanthikumar "Electronic Negotiation through
Internet-based Auctions," Technical Report, University of California at
Berkeley, 1996.
[BEA97] C. Beam, A. Segev, et al., "Electronic Catalogs and Negotiations," Technical
Report, University of California at Berkeley, 1997.
[FG94] M.S. Fox and M. Gruninger, "Ontologies for Enterprise Integration," in
Proceedings of the Second International Conference on Cooperative
Information Systems (CoopIS), Toronto, Canada, pp. 82-89, 1994.
[KOI98] J. Koistinen and A. Seetharaman, "Worth-Based Multi-Category Quality-of-
Service Negotiation in Distributed Object Infrastructures", HP Technical
Report, 1998.
[KUM98]M. Kumar and S. I. Feldman, "Business negotiation on the Internet." IBM
Institute for Advanced Commerce (IAC) Report, 1998.
[LS98] H. Lam and S.Y.W. Su, "Component Interoperability in a Virtual Enterprise
Using Events/Triggers/Rules", In Proc. of OOPSLA '98 Workshop on Objects,
Components, and Virtual Enterprise, Oct. 18-22, 1998, Vancouver, BC,
[LEE97] J. G. Lee et al., "ICOMA: An open infrastructure for agent-based intelligent
Electronic Commerce on the Internet ", In Proceedings of the International

Database Center University of Florida

Conference on Parallel and Distributed Systems (CPADS). IEEE Comp Soc,
Los Alamitos, CA, pp 648-655, 1997.
[MUL96] H. J. Muller, "Negotiation Principles", Chapter 7, Foundations of Distributed
Artificial Intelligence, (G. M. P. O'Hare and N. R. Jennings eds.), John Wiley &
Sons, Inc, 1996.
[OLI97] J. R. Oliver, "A Machine Learning Approach to Automated Negotiation and
Prospects for Electronic Commerce", Journal of Management Information
Systems, 13(10), pp. 83-112.
[SAN95]T. Sandholm et al., "Issues in Automated Negotiation and Electronic
Commerce: Extending the Contract Net Framework", In First International
Conference on Multi-Agent Systems (ICMAS-95), San Francisco, CA, 1995.
[SIE97] C. Sierra, P. Faratin and N. Jennings: "A Service-Oriented Negotiation Model
between Autonomous Agents", In Proc. 8th European Workshop on Modeling
Autonomous Agents in a Multi-Agent World (MAAMAW-97), Ronneby,
Sweden, 17-35.
[SMI80] R.G. Smith, "The contract net protocol: High-level communication and control
in a distributed problem solver." In Readings in Distributed Artificial
Intelligence (A. Bond and L. Gasser, eds.), Morgan Kaufmann, San Mateo,
CA, 1980.
[SU87] S. Y. W. Su, J. Dujmovic, D. S. Batory, S. B. Navathe, and R. Elnicki, "A
Cost-Benefit Decision Model: Analysis, Comparison, and Selection of
Database Management Systems", ACM Transactions on Database Systems,
Vol. 12, No. 3, Sept. 1987, 472-520.
[WUR99] P. Wurman, M. Wellman, et al., "A Control Architecture for Flexible
Internet Auction Servers", First IAC Workshop on Internet-Based Negotiation
Technologies, Yorktown Heights, New York, 1999.
[ZL096] G. ZIotkin, S. Jeffrey, and A. Rosenschein, "Mechanism design for automated
negotiation and its application to task oriented domains", Artificial
Intelligence 86 (1996), pp. 195- 244.

Database Center University of Florida

University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs