TAGA game simulates a global travel market in the Agentcities environment. A customer from City A want to have a recreational tour in resort R, so he/she needs a round-trip flight ticket and corresponding hotel accommodation when he/she is in resort R. Moreover, the customer will be happy if his/her preferences are satisfied, e.g. living in good hotel, enjoy a concert or go to a famous restaurant. In TAGA, all such service providers can sell their services on the Web and thus form a Web Travel market. Travel agents will help the customer to buy the travel package from the Web travel market.
All the TAGA agents are FIPA compliant and FIPA Interaction Protocols are used in agent communication. A marketing mechanism is defined as an big interaction protocol which embeds some sub-interaction protocols. In the rest of this document, we will first describe the functions of TAGA agents in section2, then we will discuss the marketing mechanisms and their corresponding interaction protocols in section 3.
There are six types of agents in TAGA: Customer Agent, Travel Agent, Bulletin Board Agent, Web Service Agent, Auction Service Agent and Central Control Agent. These agents are autonomous and can collaborate in the distributed Agentcities environment.
CA represents the human customers. A customer intends to buy a travel package. A CA can support either one customer or a group of customers. A CA can: (1) maintain user preference, which can be either synthesized or directly collected from the real customers; (2) select a proper TA to delegate the customer to buy preferred travel package in the travel market. Contract is signed to ensure the TA to buy and submit the travel package.
BBA is a robot, which facilitates the communication between CAs and TAs. A BBA can: (1) allow TAs to subscribe (normally TAs will subscribe BBA at the beginning of game); (2) accept CA's recruiting request, and then broadcast the attached travel package CFP all subscribed TAs.
WSA represents the real world companies, who sells goods on the Web. The goods can be real life services, such as an airline ticket, a hotel room reservation, and an entertainment ticket, or items, such as artifact, food, and etc. A WSA can: (1) allow other agents to query its own description (e.g. service type, service quality, location) or its inventory ( the quantity or price of a certain type of goods); (2) allow the other agent to buy the goods it has; (3) bid intentionally in the auctions to sell its good, e.g. listing its goods in auction and wait for the proper buyer.
ASAs are robots, which provide auction services on the Web. An ASA can: (1) create an auction instance upon receiving CreateAuction request; (2) handle bids upon receiving SubmitBid proposal message and send feedback message back; (3) report auction result to affiliate agents when auction close. ASAs are categorized by the type of auction they supported. Current TAGA has following types of ASAs:
TA represent the human travel agent, who assembles travel packages for the customers. It can (1) propose contract to CA according to the customer's travel package CFP; (2) buy goods from the travel market through all possible purchase mechanisms.
CCA is a robot, which controls and audits the TAGA game. It can (1) start/stop a TAGA game instance; (2) record the reported market transactions in TAGA, (3) publish the other agents' performance, e.g. TAs total wealthiness ranking, TAs' reputation ranking.
TAGA agents collaborate to achieve market mechanisms. There are two important types of market mechanisms in real world travel market: contract and purchase. A customer first make a contract with a travel agent and let the travel agent to buy him/her a travel package. Secondly, the travel agent, whether get the contract or not, will purchase goods in the travel market to assemble travel packages in the future. Running in the cyberspace, TAGA game does the same thing. Note that an authority, played by CCA, is used to monitor the market transaction, such as ownership change and payment, and a
A customer will not directly buy his travel package from the web travel market, and he/she will let a TA to do so. A TAGA contract mechanism shows how the CA and TA interact from the CA issues the travel request to the CA receives the feasible travel package. Two options are available: static contract and dynamic contract.
Normally, a contract includes following elements: the identity of the customer and the travel agent, the customer's budget limit, the travel package inventory, how the travel agent get paid, the penalty for failure.
As for the payment of a contract, one possible solution is that the customer give fix-amount of money to travel agent, and the travel agent will take the difference between the payment and real cost as his/her profit. Another solution is that the customer select the agent with lowest proposed budget, and give x% of cost to travel agent for his/her service.
This idea is already used in TAC, and the idea is simple: a customer directly send its travel request to its travel agent (i.e. the customer must go to the travel agent), and the travel agent will buy a travel packages for the customer and sent it back. Note that the travel agent knows the customer's utility function and the submitted travel package does not need to be exactly the same as the user's preference. This mechanism needs following sub-interaction protocols:
FIPA Request Interaction Protocol Specification -- customer requests travel agent to buy a travel package according to the customers' travel preferences.
It allows the customer to select a propos travel agent. The customer's utility function is hided in CA side. The travel agents need to compete with each other to win a contract with the customer. The communication need the support from bulletin board. This mechanism is now running as Dynamic Contract Interaction Protocol Specification, and needs following sub-interaction protocols:
FIPA Recruiting Interaction Protocol Specification -- customer let the recruiter to send its message to the travel agents.
FIPA Propose Interaction Protocol Specification -- travel agent proposes its contract to the customer for making a contract
Note that FIPA Subscribe Interaction Protocol Specification is also used to allow travel agents to subscribe at bulletin board -- the recruiter.
A travel agent purchases goods from the Web travel market to assemble travel packages. A TAGA purchase mechanism shows how buyer and seller interact to make purchase. Three options are available:
This purchase mechanism is initiated by the seller. The seller list its goods in auction house for sale, and the buyers can buy their wanted goods by send buy bid to the auction house. In such auction, the buyer only knows partial information about the goods, i.e. the type, quality level and date, before it submits the buy bid. And the rest information, such as the seller's identity and the final price, will be discovered when the auction closes. It is possible that no buyer will by the listed goods. This mechanism is now running as Hotwire Auction Interaction Protocol Specification, and needs following sub-interaction protocols:
This purchase mechanism is initiated by the buyer. The buyer post its wanted goods in the auction house, and the sellers will check the requirement and offer price and then decide whether or not sell goods to the buyer. A seller can sell its goods by sending a sell bid to the auction house. In such auction, the sell can only specify partial requirement on the goods, such as the final price, the quality level, the type and the date. And the rest information, such as the seller's identity, will be discovered when the auction closes. It is possible that no seller wants to sell goods to the buyer. This mechanism is now running as Priceline Auction Interaction Protocol Specification, and needs following sub-interaction protocols:
Note that FIPA Subscribe Interaction Protocol Specification is also used to allow sellers to subscribe at the auction house
This purchase mechanism is initiated by the buyer. The buyer can directly buy goods from the seller. Direct Buy often cost more than auctions, however, the buyer can enjoy the benefit of receiving the goods immediately with a known price. This mechanism is now running as Direct Buy Interaction Protocol Specification, and needs following sub-interaction protocols:
FIPA Query Interaction Protocol Specification -- the buyer queries the seller for interested goods
FIPA Request Interaction Protocol Specification -- the buyer requests the seller to sell the specified goods to it for ask price.
last update 01/27/2003