(This article first appeared at IPWatchdog.)
Software patents have been controversial for decades. The discussion generally centers around whether software is patent-eligible subject matter. Since the Supreme Court’s decisions in Bilski v. Kappos, 130 S.Ct. 3218 (2010); Mayo Collaborative Servs. v. Prometheus Labs, 132 S.Ct. 1289 (2012); Ass’n for Molecular Pathology v. Myriad Genetics, Inc., 133 S. Ct. 2107 (2013); and Alice Corp. Pty. Ltd. v. CLS Bank Intern., 134 S. Ct. 2347 (2014), much of the argument in the debate has taken one of two sides: 1) the Supreme Court has expanded the judicial exceptions to § 101 so far that nearly everything is abstract; 2) despite the Supreme Court’s decisions, way too many bad patents are getting past § 101.
I think the reality is that software patents in some form are here to stay for the foreseeable future; it is also true that things that used to be considered patent-eligible no longer are. Assuming that’s right, we need a way to identify which claims are patent-eligible.
The Supreme Court has mainly given guidance as to what isn’t patent-eligible. In Alice, for example, the Court said that simply adding conventional computer components to an otherwise conventional method or system is not patent-eligible. Put another way, if there is no “inventive concept” in the claim, it isn’t patent-eligible. But the Court’s formulation isn’t necessarily helpful in drawing the line.
Drawing the line between patent-eligible and patent-ineligible software inventions requires looking at the Supreme Court’s words a little differently. Instead of looking at what they said isn’t patent-eligible, let’s see what they said about what software claims are patent-eligible. Flipping the formulation around, if a claim is patent-eligible, then there must be either an unconventional method or system or an unconventional computer component in the claim. In theory, this leaves a little room where it’s possible to have something be patent-ineligible despite being “unconventional,” but I don’t think that matters much in practice.
The first situation (i.e., unconventional method or system) is Diamond v. Diehr; in Diehr the claim was directed to an otherwise patent-eligible method for curing rubber, so the software didn’t matter for eligibility. So what is an unconventional computer component?
Basically, it’s a computer component, either software or hardware, that has been technically improved in an unconventional way. After all, if there were no technical improvement, it would just be a conventional computer component. In other words, if a claim is directed to a technical improvement of the performance of a computer (or a particular component(s)), then it is (or at least it should be) patent-eligible.
And the See CAFC seems to be moving towards a sort of “technical improvement” test for patent eligibility. Gene did a nice summary of recent 101 cases, so I won’t recap them here. If you read the decisions, you’ll see that a common thread that flows through them is the search for a technical improvement to a technical problem.
The Enfish, BASCOM, and McRO decisions (which found the claims patent-eligible) all found technical improvements in the claims at issue. TLI Communications and Electric Power Group (which found the claims ineligible) could not find technical improvements. The reasoning in Amdocs isn’t very clear, although the opinion does discuss the presence of a technical improvement.
Over all, the See CAFC has begun to find its way on software patents and patent eligibility. It’s focusing, correctly in my opinion, on the technical innovation (or lack thereof) in claims. That means that, yes, software can be Eligible to be patented. To be patent-eligible, an invention must fall into the categories listed in 35 U.S.C. § 101 (i.e., process, machine, manufacture, or composition of matter) and cannot be an abstract idea or a law of nature., but it has to provide a technical solution to a technical problem.
The reality is that the law needs to settle down and provide some form of predictability. Software can be just as work-intensive and innovative as any other field, so it’s hard to justify some sort of complete patenting exception for software. The problem hasn’t been software patents per se; it’s been bad software patents that overclaim and block others from innovating.
It’s still early, but I think that the See CAFC is on the right track.