In a recent blog article, Professor Anthony Finkelstein, Dean of Engineering Sciences at University College London, commented: “I simply cannot understand how disciplines that struggle with complexity – law being a case in point – are able to do without [diagrams]. So many problems could be better explained, so much more material readily assimilated, and the route to analysis and problem solving smoothed, if a diagram were used.”
This prompted several memories of situations in which IP Draughts has worked with colleagues who have an engineering training, both lawyers and non-lawyers. In IP Draughts’ experience, a combination of legal and engineering thinking can be a very powerful tool in problem solving. Just having one or the other discipline, though, can lead to mutual bafflement when lawyers and engineers mingle.
A good example of the combined approach can be found in the structure and content of a legal textbook, Chartered Institute of Patent Attorneys’ Guide to the Patents Acts. IP Draughts has reviewed this book in the latest edition of the Journal of Intellectual Property Law and Practice. In his review, IP Draughts comments:
The CIPA Guide is more like an instruction manual, written by engineers for engineers, than an extended essay written by classicists for classicists. The approach of the CIPA Guide is unusual among law books, but well-suited to the area of patent law.
An example of mutual bafflement is an experience that IP Draughts had over 20 years ago, in a conference room in San Francisco. IP Draughts was negotiating the terms of a trade mark licence agreement with a roomful of computer scientists from about a dozen computer companies, including IBM and some other large players. IP Draughts’ client was a trade association that had developed standards of “open-ness” for UNIX-based computer systems. Companies that met the standards were to be permitted to apply the trade association’s branding to their computer systems, under the terms of this licence agreement. The companies were very keen to ensure that the terms of the licence agreement were appropriate.
During a line-by-line negotiation of the draft licence agreement, which took several days, one of the computer scientists piped up to complain that IP Draughts had included a “forward reference” in one of the clauses. In other words, the clause used a defined term, but the term was not defined until a later clause.
In [traditional?] computer programming, if you use a defined term before defining the term, the program won’t work – it will “crash”. Fortunately, judges have more mental flexibility than a computer, and can look forwards and backwards. IP Draughts explained this to the computer scientist and the discussion moved on. This small incident reminded IP Draughts that contracts and computer programs have many similarities, but also some significant differences.
In IP Draughts’ experience, engineers sometimes express frustration that a lawyer cannot say with certainty how a contract term will be interpreted by the court. Sometimes, this leads to unfavourable comments about the quality of judges and the desirability of replacing them with computers. Usually such comments (and IP Draughts has heard this type of comment on several occasions) overlook the human element – not just the variability in outlook (and, dare we say it aloud, quality of contractual analysis) among judges, but more importantly the human element in how the parties to a contract behave. Sometimes, neither party complies strictly with their contractual obligations, and the task of the court is far more complex than just “cranking the handle”. Issues such as waiver, good faith, misrepresentation, mistake, failure to comply with contractual procedures, variation by conduct, and the rest may have to be considered. There is also the problem that contracts are based on words, and words can have many subtle or not-so-subtle variations in meaning, depending on usage and context, as the recent criminal trial of John Terry (former captain of the English football team) shows.
Coming back to diagrams, IP Draughts is in favour of anything that may aid the parties’ understanding of their legal obligations. He sometimes include mathematical formulae in contracts, eg in payment clauses, but has not seen many diagrams being used. In principle, there is no reason why they should not be used. If flow charts are used, there may need to be a definition or cross-reference to any protocols that are used in the flow chart, eg as to the significance of the shape of an individual box. If both text and a diagram are used to cover the same point, the contract should make clear which takes precedence, in case they vary in meaning.