Resources For Lawyers

[This page should be read like a law review article: it provides information and arguments which are intended to be useful, but it is not to be taken as legal advice.]

The fight is not yet over.

The line between what is and is not patentable is open to debate. Many decisionmakers question whether software should be patentable.

  • The Court of Appeals for the Federal Circuit (CAFC) made it clear that In re Bilski would be a case that directly addresses the question of whether software and business methods are patent-eligible. The case was heard en banc. The Bilski ruling introduced an additional test for patent applications, significantly narrowing the scope for patenting software ideas.
  • Nor is this an isolated case: the CAFC's rulings in In re Comiskey and In re Nuitjen are also much more moderate that CAFC rulings from decades past.
  • As on the sidebar, the BPAI is clear that software per se should not be patentable. [What is software per se? See below.] See also Ex Parte Nehls et al, another attempt by the BPAI to restrict when a patent can be based solely on new data.
  • The Supreme Court has renewed interest in patents: after about a decade of leaving the CAFC to rewrite patent law as it sees fit, the Court has heard a series of important cases on patents, and continues to consider new patent cases, such as McFarling v. Monsanto.
  • The Supreme Court also has renewed interest in the question of patentable subject matter, as shown in the unfortunately defunct LabCorp v Metabolite. Although cert was revoked, the dissent to the revocation of cert made it clear that too much is patentable. The above actions could be read as a reaction to the dissent.
  • Even in cases that have nothing to do with subject matter, the question creeps in, as in the case of Microsoft v ATT, where in oral arguments both Justices Breyer and Stevens made it clear that the Supreme Court has never ruled that software should be patentable.

The pleas by pro-softpatent scholars that software is patentable and will be forevermore seem to have died down, given so much evidence that software patents are open to debate. But some lawyers still balk at arguing the invalidity of software patents on subject matter grounds.

The only alternative to arguing the invalidity of software patents on subject matter grounds is to not do so. For example, the subject matter issue was not raised in LabCorp, which only led to the revocation of cert at the Supreme Court level. If the defendants had argued the subject matter issue to the CAFC, they would likely have successfully invalidated the patent.

Law review articles that advocate for software patents frequently open with a claim that the matter is resolved and no longer on the table for discussion, but the courts tell a different story: the scope of patentable subject matter is a decidedly open question, which courts from the BPAI to the Supreme Court are actively re-examining.

Prior Supreme Court rulings that stated that software should not be patentable have never been overturned.

  • The ruling in Gottschalk v Benson stated that the algorithm in question, when loaded onto a stock digital computer, is not patentable. It sympathetically quotes the President's Commission on the Patent System as stating that "Direct attempts to patent programs have been rejected on the ground of nonstatutory subject matter. Indirect attempts to obtain patents and avoid the rejection, by drafting claims as a process, or a machine or components thereof programmed in a given manner, rather than as a program itself, have confused the issue further and should not be permitted."
  • The ruling in Parker v Flook again clearly states that a machine whose sole inventive step is in the software is not patentable. The alarm system in question was rejected as unpatentable because "the only difference between the conventional methods of changing alarm limits and that described in respondent’s application rests in the second step – the mathematical algorithm or formula."
  • Further, the ruling takes pains to point out that assigning variable names to an otherwise unpatentable algorithm does not magically transform the algorithm into a patentable device: "A competent draftsman could attach some form of post-solution activity to almost any mathematical formula; the Pythagorean Theorem would not have been patentable, or partially patentable, because a patent application contained a final step indicating that the formula, when solved, could be usefully applied to existing surveying techniques."
  • The ruling in Diamond v Diehr did not state that software is patentable, but simply reiterated the two rulings above. Because it is a widely-held belief by those who have never read the ruling that it advocates software patents, we reproduce the whole of the ruling's conclusion (minus references, emphasis added):

We have before us today only the question of whether respondents' claims [are] patentable subject matter. We view respondents' claims as nothing more than a process for molding rubber products and not as an attempt to patent a mathematical formula. We recognize, of course, that when a claim recites a mathematical formula (or scientific principle or phenomenon of nature), an inquiry must be made into whether the claim is seeking patent protection for that formula in the abstract. A mathematical formula as such is not accorded the protection of our patent laws, Gottschalk v. Benson, and this principle cannot be circumvented by attempting to limit the use of the formula to a particular technological environment. Parker v. Flook. Similarly, insignificant postsolution activity will not transform an unpatentable principle into a patentable process. To hold otherwise would allow a competent draftsman to evade the recognized limitations on the type of subject matter eligible for patent protection. On the other hand, when a claim containing a mathematical formula implements or applies that formula in a structure or process which, when considered as a whole, is performing a function which the patent laws were designed to protect (e. g., transforming or reducing an article to a different state or thing), then the claim satisfies the requirements of 101. Because we do not view respondents' claims as an attempt to patent a mathematical formula, but rather to be drawn to an industrial process for the molding of rubber products, we affirm the [validity of the patent].

The axis of the Diehr ruling is the emphasized "On the other hand" phrase. The lines before reiterated the prior rulings that software loaded onto a general-purpose computer should not be patentable, and the subsequent line on the other hand states that when a device is transforming matter and curing rubber, then that should be taken as a real live machine.

However, this allowed the USPTO to begin a slippery slide to allow simpler and simpler machines to make an algorithm patentable.

When considering a ruling, it must be considered as a whole.

Taking the second half of Diehr out of context is to misrepresent the ruling.

The text above is the source of the rule that a patent application must be "considered as a whole". That is, this rule appears nowhere in 35 USC. Given that it is advice from a Supreme Court justice, not a law from Congress, one should take care to retain the context in which this rule came to be. The CAFC ruling in In re Alappat quoted the above ruling, but only the second half. That is, the CAFC took a ruling that stated ‘one the one hand A, but on the other hand B’ as decisively stating B.

When stating that a patent application must be "considered as a whole", it is worth pointing out the source of that rule, and the full context in which it originated. In that context, the Benson and Flook patents would still be rejected, as would most of the ‘stock computer on which is loaded software’ patents of today.

KSR v Teleflex tells us that even if software on a stock computer is patentable subject matter, it is likely unpatentable.

  • In a sentence, KSR v Teleflex found that if two elements are in the prior art, combining them in an obvious manner does not create a patentable device.
  • The term "prior art" is defined by usage—-35 USC 102 does not use the term. If we look to Section 900 of the USPTO's Manual of Patent Examination Procedure (MPEP), "Prior Art", we find that examiners are expected to search prior patents, technical literature, and scientific literature. That is, laws of nature are part of the prior art.
  • A mathematical algorithm, with no computer attached, is unpatentable. As stated by the BPAI and a number of Supreme Court justices, there is no ruling and no statute that states that software per se is patentable. All of the Supreme Court rulings above were absolutely clear on this matter, and the CAFC has taken care to clarify this point many times. Parker v Flook took additional care to point out that a mathematical algorithm, when given real-world variable names, is still a mathematical algorithm—see the comment above about how the Pythagorean Theorem would not be patentable if it were applied to surveying.
  • A stock computer, of the type that is ubiquitous throughout the world, is clearly in the prior art. Similarly, most specialized devices, such as a network router or telephone, are also in the prior art via patents on the device or via past engineering work.
  • The process of loading a mathematical algorithm onto a stock computer is obvious. This is not merely consensus among programmers: it was ruled in Northern Telecom v Datapoint: "The conversion of a complete thought (as expressed in English and Mathematics …) into a language a machine understands is necessarily a mere clerical function to a skilled programmer."
  • The syllogism is complete: a mathematical algorithm, like any law of nature, is to be taken as prior art, and has never been ruled to be patentable by itself. A stock computer is prior art as well. Joining the two is obvious. Therefore, KSR v Teleflex found that loading an unpatentable algorithm onto an unpatentable computer does not create a patentable device.

This story is consistent with the balance suggested in Diamond v Diehr: there needs to be something beyond merely loading an algorithm onto a stock PC to make for a patentable device. But if the device is itself innovative, then the use of software does not make an otherwise patentable device unpatentable.

KSR v Teleflex severely restricts In re Alappat.

The ruling in In re Alappat, which popularized the out-of-context "taken as a whole" rule, stated that loading software onto a stock computer creates a "new machine" which is patentable as any other machine. KSR v Teleflex add the caveat that many "new machines" can not be patented when their components already appeared in the prior art and their combination involved no new skill. Thus, if one wishes to follow the CAFC ruling that software + hardware = a new machine, one still has to ask if the new machine is patentable; if the software by itself is unpatentable, the hardware by itself is unpatentable, and there was no exceptional skill or creativity involved in combining them, then KSR v Teleflex indicates that the new machine is not patentable.

Further references

  • J Bessen and M Meurer, Patent Failure: How Judges, Bureaucrats, and Lawyers Put Innovators at Risk. Forthcoming, Princeton University Press. See especially chapter 9: "Abstract patents and software". [Preview page.]
© 2008, End Software Patents

Verbatim copying and distribution of this entire article are permitted worldwide, without royalty, in any medium, provided this notice is preserved.