THESIS - RESEARCH MASTER INFORMATION LAW
Error 52(2)(3)/101: Software as (Un)Patentable Subject Matter
A comparative analysis of the legal standards for software patent protection in
Europe and the United States.
Abstract
This thesis discusses the patentability of software in both Europe and the United States. The main question to be addressed is whether the exclusion of software from patent protection is still meaningful in light of its historical development and current application, and whether there is still room for improvement. After an analysis of the history and current legal standards under which software can be patented, this thesis turns to a comparison of both legal systems and finds that their overall historical development is surprisingly similar. This thesis will also show that, contrary to general belief, it is currently more difficult to obtain patent protection for software in the United States than in Europe. Ultimately, this thesis concludes that the exclusion of software from patent protection is outdated and leads to unnecessary complexities. In this regard, various problems related to software patents, such as the monopolization of building blocks, patent thickets and high litigation risks are discussed as well. In light of the aforementioned, the final part of this thesis discusses possible improvements to both patent systems in order to reduce “bad software patents” and to enhance legal certainty.
AUTHOR:
Alexander D. de Leeuw
DATE:
3
rdof December, 2014
STUDENT NR:
6039944
TABLE OF CONTENTS 1. INTRODUCTION ……….…………..………. 5 2. RESEARCH FRAMEWORK ……….……… 8 2.1. Research Question ………...………..………..……….………. 8 2.2. Hypothesis ………. 9 2.3. What is Software? ………...……….……….……. 10 2.3.1. Mathematical Methods ………..…..…………..……… 11
2.3.2. Methods for Doing Business .……..……….…….….… 12
2.3.3. Machine Software versus Business Method Software ………….………….. 13
2.4. Interim Conclusion ……….………14
3. LEGAL FRAMEWORK IN EUROPE AND THE UNITED STATES ……….……. 15
3.1. Legal Framework in Europe ……….. 15
3.1.1. Statutory Exclusion of Software: Art.52 EPC ……..….…..….……….…… 15
3.1.2. Non-Patentable Subject Matter “As Such” ……...……….….. 17
3.1.3. Background of the “As Such” Provision ……...………..…... 18
3.2. Legal Framework in the United States ………...……21
3.2.1. United States Patent Act / 35 U.S.C. .….……….………..…… 22
3.2.2. History of 35 U.S.C. 101 ……….………….………….……… 23
3.2.3. Diamond v. Chakrabarty: Broad Interpretation of
§
101 …….………….… 253.2.4. Judicial Exclusion: Laws of Nature, Physical Phenomena and Abstract Ideas ………..… 26
3.3. Interim Conclusion ………...….. 29
4. DEVELOPMENT AND CURRENT LEGAL STANDARD IN EUROPE …...………….… 32
4.1. Interpretation of Article 52 by the European Patent Office ………...…. 32
4.1.1. Technical Character ………... 32
4.1.2. Technical Contribution to the Prior Art …….…………..…………... 33
4.1.3. Technical Effect ………..……... 35
4.1.4. Further Technical Effect ………..…….. 36
4.1.5. Combination of Software and Hardware ……….……..……….... 38
4.1.6. Contradictions & Other Relevant Considerations .. ………... 42
4.2. Enlarged Board of Appeal in G 3/08 ………. 43
4.2.1. Difference v. Divergence ………... 44
4.2.2. Assessment of Contribution Approach …. ………. ………... 45
4.2.3. Assessment of Combination Approach …. ……….... 46
4.2.4. Assessment of Further Technical Effect Approach ………... 46
4.3. What is the Current Legal Standard? ……….…..…………... 47
4.4. Business Method Software ……… 49 2
4.4.1. Business Method Software under the Combination Approach ……….. 49
4.4.2. Business Method Software under the Further Technical Effect Approach ………. 50
4.5. Interim Conclusion ……….…… 51
5. DEVELOPMENT AND CURRENT LEGAL STANDARD IN THE UNITED STATES .... 52
5.1. Interpretation of
35 U.S.C. 101 by U.S. Courts
…………...….………….... 525.1.1. Point of Novelty Approach ……….... 53
5.1.2. Freeman-Walter-Abele Approach ……….. 55
5.1.3. Machine-or-Transformation Approach ……….. 58
5.1.4. Useful, Concrete and Tangible Result Approach ……….. 60
5.1.5. Significant Additional Features Approach ……….... 64
5.1.6. Most Recent Ruling: Alice Corporation v. CLS Bank ………..……. 67
5.2. What is the Current Legal Standard? ………...…….. 70
5.3. Business Method Software ……… 71
5.3.1. Business Method Software under the Machine-or-Transformation Test ……….……….. 71
5.3.2. Business Method Software under the Significant Additional Features Approach ………..… 72
5.4. Interim Conclusion ……..………..………...…..74
6. COMPARISON OF BOTH LEGAL SYSTEMS ..………….………...………..……….…. 75
6.1. Comparison of Legal Standards ………...………... 75
6.1.1. The General Historical Development of Software Patentability ……...…… 75
6.1.2. The Specific Characteristics of Both Legal Systems ………..………... 77
6.1.3. Comparison of the Current Legal Standards ……….….79
6.2. Is the EPC Exclusion Clause Eroded? ………... 81
6.2.1. Original Intention Behind the Exclusion Clause – Travaux Préparatoires ………... 81
6.2.2. Original Intention Behind the Exclusion Clause – Case Law …………..…. 83
6.2.3. Has the Exclusion Clause Become Meaningless? ….……….………... 84
6.3. Is § 101 of the U.S. Patent Eroded?…………...………...…….……….. 85
6.3.1. Original Intention Behind § 101 – Case Law ……… 85
6.3.2. Has the U.S. Invention Hurdle Become Meaningless? ..………...……... 87
6.4. Problems Faced in Both Legal Systems ……….88
6.4.1. Overly Broad Patents ………...………..………… 88
6.4.2. Patent Thickets and Patent Trolls ………...………... 91
6.4.3. Defensive Patenting and Litigation Risks ………..……… 92
6.4.4. Lack of Interference by Lawmakers ………..……… 95 3
6.4.5. How to Formulate a Clear-Cut Legal Standard ………. 96
6.5. Interim Conclusion ……..……….…………..97
7. POSSIBLE IMPROVEMENTS TO PATENT LAW ………...……… 99
7.1. Further Limiting Patent Protection for Software …………..………..…………...…… 99
7.2. Abandon the Exclusion of Software ……...…………..……...……. 101
7.3. Exclude Subject Matter Through Other Patentability Requirements ………...…. 103
7.4. Combination of Improvements ……….. 106 7.5. Interim Conclusion ………. 109 8. CONCLUSION ………...………. 111 9. BIBLIOGRAPHY ………...………. 115 10. APPENDIX I ……….. 131 4
1. INTRODUCTION
Smartphones, computers and other electronically operated devices play an increasingly
important role in society, and represent an area of technology in which there is vast progress
and an ever accelerating pace of innovation. Take smartphones for example: new models are
presented on a yearly basis, there are high expectations of which and how many new features
are included, and many people are keen on getting their hands on these latest models. The
hardware in these devices is without a doubt patentable if it lives up to the three basic
requirements of novelty, inventiveness and industrial applicability. Patent law was originally
created to protect such tangible inventions. For another, and increasingly large part, the
innovation in such devices lies in the software, or a combination of software and hardware,
that is used to operate them. The innovation is then found in an intangible, rather than
tangible medium, which caused different legal systems to have problems in implementing
these inventions into the their legal framework for patent protection.
1The first question that might arise is why protection is sought under patent law, as opposed to
copyright law. It is fairly easy to get copyright protection. All that is required is a sufficiently
original expression in order to obtain protection for as long as 70 years after the author’s
death. This means that it is a low cost protection model with a long period of protection.
However, the scope of protection under copyright law is often too narrow for software; it
basically comes down to the protection of verbatim copies, and in some cases slight
adaptations of the work. This is assumed to be one of the most important reasons for software
developers to turn to patent law. The scope of protection provided by a patent is broad. A
patent provides a very strong monopoly, which is hard to circumvent by competitors. In
essence, it allows the applicant to obtain protection for the underlying idea, something that
copyright explicitly does not. Additionally, software developers usually do not need a term of
protection of 70+ years. Software is constantly changing and what is new at this moment is
often outdated in one to five years. Thus, patent law seems better suited for the kind of
protection that software developers seek. In light of the above, and however interesting it
might be, it goes beyond the scope of this thesis to discuss copyright protection for software
any further.
1 The term “invention” might be confusing in this regard: under the European Patent Convention, “software as such” is excluded from patentability as not being an invention. This will be further addressed in subsequent parts of this thesis.
5
Given the fact that the development of new software requires a considerable amount of time
and investment, and copying it is relatively easy and cheap, the assumption is that a certain
level protection is justified.
2On the other hand, if protection is for things that are too abstract,
this might actually stifle innovation instead of promote it, which would be contrary to the
purpose of patent law. Thus, a proper balance must be struck between these two
countervailing considerations.
In Europe, this concern is reflected in Article 52(2) of the European Patent Convention
(“EPC”). According to this provision, several categories of subject matter are excluded from
patent protection as not being an invention. Software is one of those excluded categories. It is
important to note, however, that according to Article 52(3) EPC, software is only excluded
“as such”. There is a large quantity of case law on the interpretation and application of this
exclusion clause, which will be thoroughly analysed in order to describe the historical
development and the current standard as applied by the European Patent Office (“EPO”).
The legal framework for patent protection in Europe is somewhat different from that in the
United States (“U.S.”), the most important difference being that there are no statutorily
excluded categories of subject matter in the latter. Thus, the starting point seems to be that
“anything under the sun that is made by men” is patentable, as also stated in Diamond v.
Chakrabarty.
3However, in the same case it was also mentioned that “laws of nature, physical
phenomena and abstract ideas” are not patentable.
4This creates difficulties for obtaining
patent protection for software, because software leans close towards being an abstract idea or
law of nature. As a result, several criteria under which a patent can be obtained for software
have developed in subsequent case law. These cases will be analysed and compared to EPO
case law on the same matter.
Despite the fundamental differences of the legislative frameworks, similarities can be found
through this comparative analysis. Both comprise the notion that not all is patentable, of
which software is a striking example, and both legal systems struggle with how to give shape
to the conditions under which software can nonetheless be patented. This makes it interesting
to compare these two legal systems.
2 Deschamps 2011, p.104; Bakels & Harison 2005, p.35. Economic theories about the desirability of patent protection for software will be discussed only to a limited extent.
3 Diamond v. Chakrabarty.
4 Diamond v. Chakrabarty; Parker v. Flook; Gottschalk v. Benson.
6
In short, and given the abovementioned, this thesis will look at whether the exclusion of
software from patent protection is still meaningful in light of its historical development and
current application under the EPC and in the U.S. In both legal systems, there is confusion as
to what the current legal standard for software patents is. Mapping out and comparing the
development of software patentability criteria in both systems will help to define the current
legal standards, and diminish legal uncertainty as to when exactly software can be patented.
The comparative analysis will show that even though both legal systems seem to have
different starting points at first sight, similar criteria are used and similar problems are faced,
which might enable one system to learn from the other. Thus, the comparison will show the
overall development of both legal systems. Examples of the problems that will be discussed
in this regard, are overly broad patents, litigation risks and the stifling of innovation.
Combined with the increased importance of software, these problems are reason to examine
whether the current standard of protection for software is still meaningful. The final part of
this thesis will explore and propose possible improvements to the patent system.
2. RESEARCH FRAMEWORK
2.1. Research Question
The research question that will be addressed and answered in this thesis is:
Is the exclusion of software from patent protection still meaningful in
light of its historical development and current application and is there
room for improvement?
This question will be addressed through a threefold comparison between the European and
U.S. patent system.
The first element of the research question consists of mapping the historical development of
software patents (Chapter 3). Many changes have been made with regard to the conditions
under which software could be patented. The historical overview sheds light on the context in
which these changes must be viewed, and on the original thoughts on software patents. This
will show why the framers of the EPC excluded software from patent protection, why the “as
such” provision was added to Art.52 EPC, why software is not statutorily excluded in the
U.S., and whether there are other exclusionary rules under U.S. patent law.
The second element of the research question lies in determining what the current criteria are
under which software can constitute an invention (Chapter 4 and 5) and how they have
developed.
5These criteria will be addressed with the overarching term “the current legal
standard”. Due to a vast amount of diverging and constantly developing case law, the current
legal standard is vague and not yet properly defined.
6However, it is essential to have an
understanding of what this standard is before conclusions can be drawn with regard to the
current system’s functioning. Therefore, common elements in recent case law will be
compared to expose the current patentability criteria for software.
7The abovementioned elements create a framework for the third element of the research
question. This consists of a comparison between software patents under the EPC and under
5 This is also relevant in light of finding a possible solution to the problems caused by software patents, as the historical development shows which roads have already been taken in the past and which have been successful.
6 Wisecup 2013, p.1653; Lambilotte 2012, p.639; Pierce 2012, p.186; Bakels 2009, p.514; Zekos 2006, p.434. 7 The terms “patentability” and “patent-eligibility” will be used interchangeably.
8
U.S. patent law, to point out the similarities between both legal systems (Chapter 6).
8The
problems that both systems face with the implementation of software into the existing patent
frameworks will also be compared. This comparison opens the door to the core assessment of
whether excluding software under separate patentability criteria is a practice to be embraced
or to be abandoned, and whether there is room for possible improvements (Chapter 7).
2.2. Hypothesis
The hypothesis on which this thesis is based is:
The criteria used to exclude software from patent protection have
become vague and meaningless, and the similarities between both
legal systems will show that it would be better to abandon the
categorical exclusion of software from patent protection.
The fundamental difference between European and U.S. patent law is that there is no
statutory exclusion of software in the latter.
9Despite this difference, however, both legal
systems comprise the notion that something as intangible as software requires a separate legal
standard. Thus, in both legal systems specific criteria have been developed to determine
whether patent protection can be afforded to software in a given case.
10Although the
historical development and the terminology is different in both systems, it is expected that a
similar reasoning is used to exclude software, and that a similar result is achieved.
11The
problems associated with software patents are also expected to be similar. This creates a
middle ground that has not yet been explored.
Based on these similarities, the meaningfulness of the current legal standard for the exclusion
of software patents will be assessed. Currently, the European statutory exclusion of software
seems to be eroded and the early U.S. freedom of patenting seems to be drastically limited,
which has an effect equivalent to the statutory exclusion originally found in the EPC.
12Thus,
a vicious circle unfolds. There is no coherency in the criteria, nor in the development thereof,
and there is an ongoing discussion about how to apply the patentability criteria in practice.
Neither system has as of yet arrived at a satisfactory result.
8 The relevance of a comparison to the U.S. was also highlighted in Guarda 2012, p.450.
9 Guarda 2013, p.452; Sterckx & Cockbain 2010, p.396, note 3; Rosser 2005, p.25; Hart, Holmes & Reid 2000, p.16 & 23. 10 Zekos 2006, p.427.
11 Struik 2010, p.353; Rosser 2005, p.27; Ferro 2002, p.372. 12 Valgaeren 2004, p.37; Cook 2000, p.123.
9
In light of the above, the comparison between the approaches taken in both legal systems is
expected to show that any set of criteria aimed at categorically excluding software from
patent protection will face insurmountable difficulties. Therefore, it seems necessary to
reconsider how to deal with software patents. The expected conclusion is that it is not
desirable to maintain separate patentability criteria for software, and that solutions can be
found in the well-known patentability criteria of novelty and inventiveness.
2.3. What is Software?
Software patents cause a great deal of confusion due to the complexity of the subject matter
involved.
13No clear definition of software can be found in the EPC, Section 35 of the United
States Code (“U.S.C.”) nor in case law of either one of the jurisdictions.
14Yet, many scholars
and judges discuss software as if it is a clear-cut and demarcated concept, or something in the
category of you know it when you see it. The lack of a clear definition is problematic, as it
causes discussions on substantively different topics under the same denominator.
15A properly demarcated definition needs to be narrow and technology bound to some extent.
Otherwise the definition will become too broad, vague and thereby meaningless. But when
the definition is too narrow it will quickly lose its practical significance. Due to the fear that
technical developments (which occur quickly in the realm of software) will easily transcend a
static or technology bound definition, only few have tried to define software.
16And in the
rare instance that software is defined, it usually does not go beyond a very broad definition.
In general, software can best be described as a set of instructions that, when incorporated in a
machine-readable medium, is capable of causing a machine having information-processing
capabilities to achieve a particular result.
17It is safe to say that it is probably impossible to
13 Bakels & Hugenholtz 2002, p.20.
14 The EPO explicitly notes that “software” is an ambiguous concept, and prefers the term “computer-implemented invention” over “software”. See http://www.epo.org/news-issues/issues/software.html (last visited 1 December 2014). In the EPC itself, the term “programs for computers” is used, as can be seen in the statutory exclusion of Art.52(2)(c) EPC. 15 Ferro 2002, p.369, note 9.
16. This is a problem that is hard to circumvent.
17 This is the author’s own definition, based on the Model Provisions on the Protection of Computer Software, Genève: WIPO 1978 (“a set of instructions capable, when incorporated in a machine-readable medium, of causing a machine having information-processing capabilities to indicate, perform or achieve a particular function, task or result”), Section 17 U.S.C. §101 (“a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result”), and literature, examples of which are Seltzer 2012, p.944 ("Software is the instructions given to a computing device to make it function."); Zekos 2006, p.426-427 (citing Section 17 U.S.C. §101 and describing software as “algorithms and procedures carried out by software programs, descriptions of software written in a natural language, source code written on paper or stored in a computer’s memory […]”); Sterckx & Cockbain 2010, p.373 (“A program for computers may
10
give a more detailed definition of software that will fit all circumstances.
18For purposes of
consistency and clarity, however, the following paragraphs contain an overview of the
various (sometimes overlapping) categories that can fall within the scope of the term
software. This includes mathematical methods and methods for doing business.
19A
distinction that will prove to be important in a subsequent part of this thesis is that between
“machine software” and “business method software”, which will also be described.
The term “computer implemented invention” is commonly used in connection with software
patents.
20This does not mean that it only relates to inventions that are to be applied on
personal computers, such as desktop computers and laptops. As described in the EPO
Guidelines, computer implemented inventions are "claims which involve computers,
computer networks or other conventional programmable apparatus [...]".
21It relates to any
machine having information-processing capabilities, also known as electronically operated
devices, and is used to describe an invention that needs some form of software in order for it
to achieve the desired result.
22In light of this broad interpretation of what constitutes a
computer, the term computer program will be used interchangeably with the term software.
2.3.1. Mathematical Methods
Mathematical methods are the first aspect to consider when discussing software. The EPC
makes a notable distinction between mathematical methods and programs for computers.
Mathematical methods are excluded from patent protection under Art.52(2)(a) EPC, and
computer programs under Art.52(2)(c) EPC.
23The fact that mathematical methods are
mentioned in a separate paragraph, gives the impression that these are two distinct categories
that are not related to one another. However, mathematical methods, also known as
thus be seen to be a series of instructions which, when installed on a computer, changes an otherwise functionless piece of equipment into one capable of producing a desired result.”); Guadamuz González 2006, p.1, note 2 (citing Section 17 U.S.C. §101); Laub 2006, p.346 (“The term [software] equally describes the concept of a computer program, which can be expressed via flow diagrams or by means of an algorithm.”); Park 2005, p.362 (“[…] a set of instructions […] capable of being executed by a computer”). It is not implied that software that is covered by this definition is always patentable. 18 Grosche 2006, p.287.
19 The individual discussion of these categories is based on the distinction made in Art.52 EPC. For the text of Art.52 EPC, see Chapter 3.1.1.
20 Bakels 2009, p.515.
21 EPO Guidelines Part G Chapter II-5 states that “claims which involve computers, computer networks or other conventional programmable apparatus whereby prima facie one or more of the features of the claimed invention are realised by means of a program or programs”. These claims may take the form of “a method of operating said apparatus, the apparatus set up to execute the method, or […] the computer program itself as well as the physical media carrying the program”. This clearly shows that this term is to be interpreted broadly. It is unclear how the term “conventional” relates to computer technology that is still unknown.
22 Bainbridge 2007, p.200.
23 For the text of Art.52 EPC, see Chapter 3.1.1.
11
mathematical algorithms, are in fact closely linked to computer programs.
24Computer
programs are based on mathematical algorithms.
25The algorithms embodied in the software
cause the computer to achieve particular results. Although there is more to a computer
program than just the algorithm, it is an essential part of the program’s structure and
functioning.
26A distinction between these categories thus seems slightly artificial for
software.
27Therefore, when the term software is used in this thesis, it will also cover
mathematical algorithms to the extent that they are used in computer programs.
2.3.2. Methods for Doing Business
In a broad sense, business methods can be described as “methods for conducting [...]
economic business activities”.
28This includes everything from accountancy to marketing.
29Business method patents are often perceived as a category that is distinct from software
patents. However, there is some overlap. The first noticeable aspect about business methods
and computer programs is that they are mentioned in the same paragraph of Art.52 EPC. The
framers of the EPC thereby placed them under the same umbrella. This gives the impression
that these two categories are somehow related.
30Some commentators even see business
methods and computer programs as inseparable, stating that business methods are “by their
very nature implemented by computer programs”.
31On the other hand, there seems to be a stronger bias in practice against business method
patents than software patents, which implies a distinction between the two.
32For example,
Bakels argues that business method patents are a “dangerous American invention”.
33This
bias could be due to the fact that business method patents are a more recent phenomenon than
software patents. Regardless of what the cause is, it raises the question of how these
categories relate. For the distinction between software and business methods, the way in
which a business method is implemented is essential. Therefore, business methods will be
24 Bradstreet 2013, p.376.
25 Grosche 2006, p.289. It is important to note that software is not necessarily limited to mathematical algorithms, for which see Bostyn 2001, p.87.
26 Grosche 2006, p.290.
27 Ballardini 2008, p.563; Laub 2006, p.355.
28 This is based on the definition that Ferro proposed. However, the word “non-technical” is omitted. This term is confusing in light of the technicality requirement under the EPC. Ferro 2002, p.369-370; Another broad definition can be found in the Business Method Patent Improvement Act of 2001 (which was ultimately never enacted). This is not a definition that can be used to determine whether something falls under the statutory exclusion of business methods under Art.52 EPC. 29 Looijengoed 2005, p.604; Ferro 2002, p.369; Bostyn 2001, p.78.
30 Bradstreet 2013, p.376; Cook 2000, p.123.
31 Cook 2000, p.123. See also Bradstreet 2013-II, p.503. 32 Bakels 2004, p.1; Bakels 2002, p.347; Meijboom 2002, p.66. 33 Bakels & Harison 2005, p.42; Bakels 2004, p.1; Bakels 2002, p.347.
12
divided into two categories: abstract business methods and computer implemented business
methods.
34Abstract business methods are by their very nature distinct from software; they are not
executed by an electronically operated device. For example, assume that use of the colour
blue more often in communications and advertisements, allows a company to sell more
products. The employees of the company can put this abstract method into practice without
the use of software. Thus, this category falls outside the scope of software patents. On the
other hand, computer implemented business methods, as the name already suggests, are
executed by an electronically operated device. They are given shape in the form software. An
example of this is a method for monitoring customer behaviour on a website through an
automated system in order to examine to which colours the customers react positively.
Subsequently, the customers can be shown personalized advertisements based on their
preferred colour, in order to increase sales. This is a method that needs to be performed using
a computer program, and thus is computer implemented.
35It is very common for business methods to be implemented in software.
36References to
software in a patent application can even enhance the patentability of the business method.
37In this regard, it must be noted that most abstract business methods can be transformed into
computer implemented business methods by incorporating them into software.
38Furthermore,
it can be difficult to make a distinction between the business method aspect of an invention
and the software aspect.
39Therefore, the term software as used in this thesis includes
computer implemented business methods.
402.3.3. Machine Software versus Business Method Software
Although it is clear that business methods often fall within the ambit of software, a distinction
can be made between software aimed at achieving a particular result in a machine, and
software aimed at executing a business method.
34 This distinction was also made by Ferro 2002, p.369.
35 In general, it can be held that the more complex the business method, the more likely it is that computer implementation is necessary.
36 Bradstreet 2013, p.376; Bakels 2009, p.519; Park 2005, p.336; Bakels & Harison 2005, p.42; Bakels 2002, p.349. 37 Bakels & Hugenholtz 2002, p.23.
38 Ferro 2002, p.369. 39 Bostyn 2001, p.78.
40 Where relevant, a distinction will be made between business method software and regular software.
13
In the first category, there is a strong relation between the software and the tangible medium,
as the result that is to be achieved is in the machine that runs the software. Machine software
changes the functionality of the device on which it operates. An example is the
swipe-technique often used in smartphones.
41Another example is software that increases the speed
of a sorting-machine. This intuitively makes this category less problematic in light of the
tangible inventions that patent law originally intended to protect.
The latter category is clearly more abstract, and therefore encounters more resistance in
practice with regard to its patentability. In this category, the machine on which the software is
operated is only used to perform the business method, and is thus only a step towards the
desired result of the invention. Although there might be changes in the tangible machine due
to the software, or a slight increase in functionality, this is not what the business method
software sets out to achieve. This distance between the intangible and the tangible is expected
to have an effect on passing the patentability criteria and the related problems, which is why
this distinction will be taken into account.
422.4. Interim Conclusion
This thesis sets out to answer whether the exclusion of software from patent protection is still
meaningful in light of its historical development and current application. Software can best be
described as a set of instructions that, when incorporated in a machine-readable medium, is
capable of causing a machine having information-processing capabilities to achieve a
particular result. This includes mathematical algorithms and business methods, to the extent
that they are implemented in software. However, it is necessary to make a distinction between
machine software and business method software. The latter is more abstract, as it is not aimed
at achieving a particular result in a tangible good, but aims at electronically executing an
abstract method. Even though it is necessary to perform the business method software on a
machine having information-processing capabilities, it might face more difficulties under the
patentability criteria. This will be addressed in Chapter 4 and 5. When software is used in an
invention, this will be called a computer implemented invention, and the terms computer
program and software will be used interchangeably. The following chapter sets out the legal
framework from which the different legal standards have developed.
41 Software that is developed for daily use on a personal computer or smartphone, such as applications, also fall under the category of machine software. There are varying degrees within this category. The swipe technique has a clear effect on the functionality of the device. For an application containing a game this is less clear. However, the application still aims at changing the functionality of the device. Even though it seems less technical, it is machine software.
42 There will, however, always be a grey area between both categories.
14
3. LEGAL FRAMEWORK IN EUROPE AND THE UNITED STATES
3.1. Legal Framework in Europe
The main legal instrument based on which patents are granted throughout Europe is the
European Patent Convention (“EPC”), which establishes a centralized framework for patent
applications.
43Once a patent is granted under the EPC, it falls apart into a bundle of separate
national patents, which means that national patent law still plays a crucial role in the
enforcement of patents.
44The Guidelines for Examination in the European Patent Office and
the Implementing Regulations to the EPC provide for an explanatory source of information to
consult when interpreting the EPC.
45Other than the Directive on the Legal Protection of
Biotechnological Inventions, there are no European regulations or directives on patent law.
46In 2002, an attempt was made to implement a European directive on software patents, but this
proposal was ultimately rejected by a large majority in the European Parliament.
47According to Art. 21 EPC, objections against decisions from the European Patent Office
(“EPO”) can be directed towards the Technical Boards of Appeal.
48However, Technical
Boards of Appeal are not formally bound by earlier decisions, which opens the door to
conflicting case law.
49This is an eminent problem in the area of software patents, where a
series of conflicting decisions developed.
50If there is no uniform application of the EPC, or if
an important point of law arises, questions can be referred to the Enlarged Board of Appeal,
which can then give a decision that is binding upon the Technical Boards of Appeal.
513.1.1. Statutory Exclusion of Software: Art.52 EPC
As can be seen in Art.52(1) EPC, an invention must be susceptible of industrial application,
novel, and inventive in order to be patentable. Before a claimed invention is assessed
according to these criteria, however, it must first be established that the subject matter is an
43 Convention on the Grant of European Patents of 5 October 1973, 15th edition;
http://www.epo.org/law-practice/legal-texts/epc.html (last visited 1 December 2014).
44 National Patent Offices are also able to grant patents based on national patent law.
45http://www.epo.org/law-practice/legal-texts/guidelines.html (last visited 1 December 2014);
http://www.epo.org/law-practice/legal-texts/archive/documentation/implementing-regulations.html (last visited 1 December 2014); Ballardini 2008, p.564; Hart, Holmes & Reid 2000, p.13.
46 Directive 98/44/EC of the European Parliament and of the Council of 6 July 1998 on the legal protection of biotechnological inventions. The Unitary Patent Package that is still under discussion will not be taken into account. 47 Proposal for a Directive of the European Parliament and of the Council on the Patentability of Computer-implemented Inventions, Brussels COM 92-2002/0047 (COD). For more on this Directive, see Chapter 6.4.4.
48 For the different Boards of Appeal see http://www.epo.org/about-us/boards-of-appeal.html (last visited 1 December 2014).
49 Sterckx & Cockbain 2010, p.398, note 13; Bakels 2009, p.515; T-154/04 (point 2 of the reasons). 50 For which see Chapter 4.
51 Sterckx & Cockbain 2010, p.371 & 398, note 13; http://www.epo.org/about-us/boards-of-appeal.html (last visited 1 December 2014).
15
“invention” in the sense of the EPC.
52Despite early discussions on the necessity of defining
what constitutes an invention, such a definition was never included in the EPC.
53It is,
however, defined negatively in Art.52(2) EPC, in which several categories of subject matter
are excluded from patentability as not being an invention.
54Computer programs are part of
the subject matter that is excluded under Art.52(2) EPC, as well as methods for doing
business and mathematical methods. Art.52 EPC reads:
Article 52 EPC
(1) European patents shall be granted for any inventions, in all fields of
technology, provided that they are new, involve an inventive step and are
susceptible of industrial application.
(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.
(3) Paragraph 2 shall exclude the patentability of the subject-matter or
activities referred to therein only to the extent to which a European patent
application or European patent relates to such subject-matter as such.
At first sight, this seems to be a straightforward rule that excludes software from
patentability. Unsurprisingly, when the EPC came into force, most people therefore thought
that patents would not be granted for software.
55Despite this seemingly clear-cut statutory
distinction between what constitutes patentable versus non-patentable subject matter, it has
proven to be problematic in practice, especially with regard to software.
56Some
commentators even fundamentally question the ability to make a systematic distinction
between patentable and non-patentable subject matter at all.
57In any event, it is clear that the
lack of objective definitions of excluded subject matter leaves room for interpretation and
52 Ferro 2005, p.1.
53 Sterckx & Cockbain 2010, p.367; Pila 2005-II, p.758-759; Bakels & Harison 2005, p.22; Park 2005, p.343; Singer & Stauder 2003, p.68. As can be seen in Pila 2005-II, p.759, three proposals for a definition were made, none of which were adopted. The argument that tipped the scale in favour of not adopting a definition seems to be that the drafters of the Convention did not see the term “invention” as an ambiguous concept in need of a statutory definition.
54 Deschamps 2011, p.109; Park 2005, p.343; Singer & Stauder 2003, p.68. Despite this distinction, the EPO Boards of Appeal sometimes use the term “invention” for subject matter that is excluded from patentability as not being an invention, for which see Laub 2006, p.355.
55 Grosche 2006, p.270; Rosser 2005, p.25.
56 One of the reasons for this is that “[i]n the case of software, the first difficulty lies in determining which of the exceptions in this provision applies”, as stated in Grosche 2006, p.270. See also Bainbridge 2007, p.199; Pila 2005, p.3.
57 Bakels 2009, p.518.
16
uncertainty.
58Also, Art.52(3) EPC contains the much debated “as such” provision, according
to which the statutory exclusion is limited only to the listed subject matter as such.
3.1.2. Non-Patentable Subject Matter “As Such”
The “as such” provision makes the statutory exclusion problematic, because there is an
inherent ambiguity as to when patent applications deal with something broader than software
as such.
59Notwithstanding these ambiguities, it is clear that there is no absolute exclusion of
software from patent protection and that the door is left open for its patentability.
60Case law
of the EPO Boards of Appeal on software patents deals mainly with the interpretation of the
“as such” provision, and it is still, even after many years of discussion, a difficult concept to
grasp.
61What is clear is that a certain level of technicality is required in order to fall outside
the scope of the “as such” exclusion, which distinguishes patentable subject matter from
subject matter that is too abstract to be patentable.
62The requirement of technicality is not expressly mentioned in the EPC, but it is “widely
believed to be a common element characterising the patentable inventions”.
63This
requirement of technicality can also be found in Rule 27 and 29 of the 1973 version of the
EPC.
64This is not to say that this requirement is easy to apply; in fact, the European debate
about software patents largely focusses on when software is technical enough to be
patentable.
65Also, the fact that the distinction between patentable and non-patentable subject
matter must be based on technicality is criticized.
66Due to the ambiguity of the “as such”
provision and the technicality requirement that comes along with it, an extensive repertoire of
case law has developed, and the exception seems to have been interpreted ever more broadly
58 Laub 2006, p.354; Zekos 2006, p.434.
59 Deschamps 2011, p.109; Bakels 2009, p.516; Ballardini 2008, p.564; Diver 2008, p.130; Grosche 2006, p.270; Bakels & Harison 2005, p.36; Looijengoed 2005, p.605; Sarvas 2001.
60 Guarda 2013, p.450; Deschamps 2011, p.109; Newman 1997, p.702. 61 Bakels 2009, p.514; Meijboom 2002, p.66.
62 Ballardini 2008, p.564; Pearson 2006, p.89; Pila 2005, p.4; Park 2005, p.344; Bakels 2004; Hart, Holmes & Reid 2000, p.10. The technicality requirement was already discussed during the early discussions on the EPC, as can be seen in Pila 2005-II, p.760 in which it was stated that “[o]f particular interest in the Party's early discussions is its conclusion regarding the first proposal, that inserting a requirement for technical progress would merely repeat what was apparent from the requirement for an invention.”
63 Guarda 2013, p.450; Bakels & Harison 2005, p.36-37.
64 For which see http://www.epo.org/law-practice/legal-texts/html/epc/1973/e/rciii_ii.html (last visited 1 December 2014); Park 2005, p.344. These requirements are currently embodied in Rule 42 and 43. Although it is questionable whether the general requirement of technicality, which has far reaching implications, can be deduced solely from these rules, for which see also Bakels & Harison 2005, p.36-37.
65 Pila 2011, p.5; Pila 2005, p.5.
66 Bakels 2009, p.517; Bakels 2003, p.213.
17
over time.
67As stated by Sterckx & Cockbain, this has led to a “strange and unnatural
interpretation to the words “as such””.
68The different approaches taken by the EPO Boards
of Appeal will be addressed in Chapter 4. In order to understand the development of the “as
such” exclusion and the case law that will be discussed in Chapter 4, the origins of the “as
such” provision and the thoughts behind including it in the EPC must be addressed.
693.1.3. Background of the “As Such” Provision
“Some features of intellectual property law and information technology only become
apparent against the historical background of their respective evolution, and to a surprisingly
large extent, guidance for the future course on the appropriate protection for software is to be
found in the past.”
70With a concept as ambiguous as the “as such” exclusion, the Travaux
Préparatoires can give crucial insights into the origins of the debate, as well as the context in
which the current debate must be viewed.
71The first proposal to exclude software as non-patentable subject matter dates back to October
1971, and was put forward by the United Kingdom.
72It was argued that “a computer
programme was basically not inventive and was merely the mathematical application of a
logical series of steps in a process which was no different from a mathematical method
excluded under (a)”.
73Although the United Kingdom also proposed a definition of the kind
of software that was supposed to fall within this new category of excluded subject matter, it
was not adopted “so as not to tie the hands of the [EPO] and of the national courts”.
74Eventually, the exclusion clause was accepted, be it without the proposed definition.
7567 Deschamps 2011, p.109; Newman 1997, p.702. 68 Sterckx & Cockbain 2010, p.396.
69 Hart, Holmes & Reid 2000, p.9. 70 Grosche 2006, p.281-282.
71 “Even patent law reform has a long history, and modern patent law reform efforts can benefit by taking careful account of that history”, for which see Janis 2002, p.2. For the Travaux Préparatoires see https://www.epo.org/law-practice/legal-texts/archive/epc-1973/traveaux.html (last visited 1 December 2014).
72 Travaux Préparatoires, Minutes of the 9th meeting of Working Party I, held from 12 to 22 October 1971, in Luxembourg (BR/135/71), p.50 (“The United Kingdom delegation proposed that computer programmes should not be patentable and it proposed a draft giving a definition of what a computer programme was.”). Interestingly, Pila describes a strong opposition by the United Kingdom against including software in the exclusion clause, for which see Pila 2005-II, p.764.
73 Travaux Préparatoires, Minutes of the 9th meeting of Working Party I, held from 12 to 22 October 1971, in Luxembourg (BR/135/71), p.50; Pila 2005-II, p.769. It was recognized, however, that some form of protection might be necessary for software, albeit under a separate protection regime. It is difficult to grasp why a separate exclusion clause was deemed necessary if software was already believed to fall under the exclusion of mathematical methods.
74 Travaux Préparatoires, Minutes of the 9th meeting of Working Party I, held from 12 to 22 October 1971, in Luxembourg (BR/135/71), p.51; Pila 2005-II, p.769.
75 Why the exclusion clause was adopted despite the aforementioned counter arguments is not mentioned.
18
In 1972, however, there was strong opposition against the exclusion of computer programs
from patent protection. The main reason for that was the perceived need for flexibility and
discretion.
76It had been observed that excluding computer programs from patentability might
hinder future developments in this area.
77As portrayed by Pila in her study of the Travaux
Préparatoires, the opposition received broad support, as deletion of the exclusion clause
would allow subject matter broader than computer programs as such to be patented.
78Thus,
there was a fear that the exclusion clause would be too broad.
79It is notable that even the
United Kingdom itself revoked its interest in the exclusion of software, because "the free
development of precedents – which is of paramount importance in this still very uncertain
field – would be hindered”.
80Despite the opposition, the exclusion clause remained in the
text of the EPC.
81The main motivation behind this seems to have been the urge to provide
for legal certainty and uniformity.
82But there were still concerns about how to frame the
exclusion clause, so as not to exclude all software from patentability.
83This caused the “as such” terminology to gain momentum.
84Originally, the “as such”
provision was not applicable to all categories of subject matter listed under Art.52(2) EPC,
but only to scientific and mathematical theories.
85However, this raised the concern that
applying the “as such” provision only to one category, implies that the other categories are
excluded in a more broad sense, an argument put forward by the German delegation in March
76 Travaux Préparatoires, Minutes of the meeting of Working Party I, Brussels, 29 July 1969 (BR/7/69), p.9; Travaux Préparatoires, Minutes of the 5th Meeting of the Inter-Governmental Conference for the Setting up of a European System for the Grant of Patents, Brussels, 15 March 1972 (BR/169/72), p.6; Ballardini 2008, p.564; Pila 2005-II, p.769.
77 Travaux Préparatoires, Minutes of the 9th meeting of Working Party I, held from 12 to 22 October 1971, in Luxembourg (BR/135/71), p.50. For a similar line of thought, see Sterckx & Cockbain 2010, p.369-370, note 6.
78 Pila 2005-II, p.769.
79 For a similar line of thought, see Pila 2005-II, p.770 in which it was stated that “[t]he proposal on this second matter was to replace “computer programs” with “data handling systems” in recognition of the fact that “computer program” denotes a more complex system […] and might thus support an unduly broad construction of the exclusion as a whole.”
80 Travaux Préparatoires, Report on the 11th meeting of Working Party I held in Luxembourg from 28 February to 3 March 1972 (BR/177/72), p.3.
81 Sterckx & Cockbain 2010, p.367.
82 Travaux Préparatoires, Minutes of the 5th meeting of the Inter-Governmental Conference for the Setting up of a European System for the Grant of Patents, Brussels, 15 March 1972 (BR/168/72), p.14.
83 Travaux Préparatoires, Report on the 11th meeting of Working Party I held in Luxembourg from 28 February to 3 March 1972 (BR/177/72), p.3 (“Most of the Working Party on the other hand was in favour of this exclusion, which would, as a matter of fact, make for the exclusion of computer programs as such, while allowing precedents to be used to assess the patentability of any related inventions. This majority opinion held, on the contrary, that a special sub-paragraph dealing with computer programs could lead to the conclusion that any program, including true inventions related to such a program, should be excluded from patentability.”).
84 Ballardini 2008, p.564; Pila 2005-II, p.766.
85 Pila 2005-II, p.766; Travaux Préparatoires, Minutes of the 2nd meeting held at Luxembourg on 13 to 16 January 1970 (BR/7/69), p.10. It must be noted, however, that financial or accounting methods, rules for playing games or other systems, were only excluded insofar as they were of a purely abstract nature, as can be seen in LT 234/82, Section 1, 2335/IV/65-E, Brussels, 22 January 1965. In 1970 this was changed to “insofar as they are of a purely intellectual nature”, as can be seen in Travaux Préparatoires, Minutes of the 2nd meeting held at Luxembourg on 13 to 16 January 1970, (BR/7/69), p.10 & Minutes of the 3rd meeting of the Co-ordinating Committee, Brussels, 26 September 1972 (BR/218/72), p.4.
19
1973.
86Therefore, the “as such” terminology was introduced in a new paragraph, Art.52(3),
so as to be applicable to all subject matter listed under Art.52(2) EPC. Pila described this as
an "odd reversal of fate".
87As mentioned in a 1973 proposal, “[t]he idea behind paragraph 3
is that the inventions excluded from patentability pursuant to paragraph 2 are those which
relate exclusively to the intellectual works referred to in paragraph 2(a), (b), (c) and (d)”.
88The need for flexibility is a recurring element in the discussions about whether or not to
exclude software from patent protection.
89This was also one of the main reasons not to adopt
a definition of software, and it was stated that the EPO would “simply have to be relied upon
subsequently to interpret this expression unequivocally”.
90When the EPC was drafted, the
development of software had only just started, and software was nowhere near as complex as
it is today. It will come as no surprise that in these early discussions, the participants had no
idea as to what software would look like 20 or 30 years ahead.
91This can be seen in the first
version of the EPO Guidelines, in which software was considered “an independent
component, easily separable from the hardware itself, which could thus be excluded from
patentability per se”.
92Nowadays, the interplay between software and hardware is much
more complex, and software is often intertwined with the functioning of hardware. Some of
the stakeholders involved in the early discussions addressed this issue, and mentioned that it
would not be wise to make definitive statements about whether or not to exclude software
from patentability.
9386 Travaux Préparatoires, Munich Diplomatic Conference for the Setting up of a European System for the Grant of Patents, Comments by the Government of the Federal Republic of Germany, 29 March 1973, p.64; Pila 2005-II, p.767. All of this indicates that the drafters never intended to exclude software from patent protection to a very broad extent.
87 Pila 2005-II, p.766. Pila describes this as “odd”, because it was originally argued that the as such provision should only apply in the context of scientific discoveries, for which see Pila 2005-II, p.766.
88 Travaux Préparatoires, Munich Diplomatic Conference for the Setting up of a European System for the Grant of Patents, Proposal by the IAPIP, 11 September 1973 (M/66/I), p.1.
89 Ballardini 2008, p.564.
90 Travaux Préparatoires, Minutes of the Munich Diplomatic Conference for the Setting up of a European System for the Grant of European Patents, Munich, 10 September to 5 October 1973, p.28; Pila 2005-II, p.769.
91 The status of software even changed during the drafting process, as can be seen in Pila 2005-II, p.768-769 & 775, which shows that “The status of computer programs also changed in the course of the framers’ deliberations. Initially the view was taken that the patentability or otherwise of computer programs could not be prejudged because of the uncertainty of their position given the (then) “present state of developments”.”
92 Ballardini 2008, p.564.
93 Travaux Préparatoires, Minutes of the 5th Meeting of the Inter-Governmental Conference for the Setting up of a European System for the Grant of Patents, Brussels, 15 March 1972 (BR/169/72), p.9-10. Another proposal in this regard was to transfer the provision containing computer programs to the Implementing Regulations. for which see Travaux Préparatoires, Munich Diplomatic Conference for the Setting up of a European System for the Grant of Patents, Comments by CPCCI Standing Conference of the Chambers of Commerce and Industry of the European Economic Community, 2 April 1973, p.160.
20
So how should the “as such” provision be interpreted? Little is known of what the drafters
intended, except for the fact that they intended to avoid confusion, in which they arguably
failed to a large extent.
94What does become clear from studying the history of the EPC is
that it was never the intention to exclude software very broadly.
95The exclusion clause is
aimed at inventions of which software was the only element; this was possible because
software was far less complex and therefore easily separable from other elements of an
invention.
96It is also clear that items "which were traditionally patentable should not be
excluded merely because they contained computer programs”.
97However, it is not possible to
draw a uniform and unambiguous threshold of software patentability from the EPC's history.
Given this lack of a clear threshold, many interpretations of the words “as such” have
emerged over the past decades, all revolving around a single technicality requirement.
98A
noticeable and recurring aspect in this regard is that the contracting parties seemed to agree
that the EPO could and should be relied upon in the interpretation of software exclusion.
99These EPO interpretations will be discussed in Chapter 4, in order to provide more clarity to
the differing EPO case law on this topic. As will become clear in that chapter, however, there
still remains ambiguity as to the exact conditions under which software can be patented.
3.2. Legal Framework in the United States
The legal framework in the United States (“U.S.”) is somewhat different from the European
legal framework, in the sense that there is no statutory exclusion of software.
100Criteria
under which software can and cannot be patented developed solely through case law, and are
based on the United States Constitution ("Constitution") and the United States Patent Act
(“Patent Act”). Article I, Section 8, Clause 8 of the Constitution, better known as the
94 Bakels & Harison 2005, p.38.
95 Deschamps 2011, p.109; Hart, Holmes & Reid 2000, p.14; T 154/04 (point 6 of the reasons); T 935/97 (point 4.1 of the reasons).
96 Pinxten 2009, p.654; Rosser 2005, p.25-26 stated that “[a]s early as 1984, the EPO Board of Appeals established the position that inventions, including those involving software, must be considered as a whole when determining whether they are patentable. The key “as such” clause, according to the EPO, means the items mentioned in Article 52 […] are only not patentable if they constitute the entire invention. A computer program, in particular, is not patentable only if the computer program is all there is to the invention. If a computer program is merely a part of the invention, that invention may be patentable so long as the invention as a whole meets the patentability standards […].”
97 Travaux Préparatoires, Minutes of the 5th Meeting of the Inter-Governmental Conference for the Setting up of a European System for the Grant of Patents, Brussels, 15 March 1972 (BR/169/72), p.10; T 154/04 (point 6 of the reasons). 98 Bakels & Harison 2005, p.38.
99 Travaux Préparatoires, Minutes of the Munich Diplomatic Conference for the Setting up of a European System for the Grant of European Patents, Munich, 10 September to 5 October 1973, p.28; Pila 2005-II, p.769.
100 See also Chapter 2.2. of this thesis.
21
“intellectual property clause”, gives Congress the power to establish a patent system.
101The
article is lengthy, but the relevant section for this thesis reads: “Congress shall have the
power to […] promote the Progress of Science and useful Arts, by securing for limited Times
to Authors and Inventors the exclusive Right to their respective Writings and Discoveries
[…]”.
102Based on this clause of the Constitution, the Patent Act was enacted in 1790, which
is the legal instrument governing patents in the U.S.
The entity responsible for examining patent applications is the United States Patent and
Trademark Office (“USPTO”).
103In addition to the Patent Act, there is a Manual for Patent
Examination Procedure (“MPEP”), which was issued by the USPTO and contains specific
sections on subject matter patent-eligibility.
104Objections against USPTO decisions can be
directed to the Court of Appeals for the Federal Circuit (“CAFC”), which in 1982 was
entitled jurisdiction over all patent appeals.
105The highest court to give decisions regarding
patent law is the U.S. Supreme Court.
3.2.1. United States Patent Act / 35 U.S.C.
The patentability of software starts with determining whether claimed subject matter
constitutes an invention. 35 U.S.C. 100 (“§ 100”) of the Patent Act contains a definition of
what constitutes an invention under U.S. patent law. However, there is some circularity to
this definition, as § 100 defines an invention as “a discovery or invention”, which does not
provide any clear guidance on what constitutes an invention under the Patent Act.
10635
U.S.C. 101 (“§ 101”) explicitly deals with patentable subject matter and, unlike the EPC, lists
four categories of subject matter that fall under the scope of the term “invention” and are thus
patent-eligible.
107When this “invention hurdle” is passed, the patent application still has to be
assessed according to the generally applicable criteria of novelty and non-obviousness, as
described in the other sections of the Patent Act.
108§ 101 of the Patent Act reads:
101 It also forms the basis for other protection regimes such as copyright.
102 For more on this clause see Pierce 2012, p.199; Wisecup 2012, p.1654; Deschamps 2011, p.107. 103http://www.uspto.gov/ (last visited 1 December 2014); Lambilotte 2012, p.645.
104 http://www.uspto.gov/web/offices/pac/mpep/index.html (last visited 1 December 2014). For patent eligibility see Chapter 2100 of the MPEP.
105 28 U.S.C. § 1295(a)(4)(A); Oppenheimer 2012, p.28, note 194. 106 Laub 2006, p.357.
107 It thereby provides a positive enumeration, as opposed to the negative enumeration of Art.52 EPC. Collins 2013, p.1426; Perel 2012, p.240; Laub 2006, p.358.
108 Wisecup 2012, p.1655; “The usefulness or utility requirement, dealt with in the same section, provides that the invention must have specific and credible utility. The novelty requirement, set out in s.102, demands that the invention must not have been previously known or used by others. Finally, the non-obvious requirement of s.103 means that the invention must not have been obvious, at the time it was made, to a person having ordinary skill in the art to which the subject-matter pertains.” See Deschamps 2011, p.108; Zekos 2006, p.430 & 433; Park 2005, p.363.
22
Section 101. Inventions Patentable
Whoever invents or discovers any new and useful process, machine,
manufacture, or composition of matter, or any new and useful
improvement thereof, may obtain a patent therefor, subject to the
conditions and requirements of this title.
The definition of statutory subject matter lies at the core of any patent system.
109Given the
fact that the patent system is designed to promote technological and scientific progress, the
types of subject matter that are patentable directly influence the type of innovation that is
promoted.
110On first sight, the wording of § 101 seems clear.
111However, the broad
terminology leaves room for discussion as to what exactly § 101 is meant to cover. Similar to
the EPC, this seemingly clear rule caused years of discussion through case law, and the
criteria under which the patentability of software must be assessed remain difficult to
grasp.
112As described by Judge Rich, the scope of § 101 has become one of the “most
difficult and controversial issues”.
113In order to properly define the scope of § 101, and to
properly assess case law that interprets § 101, it is necessary to gain an understanding of its
history.
1143.2.2. History of 35 U.S.C. 101
To start with, it must be noted that the Constitution and Patent Act were drafted at a time in
which software did not yet exist.
115The inventions known at that time related to tangible
technology.
116This means that there are no documented discussions explicitly dealing with
the patentability of intangible subject matter, such as software. Also, records of the
Constitution and its ratification debates are silent on the intellectual property clause; there are
no records of who proposed it and why it was adopted.
117The same holds true for § 101 of
the Patent Act. History on what motivated Congress to include § 101 in the Patent Act is
scarcely available, and Congress surely did not take software into account at the time of
drafting it. It is therefore difficult to grasp what the framers of the Constitution and Patent
109 Oppenheimer 2012, p.4. 110 Oppenheimer 2012, p.7. 111 Oppenheimer 2012, p.42.
112 Oppenheimer 2012, p.45 indicated that "The [Supreme] Court has had to address the issue of statutory subject matter directly and tangentially more than a dozen times and has never been able to reach a unanimous decision”; Pierce 2012, p.189; Deschamps 2011, p.108; Peterson 1995, p.91.
113 Peterson 1995, p.105. 114 Pierce 2012, p.188.
115 Burk & Lemley 2002; Whereas the EPC was drafted at the early ages of software development, the U.S. Constitution dates from 1789, and the U.S. Patent Act dates from 1790, although subsequent amendments have been made to both legislative instruments. See also Burk & Lemley 2002, under I-A.
116 Bradstreet 2013, p.506. 117 Oppenheimer 2012, p.8.
23
