[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa] [Fwd: [legalxml-econtracts] File TransmissionWIUScenarioTwo]
I though this may be of interest to this TC. -Matt -------- Original Message -------- Subject: [legalxml-econtracts] File Transmission WIUScenarioTwo Date: Mon, 24 Feb 2003 18:52:15 -0600 (CST) From: Dr. Laurence Leff <D-Leff@wiu.edu> To: legalxml-econtracts@lists.oasis-open.org 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 ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC