[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [legalxml-econtracts] File Transmission WIUScenarioTwo
Scenario: Dispute Resolution and Litigation Involving Contracts
Name: Dispute Resolution and Litigation Involving Contracts
Principle Stakeholders: Law Firms, Contracting Parties, Courts, Alternative
Dispute Resolution, Electronic Commerce Software Developers
Scenario Owner: Laurence Leff, Ph.D. Western Illinois University
Draft Number 1
Draft Date Feb 23
Contributors: Laurence Leff, Ph.D. Western Illinois University
Zaw Han, Western Illinois University
Tin Tin Khine, Western Illinois University
Sunil Shrestha, Western Illinois University
Imtinan Ahmad, Western Illinois University
Our group has prototyped expert system rules that read XML transmitted as part
of electronic commerce and simulates a flow of possible litigation including
XML format for all motions and other court documents. We started with an
exchange of purchase order and acknowledgment under an ebXML system. This
input included:
1) the ebXML Collaboration Protocol Agreement (CPA)
2) the ebXML Business Process Specification (BPS)
3) a purchase order as defined by the Common Business Language
4) a purchase order acknowledgments
3) the ebXML messages and SOAP headers associated with their transmittal
Assume that the plaintiff is suing as they delivered goods and did not receive
payment. We processed the XML documents associated with that lawsuit. These
were all prepared in accordance to the proposed Court Document standard from
the OASIS Electronic Court Filing group.
These included:
a) affidavits connecting the DUNS ID number used in the CPA to a party at
with a specific name and address.
b) affidavits from a signature verification service that the digital signature
and document matched the digital certificate as specified in the CPA
c) the court complaint
d) the affidavit that the goods were shipped
e) the request for summary judgment
The software determined whether summary judgment was warranted.
Of interest to the e-Contracts group, our software used an electronic contract
as an intermediate format between the rules inspecting the electronic commerce
XML and the rules relating to court processing . The software ascertained
whether the messages were in the proper format, whether deadlines for
acknowledgment and acceptance that were specified in the CPA were met, whether
the proper signatures were made and were valid.
If so, the software extracted the legally significant information from the
purchase order. This was transformed into the electronic contract format
proposed to the Legal XML Contracts Workgroup in the Summer of 2000 by
the enior author. This was input to another set of rules, simulating
litigation involving the above described Court Documents.
See http://www.wiu.edu/users/mflll/rules/Interop3.doc
http://www.wiu.edu/users/mflll/rules/Interop.html
Scenario Statement
Parties transmit electronic commerce using two sets of XML standards. One
defines a framework such as ebXML or bizTalk and primarily specifies low-level
transaction data such as signature standards, acknowledgement times, and
the like. I will refer to these as the framework standards and XML.
The other set of XML standards would be for the type of electronic
commerce. For example, sales of goods might use the Intellisys purchase
order standard, Common Business Language standard, or the Universal Business
Language. There are other XML standards proposed for fields such as insurance
and real estate. I will refer to these as the payload standards and XML.
When there is a irreconcilable dispute,
the software examines both the payload and framework XML.
This software defines whether an electronic contract was agreed to. This
is primarily based upon the framework XML and framework standards.
If so, it would prepare a contract in an XML format proposed by this
Technical Committee to be sent to the court or arbitration agency (the venue).
This would be based upon the payload XML.
The parties would submit various documents such as affidavits, motions,
and the original complaint to the venue. These, of course, would be based
upon the Electronic Court Filing Committee's Court Document Standard.
Rules in an expert system at the venue would examine the motion XML and
the Contract XML and determine
whether summary judgment for either party was warranted. If a trial or hearing
was required, these rules would help determine the issues to be decided
and prepare such documents as the proposed charge to the jury.
Thus, I propose that our Electronic Contracts standards serve as a lingua
franca between disparate payload standards for different industries and
the expert systems that will hopefully some day exist in the courts and
alternative dispute resolution agencies.
Summaries of Key Benefits to Stakeholders
Routine matters could be resolved without human intervention. Examples of
such matters would be collection cases that go to default judgment and
forcible detainers that are not contested.
The software would help determine the issues in complicated litigation involving
complicated contracts.
Parties could test their contracts by simulating possible litigation involving
them. This will make contracts less ambiguous and allow parties to avoid
litigation.
Functional Requirements
00: A contract format that allows one to unambiguously mark up the obligations
of both parties. Obligations could be text statements. They could also
be XML for specific situations. The first-level contract standard should
have markup for commonly-used obligations such as the payment of money
or the transmission of communications electronically. Industry groups
should have the ability to provide specialized markup. For example,
the steel industry might have specialized markup for grades of iron
scrap. The construction or real estate industry might have specialized
markup for their subject matter.
Legal concepts referenced in the Uniform Conditional Code should have
unambiguous mark up. "Freight On Board" or waiver of the Warranty of
Merchantability come to mind.
01: A contract format that has markup for conditional clauses. The conditions
could be other events stated in the contract. Or they could be external
events. It should be possible to state that a party must perform a
certain task that will occur a certain period of time from when another
was completed. Alternatively, a contract might specify has the option
to do something within so many days of the opposite party completing a task.
For example, it should be possible to unambiguously mark up the following:
a) A will pay B fifteen days after an invoice is sent out
b) If the goods are not satisfactory, B MAY send a request to repair
B can do this up to thirty days from delivery.
c) B shall repair within thirty days
d) if repair is not completed satisfactorily within thirty days from
notice, B MAY send the goods back and receive a refund
02: Contracts should be able to refer to the obligations in other contracts
(so called "choses-in-action")
03: There should be a mechanism for marking up exceptions. Assume that
the above purchase contract said that requests to repair were to be
forwarded to a specific person, Mary Lou. There should be sufficient
markup so that a contract drafting system could reason that Mary Lou might
die, and provision should made for that exceptional condition.
Less prosaically, a contract drafting system observing a contract that
specified a shipping method, should raise an alert that certain
conditions might prevail that would prevent such shipments in a timely
fashion, e. g., a terrorist attack or extreme weather.
Or a contract specifying payment of a certain number of shares of stock,
should trigger an inquiry as to what would happen should the stock split.
Of course, this mechanism, like the clause mechanism, should be expandable.
Thus, an industry contributing clause replacements, would have a way to
state what exceptional conditions might apply to them. For example,
the definitions for the construction industry markup might include
statement about weather conditions or strikes that would make unfeasible
certain types of obligations. This would be used by the drafting
software to ensure that all possibilities are accounted for.
The exception mechanism would enable the contract drafters to still
have clean XML when the exceptions are marked up.
A generalized mechanism to handle "Commercial Infeasibility" should be
provided for those parties who do not want to specify all possibilities.
Notes:
Dr. Leff proposed a contract markup in Summer 2000 on the old Legal XML group.
These documents are temporarily located at
http://www.wiu.edu/users/mflll/UN_100XX_2000_04_24.html
http://www.wiu.edu/users/mflll/UN_100XX_2000_08_22.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC