Action execution

If the opponent evaluates the current course of the negotiation to establish no basis for further negotiation according to the their concession strategy, they will try to interrupt the offering procedure, determined by their offer generation strategy if this is enabled by the protocol, in a predefined order. If the protocol allows to send reject messages (in protocol 3) the agent will do so and elicit a new, maybe better offer, from the opponent which could allow to continue its strategy. This is done at the risk of a termination of the negotiation if the opponent also sends a reject message. However, if it is not possible to reject offers and thereby interrupt the offering procedure temporarily the software agent will try to interrupt it permanently to avoid exploitation and unfavorable outcomes by sending a quit message and breaking off negotiations (in protocol 2). As can be seen from the flowchart in Figure 4.9 the agents will always first try to temporarily interrupt their offering procedure before they break off negotiations, i.e. wait for the opponent to catch up in making sufficiently large concessions to keep on negotiating rather than sacrificing the opportunity of an agreement. If the protocol neither allows to send rejectnor quit messages (in protocol 1) the opponent cannot interrupt its offering strategy and has to send an offer or if no more offers are left, accept the last offer of the opponent. In this protocol, as discussed, an agreement is certain but maybe unfavorable for the software agent that not wants to further negotiate but cannot follow its intention due to restrictions of the protocol. Otherwise, in case the software agent comes to the conclusion – due to the concession strategy it follows – that the current course of the negotiation builds the basis for further negotiating, it has to decide whether to accept the opponent’s last offer or make the counteroffer determined according to its offer generation strategy before. The criterion for accepting an offer of the

4.2. Automated negotiation system 97

opponent is simple and equal for all agents: Software agents accept the last offer of the opponent if it affords same or higher utility compared to the next own offer to be proposed. If this is the case then the agent sends an agree message thereby terminating the negotiation with this agreement, otherwise it sends a message of the type offer proposing the generated offer. Using the notation from the previous section acceptance or offer submission is determined by (4.4).

messagej,t=    agree o−j,t−1, if uj(oj,t) ≤ uj(o−j,t−1) offer oj,t, else (4.4)

Note that this acceptance criterion could have drawbacks when the opponent proposes an offer of high utility early in the negotiation process but the software agent at this point in time is not ready to accept it as the level of own demands is still too high. Normally the software agent would come back to this offer first proposed by the opponent later in his own offering sequence and then the opponent would accept the offer. As both agents follow the same acceptance rules and as the agents follow concession strategies a previous offer proposed is always of higher or equal utility to the software agent than later offers and so if a previously proposed offer is back on the negotiation table as it is proposed again by the opponent following the acceptance criterion it will be accepted. However, the negotiations might terminate earlier with an inferior agreement, a break off of negotiations by one party, or termination by the protocol due to lack of progress. In these cases the opportunity of a favorable agreement is forgone due to the acceptance criterion. One alternative to circumvent this drawback would be a fixed acceptance threshold – as implemented in most evolutionary computing-based strategies for software agents (e.g. Oliver, 1996) – for the utility of the opponent’s offers, where the offer is accepted if it passes this threshold, however then there exists the problem to define this threshold, which might be not trivial for diverse negotiation problems and without information about the opponent’s preferences. If the threshold is to high negotiations often would end without agreement, if it is too low potential value could be left unrealized. For example Chavez and Maes (1996), who implemented a fixed acceptance threshold in their experimental automated negotiation system ’Kasbash’, report:

Users expect their agent not to do clearly stupid things. Even though most partic- ipants knew the details of how their agents worked, they were disappointed when agents did ’dumb’ things that a human would never do, such as accept an offer when a better one was available. This happened because the agents always accept the first offer which meets their asking price; however, there might be another offer which also meets the asking price but is even better. If Kasbash’s agents are to serve as intelligent assistants to the user, then they will have to be made free of such ’bugs’. (Chavez and Maes, 1996, p. 86)

An alternative to this fixed threshold would be a variable threshold like the acceptance functions proposed by Gerding et al. (2003) as a ’social extension’ of their evolutionary computing-based software agent strategies. These functions determine a probability of accepting the offer of the opponent which increases with the utility of the proposed offer. However, again the problem to determine the function exists and due to determining only a probability it is not certain that a favorable offer is actually accepted and the problem of our acceptance criterion therefore with

such an approach also remains unsolved. Therefore we implemented our acceptance criterion, which also is commonly used in other studies, as other approaches do not solve this problem but rather create additional ones.