Fillable Printable Business Contract for B2B

Business Contract for B2B

Session 4: Electronic Contracts

Business Contracts for B2B

Andrew Goodchild, Charles Herring and Zoran Milosevic

Distr ibuted System T echnology Center (DSTC)

Level 7, GP South, The University of Queensland, QLD, 4072, AUSTRALIA

E mail: [andrewg, herring, zoran]@dstc.edu.au

Web: http:// www.dstc.edu.au

Abstract

This paper presents an approach for the

specification and implementation of business

contracts needed for Business-to-Business (B2B)

services. We first examine typical elements of

business contracts and their usage. This analysis

sets a foundation for 1) modeling contracts and 2)

developing a role-based architecture that supports

typical operations in the contract’s lifetime. We

explore how contracts can be encoded in XML and

present an approach for monitoring and enforcing

of contracts. This approach provides a flexible way

of modifying rules of enforcement, as trading

arrangements change. A real-world contract

example is used to illustrate the concepts described.

1. Introduction

Many enterprises are eager to take advantage of the

emerging "Internet Economy". Internet based

commerce offers more potential than just online

storefronts (a.k.a. Business-to-Customer (B2C)) and

auction sites (a.k.a. Customer-to-Customer (C2C)), it

also offers opportunities in Business-to-Business

(B2B) e-commerce. B2B covers the area of online

exchange of information between trading partners.

Some exa mples of B2B include:

•

Trading partner integration between enterprises,

forming supply and value chains and allowing

automated coordination of business operations

(e.g. order management, invoicing, shipping and

government procureme nt).

•

Business process integration. Integration of

commerce sites, Enterprise Resource Planning

systems and legacy systems.

• Business-to-business portals enabling formation

of trading communities, electronic catalog

management, content syndication, and post-sale

customer management. Example sites include

www.mySAP.com, www.I2I.com and

www.ariba.com.

A fundamental issue faced by many developers of

B2B systems is how to ensure that you can trust a

party that you are dealing with at arms length. The

primary mechanism for doing this is by setting up a

business contract and depending on the law to enforce

the terms of the contract. The aim of this paper is to

provide mechanisms to facilitate electronic business

contracting. This involves support for electronic

contract representation and also support for various

contract operations. Typically, these include contract

negotiation, validation, signing, tracking, monitoring

and enforcing contract ter ms and conditions

Section 2 starts this paper off by stating the

requirements for business contracts in the context of

B2B. Section 3 outlines a role-based architecture to

support typical contract operations. Section 4 explains

how XML can be used for the specification of

business contracts. Section 5 presents an approach of

using BizTalk technology to support the monitoring

of business contracts. Section 6 concludes the paper.

2. Busi ness Contr acts for B2B

A contract is a legally enforceable agreement in

which two or more parties commit to certain

obligatio ns in return for certain rig hts [R89 ] . In a B2B

context this can range from a simple one-page

purchase order for the sale of goods, to an extremely

complex thousand-page document for a trade level

agreement b etween multi national businesses.

In general, most B2B scenarios can be generalized to

a 5-phase trading process, of which contract

formatio n is one phase [C93]:

• Pre-contractual phase: customers identify

products or services and possible sources of

supply;

• Contractual phase: creation of a formal

relationship between buyer and seller, covering

contract nego tiation and validation op erations;

• Ordering and Logistics phase: placing of

purchase order, delivery of goods and services;

Session 4: Electronic Contracts

•

Settlement phase: invoicing, payment

author ization and payment; and

•

Post-processing phase: gathering information for

management reports, e.g. trad e statistics.

The focus of this paper is on the contractual phase

and in particular supporting electronic contract

representation and contract monitoring and enforcing

operations.

2.1 Elements of a Business Contract

There are up to four elements needed to create a valid

business contract [R89]. First, an agreement has to be

reached on all essential conditions of the contract.

The second element is the notion of consideration.

Each party establishes the obligation to give

something to each other. Consideration can take the

form of money, services rendered, property or

individ ual rights. The third element is t hat of capacity

(or competence): ensuring that parties entering into

the contract are lawfully capable of agreeing to

contracts (e.g. whether an individual has the authority

to represent their organization). Finally, the legal

purpose of the contract must be established. A

contract cannot be enforced unless the actions agreed

upon are legal in the jurisdictio n where the contract is

mad e .

In general, each of these elements will appear in a

business contract as clauses covering [FL96]:

•

The description of parties involved, including:

na mes, addresses, roles etc;

•

The definition and interpretation of terms used in

the contract;

•

The jurisdiction under which the validity,

correctness, and enforcement of the contract will

operate;

•

The duration and territory

of the contract, which

defines the ti mes and places at which t he contract

is in force;

•

The nature of consideration e.g. fees, services

rendered, goods exchanged, rights granted, etc;

•

The obligations associated with each role, which

is expressed in terms of the criteria over the

considerations. This includes terms and

conditions for invoicing and payment such as

warranties, delivery, liability, rejection,

ter mination and accounting provisions.

Note that the te rritory of a contract refers to what

geographical areas the contract covers. Whereas the

jurisdiction of a contract refers to which locatio n’s

laws the contract is subject to. For example, the

territory of a contract may co ver all trade bet ween

two parties in Brisbane, and the jurisdiction may be

covered by the la ws of the State of Queensland.

A sample contract illustrating these elements is

provided in appendix A.

In the context of B2B, many of the terms and

conditions in the contract will form part of the

software requirements that specify behavior of a B2B

system. For example, terms and conditions associated

with invoicing and payment will dictate what forms

of electronic invoices are acceptable, when the y are to

be received, and how the payment is to follow. There

will also be ma ny terms a nd conditions t hat ca nnot b e

implemented (or are only partially automatable) and

would require human actions and interventions.

2.2 Standardizing Contracts

In some business environments, such as insurance,

cargo, real estate and banking, it would become

highly complicated and costly if the terms of every

contract had to be newly settled for each transaction.

Significant savings can be achieved by reusing

standard for m contracts for newly established contract

agreements [T95]. The terms of such standard

contracts can be dictated by one party (e.g. the seller)

or by a third party (e.g. in Queensland the Rental

Tenancy Authority sets out a standard lease

agreement for all leases in Queensland). Standard

form contracts are also available for a fee from

commercial organizations

, which will provide

general-purpose contracts for many business

situations.

In some instances, new contracts can include standard

contract clauses [FL96]. For example, some large

institutions, like universities and government

departments, may outline policies on standard

contract clauses to be included in all contracts of a

certain nature. In some cases standard contract

clauses are defined by a standards body and are in use

between many businesses. For example, the

International Chamber of Commerce (ICC)

has

outlined a set of "Incoterms" for use in specifying

departure, shipment and arrival terms in international

sales contracts.

In terms of B2B, standard form contracts are

essential, as they allow business to confidently

operate at arms length. A business can deal with

another business without the need to negotiate a new

contract for each transaction. Furthermore, the

standardized nature and the regular use of standard

form contracts means that many elements are stable

enough to be implemented as components in a B2B

for example: http://www. legaldocs.com/

http://www.iccwbo.org/

Session 4: Electronic Contracts

system. Finally, as many standard form contracts

share similar elements and contract clauses, there

exists the possibility to reusing components in

different B2B systems.

2.3 Support for electronic contracting

operations

The discussion in the above subsection suggests that

the availability of electronic representation of

standard contract forms and clauses can bring

significant savings to the process of creating and

negotiation contract terms. Electronic contract forms

can be stored in an electronic repository that can be

subsequently accessed and used by businesses to

facilitate the definition of their mutual obligations.

It is important to note however that by electronic

contracting we do not only mean an electronic version

of contract forms but also a wide range of

possibilities related to the automation of the typical

contracting procedures or processes such a s:

•

location of suitable contract templates and/or

contract clauses,

•

electronic negotiation of contracts,

•

electronic signing of a contract, and having this

as an evidence of the agreement; this can bring

significant savings, in particular in cases where

contracts involve multiple, geographically

distributed trading partners, such as those related

to international co ntracts,

•

electronic tracking - This allows timely reaction

to some important deadlines such as contract

termination, thus making it possible to re-

negotiate a subsequent contract and put it in

place, before or immediately after the existing

contract terminates.

•

monitoring of the behaviour of the trading

partners who have entered in contractual

relationship and, possibly,

•

enforcing behaviour of trading partners so that

their contractual operations are met.

2.3 Legal Enforceability of B2B

Contracts

An essential element of trust in a B2B system is the

legal enforceability a contract. In order to create

certainty for electronic contracts, legal groups, such

as American Bar Association (ABA), have

established several rules for enforcement of a

contracts in the B2B area [W94]. These rules cover

issues such as fraud, transmission and receipt of

messages, evidentiary concerns, prior terms and

conditions, and liability due to failures or

malfunctions. Discussion of these rules and their

implicatio ns is out of the scope of this paper.

3. Key Contract Related Roles

for B2B Applications

Based on the above requirements for business

contracts in B2B systems, we have identified the

basic roles needed to support typical operations

associated with contract establishment, monitoring

and enforcement [MB95, MAL96]. These roles are:

The Contract Repository (CR) is needed to store

standard for m contracts and standard contract clauses.

The Notary is used to store signed instances of

standard form contracts which, can later be used as

evidence of agreement in contract monitoring and

enforcement activities.

The Contract Monitor (CM) enables monitoring of

the activities of parties by measuring their

conformance to contractual terms and conditions and

signals the contract e nforcer if it detects a violation.

The Contract Enforcer (CE), upon being signaled by

the CM, performs enforcing actions such as sending a

message to various parties informing them of the

violation and possibly preventing further access to the

s ystem b y non-conforming parties.

The Contract Validator (CV) ensures the creation of

legally valid contract instances by checking the four

aspects of contract validity (disc u ssed in 2.1):

•

Competence. To accomplish this, the CV verifies

the capacity of parties willing to enter a

co ntractual rela tionship.

•

Clarity. In most cases the contract semantics will

be unambiguous if it is derived from a template

in the CR. The CV can be used to provide

add itional checkin g if needed.

•

Legal purpose. The legal purpose of a clause or

contract can be validated based on information in

a reposito ry of legal rules.

•

Consideration. The CV can ensure the contract

contains contract elements describing what is

exchan ged bet ween the parties.

Some elements of contract validation are very

difficult for a computer to perform. For example, the

clarity and legal purpose elements are very difficult to

model and verify. Attempts have been made in the

area of deontic logic, however, this work is still

preliminary [TT98]. One approach to address this

problem is to establish some systems of credentials

Session 4: Electronic Contracts

that would guarantee legal validity of contract

templates.

Some elements of contract validity are possible to

automate, such as checking the consideration aspects

(by inspecting signed contract instances) and

competence aspects (by enforcing rules for signing

contracts by people with the legal authority to do so,

as discussed in [MAL96]).

The Contract Negotiator (CN) is an optional role that

can be used to mediate the negotiation of contracts in

the pre-contractual phase. Automated contract

negotiation is another area with significant challenges

as much of this work requires reasoning about the

effect of obligations outlined in a contract and then

negotiating based on this. Some attempts to solve

related problems have been made in the area of

intelligent agents [S96].

4. Use of XML technology to

support contr acts

Based on the analysis of contracts presented in

section 2.1, we have defined a model for contracts.

The model (shown in figure 1) for a contract is

broken down into the following elements:

•

A preamble which outlines the parties involved

in the contract and the nature of the

consideration;

•

A list of contract clauses, clustered in logical

groups. In some cases, a contract clause itself

may be a pointer to a standard contract clause

provided by an external institution;

•

An approval section which enumerates whom

from each party approved the contract; and

•

A digital signature section with d igital sig natures

fro m the appropriate parties listed in the approval

section; and

•

Finally, a separate section contains a list of policy

specifica tions stating contract enforcement rules

according to the agreed contract clauses. This

aspect will be explained in detail in section 4.2.

4.1 Describing Contracts

In this paper, we will be encoding this model using

XML. Given the textual nature of business contracts,

XML is the logical choice for capturing the structure

of a contract while preserving the text of the contract.

Furthermore, essential pieces of emergent XML

infrastructure can be used to advantage, namely:

CBL, XML-DSig, XSLT, and XML repositories as

will be discussed in the following sections.

Figure 1: Element s of a business contract template

Session 4: Electronic Contracts

4.1.1 Use of CBL

Common Business Language (CBL), devised by

Co mme rc e O ne

defines a set of XML documents and

XML building blocks that enable businesses to

assemble e-commerce applications quickly. CBL has

made important contributions to CommerceNet’s

ECO

semantic recommendations and is available in

the emerging XML.org and Biztalk.org repositories

and the "electronic business XML initiative"

. CBL

provides a “document service architecture” enabling

the exc hange of:

•

Documents to send, reply to and check the status

of purchase orders;

•

Docu ments related to invoices;

•

Documents used to check the price and

availability of goods; and

•

Documents used to mainta in product catalogs.

Each of these documents is built out of smaller

elements, such as elements for customer details,

delivery information, product descriptions, names,

addresses, list of part numbers, prices, currencies,

countries, dates, etc. This is an important feature as it

already provides elements that can be reused in a

business co ntract specification.

CBL also provides the concept of a contract, which is

very brief and only includes a contract identifier and

start and end dates. In this paper we have taken the

CBL contract and extended it to include the additional

ele ments illustrated in figure 1.

Appendix B provides an example of a CBL-based

description of the contract introduced in Appendix

4.1.2 Other Related XML Technologies

T he standard form contracts are stored in the Contract

Repository. This can be implemented using any

number of existing XML-enabled repositories, such

as relational databases provided by Oracle, Informix,

Sybase and Microsoft. Specialized XML repositories

can also be used.

The agreed upon and signed contract instances are

stored in a Notary repository, which can be

http://www.commerceone.co m

http://eco.commerce.net

http://www.ebxml.com

Note that the sche ma for this XML docu ment has

not been included in this paper to conserve space. It is

available upon request.

implemented using the same repository

implementation c hoices as above.

The signing of contract instances can be facilitated

using XML-DSig compliant signatures. XML-DSig

is a digital signature standard currently being jointly

worked upon by the W3C and IETF. The use of such

signatures will prevent fraud by providing

mechanisms to guarantee integrity, authenticity and

privacy of XML documents. Further protection can

also be achieved by using a third party, such as

Verisign

, as a certificate authority to prevent the

tampering with of signatures by one of the parties.

Finally, to facilitate human user viewing of contracts,

an XML contract can be rendered in HTML by using

a transformation technology like XSLT

. This

implementation detail is beyond the scope of this

paper.

4.2 Describing contract policies

In this paper, the contractual terms and conditions are

modeled as a policy which specifies that a role is

either forbidden or obligated to perform actions under

certain conditions. Each of the contract clauses can be

regarded as a high-level policy statement. However,

these statements need to be further refined so that

they express constraints on the actions that parties

involved in contract need to fulfill – as a result of

their contractual obligations. These actions can then

be monitored, if required, and if they do not comply

with those agreed in the contract, then the Contract

Monitor can signal this non-performance to the

Contract Enforcer to perform an action on a specified

role.

The formulation of this policy system has been

influenced jointly by the Event-Condition-Action

(ECA) paradigm from active databases [UW97] and

the ODP enterprise language [SD99]. The core part of

the gra mmar for this policy system is for mulated as:

<policy> ::= <variable_declaration>*

when <condition>

must [not] occur where <condition>

otherwise <trigger_action>;

<action> ::= action( < ac tion _nam e>, <actor>,

<audience>, <time>, <body>)

<trigger_action> ::= trigger_action(<action_name>,

<audience>, <body>)

http://www.w3.org/Signature/

http://www.verisign.com/

http://www.w3.org/Style/XSL/

Session 4: Electronic Contracts

To illustrate the various pa rts of this grammar

consider the following policy statement:

P = Contract.Purchaser;

S = Contract.Supplier;

start_date = Contract.Commencement_Date;

price_list = Supplier.price_list;

when Contract.State == ’initial’

action(send_purchase_order, P, S, t1, b1),

must occur where

t1 >= start_date and

t1 <= (start_date + 7 days) and

validate_price_list(b1, price_list) and

validate_delivery(b1)

otherwise

trigger_action(send_notice_of_breach, *, "Purchaser

failed to send valid purchase order");

This policy statement encodes clauses 2.1, 3.1, 3.2,

4.1 and 7.1 in the contract in Appendix A. These

clauses collectively specify that a purchase order

must be sent within 7 days of the commencement of

the contract, otherwise a notice of breach will be sent.

The policy statement starts out by defining a number

of convenient variables, such as P, S, start_date, etc

that can be used throughout the policy statement.

These variables actually refer to values within the

contract. For example, the variable P is defined as

the purchaser within the contract.

The second part of the policy specifies when a policy

should be checked. In the example above the when

condition specifies that the contract is in its initial

state, i.e. no actions have occurred yet, it should be

checked. Note that for the when statement to be

effective the system needs to be able to query the

state of a contract. Therefore, the contract monitor

needs to maintain the state of a contract and make it

accessible for policy evaluation. Through the state

mechanism it is also possible to specify sequences of

actions that must occur by using a set of policy

state ments linked b y changes of state.

The third part specifies that an action called

send_purchase_order must be performed by an actor

called P (the purchaser) on an audience S (the

supplier) at time stored in the variable t1 with the

body of the message stored in variable b1.

The fourth part specifies that the action must occur

within 7 days of the contract start date and the body

of the purchase order must use the valid price list and

specify the delivery terms for the goods. Note that in

this section it is possible to specify that operations

may not occur.

The fifth and final part of the specification nominates

the action that must be triggered if this policy is not

met. In this case, a notice of breach is sent to both

parties informing them that the purchaser failed to

send a valid purc hase o rder.

4.2.1 Embedding Policies in XML

Policy statements can be embedded in XML. The

benefits o f do ing this are that additio nal an notations,

such as refere nces to clauses in the main contract can

be added. For example, the above policy could be

embedded as follows

P = Contract.Purchaser;

S = Contract.Supplier;

start_date = Contract.Commencement_Date;

price_list = Supplier.price_list;

when Contract.State == ’initial’

action(send_purchase_order, P, S, t1, b1),

must occur where

t1 &lte start_date and

t1 &gte (start_date + 7 days) and

validate_price_list(b1, price_list) and

validate_delivery(b1)

otherwise

trigger_action(send_notice_of_breach, *,

"Purchaser failed to send valid purchase

order");

</PolicyStatement>

</Policy>

… other policy statements …

</Policy>

</EnforcementPolicySpec>

Annotations to policies can be used later to help

diagnose the nature of the violation. For example, the

system could provide a user with the text of violated

clauses by follo wing the clause re ferences.

4.2.2 Open Issues

The policy specification language included in this

paper is our first step to wards developing a more well

Note that the sche ma for this XML docu ment has

not been included here to save space. This schema is

available upon request. Also note that it is possible to

define t he syntax of the policy language in XML.

T his has certain advantages in terms o f processing -

howe ver, we have not d one that here, as a textual

form is more readable.

Session 4: Electronic Contracts

defined language. There are a number of issues yet to

be considered including:

•

Expressiveness: Can most useful types of

policies be specified? What classes of polices are

difficult or impossible to express?

•

Modality: Currently only two forms of modality

are supported: must and must not. Should other

weaker forms of modality such as may or should

be supported?

•

Computability and Complexity: Can all

expressible statements be evaluated in a finite

time? Which classes of policy statements take an

unre asonable amo unt of time to e va lua te?

•

Conflicts: How do you detect and deal with

conflic ts bet ween policies?

•

Termination: Can we guarantee that if policies

cause other policies to be triggered that

eventually the system will reach a steady state

and no more p olicies will be triggered?

•

Confluence: Is the order of evaluation of policy

state ments relevant?

•

Practicality: Does the underlying B2B

infrastructure provide enough information to

enable polic y stateme nts to be evaluated?

In future work we hope to address some of these

issues by establishing a model and formal semantics

for this language, and then demonstrate its feasibility

through a n impleme ntation.

5. Implementation

Previously, we have implemented a prototype of

various business contract application roles using

standard CORBA technology [M95]. We are

currently in the process of porting it to component

technologies such as J2EE and Microsoft’s Windows

DNA. This paper reports on our work in progress

related to the use of DNA’s BizTalk

. We are

experimenting with the BizTalk technology as it

offers facilities to support rapid prototyping of B2B

specific services and utilities. These services are

COM+ extensions that use the underlying storage

(SQL Server), transport (HTTP, SMTP, MSMQ,

SOAP, etc) and formats (XML, HTML, EDI X12,

EDIFACT, etc) to build B2B systems.

The utilities

include: BizTalk XML Schema Editor to create and

modify XML schema specifications; a BizTalk

Mapper to provide data transformations; and other

administration tools, that provide control over

document flow, document tracking, business analysis

and troubleshooting.

In the following section, we will describe how the

role of a contract monitor can be implemented. Other

roles will not be discussed. Some roles such as the

contract repository and notary can be implemented in

a straightforward fashion using SQL Server. Other

http://www.microsoft.com/biztal kserver

Party A Party B

MSMQ

SQL -Server

(message archive &

contract state table)

SQL tri gge r s wh ic h

create messages

MSMQ triggers whic h

arc hive mess ages

Co ntrac t

Monitor

Manager

Figure 2:

Samp le Arc hit ec tur e

Policy

Statements

(in XML)

Session 4: Electronic Contracts

roles such as the contract negotiator and validator are

comp lex and are out of the scope of this paper.

5.1 Implementing a Contract Monitor

As illustrated in figure 2 the contract monitor could

be implemented by using some of the existing

BizTalk services. The central piece to this system is a

Contract Monitor Manager (CMM). The main role of

the CMM is to manage the various settings within the

SQL server and message queue. Over time as new

contracts are formed and old contracts are amended or

terminated each of these items will need to be added

to, updated and remo ved.

When the CMM receives a policy statement, the

CMM analyses the <action> section of each policy

and installs triggers on a message queue. As each

party communicates messages to one another using

the message queue, the triggers will search for

appropriate messages to be archived on an SQL

server.

Once a history of messages has been archived on the

SQL server, the sequence can be analyzed to

determine if the contract has been violated. This is

done in a two step process. First, triggers which are

designed to determine the state of the contract as

messages archive are created on the message archive,

This state is then stored in a contract state table. A

second set of SQL triggers are defined on the state

table and are based on the when <action> part of a

policy. When fired, these state-based triggers call

stored procedures, which inspect messages in the

message archive to determine their validity based on

the must [not] occur when <condition> part of the

policy statement. Finally, if the condition is violated

then the stored procedure raises a message on the

message queue based on the otherwise

<trigger_action> part of the policy.

Finally, note that one of the advantages of defining

policy statements in a declarative fashion is that it

enables us to separate policy specification from how

the applications are actually built. This means that it

should be possible to build a contract monitor for a

system built on other methodologies such as

Workflow or RPCs without changing the policy

specification language.

7. Conclusions and Related

Work

This paper has outlined our work in progress, which

uses: 1) an XML-based business extension to describe

business contracts and 2) BizTalk server capabilities

to facilitate the process of encoding policies for

monitoring and enforcing contracts. The novelty of

our approach is that we provide support for a

declarative way of specifying policies for contracts.

The main benefit of this is that it enables a separation

between enforcement policy specification and the

functional specification of the operations needed to

support contract operations. The use of the BizTalk

platform enables flexible updates of contract

enforcement rules to accommodate changes in

business policies related to contract enforcement.

Our XML-based approach for specifying contracts is

similar to some of the results from the CrossFlow

project, with the additional feature of using an XML

extension (i.e. CBL) to embody some business

documents semantics. Furthermore, our approach of

defining and implementing the roles needed to

support of contract operations has some similarity to

recent IBM work on contracts

. Unlike the IBM

approach, our approach is focussed on supporting

business and in particular legal views on contracts

and thus our business contract architecture does not

include low-level concerns such as security and

transport mechanisms used to support contract

operations. These can be regarded as implementation

choices specific to the deployment en vironment.

In this paper, we have also identified several open

issues that we plan to investigate in the future.

Examples of these issues include better support for

contract negotiation, conflict detection and resolution

of the legal rules when composing customized

contracts, and better support for policies to govern

service provision through cross-organizational

business process.

7. Acknowledgements

The authors would like to thank Andy Bond and

Linda Bird for their comments on this paper.

The work reported in this paper has been funded in

part by the Co-operative Research Centre Program

through the Department of Industry, Science &

T ourism, Australia.

8. References

[C93] Clarke, R. "EDI is bu t one element

of elect ronic commerce", 6th

International EDI Conference, June

1993.

http:// www.cros sflow.org

http:// www-4.ibm.co m/software/developer/

library/tpaml.html#resources

Session 4: Electronic Contracts

[FL96] Fosbrook, D. and Laing, A. "The A-

Z of Contract Clauses", Sweet &

Maxwell, London 1996.

[MAL96] Milosevic, Z., Arnold, D. and

O’Connor, L. "Inter-enterprise

Contract Archi tectur e for Open

Distribu ted Systems: Security

Requ irements". WET ICE’96

Workshop on Enterprise Security,

Stanfo rd, USA, June 1996.

[MB9 5] Milosevic, Z. and Bond, A.

"Elect roni c Commerce on the

Internet: What is Still Missing?"

Proc. 5th Conf. of the Internet

Society. p245-254, Honolulu, June

1995.

[R89] Reinecke et al ., Introduction to

Business - A Contemporary View ,

Allyn and Bacon, 1989.

[S96] Sandholm, T. "Negotiation among

self-interested computationally

limited agents", PhD Thesis,

University of Massach usets,

Amherst. 1996.

[SD99] St een, M . and Derrick, J.

"Formalizing ODP Enterprise

Policies", Proceedings of Enterprise

Distribu ted Object Compu ting

Conference (EDOC’9 9), 1999.

[ T95] Trietel, G. The Law of Contract, 9th

Edition. Sweet and Maxwell, 1995.

[TT98]

T an, Yao-Hua and T hoen,

Walter. "Modeling directed

ob ligations a nd permissio ns in

trade contracts", AI & Logic

Modeling. 1998.

[UW97] Ullman, J. and Widom, J. A First

Course in Database Systems,

P rentice-Hall. 1997.

[W94] Whipple, J. "The Formation and

Enforcement of Electronic

Contracts". Publi c Law Research

Institute. Available at:

http://www.uchastings.edu/plri/fall1

994/whipple.html

Session 4: Electronic Contracts

Appendix A: Sample Contract

CONTRACT FOR THE PURCHASE AND SUPP LY OF GOODS

T his Deed of A g reement is en te r ed into as of the Eff e ctive Date iden tif ied below.

BETWEEN [Name] AND:

[Name]

of [Address] of [Address]

(To be known as the (S upplier) in this Agreement) (To be known as the (Purchaser) in this agreement)

WHEREAS (Supplier) desires to enter into an agreement to supply (Purchaser) with [Item] (To be known as (Goods) in this Agreement).

NOW IT IS HEREBY AGREED that (Supplier) and (Purchaser) shall enter into an agreement subject to the following terms and conditions:

1. Definitions and Interpretations

1.1 Pri ce, Dollars or $ is a referenc e to t he currency of the [ Count ry] unless otherwise stated.

1.2 This a greement is governed by [Count r y] law and the pa rties hereby agree to submit to the jurisdiction of the Court s of the [Country]

w ith re s pe ct to this agr e ement.

2. Commencement and Completion

2. 1 T he com mencement date is s che d ul ed as [da te ] .

2.2 The completion date is scheduled as [date].

2.3 The schedule may be modified by agreement as defined in Section 9.

3. Purchase Orders

3.1 The (Purchaser) shall follow the (Supplier) price lists.

3.2 The (Pu rch aser) shall present (Supplier) wit h a purchase order for t he provi s ion of (Goods) within 7 days of th e commencement

date.

3.3 The purchase order shall nominate the method of delivery as defined in Section 4.

3.4 Purchase orders are to be sent electronically, and are to be interpreted under standards and guidelines outli ned in Supplement A.

4. Delivery

4. 1 T he ( Pur ch as e r ) s h al l arr ang e f o r de liver y to be made a cco rdi ng to one of the f o llowing term s :

(a) The shipping and insurance of the (Goods) shall be the sole responsibility of and entirely at the expe nse of the (P urchaser).

(b) The shipping and insurance of the (Goods) shall be the responsibility of the (Supplier). The (Purchaser) shall provide the

(Supplier) at least [days] days notice and pay the carriage and insurance costs fro m the (Supplier) delivery price list.

5. Pa yment

5.1 The payment terms shall be in full upon receipt of invoice. I nterest shall be charged at [percentage ] o n acco unts not paid within 14 days of

the invoice date. T he prices shall be as stated in the sales order unless otherwise agreed in writing by the (Supplier).

5.2 Payments are to be sent electronically, and are to be performed under standards and gu idelines outlined in Supplement B.

6. Rejection

6.1 If the (Goods) do not comply with the Order or the (Supplier) does not comply with any of the conditio ns, the n the (Purchaser) shall at its

sole discretion be e ntitle d to re ject the (Goods) and the Order. The (Purchaser) shall return the rejected (G oods) to the (Supplier) at the

(Purchaser) risk and expense or notify the (Supplier) to collect the (Goods). T he (Supplier) may use its discretion to replace the (G oods)

according to the invoice or refund any mo nies paid.

7. Te rminat ion

7.1 If (Purchaser) fails to carry out any of its obligations and duties under this agreement (Supplier) may issue a notice specifying the

breach and request that it be remedied within 14 days after receipt of such notice.

7.2 If (Purchaser) fails to provide adequate remedy within the specified 14 days the agreement may be terminated forthwith.

8. Dispute s

8.1 (Supplier) and (Purchaser) shall attempt to settle all disputes, claims or controversies arising under or in connection with the

agreement throu gh con sultation and negot iations in good faith and a spirit of mu tua l cooperati on.

8.2 Th is meth od of determinat ion of any d ispute is without prejudice to the ri ght of an y p arty to have the matter judic ially d ete r m ined by

a [Country] Cour t of competent jurisd icti on.

9. Amendment

9.1 This agreement may only be amended in writing signed by or on behalf of both parties.

SIGNATURES

In witness whereof (Supplier) and (Purchaser) have caused this agreement to be entered into by their duly authorized representatives as of the

effective date written below.

Effective date of this agreement: [day] day of [month] [year]

[Signature] [Signature]

[Person] [Person]

[Role] [Role]

Address for Notices:

[Address] [Address]

Session 4: Electronic Contracts

Appendix B: XML Encoding of Sample Contract

<title> CONTRACT FOR THE PURC HASE AND SUPPLY OF GOODS <title>

Thi s Deed of Agreement is en tered in to as of the E ffective Dat e iden tified b elow.

<parties> BETWEEN

<pa rt y ID=’P1’> <name> </name> of <address> </address> (To be known a s t he <role> Sup plier </role> in t he agreement) </par ty>

AND

<pa rt y ID=’P2’> <name> </name> of <address> </address> (To be known a s t he <role> Pur chaser </role> i n this agr eemen t) </p arty>

</parties>

WHEREAS

<partyref IDREF=’P1’/> desires to enter into an agreement to supply <partyref IDREF=’P2’ /> with <item ID=’I1’> </item>

NOW IT IS HEREBY AGREED that <partyref IDREF=’P1’/> and <partyref IDREF=’P2’/> shall enter into an agreement subject to the

following terms and conditions:

</preamble>

<clause ID=’C1.1’>Price, Dollars or $ is a reference to the currency of the <country> </country> unless otherwise stated. </clause >

<clause ID=’C 1.2’>This ag reement is governed by <country> </ country> law a nd t he pa rties hereb y ag ree t o sub mit to the ju risdiction of the

Courts of the <country> </country> with respect to this agreement. </clause>

</clausegroup>

<clause ID=’C2.1’> The commencement date is scheduled as <date> </date>. </clause>.

<clause ID=’C2.2’> The completion date is scheduled as <date> </date>. </clause>

<clause ID=’C2.3’> The schedule may be modified by agreement as defined in <clausegroupref IDREF=’G9’/>. </clause>

</clausegroup>

<clause ID=’C3.1’> The <partyref IDREF=’P2’/> shall follow the <partyr ef IDREF=’P1’/> price lists. </clause>

<clause ID=’C3.2 ’> The <pa rtyref IDREF=’P2 ’/> shall present <partyref IDREF=’P1 ’> with a purch ase order for the provision of <itemref

IDREF=’I1’/> within [days] days of the commencement date. </clause>

<clause ID=’C3.3’> The purchase order shall nominate the method of delivery as defined in <clausegroupref IDREF=’G4’/>. </clause>

<clause ID=’C3.3’> Purchase orders are to be sent electronically, and are to be interpreted under standards and guidelines outlined in

</clausegroup>

<clause I D=’C4.1’ > The <partyref IDREF=’P2’/> shall arrange for delivery to be made according to one of the following te r m s:

(a) The shipping and insurance of the <it emref ID=’ I1 ’> shall be the sole responsib ility of and entirely at the expense of th e <partyref

IDR E F= ’ P 2 ’/> .

(b) The shipping and insurance of the <itemref ID=’I1’/> shall be the responsibility of the <partyref ID=’P1’/>. The <partyref

IDREF=’P2’/> shall provide the <partyref IDREF=‘P1’/> at least <days> </days> days notice and pay the carriage and insurance

costs from the < partyref IDREF =‘P1’/> delivery price list. < /clause>

<clause ID=’C5.1’ behav ior = ‘ ‘/> The payment terms shall be in full upon receipt of invoice. I nterest shall be charged at <pe r cen tag e > </ per ce n tage >

on accounts not paid within <days> </days> day s of the invoice date. The prices shall be as stated in the sales order unless otherwise agreed in

writing by the <partyref I DREF=‘P1’/>. </clause>

<clause ID=’C5.2’> Payments are to be sent electronically, and are to be performed under standards and guidelines outlined in <suppl ementr ef

IDREF = ’SupplementB’>.</clause>

</clausegroup>

<clause ID=’C6.1’> If the <itemref I DREF=‘I1’/> do not com ply with the Order or the <partyref IDREF=‘P1’/> does not comply with any of the

conditions, then the <partyref I DREF=‘P2’/> shall at its sole discre tio n be entitled to reject the <itemref I DREF=‘I1’/> and the Order. The

<par ty ref I DREF=‘P 2’/> shall return the rejected <itemre f I DREF =‘I 1’/> to the <partyre f I DREF=‘P1’/> at the <party ref I DREF=‘P2’/> risk

and expense or no tify the <party ref I DREF=‘P1’/> to collect the <itemref I DREF=‘I1’/>. The <partyref IDREF=‘P1’/> may use its discre t ion

to replace the <itemref I DREF =‘I 1’/> according to the invo ice or refund any mo nies paid.</clause>

<clause ID=’C7.1’> If <partyref IDREF=‘P2’/> fails to carry out any of its obligati ons and duties under this agreement <partyref

IDREF=‘P1’/ > may issue a no tic e specif yi ng the brea ch and request th at it be remedied wi thin <da ys> 1 4 </days> days after receipt of

such notice. </clause>

<clause ID=’C7.2 ‘> If <partyref IDREF=‘P2’/> fails to provide adequate remedy within the specified <days> 14 days </days> the ag reement

may be term inat ed fo r t hwith. </claus e>

</clausegroup>

<clause ID=’C8.1’> <partyref IDREF=‘P1’/> and <partyref IDREF=‘P2’/> shall attemp t to settle all disputes, claims or controversies arising

un der or in connecti on with th e agreemen t t hrou gh consultation and negotiat ions in good faith and a spirit of mutua l cooperati on.

</clause>