See discussions, stats, and author profiles for this publication at:

https://www.researchgate.net/publication/221269828

A Frame Work for Modeling Electronic Contracts

Conference Paper · November 2001

DOI: 10.1007/3-540-45581-7_16 · Source: DBLP

CITATIONS READS

41 61

3 authors, including:

Kamalakar Karlapalem A. R. Dani

International Institute of Information Technolo… The ICFAI University, Hyderabad
201 PUBLICATIONS   2,641 CITATIONS    16 PUBLICATIONS   131 CITATIONS   

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Kamalakar Karlapalem on 29 May 2014.

The user has requested enhancement of the downloaded file.

 A Frame Work for Modeling Electronic Contracts

Kamalakar Karlapalem+, Ajay R. Dani*, and P. Radha Krishna*

+
IIIT, Hyderabad, India.
*Institute for Development and Research in Banking Technology, Hyderabad, India.

kamal@iiit.net, {ardani, prkrishna}@idrbt.ac.in

Abstract. A contract is an agreement between two or more parties to create

business relations or legal obligations between them. A contract will define the
set of activities to be performed by parties satisfying a set of terms and
conditions (clauses). An e-contract is a contract modeled, specified executed,
controlled and monitored by a software system. Typically, a workflow
management system is used for e-contract management. E-contracts are
complex inter related workflows that have to be specified carefully to satisfy the
contract requirements. Most workflow models do not have the capabilities to
handle the complexities of these interrelationships. That is, an e-contract does
not adhere to activity/task oriented workflow process, thus generating a gap
between a conceptual model of e-contract and workflow. Therefore, there is a
need for a modeling framework to conceptualize e-contracts and model the
complexity of interrelationships. In this paper, we present a framework for
conceptually modeling e-contracts (using ER-R data model) and a methodology
to translate an e-contract to a workflow that can be executed by a workflow
management system.

1. Introduction
A contract is an agreement between two or more parties to create business relations or
legal obligations between them. There are several stages involved in a contract such
as exchange of information and negotiation, before the execution of the contract. A
contract will define a set of activities to be performed by parties satisfying a set of
terms and conditions (clauses). Thus, a contract consists of several entities such as
parties, activities, and clauses. Each of the activities may involve a considerable
period of time for its execution. The terminology of activities is according to the
concept of activities as promoted by activity management system [KYH1995]. In rest
of the paper, we mean an activity to be a workflow and an activity consists of set of
tasks.
In recent years, the penetration of Information Technology into real-life
applications has transformed the way business is being transacted. One such
application is Electronic Contracts, which made business simple by effectively
modeling and managing the processes/tasks involved. An electronic contract (e-
contract) is a contract modeled, specified, executed, controlled and monitored by a
software system. In e-contracts, all (or a number of) activities are carried out
electronically and, thus, overcome the delays involved in the manual system and also
personnel biases. In the literature, considerable work has been carried out on the legal

H.S. Kunii, S. Jajodia, and A. Sølvberg (Eds.): ER 2001, LNCS 2224, pp. 193-207, 2001.
 Springer-Verlag Berlin Heidelberg 2001
194 Kamalakar Karlapalem, Ajay R. Dani, and P. Radha Krishna

aspects and negotiation stages of e-contracts [GSG2000][KS1998]. In this paper, our

focus is to conceptualize and specify e-contracts.
A workflow is concerned with the automation of procedures where documents,
information or tasks are passed between participants according to a defined set of
rules to achieve, or contribute to, an overall business goal [WfMC1995]. The
execution of an e-contract involves several processes/tasks and monitoring activities,
which can be represented as workflows. However an e-contract involves the complex
inter/intra relationships among workflows in a contract. An e-contract can be seen as
a global manifestation over a set of inter-related workflows. Most workflow models
do not have the capabilities to provide this global view of an e-contract arising out of
these relationships. Due to this, the workflows for an e-contract must be carefully
specified and related to meet the contract requirements. Therefore, in this paper, we
present a framework for conceptually modeling e-contracts (using ER-R data model
[TNCK1991]) and a methodology to translate an e-contract to a workflow that can be
executed by a workflow management system. In our approach, the Entity-
Relationship (ER) model is extended to model the e-contracts. We call the resulting
model as the EREC model.
The rest of the paper is organized as follows. In section 2, we introduce e-contracts
and Meta-Schemas for e-contracts and workflow. Section 3 presents an EREC Model
for E-Contracts. In section 4, we describe a methodology to translate an e-contract to
a workflow. Section 5 discusses related work, and section 6 concludes this paper.

2. E-contracts
In the present work, we consider a typical e-contract consisting of parties, activities
and clauses. E-contract and contract are used synonymously in the rest of the paper.
Two or more parties are involved in performing activities of a contract. A contract
has a set of clauses. Each party has a well-defined role in a contract, which is
specified in the contract document. For example, in a purchase of goods contract, one
party is a buyer and there can be many sellers. Even though a contract can have many
entities involved, a contract in its simplest form can be characterized as an ordered list
consisting of {P, A, CL}, where P = {P1, P2, . . ., Pn} is the set of parties, n ≥ 2; A is
the set of activities to be performed by different parties; CL is the set of clauses.
A contract will specify how the contract will be executed, the restrictions on the
parties involved, etc. Unless it is specified in the contract it can be assumed that
1. One or more parties involved in the contract can enter into a subcontract. A sub
contract itself is a contract, thus may have its own parties, activities and clauses.
Thus, contracts may be nested.
2. A clause can refer to another clause in the list of clauses of a contract.
3. A contract will have list of activities to be performed, some of the activities may
be nested. That is, an activity is composed of other activities. Some activities
may be carried out in parallel, and some sequentially.
The contract will be for a specified time period or duration, which will be defined
in the contract. This duration will define the active life stage of the contract. It is
expected to last till the contract is completed. A contract completion may not occur
when some clauses beyond completion of activities need to be adhered to, for
example, maintenance and warranty period. The activities will be linked with parties,
 A Frame Work for Modeling Electronic Contracts 195

and each party will have to carry out one or more activities. The clauses in the
contract may list out the activities, however the activities may not be linked with
clauses. For example, “70% of the payment is made after the systems received and the
remaining amount will be paid in two installments after six months and one year
respectively from the date of installation”. In this example, the clauses are linked with
payment activity, but not vice-versa. This helps us to have a library of common
activities that cater to various clauses in the contracts.

2.1. E-contract Meta-schema

Figure 1 shows the meta-schema for a contract using the ER-R model. In addition to
entities and relationships, and their attributes, it models exceptions as external rules
using ER-R model. Exceptions in e-contracts will play a major role when a
process/task deviates from a clause. The exceptions are represented as parallelograms
(as rules). For the sake of simplicity, the attributes of entities and relationships are
not shown in the ER-R diagram.
The meta-schema of e-contract allows us to capture the conceptual level details
about the elements involved in a contract. The entities in the meta-schema are parties,
activities, clauses, budget, roles and payments (see Figure 1). Note that this meta-
schema also facilitates easier modeling of e-contracts by being a template (see Section
3.2) that can be instantiated for specific applications.
Subcontract is a weak entity of Contract. Though, a subcontract previously exists
as a contract, it can also be a part of the main contract for an application. The entities
parties, activities and clauses form a relationship with a contract. Activities have
relationship with Synchronization, so that there is coordination among the activities
during their process. Clauses in a contract are similar to constraints (or
Conditions/Rules) in ER-R model. Since a clause can refer another clause, the Clause
entity in the meta-schema is self-related. The relationship Lists between Clauses and
Activities models the activities in a clause.
Each party plays some role in a contract. The many-to-many relationship between
Parties and Roles in the meta-schema represents that one party can have many roles,
and different parties can play the same role. Payments is an important entity in e-
contracts. Payment transactions are always between the parties, and the payment is
made to payee based on the clauses defined in the contract. The Payments in the
meta-schema have a ternary relationship with Parties and Budget entities. The budget
is continuously monitored during payments so that the expenditure is within the
budget. If amount in a payment transaction exceeds the balance budget amount (i.e.,
budget exceeds), then an exception budget over is raised. Exceptions defined in the
meta-schema are associated to entities in the form of Event-Condition-Action (ECA)
rules. Specific ECA rules can then be bound to contract for versatile exception
handling.
Contract events
The information about the contracts including parties, clauses and activities are stored
in a database, and are linked with each other. The activities have attributes like
Activity Identification, Starting-Date, Ending-Date, Name of Activity, Description,
Requirements and Specifications. There may be Payment Schedule linked with the
Activity, so that the payment may be done after successful completion of an activity.
196 Kamalakar Karlapalem, Ajay R. Dani, and P. Radha Krishna

Thus, when a contract is being executed, many events will occur and operations on
different files (tables) will take place.

Rule-1 Addition
of New
(1, n)
Reject Parties Is a
Request

Contract (0, n) Sub

Can
Contract
have

Parties Has Activities Must

have

Have Clauses Lists

Synchronization

refer
Roles Budget
Over
Can
Budget
have
Stop
Rule - 3
Work
Rule - 2
Role Payments
Allowed
changes Relations
Rules
Not Allowed
Events

Fig. 1. A Meta-Schema for E-Contract

An event happens at any point of time and has no duration. At any particular time
some action will cause an event to occur. The action like “Change Status of Activity”
will cause the occurrence of an event like “Status Updated”. A Contract event such
as adding of new party may trigger several database operations. Similarly, new
activity may trigger several insertions or updates across the tables. The contract
events will be caused by the actions in the execution of the contracts. A contract event
may lead to several database events, however database event can occur independent
of contract events. Suppose, when an address of a party in the contract is changed (a
database event), it is not a contract event since it will not effect the execution of the
contract. In the Figure 1, we use ER-R model to model an event.
Some of the contract events in the meta-schema are contract completed,
subcontract made, subcontract over, new party joined, activity started, activity
completed, party violates clauses, activity deviates from clauses, activity updated,
 A Frame Work for Modeling Electronic Contracts 197

activity requires more budget, Payment initiated, payment made, role added and role
updated, synchronization of activities not followed.
The event is defined as below:
<event> ::= <contract_event> | <database_event> |
<temporal_event> | <external_event>

<composite-event> ::= <event> AND <event>

<contract Event> ::= started <contract_object> attempted
| completed <contract_object> attempted
| deviates <CLAUSES> attempted
| <ACTIVITY> synchronization attempted
| update <contract_object> attempted.

The database events are associated with data objects (<data_object>), and
<database_event> is defined as in [TNCK1991]. In the above definitions,
<contract_object> and <data_object> can be an entity set or a relationship set, and
<attribute> is an attribute of a <contract_object> or <data_object>. Further, both
contract events and database events can have more events than those specified above.
A temporal event is a time-based event, which could be relative (20 minutes after
contract starts) or absolute (at 3.00 PM). An External event could be, for example, a
document arrived.
Exceptions in a contract are mainly due to the deviations from the clauses defined
in the contract. Some of the exceptions in the meta-schema are shown in the Table 1.

Table 1. Exceptions in the meta-schema for e-contract

(i) Exception_name: Addition of new party
Event: Insert a new party attempted
Condition: New party can not be added during the execution of a contract
Action: Reject the request
(ii) Exception_name: Role Changes
Event: Update the role of a party attempted
Condition: Change of role violates the clauses.
Action: Allowed (ROLE updated); Not Allowed
(iii) Exception_name: Budget over
Event: Total amount in the budget is over attempted
Condition: Expenditure exceeds the budget
Action: Stop work; allocate more budget (BUDGET updated)

2.2. EREC Meta-schema Template

The EREC meta-schema can be treated as a template of an EREC model for e-contracts.
Because an e-contract has a fixed set of relationships that are commonly held over
various entities within the conceptual model for an e-contract. For example, the “has”
relationship among the entities contract, parties, clauses and activities will mostly
exist in a conceptual model for an e-contract. That is:
A. E-contracts are standardized with some parametric inputs required at
specification time for a new e-contract.
B. There are many fixed entities and relationships in an e-contract.
198 Kamalakar Karlapalem, Ajay R. Dani, and P. Radha Krishna

C. Additional flexibility is accommodated by customizing the e-contract instance

with more relationships and entities specific to an e-contract being modeled.
D. There is a mix of entity types and entities (representing instances) co-existing
in an EREC model. This is a special feature of this model that is used in
translating an EREC model to a set of workflows.

2.3. Workflow Meta-schema

Workflow is automation of a business process. Workflow Management Systems
(WFMS) have been extensively used in businesses to design, execute, and monitor
processes [G+1995]. It provides an efficient environment for collaboration,
coordination and communication among agents - people and software programs - to
complete activities in a particular order and with certain rules, procedures and
constraints.
Fig. 2 illustrates a typical workflow meta-schema [WfMC1995]. Note that
workflow is same as an activity, and an activity of a workflow is same as a task as
proposed in activity management system [KYH1995]. A reference to an activity
should be clear based on whether it is a part of a workflow or an independent activity.

Workflow
Type Definition

may consists of has

refer to
Role Activity uses Workflow
Relevant data

may
have
uses

Invoked Application
Transition
conditions may refer to

Fig. 2. A typical workflow meta-schema

2.4. Differences between the Meta-schemas for E-contract and Workflow

In sections 2.1 and 2.3, we presented the meta-schemas for e-contract and workflow.
These two models combined together helps in the implementation of an e-contract,
thus a mapping between the two models has to be performed. Unfortunately, the
mapping may lose some semantics when transforming from a "semantically richer"
EREC (explained in Section 3) model to a workflow. Therefore, the workflow model
has to be augmented with a database for storing additional information about parties,
clauses, contracts, and any other related data and business processes.
In general, a contract contains a number of clauses, and any deviation from a
clause violates the contract. It is required that each clause should be monitored
continuously during the entire contract process. Activities are the actual work
elements in a contract. A contract consists of large number of activities, and each
 A Frame Work for Modeling Electronic Contracts 199

activity, in-turn, consists of multiple inter-dependent tasks that need to be

coordinated, scheduled and executed. Also, there must be dependency checks among
various activities.
The meta-schema of a contract shows exceptions, which occur frequently during
the contract process due to the unanticipated possibilities, deviation from clauses, and
a violation from contract law. Exceptions may occur asynchronously or occur in
scattered places in a contract process (e.g., budget over), and these cannot be directly
handled by explicit rule based processing such as IF-THEN-ELSE constructs. Thus,
there is a requirement for extra constructs and semantics in a workflow meta-schema
to address the exception modeling and management. In addition, the complexity
arising due to large number of relationships among the entities shown in e-contract
meta-schema cannot be handled with current commercially available WFMSs or
research prototypes. Therefore, after mapping an EREC schema to a workflow,
additional applications may need to be written to monitor and enforce e-contracts.
Otherwise, workflow systems need to be enhanced to handle e-contracts. In this
paper, our focus is on modeling e-contracts and developing a methodology for
translating an e-contract conceptual model to an implementation level workflow or
activity.

3. EREC Model
In our approach, we describe an EREC model as an extension of ER-R [TNCK91]
model, to bridge the gap between the complexities in E-Contracts and Workflow
process. The conceptual schema in the EREC model is represented by an EREC diagram
(Figure 1.). An EREC model has the following constructs for modeling e-contracts:
1. Contracts – A contract is a legal agreement between multiple parties.
2. Clauses – A contract consists of many interdependent clauses that need to be
fulfilled.
3. Activities – A clause is fulfilled by successfully executing one or more
activities.
4. Parties – An activity is undertaken by one or more parties.
5. Exceptions – Exceptions model deviations from fulfillment of contracts.
The above five constructs form the core of EREC model. First, an e-contract is
conceptualized from the requirements collected by the user. Once it is conceptualized,
it is presented as a single EREC model. After that, the clauses within e-contract need to
be fulfilled while executing one or more activities. Each activity is handled by one or
more parties. Therefore, in an e-contract, the actual work done is modeled by
activities. Many times, an activity fails triggering a violation of an important clause in
a contract. This gives rise to an exception that needs to be handled by further
augmenting activities with exception handling process. We illustrate an EREC model
for an “Investment” example in the next subsection.

3.1. Investment E-contract - Example

Suppose, Financial Institution (FI) in a country has different types of investment
schemes, and some of the schemes are opened for a short period, and other schemes
for a longer period. The FIs periodically issue Bonds or Securities for fixed amount in
200 Kamalakar Karlapalem, Ajay R. Dani, and P. Radha Krishna

which individual investors or the institutional investors can invest (i.e. Bond holders).
The payment of interest, which is promised in advance, may be done electronically or
through paper instruments.
When an individual/institution invests the amount with FI, they enter into a
contract. The terms and conditions of the operation of Bond or security are defined by
FI. It has to periodically pay the interest and must return the amount to the holder
after the period defined in the contract is over. The investors will be making initial
payments through bank. The FI will be periodically paying interest through banks.
Here, the contract and subcontracts involved are:
1. FI and Banks/agencies for accepting the Application Form and initial amount
from Investors and sending the Application Forms to FI and collected amount
to the account of FI (with FI’s own bank).
2. FI and Banks (in some cases may be different from 1) for periodic payment
of interest/warrant/dividend.
3. Among banks for inter bank funds transfer
4. Bank and investor – investor being the account holder of the bank
5. FI and Investors
6. Among the investors for the transfer of ownership
7. Agencies and banks for transfer of funds
In above case (5) is the main contract relevant to our example and others are sub
contracts. However, the sub contracts listed in (3) and (4) can exist irrespective of
main contract. The contract at (7) is required, if there is a contract between FI and
agencies (i.e. not banks). In this case, there has to be another sub contract for the
transfer of funds. The clauses in the main contracts will be as indicated by the FI at
the time of notification. Table 2. and Table 3. shows some clauses and activities in the
“investment” contract respectively. Table 4. shows some of the rules defined in the
meta-schema for the present example.

Table 2. Some clauses in “investment” contract

CL-a. Who can invest (like say citizen of the country and or institutions), how they can
invest (like say singly, jointly etc.)
CL-b. Minimum Amount, Maximum Amount and Other restrictions Maturity Period
CL-c. Promise of return, mode and periodicity of interest payment etc.
CL-d. Other conditions like whether Transfer of ownership allowed, Pre-mature withdrawal
allowed or not, reinvestment in other schemes allowed or not etc. and penal clauses
like payment of additional penal interest in case the interest is not paid in time.

Figure 3. shows the schema for the contract in our example. In the Figure 3, the
“instance” level information is co-existing with conceptual level information. That is,
in the case of Parties, FI is a particular instance of entity Party. But we show it as a
specific entity (object) in the entity type “Parties”. This feature is very much needed
to model e-contracts, because the information captured at the instance level of an
entity is different from other instances of the same entity type due to its specific
behaviour in a contract. For example, the information captured for the Party instance
FI is entirely different from the Party instance Investor. This feature is also a feasible
solution because of small number of entities involved in each entity-type. In other
words, the EREC meta-schema is a template for modeling e-contracts.
 A Frame Work for Modeling Electronic Contracts 201

Table 3. Some Activities of FI, Investors and Banks in “Investment” contract

Activity FI Activity Investors
1. Issuing notification for 1. Submit the signed and completed application and pay
bonds/security the amount
2. Entering into an agreement 2. Get notification
with banks/agencies for 3. Hold the Bond/Security till maturity or carry out
acceptance of application allowed operations like Transfer, pre mature
forms and amount. withdrawal etc.
3. Receive Application forms 4. Tally the periodic interest received
and funds, scrutinize Activity Bank
applications, pass accounting
entries, allot bonds/ securities 1. Receive Application Form and Amount
to investors, return the 2. Send Applications to FI and collected Amount to
amounts for rejected FI’s Bank
applications and unallotted 3. FI’s bank will credit the amount collected to FI’s
amount, issue bonds and Account
certificates, send acceptance 4. FI’s Account will be debited for periodic interest and
notifications to holding repayment, the amount to be transferred to different
agencies and investors, bank accounts.
periodically pay the promised 5. Transfer the interest and amount received to the
interest, repay or reinvest in investor’s account.
new scheme, etc.

Another interesting feature of EREC model is the relationships between the

instances of entities. These relationships are in addition to the relationships between
entities. That is, for example, consider the relationship between Activity instances
“Submission” and “Fund-Receipt & Info. to FI” and Parties instance “FI” and
“Investor”. Here, the relationship is between the instances of entity types Activities
and Parties. The investor submits an application for a bond through a bank/agency.
The bank/agency receives the application and the required amount, and sends the
information to FI. These low-level relationships among the instances of entity types
will help to conceptualize the e-contract and facilitate translation of EREC model to
workflow.

4. Mapping EREC to Workflow Specification

The mapping of EREC model to a workflow is done as follows:
Step 1. All parties are mapped to agent types/roles.
Step 2. Activities to workflows and activities in a workflow.
Step 3. Contracts to events that occur.
Step 4. Clauses to conditions that need to be satisfied.
Step 5. Exception handling to additional activities in a workflow.
Step 6. Payments and contracts to documents and additional input/output events.
The above steps for mapping an EREC model to a workflow needs to be carried out
to facilitate an instantiation and execution of an e-contract. The steps are based on the
relationship among various constructs in EREC model. Therefore, first, parties need to
be mapped to agents that perform (are responsible for) various activities. Second, the
activities themselves need to be mapped to a workflow. This may require additional
202 Kamalakar Karlapalem, Ajay R. Dani, and P. Radha Krishna

Activities
(A1,A2,A3, A4)

Submission Contract
A1 Sub Contracts

Fund Agreement
Receipt &
Info. To FI
Investment have
Bank
Scrutiny Customership

A2
Inter-Bank
Allotment

Periodic
Repayment Clauses

has CL-a
Maturity
Repayment
CL-b
have
Parties
A3 Change
Ownership CL-c
Payments
Funds ∪
A4 Transfer CL-d
FI
Agency

Investor
Bank refer

Invalid No Invalid Hold

Sufficient Account
Balance Details Resend
Again
R Send
Reject Wait Clarification Exceptions

Relations between entity types Contract Events

Relations between instances of Output events for exceptions
different entities Input events for exceptions

Fig. 3. A Meta-Schema for E-Contract

business processes to be specified. For example, the activity scrutiny may require a
new business process in a FI to be specified. This Scrutiny workflow may require
additional agents to be involved in the execution. Third, the contracts and clauses are
 A Frame Work for Modeling Electronic Contracts 203

mapped to events that need to occur to intimate the satisfaction of a clause or

completion of a (sub-)contract. Note that these additional events need to be modeled
and specified in the workflow. In case some of the clauses are not satisfied exception
handling will take over the processing of a contract. This exception handling may
require additional activities (depending on clauses) to be added to the workflow.
Payments are also treated as clauses that need to be satisfied. It should be noted that
this mapping only handles the “workflow support component” required to execute an
e-contact. Additional databases and other “human-supported” activities and business
processes need to be specified for the implementation support for e-contracts. Further,
EREC model’s main objective is to facilitate conceptual understanding of
dependencies within an e-contract and their mapping to a workflow.

Table 4. Rules of “investment” contract for EREC model

Rule_Name : Allot_Bonds_To_Investors
Triggering_event : Amount_Received and Application_Scrutiny_Successful
Condition : Decide upon the Bond Allocation policy.
Action : Return the remaining Amount if the Face_Value of Bonds
Rule 1

allotted is less than paid amount.

Resultant_Event : {Allot Bonds, Return Amount, Inform_Depository}
Suppose that investor has applied for Bonds of face value say X and he has paid
amount Y (>X) then the amount (Y-X) is returned. The information is sent to the
depository.
Rule_Name : Pay_Interest
Triggering_event : Due_Date
Condition : There should not be any hold on interest payment
Action : Calculate the interest payable and credit it to the investor’s
Rule 2

Account
Resultant Event : {Calculate Interest Due, Amount_Transfer, Bank_Transfer}
The interest will be calculated and the amount will be transferred to the Account of
the Customer
Exception : Not able to credit – Incorrect_Account_Info, Interest cannot be paid
Rule_Name : Transfer_Bond
Triggering Event : Transfer
Rule 3

Condition : There should not be any hold on transfer of ownership

Action : Update the Holder Database
Resultant Event : {Get_New_Act_Details, Change_Holder}
The bonds will be transferred to new holder. Transfer will change the ownership.
Exception : Transfer not allowed
Rule_Name : Repay_Bond
Triggering Event : Maturity_Period_Over
Rule 4

Condition : There should not be any hold on repayment

Resultant Event : {Calculate_Amount, Transfer_Funds}
Exception : Reinvest in new scheme, Not able to Repay, Incorrect Account
details
Rule_Name : Pre_Mature_Closure
Triggering Event : Holder_Request
Rule 5

Condition : There should not be any hold on pre-mature withdrawal

Resultant Event : { Calculate_Amount, Transfer_Funds}
Exception : Premature withdrawal not allowed , Incorrect Account details
204 Kamalakar Karlapalem, Ajay R. Dani, and P. Radha Krishna

First, the parties are mapped to agents as described in Table 5. In Figure 4, we

show how the activities A1,A2, A3, and A4 are mapped to workflows A, B, C, and D,
respectively. In Figure 5, we augment workflows B and D with exception handling
based on exceptions in Investment EREC model.

Table 5. Mapping of Parties to Agents

Workflow Parties Payments (sub-)contracts
1 Investor, Bank, Investor -> Bank Customership
agency, FI Bank/Agency Inter-Bank
Bank/Agency -> FI
2 FI, Investor, FI -> Investor Agreement, Bank Customership
Bank Inter-Bank
3. Investor, FI Investor -> Investor Agreement
4 Bank Bank -> Bank Inter-bank

After specifying the workflows, they can be incorporated at various parties for
supporting e-contracts. For example, workflow A enables an investor (say, Rama) to
submit a requisition to buy some ICICI bonds from Citibank. At Citibank, the
workflow A will enable relevant information, documents and payments (through his
account in Citibank) to be provided by Rama. Further, workflow A will transmit the
documents to ICICI and the payment is transferred from Citibank to ICICI. After that,
workflow B is initiated at ICICI to scrutinize and allot the bonds to Rama. Once
Rama is allotted the bonds, Workflow D is initiated at ICICI to transfer funds to
Rama’s account in Citibank, either periodically and/or at maturity time based on the
contract. In case, Rama is interested to sell the bonds to another investor, (say, Sunil),
the workflow C enables Rama to transfer the ownership of his bonds to Sunil. Here,
the workflow C is initiated by Rama and the transfer takes place at ICICI.

Start Submission Fund Receipt Fund End

& Info. To FI Transfer
(a) Mapping Activity A1 to workflow A

Scrutiny
Start Periodic Maturity Fund
repayment Payment Transfer

Allotment Fund
End
Transfer
(b) Mapping Activity A2 to workflow B

Change Fund
Start End Start Transfer End
Ownership

(c) Mapping Activity A3 to workflow C (d) Mapping Activity A4 to workflow D

Fig. 4. Mapping Activities to workflow

 A Frame Work for Modeling Electronic Contracts 205

Start Invalid Hold

account
Allotment Periodic details
Scrutiny repayment Resend
Again

Fund Maturity Fund

Invalid Transfe Payment Transfer
Reject
End

(a) Augmenting Invalid and Invalid account details exceptions to workflow B

Fund End Wait
Start
Transfer

No sufficient Send
balance clarification

(b) Augmenting No sufficient balance exception to workflow D

Fig. 5. Augmenting exceptions as additional activities to workflow

4.1. Discussion
E-contracts are complex and difficult to understand and facilitating an implementation
of e-contracts is not straightforward. Therefore, we have developed a modeling
framework for e-contracts, namely EREC data model and illustrated an investment
EREC model and its mapping to a workflow. The points that need to be noted are:
1. The EREC model is a natural way for modeling e-contracts. The important
aspects namely, clauses, activities and parties can be easily conceptualized and
their relationships can be modeled.
2. Exceptions to clauses are integral part of e-contracts which needs to be modeled
carefully. In EREC model, we provide facilities to link up contracts, activities
and exceptions are modeled using rules.
3. A methodology is developed to map an e-contract to many workflows that need
to be executed by various parties involved in the contract. Thus, EREC model is
one of the first models to facilitate conceptual modeling of cross-organizational
e-contracts that are implemented by cross-organizational workflows.
4. The meta-schema for e-contracts can be augmented to include additional e-
contract requirements such as authorization and delegation.

5. Related Work
In the recent years, the research on E-Commerce and related areas made it a challenge
to do business electronically. This is mainly due to the increase use of Internet and
web driven business processes. The Domain Task Force established by OMG
produced a working version of the electronic commerce reference model [O1997].
This model is largely based on the results of OSM ( An Open Service Model for
206 Kamalakar Karlapalem, Ajay R. Dani, and P. Radha Krishna

Global Information Brokerage and Distribution) project [I1998], in which a

framework was created for the electronic commerce. Jenny Hands et. al [H+2000]
presented an architecture for electronic brokerage, and describes a reference model
and functional architecture for value-added mediation in electronic commerce. A
three level framework using Intelligent agents is presented in [LH2000] to support
electronic trading.
In [GSG2000], a framework for legal e-contracts is developed, but a mechanism
for modeling e-contracts is not provided. In [S1980], a contract net protocol is
described for structuring contractor and subcontractor market places. A declarative
approach to business rules in e-commerce contracts in [G1999] by combining CLP
(Courteous Logic Program) and XML. Kersten and Szpakowicz presented modeling
business negotiations for electronic commerce using software agents [KS1998]. In
[LS1997], a detailed comparison of various workflow metamodels is discussed. But
there has been no work on conceptually modeling e-contracts and developing a
methodology for mapping an e-contract to workflow. In [TNCK1991] a modeling
framework for rule processing and ECA triggers in active databases was developed.
This work facilitated conceptual modeling of active databases. In this work, we build
on it to develop a novel framework for conceptually modeling e-contracts. Further, in
[CKL2000] a framework for e-services is developed as an application built on top of
workflow systems. That is, it advocated the idea that the implementation vehicle for
e-services is workflows. Along the same lines, we in this paper showed how
conceptually modeled e-contracts are mapped to workflows.

6. Conclusion
In this paper, we focused on the framework for modeling an e-contract. The meta-
schema for electronic contracts is presented and illustrated with a simple example. We
proposed an extension to ER model called EREC model to represent the complex
inter/intra relationships among entities in an electronic contract. We illustrated the
utility of this EREC model through a detail example. The salient feature of the EREC
model is the seamless conceptualization of “instances” and constructs, and
relationships among them. This advocated the notion of an EREC model to be a
template for a class of e-contracts to be supported by a set of parties. In this case, a
particular e-contract may involve some of the parties to engage in fulfillment of the e-
contract. For example, in the “Investment” EREC model, for a user Rama, the parties
involved were Citibank and ICICI and the e-contract was among them. Thus, the
notion of conceptual model as a template instantiated at run-time is proposed.
Further, we showed how an e-contract is mapped to a set of workflows that can be
executed by different parties. A detailed methodology for this mapping has been
provided along with an illustrative example. Overall, in this paper we focused on
modeling e-contracts and mapping it to workflows. We are currently working on
developing a toolkit for EREC data model and facilitate its mapping to workflows in
commercially available workflow management systems.
 A Frame Work for Modeling Electronic Contracts 207

References
[CKL2000] Dickson Chiu, Kamalakar Karlapalem, Qing Li. E-Adome: A framework for
enacting e-services, Workshop on Technologies for E-Services (VLDB workshop), 2000.
[G1999] B. N. Grosof, A declarative approach to business rules in Contracts: Courteous Logic
Programs in XML, Proceedings of the 1st ACM Conference on Electronic Commerce (EC99),
Denver, Colorado, USA, Nov. 3-5, 1999.
[GHS1995] Dimitrios Georgakopoulos, Mark F. Hornick, Amit P. Sheth: An Overview of Workflow
Management: From Process Modeling to Workflow Automation Infrastructure. Distributed and
Parallel Databases 3(2): pages 119-153 (1995).
[GSG2000] M. Gisler, K. Stanoevska-Slabeva, and M. Greunz, Legal Aspects of Electronic
Contracts, in CAiSE*00 Workshop of Infrastructures for Dynamic Business-to-Business Service
Outsourcing (IDSO'00) Stockholm, 5 - 6 June 2000.
[H+2000] Jenny Hands, Mikhail Bessonov, Mike Blinov, Ahmed Patel and Ron Smith, An inclusive
and extensible architecture for electronic brokerage, Decision Support Systems, 29, 305-321,
2000.
[I1998] Infowin ACTS Project 1998, Information Brokerage, Deutshe Telekom Berkom, Berlin.
[KS1998] G. E. Kersten and S. Szpakowicz, Modelling business negotiations for electronic
commerce, Proceedings of the 7th workshop on Intelligent Information Systems, Warsaw: IPI
PAN, 1998, 17-28.
[KYH1995] Kamalakar Karlapalem, Helen P. Yeung, Patrick C. K. Hung: CapBasED-AMS - A
Framework for Capability-Based and Event-Driven Activity Management System. CoopIS 1995:
pages 205-219.
[LH2000] Ting-Peng Liang and Jin-Shiang Huang, A framework for applying intelligent agents to
support electronic trading, Decision Support Systems, 28, 305-317, 2000.
[LS1997] Yu Lei and Munindar P. Singh, A comparison of workflow metamodels, Proceedings of
the ER'97 Workshop on Behavioral Models and Design Transformations: Issues and
Opportunities in Conceptual Modeling, 6 - 7 November 1997, UCLA, Los Angeles, California.
[O1997] OMG/CommerceNet 1997, Joint Electronic Commerce Whitepaper. OMG Domain
Technical Committee, Monreal ( http://www.osm.net/upload/97-06-09.pdf)
[S1980] R. G. Simith, The contract net protocol: High Level Communication and Control in a
Distributed Problem Solver, IEEE Transactions on Comp[uters (29;12), December 1980, 1104-
1113.
[TNCK1991] A. K. Tanaka, S. B. Navathe, S. Chakravarthy and K. Karlapalem, ER-R: An
enhanced ER model with situation-action rules to capture application semantics, in ER
1991: pages 59-75.

View publication stats