Haggle Travel
The Haggle architecture consists of a number of Intelligent Software Agents which communicate with one another via a central server (which routes messages amongst the agents). The Haggle negotiation agent, which acts on behalf of the end user, contacts intelligent software agents which operate on behalf of a number of hotels (here referred to as Hotel agents), and negotiates directly with them to find a suitable room.
The Haggle Negotiation Agent has a number of strategies for getting the best hotel room for the user. If there are a number of Hotel agents willing to offer rooms, the agent will try to get them to reduce the price they are willing to accept. If several rooms are offered at an appropriate price, the Negotiator will attempt to improve the facilities on offer for that price, e.g. breakfast included in the price, or free use of the hotel’s business centre. The Haggle negotiation agent and the Hotel agents use an “Iterated Contract Net” protocol (http://www.fipa.org/specs/fipa00030/index.html). The Haggle agent makes successive “calls for proposals”, (which embody requirements such as price, preferred location, and room and hotel facilities). The Hotel Agents respond either with offers of rooms, or else with an explanation for why the offer is being rejected (the price requested is too low, a requested facility is unavailable, etc.).
The Hotel Agents are themselves intelligent software agents operating as principals for various hotels or room suppliers. Each Hotel Agent has access to a database of available rooms and their facilities. Hotel Agents have their own customizable negotiation strategies. For example, they are more willing to compromise on the price of a hotel room booking for today or tomorrow than they would be for a booking for next week. They may insist on stays of two or more nights to get the best rates at weekends. As well as discounting room rates, they may offer prices at a premium in busy periods. Over a series of iterations of the negotiation process (with a fixed time limit), the Haggle negotiation agent is able to find a room for the user that has the best combination of price and features currently available.
At the start of the negotiation process, the user must specify some details of the room/hotel that they are seeking. They must also specify the room’s preferred location (either the user’s current GPS-determined position, or a location determined by searching geocoded map data). They must also specify a target (maximum) price they are willing to pay per night. In addition, the user must specify the maximum time (in seconds) that they want the Agent to continue negotiating.
Having specified these details, the user must then choose a “profile” which is used to evaluate each hotel room that is offered. The profile contains user-specified weightings of the features and facilities of a hotel and a hotel room. The profile provides a means of applying a utility function to evaluate each room offered to the agent, in order for it to be able to evaluate the ‘best’ room on offer. As an example, a “business” profile might favour facilities and location over price, and a “leisure” profile might be less concerned with facilities and location, and more weighted towards getting the lowest price. A “default” profile might aim to locate a room which rates facilities and price equally, and an “emergency” profile might not rate either price or facilities highly (“Get me a room, any room, fast!”).
Once the user has specified both the required room details and the profile to use, the Negotiator Agent starts to negotiate with the Hotel agents. As it does so, the user is provided with feedback about the progress of the negotiation - they are told how many room requests the Agent has sent, and how many offers of rooms the Hotel Agents have made. A progress bar shows how much time remains for the Agent to complete negotiations. The user can stop the process at any point, if they are willing to accept the best of the room offers that have already been made. Figure 2 shows screenshots of the negotiation agent. The first screen shows progress of the negotiation, in terms of requests and offers made, the second screenshot shows summary information about the best offers received at the end of the negotiation process. The ‘best’ deal, in terms of the selected profile, is a three start hotel, 3.3Km away from the user’s current location, for €80 per night (the price and number of stars of the hotel are good, but it is further away than other offered rooms – this example used the ‘leisure’ profile, where price was rated as most important). The constraints of the user specification are relaxed over time, with the Agent willing to accept less favourable rooms closer to the deadline. At the end of this time, they will be presented with details of the best rooms that the Agent has been able to locate, according to the user’s chosen profile.
At this point, after negotiation is completed, the user can look at further information about each room offer. Figure 3 shows an image and text description of one of the hotels that has made an acceptable offer, and routing instructions from the user’s current location to that hotel.
