Since 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 Federal Circuit, per the iconic Judge Giles Sutherland Rich, pointed out that the business method exception had never been invoked by either the Federal Circuit or its predecessor court the CCPA. Furthermore, the case frequently cited for establishing the business method exception did not ultimately rely on that exception to deny patentability, meaning it was nothing more than dicta. The Court explained that “[s]ince the 1952 Patent Act, business methods have been, and should have been, subject to the same legal requirements for patentability as applied to any other process or method.”
The importance of State Street Bank is that business methods were considered patentable subject matter, and that 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 are 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; so everyone could be an inventor. Perhaps even more importantly was the fact that every patent attorney knew how to write claims and an associated patent application to cover a method or process. All many would do was define the steps, not touching on any aspect of the underlying or associated technology employed to carry out the business method. Unfortunately, the fact that many attorney and patent agents who were writing business method patents didn’t really understand computer technologies lead, at least for a time, there to be the perception that business methods and software could not be patented; this was in the months immediately following the Federal Circuit en banc decision in Bilski. See How to Patent Software in a Post Bilski Era.
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. See Patent Office Releases Interim Bilski Guidelines and Dissecting Bilski: The Meaning of the Supreme Patent Decision.
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.”
Starting with “useful,” the patent statute already has a utility requirement embedded therein. 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 misleading for Judge Rich to have included “useful” in the test. It allowed the test to literally confuse those who attempted to apply it because those knowledgeable knew that the use of the term “useful” in the test had to be referring to something other than utility, but what did it mean? Over and over again during the Federal Circuit en banc hearing Judge Michel asked what the test meant, repeatedly receiving no satisfying answer.
The Road Forward: Software Patents in the Post-Alice Market
Join Gene Quinn and Scott Alter for a discussion on patent eligibility, techniques for claiming software, prosecution strategies and more. Wednesday, March 4, 2015 at 12pm ET ~ CLICK HERE to REGISTER
Moving on to “result,” it is likewise unfortunate that this term found its way into the test because 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, thus having the term “result” modify “useful, concrete and tangible” lead to a test that largely was incoherent and 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. So 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 inquiry is 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 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.
Those familiar with patent law know, however, that focusing on whether there is an innovation described with sufficient detail so that it is “concrete and tangible” 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, first paragraph. 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. They have been instructed to only reject inventions for lacking patent eligible subject matter in extreme cases, allowing the inquiry to ripen to whether the entirety of the disclosure articulates an invention, which is the written description inquiry under 112. The USPTO in the Bilski guidelines even said that patent examiners should ordinarily handle such matters under 112, not under 101. Thus, while we cannot say that the State Street inquiry lives on, by any fair understanding of what the test was trying to do the analysis is really the same. 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 an invention, not merely an idea.
It is, therefore, 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. Unfortunately, most provisional patent application do not satisfy this requirement, particularly those filed by non-attorney corporations engaging in the unauthorized practice of law, and many of those filed directly by inventors who are not represented.
In typical business method patent applications today a computer implementation is frequently carried out over the Internet or some other communications network. In fact, a disembodied business method, meaning one that is not associated with any underlying technology, hardware or equipment, is likely not patent eligible subject matter. Of course, if you do have something that you think may be a disembodied business method you should still get an opinion from a patent attorney or patent agent who operates in this space. It is never good to assume you know the law, particularly the byzantine patent laws, without seeking competent legal advice. In any event, in order to adequately identify the business method invention that is linked to some kind of computer implementation the following should be followed:
- 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.
- 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.
- 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).
- In many cases specialized software will also 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.
- 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 at least some code is somewhat popular, particularly at the time of filing a provisional patent application. This is because the code you disclose provides an effective way to convey certain aspects relating to core functionality. 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.