The Information Needed to Avoid Writing Bad Software Patents

Software is now and will remain patentable in the United States. Software patents have been vilified by many, but they have been granted by the United States Patent and Trademark Office and upheld in federal courts across the United States. The much anticipated Bilski v. Kappos decision at the Supreme Court did nothing to slow down the patentability of software, and in fact even the original Federal Circuit decision wound up, as applied by the USPTO, to make it more likely that adequately written software patent applications would be granted and transformed into issued patents. What has changed over the last several years, however, is the amount of detail that must go into a software patent application in order to satisfy the adequate description requirements under US patent law. So don’t listen to anyone who tells you software cannot be patents in the United States; it certainly can, but it isn’t quite as easy as it used to be.

Those who despise software patents do have a legitimate point in some regards. They over play their hand badly 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? Those who only endeavor to appreciate (and I use that term loosely) the issues get tied up in pointing out that when a software patent issues the technology has been generally used for many years usually. That is true, but the question is was it generally used or known prior to the filing of the patent application? In most instances the answer is no, it wasn’t. So the first lesson of software patents must be that if you have an innovation you should apply as early in the process as possible. That is good advice for almost all inventions (in my opinion) but critical for software.

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 basics, but it is exceptionally challenging to explain initially. This is one of the things that I have the most difficulty getting across to the clients I represent in the software industry, and the primary reason I am writing this article.

I follow the same process whenever handling software related inventions. We start with a patent search and spend a good deal of time working to understand the core uniqueness, and there is almost always some uniqueness with any software innovation. This iterative and collaborative process I engage in with the client allows me to understand in a detailed way the prior art, and it also allows me to learn far more about the invention from the earliest stages of the process. We collaborate to figure out what the big picture innovation is and what a variety of little picture, or specific implementations, inventions that fall within the big picture.

Transitioning from this I invariably ask the 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 the 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.

The first thing to realize is 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.

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. 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 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 and that is quite unfortunate indeed.

When writing up a software patent application what we really want is a global flow chart of the implementation that describes the action items that the algorithms will implement. While algorithms are not patentable themselves, what we do is think in terms of process steps. It is critical to realize that a series of algorithms is not an unpatentable algorithm, but starts to define a process. Processes have always been patentable in the United States and always will. Don’t listen to those who tell you software is math and cannot or should not be patentable. That is to miss the forest for the trees, or perhaps to miss the forest for the ants. No doubt that software employs logic that is similar to mathematics, but the innovation that can be protected is the process.

If you have innovative software what you 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. You see, software directs the successful completion of a task through the use of a host of hardware and communications equipment. 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.