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 very core of the challenge. This software challenge stems from the fact that the software code is not protected by patent law but is instead protected by copyright law. This is because software code is expressive, written in a language that can be translated into machine understandable instructions. As such, the code is the expression of the invention, not the invention itself.
The invention when one is talking about software resides in the uniqueness of the set of functionalities that will direct operation of a particular machine or system. That uniqueness can be with respect to how the information is handled, stored, compressed, or transferred. The uniqueness resides in how the software operates, not the particular code that tells the machine what to do. The invention that will be protected in a patent – assuming the innovation is patentably unique – is language independent.
The code is not protected, but rather the structures and processes that deliver the functionality are what 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. It also means it is preferable to approach this task of innovating the way an engineer would approach the task, rather than simply sitting down and writing lines of code, stringing them together without documentation. The documentation, the explanation, the story of the technology and innovative advances and improvements is what will make all the difference when seeking a patent on a software related invention. Millions of lines of undocumented code are a nightmare from a patent perspective, not to mention a scalability perspective.
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 they are 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 requirement, the explanation of the software in a patent application must give a 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 memoir 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 instead will be able to simply follow directions. If this is the case the computer programmer is not an inventor because they are merely following the instructions and directions of someone (i.e., the inventor) who maintains mental dominion over the invention. 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.
Obviously, when an accomplished computer programmer sets out to write code, even if they have the most detailed specifications provided by the inventor, the computer programmer will interject their own creativity. If the computer programmer interjects creativity that rises to the level of what the law considers conception, the computer programmer would become a co-inventor. Therefore, it is always wise for inventors who have engineered the overall system architecture to enter into agreements with those they hire to code making it clear who will own any inventions.
Assuming you have an agreement in place that defines ownership of intellectual property rights, particular invention rights (i.e., patent rights), consider sitting down with the person who will be coding the invention. The inventor and programmer can collaborate to create the technical document, sometimes called a “design document,” that will give the programmer all the information necessary to 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.
Overall Computer Architecture
Increasingly it is becoming more and more difficult to obtain a patent on software related inventions. The cases from the Federal Circuit and the Supreme Court say that having tangible components in the invention do not alone make an invention patent eligible. That is all well and good, but let’s not kid ourselves – the tangible matters.
Machines have been patentable in the U.S. since 1790, and a faster machine has always been something that could be patented. It is hardly surprising that the Federal Circuit has over the past several years focused on the improvement being made. If you describe the technological improvement the innovation makes, and you claim that improvement you are within the safe harbor cases, which include Enfish, Thales Visionixand others.
Similarly, if you describe the technology at play from a system level viewpoint and claim that innovation you will be far more likely to overcome any patent eligibility concerns. This necessarily requires discussion of the tangible components, as well as a technological description of how everything is working together to achieve the solution.
Whether we like it or not, and whether the law actually specifically includes it or not, the Federal Circuit has adopted the European approach to patent eligibility of software. The software must provide a technical solution to a technical problem. The more that is explained about the tangible technology and how the technical solution improves functionality and/or solves the problems can only be of benefit. In fact, while tangible elements are not enough in and of themselves when presented in a disembodied way, done properly the incorporation of the tangible into the disclosure of the technology is absolutely the best practice. It is the answer and why those who have been filing solid patent disclosures haven’t had problems even with pre-Alicecases.
What this means is that any time you have a computer related invention you must describe 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 current patent disclosure requirements.
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 – at least not unless you are seeking to protect a Graphical User Interface or User Experience, which I’ll write about in a later article.
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.
And if you think you can show logic without a flowchart you need to come to believe you are mistaken. Sadly, it seems that computer logic classes are not taught like they once were, or they are only taught in engineering or only to electrical and/or computer engineers. In any event, if you are unfamiliar with computer logic as course and/or have never read a computer logic text I suggest you try and find such a course at a local college. If you are an inventor in this space, or a practitioner who will be doing work in this field repeatedly, you must be familiar with the fundamentals of a basic computer logic class.
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. 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 (i.e., means plus function claiming), not all claiming techniques. Still, it is easy to envision a day when this requirement is applied across the board in software patent cases. Thus, it is best practice to seek to satisfy this much stricter disclosure requirement regardless of the claiming techniques you envision using when you file the application. By so doing you will 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. You should also have security against further creep in the law, the way we saw withAlice.
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, as was seen in McRo, where the presence of rules is what saved the claims to a lip synchronization invention that was truly remarkable.
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.
Image Source: Deposit Photos.