• Aucun résultat trouvé

Automated Negotiation from Declarative Contract Descriptions

N/A
N/A
Protected

Academic year: 2021

Partager "Automated Negotiation from Declarative Contract Descriptions"

Copied!
10
0
0

Texte intégral

(1)

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:

(2)

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.

(3)

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}

/

f

dreeves,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-speci c knowledge aboutthecontractsubjectalongwithpreferencesfrom po-tentialbuyersandsellers. Second,translatethedetermined negotiation structure into an operational speci cation for anauction platform. Third,mapthe negotiationresultsto a nal contract. We have implemented aprototypewhich supportsthese steps, employing adeclarative speci cation (inCourteousLogic Programs)of (1)high-levelknowledge about alternative negotiation structures, (2) general-case rulesaboutauctionparameters,(3)rulestomaptheauction parametersto aspeci cauction 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

Oneformofcommercethatcanbene tsubstantiallyfrom automationiscontracting,whereagentsformbinding, agree-ableterms,andthenexecutetheseterms. Theoverall con-tractingprocesscomprisesseveralstages,includingbroadly:

1. Discovery. Agents ndpotentialcontractingpartners.

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-matednegotiationmechanismcanbecon guredtosupport

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 cande ne 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 herewiththede nitionofnegotiationmechanismsandnot 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,itgeneratesa nal,executablecontract.

Section2givesanoverviewofourapproachtoautomated contracting. Section 3 provides background on auction-basednegotiation. Section2.3framestheoverallprocessof automatedcontractnegotiationandshowshowrules gener-ated during thenegotiation processcan becombinedwith thepartialcontracttoformanexecutable nalcontract. In Section4,wediscussindetailhowthelanguageisused to inferparametersforcon guringthenegotiation|thatis, pa-rametersforasetofauctions-. WefocusonaTradingAgent Competition[15]asanexampledomain(Sections5and6). Finally,inSection7,wediscussdetailsofourprototype.

2.

CONTRACTBOT FRAMEWORK

Thecentralquestionincon guringacontractnegotiation is,\Whatistobenegotiated?" Inanycontractingcontext, somefeaturesofthepotentialcontractmustberegardedas xed,withotherstobedeterminedthroughthecontracting process. At oneextreme,thecontractisfullyspeci ed, ex-ceptforasingleissue,suchasprice. Inthatcase,the negoti-ationcanbeimplementedusingsimpleauctionmechanisms ofthesortoneseesforspeci edgoodsontheInternet. The otherextreme, where nothingis xed,is tooill-structured toconsiderautomatinginthecurrentstateoftheart.

Mostcontractingcontextslieinbetween,wherean iden-ti ablesetofissuesistobedeterminedthroughnegotiation. 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/.

(4)

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-tomaticallycon gurethe 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, whichproduceresultsforthe nalcontract. 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 speci ed 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

ContractBotcon guresauctionsbasedonrulesaboutthe contractandaboutthenegotiation,aswellasgeneral back-groundknowledgeabout auctioncon guration itself. This backgroundknowledge(describedindetailinSection4) in-cludesrulesde ning:

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.

Tocon gureasetofauctionsforaparticulardomain,we incorporateadditionalrulesfromthecontracttemplateand from potential buyers and sellers. These rules, combined with the background knowledge about auction con gura-tion,are used to inferthe actual auctionparameters for a suiteofauctionsthatwillimplementthechosennegotiation structure.

2.3

Overall Contracting Process

Thecontracttemplateisessentiallyadeclarative descrip-tionofthespaceofpossiblenegotiationoutcomes,with ad-ditionalrulesforin uencingthestructureofthenegotiation andhowitwillbecon gured. AsshowninFigure1,the con-tracttemplatecomprisesrulesthatwillimplementthe nal 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 di erent levels. Rules in theproto-contractthatimplementsomeaspectofthe nal dealmayalsobeusedindetermininganappropriate negoti-ationmechanism. Forexample,timeconstraintsondelivery maydictateauction nalclearingtimes.

Thenegotiation-levelrulesaddressbothquestionsofwhat is to be negotiated, and how. Rules describing ways that thecontractissuesmay bepartitionedintoseparable com-ponentsde nethespace ofpossiblegoods tobenegotiated at auction. Rules referring to policies for negotiating in-dividual components de ne the auction behaviors for the correspondinggoods.

Thekeystepinthisprocess|bridgingthediscoveryphase (thepartialcontract)andthenegotiationphase(setof auc-tions)|is the con guration of the negotiation mechanism basedoninferencefromthecontracttemplateandrules sub-mittedbyagents.

After ContractBot con gures and generates the suite of auctions,itmonitorstheauctions,waitingfortransactions. Eachtransactiongeneratesafactspecifyingwhichaspectof

(5)

sellerwere,andthepriceandquantity. Theproto-contract containsrules thatmakeuseofsuchtransactionfactsonce theyare lledin. 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 con gured and run andthenegotiationphaseiscomplete,wecanautomatically entertheexecutionphasebygeneratingthe nalcontractas afunctionoftheproto-contractandtheauctionresults. The actualexecutionof nalcontractsisthesubjectofprevious work[8].

3.

AUCTION-BASED NEGOTIATION

Mechanismsfor determiningprice andother termsofan exchange are called auctions. Althoughthe most familiar auctiontypesresolveonlyprice,itispossibletode ne 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-derstoexpresso ersforcombinationsofgoods,and deter-mine anallocation that attemptsto maximize overall sur-plus. We are aware of one prototype system that o ered generalcombinatorialauctionsovertheInternet[13]. Mul-tiattribute auctions,typicallyemployedinprocurement, al-lowspeci cation ofo ersreferringtomultipleattributesof 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:

 Thecoherenceofauctioncon gurations. Forexample, ifsome attributesare inseparable(say,size andcolor of a good), then it makes nosense to treat them as separategoodsinacombinatorialauction.

 The expected performance of auction con gurations. Forexample,ifparametersrepresentdistinctand sep-2

Asofthiswriting,eBayalonehasover vemillion 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 ofauctioncon gurations,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-speci c rules from the contract template, our con guration process employs three sets of rules encoding background knowledge about the space of possiblenegotiationmechanisms.

4.1

Auction Configuration

TheAuction-Con guration rulesetde nes 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-Con gurationhelpsdeterminehowtopartitionthe 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\?" pre x indicatesalogicalvariable. Rulelabels are speci edwith angle brackets (< >). Thesyntaxis de-scribed indetail inthe documentation for IBM Common-Rules[1],theimplementationofCourteousLogicPrograms weemploy. AlsoincludedinAuction-Con gurationarerules 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.

(6)

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 basedonspeci c aspects ofanegotiation willtakeprecedence. Forexample,the fol-lowingrulesspecifythatbydefault,anyauctionshouldhave multiplebuyersandoneseller,andthattiesforwinningbids shouldbebrokenby rst-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 speci c 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 di erence turns out to have a marked e ectonagentstrategies.[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 needtodriveaspeci cauctionserver. AuctionBot-Mapping isaparticularsetofrulesforderivingAuctionBot parame-tersfromthegeneralizedandextendedparametrization pro-videdbyAuction-Space. Separatingtheserver-speci c 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)

(7)

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-Con guration. Thisspeci cruleis pre-sentedfor illustrationandwouldnotactuallybenecessary inspecifyingacontracttemplatewithContractBot. 9

InferringthesetofauctionsfromthevalueTuples,aswellas inheritanceofparametersfromparentcomponents,isdone automaticallyintheAuction-Con gurationruleset. 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(de nedbydayand destination| inbound or outbound), hotels (de ned by day and qual-ity), and entertainment tickets (de ned by day and type ofevent).Eachtypeofgoodismediatedbyadi erentkind ofauction. Flightssellatrandomly uctuatingprices, dic-tatedbya xed-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 con gurations 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 speci es is a proto-contract. As described in Section 2.3, the proto-contractis the subsetofthe contract template that,when combinedwiththerulescomingoutofthenegotiation mech-anism,formthe nal,executablecontract.Atypicalrulefor aproto-contract (seeSection2.3)that wehaveincludedin theTACexampleisinferringthetotalamountthatagiven agentowesanotheragentafterthenegotiation,by aggregat-ingtransactionfactsfromcompletedauctions:

transact(?Agent1, ?Agent2, ?Component, ?AVList, ?Pay12, ?Qty).

Morespeci cto TAC,weincluderules inthe proto-con-tracttoinfertheutilitythatatravelagentreceivesfromits transactions,accordingtothede nitionoftheTACgame.

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.

(8)

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

The rstthingtheTACcontracttemplatespeci esafter 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 inferredfromthegloballyde neddayvalues,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).

Twoattributesforroundflightcomponentsarespeci ed, andtheyinherittheirdomainsfromthegloballyde ned do-mainforpossible days. Theindividual auctionparameters for round-trip ights are inheritedfrom thoseinferred for one-way ights.

Figure3illustratessomeofthepossiblecomponents spec-i ed in the TAC contract template and the next section shows how ContractBot choosesbetween these alternative con gurations.

Figure 3: Some alternative ways to structure the TACnegotiation: (a)theactualTACcon guration, (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-Con guration 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

(9)

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-tracttemplatealongwithrulesfromagentsintoa nal con-tract,andthenanexecuteddeal. Attheheartof this pro-cess are the threesets of backgroundknowledgediscussed in Section 4|Auction-Con guration, 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 speci edin contractBot.clp. This conglomeration of CLP input is fed into the Courteous Compiler, a component of IBMCommonRuleswhichcompilesCLPintoordinary Pro-log. ThisPrologcodeiscombinedwiththequeriesspeci ed 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-Con gurationfor 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 speci ed 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 useauctionresultstoforma nalcontract?

In our prototype, we use Courteous Logic Programs to represent(1)partialcontracts,(2)additionalrulesaboutthe negotiationprocessfrombuyersandsellers,(3)background knowledgeabout howtostructurenegotiation mechanisms andcon gureindividualauctions,and(4) nal,executable 13

Mathematica was chosen for itsclean implementation of the protocol and its convenient LISP-like handling of the auctionandparameterlists.

(10)

templateandfrompotentialbuyersandsellers,we rstinfer thebasicstructureofthenegotiation mechanismby apply-ing background knowledge encoded in Auction-Con gura-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 operationalspeci cation for the Michigan Internet AuctionBot. Finally, we combine rules generated by auction transactions withrules inthe proto-contract ofthe contract template,to form a nal 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 onArti cialIntelligenceinElectronic 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: Acon gurableauction 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.

Figure

Figure 1: Overall contracting process, partial to
Figure 3 illustrates some of the possible components spec-
Figure 4: How ContractBot uses its auction knowl-

Références

Documents relatifs

The rest of the paper is organized as follows: Section II provides foundation material for our paper including QoS in web services in Section II-A, probabilistic contracts in

ABSTRACT. In 1998, and then again in 2000, the French govern- ment adopted laws designed to reduce working time to 35 hours a week. This article will deal with two questions

For that, this work contributes with an identification and preliminary characterization of technological tools that can be related to the topic and for the consolidation

The negotiation problem is then: how to organize compensation transfers from the developed countries to the developing country to sustain a higher (Pareto optimal) level

The tool is currently being used at both industrial and academic environments, and user feedback indicates that both the development method and the tool are effective in

Given such a new way people are using the Internet today, the approach of Automated Trust Negotiation (ATN) [2][3] is becoming relevant, because it allows unknown users

In this paper, an architecture based on SQ is presented and its implementation is outlined with the goal of generating SADI Semantic Web service code automatically from

„ Price level should be considered alongside other criteria, including product quality, product characteristics, availability, supply security, supply reliability and charges along