!041894 Software patenting "crisis" worsening To whatever degree you think that there is a problem in the area of software patenting, the problem is getting worse as the arguments rage back and forth. Consider the following weekly counts of new software patents issued for the first quarter of 1994: DATE COUNT -------- ----- 04/05/94 116 03/29/94 88 03/22/94 100 03/15/94 65 03/08/94 109 03/01/94 75 02/22/94 62 02/15/94 107 02/08/94 49 02/01/94 71 01/25/94 56 01/18/94 61 01/11/94 67 01/04/94 107 --- 1146 These figures trend to about 4500 software patents this year, double+ 1993. My estimate is that in 1994 and 1995, about 11,000 software patents will be issued. To put this in perspective, about 11,000 software patents had been issued from the early 1970's to the early 1990's. Thus as many new patents will be issued in the next two years as have been issued since the dawn of computer software engineering. In short, we have strong exponential growth in the number of software patents, and everything that derives from these patents, including lawsuits. Now it can probably be shown that the number of unobvious, novel, unpublished news ideas in the software world grows linearly at best. For example, most categories in my software patent classification scheme are as applicable now as are they for 1970's software patents, except for a few categories such as object oriented programming and virtual reality. Read Scientometrics to find about modeling these growths. Thus without even observing actual software patents, it is very likely that the difference between exponential patent growth and linear new idea growth implies a growingly large number of questionable software patents. Actual examination of many software patents confirms this, especially in light of the fact that there are over 20,000 additional software patents issued in foreign countries which add to the database of direct prior art. So while all of these arguments about software patents rage, the underlying administrative problem continues to get worse. Unfortunately, most of the suggestions put forth to deal with this problem probably will have little effect on the raw count of issued software patents, including: 1) Improving the operations of Group 2300 Group 2300 is the main computer technology examining group at the USPTO. While they are making efforts to better deal with software (especially by hiring more people with software experience as examiners), at best only half of all software patents are processed by their group. So unless the other examining groups coordinate their efforts with Group 2300, not much of a dent will be made in the growth of software patents. (About 10% percent of all new software patents are listed in the Mechanical section of the Official Gazette, to illustrate how widely distributed they are across PTO groups). 2) Requesting prior art information from the Internet There are two problems with this. First, multiply the number of patents for which information will be sought by the number of active participants on the Internet interested in software by some fraction of the hundreds of thousands of bibliographic references usuable as prior art, and the resulting flood of submissions from the Internet would swamp the Patent Office computer system and force examiners to spend lots of time they don't have sifting through all of this stuff. Second, such a request implies that examiners have exhausted the uses of information on hand, in particular, DIALOG searches. As an extreme case of why this is not so, for one particularly bad software patent issued last year, I was able to find over 500 references on DIALOG that undermined one or more, or all of the claims for the patent. While this is an extreme case, in general based on the excessive generality of current independent claims in software patents, PTO use of the resources on hand is not complete. Adding Internet resources thus does not presage better analysis of software patent applications. 3) Archiving software companies manuals and documentation If you prepare a classification tree of all software patents, and then for each branch representing a software technology area, make a model of the flow of ideas from academic/government/corporate research facilities through the trade press and conference circuit and finally through the filter of corporate acceptance vis-a-vis being productized, you will find that only about 5% of software patent prior art concerns require access to corporate manuals and documentation (and proving so is very good practice for preparing to build a software prior art database). So while at some point in time, collecting such materials will be useful and necessary, right now it is a waste of limited resources applicable to only a very small fraction of software prior art concerns. 4) Seeking the help of other government agencies A large volume of software prior art is the direct result of government funding of software research and development, either directly at government facilities, at universites or by corporate contractors. It is natural then to call upon these agencies (DoD/DoE/NASA/NSF/HHS/EPA/NIH) for assistance. Unfortunately, these agencies have had no more luck than anyone else over the past twenty years in terms of keeping track of what they have funded. 5) Ignoring hardware/software equivalence This actually isn't a proposed solution, but important nonetheless because no one is proposing solutions for it. You can now buy VHDL models of entire microprocessors that when run on VHDL simulator engines, can replicate the hardware microprocessor in software about 1000 times slower than for hardware execution. While large, in the nanosecond world of digital electronics, who cares? Thus when I see a basically hardware patent focused on the use of a microprocessor, I can easily infringe any potential commercial application by implementing the method completely in software with these VHDL models. As long as the underlying process, method or apparatus has at least multi-second timing cycles, it won't matter that the software VHDL microprocessor is much slower than the hardware microprocessor. The only way to prevent this infringement is to draft the claims so that hardware/software implementation details are buried symmetrically deep in the dependent claims, something you see with a growing number of neural network and signal processing patents, where the overlap is much more obvious, and you can rely on the Doctrine of Equivalents to ward off potential infringers. However, it applies everywhere, and it becomes increasingly difficult to avoid having to build a software/hardware prior art database. In my mind you can't, and I don't think about the issue anymore, just deal with it. What interests me now is research going on in self-replicating polymers. Within a few years, efforts here, along with algoritms derived from artificial life experiments (such as Tierra), will extend computing into a new domain whose prior art considerations will eventually require folding in the biotechnology prior art into computer hardware/software. Not an immediate problem, but an inevitable problem. -------------------- What should you expect in the next few years under current conditions? A lot more software patent infringement lawsuits. With venture pools being formed on Wall Street to finance infringement actions, cushioned slightly with patent infringement insurance, bad software patents become valuable for their nuisance value as the financial risk/reward ratio decreases. Of course, I protest too loudly, believing in the AAMCO-man philosophy :-) Greg Aharonian Internet Patent News Service