The stories appear so frequently these days that it’s practically a new genre: The lawsuit over some patent claiming monopoly on a bang-your-head-on-a-desk obvious procedure, emerging from the shadows to threaten a technology that’s long been ubiquitous. The most recent instance is likely to get some play outside the tech press because it’s resulted in an injunction that bars the sale of Microsoft Word in the United States, thanks to supposed infringement of a Canadian firm’s 1989 patent on a method for structuring data in XML documents. Microsoft is appealing, of course, though there’s a certain irony given that the company was recently awarded a similarly dubious patent on yet another aspect of XML data storage.
Skimming the patent at the heart of the injunction, it basically seems to cover the idea of storing formatting information about a document separately from the content. If you’ve ever looked at the source code to a web page, you know that in HTML, they’re generally mixed together, so in the code your browser is interpreting to display this very page, there’s a <strong> tag right before “this,” which your browser knows not to actually print, but take as the sign to turn on the boldface, and then a </strong> tag after “page” to turn it off again. Of course, some formatting information is contained separately, in the cascading style sheets used by all the pages on this site. So when I want to use a blockquote,
…the document tells your browser where to find the formatting instructions for the page, and that style sheet tells your browser exactly what to do with the <BLOCKQUOTE> tag—to render it indented with the line down the left-hand side and using (I think?) the Courier font in a slightly lighter shade than the rest of the text. The upshot of the Canadian patent is just that you can totally segregate content from formatting, so instead of a <strong> tag in the text, say, there’s either a separate section of the document, or a separate formatting document, that tells your reader program when to turn the boldface on and off. The patent also describes, in abstract terms but at considerable length, an algorithm for translating between an embedded tags structure and a segregated one. Now, there are many purposes for which this is an excellent strategy for structuring your documents, but even in 1989 I can’t believe it was the kind of innovative leap that should come with any sort of monopoly. Intuitively, at least, any program that can print out a document on different sorts of paper already has to do something like this by consulting some built-in set of specs for (say) legal-sized and letter-sized paper, then putting the page breaks in the right places. I seem to recall having this capability even in 1989. TeX, from the ’70s, formats plaintext using general rules, so the general idea is clearly nothing new; the main difference seems to be that the Canadian company wanted a monopoly on the idea of a specific set of formatting instructions keyed to a particular content text.
So how did a patent on this possibly get awarded and survive review? The rather technical-looking translation algorithm may have helped, but it surely fails to meet the standard of not being obvious to someone with ordinary skill in the relevant art (in this case, programming). Put it this way: I haven’t done any real coding since I was a teenager tweaking my dial-up BBS. I doubt I could write “hello world” in C without consulting a manual anymore. I have no kung-fu. But even with my incredibly rusty echo of a memory of how you structure a program, if you told me you needed an algorithm to convert between an embedded-tags structure and a segregated content-plus-formatting-information, I’d know the general method they describe (not specific to any particular language) is how you’d go about it.
Now, I bounced this off my friend Tim Lee, who writes quite a lot about patent policy. And I suggested that they must not have many people with programming experience working as examiners at the USPTO. But Tim thinks that’s not really the problem—the problem is that if an applicant wants to appeal, the examiner, who may well be a programmer, has to defend his subjective judgment of what’s “obvious” with some kind of explicit argument. And the result (says Tim) is that in practice the “non-obviousness” requirement has been largely conflated with a review of the “prior art” or previous related inventions. The upshot is that unless someone else has done almost exactly the same thing before, you’ve got a good shot at getting the patent. Maybe this is motivated by a version of the no-five-dollar-bills-on-the-sidewalk fallacy in economics: If nobody has done it before, it can’t have been all that obvious. But, of course, in a rapidly evolving area of technology, someone’s always going to be the first to do something obvious.
I think the source of the problem in the patent system may be linked to a point Friedrich Hayek made long ago about our tendency to overrate the economic importance of theoretical knowledge and vastly underestimate the importance of tacit or practical knowledge. The non-obviousness requirement, tied to the standard of an observer skilled in the appropriate art, is supposed to make the patent system sensitive to this kind of knowledge. But if examiners have to defend their judgments of obviousness, they’re essentially being required to translate their tacit knowledge into explicit knowledge—to turn an inarticulate knack into a formal set of rules or steps. And Hayek’s point was that this is often going to be difficult, if not impossible. Just as a loose analogy, consider that in the Principia Mathematica, Bertrand Russell and A.N. Whitehead’s attempt to provide a rigorous, formalized basis for ordinary arithmetic, it takes several hundred pages to strictly establish the proposition “1+1=2.” It takes a fairly advanced mathematical education to understand the explicit elaboration of a practice (counting, adding) that we expect most children to master.
If you ask me how I knew the way to go about writing the translation program in question, I’m not sure I could tell you—just as we sometimes find ourselves at a loss when we’re asked to give explicit directions for a route we know by heart. Things that are “obvious” are often the hardest to explain or articulate explicitly, precisely because we’re so accustomed to apprehending them by an unconscious (and possibly itself quite dizzyingly complicated) process. The very term “obvious” comes from the Latin obviam for “in the way”—that is, right in front of you, where you can’t help but see it. Except the visual processing system we “use” automatically is vastly more sophisticated than what we’re (thus far) capable of designing. If you had to describe explicitly the unconscious process by which you see what’s right in front of you, it wouldn’t seem “obvious” at all. The same, I expect, goes for the knack of knowing how to go about solving a particular problem in coding or engineering—with the result that the patent system systematically undervalues the tacit knowledge embedded in those skill sets until it’s embedded in a piece of “prior art.” So knowledge that’s widespread but implicit and inarticulate is routinely mistaken for the kind of innovation it’s necessary to incentivize with a monopoly grant. In effect, the hidden value of dispersed tacit knowledge is redistributed to the first person to render it explicit.