Patent Drafting: Defining Computer Implemented Processes
|Written by Gene Quinn
President & Founder of IPWatchdog, Inc.
Patent Attorney, Reg. No. 44,294
Zies, Widerman & Malek
Blog | Twitter | Facebook | LinkedIn
Posted: March 14, 2011 @ 4:51 pm
The United States Patent and Trademark Office is radically updating the Patent Bar Examination starting in April 2011. Since I teach the PLI Patent Bar Review Course that has required John White and I to revise our materials. One of the new things tested will be the recently released 112 Guidelines, which are full of great information and explanation, particularly relating to computer implemented processes; what many would call software. Being the “software guy” one of my responsibilities has been to work on the 112 Guidelines and the Bilski Guidelines for the PLI course. So I thought I would take this opportunity to write, once again, about how to disclose computer implemented inventions to satisfy the disclosure requirements, which are embodied specifically in 35 U.S.C. § 112.
The statutory requirements for computer-implemented inventions are the same as for all inventions. That means that in order to be patentable the invention must meet the patent eligibility test in 35 U.S.C. § 101, the invention must be new (§ 102), it must be non-obvious (§ 103) and it must be adequately described (§ 112). Since the United States Supreme Court announced its decision in Bilski v. Kappos, the United States Patent and Trademark Office has continually urged patent examiners to get beyond the § 101 inquiry except in extreme cases. Prior to the Supreme Court’s Bilski decision many examiners would simply see a computer-implemented method and issue a blanket and rather non-specific rejection asserting that the invention was not patent eligible subject matter under § 101. The USPTO focus on getting past § 101 and to the meat of the invention means that such rejections are no longer the norm. It also means that the Patent Office is pushing the real question about whether an patentable invention is presented into the adequate description space pursuant to § 112. Thus, a thorough and complete description is absolutely essential when your invention relates to a computer-implemented method, whether it is software, an Internet processes or a business method.
There are three separate and distinct requirements under the adequate description requirement set forth in § 112, ¶ 1. These are the written description requirement, the enablement requirement and the best mode requirement. We will table discussion of the best mode requirement, which essentially says if you have a preference you need to disclose it. Patent reform efforts may soon eliminate that requirement from the U.S. patent laws anyway. On top of that, during prosecution of the patent application at the Patent and Trademark Office there is no way for an examiner to know if the best mode has been or has not been disclosed. Lack of a defined best mode is a litigation matter.
The first paragraph of § 112 contains a written description requirement that is separate and distinct from the enablement requirement. To satisfy the written description requirement, the specification, which is typically referred to as the non-claims portion of the patent application, must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Specifically, the specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention.
PTAB Past, Present, and Future
FREE WEBINAR: Join Gene Quinn and Scott McKeown as they discuss the reality and consequences of post grant administrative proceedings at the United States Patent and Trademark Office before the Patent Trial and Appeal Board (PTAB). CLICK HERE to REGISTER.
DATE/TIME: Tuesday, September 23, 11:00am to 12:00pm Eastern
The level of detail required to satisfy the written description requirement varies depending on the nature and scope of the claims and on the complexity and predictability of the relevant technology. Computer implemented inventions are often disclosed and claimed in terms of their functionality. This is because writing computer programming code for software to perform specific functions is normally within the skill of the art once those functions have been adequately disclosed. Nevertheless, for computer-implemented inventions, the determination of the sufficiency of disclosure requires inquiry into both the sufficiency of the disclosed hardware as well as the disclosed software due to the interrelationship and interdependence of computer hardware and software.
Because a thorough and complete disclosure requires specific information about the hardware as well as the software there is really no practical way to any longer file quick, easy, cheap patent applications directed to computer-implemented inventions. In fact, some patent attorneys and patent agents had taken to telling inventors that software and business methods were not patentable prior to the Supreme Court Bilski decision. That was, of course, inaccurate. The Federal Circuit announced what they called the machine-or-transformation test, which required the claimed process to (1) tied to a particular machine or apparatus (machine implemented); or (2) particularly transform a particular article to a different state or thing. It was never impossible to obtain patent claims on software or business methods even after the Federal Circuit created the machine-or-transformation test, but it did get a lot harder and requires familiarity not only with easy to write method claims, but also requires detailed and sophisticated understanding of the interrelationship and interdependence of hardware and software.
Many probably know that the Supreme Court overruled the Federal Circuit in Bilski v. Kappos, at least to some extent. The Bilski invention was still held to unpatentable as an abstract idea, but the Supreme Court explained that the machine-or-transformation test was not the only test to determine whether a process is patentable. Rather, the machine-or-transformation test was said to be an important clue to patent eligibility. Because after the Federal Circuit announcement of the test it was for a period believed to be the only test, patent applications written to satisfy the machine-or-transformation test quite clearly would satisfy the nebulous looser standard that results from the Supreme Court decision in Bilski v. Kappos. So the machine-or-transformation test still remains the hallmark for patentability of processes. Satisfy the machine-or-transformation test and you are good to go.
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.
Specifically, if one skilled in the art would know how to program the disclosed computer to perform the necessary steps described in the specification to achieve the claimed function and the inventor was in possession of that knowledge, the written description requirement would be satisfied. If the specification does not provide a disclosure of the computer and algorithm in sufficient detail to demonstrate to one of ordinary skill in the art that the inventor possessed the invention including how to program the disclosed computer to perform the claimed function, a rejection will be made under § 112, ¶ 1 for lack of a sufficient written description.
The enablement requirement is supposed to be a separate and distinct requirement found in § 112, ¶ 1, and that is, in fact, what the law says it is. However, the articulation of the written description requirement above, taken from the USPTO’s description in the recent 112 Guidance, seems to muddle the written description requirement and the enablement requirements into one. For example, demonstrating how to program the disclosed computer to perform the claimed function is far more of an enablement concern than a written description concern. I say this because to satisfy the enablement requirement the specification must teach those skilled in the art how to make and use the full scope of the claimed invention without “undue experimentation.” The make and use requirements embodied by the enablement requirement become redundant if pursuant to the written description requirement you need to describe how to program the computer.
Of course, the above discussion and parsing about what the written description requirement entails versus what the enablement requirement entails is largely unnecessary babble. I say that because at the end of the day you need to satisfy both requirements, so it really doesn’t matter if there is a bleeding of one into the other or the bright lines between the two are not so easy to define in the computer implemented invention context. The short of it is that you need to articulate the invention so that others know you have more than just an abstract idea and you need to articulate how a programmer would set out to create the code to bring about the desired functionality. This doesn’t mean that you need to know how to write the code, but it does mean that you need to take a systems approach to the project. Treating the software project like an engineering problem and setting out to create a design document that can and will be used by those writing the code is the goal. Essentially you want to answer as many questions that the programmer will have as possible, with the goal being to answer each and everything they could ever want to know so that the programming is a ministerial task akin to translating your design document (i.e., patent application) into code.
If you leave something out of your patent application it is not a part of your invention. For computer implemented inventions that which is left out is typically the meat and bones necessary to demonstrate that you are actually in possession of the invention separate and apart from a nebulous idea that you don’t really understand how to articulate. Although the specification need not teach what is well known in the art, meaning that you can rely on the knowledge of those skilled in the art for basic concepts and presume a certain level of understanding, you cannot rely on the reader to supply any critical information. Said another way, you cannot rely on the knowledge of one skilled in the art to supply information that is required to enable the novel aspect of the claimed invention. Therefore, particular care must be given to describing with as much detail as possible all those aspects of the computer implemented invention that contribute to it being unique and patentable. That is why a patent search is absolutely critical. Without a patent search you invariably describe everything with equal importance and that typically leads to not as much description of the novel and unique aspects as desirable.
For more information on computer implemented invention see: Software Patents.- - - - - - - - - -
For information on this and related topics please see these archives:
Posted in: Business Methods, Computers, Gene Quinn, IP News, IPWatchdog.com Articles, Patent Drafting, Patent Drafting Basics, Patents, Software, Software Patent Basics
About the Author
Gene Quinn is a Patent Attorney and the founder of the popular blog IPWatchdog.com, which has for three of the last four years (i.e., 2010, 2012 and 2103) been recognized as the top intellectual property blog by the American Bar Association. He is also a principal lecturer in the PLI Patent Bar Review Course. As an electrical engineer with a computer engineering focus his specialty is electronic and computer devices, Internet applications, software and business methods.