9.2.7 The notional business person

In T 1463/11 the board introduced the notional business person. The board noted that if the essential idea of the invention lies in a non-technical field (usually one excluded by Art. 52(2) EPC, such as business, programs, or presentations of information), the objective technical problem often amounts to a statement of requirements that any implementation must meet. The assessment of what is and what is not technical is, therefore, a critical step in the formulation of the objective technical problem. A non-obvious difference over the prior art leads to a positive outcome, if it is deemed technical; but a non-obvious difference that is deemed non-technical leads to a negative outcome. This often leads to opposing definitions of the problem and must therefore be analysed precisely. The formulation of the objective technical problem in terms of non-technical requirements raises the question of what requirements the business person (for example) can actually give to the technically skilled person. Naturally, any requirement that is purely a business matter can be included. However, in the assessment of inventive step, the business person is just as fictional as the skilled person of Art. 56 EPC. The notion of the skilled person is an artificial one; that is the price paid for an objective assessment. So it is too with the business person, who represents an abstraction or shorthand for a separation of business considerations from technical. A real business person, a real technically-skilled person, or a real inventor does not hold such considerations separately from one another. Thus, the notional business person might not do things an actual business person would. He would not require the use of the internet This approach ensures that, in line with the Comvik principle, all the technical matter, including known or even notorious matter, is considered for obviousness and can contribute to inventive step. Similarly, the notional business person might do things that a real business person would not, such as include requirements that go against business thinking at the time - a sort of business prejudice. If this were not the case, business requirements would need to be evaluated and would contribute to inventive step, contrary to the Comvik principle.

In T 144/11 the board followed T 1463/11 and held that the technical skilled person must receive a complete description of the business requirement, or else he would not be able to implement it and should not be providing any input in the non-technical domain.

In T 1082/13 the board held that the notional business person, as interpreted within the framework of T 641/00 knows all about the business related requirements specification and knows about the fact that such business related concepts can be implemented on a computer system. The choice of where to do a calculation in a distributed system is not necessarily technical, but can also be driven by administrative considerations. What the notional business person does not know, however, is how exactly it can be implemented on a computer system. This is in the sphere of the technical expert and subject to the assessment of inventive step. When referring to prejudices, it has to be carefully analysed, whether it is actually a technical prejudice or, in fact, a business prejudice.

In T 1408/18 the board found that a business person who wanted to offer a product enabling users to make a transaction on a single terminal device would specify that the transaction could go ahead only after user authorisation and that, in keeping with the latest trends, it would be desirable for users to be able to make all necessary entries on their smartphone. By contrast, using a TAN-based process, including dealing with how the TAN could be transmitted securely, fell within the sphere of a technical expert. Building on traditional PIN-based password authentication, using a TAN, i.e. a one-time password, added a second layer of security. The associated interaction of two applications and communication channels for obtaining and providing a TAN led to two-factor authentication guaranteeing greater security. So, regardless of how a TAN-based process was used in practice, there were technical considerations behind it that went beyond the technical understanding that could be expected of a business person.

In T 2455/13 the board endorsed the above reasoning in T 1082/13 and added that, features were not technical where they were specified merely as modules on an abstract meta level and represented functions the "non-technical skilled person" would base their idea on; after all, in outlining these functions, that person would not be considered to have dictated any technical features either. It was only once actual implementation steps had been specified in the claim that such modules could be treated as technical features.

In T 737/14 the board held that the proper application of T 641/00 required a thorough analysis of the business constraints when formulating the problem to be solved before investigating what the skilled person would have done to solve it.

In T 817/16 the board considered that a useful test for determining whether such technical considerations were present was to ask whether the non-technical features would have been formulated by a technical person rather than by a non-technical person or persons (T 1214/09, T 1321/11, T 1463/11, T 136/13). This was not an enquiry into the actual state of technical or non-technical knowledge at the effective filing date; the question was rather whether the knowledge required for coming up with the non-technical features in the particular case was of a kind that only a technical person, i.e. a person not working exclusively in areas falling under Art. 52(2) EPC, could possess.

In T 1902/13 the board held that a business consultant, who wanted to assess the competence of an organisation, would design a set of rules and questions which could be reused for another organisation. Automating parts of this process did not render it technical. The board did not agree that the business person and the skilled programmer would have to sit together in order to elaborate a workable solution. Rather, the underlying administrative concept would be provided to the programmer as a requirements specification.

In T 1749/14 the board held that the notional business person might come up with the abstract idea of avoiding the customer having to provide PIN and account information to the merchant. The invention however required a new infrastructure, new devices and a new protocol involving technical considerations linked to modified devices and their capabilities as well as security relevant modifications of the transfer of sensitive information using new possibilities achieved by the modifications to the previously known mobile POS infrastructure. This went beyond what the notional business person knew and concerned technical implementation details which were more than a straight-forward 1:1 programming of an abstract business idea. This was in the sphere of the technical expert and subject to the assessment of inventive step (see T 1082/13).