Despite what you may have heard to the contrary, software is still patent eligible in the United States. It is not as easy to get a software patent as it once was, and it is quite unfortunate that we even use the term “software patent” to refer to an invention that can be implemented using a computer. Indeed, according to Martin Goetz, the first person ever to be granted a software patent, software is a means to an end and whether the innovation is implemented using a computer has nothing to do with whether a patent should, or should not, be issued for an invention. Goetz is, of course, correct. Eventually the law will catch up to his viewpoint, but for the time being we are left with a Patent Office and Judicial system that exalts form over substance. Still, it is extremely helpful to follow Goetz’s advice and view the innovation holistically.
When embarking on a software development project it is critical to understand that in order to both maximize the chance of obtaining a patent, as well as the likelihood of developing a working computer implemented process, you need to approach the task with an engineering mind set. If you simply sit down and start coding you are unlikely to achieve something truly unique, nor are you even likely to achieve something that is workable and scalable.
The engineering mentality is to look at the software implemented innovation as a system, taking into account everything that can go wrong because everything that can go wrong will go wrong. This is where Murphy’s Law comes into play. Anything that can go wrong will go wrong, and once you release the process to end users a human element will complicate what should otherwise be a predictable, linear, machine driven response. Embrace the uncertainty and challenges because the fact that software rarely, if ever, works like it should is what makes a working computer implemented process patentable.
To paraphrase Donald Rumsfeld, there are things that you know and there are things that you don’t know. You can adjust for the known problems but there are always going to be unknown problems that can’t be envisioned. If you just throw code together to see what happens without really sketching out the whole system and how it needs to work, you’ve just created so many more problems. Not looking at the entire project with an engineering mindset will make it virtually impossible for the system to scale, it will make it virtually impossible to maintain and filing a patent application to seek protection will become extremely expensive.
Defining a software related invention
The term “software patent” does not really have a universally accepted meaning. It is probably safe to say that in its broadest definition a software patent is any patent that covers a computer implemented process. This definition, however, is not all that satisfying because it is incredibly broad and ignores the reality that the computer implementation of processes, at least on some level, is increasingly becoming intertwined with a wide array of devices and gadgets. These devices and gadgets are tangible, and patentable, but yet rely on software to make them truly unique. After all, a computer or smartphone isn’t particularly useful without software, neither is your automobile. The law continues to put a premium on what is tangible and concrete despite the fact that it is the software that truly provides the functionality.
With this in mind, when you set out to define a patentable computer implemented process it is essential, in my opinion, to first view the innovation as a system that provides a desired set of functionalities. I always encourage the inventors I work with to envision the system from at least three distinct views: (1) from the view of the end user; (2) from a system/architecture view; and (3) from the viewpoint of the computer.
From the view of the end user
With respect to the first viewpoint, the view of the end user, this is typically quite easy, and what most inventors are good about describing. Here we spend time on graphic user interfaces and what I refer to as “click here, do that” type descriptions. Working to define these aspects is essential, but not enough in and of itself if you want to obtain a patent. It does, however, typically create the framework, at least initially. Many of the broadest software patents and computer related patents that have come under enormous scrutiny and ridicule limit themselves to vague description of the process from the viewpoint of the end user. These patents are typically characterized as business method patents, and today these types of broad patents are difficult, if not impossible to obtain.
The term “business method patent” also doesn’t have a well developed meaning, but is probably most often used to describe pure business methods (i.e., methods without any computerized reliance or tangible hardware/devices involved) or what could be called quasi-software used to provide a description certain business functionality without reference to the underlying technology implementation. I refer to it as quasi-software because as described it masquerades as software by expressing only method steps and little, if any, tangible equipment or underlying technology or system structure. Once upon a time this was how many software and business method patents were written, many by attorneys and agents who did not specialize in software or computers. This type of vague patent description will not lead to a patent eligible invention after the Supreme Court’s decisions inBilski v. Kappos and Alice v. CLS Bank.
System/architecture view
The second viewpoint focuses on the tangible items that together are necessary to provide the overall functionality. This allows us to tie the processes directed by the computer (i.e., software) to tangible items that have always been patentable. There is a significant advantage to describe the underlying technology, hardware, data structures and communications technology. This is because the more you make something look like other things that have long been patentable the better your chances are of convincing someone, like a judge down the road, that what you have is a true invention because there are pieces and parts that can be identified and touched.
Furthermore, by spending time to discuss tangible applications that utilize tangible components you may be able to nudge your patent application out of an Art Unit that deals with pure software and into an Art Unit that deals with the tangible components. This is potentially very useful because allowance rates at the Patent Office are highly dependent upon the Art Unit assigned to examine the application. See 20 Hardest and Easiest Art Units. Furthermore, even if the law changes or modifies, which is a virtual certainty, this is clearly the best way to ensure the patent application enables one of skill in the art to both understand, use and replicate the invention, all of which is required in order for you to have a viable patent application and ultimately valid patent claims.
Viewpoint of the computer
The final focus should be from the viewpoint of the computer, and this is where things get interesting and we encounter Murphy’s Law in a big way. Here the approach is to consider the process as if the computer were a person engaging in the computations, manipulations, verifications, routing and other functions necessary to take information/data in and output other information/data in a usable format. This perspective is critical, in my opinion, because this is typically where the core innovation resides. Simply describing a vague and amorphous set of process steps can and will lead to broad claims, but claims that will almost certainly overlap with at least something in the prior art, or which will simply be patent ineligible. Furthermore, once you realize an end user will be providing the contemporaneous instructions and commands to prime action, you realize that it is not at all surprising that even the best thought out process is doomed if there are not a series of fail safe, idiot proof measures embedded within the system architecture and code.
Now I am not suggesting that the invention be described in a patent application as being capable of being done by a human in any relevant time frame, but without knowing exactly how the computer processes and otherwise handles information/data the patent application will be woefully inadequate, and inappropriate attention will have been placed on the human element driving the process. I believe this is why software patents have been so maligned, because when they simply talk of “accepting data, processing data, outputting data” the process steps lack the typical concrete explanation required in a patent application, and it assumes everything will work every time without fail. If we know anything it is that software doesn’t always, or even typically, work as designed. Every time you turn on your computer one or more applications need some kind of critical update.
Naked description, without more, does little more than explain to the computer programmer what generally needs to be done and leaves them open to figuring out the implementation. While a patent application does not need to be a blueprint, it does need to direct and it should envision not only the optimal path, but should embrace checks and balances that understand the computing power of the end user will be less than the computing power of the machine running the process. Therefore, what is essential to the patent process, and likely to the successful completion of the development of software, is to have a design document that lays everything out for the programmer and takes into account the human element. You essentially want the programmer to be a translator. You want them to be able to take your design document and code it up into whatever language they choose, but you don’t want them making choices. You want to retain mental control over the invention, which translates into you being the conceiver (i.e., inventor) and the programmer being the reducer to practice (i.e., not an inventor) that follows your requirements.
There is a fine line, however, between creating a set of desired functionalities and having a patentable invention. I suspect that where the law will ultimately head is to a place where patentability focus is placed on how quickly there is reduction to practice after articulation of the process steps. For example, if you articulate your desires and a programmer say “no problem, that can be done,” you probably don’t have an invention. Assuming there is simply rote implementation, then there is probably not conception and likely not an invention. This being the case, as you go about articulating the process and creating a design document or project management series of deliverables, you want to make sure you focus on those areas where the coding and implementation will not be rote, but will require ingenuity or first-of-its-kind development. That is where the innovation resides and what must be the focus of the patent application.
Conclusion
As with any invention, software frequently takes what previously existed and makes it better. So just like with any improvement patent, if your computerized process is faster, more accurate, uses less resources, provides enhanced functionality, is more compatible and platform independent, then you may have an invention. If your enhancements make the computer implemented process enough better that people would be willing to pay a premium, then you likely have an invention worth protecting via patent.
[“source-ipwatchdog”]
