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
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

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


To read comments to this article, go here
The Arguments For Patents for Business Methods and Software-Implemented Inventions - And Some Against
Saturday, September 26 2009 @ 09:02 PM EDT

I asked if it would be possible for the law firm of Wolf, Greenfield & Sacks to write an article defending business methods and software patents for Groklaw, and they were nice enough to agree to do it. Steven J. Henry and Eric L. Amundsen, to be specific, were nice enough and brave enough to step up to the plate and explain why, in their view, based on their experience as IP attorneys, the sky will not fall no matter how Bilski is decided.

I know, and they know -- because I made it clear -- that most of us here are opposed to software patents and disagree with their position. But they came anyway, and I appreciate it. Thank you both. Please treat them as my guests at this party, with respectful attention, and then explain to them in return, please, all the reasons you do or do not agree. References are ideal for expanding and deepening the conversation.

It's particularly pertinent now to be having this discussion because the Supreme Court is going to be deciding the appeal of Bilski, and I thought it would be useful to consider a bit of the history of those kinds of patents and the cases that led to them being thought of as patentable subject matter. Groklaw can't file an amicus, but at least we can contribute to thinking about the issues. Think of it as tossing a note in a bottle into the ocean. You just never know who you might reach. When I go down the Patently O list of Bilski briefs now being filed with the Supreme Court, I don't see the pro-software/methods patents proponents even addressing the needs and concerns of the FOSS community.

I will simply point to the single most important reason FOSS developers and users of GNU/Linux operating systems are so opposed to software patents -- they violate and block a new development model, that of Open Source. That is the one argument I don't see being addressed. The Internet is built on Open Source. Every time you use Google or Amazon, you are using Open Source. So I believe the economy can be affected by Bilski in ways not everyone has thought through sufficiently. I'll put some further remarks after the article, so as not to skew your impressions on first reading by answering the article before you even read it. But after the double row of stars, I'll amplify. My goal is that both sides of this discussion have a deeper understanding of the other's point of view.

In addition to any comments that may be posted here in response, you will find a long thread of comments -- there are over 400 comments on that article alone as I write this introduction -- specifically on whether software is math and hence unpatentable subject matter here. If anyone wishes to re-post their best arguments here, that would probably be helpful, so as to have them all in one place.

So with that introduction, let's first let the two patent attorneys present *their* arguments for business methods patents and software patents.

***********************************

The Arguments For Patents for Business Methods and Software-Implemented Inventions
By Steven J. Henry and Eric L. Amundsen

Defining the Debate

Let’s begin with something on which we—hopefully—can agree. Since a landmark 1998 U.S. court decision granted patentability for inventions in the fields of business methods and software-implemented inventions, a controversy has raged between those in favor of patents for such inventions and those believing these patents are, at least, unnecessary and, at most, an impediment to innovation.

Recognizing that the majority of Groklaw readers are in the latter camp, the goals of this article are to present a historical perspective through which to view the debate, clarify some of the facts surrounding it, and provide answers to the primary arguments in opposition to the idea of allowing patents on business method and software-implemented inventions.

Through the Looking Glass: a Historical Perspective

How Large the Tent?

The purpose of the patent system is to encourage innovation, disclosure of ideas, and investment in inventions. From the beginning, a central question has been “What kinds of things should be eligible for protection?” Philosophically, the approach in this country has been that the tent should be large: as it was put by the U.S. Supreme Court in one of the first biotech patent cases, Chakrabarty, “Congress intended statutory subject matter to ‘include anything under the sun that is made by man’.” However, the Court has also noted certain exceptions, on policy grounds, for inventions of a sort that nobody should be able to appropriate personally: laws of nature, scientific principles, and abstract ideas.

Why the breadth of types of inventions that can be patented? Aside from the fact that the evolution of new technologies is impossible to forecast, the underlying theory is that the public benefits and loses nothing. A patent may not subtract from that which was already available in the public domain before the invention was made; it only enriches the public. That is, in return for the right to exclude others for a period of time, the inventor discloses to the public something nobody had previously known. The public cannot directly use the invention during that period of exclusion, but it can do so later, and, even during the exclusionary period, the public can be spurred by the invention to seek alternatives to it or improvements that may merit their own protection. Many patents (and by extension the inventions which they protect) are clearly valuable based on the amount of money that entities are willing to spend to license or purchase patents. If one assumes that but for the applicant’s contribution, the inventive advancement that a patent represents would have not come about, or at a minimum would have been significantly delayed, then the patent does not represent a taking from the public, but rather a contribution of something new.

When this country was founded, there was considerable antipathy to monopolies. Such attitudes traced back to when the British crown granted exclusive rights to its favorites. For example, a monopoly—or patent—on salt. Patents on inventions were a different animal. They were an extension of a person’s natural right to “own” his or her creative thoughts. The only kind of patents our founding fathers blessed, therefore, was a monopoly over new intellectual work product.

As cast in the Constitution, Congress was given the power to provide for limited times, to authors and inventors, the exclusive rights to their contributions to “science” (the word used for natural philosophy, which is the basis for the copyright system) and the “useful arts” (the term embracing all manner of commercially beneficial invention.) Instead of limiting freedom of commerce and raising prices, these exclusive rights promised, among other things, to encourage inventors to disclose their ideas and to offer the public free use of such new inventions after a reasonable period of time.

That still leaves the question of what should potentially be patentable. This includes both the kinds of things (i.e., “eligible subject matter”) and defining when an idea represents a large enough advance to warrant a patent (i.e., the requirements of “novelty” and “nonobviousness”.) After all, protecting trivial, inevitable advances would thwart progress.

The Inclusion of Processes

In addition to machines, tangible objects, and new chemical compositions, advances in manufacturing methods and the like—or “processes”—were considered important and justified protection. The question then naturally arose: Do we mean all processes, just manufacturing processes, or what?

In the 1800’s, a number of important inventions of the industrial revolution were perceived by their inventors to be definable, at least in part, as processes. For example, the process of modulating an electrical signal on a wire to communicate either telegraph or voice signals by wire. The apparatus was also new, but it was recognized that protecting the apparatus alone was inadequate. Others would conceive of new and different apparatus to practice the same techniques.

If you are old enough, you may remember when almost all microphones—certainly the good ones—were so-called carbon microphones that worked on a variable resistance principle. (Today, you would have to go to a museum or perhaps eBay® to find one of these.) We now use more efficient and less expensive microphones based on variable capacitance or other principles. All microphones share the generic ability to transduce sound pressure waves from the air into varying electrical signals, and it is that process that Alexander Bell originally recognized as his contribution, and which he battled through the courts to protect. Likewise, Samuel Morse sought to protect broadly a technique for signaling electrically. Neither wanted to be confined to his initial apparatus.

However, in the early 1900’s, there was a company that obtained a patent on a bookkeeping system to prevent embezzlement by waiters. The final decision in that case was interpreted as signaling that methods of doing business—as opposed to the apparatus used in practicing those methods—fell outside the patent system. That is, not all processes were embraced by the statute. So for decades, patent attorneys told their clients that business methods could not be protected.

Fast Forward to 1998

A sea change occurred in 1998. Two cases reached the U.S. Court of Appeals for the Federal Circuit (“Federal Circuit,” which has exclusive jurisdiction over patent law cases at the appeals level) within months of each other. In the first case, State Street Bank and Trust v. Signature Financial Group, State Street challenged a patent by a small mutual fund administrator, Signature, which claimed a computer system for administering a certain kind of mutual fund family. The challenger argued that, though the claims defined a computer system, they should be treated as an unpatentable method of doing business. The Court ruled that the claims were not directed to a method and, anyway, there was no basis for excluding business methods (whatever that term means.)

In the second case, AT&T v. Excel, AT&T was challenging a patent on a method of modifying cell phone billing records to facilitate the billing of roaming calls. The Court basically reinforced that its ruling in State Street really did apply to method claims and also made clear that there was no basis for excluding an invention because it was implemented in software. Both the programmed computer and the method it implemented were eligible for consideration (and could receive protection if novel and unobvious.) Suddenly, a new mindset was in order. Methods of doing business and software-implemented inventions could receive patent protection.

The U.S. Patent and Trademark Office (PTO) reacted. Congress reacted. The press reacted.

Notable among the PTO’s reactions, it created a special classification for business methods, sought out patent examiners with MBAs, established mandatory criteria for searching for prior art, brought in outsiders to lecture examiners on the state of the art in banking, finance, industry, and created a panel of seasoned examiners to screen all potential allowances before granting patents.

Congress, for its part, declined to alter the statutory definition of eligible subject matter, but created a personal defense to infringement of a business method patent. If the accused infringer could show that it had been using the process in its business more than a year before the patentee’s filing date, it was not liable for infringement and could continue to use the same process.

Enter Bilski

While the majority of business-method-oriented patent applications required a computer or other hardware support, some people speculated that because the 1998 decisions were silent as to such a requirement, it might be possible to obtain patents on processes that were not confined to machine implementations. For example, were it not barred by prior art, would an adjustable rate mortgage process or the issuance of a security with special characteristics be eligible?

The question is now looming large in a test case, Bilski et al v. Kappos, soon to be heard by the U.S. Supreme Court. The PTO rejected the claims in a patent application on a method for managing risk in commodity consumption transactions, using hedging techniques. Notably, the only rejection the PTO made was on improper subject matter; it did not reject for obviousness. The Federal Circuit—with all 12 judges sitting as a single panel—affirmed the PTO rejection but created a new test which requires each method claim to either tie the method to a “particular” machine or to transform an article or thing to a different physical condition/state or composition.

The new test spawned three vigorous dissenting opinions and has drawn much criticism, leading the Supreme Court to take the case, apparently to clarify the law. There have been 40 “friend of the court briefs” filed challenging the new test, and there will likely be as many supporting it.

If the Supreme Court affirms this test, many business method claims will fail. For example, all claims similar to those in Bilski which merely involve creating or changing legal obligations among parties, will not pass. To opponents of business method patents, this will be a near total victory, and to proponents, a near total loss. However, it will also mean that the methods implemented by much traditional technology also will not be protectable, for example, some involving the diagnosis and treatment of humans and animals which are not limited to specific equipment, claims to public key encryption and other information transmission processes, and numerous others. Many speculate the Supreme Court will take a less mechanistic view and leave room for challenging some business methods as abstract ideas, while allowing others as sufficiently specific and applied.

It’s fair to say the Supreme Court’s decision will be anxiously awaited from those on both sides of the debate.

Digging Deeper into Some Facts

Let’s acknowledge upfront that there are imperfections in the operations of the PTO. Much has been written about some patents improvidently granted due to lax examination in the PTO. Further, the fact that certain patent claims on software-implemented inventions generally thought dubious have survived litigation suggests some general imperfections in our civil litigation system. So as not to “throw the baby out with the bath water,” however, we believe these actions do not demonstrate that an overall anti-patent position is beneficial to the country.

On inspection, one will actually find that the allowance rate for patent applications for software-implemented inventions is lower than average, and that applications for business method inventions are examined under a higher, two-tier level of scrutiny reserved for them alone. For those applications that do survive examination and have claims that are still broad enough to justify litigation, few go all the way to trial and still fewer survive the withering litigation process and result in significant damage awards.

Most patents that have commercial value—whatever the field—are used for licensing and other types of business deals, or to persuade a competitor to change its product. Hence, it is no surprise that a recent study found great importance for small companies in patents for software-implemented inventions. R.J. Mann, “Do Patents Facilitate Financing in the Software Industry?,” Texas Law Review, March, 2005.

As practitioners, we represent parties with highly varied interests: one moment seeking to protect an invention and the next defending a client against a dubious charge of infringing a dubious patent. Our biases result from years of anecdotal experience. Approached with an open mind, the same economic behaviors appear to apply to the fields of business and software as in other fields. Sometimes, patents help create order and opportunity—especially for smaller businesses and universities—while at other times they are obstacles (perhaps even unfair obstacles) that competitors find obnoxious.

Determining the net impact of patents on business method and software-implemented inventions requires a data set large enough to provide statistically valid analysis. The problem, however, is that the number of granted patents in these areas which have been subjected to the exhaustive gamut of litigation, or to an otherwise intense prior art study in a PTO reexamination or other process, is extremely small. One reads about things like the I4i case against Microsoft and one is tempted to extrapolate. Not only would that extrapolation be statistically invalid, it would also be based on incomplete information.

First, the PTO filters out nearly 60% of the applications filed and whittles down the majority of others to a lesser scope than the applicant initially sought. Very few of the resulting patents end up in litigation, and about 96% of filed patent infringement lawsuits never make it to trial, being dismissed or settled far short of that point. So the lawsuits we read about in the press usually represent the instances where a patent has survived numerous attacks already, a lot of money is at stake, and reasonable people differ as to which party has the better story to tell.

In those few cases that do go to trial, we ask non-technically trained judges and juries to listen to witnesses and make a decision based on the evidence presented. Then these decisions are reviewed by a technical community which may have little knowledge of patent law and may not fully understand what constitutes prior art and what attacks have already failed. While different results might have been obtained from a technically trained judge or jury, such as striking one or more patent claims that a lay judge or jury accepted as valid, there is little empirical data on which to base this assumption.

In the authors’ experience, when there is clear and unmistakable prior art that shows the invention to have been known by the public prior to the inventor having conceived it, there is usually a withdrawal or settlement of the case. Otherwise, if there is room for disagreement and enough at stake, the fight can go on for some time and lead to results some might find scandalous or absurd. That, however, does not mean the system is broken. There will always be results with which experts will disagree, if for no other reason than they have a different concept of what constitutes obviousness.

Why Should Software-Implemented and Business Method Patents Be Treated Differently?

Many opponents of patents on software-implemented inventions and business method inventions insist that, from an economic and policy perspective, the grant of such patents is unnecessary, at least, and harmful, at worst. Based on our experiences and observations, we suggest that many of the proffered arguments would apply equally to other types of inventions. That is, most of the arguments are not specific to the software-implemented and business method categories of invention. Some arguments may be different in degree, though—e.g., difficulty of finding prior art, ability of a competitor to get a patent on a process used secretly by others for years, lack of examiners with expertise in the subject matter (financial transactions, insurance, etc.) However, our experience is that many of the advantages traditionally associated with patents on mechanical devices, chemicals, etc. also apply to patents on business methods and software-implemented inventions, and many of the concerns are based more on fear than actual data.

Because of the positive incentive aspects of the patent system, within the universe of mechanical, pharmaceutical, chemical and electrical inventions, patents are generally (though not universally) accepted as a beneficial policy or, at worst, a necessary evil. Why then, do software-implemented and business method patents stir so much debate as compared to more “traditional” patents? Perhaps there is a shift in the public’s respect for property—or at least intangible property—in general. Perhaps putting the means for copying digital information into the hands of nearly every person on the planet induces a different mindset. Perhaps the very practices of making some software available for free leads some to think it all should be free (in the economic sense, not the open source sense.) Perhaps the nature of such inventions plays a role. For example, software and information processing methods typically do not have “parts” that are viewed and manipulated on a scale visible to the naked eye. Similarly, business methods often involve the manipulation of information and legal obligations.

Yet advances in these subject areas require inventions and investment just as much as new mechanical devices. And providing incentives and protections for inventions and investments in the software and business method arenas is becoming more important to the United States with the shift toward a knowledge-based economy. New ideas and new companies expand the economy. If a new company’s flagship product is sure to be copied by domestic or foreign competition, the incentives to develop—and to invest in—the new product in the first place are significantly reduced.

That is not to say that no incentives would exist, as there may be a sufficient marketing “first-mover” advantage, but the overall incentives would be reduced. If investors are not comfortable about the non-IP advantages being sufficient to permit a reasonable return on a risky investment, they simply will not invest. Time and again one of the first questions potential investors ask us is whether there will be good patent protection available when an invention is readily copiable by competitors.

Even when the invention does not cost a fortune to develop, marketing costs may still be in the millions or tens of millions of dollars. No investor wants to back a small company that is going to have a larger competitor steal its thunder with a copycat product or service, without recourse.

Answering the Arguments Against Software and Business Method Patents

Below are some alternative reflections to some of the more common arguments put forth in opposition to the idea of allowing patents on business method and software-implemented inventions.

“Patents stifle competition, thereby impeding new businesses and raising prices for products and services.”

This criticism could be voiced for any type of patent, whether it be mechanical, pharmaceutical, or software-related. From a short-term standpoint, the statement can be true in that a patent holder can prevent entities from using their patented invention or charge higher prices as compared to those of alternative products or services. But from a longer-term standpoint, competition is promoted by the patent system because new inventions and improved products are more likely to be brought to market to challenge the status quo. If anything, the introduction of a new, improved version of a product with a patented feature will drive down the price of the pre-existing products, as they are now less desirable and a better alternative exists. It is irrelevant how much the innovator charges for the new, patented product. It did not exist previously and the public is free to refuse to pay a price it considers too high.

A system that does not encourage and reward invention and innovation, by contrast, logically leads to a lower level of competition for established technologies and can, over time, lead to higher prices and less efficient “legacy” technologies. The mere existence of a dominant player in a given market can discourage a new company from attempting to bring an inventive technology to market because of the fear that the dominant player will co-opt the invention if the invention is successful. It can “cherry pick,” avoid the expense of R&D, and offer the same product at the same or a lower price, making the innovator non-competitive. A new business has little chance of competing with the dominant player based on the latter’s lower overhead (due to having avoided the R&D expense,) possibly lower price, marketing channels, brand recognition, etc. Accordingly, while competition for an already existing invention might be increased by eliminating patents, the lack of patent protection would ultimately reduce attempts to compete with existing products and services in the first place.

“Innovation would happen without patents. Software and business methods have advanced during periods when patent protection was not available for such inventions.”

Some software developers argue that they engage in their creative activity for the joy if it, for the intellectual challenge, and for the reward of helping others or seeing the fruits of their ingenuity and labor adopted by others. That is, the psychic reward is enough. Others say that to stay one step ahead of the competition, they have to engage in continuous product improvement and do not need the patent system to protect their improvements (after all, it takes so long to get the patent that it represents an obsolete approach by the time one is granted) or to get in the way and prevent them from making desirable advances. Patents to such individuals are roadblocks preventing them from adopting good ideas from others, something they think should be freely available in the world of software development. So, whether motivated by psychic reward or the profit motive, these individuals proclaim patents unnecessary and unwanted in the realm of software.

However, unlike pharmaceutical scientists or machine tool engineers, for example, software engineers often have the ability to develop and test their new ideas without enormous overhead. In this context, barriers (such as patents) to using existing inventions may feel unnecessarily obtrusive. Additionally, software engineers have more experience with copyright protection, where ideas may be freely appropriated and the copying prohibition is limited to the code and perhaps its organization, but not its functionality. Moreover, independent creation that does not involve copying is a complete defense to a charge of infringement. In the patent context, where inadvertent infringement is still infringement, and basic ideas and processes are protectable, intellectual property rights may feel burdensome. Many times, however, we have seen software developers change their mindset when it is they who have the great idea that took hundreds or thousands of person hours to develop into a new breakthrough product. Laissez-faire thinkers become pragmatists, either out of self-interest or in response to investor pressure, and ask us how they can protect their ideas and get investors to back them.

For business method inventions (whether relying on software implementations or not,) in addition to the complaint that “we got along just fine without them,” come the further complaints that the PTO is incompetent to examine business methods and that much of the prior art is non-public. These three complaints have a familiar ring to them. They are the same complaints we heard in the 1960’s and 1970’s about patenting software-implemented inventions. Over time, however, the PTO has built up its resources for searching for software prior art, has adopted a peer review program that allows the industry to cite prior art products and the like that might not be found in a literature search, and has hired and trained computer scientists as patent examiners.

Interested parties in every industry ask us: “How could the Patent Office have given those guys a patent on that idea? They weren’t the first to do that, anyway.” Or, “I see that X just got a patent on Y, but we’ve been doing Y in our operation for a long time. Does this mean we have to stop?” Opponents of business method patents may think they have unique complaints, but they do not. Some will cry over the lost opportunity to protect a new business method while others will be afraid that a competitor will now try to foreclose some path of development that previously might have been open to all.

For example, the insurance industry has long been a copycat industry. With little or no IP protection available to support proprietary rights, an innovator quickly sees others copying its new policy features. That could now change. An innovator might secure a new beachhead for a product and force a competitor to take a license or to tilt its products in a different direction. The lessons of theory and history suggest that the public will benefit because the variety of product offerings available to it will increase. Instead of competing solely on price, financial performance and client service, insurance companies may have to learn to be more creative and distinguishable in their offerings. Time will tell.

“Software and business method patents are too broad.”

Certainly, many overly broad software and business method patents have issued (in the sense that the claimed invention in reality was not new and nonobvious and the PTO failed to find the best prior art.) Of course, when this occurs, there are costs associated with contending with the patent and/or attempting to invalidate the patent. But overly broad claims are a consequence of the “new” and “nonobvious” hurdles being incorrectly cleared, and the fix for overly broad patents should not be the elimination of patents. Instead, the focus should be on improvements to prior art searching capabilities, and training for patent examiners and patent agents.

Additionally, overly broad patents issue in all fields, so software and business method patents are not unique in this sense. The PTO has made serious efforts to minimize such occurrences, but inevitably some number will occur. An additional challenge has been the rapid increase in software and business method patent applications after these fields became patent eligible, resulting in staffing pressure at the PTO. If you want to see the system perform better, support measures you believe will result in fewer “bad” patents and that will make it cheaper, easier, and faster to challenge patents on the basis of evidence the patent examiner has not reviewed.

“Abstract ideas should not be patentable, and therefore patents are for physical things, not software or business methods.”

The law is clear, and courts have consistently ruled that abstract ideas are not patentable. The issue here, then, is the interpretation of the term “abstract.” This has been a difficult question for the courts but, in many cases, courts have held that an abstract idea—such as a mathematical algorithm in and of itself—is no longer considered abstract when it is tied to a specific, practical application such as a structure or process. Critics of software patents often have a different view of the meaning of “abstract.” In some cases, people view software as abstract because it can be represented by logic charts. But logic charts can be used to represent mechanical devices, and software is ultimately implemented in a physical manner. In other cases, software is described as abstract because various terminology can have flexible meanings. This is a problem of clarity rather than a fundamental problem.

Business methods and systems to implement them, as well as software-implemented inventions, are inherently no more abstract than is the theory behind FM radio or data compression or a continuously variable transmission. All rest on ideas and concepts that had to come into someone’s head at some time, and all require some concreteness to bring them into the stream of commerce.

What is a “business method” anyway? What makes a method a “business” method? Is tracking your on-line activity and, from it, deducing what ads to present to you a business method? Let’s assume you answered affirmatively. I now ask, instead, about a method of minimizing the presentation of data to a computer user. Would your answer be different? They might be the same notion, packaged in different ways. We have yet to encounter a line-drawing exercise that justifies putting business methods in a category different from other inventions, in part because they exist as a category only in the eye of the beholder.

Conclusion

On balance, our experience is that the system, flawed though it may be, works reasonably well to promote innovation for the general good. Serious effort at improvement would not, in our minds, require exclusion of any specific kind of subject matter from protection. Rather, we believe more consideration should be given to prior art during the examination process, and less costly ways to challenge the validity or scope of a granted patent should be explored.

Of course, the game may radically change once the Supreme Court hands down its decision in the Bilski case. So stay tuned.

__________________

Notes:

Chakrabarty: http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=us&vol=447&invol=303… Hotel Security Checking Co. v. Lorraine Co., 160 F. 467 (2d Cir. 1908). patent no. 500,071

http://www.bricklin.com/patenting.htm

http://www.bricklin.com/patentsandsoftware.htm


Steven J. Henry is a shareholder and Eric L. Amundsen is an associate at the Boston-based intellectual property firm of Wolf, Greenfield & Sacks, P.C. Henry can be reached at shenry at wolfgreenfield.com and Amundsen can be reached at eamundsen at wolfgreenfield.com.


******************************************
******************************************

PJ's Additional Response:

I would suggest that anyone interested in why FOSS developers and the community in general are so opposed to software patents read Red Hat's introduction in its amicus brief in Bilski for the Appeals Court en banc review, if they wish to consider the important reasons why there is a need to adjust patent law to make room for Free and Open Source software development -- which, if you may have noticed -- is also making a huge contribution to the world's economies and deserves consideration for that reason alone. Software patents are not the source of innovation for Linux and FOSS. At the time, the court was asking different questions than the Supreme Court now is asking amicus briefs to address, but Red Hat pointed out the following in the introduction:

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.

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 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. 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 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 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.

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

Keep in mind that the licenses that most FOSS software comes to us under are either the GPL or the LGPL, and patents and the GPL do not mix. (If any attorneys wish to read up on that, here's a specific page with further information on the GPL and how it works.) So arguments asserting that innovation is being encouraged by software patents don't actually apply to any GPL code. Rather the reverse. Vendors and attorneys who are accustomed to handling proprietary software may not realize how damaging patents are for the new development model. Even IBM, who really should know better, filed an amicus brief [PDF] stating that open source software innovation is encouraged by patents. It is not. Here is one footnote that surprised me mightily:
22 Without the benefit of patent protection, software companies would be forced to rely on secrecy which limits the public’s ability to learn from software innovations, since patent documents are a significant source of technological disclosure. See, e.g., In re Alappat, 33 F.3d 1526, 1571 (Fed. Cir. 1994) (Newman, J., concurring). Given the reality that software source code is human readable, and object code can be reverse engineered, it is difficult for software developers to resort to secrecy. Thus, without patent protection, the incentives to innovate in the field of software are significantly reduced. Patent protection has promoted the free sharing of source code on a patentee’s terms—which has fueled the explosive growth of open source software development.
I'd like to see them prove that in a court of law, as they say. I don't believe they could. The GNU Project and Linux, the kernel, were both developed prior to the two cases this article cites, after all. And the idea that programmers in the US benefit from the knowledge patents provide is ludicrous, since everyone is terrified of reading any patents for fear of triple damages. Not to mention that most software patents are filed without the source code. They describe the process or the inventive step -- albeit in legal language most programmers find impenetrable -- but that's it. For example, take a look, if you are free to do so, at i4i's patents. They are attached to its Complaint. You will note that not even i4i claims Microsoft figured out how to do what i4i says it invented from that description in the patent application. It was available, but i4i claims Microsoft met with them and watched a demo and listened to explanations of how i4i did customXML, and *that* is how they say Microsoft learned the process. Had the source code been attached to the patent, Microsoft certainly could have learned how to do it from that. But who files source code? The idea of a patent is that knowledge is spread that way; but in reality it is not, so the public is not benefited in the way originally intended.

But the deepest problem in the footnote is the idea that secrecy benefits Open Source, when actually it's the openness, the ability to see the source itself and to use it to build upon. That is the purpose of the GPL, after all, to make sure no one can take code that is under that license and pull it under the surface of the water, so to speak, into proprietary secrecy. Red Hat's code is GPL code, and they are innovating and making money too, so something is logically wrong about the ideas expressed in that footnote. I notice that they provided no examples of Open Source companies benefiting from software patents.

Another amicus brief [PDF] filed with the Federal Circuit in 2008, FSF's End Software Patents' submission, addressed another problem with patents on what it termed information processing:

The economics of information processing is substantively different from that of physical materials processing, such that patents on information processing create progress-hindering problems that are not created by physical materials-based patents.

There is a pharmaceutical sector of the economy, with a few dozen companies; there is an automotive sector of the economy, which is also well-defined; but the “information processing sector” is the entire economy. Every organization in the world has information on hand that needs collating and presenting. Thus, allowing patents on information processing creates infringement risk not for a small set of companies who should know the patent literature, but for all companies everywhere. With literally millions of organizations potentially re-inventing any work of software, the holder of a software patent need only search the Internet to find a party to sue. Such opportunistic, unproductive lawsuits are a hallmark of the software patent.

The massive-scale liability created by information processing patents is not merely a theoretical prediction. Over the last few months alone, the Amicus tallied over fifty nonsoftware companies being sued for infringement regarding their web site or other course-of-business software, such as the Green Bay Packers, McDonald’s, Dole Foods, Kraft Foods, Caterpillar, J Crew, Burlington Coat Factory, Wal-Mart, and Tire Kingdom. See http://endsoftpatents.org/alitanyoflawsuits (visited April 3, 2008). Even this court is probably infringing some number of software patents, because it is has produced some portion of the software underlying http://www.cafc.uscourts.gov/.

In fact, the last decade of software patentability has brought about so many lawsuits considered to be onerous or frivolous that they have inspired Congressional action and caused many persons having ordinary skill in the art to question the entire patent system.

The point, obviously, is that when patents are so trivially granted on more and more types of "inventions", it becomes literally impossible to research whether or not you are violating someone's patent. The chill from that is real. I wish some of the proponents would answer that concern.

You might also enjoy reading the amicus brief the Software Freedom Law Center filed in Microsoft v. AT&T in 2006. It explains why software patents are so damaging and why they believe software is not patentable subject matter. In the press release, it said this:

"In contrast to the Federal Circuit, the Supreme Court has maintained limits on patentable subject matter throughout U.S. history," said Eben Moglen, Executive Director of SFLC. "The Supreme Court has consistently ruled that algorithms and mathematics cannot be patented. Since software is expressed as mathematical algorithms, it should not be patentable."
I would ask also that you consider how some are currently using software patents specifically against Linux and Open Source applications, as an anti-competitive weapon, which makes general statistics on unlikelihood of patent infringement litigation moot. It's real for us, and it is like an arrow pointed at the heart.

Even if they stopped, which they won't, patent law is for the rich, not for individual programmers who can't possibly defend against litigation the way a large vendor can.

I sincerely hope that the Supreme Court asks itself: do we want a system of law that would make it impossible for another Linux to be created? A system that benefits one type of software development, the proprietary software business model, but which impedes a competing type of development business model, Open Source?


  View Printable Version


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 )