A Guide to Patenting Software: Getting Started

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

Let me use a simple example.  Lets say that you obtain a card that allows you to ride mass transit. Lets say the card employs a transponder in communication with reader equipment installed at the entrance to the mass transit terminal. Card in hand you approach the entrance to the mass transit terminal to scan your card so you can enter and ride the bus, train or subway.  As you approach what could go wrong? You could swipe the card and the gate opens and you enter, but what if the card cannot be verified to be associated with an active account, or what if your balance in your account tied to the card is insufficient? You will be denied entry.  What happens next?  What process must be followed? In the case where the account balance is insufficient will there automatically be a retrieval of funds from an account tied to your mass transit card account? In the situation where the card cannot be verified to be tied to an active account will you be given “courtesy access” one time so that you can ride, get to work on time and sort the problem out with your account while on break? What happens in the event of a system outage? These are but a few of the things that can go wrong, and if your system does not address these and many other scenarios you have a problem.  Indeed, with software the engineering of the system must take into account the human problems that will be encountered and provide work-arounds and solutions. See Murphy’s Law is Where Patentability Resides.

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.

Yes, flow-charts! Many simply refuse to engage in the creation of flow-charts believing them to be unnecessary and superfluous. To the contrary, flow-charts are worth at least 10 times their weight in gold! Inventors really need to engage in the preparation of flow charts. At times I have worked with inventors to do this, swapping flow charts back and forth with inventors. I would learn what the they thought the basic invention was and then I would prepare a simple flow chart and send it to them. They would edit the flow chart and send it back to me. This process would go on in series until the processes were completed. This flow chart swapping exercise lead to basic flow charts that covered the broadest articulation of the invention, as well as a series of specific flow charts that described layers of nuances. Any patent application must include both general and specific articulations. This is critical.

Take a look U.S. Patent Application No. 20120214602.  I want to draw your attention to the flow charts in particular.  Notice the detail and the multiple paths that account for the various things that can happen.  This is what you need to focus on creating.  Once you have the flow charts to demonstrate the logic of the software then you have everything you need to start writing. The more flow charts the better!

If you need assistance with respect to a computer related invention please feel free to contact me directly. My firm and I have quite a bit of experience working with these types of inventions.


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

14 comments so far.

  • [Avatar for Gene Quinn]
    Gene Quinn
    May 2, 2014 12:23 pm


    That is your opinion, but if people were to follow your opinion and wait in many cases they would no longer be able to obtain a patent even if the Supreme Court finds all the claiming techniques create patent eligible claims. In the patent world you just can’t wait, particularly now with the U.S. being first to file. Thus, business must go on and innovators and the patent attorneys that represent them still need to move forward.

    We know for sure that if the Supreme Court follows the law software will be patent eligible anyway.


  • [Avatar for donny]
    May 2, 2014 04:14 am

    this article needs to wait for CLS Bank

  • [Avatar for Wayne Borean]
    Wayne Borean
    February 25, 2013 03:29 pm


    Is there a comment of mine caught in the spam filter?


  • [Avatar for Blind Dogma]
    Blind Dogma
    February 18, 2013 11:17 am

    step back,

    the chesire cat in me grins at your post.

  • [Avatar for step back]
    step back
    February 18, 2013 08:07 am


    I’m wondering out loud if it would shock some of these anti-software judges
    if we could point out to them that, “Your honor, you yourself are software.
    In the past 10 years almost every molecule in your body has been replaced.


    The only thing of you that remains “you” is your pattern where the latter is mostly established by your DNA and by your neurological connectome, in other words, basically by your software. To assert that software is not real is to assert that you yourself are not real.”

  • [Avatar for Mark Annett]
    Mark Annett
    February 18, 2013 08:03 am

    I am very much on board with your master flow diagram. But I take a different approach to what additional supplemental flow charts that I need. My approach is have the simplest master flow diagram that functionally performs the intended functionality and then my supplemental flow charts show enhancements added to my master flow diagram. These are sort of my contingency master flow diagrams in case my initial master flow ends up being non-patentable.

    Then rather than showing in painstaking detail the various routines and subroutines that need to occur what I do is I describe in words the following: the simplest approach that can be thought of to accomplish a particular step in the master flow (or its supplements), the approach that will most likely be actually implement, and then the most sophisticated approach that we are currently aware of or that might be available soon.

    My goal is to make sure that at least the first two above are “instructionally” enabled.

    I find that this structured approach works better in words than in flow diagrams.

    Am I missing something or are you talking about more sophisticated software than I typically work on and therefore what you consider a master flow needs to be “chunked” down to the point that you can do what I describe above? Or, do you choose to implement in flow diagrams the structured options that I implement in words?


  • [Avatar for Ron Hilton]
    Ron Hilton
    February 17, 2013 06:48 pm

    I think it is good practice to have a variety of claim types, including apparatus (the essential software modules), system (apparatus + hardware), method (functionality; a flowchart in words) and program product (method on computer-readable media). Hopefully at least one of these claim types would survive a court challenge as the law evolves during the life of the patent.

  • [Avatar for Gene Quinn]
    Gene Quinn
    February 17, 2013 03:13 pm


    PA to PA… I’m not entirely sure. I do think it is possible that in hindsight we will look back in years to come and make that observation.

    I personally think it is far more likely that the algorithm line of cases will be extended outward beyond the means-plus-function context.

    Sadly, we are in for some difficult years as we continue to have judges who simply don’t understand software. This is compounded by the so many in the software community that themselves refuse to ignore that software is really a series of instructions directed toward computer (or machine) operation.


  • [Avatar for step back]
    step back
    February 17, 2013 01:26 pm


    So patent attorney (pa) to pa what are you saying?

    What is claimed is:
    1. A non-abstract and non-ephemerally-transient machine comprising:
    (a) a first programmatically configurable machine part configured to perform a first function of ….
    (b) a second ……; and
    (z) an Nth programmatically configurable machine part configured to perform ….
    wherein portions of said machine parts can overlap in physical space while not overlapping in temporal space.

    Are we back to this in the “enlightened” 21st century?

  • [Avatar for Gene Quinn]
    Gene Quinn
    February 17, 2013 11:56 am


    This article is primarily intended for those who are approaching a software project and wanting to get a patent, but who are new to the area and are trying to figure out what they need to know to get the ball rolling. It might also be useful to know that typically my clients are starting out, maybe have some code or pseudo code written, but are at the beginning of a project.

    Also, I titled this “A Guide to Patenting Software: —–” specifically with the intent to make it a series. There will be others in the series that will address specific issues more in depth and take a look at various cases and what we can pull from them.

    Before getting into my response… I think we are unfortunately hamstrung by the fact that the cases we see in this space so far are inventions that suffer from an infirmity of one kind or another. That is not to malign the attorneys. Pre-Bilski patent applications are a challenge in many cases because the inventions were written in an intellectually honest way acknowledging that the method was the unique innovation. Increasingly we are heading back to the 1970s where the machine needs to be treated like it is the unique inventive contribution even thought that is simply not true.

    In terms of “software engineer” and how that differs from a programmer… in my practice experience those who are programmers will not stop and think about the overall system and what it needs to accomplish both in the macro and micro scale. What they do is write code, so they jump in writing code. The only documentation they will frequently have is within the code itself. While documenting within the code is essential, that doesn’t create a design document that can be followed and means that the attorney might have to sift through hundreds of thousands of lines (or more) of code. That isn’t a recipe for successful patent drafting. In my experience with code writing it isn’t the right course to pursue if one wants a successful project either. The project needs planning. Just sitting down and writing code without thinking through what you want to accomplish is no different than writing a patent application without an idea of what the invention is to start. So I stress to my clients the importance of considering things from both a macro and micro perspective.

    In terms of the machine, I understand your position. What you raise seems to be what some examiners in certain Art Units are raising as well. I think this is missing what machine-or-transformation means. MOT requires a tethering of the process to a machine and extra solution activity is not enough to satisfy. I don’t know how the computer can be extra solution activity if the process as defined in the claims won’t work absent a machine. I have seen examiners databases are extra solution activity, which is absurd. Without the database the process won’t work, so the process that includes storing and retrieving information from a database, performing calculations and then restoring to a database, for example, has to satisfy machine-or-transformation. If there needs to be something unique about the computer structures then software is no longer patentable and we have to simply pretend that the hardware is what makes things different, when we know that not to be the case.

    In terms of the contingencies, I don’t know that one has to absolutely consider them, but if they are not being considered at the drafting stage then I do think there is a big mistake. In order for the system to work once coded it has to have all kinds of contingencies. Delivering a system that returns an error code every time it is not used exactly as designed doesn’t create a very useful system. If the person or people who are designing the software/system want to be the inventors they need to explain to the code writer what needs to happen in all the various situations, otherwise the code writer is the one making the choices. If those choices wind up being important for a claim limitation then the code writer is an inventor.

    I also think that the more contingencies that we can get a client to articulate the more likely we are to see things that contribute to patentability. If A then B is the type of static event that doesn’t necessarily help patentability, but dynamic rules make a system more complex, and that in turn makes it far more likely to be unique (i.e., novel and nonobvious), and the complexity then also should contribute to satisfying the machine or transformation test (i.e., the more complex the more integral the machine in order to accomplish the task/functions).


  • [Avatar for Gene Quinn]
    Gene Quinn
    February 17, 2013 11:36 am


    No, I don’t think this article needs to wait for CLS Bank. As a “getting started” article it is intended to explain to those who are embarking on the path to protect their innovation what they need to do. Whatever the decision in CLS Bank these types of inventions will still be patentable. The initial steps to discovering and defining what the invention is will remain the same from a practical standpoint (i.e., behind the scenes). Flow charts will never go out of style. Although it went beyond the scope of this article, flow chart are really one of the best ways (if not the best way) to satisfy the algorithm cases. I suspect that strict disclosure requirement from the algorithm cases will ultimately wind up being the rule of the day even when means plus function is not employed.


  • [Avatar for tifoso]
    February 17, 2013 08:44 am



    . . . which event is not the core . . .

    . . . Footwear Engineer. Lewis . . .

    Sorry. Eyesight not so good today.


  • [Avatar for tifoso]
    February 17, 2013 08:40 am

    Gene –

    Interesting but there are a few minor points on which the topic could be expanded.

    When satisfying the machine-or-transformation test, is it sufficient to state that the computer is a von Neumann machine? (One can see the SCt puzzling over that one, considering the mess CJ Rehnquist made of “falsifiability in Daubert v. Merrell Dow Pharmaceuticals, Inc.) The von Neumann machine is the “overall architecture” of the vast majority of all computers that have been produced since the time of UNI’VAC I. If that is sufficient, does that render the machine-or-transformation test a virtual nullity? Any wise practitioner will have a boilerplate statement that the machine is a von Neumann machine or has the overall architecture of a von Neumann machine. Or must the description get into issues such as interrupt processing vs. polling, caching, overlapped fetch and store, word vs. byte, etc.? The topic can become deeply muddled if we consider the issue of programs as abstractions, that is, divorced from the hardware.

    You refer to including a description of what the software does when some event occurs which event it not the core functionality of the software (my words). You are referring to “contingency handling”. The rule of thumb is that 90% of the code covers the 10% that is contingency handling. Is it sufficient to state that if some “unintended event” occurs, the system responds with an error message, e.g., “404 error” or must there be some more “graceful degradation” of the system? Isn’t that really a design choice rather than a mandatory? Does the invention lie in the contingency handling or in how the mainline functions deal with input? Where is the inventive step in rejecting input that is malformed?

    You refer to a “software engineer”. How does an SE differ from a systems analyst or programmer?
    This term seems to have come from the engineering schools which would label a bootblack a Footwear Engineer Lewis Carroll (or his character Humpty Dumpty) would have had much fun with this.

    Might it be better stated that a copyright covers a particular implementation of a system design? The same system can be implemented in COBOL, Fortran, C, C++, PROLOG, or any of the other inhabitants of Jean Sammet’s Tower of Babel and still be patentable.

    Again, not disagreeing with you, Gene. Just fleshing out some parts.


  • [Avatar for Blind Dogma]
    Blind Dogma
    February 16, 2013 04:39 pm

    Shouldn’t this article wait until after CLS Bank is decided?