Blog Post

Here Comes Trouble: An Antidote to Software Patents

The $250 million Vonage burned through as a result of the patent lawsuit brought by Verizon et al provides yet another example of why patents for business processes implemented on computers (a.k.a. software patents) deserve to die. Verizon’s two successful “name translation” patents negate an open standard assembled by Cisco, Microsoft, IBM, Intel and Vocaltec via the VoIP Forum during 1996. The threat of patent litigation cleared the landscape of independent VoIP companies the VoIP Forum sought to make possible.

Vonage survived and can look forward to a prosperous future as the third player in an oligopoly with the regional telcos and cablecos, but this hardly seems like the success story sought with the opening of patent protection to business methods in 1999. The work of the VoIP Forum built on the ITU H.323 standard, which dates back to 1991 , so Vonage’s loss in court does not owe to a lack of prior art. Vonage lost because of the difficulty in finding the proper documentation of prior art 15 years after the fact.

The antidote to software patents involves creating their exact opposite — a formal process of contributing software innovations to the public domain. Vonage’s experience, however, illustrates that the various standards-creating processes represent only a first step. A successful open-source model for patents requires creating a searchable archive of prior art in which inventors contribute their innovations in order to get protection from subsequent litigation.

This would replace the patent office’s dependence on the oath signed by patent applicants “acknowledging the duty to disclose all information known to be material to patentability.” Vonage’s decision to base its technical implementations on the work of the VoIP Forum and IETF seems reasonable. Who would have guessed the patent office granted Verizon a patent on the same subject matter?

Verizon’s “name translation” patents address the process of converting between an IP address and a telephone number during call setup. Absent the expectation of end users dialing IP addresses, all VoIP implementations will involve some form of “name translation.” A patent examiner trying to meet expectations of reviewing a patent per day can be excused for having missed the fact that the name translation issue arose with the ITU H.323 standard.

Questions remain over how Verizon failed to disclose the H.323 standard in their declaration, never mind the VoIP Forum’s efforts that built on the H.323 standard. Verizon’s first name-translation patent (‘711) has a filing date two months after the VoIP Forum published the results of their efforts. Verizon’s prior art disclosures also failed to mention VocalTec Communications, the company credited with bringing the VoIP category to public awareness in February 1995. The author of the patent in question, Eric Voit, initiated a relationship with Lior Haramaty, a co-founder of VocalTec, in the same month he filed the first patent.

As project director for VocalTec, I was around then; I also led a joint venture with Digital Equipment that involved implementing Verizon’s first VoIP pilot in 1998. Eric Voit’s second patent, from February 2000 (‘574), incorporates ideas addressed in detail during this pilot. However, Verizon filed the second patent as a continuation of the first — and it, too, was absent any disclosure about VocalTec or the VoIP Forum. The filing of the second patent as a continuation gives the claims the same prior art grace period as the first patent.

A formal process of filing prior art to the public domain will protect an emerging infocom industry better than just depending on overworked patent examiners and applicants for prior art searches.

28 Responses to “Here Comes Trouble: An Antidote to Software Patents”

  1. How about a use it or lose it principle for any software patents? That would stop what, to me, appear to be speculative patents designed to give lawyers something to sue for. The patent holders never use the patent and just wait till someone solves the problems of actually making things work… they then take their losely formed patent and get litigous.

    A small company like ours would be royally stuffed if a patent lawyer came after us.

  2. Andrew wrote: “Algorithms that are genuinely new in the sense that literature has never described the abstract process in any context, never mind a reduction to practice, should be as patentable as any other chemical process result if we are going to have patents at all.”

    That might be a reasonable position if the patent system was merely a system for rewarding inventors with prizes, incapable of harm. However, it is not – far from it – and such a position is economically (and ethically) naive (to put it mildly). It is also extremely naive to believe that because some software inventions are just like some other inventions in some respects, they should be patentable.

  3. Andrew, you rightly highlight the biggest failing in the current patent system when you point out that it gives out plenty of patents that are nonobvious, regardless of whether they’re software or industrial patents. However, your recurring analogy to chemical processes falls down because the patent system is a flawed way of doing even that. As you point out, it doesn’t stop drug companies from producing knockoff drugs and is a bad way of protecting drug innovation. A better IP process for drugs would focus on the safety aspects and be focused on safety certification rather than the current extension of the patent system to something it wasn’t designed for.

    As for software patents, the truth is that almost nothing algorithmic takes the level of R&D investment that some industrial processes take. You claim that you know of new algorithm patents that took years to develop but if you actually tabulate the money that was invested, you will find that it is a piddling amount. I think that the overall case for patents of any kind is pretty weak, even when you consider the xerox copier or other famous cases of manufacturing patents. When you overextend the patent system to areas it was never designed for, like software or pharmaceuticals, it breaks down completely.

  4. The absence of a working prototype is a minor point insofar as it is obvious to someone skilled in the art that such a prototype could be trivially built that functions as described. The problem with the Verizon patents is that there is nothing there that really meets the threshold of patentability (IMO) and I do defend some software algorithms as reasonable. The novelty of the patents in question is not the algorithm, but their chosen reduction to practice of an existing process.

    Using chemical process patents to illustrate the point helps, because it is less contentious. Suppose I patent a chemical process for synthesizing chemical B from chemical A by some new pathway P. I am not patenting the production of chemical B, I am patenting the novel algorithm P that allows me to synthesize chemical B from chemical A. This process P can then be reduced to practice in a diverse set of ways which are protected by copyright. The kinds of so-called “software patents” that seem to cause the problems are not those that present a novel algorithm P, but those that frame a reduction to practice of an existing abstract algorithm as a patentable entity. In the case of many business process patents, one could very much argue that they are patenting a reduction to practice which has traditionally been protected by copyright. The old “do X on the Internet” patent model is clearly nothing more than a particular reduction to practice of well-known ideas.

    Where a lot of people get it wrong is that there are many algorithm patents that are not merely trivial reductions to practice of existing algorithms. Algorithms that are genuinely new in the sense that literature has never described the abstract process in any context, never mind a reduction to practice, should be as patentable as any other chemical process result if we are going to have patents at all. Patenting genuinely new abstract algorithms/processes/mechanisms has relatively few downsides in that novel but stupid ones do not matter and the ones that represent a technological improvement are at least nominally fulfilling the intention of patents. The problem is that a lot of patents granted by the USPTO in all areas are trivial reductions to practice of already understood ideas and therefore obnoxious.

  5. Andrew,

    I appreciate the point as a theory, but the issues do not seem so clean cut in practice.

    Consider the Verizon patents in question.

    There is no working prototype.

    What is the bright line distinction between a series of ambiguous ideas that do not clearly move from A to B and a innovative algorithm?

    Verizon’s name translation patents are the equivalent of patenting the idea of there should be a “door” on a house.

  6. Daniel:

    I think it might be hard to get those companies that benefit from winning a payout in the patent lawsuit lottery to come on board. At some point, the greater good has to be the deciding factor, and businesses aren’t usually in business to do good, but to make money. Plain as that.

    Anthony Kuhn

  7. Great post, Dan, and your unique position, having worked with VocalTec in the mid-1990s, gives you a valuable perspective on the issue. Lots to think about, here:

    1. Should software be patentable? I would argue that copyright is the correct form of intellectual property protection for software. The use of the patent system for software is a misapplication of law, in my view. More on my blog at

    2. The patent office is currently drowning in patent applications and is suffering from a backlog from which it may never recover. Reforming what is patentable has to be part of the solution…it is just good government. More here:

    3. An “open source” approach to creating a prior art database sounds useful, and could help in the meantime, while patent reform hopefully winds it way through the system. I may be overly optimistic about the chances for patent reform, but I think it is the right route.

  8. I’m a little confused. I’ve read a fair amount of people decrying the evils of “software patents”, and I guess it never really occurred to me that they were specifically talking about “patents for business processes implemented on computers”. Is this the generally understood definition of “software patents”?

    As someone who has successfully prosecuted several of the “software algorithm”-type patents that Andrew referred to in his comments, it has always puzzled me why people would be so vehemently against being able to obtain patent protection for these types of innovations. As Andrew pointed out, developing a more efficient software algorithm is not fundamentally different than developing a more efficient engine.

  9. The patent system is now so messed up in a variety of ways, software patents, business process patents, reach-through issues. Ugh, what a disaster. And to think the US’s main competitive advantage in the world economy is its innovation and creativity.

  10. There are a lot of issues here that are conflated. First, one could argue that there is a real distinction between “business process” patents (e.g. Amazon one-click) and “software algorithm” patents (e.g. RSA crypto algorithm); a new algorithm is a theoretical engineering R&D result, no different than physical. Second, there is no difference between “software” and “hardware”, either in theory (people who whip out the “but it is math” argument apparently slept through their math classes) or in practice these days; I have patents for pure algorithm R&D, and they explicitly cover the continuum from software to hardware precisely because there is no meaningful distinction. Third, software algorithm patents are completely indistinguishable from the venerable chemical process patents that no one complains about (swap molecules with bits and you have an algorithm patent); you patent the abstract chemical process and then also license a copyrighted reduction to practice — asserting that this is a unique feature of software algorithm patents is simply ignorance.

    Any problem with software algorithm patents is a problem with all patents. The vast majority of non-software patents are frivolous as well. Most “business process” patents are frivolous because they are obvious (and frequently have prior art), but that is far from true in the algorithm design space. Designing a more efficient algorithm is not much different than designing a more efficient engine, and I know of new algorithm patents that had years of intensive R&D invested in the result. I do not care so much about what is done regarding patents so long as the application is consistent. A lot of problems have stemmed from the fact that patent tradition blithely pretends distinctions exist that provably do not, allowing all sorts of subjective redrawing of the lines when convenient.

  11. I suspect a better solution to the overall problem is fighting fire with fire. I think we need a Patent Cooperative to which we contribute all our patents (contributing some of them being against its charter). The Coop should be highly litigious, pay high success fees to the nastiest patent attorneys in the business, and sue the crap out of any non-members. The Coop’s charter should prevent settling out of court, so that the only way to avoid paying damages if awarded is joining the Coop with ALL of ones patents, losing the ability to enforce them against other members and cut 1-on-1 cross-licensing deals.

  12. If as you say there was prior art, Vonage would surely have raised that issue in court and invalidated Verizon’s patent. You seem to have very limited understanding of patent law. Better leave these issues to those who are better informed.