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.