encountered in online auctions are the same for mobile auctions among ... system architecture and the system functionality. ... to complete the transaction. ..... âA Next Generation Electronic Commerce Serverâ, Technical Report WUCS-99-.
Agent-Based Mobile Auctions: The Flea Market Scenario I. Khalil Ibrahim, R. Kronsteiner, G. Kotsis Institute of Telecooperation, Johannes Kepler University Linz, Austria Altenbergerstr. 69 4040 Linz Austria {ismail;reinhard;gk}@tk.uni-linz.ac.at Abstract With the proliferation of mobile devices, such as laptops, mobile phones, Personal Digital Assistants (PDA), and the fast mobile networks, mobile auctions seems to be the most compelling service that is going to revolutionize the mobile commerce landscape and make it dramatically more powerful and easier to use. Until now, mobile auctions are usually limited to be alert SMS messages sent via mobile phones to people participating in traditional Web-based auctions about their latest bids with inquires to bid higher or not. In this paper, we describe the process of auctioning goods and services using mobile devices in a flea-market like scenario. We elaborate on a prototypical process how these auctions methods, interaction requirements and other attributes can be incorporated in an agent based mobile auction.
1.
Introduction
Significant progress has been achieved toward the development of requirements and strategies for ecommerce applications. Advances in wireless communications and mobile networks have yielded in a plethora of novel mobile e-commerce applications such as mobile financial applications, mobile inventory management, proactive service management, product location and search, and wireless reengineering. According to the definition of m-commerce [14] as any transaction with a monetary value that is conducted via a mobile telecommunication network, m- commerce represents a subset of all ecommerce transactions. As a consequence, most research on mobile commerce has fallen under three categories; namely, 1) how to provide users with the possibility of accessing the Internet via a rapidly expanding array of mobile devices (smart mobile handsets, connected palmtop PCs, personal digital assistants, etc.,). According to predications, mobiles will provide the most common access to high speed Internet, thus enabling transactions and specialised information services on the move for the mass market. 2) how the specific nature of m-commerce of mobility, ubiquity, multimodality, speed and interoperability can transform the mobile communication industry into the next revolution and revenue sources for the new digital economy and 3) the technology, infrastructure, and content challenges that could hinder the development of mobile commerce services. On the other side, in order for m-commerce to be the next technology revolution and to live up to its expectations, three drivers should be considered 1) the enormous demand for affordable and interpersonal communication, 2) mobile communication to substitute or generate new tools for electronic transactions (electronic payment, reservations, information systems, portfolio management, leisure, etc.,) and 3) new, revolutionary services that are based on customer location will enable the emergence of a new brand of services that will reshape entire business and generate new revenue. With an increasingly mobile society where more and more people are on the move, mobile auctions seems to be the most compelling service that is going to revolutionize the mobile commerce landscape and make it dramatically more powerful and easier to use. Mobile auctions can be defined in the same way as traditional and Internet auctions [13] as “a market institution with an explicit set of rules determining resource allocation and prices on the basis of bids from the market participants”.
Auctions (mobile or not) can be classified in different ways [12], there are open auctions as well as sealed bid auctions. There are auctions where the bidding prices ascend and auctions where the prices descend. The most commonly used auction types are the open-cry auction (also called English auction), where auction participants gather at one location, physical or virtual, at a pre-specified time and buyers can hear the bids submitted by rival buyers and have to decide whether to bid higher or not within a limited time. In sealed bid auctions, auction participants are required to submit their bids by a specified deadline. The auctioneer keeps the bid information secret until the deadline when the bids are evaluated and the winner is declared. Sealed bid auctions can be either single round or multiple round. Dutch auctions are different. The auctioneer starts with a very high asking price. Then this price is decreased gradually until a buyer declares that he accept the asking price. These auction methods can be compared quantitatively and qualitatively [10] based on information anonymity (which information about products or people to be revealed during and after the auction), auction rules (when to start or end the auction), pricing mechanisms (whether winners pay the same price they bid for (Yankee auction) or the second highest bid (Vickrey auction). Most of the problems encountered in online auctions are the same for mobile auctions among which how to deal with unsupported bid (when a buyer submits a bid that his credit cannot guarantee. One possible solution can be fining the buyer and repeating the auction round), collision (when two or more buyers simultaneously submit the same bid. A solution can be declaring a restarting the round), expulsion (when a buyer is overdrawn and can not back up a fine, he may be sent off the market and the round restarts as usual), and withdrawal (when a buyer or a seller decides to withdraw from the market or a good didn’t get the minimum price set by the seller). In addition to the advantages of online auctions [14] , mobile auctions can offer the following advantages: • Cost effectiveness: since most people (at least in developed countries) will be equipped by some sort of mobile device at the end of 2005 [14]. • Technology power: computers and mobile phone technologies are getting more and more powerful. There are remarkable improvements in memory, battery and central processing unit (CPU) technologies allowing more advancement at incorporating powerful application and multimedia content. • Ample Bandwidth- the availability of third generation (3G) wireless technologies with greater wireless transmission speed will create widespread business or business participation • Value of the Internet access: More and more people are reenlisting the value of the Internet access for personal and professional needs. Mobile phones the most convenient way to access the Internet than being connected to the desktop. • Market share: as more and more people will be using mobile devices, the market share will be a critical factor that will make m-commerce applications the next cash cow for the digital economy. • Cellular networks: New digital cellular networks are beginning to be more capable and efficient for most Internet and Web applications. • Standardization: Wireless protocol standards (WAP) had promoted the need for standards for wireless access, while GSM and IMT 2000 will be the global mobile communication standard. • Pricing models: Flat rate pricing for Internet already been introduced but predictable fixed cost will make it easier for potential wireless data communication to take the plunge.
2.
Structure of the Paper
The paper is structured as follows; We start in section 3 with a review of the most salient agent based virtual marketplaces to highlight the similar aspects to mobile auctions. In section 4 we illustrate our approach for agent-based mobile auctions with a flea-market scenario and the modelling of the scenario using UML notation for use case and activity diagram. In section 5 and 6 we explain the system architecture and the system functionality.
3.
Agent-Based Auctions
To the best of our knowledge, there are no agent-based mobile auctions whether as commercial products or research prototypes. However, due to the similarity between online auctions and mobile auctions, we survey in this section the most salient agent-based virtual marketplaces to highlight the similar aspects to mobile auctions [1] [16]. Kasbah [2][3] is a web based and agent based consumer-to-consumer electronic marketplace. Users intending to buy or sell goods can create buying and selling agents that help them transact their product. When creating agents, users must give them some strategic direction, and afterward send them off into a centralized agent marketplace. Kasbah agents proactively seek out potential buyers or sellers so as to negotiate with them on their owners’ behalf. Thus these agents are responsible for automating much of the merchant brokering and negation stages for both buyers and sellers. Each agents arriving into the central marketplace is targeted to close acceptable deal according to a set of user-specified constrictions such as desired price, lowest (or highest) acceptable price and a deadline to complete the transaction. AuctionBot [18] is a web based flexible auction server that supports both software and human agents. AuctionBot is cable of managing a large number of simultaneous auctions, which are organized in a hierarchical catalog. The user initiating an auction can position it anywhere within the exiting catalog, or extend the catalog to create an appropriate strategy. The most distinguishing, interesting feature of AuctionBot is that it manages a wide range of auctions types by decomposing the auction design space into a set of orthogonal parameters .Based on such parameters, the classic auctions types can be generated, plus others that have not been studied yet. Zeus [5] is not a computational market, but an agent building toolkit that has been successfully employed for constructing a virtual electronic marketplace. The resulting marketplace was developed as a virtual commodity auction with a variable number of agents capable of buying and selling items. The marketplace is open, with an indeterminate number of participating agents spread across a LAN (local area network). This is different from Kasbah, Fishmarket and AuctionBot, which all allow for agents to be distributed over the web. MAGNET [4] is a computational market designed to act as an intermediary for multi agent negotiations. It implements a generalised multi agent market architecture that provides explicit and integrated support for complex multi agent interactions; from complex negotiations to simple auction protocols. eMediator [17] is a web-based electronic commerce server that includes: An auction house, the so called e-AuctionHouse that allow users from across the Internet to buy, sell and set up auctions; A leveled commitment contrast optimizer that determines the optimal contract price and decommitting penalties for a variety of leveled commitment contracting protocols; and a safe exchange planner that enables anonymous exchanges by dividing the exchange into chunks and sequencing those chunks to be delivered safely in alternation between the buyer and the seller. FM96.5(Fishmarket) [6][7][16] is an open flexible robust agent based auctions house where heterogeneous (software and human) agents may trade. Along with AuctionBot, it was the first auction house providing support to software agents. In order to assist agent developers in the construction of their agents, FM96.5 encloses a library of agents templates in several languages. Furthermore, it also offers the possibility of generating agents with customized trading strategies likewise. The criteria for the comparison between agent-based mobile auctions and web-based auctions is beyond the scope of this paper but it generally speaking depends on the organizational architecture of the marketplace which decide the distribution of agents, the kind of support provided to trading agents, negotiation protocols, auction protocols, seller buyer cardinality (number of potential buyers who will be in competition for one item), merchant brokering (how buyers know who is selling the item they desire), mobility of agents, credibility and reputation of trading agents, and the monitoring and debugging facilities [16].
4.
Flea Market Concept
In order to illustrate our approach for agent based mobile auctions, we will use a specific scenario. This scenario illustrates a number of important characteristics that must be taken into account in the development of an agent based computational markets [15]. First, there maybe multiple services available from a number of agents representing independent participants. Multiple agents may offer broadly similar services. The services themselves are described by multiple attributes; for example, price, quality and delivery time. The services available may change over time: new services may become available, or agents may alter the way in which existing services are offered. Services may differ in terms of the number and heterogeneity of the tasks involved in the delivery of the service and their degree of independence, and the type and frequency of interactions between different customers while the service is being delivered. With these issues in mind, we consider a flea-market scenario. Flea markets are quite popular in Europe. An important characteristic of traditional flea markets is that they are only available on a certain day and for a certain time. Then, walking around takes time and energy, as one has to carefully scrutinize what is available. And finally, the different roles (buyer and seller) are clearly separated [8]. Consider a flea market that takes place at a certain place. Potential customers are walking around searching for specific products and negotiate the price for them. Sellers want to sell their goods to the highest possible price to the customers in an auction like manner. Sellers need to join the flea-market place and define the goods to sell with certain properties. In the case of more than one customer interested in the same item, customers start bidding for the good in an auction style. As soon as the negotiating is over (no higher bid is available) the settlement of the business case starts. What makes this scenario different from other scenarios and make it more suitable for the study of the role of agents in the integral value added chain of mobile business is the following: • Role partitioning: Each participant can act as a seller and as buyer at the same marketplace at the same time. The set of participants is not predefined in the meaning that it is possible to join or leave the flea market at specific point or specific time. • Parallelism: The process typically runs in parallel (different products are sold to different customers at the same time). This includes the risk that the buyer of a product is not clear, but much more that one buyer negotiates for two products and exceeds his financial limit when his bid is accepted for more than one product. • Uncertainty: The set of participants in a specific business case is fluctuating (potential business partners are continuously joining and leaving each other). 4.1. Modelling Agent-based Mobile Auction: According to the above scenario, the following use case diagram helps to have a better idea of the fundamental features of our scenario
Figure 1: The Bidding use case
As can be seen in Figure 1, the flea market has three actors and eight different use cases. •
Marketplace: The marketplace is the container for a set of auctions with their state (running, rolling back, closed).
•
Auction Participant: An auction participant can be a Seller or a buyer. Each participant needs to register for the marketplace.
•
A seller is a seller because he gave a set of products for sale to the marketplace. He must be able to register a product with its detailed information.
•
A customer has no product in the auction queue but can own product he bought in the auction.
•
A product is something sold via an auction on the marketplace. A product can be owned by a seller when it is part of a running auction. A product is owned by a buyer when it is already sold
Every participant of the flea-market registers with details about his name and preferences. Participants with products to sale register their products at a dynamic market-place. They setup product specific properties including product description and category, auction strategy (minimum price, temporal restrictions) and salesman specific properties (bank account used for transactions, topic related excellence,…). Potential customer (including salesman that act as customers) join the market place and search for products categories specified in their wish list. Taking into account the users wish-list the customers are navigated to the salesmen selling adequate products in auctions actually running. The time constraints are necessary to handle multiple auctions at the same time and to finish business before the customer decides to leave the flea-market. After product inspection the customer specifies upper limits and time constraints for products he want to bid for. The upper limit is strongly affected by the bank account (or the money that the product seems worth to the customer). The seller needs to receive notification for each bid according his goods. The customer receives the actual bid for each auction which he is also participating with the option to overcome this bid if it is within his financial constraints. The acceptance of a bid by a seller leads to direct communication and settlement between seller and buyer. Financial transactions are handles via mobile devices, also the bidding / negotiating process is handled by mobile devices to complete the virtual market-place. 4.2. Activities in the scenario: • Registration at flea-market: Every action of joining the flea-market community starts with registration. A participant needs to register the flea-market with his personal data (as account number) to be identified and grab able (catch able in case of troubles) for the system. • Seller activities
•
Seller - Product registration: If a product should be sold at the flea-market it needs to be registered in the system. The product registration includes the owner, product description to search for, minimum auction price.
•
Marketplace - Auction queue: The auction queue is a permanent activity that handles the state of the single auctions (starting / closing them, receive bids for auctions, handle exceptions, initiating settlement)
•
Seller - Auction setup / start: To sell a product in an auction, the actual auction needs to be included in the (container of the) market place. There the auction and auction specific parameters (type of auction; Dutch, English), duration of the auction, notification frequency, bid step (how much the next bid needs to overcome the actual bid).
•
Seller - Receive bid: To receive a bid from a customer according to a specific product. The auction queue needs to assign the bid to a specific product, check if the bid is valid and send a notification about a valid bid to the customer.
•
Seller - exception handling: Exceptions need to be identified and handled. E.g. if a conflict occurs in the auction a customer bids less than other customer already bid, because his notification about the higher price was late, or a customer exceeded his financial limit because his bid was accepted for two products, or a customer leaves the auction although he didn’t finish the settlement process the flea-market needs to act with either an optimistic exception handling or a pessimistic exception handling. E.g. the market can just allow complete transactions before publishing their effect, or the market needs a sophisticated rollbackmechanism to correct errors.
•
Seller – notification: After each bid for a product the customer that are part of the auction (joined the auction and did not leave it) need to be informed about the actual state of the auction. Also the salesman needs to be informed about the actual price of the auction and the remaining potential business partners.
•
Seller - Auction close: An auction can be closed after a specific time (auction under time restrictions because the salesman needs to leave the location) or after a specific time without any higher bids (the product is sold). Closing an auction can also lead to transactions.
•
Initiate settlement: The validity of information about salesman and customer need to be checked before definitely sell the product (if there is enough money available). Then the financial transactions need to be started and the product logistic (delivery of the product) need to be negotiated and initiated.
• Customer Activities •
Customer - search: After entering the flea-market a customer searches for products. For this he needs to configure a wish-list with rankings of most wanted products and limitations for them (usually financial limitations). Then the customer needs to query the market place for adequate products sold there.
•
Customer join auction: After the search the customer joins auctions according to products he wants knowing about his limitations (temporal and financial limits). The customer is now in the notification queue of this auction and gets informed about the actual price and whenever someone else overbids his highest bid. This notification can be done frequently after a certain time. Or on demand (just when the price changed).
•
Customer – bid: A customer frequently gets informed by notification of the seller what the actual price of the product is. The customer needs to process this information if he is allowed (or wants) to overcome this bid. He needs to decide how high he wants to overcome this bid by staying still behind his limited financial resources. In other cases the customer leaves the auction.
•
Customer leave auction: The customer leaves the auction when he (according his limits) can’t buy the actual product any more. In this case he needs to be unregistered from the auction queue so that he does not receive any more notifications, and is not “responsible” any more when a rollback (in cases of errors) happens.
The activity diagram of the auction part in our scenario is shown below Seller
Buyer
Register Participant
Register Participant
Register Product
Configure Preferen ces
Configure product constraints
Define Type of Auction Define Time Constraints
Configure price constraints
Define Price Constraints Search running Auctions
Check product constraints Start Auction
Send actual bid
Join Auctions
Receive actual bid
Check price constraints
Receive bid
Handle Exceptions
Notify buyer
Send bid
Initiate Settlement Actualize price
Close Auction
Figure 2: Activity Diagram of a typical Auction
5.
Architecture Overview
An agent based approach for developing truly distributed systems offers in general better abilities to design flexible, adaptable and mobile software solutions [11]. The reasons why agents seems to be the most appropriate in the context of the flea market scenario is that agents have the capability to provide flexible and personalized user interaction, have low demand on network bandwidth which is the main constraint in mobile and wireless communication, the proactivity of agents [9] will enable them to autonomously find relevant information and act of behalf of their use, in addition to the fact that such a solution can be adapted to different kinds of scenarios. Our application consists of a number of principally equal agents in the sense that they are built on the same basic architecture principles (Figure 3). Each of the agents has the capability to sell/buy goods and to bid for products. To do this they need a communication module, a decision-making module and a coordination module and a pool of objects to store information about the goods to be sold or bought. Communicator: The communication engine is responsible for the agents’ interaction with other agents and with the marketplace. It sends and receives information from the marketplace and from other agents (in their role as seller). The messages will be parsed and delivered to the decision-engine. Decision finder: The decision finder looks for the most benefit of the agent. Consequently we need to different decision finder. One for the seller who wants to get the best value for his products (sellerengine), and one for the buyer who wants to pay as less money as possible (buyer engine). Each agents includes both parts and uses them depending on its actual situation.
Coordination module: The coordination module is responsible for the cooperation between seller and buyer agents as well as the market place. The coordination module interacts with communicator and decision finder through message exchanges Objects pool: Is the database where to keep records of products’ specification together with an indication whether the value of a specific feature.
Figure 3: Agent-based mobile auction system architecture
6.
System Functionality
A prototype is under development to evaluate the benefits of using Microsoft .NET to build an agentbased mobile auction flea market scenario. The application consists of web page application, phone call application, which is the standard WAP application, and also additional application such as email and database access. In order to demonstrate the basic elements of the system functionality, a stimulation has been developed. Due to space limitations, the discussion is limited on the front end. The prototype shows a limited implementation of the flea-market scenario. Simplification is done in the registration process (just the name needs to be entered) and the limitation to one type of auction (just dutch-type auctions are supported). The user enters the flea market: Entering the flea-market starts with the users authentication. In our prototype we simplified the authentication process and limited it to the users name (Figure 4.a) . Already during this step a list of available product categories can be downloaded, with name and the number of available goods at each category. If the user just participates as a buyer at the auction, he needs to select product categories he is interested in and check for running auctions (“Check auction”). If the user wants to act as a seller he can go on to offer his goods (“Offer product”). Offering a product: If the flea-market participant decides to offer his goods, he can configure the details of the auction. It is necessary to give the product a name and classify it into one of the predefined product categories. The screen (Figure 4.b) shows and dutch-type auction, with a price to start the auction, an under limit where the auction is cancelled and the step-size to decrease the actual bid (as price constraints). Also the time constraints for the auction are configured in this screen. Select auctions to participate: The user receives a list of actually running auctions (Figure 4.c) in the product-categories he selected. For each running auction the auctioneered good, the seller and the time left till the end of the auction is listed. By checking a set of auction the user can participate on them (“Enter Auctions”) or change his general preferences (product categories interested in (“Registration”).
Auction details: This interface shows the details of the running (and selected) auctions including the actual auction price of the selected products (Figure 4.d). Here the user can bid for a specific good if the auction is still running. The bid will be transmitted to the seller of the product. Changing bids of other potential buyers are updated in this screen. Bid notification: Every bid by an auction participant that acts as a potential buyer for a specific product is transmitted to the seller of the product. The name of the potential buyer, his actual bid, the description of the product and its price constraints are listed (Figure 4.e). The seller now needs to accept the bid (“Accept”) or decline the offer out of any reason (“Decline”). As soon a bid is accepted by the seller the good is deleted from the lists of open auctions at any participating device. Acceptance notification: Once a bid is accepted by the seller the buyer is informed with an acceptance notification (figure 4.f). This notification includes the details of the offer and encourages the buyer to get in contact with the seller of the good for detailed settlement.
a) User registration
b) Product Registration
c) Auction Selection
d) Bidding
e) Offer Notification
f) Acceptance Notification
Figure 4: Screenshots of the Prototype
7.
Conclusion
In this paper we have elaborated on a prototypical system for an agent-based mobile auction scenario where software agents are deployed over mobile devices. The purpose of the paper was to highlight how auction methods, interaction requirements and other attributes of online auctions can be incorporated in mobile environment. Different requirements of the future deployment of the system which are mostly technology and infrastructure related such as information provisioning, networking, agents mobility, security and transaction enabling requirements have not been discussed. We have built a prototypical solution to support our scenario in a simplified manner.
8.
References
[1]
J. Béjar and J.A. Rodríguez-Aguilar, “To Bid or not To Bid – Agent Strategies in Electronic Auction Games”, Lecture Notes In Computer Science, Springer 2001, pp173-192
[2]
Chavez, D. Dreilinger, R. Guttman and P. Maes, “A Real Life Experiment in creating an Agent Marketplace”, Proc. Of the 2nd International Conference on the Practical Application of Intelligent Agents and Multi-Agent Technology, PAAM 1997.
[3]
Chavez and P. Maes. “Kasbah: An Agent Marketplace for Buying and Selling Goods”, Proc. Of the 1st International Conference on the Practical Application of Intelligent Agents and Multi-Agent Technology, PAAM 1996.
[4]
J. Collins, B. Youngdahl, S. Jamison, B. Mobasher and M. Gini, “A Market Architecture for Multi Agent Contracting”, Proc. Of the 2nd International Conference on Autonomous Agents (AGENTS98), pp. 285-292.
[5]
J. Collins and L.C. Lee, “Building Electronic Marketplaces with the Zeus Agent Toolkit”, In P. Noriega and C. Sierra(eds.) Agent Mediated Electronic Commerce, Lecture Notes in Artificial Intelligence, No. 1571, 1998.
[6]
Faculta d´Informatica de Barcelona http:// www.fib.upc.es
[7]
The Fish-Market Project. http:// www.iiia.csic.es/Projects/fishmarket
[8]
Garbinato and P. Rupp, “From Ad-hoc Networks to Ad-hoc Applications”, ERCIM News, No. 54, July 2003.
[9]
N. Karacapilidis and P. Moraitis, “Building an Agent-mediated Electronic Commerce System with Detection Analysis Features”, Decision Support Systems, Vol. 32, Elseview 2001, pp 53-69.
[10]
G.E. Kersten, S.J. Noronha and J. Teich, “Are All E-Commerce Negotiations Auctions?”, Proc. Of COOP 2000 4th International Conference on the Design of Cooperative Systems, Sophia-Antipolis, France, May 2000.
[11]
R. Kowalczyk, P. Braun, I. Mueller, W. Rossak, B. Franczyk and A. Speck, “Deploying Mobile and Intelligent Agents in Interconnected E-Marketplaces”, Transactions of the SDPS, Vol. 7, No. 3, Sept. 2003, pp109-123.
[12]
M. Kumar and S.I. Feldman, “Internet Auctions”, Proc. Of 3 rd USENIX Workshop on Electronic Commerce, 1998, pp 49-60.
[13]
R.P. McAfee and J. McMillan, “Auctions and Bidding”, J. Ec Lit., XXV:699-738, June 1987.
[14]
F. Muller-Veerse, “Mobile Commerce Report”, Durchlacher Cooperation 1999
[15]
T.J. Norman, A. Preece, S. Chalmers, N.R. Jennings, M. Luck, V. Deora, J. Shao and N.J. Fiddian, “CONOISE: Agent-based Formation of Virtual Organisations”, International Journal of Knowledge Based Systems, Feb. 2004.
[16]
J.A. Rodriguez-Aguilar, “On the Design and Construction of Agent-Mediated Institutions”, PhD thesis, Institut d´Investigació en Intelligencia Artificial, 2000.
[17]
T. Sandholm, “Emediator: “A Next Generation Electronic Commerce Server”, Technical Report WUCS-9902, Washington University 1999.
[18]
P.R. Wurman, M.P. Wellman and W.E. Walsh, “The Michigan Internet Auction Bot: A Configurable Auction Server for Human and Software Agents”, Proc. Of 2nd International Conference on Autonomous Agents (AGENTS1998), p. 301-308.
