Best practises for writing defensive publications

So with the Apple vs. Samsung case drawing to a close, we’re all being reminded how bad patents are, for developers, for innovators, and also for consumers. I’ve written about Defensive Publications as a means to fight the war on patents before, and while reading the news this morning, it’s probably time to give everybody around a few hints how to best write a defensive publication so that, at least that idea, cannot be patented and used in the war again.

A defensive publication is a technical document that describes ideas, methods or inventions and is a form of explicit prior art. Defensive publications are published by Open Invention Network in a database that is searched by patent offices during a patent exam. A good defensive publication will prevent software patents from being granted on ideas that are not new and inventive.These will help protect your freedom to operate.

A defensive publication typically consists of the following:

  • a descriptive title
  • a few paragraphs documenting the idea including how the idea would work.
  • one or two (or more) diagrams describing control flow, interaction, network flow or communication between components possibly an example or two

It is important to make sure that a defensive publication does not go into too much detail: patent examiners typically have little time to read all materials and it makes it likely to miss the important bits. If possible only describe one idea or invention per defensive publication. If there are two or more ideas that can be conceptually separated, split them and write them as separate defensive publications.Make sure that the defensive publication connects completely describes the idea by explaining HOW this idea would work. This part is the most important. Without the how, the idea is too abstract.

Things to watch out for when writing defensive publications:

  • don’t use technology specific terms, like program names. For example: don’t say MySQL, say database.
  • don’t refer to competitor’s products, or say that it works like a specific technology
  • try to use standard terms that are in common use

Examples of defensive publications can be found on Via the “search” menu a menu for “non-patent literature” can be found. The publications sent in via Linux Defenders can be chosen in the drop down box for prior art databases.Good places to scrape for ideas for defensive publications:

  • roadmap
  • blog posts
  • issue tracker (especially wish lists)

Tools for making the diagrams:Good tools for making the diagrams are:

  • xfig (very basic)
  • scribus (for a limited set of diagrams)

If you’re interested in how this could look like in practise, have a look at my example defensive publication on KDE Plasma’s Activities.

Much thanks go to Armijn Hemel, Andrea Casillas and Raffi Gostanian from the Open Invention Network for helping me collect these tips.

9 thoughts on “Best practises for writing defensive publications

  1. The link to your example defensive publication gives error 404. It has an additional “n” in the hostname.

  2. Very interesting suggestion. Please make sure that in the document are your name, date, and place. In the description make clear what is new about it. Finally, some other good tools are Inkscape and Dia.

  3. [Disclaimer: I work for a company that (also) does software patents, but I am one of the good guys]

    I have to disagree with the “It is important to make sure that a defensive publication does not go into too much detail: patent examiners typically have little time to read all materials and it makes it likely to miss the important bits. ” statement.

    Do not care about the patent examiner. The real obstacle are the opposition divisions and the patent courts – they do have time to read all documents thoroughly.
    The patent granting process is based on a hypothetical person, the “man skilled in the art”. He is kind of autistic in that he knows everything, but does not have creativity. For a good defensive publication it is of paramount importance to guide the “man skilled in the art” by making explicit reference to all relevant neighboring technologies. In a strong publication, you will read phrases like “while example 3 discloses the use of an embedded database, it is also possible to use a database server or a cloud-based service”

    1. The question to think about is: Why isn’t public source code sufficient as a defensive publication?

      1. Quoting Armijn from here:

        Because the patent examiners don’t search source code. They only have a ridiculously short term to research a patent claim (about 8 to 10 hours over a period that could be two *years*), so they tend to search a limited set of prior art and existing patent applications.

        Patent examiners are not lazy: they are just extremely overloaded with work, so they simply can’t decipher all code out there, and stick to the things they know are good prior art.

        What we (disclaimer: I work for Open Invention Network) try to do is to make a good source of explicitely documented prior art of open source software. We submit the defensive publications we receive to a database on, to which many patent offices are subscribers.

        This is not about doing a patent examiner’s job and your suggestion about getting paid for it doesn’t make any sense to me at all. It is about protecting your own freedom to operate and help patent applications for which prior art exists to be rejected, or decreased in scope.

      2. In a perfect world, source code would suffice.

        In our world, you have to convince a jury (or a judge) that a stack of paper containing strange characters (lisp) is equivalent to a claim of the patent in suit. Good luck with that!

Comments are closed.