PUBLISHED Feb. 2010, UPDATED November 1, 2011

In the United States software is patentable.  We typically refer to such inventions as computer implemented processes, but in the end it is software that is being protected.  Software can be protected in the U.S. if it is unique and tied to a machine.

The “unique” requirement is a short-hand way of saying it must be novel and non-obvious, which are core patentability requirements for any invention.  The requirement that the process be tied to a particular machine is not really much of a limitation if you really have a computerized process, but it is there to make sure that whatever protection you do ultimately obtain will not extend to so-called “pure business methods.”  In other words, you cannot patent a process done in your head, but if that process leverages a tangible machine, such as a computer, now you have something that is patent eligible and which will receive a patent if it is described properly and is unique.

When dealing with software patents the process we follow is rather straight forward; we view the innovation as a system that provides a desired set of functionalities.  We work with clients to consider the project with an engineering mind set, which requires understanding of the overall design, but also requires more detailed understanding. We first want to start out with the broad vision and then drill down to the specifics, which allows us to protect the broadest aspects of the invention as well as the specific features and implementations. This leads to the strongest, broadest software patent that can be obtained.

Which functionalities are unique and why? How does the rules engine implementing those core functionalities handle and manipulate information? Because human actors will interface with the system we can anticipate mistakes and errors, so what compensation is integrated to address this inevitable human element? What problems are solved by your solution and how is this more advantageous than any other known solutions? Uniqueness can and will reside in many places when dealing with software and computer process related inventions. We first work with you to uncover that which is unique and most likely patentable, and then we set about working to get it protected — patented — so you obtain a valuable business asset — a software patent that provides a meaningful foundation to build on.

I always recommend that inventors seeking software patents start with a patent search. Typically there is always something that can be patented, it is just a matter of finding out what is unique and how to describe it to accentuate the uniqueness of the invention. Ultimately, the question is usually whether the patent claims that can be obtained will be broad enough to warrant the time, money and expense associated with obtaining a patent.

When I do a patent search for computer related technologies and software inventions are comprehensive and employ a multi-phase search. This allows us to learn more about the invention little by little in context of the prior art we locate. We work together with the inventors in a cooperative approach. By the time the search process has concluded the inventor will have a 5-7 page single spaced detailed assessment, a complete patent search report detailing everything that was located and we will thoroughly understand the invention and likelihood of obtaining protection. This approach allows for a much more detailed patent application. For more information about our patent search process please see Patent Search FAQs.

We work to envision the system from three distinct views, all of which are described in the software patent application. Specifically we approach the software patent application: (1) from the view of the end user; (2) from a systems/architecture view; and (3) from the viewpoint of the computer.  To get a sense for this, and why it is important, I strongly recommend reading these few articles:

• The Information Needed to Avoid Writing Bad Software Patents
• Software Patents and Murphy’s Law: Uncertainty is Where Patentability Resides
• Defining Computer Related Inventions
• Writing Software Patent Applications

I always recommend my new clients read at least these articles to get an idea about the project, what information I will need and how we approach the overall task.  The more you understand about why we need what we ask for the better the results.  It will make you a better inventor because you will be more in tune with what information is required and it will help you to identify a great many things that are likely capable of being protected that you never considered as patentable.

If you need assistance with a software patent, Internet technology or computer device send me an e-mail.  My firm and I have quite a bit of experience with software patents and related technologies, and I even have my own software patent application pending on a computer implemented process, so my interest in this area is both as a legal representative and an inventor.

From the IPWatchdog.com Blog

• A Patent for Software — October 31, 2011 — What If you created an automobile engine that could deliver 500 miles per gallon of gasoline would you seek a patent? I suspect you would because that type of engine would almost certainly be revolutionary. So why wouldn’t you think about patenting a software system that more efficiently manages power consumption for a large office building? If you could reduce energy consumption by 25% wouldn’t that be noteworthy? Of course, and it should be patentable as well. Legally it doesn’t matter whether the advantage is created by an old world mechanical gadget or thanks to the constant monitoring and manipulation of parameters via a computer following instructions. Both are innovations and both are patentable, and rightly so.
• Patenting Business Methods and Software in the U.S. — July 18, 2011 — Any method claim that does not require machine implementation or does not cause a transformation will fail the test and will be rejected under § 101. The importance of this from a practical standpoint is that business methods not tied to a machine are going to be rejected under § 101 and the rejection will be difficult, if not impossible, to overcome.
• Patent Drafting: Defining Computer Implemented Processes — March 14, 2011 — So what information is required in order to demonstrate that there really is an invention that deserves to receive a patent? When examining computer implemented inventions the patent examiner will determine whether the specification discloses the computer and the algorithm (e.g., the necessary steps and/or flowcharts) that perform the claimed function in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor invented the claimed subject matter. An algorithm is defined by the Patent Offices as a finite sequence of steps for solving a logical or mathematical problem or performing a task. The patent application may express the algorithm in any understandable terms including as a mathematical formula, in prose, in a flow chart, or in any other manner that provides sufficient structure. In my experience, flow charts that are described in text are the holy grail for these types of applications. In fact, I just prepared a provisional patent application for an inventor and we kept trading flow charts until we had everything we needed. Iterative flow charting creates a lot of detail and the results provide a tremendous disclosure.
• Business Methods: Concrete & Tangible Description a Must — November 4, 2010 — In order to have a patentable business method it is necessary for the invention to accomplish some practical application. In other words, in order for a business method to be patentable it must produce a “useful, concrete and tangible result.” Although the United States Supreme Court did away with that test when it issued its decision in Bilski v. Kappos, it is still nevertheless illustrative and the best test that is out there. If you really understand what Judge Rich meant by “useful, concrete and tangible result” you come to the inescapable conclusion that it is the appropriate test and if you really target the description of the invention to satisfy the test you will have something that is patentable under the Supreme Court Bilski v. Kappos test and the USPTO guidelines that have followed.
• Beware Open Source Strings Attached if You Want a Patent — October 12, 2010 — Just this week I had the opportunity to consult with a client that is in the process of creating unique software that is, at least in my opinion, patentable over the prior art. We were chatting over the telephone when he explained that the developer he hired was using certain open source code to supplement the original code being written. Not wanting to scare my client needlessly, but suspecting the worst, I asked him to send me information on what was being taken, in particular the license agreements that govern the allegedly free open source software. In life there are few certainties. Death and taxes are among them; as is the fact that if you are taking open source software for your proprietary project you are likely about to do a deal with the devil that might be extremely difficult, or even impossible, to undo.
• The Information Needed to Avoid Writing Bad Software Patents — September 9, 2010 — Software is now and will remain patentable in the United States. Software patents have been vilified by many, but they have been granted by the United States Patent and Trademark Office and upheld in federal courts across the United States. The much anticipated Bilski v. Kappos decision at the Supreme Court did nothing to slow down the patentability of software, and in fact even the original Federal Circuit decision wound up, as applied by the USPTO, to make it more likely that adequately written software patent applications would be granted and transformed into issued patents. What has changed over the last several years, however, is the amount of detail that must go into a software patent application in order to satisfy the adequate description requirements under US patent law. So don’t listen to anyone who tells you software cannot be patents in the United States; it certainly can, but it isn’t quite as easy as it used to be.
• Patenting Software: The Business Responsible Thing to Do — August 9, 2010 — Whether the “open source means free” community ever chooses to acknowledge it, the truth is that a patent is a business tool; an asset. If you are serious about being in business in the software space you absolutely must have patents. Yet, there are those in the “open source means free” community, which simply a naive anti-patent sector, would have those throughout the open source community incorrectly think patents are evil. They complain that patents shouldn’t be protected by patents and copyrights are enough. They claim it is too hard to figure out if you are infringing. What they are really saying is that they choose not to operate their business affairs in a business appropriate fashion and in order for them to succeed while ignoring best practices and being responsible like every other business and industry they need patents on software to cease. This chicken little approach proves only that they are not business savvy, and that they aren’t paying attention to developments in the industry.
• Who Owns Software Copyrights? — June 29, 2010 — Companies enter into software development deals with independent contractors without adequately addressing copyright ownership. Many times, it is assumed by the programmer that the copyright, including the right to modify and prepare derivative works, remains with her or him. From the company side it is generally assumed that when someone is paid to create copyrighted material that flows from the original creation those copyrights will be owned by the commissioning party. Neither assumption is true, which means that when a dispute arises, litigation ensues and unnecessary expenses mount.
• Dissecting Bilski: The Meaning of the Supreme Patent Decision — June 29, 2010 — Who knows what goes through the minds of anyone, let alone a cloistered Justice of the United States Supreme Court. What we do know, however, is that 5 Justices, namely Justices Kennedy, Roberts, Thomas, Alito and Scalia all agreed that business methods are patentable subject matter. All 9 Justices agreed that the Federal Circuit misread previous Supreme Court decisions when they mandated that the machine or transformation test be the only test for determining whether a process is patentable subject matter. All 9 Justices agreed that the Bilski application was properly rejected, with the majority agreeing that it was properly rejected because it was an abstract idea, and the concurring minority simply wanting to say that business methods are not patent eligible unless tied to an otherwise patentable invention (see Stevens footnote 40).
• Supremes Decide Bilski: Machine or Transformation Not the Only Test, Bilski Not Patentable — June 28, 2010 — The Supreme Court held that the machine-or-transformation test is not the sole test for patent eligibility under §101, and that the Federal Circuit erred when it ruled that it was the singular test to determine whether an invention is patentable subject matter. Delivering the opinion for the Court was Justice Kennedy. There were no dissents, only concurring opinions, which is in and of itself a little surprising. In any event, Kennedy explained that the Federal Circuit decision ignored well established rules of statutory interpretation, and further explained that there is no ordinary, contemporary common meaning of the word “process” that would require it to be tied to a machine or the transformation of an article. Nevertheless, the machine or transformation test may be useful as an investigative tool, but it cannot be the sole test.
• Software Patents and Murphy’s Law: Uncertainty is Where Patentability Resides — March 29, 2010 — When embarking on a software development project it is critical to understand that in order to maximize the chance of obtaining a patent 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.
• Beware Those Claiming Software Patents Are Unnecessary — January 13, 2010 — If patents are good for Microsoft and the tech giants, patents are right for Red Hat and the open source community and patents are demanded by investors, as Dean Kamen explains, when small businesses seek funds, why would they be bad for independent inventors and small businesses? When you start out in business you don’t model yourself after those who fail, but rather after those who succeed, and the one thing successful businesses with proprietary and open source business models agree on is that patents are important enough to obtain. Simply stated, those who refuse to acknowledge the power and protection afforded by patents ignore reality and must be assumed to have an agenda.
• Open Source Success Must Embrace Proprietary Features — October 20, 2009 — Sure, a computer programmer with time on their hands can write code and freely give it away, but that is not a business model or innovation strategy that will lead to widespread acceptance or use. In order for open source companies to grow they need to rely on investors who fund development, and investors are only going to be interested in funding development if there is a proprietary strategy in place. It is as simple as that.
• Why All Small Businesses Need Software Patents — October 4, 2009 — The reason giant companies hate patent trolls is because they are not capable of being counter-sued. There is no deterrent effect because patent trolls do not make, use or sell anything, they just sue. So giant companies are targets in the same way that smaller companies without patents are targets of big companies with patents. No one should aspire to be a target. A simple truth is that a small business without patents might as well dress themselves up as a buck during hunting season complete with a bulls-eye pre-drawn. So here is the case for every business to get patents, particularly software patents. Ignore it if you like, but you do so at your own peril.
• How to Patent Software in a Post Bilski Era — June 29, 2009 — While it is true that the Federal Circuit has largely made “software” unpatentable, they did not prevent the patenting of a computer that accomplishes a certain defined task. Given that a computer is for all intents and purposes completely useless without software, you can still protect software in an indirect manner by protecting the computer itself, and by protecting a computer implemented process.
• Defining Computer Related Inventions — September 16, 2008 — The code itself and how it is written is protected via copyright, if at all, not through a patent. So when you are trying to define the invention so that it can be described adequately in a patent application you do not need to detail every language that could be used, and you do not need to provide an outline of the routines or subroutines, but what you do need to provide is enough information so that the computer programmer could translate your description into code, so you want to provide enough to allow the computer programmer to create the outline themselves, understanding that the actual approach employed by the computer programmer will be as unique as they are.
• Writing Software Patent Applications — August 31, 2008 — 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.