The United States Supreme Court is poised this term to decide CLS Bank v. Alice Corporation, which could make meaningful strides toward settling once and for all the patent eligibility of software. The Supreme Court is known to like to dodge the most important questions we all need answered, and that trend is almost certainly going to continue in any decision in CLS Bank. But the Supreme Court won’t be able to dodge the fundamental question about whether software is patent eligible. The will likely, and unfortunately, dodge the question about what specifically must be recited in patent claims in order to properly define a software, or computer implemented invention.
Software is now and will remain patentable in the United States even after the Supreme Court’s decision in CLS Bank. The Patent Act is replete with references to software and computer implemented inventions. In fact, in 2011 Congress essentially said that tax strategies could not be patented in and of themselves, but this exclusion relating to tax strategies does not render an otherwise patent eligible software program patent ineligible. Thus, Congress has spoken, and on this particular issue Congress will be the final word because there is no chance the Supreme Court will rule software patents unconstitutional. That issue is not even before the Court.
Congress clearly has stated that at least some software is patent eligible, and so will the Supreme Court. That being said, the real question is how do you describe a software related invention to satisfy the patent requirements? The short answer is that it takes quite a bit more disclosure than you might otherwise think. Long gone are the days of cheap, easy software patents.
Those who despise software patents do have a legitimate point in some regards, although they severely over play their hand when they want all software patents abolished, but those who take a more strategic and pinpoint approach do correctly observe that there are a lot of bad software patents out there. But what makes a bad software patent? This is where those who loath software patents typically run off the rails. They point out that when a software patent issues the technology has been generally used for many years. That is true, but the question is was it generally used or known prior to the filing of the patent application? The honest answer in many, if not most, instances is no, it wasn’t.
The real trouble with the so-called bad software patents is that they typically have non-enabling disclosures. This is not an enormously difficult concept once you know some patent basics, but it is exceptionally challenging to explain initially because in some ways what you need to do may seem counterintuitive.
The key to any software patent application is to describe the invention with enough technical detail, system specifics and process information so that a computer programmer could take the disclosure and code the software without having to make any independent, creative decisions. Essentially, you want your patent application to be a design document. This is critical because it is the design of the software — the architecture of the system, how the algorithms are strung together, the rules, calculations and manipulations — that are patentable. Software code is not patentable. You can and should get a copyright on the software code as written, but the invention does not reside in the code. The computer programmer is merely a translator that takes your invention and writes it into code that the computer can execute.
The difficulty with any software patent project is figuring out where the patentable uniqueness likely resides. In my experience, when a client describes their software to me I can almost always find something that is quite similar, if not nearly identical. Many years ago it got to the point where I would send out a search result that found exactly what was described to me. The client would be ecstatic after reviewing the search because we didn’t find their invention, but we did find what we were told was the invention.
The truth is that there are so many nuances to any computer implemented invention that there can almost always be something unique somewhere, you just have to find it. This lead us to start doing software patent searches in two phases. In the first phase we look for things that seem big picture related. Then we work in a collaborative process with the client to understand what is similar and what is different. With this critical information obtained in context of items in the prior art that are generally (or sometimes specifically) related we drill down on what is at the core of the invention. This allows for a far more detailed search in phase 2, and ultimately gives us great insight into the invention. Since I overwhelmingly work with clients who are at an early stage of development it also helps them see what is already in the prior art, which allows them to distinguish and refine what they were already working on relative to the overall project.
If the patent search suggests that there is a likelihood of obtaining a patent we next transition into the nitty gritty of the patent project. I will invariably ask clients to provide me both a macro description of the software and a series of micro descriptions focusing on the various calculations, measurements and systematic handling of data that is the hallmark of every software innovation. At this point I usually receive the first substantial push back. By now clients are knowledgeable enough to understand that the protection of the micro details is not exactly what they are after for a variety of reasons. First, a narrow patent is not what they want. Second, there are frequently (or typically) a multitude of ways that the micro process can be accomplished.
It is important to realize that a patent application has many parts and many purposes. The claims in an issued patent will define the exclusive rights granted, and any patent should have some broad claims and a series of narrow claims, which weave together to create a variety of claim scope. You do this for multiple reasons, but perhaps chief among them is to make sure you have the broadest protection possible while realizing that if the patent becomes valuable enough to litigate you might lose some of the broader claims due to newly discovered prior art. If you only have those broad claims then you might wind up with nothing at all later, which defeats the entire purpose.
The specification, which is typically referred to as anything that is not a claim and now a drawing, will describe the invention thoroughly and completely. In fact, most specifications will describe the grandiosity of the invention and include much description that does not specifically pertain to the claims and which may relate to aspects that you don’t think could be captured with exclusive rights. This is because the specification needs to describe the invention so that others of skill in the relevant technology would be able to both make and use the invention without undue experimentation after having only read the disclosure. This is another reason why you want your patent application to be akin to a wholly self contained design document.
But how much information is really necessary? What is undue experimentation is an article, or treatise, in its own right. For now suffice it to say that with a modest amount of tinkering, trial and error by someone reasonably sophisticated in the technology field should be able to bring your invention into being after having only read your patent application. This is what most “bad software patents” fail at. They vaguely describe a process and the reader is largely left up to fill in the blanks and figure it out themselves. Those types of patents wouldn’t issue today, but once upon a time they did issue. It is many of these patents that are legitimately criticized as being representative of bad software patents. Nevertheless, it is important to realize that things have changed and for quite some time it has been impossible to obtain patent protection when the technical disclosure in a software patent application is thin.
When writing up a software patent application what we really need is a global flow chart of the implementation that describes the action items that the algorithms will implement. While algorithms are not patentable themselves, we will need to think in terms of process steps. It is critical to realize that a series of algorithms working together to achieve a particular functionality is not an unpatentable algorithm, but starts to define a patent eligible process.
If you have innovative software what you must have is this: a task that needs completing and the mechanism to accomplish that task. The task might take a very long time, perhaps forever, without automation. Through the use of tools, conditions and processes (i.e., the mechanisms) you accomplish the task. Software directs the successful completion of a task through the use of a host of hardware and communications equipment that are connected and coordinated to accomplish the intended purpose. When this task driven process is unique a patent can be obtained. It is helpful, although not necessary, to have a unique system architecture as well, which can be protected in its own right separate and apart from the process.
When describing a software related innovation we would like very much to be able to describe the process that the computer will go through in making the comparisons, what metrics will be and could be measured/considered, etc. Perhaps it might be best to consider the algorithms that embody the overall process as a single step within the overall process. In and of itself not patentable, but together with other steps, calculations and comparisons it can and will create a patentable process overall.
It is also critical for a patent attorney to understand the micro aspects of the overall software processes because invariably suggestions can be made and underlying threads and themes will emerge. By understanding the ultra specific it is easy to describe various aspects in illustrative, non-limiting ways and start to be able to formulate a sophisticated understanding of how to describe the specifics in ever more general terms. In essence, by understanding the specifics it makes it much easier to figure out how to accurately and honestly describe what is going on in general, yet intellectually honest ways.
The purpose of the requirement that the specification describe the invention in such terms that one skilled in the art can make and use the claimed invention is to ensure that the invention is communicated to the interested public in a meaningful way. The information contained in the disclosure of an application must be sufficient to inform those skilled in the relevant technology.
In order for any patent application to be complete the invention must be described with great particularity. This may seem obvious, but remember that the patent application needs to explain your invention to someone who is not already familiar with the invention. The best way to do this is to explain it like we used to do when we were kids doing a show and tell at school. You explained everything, no matter how obvious, no matter how insignificant or trivial. Kids do this when they describe things because they have no idea what the person listening knows, and to them it is new and interesting so they explain everything with tremendous detail (whether you want to hear it or not). That is exactly what needs to be done in a patent application. Explain the invention with so much detail that you will bore the knowledgeable reader to death. Focus on the big picture, the little picture and everything in between. That is why it is essential to to obtain both the high level flow charts and a detailed understanding of exactly how the client intends to carry out the implementation of the software innovation.