Patent law's functionality malfunction and the problem of overbroad, functional software patents.

Author:Collins, Kevin Emerson
Position:III. Explaining Software-Patent Overbreadth through V. Conclusion, with footnotes, p. 1440-1471
 
FREE EXCERPT
  1. EXPLAINING SOFTWARE-PATENT OVERBREADTH

    This Part identifies the root cause of the problem of software-patent overbreadth. Part III.A argues that software is a purely functional technology in the sense that the structural properties of the software actually generated by an inventor should not define a protectable software invention. Part III.B identifies patent law's functionality malfunction: the invention-structure equation breaks down when it is brought to bear on technologies, like software, that are purely functional.

    1. Software Inventions Are Functional All the Way Down

      Software is commonly described as exceptional or different from other patentable inventions, and one of the factual premises frequently put forward to justify software exceptionalism is that software is "intangible." (180) Early courts questioning the patentability of software inventions analogized software to the supposedly intangible mental processes that occur within human minds, (181) and the Freeman-Walter-Abele test for patentable subject matter labeled software-executed processes as non-physical. (182) More recently, the Federal Circuit used the assumption that software is intangible to question the patentability of software inventions under the machine-or-transformation test. (183)

      However, the embodiments of software programs that are capable of infringing software patents are clearly material, worldly entities. (184) Software does not violate the materialist worldview: it is the physical structure of software loaded onto a computer that endows software with its behavioral capacities. (185) Software exists as electrons or charges on a hard drive or in a computer's memory; a computer implements a software program only because a particular set of gates in the processor is open or closed. (186) While likely intended metaphorically, the statement that "[p]rogram text is, thus, like steel and plastic, a medium in which other works can be created" is literally true in that an operable embodiment of a software program exists only because it is crafted from a tangible medium. (187)

      Yet, despite the materiality of embodiments of software inventions, there is a grain of truth buried in the assertion that software is intangible in a way that makes software anomalous among patentable subject matters. Software programs may not lack materiality, but their materiality is irrelevant to identifying, delineating, or defining protectable software inventions. Assume a computer programmer has just invented a new software program. How can the inventor describe or define what he has invented? The programmer would be hard pressed to convey the gist of what he had invented by referring to any of the physical, structural properties of the software.

      [F]or all practical purposes the programmer and others who think about and describe the program have no practical choice but to conceive of and describe it in terms of its logical structure [or function]....It is far from clear that it would even be possible for the human mind to appreciate the physical structure of all but the simplest programs or to explain them in terms of their physical structures. (188) The irrelevance of the physical, structural properties of a software embodiment to the definition of a software program has been engineered into the very nature of software itself at the most fundamental of levels. The core value of software lies in the fact that the design of software that possesses any given set of logical, functional properties need not involve any consideration of the physical properties of the hardware or the distribution of electrical charges therein: "Computers are understandable because you can focus on what is happening at one [functional] level of the hierarchy without worrying about the details of what goes on at the lower [structural] levels." (189) A software program can be implemented in entirely different code in the same programming language or in an entirely different language, (190) and there is no common thread of physical, structural properties that runs through these distinct codings. Thanks to interpreters and compilers, any given program can be implemented on a wide array of different computers, each possessing a different internal architecture and requiring the software to take on different physical, structural properties. (191) In fact, "[p]resent-day computers" on which software programs are executed "are built of transistors and wires, but they could just as well be built, according to the same principles, from valves and water pipes, or from sticks and strings." (192) Furthermore, hardware and software implementations of any given program are functionally interchangeable despite their radically different structural properties. (193)

      The behavioral capacities of a computer program--that is, "the actions that a computer can perform by executing program instructions"--are central to the definition of a computer program. (194) Standing alone, however, the importance of the functional properties does not differentiate software from other patentable technologies. A pharmaceutical drug is valued by a consumer more directly for what it does (cure a disease) than for its molecular structure; a patient cares that a drug has a particular molecular structure only because that structure has a metabolic function. (195) What is unique about software is not the significance of functionality per se but rather the insignificance of physical structure: it is practically impossible to refer to a set of structural characteristics shared by the embodiments of a software invention. (196) It is for this reason that "[b]ehavior is not a secondary by-product of a program, but rather an essential part of what programs are." (197)

      In short, software is exceptional. The key to software exceptionalism lies in a weak form of the software-is-intangible argument. Although they exist, the physical, material properties of an embodiment of a software invention are not relevant to what constitutes a protectable software invention or thus to the optimal scope of a software claim. Viewed from the opposite perspective, software is a purely functional technology on all relevant levels of definition. (198) The ontology of invention is thus reversed in the software arts. In most arts, an invention "is" its structure, not its function. (199) In the software arts, however, an invention "is" its function, not its structure. A software invention is function "all the way down." (200)

    2. The Functionality Malfunction

      There is a fundamental mismatch between the invention-structure equation that patent law has traditionally employed to curtail the scope of functional claims and the purely functional nature of software inventions. The invention-structure equation enables courts to rein in the overbreadth of functional claims. Because protectable inventions are defined by some subset of the structural properties of the technology that an inventor has generated, purely functional claims are overbroad and invalid. (201) Software inventions, however, are purely functional entities. The material, structural properties of a software program are not relevant to the definition of a protectable software invention or the optimal scope of a software claim. (202) Software inventions therefore lack the metaphorical bolt onto which patent law's conventional scope-restraining doctrinal tools (or "policy levers" (203)) can attach to gain purchase and curtail permissible claim scope in a systematic manner. This is patent law's functionality malfunction: the patent doctrines that have traditionally curtailed claim overbreadth break down when they are brought to bear on purely functional technologies. The invention-structure equation simply cannot get a grip on the problem of the overbreadth of functional claims in the software arts as there are no relevant physical, structural properties to grab onto and require as claim limitations.

      The functionality malfunction places judges and examiners between a rock (too little protection) and a hard place (too much protection) in the software arts. Enforcing the invention-structure equation by requiring the recitation of physical, structural properties as claim limitations would yield absurdly narrow, economically irrelevant claims. Unclaimed, perfect economic substitutes would abound, (204) and the private value of a software patent to its owner would most likely not be worth the private cost of obtaining the patent. Software patents would wither on the vine. Alternatively, if the courts were to exempt software from the invention-structure equation and sanction purely functional software claims, then the very functional claims that are deemed to be overbroad and invalidated in other arts would be an expected feature of software patents. (205) As early commentators on the patentability of software inventions noted,

      [I]f the Patent and Trademark Office were willing to issue a patent with claims for any means of achieving a particular set of results, such a patent would issue at a high level of generality and would inhibit competition in development of useful program behaviors out of proportion to the innovation actually contributed by the claimant. (206) Confronted with this choice between patent protection that is either too hard or too soft, the courts have clearly chosen too soft. Inventors routinely seek, and courts routinely sanction, purely functional software claims. For an anecdotal illustration of the purely functional nature of most contemporary software claims, consider claim 22 of patent number 5,231,670. (207) Claim 22 describes a voice-recognition technology that allows a user to create a text file by uttering both the words that are the substance of the text ("spoken input") and commands that trigger functional responses from the software that one could otherwise trigger by using pull-down menus or keyboard shortcuts ("spoken commands"). (208) In its entirety...

To continue reading

FREE SIGN UP