We have several interrelated projects underway that share a common theme, integrating contracts, particularly those in XML, so they can be negotiated and formed on one hand, and be litigated or brought to arbitration forums on the other hand. This is integrated contract civil justice.
Those familiar with electronic commerce trends know that XML is being used and proposed for many applications. XML is a way that industry groups can specify for the format for structured information such as insurance claims, purchase orders, stock quotes.
For example, e-procurement companies such as Intelisys developed standards for purchase orders and items. Or trade groups such as the Legal XML Group or the IMS project prepared standards for their respective industries (court filing and distance education).
Then, everyone in that industry will prepare XML documents that adhere to the standard. In many cases, this preparation will be done by various automated tools. For example, a person ordering products via an e-commerce business system, would not write the XML for the purchase orders with a text editor. Their purchasing system would do this for them and forward it to a receiving computer, perhaps running a different brand of purchasing software. That software would "validate" the incoming purchase orders to ensure that there were no bugs or problems with the software.
The Legal XML Group is developing standards for Legal documents including court filing documents, contracts, transcripts, and legislation. Our work concerns the first two.
I defined a DTD for contracts for the Legal XML Contract Work Group. Unlike conventional English contracts, using this XML eliminates ambiguities in which some obligations are conditional on actions of the other party or other obligations . Other features including using the DTD validation mechanism to ensure that commercial unfeasibility and other unlikely events are considered for each obligation or condition in the contract. This mechanism was inspired by exceptions in Java which ensure that a programmer considers each and every unlikely possibility from their statements, e. g., I/O errors.
We hope to develop interactive software with a graphical users interface, e. g. Windows, to generate this contract format.
The above methods are for situations where each contract is individually prepared and negotiated. Electronic Commerce often involves the exchange of XML such as purchase orders and invoices. Legally, this may be under the control of a Master Agreement. Electronically, it may be under control of a Trading Partner Agreement Markup Language This controls details of the electronic transmission: such as the communication protocols, the security information, and the BusinessProtocol section which specifies a state table. That state table specifies the order by which XML documents are exchanged. Thus, at each point in the sequence, the TPA specifies what XML documents are transferred and to whom. E. G., after a purchase order is sent, a purchase order acknowledgment or an out-of-stock message might be permissible.
Similarly, the E Commerce Framework, specified in the eCo Architecture, specifies which XML documents are exchanged between market participants. It also specifies which businesses are members of which markets, and the electronic commerce provided by each one.
However, the legal significance of the contract is specified by the The Operating Rule Markup Language, specified as part of the MIT E-Commerce Architecture Project, provides a precise mechanism for allowing the trading partners to specify the legal affect of their contracts. This document precisely answers such high level questions as precisely which exchanges constitute a legally binding offer and acceptance. A price check request and a purchase order constitute a legal offer and acceptance forming a contract. Or the trading partners might want to require a Purchase Order and Purchase Order Acknowledgment before a contract is formed. (Note: all three of these document types are defined as part of the DTD's available in the Common Business Language.)
At a lower level, this process determines which parts of the purchase order XML have legal significance. For example, the Common Business Language Purchase Order DTD specifies tags for TermofDelivery, ShippingInstruction, GeneralNote, and SpecialHandlingNote. The ORML allows, and indeed forces, the parties to decide which of these specify legal duties and which are just unofficial requests.
The ORML maps between the Trading Partner Agreement or Eco Architecture, the XML being exchanged and the proposed contract DTD.
Our students are developing software that takes as input, XML produced under the legal aegis of an ORML-based master agreement. It will then produce the corresponding contracts by substitution using the mapping in the ORML. Thus, XML such as purchase orders and purchase order acknowledgments will be given legal affect by being converted into a contract format. The mapping from the XML already in use by the firms to contract language, is defined precisely and unambiguously by the ORML, itself an XML document.
I used AI technology to reason about contracts formed using these mechanisms as well as documents using the Legal XML court filing standard. First, I interfaced the Jess expert system tool, a rule based shell developed in Java at the Sandia National labs, with the IBM Xerces XML parser. This java interface allows the Jess rule author to refer to the inside of an XML object. I also developed efficiency hacks to selectively expand different parts of the XML document into the rule engine and then retract them when the reasoning about that part of the document is completed.
I then developed rules that read in a slightly abbreviated form of the court filing which contained a complaint. Another set of rules processed a contract as specified in the proposed DTD for contracts. In addition, I assumed formats for complaints, affidavits supporting motions, and a request for summary judgment and developed a rule set to determine if summary judgment should be granted. If the contract specified that the first party should have certain obligations and there was a payment clause for the second party, then the second party was obligated to pay. The system checked for affidavits asserting each of the clauses that the first party did, and then checked that the amount prayed for was equal to the amount that the person owed. Then, the expert system asserted a money judgment.
This shows an integration between a format for contracts on one hand and procedural rules of justice on the other hand. This was a small proof of concept, but the same techniques can and will be used to encode much of contract law, as might be stated from the Restatement of Contract Law or the Uniform Commercial Code. The same technique would be used to encode the Rules of Civil Procedure in a court.
Lastly, I wrote software so that the rules themselves are entered in XML. This makes it easy for the rule-writer to prepare the matching. They simply cut and paste the XML to be matched from their example document to the rule-set. Then, they place tags and values like VariableName:p to indicate where matching is to occur.
This leads to the integrated civil justice architecture described earlier (as applied to contracts). Where many XML documents will be exchanged between parties or among a market, an ORML document is created. Then, the XML documents are exchanged amongst the parties in the normal fashion, there may be a dispute between them.
Our software will read the log of XML transferred between these parties. It will also read the ORML and any eCo Architecture or Trading Partner XML that was set up in advance for the parties oar market. Then, the software can generate the equivalent Contract DTD's as discussed earlier.
These can be processed an expert system with a knowledge base containing rules from the Uniform Commercial Code, private Law to be administered by the contract body, or general law such as statutes or that expressed in the Restatement of the Law of Contracts. Initially, it might be configured to make conclusions of law based upon the XML transferred, and the dates in the logs of the XML. Thus, routine litigation can be handled electronically.
Other versions would be configured to sit in the offices of a plaintiff or defendant attorney to read the court filings and make conclusions of both procedural and substantive law. It might be configured to draft new documents.
And lastly, versions could sit in the court system or the arbitration agency. They would read the incoming filings and generate routine motions.
I am focusing first on contracts for two reasons. The first is that contract cases constitute half of all civil litigation. Half of these were plaintiffs trying to recover payment for goods or service rendered. [DEF96]. In one year, there were at least 90,000 state court suits as well as 50,000 federal cases. This survey only included the 75 largest counties and does not include rural areas or small claims court suits. I believe that much of this litigation is routine.
All or much of the data for a contract case are often in the records of the participants, particularly when the contract was formed electronically. This is in contrast to tort cases such as car accidents, where much of the data must be obtained by interviewing witnesses.
The diagram below shows the interrelationship between these programs and the DTD's and documents with which they deal.
Relatedly, we will begin working on interfacing accounts payable software to the court system. When a firm has outstanding debts, they should be able to forward these as litigation to the appropriate court. Collections of debts are a substantial problem in the United States.
23.8 billion dollars are collected yearly by
third party collection agencies and 170 billion dollars were placed
for collection.
Credit and collections was designated as the fourth-largest growing
small-business dominated business in the economy by the U. S. Small
Business administration.
(
American Collection Association)
It is important that collections are quick.
Even after
only three months, the probability of collecting a delinquent account
drops to 73%. After six months, the probability of collecting drops to
57%. And after one year, the probability drops to 29%.
(Commercial Collection Association))
.LP