Last week, the Supreme Court heard oral arguments in what is expected to be a significant case on software patents, Alice v. CLS. The consensus view based on how the oral arguments went seems to be that the Court is not likely to issue a sweeping ruling.
Regardless, this seemed an appropriate juncture to talk about what’s wrong with the US patent system, and in particular, what’s wrong with respect to software patents.
Editorial Note: This is a revised version of an earlier article, “What’s Wrong With Software Patents?”
Focusing on Patent Trolls
Congress has been focused of late on crafting legislation to problems with the patent system related to patent trolls. “Patent trolls” is an (obviously) pejorative term for what are known as non-practicing entities (NPEs). That is companies that don’t actually make or provide a patented product or service, but merely attempt to seek license fees from other companies. It’s not that being an NPE is inherently a bad thing, but in practice, a business model has developed over the years whereby NPEs have engaged in patent abuse, bringing suits without merit, and attempting to collect licensing fees from companies that make a pragmatic decision that it is cheaper to settle than to litigate.
Most of these NPEs are not individual inventors asserting their own patents, but companies created specifically for this purpose, who buy these patents, usually inexpensively. Often, the NPEs create complex business structures of shell companies, so that if a company does decide to litigate to defend itself, and the suit is found to be frivolous, the NPE is judgment proof: it’s impossible for the defendant to collect damages (such as recovering its legal expenses), because the NPE holds no assets.
Lawsuits from NPEs are also especially hard to defend, because of the fact that they don’t practice. In a typical patent litigation where, say, one competitor sues another for patent infringement, the defendant will frequently counter by suing for infringement of its own patents. When an NPE files suit, however, it’s impossible to countersue them for patent infringement, because they don’t actually do anything but file lawsuits.
Having spent many years in industry dealing with patent trolls, myself, I can assure you, they are a serious problem. (We’ll discuss some of the issues of patent abuse that are usually involved in patent troll cases, in a second part of this series.)
But patent trolls are hardly the only serious problem with the patent system, and focusing solely on trolls does a disservice to us, by ignoring other serious problems.
What I’d really like to talk about here are some fundamental problems with how the patent system works (or doesn’t work). To go back to the interest in the case heard yesterday, software patents are a particularly problematic area.
Not All Patent Fields Are Created Equal
One thing I do feel pretty certain of is that if you’re against software patents, you’re against patents in general. Gradually our machines consist more and more of software. Things that used to be done with levers and cams and gears are now done with loops and trees and closures. There’s nothing special about physical embodiments of control systems that should make them patentable, and the software equivalent not.
On a philosophical level, Graham is at least partly correct. While I’m not certain that all fields in which one can obtain patents are philosophically equivalent to software (drug patents?), there are certainly many that are. In particular, it’s pretty tough to draw a distinction between a software algorithm and an electronic circuit embodying the same software algorithm, in hardware. (I will skip an extended discussion over terminology and the formalities of that patent system that say “algorithms” aren’t patentable.)
The problem with Graham’s view, however, is that the basis for our patent system is pragmatic not philosophical.
To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries;
Note that explicit purpose of patents (as well as copyright) is to promote progress. This is utilitarian in nature: patent law should be designed to balance the encouragement of inventors (via the granting of exclusive rights for limited times) against the interest of society in enabling others to exploit and enhance those inventions, in order to maximize the promotion of progress.
Accordingly, any patent policy needs to be evaluated based upon its pragmatic effects, and to the degree that these effects are different in different fields of use, there should be different policies.
For example, if we look at something like drug development, we have a field where there are relatively few participants, where the cost to identify, develop and bring a drug to market typically costs at least tens of millions of dollars, and where there is a very high risk of failure along the way (after tens of millions of dollars have already been invested). As a practical matter, it’s hard to see how for-profit entities could continue to invest in drug development, without the benefit of exclusivity for some period of time, once a successful drug gets to market.
Furthermore, drug patent claims tend to be very narrow, covering a specific compound, or a closely related set of compounds with a common active component, so they have a very limited effect when it comes to preventing others from pursuing other advancements. In fact, once it becomes apparent that a drug shows significant promise, it’s quite common for competitors to begin identifying and developing similar candidate compounds. This why, for example, we have many different statins, developed by different drug companies, available to treat high cholesterol.
As much as some may criticize certain aspects of how drug companies operate, and how they use patent laws, it’s hard to argue that granting some form of patent protection isn’t very important to the continued development of drugs.
The same cannot be said for all fields, and in particular, for software patents (and business method patents, more generally).
The Problem with Software Patents
Let’s consider the software field. But before we do, let me point out that an important aspect of patent law is that it grants the owner of a patent exclusive rights to an invention, even to the exclusion of other independent inventors. That is, if second person also discovers an invention, without knowledge of, and completely independent of, a prior inventor who holds a patent, that second person is nonetheless prohibited from using their own invention, because another inventor discovered and patented it first.
The idea is that, by encouraging inventors to publish their discoveries (in patents), others will learn from those discoveries and be able to build on them faster than if they had to rediscover the inventions, themselves. This will be true so long as, most of the time, nobody would independently rediscover the same inventions, long before the patents expires
With that in mind, let’s go back to examining the characteristics of the software field.
Monkeys at the Typewriter (or Independent Reinvention)
There are literally millions of software developers, because, unlike drug development, the cost of entry to software development is incredibly low—as little as a few hundred dollars for an inexpensive laptop. One consequence of having so many working in the field is that almost all “inventions” are independently reinvented very quickly, by many software developers.
Software developers would typically consider such “inventions” to be obvious. And while patents are ostensibly prohibited from being issued for the obvious, obviousness is a nebulous concept, and establishing it as grounds to reject a patent application is difficult.
The result of which is that the patent office frequently issues patents, lasting on the order of 20 years, for obvious software “inventions” that have undoubtedly already been independently re-invented many times, even before the patent issues. I have often characterized this as granting 20 year monopolies for inventions where the expected interval to independent reinvention is 5 minutes. And while 5 minutes may be a tongue-in-cheek estimate, it is no joke that the length of the monopoly being granted dwarfs the amount of time we can expect it to take before independent reinvention occurs.
In such circumstances, patents serve the opposite of their intended purpose, becoming an inhibitor to progress.
He Who Laughs Last, Laughs Best (or Who Actually “Invented” It?)
In fact, many inventions that get patented aren’t even new (or novel in patent parlance). Historically, the patent office has a very poor record of being able to identify all relevant prior art, and has relied primarily on searching prior patents and patent applications.
But precisely because software has such a low cost of entry, many software developers can’t justify the thousands of dollars, and significant time, required to file and prosecute a patent application. For a drug development company, the cost to file a patent is trivial compared to other costs. By comparison, even for successful software development companies, the cost to pursue patents can be quite significant, and often hard to justify. (Furthermore, software inventions only became patentable relatively recently, so that decades worth of subject matter isn’t part of the patent database, to begin with.)
The result is that patents often get issued to inventors who aren’t actually the first inventor, but who merely independently reinvented the (probably obvious) patented invention.
Predicting the Weather (or Forecasting, not Inventing)
Many people who aren’t familiar with the patent system still believe that in order to patent an invention, one actually has to build it first. In fact, there is no such requirement. One merely needs to “reduce to practice,” which means to explain it in sufficient detail that a “practitioner skilled in the art” could implement it “without undue experimentation.”
So in fact, in a field like software patents, it isn’t actually necessary to have so much as cheap laptop, or even to know how to program computers!
On the one hand, it’s conceptually understandable that an inventor might have the proverbial “flash of genius,” whereby she conceives an important advance merely as a thought experiment. And if by doing such, she advances the art, why should it be necessary to actually implement it, herself, to protect the invention?
On the other hand, when coupled with the fundamental characteristics of the software industry—that there is constant invention and independent reinvention, at a very rapid pace—what this has overwhelmingly meant in practice is that patents frequently get issued for merely forecasting the direction that technology will take.
A perceptive observer anticipates a natural advancement that will take place, sometimes smaller, sometimes larger, and then races off to the patent office to file a patent. The filing of the patent will have no impact on the industry, whatsoever—typically, nobody will even know of its existence. But if the forecast proves at all accurate, the “inventor” is liable to succeed in getting claims to issue that will allow her to tax all users of the “invention” for nearly two decades. (And as we will see in the second part of this series, even inaccurate forecasts are frequently used to impose such taxes.)
You might think this would be rare, given the expense of patent prosecution, but it’s actually quite common, for there are many situations where prosecution costs are not a barrier. For example, many large companies (such as IBM, Microsoft, Apple, Google, etc.) can afford to invest in patent development programs, and often create incentives (both financial, and in terms of prestige) for employees to submit potential patents. It is extremely frequent for such well-funded companies to file patents for ideas employees have submitted that are nothing more than that: ideas, which may or may not ever get turned into a project or product.
At the other end of the spectrum are those who are prepared to self-file patents. The “serial inventor” who educates himself sufficiently on patents to write and prosecute his own patent applications, the attorney who prognosticates where technology will lead on the side and files patent applications despite not being very technical, or who finds “serial inventors” to partner with, and takes an ownership stake in the patents, in exchange for handling patent prosecution.
(Who you less frequently find in this category are startups and smaller companies, that often can’t afford even to fully pursue patenting the things they’re actually doing, let alone things that they aren’t doing.)
But whatever the origin, the result is that patents frequently get issued to “inventors” who do nothing more than forecasting the weather. Like all weather forecasters, these prognosticators do nothing to change the future. They merely predict it. But under the patent system, they are often then authorized by the government to collect a toll from everybody they see carrying an umbrella.
The Last Refuge of Scoundrels (or Motivating Lawsuits, But Not Innovation)
Of course, the purpose of the patent system is supposed to be to encourage people to take actions—and specifically, actions which they otherwise would not take—to actually change and advance the course of innovation, not merely to forecast it quietly from the sidelines.
It may surprise some, but there’s actually very little evidence that patents in the software field are important to motivating development of new inventions. Once upon a time, almost all software inventions were unpatentable, and yet, the software industry saw robust growth, nonetheless. In reality, almost all of the inventions in the software domain that get patented are valuable to those who create them, regardless of whether a patent can be obtained. To pick a particularly notorious example, would anybody believe that, absent a patent system, Amazon wouldn’t have “invented” one-click ordering?
In fact, the software industry moves so quickly that software patents typically don’t issue until years after the “invention” has gone to market. That means that the owners of those inventions decided it made business sense to use the inventions long before they knew whether or not they would even be able to obtain patent protection, and with nothing to stop competitors from copying the “invention” in the intervening time.
While there are other fields where this may occur, in many (perhaps most) of those other fields, companies can be reasonably confident in predicting the scope of the claims that will eventually issue. Not so with software, where it is extremely difficult to predict the scope of claims that will eventually issue, or whether any claims will issue, at all. The fact that software development proceeds despite this inability to determine what, if any, patent rights they will be able to obtain, strongly suggests that patents truly are a secondary consideration, not a primary motivation to develop.
Having spent two decades working in (mostly) software at large companies, I have yet to see any company that evaluates development projects where potential patents are part of the ROI analysis. That includes when I was doing software-development at IBM, who year after year leads the US in issued patents. (Granted, not all of these relate to software.) Rather, at least when it comes to software development, identification of potentially patentable subject matter is typically left to reviews shortly before (and sometimes even after) a product ships. And when I was at IBM, there weren’t even standard processes requiring such reviews. While IBM was and is certainly interested in building a patent portfolio in software, patents simply weren’t a factor in deciding whether to proceed with any given project.
Personally, as an investor in both software and (mostly medical) device startups, I can tell you that it’s hard to imagine investing in a device startup without exclusive rights to existing patents, or a strong expectation that patents will issue, on key aspects of the device. Absent that, it’s too likely that success will immediately spur well-funded competitors to enter the market.
On the other hand, I have yet to invest in (or to decline to invest in) a software startup that I believed had any significant chance of excluding competition through patents. Software startups often will apply for patents, usually because they want to be able to check off a box saying “we’ve applied for some patents on this,” but the reality is that investment decisions in such companies get made on other perceived competitive advantages, such as first/early mover advantages, access to proprietary data sets, etc. Patents simply aren’t a significant factor.
Yet patents will eventually issue to many such startups. Typically, there will be no attempt to enforce these patents, so long as the company is progressing successfully. On the other hand, if the startup fails, those patents are very likely to become the fuel for new patent troll suits, with all the abuses and burdensome effects that come with such.
A Baby in the Bathwater?
Now, none of this says that there are never instances where truly breakthrough inventions occur in the software domain, or where the ability to exclude others from using an invention is critical to enabling an inventor to fully develop and exploit it.
But anybody who works in this field knows well that those instances are extremely few and far between. And those familiar with the patent system also know that, even after decades of trying to implement improvements, the patent system has proved completely ineffective at distinguishing these rare instances.
So what we end up with in the software field (and surely in at least some other fields, also) is a patent system that unequivocally imposes huge and unjustifiable burdens on development in the field, while offering, at best, highly questionable value in terms of “promot[ing] progress.”
The purpose of patent law being inherently pragmatic in nature, the conclusion is obvious: patent policy for the software inventions needs dramatic reform. In all likelihood, the best policy would be to simply eliminate patent protection for software inventions, altogether. This is especially true considering how rife with abuse the patent system has come to be.
(And consistent with Paul Graham’s observation, patent protection for inventions that merely embody a software-equivalent algorithm in a physical implementation should be handled similarly.)
Some would complain that we’d be throwing out the baby with the bathwater. But if there’s a baby at all, it has already drowned in what is an ocean of bathwater, that’s in the process of drowning the whole industry.
In the second part of this series, we’ll outline the most common and problematic forms of patent abuse and explain how patent abuse has now become not just common, but in many respects, best practice.