.What Can The Software Patent Institute Accomplish?
.   by the League for Programming Freedom (14 April 1993)

Software patents are patents which can apply to (and thus prohibit)
writing a program.  Any software patent can cause trouble for people
who want to develop software.

Some software patents are Patent Office mistakes which cover things
that are already known.  In some cases (but not all), these mistakes
can be proved based on published prior art.

Other software patents do not result from errors of the system, but
are still disadvantageous to software development.  How much trouble a
software patent causes is independent of whether it violates the
patent system's own rules.  And the sheer number of software patents
causes trouble regardless of their details.

The Software Patent Institute is a new organization that aims to
produce a data base of "prior art"--published and known software
ideas--to make it easier for the Patent Office and others to find out
which software techniques and features are already known and thus
supposed to be unpatentable.

The SPI cannot prevent all patents which harm the software field.  It
can only prevent a certain kind of Patent Office mistake: overlooking
prior art whose prior publication can be proved.  Thus, the SPI can
address only a fraction of the software patents that cause trouble for
programmers.

Even perfect knowledge of prior art would not prevent all absurd
software patents.  Some software patents cover such trivial matters
that a description of the idea would be reject by any professional
technical journal.  For example, patent number 5,049,881, issued in
1991, covers modifying the way a data compression program uses a hash
table to look up the strings that have assigned encodings:
specifically, when it has found the hash bucket for a string being
looked up, it considers only the first string in the bucket as a
possible match, rather than all of them.  Patent number 5,140,321,
issued in 1992, covers checking just the first N strings in the hash
bucket as possible matches.  (Both of these modifications apply to a
particular data compression algorithm, and similar modifications could
probably be patented for any other algorithm.)

To ask whether those particular variations were published before, is
to miss the point---it is a mistake for patent system decisions to
depend on such questions.  But those questions are the only ones that
the SPI can help answer.

No matter how well the published prior art is known, it cannot include
all variations, and under current policy, many of these can be
patented.  What's more, you cannot effectively challenge decisions
about obviousness in court, because the courts presume that the Patent
Office has exercised good judgement when deciding what is obvious.

But suppose that the Patent Office learns how to judge obviousness
better; then how much good can the SPI do?  Even if this prevents a
sizable fraction of future software patents, that will not appreciably
reduce the problem that software patents cause for programmers.

Even cutting the number of software patents in half (which would be
great success for the SPI!) will not cut the problem in half.  This is
because a large software system is likely in the future to infringe a
large number of patents--easily dozens.  Even if half of them were
eliminated, the remaining half could still create prohibitive
problems.

There is no official figure for the number of software patents we have
today, but 5000 or 6000 is a likely estimate given past numbers and
trends.  (To find them all would be a mammoth task.)  At the beginning
of 1992 there were 9000 pending patent applications in a category
which contains many software patents, which suggests there will be
many more software patents in the future.  To make software
development a safe activity again, we must do more than cut the number
of patents in half.  Eliminating 90% of the software patents that
exist today would just reach the level where further reduction starts
to help matters.  (See the LPF's position paper, "Against Software
Patents," for more explanation of why software patents in general
cause mainly trouble, even those that are not trivial.)

While the SPI may prevent some software patents from being issued,
ironically it may also make some patents more dangerous by helping the
patent applicant design the patent to withstand legal challenges.
Even the holders of existing patents can use this information to
rewrite the patents and make them harder to overturn.  For more
information, see the companion paper, "What Should You Do With Prior
Art?"

The SPI is supported by large companies such as IBM, Apple and DEC
that can expect to have many software patents, and by patent law
firms.  It is not likely these sponsors would support the SPI if they
expected it to prevent most software patents.

The interface proposed for the SPI's database will resemble those of
Westlaw and Lexis; it seems to be aimed at use by lawyers, not
software developers.  The SPI plans to raise revenue by charging for
access to the data base, which suggests that in practice it may
available primarily to larger companies.

The operation of the SPI will not alter the overall software patent
problem.  So wish the SPI good luck in preventing a few absurd
software patents; but don't spend your time on the SPI.  Instead,
spend it telling our lawmakers that software patents are harmful and
should be abolished.
