Software, Abstractness, and Soft Physicality Requirements

Abstract

TABLE OF CONTENTS I. INTRODUCTION II. SOFTWARE PATENT HISTORY AND PROBLEMS A. Current Standards B. Software Patent Problems 1. The Patent System Does Not Suit Software 2. The USPTO Is Ill-Equipped 3. Software Patent Thickets 4. Software Patents Are Easily Abused III. SOFT PHYSICALITY REQUIREMENTS AND SOFTWARE IV. SOFT PHYSICALITY IN OPERATION A. Precedent and Soft Physicality B. Tailored Standards in Other Jurisdictions V. ARGUMENTS AGAINST SOFT PHYSICALITY REQUIREMENTS A. Not All Software Is Abstract B. The Alice Framework Is Sufficiently Limiting VI. CONCLUSION I. INTRODUCTION Many commentators claim the fundamental problem with software patents is their low quality, which facilitates abuse. (1) Patent trolls, which are generally described as entities that assert patent infringement claims but do not produce or commercialize the patented inventions, are often the ones that abuse low quality patents. (2) Scholars and legislators alike have proffered solutions to curb abuse by patent trolls. (3) These attempts, however, may simply act to soothe the symptoms of a more fundamental illness. The patent troll problem has been characterized as stemming from software patents. (4) A study by the Government Accountability Office found that from 2007 through 2011 the number of defendants in patent lawsuits more than doubled, and software patents accounted for eighty-nine percent of the increase. (5) To combat this problem, some have advocated completely barring software patents. (6) However, such visceral reactions may stem from focusing too much on the fact that the actors abusing software patents are frequently patent trolls, which obscures the root problem that the low quality of many software patents is what makes them easy to abuse. (7) This Note argues that the problem arises from insufficient legal guidance. The United States Patent and Trademark Office (USPTO) should proactively address this issue by adopting soft physicality requirements for the approval of software patents. This proposal allows for the patenting of certain software, but forces the patentee to limit the scope up front by requiring a tie into essential hardware or computing platform(s). Other highly innovative nations have similarly used special industry-specific hurdles to software patenting. (8) Accordingly, this Note will also discuss the Japanese patent system and explore what lessons can be learned from that model. The Note begins by discussing the history, current eligibility standards, and problems associated with software patents in Part II. In Part III, the specific proposal is developed and described. The merits of the proposal and precedential support are discussed in Part IV. Criticism is briefly discussed in Part V. Part VI concludes. II. SOFTWARE PATENT HISTORY AND PROBLEMS In the late 1960s, the USPTO took a hard anti-software stance, issuing examination guidelines in 1968 that held computer programs generally unpatentable. (9) A programmed computer, however, could be part of a patentable process (10) if combined with unobvious elements to produce a physical result. (11) Despite the strong directive from the USPTO on the ineligibility of software patents, the Court of Customs and Patent Appeals (CCPA) (12) held in favor of the patentability of software. (13) With this tension, the Supreme Court intervened in a pair of landmark cases during the 1970s: Gottschalk v. Benson and Parker v. Flook. (14) In Benson, the Court fell back on precedent, holding that phenomena of nature, mental processes, and abstract ideas are unpatentable (15) and finding that the claim in question was so abstract and sweeping as to cover both known and unknown uses of the mathematical algorithm in question. (16) A primary concern of the Court was that granting such a patent would wholly pre-empt use of the formula and allow for its monopolization. …