In the CLS Bank v. Alice Corp upcoming Supreme Court case, Alice poses the question… “Whether claims to computer-implemented inventions – including claims to systems and machines, processes, and items of manufacture – are directed to patent-eligible subject matter…”
That’s absolutely the wrong way to phrase a question about inventions. Equally wrong is the same boiled down twin sister question “Is software patentable” which has now been debated around the world for almost 50 years.
As the recipient of the first software patent in 1968 and a founder of Applied Data Research (ADR), the first company to market software products, I have intensely followed and written about the software patent controversy for almost 50 years.
Here’s why the Alice question should not be answered by the Supreme Court in its present form.
EDITORIAL NOTE: What follows are the prepared remarks of David Kappos, Under Secretary of of Commerce for Intellectual Property and Director of the United States Patent and Trademark Office, delivered at the Center for American Progress in Washington, DC, on November 20, 2012. This is reprinted here with permission.
Thank you, Winnie, for that kind introduction. Good morning, everyone. It’s great to be here at the Center for American Progress. I’m pleased to be able to talk about intellectual property and the role that intellectual property rights play in enabling innovative goods and services to come to market. And specifically, I’m going to focus my remarks on software patents and the so-called smartphone “patent wars,” which have become front page news in the last year or so.
It is increasingly clear that intellectual property, or IP, is a key driver of economic growth, exports, and job creation. IP rights are the global currency for creating value for products and services, for all innovators, in all markets. And the protection provided by patents is critical to the innovation ecosystem. In fact, last spring, the U.S. Commerce Department released a report that found IP-intensive industries support at least 40 million jobs and contributes more than $5 trillion to our economy, accounting for 35 percent of America’s gross domestic product. So it is in this context that we are seeing multi-billion dollar acquisitions of patent portfolios and a number of high profile patent lawsuits, involving some of the most innovative companies on the planet, who are producing some of the most popular technologies ever created.
Means-plus-function claiming has been disfavored (by and large) since at least 1994 when the Federal Circuit handed down its decision in In re Donaldson, where the Federal Circuit sitting en banc explained:
If one employs means plus function language in a claim, one must set forth in the specification an adequate disclosure showing what is meant by that language. If an applicant fails to set forth an adequate disclosure, the applicant has in effect failed to particularly point out and distinctly claim the invention as required by the second paragraph of section 112.
In other words, if it is not in the specification then the fact that it may be a “means” to accomplish the function does not save you. Means that accomplish the recited function that are not within the specification of a patent application are not captured by the claims.
Means-plus-function claiming is not very popular in many technical disciplines because of how narrowly limited the claims are to what is specifically disclosed. Over the years, however, mean-plus-function claiming has continued with various levels of popularity for those who deal with computer-implemented methods (i.e., software). After all, software is just a series of steps directing a machine (typically a computer) to perform certain processes to accomplish a result. Thus, “means for” doing something remained a rather descriptive way, at least generally speaking.
Despite the protestations of some, software is patentable in in the United States. There are some jurisdictions that do not allow for the patenting of software or computer implemented processes, but the law in the United States allows for software to be patented.
Given the software patents are my business, one of the questions I typically receive from an inventor is: What software can be patented? How does one know that what they have is something that can be protected? The short answer is this: In my experience those who come to me before they start coding always have something that can be patented. Of course we have to do a search and seek out the available space, but there are some many twists and turns that there is almost always something patentable. Unfortunately, some do the programming first and never approach the design as an engineering problem for which they have a unique solution. That means no attempt has been made to identify the unique characteristics so what is programmed is many times virtually identical to the prior art. It doesn’t have to be that way though.
The conundrum created by the Federal Circuit’s joint infringement doctrine and its impact on protecting interactive computer-based technologies got worse last week with McKesson Technologies, Inc. v. Epic Systems Corp.McKesson Technologies involved a patented interactive electronic method for communicating between healthcare providers and patients about personalized web pages for doctors. Judge Linn’s majority opinion (and a “thin” at majority at that) ruled that, because the initial step of the patented method was performed by the patient while the remaining steps were performed by the software provided by the healthcare provider, there was no infringement, direct, indirect, joint or otherwise of the patented method.
The problem with software patents isn’t that they are granted on obvious innovations, but rather that those who spend so much time complaining about them are just about completely clueless, at least with respect to patent law. It borders on the comical to observe some of the apoplectic rants against software patents, which almost universally conclusively prove that the person writing (or ranting) has not read past the title of the software patent in question. That is, of course, assuming they have even looked at the patent and are not merely mimicking what they have read from some other equally clueless and irresponsible critic.
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.
What do you think of my jumping buddy over there? Pretty cool, huh? Let’s call him “George”.
George is just one example of the enormous number of inventions being made to serve our newly emerging social networking economy. George was created using a patent pending process called Evolver. He’s an avatar that can be transported to any number of different full immersion virtual world networking sites. Many new companies are forming to commercialize these new social networking innovations. They are also filing patent applications. They have many challenges ahead of them to get those patents.
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.
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.