On October 30, 2008, the United States Court of Appeals for the Federal Circuit issued its decision in In re Bilski, which dealt a serious blow to software patents and largely did away with business method patents altogether, although there is still some room to receive a patent if the business process employs the use of a new, nonobvious and tangible computer system, but the protection would have to focused on the tangible computer system that employs an overarching architecture and not the process. I have written much about the decision of the Federal Circuit, and its wisdom, or lack thereof. For about a month I have owed Groklaw a response to some thoughtful comments regarding my opinions and beliefs, so without further ado I will try and explain my thoughts and what I would like to see moving forward. This will require a series of posts, so this post will act as Part 1.
I have been criticized quite a lot for statements I have made that computer software is not the same as math, and I simply cannot back away from that. Nevertheless, as I have read through comments provided to Groklaw I am not so sure that my critics and I are as far apart on this position as one would belief. One particularly helpful comment was made by Daniel Berinson, who has a PhD in Physics and got his degree in electrical engineering but who is also a programmer. Daniel cites to On the Interplay Between Mathematics and Programming by E. W. Dijkstra. Here are a few quotations from Dijkstra:
- “So much for the care needed to keep the arguments manageable: we can summarize it by stating that in programming mathematical elegance is not a dispensable luxury, but a matter of life and death.”
- “The programmer applies mathematical techniques in an environment with an unprecedented potential for complication; this circumstance makes him methodologically very, very conscious of the steps he takes, the notations he introduces etc.”
- “Much more than the average mathematician he is explicitly concerned with the effectiveness of this argument, much more than the average mathematician he is consciously concerned with the mathematical elegance of his argument.”
I would agree with all of this and do not see how what Dijkstra says in any way contradicts what I have said or what I believe. I think the disagreement between me and my critics is largely due to the way patent law views mathematics, which seems admittedly quite different from the way that many computer programmers view mathematics.
It is impossible to argue that software code does not employ mathematical influences, because it does. I think Dijkstra’s explanation that a “programmer applies mathematical techniques” is completely true and accurate. Having said this, the fact that mathematical techniques are employed does not as a matter of fact mean that software is mathematical. Under the US patent laws you cannot receive a patent that covers a mathematical equation or a law of nature. You can certainly use mathematical equations and laws of nature as the building blocks to create something that is new and nonobvious that is patentable. So even if software used mathematical equations there would be no prohibition against the patenting of software under a true and correct reading of the US patent laws.
The primary example defining the ability to use mathematical equations within an invention is the United States Supreme Court’s decision in Diamond v. Diehr, where the inventors claimed a method of operating molding presses during the production of rubber articles. The inventors asserted that their method ensured that articles remained within the presses for the proper amount of time. The patent examiner rejected the patent claims because it was believed that the patent claim recited a mathematical equation. The Board of Appeals within the Patent Office affirmed the examiner, but then the Court of Customs and Patent Appeals (the predecessor of the Federal Circuit) ruled that the claims were not directed to a mathematical algorithm, but rather to an improved process for molding rubber articles. The Supreme Court agreed with the CCPA and ruled that the claims were not an attempt to patent a mathematical formula, but rather covered an industrial process that utilized a mathematical formula. So the fact that mathematical computations were ongoing during the monitoring phase of the rubber curing process did not mean that the mathematical equations were being removed from the public domain. Others could use the mathematical equations and computations, just not as a part of the protected industrial process that resulted in properly formed and cured rubber. Now the Supreme Court’s decision in Diamond v. Diehr may be offensive to some, but it is well established and consistent with US patent laws, so for a legal discussion this needs to be the starting point.
Returning to the matter of software generally, the logic employed by the computer programmer is certainly of a mathematic nature, but that is quite different than saying that the code created by the programmer is a mathematical algorithm. Now I am speaking in generalities here, but what I am trying to address is whether all computer software should be considered unpatentable subject matter. I see absolutely no justification for all software to be considered unpatentable subject matter because it is simply not correct to say that software code is the equivalent of a mathematical equation or a mathematical algorithm. Employing the same logical structure is certainly wise, and complies with best practice standards for programming, but at the core computer software directs. The code is a series of instructions written using mathematical logic as its foundation. In the patent arena this does not and cannot mean that the patenting of software is the equivalent of patenting mathematics. It merely means that the instructions are written in a language and format that are heavily influenced by mathematics.
Before I proceed it is important to perhaps state the obvious. The fact that software ought to be considered patentable subject matter does not by any stretch of the imagination lead to the conclusion that software should be patented. It is unfortunate that the patent laws unnecessarily jumble the complex question of whether an invention ought to be patented by having the conclusion (i.e., patented) and one of the five patentability requirements (i.e., patentable subject matter) use confusingly similar labels for different concepts. The fact that an invention is patentable subject matter means only that the invention is one that could potentially receive a patent if it is useful, new, non-obvious and described specifically enough to satisfy the requirements of the US patent laws and rules. So the patentable subject matter inquiry is a threshold inquiry, not a conclusion that a patent will or ought to issue.
It is undeniable that programmers employ logic similar to the logic employed by mathematicians. Reaching the conclusion that the use of the same or similar logic means that software code is mathematical is a step to far. The influence mathematics has on programmers is largely or perhaps even solely related to work-flow. Mathematics teaches us how to manage a problem by going through the steps to solve the problem in a predictable and traceable manner. By employing the same type of thoughtful, step-by-step approach to writing code the programmer can manage write segments of code and tie everything together into an overall structure that will deliver the desired functionality. As we all know, first attempts fail with almost a 100% certainty, so where the mathematical influence can best be seen to be useful is in the debugging process. By following rules and processes learned from mathematics the debugging process becomes manageable.
I just cannot reconcile in my mind why employing lessons learned from mathematics would, could or ought to render software unpatentable. If you take this logic to its extreme you are left with absolutely nothing being patentable, which I suspect is the goal of some, but certainly not all, of those who would rather software not be patentable subject matter. Again, it is undeniable that mathematics is the backbone to virtually everything. Virtually everything can be explained using mathematical models. If you combine mathematics and physics there is virtually no mechanical, electrical or chemical phenomena that cannot be explained in a descriptive way. So does that mean that mechanical, electrical and chemical inventions ought not to be patentable?
Similarly, we know that there are known processes for investigating and researching in laboratories. The way that experiments are conducted and memorialized are through the use of the same mathematical logic that is employed by computer programmers. In order for a discovery to be believed it must be reproducible, so there needs to be a definition of controls, environment and process so that others can engage in the same process to verify the outcomes. This process is also extremely mechanical and largely influenced by mathematical logic and processes. So does that mean that anything that is the creation of a scientific process ought not to be patentable because the logic employed is the logic of mathematics?
Mathematics is the backbone of science and the backbone of invention. If we are willing to say that processes that relate to a computer are not patentable because they employ mathematical structures and logic then where does the line get drawn? In the patent context we cannot and do not concern ourselves with the foundational information and logic used by the inventor to achieve an invention. If we did then absolutely nothing would be patented because everything that can be created is a combination of elements and steps that have previously existed. Rather we focus on the output of scientific efforts. Is the output something that is sufficiently new and nonobvious to deserve a patent?
I tend to think that the real problem presented by software is not whether it is or ought to be patented, but rather the patent term associated with the awarding of a patent. For all intents and purposes a US patent can last for 20 years from the original filing date of the patent application, although we know that most patents do not last that long because they fall into the public domain far earlier due to the failure to make maintenance fee payments. Nevertheless, 20 years is a long time to provide protection for an invention that likely has a useful active life of maybe 2 years. On top of that, in the area of computer technologies you are going to wait on average wait 30.8 months to receive any substantive response from the Patent Office on your application, and will wait on average 42.4 months to have the application finally resolved. This is an unacceptably long wait, and 20 years is an unacceptably long period of time to grant protection. In my opinion we need to stop focusing on whether software ought to be patentable and decide to make it patentable once and for all. At the same time we need to figure out ways to cut the time inventors wait down to an acceptable length, and abandon the one-size-fits-all patent term. If we really want to benefit society as is the constitutional purpose we need to encourage, not discourage, the filing of patent applications and recognize rights for a reasonable but limited amount of time. It does no one any good to have computer related applications tied up in the Patent Office for 3.5 years, and it does society no good to recognize a right that lasts 20 years on technology that has at best a 5 year life cycle.
About the Author
|Eugene R. Quinn, Jr.
President & Founder of IPWatchdog, Inc.
US Patent Attorney (Reg. No. 44,294)
B.S. in Electrical Engineering, Rutgers University
Gene is a US Patent Attorney, Law Professor and the founder of IPWatchdog.com. He teaches patent bar review courses and is a member of the Board of Directors of the United Inventors Association. Gene has been quoted in the Wall Street Journal, the New York Times, the LA Times, CNN Money and various other newspapers and magazines worldwide.