[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-cppa-negot] [Fwd: [legalxml-econtracts] Agenda for upcomingmeeting from theOASIS Legal XML Member Section Electronic Contracts TechnicalCommittee Secretary(File id: @@2280)]
See attached as requested. > > Sachs: I will be unable to attend the legalxml call. If you will be > there, could you post a summary of anything interesting in the > automated negotiation topic? > > Also, I still cannot get access to the automated negotiation document > (link below). Could you send it to me and perhaps post it to the > negotiation listserver? > >> -------- Original Message -------- >> Subject: [legalxml-econtracts] Agenda for upcoming meeting >> from the >> OASIS Legal XML Member Section Electronic Contracts Technical Committee >> Secretary (File id: @@2280) >> Date: Mon, 1 Sep 2003 21:45:22 -0500 (CDT) >> From: Dr. Laurence Leff <D-Leff@wiu.edu> >> To: legalxml-econtracts@lists.oasis-open.org >> >> >> >> Agenda for Conference Call >> Electronic Contracts Technical Committee of the >> OASIS Legal XML Member Section >> >> September 3rd >> 18:00 Eastern >> Dial 512 225 3050 - Use 84759# for Pin Code >> >> 18:00:00 Wed Sep 03 2003 in US/Eastern converts to >> 22:00:00 Wed Sep 03 2003 in GMT >> >> Welcome and Roll Call >> Approval of draft Minutes for the meeting of August 20th >> >> The Automated Negotiation Scenario - Dave Marvit (first twenty minutes) >> http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/download.php/2032/b.txt >> >> >> (These two will take the next fourty minutes) >> Scenario - Law Firm Contract creation and Negotiation >> http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/download.php/2039/scenar%7E3.htm >> >> >> Scenario - Enterprise Contract Management Scenario >> http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/download.php/2056/Enterprise%20Contracts%20manager%20scenario.htm >> >>
Scenario - Automated Negotiation System Document Owner: Dave Marvit, dave@marvit.org Version: 1.0 Date: February 27, 2003 Introduction This document is a scenario developed as part of the eContracts requirements process. The goal is to describe a generalized automated negotiation process and determine the minimal set of requirements for an eContract specification that will support such a process. Stakeholders The stakeholders for an automated negotiation system are parties that will be engaging in transactions in which the space of business terms (parameter space) is both well understood and rich. These will typically be commodity transactions. Scenario Statement Regular business partners are engaging in an automated transaction of some commodity. They recognize that there are many business terms (call them parameters) in each such deal relating to, for example, delivery and payment schedules, price (which constantly fluctuates in this commodity market), and the details of the specification of the commodity. The parties recognize that in any given transaction one side might care a lot about one parameter such as delivery date, while this may be much less important to the other side which may be more concerned about, say, the quality of the goods shipped. In such a rich parameter space in which the parties have differing (but competing) value functions, all parties want to automate the negotiation. Here negotiation is defined as process of making tradeoffs between parameters as a part of the process of reaching an agreement. An automated system exchanges documents thereby exploring this complex parameter space until an agreement is reached or the process is abandoned. If an agreement is reached, an eContract is generated and, once approved, is signed electronically by the parties. After the contract is signed it moves on to other systems that are beyond the scope of this scenario Example A PC manufacturer is in need of memory chips for a new batch of PCs. The chip manufacturer can provide a variety of types of chip (RDRAM, SDRAM and so on), many sizes, speeds, reliability levels and so on. The provider can deliver these chips along many different timelines. And, of course, the price will vary depending upon the exact combination of all of these terms. The importance that the manufacturer places on each of these different terms (chip type, chip size, delivery schedule, and so on) depends on a variety of factors, including orders in the queue, support resources, current debt load, predictions of coming price reductions in memory costs, the economic viability of the chip vendor, and a variety of other internal and external conditions. Determining how much importance to place on each term is a complex process that, for the sake of argument, we will assume exists. The mathematical expression of the importance of each business term (or parameter) is called a 'value function'. The chip manufacturer has a value function as well, although the specific importance that the seller places on each term is quite different from the buyer's. It is this difference in value functions that allows both parties to benefit from the transaction. Every good negotiator knows that you can often find a deal that benefits both sides by adding more business terms into the mix. "If you can wait a week longer for that I can save some money and share the savings with you." Here there is a tradeoff between time and money that benefits both sides. As more parameters are added the opportunity for savings increases. ("Do you really need such a fast chip? I can get you a bigger slower chip for the same price" and so on.)With the rich parameter set described in the memory chip example the opportunities for savings are considerable - as long as optimal points can be found in the (mathematical) space of possibilities. Unfortunately, as the richness of the parameter space increases, so does the complexity. Humans have difficulty handling negotiations with many parameters. They certainly cannot process such negotiations in a timely fashion. Hence the need for automated negotiation. In the automated negotiation, the manufacturer and the chip vendor exchange documents that describe different proposed values for the different business terms. They iterate as they (hopefully) zero in on a deal that maximized the total value. All of this takes place in the context of their competing interests. Once a set of terms is reached that is agreeable to both sides a formalization of that agreement takes place, here by generating an eContract and applying digital signatures. Summary of Key Benefits to Stakeholders 1. The capability of exploring a rich parameter space (a rich set of business terms) automatically allows all parties to extract more value from each transaction. (An automated negotiation system can explore a much richer parameter space than humans ever could, and it can explore such a space more exhaustively. This allows discovery of those points where each side's needs can be met at a minimal cost to the other.) 2. Negotiating a contract in this manner can significantly reduce time and costs associated with the transaction process. 3. Lowering the costs associated with transactions makes many types of transactions economically feasible that are not feasible in a manually negotiated context. Assumptions 1. Enough business terms can be represented as negotiable 'parameters' that such a system can be useful. This does not require that ALL business terms can be parameterized, nor does it presume that it is practical to represent all business terms as parameters. 2. This approach does not need to benefit all forms of contract negotiations to still have significant utility. 3. The process of assigning 'value' to each of the different parameters is out of scope for this discussion. 4. Documents other than the contract will be exchanged in the process of negotiation. 5. Documents other than the parameterized business terms may be required to generate the contract, such as documents containing formatting information. Requirements 1. Business terms must be represented such that their values can be changed independently of one another. 2. An eContracts can be generated by a list of parameterized business terms (and possibly non-parameterized terms) in combination with appropriate formatting information. 3. The point at which contracts are agreed to by the parties involved must be made clear to all involved. Non-Requirements There does not need to be any mechanism within the contract itself for representing whether a term is negotiable or not. Notes The actual process of negotiation will take place through the exchange of abstract representations of the contract terms specifically designed for the negotiation process. The eContracts itself will not be the format used for all of these exchanges.Title: OASIS LEGALXML ECONTRACTS TC - SCENARIO
OASIS LegalXML eContracts TC Requirements ProcessScenario - Law Firm Contract Creation and Negotiation
IntroductionThis document is a scenario developed as part of the eContracts requirements process. The purpose of a scenario is to provide a context for a set of requirements important to some group of end-users (in this case, law firms). A scenario is intended to help members of the working group to understand the drivers behind stated requirements. To that end, this document contains a Scenario Statement, and a set of Requirements extracted from the Scenario Statement. As per the requirements process, contributions to this scenario are welcome. Please send your contributions to the Scenario Owner. The Scenario Owner will decide whether to accept your contribution or not. If your contribution is not accepted, you may create your own Scenario. For further details, please refer to the eContracts Requirements Process document Scenario StatementLaw firms are currently re-evaluating their document processing strategies in light of Microsoft's announcement that the forthcoming release of Microsoft Word will be fully XML enabled (see for example http://www.microsoft.com/presspass/press/2002/Oct02/10-22Office11Beta1PR.asp). This scenario identifies some possible outcomes which an XML contract format could deliver law firms and their customers. A lawyer (or solicitor) will typically come to be working on a contract in one of two ways:
In either case, someone created an initial draft of the contract, a series of subsequent drafts were produced, and in due course (all going well), a final document acceptable to all parties is ready for signature. The initial draft will often be “cut and pasted” from an existing contract. Sometimes this existing document is a “precedent”, which a lawyer can expect to be of a high quality as a result of some precedent maintenance process. A draft contract is a version produced by the lawyer and provided to his/her client for review. (Typically the client is actively discouraged from amending a draft – amendments made by a client are best seen as instructions to the lawyer.) A draft may or may not be provided to the other side (or sides). So, the business of the lawyer is to get from the starting point (ie a blank page, a precedent, or the other side's draft) to a result his client is satisfied with, with as little pain as possible. This means negotiating favourable (or at least acceptable) terms, and reflecting those terms accurately in the words of the contract, in an efficient manner. Currently, most lawyers produce contracts using Microsoft Word (97 or later). Some still use WordPerfect. The vision for XML contracts is to improve significantly on today's typical contract production process. Improved Document QualityIt should be possible to improve the quality of a draft contract per unit of effort. Quality has several aspects to it:
XML contracts should deliver improvements in each of these areas. It must be possible to produce the vast majority of “formal” contracts currently produced in law firms. This means cover pages, table of contents, headers and footers, pictures, tables, equations, and arbitrary contents in schedules and annexures. Automatic numbering and cross-references should be supported, so the lawyer does not need to number the clauses, or worse, re-number them after a clause is inserted. Put another way, it should be possible to convert most legacy contracts into the eContracts XML format, without loss of content. It is acceptable for the formatting to be handled by a stylesheet (ie in accordance with the practice of separating content from style), provided the stylesheet can capture the format adequately. Example contracts (Australia):
Example contracts (UK): Example contracts (USA): Some contracts take the form of paragraphs in a letter. It would be good if eContracts can cover these informal contracts as well. Second, it must be possible to enforce a consistent firm style across all contracts. For example, all exclusions of liability appear in capital letters. Third, it must be possible to deliver the contract in various popular formats, including RTF, PDF, and XHTML. Better Negotiation SupportAs successive drafts are produced, the wording of various clauses will change, and some clauses will be added/removed. The lawyer needs to keep track of the state of each clause, and manage the process to an acceptable final state. It should be possible:
Word processors do not do a good job at any of this. As law firms adopt Word 11 and use its XML features to draft contracts, law firms will increasingly send their draft contracts to their client and the other parties, in XML (rather than RTF, DOC, or PDF). Alternatively, their client and the other parties will see the document in a shared workspace. In either case, it must be possible to provide an instance of the XML contract which does not contain any sensitive information, and which the other party can work with. Risk ManagementWhen a law firm drafts a contract covering say infrastructure or finance worth $1 billion, it obviously exposes the law firm to more risk than a contract with a value of say $100,000. The drafting process must address the risk. By capturing the value of the contract in the document, the workflow can automatically adapt to the value of the transaction (for example, by incorporating extra sign off steps). Downstream processingXML contracts should explicitly tag information which is necessary for the client's downstream applications. For example, information regarding the parties, the commencement, term and renewal of the contract, must be tagged so that this can be automatically captured when the contract is fed into a contract management system. Similarly, it is useful to capture the value of the contract, and any contract milestones. Particular clients are likely to have their own systems, for which special information is required (ie information specific to an industry sector like insurance, finance, or construction). It would be useful if this information could be tagged in the contract so that it can be automatically extracted. Knowledge re-use: Improved Drafting EfficiencyFirms will wish to store their precedent contracts in XML. Doing so enables the precedents to be managed more effectively. For example, if a piece of legislation changes, it should be possible to search for all contracts which contain a reference to that legislation. Precedent contracts will often have additional text which guides a lawyer in their usage. It should be easy to re-use existing precedent clauses in an XML contract. There is no reason to draft, say, a governing law clause from scratch. Equally, XML contracts should encourage lawyers to submit original or impoved clauses, so other lawyers can re-use them. Appropriate meta data must be captured, so it is easy to search across a library of existing clauses. ArchivingA law firm will often need to locate its copy of a contract, possibly many years after it was signed. It is obviously important that the document be in a format which is still readable, and it is expected that XML contracts will facilitate this. SearchIt is useful to be able to search by party, date, dollar value etc, as well as any other information which may have been tagged for the purposes of downstream applications. It is also useful to search for contracts which contain a clause of a particular type (eg termination clause), or a clause containing a certain string of words.
Application / Tool SupportLawyers must be able to create XML eContracts in the normal course of their daily practice. XML eContracts must be supported by commonly available tools. Note: this need will be taken to have been met if the XML eContract format can be handled by Microsoft Word 11. Summary of Key Benefits to Stakeholders
RequirementsThe following requirements have been extracted from the Scenario Statement. Important Note regarding Traceability: Why each requirement is important should be clear from the scenario above. If it isn't, the scenario or the requirements should be amended. STRUCTURE-related Requirements
Markup of Particular Information
MetaInformation Requirements
OTHER Requirements
NotesSome of the things in this scenario may not be delivered by the XML contract schema per se. However, it should be possible to build tools which support the requirements, using XML contracts. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Search: this monththis yearthis list Match: allanyboolean Sort by: scoredatereverse scorereverse date
Words: | Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]