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.
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.
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.
The most important facts in a software or electronics dispute are usually locked inside a product nobody will hand over. The accused device ships as a sealed board and a stripped binary. The protocol is undocumented. The chip at the center of the case is a black box the size of a fingernail.
I once spent the better part of two days on the witness stand in an Oklahoma courtroom, explaining to a jury what my team had found inside the engine control software of a Toyota Camry. The jurors were not engineers.
When two software companies collaborate on a joint venture, they inevitably share confidential technical information. What happens when that collaboration ends and one party's proprietary techniques turn up in the other's products?
Generative AI has quickly become a research aid and first-draft writer for many people involved in modern work, and litigation is no exception. A recent federal decision is a sharp reminder that the convenience carries a question few have stopped to ask: when someone types into a publicly available AI tool, are they creating a confidential work product, or a discoverable record?