How to Fix Software Patents (Part 3 of 3)

By Eric Goldman

Posted on January 11, 2013


There has been a lot of angst about software patents, and I’ve already posted about some of the problems software patents create and some of the challenges trying to fix those problems. Unfortunately, the rhetoric about software patents tends to devolve into a black-or-white debate: are software patents good for society, or should we kill them?

I want to move past that binary–and irresolute–discussion. Last month, at Santa Clara University, we held a conference entitled ”Solutions to the Software Patent Problem” that assumed, without debating, that software patents were a problem. With that premise, conference participants could focus their attention on thoughtful and creative ways to redress the problems created by software patents. Undoubtedly, some of the speakers and attendees favored killing software patents outright, but most speakers and attendees supported more nuanced and implementable approaches could fix the problems of software patents without resolving the question of whether software patents are good or bad.

At the conference, we heard a lot of different proposals (nearly two dozen) from experts in the field. I thought all of them had promise (that’s why we put the presentations on the agenda in the first place), but here’s a recap of some of my personal favorites:

* Prof. Mark Lemley (Stanford). Prof. Lemley argued that many software patents use “functional claiming,” which is patenting a software function (basically, the problem that needs to be solved) rather than a specific way to implement that function (the innovator’s solution to the problem). For example, currently we allow patent claims in the form “a computer programmed to achieve this result” or “a computer programmable/capable of achieve a result” (his research identified 11,000 patents using the “capable of” language). Prof. Lemley argued that we should prevent functional claiming in software, allowing patents only on methods of achieving the function, not the function itself. For more on Prof. Lemley’s solution, see his Wired Opinion and Wisconsin Law Review articles.

Prof. Lemley’s proposal squarely attacks the breadth of software patents. By limiting software patents to their specific way of accomplishing a function, other innovators can develop alternative solutions without infringing the patent. Further, courts and the Patent and Trademark Office (the PTO) can execute this solution without legislative changes by changing the way they apply existing laws. Thus, this solution could be implemented immediately.

* Prof. Arti Rai (Duke). Prof. Rai noted parallels between software patents and patents on bioinformatics–basically, software applied to biopharmaceuticals–which are handled in PTO Art Unit 1631. In art unit 1631, the PTO implemented a more stringent non-obviousness review of applications, requiring patent applicants to provide better written descriptions of the patents and more definite claims. Due to the heightened scrutiny of these patents, a noticeably higher percentage of applications were rejected on non-obviousness grounds. Prof. Rai argued that software could be subjected to similarly higher scrutiny, something that (like Prof. Lemley’s solution) the PTO and courts could implement immediately under existing law. On the other hand, changing the PTO’s evaluation of software patents doesn’t address the perniciousness of legacy software patents that never should have issued. For more on Prof. Rai’s solution, see her Wired Opinion article.

* Prof. John Duffy (Virginia). Prof. Duffy took a more conceptual approach than Profs. Lemley or Rai. He argued that patent law’s non-obviousness requirement should screen out innovations that multiple inventors identify around the same time. While perhaps counter-intuitive, simultaneous invention happens often–enough to have a Wikipedia page, a Malcolm Gladwell article and a Mark Lemley article. The point is that if multiple inventors achieve the same solution around the same time, then the innovation apparently was obvious to the relevant experts and therefore doesn’t deserve the patent reward. For more on Prof. Duffy’s solution, see his Wired Opinion and Yale Law Journal articles.

Though the approach isn’t limited to software patents, it would help with software patents–which are also the subject of simultaneous invention–and it could be implemented by the PTO and judges without new legislation. However, I’m concerned about the adjudication costs to figure out if multiple inventors made the same innovation around the same time. Furthermore, I would expect patent applicants in some non-software disciplines–notably, pharmaceuticals–may resist this approach, potentially even seeking Congressional intervention.

* Prof. Sam Vermont (University of Miami). Prof. Vermont noted that in some cases, the research costs to find and diligence precedent patents might be more costly than just independently inventing the innovation. This is especially true with software innovations, as discussed in this 2010 post by Brad Burnham (who spoke at the SCU conference). Thus, Prof. Vermont proposed a defense when the “defendant’s costs to find the patentee’s version of the invention beforehand were greater than the defendant’s costs to invent it on his own.” In some sense, this situation is a damning indictment of those patents; if it’s cheaper to recreate the innovations than to find their patents, why did we give those innovations a patent reward in the first place? For those reasons, I like Prof. Vermont’s suggestion, but it would require new legislation to implement, making it potentially more of an insightful thought exercise than a practical near-term solution.

* Maintenance Fee Reform, advocated by Prof. James Bessen (Boston University) and Prof. Brian Love (SCU). Prof. Bessen analogized patents to pollution because both produce negative externalities. To internalize the externality, Prof. Bessen argued for Pigouvian taxes in the form of increased maintenance fees (ongoing payments to maintain the patent in effect). By his estimate, the maintenance fees should increase 10x to reflect the patents’ true social costs; and he would further adjust maintenance fees to reflect the likelihood of patents being asserted, which would result in even greater increases for software/business method patents. See Prof. Bessen’s Wired Opinion article.

My colleague Prof. Brian Love has written about how some of the lowest-merit patent lawsuits come near the end of a patent’s term. We could mitigate those suits by truncating the patent term, but that’s not likely. Nevertheless, we can achieve a similar result by changing the maintenance fee structure to cause some weak patents to lapse early, including increasing maintenance fees as the patent ages and adding new late-term payment periods. See Prof. Love’s essay explaining this point and his University of Pennsylvania Law Review article.

Economic theory supports modifying maintenance fees by getting patent owners to internalize the costs of their actions. In particular, I was particularly persuaded by Prof. Love’s analysis that we should have at least one more maintenance fee payment period later in the patent term; the last maintenance fee payment date comes too early in the patent term.

However, tinkering with maintenance fees could produce unexpected results. This Vanderbilt Law Review paper suggests the PTO may adjust its patent issuance rate to maximize its revenue. Reducing the PTO’s maintenance fee revenue by lapsing more patents might cause the PTO to issue more patents to increase revenues from patents before they lapse. Similarly, increasing the maintenance fees-per-patent could cut in different directions: the PTO might reject weak patents because of increased revenues from issued patents, or the PTO might be issue more weak patents in a pure revenue grab. It might be possible to ameliorate these unwanted budget-driven decisions, but before we tinker with maintenance fees, we better understand all of the dynamics, not just how patent owners will respond.

* Prof. Jennifer Urban (UC Berkeley). Prof. Urban, along with Prof. Jason Schultz (also of UC Berkeley), proposed the Defensive Patent License (DPL). Patent owners can opt-into the DPL, in which case they agree to license their patents royalty-free to everyone else who has opted into the DPL. In effect, everyone participating in the DPL agrees not to sue each other for patent infringement. This gives companies substantial incentive to opt-into the DPL; by doing so, they eliminate the potential patent risk from dozens, hundreds or even thousands of other industry participants. This solution nicely responds to the prisoner’s dilemma by increasing the payoffs from defanging patents.

However, the DPL has some obvious limitations (among others): (1) it does not affect patent trolls who never participate in the DPL, (2) it assumes enough players join the DPL to make other companies want to join the network (i.e., the DPL exhibits network effects), and (3) it assumes that DPL participants bring enforcement actions against non-DPL participants; otherwise, the non-participants can free-ride off the network without paying the costs. I think the DPL is a brilliant concept, but it remains to be seen how effective it will be in the marketplace. Read Profs. Urban and Schultz’s explanation of the DPL.

Ben Lee of Twitter introduced a related idea, the Innovator’s Patent Agreement (IPA), where Twitter unilaterally promises that it will not assert specific patents offensively. This promise principally targets Twitter’s own employees, who don’t have to fear that their innovative work lead to socially harmful patent lawsuits. The IPA doesn’t rely on network effects, so any company can adopt it unilaterally; but for the same reason, adoptions may be slow and possibly de minimis.

Other Ideas. Two other solutions to software patents that came up throughout the conference:

1) The SHIELD Act. The SHIELD Act would make it easier for successful defendants in weak computer patent cases (both hardware and software) to get their attorneys’ fees. The fee-shift only benefits defendants; successful plaintiffs wouldn’t be any more likely to get their attorneys’ fees covered. As a result, the SHIELD Act would increase plaintiffs’ anticipated costs of litigation and thus discourage weak computer patent cases from being filed.

We didn’t have anyone at the conference expressly advocate for the SHIELD Act, although Google’s ($GOOG) Kent Walker (and others) did express support. See Kent Walker’s Wired Opinion article. Like all legislative solutions, the odds that the SHIELD Act will pass are low, at least in the near future.

2) An Independent Invention Defense. Independent invention–i.e., innovators developing the same innovation without reference to each other’s work–occurs all the time, especially in the software community. Unlike the other main intellectual properties, patent doctrine does not have a general-purpose independent inventor defense [FN]. Why do we treat patents differently?

FN: Independent invention is a complete defense to trade secret misappropriation, although a person actually exposed to trade secrets is effectively barred from later claiming independent invention of those ideas. Independent creation is also a defense to copyright infringement; but like trade secrets, a person exposed to a copyrighted work can’t claim independent creation, and furthermore, we inferentially presume copying rather than independent creation in some situations where the defendant could have been exposed to the work. Trademarks aren’t infringed merely by copying, so independent development of an identical trademark does not contribute to trademark infringement However, intent to copy a third party trademark is a factor that weighs against defendants, and proving good intent goes a long way towards a successful defense.

An independent invention defense to patent infringement poses some practical problems. First, it will be asserted by most (if not all) defendants, increasing patent adjudication costs. Second, the evidence to prove or disprove independent invention often will be self-serving, like asking engineers to self-report what material they reviewed to achieve their goals. Third, the defense will give inventors even more incentive not to research the patent database (for fear of seeing patents and thus losing the ability to claim independent invention), further undermining the public disclosure benefits of patents.

These problems highlight the strength of Prof. Duffy’s suggestion. Rather than trying to investigate what was independently invented and what wasn’t, we could use that same fact (that multiple inventors reached the same solution) to support a non-obviousness objection–and, unlike an independent invention defense, we could achieve that result without any legislative changes.

What Next?

Our November conference attracted 250+ people–most of whom came because they want to fix the problems with software patents. It was a remarkably large and enthusiastic crowd, and there was palpable energy to fix software patents. It’s clear that the Silicon Valley community, and many other technology communities, are experiencing a lot of pain from software patents.

Even so, I remain bearish on legislative solutions–even relatively minor changes like the SHIELD Act–at least in the next few years. Congress made some big moves with the America Invents Act (AIA), and cleaning up the bugs in the AIA will consume whatever remaining time and appetite Congress has for patent issues.

As a result, I’m more optimistic about solutions that the PTO or judges can unilaterally and immediately implement without any statutory changes. I think a combination of Profs. Lemley’s, Rai’s and Duffy’s proposals are especially promising. By re-characterizing the appropriate level of acceptable abstractness, requiring more proof from patent applicants, and then screening out innovations that multiple inventors all achieve around the same time, the PTO would kill most of the least appropriate patents, and judges could finish off any unmeritorious patents that somehow get through the PTO. I also think marketplace solutions, like the DPL and IPA, hold promise, but they aren’t likely to solve the problems on their own.

Ultimately, the single most important thing we can do is to keep identifying problems (like my colleague Prof. Chien’s research on Startups and Patent Trolls and Reforming Software Patents) and researching and publicly debating solutions. By continuing to shine the spotlight on the issues, the issue will remain impossible for policymakers and judges to ignore–as evidenced by a recent speech by PTO Director Kappos shortly after the SCU conference, where he simultaneously (and quite defensively) decried critics of software patents and outlined the many steps the PTO has taken handle software patents better. Perhaps it’s so obvious that it need not be said at all, but the many criticisms levied against the PTO have helped drive some of the PTO’s improvements. Simply discussing software patent issues publicly makes a difference. Let’s continue this conversation in the comments below, in comments to the Wired Opinion articles and at the EFF’s website, Defend Innovation.

1) The Problems With Software Patents (re-published on TAP: part 1)
2) Two Challenges to Fixing Software Patents (re-published on TAP: part 2)
3) How to Fix Software Patents (re-published on TAP: part 3)

The preceding is re-published on TAP with permission by its author, Professor Eric Goldman, Director of the Santa Clara High Tech Law Institute at Santa Clara University. “How to Fix Software Patents” was originally published December 12, 2012 on Professor Goldman’s Tertium Quid blog at Forbes. This post is one of a three-part series that has been compiled into an integrated article: “Fixing Software Patents.”