a software engineering view to the decisions of the

104
HELSINKI UNIVERSITY OF TECHNOLOGY Department of Computer Science and Engineering Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs Thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Engineering Espoo 10th October 2001 Supervisor Professor Reijo Sulonen Instructor Professor Jukka Kemppinen

Upload: others

Post on 27-Nov-2021

1 views

Category:

Documents


0 download

TRANSCRIPT

HELSINKI UNIVERSITY OF TECHNOLOGY Department of Computer Science and Engineering

Risto Sarvas

A software engineering view to the decisions of the European Patent Office concerning computer programs

Thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Engineering

Espoo 10th October 2001

Supervisor Professor Reijo Sulonen

Instructor Professor Jukka Kemppinen

i

HELSINKI UNIVERSITY OF TECHNOLOGY

ABSTRACT OF THE MASTER’S THESIS Author: Risto Sarvas

Title of thesis: A software engineering view to the decisions of the European Patent Office concerning computer programs

Date: 10.10.2001 Number of pages: 104

Department: Computer Science and Engineering

Professorship: Software Engineering

Supervisor: Professor Reijo Sulonen

Instructor: Professor Jukka Kemppinen

The objective of this thesis was to study European Patent Office’s Board of Appeals’ decisions concerning computer program patent applications, and to research these decisions for any clear practice or principles on the patentability of computer programs.

In the theoretical part of this thesis, the current problems facing intellectual property rights in general are discussed, and a short introduction to patenting and its principles is presented. Computer programs are presented from the point of view of software engineering as machines having certain inherent characteristics. Also, the legislation concerning the European patent system is presented and discussed.

The experimental part of this thesis consists of 21 European Patent Office’s Board of Appeals’ decisions and their respective patent applications. The decisions were chosen on the basis of previous studies and literature about the subject, and they all involved computer program inventions.

The Board of Appeals’ decisions and their reasoning showed that there is no clear practice relating to the patenting of computer programs. This is due to the rapidly evolving and relatively young discipline of computer programming which has caused the level of technology, i.e. state of the art in this field, to remain obscure. For a patent system to function adequately the current level of technology should be well understood.

Secondly, the special nature of computer programs seems to contribute to the problems encountered in patenting computer programs: computer programs’ inherent qualities of invisibility and complexity that can be identified when computer programs are contrasted to more traditional mechanical machines, and the dual nature of computer programs as having behavior and being writings at the same time. These unique attributes have caused ambiguity in defining patent protection for computer programs using the existing legal regime.

Keywords: computer programs, European Patent Office, patenting, software patents

ii

TEKNILLINEN KORKEAKOULU

DIPLOMITYÖN TIIVISTELMÄ Tekijä: Risto Sarvas

Työn nimi: Ohjelmistotuotannon näkökulma tietokoneohjelmia koskeviin Euroopan patenttiviraston päätöksiin

Päivämäärä: 10.10.2001 Sivumäärä: 104

Osasto: Tietotekniikka

Pääaine: Ohjelmistotuotanto

Työn valvoja: Professori Reijo Sulonen

Työn ohjaaja: Professori Jukka Kemppinen

Työn tavoitteena oli tutkia Euroopan patenttiviraston valituslautakunnan päätöksiä tietokoneohjelmia koskevista patenttihakemuksista. Tutkimuksen päämääränä oli sel-vittää onko näiden päätösten pohjalta havaittavissa selkeää linjaa ja käytäntöä tietokone-ohjelmien patentoitavuudessa.

Työn kirjallisuusosassa tuodaan esille immateriaalioikeuksien nykyiset ongelmat yleisellä tasolla ja patentointiin yleensä annetaan lyhyt johdanto. Tämän jälkeen tietokoneohjelmat esitetään ohjelmistotuotannon näkökulmasta koneina, joilla on tiettyjä luontaisia piirteitä, ja Euroopan patenttiviraston patentin myöntämistä koskeva lainkäyttö käydään läpi.

Kokeellisessa osassa tutkitaan 21 Euroopan patenttiviraston valituslautakunnan päätöstä sekä niiden vastaavat patenttihakemukset. Tutkitut päätökset on valittu aikaisempien tutkimusten ja alan kirjallisuuden perusteella. Kaikissa tapauksien keksinnöissä on mukana tietokoneohjelma.

Valituslautakunnan päätökset sekä niiden perustelut osoittavat, että selkeää käytäntöä tietokoneohjelmien patentoitavuudesta ei ole. Tämä johtuu tietokoneohjelmien suhteel-lisen nuoresta ja nopeasti kehittyneestä tieteenalasta, minkä seurauksena vallitseva teknologinen kehitystaso on jäänyt epäselväksi; patentointijärjestelmä vaatii toimiakseen, että vallitseva teknologinen kehitystaso on selkeä ja ymmärretty.

Toiseksi, tietokoneohjelmien erityispiirteet näyttävät vaikuttavan tietokoneohjelmien patentointiin liittyviin ongelmiin: tietokoneohjelmien luontainen näkymättömyys ja monimutkaisuus, mikä on havaittavissa verrattaessa tietokoneohjelmia mekaanisiin koneisiin, ja tietokoneohjelmien kaksijakoinen piirre olla samaan aikaan sekä toiminnal-linen kone että kirjallinen tuote. Nämä erityispiirteet ovat syynä epäselvyyksiin tietoko-neohjelmien patenttisuojan määrittelemisessä nykyisen oikeudellisen säätelyn puitteissa.

Avainsanat: Euroopan patenttivirasto, patentointi, ohjelmistopatentit, tietokoneohjelmat

iii

Acknowledgements

This thesis was done at Helsinki Institute for Information Technology during the nine months between January and September 2001.

Primary thanks for support and priceless knowledge go to the unequaled and eminent professor Jukka Kemppinen and to my project partner Aura Soininen. Refined gratitude goes to Helsinki Institute for Information Technology and Sonera for supporting the making of this thesis financially.

Especially, thanks to professors Shosta Sulonen and Martti Mäntylä for their contribution during the work and development of this thesis.

Lavish thanks to Markus Huttunen, Mikko Kiesilä, Tero Mononen and dad - undeniably valuable proofreading.

Because of this opportunity to express my gratitude, I would like to adduce few instructors from my years as a student in the Helsinki University of Technology: special thanks to Eeva-Leena Aittoniemi, Vesa Kantola, Pasi Karonen, and Tuuli Lehtisalo for your excellent teaching.

The last thanks go out to various people whose direct and indirect support has helped me to produce this thesis: thank you the people of Lastenhuone, Ben Folds Five, Guy Ritchie, Terry Pratchett, Fraternitas per se, and Tuula.

In the end I would like to add the mandatory quote:

Barbarian Invaders Machine, the. A device apparently invented by Leonard of Quirm. Weight: 2 tons. Construction: big blocks of wood, and lots of cogwheels. Motive power: weights on a pulley and twisted rubber bands. Purpose: on the insertion of one penny in the slot, the player has the opportunity to fire little spears at the ranks of wooden barbarian invaders as they wobble across the proscenium. Occasionally a badly carved horseman jerks past and extra points are scored if he is hit. A device ahead of its time. (Pratchett, T.; Briggs, S. The Discworld Companion)

Espoo 10.10.2001

______________________________ Risto Sarvas

iv

Table of Contents

ABSTRACT OF THE MASTER’S THESIS ...........................................................................I DIPLOMITYÖN TIIVISTELMÄ .............................................................................................II ACKNOWLEDGEMENTS...................................................................................................III TABLE OF CONTENTS..................................................................................................... IV 1 INTRODUCTION .........................................................................................................1

1.1 Problem Statement ........................................................................................................... 2 2 BACKGROUND ...........................................................................................................3

2.1 Summary of patenting....................................................................................................... 3 2.1.1 Patenting in general...................................................................................................... 3 2.1.2 Patentability .................................................................................................................. 4 2.1.3 Famous patents ............................................................................................................ 5

2.2 Patent systems face new problems .................................................................................. 6 2.2.1 Traditional patenting ..................................................................................................... 7 2.2.2 Rise of information technology ..................................................................................... 8 2.2.3 New problems in patenting ........................................................................................... 9 2.2.4 Questioning the patent system ................................................................................... 10

2.3 Everyday terminology in a new context .......................................................................... 11 2.3.1 Algorithm..................................................................................................................... 13 2.3.2 Computer program...................................................................................................... 14 2.3.3 Software...................................................................................................................... 15 2.3.4 Summary..................................................................................................................... 15

3 COMPUTER PROGRAMS AND PATENTING ..........................................................17 3.1 A software engineering view of computer programs....................................................... 17

3.1.1 Application domain ..................................................................................................... 19 3.1.2 Computer programs are machines ............................................................................. 20 3.1.3 Characteristic problems of computer programs.......................................................... 21 3.1.4 Summary..................................................................................................................... 23

3.2 Patenting in the European Patent Office......................................................................... 24 3.2.1 Patentability: European Patent Convention Article 52................................................ 26 3.2.2 Rules 27 and 29 of the Implementing Regulations..................................................... 28 3.2.3 Guidelines for Examination in the EPO ...................................................................... 28 3.2.4 Summary of patentability in the EPO.......................................................................... 29 3.2.5 Differences in patentability in U.S. and Japan............................................................ 30

3.3 Invention descriptions and technicality ........................................................................... 31 3.3.1 Patentable invention structure .................................................................................... 32

v

3.3.2 Invention elements, technical features ....................................................................... 33 3.3.3 Computer program invention structure ....................................................................... 33 3.3.4 Computer program invention elements ...................................................................... 35 3.3.5 Technical contribution and technical character .......................................................... 36 3.3.6 Technical problem and solution.................................................................................. 38 3.3.7 Technical effect........................................................................................................... 39 3.3.8 Technical features forming the solution...................................................................... 40 3.3.9 Technical considerations, technical knowledge.......................................................... 40 3.3.10 Invention as a whole vs. novel feature ................................................................... 41 3.3.11 Summary ................................................................................................................ 42

4 EXAMPLES OF EPO PATENTS ...............................................................................43 4.1 EPO Board of Appeal cases ........................................................................................... 44

4.1.1 Technical and mental processes ................................................................................ 45 4.1.1.1 Vicom / Computer-related invention................................................................... 45 4.1.1.2 IBM / Document abstracting and retrieving........................................................ 46 4.1.1.3 IBM / Generating a list of expressions ............................................................... 48 4.1.1.4 IBM / Text processing ........................................................................................ 49 4.1.1.5 Siemens / Character form .................................................................................. 51 4.1.1.6 IBM / Data communication system .................................................................... 52 4.1.1.7 Summary............................................................................................................ 53

4.1.2 Networks ..................................................................................................................... 54 4.1.2.1 IBM / Data processor network............................................................................ 54 4.1.2.2 IBM / Document distribution network ................................................................. 55 4.1.2.3 Summary............................................................................................................ 56

4.1.3 Internal workings of hardware..................................................................................... 57 4.1.3.1 IBM / Displaying of pre-determined messages .................................................. 57 4.1.3.2 Koch & Sterzel / X-ray apparatus....................................................................... 58 4.1.3.3 IBM / Editable document form............................................................................ 59 4.1.3.4 Bosch / Electronic computer component ........................................................... 61 4.1.3.5 Summary............................................................................................................ 62

4.1.4 User convenience and user interfaces ....................................................................... 62 4.1.4.1 Sohei / General-purpose management system ................................................. 62 4.1.4.2 IBM / Editing business charts............................................................................. 64 4.1.4.3 IBM / On-line help facility ................................................................................... 66 4.1.4.4 IBM / Interactive rotation of displayed graphics ................................................. 67 4.1.4.5 IBM / Hierarchical selection ............................................................................... 69 4.1.4.6 DAI / Designing 3D container............................................................................. 70 4.1.4.7 IBM / Windowing ................................................................................................ 72 4.1.4.8 Summary............................................................................................................ 73

4.1.5 Code generation and programming............................................................................ 73 4.1.5.1 Texas Instruments/Menu-based natural language understanding system........ 74 4.1.5.2 AT&T / System for generating software source code ........................................ 75

vi

4.1.5.3 Summary............................................................................................................ 76 4.2 Mechanical patents ......................................................................................................... 76

4.2.1 Means for cleaning floor ............................................................................................. 77 4.2.2 Chopping machine for cutting and splitting timber...................................................... 78 4.2.3 Method and apparatus for bending and tempering glass sheets ............................... 79 4.2.4 Summary..................................................................................................................... 80

5 CONCLUSIONS.........................................................................................................81 5.1 Components and generic programs................................................................................ 81 5.2 Level of implementation .................................................................................................. 82 5.3 Abstract machine descriptions ........................................................................................ 83 5.4 Problems in patenting computer programs..................................................................... 84 5.5 Problem statement .......................................................................................................... 85 5.6 Further research.............................................................................................................. 86

REFERENCES ................................................................................................................... A APPENDIX A ......................................................................................................................G APPENDIX B ...................................................................................................................... H APPENDIX C .......................................................................................................................J

1 Introduction 1

1 Introduction

Patenting plays a major part in advancing technological innovation and making a profit out of it. The idea of protecting innovation has been around the last five centuries and it has developed to its present state of patent laws along with the technological progress.

The rapid development of information technology in the last decades has brought intellectual property rights onto its knees. Copyright and patent laws are stretching their definitions and practice trying to overcome the problems emerging from the new technology. Examples in copyright law like Napster and mp3 music have even reached the public (Harmon 2000). In the field of patents Amazon’s 1-click-patent is probably the most famous one (Bezos 2000).

In the field of patents the criticism has been directed to the quality of patents and the patent system providing too much protection to innovations. The so-called bad patents have been accused of being too obvious, not novel and suffocating innovative development in the software industry.

The problems of the intellectual property laws are not helped by the rise in information business. Patenting computer programs has become a strategic business tool: IBM’s revenue from licensing has tripled from $500 million in 1994 to $1.5 billion in 1999. In year 1999 Sun Microsystems had 1223 patents and Microsoft had over 600 patents; in the same year IBM had 26342 patents. Also the amount of patent applications and granted patents has more than doubled in the last 20 years. (Patent wars 2000)

The uptrend of information business and the problems of intellectual property have caused lots of debate among professionals in legal, software and economic fields. These three disciplines seem to lack the kind of comprehension that is present in traditional industries; the rapid developments in technology have caused that these professionals simply do not understand each other.

One objective of this thesis is to shed some light on software patenting. The presumed readers for this study are software engineers and other professionals who might not be familiar with the concepts and practice of patenting computer programs in Europe. After reading this thesis the reader should have a slightly better understanding of the problems and questions involved.

This thesis is limited to the legal practice of the European Patent Office. Nevertheless, other patent offices have nearly the same principles and problems and understanding computer program inventions in one patent system is beneficial in understanding others.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

1 Introduction 2

The goal of this study is to find out from European Patent Office’s practice what is actually meant by computer program patents in Europe, and is there a clear practice surrounding the patentability of computer programs. The problems encountered are contrasted to software engineering principles and traditional mechanic innovations.

The first part of the thesis consists of chapters 1-3. In these chapters first patenting is introduced briefly, then the general current problems of intellectual property rights are discussed with a focus on patenting. Special weigh is put on the difficulties rising from the use of different vocabulary. Then a software engineering point of view used throughout the thesis is presented. Also, the legislation and practice of the European Patent Office is introduced.

The second part of the thesis consists of chapters 4-5. Chapter 4 includes the 21 European Patent Office’s Board of Appeals’ decisions concerning patenting of computer programs. The Board of Appeals is the authority on the practice and direction of the whole patent office. In the end of chapter 4 three mechanical inventions are presented to show the differences between patent descriptions of computer programs and patent descriptions of mechanical machines. Chapter 5 concludes the thesis by drawing conclusions from the material in chapter 4, and presenting further questions rising from these conclusions.

1.1 Problem Statement

The purpose of this thesis is to go through the European Patent Office’s Board of Appeals’ decisions concerning computer program patents, and study these decisions for any clear practice or principles on the patentability of computer programs.

The problem involved in patenting computer programs in Europe is that there seems to be a lot of misunderstanding and ambiguity surrounding the practice and convention in the patentability of computer programs. Computer program technology is a young field of technology when compared to, e.g. mechanical fields where the practice on patentability has two hundred years of history. Therefore, the patentability of computer programs is referred to patenting of mechanical inventions; both seen, in the context of patenting, as machines serving a purpose in a distinguished application domain.

This thesis is restricted to the practice of the European Patent Office. The Board of Appeals’ decisions were chosen as an indicator of the whole Office’s practice because the Board is the highest authority interpreting the European Patent Convention, which is the legal basis for patenting in the Office. Therefore, the Board’s decisions form the grounds for practice in examining patents in the European Patent Office.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

2 Background 3

2 Background

This chapter is a short introduction to the ongoing debate and discussion on problems involved in patenting computer programs. The area of so-called software patenting has emerged in the last twenty years as the technology has advanced and it has become increasingly more important for businesses and researchers institutes to find ways of protecting their computer programs.

The first section is a short summary of patenting in general. The second section introduces the history of the problem and the main issues involved when discussing patenting computer programs. The third section is an example of the simple problem of defining everyday words in legislation: words like algorithm, computer program and software must have as precise definition as possible in the given context, to avoid confusion and ambiguity.

The goal of this chapter is to help the reader to understand the questions and problems surrounding the discussions on computer program patents.

2.1 Summary of patenting

This section presents a short summary of patents in general according to the European Patent Office with some comments from the UK Patent Office.

2.1.1 Patenting in general

A patent is a legal title granting its holder the exclusive right to make use of an invention for a limited area and time by stopping others from, amongst other things, making, using or selling it without authorization (EPO 2001).

The need for a special system for granting exclusive rights can be seen to compensate for the fact that ideas and processes can not be own in the same way as physical property can be own. In other words, inventors were given exclusive rights for their inventions so that the rights for inventions could be paralleled to proprietary rights.

All patent applications and granted patents are published. They provide a useful indicator for monitoring market trends, as well as being a source of information about innovative developments in all areas of technology, and as such are an effective means of avoiding parallel developments and duplicated research. (EPO 2001)

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

2 Background 4

The patent system plays a major part in the transfer of technology, which acts as a stimulus to technical innovation: the exclusive right to exploit an invention commercially makes it easier for companies to finance research and development; as exclusive rights, patents strengthen a company's market position; patent inventions encourage research into alternative solutions; and the licensing of patents promotes the dissemination of new technologies. (EPO 2001)

Patents indicate the level of innovative activity in a particular market. They generate new investment and are a motivating force behind technical progress. (EPO 2001)

2.1.2 Patentability

In the European patent office, the patents have three criteria for patentability: novelty, inventive step and industrial applicability. But before these criteria are examined the invention must be technical, because the patent system is for technical inventions. The term technical is not explicitly defined, but in the European Patent Office the following are not considered technical: discoveries, scientific theories and mathematical methods; aesthetic creations; schemes, rules and methods for performing mental acts, playing games or doing business, and programs for computers; and presentations of information. These non-technical things are also referred to as excluded subject-matter or as things excluded from patentability. In other words, the European Patent Office does not define what is patentable, it only lists what is not patentable.

Chapter 3 of this thesis presents the legislation and practice involved around technicality in more detail, but it is worth mentioning that interpretation of the list of excluded things presented above is by no means trivial, and what is excluded and what is not, i.e. what is technical and what is not, is one of the difficult questions surrounding the patenting of computer programs.

The three criteria for granting a patent, after it has been claimed technical, are novelty, inventive step and industrial applicability.

An invention is considered new if it does not form part of the state of the art (EPO 2001). In other words, the invention must never have been made public in any way, anywhere in the world, before the date on which an application for a patent is filed (What is a patent? 2000).

In practice, state of the art means the information a patent examiner has or can easily achieve of the current level of knowledge in the field of the invention. Usually for information to be thought as state of the art, it is either published, publicly used or considered obvious for a person skilled in the art. Traditionally

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

2 Background 5

patent offices have used patent libraries as a reliable indicator of the state of the art.

An invention is considered as involving an inventive step if it is not obvious to a skilled person having regard to the state of the art. In other words, an invention involves an inventive step if, when compared with what is already known, it would not be obvious to someone with a good knowledge and experience of the subject (What is a patent? 2000).

And thirdly, an invention shall be considered as susceptible of industrial application if it can be made or used in any kind of industry, including agriculture (EPO 2001). In other words, an invention must be capable of being made or used in some kind of industry. This means that the invention must take the practical form of an apparatus or device, a product such as some new material or substance or an industrial process or method of operation. Industry is meant in its broadest sense as anything distinct from purely intellectual or aesthetic activity. It does not necessarily imply the use of a machine or the manufacture of an article. Agriculture is included. Articles or processes alleged to operate in a manner clearly contrary to well-established physical laws, such as perpetual motion machines, are regarded as not having industrial application. (What is a patent? 2000)

This thesis focuses on the concept of patentability of computer programs. As stated above and discussed in more detail in chapter 3, computer programs are not considered to be technical by the European Patent Office. This study centers on technicality of computer programs and how that is interpreted by the European Patent Office’s Board of Appeals. What is meant by novelty, inventive step and industrial applicability in the context of computer programs is left less focus.

2.1.3 Famous patents

To give an example of what is patented here are some patents that are considered famous according to The Franklin Pierce Law Center Intellectual Property Library User’s Guide’s Famous United States Patents (1998) and the UK Patent Office (500 years of patents 2000).

These examples of patents show that patenting has played a major role in the development of technology and business, and show the reader what has been meant by patents traditionally. A long history in certain fields of technology has provided them with wide library of patents and a clear comprehension of the concepts of novelty, inventive step and industrial applicability. It is easy to understand that a new field of technology, such as computer software technology, has to go through a lot of practice and ambiguity to achieve a similar state of convention.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

2 Background 6

Early patents were grants of privilege to manufacturers and traders. The earliest known English patent for invention was granted by Henry VI to Flemish-born John of Utynam in 1449. The patent gave John a 20-year monopoly for a method of making stained glass, required for the windows of Eton College, that had not been previously known in England.

The first U.S. patent was given in 1790 to Samuel Hopkins for Improved potash process. British patents of that time included James Puckle’s machine gun in 1718 and James Watt’s 1796 patent for a steam engine. Some 19th century patents made in the U.S. were revolver by Samuel Colt in 1839, telegraph by Samuel F.B. Morse in 1840, rubber fabric by Charles Goodyear in 1835, sewing machine by Isaac Singer in 1855, alternating current transmission by Nikola Tesla in 1888, punch card accounting by Herman Hollerith in 1889, speaking telegraph by Thomas Edison in 1892, and aspirin by Felix Hoffman in 1900.

Some famous patents of roughly the first half of the 20th century include, wireless telegraphy by Guglielmo Marconi in 1901, safety blade and razor by King Gillette in 1904, nylon by Wallace Carothers in 1937, junction transistor by William Shockley in 1951, and integrated circuit by Robert Noyce in 1961.

2.2 Patent systems face new problems

Patenting involves three disciplines: law, engineering and economy. Traditionally the engineers design the inventions, patent professionals describe the invention in the patent application, and the economists figure out the profit of patenting. Therefore it can be said that patenting has been a familiar part of production.

On the other hand, software engineering is such a young discipline that patenting has not formed its ground there. Therefore, legal discussions concerning patenting in software industry are based on the old model that has formed prior to software industry. The software engineers on the other hand base their discussions on practices and principles that are not based on traditional patenting.

As a result to this, none of the three disciplines involved are aware of what they are talking about: The patent offices are not up to date on the state of the art considering computer program inventions. The software engineers do not understand the peculiarities involved in patenting computer programs, and the legal professionals do not understand the technical characteristics of software. The economists have hard time understanding both the rapidly evolving technology and the complex world of software patents.

The big question behind all the discussions is the rationale behind patenting software, or computer programs. Should software be excluded from patentability or not? When is software patentable? What are the economical effects of allowing

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

2 Background 7

software patents or excluding them? These difficult questions are not answered in this thesis, but the research done does its best to shed some more light on the problems arising in applying the old patent system to computer programs.

This section is a quick tour to the questions, comments and feelings involved in patenting computer programs. Although this thesis focuses on European Patent Office’s practice, the problems encountered in patenting are the same worldwide and the discussion flourishes across the borders of individual patent systems.

The first section describes how the old patent system worked and what was its purpose. Then the technological leap of information technology is presented in the context of patenting. The last two sections go through the problems and discussions involved in patenting computer programs.

2.2.1 Traditional patenting

The patent system is an old system, first recorded patent being from Florence from 1421 (Cornish 1989). It has changed during the hundreds of years as the sociological and economical situations have changed. Encyclopædia Britannica (2001) defines a patent as:

a government grant of the exclusive right to make, use, or sell an invention, usually for a limited period. Patents are granted to new and useful machines, manufactured products, and industrial processes and to significant improvements of existing ones. Patents are also granted to new chemical compounds, foods, and medicinal products, as well as to the processes for producing them. Patents can even be granted to new plant or animal forms developed through genetic engineering.

The purpose of the patent system has been to encourage the making of inventions and the subsequent innovative work that will put those inventions to practical use. The purpose has also been to disclose technical inventions for other inventors to use and base their new inventions on, and in that manner move overall technological development onwards. The state gives the inventor an economic monopoly for a limited time in return for a public description of the invention. (Hakulinen 1945) (Cornish 1989)

Prior to the technological advances in computers and computer networks in the late twentieth century, the patent system was considered to function adequately; the last large debate on the usefulness of patenting took place in the late 19th century. The patent system was, and still is in many fields of technology, a source of technical information, and patents have been considered to make available a large quantity of information about the latest technical advances. Those concerned with the development of a technical field have regularly consulted patent libraries,

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

2 Background 8

and it has been a common practice for competitors who are roughly at the same state of advance to read each other’s patent specifications. (Cornish 1989)

As the technology advanced and handling of information changed radically, these traditional roles were facing a change of their own.

2.2.2 Rise of information technology

Advances in information technology have radically changed the ability to reproduce, distribute, control and publish information (NRC 2000). These changes have affected directly and indirectly the traditional form of engineering, economy and intellectual property. The technological leap consists of developments in the field of microprocessors, personal computers, computer networks, and the technology involved in combining and applying them.

In the last thirty years when the new discipline of software engineering has evolved (Sommerville 1995), it has developed hand in hand with the advances in computer and information technology. Having its background more in science than in industry, software engineers have taken the approach that ideas are free, like scientific discoveries are. Therefore, the industry's view of treating intellectual property as business and using patents to protect ideas was not an obvious choice in the first decades of software engineering. Also the legal cases in the United States, involving patenting of computer programs or algorithms, i.e. Gottschalk v. Benson (1972) and Parker v. Flook (1978), did not encourage patenting of computer programs.

The Gottschalk v. Benson case was about transforming binary coded decimals into pure binary form. The Supreme Court ruled that the method could no be patented, even though the applicant intended to carry out the method by computer, because it would preempt all use of the algorithm. The Supreme Court announced that mathematical algorithms could not be patented. (NRC 2000)

The Parker v. Flook case was about an algorithm useful for calculating alarm limits for a catalytic converter plant. The Supreme Court did not think that this algorithm, any more than the Pythagorean theorem or any other purely mathematical method, could become patentable merely because it might be applied to a particular useful end. (NRC 2000)

The 1981 U.S. Supreme court’s case Diamond v. Diehr (1981) is considered a turning point in patenting computer programs in the United States. The invention involved a computer program and nonetheless the patent was granted. The grant was accepted because the invention involved a traditional technological process of curing rubber, one step of which required a computer program. (NRC 2000)

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

2 Background 9

A similar turning point in Europe is considered to be Vicom’s patent case in the EPO Board of Appeals in 1986 (T 208/84 1986), where a digital signal processing program for processing images was found patentable when it was regarded as a technical process on a physical object, in this case a digitized image.

Therefore it can be said that patenting came late to software engineering; already when the discipline had formed its own traditions and ways of dealing with ideas and their protection.

Intellectual property law and its fundamental concepts have evolved for couple of hundred years, adapting and changing as the technology has changed. Prior to the technological advances, they were in a certain balance, but now with the information technological leap of last decades intellectual property is in need of a renovation. NRC’s book Digital Dilemma (2000) states the problem:

… the carefully crafted balance may be in danger of being upset. The emergence in the past 10 years of a new information infrastructure marked by the proliferation of personal computers, networks that connect them, and the World Wide Web has led to radical changes in how informational works are created and distributed, offering both enormous new opportunities and substantial challenges to the current model of intellectual property.

2.2.3 New problems in patenting

As software industry has grown to a major business, it has become important to protect computer programs by intellectual property laws. Historically information innovations such as computer programs have been excluded from patent law, but as mentioned above, this point of view has been narrowed in recent decades, and computer programs and even business methods are no more excluded from patentability in some patent laws (NRC 2000).

Academics have concluded that copyright can offer protection for some aspects of computer programs. Other valuable aspects, such as the useful behavior generated when programs are in operation and the industrial design responsible for producing this behavior, are vulnerable to rapid imitation within copyright law. The behavior of a computer program can be quite easily imitated or cloned without copyright infringement and none of the existing legal regimes is well suited to solving this problem, and there have been suggestions about a sui generis approach to legal protection of computer programs. (Samuelson et al. 1994)

Most of the controversy about software protection has arisen when software developers have tried to use existing legal regimes to protect their computer program innovations. The discussion flourishes in the legal and software engineering communities, both in the academic field and industry.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

2 Background 10

The new problems in patenting rise from the fact that computer programs and business methods, previously excluded innovations, have become patentable and the system has no practice on how to handle them. Nevertheless, software innovators are seeking legal protection for their computer programs, and copyright and patents do not seem to give appropriate protection.

2.2.4 Questioning the patent system

There is growing scepticism among academics about whether such state-imposed monopolies help a rapidly evolving market such as the Internet. What is "novel," "nonobvious" or "useful" is hard enough to know in a relatively stable field. In a transforming market, it's nearly impossible... (Lessig 1999)

The ongoing discussions, articles, and legal cases have brought about several questions about patenting software and the patent system in its entirety. The efficiency and functionality of patent offices has been questioned in the face of such a rapidly developing industry as computer programs: is there sufficient prior art to make sound decisions about novelty and nonobviousness, are the patent examiners adequately trained, is the monopoly given for patents too long, and is the bureaucratic patent office just too slow for the market cycles of information products (NRC 2000)?

One of the organizations opposing computer program patents, League for Programming Freedom, criticized in 1991 the U.S. Patent and Trademarks Office for granting obvious inventions a patent. The League blamed the U.S. Patent Office for having insufficient prior art and knowledge on computer programs, and claimed that searching software for all potential patent infringements is prohibitively expensive (LPF 1991).

The concept of an artificial system for granting monopolies in software has created lots of dissatisfaction among individual software designers, especially among the members of open source and free software movements (LPF 1991, FSF 1996). For programmers and software engineers it seems strange that a computer program that somebody has developed independently from scratch may be unusable because someone has a patent on a similar program, in the words of the League for Programming Freedom: reinventing independently is prohibited. Figure 1 shows a humoristic reaction from software developers towards the U.S. patenting system.

Not everyone is against patents on computer programs. Paul Heckel (1992) in his article defends software patents and says that they are beneficial to small software developers in stimulating innovation. He also argues that software is not fundamentally different from other technologies where the patent system has worked quite well.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

2 Background 11

Figure 1. Alan Cox’s t-shirt design criticizing U.S. Patent Office’s policies.

A recent study from PbT Consultants (2001) shows that software professionals are not aware that although the European Patent Convention states that computer programs are not patentable there are over 20 000 software related patents in Europe. This kind of misunderstanding is due to the use of same words in different contexts: the word computer program used by software professionals is much wider in its meaning than the word computer program used by the European Patent Office. The next section discusses this problem.

The criticism of the patent system is not a novel idea. In the nineteenth century there were similar arguments attacking the rationale of patenting. One persistent argument against patents in earlier controversy was this: since inventions are there to be discovered, industries that have progressed to a certain point will inevitably make them, and so artificial aids are unnecessary. It was a line of argument that carried some conviction when the bulk of inventions concerned relatively simple mechanical contrivances that were often worked out as a by-product of ordinary manufacturing (Cornish 1989). It is easy to find analogies in the argumentation of contemporary patent opposition.

2.3 Everyday terminology in a new context

The devil is in the details (NRC 2000).

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

2 Background 12

This section presents three often-used words in computer science and engineering that require an autopsy when they become a part of juridical text. The definitions are presented to help the reader understand the problem in using these words when discussing intellectual property rights like patenting. The examples show how a basic word used daily must be defined in a more precise way in the juridical context. Also this underlines the problem in interpreting decisions made by different courts where there are keywords left undefined, and their exact meaning is of most importance. Chapter 3 of this thesis is devoted to the problem of understanding the use of certain words in patenting computer programs in the European Patent Office.

In software engineering the need for defining the meaning of common words, like ‘computer program’, is not necessary; the different connotations and implications cause no problems in practice, like in everyday life the definition of word ‘water’ as H2O is not necessary for practical purposes, but in the context of chemistry it is important. Another example is the definition of the word ‘car’: in everyday language it is quite clear what is meant by a car, but in the context of motor insurances or driver’s licenses a more detailed definition of a car is required.

For example, using the above word ‘car’ in everyday language is adequate for most purposes; people know what a person is talking about when she uses the word ‘car’. The problem, which is evident in juridical contexts, rises when the word ‘car’ must be defined so that it is as explicit as possible. In the context of driver’s licenses it is important to define the word ‘car’ to mean certain kind of vehicles; usually trucks, heavy vans, and busses are not cars in that context.

The problem rises when a word must be explicitly defined so that it can be identified when presented for examination or distinguished from other semantically similar words. For example, the actual meaning of words ‘software’, ‘program’, and ‘algorithm’ is not a problem in everyday software engineering, but when these words become a part of legislation the overlapping in their meanings and connotations involved with them become a problem.

To make any rules, laws or regulations concerning computer programs, algorithms or software the meaning of these words should be clear to the parties involved. In some cases everyday language suffices. In patenting it does not. Statements that mathematical methods are not patentable, or computer programs are not patentable are too vague. In the context of patenting they require either a long history of practice or a clear definition to be understood unambiguously. A long history of practice, like in patenting in the mechanical industry, is not possible in patenting computer programs because it is such a new phenomena. A clear definition of the key words in the context of patenting also seems impossible, because even none of the patent offices has provided one.

This section does not define the words algorithm, computer program and software in the context of patenting. The purpose of the chapter is to demonstrate the

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

2 Background 13

problems involved in defining these words by showing three different approaches to them.

The definitions presented here are from Merriam-Webster’s On-line Collegiate Dictionary (2001) as an example of everyday language, IEEE Standard Glossary of Software Engineering Terminology (1990) as an example of software engineering language, and Laddie et al’s The Modern Law of Copyright and Designs (2000) as an example of legal language.

2.3.1 Algorithm

The word algorithm is defined as follows in the three sources.

Merriam-Webster’s Collegiate Dictionary:

a procedure for solving a mathematical problem (as of finding the greatest common divisor) in a finite number of steps that frequently involves repetition of an operation; broadly : a step-by-step procedure for solving a problem or accomplishing some end especially by a computer

IEEE Standard Glossary of Software Engineering Terminology:

(1) A finite set of well-defined rules for the solution of a problem in a finite number of steps; for example, a complete specification of a sequence of arithmetic operations for evaluating sine x to a given precision.

(2) Any sequence of operations for performing a specific task

Laddie et al, The Modern Law of Copyright and Designs:

An algorithm is a set of rules for accomplishing a given logical process, and exists at a level of abstraction whose place in the hierarchy lies somewhere between a program specification (written in English) and the high level computer program itself (written in a computer language). An algorithm may therefore be thought of as a computer program, or part thereof, irrespective of the particular form of its expression.

The first two sources divide the meaning of ’algorithm’ into two: a mathematical algorithm and an everyday algorithm. A mathematical algorithm is considered a procedure for solving a mathematical problem, e.g. Newton’s iteration algorithm for finding the roots of an equation. An everyday algorithm is any step-by-step operation to specify a specific task, e.g. a recipe for making a cocktail.

An algorithm in the context of computer programs can be either a mathematical or an everyday algorithm. Laddie et al’s definition presented above wrestles with

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

2 Background 14

this problem by providing a definition somewhere between the two, by calling it a logical process.

Laddie et al’s definition also points out the relationship between a computer program and an algorithm. An algorithm being a set of rules lying somewhere between natural language and programming language; its expression being little closer to natural language, but implementation independent and therefore not the same as if it were expressed in a programming language.

The question whether algorithms should be patentable, therefore has a very different tone depending much on the definition used for the word algorithm.

2.3.2 Computer program

The word ‘computer program’ is defined as follows in the three sources.

Merriam-Webster’s Collegiate Dictionary:

a : a plan for the programming of a mechanism (as a computer) b : a sequence of coded instructions that can be inserted into a mechanism (as a computer)

IEEE Standard Glossary of Software Engineering Terminology:

A combination of computer instructions and data definitions that enable computer hardware to perform computational or control functions

Laddie et al, The Modern Law of Copyright and Designs:

… the word ‘program’ … should be taken to mean a series of instructions capable of being fed to a computer system, by typing in at a keyboard or in any other way, and, when so entered, of controlling its operation in a desired manner.

All the three definitions are quite similar and include a series or a sequence of instructions for controlling a mechanism, i.e. a computer. It is worth noticing that these define a computer program to be independent of the language of the instructions. For example, these definitions include computer programs presented in natural language, programming language or binary numbers. It can be argued that a computer able to read natural language would make the language used a programming language by definition, but it still remains that a computer program is a computer program irrespective of its presentation form, only restriction being that the computer program can be interpreted by a computer.

In intellectual property rights, protection is sought for computer programs. For this purpose it must be possible to present a computer program in such a form that two programs can be compared. In this context the answer to question “What

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

2 Background 15

is a computer program?” is not trivial; is it its specifications in natural language, its source code in a programming language, its binary form, or all of them.

2.3.3 Software

The word ‘software’ is defined as follows in the two sources. Laddie et al does not give a specific definition for this word.

Merriam-Webster’s Collegiate Dictionary:

Something used or associated with and usually contrasted with hardware: as the entire set of programs, procedures, and related documentation associated with a system and especially a computer system; specifically : computer programs.

IEEE Standard Glossary of Software Engineering Terminology:

Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.

These two definitions clearly state that computer programs are a part of software. It is easy to see that when words are put under precise inspection, patenting computer programs is not the same as patenting software. These two concepts are often used synonymously in public discussions, which is quite adequate as long as both parties of the discussions use the same definitions, but once the words become a part of legislation they must be clearly separated and defined.

2.3.4 Summary

The point of this section was to present different definitions for very basic words in computer science and engineering, and how these definitions vary depending on the context used. The three words presented have hundreds of, more or less official definitions, but the three sources were chosen to represent three different contexts: colloquial language, software engineering language, and juridical language.

The slightly different meanings between the words themselves and within the word’s own definitions demonstrate the problems encountered when they are used in legislation. Also these different meanings cause a lot of misunderstanding in debates on patenting computer programs. Usually software professionals understand the words used in quite a different way than IPR professionals or business professionals.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

2 Background 16

This thesis uses the word ‘computer program’ in the context of patent protection rather than the word ‘software’. The definition for the word ‘computer program’ used in this thesis is close to the definition by Laddie et al (2000).

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 17

3 Computer programs and patenting

This chapter gives an overview to what computer programs are. Firstly a software engineering view of computer programs is presented as one way of thinking about computer programs. This point of view has the advantage of evolving and developing along with the development in information technology. The view presented is by no means absolute, but quite sufficient in studying computer program patents.

The second view presented is the view of the European Patent Office. This view is based on the legislations and legal practice formed around the patenting system and its goals in the last few centuries. The legislation, rules and guidelines use terms and concepts known in everyday software engineering but their exact meaning can be surprising to a person not acquainted with the legal definitions.

The first section presents the software engineering view, the second section describes the legislation concerning patenting in Europe in a nutshell, and the third section describes what computer program inventions are in the European Patent Office.

3.1 A software engineering view of computer programs

Software engineering is making descriptions. Requirements are descriptions of the application domain and the problem to be solved. Specifications are descriptions of the interface between the machine to be built and the application domain. Programs are descriptions of the machine to be built in the application domain. (Jackson 1995)

But there is no one way of describing software or computer programs; there is no canon in software description. There are as many different ways to describe computer programs as there are programmers or developers. There are universal modeling languages used widely, but the informal line-and-box diagram is probably still often used in practice.

For patenting software there is also no universal method of describing computer programs. In a system where inventions are categorized into a taxonomy, one might expect strict rules for description to help the classification of inventions. Nevertheless, there are some requirements for the claims and teachings in a patent application, and they shape the interpretation of computer program structure in patent offices. These requirements for description and the invention itself are gone through in section 3.3. But there is nothing even close to a formal description language required to be used in patent applications.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 18

The lack of any unified presentation language is a problem in patenting computer programs. The problem arises when two similar patents are compared, or when patents descriptions are used as source of information: understanding of computer programs is hard, and when the description language can vary widely it is even harder. A similar problem in software engineering is filling the gap between specification and implementation in producing software - the problem is also understanding descriptions of computer programs. In software engineering the problem is tackled by using more or less formal description languages like the Unified Modeling Language.

To examine the way the EPO requires the software to be described, this thesis uses some basic terms and concepts from software engineering. As mentioned above, there are way too many different ways to describe software to cover all the ways of describing software. Therefore, in this thesis the basic approach is from Michael Jackson’s book “Software Requirements & Specifications, a Lexicon of practice, principles and prejudices” (1995). Jackson has approached software development by explaining what software is and what is its relationship to the world surrounding it. This approach is suitable for this thesis, where management, costs, efficiency and customer satisfaction of software are not key issues.

Jackson’s view is not widely known, and to support his view of software, another approach to explaining software is from the legal sciences: Samuelson et al. “A Manifesto concerning the legal protection of computer programs” (1994). The article was chosen as a reference in this thesis, because its approach to describing software takes into account the legal problems concerned with the nature of computer programs.

Both of these approaches, Jackson’s and Samuelson et al.’s, view computer programs as machines. This view is compatible with the fact that the European Patent Office is compelled to view computer programs as machines. This is due to lack of practice and tradition in handling computer program inventions, and the closest practice available for patent offices is to view computer programs as machines or processes.

To bring forth the inherent characteristics of software Frederick P. Brooks’s article “No silver Bullet: Essence and Accidents of Software Engineering” (1987) is used as a credible reference of the nature of software.

In the first section the meaning of the term application domain is discussed. Then the concept of computer programs as machines is introduced. After that the phenomena shared between a machine and the world surrounding it is presented briefly. Then the inherent difficulties of software according to Brooks are introduced.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 19

The concepts explained here are used in the following chapters as a reference to study the EPO terminology for describing inventions and the EPO practice concerning computer programs.

3.1.1 Application domain

The purpose of any machine is to be installed into the world and interact with that world. The part of the world in which the machine’s effects will be felt is the application domain. The application domain is specific to the problem to be solved by the machine. It is not a generic domain denoting a class of applications, as in the phrases the banking domain, or the telephone switching domain, but a specific domain like this company’s payroll system, or these particular suppliers, products and orders. (Jackson 1995)

The application domain contains the physical things surrounding the machine, but also the intangible things, e.g. pay scales, labor agreements and employment legislation for a payroll system. Also it is possible that some of the things in the application domain do not surround the machine, but make much more sense when thought to reside inside the machine, for example the source code programs to be compiled by a compiler machine. Application domain contains all the things affected by the machine and that have an effect on the machine. (Jackson 1995)

In addition to the concept of an application domain the concept of shared phenomena is an important part of any machine. Some of the phenomena in the application domain are shared with the machine. These shared phenomena, among the application domain and the machine, are the purpose and behavior of the machine; phenomena not shared with the machine belong to the application domain and phenomena inside the machine are internal workings not directly restricted by the application domain. (Jackson 1995)

For example, printing out an e-mail message is a shared phenomena between the machine and the application domain, namely the real world. Sending the printing command along with the data containing the e-mail message is internal workings of the machine. Posting the printed e-mail on a wall is a phenomena of the application domain, namely a phenomena between the user and the wall. The concepts of course depend on the scope of machine: if the machine was the computer without the printer then sending the printing command would be a shared phenomena with the application domain and the machine.

This long introduction to the concept of application domain is given to give the reader an understanding of what is meant by it as the term is used later in this thesis as the computer program inventions are discussed. It is easy to see that both application domain and shared phenomena are notions which are present when any kind of machine is described – a computer program or a mechanical machine.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 20

3.1.2 Computer programs are machines

Computer programs are machines as much as any other machine. Merriam-Webster dictionary (2001) defines a machine:

a mechanically, electrically, or electronically operated device for performing a task

Machines exist to bring about some behavior, to fulfill a purpose defined by the application domain of the machine (Samuelson et al. 1994).

Computer program machine’s behavior is its essential part. A computer program is quite useless without its behavior: it is behavior that is of value, it is what consumers and customers buy when purchasing a computer program. Computer program’s source code, documentation or user manuals are secondary to its behavior. It is also worth noting that computer program’s behavior is not equal to its description; a computer program may have different descriptions, e.g. source code, and still behave identically. (Samuelson et al. 1994)

Obviously a computer program requires a physical computer to be a machine. Without a computer the program would not behave and fulfill its purpose. With the technology advanced to the state it is, the actual computer that performs the tasks programmed to the computer program is not a major issue and it can be abstracted simply as a general purpose computer. The computer program patents presented in chapter 4 all define the computer involved with the invention in terms of processor, primary and secondary memory, bus, display etc. But it is easily seen that most of these descriptions can be bundled under the concept of a general purpose computer.

Of course the computer executing the computer program can also be a specific computer built solely for that purpose, but then the invention contains also the special computer, not only the computer program. In the context of patenting computer programs this not a separate issue: discussing patenting of computer programs for general purpose computers includes specific tailor-made computers.

A general purpose computer has three elements that turn it into a platform for executing computer programs: it is programmable, it can calculate and it has standard interfaces. A general purpose computer must be a calculator to execute the computer programs written, which are after all only arithmetic operations. To be able to alter the calculator’s behavior, without breaking the machine apart and building it again, it has to be programmable. When these two concepts are put together and the notion that it can calculate about its own programs, or reference to its own output as input, we get the essential idea of a general purpose calculator, or computer. (Jackson 1995)

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 21

For this machine to be really a general purpose machine, a machine that can take meaningful inputs and produce comprehensible outputs, it must have standard interfaces (Jackson 1995). For example, with a standardized serial port, a personal computer can control any machine imaginable when programmed to do so. When the computer becomes a general standardized tool, it is not an issue every time a computer program is developed; like when selecting the bait for a mousetrap, the mousetrap itself is not an issue as long as it functions accordingly and has standard interfaces.

Computer programs are similar to mechanical machines, although they are seldom treated so. Designing any machine requires industrial design work and study of the application domain: from identifying the constraints under which the machine will operate, to listing the tasks to be performed, to deciding what component parts to utilize in bringing about this behavior, to integrating the component utilitarian elements in an efficient way (Samuelson et al. 1994). These phases are the same irrespective if the machine to be built is a cuckoo clock or a computer program.

Thinking of software as a machine makes it clear that source code - text - is the medium in which a program is created, like the medium of traditional machines is steel, wood or plastic. The gears, screws, wires etc. of a computer programs are the algorithms and data structures used with the pieces of code binding them together. Like the components of a traditional machine the functionality of each computer program component must be carefully selected and inserted into the program to advance the overall purpose of the machine. (Samuelson et al. 1994)

Samuelson et al (1994) defines computer programs as having a dual character: being both writings and machines at the same time. They are writings as source code or specifications, and they are machines when they fulfill their purpose by functioning in a certain way. These two characteristics are also independent of each other: the same functionality or behavior can be achieved with different source code. This presents a major problem in intellectual property rights where copyright is the means for protecting writings but not machines, and on the other hand patent law has traditionally excluded texts, or printed matter from patentability and used for protecting machine inventions. (Samuelson et al. 1994)

3.1.3 Characteristic problems of computer programs

According to Brooks’s article “No Silver Bullet: Essence and Accidents of Software Engineering” (1987) modern software systems have four inherent difficulties: complexity, conformity, changeability, and invisibility. These characteristics are what make computer programs, or software, different from other machines, and they give some insight into understanding the problems rising from patenting computer programs.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 22

Brooks uses the word ‘software’ in his paper instead of ‘computer programs’. Software in Brooks’s paper can be understood to mean commercial computer program products or large systems consisting of several computer programs. But computer programs being the essential part of any software, as defined in section 2.2, these words can be interchanged without doing significant injustice towards Brooks’s theory.

Computer programs, and especially software systems are more complex for their size than perhaps any other human construct: No two parts are alike in a computer program; if there is need for several copies of one part it is implemented in a subroutine and called for whenever needed. Also computers themselves are very complex having very large number of states. Programs for computers have therefore orders-of-magnitude more states than computers do. Thirdly, scaling-up a computer program is not merely repetition of the same elements in larger sizes, but it is necessarily an increase in the number of elements. These elements, in most cases, interact with each other in a non-linear fashion causing the complexity of a computer program to increase much more than linearly. (Brooks 1987)

The problems rising from complexity as defined by Brooks (1987):

From the complexity comes the difficulty of communication among team members, which leads to product flaws, cost overruns, schedule delays. From the complexity comes the difficulty of enumerating, much less understanding, all the possible states of the program, and from that comes the unreliability. From complexity of function comes the difficulty of invoking function, which makes programs hard to use. From complexity of structure comes the difficulty of extending programs to new functions without creating side effects. From complexity of structure come the unvisualized states that constitute security trapdoors.

The second characteristic of computer programs is its conformity. Computer programs are machines built to conform with different application domains via their interfaces. These interfaces are artificial and more than often quite arbitrary, not defined by or derived from some law of nature, and they tend to change from time to time. In Jackson’s terms, computer programs are machines that must conform with their application domain, which is usually anything but formal. Computer programs are usually the first part of the system that must conform. This is due to its young age as a component in a system consisting of hardware and software elements, and the perception that software is the most conformable. (Brooks 1987)

The third characteristic is changeability. Manufactured things are seldom changed after manufacture; later models usually replace them or changes are implemented in later versions. Computer programs are quite often modified after manufacture, one reason being that computer programs embody their function and it is the function that feels most the pressure of change. Another reason for modifying computer programs is that the modifying is quite easy, and therefore they are

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 23

readily changed – sometimes with unpredictable results. The pressure to change is caused by the continually changing application domain, ”a cultural matrix of applications, users, laws, and machine vehicles” as Brooks describes it. (Brooks 1987)

The fourth characteristic listed by Brooks is invisibility. According to him, computer programs are invisible and unvisualizable, which means that describing them is more difficult than describing traditional machines. In Brooks’s own words:

The reality of software is not inherently embedded in space. Hence, it has no ready geometric representation in the way that land has maps, silicon chips have diagrams, computers have connectivity schematics. As soon as we attempt to diagram software structure, we find it to constitute not one, but several, general directed graphs superimposed one upon another. The several graphs may represent the flow of control, the flow of data, patterns of dependency, time sequence, name-space relationships. These graphs are usually not even planar, much less hierarchical.

Brooks’s four listed problems can be analyzed in the context of computer program patents. One question rising is how can the complexity of computer programs be seen in patents. When this complexity is paired with invisibility, how are computer programs described in patent applications, and how is this problem tackled? Also conformity and changeability pose some questions in patenting computer programs: if computer programs are under pressure to conform and readily changed, how can this be seen in patent application?

3.1.4 Summary

This section presented some characteristics of computer programs and common problems rising from them. The following concepts were introduced and the patents in chapter 4 are studied using these terms and ideas.

Application domain is the world into which the machine is built and where it interacts. A machine has a purpose and behavior in the application domain, which it fulfills by sharing phenomena with the application domain. Figure 2 depicts the relationship between the machine and the application domain.

A computer program is a machine as much as a car, a computer, a clock or a paper factory is a machine. It is a machine whose medium of construction is text. The functional components of this machine are algorithms and data structures. The machine’s essential part is its behavior, which can be achieved by running the program on a computer.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 24

Figure 2. The machine shares some phenomenas with its application domain.

Computer programs have a dual character, not present in any other machines. They are both machines that behave to fulfill a purpose and they are writings that build up the machine. Intellectual property protection has traditionally separated these two so that copyright is meant for protecting writings and patents are meant for protecting machines.

Computer programs have inherent problems that are not present in traditional mechanical machines: computer programs, or software is complex, conformable, changeable and invisible. These problems should be borne in mind when discussing patenting of computer programs.

3.2 Patenting in the European Patent Office

This section presents the basics of European patenting, focus being on computer program patenting, and how the application and appeals procedure for European patents works. The decisions studied later in this thesis is based on the official proceedings or bureaucracy presented in this section.

In the European patent system, the definition of patentable subject matter is in the European Patent Convention (EPC 2000) of 1973, which explicitly states that computer programs “as such” are not patentable. Especially its Article 52 is of most importance to patenting of computer programs.

The purpose of the EPC is to unify patenting in Europe and its preamble states. The desire of the contracting twenty states is according to the EPC (2001):

… to strengthen co-operation between the States of Europe in respect of the protection of inventions, that such protection may be obtained in those States by a

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 25

single procedure for the grant of patents and by the establishment of certain standard rules governing patents so granted.

The EPC also established The European Patent Organisation which comprises of its legislative body, the Administrative Council, and its executive body, the European Patent Office (abbreviated EPO). (EPO 2001)

The procedure of applying for a patent advances so that the patent applications are examined by the EPO Examination Division for patentability, novelty, inventive step and industrial applicability. If a European patent is granted, competence is transferred to the designated contracting states, where it affords the same level of legal protection as a national patent. Enforcement of the patent laws is by means of the national courts using national procedures. (EPO 2001)

Patents applications in the EPO must have designated states in which the patent will be valid. These states must be members of the European Patent Organisation. Once the patent application is accepted in the EPO it is sent to the states designated in the application for acceptance. The acceptance is only a formal procedure which does not involve any searches or studying of the patent. Once the patent is accepted in a designated state it is treated as a local national patent.

The patent application is published 18 months after the application was filed. Opposing arguments to published patent applications are submitted to the EPO Opposition Division within nine months of the date of grant. Examination and Opposition Division’s decisions can be appealed to the Board of Appeals. Board of Appeals decisions can then be appealed to the Enlarged Board of Appeals. Figure 3 summarizes the appeal procedure. (EPO 2001)

Figure 3. The application and appeal procedure. First the patent application is filed to the EPO. There it goes to the Examination Division who examines the application for patentability and publishes it. If the patent application is opposed by anyone it goes to the

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 26

Opposition Division for respective procedures. The patent applicant can appeal the decisions made by either the Examination Division or the Opposition Division. The appeals, if accepted, go to the Board of Appeals for further study. In some cases the Board of Appeals’ decision can be applied to the Enlarged Board of Appeals but that is very rare, and therefore the Board of Appeals is in practice the highest authority on patentability in the EPO.

It is worth pointing out that patents granted in by EPO are valid only in the states designated in the application and not anywhere else. Therefore patent applicants must apply for another patent if they want a patent for example in the United States. Nevertheless, a patent granted by the EPO, or any other patent office, prohibits any other inventor patenting the same invention elsewhere: a patent granted by some other patent office is prior art and a patent application can be rejected on that basis. In other words, a patent granted in the United States prohibits in practice the patenting of the same invention by other inventor in the EPO, and vice versa.

For examining the patent applications EPO has produced Examination Guidelines (Guidelines 2001) that help the examiners to interpret the EPC.

In this section, first the definition of patentable inventions under the EPC is presented. Then the Implementation Regulations and EPO Guidelines are presented. It is worth pointing out, that these are the official documents used by the Examination Division and the Board of Appeals. In addition to these the decisions of the Board of Appeals have a major role in interpreting the juridical documents. The decisions are analyzed in chapter 4 of this thesis.

3.2.1 Patentability: European Patent Convention Article 52

In its Article 52 the EPC states what is patentable and what is not. The first paragraph of the Article, referred as 52(1), states as follows:

1) European patents shall be granted for any inventions which are susceptible of industrial application, which are new and which involve an inventive step.

In Article 52(1) the concepts of industrial application, new, and inventive step are presented. A detailed analysis of these words in the context of computer program inventions is not within the scope of this thesis, but nevertheless these words have an important role in examining an invention for patentability. The invention must be described so that its industrial application, novelty and inventive step can be easily identified.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 27

It is worth mentioning that Article 52(1) does not define what is an invention, but only states that patentability has four basic requirements: an invention, industrial application, novelty, and inventive step. From these it has been derived in practice that to be an invention, in the context of Article 52(1), it has to be technical. Therefore, the four requirements could be listed as technicality, novelty, inventive step, and industrial applicability. The key term here is technicality.

The second paragraph of the Article, referred as 52(2), states what is not patentable subject-matter, i.e. not technical:

(2) The following in particular shall not be regarded as inventions within the meaning of paragraph 1:

a) discoveries, scientific theories and mathematical methods;

b) aesthetic creations;

c) schemes, rules and methods for performing mental acts, playing games or doing business, and programs for computers;

d) presentations of information.

This paragraph of the Article is the most important part of the EPC considering computer programs. As quite explicitly stated, programs for computers are not regarded as inventions, but as it can be seen from the EPO decisions presented in chapter 4, the interpretation of 52(2) part c) is not trivial: computer programs can be patented in the EPO.

The third paragraph of the Article, referred as 52(3) states as follows:

(3) The provisions of paragraph 2 shall exclude patentability of the subject-matter or activities referred to in that provision only to the extent to which a European patent application or European patent relates to such subject-matter or activities as such.

This paragraph of the Article limits the exclusions stated in 52(2) to inventions that are subject-matter or activities listed in 52(2) as such, i.e. mathematical methods as such, programs for computers as such etc. The interpretation of 52(3), in other words when subject matter is considered to be as such, is also of uttermost importance to patenting computer programs in the EPO.

Article 52 of the EPC is the definition of patentability, i.e. technicality, and therefore the basis for studying patents for computer programs.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 28

3.2.2 Rules 27 and 29 of the Implementing Regulations

These two Rules are part of the EPC’s Implementing Regulations (1999). They define how an invention should be described. Rule 27 states the content of the description and Rule 29 states the form and content of the claims.

Especially, Rule 27 states that in the patent application the technical problem and its solution must be described:

c) disclose the invention, as claimed, in such terms that the technical problem (even if not expressly stated as such) and its solution can be understood, and state any advantageous effects of the invention with reference to the background art;

In Rule 29 the concept of technical features is presented:

The claims shall define the matter for which protection is sought in terms of the technical features of the invention.

The concept of technical problem and its solution and the concept of technical features, in the context of computer programs, is discussed in more detail later in this thesis as an important part of computer program structure.

3.2.3 Guidelines for Examination in the EPO

The Guidelines give instructions as to the practice and procedure to be followed in the various aspects of the examination of European patent applications in accordance with the EPC and its Implementing Regulations. The Guidelines do not constitute legal provisions, and their application to individual patent applications or patents is the responsibility of the examining staff. (Guidelines 2001)

In addition to pointing out the four requirements for patentability stated in Article 52(1), it states two implicit requirements:

The invention must be such that it can be carried out by a person skilled in the art.

and

The invention must be of “technical character” to the extent that it must relate to a technical field, must be concerned with a technical problem, and must have technical features in terms of which the matter for which protection is sought can be defined in the claim.

The Guidelines also go into more detail in explaining Article 52(2), i.e. what is excluded from patentability. According to the Guidelines, the excluded things

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 29

stated unpatentable have in common that they all are either abstract or non-technical. The Guidelines classify discoveries, scientific theories, and aesthetic creations as non-technical and therefore not patentable. Mathematical methods, schemes, rules and methods for performing mental acts, playing games or doing business are classified as being abstract or intellectual character, and therefore not patentable.

The Guidelines, the EPC nor the Implementing Regulations give no rationale for excluding computer programs or presentations of information; they are only explicitly stated to be excluded from patentability as being not technical.

As the Article 52(3) states, inventions belonging to the list of excluded things are excluded only if they relate to excluded subject-matter as such, i.e. aesthetic creations as such, discoveries as such etc. However, if the invention is found to contribute to a technical art, it might be patentable although it relates to excluded subject-matter as such. The Guidelines give an example that a discovery of a substance occurring in nature which is found to have an antibiotic effect, may be patentable – the antibiotic effect is considered a contribution to a field not excluded from patentability. Also physical processes and products applying non-technical or abstract methods may be patentable.

It can be seen that the problem lies in deciding when an invention relates to excluded subject-matter as such and when it does not. And when it relates to excluded subject-matter as such, does it contribute to a non-excluded field.

The Guidelines also point out that

testing whether there is an invention within the meaning of Article 52(1) is separate and distinct from the question whether the subject-matter is susceptible of industrial application, is new and involves an inventive step.

More on technical character and technical contribution in section 3.3.

3.2.4 Summary of patentability in the EPO

This section summarizes the three documents presented above: EPC Article 52, EPC Implementation Regulations Rules 27 and 29, and the Guidelines for Examination in EPO. In this section the requirements for susceptibility of industrial application, novelty and inventive step are not considered in detail.

For an invention to be an invention according to Article 52(1), it must not relate to any of the following as such: discoveries, scientific theories, mathematical methods, aesthetic creations; schemes, rules and methods for performing mental acts, playing games or doing business; programs for computers, or presentations

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 30

of information. These are not considered to be technical and therefore they are not patentable.

The invention considered as a whole must have a contribution of technical character, i.e. it must relate to a technical field, it must be concerned with a technical problem and its solution, and it must be claimed by its technical features. Also the invention must be such that it can be carried out by a person skilled in the art.

On the matter of patentability of computer programs the EPO Board of Appeals has commented in a recent case (T 0935/97 1999).

...programs for computers must be considered as patentable inventions when they have technical character.

This is seen by the Board to be consistent with the Articles 52(1), 52(2) and 52(3). The problem is therefore the meaning of the word "technical character". This view of the Board can be seen in the Board’s patent cases presented in chapter 4 of this thesis. The concept of technical character is discussed in the following section 3.3.

The definitions of patentability in the EPO has not been questioned previously, because there have not been so much demand for patent protection for computer programs. Computer programs is a field of technology that has no firm tradition or practice in patenting, and because of the explicit exclusion in Article 52(2) it is clearly a borderline case of patentability. In practice, some computer programs are patentable and some are not, and the rationale of these decisions is anything but clear. One of the reasons for this ambiguity is the lack of well-defined vocabulary, as mentioned in section 2.3. Chapter 4 goes through the Board of Appeals’ decisions that have shaped the practice of patenting computer programs in the EPO.

3.2.5 Differences in patentability in U.S. and Japan

Of the three major parties in patenting, the approach to computer program patents adopted by the EPO is considered the most strict in explicitly stating that programs for computers are not patentable. Also in practice the EPO is thought to be hardest of the three patent regimes.

U.S. patent law is clearly less restrictive on what is patentable than EPO. The United States is probably one of the most favorable jurisdictions when it comes to the protection of computer related technology by means of patents. (Protection of Software-related Inventions 1996)

The Japanese approach to patenting computer programs is similar to the European approach. The Japan patent law requires patentable inventions to use a law of

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 31

nature, which the standard contrasts with laws of man, such as the rules of chess. The Japanese approach is nevertheless, not quite as restrictive since the Japanese examiners appear to be more apt to find that a claim for a computer program related invention utilizes a law of nature than an EPO examiner will find that essentially the same claim is directed to an invention having technical character. (Protection of Software-related Inventions 1996)

Simply put the U.S. patent law is in practice the most lenient of the three, EPO being the strictest and Japanese patenting lying somewhere between the two. But similar to all these patent laws are the problems they are facing with computer programs being a gray area in the border of patentability.

3.3 Invention descriptions and technicality

This section goes through the way EPO describes inventions and a way to interpret them with computer programs. EPO does not explain in detail the way a computer program invention should be described; there is no requirement for certain notation or certain figures, e.g. a logical view, a process view, development view, or physical view like in the 4+1 architecture model (Kruchten 1995). This analysis and decompilation is based on the EPC Implementation Regulations Rules 27 and 29 (Implementing Regulations 1999), the EPO Examination Guidelines (Guidelines 2001) and few EPO Board of Appeals’ decisions.

Rule 29 states that the claims defining the matter for which protection is sought must be described in terms of the technical features of the invention. Rule 27 requires the invention to be described so that the technical problem and its solution can be understood. The Examination Guidelines add that the invention must be of technical character, i.e. it must relate to a technical field and the attributes mentioned in the Rules.

As mentioned previously, and is evident from the paragraph above the meaning of the word technical is important in patenting in the EPO. To put it simply: technical inventions can be patented, and non-technical inventions can not be patented. This section presents the official answers to what is technical and what is not. Especially sections 3.3.5 to 3.3.9 discuss what is technicality in the EPO.

In addition to the official documents concerning the structure of an invention a reference is also made to literature on the subject (Beresford 2000, Liesegang 1999, van den Berg 1996, Newman 1997).

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 32

3.3.1 Patentable invention structure

A patentable invention is described by its technical features. The technical features are the structural units of the invention and the functional interactions between them. In the case of traditional mechanic devices these structural units are chassis, wheels, levers, connectors, transmissions etc. (Beresford 2000)

When these technical features are put together they achieve a function – the function of the invention. Each technical feature has a sub-function of its own that contributes to the overall function of the invention; if a technical feature has no sub-function it is irrelevant in the context of patenting. (Beresford 2000) A sub-function may be indirect, so that it does not directly contribute to the overall function, but it is required for the whole invention to work at all.

Figure 4. Structure of an invention in the context of patenting.

In addition to having a function, an invention should have an advantage over previous inventions of similar kind. This advantage is undoubtedly the invention’s ultimate purpose. Similarly to the function of an invention, each technical feature contributes to the overall advantage of the invention. (Beresford 2000). Figure 4 summarizes the structure of an invention.

For example, a mechanical clock has a spring that moves cogwheels whose certain size achieve the function of rotating the hands in a certain speed. The items are the spring, cogwheels and the hands. Their interaction is the transferring of force, and the achieved function is the moving of hands. Clearly, the moving of hands in a certain speed is important to the clock and achieving a clock whose hands move at the correct speed all the time might be an advantage to previously manufactured clocks.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 33

3.3.2 Invention elements, technical features

Each structural unit of an invention has three attributes: first of all its structure, e.g. size, form, material, circuit diagram etc., secondly it has a function contributing to the overall function of the invention, and thirdly it has an advantage or purpose contributing to the overall advantage of the invention. (Beresford 2000)

To summarize: structural units have a structure that enables them to perform a function to achieve an advantage. Figure 3 depicts the situation.

Figure 5. Three attributes of an item in the context of patenting.

For example, the spring of a mechanical clock has a certain structure that enables it to uncoil. The function of the spring is to provide the force for moving the hands of the clock. The advantage of the spring is that without it the whole clock would not work. If a new clock was made where the structure of the cogwheels was the novel and inventive step, the spring would still contribute to the overall advantage, because without it the new and inventive cogwheels would be useless.

3.3.3 Computer program invention structure

Neither the EPC Implementation Regulations nor the Examination Guidelines give any specifications for a computer program invention structure. Therefore, the structure of a computer program must be described in the terms of inventions from other fields of technology: items and interactions, and the advantage or function they achieve. It can be argued that computer programs are different from traditional machines where structure implies function, nevertheless computer programs must be described and handled according to the same rules as other patentable inventions because there are no special rules for them.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 34

This section gives a way of presenting computer program inventions in the context of patents, and it may seem unimportant and queer in the context of software engineering. The purpose of this and the following section is to describe the items and structures involved in computer programs in the terms and practice of the EPO.

A computer program invention has three distinguished parts due to its nature: the code itself which is a list of instructions, the computer that provides the platform by executing the instructions, and the application domain that uses the computer program via the computer. When the code and the computer are thought as one, a computer program is a machine performing a task in the application domain like any other machine. Figure 6 shows this division of a computer program invention.

Figure 6. Main parts of a computer program invention.

The structure of the computer, a general purpose computer is a simplified von Neumann machine (Patterson and Hennessy 1998). It has a CPU for calculating the instructions given and it has a memory that stores the program and the data, everything else is considered peripherals that should be defined separately when they form an important part of the invention. The peripherals are connected to the memory by a bus. Figure 7 shows the structure of this simple machine.

Figure 7. Structure of a simple computer machine.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 35

3.3.4 Computer program invention elements

In a traditional machine, like in electronics the structural elements are the amplifiers, filters, etc. as presented in sections 3.3.1 and 3.3.2. In a computer program invention the elements are the modules and the i/o data structures (Beresford 2000). In addition, the concept of main program is introduced.

The main program is the central program that contains the top-level algorithm of the program. This top-level algorithm is divided in smaller algorithms implemented outside the main program by the modules. This assumes the hierarchical structure of computer programs. The main program can be considered as the backbone of the whole program that connects the modules together. For practical purposes, this special part of the whole program has been selected to be an element of its own. It can also be thought as one module among others.

The modules of the computer program are the elements that actually implement the commands given by the main program. The modules can be thought as objects, sub-functions, or libraries. The use of modules in a computer program is not necessary, the whole program could be programmed into the main program, but it is very inconvenient and never used in practice due to the hierarchical structure of designing and implementing computer programs. Also it is possible and very probable that the modules themselves have sub-modules of their own.

The third part is the input and output data structures (i/o data structures) used. In addition to the actual structuring of the data, e.g. a linked list, a heap, a hash table, etc., the data structure in this context includes also the nature of the data, in other words the meaning of the data beyond pure numbers or letters. The nature of the data is directly related to the shared phenomena between the computer program and the application domain. All the interaction between the computer program and the application domain is the input and output of data. Even commands given to the computer program while it is running are data: a distinction is made between commands written prior to compilation and commands given as input - the former are commands contained in either the main program or the modules, the latter are data to the program.

Data structures, in the wide sense, are the interface between the computer program and the application domain. Figure 8 depicts this structure.

The computer program invention’s elements can be summarized in the terminology of patenting as being modules having a structure that enables them to perform a function on the data to achieve an advantage. In comparison, the traditional invention’s elements can be summarized as being items having a structure that enables them to perform a function to achieve an advantage (Beresford 2000).

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 36

Figure 8. Computer program invention structure.

3.3.5 Technical contribution and technical character

As mentioned previously, the Guidelines for examination require an invention to be of ‘technical character’, and the concept of technicality has in a major role in patentability. The Guidelines also mention that the real contribution of the invention must be of technical character:

… the real contribution which the subject-matter claimed, considered as a whole, adds to the known art. If this contribution is not of a technical character, there is no invention within the meaning of Art. 52(1).

‘Technical contribution’ can therefore be understood to mean a contribution of technical character, and the meaning of the term technical character is gone through in the following sections.

The concept of an invention making a technical contribution to the known art has risen to be a significant concept and argument when examining the patentability of computer programs. This is due to the Guidelines’ statement presented above and the EPO decisions which state that if the claimed subject-matter makes a technical contribution to the art, patentability cannot be denied on the ground that a computer program is involved (Liesegang 1999). In other words, if an invention makes a technical contribution it can be patented, even if it is a computer program.

It is almost obvious that an invention should contribute to a technical field; one reason for having a patent system is to expand the knowledge of science. The

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 37

reason for focusing on technical contribution is not so much should the invention contribute or not, but can the test for technical contribution in finding patentability be separate from tests of novelty and inventive step (Liesegang 1999). This separation of examinations for patentability or technicality, and the examination for novelty, inventive step and industrial applicability is required in the Examination Guidelines as mentioned in section 3.2.3.

Separating examinations for contribution and for novelty and inventive step produces a contradiction: if testing for patentability (technicality) must be separate from testing for novelty and inventive step, how can “contribution to the known art” act as an indicator for patentability (technicality)? The word ‘contribution’ implies that the current state of the art must be identified in some way and the invention’s technical characteristics evaluated in that context. Is it possible to analyze an invention’s contribution to a field of technology if its novelty nor its inventive step can be investigated?

The EPO Board of Appeals has stated in one of its more recent cases (T 0935/97 1999) that determining the technical contribution of an invention is more appropriate for the purpose of examining novelty and prior art than for deciding on possible exclusion under Article 52(2) and (3), i.e. patentability of the invention.

The Board of Appeals did also comment on the concept of technical character in the same case (T 0935/97 1999). The Board stated that programs for computers cannot be considered to have technical character for the very reason that they are programs for computers. This means modifications in hardware deriving from the execution of the program cannot per se constitute to technical character. In other words, modifications in hardware mean technical transformations and handling of electricity in computer hardware. Therefore, the mere changing of electric signals in computer chips is not enough to make a computer program invention technical.

Technical character should therefore be looked for in the further effects deriving from the execution of the program, not just the effect of changing the electrical currents in hardware. Consequently, a patent may be granted not only to an invention where a computer program manages an industrial process or the working of a piece of machinery, but in every case where a computer program is the only means, or one of the necessary means, of obtaining a technical effect.

From the regulations and the Board decisions an interpretation of the meaning of ‘technical character’ can be derived. According to Liesegang (1999) technical character of a computer program invention can manifest itself as:

• a technical problem to be solved

• technical features forming the solution to a problem

• a technical effect achieved with the solution of the problem

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 38

• technical considerations or technical knowledge which are necessary to provide a computer-compatible solution

These listed attributes, technical characteristics, are considered in more detail in the sections below.

A technical contribution can be understood to be a contribution to a technical field, i.e. a field not excluded by Article 52(2), in the form of one of the characteristics listed above. In other words, a computer program invention is considered technical, and therefore patentable, if it has at least one of these technical characteristics.

3.3.6 Technical problem and solution

Rule 27 c) of the Implementing Regulations states that an invention must be disclosed so that the technical problem and its solution can be understood (Implementing Regulations 1999). Describing a problem and presenting a solution, is considered a contribution to the known art. As mentioned before, to be a contribution, the problem and its solution must be contrasted to the current state of the art; a known solution to a known technical problem is not a contribution.

This requirement for presenting a technical problem and how the invention solves the problem can be the sole basis for patentability for computer programs. The EPO Board of Appeals has stated in T 0115/85 (1988) that

Even if the basic idea underlying an invention may be considered to reside in a computer program, a claim directed to its use in the solution of a technical problem cannot be regarded as seeking protection for the program as such within the meaning of Article 52(2)(c) and (3) EPC.

In other words, even if the invention is of excluded subject-matter, a computer program in the case above, if it solves a technical problem it cannot be thought as a computer program as such, and therefore it is patentable. Therefore, a computer program that solves a technical problem can be patented. A problem is considered technical if it relates to a technical field, i.e. a problem is from a field not excluded in Article 52(2) (Newman 1997). There are no regulations or statements that define the concept of technical problem any further. In chapter 4, the decisions presented give a view to the practice.

Van den Berg (1996) points out that a problem arises in describing an invention in the patent application to solve a technical problem. The problem described by the applicant is naturally subjective and in the interests of the applicant, and therefore the examiner should identify the objective problem solved by the invention. In forming this objective problem, van den Berg states that formulating it requires

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 39

taking prior art into account and thus contradicting the Guidelines’ principal of separating the studies for patentability and prior art. This subjective way of formulating the problem should be borne in mind when reading patent applications.

3.3.7 Technical effect

A computer program invention must be described by its structure and functions, but also by the technical benefits which it achieves (Beresford 2000). This was presented in sections 3.3.1 and 3.3.2.

One of the most easily comprehended characteristics of a technical invention is its technical benefits, or technical effect. It is easy to understand that a machine working faster, using less resources, being easier to control, more reliable, and so forth, makes a contribution to the art, i.e. is inventive in the everyday meaning of the word.

In the case of computer program inventions these technical effects can be, for example: a program, a data structure or a file structure that takes less memory space; a program which operates more quickly; improved control facilities for a human operator; a program which makes it possible to perform by computer something which previously could only be done manually or mentally; or a computer program which is more reliable (Beresford 2000). These are undoubtedly highly inventive developments that contribute to the field of technology.

For example, a computer program that uses less primary memory than another computer program of the same function can be said to have an advantage over the other program. This advantage is the technical effect of using less primary memory.

The technical effect of a computer program is beyond the mere fact that the program inevitably controls electrical processes and electrical circuitry within a physical apparatus. (Beresford 2000)

Rule 27 states that the invention must be described by the technical problem and its solution. Is it possible to have a technical effect without it solving a technical problem? Isn’t there always a technical solution to a technical problem involved when a technical effect is present?

Rule 27 can be interpreted so that there always must be a technical problem and its solution, and therefore it can be argued that if a technical effect is present, it must always be a solution to some technical problem.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 40

3.3.8 Technical features forming the solution

A patentable invention must be described by its technical features: Rule 29 of the Implementing Regulations requires that the claims of a patent application must define the matter in terms of the technical features of the invention. The technical features are the structural units of the invention and the functional interactions between them (Beresford 2000) as defined in presented in sections 3.3.1 and 3.3.2. When put together, these features achieve a function, and this function must be a solution to a technical problem in order to be patentable.

Because of Rule 29 mentioned above, all inventions must be described by their technical features and therefore the existence of technical features should be always present. It is with these features that the invention can be distinguished from prior art: a feature that is new, a feature that makes an inventive step, or a feature that makes the invention industrially applicable.

A technical feature itself is nothing, but the advantage that the feature achieves justifies its existence. Therefore it can be said that a technical feature must have an advantage or an effect. The advantage can be the effect which makes the invention patentable, or it can be an indirect effect that must be present to make the invention function at all.

The example of a simple mechanical clock from section 3.3.2 can be used here. The clock’s features are the spring, the cogwheel and the hands. Let’s assume that hands of the clock represent the hands of Mickey Mouse. Now the spring, the cogwheels, and the hands as mere pointers are technical features, but the feature that the hands represent the hands of a famous cartoon character is not a technical feature. Therefore, the description of the hands of the clock as the hands of Mickey Mouse is irrelevant to patenting the machine, and the novelty, inventive step or industrial applicability can not lie in the feature that the hands represent the hands of Mickey Mouse, because the feature is not technical.

What do these technical features mean in computer programs is a difficult question. Because there are no clear definitions of the matter and the practice in the field of computer program patents is not mature, the answer to the question remains ambiguous. In chapter 4, the Board of Appeals decisions represent the practice on the matter.

3.3.9 Technical considerations, technical knowledge

The requirement for technical considerations in implementing an invention is a new concept formed by the decisions of the Board of Appeals. Unlike the three attributes presented above, this technical characteristic is even more abstract and not easily identified.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 41

The EPO Board of Appeals has stated that if technical considerations, i.e. technical skills or technical knowledge, have to be dealt with in order to implement an invention, it indicates that there is a technical problem to be solved (T 0769/92 1994). This is based on the fact that these technical considerations had to be taken into account in implementation and therefore a technical problem was solved.

In other words, technical character is present if there are technical skills used to implement the invention.

To use the mechanical clock again as an example, it is quite easy to understand that the clock is technical because implementing it requires some technical considerations, e.g. the size of the cogwheels in relation to the size of the hands. On the other hand, it would seem logical that implementing the hands of Mickey Mouse as the hands of the clock would not require technical considerations, but artistic considerations or artistic skill.

3.3.10 Invention as a whole vs. novel feature

A lot of discussion has been made on the EPO Board of Appeals’ decisions to examine the inventions either as a whole or only the invention’s novel feature (Newman 1997, Liesegang 1999, van den Berg 1996, T 0769/92 1994). According to the Guidelines (2001), the examination for patentability (i.e. technicality) should be done separate from the examination for novelty, inventive step and industrial applicability.

Examining an invention from the point of view of the invention’s new technical features means that first the invention’s technical features are identified, and then the new and inventive features are taken under consideration to determine their advantage over the state of the art. If the advantage is found to be non-technical the invention is not patentable, i.e. if the novel technical feature is found to be of excluded subject-matter it cannot be patentable (as in the example of Mickey Mouse hands in section 3.3.8.). This kind of approach is very discouraging for patenting of computer programs, because usually the novel technical feature is of excluded subject-matter, namely a computer program. This strict point of novelty approach has not been used in the last two decades. (Newman 1997)

On the other hand, the whole contents approach examines the invention as a whole, not separating the new and inventive parts. If the whole of the invention is found to have technical character or not being of excluded subject-matter, it is considered patentable. (Newman 1997)

Newman (1997) categorizes the technical effect and technical problem tests as invention as a whole approaches, and novel technical feature test as a point of novelty approach.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

3 Computer programs and patenting 42

When the Board of Appeals latest decisions concerning computer programs are viewed it seems that the whole contents approach is more popular, as the invention is treated as a whole containing all of its features.

3.3.11 Summary

Newman (1997) defines the first three characteristics of technical nature as three separate tests of patentability: test for technical effect, test of overcoming a technical problem and the test of novel technical feature. If one of the tests is passed then the invention is patentable subject-matter. Of course the invention must also be new, nonobvious and susceptible of industrial application for the patent to be granted.

These tests for patentability can be divided into two categories: looking at the invention as a whole or looking only at the novel feature of the invention (Newman 1997).

The four characteristics presented above, technical problem, technical effect, technical features and technical considerations, are not absolute but overlap. A technical problem may be the achievement of a technical effect, for example the problem of having limited amount of memory can be solved by the technical effect of using less memory space. It can also be argued that a technical feature must by definition have a technical effect or solve a technical problem; what is it that makes a feature technical?

The concept of technical considerations or technical knowledge required in implementing the invention is kind of an oddball among the other three characteristics. If technical considerations mean engineering then the scope of patentable inventions is much larger. For example, all computer programs require software engineering in one way or the other. Clearly the concept is in need of an unambiguous definition, and is too abstract in its colloquial form.

The terms presented in this section are very important in understanding the decisions of the Board of Appeals. The Board bases all its decisions and grounds on the concepts presented above.

Appendix A of this thesis present Finnish translations of the key words in defining technicality in EPO practice.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 43

4 Examples of EPO patents

This chapter presents the main data of the thesis, i.e. the decisions of the EPO Technical Board of Appeals on computer program inventions. The inventions are presented and the respective decision of the Board analyzed. In the end of this chapter three examples of mechanical patents are presented to show the contrast in EPO practice between computer program inventions and mechanical inventions.

The EPO Board of Appeals’ decisions were chosen because they represent the highest authority of the EPO, and the practice of granting patents is shaped by these decisions. To form a picture of the practice or convention involved in patenting computer programs in the EPO, the Board of Appeals’ cases are the most important source.

The role of the Board of Appeals’ decisions is an example of a larger juridical dilemma. In legal sciences proprietary right, copyright, and patent right are not unambiguously defined; their practice is formed around a consensus rather than a explicit definition. This results in a gray area instead of distinct borders around these concepts. To clarify this gray area an authority is required to help solve cases where the consensus is not sufficient. The Board of Appeals represents this kind of authority in making decisions in the gray area of patenting computer programs.

The chapters above have presented the terms and concepts involved in the decisions and the inventions themselves. The main terms are the attributes of technical character, i.e. technical problem, technical effect, technical features and technical considerations. The descriptions of the inventions are summarized because the descriptions themselves range from three pages to over hundred pages.

Some of the inventions in this chapter are claimed as systems, apparatus, methods or products. These differences are juridical more than technical and therefore not emphasized: the inventions are all viewed as computer programs.

Appendix B lists all the inventions of this chapter in a single table. For each invention its technical character is stated and a comment from the Board of Appeal’s decision. Chapter 5 of the thesis concludes the observations made in viewing the inventions.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 44

4.1 EPO Board of Appeal cases

This section presents examples of computer program patents, or patent applications. All of them were appealed to the EPO Technical Board of Appeals (later referred to as the Board) after being rejected by the EPO Examination Division or opposed by the Opposing Division. These patent applications are a good example because they have been commented by the Board and therefore give an excellent view of EPO’s practice.

The reader should be warned that the Board has no clear practice in dealing with computer program inventions. If the Board’s decisions and reasoning seem to vary or contradicted it is a correct observation. One objective of this thesis is to demonstrate the ambiguity of the Board’s practice. Also, the reader should at this point understand that the words patentable and technical are used synonymously because their meaning, in practice, is the same.

It is worth mentioning that the patent applications presented in this section are somewhat old when compared to the rapid development in computer programs. Some of the patent applications and respective Board of Appeals cases are significant to the patentability of computer programs although they are five to twenty years old inventions. The cases themselves are a bit more recent because it takes few years for a patent application reach the Board of Appeals due to bureaucracy of the EPO. Because of the age of the inventions presented here they may seem obvious or trivial, but it should be borne in mind that these decisions are not studied for novelty, inventive step or industrial applicability, but for patentability or technicality as it is defined in the previous chapters.

The cases and their respective patent applications are presented by their application domain or general field of use. These categories are by no means absolute and some of the cases overlap with several categories.

For each invention its summary is presented as it is in the original patent application. Also, one picture from the original application is shown as an example of the way computer program inventions are depicted, and they should not be viewed as clarifications to the patent descriptions. The original patent applications have a wide range of pictures varying from circa three to over dozen figures and illustrations, and presenting only one of them for each invention does injustice to the invention if viewed as explanations. The purpose of the pictures included in this thesis for each application is to vivify the text and show a contrast between pictures of computer program inventions and traditional mechanical inventions.

All the EPO cases with their file numbers and corresponding patent applications are listed in the References part of this thesis.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 45

4.1.1 Technical and mental processes

As mentioned in previous sections the EPC explicitly states that computer programs as such cannot be patented. Nevertheless, the EPC does not define what is a computer program and what is not. The task of defining this fine line was left to the decisions of the Board. In its decisions the Board has made a distinction between technical processes and mental acts; the former being patentable and the latter not. The mental acts include any method falling into the category of excluded things listed in Article 52(2). This section lists some patents that have been judged by the Board to be of either category.

4.1.1.1 Vicom / Computer-related invention

One of the first decisions in the EPO to make a statement on computer program inventions was T 0208/84 Vicom/Computer-related invention (1986). The patent application (EP 0005954 1979) was for a system of digital image processing, which provided more efficient restoration, enhancement and other conventional digital image processing techniques. The image was inputted as pixels and the processed image was outputted as pixels. In other words, it was a digital signal processing system for image processing. The application used mathematics as a description language for the signal processing function and a computer program was used to carry out the signal processing.

Figure 9 is a picture from the patent application. The summary of the invention in the patent application stated:

An improved method and apparatus for digital image processing is disclosed which permits greater efficiency in implementation of digital filtering techniques. In one implementation specially selected small generating kernels, or masks, are sequentially convolved with a data array of pixels representative of a particular image for more efficient restoration, enhancement or other conventional digital image processing techniques. The small generating kernels may be varied for each sequential convolution. In some implementations the output of each sequential convolution may be weighted in accordance with the filtering desired. Means for implementing the method are also disclosed.

In the case the Board stated that the signal processing was directed to a technical process in which the method was used, therefore it did not seek protection for the mathematical method used and was considered patentable. The process was considered technical because the processing was done on a physical entity: an image stored as an electric signal in this case. The Board explained further:

A claim directed to a technical process which process is carried out under the control of a computer program, cannot be regarded as relating to a computer program as such.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 46

The Board also made a point that making a distinction between the software and hardware implementations is inappropriate in the context of the inventive concept, i.e. it does not affect the invention’s patentability whether it is implemented in hardware or software.

Figure 10. A picture from the patent application for a system for processing monochromatic digital images.

In this case, the nature of data defined the process to be technical; if the data was pure numbers it would be a mathematical method, according to the Board. In other words, the definition of an application domain made the mathematical method a technical process along with the fact that a digitized image was considered a physical object. Later, the meaning of an image as a physical object in this case, has been specified to mean an image of a real physical object, not just any image (T 0935/97 1999).

4.1.1.2 IBM / Document abstracting and retrieving

Another computer program case testing the meaning of a technical process was T 0022/85 IBM/Document abstracting and retrieving (1988). The invention (EP 0032194 1980) was a program for automatically making an abstract of a given document, storing it and retrieving it when required. The abstracting was done by identifying certain type of words (e.g. numerics, proper names, acronyms) and comparing the document to a stored lexicon and filtering the identified words that were not in the lexicon. These words formed the abstract of the document.

Figure 11 is a picture from the patent application. The summary of the invention in the patent application stated:

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 47

A system that intelligently abstracts and archives a document for storage and interprets a free form user retrieval query to recall the document from the storage file. The system includes a method for automatically selecting keywords from the document using a parts of a speech directory. A method is given for weighing the importance or centrality of each keyword with respect to the document of its origin. Using the same logic paths, a free form query that describes the document in the same manner that it would have to be described to a secretary to "find" it in a filing cabinet, the system automatically determines the key matching terms and finds the archived document(s) with the greatest affinity.

Figure 11. Flow charts of the operation in abstracting and storing a document (left) and retrieving a document in response to a user query (right) as they were depicted in the original patent application.

The Board stated that the subject-matter was not of technical character, but felt into the category of schemes, rules and methods for performing mental acts, therefore the invention was not of technical nature and not patentable. Especially the rules for abstracting were considered to be of purely intellectual nature. Also the technical means used to run the program imported no technical considerations to the invention as a whole, and therefore lent no technical character to the invention; i.e. mere automation of the method did not make it technical. The contribution was therefore regarded to be in a field excluded from patentability.

The Board also stated that the actual problem to be solved was not technical: the problem of establishing a set of rules for abstracting a document on the basis of its textual properties.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 48

When the Board this decision compared to the Vicom decision, it made a distinction between the two: In Vicom the technical process brought about a change in the thing operated upon, i.e. the image, but in the present invention there was no such change, only new data derived from the document, therefore it could not be qualified as a technical process.

It is worth considering if the result of the method was only the abstract without the original document, could it then be regarded as a change in the operated thing, as in the Vicom case. The algorithm presented in the patent application can be thought similar to a digital signal processing algorithm, as in the Vicom case, and it could be argued that the algorithm is independent of the meaning of the document – processing only individual words in a similar way that a signal processor processes on individual numbers.

4.1.1.3 IBM / Generating a list of expressions

Third case concerning technical processes is T 0052/85 IBM/Method of generating a list of expressions semantically related to an input linguistic expression (1989), patent application filed in 1981 (EP0054667 1981). The program was for generating semantically related expressions according to an expression typed by the user. The input being a word given by the user and the output a list of semantically related words or expressions, if available. Application domain was word processing or any kind of writing in natural language. The algorithm itself was not complex, only taking the input word and comparing it to a pre-stored lexicon and showing the expression marked as semantically related. Obviously most of the work was done in defining the semantic relations between expressions.

Figure 12. A block diagram of some components in a text processing system according to the patent application.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 49

Figure 12 is a picture from the patent application. The summary of the invention in the patent application stated:

A storage method and control system for storing and interactively accessing a large data base of related linguistic expressions such as synonyms and antonyms. The data base structure includes a stored ordered vocabulary of the linguistic expressions and a stored NxN binary matrix defining the relationship between the expressions in the vocabulary. Address indexes are associated with the vocabulary and binary matrix to enhance access times. The control system controls a programmable digital processor to receive an input linguistic expression and access the binary matrix to generate linkages to the related linguistic expressions in the vocabulary. The related linguistic expressions in the vocabulary are concatenated and displayed for operator review.

The Board was of the opinion that the subject-matter of all the claims was in the field of linguistics, and the question remaining was if the subject-matter was related to linguistics as such. The Board stated that semantical relations, such as described in the invention, are not of a technical nature:

Semantical relations do not relate to any physical entity and they can be found by performing mental acts only, with no technical means involved.

Because the hardware elements described were conventional parts of a computer, they made no contribution to a technical field either. All the functions described in the method (storing, retrieving, comparing, etc.) were considered conventional by the Board, and therefore made also no contribution. Therefore the only contribution made by the invention was the semantic relations coded into the memory of the program, and these were considered to be in the field of linguistics, which is excluded from patentability. The program was, according to the Board, a straightforward automation of the linguistic problem of relating words semantically, and not patentable.

4.1.1.4 IBM / Text processing

Fourth case involving technical processes is T 0038/86 IBM/Text processing (1989). The application (EP 0093250 1983) was for a program that proofreads a text document and automatically detects (and replaces if required) words in the document which exceed a predetermined understandability level. The user defines first the appropriate understandability level. The invention was a quite simple algorithm of comparing the input data with pre-stored data about understandability and presenting data linked to the input as synonyms in the output.

Figure 13 is a picture from the patent application. The summary of the invention in the patent application stated:

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 50

A system for proofreading a text document and automatically detecting and replacing text words in the document which exceed a predetermined understandability level for the documents intended audience. Text words and synonyms are stored in a dictionary which includes an understandability code for each word based statistically on textbook grade levels. The operator enters a grade level code into the system for the intended document audience. The system scans the document for words which exceed the desired grade level, highlights those words on the system display and prompts the operator with synonyms which can be used to replace the highlighted word. The operator may select a desired replacement synonym by placing the system cursor underneath the word and depressing and enter key from the system keyboard.

Figure 13. A flow diagram from the original patent application for controlling the text processing system.

According to the Board, the steps in the method were information processing on data representing only linguistic information, and the processing itself was conventional from a technical point of view. In other words, the method was an automation of a mental process, and the automation itself was conventional. Therefore it made no contribution to the art in a field not excluded from patentability. The Board also stated that the data or signals processed did not undergo any change from a technical point of view; the processed data differed

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 51

only from the original data in semantics. The invention was not considered a technical process and was regarded unpatentable.

4.1.1.5 Siemens / Character form

Another significant case in forming the concept of technical process was T 0158/88 Siemens/Character form (1989). The invention (EP 0144656 1984) was a program for displaying characters, which are displayed in isolated form, start form, middle form or end form depending on their position in a word. The character is given a form once it is typed by the user, not until the whole word is typed, like in prior art. In other words, the program presented the character in some form even though the whole word had not been typed in. The form of the character was changed as the whole word was finally typed. The algorithm was quite simple once the rules for displaying characters were defined.

Figure 14 is a picture from the patent application. The summary of the invention in the patent application stated:

In a display of graphic characters (Z1 to Z3) in which the character shape depends on the particular position in a word, in particular in a display of Arabic graphic characters, on inputting the first graphic character (Z1) it is displayed in a basic form, for example in the isolated form. If a second character (Z2) is entered, it is displayed in the terminal form, whereas the first character (Z1) of the isolated form is altered to the starting form. On entering further characters (Z3), each of these is shown in the terminal form and the immediately preceding character (Z2) is altered to a centre form.

Figure 14. An example of entering graphic characters as depicted in the patent application.

The program was, according to the Board, only a method of processing data and produced no effects beyond information processing. Therefore, it was considered a computer program as such. Also the controlling of a display unit, explicitly mentioned in the claims, was not seen to produce any effect beyond its normal functioning and therefore the invention could not be considered to have a technical effect on the hardware element. Also the invention solved no problem, considered by the Board to be technical. The invention’s process was not

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 52

considered technical but mere processing of data. The invention was not patentable.

4.1.1.6 IBM / Data communication system

The last case on technical processes is T 0216/89 IBM/Data communication system with capabilities to analyze an error or problem condition (1990). This invention (EP 0068093 1982) was a program for showing alphanumerical data, both in encoded and decoded form, in a network where encoded alphanumerical data can be transmitted from one terminal to another. The program was used to make detecting errors in the transmitted the data easier for engineering support personnel. The detection of errors was made easier by providing the engineering support both the encoded and decoded data for spotting errors. As a computer program, the invention is quite simple today: showing encoded and decoded data and comparing them to find an error can be considered trivial.

Figure 15 is a picture from the patent application. The summary of the invention in the patent application stated:

A communication system is provided in which one data transmitting display terminal has the capability of transmitting a data stream in coded form to at least one data receiving terminal over a communication linkage. This data transmitting terminal further includes the capability of displaying, when necessary, the stream of coded data directly on its display so that if there is a transmission problem, the coded data itself can be analyzed in diagnosing the problem. The present communications system has the further capability of diagnosing data streams at remote display terminals. For example, if one transmitting terminal is communicating with a receiving terminal and a problem arises between the two terminals, the system provides the capability of the transmitting terminal sending the data stream to another receiving terminal remote from the first two terminals. This remote receiving terminal is a display terminal having the capability of displaying the received stream of coded data whereby the problems between the two communicating terminals may be diagnosed at a remote location where better engineering support may be available.

The Board considered the case as follows. Firstly, the mentioned availability of competent engineering support was not seen, by the Board, as a defined feature of the system. Although to recognize and diagnose a problem in the network would require mental acts, the Board stated that the system itself did not involve mental acts. The Board also was of the opinion that encoding and decoding of alphanumerical data in the invention is

…technical transformations in which the represented text per se remains unchanged.

The Board considered that viewing encoded and decoded data is viewing the data from a different points in the sequence of technical transformations of the same

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 53

signal, which is considered technical subject-matter and the invention was declared patentable. In other words, encoding and decoding a data stream was considered a technical transformation of a signal, and viewing the signal both in encoded and decoded form was therefore considered technical, i.e. patentable subject-matter.

Figure 15. The apparatus of the invention according to the patent application.

4.1.1.7 Summary

All of the above cases were automations of some mental steps on data that could have been done manually, at least in theory. From these six cases it can be seen that the two cases that were considered patentable were programs that manipulated data according to some mathematic formula: a signal processing function in Vicom and some encoding/decoding function in IBM/Data communication system. On the other hand, the four rejected cases manipulated their data according to some predefined rules relating to linguistics, according to the Board.

It is also worth considering what was represented by the data in the cases to understand what might be the reasons for patentability. The Vicom case’s data was a digitized image, represented by a matrix of numbers. In IBM/Abstracting, IBM/Semantically related expressions, and IBM/Text processing the data was words. In these cases the meaning of the words was irrelevant to the program, only their occurrence in a pre-stored lexicon was used, but they were not patentable. In Siemens the data was pre-defined symbols representing different

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 54

forms of characters and it was not patentable. In IBM/Data communications system the data was alphanumerical, i.e. words, and it was patentable.

The Board made no comment on the difference between mathematical rules and linguistic rules but regarded their difference important in patentability. Also the nature of data was mentioned several times but the fact that all the data is numbers to all of the programs was not brought up, and the differences in the nature of the data was not clear.

4.1.2 Networks

This section presents two cases where the patents were on a computer network of some sort and a computer program functioning in that network.

4.1.2.1 IBM / Data processor network

The first case is T 0006/83 IBM/Data processor network (1988). The patent application (EP 0006216 1979) was for a plurality of data processing systems (nodes) in a network, where a local node can determine when a process requires resources held at another remote node of the network. When the local node has determined that remote resources are required it generates a transaction request to the remote node. All the nodes have the capability to receive such requests and process them as if they were local transactions, and sending the processed results back to the node that sent it in the first place.

Figure 16 is a picture from the patent application. The summary of the invention in the patent application stated:

A plurality of digital data processing systems are interconnected as nodes in a telecommunication network. When two intelligent nodes are connected and one local node determines that a process which it is executing requires the use of resources held at the second remote node, the local system sends a request to the remote system. It is desirable that the remote system handle the request from the local system as it handles all other requests so that source integrity is maintained. The local system, in response to a request from a local application program which it is servicing, sends a corresponding transaction request along a communication link to the remote system. This transaction request passes directly from node to node without going through any intermediate controller. The remote system receives the request and creates a new unit of work. The remote system then performs the unit of work and sends the result back to the local node. The local system receives the result and returns it to the requesting application program.

The Board superficially commented that the invention solves a problem essentially technical, and it is not a computer program as such, because the application is independent of the data processed. As for the technicality of the problem, the

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 55

Board gave no further explanation on what made it technical, it was only declared to be essentially technical and therefore patentable.

Figure 16. A flow diagram of the transaction program in the original application.

4.1.2.2 IBM / Document distribution network

The other case is T 0071/91 IBM/Document distribution network (1993). The invention (EP 0108899 1983) was a program and data a uniform data stream for handling documents in a network, where the nodes (processors) have a varying level of data processing capabilities, i.e. some nodes can process some parameters of the document and some nodes can process some other parameters. The uniform data stream was defined to have a standard interface so that the programs on individual nodes could process the parameters of the document they were able to, and the data that was not processed was not lost but remained unprocessed in the data stream. The data to be processed was, e.g. presentation of images; a processing capability not available in all the nodes of the network.

Figure 17 is a picture from the patent application. The summary of the invention in the patent application stated:

An electronic document distribution network is provided having a uniform data stream which may be used by data processors of varying levels of data processing capability interconnected in the network. The network comprises a plurality of linked communicating data processors. Each of the processors has apparatus for receiving and for transmitting a uniform data stream which is representative of the

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 56

content and format of the document as well as the processing to be performed with respect to the document. The network includes higher level processors which have a higher level of data processing capability with respect to the data stream and lower level processors. One or more of the lower level processors further include apparatus for scanning a received data stream and for selecting from the data stream parameters which this lower level processor is capable of processing. The lower level processor also has apparatus for storing the non-selective parameters which it is not capable of processing. After the lower level processor has processed the selected parameters, the processor includes apparatus for merging the selected parameters and the stored parameters into a reconstituted data stream which corresponds to the received data stream and apparatus for transmitting this reconstituted data stream to another processor in the network.

Figure 17. A presentation of the data stream with its units and sub-units broken down to the levels dealt within the invention.

According to the Board, the invention was not concerned with the linguistic meaning of words in the document, and the data processed was also independent of the content of the document. Also a clear contribution, an advantage, was made to the art in describing the system where documents can be passed over to processors with low processing capabilities without them losing the data which they are not able to process; a problem encountered in prior art. The invention was found patentable.

4.1.2.3 Summary

These two cases both handle data independent of its meaning - at least its linguistic meaning – and focus on controlling the processors. Both of these patents

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 57

seem to be similar with operating system functions, and therefore closer to the hardware in their level of abstraction. As indicated above, both of the patents were found patentable.

4.1.3 Internal workings of hardware

This section presents the EPO cases that were interpreted to have a technical nature in controlling the internal workings of a computer in one way or the other. In other words, they were seen as being close to the hardware of the computer in the level of abstraction.

4.1.3.1 IBM / Displaying of pre-determined messages

The first case is T 0115/85 IBM/Displaying of pre-determined messages (1988). The invention (EP 0052757 1981) was a program for displaying system events to the user of a text processing system. System events include events like having no disk in the disk drive when one was required. The domains involved were the user and the computer on which the text processing program is run; the inputs were from the computer hardware and the outputs were given to the user. The use of a certain data structure and an algorithm for handling it made the program function faster and use less storage than prior art.

Figure 18 is a picture from the patent application. The summary of the invention in the patent application stated:

Method of decoding stored phrases and obtaining a readout of events in a text processing system controlled by a processor with program and tables stored in a memory. The method includes comparing a phrase made up of a number of words encoded on a byte value/frequency of use basis and included in a phrase table with the words of a decode table arranged on a byte value/frequency of use basis, a pointer associated with each word pointing to a word stored in a word table. Upon a compare, the number of bits information associated with the word resulting in a compare is used to determine any phrase remainder. If there is a remainder, the remainder is compared with the decode table to obtain a match. The compare/remainder determination sequencing continues until all words in the phrase have been decoded.

According to the Board, displaying system events to a user is a technical problem. Although the underlying invention was a computer program, a claim directed to its use in the solution of a technical problem was not regarded as seeking protection to computer program as such, and the invention was considered patentable.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 58

Figure 18. Operations performed by the word processing system according to the original patent application.

4.1.3.2 Koch & Sterzel / X-ray apparatus

The second case is T 0026/86 Koch & Sterzel / X-ray apparatus (1987). The X-ray apparatus (EP 0001640 1978) had a computer program part for maintaining X-ray tube voltage and current, and determining exposure parameters. The program calculated values for the parameters according to certain functions.

There was no suitable picture available in the patent application. The summary of the invention in the patent application stated:

A diagnostic X-ray system operative in response to control signals from a stored program digital computer to generate an X-ray beam and to produce an image of the object through which the X-ray beam passes. The computer which is preferably a microprocessor has a plurality of selectable programs stored in a digital memory and is operable to control a plurality of operations such as maximizing image quality in terms of resolution, verifying the available anode heat capacity, providing the necessary wait time between successive exposures in a tomographic series, storing the X-ray tube(s) histories, storing and recalling X-ray factors on an anatomic basis and, among other things, making a calculation and display of a pseudo-dose.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 59

The only difference between the invention and prior art was the computer program, and therefore its patentability was under dispute. The computer program was not considered a computer program as such, because it produced a technical effect in the X-ray apparatus. A mixture of technical and non-technical (here the x-ray machine was considered technical and the computer program non-technical) features was accepted. The Board also stated that the conventional electric signals as changes in the voltage in the computer's circuitry produced by a computer program cannot be considered a technical effect, therefore any computer program does not automatically produce a technical effect just by having electric circuits.

This case was another example of computer program controlling physical pieces of hardware. In the present case the hardware was not conventional computer hardware but a specific apparatus with changeable parameters.

4.1.3.3 IBM / Editable document form

The third case is T 109/90 IBM/Editable document form (1993). The invention (EP 0109614 1983) was a program for transforming documents written in one format to another format (i.e. between two incompatible formats), while maintaining their editability. The algorithm described was not simple: it was written to transform any document format to any other document format without storing in advance any transformation functions.

Figure 19 is a picture from the patent application. The summary of the invention in the patent application stated:

A method of transforming a first editable form of a document prepared by an interactive text processing system into a second and incompatible editable form for use in another interactive or batch text processing system through the use of a transform mechanism is described. A significant step of this method requires the identification of a limited number of key state variables, whose values collectively identify the necessary state information for transforming the first document form to the second. After the key state variables have been identified, the actual number of combinations thereof is determined. For each first document form input item encountered by the transform mechanism, and for each combination of key state variables in which that input item can be encountered, one or more output items for the second document form is explicitly defined as the transform thereof. In addition, the state of the transform mechanism after each such transform has occurred, must also be specified. The described method is also to resolve the actual state that exists at the start of each document. It is also adapted to handle sub-documents, such as margin text, existing within a document to be transformed.

The input and output items were considered by the Board to be

control items, understood as acting on items of hardware such as a printer,

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 60

not as text items. Although some of the method's steps were considered mental steps, they did not exclude the whole invention from patentability. The transformations made to the document were seen independent of the linguistic meaning of the digital text data processed; it was concerned only with the control items and transforming them. Therefore,

the ultimate purpose of the control items is, inter alia, the control of hardware such as a printer.

These control items were considered by the Board to be

characteristics for the technical, internal working of the system,

i.e. they represented technical features of the text-processing system. The technical effect according to the Board was transforming digital data representing control items in one form to another form without altering the information, thus creating a communicative link between two normally incompatible text-processing systems.

Figure 19. Unified but separable configuration of two text processing systems adapted to work with the invention as pictured in the patent application.

This interpretation by the Board emphasizes the importance of having items in the invention whose abstract level is close to hardware; in the present case it was control items for printers. It can be argued, that the Board’s interpretation changed

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 61

the character of the invention: In the patent application the invention is described as solving the common problem of having several different document formats. But the Board’s decision underlined that the invention was about transferring technical features of a text-processing system from one format to another; a problem not easily identified as the everyday problem of having two incompatible document formats.

4.1.3.4 Bosch / Electronic computer component

The fourth case is T 0164/92 Bosch/Electronic computer component (1993). The invention (EP 0163670 1984) was a program that detected if resetting an electronic component (e.g. microprocessor) was done by a monitoring device or by a power-on reset circuit. Input for the program was two values from memory that were compared and output was the result of the comparison. The program was based on a very simple algorithm of comparing two values from memory; one from volatile memory and the other from more permanent memory.

Figure 20 is a picture from the patent application. The summary of the invention in the patent application stated:

A method is proposed which serves to enable recognition, in microprocessors (1) provided with a monitoring device (2) having a signal generator stage for reset signals, of whether a reset signal was effected by the monitoring device (2) or by a power-on reset circuit (5). To this end, a comparison is performed between a comparison pattern stored in a non-erasable memory zone (6) and a pattern, which is typical of resetting erected by the monitoring device (2), located in an erasable memory zone (7).

Figure 20. Elements of the invention according to the original patent application.

The Board considered the advantage to prior art to be that the type of reset can be decided by the processor running under the computer program claimed. This was

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 62

considered to shorten the restarting of programs and having the further advantage of requiring no particular circuit configuration. In other words, the advantage was that the invention could be implemented by using conventional hardware. The Board considered this kind of invention not to be a computer program as such and decided that it was patentable.

Here again the close involvement of hardware elements was reason enough for patentability although the computer program used did only very trivial information comparison.

4.1.3.5 Summary

The four cases in this section showed that although the computer programs themselves were quite simple, the close presence of hardware in the application domain made the application seem more readily patentable. For example, a program changing documents from one format to another was considered patentable once it was formulated to change hardware control items from one format to another.

4.1.4 User convenience and user interfaces

The Board’s cases in this section consist of inventions that improve usability or user convenience. These inventions can be thought of being quite abstracted from the hardware of the computer, but quite visible to the user. There are seven EPO cases presented, and it can be seen that they are newer inventions than the ones before.

4.1.4.1 Sohei / General-purpose management system

The first case is T 0769/92 Sohei/General-purpose management system (1994). The invention (EP 0209907 1986) was a program for combining several types of management under one system. The types of management including at least financial and inventory management, but the program was generalized to fit almost any kind of management. The program itself, according to the claims, was very simple and had only few functional items and few defined steps on those items, although the application domain of management systems is usually very complex.

Figure 21 is a picture from the patent application. The summary of the invention in the patent application stated:

A general-purpose management system displays a single general format on a display unit so that items redundant in plural types of management to be performed independently, as well as items peculiar to each type of management, can be inputted successively, and includes a first file for collectively storing data

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 63

relating to each of the items inputted in accordance with the display, a plurality of second files for storing data necessary for each type of management on a type-by-type basis, a data extractor which, in dependence upon the type of management to be performed independently, is adapted to extract data necessary for this management from the first file and transfer the data to a corresponding second file, and a data prepared for preparing data necessary for a specific type of management and outputting these data in accordance with a predetermined format on the basis of the data in the first file and the data transferred to the corresponding second file.

Figure 21. The format of the transfer slip.

In the Board’s decision the system and method claims were seen to differ only in their categories, and therefore they were treated jointly. The system was found to be a general-purpose management system, not bounded to any particular type of management; financial and inventory management were only used as an example to render the invention more understandable. All the hardware units in the invention were considered conventional.

The important point between the management types involved in the program, was that the first and second kinds of input items were different: specific types to be performed independently of each other. In the Board's opinion the only thing that was relevant to the management systems was that the program could be used to any kind of management as long as the management types were different.

The claimed system allowed data from several types of management to be inserted via one user interface. According to the Board, technical nature was achieved because two kinds of systems having different purposes and implying independent activities were combined by a common input device, allowing items from one system to be used in the other. In the Board's opinion, the implementation of the user interface combining the two systems was not an act of programming, but

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 64

rather concerns a stage of activities involving technical considerations to be carried out before programming can start.

In the Board's view the implementation of the invention required technical considerations, and such technical considerations implied the occurrence of a technical problem to be solved and technical features solving that problem. This decision by the Board resulted in adding a new attribute to the meaning of the concept of “technical nature”, namely “technical considerations”. Technical considerations were discussed in section 3.3.9 of this thesis.

What is interesting in the Board’s decision is that it generalized the invention even more than would seem to be the original purpose of the patent application. In its efforts to show that the program was almost independent of the type of management the Board described the invention in very general terms.

The invention was described, by the Board, to have five different file types and five different activities on these files. The first files were intended for storing the input, the second and fourth files were for storing data necessary for the first type of activity, and the third and the fifth files were for storing data necessary for second type of activity.

The activities were generalized so that the first processing was inputting data to the first file and controlling the display, the second processing was automatically updating the second and third file according to the input of the first file, the third processing was transferring data from the first file to the fourth file and relating the data in the fourth file to data in the second file, fourth processing was transferring data from the first file to the fifth file and relating the data in the fifth file to data in the third file, the fifth processing means was for outputting the data in the files. Even from this complicated description it can be understood that the described program is very abstract and stating no application domain for the file types and activities; a policy strictly avoided by the Board in other decisions on computer programs.

4.1.4.2 IBM / Editing business charts

The second case is T 0790/92 IBM/Editing business charts (1993). The invention (EP 0196430 1986) was a computer program for editing (business) charts like they were drawing objects, e.g. scaling, rotating, etc. The link to the data represented by the chart was broken if the chart was edited in a such a way that it no longer represented the original data, for example one bar of a bar chart was made larger than it should be according to data. The program itself was very similar to basic drawing programs having an event loop waiting for instructions.

Figure 22 is a picture from the patent application. The summary of the invention in the patent application stated:

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 65

A method is disclosed for interactively manipulating a business chart as a group of draw graph objects. The chart is displayed using predefined data. A draw graph object of the business chart is selected for editing. When the editing action is completed, a check is made to determine whether the action on the business chart destroyed the relationship between the chart and the predefined data. If it did, a message is displayed to the operator indicating that the link between the chart and the data has been broken.

Figure 22. Operation of the invention as depicted in the patent application.

The invention was carried out on a general purpose computer, and no new hardware was involved. From claim 1 the Board derived that the invention claimed only two kinds of features: features involving operator's activity and functions carried out under a computer program. The operator's activity was considered to be purely mental considerations. As for the functions carried out under the computer program, the Board divided them into two: displaying the charts and accessing data to check for consistency between the chart and the data. Displaying charts was considered not technical, because the charts represent only numerical data, not a physical object, and therefore it was considered presentation of information which is not technical. The displaying of charts was not, according to the Board, displaying internal functioning of the computer and not patentable subject-matter on that account either. The other function of accessing data to check

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 66

consistency between the chart and the data it represented was not considered to be technical either. The accessing of data was seen to have no features of a technical kind, apart from conventional ones.

The appellant argued that the invention made a technical contribution in checking for consistency between the chart and the data the chart represented. In the appellant's view the computer's internal state was switched from one state to another once the link between the chart and the data was broken, and in addition this switching of internal state resulted in a change of the signal controlling the CRT display. The Board stated that the state of the link, broken or not, concerned only presentation of information and not structural features of the computer. The Board also considered that the change of the display signal was a change in the signal's information content, not a change from a technical point of view.

The invention was considered to be operations on information content involving no technical modifications of the computer, and was found unpatentable.

4.1.4.3 IBM / On-line help facility

The third case is T 0887/92 IBM/On-line help facility (1994). The invention (EP 0190419 1985) was a computer program for presenting help information to the user. The help information presented was related to only those commands which were valid to the task at hand, in other words it did not show help information on commands that could not be executed at the present state of the computer program. The description of the invention itself was on a quite high level of abstraction giving only some guidelines about the implementation.

Figure 23 is a picture from the patent application. The summary of the invention in the patent application stated:

A method to help and displace Help Panels containing information to explain Command Functions, Command Syntax, and Command Parameters to the operator of an interactive information handling system in response to the entry of a "Command Help Request" into said system by said operator. The method displays the selected panel as an overlay on the existing screen at the time the Command Help request is entered into the system. Selection of the panel to be displayed is based on an analysis by the system as to what commands are valid or active for the next step in the process or task that the system is performing. The operator may select directly from the Command Help Panel overlay, the desired command, or alternately enter the command desired by moving the cursor to the command area of the underlying screen and keying in the command. The method further provides for the system to display a second level of Command Help Panels containing information as to the Parameters and their meaning for commands selected from the first level of the Command Help Panels. The method also advises the operator with other overlaid Help Panels if an invalid command is entered when the system is displaying a first level of Help Panel. The panels that re displayed in addition to advising that the command is not active also advise the operator how to reach the

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 67

point in the process where the non-active command becomes active from the current state of the process task.

Figure 23. A picture form the original patent application representing a sequence of steps involved in the invention.

The technical problem solved by the invention was seen by the Board in making the known method more efficient and convenient for the user. The use of the invention relied on a combination of a selection key and a cursor for inputting a command; this was considered by the Board to be a tool of clear technical character. This tool was also seen as a technical link between the display and the processing means. The Board's earlier decisions have stated that giving visual indications about conditions prevailing in a system is basically a technical problem. Therefore the Board considered that displaying of only valid commands clearly reflected the status or condition of the system or apparatus. The computer program involved in the claims was seen as necessary means for carrying out the invention and therefore not an objection to patentability. Therefore the subject-matter was seen to clearly make a contribution to the art in a field outside the range of excluded matters, i.e. it was found patentable.

4.1.4.4 IBM / Interactive rotation of displayed graphics

The fourth case is T 0059/93 IBM/Interactive rotation of displayed graphics (1994). The invention (EP 192022 1986) was a computer program for rotating graphics objects on a display, and enabling the user to decide the length of the rotational lever by moving the cursor directly away from the center of the object.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 68

This gave the user much more accuracy to rotating than inventions in prior art. The algorithm in the program was a straight-forward calculation of the rotational angle based on the values of the rotational lever’s length and cursor movement from the starting point.

Figure 24 is a picture from the patent application. The summary of the invention in the patent application stated:

A method is described for editing a graphic object being displayed by an interactive draw graphic system. The method is directed to a rotate edit action on a graphic object that can be selected from a group of individual objects that are being concurrently displayed in an overlaid fashion on the same screen. The method permits the operator to move the cursor that is involved in the object selection task away from the object after the object selection task is completed so that the cursor can be positioned in an uncluttered area of the screen. The direction of movement of the cursor is along the line extending from the center of the object through a point or line segment of the object that was adjacent the cursor the time the object was selected. When cursor motion is under the control of an input device, such as a mouse, the operator's efficiency and accuracy is increased since the desired amount of rotation becomes easier to obtain as the distance between the object and the cursor increases.

Figure 24. A picture form the original patent application showing the steps of the method of rotating the graphic object.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 69

The features, or method steps presented in the claims were not regarded by the Board as a method for performing mental acts. The steps where mathematical methods were involved were considered to be used as tools within the overall method claimed, not mathematical methods as such. The invention, according to the Board, brought about technical effects and solved a problem which was regarded as technical: enabling the user to perform finer control of the rotate action. Excluded matters present in the invention, mathematical method and computer program, did not render the invention unpatentable. The invention was found patentable.

4.1.4.5 IBM / Hierarchical selection

The fifth case is T 0094/93 IBM/Hierarchical selection (1994). The invention (EP 0180021 1985) was a computer program for handling selection of components that have hierarchical sub-components, for example a graphical presentation of a wheel where the tire and the rim are sub-components. The selection was done by repeatedly selecting (clicking) the object and each time the selection moves to the next level of hierarchy until the lowest sub-component was reached and after that the selection loop started from beginning (e.g. wheel -> tire -> inner tube -> wheel -> tire ...). The algorithm used is very simple and intuitive.

Figure 25 is a picture from the patent application. The summary of the invention in the patent application stated:

A method of, and system for, building a screen and retrieving related portions of the screen through single button depression. The order with which various portions are built in building a screen is used upon recall of the screen and selection of one portion for controlling selection of related portions. Consider a wheel which is built by building a hub, spokes, rim, and tire in order. Later recall of the wheel and selection of the spokes will permit selection of either the hub or rim upon single button depression.

The Board was of the opinion that a computer program as such was not involved. Firstly, a screen pointing device in combination with a selection button was considered a new input tool which is technically different to prior art. The new pointing device was seen to provide a link between the display and the processing means. A computer program as such was not involved, because the computer program was seen by the Board to be technical means necessary for carrying out the invention. The features of the invention were therefore considered to have technical character, moreover they

…clearly contribute to the solution of the technical problem;

the problem of improving the method of selection by a pointing device. The invention was found patentable.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 70

Figure 25. Operation of the invention as illustrated in the original patent application.

4.1.4.6 DAI / Designing 3D container

The sixth case is T 0605/93 DAI/Designing 3D container (1995). The invention (EP 0229849 1986) was a computer program for designing three-dimensional containers (receptacles), especially with non-revolutional body. Coordinates were given as an input, and the machine processed the data to make a predefined compilation. Output could be achieved either as a 2D hardcopy, on a display for the user, or a line drawing. The program’s algorithm was based on the pre-defined input parameters’ form and calculating the object based on them was quite simple.

Figure 26 is a picture from the patent application. The summary of the invention in the patent application stated:

A method of designing a cubic receptacle which determines the form of the receptacle in consideration of an internal capacity of the receptacle or an amount of material required for manufacturing the receptacle to prepare a two-dimensional pictorial image of the receptacle of which form is thus determined with a label being attached thereon to appraise the pictorial image thus obtained. To carry out the above design, a computer and various input/output units are used. In addition, a designing method particularly suitable for determining the form of a receptacle of body of revolution. Such a determination of the form is made using a coordinate input unit. Moreover, a technique is provided for representing a three-dimensional body in a two-dimensional manner, especially to a technique for representing a

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 71

cubic receptacle on which a label is attached in a two-dimensional manner. In addition, a special algorithm is used for representing an impression of material quality of the receptacle. Further, a method of forming vector data of special character font suitable for a work for attaching a label including character on a cubic receptacle.

Figure 26. Illustration of one embodiment according to the invention.

The claimed invention comprised of conventional hardware. The Board found a contribution made to conventional computer art: Firstly, the receptacle represented a real concrete thing, i.e. a physical entity, which may be subsequently manufactured. The input units were seen by the Board to differ from conventional ones, because they had to be constructed to allow particular kind of data to be entered. Using computer programs to implement the input functionality was acceptable, because the computer programs can be regarded as tools. Therefore the Board considered the invention to be patentable subject-matter.

The explicitly defined interface for the input parameters seems to have been an important part of the invention. The input parameters were a central axis of the receptacle, several lateral two-dimensional cross-sections perpendicular to the central axis, and segment data on the designated ranges of the cross-sections relative to the central axis. These parameters have a clear physical nature and therefore seemed to be of importance to the Board.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 72

4.1.4.7 IBM / Windowing

The seventh case is T 935/97 IBM/Windowing (1999). The invention (EP 0767419 1996) was a computer program for displaying information in a windowing system, where two windows overlap and the lower window's information is fitted so that it is no longer obscured by the window overlapping it.

Figure 27 is a picture from the patent application. The summary of the invention in the patent application stated:

In a data processing system having a display and an operating system, information is displayed within a first window utilizing information display software. Thereafter, the process detects a second window displayed within the display at a location that obscures a portion of the information displayed in the first window. Utilizing the operating system, the process notifies the information display software that the portion of the information within the first window is obscured by the second window. In response to receiving this information, the information display software displays, in the first window, the portion of the information that had been obscured by the second window, wherein the information in the first window previously obscured by the second window may be viewed in the first window by the data processing system user. Information displayed in the first window may be textual or graphical. The information display software may also receive information form the system that specifies coordinates of available display area. In response to predetermined conditions, previously obscured information may be displayed in available display area in a relocated first windows.

Figure 27. A window for displaying information with the display feature of the invention.

The case presented to the Board was not about the patentability of the program but the patentability of the program on a computer readable medium, e.g. a floppy disk, cd-rom etc. The program itself was considered patentable and the main focus was on the so called “product claims” meaning that the patent could be claimed

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 73

on a carrier or a medium (floppy disk, cd-rom etc.). Previously, such claims were not accepted. In its decision the Board saw

… no good reason for distinguishing between a direct technical effect on the one hand and the potential to produce a technical effect, …, on the other hand.

Therefore the Board was of the opinion that a computer program product can have a technical character because it has the potential to produce further technical effect. This removed the distinction between a computer program loaded into a computer’s memory and a computer program on a carrier; a distinction that seems quite artificial from the software engineering point of view when the program’s basic idea is considered. The invention was found patentable as a product.

The Board’s decision took also the opportunity to roundup its policy on patenting computer programs. These considerations were presented in chapter 3 when these concepts were discussed.

4.1.4.8 Summary

This section presented patent cases where the computer program’s idea was in providing the user with better usability. The concept of usability can be thought of being on the other end of the abstraction hierarchy from hardware elements to the user: the whole idea of a user interface can be thought of abstracting the hardware elements to make using the computer as convenient as possible. Therefore the inventions presented here are very different from the ones presented in the previous section where having or controlling hardware elements was important.

The importance of hardware elements can be seen also in some of the justifications for patentability in the user interface cases. For example, a device that combined a cursor and a selection button was seen to link together two hardware elements, namely a display and a processor. Another example is the reasoning found in IBM/ On-line help facility (T 0887/92 1994) where technical nature was found when the invention was thought as reflecting the status or condition of the computer system, although the invention was about more usable help facility.

To contrast this amiability towards hardware elements the case of Sohei/General-purpose management system (T 0769/92 1994) justified the inventions patentability by generalizing, i.e. abstracting, the invention to a very high level of specifications having no application at all.

4.1.5 Code generation and programming

This section presents two cases on patenting inventions that relate to programming and code generation.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 74

4.1.5.1 Texas Instruments/Menu-based natural language understanding system

The first case is T 0236/91 Texas Instruments/Menu-based natural language understanding system (1993). The invention (EP 0118187 1984) was a computer program for entering natural language input. The program showed in menus the available words to input phrases so that the grammar and vocabulary remained correct. The input string was then translated by the machine into a computer executable command. The program and the algorithm was a parser with a pre-stored grammar and lexicon.

Figure 28 is a picture from the patent application. The summary of the invention in the patent application stated:

An interface system which can elicit well-formed inputs in a restricted subset of a natural language, such as English, from unskilled users. To accomplish this, a menu is displayed which contains all possible elements which might form the continuation of a legal sentence within the restricted syntax being applied. The user then merely indicates from the menu which of the possible legal elements he wishes to use to continue his sentence. This can be done, e.g., with a joystick or a mouse. To accomplish this function, the system systematically parses every successive input, as soon as received from the user, and, as part of the parsing operation, produces the set of possible categories of next inputs which would be legal. This set of possible categories of legal next inputs is then translated, through the lexicon, into a list of possible legal next words. The set of legal next words is then displayed, e.g. as a highlighted menu. After a complete sentence has been input in this fashion, the sentence is necessarily a legal one within the restricted syntax being applied, and a trivial mapping then transforms the parsed sentence into an executable machine-language command.

Figure 28. An example of parsing according to the invention.

In the Board's opinion the invention's means and functions were clearly conventional (e.g. inputting, storing etc.), but it was stated by the Board that the technical effect of the invention would be caused by the feature concerning the parsing means, which rendered the internal working of the computer "not conventional". The parsing means consisted of parsing the sentence step-by-step, not until the whole sentence was given, and ad hoc creation of menus for the user to select input words from. The Board also pointed out that

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 75

…the inputting of a command is the execution of this command by a particular function of the computer, and this execution will normally have a technical effect.

In other words the inputting of words was seen as controlling a machine having a technical effect. The Board was, for these reasons, of the view that a technical contribution was made to the art, and found the invention patentable.

4.1.5.2 AT&T / System for generating software source code

The second case is T 0204/93 AT&T/System for generating software source code components (1993). The invention (EP 0219993 1986) was a computer program for generating source code components or modules. The machine relied on general purpose components (general in some category, e.g. sorting, storing etc.) that were instantiated into source code once the detailed requirements or specifications for that module were given in a certain specification language. The patent application defined the specification language and the setup of the program, but the claimed method steps or algorithm for using the components were quite trivial.

Figure 29 is a picture from the patent application. The summary of the invention in the patent application stated:

A system has been devised that allows commonly used software components to be designed and developed only once, and reused many times in different applications with different operational contexts and requirements. The system includes a language for the specification of software components in a context-independent generic fashion, a compiler for the specification language and a program for generating concrete software components to work in a specific context.

Figure 29. A picture from the original patent application showing the invention in a computer system.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 76

The Board's opinion was that the invention resembled the well-known calling up of stored sub-routines in main programs. The Board also pointed out that writing a computer program is excluded from patentability because it requires performing mental acts as such. None of the invention's features or functions required any new hardware or other novel structural features. Therefore, according to the Board the invention did not seem to go beyond a computer implementation of a programmer's activity. The Board agreed with the appellant that the invention would make the programming process more efficient, but the Board pointed out that the computer's efficiency would remain the same and the functioning of the computer as a programmable machine would not improve either. The Board also stated that

…programmer's activity of programming would, as a mental act, not be patentable irrespective of whether the resulting program could be used to control a technical process.

The invention under consideration produced no technical effect, had no new hardware elements or other novel technical features and therefore it was not patentable.

4.1.5.3 Summary

When these two cases are compared the Board’s decisions seem to be in contradiction. In the first case the invention is patentable because commands produced by the user usually produce technical effects when executed. In the second case the Board is quite specific about programming not being patentable. The difference between producing commands for computer that may have a technical effect and programming remains unclear.

When the technical effects of the inventions are compared it sheds no extra light on the Board’s decisions. The technical effect in the first case was the feature that the input sentence was parsed word-by-word as the user input the words. The technical effect of the latter case was making the programming process faster and more reliable by using ready-made components that had been tested. Both of the technical effects are making the process more convenient for the user, and the process in both cases is programming, i.e. giving commands to the computer.

4.2 Mechanical patents

This section presents some traditional machine inventions to show the contrast between mechanical machines and computer program machines. Traditional means in this context machines and methods that work in a more mechanic way than computer programs, and that they are closer to the kind of inventions that the patent system was designed for in the first place.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 77

These inventions are presented to give some contrast to the problems rising in patenting computer programs. The aim is to point out some clear differences in describing so called traditional inventions and computer program inventions in the context of patenting.

All of the three patents presented here have been granted by the EPO and therefore their application and granting process is the same as in the patents presented in the previous section. The first two patents, a mop and a wood chopping machine, are very simple devices for doing basic work. The third patent, a tempering and bending machine for glass sheets, is more of an industrial machine probably not used in everyday life.

4.2.1 Means for cleaning floor

This patent is an example of a very simple device with a clear technical improvement in relation to prior art. The invention is a floor mop with an easily attachable and detachable cleaning part; the user does not need to bend down to change the cleaning part (EP 0126054 1984). Figure 30 shows the patented mop.

Figure 30. Steps A through D show how a cleaning part is inserted into the frame of the mop.

A partial description of the invention is stated in the claims of the patent as follows. The numbers in parentheses refer to the numbers in figure 30.

A means for cleaning a floor comprising a shaft (1), an elongated frame (2) pivotally mounted on one end of said shaft, an elongated cleaning part (3) detachably affixed to said frame, said cleaning part having a pocket (7, 7’) at each end thereof with a mouth and a bottom, the mouths of said pockets opening toward the center of said cleaning part and toward each other, … , said frame having a pair of ends (5,14) and being provided at at least one end (5) with a clamping means (6) which can be moved towards and away from the center of said frame, characterized in that said

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 78

clamping means comprises an end part (10) and a spring (11) operatively associated with said frame and end part (10), said end part having first and second ends (9, 12), said first end (9) being pivotally mounted to said frame, … , said frame being insertable into said pockets of said cleaning part by moving said second end of said end part (10) towards said frame.

When reading the description alongside with the pictures in figure 31, it is easy to understand what parts of the mop are important, what they look like, and what is their functionality.

4.2.2 Chopping machine for cutting and splitting timber

The second patent presented in this section is a machine for cutting and splitting wood (EP 1118438 2001). The machine takes timber wood as input and produces as an output the wood cut to pieces of certain length and split in half. The functions carried out between the input and output can be easily seen and understood from the descriptions in the patent application. A picture of the machine is presented in figure 31.

Figure 31. A chopping machine according to the invention.

A partial textual description of the machine in the claims of the patent application is as follows. The numbers in parentheses refer to the numbers in figure 31.

Chopping machine for cutting and splitting a timber, said chopping machine comprising a crosscutting device (1) for cutting the timber, a feeder (2) for feeding the timber in its longitudinal direction to the crosscutting device, a splitting apparatus (4) operated by a splitting cylinder (3) for splitting a block cut off the timber, said feeder comprising two elongated supporting surfaces (5,6) forming a

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 79

substantially horizontal trough open in upward direction, into which the timber to be treated can be placed, characterized in that one of the supporting surfaces (5,6) is connected to a power means for moving the supporting surface back and forth … , and that the supporting surfaces (5,6) are provided with directional holding elements (7) arranged … to prevent the timber from moving in relation to the surface away from the crosscutting device (1).

The invention described in the picture and the claims can be easily understood even by a person not trained in the art of cutting wood. The parts of the machine are quite concrete and their functionality comprehendible.

4.2.3 Method and apparatus for bending and tempering glass sheets

The third example of a mechanical and traditional machine is an apparatus for bending glass sheets (EP 0778246 1995). This example is more complicated and used only for industrial purposes. The invention is an apparatus for bending a tempered glass sheet in two directions at the same time. The glass sheet is first heated and then moved to the bending unit. The advantage of the invention, in contrast to prior art, is that the sheet can be bended in two directions and harmful overheating is reduced. A picture of the machine is showed in figure 32.

Figure 32. Side view of a bending and tempering station during a bending operation.

A partial textual description of the machine in the claims of the patent application is as follows. The numbers in parentheses refer to the numbers in figure 32.

An apparatus for bending and tempering glass sheets … comprising a roll conveyor (3) consisting of rolls (4) having a relative vertical position which is variable for arching the conveyor to a curvature corresponding to desired degree of bending, lower tempering boxes (5) … and upper tempering boxes (7) …, said tempering boxes (5,7) being movable … to conform to the arching of the said

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

4 Examples of EPO patents 80

conveyor (3), wherein above said rolls (4) are provided a number of press rollers (11) capable of moving in vertical direction … applying a pressing force to the top glass surface, characterised in that the rolls (4) have their midsection deflected or deflectable downwards from the plane of the roll ends.

This invention, although more complicated than the previous two, is mostly comprehensible with no special knowledge about heating and bending glass sheets. The textual description and the picture together give a concrete view of the machine, what are its major parts, and how it functions.

4.2.4 Summary

The three patents presented above show what kind of machines and methods the patent system traditionally has been used for: the machines have physical implementations. Even highly specialized machines can be described intelligibly to a person not trained in the art, and a picture of the physical machine can be drawn.

In contrast, the machines described in the computer program patent applications have difficulty fulfilling these attributes: they have no physical implementation in the way mechanical machines do, they require more interpretation to be unambiguous than physical machines, and they have no geometric representation (Brooks 1987). The differences between the more traditional mechanical machines and the computer program machines described in patent applications is discussed in more detail in the conclusions chapter below.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

5 Conclusions 81

5 Conclusions

This chapter concludes the thesis. After having introduced the terms and concepts of patenting in EPO and gone through several computer program inventions this chapter summarizes the ideas and observations presented in previous chapters and brings forth some conclusions.

The first section discusses what kind of programs the patented inventions seem to be on the basis of the material in chapter 4. Can they be categorized into certain types of programs from software engineering point of view? The second section discusses the level of implementation in patent descriptions in the context of software production. The third section considers the inventions as descriptions and how the descriptions of computer program inventions differ from descriptions of mechanical inventions. The fourth section contemplates the problems rising from the special characteristics of software and the results presented in the previous sections. The fifth section vies the whole thesis from the problem statement’s point of view. In the last section some thoughts are given on further areas of study based on this thesis and its results.

5.1 Components and generic programs

When the inventions presented in chapter 4 are considered in the context of their application domain it is clear that their application domain is not the kind that Jackson (1995) had in mind. Jackson’s definition of application domain is for a very specific domain, e.g. a particular company’s payroll system, particular customer’s legacy system etc. The inventions presented in chapter 4 are inventions for a generic domain: word processing domain, digital image filtering domain, window user interface domain etc. This seems logical because the patent applicants probably want to maximize the width of their invention. Also the three mechanical inventions presented in chapter 4 seem to fall into this category.

A closer look of the computer program inventions shows that they can be categorized roughly into two categories: components and general programs. This is due to the nature of patents; they present practically only a single idea and several ideas should be divided into several patents.

Programs in the component category are algorithms or simple programs that are a part of a larger program or system. For example, checking for understandability and changing documents from one format to another can be thought as components of a word processing software. The other category is general programs like a general-purpose management program, designing a 3D container etc. Appendix A divides the inventions of chapter 4 into these two categories.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

5 Conclusions 82

5.2 Level of implementation

The computer programs in chapter 4 were categorized into either components or general programs. These programs have very loose specifications: the requirements for the programs are from generic domains and not specific domains. The descriptions are also on a high level of abstraction as opposed to a fully implemented program; some descriptions have pseudocode, but most have only generic natural language descriptions.

The descriptions define almost no practical implementation information, in other words the descriptions are similar to program specifications that leave many questions open to the programmer. For example, the implementation platform is defined as a general purpose computer, there is no information about testing the program, and the interfaces of the component type of programs are not defined.

When software production is thought as a simple waterfall process it goes from requirements to specifications, and from there to implementation by programming, and finally testing. The patent inventions seem to fall somewhere between requirements and specifications. So how much reading a patent description helps in implementing the program?

Another way of describing the abstraction level is to think software production as a process ranging from a problem to be solved to a specified program and finally a series of electrical signals. This view is depicted in Figure 33 where the patent descriptions are between natural language descriptions and formal programming languages.

Figure 33. Abstraction level of patent descriptions lies between natural language and a programming language.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

5 Conclusions 83

Patent descriptions give a design and specifications on a generic level but leave the testing and implementation to the reader. A lot of work may be saved by reading a patent description, but nevertheless, a large part of the work still remains undone. This poses the questions: Is the remaining implementation and testing different from traditional machines and inventions? Is there still so much work left to be done that patent descriptions are not worth reading?

5.3 Abstract machine descriptions

The width of the application domain also affects the descriptions. The more detailed implementation the description presents the less scope the patent has. As mentioned above this is not the goal of the patent applicant. Therefore the descriptions remain on a high level of abstraction in terms of implementing the software but they are also very abstract as machines.

It is worth mentioning that inventions here mean patentable inventions or inventions that have applied for a patent.

The computer program patents seem to go higher in abstraction as the technology has advanced (NRC 2000): the first inventions were close to the hardware of the computer, but the hardware has been gradually abstracted away to a general purpose platform, the peak of abstraction being user interface inventions, where the inventive step is in user convenience.

When compared to mechanical machines the computer program inventions are abstract and intangible. Computer programs are according to Brooks (1987) inherently unvisualizable and complex: they have no one representation in geometric space like mechanical machines and they have more numbers of states than their mechanical counterparts. This can be seen when the pictures and descriptions of computer programs are compared with pictures and descriptions of mechanical machines. The computer program figures and descriptions are much closer to abstract ideas than the very concrete physical pictures and descriptions of mechanical machines - the difference is clear.

To summarize the matter of descriptions: Both computer program machines and mechanical machines have a behavior that is described in the patent application. The computer program descriptions differ in that the inventions are not easily visualized, they are very complex and provide little implementation details, and the final result is intangible.

In addition to having the behavior or functionality that justifies any machine’s existence, computer programs are at the same time writings the same way a book or a document is. This poses more problems that have not been encountered when patenting mechanical machines.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

5 Conclusions 84

5.4 Problems in patenting computer programs

As mentioned above, describing a computer program invention in a patent application is difficult. The problem of describing computer programs or software is everyday life in software engineering and as Jackson (1995) put it, software engineering is making descriptions. This problem is strongly present in patenting computer programs.

The intangibility of computer programs and their dual nature as having behavior and being writings at the same time may be one reason for the ambiguous policy of the European Patent Office. Some of the ambiguity is due to the contradiction of explicitly excluding computer programs from patentability in legislation, and accepting them in practice. But also the exclusion of mathematical methods and schemes, rules and methods for performing mental acts adds to the ambiguity: computer programs are in a way mathematical methods and a set of rules for performing mental acts, so why are they explicitly distinguished from these two?

Another reason for the ambiguous policy of the EPO is that the EPO has gradually changed its practice during the last decades. The practice has been changed to include patenting of computer programs as the software industry has risen to be a significant business requiring legal protection for its products. The explicit exclusion of computer programs as such from patentability has been circumvented to a certain degree by accepting computer program patents to be granted on the basis of them having technical characteristics.

It seems that computer programs are a new kind of machines that the patent system and its practices were not ready for, but were forced to deal with.

Another problem is the generic nature of the programs patented, in other words, they are components more than stand-alone programs. This is the result of patents containing only one invention and the patent applicant’s goal of maximizing the scope of the invention. The problem is not present in the same way in traditional industries where machine components are readily available and an important part of manufacturing. In the software industry there is no similar market for components; virtually all components must be built from scratch. The problem is that a software designer usually has several thousands of components in a program and has a high risk of infringing patents without knowing it. This is not a problem in other industries where buying a component takes care of license fees or royalties. (Samuelson et al. 1994)

The lack of an extensive component industry similar to mechanical industry, and having no comprehensive prior art knowledge of computer programs in patent offices have partly caused that there is no certain knowledge of the level of technology present in computer programs. In other industries the patent office prior art libraries and databases are accurate representations of the level of

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

5 Conclusions 85

technology. As a result of this, it is quite hard to tell when a patentable computer program invention is novel or obvious in the context of the level of technology. An example of this are the so-called bad patents that have been granted due to the lack of knowledge, in patent offices, of the level of technology.

5.5 Problem statement

The purpose of this thesis was to study European Patent Office’s Board of Appeals’ decisions concerning computer program patents for any clear practice on patentability of computer programs. Twenty-one decisions were analyzed and studied more from an engineering point of view rather than a juridical perspective. The result of the study was that there is no clear and unambiguous practice in the patentability of computer programs.

It seems that the practice is forming and stabilizing around certain principles, i.e. technical character and viewing the inventions as a whole rather than viewing only the inventive part. Nevertheless, these principles are not clear in the context of computer programs, because they are adopted form the context of more traditional inventions where several decades of practice have made them sufficiently explicit.

Difficulties in defining computer program inventions for patenting rise from the problems presented in above sections. First of all, the young age and the fast development of the discipline are reasons for the patent offices’ insufficient knowledge of the level of technology, or state of the art, in computer programs. Secondly, the special nature of computer programs has introduced problems previously unaccounted for, e.g. the dual nature of computer programs, or their inherent invisibility and complexity.

This thesis does not provide any distinct resolutions to the problems involved in patenting computer programs in Europe. The thesis has identified and pointed some major problems that are probable causes for these problems. The thesis has also defined the obscure terms and concepts involved in patenting computer programs.

Nevertheless, it is quite clear that the answers to these problems can be reached by widening the understandability of computer programs and patents. First of all, the patent offices are facing the tremendous job of defining the state of the art in the field of computer programs if bad patents are to be avoided. Secondly, a deeper understanding of the characteristics of computer programs is needed in the context of intellectual property rights. This understanding involves a broader perspective to computer programs than computer science and legal science can solely provide. It seems to involve the history of science and technology to understand the significance of inventions in general, also the problems

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

5 Conclusions 86

encountered in describing and defining are present whenever any kind of metrics is required, and the economic science around patenting is an integral part of justifying the patent system.

5.6 Further research

This thesis has been a study of computer program patent applications that reached the EPO Board of Appeals. The generalizations made here may be therefore little biased, but nevertheless, they present quite comprehensively the Board’s view of the matter. All of the main themes in this thesis are worth further investigation: What does the abstract nature of software mean in juridical context? How should the legislation take into consideration the special nature of software? Does the component or generic nature of the patented inventions affect the software industry?

Further study could also be made on patent infringements and legal cases, i.e. how are computer program patents handled and used after the granting process, or what kind of protection the patent gives to a computer program in practice? This thesis focused solely on the granting process.

Some of the other questions that rose from studying the material for this thesis are also worth further considerations. For example, clear definitions on what is the difference between mathematical methods and computer programs, or what is the difference between computer programs and schemes, rules and methods for performing mental acts. Other questions were also encountered: Can there ever be a deterministic system for patenting computer programs? Would an explicitly defined patent specification language solve some of the problems in describing the inventions? Could software engineering principles and practices be adapted to patenting?

One of the big questions that dominates the discussions is that are the problems with patenting computer programs due to software’s fundamental differences in contrast to other inventions, or are the difficulties encountered only a result of patent offices not working properly and will it be remedied if they catch up with the progress.

One goal of this thesis was to shed some light to the ongoing discussions about software patents. One of the big problems is misunderstanding of legal terms and technical concepts by the different parties of the discussions. Hopefully this study enriches the discussions on patenting computer programs.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

References a

References

EPO Technical Board of Appeals’ decisions

T 0006/83. Data processor network. International Business Machines Corporation. 6.10.1988.

T 0208/84. Computer-related invention. Vicom. 15.7.1986.

T 0022/85. Document abstracting and retrieving. International Business Machines Corporation. 5.10.1988.

T 0052/85. Method of generating a list of expressions semantically related to an input linguistic expression. International Business Machines Corporation. 16.3.1989.

T 0115/85. Computer-related invention. International Business Machines Corporation. 5.9.1988.

T 0026/86. X-ray apparatus. Koch & Sterzel GmbH & Co. 21.5.1987.

T 0038/86. Text processing. International Business Machines Corporation. 14.2.1989.

T 0158/88. Character form. Siemens Aktiengesellschaft. 12.12.1989.

T 0216/89. Data communication system with capabilities to analyse an error or problem condition. International Business Machines Corporation. 11.10.1990.

T 0109/90. Methodology for transforming a first editable document form. International Business Machines Corporation. 28.9.1993.

T 0071/91. An electronic document distribution network with uniform data stream. International Business Machines Corporation. 21.9.1993.

T 0236/91. Menu-based natural language understanding system. Texas Instruments Incorporated. 16.4.1993.

T 0164/92. Electronic computer components. Robert Bosch GmbH. 29.4.1993.

T 0769/92. General-purpose management system. Sohei, Yamamoto, et al. 31.5.1994.

T 0790/92. Editing business charts. International Business Machines Corporation. 29.10.1993.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

References b

T 0887/92. Method for providing an on-line help facility for interactive information handling systems. International Business Machines Corporation. 19.4.1994.

T 0059/93. Method for interactive rotation of displayed graphic objects. International Business Machines Corporation. 20.4.1994.

T 0094/93. Hierarchical selection. International Business Machines Corporation. 17.10.1994.

T 0204/93. System for generating software source code components. American Telegram and Telegraph Company. 29.10.1993.

T 0605/93. Method and apparatus for designing three-dimensional container. Dai Nippon Insatsu Kabushiki Kaisha. 20.1.1995.

T 0935/97. Method and system in a data processing system windowing environment for displaying previously obscured information. International Business Machines Corporation. 4.2.1999.

EPO patent applications

EP 0001640. Röntgeneinrichtung. Koch & Sterzel GmbH & Co. Essen, Germany. 78101198.6. 23.10.1978.

EP 0005954. Method and apparatus for improved digital image processing. Image Associates Inc. Malibu, USA. 79300903.6. 22.5.1979.

EP 0006216. Improvements in digital data processing systems. International Business Machines Corporation. Armonk, USA. 79101907.8. 12.6.1979.

EP 0032194. Method and system for automatically abstracting, storing and retrieving a document in a machine readable form. International Business Machines Corporation. Armonk, USA. 80107625.8. 4.12.1980.

EP 0052757. Method of decoding phrases and obtaining a readout of events in a text processing system. International Business Machines Corporation. Armonk, USA. 81108567.9. 20.10.1981.

EP 0054667. Method of generating a list of expressions semantically related to an input linguistic expression. International Business Machines Corporation. Armonk, USA. 81108566.1. 20.10.1981.

EP 0068093. Data communication system with capabilities to analyse an error or problem condition. International Business Machines Corporation. Armonk, USA. 82103335.4. 21.4.1982.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

References c

EP 0093250. Automatic text grade level analyser for a text processing system. International Business Machines Corporation. Armonk, USA. 83102553.1. 15.3.1983.

EP 0108899. An electronic document distribution network with uniform data stream. International Business Machines Corporation. Armonk, USA. 83109604.5. 27.9.1983.

EP 0109614. Methodology for transforming a first editable document form. International Business Machines Corporation. Armonk, USA. 83111221.4. 10.11.1983.

EP 0118187. Menu-based natural language understanding system. Texas Instruments Incorporated. Dallas, USA. 84300515.8. 27.1.1984.

EP 0126054. Means for cleaning floor. Heinonen, Ahti. Kisko, Finland. 84850154.0. 16.5.1984.

EP 0144656. Verfahren und Anordnung zum Darstellen von Schriftzeichen an einer Anzeigeeinheit. Siemens Aktiengesellschaft. Munich, Germany. 84112599.0. 18.10.1984.

EP 0163670. Vorrichtung zur Überwachung von elektronischen Rechenbausteinen, inbesondere Mikroprozessoren. Robert Bosch GmbH. Gerlingen-Schillerhöhe, Germany. 84904096.3. 2.11.1984.

EP 0180021. Hierarchical selection. International Business Machines Corporation. Armonk, USA. 85111748.1. 17.9.1985.

EP 0190419. Method for providing an on-line help facility for interactive information handling systems. International Business Machines Corporation. Armonk, USA. 85114955.9. 26.11.1985.

EP 0192022. Method for interactive rotation of displayed graphic objects. International Business Machines Corporation. Armonk, USA. 86100112.1. 7.1.1986.

EP 0196430. Editing business charts. International Business Machines Corporation. Armonk, USA. 86101872.9. 14.2.1986.

EP 0209907. Computer system for plural types of independent management and method for operating a general purpose computer management system. Sohei, Yamamoto; Moriyama, Teruko. Japan. 86110223.4. 24.7.1986.

EP 0219993. System for generating software source code components. American Telegram and Telegraph Company. New York, USA. 86307473.8. 30.9.1986.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

References d

EP 0229849. Method and apparatus for designing three-dimensional container. Dai Nippon Insatsu Kabushiki Kaisha. Tokyo, Japan. 86904369.5. 5.7.1986.

EP 0767419. Method and system in a data processing system windowing environment for displaying previously obscured information. International Business Machines Corporation. Armonk, USA. 96305851.6. 9.8.1996.

EP 0778246. Method and apparatus for bending and tempering glass sheets. Tamglass Engineering Oy. Tampere, Finland. 95119315.0. 7.12.1995.

EP 1118438. Chopping machine for cutting and splitting timber. Pitkäniemi, Timo. Kuukanniemi, Finland. 01660003.3. 9.1.2001.

Books

Beresford, K. 2000. Patenting Software under the European Patent Convention. London. Sweet & Maxwell.

Cornish, W.R. 1989. Intellectual Property: Patents, copyright, trade marks and allied rights. 2nd edition. London. Sweet & Maxwell.

Jackson, M. 1995. Software Requirements & Specifications, A Lexicon of Practice, Principles and Prejudices. Harlow. Addison-Wesley.

Laddie, H.; Prescott, P.; Vitoria, M.; Speck, A.; Lane, L. 2000. The Modern Law of Copyright and Designs. 3rd edition. London. Butterworths.

NRC (National Research Council). 2000. The Digital Dilemma, Intellectual Property in the Information Age. Washington D.C. National Academy Press.

Patterson, D.A.; Hennessy, J.L. 1998. Computer Organization & Design, The Hardware / Software interface. 2nd edition. San Francisco. Morgan Kaufman Publishers, Inc. p.33.

Sommerville, I. 1995. Software engineering. 5th edition. Harlow. Addison-Wesley.

Other references

500 years of patents (2000) UK Patent Office. [online] [cited 15.9.2001] < http://www.patent.gov.uk/patent/history/fivehundred/>

Bezos, J. 2000. An Open Letter from Jeff Bezos on the Subject of Patents. [online].

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

References e

[cited 30.8.2001]. <http://www.amazon.com/patents/>

Brooks, F.P. 1987. No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer, vol 20, no 4. p. 10-19.

Diamond v. Diehr. 1981. 450 U.S. 175.

Encyclopædia Britannica. 2001. [online]. [cited 30.8.2001]. <http://www.britannica.com/>

EPC (European Patent Convention). 2000. [online]. 10th edition. [cited 21.8.2001]. <http://www3.european-patent-office.org/dwld/epc/epc_2000.pdf>

EPO (European Patent Office) website. 2001. [online]. [cited 22.8.2001].

The Franklin Pierce Law Center Intellectual Property Library User’s Guide. (1998) Famous United States Patents. [online].[cited 21.8.2001] <http://www.ipmall.fplc.edu/userguid/user11.htm>

FSF (Free Software Foundation). 1996. Saving Europe from Software Patents. [online]. [cited 21.8.2001]. <http://www.gnu.org/philosophy/savingeurope.html>

Gottschalk v. Benson. 1972. 409 U.S. 63.

Guidelines for Examination in the European Patent Office. 2001. European Patent Office. Munich.

Hakulinen, Y.J. 1945. Keksijän oikeussuojasta. K.J.Ståhlberg Juhlajulkaisu. Vammala. Suomalainen Lakimiesyhdistys. p. 383-421.

Harmon, A. 2000. New Economy; With music widely available online, is it now time to tighten copyright laws or consider rewriting them to reflect reality? The New York Times. 2.10.2000.

Heckel, P. 1992. Debunking the Software Patent Myths. Communications of the ACM, vol 35, no 6.

IEEE Std 610.12-1990, Standard Glossary of Software Engineering Terminology. 1990 New York. The Institute of Electrical and Electronics Engineers.

Implementing Regulations to the convention on the Grants of European Patents. 1999. [online]. Amended edition. [cited 21.8.2001]. <http://www3.european-patent-office.org/dwld/epc/epc_2000.pdf>

Kruchten, P. 1995. The 4+1 View Model of Architecture. IEEE Software, vol 12, no

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

References f

6. pp.42-50

Lessig, L. 1999. The Problem with Patents. [online]. The Industry Standard. [cited 22.8.2001]. <http://www.thestandard.com/article/0,1902,4296,00.html>

Liesegang, E. 1999. Software Patents in Europe. Computer and Telecommunications Law Review, vol 5, issue 2. p. 48-51

LPF (League for Programming Freedom). 1991. Against Software Patents. [online]. [cited 21.8.2001]. <http://lpf.ai.mit.edu/>

Merriam-Webster On-line Collegiate Dictionary. 2001. [online]. [cited 19.5.2001]. <http://www.m-w.com/>

Newman, J. 1997. The Patentability of Computer-related Inventions in Europe. European Intellectual Property Review, vol 19, issue 12.

Parker v. Flook. 1978. 437 U.S. 584.

Patent wars. 2000. The Economist, Apr 8th 2000.

PbT Consultants. The Results of the European Commission Consultation Exercise on the Patentability of Computer Implemented Inventions. [online]. [cited 21.8.2001]. <http://europa.eu.int/comm/internal_market/en/indprop/softanalyse.pdf>

Protection of Software-related Inventions in Europe and Japan. 1996. [online]. Ladas & Parry. [cited 30.8.2001] <http://www.ladas.com/>

Samuelson, P.; Davis, R.; Kapor, M.D.; Reichman, J.H. 1994. A Manifesto Concerning the Legal Protection of Computer Programs. Columbia Law Review, vol 94, no 8.

What is a patent? 2000. UK Patent Office website. [online]. [cited 6.9.2001] < http://www.patent.gov.uk/patent/definition.htm >

van den Berg P., 1996. Patentability of Computer-Software-related inventions. The Law and Practice of the Enlarged Board of Appeals of the European Patent Office.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

Appendix A g

Appendix A

The table in this appendix presents the terms introduced in section 3.3 in Finnish. The Finnish legal practice concerning patenting does not use these terms in the same way as the EPO practice: the EPO practice builds its approach to technicality very much on these terms. Therefore, the translation in Finnish does not have such an exact meaning as the English word. In other words, the Finnish words do not have the same connotations in Finnish patent law. Especially the word for technical effect, tekninen teho, has a very different meaning in Finnish law: it means that the invention must function as described in the patent application, not that it must have a technical effect as described in section 3.3.7.

English word Finnish translation

Technical character Tekninen luonne

Technical nature Tekninen luonne

Technical contribution Tekninen kontribuutio

Technical problem Tekninen ongelma

Technical effect Tekninen teho

Technical features Tekniset ominaisuudet

Technical considerations Tekninen harkinta

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

Appendix B h

Appendix B

Invention Technical character

Comments made by the Board

Vicom/Computer-related invention

Technical effect

Technical effect in modifying a physical entity; a digitized image.

IBM/Document abstracting and retrieving

None The subject-matter was not of technical character, but a rule for a mental act.

IBM/Generating a list of expressions

None The subject-matter was in a non-technical field of linguistics as such.

IBM/Text processing None Method was a mere automation of a mental act.

Siemens/Character form None No technical effect beyond information processing.

IBM/Data communication system Technical effect

Transforming a signal in which the represented text remains unchanged is technical.

IBM/Data processor network Technical problem

The problem solved was considered essentially technical.

IBM/Document distribution network

Technical problem

Linguistic meaning of words was irrelevant and therefore the not a linguistic problem.

IBM/Displaying of pre-determined messages

Technical problem

Displaying system events to a user is a technical problem.

Koch & Sterzel / X-ray apparatus Technical effect

The computer program produced a technical effect in the X-ray apparatus.

IBM/Editable document form Technical effect

Transforming digital data representing hardware control items was a technical effect.

Bosch/Electronic computer component

Technical effect

Shortening the restarting of programs.

Sohei/General-purpose management system

Technical considerations

Technical considerations had to be carried out before programming could start.

IBM/Editing business charts None Operations on information content which were not considered technical.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

Appendix B i

IBM/On-line help facility Technical problem

Technical problem solved in making the known help facilities more efficient and convenient for the user.

IBM/Interactive rotation of displayed graphics

Technical problem

Technical problem was solved in enabling the user to perform finer control of the rotate action.

IBM/Hierarchical selection Technical problem

The features of the invention were considered to solve a technical problem of improving the method of selection.

DAI/Designing 3D container Technical features

The container represented a physical entity and the input functionality was found to be technical.

IBM/Windowing Technical effect

Technicality was not directly commented by the Board.

Texas Instruments/Menu-based understanding system

Technical effect

Inputting of a command was considered controlling of a computer which normally has a technical effect.

AT&T/System for generating software source code

None Programming was not patentable irrespective of whether the resulting program could be used to control a technical process.

Means for cleaning floor - Not commented by the Board.

Chopping machine for cutting and splitting timber

- Not commented by the Board.

Method and apparatus for bending and tempering glass sheets

- Not commented by the Board.

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

Appendix C j

Appendix C

Invention Type Comment

Vicom/Computer-related invention

General A general independent program that could also be a component

IBM/Document abstracting and retrieving

General / Component

A component of a word processor or an independent program

IBM/Generating a list of expressions

Component Most probably a component of a word processor or a text editor

IBM/Text processing Component Most probably a component of a word processor or a text editor

Siemens/Character form Component Most probably a component of a word processor or a text editor

IBM/Data communication system Component A component in a network

IBM/Data processor network Component A component in a network operating system

IBM/Document distribution network

Component A component in a network word processing system

IBM/Displaying of pre-determined messages

Component A component of a word processor or a text editor

Bosch/Electronic computer component

Component A component of an operating system

Sohei/General-purpose management system

General General program by definition

IBM/Editing business charts Component A component of a spreadsheet or similar program

IBM/On-line help facility Component A component of any program that provides help to the user

IBM/Interactive rotation of displayed graphics

Component A component of a graphics program

IBM/Hierarchical selection Component A component of a graphics program

DAI/Designing 3D container General A general program for designing; could be a feature or component of a general designing program

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute

Appendix C k

IBM/Windowing Component A component of operating system windowing

Texas Instruments/Menu-based understanding system

Component A component of any program with a natural language user interface

AT&T/System for generating software source code

General A general program for generating source code

Means for cleaning floor General A general floor mop

Chopping machine for cutting and splitting timber

General A general machine for cutting and splitting wood

Method and apparatus for bending and tempering glass sheets

General / Component

A general independent machine or part of a technical process

Risto Sarvas A software engineering view to the decisions of the European Patent Office concerning computer programs

HELSINKI UNIVERSITY OF TECHNOLOGY Computer Science and Engineering

Software Business and Engineering Institute