Procuring software based intellectual property rights have become a complicated task in a post-Alice world. In 2014, for the first time, the U.S. Supreme Court invalidated software patents in the matter of Alice Corporation Pty. Ltd. v. CLS Bank International (June 19, 2014) (or simply Alice). This case has resulted in a fair amount of commotion among patent lawyers, so it may be important for an inventor to at least have a basic understanding of the case. I’ll also discuss the recent guidelines issued by the USPTO based on Alice. These guidelines are currently being used to reject software patent claims.
[includeme file=”ncs.html”]
Background
Alice Corporation was formed by an Australian citizen, Ian Shepherd, after he successfully obtained a patent, issued in 1999 (filed in 1992), on performing escrow services using a general computer. Alice Corporation then spawned many child applications from the original patent application. As such Alice Corporation obtained patents on an abstract idea implemented on a computer system. However, as most of us are aware (and as recognized by the U.S. Supreme Court), escrow services have been around even before computers existed.
When Alice‘s patents were challenged, the Supreme Court had to deal with the question: Is implementing an (abstract) idea on a computer enough to claim novelty? As expected, the Court ruled against Alice. The Court determined that Alice‘s claims were patent ineligible because “the claims … amount[ed] to ‘nothing significantly more’ than an instruction to apply the abstract idea of intermediated settlement using some unspecified, generic computer.” (Alice at p. 15).
Based on Alice, the USPTO has issued guidelines using which software claims are now being rejected. However, as discussed below, a well drafted application should be able to overcome any Alice type rejection.
USPTO GUIDELINES
Earlier the USPTO would allow a software idea be patented using any computing device. However, Alice prompted the USPTO to update it’s guidelines on patent eligible subject matter. First we provide the official (confusing) guidelines, and then we provide some tips as to what do these mean, and how to overcome them.The guidelines are:
STEP I: Determine whether the claim is directed to a process, machine,
manufacture, or composition of matter. If not, reject the claim. However, if the above is true then proceed to Step II A. Usually this step is a non-issue in a well drafted application.
STEP II A. If Step I is true, is the claim directed to an abstract idea, like:
- Fundamental economic practices;
- Methods organizing human activities;
- An idea itself; or
- Mathematical ideas or formulas.
If not, then no further analysis is needed. If however, step II A is true, then proceed to Step IIB. Caution: Examiners will always attempt to allege an invention is abstract to justify the rejection. To avoid such a rejection, the application should conclusively provide a disclosure that suggests that the invention is “directed to a specific implementation of a solution to a problem in the software arts.” (Enfish LLC V. Microsoft Corporation, slip. op. at 18.)
STEP II B. If, however, the claim is directed towards an abstract idea, does the claim provide details that “limits the claims in a significant manner?” For such a showing, the USPTO will be looking for a:
- claim limitation that limits the implementation of an abstract idea with a particular technology;
- claim limitation that improves another technology or technical field ; or
- claim limitation that improves the function of the computer itself.
If so, the matter cannot be held abstract.
But what do these guidelines mean?
To summarize, this means that software patent applications need to be more detailed than before. Here are some tips to keep in mind (Please note, the tips below are based on our experience and success in procuring business method patents for our clients even in USPTO departments that have over 95% rejection rates) :
Tip 1: All that technicality matters. Software patent applications should at least disclose a particular way of doing something on a computer. You cannot claim every way of doing something on the computer –the specification needs to be technical and detailed, explaining at least one implementation of the invention.
Tip 2: Greed may result in trouble. In view of Alice, the practice and mindset of attempting to monopolize an abstract idea needs to change. Inventors need to be realistic in what they want to be claimed. Inventors should be mindful of the USPTO guidelines and brainstorm their invention with their attorneys considering what the USPTO is looking for in software claims. Failure to do so would only result in huge legal bills and/or a failure to secure your patent rights.
Tip 3: It’s all in the details. Because software inventions often involve breakthrough ways of using a computer to perform a long wanted task on a computer more efficiently, it is important that at least some claims provide details on how the novelty was implemented. Based on Alice, it is clear the Supreme Court takes a negative view of computer related claims written with a high level of generality. Narrowing the scope of the claims while drafting software patent applications would most likely overcome the issue.
Tip 4: I, Robot! Inventors involving robotics must be aware that at least some mechanical aspect of their invention is also described within the specification and claims of their software patent applications. Thus, robotics based products with software-related inventions should have a combination of software and hardware elements in the claims.
Tip 5: Man v. Machine. Machine wins! Inventors should emphasize on ways in which a computer is an integral unit to the claimed invention, emphasizing why a computer was needed to perform the task. If something can easily be performed by a human without the use of a machine, claiming patent eligibility based on implementation of the task on a machine may not be enough to pass muster.
About the author: Rohit is a software patent attorney and has assisted numerous clients in securing their software rights.
[includeme file=”GoogleReviews.html”]