Why Database Architecture Matters

In 2020, Docket Navigator engaged Feit Consulting to compare Docket Navigator with its closest competitor. Feit recruited seasoned researchers from AmLaw 50 law firms who compared Docket Navigator and the other platform using 10 real-world research questions. The researchers concluded that Docket Navigator outperformed the other platform on 9 of the 10 questions and tied on one other. The primary reason, Feit concluded, was Docket Navigator’s database architecture; how the data points are collected, and how they are connected to other related data points.

The following review highlights the inner workings of Docket Navigator’s architecture and shows how it models real-world patent litigation to answer difficult legal research questions.

Patent infringement cases may contain any number of infringement claims involving multiple patents and multiple accused parties. Each infringement claim could have a different outcome. For example, a plaintiff could win on some patents and lose on others. A plaintiff could win against some defendants and lose against others.

To model these claims individually, Docket Navigator created “Patent Accusations,” a group of related data fields that model the essential elements of a patent infringement claim:

1. the party that claims the right to assert a patent,
2. the patent number, and
3. the party accused of infringing or who is otherwise challenging the patent.

Every day, Docket Navigator’s human editors read through new pleadings in patent cases, extract the above data fields and enter them into Docket Navigator using internal data entry tools. At the end of a case, our editors add a fourth data field, an “Accusation Outcome,” indicating how the Patent Accusation was resolved. Here is how these four data fields appear in Docket Navigator in the data entry tool.

Recording these four data fields for each infringement claim allows Docket Navigator to answer real-world questions like: How many patents has Apple Inc. asserted in U.S. district court cases? With Docket Navigator’s detailed architecture, it is easy to search for all Patent Accusations in U.S. district court cases in which Apple Inc. is the Patentee.

Claim construction is a patent specific process by which the court defines or “construes” disputed claim terms. In many cases, claim construction can be case-dispositive, so creating a record of how individual claim terms have been construed can be highly informative.

Many courts conduct claim construction after a hearing using a special order called a “claim construction order,” or a “Markman order.” But other courts prefer to conduct claim construction in the context of summary judgment or other dispositive motions. Typically, these orders will identify the patent, the claim term (or phrase) in dispute, and the court’s construction of the term (or phrase).

Searching court records for claim constructions presents a unique challenge because many claim terms consist of common words with multiple meanings used in many contexts outside the claim construction process. For example, connect, network, and memory are common claim terms that are also commonly used in court documents outside the claim construction process. As a result, conducting text searches of court documents often generates more false hits than positive.

To model this claim construction process, Docket Navigator created “Claim Constructions” which consists of a group of related data fields that model the essential components of claim construction:

1. the patent whose claim term is being construed,
2. the claim term in dispute,
3. the court’s construction of the disputed term, and
4. the page of the order containing the construction.

Every day, Docket Navigator’s human editors read through every new decision in a patent case. When they discover a claim construction – whether it be in a Markman order or other order – they enter the data described above by hand into a specially designed interface. The claim construction data is then connected to the case, judge, court and document in which the terms were construed. Here is how these four data fields appear in Docket Navigator in the data entry tool.

Recording these four data fields for each claim construction allows Docket Navigator to answer real-world questions like: “How many times has the claim term ‘individual’ been construed, and what were those constructions?” or “How has Judge Albright construed the term “network”? Docket Navigator users can click the Claim Constructions category on the main search page, enter a specific claim term and receive a list of every construction of that term going back to the year 2000. Completely accurate results with no false hits.

Artificial intelligence has a much better chance of finding specific rulings, even rulings that rely on specific legal concepts as a basis for the decision. The problem though is the degree of granularity that AI can provide. For example, it is easy for a machine to distinguish if a court order is ruling on a motion for summary judgment. Where it falters though is differentiating the various types of MSJs being ruled on. Is it an MSJ for infringement, or for non-infringement? A human being can make that distinction easily, which is how Docket Navigator is able to track those and hundreds of other motion types comprehensively.

As with Markman orders, at Docket Navigator a human being reads every MSJ ruling that occurs in patent cases, enters the specific type of MSJ, the result of the ruling, the legal concepts used as a basis for the ruling, the judge that signed it, etc. Because each of these data fields are entered separately, but linked together, users can click on the Documents search, select any type of MSJ ruling (Docket Navigator tracks over a dozen types) and find all such rulings in a few seconds by a specific court, judge or even in cases involving a specific firm or attorney. Entering the data at this fine level of granularity is what makes answering the question “How many U.S. district court decisions have addressed motions for summary judgment asserting patent invalidity based on lack of patentable subject matter under 35 USC § 101?” a snap with Docket Navigator.

Another failure of artificial intelligence when it comes to processing legal documents is its inability to discern the “posture” of a motion, meaning the way a motion is teed up to the court. Is the motion contested? Stipulated? Sua sponte? Renewed? The posture of a motion has a great impact on the court’s willingness to grant or deny it.

The posture of a motion has a great impact on the court’s willingness to grant or deny it.

For example, contested motions to stay pending an inter partes review are granted only 43% of the time. However, stipulated motions of the same type are granted a whopping 94% of the time. When advising clients on a judge’s track record for a specific type of motion, it only makes sense to compare apples to apples. If your motion is contested, it would not make sense to rely on historical data based on stipulated motions. The ability to exclude or include specific postures in search results is vital when building a strategy.

In the Docket Navigator platform, court rulings are diagrammed with several different components, but the four main components are (i) the posture (how the motion was presented), (ii) the type of motion (the procedural tool used to request relief), (iii) the result (how the court ruled on the motion), and (iv) legal issues (the legal concepts addressed in the court’s ruling). Because those exist as four different data points, users can filter by just one of them, or use any combination of the four. This model is called a “Document Filter Group,” and this is how it appears in the user interface, using the contested motion to stay pending IPR as an example:

By designing the data in this way, questions such as “How many rulings on original, contested motions to stay pending IPR have there been?” take only a few seconds to answer, comprehensively, in the Docket Navigator platform.

Perhaps the most difficult question for machines to answer when it comes to a patent case is “Who owns the patent being asserted?”  Many platforms assume that it’s always the plaintiff, but of course that is not the case with declaratory judgment cases.  And what happens when there are claims and counterclaims with both plaintiff and defendant asserting patents against each other?  This is why Docket Navigator created Patent Accusations. 

Perhaps the most difficult question for machines to answer when it comes to a patent case is “Who owns the patent being asserted?”

In a Patent Case, an Accusation is a request for relief, the resolution of which could determine if a patent has been infringed or the patent’s validity or enforceability.   

Docket Navigator models Patent Accusations by using three main components, (i) the party that owns the patent at issue, (ii) the patent number, and (iii) the party challenging the patent at issue.  The combination of those three components form one Patent Accusation. 

For example, a case with one plaintiff asserting one patent against one defendant would involve one Accusation. A case with one plaintiff asserting 5 patents against 10 defendants would result in 50 Accusations. 

Here is an example of some common Accusation scenarios: 

Entering parties and patents based on the model above is what allows Docket Navigator to answer the question “How many patents has Apple Inc. asserted in U.S. district court cases?” 

Although artificial intelligence certainly has its place in the research and practice of law and should be used whenever possible, it’s important to differentiate where AI shines and where it fails.  In the majority of the research questions surveyed in Feit’s study, it is readily apparent that the human component in finding, understanding, modeling and organizing data is a critical part of producing accurate, comprehensive search results.  

Although artificial intelligence certainly has its place in the research and practice of law and should be used whenever possible, it’s important to differentiate where AI shines and where it fails.