The USPTO has posted the day's agenda for the February 16th meeting regarding the Open Source as Prior Art and Open Patent Review initiatives. It begins at 10 AM and runs until 2 PM. Directions. You can't just show up, though, and be sure of getting in. You must register by email to guarantee a seat.
The Open Source as Prior Art segment begins at 10:15, so please don't be late. That is the one I am most interested in hearing about. One of the things listed for that segment is the following goal: "Identify interest and resources for ongoing effort." The Patent Review segment is at 11:15.
Since patents are the future battleground, from all we can discern, we might as well keep on adding to our armor and our knowledge. That is why I'm making myself read books on patents. Groan. Not my first choice of reading material. But you can't be effective unless you are equipped.
Here are two presentations from the December meeting with the USPTO that led to the decision to try to work together with the OS community to fix some of what's broken, at least the parts we don't need Congress for.
The first presentation [PDF], Open Source as Prior Art, by Kees Cook of OSDL, addresses what is needed for a prior art database to count as prior art. It lists all the places that currently have databases, but it points out some problems. Kernel.org, for example, allows a publisher to change time stamps, and others don't stop a publisher from deleting a release. In other contexts, both might be all right, but in the context of wishing to prove something is prior art, both are a problem. See what I mean about knowledge?
The second presentation [PDF] is by the USPTO, and it explains the basics of what qualifies as prior art and what would be useful to the USPTO for search purposes.
Reading them both will help you to prepare for the February meeting. The agenda mentions that at 12:45, there will be a summing up of the identified patent quality initiatives, and at 1:15
there will be a segment for any other ideas you may have on improving patent quality. Deep sixing software patents isn't on the list for this particular day's discussion, so don't waste time bringing that up on the 16th but do save that idea for another forum, another day. This particular agenda is about trying to solve some of the worst problems in the current system, which neither I nor the USPTO can change by Wednesday. Only Congress can change the complete patent system. What can happen, if the USPTO is serious, is fixing the worst offenses, which are real and which are causing real pain. Unnecessary pain. So if you have ideas on that, February 16 is the day. And what I'd really like is if all of you who go, and I know of several already planning to attend, would give us at Groklaw feedback on your impressions.
Finally, please remember that the USPTO is going to be experiencing a measure of culture shock. Please be polite and help them to make the transition to collaboration with the community as smooth as possible. And when you write up your reports, one thing I'd like to know personally is, does the USPTO seem to be serious in intent? What are your impressions? There is a lot at stake here, and we need to evaluate what can be achieved.
Most of us are not patent experts, and it's my view that we need to become better educated on the subject, no matter what our ultimate solution to the patent problem might be. This meeting is, without a doubt, an opportunity to do that, to learn. Even if you say nothing at all at the meeting, you will learn more about the way things work, and that is always valuable. Even in warfare, the sides send out spies to spy out the land, do they not? Why do they do that? Because knowledge is power, and many eyeballs are the solution to lots of problems, so I'm looking forward to hearing from all of you who have the opportunity to go.
Finally, I know a few of you are worried that if we do the database of prior art, it will enable bad actors to fine-tune their patents and be more effective in attacking FOSS. I thought about that a great deal and did some brainstorming. Here's the piece that is missing in that concern. They still would have to make the case that their invention
was not obvious. One way to reduce their ability to make that case is to
get published and make accessible as many inventions and ideas in the
computer software invention world as possible. The more we put out there, in a database set up to meet the requirements to qualify as prior art, the more broadly
disseminated an idea, the more likely that idea bumps into other ideas that
are related or could become related, and the more obvious and logical the
connections are between them.