T 0288/19 (notional business person) 17-02-2022

1. The invention as claimed

1.1 The volcano activities in Iceland 2010 and the subsequent closure of airspace led to an estimated loss of 1.7 billion dollars for the airline industry. Between 15 and 21 April 2010 almost the entire European airspace was closed resulting in cancellation of all flights in, to and from Europe. The invention relates to dealing with such airport closures and flight plan changes related to natural disaster events.

1.2 When aircraft are grounded for more than ten days, airline companies may no longer be able to pay the operating resources (kerosene, salaries, maintenance etc.) due to lack of revenues. It is an aim of the invention to reduce the risk that airline companies go bankrupt due to lack of cash for operation during or after natural disaster events. The airlines seek risk transfer by means of insurance technology to cover such unforeseeable events and to ensure operation of the aircraft fleets. The related technology should be able to cover risk events such as 1) strikes, riots etc.; 2) war, hijacking, terror; 3) pandemic-based risks; 4) extreme weather situations; 5) instabilities in Air Traffic Control (ATC). However, the covers are technically difficult to design because no standards e.g. for critical ash concentrations exist. It is an object of the invention to provide an automated system preventing imminent grounding of aircraft fleets due to missing financial resources after risk events and to provide a systematic and automated management of risk exposure.

1.3 The invention proposes automatically paying financial compensation to the affected business units, i.e. airlines and their fleets, by monitoring relevant airport data, defining critical thresholds and automating cover payments in case of airport closures.

2. Admission of the Requests

Annex A and B (on which the new Main, First and Second Auxiliary Requests are based) were filed in reply to objections under Articles 56, 83, 84 and 123(2) EPC introduced by the Board for the first time in its communication under Article 15(1) RPBA 2020. The Board therefore decided to admit these requests into the proceedings under Article 13(2) RPBA 2020.

3. Inventive step - Annex A (Main Request)

3.1 Closest prior art

D1 is chosen as closest prior art because it has the most technical features in common with claim 1. It discloses detection of airport closures and the use of a stack memory for risk evaluation. D3 discloses an emergency system based on ACRAS (Airborne Call and Recording System) and also deals with risk management and automated emergency procedures for aircraft. D11 is a Wikipedia article about hash tables.

3.2 D1

3.2.1 D1 discloses an automated system for a fleet of aircraft (40, 41, 42). The system comprises sensors (3, 411, 601) both in the aircraft and in the ground station (81) for measuring parameters relevant for geophysical disasters, e.g. sensors for wind speed, satellite images, water level sensors, water and wind temperature sensors etc. The system activates an emergency procedure in an aircraft when certain conditions are met (claim 1). Such a condition may be the event of reaching a threshold in an incremental stack memory. The stack memory stores critical weather and flight-specific data for defined time intervals (page 6, right-hand column, last but ninth line). In addition, ATIS (Automatic Terminal Information Service) data comprising relevant airport information is stored in the stack (claim 30). The likelihood for a risk exposure to the aircraft fleet is therefore defined by the threshold. The threshold is dynamically adapted ([0012]).

FORMULA/TABLE/GRAPHICD1

3.2.2 Furthermore, D1 discloses evaluating the probability of malfunction ([0012]) and calculation of [insurance] tariffs (page 3, right-hand column, center part: "the aviation system, for the first time, allows full automation of the additional tariff setting of the operating malfunction at all stages"; Swiss Reinsurance is Applicant for D1, therefore insurance tariffs are meant). These calculations are performed in a central processing unit (81) comprising an assembly module for evaluating the risk (101-103). Under point 6.2.4 of the Board's communication under Article 15(1) RPBA 2020, it was stated, and not disputed by the Appellant, that the ATIS message would comprise essential airport information including the information about the closure of parts of the airport (runways) or the entire airport. Therefore airport closures are taken into account for the risk evaluation and data relating to airport closures are saved in the central computer of earth station 81 (see D1, paragraphs [0024], [0014] and claim 30)).

3.2.3 Using the wording of claim 1, but referring to D1, D1 therefore discloses an

(A) avionic system (Fig. 1, 1-601) for emergency interception preventing imminent grounding or damages of aircraft fleets (40,41,42) [deleted: following] due to natural disaster events by preventing damage [deleted: providing] [deleted: interruption cover] of the aircraft fleets by means of an automated [deleted: damage covering] system, the natural disaster events leading to airport closings and being measurable at least based on atmospheric conditions and/or meteorological conditions and/or seismic conditions (cf. sensors 401, 3, 601), and the automated [deleted: damage covering] system being steered by a generated output or activation signal of the avionic system (emergency signal, when a threshold in stack 101 is reached), comprising

(B)[deleted: a selectable hash table assigned to a flight plan of an aircraft fleet comprising table elements with operational parameters of an airport, wherein airports covered by the table elements are airports flown to according the fight plan of pooled aircraft fleet],

(C) a plurality of ground stations (81) situated at said flown to airports [deleted: of the fight plan], wherein the ground stations (81) are linked via a communication network (50, 51, 111) to a central processing unit (2, 81) of the avionic system (1),

(D) wherein for detecting an airport closing, an electronic detection device (device 3 detecting airport closures, e.g. related to wind strengths/directions exceeding threshold levels) is integrated into the ground stations,

(E) wherein the central processing unit (2, 81) comprises a receiver (FORMULA/TABLE/GRAPHIC) for receiving transmissions from the detection device via a communication network and a communication network interface,

(F) wherein the transmissions comprise measured log parameter vales (data from sensors 401, 411) of the aircraft fleet

(G) at the moment situated at a specific airport (output of landing/take-off sensors 411) and

(H) parameters regarding a time interval parameter (time window of the stack memories) of an airport closing and an airport identification (ATIS frequency, airport code) of an identification module of the ground station containing the authentication data relevant for authenticating the related detection device,

(I) wherein the time interval parameters are saved to the operational parameter of the appropriate [deleted: table] element based on the airport identification (the base station has access to all ATIS data of all airports),

(J) wherein airport closings are automatically detected by the avionic system by means of the transmission of the detection device (transmission of ATIS data via radio communication, Internet, fax etc.),

(K) and wherein the avionic system comprises triggers triggering measuring parameters of the natural disaster events (via sensors 3, 401, 601)

(L) comprising event strength values (e.g. wind strengths) by defined trigger thresholds values (e.g. thresholds for closing airport runways of the entire airport) providing adaptable border conditions for the natural disaster events,

(M) a filter module (2) of said central processing unit (2) dynamically incrementing a stack (101) with the transmitted time interval parameters [deleted: based on the hash table]

(N) and activating a failure deployment device (603) by means of the filter module (2) if a threshold, triggered on the incremented stack value, is reached, (O) thereby automatically generating an output signal (602) to the automated activatable [deleted: damage covering ]system operated or steered by the output signal to provide interruption [deleted: cover] of the aircraft fleet for at least a part of said time interval of said airport closing by means of an automated [deleted: damage covering ]system,

(P) said output signal being automated generated by means of the avionic system for a dynamically scalable [deleted: damage covering] risk of the aircraft fleet with an definable upper [deleted: coverage] limit (threshold triggering emergency procedure),

(Q) and wherein said output signal is only generated, if said transmission comprises a definable minimum number of events [deleted: airport identifications assigned to airport closings thus creating an implicit geographic spread of the closed airports of the flight plan], and in that

(R) the automated [deleted: damage covering] system is realized by means of an automated [deleted: resource-pooling] system integrated to the avionic system,

(S) the [deleted: resource-pooling] system comprising at least an assembly module to process risk related aircraft fleet data (evaluating probability of damage) and to provide the likelihood value for said risk exposure a pooled aircraft fleet based on the risk related aircraft fleet data (sensor data, stack memory data),

(T) wherein the aircraft fleets are connected to the automated [deleted: resource pooling] system [deleted: by means of a plurality of payment receiving modules configured to receive and store payments from the pooled aircraft fleets for the pooling of their risks and]

(U) wherein the [deleted: payments] insurance tariffs are automated scaled based on the likelihood value of said risk exposure of a specific aircraft fleet, and

(V) wherein by means of the automated [deleted: resource-pooling] system flight interruption risks for of a variable number of aircraft fleets and/or aircraft operators is [deleted: sharable] preventable by providing a self-sufficient risk protection for a risk exposure of the aircraft fleets and/or aircraft operators by means of the automated [deleted: resource-pooling] system.

3.2.4 The Appellant argued that the detection devices of document D1 were integrated into the avionics of the aircraft and that this was in contrast to the electronic detection device of claim 1 of the present invention. The activation parameters of document D1 were either determined by means of a filter module on the basis of the detected number of take off and/or landing units or were generated by the avionics of the aircraft. In contrast to document D1, the time interval parameter of claim l of the Main Request was related to an airport closing and the triggers were located close to an airport.

3.2.5 The Board however is of the opinion that D1 clearly discloses that the detection devices can be implemented as part of a monitoring system of a land base, e.g. an airport (see page 3, bottom of left-hand column, passage starting: "However, the land bases can ..."), and that the detection device can include "sensors and/or detection means for dynamic detection of land-base-specific data of the assigned landing/take-off base" (see D1, paragraph [0024], passage starting: "The detection device 411 can also include ..."). Thus conditions at or close to the airport would be monitored by the detection devices and the resulting signal would then be fed to a computer to generate the automated ATIS message (see D1, paragraph [0024], passage starting: "Also, by means of the avionics 402 ...").

3.2.6 ATIS data comprises weather data close to the airport and information about airport closure. The ATIS message prevents approaching aircraft from initiating the landing procedure in case of airport closure. The event tracker in the stack (101) evaluates the ATIS data. The stack memory therefore comprises information about both airport closures and weather conditions measured close to the airport. It is therefore implicit that the time interval parameter ("relevant time window" in D1) relates inter alia to airport closures. The stack and the computer module 2 triggering the emergency procedure are not located in the aircraft, but in the ground station 81. D1 therefore discloses trigger thresholds of the measuring parameters of natural catastrophes located close to the airport.

3.2.7 Therefore D1 does not explicitly disclose

(a) flight plan data is presented as a hash table.

(b) a threshold which is linked to a minimum number of airport identifications assigned to airport closures thus creating an implicit geographic spread of the closed airports of the flight plan.

(c) the geographic spread is associated with geophysical disaster events.

(d) damage covering is performed with a definable upper coverage limit, instead of simple damage prevention.

(e) automated payments are scaled payments and are based on the likelihood of said risk exposure.

(f) flight interruption risks are shared by providing a self-sufficient risk protection.

3.3 Effects

3.3.1 Features (d) to (f) as such and disconnected from the (technical) automated system are related to a business method. Features (a) to (c) are technical. The application does not disclose for which reason the flight plan data is hashed (feature (a), part 2). A hash table appears to be advantageous for database indexing and improved retrieval of data.

3.3.2 Effects and technical/non-technical character of the features:

(i) features (a) [part 1, considering the flight plan], (b) and (c) [creating an implicit geographic spread of the closed airports in case of a natural disaster] are related to preventing further financial damage. The character of these features is technical, the purpose is non-technical.

(ii) hashing the flight plan data has the technical effect of improved data base indexing. Both the character and effect of feature (a), part 2, are technical.

(iii) features (d) to (f) are related to a shared insurance cover system including managing the payments; the character and effect of these features as such are non-technical.

3.3.3 To summarise, the subject of the present invention (the "what") is an automated system for dealing with technical/financial damage of an aircraft fleet and is without any doubt technical. The purpose (the "why") of the present invention however is the automation of a business scheme for providing monetary cover for financial damage to aircraft fleets based on available information, including flight plans and information about airport closures and natural events, i.e. a managerial system for managing the business operations of aircraft fleets including involved operational and financial risks, including covering financial losses of airlines caused by the situation of airport closures resulting from natural disaster. This purpose is non-technical and relates to a business method. The solution (the "how") with respect to the disclosure of D1 is both technical (adaptation of the software) and non-technical (implementation of the business model). Therefore, the overall character and effect of claim 1 is technical.

3.3.4 Non-technical features within the meaning of Article 52(2)(c) EPC, i.e. features related to business methods, are allowed in the context of other technical features, but cannot contribute to inventive step. These features can thus be included into the formulation of the task (see, inter alia, G 1/19 [reasons 31], T 0641/00, G 3/08, Case Law of the Boards of Appeal, 9th edition 2019, sections I.D.9.1.2 to I.D.9.1.4). According to T 0641/00, the aim to be achieved in a non-technical field may legitimately appear in the formulation of the problem as part of the framework of the technical problem. Therefore, the non-technical features (O) to (V) ("damage cover" and "automated payment") can be included into the task formulation as a framework condition to be fulfilled.

3.3.5 Furthermore, the application as a whole is silent on the technical details of the sensors or detection devices needed, and on exactly what physical properties are measured and how from those measurements the situation of a natural disaster or an airport closure can be determined. The effect of features (i) to (iii) is therefore limited to the broad formulation of the corresponding features in claim 1.

3.4 The skilled person

3.4.1 The Appellant argued that the skilled person is a business person. In T 1463/11, the Board introduced the concept of the notional business person to help separate business considerations and technical considerations. The business person might formulate business requirements but would not include any technical matter. This approach ensured that, in line with the COMVIK approach, all the technical matter, including known or even notorious matter, could contribute to inventive step and was therefore considered for obviousness.

3.4.2 The Board agrees that the business person defines the business framework conditions for the system:

(a) The business person defines the insurance conditions. Depending on these conditions specific geophysical events (volcano ash, riots, hurricanes, strikes etc.) are covered (or not).

(b) It has further to be defined in the insurance conditions which airports/specific regions, which specific time interval and/or which specific types of event are to be taken into account, e.g. only Eurasian and American airport closures may be taken into account for a minimum of seven consecutive days of closure, financial damage due to strike within the airline company and closures for less than seven days may not be taken into account etc.

(c) Another implicit condition is that only groundings of scheduled aircraft (i.e. according to a flight plan) are considered.

3.4.3 In the present case the skilled person solving the objective technical problem however is not the "notional business person", but a computer specialist, because the solution of the problem concerns principally re-programming the central CPU (e.g. of the ground station 81). The business person however provides the framework and object of the invention. This is very frequently the case for technical inventions, e.g. a business person may instruct an engineer to design a double-deck aircraft for up to 850 passengers with a budget of 10 billion dollars. The solution to this object can only be provided by a technically skilled person. In the present case the notional business person (e.g. insurance company in cooperation with the airline companies concerned) instructs a computer specialist with the implementation of an automated system. Their task is to adapt the software in module 81 of D1 (cf. also T 2522/16, reasons 3.2.1, T 0589/17, reasons 2.6, T 0755/18, reasons 3.5).

3.4.4 The Appellant argued that the skilled person needed to have specific knowledge in aircraft communication systems and aircraft security. The Board however concludes that such specific knowledge is not necessary because all raw data required for solving the problem is available on the computer base station 81 of D1. The modified software has only to provide a link between airport closure data and automated payments.

3.5 Problem

3.5.1 The Appellant has formulated the technical problem during the oral proceedings as "if airports are closed we cover the financial damage: how can we trigger the payouts quickly and automatically".

3.5.2 The Board therefore formulates the objective technical problem with D1 as starting point as "technically implementing an automated management of financial risk exposure of scheduled flights due to airport closures, including implementing the claimed non-technical features (O) to (V)".

3.6 Obviousness

ad (i)

3.6.1 The technically skilled person would therefore consider analysing whether airports were closed and whether such closures were linked to geophysical events covered by the insurance policy. They would then adapt the threshold defined in D1 to a specific number of airport closures within the given time window as defined in the insurance policy.

3.6.2 In order to deal with the technical and financial consequences of airport closures it is obvious to the skilled person to consider the concerned airports and flight plan routes to and from the closed airports. In view of the objective technical problem to be solved it would be a normal option to monitor which flight plan connection (and therefore which fleets and airlines) are concerned by the closure of specific airports and air-spaces. Furthermore, the emergency system of D3 teaches ([0084]) to take flight plan data into account. The skilled person would therefore adapt the software architecture of D1 and correlate the airport closure events with the flight plan data.

ad (ii)

3.6.3 In order to improve the data base indexing of the flight plan table the skilled person would choose the common option of providing the flight plan data in a hash table. D11 teaches the use of hash tables.

ad (iii)

3.6.4 Features (O) to (V) directly result from the problem to be solved.

3.6.5 The Appellant argued that D1 had a different purpose, i.e. preventing emergency situations of particular aircraft. D1 disclosed a plurality of parameters to be monitored and to be taken into account for risk calculation. Since in the present case the skilled person was a business person, they were not able to

(a) select between the plurality of physical parameters the parameter of airport closures;

(b) to implement feature (Q), i.e. creating a geographic spread of the closed airports of the flight plan;

(c) to create a robust, effective and reliable software implementation making the link between the spread of closed airports and the automated payment of insurance cover premiums. This implementation comprised complex insurance algorithms.

In addition the Examining Division had neither provided a document teaching the creation of said spread of closed airports nor a document teaching the automation of damage cover payments by means of a computer system and without an intermediate agent.

3.6.6 According to T 2079/10 the skilled business person was not able to select relevant physical parameters. In T 2079/10 the Board held (reasons 4.2 and 4.3):

It cannot be assumed that a technical specialist will first determine a physical output variable, on the basis of which it will then be instructed by the businessman to implement the concept of a purely abstract business process. This procedure also does not correspond to the COMVIK approach (T0641/00) applied according to current case law. On the other hand, it cannot be assumed that a businessman specifies technical features, such as physical measurement parameters in the present case, as part of a purely administrative business process. Otherwise, technical features contributing to technical character would be excluded from the assessment of inventive step (see also T1463/11 CardinalCommerce, point 16). According to current case law, the objective technical problem has to be free of solution features of the claimed subject matter. Claim features may only be part of the problem if such features themselves do not contribute to the technical character and are therefore not part of the technical solution (see T0641/00 COMVIK).

3.6.7 However, the Board is of the opinion that T 2079/10 relates to the control of an alarm system and to dynamically adapt alarm threshold parameters of a memory stack similar to the system described in D1. Business considerations play a role, if any, only after selection of the physical parameters (cf. also T 1632/18, reasons 2.8). The present case is not comparable. Whether or not an airport is closed cannot be considered to be a "physical measurement parameter" in the sense meant in T 2079/10; it is rather a business consideration with which the business person in the field of aviation or aviation insurance would be fully familiar. The decision to pay compensation automatically in the case of such closures, including making payment dependent on the number of closures and the geographical spread of, and reasons for, such closures, would be entirely a matter for the business person in the field of insurance. Only the technical implementation would be delegated to the skilled programmer.

3.6.8 The present application involves the automated payment of insurance premiums based on a minimum number of airport closures, according to a geographical spread. The insurance policies would define this business framework. The skilled person has to provide the technical implementation, i.e. software analysing airport closure data according to the insurance conditions, e.g. location of the closed airports, time span of airport closure, reasons for the closure etc. The business model boundary conditions (insurance conditions) therefore directly require the analysis of parameters related to number, location, time window and relevance of the airport closures. It is therefore inherent to the problem to be solved (i.e. the business constraints to be met) that airport closures, flight plan data and the geographic spread of the closed airports (Feature (Q)) must be taken into account in the technical implementation.

3.6.9 Although D1 has primarily a different purpose with respect to the present invention, it provides teachings for all the technical features of the proposed solution except using hash tables for data storage and creating a geographical spread. As discussed above, these features are however obvious in the given context. Applying the technical infrastructure disclosed in D1 for a different purpose, i.e. automated premium payouts, is directly suggested by the problem to be solved, in particular the non-technical constraints to be met. In addition, the Board considers automatically adapting insurance tariffs (as suggested in D1) - and therefore indirectly adapting insurance premiums - and automatically paying out insurance premiums not as being remote from each other. Furthermore, insurance algorithms and details about how the parameters are treated are neither part of the scope of the claim nor disclosed in the description.

3.6.10 To summarise, the business person sets the framework of the problem to be solved by their business model (insurance conditions) and thus reduces - by setting specific boundary conditions - the degrees of freedom of the skilled computer specialist. The technically skilled person, who has to solve the objective technical problem of implementation, therefore has no latitude in selecting the corresponding (physical) parameters. Working out the specific implementation of the features follows in a straightforward manner from the teaching of D1 and from the problem to be solved.

3.6.11 Consequently, claim 1 of Annex A does not involve an inventive step over the disclosure of document D1 and the common general knowledge of the person skilled in the art. As a result, neither the Main Request nor the First Auxiliary Request can be allowed.

4. Second Auxiliary Request

The subject-matter of claim 1 of Annex B is a subset of the features of claim 1 of Annex A. Consequently, since the subject-matter of claim 1 of Annex A is not allowable under Article 56 EPC, for the same reasons also the second Auxiliary Request (Annex B) is not allowable.