SOFTWARE PATENTS: TIME FOR ACTION ================================= by Gordon Irlam and Ross Williams Software patents, formerly considered merely worrying, are now out of control, and are actively damaging the software industry. With about 2000 new patents granted each year, software patents are jamming up everything from data compression to spreadsheets. The situation is now so bad that the US Commissioner of Patents and Trademarks has called a public hearing to procure comments from the public on the issue. This will provide the single best opportunity for the software industry to influence the software patent system. All software companies affected by software patents should act NOW to convey their opinion to the hearings on January 26-27, 1994 in San Jose - two weeks away at the time of this writing. The purpose of this document is to crystalize the case against software patents and thereby assist those in a position to significantly influence the outcome of these hearings: CEOs, VPs, legal professionals, and others. NOTE : This document is large simply because it contains many appendices containing supporting material. The main text can be read in less than twenty minutes. NOTE: This document does not advocate that companies cease applying for software patents or unilaterally dismantle their patent portfolios. This document presents the case for the legislative abolition of software patents. TABLE OF CONTENTS ================= 1. THE THREAT POSED BY SOFTWARE PATENTS 2. WHAT MAKES SOFTWARE DIFFERENT? 2.1 Software is More Complicated 2.2 Software is More Abstract 2.3 Software Technology Evolves Rapidly 2.4 Software Doesn't Wear Out 2.5 Software has Different Economics 2.6 Software is Successful Because of Market-Driven Properties 3. THE PROBLEM OF SOFTWARE PATENTS 3.1 Problems Developing Software 3.2 Problems in the Courts 3.3 Problems in the Patent Office 4. THE EFFECT OF SOFTWARE PATENTS 4.1 Current Corporate Behavior 4.2 Patents as a Selection Effect in Corporate Evolution 4.3 The Future 5. OPTIONS FOR THE SOFTWARE INDUSTRY 5.1 Options 5.2 Your position 6. ACTION 6.1 A Rare Opportunity 6.2 What You Can Do APPENDIX A: WHAT IS A PATENT? APPENDIX B: EXAMPLES OF SOFTWARE PATENTS B.1 Word Processors B.2 Spreadsheets B.3 Operating Systems B.4 Compilers B.5 Miscellaneous APPENDIX C: EXAMPLES OF SOFTWARE PATENT LAWSUITS APPENDIX D: NEGATIVE CORRELATION OF INNOVATION AND SOFTWARE PATENTS APPENDIX E: OPPOSITION TO SOFTWARE PATENTS APPENDIX F: ORACLE CORPORATION'S POLICY ON SOFTWARE PATENTS APPENDIX G: MITCH KAPOR'S CONGRESSIONAL TESTIMONY APPENDIX H: THE PATENT OFFICE ANNOUNCEMENT APPENDIX I: ABOUT THIS DOCUMENT 1. THE THREAT POSED BY SOFTWARE PATENTS ======================================= Let's play adventure! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Welcome to Patent Adventure V3.4 -------------------------------- You are the CEO of Acnesoft - a fairly successful software company. You are at your desk. Suddenly the fax machine rumbles... Command> READ FAX It's from SharkTech! They're claiming that your company's product "Acne Professional" violates their software patent "Displaying the Color Red on a Computer Monitor in a Circular Shape" and they want 5% of your wholesale price in royalties. Command> GIVE ROYALTIES Now they want 7%. Command> GIVE ROYALTIES That satisfied them. Hummmm! The fax machine is humming again. It's from ParaTech! They're claiming that your company's product "Acne Professional" violates their software patent "Displaying Text within a Window Whose Vertical Axis is Marked in Inches" and they want 3% of your wholesale price in royalties. Command> IGNORE THEM ParaTech have decided to take you to court. Do you want to settle for 10%, pay $800,000 in legal fees, or circumvent the patent? Command> CIRCUMVENT Your programmers say they can't circumvent the patent without removing a feature that will lose you 30% of your customer base. Do you want to circumvent it? Command> CIRCUMVENT You've lost 30% of your customers. The fax machine is going again. It's from MeanTech. They're claiming that your company's product "Acne Professional" violates their software patent "Means for Storing Documents on a CD ROM" and because they are a competitor, they do not want a royalty. They want you to remove the violating code or stop shipping the product. What do you wish to do: 1) Ship 400 floppy disks instead of one CD-ROM, 2) go to court, 3) stop shipping the product. COMMAND> GO TO COURT Legal fees are $600,000. Current funds are $400,000. You've gone broke! Do you want to play Patent Adventure again?> DEFINITELY NOT - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - While the above is fiction, it is far closer to the current situation than many in the software industry believe. Already patent #4,965,765 covers the use of color to indicate the level of nesting of a logical expression. And patent #4,941,125 covers use of a digital camera in conjunction with character recognition software to store and index documents on a CD ROM. The software patent system is clearly out of control and if not caught soon will change the face of the software industry forever. Two thousand new software patents are granted each year. They are being granted on software technologies as diverse and mundane as file servers and wordprocessors. It is already dangerous to create products containing data compression or public key encryption, and recently major inroads were made in the field of multimedia. Here are some more examples to help give you a feel for the scope of the problem: * A spreadsheet in which each cell has a "next cell" attribute defining the next cell to advance to after having entering data into the current cell. [#5,121,499]. * Any spreadsheet in which a single cell can contain multiple fields. [#5,247,611]. * A word processor that has a feature that allows you to specify that a portion of the text should be shaded - such as may be useful when revising a manual - by enclosing the relevant text within commands that turn shading on and off. [#4,924,411]. * Use of a host independent network byte ordering. [#4,956,809]. * A parallelizing compiler that estimates the execution time for each of a number of different parallelization conversions and selects the one that it thinks will be the fastest. [#5,151,991]. * Simulating the access times associated with a CD ROM by slowing down a hard disk. [#5,121,492]. These are just a few of hundreds of software patents that pose a critical threat to all software developers, large and small. Many more examples are contained in an appendix. The fact that these patents all cover trivial ideas is significant, but not the only reason for the difficulties. In this document, we argue that the nature of the software industry makes it an inappropriate subject for the granting of patents. 2. WHAT MAKES SOFTWARE DIFFERENT? ================================= The patent system has served us for more than 200 years. Over the years, it has adapted to all sorts of emerging technologies. So why is it failing now? The reason is that software isn't just something new. Software is something fundamentally different. Abstract and slippery, it doesn't conform to the ordinary constraints of the real world of objects. The nature of software has created not only a different kind of intellectual challenge, but a different kind of industry with its own particular economic structure. To this is being applied a 200 year old patent system. The following section describe the special properties of software that make the application of the patent system inappropriate. 2.1 Software is More Complicated -------------------------------- At the top of the list is the complexity of software. Because software is largely free from physical constraints, complexity has grown to the current state where a single large computer program cannot be completely understood by a single human being. As the highly acclaimed computer scientist E. W. Dijkstra has stated: In computer programming our basic building block, the instruction, takes less than a microsecond, but our program may require hours of computation time. I do not know of any other technology than programming that is invited to cover a grain ratio of 10^10 or more. The automatic computer, by virtue of its fantastic speed, was the first to provide an environment with enough `room' for highly hierarchical artifacts. And in this respect, the challenge of the programming task is without precedent. --- E. W. Dijkstra, A Discipline of Programming, 1976. This capacity for complexity is a great strength because it permits the creation of highly sophisticated products. But it also means that most products, simply by their very complexity, are dependent on a vast range of software technologies. In most other industries, a product will contain perhaps twenty parts. In the case of sophisticated consumer goods, such as video cameras, we could raise this to 1000 parts, but nevertheless, the constraints of the real world ensure that the complexity of the product cannot become too great. As a result the product will involve technologies covered by just a few patents. However, a typical computer program may contain thousands of inventions, many of which will correspond directly to features, any of which can be patented. For instance even when buying something as mundane as a word processor you might be able to choose between a word processor with built-in spelling checker, ability to format multi-column text, and an outline editor; a word processor with proportional fonts, an equation editor, and kanji capabilities; and a word processor that has style sheets, a page previewer, and document interchange facilities. And this is only the start. When you look closely you will find that each word processor actually incorporates thousands of different user visible features, while inside, there exist tens of thousands more features that are visible only to the programmer. The total number of features contained in something as simple as a word processor is enormous. Thus patents make the legal risks and expenses associated with developing even well understood software frightening. 2.2 Software is More Abstract ----------------------------- While software's complexity makes a typical computer program dependent on many different software technologies, software's abstraction makes it difficult to partition these technologies. In most industries patent searches are fairly easy to perform and provide fairly solid results. Patents are typically targeted at a particular product in a particular industry, and as such can be readily classified. For example, a typical patent title might be "Method for increasing grain throughput in a combine harvester by means of an air-forced hopper". In contrast, the nature of software means that much of it is very abstract. As a consequence its patents are often abstract even though their titles can sound specific. For example, patent #5,175,857, "System for Sorting Records Having Sorted Strings Each Having a Plurality of Linked Elements Each Element Storing Next Record Address" has a rather specific-sounding title, but is in fact a rather broad patent covering a well known algorithm called "Quicksort" when implemented using a linked list. Sorting is a fundamental building block of software, and its implementation using linked lists could be performed by any programmer working in any area of software development without the programmer even being conscious that he had accidentally "invented" anything; the "Quicksort" algorithm appears in one form or another in many undergraduate Computer Science textbooks. The complexity of software means that it is dependent on many technologies. The abstraction of software means that it is hard to catalogue those technologies, so there is a combinatorial explosion of potential patent coverage which removes any kind of certainty about what is patented and what is not. The result is that: * Software patents are expensive to search. * Software patents are difficult to reason about. * Software patents are expensive to fight over in court. In short, because of their broad coverage and complexity, software patents introduce far more uncertainty than do their non-software cousins. And uncertainty is bad for business. Uncertainty makes it difficult to decide the best strategy to pursue. Which patents might you be in violation of? Will the patent owners take any action? What royalties will they request? Will they sue? Will you be able to get the patent overturned? What damages might be awarded? These are not questions that can be incorporated into the smooth everyday running of a business. They are not questions comparable with concerns about tuning advertising or production inefficiencies. Rather these are issues that can kill your product stone dead and destroy your company. The penalties for patent infringement can be severe. The most famous case was Polaroid v. Kodak in which damages amounted to $900 million. With a further $500 million reportedly being spent by Kodak buying cameras back from consumers. More recently: ... a US District Court jury in California awarded $1.2 billion in damages based on the company's claim that Honeywell, which developed the first laser gyros in the 1960s, had subsequently and "willfully" appropriated a special process Litton patented in 1978 for coating the instruments' high-precision mirrors. --- Photonics Spectra, October 1993. in certain circumstances, the patent system has the power to award "triple damages" as a punitive measure. Thus, your liability may be far higher than your profits. 2.3 Software Technology Evolves Rapidly --------------------------------------- As if complexity and abstraction were not enough, the software industry is developing much faster than other industries --- even the computer hardware industry. Conventional industries typically produce a new generation of products every ten to twenty years. This has generally been reduced in recent decades thanks to "lean production" and "time-based competition", but even so the rate of product generational change in the software industry is far higher than that of other industries. The presence of patents that last for 17 years is therefore extremely frightening. Think back 17 years. Computer graphics didn't exist. Networking didn't exist. Desktop publishing didn't exist. Neither did PCs and Macintoshes. With processors doubling in speed every 2 years, this qualitative change is likely to continue. Compare this rate of progress to that of other industries such as the aircraft industry. In software seventeen years is a very long time. The existence of patents 17 years ago on what might have seemed non-obvious or esoteric technologies could be extremely damaging today. Likewise much of what may be considered non-obvious today may be seen as being fundamental and obvious tomorrow. One consequence of this rapid change is that research is galloping ahead of development. Many (most) industries could be considered to be "waiting" for new ideas. In most industries it costs more money to come up with suitable ideas than it does to bring them to market. In contrast, the software industry is completely overloaded with new ideas and innovations. In software, the costs are reversed: it's easy to come up with a new idea, but very difficult to turn it into a product. The idea behind most software patents can be coded in just 20 lines of code, but the program that must house the idea will usually be a thousand times larger. It is the writing of that program that takes all the time, not coming up with the idea. The result is that the software industry is awash with innovation and it will take many many years for technology to catch up, if ever. This rapid rate of evolution means that those who investing time creating and lodging patents are vastly outpacing those who are investing effort bringing such ideas to market. By the time an obvious, but immature, technology develops to the point where it can be incorporated into products, it has a dozen or more patents on it that render it commercially intractable. The consequence of all this is that it is now difficult or impossible to produce new products in the software industry without violating numerous patents. The uncertainty that this introduces into the product development process has to be seen to be believed. The sight of personnel of massive software companies scrambling to rework their software so as to circumvent patents on trivial ideas that were in use twenty years ago, but not documented because they were too obvious, is now a sad reality. 2.4 Software Doesn't Wear Out ----------------------------- A traditional argument for patents in general is that they encourage innovation in fields that have stagnated. Experience shows that most major industries go through a "sunrise" phase of rapid growth during which the first 80% of good ideas are discovered and incorporated into products. Finding these good ideas is usually easy in the early stages, and even some exponents of patents accept that patents may retard the industry during this first phase of chaotic growth. However, they argue that once an industry matures, good ideas are harder to find, and there is a tendency for mature industries to operate non-innovatively, in complacency, merely supplying their customers' need to replace products that have simply worn out. There may be scope for innovation, but it might require too high a capital investment in research to be tempting. In mature industries, it is argued, patents encourage innovation by rewarding capital investment in research with a monopoly in the market of the results of the research. However, this argument doesn't apply to software because software doesn't wear out. A computer program that is fully debugged will perform its function forever without requiring maintenance or modification. What this means in the market is that unlike socks that wear out, and breakfast cereal that is eaten, a particular software product can be sold to a particular customer at most once. If it is to be sold to that customer again, it must be enhanced with new features and functionality. The inevitable conclusion is that, even if the software industry approaches maturity, any software company that does not produce new and innovative products will simply run out of customers! Thus, the industry will remain innovative whether or not software patents exist. The need for a patent system to encourage innovation in mature industries doesn't apply to the software industry. A mature software industry is not going to gain any benefits from the patent system. And even the exponents of software patents admit that in the early stages of the industry, software patents could inflict considerable harm. 2.5 Software has Different Economics ------------------------------------ Previous sections have shown that software patents, at the very least, introduce considerable uncertainty and impose a significant business overhead. This would not matter so much if the software industry naturally provided a financial infrastructure that could support a patent system. Software is not the only complex product around: a jumbo jet probably incorporates over 100,000 different parts, many of which will be covered by patents. However, in all such industries the physicality of the parts, and the cost of their mass production, means that their cost dwarfs the legal overheads. A typical jumbo jet part (e.g. a small panel) might cost $100 to manufacture. A typical software component (e.g. a line of code) deployed in a mass market application costs approximately $0.00001 to manufacture. To see the effect of the patent system on the economics of the software industry, let us model the product cycle in three stages: research, development, and production. Various industries differ in the relative size of these costs: Research Development Production -------- ----------- ---------- Pharmaceuticals Medium High Low to Medium Cars Medium Medium Huge Aircraft Medium High High Software Tiny Huge Low Software has a very low research cost because development has not been able to keep up with research, and there are thousands of ideas just waiting to be exploited. Also a core idea often requires just a few lines of code to implement. Software has a high development cost because it takes a lot of human effort to write production-quality software. The industry average is about ten lines of code per programmer per day. An important aspect of the software development cost is that it mostly consists of people's time. This means that somebody with nothing but a computer and a lot of time on his hands can develop software even though they do not have a lot of capital. Thus, while development is expensive, it is still accessible to the individual - at least for small products. Depending on how much support is provided, software production costs are low. Each product consists of just a few floppy disks at $0.50 each and a manual which can be printed for less than $5. Typically software sells for in excess of $100. Now consider the impact of the patent system on these various industries. The cost of patents is proportional to the development cost because it is the amount of stuff that you actually put in your product that determines how many different royalties must be paid. In other industries, production costs dwarf development costs, and so the overhead of the patent system (on the development cost) is a minor component in the entire enterprise. However, in software the entire cost is development, and so the patent system represents an enormous cost to the industry. The car industry would scream if the government modified its production margins by just 1%. The software industry is being progressively slugged with a far greater impediment, but so far has not been organized enough to react to the threat coherently. The effect on LARGE COMPANIES is that they will have to incorporate the patent process into their software development process, set up bulky legal divisions, get into the business of cultivating defensive patent suites, and perpetually negotiate royalty payments and lawsuit settlements. For most big companies, such action will allow them to survive, for with enough broad and trivial patents in their suite they can threaten anyone who threatens them. But one day they will encounter a company THAT DOES NOT DEVELOP SOFTWARE and which is demanding royalties with the gloves off! Because such companies have a distinct advantage when negotiating royalty licenses, it is likely that corporate evolutionary selection pressures will make them more numerous in the future. Big companies will also experience difficulties with small companies that decide to use broad, but trivial, patents to defend market niches against legitimate competitors. A recent example is Stac Electronics, a small company making data compression software, who apparently bought a software patent from Ferranti in England so that they could prevent Microsoft from including a data compression feature "Doublespace" in MSDOS V6.0. This lawsuit was launched over a year ago, is still going, and has cost both sides huge amounts of money. The effect of all this on large companies is bad enough, but to a SMALL COMPANY it can be crippling. Large companies may already have a legal infrastructure, but most small companies must rely on the advice of external professionals who charge what seem high rates. Large companies may for a time be able to accept patent lawsuits in their stride, but small companies can be wiped out by a single one - fair or not. For many small companies, the prospect of being sued over a patent infringement EVEN IF THE CASE IS UNGROUNDED AND WOULD ULTIMATELY LOSE is so terrifying, that many companies choose to give all patents they know about a wide berth rather than risk the POSSIBILITY of any kind of patent challenge. Patents and patent laws are so complex that even an ungrounded lawsuit may take a year to resolve, simply because it may be hard to prove quickly that the other side does not have a case. Meanwhile hundreds of thousands of dollars in legal fees will be burnt, crippling the target software company. Thus, whereas most large pharmaceutical and aerospace companies can afford to conduct ongoing patent battles to resolve the scope of various patents, the small players of the software industry cannot. As a result, they steer well clear of patents, making the patents even more powerful than they were ever intended to be. In summary: the marginal cost to produce software is very small, while the value of that software in the market place may be large. Thus if sufficient volume is attained, profit margins may become very high. This is the main reason that the software industry is able to attract venture capital, and is a reflection of the value that the industry is delivering to society. Software patents, by introducing uncertainty and requiring the payment of unavoidable royalties, have the potential to destroy this leverage. 2.6 Software is Successful Because of Market-Driven Properties -------------------------------------------------------------- As we have seen, the software industry has a surplus of new ideas and technologies. What happens to them all? Well, of course, eventually they appear in products. However, because of the complexity of the products, the process by which this happens is more convoluted than in other industries. Typically, the technology is so complicated that bringing it to market as a simple, workable product is a greater challenge than performing the research to create the enabling technology. Because of this, today's successful software companies have become successful largely because they are market driven, rather than technology driven companies. These companies didn't build a piece of software because they thought it would be fun to build something no-one else had built before; rather they set out to build products that would meet the real needs of the market place. As Oracle Corporation clearly states: Whether a software program is a good one does not generally depend as much on the newness of a specific technique, but instead depends on the unique combination of known algorithms and methods. Patents should not protect such methods of innovation. --- Oracle Corporation Policy on Software Patents (See appendix). Borland didn't invent compilers. Microsoft didn't invent operating systems. Novell didn't invent networking. Sun didn't invent Unix. Apple didn't invent the graphical user interface. Oracle didn't invent the database. It turns out that nearly all successful software companies have concentrated on constructing better implementations of already existing technologies. The market rewarded these companies because they provided the market with what it wanted: products, not ideas. These companies didn't have a hoard of researchers working in obscure fields in the hope that one of them would discover something useful. In the software industry ideas are like air. The hard part is deciding which ideas to choose. The focus of these companies was on "doing it right" rather than on "doing it first" or "doing it differently". By allowing other companies to monopolize new technologies, patents strike at the very essence of the software industry's business philosophy. All of the above companies have relatively few software patents (see appendix). Furthermore the patents they do hold tend to have relatively narrow claims. For instance something like "enhanced file attribute caching mechanism" rather than "image storage and retrieval system". This is a result of their focus on developing the right product at the right time, rather than on trying to be the first to leap into every new technology. Opportunities for mainstream software developers to obtain important software patents will be somewhat limited. Most companies don't spend their time thinking what they can do that no one else has done before, but on which techniques to incorporate into products. Software patents will hurt successful companies because they will prevent them from doing what they do best: bringing technology to market, not because it is new, but because the time is right. In summary, it is easy to be the first to develop a new software technology (such as desktop video). The hard part is to transform that technology into a useful product that solves a real customer need. By rewarding research companies rather than development companies, software patents harm an industry whose value is largely a result of development. 2.7 Conclusions --------------- The software industry is significantly different from other industries subject to the patent system: * Software is More Complicated. * Software is More Abstract. * Software Technology Evolves Rapidly. * Software Doesn't Wear Out. * Software has Different Economics. * Software is Successful Because of Market-Driven Properties. These differences make application of the patent system at best ineffective, and at worst disastrous. The complex nature of software patents, their abstraction and broad scope, their excessive longevity, and their capacity for detrimental economic transformation, make software patents a significant problem for the software industry. 3. THE PROBLEM OF SOFTWARE PATENTS ================================== 3.1 Problems Developing Software -------------------------------- As a result of software patents many areas of software development are simply becoming out of bounds. A good example is the field of text data compression. There are now so many patents in this field that it is virtually impossible to create a data compression algorithm that does not infringe at least one of the patents. It is possible that such a patent-free algorithm exists, but it would take a team of patent attorney's weeks to establish this fact, and in the end, any of the relevant patent holders would be able to launch a cripplingly unfair lawsuit anyway. For the small company, even tiptoeing through the minefield is not good enough. The mines do not need to go off to be damaging. A similarly situation probably exists in most other relatively new fields of software development: neural networks, hypertext, public key encryption, multimedia, "groupware", and so on. This pattern is set to continue. Until they are eliminated software patents will likely jam up development in all future new areas of software technology. 3.2 Problems in the Courts -------------------------- I'm not familiar with any type of ligation that is any more costly than patent litigation. --- R. Duff Thompson, VP and General Counsel WordPerfect. Numerous software companies now find themselves facing threats or lawsuits relating to software patents. Indeed a large software company might face perhaps 5 or 10 such threats at any one time. As with most other legal matters there is a tendency to try and keep the matter quiet, but occasionally it does spill over into the public domain. Examples of some known software patent disputes are contained in an appendix. IBM has an extremely large software patent portfolio. Very little is known about how much different organizations have to pay to license it, but a large software company should probably be prepared to budget somewhere around $10 million per year. A small software company may need to budget anywhere up to 5% of gross revenues. In addition to the threat from large companies, there is also the risk of threats from "independent inventors". Take Roger E. Billings, founder and first graduate of his own "International Academy of Science": Novell Inc. is bracing for a battle that could be fiercer that anything the company has faced in the network software market. This battle will be in the courts, where both Novell and one of its largest customers will try to prove that a patent they are charged with infringing is not valid. In a suit filed in U.S. District Court, Northern California, last December, Billings claims Novell's NetWare network operating system infringes his patent when used for distributed computing. Billings applied for the patent in February 1982, nearly a year before NetWare hit the market; he won approval in 1987 after twice being rejected by the U.S. Patent Office. Billings wants Novell to fork over royalties representing 8% of total NetWare sales through the trial date, or about $220 million. --- Information Week, March 16, 1992. The case is still going. So far Billings has met with some success. Billings claims his patent #4,714,989 is for the concept of a "file server", however, the wording of the patent makes it difficult to know exactly what it covers. Irrespective of the merits of this case - Microsoft who invented what when - just the possibility of 17 year patents on enabling technologies such as this will have have a chilling effect on both the software and hardware industries. 3.3 Problems in the Patent Office --------------------------------- There are numerous problems in dealing with software patents within the patent office: * A lack of computing expertise. * An inability to properly search for prior art. * Difficulties in classifying software patents. * An excessive period of pendancy - typically 2 years. This time period is unacceptably slow in comparison to the rate at which software technology advances. Investment decisions are made in the presence of great uncertainty over whether a competitor holds a key patent covering the technology being considered. Other problems that are sometimes blamed on the patent office, but are not entirely their fault: * The application of very low criteria for judging whether a patent is non-obvious and novel. * A term of 17 years is totally inappropriate to software. These problems are more properly problems in legislation or alternatively in the way the courts have chosen to interpretation legislation. While problems in the patent office may be interesting to talk about, we feel that fundamentally this is only a secondary issue. The real problem with software patents has now become a legislative one. A legislative approach is now called for to resolve it. 3.4 Conclusions --------------- The software industry is significantly different from other industries. As a result software patents are causing numerous problems for the software industry: * Problems Developing Software. * Problems in the Courts. * Problems in the Patent Office. The problem of software patents is already having a direct effect on the software industry. But this is only the start. If software patents continue unchecked, the underlying structure of the software industry is going to be significantly changed. 4. THE EFFECT OF SOFTWARE PATENTS ================================= 4.1 Current Corporate Behavior ------------------------------ "Lawyers are running around our industry asking people if they'd like to patent something," said Ken Wasch, executive director of the Software Publishers Association in Washington, D.C. "It's gotten worse than ambulance chasing, and we don't think it's a positive development." --- Chicago Tribune, March 20, 1989. Most large software companies are by now well aware of the threat that software patents can pose to their business interests, and as a form of protection are attempting to build up "defensive" patent portfolios that can be cross-licensed with other large corporations. This provides protection against other large companies, but there seems little possibility for any sort of guaranteed protection against people like Roger Billings, who are probably not interested in signing a cross-licensing agreement. Against such people the future of your company is very much at the mercy of the courts, and the amount of damages they choose to award. For the small software company it obviously is not possible to build up any sort of serious defensive portfolio. You have to be prepared to pay whatever license fee the big company determines - or find a business other than developing software. Likewise you need to stay prepared for the possibility of a bloody fight against a small competitor. One anonymous vice president of a major software company crystalized his corporation's dilemma and consequent decision to register software patents, despite widespread unease with them within the company, by saying: "How does a just man live in an unjust world?" It is a common nostrum that patents "protect" small companies from competition from bigger ones. As mentioned above it usually doesn't work that way. Normally, the largest companies own most of the patents, and use them to force other companies, both large and small, to cross-license with them. IBM explains how this works: "You get value from patents in two ways," says Roger Smith, IBM Assistant General Counsel, intellectual property law. "Through fees, and through licensing negotiations that give IBM access to other patents. "The IBM patent portfolio gains us the freedom to do what we need to do through cross-licensing--it gives us access to the inventions of others that are the key to rapid innovation. Access is far more valuable to IBM than the fees it receives from its 9,000 active patents. There's no direct calculation of this value, but it's many times larger than the fee income, perhaps an order of magnitude larger." --- "Think" magazine, #5, 1990. Thus, if a small company tries to use a patent to "protect" itself against competition from IBM, IBM can usually find patents in its collection which the small company is infringing, and thus obtain a cross-license. Besides which, if you are a small company, do you really want to try taking IBM to court? This need to take out "defensive" patents is likely to be detrimental to the overall profitability of the software industry. As shown in an appendix there is a strong negative correlation between a company's propensity to patent and its ability to bring to market innovative software; software that proves itself capable of filling a real customer need. 4.2 Patents as a Selection Effect in Corporate Evolution -------------------------------------------------------- Strong parallels can be drawn between the functioning of the market and the notion of survival of the fittest from evolution theory. The successful software company of today has succeeded because of its ability to develop and bring innovative products to market. However software patents will make these traits far less desirable. The desirable traits will be those embodied in IBM, Hitachi, Xerox, and AT&T. An ability to produce software inventions without producing software products. These traits will be rewarded. Some companies may be able to adopt to these changes. Those that can't may become extinct. To survive software companies will need to somewhat de-emphasize developing new products to solve real customer needs and emphasize activities more likely to result in obtaining broad patents in newly emerging fields. Companies that choose to develop and market significant products should expect and make contingencies for the suits alleging patent infringement. Having a large patent portfolio will prevent threats from competitors, but will only provide a limited defense against those who produce little. The resulting changes in the make up of the software industry won't happen overnight, but over a period of perhaps ten years they will happen. A large company that chooses to continue to concentrate on producing only software will be able to keep doing so for quite a while. Eventually however it will find most future areas of technology restricted. Then, either as the result of a single calamitous award for damages, or the cumulative costs of the patent system, it will find it has become uncompetitive. 4.3 The Future -------------- A vision of patents entrenched in the software industry is a vision of stagnation. A vision of IBM once again calling the shots. A vision of companies like Xerox and AT&T who have proven incapable of bringing innovative products to market stealing profits from those companies can. Such a vision is particularly alarming to the successful software company of today, the company that is skilled in building and bring products to market. Software patents can be viewed as presenting an extremely profitable opportunity. Unfortunately these profits are only likely to accrue to those outside the software industry. Those that have no real products to build. Companies that currently build products are going to have a much harder time. First, they can't aggressively seek royalties on their patents for fear of an equally aggressive counter suit on some other patent. Second, building products that don't infringe patents is likely to prove an extremely expensive business. Patented techniques have to be identified, and either licensed or worked around. Not taking these measures may save development time, but will expose the company to significant risk. Those that have few or no products to sell are likely to pose a serious threat to those that do. An example of a successful software company of the future might be RSA Data Securities. Instead of building and marketing a real product it purchased the patent rights to a technology. It now collects royalties from companies capable of integrating and marketing products containing this technology. Being property, patents can be bought and sold. Some companies specialize in acquiring and litigating patents. Such companies present another example of the software companies of the future. Lastly we might see the software equivalent of Gilbert Hyatt. He files very broad patents relating to some emerging technology, contests the claims with the patent office for as long as possible, and when the patent finally issues attempt to collect sizable royalties for the next 17 years. See for example patent #4,942,516 originally filed in 1970, finally issued in 1990, and titled "Single chip integrated circuit computer architecture": North American Philips Corporation ... today announced the signing of a license agreement for two portfolios of Hyatt's patents. The Computer-Related Patent Portfolio covers technologies including: fundamental single-chip microprocessor architecture; dynamic random access (DRAM) chip memory refresh techniques; intelligent keyboards for computers; techniques for creating random access memory (RAM) pages or blocks (for memory management purposes); computer-to-computer communication and serial communication, such as in networks or automobiles; and, control of machines by micro computers. In the case of the latter, machines include disk drives, printer control in PCs; tape control in camcorders and VCRs; and control of automobiles. The LCD-Related Patent Portfolio covers technology including: LCD television displays; projection LCDs; shades of intensity and color for LCDs; high intensity illumination and thermal control for projection LCDs; and other related inventions. --- PR Newswire, November 6, 1991. Perhaps disturbingly, such people often tend to be viewed in the media and by juries, as being in some sense unsung heroes who have had their inventions misappropriated by "evil corporations". (Ford was recently ordered to pay $5 million dollars in damages to Robert Kearns for the patent he has on the intermittent windshield wiper.) 4.4 Conclusions --------------- The current problems in the software industry caused by software patents are really just a symptom of what, if left unstopped, is going to constitute a far more fundamental change. Resources are already being diverted away from developing software and towards building up defensive patent portfolios. However the overall influence of this in changing the software industry will be relatively minor. The major influence on the software industry will result from the competitive disadvantage suffered by those firms that choose to build software products to fulfill market needs, relative to those firms that choose to de-emphasize direct product development in favor of attempting to monopolize emerging software technologies. A vision of the likes of IBM, Xerox, and AT&T being in control of the software industry is particularly disturbing to those companies that are able to successfully build software products to meet customer needs. In addition, the industry is likely to be haunted by firms and individuals that produce little, but demand much. On the flip side, of course, there are going to be benefits for those who register particular software patents. But given the almost non-existent amount of research required to develop a patentable software idea, ownership of a software patent is more akin to winning a minor (or major!) lottery than a reward for years of research. Directing money towards these people will only be bad for the industry. 5. OPTIONS FOR THE SOFTWARE INDUSTRY ==================================== 5.1 Options ----------- With the Patent Office hearings into software patents this month, the software industry is at the crossroads. What is the feeling out there? Opinions appear to vary widely. It is probably fair to say that most programmers are strongly against software patents and would like the software patent system dismantled. Views within the legal profession are mixed. Some lawyers would like to see the software patent system dismantled. Others are strongly in favor of software patents. Most seem to feel that some sort of system of protection of ideas is desirable, but that the current patent system has been misapplied and needs to be changed. The feeling within the top management of software companies is unstable. Unlike programmers who have to avoid patented constructs on a day-to-day basis, and rapidly become opposed to them, management is exposed to the issue mainly when they are on the sending or receiving end of a software patent lawsuit. As such, one tends to find CEOs who are strongly against software patents, and those who are strongly for them. The remainder usually have not been exposed to the issue much and tend to default to the conservative line representative of the general population that "more intellectual property laws can't be a bad thing". However, as we have shown, this is tragically false. So what are the options? * MAKE NO CHANGES: This document shows why this would be disastrous. * ABOLISH SOFTWARE PATENTS COMPLETELY: This is the option we advocate. The industry thrived and prospered without software patents. There is simply no real need for them. * MODIFY THE PATENT SYSTEM: Proposed modifications include: * Tighten up the requirements for awarding software patents. * Reduce the duration of software patents from 17 years to, say, 5 years. * Significantly reduce the period of pendancy. * Abolish retrospective damages. Only liable for damages AFTER you have been notified by a patent holder. * Make changes in the law related to the process of "legal discovery" to make the process less expensive. * Somehow find a simpler way to determine if a piece of code is covered by a patent. * Improve patent indexing so that software patents can be more easily searched. * ABOLISH SOFTWARE PATENTS COMPLETELY AND SET UP A NEW SYSTEM OF PATENTS SPECIFICALLY TAILORED FOR SOFTWARE: This idea has a lot going for it. Some software ideas really do require a lot of research to arrive and and some kind of system to protect them could be a good thing. But the current system is completely inappropriate. * HAVE COPYRIGHTS AND PATENTS BE MUTUALLY EXCLUSIVE: This would allow software to be copyrighted or patented, but not both at the same time. It would be permissible in a copyrighted work to freely make use of a patented invention only if no attempt was made to patent any of the improvements to that invention, or to patent any other inventions that may be contained in that product. This would provide the software industry the freedom to choose the system best suited to the development of software. Despite the merits of some of these proposals, WE MUST ADVOCATE THAT THE CURRENT SOFTWARE PATENT SYSTEM BE DISMANTLED. Here's why: * While in theory is may be possible to modify the current software patent system to be fairer, it is unlikely that this will be possible in practice. The Patent Office is a 200 year old institution with its own culture and history. Its behavior so far has been to apply the general patent system to software with NO compensation for the special nature of software and the software industry. (This has been evident particularly in the low threshold of acceptable inventiveness, which while acceptable in other industries, is a disaster for the software industry). Whether or not an acceptable patent system can be constructed for software, it remains true that the current patent system IS SO TOTALLY WRONG when applied to software, that it is hard to imagine that it could evolve into something acceptable. A total break seems the only way to prevent the Patent Office from doing what comes naturally. * It seems that the Patent Office is holding hearings into software patents because of the ongoing heat surrounding them, and because of the recent Compton Multimedia Patent. Despite this action, it's likely that the office doesn't really want to change and won't unless it receives a clear signal from the industry. Muddling about with vague proposals for alternative systems may give it the excuse it needs to basically continue as it has. * Of all the thousands of software patents that we have seen, the number that seem truly deserving of patent protection could be counted on one hand. From the simple perspective of numbers, the most direct path to the best outcome is abolition. A secondary issue is what to do about existing and pending software patents. Patents are considered to be property, and property is very strongly protected in Western law and so it is likely to be very difficult to the abolish software patents already issued. And clearly, if people have based their lives on such patents, they should not be destroyed. However, one concession could be made, and that is to reduce the duration of these patents to, say, five years rather than 17 years so as to reflect the pace of the software industry. This would be a fair outcome for everyone. In the long run, past patents are a minor consideration, as the growth rate in software patent lodgements means that the number of existing patents will eventually be dwarfed by the number filed in the future - even when the 17-year expiry rule is taken into account. The important thing is to stop any more software patents from being issued. 5.2 Your position ----------------- So how does all this affect you? Well, if your company is a SMALL PLAYER in the software industry, you will find that it will eventually become impossible to produce software without paying attention to the patent landscape. This means conducting patent searches and hiring expensive patent attorneys to evaluate them. If, after this process, you find that you have breached some patents, you will have to become involved in licensing them, circumventing them, or finding another product to make. Even if you do not find any threatening patents, you will still live in fear of receiving a letter from a random company asserting that you have violated their patent, for it is impossible to find out what patents are currently in the process of being filed. All in all, the introduction of patents will radically change the economics of your software production and harm your software development process. If you are a LARGE PLAYER in the computer industry you will find that you will eventually be forced to either play the patent game or go out of business. Even if patents currently form no part of your business strategy, you will have to develop a software patent pool so that you can defend yourself against other companies. While it is conceivable that some small players may be able to duck and weave through the patent minefield, it is inconceivable that a large corporation of the future could launch a major software product without violating at least five patents owned by other organizations. So you must ask yourself: "Would I rather have my corporation spending time constructing a defensive patent pool, or would I rather have it expend that effort creating new market-driven products and services to create wealth? Would I rather spend my time negotiating royalty deals with patent holders or with distributors? Consider the following equation which every software manager now faces. Software patents are harmful if: profits gained profits lost royalties by impeding royalties by being legal and other you + competitors < you + impeded by + administrative receive with patents pay competitors' costs patents For companies whose focus is on building and bringing innovative software products to market the first and second terms will be relatively small. The third term will be quite large due to the likes of IBM. It also probably has a large positive uncertainty because some individuals with patents with no product of their own requiring cross-licensing may negotiate crippling royalty contracts. The fourth term is not yet large, but as more and more fundamental technologies are patented it will rise rapidly. Some areas of technology, such as data compression, are already intractable. The fifth term is relatively small for large companies, but a crippling overhead for small developers whose entire capital outlay may be less than $1 million. This last term entirely constitutes destroyed wealth. Is this what you want? 6. ACTION ========= SOFTWARE IS DIFFERENT. SOFTWARE PATENTS ARE CAUSING PROBLEMS. SOFTWARE PATENTS WILL SIGNIFICANTLY AFFECT THE SOFTWARE INDUSTRY. 6.1 A Rare Opportunity ---------------------- The difficulties with software patents and the continuing opposition to them, coupled with the widespread condemnation of the Compton multimedia patent, has led the Patent Office to organize public hearings so as to get a perspective on the problem. These hearings represent a rare opportunity for the software community to make its voice heard. Perhaps even more strongly, this is an opportunity that must not be missed. This is the first time that the Patent Office has instituted a public hearing on the issue of software patents and the message it receives will determine the background for any future inquiries and hearings. The patent office has never been as ready to listen to the industry's opinion on software patents as it is now. However, a strong message will have to be delivered to have any effect. Just as farmers farm and bakers bake, the Patent Office issue patents, and it seems clear that they are likely to continue doing what comes naturally unless they receive a strong message. If the result of the hearings is inconclusive, software patents will continue to be issued, and the industry will gradually reorganize itself with the companies involved in patents becoming stronger, and those opposed to patents becoming weaker. Once this happens, it will be impossible to change the system and the industry will become stuck in the software patent tarpit. Software development will become like a trip through Jurassic Park: expensive and dangerous. Something must be done soon if dinosaurs such as IBM are not to rule the earth again. 6.2 What You Can Do ------------------- The hearing is to be held on January 26-27, 1994, at the San Jose Convention Center, 408 Almaden Avenue, San Jose, California. This is in less than two week's time, so action is required VERY SOON. If you are an influential member of a large or influential software corporation you can change the future of the software industry by raising this issue within the top management of your company and organizing for a company spokesperson to attend the hearings. Obviously if you want to carefully evaluate the issue, then you have some homework to do. However, if, like us, you are by now convinced that software patents are detrimental to your company and to the software industry in general, then all you need to do is turn up and say: I represent X Corporation, a $Y billion/year software company employing Z people. X opposes the granting of patents on software. We believe that this alone will have a profound effect on the Patent Office and the legislative agenda. But action must be taken IMMEDIATELY. If you want a representative of your company to speak at the hearings, you must try and notify the Patent Office by Friday January 21st. Alternatively you may choose to send electronic mail directly to the patent office using the following Internet address: comments-software@uspto.gov The deadline for doing this is March 15, 1994. We urge you to grasp this unique opportunity to preserve the software industry. APPENDIX A: WHAT IS A PATENT? ============================= A patent is a monopoly right created by the government to a new invention. It provides the holder the legal right to prevent others from making, using, or selling the invention, or any product containing the invention for a period of 17 years. The holder has to go to court to enforce this right. Independent re-invention does not constitute a defense against the charge of patent infringement. Patent holders typically grant third parties license to make use of the invention in return for an agreed license fee or royalty. Licensing a patent does not automatically permit the licensee to produce the named invention. Frequently an invention will be covered by several patents and it is necessary to license each one. A patent is obtainable by a third party for an improvement to an already patented invention just as readily as on anything else. The patent office interprets the notion of what constitutes an invention very broadly. Important inventions and trivial applications are equally patentable. There is a requirement that prohibits the obtaining of a patent if: ... the subject matter taken as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. --- 35 USC 103. However this means exactly what it says: "non-obvious". It does not mean the invention has to be in some sense above the norm, or in any way clever. The patent office takes the attitude that if something has never been built before, then presumably, the invention is non-obvious. This causes significant problems in the software industry due to the rapid rate of technological change. Brian Kahin, at Harvard's Kennedy School of Government, states that the nature of what is considered to be an invention is "often at a level of abstraction that is shocking to the uninitiated." This point is central to any understanding of the workings and potential impact of the patent system on the software industry. There are at least three important vantage points from which the patent system may be considered: * Law: as a matter of jurisprudence. * Economics: as a public policy issue. * Business: as a matter of financial self interest. This document focuses on the direct business impact of patents, but first here is a brief discussion of the other two. Most people who deal with the patent system have some sort of legal background. It is not surprising then that the legal technicalities of the patent system gain the most study. For our purposes however the precise legal details of the patent system are only of marginal interest. Suffice to say patent legislation has a long history dating back to the English Statute of Monopolies of 1623. The U.S. constitution granted Congress the right to issue patents subject to certain constraints. The economic rationale for the patent system is that on account of the appropriable nature of inventions it is necessary to grant patents so as to provide an incentive to invent. Economists tend to be slightly uneasy about the patent system on account of its ability to stifle competition. Taking a business point of view all that really matters about the patent system is the bottom line. Will the existence of fewer patents increase or decrease your profit margins? This is a difficult question to answer, but it is likely that the patent system is detrimental to much of the software industry. The reasons for this are discussed in much more detail elsewhere. While a few earlier examples can be found, essentially beginning in the early 1980's and in response to supreme court decisions, the patent office started to grant patents on inventions that included software. Different companies realized this at different times and started submitting applications accordingly. It is fair to say that by 1990 most in the computing industry were well aware of this policy and had applications pending. Since it typically takes 2-3 years for an application to be approved, it is only relatively recently that the full effects of this policy are becoming apparent. Roughly, 2,000 software patents are issued each year. The total number of software patents in existence is probably around 10,000. As a technical point the patent office maintains that algorithms per se are not patentable. This is indeed the case, although for all practical purposes algorithms may as well be. An algorithm in the abstract is not considered patentable. However an algorithm when used to solve some particular problem is considered patentable. Thus the "RSA algorithm" is not patentable, however "use of the RSA algorithm to encryption data" is patentable. If it turned out that you suddenly decided to use the RSA algorithm to, say, produce a string of random number, you would not be infringing the RSA patent. For all practical purposes algorithms are patentable. APPENDIX B: EXAMPLES OF SOFTWARE PATENTS ======================================== This appendix contains examples of currently existing software patents. We have chosen software patents from a range of fields to indicate their diversity and scope. Perhaps the most alarming aspect of this list is that these examples do not represent the worst cases; there are HUNDREDS more patents that are as trivial and as broad in scope as the ones listed here. For all practical purposes, no invention is too trivial to be patented. B.1 Word Processors ------------------- * Any word processor with a separate mode that the user selects when they wish to type in a mathematical formula. [#5,122,953]. * Any word processor screen layout that simultaneously displays the global page heading/footing and the contents of the current page, and permits you to edit either. [#4,984,162]. * Any word processor that has a feature that allows you to specify that a portion of the text should be shaded, such as may be useful when revising a manual, by enclosing the relevant text with command codes that turn shading on and off. [#4,924,411]. * Any word processor which marks and makes correction to a document using two additional different colors. [#5,021,972]. * A word processor that monitors the sequence of keys you type and tries to teach you about new features. If it notices you doing a particular sequence several times, will display information about a simpler command sequence that may help you do what you want. [#4,947,346]. * Use of different colors to distinguish the nesting level of nested expressions in computer programs. [#4,965,765]. B.2 Spreadsheets ---------------- * Any spreadsheet that can automatically collapses rows that are hierarchically subordinate to another row. [#5,255,356]. * Any spreadsheet in which a single cell can contain multiple fields. [#5,247,611]. * Any spreadsheet in which each cell has a "next cell" attribute defining the next cell to advance to after having entering data into the current cell. [#5,121,499]. B.3 Operating Systems --------------------- * A file server that merges together multiple pending writes that require updating the same meta-data. [#5,218,695]. * Remembering file access behavior and using it to control the amount of read-ahead the next time the file is opened. [#5,257,370]. * Altering the working set of a process based upon its paging behavior and how its paging behavior changes in response to changes in its working set size. [#5,247,687]. * Creating variable size disk partitions comprising tracks residing on multiple disks. [#5,129,088]. B.4 Compilers ------------- * Any parallelizing compiler that estimates the execution time for each of a number of different parallelization conversions and selects the one that it thinks will be the fastest. [#5,151,991]. * Using condition code graph analysis in a CPU simulator to determine whether it is necessary to simulate the generation of the condition codes. [#4,951,195]. * Caching the most recent branch target code for simulating a procedure return instruction. [#5,167,023]. B.5 Miscellaneous ----------------- * Any document storage system that has a digital camera to scan in documents documents, stores the documents on an optical disk, and uses optical character recognition to construct an index. [#4,941,125]. * Generation of random numbers by feeding the output of one random generator into the input of another random number generator. [#5,251,165]. * The computer graphics representation of a surface using and array of dots, rather than the more traditional wire frame model. [#5,257,347]. * Quicksort implemented using a linked list of pointers to the objects to be sorted. [#5,175,857]. * A calendar tool that includes a bar graph of the duration of each meeting and a composite bar graph of all meetings. [#5,247,438]. * Simulating the access times associated with a CD ROM by slowing down a hard disk. [#5,121,492]. APPENDIX C: EXAMPLES OF SOFTWARE PATENT LAWSUITS ================================================ Most companies that are threatened over patent infringement probably prefer to keep the matter quiet. Therefore the true impact of patents on the software industry is largely unknown. The following examples probably heavily understate the true effect. The biggest news at Comdex this year was the announcement of the Compton's patent. Compton's, a spin off of Encyclopedia Britannica, claim their patent covers multi-media searching. Their announcement received a very hostile response from the press. Compton's had been threatening everyone with a 3% license fee before the Patent Office spontaneously decided to re-examine it. This decision must have been a result of all the media attention it was receiving. Other than that, there was nothing particularly unusual about this patent. Hundreds more equally broad software patents currently lie dormant in the Patent Office. Lotus, Microsoft, and Aston-Tate have all been sued by Refac, a litigation company, for a patent it acquired, #4,398,249, that contains a very broad claim covering "natural order recalculation" used in spreadsheets. Fortunately the case got thrown out on a legal technicality. This patent in question was filed in 1970, but wasn't issued by the Patent Office until 1983. Paul Heckel has threatened Apple and IBM over patent #4,736,308 which he alleges is infringed by HyperCard and ToolBook respectively. Cadtrak has collected large sums of money and successfully defended patent #4,197,590 on the concept of an "xor cursor". XyQuest was forced to remove features from the latest release of the XyWrite word processor after being threatened by Productivity Software. Attempts to license the features proved unsuccessful as Productivity Software increased the fees every time XyQuest attempted to reach an agreement. Mark Williams Company has harassed various companies over patent #4,956,809 on the use of a host independent network byte ordering. AT&T is finding itself free to start exercising its muscle. It first threatened members of the MIT X consortium alleging that the X11 windowing system was in violation of patent #4,555,775 which it holds on the concept of backing store. AT&T is now suing MCI for alleged software patent infringement. Novell is being sued for $220 million dollars by Roger Billings for infringing his patent #4,714,989 on the concept of a file server. The fields of cryptography and data compression are essentially off limits to programmers on account of patents. Numerous companies have been forced to obtain licenses from RSA Data Securities who purchased key patents from Stanford and MIT to create an outright monopoly on public key cryptography. Unisys has threatened people over the data compression algorithm also used in the Unix "compress" program. Microsoft is being sued by Stac Electronics over Microsoft's incorporation of transparent data compression in MSDOS 6.0. The main patent involved is #5,049,881. APPENDIX D: NEGATIVE CORRELATION OF INNOVATION AND SOFTWARE PATENTS =================================================================== In what may be judged as either ironic or deeply disturbing, most software patents are held by companies that history has proven to be totally incapable of delivering innovative software products to market: Interestingly, approximately 12% of all software patents are owned by IBM (roughly 1,000), and no other companies come close (the importance of this being that Microsoft just paid $20,000,000 to license IBM's software patents). Other American companies with many software patents include ATT and the Bell Laboratories, Xerox and DEC, while Hitachi has the most patents by a Japanese company (roughly 450), along with Toshiba, Fujitsu, Fanuc, Sharp and Mitsubishi. --- Gregory Aharonian, Communications of the ACM, January 1993. The following constitute our best estimates of the number of software patents granted to various companies between 1990 and 1992 (the results appear similar to the above, but they are not identical): Software patents granted 1990 - 1992 ------------------------------------ IBM 500 Fujitsu 50 Lotus 7 Hitachi 400 HP 50 Novell 1 AT&T/Bell 150 Sun 50 Borland 0 DEC 150 Unisys 30 NeXT 0 Toshiba 150 Apple 20 Oracle 0 Sharp 100 Texas Inst. 20 Pyramid 0 Xerox 100 Microsoft 13 SGI 0 Canon 70 Intel 10 Sybase 0 Motorola 70 Matsushita 9 Symantec 0 Wang 60 Adobe 8 WordPerfect 0 Total software patents granted (1990 - 1992): 5000 Entities with fewer than 5 s/w patents: 1000 Entities with 5 or more s/w patents: 60 Because of the way patents are classified it is very difficult to gather accurate data on how many software patents exist. Differences of opinion as to precisely what constitutes a software patent also muddy things. The above data is indicative of the overall situation, but the individual figures may have errors of anywhere up to 50%. The above table tends to suggest a significantly negative correlation between the number of software patents granted to a company and its ability to bring innovative software products to market. Companies that form the backbone of the software industry: Microsoft, Adobe, Lotus, Novell, Borland, Oracle, Sybase, have relatively few software patents, while companies that hardly market any software: Hitachi, AT&T, Toshiba, Sharp, and Xerox, have many. As an example of this, consider Sun's Network File System, NFS, which Sun designed and developed, which for its time was a highly innovative product, and which went on to become the standard protocol throughout the Unix industry. Although far from conclusive, a search for the string "NFS" on a small database of some 2000 patent abstracts which I maintain turned up five patents assigned to IBM, one to Auspex, and none to Sun. This is despite the fact that Sun developed NFS, and the other two companies have engaged in no more than the most trivial of tinkering around the edges. When asked to name some companies responsible for the production of innovative software, Hitachi isn't one of the companies most people immediately think of. IBM has a very strong software patent portfolio. It is over-sized even in proportion to the size of IBM itself. This is a result of IBM's patenting every single trivial idea every employee ever comes up with, rather than having any great propensity to be truly innovative. IBM has never been considered synonymous with innovative software. IBM even has a patent, #5,247,661, on a software application to permit employees to automatically document ideas for later patenting. Fortunately, when IBM was being investigated for anti-trust some time ago it issued a consent degree permitting the automatic licensing of its patent portfolio. As a result any one patent can be licensed for 1% of royalties, and the entire suite for 5%. In this regard the downsizing of IBM that is currently occurring is cause for considerable concern. If IBM ever feels free to start exercising its powers, its patent portfolio could pose a considerable threat to the entire computer industry. It has already recently increased the fee to automatically license its entire suite from 3% to 5%. The possibility of IBM selling off various divisions or deciding to break up is also cause for concern. A worst case scenario as far as the rest of the computer industry is concerned would involve some or all of IBM's patents winding up in a company that produces few or no real products. None of the hardware or software companies that collectively constituted the "microcomputer revolution" hold significant numbers of software patents. Companies such as Microsoft, Borland, Novell, Adobe, Lotus, NeXT, Intel, Apple, Sun, and SGI all have relatively weak software patent portfolios. These are the companies that have created wealth in the computer industry over the last ten years by developing of new and innovative products. They are very much responsible for turning the industry into the vibrant place it is today. Without these companies, the software industry would be virtually non-existent. Between 1990 and 1992, software patents were granted to roughly 1,000 different people and organizations. This tends to confirm the theory that entities that individually play only a very small role in the software industry will be able to obtain patents on various software techniques. APPENDIX E: OPPOSITION TO SOFTWARE PATENTS ========================================== Articles discussing the threat posed by software patents have appeared in numerous newspapers including the New York Times, Wall Street Journal, and Washington Post. Pamela Samuelson, Professor at the University of Pittsburgh School of Law, and Brian Kahin, Adjunct Research Fellow at Harvard's Kennedy School of Government, are both speaking eloquently against the current patent office policy of patenting software. Surveys by organizations such as the Association for Computing Machinery show a strong opposition to software patents amongst its members. Many academic computer scientists are willing to speak out against software patents. Wordperfect Corporation has expressed considerable concern regarding software patents. They currently receive an average of one letter a month alleging patent infringement and threatening legal action. This is probably not atypical for a large software company. Mitch Kapor, the original founder of Lotus, recently attested before Congress as to the danger software patents pose (see separate appendix). Phillipe Kahn, president of Borland International, is known to share similar concerns. "I'm kind of scared about the climate for the next 10 years" says Dan Bricklin, co-inventor of VisiCalc, the world's first electronic spreadsheet. Jim Warren, founder of InfoWorld, and a member of Autodesk's board of directors, is likewise equally strongly opposed to the patenting of software related inventions. Oracle Corporation recently issued a detailed statement opposing the granting of patents on software (see separate appendix). APPENDIX F: ORACLE CORPORATION'S POLICY ON SOFTWARE PATENTS =========================================================== The following statement on software patents has been released by Oracle Corporation: Oracle Corporation opposes the patentability of software. The Company believes that existing copyright law and available trade secret protections, as opposed to patent law, are better suited to protecting computer software developments. Patent law provides to inventors an exclusive right to new technology in return for publication of the technology. This is not appropriate for industries such as software development in which innovations occur rapidly, can be made without a substantial capital investment, and tend to be creative combinations of previously-known techniques. Even if patent law were appropriate for protection of software, due to the large volume of recently-granted software patents and the rising number of new applications, the current patent process would continue to be troublesome for the software industry. Software patent examinations are hindered by the limited capability of searching prior art, by the turnover rate among examiners in the Patent and Trademark Office, and by the confusion surrounding novelty and innovation in the software arena. The problem is exacerbated by varying international patent laws, which both raise the cost and confuse the issue of patent protection. Unfortunately, as a defensive strategy, Oracle has been forced to protect itself by selectively applying for patents which will present the best opportunities for cross-licensing between Oracle and other companies who may allege patent infringement. COMPUTER SOFTWARE POLICY ISSUES The policy rationale for patent protection in many industries is understandable. In exchange for making an invention available to the public, inventors are rewarded with a seventeen-year monopoly giving them exclusive right to the new technology. In such cases, this opportunity to monopolize the commercial application of the invention is justified as an appropriate reward given the capital resources dedicated by the inventor to the invention, including time and money spent in innovation, production, distribution, etc. This policy, however, does not fit well with the software industry. Unlike many manufacturing-intensive industries, the development of software requires a minimum of capital investment. Producing and distributing a product is simpler, faster, and less expensive in the software industry than in manufacturing sectors. New developments influential to the software industry frequently emanate from individuals and small companies that lack substantial resources. Software varies from manufacturing in another key aspect. The engineering and mechanical inventions for which patent protection was devised are often characterized by large "building block" inventions that can revolutionize a given mechanical process. Software, especially a complex program, seldom includes substantial leaps in technology, but rather consists of adept combinations of many ideas. Whether a software program is a good one does not generally depend as much on the newness of a specific technique, but instead depends on the unique combination of known algorithms and methods. Patents should not protect such methods of innovation. The U.S. software industry has evolved to a multi-billion dollar industry that leads the world in productivity, and accounts for substantial portion of U.S. GNP. The software industry has advanced the efficiency of other industries through the proliferation of computing and computer-controlled processes. All of these gains have come prior to the application of the patent process to software, and consequently without patent protection for software. There is no justification for a policy that would not only drain capital resources (which are better spent on software development) into patent applications and other legal fees, and also actually serve to reduce innovation by limiting the availability of previously-developed techniques. In sixteen years, Oracle Corporation has grown from a start-up company with a handful of employees to the world's third-largest independent software producer employing 8,000 people. Oracle filed its first patent application in November 1991, not because it felt that its software was suddenly worthy of patent protection; it filed that application because of concerns that other inventors, afforded patent protection by a flawed patent system, might find themselves in a position to seriously weaken the Company's competitive edge by alleging patent infringement. Even if Oracle had developed a certain invention first and could produce the appropriate prior art to prove its case, thousands of dollars in attorneys fees and other expenses would be spent in defense of its rightfully-owned technology. Oracle consequently believes that it must have a patent portfolio with which to respond to potential aggressors, so as to settle with them by cross-licensing to avoid litigation. Oracle is forced to channel a significant portion of its financial resources into patent protection of its assets, rather than using those resources in further innovating and expanding its computer software products. Copyright protection for computer software is sufficient to preserve the rights of software developers, who rely on the unique combination of algorithms and techniques to produce successful software programs. Copyright law, including relief from those who copy or distribute copyrighted works without permission, in combination with careful handling taken to preserve trade secrets, has afforded adequate protection to software developers against the losses they may encounter from the wrongful use of their software. Compared to adequate copyright and trade secret protections, patent protection is excessively broad and enormously expensive. CHANGING THE PATENT SYSTEM Oracle has recommended that patent protection not be provided for computer software or computer software algorithms, for the reasons described above. If software continues to be protected by patent law, however, we recommend the changes described in the following paragraphs. These recommendations in no way endorse the use of patents for protecting software, but rather serve to assuage the existing problems if patents must ultimately affect software development. Patent law should be consistent throughout the world and, if it is to be applicable to software, should extend for much shorter periods of protection than exist now, unified prior art searching capabilities, equal standards of novelty, the elimination of patent rules that allow "patent flooding," and identical standards for prior use restrictions (bar dates). The evolution of software moves very quickly. The term of software protection should be cut back accordingly, from the current 17 years from grant date to three years from application date (the application period must be drastically reduced). A balance of fifty years protection for direct copying of code would continue to be provided by copyright law. If the patent system is to remain an entrenched part of the software industry, then the following changes need to be made: * The prior art capabilities of PTO records must be vastly improved to confirm effectively the novelty and non-obviousness of software patent that is the subject of applications. New classifications, as well as an effort to record the current state of prior art would be necessary. * Because of the unusual speed with which software innovations are incorporated into products, the PTO's patent review process must be made much more efficient so that it takes no more than six months from application to registration. In the software industry, if a patent application takes two years to process, the patented "invention" is often either widely used or obsolete by the time the registration is issued. * Examiners skilled in computer science and software programming must be trained on the nature of software inventions, and the state of existing art. Qualified examiners must be hired and retained by the PTO at much higher rates than they are today. Compensation rates equal to those provided by industry are essential to recruit qualified personnel. * The PTO, in conjunction with industry, must establish additional committees to clearly delineate the standards of novelty and non-obviousness that will be required for software inventions to receive patents. APPENDIX G: MITCH KAPOR'S CONGRESSIONAL TESTIMONY ================================================= The following is an extract from the testimony of Mitch Kapor in a congressional hearing: I want to thank the Committee for this opportunity to testify on some of the intellectual property questions surrounding software. This is an area that I personally find fascinating and provocative - so please excuse me if my testimony ends up leaving you with more questions than answers. With no joke intended, software has been very, very good to me. I was fortunate enough to find a collaborator to craft an innovative piece of software called Lotus 1-2-3 - and that software evolved into both an industry standard and turned Lotus Development Corp. into one of America's most successful software companies. Because it is impossible to know what patent applications are in the application pipeline, it is entirely possible, even likely, to develop software which incorporates features that are the subject of another firm's patent application. Thus, there is no avoiding the risk of inadvertently finding oneself being accused of a patent infringement simply because no information was publicly available at the time which could have offered guidance of what to avoid. Please, require publication of patent application within a short period of their filing. The period of patent protection, 17 years, no longer makes sense in an era when an entire generation of technology passes within a few years. My recommendation would be to consider substantially shortening the length of protection. Most importantly, it is my heartfelt belief that many of the increasing number of recently issued software patents, concerning, for instance, fundamental techniques and artifacts of user interfaces, should never have been granted in the first place because of their failure to qualify as either novel or non-obvious. Some patents appear to preempt automation of common functions such as footnoting. This to me is like allowing a patent on the round steering wheel. The breadth of claims being allowed in these matters, is, in the words of Brian Kahin, Adjunct Research Fellow at Harvard's Kennedy School of Government, "often at a level of abstraction that is shocking to the uninitiated." If some future litigant is successful in upholding rights to one of these "bad" patents It will require expensive and time-consuming litigation, whose outcome is frankly uncertain, to defend the rights of creators which should never have been challenged in the first place. If I speak very bluntly here, it is only because I am deeply concerned that a single bad patent court fight with a negative outcome, like a major environmental accident, could have catastrophic effects. I don't think we can afford the risk. APPENDIX H:THE PATENT OFFICE ANNOUNCEMENT ========================================= This appendix contains the USPTO announcement for the public hearings to be conducted very soon: DEPARTMENT OF COMMERCE Patent and Trademark Office Docket #: 931222-3322 Notice of Public Hearings and Request for Comments on Patent Protection for Software-Related Inventions AGENCY: Patent and Trademark Office, Department of Commerce ACTION: Notice of hearings and request for public comments SUMMARY: The Patent and Trademark Office (PTO) is interested in obtaining public input on issues associated with the patenting of software-related inventions. Interested members of the public are invited to testify at public hearings and to present written comments on any of the topics outlined in the supplementary information section of this notice. DATES: Public hearings will be held on January 26-27, 1994, at the San Jose Convention Center, 408 Almaden Avenue, San Jose, California, and on February 10-11, 1994, at the Crystal Forum in Arlington, Virginia. Those wishing to present oral testimony at any of the hearings must request an opportunity to do so no later than five days before the date of the hearing at which they wish to testify. Written comments on the topics presented in the supplementary information section of this notice should be received by the PTO on or before March 15, 1994. ADDRESSES: Those interested in presenting written comments on the topics presented in the supplementary information, or any other related topics, should address their comments to the Commissioner of Patents and Trademarks, marked to the attention of Jeff Kushan. Comments submitted by mail should be sent to Commissioner of Patents and Trademarks, Box 4, Patent and Trademark Office, Washington, DC 20231. Comments may also be submitted by telefax at (703) 305-8885 and by electronic mail through the Internet to comments-software@uspto.gov. Written comments should include the following information: - name and affiliation of the individual responding; - an indication of whether comments offered represent views of the individual's organization or are the respondent's personal views; and - if applicable, the nature of the respondent's organization, including the size, type of organization (e.g., business, trade group, university, non-profit organization) and principal areas of business or software development activity. Parties offering testimony or written comments are asked to provide their comments in machine readable format in one of the following file formats: ASCII text, WordPerfect for DOS version 4.2 or 5.x, WordPerfect for Windows version 5.x, Word for Windows version 1.0 or 2.0, Word for DOS version 5.0, Word for Macintosh version 3.0, 4.0 or 5.x, or WordPerfect for Macintosh version 2.x. Persons wishing to testify must notify Jeff Kushan no later than five (5) days before the date of the hearing at which they wish to testify. Mr. Kushan can be reached by mail sent to his attention addressed to the Commissioner of Patents and Trademarks, Box 4, Washington, DC 20231; by phone at (703) 305-9300; or by telefax at (703) 305-8885. No requests for presenting oral testimony will be accepted through electronic mail. Written comments and transcripts of the hearings will be available for public inspection no later than March 30, 1994, in Room 902 of Crystal Park Two, 2121 Crystal Drive, Arlington, Virginia. In addition, transcripts of the hearings and comments provided in machine readable format will be available after March 16, 1994, through anonymous file transfer protocol (ftp) via the Internet (address: comments.uspto.gov), and will be available for Wide Area Information Server (WAIS) searching after March 30, 1994. FOR FURTHER INFORMATION CONTACT: Jeff Kushan by telephone at (703) 305-9300, by fax at (703) 305-8885, by electronic mail at kushan@uspto.gov, or by mail marked to his attention addressed to the Commissioner of Patents and Trademarks, Box 4, Washington, DC 20231. SUPPLEMENTARY INFORMATION I. Background Over the past decade, the computer software industry has evolved into a critical component of the U.S. economy. It is presently the fastest growing industry in the United States, with 1992 sales in the three core elements of the software industry -- programming services, prepackaged software and computer integrated design -- accounting for over $36.7 billion of our domestic gross product. The software industry also has created jobs at a remarkable rate; since 1987, employment in the software industry has risen at an annual rate of 6.6 percent and today, the industry employs about 4 percent of the American work force. The dynamic nature of the U.S. software industry has also served to propel the U.S. firms into a dominant position in the global software industry. U.S. firms hold about 75 percent of the global market for prepackaged software and approximately 60 percent of the world market for software and related services. In 1991, foreign sales of U.S. prepackaged software vendors totaled over $19.7 billion. Constant innovation has been the key to continued success in the U.S. software industry. As such, it is imperative that our domestic intellectual property systems not only provide an effective stimulus for innovation, but also provide appropriate and effective means for protecting those innovations. Indeed, the continued success of U.S. firms, in both domestic and foreign markets, depends directly on the availability of effective mechanisms to protect software innovations. Without such means, the full value of American innovation cannot be realized. Intellectual property systems provide the means through which software innovations can be both encouraged and protected. The present framework of intellectual property laws provides three basic forms of legal protection that are most relevant to the development and protection of software; namely, copyrights, patents and trade secret protection. Detailed reviews of each of these forms of protection can be found in the 1992 Office of Technology Assessment report entitled "Finding a Balance: Computer Software, Intellectual Property and the Challenge of Technological Change" (OTA-TCT-527), and in the final report of the Advisory Commission on Patent Law Reform to the Secretary of Commerce (1992). A brief synopsis of these three forms of protection follows. Software code is protected under copyright law as an original work of authorship. Copyright protection stems automatically from the act of fixation of a work onto a tangible medium. A copyright gives its owner the ability to control the reproduction, adaptation, public distribution, public display and public performance of the software code. Copyrights can be used to prevent others from copying the software program, either through direct duplication or through appropriation of the software's expressive (as opposed to functional) elements. Under U.S. law, copyright owners can also prevent the unauthorized rental of software. Copyright protection cannot be used to prevent the use by others of the functional aspects of software, nor can it be used as a basis for action against independently developed software. In addition, the fair use doctrine under copyright law provides third parties some flexibility in their use of copyrighted works. Patents can be used to protect processes implemented using software, as well as computer-based systems. The statutory definition of inventions that are eligible to receive patent protection is found in section 101 of title 35, United States Code. This section makes patents available for "any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof." To obtain patent protection, the inventor must apply for protection and proceed through an examination process before the Patent and Trademark Office (PTO). The examination process is used to assess whether the invention for which protection is sought meets all of the statutory criteria for patentability; namely, that the invention is eligible for protection, that it is new, that it is not obvious to a person familiar with the technical field of the invention, and that the invention has been adequately described in the patent application. Patent protection allows the patent holder to preclude others from making, using or selling the patented invention, as it has been defined in the patent claims, for a period of seventeen years measured from the date the patent is granted. Importantly, the party granted a patent must take action to enforce rights provided under the patent--the issuance of a patent does not automatically preclude infringing activity. In addition, the Federal courts have developed a limited exception to liability for infringement for non-commercial experimental use of inventions described in patents. Additional information on the patent process is available in the Manual of Patent Examining Procedure (MPEP), in particular, chapters 600, 700 and 2100. Finally, certain aspects of software can be protected through use of trade secrecy and contractual licensing agreements. Protection of trade secrets in the United States is governed by state, rather than Federal, law. Trade secret laws typically require the party asserting a trade secret right to take reasonable steps to prevent the public disclosure of the information held as a trade secret. Accidental or other public disclosure of a trade secret will eliminate the protection. Absent such disclosure, the trade secret rights will remain effective indefinitely. Trade secret rights can be enforced against parties that unlawfully obtain the information held as a trade secret. The focus of the discussions in the three scheduled public hearings will be the use of the patent system to protect software-related inventions. There will be three general subject matter areas presented for discussion: - - Use of the patent system to protect software-related inventions; - - Standards and practices used in examination of patent applications for software-related inventions; and - - Significance of and protection for visual aspects of software-related inventions. Questions appearing in section II, below, are intended to focus the discussion on each of the topics. They are not intended to discourage individuals from providing written comments on issues they believe should be addressed that are related to the protection of software-related inventions. Written comments on matters not presented below for discussion can be forwarded to the Commissioner of Patents and Trademarks for inclusion in the records of these hearings, but should clearly indicate that the comments are general in nature and not directed at the issues presented for discussion. II. Topics for Discussion Topic A. Use of the patent system to protect software-related inventions Dates and Times for Hearings on Topic A: January 26, 1994; 9:00 a.m. to 12:00 p.m., 2:00 p.m. to 5:00 p.m. January 27, 1994; 9:00 a.m. to 12:00 p.m., 2:00 p.m. to 5:00 p.m. Location for Hearing: San Jose Convention Center 408 Almaden Avenue San Jose, California. The question of patent protection for software-related inventions has engendered a significant amount of public debate. For example, concern has been expressed over the appropriate scope of eligible subject matter (e.g., which aspects of software-related inventions should be eligible for patent protection, and which should not). Others have expressed concerns over the effects of providing protection for inventions in which the main distinguishing characteristic is a software component. Some guidance on the question of patent eligibility has been provided by the Federal courts. First, the Supreme Court has instructed the lower courts to interpret the eligibility standards for patent protection broadly. In Diamond v. Chakrabarty, 447 U.S. 303, 309 (1980), the Court stated: The committee Reports accompanying the 1952 Act inform us that Congress intended statutory subject matter to "include anything under the sun that is made by man." The subject matter provisions of the patent law have been cast in broad terms to fulfill the constitutional and statutory goal of promoting "the progress of science and the useful arts". Congress employed broad language in drafting Section 101 precisely because such inventions are often unforeseeable. Second, the Supreme Court has held that the mere presence of a computer software-implemented mathematical algorithm in an invention does not automatically preclude the invention from being eligible to receive patent protection. Diamond v. Diehr, 450 U.S. 175 (1981). Finally, through interpretation of the exclusions from patentable subject matter under section 101 of title 35, United States Code, the Supreme Court and the lower Federal courts have provided guidance in determining which aspects of software-related inventions are eligible for patent protection. There are three general categories of exclusions to patent eligibility that are particularly relevant to software-related inventions. The first, and most commonly applied exclusion, is the exclusion of mathematical algorithms, per se, from patent eligibility. For a summary of the law governing this exclusion, and for guidance on how the PTO applies this exclusion in the context of its examination procedures, see "Patentable Subject Matter, Mathematical Algorithms and Computer Programs", 1066 O.G. 5, (Sept. 5, 1989) and "Note Interpreting In re Iwahashi," 1112 O.G. 16 (March 13, 1990). Second, methods of doing business are excluded from patent protection. While no cases have directly applied this exclusion to deny patent protection for software-related inventions, the exclusion is relevant for questioning the patent eligibility of processes that are modeled upon existing business processes but are implemented through a software-based system. See, e.g., Paine, Webber, Jackson & Curtis, Inc., v. Merrill Lynch, Pierce, Fenner & Smith, 564 F. Supp. 1358, 218 U.S.P.Q. 212 (D. Del. 1983). Finally, printed matter, per se, is not eligible for protection under the patent laws. This exclusion has relevance in the context of software code "written" onto non-paper media (e.g., magnetic or optical media capable of storing the software code). See, e.g., In re Miller, 164 U.S.P.Q. 439 (C.C.P.A. 1969); In re Jones, 153 U.S.P.Q. 77 (C.C.P.A. 1967). Within these limits, however, is a spectrum of inventions whose patent eligibility has been questioned. To encourage discussion of what aspects of software-related inventions should or should not be eligible for patent protection, interested members of the public are invited to offer their views on the following series of questions. 1. What aspects of the following examples of software-related inventions should or should not be protectable through the patent system? [Note--these are generalized hypothetical examples of patent claims. They are not intended to prompt comments as to the merits of the process referred to in the claim (e.g., whether the process is well known or obvious to a computer programmer). Instead, comments are desired as to the benefits or drawbacks of granting patents on the invention defined by the claim, presuming it was new and not obvious to a computer programmer.] Example A: a mathematical algorithm implemented on a general purpose computer: A computer comprising means for causing the computer to generate a signal that varies according to application of mathematical algorithm X to a given numerical input value. Example B: a mathematical algorithm implemented on a special purpose computer: A computer comprising: - means for collecting data; - means for extracting usable data from the collected data; - means for processing the usable data through application of mathematical algorithm X=A2 + B2, where A and B are derived from the extracted usable data; - a read-only memory used to calculate the squares of numbers provided to it; - means for providing to said read only memory numerical values derived from the extracted usable data; - means for storing in said read only memory numerical values derived from the extracted usable data; - means for obtaining from said read only memory the squares of numbers provided to said read only memory; and - means responsive to the output of said read only memory. Examples C-1 and C-2: A computer-readable medium, such as a disk, on which is stored a computer program. [Note: These examples include references to a computer readable medium as a "tangible" or "physical" embodiment of a software-related invention. The two perspectives presented in the examples differ in how the invention is defined. The first example defines the invention through reference to the actual software object or source code. The second example defines the invention through a narrative description of how the program functions.] C-1. A computer-readable medium, on which is stored a computer program of instructions comprising [software object or source code]. C-2. A computer-readable medium, on which is stored a computer program of instructions comprising: - means for performing function X; - means for performing function Y; and - means for performing function Z. Examples D-1 and D-2: A computer program, per se. [Note: These examples focus on the computer program, per se, as the invention, without inclusion of a "tangible" or "physical" embodiment. Like examples C-1 and C-2, two perspectives are presented as to how the invention is defined. The first example defines the invention through reference to the actual software object or source code. The second example defines the invention through a narrative description of how the program functions.] D-1. A computer program of instructions comprising [software object or source code]. D-2. A computer program of instructions comprising: - means for performing function X; - means for performing function Y; and - means for performing function Z. Example E: A data structure used in a computer program A hierarchical tree data structure having elements and possessing properties and operations. Example F: A process consisting of a series of computational or decisional steps that can only practicably be performed on a computer: A method of diagnosing an abnormal condition in an individual comprising: - collecting data related to the condition of the individual; - processing the data collected to place it in a structured, consistent format; - comparing the processed data to a first database of information documenting characteristics of normal and abnormal conditions in patients to determine if an abnormal condition exists; - upon detecting an abnormal condition, comparing the processed data to a second database of information documenting characteristics of the abnormality to determine the precise nature of the abnormality; - upon determining the precise nature of the abnormality, comparing the characteristics of the abnormality to a third database of information documenting suggested treatment and therapeutic regimes; and - collecting and presenting the information from said third database relevant to the determined abnormality. Example G: A method of doing business that has been implemented in a computer program (e.g., an accounting system implemented in software). A computer-implemented process comprising the steps of: - accessing information regarding the name of a patient and services provided to that patient from an electronic storage medium; - associating treatment rendered to a patient with a fee by comparing the collected data to a database of fees; - extracting billing data for said patient from said database; - printing an invoice documenting the fees charged and the appropriate mailing information for said patient. 2. What impact, positive or negative, have you or your organization experienced from patents issued on software-related inventions? [Note: If providing comments on this question, please provide details regarding the nature of the impact (e.g., the nature of any action taken by or against you or your organization under a patent, the results of the action, and the impact of those results on your activities or operations).] 3. What implications, positive or negative, can you foresee in maintaining or altering the standards for patent eligibility for software-related inventions (e.g., consider possible effects, if any, on doing business or protecting software products in domestic or foreign markets, conducting research, designing software or modifications thereto, etc.)? 4. Does the present framework of patent, copyright and trade secret law: (a) effectively promote innovation in the field of software? (b) provide the appropriate level of protection for software-related inventions? [Note: If responding to this question, please describe the experiences, if any, that you have had with the current system that led you to your conclusions.] 5. Do you believe a new form of protection for computer programs is needed? If so, what would be the desirable characteristics of such protection (e.g., what would be the substantive requirements for obtaining protection, what procedures would be used to obtain or register rights, what rights would be provided and how would those rights be enforced, and how would the new system relate to existing forms of intellectual property protection)? What would be the drawbacks of a new form of protection? Topic B. Standards and practices used in examination of patent applications for software-related inventions Dates and Times for Hearings on Topic B: February 10, 1994; 9:00 a.m. to 12:00 p.m., 2:00 p.m. to 5:00 p.m. February 11, 1994; 9:00 a.m. to 12:00 p.m. Location for Hearing: Marriott Crystal Forum 1999 Jefferson Davis Highway Arlington, Virginia Different sectors of the software industry have expressed concern over the ability of the Patent and Trademark Office to examine patent applications for software-related inventions effectively. Much of the discussion involves the lack of availability of printed documents, patents, and other evidence of public use of the invention before the application was filed (e.g., called "prior art") that can be used by examiners as a basis for denying the grant of a patent. Factors that have been identified as contributing to this problem include: - - early programming techniques were not well documented or publicly available; - - many software programming techniques were kept as trade secrets and not publicly disclosed; - - locating and obtaining the most relevant prior art is extremely difficult, due to the widely diverse nature of processes that have been implemented by computer software-related systems; and - - software is not documented in a consistent, readily understandable format (e.g., some programs only provide object code, different programming languages are used, source code is not summarized or documented, etc.). Concerns other than access to and use of prior art have also been cited. For example, some concern has been expressed that the standards used by examiners to assess novelty and/or obviousness over prior art are not reflective of industry standards, with the effect that patents are granted for well-known or obvious software techniques. Others have questioned the closed nature of the examination process, with no public intervention prior to grant, while some have criticized the current options for contesting the validity of granted patents (e.g., the PTO reexamination process or litigation in the Federal courts). In view of this, the PTO is interested in public input on how to improve the examination process for patent applications for software-related inventions. Interested members of the public are invited to offer comments on the following series of questions: 1. Do patents and printed publications provide examiners with a sufficient and representative collection of prior art to assess novelty and obviousness of software-related inventions? If not, how can existing collections of prior art be supplemented to provide examiners with a complete collection of prior art? 2. Can an accurate measurement of the ordinary level of skill in the art in the field of computer programming be derived from printed publications and issued patents? 3. Should the PTO impose a special duty on patent applicants for software-related inventions to disclose information relevant to their inventions (e.g., one that is higher than in other areas of technology)? [Note: Under current Rule 56 (37 CFR 1.56), all patent applicants are required to disclose to the PTO any information of which they are aware that is pertinent to the invention they claim in their patent application. The standard does not require the patent applicant to search or locate relevant information and present it to the Office for consideration. Failure of an applicant to comply with this requirement can result in the patent being held unenforceable.] 4. Do the standards governing novelty (35 U.S.C. 102) and obviousness (35 U.S.C. 103), as applied by the PTO and the Federal courts, accurately reflect inventive activity in the field of software design and development? [Note: If responding "no" to this question, please provide your suggestions on standards that could be used to demonstrate which software innovations should be viewed as "new" and "non-obvious" to a person of ordinary skill in the field of software design and development.] 5. Should implementing a known process, technique, system or method of doing business on a computer be viewed as being novel and non-obvious if, but for the use of software, the overall process, technique, system or method is well known? 6. In what ways can the PTO change examination procedures to assess novelty and obviousness of software-related inventions? [Note: The following questions are not intended to restrict comments on ways the PTO can improve the examination process, but are offered only as a sample of possible changes to the examination process. - Should the PTO require patent applicants for inventions related to software to conduct a search of prior art before filing a patent application, and to include in their application copies of relevant prior art documents along with a detailed explanation that points out how the invention claimed in the application is distinguishable over the supplied references? [Note: This would make the "special accelerated examination" practice described in MPEP 708.02 VIII standard practice for patent applications on software-related inventions.] - Given the difficulties associated with examiners assessing procedures from all fields of technology that have been implemented on a software-based system, should the PTO require patent applicants to prove that their inventions are distinct over the prior art aside from the implementation of the process on a computer? - Should the PTO be permitted to establish that a software-related invention is not novel or is obvious using a lower standard of proof than for other areas of technology (e.g., a standard less than prima facie)? A second topic related to patent examination standards and practices relates to the problem of effectively and meaningfully disclosing software-related inventions in patents and other printed publications. To fulfill their statutorily defined function, patent documents must effectively teach a person of ordinary skill in the relevant field of technology how to make and use the invention that is protected by the patent. With respect to patents on software-related inventions, this means that the patent must disclose enough information to enable the software programmer of ordinary skill to recreate the invention protected by the patent claims. In practice, several concerns have been identified. For example, some have questioned the "disclosure" value of computer program listings that are often included with patent specifications, given the significant administrative problems these listings create for the PTO and the widely divergent manner in which software is written. Others have questioned how best to describe software-related inventions in general, standardized terms (e.g., not through program code listings). In view of these points, the PTO invites public input on the following series of questions regarding disclosure requirements for software-related inventions. 7. What are the most effective ways to describe software (e.g., pseudocode, flowcharts, etc.), and how can they be implemented through the disclosure requirements for patent applications? 8. What difficulties do patent applicants face in complying with existing disclosure requirements (e.g., enablement, description, best mode) for software-related inventions? 9. Should the PTO require patent applicants to conform to a standardized disclosure format for applications filed on software-related inventions? 10. How should the PTO handle the submission of computer program code listings? Should the PTO require submission of program code listings? Should they require submission of code listings in machine readable format only? Should program code listings be included in patent documents or should they be made available only through a publicly accessible database? What hardships would patent applicants face if these requirements were imposed? 11. Are current rules governing the submission of drawings impeding the effective description of software-related inventions, and if so, what changes should be made? [Note: Rule 96 (37 CFR 1.96) governs the submission of computer program listings]. 12. What difficulties might patent applicants face if they were required to fully satisfy the disclosure requirements of 35 U.S.C. 112, 1st paragraph (i.e., enablement, description, best mode), without reliance on computer program listings? Topic C: Significance of and protection for visual aspects of software-related inventions Date of Hearing for Topic C: February 11, 1994; 2:00 p.m. to 5:00 p.m. Location for Hearing: Marriott Crystal Forum1999 Jefferson Davis Highway Arlington, Virginia This topic addresses the question of design patent protection for computer screen elements (e.g., icons and other user interface elements), and the significance of screen elements in the context of patentability (utility) of software-related inventions. Protection of the visual elements of software, particularly computer screen displays and images, is very important to the software industry. Recently, questions have arisen whether design patents can be used to provide protection for such elements. As way of background, a design patent provides protection for only the appearance of an article, not for its structural or utilitarian (functional) features. See, 35 U.S.C. 171. This is in contrast to a "utility" patent that provides protection for new, useful and non-obvious products, processes, machines, and compositions of matter. In the context of software, some have argued that design patents could provide much needed protection for the visual elements of screen displays that give programs their distinctive "look and feel." The question of design patent protection for computer screen displays or images has been raised in a series of recent cases before the Board of Patent Appeals and Interferences (Board). See, Ex parte Tayama, 24 U.S.P.Q.2d 1614 (Bd. PA&I. 1992); Ex parte Donaldson, 26 U.S.P.Q.2d 1250 (Bd. PA&I. 1992); Ex parte Strijland, 26 U.S.P.Q.2d 1259 (Bd. PA&I. 1992); Ex parte Donoghue, 26 U.S.P.Q.2d 1266 (Bd. PA&I. 1992); and Ex parte Donoghue, 26 USPQ2d 1271 (Bd. PA&I. 1992). The Board held in each of these cases that screen displays, standing alone, are not statutory subject matter. The Board concluded that, as claimed and described, the designs were merely pictures, and that "a picture standing alone is not protectable by a design patent." The Board's conclusions are consistent with judicial precedent that treats pictures standing alone as not being statutory design subject matter. This precedent points out that the factor that distinguishes subject matter eligible for design patent protection from a mere picture or surface ornamentation per se (i.e., abstract designs) is "the embodiment of the design in an article of manufacture." Note that, in dicta, four of the Strijland panel members indicated they would have concluded that statutory subject matter was present if certain threshold requirements were met. These are: (1) the specification as originally filed described and claimed the icon as a design for a programmed computer system; (2) the specification included drawings depicting the icon displayed on the monitor of a programmed computer system and (3) the specification explained how the icon was an "integral and active component in the operation of a programmed computer displaying the design." The Board decisions leave open the question of the threshold requirements for the protection of screen displays. To assist the Office in evaluating how to proceed in light of these decisions, public comments are invited on the following series of questions: 1. Should design patent protection be available for screen displays and other visual elements of computer software (e.g., should the PTO adopt the suggestion of the Board in the Strijland opinion that, if properly presented, screen displays can be statutory subject matter under 35 U.S.C. 171)? 2. If your answer to 1 is "yes" then: (a) Should the Office adopt the threshold requirements for statutory subject matter set forth in Strijland? What alternatives to those requirements would be consistent with current statutes, regulations and case law? (b) Would adoption of the Strijland threshold requirements require more detailed design application specifications in order to meet the description, enablement and best mode requirements of 35 U.S.C. 112, paragraph 1? (c) Would adoption of the Strijland threshold requirements affect the patentability of design applications claiming type fonts designs? Are type fonts distinguishable from screen displays for the purposes of 35 U.S.C. 171? (d) What is the article of manufacture that can be considered ornamented by icons, screen displays, menus, dialog boxes, etc., and how can these articles be illustrated to comply with 37 CFR 1.152? 3. What protection would design patents for screen displays provide that is not already provided by copyright and trademark law? 4. Have you or your organization encountered situations where copyrights or trademarks have failed to provide adequate protection for visual elements of software that could have been addressed through use of design patent protection? 5. Are images displayed on a television screen legally distinguishable from the same image displayed on a computer monitor? 6. Does a description in a specification indicating how a displayed image is an "integral and active component in the operation of a programmed computer displaying the design" provide a workable line between statutory and non-statutory design subject matter? A second facet of the discussion of visual elements of software is the significance of those elements in evaluating whether a software-related invention is deserving of utility patent protection. Specifically, how should visual elements of a software-related invention be evaluated, in the context of the invention as a whole, during examination and for judicial assessments of validity? The focus of this question is not whether the software-related invention should be eligible for protection under the utility patent law (for discussion of this question, see topic A, above). Rather, it is focused on the significance of visual elements of software in determining whether a patentable improvement has been made to a previously known process or article of manufacture. To assist this discussion, consider each of the following questions in the context of two machines, each having multiple hardware components and one software component that guides the operation of the machine. The only difference between the two machines is that the "new" machine employs different visual display elements in its software component. 7. Should the "new" machine be considered "novel" in view of the different visual elements used in the software component? 8. If viewed as making the machine as a whole "novel", should the visual display elements of the "new" machine justify a conclusion that the product as a whole could be non-obvious to a person of ordinary skill? 9. If you answered yes to questions 1 or 2, (a) Which field of technology should be used to determine the ordinary level of skill for assessing the question of obviousness (e.g., software programming, software interface design, field of technology for the machine, other) ? (b) How should the visual display elements be evaluated (e.g., ease of use, functions they provide, etc.)? (c) What aspects of the visual display should be compared and/or considered? III. Guidelines for Oral Testimony Individuals wishing to testify must adhere to the following guidelines: 1. Anyone wishing to testify at the hearings must request an opportunity to do so no later than five days prior to the date of the hearing at which they wish to testify. No one will be permitted to testify without prior approval. 2. Requests to testify must include the speaker's name, affiliation (if any), phone number, fax number (if available), mailing address, and the questions in each topic that the speaker intends to address in his or her testimony. 3. Speakers will be provided between 7 and 12 minutes to present their remarks. The exact time allocated per speaker will be determined after the final number of parties testifying has been determined. 4. Speakers must provide a written copy of their testimony for inclusion in the record of the proceedings no later than the last date of the hearings at which they are testifying (e.g., either January 27 or February 11, 1994). 5. Speakers must adhere to guidelines established for testimony. These guidelines will be provided to all speakers no later than two days prior to the date of the hearings. A schedule providing approximate times for testimony will be provided to all speakers no later than the morning of the day of each hearing. Speakers are advised that the schedule for testimony will be subject to change during the course of the hearings. IV. Other Information For information regarding accommodations in the San Jose area, or for information regarding the San Jose Convention Center facilities, individuals can contact Joseph R. Hedges of the Office of Economic Development of the City of San Jose. Mr. Hedges can be reached by phone at (408) 277-5880; by fax at (408) 277-3615, or by mail addressed to 50 West San Fernando Street, Suite 900, San Jose, California 95113. Bruce A. Lehman Assistant Secretary of Commerce and Commissioner of Patents and Trademarks APPENDIX I: ABOUT THIS DOCUMENT =============================== Version 1.0 of January 14, 1994. Copyright (C) Gordon Irlam and Ross N. Williams, 1994. Assistance: James Salsman, Lile Elam, and Ron Maeder. This document represents the opinions of its authors. Reproduction of this document is permitted. Gordon Irlam Ross N. Williams Sun Microsystems Rocksoft^tm (415) 336-5889 +61 8 379-9217 gordoni@Eng.Sun.COM ross@guest.adelaide.edu.au Gordon Irlam is a software developer at Sun Microsystems. He is in the Systems