Articles about intellectual property litigation and technical expert witnesses.
Note: These articles offer practical guidance for attorneys engaging technical experts. They are general commentary, not legal advice. Discussion of specific litigation is drawn from publicly available court records and published reports. Consult counsel about any specific matter.
Some lawyers call us first. Others call us when it's urgent. The call often starts the same way: an attorney has searched on their own, the right expert hasn't turned up, and the case can't wait.
By Michael Barr
The deposition of a technical expert is usually won or lost in the three weeks before it. Not in the deposition itself, and not in the last-minute session the night before. By the time the court reporter swears the witness in, the report is served, the exhibits are fixed, and most of what opposing counsel will use has been sitting in the file for months.
By Michael Barr
The easy software copyright case is the one where the files match. Somebody took the source, changed the header comment, and shipped it. An expert can put the two listings side by side and the argument is essentially over.
By Michael Barr
As a consultant, I think with the trial team. I can tell them a theory is weak, that a document cuts against us more than counsel realizes, or that the honest reading of the code doesn't support what someone hoped it would. As a testifying expert, everything I look at (and much of what I write) is something opposing counsel may hold up at deposition. Both roles are useful. Confusing them is expensive.
Breach cases have an unusual problem. In most technical litigation the evidence sits still and waits for you. In a breach, the evidence is a set of logs that were designed for operational troubleshooting rather than for proof, that were retained for as long as somebody's storage budget allowed, and that describe an event which the defendant was actively trying to stop while the record was being written.
The first safety-critical firmware I worked on had a watchdog timer, a set of self-tests, and a review process that felt, at the time, unusually strict. Years later I would spend a great deal of time reading other people's automotive firmware in litigation, and I learned something that surprised me: the strictness of a process tells you far less about the safety of the resulting product than most people assume, and the paperwork proving the process was followed is not the same evidence as the code itself.
My first engineering job was writing firmware for chips that other people had designed. I lived inside their datasheets, I built workarounds for their errata, and when a product misbehaved at two in the morning I had to settle one question before I could fix anything: was the fault in my code, or in the silicon underneath it?
In 2008 I wrote down a set of C coding rules because engineering teams kept arguing about the wrong things: a morning spent debating brace placement, and not one minute on the volatile keyword, which is the kind of omission that produces a field failure nobody can reproduce. The rules became the Embedded C Coding Standard, better known as BARR-C.
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.