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 a uniqueness that you can identify you have 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 an important question — what is software and what are we protecting?
I was recently reading a book sent to me titled The Software IP Detective’s Handbook, written by Bob Zeidman. The book is generally about intellectual property for software, and more specifically about the field of software forensics. At the beginning of Part II of the book Zeidman writes this about software, which is particularly elucidating.
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.
Zeidman explains the basics of computer programming this way:
The process of writing computer code, called “programming,” is a difficult task that typically requires years of education or experience. Programming requires significant understanding of complex concepts in mathematics and computer science and a great deal of creativity. There is a huge number of ways, perhaps even an infinite number of was, to write computer programs to perform any given task. Some ways produce programs that run faster; other ways produce programs that run more reliably; other ways use fewer computer resources such as memory or electrical power. Just as many novels can be easily described as “Boy meets girl, boy and girl fall in law, boy and girl die,” there is a big difference in the implementation if the author is Charles Dickens or Stephen King.
That there are an infinite number of ways to translate a desired set of functionalities into software is why you want to obtain a patent on the software, rather than rely on copyright protection. With a patent you will be able to lock in exclusive rights with respect to any possible way the software is coded to accomplish what is recited in your patent claims. This makes the rights obtained via a patent very different and far broader and stronger than the rights one can obtain in software from a copyright. With a copyright you only get protection of the specific code, so to receive the same protection via copyright alone as is offered in a patent you would have to write the software in those infinite number of way and copyright all of them. For this reason patent claims should focus on the core process steps and not discuss the software code.
Zeidman also touches on another important aspect of software, namely what is the uniqueness? He explains that some software runs faster, is more reliable or consumes less memory or power. This is the central advantage the software possesses and what absolutely needs to be protected. This is what will make your software an innovation and not just a different version of something already done. Software is patentable in the same way that machines and tools have always been patented. You set out to do something better, faster, cheaper, easier or more reliable and frequently what you develop is something that is patentably unique.
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.
When I work with inventors I encourage them to 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 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 does 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.
For more information on this topic please see Software Patents.