Writing Software Patent Applications
|Written by Gene Quinn
Patent Attorney & Founder of IPWatchdog, Inc.
Principal Lecturer, PLI Patent Bar Review Course Posted: April 20, 2013 @ 9:00 am
#The 1 Patent Bar Review Course
LIVE or HOME STUDY ~ CLICK HERE to REGISTER
Call 888.296.5973 and mention "IPWatchdog" to save 10%
Collecting the information necessary to prepare a patent application covering a computer related invention can be quite challenging. Typically, most computer related inventions today relate at least in some way to software, which is at the core of the challenge. This software challenge stems from the fact that the software code is not protected by patent law, but rather how the software operates is protected. This means that the description needs to be one that can be replicated by others regardless of how they choose to write code to accomplish the necessary tasks.
A patent does not need to be a blueprint, but it needs to direct. For example, you do not need to provide the code for the scripts, although that is certainly one way to make sure it is described adequately, and perhaps something you may want to consider if you have a working prototype that you want to protect (more on this later).
Generally speaking, the goal is to provide enough description so that someone who is “skilled in the art,” which is a legal term that refers to those who would be expected to possess the knowledge and understanding appropriate to comprehend the invention, can make and use the invention after reading the patent application. In order to satisfy the patent law description requirements the explanation of the software in a patent application must give the programmer enough information to be able to sit down and know how to write the code having only read the description contained in the patent application.
Think of the process in this way. When someone famous wants to write an autobiography or memoirs they frequently sit down and tell an accomplished writer who then writes. The accomplished writer is the computer programmer. The programmer will not write anything they are not explicitly told, just like the memoir writer. The writer does not make things up, so all the information necessary for writing must be provided. The word choices and how the story will be told will be decided by the writer. Similarly, when you have an invention that relates to software you need to provide all of the necessary information about what needs to be accomplished so that the computer programmer will not need to make things up, but rather will be able to follow directions. In other words, the inventor does not need to micro-manage the writing of the code, but the inventor must give enough detail so that the writing of the code will be a purely ministerial matter.
What I have successfully suggested in the past to inventors is that they sit down with the person who has or will be coding the invention. The inventor and programmer should collaborate to create a technical document, sometimes called a “design document,” that will give the programmer all the information necessary to sit down and start the programming of the code.
When you sit down to collect the information necessary to create the “design document” you have to keep three things in mind. 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. I will address each of these three things more completely in turn.
Overall Computer Architecture
Increasingly it is becoming more and more difficult to obtain a patent on business methods. Business methods became patentable subject matter in 1998 after the Federal Circuit’s decision in the now famous State Street Bank case. In May of 2008 the Federal Circuit, the chief patent court in the US, heard arguments in In re Bilski. In that case the court significantly cut back on the type of business methods that are patentable, requiring that the these types of methods be tied to a machine somehow. See Patenting Business Methods and Software in the U.S.
Essentially, the Federal Circuit did away with so-called “pure business method patents,” which are those patents that recite only business steps that are disassociated with a computer or overall system. Ultimately the Supreme Court overruled the Federal Circuit, but only to a limited extent. The pure business method of the Bilski case was found to be unpatentable, but the so called machine-or-transformation test that required business methods to be tied to machines in all cases was found to be too restrictive. The Supreme Court determined that it was possible that a method that does not satisfy the machine-or-transformation standard could be patent eligible. In practice, however, there has not yet been a single case where a method that did not satisfy machine-or-transformation was ever deemed patent eligible. Thus, machine tethering of a business method must be viewed as essential.
What this means is that any time you have a computer related invention you need to give serious thought to describing the overall architecture of the system that will perform the desired function. Merely reciting the process steps in a way that is disassociated from the overall architecture of the system will not satisfy the machine-or-transformation test and will lead to significant problems. Thus, the first thing you need to do is not focus on the software, but rather, focus on that hardware and how the hardware will be connected. This harkens back to a time not so long ago when computer software was not patentable. Even though computer software is patentable today, because so many inventions relate in whole or in part to a method of conducting business it is once again wise to consider defining inventions in terms of an overall system that has tangible components. What are those tangible components? Databases, servers, receivers, transmitters, memory? Describe as many tangible things as possible.
Master Flow Chart
Now that you have the overall computer architecture defined focus needs to shift to how it is that this computer system will operate to achieve the desired results. It is the software that will cause the system to operate as desired, so the software needs to be described with the greatest amount of detail possible.
Many times those who are new to drafting patent applications that relate to software will focus entirely on how the software is used from the perspective of the end user. This information certainly should be in any application, but it is not sufficient to describe things from the user’s perspective. As far as patent law is concerned, you should describe things from the user’s perspective, but such a description is not essential. The description that is essential is an explanation of how the software operates from the perspective of the computer, not the perspective of the user. This is a subtle but extremely important distinction. If you describe things only from the user’s perspective you are not describing what happens on a technical level. How things happen might as well be black magic. The user doesn’t care how information is passed along, what calculations are made or how data is compared. All the user cares about is what they enter into various fields and that they get a predictable and accurate output. So describing software from the perspective of the user is nice, and it is something that I always do to give context, but it is not something that is really very relevant insofar as the patent laws are concerned.
What you will need to do is explain how the software operates to achieve the desired results. In order to do this it will be absolutely necessary for you to break down the software step by step so that a computer programmer will be able to create the code necessary. What this means is that you must describe the logic that the computer programmer needs to follow. Regardless of how you describe the logic to the computer programmer, the way this logic needs to be conveyed in a patent application is through the use of a flow chart. At this point you need to create a single flow chart that demonstrates the overall logic of the software, from start to finish. There is no need to make this flow chart such that it will explain everything. You are creating a master flow chart that will show the logic from broad, overarching point of view.
Routines and Subroutines
Finally, what you need to do is break down the master flow chart into as many smaller pieces as possible. Here you will provide the fine details as to how the software will accomplish the larger tasks. You really want a series of flow charts that now show the logic of the major routines and subroutines.
But some may be quick to point out that they previously did not have to submit flow charts when they sought software patents in years past. That may well be true, but times have changed. There is a line of recent decisions from the United States Court of Appeals for the Federal Circuit, referred to as “the algorithm cases,” which are a substantial departure from traditional jurisprudence in the area. The algorithm cases say that it is immaterial whether one of skill in the art would understand the full invention from the disclosure provided, but rather what is required is that 100% of each and every algorithm must be disclosed. Now don’t panic. These cases deal with a particular claiming technique, not all claiming techniques. Still, it is easy to envision a day when this requirement is applied across the board in software patent cases. In fact, many notable academics are already urging courts to do just that. Thus, it is best practice to seek to satisfy this new, much stricter disclosure requirement. By so doing you have opened up another avenue of claims that can be pursued, and you have created a much stronger patent application that will support numerous patent claims and can legitimately be the foundation of a patent portfolio moving forward.
Thus, flow charts, pseudo code or even software code that describes the routines and subroutines can and should be included in what you file when you file a patent application that relates to software. The rules engine that defines the “if this then that” will become a critical component of your software and of your patent application.
Once all of these pieces of information are collected you are now ready to start writing the application. Alternatively, if you are going to hire a patent attorney to assist you now is the time to move forward.
If you need assistance with a computer related patent application feel free to contact me. My firm and I do quite a lot of work in this area for inventors and we can certainly assist you.- - - - - - - - - -
For information on this and related topics please see these archives:
Posted in: Gene Quinn, IP News, IPWatchdog.com Articles, Patents, Software, Software Patent Basics
About the Author
Gene Quinn is a Patent Attorney and the founder of the popular blog IPWatchdog.com, which has for three of the last four years (i.e., 2010, 2012 and 2103) been recognized as the top intellectual property blog by the American Bar Association. He is also a principal lecturer in the PLI Patent Bar Review Course. As an electrical engineer with a computer engineering focus his specialty is electronic and computer devices, Internet applications, software and business methods.