A Generic Agent-Mediated Electronic Commerce
Framework for Multi-Attribute Negotiation and Trading
by
Gaurav Tewari
Submitted to the Department of Electrical Engineering and Computer Science
in Partial Fulfillment of the Requirements for the Degrees of
Bachelor of Science in Computer Science and Engineering
and Master of Engineering in Electrical Engineering and Computer Science
at the Massachusetts Institute of Technology
May 11, 2001
Copyright 2001 Massachusetts Institute of Technology. All rights reserved.
Author________________
Department of Electrical Engineering and Cornputer Science
Ma>,11, 2001
Certified by
n r- Pa-ti Maes
Thesis Supervisor
Accepted by
Arthur C. Smith
Chairman, Department Committee on Graduate Theses
MASSACHUSETTS INSTITUTE
OF TECHNOLOGY
2002
KJUL 3 1
LIBRARIES
2
A Generic Agent-Mediated Electronic Commerce Framework for Multi-Attribute
Negotiation and Trading
by
Gaurav Tewari
Submitted to the
Department of Electrical Engineering and Computer Science
May 11, 2001
In Partial Fulfillment of the Requirements for the Degree of Bachelor of Science in
Computer Science and Engineering and Master of Engineering in Electrical Engineering
and Computer Science
ABSTRACT
Current electronic marketplaces emphasize the singular importance of price in matching
buyers and sellers. Unable to adequately express their underlying preferences for all
relevant attributes, buyers and sellers are forced to partake in an inflexible and
antagonistic price-centric interplay. The result is an unfortunate, zero-sum circumstance
of adversarial competitiveness, in which one party can benefit only at the expense of the
other. "Multi-Attribute Resource Intermediaries" (MARI) is a project which proposes to
improve online marketplaces. MARI is a domain-independent, generic agent-based
architecture for electronic markets, which can be instantiated in different product
domains. MARI represents an advance over current e-markets in the following ways: (i).
It permits buyers and sellers to express multi-attributepreferences; (ii). It is multi-tiered,
allowing buyers and sellers to express preferences not only for the attributes for the
underlying product or service, but also for each other; and (iii). It facilitates significant
automation, allowing software agents to act as proxies for buyers and sellers. MARI
transcends bid and ask prices to include all relevant attributes as dimensions for
consideration and differentiation, making it possible for both buyers and sellers alike to
more holistically and comprehensively specify relative preferences, and making price just
one of a multitude of possible factors influencing the choice of trading partner and the
decision to trade. Buyers and sellers express their preferences, which permits agents to
represent them and their "utility functions." The system then computes matches between
buyer and seller agents in a Pareto optimal fashion, meaning that no one can be made
better off without making someone else worse off, and implying that no potential gains
are left unexploited. This thesis presents the theory behind MARI, the generic
architecture, and an evaluation through the instantiation of the system in a services
marketplace.
Keywords: Electronic Commerce; Software Agents; Intermediaries; Highly Mediated
Communications; Product Brokering; Merchant Brokering; Preference Modeling; Decision
Support; Negotiation; Utility Theory; Electronic Markets.
Thesis Supervisor: Dr. Pattie Maes
Title: Associate Professor of Media Arts and Sciences, MIT Media Laboratory
3
4
This thesis is dedicatedto my advisor Pattie, to my parents, Satish and Balvinder, and to
my sisters, Geetika and Kanu. For everything I am and will become, I thank you
sincerely and with the utmost gratitude.
5
6
CONTENTS
1 INTRODUCTION ..........................................................................................................
16
1.1 Overview .................................................................................................................
16
1.2 Contribution ........................................................................................................
16
1.3 Roadm ap ............................................................................................................
17
2 THE MARI SYSTEM ...............................................................................................
20
2.1 Introduction........................................................................................................
20
2.2 M otivation...........................................................................................................
20
2.3 The M ARI System ..............................................................................................
21
2.4 Example Usage....................................................................................................
24
2.5 Application Domain: Service M arketplaces ......................................................
28
2.6 The Language Translation M arketplace..............................................................
28
3 RELATED W ORK ...................................................................................................
30
3.1 Gam e Theory and Econom ic M odeling .............................................................
30
3.2 Existing System s .................................................................................................
33
4 ALGORITHMS AND TECHNOLOGIES USED ....................................................
36
4.1 M odeling User Preferences.................................................................................
36
4.1.1 Overview ......................................................................................................
36
4.1.2 Capturing User Preferences..........................................................................
36
4.1.3 M odeling User Utility Functions..................................................................
38
4.2 M atching Buyers and Sellers ..............................................................................
43
4.2.1 Overview ......................................................................................................
43
4.2.2 Generating Data Points from Functional Approximations...........................45
4.2.3 Exploring the Attribute Space to identify the Optimal Transaction
Configuration (OTC)............................................................................................
48
4.2.4 Delineating Transaction Partners to Maximize Aggregate Surplus .............
49
4.2.5 Presenting Results .......................................................................................
53
5 THEORETICAL PRINCIPLES AND METHODOLOGICAL RATIONALE.........56
5.1 M odeling Preference Functions .........................................................................
56
5.1.1 Assumptions .................................................................................................
56
5.1.2 M athem atical Formulation of Utility Functions...........................................
57
7
5.2 Mechanism Design ...............................................................................................
61
5.3 Optim ization Heuristics for Transaction Brokering.............................................
63
5.4 Welfare M axim ization .......................................................................................
65
5.5 A lgorithm s for M atching Buyers w ith Sellers ...................................................
67
6 FUN CTIONA L D ESIGN ..........................................................................................
70
6.1 Functional Schem a and M odules .........................................................................
70
6.2 Usage Schem a and Interaction Model................................................................
73
7 IMPLEMENTATION: USER EXPERIENCE...........................................................76
7.1 Introduction .............................................................................................................
76
7.2 O verview
76
F......ai..............................................................................
7.3 M ajor U ser-Driven Functional Operations.............................................................
7.3.1 Creating aNew A gent .. .........................................
...................................
79
79
7.3.2 Viewing Existing Agents ..........................................................
84
7.3.3 V iew ing M arket Status.....................................................................................
90
7.3.4 View ing M arket H istory ...............................................................................
90
7.3.5 Logging Out ........................................................................
92
7.4 Usability Considerations.....................................................................................
92
7.5 Conclusions.............................................................................................................
94
8 EVALUATION: MARKET SCENARIOS................................................................
96
8.1 M arket V ariables and Possible Scenarios ...........................................................
96
8.2 First Scenario .....................................................................................................
98
8.3 Second Scenario ....................................................................................................
103
8.4 Third Scenario.......................................................................................................
107
8.5 Fourth Scenario.................................................................................................
11
9 EV A LU A TION : U SER TESTIN G ..............................................................................
114
9.1 Introduction ...........................................................................................................
114
9.2 Experim ental D esign.............................................................................................
114
9.2.1 Objectives.......................................................................................................
114
9.2.2 M ethodology ..................................................................................................
114
9.3 Interface Study ......................................................................................................
116
9.3.1 Q uestions Posed .............................................................................................
116
8
9.3.2 Findings ..........................................................................................................
117
9.4 System Study.........................................................................................................120
9.4.1 Q uestions Posed .............................................................................................
120
9.4.2 Findings ..........................................................................................................
120
9.5 Conclusions ...........................................................................................................
122
10 CONCLUSION AND FUTURE DIRECTIONS .......................................................
124
10.1 Conclusion...........................................................................................................
124
10.2 Future D irections.................................................................................................
124
10.2.1 Econom ics and G am e Theory ......................................................................
125
10.2.2 U ser Interface Studies ..................................................................................
126
10.2.3 O perations Research.....................................................................................
126
10.2.4 Software Engineering ...................................................................................
126
10.2.5 M arket Research...........................................................................................127
10.2.6 V alue Proposition Analysis ..........................................................................
127
11 APPENDIX A: IMPLEMENTATION DATA MODEL ...........................................
128
11.1 Structured Q uery Language (SQ L) U sage ..........................................................
128
11.2 Extensible M arkup Language (X M L) Usage ......................................................
131
11.3 M ajor D atabase Tables and Constituent Fields...................................................
132
11.3.1 TABLE Players ............................................................................................
132
11.3.2 TABLE Markets ...........................................................................................
133
11.3.3 TA BLE PlayerProfileM ap............................................................................133
11.3.4 TA BLE MarketToX ToAttributeM ap ...........................................................
133
11.3.5 TA BLE C losedTransactions ........................................................................
134
11.3.6 TA BLE PendingTransactions ......................................................................
134
11.3.7 TA BLE TransactionA ttributes.....................................................................135
11.3.8 TA BLE Attributes ........................................................................................
135
11.3.9 TA BLE CorrelationCoefficients ..................................................................
136
11.3.10 TA BLE M arketPlayerRequests..................................................................136
11.3.11 TA BLE M arketProfiles ..............................................................................
137
11.3.12 TA BLE M arketQ uestions ..........................................................................
137
11.3.13 TABLE M arketA nsw ers ............................................................................
138
9
11.4 Schematic Depiction of Database Components and Their Interrelationships.....138
12 APPENDIX B: IMPLEMENTATION BACK END COMPONENTS .........
142
12.1 Introduction .........................................................................................................
142
12.2 Back-End Com ponents...................................................................................
144
12.2.1 Login.asp......................................................................................................
144
12.2.2 W elcom e.asp ................................................................................................
144
12.2.3 Specific-m arket.asp ......................................................................................
145
12.2.4 Create-agent.asp ...........................................................................................
145
12.2.5 Choose-profile.asp ...................................................................................
146
12.2.6 Start-request.asp .......................................................................................
147
12.2.7 M arket-param eters.asp .................................................................................
148
12.2.8 Visit 0:...............................................148
12.2.9 V isit 1: ..........................................................................................................
149
12.2. 9 V isit 2: ........................................................................................................
150
12.2.11 V isit 3 .........................................................................................................
150
12.2.12 Market-w atch asp.....................................
. .................................................
150
12.2.13 Market-history as ....................................................................................
151
12.2.14 Process-request.asp....................................................................................
151
12.2.15 M atching.asp...asp.....................................................................................
152
12.2.16 Logout.asp ....................................................
..........................................
154
12.2.17 Faq .asp.. .....................................................
...........................................
154
12.2.18 About.asp.........................................................
...........................................
155
12.2.19 Contact-info. asp......................................
. ..................................................
155
13 APPENDIX C: SUGGESTIONS FOR FURTHER READING ABOUT MARI...... 156
14 BIBLIOGRA PH Y ......................................................................................................
158
14.1 W orks Referenced...............................................................................................
158
14.2 Works Consulted .....................................................................
161
10
List of Figures
Figure 1: Agents Manifest Their Owners' Preferences, and are Optimally Matched by the
24
S y stem .......................................................................................................................
25
Figure 2: Bids and Asks Corresponding to User Preferences ........................................
27
...........................................................
Market
Figure 3: Value Created in a Traditional
27
Figure 4: V alue Created by M ARI................................................................................
Figure 5: Specifying the Ideal Offer and Permissible Ranges for Flexible Attributes ..... 38
Figure 6: The Market Maker Visually Associates Utility Functions with Flexible
39
Attrib utes ...................................................................................................................
Figure 7: Details of the "deal" designated by the system for a matched agent.............54
Figure 8: Details of potential deals with other qualified transaction partners that were
considered, with corresponding scores, and whether these prospective transaction
54
partners were matched with someone else .............................................................
70
....................................................................
Schematic
Figure 9: Architecture Design
Figure 10: Flowchart Schematically Illustrating Major MARI Front-End Modules ........ 77
78
Figure 11: Flowchart Illustrating Major MARI Back-End Modules ............................
80
Figure 12: Choosing a Buyer Profile............................................................................
Figure 13: Specifying Permissible Ranges for Flexible Attributes...............................81
82
Figure 14: Selecting Utility Functions .........................................................................
85
A
gent.................................................................................
Selling
a
15:
Editing
Figure
88
Figure 16: Viewing Matched Agents ...........................................................................
Figure 17: Viewing Details of the "Deal" the System has Selected for a Matched Agent88
Figure 18: Viewing Alternatives that Were Taken Into Account for a Matched Agent ...89
92
Figure 19: V iew M arket H istory ..................................................................................
Figure 20: Theoretically Calculated Surplus Values Corresponding to each Potential
10 0
M atch .......................................................................................................................
Figure 21: Actual System Generated Surplus Values Corresponding to each Potential
10 0
Match .......................................................................................................................
agent......102
matched
his
with
associated
"deal"
of
the
details
sees
S2's
owner
Figure 22:
Figure 23: S2's owner sees details of potential deals with other qualified transaction
partners that were considered and whether these prospective transaction partners
102
were m atched w ith someone else ............................................................................
103
Figure 24: D etails Seen by B I's Ow ner..........................................................................
Figure 25: System Generated Surplus Values Corresponding to each Potential Match. 105
106
Figure 26: Value Created in a Traditional Market ..........................................................
107
Figure 27: V alue Created by M ARI................................................................................
Figure 28: System Generated Surplus Values Corresponding to each Potential Match. 109
110
Figure 29: D etails Seen by SI's Ow ner ..........................................................................
Transaction
other
Qualified
Figure 30: SI's Owner Sees Details of Potential Deals with
110
P artn ers ....................................................................................................................
Figure 31: System Generated Surplus Values Corresponding to each Potential Match. 112
113
Figure 32: Details Seen by B I's Owner..........................................................................
Figure 33: BL 's Owner Sees Details of Potential Deals with other Qualified Transaction
113
P artners ....................................................................................................................
Figure 34: Table 'Players' and its Interaction with Other Tables ................................... 129
11
Figure 35: Table 'Markets' and its Interaction with Other Tables..................................
130
Figure 36: Table 'MarketToXToAttributeMap' and its Interaction with Other Tables.. 131
Figure 37: Interaction Schema between Major MARI Database Components...............139
Figure 38: Flowchart Illustrating Major Back End Components and Programmatic
C ontrol Flow ...........................................................................................................
143
12
List of Tables
Table 1: MARI's Predefined Generic Utility Functions (x is a place-holder variable for a
value of the flexible attribute over its permissible range).......................................41
Table 2: Profile of a "Professional Buyer" BPRO ..............................................................
Table 3: Profile of a "Professional Seller" SPRO---------------------.........................................
46
48
Table 4: Utility Functions Represented by Degree One (Linear) Polynomials ............ 59
Table 5: Utility Functions Represented by Degree Two (Quadratic) Polynomials .......... 61
61
Table 6: Other Utility Functions ...................................................................................
Table 7: Scenario 1, Buyer 1 (B1).................................................................................99
Table 8: Scenario 1, Buyer 2 (B2).................................................................................99
Table 9: Scenario 1, Buyer 2 (B2).................................................................................99
99
Table 10: Scenario 1, Seller 1 (S1) ..............................................................................
99
Table 11: Scenario 1, Seller 2 (S2) ..............................................................................
Table 12: System Generated Closing Prices Corresponding to Each Potential Pairing.. 101
104
Table 13: Scenario 2, Buyer 1 (Professional Buyer).......................................................
104
Table 14: Scenario 2, Buyer 2 (Casual Buyer)................................................................
104
Table 15: Scenario 2, Seller 1 (Professional Seller)........................................................
104
Table 16: Scenario 2, Seller 2 (Casual Seller) ................................................................
105
Pairing..
Potential
Table 17: System Generated Closing Prices Corresponding to Each
107
Table 18: Scenario 3, Seller 1 (Monopolist)...................................................................
Table 19: Scenario 3, Buyer 1.........................................................................................108
108
Table 20: Scenario 3, Buyer 2 .........................................................................................
108
Table 21: Scenario 3, Buyer 3.........................................................................................
Table 22: Details of Potential Matches for S1 Considered by the System ..................... 109
111
Table 23: Scenario 4, B uyer 1.........................................................................................
111
Table 24: Scenario 4, Seller 1 .........................................................................................
111
Table 25: Scenario 4, Seller 2 .........................................................................................
112
T able 26: Scenario 4, Seller 3 .........................................................................................
Table 27: Details of Potential Matches for B 1 Considered by the System.....................113
119
Table 28: Interface Experiment Results ..........................................................................
121
Table 29: System Experiment Results ............................................................................
13
List of Equations
E qu ation I ......................................................................................................................... 4 0
Equation 2 ......................................................................................................................... 42
Equation 3 ......................................................................................................................... 47
Equation 4 ......................................................................................................................... 48
Equation 5 ......................................................................................................................... 50
Equation 6 ......................................................................................................................... 50
E qu ation 7 ......................................................................................................................... 5 1
E quatio n 8 ......................................................................................................................... 5 1
Equation 9 ......................................................................................................................... 51
Equation 10 ....................................................................................................................... 51
Equation I I ....................................................................................................................... 66
Equation 12 ....................................................................................................................... 66
Equation 13 ....................................................................................................................... 66
Equation 14 ....................................................................................................................... 67
Equation 15 ....................................................................................................................... 67
14
ACKNOWLEDGEMENTS
This thesis could not have been accomplished without the assistance, support and
encouragement of a number of people and institutions.
I would like to recognize the invaluable assistance provided by undergraduate
students Alexander Berkovich, Vladislav Gabovich, Shuehan Liang and Anand
Ramakrishnan in helping to implement this system and in making the project a success.
Additionally, I want to convey my sincere gratitude and appreciation to Professor
Pattie Maes, for having given me the opportunity to work directly with her and for
allowing me to have benefited from her advice and guidance thoroughout my tenure at
the Media Lab. Pattie has had a profound impact on me personally as well as
professionally and, going forward, I sincerely hope that I will continue to have the good
fortune to interact with her.
I would like to thank Professors Jeremie Gallien, Dan Ariely, Chris Dellarocas,
Benjamin Grosof, Hal Varian and David Autor and Mr. Michael Schrage for providing
useful and timely comments, suggestions and guidance. Their discussions with me helped
to substantially improve the quality and contribution of this thesis.
I would like to recognize the members of the Software Agents Group at the MIT
Media Laboratory, as well as the Media Lab community at large, for their objective, yet
supportive, critiques of my work and valuable feedback. I would like to thank MIT, and
specifically the MIT Media Laboratory for use of equipment, laboratory space and, in
general, for providing, an atmosphere conducive to doing research.
Words are not enough to express my appreciation and respect for my sisters,
Geetika and Kanu, my father, and my mother for their unconditional love, support and
patience. Without their constant blessings, prayers, and encouragement, I could not have
accomplished anything.
Finally, I recognize and feel blessed by the influence upon my life of that
omniscient, omnipresent and omnipotent higher power we call God. Mata Gayatri and Sri
Krishna, I am constantly cognizant of your manifest, divine protection over me at every
moment, everywhere.
15
16
1 INTRODUCTION
1.1 Overview
This thesis describes the design, implementation and evaluation of "Multi-Attribute
Resource Intermediaries" (MARI) - a research project conducted in the Software Agents
Group at the MIT Media Laboratory. MARI is an agent-based architecture intended as a
generalized platform for the specification and brokering of heterogeneous goods and
services. MARI proposes to radically improve online marketplaces, specifically those that
involve the buying and selling of non-tangible goods and services. Our work has focused
on developing a general, domain-independent infrastructure that will make it easier for
human users to customize the behavior of software agents (self-contained, executing
segments of code designed to perform particular tasks), that represent them in the
marketplace. Our system makes it possible for users to quantify their preferences for
goods and services along multiple, heterogeneous attributes or dimensions rather than just
on the basis of price, as is currently the case in state of the art systems. This, in turn,
makes it possible for participants in online marketplaces to be represented by software
agents who find suitable products and trading partners on behalf of their owners, autonomously generate valuations for the product in question, and ultimately negotiate the terms
of the transaction.
MARI represents an advance over state of the art electronic marketplaces in the
following ways: (i). It permits buyers and sellers to express multi-attribute preferences;
(ii). It is multi-tiered,allowing buyers and sellers to express preferences not only for the
attributes for the underlying product or service, but also for each other; and (iii). It
facilitates significant automation,allowing agents to act as proxies for buyers and sellers.
1.2 Contribution
MARI attempts to overcome many of the deficiencies of contemporary electronic
markets and represents a fundamentally novel paradigm for gathering and modeling user
preferences, and for matching buyers and sellers. It provides automation and facilitates
17
multi-attribute considerations that help transcend price as the only negotiative dimension.
Ultimately, MARI provides a framework for value creation, in a strategic sense, by
allowing buyers and sellers to sufficiently differentiate their preferences and offerings
from other players in the market, and thereby establish a competitive advantage. The
unique contributions of this thesis include:
1. Formulation and implementation of the theory of multi-attribute matching;
2. Design of a general architecture that includes:
a. A mechanism for expressing and modeling utility functions;
b. Matching algorithms;
c. Dynamic, domain-independent marketplace creation. The design of the
system is sufficiently flexible that creating an entirely new market merely
entails editing two XML files.
3. Evaluation of the system via simulations of market scenarios and user testing.
1.3 Roadmap
Chapter 2 provides a functional overview of the application domain and example usage
of MARI, and delivers a high-level view of the contribution, importance and relevance of
the system. Chapter 3 presents related work in transaction brokering and user preferencemodeling technologies in contemporary electronic markets, along with the limitations of
these approaches. This chapter underscores the compelling need for system such as
MARI, and situates our work relative to other research efforts.
Chapter 4 details how the MARI system actually works, specifying the algorithms
and technologies employed in the process of capturing and modeling user preferences,
and matching buyers and sellers. Chapter 5 elucidates the theory and rationale behind our
algorithms and technologies, and validates these choices from a theoretical perspective.
Chapter 6 discusses the functional design of the MARI system, giving an overview of the
major functional modules and top-level user-interaction schema. Chapter 7 describes
MARI's front-end Web based interface, the user experience, and major user-driven
operations, with the help of flowcharts and screenshots.
18
Chapters 8 and 9 discuss how MARI has been evaluated via simulations of market
scenarios and via actual user-testing with human participants. Our simulations effectively
illustrate the range of MARI's functionality in actual market settings and allow the reader
to gain further insight into how participants in electronic markets may benefit from such a
system. Bringing the human element into the picture, findings from our user studies shed
light on the extent to which users feel satisfied with the system, and provide important
cues for future improvements.
Chapter 10 concludes the thesis and discusses potential future research directions.
Appendices A and B detail the actual implementation of MARI's data-model, and backend algorithms, respectively. In addition to presenting implementation-level flowcharts
and module-dependency
diagrams, these chapters
discuss the rationale behind
implementation decisions and elucidate tradeoffs. Appendix C provides suggestions for
further reading about MARI, and cites some of the most important publications related to
the project.
19
20
2 THE MARI SYSTEM
2.1 Introduction
MARI embodies a trend, expected to be key to the electronic marketplaces of tomorrow.
Specifically, we believe that negotiations will be highly complex and participants will
engage in negotiation over various aspects of a transaction, price being only one of many
considerations.
MARI represents a general purpose architecture that is capable of supporting
multiple sellers and buyers within multiple product domains. To evaluate the project, we
deployed the MARI infrastructure in the context of a "services marketplace" in which
language translation services are bought and sold. Hence, MARI is specifically encoded
with a "language translation service" ontology and suitable complementary data.
2.2 Motivation
Contemporary electronic markets are deficient for two major reasons: (a). They
accentuate the importance of price in matching buyers and sellers; and (b). They severely
lack any form of automation, often mandating a significant time commitment on the part
of the human participant.
State of the art online marketplaces, such as Chemdex [2], Priceline [35], Elance
[11], etc., do not provide any means for market participants to be able to transcend the
singular importance of price and convey the full "value proposition" of the holistic
product offering. When making buying decisions, we all make tradeoffs across product
features (additional RAM in lieu of a faster processor when purchasing a computer, for
instance) and also associate different levels of importance with different features (number
of stopovers being much more important than the brand of the airline when buying an air
ticket, for instance). Unfortunately, current electronic markets provide no mechanism by
which market participants may express such aspects of their preferences. Further
accentuating this problem, online auction systems additionally have a tendency to foster a
spirit of adversarial competitiveness in the buying process. In systems such as Ebay [10]
21
and Amazon Auctions [2], not only must a buyer first undergo the burden of uniquely
identifying the exact product she is seeking, but furthermore, she must then enter into a
inflexible and antagonistic bidding interplay with the seller.
Contemporary electronic markets also suffer from a severe lack of automation.
While some level of automation has begun to be introduced, such as "bidding agents" in
E-bay [10], which can be programmed to automatically increment bids up to a user
defined threshold at pre-specified increments, as e-commerce becomes more pervasive,
much more automation will be needed in both generating bids and asks on behalf of
market participants, as well as facilitating the actual matching between buyers and sellers.
In general, we have found that there is no existing satisfying system that allows
buyers and sellers to express their underlying multi-attribute preferences in an intuitive
and understandable fashion, and which uses these preferences to facilitate automatic, yet
non-binding, matching of transaction partners. Our work represents a step in the direction
of filling this void.
2.3 The MARI System
MARI is a general market architecture that can be instantiated in different
domains. MARI attempts to overcome many of the deficiencies of contemporary
electronic markets and represents a novel paradigm for gathering user preferences, and
for matching buyers and sellers.
MARI allows market participants to express their underlying preferences with
greater expressiveness. Market participants specify what they are ideally looking for, and
associate a price with this ideal configuration. Additionally, market participants are able
to specify permissible ranges for feature values they are willing to be flexible on and,
furthermore, they are able to visually, in an intuitive fashion, associate preference
functions with attributes. Based upon this input, MARI asks the user a small number of
simple questions, that allow the system to generate an accurate mathematical model of
the user's underlying preferences.
MARI facilitates automation via the instantiation of buyer and seller agents that
act as manifestations of their owners' revealed preferences. These agents autonomously
22
generate bids and asks on behalf of their owners, which the system uses to "optimally"
match transaction partners. Figure 1 schematically illustrates this notion. Our current
heuristic of optimality is that aggregate "surplus," which is currently taken to be the
cumulative bid-ask spread across all buyer-seller pairs, and which can be shown to be
equivalent to the economic notion of aggregate "welfare," [15, 38] is maximized. In
practice, the choice of optimization heuristic is configurable by the "market maker." The
final matching produced by our system can be shown to be Pareto efficient [15, 38],
meaning that no one can be made better off without making someone else worse off. A
strong condition, Pareto efficiency guarantees that our system does not leave any
potential gains unexploited.
MARI facilitates matching of buyers and sellers on multiple attributes, rather than
just price. MARI is unique in the sense that it allows both the buyer as well as the seller
to mutually exercise control and, furthermore, allows market participants to express
preferences for the attributes of the transaction partner (for instance, a buyer can express
preferences for desired seller reputation or skill), in addition to the attributes of the
underlying product. Our matching algorithm balances the myopic, selfish interests of
individualistic agents at a local level with the desire to achieve "welfare" maximization
and Pareto efficiency at a global level. Our model of user preferences allows us to predict
how much a given user is willing to bid (or ask) for a given transaction partner, as well as
to gauge how "far" the transaction partner lies from the user's desired ideal offer
configuration.
For each user we look at each qualified transaction partner to see whether a deal
is possible and, if so, what the "Optimal Transaction Configuration" (OTC) would be.
Exploring the space of possible deals is accomplished by exploring the space defined by
flexible attribute ranges, as specified by the buyer and seller, and is equivalent to
automated negotiation over the underlying attribute values. We explore the attribute
space to find a deal configuration that is mutually agreeable and beneficial from both the
buyer's and seller's perspective. The OTC is simply a particular configuration of
attributes, or a "deal," that is consistent with the permissible attribute ranges that both the
buyer and the seller are willing to tolerate, and is the "deal" which lies "closest" to both
the buyer's and seller' ideal offers. The notion of the OTC captures the "deal"
23
configuration that is myopically optimal in the context of a specific buyer-seller pairing,
from the self-interested perspectives of the buyer and seller agents involved in this
pairing. Calculating the surplus corresponding to the OTC allows us to gauge how the
"goodness" (in terms of aggregate welfare or surplus) of this pairing might compare with
that of other pairings. Since, for any given user, an OTC will be computed for every
qualified transaction partner, comparing the relative "goodness" of the various OTCs
gives us a global heuristic of surplus maximization by which we may decide which of the
various qualified transaction partners the user ought to be ultimately paired with.
Even after having delineated tentative transaction partners, MARI gives market
participants flexibility in choosing to confirm or reject the proposed match. A proposed
match between a buyer and seller can only be consummated by explicit mutual
confirmation from both parties involved. Moreover, without mutual confirmation, buyer
and seller agents continue to remain "active," or eligible to be matched in future market
cycles, thereby maximizing the potential set of suitable alternatives.
Ultimately, MARI provides a framework by which buyers and sellers may
differentiate themselves to create value. The system facilitates value creation, in a
strategic sense, by allowing buyers and sellers to sufficiently differentiate their
preferences and offerings from other players in the market, and thereby establish a
competitive advantage.
MARI is intended to be instantiated by a "market maker" within a specific product
domain. The design of the system is sufficiently flexible that creating an entirely new
market merely entails editing two XML files. Within the context of any specific product
domain, the market maker can use these XML files to specify relevant domain specific
knowledge, such as the domain ontology (vocabulary used to describe product features),
and user "profiles" (stereotype driven "profiles" of default user preferences). We assume
that the market maker must independently deal with implementation specific issues
relating to things such as security, scalability, fulfillment guarantees, etc.
24
Figure 1: Agents Manifest Their Owners' Preferences, and are Optimally Matched by the System
2.4 Example Usage
To illustrate the functionality of the system, we now turn towards a simplified example of
a language translation marketplace in which there are two types of buyers and two types
of sellers1 . The buyers and sellers are differentiated in the following ways:
1. Professional Buyer (BPRo): Wants a fast translation, is sensitive to seller
reputation and skill. Possesses a high reputation rating.
2.
Casual Buyer (BcAs): Is not very sensitive to time, seller reputation or skill.
Possesses a low reputation rating.
3. ProfessionalSeller (SpRo): Does not mind completing a translation job under time
pressure, is sensitive to buyer reputation. Possesses a high reputation and skill
rating.
'This results presented in this example are concretely substantiated via a market simulation, in Chapter 8.
25
4. Casual Seller (SCAs): Faces a large opportunity cost if asked to complete a
translation under time pressure, is not very sensitive to buyer reputation.
Possesses a lot reputation and skill rating.
MARI makes it feasible for these buyers and sellers to express their differential
preferences for prospective transaction partners. Figure 2 shows system generated 2 bids
and asks corresponding to these preferences.
Figure 2: Bids and Asks Corresponding to User Preferences
From Figure 2 we see that the Professional Buyer is willing to pay less for the Casual
Translator than for the Professional Translator, since the Casual Translator possesses a
lower reputation and skill rating. The Casual Buyer on the other hand does not care for
the higher skill and reputation ratings of the Professional Translator has, and is hence
unwilling to pay any premium over what he is willing to pay for the Casual Translator.
Numerical values used are based on actual system generated data. See Chapter 8 for precise details of an
analogous simulation that we conducted.
2
26
The Professional Translator is willing to charge less to the Professional Buyer
than the Casual Buyer, as a consequence of the former's higher reputation rating. The
Casual Translator, on the other hand, actually wants to charge more to the Professional
Buyer than the Casual Buyer, since the former mandates a faster translation, which
imposes a higher opportunity cost on the Casual Translator3
Based upon these preferences, MARI matches BPRO with SPRO at a clearing price
of $90 (midway in between the $100 bid and $80 ask), and matches BCAS with SCAS at a
clearing price of $45. The aggregate surplus, which in this case corresponds to the total
value created in the marketplace, is maximized and the pairing is Pareto efficient.
In traditional markets, there is no mechanism by which a professional buyer
(BPRO), for instance, can instantiate an agent with variable degrees of preference and
valuation for different (professional and casual) sellers. The buyer can merely assume
that there is some mixture of the two types of sellers in the market and bid something in
between his differentiated bids corresponding to different sellers. For the sake of
simplicity lets assume that in a price-matched marketplace BPRO would bids $85 (halfway
in between the differentiated bids). Using the same reasoning, BCAS would bid $50, SPRO
would ask $90 and SCAS would ask $60. In this case, BPRO will be undesirably matched
with SCAS.
Figure 3 and Figure 4 illustrate how MARI facilitates greater value creation, and
more appropriate allocation of scarce resources compared to traditional marketplaces.
3 Chapter 8 shows in greater detail how these buyers and sellers would express these valuations.
27
Figure 3: Value Created in a Traditional Market
Figure 4: Value Created by MARI
28
2.5 ApplicationDomain: Service Marketplaces
A substantial motivation for the choice of "services marketplaces" in general, and a
language-translation marketplace in particular, as the application domain for this project
lies in our belief [33] that in the future, as people become increasingly networked, it will
be easier for individuals to mutually help one another. People who share each other's
notions of quality, and other such intangible attributes, are in a much better position to be
helpful to one another, at least until agents become truly "intelligent," and can be the
ones helping people with complex tasks. For instance, given the extremely rudimentary
capabilities of current state of the art automated translation systems [1], a (networked)
person would be much better off if she could receive help with a language translation
problem from a human expert located somewhere else. In this context, it is reasonable to
postulate that the importance of technologies that mediate communications amongst end
users will emerge as being of critical importance.
2.6 The Language Translation Marketplace
In order to be able to participate in the MARI marketplace, a "seller" creates a "selling
agent" that is aware of its owner's level of expertise, availability, compensation expectations, and other special constraints, such as requirements for the buyer. Similarly, a
"buyer" creates a "buying agent" that understands the exact needs of its owner such as
degree of expertise desired, time-sensitivity or urgency with which information is needed,
range and type of compensation that the buyer is willing to offer the seller, and other
special constraints, such as minimum requirements on the seller's reputation level.
Additionally, the buying and selling agents also encapsulate information on how different
qualified sellers or buyers, respectively, can be rank ordered in degree of relative
preference. Subsequently, the "market" automatically matches buyers and sellers. Once a
match has been made, other media (such as email, cell-phone, as well as richer media)
may be employed to implement the "knowledge transfer relationship" in practice.
A benefit of focusing specifically on "services marketplaces" and "information
goods" is that it allows us to concentrate more on the attributes relevant to the parties
attempting to engage in the transaction without getting overwhelmed by the details
29
inherent to the product itself. For many information goods, the characteristics of the seller
actually serve to define the good itself. For instance, in a language translation
marketplace, the fact that the seller of the translation service is considered an expert, and
has a high reputation rating associated with her to substantiate this claim, implicitly
conveys the nature and quality of the "good," in this case the translation service. Indeed,
one can argue that in the context of services marketplaces, in which the service being
bought and sold lacks tangible manifestation and is hence not as easily susceptible to
objective evaluation, the ability to be able to ontologically segregate and prioritize the
various subtle impinging factors gains significance and relevance. Hence, the choice of
services marketplaces, in which intangible services and information are bought and sold,
is an appropriate and fitting choice as the target application domain for this project.
The electronic services marketplace built with MARI allows us to instantaneously
match buyers and sellers in real-time. The resulting transactions capture both the
marginal utility that the buyer derives, as well as the marginal cost that the seller incurs,
ensuring market efficiency from an economic point of view 4 . What is remarkable about
this infrastructure is that, by using a highly mediated approach, we are able to
successfully coordinate buyers and sellers in real-time so as to facilitate ad-hoc
interactions. Ultimately, market forces will push the system towards an equilibrium
where the time and efforts of a true expert are optimally used for just those translation
jobs that cannot easily be dealt with by anyone else. Resources will be bid up or down to
reflect their true worth based upon a continuously updating balance between supply and
demand of the scarce resource, and will thus be optimally allocated.
4 These terms are explained further in Chapter 4 .
30
3 RELATED WORK
MARI broadly relates to: (i). Theoretical work done in the sphere of game theory and
economic modeling; and, (ii). Practical and research systems deployed in the context of
contemporary electronic markets. We sequentially consider each of these categories.
3.1 Game Theory and Economic Modeling
A substantial amount of work in the realm of game theory and economic modeling has
been done to understand and devise methods for agents to interact in various contexts.
For our purposes, auction mechanisms, market-oriented programming, coalitionformation techniques and contracting methods represent the most important related areas
of relevance. We briefly discuss each of these approaches in relation to the MARI
system.
Historically, auctions have been a popular means for brokering transactions.
While it is possible to formulate many different kinds of auction mechanisms, the most
common patterns of interaction have been one-to-many auction protocols [32], where one
agent initiates an auction and several other agents can bid, and many-to-many protocols
[46], where several agents initiate an auction and several agents may bid. Auction
mechanisms typically differ in the type of protocol used in the auction (ascending price,
descending price, etc.) [15], and the bidding strategy adopted by the participating agents.
The MAGMA system [23, 22] is an example of an architecture for an agent-based virtual
market that relies upon an auction mechanism. Currently, MAGMA uses a Vickery
auction mechanism as a negotiation method, but it is capable of incorporating other
protocols. In MARI we chose not to adopt an auction mechanism, since one of the
explicit design goals of the system has been to circumvent the adversarial competition
between buyers and sellers that auctions typically induce. The main difference between
auction-based marketplaces and MARI is that the former match based on a single
attribute, namely price, while MARI uses multiple-attributes as dimensions for
negotiation and brokering. Furthermore, auction mechanisms exhibit a great deal of
variability depending upon what protocol (English, Dutch, Vickery etc.) [15, 40] is used.
31
Hence, using an auction mechanism to create a general, domain-independent system such
as MARI, while trying to preserve desirable economic invariants such as Pareto
optimality, would not be feasible without imposing significant and specialized
restrictions upon participating agents. This would run counter to one of MARI's design
philosophies, that individual agents can be relatively naive and lightweight, since most
processing and computation is performed centrally on the MARI server.
Recently, there has been some work in the area of multi-attribute, combinatorial
auctions [42]. Such multi-attribute auction schemes usually mandate that buyers and
sellers specify several mutually exclusive "bundles" of what they are looking for. A
combinatorial auction is then used to allocate a suitable bundle for each buyer-seller pair.
The difference between such schemes and MARI, is that our system does not require that
market participants explicitly articulate every single acceptable bundle. Rather, MARI
searches over the attribute space and automatically finds an acceptable "deal" or
transaction configuration, and derives the associated transaction price.
MARI also relates to work done in the area of market-oriented programming, an
approach to distributed computation based on market price mechanisms [4, 5, 24, 25, 43,
50]. Market-oriented programming exploits the institution of markets and models markets
to solve problems that fundamentally pertain to distributed resource allocation.
Participating agents in such systems typically act in a very restricted manner - by
offering to buy or sell quantities of commodities at fixed prices. The system is eventually
expected to reach an equilibrium, at which point the market has computed an allocation
of resources corresponding to each participating agent [5, 24, 25]. However, such
approaches are applicable only when there are several units of each kind of good and
when the number of agents is large - conditions which would clearly be restrictive in a
system such as MARI [40]. Another issue is that there can be situations in which reaching
an equilibrium takes an inordinate amount of time, and the system cannot be guaranteed
to converge [24].
Another technique for resource allocation in agent-based markets has been that of
coalition formation [30, 44, 45]. The formation of coalitions has been studied both in the
context of multi-agent systems and distributed problem solving environments. Typically
agents are always built to maximize the overall performance of the system, and design of
32
the coalition based mechanism typically hinges on how coalitions are formed or
structured so as to maximize the overall expected utility of the agents [40]. However,
finding the coalition structure that maximizes the overall utility of the system is an NP
complete problem [40], which creates computational bottlenecks. Moreover, in a multiagent environment, such as MARI, the problem of how joint utility should be ultimately
divided amongst the participating self-interested agents itself becomes a difficult problem
to resolve. In addition to these reasons, we chose not to adopt a coalition-oriented
mechanism since deploying it in the context of MARI would impose further constraints,
such as increased communication costs and computation time, not to mention the
complexity of devising algorithms and metaphors for coalition formation in the first
place.
Contracting methods are yet another approach towards inducing cooperation
amongst agents in multi-agent systems. Applied to electronic markets, contract based
mechanisms typically entail that one self-interested agent try to convince another selfinterested agent to help it, in return for some promise of reward [40]. Perhaps the best
known framework for automated contracting is the Contract Net protocol [39, 46]. This
protocol provides a formalization of the bidding and decision processes based on
marginal cost calculations by localized agents. The main question that arises when
thinking about a contract metaphor in a setting such as MARI is how one agent might be
able to convince another agent to undertake a contract for it when the agents do not share
a global task and when the agents are strictly self-interested.
In summary, game theoretic and economics techniques provide useful metaphors for
development of transactional agent-based e-commerce systems. However, the choice of a
specific technique for a given domain depends on a variety of factors including: whether
the agents are self-interested, the number of agents in the environment, the type of
agreement, if any, that agents need to reach, and the amount and type of information that
agents have about one another [40]. Given our assessment of the most popular game
theoretic approaches, we did not feel that a direct application of any of the abovementioned metaphors would be appropriate for a system such as MARI. Even though we
borrow significantly from the field of market-oriented allocation mechanisms, given our
33
high-level objectives and design philosophy, we have devised a novel and, in many ways,
a simpler and less restrictive schema.
3.2 Existing Systems
MARI relates to online negotiation systems and auctions, such as Kasbah [19] and
AuctionBot [32], and to commercial systems provided by Moai [26], TradingDynamics
[47] and others. It differs from these in its bilateral, multi-attribute methodology for
matching of buyers and sellers. Our model, implicitly incorporating negotiation, provides
a richer alternative to these systems and successfully circumvents the adversarial
competitiveness of online auctions.
Unlike most online shopping systems which generally operate in only one stage of
the online shopping process [31], MARI operates in three core stages - namely product
brokering, merchant brokering, and (implicitly) negotiation - to provide a unified
experience that better facilitates economically
efficient and socially desirable
transactions. MARI amalgamates features of the 'Market Maker' [9] and 'Tete-A-Tete'
[37] projects at the Media Lab, and extends these to create a more comprehensive
solution.
MARI relates to first generation price-comparison systems such as BargainFinder
[3] and Jango [17], but goes much further than the rudimentary functionality afforded by
such tools. MARI goes beyond just bid and ask prices to include the attributes of the
transaction parties as dimensions for consideration and differentiation. MARI relates to
second generation value comparison shopping systems such as Personalogic [34],
MySimon [27], and the Frictionless ValueShopper [12] in that it integrates ideas from
multi-attribute utility theory to meaningfully facilitate the exchange of complex and
heterogeneous products. It differs from these systems in that: (i). It is two-way, allowing
both the buyer and seller to express preferences; and (ii). It facilitates significant
automation, allowing agents to act as proxies for buyers and sellers.
MARI also relates to overtly agent-based systems such as Lost Wax's "e-Market"
platform [21], a software solution targeted specifically at the business-to-business (B2B)
e-commerce space. Akin to MARI, systems such as Lost Wax's "e-Market" espouse the
34
philosophy that individual intelligent agents ought to automate negotiation and aspects of
transactions between e-market participants. Most such systems, and "e-Market" in
particular, rely upon some derivation of the standard agent Belief Desire Intention (BDI)
architecture to construct and evaluate plans for agents [41]. Subsequently, participating
agents are expected to formulate offers, evaluate counteroffers, and make decision about
accepting or declining negotiated contracts. MARI differs from such systems in several
ways. Most obviously, MARI mitigates the complexity that needs to be engineered in
individual agents, and does not mandate that agents be sophisticated enough to be able to
evaluate and formulate offers. This is desirable, since in many application domains,
particularly in mobile computing, individual agents face
severe computational
limitations. Further, by delineating deals and transaction partners in a centralized fashion,
MARI substantially mitigates the computational time and overhead that is incurred in the
process of negotiating aspects of deals and matching transaction partners, while, at the
same time, affording individual agents a great deal of flexibility in consummating deals
and gaining exposure to potential transaction partners. Finally, by having a centralized
entity mediate interactions between participating agents, we are able to significantly
reduce the scope of potential security threats and possibly damaging behavior on the part
of individual agents, while guaranteeing the existence of desirable global optimality
metrics, such as welfare maximization.
35
36
4 ALGORITHMS AND TECHNOLOGIES USED
4.1 Modeling User Preferences
4.1.1 Overview
When a user5 (buyer or seller) initially logs onto MARI, he or she must specify
whether her intent is to put a product or service up for sale or to purchase a product or
service. Our intent is to gauge the user's multi-attribute utility function so as to be able to
accurately assess how the user would value products that have not been explicitly seen or
"rated" before. Being able to make such inferences is integral to the successful
functioning of MARI's core matching algorithm.
MARI's market structure most closely resembles a "monopolistic competition"
[38] - each seller has the ability to differentiate her products or services from those of
other sellers 6 . The market structure is monopolistic in the sense that each seller has the
ability to set her own price, rather than merely accept the prevalent "market price" as
under perfect competition and, thus, can be said to exercise market power. On the other
hand, each seller must still compete, in terms of price and the range of products offered,
with other sellers since they are all effectively trying to find transaction partners from a
common underlying set of buyers. Moreover, there are no barriers to entry, and new
sellers are free to enter the market. In this way, the market structure also resembles that of
a competitive industry.
4.1.2 Capturing User Preferences
Each distinct buyer or seller is represented within MARI by an agent. The "buyer
agent" embodies the buyer's revealed preferences with respect to the desired resource.
5 We use the term "user" to refer specifically to a buyer or seller. By contrast, we use the term "market
maker" to refer to the system administrator who instantiates MARI within the context of a specific product
domain.
6 Since we specifically focus on complex products and services that consists of multiple, often nontangible, attributes (such as seller reputation, for example), one could argue that the merchant offerings are
differentiated a priori. Indeed, one can reasonably argue that in such product domains, it is extremely
difficult, if not simply infeasible, for a given seller to perfectly replicate another seller's product offering.
37
Similarly, "seller agents" embody the preferences and interests of sellers. Each agent is
customized to the needs and desires of its owner, and attempts to advocate on the owner's
behalf when finding suitable transaction partners. These agents are then used by the
system to coordinate the preferences and interests of each party involved. MARI's
interaction with the user can be decomposed into several steps, and results in an agent
being created to represent the user.
Step 1). Specifying the Ideal Offer (see Figure 5): The user specifies a "referential" or
"preferred" configuration, or offer, which consists of specific product and transaction
partner attribute values, as derived from the underlying domain ontology. Each ontologyspecific attribute has a predefined "default" value associated with it, and the user can
accept or override these defaults. The user can also modify which attributes are fixed and
which are flexible and must also associate a monetary valuation ("bid" or "ask") with this
offer (referred to as the pbsvalue).
In general, an attribute can be either "fixed" or "flexible". A fixed attribute is one
whose value, as specified by the user, is used for transaction party qualification. By
contrast, flexible attributes have associated ranges, and are used for transaction party
valuation. For instance, in the example of language translation services (buyer's
perspective), the number of words to be translated could be a fixed attribute, while the
reputation of the seller, the degree of expertise of the seller, and the amount of time within
which the translation should be completed could be flexible attributes. Each fixed attribute
has a predefined set of permissible values, and the user must select acceptable values from
this set. For instance, the permissible values for 'number of words to be translated' might
be the set of non-negative integers.
Step 2). GatheringRanges of Flexible Attributes (see Figure 5): Users must also associate
a permissible range of values with each flexible attribute. Flexible attributes essentially
embody the tradeoffs that a given user is willing to make. Associated utility functions
(discussed in section 4.1.3) define how the user's valuation changes as flexible attributes
vary over their permissible ranges.
38
Figure 5: Specifying the Ideal Offer and Permissible Ranges for Flexible Attributes
4.1.3 Modeling User Utility Functions
For each flexible attribute, the aim is to gather sufficient information from the
user so as to be able to accurately infer how her (uni-dimensional) utility might change as
the flexible attribute varies over its permissible range, while all other attributes are held at
their ideal (offer) values. As such, we require the user to specify the range of permissible
valuations, referred to as maxvalue and minvalue in Equation 1, associated with the
flexible attribute being held at the high and low endpoints of its permissible range,
respectively, while all other attributes are held fixed at their optimal or offer values.
Doing so enables us to accurately assess how the user would value product offerings and
transaction partners that have not been explicitly seen or "rated" before. Based upon the
39
market maker's configuration parameters, MARI models the user's utility function as
follows:
Step 1). Visually Selecting Utility Functions: When first instantiating MARI, the market
maker is required to visually associate a generic (pre-defined) mathematical function with
each flexible attribute (see Figure 6). Users could be given the option of being able to
override these "default" functions during the offer specification process.
Figure 6: The Market Maker Visually Associates Utility Functions with Flexible Attributes
Step 2). Quantifying Utility Functions: Using the generalized equation form of the utility
function selected by the market maker (see Table 1), in conjunction with the pbsvalue,
maxvalue, and minvalue parameters specified by a given user, MARI is able to compute a
mathematical approximation to the utility function corresponding to each flexible attribute.
The polynomial used to represent the function is usually a quadratic. Higher order
as
polynomial approximations can optionally be calculated using Lagrange interpolation,
described in Step 3 below.
40
For example, let us assume that a given buyer is willing to accept a "seller
reputation" ranging from 6 to 10. Assume that in her "referential offer" the buyer
specifies a preferred value of 6. Further, say the market maker has pre-associated UF 2
with this flexible attribute as it varies over its range - the choice of this utility function
would reflect the fact that the buyer is willing to bid higher as the seller's reputation
increases, and that her valuation increases exponentially as reputation approaches the
maximum possible. In this case we can derive the equation 7 which captures the change in
the buyer's utility as reputation varies, as:
maxvalue - pbsvalue
2
UF2 (X)=K ~
2
(hx,
(xhi
(xh+
- x10w) 2(hi
+ pbsvalue +
- pbsvaue)(x,1 ,) X
2 +(-2)(maxvalue
)
(maxvalue - pbsvaue)(xa
(2
1
( Xhj
-X
~
x1 ,X 2
_~ X1.
)
)2
0
X/Ow 2
Equation 1
Where:
x1OW= the value of the attribute specified in the referential offer (i.e. 6);
Xhi = high endpoint of the permissible range (i.e. 10).
7 This function is derived using standard algebraic techniques along with special properties of quadratic
functions. In particular, we have used the fact that the global minima of a quadratic, of the form
y=ax+
bx+c, occurs at -,
2a
that the quadratic function corresponding to UF 2 is monotonically
increasing, and that the user has already revealed two data points, (x, y), on the curve: (x 0,, pbsvalue) and
(xhi,
maxvalue).
41
Functional Generalization
(a, b, c representarbitrary,
Name
Graph Shape
non-negative constants)
UF1
(ax:±b)
UF 2
(ax2 ±bx c)
UF 3
(-ax2 :bx c)
UF 4
(-axb)
UF5
(ax 2 ±bx± c)
UF 6
(-ax2 ±bx±c)
U7
__9
UFw
x <(midpoint of permissible range) ? (ax b):
(-ax ±b)
x < (midpoint of permissible range) ?
(ax 2 ±bx± c) : (ax2 bxic)
x < (midpoint of permissible range) ? (ax2 ±bx ±c) : (-ax2. bx ±c)
x < (midpoint of permissible range) ? (-ax b):
UF 12
x < (midpoint of permissible range) ?
(ax bxC) : (ax 2 Jbx c)
x < (midpoint of permissible range) ? (ax 2 ibx ±c): (-ax bx ±c)
UF 13
x = (high end point of permissible range) ? 1 : 0
UF 14
x = (high end point of permissible range) ? 0 : 1
UF5
x=1Z
UF 16
x
UF 17
x = (low end point of permissible range) ? 0 : 1
UF11
= (low
end point of permissible range) ? 1 : 0
Table 1: MARI's Predefined Generic Utility Functions (x is a place-holder variable for a value of the
flexible attribute over its permissible range)
Step 3). Refining Utility Functions through Revealed Preferences (Optional): The market
maker can optionally configure the system to fine-tune the quadratic utility functions
captured in Step 2. This requires that the market maker iteratively "train" the system. The
market maker is asked to explicitly "valuate" hypothetical product offerings strategically
42
chosen to representatively span the space of all relevant product offerings. Essentially, the
preferences expressed by the market maker are taken to be a benchmark set of "reasonable"
preferences. Using these revealed preferences in conjunction with offer data that is specific
to a particular user, the system facilitates the construction of a (iteratively refined)
piecewise, linear approximation of the user's utility function.
If there are n flexible attributes, then the user's utility function can be visualized as
an n dimensional hyper plane in (n+1) dimensions (where the (n+])" dimension is the
numerical "monetary" valuation associated with each point on the hyper plane). Using
Lagrange Interpolation, in conjunction with an iterative scheme we shall refer to as "delta
scaling," it becomes feasible to determine higher degree polynomial approximations for
utility functions.
In general, we can use Lagrange Interpolation to approximate the value of any
(n -1)s degree polynomial, f, at any arbitrary point, x, provided that we already know the
values of the function (fo, fl, ..., fni) at n distinct points (xo, x 1, ... , xni), by using the
following expression:
-y
.Ax) =f
(
-i-2.(x
(-X
"
"-2
+...+
(x
-x;
-XxaO
-Xi)(-(x
-x&-2)
Equation 2
The term "delta scaling" refers to the technique by which the system picks points
in the attribute space to be valuated by the market maker. The algorithm goes through
iterations referred to as "delta phases." In each delta phase, the algorithm unidimensionally varies the value of a single flexible attribute (by "delta"), while all other
attributes are held fixed at their ideal (offer) values, and asks the market maker to
explicitly associate a valuation with the feature set, thus effectively obtaining an
additional data point relevant to this attribute. Subsequently, the algorithm performs
Lagrange interpolation to compute a higher degree (uni-dimensional) utility function for
the attribute. In a given delta phase, the algorithm does this for each attribute, thereby
improving the degree of each attribute's associated utility function by at least one. The
43
market maker thus provides MARI with an internal model of reasonable user preferences.
This model can be though of as a "template," that is subsequently adapted to user-specific
data.
4.2 Matching Buyers and Sellers
4.2.1 Overview
Finding automated matches between buyer and seller agents in electronic markets
has been at the forefront of research in multi-agent e-business systems. While a number
of heuristics have been explored for brokering transactions, in the vast majority of
systems there is potentially a conflict between maximizing global welfare or surplus8 ,
versus allowing each agent to act in self interest to optimize its individual gains.
Maximizing aggregate welfare for a collection of buyer and seller agents is not
necessarily harmonious with allowing each individual economic agent to act in selfinterest9. This is equivalent to saying that a centralized entity that allocates scarce
resources, seeking to maximize the aggregate profit of a "society" of agents, may leave
some individual agents faring very poorly, essentially as a "sacrifice" to improve the
aggregate lot of society at large. However, from the perspective of the self-interested,
individualistic agent who is required to make this sacrifice, this is hardly an attractive
outcome!
To illustrate this problem, let us consider a stylized example of routing traffic
along major routes. For example, lets say that a fictitious country consists of two cities,
C1 and C2, with two roads connecting the cities, R1 and R2 , such that R2 (side-streets) is a
significantly more time consuming route than R1 (freeway). Further, lets say that, at a
given time, 100 agents have to travel from CI to C2, and that the capacity of each
interconnecting road is 98. In this case, each individual agent would clearly prefer to
take R, (freeway), since it is faster and quicker. However, if all 100 agents were to take
8 Aggregate surplus is the sum of consumer and producer surplus. Consumer surplus is defined as the
difference between the amount a consumer is willing to pay for a good and the amount she actually pays.
Producer surplus is defined as the difference in the market price the producer receives for a good and the
marginal cost incurred in its production [5].
9 The converse is also true: allowing each agent to act in self-interest does not, in any way, guarantee that
"society," as a whole, will be well off.
44
R1, the freeway would exceed capacity, leading to traffic jams and thereby depleting the
time and speed advantages that it could otherwise had offered. As such, a centralized
entity that regulates how traffic is routed would choose to allow only 98 agents to take R1
and would require that the remaining two agents make a "sacrifice" by taking R2, so as to
improve the lot of society at large. The resulting configuration can be shown to maximize
aggregate surplus and to be "Pareto optimal" [15, 38], meaning that no agent can be made
better off without making another agent worse off (transferring an agent from R2 to R1
would require an agent to move from R1 to R2 , or would otherwise make things miserable
for all agents on R1 due to overcrowding). In general, it is precisely due to the outcome of
welfare or "surplus" maximization and Pareto optimality that centrally mediated resource
allocation techniques have been embraced in the past. However, as demonstrated in this
example, this approach clearly has the potential to alienate some agents. Since each agent
is concerned primarily with its own well being, and not with the benefit of society as a
whole, this scheme clearly disincentives individualistic agents from participating in the
first place.
It is worth contrasting the above argument with the classical laissez-faire
economics contention that, given perfect information and rational behavior on the part of
each economic agent, allowing each agent to act freely in its selfish self-interest will
translate into society being best off (first welfare theorem of neoclassical economics) [15,
38]. However, in general, agent-based electronic markets are characterized neither by
perfect information (often computationally intractable for software agents), nor perfect
rationalityl. Hence, the laissez-faire argument cannot be assumed to hold in general, and
more generically applicable techniques for matching buyer and seller agents, such as the
one proposed here, are needed.
As part of the MARI system, we have developed a technique applicable to
brokering transactions in agent-based electronic markets that permits us to maximize
aggregate social welfare (defined as aggregate surplus) while, at the same time,
permitting each agent to find a transaction partner that is myopically optimal from its
self-interested perspective.
10 This is especially true if agents are created by third parties and simply participate in the market using
some published market interface. In general, the market cannot make any assumptions about rational
behavior on the part of such agents.
45
As discussed previously, MARI allows users to specify an ideal offer, as well as
to cite ranges of attribute values over which they are willing to be flexible. Using this
information, we can build a mathematical model of user utility functions. This model of
user preferences allows us to predict how much a given user is willing to bid (or ask) for
a given transaction partner, as well as to gauge how "far" the transaction partner lies from
the user's desired ideal offer configuration.
Specifically, for each buyer we can look at each qualified seller to see whether a
deal is possible and, if so, what the "Optimal Transaction Configuration" (OTC) would
be. Exploring the space of possible deals is equivalent to exploring the space defined by
flexible attribute ranges, as specified by the buyer and seller. The OTC is simply a
particular configuration of attributes, or a "deal," that is consistent with the permissible
attribute ranges that both the buyer and the seller are willing to tolerate, and is the "deal"
which lies "closest" to the buyer's and seller' ideal offers.
The notion of the OTC captures the "deal" configuration that is myopically
optimal in the context of a specific buyer-seller pairing, from the self-interested
perspectives of the two buyer and seller agents involved in this pairing. Calculating the
surplus (defined as the bid-ask spread) corresponding to the OTC allows us to gauge how
the "goodness" (in terms of aggregate welfare or surplus) of this pairing might compare
with that of other pairings. Since, for any given buyer, an OTC will be computed for
every qualified seller, comparing the relative "goodness" of the various OTCs gives us a
global heuristic of surplus maximization by which we may decide which of the various
qualified sellers the buyer ought to be ultimately paired with.
4.2.2 Generating Data Points from Functional Approximations
A mathematical model of preferences allows us to predict how much a given user
would be willing to bid (or ask) for a given transaction partner. We begin by generating
additional data points, using the seed data provided to us by the user. In order to
formulate a functional generalization for a user's multi-dimensional utility function, we
use a quadratic least squares approximation technique [20].
" Here, as in other parts of the paper, we will take the buyer's point of view in discussing our brokering
methodology. We could just as well have adopted the seller's perspective, without loss of generality.
46
To do so, we first generate an nxm matrix A for every user. Every row of A
corresponds to a hypothetical configuration of attributes, or market "bundles," derived
using the user's ideal offer in conjunction with flexible attribute ranges. For example, lets
consider a "Professional Buyer" BPRO. Lets assume BPRO possesses a reputation of 10
and, ideally, is willing to pay $100 for a seller who can translate 4000 words in 30
minutes and who has a reputation of 10 and an expertise of 5. Further, lets say that BPRO
is willing to be flexible on translation time (30-120 minutes) and reputation (5-10), and
associates utility functions UF 5 and UF2 (see Table 1) with these flexible attributes,
respectively. BpRo's "profile" is summarized in Table 2.
Attribute
Optimal
Permissible
Utility
Bid
(Offer)
Range
Function
Range
Value
BPRO
(see Figure 1)
Words
4000
Fixed
N/A
N/A
Reputation=10
Seller
5
Fixed
N/A
N/A
OfferBid=$100
Expertise
Seller
10
5-10
UF 2
$80-
30
30-120
UF5
$100
Reputation
Time (mins)
Table 2: Profile of a "Professional Buyer"
$100$65
BPRO
The "bid range" in Table 2 is deduced by explicitly asking the user a sequence of
questions. For instance for the time attribute, the $65 figure is obtained by asking the
buyer how much she would be willing to pay if translation time were to equal 120
minutes, while all other attributes are held fixed at their optimal values (as discussed in
Section 4.1.3). In other words, if <4000, 5, 10, 30> is the buyer's offer bundle, we ask the
buyer to "bid" on a bundle of the form <4000, 5, 10, 120>. With this information, in
conjunction with the fact that we know that UF 2 (see Figure 1) is a mathematical
approximation to how the buyer's valuation changes from $100 to $65 as time ranges
from 30 to 120 minutes, we can discretize the [30, 120] range to automatically generate
data points of the form <4000, 5, 10, [30...120]> and corresponding bids. Doing so for
every flexible attribute allows us to generate the matrix A, and a corresponding bid vector
47
b. A will thus be an nx4 matrix, where the exact value of n is configurable, depending on
how many data points we generate.
Having thus generated A and b, the task is to model the underlying mathematical
function that maps each row in A to each row in b. We can do so using least squares data
fitting [20] - a well known technique in linear algebra, where the problem is to solve an
over-determined system of equations Ax = b, so as to deduce the vector x that maps each
row of A to the corresponding entry in b. The vector x can be interpreted as a set of
coefficients or "weights," which effectively defines a function that can be used to map a
configuration of attributes to a bid, in a manner consistent with the buyer's revealed
preferences.
In essence, the least squares technique attempts to "solve" the Ax = b system by
minimizing the residual form b-Ax. More precisely,
Given A e C"x",m > n,be C',
We find
xe C"such
that 1b - AxI| 2 is minimized.
Equation 3
Here 1b - AxII 2 denotes taking the 2-norm [20], which corresponds to euclidean distance.
As such, the geometric interpretation of Equation 3 is that we seek a vector
xe C"
such
that the vector Axe C"' is the closest point in range(A) to b.
Once we determine x using our automatically generated data points, we can
effectively automatically estimate the buyer's bids for various sellers in the market. Each
differentiated seller offering simply represents a combination of attributes, of the same
form as a row of A. Since x approximates the mapping from each row of A to a bid, the
process of "valuating" a given seller is simply a matter of "scaling 12" each seller attribute
by the corresponding entry in x.
We use the term scaling, since the entries of x can be interpreted as "weights," signifying different
degrees of importance that the user associates with different attributes.
12
48
4.2.3 Exploring
the
Attribute
to
Space
identify
Optimal
the
Transaction Configuration (OTC)
Subsequently, for each buyer-seller pair in the market, we explore the space of
potential transactions or "deals" that can take place. Exploring the space of possible deals
is equivalent to exploring the space defined by flexible attribute ranges, as specified by
the buyer and seller. For instance, lets consider a "Professional Seller,"
SPRO,
whose
"profile" is summarized in Table 3 (analogous to Table 2):
OfferAsk=$100
Utility
Function
Words
4000
4000-6000
(see Figure 1)
UF 1
Buyer
10
Fixed
N/A
60
30-120
UF 6
SPRO
Reputation=10
Expertise = 5
Permissible
Range
Optimal
(Offer)
Value
Attribute
Ask
Range
$100$150
N/A
Reputation
Time (mins)
$1251_$85
1
Table 3: Profile of a "Professional Seller"
SPRO
Comparing SPRO with BPRO, clearly we see that any attribute (such as 'time') that
is a flexible attribute for both parties with overlapping range, is a candidate for
"negotiation." A possible "deal" between SPRO and
'time' between 30 and 120. However, since,
BPRO
BPRO
could involve any value of
and SPRO each have different optimal
values (30 and 60 minutes respectively), a point in the interval [30, 120] will not be
equally desirable from the perspective of both parties. Our goal is to delineate the
particular "deal" (Optimal Transaction Configuration or OTC) that is myopically optimal
from the self-interested perspectives of the buyer and seller agents involved in the
pairing. As such, we use a distance function (see Equation 4) to assess how any given
"deal" might deviate from the buyer's and seller's optimal "bundles:"
Distance, A
=
[(d, -B,.)
Equation 4
2
+(d,-
S,)2]
49
Where:
i, ranges over all flexible attributes;
d, is the value of attribute i corresponding to the specific deal, d, under consideration;
B," is the value of attribute 'i' corresponding to the Buyer's optimal offer;
S," is the value of attribute 'i' corresponding to the Seller's optimal offer.
For each buyer-seller pair in the marketplace, we can enumerate a set of possible "deals"
that can be brokered. By searching over the (discretized) underlying attribute space,
corresponding to differentiated buyer and seller offerings, we can identify a particular
"deal" that is suitable from the perspective of both transaction partners, in the sense that it
lies close to both of their "optimal" configurations. By searching over the whole attribute
space, in conjunction with our model of user preferences, we effectively explore
permissible tradeoffs that users' are willing to make, and implicitly negotiate over the
holistic product offering to identify a "transaction configuration" that is suitable for both
the buyer as well as the seller.
From the set of all possible "deals" for which surplus is non-negative (i.e. bid is
greater than or equal to the ask) we identify the particular deal for which A is minimized,
and call that the Optimal Transaction Configuration (OTC). Since, for any given buyer,
an OTC will be computed for every qualified seller, comparing the bid-ask spread
(surplus) corresponding to each OTC gives us a global heuristic of surplus maximization
by which we may decide which of the various qualified sellers the buyer ought to be
ultimately paired with.
4.2.4 Delineating
Transaction
Partners
to
Maximize
Aggregate
Surplus
Finally, having found an OTC corresponding to each possible buyer-seller pair in
the market, we use a heuristic of aggregate surplus maximization so as to delineate
transaction pairs.
In essence, for each buyer, we evaluate the "cost" that would be incurred if the
buyer were to engage in a transaction with any of the qualified sellers. Currently, we take
this "cost" to be equal to the OTC "bid-ask spread," which can be interpreted as the
50
aggregate surplus [15, 38] that the two parties would derive if the transaction were to take
place. We use this metric of "cost" since our indicator of the "goodness" of an allocation is
welfare, which, in this case, is measured by the surplus that the allocation generates.
Subsequently, we can conveniently formulate the problem of optimally pairing up
buyers and sellers as a "matching" problem. Mathematically, we can represent the state of
the marketplace as a graph13 , G, in which sellers and buyers represent nodes. We refer to
the set of buyers and seller as B and S, respectively, and to the set of arcs as A. Hence,
G =S
U B; and,
Equation 5
SnB=0.
Equation 6
Equation 5 says that all nodes in the network are either seller nodes or buyer
nodes. Equation 6 captures the fact that each node in the network can uniquely be
classified as a buyer node or as a seller node without ambiguity. Each individual buyer
node b e B is connected to a subset of seller nodes S' c S, via some arc (b, s) with
associated arc "cost" cbs.
In general, we can expect that, in the absence of buyer coalitions or seller
14
44
"cliques" G will be bipartite . The bipartite matching problem is a special case of the
general matching problem and allows for algorithmic simplifications in its solution
15
methodology' .
We assume some basic knowledge of graph theory and terminology here. To learn more, we invite the
reader to browse some of the Network Optimization and Graph Theory books referenced in the
13
bibliography.
"
A graph G = (N, A), where N is the set of Nodes and A is the set of Arcs, is said to be bipartite if we can
partition its node set into two subsets N, and N 2 so that for each arc (i,
j) in A either (i). i E N and
je N 2 , or (ii). ie
N 2 and j E N [36].
and
seller coalitions would be a fascinating and extremely intriguing area of research
" Exploring buyer
within the context of this project. Indeed, it is our expectation that, facilitating such coalitions in our system
should be fairly straightforward, given our modular design and generalized treatment of the overall
problem. However, in the interest of simplicity, we will resist the temptation of analyzing such a market
structure in depth, for the time being.
51
Given this formulation, our goal is to find a sub-graph G' c G, such that the subgraph represents a feasible16 pairing of buyers and sellers with the largest overall "cost"
(surplus), defined as the sum of the costs of its constituent arcs. To accomplish this, our
solution strategy mirrors that of a (modified)17 minimum cost flow problem. With this
formulation the matching problem can now be expressed as the following linear program
[36]:
Minimize I
cyx,
Equation 7
Subject to the constraints:
xj
{j:(i
=1 for all ie S,
e A}
Equation 8
({:(j)eA}
xZ, =1 for all ic B,
Equation 9
x
0 for all (i, j)e A.
Equation 10
Conveniently, we can now apply a direct implementation of the Successive Shortest Path
algorithm for the minimum cost flow problem in order to find an optimal matching [36].
The successive shortest path algorithm functions by first finding the residual
network, G(x) corresponding to G' 8 . It then finds shortest paths from a "supply" node
(which, in our formulation, conveniently corresponds to a seller node) to all other nodes
in G(x). The distances computed are then used to update node "potentials" (denoted by
In this case the "feasibility" condition maintains that for a given buyer, the seller should be qualified to
serve the buyer and that the buyer should meet the qualification criteria, if any, specified by the seller.
Moreover, the buyer's bid can be no less than the seller's ask.
17 Since we are actually trying to maximize the sum of our costs (aggregate
surplus), we redefine costs in
the min cost flow formulation to be the negative of the computed surpluses. Minimizing the sum of the
negatives of the original quantities is equivalent to maximizing the sum of the original quantities.
18 We can find the residual network, G(x), corresponding to a given flow x in G, by replacing each arc
(i, j) e G by two arcs: (ij) and (j, i), such that (i, j) has cost cij and residualcapacity rij = uij - xij (uij denotes
the capacity of arc (ij) in G) and arc (j,i) has cost -cij and residual capacity ri = xij. G(x) consists only of
arcs with positive residual capacity.
16
52
r) and to augment flow from the supply node to a demand node. Intuitively, then, for our
purposes, when the algorithm augments one unit of flow in each iteration, that
corresponds to assigning a seller in S to a buyer in B. It can be shown that the running
time of the algorithm is asymptotically bounded by O jSJ*F(IS+BJAmax(cj)), where
F(IS+B,AI,max(cj)) denotes the time needed to solve a shortest path problem' 9 .[36]
Consequently, the algorithm terminates within ISI iterations.
The algorithm concludes by identifying buyer-seller pairings for which the
aggregate surplus of transaction parties is globally maximized. The "clearing price" for any
given transaction pair is, by default, set at the midpoint between the original bid and ask
prices, thereby equally dividing the surplus between the buyer and the seller. The market
maker can, however, modify this distribution of surplus, choosing to retain the bid-ask
spread as operating profit, for instance.
As a consequence of our matching technique, we are able to ensure that the following
invariants are maintained2 0 :
1. Optimization Invariant: Of all the "market baskets2 "1 that a consumer can afford, a
consumer always tries to select the basket which yields the highest utility22 . This is a
consequence of our local optimization technique, prior to running global matching.
2. Efficiency Invariant: The allocations determined by the system are economically
efficient and consistent with some form of utility maximization. This is a consequence of
our Pareto optimality condition, which guarantees that no potential economic gains are
19 Strictly speaking, we should only use the shortest path algorithm when our arc costs are non-negative, in
order to avoid the unhappy situation of negative cost cycles. However, in this case, since, by formulation,
our graph, G, is bipartite and all arcs are unidirectional (going from nodes in S to nodes in B), we can
guarantee that no negative cost cycles will arise in the residual network G(x).
20 The optimization and equilibrium invariants are based on the "optimization principle" and "equilibrium
principle" discussed by Varian [15].
21 Here the term "market basket" refers to any set (possibly null or singleton) of goods and services that are
purchased by a given consumer.
22 The claim makes some implicit judgments about rational consumer behavior, namely that a rational
consumer's behavior is necessarily oriented towards utility maximization.
53
left unexploited and, hence, that the final allocation or matching is economically
efficient.
4.2.5 Presenting Results
All matchings delineated by the system are considered tentative or "pending" until they
are mutually "confirmed" by both transaction partners. If a user's agent has been
matched, the user has the option of reviewing and confirming the deal associated with the
matched agent or doing nothing. Upon mutual confirmation by both parties involved in a
"pending" transaction, the transaction is said to become "closed," and the agents involved
are "Expired" from the market, meaning that they are no longer considered in future
matching cycles. Agents not involved in "closed" transactions are kept "Active," or
eligible to be matched in future matching cycles. This is desirable, since it increases the
set of prospective transaction partners available to a given agent, and affords a greater
deal of flexibility to the parties involved.
When "reviewing" a matched agent, the owner not only sees the details of the
"deal" associated with his matched agent (see Figure 7), but also sees details of
"potential" deals with other qualified transaction partners that were considered and,
further, is able to see whether these prospective transaction partners were matched with
someone else or not. Moreover, each deal shown to the user has a score metric associated
with it (see Figure 8). The score metric printed with each deal reflects the surplus
associated with that potential pairing. Surplus, taken here to be the bid-ask spread, is a
valid scoring metric for both buyers and seller agents. The system only considers
transactions for which the spread is positive and for which the bid is greater than the ask.
As such, from the buyer's perspective, for a given bid, a larger score indicates a lower
closing price for a transaction, which translates into cost savings. Symmetrically, from
the seller's perspective, for a given ask, a larger score indicates a higher closing price for
a transaction, which translates into greater profits.
Finally, when "reviewing" a matched agent, the owner is able to see whether the
other transaction partner involved in the matching has already "confirmed" or unilaterally
accepted. The presence of a unilateral confirmation by the other side makes it clear that
54
the transaction will consummate (become "closed") by mutual confirmation if the owner
confirms as well.
Figure 7: Details of the "deal" designated by the system for a matched agent
Figure 8: Details of potential deals with other qualified transaction partners that were considered,
with corresponding scores, and whether these prospective transaction partners were matched with
someone else
55
56
5 THEORETICAL PRINCIPLES AND
METHODOLOGICAL RATIONALE
5.1 Modeling Preference Functions
5.1.1 Assumptions
Within MARI, we attempt to determine user utility functions by explicitly observing
behavior via revealed attribute preferences and then inferring what kind of preferences
might have generated the observed behavior. In other words, asking the user to explicitly
valuate hypothetical data gives us the opportunity to generate observations on choice
behavior which, in turn, allow us to determine what, if anything, is being maximized.
Once we have a mathematical estimate of the function that is being maximized, we can
use this to predict choice behavior in previously unseen situations, as well as to evaluate
the effects of proposed policy changes in the economic environment.
As is standard practice in economic literature, we assume that user preferences are
"well behaved." More formally, in order for preference relations to be representable by
mathematical utility functions, we assume that preferences are:
1. Complete: Meaning that preferences are well defined over the entire space of possible
product attribute values. This assumption guarantees that individuals are able to
completely understand and decide between any two alternatives. This assumption also
rules out irrational preferences, in which an individual might claim that both A is
preferred to B and that B is preferred to A.
2. Transitive: Meaning that, if the consumer prefers Product A to Product B, and prefers
B to C, then the consumer also prefers A to C. This assumption guarantees that an
individual's choices are internally consistent.
3. Continuous: If an individual prefers A to B, then situations "close" to A must also be
preferred to B. Mathematically, the purpose of this assumption is to ensure that the
57
corresponding utility functions should not exhibit any singularities and should have
quantifiable values at all points in the attribute-space.
5.1.2 Mathematical Formulation of Utility Functions
All our predefined utility functions (with the exception of UF15 which is constant) have
the property that they are either:
(i). Type I: Monotonically decreasing over the permissible range (UF 4, UF5 , UF 6, UF 14,
UF16);
(ii). Type II: Monotonically increasing over the permissible range (UF 1 , UF 2, UF 3, UF 13,
UF17);
(iii). Type III: Monotonically increasing till the midpoint of the permissible range, and
monotonically decreasing thereafter (UF 7, UF 8 ,UF 9); or,
(iv) Type IV: Monotonically decreasing till the midpoint of the permissible range, and
monotonically increasing thereafter (UF o, UF1I, UF 12).
Type III (Type IV) functions can be seen as the "aggregation" of a Type II (Type I)
followed by a Type I (Type 1I) function. In fact, this is how we represent Type III and IV
functions within MARI. Given these observations, we can derive a generic mathematical
formulation for the utility functions corresponding to each of the flexible attributes as
shown in Table 4, Table 5 and Table 62. It should be noted that in each case the degree
of the polynomial used to represent the function can be at most two (quadratic). Higher
order polynomial approximations can subsequently be created using Lagrange
interpolation.
For the purpose of generating generic mathematic forms of the functions, we
assume the presence of data-points of the form (x, UF(x)). These data
points are
obtained directly from the user during the normal course of interaction with MARI. The
front-end user interaction model ensures that the system asks the user sufficient questions
so as to be able to obtain these data points. It should be noted that all Type II functions
In each case, Type III and Type IV functions are treated as "aggregations" of Type I and Type
II
functions. Further, we assume that functions are only evaluated over valid x values that are contained in the
permissible interval, inclusive of endpoints.
23
58
only assume knowledge of two data-points, despite the fact that these are quadratic
functions. This is a consequence of the fact that, for simplicity, we have assumed that the
quadratic function reaches its minimum or maximum value at the point where it levels off
(where the slope of the function is zero). In some cases, the user might voluntarily reveal
three data points, more than the minimum two required by our system. This could
happen, for instance, when the optimal value of a flexible attribute lies between, and is
distinct from, the maximum and minimum values of the attribute. In this case, the system
prompts the user to associate prices with all three attribute values. When this happens, the
system automatically uses the extra data point to generate an exact quadratic
representation of the utility function corresponding to the attribute.
In our prototype implementation, we have elected to retain only Type I and Type
II functions for simplicity. However, for the sake of completeness, we will derive the
equation forms of all utility functions, dividing the analysis into three "cases:"
Case 1: Utility functions represented by degree one (linear) polynomials, i.e., UF 1, UF 4,
UF 7, UFio. Since, two points are sufficient to define a line in a plane, we can easily
calculate these linear functions:
Name
Equation
Known Data
Points
(x, UFi(x))
UF 1
(xi0,, pbsvalue);
(Xhi,
UF 4
(x 0,,, pbsvalue);
(Xhi,
UF 7
UF,(x)
- Xh)
(x
UF4(x) (pbsvalue)(X -
minvalue)
(xI..
(xij,0 pbsvalue);
maxvalue);
(xhi, pbsvalue)
+ (maxvalue) (X- x".)
=(pbsvalue)
maxvalue)
(pbsvalue)
(X
+ (minvalue) (X
X
-
XhI)
-
Xd)
(x 16w-
(Xmid,
UFE,(x) =
(maxvalue)
(Xh - x 1o.
(X,
+ (a
)
x1 )
-
x/0w
(X - x")
i
x,,
x < Xmid
Xmid
X
(Xmid -
Xmid)
(-h)(-
+ (pbsvalue)
(Xmid - Xh1 )
)
(Xh, - Xmid)
id f
Xh,
59
UF10
(xl0,, pbsvalue);
(Xmid, minvalue);
(Xhi,
pbsvalue)
{(minvalue
malue (X
(pbsvalue)
-
(s
UFl0 (x) =
lue)
(x
xid)
(XmidXh' + (pbsvalue) (X
(X
-Xh
)
-
x < x md
X
- X,d)
(Xh
)
if x,.
)
(Xm d -x,
f
Xmid
X
Xmid )
Table 4: Utility Functions Represented by Degree One (Linear) Polynomials
Case 2: Utility functions represented by degree two (quadratic) polynomials, i.e., UF 2,
UF 3, UF 5, UF 6, UF8 , UF 9, UF11 , UF 12 . Given the fact that we already know the general
shape of these functions, we can easily derive general form equations using elementary
algebra techniques along with special properties of quadratic functions. In particular, we
have used the fact that the global minima of a quadratic, of the form y = ax2 +bx+c,
occurs at
-
2a
. The astute reader will note that many of the derived equations are simply
shifted and scaled reflections of each other across the vertical axis, x
horizontal axis, y
=
".
+Y"""
2
+ Xh,
-
or the
(where ymax and ymin respectively denote the maximum
and minimum values of the function, y, over the permissible range of the flexible
attribute), or some combination thereof.
Name
Equation
Known Data
Points
(x, UF1(x))
UF 2
(xi0,, pbsvalue);
(Xhi, maxvalue)
(maxvalue
UF2 (
=
(xh,
- pbsvalue
_
2 +
X,
0 w)2
(-2)(maxvalue - pbsvaue)(x,, )
(Xhi
-
XI 0.
)2
0 w )2
+ pbsvalue + (maxvalue - pbsvalue)(x,
o
(hi _ XI.)
UF 3
(xi0,, pbsvalue);
(Xh i, maxvalue)
UF (x) =
maxvalue - pbsvalue
(xhi ~ X10. )2
2 +
(2)(maxvalue - pbsvaue)(x1 )
(Xhi
+ pbsvalue + (3)(maxvalueh,-- pbsvalue)(x,
xI. )2
u +(x
+1p
)2
-XI.
)2
Xh,
60
UF5
(xi0 n, pbsvalue);
(Xhi, minvalue)
pbsvalue - minvalue x 2 +(-2)(pbsvalue
W
X
UF(x)=
+ Lminvalue +
(xi0 ,, pbsvalue);
(Xhi, minvalue)
pbsvalue - minvalue
6
)2
- xjaw )2
(xhi
UF 6
XI 0. )2
- minvalue)(x,
+ (pbsvalue
(h
~)
a
+K
- minvalue)(xhi )
x +
. )2
-
2+(2)(pbsvalue
(x6
Xhi+
(xh, _ x,0 )2
minvalue)(x,0 )
2
-
+ minvalue + (3)(pbsvalue - minvalue)(xw )2
(Xhi
UF 8
(xl0,, pbsvalue);
(Xmid, maxvalue);
(Xhi, pbsvalue)
XI.W )2
--
'maxvalue - pbsvalue x2+
(-2)(maxvalue - pbsvalue)(x0 w )
mX
id _ Xow )2
ow )2
_ X0
(Xmid
+ pbsvalue + (maxvalue - pbsvalue)(xlo,
)2
(Xmid
flo.
0
XIO. )2i
-
X<
Xmid
UF (x)=
maxvalue - pbsvalue x2 +
(xhi
(-2)(maxvalue
- pbsvalue)(xh, )
2
(Xi-Xi
- xmid )2
++ minvalue+
min u + (maxvalue
- pbsvalue)(xh,)2<
(x,-Xj2
(xhi
UF 9
(xl0,, pbsvalue);
(Xmid, maxvalue);
(Xh,
(xmid
Xow )
e
+ pbsvalue +
-hi
- pbsvalue)(xmid)
9mid
2
if Xmid
)2
- pbsvalue x2 +(2)(maxvalue
'maxvalue
pbsvalue)
xmd
-
_wX,.)2
pvalbs)xalue)
-
(3)(maxvalue -
f2 x o
pbsvalue)(xid
X < Xd
(Xmid _ Xow )2
UF(x)=
Chi
Cpbsvalue
maxvalue - pbsvalue
(xh,
+
-Xmid
Xmid )
+ (3)(maxvalue - pbsvalue)(xmid )2
(xi
UF11
(xi0,, pbsvalue);
(Xmid, minvalue);
(Xhi,
(2)(maxvalue - pbsvalue)(xmd )
2+
)2
-
pbsvalue)
+
+
_Xow )
minvalue +
(pbsvalue -
X1 )
X
2
minvalue)(xmid )2
2
-
(Xmid
Xmid ! X
- minvalue)(xmid )
9m.d
2
if
Xmid
pbsvalue - minvalue x2 +(-2)(pbsvalue
(Xmid
2
~
f
X1 ~
X <Xmid
_ Xo.w
UF (x)=
pbsvalue - minvalue
+
(-2)(pbsvalue
a2 - minvalue)(xmid )
Xhi _
(xhi - xmid )2
C
+ minvalue +
md )2
(pbsvalue - minvalue)(xmd )2
(Xhi
Xmid)
9
d
f
Xmid
h
X ! Xhl
61
UF12
(x 0,,, pbsvalue);
'
(Xm..id, minvalue);
(Xh, pbsvalue)
pbsvalue - minvalue X2+
(Xmid _ow 2
(2)(pbsvalue-minvalue)(x,,)
min
+(3)(pbsvalue- minvaue)(x,,.
Lmznvalue +
(Xi
0
+.
+
)2
~~
2
iff X10-
-x
(mid
UF2 (x)
X.,_
mX.d
XX <
=
pbsvalue - minvalue
+
2+
(2)(pbsvalue - minvalue)(xh
2
Xmid
Cminvalue
(Xhi
Xmid )
+
hi
(3)(pbsvalue
- minvalue)(xh
)2
(
Xmd 2
1
(Xhi
-
if Xmld
!5
Xmid)2
Table 5: Utility Functions Represented by Degree Two (Quadratic) Polynomials
Case 3: All other Utility functions, i.e, UF 13 , UF 14 ,UF 15 , UF 16, UF 17.
Name
Equation
Known Data
Points
(x, UF1(x))
UF 13
UF 14
(xi0,, pbsvalue);
(xhi, maxvalue)
(xi0,, pbsvalue);
UF() = pbsvalue
maxvalue
fpbsvalue
(Xhi, minvalue)
minvalue
UF 15
(xi0,, pbsvalue);
UF, (x) = pbsvalue
UF 16
(xhi, pbsvalue)
(xi0,, pbsvalue);
(Xhi, minvalue)
UF(
UF 17
UF
(xl0,, pbsvalue);
W
(xhi, minvalue)
=
if
X.
x<
Xh,
if x = xh,
'f
x,.
x < Xh,
if x =xh
pbsvalue
if x =x,
minvalue
'f X1 , <X
pbsvalue
if x =x,
if x,0, < x
maxvalue
X
xhi
Table 6: Other Utility Functions
5.2 Mechanism Design
From a functional perspective, MARI's goal is to match buyers and sellers while taking
into account relevant economic criteria, such as Pareto optimality, utility functions, and
surplus maximization. As such, one can envision several possible mechanism designs.
Here, we identify a few candidate mechanisms we have considered, and discuss the pros
and cons of each for our purposes.
Xi
,oj
X
)2
Xhi
62
1. Sealed Bid Double Auction: This strategy is similar to that employed in MarketMaker
[9]. In this case, each buyer (seller) defines an upper and lower bound on the price he or
she is willing to accept, and delineates a mathematical function that defines how the price
varies from the lower (upper) bound to the upper (lower) bound with the progression of
time [7]. Over time, the buyer (seller) increases (decreases) her price until there is some
seller (buyer) who is willing to transact at that price, or until the upper (lower) bound is
reached or until the permissible amount of time available expires. In the latter two cases,
the transaction does not take place.
The analysis of the sealed bid double auction can be reduced to a weak version of
Bayesian Nash equilibrium [8]. Since, in this scheme, buyers and sellers do not directly
reveal their valuations and preferences, each round of the auction will, in general, not be
Pareto optimal [28]. Secondly, it should be noted that this method would violate one of
the design goals intrinsic to the MARI architecture -- to transcend the adversarial winnerloser characteristic inherent to common-value auctions24 .
2. Repeated Vickrey Auction: In this case, we individually auction the services of the
sellers to the buyers [49]. The Vickrey auction is like the conventional sealed bid auction
with the critical difference that although the good is awarded to the highest bidder, it is
awarded at the second-highest price that is above the seller's reservation price. It can be
shown that in a Vickrey auction, it is always in each player's interest to bid their true
value [15] It can also be shown that a Vickrey auction will always result in a Pareto
optimal outcome [15], making it an attractive candidate for a resource allocation
mechanism.
However, like any other auction, a Vickrey auction is susceptible to collusion and
other forms of strategic behavior. Most importantly though, for our purposes, this
mechanism only maximizes the welfare of the economy if we assume that the sellers are
homogenous [29]. Needless, to state, this assumption is not reasonable in the kinds of
markets we are interested in focusing on.
A common-auction is defined as an auction in which the good in question has essentially the same value
to all bidders, even though bidders may have different estimates of that value [15].
24
63
3. ClearinghouseDouble Auction: Conceptually, this method is similar to the Sealed Bid
Double auction except that in this case we attempt to find a single market clearing price
at which many (possibly all) buyers and sellers can be matched up [7].
The Clearinghouse functions by examining the sealed bids of the buyers and
sellers at predefined frequencies, and using these to compute mathematical demand and
supply curves. Subsequently, the intersection of these curves is used to identify a single
equilibrium or market-clearing price, which is then enforced for all the associated
transactions.
One potential shortfall of this method, however, is that it would not be very
accurate in thin or semi-liquid markets since, in general, to come up with meaningful
demand and supply curves, we will require that some critical mass of buyers and sellers
be present. Indeed, in MARI, we expect that markets for many specialized services will,
in fact, be thin, and we want that our matching methodology should be robust enough to
handle such situations. Secondly, one of the manifest goals of MARI is, in fact, to
transcend this notion of a "single market clearing price" and make the transaction
experience personalized at the individual level. Hence, the Clearinghouse Double
Auction is not an appropriate choice for our system.
5.3 Optimization Heuristicsfor Transaction Brokering
We use a matching technique in conjunction with an optimization heuristic, to
successfully match up buyers with sellers. Different heuristics will differ in the metrics
they employ in formulating the objective function of the optimization problem. Such
metrics could include, for instance: (maximizing) cumulative profits or revenues of the
sellers, (maximizing) profits or revenues of a particular seller or a subset of sellers,
(minimizing) cumulative prices paid by buyers, (minimizing) the price paid by a
particular buyer or some subset of buyers, (maximizing) cumulative producer surplus25
or the surplus of some (possibly singleton) subset of sellers, (maximizing) cumulative
25 Producer surplus can be defined as the sum over all units of production of the
difference between the
market price of the good and the marginal cost of production (Pindyck and Rubinfeld, p.267).
64
consumer surplus26 or the surplus of some (possibly singleton) subset of buyers,
(maximizing) combined surplus of consumers and producers, etc. Clearly, there can be
many different economic institutions for allocating resources. In order to be able to
compare these schemes to determine which is the best, we must first define the concept of
"best" in our context.
A useful criteria for comparing these outcomes is by using the
notion of Pareto optimality2 7 . If an allocation of resources has the property that it is not
possible to make any one person better off without making someone else worse off at the
same time, then we say that it is Pareto Optimal, and that no Pareto Improvement is
possible [15].
More precisely, a market allocation is said to be Pareto Optimal if [15]:
1. There is no way to make all the market participants involved better off; or
2. there is no way to make any one individual better off without making some other
individual worse off at the same time; or
3. all possible gains from trade have been exhausted; or
4. there are no further mutually advantageous trades to be made.
Conventional economics often associates Pareto optimal with a market in which the seller
is able to perfectly price discriminate. First-degreeor Perfect price discrimination means
that the seller is able to sell different units of output for different prices and vary these
prices across different buyers [15]. Hence, prices differ across units of the good as well as
across customers. perfect discrimination is associated with the producer capturing all the
surplus in the market. In this scenario, the producer is seen as wanting to maximize his or
her profits (producer surplus) subject to the fact that the good is sold at the buyer's
reservation price2 8 . Interestingly enough, though, this means that the outcome will be
Pareto optimal, since there is no way to make both the producer and the consumer better
off: we cannot increase the consumer's surplus without decreasing the producer's profit
Consumer surplus can be defined as the difference between the amount consumers are willing to pay for
a good and the amount they actually pay 38].
27 Pareto efficiency is named after the 19t century economist and sociologist
Vilfredo Pareto.
28 The highest price that the buyer is willing
to pay.
26
65
(surplus), and we cannot increase the producer's profit since it is already the maximum
possible.
In our system, since we use a mediated approach to matching up buyers and
sellers we are able to capture desirable Pareto optimality and surplus maximization
properties, while preventing all the surplus from being usurped by any one party. MARI's
default optimization heuristic and matching technique guarantee that the final matching
output by the system is Pareto optimal and maximizes surplus, as measure by the
cumulative bid-ask spread amongst all prospective transaction partners in the market. The
market maker can then control how this surplus ought to be divided amongst the buyers,
sellers and himself.
5.4 Welfare Maximization
A maximal welfare allocation must necessarily be Pareto optimal [15]. This is
easy to see by contradiction. If the allocation were not Pareto optimal, then it would be
possible to redistribute resources to create a new allocation such that everyone would
have the same or greater utility, and one individual would have strictly greater utility29.
However, the condition we placed on any welfare function is that it must be an increasing
function of individual utilities, meaning that aggregate welfare should increase as the
utilities of individual participants increases. Hence, the new allocation would have a
higher social welfare than the previous allocation, thus contradicting the fact that the
previous allocation was a maximal welfare allocation. Conversely, it is also true that any
Pareto optimal allocation is a welfare maximum for some welfare function30 [15].
In general, however, the condition of Pareto efficiency says nothing about the
distribution of welfare (surplus) amongst the market participants. Thus, the notion of
Pareto optimality ignores questions of fairness and how aggregate surplus might be
apportioned amongst people. Pareto optimality is a desirable goal in and of itself.
However, in general, there can be many Pareto optimal allocations corresponding to a
market scenario and, as such, we must define criteria to choose amongst them.
This follows directly from the definition of Pareto optimality presented earlier.
A proof of this converse claim is left to the reader as an exercise. The reader is invited to refer to [15],
Chapter 31 for additional details.
29
30
66
One way to obtain the "social utility" corresponding to a market allocation is
simply by numerically adding individual utilities corresponding to that allocation. That is,
we say that allocation A is socially preferred to allocation B if
u, (A) >
__=_
u(B)
U,
i=1
Equation 11
where n is the number of market participants. Summing the individual utilities, rather
than multiplying them, or subjecting them to some other monotonic transformation before
aggregating, is a completely arbitrary choice. The only restrictions that a "social welfare
function" needs to follow is that it should depend only on individual preferences, and it
should be an increasing function of each individual's utility - meaning that if all
individuals prefer allocation A to allocation B, then the social welfare function will also
rank A higher than B. As such, there are several social welfare function that we can use
[15]:
1. A simple "sum of utilities" welfare function:
n
W(Ull,...,'Un)=YU,
i=1
Equation 12
2. A "classical utilitarian"or Benthamite3 1 welfare function, generalized as a weightedsum-of-utilities welfare function. Classic utilitarianism considers the highest good to be
the maximum utility for the maximum number of people:
n
W(UI,..Un)=
ai u,
Equation 13
In this case the weights, ai....an, represent how important each individual economic
agent's utility in the context of overall social welfare.
3. A "maximum of minimum" or Rawlsian33 social welfare function:
31
32
Named after Joseph Bentham, who is often called the father of the utilitarian school of moral philosophy.
Of course, it is not immediately intuitive as to what criteria we might use to determine these weights.
67
Equation 14
The Rawlsian school of moral philosophy thus contends that the social welfare of an
allocation is contingent upon the welfare of the person who is worst off in the society.
Each of the above functions represent different ways in which we can aggregate
individual utilities corresponding to a given allocation of resources to deduce a societal
utility metric. In general, in the context of matching buyers and sellers in our system, we
would like to find a feasible allocation that simultaneously also maximizes social welfare.
However, these welfare functions view individual utilities as defined over entire
allocations rather than over each person's individual, post-transaction, allocation of
goods. As a consequence, within MARI, we measure social welfare by adopting a special
form of the welfare function, known as the "individualistic" or Bergson-Samuelson
welfare function [15]. This formulation says, that if we let xi denote individual i's
consumption bundle, and ui(x,) as the individual i's utility corresponding to the bundle xi,
then the social welfare function can be written as:
W=
W(ul (XI), ...
,IUn(X,)).
Equation 15
5.5 Algorithms for Matching Buyers with Sellers
While we have adopted a graph-based min-cost flow algorithm that uses a heuristic of
aggregate surplus maximization to match buyers and sellers within our system, other
techniques were also considered. In general, "matching" problems may be viewed as a
subclass of combinatorial optimization problems in general, and of network flow
problems in particular [36]
In general, there are three common versions of bipartite matching problems [36]:
" Named after the moral philosopher John Rawls.
68
1.
The Cardinality Problem: We wish to find a matching containing the maximum
number of arcs. This corresponds to a situation in which we simply wish to maximize the
number of market participants who have a transaction partner, without regard to the costs
associated with the matching.
2. The Stable MarriageProblem: There is no objective function, per se, that we wish to
maximize. Rather this models a situation in which each seller has a ranking of each buyer
and each buyer has a ranking of each seller. Then we seek a feasible matching of the
members of the two groups, with the property that no pair of buyer and seller prefer each
other to the partners they are assigned in the stable matching.
We chose not to use a cardinality problem formulation, since this does not allow
us to make any claims about Pareto efficiency or surplus maximization, which we had
perceived as being desirable properties.
The algorithm for the stable marriage problem [36] is an iterative greedy
algorithm. Each buyer34 "proposes" to his or her most preferred seller, and each seller
who receives more than one proposal rejects all except her most preferred buyer amongst
all buyers who proposed to her. In general, there can be several stable matchings that
correspond to a given set of rankings. The matching constructed has several interesting
properties. In particular, it can be shown that every buyer is at least as well off under it as
under any stable matching [36]. Hence, such a matching can be referred to as a "buyeroptimal matching."3
Intuitively, since buyers propose to sellers in decreasing order of
their preferences, and since no seller ever rejects a stable partner 36 , each buyer is
necessarily paired with the best possible stable seller. This implies that if each buyer is
independently given her best stable partner, the result is a stable matching. However, this
optimality from the buyer's point of view is obtained at the expense of the sellers. In fact,
it is possible to show that in a "buyer-optimal matching," each seller obtains the worst
partner that she can have in any stable matching [36].
The treatment of the formulation with sellers "proposing" to buyers is symmetrical.
3s Symmetrically, in the converse formulation where sellers propose to buyers, we would have a "selleroptimal" matching.
36 The fact that a seller never rejects a stable partner is an interesting consequence of this formulation of the
stable matching algorithm. The reader is invited to refer to [36], p.474 for a formal proof of a similar claim.
1
69
Thus we see, that if we wish to optimize strictly from the buyer's perspective
alone or from the seller's perspective alone, then the stable-marriage algorithm would be
a good choice. However, in the current incarnation of our system, we want to take
economic welfare considerations into account and optimize from a global perspective.
70
6 FUNCTIONAL DESIGN
6.1 Functional Schema and Modules
The MARI system consists of several major functional components. Figure 9
illustrates the major modules and the inter-relationships between them. Subsequently, we
discuss each major component and its role.
--
---
---
Buyer and Seller
..- Clients
HTTP
Internet
TCP/IP
-
HTTP
Uq
HTML Intarface
a fact Manger (UIM),
Event Trigger+d
-U
M"g
c
4
I I
Figure 9: Architecture Design Schematic
71
1). User Interface Manager (UIM): Controls the (HTML) interface that is presented to
the user. The UIM allows the user to specify and initiate a buy or sell request, to examine
the status of previous requests, and to view market status and history. The Valuation
Managers, discussed below, are invoked by the UIM during the course of initializing a
user request to buy or sell. The UIM ensures that all relevant parameters are collected
from a user in the context of any request, and that only valid requests are propagated.
2). Buyer Valuation Manager (BVM): Gathers sufficient information from a potential
buyer so as to be able to accurately infer the buyer's valuation for previously unseen
products.
2.1). Valuation Function Generalizer (VFG): Models a buyer's utility for multiple
attributes by allowing the market maker to select from generic, pre-defined mathematical
functions.
2.2). Valuation Function Trainer (VFT): Fine-tunes the rough utility function captured by
the VFG by giving the market maker the option of iteratively "training" the system.
Essentially, the VFT facilitates the construction of an (iteratively refined) piecewise,
linear approximation of the buyer's utility function.
3). Seller Valuation Manager (SVM): Gathers information from a potential seller so as to
be able to accurately infer the seller's valuation for previously unseen products. Like the
BVM, the SVM works by having the market maker initialize the VFG and VFT.
4). Market Cycle Manager (MCM): Manages and enforces market cycles. The frequency
of market cycles is a system variable that must be pre-specified, or can be set to be
triggered by
the simultaneous
presence
of certain
(pre-specified)
environmental
conditions (such as number of users currently waiting to be matched).
4.1). Optimization Heuristic Manager (OHM): Allows the specification of which
optimization heuristic ought to be employed. For instance, in some cases, the market
maker's aim might be to maximize the number of buyers and sellers matched, while in
other cases one may want to maximize the minimum surplus amongst all transaction
72
partners, etc. The OHM enforces the specified optimization heuristic throughout the
system by setting key global parameters appropriately, in a mutually consistent fashion.
These parameters can then be referenced by other modules in the process of optimally
pairing transaction partners.
The MCM invokes the Match Maker (MM) at the start of every "market cycle" (a
"market cycle" is defined as the period between consecutive runs of the matching
algorithm). The MCM also ensures that buying and selling requests are time-stamped and
queued appropriately so that precedence and priority relationships can be established if
needed. At the end of every market cycle, the MCM examines the results output by the
MM and notifies the User Status Manager (USM) and User Notification Manager
(UNM), so as to update the status of user requests, as appropriate.
5). Match Maker (MM): Invoked by the MCM, the MM optimally pairs up buyers and
sellers. The exact optimization heuristic to be used by the MM is specified by the MCM
at the time of invocation. The MM gets the IDs of "active" users to be included in the
matchmaking process from the User Status Manager (USM).
6). User Status Manager (USM): The USM monitors the status of each user. The USM
keeps track of which requests are "active" and ought to be included in the matchmaking
process in any given market cycle. For instance, the market maker may require that any
given user should remain active for at least n market cycles, or, perhaps, that a given user
should remain active until she is involved in market cycles with an aggregate of at least m
other users, at least m, of whom are sellers and m2 are buyers.
7). User Notification Manager (UNM): The UNM notifies a given user of the outcome of
their buying or selling request once a definitive outcome has been established or the time
permitted by the user has expired. "Notification" can be "active" (sending an e-mail to
the user) or "passive" (writing the outcome to a local database which is queried when the
user logs in to check the status of his or her request).
73
8). Database Manager (DM): The DM presents each of the above components with an
interface to a back-end database, thus abstracting away the specific details by which data
is stored and retrieved from the rest of the system.
9). Active User List (A UL): At the beginning of each market cycle, the Match Maker
(MM) reads the AUL to identify "active" buyers and sellers who need to be matched. The
User Status Manager (USM) updates the AUL when a new user enters the system and at
the end of each market cycle.
10). Transaction Partner List (TPL): The TPL is a list of transaction partners as
determined by the Match Maker (MM) at the termination of the most recent market cycle.
The AUL, TPL, and Buyer and Seller Pools effectively comprise a system "log" that
capture the state of the system at the end of a Market Cycle. In the event of a system
failure, we revert back to the last logged state.
6.2 Usage Schema and Interaction Model
Referring to the major modules highlighted in Figure 9, we designed the system to
support the following usage schema:
Step 1: A buyer or seller client connects to the HTML front end of our system via the
Internet (HTTP), and specifies which product he or she wishes to buy/sell.
Step 2: The UIM queries the DM for the appropriate product ontology and asks user to
specify required parameters via the HTML interface. Subsequently, these parameters are
written back to persistent storage through the DM.
Step 3: The UIM invokes the BVM/SVM as appropriate.
Step 4: The BVM/SVM invokes the VFG, which collects relevant valuation parameters
from the user and writes results back to persistent storage.
74
Step 5: The BVM/SVM invokes the VFT, which collects relevant valuation parameters
from the user and writes results back to persistent storage.
Step 6: Once the BVM/SVM has finished, the UIM notifies the USM that a new user has
successfully entered the system. The USM "activates" the user's "profile" uniquely
prefixed by the user's MARI ID number, and updates the "Active" User List (AUL), and
Buyer/Seller Pool.
Step 7: The MCM initiates a new Market Cycle when some pre-defined event or set of
events occur. Such an event could be something as simple as "passage of x minutes of
time," or something more elaborate, such as the simultaneous presence of certain global
environmental conditions (for instance, such a condition might be that there be at least yi
active buyers present and y2 active sellers present).
Step 8: The MCM invokes the OHM and indicates which optimization heuristic is to be
used in pairing up buyers and sellers. Subsequently, the OHM sets all global parameters
appropriately, in a mutually consistent manner, so that the system will indeed optimize
according to the chosen heuristic. For instance, in some cases our aim might be to
maximize the number of buyers and sellers matched, while in other cases we might want
to maximize the minimum surplus amongst all transaction partners (Rawlsian approach)
etc.
Step 9: The OHM invokes the MM to actually generate buyer-seller pairs.
Step 10: The MM readsthe AUL to identify "active" buyers and sellers.
Step 11: The MM runs a pre-defined algorithm, specified as a global variable by the
OHM, and writes the Transaction Partner List (TPL).
75
Step 12: The USM reads the TPL. In accordance with pre-defined system variables, the
USM decides which users should continue to remain "active," and which should be
considered "matched optimally." For instance, we may require that any given user should
remain active for at least n market cycles, or, perhaps, that a given user should remain
active until he or she is involved in market cycles with an aggregate of at least m other
users, at least m, of whom are sellers and m2 are buyers.
Step 13: The USM updates the AUL, writes finalized transaction pairs to persistent
storage through the DM, The AUL, TPL, and Buyer and Seller Pools associated with the
USM effectively comprise a system "log" that capture the state of the system at the end
of a Market Cycle. In the event of a system failure, we revert back to the last logged state.
Step 14: The USM asks the UNM to send notification to users whose matchings have
been finalized.
Step 15: The UNM notifies users of the outcome of their requests via email over TCP/IP.
76
7 IMPLEMENTATION: USER EXPERIENCE
7.1 Introduction
MARI is a web application that allows users to perform complex tasks involving
buying and selling of goods and services in an online marketplace. These tasks include
creating customizable agents that find appropriate transaction partners based on the user's
preferences, editing these agents, viewing current market activity, and viewing market
history. The user interface for MARI was designed to enable users to perform these tasks
easily and effectively. Attention was given to presentational elements and aesthetics as
well to create a more enjoyable user experience.
7.2 Overview
The user interface for MARI consists of HTML pages that capture all the various states
that a user can be in when using MARI. These include pages for logging in, registering,
creating agents, editing agents, viewing market activity, and viewing market history, as
well as success pages that provide confirmation that a task has been completed
successfully, and error pages that inform the user that an error has occurred. Embedded
stylesheets containing information about colors, fonts, and positioning provide a basic
template for these pages. Browser compatibility issues were taken into account when
creating these pages, and the system is intended for use on Internet Explorer 4.0 and
above, and Netscape Navigator 4.0 and above. Figure 10 schematically illustrates various
front-end states that users may experience when using MARI.
The user interface was built to be integrated with a back-end component
implemented as a collection of Active Server Pages (ASP) scripted in JScript. The backend provides the functionality for matching up prospective buyers and sellers with
appropriate transaction partners.
The back-end also provides the functionality for
carrying out all the user tasks outlined above. The data for the system is managed using a
relational database, where it is accessed and updated as users perform their various tasks.
77
The entire system is running on Microsoft Internet Information Server (IIS) and
Microsoft SQL Server.
index
login
logout
registration
welcome
welcomenew
create new
agent
market statu
create
a
age
market
history
nt
buyin g1
(select profile
view agent
view
al
expired
a
ents
create buying
(select
languages)
e i
edit preferre
values
uying
e i ac
agents
range
edit
create
sellingi
ive
c
creat
2
selling2
view expired
agents
agents
edit
seIIng
agents
(same as edil
buying agents
edit
profile
create buying
(specify
values)
create
selling3
create buying
(specify
ranges)
selling4
create buying
(utility
create
selling6
success buyin
sullss
create
e dit utility
functions
view utility
edit buying
functions
functions)
success
Figure 10: Flowchart Schematically Illustrating Major MARI Front-End Modules
The integrated pages contain both HTML and ASP code. The ASP code is interpreted in
the script engine of the server, which then carries out the specified instructions. These
instructions can consist of querying the database for information and generating and
displaying a dynamic HTML page with the information.
When the user submits
information through a form, that information is processed by the ASP specified as the
action of the form. The information can then be passed into functions, used to perform
calculations, inserted into the database, or used to make other changes in the database.
Figure 11 graphically illustrates the various back-end components and the interrelationships between these.
78
defauft-asp
Redirects to login
login.asp
for login
information.
Asks
u
Logout.asp
register.asp
Registers a
new user.
welcomeasp
User info.
7A
A 6change-basic-
usrChange
P
Re directs to
tch
saecific
name
password, etc.
market.
specificmarket-asp
-_
Displays all the
agents of the usE r
in this m arket.
---
market-
watch.asp
Gives full market:
s 1nfo rm ati o
statu
number of agent:i
number of users;
logged in. etc.
im o.asp
--
createagerit-asp
---
Choose buy/sell.
market-
history.asp
choose-
Lists all the close d
-commited
profile.asp
profile fC F
transction forChoose
trhnsakt.s
this
the
agent to
be
mrket.created.
stcartrequest.asp
Initialize request,
asks user market -
specific
questions.
marketparameters.asp
Calculate UF's
placerequest.as
p
Calculate bids aiid
asks.
matching.asp
Matches all users;
in the system.
Figure 11: Flowchart Illustrating Major MARI Back-End Modules
79
7.3 Major User-Driven Functional Operations
To use MARL, the user must first either login or register as a new user. The user only
needs to enter a preferred username and password to register. Once the user has logged
in, he has the option of doing one of the following: Create a new agent, view existing
agents, view the current market status, view the market history, or log out. These five
options appear as links on every page the user visits if he is logged in.
7.3.1 Creating a New Agent
The user can choose to create a new buying agent or create a new selling agent.
a) Creating a New Buying Agent
There are five steps to creating a new buying agent.
Step 1: Choosing a buyer profile. Each profile has pre-associated utility functions that
define how preference changes as each attribute is varied over its permissible range. The
buyer has the option of changing these values in later steps, but may also leave them
unchanged if he wants to.
Within the context of our language translation market
prototype, there are two buyer profiles, the professional buyer profile and the casual
buyer profile (see Figure 12).
The professional buyer profile represents high time
sensitivity, high seller reputation sensitivity, and high seller expertise sensitivity. The
casual buyer profile represents low time sensitivity, low seller reputation sensitivity, and
low seller expertise sensitivity.
80
Figure 12: Choosing a Buyer Profile
Step 2: Selecting a translationservice. The buyer selects the translation service he is
interested in buying by choosing the language to translate from and the language to
translate to. Currently, the available languages are Spanish, French, German, Italian,
Dutch, Russian, and English.
Step 3: Specifying preferred values (see Figure 13). The buyer specifies his preferred
values for each of the following attributes: Number of words, seller reputation, seller
expertise, and task completion time. Seller reputation can range from 0 (worst) to 10
(best), seller expertise can range from 0 (worst) to 5 (best), and task completion time can
range up from 10 minutes. The buyer also specifies his maximum bid for a seller that
matches all the preferred values in the ideal "offer" configuration.
81
Step 4: Specifying permissible ranges (see Figure 13). The buyer specifies permissible
ranges for flexible attributes in this step. Seller reputation, seller expertise, and task
completion time are flexible attributes; number of words is not a flexible attribute. The
preferred value specified in Step 3 must be within the permissible range. The buyer also
specifies bid ranges in this step. This is accomplished by asking the buyer a series of
questions. The buyer is asked to associate a bid value with "bundles" of attributes such
that, in each bundle, a particular flexible attribute is held at the lowest or highest endpoint
of its permissible range, while all other attributes are held constant at their optimal
values. This, in effect, allows the buyer to valuate differently qualified sellers, and the
information is used to generate a mathematical approximation of the buyer's utility
function corresponding to each flexible attribute.
Figure 13: Specifying Permissible Ranges for Flexible Attributes
82
Step 5: Selecting utility functions. Each of the flexible attributes has a utility function
associated with it that defines how the buyer's preference changes as the attribute varies
over the permissible range specified in Step 4 (see Figure 14). The utility functions are
preset (by the market maker) to the values associated with the buyer profile selected in
Step 1. The buyer may leave these values unchanged, or he may change them to match
his preferences more accurately.
Figure 14: Selecting Utility Functions
Finishing up. At the end of step 5, the buyer may click the "Create Agent" button to
finish creating the new buying agent. He is then taken to a confirmation page that
informs him that the agent has been successfully created. This page also displays the
83
time that the next market cycle will be run, when his results (i.e. information about a
suitable seller) will be emailed to him.
b) Creating a New Selling Agent
There are five steps to creating a new selling agent.
Step 1: Choosing a seller profile. Each profile has pre-associated utility functions that
define how preference changes as each attribute is varied over its permissible range. The
seller has the option of changing these values in later steps, but may also leave them
unchanged if he wants to. There are two seller profiles, the professional translator
profile and the casual translatorprofile. The professional translatorprofile represents
low time sensitivity, moderate (linear) number of words sensitivity, and high buyer
reputation sensitivity. The casual translatorprofile represents high time sensitivity, high
number of words sensitivity, and low buyer reputation sensitivity.
Step 2: Selecting a translationservice. The seller selects the translation service he wants
to sell by choosing the language to translate from and the language to translate to.
Step 3: Specifying preferredvalues. The seller specifies his preferred values for each of
the following values: Number of words, buyer reputation, and task completion time.
Buyer reputation can range from 0 (worst) to 10 (best), and task completion time can
range from 10 minutes to 100 minutes. The seller also specifies his minimum ask price
for a buyer that matches all the preferred values.
Step 4: Specifying permissible ranges. The seller specifies permissible ranges for flexible
attributes in this step. Number of words, buyer reputation, and task completion time are
all flexible attributes.
permissible range.
The preferred value specified in Step 3 must be within the
The seller also specifies ask price ranges in this step.
This is
accomplished by asking the seller a series of questions. The seller is asked to associate a
ask value with "bundles" of attributes such that, in each bundle, a particular flexible
attribute is held at the lowest or highest endpoint of its permissible range, while all other
84
attributes are held constant at their optimal values. This, in effect, allows the seller to
valuate differently qualified buyers, and the information is used to generate a
mathematical approximation of the seller's utility function corresponding to each flexible
attribute.
Step 5: Selecting utility functions. Each of the flexible attributes has a utility function
associated with it that defines how the seller's preference changes as the attribute varies
over the permissible range specified in Step 4. The utility functions are preset (by the
market maker) to the values associated with the seller profile selected in Step 1. The
seller may leave these values unchanged, or he may change them to match his
preferences more accurately.
Finishing up. At the end of step 5, the seller may click the "Create Agent" button to
finish creating the new selling agent. He is then taken to a confirmation page that
informs him that the agent has been successfully created. This page also displays the
time that the next market cycle will be run, when his results (i.e. information about a
suitable buyer) will be emailed to him.
7.3.2 Viewing Existing Agents
The user can choose to view, edit or delete his active agents, view his matched agents and
review or confirm "pending" transactions, view his expired agents, view all active agents,
or view all expired agents.
a) Viewing, Deleting and Editing Active Agents
The user is given a list of all his currently active buying and selling agents and some
information (such as source and target translation languages) about what each agent is
trying to buy or sell, as well as the time at which the agent was created. He can choose to
view the details, delete or edit any of those agents by clicking on it. He is then taken to a
page that displays the information for that agent (see Figure 15). If the user has never
edited the agent before, the values specified when creating the agent are displayed. If the
85
user has edited the agent before, the most recent changes that have been made will show
up in the values that are displayed.
Figure 15: Editing a Selling Agent
This information is divided up into five sections corresponding to the five steps involved
in creating an agent. The five sections are: buyer or seller profile selection, translation
languages, preferred values for attributes (offer), permissible ranges of flexible attributes,
86
and utility functions corresponding to flexible attributes. At the end of each section is a
link that allows the user to edit the values for that particular section. This link takes the
user to a page similar to the page for the corresponding step when creating the agent. The
current values for the fields in that section are pre-selected in the form and the user can
then make any changes he wants to those values. When he is finished, he may click
"Submit" to update the agent with his changes. He is then taken to a confirmation page
that informs him that his changes have been successfully made. From there, he may
choose to make more changes to the same agent, edit another agent, or delete an active
agent.
Example. Editing the preferredvalues for a selling agent. The information page for the
agent will display the five sections corresponding to the five steps to creating a selling
agent.
The third section, titled "Preferred Values," lists the current values for the
following information: Number of words, buyer reputation, task completion time, and ask
price. The user then clicks "Edit your preferred values" to make his changes. He is taken
to a page with the same form he filled out in Step 3 when creating this agent, except that
his current preferred values for number of words, buyer reputation, and task completion
time are already filled out in the form. He can then edit these values to his liking and
click "Submit" to update the agent with these changes.
b) Viewing Matched Agents
Matched agents comprise the subset of active agents that are involved in "pending"
(mutually unconfirmed) transactions. The user has the option of viewing the details of a
matched agent or deleting it. Additionally, the user can review and (subsequently)
confirm the matching that the system has selected for the matched agent (see Figure 16).
When a user clicks on the "Review/Confirm Transaction" link adjacent to each
matched agent listing, he is taken to another page which shows the details of the "deal"
that the system has selected for the agent. "Transaction details" consist of a listing of
relevant attributes and their values corresponding to the "Optimal Deal Configuration"
(OTC) that the agent has been matched with (see Figure 17). In addition, when
"reviewing" a matched agent, the user not only sees the details of the "deal" associated
87
with his matched agent, but also sees details of "potential" deals with other qualified
transaction partners that were considered and, further, is able to see whether these
prospective transaction partners were matched with someone else or not (see Figure 18).
Each deal shown to the user has a score metric associated with it. The score metric
printed with each deal reflects the surplus associated with that potential pairing. The idea
behind showing the user this information is to follow the general user-interface heuristic
that the user be given some contextual information that helps him better understand why
the system made the choice it did, and what other choices were taken into consideration.
The user can use this information to infer why his agent was not matched with other
qualified transaction partners and, via the score metric, can objectively situate the deal
chosen by the system in relation to other possibilities.
The user has the option of reviewing and confirming the deal associated with the
matched agent or doing nothing. Upon mutual confirmation by both parties involved in a
"pending" transaction, the transaction is said to become "closed," and the agents involved
are "Expired" from the market. When "reviewing" a matched agent, the owner is able to
see whether the other transaction partner involved in the matching has already
"confirmed" or unilaterally accepted. The presence of a unilateral confirmation by the
other side makes it clear, for instance, that the transaction will consummate (become
"closed") by mutual confirmation if the owner confirms as well.
88
Figure 16: Viewing Matched Agents
Figure 17: Viewing Details of the "Deal" the System has Selected for a Matched Agent
89
Figure 18: Viewing Alternatives that Were Taken Into Account for a Matched Agent
c) Viewing Expired Agents
This page displays the user's expired agents (agents involved in "closed" or mutually
confirmed transactions), the translation languages corresponding to each, the price at
which the service was sold, and the date and time the agent was created. The user cannot
edit his expired agents, but has the option of being able to "reactivate" these, in which
case the agent's status shifts from "Expired" to "Active," and the agent becomes eligible
to be matched in future market cycles.
d) Viewing All Active Agents
This page displays all active agents in the marketplace at the current time, the translation
languages corresponding to each, the bid or ask price of the translation service the agent
is trying to buy or sell, and the date and time the agent was created.
90
e) Viewing All Expired Agents
This page displays all expired agents in the marketplace, the translation languages
corresponding to each, the price at which the transaction was closed, and the date and
time the agent was created.
7.3.3 Viewing Market Status
The user can view the current marketplace activity on this page. Information that is
provided includes the current number of active buying and selling agents, the number of
matched buying and selling agents (active agents involved in mutually unconfirmed,
"pending" transactions), and the number of expired buying and selling agents (agents
involved in mutually confirmed, "closed" transactions).
The user is shown a listing of active agents with information about what each
agent is trying to buy or sell and at what price. The user can optionally view more details
about any individual agent to see ranges and utility functions corresponding to various
attributes. Additionally, the system differentiates between active agents that have already
been matched by the system and those that are currently unmatched.
Finally, the market status page also lists all pending transactions in the market,
giving details of the transaction including the final attribute values for all relevant
attributes associated with the deal, the final closing price, and links to detailed views of
the buyer and seller agents involved.
The purpose of the Market Status page is to give a user a complete and
informative snapshot of the market. Not only can a user gauge what prospective
transaction partners might be available for an agent he might create, but can also
implicitly receive signals about prevailing market prices, and competition his agent can
expect to face from other active agents.
7.3.4 Viewing Market History
The user can view the transaction history of the market on this page. A list of the last ten
market cycles (exact number is configurable by the MarketMaker) is displayed, along
with the date and time at which each cycle was completed. The user can click on any of
91
these cycles to pop up a window which lists all "closed" transactions (transactions that
have been mutually confirmed by the buyer and seller involved in the matching) (see
Figure 19).
The detail page for each cycle displays the date and time at which it was
completed and the number of matches that were made during the cycle. For each
transaction, we show the details of the transaction including the final attribute values for
all relevant attributes associated with the deal, as well as the closing price at which the
transaction was consummated.
The purpose of the Market History page is to give the user a cumulative historical
snapshot of the market. The user can thereby infer market trends, as well as gain insight
into characteristics of deals that were consummated by both of the involved transaction
partners. This information can help the user set realistic expectations of what his agents
can hope to accomplish, and tailor his agents so as to maximize chances of eventually
reaching a consummated transaction, that would be appealing from the perspective of
both parties involved in a potential pairing.
92
Figure 19: View Market History
7.3.5 Logging Out
The user can log out at any time while using MARI. If he is in the middle of creating or
editing an agent, the process will not be completed and there will be no record of it.
7.4 Usability Considerations
The MARI user interface was designed so that it would be easy to learn, easy to
understand, and easy to use. The user tasks themselves are not very complex, but the
concepts behind the functionality of the system may be more difficult to understand for
those that have no experience with using software agents. Therefore, care was given to
making it as easy as possible to understand the system as well as making it as easy as
possible to use the system.
93
As discussed earlier, there are four main functions that users can perform when
using MARI.
These functions are: creating new agents, viewing and editing existing
agents, viewing current market activity, and viewing market history. Links to performing
each of these tasks are displayed prominently at the top of each page the user visits after
logging in. A fifth link to log out of the system is also displayed with the other links so
that the user can quit at any time.
When creating and editing agents, each step is clearly labeled and a detailed
explanation of what the user is expected to do in that step is given. Detailed explanations
are also given when the user is dealing with a concept that may be difficult to understand.
For example, when choosing a buyer or seller profile, a description of each profile is
given so that users may choose the one that is more appropriate for them (see Figure 12).
The user is also informed that the pre-associated utility functions for each profile can be
changed later on so that he will not feel uncomfortable selecting a profile even if he is not
sure it is the right one for him. The selection of a buyer or seller profile is an important
usability consideration in itself because it allows inexperienced users who will have
trouble selecting utility functions to skip this step altogether.
For sections with forms that have more than one field to fill out, each field, with
its own instructions, is clearly separated from those around it with a horizontal line,
making it easier to distinguish between them and enabling users to enter their information
more quickly.
Examples of these sections are specifying preferred values and
permissible ranges when creating a new agent (see Figure 13).
The most complex user task in MARI is editing agents. A possible way to create
the pages for editing agents was to make them exactly the same as those for creating
agents. However, users may not want to change something in every section, and for these
users, it would be inefficient to go through all five steps when they only want to make a
change in one section. It is also inefficient for users who want to edit, for example, Steps
2 and 5, of the 'create agent' sequence, to have to go through all the steps, 1 through 5,
sequentially. Therefore, the information page (see Figure 15) for editing an agent allows
the user to choose the section they want to edit. It also displays the current values for
each section so that the user can find the field they want to edit quickly. When the user
94
has finished editing a section, he is taken to a page that gives him the option of editing
another section easily.
Pop-up windows are used when it is more convenient for the user to not leave the
current page when viewing the information in the new page. When the user selects utility
functions for creating or editing an agent, it is more convenient to be able to view the
graphs for the utility functions and make their selections at the same time (see Figure 14).
When viewing market history, it is also more convenient to view information for more
than one market cycle at the same time if the user wants to make comparisons.
7.5 Conclusions
Although we are reasonably satisfied with the current state of the MARI interface, we can
envision a number of changes that may be made in the future, so as to enhance usability.
The addition of more explanations to help users understand the system would be
especially important if MARI was to be presented to a wider audience in the future.
Users with limited technical knowledge may have difficulty when creating an agent if
they do not fully understand how their choices, especially when selecting utility
functions, will affect the results. The option of selecting a buyer or seller profile at the
start of the agent-creating process so that inexperienced users are not required to select
utility functions themselves mitigates this problem, but users will still need to know how
to select utility functions themselves to improve their chances of being matched up with a
transaction partner they are happy with in different situations. It would also be helpful to
view some sample agents with sample results so that they could learn more about how
each aspect of an agent affects the end results. The pages for viewing market history
provide the results of matchings, but not the details of the buying and selling agents
involved. Users also need to be provided with more information on what their choices
mean, for example, exactly what a seller of an expertise level of 7 implies.
Some of the choices made for the "look and feel" of the user interface also
interferes with its usability. The biggest problem is the readability of white text on a red
background, especially for users that have weak vision or are colorblind.
Another
problem is the fonts used for the heading and caption on every page, which may be
95
difficult to read as well. There may also be some confusion caused by the doubling of the
links on the navigation bar, because both the text links and the smaller boxes underneath
them link to the same pages.
Overall, the user interface design for MARI is satisfactory for the time being
because the intended audience consists mainly of those that already have knowledge of
software agents and are more interested in the functionality of the system than its
usability.
In the future, however, some changes could \be made for the system to be
successful with a wider, less-specialized, audience.
96
8 EVALUATION: MARKET SCENARIOS
8.1 Market Variables and Possible Scenarios
In order to illustrate the system's functionality we simulated a few carefully chosen
market scenarios. We identified the following underlying variables to be of interest in
selecting suitable scenarios:
1. Market Participants: Market segmentability or homogeneity ofparticipantsdetermines
the extent to which buyers and sellers are homogenous within their respective groups -i.e. the extent to which each seller is similar to other sellers and each buyer is similar to
other buyers, both in terms of their preferences for the transaction partner, as well as
their own attributes. This, in turn, determines the extent to which buyers and sellers can
be segmented into easily differentiable, distinct groups.
2. Market Participant Preferences: Correlated versus uncorrelated price points and
valuations determine the extent to which buyers or sellers, within their respective groups,
generate independent and uncorrelated bids or asks. Valuations can be said to be
uncorrelated (or "private") when, for instance, two different buyers with similar
underlying preferences bid differently, in absolute monetary terms, for a seller who is
equally "good" in an objective sense. Valuations can be said to be correlated (or
"public") when the two buyers somehow are able to peg the absolute level of their bids,
perhaps using market signals such as 'Market Status' or 'Market History' that would
provide cues as to how the seller, or similar sellers, are valuated by the market at large.
In the vast majority of cases, goods and services lend themselves to public
valuation, and there are generally sufficient market signals present so that buyers and
sellers are able to infer the prevalent market price. Moreover, in our system, the purpose
behind creating Market History and Market Status pages is precisely so that buyers and
sellers will be able to gain access to such market signals. As such, even though the case
of uncorrelated or private valuations is interesting in certain niche cases, such as trading
97
of authentic art pieces, we will mostly limit our analysis to the more general case of
correlated valuations.
3. Macro-market Factors: Market power determines the extent to which a given buyer or
a seller might be able to position himself as a dominant player. For the purposes of our
system, a seller, for instance, can be said to have market power when he is the only one
present amongst several buyers, thus giving him more implicit negotiation power in being
able to select the optimal from a variety of potential deals.
Using binary values for the above variables, we can imagine eight possible market
simulations:
a). Homogenous market participants with correlated price points, no market power. This
scenario is not interesting because if participants are homogenous and have correlated
valuations, then they will all be exactly identical. In this case matching would be trivial
since any buyer could be matched with any seller.
b). Homogenous market participants with correlated price points, market power present.
This scenario is not interesting for the same reason as (a).
c). Homogenous market participants with uncorrelated price points, no market power.
This case is further explored in "Scenario 1" below. This is the only case in which we
examine uncorrelated or private valuations, since the concept of correlated valuations is
meaningless when market participants are homogenous.
d). Homogenous market participants with uncorrelated price points, market power
present. This scenario is not interesting since if the participants are homogenous (i.e. all
buyers are similar and all sellers are similar), and if a given seller, say, has market power,
then the seller can be trivially matched with the prospective buyer whose offer bid is the
highest.
98
e). Heterogeneous market participants with uncorrelated price points, no market power.
We will not examine this case since, in this context, the case of uncorrelated or private
valuations is of niche interest and not of sufficient generality.
f). Heterogeneous market participants with uncorrelated price points, market power
present. We will not examine this case for the same reason as (e).
g). Heterogeneous and segmentable market participants with correlated price points, no
market power. This case is further explored in "Scenario 2" below.
h). Heterogeneous market participants with correlated price points, market power present.
This scenario is interesting both for the monopoly (seller has market power) ("Scenario
3" below) and monopsony (buyer has market power) ("Scenario 4" below) cases.
From the above analysis, it is clear that only cases 'c', 'g' and 'h' (2 subcases) ought to
be simulated. These are further discussed in the following scenarios 1-4. Case 'h' is
discussed in both scenarios 3 (seller has market power) and 4 (buyer has market power).
These scenarios effectively illustrate how our system works under different market
conditions.
8.2 First Scenario
Case 'c': Homogenous market participants with uncorrelated price points, no market
power.
Overview: Three Buyers (see Table 7, Table 8, and Table 9) and two Sellers (see Table
10 and Table 11), in the market for French to German Translations. The buyers and
sellers are identical except for their offer bid or ask values. All the buyer agents are
qualified for all the seller agents, and vice versa. This scenario illustrates how our system
maximizes welfare and achieves Pareto optimality.
99
Optimal
(Offer)
Attribute
Utility
Function
Bid Range
Value
B1
Reputaion=5
OfferBid=$420
Permissible
Range
Words
Seller Skill
Seller
Reputation
Time (mins)
4000
3
5
Fixed
2-5
4-10
N/A
UF9
UF9
N/A
N/A
N/A
40
30-50
UF6
$430-$400
Table 7: Scenario 1, Buyer 1 (Bi)
Optimal
(Offer)
Attribute
Permissible
Range
Utility
Function
Bid Range
Value
B2
Reputation=5
OfferBid=$350
Words
Seller Skill
Seller
Reputation
Time (mins)
4000
3
5
Fixed
2-5
4-10
N/A
UF 9
UF9
N/A
N/A
N/A
40
30-50
UF 6
$360-$330
Table 8: Scenario 1, Buyer 2 (B2)
Optimal
(Offer)
Attribute
Utility
Function
Bid Range
Value
B3
Reputation=5
OfferBid=$450
Permissible
Range
Words
Seller Skill
Seller
Reputation
Time (mins)
4000
3
5
Fixed
2-5
4-10
N/A
UF9
UF9
N/A
N/A
N/A
40
30-50
UF 6
$460-$440
Table 9: Scenario 1, Buyer 2 (B2)
Attribute
S1
Reputaion=5
Skill=3
OfferAsk=$250
Words
Buyer
Reputation
Time (mins)
Permissible
Range
Utility
Function
Ask Range
Optimal
(Offer)
Value
4000
5
Fixed
4-10
N/A
UF 9
N/A
N/A
40
30-50
UF6
$260-$230
Table 10: Scenario 1, Seller 1 (S1)
Attribute
S2
Reputation=5
Skill=3
Offer Ask=$300
Words
Buyer
Reputation
Time (mins)
Permissible
Range
Utility
Function
Ask Range
Optimal
(Offer)
Value
4000
5
Fixed
4-10
N/A
UF 9
N/A
N/A
40
30-50
UF6
$260-$230
Table 11: Scenario 1, Seller 2 (S2)
100
Results: Based upon the structure of our examples, we can precisely determine the
theoretical surplus that would be generated between any potential buyer seller pairing.
These computed surplus values are shown in Figure 20. MARI, based upon an
approximation of user preferences, generates numbers that are remarkably similar (see
Figure 21).
7.
29W
Figure 20: Theoretically Calculated Surplus Values Corresponding to each Potential Match
208 0
Figure 21: Actual System Generated Surplus Values Corresponding to each Potential Match
Using the heuristic of surplus maximization, MARI determines that Si ought to be
matched with BI, S2 should be matched with B3, and B2 should be left unmatched. The
"closing price" corresponding to each potential transaction is shown in
101
Table 12. By inspection, it is clear that the (SI-B1, S2-B3) matching output by the system
is Pareto optimal.
Closing Price
Pairing
SI-BI
$344.70
S1-B2
$308.62
S1-B3
$361.08
S2-B1
$370.41
S2-B2
$334.39
S2-B3
$386.85
Table 12: System Generated Closing Prices Corresponding to Each Potential Pairing
Within our system, the above information is visible to each agent owner's when they log
in to "review or confirm" potential transactions. For instance, when S2's owner logs in,
he sees the details of the "deal" associated with his matched agent (see Figure 22). In
addition, he sees details of potential deals, including closing price, with other qualified
transaction partners that were considered (i.e. deals with B1 and B2) and, further, is able
to see whether these prospective transaction partners were matched with someone else or
not (see Figure 23). The score metric printed with each "deal" reflects the surplus
associated with that potential pairing. Similarly, the details seen by Bi's owner are
shown in Figure 24.
102
Figure 22: S2's owner sees details of the "deal" associated with his matched agent
Figure 23: S2's owner sees details of potential deals with other qualified transaction partners that
were considered and whether these prospective transaction partners were matched with someone else
103
Figure 24: Details Seen by B1's Owner
8.3 Second Scenario
Case 'g': Heterogeneous and segmentable market participants with correlated price
points, no market power. This scenario illustrates how our system facilitates value
creation via differentiation, and how scarce resources are allocated in an appropriate
fashion.
Overview: Two Buyers and two Sellers, in the market for English to German
Translations. The buyers and sellers are differentiated into 2 segments each: Professional
Buyer (B 1), Casual Buyer (B2) and Professional Seller (S1), Casual Seller (S2).
104
Attribute
B1
Reputation=10
OfferBid=$100
Words
Seller Skill
Seller
Reputation
(mins)
_Time
B2
Reputation=5
OfferBid=$70
_
Words
Seller Skill
Seller
Reputation
Time (mins)
Bid Range
Fixed
3-5
5-10
N/A
UF 3
UF 3
N/A
$70-$100
$70-$100
30
30-90
UF,
$100-$70
Table 13: Scenario 2, Buyer
Attribute
Utility
Function
Permissible
Range
Optimal
(Offer)
Value
4000
5
10
1 (Professional Buyer)
Utility
Function
Permissible
Range
Optimal
(Offer)
Value
4000
3
5
Bid Range
Fixed
3-5
5-10
N/A
UF 9
UF9
N/A
N/A
N/A
30-90
UF6
$85-$70
I
90
Table 14: Scenario 2, Buyer 2 (Casual Buyer)
Attribute
S1
Reputation=10
Skill=5
OfferAsk=$80
Words
Buyer
Reputation
Time (mins)
S2
Reputation=5
Skill=3
OfferAsk=$60
Words
Buyer
Reputation
Time (mins)
Ask Range
Fixed
5-10
N/A
UF5
N/A
$100-$80
30
30-90
UF 9
N/A
Table 15: Scenario 2, Seller
Attribute
Utility
Function
Permissible
Range
Optimal
(Offer)
Value
4000
10
1 (Professional Seller)
Permissible
Range
Utility
Function
Ask Range
Optimal
(Offer)
Value
4000
5
Fixed
5-10
N/A
UF 9
N/A
N/A
90
30-90
UF6
$90-$60
Table 16: Scenario 2, Seller 2 (Casual Seller)
Results: MARI determines that SI (professional seller) ought to be matched with the B 1
(professional buyer), and that S2 (casual translator) should be matched with B2 (casual
buyer). The matching, as well as surplus associated with potential transactions is shown
in Figure 25. The "closing price" corresponding to each potential transaction is shown in
Table 17.
105
B i
19.65
Ne afive
7X
SB1N/(Bd<Ak
Figure 25: System Generated Surplus Values Corresponding to each Potential Match
Closing Price
Pairing
SI-Bi
$82.68
S1-B2
$89.46
S2-B 1
N/A (Bid < Ask)
S2-B2
$57.75
Table 17: System Generated Closing Prices Corresponding to Each Potential Pairing
This scenario illustrates how MARI effectively provides a framework by which buyers
and sellers may differentiate themselves to create value. The total value created by a
transaction can be interpreted as being equivalent to the surplus generated by that
transaction, or the difference between the buyer's willingness to pay (WTP) and the
supplier's ask price. A competitive advantage, in business strategy, is typically
interpreted as one that widens the gap between WTP and ask price. MARI facilitates
value creation by allowing buyers and sellers to sufficiently differentiate themselves from
other players in the market, and thereby create a competitive advantage.
In traditional markets, there is no mechanism by which a professional buyer (B 1),
for instance, can instantiate an agent with variable degrees of preference and valuation for
different (professional and casual) seller segments. The buyer can merely assume that
there is some mixture of the two types of sellers in the market and bid something in
between his differentiated bids corresponding to different seller segments. In our
scenario, for example, Bl's bids for a professional translator and a casual translator are
106
$100 and $70 respectively. However, if there is no mechanism by which sellers can
convey their differentiated product offerings, BI will only be willing to bid something in
between $70 and $100, say $85 (halfway in between the differentiated bids). Using the
same reasoning, B2's bid will be $77.5, Sl's ask price will be $90 and S2's ask price will
be $75. In this case, B 1 (professional buyer) will be undesirably matched with S2 (casual
seller), leading to a circumstance akin to the classical "lemons" problem of economics,
that stems from information asymmetries between buyers and sellers [48].
Figure 26 and Figure 27 illustrate how MARI facilitates greater value creation,
and more appropriate allocation of scarce resources compared to traditional marketplaces.
Figure 26: Value Created in a Traditional Market
107
Figure 27: Value Created by MARI
8.4 Third Scenario
Case 'h': Heterogeneous market participants with correlated price points, market power
present. Seller has market power (Monopoly).
Overview: Monopoly. One Seller and three Buyers in the Market for English to Russian
translations. This scenario illustrates how our system automatically identifies a suitable
deal and transaction partner for a given seller from potentially many possibilities.
Attribute
S1
Reputation=10
Skill=5
OfferAsk=$200
Optimal
Permissible
(Offer)
Value
Range
Utility
Function
Ask Range
Words
4000
4000-8000
UF1
$200-$400
Buyer
Reputation
Time (mins)
7
5-10
UF 5
$260-$180
UF6
$250-$120
I
60
II
30-120
Table 18: Scenario 3, Seller 1 (Monopolist)
108
Attribute
B1
Reputation=10
OfferBid=$300
Words
Seller Skill
Seller
Reputation
Time (mins)
Permissible
Range
Utility
Function
Bid Range
Optimal
(Offer)
Value
5000
5
10
Fixed
3-5
5-10
N/A
UF 3
UF 3
N/A
$270-$300
$270-$300
30
30-90
UF 5
$300-$220
Table 19: Scenario 3, Buyer 1
Attribute
B2
Reputation=5
OfferBid=$400
Words
Seller Skill
Seller
Reputation
Time (mins)
Permissible
Range
Utility
Function
Bid Range
Optimal
(Offer)
Value
7000
3
5
Fixed
3-5
5-10
N/A
UF9
UF 9
N/A
N/A
N/A
90
30-90
UF6
$450-$400
Table 20: Scenario 3, Buyer 2
Attribute
B3
Reputation=10
OfferBid=$300
Words
Seller Skill
Seller
Reputation
Time (mins)
Permissible
Range
Utility
Function
Bid Range
Optimal
(Offer)
Value
4000
4
8
Fixed
4-5
8-10
N/A
UF
UF 1
N/A
$300-$350
$300-$400
60
30-60
UF 4
$400-$300
Table 21: Scenario 3, Buyer 3
Results: MARI determines that SI ought to be matched with B3. The surplus
corresponding to each potential buyer-seller pairing is shown in Figure 28. Table 22
summarizes the most important factors taken into consideration by the system in deciding
upon the final pairing of SI with B . In particular, Table 22 illustrates how, based upon
its modeling of user preference functions, the system is able to approximate what each of
the buyers are willing to bid for SI and, symmetrically, what ask price SI is willing to
take from each buyer. These bid and ask prices correspond to the myopically optimal
Optimal Transaction Configuration (OTC) that the system identifies for each potential
buyer-seller pair (see Figure 29 and Figure 30 for these transaction configurations).
When Si's owner logs in, he sees the details of the "deal" associated with his
matched agent (see Figure 29). In addition, he sees details of potential deals, including
109
closing price, with other qualified transaction partners that were considered (i.e. deals
with BI and B2) and corresponding scores (see Figure 30).
Our matching algorithm tries to find the value maximizing "deal" or optimal
transaction configuration for each potential pairing. An example of this is how the time
attribute is set to 45 minutes in the SI-B 1 pairing (see Figure 30), a value that lies exactly
midway between SI's optimal value of 60 minutes and Bi 's optimal value of 30 minutes.
Overall, the system identifies the deal where the greatest value is created and where the
buyer and seller stand to benefit the most in terms of the surplus they manage to capture.
Sl2.484Af
30.
Figure 28: System Generated Surplus Values Corresponding to each Potential Match
Ask
Bid
Pairing
S1-B
S1-B2
S1-B3
$265.00
$455.10
$456.25
$186.19
$452.62
$153.33
Closing Price
$225.60
$453.86
$304.79
Score (Surplus)
78.810
2.484
302.917
Table 22: Details of Potential Matches for S1 Considered by the System
110
Figure 29: Details Seen by Sl's Owner
Figure 30: Sl's Owner Sees Details of Potential Deals with other Qualified Transaction Partners
111
8.5 Fourth Scenario
Case 'h': Heterogeneous market participants with correlated price points, market power
present. Buyer has market power (Monopsony).
Overview: Monopsony. One Buyer and three Sellers in the Market for English to Spanish
translations. This scenario illustrates how our system automatically identifies a suitable
deal and transaction partner for a given buyer from potentially many possibilities.
B1
Words
Reputation=10
OfferBid=$400
Seller Skill
Seller
Reputation
Time (mins)
Bid Range
Utility
Function
Permissible
Range
Optimal
(Offer)
Attribute
Value
4000
4000-8000
UF
$400-$600
4
7
3-5
5-10
UF 3
UF 3
$360-$420
$360-$420
60
30-120
UF 5
$450-$330
Table 23: Scenario 4, Buyer 1
S1
Reputation=10
Skill5
OfferAsk=$300
Words
Buyer
Reputation
Time (mins)
I
N/A
$375-$300
N/A
UF5
Fixed
5-10
I
30
Ask Range
Utility
Function
Permissible
Range
Optimal
(Offer)
Value
5000
10
Attribute
I
30-90
_
UF 9
I
N/A
Table 24: Scenario 4, Seller 1
Attribute
S2
Reputation=5
Skill=3
Words
Buyer
Reputation
Offer Ask=$400
Time (mins)
Optimal
(Offer)
Value
7000
5
II
90
Permissible
Range
Fixed
5-10
_
30-90
Table 25: Scenario 4, Seller 2
Utility
Function
N/A
UF 9
II
UF 6
Ask Range
N/A
N/A
$600-$400
112
Optimal
(Offer)
Attribute
Permissible
Range
Utility
Function
Ask Range
Value
S3
4000
8
Fixed
5-10
N/A
UF 9
N/A
N/A
Skil=5
Words
Buyer
Reputation
Offer Ask=$300
Time (mins)
60
30-90
UF6
$325-$250
Reputation=10
Table 26: Scenario 4, Seller 3
Results: MARI determines that B 1 ought to be matched with Si. The surplus
corresponding to each potential buyer-seller pairing is shown in Figure 31. Table 27
summarizes the most important factors taken into consideration by the system in deciding
upon the final pairing of B 1 with Si. In particular, Table 27 illustrates how, based upon
its modeling of user preference functions, the system is able to approximate what each of
the buyers are willing to bid for SI and, symmetrically, what ask price SI is willing to
take from each buyer. These bid and ask prices correspond to the myopically optimal
Optimal Transaction Configuration (OTC) that the system identifies for each potential
buyer-seller pair (see Figure 32 and Figure 33 for these transaction configurations).
When Sl's owner logs in, he sees the details of the "deal" associated with his
matched agent (see Figure 32). In addition, he sees details of potential deals, including
closing price, with other qualified transaction partners that were considered (i.e. deals
with B 1 and B2) and corresponding scores (see Figure 33). Overall, the system identifies
the deal where the greatest value is created and where the buyer and seller stand to
benefit the most in terms of the surplus captured.
Si
251.
0.205
S2
Figure 31: System Generated Surplus Values Corresponding to each Potential Match
113
Ask
Bid
Pairin
BI-S
B1-S2
B1-S3
$524.29
$408.19
$441.79
$273.21
$407.99
$337.03
Closing Price
$398.75
$408.09
$389.41
Score Surplus
251.08
0.205
104.76
Table 27: Details of Potential Matches for B1 Considered by the System
Figure 32: Details Seen by B1's Owner
Figure 33: B1's Owner Sees Details of Potential Deals with other Qualified Transaction Partners
114
9 EVALUATION: USER TESTING
9.1 Introduction
While modeling of market scenarios allows us to better illustrate the behavior of our
system and exhibit its full range of functionality, no evaluation of such a system can be
truly complete without a user study to better understand usability and comprehensibility
considerations from the perspective of human users. Indeed, since MARI represents a
fundamentally novel paradigm for gathering and modeling user preferences, and for
matching buyers and sellers in electronic markets, a user study that addresses how well
prospective buyers and sellers are able to use and understand the system is of substantial
relevance and value. As such, we carried out a user study with real human participants, to
complement our evaluation of MARI via simulations of market scenarios.
9.2 Experimental Design
9.2.1 Objectives
Our user study was conducted with two major objectives in mind:
i). To evaluate the user interface of MARI, from a useability perspective;
ii). To evaluate the system holistically, in terms of end user satisfaction. End user
satisfaction was measured along a number of dimensions, including: how well users felt
that they were able to express what they wanted, to what extent users felt that they could
understand how the system works, and to what extent users felt satisfied with and
understood the rationale behind the transaction partner the system ultimately matched
them with.
9.2.2 Methodology
With the above objectives in mind, we decided to carry out two separate user studies,with
six subjects each, corresponding to the two distinct objectives. We formulated the
following (common) experimental methodology for each of the studies:
115
A. We started by giving each subject a 10 minute overview of MARI, and explained how
the system works. We also explained the meanings of technical terms in the context of
the system. Specifically, we defined the following terms for each subject: agent,
attributes, utility functions, optimal values, permissible ranges, active agents, expired
agents, matched agents, bids, asks, score metric (surplus), confirmation, transactions,
closed transactions, and pending transactions.
B. Next, we asked subjects to create an account, log in and take a couple of minutes to
navigate the major sections of the MARI Web site: View Agents, Create Agent, Market
Status, Market History.
C. Having pre-initialized the system with a number of seller agents that we had created
beforehand, we asked the subject to assume the role of a buyer. Specifically, we asked
each subject to assume one of the following personas:
1
A lawyer who requires a highly accurate and timely legal translation (high
seller reputation, expertise, and time sensitivity);
2 A tourist in a foreign city who wants real-time translation of a transcripted
conversation with a street vendor (low seller reputation and expertise
sensitivity, but high time sensitivity);
3
A student who wants to translate an email sent to him by a foreign pen-pal
(variable expertise and reputation sensitivity, low time sensitivity).
Since we expect buyer requirements on seller reputation and expertise in a translation
market to usually be correlated, the above three personas allow us to span all the
interesting possibilities that could arise from differential (high/low) levels of the variables
of interest.
D. Having assumed a persona, we asked the subject to go through the exercise of creating
a buyer agent. This agent was subsequently immediately matched by the system, with one
of the predefined seller agents.
116
E. We asked the user to look at Market Status, Market History and View Agents pages.
F. Finally, depending upon whether the subject was evaluating the interface or the system
as a whole, we posed a number of questions (discussed below).
9.3 Interface Study
9.3.1 Questions Posed
This study was very subjective in its scope and sought to uncover and assess general
interface-level usability considerations. For subjects who participated in this study, we
posed the following questions:
1.
We asked subjects to provide general written comments on what they liked and
disliked or found confusing about the interface.
2. We asked subjects to rate, from an ease-of-use perspective, how easy or difficult
(confusing) it was to perform a few tasks. We asked subjects to quantify their
ratings on a scale of 1-7, where 1 signified "extremely easy and understandable."
and 7 signified "extremely difficult and confusing." Specifically, we asked
subjects to rate the following experiences (the experimental variable name of
interest, corresponding to each question, appears in parentheses):
a. Logging into MARI and proceeding to the specific Language Translation
market (login);
b. Navigating between different parts of the site (navigate);
c. Initializing agent creation (create);
d. Selecting a user profile (profile);
e. Associating a price with the ideal offer configuration (offerprice);
f. Specifying permissible ranges and picking utility functions (rangeuf);
g. Answering system generated valuation questions pertaining to preferences
(valquestions);
117
9.3.2 Findings
a) Qualitative Findings
The written comments we receive on what subjects generally liked and disliked about the
interface, allowed us to gain a great deal of insight into what we could do to substantially
enhance the usability and intuitiveness of our system. Based upon the aggregated
comments we received, we implemented the following changes to the MARI user
interface:
1. In pages with multiple sections, horizontal lines were placed between adjacent sections
to clearly separate one section from the next.
2. There was originally a row of boxes in the navigation bar that served as an alternative
way to navigate the site.
These boxes are still there for aesthetic reasons but were
unlinked to minimize confusion.
3. Subjects were a bit confused that the title and all the links on the top changed after
going to the specific translation market from the generic MARI login page. The
background color of Translation Marketplace pages was changed to differentiate between
these pages and those outside the specific marketplace.
4. Subjects were confused by the presence of "Active Agents", "Matched Agents" etc.
headers in specific-market.asp in situations when there weren't any such agents in the
market. When there are no agents to list, we now display a line of text stating: "You do
not have any active agents so far..." (View Agents page); "There are no active agents in
the market so far..." (Market Status page), etc.
5. In market-watch.asp (Market Status pages), we now no longer underline text that is not
a link, since this was apparently causing some confusion amongst subjects. We found that
the Market Status page could get messy with too much information. It shows a list of all
active agents followed by a list of Pending Transactions. We have created links at the top
so that users can readily reach each of the sub-sections.
118
6. The "View Agents" link has been modified to read "View my Agents" so as to
differentiate this from the information displayed in Market Status (which shows all agents
in the market)
7. When looking at Pending or Closed transactions, we have now added links that allow
users to see details of the agents that actually took part in transactions.
8. When showing a user a listing of matched agents in the marketplace, we now
differentiate between the agents that are currently unmatched and those that are matched
but unconfirmed (i.e. involved in Pending Transactions).
9. The "Back to Welcome Page" link in Market Status and Market History has been
changed to read "Back to Translation Market" page and now links to a page which gives
the user a personalized view of his agents in the specific market. Previously, the link
would take the user back to the generic MARI login.
b) Quantitative Findings
A total of six subjects participated in our interface study. From the quantitative part of the
questionnaire, we collected the following data (see Section 9.3.1 for interpretation of
variable names and ratings):
119
Subject 1
1
3
1
1
4
3
3
Subject 2
Subject 3
Subject 4
1
2
1
3
2
3
3
2
3
3
3
3
5
5
4
3
4
3
3
4
4
Subject 5
1
3
3
3
3
3
3
Subjectf6
2
3
3
2
6
5
4
1.33
1
2.83
3
2.50
3
2.50
3
4.50
5
3.50
3
3.50
4
0.516
0.408
0.837
0.837
1.049
0.837
0.548
Mean:
Median:
Standard Deviation:
Table 28: Interface Experiment Results
As can be seen from Table 28, we found that, overall, most aspects of our system are easy
to use and understandable from the perspective of users. Associating a price with the
ideal offer (offerprice) manifested itself as the most non-intuitive operation. In general, it
took some time for subjects to realize that they could gain cues from the Market History
and Market Status page when specifying the offer price and selecting utility functions.
One way to alleviate this problem would be to provide this hint directly on the offer
specification page in the future. Reassuringly, most users did not find answering system
generated questions about their preferences to be tedious or difficult. In fact, this
interactive mechanism of iteratively extracting preferences was praised by several
subjects, who liked the dialogue style interaction schema. Subjects also did not seem to
have any trouble in visually associating utility functions with attributes. At a high level,
everyone seemed to grasp what the shape of the utility function conveyed. In many cases,
subjects chose to retain the default utility functions pre-associated with their selected
profile.
120
9.4 System Study
9.4.1 Questions Posed
Somewhat like the interface study, the system study was also subjective and quite highlevel in its scope. Our goal was really to evaluate the functionality of the system, in terms
of the end-user's satisfaction with the results and understanding of the system. We asked
subjects to provide quantifiable ratings along several dimensions using a scale of 1-7.
Specifically, we asked subjects to rate the following dimensions (the experimental
variable name of interest, corresponding to each question, appears in parentheses):
a. "To what extent did you feel satisfied with the transaction partner and deal the
system designated for you?" (dealsatisfaction)[Rate: 1 (not satisfied at all) ...7
(completely satisfied)].
b. "Based upon the preferences you had specified when creating your agent, and the
contextual information provided by the system about other qualified transaction
partners who were taken into consideration, to what extent did you understandthe
rationale behind the transaction partner and deal the system designated for
you?" (dealunderstanding) [Rate: 1 (do not understand at all)...7 (completely
understand)].
c. "When creating an agent, to what extent did you feel that the system allowed you
to adequately express your preferences?" (expressprefs) [Rate: 1 (could not
express preferences at all)....7 (could express preferences to the maximum
extent)].
9.4.2 Findings
A total of six subjects participated in our system study. From the quantitative part of the
questionnaire, we collected the following data (see Section 9.4.1 for interpretation of
variable names):
121
Subject 1
Subject 2
5
6
6
5
5
5
Subject3
5
6
5
Subject 4
5
5
4
Subject5
6
4
7
4
5
5
5.17
5.50
4.83
Subject6
Mean:
5
56
Median:
0.753
Standard Deviation:
0.408
1.049
Table 29: System Experiment Results
Several conclusions may be drawn from the data in Table 29. We see that, reassuringly,
the results are largely positive. The high mean values, and relatively small standard
deviations, confirm that, in general, users were satisfied with the results produced by
MARI, in every case they understood, at least to some extent, the rationale behind the
transaction partner and deal the system designated for them, and, overall, they were
reasonably satisfied with the extent to which the system allowed them to express their
preferences.
By
observation,
there
appears
to
be
some
correlation
between
dealsatisfaction and dealunderstanding,implying that subjects who felt most satisfied
with the deal and transaction partner MARI chose for them, were also the same
individuals who best understood the rationale behind the system's choice. As far as being
able to adequately express preferences, in retrospect, it seems that it might have been a
good idea to give users a frame of reference. While users did feel that they were able to
adequately express their preferences at a high-level, and they liked the fact that the
system proactively asked them questions about their preferences, it might have been
useful to allow users to use the interface of Frictionless Valueshopper [12] or Priceline
[35], for instance, so that they could better situate MARI relative to contemporary stateof-the-art systems.
122
9.5 Conclusions
Overall, we are pleased with the results of our user studies. The qualitative component of
the interface study allowed us to substantially benefit from direct user feedback, so as to
further improve the usability of the system. The quantitative aspect of the interface study
and the system study confirmed that, in general, users do find our system to be practically
useful, functionally advantageous, and adequately fathomable.
For more rigorous evaluation in the future, it would be meaningful to do a study with
two treatment groups: one group would use MARI to express preferences and find a
suitable deal and transaction partner, while the other group would use an existing
commercial system. Our goal would be to try to see whether improvements in perceived
quality of the outcome and improved satisfaction can be correlated with usage of MARI,
in a statistically significant manner. The biggest obstacle to embarking on such a study is
that we would implicitly need to exercise a great deal of control over aspects of the other
system, which might not be feasible. In order to isolate the relevant impinging factors, we
would have to ensure that the only thing that differs across the experience of subjects in
the two treatment groups is the system-interaction schema, or the method by which users
are asked to express their preferences, and the matching technique, by which buyer-seller
pairings are delineated. If we assume that our subjects will assume the role of buyers, we
would, for instance, have to ensure that the potential set of sellers available to these
buyers is identical in the two systems and, moreover, that the product or service being
traded is inherently identical across the two cases. Needless to say, it could be
cumbersome to exercise precise control over such factors.
123
124
10 CONCLUSION AND FUTURE DIRECTIONS
10.1 Conclusion
Motivated by the presence of significant deficiencies in contemporary electronic markets,
this thesis presents the design, implementation and evaluation of the Multi-Attribute
Resource Intermediaries (MARI) system. MARI attempts to overcome many of the
shortcomings of today's electronic markets and represents a novel paradigm for gathering
and modeling user preferences, and for matching buyers and sellers. MARI facilitates
dynamic, domain-independent marketplace
creation. It provides automation and
facilitates multi-attribute considerations that help transcend price as the only negotiative
dimension. Ultimately, MARI provides a framework for value creation, in a strategic
sense, by allowing buyers and sellers to sufficiently differentiate themselves from other
players in the market, and thereby establish a competitive advantage. Our evaluations, in
the form of market-scenario simulations, highlight the benefits that electronic markets
may derive from our system. Our user-studies confirm that participants in these markets
would find our system to be practically useful, functionally advantageous, and adequately
understandable.
10.2 Future Directions
Going forward, as the MARI architecture and implementation is further refined, we expect
to face a number of key questions. In particular, even though we have identified one set of
models by which agents will interact and transaction partners will be determined, several
issues remain to be addressed.
It would be instructive to explore what algorithms and technologies our system can
leverage in the process of information integration and representation, decision analysis,
modeling, and reasoning about utilities, heuristical learning and inference from userinteraction, facilitating inter-agent communication and negotiation, and attuning preexisting knowledge bases in developing and managing shared product ontologies. Further,
we would like to see how machine learning techniques can be used in assisting decision
125
support and negotiation, and could also facilitate dynamic alteration of bids and asks based
upon stochastic demand and supply patterns over finite horizons [19, 20, 21].
Although we have conducted a reasonable amount of evaluation, to more
comprehensively assess the viability of the ideas presented in this thesis, MARI must be
more formally evaluated in the future. Lying at the intersection of several fields of study,
MARI lends itself to evaluation using a wide range of multi-disciplinary techniques:
10.2.1 Economics and Game Theory
A formal game-theoretic analysis of MARI's user modeling and transaction brokering
techniques would shed further light on what types of strategies might be optimal for
buyer and seller agents, and would also help delineate market equilibrium conditions that
the system would lead to. An economic analysis of MARI's "mechanism design" would
allow us to better gauge whether the system is incentive compatible [15], such that each
economic agent has an incentive to reveal her true preferences, and not benefit from
systematically understating or overstating. More generally, we would be able to get a
better sense of the conditions under which the system can be "gamed," meaning that
agents can systematically misstate their preferences to gain an unfair advantage.
In some sense, the flexibility that MARI gives buyers in sellers in being able to
commit and de-commit from tentative transactions, as their agents are involved in
alternative deals, suggests a resemblance to a non-binding, iterative, first-price, sealedbid auction protocol. A game theoretic analysis along these lines, as well as possible
comparisons with other auction paradigms, such as Vickrey (second-price, sealed bid)
would be reasonable.
An alternative to purely theoretical analysis would be to execute automated
simulations and compile statistical inferences. This simulations, and in particular
comparison of these with other simulations of agent economies, such as those performed
by Kephart [37, 44], would help us better understand how our system allocates scarce
resources compared to alternative techniques.
126
10.2.2 User Interface Studies
MARI embodies a novel paradigm by which buyers and sellers are able to express their
preferences. Although we have conducted some basic usability testing that has helped to
drastically improve the usability and comprehensibility of the current interface, more
extensive user testing would need to be performed in the future, so as to be able to more
accurately gauge the effectiveness of the system.
The most important questions regarding MARI's ease of use and user interaction
schema have to do with whether buyers and sellers feel that the system permits them to
express their true preferences with reasonable comprehensiveness, whether the results
(tentative buyer-seller pairings) output by the system accurately reflect their underlying
preferences, and whether they feel transaction partners are significantly differentiated
using MARI versus other systems.
10.2.3 Operations Research
In the process of modeling user preferences and brokering transactions, MARI borrows
significantly from Operations Research, Network Optimization and Linear Algebra. It
would be interesting to see how the results produced by the system, and thus the user
experience, would change if we were to implement more elaborate modeling techniques.
For instance, we currently use a quadratic least square approximation for modeling multidimensional user utility functions. Experimenting with more complex, higher order
approximations would allow us to measure, for instance, the deviations in terms of
efficiency (total market surplus) that arise as a consequence of our approximations.
It would be also be interesting to undertake simulations that employ different
optimization heuristics, welfare metrics, and matching algorithms, and to see how the
quality of the outcome might change as we vary these parameters.
10.2.4 Software Engineering
In the process of implementing MARI, we have taken great pains to build a scalable,
robust system with a modular, generic data model. MARI is wholly domain independent
127
and readily extensible in terms of functionality. Nevertheless, further analysis needs to be
performed in order to assess the system's performance bottlenecks. In particular, if the
system is commercially deployed we would need to reassess performance limitations, and
would need to consider how our algorithms, particularly the core matching algorithm,
may be optimized for speed and fault-tolerance.
10.2.5 Market Research
It would be instructive to attempt to make generalized inferences about domain-specific
buyer and seller preferences by analyzing the user-preference data captured by the
system. For instance, aggregated buyer preferences for permissible attribute ranges,
utility functions and optimal attribute values would help sellers better understand which
value-added services their customers care about and which features are most important.
This information could then be used by sellers to tailor their product offerings to be more
compelling, given the mandate of the marketplace.
10.2.6 Value Proposition Analysis
An alternative mode of evaluation of our system could be to actually survey some current
buyers, sellers and "market makers" in electronic markets in an attempt to gauge whether
MARI's value proposition is sufficiently attractive. This would also help us better
understand what additional features could be added to the system so as to make it more
attractive from the perspective of prospective commercial users. In fact, the most
comprehensive evaluation of MARI's concepts would come from actually deploying the
system in a real world commercial setting. This would allow us to benefit from direct user
feedback to address considerations ranging from incentive compatibility, market liquidity,
and desirability of system-designated matchings, to more mundane concerns such as speed,
accuracy, data integrity, ease of use, and scalability
128
11 APPENDIX A: IMPLEMENTATION DATA
MODEL
MARI is implemented using three technologies: ASP (Active Server Pages) with Jscript,
SQL (Structure Query Language), and XML (extensible Markup Language). All data is
stored in the SQL tables. The exceptions are user-profile templates and market-specific
questions, which are stored in XML files. ASP files handle and process all the data
presented to the user. These files are completely domain-independent, and therefore it is
very easy to add new marketplaces to the system. In order to add a new marketplace to
the system, the administrator only needs to add two new files to the MARI root directory:
<marketname>Profiles.xml and <market name>Questions.xml.
11.1 Structured Query Language (SQL) Usage
The backbone structure of the MARI data model is comprised of a number of SQL tables.
These constitute several data abstractions.
Table 'Players' represents the user (see Figure 34). That is where the basic information
(name, email, etc.) about the user gets stored. The ISADMINISTRATOR field
distinguishes administrators from regular users. ASP uses this field to give more detailed
picture of the system, as well as additional powers, to the administrator. The most
important field is PLAYERlID, which uniquely identifies the user in the system. With
this parameter, one can get all the information about the user in the other database tables.
Basic personal information about administrators is hard-coded into the system by the
SQL scripts. Regular users fill up the table upon registration.
129
r PROFILE-ID
PLAVERID
9I PLAYER ID
FIRSTNAM
LAST.NAM
EMAIL
REQUESTID
PLAYERID
MARKETNAME
LOGINJNAME
LOGINPASSWORD
LOGINJDATE
ONLINESTATUSP
15_ADMINISTRATOR
REGISTRATIONDATE
REQUESTSTARTJDATE
REQUESTENDDATE
%NSELLP
tS.fXPMA6tE
NEWOLDP
DATESIFBIRTH
Figure 34: Table 'Players' and its Interaction with Other Tables
Table 'Markets' lists all the markets in the system, assigning a unique identifier
MARKETNAME to each of them. All other tables use this field to differentiate between
markets. This allows the MARI system to support multiple marketplaces simultaneously.
The following tables are used to store more specific information about each
market
(see
Figure
35):
MarketAttributes,
MarketProfiles,
MarketPlayersInfo,
MarketQuestions, and MarketAnswers. Specific information pertaining to any particular
market can easily be accessed via the MARKETNAME field of the Markets table.
Tables PlayerProfileMap and MarketPlayerRequests map the user to his profiles
and requests (equivalent to agents) respectively. Since users can have more than one
profile in different Markets, the PlayerProfileMap table usually has multiple entries for
each user. The MarketPlayerRequests table has MARKETNAME as one of the fields to
facilitate data handling.
Transactions (matched requests) are represented using the following tables:
PendingTransactions,
ClosedTransactions
and
TransactionAttributes.
PendingTransactions keeps track of all system-matched, but not yet finalized requests
(i.e. the system has matched a buyer-seller pair, but either the buyer, or the seller, or both
have not yet confirmed their intent to consummate the transaction based upon the system
matching). ClosedTransactions keeps track of all matchings that have been confirmed by
both the matched buyer and seller. Finally, TransactionAttributes shows the exact details
130
of each transaction, whether closed or pending. All three tables are bound together by the
common TRANSACTION_ID identifier.
MARKET NAME
ATTIRMBTE-AME
QUESTION.ALUE
ANSWERTYPE
MARKET NAME
ATTRIBUTENAME
ANSWER.YALUE
ANSWERJO
MAR
E
I
X ID
X-TVPE
ATTRIBUTEJD
PQRLTFILE ID
P
70 MARKETTID
MARKETNAME
PARKETNAME
M
MARKETRDESCUEUYTSELLEP
M4ARKETjADMIN
ID
PROFILE NAM ,E
BYSL-
STRA1SACTM-MJ
TRANSAC-DTEDNDPATE
MAPKETNAME
0V-_EREQUSTJD
REQUT
SMARKET NAME
REQUEST-START DATE
REQUEST ENDJDATE
BUYSELL P
VR.ACINAION
W
-TRANWAVION-DATI
BUYER-ID
SELLERJD
BUYER._REQUEST.ID
SELLER-REQUEST.JD
BLyER_C0W1RMAT10N
I5 EXPIRABLE
ISE~G'RA8LESELLER CONFIRMATOIJ
NEW-OLD-P
Figure 35: Table 'Markets' and its Interaction with Other Tables
Table 'Attributes' represents the attributes or features of products or services being
traded in MARI marketplaces. This is a generic and versatile table. It can readily hold
attribute information for Profiles, for Requests, as well as the request-history information
for the ClosedTransactions. In order to identify which attribute belongs to which type of
data, table MarketToXToAttributeMap comes into play (see Figure 36). It maps each
type of data-type (profile, request or transaction) to all the attributes associated with that
particular data-type using the X_ID identifier. MarketToXToAttributeMap is a very
important table that significantly simplifies the use of the other Tables.
131
'91 MARKET
ID
MARKETJNAME
MARKET DESC
MARKET-ADMIN-ID
PROFILEID
XI
MARKET-NAME
PROFILE-NAME
,
ATTRWUTETME
ATTRUEJWE
V REQUIEST.IM-
XTYPE
PLAYER-ID
XID
ATTRIBUTE_-ID
Selecdor
SMARKETNAME
REQUESTJSTARTDATE
REQLIEST-END DATE
-.
fUNCTION
COEFFYALUE
PERMS51BLERANGE-LFFEROLND
PERMSBLERANGELOWERSO~L
BElY_5ELLP
IS-EXPIRABLE
POSSOMLERANEJOWER.OMW
P055TLEANGE
NEW-OLD_
TP TR.ANSACTIONJD
UT
AO
Al
A2
ERBc'JJ
OPTIMAI.JALUE
mcmi
t
TRANSACTIONIATE
14AlRKEtNA
BUYER-JO
TRANMACTIOMU
TRANWACTICN-PATE
MAKEERR E
eUYR QE51JD
8UwRREqLE5TjD
5ELLEREQUESTJD
WUERCOWIRMATION
SELLER CONFIRMATION
Figure 36: Table 'MarketToXToAttributeMap' and its Interaction with Other Tables
Finally, the CorrelationCoefficients table stores the mathematical coefficients used in
generating a mathematical approximation to the global utility function of the user.
11.2 Extensible Markup Language (XML) Usage
There are two data files written in XML within the system: <marketname>Profiles.xml
and <marketname>Questions.xml.
<marketname>Profiles.xml has all user profiles relevant to the specific market under
consideration. This file may be easily extended or modified by the administrator, as it is
conveniently placed outside the code base of the system. The general structure of the file
is the very simple:
<prof ile>
<profileName>...</profileName>
<profileType>...</profileType>
<profileAttributes>
132
<attribute> ... </attribute>
</profileAttributes>
</profile>
<marketname>Questions.xml keeps track of all the questions that are specific to the
specific market under consideration, and which cannot be asked by the generic marketindependent code. For instance, asking the user about source and target languages are
questions specific to the language translation marketplace, and are hence encoded within
the TranslationQuestions.xml file. The structure is:
<question>
<questionValue>
... </questionValue>
<attributeName>
... </attributeName>
<answerType>
... </answerType>
<answerCategory> ... </answerCategory>
</question>
11.3 Major Database Tables and ConstituentFields
Now, we iteratively discuss the structure of each major data table in the system, giving a
brief overview of the functionality embodied within each:
11.3.1 TABLE Players
Overview:
User data abstraction. Represents basic information about the user. The main key is
PLAYER_ID, which can also be used to access data in other user-related tables.
Field
Explanation
PLAYERID
PRIMARY KEY
FIRSTNAME
User's first name
LASTNAME
User's last name
EMAIL
User's email
LOGINNAME
User's login name
LOGINPASSWORD
User's password
ONLINESTATUSP
1 if user is currently logged in; 0 otherwise
ISADMINISTRATOR
1 if user has administrator privileges; 0 otherwise
133
REGISTRATIONDATE
Date when the account was registered
11.3.2 TABLE Markets
Overview:
Market data abstraction. A list of markets in the system. The main field is
MARKETNAME, which distinguishes markets in other tables.
Explanation
Field
MARKETID
PRIMARY KEY, not user
MARKETNAME
Market name. Used to uniquely identify the market in other tables; the
de-facto PRIMARY KEY
MARKETDESC
Description of the market
11.3.3 TABLE PlayerProfileMap
Overview:
Maps users to profiles. There is no primary key, but the system usually requests all the
profiles for the current user (making PLAYERID the de-facto primary key).
Explanation
Field
PROFILEID
Unique identifier of the profile
PLAYERID
User unique identifier (derived from the Players Table)
11.3.4 TABLE MarketToXToAttributeMap
Overview:
The MarketToXToAttributeMap table serves as mapping mechanism to link data profiles,
requests (equivalent to buying or selling agents), and transactions (derived from the
MarketPlayerRequests, MarketProfiles, and PendingTransactions tables respectively) to
attributes (stored in the Attributes table). This approach simplifies table creation
significantly. Given an id (XID), and a type of record it represents (XTYPE), the
MarketToXToAttributeMap table yields a list of all attributes associated with this record.
X_ID serves as the de-facto primary key.
134
Explanation
Field
MARKETNAME
Market name
X_ID
De-facto PRIMARY KEY
X_TYPE
Selector, determines what XID represents: 0 - request,
1 - profile 2
- transaction
ATTRIBUTE_ID
Attribute unique identifier
11.3.5 TABLE ClosedTransactions
Overview:
Keeps record of all committed or closed transactions (i.e. transactions that matched
buyer-seller pairs have agreed to consummate) in the system. Exact values of all
attributes assigned during the transaction can be obtained using TRANSACTIONID in
TransactionAttributes table.
Explanation
Field
TRANSACTION_ID
PRIMARY KEY representing the transactions
TRANSACTIONDATE
Time at which transaction was committed
MARKETNAME
Market name, where transaction took place
BUYERREQUESTID
Unique identifier for the buyer's request. Used to obtain more detail
in MarketPlayerRequests table
SELLERREQUESTlID
Unique identifier for the seller's request. Used to obtain more detail
in MarketPlayerRequests table
11.3.6 TABLE PendingTransactions
Overview:
Keeps record of all pending transactions is the system (i.e. the case when the system has
matched a buyer and seller, but at least one of them has not yet confirmed the deal).
Exact values of all attributes assigned during the transaction can be obtained using
TRANSACTIONID in TransactionAttributes table.
Field
Explanation
TRANSACTION_ID
PRIMARY KEY representing the transactions
TRANSACTIONDATE
Time at which system matched the buyer and seller request
MARKETNAME
Market name, where transaction took place
135
BUYERREQUESTID
Unique identifier for the buyer's request. Used to obtain more detail
in MarketPlayerRequests table
SELLERREQUESTID
Unique identifier for the seller's request. Used to obtain more detail
in MarketPlayerRequests table
BUYERCONFIRMATION
Indicates whether the buyer confirmed the deal:
1 if yes, 0 if no
SELLERCONFIRMATION
Indicates whether the seller confirmed the deal:
1 if yes, 0 if no
11.3.7 TABLE TransactionAttributes
Overview:
Keeps a detailed record of all transactions, pending as well as confirmed. Given a
TRANSACTION_ID, gives the list of corresponding attributes and their values.
Explanation
Field
TRANSACTIONID
Unique identifier representing transaction
ATTRIBUTENAME
Attribute name
ATTRIBUTEVALUE
Value of the attribute given in ATTRIBUTENAME
11.3.8 TABLE Attributes
Overview:
Data abstraction representing Attributes or features. Attributes are basic elements of
requests, profiles and transactions. An Attribute has an optimal value (specified by the
buyer or seller in the ideal offer), a mathematical functional approximation represented
by coefficients (A0,A1,A2), and a general form (derived from the utility function
associated with the attribute by the buyer or seller)
Explanation
Field
ATTRIBUTEID
PRIMARY KEY
ATTRIBUTETYPE
Type of the attribute: 0 if personal (i.e. owned by an agent, such as
the agent's own reputation);
1 if desired (i.e. pertaining to the
desired transaction partner)
ATTRIBUTENAME
Attribute name
UTILITYFUNCTION
Number representing the utility function corresponding to the
Attribute
AO
Constant coefficient in mathematical equation corresponding to
136
utility function
Al
Coefficient before the first power
A2
Coefficient before the second power
COEFFVALUE
Coefficient obtained through least-squares first order approximation
to represent a variable in the global utility function for the user (in
requests).
PERMISSIBLERANGEUPPER_
Upper end of the flexible attribute's permissible range, as defined
BOUND
by the user
PERMISSIBLERANGELOWER
Lower end of the flexible attribute's permissible range, as defined
-BOUND
by the user
POSSIBLERANGEUPPERBO
Upper end of the flexible attribute's possible range, as defined by
UND
the system
POSSIBLERANGELOWERB
Lower end of the flexible attribute's possible range, as defined by
OUND
the system
OPTIMALVALUE
Optimal value of the attribute (from the ideal offer), as specified by
the user
11.3.9 TABLE CorrelationCoefficients
Overview:
Used in least squares approximation to represent correlation coefficients between
variables. This table facilitates a second-degree least-squares approximation. First-degree
coefficients are stored in the COEFFVALUE field of the attributes themselves.
Field
Explanation
1
ATTRIBUTEID_1
Unique identifier representing attribute
ATTRIBUTEID_2
Unique identifier representing attribute 2
COEFFVALUE
Corresponding correlation coefficient for second order least squares
11.3.10 TABLE MarketPlayerRequests
Overview:
Data abstraction representing all types of requests (a 'request' is equivalent to a buyer or
seller agent): active (not expired, not yet matched), expired (matched but not yet
confirmed) (see PendingTransactions table); and finalized (matched and confirmed) (see
ClosedTransactions table).
137
Explanation
Field
REQUESTID
PRIMARY KEY, identifies a request to other tables
PLAYERID
Unique identifier of the user that initiated this request
MARKETNAME
Market name, where the request takes place
REQUESTSTARTDATE
Time at which request was initiated
REQUESTENDDATE
Time at which request expires
BUYSELLP
Indicates whether this request represents a buyer (0) or a seller (1)
ISEXPIRABLE
If 0, this request is not expirable (overrides
REQUESTENDDATE); otherwise, 1
Used to differentiate new requests (0), from old (1), internal state
NEWOLDP
11.3.11 TABLE MarketProfiles
Overview:
List of profiles in the market identified by the MARKETNAME field.
Explanation
Field
PROFILE_ID
PRIMARY KEY, identifies a profile in other tables
MARKETNAME
Market name, where this profile is registered
PROFILENAME
Name of the profile
BUYSELLP
Indicates whether this profile represents a buyer (0) or a seller (1)
11.3.12 TABLE MarketQuestions
Overview:
A list of irregular questions in the market, MARKETNAME, that cannot be stated in a
generic market-independent way. For instance, asking users about source and target
languages in a language translation marketplace are examples of irregular questions
specific to the language translation marketplace.
Explanation
Field
MARKETNAME
Market name, in which the question is relevant
ATTRIBUTENAMIE
Name of the attribute, for which the question is asked
QUESTIONVALUE
The question itself
ANSWERTYPE
Format of the answer (list, number, text, etc.)
138
11.3.13 TABLE MarketAnswers
Overview:
A list of possible answers to the questions in the table MarketQuestions.
Field
Explanation
MARKETNAME
Market name, in which the answer is relevant
ATTRIBUTENAME
Name of the attribute, for which the answer is relevant
ANSWERVALUE
Possible value of the answer
ANSWER__ID
Integer that uniquely identifies the answer
11.4 Schematic Depiction of Database Components and Their
Interrelationships
Having discussed, in detail, the structure and functionality of each major table within the
system, we now present the MARI user interaction schema from an internal data-flow
perspective. Figure 37 presents a schematic depiction of database components,
illustrating the interrelationships between these components, and highlighting the flow of
data within back-end tables. The numerical steps labeled in Figure 37 are discussed in
detail below the figure.
139
9* PLAYERJD
FIRSTAPE
-
PROFILEJ
F2
LAST-NAME
EMAIL
LOIN-W
1MARKETAME
oses a
LOEINPASSWORD
User
OMNLESTATUS..P
mrefrMARIT-ACM1
which to begi
a trassactiox
REGISTRATIONDATE
MAR
PROFILENAME
User selects a
T
euY5ELL
DATE OPFXRTH
The proffe's set of
WAZ
A new p hyer- '53
4
pro ile pair is
associated attributes is
recorded
created
.9
_ATRIUTE
MARKET NAME
PROFILE ID
PLAYER ID
ATTRIBUTEJID
ATTRIBUTE! 7YPE
NME
_JDTFYbA
ZJI
ATTRIBUTEID
2,
COEFF
VALUE
PER1WI55LEPAGE.UPPER.1OLN
FERMISSIBLE.PANGE-LOWERJOULU
0S RAN5ELFPERJOUND
.....
PO.55ELANGELOWER-BOMND
OPTIMAL-VALLIE
SMARKET-NAME
ATTRIBUTE.NAME
QUESTION-VALUE
ANSWERTYPE
~4t.
UTILITYFUNCTION
DESCRIPTION
MARI
deterineswhat
questions to ask
user to extract
~
PAYERJD
his utilty
fnctin
MARKETNAME
REQUESTjTAAATE
-
REQE5TSEVDATE
ATTRAIEID,
COEFPYALUE
Userp reftrences are
written to appropriate
tables and the relatin nship
is recoriled
tNELLP
ISJXPIRABLE
-
MATCHING
TO TRANSACTIONID
TRANSACTIONJD
TRANSACTIONpATE
-TRANSACTIONJDATE
Transacions*
MARKET_-ANE
User
MARKEIJAME
suggested by
&WERD
Confirmation
MARI but not
SELLERD
SUMRREQUESTjD
SELLERREQUEST_1D
yet confrmed
b y users
WLNER_-REQUESTID
SELLER.REQLEST_ D
JUYERCONWIRMA1ON
SELLER CONFIRMATION
8
Fbnal trasaction
ttrd ue vaue
recorded
TRANSACTIONJID
A TTRIBUTEJYAME
A TTRIBUTE.VALUJE
Figure 37: Interaction Schema between Major MARI Database Components
140
Step 1: The user chooses a market in which to begin a transaction.
The Players table serves as the main repository of user information: biographical data,
MARI access privileges, online status etc.
The Market table contains market specific information such as 'Market Maker'
information and any special characteristics.
Step 2: The user chooses a profile that most closely represents his preferences.
A Profile is a pre-specified set of user preferences.
Step 3: A new player-profile pair (a user to profile mapping) is added to the database.
Since the user-profile map is many-to-many, the PlayerProfileMap table is used to
represent this.
Step 4: Each profile has a set of associated attributes and this mapping is recorded in the
MarketToA ToAttributes table.
Step 5: MARI automatically determines what questions the user ought to be asked so as
to extract his general utility function.
A 'Request' (equivalent to an 'agent'), is represented internally as a modified profile,
bound by the MarketToXToAttributeMap table to specific attribute preferences. Requests
have various expiration properties, normally expiring after a transaction is completed.
Step 6: The user preferences or utility function approximation along each attribute
dimension is written to the appropriate tables, and the relationship is recorded in the
MarketToXToAttributeMap table.
The "Attributes" of a request include the user's utility functions along each attribute
dimension.
The CorrelationCoefficientstable is used to store second order coefficients for general
utility function approximation.
141
Step 7: Once the Matching algorithm is run, transaction suggested by MARI, but not yet
confirmed by the matched parties, are stored in the PendingTransactionstable.
Step 8: The attribute values corresponding to the final "deal" configuration between each
matched buyer seller pair are written out to the TransactionAttributestable.
Step 9: Upon user confirmation by the matched parties, transactions are treated as
'closed' and stored in the ClosedTransactionstable.
142
12 APPENDIX B: IMPLEMENTATION BACK END
COMPONENTS
12.1 Introduction
In the creation of both the back end and the front-end specific programming and user
experience goals were kept in mind. After exhaustively diagramming what user interface
components were needed, programming goals were added to realize the desired
functionality. Figure 38 schematically illustrates the various back-end components (ASP
files) in the MARI system and the inter-relationships between them. Subsequently, we
discuss each back-end file's functionality from a programming perspective as well as the
user experience perspective.
143
login.asp
welcome.asp
abOutAASP
faq.asp
selectmarket.
asp
contactinfo.asp
logout.asp
specificmarket.asp
process -req
uest.asp
create-
specific-
agent.asp
market.asp
choose-
market-
market-
history.asp
watcha sp,
welcome.asp
prof ile.asp
startrequest.asp
2
1
marketparameters.a
sp
3
4
placere q ue st.a s pm
a h ng
b.asp
Flow
Figure 38: Flowchart Illustrating Major Back End Components and Programmatic Control
144
12.2 Back-End Components
12.2.1 Login.asp
a) User Experience
The user is prompted for a Username and Password. The red background and yellow
highlighted link scheme is repeated throughout the web page.
The user is given the
option to create an account in the top-most link.
b) Programming
Behind the scenes, a simple SQL query searches to see if the Username-Password pair is
correctly matched.
If so, the user is redirected to the welcome.asp page with the
username data in the URL.
12.2.2 Welcome.asp
a) User Experience
The welcome page greets the user with his or her username and personal details. The
user has the option to modify data by clicking the "Change your info" button as well as
the option to go to a specific marketplace (such as the language translation market) where
further modifications of the buying agents and selling agents can occur.
b) Programming
Input:
9
playerid, an alphanumeric string or nonce that uniquely identifies the user
Output:
" playerid
* market, the specific market (such as translation market) the user is accessing
Effects:
* List all of the user's information such as the username, first and last name, and
email address with an option button allowing the user to change the
information. The file queries the Players table based on the input of 'playerid'
in the database to get this general user information.
145
* The outputs above are attached to the URL string if faq.asp, about.asp,
contact-info.asp, logout.asp, or selectmarket.asp are selected. If the user goes
to a specific market (such as 'language translation market'), both the playerid
and the market are outputted.
12.2.3 Specific-market.asp
a) User Experience
This page presents new menu options to the user as well as a broad overview of the
current outstanding requests. The user can create buying and selling agents, as well as
view the current 'market status'.
b) Programming
Input:
e
playerid
Output:
" playerid
" market, the specific market the user is accessing
Effects:
* This file displays outstanding Active, Matched, and Expired requests by
querying the MarketPlayerRequests table with the playerid.
12.2.4 Create-agent.asp
a) User Experience
This page gives the user the option to create a buying or selling agent.
b) Programming
Input:
* playerid
Output:
9
playerid
146
"
isBuy, a Boolean which indicates whether the agent being created is a buyer
agent or a seller agent
" market
Effects:
* This file allows the user to select whether to create a buying agent or a selling
agent and, in both cases, the browser redirects the user to choose-profile.asp.
12.2.5 Choose-profile.asp
a) User Experience
This page gives the user the option to choose a pre-defined buyer or seller profile.
b) Programming
Input:
" playerid
*
market
" isBuy
Output:
" playerid
" market
" MenuSelectProfile, the profile selected by the user
" isExpire, a Boolean that indicates whether the agent being created can 'expire'
after some time. Only Administrators may create non-expirable agents
" visit, a variable that keeps track of the number of user visits for internal state
maintenance
Effects:
* The page gives the user the option to choose a pre-defined profile
("stereotype") for the agent he is trying to create. From this page, onwards, the
user must sequentially navigate through the files: choose-profile.asp, startrequest.asp, market-parameters.asp,
and place-request.asp,
whether a buying or selling agent is being created.
regardless of
147
"
The type of profile can be chosen in a menu that accesses the MarketProfiles
table for a complete list of available profiles, and queries the PlayerProfiles
table for the current profile of the user (taken to be the profile the user used,
the last time he created an agent).
* The page redirects the users with the output variables above to startrequest.asp.
12.2.6 Start-request.asp
a) User Experience
This page asks the user any "special" questions that are specific to the market in which
the user is attempting to create an agent. For instance, in the language translation market,
asking the user about the source and target languages are seen as special questions.
b) Programming
Input:
" playerid
" market
" isBuy
" visit
Output:
" playerid
" market
" requested, a unique ID assigned to the create-agent request currently being
processed
* outerror, any errors generated from previous visits to this file
" special, the attribute ID where errors, if any, are generated
" visit
Effects:
* The page updates the profiles of the user in the PlayerProfileMap table (maps
users to profiles) and MarketProfiles table (maps profiles to a specific
market).
148
"
The page registers the request in the MarketPlayersRequest table (maps
players
to
agents they
MarketToXToAttributeMap
have
created).
The
page
table with XTYPE=O
then writes
to
(maps profiles to
attributes)
" Lastly the page asks the user questions from the MarketQuestions table giving
the user a range of possible answers to select from, from the MarketAnswers
table
12.2.7 Market-parameters.asp
The market-parameters.asp file is visited multiple times. Each 'visit' (tracked by an
internal state variable called 'visit') in the looping file is documented below.
12.2.8 Visit 0:
a) User Experience
This page allows the user to choose optimal values for relevant attributes, and to specify
the ideal "offer".
b) Programming
Input:
* playerid
" visit
" market
* sellProfile, the seller profile chosen by the user, if any
* buyProfile, the buyer profile chosen by the user, if any
0
isBuy
Output:
" playerid
" market
" requestID, unique ID assigned to the request (agent)
Effects:
149
* Show a user their parameters based on the profile file and the entries
corresponding to this profile in the Attribute table. Ask the user for the
optimal values for these parameters (offer configuration) and corresponding
bid or ask. Ask for ranges for flexible attributes.
12.2.9 Visit 1:
a) User Experience
The user is shown his selected offer configuration and corresponding bid or ask. The
system then asks the user a series of questions. The user is asked to associate a bid or ask
value with "bundles" of attributes such that, in each bundle, a particular flexible attribute
is held at the lowest or highest endpoint of its permissible range, while all other attributes
are held constant at their optimal values. This is only done for quadratic (i.e. non-linear)
attributes, where the extra data-points are needed to come up with a functional
approximation to the utility function.
b) Programming
Input:
0
Same as Visit 0
Output:
0
Same as Visit 0
Effects:
" Show chosen optimal values of attributes and the corresponding price.
" Get the price (bid or ask) from the user where a flexible attribute is held at the
lower endpoint of its range and the remaining attributes are held at their
optimum values; do so for each flexible attribute which has an associated
Utility Function UF belonging to the set {2,3,4,5,6,16,17}
" Get the price (bid or ask) from the user where a flexible attribute is held at the
higher endpoint of its range and the remaining attributes are held at their
optimum values; do so for each flexible attribute which has an associated
Utility Function UF belonging to the set {l,2,3,5,6,13,14}.
150
12.2.10 Visit 2:
a) Programming
Input:
*
Same as Visit 0
Output:
0
Same as Visit 0
Effects:
*
Calculate AO, Al, and A2 coefficients, corresponding to a mathematical
approximation of a quadratic utility function of the form AO+(A1)x+(A2)x^2.
An equation is generated for the utility function corresponding to each flexible
attribute.
12.2.11 Visit 3:
a) Programming
Input:
0
Same as Visit 0
Output.
0
Same as Visit 0
Effects:
* Report all errors that may have occurred if the user enters incorrect or
inconsistent data.
12.2.12 Market-watch.asp
a) User Experience
This page shows the user an overview of the complete marketplace: the number of users
logged in and the number of active agents, differentiating between buying agents and
selling agents.
151
b) Programming
Input:
" playerid
"
market
Output: none
Effects:
* The page displays general MARI system information by querying the
MarketPlayerRequest table.
12.2.13 Market-history.asp
a) User Experience
This page shows the history of closed transactions.
b) Programming
Input:
" playerid
"
market
Output: none
Effects:
* The page queries the ClosedTransactions Table. If any "closed transactions"
exist, these are listed. A distinction is made between those transactions which
were consummated (i.e. the buyer and seller proceeded to complete the
transaction after being matched by the system) and those which were not.
12.2.14 Process-request.asp
a) User Experience
This page shows the user the attributes of a request (agent) selected from a specific
market. In the case of an active (unmatched) agent, the user can review the agent,
viewing all attributes, and can choose to delete the agent if desired. In the case of a
152
matched agent, the user can 'confirm' the match or can delete the agent, indicating that
the matching proposed by the system was not found to be suitable.
b) Programming
Input:
" playerid
*
requestid, uniquely identifies the request or agent
"
whattodo, an internal variable used to keep track of the user's intentions
(delete an agent, confirm a matching etc.)
"
visit
Output: playerid
Effects:
" The page queries the MarketPlayerRequests, Attributes, PendingTransactions,
and TransactionAttributes tables to output all the information about the agent.
The MarketToXToAttributeMap table serves as mapping vector to link data
profiles, requests, or transactions to the other tables mentioned above.
"
If the user wants to delete the agent the MarketToXToAttributeMap,
MarketPlayerRequests, and PendingTransactions tables are updated by
deleting the agent's id from the tables.
*
If the user wants to confirm a matching, the state of the matching in the
PendingTransactions table is updated to reflect this. If both the buyer and
seller involved in a given matching have confirmed, then the transaction is
transferred to the ClosedTransactions table.
* Redirects to specific-market.asp upon completion.
12.2.15 Matching.asp
Input:
* marketname, an identifier for the market for which matching script is invoked
Effects:
153
* This is the script that matches buyers and sellers in a specific market. It has
two modes of execution: continuous and clocked. In continuous mode,
matching is run as soon as a user completes creating his agent. In clock mode,
a server-side executable is scheduled to invoke the matching script at set time
periods, or the system executes the matching when certain (configurable) predetermined conditions are satisfied by the market (this allows the
MarketMaker to say, for instance, that the matching should only be invoked
when there are at least n buyer or m sellers, etc.).
The matching script has four main stages of execution:
1. Market state loading;
2. Pair-wise buyer-seller optimization to search for a myopically optimal "deal";
3. Global buyer-seller matching;
4. User notification.
In the first stage, the existing bid requests and user information in the database is
projected onto the specific market, and loaded from database tables into data structures
that reside in memory. This operation effectively caches the information to be used by the
matching algorithms and speeds up the operation of the script by greatly reducing
database access operations.
Pair-wise buyer-seller optimization seeks to find a myopically optimal "deal"
configuration for every possible buyer-seller pair. The existing optimality conditions
minimize the distance (in the usual Euclidean sense, treating deal attributes as vector
components) of the proposed deal from the deals considered optimal by the users (offer
configurations), while keeping the profit (defined as bid-ask spread or surplus) as large as
possible. The results - potential buyer-seller matches and corresponding deals - are
stored in another set of data structures.
Next, global matching takes place. The algorithm borrows from Gray code
techniques, and implements an iterative depth-first search on deal attributes. The
algorithm maximizes the overall (in the additive sense) profit from all the matches.
154
Finally, the users involved in the globally optimal matching are sent email notification
with details of the proposed deal.
Final potential
deals
to are
written to
the
PendingTransactions
and
TransactionAttributes tables. Buyer and seller agents (requests) involved in these deals
are expired in the MarketPlayerRequests table.
12.2.16 Logout.asp
a) User Experience
This page logs the user out.
b) Programming
Input:
* playerid
Output: none
Effects:
* The page updates the ONLINESTATUSP field in the Players table for the
playerid given to 0, indicating that the user is no longer logged into the
system.
12.2.17 Faq.asp
a) User Experience
This page archives answers to frequently asked questions posed by users.
b) Programming
Input: none
Output: none
Effects:
* None. Displays static output
155
12.2.18 About.asp
a) User Experience
This static page tells the user information about the MARI project, and about specific
marketplaces which have been instantiated using the system.
b) Programming
Input: none
Output: none
Effects:
9 None. Displays static output.
12.2.19 Contact-info.asp
a) User Experience
This static page tells the user information about whom to contact with questions about the
marketplace, and about support-related issues.
b) Programming
Input: none
Output: none
Effects:
* None. Displays static output.
156
13 APPENDIX C: SUGGESTIONS FOR
FURTHER READING ABOUT MARI
The MARI project has resulted in a number of publications that have appeared, or will
soon appear, in refereed conferences, journals and books. Of the publications listed
below, special attention is drawn to "PersonalizedLocation-basedBrokering Using an
Agent-Based Intermediary Architecture, " which illustrates how the MARI system can
readily be instantiated in a domain other than our prototype language translation
marketplace. Specifically, the paper provides an in-depth discussion of personalized
location-based restaurant brokering using the MARI system. Special attention is also
drawn to "A Visual Preference-Modelingand Decision-Support Technique for Buyers of
Multi- Attribute Products," in which we acknowledge the compelling need for radically
different interfaces for electronic markets, and briefly discuss the theoretical foundations
of a novel proposal for the visualization and conceptualization of multi-attribute product
spaces.
G. Tewari and P. Maes. "Beyond Passive Bids andAsks: Mutual Buyer andSeller
DiscriminationThrough IntegrativeNegotiation in Agent BasedElectronicMarkets."
'Knowledge Based Electronic Markets' Workshop, Proceedings of the Seventeenth
National Conference on Artificial Intelligence (AAAI 2000), Austin, Texas, USA, July 30August 3, 2000.
G. Tewari, J. Youll and P. Maes. "PersonalizedLocation-basedBrokering Using an Agent-
BasedIntermediaryArchitecture." Proceedings of the Third International Conference on
Electronic Commerce (ICEC 2000), Seoul, Korea, August 21-24, 2000. [To be republished
in the Journalfor DecisionSupport Systems (DSS), Summer 2001].
G. Tewari and P. Maes. "Design and Implementation of an Agent-Based Intermediary
InfrastructureforElectronicMarkets." Proceedings of ACM Conference on Electronic
Commerce (EC 00), Minneapolis, MN, USA, 17-20 October 2000.
G. Tewari and P. Maes. "A GeneralizedPlatformfor the Specification, Valuation, and
Brokering ofHeterogeneousResources in Electronic Markets." Included as a chapter in the
book "Advances in E-commerce Agents: Brokering, Negotiation, Security, and Mobility."
Forthcoming, Springer-Verlag LNAI Series.
G. Tewari, P. Maes, and D. Ariely. "A Visual Preference-Modelingand Decision-Support
Techniquefor Buyers ofMulti- Attribute Products." Proceedings of the Conference on
157
Human Factors and Computing Systems (CHI 2001), Seattle, Washington USA, March 31
-April 5, 2001.
G. Tewari, A. Berkovich, V. Gabovich, S. Liang, A. Ramakrishnan and P. Maes.
"SustainingIndividualIncentives while Maximizing Aggregate Social Welfare: A Mediated
Brokering Techniquefor TradingAgents in Next-GenerationElectronicMarkets." 'Agents
for E-Business on the Internet' Session, Proceedings of the Second International
Conference on Internet Computing (IC 2001), Las Vegas, NV, USA, June 25 - 28, 2001.
G. Tewari, B. Rhodes and P. Maes. "Location-BasedAd-Hoc CoalitionFormation and
CollaborativeFilteringUsing an Agent-Based IntermediaryArchitecturefor Trading
Intangible Goods andServices." Proceedings of the Thirty-Fifth Hawaii International
Conference on System Sciences (HICSS-35), Big Island, Hawaii, January 7-10, 2002.
G. Tewari, P. Maes, A. Berkovich and V. Gabovich. "Modeling Complex User Preferences
so as to FacilitateMore Automated andAccurate TransactionBrokering within
HeterogeneousMulti-Agent ElectronicMarkets." Proceedings of the Second Asia-Pacific
Conference on Intelligent Agent Technology (IAT-2001), Maebashi City, Japan, October
23-26, 2001.
158
14 BIBLIOGRAPHY
14.1 Works Referenced
1
Altavista online translation system URL: <http://world.altavista.com/>
2 Amazon Auctions URL: <http://www.amazon.com/auctions/>
3
Bargainfinder: <http://bf.cstar.ac.com/bf>
4 C. Boutilier, Y. Shoham, and M. Wellman. "Economic Principles of Multi-Agent
Systems" (editorial). Artificial Intelligence, 94, p. 1-6. 1997.
5
C. Gerber, C. Russ, and G. Vierke. "On the suitability of market-based allocation
mechanisms for telematics applications." Proceedingsof the Third International
Conference on Autonomous Agents (Agents '99), p. 4 0 8 - 4 0 9 . ACM Press, New York,
NY. 1999.
6
Chemdex URL: <http://www.chemdex.com/>
7
D. Friedman. "The Double Auction Market Institution: A Survey." Proceedings of The
WorSkshop on DoubleAuction Markets, Santa Fe, New Mexico. June 1991.
8
D. Fudenberg and J. Tirole. Game Theory. MIT Press, Cambridge, MA. 1995.
9
D. Wang. "Market Maker: An Agent-Mediated Marketplace Infrastructure." Master of
Engineering Thesis, Department of Electrical Engineering and Computer Science, MIT,
Cambridge, MA. June 1999.
10 Ebay URL: <http://www.ebay.com/>
11 Elance URL: <http://www.elance.com/>
12 Frictionless ValueShopper URL: <http://compare.frictionless.com/>
13 G. Bitran and S. Mondshein. "Periodic Pricing of Seasonal Products in Retailing."
Management Science, 45(8), p.64-79. January 1997.
14 G. Gallego and G. Ryzin. "Optimal Dynamic Pricing of Inventories with Stochastic
Demand over Finite Horizons." ManagementScience, 40(8), p. 99 9 - 10 2 0 . August 1994.
15 H. Varian. IntermediateMicroeconomics. W. W. Norton & Company, New York.
1999.
16 J. Morris and P. Maes. "Negotiating Beyond the Bid Price." Workshop Proceedingsof
the Conference on Human Factorsin Computing Systems (CHI 2000), The Hague, The
Netherlands. April 1-6, 2000.
17 Jango URL: <http://www.jango.com/>
159
18 K. Raman and R. Chatterjee. "Optimal Monopolistic Pricing under Demand
Uncertainty in Dynamic Markets." Management Science, 41(1), p. 14 4 - 162 . January
1995.
19 Kasbah URL: <http://ecommerce.media.mit.edu/Kasbah/>
20 L. Trefethen and D. Bau. NumericalLinearAlgebra. Society for Industrial and Applied
Mathematics, Philadelphia, PA. 1997.
21 Lost Wax URL: <http://www.lostwax.com/>
22 M. Tsvetovatyy and M. Gini. "Toward a virtual marketplace: Architectures and
Strategies." Proceedings of the First International Conference on the Practical
Application of Intelligent Agents and Multi-Agent Technology, p.597-614, Lancashire,
U.K. 1996.
23 M. Tsvetovatyy, M. Gini, B. Mobasher, Z. Wieckowski. "Magma: An agent-based
50 1
virtual market for electronic commerce." Applied ArtificialIntelligence, 6, p. -523.
1997.
24 M. Wellman and P. Wurman. "Market-aware agents for a multi-agent world." Robotics
andAutonomous Systems, 24, p. 1 15-125. 1998.
25 M. Wellman. "A Market-Oriented Programming Environment and its Application to
Distributed Multi-commodity Flow Problems." Journalof ArtificialIntelligence
Research, 1, p.1-23. 1993.
26 Moai URL: <http://www.moai.com/>
27 MySimon Buyers Guide URL:
<http://www.mysimon.com/consumerresources/BuyersGuides/index.anml/>
28 0. Regev and N. Nisan. "The Popcorn Market - An Online Market for Computational
Resources." Proceedingsof the FirstInternationalConference on Information and
Computation Economies, p. 1 4 8 - 1 5 7 . 1998.
29 0. Regev. "Economic Issues in CPU Sharing System for the Internet." Masters Thesis,
The Institute of Computer Science, The Hebrew University, Jerusalem. 1998.
30 0. Shehory and S. Kraus. "Methods for task allocation via agent coalition formation."
ArtficialIntelligence, 15(3), p.2 18-251. 1998.
31 P. Maes, R. Guttman, and A. Moukas, "Agents That Buy and Sell." Communicationsof
the ACM, 42(3). March 1999.
32 P. Wurman, M. Wellman, and W. Walsh. "The Michigan Internet AuctionBot: A
Configurable Auction Server for Human and Software Agents." Proceedingsof the
Second InternationalConference on Autonomous Agents (Agents-98), Minneapolis,
MN, USA. May 1998.
33 Pattie Maes' statement URL:
160
<http://pattie.www.media.mit.edu/people/pattie/statement.html>
34 Personalogic URL: <http://www.personfalogic.com>
35 Priceline URL: <http://www.priceline.com>
36 R. Ahuja, T. Magnanti, and J. Orlin. Network Flows: Theory, Applications and
Algorithms. Prentice-Hall, New Jersey. 1993.
37 R. Guttman "Merchant Differentiation through Integrative Negotiation in Agentmediated Electronic Commerce." Masters Thesis, MIT Media Laboratory, Cambridge,
MA. September 1998.
38 R. Pindyck and D. Rubinfeld. Microeconomics. Prentice-Hall, New Jersey. 1997.
39 R. Smith and R. Davis. "Negotiation as a metaphor for distributed problem solving."
Artificial Intelligence, 20, p. 6 3 - 1 0 9 . 1983.
40 S. Kraus. Strategic Negotiation in Multi-agent Environments. MIT Press, Cambridge,
MA. 2001.
41 S. Osborn. "The role of agents in business to business (B2B) electronic commerce."
Agentlink News, 6, p. 6 - 8 . January 2001.
42 T. Sandholm "Agents in Electronic Commerce: Component Technologies for
Automated Negotiation and Coalition Formation." Autonomous Agents and MultiAgent Systems, 3, p. 7 3 - 9 6 . 2000.
43 T. Sandholm and F. Ygge. "On the Gains and Losses of Speculation in Equilibrium
Markets." Proceedingsof the Sixteenth InternationalJoint Conference on Artificial
Intelligence, p.632-638, Nagoya, Japan. 1997.
44 T. Sandholm and V. Lesser. "Coalition formation among bounded rational agents."
ProceedingsofIJCAI-95, p. 6 62 -66 9 . Morgan Kaufman, San Francisco, CA. 1995.
45 T. Sandholm, S. Sikka, and S. Norden. "Algorithms for optimizing leveled commitment
contracts." ProceedingsofIJCAI-99, p. 53 5 -5 4 0 . Morgan Kaufman, San Francisco, CA.
1999.
46 T. Sandholm. "An implementation of the contract net protocol based on marginal cost
calculations." ProceedingsofAAAI-93, p.256-262. The AAAI Press, Menlo Park, CA.
1993.
47 TradingDynamics URL: <http://www.tradingdynamics.com>
48 W. Nicholson. Microeconomic Theory. The Dryden Press, Fort Worth, TX. 1998.
49 W. Vickrey "Counterspeculation, Auctions, and Competitive Sealed Tenders." Journal
ofFinance, 16, p.8-37. March 1961
50 W. Walsh, M. Wellman, P. Wurman, J. MacKie-Mason. "Some Economics of Market-
161
Based Distributed Scheduling." Proceedingsof the Eighteenth International
Conference on DistributedComputing Systems, p.6 1 2 - 6 2 1 . 1998.
14.2 Works Consulted
51 C. Coello and A. Coello. "A Comprehensive Survey of Evolutionary-Based
Multiobjective Optimization Techniques." Laboratorio Nacional de Informatica
Avanzada Rebsamen, Xalaca, Veracruz, Mexico.
52 Charles River Associates Incorporated and Market Design, Inc. "Report IA: Auction
Design Enhancements for Non-Combinatorial Auctions." Submitted to Federal
Communications Commission. September 1997.
53 D. Come and J. Knowles. "The Pareto Archived Evolution Strategy: A New Baseline
Algorithm for Pareto Multi-objective Optimization." Department of Computer Science,
University of Reading, U.K.
54 F. Ygge and H. Akkermans. "Resource-Oriented Multicommodity Market
Algorithms". Autonomous Agents andMulti-Agent Systems, 3, p.53-71. 2000.
55 J. Teich, H. Wallenius and J. Wallenius. "Multiple-Issue Auction and Market
Algorithms for the World Wide Web." DecisionSupport Systems 26, p. 4 9 -6 6 . 1999.
56 L. Ausubel. "System and Method for an Efficient Dynamic Auction for Multiple
Objects." United States Patent 6,026,383. February 15, 2000.
57 P. Bossaerts, L. Fine, and J. Ledyard. "Introducing Liquidity In Thin Financial Markets
Through Combined-Value Trading Mechanisms." Draft Paper, Department of
Economics, California Institute of Technology, Pasadena, CA.. March 2000.
58 P. Milgrom and J. Roberts. "Comparing Equilibria." Research Paper 1229, Department
of Economics and Graduate School of Business, Stanford University. November 19,
1992.
59 T. Mullen and M. Wellman. "The Auction Manager: Market Middleware for LargeScale Electronic Commerce." Proceedingsof the Third USENIX Workshop on
ElectronicCommerce, Boston, MA, USA. September, 1998.
60 W. Walsh and M. Wellman. "A Market Protocol for Decentralized Task Allocation."
Proceedingsof the Third InternationalConference on Multi Agent Systems, p.325-332.
1998.