The Notional Business Person at the EPO

The EPO has been routinely refusing patent applications relating to inventions applied in a business sphere as ‘mere automation of a business or administrative method using a computer’.  It is of course desirable to have an idea of how the EPO will treat an invention having a business method aspect to it in advance of filing, and a couple of relatively recent decisions of the EPO Board of Appeal have established a useful framework to assist with this assessment.

EPO Guidelines indicate that so-called ‘mixed-type’ inventions are to be assessed by formulation of a ‘requirements specification’.  This is essentially a set of constraints generated at design time of the technical system, where the constraints are derived from the business context in which the technical system is to operate.  The pertinent question is whether the technical system has been configured using routine knowledge in order to meet these constraints or instead whether any technical problem has been solved.  In the former, the invention is inherently non-inventive; in the latter, the invention can in principle be inventive, depending only (as usual) on the prior art.

In decision T 1463/11 (‘CardinalCommerce’), Board of Appeal 3.5.01 reinforced the concept of the notional business person.  This is a business person equivalent to the skilled person; a fictitious legal person having specialist business knowledge but no technical knowledge.  The business person formulates the requirements specification discussed above as they know exactly what the business requires but do not have any idea regarding how to configure a technical system to meet these requirements.  In discussing the notional business person, the Board explained:

In the real world, there might be circumstances under which a business person might require some particular technology be used.  A real business person is not unaware of technology…” However, in the assessment of inventive step, the business person is just as fictional as the skilled person of Article 56 EPC….  Thus, the notional business person might not do things a real business person would.  He would not require the use of the internet, wireless, or XXXX processors.

Defining the notional business person in this way ensures that no technical information is included in the requirements specification.

CardinalCommerce therefore established a useful framework for stress testing an invention having business method aspects against EPO requirements.  One can imagine a meeting between the notional business person and the skilled person, in which the business person explains the business problem and asks the skilled person to provide a technical system to solve this business problem.  The information imparted at this meeting forms the requirements specification, and one can then ask whether the skilled person has any difficultly in configuring the technical system to meet those requirements.  If the answer is ‘no’, the invention is likely to be found routine automation of a business method by the EPO that is inherently unpatentable.  In the alternative where the answer is ‘yes’, it is likely that a non-obvious technical solution has been created; or, in other words, a patentable invention that just happens to operate in a business environment.

Board 3.5.01 has more recently issued another decision, T 1082/13 (‘SAP’), in which the abilities of the notional business person imbued in CardinalCommerce came under scrutiny.  The application in question claimed a computer-implemented method for applying tax legislation to a transaction — the business aspect therefore being immediately apparent.  In this later decision the Board departed slightly from the position established in CardinalCommerce in that the technical abilities of the business person increased slightly:

…the notional business person cannot be assumed to be so blind that he does not even know about the existence of computers or the Internet.  … What the notional business person does not know, however, is how exactly [the requirements specification] can be implemented on a computer system.  This is in the sphere of the technical expert and subject to the assessment of inventive step.

Clearly therefore the EPO is looking to see more than a high level description of the business steps being carried out by a computer.  This will not be enough — lower level details of how the computer carries out the steps will be necessary for the invention to have a chance of being considered inventive by the EPO.

It is also worth keeping in mind that the term ‘business method’ is construed broadly by the EPO and is essentially a catch-all for anything that is not technical.  The business method exclusion can therefore come into play where it is not expected.  A clinic manager can require that a medical system displays data gathered by a sensor of the system in place of patient provided data, but that patient provided data is displayed if no sensor data is available.  The rationale from the clinic manager is that it is best to see live, accurate data, but if this is not available some data is better than nothing.  As the EPO views the clinic manager as a non-technical person, this display choice is considered to form part of a requirements specification and hence is inherently non-inventive.  In this case, lower level technical details of the medical system would be required to have a chance of demonstrating an inventive step.

The take home message from these cases is that the EPO is looking for more than high level technical information to support an inventive step.  Describing a business step and stating that it is performed by a computer will not be enough.  It is essential to include details of how the computer actually operates, as otherwise one risks being caught between the requirements for inventive step on one side and the strict approach that the EPO has towards added subject matter on the other.  Where possible describe the invention in the context of a solution to a technical problem, with the business context being provided separately within the application as an example of the environment in which the invention may operate.  Asking the question as to where the impetus for the invention originated is also useful – is the working of the invention dictated largely by business requirements, or technical implementation choices?

If you would like to discuss any of the decisions raised in this article, please contact us via gje@gje.com