a joint un/cefact legal group and tmg project...– from legal considerations to technology and back...

1

2004-03-12 UN/CEFACT, LG/TMG, UBAC, 2004 1

Unified Business Agreements and Contracts (UBAC)

A joint UN/CEFACT Legal Group and TMG project

Anders W. Tell, Project team leadDavid Marsh , Team editorEva Yueh, Editor

This slideshow is indented to be a collection of slides to be used for targeted UBAC related presentations


UBAC Overview

• UN/CEFACT Unified Business Agreements and Contract project– Approved march 2003, started may 2003

• Trading Partner Relationships– From Legal considerations to Technology and back

• Electronic Agreements and Contracts– Machine readable agreements and catalogs– Partially electronically interpretable agreement for international supply

chains

• Built ontop of UN/CEFACT BCF/UMM which provides…– eCommerce foundation / ontology– process and collaboration framework– modeling framework based on UML

• Reusing UN/CEFACT Processes and Core Component libraries

2


Problem domainAgreement support for International Supply Chains

Legal and geographical

boundaries

From Paul Harmon, Business Process Trends


Problem domain

eBusiness Collaborations

Busines Domain Model

e-Collaboration Model

Strategy / Goals

Value/resource transfer

Legal and Accounting

Process and DialogInformation

Risk / Security / Trust

Organization ABusiness

Operations Model

InternalSale

Process

Organization BBusiness

Operations Model

InternalProcurement

Process

Business and IT-systems

Supply Chain Operation Model

MoneyProduct and Services

Profile / Interface

Profile / Interface

Value proposition

Preferences

BusinessystemBusinesssystem

Diagram from Anders W. Tell, Toolsmiths

3


Trading Partner Relationships

From consideration to technology

Technology BindingTrading Partner Agreement

Model Law

International Law &Conventions

Domestic Law

Consideration Formalization ofconsiderations,

principles and variants

Model TPAIncorporationby reference

TechnologyEDIFACT / AS2

TechnologyebXMl / XML

Future Technologies

• Provide advice and guidance for eBusiness technology standardization


BusinessSystem

AddresseeOriginator

Designated Information System

data messageauthenticity of originstorable/retainablepercievabletime ofintegrityauthorization

Dispatch

Reach

MSH: Acknowledge

Protocol: Receipt


Dispatching and reaching, where is the legal effect ?

Effect

Effect

Effect

Effect


4



India: The Information Technology Act 2000

• 12. Acknowledgment of receipt.• (1) Where the originator has not agreed with the addressee that the

acknowledgment of receipt of electronic record be given in a particular form or by a particular method, an acknowledgment may be given by—– (a) any communication by the addressee, automated or otherwise; or– (b) any conduct of the addressee, sufficient to indicate to the

originator that the electronic record has been received.

• (2) Where the originator has stipulated that the electronic record shall be binding only on receipt of an acknowledgment of such electronic record by him, then unless acknowledgment has been so received, the electronic record shall be deemed to have been never sent by the originator.



UN Recommendation 31

• 3.2.2 Revocation– Any offer shall, unless otherwise agreed or

expressly stated in the offer [be / not be] revocable. If revocable, an offer may only be revoked if notice of such revocation is [received by / sent to] the receiver of the offer before acceptance has been [received by /sent to] the sender.

5


Legal considerations and ebXML: MSH Acknowledgement and ReceiptAck

• Business rule: – Application must reach organization before or at 23.59:59 on Sunday.

• Transaction definition: – Request: ApplicationDocument– ReceiptAcknowledgement signal is required

• timeToAcknowledgeReceipt = 2 h

• Events:– Request

dispatched 23.01.00, reached 23.02.00• Message is complete, in correct format, readable, wellformed, etc

– MSH Acknowledge with signaturedispatched 23.50.00, reached 23.51.00

– Negative ReceiptAcknowledgement due to too late Application requestdispatched Monday 00.01.00, reached 00.02.00

Originator disputes the Negative ReceiptAcknowledgement since originator claims that ApplicationRequest was reached in due time in agreed format



Some aspects of reaching Designated Information System

acts on behalf of originator

IdentificationAuthorization

IdentificationAuthorization

Legally relevant Communication

InformationSystem

In control of

InformationSystem designated system

"push"

"pull"

AddresseeOriginator

address (logical attributed to physical)

Accessible(capability,capacity,possibility,availability,...)

Communication

(instantanous, non-instantanous)

InformationSystem

non designated system

InformationSystem

resonable fororiginator to expectaddressee to receive

other information systems

Communication

addressee hasexpressed intent toreceive

Third partyService Provider

CommunicationCommunication


6


Catalog of agreements and parts thereof

• Reuse of existing agreement templates and parts of thereof– Copy-paste templates with optional copyright– Standardized and signed

• Support establishment of Trade practices– Transparency may lead to harmonization– Possible to relate specific terms and conditions to case law

• Composition rules

Catalog ComponentXMI/RDF

Sign

Catalogpackage

XMI/RDF

Sign

Aggrement DocumentStructure

Section

Section

Section

Section

Clause

AgreementComponent

Paragraph

STATIC and REUSABLE:Constraints, Objectdefinitions, ExternalOntologies such as UMM,References, Presentation

Legally valud Statementsabout the content of theagreement/contract and stateof affair


Simple vs Complex agreements

• Must support...– simple textual agreements – as well as complex eContracts

• Range of catalog and agreement component ...– from non- interpretable textual components

• Simple text, formatted text– to simple dynamic data structures

• Dates, prices, addresses,...– to interpretable and observable commitments

• UMM artifacts

7


Interpretability Scale

Text onpaper

OCR

Machinereadable

Machineinterpretable

Text

Simple Schemas and data

Shared facts, rules, constraints, procedures and knowledge.

•Legal

•eCommerce

•Healtcare, Governmental

•Online Dispute Resolution

•EDIFACT, ebXML

•XML

•Word Processor

•UML, RDF, XML

•URI, UUID

•Classification, Grouping

•Document structure

Shared experiances, Interpretations and strategies

•Semantic web

•AI, Agents

•Description logic

•Observable commitments and fullfillments

Enforcement and monitoring

Shared beliefs, plans, goals and intentions

Domain Ontologies, processes and collaboration technologies

target


Agreement and Contract examples• U.S.Legal Forms, Inc• "Contract" - An agreement between persons which obliges each party to do or not to do a certain thing.

Technically, a valid contract requires an offer and an acceptance of that offer, and, in common law countries, consideration.

• "Agreement" - A contract between persons which obligates each party to do or not do a certain act. An agreement requires as offer, acceptance of the offer and consideration.

Advertising/MarketingAsset PurchaseBill of Sale-AutomobileBill of Sale-Watercraft/BoatBill of Sale-All FormsBuy-SellCommercial LeasesCommissionsConfidentiality AgreementsConsentsConsignment AgreementsConstructionConsultingContractors

Contracts-AContracts-BContracts-ConsultingContracts-EmploymentContracts-ServiceDistributorshipDomestic-SettlementEasementsEmploymentEntertainmentEquipmentFarmsGolfGuaranty

Hold HarmlessHome_SalesHuntingndemnityIndependent ContractorsInstallment Agreement - NotesInstallment Agreement - otherJoint Venture AgreementsLeasesLease PurchaseLegal_ServicesLicense AgreementsLimited Liability Companies

Operating AgreementLimited_PartnershipsLiving TrustsLoan AgreementsMarketingMedicaidMedical ReleasesMergersMutual Releases

Name AffidavitsNon-CompetitionNon-DisclosureOffices & Office LeasesOil, Gas & MineralsOperating AgreementsOptions--Option to Purchase--Stock OptionsPartnershipsPledges

Post-Nuptial AgreementsPower_of_AttorneyPremarital-AgreementsPromissory NotesReal_Estate AgreementsReceiptsReleasesResidential LeasesSale_of_BusinessSale AgreementsSalesperson Contracts

Security AgreementsServices ContractsShareholder AgreementsSoftware AgreementsStock Agreements- Corporate- Power of Attorney- Purchase- Option

StockholdersSubcontractor AgreementsSubordinationSubscriptionTax_Free_ExchangeTrusts

8


Collaboration artifact: Agreements

Business Agreement

Trading PartnerAgreement

public

TPPRepositorypublic

TPP RepositoryExtract

CollaborationProtocol

Agreement

Extract

General clauses

Party A Party B

Negotiation(propose, accept, reject)


Types of Agreements

Business Agreement

Trading PartnerAgreement

public

TPPRepositorypublic

TPP RepositoryExtract

CollaborationProtocol

Agreement

Extract

General clauses

Party A Party B

Negotiation(propose, accept, reject)

Requirements determines

relevant types

Focus on Commercial agreements

Supplier InternalProcesses Customer Customers

Customerresources

payments

resources

payments

resources

payments

9


UN/CEFACT Modeling and Methodology (UMM)

• Contract formation and fulfillment processes – Dynamically defined using ebXML

• Collaborations ,commitments, events, BCP2,...– Negotiation pattern

• Classification of catalog and agreement components– Using CC and CBPC mechanisms

• Information building blocks– Core components and Business Entity Types– Standardized by UN/CEFACT TBG Domain groups


UMM Views and contract types

• Domain View– Letter of Intent, Memorandum of Understanding

• Requirements View– Economic Contract

• Service View– TradingPartnerAgreement ?– Documents

• Implementation Functional View– Collaboration Protocol Agreement

10


UN/CEFACT: Reusable processes and Core Components

• TBD• Core Components Library• Process Library


UMM: Resource Exchange and legal terms & conditions

From article by Bob Haugen

11


UMM: Extending REA concepts

<<agent>>Customer

<<agent>>Company

<<contract>>Order

<<commitment>>Order Item

<<event>>Payment

<<event>>Shipment

<<resource>>Product

DUALITY

A container forcollection ofcommitments

An obligation toperform an economicevent in the future

An economic event is the transfer of controlof an economic resource from one agent toanother agentExamples: sale, cash-payment, shipment

An economic resource is something ofvalue that is under the control of anenterprise and that can be transferred fromone agent to anotherExamples: cash, inventory,labour service

An economic agent is someone who is ableto participate in economic eventsExamples: manufacturer, distributor,carrier, end customer

<<resourcetype>>ProductType

May be used forpolicies and planning

AddingCapability,capacity, availability,permission, authorization, obligation, rights, empowerment,delegationtransfer


Use cases(preliminary list)

• 7.1. Contract Management (management of risk and commitments)• 7.2. Liability Framework Automation of Supply Chain• 7.3. Payment of a Direct Shipment with Commissions or Service Charge to a Third

Service Party• 7.4. Payment Before Delivery (Payment-Up-Front)• 7.5. Alternative Dispute Resolution • 7.6. Credit Confirmation and Liability Insurance• 7.7. Negotiation and Recognition of Intellectual Properties and Rights• 7.8. Trans-Shipment • 7.9. Specification of template Agreement by industry organization• 7.10. Specify Trading Partner Relationship• 7.11. Digital receipt for online shopping or point of sale• 7.12. Contract forms• 7.13. Micro-transaction A• 7.14. Micro-transaction B• 7.15. Micro-transaction C• 7.16. Confidentiality Agreement--• 7.17. Multi-Agent Network of Related Bilateral Agreement—Order-based eFinancing

Service• 7.18. Provision of Third-Party Service (Non-Product) to Buyer and Seller• 7.19. Service Level Agreement

12


Use case: digital receipt

SellerCustomer

AdvertisePlanningProduct informationPrice InformationNegotiationPayment, DeliveryLegal UI (identification,review,sign,send)

XML

Receipt

Over the CounterPurchase

PDA

XMLReceipt

Receipt

Delivery

Paper

ReceiptCustomer

Receipt

• May be achieved reusing REA and Legal Relations Language


Requirements areas:

General requirements• 1.1. Formalization of legal considerations and mapping to

electronic commerce technologies• 1.2. Catalog and reusability• 1.3. Parties and authorized roles

– 1.3.1. Signing and signatures• 1.4. Electronic agreements and paper format

13


Req: Contract forms, Fill-In-The-Blanks, Click through

Lorem ipsum Lorem ipsum Lorem ipsum Lorem ipsum Lorem ipsumLorem ipsum Lorem ipsum Lorem ipsum Lorem ipsum FillInTheBlanks

DeliveryDate:

Lorem ipsum Lorem ipsum Lorem ipsum Lorem ipsum Lorem ipsumLorem ipsum Lorem ipsum Lorem ipsum Lorem ipsum Lorem ipsumLorem ipsum Lorem ipsum Lorem ipsum Lorem ipsum Lorem ipsumLorem ipsum Lorem ipsum Lorem ipsum

Lorem ipsum Lorem ipsum Lorem ipsum Lorem ipsum Lorem ipsumLorem ipsum Lorem ipsum Lorem ipsum Lorem ipsum

Lorem ipsum Lorem ipsum Lorem ipsum Lorem ipsum Lorem ipsumLorem ipsum Lorem ipsum Lorem ipsum Lorem ipsum

AgreeReject


Requirements areas:

2. Business Operations view

• 2.1. UBAC analysis process– 2.1.1. Contract management process– 2.1.1.1 Archiving– 2.1.2. Contract formation process– 2.1.2.1 Referencemodel– 2.1.2.2 Negotiation

14


Req: Contract formation process

Normative System/ Authorities

Reject

Natural PersonLegal Entity

Invitation

Accept

Propose

Withdrawal/Revoke

Notice


Req: Contract process (example)

Appendix SS

Catalog Construction

OCR

Archive

Printing(PDF/RTF)Party/Role

Party/Role

Party/Role

Proposal Proposal

Proposal

XMLSign

eBLA

S S

LegalDomain

XML

Sign

Catalog

Process,Information,

Collaborations,Transactions,

Events, Monitoredcommitments,

execution,enforcement, etc.

CatC

Initialproposal

acceptedproposal

Geopolitical,Industry org,Marketplace,Dominating org.Enterprise

Reject

Appendix S

XML/Paper

BLA

PaperSign

BLA

S S

Sign S S

PaperSign

BLA

S S

Sign S S

TPA

Process

Document

ProfileProfile

Party/Role

Party/Role

Collaboration Acts

Collaboration Acts

CatalogPublisher

XML/Paper

BLA

AgrC

Contractmanagement

Online DisputeResolution

Evidence

Negotiation

SigningExecution, monitoring

PostActualization

15


Req: Negotiation pattern(s)

<<BusinessTransaction>>Party A offers

Agreement[pending]

<<BusinessTransaction>>Party B offers

Agreement[pending]

Agreement[pending]

Agreement[counterpending]

[accepted]

[accepted]

[counterPending]

[counterPending]

• Propose

• Accept

• Reject

• Withdrawal

• Revoke

• Late Acceptance

• Notice


Requirements areas:

2.2.UBAC Meta model

• 2.2.1. Structural requirements– 2.2.1.1 Representation forms– 2.2.1.2 Agreements and parts thereof– 2.2.1.3 Agreement dependencies and Incorporation by

Reference– 2.2.1.4 Lifecycles of agreements and parts thereof– 2.2.1.5 Change management and amendment– 2.2.1.6 Conflict resolution between legal provisions– 2.2.1.7 Merging of legal provisions– 2.2.1.8 Grouping of legal provisions– 2.2.1.8.1 Policies

• 2.2.2. Institutional and normative aspects

16


Req: How to represent legal provisions?

Formal specification(UBAC 1.0)

Agreement representation(meta model)

Natural languagepresentation [SE]

formalizedas

Natural languagepresentation [FR]

Natural languagepresentation[UK]

presented

presented

presented As

Facts, rules and logicConcepts and RelationsOntologies

F C

R

loremipsum

UBAC v1.X

normative

Legal Provision

dependsOn(superior,specialis,posterior)

Type Catalog

explained anddefined in

On paper for humans and archival

In signed XML file for computer interpretation

For precision, consistency and

formal verification


Req: Dependencies between agreements

Agr(4)

TA(5)

Longterm(1)

TPA(3)

BLA(2)

governing

governing

governing

include

Reusable

Components

include

include

include

EDI / TPA

Technical agreements with

process specifications and

technical parameters

Long term generic agreements

Standardized components

Commercial agreements with commitments,

fulfillments and applicable law

17


Req: Associate Legal provisions with data messages using Standard Business Document Header (SBDH)

AgreementContractLegal ConventionLegal Principles

MessageEnvelope

PriceList$

VISIOCORPORATION

usage governedBy(implicit)

MessageEnvelope

PriceList $

VISIOCORPORATION

Agreement

Standard BusinessDocument Header

BusinesScope

MessageEnvelope

PriceList Document

PriceList $

VISIOCORPORATION

Agreement

Standard BusinessDocument Header

BusinesScope

explicit association


Requirements areas:

2.2.3. Basic ontology

• 2.2.3.1 Natural persons, legal entities and roles• 2.2.3.2 Resources• 2.2.3.3 Business and Legal Event• 2.2.3.4 Business rules and constraints• 2.2.3.5 Conduct, acts, processes and behavior

– 2.2.3.5.1 Communicative acts– 2.2.3.5.2 Specification– 2.2.3.5.3 Prescription (intention to be legally bound)

• 2.2.3.6 Information• 2.2.3.7 Location

18


Requirements areas:

2.2.4. Legal Relations Language (LRL)

• 2.2.4.1 Legal relations and deontics• 2.2.4.2 Intentions and assertions• 2.2.4.3 Delegation of authority


Req: Legal relations ala Wesley Hohfeld

If a party has a ..

underlying meaning another party has a …

and others does not have a …

Right Legal ability to act Duty Privilege Duty A legal obligation to act or refrain from acting Right No right Privilege No legal obligation to act or refrain from acting No right Right No right No legal ability to act Privilege Duty Power Ability to affect a change of legal relations Liability Immunity Liability Subject to a change in legal relations Power Disability Immunity Free from the legal power of another Disability Power Disability No ability to affect a change of legal relations Immunity Liability

19


Requirements areas:

2.2.5. Commitments and fulfillments

• 2.2.5.1 Commitment• 2.2.5.2 Fulfillment


Requirements areas:

2.2.6. Business centric aspects

• 2.2.6.1 Capability and capacity• 2.2.6.2 Performance measurements and

metrics

20


Requirements areas:

2.2.7. Enforcement

• 2.2.7.1 Compliance, non-compliance and not possible

• 2.2.7.2 Monitoring mechanisms• 2.2.7.3 Dispute resolution mechanisms


Requirements areas:

2.2.8. Executability

• TBD

21


Requirements areas:

2.2.9.Electronic communication of data messages

• 2.2.9.1 Trading Partner provisions• 2.2.9.2 Dispatch, reach and

intermediaries• 2.2.9.3 Designated information systems• 2.2.9.4 Writings and records


Requirements areas:

2.2.10. AgreementComponents

• 2.2.10.1 Controlled vocabularies

22


DeliverablesRequirements and

Scoping

UN/CEFACTBaselineCatalog

Catalog XML Schema

AgreementXML Schema

UBAC Meta Model

Agreement Catalog

<<instantiate>>

UBAC AnalysisProcess

Requirements

Use Cases

BenchmarkAgreements

Benchmarkconventions andlegal provisions

<<extends>>

TechnologyModels

<<uses>>

<<uses>>

ATG XMLProduction Rules

ICG,ATG Processes

UMM Meta Model

UN/CEFACT LexiconCore Components

Core ComponentsMeta Model

UMMProcess

UN/CEFACT LibraryBusiness Processes,

Business Entities

<<extends>>

<<extends>>

<<uses>>

Core Components XML Schema

UMM XMI <<uses>>

<<uses>>

ExecutableBusiness Level

Agreement

<<instantiate>>

BusinessOperationalView

FunctionalServiceView

affect

affect

affect

affect

provides requirements to BCF::UMMUBAC

Externalspecification X

Externalspecification Y

Externalspecification Z

references

references

references

UBAC UserGuide

UBACReference Guide

provides guidance

UBAC Profile

External OrganisationsSpecifications

subset



binding

UBAC Production Rules

Generic HeaderModel

<<uses>>

references

Technologybinding


UBAC Meta model

• TBD

23


UBAC Analysis process

• TBD


Functional service view

• 3.1.Production rules• 3.2.Syntax Representations

– XML Representation of Catalogs and Agreements

• 3.3.Baseline catalog– Standard set of terms and conditions

• 3.4.Standard Business Document Header– AgreementScope

24


UBAC Profiles

• Specific bindings to implementation technologie– ebXML– ... others ...


UBAC User guide

• TBD

25


UBAC Reference Guide

• Description of UBAC meta model and its extensions to UMM

• Recommendations for Technology standardization– Legal consideration for trading partner

relationships– …


Benchmarks

• 5. Benchmark agreements– 5.1.Normative

• 5.1.1. UN Recommendation 31• 5.1.2. RosettaNet TPA

– 5.2.Informative• 6. Benchmark conventions and legal provisions

– 6.1. Normative• 6.1.1. UNIDROIT Principles of International

Commercial Contracts [1994]• 6.1.2. UNCITRAL Model Law on Electronic Commerce

[1996]– 6.2.Informative

• 6.2.1. The principles of European Contract Law [1999]• 6.2.2. ICC Model Contract xxx• 6.2.3. ICC ICOTERMS

26


TODO• Harvest contracts, agreements and legal practices

– Global scope– Reference groups in various legal domains

• Possible extensions– UMM , revised or new concepts– Introduce contractual reuse

• Catalogue components such as templates, clauses, paragraphs, constraints, etc.

– Documentation of agreement and contracts• Document structure• Textual paragraphs not easily encodable and interpretable

• Investigate process requirements for legal analysis, similar to TBG, ICG• Evidentiary requirements

– Receipt, signatures– Non repudiation– Timestamps– Record

• Fulfillment– Distinguish between Conditions and Monitoring mechanism