10 November 2022

T 0698/19 - Technical effect must be derivable from the application as a whole

Key points


  • The applicant of the application at issue is Swiss Reinsurance Company Ltd.
  •  Board 3.4.03 in the headnote: " If non-technical features have both a technical and a non-technical 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".
    • This statement appears to combine two distinct rules: 1) "If non-technical features have both a technical and a non-technical effect, the technical effect must be taken into account when assessing inventive step" and 2) a  "technical effect must be clearly derivable from the application as a whole".
  • The arguments of the applicant: " Prior to automation, the handling of insured loss cases was handled by an insurance agent who determined the amount of loss to be reimbursed based on similar claims and the insurance policy. In the 1960s, attempts were made to automate the handling of claims by a computer. For this purpose, the procedures were parameterized, which led to an efficient (but less accurate) claims handling. However, there were parts that could not be parameterized. The present procedure solved this problem by automating these non-parameterized parts through pattern matching with historical data by use of seamless integration. The invention represented the complete automation of an insurance premium payment. Automation was technical as such and had a technical effect." 
  • The Board: " Automation is admittedly technical in itself. This is inherent in the very fact that the method runs on a computer. The board agrees with the Appellant that in the present case technical and non-technical features are interwoven and that generally non-technical features can have a technical effect. If non-technical features have both a technical and a non-technical 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." 
  • " The Board is not persuaded either that steps (b) to (d) in combination  have a technical effect, i.e. improving the stability of the automated system of the invention, for the following reasons."
  • "Disclosure as to how the algorithm is implemented in practice must be provided in order to give evidence that the algorithm has any proved further technical effect with respect to known algorithms and that it provides an improvement over the prior art. The present invention has the object to provide a stable system. However, as discussed above, no details are given why the proposed system should be considered to provide better stability than any other system, for example, how and at which level improved stability or accuracy of the algorithm is achieved, which kind of data is used for pattern matching, how historical data is selected, prepared and compared, and which parameters are matched. The only data provided in the application is pure economical data (see e.g. Fig. 3)."
    • Note, " The system should be stable and "give basis to better investment grounds for partners and clients supporting the system" (description, page 3, lines 28-33)." The term 'stability' of the automated insurance system may refer, possibly, to financial stability, but the Board's decision does not comment on that point.
  • "To summarise, any further technical considerations or effect must be derivable from the application as a whole and the claims must comprise the specific features which contribute to the further technical effect of the invention, ... "
  • The Board adds: "... since it must be made clear to third parties what the technical part of the invention is, and the technically skilled person needs these details to carry out the invention (Article 83 EPC). This is not the case for present claim 1." 
    • As a comment, it may also be said that an inventive step is to be based on features specified in the claim and the technical effect provided by those features (if any).
EPO 
The link to the decision is provided after the jump, as well as (an extract of) the text of the decision.




1. The appeal is admissible.

2. The invention

2.1 In the poor regions of the world, there is a massive gap between economic and insured losses due to the lack of appropriate means in the risk transfer and damage covering business. The present invention aims at solving these problems (description, page 1, lines 18-26) by resource-pooling for risk sharing of a number of risk exposure components (i.e. policy holders).

2.2 The invention proposes a system for automated pay-out of insurance premiums. The system comprises a network computer for calculating a likelihood of risk exposure, receiving and storing payments, dividing a risk into a parameterizable part and a non-parameterizable part and in case of a loss transferring payments from both risk pools to the policy holders. The system should be stable and "give basis to better investment grounds for partners and clients supporting the system" (description, page 3, lines 28-33).

3. Article 56 EPC

3.1 Closest prior art

D1 is chosen as closest prior art because it also relates to an automated system for automatically dealing with insurance events in a network computer system. Therefore, D1 is a more suitable starting point than the standard computer chosen as the starting point in the impugned decision.

3.2 D1

D1 discloses a system for automatically claiming reimbursement from an insurance company in case of personal or material damage. The payments are automatically transferred to the account of the client.

3.3 Difference

It was not contested that D1 discloses features (A) to (D) and part of feature (P) ("transferring payment parameters"). D1 therefore fails to disclose at least features (E) to (O) and a part of feature (P).

3.4 Effect - technicality

Claim 1 of Annex A is directed at a mixed-type invention. It is thus appropriate to determine the features which do achieve a technical effect and the ones which do not.

3.5 Technical aspects of claim 1

The aspects in features (A) to (P) which clearly achieve a technical effect are that

1) an (unspecified) computer is used,

2) data are stored in different database modules and

3) different system modules (e.g. system (1) and system (3)) interact via an internal or external computer connection.

3.6 Non-technical features

3.6.1 In the summons to oral proceedings the Board noted that in its preliminary opinion the following features and aspects related to an abstract economic model for determining and transferring insurance risks:

(a) the total risk of the pooled risk exposure components = a first risk contribution (associated to risk exposure in relation to loan losses) + a second risk contribution (associated to risk exposure based on emergency expenses);

(b) the pooled risk is divided into a parameterizable risk part (transferred to a connected loss coverage system) and a non-parameterizable risk part;

(c) the non-parameterizable risk part is limited by ad-hoc setting of loss settlement parameters using pattern matching of historical long term development patterns;

(d) the separation of the parameterizable / non-parameterizable part is connected through a seamless integration keeping the risk exposure components not affected by the difference in the transfer (features (L) to (N));

(e) the variable number of pooled risk-exposure components is adapted to a range where not-covariant occurring risk affects only a relatively small portion of the totally pooled risk exposure components at a given time (feature (O));

(f) associated loans and emergency expenses of the risk exposure components are based both on the parameterizable risk part and the non-parameterizable risk part.

3.6.2 Steps (d) and (e) were considered ambiguous and unclear under Article 84 EPC (the essential feature (L) contradicts the description and feature (M)). As stated by the Appellant during the oral proceedings, to overcome the clarity objection feature (L) must read "parameterizable" instead of "non-parameterizable" (see point IV above). In the following examination of inventive step, the Board used the correct version.

3.6.3 The Appellant's arguments may be summarised as follows.

(1) At least steps (b), (c) and (d) contributed to the technical character of the invention. The system and method according to claim 1 was not suitable for manual implementation and was therefore not process-related to the business per se, but contained technical-related characteristics that only made sense in connection with automation and which in a non-trivial manner resulted from the basic knowledge of the computer specialist. The additional features were therefore intrinsically related to the technical field of automation.

Prior to automation, the handling of insured loss cases was handled by an insurance agent who determined the amount of loss to be reimbursed based on similar claims and the insurance policy. In the 1960s, attempts were made to automate the handling of claims by a computer. For this purpose, the procedures were parameterized, which led to an efficient (but less accurate) claims handling. However, there were parts that could not be parameterized. The present procedure solved this problem by automating these non-parameterized parts through pattern matching with historical data by use of seamless integration. The invention represented the complete automation of an insurance premium payment. Automation was technical as such and had a technical effect.

(2) The technical improvement consisted mainly in the splitting of the loss into parameterizable and non-parameterizable parts (here "splitting"). The "seamless integration" was a numerical method that made "splitting" technically possible in the first place. The two curve components of the "splitting" were connected by "seamless integration", so that a mathematical integration below the curves (parameterized loss over time, non-parameterized loss over time) was possible. This "splitting" could not be known to the notional business person.

The notional business person only knew purely non-technical features. This technical solution to a problem subject to a business plan could therefore not be given by the notional business person. In the case of a separation of technical and non-technical features, a feature with a technical effect could not be attributed without justification to the notional business person who, in contrast to the real business person, had no technical understanding at all. As there was neither a non-technical nor a technical motivation for a "seamless integration" of parameterized and non-parameterized parts or for "splitting", these features were purely technical and had a technical effect.

(3) The same reasoning applied for "pattern matching".

(4) As was pointed out in G 1/19 (Reasons 47, 85, 110), it was fundamentally irrelevant whether a simulated process or underlying procedure was of a technical or non-technical nature. Rather, the question was whether the means indicated constitute a technical contribution, in the sense that it could be improved by a technically skilled person. The technical problem here was precisely that no algorithm could be formulated for the non-parameterizable part of the data processing, otherwise this part could be calculated directly by means of the corresponding relation of the parameters or the algorithm.

FORMULA/TABLE/GRAPHICdrawing of G 1/19

(5) According to the scheme of G 1/19, the present invention provided a technical contribution within the rectangle, since the algorithm of steps (b) to (d) improved the stability of the system.

3.6.4 The Board is not persuaded that steps (b) to (d) on their own (see the Appellant's arguments 3.6.3(1) to (4) above) contribute to the technical character of the invention for the following reasons.

(1) Automation is admittedly technical in itself. This is inherent in the very fact that the method runs on a computer. The board agrees with the Appellant that in the present case technical and non-technical features are interwoven and that generally non-technical features can have a technical effect. If non-technical features have both a technical and a non-technical 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.

In the present case, the automation predominantly serves the automatic payment of an insurance premium and thus has a purely non-technical purpose. The payment itself is undoubtedly a technical process, but it is motivated by a business plan or (in the image of "notional business person" versus "technically skilled person") commissioned by the "notional business person" and worked out by the technically skilled person in a straightforward manner. The "notional business person" - unlike the "real business person" - must not have any technical skills or knowledge about how to implement an algorithm in a computer system.

(2) "Seamless integration" could indeed be regarded as a technical feature with a technical effect in the sense of the Appellant's arguments. However, the Board doubts that "seamless integration" means pure integration in the mathematical sense, i.e. the mathematical or numerical calculation of an area under a curve. The term "seamless integration" is generally known in connection with software integration and means a smooth integration of new functionalities into an existing software. The calculation of the area under a curve, which shows the total loss for a certain loss category for the total number of claims over time - and which also makes estimates for the future - makes no sense when calculating the loss or risk amount of a single micro credit.

The only explanation in the application of what "seamless integration" could mean is provided in original claim 6, namely "that the risk exposure components [= policy holders] receive a single payment", which is more indicative of the Board's interpretation "smooth integration" in the sense that two separate payments (one for the parameterized approach, one for the non-parameterized approach) are not made, but only a single payment for both approaches. This again reflects the non-technical character of said feature.

(3) The starting point of the invention is generally a parameterized treatment of a loss case as it must implicitly underlie the procedure in D1 as D1 discloses an automated system for insurance premium pay-out. A non-parameterized pattern matching is to be integrated into this procedure. This pattern matching is an automation of the procedure of the insurance agent, who tries to treat each loss case consistently with past loss cases. It is the object of the invention - and a business constraint - that this pattern matching module must be integrated into the parameterizing module without affecting it. The Board agrees that the detailed technical implementation is the task of the technically skilled person and could not be undertaken by the notional business person.

Since the approach of handling a new insurance claim by reference to historical claims is a classic non-automated approach to dealing with insurance claims, it is an obvious objective to automate this approach as well. Neither the claims nor the application disclose in detail how the "pattern matching with historical data" is performed. This method might contain technical and inventive features, e.g. how the historical data is numerically prepared, how an algorithm is trimmed to recognise patterns and according to which criteria the matching is assessed. However, the application does not provide any technical details about this, neither about the methodology nor which parameters are treated with pattern matching.

(4) On the general and abstract level of software design it is the objective of the invention to integrate the "pattern matching module" into an existing automation module in such a way that its function is not impaired. Since splitting in itself has no other effect than to combine a known (parameterized) automation with an automated classical method (pattern matching as performed by an agent), the skilled person does not need any technical skill at this more general level to understand said objective. This is only necessary for the specific technical implementation of pattern matching, which however is neither reflected in the claim wording nor in the application as a whole.

The notional business person can therefore, without any technical expertise, commission a technically skilled person to integrate a pattern matching method into the parameterised automation process so that the software integration runs smoothly, just as the notional business person can commission a two-storey passenger aircraft with a budget of 10 billion euros without having detailed technical knowledge of how to implement it.

(5) Therefore, the Board concludes that steps (a) to (f) relate to an economic algorithm which implements an abstract economical model, and that consequently steps (b) to (d) on their own do not contribute to the technical character of the invention.

3.6.5 The Board is not persuaded either that steps (b) to (d) in combination (see the Appellant's argument 3.6.3(5) above) have a technical effect, i.e. improving the stability of the automated system of the invention, for the following reasons.

(1) According to G 1/19, Reasons 110, non-technical features may contribute to technicality if they are, for example, a reason for adapting the computer or the way in which the computer operates, or if they contribute to technical effects relating to the results of the simulation. An algorithm contributes to the technical character of a computer-implemented method only in so far as it serves a technical purpose (cf. also G 1/19, Reasons 112 citing T 1358/09 and T 1784/06).

(2) An algorithm is defined as a process or set of rules to be followed in calculations or other problem-solving operations, especially by a computer (see Wikipedia). Therefore, the Board considers "pattern matching" (using non-parameterizable functions and description) as one component of the algorithm. According to T 258/03, Reasons 5.8, an algorithm may be considered to provide a technical contribution to the invention, if it is particularly suitable for being performed on a computer in that its design was motivated by technical considerations of the internal functioning of the computer. However, following G 3/08, Reasons 13.5 and 13.5.1, such technical considerations have to go beyond merely finding a computer algorithm to carry out some procedure (G 1/19, Reasons 11, 112, 115).

(3) It is not contested that the claimed method might provide better results than known methods, but this is an inherent property of deterministic algorithms. The mere fact that an algorithm leads to better results does not imply that it makes a technical contribution. The Board is of the opinion that (see also T 2147/16, catchword)

(i) the implementation of steps (b) to (d) into the method for evaluating and sharing risks must have a technical effect or specific technical considerations;

(ii) such technical effect should be derivable from the application as a whole;

(iii) the algorithm must serve a technical purpose.

ad (i)

(4) Formulating an algorithm is a cognitive exercise (see G 1/19, Reasons 112). The definition of an algorithm does not necessarily involve technical considerations (see G 3/08, Reasons 13.5.1). According to T 1358/09 (Reasons 5.2 to 5.7) an algorithm may be particularly suitable to be run on a computer in that its design was motivated by technical considerations relating to the internal functioning of the computer. It was further concluded that not all efficiency aspects of an algorithm are by definition without relevance for the question of whether the algorithm provides a technical contribution.

In G 1/19, Reasons 115, it was confirmed that a computer software - including the underlying algorithms - may contribute to the technical character of a computer-implemented invention inter alia in that it is adapted to the internal functioning of the computer or computer system/network, if it does not serve another technical purpose.

Disclosure as to how the algorithm is implemented in practice must be provided in order to give evidence that the algorithm has any proved further technical effect with respect to known algorithms and that it provides an improvement over the prior art. The present invention has the object to provide a stable system. However, as discussed above, no details are given why the proposed system should be considered to provide better stability than any other system, for example, how and at which level improved stability or accuracy of the algorithm is achieved, which kind of data is used for pattern matching, how historical data is selected, prepared and compared, and which parameters are matched. The only data provided in the application is pure economical data (see e.g. Fig. 3).

ad (ii)

(5) According to T 154/04, Reasons 5, under (E) and (F), for examining patentability of an invention in respect of a claim, the claim must be construed to determine the technical features of the invention, i.e. the features which contribute to the technical character of the invention. However, the present invention does not provide sufficient and specific disclosure, such as parameters, how the algorithm is optimised for the computer, nor is this reflected in the claim wording.

To summarise, any further technical considerations or effect must be derivable from the application as a whole and the claims must comprise the specific features which contribute to the further technical effect of the invention, since it must be made clear to third parties what the technical part of the invention is, and the technically skilled person needs these details to carry out the invention (Article 83 EPC). This is not the case for present claim 1.

ad (iii)

(6) The algorithm claimed in the present invention depends on the specific inputs of the insurance company according to the underlying business model, i.e. insurance conditions and insurance policy. A principal purpose is the automatisation of payment transfers. For these reasons, the purpose of the claimed method is considered non-technical. The present risk assessment algorithm requires as input a certain type of historical data in a certain format or requires conditioning by the (notional) business person to train the algorithm, e.g. which kind of risks or events should be taken into account and how they should be classified and evaluated (e.g. conditions for the "ad-hoc setting of loss settlement parameters"). This depends on the individual boundary conditions, e.g. contract conditions of each insurance company and the individual insurance policy. The parameters and structure of the algorithm therefore have to be adapted to the individual insurance contract and the corresponding insurance conditions. Therefore, a risk evaluation and risk transfer system cannot have a purely technical purpose if the classification and parameters depend on the underlying economical model, e.g. parameters sets of the insurance companies and insurance contracts, such as the insured capital, types of events insured, payment parameters, lump sums etc.

(7) In summary, the board considers that any technical effects beyond merely finding and implementing an algorithm to run the algorithm on a computer cannot be derived from the application as a whole.

3.6.6 Consequently, steps (b) to (d) in combination ("splitting", "pattern matching" and "seamless integration") are to be regarded as non-technical.

3.7 Problem to be solved

3.7.1 According to G 1/19 (Reasons 121) models and algorithms first of all define (non-technical) constraints to be considered in the context of the COMVIK approach (see T 641/00 Headnote 2; Case Law of the Boards of Appeal, 10**(th) Edition, Sections I.D.9.2.1 to 9.2.8). Depending on whether they contribute to any technical effect achieved by the claimed invention, they may or may not in fact be taken into account in the inventive step assessment. Consequently, when a claim refers to an aim to be achieved in a non-technical field, this aim may legitimately appear in the formulation of the problem as part of the framework of the technical problem to be solved, in particular as a constraint that has to be met.

3.7.2 Claim 1 differs from D1 in features (E) to (O) and a part of feature (P) (these features corresponding to steps (a) to (f)). These features largely comprise the steps of an algorithm for insurance coverage and payment, which is non-technical and which cannot itself contribute to inventive step, but may appear in the formulation of the problem.

3.7.3 The technical problem of the invention may therefore be considered the technical implementation of this business algorithm, i.e. the technical problem to be solved is to implement features (a) to (f) in D1's automated system to automate the payment of insurance premiums.

3.8 Obviousness

3.8.1 The Appellant argued that the underlying physical/natural events as well as the combination of "splitting", "seamless integration" and "pattern matching" were inventive in the absence of corresponding prior art. They led to the technical effect that the non-parameterizable part could be automated, which was generally only possible for parameterizable claims. This extension made extrapolation for future damage cases technically possible. This software solution could only be created by a technically skilled person who, however, had no incentive to do so. The cited prior art did not provide a useful technical teaching for this solution.

3.8.2 The Board accepts that the losses to be paid for by insurance are usually caused by physical events or are in relation to technical accidents (as is the case in cases T 288/19 and T 524/19 from the same Applicant). However, firstly, this is not claimed. Instead, a purely abstract, economic language is used throughout the application and no reference to any specific technical feature or physical parameters can be found therein. Secondly, the claimed system does not only include embodiments where a loss is triggered by material events, such as weather conditions, but also covers embodiments in which a loss is triggered by purely economic factors, such as a fall in commodity prices. The further aspects of features (a) to (f) above thereby relate exclusively to economic considerations in the framework of a purely economic model defined by, for example, an insurance expert or economist (cf. T 0848/15 (reasons 3.2)). The only problems mentioned in the application concern risk sharing and insurance payments per se and are not related to any technical issue that would arise from the use of a computer.

3.8.3 From the point of view of the person skilled in the art, i.e. a business software developer, the task of implementing commercial features on a distributed information system is per se a normal and obvious task. Thus, the claimed technical solution does not go beyond the concept of a mere automation of constraints imposed by the business related aspects. Such automation using conventional hardware and programming methods is considered obvious to the skilled person.

3.8.4 As no technical problems derive from said non-technical aims nor any corresponding technical solutions are set out convincingly, it must be assumed that for the person skilled in the art implementing said non-technical aims on a conventional distributed information system is obvious. For example, a "resource-pooling system" may be merely a conventional server comprising databases for managing electronic payments and modules for executing the business logic (i.e., financial and risk sharing related functionality) defined by the above method steps. Furthermore, to divide the risk into a parameterizable and a non-parameterizable part relates in view of the wording used in claim 1 directly to the covering of a risk by different financial contributions (description page 6, lines 20-28, page 11, lines 20-26).

3.8.5 Also, "triggering a loss" is interpreted in the sense that, e.g., after a natural catastrophe, payments to risk exposure components are triggered. In its most general form, to trigger something means to cause an event or situation to happen, in the present case to transfer payments from the resource-pooling system to the policy holders.

3.8.6 To summarise, all above mentioned features relate to the task of implementing commercial features on a distributed information system which for a person skilled in the art is per se a normal and obvious task. The only contribution to the prior art (D1) is the claimed method for risk sharing, which is not taken into account for assessing inventive step. In accordance with established case law said method does not need to be evidenced nor hinted at by further prior art evidence.

3.9 Accordingly, the subject-matter of claim 1 according to Annex A does not involve an inventive step over document D1 in combination with the common general knowledge of the skilled person.

Order

For these reasons it is decided that:

The appeal is dismissed.

No comments:

Post a Comment

Do not use hyperlinks in comment text or user name. Comments are welcome, even though they are strictly moderated (no politics). Moderation can take some time.