One of the things that makes protecting computer related inventions tricky is that first you have to define the invention, and defining the invention is not something that is altogether easy when the invention is a computer process or relates to software. 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) to write the code that will enable the 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 for some, particularly those who are new to the patent arena.
Further complicating the matter is the reality that over the last several years the law of patent eligibility in the United States has been in flux. It did become largely settled with respect to software and business methods thanks to Bilski v. Kappos, which was decided by the United States Supreme Court. This case left the industry with the so-called “machine or transformation” test, which requires a process to be tied to a particular machine or apparatus, or transform an article into a different state or thing, in order to be patentable subject matter. The Supreme Court determined in Bilski that the machine-or-transformation test is not the only test for patent eligibility, but rather that it was an important clue. But what exactly does that mean?
Since the Supreme Court decided Bilski, the machine-or-transformation test has become thede facto test for patent eligibility; a safe harbor. If you satisfy the machine-or-transformation test then you have a patentable invention. Failure to satisfy the machine-or-transformation test and you may have a patentable invention, but there is not yet an example of a computer related process that failed the machine-or transformation test and was found to be patentable. Given this reality let’s focus on the machine-prong of the test, which asks whether the claimed process is tied to a particular machine or apparatus.
To be patentable subject matter the machine must impose a meaningful limit on the process claim’s scope, and the use of the machine must involve more than insignificant “extra-solution activity.” Thus, the claimed process must be more than “for use with a machine,” and must truly require implementation of the method steps by and through a machine. As for “extra-solution activity,” this relates to activity that is not central to the purpose of the method invented. Thus, if the machine is only present in a step that is deemed to be insignificant extra-solution activity, the claim fails the machine-or-transformation test, despite the presence of a machine in the claim. For example, a method untied to a machine would fail the machine-or-transformation test if the only link to a machine were to use e-mail to communicate results of a process.
What does the state of patent eligibility mean for software patents? If you truly have a software product and you completely, fairly and fully describe the invention you will not have a problem overcoming the patent eligibility threshold, not at least as long as the patent application drafted is written with Bilski in mind.
But when do you have a patent eligible invention? It irritates many computer programmers to no end to learn that the law doesn’t require a single line of code to be written before you can patent software. This irritates many programmers because they feel that the computer code is the end-all-be-all of the software program. That is simply not true either in reality or in the eyes of the law. Computer code is a language just like any other language, and the computer code is a set of instructions that will ultimately explain to the computer what needs to be done, how to accomplish the tasks and what to do with the information, both from a storage, manipulation and output standpoint. Thus, computer code is a set of directions.
The core of a computer program is not the code, but the design of the system. The computer code merely implements the vision, the requirements of the desired design in language that a computer can understand. The mental conception, which is what the patent law considers invention and what ultimately leads to a protected invention, relates to the design of the system, the system architecture and the road map set forth for the various processes, computations and manipulations of information that is acted upon. While it may be helpful to have some code written, and while the writing of the code will likely cause the system engineer tor reevaluate, add on and work around various things, it is the system design that is the invention, not the code. Thus, when you protect a software related invention you are not tying the protection to ask for or ultimately receive to any particular implementation in code.
Written properly the software patent will cover the myriad of different ways a computer coder will seek to accomplish the same task. Thus, software patents are far more valuable than copyrights. Copyrights protect computer code and are limited to offering protection against copy of the exact code written. If all you have is a copyright and someone writes different code to accomplish the same functionality you have no recourse. That is why software patents are critical for those that need to protect their proprietary efforts.
Notwithstanding the above, a patent does not have to be a blueprint, although the patent application must direct and evidence possession of the invention. 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 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.
So where do you start? As an inventor of a computer process what you want to do is first figure out the desired functionality. That is the easy part and the exercise that virtually everyone focuses on it, sometimes to the exclusion of the substantive considerations that must come next. Once you have the desired functionality determined, you need to figure out all the various paths that could be followed as one navigates through a particular task.
| Do You Have a New Invention Idea? CLICK HERE to Submit your Invention. 100% Confidential. No Obligation. |
Let me use a simple example. Lets say that you obtain a card that allows you to ride mass transit. Lets say the card employs a transponder in communication with reader equipment installed at the entrance to the mass transit terminal. Card in hand you approach the entrance to the mass transit terminal to scan your card so you can enter and ride the bus, train or subway. As you approach what could go wrong? You could swipe the card and the gate opens and you enter, but what if the card cannot be verified to be associated with an active account, or what if your balance in your account tied to the card is insufficient? You will be denied entry. What happens next? What process must be followed? In the case where the account balance is insufficient will there automatically be a retrieval of funds from an account tied to your mass transit card account? In the situation where the card cannot be verified to be tied to an active account will you be given “courtesy access” one time so that you can ride, get to work on time and sort the problem out with your account while on break? What happens in the event of a system outage? These are but a few of the things that can go wrong, and if your system does not address these and many other scenarios you have a problem. Indeed, with software the engineering of the system must take into account the human problems that will be encountered and provide work-arounds and solutions. SeeMurphy’s Law is Where Patentability Resides.
Any good patent application that covers a software related invention will need to put forth three specific pieces of information. First, you need to describe the overall computer architecture of the system within which the software will exist. Second, you need to prepare a single flowchart that depicts the overall working of the software. Third, you need to prepare a series of flow charts that show with painstaking detail the various routines and subroutines that together connect to create and deliver the complete functionality of the computer system as enabled by the software.
Yes, flow-charts! Many simply refuse to engage in the creation of flow-charts believing them to be unnecessary and superfluous. To the contrary, flow-charts are worth at least 10 times their weight in gold! Inventors really need to engage in the preparation of flow charts. At times I have worked with inventors to do this, swapping flow charts back and forth with inventors. I would learn what the they thought the basic invention was and then I would prepare a simple flow chart and send it to them. They would edit the flow chart and send it back to me. This process would go on in series until the processes were completed. This flow chart swapping exercise lead to basic flow charts that covered the broadest articulation of the invention, as well as a series of specific flow charts that described layers of nuances. Any patent application must include both general and specific articulations. This is critical.
Take a look U.S. Patent Application No. 20120214602. I want to draw your attention to the flow charts in particular. Notice the detail and the multiple paths that account for the various things that can happen. This is what you need to focus on creating. Once you have the flow charts to demonstrate the logic of the software then you have everything you need to start writing. The more flow charts the better!
[“source-ipwatchdog”]
