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.