decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Red Hat's Amicus Brief in Bilski, as text - Why Patents Harm Open Source
Wednesday, April 09 2008 @ 07:08 PM EDT

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


  


Red Hat's Amicus Brief in Bilski, as text - Why Patents Harm Open Source | 84 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections Thread
Authored by: Ed L. on Wednesday, April 09 2008 @ 07:38 PM EDT
Please provide clue in comment title.

---
The dream of vengeance is the darkest of dark, sad dreams. -
Stephen R. Donaldson

[ Reply to This | # ]

Off-Topic Thread
Authored by: Weeble on Wednesday, April 09 2008 @ 07:40 PM EDT
Anything on-topic here is STRICTLY FORBIDDEN. :-)

---
You Never Know What You're Going to Learn--or Learn About--on Groklaw!
(NOTE: Click the "Weeble" link for Copying Permissions and Contact Info.)

[ Reply to This | # ]

Newspicks Comment Thread
Authored by: Weeble on Wednesday, April 09 2008 @ 07:45 PM EDT
Ed, you remove your reply to my earlier thread seed and I'll delete my earlier
thread seed.

I really thought others woulda been way ahead of me.

------------------------------------------------------------

Anyway, y'all, please put the name of the article you're commenting on in the
subject line so we'll know what you're talking about. Thanks!

---
You Never Know What You're Going to Learn--or Learn About--on Groklaw!
(NOTE: Click the "Weeble" link for Copying Permissions and Contact Info.)

[ Reply to This | # ]

Produces "useful, concrete and tangible result" thread
Authored by: Ed L. on Wednesday, April 09 2008 @ 07:45 PM EDT
Abstract ideas, you know. Give it your best: I'll kick off with "F=ma".

:-)

---
The dream of vengeance is the darkest of dark, sad dreams. -
Stephen R. Donaldson

[ Reply to This | # ]

Patents don't just hurt Free Software
Authored by: Anonymous on Wednesday, April 09 2008 @ 07:46 PM EDT
They hurt ALL software and all software makers, so in the end they hurt all
users of software too.

How many Free Software companies have been sued over patents vs how many over
proprietary ones?

Who ultimately pays for their costs?

Just as with OOXML - who ultimately pays for that waste of money and time? All
of us.

[ Reply to This | # ]

Abstract ideas -- wrong path
Authored by: Anonymous on Wednesday, April 09 2008 @ 07:59 PM EDT
Inasmuch as any invention described on paper is an abstract idea, I think an
argument about software being abstract is just not going to work.

There is nothing abstract about a file, for example. In fact, the idea of a
digital file should not be patentable on the basis of abstractness: it's pretty
clever, and in fact "it works".

There is nothing abstract about a "One-click-buy-now-button". It's
very real.



[ Reply to This | # ]

Pencil and Paper
Authored by: overshoot on Wednesday, April 09 2008 @ 08:09 PM EDT
I've always thought that one reasonable test is whether the claimed invention
could, in principle, be performed by a human being aided by nothing more than
pencil and paper. If so, then the "invention" is an abstract idea and
the claim is to a monopoly on certain thoughts.

The degree of difficulty is not at issue, any more than is the length of a
Turing tape -- the test is an abstract one for purposes of making conceptual
distinctions. Lawyers should be able to deal with the idea that some tasks are
theoretically possible for humans without being feasible -- keeping up with the
case law in the United States, for instance.

[ Reply to This | # ]

Why not software patents? Here's why.
Authored by: Anonymous on Wednesday, April 09 2008 @ 08:31 PM EDT

Computer software is ultimately about configuring switches. Turning a light, or several lights, on and off is not subject to the permission of the switch's patent-holder.

Disclaimer: The link goes to my own site.

[ Reply to This | # ]

the extent to which we've been sold out ...
Authored by: Latesigner on Wednesday, April 09 2008 @ 08:37 PM EDT
Jefferson was clear about "protection against commercial monopolies"
he would have disowned our current politicians.
The folks who think they don't drink the same water, breath the same air or eat
the same food as the rest of humanity.

And now, apparently, they didn't think they thought the same thoughts.

---
The only way to have an "ownership" society is to make slaves of the rest of us.

[ Reply to This | # ]

Patentability test
Authored by: PolR on Wednesday, April 09 2008 @ 08:42 PM EDT
I notice Red Hat doesn't come with their own patentability test. They just raise
the precedents and ask for a test that is consistent. It is up to the Court to
work out the actual test.

I suppose this is the way it should be.

[ Reply to This | # ]

Patents harm the economy in general
Authored by: Anonymous on Wednesday, April 09 2008 @ 10:13 PM EDT
The Monopoly Factory

The author of the above linked article makes the point that the patent system is generally harmful to the economy. His examples come mostly from medicine but I suspect that they are generally applicable.
The cause of the problem is easy to pinpoint. Over the last decade and a half, the patent office has been set up in such a way that it's an easy mark. The system overwhelms many patent examiners, operates under laws and bureaucratic incentives that favor applicants, and can potentially be hoodwinked by the unscrupulous. A recent Federal Trade Commission report, which laid out these criticisms, concluded that in key industries such as pharmaceuticals, software, biotechnology, and the Internet, the office now "hamper[s] competition that would otherwise stimulate innovation." For some companies, armed only with dubious claims, the patent office has become not something to fear but a patsy, as easy to fool as those elderly couples who send cash to the Nigerian prime minister's wife.

[ Reply to This | # ]

Open source vs Free Software
Authored by: Anonymous on Wednesday, April 09 2008 @ 11:14 PM EDT
Open source software is also known by the earlier term "free software."

I don't think Richard Stallman would agree with Redhat's definition.

[ Reply to This | # ]

The real problem with software patents
Authored by: Anonymous on Thursday, April 10 2008 @ 04:30 AM EDT

The real problem with software patents: is the potential for injustice.

Injustice happens since patents come with a you cannot do that, namely do the same as the patent describes. This you cannot do that is enforced by the government and all its powers (police intervention in the end).

It becomes injust, when what the patent describes is not that original, so that it might occur to someone else (you).

So when a patent is applied for, the examiner should (ideally) take into account, how likely is it that someone else might happen upon this idea.

Within software, it can occur, that indeed, the idea is not that original -- a lot more easily compared to other areas.

One reason for that is that software is solving-problems, almost all of the time.

In as much as problems are often inter-connected, different people will face the same problem.

When someone faced the same problem the first time, and documented their solution, and obtained a patent, the injustice happens, when a second person runs into the same problem, and finds the same solution, completely independently. Then the patent would prevent the second person from enjoying the fruits of their labour, even though they

  • did all the work themselves, and on top of that
  • would have had to go through a huge amount of effort to find out that the first person already solved it. and on top of that,
  • would have had to go through additional effort to adapt the first person's solution to their problem.

The patent would be justified, if the second person, facing the same problem, would not find the solution, and after a while would realize that it is beyond them, and would ask "maybe there is a patent for that". Then if they found the patent, and realized its value, that would constitute some bearable justice toward the inventor: the second person would need to ask for permission.

Software is
  • very flexible : solutions are not always difficult to find (especially since there are lots of talented developers), but
  • very difficult : the same idea can be implemented very well, and very badly, and at the same time,
  • very inflexible : solutions always need to be tailored to the particular setting. So the idea behind a patent is often only a tiny part of the effort.

To me the benchmark is the question of whether Google's search method deserves a patent:

  • many organizations were working on the same problem.
  • Google's solution is not that difficult to explain and grasp.
  • there was prior-art in the form of scientific ranking of reserach papers by looking at the number of references.
  • it works
  • on the other hand, Google's ranking idea is not enough: one will face implementation problems, such as how to traverse all those web sites, how to parse the pages, how to collect the ranking data, store it, and finally, actually how to produce the search results. A bad implementation will not be useful and effective.
  • So that if Google did a bad job of implementing it (which they haven't), it would be injust to forbid others from offering their vastly superior implementation.

Thanks for your consideration.

[ Reply to This | # ]

3D printer to replicate itself
Authored by: David Gerard on Thursday, April 10 2008 @ 05:31 AM EDT

Called RepRap, released under GPL, aiming to make a version that can replicate itself.

This will be the point at which hardware patents become as damaging to innovation as software patents are.

We really need to get the hard thinking about our rights in regard to such devices now rather than later. Has RMS anything to say on the subject?

[ Reply to This | # ]

An Integral Perspective
Authored by: Anonymous on Thursday, April 10 2008 @ 06:27 AM EDT
It's interesting to see the different ways people everywhere are trying to
define the differences between Copyrights and Patents.
I've tried to look at an integral model for a clearer perspective.

Very quickly, we can consider any individual item as having 2 aspects - an
internal and an external. I'll just give a couple of quick examples:
Person Internal: Thoughts, feelings, emotions, views.
Person External: Body, skin, blood flow, brain chemicals, neuron firings.

Computer Internal: Programs, algorithms, objects, data, bits.
Computer External: Chips, electricity, switches.

Book Internal: Story, ideas, imagery, knowledge.
Book External: Layout, typeface, actual words, cover binding.

Music Internal: Lyrics, tune.
Music External: Sound waves, key, tempo, voice.

It's also worth noting that every internal has an external correlation - an idea
causes neural firings, emotions are linked to chemicals. A program is
represented by the configuration of a set of switches. A story is written in a
particular typeface.
However, there is a difference between the internals and the externals so that
one cannot be reduced to another.
Take for instance music copyright. If someone were to cover someone else's song
without paying royalties, it's still a copyright violation because the internals
have been duplicated. However, the song may be in a different tempo, different
key, different musical arrangement, different singer. The externals don't matter
to copyright, it's the internals that are affected. Similarly, someone can
borrow the band's guitar and use it in their own track, but even tho some of the
externals of the new track are the same as the original (same sounds produced by
the same instrument), it's not a copyright violation of the original track.

What Red-Hat and most others appear to be saying is that patents should be
limited to the external side of the street - ie, physical processes. Any
internals are already covered by a wealth of copyright law. Any confusion really
lies in confusing the external correlates with the internal realities, but they
are fundamentally different to everyone in their day to day life.

This appears to be a fairly clear way of defining the boundaries. What do you
think?

[ Reply to This | # ]

The open source development model originated in the early 1980s?
Authored by: Anonymous on Thursday, April 10 2008 @ 12:37 PM EDT
Gimme a break. Mainframe users were swapping source tapes in the 1950s, 60s, and
70s, improving each other's work, collaborating on larger projects, etc. That
was a world where not only did no one imagine there would be software patents,
but it was far from clear that copyright applied to software.

[ Reply to This | # ]

OSS-based pitch makes sense
Authored by: dwheeler on Thursday, April 10 2008 @ 02:59 PM EDT
I was concerned at first why Red Hat was focused just on the effects on OSS. After all, software patents are dreadfully harmful to proprietary software too, perhaps even more so.

But now I see a reasonable reason to emphasize this. Basically, this shows that patents are NOT needed to fix a "market failure" in software development. Patents create an intrusive and massive government bureaucracy, and interfere with free markets. The only reason to permit patents is to address a market failure, that is, to create a market where none would exist otherwise. The Constitution does permit creation of a patent system "To promote the Progress of Science and useful Arts"; if it's not needed or harms such progress, then there's no justification for expanding patents into software. So this line of thinking (focusing on OSS) could be interpreted as "there is no market failure, because we directly experience one way in which innovation in software can happen without patents - OSS development". Since there's no market failure, there's no reason to insert the pondering beast of patents into software development.

They may have done this for other reasons. Red Hat can't really speak for proprietary software companies, because they aren't one. But I think that this is a perfectly reasonable reason to emphasize the "OSS doesn't need patents" story... because it shows the judges that there's no need for the patent system to expand into software. There's no obligation for the courts to determine the impact on proprietary software, actually, as long as they can be convinced that there is a way that innovation can occur in software without patents.

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )