OSCON 2005 Day 5: What every open source project should know about patents

Email.Email weblog link
Blog this.Blog this

Robert Kaye
Aug. 07, 2005 06:39 PM

Atom feed for this author. RSS 1.0 feed for this author. RSS 2.0 feed for this author.

Jason Schultz's "What every open source project should know about patents" was the last session I got to attend at this year's OSCON, and I'm really glad I did. Even though I knew the most crucial things about patents, there were a number of things that Jason managed to clue me in on. Before I dive into Jason's presentation, please be aware that these notes only apply to the US. The European and Japanese patent systems are different and many of the concepts and laws presented here may not apply.

Jason defined then purpose of patents as: "To promote the Progress of ... useful arts". A patent grants an innovator a limited time monopoly (currently 20 years from when the patent was filed) on an innovation, in exchange for making the innovation public. The idea is to reward people for doing research and to further the public good by making the patents available to the public. A patent needs to be novel (never been done before) and non-obvious (must be a hard problem to solve), enabled (teaches public how to apply your patent) and described (limits of the property right must be described). A patent is comprised of claims, a specification, figures and prior art. The claims section is the most important part of a patent -- each method in the claims section represents an independent right and someone who infringes on a patent can be sued on each one of these methods.

Prior art are ideas that came before the patent in its field of art, and proves the idea was either:

  • known
  • used
  • published or
  • patented

In order for an idea to qualify as prior art, it must be documented in print or corroborated prior to the filing date of the patent. After introducing the basics of patents, Jason went on to talk about the US Patent and Trademark office that issues patents -- and this is where the problems start piling on. The patent office examines about 300,000 patents each year and each patent examiner only gets to spend about 10-15 hours of time on each patent. With such a limited amount of time per patent and limited amount of resources for patent searches, all the examiners can do are quick and dirty reviews of patents. No wonder that most patents are granted!

To make matters worse, if someone knows that a patent exists and they infringe on the patent, they can be held liable for three times the damages if they had not known about the patent (willful infringement). Given this twist, companies will send out letters to other companies in the same field when they are granted a patent. Using this sneaky scheme, the company that was granted the patent can inform others of their patent and those who have received the patent then know of the existence of the patent and are thus automatically liable for three times the damages. The overall effect is that companies attempt to not educate themselves about patents, in fear of being held liable for greater damages.

And as if things weren't bad enough, Jason dove into Lexicographic games that patent applicants play in order to trick the patent office to issue another patent. In US patent 5,728,005, a simple kids slide is described as: “Slide with lateral side channels". In US patent 5,842,927 the same slide is described as: “Children's slide with integral raceways”. Both patents were issues and are fully valid, even though the first patent should've served as prior art to the second patent. Intentional obfuscation on the part of patent applicants greatly complicate the patent examiner's job, making it nearly impossible for a patent examiner to do a thorough job on any one patent.

Finally, Jason presented few tips on what open source projects can do to protect themselves a little:

  1. Acknowledge that patents are a problem: Ignorance will not save you and innocence and good faith not a defense.
  2. Don’t be afraid to read bad patents: Willfulness is not the primary threat -- design/program around problem patents
  3. Know a good patent lawyer: Patent cases are expensive, but general advice isn’t -- you can often get reduced-fee advice on risks and design-around requirements.
  4. Document Everything: Every email, patch, comment, and line of code is prior art on future patents -- publication/posting date and public availability are critical.
  5. Know which patents to hate and which ones to hunt: Many silly and scary patents out there, but less than 5% are litigated. Worrying about each patent is wasteful. Watch actors and anticipate who is the real threat and which patents are at the heart of their portfolio and your product’s value.

While Jason's talk was a great intro to the perils of patents in the open source space, you should seriously consider seeking the help of a patent attorney if you think that you have some patent problems to worry about.

Robert Kaye is the Mayhem & Chaos Coordinator and creator of MusicBrainz, the music metadata commons.