Principle

An invention may include both technical and non-technical features (Guidelines G-VII 5.4), if considered in isolation.

However, the fact that a feature is non-technical is not sufficient in itself to exclude it from the inventive step reasoning: it is erroneous to conclude that the claimed subject-matter is not an invention because only the non-technical features make a contribution to the prior art (T154/04).

These « non-technical » features can certainly contribute to the inventive step if they contribute to the technical character of the invention to solve a technical problem (T336/14).

Thus, the question to be asked in the context of a « mixed » invention is: do the features contribute to the technical character of the invention?

Therefore, the criterion of whether the feature is technical or not (taken individually) is not the relevant criterion: we must look at the criterion of contribution to the technical character of the invention taken as a whole.

A reasoning such as « the invention is not inventive because the only technical contribution is the use of a computer » is not acceptable (T471/05 or T625/11).

Approach to follow

Features not contributing to the technical character?

Features that do not contribute to the technical character of the invention cannot support the existence of an inventive step (T641/00). However, they can be used in the formulation of the technical problem, as specifications to be met.

This may be the case, for example, when a feature helps to solve a non-technical problem, such as a problem arising in a field excluded from patentability (Guidelines G-VII 5.4).

By way of illustration, the specific operation of a neural network aimed at accelerating its learning does not solve a technical problem because it would rather aim to solve a mathematical problem (T702/20).

Features contributing to the technical character?

Principle

To identify these non-technical features (but which must be considered for the inventive step), it is necessary to identify the steps that have a technical contribution (Guidelines G-VII 5.4).

Assistance from the business person or administrative process

The notion of « business person » (or « entrepreneur ») can help distinguish business (administrative) considerations from technical considerations, as this person can only formulate business requirements without integrating technical aspects (T1463/11).

If the business person is not able to formulate a requirement, this requirement/feature is very likely to be technical (T2314/16).

If the feature makes sense to the business person because it corresponds to an organization of their business (e.g., range of production numbers of a product), this feature is very likely to be non-technical (T232/14).

For example, single password authentication will not be considered purely administrative (and therefore non-technical) because it goes far beyond what the business person can understand or specify (T1408/18).

Approach

To carry out a rigorous analysis, the guidelines (Guidelines G-VII 5.4) propose a systematic approach based on the problem-solution approach mentioned above:

  • identification of the features contributing to the technical character of the invention taken as a whole;
  • selection of the closest prior art based on this identification;
  • identification of the differences;
  • determination of the technical effects of the differences in order to identify the distinguishing features that contribute to the technical character of the invention (i.e., those that have a technical effect in the context of the invention taken as a whole).

The features contributing to the technical character of the invention will then be used for the reasoning of inventive step in a classical manner.

But of course, no one has ever given a definition of what is meant by « contribution to the technical character »… (see even point 5.3.6 of the decision T2825/19).

Indications concerning the contribution to the technical character

Principle

At this stage, and in view of the case law, we can consider that the feature in question must fulfill one or the other of these conditions to have a technical contribution:

  • it allows a particular technical implementation (i.e., related to the specific internal operation of a computer or a hardware implementation);
    • simple programming, a standard technical implementation, the fact that an algorithm is simply efficient, fast, etc., is often considered insufficient.
  • it allows a particular application to a particular technical field (i.e., technical purpose):
    • reference to a generic application (i.e., « control of a technical system ») is often considered insufficient.
    • the application to this technical field must be effective and not just possible.
    • this purpose can be the « output » of the process (e.g., determination of an operating parameter of a nuclear power plant T625/11).
    • this purpose can also be reflected in the input parameters of the process (e.g., operating temperature, pressure, T625/11).

But once I have said that, I have said nothing because no definition of the word « technical » exists.

Therefore, it is necessary to look at the case law in order to navigate between the concepts and to know what we can protect.

Focus on the application to a technical field

It is interesting to ask what the possible « technical fields » are.

Without listing them exhaustively, decision T1798/13 provides an interesting interpretation or at least one that has the merit of existing: the members of the Board of Appeal consider that this field must target a technical system that a person skilled in the art must be able to improve.

Thus, weather forecasting is, for the Board of Appeal, not technical, because it is not possible to improve « the weather » (this forecast would only be a discovery for the Board).

This approach leaves me very perplexed… indeed, this would exclude de facto:

  • methods for improving imaging in medicine;
  • seismic methods in the oil field;
  • etc.

Even if the improvement of a technical system seems to me to be part of a technical field, I do not think that this is limiting.

The application must be considered technical over the entire scope of the claims (T489/14). Indeed, if part of the application may concern a video game or only the « design » of a building (which is intellectual as opposed to construction).

Case of a broken technical chain

It may happen that the technical effect is obtained through a technical chain « broken » by the brain of an individual.

For example, if information is presented to a patient and if the technical effect is obtained depending on the processing of this information by the patient’s brain, then it is not possible to affirm that the technical effect is obtained thanks to the information presented (T970/12, T1670/07, T752/19).

Examples of technical contributions

Examples in the computer field

A technical contribution can be, for example (Guidelines G-II 3.6):

  • the control of an industrial process,
  • the internal operation of the computer itself or its interfaces under the influence of the program
  • the fact that the program has an impact on the efficiency or safety of a process,
  • the fact that the program has an impact on the management of the necessary computer resources
  • the fact that the program has an impact on the data transfer rate in a communication link.

It should be noted, however, that the acceleration of a calculation time is not in itself, for the Boards of Appeal, a technical effect likely to contribute to the technical character of an invention (T1370/11).

Examples in the field of artificial intelligence (AI)

(Between us, artificial intelligence should be treated like any computer algorithm, but since the Guidelines give us specific examples, I reproduce them)

A process implemented by an AI can be technical if its field of application is (Guidelines G-II 3.3.1):

  • medicine;
  • classification of images, videos, sounds.

However, the application to the following will not be considered technical:

  • classification of textual documents based solely on their textual content (??? what ???);
  • classification of abstract data;
  • classification of network data.

Of course, it is quite possible to attempt to save the latter cases by adding another technical purpose, e.g., classification of textual data to determine the best way to compress this data.

Similarly, the fact of obtaining a program that generates billing codes more accurately (non-technical) will not be considered technical (T755/18).

Example in the field of information presentation and user interface

As an illustration, an information presentation contributing to the proper functioning of a machine (e.g., guiding the user to correctly use the underlying technical system) may participate in solving a technical problem, whereas an information presentation contributing to better reading/analysis by a user (e.g., understanding or memorizing the steps of implementing the machine) should be considered non-technical (T336/14).

Thus, it is necessary that the information credibly helps the user perform a technical task through a continuous and guided human-machine interaction process (T336/14).

The mere fact of displaying information to facilitate a diagnosis will not be technical (T1091/17).

Furthermore, a method making haptic feedback more « realistic » would be technical, whereas a method « increasing the degree of engagement of players » (which is purely subjective) would not be (T339/13).

Similarly, increasing the satisfaction of a viewer is generally not technical, whereas providing a display timing device to increase this satisfaction can be (T1117/19).

Examples concerning simulation methods

In particular, computer-implemented methods of simulating objects (e.g., CAD) have a technical effect if this method has a future purpose, because « they are modern technical processes playing an essential role in manufacturing » (Guidelines G-II 3.3).

A method of simulating the performance of an electronic circuit using a mathematical method can be patentable if the mathematical method (which is not technical in itself) details how the simulation proceeds and is linked to the technical problem of simulation (T1227/05 and Guidelines Guidelines G-VII 5.4.2.4).

According to G1/19, a computer-implemented simulation method can, in itself, solve a technical problem by producing a technical effect that goes beyond the implementation on a computer.

We have often wanted to make a simulation claim « technical » by indicating that the input data is measured or real. This is not sufficient to make the invention technical, because the measurement and simulation are merely juxtaposed and do not interact to produce a combined technical effect (T489/14 ah ?).

Examples concerning mathematical methods

Moreover, computer-implemented mathematical methods have a technical effect if their purpose is technical (Guidelines G-II 3.3).

For example, an image processing method that results in a certain modification of the image is considered to be used in the context of a technical process (T208/84 and T1161/04).

Examples concerning business methods

A method intended to facilitate shopping (yes, I know, it’s not off to a good start, huh?) may be patentable if the distinctive feature is « determining an optimal shopping route for the selected products by accessing a cache memory in which the optimal shopping routes associated with previous requests are stored » (T1670/07 and T279/05 and Guidelines G-VII 5.4.2.1).

Indeed, for the EPO, this feature has a technical contribution because it concerns the technical implementation and has the technical effect of enabling the rapid determination of the optimal shopping route by accessing previous requests stored in a cache memory.

In the context of an automatic payment method triggered by an event (e.g., exiting a store), the non-technical features (such as the automatic triggering of the payment) are considered as constraints to be respected. If the technical solutions implemented to meet these constraints are known and their combination obvious to the person skilled in the art, the invention is deemed non-inventive (T351/19).

To identify the technical features, the decision T144/11 gives us a small methodology:

  • Establish the « business » need;
  • Integrate into this business need all the technical information necessary to achieve this « business » need (otherwise, the technically qualified person would have to design them, which is not their responsibility);
  • Formulate the technical problem on this basis.