Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

March 02 2011

Software patents, prior art, and revelations of the Peer to Patent review

A href="http://us1.campaign-archive1.com/?u=33d934c165e69e4b507504c2b&id=8771dc3ae5&e=77c352ede8#mctoc1">report
from the Peer to Patent initiative shows
that the project is having salutary effects on the patent system.
Besides the greater openness that Peer to Patent promotes in
evaluating individual patent applications, it is creating a new
transparency and understanding of the functioning of the patent system
as a whole. I'll give some background to help readers understand the
significance of Manny Schecter's newsletter item, which concerns prior
art that exists outside of patents. I'll add my own comments about
software patents.


Let's remind ourselves of the basic rule of patenting: no one should
get a patent for something that was done before by someone else. Even
if you never knew that some guy on the other side of the world thought
of adding a new screw to add to a boiler, you can't get a patent on
the idea of adding a screw in that place for that purpose. The other
guy's work is called prior art, and such prior art can be
found in all kinds of places: marketing brochures, academic journals,
or actual objects that operate currently or operated any time in the
past. For software (which is of particular interest to most readers
of this blog), prior art could well be source code.

Now for the big lapse at the U.S. Patent Office: they rarely look for
prior art out in the real world. They mostly check previously granted
U.S. patents--a pretty narrow view of technology. And that has
seriously harmed software patenting.

Software was considered a form of thinking rather than as a process or
machine up until the early 1980s, and therefore unpatentable. Patents
started to be granted on software in the United States in the early
1980s and took off in a big way in the 1990s. (A useful href="http://www.bitlaw.com/software-patent/history.html">history has
been put up by Bitlaw. This sudden turn meant that patent
examiners were suddenly asked to evaluate applications in a field
where there were no patents previously. So of course they couldn't
find prior art. It would have been quixotic in any case to expect
examiners--allowed less than 20 hours per patent--to learn a new field
of software and go out among the millions of lines of code to search
for examples of what they were being asked to grant patents for.

In many parts of the world, software is still considered unsuitable
for patenting, but it's worth noting that the European Union has been
handing out patents on software without acknowledging them as such,
because a hard-fought battle among free software advocates has kept
software officially unpatentable.

In the U.S., patents have been handed out right and left for two
decades now, so the prior art does exist within patents on software.
But that even makes things worse. First, the bad patents handed out
over the initial decades continues to weigh down software with
lawsuits that lack merit. Second, the precedent of so many unmerited
patents gives examiners the impression that it's OK to grant patents
on the same kinds of overly broad and obvious topics now.

Now to Schecter's article. He says the patent office has long
acknowledged that they look mostly to patents for prior art, but they
won't admit that this is a problem. One has to prove to them that
there is important prior art out in the field, and that this prior art
can actually lead to the denial of applications.

And Peer to Patent has accomplished that. From Schecter:

Approximately 20% of patent applications in the pilot were rejected in
view of prior art references submitted through Peer To Patent, and
over half of the references applied by examiners as grounds for those
rejections were non-patent prior art.

The discussion over the patent process, which has progressed so
painfully slowly over many years, now takes a decisive step forward.
Prior art in the field should be taken into account during the process
of examining patents. The next question is how.

Peer to Patent and related efforts such as href="http://www.articleonepartners.com/">Article One Partners
offer a powerful step toward a solution. Much of the tinkering
proposed in current debates, such as the number of patent examiners,
the damages awarded for infringement, and so forth (a bill was
debated in the Senate today, I've heard), will accomplish much less to
cut down the backlog of 700,000 applications and improve outcomes than
we could achieve through serious involvement of public input.

I am not a zealot on the subject of software patents. I've read a lot
of patent applications and court rulings about patents (see, for
instance, my href="http://www.praxagora.com/andyo/article/patent_bilski_aftermath.html">
analysis of the Bilski decision) and explored the case for
software patents sympathetically in href="http://radar.oreilly.com/archives/2007/09/three_vantage_p.html">another
article. But I have to come down on the side of position that
software and business processes, like other areas of pure human
thought, have no place in the patent system.

Maybe Rivest, Shamir, and Adleman deserved their famous href="http://www.google.com/patents?vid=4405829">patent (now
expired) on public-key cryptography--that was a huge leap of thought
making a historic change in how computers are used in the world. But
the modern patents I've seen are nothing like the RSA algorithm. They
represent cheap patches on tired old practices. Proponents of software
patents may win their battle in the halls of power, but they have lost
their argument on the grounds of the patents to which their policy has
led. Sorry, there's just too much crap out there.

Don't be the product, buy the product!

Schweinderl