This information is available in Korean.
This page describes the current approach of the European Patent Office (EPO) concerning the patentability of software and business method inventions with a view to providing some insight regarding when an invention devised in a software and/or business context might be patentable at the EPO.
For the purposes of comparison, the corresponding approaches of the UK Intellectual Property Office (UKIPO) and the United States Patent and Trademark Office (USPTO) are also briefly discussed.
European patent law explicitly excludes computer programs and methods of doing business from patent protection. However, these exclusions are applied in a complicated manner such that it is still possible, in certain circumstances, to obtain European patent protection for inventions devised in a software and/or business context.
Put simply, the EPO believes that in order for a claimed invention devised in a software and/or business context to be patentable, the claimed invention must define “technical” features which solve a “technical problem” in a non-obvious manner.
In principle, the EPO accepts that a “technical problem” can legitimately occur in a software and/or business context, though in practice it can be challenging to obtain patent protection in Europe for inventions devised in a software and/or business context (particularly for inventions devised in a business context, where examination by the EPO tends to be particularly strict).
In practice, the EPO combines its non-patentable subject matter test with its assessment of whether a claimed invention is obvious[1].
To achieve this, the EPO first separates a claim into what it views as “technical” features and “non-technical” features. In general, claimed features describing physical objects (e.g. computer hardware) will be viewed as “technical” by the EPO. However, any claimed features which appear to relate to subject matter excluded from patentability, such as features relating to software or to business methods (e.g. financial transactions) are likely to be viewed as “non-technical” by the EPO, unless it can be shown that those apparently non -technical features have “technical character” through either (i) being capable of causing a change in the physical nature or technical functioning of clearly technical features, or (ii) reflecting technical considerations required to carry out the disclosed invention[2].
Next, when considering whether the claimed invention is obvious, the EPO strips the claimed invention of its “non-technical” features and formulates a “technical problem” solved by the remaining “technical” features in relation to the prior art[3]. Finally, the EPO considers whether the “technical features” of the claimed invention would have been obvious to a skilled person starting from this “technical problem” and the prior art.
Crucially, the EPO is allowed to include any “non-technical” features of the claimed invention within its formulation of the “technical problem”, e.g. as constraints to be met. In effect, the “non-technical” features of the claimed invention are assumed by the EPO to form part of the prior art, even if there is no evidence to suggest that this is actually the case.
Consequently, in order to successfully patent an invention devised in a software and/or business context at the EPO, it is necessary to show that the “technical” features of the claimed invention would have been non-obvious to a skilled person armed, not only with the prior art, but also with knowledge of any “non-technical” features of the claimed invention.
This means than when attempting to patent an invention devised in a software and/or business context at the EPO, much of the arguments focus on whether or not the claimed features thought to be novel and non-obvious have "technical character". If this argument is lost, i.e. if the claimed features thought to be novel and non-obvious are viewed by the EPO as "non-technical, then the EPO is likely to reject the claimed invention as being obvious, even if there is no evidence to suggest that the “non-technical” features of the claimed invention are actually disclosed/suggested by the prior art.
The EPO approach to patent eligibility is commonly referred to as the “COMVIK” approach. Further reading on the COMVIK approach can be found in our detailed study on software patents at the EPO here.
Applying the above considerations to software inventions, it will only be possible to obtain patent protection for an invention devised in a software context at the EPO, if it can be shown that the claimed invention contains at least one novel feature that is "technical" and that solves a “technical problem” in a non-obvious manner.
In order for a software feature to meet the requirement of being "technical", it is usually necessary for the software, when executed, to produce a technical effect which goes beyond the normal physical effects produced when an ordinary piece of software is executed on computer hardware (such as the graphical display of data on a monitor or the movement of data from one location to another).
By way of example, software containing a new algorithm for controlling the operation of a steel mill in order to produce better quality steel should in principle be patentable at the EPO. Similarly, software containing new code that allows a computer processor to process data more efficiently, should in principle be patentable at the EPO. Note that in both these cases, it is straight-forward to argue that a “technical problem” has been solved (e.g. how to produce better quality steel, how to process data more efficiently), since the technical effects produced clearly go beyond the normal physical effects produced by an ordinary piece of software.
As a contrasting example, complex financial systems may use computers and software to monitor the movements of large numbers of stocks and shares, e.g. in order to recommend buying or selling activity according to predetermined criteria. In general, software implementing such financial methods will not be patentable at the EPO, even if the underlying financial methods are new and non-obvious. The difference from the examples given in the previous paragraph is that the beneficial effects produced by software implementing a financial method are unlikely to be viewed as “technical” by the EPO, because those effects are primarily financial in nature.
Often, it will not be clear whether patent protection will be available at the EPO for an invention relating to software. In such cases, we recommend you get in touch with your usual Mewburn contact for some case-specific guidance.
Once the EPO has accepted that a claimed software invention is patentable, i.e. because it defines “technical” features which solve a “technical problem” in a non-obvious manner, the EPO is quite liberal in the formulation of claim it will allow.
In November 2016, the EPO issued guidelines providing example claim formulations for computer-implemented inventions, which should not face formal (e.g. lack of clarity) objections at the EPO. The full EPO guidelines can be found on the EPO website via the link set out in the footnotes to this information sheet[4].
The EPO guidelines expressly indicate that the example claim formulations that have been provided by the EPO are non-exhaustive, so there is no formal requirement to prepare claims that exactly match these examples. Nonetheless, we think the EPO guidelines provide a useful reference that may assist in the preparation of claims for protecting software inventions at the EPO.
Applying the above considerations to business method inventions, it will only be possible to obtain patent protection for an invention devised in a business context at the EPO, if it can be shown that the claimed invention contains at least one novel feature that is "technical" and that solves a “technical problem” in a non-obvious manner.
Novel and non-obvious steps of a business method are very unlikely to be viewed as “technical” by the EPO in any scenario, even if those business method steps result in beneficial technical effects[5].
And even for claimed features set in a business context that do not equate directly to steps of a business method, such features will in generally only be seen as technical if it can be shown that they solve a “technical problem” in a manner that does not depend on the business context in which the invention has been devised.
By way of example, a new and non-obvious financial method (e.g. tax optimisation method) that utilises general purpose computer hardware (e.g. “a processor”, "a network") will almost certainly be viewed as unpatentable by the EPO, even if the financial method produces technical advantages (such as increased speed, or reduced burden on a processor). This is because the EPO will simply view the underlying financial method as a method of doing business which is inherently unpatentable.
In contrast, an automated system for performing a financial method that involves moving financial data from A to B could potentially be patentable at the EPO if it uses a new and non-obvious hardware arrangement that allows the financial data information to be moved more quickly from A to B. Here, the automated system could potentially be viewed as patentable because the new and non-obvious hardware arrangement is clearly a technical feature, and the increase in speed results from the hardware arrangement itself rather than the financial method being performed by the automated system.
Ultimately, if an invention really does reside in a new and non-obvious way of doing business, rather than in a new and non-obvious technological development made in the context of a business process, it will be extremely difficult, if not impossible, to obtain patent protection for that invention at the EPO.
Often, it will not be clear whether a claimed invention relating to a business method will or won’t be viewed as patentable by the EPO. In these cases, we recommend you get in touch with your usual Mewburn contact for some case-specific guidance.
Statutory law in the UK regarding the patentability of software and business method inventions is essentially the same as it is in Europe. However, unlike the EPO, the UKIPO applies this law in practice by assessing whether a claimed invention relates to non-patentable subject matter independently from its assessment of whether the claimed invention is obvious[6].
Essentially, in order to obtain patent protection for a software or business method invention in the UK, it is necessary to show that the claimed invention provides a “relevant technical effect”. Although a formal definition of what constitutes a relevant technical effect has not been (and is unlikely to be) provided, the UK High Court has set out the following factors as being “useful signposts” for determining whether a claimed technical effect is a relevant technical effect[7]:
i) whether the claimed technical effect has a technical effect on a process which is carried on outside the computer;
ii) whether the claimed technical effect operates at the level of the architecture of the computer; that is to say whether the effect is produced irrespective of the data being processed or the applications being run;
iii) whether the claimed technical effect results in the computer being made to operate in a new way;
iv) whether the computer is made a computer a better computer in the sense of running more efficiently and effectively as a computer;
v) whether the perceived problem is overcome by the claimed invention as opposed to merely being circumvented.
In theory, the approach of the UKIPO concerning the patentability of software and business method inventions should produce the same result as the approach of the EPO, and the UK courts have indicated that both approaches ought to produce the same result[8]. However, in practice, the UKIPO appears to take a much narrower view of what can be considered as “technical” compared with the EPO. The unfortunate effect of this is that the prospects of getting granted patents for software inventions at the UKIPO appear to be considerably worse than at the EPO[9]. For a more detailed comparison of UKIPO and EPO approaches to patent eligibility of software inventions, please see our Special Report which can be found here.
In the 1990s, following some decisions of the US Court of Appeal for the Federal Circuit (CAFC), most notably the well-known State Street[10] decision, the US courts and USPTO adopted a very liberal approach to what could be patented, such that it was generally possible to gain patent protection for most new ideas in the fields of business methods and software.
In recent years, however, the US courts and USPTO have stepped back considerably from the permissive approach outlined in the State Street decision, particularly in relation to the patentability of business methods[11]. As a result, the approach to the patentability of software and business method inventions taken by the US courts and the USPTO seems to be converging to some degree with the approach taken by the EPO.
However, there is not a direct equivalence between the EPO and USPTO approaches to patent eligibility, and case law regarding patent eligibility continues to develop in the US courts and at USPTO. So, if a clear view is wanted regarding whether an invention relating to software and/or business will be seen as potentially patentable in the US, we recommend seeking advice from a US attorney.
This guide sets out in broad terms the sorts of inventions relating to software and/or business might be seen as potentially patentable in Europe. However, in borderline cases or where there is doubt, we recommend you get in touch with your usual Mewburn contact for some case-specific guidance.
Footnotes:
[1]See e.g. “Examination of computer-implemented inventions at the European Patent Office with particular attention to computer-implemented business methods”, EPOJ 2007, 594.
[2]See e.g. “Examination of computer-implemented inventions at the European Patent Office with particular attention to computer-implemented business methods”, EPOJ 2007, 594.
[3]See e.g. EPO Appeal Board Decision T641/00 as developed by e.g. T531/03 and T125/04
[4] EPO Guidelines F.IV.3.9: http://www.epo.org/law-practice/legal-texts/html/guidelines/e/f_iv_3_9.htm
[5] See e.g. T531/03
[6] This involves a four-step test which is set out in Aerotel Ltd v Telco Holdings Ltd; Macrossan’s Patent Application [2006] EWCA Civ 1371
[7] See AT&T Knowledge Ventures LP v Comptroller General of Patents Designs and Trade Marks [2009] EWHC 343 (Pat) updated by HTC v Apple [2013] EWCA Civ 451
[8] See e.g. Symbian Ltd v Comptroller General of Patents [2008] EWCA Civ 1066
[9] See e.g. “Protecting software and computer-implemented inventions in Europe”, IP Value 2014 - An International Guide for the Boardroom, supplement to IAM magazine, published by The IP Media Group, pages 21-26
[10] State Street Bank and Trust Company v. Signature Financial Group, Inc., 149 F.3d 1368 (Fed. Cir. 1998)
[11] See e.g. “Business methods under attack”, CIPA Journal, October 2015, pages 10-11
This information is simplified and must not be taken as a definitive statement of the law or practice.
Our IP specialists work at all stage of the IP life cycle and provide strategic advice about patent, trade mark and registered designs, as well as any IP-related disputes and legal and commercial requirements.
Our peopleRead our blogs to keep up to date with developments in the IP world and what we are up to at Mewburn Ellis.
We have an easily-accessible office in central London, as well as a number of regional offices throughout the UK and an office in Munich, Germany. We’d love to hear from you, so please get in touch.
Get in touch