Patenting software inventions in Europe: Understanding the need for a technical contribution

As part of a new series of articles, we discuss key takeaways from recent decisions by the Boards of Appeal at the European Patent Office, as these provide learning points for those seeking patent protection for software inventions in Europe.

BACKGROUND

Is my invention patentable? For most inventions, the answer is straightforward: yes, in principle, assuming the invention is new (novel) and not obvious (inventive).

For software inventions in Europe, however, the answer is usually another question: well, what does the software do? This is because the purpose or contribution of a software invention risks being found by the European Patent Office to be non-technical or falling under one or more areas that are excluded from patent protection1.

The following examples show that avoiding a finding of a non-technical contribution continues to present challenges for software inventions in Europe.

As further background to this article please visit our guide to software patents here, and our frequently asked questions here.

WIDE AND DEEP MACHINE LEARNING MODELS (GOOGLE)

This patent application relates to machine learning and combining a “deep machine learning model” and a “wide machine learning model” with a “combining layer.” The combination obtains, for a set of “features” provided as input, a “predicted output” from the outputs of the two models.

Google argued for a technical contribution of the claimed invention based on:

In general, a wide machine learning model can memorize feature interactions through a wide set of cross-product feature transformations and a deep machine learning model can generalize unseen feature combinations by applying embedding functions to the input features. By including both deep machine learning model and wide machine learning model, the wide and deep machine learning model can obtain both benefits of memorization and generalization and thus can perform better on predicting an output from a set of input features.” (paragraph [0013] of the application)

The Board disagreed with Google’s argument because the claimed invention takes an abstract input (a set of “features”) and produces an abstract output (a “predicted output”), neither of which has an inherent technical character.

The Board also cautioned that “the argument that only a "technical expert" could have devised the features of the invention” does:

not constitute a definite test as it only concerns which kind of considerations underlie some features of the invention and not which kind of effects are achieved by it. For instance, a claim to a computer-implemented simulation may involve features which are based on expertise in the technical field of the technical system that is being simulated. This alone would however not be sufficient to conclude that these features contribute to the technical character of the [claimed invention].

The patent application was refused based on the Board’s consideration that the claimed invention “does not reflect any considerations beyond computer programming (which encompasses the design of algorithms) and mathematics.

This case provides a cautionary takeaway on claiming machine learning inventions too generically in Europe: in isolation, abstract (purely mathematical) features are not sufficient to support a technical contribution. Instead, these features should be functionally limited to a specific technical purpose, either explicitly or implicitly and using established (clear) terminology.

A mathematical method may also support a technical contribution in Europe when a claimed invention is directed to a specific technical implementation of the mathematical method and the design of the mathematical method is motivated by technical considerations of the internal functioning of a computer.

For example, assigning the execution of data-intensive training steps of a machine-learning algorithm to a graphical processing unit (GPU) and preparatory steps to a standard central processing unit (CPU) take advantage of the parallel architecture of the computing platform. This may have resulted in a different outcome for Google had such considerations been detailed in the application and, ultimately, specified in the claims.

RESTRICTING LOW PERFORMERS' ACCESS TO A SYSTEM (FUJI) 

This patent application relates to restricting an operator from performing work in a production system if they are causing a lowered productivity. Doing so prevents a decrease in the efficiency of the system since operators who are not suitable for performing certain work are identified and have their access restricted.

Fuji argued that the claimed invention was not based on a pure management decision, and instead provided for an individualised restriction - all other operators were still able to perform production work - by storing and updating individualised “performance information.

Conversely, the Board held that the claimed invention merely automates the work of a manager:

observing workers on an individual basis, detecting performance issues of individual workers, and restricting the type of work that those workers are authorised to do based on the individual observations. All those things are non-technical requirements, (…).

This patent application was also refused.

A takeaway from this case is that management decisions alone, and methods of doing business as such more generally, cannot support a technical contribution in Europe.

HOW CAN I PROTECT MY SOFTWARE INVENTION USING PATENTS?

As the above examples show, navigating around the pitfalls faced by patent applications for software inventions can be challenging. To add further complexity to this area, there is no collective agreement among the major patent offices as to how software inventions should be assessed. Indeed, in certain cases, the absence of a collective agreement can lead to contrasting outcomes for an applicant. For example, while the patent applications discussed above were ultimately refused in Europe, the US Patent and Trademark Office granted corresponding patents2. It is important to note, however, that not all the arguments put forward in the US were applied in Europe, given the differing claim scopes pursued.

More generally, depending on the details of the software invention – which returns us to the additional question “well, what does the software do?” – seeking patent protection may not necessarily represent the best approach at the outset.

In our view, a specialist team that understands the challenges of patenting computer-implemented inventions is key to protecting the software, whether through patents or other IP rights (such as trade secrets), as it is this protection which is fundamental to the software's success.

To find out how to protect your software invention using patents or other IP rights, please feel free to contact us.

REFERENCES

  1. The technical assessment by the European Patent Office in this respect follows the established COMVIK approach. Briefly, this approach involves identifying differences of a claimed invention over the closest prior art and only considering those differences which contribute to claimed invention’s technical character (that is, which contribute to producing a technical effect serving a technical purpose) in the assessment of inventive step.
  2. See US10762422B2 Wide and deep machine learning models, and US10216159B2 Production system.