Software Patents and Murphy’s Law: Uncertainty is Where Patentability Resides

By Gene Quinn on March 29, 2010

When embarking on a software development project it is critical to understand that in order to both maximize the chance of obtaining a patent, as well as the likelihood of developing a working computer implemented process, you need to approach the task with an engineering mind set, as well as a healthy familiarity with Murphy’s Law.  Anything that can go wrong will go wrong, and once you release the process to end users a human element will complicate what should otherwise be a predictable, linear, machine driven response.  Embrace the uncertainty and challenges because the fact that software rarely, if ever, works like it should is what makes a working process patentable.

The term “software patent” does not really have a universally accepted meaning. It is probably safe to say that in its broadest definition a software patent is any patent that covers a computer implemented process. This definition, however, is not all that satisfying because it is incredibly broad and ignores the reality that the computer implementation of processes, at least on some level, is increasingly becoming intertwined with a wide array of devices and gadgets. These devices and gadgets are tangible, and patentable, but yet rely on software to make them unique. At the very least these devices and gadgets rely on at least some computerized implementation in order to provide full functionality.

When you set out to define a patentable computer implemented process it is essential, in my opinion, to view the innovation as a system that provides a desired set of functionalities. I always encourage the inventors I work with to envision the system from at least three distinct views: (1) from the view of the end user; (2) from a systems/architecture view; and (3) from the viewpoint of the computer.

With respect to the first viewpoint, the view of the end user, this is typically quite easy, and what most inventors are good about describing. Here we spend time on graphic user interfaces and what I refer to as “click here, do that” type descriptions. Working to define these aspects is essential, but not enough in and of itself. It does, however, typically create the framework, at least initially. Many of the broadest software patents and computer related patents that have come under enormous scrutiny and ridicule limit themselves to vague description of the process from the viewpoint of the end user. These patents are typically characterized as business method patents.

The term “business method patent” also doesn’t have a well developed meaning, but is probably most often used to describe pure business methods (i.e., methods without any computerized reliance or tangible hardware/devices involved) or what could be called quasi-software used to provide certain business functionality. I refer to it as quasi-software because as described it masquerades as software by expressing only method steps and little, if any, tangible equipment or underlying technology or system structure. Once upon a time this was how many software and business method patents were written, many by attorneys and agents who did not specialize in software or computers. This, however, is likely what will no longer be patentable after the Supreme Court decision in Bilski, or soon thereafter will not be patentable once the Federal Circuit gets to weigh in with a more restrained scaling back of software and business method patents post-Bilski.

The second viewpoint focuses on the tangible items that together are necessary to provide the overall functionality. This allows us to tie the processes directed by the computer (i.e., software) to tangible items that have always been patentable. There is a significant advantage to describe the underlying technology, hardware, data structures and communications technology. This is because the more you make something look like other things that have long been patentable the better your chances are of convincing someone, like a judge down the road, that what you have is a true invention because there are pieces and parts that can be identified and touched. Additionally, as of right now under the current Bilski standard set by the Federal Circuit this is the only way to attack software patent applications. Even if the law changes or modifies, which is a virtual certainty, this is clearly the best way to ensure the patent application enables one of skill in the art to both understand, use and replicate the invention, all of which is required in order for you to have a viable patent application and ultimately valid patent claims.

  Do you have a software related invention?
If you need assistance with a software patent, Internet technology,
computer device or other invention IPWatchdog founder and patent attorney
Gene Quinn can help. CLICK HERE to CONTACT GENE.

The final focus should be from the viewpoint of the computer, and this is where things get interesting and we encounter Murphy’s Law on steroids!  Here the approach is to consider the process as if the computer were a person engaging in the computations, manipulations, verifications, routing and other functions necessary to take information/data in and output other information/data in a usable format. This perspective is critical, in my opinion, because this is typically where the core innovation resides. Simply describing a vague and amorphous set of process steps can and will lead to broad claims, but claims that will almost certainly overlap with at least something in the prior art.  Furthermore, once you realize an end user will be providing the contemporaneous instructions and commands to prime action, you realize that it is not at all surprising that even the best thought out process is doomed if there are not a series of fail safe, idiot proof measures embedded within the system architecture and code.

Now I am not suggesting that the invention be described in a patent application as being capable of being done by a human in any relevant time frame, but without knowing exactly how the computer processes and otherwise handles information/data the patent application will be woefully inadequate, and in appropriate attention will have been placed on the human element driving the process.  I believe this is why software patents have been so maligned, because when they simply talk of “accepting data, processing data, outputting data” the process steps lack the typical concrete explanation required in a patent application, and it assumes everything will work every time without fail.

This type of naked description, without more, does little more than explain to the computer programmer what generally needs to be done and leaves them open to figuring out the implementation. While a patent application does not need to be a blueprint, it does need to direct and it should envision not only the optimal path, but should embrace checks and balances that understand the computing power of the end user will be less than the computing power of the machine running the process. Therefore, what is essential to the patent process, and likely to the successful completion of the development of software, is to have a design document that lays everything out for the programmer and takes into account the human element. You essentially want the programmer to be a translator. You want them to be able to take your design document and code it up into whatever language they choose, but you don’t want them making choices. You want to retain mental control over the invention, which translates into you being the conceiver and the programmer being the reducer to practice that follows your requirements.

There is a fine line, however, between creating a set of desired functionality and having a patentable invention. I suspect that where the law will ultimately head is to a place where patentability focus is placed on how quickly there is reduction to practice after articulation of the process steps. For example, if you articulate your desires and a programmer say “no problem, that can be done,” you probably don’t have an invention. Alternatively, you may be working with someone who over-promises and will under deliver, but that is a different story for a different day. Assuming there is simply rote implementation, then there is probably not conception and likely not an invention. This being the case, as you are going about articulating the process and creating a design document or project management series of deliverables, you want to make sure you focus on those areas where the coding and implementation will not be rote, but will require ingenuity or first-of-its-kind development. That is where the innovation resides and what must be the focus of the patent application.

As with any invention, software frequently takes what previously existed and makes it better. So just like with any improvement patent, if your computerized process is faster, more accurate, uses less resources, provides enhanced functionality, is more compatible and platform independent, then you may have an invention. If your enhancements make the computer implemented process enough better that people would be willing to pay a premium, then you likely have an invention worth protecting via patent.

As you embark upon defining the invention you also want to spend time articulating the problem with previous solutions and why your software, system or process is better, and perhaps more idiot proof. You may not want to include that in your patent application any more, or in a very watered down fashion. The law of obviousness being what it is today if you describe the problems with the prior art very well you might be creating your own obviousness rejection. Eventually KSR will become watered down and either statutorily repealed or gutted by the Federal Circuit, or nothing will be patentable because literally everything is obvious under KSR. That is not how it is being applied, thankfully, but still why take any chances. Nevertheless, working through and being able to explain the problems with the prior art and how your invention is better will pay dividends because this will allow the primary focusing on those core aspects of your invention that are most likely patentable.

The Author

Gene Quinn

Gene Quinn is a patent attorney and the founder of He is also a principal lecturer in the PLI Patent Bar Review Course and an attorney with Widerman & Malek.

Gene’s particular specialty as a patent attorney is in the area of strategic patent consulting, patent application drafting and patent prosecution. He has worked with independent inventors and start-up businesses in a variety of different technology fields, but specializes in software, systems and electronics.

is admitted to practice law in New Hampshire, is a Registered Patent Attorney licensed to practice before the United States Patent Office and is also admitted to practice before the United States Court of Appeals for the Federal Circuit.

Gene is a graduate of Franklin Pierce Law Center and holds both a J.D. and an LL.M. Prior to law school he graduated from Rutgers University with a B.S. in Electrical Engineering.

You can contact Gene via e-mail.

Warning & Disclaimer: The pages, articles and comments on 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 and should not be attributed to the author’s employer, clients or the sponsors of Read more.

Discuss this

There are currently 12 Comments comments.

  1. Blind Dogma March 29, 2010 3:45 pm

    I am certain of the types of comments this entry will produce.

  2. step back March 29, 2010 4:37 pm

    Perhaps we need a patent application for automated method of bringing more eyeballs to a patent related blog, said method comprising the machine implemented step of providing a blog heading having at least one of the text strings, ‘Bilski’, ‘software’ and ‘business method’ included therein?

    With that said, debugging a program is a routine and expected part of software development. It doesn’t make a software invention either patentable or unpatentable. The manner in which an invention was arrived at does not negative the patentability of that invention.

  3. Gene Quinn March 29, 2010 9:00 pm


    Based on your comment I suspect you believe I have said that debugging a program is not routine, is unexpected and will make the software patentable. Is that true? If yes, where did you come up with that reading? Did you stop reading at the first paragraph?

    If you can sit down and start programming without any thought and are merely acting as a translator then there is likely no innovation and no invention, just a reordering of what has previously existed using known techniques. It is my belief that if the project is so simple that it can be completed without need to a design document then there is no invention.

    In terms of the manner in arriving at the invention, you are so old-school. I know that is what 35 USC 103 says, but it also happens to be what the Supremes in KSR ignored.


  4. Blind Dogma March 30, 2010 9:55 am

    test test

  5. Blind Dogma March 30, 2010 9:57 am

    For example, if you articulate your desires and a programmer say ‘no problem, that can be done,’ you probably don’t have an invention.

    Well obviously, you need a flash of genius, don’t you?

    Nevertheless, working through and being able to explain the problems with the prior art and how your invention is better will pay dividends because this will allow the primary focusing on those core aspects of your invention that are most likely patentable.

    Agreed – in your patent writing process – but as you noted, leave out of the patent itself because of KSR.

    In terms of the manner in arriving at the invention, you are so old-school. I know that is what 35 USC 103 says, but it also happens to be what the Supremes in KSR ignored.

    And I thought that you were a champion of what the law actually says. Gene, when did you just get tired of defending what is right?

  6. Gene Quinn March 30, 2010 4:09 pm


    Relax… no need to panic.

    I can see how you might think I am looking for a flash of genius, but actually I am just looking for conception. Trying to explain this to software folks has lead me to try and come up with ways to convey legal realities into every day language. What I try and get across is that if all you are doing is just reordering things that are known and putting them up on your unique website, that an invention does not make. So what I try and stress is focus on the part of the project that was challenging, required thought or was lacking in whatever else has been done. This allows me to get them to explain to me from a functionality standpoint what the improvement or uniqueness is, which then allows for drilling down on the structure/process.

    I think it is safe to say that I try and pull my clients along to higher ground, where there is maximum safety. So it sure doesn’t hurt if there is a flash of genius, or I can articulate what they have done to accentuate the genius. I know that shouldn’t be necessary, isn’t what the law says, but unfortunately seems to be where we are headed without some Congressional oversight. That being the case, I will continue to fight the good fight for truth, justice and the American way, while at the same time describing inventions in a way that worked under State Street, that works under the CAFC Bilski view and which will work under more restrictive tests that might come to bear as whatever Bilski decision the Supremes give us matures. Broad to narrow, everything should be articulated in the disclosure for claims to be added.

    Now, if the Supremes would only read that last sentence of 103(a), or Congress would amend it by underlining it!


  7. step back March 30, 2010 5:39 pm

    It is my belief that if the project is so simple that it can be completed without need to a design document then there is no invention.


    With due respect, my religious beliefs go the other way. If an inventor sees an incredibly simple way of achieving a novel and nonobvious result (which is also highly useful to others) with code so short that it can be crafted without need for a design document, then that inventor is a genius and the mere fact that he came up with truly tight and elegant code for achieving the result should be reason to applaud him not to deride his abilities.

    Anyway, we have bigger fish to fry this week with the Myriad decision. So let’s bite into that juicy one first.

    BTW, rumors are floating that Bilski is coming out soon. Have you heard something more substantial than just rumors?

  8. pop March 31, 2010 11:04 am


    I understand exactly where you are coming from and I think you hit the nail on the head on many issues. The only reasonable example I can think of right now is of a chef.

    If you decided to fill pasta with carrots and asked a chef to do it, then I’m sure he would have no problem with it because it is very similar to making other kinds of stuffed pasta. If you however, requested that the carrots still be crisp and hard after cooking, then you might be in for some trouble because they are likely to steam and boil in the pot. If some brilliant chef figured out a way to coat them with a oil mix or something that would allow them to cook and retain their freshness inside the pasta, then that might be unique, non-obvious, and useful. The example is quite stupid I admit, but I think it gets the point across.

    I hope you are right about the direction things are heading in Gene.

  9. Gene Quinn March 31, 2010 2:02 pm


    I wouldn’t say your example is stupid. I think that is the perfect example. I am sure there are others, but the key is you have to look for that which is unique. If there is nothing unique then why attempt to get a patent? Perhaps you do it as a defensive proposition, but focusing on what is unique, or the non-trivial challenge, will turn much software into something that could potentially be patented. It would at least (or should at least) be patentable subject matter, so the core issue would be whether it is something that has already been done before.

    I think the problem with software patents is twofold. First, in the early days of the Internet and business methods everyone ran to patent old business methods not capable of being carried out in real time over wide geographical areas. At best this is a unique way of using a new technology, but more likely a known way of using a new technology. The underlying technology should be patentable, but I have a hard time understanding why a known use of a new technology should be patentable without a core uniqueness, as discussed above.

    Second, over time many patent attorneys who didn’t understand computers or software started looking at the patents and applications and came to the conclusion that they are hardly descriptive in the same way as a tangible invention. That is true in many respects. But they must have figured that they could write such non-specific patents themselves, which many did. The trouble is they never really understood what they were doing, and had no hope of understanding the core uniqueness. That lead to crazy, overbroad applications that sometimes issued.

    These two things clouded the viewpoint of many and made them cynical. So then when you have some foundational technology applied for and a patent issues 12 years later everyone throws up their hands and says “that has been used for a decade, this is crazy.” That is true, but irrelevant if the patent application was filed before it was used or known by everyone. The problem is patent office delay.

    What a mess this has created. I hope the Supremes get it right and sort it out, at least a little. But as I type that I realize I have very little hope of that, so the best we can hope for in Bilski is a narrow decision with few words. Bilski patent claims not allowable. Reverse machine or transformation test. Any more than that would lead to all kinds of unintended consequences because the Supremes simply don’t understand patents or technology.


  10. Steve M March 31, 2010 9:03 pm

    Anyone know the cite on that “flash of genius” court case; ideally a link?

    Thank you.

  11. Gene Quinn April 1, 2010 10:20 am

    Steve M-

    Take a look at Cuno Engineering Corporation v. Automatic Devices Corporation, 314 US 84 (1941), which says:

    “We may concede that the functions performed by Mead’s combination were new and useful. But that does not necessarily make the device patentable. Under the statute, 35 U.S.C. § 31, 35 U.S.C.A. § 31, R.S. § 4886, the device must not only be ‘new and useful’, it must also be an ‘invention’ or ‘discovery’. Since Hotchkiss v. Greenwood, 11 How. 248, 267, 13 L.Ed. 683, decided in 1851, it has been recognized that if an improvement is to obtain the privileged position of a patent more ingenuity must be involved than the work of a mechanic skilled in the art. ‘Perfection of workmanship, however much it may increase the convenience, extend the use, or diminish expense, is not patentable.’ The principle of the Hotchkiss case applies to the adaptation or combination of old or well known devices for new uses. That is to say the new device, however useful it may be, must reveal the flash of creative genius not merely the skill of the calling. If it fails, it has not established its right to a private grant on the public domain.”

    Available at:


  12. Steve M April 1, 2010 6:36 pm

    Thanks Gene; really appreciate it.