[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes Draft from the OASIS Legal XML Member Section Electronic Contracts Technical Committee Secretary (File id: @@2432)
Minutes of OASIS Legal XML Member Section e-Contracts Technical Committee
Face-to-face held September 19th and September 20th at San Francisco
Present
Dave Berry
Dr. Zoran Milisovic
Peter Meyer
Daniel Greenwood
Dave Marvit
Dr. Laurence Leff
1) Thanks and appreciation to Lon and David Marvit for opening up their home
for our meeting
2) Introductions - We each introduced ourselves and told a little about
our work with electronic Contracts
3) Mr. Greenwood shared some history of the group
(It was recognized that Intellectual Property Issues were
important, which included.
a potential patent related to representing contracts. However, at the
suggestion of Mr. Greenwood, it was decided to proceed with the
requirements process as if such intellectual property was not a concern,
so that we would come up with the best ideas unimpeded by these concerns.)
4) Mr. Greenwood said that this was a "Make or Break" meeting and it was
hoped that there would be a consensus on the vision and direction of this
technical committee.
5) We also had a discussion of business process standards such as BPEL and
Choreography and its relationship with contracts. Also, we discussed the
efforts by the OASIS Technical Committee on Unified Business Languages
as well as the Contract Expression Language from Content
Guard, how to liaison with these, and the possible role of James Clarke
of OASIS, who is the liaison from the OASIS staff to our Technical Committee.
6) The Technical Committee discussed its approaches for the face-to-face.
We would:
for each use case
outline the use case
identify the transaction classes
identify the user needs
Come up with a vision statement (possibly two to four sentences)
Do a high-level requirements and collapse
Determine priorities
[As we proceeded, we adopted a slightly different approach as you will
see below.]
7) Mr. Daniel Greenwood led us to a dedication and mutual dedication to
focus, clarity, and emphasis on the business problems
Also, we would respect each other and accept the business problem
And, lastly, there would be open mindedness, and we are starting
fresh on this project.
8) Midway, through the meeting, we agreed on some terminology and typology.
This would be an alternative to the terms: "structural" vs. "semantic"
and "non-narrative" vs. "narrative"
We recognized the importance of two types of information in a contract
Human-readable
Machine-readable
Machine-Readable would be further divided into "rules" and "data" It
was understood that "data" would be a special case of "rules." as
a single data item would be a reduced case of "rule" just as an integer
is also a rational number.
9) For each of the use cases, we identified the
a) basic statement
b) transaction classes
c) User Needs
CLICK-THROUGH CONTRACTS
(WIU Scenario Two:)
a) A person downloads a contract to which they will assent. They also capture
the contract itself.
b) The two transactions are the agreement process and searching the
set of contracts to which there was an agreement.
c) The user needs to be able to record the contracts and search the database.
INTEROPERABILITY
(WIU Scenario One: Electronic Commerce to Litigation)
a) We convert messages in electronic commerce to one lingua-franca.
These may be used in court or arbitration procedures.
b) Transaction Classes are the master agreements that cover all transactions
between the trading partners and each transaction underlying the
commerce. (Note, the master agreement now is a conventional signed
document which governs the contractual relations established by the
electronic commerce.)
c) The user needs are to recognize contract obligations.
To match the XML documents exchanged in the normal part of exchanging
XML documents with these obligations.
The court should be able to recognize the electronic commerce.
To be able to "debug" the master agreement, determine if it does give the
needed affect to the electronic commerce and to determine that the
contract is enforceable in various scenarios via the procedure used
by the arbitration agency or court.
LITIGATION
(WIU Scenario One: XML Contracts to Ligitation)
a) A contract is used and established. The obligations are matched against
the documents in litigation.
b) Transaction Classes are the litigation documents and the match with the
contract.
c) The user needs are to sort through the obligations and determine:
a) if one user has a prima facie case (corresponding to a summary judgment)
b) what must be established by the trier of fact.
ACCOUNTING
a) We start with the contract:
These are compared to the payments and to documents such as bills of
lading or advice to determine the recognition of revenues and
expenses
b) Transaction Classes are per the normal business process
c) The user needs are to match the contract with related electronic
documents
NEGOTIATED CONTRACTS (by Peter Meyer)
a) These are the creation of a contract negotiated by the partners:
First the Basic Deal Terms are determined,
Then the formal complete contract language is authored,
The parties exchange these, and there may be iteration through these
steps as issues are negotiated.
Finally, the contract is formally adopted as recognized by both parties
signing the contract.
CONSTRUCTION PREPARATION and MANAGEMENT by Rolly Chambers
This scenario includes everything that happens in negotiated contracts.
However, they start with a standard contract, such as one from the
American Institute of Architects. Changes to these are kept, marking
with parentheses and underlines so parties can recognize these deviations
from the standard language easily. Note that this is different from
the negotiation as expressed by Mr. Meyer as we must keep the complete
history of changes.
Then, electronic versions of the terms can go into a project-management
system. We should be able to rapidly derive information from the
management of the contract.
We need to manage the process system.
We manage access to the contract by the stakeholder.
They have rights and obligations and need to access (push/pull) to the
terms. However not all parties need access to all terms. For example,
the plumbers don't need to know the payment schedule or the total that
the parties agreed to for the entire building project.
The parties may need access in multiple formats such as print, web,
text to speech, and via PDA.
After a change order, we need to track the new contract, that is, the
set of mutual obligations.
We recognize that the contract may consist of several documents. These
may be prepared by different people, and some of these may be incorporated
by reference from the main contract documents.
The parties may need to check and analyze performance of parties across
multiple contracts and determine the adequacies of templates being used in
the contracts.
ELECTRONIC CONTRACT MANAGEMENT
(This was based upon Dr. Zoran Milosovic's scenario, but not on a use
case as expressed in the template Mr. Meyer shared with us for the
September First Action deadline.)
a) This involves automated monitoring of the circumstances and compliance with
contract.
b) Interested people and persons are notified about fulfillment, their
obligations, and possible violations.
CLICK THROUGH CONTRACTS
Further discussion of this scenario revealed that:
The scenario is that a person or electronic-agent interacts with the system.
(This is predominantly the web, but might include interacting with an installer
program.) These contracts provide the terms and conditions for downloading
software, but might also include participating in a service such as
eBay or a travel agency.)
The user might have difficulty saving the document, as it might be in text
Potentially, these difficulties might lead to the contract being void under
the Federal E-Sign law. This law provides that if a party inhibits a party
saving or printing the document, then that contract is not valid.
When the document is saved, it is difficult to name the file reasonably
so it is very difficult to save them.
Also, we need to track when one contract supersedes the other. The typical
case is when a new version of the software is downloaded.
The steps are:
Step One: The user agrees to "access an artifact" such as "online resources"
Step Two: The user wishes to store the contract plus related "temporal data."
These include the time of signature, the URL from which the
document is retrieved.
Step Three: We might want to link to the software downloaded. That is
a person using the product might wish to be able to quickly
access the terms under which it is used. Similarly, if one
has source code, one might want to link to the terms and
conditions if that source code is to be included in another
product, perhaps submitted to open-source repository
Step Four: We may want to share the contracts agreed to by one party
with another party.
Value Propositions:
A company may want all of its employees to record the contracts to which
they agree by click-through so that the legal counsel can review them.
We want to ensure that the employees do not evade this process or requirement.
We want to know if a contract supersedes any existing documents.
We may want to prevent the user from agreeing to contracts that are
contrary to corporate policy or state law. (For example, some state
constitutions prohibit the state from "indemnifying" other parties.)
We may want an interface to digital rights management.
Corporations and legal entities may want to keep a "white list"
and "black list" regarding specific types of terms and companies
with which it will agree or not.
INTEROPERABILITY
Further discussion on the interoperability use case (from WIU Scenario Two)
focused on the steps in this scenario:
Step One: A Master Document is Created
Step Two: If this Master Document represents a trading community such as
Covisint, people join
Step Three: Commerce Occurs
Step Four: Disputes occur
a) many disputes are resolved between the parties without involving
a third party such as an arbitrator or court
b) other disputes would require such adjudication
Step Five: Litigation begins
Step Six: Adjudication occurs by arbitrary or court which leads to one of
two results:
a) a summary judgment
b) facts that are in dispute are identified.
The Technical Committee discussed how the contract litigation use case
and Accounting use case relate to this.
AUTOMATED NEGOTIATION (from Dave Marvit)
We need parameters. The Technical Committee discussed how parameters
related to Document Assembly and the Interoperability scenario. And,
the technical committee discussed whether this need was in scope; perhaps,
parameterized clauses and contracts should not be included specifically
in the specification but not precluded specifically. We also discussed
the importance of a one-to-one mapping from parameters to the resulting
contract.
10. Scope Issues
The technical committees discussed how it would resolve scope issues:
a) Would the market accept a solution
b) What are the problems that could be resolved by a standard
c) Which use case would most further our goals? (Rolly Chambers' Construction
Contract Management use case was selected.)
d) Which use case would impact the most users?(Click Through Contracts Scenario)
11. The Technical Committee looked at the use cases, identifying the
goals and problems for each.
CLICK THROUGH
Problems:
1) End users don't know what contracts they signed or their obligations
under these agreements.
2) The party promulgating such contract (e. g. eBay or software vendors) have
no interest or benefit in helping the end users interpret or save their
contracts.
3) Systems for entering into transactions are fully created.
Goals:
1) To create and preserve evidence of contracts into. (This was identified
as a key requirement.)
2) The Technical Committee discussed the issue of searching the saved
contracts but did not decide anything about this requirement.
ELECTRONIC CONTRACT MANAGEMENT (based upon Peter Meyer's scenario)
Problems:
1) Competition is driving the need for efficiency
2) Cost and Speed. Iterations of negotiations are slow. There is a transaction
drag on negotiations
3) Lawyers are expensive. Perhaps, non-lawyers can do some of this work
Goals:
1) Traceability of contract changes
2) Cost and Speed, Reuse of terms is hard
3) Precedent data management
4) Repeatability - re-use reduces risks
The Technical Committee identified "reuse" as a key goal.
CONSTRUCTION PREPARATION and MANAGEMENT by Rolly Chambers
Problems:
1) There are disputes over change orders. (Specifically, people interact
and act on a change order that may not be authorized.)
2) We want to ensure that the amendment process and initial assent process
are clear.)
3) One wants controlled "visibility" by different interested parties.
4) And it is hard to access the contract in different forms.
5) One wants to be able to extract items to the contract management system.
5) It is hard to reference external documents from the contract.
6) It is hard to determine the current state of contract-events, delegations,
and processes.
7) We wish to record the past analysis of contracts of time, and parties.
Goals and objectives:
1) Automatic extraction of quantitative information from the Contract
2) Access to contract language for different output forms
3) Monitoring and tracking. This includes reminders of dates, anticipated
breeches, and when payments are due.
4) On-line Realtime Contract Management
5) Clear Conclusive Change-Order Management
6) Identify the current version of the contract
7) Access control to the content of the contract, and changes thereto.
INTEROPERABILITY and ACCOUNTING USE CASE (submitted by Dr. Leff)
The Technical Committee identified that the two use cases, both from
the same scenario, could be combined for this analysis.
Problem:
1) Use of electronic commerce standards, such as ebXML, are not sufficient
to determine if a contract is formed.
2) Currently paper contracts are used to express the "master agreement"
to establish a trading partner or by which new partners could
enter into a trading community. This represents a drag on electronic
commerce and is one of the last bastions of paper in a world of electronic
transactions.
3) Related to the above, there is no automated process for new partners
to agree to the Trading Partner Agreement.
Goals:
1) To compare the transactions with the terms of the contract
2) To have a master trading partner agreement with the ability to opt in
with zero lawyer involvement. Thus, it might be possible for a
corporation to establish a "white list" of acceptable terms.
3) To provide a "lingua franca" between electronic commerce and other
systems.
AUTOMATED NEGOTIATION (from Dave Marvit)
Problems:
1) Contract Negotiation is slow and expensive
2) There are limits to the value to partners because current negotiation
cannot support a large number of parameters.
Goals:
1) To make contract negotiation cheap and fast.
2) To give all parties maximum practical value.
12. Table
Our technical committee worked on a table to show how each use case
corresponds to the different steps of contract formation and management
and the actors and systems relevant. (This table was prepared in
HTML and is incorporated by reference with these minutes.)
13. Vision Statement
The technical committee observed the following introductory paragraph
or problem statement applied to all contracts:
Today, contracts are locked in blobs which can't be processed outside
the creating application (such as Microsoft Word). This inhibits
automated document creation, information reuse, and the extraction
of information.
The Technical Committee prepared vision statements for the different
use cases:
CONTRACT DRAFTING (from Peter Meyer)
We want to allow contract terms to be managed at convenient levels of
granularity to facilitate improved access to
the terms and conditions in precedent documents. We want to improve
document assembly with easier harvesting of re-usable contract terms
from transaction documents. We want to facilitate collaborative
authoring with revision history management. And lastly, we want
to help an enterprise consistently format all of its contract
documents.
CLICK-THROUGH CONTRACTS
The eContracts standard will enable individuals and enterprises to
a) identify click-through contracts prior to assent
b) store contracts to which they assented
c) identify the contracts and terms assented to
when dealing with supporting online service provider.
ELECTRONIC CONTRACT MANAGEMENT (from Dr. Zoran Milosovic)
At the moment parties to contracts and other users of contract information
have no way to exchange machine-readable contract information for
importing into contract management systems.
Vision:
To allow parties to contracts to exchange machine-readable information for importing into contract management system. We wish to map machine-readable
contract information items to relevant human-readable contract terms.
We discussed whether the information could be exchanged as XML contracts
or attached to other forms. It is presumptuous for us to develop a
standard that supports features not currently in contract management systems.
INTEROPERABILITY (from Dr. Laurence Leff)
In electronic commerce, there is currently no way to map or validate
electronic transactions against the master agreement or determine the
transaction's legal effect.
There may be no master agreement and thus no way of determining the
legal affect of transactions.
Manual negotiation of master agreements is too time-consuming.
The following problems occurred in the context of masters agreements:
We wish to automatically update pointers when a clause is moved or changed
and update references to a document when the document location changes.
INTEROPERABILITY vision
the eContract standard will enable machine-readable master contracts that
will permit:
a) automatic validation of subordinate electronic transactions
b) automatic contractual opt-in to participate in the system representing
an electronic community
The technical committee will consider whether the contract standards could
provide a "lingua franca" for processing data created from various
e-commerce standards such as ebXML.
14. Plan
At the end of our face-to-face, our technical committee briefly
identified its plan to continue its work.
Various people will do high-level requirements. Mr. Meyer graciously
offered to provide a template and/or example.
The Technical Committee will discuss these requirements, and then
prioritize them, prior to preparing detailed requirements.
We also decided that we will probably pursue liaisons with other agencies
after requirements are done.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]