Why Wishes Should Be Patentable

Robert Plotkin, author of "The Genie in the Machine"

Critics of software patents often argue that software should not be patentable because software is too “abstract” to be patented. The patent system was created to protect nuts-and-bolts machines like the steam engine and the cotton gin, not “intangible” creations like software, so the argument goes. In this article I will argue that not only should software be patentable, but that inventions that are even more “abstract” should be patentable – inventions that I call “wishes” in my recent book, The Genie in the Machine: How Computer-Automated Inventing is Revolutionizing Law and Business.

Chuck Connell did an excellent job of laying out why arguments against software patents miss the mark in his recent posting on this blog, entitled Is Software Patentable? Let me add to what he said by pointing out that the software in a physical computer is not “abstract” or “intangible”: it is as concrete and tangible as a cotton gin in the senses that are relevant to patent law. Consider anti-lock braking software installed in the anti-lock braking system of a car. Such a system includes both a processor and a memory in which the anti-lock braking software is installed. Everyone agrees that the processor and memory are concrete and tangible. Yet the “software” that is “installed” in the memory is simply the collection of switches in the memory which have been flipped into a particular pattern to cause the processor to behave as an anti-lock braking controller. If the memory itself is concrete and tangible, then certainly a subset of the memory is also concrete and tangible.

Although you could (and many do) argue that the software in this case is the pattern of flipped switches and therefore is intangible, this is what philosophers like to call a “category mistake,” and if taken seriously, leads to the conclusion that nothing is patentable. After all, consider a watch gear that is novel and nonobvious because of the pattern of its teeth, which causes it to turn more efficiently inside the watch. I suppose you could argue that this tooth pattern is abstract and intangible, thereby rendering the gear unpatentable. The same could be said of every physical device which has ever been patented. The problem with this argument is that although it may be true that an abstract or intangible pattern may be embodied in the gear, the gear itself is both concrete and tangible, and is capable of performing a useful function in the real world. The same is true of a computer memory which has been programmed with a particular piece of software. Therefore, software installed in the physical memory of a computer should be considered just as concrete and tangible as any traditional mechanical device for patent law’s purposes.

“But wait,” you say, “the problem with software patents isn’t that software is too abstract, it’s that software patents are written too broadly and abstractly.” Abstraction, however, isn’t necessarily a problem in patents. In fact, the whole point of a patent claim is to abstract from the implementation details of the various embodiments of the invention and point out the general features of the invention that make it useful, novel, and nonobvious. Going back to my watch gear example, if the pattern of teeth on my gear makes it useful, novel, and nonobvious, then patent law entitles me to obtain a patent claim written relatively abstractly to cover gears having the novel pattern. Such a claim will generally be interpreted to cover various gears having the same pattern, even if they vary in size, material, and other features. This kind of abstraction is well-accepted within patent law, and does not necessarily lead to unclear or overly broad patents. As computer scientist Edsger Dijkstra said, “the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise.”

This isn’t to say that software doesn’t raise some new and challenging problems for patent law. In The Genie in the Machine, I use the engineer’s “waterfall model” of design as a framework for thinking about the similarities and differences between abstraction in mechanical patents and abstraction in software patents. In a nutshell, the waterfall model defines several sequential stages for solving a problem, such as: (1) Problem Definition; (2) Requirements Analysis; (3) Functional Design; and (4) Structural Design. Traditional mechanical patent claims are often written to a high degree of abstraction within the realm of the final stage of Structural Design. The law typically limits (but does not entirely prevent) the ability to cross the line into claims written at the Functional Design level of abstraction.

Modern computers enable programmers to engage in stages (1)-(3), resulting in written computer source code, which is essentially a Functional Design specification from the perspective of traditional engineering. The programmer can then hand off the source code to a computer, which automatically creates executable software that can perform the functions described in the source code. In this sense computers have automated, or eliminated the need to engage in, the final stage of Structural Design for that class of problems which can be solved by computer programming. It should be no surprise, then, that software patent specifications and claims are typically written at the level of Functional Design – this is the level of abstraction at which software developers conceive of and create software. As I argue in The Genie in the Machine, patent law’s traditional aversion to patents written at this higher level of abstraction should be relaxed to the extent that purely functional descriptions of software can actually enable those having ordinary skill in the art to make and use the invention – which is not often the case for purely functional descriptions of mechanical devices. Similarly, functionally-worded software patent claims can (if written appropriately) provide the public with clear notice of what has been invented and therefore should not be rejected out of hand for being “too abstract” in some absolute sense.

This all leads to the “wish patents” that I mentioned at the beginning of this article. As computers continue to further automate the process of inventing, it is becoming possible for an inventor to create a new, useful, and nonobvious machine merely by writing an even more abstract description – such as a description of the problem to be solved or the requirements to be satisfied – and then providing that description to a computer, which produces a concrete design for a machine that solves the problem or satisfies the requirements. I provide many examples of such “artificial invention” technology and the inventions it has produced in The Genie in the Machine.

For example, the inventor might tell the computer – in a computer-understandable form – that he needs an antenna that can transmit signals having specified properties within a certain range of frequencies, and that weighs less than two ounces. This description is an example of what I have been calling a “wish.” If all goes well, the computer churns for a while and then produces a digital design for an antenna that satisfies the criteria specified by the wish.

One question raised by such technologies is whether such artificial wishes themselves should be patentable. Of course, many such wishes will fail to be novel or nonobvious. In practice it may be very difficult to come up with a novel and nonobvious wish. In many fields, the problems to be solved and the requirements to be satisfied are well known, and what engineers spend their time doing is figuring out how to satisfy those requirements with specific product designs. In such cases, patent law’s novelty and nonobviousness requirements will stop wish patent applications at the gate.

What should happen, however, if someone does come up with a useful, novel, and nonobvious wish that can be provided to a computer to create designs for a whole new class of products? Should the creator of such a wish be entitled to a patent on the entire class of products? In short, in The Genie in the Machine I argue that such patents should be allowed, assuming of course that they satisfy not only the utility, novelty, and nonobviousness requirements, but also the enablement requirement. Satisfying such requirements may prove difficult in practice, but not impossible in theory. If someone is able to satisfy them all in a particular case, then he has not only enabled a whole new class of products to be created but has taught the public how to make and use such products. The inventor should therefore be entitled to patent protection for the class of products for the same reasons that the watch gear inventor should be entitled to a patent covering the class of watches having the tooth pattern he invented.

In summary, if you thought the patent system would have a hard time dealing with the abstract nature of software patents, then you ain’t seen nothing yet. It is only a matter of time before savvy inventors start filing wish patent applications, forcing the Patent Office and the courts to grapple with them. Careful study of the history of software patents, however, can help us to head off the worst problems at the pass if we begin to work now on making sure that such patent applications are examined correctly and interpreted appropriately after they are granted.

About the Author

Robert Plotkin started programming computers when he was in fifth grade when his school received two brand new Tandy/Radio Shack TRS-80s. His first lesson was learning how to write a two-line program that would display my name repeatedly on the screen. He was hooked. Now, about a quarter of a century later, he is a full-time patent lawyer and part-time law professor, and he still spends most of my time working with and thinking about computers. He is the author of The Genie in the Machine: How Computer-Automated Invention Is Revolutionizing Law & Business, and he blogs at Automating Invention, writing about the impact of computer-automated inventing on the future of invention and patent law.