5 Things you Need to Know about Software Patentability in 2018
If you are a developer, tech startup or otherwise considered trying to protect your amazing new idea or technology based in software, you probably have already looked into patents as a potential to secure those technologies. (I highlight idea, as we will come back to that very salient point in a minute). Probably one of the first things you run across is everyone talking about Alice!
Who is Alice? When people refer to Alice, they are referring to a Supreme Court decision in the case of Alice Corp. v. CLS Bank International, 573 U.S. __, 134 S. Ct. 2347 (2014). In 2014, this was a landmark ruling that shifted the applicability of 35 U.S.C. § 101 to certain types of inventions. One central component of this shift was related to the patent eligibility of inventions that were based in software (or those that were otherwise based on abstract ideas).
We will not dive too deep in the analysis of Alice in this article for two main reasons: 1) it has been covered ad nauseum elsewhere; and 2) the ruling is over 4 years old and while Alice is still the root to most eligibility analyses, there have been numerous rulings since that have broadened, extended and clarified exactly what is and is not patent eligible subject matter.
So let’s start with this, for all you developers and executives at software companies:
1. Software is Patentable
Let us be clear, software is patentable, when done correctly. Even things that are simple processes are still protectable. For instance, Sony Interactive Entertainment, Inc. just received a patent for “DISPLAY OF TEXT INFORMATION ON A HEAD-MOUNTED DISPLAY” on May 29, 2018 (See US Patent 9,984,905), and Zynga recently got a patent for providing in game tutorials for players via a “Show Me” button on May 8, 2018 (See (US Patent No. 9,962,612).
It is important to note that a utility patent covers the functionality of the software, through defining the software in terms of systems and methods. What patents do not cover is the actual code. Source code is covered largely by copyright, which can protect direct copying of the code, but not those who write their own code to do the same thing. And that is exactly where patents step in.
Now, there is a certain bare minimum that must be reached for a software system and/or method to be patentable. Which brings us back to why I highlighted idea back in the beginning. Ideas are not patentable in and of themselves, as they are abstract and fall squarely into the realm of what is not patent eligible.
2. An Idea is Not Enough
If you are forming the next great startup and you want to be the “Uber for X” or the “Tinder for Y”, that is not, in and of itself, going to get you cross the finish line for patent eligibility. Remember, software patents are directed to covering systems and methods. Software almost always is nothing more than a series of steps (i.e., instructions) that drive a computer to take some action (e.g., process data). Some data goes in, software directs the computer as to what to do with that data, and the output is some generally useful result. Whether it is finding the closest Uber, matching you to your next soulmate, adding two numbers together, or calculating the trajectory of a rocket for sending a payload into space, it all boils down to some data going in, being processed, and a result being output.
When putting together a patent to protect your invention, your invention must be more fully flushed out than simply stating in conclusory terms what your software will do. The abstract idea alone is not protectable, but the steps you use to get to the solution (i.e., method) may be. Develop the flowcharts for how your great idea gets from problem A, to solution B. The road in between is your patentable method. For some help on this topic, the United States Patent and Trademark Office (USPTO) has provided a useful resource in the form of a Quick Reference Sheet for Identifying Abstract Ideas.
Remember, the more flushed out your idea is, the more it becomes a methodology which may be protected.
3. What you Disclose in your Patent is Important
The content you put into your disclosure is king when it comes to your patent filing, especially for software related inventions. The basic requirement for a patent application is that the drawings and specification disclose the invention in enough detail that one of ordinary skill in the art would be able to practice the invention without undue experimentation. While that is the bare minimum, remember, if it is in your application, you can use it later during examination to overcome examiner’s arguments related to novelty, obviousness and even indefiniteness. Conversely, if you do not include detailed descriptions of the various aspects of your invention, you cannot later use them in your arguments.
One thing that should be remembered when preparing a patent application for software methods is that even though you may be filing a patent application for your unreleased software product that will be launched soon as an initial version (e.g., v1, beta), there is no need to limit the patent application disclosure to just the features that are in the software now. In fact, there is no requirement to have a working prototype in order to file a patent application on an invention. This is particularly important with software, where you may be going to market with a minimum viable product (MVP), but have a roadmap that goes through several iterations, versions and include numerous improvements and features not present in the MVP.
Since there is no requirement to have a working prototype, and the enablement requirements only require that you be able to describe the invention in enough detail that one or ordinary skill in the art would be able to practice the invention – something probably already at least partially contained in your roadmap – you should consider putting details of all your future concepts, features and improvements in your application. What this does is secure your priority date for all of the future features and improvements you have planned.
This strategy also allows you to use these features and improvements in arguments and amendments during examination. It generally takes 18-24 months to enter substantive examination at the USPTO. By this time, you will have a greater insight as to what features and improvements became a big hit, and those that did not pan out as planned. This allows you to focus the examination of the application on those key features that were later implemented, without the need to file additional patent applications on an ongoing basis.
Further, by disclosing additional features and improvements in the first application, you can later file one or more continuation applications at a later time to secure patents on the individual features and improvements at a later time. Each of these continuation applications get the benefit of the earlier filing date, even though they may be filed years later.
4. How you Write the Patent is as Important as the Technology
What you disclose in the application is only part of it. How you write the application is critical. The words you use can end up coming back to haunt you, by unnecessarily limiting the breadth and scope of your rights, or otherwise acting as self-sworn statements that you cannot back away from.
For instance, restrictive words, like, “only”, “must”, “always”, and “never” may limit the scope of an invention. If in an application, the disclosure states, “The system always does X before Y”, then you have been committed to a system that either always does X before Y, or never does Y (if you don’t do X, you cannot do Y). These kinds of limitations can poke holes in the breadth of an application, particularly when related to software, where there are frequently dozens if not hundreds of other ways to accomplish a task. Think to yourself when drafting or reviewing an application whether the statements you are making are really requirements, or just simply one way you have chosen to implement the solution.
In another example, statements about what have been done in the past or are done in an industry can act as prior art against your invention. This is known as “Applicant Admitted Prior Art” (AAPA) and can be disastrous in certain cases. Commonly found in the background section of a patent, some applicants (or their patent attorneys or agents) may end up making statements that go beyond what actually IS prior art and inadvertently giving up certain rights by making such statements.
Further, even beyond just admissions of prior art, statements in the application about what is well-understood, routine and conventional in the art can come back to haunt inventors and applicants, as this can give grounds to the examiner to provide a subject matter rejection under 35 U.S.C. § 101. Avoid these statements at all cost, as they are generally unnecessary and add little value to the actual disclosure itself.
However, the recent federal circuit opinion in Berkheimer v. HP, Inc., 881 f.3d1360 (Fed Cir. 2018) also confirmed that the concept of applicant admissions in a patent specification works in the opposite direction as well. In Berkheimer v. HP, Inc., and a later USPTO memo regarding implementation of the ruling as it relates to patent examination practice. In this case, the court found that the applicant’s statement that the novel improvements contained in the application were not convention, and represented an improvement over the art, created a factual dispute that would not permit a finding otherwise under a motion for summary judgment. Simply put, feel free to include statements throughout the specification as to how the disclosed software works or functions differently than conventional software, and how it provides improvements over the conventional or routine functionality of other software.
5. Examiners are Now Put to Task on Eligibility
When it comes to patents on software based systems and methods, Alice’s spectre still haunts us to this day. Examiners are still issuing subject matter eligibility rejections under 35 U.S.C. § 101 on otherwise valid and protectable systems and methods that are based in software. Frequently, these rejections are held up only by loose accusations and conclusory statements about an abstract idea contained in the claims.
The good news is that the examiners have now been put to task on these rejections. Per a recent memo from the Deputy Commissioner for Patent Examination Policy at the USPTO addressing all patent examiners, the examiners are now required to give specific rationale for findings that specific elements of the claims are well-understood, routine and conventional in the art. The avenues for them to do this are: i) point to the specification of the present application where the applicant makes express statements about the element being well-understood, routine and conventional (note: silence is not to be construed as having made any such statement); ii) point to previous court rulings that address specific claim elements in the present application; iii) provide reference(s) that show that the claim element is well-understood, routine and conventional in the art; or (iv) take official notice.
The memo and the CAFC note that when providing one or more specific references to show that the claim is well-understood, routine and conventional in the art, that “merely finding the additional elements in a single patent or published application would not be sufficient to demonstrate that the additional element is well-understood, routine and conventional in the art.”
Further, the memo notes that when an examiner chooses to take official notice, that the examiner be “certain, based on upon his or her personal knowledge, that additional element(s) represent well-understood, routine, or conventional activity engaged in by those in the relevant art, in that the additional elements are widely prevalent or in common use in the relevant field, comparable to the types of activity or elements that are so well-known that they do not need to be described in detail in a patent application to satisfy 35 U.S.C. § 112(a).” However, the memo then states that if challenged on this by the applicant, the examiner must provide items under (i)-(ii) above.
Conclusion
Software system and methods are still very much patentable in 2018, even in light of Alice. However, it is important to consciously and conspicuously focus on what is it you are trying to protect, and what you say in your disclosures to the USPTO. Done right, the pathway to obtaining a patent on a software system and method can be paved with a smooth and straightforward surface. Follow the rules, watch what you write, include everything, and you are on your way.