|
One of the things that makes protecting computer related inventions tricky is that first you have to distinctly identify the invention in exact terms. Defining any invention with the level of specificity required to satisfy U.S. patent laws is not something that is easy, but when the invention is a computer process or relates to software it is even more difficult. Sure, it is easy enough to define a list of desired functionality, and if you have some computer programming skills it is easy enough (after investing the requisite time, of course) to write the code that will enable that desired functionality, but that which can be protected via patent lies somewhere between the desired functionality and the code, making the defining of the invention rather elusive, particularly for those who are new to the business of inventing.
No patent application or issued patent must be a blueprint, but it must direct one of skill in the technical area or science so that they could be able to both make and use the invention without undue experimentation having only read the disclosure in the patent application or issued patent. What this means is that you do not have to provide micro-level details, but rather you need to be able to describe how a computer programmer would be able to get from point A to point B, with point A being a list of desired functionality and point B being the code that enables the functionality. So that which is patented is not found either at point A or at point B, but rather in between. The exclusive rights that will flow from a patent that protects computer processes will describe the journey from point A to point B. Said another way, you essentially want any patent or patent application to function as the equivalent of a design document for the software project.
It has become increasingly difficult over the past several years to get patents that cover software related invention in at least some sectors of the Patent Office. Business method and e-commerce patents are perhaps the most difficult to obtain, but other software can and does create challenges. Frequently inventors will come up with a first of its kind platform or software suite that integrates a bunch of known, disparate functionalities into a single platform or software suite. The fact that these functionalities exist together and significantly streamline processes is, unfortunately, not likely going to be enough. There needs to be some innovative contribution that goes beyond tying everything together.
The chief hurdle that has created the difficulty obtaining patents in the software space is the Supreme Court’s decision in Alice v. CLS Bank, which has infused a great deal of uncertainty into the law of patent eligibility. The good news is that any patent application filed now covering a software related innovation will undoubtedly sit awaiting a First Office Action on the Merits from the Patent Office for at least two years, more likely three years. That means that the law that will be used to evaluate the software patent applications filed today has not yet been written by the courts, and over the last year the Federal Circuit has finally started loosening the death grip on these patents and is providing meaningful guidance to patent drafters.
The delay also means the draconian interpretations of the Supreme Court’s Alice decision should have largely subsided by then, perhaps we will also have Congressional action once and for all settling the matter of software patent eligibility. Of course, the delay in examination at the Patent Office also means that the standard used by patent examiners is one that cannot be known today with any level of certainty. For that reason it is absolutely critical that computer related inventions describe the technology to the greatest extent possible, focusing on as much that is tangible as possible. In fact, a recent study of allowed software patents shows that incorporation of tangible, physical devices is what leads to these patent claims ultimately being allowed. In short, the software patent application you file today is not your father’s software patent application.
Anyone who had written computer code will know that there are an infinite number of ways to actually write the code, and likely a list of computer languages that could be used to write the code. The code itself and how it is written is protected via copyright, if at all, not through a patent. So when you are trying to define the invention so that it can be described adequately (and now with the virtually required level of technical overkill) in a patent application you do not need to detail every language that could be used, and you do not need to provide an outline of the routines or subroutines, but what you do need to provide is enough information so that the computer programmer could translate your description into code. In other words you want to provide enough detail to allow the computer programmer to create the outline themselves, understanding that the actual approach employed by the computer programmer will be as unique as they are. So you do not protect the creativity that will ultimately be expressed in code form, you protect that logic that underlies the journey from functionality to code.
Taking a step backwards, as an inventor of a computer process the first thing you want to do is figure out the desired functionality that will be provided. That is the easy part and the exercise that virtually everyone focuses on to the exclusion of the next, far more important steps. Next, you need to figure out all the various paths that could be followed as one navigates through a particular task. Let me use a simple example. Lets say that you have purchased a season pass to an amusement park. Lets say that this amusement park issues passes that have a magnetic strip on the back of the pass to be read by an appropriate scanner at the park entrance. So you have the pass and want to gain entry to the park. You approach the entrance. What could happen? You could swipe the card and the gate opens and you enter, but what if the card has become demagnetized? You will be denied entry. What happens next? What process must be followed? You paid for the pass so the fact that the card has somehow become deactivated should not prevent you from entering the park, but the employee at the park entrance is not going to let you in because your pass doesn’t work. You have a problem.
Actually, you do not have a problem per se, but to get to the solution that everyone wants (i.e., a happy patron in the amusement park) additional task(s) are required. So what you have encountered is a trigger. If your pass were not demagnetized you would have entered, but because it was demagnetized you need to follow a slightly altered route to gain access to the park. This is simple enough to understand, but this is the single largest problem I deal with when working with inventors who have a computer process related invention. So many folks simply describe their process as A to B to C to D to E. Software never has a linear path though. There are always questions, calculations, verifications, authentications, etc. To have any hope of obtaining a patent your software needs to take into account what occurs in the event that something doesn’t happen according to plan, and so too does the description of the invention. Indeed, patentability resides at the edge of Murphy’s law with software. Anything that can go wrong will go wrong, and your software needs to anticipate that and your description needs to explain it all with great technical detail. Generally speaking, the uniqueness of a computerized process will be with respect to how elegant solutions are crafted to handle and streamline those points of departure.
Not only do you need to take into account imperfection in the process, but frequently users will be allowed to enter different information that will then be reviewed and based on what information is collected you will take one path or the other. A good example of this would be at the airport where if you are a First Class Elite member you show your ticket and then go to the front of the line, where as the rest of us just stand in a hopelessly long line wishing we were special enough to be First Class Elite members.
As far as I am concerned the thing that inventors need to figure out first is the flow chart. With this in mind, take a look at U.S. Patent No. 4,862,357. This is an old patent and one that for many reasons makes choices in the way the invention is described that would not be appropriate today for a variety of reasons. Nevertheless, I want to draw your attention to the flow charts. Notice the multiple flow charts, the detail and the multiple paths that account for the various things that can happen. This is what you need to focus on creating as you figure out the logic of the processes at play in your system. Once you have the flow charts to demonstrate the logic of the software then you have everything you need to start writing. Of course, don’t be surprised if as you start writing you need to go back and add or amend your flow charts. And even when you get everything to the point where you think it is perfect, when you turn it over to someone who will do the coding, they will likely have dozens, if not hundreds, of questions. If the person doing the coding has questions that means your description wasn’t enough and needs to be supplemented.
First things first. Many inventors will come up with the logic and system architecture and will not be the ones who will write the code. That is why provisional patent applications are frequently a first step along a path to a software patent. Protect what you can describe to the greatest extent you can describe it today. File a provisional patent application and now you have a “patent pending.” Then as you work get the project coded a great deal more will be learned, which should go into either another provisional patent application or a nonprovisional patent application filed within 12 months of the original provisional patent application. But more of that patent strategy for another day.
|
