T 0144/11 - Technical but still in the business specification

Key points

• The Board provides a gloss to T1463/11: describing the problem as "how to implement the business method" is only a starting point. If a technical effect of the implementation becomes apparent, the problem must be reformulated has "how to achieve the technical effect". 
• The Board also emphasizes that "that the technically skilled person must receive a complete description of the business requirement, or else he would not be able to implement it and he should not be providing any input in the non-technical domain".
• The applicant had submitted: " The present invention enabled a safe and reliable security rating system which automatically provided investors with objectively calculated security rating values. This was technical. The popularity of a security was taken into account by counting the transmissions of rating values to investors. " The question is how to deal with the feature of counting the transmissions for the assessment of inventive step.
• The Board: "The popularity is measured by counting the number of transmissions. The observation that the "transmission of data" between a client and server is technical - which is undoubted - does not necessarily imply that the mere idea of "counting" these transmissions is also technical. The question is whether the idea of counting is on the business side of the line or on the side of the technical implementation." 
• "The Board judges that counting is rather part of the business specification. The more popular a security is, the higher is the number of investors interested in receiving information about it. Within a business setting, this would amount to counting the number of telephone calls, the number of emails sent, the number of letters, votes received, etc. All these thoughts are made by the notional business person." 

EPO T 0144/11 -  link


Key points
A problem of the type "implement [the business requirement]" will normally never lead to an allowable claim. Either the implementation will be obvious or have no technical effect, or if not, the implementation will have a technical effect that can be used to reformulate the problem essentially to "achieve [the effect of the implementation]".

However, the implementation-type problem is just a starting point that might have to be modified when the implementation is considered. It helps when a technical problem is not apparent at the outset. Examining the business requirements carefully and correctly establishing what is to be implemented ensures that all technical matter arising from the idea of the invention and its implementation is taken into account for inventive step.

2. Article 56 EPC - Deriving the technical problem

2.1 This case, like many in this field, is all about drawing the line between technical and non-technical subject-matter. This is of critical importance since as stated in decision T 641/00 (COMVIK), only features with technical character can support the presence of inventive step. As a result, non-technical aspects of the invention may legitimately appear in the formulation of the problem as part of the framework of the technical problem that is to be solved, in particular as a constraint that has to be met.

2.2 Recent decision T 1463/11 (Universal Merchant Platform / CardinalCommerce) considered this framework in the form of business requirements that a "notional business person" could give to the technical skilled person to implement. The decision stated at point 13 that the business requirements should not contain any technical aspects.

2.3 The invention in that case was about authenticating consumer-merchant transactions with financial entities using different authentication protocols. The idea of the invention was to move the software plug-ins that authenticate transactions from merchants' individual servers to a separate centralised transaction processing service provider server.
The examining division had considered that the invention amounted to outsourcing the authentication of a commercial transaction to a third-party, which was a business activity. The technical problem was thus how to implement this, the use of a separate server being obvious.

2.4 The Board considered that this abstraction [by the ED, PJL] overlooked technical considerations that were inherent in the use of plug-ins and servers. As a result, the concept of centralisation could not be included in the problem as a business requirement.

2.5 During the course of the present appeal, the appellant alleged that T 1463/11 did not actually state the technical problem that centralising the authentication plug-ins in a separate server solved. However, the present Board considers that it was implicit from the statements in points 21 and 23 of this decision that the problem was to simplify software maintenance at the merchant servers.

2.6 Removing the concept of "centralising" from the business requirement meant that it became part of the solution. The technical problem changed from implementing the business requirement to achieving the effect of the centralisation, namely to simplify software maintenance at the merchant servers. The Board went on to find that solution inventive. This case demonstrated that a careful analysis of which parts of a claimed feature involve a business requirement can help to resolve the grey area between technical and non-technical features.

2.7 A corollary of this approach, and what is seen in practice, is that a problem of the type "implement [the business requirement]" will normally never lead to an allowable claim. Either the implementation will be obvious or have no technical effect, or if not, the implementation will have a technical effect that can be used to reformulate the problem essentially to "achieve [the effect of the implementation]". However, the implementation-type problem is just a starting point that might have to be modified when the implementation is considered. It helps when a technical problem is not apparent at the outset. Examining the business requirements like that and correctly establishing what is to be implemented ensures that all technical matter arising from the idea of the invention and its implementation is taken into account for inventive step.

2.8 In the Board's view, another constraint is 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 he should not be providing any input in the non-technical domain.