Donna Wentworth
( Archive | Home | Technorati Profile)

Ernest Miller
( Archive | Home )

Elizabeth Rader
( Archive | Home )

Jason Schultz
( Archive | Home )

Wendy Seltzer
( Archive | Home | Technorati Profile )

Aaron Swartz
( Archive | Home )

Alan Wexelblat
( Archive | Home )

About this weblog
Here we'll explore the nexus of legal rulings, Capitol Hill policy-making, technical standards development, and technological innovation that creates -- and will recreate -- the networked world as we know it. Among the topics we'll touch on: intellectual property conflicts, technical architecture and innovation, the evolution of copyright, private vs. public interests in Net policy-making, lobbying and the law, and more.

Disclaimer: the opinions expressed in this weblog are those of the authors and not of their respective institutions.

What Does "Copyfight" Mean?

Copyfight, the Solo Years: April 2002-March 2004

a Typical Joe
Academic Copyright
Jack Balkin
John Perry Barlow
Blogbook IP
David Bollier
James Boyle
Robert Boynton
Brad Ideas
Ren Bucholz
Cabalamat: Digital Rights
Cinema Minima
Consensus @ Lawyerpoint
Copyfighter's Musings
Copyright Readings
CopyrightWatch Canada
Susan Crawford
Walt Crawford
Creative Commons
Cruelty to Analog
Culture Cat
Deep Links
Derivative Work
Julian Dibbell
Digital Copyright Canada
Displacement of Concepts
Downhill Battle
Exploded Library
Bret Fausett
Edward Felten - Freedom to Tinker
Edward Felten - Dashlog
Frank Field
Seth Finkelstein
Brian Flemming
Frankston, Reed
Free Culture
Free Range Librarian
Michael Froomkin
Michael Geist
Michael Geist's BNA News
Dan Gillmor
Mike Godwin
Joe Gratz
James Grimmelmann
Groklaw News
Matt Haughey
Erik J. Heels
Induce Act blog
Inter Alia
IP & Social Justice
IPac blog
Joi Ito
Jon Johansen
JD Lasica
Legal Theory Blog
Lenz Blog
Larry Lessig
Jessica Litman
James Love
Alex Macgillivray
Madisonian Theory
Maison Bisson
Kevin Marks
Tim Marman
Matt Rolls a Hoover
Mary Minow
Declan McCullagh
Eben Moglen
Dan Moniz
Danny O'Brien
Open Access
Open Codex
John Palfrey
Chris Palmer
Promote the Progress
PK News
PVR Blog
Eric Raymond
Joseph Reagle
Recording Industry vs. the People
Lisa Rein
Thomas Roessler
Seth Schoen
Doc Searls
Seb's Open Research
Shifted Librarian
Doug Simpson
Stay Free! Daily
Sarah Stirland
Swarthmore Coalition
Tech Law Advisor
Technology Liberation Front
Siva Vaidhyanathan
Vertical Hold
Kim Weatherall
David Weinberger
Matthew Yglesias

Timothy Armstrong
Bag and Baggage
Charles Bailey
Beltway Blogroll
Between Lawyers
Blawg Channel
Chief Blogging Officer
Drew Clark
Chris Cohen
Crooked Timber
Daily Whirl
Dead Parrots Society
Delaware Law Office
J. Bradford DeLong
Betsy Devine
Ben Edelman
Ernie the Attorney
How Appealing
Industry Standard
IP Democracy
IP Watch
Dennis Kennedy
Rick Klau
Wendy Koslow
Elizabeth L. Lawley
Jerry Lawson
Legal Reader
Likelihood of Confusion
Chris Locke
Derek Lowe
MIT Tech Review
Paper Chase
Frank Paynter
Scott Rosenberg
Scrivener's Error
Jeneane Sessum
Silent Lucidity
Smart Mobs
Trademark Blog
Eugene Volokh
Kevin Werbach

Berkman @ Harvard
Chilling Effects
CIS @ Stanford
Copyright Reform
Creative Commons
Global Internet Proj.
Info Commons
IP Justice
ISP @ Yale
NY for Fair Use
Open Content
Public Knowledge
Shidler Center @ UW
Tech Center @ GMU
U. Maine Tech Law Center
US Copyright Office
US Dept. of Justice
US Patent Office

In the Pipeline: Don't miss Derek Lowe's excellent commentary on drug discovery and the pharma industry in general at In the Pipeline


« Patent "Monetization" Entities... Which is to Say, Trolls | Main | No Kidding, Matt »

April 16, 2013

At Least They're Asking the Right Question

Email This Entry

Posted by Alan Wexelblat

After a variety of efforts at what I've termed "downstream" fixes to the patent problem, the EFF appears finally to be turning its attention to the source of the mess, issuance by the PTO. The blog post by Daniel Nazer is titled "EFF Politely Asks PTO to Stop Issuing So Many Crappy Software Patents."

Take out the word 'software' and I'd be in complete agreement. Bad software patents have gotten a lot of attention lately but rules for reforming patent examination and issuance need to be universal. You can't just single out bad software patenting practices and ignore errors if they are happening in hardware, biotech, etc. The EFF do focus on a problem that is endemic to software patents - overbroad claiming. In most other fields of patent arts it's necessary for the invention to be narrowly described and for the patent only to protect the specific claims. For example, if I patent a medicine to cure headaches I am given protection only on the specific medicine I disclose in the patent, not on the entire field of headache cures.

The post also renews EFF's earlier calls for source-code submission, with which I sympathize but I think will make more trouble than it solves. For example, what language(s) will be accepted? And how will you prove that two source code submissions are or are not equivalent? I haven't looked lately but I think proof of program equivalence is an NP-hard problem to solve. Really, though, you don't care about the code. You care about the algorithm the code implements, and we have some pretty well-understood ways to describe algorithms without reducing them to specific code forms. Yes, it may take a certain level of skill to understand non-textual algorithmic representations but we ought to expect the examiners of software patent applications to be able to read those, just as we expect other examiners to be able to read mathematical equations, or chemical reaction formulae.

Comments (4) + TrackBacks (0) | Category: Big Thoughts


1. Cory Doctorow on April 17, 2013 11:40 PM writes...

Why is code equivalence important? Proving that two mechanical devices aren't equivalent is also often an impossible task, but the patent office still required working models for them.

Permalink to Comment

2. Alan Wexelblat on April 18, 2013 2:59 PM writes...

Code equivalence is important because what the EFF is asking - where I think they get it right - is functional protection. If I take the typical C-language "Hello World" program and implement it in C++ or Java or Perl or whatever it's still the "same" program, in the sense that it performs the same function. If we imagine that I got a patent on Hello World and I submit my C-code example then someone else might submit a patent with their Perl-code version and unless we can say "these are the same program" then it's hard to determine if theirs is patent-eligible or not.

Patents on (physical) machines must be accompanied by drawings to a certain standard and must expose and enumerate the parts and processes of the machine that are protected. Equivalence isn't important because of the functional nature of the machine patent. If I have, say, a patent on a rocking chair and I submit drawings of a rocking chair made of wood, then someone else's submission of a different isn't compared based on whether the machines are identical, but whether they perform the same arc-describable rocking motion.

My argument is that removing source code and replacing it with a language-independent algorithm description is the same thing in code space as we already have in physical-machine space.

Permalink to Comment

3. Cory Doctorow on April 20, 2013 12:59 AM writes...

But code equivalence isn't the only reason to request source, right? It's also to prove that you can actually do the thing you claim you're patenting. It's the difference between claiming that you have code that proves P=NP and running the code that proves P=NP. If you can't implement it, why allow you to patent it?

Permalink to Comment

4. Alan Wexelblat on April 22, 2013 10:27 AM writes...

The "working machine that demonstrates" requirement for patents went out a long time ago. Biopharma people don't submit molecules, they submit chemical descriptions of molecules and claims as to the molecules' effects.

In order to make code the determinant of whether an idea has been reduced to practice and patentable you would have to submit not only your code, but everything else that is required to make that code run (hardware, OS, compiler/linker/assembler, makefiles, etc). The code itself may be desk-inspected to some degree but no program of any reasonable complexity can be fully understood that way.

This would also bring in several weird peripheral effects; for example, if your code only works with a certain set of optimizer flags on gcc and fails with every other combination of flags does that matter? Have you really invented what you claim if you rely on a very specific set of factors to demonstrate it? Does requiring code as proof mean that I can't patent a method that only runs on specific proprietary hardware (e.g. a control system)? What if the code I sent in has a bug? Does that invalidate my invention.

Et cetera. Code raises WAY more questions than it settles.

Permalink to Comment


Remember Me?


Email this entry to:

Your email address:

Message (optional):

Is There an Independent "Right of Performance"?
Did the Director-General of WIPO Steal Employee DNA Samples?
More Evidence People Don't Learn from the Past
Phoenix (music) Supports Free Use
Robo-Papers "Flooding" Academic Conferences
Apple Appeals
Who's Taking All That Money?
Pointing the Troll Finger in the Correct Direction