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.  What you need to do is 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 this case it is widely expected that the Court will significantly cut back on the type of business methods that are patentable.  It would be quite unexpected for the Court to rule that business methods cannot be patented, but it is indeed anticipated, by me and others, that the Federal Circuit will require business methods to be associated with a system and likely with an overall computer architecture that enables the business method to be performed.  It is also widely anticipated that the Federal Circuit will do 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.

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.  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.

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.

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.