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).
- T 698/19
If non-technical features have both a technical and a nontechnical effect, the technical effect must be taken into account when assessing inventive step, but the technical effect must be clearly derivable from the application as a whole (Reasons 3.6.4 (1)).
- T 524/19
While a feature might, in certain contexts, be seen as technical, the technical effect of a feature must be assessed as a whole and in the context of the claimed invention (reasons 2.7.4).
- T 2626/18
The appellant argued that the claimed features relating to the abstract business concept neither could have been provided by the business person to the technical expert for programming, nor would the technical expert have corresponding knowledge starting from a networked standard computer system. The appellant thereby alleged that there was to be considered an imaginary third person who came up with the concept of the invention to be implemented on a computer system. The Board notes that when assessing inventive step in the field of computer implemented business related inventions following the COMVIK approach and the corresponding case law, there is no room for such a third expert. When analysing the features of a claim and answering the question of whether they provide a technical contribution, each such feature has to be judged to be either a contribution of the technical expert or of the non‑technical business person in order to conclude whether there is an inventive technical contribution.
- T 1026/17
In the Board's judgement it is part of the non-technical requirement specification to keep keys (be it analog or electronic keys) away from people one does not trust. This does not require technical considerations of a technically skilled person. The Board does not consider this to be a technical difference, but to be an administrative consideration within the sphere of a business person when contemplating a secure tender process. It is not regarded as a technical innovation, but a natural choice for the bidders to use individual keys, keep the keys back as long as possible and furnish them as late as possible. And even if this was considered technical, it would, in the Board's view, be obvious to do so. Furthermore, the Board considers that implementing a functionality in the networked e-tender system corresponding to D1 would be, at the claimed level of generality, obvious in view of the above business related requirement specification. The Board notes that the implementation is claimed in functional terms and neither the claim nor the application as a whole provide details on how encryption/decryption is achieved on a technical level. The application apparently relies in this respect on the skilled person's common general knowledge. The Board notes in this regard that if providing necessary software and data structures were beyond the skilled person's skills, the invention would not be sufficiently disclosed (Article 83 EPC). Even if the appellant is correct that using different keys for different bidders is a difference over D1, this would in the Board's view imply - in the light of bidders creating their own individual keys for unlocking/decrypting being obvious - that the keys of different bidders are different, too. Therefore creating individual keys/pass-phrases would inherently require the use of multiple keys for implementation. (See points 4.2 to 4.4 of the reasons)