decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.

To read comments to this article, go here
Curing the Problem of Software Patents, by Michael Risch
Sunday, June 10 2012 @ 06:44 PM EDT

Introduction, by PJ

I have a real treat for you, and also a serious assignment, if you are up for it. Professor Michael Risch has been good enough to write an article for us at Groklaw on the subject of software patents. He thinks he has some ideas on how the problems they pose could be ameliorated even without changing the law.

Will you please treat him as my personal guest? He is a member of Groklaw, actually, as mrisch, so in that sense you are colleagues. He and I have been in quite a discussion about this topic, ever since I wrote the article about the Prometheus case, where the US Supreme Court referenced two of his articles, Everything's Patentable, which they disagreed with, and Life After Bilski, which was relied on heavily by the court. Over time, I realized I really like him as a person, even though we don't agree on this topic altogether, and one day as we were emailing, I thought to myself, why am I not sharing this with all of you? You know more than I do about software patents, and it's a real opportunity for you to explain your point of view to him and vice versa. If patent law includes a specific reference to those skilled in the art, in the category of software patents that would be you. Surely your voices should matter. In my dreams, he ends up influenced to some degree by Groklaw, and then goes on to influence the US Supreme Court in a way we might actually like. If not, I still like *him*, even if we never agree. He plans to present the ideas in this article as a solution to the problem of software patents at a conference this fall, so he is very interested to hear from you. And he does know how to program, so you can speak freely and specifically, and he'll understand you. So with that introduction, I give you Professor Risch and let the conversation begin.


Curing the Problem of Software Patents
~ by Michael Risch1

I would like to thank the Groklaw community for having me, and in advance for your comments. I’ve read posts here on and off over the years, and the recent discussion about Prometheus and Oracle v. Google piqued my interest. Before I get into the meat of things, note that I have a lot of experience in software, as I discuss below. So, if you disagree with me (as I suspect many of you will), please don’t assume that it is because I don’t understand software – I do.

Many people who have read my work probably assume that I am pro-software patents. I’m not really; I am just not anti-software patent. I’m agnostic.  I think that there are a lot of bad software patents out there, and we should get rid of those. However, I don’t think that the solution is to get rid of all software patents. I think that such patents can be inventive and productive like any other, and I also think that defining when a patent becomes software (as opposed to hardware) is too difficult an inquiry.

Abstractness and Software

I’ve read a few postings here about how all software is really just mathematics and thus abstract (I’m paraphrasing, of course). And indeed, I’ve written in an article: “In software patents, hardware is almost never the inventive aspect.”  But note this comment I got at PatentlyO from an engineer/patent lawyer in response to the above statement: “ALL software is a specification of hardware. ALL software is run very differently on different hardware and is written for specific hardware platforms. Software is hardware in every sense that matters for patents.”

Here was my response: “Of course you are right that software has to be written and compiled for specific hardware. Indeed, the real ingenuity of most software patents is that they attempt to do something that is really difficult given the available hardware at the time of the invention. But so what? No patent is written at that level of abstraction. If they were, then the Court [in Bilski v. Kappos] would likely not have worried so much. The issue is that patents aren't for specific implementation of specific solutions on specific hardware. It's that patents claim general steps to solve general problems (or sometimes specific ones) on general hardware.”

So, you can see that I’m in sort of a middle-ground that makes no-one happy. Anti-software patent folks think that I give too much credit to the non-abstract aspects of software. Pro-software patent folks think that I too easily see software as abstract. As we like to say at home when the kids have to compromise: if no one is happy, then I must be doing the right thing.

An Example

I thought I would give an example of a patent I find potentially meritorious. Note, of course, that the patent still has to hold up to a novelty analysis, etc., but Patent 7,098,896 [claims] for continuous stroke input on a keyboard is the type of software patent that the system should protect if it is otherwise valid.

This patent, owned by Swype, was filed in January of 2003. It claims at its most basic the idea of moving the finger from letter to letter on a qwerty keyboard. The motion of the finger is then captured (the shape of the line), and matched against a dictionary of shapes for different words. The system also compares for close shapes and suggests words that might have been intended but the finger didn’t quite get to the correct keys.

Is this math? Absolutely – it encodes data about the touch and does a mathematical comparison. But it is so much more; it provides an interface from my finger to the touch keyboard to the words on the screen in an incredibly efficient and useful way. I connect with this patent in part because it is the only way I’ll type on a touch keyboard – the other methods just don’t work with my big fingers, and I stubbornly held onto a Blackberry for a long time believing that I could never effectively type on a touch keyboard. It may be math, but it is math applied to a very specific hardware problem – small touch keyboards.

So, does this impede innovation? I don’t think so – continuous stroke typing was a twinkle in the eye of researchers at the time this was invented. The patent cites the leading work at the time, and that work was not nearly as easy or useful as this product. The idea, once disclosed, was easily copied by competitors, and the only way to ensure early development of it was to protect it with a patent. I suspect the patent helped the company get venture funding, and thus survive long enough to complete development. Furthermore, there are ways to work around the patent to allow for continuous stroke typing – this is only one specific way. Of course, it would be better if they invented this, disclosed it to the world, and then never enforced the patent, but that’s not how the world of incentives works.

Now, you may not agree with me that this is a worthwhile patent, but I believe that it fulfills the basic role we would expect of all patents. If you think that patents in general don’t do that, it’s unlikely that I will convince you otherwise.

Patentable Subject Matter

Now onto the legal perspective; let’s start at the beginning. First, software can be patentable subject matter. Why? The real question is: why not? It is either part of a machine that does something useful, or it is part of a process for a machine to do something useful. While information processing is certainly more complex (and abstract? I’m not convinced) than primitive programmable machines like the Jacquard loom, at bottom there is no principled reason to differentiate as a matter of subject matter. Even if patenting of methods was unclear in the distant past, Congress made clear that machines, new uses of machines, and processes are all patentable.

Of course, one might except “abstract ideas” from patentability, but as I argue in my article Everything is Patentable, figuring out what is abstract or not is nearly impossible, especially in light of the fact that “insignificant postsolution activity” is to be ignored. In my co-written article Life After Bilski, we tried to come up with a way to define an abstract idea, but I still think it is pretty difficult to apply consistently.

Solving the Problem of Software Patents

Does all this mean that I don’t think software patents are a problem? Of course not. Many (most?) software patents are terrible. Indeed, I spend a lot of time finding prior art to invalidate software patents, and more often than not I find something that is pretty close, if not identical to the patent claims. There are many other problems with software patents. I just don’t think that subject matter is the way to deal with them. Instead, I think the better course is the one I propose in Everything is Patentable (and Forward to the Past): more rigorous application of the traditional patentability criteria.  I believe most of these techniques are already available or in reach of current rules.

Some of these solutions are best applied by patent examiners at the time the patent is being sought, but the reality is that we will never have enough money to fully test every patent application. For that reason, I’m a firm believer that for many disputes it is more efficient for the parties that have a stake in the matter to fight about validity at the time of litigation. This increases costs on patent defendants, but if examiners will not get the job done anyway, I would rather they not spend a lot of time trying.

I’ll explain what I mean by more rigorous application.

Utility: To be patentable, a claim must be practically useful – it must provide a specific and substantial benefit to the public. In my articles Everything is Patentable and A Surprisingly Useful Requirement, I argue that this requirement means that the claim must “do something.” As a result, patents that are too abstract likely lack practical utility. They don’t do anything. I argue that Bilski’s first claim for hedging fits this description in Bilski v. Kappos: sell a commodity to one group at one price and to another group at another price. There is no limitation for type of commodity, how to calculate pricing, which groups of sellers, or even who is supposed to benefit. By being so broad as to be everything to everyone, Bilski’s claim really covers nothing specific. This application of practical utility to overly broad, abstract patents is already within the bounds of the law, I believe, even if it is not being applied that way very often.

I realize the Supreme Court has said that algorithms are unpatentable. My view is that this is an untenable solution, because every process patent is an algorithm, mathematical or not. And it can't be that every process is unpatentable. I don't think the dividing line can be software, because so many solutions use electrical signals as part of the product or process. It is easy to rail against software, but it is far more difficult to determine what is and is not software. So I look for a different dividing line. Here is a lengthy quote from the article I wrote, A Surprisingly Useful Requirement, that discusses this issue:

Practical use analysis can help answer whether a seemingly intangible process is patentable or not. Bilski is merely the latest in a line of cases considering this question. For example, in Gottschalk v. Benson, the Court disallowed a computerized method whose purpose was to simply convert numbers from one format to another. Interpreting Gottschalk on subject matter grounds has caused much confusion, but the opinion can be better explained by usefulness. The method at issue did not do anything – it was an isolated series of calculations without any inputs or outputs applied to a real world problem.

Thus, it had no practical use because the process standing alone did not provide a specific and substantial benefit to the public. It surely could have been incorporated into a number of practically useful applications, but where a calculation can be used everywhere, including simply for calculation’s purposes, it lacks practical usefulness.

Similarly, a process to calculate the result of Einstein’s famous e=mc2 lacks practical use, while a nuclear reactor using the same process might have practical use. Thus, if such processes were applied to solve some practical problem, they might be useful. In general, a series of steps that achieves no end is not practically useful, and is therefore unpatentable. . . .

[P]rincipled consideration of a claim’s usefulness is preferable to an ill-defined “abstract idea” test because ... the tens of thousands of intangible method claims that need to be tested by the PTO and courts [might or might not be abstract] and an undefined test has no way to determine which ones are abstract or why.

Novelty: The heyday of software patents involves filing dates before 1998 or so. It is much more difficult to find prior art before that time. Further, there were also PTO limits on using search engines. Current software patents do not have the benefit of limited search resources. As a result, it will be much easier to find prior art for software patents in the future. Furthermore, companies such as Article One Partners provide crowdsourced prior art  searching that has aided finding prior art.

Obviousness: My experience with computer scientists is that they believe everything is an obvious improvement over the past. I’ve read enough engineering journal articles to know that this is not true, but many software patents are obvious.

The Supreme Court case of Dann v. Johnston is significantly underutilized. That case held that it is obvious to implement in software something that was already well known in noncomputerized circles : “[Patentee’s] ‘category code’ scheme… is, we think, closely analogous to a bank's offering its customers multiple accounts from which to choose for making a deposit or writing a check.”. (A little known fact is that the Supreme Court also agreed to hear a subject matter challenge, but ruled only on obviousness). This means that many software patents, such as “slide to unlock” are obvious.

However, a fundamental problem with obviousness is the growth of the Federal Circuit’s rigid “teaching, suggestion, and motivation” test during the 1990’s: “Seeking to resolve the question of obviousness with more uniformity and consistency, the Court of Appeals for the Federal Circuit has employed an approach referred to by the parties as the ‘teaching, suggestion, or motivation’ test (TSM test), under which a patent claim is only proved obvious if ‘some motivation or suggestion to combine the prior art teachings’ can be found in the prior art, the nature of the problem, or the knowledge of a person having ordinary skill in the art.” (See KSR v. Teleflex).

This rigid test made it much harder to find software obvious, because it barred examiners from using common sense, instead requiring that every difference between existing technology and the patent be suggested in writing somewhere. This rigid test helped create a large volume of software patents. The test also meant that finding a software patent obvious required courts to imagine software engineers as superskilled experts so that they would know to combine specific references. As noted below, this superskill hurts the enablement analysis.

Obvious is not so hard today. Today, the Supreme Court’s 2007 decision in the KSR v. Teleflex case has made it easier to use common sense to find patents obvious: “When a work is available in one field of endeavor, design incentives and other market forces can prompt variations of it, either in the same field or a different one. If a person of ordinary skill can implement a predictable variation, § 103 likely bars its patentability.”

This also allows us to reduce the skill level of our ordinary software engineer while still finding patents obvious.

Enablement: Many software patents do not enable the ordinary engineer to make and use the invention as required by the patent statute. For broad claims, this means that the patent must teach not only the specific implementation, but also every implementation available at the time of the filing. Usually, the filing date is very early; otherwise, the patent would be obvious. Such broad patents may enable particular solutions on particular hardware platforms, but limited technology available at the time means that one can’t enable the general, abstract solution on any platform available. However, because engineers were considered superskilled, they were deemed to be able to fill in the gaps to implement broad claims. This should be dialed back a bit by assuming that software engineers are not as skilled as previously thought, and that a specific hardware solution does not teach one how to implement the solution on all the hardware available at the time.

Written Description: More important than enablement, it is often not clear whether inventors are in full possession of their broadest claims, even if a skilled engineer could fill in the gaps. A recent case, called Ariad v. Eli Lilly, reinvigorated the written description requirement. Under that ruling, the ordinary skilled engineer must see enough in the specification to believe that the inventor has actually invented the broadest claim scope: “We held that a sufficient description of a genus instead requires the disclosure of either a representative number of species falling within the scope of the genus or structural features common to the members of the genus so that one of skill in the art can ‘visualize or recognize’ the members of the genus.”

Patentees often do not disclose all of the species of broad software inventions. Usually, the most one can expect is that the inventor solved a specific problem in specific hardware, and does not disclose enough general principles to show that he/she understood all ways to implement the particular claim – especially where there is no source code or pseudo source code.  The reality is, however, that there is usually some new technological breakthrough that makes the patent possible, like cheaper RAM, faster networks, etc. Requiring more detail in the written description might flesh this out, and make obviousness easier to find. Written description was, for example, the downfall of many patents held by Ronald A. Katz (see, e.g., at p. 27): “Instead, the court held that the specification fails to describe the step of ‘visually displaying customer number data’ because the only descriptions of visual display in the specification involve information that was not entered by customers.” In short, Katz tried to claim something that he didn’t actually invent at the time.

Best Mode: Patent reform (the America Invents Act) actually hurts when it comes to software. A major failing of software patents is that they do not disclose the best way of practicing the patented claim as is required by the Patent Act: “The specification shall … set forth the best mode contemplated by the inventor of carrying out his invention”. 35 U.S.C. § 112. Inventors often don’t disclose specific hardware, and they certainly don’t disclose source code.

This disclosure used to be a basis for invalidating a patent in litigation, but the AIA removes best mode as a defense in litigation, including inequitable conduct for intentional failure to disclose a best mode. However, disclosure of best mode is still required in the initial patent application. This means that a) the PTO should be asking if patentees have a best mode to force the issue, and b) the PTO should be aggressively considering the issue in reexamination proceedings.

Definiteness: There’s not much to say here; software patents are often impossible to understand. Examiners and courts should demand more definiteness, as required by the statute: “The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.” 35 U.S.C. § 112.

PTO Claim Construction: The PTO uses the broadest reasonable construction rule to decide whether a patent is valid. This is different than the way claims are interpreted in litigation, which is the way someone skilled in the technology would understand the patent. This is one reason why reexamination can lead to invalid patents in a way that litigation does not. The idea is that if you interpret each claim as broadly as possible, then there will be more prior art to apply to it and it is more likely that the written description is not sufficient to support the broadest claims. Examiners should use the broadest reasonable construction rule to expose broad claims as old, obvious, or ill-described. The problem is that many examiners have not used this rule to their advantage in the past.

I think that each of the above applications is achievable under the law as it stands, or at most a small stretch from current law. By rigorously pushing these points, opponents of software patents can make sure that only the few meritorious ones make it through without eliminating the incentives created by the patent system. Your collective thoughts are appreciated, especially because I’m presenting this as a solution to the problem of software patents at a conference this fall.

Finally, as promised above, here’s a bit about my own background. I started working with computers when I was 10 (and the elementary school’s only computer was an Apple II in the principal’s office). I started writing computer programs when I was 13 and my Dad gave me his Commodore CBM – a brilliant child-rearing decision, I have to think. I recall the dual floppy disk drive costing more than $1,000 (ouch). While I didn’t major in engineering in college, I took courses in math, statistics, computer science, symbolic systems, and neural networks. I’ve read on the subject as well; “Godel, Escher, Bach” is one of my favorites. I currently program a bit in a variety of languages, but not nearly as often as I used to.

1 Michael Risch is an Associate Professor of Law Villanova University School of Law. Professor Risch’s teaching and scholarship focus on intellectual property and cyberspace law, with an emphasis on patents, trade secrets and information access. His articles have appeared in the Stanford Law Review, Indiana Law Journal, George Mason Law Review, BYU Law Review, Yale Law Journal Online, Penn. Law Review’s PENNumbra, Tennessee Law Review, and Harvard Journal of Law & Technology, among others. His work has been cited by the U.S. Supreme Court. Prior to joining the Villanova faculty in 2010, he was an Associate Professor at the West Virginia University College of Law, and an Olin Fellow in Law at Stanford Law School. Professor Risch graduated from Stanford University with honors and distinction in public policy and distinction in quantitative economics. He earned his law degree at the University of Chicago, where he graduated with high honors and was an Olin Fellow in Law & Economics and a Bradley Fellow in Law & Economics.

  View Printable Version

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )