May 30, 2024

Federal Circuit Reins in Business Method Patents

This has been a big year for patent law in the technology industry. A few weeks ago I wrote about the Supreme Court’s Quanta v. LG decision. Now the United States Court of Appeals for the Federal Circuit, which has jurisdiction over all patent appeals, has handed down a landmark ruling in the case of In Re Bilski. The case dealt with the validity of patents on business methods, and a number of public interest organizations had filed amicus briefs. I offer my take on the decision in a story for Ars Technica. In a nutshell, the Federal Circuit rejected the patent application at issue in the case and signaled a newfound skepticism of “business method” patents.

The decision is surprising because the Federal Circuit has until recently been strongly in favor of expanding patent rights. During the 1990s, it handed down its Alappat and State Street decisions, which gave a green light to patents on software and business methods, two categories of innovation that had traditionally been regarded as ineligible for patent protection. Even as the evidence mounted earlier this decade that these patents were hindering, rather than promoting, technological innovation, the Federal Circuit showed no sign of backing down.

Now, however, the Federal Circuit’s attitude seems to have changed. The biggest factor, I suspect, is that after a quarter century of ignoring patent law, the Supreme Court has handed down a series of unanimous decisions overturning Federal Circuit precedents and harshly criticizing the court’s permissive patent jurisprudence. That, combined with the avalanche of bad press, seems to have convinced the Federal Circuit that the standards for patenting needed to be tightened up.

However, as Ben Klemens writes, Bilski is the start of an argument about the patentability of abtract inventions, not its end. The Federal Circuit formally abandoned the extremely permissive standard it established in State Street, reverting to the Supreme Court’s rule that an invention must be tied to a specific machine or a transformation of matter. But it deferred until future decisions the precise details of how closely an idea has to be tied to a specific machine in order to be eligible for patentability. We know, for example, that a software algorithm (which is ultimately just a string of 1s and 0s) cannot be patented. But what if I take that string of 1s and 0s and write it onto a hard drive, which certainly is a machine. Does this idea-machine hybrid become a patentable invention? As Ben points out, we don’t know because the Federal Circuit explicitly deferred this question to future cases.

Still, there are a lot of hopeful signs here for those of us who would like to see an end to patents on software and business methods. The decision looks in some detail at the Supreme Court’s trio of software patent cases from the late 1970s and early 1980s, and seems conscious of the disconnect between those decisions and the Federal Circuit’s more recent precedents. Software and business method patents have developed a lot of institutional inertia over the last 15 years, so we’re unlikely to see a return to the rule that software and business methods are never patentable. But it’s safe to say that it’s going to start getting a lot harder to obtain patents on software and business methods.


  1. That’s odd. I definitely did not double-post that comment, yet now there are two copies of it.

  2. Copyright law is not necessary, though it is sufficient. The existence of important and large software systems developed without an expectation of copyright-derived royalties or rents is proof of that. Exhibit A: Red Hat Linux. Exhibit B: PostgreSQL. Exhibit C: Apache. Need I go on?

  3. G. Fernandes says

    In theory any software absolutely MUST undergo a transformation (compilation from source to executable form) to be used – a transformation need also be applied to store this software. This of course involves a machine (the computer you compile on). Therefore, you’ve already made an “idea-machine” argument at this stage.

    There are reasons why this argument is not acceptable for a patent – mainly because this transformation is mathematical and can be therefore be achieved on paper and in a (sufficiently capable) human mind.

    However, the question is not that of the transformation into executable or storage format. The question is about what is achieved by the software itself. In addressing this question, the software itself is a representation of an idea, coded in some computer programming language.

    At this point, it should be clear that patents are absolutely unacceptable for “protecting” software. Software is an expression of an idea in much the same way as a story in a book is an expression of an idea by the author of that book. As such, copyright law is both necessary and sufficient to “protect” software.

  4. “We know, for example, that a software algorithm (which is ultimately just a string of 1s and 0s) cannot be patented. ”

    No, the algorithm is not a string of 1s and 0s, it’s an abstraction that can typically be represented by many possible series of 1s and 0s, just as a given chunk of C code can be represented by many possible series of machine instructions depending on the architecture of the compiler’s target machine. The problem the court is going to have to address is what it means for an algorithm to be “tied” to a specific machine. This standard closes off one set of patents, but opens up another. Specific compiler optimizations, for example, are tied to a specific machine and therefore patentable. But what about network protocols implemented in combinations of hardware and software? They bring about a transformation of matter, but they also lend themselves to multiple implemenations. So is a protocol patentable, or just a specific implementation? This is a matter of great interest to me, as I have patents in this area, and patents pending.