Is software patentable?

Yes, software can be patented. However, the road to a granted patent may be long, frustrating and expensive. Let’s dive into the factors that can make software patentable.

Need to file a software patent? Email Vic at vlin@icaplaw.com or call (949) 223-9623 to request a flat fee cost estimate for filing your software patent application. 

What makes software patentable?

Just like any other type of invention, software must be novel and non-obvious. The extra hurdle that software and business method applications must overcome is the requirement of patent eligibility. A software invention must have eligible subject matter in order to be patentable.

What is patent eligible?

Patent eligible is not the same as new. That being said, a more unique invention can increase the eligibility of the subject matter sought for patent protection.

We start with a foundational question: Is the claim directed to a process, machine, manufacture of composition of matter? If not, then the subject matter is not patent eligible.

Since the answer to the foundational question is yes for nearly all software inventions (and practically all inventions in general), we move to a two-step line of questioning established in the US Supreme Court case of Alice Corp. v. CLS Bank Int’l:

  1. Is the claim directed to a law of nature, a natural phenomenon, or an abstract idea?
  2. If so: Does the claim recite additional elements that amount to significantly more than an abstract idea?

Since software inventions are not directed to laws of nature or natural phenomena, the key issue in the first step of this Section 101 analysis is whether the software constitutes an abstract idea. If your claim is not directed to an abstract idea, your software is patent eligible and the second step can be bypassed. If the claim is directed to an abstract idea, then you must show additional elements that make the software more than an abstract idea.

Step 1: What kinds of software and computer inventions are not abstract ideas?

Enfish, LLC v. Microsoft Corporation is a post-Alice case from the Court of Appeals for the Federal Circuit that provides guidance on how a computer invention might not be an abstract idea in the first place. One factor considered by the Court was whether the claim covered “an improvement to computer functionality itself, not on economic or other tasks for which a computer is used in its ordinary capacity.” In Enfish, the Court found that patented invention was “directed to a specific improvement to the way computers operate . . .”

The significance of Enfish is that an invention is not inherently abstract simply because it consists of software.

Step 2: What is significantly more than an abstract idea?

If an examiner deems your software claim to be directed to an abstract idea, then you’ll want to show how the claim recites additional elements that amount to significantly more than an abstract idea. But, what is significantly more?

BASCOM Global Internet Services, Inc. v. ATT Mobility, LLC sheds light on this second step stating that an “inventive concept can be found in the non-conventional and non-generic arrangement of known, conventional pieces.” The invention in the BASCOM patent related to an individually customizable system for filtering Internet content at a particular network location. “Significantly more” in that case meant a unique arrangement of otherwise known components.

Well-understood, routine and conventional?

Berkheimer v. HP Inc., 881 F.3d 1360 (Fed. Cir. 2018) was a positive case for software patents by stating that the inquiry of whether something is well-understood, routine and conventional is a question of fact. Following up on this ruling, the USPTO issued an examination memo requiring patent examiners to cite evidence to support the finding that something claimed was well-understood, routine and conventional (at least one of the following):

  1. Express admission by applicant in specification or during prosecution;
  2. Citation to court decisions discussed in MPEP 2106.05(d)(II);
  3. Citation to publication demonstrating the well-understood, routine and conventional nature of the clam elements at issue;
  4. Statement that the examiner is taking official notice pursuant to MPEP 2144.03. If the applicant challenges the position of official notice taken by the examiner, the examiner must then provide one of items 1-3 above, or an affidavit or declaration under 37 CFR 1.104(d)(2) setting forth specific factual statements and explanation to support the examiner’s position.

USPTO examples of eligible software inventions

The USPTO has published examples of subject matter eligibility that includes the BASCOM case and a hypothetical invention for a “two-factor authentication for ATM transactions.”

In the ATM hypothetical, the USPTO provided three representative claims to help illustrate the additional elements that would amount to significant more than an abstract idea (note that the USPTO regards each claim as directed to an abstract idea):

Claim 1

A method of conducting a secure automated teller transaction with a financial institution by authenticating a customer’s identity, comprising the steps of:

obtaining customer‐specific information from a bank card,

comparing, by a processor, the obtained customer‐specific information with customer information from the financial institution to verify the customer’s identity, and

determining whether the transaction should proceed when a match from the comparison verifies the authenticity of the customer’s identity.

Result: Claim 1 is ineligible.

Since the claim is directed to a method of ATM fraud prevention by authenticating a customer’s identity, it covers an abstract idea. Next, the USPTO looked at the additional limitations, or elements, in Claim 1 individually and in combination. Individually, each additional element represented a conventional action such as obtaining customer-specific information and comparing by using a generic processor. Taken individually, the additional elements of claim 1 failed to provide significantly more.

In combination, the additional elements failed to amount to something more because the combination is “no more than the sum of their parts, and provides nothing more than mere automation of verification steps that were in years past performed mentally by tellers when engaging with a bank customer.”

Claim 2

A method of conducting a secure automated teller transaction with a financial institution by authenticating a customer’s identity, comprising the steps of:

obtaining customer‐specific information from a bank card,

comparing, by a processor, the obtained customer‐specific information with customer information from the financial institution to verify the customer’s identity, by

   generating a random code and transmitting it to a mobile communication device that is registered to the customer associated with the bank card,

   reading, by the automated teller machine, an image from the customer’s mobile communication device that is generated in response to receipt of the random code, wherein the image includes encrypted code data,

   decrypting the code data from the read image, and

   analyzing the decrypted code data from the read image and the generated code to determine if the decrypted code data from the read image matches the generated code data, and

determining whether the transaction should proceed when a match from the analysis verifies the authenticity of the customer’s identity.

Result: Claim 2 is eligible.

Similar to claim 1, claim 2 is also directed to an abstract idea. Taken individually, the USPTO does not regard the additional elements of claim 2 as adding significantly more.

As a whole, however, the combination of the elements “operates in a non-conventional way and non-generic way to ensure the customer’s identify is verified in a secure manner that is more than the conventional verification process employed by an ATM alone.” The USPTO believes that the combination of steps recited in claim 2 “presents a specific, discrete implementation of an abstract idea” and that the additional elements in claim 2 “are a practical implementation of the abstract idea of fraud prevention that performs identity verification in a non-conventional and non-generic way, even though the steps use well-known components . . .”

Claim 3

A method of conducting a secure automated teller transaction with a financial institution by authenticating a customer’s identity, comprising the steps of:

obtaining customer‐specific information from a bank card,

comparing, by a processor, the obtained customer‐specific information with customer information from the financial institution to verify the customer’s identity, by

   generating a random code and visibly displaying it on a customer interface of the automated teller machine,

   obtaining, by the automated teller machine, a customer confirmation code from the customer’s mobile communication device that is generated in response to the random code, and

   determining whether the customer confirmation code matches the random code, and

automatically sending a control signal to an input for the automated teller machine to provide access to a keypad when a match from the analysis verifies the authenticity of the customer’s identity, and to deny access to a keypad so that the transaction is terminated when the comparison results in no match.

Result: Claim 3 is eligible. Claim 3 is similar to claim 2 in that it is directed to an abstract idea where each additional element, taken individually, does not amount to significantly.

The combination of steps, however, operates in a non-conventional and non-generic way. The USPTO also noted that claim 3 “describes a process that differs from the routine and conventional sequence of events normally conducted by ATM verification.”

How to file a software patent application

Keep in mind that the above USPTO examples relate only to eligibility. The patentability of such claims will also depend upon how new they are in view of the prior art. The takeaway from these eligibility examples is to draft claims that, if possible, cover an improvement to functionality such that the claim is not directed to an abstract idea in the first place.

Claim should also be drafted in anticipation that a patent examiner will regard them as directed to an abstract idea. In particular, the claims should recite steps which, when viewed in combination, operate in a non-conventional and non-generic way. Each component may be known, but the arrangement should be recited in such a unique way so as to surpass that elusive threshold of “significantly more.”

Have questions on whether your software is patentable?

Contact startup patent attorney Vic Lin at vlin@icaplaw.com or call (949) 223-9623 to see how we might be able to help you patent your software.

How useful was this post?

Click on a star to rate it!

Thank you for rating my post!

We want to do better.

Could you tell us what was missing in our post?

Innovation Capital Law Group
Ready to Slay Goliath?

What IP do you need?*

What IP do you need?*

(Check all that apply)

Your Name*

Your Name*

Your Email*

Your Email*

Your Phone Number

Your Phone Number

Design Patent Money-Back Guarantee
Get your design patent allowed or attorney's fees refunded. Call or email Vic to see if your design qualifies.

Not sure where to start? Email Vic at vlin@icaplaw.com.

Copyright © Vic Lin 2023