Examination practice at the European Patent Office follows a set of Guidelines. These are published online and provide guidance for European Examiners and applicants. They are updated annually.
An updated set of Guidelines came into force on 1st November 2018. The recent updates introduce major amendments to sections that cover subject matter that is excluded from patentability in European. These sections include those directed to “mathematical methods”, “schemes, rules and methods for performing mental acts, playing games or doing business” (often shortened to “business methods”), and “programs for computers”. The updates are relevant to those filing applications related to “computer-implemented inventions” (often colloquially referred to as “software patents”).
Although the amendments do not significantly change current practice at the European Patent Office, they do expand the guidance on what may and may not be protected with a European patent. They represent a significant upgrade and demonstrate the maturity of the case law with regard to computer-implemented inventions.
This post will review and highlight the updates. The post may be useful for those seeking to patent machine learning and artificial intelligence inventions. The updates cover the following areas:
- claims to distributed computing systems;
- inventions that use mathematical methods;
- AI and machine learning inventions;
- inventions that cover simulations and models; and
- inventions that relate to business methods, gaming, mental acts or computer programs.
Distributed Computing
Section F-IV, 3.9.3 has been added to the section relating to claims for computer-implemented inventions. It provides expanded guidance and an example relevant to processes operating in a distributed computing environment. These processes form a basis for many real-world implementations of computer-implemented inventions. For example, a smartphone accessing a cloud computing service would implement a process operating in a distributed computing environment.
The section sets out the current practice of the European Patent Office. Claims in a claim set may be directed to each entity of the distributed system and/or the system as a whole. Such a claim set may be argued to meet the requirement for multiple independent claims set by Rule 43(2)(a) EPC, i.e. the claims may be allowed despite having multiple independent claims in the same category because the subject-matter of the claims relates to a plurality of interrelated products. However, each individual claim will need to meet the requirements of novelty, inventive step and clarity.
For example, if a cloud computing service provides a new image classification function via an application programming interface that is accessed by a smartphone, a claim set may feature apparatus claims to both a server computing device (the cloud server) and a mobile computing device (the “accessing device” or smartphone). If the smartphone is simply a generic smartphone making a network request (e.g. an “HTTPS request to a REST API endpoint”), it will likely not be new when compared to known smartphones. An objection will be raised against the smartphone claim. However, if the smartphone implements some new low-level processing, e.g. some new feature extraction process that is specific to the new image classification function (like pre-extracting cat-like facial features), it may also be new and inventive in itself and be allowed.
The updated section draws our attention to the need for clarity in claims to distributed entities. It recommends that distributed method claims specify the entity that is performing each method step.
Claiming distributed processes in a challenge. In practice, one entity often implements most of the new and inventive process (e.g. the cloud server), while other devices are relatively “thin” and generic (e.g. the smartphone). However, claims to the accessing device are often of greater commercial value (e.g. they might allow a royalty for each smartphone that is sold). This often leads to the inclusion of claims to the mobile computing device in a claim set, but a high likelihood of an objection being raised by the European Examiner.
To attempt to overcome novelty and inventive step objections to “accessing device” claims, it is common to include an indirect or implicit reference to the functions of the server computing device. This can then lead to one or more clarity, novelty or inventive step objections. For example, the indirect features may trigger a clarity objection for not clearly specifying features of the “accessing device”. Alternatively, the indirect features may be ignored for novelty and/or inventive step, as they are deemed to present no inherent structural limitations for the “accessing device”.
When drafting claims to distributed systems, it is worth questioning the inventors to determine what functions may be implemented with low-level adaptations to the accessing device. If the invention can be embodied in an “app”, it is worth looking at the architecture of the app, and the sequence of low-level system calls it may be implementing. This may not be obvious to the inventors, as commercial and engineering demands often require as much functionality as possible to be embodied on the back-end in the cloud.
Mathematical Methods
The section on the examination of mathematical methods has been re-written and two sub-sections have been added. A first sub-section – 3.3.1 – now provides specific guidance for artificial intelligence and machine learning. A second sub-section – 3.3.2 – expands upon claims to simulation, design or modelling.
The updated guidance is now clearer on the importance of “technical means”, i.e. a concrete implementation in a field of technology, when an invention makes use of mathematical methods. This complements the recent changes to practice for “abstract inventions” in the United States.
I really like the updates to this section and the inclusion of helpful concrete examples. The section emphasises that a mathematical method or algorithm per se will not be enough to make a claim feature patentable, although many patentable inventions do have a mathematical or algorithmic basis.
Examples of the Fast Fourier Transform, geometric objects and graphs are provided: these features may contribute to the technical character of an invention if they contribute to producing a technical effect that serves a technical purpose. Put another way, these features need to be provided in a context that relates to an engineering problem encountered in the real-world, and the use of these features needs to result in a change in the real-world that helps solve that problem. This is further emphasised later in the guidance – the technical purpose of the mathematical features needs to be specific rather than generic, and the claim needs to be functionally limited to the technical purpose, either explicitly or implicitly.
What kind of applications are seen by the European Patent Office to be “technical”? My personal definition is: does the application relate to something in the real-world that requires knowledge that is taught in an undergraduate engineering degree? If the answer is “yes”, then the application is “technical”. If the answer is “no”, then the application may not be “technical”.
Section 3.3 now provides a useful list of purposes that are deemed “technical”. These include:
- controlling a specific machine or technical process, e.g. an X-ray apparatus or steel cooling;
- using measurements to control a machine or technical process, e.g. using a compaction machine to achieve a desired material density;
- digital audio/visual processing, this can be relatively high-level – detecting people is a provided example (but a clear relation to captured data is recommended);
- processing speech data, e.g. to generate text (but processing text per se may not be technical);
- encoding data, e.g. for transmission or storage;
- cryptography;
- load balancing;
- generating higher-level measurements by processing data from physiological sensors or other medical diagnosis;
- analysing DNA samples to provide a genotype estimate; and
- simulating “technical” things (this is described in more detail in new sub-section 3.3.2).
The section stresses that there must be a sufficient link between the technical purpose of the invention and the mathematical method steps, for example, by specifying how the input and the output of the sequence of mathematical steps relate to the technical purpose so that the mathematical method is causally linked to a technical effect. When drafting an application for Europe for an invention that features mathematical operations (e.g. equations and/or algorithmic designs), it is recommended to place such an explanation in the description – this can then be pointed to in examination if any objection is raised.
Similar to practice in the United Kingdom, the section ends by indicating that a feature may contribute to the technical character of an invention independently of any technical application, when the claim is directed to a specific technical implementation of a mathematical method, and the mathematical method is particularly adapted for that implementation in that its design is motivated by technical considerations of the internal functioning of the computer. Using the Fast Fourier Transform example, it may be possible to obtain protection for a new digital implementation of the Fast Fourier Transform, if you were performing specific mathematical operations that were adapted to the available computing resources of the implementation, e.g. available memory registers, processing cores, etc.
When considering inventions involving mathematical methods, one useful approach is to make an initial determination:
- Does the invention relate to a specific engineering application (e.g. what branch of “applied” maths is being considered)?
- Or does the invention relate to a new technical implementation of a mathematical operation (e.g. in effect a new and beneficial way of performing mathematical operations or “computing” using a device – sometimes called “core” inventions)?
A positive answer in the first case, suggests a quick check against the provided examples and the case law to determine if the specific engineering application has in the past been deemed to be “technical” under European practice.
A positive answer in the second case suggests looking carefully at the constraints imposed by the electronic hardware of the implementation. You will need to describe how the mathematical method is adapted, e.g. as compared to a “text-book” application, to provide concrete implementational improvements.
Artificial Intelligence and Machine Learning
Sub-section 3.3.1 is relatively short and seeks to summarise existing case law that applies in this area. This anticipates a large rise in patent applications over the coming years.
Machine learning inventions have been patented at the European Patent Office almost since its inception in the late 1970s. The present sub-section reminds us that despite the recent resurgence in neural networks, algorithms for approaches such as “classification, clustering, regression and dimensionality reduction” including “genetic algorithms, support vector machines, k-means, kernel regression and discriminant analysis” have been around for a number of years.
The sub-section stresses that the algorithms and approaches themselves per se of an abstract mathematical nature. The guidance from section 3.3 therefore applies: the invention either needs to relate to a specific engineering application that uses the approaches (e.g. using k-means clustering to classify packets in a network for selective filtering) or a new technical implementation of the approach that is constrained by technical factors at least the underlying computation hardware.
The sub-section hints that “technical character” often requires a clear causal link to measured data that represents physical phenomena. For example, classification of digital data such as physiological measurements, images, videos, or audio data is seen to be a common “technical application”. However, classifying text data is regarded as a “linguistic” and “non-technical” application. Likewise, general classification of “data” or “records” without a link to a specific technical problem would likely be seen as “non-technical”. Reference is made to case T 1358/09.
The sub-section ends by indicating that if a classification method is seen to serve a technical purpose then the steps of generating the training set and training the classifier may also contribute to the technical character of the invention if they support the technical purpose. This provides useful advice for drafting claims for inventions in this area: it is recommended to consider independent claims to the generation of training data and architecture training, as well as claims to an inference step. These claims may also provide a distributed processing system as discussed in section 3.3, for example inference may be performed on a smartphone, whereas data cleaning and training may be performed on a remote server. Care should be taken to cover different infringing acts.
Simulation, design or modelling
Sub-section 3.3.2 draws out material that was present in section 3.3. Discussing this material in a separate sub-section clarifies the high-level overview now present in section 3.3.
A computer-implemented simulation of a specific technical system or process may be seen to provide a technical effect and lead to a granted European patent. However, objections will be raised to computer-implemented simulations of non-technical systems or processes, such as those with an aim in the fields of finance, marketing, administration, scheduling or logistics. Care should be taken; cases such as T 531/09 indicate that the presence of technical devices (X-ray scanners in that case) is not enough to provide technical character, the technical devices need to be specific devices and the simulation needs to perform a technical purpose.
In the field of computer-aided design, the determination of a technical parameter which is intrinsically linked to the functioning of a technical object, where the determination is based on technical considerations, is a technical purpose. For example, a method of determining a particular value for a parameter of a specific technical device, in a manner that improves production or use of the device may be seen as suitably “technical”. Care should be taken if the design involves decisions to be made by a human being – e.g. the selection of an approved value – this intervention may be seen to break a causal chain that connects the design method to a technical purpose. Such decisions also risk importing factors that are outside of a narrow determination based on “technical considerations”.
Finally, this new sub-section suggests that claims that produce “models” will often lead to objections on the grounds that the models are not technical features per se; instead, they are seen as “abstract” mathematical or mental features. This again complements current practice in the United States. It is emphasised that generation of a model may be considered to lack a technical effect, even if the modelled product, system or process is technical. It this case it is important that the claim clearly indicates how the model is used, or to be used, in a technical system or process to solve a technical problem.
Business Methods
The previous high-level summary in section 3.5 has now been deleted, with this material being moved into separate sub-sections related to each of “performing mental acts”, “playing games” and “doing business”. Each sub-section then contains new material relating to each sub-category.
Each sub-section begins with a useful definition of each exclusion. Although this is described in the context of the exclusion being applied to the whole claim (e.g. the exclusion applying “as such” or “per se”), this often will not occur in practice, e.g. in most cases the exclusions set out in Article 52(2)(c) EPC will be avoided by having the method performed by a computing device. However, the definitions are useful as they indicate which claim features may be ignored for inventive step on the grounds that they provide no technical effect.
Mental Acts
These are described as instructions to the human mind on how to conduct cognitive, conceptual or intellectual processes. The learning of a language is given as an example, which hints at how the European Patent Office legally support an objection to “linguistic” features (e.g. text processing) as being non-technical.
When drafting claims to computer-implemented inventions, especially method claims, care should be taken to avoid accidentally falling within the exclusion. For example, claims should be checked to ensure that the method steps therein cannot be performed entirely in the human mind; at least one step needs to be performed outside of the human mind. In practice, considering whether a method step can be performed in the human mind is useful when predicting whether inventive step objections may be issued during European examination; if the determination is positive, the method step can often be drafted or amended in a manner that avoids this interpretation, e.g. by referring to a specific technical apparatus. The sub-section indicates that a method would not be seen as performing mental acts if it requires the use of technical means or if it provides a physical entity as a resulting product.
The sub-section does not indicate that mental steps are necessarily ignored for an analysis of inventive step; however, it does emphasise that are mental steps must contribute to producing a technical effect that serves a technical process. A good example provided in the sub-section is that of affixing a driver to a Coriolis mass flowmeter: steps specifying the position of the driver may be performed mentally but by defining the position so as to maximise the performance of the flowmeter, a technical contribution is provided.
Games
Games are defined in sub-section 3.5.2 as 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. Games are governed by game rules, that are by their nature abstract, mental entities that are only meaningful within a game context. Games may be simple – matching random numbers – or complex – video games with extensive virtual game worlds.
If a claim sets out technical means for implementing the rules of a game, it is not excluded as such and analysis moves onto inventive step. To provide an inventive step, a claim feature must make a technical contribution, i.e. provide some engineering benefit beyond a mere computer-implementation of the game rules. The benefit of a claim feature is to be assessed from the point of view of an engineer or game programmer, who may be given the games rules by a game designer as a “requirements specification”.
The sub-section indicates that in many situations the burden is on the applicant to show that a gaming invention provides a real engineering benefit. It notes that abstracting non-technical game elements, relying on a complexity of a solution or indicating cognitive content will not help the applicant.
It is interesting to compare the general negativity of this sub-section with cases such as T 928/03 and T 12/08 that presented a more liberal view of the technical nature of gaming inventions. It will be seen whether they represent a narrower approach than seen in the past.
Doing Business
Doing business is defined in sub-section 3.5.3 as including activities which are of financial, commercial, administrative or organisational nature. The latter two areas should be noted; they are often overlooked as they do not directly relate to making a profit but are still seen to be “non-technical”.
Some useful examples of “business method” features are provided. They include:
- banking,
- billing,
- accounting,
- marketing,
- advertising,
- licensing,
- management of rights and contractual agreements,
- legal activities,
- personnel management,
- workflows,
- scheduling of tasks,
- logistics,
- organisational rules,
- operational research,
- planning, forecasting,
- business optimisation, and
- data science for the purpose of managerial decision making.
If an invention relates to any of these features, it should be assumed to relate to excluded subject matter unless there is strong evidence that a technical problem is being solved by a technical solution that involves technical considerations.
For practitioners, a disclosure document or inventor from industry will often present an invention in terms of a commercial benefit. For example, inventors often become familiar with internally promoting an invention on commercial grounds. Care should be taken to dig behind these grounds and return to the underlying engineering aspects of the idea. If no engineering aspects can be presented, the idea may not be suitable for a European patent application. Examiners and Boards of Appeal will also use an indication of a commercial benefit, or the presence of the above business features, as evidence of a lack of a technical contribution. For this reason, it is recommended to avoid discussing these when drafting the patent specification.
Programs for Computers
Section 3.6 has now been redrafted and sub-sections 3.6.1, 3.6.2, and 3.6.3 have been added to respectively cover “further technical effects”, “information modelling” and programming, and “data retrieval, formats and structures”.
Section 3.6 now begins by indicating that computer programs must produce a “further technical effect” to avoid exclusion on the grounds of being a computer program “as such”. A “further technical effect” is an effect that goes beyond the normal operation of a computer, e.g. the physical effects of executing a computer program. Controlling a technical process or the internal functioning of a computer or its interfaces are deemed to be valid “further technical effects”.
Although not explicitly indicated in section 3.6, it is relatively straightforward to demonstrate a “further technical effect” and avoid an objection to the whole claim under Articles 52(2)(c) and (3) EPC. For example, claims to a computer program may be said to provide a “further technical effect” if they include instructions to implement a technical method, e.g. if they indicate a dependency to an independent method claim that is deemed technical. In this manner, European patent applications often feature claims to a “computer program for implementing the method of claim X”.
Further technical effects that may be demonstrated by a computer program are set out in sub-section 3.6.1. These include:
- controlling a technical system or process (e.g. a braking system of a car or an X-ray device);
- data processing in any of the areas highlighted in section 3.3, e.g. audio/visual processing, encryption or compression;
- improving the internal functioning of a computer running the program, e.g. programs that are adapted for a specific architecture or that provide benefits at the kernel or operating system level; and
- providing low-level tools such as compilers, memory allocators, and builders.
This updated section and its sub-sections are more useful in indicating what kind of features may be deemed to provide a technical effect. For example, if a feature of a computer program is deemed to provide a “further technical effect” as set out in this section, the feature would be seen as “technical” and be counted in any evaluation of inventive step (e.g. for other independent system or method claims).
Information Modelling and Programming
Sub-section 3.6.2 now provides useful guidance when the invention relates to aspects of computer engineering or software in itself, e.g. as opposed to a computerised solution in another field of engineering. While software developers may assume that their solution is technical according to the normal use of that term, features may not actually be “technical” for the requirements of patentability.
Information modelling is defined here as relating to providing a formal description of a real-world system or process. It may be seen to relate to models built in graphical or textual modelling languages, such as the Unified Modelling Language (UML) or the Business Process Modelling Notation (BPMN). Information Modelling may result in data models or templates that represent an underlying process.
Programming is defined as relating to the way in which computer code is written. It can involve choosing certain options or conventions for performing a common functional operation, or defining and providing a programming language, including text-based or graphical systems.
This sub-section stresses that information modelling or programming features that improve the intellectual effort of a programmer or software developer will often be seen to lack technical character and so cannot contribute to an inventive step. Benefits such as re-usability, platform-independence, conciseness, easier code-management or convenience for documentation, are not regarded as technical effects. For a feature to provide a technical effect, it must provide an improvement from the viewpoint of the computer, as opposed to the programmer. For example, manipulating machine code to provide for greater memory efficiency is seen as providing a technical contribution.
Data retrieval, formats and structures
Computer-implemented data structures or data formats embodied on a medium or as an electromagnetic carrier wave may be claimed, as they do not fall within the exclusions of Article 52(2) EPC. This sub-section has been relocated from previous section 3.7.
This section emphasises that cognitive data, i.e. data that is only relevant to a human user, cannot normally contribute to an inventive step. However, functional data, i.e. data that controls a device processing the data and that reflects technical features of the device, can.
Some examples of functional data are provided. These include a picture encoding, an index structure for a relational database, or a header structure of an electronic message. It is emphasised that the actually data content of the picture, database record or electronic message is often seen to be cognitive content and so cannot contribute to an inventive step.
IP Chimp 