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, as well as a healthy familiarity with Murphy’s Law. 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 process patentable.
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 unique. At the very least these devices and gadgets rely on at least some computerized implementation in order to provide full functionality.
When you set out to define a patentable computer implemented process it is essential, in my opinion, to 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 systems/architecture view; and (3) from the viewpoint of the computer.
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. 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.
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 certain business functionality. 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, however, is likely what will no longer be patentable after the Supreme Court decision in Bilski, or soon thereafter will not be patentable once the Federal Circuit gets to weigh in with a more restrained scaling back of software and business method patents post-Bilski.
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. Additionally, as of right now under the current Bilski standard set by the Federal Circuit this is the only way to attack software patent applications. 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.
The final focus should be from the viewpoint of the computer, and this is where things get interesting and we encounter Murphy’s Law on steroids! 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. 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 in appropriate 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.
This type of 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 and the programmer being the reducer to practice that follows your requirements.
There is a fine line, however, between creating a set of desired functionality 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. Alternatively, you may be working with someone who over-promises and will under deliver, but that is a different story for a different day. Assuming there is simply rote implementation, then there is probably not conception and likely not an invention. This being the case, as you are going 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.
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.
As you embark upon defining the invention you also want to spend time articulating the problem with previous solutions and why your software, system or process is better, and perhaps more idiot proof. You may not want to include that in your patent application any more, or in a very watered down fashion. The law of obviousness being what it is today if you describe the problems with the prior art very well you might be creating your own obviousness rejection. Eventually KSR will become watered down and either statutorily repealed or gutted by the Federal Circuit, or nothing will be patentable because literally everything is obvious under KSR. That is not how it is being applied, thankfully, but still why take any chances. Nevertheless, working through and being able to explain the problems with the prior art and how your invention is better will pay dividends because this will allow the primary focusing on those core aspects of your invention that are most likely patentable.