Despite the protestations of some, software is patentable in in the United States. There are some jurisdictions that do not allow for the patenting of software or computer implemented processes, but the law in the United States allows for software to be patented.
Given the software patents are my business, one of the questions I typically receive from an inventor is: What software can be patented? How does one know that what they have is something that can be protected? The short answer is this: In my experience those who come to me before they start coding always have something that can be patented. Of course we have to do a search and seek out the available space, but there are some many twists and turns that there is almost always something patentable. Unfortunately, some do the programming first and never approach the design as an engineering problem for which they have a unique solution. That means no attempt has been made to identify the unique characteristics so what is programmed is many times virtually identical to the prior art. It doesn’t have to be that way though.
When dealing with software and other computerized inventions you should view the innovation as a system that provides a desired set of functionalities. If there is uniqueness that you can identify you has something that can be patented. You don’t have a bunch of code or compiled 1s and 0s, what you have is an innovation that provides desired functionality. It is the desired functionality that will create market demand for your software, and it is those same functionalities that that lead to a patentable innovation. Time needs to be spent to understand the unique value added and how to best characterize the invention.
Software is patentable in the United States provided that it is unique and tied to a machine. The “uniqueness” requirement mentioned is similar to the requirements for all inventions to be patented and is grounded into the patent laws by the novelty and non-obviousness requirements. The “tied to a machine” requirement comes to us thanks to the Supreme Court and Federal Circuit decisions in Bilski. In a nutshell, what is required to obtain a patent is a unique process that is performed using a computer or similar device. The requirement that the process be tied to some machine eliminates the possibility that a pure business method can be patented. For those who really have software that is unique obtaining a patent in the U.S. is not difficult if you know what you are doing.
Difficult is really in the eye of the beholder, and saying that it is not difficult to patent software begs the important question — what is software and what are we protecting?
Software consists of the instructions that a computer follows to perform a task, whether it is calculating the square root of 2, accepting input from a user, running a hotel elevator system, displaying a Web page, or searching the Internet…
Thus, software is what causes a computer to act. Software is what breathes life into the computer and enables it to be something other than just an ornament for your desk. Without software a computer just sits there. With software it can do whatever it has been instructed to do. Software is different conceptually in patent terms from the code that makes up the set of instructions. The code can be copyrighted; the invention (i.e., the software) can be patented.
Not sold on the idea of software patents? Well what If you created an automobile engine that could deliver 500 miles per gallon of gasoline would you seek a patent? I suspect you would because that type of engine would almost certainly be revolutionary. So why wouldn’t you think about patenting a software system that more efficiently manages power consumption for a large office building? If you could reduce energy consumption by 25% wouldn’t that be noteworthy? Of course, and it should be patentable as well. Legally it doesn’t matter whether the advantage is created by an old world mechanical gadget or thanks to the constant monitoring and manipulation of parameters via a computer following instructions. Both are innovations and both are patentable, and rightly so.
The inventor should conceptualize the project with an engineering mind set, not the mindset of a computer programmer. Unless the computer program is an inventor the programmer should not be imparting patentable uniqueness to the software, but rather they are following the instructions, desires, and goals of the project manager. It is that set of instructions, desires, and goals that are laid out for the programmer that are the innovation.
The laying out of the who, what, where, when, why and how associated with the overall structure of the system makes an inventor, and that is not the job of a programmer. In fact, computer programmers are frequently given a task and they sit down and begin working on the task. This is done in a project management setting where programmers are given discrete deliverables. In this situation sitting down and starting isn’t so bad because the task is small and manageable. When the task becomes more complex the “let’s just get started” approach is not particularly helpful. Jumping right in is a little like starting to tell a story and not knowing the morale you are trying to teach. You should never meander through a software development project, and approaching a software patent without an overarching view of the system is a recipe for disaster.
The code written by the programmer will merely translates the innovation into something that can be performed on a machine. The translation from design document to code is not unlike the translation from one language to another. The act of translation does not impart newness, but rather just changes the form. Thus, the typical code writer is not providing the mental conception that is required for innovation. What this means is that most people have inventorship exactly backwards when it comes to software and computer implemented processes. To be an inventor you do not need to know a stitch about programming. You merely need to define what the overall system needs to do. In essence you define the rules.
Which functionalities are unique and why? How do the rules implementing those core functionalities handle and manipulate information? Because human actors will interface with the system we can anticipate mistakes and errors, so what compensation is integrated to address this inevitable human element? What problems are solved by your solution and how is this more advantageous than any other known solutions? Uniqueness can and will reside in many places when dealing with software and computer process related inventions. First work to uncover that which is unique and most likely patentable, and then set about working to get it protected — patented — so you obtain a valuable business asset.
