MIT Sloan School of Management
Sloan Working Paper 4188-01
eBusiness@MIT Working Paper 114
October 2001
AUTOMATED NEGOTIATION FROM DECLARATIVE
CONTRACT DESCRIPTIONS
Benjamin Grosof, Daniel M. Reeves, Michael P. Wellman
This paper is available through the Center for
eBusiness@MIT web site at the following URL:
http://ebusiness.mit.edu/research/papers.html
This paper also can be downloaded without charge from the
Social Science Research Network Electronic Paper Collection:
Publishing Information:
Grosof, Benjamin, Reeves, Daniel M., Wellman, Michael P., “Automated Negotiation
from Declarative Contract Descriptions”, Proc. Fifth International Conference on
Autonomous Agents, May 28-June 1, 2001.
Automated Negotiation from Declarative Contract
Descriptions
Daniel M. Reeves
Michael P. Wellman
University of Michigan Artificial Intelligence Lab.
1101 Beal Avenue, Ann Arbor, MI 48109 USA
ai.eecs.umich.edu/people/{dreev es,w ellm an}
/
fdreeves,wellman
g@umich.edu
Benjamin N. Grosof
MIT Sloan School of Management
50 Memorial Drive, Rm E53-317
Cambridge, MA 02142 USA
www.mit.edu/~bgrosof/
bgrosof@mit.edu
ABSTRACT
Our approach for automating the negotiation of business contracts proceeds in three broadsteps. First, determine thestructureofthenegotiationprocessbyapplyinggeneral knowledge about auctions and domain-specic knowledge aboutthecontractsubjectalongwithpreferencesfrom po-tentialbuyersandsellers. Second,translatethedetermined negotiation structure into an operational specication for anauction platform. Third,mapthe negotiationresultsto anal contract. We have implemented aprototypewhich supportsthese steps, employing adeclarative specication (inCourteousLogic Programs)of (1)high-levelknowledge about alternative negotiation structures, (2) general-case rulesaboutauctionparameters,(3)rulestomaptheauction parametersto aspecicauction platform,and (4) special-case rules for subject domains. We demonstratethe exi-bility ofthis approachby automatically generating several alternative negotiation structures for a previous domain: travel-shoppinginatradingagentcompetition.
1.
INTRODUCTION
Oneformofcommercethatcanbenetsubstantiallyfrom automationiscontracting,whereagentsformbinding, agree-ableterms,andthenexecutetheseterms. Theoverall con-tractingprocesscomprisesseveralstages,includingbroadly:
1. Discovery. Agentsndpotentialcontractingpartners.
2. Negotiation. Contract termsare determinedthrough acommunicationprocess.
3. Execution. Transactionsandothercontractprovisions areexecuted.
Inthis work we areconcerned withbridgingthese three stages, and primarilywith the process by which an auto-matednegotiationmechanismcanbeconguredtosupport
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
AGENTS’01, May 28-June 1, 2001, Montr´eal, Quebec, Canada.
Copyright 2001 ACM 1-58113-326-X/01/0005 ...
$5.00.
a particular contracting episode. We begin by presenting a shared language withwhich agents candene the scope and content of a negotiation, and reach acommon under-standing ofthe negotiationrules and thecontract implica-tions of negotiation actions. Note that we are concerned herewiththedenitionofnegotiationmechanismsandnot thenegotiationstrategiesemployedbyparticipatingagents, thoughindesigningamechanismonemustconsiderthe pri-vate evaluation and decisionmaking performed by each of thenegotiatingparties.
Ourprototypesystemforautomatedcontractingiscalled ContractBot.
1
By starting from a formal description of a partial contract|describingthe space of possible negotia-tion outcomes|ContractBot automatically generates con-guration parameters for anegotiation mediator (auction) platform. Then, by monitoring the individual auction re-sults,itgeneratesanal,executablecontract.
Section2givesanoverviewofourapproachtoautomated contracting. Section 3 provides background on auction-basednegotiation. Section2.3framestheoverallprocessof automatedcontractnegotiationandshowshowrules gener-ated during thenegotiation processcan becombinedwith thepartialcontracttoformanexecutablenalcontract. In Section4,wediscussindetailhowthelanguageisused to inferparametersforconguringthenegotiation|thatis, pa-rametersforasetofauctions-. WefocusonaTradingAgent Competition[15]asanexampledomain(Sections5and6). Finally,inSection7,wediscussdetailsofourprototype.
2.
CONTRACTBOT FRAMEWORK
Thecentralquestioninconguringacontractnegotiation is,\Whatistobenegotiated?" Inanycontractingcontext, somefeaturesofthepotentialcontractmustberegardedas xed,withotherstobedeterminedthroughthecontracting process. At oneextreme,thecontractisfullyspecied, ex-ceptforasingleissue,suchasprice. Inthatcase,the negoti-ationcanbeimplementedusingsimpleauctionmechanisms ofthesortoneseesforspeciedgoodsontheInternet. The otherextreme, where nothingis xed,is tooill-structured toconsiderautomatinginthecurrentstateoftheart.
Mostcontractingcontextslieinbetween,wherean iden-tiablesetofissuesistobedeterminedthroughnegotiation. 1
A complete version of the prototype, including rule-sets required for the examples described in this paper, is available at http://ai.eecs.umich.edu/people /dree ves/ contractbot/.
Naturally, thereis a tradeo between exibility in consid-ering issues negotiable and complexity of the negotiation process. Butregardless ofhowthistradeo isresolved,we requirea meanstospecifytheseissues so that we can au-tomaticallycongurethe negotiationmechanismsthat will resolvethem. Thatis,werequireacontracting language.
Ourapproachusesaformoflogic-basedknowledge repre-sentationto represent contractsandextends thislanguage toexpressand reason about partial contracts. Thepartial contract,orcontracttemplate,describespossiblenegotiable parametersandhowtheyareinterrelated,alongwith meta-levelrules aboutthenegotiationandaboutindividual auc-tions. It combines all this with rules from agents about theirconstraintsandpreferences overthe possible negotia-tionstructures. Fromimplicationsoftherules,itgenerates theappropriateauctionsanddeterminestheauction param-eters. Transactionsintheauctionsgenerateadditionalrules, whichproduceresultsforthenalcontract. Aspartofthis newframework, ourapproachallows forreuseofthe infor-mationinmultiplestagesofthecontractingprocess.
2.1
Contracting Language
Thatour languagemustsupportall threestages of con-tracting (discovery, negotiation, and execution) is one ar-gumentfor adoptingadeclarativeapproach. \Declarative" here means that the semantics say which conclusions are entailedbyagivensetofpremises, withoutdependenceon procedural or control aspects of inference algorithms. In additionto exibility,suchanapproachpromotes standard-ization,humanunderstandability,andinformationreuse.
Traditionally, contracts are specied in legally enforce-ablenaturallanguage(\legalese"), asinatypicalmortgage agreement. Attheotherextremeareautomatedlanguages for restricted domains (e.g., ElectronicData Interchange). Inthese,mostof themeaningisimplicitintheautomated representation. We are in the sparsely occupied middle ground, aiming for considerable expressive power butalso considerableautomatability.
We adoptas our underlying representation of contracts setsofbusinessrulesexpressedasCourteousLogicPrograms (CLPs) [7, 8]|a language well-suited to expressing busi-nesscontracts. The rules mustspecify the goods and ser-vicestobeprovided,alongwithapplicable termsand con-ditions. Such terms include customerservice agreements, deliveryschedules,conditionsforreturns,usagerestrictions, andotherissuesrelevanttothegoodorserviceprovided.
2.2
Configuring Auctions
ContractBotconguresauctionsbasedonrulesaboutthe contractandaboutthenegotiation,aswellasgeneral back-groundknowledgeabout auctionconguration itself. This backgroundknowledge(describedindetailinSection4) in-cludesrulesdening:
1. The process of generating suites of auctions for ne-gotiation of multipleparameters,and foraggregating agent preferencesaboutwhichauctionstogenerate.
2. Behavioral elements of individual auctions [17], and relationshipsamongtheseelements.
3. Means of specifying these behaviors for a particular auctionplatform.
Contract Template
Rules
Implementing
Agreement
("proto-contract")
Negotiation-level
Rules
Executable Contract
Transaction
Facts (buyer,
seller, price, qty,
other attributes)
Rules
Implementing
Agreement
("proto-contract")
Negotiation
Mechanism
Figure 1: Overall contracting process, partial to complete contract.
Tocongureasetofauctionsforaparticulardomain,we incorporateadditionalrulesfromthecontracttemplateand from potential buyers and sellers. These rules, combined with the background knowledge about auction congura-tion,are used to inferthe actual auctionparameters for a suiteofauctionsthatwillimplementthechosennegotiation structure.
2.3
Overall Contracting Process
Thecontracttemplateisessentiallyadeclarative descrip-tionofthespaceofpossiblenegotiationoutcomes,with ad-ditionalrulesforin uencingthestructureofthenegotiation andhowitwillbecongured. AsshowninFigure1,the con-tracttemplatecomprisesrulesthatwillimplementthenal agreement(theproto-contract),alongwithrulesdescribing the contractissuesto benegotiated(the\negotiation-level rules").
Theproto-contractreferstofactsandconditions regard-ing mechanicsofthedeal (e.g.,paymentanddelivery) and ancillary agreements such as return policies or provisions for failure ofoneparty. Itis the partof the contract that carries over unchanged into the nal contract, and which combineswiththe facts outputby the negotiation mecha-nismtoresultinanexecutablerulesetthatimplementsthe agreement. We point out, however, that this distinction neednotbesharp. Infact,animportant advantage ofour rule-based representation language is the ability to re-use rules and reason about them on dierent levels. Rules in theproto-contractthatimplementsomeaspectofthenal dealmayalsobeusedindetermininganappropriate negoti-ationmechanism. Forexample,timeconstraintsondelivery maydictateauctionnalclearingtimes.
Thenegotiation-levelrulesaddressbothquestionsofwhat is to be negotiated, and how. Rules describing ways that thecontractissuesmay bepartitionedintoseparable com-ponentsdenethespace ofpossiblegoods tobenegotiated at auction. Rules referring to policies for negotiating in-dividual components dene the auction behaviors for the correspondinggoods.
Thekeystepinthisprocess|bridgingthediscoveryphase (thepartialcontract)andthenegotiationphase(setof auc-tions)|is the conguration of the negotiation mechanism basedoninferencefromthecontracttemplateandrules sub-mittedbyagents.
After ContractBot congures and generates the suite of auctions,itmonitorstheauctions,waitingfortransactions. Eachtransactiongeneratesafactspecifyingwhichaspectof
sellerwere,andthepriceandquantity. Theproto-contract containsrules thatmakeuseofsuchtransactionfactsonce theyarelledin. Atypicalruleintheproto-contractmight beto say that the amount paidby agentX to agent Y is thesumofthepricesinalltransactionsinwhichX bought fromY minusthe sumof transactions inwhich Y bought fromX.
Finally, after the setof auctions are congured and run andthenegotiationphaseiscomplete,wecanautomatically entertheexecutionphasebygeneratingthenalcontractas afunctionoftheproto-contractandtheauctionresults. The actualexecutionofnalcontractsisthesubjectofprevious work[8].
3.
AUCTION-BASED NEGOTIATION
Mechanismsfor determiningprice andother termsofan exchange are called auctions. Althoughthe most familiar auctiontypesresolveonlyprice,itispossibletodene mul-tidimensionalgeneralizationsthatresolvemultipleissuesat once. This can range from a simple approach of running independentone-dimensionalauctions,tomorecomplicated approaches that directly manage higher-order interactions amongtheparameters.AuctionshaveprovedapopularmediumforInternet com-merce.
2
Althoughtypicalconsumer-orientedonlineauctions supportsimplenegotiationservices,business-to-business dy-namic trade applications have begun to exhibit advanced capabilities previously found in researchsystems. For ex-ample,somecommercialauctionplatformssupportthe con-gurabilitycharacteristicoftheMichiganInternet Auction-Bot [16],
3
and several integrate auctions with other com-mercefacilities,asdemonstratedbyanIBMauction proto-type[9].
Althoughmultidimensionalmechanismsaremore compli-cated,andnotyetwidelyavailable,weexpectthattheywill eventuallyprovideanimportantmediumforautomated ne-gotiation. In particular, combinatorial auctions allow bid-derstoexpressoersforcombinationsofgoods,and deter-mine anallocation that attemptsto maximize overall sur-plus. We are aware of one prototype system that oered generalcombinatorialauctionsovertheInternet[13]. Mul-tiattribute auctions,typicallyemployedinprocurement, al-lowspecication ofoersreferringtomultipleattributesof asinglegood[3].
Whether a multiattribute auction, a combinatorial auc-tion, or an array of one- or zero-dimensional auctions
4 is appropriatedependsonseveralfactors. Althoughafull dis-cussionis beyond thescopeof thispaper, we observe that thesefactorscanbearonanyof:
Thecoherenceofauctioncongurations. Forexample, ifsome attributesare inseparable(say,size andcolor of a good), then it makes nosense to treat them as separategoodsinacombinatorialauction.
The expected performance of auction congurations. Forexample,ifparametersrepresentdistinctand sep-2
Asofthiswriting,eBayalonehasovervemillion concur-rentlyrunningauctions.
3
http://auction.eecs.umich.edu 4
A zero-dimensional auction is one that determines only price. A one-dimensional auction determines price and quantity.
eitherbyseparateorcombinedauctions. Iftheoptions are consideredbynegotiating agentsto be substitut-able,thenseparateauctionswill likelyworkwell[10]. Iftheyarecomplementary,thencombiningthemmay proveadvantageous.
Thecomplexity ofauctioncongurations,forboththe mechanisminfrastructureandparticipatingagents. InSections4.1and5wegiveexamplesofthesupportthat the current ContractBot provides for reasoning about the above criteria and choosing among alternative negotiation mechanisms.
4.
COURTEOUS LOGIC PROGRAMS FOR
GENERATING AUCTIONS
In addition to instance-specic rules from the contract template, our conguration process employs three sets of rules encoding background knowledge about the space of possiblenegotiationmechanisms.
4.1
Auction Configuration
TheAuction-Conguration rulesetdenes theprocess of collectingallpossibleattributecombinationsfornegotiable components,andgeneratingauctionsforeachpointinthis space.
5
It generatesvalueTuple predicates forevery com-binationof attributevalues,noting whichcomponenteach belongsto. Itthencreatesanauctionfor eachofthevalue tuples, and theparameters for thoseauctionsinherit from the parametersfor the parent component. In addition to determiningthesetofauctionsforaparticularcomponent, Auction-Congurationhelpsdeterminehowtopartitionthe negotiation into components. For example, as part of the inference for determiningpriorities foreachof several pos-siblecomponentswecomputea\userinterestscore"which isthetotalnumberofusersinterestedinthecomponent,or zeroifthereisnotatleastonebuyerandoneseller: <m> userInterestScore(?Component, ?N) <-numBuyers(?Component, ?NB) AND numSellers(?Component, ?NS) AND ?N is ?NB + ?NS. <high> userInterestScore(?Component, 0) <-numSellers(?Component, 0). <high> userInterestScore(?Component, 0) <-numBuyers(?Component, 0).
Intheruleexampleabove,thearrow(\<-")indicates\if" and the\?" prex indicatesalogicalvariable. Rulelabels are speciedwith angle brackets (< >). Thesyntaxis de-scribed indetail inthe documentation for IBM Common-Rules[1],theimplementationofCourteousLogicPrograms weemploy. AlsoincludedinAuction-Congurationarerules governingtheprioritiesof otherrules. Itisfrom these pri-ority rules that we know,for examplethat the rule labels intheexcerptabovehaveprioritysuchthatsettingascore tozerowhentherearenobuyersorsellersoverridessetting thescoretothesumofthenumberofbuyersandnumberof sellers(therulelabel\m"referstomediumordefault prior-itywhichislessthan\high"). Con ictresolutioninCLPs isdiscussedindetailinpreviouswork[7].
5
Moreadvancedauction types(Section3)willallowfor al-ternativewaystohandlemultipleattributes.
4.2
Auction Space
Auction-Space provides basicknowledgeabout the para-metrization of the space of possible auction mechanisms, as wellas defaults for auction parametersand constraints among them. The parametrization is motivated by that employed by theAuctionBot [16] andbyanextended and generalizedparametrizationinmorerecent work[17]. The defaultvaluesfor parametersare labeledas lowestpriority rules sothat parameters inferred basedonspecic aspects ofanegotiation willtakeprecedence. Forexample,the fol-lowingrulesspecifythatbydefault,anyauctionshouldhave multiplebuyersandoneseller,andthattiesforwinningbids shouldbebrokenbyrst-in/rst-out.
<lowest> auction(multipleBuyers, true). <lowest> auction(multipleSellers, false). <lowest> auction(tiebreaking, fifo).
We also specify conditional defaultparameters. For ex-ample,ifweknowthat anauctionhas asinglebuyerthen, bydefault,itshould havemultiple sellers. (Note that con-ditionaldefaultshavehigherprioritythandefaults.)
<verylow> auction(?ID, multipleSellers, true) <-auction(?ID, multipleBuyers, false).
Constraintsaresimilartoconditionaldefaultsexceptthat they have overriding priority. For example, if there is a biddingrulethatsaysonemustbeatthecurrentquote,then thisimpliesthatthebidmustmeetthequote(i.e.,a greater-thanruleimpliesagreater-than-or-equalrule).
<highest> auction(?ID, meetQuote, true) <-auction(?ID, beatQuote, true).
ThenegotiationType predicate isused inacontract to aggregateauction parametersandspecifyhowtonegotiate particularcomponents.Auction-Spacemapssuchdirectives to more specic auction features. Note that negotiation-Types can entail other negotiationTypes but that the in-ference must propagate conclusions to auction predicates eventually. For example, negotiationType(continuous) implies, among other things, negotiationType(continu-ousClears)whichinturnimpliesauction(quoteMode,bid). One particularly usefulfeature of Auction-Space is that itencodesseveralwell-knownauction types. For example, specifying a negotiation type of \CDA" is all that is nec-essarytoinferall the characteristics ofaContinuous Dou-bleAuction[5]|chronologicalmatching,continuousquotes (bid-ask)andclears, double-sided,anddiscretegoods.
<m> auction(?ID, matchingFunction, earliestTime) AND negotiationType(?ID, continuous) AND negotiationType(?ID, double) AND auction(?ID, divisible, false) AND auction(?ID, quoteMode, bidAndAsk) <- negotiationType(?ID, cda).
The con ict resolution that CLP provides is also useful here. For example, it allows specifying that an \Amazon-style"auctionis justlike\eBay-style"except thatAmazon auctions do not close until ten minutesof inactivity have passed.
6 6
Incidentally, this dierence turns out to have a marked eectonagentstrategies.[12]
Figure 2: An example of an inheritance hierarchy encodedin theAuction-Space ruleset.
<ebay> auction(?ID, matchingFunction, mthPrice) AND auction(?ID, multipleBuyers, true) AND auction(?ID, multipleSellers, false) AND negotiationType(?ID, revealAll) AND ...
auction(?ID, finalClearMode, fixed) <- negotiationType(?ID, ebay).
negotiationType(?ID, ebay) <-negotiationType(?ID, amazon).
<amazon> auction(?ID, finalClearMode, inactivity) AND auction(?ID, finalClearInactivityInterval, 600)
<- negotiationType(?ID, amazon).
overrides(amazon, ebay). /* Amazon rule is an exception */
Inourimplementationweincludeadditionalrulesforthe caseofthestandardEnglishauctionasamoregeneraltype, andincludeeBayasaspecialcase. Theresultisathree-level hierarchy,showninFigure2.
4.3
Auction Server Mapping
Basedonparameters concludedfromAuction-Space, we needtodriveaspecicauctionserver. AuctionBot-Mapping isaparticularsetofrulesforderivingAuctionBot parame-tersfromthegeneralizedandextendedparametrization pro-videdbyAuction-Space. Separatingtheserver-specic rule-setallowsforgreat exibilityininferringnegotiation mecha-nisms,allows ustocopeelegantlywithshortcomingsinthe AuctionBot parametrization, and facilitates connection of ContractBottoalternativeauctionplatforms.
4.4
Domain-specific Rules: Widget Example
Considerasimplecontractinvolvingonlyonecomponent (awidget)withonlyoneattribute(quality)withtwo possi-blevalues(regularanddeluxe).component(widget).
attribute(widget, quality). possValue(quality, regular). possValue(quality, deluxe).
Thepossiblevaluesarenottiedtothewidgetcomponent becauseingeneraltheymightapplytomorethanone com-ponent inthe contract. The following general rulecreates possValue/3 rules for each component based on the gen-eralpossValue/2rulesandthecomponentsthathavebeen declared:
possValue(?Component, quality, ?Q)
tributes(price, quantity,andquality)butthecurrent Auc-tionBotsupports onlysingle-dimensional auctions (negoti-atingpriceandquantity).One(ratherbrute-force)method fordealing withthisis tosimplycreateanarray of single-dimensionalauctions, onefor eachpoint inattribute-value space.
7
Thefollowing ruleenumeratesallthe pointsin at-tribute-valuespace forall components.
8
Inthis simple ex-ample,onlytwopointswillbeenumerated,oneforeach pos-siblevalueofthesingleattributeofthesinglecomponent,a widget:
valueTuple(?Component, [?Quality]) <-possValue(?Component, quality, ?Quality).
Note that \[?Quality]" represents a list with a single element (a variablerepresenting a value for the \quality" attribute). Theaboverulecreates avalueTuple/2 fact for every possible way to assign values to the attributes of a component.
Next,weprovidegeneralinformation about the negotia-tionofwidgets. These factsare used byAuction-Space to generatethefull setof auction parametersfor widget auc-tions. (Inthis case,mostof theparameterswillbedefault values.)
negotiationType(widget, continuous). negotiationType(widget, double). negotiationType(widget, revealAll).
At this point, we have inferred the auction parameters forwidgetsandwehaveenumeratedthevalueTuplesforthe auctionsweneedtocreate. Wenowcombinethosestepsto explicitlycreatetheauctionsandhaveeachoftheminherit itsparametersfromthosederivedforwidgetsingeneral.
ForeveryvalueTuple,weinferamakeAuction/1factwhich takesalist(thoughtofasanID)andtellsourprototypeto createanactualauction. Wealsoinferaparent/2factfor everyvalueTuple.
9
This tells us the component that each auctionbelongsto.
makeAuction([?Component, ?Values]) AND
parent([?Component,?Values], ?Component) <- valueTuple(?Component, ?Values).
Finally,wespecifytheauctionparametersforeachcreated auction|simplytheparametersthatwederivedingeneral forthecomponentthattheauctionbelongsto(itsparent).
auction(?ID, ?Attr, ?Val) <-parent(?ID, ?Component) AND auction(?Component, ?Attr, ?Val). 7
Notethatthisplacesquiteaburdenonagents|for exam-ple,iftheywouldvalueeitheraregularoradeluxewidget andplacebidsforboth,theyassumetheriskofbeingstuck withredundantitems.
8
Therules for enumeratingpointsinattribute-value space are generalizedandincludedinthe backgroundknowledge encodedinAuction-Conguration. Thisspecicruleis pre-sentedfor illustrationandwouldnotactuallybenecessary inspecifyingacontracttemplatewithContractBot. 9
InferringthesetofauctionsfromthevalueTuples,aswellas inheritanceofparametersfromparentcomponents,isdone automaticallyintheAuction-Congurationruleset. Sothe remainingrulesalsowouldbeunnecessaryinacontract tem-platewithourimplementation.
created: \widget: quality= regular" and \widget: qual-ity=deluxe". Foreachauction, 27distinctauction param-eters will be inferred via Auction-Space and AuctionBot-Mapping. Notethat sincethese auctionsderivedfrom the sameparentcomponent(widget),theirparametervaluesare identical.
5.
THE TAC DOMAIN
InJuly2000 at theInternationalConference on Multia-gent Systems,
10
the University of Michigan hosted a trad-ing agent competition(TAC),inwhichsoftware agents de-veloped by participating teams competed in a challenging marketgame[15]. InTAC, agentsaim to assemble travel packagesfordesignatedclients,buyingandsellingtravel re-sources through various typesof auctionsimplementedby theMichiganInternetAuctionBot. TACfeaturesthree ba-sic travel goods: ights(denedbydayand destination| inbound or outbound), hotels (dened by day and qual-ity), and entertainment tickets (dened by day and type ofevent).Eachtypeofgoodismediatedbyadierentkind ofauction. Flightssellatrandomly uctuatingprices, dic-tatedbyaxed-priceseller. Hotelsare soldinavariantof an ascending English auction. Agents buyand sell enter-tainment ticketsinacontinuousdoubleauction, muchlike tradingsecuritiesinastockexchange.
TheTACexampleContractTemplateincludedwith Con-tractBotisarulesetthatgeneratesthepartitioning(among a space of possible partitionings) of atravel package con-tractintothegoodsdescribedabove. Italsogenerates,from a high-level description inthe contract template, the auc-tion congurations used in the competition. In Section 6 wedemonstrateakeyresult: howalternativestructuresfor thenegotiationcanbederived,basedonrulesplausibly con-tributedbypartiesinterestedinthenegotiation.
5.1
Contract Template: Proto-Contract about
Payments and Utilities
The rst thing the TAC contract template species is a proto-contract. As described in Section 2.3, the proto-contractis the subsetofthe contract template that,when combinedwiththerulescomingoutofthenegotiation mech-anism,formthenal,executablecontract.Atypicalrulefor aproto-contract (seeSection2.3)that wehaveincludedin theTACexampleisinferringthetotalamountthatagiven agentowesanotheragentafterthenegotiation,by aggregat-ingtransactionfactsfromcompletedauctions:
transact(?Agent1, ?Agent2, ?Component, ?AVList, ?Pay12, ?Qty).
Morespecicto TAC,weincluderules inthe proto-con-tracttoinfertheutilitythatatravelagentreceivesfromits transactions,accordingtothedenitionoftheTACgame.
11 Asinthepaymentexample, thisis astraightforward com-putationasafunctionofthetransactionfacts.
Following is a part of the utility calculation specifying that a client's utility is a functionof whether it was able 10
and again in 2001 at the ACMConference onElectronic Commerce
11
A utilitycalculation wouldprobably not make senseina proto-contractintherealworld,butintheTACgame,the utilityisusedexternallytoevaluateagents'performance.
anditsbonusesfor stayinginthenicehotelandseeingthe entertainmentitwanted:
<high> clientUtility(?Client, 0) <-feasibleTrip(?Client, false). <m> clientUtility(?Client, ?U)
<-feasibleTrip(?Client, true) AND travelPenalty(?Client, ?TP) AND hotelBonus(?Client, ?HB) AND funBonus(?Client, ?FB) AND
?U is 1000 - 100 * ?TP + ?HB + ?FB.
Notethatalthoughthecompleterulesetfor utility calcu-lation is not given, all of the above predicates can be in-ferredfrom transactionfacts generated by ContractBot as itmonitorstheauctionresults. TheTACexamplecontract templatethenincludesrulestoinferatravelagent'sutility inthecompetitionbysummingtheutilitiesofitsclientsand subtractingitsexpenses.
5.2
Contract Template: Possible Components
and Attributes
TherstthingtheTACcontracttemplatespeciesafter theproto-contractisthepossiblevaluesfortheattributesof thegoods. Forexample,thefollowingfactssetthepossible typesofentertainmentevents:
possValue(entertainment, type, baseball). possValue(entertainment, type, symphony). possValue(entertainment, type, theatre).
Afterspecifyingthedomainsfortheattributes,thereare several sections of rules corresponding to possible compo-nentsoftheTACdomain. Thesegivetheattributesofeach ofthecomponents,aswellasspecifynegotiation-levelrules. Forexample,thefollowingrulesspecifythat ightshavetwo attributes|type(inboundoroutbound)andday.
attribute(flight, type). attribute(flight, day).
possValue(flight, day, ?Val) <-possValue(day, ?Val).
Notethatthepossiblevaluesfor ighttypeswere enumer-atedinseparaterules. Thepossiblevaluesfor ightdaysare inferredfromthegloballydeneddayvalues,declaredwith possValue/2 predicates (similar to quality values for wid-getsinSection4.4).
Anotherpossible component isthe bundleof two ights intoaround-trip.
attribute(roundflight, dayin). attribute(roundflight, dayout).
<m> auction(roundflight, ?Param, ?Val) <-auction(flight, ?Param, ?Val).
Twoattributesforroundflightcomponentsarespecied, andtheyinherittheirdomainsfromthegloballydened do-mainforpossible days. Theindividual auctionparameters for round-trip ights are inheritedfrom thoseinferred for one-way ights.
Figure3illustratessomeofthepossiblecomponents spec-ied in the TAC contract template and the next section shows how ContractBot choosesbetween these alternative congurations.
Figure 3: Some alternative ways to structure the TACnegotiation: (a)theactualTACconguration, (b) bundling round-trip ights and blocks of hotel rooms, and (c) bundling everything into a compre-hensive travelpackage.
6.
ALTERNATIVE NEGOTIATION
STRUC-TURES: TAC EXAMPLE
OneofthemostinterestingfeaturesofContractBotisits abilitytoreasonaboutalternativenegotiationstructuresby stating relationships between thepossible componentsand incorporatingrulesfromparticipatingagents.
TheexampleTACContractTemplateincludesbuyer, sel-ler,and auctioneerruleswhichare consistentwiththe sce-nariointheactualTACgame. There aretravel agents in-terestedinbuyinganyoftheatomiccomponents,andwho wouldalsobeinterestedinbuyingvariousbundles,suchas round trip ights and blocks of hotel rooms. The travel agentsarealsointerestedinsellingentertainmentticketsas well as buying them. The only other sellers are the air-line,who isonlywillingtosellone-way ights,andthe ho-tels, who will sell rooms either individually or in blocks. The auctioneer prefers fewer auctions and more users. It makesthis explicit by specifying aperAuctionCost and a perUserCredit. ContractBotwillchooseaconsistentsetof componentsthatminimizes
#usersperUserCredit #auctionsperAuctionCost:
Althoughthehotelselleriswillingtoselleitherblocksof hotels or individual nights, havingahigh perAuctionCost leadstothestructureshowninFigure3(a). Thisisbecause thehotelblockcomponenthasmoreattributes(firstnight andlastnight)thanhotel(whichhasonlyone\night" at-tribute), resultinginmore auctionsand therefore ahigher cost. Section4.1 discusses some ofthe componentscoring rules that drive this inference. As described in the wid-get example(Section4.4), theAuction-Conguration rule-set willinfer multiple auctionsfor eachgood. Inthe TAC example, assuming fourdays,therewill be42=8 ight auctions|one for everycombination of day and type (in-bound or outbound)|andsimilarly for hotels which have twotypes(goodorbad). Entertainmentticketshavethree types(baseball, symphony, or theatre) and so 43 = 12 auctionsarecreated.
Notethatthe buyer/sellerrules include several travelers who areinterestedinbuyingcompletetravelpackages (see Figure 3(c)). Thisstructureis not inferred, however, be-causetherearenoagentswillingtoselltravelpackages(as wellas theprohibitiveperAuctionCost). By addingrules suchas
Figure4: HowContractBotusesits auction knowl-edgetoturnapartialcontractintoacomplete, exe-cutablecontract. The largearrowsrepresentinputs and outputs of the system. The nal stage of ex-ecuting a nal contract is the subject of previous work[8].
seller(hypotheticalSeller,tr avel pack age). perAuctionCost(0).
ContractBotwill insteadinfer asinglecomponentwithsix attributes(arrive,depart,hoteltype,ent1day,ent2day, ent3day). Thesizesof thedomains oftheseattributes are 4, 4, 2, 5, 5, and 5, respectively, and would require 392 auctions.
12
Without a perAuctionCost, the following rules are the minimal set necessaryto choose a bundlingof ights into roundtrips, hotelroomsintocontiguousblocks,and enter-tainmentintopackagesofthreeevents.
buyer(traveler1, roundflight). buyer(traveler2, hotelblock). buyer(traveler1, entpackage). seller(airline1, roundflight). seller(hotel1, hotelblock). seller(agent3, entpackage).
These rules will (trivially) infer the structure shown in Figure3(b).Variousotherpartitioningsofthecontractinto bundlescanbeinferredsimilarlybyaddingorremoving po-tentialbuyersandsellersforthevariouspossiblecomponents andadjustingthecostofadditionalauctionsandcreditfor additionalbuyersandsellers.
7.
PROTOTYPE IMPLEMENTATION
Figure 4 depicts the overall process of turning a con-tracttemplatealongwithrulesfromagentsintoanal con-tract,andthenanexecuteddeal. Attheheartof this pro-cess are the threesets of backgroundknowledgediscussed in Section 4|Auction-Conguration, Auction-Space, and AuctionBot-Mapping. ContractBot.clp wraps these rule-bases together along with miscellaneous utilities (util.clp) andProlog(XSB)[2]queriesthat drivetheinference.
Theinferenceengineitselfisactuallywrittenasaseriesof Perlscriptsthat owasetofinputrulesandthebackground 12
Lessthan 4000 since infeasible packages|e.g., departure beforearrival|arenotinferred.
Bot executable accepts arbitraryCLP rules (generally the contracttemplateandbuyer/sellerrules)onstandardinput and combines these rules with the background knowledge speciedin contractBot.clp. This conglomeration of CLP input is fed into the Courteous Compiler, a component of IBMCommonRuleswhichcompilesCLPintoordinary Pro-log. ThisPrologcodeiscombinedwiththequeriesspecied incontractBot.clpandfedintotheXSBPrologengine.
Itis thesequeriesthat generatetheoutputthat the fol-lowing modulesneedinordertointeractwiththe Auction-Bot. For example, to generate the list of auctions to be created,contractBot.clpmakesa querywhichwrites alist tostandardoutputcontainingalltheauctionIDsforwhich thereisamakeAuctionfactentailedbytheknowledgebase. Thesefactsaregenerated byAuction-Congurationfor ev-ery point inattribute space for every component inferred. Components, inturn, are inferred from the contract tem-plateandfromrulesfromagents.
TheoutputofthePrologqueriesamountstoalistof auc-tionsandparametervaluesforeachauction. Thelistof auc-tions andparametersettingsare fedtothe create-auctions module which connects to the AuctionBot via the Mathe-matica implementation of the AuctionBot Agent Commu-nication Protocol
13
and creates the auctions. The list of auctions is alsosent to the auction-watcher module which monitors the specied auctions and composes the corre-spondingtransaction facts (see Sections 2.3 and 5) when-everatransactionoccursonAuctionBotinanauction rele-vanttothecontract. Finally,thetransactionfactsare con-catenatedwiththeproto-contractfromtheoriginalcontract templatetoformanexecutablecontractwhichcanitselfbe fedthroughaninferenceenginetoexecutethetermsofthe deal[8].
8.
DISCUSSION AND FUTURE WORK
We have given a new approach to automatically bridg-ing the threestages of contracting: discovery,negotiation, and execution. In particular, this encompasses three new contributions:(1)weuseadeclarativecontractinglanguage to represent information pertinent to all three aspects of contracting, (2)our approach relatesall 3aspectsto each otherandenablesthesameinformationtobeusedin mul-tiple stages, and (3) we have shown the exibility of this approach by implementinga prototype (ContractBot) and generatingalternativenegotiationstructuresforatravel do-main(TAC).
Ourapproachaddressesseveralresearchquestions regard-ing practical automationofthe contractingprocess. First, how can we represent information to allow automatic in-ferenceof negotiation structures? Second,how canwe au-tomatically specifynegotiations in a way that will closely drive a realistic automated platform? Third, how can we useauctionresultstoformanalcontract?
In our prototype, we use Courteous Logic Programs to represent(1)partialcontracts,(2)additionalrulesaboutthe negotiationprocessfrombuyersandsellers,(3)background knowledgeabout howtostructurenegotiation mechanisms andcongureindividualauctions,and(4)nal,executable 13
Mathematica was chosen for itsclean implementation of the protocol and its convenient LISP-like handling of the auctionandparameterlists.
templateandfrompotentialbuyersandsellers,werstinfer thebasicstructureofthenegotiation mechanismby apply-ing background knowledge encoded in Auction-Congura-tion. We then use the Auction-Space knowledge base to infer a general set of parameters for each of the auctions supportingthenegotiation. TheAuctionBot-Mapping rule-settranslates this into an operationalspecication for the Michigan Internet AuctionBot. Finally, we combine rules generated by auction transactions withrules inthe proto-contract ofthe contract template,to form anal contract whichitselfisexecutableusingrule-basedtechniques.
Ourprototypecangeneratesets of auctions correspond-ing to a multicomponent, multiattribute negotiation, and supportsreasoningaboutalternativeways todecomposea contract into multiattribute components. In futurework, wewouldliketoextendAuctionBotaswellasourontology inContractBot to supportricher negotiation mechanisms. Wecurrentlyhandlemultipleattributesofacomponentby creatinganarrayofauctions,oneforeverycombinationof attributevalues. Thisisnottractableforlargernumbersof attributes and needsto be augmented with multiattribute and/orcombinatorialauctions. Asweaddadditional nego-tiationmechanismstoAuctionBot, wewill be able to add moresophisticatedbackgroundknowledgeabouthowto op-timallystructureanegotiationaccordingtothecriteria dis-cussedinSection3. Toextendourabilitytohandlethe exe-cutionphaseofcontracting,wewillgeneralizeourknowledge representationtoexpressSituated CourteousLPs. Situated logicprograms[6]usebeliefstodriveproceduralAPIs.
OnepieceoffutureworkoutsideofContractBotitselfwill involvewritingagentsthatparticipateintheinfrastructure we'vedeveloped. Thisisanextremelyrichareaforanalyzing complexagentstrategiessince anagentusing ContractBot mustnotonlyknowhowtobidintelligentlyinavastspace ofnegotiationmechanisms,butalsointelligentlycontribute rules to in uence which negotiation mechanism is chosen. Furtherissuesforfutureworkincludemeshingmoreclosely withotheraspectsofcontracts,e.g.,transactions,payments, negotiationandcommunicationprotocols[4][11], and sup-plierselection[14].
Acknowledgments
Thisworkwassupportedby IBM'sUniversity Partnership Program while the thirdauthor was at IBM. HoiChan of IBMplayedakeyroleindevelopmentofCommonRules.We would also like to thank Bill Walsh,Terence Kelly,David Parkes, Ed Durfee, Bill Birmingham,and RachelRose for helpful discussions and comments in earlier stages of this work.
9.
REFERENCES
[1] IBMCommonRules.http://www.research.ibm.com/ rules/commonrules-overview.h tml.
[2] TheXSBProgrammingSystem. http://xsb.sourceforge.net/.
[3] F.Branco. Thedesignofmultidimensionalauctions. RANDJournalofEconomics,28:63{81, 1997. [4] A.Dan,D.Dias,T.Nguyen,M.Sachs,H.Shaikh,
R.King,andS.Duri.Thecoyoteproject: Framework formulti-partye-commerce.InSeventhDelos
WorkshoponElectronicCommerce,Lecture Notesin ComputerScience,Vol.1513.Springer-Verlag,1998.
Market.Addison-Wesley,1993.
[6] B.N.Grosof.BuildingCommercialAgents: AnIBM ResearchPerspective.InProceedingsoftheSecond InternationalConference andExhibitiononPractical Applicationsof IntelligentAgents andMulti-Agent Technology(PAAM97),April1997.
[7] B.N.Grosof.Prioritizedcon icthandlingfor logic programs.InJ.Maluszynski,editor,Logic
Programming: ProceedingsoftheInternational Symposium(ILPS-97),pages197{211,Cambridge, MA,USA,1997.MITPress.
[8] B.N.Grosof,Y.Labrou,andH.Y.Chan.A declarativeapproachtobusinessrulesincontracts: Courteous logicprogramsinXML.InACM Conference onElectronic Commerce,pages68{77, Denver,1999.
[9] M. KumarandS.I.Feldman.Internetauctions.In ThirdUSENIXWorkshoponElectronicCommerce, pages49{60,Boston,1998.
[10] P.Milgrom.Puttingauctiontheorytowork: The simultaneousascendingauction.JournalofPolitical Economy,108,2000.
[11] N.H.MinskyandV.Ungureanu.Amechanismfor establishingpoliciesforelectroniccommerce.In18th InternationalConference onDistributedComputing Systems(ICDCS),May 1998.
[12] A.E.RothandA.Ockenfels.Lastminutebiddingand therulesforendingsecond-priceauctions: Theoryand evidencefromanaturalexperimentontheinternet. Technicalreport, May2000.http:
//www.economics.harvard.edu/~ aroth /alr oth.h tml. [13] T.Sandholm.eMediator: Anextgenerationelectronic commerceserver.InFourthInternationalConference onAutonomousAgents,Barcelona,2000.
[14] P.Szekely,B.Neches,D.P.Benjamin,J.Chen,and C.M.Rogers.Controllingsupplierselectioninan automatedpurchasingsystem.InAAAI-99Workshop onArticialIntelligenceinElectronic Commerce (AIEC-99),MenloPark,CA,USA,1999. [15] M. P.Wellman,P.R.Wurman,K.O'Malley,
R.Bangera,S.-d.Lin,D.Reeves,andW.E.Walsh. Designingthemarketgameforatradingagent competition.IEEEInternet Computing,5(2),2001. [16] P.R.Wurman,M.P.Wellman,andW.E.Walsh.The
MichiganInternetAuctionBot: Acongurableauction serverforhumanandsoftware agents.InSecond InternationalConference onAutonomous Agents, pages301{308,Minneapolis,1998.
[17] P.R.Wurman,M. P.Wellman,andW.E.Walsh.A parametrizationoftheauctiondesignspace.Games andEconomicBehavior,35,2001.