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 the de 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 limiton 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.
Comments
Post a Comment