

I have exciting news for you. Red Hat has just filed its brief [PDF] in Bilski, and it's saying things you certainly have been hoping someone would express to the Supreme Court. For one thing, they explain the tech, how programs are algorithms, and thus they should not be patentable. The brief asks the Supreme Court to adopt the lower court's machine-or-transformation test, but also -- yay! -- to exclude software from patentability! They also lay out clearly the damage that has been done by broadening patents to include abstract ideas, how risky it has become to even try to write software. Here's the press release, subtitled Files Amicus Brief Giving Open Source Perspective in Bilski Case and Supporting the Exclusion on Patenting Algorithms. Also Red Hat's President and CEO, Jim Whitehurst, has a blog on Bilski. I love Red Hat. They stand alone alone so far among vendors, willing to stand up and express what the FOSS community would really say if it could speak with one voice to the Supreme Court. This is certainly what *I* would say if I had that chance. And so I am satisfied. I was going down the depressing list of briefs filed for Petitioner on the ABA's list of filed amicus briefs, and it was so frustrating to see no one saying anything like what I believe to be technically true about software patents or addressing the specific needs of Free and Open Source software. At last someone has told them what we wanted to say. I just hope the Supreme Court has some techies in the clerk pool!



If anyone could do a quick OCR for me, I'd appreciate it a lot. - Done. Here's the meat of the press release, followed by the brief, minus the header and index, which I'll add asap: *************************** Red Hat Urges Supreme Court to Address Difficulties Posed By Patents to Software Files Amicus Brief Giving Open Source Perspective in Bilski Case and Supporting the Exclusion on Patenting Algorithms RALEIGH, N.C.--(BUSINESS WIRE)--Red Hat, Inc. (NYSE: RHT), the world's leading provider of open source solutions, today announced it has filed an amicus brief with the United States Supreme Court. In the brief, Red Hat explains the practical problems of software patents to software developers. The brief, filed in the Bilski case, asks the Supreme Court to adopt the lower court's machine-or-transformation test and to make clear that it excludes software from patentability. The Bilski case involves the standard for patenting a process. The case concerns a business method patent, but involves many of the same issues as software patents. Red Hat continues its commitment to the free and open source software community by taking a strong position against bad software patents, said Rob Tiller, vice president and assistant general counsel, IP for Red Hat. Our patent system is supposed to foster innovation, but for open source and software in general, it does the opposite. Software patents form a minefield that slows and discourages software innovation. The Bilski case presents a great opportunity for the Supreme Court to rectify this problem. Patenting of software exploded in the 1990s based on judicial decisions changing the test for patentable subject matter. Software patents now number in the hundreds of thousands, and they cover abstract technology in vague and difficult-to-interpret terms. Because software products may involve thousands of patentable components, developers face the risk of having to defend weak-but-costly patent infringement lawsuits. A new class of business enterprise  patent trolls  has developed to file lawsuits to exploit this system. The Federal Circuit set forth a clear test to determine if a process is patentable in stating that it must be either tied to a particular machine or apparatus or must transform a particular article into a different state or thing. Red Hat argues that this standard is consistent with Supreme Court case law, and that it should be applied to exclude algorithms, including computer software, from patenting. The scope of patentable subject matter is an issue of critical importance to the future development of all software, including open source. The Supreme Court's Bilski decision could clarify the law and lessen the risks that innovation will be hindered by patents. Oral argument is scheduled for November 9, 2009. Red Hat has consistently supported patent reform to address problems posed to open source and other software developers. It previously filed an amicus brief in the Bilski case with the Federal Circuit Court of Appeals. To read the full amicus brief, please visit http://www.redhat.com/f/pdf/rh-supreme-court-brief.pdf. For more information about Red Hat, please visit www.redhat.com. For more news, more often, visit press.redhat.com. Red Hat, the world's leading open source solutions provider, is headquartered in Raleigh, NC with over 65 offices spanning the globe. CIOs ranked Red Hat as one of the top vendors delivering value in Enterprise Software for five consecutive years in the CIO Insight Magazine Vendor Value survey. Red Hat provides high-quality, affordable technology with its operating system platform, Red Hat Enterprise Linux, together with applications, management and Services Oriented Architecture (SOA) solutions, including JBoss Enterprise Middleware. Red Hat also offers support, training and consulting services to its customers worldwide. Learn more: http://www.redhat.com. *******************************

******************************* IN THE

Supreme Court of the United States







BERNARD L. BILSKI AND RAND A. WARSAW,

Petitioners,



v.



DAVID J. KAPPOS, UNDER SECRETARY OF COMMERCE

FOR INTELLECTUAL PROPERTY AND DIRECTOR,

PATENT AND TRADEMARK OFFICE,

Respondent.







On Writ of Certiorari to the

United States Court of Appeals

for the Federal Circuit







BRIEF AMICUS CURIAE OF RED HAT, INC.

IN SUPPORT OF AFFIRMANCE







ROBERT H. TILLER

Counsel of Record

RED HAT, INC.

[address]

[phone]

Counsel for Amicus Curiae (1) TABLE OF CONTENTS Page TABLE OF AUTHORITIES ii STATEMENT OF INTEREST OF AMICUS

CURIAE RED HAT, INC. 1 SUMMARY OF ARGUMENT 4 ARGUMENT 6 I. THE COURT BELOW CORRECTLY APPLIED THIS COURT'S PRIOR DECISIONS ESTABLISHING THAT ABSTRACT IDEAS ARE NOT PATENTABLE, AND ITS MACHINE-OR-TRANSFORMATION TEST IS CONSISTENT WITH THOSE DECISIONS 6 II. THE FEDERAL CIRCUIT CORRECTLY ABANDONED A MISINTERPRETATION OF STATUTORY SCOPE THAT HAS CAUSED DRAMATIC HARM TO THE INNOVATION PROCESS IN SOFTWARE 9 A. Software Innovation Long Predated Software Patents 9 B. The Proliferation of Software Patents Has Resulted in New Risks that Discourage Innovation 12 III. AN ABSTRACT IDEA DOES NOT BECOME PATENTABLE MERELY BY IMPLEMENTING IT IN COMPUTER SOFTWARE 19 CONCLUSION 22 i (2) TABLE OF AUTHORITIES CASES Page In re Allapat, 33 F.3d 1526 (Fed. Cir. 1994) 7, 8 In re Bilski, 545 F.3d 943 (Fed. Cir. 2008) 8 Dealertrack, Inc. v. Huber, No. 06-2335, 2009 WL 2020761 (C.D. Cal. Jul. 7, 2009) 20 Diamond v. Diehr, 450 U.S. 175 (1981) passim Gottschalk v. Benson, 409 U.S. 63 (1972) passim Oreilly v. Morse, 56 U.S. 62 (1853) 6 Parker v. Flook, 437 U.S. 584 (1978) 7, 8, 20-21 State Street Bank & Trust Co. v. Signature Fin. Group Inc., 149 F.3d 1368 (Fed. Cir. 1998), cert. denied, 525 U.S. 1093 (1999) 7, 8 WMS Gaming Inc. v. Int'l Game Tech., 184 F.3d 1339 (Fed. Cir. 1999) 20 BPAI CASES Ex parte Cornea-Hasegan, No. 2008-4742 (BPAI Jan. 13, 2009) 20 Ex parte Daughtrey, No. 2008-0202 (April 8, 2009) 20 Ex parte Enenkel, No. 2008-2239 (April 6, 2009) 20 Ex parte Forman, No. 2008-005348 (BPAI Aug. 17, 2009) 20 Ex parte Goud, No. 2008-003121 (BPAI July 20, 2009) 20 Ex parte Gutta, No. 2008-3000 (BPAI Jan. 15, 2009) 20 Ex parte Halligan, No. 2008-2823 (BPAI April 8, 2008) 20 Ex parte Myr, No. 2009-005949 (BPAI Sept. 16, 2009) 20 (3) TABLE OF AUTHORITIESContinued Page Ex parte Nawathe, No. 2007-3360 (BPAI Feb. 9, 2009) 20 CONSTITUTION AND STATUTES 35 U.S.C. § 101 (2006) 6, 7, 8, 21 U.S. Const. art. I, § 8 11 OTHER AUTHORITIES AMERICAN INTELLECTUAL PROPERTY LAW ASSOCIATION, REPORT OF THE ECONOMIC SURVEY (2009) 16 JAMES BESSEN & MICHAEL J. MEURER, PATENT FAILURE: HOW JUDGES, BUREAUCRATS, AND LAWYERS PUT INNOVATORS AT RISK (2008) 12, 13, 14, 15, 16 James Bessen & Robert Hunt, An Empirical Look at Software Patents, 16 J. ECON. & MGMT. STRATEGY 157 (2007) 12 DAN L. BURK & MARK A. LEMLEY, THE PATENT CRISIS AND HOW THE COURTS CAN SOLVE IT (2009) 11, 13, 14, 15, 16, 17 COMM. ON INTELLECTUAL PROP. RIGHTS IN THE KNOWLEDGE-BASED ECON., NAT'L RESEARCH COUNCIL, PATENTS IN THE KNOWLEDGE-BASED ECONOMY (Wesley M. Cohen & Stephen A. Merrill eds., 2003) 12 CLAYTON M. CHRISTENSEN, THE INNOVATOR'S DILEMMA (2006) 18 Amit Deshpande & Dirk Riehle, The Total Growth of Open Source, in PROCEEDINGS OF THE FOURTH CONFERENCE ON OPEN SOURCE SYSTEMS, 197-209 (Springer Verlag, 2008) 2 (4) TABLE OF AUTHORITIESContinued Page ERIC VON HIPPEL, DEMOCRATIZING INNOVATION (2005) 4 BEN KLEMENS, MATH YOU CAN'T USE  PATENTS, COPYRIGHT, AND SOFTWARE (2006) 15, 16, 17, 19 Ben Klemens, The Rise of the Information Processing Patent, 14 B.U. J. SCI. & TECH. L. 1 (2008) 15, 18 Donald E. Knuth, Letter to Commissioner of Patents and Trademarks (Feb. 23, 1994) 13, 15 Mark Lemley, Ignoring Patents, 2008 MICH. ST. L. REV. 19 (Spring 2008) 16 Michael J. Meurer, Controlling Opportunistic and Anti-competitive Intellectual Property Litigation, 44 B.C. L. REV. 509 (2003) 14, 17, 18 To Promote Innovation: The Proper Balance of Competition and Patent Law and Policy, Report of the U.S. Federal Trade Commission, ch. 3 § V (2003) passim Kirk Rowe, Why Pay for What's Free?: Minimizing the Patent Threat to Free and Open Source Software, 7 J. MARSHALL REV. INTELL. PROP. L. 595 (2008) 13 RICHARD M. STALLMAN, FREE SOFTWARE, FREE SOCIETY: SELECTED ESSAYS OF RICHARD M. STALLMAN (Joshua Gay, ed., 2002) 17 Andrew W. Torrance & Bill Tomlinson, Patents and the Regress of Useful Arts, 10 COLUM. SCI. & TECH. L. REV. 130 (2009) 12 (5) TABLE OF AUTHORITIESContinued Page STEVEN WEBER, THE SUCCESS OF OPEN SOURCE (2004) 10 (6) BRIEF AMICUS CURIAE OF RED HAT, INC.

IN SUPPORT OF AFFIRMANCE

--------

STATEMENT OF INTEREST OF

AMICUS CURIAE RED HAT, INC. Red Hat, Inc. is the world's leading provider of open source software and related services to enterprise customers.1 Its software products are used by Wall Street investment firms, hundreds of Fortune 500 companies, and the United States government. Headquartered in Raleigh, North Carolina, Red Hat has offices in 28 countries. Red Hat's interest in this proceeding is based on its experience in the software industry and its commitment to the free and open source software community. Open source software is growing at an exponential rate,2 and is already of strategic economic importance. It provides the technological backbone of many large corporations and supports essential functions of many national and regional governments. It is used daily by millions of individuals for such activities as web searching, email, on-line shopping, and banking. It is found in devices as varied as mainframe computers, desktop computers, cellular phones, camcorders, medical devices, automobiles, and warships. The open source model produces software innovation through a mechanism of collaborative development that relies on free communication of ideas among large numbers of independent individuals and companies. To understand open source, it is helpful to understand generally how software is made. Software begins as plain text "source code." Programmers write and edit source code in human-readable programming languages that allow specification of software features and behavior at a high level of abstraction. Source code is typically translated by a 2 program called a compiler into "object code" form, which basically consists of a series of instructions to be executed on a computer. Since object code consists of unintelligible strings of 1s and 0s, software is effectively unmodifiable without access to its source code. Open source software permits such modification by making the source code available to the user. Open source software is the product of collaborative development that uses a combination of technological and legal means. Typically, an open source program originates as a community-based project whose members work together using Internet tools such as email, mailing lists, Internet relay chat, bug reporting systems, wikis, and source code version control systems. These tools enable rapid communication among geographically dispersed software developers, and make it possible for large numbers of developers from many different backgrounds and organizations to work collaboratively. A community project makes its software publicly available in source code form, under licensing terms that grant very broad, royalty-free copyright permissions allowing further use, copying, modification and distribution. In making source code available and conferring broad copyright permissions, open source differs significantly from traditional proprietary software. A vendor of proprietary software generally develops the software in-house and provides only object code to the user subject to restrictive licenses that allow no rights to copy, modify, or redistribute that code. Such vendors retain the source code as a trade secret. The open source development model has proven to be highly effective in producing software of superior 3 quality.3 Because there are many developers working as collaborators in a distributed fashion, innovation happens rapidly.4 Because of the many who volunteer their time, and the availability of the source code under royalty-free licenses granting generous modification and distribution rights, the cost of producing and improving software is low. Software bugs and security problems are quickly identified and remedied. Moreover, because users have access to the source code, those users can diagnose problems and customize the software to suit their particular needs. The scope of patentable subject matter is an issue of critical importance to the future development of all software, including open source. Because open source innovation depends on sharing source code and free collaboration, open source community members do not generally seek to prohibit or control use of open source software through patents, and most open source software developers view software patents as hindering innovation. Red Hat respectfully submits that this Court should evaluate the issues at bar with a view to the importance of open source software and the bright promise of future open source innovation. SUMMARY OF ARGUMENT In the decision below, the Federal Circuit issued a course correction. Beginning in the mid-1990's, that court disregarded the guideposts established by this 4 Court on the limits of patentable subject matter and issued a series of decisions that opened the floodgates for patents on certain kinds of abstract ideas. As a result, there are now hundreds of thousands of patents on abstract subject matter, and tens of thousands of new patents are now granted each year for software and business methods that were previously excluded from patentable subject matter. Far from encouraging innovation, this proliferation of patents has seriously encumbered innovation in the software industry. Software is an abstract technology, and translating software functions into patent language generally results in patents with vague and uncertain boundaries. Software products are often highly complex, created by combining hundreds or thousands of discrete (and potentially novel) elements in a cumulative process. Because the boundaries of software patents are exceedingly vague and the numbers of issued software patents is now enormous, it is virtually impossible to rule out the possibility that a new software product may arguably infringe some patent. Thus, under the Federal Circuit's previous erroneous approach, the risk of going forward with a new software product now always entails an unavoidable risk of a lawsuit that may cost many millions of dollars in legal fees, as well as actual damages, treble damages, and an injunction that terminates a business. Only those with an unusually high tolerance for risk will participate in such a market. The more risk averse, no matter how great their business or technical gifts and innovative potential, are likely to avoid such a market and seek their fortunes elsewhere. 5 This case offers an opportunity to restore the historical and well-founded boundaries for patentable subject matter that exclude abstract ideas from patent eligibility. It also offers an opportunity to reaffirm the rule, supported both by case law and by sound policy, that computer software is among the types of abstract subject matter that are not patentable under 35 U.S.C. § 101. The machine-or-transformation test set forth in the decision below is fully consistent with this Court's prior case law regarding the patenting of abstract ideas. The Court should adopt this test and make clear that it excludes software from patenting. ARGUMENT I. THE COURT BELOW CORRECTLY APPLIED THIS COURT'S PRIOR DECISIONS ESTABLISHING THAT ABSTRACT IDEAS ARE NOT PATENTABLE, AND ITS MACHINE-OR-TRANSFORMATION TEST IS CONSISTENT WITH THOSE DECISIONS This Court has long recognized that patents have costs as well as benefits. See Gottschalk v. Benson, 409 U.S. 63, 68 (1972) (explaining Oreilly v. Morse, 56 U.S. 62 (1853)). Patents do not always promote innovation, and they may substantially hinder it. See id. A patent on a process excludes others from using that process. If the patent is too broad or vague, it may block or discourage technological progress. Therefore defining the proper subject matter limits of process patents under 35 U.S.C. § 101 is of critical importance. This requires distinguishing between a patentable "process" within the meaning of Section 101, and abstract intellectual concepts. 6 Thus this Court has determined that "[p]henomena of nature, though just discovered, mental processes, and abstract intellectual concepts are not patentable, as they are the basic tools of scientific and technological work." Benson, 409 U.S. at 67. It runs directly counter to the objective of fostering innovation to allow patents that impede scientific and technological progress. A patent on an algorithm or other abstract idea, as opposed to a specific tangible process, blocks innovation. Id. at 68. To be sure, "[t]he line between a patentable 'process' and an unpatentable 'principle' is not always clear." Parker v. Flook, 437 U.S. 584, 589 (1978). This Court has repeatedly faced this line-drawing problem in the context of computer-related patents, and has consistently articulated the guideposts to be used. It has affirmed and reaffirmed that "[t]ransformation and reduction of an article 'to a different state or thing' is the clue to patentability of a process claim that does not include particular machines." Benson, 409 U.S. at 70. Accord Diamond v. Diehr, 450 U.S. 175, 192 (1981);Flook, 437 U.S. at 589. In the mid-1990s, however, the Federal Circuit took an approach at odds with this Court's teachings in Flook, Benson, and Diehr. In the leading cases of In re Allapat, 33 F.3d 1526 (Fed. Cir. 1994), and State Street Bank & Trust Co. v. Signature Fin. Group Inc., 149 F.3d 1368 (Fed. Cir. 1998), cert. denied, 525 U.S. 1093 (1999), the Federal Circuit significantly broadened the standards for patentable subject matter. These and subsequent Federal Circuit cases ignored the risks of granting patents on abstract ideas, and instead held that usefulness ("a useful, concrete and tangible result") was sufficient to satisfy Section 101. 7 State Street, 149 F.3d at 1373; Allapat, 33 F.3d at 1544. As explained in the next section, this departure from this Court's teachings caused enormous damage to the patent system in general and the software industry in particular. In the decision below, the en banc court of appeals acknowledged that its "useful, concrete and tangible result" test was problematic. In re Bilski, 545 F.3d 943, 959-60 (Fed. Cir. 2008). It carefully reexamined this Court's decisions in Flook, Benson, and Diehr, acknowledged the importance of not extending patentable subject matter so far as to impede technological innovation, and articulated a test that is entirely consistent with those decisions. Using language from Flook, Benson, and Diehr, the Federal Circuit's test distinguishes a patentable process from an abstract idea by considering whether "(1) it is tied to a particular machine or apparatus, or (2) it transforms a particular article into a different state or thing." Id. at 954. The appeals court explained that "the use of a specific machine or transformation of an article must impose meaningful limits on the claim's scope to impart patent-eligibility." Id. at 961. In addition, the court explained that "the involvement of the machine or transformation in the claimed process must not merely be insignificant extra-solution activity." Id. at 962 (citing Flook, 437 U.S. at 590). The decision below thereby corrected the erroneous approach that the Federal Circuit took to Section 101 in the mid-1990s. The Federal Circuit's machine-or- transformation test is in full accord with this Court's prior decisions in Flook, Benson, and Diehr. 8 II. THE FEDERAL CIRCUIT CORRECTLY ABANDONED A MISINTERPRETATION OF STATUTORY SCOPE THAT HAS CAUSED DRAMATIC HARM TO THE INNOVATION PROCESS IN SOFTWARE The decision below did not purport to address in categorical terms the patenting of either business methods or software. It is obvious, however, that the machine-or-transformation test (or any other replacement test considered by this Court) will govern attempts to patent these and other abstract ideas. Patenting of software has been particularly controversial, and presents in a clear form the challenge of separating abstract ideas from patentable processes. The creation and expansion of the field of software patents therefore is worth considering both as an example of the larger problem posed by abstract patents and a problem in its own right. A. Software Innovation Long Predated Software Patents The importance of the software industry to the United States economy is well recognized. What is less well recognized is that major innovations and economic successes in the software industry occurred prior to the Federal Circuit's decisions in the mid-1990s encouraging software patents. Such enormously successful software products as Microsoft Word, Oracle Database, Lotus 1-2-3, the Unix operating system, and the GNU C compiler all date from the 1980s or earlier--well before the proliferation of software patents. Market forces, rather than patents, spurred development of these products. See To Promote Innovation: The Proper Balance of Competition and Patent Law and Policy, Report of the U.S. Federal Trade Commission, ch. 3 § V, at 46 (2003), 9 available at http://www2.ftc.gov/os/ 2003/10/innovationrpt.pdf (hereinafter "FTC Innovation Report").5 Indeed, in the 1972 Benson decision, this Court took note of the exclusion of software from patenting, of problems caused by attempts to patent software, and of the industry's impressive growth without patents. "Direct attempts to patent [software] programs have been rejected on the ground of non-statutory subject matter." 409 U.S. at 72 (quoting 'To Promote the Progress of . . . Useful Arts,' The President's Commission on the Patent System 13 (1966)). "Indirect attempts to obtain patents and avoid the rejection, by drafting claims as a process, or a machine or components thereof programmed in a given manner, rather than as a program itself, have confused the issue further and should not be permitted." Id. The Benson Court, quoting the President's Commission, also noted the inability of the Patent Office to examine adequately software patent applications. 409 U.S. at 72. At the same time, the Court noted "that the creation of programs has undergone substantial and satisfactory growth in the absence of patent protection and that copyright protection for programs is presently available." Id. 10 Thus the software industry began and reached maturity without the benefit of extensive patent monopolies. This is not to say there was no legal protection for software products. As the Benson Court noted, copyright law provided (and it still provides) substantial protection for software products.6 This recent history, by itself, calls into serious question whether software patents serve the primary purpose of the patent system of encouraging innovation. See U.S. Const. art. I, § 8. Many of the world's most successful software companies and soft- ware products originated and grew strong without incentives from patents. Instead, these successes arose from the dynamics of the competitive market place. FTC Innovation Report, ch. 3, § V at 46. That is, prior to the expansion of patentability for software in the mid-1990s, survival in the market place for software depended primarily on the ability to innovate better and more quickly than competitors. Competition, without patent monopolies, resulted in a remarkably dynamic software industry with an impressive record of innovation.7 11 B. The Proliferation of Software Patents Has Resulted in New Risks that Discourage Innovation Since the mid-1990s, there is one respect in which software patents have been successful as a species: they have proliferated. At present in the United States there are at least 200,000 issued software patents. See JAMES BESSEN & MICHAEL J. MEURER, PATENT FAILURE: HOW JUDGES, BUREAUCRATS, AND LAWYERS PUT INNOVATORS AT RISK 22 (2008) (hereinafter "PATENT FAILURE"), available in part at http://researchoninnovation.org/dopatentswork/. They continue to increase at the rate of approximately 20,000 per year. See James Bessen & Robert Hunt, An Empirical Look at Software Patents, 16 J. ECON. & MGMT. STRATEGY 157, 158 (2007). This proliferation has raised significant risks for software developers. For years, far-sighted industry leaders, scholars, and software developers have warned of these risks and opposed software patents. See PATENT FAILURE at 189. These include Bill Gates, co-founder of Microsoft. In 1991, Mr. Gates stated, "If people had understood how patents would be granted when most 12 of today's ideas were invented and had taken out patents, the industry would be at a complete standstill today." Kirk Rowe, Why Pay for What's Free?: Minimizing the Patent Threat to Free and Open Source Software, 7 J. MARSHALL REV. INTELL. PROP. L. 595, 595 (2008). Similar, Donald E. Knuth, Professor Emeritus at Stanford University and one of the world's most respected computer scientists, wrote in 1994, "When I think of the computer programs I require daily to get my own work done, I cannot help but realize that none of them would exist today if software patents had been prevalent in the 1960s and 1970s." Donald E. Knuth, Letter to Commissioner of Patents and Trademarks 2 (Feb. 23, 1994), available at http:// documents.epo.org/projects/babylon/eponet.nsf/0/5294 C4422611FE7BC12575B6006414D2/$File/G3-08_ami cus_curiae_brief_Knuth_en.pdf. Dr. Knuth also stated, "I strongly believe that the recent trend to patenting algorithms is of benefit only to a very small number of attorneys and inventors, while it is seriously harmful to the vast majority of people who want to do useful things with computers." Id. The views of Mr. Gates and Dr. Knuth were shared by many firms and developers in the 1990s. PATENT FAILURE at 189. The risk that they articulated--that patents tend to hinder software innovation--relates to at least two different aspects of software: the incremental nature of software development and the near impossibility of establishing clear boundaries for software patents. In general, software innovation is cumulative in nature--that is, new products typically build on products built previously. See FTC Innovation Report, ch. 3, § V at 44-45; THE PATENT CRISIS at 47. Innovation 13 is rapid and product cycles are short.8 Major software products are complex, involving many thousands or even millions of lines of code and many different components. Components are normally developed using many earlier-developed sub-components. Some software products contain thousands of distinguishable components, any number of which could (in view of erroneous patenting practices) already be patented. See FTC Innovation Report, ch. 3 § V at 52; THE PATENT CRISIS at 53-54. It is, however, practically impossible to know with reasonable certainty whether a new software product could be said to infringe some prior software patent. Patents are conventionally referred to as intellectual property. However, as James Bessen and Michael Meurer have explained in detail, patents differ substantially from tangible property in that their boundaries are often fuzzy and unpredictable. PATENT FAILURE at 46-72. If patents do not give clear notice of their limits, they create a risk of inadvertent infringement. Vague patents also enable opportunistic behavior. For example, a patentee may, based on vague language, claim ownership of a technology unknown to the inventor, but instead first conceived by someone else. Id. at 199. 9 14 This problem of uncertain patent boundaries is particularly acute with software patents. Software is an abstract technology.10 Software algorithms can be represented in numerous different ways, and even computer scientists sometimes disagree over whether two software technologies are equivalent. See PATENT FAILURE at 22, 203. Thus it is not surprising that software patents are typically framed in abstract language with uncertain boundaries. See PATENT FAILURE at 23, 203; THE PATENT CRISIS at 27, 58. As a result, a software developer, when shown a software patent, often cannot be sure whether the patent reads on newly developed code. This difficulty is multiplied hundreds or thousands of times with regard to a complex software product combining hundreds or thousands of discrete components. A separate but related problem faces all software developers--that of the impossibility of patent clearance, or determining whether there are existing patents that may be said to read on a new product. There is no reliable, economical method for 15 searching the hundreds of thousands of existing software patents.11 PATENT FAILURE at 50, 69-70. See also MATH YOU CAN'T USE at 79-80. The clearance problem is made even worse by the existence of tens of thousands of applications that for eighteen months after filing are unpublished. Thus, simply by virtue of producing and marketing an innovative software product, a software developer assumes the risk of a costly patent infringement lawsuit.12 See FTC Innovation Report, ch. 3. § V at 53-54, 56. In the U.S., software patents are more than twice as likely to be the subject of a lawsuit than other patents and account for one quarter of all patent lawsuits. PATENT FAILURE at 22, 192. The cost of defending a patent lawsuit frequently amounts to several million dollars. AMERICAN INTELLECTUAL PROPERTY LAW ASSOCIATION, REPORT OF THE ECO- NOMIC SURVEY I-128-29 (2009). Such lawsuits involve technical issues that are difficult for judges and juries to understand, and so even with a strong defense the outcome is usually far from certain. If 16 there is a judgment of infringement, the penalty may be an injunction ending further production and enormous monetary damages. Defense costs and litigation risks are so large that in most cases defendants agree to some payment to settle such cases. Even when claims appear to have no valid basis, targets frequently agree to pay for licenses based on the mere threat of litigation. Michael J. Meurer, Controlling Opportunistic and Anticompetitive Intellectual Property Litigation, 44 B.C. L. REV. at 542. Some large technology companies have addressed the risk of inadvertent infringement of patents by seeking as many patents as possible, on the theory that a large patent portfolio signals the possibility of a countersuit and thus will deter other companies from bringing a patent lawsuit.13 See FTC Innovation Report, ch. 3 § V at 56; THE PATENT CRISIS at 55. Companies with such portfolios often enter into cross-licensing agreements with other large companies that have their own patent portfolios in an attempt to obtain a modicum of patent peace. Id. at 52. See RICHARD M. STALLMAN, FREE SOFTWARE, FREE SOCIETY: SELECTED ESSAYS OF RICHARD M. STALLMAN 101-103 (Joshua Gay, ed., 2002); MATH YOU CAN'T USE at 83-85. While such defensive measures are understandable from an individual enterprise's perspective, they are 17 far from optimal. They create a vicious cycle: to defend against a multitude of vague patents, companies obtain still more vague patents. Resources expended on this strategy are, of course, unavailable for research and development or for other more productive purposes. FTC Innovation Report, ch. 3 § V at 52. Moreover, although established companies may be able to bear the cost of this deterrence strategy, small companies and potential new competitors generally lack the resources to do so. Thus the system discourages new entry into the market, and thereby hinders innovation. See id. at 51-52. See also CLAYTON M. CHRISTENSEN, THE INNOVATOR'S DILEMMA 26, 52 (2006) (showing that small firms generally lead in new technologies). Moreover, even for companies with the financial resources to build patent portfolios, the deterrence approach is not always effective. With the proliferation of software patents has come the expansion of a class of businesses created expressly for the purpose of exploiting vague patents. See Ben Klemens, The Rise of the Information Processing Patent, 14 B.U. J. SCI. & TECH. L. at 27-31; Meurer, supra. These are sometimes referred to as non-practicing entities or, less politely, as patent trolls. These entities acquire vague patents at low cost with a view to threatening or bringing lawsuits against operating businesses. They frequently conceal their identities and holdings until the companies that are their targets, which have no knowledge of the relevant patents, are locked in to a product and business strategy. Then they demand ransom. Because such entities produce no products, they are not deterred by the possibility of a countersuit. 18 In sum, all software companies, developers, and users face substantial risks from software patents. These risks include whether an unknown patent may cover newly written code or some other preexisting code in a complex product, whether such a patent could be the basis of a lawsuit, whether a relevant patent is in the hands of an aggressive party dedicated to bringing patent lawsuits, and whether a trial may result in an injunction or damages award. These risks have obviously not brought the software industry to a standstill. Established companies are protected to some extent by their patent portfolios and war chests. But for them and even more for new players, software innovation, like sky diving, requires a high tolerance for risk. See MATH YOU CAN'T USE at 91. Developers without a high risk tolerance are likely to find the threat of ruinous lawsuits to be discouraging, and to use their talents and energy in less hazardous endeavors. Thus software patents discourage new entries into the marketplace and new software innovation. III. AN ABSTRACT IDEA DOES NOT BECOME PATENTABLE MERELY BY IMPLEMENTING IT IN COMPUTER SOFTWARE In connection with addressing the test for excluding abstract ideas from patenting, this Court it should also clarify the application of that test in the context of computer programs that run on general purpose computers. Lower court case law and commentary since the Federal Circuit's en banc decision shows that this issue is an important one on which this Court's guidance is needed. 19 The basic question is whether an otherwise unpatentable idea becomes "tied to a particular machine" when it is implemented in software for execution on a general purpose computer. Prior to the decision below, the Federal Circuit gave credence to the idea that a general purpose computer could be transformed into a particular machine by executing software. WMS Gaming Inc. v. Int'l Game Tech., 184 F.3d 1339, 1348 (Fed. Cir. 1999). On the other hand, this view was recently rejected in Dealertrack, Inc. v. Huber, No. 06-2335, 2009 WL 2020761, at *4 (C.D. Cal. Jul. 7, 2009). Moreover, it has been recently repeatedly rejected by the Board of Patent Appeals and Interferences. See, e.g. Ex parte Myr, No. 2009-005949 (BPAI Sept. 16, 2009); Ex parte Forman, No. 2008-005348 (BPAI Aug. 17, 2009); Ex parte Goud, No. 2008-003121 (BPAI July 20, 2009); Ex parte Daughtrey, No. 2008-0202 (April 8, 2009); Ex parte Halligan, No. 2008-2823 (BPAI April 8, 2008); Ex parte Enenkel, No. 2008-2239 (April 6, 2009); Ex parte Nawathe, No. 2007-3360 (BPAI Feb. 9, 2009); Ex parte Gutta, No. 2008-3000 (BPAI Jan. 15, 2009); Ex parte Cornea-Hasegan, No. 2008-4742 (BPAI Jan. 13, 2009). This Court's decisions in Benson and Diehr signal that the mere fact that otherwise unpatentable software is executable on a general purpose computer should not convert such software into a patentable invention. This is not to say that software may not be part of a patentable process or machine. As Diehr recognized, an algorithm that is plainly unpatentable by itself may be a part of a process that is patentable when it involves a physical transformation of the sort that has traditionally been considered patentable, such as an industrial process for curing rubber. 450 U.S. at 184-88. See also Parker v. Flook, 437 U.S. at 20 589-94. The Court has also recognized that an otherwise abstract idea may be patentable when "tied to a particular apparatus." Flook, 437 U.S. at 588, n.9. In Benson, the patent application covered "a method of programming a general-purpose digital computer to convert signals from binary-coded decimal to pure binary form." 409 U.S. at 65. The Court found that the procedure at issue was a mathematical algorithm, and amounted to an unpatentable abstract idea. Id. at 65-66. It is important to note, however, that the algorithm had "no substantial practical application except in connection with a digital computer." Id. at 71. The claims were intended to "cover any use of the claimed method in a general-purpose digital computer of any type." Id. at 64. Thus the algorithm claimed in Benson could have been viewed as "tied to a machine," inasmuch as it was functionally tied to a digital computer. Nevertheless, this Court held that the claims were abstract ideas outside the scope of Section 101. Thus Benson precludes an interpretation of Section 101 that views abstract ideas as patentable based on their implementation in software running on a general purpose computer. The more recent decision in Diehr is consistent with this understanding. The rubber curing process in Diehr involved an algorithm and a computer, but this Court's analysis of subject matter turned on the claim as a whole, which concerned the physical transformation of the rubber--not the implementation of the algorithm in a computer program. 450 U.S. at 184-85. Diehr explained that use of the computer did not render the process unpatentable, 21 but the decision makes clear, by its focus on the transformation of rubber, that use of the computer alone does not suffice to make the process patentable. See id. at 187. The Diehr Court cautioned against allowing the prohibition on patenting of abstract formulas to "be circumvented by attempting to limit the use of the formula to a particular technological environment." 450 U.S. at 191. "To hold otherwise would allow a competent draftsman to evade the recognized limitations on the type of subject matter eligible for patent protection." Id. at 192. In view of this caution, this Court should make clear that the test for patentable subject matter cannot be satisfied by the mere drafting device of adding a general purpose computer as an element in a claim that is otherwise directed to an unpatentable algorithm. CONCLUSION The judgment of the Federal Circuit should be affirmed. Respectfully submitted. ROBERT H. TILLER

Counsel of Record

RED HAT, INC.

[address, phone]



Counsel for Amicus Curiae 22 No counsel for a party authored this brief in whole or in part, and no such counsel made a monetary contribution intended to fund the preparation or submission of this brief. No person other than amicus curiae, its members, or its counsel made a monetary contribution to its preparation or submission. Petitioners and Respondents have consented to the filing of this brief through blanket letters of consent filed with the Clerk's Office. The amount of open source code doubles every fourteen months. Amit Deshpande & Dirk Riehle, The Total Growth of Open Source, in PROCEEDINGS OF THE FOURTH CONFERENCE ON OPEN SOURCE SYSTEMS, 197-209 (Springer Verlag, 2008), http:// dirkriehle.com/wp-content/ uploads/2008/03/oss-2008-total-growth- final-web.pdf. There are numerous widely used open source software pro- grams, including the Linux operating system kernel, the Apache web server, the Firefox web browser, the MySQL database management system, and the GCC compiler collection. See, e.g., ERIC VON HIPPEL, DEMOCRATIZING INNOVATION 93-106 (2005), available at http://web.mit.edu/evhippel/www/books. htm. The profit motive is, of course, an important incentive for software development, but it is not the only one. Open source software developers generally work for open source projects on a voluntary basis. See STEVEN WEBER, THE SUCCESS OF OPEN SOURCE 129 (2004). Some of the motivations for their contributions include improving the functioning of a product for business or personal use, enhancing programming skills, reputation, philosophical commitment to free software, and personal enjoyment. Id. at 134-36. Copyright protects authors against the copying of their software. Patents, of course, block independent invention of patented technology. Although some patent advocates use the rhetoric of "theft" of ideas to support their arguments, there is evidence that the great majority of patent lawsuits are not against defendants who copied inventions but rather against independent inventors. DAN L. BURK & MARK A. LEMLEY, THE PATENT CRISIS AND HOW THE COURTS CAN SOLVE IT 28 (2009) (hereinafter "THE PATENT CRISIS"). Although it is frequently assumed that patents encourage technological innovation, there is little empirical evidence supporting this view. In a 2003 report "Patents in the Knowledge-Based Economy," the National Academies undertook a comprehensive review of the United States patent system, and concluded that "[t]here are theoretical as well as empirical reasons to question whether patent rights advance innovation in a substantial way in most industries." COMM. ON INTELLECTUAL PROP. RIGHTS IN THE KNOWLEDGE-BASED ECON., NAT'L RESEARCH COUNCIL, PATENTS IN THE KNOWLEDGE-BASED ECONOMY 2 (Wesley M. Cohen & Stephen A. Merrill eds., 2003), available at http://www.nap.edu/ catalog.php?record_id=10770. Scholarly studies have called into question the basic assumption that patent protection in general spurs innovation. Andrew W. Torrance & Bill Tomlinson, Patents and the Regress of Useful Arts, 10 COLUM. SCI. & TECH. L. REV. 130, 133-34 (2009). Because of rapid product cycles, it is difficult for a software inventor to use a patent productively to enforce legitimate rights. A patent lawsuit is likely to take longer to resolve than a product cycle, and may even take several product cycles. See THE PATENT CRISIS at 57. For example, a plaintiff may argue that a pre-internet patent covers some use of internet technology. Michael J. Meurer, Controlling Opportunistic and Anti-competitive Intellectual Property Litigation, 44 B.C. L. REV. 509, 542 (2003). Computer software is abstract because it is, in essence, nothing more than a set of mathematical algorithms, expressed in a particular programming or machine language. An algorithm is a mathematical construct, consisting of a series of steps for solving a problem. See BEN KLEMENS, MATH YOU CAN'T USE PATENTS, COPYRIGHT, AND SOFTWARE 48-51 (2006) (hereinafter "MATH YOU CAN'T USE"). Computer scientists view software as consisting entirely of algorithms. See Ben Klemens, The Rise of the Information Processing Patent, 14 B.U. J. SCI. & TECH. L. 1, 9-11 (2008). As Donald Knuth has explained, "[It is not] possible to distinguish between 'numerical' and 'nonnumerical' algorithms, as if numbers were somehow different from other kinds of precise information." See Letter to Commissioner of Patents and Trademarks at 1. This Court has held that algorithms are not patentable. Benson, 409 U.S. at 72. The unreliability of indexing for software patents also means that software patents are of little use in advancing innovation by disclosing new technology. From a software developer's point of view, it is completely impractical to seek new ideas in patents, and few if any do so. Most avoid reading patents, for fear that a chance encounter may increase the risk that they will one day be accused of willful infringement. See THE PATENT CRISIS at 32; Mark Lemley, Ignoring Patents, 2008 MICH. ST. L. REV. 19, 21 (Spring 2008). A further indication of the ineffectiveness of the patent system for software is that there is little patent licensing prior to development and distribution of products. See THE PATENT CRISIS at 59. Because of vague patent boundaries and unreliable search methods, it is not possible to determine all possible rights at issue and strike bargains as to those rights. Red Hat, like some of its competitors, has built a patent portfolio. This portfolio is designed to be used only for the purpose of defending against patent aggression. Red Hat has extended a public Patent Promise under which it pledges not to enforce its patents against parties that infringe those patents through their use of software covered by designated open source licenses. See https://www.redhat.com/legal/ patent_policy.html.