OSAPA initiative will combat unworthy software patents

11

Author: Diane M. Peters

The elusive open source prior art repository — attempted by several, failed at by all. What makes the Open Source as Prior Art (OSAPA) initiative, championed by OSDL, IBM, and others such as SourceForge.net, and announced by the USPTO Office in January, likely to succeed where others have failed? The answer can be found in the timely confluence of pressures on the different stakeholders, combined with an approach that leverages the existing resources and strengths of the open source community.

In theory, a prior art repository would be a central, comprehensive resource housing a vast amount of source code, information, and abstracts documenting the functionality of free and open source software in a way that could be searched by the US Patent and Trademark Office (USPTO) to locate potentially relevant prior art. The goal is laudable and difficult to argue against: prevent software patents from being issued if the inventions claimed were not novel or were obvious.

In the past several years, its biggest users have pressured the USPTO to reduce the time patent applications remain pending before final disposition from the current average of almost three years. At the same time, the USPTO has seen a sharp increase in public criticism about the quality of the patents it is issuing. By some estimates, more than 50% of all patents issued are of questionable quality because the examiners did not have access to, or did not correctly apply, relevant prior art. Top these pressures off with calls for legislative reform in Washington, and it becomes easy to see why the USPTO is motivated as never before to demonstrate progress on reducing the time patent applications remain pending.

Pressure is also building on the major players in the software industry. It is not lost on the development community (which, generally, disdains software patents) that companies such as IBM and others who promote open source software have some of the largest patent portfolios, and support software as patentable subject matter. Those companies are motivated to address the quality issue in part to be viewed as a friend to the community on which their businesses depend for success. Companies that promote proprietary software, such as Microsoft, similarly join the call for reform and an up-leveling of patent quality because of the business costs associated with defending against assertions of infringement made by holders of bad patents.

For the open source community, it is now widely understood that software patents, not unfounded assertions of copyright infringement like those threatened by The SCO Group, pose the greatest threat to software. That is particularly true now that open source software is mainstream and viewed as a real threat to traditional, proprietary software business models. With meaningful legislative reform in the US essentially halted for the foreseeable future, it is natural for the community to start looking harder at short-term and medium-term solutions to the software patent problem that has the potential to be their undoing.

All of these pressures, taken together, have motivated a broad spectrum of people, with sometimes different long-term objectives, to join forces on a handful of possible solutions to the quality issue, including the OSAPA initiative that is, as of this writing, concluding its second month of development. For the community of software developers desirous of a future without any software patents, it is the ideal time to leverage the pressures on the USPTO and industry players in order to reduce the number of software patents that are issued.

The keys to success

The approach to the OSAPA initiative is fundamentally different in several important respects from the prior art repositories attempted in the past. For starters, the solution, which consists of a methodology described in more detail below, is being developed by a broad community of individuals and companies in a collaborative, open forum. It is not being crafted in private, nor will it be pushed onto a community of developers who will then be expected to use it. Having ownership and control over the development process means the solution belongs to and is understood by the constituency that will be encouraged to use it.

A second feature is a natural outgrowth of the first — the developers participating in its creation are intent on making the solution useful for their own development purposes, separate and apart from any potential uses by the USPTO and patent practitioners. This is critically important, because it provides motivation for developers not only to participate in the development process, but more importantly to use the methodology once created. If developers don’t use what’s made, the initiative will not succeed.

The third differentiator lies in the design of the “repository” itself. Rather than attempting to aggregate source code, documentation, and abstracts in a single, centralized location, OSAPA depends on the existing code repositories to which developers currently publish source code, such as SourceForge.net, Kernel.org, CPAN, and many others. This has several benefits. Developers can continue publishing source code to the same repositories they have in the past — they need not change their behavior. This also reduces the likelihood that potentially relevant prior art will not be found; the process is designed to capture all source code, documentation, and abstracts wherever published, even on personal Web sites, provided it is published consistent with the methodology under development.

How it works

Although still in development, the methodology underlying the initiative is simple. Open source software developers electronically publish source code, documentation, and other information about their software to an existing repository such as SourceForge.net or perhaps their own independent Web site. At the time of publication, the developer attaches a tag to the package containing basic information about the software’s functionality, the author of the code, etc. The functionality is described using a taxonomy developed by the community with an eye toward the terminology and classifications used by patent examiners when searching for prior art in the computer software field. The package receives a time stamp when published, and the repository or Web site adheres to some established practices to help ensure the integrity of the package for evidentiary purposes. Patent examiners can then locate the art by the information contained in its tag when searching the repository itself or when searching through a public interface such as Yahoo! or Google.

All stakeholders benefit from this increased access to published software inventions. For patent examiners, the result is easier, faster access to potentially relevant prior art that can be used to evaluate the novelty or obviousness of inventions claimed in software patent applications. The art may be used to preclude the issuance of a software patent altogether, or limit the breadth of the claims made in the application. For the software industry, it means the software patents that do get issued are of higher quality and are, in theory, more valuable. It also means a reduction in the number of bad software patents carrying a presumption of validity and against which they must defend themselves. For the open source software community, it means an effective defensive publication tool that allows developers unable or not inclined to apply for a software patent to publish their inventions in a manner that helps ensure that others don’t patent them. And for everyone, it means fewer patents to navigate overall.

Pushing ahead

The OSAPA initiative is still in its earliest stages of development, yet its base of supporters continues to grow despite critics who complain about possible abuses or who label it a distraction. Admittedly, the OSAPA initiative is not a perfect solution, nor is it a complete solution. But it does help solve an identifiable problem with patent quality, and as a result is better than what we have now. Perhaps most promising of all, the initiative has managed to find common ground among stakeholders with interests that are traditionally adverse, and focused attention on a solution, albeit imperfect, that benefits everyone.

The USPTO continues to commit itself publicly to OSAPA’s success, and the success of other patent quality initiatives such as the Community Patent Review initiative, through its participation in working groups and public meetings. Look for a USPTO-sponsored meeting to take place this month, at which progress updates will be provided on these initiatives and more.

Diane M. Peters is general counsel for Open Source Development Labs, Inc.

Category:

  • Legal