Software and Patent Scope: A Report from the Middle Innings

In the 1980s and early 1990s, it was commonly said that patents would severely damage the software industry. I review some of these early predictions and hold them up to the light of actual experience. However judged-by overall industry revenues, by product innovation, or by vibrancy of new firm entry-the industry today appears quite robust. I conclude that the early predictions were wrong. This helps explain why we are experiencing what might be called the "normalization" of software patents. Now, the frontier legal issues pertaining to software no longer center on whether it should be patentable in the first place. Post-State Street Bank, the interesting questions now concern the details and contours of patent protection for software inventions. As with other technologies, the breadth or scope of software patents is a crucial issue. One of the several doctrines that collectively determine a patent's scope is the "written description" requirement in patent law. I briefly review the rise of this doctrine after 1995, arguing that in many cases the new doctrine is redundant: traditional principles of enablement are often a better ground for decision. One exception is the line of cases involving "misappropriation by claim amendment," but even here a modest extension of enablement principles would achieve a fair result without the cumbersome apparatus of written description. I then look in detail at the recent LizardTech case, which applied the written description requirement to a software patent. This serves as an interesting case study in how software firms are acquiring and using patents in their competitive strategies. The overall theme of the Article is normalization: the legal system is integrating software into the fabric of patent law, and software firms are integrating patents into the competitive fabric of the industry. Proper application of enablement principles will help insure reasonable scope for software patents and thus assist this process of normalization. I. Introduction I started studying and teaching1 patent law in 1988. At that time, software patents were just beginning to seep out from the back currents and ease into the mainstream. I will not bore the reader with a case-by-case account of this long process. Suffice it to say: with the persistence of rabbits in a field or termites in a fallen tree, software patents just kept showing up. Finally, perhaps exhausted with the business of drawing lines around software inventions in a futile attempt to keep them out of the domain of patents, the Federal Circuit threw in the towel in 1998. And, as so many predicted, apres State Street Bank} le deluge. Software applications, and then of course issued patents, increased dramatically. Today they are commonplace. This brief Article surveys the post-deluge scene in the software industry. Though there are many - and I mean many - interesting predictions and provocative hypotheses in the vast literature on the topic, I will limit myself to two observations about how patents have affected the industry, which I will make in Part II. For good measure, or just to stir things up, I will add a conjecture about the future. Observation number one is straightforward: the software industry is thriving rather than dying. Whatever else patents have done or not done to this industry, they have not killed it. Observation two explains why: legal issues are of secondary importance. The major driving forces in the industry, technological change and widespread capital availability, simply swamp whatever marginal effects law might be exerting. This leads to the conjecture: my educated guess is that patents over business methods will follow roughly the same trajectory. With perhaps a few carve outs for particularly problematic subject matter (such as patents on tax strategies), business method patents seem destined to become a regular feature of the commercial landscape in the coming years. The same problems of line drawing we saw with software are already appearing in this area. …