IP in software: What type of software is patentable in Europe?

Before we look at what type of software is patentable in Europe, it may be useful to look at what type of software isn’t patentable in Europe.

Articles 52(2) and (3) of the European Patent Convention (EPC) tell us that some technologies are excluded from patentability:

“The following in particular shall not be regarded as inventions… schemes, rules and methods for performing mental acts, playing games or doing business, and programs for computers; presentations of information…”

However, this technology is only excluded from patentability to ”the extent to which a European patent application or European patent relates to such subject-matter or activities as such.”

This wording is critical. It means that if the software performs a technical function and we can focus the patent on this technical function, then innovations in software can be protected effectively.

WHEN CAN SOFTWARE BE PATENTED?

If you believe your software can be patented, the next question you will probably ask is when it should be patented. The simple answer is when it makes a technical contribution over the prior art.

The European Patent Office has been dealing with the issue of when software makes a technical contribution for years. As attorneys who specialise in patenting software and software-related inventions, we understand the EPO’s approach and can predict if your software is likely to be the right type of software or not.

The first thing we need to find out is the role the software plays in your product. We can then assess the technical contribution it makes and, should a patent application be sought, describe the software in a way that emphasises the technical function it provides.

This conversation usually begins with a discussion with the inventor on the advantages the software provides. These advantages could be that the software provides cost savings or enables better transactions to be performed or provides a better user experience.

To be patentable the software needs to solve a technical problem. Therefore, once we identify the advantages, we need to analyse them in much greater detail.

For example, are the cost savings borne out of the software providing improved efficiency or the output of a more accurate parameter that can be used to control a process?

Or, is the “better transaction” a more secure transaction? Is the better transaction a more convenient transaction and, if so, how is security and integrity maintained?

Or, what does the “better user experience” achieve? Can the user now use the software to create something more effectively? Does the software enable the user to perform a task despite the existing limitations of the hardware?

Thinking more deeply about the advantages may reveal the technical considerations behind them and help identify the ‘right type of software’.

PATENTABILITY REQUIREMENTS FOR SOFTWARE INVENTIONS

The examination of software-based inventions will almost certainly look a little different to more conventional inventions. This means it’s important you understand the differences in the patentability hurdles you need to jump over.

For most patents, there are just two hurdles to clear:

1. Are the claims novel over the prior art?
2. Does the invention provide a solution to a problem in a non-obvious way?

However, with software patents there is often an initial hurdle that must be cleared before you can move forward to these questions.

Also, the final hurdle can be a little higher as the European Patent Office focus their attention on the technical features of the claim. So, the hurdles look more like this:

1. Do the claims include technical features?
2. Are the claims novel over the prior art?
3. Does the invention provide a solution to a problem in a non-obvious way?

This means you may need to start the patenting process by showing the patent claims include technical subject matter, but that hurdle is relatively low. The most significant change is the assessment of inventive step because only features that contribute to the technical character of the invention can be considered for inventive step purposes.

Software-based patent applications are often considered by the EPO as mixed-type inventions. A mixed-type invention is one in which the claims comprise technical and non-technical features. The EPO’s problem-solution approach to assessment of inventive step is modified as follows:

1. The features within the claims which contribute to the technical character of the invention are determined on the basis of the technical effects achieved in the context of the invention. This can be considered as going through the claim labelling which features have a technical effect and which do not. This step needs to be considered very carefully because much of the analysis that comes later is based on what is deemed to have a technical effect.
2. With reference to the prior art, a document is selected as the closest prior art taking account of the features that are labelled as contributing to the technical character in step 1.
3. The differences from the closest prior art are identified. The technical effect(s) of these differences, in the context of the claim as a whole, is/are determined in order to identify from these differences the features which make a technical contribution and those which do not. This debate is likely to lead to one of three answers:
   1. There are no differences which means the claims will be deemed to lack novelty.
   2. The differences do not make any technical contribution. This means the claim will be deemed not to be inventive. This is because the EPO require there to be a technical contribution over the prior art for there to be an inventive step.
   3. The differences include features that do make a technical contribution. This means we can work out what is the technical problem solved, in step 4.
4. The objective technical problem is formulated on the basis of the technical effect(s) achieved by the distinguishing features that make a technical contribution. The big difference here over more conventional inventions is that any non-technical effects achieved by the invention may be used in the formulation of the objective technical problem.

For instance, if the invention involves a method of doing business or some administrative tasks (which the EPO would consider as non-technical), then the EPO may say that the problem to be solved is how to implement the business method/administrative task. That is, they effectively assume that the business method/administrative task is already known for the purposes of this part of the patentability test.

If the implementation of the method/task is straightforward once the software developer has been told what functionality is required, then this will probably result in the solution to the problem being considered obvious and no patent being granted. It is therefore fundamental to success that step 1 is considered very carefully and that the invention addresses a problem which is not solely related to a specific business or administrative context.

So, to summarise, what we are looking for is an invention that provides a non-obvious technical solution to an objective technical problem.

If you would like to explore the patentability of your software with one of the software specialists in our dedicated electronics and communications team, please contact us today.