FORMATION AND FULFILLMENT OF ELECTRONIC
CONTRACTS IN ICS
Nathália R. S. Oliveira, Sofiane Labidi, Edson Nascimento and Carlos R. B. Almeida
Eletrical Engineering Department, Federal University of Maranhão, Campus do Bacanga, São Luís-MA, Brazil
Ke
ywords: Electronic Commerce, Intelligent Agents, Contract Formation, Contract Fulfillment, Ontology, Temporal
Workflow
Abstract: This work is part of the ICS project (Intelligent Commerce System) whose aim is to design and implement
an effective B2B E-commerce system based on mobile and intelligent agents. The ICS lifecycle is based on
five phases: User Modeling, Matchmaking, Negotiation, Contract Formation and Contract Fulfillment. We
propose here an automated process for the Contract Formation and Fulfillment phases. We propose ontology
for sharing knowledge between agents that participate in the configuration process of contract, besides a
repository to store contract templates and contract instances. For managing the contract fulfillment, a
Temporal Workflow and active rules based on ECA paradigm of Active Database System are applied in
order to develop this process.
1 INTRODUCTION
Electronic commerce is increasingly applied in
organizations. This is encouraged by the fact that it’s
offering opportunities to discover new ways and to
improve the existing ones. E-commerce aggregates
more activities than purchase and sale: marketing,
invoicing, negotiation, contracting, payment,
delivery and so on. This and other facts prove that
doing electronic commerce on the Internet became
attractive and made it one of the most important
areas of investment in information technology.
Researches showed that the progress on
sophistication of automation turns the e-commerce
more dynamic and personalized. Examples are
applications that use intelligent agents to act on
behalf of its users, developing things like: making
commercial decisions, negotiations, participating on
auctions, playing important roles on electronic
markets as mediators, matchmakers, and other ones
(Jennings, 1998). One of the most growing e-
commerce areas are B2B applications that had
received increased interest by companies. But many
still have worried about the trust in transactions
made through Internet. To resolve this problem, the
ICS included two important phases on it lifecycle:
Contract Formation and Contract Fulfillment. This
paper focuses on the development of these two last
phases of ICS (Intelligent Commerce System)
(Labidi et al., 2003). We adopt the use of electronic
contracts on ICS to provide guarantees and,
consequently, to reduce the uncertainty associated
with transactions realized through this system.
Defining obligations that each party must fulfill and
making it enforceable by law, could reach these
guarantees we are referring.
We propose an automated process to implement
the Contract Formation phase. It uses intelligent
agents, ontology and XML. This includes two
aspects: a modeling of contracts that are manipulated
by a special agent and the behaviour of this agent.
We decide to apply the concepts of Semantic Web to
deal with this project because it makes possible the
improvement of the interpretation and recuperation
of information by agents, besides the exchange
information between them.
In the Fulfillment phase, we propose the use of
Temporal Workflow and active rules based on
ECAA paradigm’s Active Database System to
achieve the monitoring and management of the
activities to be performed by the parties of a
contract.
The paper is structured as follow. The section 2
presents the ICS system and its architecture. This is
continued by a brief description of ICS life cycle and
its phases. Section 4 and 5 details the process of
Contract Formation and Fulfillment phases. Finally,
section 6 outlines our conclusions and future works.
24
R. S. Oliveira N., Labidi S., Nascimento E. and R. B. Almeida C. (2004).
FORMATION AND FULFILLMENT OF ELECTRONIC CONTRACTS IN ICS.
In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 24-30
DOI: 10.5220/0002648700240030
Copyright
c
SciTePress
2 THE INTELLIGENT
COMMERCE SYSTEM - ICS
The ICS is an implementation of Business to
Business Electronic Commerce that apply mobile
and intelligent agents to carry out the process of
business making. The mobiles are responsible to
represent the ICS’ users, while the others have to
implement internal functions that take this system
work.
In the ICS system, negotiating agents work in an
open environment like Internet (or Intranet), moving
through the network to meet a potential negotiation
area with other agents looking for opportunities to
do business.
Fig. 1 shows the architecture of ICS that is made
by eight main components: marketplace, region,
matchmaker, mediator, contractor, negotiators,
ontology repository and contracts repository.
A marketplace is an environment that provides a
context within the system in which an agent
performs its tasks.
These tasks include details about communication
protocols, negotiation, storage information in
repositories, contract formation, besides functions
like access and control negotiation.
A region is a cluster of marketplaces operating
on the same domain ontology that represents the
business areas (sales of vehicles, food, electronic
products, etc). It also provides a higher level of
abstraction for communication among agents from
different regions. Whenever a new marketplace is
created it is identified as member of a region.
Only marketplaces of the same region can
communicate with each other. The objective is to
resolve the context problems.
The negotiators are mobile agents that represent
the users of ICS (companies that want make
business on the Internet). They should be
responsible for making commercial transactions
such as making survey of prices, analyzing business-
oriented proposals, etc, and put announcements in
appropriate repositories placed on regions.
The matchmaker agent makes queries in these
repositories to match similar interests and contact
possible business partners. There is just one instance
of this agent per region. This agent with its complete
functional and design requirements is detailed in
(Tomaz et al., 2003).
The mediator agent treats to guarantee the
management of the process negotiation governed by
a protocol – placed in the ontology repository -,
coordinating the participation, execution, resolution
and termination of negotiation.
In the case of a successful negotiation, the
contractor should validate the contract obtained
through negotiation using the same protocol, store it
in the repository (contracts repository) and produces
a workflow with the obligations established between
the parties.
The used protocol, called Negotiation Protocol,
coordinates messages flow among participants and
imposes rules for negotiation “game”. Each
marketplace implements a kind of it, which can be:
auction, procurement, bargain, etc.
3 ICS LIFECYCLE
The ICS lifecycle adopted in our system is an
extension of the model proposed in (Jennings, 1996)
and (Bartolini, 2001). A previous work (Fonseca et
al., 2003) has already introduced the user modeling,
matchmaking and negotiation phases, concept of
information feedback and has described ontologies
for each of these phases. As shown in Fig. 2, the
new model is composed by five phases.
User Modeling: In this phase the system capture
the users’ preferences and restrictions from queries
based on a domain specific ontology (Mukherjee,
2000).
Matchmaking: A trader locates other traders that
could potentially do business. This is made placing
advertisements in a shared repository.
Negotiation: The trader enters into negotiation
with one or more of these potential business partners
to agree or disagree to mutually acceptable terms of
business. These terms are placed in contract
templates and include some definitions like the
goods or service being traded, price, delivery date,
etc.
Contract Formation: All agreed terms are placed
into a legally biding contract and it is stored in an
appropriate repository.
Contract Fulfillment: The parties carry out the
agreed transaction, within the parameters specified
in the contract, monitored by workflow.
Figure 1: The ICS Environment
FORMATION AND FULFILLMENT OF ELECTRONIC CONTRACTS IN THE ICS
25
The results of Contract Fulfillment may be
returned, giving a feedback and reused during a new
modeling enriching the user models. The next
sections detail the Contract Formation and
Fulfillment phases of ICS lifecycle.
4 CONTRACT FORMATION
4.1 Definition
Contract is an agreement between two or more
parties about certain object that establishes rights
and obligations to each one. As a legal standpoint, a
contract serves to alleviate mistrust in a world of
uncertainty by constraining the unpredictable
activities of the other autonomous parties
(Milosevic, 1995).
We are working on B2B contracts - contracts that
deal with business transactions. For a while, the ICS
aims to provide some species of contracts that are
more common in B2B transactions: buy and sell,
rent, permute and service.
4.2 Contract Template and Instances
In our work, we propose modeling electronic
contracts through a kind of representation that are
orient to the reading and understanding of intelligent
agents. To deal with this modeling of contract
formation, we propose the use of a repository to
store contract templates (Ludwig, 2001) and contract
instances. Contract templates, in our approach, are
full standard contract forms that include fields to be
filled. These forms, in principle, correspond to the
species above mentioned. So, we decided to use
XML and build ontology.
The templates were modeled using XML, giving
structuring and representation to textual information.
We present in this paper a simple contract template
modeled with XML given in Appendix.
However, contract instances are contracts agreed
by parties, i.e., templates that already have been
filled after a successful negotiation.
The full standard contract forms have their
structure fixed and pre-defined. So, the negotiation
is obtained through the agreeing on the values in the
contract as defined in the standard contract forms.
Templates were introduced to reduce the cost of
setting up the contract formation, based on our
observation that there are a number of elements
which are common to many contracts and that this is
a frequently practice adopted by lawyers.
In addition, the repository should provide related
management operations, for example: addition of
new contract templates, specialization of contract
templates from existing ones, establishing other
possible relationships between them, besides add
and remove contract instances.
4.3 Contract Ontology
In the Negotiation phase, as we have already
mentioned, the negotiators agents start the process of
negotiation following a protocol. This protocol is a
common sense knowledge shared into ICS’s
marketplace, which was modeled as ontology like
proposed by (Tamma, 2002).
We extend this ontology adding the concept of
Contract, its types and parameters, bringing
advantages such as improving the negotiation and
allowing validation of templates.
The Fig. 3 shows the new Negotiation Protocol
ontology modeled on Protegé Ontology Editor (Noy
et al., 2001). This ontology approach has been
designed to support multiple kinds of negotiation,
cardinality among traders and some species of
contracts. It is stored in the marketplaces – on
ontology repository - and shared by all agents that
participate in the negotiation.
4.4 The Automated Process of
Electronic Contract Formation
One of the paper’s objectives was the development
of contractor agent’s function: management of
electronic contract configuration. To develop this,
the contractor should make a lot of activities. The
scene where interactions among contractor and
Figure 2: The ICS E-Commerce Lifecycle
ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING
26
negotiators agents happen is illustrated below on the
Fig.4.
A sequence of contractor’s actions is:
1) The negotiators that had closed an agreement
should communicate this to contractor;
2) Contractor accesses the repository to take an
appropriate template;
3) After, it requests the negotiation parameters
from these negotiators;
4) When it had received, should validate it using
the Protocol ontology already showed;
5) Then, it fills the template and stores it on the
repository – now becoming a contract instance – to
keep the evidence of transaction.
In Fulfillment phase, the contractor will produce
a workflow based on parties’ obligations.
5 CONTRACT FULFILLMENT
Although the parties have compromised to each
other, there is the possibility of contract breach.
Contract Fulfillment phase treats to verify the
execution of obligations defined by parties. So, if a
contracting part deviates from its prescribed
behavior, - intentionally or not – some mechanism
should be programmed to inform what kind of
problem has occurred.
A contract can be seen as a kind of business
process that usually defines deadlines dates to it
execution, fact that made us apply one of execution
system technologies existents - Temporal Workflow
- in conjunction with active rules to coordinate this
whole process.
Temporal Workflow produces all the obligations
and related activities that each party must fulfill,
defining the start time, duration and finish time. This
temporal model used is based on work in (Labidi,
2000). Active rules enable monitoring the
obligation’s deadlines, based on finish time of each
obligation and notify the agent to verify the status of
next activity. This approach was adapted from
(Kappel, 1998) work.
The results of the Fulfillment phase –
performance or non-performance of obligations –
will be returned to User Modelling phase. This fact
helps to enrich the User Model through the reusing
of these informations during a new modeling
(Fonseca, 2003).
Fig. 5 shows an example of temporal workflow
produced from a buy and sell contract.
6 CONCLUSION AND FUTURE
WORKS
The fast growing of electronic commerce, mainly in
B2B, requires a sophistication of its functionality.
The applications of intelligent and mobile agents
bring many advantages as personalized queries of
consumers and business suppliers, real-time access
from remote resources, lower computational cost
and so on.
The contributions of ICS relative of ontologies
proposed on some phases, permit sharing the
knowledge about negotiation and contracting
process between all agents that shall communicate.
Figure 4: The Contractor Agent Scenario
Figure 3: The Shared Protocol Ontology
Negotiator
Agents
Contractor
Agent
Repository Protocol
send_message_agreement
get_template
request_parameters
send_parameters
validate_parameters
fill_tem plate_with_parameters
store_template
FORMATION AND FULFILLMENT OF ELECTRONIC CONTRACTS IN THE ICS
27
Contracts make any business more attractive. The
fulfillment of obligations enforceable by law
provides some guarantee that either it will be done
or the legislation will carry out until the final
resolution.
Future works in this area can include a feedback
of contract filled to the users of ICS (companies)
that had closed an agreement. This make that they
can confirm if what did they negotiate is correct.
This implies in adoption of infrastructure’s supply
security in transactions involving the transference of
contract information. Issues like Cryptography and
Digital Signatures must be considered in terms of
Contract Formation’s implementation.
REFERENCES
Bartolini, C., and Preist, C. A Framework for Automated
Negotiation. 2001. HP Labs Technical Report.
Bechhofer S., Horrocks I., Goble C., Stevens R. OilEd: a
Reason-able Ontology Editor for the Semantic Web.
Proceedings of KI2001, Joint German/Austrian
Conference on Artificial Intelligence, September 19-
21, Vienna. Springer-Verlag LNAI Vol. 2174, pp 396-
-408. 2001.
Fonseca, Luis C. et al. ICS-An Agent Mediated E-
Commerce System. In Proceedings of 5th International
Conference on Enterprise Information Systems,
Angers – France, p.23-26, April, 2003.
Jennings, N. R., Faratin, P., Johnson, M. J., O'Brien, P. O.,
and Wiegand, M. E. 1996. Using intelligent agents to
manage business processes. In First International
Conference on the Practical Application of Intelligent
Agents and Multi-Agent Technology (PAAM-96)
(April 1996), pp. 345–360.
Jennings, N.R. and Wooldrigde M. Applications of
intelligent agents. 1998.
Kappel, G., Rausch-Schott, S., Retschitzegger, W.,
Coordination in Workflow Management Systems - A
Rule-Based Approach, in: W. Conen, G. Neumann
(eds.) Coordination Technology for Collaborative
Applications - Organizations, Processes, and Agents,
Springer LNCS 1364, 1998, pp. 99-120.
Labidi, Sofiane et al. Intelligent B2B Commerce System.
In: INNOVATEX/FORMATEX. (Org.). Techno-
Legal Aspects of Information Society and New
Economy: an Overview. Badajoz, 2003, v. I.
Labidi, Sofiane; Hammodi, Slimane; Gannoun, Lassaad.
Integrating Cooperation and Temporal Organization in
Workflow Management. In: The 2000 International
Conference on Artificial Intelligence (IC-AI'2000).,
2000, Las Vegas. The 2000 International Conference
on Artificial Intelligence (IC-AI'2000). Las Vegas:
World Scientific Engineering Society, CSREA Press,
2000. p. 229-235.
Ludwig, H.; Gisler M.. Electronic Contracts and Contract-
Based Computing. Invited Tutorial at the IFIP I3E
Conference, Zurich, October 2001.
Milosevic, Z. and Bond A. Electronic Commerce on the
Internet: What is Still Missing? In Proceedings of the
5th Conference of the Internet Society, Honolulu, June
1995.
Mukherjee R. et al. Analysis of domain specific ontologies
for agent-oriented information retrieval. In the
working notes of AAAI 2000 Workshop on Agent
Oriented Information Systems, Austin, TX.
Noy N. F. Creating Semantic Web Contents with Protégé-
2000. IEEE Intelligent Systems 48(2):60-71, 2001.
Tamma V., Wooldridge M., and Dickinson I.. An
Ontology for Automated Negotiation. In Proceedings
of the Workshop on Ontologies in Agent Systems,
Bologna, Italy, July 2002.
Tomaz R. F. et al. A Semantic Matching Method for
Clustering Traders in B2B Systems. In IEEE/LA-Web
First Latin American Web Congress, Santiago, Chile,
November 2003.
Figure 5:
Example of Temporal Workflow
Send confirmation
payment
confirmation
arrived?
NY
Y
N
Business
Consumer
Business
Supplier
Check receiving of
confirmation
Delivery product Cancel contract
Check delivery
product
arrived?
Cancel contract
Receive product
ST = 0
D = 5
FT = 5
ST = 6
D = 10
FT = 16
ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING
28
<Contract>
<Title>Contrato de Compra e Venda</Title>
<Party_ID>
<body>This private Agreement Promise of Buying and Selling which is done between (hereby
called The Seller) , located at here being represented according to the Social Contract, and on the other
side (The Buyer), located at here being represented according to the Social Contract have the following
agreement according to the clause and conditions below:</body>
<name1/>
<cod1/>
<address1/>
<name2/>
<cod2/>
<address2/>
</Party_Identification>
<Chapters>
<ChapterI Name="Chapter I - Object">
<ClauseI.I Name="First Clause">
<body_cI.I>The seller is the legally onwer of the instrument which is being described
below:</body_cI.I>
<object/>
</ClauseI.I>
</ChapterI>
<ChapterII Name="Chapter II - The Amount and Way of Payment">
<ClauseII.I Name="First Clause">
<body_cII.I>On this selling and buying instrument and in the best way the seller
compromises to sell to buyer and this is compromises to buy form buyer the instrument above described
by the price of to be paid on the following conditions:
</body_cII.I>
<price/>
<price_desc/>
<paym_cond/>
</ClauseII.I>
<ClauseII.II Name="Second Clause">
<body_cII.II>It is determined the equivalent fee to be applied in case of unjustified
delay applicable in the payment of remaining parcels paid by buyer to seller plus interests every month
and monetary update.</body_cII.II>
<fee_value/>
<fee_desc/>
<interests_value/>
<interests_desc/>
</ClauseII.II>
</ChapterII>
<ChapterIII Name="Chapter III - Time of Delivery">
<ClauseIII.I Name="First Clause">
<body_cIII.I>The time of delivery has to be in , counted from the date of signature of
the agreement except in case of happening any disaster or inevitable actions.</body_cIII.I>
<n_days/>
</ClauseIII.I>
</ChapterIII>
APPENDIX: THE SIMPLE CONTRACT TEMPLATE MODELLED IN
XML
FORMATION AND FULFILLMENT OF ELECTRONIC CONTRACTS IN THE ICS
29
<ChapterIV Name="Chapter IV
-
Obligations">
<ClauseIV.I Name="First Clause">
<bodyc_IV.I>Obligations Seller:</bodyc_IV.I>
<list_obligations1/>
</ClauseIV.I>
<ClauseIV.II Name="Second Clause">
<bodyc_IV.II>Obligations Buyer:</bodyc_IV.II>
<list_obligations2/>
</ClauseIV.II>
</ChapterIV>
<ChapterV Name="Chapter V - Responsibilities">
<ClauseV.I Name="First Clause">
<bodyc_V.I>Responsibilities of Seller:</bodyc_V.I>
<list_responsabilities1/>
</ClauseV.I>
<ClauseV.II Name="Second Clause">
<bodyc_V.II>Responsibilities of Buyer:</bodyc_V.II>
<list_responsabilities2/>
</ClauseV.II>
</ChapterV>
</Chapters>
<Final>
<body_dg>Is elected the Court of to have all the registration and not any other one to be
questioned in case of any doubts about this agreement.
Being this the agreement the parties below agree and sign this present instrument in 02 (two) copies of
equal form and pages in the presence of witness:</body_dg>
<court/>
<local/>
<date/>
<witness1/>
<name_witness1/>
<cod_witness1/>
<witness2/>
<name_witness2/>
<cod_witness2/>
</Final>
</Contract>
ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING
30