Patenting business methods and software still requires concrete and tangible descriptions

programing-softwareSince at least 1998 business methods have been patentable in the United States. This is thanks to the decision of the United States Court of Appeals in State Street Bank & Trust Co. v. Signature Financial Group, Inc., which categorically and unceremoniously did away with what had previously been come to be known as the business method exception to patentability. Essentially, the business method exception said that no method of doing business deserved patent protection. The rule excluding business methods was as absolute as it was ridiculous, because after all aren’t all patent methods used for some business purpose?

That business methods became patentable subject matter led to an ever increasing number of business method applications being filed at the United States Patent Office. The volume of business method patents became staggering, in part a function of the fact that business methods were only patentable in the United States and in part because practically everyone can come up with a process that in some way facilitates the doing of business; everyone could be an inventor.

Gone are the days of the business method wild west. Truthfully, it hasn’t been easy to get a business method patent since at least 2002. The laws have changed numerous times since then, most directly with the Supreme Court deciding Bilski v. Kappos, which specifically addressed the issue of whether business methods are patentable.

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, it is still the best test that is out there if you are really trying to understand what it is that you must have in order to have a chance of obtaining a patent.

If you really try and understand what Judge Rich meant by “useful, concrete and tangible result” you come to the inescapable conclusion that it is the appropriate test. The purpose of the “useful, concrete and tangible result” requirement was to limit patent protection to inventions that possess a certain level of “real world” value, as opposed to subject matter that represents nothing more than an idea or concept (which is not patentable), or is simply a staring point for future investigation or research. The unfortunate aspect of the test was that is used two terms that really have no place in the patentable subject matter equation; these are “useful” and “result.”

[[Advertisement]]

The patent statute already has a utility requirement embedded in 35 U.S.C. § 101. Inventions are only patentable if they are useful, which has always been considered to be a separate and distinct requirement when compared with the patent eligible subject matter requirement. Thus, it was truly unnecessary, unfortunate and even misleading for Judge Rich to have included “useful” in the test. It allowed the test to literally confuse those who literally attempted to apply it because the term “useful” in the test had to be referring to something other than utility, but what did it mean?

It is likewise unfortunate that this term “result” found its way into the test. If the focus is on the result in any way, shape or form then the process becomes nothing more than a meaningless black box. With business method inventions, however, the process is everything. Today the process along with how technology is used to facilitate the process is everything. Having the term “result” modify “useful, concrete and tangible” lead to a test that was largely incoherent and which simply could not be applied with any meaningful consistency. If you were predisposed to believing the invention was patentable it was patentable, and if you were predisposed to believing no patent should be awarded you could find that as well. This meant that the State Street test ultimately wound up no better over time than did the tests it sought to replace.

If you stand back and try and figure out what one is trying to determine with respect to whether a business method is patentable the core of the State Street inquiry is very relevant. Judge Rich was attempting to articulate a test that would allow the decision maker to determine whether there is in fact an innovation; an invention that we recognize as one that can and should be patented if it is in fact novel and nonobvious. So the key to the “useful, concrete and tangible result” test of State Street is the “concrete and tangible” part of the test. That part of the test must be referring to whether an invention has been articulated sufficiently so that if it is novel and nonobvious a patent could be appropriately awarded. This explanation of the State Street test would be in accord with both the Supreme Court’s decision in Bilski, as well as the more recent decision in Alice v. CLS Bank, as well as the Federal Circuit’s decision in DDR Holdings, LLC v. Hotels.com, L.P.(commentary here).

The key to obtaining a software patent is to thoroughly describe the system and processes from a technological level. As to Judge Chen explained in DDR Holdings, in order for software patent claims to be patent eligible they must not “merely recite the performance of some business practice known from the pre-Internet world along with the requirement to perform it on the Internet.” To be patent eligible claims to software must be  “rooted in computer technology in order to overcome a problem specifically arising in the realm of computer networks.” Of course, this patent eligible example of software patent claims is extremely relevant for business methods because a naked business method is no longer patent eligible. To have a realistic chance of being patented business methods must be tied to a particular compute technology in a meaningful and substantial way. Said another way, the business method really needs to be performed by and through a concrete and tangible system, where the system and processes are painstakingly described.

Those familiar with patent law will realize that focusing on whether there is an innovation described with sufficient technical detail weaves together in at least some meaningful way the considerations of patent eligible subject matter under 35 U.S.C. 101 and the written description requirement under 35 U.S.C. 112(a). While I am not typically a fan of merging considerations under the patent statute, and have been highly critical of the many judges, particularly Supreme Court Justices that unknowingly weave together the very different considerations presented by the novelty inquiry (35 U.S.C. 102) and obviousness (35 U.S.C. 103), there is no such concern with leveraging patentable subject matter alongside of written description. First, they are not different considerations by any fair assessment, which is contrary to the fingers on the chalkboard mingling of novelty and obviousness, which are fundamentally different. Second, there is already precedent to leverage 101 off 112 with respect to utility; specifically that which is not useful under 101 cannot be enabled under 112.

Whether you want to weave the patent eligible subject matter determination together with the written description determination is really of no consequence. You have to because that is what the Patent Office has told examiners to do. It is also what the Supreme Court seems to be mandating although they don’t seem to understand patent law enough to understand that is what they have said.

[[Advertisement]]

While we cannot say that the State Street inquiry lives on, by any fair understanding of the current law you absolutely must have the business method defined in a concrete and tangible manner so that your written description satisfactorily conveys what you have is a real invention, not merely an idea.

With this in mind it is critically important that the description of the business method be as complete as possible at the time of the filing of your first patent application, which means that the description must clearly identify the invention as of day one, even if you file a provisional patent application. This is true because in order to provide priority a provisional patent application must completely articulate the invention with enough detail to satisfy 35 U.S.C. 112.

In typical business method patent applications today a computer implementation is frequently carried out over the Internet or some other communications network. Having said that, merely saying that a particular process could be carried out over the Internet is not going to be enough. You really must be able to provide the technical details. If you have a disembodied business method, meaning one that is not associated with any underlying technology, hardware or equipment, it is not patent eligible subject matter.

In order to adequately identify a business method invention that is linked to some kind of computer implementation the following should be followed:

  1. The business method must be described in a way that clearly identifies the real world value of the business method. In order to fulfill this requirement it will be necessary to provide a generalized description of the overall business method in a way that explains what the business method accomplishes and how it accomplishes the task. In order to do this most patent attorneys suggest the use of one or more flow charts the depict the steps associated with the overall business method. In most, if not all, business method inventions it will be possible to describe the process from multiple viewpoints. For example, how the overall system operates viewed from the user perspective is different from the perspective of the central computer, which performs the various computations, comparisons and routes information. It is, therefore, critical to clearly identify the business method from all possible viewpoints.
  2. In addition to providing a generalized overview of the business method, it is also necessary to clearly identify what the central computer (or other central controller) does when it performs the processes required by the business method. This will normally require a detailed description of the functionality of the central computer. This description should be as complete with as much technical information as possible, including discussion of how the central computer is to be configured to provide the required functionality.
  3. It is also necessary to provide an overview of the system used to implement the business method. This will require description of the relationship of the central computer (or other central controller) to other subject matter outside the computer (or controller), which together represent the system for carrying out the business method. In other words, it is necessary to explain how the central computer (or controller) is to be integrated with other elements that are a part of the invention, and to further explain how these other elements work to facilitate the business method. These other elements can include, but are not limited to telecommunications equipment, the Internet, remote computers or terminals and peripheral devices connected to the central computer (or controller).
  4. Specialized software will almost always constitute a part of the best way to carry out the invention. In this situation it is necessary to provide a description of the best way to carry out the invention using software by disclosure of the functions of the software. While the Patent Office position is that flow charts are not a requirement for adequately disclosing the functions of the software, most patent attorneys would strongly recommend or even require their clients to include flow charts. I am one of those patent attorneys. This is because those skilled in the art will be computer programmers and computer engineers, who are (or should be) taught from the earliest levels of their technical education to conceptualize software first in a flow chart.  Therefore, the provision of a flow chart is fundamental to conveying the function of software. If done properly your flow charts will also satisfactorily disclose the algorithms, which is becoming increasing essential. See The Algorithm Cases.
  5. Disclosure of the software code is not necessary where the functions of the software program are readily apparent from the specification and one skilled in the art could generate the necessary software code to implement the disclosed functions. Nevertheless, the disclosure of some code may be a good idea, particularly at the time of filing a provisional patent application.  This is because the code you disclose provides an effective way to convey aspects relating to core functionality of what has been coded. This is true because patent applications need to speak to those skilled in the art, who in this case would be computer programmers and computer engineers. When a computer programmer reads code it will convey with pinpoint accuracy both the requirements and any number of alternatives that could be employed to achieve the same functionality.

All of the above are things that a computer engineer would take into consideration, and what you should as well.  You need to visualize the solution to the problem your invention solves as an engineering problem; one that takes into consideration engineering principles and Murphy’s law.  See Software Patents and Murphy’s Law: Uncertainty is Where Patentability Resides.  After all when human actors get involved with computer software or carrying out any type of business process whatever can go wrong will go wrong.

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

No comments yet.