|
2003 UCLA J.L. & Tech. 7 |
||||||||||||||||||||
|
Computer Programming and the Automation of Invention: |
||||||||||||||||||||
|
||||||||||||||||||||
|
Footnotes 1. Mr. Plotkin is a solo practitioner with a practice emphasizing intellectual property protection for computer hardware and software. The author gratefully acknowledges the research assistance provided by Meleena Bowers, Esq. in the preparation of this paper. The author also wishes to thank Melissa Hoffer for the insightful and invaluable feedback she provided on the topics addressed herein. The author is also grateful for feedback provided by Professors Harold Abelson, Archon Fung, and Michael Martin, and Attorneys Peter Gordon and Larry Kolodney. Finally, the author wishes to thank Professor James Moor, the Nelson A. Rockefeller Center at Dartmouth College, and the Dartmouth Lawyers Association (DLA) for providing the author with an opportunity to present some of the ideas contained herein as part of the DLA’s Law Speaker Series in the spring of 2003.2. The debate dates back at least to 1965, when President Johnson commissioned a comprehensive study of the United States patent system. The Commission explored a wide range of pressing issues facing the patent system and recommended, among other things, that “no patents on . . . computer programs” be issued. 1966 Report of the President’s Comm’n on the Patent Sys. 1. The Supreme Court first wrestled with software patentability in Gottschalk v. Benson, 409 U.S. 63 (1972). For an overview of the history of software patents, see, e.g., Gregory A. Stobbs, Software Patents 1-46 (2d ed. 2000). For information on some of the history of copyright protection for software, see, e.g., Pamela Samuelson, CONTU Revisited: The Case Against Copyright Protection for Computer Programs in Machine-Readable Form, 1984 Duke L.J. 663 (1984). 3. See, e.g., James R. Goodman et al., Toward a Fact-Based Standard for Determining Whether Programmed Computers are Patentable Subject Matter: The Scientific Wisdom of Alappat and Ignorance of Trovato, 77 J. PAT. & TRADEMARK OFF. SOC’Y 353 (1995) (arguing that the particular manner in which computers are programmed using software distinguishes software from other technologies in a way that is relevant to patent law); see also Symposium: Toward a Third Intellectual Property Paradigm: A Manifesto Concerning the Legal Protection of Computer Programs, 94 Colum. L. Rev. 2308, 2327 (1994) (arguing that computer “programs are machines that happen to have been constructed in the medium of text” and therefore differ from other kinds of machines and other kinds of textual works for purposes of intellectual property protection); Samuelson, supra note 2, at 663 (arguing that computer program code is functional and therefore should not be subject to copyright protection, but rather should be subject to a new form of intellectual property protection). 4. See Donald S. Chisum, Patents, A Treatise on the Law of Patentability, Validity and Infringement § 4.01 (Matthew Bender ed., 2000) [hereinafter Patents]. 5. The subject matter copyright law protects is defined in 17 U.S.C. § 102(a) (2002): “Copyright protection subsists…in original works of authorship fixed in any tangible medium of expression . . .” 17 U.S.C. § 102(b) expressly excludes from copyright protection, inter alia, procedures, processes, systems, and methods of operation, which are within the purview of patent law. See also Symposium: Toward a Third Intellectual Property Paradigm: Misappropriation as a Third Intellectual Property Paradigm, 94 Colum. L. Rev. 2594, 2597 (1994) (“[P]atent law protects creative but functional invention, while copyright protects creative but nonfunctional authorship.”). 6. See, e.g., Vincent Chiappetta, Patentability of Computer Software Instruction as an “Article of Manufacture”: Software as Such as the Right Stuff, 17 J. Marshall J. Computer & Info. L 89, 143 (1998) (arguing that “[a] proper test for patentability of software related inventions must clearly and consistently draw a line separating claims to software as the specific means for computer system implementation of the contained algorithms/processes (which are patentable subject matter) from those using a software context merely to express and communicate those algorithms/processes (which must be tested on their own merit independently of the software context to determine if they involve patentable subject matter).”). 7. See, e.g., Pamela Samuelson, Symposium: The Semiconductor Chip Protection Act of 1984 and its Lessons: Creating a New Kind of Intellectual Property: Applying the Lessons of the Chip Law to Computer Programs, 70 Minn. L. Rev. 471, 516 (1984) (noting that, with one exception, patent and copyright protection were mutually exclusive prior to the advent of software); Randall Davis et al., A New View of Intellectual Property and Software, Communications of the ACM, Mar. 1996, at 124-45. 8. . For discussions of dual and hybrid approaches, see generally Symposium: Toward A Third Intellectual Property Paradigm: Legal Hybrids: Beyond Property And Monopoly?, 94 Colum. L. Rev. 2630 (1994); see also Symposium: Toward A Third Intellectual Property Paradigm: Legal Hybrids Between The Patent And Copyright Paradigms, 94 Colum. L. Rev. 2432 (1994); John Swinson, Copyright or Patent or Both: An Algorithmic Approach to Computer Software Protection, 5 Harv. J.L. & Tech. 145 (1991); John M. Griem, Jr., Note: Against a Sui Generis System of Intellectual Property for Computer Software, 22 Hofstra L. Rev. 145 (1993); Gregory J. Maier, Software Protection – Integrated Patent, Copyright and Trade Secret Law, 28 IDEA 13 (1987); Daniel G. Feder, Computer Software: Hybrid Technology Demanding a Unique Combination of Copyright and Patent Protection, 59 UMKC L Rev. 1037 (1991). 9. See, e.g., Allen B. Wagner, Patenting Computer Science: Are Computer Instruction Writings Patentable?, 17 J. Marshall J. Computer & Info. L. 5 (1998) (“[P]atents and copyrights are mutually exclusive statutory interests with no overlap in ‘abstract expression’ subject matter.”); Robert A. Kreiss , Patent Protection for Computer Programs and Mathematical Algorithms: The Constitutional Limitations on Patentable Subject Matter, 29 N.M.L. Rev. 31, 77 (1999). For an overview of the issues related to mutual exclusivity of patent and copyright protection for software, and an argument against such mutual exclusivity, see David A. Einhorn, Copyright and Patent Protection for Computer Software: Are They Mutually Exclusive?, 30 IDEA 265 (1990); Pamela Samuelson, Benson Revisited: The Case Against Patent Protection for Algorithms and Other Computer Program-Related Inventions, 39 Emory L.J. 1025, 1128-9 (1990). 10. See infra Sections II and III. 11. See infra Sections IV and V. 12. The term “executable” means “[c]apable of being run on [a] computer.” Webster’s New World Computer Dictionary 341 (9th ed. 2001). 13. The terms “software program” and “computer program” are used interchangeably herein. 14. I assert that an executable software program “may be” a machine component because a particular executable software program may or may not be a machine component depending on the function performed by the software. For a more detailed justification of this position, see infra Section V.B.1. 15. I use the term “electromechanical” to mean “electrical, mechanical, or a combination of both.” 16. See infra Section II. 17. By “successfully be designed” I mean that an executable software program may be built automatically based solely on a design that specifies the software program in terms of its logical structure. In other words, the “success” of the design process depends on the ability to construct a working embodiment of the software program based on the design specification that results from the design process without the exercise of any additional creative effort by a human being. 18. See infra Section II. 19. See infra Section V. 20. For dictionary definitions of “software” see Merriam Webster’s Collegiate Dictionary 1117 (10th ed. 1993) (defining software as “something used or associated with and usu. contrasted with hardware,” such as “the entire set of programs, procedures, and related documentation associated with a system and esp. a computer system”); Webster’s New World Computer Dictionary, supra note 12, at 341 (defining software as a “computer program or programs, in contrast to the physical equipment on which programs run (hardware))”; Microsoft Computer Dictionary 489 (5th ed. 2002) (defining software as “[c]omputer programs; instructions that make hardware work”). 21. See, e.g., Griem, supra note 8, at 154 (“Where the mechanical engineer uses pumps and pulleys to manipulate physical objects, the software designer uses programming algorithms to manipulate inchoate data.”). Statements such as this imply that software programs literally are algorithms. 22. See, e.g., Mark Aaron Paley, Article: A Model Software Petite Patent Act, 12 Computer & High Tech. L.J. 301, 319 (1996) (“[A] written claim for an algorithm can be expressed either as a literal or nonliteral expression of the algorithm. The literal description of the algorithm is the algorithm itself. Hence, the mere literal description of a software process is the process.”). 23. For definitions of “source code,” see, e.g., Webster’s New World Computer Dictionary, supra note 12, at 343 (“In a high-level programming language, the typed program instructions that programmers write before the program is compiled or interpreted into machine language instructions the computer can execute.”); see also Microsoft Computer Dictionary, supra note 20, at 491 (“Human-readable program statements written by a programmer or developer in a high-level or assembly language that are not directly readable by a computer.”). 24. See, e.g., Symposium: Toward a Third Intellectual Property Paradigm: A Manifesto Concerning the Legal Protection of Computer Programs, supra note 3, at 2322 (“Thinking of software as a machine makes it clear that source code is the medium in which a program is created, even though the value of the program, as with other machines, lies in its behavior.”). 25. See, e.g., Symposium: The Future of Software Protection: Common Law, Uncommon Software, 47 U. Pitt. L. Rev. 1037, 1064 (1986). The USPTO has conceded that computer programs embodied in a tangible medium, such as a floppy diskette, are patentable subject matter. Software patent claims which describe a program in terms of a set of instructions embodied in a tangible medium are common. See Richard H. Stern, An Attempt to Rationalize Floppy Disk Claims, 17 J. Marshall J. Computer & Info. L. 183 (1998). 26. The term “physical computer” refers herein to a physical machine implementing the “general-purpose computer architecture” described in supra Section III.C. The term “physical computer” therefore contrasts with terms such as “logical computer,” “abstract computer,” and “virtual machine,” all of which refer to an ideal or abstract machine that has the logical structure (i.e., architecture) defined by the general-purpose computer architecture. 27. The terms “run” and “execute” are synonymous with respect to computer programs. See, e.g., Webster’s New World Computer Dictionary, supra note 12, at 341(defining “run” as “[t]o execute a program”). 28. The term “execute” means “[t]o perform an instruction. In programming, execution implies loading the machine code of the program into memory and then performing the instructions.” Microsoft Computer Dictionary, supra note 20, at 200. 29. Providing a rigorous definition of automation is beyond the scope of this article. At least two plausible meanings, however, are sufficient for purposes of the present discussion. In one sense, an action is “automatic” if its execution does not involve the performance of substantial physical acts by a human being. This sense of the term “automatic” focuses on the lack of all but the most trivial physical involvement by a human being in performance of the action, and is reflected in certain dictionary definitions of “automatic” (e.g., “done or produced as if by machine” and “having a self-acting or self-regulating mechanism”) and “automaton” (“a machine or control mechanism designed to follow automatically a predetermined sequence of operations or respond to encoded instructions”). Merriam Webster’s Collegiate Dictionary, supra note 20, at 78. A dishwasher, for example, washes dishes “automatically” in the sense that it performs the necessary sequence of actions without the physical assistance of a human being, other than the physically trivial acts of selecting a setting and pressing the power button. In another sense, the term “automatic” refers to an action that is performed without all but the most trivial mental involvement by a human being. In particular, the term “automatic” in this sense refers to an action that is performed without the substantial exercise of conscious human thought or discretion. According to this sense, an action may be performed automatically even if physically performed substantially or entirely by a human so long as the action is performed unconsciously or without the need to exercise substantial discretion. Workers on an industrial assembly line perform their actions “automatically” in this sense despite the significant amount of physical labor they perform. This sense of the term “automatically” is also reflected in conventional dictionary definitions (e.g., “largely or wholly involuntary” and “acting or done spontaneously or unconsciously”). Id. In the context of software, the instance of Microsoft Word described above may be executed in response to a user double-clicking on an icon representing the program. The Microsoft Word program is executable “automatically” in both senses just described: execution of the software requires the human user to engage in neither substantial physical activity nor substantial mental activity. Executing the program is akin to pressing the “power” button on a dishwasher. Interesting questions are raised by various meanings of the term “automatic,” such as whether computer source code written on paper qualifies as an “executable software program” if it may be executed “automatically” by a computer in either or both of the two senses described above. The answers to such questions and the technological, social, and legal implications of this observation are beyond the scope of this paper. Also beyond the scope of this paper is the question of whether all tangibly-embodied instructions that are executable by a computer qualify as software, or whether such instructions must be stored in the memory of a computer to qualify as software. 30. Drawing a bright line between executable source code and non-executable software designs is particularly difficult. As a result, it is particularly difficult to identify the point at which the process of “designing” software ends and the process of “implementing” or “coding” software begins. Despite these difficulties, executability provides a reasonable basis for distinguishing between mere software designs and executable source code. See, e.g., Dick Hamlet & Joe Maybee, The Engineering of Software: Technical Foundations for the Individual 211-12 (Addison-Wesley 2001) (“Despite the similarities between the processes of designing and coding, there is one tremendous distinction between the end results: code can be executed on hardware – a design cannot.”). 31. See PLATO, The Republic, Book VII (Viking Press 1955). For a discussion of the relationship between the universal/particular distinction and the idea/expression distinction in copyright law, see Thomas M. Powers, Ideas, Expressions, Universals, and Particulars: Metaphysics in the Realm of Software Copyright Law, Proceedings of the Sixth Annual Ethics and Technology Conference 195 (2003). 32. A design is one example of a “logical entity” as that term is defined below in Section III.D.1. 33. Although these terms are commonly used with the meanings ascribed to them herein, the terms “conception” and “specification” must be carefully used in context because each may be used to refer either to a process or to the product of that process. For example, a programmer may form a conception of a software program as a result of engaging in the process of conception. The context in which such terms are used should make their intended meaning clear in particular cases. 34. The term “design,” for example, has other meanings, which differ from the meaning used herein. According to U.S. patent law, for example, a design patent may be granted for any “new, original and ornamental design for an article of manufacture.” 35 U.S.C. § 173 (2002). A design patent protects the nonfunctional aspects of an ornamental design as shown in a patent. See Elmer v. ICC Fabricating, Inc., 67 F.3d 1571 (Fed. Cir. 1995); see also Keystone Ret. Wall Sys., Inc. v. Westrock, Inc., 997 F.2d 1444 (Fed. Cir. 1993). I use the term “design” to refer to universal (ideal) representing the logical structure of an invention, despite the potential for confusion, because its colloquial meaning is closest to that which is intended herein, and because other potential terms (such as “invention”) carry with them even more problematic theoretical baggage. 35. See, e.g., Wagner, supra note 9, at 34-36 (arguing that “[s]oftware is disembodied symbolism” even when fixed in a tangible medium). Although I claim that a software program literally is a component of a machine, computer scientists sometimes use term “software component” in a different, figurative, sense to draw an analogy between physical components of an electromechanical device and (typically object-oriented) software program “components” that may be interconnected with each other logically to form larger programs. See, e.g., Bertrand Meyer, Object-Oriented Software Construction (Prentice Hall 2d ed. 1997). 36. See, e.g. James Gleick, Patently Absurd, N.Y. Times, Mar. 12, 2000 (Magazine), at 44 available at http://www.nytimes.com/library/magazine/home/20000312mag-patents.html (“Patents began in a world of machines and chemical processes – a substantial, tangible, nuts-and-bolts world – but now they have spread across a crucial boundary, into the realm of thought and abstraction.”). Although Gleick later acknowledges that software programs “are machines, in a way,” he asserts that “they are machines without substance – incorporeal machines, machines made of imagination and ‘logic’ and ‘bits.’” Id. Jim Warren of Autodesk, Inc., testified before Congress that “[s]oftware is not a gadget. . . . Software is what occurs between stimulus and response, with no physical incarnation other than as representations of binary logic.” Prepared Testimony and Statement for the Record of Jim Warren Before the Patent and Trademark Office (Jan. 26-27, 1994), available at http://www.bustpatents.com/autodesk.htm (September 14, 2003). Warren also recommended that the Patent Office “[i]ssue a finding that software . . . implements intellectual processes that have no physical incarnation; processes that are exclusively analytical, intellectual, logical and algorithmic in nature.” Id. Professor Donald Knuth, the grandfather of algorithms, stated his belief in a letter to the Patent Office that “[t]he Patent Office has fulfilled this mission [of serving society by formulating patent law] with respect to aspects of technology that involve concrete laws of physics rather than abstract laws of thought,” such as software. Letter from Professor Donald Knuth, the Patent Office, available at http://lpf.ai.mit.edu/Patents/knuth-to-pto.txt (September 14, 2003). See also John Perry Barlow, The Economy of Ideas, Wired (Mar. 1994) (arguing that “all the goods of the Information Age [including software] . . . will exist either as pure thought or something very much like thought: voltage conditions darting around the Net at the speed of light, in conditions that one might behold in effect, as glowing pixels or transmitted sounds, but never touch or claim to ‘own’ in the old sense of the word.”). 37. See, e.g., Georges Ifrah, The Universal History of Computing: From the Abacus to the Quantum Computer 120, 123-124 (John Wiley & Sons 2001) (claiming that Pascal’s invention of the Pascaline mechanical calculating device in 1624 “mark[e]d the final break with the long age of ignorance, superstition and mysticism which above all had stopped the human race from contemplating that certain mental operations could be consigned to material structures made up of mechanical elements, designed to obtain the same results.”). Similarly, Charles Babbage, the 19th century mathematician and designer of early computation devices referred to as the Inference Engine and the Analytical Engine, was recognized as having effectively embodied “mental processes” in a physical form. See id. at 204 (quoting W.S. Jevons, On the Mechanical Performance of Logical Inference, 160 Philosophical Transactions of the Royal Society, 497-518 (1870) (“The mind seems thus able to imbue matter with some of its highest attributes, and to create its own rival in the wheels and levers of an insensible machine.”). 38. The term “intangible” is used with several meanings in the law and the literature. For example, the term sometimes refers to entities, such as electrical signals and microscopic particles, that literally are not “touchable” or directly perceptible by the unaided senses. See, e.g., Richard H. Stern & Edward P. Heller, In Re Alappat: The Gordian Knot Retwisted, 2 U. Balt. Intell. Prop. J. 187 (1994) (characterizing electrical signals as “intangibles”) (quoting In re Schrader, 22 F.3d 290, 294 (Fed. Cir. 1994)); see also Barlow, supra note 36. Sometimes the term “intangible” refers to energy in contrast to matter, so that even microscopic particles are “tangible” despite the fact that they are not directly perceptible by the senses, while electricity is “intangible” because it is energy, even if it takes the form of a lightning bolt and therefore is perceptible directly by the senses. See, e.g., Eric J. Sinrod, Court Rules Insurance Doesn’t Cover Damage to Computer Systems, available at http://www.duanemorris.com/publications/pub899.html (July 16, 2002) (describing case of America Online, Inc. v. St. Paul Mercury Insurance Co. (E.D. Va. 2002), in which the court held that damage to computer data did not constitute damage to “tangible” property under an insurance policy). Finally, the term “intangible” sometimes is used to refer to Platonic universals (ideals), while the term “tangible” is used to refer to particulars, so that all matter and energy are tangible, while ideas, opinions, laws, and mathematical formulae are intangible. See, e.g., Greenwalt v. Stanley Co., 54 F.2d 195, 196 (3d Cir. 1931) (examples of “intangible, illusory, and nonmaterial things” include “emotional or aesthetic reactions”); In re Schrader, 22 F.3d 290, 296 n.12 (Fed. Cir. 1994) (implicitly distinguishing “intangible subject matter” from “physical activity or objects”). Similar confusion arises with the term “physical,” which is sometimes used to refer only to matter in contrast to energy and other times to refer both to matter and energy (particulars) in contrast to universals. I use the terms “tangible” and “physical” herein synonymously to refer to any entity that is composed of matter and/or energy, i.e., to particulars in the physical world. 39. This is exemplified by the distinction often drawn between “bits and atoms,” as popularized by Nicholas Negroponte in Being Digital. See Nicholas Negroponte, Being Digital (Vintage Books 1995). This distinction, although useful in some ways, conflates the logical and the physical in a way that can be as likely to confuse as to illuminate. In particular, comparing bits, which are units of information (like decimal numbers) that can be embodied in many different physical forms, to atoms, which are physical entities, is to compare apples to oranges and to conflate the logical properties of bits with the physical properties of electrons. Negroponte claims, for example, that “[a] bit has no color, size, or weight, and it can travel at the speed of light.” Id. at 14. In reality, these are properties of electrons, whether such electrons carry digital information (i.e., bits) or analog information (such as an analog television signal). For purposes of clarity it would be more useful to define a bit as a logical unit of information having certain logical properties (in the same way that numbers in general are defined), distinct from any particular physical form in which a bit may be embodied, and to speak of whether bits are embodied, instantiated, or encoded in a particular physical entity. Using the term “bit” in this way would help to avoid confusion in this already confusing area. 40. Punch cards, for example, in common use until the 1970’s, stored computer programs on physical cards rather than in electronic memories. Such cards were a form of executable software program. See, e.g., Ifrah, supra note 37, at 240-41. Breakthroughs in biological computing may enable tomorrow’s software to be constructed of indisputably tangible biological materials such as strands of DNA. See, e.g., Thomas F. Knight, Jr. & Gerald Jay Sussman, Cellular Gate Technology, MIT Artificial Intelligence Laboratory, (1998); see also Leonard Adleman, Molecular Computation of Solutions to Combinatorial Problems, 266 Science 1021, 1021-23 (1994); Dan Boneh et. al., On the Computational Power of DNA, 71 Discrete Applied Mathematics, Special Issue on Computational Molecular Biology, 79-94 (1996); Sandeep Junnarkar, In Just a Few Drops, a Breakthrough in Computing, N.Y. Times, May 21, 1997. Biocomputing is still in its embryonic stage. 41. Merriam Webster’s Collegiate Dictionary, supra note 20, at 697. 42. This assumes that, in accordance with the Cartesian mind-body duality, the mind is a non-physical entity distinct from the body. 43. See generally Stephen A. Ward & Robert H. Halstead, Jr., Computation Structures (MIT Press 1990), especially pages 281-512 for an introduction to the interaction between stored electrical software and computer hardware. 44. For examples of such definitions, see, e.g., John C. Phillips, Note: Sui Generis Intellectual Property Protection For Computer Software, 60 Geo. Wash. L. Rev. 997, 1002 (1992) (“In the broadest sense, a computer consists of two elements: hardware and software. Hardware includes the physical embodiment and structures associated with a computer system.”); Andrew G. Isztwan, Computer Associates International v. Altai, Inc.: Protecting The Structure Of Computer Software In The Second Circuit, 59 Brook. L. Rev. 423, 425 (1993) (“Hardware consists of the physical electronic circuits in which the processing ordered by the instructions occurs.”). 45. See, e.g., Webster’s New World Computer Dictionary, supra note 12, at 24 (defining “architecture” as “[t]he overall conceptual design and design philosophy of a hardware device or computer system or network”). In the context of software development, “[i]t has become common practice to use the term architecture to characterize the internal structure of a software system . . . .” James F. Peters & Witold Pedrycz, Software Engineering: An Engineering Approach 206 (John Wiley & Sons, Inc. 2000). See also Hafedh Mili et al., Reuse-Based Software Engineering: Techniques, Organization, and Controls 382-393 (John Wiley & Sons, Inc. 2001). As will become clear from the discussion below in Section III.D, the architecture of a computer is an example of a logical structure. The general-purpose computer architecture requires only that the components of a computer perform particular functions and exhibit particular logical properties both individually and collectively, without requiring that any particular physical structures be used to implement such features. In fact, one might say that all modern computers have the same basic logical structure despite having widely varying physical structures. 46. Although the term “computer architecture” is sometimes used to refer solely to computer hardware, a computer is not complete in an important sense until a particular software program is stored in its memory. I therefore use the term “computer architecture” to refer to a combination of hardware and software and, in particular, to refer to the particular relationship between hardware and software that defines modern digital computers. 47. See, e.g., Webster’s New World Computer Dictionary, supra note 12, at 341 (software is “[a] computer program or programs, in contrast to the physical equipment on which programs run (hardware).”); Microsoft Computer Dictionary, supra note 20 (software is “[c]omputer programs; instructions that make hardware work”). 48. See, e.g., Microsoft Computer Dictionary, supra note 20, at 407-8 (defining “platform” as “[t]he foundation technology of a computer system. Because computers are layered devices composed of a chip-level hardware layer, a firmware and operating-system layer, and an applications program layer, the bottommost layer of a machine is often called a platform.”). The term “platform” is sometimes used alternatively to refer to a combination of particular hardware and a particular operating system, in contrast to application programs (such as word processors and web browsers), which require the particular combination of hardware and operation system to execute. See, e.g., Webster’s New World Computer Dictionary, supra note 12, at 286 (defining “platform” as “[a] type of computer system defined by the type of hardware and operating system used. An example of a platform is the category of computers that have an Intel or Intel-compatible processor and are equipped with [the] Microsoft Windows [operating system.]”). 49. See, e.g., Symposium; Toward a Third Intellectual Property Paradigm: Article: A Manifesto Concerning the Legal Protection of Computer Programs, supra note 3, at 2316 (“[P]rograms are, in fact, machines (entities that bring about useful results, i.e. behavior) that have been constructed in the medium of text (source and object code).”). Programs need not, however, be “constructed in the medium of text,” as evidenced by the existence of “visual” (i.e., graphical) programming languages, such as Microsoft Visual C++®, which allow programs to be specified at least in part using graphical rather than textual elements. Programmers design programs in such programming languages by using a mouse and/or keyboard to add icons to the program, modify existing icons, and interconnect icons in various ways. Any program written in a textual programming language may alternatively be represented graphically and vice versa. See, e.g., Joseph G. Arsenault, Comment: Software without Source Code: Can Software Produced by a Computer Aided Engineering Tool be Protected?, 5 Alb. L.J. Sci. & Tech. 131 (1994). 50. The “general-purpose computer architecture” is described in more detail in Section III.C, infra. For reasons which will become clear in Section III.C, infra, modern digital computers are also referred to alternatively as “universal Turing machines” and, by abbreviation, as “Turing machines” and “universal machines.” 51. See In re Alappat, 33 F.3d 1526, 1545 (Fed. Cir. 1994) (“[S]uch programming creates a new machine, because a general purpose computer in effect becomes a special purpose computer once it is programmed to perform particular functions pursuant to instructions from program software.”); In re Bernhart, 417 F.2d 1395, 1400 (C.C.P.A. 1969) (“[I]f a machine is programmed in a certain new and unobvious way, it is physically different from the machine without that program; its memory elements are differently arranged. The fact that these physical changes are invisible to the eye should not tempt us to conclude that the machine has not been changed.”). 52. In fact, as described in Section III.G below, one need only design the function to be performed by the software, because the computer itself performs the equivalent of structural design and construction of the software. 53. Software differs from conventional electromechanical components in other ways, at least as software is embodied using current technology. For example, as described above, software may be embodied in electrical signals rather than matter, and therefore may be copied, stored, and transported more quickly than matter-based components. This is not, however, the fundamental difference between software and hardware for the reasons described herein. 54. See generally Gerard Voland, Engineering by Design (Denise Penrose ed., Addison-Wesley Longman, Inc. 1999); Nam P. Suh, The Principles of Design (J.R. Crookall et al. eds., Oxford University Press, Inc 1990); Atila Ertas & Jesse C. Jones, The Engineering Design Process (Cliff Robichaud ed., John Wiley & Sons, Inc. 2d ed. 1993). In particular, increasing attention is being paid to the application of engineering design techniques to software development. See generally Peters & Pedrycz, supra note 45; Mili, supra note 45; Shari Lawrence Pfleeger, Software Engineering: Theory and Practice, (Prentice Hall 2d ed. 2001); Hamlet & Maybee, supra note 30. 55. I use the term “ideal” not to imply that the model described herein is superior to others, but merely to indicate that it is “idealized” in the sense that it is an abstraction incorporating features of various other models. In particular, the “ideal design model” described herein is an example of a “waterfall” design model because the stages of the model are performed in sequence, each stage producing results that form the basis for the next stage, calling to mind a waterfall cascading down a terrace. See, e.g., Pfleeger, supra note 54, at 48-50. Other kinds of engineering design models include life-cycle models, such as the evolutionary, prototyping, incremental, and spiral life-cycle models. See, e.g., generally Peters & Pedrycz, supra note 45, at 46-48. The analysis herein does not, however, require the process of engineering design to proceed according to the stages of the ideal design model described herein. Rather, the ideal design model that I present is provided merely to highlight particular characteristics of engineering design that are relevant to computer programming and to patent law. In practice, engineers employ an extremely wide variety of techniques to design new products and processes, some of which are highly rigid and methodical and others that are largely spontaneous and based on intuition. All such techniques are consistent with the analysis presented herein. 56. . Although for completeness the model may include additional stages, such as testing and maintenance, such stages are omitted because they are not relevant to the discussion herein. For a description of a somewhat more complex design model, see Steve McConnell, Code Complete: A Practical Handbook of Software Construction 1-6 (Microsoft Press 1993). 57. I have used facts described in the Supreme Court case of O’Reilly v. Morse, 56 U.S. 62 (1853), whenever possible. In cases where relevant facts are not available in O’Reilly, I use hypothetical facts and indicate as such in the text. 58. See, e.g., generally Peters & Pedrycz, supra note 45, at 119-20; Suh, supra note 54, at 30-35. 59. See Stobbs, supra note 2, at 129. (“During the decade that followed [Oersted’s discovery of electromagnetism], several prominent inventors saw Oersted’s miraculous new form of energy as a possible way to communicate at a distance. Many tried, but Samuel Morse is credited as the one who first made it happen.”). 60. See, e.g., generally Peters & Pedrycz, supra note 45, at 117-122; Suh, supra note 54, at 12-13. 61. I use the term “Logical Structural Design” to refer to a stage of the design process that is often referred to by other names. For example, it is sometimes referred to as “architectural design”. See, e.g., McConnell, supra note 56, at 3; Peters & Pedrycz, supra note 45, at 205-209. The term “structural design,” by itself, is ambiguous, because it may refer either to the design of a logical structure or to the design of a physical structure (which I call “physical structural design”). Similarly, the term “structure” is ambiguous because it may refer either to a logical structure or a physical structure, depending on the context in which it is used. For example, the term “structure” in the title of the classic introductory text on computer programming, Structure and Interpretation of Computer Programs, refers to the logical structure of computer programs. See Harold Abelson & Gerald Jay Sussman, Structure and Interpretation of Computer Programs (MIT Press 1985). More generally, references in the software engineering literature to the “structure” of software refer to the logical structure of software. I make liberal use of the terms “logical” and “physical” as qualifiers for the terms “structure” and “structural” to avoid any such ambiguities. 62. See, Section III.D.1, infra. 63. See, e.g., Hamlet & Maybee, supra note 30, at 89-90; Peters & Pedrycz, supra note 45, at 132-137. 64. The process of Functional Design may further be performed for each subsystem. For example, Morse may have decided that the transmitter should include a means for receiving a message from a human, means for converting the message into electrical signals, and means for transmitting the message over the communications channel. This process of subdividing an element of a design into lower-level elements is referred to as “decomposition.” For descriptions of functional decomposition, see, e.g., Meyer, supra note 35, at 103-14; McConnell, supra note 56, at 145-48. 65. See, e.g., Suh, supra note 54, at 18-25. 66. See O’Reilly v. Morse, 56 U.S. 62, 55 (1853). 67. Morse conceived of the physical structure of the telegraph while on a trans-Atlantic voyage from Havre, France to New York. See id. at 12-13. 68. Note that the term “design” is used to refer to the end product of the process of physical structural design. See, e.g., Pfleeger, supra note 54, at 195 (“Design is the creative process of transforming the problem into a solution; the description of a solution is also called [a] design.”). It is important to keep these two meanings of the term “design” distinct. See supra note 34. 69. See, e.g., Ertas & Jones, supra note 54, at 28-30. The Construction Stage often is referred to by other names, such as “manufacturing” or “production.” Further confusing matters, the term “construction” in the context of computer programming is often used to refer to the process of “constructing” the logical structure of a program by writing source code, rather than to the process of constructing the physical structure of the program. For example, the term “construction” in the titles of the books Code Complete: A Practical Handbook of Software Construction and Object-Oriented Software Construction refer to the detailed design of computer source code, not to the kind of physical construction associated with conventional electromechanical devices. See McConnell, supra note 56; see also Meyer, supra note 35. This usage of the term “construction” is correct by analogy in that it refers to the final and most detailed stage carried out by a human being in both electromechanical and software design. The use of the term “construction” to refer to the design of computer source code, however, may be confusing in the context of the present discussion. I therefore only use the term “construction” to refer to the physical construction of a physical entity (such as an executable software program), not to any aspect of the process of designing a software program or other product. 70. “The true date of invention is at the point where the work of the inventor ceases and the work of the mechanic begins.” Cameron & Everett v. Brick, 1871 C.D. 89, 90 (Comm'r Pat. 1871). The builder may, of course, be the same person who performed the Physical Structural Design stage. 71. I use the term “invention” in this portion of the analysis despite potential confusion with the legal meaning of the term “invention” because the use of the term “invention” in this context closely tracks its legal meaning. The legal requirements for invention are described below in Section IV.C. 72. As described above, Functional Design is a specific case of Logical Structural Design. 73. O’Reilly, 56 U.S. 62, 107 (1853). 74. The definitive biography of Alan Turing is Andrew Hodges, Alan Turing: The Enigma (Walker & Company 2000); see also Martin Davis, Engines of Logic: Mathematicians and the Origin of the Computer (W.W. Norton 2000). 75. See, e.g., Ifrah, supra note 37, at 158. 76. See, e.g., John Agar, Turing and the Universal Machine: The Making of the Modern Computer 60-61 (Totem 2001) (“The ENIAC . . . could also be ‘reprogrammed,’ switching from calculating trajectories to the motion of a shockwave. But this reprogramming meant extensive rewiring: two days spent completely rearranging a nest of plugboard wires. It was not the same machine doing different calculations, but a subtly different machine for each job. . . . [T]he frustration of rebuilding the machine each time the mathematical problem was changed forced the ENIAC team to devise the crucial idea of this book: the concept of the stored program.”). 77. For a general overview of Turing’s codebreaking work during World War II, see Hodges, supra note 74, at 160; Davis, supra note 74, at 170-75. The quest to eliminate the tedium of electromechanical design is related to the general quest of scientists to eliminate the tedium involved in performing the calculations that are necessary for all scientific work. See, e.g., Ifrah, supra note 37, at 101 (quoting L.F. Menabrea, Sur la Machine Analytique de Charles Babbage, Comptes rendus des séances de l’Académie des sciences, 179-82 (July 28, 1884); Agar, supra note 76, at 39-62, 101-12. 78. The particular architecture implemented by modern digital computers is sometimes referred to as the “von Neumann” architecture, named after John von Neumann, another computing pioneer. In 1945 von Neumann wrote the now-famous First Draft of a Report on the EDVAC, which proposed that the proposed EDVAC computer be designed and constructed as a physical implementation of a universal Turing machine. Davis, supra note 74, at 182. 79. See, e.g., Davis, supra note 74, at 151; Ifrah, supra note 37, at 272-80, 313. 80. James Moor coined the term “logically malleable” to refer to this feature of computers. See James H. Moor, The Future of Computer Ethics: You Ain’t Seen Nothin’ Yet!, 3 Ethics & Info. Tech. 89, 89-91 (2001). 81. References to the “computer revolution” sometimes focus on the incredible speed at which computers operate and the degree of miniaturization that is realized in computer technology. Although these technological advances may qualify as revolutionary in their own right, they are distinct from the theoretical advance represented by the unique architecture of the general-purpose computer. 82. Even Howard Aiken, one of the founders of modern computing, expressed his surprise at the ability of a computer to mimic a wide variety of machines when he said: “If it should turn out the basic logics of a machine designed for the numerical solution of differential equations coincide with the logics of a machine intended to make bills for a department store, I would regard this as the most amazing coincidence I have ever encountered.” Paul Ceruzzi, Reckoners: the Prehistory of the Digital Computer, from Relays to the Stored Program Concept 43 (Greenwood Press 1983) (quoted in Davis, supra note 74). 83. See Alan Turing, On Computable Numbers, with an Application to the Entscheidungsproblem, Proceedings of the London Mathematical Society, ser. 2, vol. 42 at 230-67 (1936-37), correction in ser. 2, vol. 43 at 544-46 (1937). For a description of the substance of the paper and the work behind it, see, e.g., Agar, supra note 76, at 139-76. The “universal machine” is also referred to as the “universal Turing machine,” which is capable of mimicking any of a near-infinite number of special-purpose machines referred to as “Turing machines.” 84. Davis, supra note 74, at 169-97. 85. John von Neumann, for example, is typically credited with proving the equivalence between an abstract universal Turing machine and actual digital computers having particular physical structures. See Ifrah, supra note 37, at 291; id. at 178. 86. See, e.g., id. at 177-97, 280-95. 87. The term “software architecture” is often defined in a similar way, as in the following: A description of a software architecture consists of three basic elements: processing, data, and connecting elements… A processing element is a software structure that transforms its inputs into required outputs. A data element consists of information needed for processing or information to be processed by a processing element. Connecting elements are the “glue” that holds different pieces of an architecture together. Peters & Pedrycz, supra note 45, at 208. In this description of software architecture, the processing and data elements are examples of logical entities and the connecting elements are an example of logical relationships. 88. Although one might attempt to distinguish between mathematics and logic, modern mathematics and logic are inextricably intertwined. See, e.g., Bertrand Russell, Introduction to Mathematical Philosophy, 194 (1996) (quoted in Ifrah, supra note 37, at 268) (“Logic has become more mathematical and mathematics more logical. The consequence is that it is now wholly impossible to draw a line between the two; in fact, the two are one. They differ as the child differs from the man; logic is the youth of mathematics and mathematics is the manhood of logic.”). 89. “Thus it will be readily understood that in order to demonstrate a theorem, it is not necessary or even useful to know what it means… we might imagine a machine where we should put in axioms at one end and take out theorems at the other, like that legendary machine in Chicago where pigs go in alive and come out transformed into hams and sausages. It is no more necessary for the mathematician than it is for these machines to know what he is doing.” H. Poincaré, Science and Method ch. 3 (Dover Press 1952) (quoted in Davis, supra note 74, at 93). 90. A “programming language” is defined as “[a]n artificial language consisting of a fixed vocabulary and a set of rules (called syntax) that one can use to create instructions for a computer to follow.” Webster’s New World Computer Dictionary, supra note 12, at 299. 91. See supra n. 54. 92. Certain aspects of computer programming involve mental and physical processes that are the same as or very similar to those involved in writing literary works. As a result, computer programming is often referred to as a process of “writing” code. See, e.g., Randall M. Whitmeyer, Comment: A Plea for Due Processes: Defining the Proper Scope of Patent Protection for Computer Software, 85 Nw. U.L. Rev 1103, 1107 (1991) (“Developing software is most definitely a literary exercise, like writing an essay or a book.”). All too often, however, computer programming is conceptualized solely as an act of “writing,” thereby obscuring aspects of programming that are dissimilar from writing. See, e.g., Alan L. Durham, “Useful Arts” in the Information Age, 1999 B.Y.U.L. Rev 1419, 1457-8 (1999) (“[P]rogramming does not begin with coding any more than house building begins with nailing boards together. In either case, the construction phase is preceded by a planning stage.”). Increasing attention, however, is being paid to the process of designing programs prior to and while writing source code. See generally McConnell, supra note 56, at 53-170. Furthermore, the choice of language may influence the design process in important ways. See Abelson & Sussman, supra note 61, at 4 (“A powerful programming language is more than just a means for instructing a computer to perform tasks. The language also serves as a framework within which we organize our ideas about processes.”). 93. More generally, commands, statements, and other syntactic structures are defined in terms of their logical structure, as described in more detail below. 94. See Symposium, Toward a Third Intellectual Property Paradigm: Article: A Manifesto Concerning the Legal Protection of Computer Programs, supra note 3, at 2327-8; see also Durham, supra note 92, at 1463-5. 95. See Paley, supra note 22, at 325-6 (“In 1969, the Court of Customs and Patent Appeals found in In re Prater that there is no constitutional, statutory, or case law support for the proposition that a ‘programmed general-purpose computer [is] necessarily unpatentable.’ This novel approach likens a general-purpose computer to a storeroom of electrical components. The components are taken by a computer program out of the storeroom as needed, connected together, and a new machine built from those parts.”). 96. It is common to equate the terms “computer program” and “algorithm.” See, e.g., Christopher M. Mislow, Computer Microcode: Testing the Limits of Software Copyrightability, 65 B.U.L. Rev. 733, 775 (1985); Wagner, supra note 9, at 14; Swinson, supra note 8, at 147. It is not true, however, that all computer programs are algorithms. Object-oriented software programs, for example, define systems of interrelated logical objects. Software which defines graphical user interfaces (GUIs) defines such interfaces not only in terms of the steps that such interfaces perform but also in terms of their logical content. Although neither object-oriented software programs nor GUI software programs are properly classified as “algorithms,” they are still examples of software and are properly classified as defining logical entities. 97. See, e.g., Microsoft Computer Dictionary supra note 20, at 23 (defining an algorithm as “[a] finite sequence of steps for solving a logical or mathematical problem or performing a task”);Donald E. Knuth, The Art Of Computer Programming: Fundamentals Of Algorithms 1-4 (1973); Allen Newell, Response: The Models are Broken, the Models are Broken, 47 U. Pitt. L. Rev. 1023, 1024 (1986) (“A standard definition is: An algorithm is an unambiguous specification of a conditional sequence of steps or operations for solving a class of problems.”). 98. See Mitchell P. Novick & Helene Wallenstein, The Algorithm and Computer Software Patentability: A Scientific View of a Legal Problem, 7 J. Computers, Technology, and Law 313 (1980) (“A more scientific definition [of algorithm] would be as follows: ‘Given both the problem [to be solved] and the device [to be used in solving the problem], an algorithm is the precise characterization of a method of solving the problem, presented in a language comprehensible to the device.’”); Swinson, supra note 8, at 147 (“[A]ll algorithms by definition have at least one defined or implied processor [on which to execute].”). 99. See, e.g., Tim Lindholm and Frank Yellin, The Java™ Virtual Machine Specification 1-4 (Addison-Wesley 1996). 100. Alternatively, a data structure is “[a]n organizational scheme, such as a record or array, that can be applied to data to facilitate interpreting the data or performing operations on it.” Microsoft Computer Dictionary, supra note 20, at 145. 101. See generally Meyer, supra note 35, at 217-278. 102. Object-oriented programming is a “programming paradigm in which a program is viewed as a collection of discrete objects that are self-contained collections of data structures and routines that interact with other objects.” Id. at 373. It is further defined as “an approach to programming language design in which program elements are conceptualized as objects that can pass messages to each other by following established rules.” Webster’s New World Computer Dictionary, supra note 12, at 260. 103. Although the source code may first need to be compiled into object code to be executed, whether the source code needs to be compiled is irrelevant to the present discussion. Even in cases in which the source code needs to be compiled into object code to be executed, such compilation may be performed automatically (as that term is used herein) by a computer. See, supra note 29. Therefore, one may provide source code to a computer and thereby automatically create an executable software program in the memory of the computer, whether or not the source code needs to be compiled to create the executable software program. 104. See Abelson & Sussman, supra note 61, at 4. 105. For an overview of information hiding, see, e.g., McConnell, supra note 56, 118-30. 106. A program written in the Java programming language, for example, is in theory capable of executing on any computer platform, regardless of its physical hardware or operating system. As a result, a programmer may write a single Java program without regard for the physical properties – or even the lower-level logical properties – of the platform(s) on which the program will execute. The Java programming language was designed not to include any instructions which allow the programmer to refer to specific physical features of the underlying computer hardware or operating system, although in practice the language does not strictly adhere to this high standard. 107. Id. 108. See Ifrah, supra note 37, at 122-24. 109. Id. at 123 (quoting Gilbert Pascal, brother of Blaise Pascal). 110. See, e.g., Bob Frankston, Beyond Limits, in Beyond Calculation: The Next Fifty Years of Computing 47 (Peter J. Denning & Robert M. Metcalfe eds., Copernicus 1997); see also Richard Green, Train Once, Write Anywhere, 6 Java Developer’s J. 8 (2001). The development of “genetic programming” techniques enables programmers to write programs that “evolve” other programs, thereby enabling programmers to remain ignorant even of the logical structure of the programs they bring into existence. See, e.g., Steven Johnson, Emergence: The Connected Lives of Ants, Brains, Cities, and Software (Scribner 2001). 111. R.W. Hamming, One Man’s View of Computer Science, 16 J. Of The Ass’N For Computing Mach. 3, 5 (1969). 112. Some software, however, does not comfortably fit into either of these two categories. The proper status of such software within patent law is a difficult and interesting question. For a discussion of this topic, see Edward Brown, , Patenting Architectural Features of Software, 2002 Proc. Of The Third Int’l Conf. on Law And Tech., at 67-72. 113. This is accomplished using “virtual memory.” For a discussion of techniques for implementing virtual memory see Ward & Halstead, supra note 43, at 486-97. 114. This idea is sometimes stated by asserting that mechanical engineers solve “physical problems,” while computer scientists solve “intellectual” or “abstract” problems. See, e.g., Allen B. Wagner, supra note 9, at 16 (“A natural scientist applies physical science to physical phenomena; that is, s/he conceives solutions to concrete (objective) problems. The computer scientist assigns meanings to symbols (the abstract model) and develops the steps (algorithm) of a symbol manipulating process; that is, s/he conceives solutions to abstract problems.”). Assertions, often made by critics of software patents, that software is “intangible” or otherwise is not subject to the laws of physics may be interpreted in their best light as assertions that computer programmers do not take physical constraints into account when designing software, rather than as assertions that software itself is not physical. For example, although Jim Warren in his testimony to Congress claimed that software has no physical form, he also stated more accurately that “[w]hat programmers do is figure out how to solve intellectual problems, rather than physical problems.” Testimony of Jim Warren, supra note 36. Similarly, this is presumably what Richard Stallman, the most vocal proponent of the free software movement, means when he says: “We [software developers] can build a castle and rest it on a thin line, and it will stay up. In other fields you have to deal with matter, and make physical objects that work. But if I want to put an ‘if’ statement inside a ‘while’ statement I don’t have to worry whether the ‘if’ statement will oscillate against the ‘while’ statement and eventually fracture. I don’t have to worry about whether the ‘if’ statement will dissipate heat well enough, or whether a voltage drop across the ‘if’ statement will stop the ‘while’ statement from working or, if it is working under water, whether salt water will get between the two statements and corrode them. I don’t have to worry about how I will physically assemble each copy, and whether I can physically get access during construction to put one statement inside the other, and I don’t have to worry about how, if one breaks, I will replace it.” Matt Loney, Stallman: Patents victimize developers, ZDNet (UK), available at http://zdnet.com.com/2100-1104-870390.html (Mar. 28, 2002); see also Richard Stallman & Simson Garfinkel, Viewpoint: Against Software Patents, 35 Comm. of the ACM 17, 19 (1992) (“When an if-statement follows a while-statement [in source code], there is no need to study whether the if-statement will draw power from the while-statement and thereby distort its output, or whether it could overstress the while-statement and make it fail.”). Stallman’s assertion that he does not “have to worry” about the physical properties of computer program instructions or “need to study” the physical interactions of computer program instructions may be interpreted as assertions that programmers need not take physical constraints into account when designing software, rather than as assertions that the software itself is not physical. Id. In other words, Stallman is best interpreted as making assertions about the thought processes of programmers rather than the physical properties of software. What Stallman omits, however, is the equally important fact that programmers need to take logical constraints, imposed by the virtual machine that they are programming, into account. See also references cited supra in note 36. 115. See Hamlet & Maybee, supra note 30, at 50-51; J. David Bolter, Turing’s Man: Western Culture in the Computer Age 40 (1984) (quoted in Alan L. Durham, supra note 92, at 1463): [W]hat especially characterizes the programmer is his withdrawal from nature into the private intellectual world of the program he is writing. Normally, he thinks neither of the keyboard at which he is typing nor of the electrons that are performing the calculations. He concentrates his full attention on the abstract problem, its representations in the programming language, and the logical design of the machine he is using. In this respect, he resembles the mathematician, the philosopher, the theologian, or indeed the chess master, all of whom live more or less completely in intellectual worlds of their own making. 116. See John Searle, Minds, Brains, and Science 37-38 (Harvard University Press 1984) (arguing that whether a computer program simulates physical activity (such as a rain storm) is distinct from whether the computer performs that activity (“We can do computer simulation of rain storms in the home counties . . . [yet] no one supposes that a computer simulation of a storm will leave us all wet.”) 117. See infra Sections IV-V. 118. See, e.g., In re Walter, 618 F.2d 758, 767-68 (C.C.P.A. 1980) (“[I]f the end product of a claimed invention is a pure number . . . the invention is nonstatutory . . . . If, however, the claimed invention produces a physical thing . . . . the fact that it is represented in numerical form does not render the claim nonstatutory.”); Diamond v. Diehr, 450 U.S. 175, 185 (1981) (process held to be statutory the claims “involve[d] the transformation of . . . raw, uncured synthetic rubber, into a different state or thing”); In re Pardo, 684 F.2d 912, 916 (C.C.P.A. 1982) (holding that a process claim directed to controlling the internal operations of a programmed computer constituted statutory subject matter because the claim was directed to “executing programs in a computer,” which the court viewed as indistinct from a strictly mechanical adding machine); In re Grams, 888 F.2d 835, 840 (Fed. Cir 1989) (holding that an algorithm that failed to perform “physical steps” did not qualify as statutory subject matter); State Street Bank & Trust Co. v. Signature Financial Group, Inc., 149 F.3d 1368, 1373 (Fed. Cir. 1998) (holding that “the transformation of data, representing discrete dollar amounts, by a machine through a series of mathematical calculations into a final share price,” qualified as statutory subject matter because it produced “a useful, concrete and tangible result,” even though the transformed data did not represent physical entities). Although the court in State Street did not expressly refer to the physical transformations performed by the machine, the referenced “transformation of data” must be a physical transformation because it is performed by a machine, and the only transformations that machines are capable of performing are physical transformations. Id. The court’s holding may therefore be interpreted, in its best light, to stand for the proposition that a machine which performs a physical transformation (e.g., of electrical signals from one form into another) qualifies as statutory subject matter if the result of the transformation is useful, concrete, and tangible (i.e., physical). 119. See, e.g., In re Taner, 681 F.2d 787, 790 (C.C.P.A. 1982) (holding that claimed processes which both performed and simulated physical activity satisfied the statutory subject matter requirement, without distinguishing between these two sense of physicality or explaining the relevance of either to the subject-matter patentability determination); In re Abele, 684 F.2d 902 (C.C.P.A. 1982) (basing statutory subject matter determinations on whether the data used by the claimed processes represented physical entities); In re Schrader, 22 F.3d 290, 294 (Fed. Cir. 1994) (holding disputed process claims not to be directed to statutory subject matter because they “do not reflect any transformation or conversion of subject matter representative of or constituting physical activity or objects”). 120. See Arrhythmia Research Technology v. Corazonix Corp., 958 F.2d 1053 (Fed. Cir. 1992) repeatedly conflates the two senses of physicality noted herein. 121. AT&T Corp. v. Excel Communications, Inc., 172 F.3d 1352 (Fed. Cir. 1999). The reasoning in the AT&T decision is seriously flawed. For example, the court in AT&T cited the State Street decision in support of the proposition that a process need not effect a “physical transformation” to qualify as statutory subject-matter, even though the holding in the State Street case applies only to apparatus – not process – claims, and even though the holding in the State Street case does not imply that a statutory process need not be embodied in a physical form, only that the data manipulated by a statutory process need not represent physical activity or objects. Id. at 1359. The AT&T court, in other words, conflated the two senses of physicality described herein. Although a full analysis of the flaws in the AT&T court’s analysis is beyond the scope of this article, the recommendations provide in Section V.B, infra, are intended in part to address the problems in the AT&T court’s reasoning by providing rules for patentability that analyze the two senses of physicality separately. 122. I use the phrase “providing a computer program to a computer” rather than “computer programming” here to distinguish between the mere physical act of providing a program to a computer so that the program is stored in the computer’s memory and the creative act of designing a computer program, which may be done in whole or in part without physically providing the program to a computer. 123. See, e.g., John A. Kidwell, Software and Semiconductors: Why are we Confused?, 70 Minn. L. Rev. 533, 542 (1985): If one conceives of a computer as an extraordinarily complicated set of electrical switches and relays, the computer program is nothing more than the list of instructions for the setting of those switches to facilitate some particular electrical manipulation. The entry of the program into the computer is nothing more than the translation of the description of the switch settings into the setting of the switches themselves. Thus, as noted earlier, the instructions have been transformed into the thing itself. That is, the instructions as to switch settings have at a certain point become the switch settings. 124. Furthermore, the same program may produce different physical structures in different computers, or even in the same computer under different conditions. See, e.g., Paley, supra note 22, at 326-27. 125. Although the program is embodied in electrical signals and the drill bit is embodied in matter, this is an irrelevant distinction for the reasons described in Section II.C supra. 126. 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. 127. Computer program instructions are often described as instructions directed to a computer, which instruct the computer to perform particular functions. This view of computer programs, while accurate, is incomplete because it best explains only some features of computer programs. Computer programs, for example, include not only instructions that define actions to be performed, but also instructions defining data. A computer program, furthermore, need not be viewed as a set of instructions at all. Rather, a computer program may be viewed as a description of a machine, akin to a conventional architectural blueprint or electrical schematic diagram. Unlike such conventional descriptions, however, a computer program describes its corresponding machine in terms of its logical structure, rather than in terms of its physical structure. 128. This is not to say that electromechanical engineers do not also engage in logical structural design in the process of designing electromechanical devices, only that electromechanical engineers further need to engage in physical structural design to enable the construction of working embodiments of their designs. 129. The automation of Physical Structural Design effectively provides software developers with a shortcut for designing and building electromechanical device components. See James R. Goodman et al., supra note 3, at 354 (“[P]rogramming a computer is just another way of making circuitry, and the exact same circuitry or equivalent circuitry can be hard wired.”). 130. See, e.g., James R. Goodman, et al., The Alappat Standard for Determining That Programmed Computers are Patentable Subject Matter, 76 JPTOS 771, 780 (“A computer program . . . operates in a computer to set switches, to make electrical connections, and to form circuitry.”); “[P]rogramming a computer inherently makes the circuitry [to carry out the program] – this is how a computer operates.” Goodman, supra note 3. at 357; Cf. Wagner, supra note 9, at 17 (“[C]omputer science ingenuity does not cause change to physical phenomena, since no causal relationship crosses the Cartesian divide.”). 131. Perhaps in the future the process of logical structural design will be automated, so that we will be able to construct new machines for solving particular problems merely by specifying their requirements or the problem to be solved and providing the specification to a computer. Perhaps someone will write a program that merely says “cure cancer” and let the computer do the rest of the work. 132. Software developers are engineers in the sense that they design machine components to perform useful functions in the physical world. This is not to be confused with “software engineering,” a term which refers to the application of particular engineering techniques to software development. See, e.g., Hamlet & Maybee, supra note 30, at 49-50. Software developers are “engineers” in the sense in which I use that term regardless of the techniques that they use to develop software. Not everyone agrees that software development is a process of “engineering” in any sense of the term. See, e.g., Wei-Lung Wang, Beware the Engineering Metaphor, 45 Communications of the ACM, 27-29 ( 2002). The view of software development as a form of engineering, however, is consistent with the view that “technology may be characterized as knowledge that is applied towards material enterprise, guided by an orientation to the external environment and the necessity of design.” Symposium The Post-Industrial Patent System, 10 Fordham Intell. Prop. Media & Ent. L.J. 346 (1999). To the extent that engineering is characterized by the design and implementation of technology, and to the extent that software is a kind of technology, software development is a kind of engineering. 133. The logical structure of computer programs may also be relevant to other areas of the law, such as copyright law. For an overview and analysis of cases addressing the applicability of copyright law to the logical structure of computer programs, see, e.g., Dennis S. Karjala, Copyright Law: Copyright Protection Of Computer Program Structure, 64 Brook. L. Rev. 519 (1998); Isztwan, supra note 44, at 423; Steven R. Englund, Note Idea, Process, or Protected Expression?: Determining the Scope of Copyright Protection of the Structure of Computer Programs, 88 Mich. L. Rev. 866 (1990); Thomas M. Gage, Note Whelan Associates v. Jaslow Dental Laboratories: Copyright Protection For Computer Software Structure -- What's The Purpose?, 1987 Wis. L. Rev. 859 (1987). This article focuses on patent rather than copyright law because patent law is particularly well-suited, and copyright law particularly poorly suited, to protecting the logical structure of useful artifacts. 134. See definition supra Section III.D.5. 135. See infra Section IV.C. See also Richard H. Stern, Solving the Algorithm Conundrum: After 1994 in the Federal Circuit Patent Law Needs a Radical Algorithmectomy, 22 AIPLA Q. J. 167, 170 (1994). Although the opinions of the Federal Circuit in the recent State Street Bank and Excel opinions reflect a movement away from an absolute physicality requirement for process claims, I argue in Section V.B.1 infra that such movement is both misguided and unnecessary for the protection of software by patent law. 136. See infra Section IV.C.2. 137. See infra Section IV.C.3. 138. U.S. CONST. art. I, § 8, cl. 8. The term of a patent is twenty years from its effective filing date. 35 U.S.C. § 154 (a)(2) (2002). 139. This “public disclosure” requirement is embodied in 35 U.S.C. § 112 (2002). 140. See, e.g., Bonito Boats Inc. v. Thunder Craft Boats Inc., 489 U.S. 141, 150-51, 9 USPQ2d 1847, 1852 (1989); see also Patents, supra note 4, at § 7.01. 141. See 35 U.S.C. § 112 (2002) (requiring that a patent specification enable the public to make and use the claimed invention). 142. See Permutit Co. v. Graver Corp., 284 U.S. 52, 60 (1931); General Electric Co. v. Wabash Appliance Corp., 304 U.S. 364, 369 (1938). Putting the public on notice of the exclusive rights granted by a patent enables the public to avoid infringing the patent, to design around the patent, and to begin using the invention after the patent expires. See 35 U.S.C. § 112 (requiring that patent claims particularly point out and distinctly claim the invention); Hilton Davis Chem. Co. v. Warner-Jenkinson Co., 62 F.3d 1512, 1520 (Fed. Cir. 1995) ("The ability of the public to successfully design around-to use the patent disclosure to design a product or process that does not infringe, but like the claimed invention, is an improvement over the prior art-is one of the important public benefits that justify awarding the patent owner exclusive rights to his invention."); State Industries, Inc. v. A.O. Smith Corp., 751 F.2d 1226, 1236 (Fed. Cir. 1985). 143. . See generally Julie E. Cohen & Mark A. Lemley, Patent Scope and Innovation in the Software Industry, 89 Calif. L. Rev. 1 (2001) (discussing the scope of software patent claims); see also Robert P. Merges & Richard R. Nelson, On the Complex Economics of Patent Scope, 90 Colum. L. Rev. 839 (1990) (discussing the impact of scope on the economic significance of patents). 144. “Use” of the invention includes both “non-creative” uses of the invention – such as building, selling, and using embodiments of the invention – as well as “creative” uses of the invention, such as designing improvements to the invention and making, selling, and using such improvements. 145. See 35 U.S.C. § 154(a)(2) (2002). 146. See 2 MELVILLE B. NIMMER & DAVID NIMMER, NIMMER ON COPYRIGHT §§2.01-2.20 (1995). 147. See generally Patents, supra note 4, at ch. 18. The manner in which the scope of a patent claim is ascertained will be discussed in more detail in Section IV.C, infra. 148. The discussion in this section refers most accurately to electromechanical inventions. 149. See infra Section IV.C.1. 150. By “physical structure” I refer not only to shape, size, and other features that are typically considered “structural,” but also to color, mass, chemical composition, and other physical features. 151. See infra Section IV.C.2. 152. See infra Section IV.C.2(c). 153. 35 U.S.C. § 101 defines four categories of statutory subject matter: machines, manufactures (also referred to as “articles of manufacture”), compositions of matter, and processes. The term “product” herein refers to machines, manufactures, and compositions of matter. 154. Courts historically have had significant conceptual difficulty defining the characteristics that a process must have to qualify as statutory subject matter. In general, a process “is not a structural entity but rather an operation or series of steps leading to a useful result.” Patents, supra note 4, § 1.03. Early decisions adopted the definition of “process” provided in the case of Cochrane v. Deener, 94 U.S. 780, 788 (1876) where the Court defined a process as “a mode of treatment of certain materials to produce a given result. It is an act, or a series of acts, performed upon the subject-matter to be transformed and reduced to a different state or thing.” Cochrane, 94 U.S. at 787-88. Similarly, Professor Robinson defined a process as “an act or a series of acts performed by some physical agent upon some physical object, and producing in such object some change either of character or of condition.” 1 William C. Robinson, The Law of Patents for Useful Inventions § 159 (1890). Transformation of matter from one state to another was long the lynchpin of process subject-matter patentability. Under this view a process itself is not a physical entity but rather acts upon a physical entity to transform it into “different state or thing.” Later courts defined patentable processes as those processes which fall within the “technological arts.” See, e.g., In re Musgrave, 431 F.2d 882, 883 (C.C.P.A. 1970). The U.S. Supreme Court then announced that “[t]ransformation and reduction of an article ‘to a different state or thing’ is the clue to the patentability of a process claim that does not include particular machines.” Gottschalk v. Benson, 409 U.S. 63, 70 (1972). Presently, a process constitutes statutory subject matter if it produces “a useful, concrete and tangible result.” State St. Bank & Trust Co. v. Signature Fin. Group, Inc., 149 F.3d 1368, at 1373 (Fed. Cir. 1998). The best interpretation of this standard is that a process must at least act upon physical entities – whether they consist of matter, energy, or some combination of both – to constitute statutory subject matter. For an overview of the history of the physicality requirement as it relates to process inventions, see Christopher L. Ogden, Patentability of Algorithms After State Street Bank: The Death of the Physicality Requirement, 83 JPTOS J. Pat. & Trademark Off. Soc’y 491, 497-506 (2001). Courts in at least some software patent cases have declined to define the term “process” solely in terms of actions performed upon physical entities. For example, in In re Schrader, the Federal Circuit stated in dictum that the “subject matter transformation or reduction requirement [for processes] is not limited to physical activity or objects but rather encompasses “‘changes to intangible subject matter representative of or constituting physical activity or objects….’” In re Schrader, 22. F.3d 290, 295 n.12 (Fed. Cir. 1994). Furthermore, some have argued that the Federal Circuit, through the State Street and Excel opinions, has eliminated the physicality requirement for process inventions. See, e.g., Symposium: The Post-Industrial Patent System, supra note 132, at 4. To the extent that State Street and Excel eliminate or weaken the physicality requirement, this author agrees that such a step is a move in the wrong direction. See supra notes 118, 121 and infra Section V.B.1. 155. See generally Patents, supra note 4, at ch. 4. 156. See, e.g., State St. Bank & Trust Co. v. Signature Financial Group, Inc., 149 F.3d 1368,at 1375 (Fed. Cir. 1998) (“The question of whether a claim encompasses statutory subject matter should not focus on which of the four categories of subject matter a claim is directed to…but rather on the essential characteristics of the subject matter, in particular, its practical utility”); see also In re Ziegler, 992 F.2d 1197, 1201 (Fed. Cir. 1993) (citing Cross v. Iizuka, 753 F.2d 1040 1044); Nelson v. Bowler, 626 F.2d 853, 856 (C.C.P.A. 1980) (“‘Practical utility’ is a shorthand way of attributing ‘“real-world’” value to claimed subject matter. In other words, one skilled in the art can use a claimed discovery in a manner which provides some immediate benefit to the public.”); Malta v. Schulmerich Carillons, Inc., 952 F.2d 1320, 1341 n.5 (Fed. Cir. 1991) (“The patent system is directed to practical utility, not to basic research.”). 157. Patent law uses the term “embodiment” to refer to a physical product or process that has the features defined by a patent claim. A particular physical chair, for example, may be an embodiment of a claimed chair design. Thomas Edison’s light bulb invention, for example, has been implemented in millions of particular embodiments having a wide variety of shapes, sizes, and other physical properties, although all of them share the basic physical structure of the invention. In general, the claims of a patent describe the invention and the specification of the patent describes embodiments of the claimed invention. 158. See, e.g., Examination Guidelines for Computer-Related Inventions, U.S. Patent & Trademark Office, 61 Fed. Reg. 7478 (U.S. Pat. & Trademark Off. Feb. 28, 1996) (requiring that the subject matter sought to be patent “must have a practical application,” thereby “limit[ing] patent protection to inventions that possess a certain level of ‘real world’ value, as opposed to subject matter that represents nothing more than an idea or concept”). The utility requirement and the statutory subject matter requirement are closely intertwined and often analyzed together. For example, a process constitutes statutory subject matter only if it produces a “useful, concrete, and tangible result.” State St. Bank & Trust Co., 149 F.3d at 1373. 159. U.S. Patent No. X72X (issued Mar. 14, 1794). 160. One example of which may be found in U.S. Patent No. 403,335 (issued May 14, 1889). 161. Because a process is, by definition, a sequence of steps, a process claim is not necessarily limited in scope to any particular machinery for carrying out the process. See, e.g., Cochrane, 94 U.S. at 780, 787-88 (1877). As a practical matter, however, process claims historically have been required to recite physical structure either for carrying out the claimed process or for being acted upon by the claimed process in order for such claims to satisfy the statutory subject matter and utility requirements. As described in more detail above in Section III.G, however, the advent of software has made it possible to adequately describe processes that have practical utility without using physical terms. 162. Corning v. Burden, 56 U.S. (15 How.) 252, 267-68 (1854). 163. See, e.g., Le Roy v. Tatham, 55. U.S. (14 How.) 156, 174-5 (1853). 164. See, e.g., Diamond v. Chakrabarty, 447 U.S. 303, 309 (1980) (“The laws of nature, physical phenomena, and abstract ideas have been held not patentable.”); Funk Bros. Seed Co. v. Kalo Inoculant Co., 333 U.S. 127, 130 (1948). 165. See, e.g., Gottschalk v. Benson, 409 U.S. 63, 67 (1972); Tol-O-Matic v. Proma Produkt-Und Mktg. Gesellschaft m.b.H., 945 F.2d 1546, 1552 (Fed. Cir. 1991); see also Diamond v. Diehr, 450 U.S. 175, 185 (1981). 166. See, e.g., Le Roy, 55. U.S. at 175 (“[T]he processes used to extract, modify, and concentrate natural agencies, constitute the invention. The elements of the power exist; the invention is not in discovering them, but in applying them to useful objects.”); Funk Bros. Seed Co., 333 U.S. at 130; Mackay Radio & Tel. Co. v. Radio Corp. of Am., 306 U.S. 86, 94 (1939). 167. Conception is typically considered to be a “standard” that is applied in certain circumstances rather than a “requirement” for patentability. The Patent Office, for example, does not require any proof of conception during the prosecution of a patent application, but rather relies on the inventor’s oath or declaration attesting to the fact that the inventor invented the claimed invention. See 35 U.S.C. § 115, 37 C.F.R. 1.63, Manual of Pat. Examining Proc. § 602. As a procedural matter, conception is only at issue when a third party disputes the inventorship of a patent or patent application, such as in an interference or in an invalidity defense in an infringement suit. I treat conception as a requirement, however, because there is no invention absent conception. Conception is therefore effectively a substantive legal requirement for patentability despite the fact that there currently is no procedural mechanism in place to enforce it during ex parte patent prosecution. 168. Mergenthaler v. Scudder, 11 App. D.C. 264, 276 (1897). Conception is a mental act. Burroughs Wellcome Co. v. Barr Lab., 40 F.3d 1223, 1232 (Fed. Cir. 1994) (“For conception, we look not to whether one skilled in the art could have though of the invention, but whether the alleged inventors actually had in their minds the required definite and permanent idea.”). 169. Burroughs Wellcome Co. v. Barr Lab., 40 F.3d at 1227-28. 170. See id. at 1228; see also Fiers v. Revel, 984 F.2d 1164, 1169 (Fed. Cir. 1993) (“Conception of a substance claimed per se without reference to a process requires conception of its structure, name, formula, or definitive chemical or physical properties.”); Amgen, Inc. v. Chugai Pharmaceutical Co., 927 F.2d 1200, 1206 (Fed. Cir. 1991). 171. See Alpert v. Slatin, 49 C.C.P.A. 1343, 1347 (C.C.P.A. 1962) (“Conception of an inventive process involves proof of mental possession of the steps of an operative process and, if necessary, of means to carry it out to such a degree that nothing remains but routine skill for effectuation thereof.”); accord Rey-Bellet v. Engelhardt, 493 F.2d 1380 (C.C.P.A. 1974); see also Amax Fly Ash Corp. v. United States, 206 Ct. Cl. 756, 770 (1975). 172. See Burroughs Wellcome Co., 40 F.3d at 1228; see also Technitrol, Inc. v. United States, 194 Ct. Cl. 596, 609 (1971). In his treatise on patent law, Walker on Patents, Walker notes that “[a] mere idea is not conception” and that “[u]ntil the entire conception is complete and is ready to be incorporated in a practical embodiment, there is no available and complete conception of the invention within the meaning of the patent law.” 1 A.W. Deller, Deller’s Walker on Patents § 75 356-57 (Anthony William Deller ed., 2d ed. 1964). 173. See Markman v. Westview Instruments, 517 U.S. 370, 373 (1996) (“A claim covers and secures a process, a machine, a manufacture, a composition of matter, or a design, but never the function or result of either, nor the scientific explanation of their operation.”) (quoting 6 E. Lipscomb , Lipscomb’s Walker on Patents 21:17 at 315-16 (E. Lipscomb, ed., 3d ed. 1985); Fiers, 984 F.2d at 1169); Hitzeman v. Rutter, 243 F.3d 1345, 1356 (Fed. Cir. 2001) (“An idea is definite and permanent when the inventor has a specific, settled idea, a particular solution to the problem at hand, not just a general goal or research plan he hopes to pursue.”) (quoting Burroughs Wellcome Co., 40 F.3d at 1228); Amgen, Inc., 927 F.2d at 1206; Fiers, 984 F.2d at 1169; Rex Chainbelt Inc. v. Borg-Warner Corp., 477 F.2d 481, 491-92 (7th Cir. 1973); Amax Fly Ash Corp., 206 Ct. Cl. at 768; Field v. Knowles, 183 F.2d 593, 611 (C.C.P.A. 1950) (“It is not sufficient that the result to be obtained be conceived, but it is required that there be conceived and disclosed the means provided to accomplish that result….”); Land v. Dreyer, 33 C.C.P.A. 1108, 1113 (C.C.P.A. 1946) (“It is not sufficient [to satisfy the conception requirement], therefore, to show that a party claiming an invention has conceived a result to be obtained; the patentable thing is the means provided and disclosed by him to accomplish that results.”); Knapp v. Morss, 150 U.S. 221, 227 (1893); Morton v. N.Y. Eye Infirmary, 17 F. Cas. 879, 881 (No. 9865) (S.D.N.Y. 1862) (No. 9865). 174. See Mackay Radio & Tel. Co. v. Radio Corp. of Am., 306 U.S. 86, 94 (1939) (“While a scientific truth, or the mathematical expression of it, is not a patentable invention, a novel and useful structure created with the aid of knowledge of scientific truth may be.”); Morton, 17 F. Cas. at 884. 175. Markman., 517 U.S. at 373. 176. Mergenthaler v. Scudder, 11 App. D.C. 264, 276 (1897). 177. Cameron & Everett v. Brick, 1871 Dec. Comm’r Pat. 89, 90 (Apr. 1, 187l). 178. 35 U.S.C. § 112 ¶ 1 (2000). 179. In re Barker, 559 F.2d 588, 592 n.4 (C.C.P.A. 1977). 180. See Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1563 (Fed. Cir. 1991). The Federal Circuit is increasingly emphasizing the importance of the written description requirement. See, e.g., Enzo Biochem, Inc. v. Gen-Probe Inc., 296 F.3d 1316, 1324 (Fed. Cir. 2002); Regents of Univ. of Cal. v. Eli Lilly & Co., 119 F.3d 1559 (Fed. Cir. 1997); Fiers v. Revel, 984 F.2d 1164, 1170-71 (Fed. Cir. 1993); University of Cal. v. Eli Lilly & Co., 119 F.3d 1559 (Fed. Cir. 1997). The Federal Circuit’s trend towards enforcing the written description requirement distinctly and vigorously has drawn sharp criticism. See, e.g., Harris A. Pitlick, The Mutation on the Description Requirement Gene, 80 J. Pat. & Trademark Off. Soc’y 209 (1998). 181. 35 U.S.C. § 112 ¶ 1. 182. See Fiers, 984 F.2d at 1170-71 (holding that a written description of a DNA sequence requires “precise definition, such as by structure, formula, chemical name, or physical properties,” because conception of a DNA sequence requires the DNA sequence to be conceived in physical terms, and “one cannot describe what one has not conceived”); accord Eli Lilly & Co., 119 F.3d at 1568 (affirming invalidity of claims which defined genetic material merely in terms of its function rather than its physical structure because such a definition “is only an indication of what the gene does, rather than what it is”). Although essentially all written description cases have involved product claims, it appears that the written description requirement is satisfied for a process claim by describing the particular steps that comprise the process. See In re Kaslow, 707 F.2d 1366 (Fed. Cir. 1983). An important exception to the general rule that product inventions be described in terms of their physical structure is described in Section I infra. 183. See Vas-Cath, Inc., 935 F.2d at 1563-64 (“The purpose of the ‘written description’ requirement is broader than to merely explain how to ‘make and use’; the applicant must also convey with reasonable clarity to those skilled in the art that, as of the filing date sought, he or she was in possession of the invention.”). 184. See Fiers, 984 F.2d at 1169. Furthermore, it is not sufficient merely to describe an invention in terms of its objectives or goals. See In re Wilder, 736 F.2d 1516, 1521 (Fed. Cir. 1984). A purely functional description may, however, be sufficient if the function described is known to correlate to a specific structure. See Guidelines for the Examination of Patent Applications Under the 35 U.S.C. § 112, ¶ 1 ‘Written Description’ Requirement, § II.A.1.3.a, 66 Fed. Reg. 1099 (U.S. Pat. & Trademark Off. Jan. 5, 2001). 185. See, e.g., Reiffin v. Microsoft Corp., 214 F.3d 1342, 1345 (Fed. Cir. 2000) (“The purpose of [the written description requirement] is to ensure that the scope of the right to exclude, as set forth in the claims, does not overreach the scope of the inventor’s contribution to the field of art as described in the patent specification.”). 186. 35 U.S.C. §112 ¶ 2. 187. See Bell Communications Research v. Vitalink Communications Corp., 55 F.3d 615, 619 (Fed. Cir. 1995); Constant v. Advanced Micro-Devices, Inc., 848 F.2d 1560, 1571 (Fed. Cir. 1988). 188. Other claims formats, such as the product-by-process claim format, are used relatively infrequently and are not relevant to the present discussion. A product-by-process claim characterizes a product in terms of the process by which it is made. The proper interpretation of product-by-process claims is currently unclear due to conflicting decisions from the Federal Circuit in Scripps Clinic & Research Found. v. Genentech, Inc., 927 F.2d 1565, 1583 (Fed. Cir. 1991) (holding that product-by-process claims are not limited in scope to products produced by the process recited in the claims) and Atl. Thermoplastics Co. v. Faytex Corp., 970 F.2d 834 (Fed. Cir. 1992) (holding that product-by-process claims are limited in scope to products produced by the process recited in the claims). For an overview of the law of product by process claims, see Patents, supra note 4 , at § 8.05, at 172; Brian S. Tomko, Comment, Scripps Or Atlantic: The Federal Circuit Squares Off Over The Scope Of Product-By-Process Patents, 60 Brook. L. Rev. 1693 (1995). 189. 35 U.S.C. § 112 ¶ 6 (“An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.”). 190. See, e.g., Atl. Thermoplastics Co., Inc., 970 F.2d at 845 (noting that “the PTO and the CCPA [have] acknowledged product-by-process claims as an exception to the general rule requiring claims to define products in terms of structural characteristics.”). See also Robert C. Faber, Landis on Mechanics of Patent Claim Drafting (4th ed. 2002), at X-45 (“[W]hile an apparatus claim is not merely a catalog of parts, it absolutely must include a catalog of parts. It is the cataloging of the parts that gives rise to what we call the positive recitation of the elements. That is, each structural element in the claim must be set forth directly and independently of every other element.”); Examination Guidelines for Computer-Related Inventions, supra note 158 (“For [claims to computer software] products, the claim limitations will define discrete physical structures. The discrete physical structures may be comprised of hardware or a combination of hardware and software.”). 191. See supra note 188. 192. Hewlett-Packard Co. v. Bausch & Lomb Inc., 909 F.2d 1464, 1468 (Fed. Cir. 1990). See also Faber, supra note 190, at X-47 (“In apparatus claims, we are concerned solely and exclusively with a definition of structure. By structure I mean hardware, something you can touch, something you can feel, something you can manipulate. We are not interested in function, and the function of an element cannot be used as a substitute for the definition of the structure of the element itself.”). 193. See Patents, supra note 4, at 8-79 (“A ‘true’ product claim is one in which the product is defined in terms of structural characteristics only.”). 194. See, e.g., Johnston v. IVAC Corp., 885 F.2d 1574, 1578 n.3 (Fed. Cir. 1989); Hybritech Inc. v. Monoclonal Antibodies, Inc., 802 F.2d 1367, 1379 (Fed. Cir. 1986) (“It is axiomatic that for prior art to anticipate under § 102 it has to meet every element of the claimed invention . . .”). 195. See, e.g., SRI Int’l v. Matsushita Elec. Corp., 775 F.2d 1107, 1118 (Fed. Cir. 1985). One exception to this general rule is the “reverse doctrine of equivalents,” according to which a product that has the literal structure recited in a claim may avoid infringement if the product works in a substantially different way than the patented invention. Id. 196. See supra Section IV.C. 197. See In re Donaldson Co., 16 F.3d 1189, 1195 (Fed. Cir. 1994) (en banc). 198. The primary exception to this rule is that the accused product may infringe the claim under the “doctrine of equivalents.” See generally Festo Corp. v. Shoketsu Kinzoku Kogyo Kabushiki Co., 532 U.S. 722 (2002); Patents, supra note 4, at § 18.04. 199. In general, the scope of a patent scope should be no greater than the scope of enablement. See, e.g., In re Moore, 58 C.C.P.A. 1042, 1047 (C.C.P.A. 1971) (“The relevant inquiry may be summed up as being whether the scope of enablement provided to one of ordinary skill in the art by the disclosure is such as to be commensurate with the scope of protection sought by the claims.”); accord In re Hogan, 559 F.2d 595 (C.C.P.A. 1977). 200. O’Reilly v. Morse, 56 U.S. 62, 112 (1854). 201. As used herein, the “facial scope” of a claim refers to the scope of a claim that is defined by the plain meaning of the claim as worded. For example, the facial scope of a pure means-plus-function claim encompasses any and all devices that perform the functions recited in the claim, because the plain meaning of the claim as worded encompasses any and all such devices. As used herein, the “actual scope” of a claim refers to the scope of the claim as correctly interpreted under all applicable patent law principles. For example, although the facial scope of a pure means-plus-function claim encompasses any and all devices that performed the functions recited in the claim, the actual scope of such a claim is limited (by 35 U.S.C. § 112 ¶ 6) to the particular physical structure recited in the specification for performing the recited functions and equivalents thereof. 202. See O’Reilly, 56 U.S. at 113. 203. See id. at 119-20. 204. See Valmont Indus., Inc., v. Reinke Mfg. Co., 983 F.2d 1039, 1042 (Fed. Cir. 1993). 205. See Johnston v. IVAC Corp., 885 F.2d 1574, 1580 (Fed. Cir. 1989); O.I. Corp. v. Tekmar, 115 F.3d 1576, 1583 (Fed. Cir. 1997). Courts historically have been skeptical of functional claim language due, inter alia, to its facial breadth. In Halliburton Oil Well Cementing Co. v. Walker, 329 U.S. 1 (1946), for example, the U.S. Supreme Court invalidated a patent claim to an apparatus for measuring the depth of oil wells because the invention was claimed using functional language “at the point of novelty.” Id. at 8. The available evidence indicates that 35 U.S.C. § 112 ¶ 6 was enacted to overrule Halliburton’s prohibition against the use of functional language in patent claims, while ensuring that functional claim language is limited in scope to the particular physical structures recited in the patent specification and equivalents thereof. See P.J. Federico, Commentary on the New Patent Act, 35 U.S.C.A. 1, 25-26 (1954), reprinted at 75 J. Pat. & Trademark Off. Soc’y 161 (1993). 206. Patent law expressly disavows any requirement that an invention be invented in a particular way to merit patent protection. See, e.g., 35 U.S.C. § 103(a) (“Patentability shall not be negatived by the manner in which the invention was made.”). Despite this fact, the rules of patentability and claim scope reflect implicit assumptions about requirements of real-world inventive processes. 207. See generally references cited in supra note 2. 208. Statements made herein regarding the courts are also applicable to the United States Patent and Trademark Office (USPTO) insofar as the USPTO interprets and influences the direction of substantive patent law. 209. See, e.g., In re Bernhart, 417 F.2d 1395 (C.C.P.A. 1969) (means-plus-function claim held to be patentable subject matter due to recitation of physical terms such as “computer”); In re Noll, 545 F.2d 141 (C.C.P.A. 1976) (means-plus-function claims held to be directed to statutory subject matter when the specification recited conventional computer hardware elements in conjunction with a computer program for performing the functions recited in the claims); In re Taner, 681 F.2d 787 (C.C.P.A. 1982) (method claims held to be directed to more than a mere mathematical algorithm and therefore constitute statutory subject matter where the claims recited application of the method to seismic energy waves and other physical entities); State Street Bank & Trust Co., 149 F.3d at 1368 (means-plus-function claim held to be patentable subject matter due to physical structure imported into claim by reference to specification); Diehr, 450 U.S. at 188 (mathematical equation applied to a process for curing rubber held to be patentable subject matter); In re Alappat, 33 F.3d 1526, 1577 (means-plus-function claim held to be patentable subject matter due to physical structure imported into claim by reference to specification); In re Warmerdam, 33 F.3d 1354 (Fed. Cir. 1994) (affirming rejection of method claims which recited no physical structure and reversing rejection of product claim directed to a “machine”); In re Lowry, 32 F.3d 1579 (Fed. Cir. 1994) (holding claim directed to a “memory” to be statutory subject matter even though claim defined contents of memory in terms of logical entities); In re Trovato, 42 F.3d 1376 (Fed. Cir. 1994), vacated by 60 F.3d 807 (Fed. Cir. 1995) (means-plus-function claims which recited invention in terms of functional elements held to be nonstatutory subject matter due to specification’s failure to recite any corresponding structure); State St. Bank & Trust Co., 149 F.3d at 1373 (means-plus-function claim held to be statutory subject matter due to definition of invention in terms of physical components in specification). Cf., Parker v. Flook, 437 U.S. 584, 594 (1978) (holding method for updating an alarm limit on a catalytic chemical conversion of hydrocarbons not to be statutory subject matter despite reference in claim to “the catalytic chemical conversion of hydrocarbons”); In re Christensen, 478 F.2d 1392 (C.C.P.A. 1973) (holding method for determining the porosity of a subsurface formation in situ to be non-statutory subject matter because the claimed invention’s sole point of novelty was a mathematical formula); In re Walter, 618 F.2d 758 (C.C.P.A. 1980) (holding method for cross-correlating electrical signals representing seismic waves not to be directed to statutory subject matter). 210. The courts have recognized the need to look beyond the language of the claims, asserting that “semantogenic considerations preclude a determination based solely on words appearing in the claims. In the final analysis under § 101, the claimed invention, as a whole, must be evaluated for what it is.” In re Sarkar, 588 F.2d 1330, 1333 (C.C.P.A. 1978). This recognition has not stopped the courts, however, from applying a formal analysis based solely or primarily on the language of the claims in many cases. 211. See, e.g., Goodman et al., supra note 3, at 357-78 (arguing that the holding in In re Trovato implies that a software invention may satisfy the statutory subject matter requirement merely by claiming the invention in terms of a functionally equivalent hardware implementation); Durham, supra note 92, at 1485 (arguing that, according to the Alappat decision, “[a]ll the applicant must do . . . is draft the claims in terms of the physical hardware that performs the steps of the algorithm, and the result will be a ‘new machine.’”); Shawn McDonald, Patenting Floppy Disks, or How the Federal Circuit’s Acquiescence has Filled the Void Left by Legislative Inaction, 3 Va. J.L. & Tech. 9, 38 (1998). 212. See Section III.D. 213. See supra n.205. 214. See, e.g., O.I. Corp. v. Tekmar, 115 F.3d 1576, 1583 (Fed. Cir. 1997); In re Alappat, 33 F.3d at 1583 (Plager, J. concurring). 215. See supra Section IV.E.2. 216. See Atlantic Thermoplastics, 947 Co. v. Faytex Corp., 974 F.2d 1279, 1283-4 (Fed. Cir. 1992) (Newman, J., dissenting) (recognizing the long-standing acceptance of product-by-process claims). “The premise of such claims has been called the Rule of Necessity, for it provides a way of patenting inventions or discoveries whose structure is not sufficiently known or knowable to be described objectively.” Id. at 1279. 217. See, e.g., In re Painter, 1891 C.D. 200, 57 O.G. 999 (Comm’r of Pats. 1891) (holding that the right to a patent should not be denied, and that the use of the product-by-process claim format is appropriate, in the cases of an invention which “cannot be properly defined and discriminated from prior art otherwise than by reference to the process of producing it”); accord Funk Bros. Seed Co. v. Kalo Inoculant Co., 333 U.S. 127, 138 (1948) (Burton, J., dissenting); In re Bernhart, 417 F.2d 1395, 1399 (C.C.P.A. 1969). Furthermore, “[w]hen mathematical formulae are the standard way of expressing certain functions or apparatus, it is appropriate that mathematical terms be used” to claim such apparatus. Arrhythmia Research Tech., Inc. v. Corazonix Corp., 958 F.2d 1053, 1060 (Fed. Cir. 1992). 218. See infra Section V.(2)b. 219. See Goodman et al., supra note 3, at 357 (“It is no wonder that in the patent applications of Trovato, ‘no computer architecture is provided, no circuit diagram is revealed, and no hardware at all receives more than brief mention.’ These are completely unnecessary for programming a computer, and programming a computer inherently makes the circuitry – this is how a computer operates.”) (emphasis in original). 220. By a “pure” software invention I mean one which the inventor has conceived of solely in terms of its logical structure and which may be enabled by a description couched solely in terms of the invention’s logical structure. 221. Electrical signals may qualify as physical structure for purposes of satisfying the subject-matter requirements of 35 U.S.C. § 101. See In re Sherwood, 613 F.2d. 809, 819 (C.C.P.A. 1980) (“seismic traces [recited in the claims] are electrical signals from geophones, i.e., physical apparitions, or particular patterns of magnetization on magnetic tape, i.e., the pattern of the magnetization being a physical manifestation, or a physical line on a paper chart”); Arrhythmia Research, 958 F.2d at 1053 (holding that a process for manipulating and analyzing electrocardiograph signals constituted statutory subject matter). 222. See Examination Guidelines for Computer-Related Inventions, supra note 158, at 7478-7492 for analysis of similar examples in the software context. 223. State St. Bank & Trust Co. v. Signature Fin. Group, 149 F.3d 1368, 1375 (Fed. Cir. 1998). 224. The question of claim scope in general has received much less attention than the question of patentability. See generally Cohen & Lemley, supra note 143, at 1 (arguing for narrow interpretation of software patent claims); Merges & Nelson, supra note 143, at 840 (noting the relative dearth of scholarly writing on patent claim scope). 225. Because the proper scope of a claim is one that is commensurate with the scope of enablement, a claim is overbroad if its scope is broader than the scope of enablement and underbroad if its scope is narrower than the scope of enablement. 226. See supra Section IV.C. 227. See, e.g., Stern, supra note 25, at 185. 228. For more information about object-oriented software, see supra Section III.D.3. 229. For example, a claim that characterizes an otherwise novel design so broadly that it encompasses designs within the prior art is not novel and therefore not patentable. See, e.g., Kalman v. Kimberly-Clark Corp. 713 F.2d 760, 770-71 (Fed. Cir. 1983). Furthermore, an issued patent claim is presumed valid (35 U.S.C. § 282 (2003)) and should be construed to avoid encompassing prior art. Modine Mfg. Co. v. United States Int’l Trade Comm’n, 75 F.3d 1545, 1557 (Fed. Cir. 1996); Texas Instruments Inc. v. United States Int’l Trade Comm’n, 871 F.2d 1054, 1065 (Fed. Cir. 1989). The prior art therefore limits both patentability and claim scope. 230. See Section IV.C, supra. Software patents may also be susceptible to particularly broad interpretations under the doctrine of equivalents. See Cohen & Lemley, supra note 143, at 39-50. 231. I say “primarily” because a process that applies to and is defined in terms of a particular physical structure (such as a material on which the process operates) may serve as prior art against a subsequent software invention that is defined without reference to physical structure. Furthermore, a physical product may serve as prior art against a software program in the (rare) case that the product embodies the same logical structure as the software program. 232. This lack of relevant prior art may cause claims for incremental software inventions to have the relatively broad scope typically affording only to “pioneer” inventions. See, e.g., Symposium, Internet Business Model Patents: Obvious by Analogy, 7 Mich. Telecomm. & Tech. L. Rev. 253 (2001). For a definition of “pioneer patent,” see Westinghouse v. Boyden Power Brake Co., 170 U.S. 537, 561-62 (1898). 233. The same may be true of business method patents. See, e.g., Symposium, Scope-of-Protection Problems with Patents and Copyrights on Methods of Doing Business, 10 Fordham Intell. Prop. Media & Ent. L.J. 105, 111-112 (1999). 234. For example, although the Federal Circuit held that the means-plus-function claim in Alappat was directed to statutory subject matter, the court did not elaborate on the range of physical structures that are enabled by a specification which merely indicates that the invention may be practiced on a “general-purpose computer.” Query, for example, whether such a claim would be infringed by a device performing the claimed functions but having a radically different physical structure, such as a biocomputer. See, e.g., Texas Instruments v. United States Int’l Trade Comm’n, 805 F.2d 1558, 1572 (Fed. Cir. 1986) (holding accused device to be noninfringing which performed the functions claimed in a means-plus-function claim using subsequently developed means which differed significantly from the means disclosed in the patent specification). 235. See generally Brad A. Schepers, Note, Interpretation of Patent Process Claims in Light of the Narrowing Effect of 35 U.S.C. § 112(6), 31 Ind. L. Rev. 1133 (1998). 236. Currently, software programs may constitute statutory subject matter either as machines, articles of manufacture, or processes, depending upon the form in which they are claimed. For examples of each, see, e.g., In re Alappat, 33 F.3d 1526 (Fed. Cir. 1994) (claiming software as a machine); In re Beauregard, 53 F.3d 1583 (Fed. Cir. 1995), described in Gregory A. Stobbs, Software Patents, 172-77 (2d ed. 2000) (claiming software as electromagnetic signals tangibly stored in a computer-readable medium such as a floppy diskette); Arrhythmia Research Technology, Inc. v. Corazonix Corp., 958 F.2d 1053, 1058 (Fed. Cir. 1992) (claiming software as a process). 237. One reason to base software patent protection on the legal rules that have developed for product inventions, rather than process inventions, is that the law of product patents is more well-developed and well-settled than the law of process patents. The courts historically “have had more conceptual problems with process claims than with product claims.” Patents, supra note 4, at § 1.03. The law of product inventions therefore serves as a more stable foundation from which to build a framework of protection for software. More generally, to the extent that the process that is used to invent product inventions is analogous to the process used to design the logical structure of software programs, and to the extent that the traditional rules of patentability and claim scope may be translated to protect logical entities in a manner that is analogous to the way in which patent law traditionally has protected physical entities (products), such a translation is justified. Rules derived in this way to apply to logical entities are equally applicable to processes because a process is a special case of a logical entity. 238. The claims provided in this section are provided merely to illustrate the form that claims would be allowed to take according to the rules proposed herein, and are not intended to satisfy all of the requirements for patentability, such as novelty, nonobviousness, and utility. 239. For an argument that object-oriented software should be considered patentable subject matter, see Keith Stephens & John P. Sumner, Software Objects: A New Trend in Programming and Software Patents, 12 Santa Clara Computer & High Tech. L.J. 1 (1996). 240. At least one early court decision placed such a burden on patent applicants. In re Prater, 415 F.2d 1393 (C.C.P.A. 1969). The Federal Circuit, however, gradually began to realize that patent protection should not be denied to certain inventions merely because they “operate according to,” and are claimed in terms of, an algorithm. See, e.g., In re Iwahashi, 888 F.2d 1370, 1375 (Fed. Cir. 1989). In In re Alappat, 33 F.3d at 1540, the Federal Circuit noted that the lack of structure in the specification in cases such as Abele, Pardo, and Walter justified interpreting the apparatus claims in those cases as if they were method claims, and pointed to the presence of structure in Alappat’s specification as a reason to interpret Alappat’s apparatus claims as apparatus claims. Id. at 1541. Furthermore, the court held Alappat’s claims to be directed to statutory subject matter because of the structure that Alappat recited in the specification to support the claims. Id. at 1543-44. The court’s reasoning in Alappat implicitly placed a burden on the patent applicant to recite structure at a fairly detailed level in the patent application to support the elements of a means-plus-function claim, perhaps even if the specification would have been enabling absent the recitation of such structure. 241. This is consistent with current Patent Office practice, according to which the fact that a program performs a physical transformation within a computer “alone does not distinguish a statutory computer process from a non-statutory computer process. What is determinative is not how the computer performs the process, but what the computer does to achieve a practical application.” Examination Guidelines for Computer-Related Inventions, supra note 158, at 7484. 242. See State St. Bank & Trust Co., 149 F.3d. at 1375 (the statutory subject matter determination does “not focus on which of the four categories of subject matter a claim is directed to . . . – process, machine, manufacture, or composition of matter – but rather on the essential characteristics of the subject matter, in particular, its practical utility.”). 243. See Durham, supra note 92, at 1423 (“My own proposal is to recognize that the programmer’s art is the art of converting an often non-technological plan (such as a particular scheme for managing a family of mutual funds) into the kind of logical structure executed by a computer. Fashioning a logical structure is, like fashioning a physical structure, a ‘technological’ endeavor, at least when the purpose is to produce a useful computer program.”). 244. For a detailed discussion of the relationship of 35 U.S.C. § 112 ¶ 6 to the proposals made herein, see infra Section V.C. 245. Guidelines for the Examination of Patent Applications Under the 35 U.S.C. § 112, ¶ 1 ‘Written Description’ Requirement, § II.A.3.a, U.S. Patent & Trade Office (2001). 246. See, e.g., N. Telecom, Inc. v. Datapoint Corp., 908 F.2d 931, 941 (Fed. Cir. 1990), cert. denied, 498 U.S. 920 (1990). 247. See, e.g., Fonar Corp. v. GE, 107 F.3d 1543, 1549 (Fed. Cir. 1997); In re Hayes Microcomputer Prods. Inc. Patent Litigation, 982 F.2d 1527, 1534-38 (Fed. Cir. 1992); In re Donohue, 550 F.2d 1269, 1271 (C.C.P.A. 1977). 248. See supra Section III. 249. See 35 U.S.C. § 102 (1994). The comments made herein with respect to the novelty requirement are equally applicable to patent law’s “nonobviousness” requirement. See id. § 103. 250. See, e.g., Hybritech Inc. v. Monoclonal Antibodies, Inc., 802 F.2d 1367, 1379 (Fed. Cir. 1986). 251. See In re Donohue, 766 F.2d 531, 533 (Fed. Cir. 1985). 252. See, e.g., Del Mar Eng’g Laboratories v. Physio-Tronics, Inc., 642 F.2d 1167, 1172 (9th Cir. 1981); Schroeder v. Owens-Corning Fiberglas Corp., 514 F.2d 901, 903-04 (9th Cir. 1975). 253. See, e.g., In re Schrader, 22 F.3d 290 (Fed. Cir. 1994); In re Prater, 415 F.2d 1393 (C.C.P.A. 1969). 254. See Durham, supra note 92, at 1524. 255. Whether a particular claim should be interpreted broadly to encompass any device or process that implements the claimed logical structure, or more narrowly to encompass only general-purpose computers that implement the claimed logical structure, is a difficult question that would need to be decided on a case-by-case basis. For a detailed description of claim scope according to the proposal put forth in this section, see infra Section V.C. 256. The legal standard for infringement is the same as that for novelty. See, e.g., Patents, supra note 4, § 3.02[1]; Knapp v. Morss, 150 U.S. 221, 228 (1893) (“[T]hat which infringes, if later, would anticipate if earlier.” ) 257. A similar methodology for making patentability determinations for floppy disk claims is proposed in Richard H. Stern, An Attempt to Rationalize Floppy Disk Claims, 17 J. Marshall J. Computer & Info. L. 183, at 198-99 (1998). 258. This is consistent with current Patent Office procedure. See Examination Guidelines for Computer-Related Inventions, U.S. Patent & Trademark Office, 61 Fed. Reg. 7478 (Feb. 28, 1996). 259. See id. 260. See In re Lowry, 32 F.3d 1579, 1584 (Fed. Cir. 1994), for an example of a nonobviousness analysis comparing a claimed data structure to a prior art data structure. 261. See, e.g., In re Fisher, 427 F.2d 833, 839 (C.C.P.A. 1970) (35 U.S.C. § 112 ¶ 1 requires that “the scope of the claims must bear a reasonable correlation to the scope of enablement provided by the specification to persons of ordinary skill in the art."); accord In re Geerdes, 491 F.2d 1260 (C.C.P.A. 1974). 262. See supra note 247. 263. See supra note 234 and accompanying text for related discussion on this topic. 264. Although such a claim would be unpatentable for several reasons, in the present discussion I focus only on the claim’s use of functional language for purposes of simplicity. 265. See supra note 205. 266. For an excellent overview of the history and current state of the step-plus-function doctrine, as well as evidence for the applicability of 35 USC § 112 ¶ 6 to process claims, see Schepers, supra note 235. 267. See O.I. Corp. v. Tekmar Co., Inc., 115 F.3d 1576, 1582-3 (Fed. Cir. 1997) (interpreting the single sentence of 35 U.S.C. § 112 ¶ 6 to correlate “means” with “structure” and “material” and to correlate “step” with “acts”). 268. Id. at 1583; Caterpillar Inc. v. Detroit Diesel Corp., 961 F. Supp. 1249, 1255 (N.D. Ind. 1996), aff’d, 194 F.3d 1336 (Fed. Cir. 1999) (unpublished) (35 USC § 112 ¶ 6 “applies to functional methods [sic] claims where the element at issue sets forth a step for reaching a particular result, but not the specific technique or procedure used to achieve the result.”). 269. See Schepers, supra note 235, at 1162 (“It is nothing less than remarkable that four and one-half decades have passed without the emergence of judicial guidance concerning how (or if) paragraph six applies to process or method claims.”). 270. See, e.g., Seal-Flex, Inc. v. Athletic Track & Court Constr.uction, 172 F.3d 836, 849 (Fed. Cir. 1999) (“Both acts and functions are often stated using verbs ending in ‘ing.’ For instance, if the method claim element at issue in this case had merely recited the ‘step of’ ‘spreading an adhesive tack coating,’ it would not have been clear solely from this hypothetical claim language whether ‘spreading’ was a function or an act. In such circumstances, claim interpretation requires careful analysis of the limitation in the context of the overall claim and the specification.”). Furthermore, the Federal Circuit has stated that “[i]f we were to construe every process claim containing steps described by an ‘ing’ verb, such as passing, heating, reacting, transferring, etc. into a step-plus-function limitation, we would be limiting process claims in a manner never intended by Congress.” O.I. Corp., 115 F.3d at 1583. 271. The decision of the Court of Customs and Patent Appeals in In re Cohn may be interpreted to stand for the proposition “that only those process steps which are truly ‘result-oriented’ and adequately defined within the specification will be subject to the effects of paragraph six.” Schepers, supra note 235, at 1155-56. 272. Similar arguments are often made in attempts to draw a dividing line between statutory and non-statutory subject matter. See, e.g., Whitmeyer, supra note 92, at 1103, 1138 (arguing that only “narrow algorithms” should be considered statutory subject matter, while “program flows” should not be considered statutory subject matter). 273. 91 F.3d 1580 (Fed. Cir. 1996). 274. 161 F.3d. 696 (Fed. Cir. 1998). 275. Greenberg, 91 F.3d. at 1583. 276. See id. 277. Personalized Media Communications, 161 F.3d. at 704.-705. 278. Id. at 705; followed by Katz v. AT&T Corp., 63 F. Supp. 2d 583, 592 (E.D. Pa. 1999) (“a structural term need not connote a precise physical structure to those of ordinary skill in the art to avoid a means-plus-function analysis, as long as it conveys a variety of structures that are referred to by that term.”). 279. See supra Section IV.C. 280. By “class of logical structures” I refer to logical structures having one or more shared structural properties, at least one example of which is known to those of ordinary skill in the art. In the context of a product claim, for example, a “chair leg” refers to a class of structures, at least one example of which is known to those of ordinary skill in the art, and therefore does not invoke § 112 ¶ 6. The claim term “chair leg” need not, however, be interpreted narrowly to any particular chair leg known to those of ordinary skill in the art at the time of the patent filing or issuance, but rather may be interpreted broadly to apply to any structure that qualifies as a “chair leg” because it has the structural properties that characterize the class of chair legs. 281. See Durham, supra note 92, at 1528 (“[T]he patent claim should reflect the art of programming; it should reflect the substantive details that belong to the programming art and that enable the technological implementation of the non-technological plan.”). 282. See, e.g., Chiappetta, supra note 6, at 94 (requiring that software be described in terms of the hardware on which it is implemented forces inventors to mischaracterize software innovations, thereby inhibiting the ability to describe and protect “the true nature” of software inventions under the patent laws). 283. See supra Section IV.E.2. 284. See Section . See Supra part III.G.III.G. 285. See generally http://www.verilog.com/; http://www.vhdl.org. Verilog became IEEE Standard 1364 in 1995. See also Goodman et al., supra note 3, at 357-360 (describing commercially-available tools that allow electrical engineers to design circuits in terms of the functions they perform). 286. Even the process of designing analog circuits is being automated. See, e.g., John G. Spooner, Shaking up the Art of Chip Design, CNET News.com(Apr. 19, 2002), available at http://news.com.com/2100-1001-886899.html (Apr. 19, 2002) (“Bucking tradition, start-up Barcelona Design is introducing software that automates aspects of analog-circuit design – a process long considered an art form by some engineers.”). See also Vinod Kathail et al., PICO: Automatically Designing Custom Computers, IEEE Computer Magazine, Sept. 2002, at 39-47 (describing the “program in, chip out” automated system for using techniques similar to computer programming to automate the design of optimized, application-specific computer systems). 287. See, e.g., John R. Thomas, Of Text, Technique, and the Tangible: Drafting Patent Claims Around Patent Rules, 17 J. Marshall J. Computer & Info. L. 219, 265 (1998) (suggesting that “[o]ne way out of this morass of confused jurisprudence would simply be to abolish the historical distinctions between artifact [product] and technique [process] in their entirety”). A patentee would still have the option, under my approach, of using the conventional product or process claim formats if desired in particular cases. 288. See, e.g., Davis, Martin, The Universal Computer, WW Norton & Co., New York 2000, supra note 74, at 164-165 (“Turing’s universal machine showed that the distinctness of these three categories [(machine, program, and data)] is an illusion.”). The final theoretical and technological breakthrough that enabled modern computers to be designed and constructed was the “stored program” concept, according to which both program instructions and data are stored in the same memory. See Ifrah, supra note 37, at 222-232. 289. See generally, Tim O’Reilly, The Internet Patent Land Grab, 43 Communications of the ACM 29-31 (2000). 290. See, e.g., Oracle Corporation Patent Policy, Patent & Trademark Office Software Patent Hearings (Jan. 26-27, 1994), available at http://www.jameshuggins.com/n/tek1/software_patent_oracle.htmlpf.ai.mit.edu/Patents/testimony/statements/oracle.statement.html (recommending that the “[p]rior art capabilities of PTO records . . . be vastly improved to confirm effectively the novelty and non-obviousness of software . . . that is the subject of [patent] applications”); Prepared Testimony and Statement for the Record of Jim Warren Before the Patent and Trademark Office, supra note 36 (recommending that a nationally-accessible collection of software prior art be made available, that the USPTO exercise much greater due diligence with regard to software patents, and that a large public advisory body be created to assist the Patent Office with its duties). 291. See, e.g., Gleick, supra note 36 (quoting a recommendation that Internet-related patents should have a term not exceeding two years); see Prepared Testimony and Statement for the Record of Jim Warren Before the Patent and Trademark Office, supra note 36 (recommending that the term of patent protection for software be limited to two years); Paley, supra note 22, at 306; Randall Davis et al., supra note 7, at 28. 292. See, e.g., Cohen & Lemley, supra note 143, at 1; Paley, supra note 22, at 343-346. 293. Cohen & Lemley, supra note 143. 294. Paley, supra note 22, at 332. 295. See id. at 334-5. 296. Symposium: Internet Business Model Patents: Obvious by Analogy, 7 Mich. Telecomm. & Tech. L. Rev. 253, 278 (2001). 297. See, e.g., Oracle Corporation Patent Policy, intra supra note 359 (recommending a six-month patent examination process); Stern, supra note 25, at 167183 (advocating for a petite patent system for algorithms with negligible examination). 298. See, e.g., Prepared Testimony and Statement for the Record of Jim Warren Before the Patent and Trademark Office, supra note 36; Simson L. Garfinkel, Patently Absurd, Wired (July 1994); available at http://www.wired.com/wired/archive/207/patents.html Paley, supra note 22, at 306. 299. See, e.g., The O’Reilly Network,. Internet Society Panel on Business Method Patents, (Oct. 23, 2000)), available at http://www.oreillynet.com/pub/a/policy/2000/10/23/isoc.html (explaining the USPTO’s “Business Method Patent Initiative,” which included: (1) improvements to patent examiners’ prior art searching capabilities; (2) the “Second Look,” according to which a primary level patent examiner takes a second look at business method patents before they issue; and (3) imposing a requirement that patent examiners use automated search tools to search for business method prior art.) (September 14, 2003). See also Business Methods Patent Initiative: An Action Plan (September 14, 2003), available at http://www.uspto.gov/web/offices/com/sol/actionplan.html (September 14, 2003).http://www.uspto.gov/web/offices/com/sol/actionplan.html. Furthermore, the American Inventors Protection Act, Pub. L. 106-113, modified U.S. patent law to require that most patent applications be published 18 months after they are filed (35 USC 154(d)), providing the public with earlier notice of the subject matter potentially covered by a patent and making it easier for the public to challenge the patentability of an invention claimed in a patent application. See 37 CFR 1.902–1.997. 300. Those who have stressed sui generis protection for software have recommended the need for a clearly-defined conceptual model of software to serve as the basis for such a system. See, e.g., Samuelson, supra note 9, at 1148 (“The first step in creating a sui generis statute for the protection of computer program innovations would be the development of an appropriate conceptual model about both the nature of the subject matter to be protected and the purposes to be served by a protection statute.”). For discussions of potential sui generis systems of intellectual property protection for software, see generally Phillips, supra note 44, at 997; Griem, supra note 8, at 145; Paley, supra note 22, at 306; Symposium: Toward a Third Intellectual Property Paradigm: Article: A Manifesto Concerning the Legal Protection of Computer Programs, supra note 3, at 2308. 301. Ifrah, supra note 37, at 227 (quoting Gaspard Monge, cited in L. Couffignal, La Cybernétique (Presses Universitaires De France 1963). 302. For excellent recommendations along these lines, see Jeffrey D. Ullman’s article Ordinary Skill in the Art, based upon the 2000 Knuth-Prize Lecture.(Nov. 16, 2000, updated May 16, 2001) Jeffrey D. Ullman, Ordinary Skill in the Art, available at http://www-db.stanford.edu/~ullman/pub/focs00.html (Nov. 16, 2000, updated May 16, 2001). | ||||||||||||||||||||
|
|