Writing Software Patent Applications

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.

[[Advertisement]]

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.

Conclusion

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.

Share

Warning & Disclaimer: The pages, articles and comments on IPWatchdog.com do not constitute legal advice, nor do they create any attorney-client relationship. The articles published express the personal opinion and views of the author as of the time of publication and should not be attributed to the author’s employer, clients or the sponsors of IPWatchdog.com.

Join the Discussion

10 comments so far.

  • [Avatar for Gene Quinn]
    Gene Quinn
    April 22, 2013 12:05 pm

    Anon-

    I don’t know of any other place where the law says we affirmatively do not care about what one of skill in the art would understand. Even with respect to means-plus-function claims, the algorithm cases eviscerates the foundation of 112(f).

    See https://ipwatchdog.com/2012/04/18/a-primer-on-indefiniteness-and-means-plus-function/id=23854/

    -Gene

  • [Avatar for Anon]
    Anon
    April 22, 2013 11:33 am

    I am just curious as to all of the other art disciplines out there if the understanding of a person of skill in the art cannot be relied upon in patent filings.

    Seems like patent prosecution will be reverting back to the times of Dickens.

  • [Avatar for Gene Quinn]
    Gene Quinn
    April 22, 2013 10:41 am

    Paul-

    The disclosure requirements tightening could easily and substantially affect the scope of the claims. In fact, it could render many claims invalid for lack of support. This is the problem with software at the moment. We don’t seem to care what someone of skill in the art would understand. That coupled together with the fact that when reviewed the disclosure requirements of the moment will be applied, not the disclosure requirements when filed or even issued, you can see the need to really do a first rate job on the disclosure. You only get one chance and it really needs to be overkill.

    -Gene

  • [Avatar for Gene Quinn]
    Gene Quinn
    April 22, 2013 10:39 am

    Step-

    Yeah… we can’t have ANY innovations that in any way require a computer. Perish the thought!

    In 100 years (probably less) folks will look back on those who made such ridiculous calls and laugh out loud at just how stupid they were.

    -Gene

  • [Avatar for step back]
    step back
    April 22, 2013 07:03 am

    German Parliament Sends Message: Stop Granting Software Patents

    (for the sake of “inNOvation”)

    http://www.ip-watch.org/2013/04/22/german-parliament-sends-message-stop-granting-software-patents/

  • [Avatar for Paul Johnson]
    Paul Johnson
    April 22, 2013 04:50 am

    How will this change to the disclosure affect the scope of the claims?

  • [Avatar for Gene Quinn]
    Gene Quinn
    April 21, 2013 05:17 pm

    Mark-

    Thanks for the shout outs!

    I agree with you. Whenever I do legal work I try and get them to complete the electronic questionnaire that is the heart of what I call the Invent and Patent System. Folks are usually game. The questions there force the inventor to answer each of your 3 points. They are essential. Once we determine something worth pursuing is patentable I also then ask them to start dreaming. Assume money is no object and computer resources (typically bandwidth and memory) are not limiting factors. What else would you want your invention to do? That is the fun part, and gives a fighting chance to come up with a disclosure that could have long legs.

    -Gene

  • [Avatar for Mark Annett]
    Mark Annett
    April 21, 2013 09:32 am

    Dear Gene,

    I have a workshop that I do on software patents for independent inventors and one of the things that I essentially add to your presentation above is that when filling in the details of the routines and subroutines that for each step they include:
    1) the simplest way that it could be accomplished
    2) the preferred method
    3) and the most sophisticated way that they can currently think of

    With the requirement that the first to need to be fully fleshed out.

    I was wondering if you provide similar guidance or if you have an alternate approach.

    As always, thanks for you valuable insights,

    Mark

    Ps IPWhatchdog always gets a very deserved shout out in my presentations!

  • [Avatar for Brian]
    Brian
    April 20, 2013 05:59 pm

    As someone who has been “skilled in the art” for 35 years, I have read many software patents over the years. The legal department where I work went through a phase of sending patents to us seeking an indication as to whether the company had a problem. I can say that without exception, every software patent I read would have been totally worthless if I was asked to use them as they are intended to be used. They were nothing more than a description of the problem, not the solution. They describe the end result of the software, not how to write software to achieve it. If you are writing software, you know what the problem is, so having a document that tells you what you already know, wraps it up in so much legal gobbledegook as to make it barely comprehensible, and is deliberately written to encompass as much functionality as possible way beyond what the inventor actually invented is of absolutely no assistance whatsoever.

    Flowcharts are an excellent idea. They would force the patent to contain the actual solution, not merely state the function or problem. It would limit the scope to the implementation as per the flowchart so that if someone else were to invent a different solution to the same problem or function, there would be no conflict. Programmers understand flowcharts, not the legalese used to write patents (lawyers are as bad at writing technical documents as engineers are at writing legal ones). So if we must suffer software patents, at least they will be a slightly useable.

  • [Avatar for EG]
    EG
    April 20, 2013 05:38 pm

    Gene,

    As you note, having a master flowchart describe generically the process that the computer program/software performs, along with other flowcharts to describe the routines and subroutines of the parts/stepsof that process is absolutely key in not only writing the specification, but in also putting together the claim set.