Prior aRt and Software Patents

We’ve just begun a new project at Mozilla to create a tool that can help defend against invalid software patents.  The project is currently sponsored by Mozilla and Emily Berger of the EFF. The problem is that when patents are asserted or enforced, it’s difficult, expensive, and time consuming to find the references (documents or other software/systems) that contain the elements of the asserted patent claims, also known as prior art. Finding prior art is often one of the key defenses to claims of patent infringement; however, this part of the  process is archaic, subjective, resource intensive, and inefficient. The result is that valuable resources are diverted from innovation and R&D to non-productive patent defense costs  (when I practiced as a patent litigator, no doubt I didn’t think it was non-productive).  The harm goes beyond hard costs, even the mere specter of an infringement claim can stall and delay the adoption of technology and products, or impose additional costs in the form of royalties and damages that has the same effect.

This is great for the legal industry, but not so good for those who are defending against such claims. A key  assumption underlying the project is that non-patented commercial and non-commercial software developments present a huge, and untapped, reservoir of prior art which software patents should be – and currently are not– tested against.  There are many other good efforts to improve the patent process, some like the P2P project focused on improving the patent examination process, and others focused on changing the legal framework, such as the Patent Reform Act.  These are good efforts, but there are other opportunities for improvement.

Our goal is to spec out the project, build a beta and see if it works. If it does, we’ll extend and enhance, if not, we’ll try something else. The details of the project are at: http://wiki.mozilla.org/Legal:Prior_Art#Summary.

10 Responses to Prior aRt and Software Patents

  1. Mr WordPress says:

    Hi, this is a comment.
    To delete a comment, just log in, and view the posts’ comments, there you will have the option to edit or delete them.

  2. John says:

    Hey Harvey. Welcome to the Mozilla blogosphere…I was still hoping for “Harvilicious” though.

  3. Let me just say, as a former IBMer, and a witness to the trials and tribulations of that patent process, I’m in. How can people help out, or is it not time yet?

  4. Eric says:

    Prior Art is not actually that hard to find. I was on a patent review board that pre-screened potential patent applications before they would get sent to the Legal department. We’d reject proposals for having prior art. If you have Delphion access and Google, you’re 90% of the way to invalidating weak patents.

  5. Gc says:

    Who would be the describers/keyword-taggers, and what would be their incentives?

    The people with the most expertise with the software might be the designers/architects/developers, but as we know in open source projects they aren’t always motivated to be good specification or documentation writers.

    If there are specialized ontology vocabularies to be used, experts in those ontologies could be hired to write and keyword-tag descriptions with the specialized vocabulary, but since they don’t directly use the tags it is less clear how to evaluate their work so they have feedback and incentives to maintain and improve the quality of their work.

    One set of people who may benefit directly from using the database appears to be patent applicants doing searches for prior art when writing a patent. Although patent applicants have usually not been open source developers, they may benefit from finding prior art quickly. If they describe some prior art in one patent application, by adding it to the database they may be able to find it more quickly again in the future. (So one source of initial descriptions may be prior patents.)

    Another, overlapping, set of people who benefit directly from using the database appears to be patent defendants. If in the process of developing a defense they find some prior art not yet in the database, they may add it to the database so they can find it again more quickly in the future. (So another source of prior descriptions may be patent defenses.)

    (Groupware knowledge sharing projects have sometimes failed because the peopled tasked with adding knowledge/tags/etc to a shared database didn’t benefit from the shared knowledge, so they had little incentive to spend time on it. In some cases, the people tasked with sharing knowledge lost power by sharing knowledge, since they couldn’t ask for favors or compensation in return for spending time sharing their expertise in the database. In some cases, they had disincentives since the people benefiting from their shared knowledge were their competitors for promotions or clients.)

  6. Michael McNeil says:

    Lousy format. Almost unreadable on my standard Windows box.

    Why?

    Also you misspelled Art:
    Prior aRt and Software Patents.

  7. lori says:

    A good way to fight software patents: make a case and go to the US Supreme Court to kick them out on subject matter.

    Anyway, it is impossible to fight the system with prior art, you play the game of the patent industry.

  8. Pingback: Boycott Novell » Microsoft’s Software Patents Bill, Mozilla Brain-Picking, More Patents in Standards

  9. J.P. Wellisch says:

    An excellent idea. Not only for litigation, but also for the granting process. If the open sourse work is documented in a way that there are legally useful dates associated with the work, and the work is presented in a searchable manner, this will certainly help to improve the useful prior art available. I’d be interested to get involved in one way or the other.

    Hans-Peter.

    (This is a private comment and does not necessarily reflect the opinion of my employer.)

  10. Andre says:

    The point is subject matter not prior art. Prior art would help if the system would work as market players believe. Dig deeper.