Here, as text, is Red Hat's amicus brief [PDF] in In re Bilski, which you can read about in depth in the prior article. This Red Hat brief explains so well why software patents clash with the Open Source development model that I thought you'd like to have it as text, and placed so you can share it easily with others who may not yet understand. FOSS is also a contributor to the world's economy, it is ubiquitous in use, and it's important to governments and businesses around the world, Red Hat points out. Therefore, it potentially matters a great deal that the US courts get this issue clearly presented. I think you'll agree that Red Hat has done so in this brief. There are three main arguments: - Abstract ideas are not patentable
-
Abstract ideas don't get patentable just because there's a computer involved
-
Both State Street Bank and AT&T v. Excel clash with binding Supreme Court precedent (Red Hat notes particularly Gottschalk v. Benson) and should therefore be reconsidered and modified.
Benson, Red Hat notes, demonstrates that tying an abstract idea to a computer doesn't make the idea patentable: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 6566. 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, the Supreme 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.
This is all in answer to three of the five questions the US Court of Appeals for the Federal Circuit asked [PDF] the parties and amici to address. You may think of other arguments, and indeed if you recall the Software Freedom Law Center's amicus brief in the Microsoft v. AT&T case in 2006, you'll know there are additional arguments to be made, but when a court asks you to address five points, that is what you do. Red Hat does begin, though, with a brief explanation of what Open Source, or Free, software is, how it is developed, how it contributes to the economy, and why it is threatened by software patents.
You'll find links to several of the cases Red Hat references in the previous article, like to Diehr and Flook.
I'd personally like to do more than modify those two cases, State Street and AT&T Corp. v. Excel Communications. I'd like to toss them in the garbage after parading them around the city so we can all throw tomatoes at them while they cry out for forgiveness for causing so much damage and distress, but that isn't how you talk in court briefs. The task Red Hat has is delicate: it must persuade this court that it made a mistake in the two earlier decisions. Specifically, the court held in State Street that abstract ideas *were* patentable, if they produced a "useful, concrete and tangible result". The task, then, is to draw a line more practically, and Red Hat chooses a line whereby there must be a physical transformation to be patentable, and more than a change in neurotransmitters in your brain. As Red Hat explains, there is a kind of physical transformation in that thinking involves "physical neurotransmitter chemicals acting on physical cells." But the Supreme Court already decided that such intangible and transient effects do not reach the level required for patentability: Similarly, transitory changes in electronic states that occur in circuits could be characterized as tangible at some level, but these cases [Benson, Flook, Diehr] show that more is required ... The algorithm in Benson, Red Hat says, was and is "useful", but the Supreme Court said it wasn't patentable, so being useful, as State Street put it, clearly can't be sufficient alone. The two cases clash, and the Supreme Court trumps. In short, it's an educational task here, to help the court to understand the tech sufficiently to draw a line in the right place. The way to get a court to reverse itself isn't to tell it that it's wrong. You have to show why, using cases that are binding upon the court, which is what this brief is doing. Courts sincerely try to get it right, and it's one of the things I like the most about the court system that when it becomes apparent that a decision has resulted in problems, courts themselves can on their own initiative ask for briefs to help them modify, as this court is now doing.
*****************************************
(Serial No. 08/833,892)
In The
United States Court of Appeals
For The Federal Circuit
IN RE BERNARD L. BILSKI
and RAND A. WARSAW
APPEAL FROM THE UNITED STATES
PATENT AND TRADEMARK OFFICE,
BOARD OF PATENT APPEALS AND INTERFERENCES.
__________________
BRIEF OF AMICUS CURIAE RED HAT, INC.
IN SUPPORT OF APPELLEE
___________________
Robert H. Tiller
Richard E. Fontana
RED HAT, INC.
[address, phone]
Counsel for Amicus Curiae Red Hat, Inc.
Dated: April 7, 2008
CERTIFICATE OF INTEREST
Counsel for the amicus Red Hat, Inc. certifies the following:
1. The full name of every party or amicus represented by me is:
Red Hat, Inc.
N/A.
3. All parent corporations and any publicly held companies that own 10 percent or more of the stock of the party or amicus curiae represented by me are:
Red Hat, Inc. has no parent corporation. More than 10 percent of the common stock of Red Hat, Inc. is held by both T. Rowe Price Associates, Inc. (a subsidiary of the publicly held corporation T. Rowe Price Group, Inc.) and Legg Mason, Inc.
4. The names of all law firms and the partners or associates that appeared for the party or amicus now represented by me in the trial court or agency or are expected to appear in this court are:
Robert H. Tiller
Vice President and Assistant General Counsel, IP, Red Hat, Inc.
Richard E. Fontana
Open Source Licensing and Patent Counsel, Red Hat, Inc.
April 7, 2008
___[signature]___
Richard E. Fontana
Red Hat, Inc.
i
INTEREST OF AMICUS
Red Hat, Inc. is the world's leading provider of open source software and
related services to enterprise customers. 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 58 countries.
Red Hat's interest in this proceeding is based on its participation in and
deep commitment to the open source software community. The development and
use of open source has expanded at an exponential rate in recent years. 1 Open source software is now ubiquitous, touching the lives of the millions of Americans who do web searching, email, online shopping, banking, and many other everyday activities. It provides the technological backbone of many large corporations and is critical to the technology operations of the U.S. and many state governments. It is playing an important role in economic development across the globe. Even so, its nature and significance are still not widely understood.
ii
The open source model produces software through a mechanism of
collaborative development that fundamentally relies on communication of ideas
by large numbers of individuals and companies. To understand this model, it is
helpful to understand 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. Software is commonly distributed in machine-
executable "object code" form, produced by "compiling" the source code of the
software. 2 Since object code consists of unintelligible strings of 1s and 0s,
software is effectively unmodifiable unless one has access to its source code.
A good example of an open source project is the Linux operating system
kernel, which is one of the most commercially-important open source programs
and which is a core component of Red Hat's flagship product, Red Hat Enterprise
Linux.3 The Linux kernel contains several million lines of source code. A
iii
worldwide community of hundreds of contributors, including many employees of
Red Hat, collaborate via the Internet in developing and improving the Linux
kernel.
Open source uses a combination of technological and legal means to
facilitate collaborative development and commercial exploitation. Typically, an
open source package originates as a community-based project that 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. The Linux kernel, for example, is licensed as a
whole under the GNU General Public License, version 2, the most widely-used
open source license. 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 entirely in-house and provides only object code to the user under
severely 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 quality. Because there are many developers
working as collaborators, innovation happens rapidly.4 Because of the many who
iv
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 open source development model originated in the early 1980s. From
that time to the present, open source software has been in a constant state of
innovation. Software patents, however, have not in any way promoted the
innovations of open source. At the time when software was first released under
open source licenses, software patents were relatively few in number and case law
appeared to limit their availability. See Diamond v. Diehr, 450 U.S. 175, 18586
(1981). By contrast, it was settled that copyright law covered software. Thus the
early innovators of open source software had no reason even to consider
obtaining patents on their work. Moreover, since at least the early 1990s open
source developers have been broadly united in their opposition to the patentability
of software.
This widespread opposition is not surprising, because the open,
collaborative activity at the heart of open source is fundamentally at odds with the
patent system. Patents exclude the public from making, using, or selling patented
v
inventions. An open source developer seeks to contribute code to the
community -- not to exclude others from using the code. The exclusionary
objectives of the patent system are inherently in conflict with the collaborative
objectives of open source.
This conflict is more than theoretical. Open source software developers
constantly face the hazard that the original code they have written in good faith
might be deemed to infringe an existing software patent. It is impossible for a
developer to rule out this possibility, because there are now more than 200,000
software patents, and those patents cannot possibly be searched and cleared at
reasonable cost. Because of the abstract nature of software patents, determining
whether even a single software patent claim is infringed is particularly difficult,
even for experts in computer science, and experts often disagree. See, e.g., J.
Bessen and M. Meurer, Patent Failure 201-03 (2008). The complexity of
software projects (open source and otherwise) is such that a single computer
program is likely to implement numerous forms of functionality that could
possibly be deemed to infringe large numbers of unknown patents. Since code
may infringe any number of patents, there is always some possibility of a patent
lawsuit that could cost millions of dollars in attorneys' fees and that could result
in court orders that effectively nullify the broad grant of rights in open source
licenses.
vi
In short, the patent system is not the source of innovation in open source
software. Because the system does not reward open source innovation and
creates litigation risks for the innovators, the system can only hinder innovation.
Thus innovation in open source software continues in spite of--not because of--
the patent system. The successes that have been built on the open source model
are likely to continue. It is, however, an opportune time to address the standards
that govern the subject matter limitations on patentability, because clarification of
those standards will unquestionably influence the future of open source software,
and the future of the software industry generally. It may be that clarification of
those standards will benefit open source by reducing the risk of lawsuits and
encouraging greater participation in the open source community, with associated
benefits for the economy and society as a whole.
5
vii TABLE OF CONTENTS
Page
CERTIFICATE OF INTEREST .............................................................i
INTEREST OF AMICUS ................................................................. ii
TABLE OF CONTENTS.................................................... viii
TABLE OF AUTHORITIES .................................................................ix
ARGUMENT ........................................................................1
I. ABSTRACT IDEAS ARE NOT WITHIN THE LIMITS SET
BY THE PATENT ACT FOR PATENTABLE SUBJECT
MATTER....................................................................2
II. AN ABSTRACT IDEA DOES NOT BECOME
PATENTABLE MERELY BY JOINING IT WITH A
COMPUTER .......................................................................4
III. THE STANDARD SET FORTH IN STATE STREET BANK
AND AT&T IS INCONSISTENT WITH THE SUPREME
COURT'S CASES ....................................................7
CONCLUSION.............................................................10
CERTIFICATE OF FILING AND SERVICE
CERTIFICATE OF COMPLIANCE
viii
TABLE OF AUTHORITIES
Page(s)
CASES
AT&T Corp. v. Excel Communications, Inc.,
172 F.3d 1352 (Fed. Cir. 1999), cert. denied,
528 U.S. 946 (1999) ......................................................1, 5, 8, 10
Cochrane v. Deener,
94 U.S. 780 (1877) ............................................................3
Diamond v. Diehr,
450 U.S. 175 (1981) ........................................... passim
Gottschalk v. Benson,
409 U.S. 63 (1972) .................................................................... passim
In re Comiskey,
499 F.3d 1365 (Fed. Cir. 2007) ...............................................................4, 10
In re Nuijten,
500 F.3d 1346 (Fed. Cir. 2007) .................................................................2, 7
Laboratory Corporation of America Holdings v.
Metabolite Laboratories, Inc.,
548 U.S. 124, 126 S. Ct. 2921 (2006) ...........................................................9
O'Reilly v. Morse,
56 U.S. (15 How.) 62 (1853) ................................................................10
Parker v. Flook,
437 U.S. 584 (1984) ............................................................... passim
State Street Bank & Trust Co. v. Signature Financial Group, Inc.,
149 F.3d 1368 (Fed. Cir. 1998), cert. denied,
525 U.S. 1093 (1999) ................................................................ passim
ix
STATUTE
35 U.S.C. § 101.................................................... passim
OTHER AUTHORITIES
J. Bessen and M. Meurer, Patent Failure (2008) ....................................................vi
E. von Hippel, Democratizing Innovation (2005) ..................................................iv
x
ARGUMENT
In inviting briefing on the reach of 35 U.S.C. § 101, this Court has
recognized an issue of enormous significance. The resolution of this issue is
likely to affect, among other enterprises, open source software. Red Hat therefore
welcomes the opportunity to offer its perspective on three of the issues on which
the Court has requested briefing: (1) whether subject matter is patent-eligible
when it constitutes an abstract idea or mental process; (2) whether a method or
process must result in a physical transformation or be tied to a machine to be
patent-eligible subject matter under Section 101; and (3) whether the Court
should reconsider State Street Bank & Trust Co. v. Signature Financial Group,
Inc., 149 F.3d 1368 (Fed. Cir. 1998), cert. denied, 525 U.S. 1093 (1999), and
AT&T Corp. v. Excel Communications, Inc., 172 F.3d 1352 (Fed. Cir. 1999), cert.
denied, 528 U.S. 946 (1999).
In summary, we contend in Part I that abstract ideas are not patentable
when they involve no substantial physical transformation. In Part II, we explain
that insubstantial physical transformations, such as running a software-implemented algorithm on a computer, should be deemed insufficient to come
within Section 101. Finally, in Part III, we argue that the standard for patentable
subject matter in State Street Bank and AT&T is inconsistent with binding
Supreme Court precedents and should therefore be reconsidered and modified.
1 I. ABSTRACT IDEAS ARE NOT WITHIN THE LIMITS SET BY
THE PATENT ACT FOR PATENTABLE SUBJECT MATTER
The language of the Patent Act sets clear limits on patentable subject
matter. To be patentable, a claimed invention must belong to one of the four
categories of subject matter specified in Section 101 -- a process, machine,
manufacture, or composition of matter. 35 U.S.C. § 101. "If a claim covers
material not found in any of the four statutory categories, that claim falls outside
the plainly expressed scope of § 101 even if the subject matter is otherwise new
and useful." In re Nuijten, 500 F.3d 1346, 1354 (Fed. Cir. 2007). In addition, the
Supreme Court has held that patent protection may not be granted for "laws of
nature, natural phenomena, and abstract ideas." Diamond v. Diehr, 450 U.S. 175,
185 (1981).
Diehr is the Supreme Court's most recent statement on the scope of
patentable subject matter under Section 101, and it is therefore worth particularly
close examination. The case has frequently been misread as a departure from
prior Section 101 cases and as a basis for patenting subject matter that is abstract
and intangible. In fact, however, Diehr reinforces the importance of the Section
101 categories and confirms that intangible subject matter may not be patented,
whether directly or indirectly through artful claim drafting.
The question presented in Diehr was whether a method for curing raw
synthetic rubber using a mathematical algorithm implemented as a computer
2
program was a process within the coverage of Section 101. The Court described
a patentable process as "an act, or a series of acts, performed upon the subject-matter to be transformed and reduced to a different state or thing." 450 U.S. at
183 (quoting Cochrane v. Deener, 94 U.S. 780, 788 (1877)). "Transformation
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." Id. at
184 (quoting Cochrane).
The Diehr Court found that the patent before it disclosed steps for
transforming raw rubber into a different state (that is, cured rubber), and so it fell
within the boundaries of Section 101. 450 U.S. at 18485. Diehr did not suggest
a broadening of the traditional requirements for patentable subject matter, but
instead restated the requirement that a process patent involve a physical
transformation. Id. at 18384.
The Diehr Court took care to emphasize the continuing validity of its prior
cases barring patents for abstract ideas. It reaffirmed its holding in Gottschalk v.
Benson, 409 U.S. 63 (1972), that algorithms, or procedures for solving
mathematical problems -- the building blocks of computer programs -- cannot be
patented. Id. at 186. Likewise, it reaffirmed its holding in Parker v. Flook, 437
U.S. 584 (1984), that an algorithm for computing a number that served as an
alarm limit was not patentable. It contrasted these intangible processes with the
3
highly tangible subject matter of the Diehr patent -- curing of rubber. Id. at 187
88.
In short, Diehr is not properly understood as modifying the traditional
requirements for patentability. Instead, Diehr reaffirms that abstract ideas by
themselves are unpatentable, and that only inventions that are sufficiently tangible
are patentable.
II. AN ABSTRACT IDEA DOES NOT BECOME PATENTABLE
MERELY BY JOINING IT WITH A COMPUTER
Distinguishing an unpatentable abstract idea from a patentable process or
machine is not always straightforward. 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
18488. See also Parker v. Flook, 437 U.S. at 58994. The Supreme 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. This Court, in In re Comiskey,
broadly summarized this case law by saying "a process claim reciting an
algorithm [can] state statutory subject matter if it: (1) is tied to a machine or (2)
creates or involves a composition of matter or manufacture." 499 F.3d 1365,
1377 (Fed. Cir. 2007).
4
It is possible, however, to read such limiting language so that it renders
abstract ideas patentable. For example, "tied to a machine" could, if read literally
without a view to prior case law, be taken to mean "run on a computer." Indeed,
State Street Bank and AT&T adopt this approach. In addressing the scope of
Section 101, this Court should now reject this approach, because it is plainly
inconsistent with the Supreme Court's holdings in Benson and Diehr.
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 6566. 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, the Supreme 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.
5
The more recent decision in Diehr is consistent with this understanding.
The rubber curing process in Diehr involved an algorithm and a computer, but the
Supreme 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 18485. Diehr explained that
use of the computer did not render the process unpatentable, 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 joining an otherwise
unpatentable algorithm to a general-purpose computer.
It is true that the line between tangible and intangible subject matter is not
precise. There is a sense in which a purely mental process that is implemented
entirely within the human brain involves a physical transformation, inasmuch as it
involves physical neurotransmitter chemicals acting on physical cells. However,
6
the Supreme Court's decisions in Benson, Flook, and Diehr make clear that
mental processes are not, by themselves, patentable, because they are too abstract
and intangible. Similarly, transitory changes in electronic states that occur in
circuits could be characterized as tangible at some level, but these cases show that
more is required for Section 101. Cf. Nuijten, 500 F.3d at 1353 (Section 101 does
not permit patenting claims directed to "physical but transitory forms of signal
transmission such as radio broadcasts, electrical signals through a wire, and light
pulses through fiber-optic cable"). Thus this Court should make clear that merely
joining an algorithm to a general purpose computer is not sufficient to create
patentable subject matter.
III. THE STANDARD SET FORTH IN STATE STREET BANK
AND AT&T IS INCONSISTENT WITH THE SUPREME
COURT'S CASES
The Federal Circuit has not consistently followed the path laid out in Diehr
and earlier cases with respect to Section 101. In State Street Bank, this Court
adopted a new test for patentable subject matter that was not well grounded in the
statutory language of Section 101 or the guiding Supreme Court precedents. This
Court said the question of statutory subject matter should not focus on the four
categories of Section 101. Instead, the Court set forth a new focus: "practical
utility." 149 F.3d at 1375. The Court acknowledged that the Supreme Court had
held that mere abstract ideas were not be patentable. Nevertheless, it went on to
7
determine that abstract ideas were patentable if they produced "a useful, concrete
and tangible result." Id. at 1373.
This Court applied the approach of State Street Bank in AT&T, which
concerned a patent for a primary interexchange carrier ("PIC") indicator to be
used to calculate billing for long distance telephone calls. The Court found that
the claim was a "process" within the meaning of Section 101. Although the Court
acknowledged that "the PIC indicator value is derived using a simple
mathematical principle," it stressed that it provided "a useful, non-abstract result
that facilitates differential billing." 172 F.3d at 1358. The AT&T Court misread
the Diehr case and concluded that Section 101 did not require any physical
transformation. Id. at 135859.
The error in State Street Bank and AT&T is evident from comparison to the
Supreme Court's decision in Flook. There, the Supreme Court determined that a
method for determining an alarm limit during a catalytic conversion process was
not patentable subject matter. The Flook Court acknowledged that the application
of the method was "useful," 437 U.S. at 585, and there is no doubt it would have
satisfied the State Street Bank test of "a useful, concrete and tangible result."
Nevertheless, the Supreme Court held that the method failed to come within one
of the four categories of Section 101. Id. at 594.
8
Likewise, the result in Benson is inconsistent with this court's "useful,
concrete and tangible result" test. Benson concerned an algorithm to be
implemented on a digital computer for converting from binary-coded decimal to
pure binary form. Plainly, this algorithm was "useful." There were, and still are,
immediate commercial and industrial applications of such an algorithm. Indeed,
the Court recognized that the Benson algorithm had "substantial practical
application . . . in connection with a digital computer." 409 U.S. at 71. Moreover,
the output of the Benson algorithm is a number that is encoded in a particular
way. This Court has said that the "useful, concrete and tangible result test" is
satisfied "even if the useful result is expressed in numbers." State Street Bank,
149 F.3d at 1375. However, the Benson Court held that the algorithm was not
within the scope of patentable subject matter under Section 101. 409 U.S. at 73.
It is also worth noting that three justices of the Supreme Court have
criticized the "useful, concrete and tangible result" test. In Laboratory
Corporation of America Holdings v. Metabolite Laboratories, Inc., 548 U.S. 124,
126 S. Ct. 2921 (2006), Justice Breyer dissented from the Court's dismissal of the
writ of certiorari as improvidently granted, in an opinion joined by Justices
Stevens and Souter. Justice Breyer's opinion took care to point out, in connection
with the useful, concrete and tangible result test, that "this Court has never made
such a statement." Id. at 2928. The dissenting justices further noted that the
9
statement "would cover instances where this Court has held to the contrary." Id.
(discussing Benson, Flook, and O'Reilly v. Morse, 56 U.S. (15 How.) 62 (1853)).
In Comiskey, a panel of this Court recently reappraised the assessment of
patentable subject matter under Section 101. The Comiskey Court emphasized
that abstract ideas are not themselves patentable, even if they have practical
utility. 499 F.3d at 1377. Comiskey correctly refocuses the Section 101 inquiry.
It does not, however, by its terms reject State Street Bank, and it states that an
unpatentable mental process may become patentable by combining it with a
machine. Id. For the reasons explained in Part II of this brief, such a statement
can easily be misinterpreted so as to undermine the prohibition on patenting
abstract ideas. This Court should correct the erroneous standard of State Street
Bank and AT&T by rejecting the usefulness approach and making clear that
abstract ideas, even when combined with general purpose computers, are not
generally patentable.
CONCLUSION
In view of the requirements of Section 101 and the governing Supreme
Court precedents, this Court should reaffirm the prohibition on patenting abstract
ideas. It should reject the test set forth in State Street Bank and AT&T and adopt
a test which is consistent with Diehr and other Supreme Court case law and
which requires an element of physical transformation.
10
Respectfully submitted,
___[signature]____
Richard E. Fontana
Robert H. Tiller
Red Hat, Inc.
[address, phone]
Attorneys for Amicus Curiae
Red Hat, Inc.
April 7, 2008
1 Open source software is also known by the earlier term "free software." "Free" here refers to the freedom to study, modify and share software, rather than availability at no cost; all open source licenses permit and facilitate commercial distribution. The term "free" has the benefit of emphasizing the ethical foundations of open source but can cause confusion if misunderstood to mean gratis. Therefore we have used the label "open source software" in this brief.
2
In some cases, source code is not compiled but is run directly by an
"interpreter" program. The main disadvantage of interpreted code is poor
execution speed.
3 There are many thousands of open source software packages in wide use. Other
well-known examples include the Apache web server, the Firefox web
browser, the MySQL database management system, and the GCC compiler
collection. A leading web site devoted to open source development,
SourceForge.net, now has more than 170,000 registered open source projects.
4 See, e.g., E. von Hippel, Democratizing Innovation, ch. 7 (2005)
5 Red Hat participates in the patent system in order to address the risk of patent litigation. It has built a portfolio of software patents, but that portfolio is designed to be used only for the purpose of defending against patent aggression. In keeping with its commitment to protect and advance the open source community, Red Hat has extended a public Patent Promise under which it pledges not to enforce its patents against parties who infringe those patents through their use of software covered by designated open source licenses.
11
Certificate of Service and Filing
Certificate of Compliance with Type-Volume Limitation, Typeface Requirements, and Type Style Requirements
|