By Michael Barr
Note: This article offers practical guidance for attorneys engaging technical experts. It is general commentary, not legal advice. Consult counsel about any specific matter.
I have spent most of my career explaining embedded systems to people who did not grow up inside them: graduate students in my operating systems courses, working engineers who read the magazine I edited, and, eventually, jurors in courtrooms. Each audience taught me something, but the audience that concentrates the mind most is a single federal judge who is about to fix the meaning of the words in a patent claim, and who needs to understand your field before ruling.
Because in most patent cases, the outcome is decided long before the jury is seated. It is decided at claim construction, when the judge fixes what the disputed claim terms mean. Those words are the boundary of the invention. A single construction of a term like "processor," "module," "coupled to," or "substantially in real time" can turn a strong infringement read into no infringement, or a dead patent into a live one. The proceeding where that boundary gets set is the Markman hearing, named for the Supreme Court decision holding that claim construction is a question of law for the judge, not the jury.
And the single most useful thing an expert and counsel can put in front of the judge before that hearing is not a brief. It is a technology tutorial.
The short version: a technology tutorial is a neutral, teaching-first primer on how the technology at issue actually works, delivered to the judge before claim construction is argued. It exists because the judge must understand the field to rule, and it succeeds or fails on one quality: whether the judge comes away trusting the teacher.
What a Markman hearing actually decides
At the Markman hearing, the parties identify the claim terms they dispute, brief their proposed constructions, and argue them to the judge, who issues a claim construction order. The judge reads the disputed terms in light of the claim language, the specification, and the prosecution history, and may consider extrinsic evidence such as expert testimony.
This hearing is decisive for a simple pair of reasons. The judge is deciding a question of law, so there is no jury to persuade and no factual deference to hide behind; the judge personally has to understand the technology well enough to rule. And the ruling controls everything downstream. A term construed narrowly can read the accused product out of the claim. A term construed broadly can pull prior art into the claim and sink validity. Litigators who have watched a case turn on one word know this is where much of the real fighting happens.
The catch: the judge deciding these questions is usually not an engineer. A federal judge may be brilliant and may have presided over a hundred patent cases, but is unlikely to have written firmware, designed a logic circuit, or traced a network protocol. Before ruling on what "clock signal" or "dynamically allocated" means in a claim, the judge needs to know what those things are in the real world. That is the gap the tutorial fills.
What a technology tutorial is, and what it is not
A technology tutorial is an educational primer on the technology at issue, prepared for the judge around the time of claim construction. It teaches the field: how the technology works, what the moving parts are, what the words of art mean to an engineer, and how the patented system fits into that landscape. It is background, delivered before the disputed terms are argued, so the judge has the mental model needed to follow the argument.
It is not advocacy. It is not the place to argue that a claim term should be construed your client's way. The test I hold my own tutorials to is this: could a neutral engineer with no stake in the outcome have prepared this? An engineer explains the technology to a smart colleague from another field. A partisan frames it to win. Judges can tell the difference, usually within minutes.
Formats vary, and judges have preferences. Some want live tutorial testimony from each side's expert, sometimes with the judge asking questions directly. Some want a joint or narrated video both sides have seen in advance. Some want slides, some want a written primer, some fold the tutorial into the Markman hearing itself, and some want it days or weeks earlier so the teaching and the arguing do not blur. The first practical step is always to learn how this specific judge likes to be taught. A tutorial the judge did not ask for, in a format the judge dislikes, spends goodwill instead of building it.
When the court brings in its own engineer
Some judges close the technical gap a second way: they appoint a neutral of their own. It is worth knowing the difference, because the two appointments carry very different weight.
A technical advisor is retained to educate the court. The advisor tutors the judge on the technology, answers the questions a judge may not want to ask in open court, and takes no position on the disputed terms. There is no report and no recommendation; the judge still decides. A special master under Rule 53 is a formal appointment that can go considerably further, since the court can delegate specified tasks and ask for findings or a report and recommendation on matters that may include claim construction itself.
Neither is common. Most patent cases have neither, and courts are generally careful about appointing a technical advisor, mindful that a neutral who educates the judge outside the record can start to look like a decision-maker nobody cross-examined. But the possibility should shape how you prepare, for three reasons.
First, it confirms the premise of the tutorial. Courts appoint neutrals precisely because they recognize the comprehension gap, so the party that teaches well is solving a problem the judge already knows they have. Second, it raises the cost of a slanted tutorial: a court-appointed engineer is exactly the reader who will notice a primer bending toward one construction, and will say so privately to the judge. Third, it changes the audience. If an advisor is in place, your expert is teaching a fellow engineer as well as the judge, and the shading a lay reader might miss will not survive that second set of eyes.
The practical consequence is the same one that runs through this piece, only sharper: build the tutorial so it would hold up if a neutral engineer read it line by line. Sometimes one will.
Why judges reward a neutral, teaching tone
Judges reward the tutorial that helps them and distrust the one that tries to work them. A judge who senses that a supposedly neutral primer is quietly steering toward one construction stops trusting the teacher, and then stops trusting the teacher on the merits too.
Understand what the tutorial really is: an early and unusually pure test of the expert's credibility, taken before the adversarial positions are locked in. An expert who teaches cleanly, concedes what the other side will reasonably say, and does not overreach earns the judge's confidence that this witness explains technology straight. That confidence carries into the disputed terms and later into trial. An expert who uses the tutorial to smuggle in argument has spent that credibility before the real fight begins.
Restraint here is not weakness. It is the whole strategy.
What makes a strong tutorial
The qualities are easy to name and hard to execute:
-
Clarity without distortion. Genuinely accessible to a non-engineer, without achieving accessibility by saying something false. Every simplification is one an honest engineer would stand behind.
-
Accuracy the other side cannot attack. If opposing counsel can stand up and correct a factual claim, the tutorial has damaged its own side. Neutral accuracy is armor.
-
Restraint at the edge of the disputed terms. The strong tutorial walks right up to the terms that will be argued and stops. Vocabulary and mental model, yes. The answer, no.
-
Analogies that illuminate without misleading. My test for an analogy: would the other side's expert accept it as fair? A good one makes an unfamiliar mechanism intuitive. A bad one quietly imports assumptions that favor one construction, and it will be found out.
-
The right depth. Enough that the judge can follow the argument, not everything the expert knows. The tutorial teaches what the case needs.
-
Anticipation of the fight without joining it. The best tutorials make sure the judge precisely understands the technical concept the parties are about to disagree over, while staying scrupulously neutral on the disagreement itself.
-
A teacher, visibly at ease. The judge should come away thinking this witness enjoys explaining things and has nothing to hide. That impression is worth more than any single point in the primer.
How a bad tutorial loses ground
The failure modes are mirror images, and each costs more than it looks. The most common is the tutorial that reads as partisan, an argument wearing a lab coat; judges see through it quickly and the expert pays in credibility for the rest of the case. Next is the expert who confuses instead of teaches, burying the judge in jargon or failing a direct question in plain terms. A confused judge is a dangerous judge, because uncertainty resolves in unpredictable directions. Overreaching into the construction itself invites the objection that the expert is doing law rather than technology. Oversimplifying into inaccuracy hands the other side an easy correction and makes the judge wonder what else was shaded.
And underneath them all: picking the wrong expert. A formidable analyst who cannot teach can write an excellent report and still lose the room. If your expert cannot make the invention clear to your paralegal, do not put that expert in front of the judge.
Why the right expert matters most here
The tutorial exposes, more than any other moment in a case, whether the expert can teach. A source code review or a validity opinion rewards analytical depth, worked in private. The tutorial is live, pitched to a non-engineer, and rewards a different gift: holding real command of embedded systems, semiconductors, or networking while making a federal judge feel the subject just became clear.
That pairing of depth and teaching is the same quality that separates a strong trial witness from a merely qualified one, and it is why we test for it explicitly in our guide to vetting a source code review team. For claim construction, the teaching half moves to the front. The patent infringement and software copyright matters that turn on claim scope are exactly the matters where a clear, neutral tutorial pays for itself.
What we do at Barr Group
Our electronics and software expert witnesses are working engineers who also teach, and we treat the technology tutorial as its own deliverable rather than an afterthought to the Markman brief. We match the expert to the technology, from firmware and real-time systems to logic design and networking, so the person teaching the judge has genuine command of the field. We build the tutorial to be neutral on its face: accurate, restrained at the edge of the disputed terms, free of partisan tilt. We prepare for the format the specific judge prefers, and we keep the tutorial consistent with the expert reports and testimony and the underlying source code review that follow, so the technical story stays straight from claim construction through trial.
The hour that decides the case
Claim construction decides patent cases, and the judge who decides it usually needs to be taught the technology first. The tutorial is one of the highest-leverage half-days in the entire case: done well, it earns the judge's trust before a single term is argued; done badly, it spends credibility the expert cannot buy back. Pick an expert who can teach, not just analyze. Insist on a tutorial that could pass as the work of a neutral engineer. And treat the hour in front of the judge as what it is: the moment the case may actually be won.
Barr Group's team of electronics and software expert witnesses provide experienced and unbiased source code reviews, expert reports and testimony for product liability, patent infringement, software copyright, and trade secrets litigation involving computer-based technology and software. HIRE AN EXPERT
Get a matched recommendation >
Free, confidential, conflicts-checked, and our fee is built into the expert's hourly rate, so we are paid only if you retain.