The Supreme Court case of Bilski v Kappos was billed as a case over business methods, but at its core it was over an application for a patent on software, and the denial of that application sets a good example that may lead to the denial of other software patents.
This case was over whether to accept or reject Bernard Bilski's application for a patent on a routine that provides insurance against jumps in energy prices due to weather fluctuations. There was a lot wrong with this application, so the Supreme Court had a number of choices by which it could reject. The means of rejection they chose is what made this ruling relevant to software.
The first, most obvious option was to say that the process is a "business method," and that business methods are not patentable. The majority decided that there is no exception in patent law dictating that business methods are out of bounds. More generally, the label by which a patent would be categorized---business method, software, whatever---is basically irrelevant to whether a patent should be granted.
That left the majority to use another more general and more potent means of rejecting Bilski's patent: they ruled that it is too abstract. Claim 4 of the application presents a series of equations, and variable names are assigned to fix that series of equations in the realm of weather futures. But the Court affirms that math is never patentable, and adding variable names to fix the math to some specific context is not enough to make abstract math into a tangible and patentable process.
I won't go over the entire application [which you can download at the bottom of this Patently-O page], but to give a sample, here is step two of the pricing process:
perform a Monte Carlo simulation across all deals at all locations ... over the last 20 years of weather patterns and establish the payoffs from each deal under each historical weather pattern ....
Bilski is using the term Monte Carlo to simply mean that one would make random draws from the many combinations of locations, deals, and weather patterns, and then recalculate prices given those combinations. He suggests a random sample because mapping 100% of the possibilities "proves quickly intractable as the number of locations increases to approximately three."
How would one implement this step? Outside of hypotheticals and sadistic homework questions, the only sane method for a Monte Carlo routine is via software on a computer. Similarly throughout claim 4 and its subsidiaries. The process uses the results of the Monte Carlo simulation to determine the mean and standard deviation of a Normal distribution, then finds the integral of the thus-calculated distribution up to a given point. The claims estimate consumption via an ordinary least squares regression on a weather indicator, where the user may need to first take the logarithm of all of the consumption and weather data before regressing.
If the claims only consisted of a few linear equations that could be solved on the back of a napkin, one could argue that the Court is ruling only on an attempt to patent pure math. But the claims are about statistical number crunching so extensive that the author needs computational shortcuts to get up to n=3. The application is not in the language of do-while loops and function calls, but the story is clear nonetheless: Bilski is describing software.
The software's operation is specified in reasonable detail, and it is limited specifically to weather-related energy futures. Yet the Court would not allow Bilski's abstract algorithm to be saved because it is really describing software.
Perhaps the problem is that Bilski did not include a physical device. A Beauregard claim, named for an early patent by IBM, is a loophole attempting to get around the abstractness of pure software. The premise is that software is not patentable because it is a series of equations, but a stock PC on which is loaded software is a solid, metal machine, and therefore patentable. Thus, putting the phrase "A stock computer on which is loaded an algorithm to..." in front of the algorithm itself will transform the abstract into a patentable device. The Federal Circuit has in the past routinely approved the Beauregard loophole, using a "useful, concrete, and tangible" rule and a "machine-or-transformation" test, both of which imply that if it is physical enough to be touched, it can be patented.
The Bilski ruling reduced the machine-or-transformation test from being the determining factor to a mere advisory role, and rejected the "useful, concrete, and tangible" mantra entirely. Striking down these rules puts the Beauregard loophole very much into question.
The ruling seems to go out of its way to not mention software by name. There is one section in the text of the majority ruling that discusses it, but that section is specifically carved out as not signed by the majority. To many pundits, the ruling was a disappointment because of this lack of firm guidance or a clear test to apply. I agree that the ruling's commentary was disappointing---it reads more like a committee compromise than a firm position---but the ruling is nowhere near vacuous, because it provides guidance via the example of rejecting Bilski.
The Justices were unanimous that an algorithm, either for a series of equations or a set of appropriately named variables, is by itself an abstraction and therefore unpatentable. Bilski's patent is not just any mathematical algorithm: it is a statistical algorithm which can not reasonably be executed unless coded into software and loaded onto a computer. Even this did not save Bilski's patent from being too abstract.
Bilski does not explicitly recite a stock computer on which his algorithm is loaded, but there is no evidence that the Court would have changed its mind if only Bilski had chosen the right software-on-hardware wording. The majority makes over a dozen mentions of the 1978 Supreme Court ruling in Parker v Flook that warns that an algorithm plus "insignificant postsolution activity" is still just an abstract algorithm. Further, two important rules holding open the Beauregard loophole---the "useful, concrete, and tangible" rule and the "machine-or-transformation" rule---were struck down and diminished, respectively.
Make no mistake about it: Bilski's application was for a software patent, and the Court decisively denied the application. It remains to be seen how the ruling affects litigation and Patent Office decisions, but it sets a solid example that abstract works including software are outside the scope of patentability.
1 Comment