For those interested, a video of my October 9, 2014 talk at Stanford Law School entitled “Machine Learning Within Law” has now been posted here.
The talk discusses the application of machine learning artificial intelligence applied to automate certain tasks traditionally done by attorneys.
Please join me on October 9, 2014 at Stanford Law School for a talk entitled “Machine Learning Within Law”.
As the name suggests, this talk will be focused on current and future applications involving machine-learning automation in the practice of law.
The paper upon which the talk is based “Machine Learning and Law” (2014 Univ. Wash. Law Review) can be downloaded here.
More details about the talk can be found here on Stanford’s website.
Computable Contracts Explained – Part II
This is the second part of a series explaining “computable contracts.” For more about what a computable contract is, please see the first part here.
Overview
In the last post I defined computable contracts as contracts that were designed so that a computer could “understand” what was being promised and under what terms and conditions (metaphorically).
We can think of a computable contract as a partial workaround to a particular technological limitation: computers can not reliably understand “traditional” English language contracts.
The goal of this second part is to explain the intuition behind how an ordinary contract can become a computable contract.
Three Steps to Computable Contracting
There are three steps to creating a computable contract:
1) Data-Oriented Contracting
2) Semantic Contract terms
3) Automated assessment of contract terms
I will discuss each of these steps in turn.
Step 1 – Data-Oriented Contracting
Recall the primary problem of Part I – computers cannot understand traditional contracts because they are written in languages like English. Computers are not nearly as good at people at understanding documents expressed in “natural” written language (i.e. the “Natural Language Processing Problem”).
What is the solution? Write the contract in the language of computers, not in the language of people.
This is known as data-oriented contracting (my terminology). In a data-oriented contract, the contracting parties deliberately express contract terms, conditions and promises, not in English, but as data – the language of computers.
This partially gets around the natural language processing problem – because we are not asking the computer to understand English language contracts. Rather, the parties are deliberately expressing their contract in a format amenable to computers – structured data.
Example of Data-Oriented Contracting
What does it mean to express a contract term as computer data?
Let’s continue with our earlier example: an option contract with an expiration date. Let’s imagine that one contracting party has the option to purchase 100 shares of Apple stock for $400 per share from the other, and that this option to buy the Apple stock expires on January 15, 2015.
Recall that one of the impediments to computers understanding traditional contracts was the flexibility of natural languages. A party crafting this provision in English could express the idea of an expiration date in innumerable ways. One might write, “This contract expires on January 15, 2015”, or “This contract is no longer valid after January 15, 2015”, or “The expiration date of this option is January 15, 2015.”
These are all reasonably equivalent formulations of the same concept – an expiration date. People are very adaptable at understanding such linguistic variations. But computers, not so much.
A Data-Oriented Term Equivalent?
Is there a way that we can express essentially the same information, but also make it reliably extractable by a computer? In some cases, the answer is yes. The parties need to simply express their contract term (the option expiration date) as highly structured computer data.
For instance, the equivalent of an “expiration provision”, expressed as structured data, might look something like this:
<Option_Expiration_Date : 01-15-2015>
The parties made this contract term readable by a computer by agreeing to always express the concept of an “expiration date” in one, specific, rigid, highly-structured way (as opposed the linguistic flexibility of natural languages like English).
If contracting parties can agree to express data in such a standard way, a computer can be given a set of rules by which it can reliably extract contract data such as expiration dates, buyers, sellers, etc.
Endowing Data with Legal Meaning
You might wonder, how does a piece of computer data like <Option_Expiration_Date : 01-15-2015> can acquire the legally significant meaning necessary for contracting?
There are essentially two ways that this happens. First, the contracting parties might get together ahead of time and agree that computer data in the format “<Option_Expiration_Date : Date>” should always be interpreted as “the option contract will expire after the date listed.”
Alternatively the parties, might agree to adhere to a pre-existing data standard in which contract terms have been previously well defined. Standardization groups often design standards and protocols that others can adhere to. For example, many modern, electronically-traded financial contracts are expressed as data according to the predefined FIX protocol and other data standards.
Pretty much any computer data format or language can be used for this purpose as long at it is structured (has a well-defined, consistent format). For example, others have written about using the structured data format XML for this purpose.
Note that data-oriented contracting is not always conducted completely as computer data, but rather can involve a mix of “traditional” English contracts and data-oriented contracts. Data-oriented contracting is sometimes built upon traditional, English language “master agreements which serve as the foundation for subsequent electronic, data-oriented contracting.
In sum, the first step to creating a computable contract is data-oriented contracting. This means that contracting parties express some or all of their contract terms as data (the language of computers), rather than in legal-English (the language of people).
Step 2 – Semantic Contract Terms
We just discussed how people come to understand the meaning of contract terms expressed as data. How do computers come to understand the meaning of such contract terms? The second step to creating computable contracts is to create “Semantic Contract Terms.”
Computable Contracts Explained – Part 1
I had the occasion to teach “Computable Contracts” to the Stanford Class on Legal Informatics recently. Although I have written about computable contracts here, I thought I’d explain the concept in a more accessible form.
(Part 2 of “Computable Contracts Explained” is found here)
I. Overview: What is a Computable Contract?
What is a Computable Contract? In brief, a computable contract is a contract that a computer can “understand.” In some instances, a computer can automatically assess whether the terms of a computable contract have been met.
How can computers understand contracts? Here is the short answer (a more in-depth explanation appears below). First, the concept of a computer “understanding” a contract is largely a metaphor. The computer is not understanding the contract at the same deep conceptual or symbolic level as a literate person, but in a more limited sense. Contracting parties express their contract in the language of computers – data – which allows the computer to reliably identify the contract components and subjects. The parties also provide the computer with a series of rules that allow the computer to react in a sensible way that is consistent with the underlying meaning of the contractual promises.
Aren’t contracts complex, abstract, and executed in environments of legal and factual uncertainty? Some are, but some aren’t. The short answer here is that essentially, the contracts that are made computable don’t involve the abstract, difficult or relatively uncertain legal topics that tend to occupy lawyers. Rather (for the moment at least), computers are typically given contract terms and conditions with relatively well-defined subjects and determinable criteria that tend not to involve significant legal or factual uncertainty in the average case.
For this reason, there are limits to computable contracts: only small subsets of contracting scenarios can be made computable. However, it turns out that these contexts are economically significant. Not all contracts can be made computable, but importantly, some can.
Importance of Computable Contracts
There are a few reasons to pay attention to computable contracts. For one, they have been quietly appearing in many industries, from finance to e-commerce. Over the past 10 years, for instance, many modern contracts to purchase financial instruments (e.g. equities or derivatives) have transformed from traditional to electronic, “data-oriented” computable contracts. Were you to examine a typical contract to purchase a standardized financial instrument these days, you would find that it looked more like a computer database record (i.e. computer data), and less like lawyerly writing on a document.
Computable contracts also have new properties that traditional, English-language, paper contracts do not have. I will describe this in more depth in the next post, but in short, computable contracts can serve as inputs to other computer systems. For instance, a risk management system at a financial firm can take computable contracts as direct inputs for analysis, because, unlike traditional English contracts, computable contracts are data objects themselves.
II. Computable Contracts in More Detail
Having had a brief overview of computable contracts, the next few parts will discuss computable contracts in more detail.
A. What is a Computable Contract?
To understand computable contracts, it is helpful to start with a simple definition of a contract generally.
A contract (roughly speaking) is a promise to do something in the future, usually according to some specified terms or conditions, with legal consequences if the promise is not performed. For example, “I promise to sell you 100 shares of Apple stock for $400 per share on January 10, 2015.”
A computable contract is a contract that has been deliberately expressed by the contracting parties in such a way that a computer can:
1) understand what the contract is about;
2) determine whether or not the contract’s promises have been complied with (in some cases).
How can a computer “understand” a contract, and how can compliance legal obligations be “computed” electronically?
To understand this, it is crucial to first understand the particular problems that computable contracts were developed to address.
Patent Law’s Definiteness Requirement Has New Bite
The Supreme Court may have shaken up patent law quite a bit with its recent opinion in the Nautilus v. Biosig case (June 2, 2014).
At issue was patent law’s “definiteness” requirement, which is related to patent boundaries. As I (and others) have argued, uncertainty about patent boundaries (due to vague, broad and ambiguous claim language), and lack of notice as to the bounds of patent rights, is a major problem in patent law.
I will briefly explain patent law’s definiteness requirement, and then how the Supreme Court’s new definiteness standard may prove to be a significant change in patent law. In short – many patent claims – particularly those with vague or ambiguous language – may now be vulnerable to invalidity attacks following the Supreme Court’s new standard.
Patent Claims: Words Describing Inventions
In order to understand “definiteness”, it’s important to start with some patent law basics. Patent law gives the patent holder exclusive rights over inventions – the right to prevent others from making, selling, or using a patented invention. How do we know what inventions are covered by a particular patent? They are described in the patent claims.
Notably, patent claims describe the inventions that they cover using (primarily) words.
For instance, in the Supreme Court case at issue, the patent holder – Biosig – patented an invention – a heart-rate monitor. Their patent used the following claim language to delineate their invention :
I claim a heart rate monitor for use in association with exercise apparatus comprising…
a live electrode
and a first common electrode mounted on said first half
In spaced relationship with each other…”
So basically, the invention claimed was the kind of heart rate monitor that you might find on a treadmill. The portion of the claim above described one part of the overall invention – two electrodes separated by some amount of space. Presumably the exercising person holds on to these electrodes as she exercises, and the device reads the heart rate.
( Note: only a small part of the patent claim is shown – the actual claim is much longer)
Patent Infringement: Comparing Words to Physical Products
So what is the relationship between the words of a patent claim and patent infringement?
In a typical patent infringement lawsuit, the patent holder alleges that the defendant is making or selling some product or process (here a product) that is covered by the language of a patent claim (the “accused product”). To determine literal patent infringement, we compare the words of the patent claim to the defendant’s product, to see if the defendant’s product corresponds to what is delineated in the plaintiff’s patent claims.
For instance, in this case, Biosig alleged that Nautilus was selling a competing, infringing heart-rate monitor. Literal patent infringement would be determined by comparing the words of Biosig’s patent claim (e.g. “a heart rate monitor with a live electrode…”) to a physical object – the competing heart-rate monitor product that Nautilus was selling (e.g. does Nautilus’ heart rate monitor have a part that can be considered a “live electrode”)?
Literal patent infringement is determined by systematically marching through each element (or described part) in Biosig’s patent claim, and comparing it to Nautilus’s competing product. If Nautilus’ competing product has every one of the “elements” (or parts) listed in Biosig’s patent claim, then Nautilus’s product would literally infringe Biosig’s patent claim.
If patent infringement is found, a patent holder can receive damages or in some cases, use the power of the court to prevent the competitor from selling the product through an injunction.
Patent Claims – A Delicate Balance with Words
Writing patent claims involves a delicate balance. On the one hand, a patent claim must be written in broad enough language that such a patent claim will cover competitors’ future products.
Why? Well, imagine that Biosig had written their patent claim narrowly. This would mean that in place of the broad language actually used (e.g. “electrodes in a spaced relationship”), Biosig had instead described the particular characteristics of the heart-rate monitor product that Biosig sold. For instance, if Biosig’s heart-rate monitor product had two electrodes that were located exactly 4 inches apart, Biosig could have written their patent claim with language saying, “We claim a heart rate monitor with two electrodes exactly 4 inches apart” rather than the general language they actually used, the two electrodes separated by a “spaced relationship”
However, had Biosig written such a narrow patent, it might not be commercially valuable. Competing makers of heart rate monitors such as Nautilus could easily change their products to “invent around” the claim so as not to infringe. A competitor might be able to avoid literally infringing by creating a heart-rate monitor with electrodes that were 8 inches apart. For literal infringement purposes, a device with electrodes 8 inches apart would not literally infringe a patent that claims electrodes “exactly 4 inches apart.”
From a patent holder’s perspective, it is not ideal to write a patent claim too narrowly, because for a patent to be valuable, it has to be broad enough to cover the future products of your competitors in such a way that they can’t easily “invent around” and avoid infringement. A patent claim is only as valuable (trolls aside) as the products or processes that fall under the patent claim words. If you have a patent, but its claims do not cover any actual products or processes in the world because it is written too narrowly, it will not be commercially valuable.
Thus, general or abstract words (like “spaced relationship”) are often beneficial for patent holders, because they are often linguistically flexible enough to cover more variations of competitors’ future products.
Patent Uncertainty – Bad for Competitors (and the Public)
By contrast, general, broad, or abstract claim words are often not good for competitors (or the public generally). Patent claims delineate the boundaries or “metes-and-bounds” of patent legal rights Other firms would like to know where their competitors’ patent rights begin and end. This is so that they can estimate their risk of patent liability, know when to license, and in some cases, make products that avoid infringing their competitors’ patents.
However, when patent claim words are abstract, or highly uncertain, or have multiple plausible interpretations, firms cannot easily determine where their competitor’s patent rights end, and where they have the freedom to operate. This can create a zone of uncertainty around research and development generally in certain areas of invention, perhaps reducing overall inventive activity for the public.
Welcome. I have recently started this blog in which I will be posting occasional commentary on intellectual property law, legal informatics, legal automation, and privacy law.
Recently I have started to focus my research interests more in legal automation, especially those involving machine learning and law , and computable law.