This is the fourth year in a row that sections of the EPO guidelines for examiners relating to computer implemented inventions (CII) have been significantly amended. These amendments have come about as a result of a project within the EPO to harmonise the treatment of inventions involving computers and software across all examining divisions. In the EPO, inventions not relating to computer science per se are handled in various examining divisions according to the function performed by the computer and its software. Thus, significant variation in practice had arisen between different examining divisions. This year’s set of amendments is the last to be expected from this project, which has declared itself dormant. For the next few years we can expect only minor changes unless there is some significant new case law from the boards of appeal.
The changes to the guidelines relating to software inventions are quite extensive but do not involve any major policy changes. Rather they reflect recent case law and expand on the examples given, especially in relation to identifying technical and non-technical subject matter. A new section addresses claim formats for inventions involving distributed computing (aka cloud computing) whilst specific attention is given to machine learning and simulation. In the on-line version of the guidelines an index to the parts relevant for CIIs is also provided. We discuss below the most significant portions of the amended guidelines.
New section 3.9.3 of the guidelines, part F chapter IV discusses at considerable length, with examples, possible claim forms for inventions “realised in a distributed computing environment” (sometimes known as cloud computing). The key point is that the guidelines now recognise that the different components of such an invention
(e.g. client computer and server computer) are “a plurality of inter-related products” and so more than one independent claim in a given category is permissible under Rule 43(2)(a). For example, it is permissible to claim in the same patent application a client device, a server computer and the complete system as well as the corresponding methods.
The guidelines also note that each independent claim has to meet, by itself, the requirements of novelty, inventive step, clarity and sufficiency. Thus if the only novel steps of a distributed computing method are performed at the server side, claims to the client may not be new. Also, it is often not clear to define one entity (e.g. the client) by reference to features or steps performed by another (e.g. the server). For example a step of “receiving data encoded by [novel method steps performed elsewhere]” would normally not be regarded as imposing a clear limitation on the receiver. In other cases the invention may lie in the distribution of steps between different devices. Therefore the full gamut of claims may not be achievable in all circumstances.
The EPO has long permitted claims to a computer program per se in the format “a computer program comprising code means that, when executed by a computer system, instruct the computer system to perform [method steps]”. Such a claim does not need to include a computer readable medium and the method steps are preferably defined by reference to method claims, provided those method claims include only steps performed by a computer.
However, computer program claims are considered allowable only if the method performed by the program results in a “further technical effect”, over and above the normal operation of a computer when a computer program is run. The revised guidelines discuss various ways in which a computer program claim can be given the requisite further technical effect. Broadly speaking, there are two ways in which a computer program can be considered technical. The first and most straightforward is that the program performs a method outside the field of computer science that is technical, e.g. controls a machine or processes an image. The second possibility is that the invention relates to a technical aspect of computer science. This is more complex and is discussed below.
Although the specific exclusions for patentability are often treated collectively as non-technical, the exact scope of the specific exclusions, and whether an invention relates to excluded matter “as such”, is often an issue in borderline cases. The sections of the guidelines relating to the exclusions most relevant to computer-implemented inventions – mathematical methods (including artificial intelligence, simulation and modelling), games, mental acts, business methods and programs for computers – are completely rewritten. We discuss these in turn below.
The revised guidelines recognise that “[m]athematical methods play an important role in the solution of technical problems in all fields of technology” and indicate that claims are excluded only if they relate to a “purely abstract” method, object or concept. Boards of appeal have stated that the exclusion applies only to mathematics performed for mathematics’ sake and a claim limited to a technical application of a mathematical method is outside the exclusion. The revised guidelines include a list of examples of mathematical methods that perform a technical purpose and so are not excluded. These examples range from controlling a technical system or process to encoding data for storage or transmission.
Another, but less common, way in which a mathematical method can escape the exclusion is if it is claimed as being performed on technical means and is specifically adapted to technical characteristics of the internal functioning of the computer. Note that an abstract mathematical method cannot be rendered patentable merely by specifying that it is performed on generic computer hardware, that it is algorithmically more efficient than prior art, or that the data on which it operates is technical. In the case of a mathematical method operating on technical data, it is necessary to show that the output is technical and improved in a meaningful way.
One difference between mathematical methods and other forms of excluded matter is that, if a claim as a whole has technical character, any mathematical steps within it will generally be considered for contribution to inventive step. Other excluded matter, especially business method steps, is usually disregarded.
Artificial intelligence (AI) and machine learning (ML) are considered a category within mathematical methods but deserving of a subsection of the guidelines to themselves, given the large number of applications the EPO is receiving in this field. Two points are made. First, the language of a claim must be examined carefully to ensure that what is claimed is a concrete implementation of a machine learning algorithm and not the algorithm in the abstract. An objection that a claim is directed to an algorithm in the abstract is usually easily dealt with by straightforward amendments.
The second point on AI and ML is more fundamental. The guidelines indicate that the patentability of a method employing AI or ML will usually depend on the nature of the overall purpose of the method. An ML algorithm performing a technical purpose, e.g. recognising irregular heartbeats or classifying images based on low-level features, is patentable, but an ML algorithm classifying abstract or non-technical data, e.g. classifying text documents by reference to the text content, is not.
Another subsection is devoted to simulation, design and modelling, reflecting some recent case law. For inventions in this area, the key is to ensure that the claims are sufficiently specific. Simulation of a generic “technical system” will not be regarded as technical but if the nature of the system is adequately defined and limited then simulation is considered technical even if there is no concrete output. A method of designing something is technical provided the invention relates to the determination of some technical parameter of the thing and is automatic. A method where the design is primarily aesthetic or which relies too heavily on human input is not technical. Note though that in view of variations in national law on this point it is advisable also to include a claim to making the thing that has been designed.
The revised guidelines discuss methods of performing mental acts at some length but the points made are fairly straightforward.
A common objection, where the invention does not have a concrete output or an effect on a concrete system, is that a claim is not limited to the invention being performed by technical means, e.g. a computer. Provided there is basis, a simple amendment can usually get around such an objection. However, as the guidelines observe, “the complexity of a method cannot disqualify it as a method for performing mental acts as such” and arguing along these lines will likely bring an additional objection that the claim lacks essential features.
Therefore, as long as at least one step of a method is clearly specified to be performed by a computer an objection that the invention is excluded from patentability will be avoided. Other steps may still be open to being performed mentally by a user. Such steps will only contribute to inventive step if they “contribute to producing a technical effect serving a technical purpose”. An example given is a method which involves the selection (by a person) from a family of products. This selection step only contributes to an inventive step if the selection is explicitly based on technical criteria and not, for example, aesthetic considerations.
The exclusion of rules for playing games most often arises in the context of computer games and gambling machines. The revised guidelines provide a helpful definition: “Game rules define a conceptual framework of conventions and conditions that govern player conduct and how a game evolves in response to decisions and actions by the players. They comprise the setup of the game, options that arise as game play unfolds, as well as goals defining progress in the game.”
It is rare that a claim seeks to claim game rules in the abstract; more frequently claims are directed to technical means (e.g. a computer) that implement the rules. Such technical means pass the patent-eligibility test, but neither the game rules nor their mere automation can contribute to inventive step.
Nevertheless, a technical effect can arise in in the implementation of game rules: for example in the interactive control of game elements; ways of addressing technical limitations of displays; or user input. Not technical are features that increase engagement by psychological effects or ensure fair game play. The precedent that automatically indicating the internal state of a machine is technical does not apply if the internal state is the state of play of a game. A recent board of appeal decision T0339/13 in which increasing realism was considered a technical problem is not reflected in the guidelines.
The section of the revised guidelines dealing with business methods is extensive, reflecting the numerous decisions on this topic. The guidelines define business methods broadly as “activities which are of financial, commercial, administrative or organizational nature” and provide numerous examples.
As with other excluded matter a technical (e.g. computer) implementation of a business method is patent-eligible but the guidelines warn that claim terminology must be examined with care ‘because a “system” might e.g. refer to a financial organization and “means” to organisational units’. An explicit reference to the use of computers and/or processors is therefore best.
Again, if the patent-eligibility test is passed it is necessary to consider what features of the invention contribute to the technical character of the claims. The revised guidelines indicate that the features which can contribute to a technical inventive step are “those specifying the particular technical implementation” and “which are results of technical implementation choices”. A technical invention can lie in a specific implementation of a business method that addresses a technical problem in the implementation. On the other hand, a modification to the underlying business method to circumvent rather than address a technical problem is not considered patentable. Similarly a modification in a business method that provides a technical advantage - e.g. reduction of data transmission, storage or processing – does not provide a technical effect if the reduction is simply the inevitable result of a more efficient business process.
The revised guidelines also include several cautions to examiners, which applicants need to bear in mind:
The EPO’s view on what is technical (i.e. makes a claim patent-eligible and can contribute to inventive step) in the field of computer science can seem inconsistent at times. On the one hand, it is enough to say that a method is “computer-implemented” or include generic computer hardware to make a claim patent-eligible. However on the other hand, the EPO does not consider all computing inventions to be patentable.
Early EPO case law held that the categories of thing specified in Article 52(2) EPC as not patent-eligible have in common that they are not technical and therefore things that are technical should be patent-eligible. This logic can be extended to the conclusion that since computers are technical, the programs they run are technical and so ought to be patentable. However, this would completely negate the fact that “programs for computers” is a specific category excluded from patent-eligibility. Therefore EPO practice is that not all computer programs are created equal. The revisions to the guidelines in G-II-3.6 seek to explain what is and is not technical programming. As mentioned above, a computer program is technical if it relates to a technical thing external to the computer; this section concerns computer programs and inventions that are essentially internal to the computer.
A useful rule of thumb is that the lower the level of the invention, the more likely it is to be considered patentable. Thus examples in the guidelines of inventions likely to have technical character include: boot security; processor load balancing; and memory allocation. Examples that are not considered technical include: information modelling; automated conversion of models to code; processes for writing code; programming languages or environments; and data formats relating to cognitive data (as opposed to functional data which control a device).
The guidelines do offer some possibilities by which a relatively high-level invention which might therefore be considered unlikely to be patentable, could be considered technical. In particular, if a relatively high-level program is nevertheless designed based on specific technical considerations relating to the internal function of a computer or to solve a technical problem, it might be considered technical. In this context, the mere implementation of a non-technical method is not considered a technical problem, nor is reducing the intellectual effort required of a coder.
This topic is covered at length in part G, chapter VII, section 5.4. In the latest revision of the guidelines only minor editorial amendments have been made; there are no substantive changes. The 2016 and 2017 CardinalCommerce (T1463/11) and Waterleaf (T0630/11) decisions from Board 3.5.01 have, in our view, made a significant modification to the approach to so-called mixed inventions, especially where business methods are involved. These decisions are being referenced by Board 3.5.01 and occasionally by examiners but do not yet seem to have been picked up by other boards. The decisions are discussed in detail in our briefings: The Notional Business Person - A New Actor on the IP Stage? and Clarification of the Concept of the "Notional Business Person".