Alice v. CLS Bank

Alice Corp. v. CLS Bank International, 573 U.S. __, 134 S. Ct. 2347 (2014), was a 2014 decision of the United States Supreme Court about patentable subject matter (patent eligibility). The issue in the case was whether certain claims about a computer-implemented, electronic escrow service for facilitating financial transactions covered abstract ideas ineligible for patent protection. The patents were held to be invalid because the claims were drawn to an abstract idea, and implementing those claims on a computer was not enough to transform that idea into patentable subject matter.

Alice-Corp-v-CLS-Bank

Patenting Software In A Post-Alice Era

Early 2016, after a long winter of despair for patent owners on the patent eligibility front lines, hope was springing. Surely there would soon be another case from the Federal Circuit that would find at least some software patent claims to be patent eligible, right? After all, the Federal Circuit was starting to see patents on innovations of an entirely different class of sophistication. Automation of a lip synchronization process for three-dimensional characters certainly cannot be patent ineligible, can it? If the Federal Circuit did not start to find at least some software patent claims patent eligible the realization would need to set in that you could not patent software in the United States because software was de facto patent ineligible.

In May 2016 that hope was realized with a decision in Enfish LLC v. Microsoft Corporation, but then hope was quickly dashed just several days later as the court returned to its all too familiar Soup Nazi like refrain of “no patent for you” whenever software was the subject matter. But as the summer progressed we saw several more decisions that brought hope, a trend that has followed into the fall.

A great deal has been learned about what needs to be done in order to demonstrate that a computer-implemented innovation (i.e., software) is patent eligible subject matter over the last six months. Despite the fact that there are some judges on the Federal Circuit that believe software is not patent eligible, the good news is that view is now a clear minority view.

First, let’s start by acknowledging that the Supreme Court has never said that software is patent ineligible. Quite to the contrary, the Supreme Court has left the door open on software patents, even finding software to be patent eligible in Diamond v. Diehr, a decision that the Robert’s Court continues to insist remains good law. The Supreme Court has also unequivocally stated that business methods are patent eligible. See Bilski v. Kappos. 

Second, after the last six months we have now seen Judges Moore, Taranto, Hughes, Chen, Newman, O’Malley, Reyna, Stoll, and Plager all sign on to decisions that found software patent claims to be patent eligible. That brings the total to nine (9) judges of the Federal Circuit indisputably in favor of patent eligibility for software in at least some instances over the last six months. Judge Wallach joined Judge Chen in the majority decision in DDR Holdings v. Hotels.com, so it would seem safe to say that he too remains in favor of patent eligibility in at least some cases, bringing the number to ten (10). Not on that list is Judge Linn, a former patent attorney, who has throughout his career has been one of the most forceful defenders of a strong patent system and the author of previous decisions finding software claims patent eligible, including the original panel decision in Alice. Thus, the number of Federal Circuit judges that would find at least some software patent claims to be eligible conservatively sits at eleven (11).

The lone predictable “no votes,” which in all cases would be virtually certain to find any and software claims patent ineligibility are Judges Dyk and Mayer. The remainder of the court is somewhat difficult to predict at this time as the law is quickly evolving and better patentee cases are arriving at the court. Judge Lourie, also a former patent attorney, has generally throughout his career been willing to find appropriately drafted claims to be patent eligible, and would have been a predictable vote for patent eligibility in at least some cases prior to Mayo, Myriad and Alice. Chief Judge Prost authored an opinion finding method claims in a life sciences patent to be eligible, but will that carry over to software?

Even with the clear “no votes,” and those that have not yet voiced an opinion during this relatively new Federal Circuit trend, it is safe to say the tide has clearly turned at the Federal Circuit, and much has been learned in recent months. To be perfectly honest, at least as much has been learned from cases where the Federal Circuit has found the claims patent ineligible (i.e., TLI Communications and FairWarning IP) as from those cases where the claims were found to be patent eligible (i.e., EnfishBASCOM, McRo, and Amdocs). Those of us in the software space also even received some potentially insightful help from that aforementioned life sciences case — Rapid Litigation Management — which explained that while preemption is not the test for eligibility any more, the fact that a claim can be designed around confirms that the claim is not drawn to a judicial exception.

In a nutshell, if you are going to write a patent application in such a way that the reader will be left wondering what the innovation is, what the problem being solved is, or the technical particulars on how the innovation actually solves the problem and achieves the specified functionality, you should not expect a patent. In other words, if you write your patent applications without actually defining the problem, explaining the technological solution and how it is implementing the desired functionality described in the specification, and how what you are claiming is an improvement (or at least unconventional), you will not get a patent because the claims will be patent ineligible.

On the other hand, if you write your patent applications to describe (and claim) an invention that is adequately described so that someone of skill in the art will actually understand what is innovative (i.e., how and why), with a thick technical disclosure and explanation as to how computer functionality is being improved, or even generic components are working in unconventional ways, then you will get a patent because your claims will be patent eligible. [1]

What this means is if you want to patent software you simply cannot write your patent applications so that an English major or History major will be able to understand the application from start to finish. If you write your application so that an technologically unsophisticated reader can understand everything from start to finish then you have failed. That, of course, does not mean I am suggesting you hide or otherwise obfuscate the invention, but it does mean that your patent application needs to be written for the proper audience, which is a technologist skilled in the computer/software arts.

It is perfectly accurate to say, as I’m sure some will, that there is no technical standard in U.S. law. While that is true, if you are not writing your applications to satisfy such a technical standard you are not only going to have problems in the U.S., but you are going to have problems elsewhere, which is why Microsoft has settled on the European technical standard as the guide for how to draft software patent applications. If it is good enough for a top patenting company like Microsoft then shooting for a technical standard reminiscent of the European standard should be good enough for you, and in fact you should consider it to be a best practice.

To accomplish the goal of satisfactorily describing a computer implemented invention with enough specificity to overcome the patent eligibility threshold it is imperative for inventors and practitioners give serious thought to describing the overall architecture of the system that will perform the desired function. Merely reciting the process steps in a way that is disassociated from the overall architecture of the system will simply not be enough. Thus, the first thing you need to do is not focus on the software, but rather, focus on that hardware and how the hardware will be connected. Some will think this harkens back to the machine-or-transformation test, or perhaps longer ago when computer software was not patentable at all and these innovations were protected by describing the machine performing the functions. Think what you want, but if you want to patent software your description must be of a concrete and tangible technological innovation, and that concrete and tangible technological innovation must come through in the claims.

Conceptually it is critical to understand that while the machine-or-transformation test is not the test for patent eligibility, it is exceptionally difficult to characterize something as an abstract idea when tangible hardware is present, particularly if that hardware is described to be working in unconventional ways. Further, even if the the claim is characterized as an abstract idea the presence of tangible components can and does add “significantly more” than the abstract idea so as to render the claim patent eligible. This has lead many to observe that the easiest path to patent software is to make sure your software is adequately supported by hardware components.

It is also essential to guard against the tendency to want to describe the software from the perspective of the end user. In truth, descriptions that focus almost exclusively on what the end user perceives are responsible for many of the problems facing software patents over the last 5-10 years. While this information certainly should be in any application, it is not sufficient to describe things purely from the user’s perspective. The description that is essential is an explanation of how the software operates from the perspective of the computer, not the perspective of the user. This is a subtle but extremely important distinction. If you describe things only from the user’s perspective you are not describing what happens on a technical level. How things happen might as well be black magic. What you will need to do is explain how the software operates to achieve the desired results. In order to do this it will be absolutely necessary for you to break down the software step by step so that a computer programmer will be able to create the code necessary. What this means is that you must describe the logic that the computer programmer needs to follow.

Will all of this in mind, it would be useful to review the patent eligibility cases decided by the Federal Circuit over the last six months.

Source

Write a comment:

*

Your email address will not be published.

logo-footer