- In this paper we present an XML-based multi-agent system, called Multi Agent System for Traders (MAST), that completely supports Business-to-Customer E-commerce activities, including advertisements and payments. MAST helps both customers and merchants in their tasks with a homogeneous and personalized approach. In particular, E-payments in MAST are implemented under the availability of financial institutions. This avoids exchanging of sensible customers' information and reinforces the confidence between customers and merchants. A complete prototype of MAST has been implemented in the JADE framework, and it has been exploited for realizing some experiments, in order to evaluate its performances.
A great contribution to the Internet diffusion has been
provided by E-Commerce (EC) activities, i.e. all trading activities
carried out by means of Internet. In [
Nowadays, the B2C involves a large number of merchants
interested in offering products using a convenient media and
customers that desire to purchase those products. In this
context, customers and merchants can exploit different
opportunities as: (i) absence of time and space boundaries; (ii) simple,
fast and comfortable purchases; (iii) low costs and several
sale terms available. However, a significant customer-merchant
distrust still persists, mostly due to the absence of personal
contacts and to a low acceptance of the e-payment methods
for security reasons. To capture the different phases carried
out by enacting a B2C process, some behavioural models
can be exploited, and particularly, in this paper we adopt
the Consumer Buying Behavior (CBB) model [
This work presents a multi-agent framework to support B2C
activities of merchants and customers. Such a framework,
called Multi-Agent System for Traders (MAST), is composed
of a set of agents and a central agency. In particular, in MAST
each merchant and each customer is provided by a software
agent, managing a personal profile, able to support B2C
activities during all the CBB stages. The MAST framework
presents the following important features: (i) software agents
are XML-based to manage agent profiles and messages in a
light and easy manner and to realize agent communications in
ACML language [
The paper is organized as follows: the MAST framework is presented in the following section. In Sect. III the AIPP protocol is briefly illustrated and in Sect. IV the adopted functionalities for customer and merchant support are described. In Sect. V the MAST prototype and performances are discussed. Section VI deals with some Related Work and finally, in Sect. VII, some conclusions are drawn.
In the MAST framework, represented in Fig. 1, each customer C and merchant M is associated to her/his personal agent (resp., c and m) and with her/his financial institution (F I). All agents are logged into the MAST Agency (Ag). Both agents and agency support B2C activities managing (in terms of insertion, deletion and updating) their respective Knowledge profiles. In this section, agents and agency will be briefly described by illustrating their profiles and behaviours, while the B2C support activities in the CBB stage are exposed in Sect. IV.
In the following, U denotes the generic user (a customer or a merchant) and a represents her/his agent. Each MAST agent manages its Agent Knowledge (AK) profile, represented in Fig. 2 and described by the following elements:
U D (User Data), contains the user’s name (N ame) and address (Address), login identifier (AcL), password (AcP ), real (Ac) and single-use (AcT ) user’s account identifiers, all referred to the user’s account into F I . Note that Ac and AcT include also F I coordinates.
AD (Agent Data), containing the user’s agent (aI ) and Agency (AgI ) identifiers and a pruning threshold (T ) to delete uninteresting information from AK.
O (Ontology). In order to identify products of interest
for the users, in our framework as Ontology we adopt
the North America Industry Classification (NAICS) [
P D (Product Data) is a set of products, where each product is represented by an identifier (P I ) and described by the following elements: NAICS code (N ); model (M ); brand (B); price (P ); currency (C); commercial unit (U ); auction flag (A) that is set to 1 if the product has a fixed price otherwise it is set to 0; tax (X ); benefits set (BSet), eventually empty, of added values; delivery set (DSet), that collects the delivery identifiers (see DD section) related to the product.
DD (Delivery Data) is a set of elements, where each element, represented by an identifier (DI ), is described by the delivery time (DT ) and by the fixed (F ) and variable (V ) costs. Note that DD collects the data of the chosen delivery for a customer, while it collects the data of the delivery he/she makes available for a merchant. ADB (Agent Data Base) is a set of agent (and Agency) data where each element, represented by its identifier aI , is described by its Internet address (aA) and by the date of its update (aAU ).
U P (User Profile) is a set of data that an agent a obtains monitoring the CBB activities in the MAST environment; for a customer its c agent collects the data of the products which the customer is interested in; elsewhere, for a merchant its m agent collects the data of the CBB activities carried out in the site by the agents of the various customers for the products offered by the merchant. Each element of U P is represented by the identifier P I (the same of the P D section) and it is described by the following elements: visit counter (V C); first visit (F V ), one before the last visit (P V ) and last visit (LV ) dates; product rate (R); a set (P ASet), where each element is associated to an agent that has been interested in the product, and that is composed by an agent identifier (aI ), the highest CBB stage reached and eventually the delivery identifier (DI ) and the auction flag (A). More in detail, the rate R represents the interest of a customer for a specific product and it is updated (by a) when a CBB activity is monitored by a using the following formula:
R = P5=1[ ((6CV )2(1(+1P+VLV FPVV) )) ] where: 2 [1; ; 5] identifies one among the first five CBB stages; 2 f1; 1g describes the satisfaction of the customer about a product ( is usually set to 1, but it is set to 1 by the customer only if in the last and optional CBB stage he/she is unsatisfied of the purchased product; for a merchant, is always set to 1). Furthermore, the differences among F V , P V and LV are expressed in days1 beginning from F V . Note that R depends on the number of times that an activity has occurred in a CBB stage, the relevance of the involved CBB stage and the more recent accesses.
The information in the described structures are used by an agent a to realize its goals, as explained in the following, excluding the CBB support which is presented in Sect. IV. More in detail: setup steps: semi-automatic procedures are activated to: (i) set initially or update U D, AD, ADB, interacting with Ag when it is needed as in the first a’s activation; (ii) remove a from the system for an U ’s request to Ag. operational steps: a customer agent is automatically activated (resp., deactivated) when a Web session starts (resp., ends “per se” or for an explicit customer’s choice), whereas a merchant agent is automatically activated (resp., deactivated) when its site is on-line (resp., off-line or for an explicit merchant’s choice). An agent performs the following activities: (i) it sends periodically to Ag its aA; (ii) it constructs its profile to support its user updating its AK w.r.t. each agent contact and each access for a product in one or more CBB stages; (iii) in order to realize the first phase of the “Need Identification” CBB stage, in MAST a customer agent periodically sends to Ag a list (L) containing the NAICS code of those products that meet interests and preferences of its user, ordered on the basis of their rate R; (iv) periodically each agent prunes its AK from some evaluated unimportant information on the basis of the values of the rating w.r.t. the threshold T .
The Agency Knowledge (AgK) profile is described by: AgD (Agency Data), that is composed by the Agency Identifier (AgI ) and Internet Address (AgA).
1The choice of the day as reference time unit is due to the characteristics of the problem, given that purchases usually do not occur often in time (e.g., each minute or hour). However, it is possible to change the reference time unit without influencing the generality of the model.
ADB (Agent Data Base), that is a set of agent data where each element, represented by its identifier aI, is described by: an Internet address (aA); the date of the aA update (aAU ); a list (L) of NAICS code referred to those products of interest or preferences; the name (N ame) and address (Address) of the agent’s owner. aP T (Agent Pruning Threshold) that is exploited to deallocate long-time inactive agents.
The behaviour of the Agency consists of: affiliate managing steps: The Agency carries out the following operations automatically: (i) when it is required, the Agency affiliates an agent sending it its Identifier and at this point the agent is logged and operative; (ii) the Agency updates the agent data when it changes; (iii) the Agency stores, for each active agent, the current address and the list L that the agent periodically sends to Ag; (iv) if a user requires an agent deletion to the Agency or if an agent is inactive for a time longer than the pruning threshold aP T , then the Agency deletes the agent and informs the community. service managing steps: The Agency provides some services to agents, namely: (i) the support to realize some CBB stages efficiently as will be described in the following; (ii) a broadcasting message service (e.g., to provide an agent m offer to all agents c); (iii) a yellow page service, where each affiliate can ask the address of another MAST affiliate.
III. THE AGENT INTERNET PAYMENT PROTOCOL (AIPP)
Payment schemes can be assessable with subjective criteria,
as customer acceptance or trust [
Currently, the most used e-payment system is the credit
card, but in this case a credit card number should be provided
to the merchant; this could be risky because the card
number is provided over Internet and/or stored in the merchant
site. The electronic cash systems cannot be used due to
law and crime prevention regulation/legislation [
A centralized account approach has been proposed in 1999
by the Financial Service Technology Consortium (FSTC) with
the Financial Agents Secure Transaction (FAST) project [
The risks in FAST can be further minimized by transferring funds over interbanking networks, assigning to each message a time to live and a unique identifier, managing as much sensible information as possible off-line, etc. The problems of security communication among financial institutions, as those related to defense against viruses or hacker attacks, are beyond the FAST project objectives.
In this paper, we exploit the e-payment protocol AIPP
(Agent Internet Payment Protocol) [
MAST provides a support, in accordance to the CBB model, to customers and merchants in their EC activities. In MAST, typical interaction between agents involves a customer (C) with her/his agent (c) and financial institution (F I C ), a merchant (M ) with her/his agent (m) and financial institution (F IM ), the Agency (Ag), a product (G) offered by a M . The appropriate financial institution typologies are limited to banks, card issuers or relevant financial organizations; further, it is assumed that payers and payees can manage their on-line accounts. In the following, the terms product and service will be used interchangeable.
In MAST, to avoid possible attacks, single-use account identifiers (preserving also financial privacy) and a nonce (i.e., an agent sender marker) are adopted, and a Time To Live (T T L) is used as message deadline for each agent communication. Moreover, to promote trust among customers and merchants, the AIPP protocol allows the F Is to be third parties in a financial transaction, still guaranteeing user’s privacy.
Notation and data contents of the messages used in MAST to transfer in a consistent and efficient way the business information are illustrated before describing the MAST protocol. Note that the subscripts identify sender and receiver while data is an XML document2, whose content is context sensitive (see Table I). More in detail:
IN Fx;y(data): it requires/provides commercial information about a product; REQ IN Vc;m(data): it requires an invoice for a product offered by M ; IN Vm;c(data): it contains the invoice required with REQ IN Vc;m(data); P Oc;m(data): it is the purchase order w.r.t.
IN Vm;c(data);
2MAST agents employ the eXtensible Markup Language (XML) [
TABLE I
MESSAGE SPECIFICATION Message Message Content INFx;y HG((aNS;xM;;aBR;xP;;nCcx;U;T;AT;LXx;)B;Set; DD; CUR; FP ) REQ INVc;m H(aSc; aRc; ncc; TTLc);
G(P IM ; N; M; B; P; C; U; A; X; BSet; DIM ; CUR; F P) INVm;c HC(;aUS;mA;; aXR; mBS;netc;mD;ITMT;LDmD;;PFI;IVm; C);UGR(P;IFMP );;NF(;FMI;IBM; ;P;
FIAM ; AcTM ) POc;m H(aSc; aRc; ncc; TTLc; PIIm);
F(F IIC ; FIAC ; AcTC; AddressC) PPMEATxxO;;yyc;F IC HHH(((aaaSSScxx;;;aaaRRRcxx;;;nnnccccxx;;;TTTTTTLLLcxx;;;PPPIIIIIImmm);))
F(F IIM ; FIAM ; AcTM ; H(INVm;c)) A MTOF IC ;c H(aSF IC ; aRFIC ; ncFIC ; TTLFIC ; PIIm) R MTOF IC;c H(aSF IC ; aRFIC ; ncFIC ; TTLFIC ; PIIm)
EANCVETAWLCAcO;ImDx;xy;y HHH(((aaaSSScxx;;;aaaRRRcxx;;;nnnccccxx;;;TTT.TTTLLLcxx;;)P;PIFI(IAImmc)T);yF)(H(INVm;c)) In the first three CBB stage the messages can be addressed to c agents chosen among those listed in ADB or employing the Ag’s broadcasting messages service P Ex;y(data) (resp., P Ax;y(data)): it notifies that the payment has been performed (resp., aborted) w.r.t. P Oc;m(data); M T Oc;F IC (data): it is an irrevocable money transfer order w.r.t. IN Vm;c(data); A M T Oc;F IC (data) (resp., R M T Oc;F IC (data)): it notifies the MTO acceptance (resp., rejection) w.r.t. M T Oc;F IC (data); ACT CODx;y(data): it contains the MTO activation code w.r.t. IN Vm;c(data); N EW AIx;y(data): it contains a new single-use account identifier to be employed in the next purchase or sell; EV ALc;m(data): it is an optional evaluation of a purchase.
A data XML document is structured in three sections including: 1) H (Header) that is composed by: agent identifiers of Sender (aS) and Receiver (aR); CBB Stage (S); Nonce (nc) that is an agent’s marker; Time To Live (T T L); Product Invoice Identifier (P II). 2) G (Products) that encodes: Product Identifier (P I) and the product data (N; M; B; P; C; U; A; X; BSet) previously described in Sect. II-A; one or more Delivery Identifiers (DI) with the corresponding data (DD; F; V ), previously described in Sect. II-A; Commercial Unit Required (CU R); Final Price (F P ). 3) F (Financial) is constituted by: Financial Institution Identifier (F II); Financial Institution Internet Address (F IA); Financial Institution Single-Use Account identifier (Ac); User Address (Address).
The actions performed by agents in MAST to support customers and merchants in their B2C activities during all CBB stages are described below in detail for each CBB stage and represented in Fig. 3.
a) Need Identification Support: ( = 1). In the first CBB stage, customers identify their needs and merchants advertise their offered products (G) to as more potential customers as possible. In detail: (i) when an M wants to make an offer about a product to potential Cs, he/she has to submit own offer sends to Ag an IN Fm;c; (ii) in a first phase the Ag, on the basis of the lists L provided by the c agents, takes care of sending the offer to the potentially appropriate c agents, then in a second phase the c agents present such offers to their Cs only if they are fully compatible with their interests and preferences.
b) Product Brokering Support: ( = 2). This stage occurs when a customer has identified a need and looks for a suitable product to satisfy it. In detail: (i) C can ask information on the desired product typology to one or more M s by means of IN Fc;m; (ii) all M s that have a product that matches the C request, reply with a new IN Fm;c with all the details of the products and commercial information.
c) Merchant Brokering Support: ( = 3). A customer identifies the most suitable merchant to purchase a product carrying out the following actions: (i) If C has sufficient knowledge of the product details, a c’s message IN Fc;m is sent to one or more merchants; (ii) if there is a product that matches C’s request, M replies with a message that reports a complete description of the product; in such a way c can select the best product offer. Note that if in the previous stage C has received a sufficient number of IN Fm;c it is possible to choose a merchant without carrying out this present stage explicitly.
d) Negotiation Support: ( = 4). In this stage a pair of customer and merchant define the purchase details. They realize suitable strategies in a multi-round session for their respective bids and offers presented by means of messages. This stage is closed when an agreement is reached or the timeout T T L of the last message has elapsed.
e) Purchase and Delivery Support: ( = 5). In this stage the customer purchases, pays and chooses a delivery modality for a product offered by a merchant employing the AIPP protocol where: payer and payee identities are authenticated by their respective financial institutions during their on-line accounts accesses (usually with login and password over a SSL Internet session); payments occur directly among the financial institutions; Single-use account identifiers are adopted; No heavy protocol is needed; no sensible financial and commercial information is exchanged to assure privacy; financial institutions are third parties in the transaction to guarantee customers and merchants. The actions performed in this stage are: (i) When C wants to purchase a product offered by M , he/she sends the message REQ IN Vc;m; (ii) m replies with IN Vm;c (a pro-forma invoice); (iii) c logs into F IC and then orders a Money Transfer Order (M T Oc;F IC ) to F IM payee; (iv) F I C accepts/rejects the MTO on the basis of the existence of sufficient C’s funds and notifies to c its choice with a A M T OF IC;c + a new single-use account identifier (AcT ) for the next purchase or with a R M T OF IC;c message; (v) c sends a P Oc;m to effect the purchase order; (vi) m logs into F I M and sends the required payment activation code (H(IN Vm;c) to F I M ; (vii) F I M provides M with a new single-use account identifier (AcT ) for the next sell and sends to F I C the payment code (H(IN Vm;c); (viii) if the activation code is the same as that provided by c, then F I C effects the payment via F I M and informs c about the state of success (P EF IC;c) or failure (P AF IIC;c) of the MTO process; (ix) if the payment has been performed by F I C, then F I M informs m with a P EF IM ;m message, otherwise after the TTL of the ACT CODF IM ;F IC message F I M informs m with a P AF IM ;m of the sell failure; (x) finally, m could however accept the payment informing F I M , and consequently F I C, or refuse it aborting the sale and returns back the money to F I C by means of its F I M . At last F I C will inform c whether the product has been purchased or not.
f) Service and Evaluation: ( = 6). It is an optional feedback provided by a customer to express her/his dissatisfaction about the purchase of a product, the merchant or both. Two kinds of actions can be carried out by the customer: (i) if the purchased product has been evaluated negatively, the Rate R 2 AK will assume a negative value by setting the coefficient to 1; (ii) if the merchant has been evaluated negatively, its identifier will be deleted from P ASet (w.r.t. G), Time employed by the merchant server for 1000 "Purchase and Delivery" transactions 600 500 then C might decide to inform M directly, or in an anonymous form by means of Ag, about her/his dissatisfaction.
A complete prototype of MAST framework has been
implemented in JADE [
In the “Need Identification” the experiments have been finalized to measure the customer satisfaction degree (CSD) computed as the number of merchants’ offers evaluated by the customers as correctly filtered by the system. The filtering process is carried out for each customer in two phases, the first performed by the Agency and finalized to disregard immediately all merchants’ offers clearly out from the customer’s interests and preferences; while the second phase is performed by the customer’s agent to realize a fine tuning of the filtering activity on the basis of its profile. The tests have been carried out by 19 customers, using their agent profiles previously built on the basis of CBB activities carried out on XML EC sites.
More in detail, in the first phase on a total of 4750 merchant offers (250 offers for each customer), randomly chosen among the products offered in the XML EC sites, the agency has correctly rejected 3154 of them and considered potentially interesting 1596 offers. Then in the second phase, on the remaining 1596 offers the customers’ agents have evaluated surely interesting only 193 offers, but 79 of them were not really interesting for the customers. In this way, we obtain a global CSD equal to 0,983. Note that we have set the filtering parameters to avoid the rejecting useful merchants offers.
About the “Purchase and Delivery” stage, it is clear that the cost located on the customers’ client side has a minimal impact on the computational performance, since usually only 3The simulations have been realized by employing computers based on single CPU (Intel Pentium 4, 3 GHz), RAM 2 Gbyte and O.S. Linux. one MAST activity runs at a time. Conversely, a merchant agent is associated with high computational cost, given that it has to satisfy a large volume of processes at the same time referring to different c agents. Consider that the server has to carry out other tasks for its EC activities that can absorb also a significant amount of resources and that have been simulated by assuming some different application costs as percentage of all processes carried out by an m agent; besides, the Internet cost can influence the global system performance and it has been simulated by setting some delays in the communications (tests were carried out on a 100 Mb LAN).
This procedure is surely a critical test activity, for the necessity to coordinate more parties, sending more messages and realizing some secure connections (SSL connections have been adopted in the tests). In the following, we employ this process only in order to obtain a rough estimation of the MAST computational efficiency in this CBB stage (keeping in mind that the MAST approach has anyway other significant benefits provided by the authentication mechanism and payment security level). In particular, the time necessary by the merchant’s server to complete a sequence of 1000 “Purchase and Delivery” transactions for different application costs and network delays is represented in Fig. 4. Note that some steps occur using no secure connections and other occur on a simulated reserved banking channel.
The experiments suggest some considerations about the implemented MAST prototype and experimental results obtained. Using the MAST prototype, all CBB activities have been correctly carried out, customer and merchant profiles have been initialized, correctly updated and all our project goals have been meet, showing the capability of MAST to provide proper support to customers and merchants in EC scenarios. The experimental results obtained, even though they have only an indicative meaning both for the initial scenario assumption and some compulsory rough simulation show interesting performances in terms of efficiency, effectiveness and time employed.
The various aspects connected to the B2C have been dealt with in a very large variety of scientific works; some works which to our knowledge come closest to the material presented in this paper will be mentioned in this section.
The role of software agents in the EC has become very
relevant, as proved by the large number of models and
architectures proposed in literature and the state of the art
has been investigated in a significant number of surveys
[
MAGMA [
CASBA [
This aforementioned work exploit multi-agent systems to
support B2C activities. They are explicitly CBB based or
partially consistent with it. Customer interests and behaviour
are taken into account in [
This paper describes MAST, an XML-based multi-agent system to support customers and merchants in a suitable, homogeneous and personalized way, taking into account their interests on the basis of the behaviours shown during their B2C activities, represented as in CBB model. Furthermore, the opportunities offered by XML (for agent profiles, the messages, the inter-catalogue representation of products and categories and the agent communication language) are used along with those of a secure centralized payment scheme, based on existing financial institutions and single-use account numbers (payments happen only among financial institutions, over reserved communication channels, by preserving financial anonymity and confidentiality and benefiting of an existing authentication mechanism). Some results of experimental simulations in a small B2C scenario, carried out using a Jadebased prototypal implementation of MAST, are presented.