Skip To Content

5 Things you Need to Know about Software Patentability in 2019

April 02 2019

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 way 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 you and I may feel are simple processes are still protectable.  For instance, Gaming Arts, LLC. just received a patent for a software-based “BINGO GAME WITH BONUS FEATURE” (See US Patent 10,242,531), and Sony Interactive Entertainment just received a patent for playing a sound effect when a computer detects a user saying a trigger word (See US Patent No. 10,242,674).   Both were issued on March 26, 2019.

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 does not provide protection against 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 “Instagram 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 an 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 includes 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 of 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 an examination.  It generally takes 18-24 months to enter substantive examination at the USPTO.  By this time, you will have 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 gets 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 do X before Y, or never does Y (if you don’t do X, you cannot do Y).  This kind 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 has 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 the 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 the 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 a 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. New Guidance Makes Obtaining Software Patents Easier

When it comes to patents on software-based systems and methods, Alice’s specter 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.

However, on January 4, 2019, the USPTO announced the issuance of revised guidance relevant to 35 U.S.C. § 101 (Subject Matter Eligibility) rejections. Entitled, 2019 Revised Patent Subject Matter Eligibility Guidance, the document adds a new pathway for patent eligibility, whereby a claim that includes a judicial exception is still subject matter eligible under 35. U.S.C. § 101, if the judicial exception, such as an abstract idea, is “integrated into a practical application” of the judicial exception.

Since the issuance of the new guidance, we have seen very favorable action on subject matter eligibility involving the “integration into a practical application” analysis as it relates to software patents.  For instance, on March 19, 2019, the USPTO marked as “Informative” the Patent Trial and Appeals Board (PTAB) finding in Ex parte Smith (2018-00064).  The matter involved “claims directed to a hybrid trading system for concurrently trading securities or derivatives through both electronic and open-outcry trading mechanisms.”

The board initially identified the claims as being directed to methods of organizing human activity, a category of inventions under 35 U.S.C. § 101 that constitutes an abstract idea, namely fundamental economic practices.  The board then reviewed the claims under the revised guidance relevant to 35 U.S.C. § 101 (Subject Matter Eligibility) rejections. Using this guidance, the board determined that the claims were “integrated into a practical application” of the abstract idea, and therefore patent-eligible subject matter.

Interestingly enough, the board’s determination that the claims were “integrated into a practical application” was based on the use of timers to delay automatically executing market orders (i.e., electronic) to allow “in-crowd” market orders (i.e., from “in the pits”).

However, we do have to be cautious with regards to this guidance, as the Court of Appeals for the Federal Circuit (CAFC) just stated in its opinion in Cleveland Clinic Foundation v. True Health Diagnostics LLC on April 1, 2019, that, “while we greatly respect the PTO’s expertise on all matters relating to patentability, including patent eligibility, we are not bound by its guidance.”