Help for the Supreme Court in CLS Bank
|Written by John White
Patent Attorney - Berenato & White
PLI Patent Bar Review Lecturer
Posted: December 15, 2013 @ 9:05 am
Greetings patent world. A very, very, important case relating to software has again made its way to the Supreme Court for decision. The United States Court of Appeals for the Federal Circuit (CAFC) badly muffed their chance to clearly set forth what thresholds should be implemented for software patentability and the Supreme Court now must step into the breach. Good thing too; but, not without lots of anxious handwringing on the part of true believers in the patent system who favor its worthwhile and broad applicability. Hence; this series of open letters/articles written for consumption by the Justices and their clerks as a primer for this case.
I know— it is presumptuous on my part that this would have any influence, but these pages are an important forum to air out these issues. If we can do this in a non-hysterical erudite fashion, these pages will be read and help inform on this issue. No doubt, every person with a dog/pup/minnow/free electron in this fight will file amici. Too bad they cannot all receive the same level of attention as the effort they take to write, but such are the practicable limits of time and comprehension of those who will make and write the decisions. My hope here is to write about this topic in a way that is both engaging and elucidating.
In the beginning… seriously we need to go back that far to bring perspective to the issues. Business methods were always thought to be outside what was patent eligible in the U.S. The historic practice of crony capitalism based on “patents” granted by the Crown made these business practice monopolies not something that would be useful or even acceptable to the then new U.S. The Constitution simply confined the patent system to the ”useful arts”. On occasion, various Supreme Court decisions have referenced the antipathy to monopolies that undergirds their thinking as to patents and what ought to be in or out on the patent eligibility front. This sidelining of business methods was fairly easily implemented right up until the digital revolution.
It started slowly at first. Control systems, mostly hardwired, began to eliminate decision making human operators in various machine settings. Once upon a time, telephone operator was a job, not just a Lilly Tomlin caricature! Mechanical marvel player pianos with paper role notes and furiously pumped foot pedals became sleek playerless department store grands that tirelessly played error free musak. Things became “automated”. The tag phrase “..omatic” was added to almost everything from the 1950’s forward. The digital folks were arriving on the scene as a component of what was otherwise clearly a machine or thing. The world of Homer Simpson began to take shape, we thought much less than before and pushed buttons as never before. But, those buttons were attached to something that did a more-or-less a recognizable task by virtue of the associated machine. It was a car, a coffee maker, a massage chair, etc. Clearly, regardless of the control system or buttons, a “machine or transformation of matter” was unavoidably an integral part of what was occurring; All patentable by virtue of that association.
The next steps of the digital revolution, however, changed how we thought about the control systems that helped us operate the device. We came to realize that the control system was the “device”. How many times did we hear the question: is that a Windows “machine” or a Mac? We bought updated versions of these machines to increase speed and capability of the device. To those of us who were untutored it was hard to tell whether anything had changed except that we were obliged to discard our perfectly working machine that we were used to using for a newer unfamiliar (albeit faster) machine. This is about the time the concept of software being patentable as a thing in its own right first arose. The decision, authored by Judge Rich, that led the way: State Street.
Thanks to Judge Rich phrase “concrete tangible result” entered our patent lexicon. It made sense to us in the field because it confirmed the machine or transformation standard for what a computer was being instructed to do. It was transforming data from one set of tangible useful information to another set of tangible useful information. Kind of an elaborate adding machine. A control system, in the form of code, would shove data through a series of logical steps and, as a result, create a transformed data set from the dataset that was originally shoved through. Okay, this is a very equivalent concept to a machine full of pulleys and gears that can be changed to alter operation of the machine, ie, make it run faster or slower, or have tighter or looser tolerances. Put in ears of corn, get out corn and cobs. The difference is, and it is only slight, is that the machine, i.e., the computer, is now but a temporary artifice, and can be reconfigured at the behest of coded instructions that arrive before the code that tells the newly configured machine exactly what to do in what order. In this way, my iPhone can be a bell that you physically shake and it goes “ding” like a hotel desk bell; or it can be a carpenter’s level to help hang pictures, level a cabinet; or, it can be a compass that swings this way and that just like the one from a long ago scouting exercise; or it can be a flashlight. Clearly, one can patent a bell, level, or compass in whatever form it exists, it is a device. That much is not in dispute. But, what about the “code” that creates that “device”.
It is now that we have the conundrum: is software (the code that both creates and instructs the machine) patentable apart from the machine? The answer to this question, when phrased in this way, is self-evident; yes, of course it is patentable. For the same reasons machines have always been patentable, they are a part of the “useful” arts. You see, the software is the machine. The machine is software. These are one in the same “thing”. If this is all so simple, then what is the argument about?
I think it comes down to the necessary level of disclosure (i.e., 35 USC 112(a)) required of an applicant to deliver to the United States Patent and Trademark Office (PTO), and thus to eventually benefit the public, in exchange for the time limited exclusory right of the patent. You see, the PTO is the guardian of the public interest. It is axiomatic that you cannot patent, or take credit, for more than you’ve given up to the public in exchange for that right. They and you, the applicant, both derive a benefit. The problem is when you try and patent an “idea” and not its fully developed tangible machine version. Let’s say I said to a friend let’s make an iPhone shake or tremble whenever it receives a GPS indication of the proximity of the girl you like, the guy you really dislike, or the ice cream man, or your mother, etc. Kind of an iPhone with “spidee senses”. You set it to “sense” others and let you know when to be on the lookout, when to run, etc. Okay, we know an iPhone can likely do this, but how to write the code to make it do this is another matter. There is no requirement in other fields of invention for an inventor to have an “actual” reduction to practice before filing a patent application. It is enough if the application itself is informing to one of ordinary skill such that the invention could be carried out without “undue” experimentation. This is where, in my judgment, the reality of the intangible idea that is at least possible meets the reality of patent law.
The CAFC, and others, have rightly recognized that merely writing up an intangible idea and associating it with generic computer bits and pieces does not transform it into a machine that can be patentable. It remains an intangible idea now with computer bits mixed in. It is not a machine. What makes it a machine is the code. Hence, the necessary disclosure to obtain a patent for software implemented machines is not any different from anything else. Enablement is necessary. The code, or its equivalent, must be present to obtain a patent for a software implemented method or machine. Hence, the claims, read in light of the supporting and fixed specification do not miraculously become latex and cover everything that is remotely similar. No, they cover what is reasonably enabled and described in the specification. If you write a narrow limited specification, your claims are likewise narrow and limited.
Next, is it is obvious? The standard for obviousness is, by now, well settled by virtue of KSR v. Teleflex and its many daily applications by the PTO and CAFC. The technical features of a smart phone make it capable of being configured to do many, many, things. The number and scope of the apps is almost limitless. Are each of these things separately patentable? No. For the same reasons that using a screw driver to sculpt, pry, bang, lawn dart, scrape, tent peg, open cans, remove oil filters, fish spear, grilling tool, electrical ground, etc. is obvious by virtue of the necessary structure and features of a screw driver. None of these screw driver uses has to do with driving a screw, but it doesn’t matter does it. A long stiff metallic lever with a handle is useful in myriad ways. In the same way, a smart phone with WiFi, accelerometers, touch screen, G4, etc., can do almost any function that combines those attributes. Merely rigging it up to combine a few features and getting them to work in synch should not get you a patent. I think this is where the general public, and the techies, run onto the reef. If a device is merely capable of doing something, and you make it do it, isn’t this an obvious extension of what it can do, i.e., the various machine forms that it can manifest? In all likelihood, yes. In the same way you might ask is this new transmission patentable, you should likewise be as discerning for software implemented machines. They are, after all, merely a machine.
Thus, the solution to the patentability of software is the same as it has been since 1790. Is the machine adequately described, and is it novel and unobvious.
About the Author
John White is a US patent attorney and a patent lecturer. He is an Adjunct Law Professor at the University of Virginia School of Law, and he is also the principal lecturer/author of the PLI Patent Bar Review Course, a course that he originally created. In fact, since John began teaching patent bar review courses in 1995, he has personally taught approximately 50% of all practicing patent attorneys and agents how to successfully become admitted to the Patent Bar. John has also taught numerous US Patent Examiners at the United States Patent & Trademark Office (USPTO) in the “Law and Evidence Course” necessary for them to advance to Partial Negotiation authority as Examiners.