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.
Join the Discussion
7 comments so far.
step backJanuary 27, 2014 02:40 pm
One problem in the software arts –and I have run into it a number of times– is that each block in the flowchart says “Do X here” and “Do Y next here”.
Often X and Y are routine functions like “sort” and display “results”.
But every once in a while there is a “Do Z here” box where Z translates into “and this is where the miracle happens”.
However, the words in the Z box are ordinary English words that to the untrained eye seem extraordinarily plausible because it is oft something that the mind of a 5 year old child can easily do –and yet it is undoable with present day computer technology. Example: Let Z= “And here the computer determines whether the stared-at painting is beautiful or not.”
MaxDreiJanuary 26, 2014 05:37 pm
Constructive reduction to practice? Yes, anon, we do understand such matters in Europe, ever since the 19th century, if not earlier.
Paul was it not judge Robin Jacob who was the most recent to point out to us the choice facing those who would file early. They are under no obligation first to have already run their invention but, if in their specification as filed they teach how to realise it and they turn out to be insufficient or wrong, then their patent is likely to be invalid. The corollary is of course that, if they guess, and guess right, they get away with it. Quite right too. The patent system is supposed to foster enabling disclosures of clever new stuff, at the earliest possible date.
Since you ask, anon, I will walk you through how it is in Europe. You request a patent for an invention. That invention you define with in a claim which has to be clear. That self-same invention you describe in your specification, whose task it is to enable the invention, over an area corresponding to the scope of the claim. So, no need for 112(6) and no need to complicate things by the notion of a mode that’s the “best”. It is your risk if you keep the best mode a secret, for then somebody else filing later might secure for it a valid issued claim.
As I have already written, Europe recognises the phenomenon of the “Problem Invention”, one which is made when the problem is first perceived, such that the subsequent implementation of the Invention is banal. Specifications for such inventions can be very short. Trouble is, so can their lifetime, when it becomes apparent from the state of the art that it was not after all an Invention to perceive the problem.
It is a core activity of a patent attorney in Europe to draft the claim and the specification and identify the optimal Goldilocks (not too soon and not too late) date for filing it. As I wrote above, jump too soon and you might well end up with nothing.
Are these writings “food for thought”? Between seasoned patent professionals? Hardly.
Paul ColeJanuary 26, 2014 04:38 pm
Of course an applicant does not have to have created working software. But by the time the attorney is visited there should be some fairly detailed plans which can be used as the basis of a convincing specification. As max has said, in developing these plans there are likely to have been some problems encountered along the way which if solved would make a specification worth reading. The detailed plans, though,should be something more than a few naive flowcharts which a computer-literate teenager could construct.
AnonJanuary 26, 2014 12:41 pm
As both Paul Cole and MaxDrei are not native to the US laws on patents, I feel obliged to draw attention to the word ‘possession’ as being used here and note that the legal meaning of that term is in danger of being misconstrued and misunderstood in the present discussion.
Paul and MaxDrei, in your home territories, does your national and sovereign law recognize the concept of constructive reduction to practice? How does the understanding of what it takes to be an invention work for your patent laws? Are you familiar with the fact that in the US an actual working model has not been required to accompany a patent application for hundreds of years**?
** The exception that proves the rule, of course, is that a model for a perpetual motion machine must be submitted. The common sense approach – at least in the States – is that if the invention is at all plausible, no working model is required. Does you sovereign law differ?
And let’s take a closer look at a different art field that may not measure up to a ‘working model’ requirement if one were to be re-enacted: Pharma.
What? You may ask? Pharma is an art field where surely indefiniteness is not a problem and the ‘need’ for a working model submitted would not be needed – or so one might be tempted to think.
However, let’s look at utility – every bit a requirement for patent applications as the requirement for being definite. Hmmm, exactly how many pharma patents are filed only after utility has been actually vouched – as in, only after the appropriate FDA hurdles have been jumped? (you might check into the large number of drugs that actually fail to pass this hurdle).
The answer? That’s right: absolutely none.
Zero. Zilch. Nada.
Now you might wonder why no one questions the fact that applications are ALWAYS filed in this art field before utility is actually possessed. You might also recognize that a strict application of the working model submission requirement would mean the end of Pharma patents as we know them today.
Food (or medicine) for thought…
AnonJanuary 26, 2014 09:05 am
Post caught in filter – please release and delete this post.
MaxDreiJanuary 26, 2014 08:11 am
I wonder how many inventors are not yet in possession of “a real working embodiment” when they file. At least some of them, surely.
I wonder whether there will be more or less such cases, now that the system is “First to File”. Many would immediately cry “more”, but I have written many times that, under FtF, filing too early is worse for your ultimate legal position than not filing at all.
For those not yet in possession, fleshing out the specification with gratuitous detail will likely serve only to advertise, to those who by now are engaged in working the Invention, the areas where sufficiency of description can successfully be put in dispute.
In contrast, those Inventors already in possession before they file will already have found out that the devil does indeed lie in the detail. In getting all the way to an embodiment which is real and which works, they will have had to address and solve all manner of implementation problems. This experience will provide the meat of the specification and render it more than just plausible.
Paul ColeJanuary 26, 2014 06:36 am
One of the major dangers in all software patenting is high level disclosure not supported by detailed description of a real working embodiment.
It seems to me that the spirit of 35 USC 112(f) should always be borne in mind, even if strict means + function language is avoided in the claims. For example, if a flowchart has a box labelled “double-entry accounting module”, then either specific commercially available software should be identified or appropriate flowcharts should be included showing how the particular module is intended to operate. If we go back to State Street Bank it seems to me that the real objection was that the software was non-enabling because the boxes in the diagrams and flowcharts were never populated. The skilled reader might obtain a general idea, but in terms of practical implementation would be left with a long and difficult development exercise before anything workable was produced.