The Software Patent Podcast

This is the first in a series of podcasts on how to determine whether your software is patentable. If you are an inventor, in management at a high tech company, or a patent lawyer outside the U.S. this will help you to at least make a first pass determination of whether your software or your client’s software is worth considering for patent protection.  If you’re like most people, you will probably be surprised by much of what you read here because there are many common misconceptions about the patentability of software. In particular, I’ve found that many people underestimate how patentable their software is and, as a result, they overlook seeking patent protection that could be extremely valuable. I hope this series of podcasts helps you to avoid this and other pitfalls.

The criteria I'll give are just general guidelines. They are not hard and fast rules, but we have found these guidelines to be extremely helpful to us when evaluating our own clients’ software for patenting in the U.S. through our many years of experience specializing in U.S. software patents. Although these suggestions are based on U.S. patent law, you may find that they are also helpful to a certain extent in other countries. 

In today's article, I'll focus on one factor that weighs in favor of patenting software. That is, if the software you or your client have developed includes any kind of new automated decision making, then that weighs in favor of the patentability of the software. What do I mean by automated decision making? I'm referring to even a single decision within the software that is performed automatically by the software. It could be as little as one instruction in the code. This does not necessarily have to be a complex or sophisticated kind of decision making. It just needs to be some decision made within the software that is automated, or, in other words, a decision made by the computer where it evaluates some data and then makes a decision. If when the data has one property, the computer does one thing; and when the data is another property, the computer does another thing, that is an automated decision. That's the basis of an “if-then” statement within software code. 

One reason I point this out as a factor to consider when evaluating software for patenting is that many inventions and software comes across my desk from clients, potential clients, and foreign law firms where the description of the process performed by the software just includes a sequence of steps. Such as; Step A + Step B + Step C + Step D.

In that case, the process just performs the above sequence of steps. When you have a process like that, which always performs the same steps in the same order, it is less likely that you have an invention that is going to satisfy patent law’s non-obviousness requirement. The non-obviousness requirement requires there to be something unexpected about the invention and, in most cases, an invention will be more likely to be non-obvious when the invention carries out at least one automated decision.

Automated decision making within software also often helps to avoid or overcome what is referred to as an “abstract idea” rejection in the U.S., sometimes called a “Section 101 rejection,” a “patentable subject matter rejection,” or a “patent eligibility rejection.” Very often if the method that you are trying to patent just has a sequence of steps without any automated decision in it, the Patent Office will view that as a method that could (at least in theory) be performed by a human, or that is not inherently tied to a computer or another machine. Whereas if there is a step in the method that involves making a decision automatically by a computer and then having the computer automatically perform one of two different actions depending on the outcome of the decision, then it is more likely to be seen by the Patent Office as a method that is inherently tied to a computer and less likely to be capable of being performed manually. Again, this is not a guarantee, but it is one reason why having an automated decision making step is helpful.

If, in addition to having an automated decision making step, your software contains what is called a “loop” in computer science, your software will also be less likely to be rejected for being an abstract idea. This means that one or more steps in the method are performed repeatedly and automatically. A loop also helps to make the argument to the Patent Office that the method is inherently a computer implemented method and therefore is not an abstract idea and not the kind of process that could be performed manually by a human. It is these kinds of arguments that help us both to overcome or avoid abstract idea rejections and help to increase the likelihood that we can convince an examiner that the software is not obvious. 

In summary, when evaluating whether some software that you or your client has developed might be patentable in the U.S, ask yourself whether that software includes at least one automated decision making step, such as an “if then” statement, which is sometimes called a branch or conditional statement in computer science. In the rest of the series, each article will point to an additional factor that weighs in favor of patentability. By the time you have read all of these podcasts you will have a solid checklist that you can use when evaluating your software or your client’s software.

To determine whether or not your software is patentable, it is best to leave the final decision to a registered patent attorney who has expertise in software patents. If you review the checklist provided in these podcasts and find that your software or your client's software satisfies one or more of the guidelines in the checklist, then it may be a good idea for you to go to a patent attorney and get further advice about whether to pursue patent protection. 

You can visit our website at www.blueshiftip.com for more information.