T 1000/09 (Vehicle monitoring/BOEING) of 18.11.2014

Summary of Facts and Submissions

I. This appeal is against the decision of the examining division to refuse European patent application No. 04075212.3, "Vehicle monitoring and reporting system and method", published as

A2: EP-A2-1 445 721,

for lack of inventive step (Article 56 EPC 1973) over

D1: US-A1-2002/0065698, "System and method for managing a fleet of remote assets".

II. In the statement setting out the grounds of appeal, the appellant requested that the refusal decision be set aside and that a patent be granted on the basis of the claim set refused by the examining division, i.e. claims 1 to 20 received on 4 August 2008.

The arguments submitted in the statement of grounds can be summarised as follows.

- The claimed monitoring system acts as a filter by not alerting a user to events that do not reach a predetermined probability of vehicle failure. The system, thus, minimises the risk of a maintenance worker being flooded with unnecessary maintenance data, thereby allowing the worker to concentrate and develop a maintenance schedule on areas that require attention.

- By assigning one of three user-defined statuses to the data, the data not filtered out by the system may be processed more quickly.

- D1 provides a system that allows users to filter data based on their selection of web pages, whereas the present application provides a system that filters the data based on a user preference.

- D1 does not disclose assigning, and displaying, one of three user-defined data statuses based upon the probability of vehicle failure. While D1 (paragraph 0028) describes the use of a colour to indicate a readiness status, this is for a different purpose.

III. The Board appointed oral proceedings, as requested on an auxiliary basis, and expressed its preliminary opinion that the independent method claim (claim 12) did not specify any technical means for monitoring the operation of a vehicle and for assessing and presenting the probability of a failure of the vehicle. Regarding system claim 1, D1 seemed to represent the closest available prior art. Contributions over D1 seemed to be either non-technical (presentation of information) or obvious in view of an administrative goal (user-specific information policy, A2, paragraphs 0005/0006/0008).

IV. In response to the summons, the appellant filed an amended set of claims 1 to 20 (main request) on 24 October 2014. According to an auxiliary request the method claims, claims 12 to 20, were deleted from the claim set.

Claim 1 (common to both requests) reads:

"1. A monitoring system (10) for an air vehicle (12) comprising a plurality of components, wherein the monitoring system (10) comprises:

a data gathering element comprising an aircraft central maintenance computer or aircraft condition monitoring system (14) that receives data associated with the failure of a component of the vehicle (12) and indicative of an occurrence of an event;

a processing element (20) that determines a probability of failure of a component of the vehicle based upon the occurrence of an event and upon the passage of time following the occurrence of the event;

a customization element (16) for processing the gathered performance data including applying at least one user preference to the data, wherein the user preference comprises an alerting preference including directions to alert the user once the probability of vehicle failure after the occurrence of the event reaches a predetermined threshold, prioritization preferences and data delivery preferences; and

a display element (18) for presenting data received by said data gathering element after said customization element applies the user preference to the data."

V. In the written response to the summons, and at the ensuing oral proceedings, the appellant provided the following additional arguments.

The amended claims related specifically to a monitoring system for an air vehicle comprising an aircraft central maintenance computer or aircraft condition monitoring system. D1 related primarily to trains; the infrastructure relating to data collection and analysis for trains was not analogous to the infrastructure needed to support data collection and analysis for aircraft. A person of ordinary skill in the art would not look to train data management systems to develop an aircraft data reporting system. That view was corroborated by the opening portion of D1 (paragraph 0003) which referred to several types of surface-based vehicles (trucks, ships, railway locomotives) but did not mention aircraft.

The use of a central maintenance computer was specific to the airline industry. A central maintenance computer received raw sensor data and pre-processed it to generate event data (notably fault data). The processing element of the present invention determined a failure probability based on the occurrence of an event, whereas the system of D1 predicted failures on the basis of raw sensor data. In view of the large amount of raw data to be transmitted, the teaching of D1 was difficult to apply to aircraft.

While D1 (paragraph 0033) aimed at predicting a time to failure of a component, the system according to claim 1 was designed to calculate the probability of failure of the component at any given point in time following an event. To demonstrate the difference, the appellant pointed out that the probability of failure might even decrease over time: A specific event (such as a bird hitting an engine) might cause a great initial probability of failure but the probability might decrease once the initial phase was overcome without failure.

The present invention combined the probability calculation with a user's ability to build a custom maintenance plan by inputting preferences for what performance data was to be presented when. There was no suggestion in D1 to permit the user to customise a maintenance plan based on user-inputted preferences. In particular, D1 did not show a customisation element with the ability to set three specific user preferences regarding the presentation of failure probabilities.

Therefore, the appellant maintained its request that the decision under appeal be set aside and a patent be granted on the basis of the main request or auxiliary request filed with the letter of 24 October 2014.

Reasons for the Decision

1. The application addresses a need for a vehicle monitoring and reporting system that combines real-time vehicle performance data with specific user preferences for different types of data that may be captured by the system, such that a user may implement a maintenance plan that fits their specific business plan for their vehicles (A2, paragraph 0008).

Data associated with the operation of a vehicle is gathered, processed to determine a probability of vehicle failure, and presented to the user. The probability of failure may vary over time (A2, Figures 2 and 4A...4C).

The monitoring may be customized to take account of user preferences so that the user does not have to read and interpret all of the data to determine what type of maintenance is required. The user preferences comprise alerting preferences specifying that the user is to be alerted once the probability of vehicle failure reaches a threshold defined by the user (A2, paragraphs 0023/0024).

The user may also define statuses related to the probability of vehicle failure. The statuses may be coded and indicated by colours (e.g. green/yellow/red; Figures 4A-4C), or any other type of three-item scale indicating a low, medium, or high probability of vehicle failure. For example, if the data indicates a critical fault that needs immediate attention, the status is set to "red" (A2, paragraphs 0028 to 0033).

The data may be notified to the user using e.g. a pager, electronic mail, a terminal or any other means suitable for alerting the user in accordance with the user's preferences (A2, paragraphs 0011, 0027).

Main Request

Article 56 EPC 1973 - Inventive step

2. In the light of Article 52(1)(2)(3) EPC, Article 56 EPC 1973 requires a non-obvious technical contribution. Contributions not achieving any technical effect do not enter into the examination for an inventive step (T 641/00-Two identities/COMVIK, Headnote 1, OJ EPO 2003, 352; T 1784/06-Classification method/COMPTEL).

3. D1 represents the closest available prior art. D1 (paragraph 0033) discloses a monitoring system (110) for a vehicle comprising: a data gathering element (116) capable of receiving data associated with the operation of a vehicle ("on-board systems parameter data") and indicative of an event (e.g. a "fault"); a processing element (118) for determining whether monitored data is out of range and for predicting when a system is likely to fail upon the occurrence of a fault (paragraphs 0033, 0040...0045); and a display element (web page) for presenting at least a portion of the data received by said data gathering element (paragraphs 0028, 0029, 0031, 0046).

The classification and prioritisation of faults in D1 (paragraphs 0029, 0033, 0040...0045; Figure 5) imply an assessment of the monitored data with respect to a probability of vehicle failure (paragraph 0033: "predicting when such a system is likely to fail"; paragraph 0045: "predicts which vehicle system is likely to fail"). The system of D1 assigns a status to the data based on a probability of vehicle failure: faults are classified as "critical" and/or "restrictive" (D1, paragraph 0044). The user is alerted once the probability of vehicle failure reaches a critical threshold (paragraphs 0029, 0044, 0057). Colour coding may be used to indicate a readiness status for each vehicle displayed on an Internet web page; for example, red may indicate a vehicle having a critical fault. The user of such information is able to quickly assimilate a large volume of data and to have his/her attention directed to important portions of the data (paragraphs 0026, 0028).

4. The following contributions of claim 1 over D1 have been asserted by the appellant.

(a) Firstly, the system is designed to monitor an air vehicle and comprises an aircraft central maintenance computer which pre-processes raw sensor data into event data so that the voluminous raw data does not have to transmitted to the processing element which bases its calculations on event data.

(b) Secondly, the processing element uses the occurrence of an event to determine current and future probabilities of failure of the monitored component (rather than an estimated time to failure).

(c) Thirdly, a customisation element allows the user to set an alerting threshold, a prioritisation preference and/or a data delivery preference.

5. The Board reiterates that D1 discloses a system for monitoring a fleet of remote mobile assets such as trucks, ships and railway locomotives (D1, paragraph 0003). For obvious reasons, moving vehicles may not be able to constantly transmit voluminous sensor data from every remote location to a central monitoring station. Consequently, the system of D1 is not limited to transmitting raw sensor data: On-board pre-processing of the data may be conducted to facilitate communication of data from the vehicle to the data centre (D1, paragraph 0073; Table 8 "On-Board Data Reduction").

For those reasons, the Board is convinced that D1 would be considered by a skilled person designing a system for monitoring an air vehicle. Where necessary, he/she would adapt the monitoring scheme to specific requirements of the aircraft industry using solutions from that industry, in particular an existing on-board maintenance computer. The Board adds that claim 1 relates to aircraft monitoring only in a general way without addressing any specific requirement of aircraft.

6. D1 is not limited to using raw sensor data for assessing the reliability of components. An "event" within the meaning of present claim 1 is embodied by the occurrence of a "critical fault" or "restrictive fault" as defined in D1 (e.g. paragraph 0044). Hence, basing a failure assessment on an "event" is pre-empted by D1.

7. The appellant argues that the claimed system determines a "probability" of failure of a component whereas D1 determines its "time to failure" (D1, paragraph 0033) or "estimated time of failure" (D1, paragraph 0045). In this respect, the Board first notes that a time to failure is conceptually linked to a probability or likelihood of failure (D1, paragraph 0033: "when such system is likely to fail"; paragraph 0045: "which vehicle system is likely to fail"). This finding is consistent with the graphical user interface according to Figure 3 of the present application which also displays a "Time-to-Failure Sensitivity" (reference numeral 28; see also A2, paragraph 0032).

Above all, the failure probability information defined in claim 1 is only determined for presentation to the user, who may then decide to take technical action. The cognitive content of the presentation is not a technical feature, and it does not become technical even if it prompts the user to start a technical action (broken technical chain, T 1741/08, T 1670/07).

8. A customisation element which allows the user to set an alerting threshold, a prioritisation preference and/or a data delivery preference is not disclosed by D1.

Allowing the user to customise display criteria provides the advantage of minimising the risk of a maintenance manager being flooded with information that he/she does not need by his/her own standards. Thus, the claimed system saves time and money for the user who might otherwise have to investigate more events (A2, column 8, lines 33 to 36).

9. According to D1 (paragraph 0029), information regarding an anomaly or critical fault may be uploaded to an Internet web page, and a user may be notified by any simple form of communication (electronic mail message, telephone call, fax) that new or urgent information has been displayed on the Internet web page. The user may then actively interact with the web pages that present data regarding the vehicle of interest. Such interaction may include a request by the user for additional information. However, the system of D1 is not arranged to allow the user to define a customised threshold between an anomaly and a critical fault, for example, and D1 is silent on whether the user may choose the form of alerting communication.

10. D1 (paragraph 0028) envisages a predetermined colour code to indicate a readiness status of each vehicle. Conversely, the present application teaches a green, yellow or red status to be assigned to monitored data "in light of the user's particular requirements" (A2, paragraph 0028; Figures 4A...4C).

The general purpose of colour coding (quick overview) is the same in the prior art (D1, paragraph 0028) and in the present application (A2, paragraph 0028). It is customised colour coding that is specific to the present application.

11. On the other hand, setting user preferences for categories and ranges of data to be displayed in a convenient manner aims at a presentation of information, the latter being a priori non-technical (Article 52(2)(d) EPC), even if lowers a user's cognitive burden (T 1741/08-GUI layout/SAP). The cognitive meaning of the display data does not convey any technical character to the presentation. Effects resulting from a user-defined data presentation (according to three classes or "statuses") depend on the user's perception and/or constitute indirect technical effects (ensuing maintenance of the vehicle) and/or relate to organisational and economic aspects (maintenance plan adapted to a business plan, see A2, paragraph 0008).

12. Regarding the technical, inputting side of the man-machine interface, the desire to provide it with inputting means for controlling the data output is driven by obvious needs of users who have in practice been flooded with information meaningless to them. The resulting administrative goal of a user-specific information policy (A2, paragraphs 0005/0006/0008) suggests that the user should be provided with a means ("customisation element") for inputting his/her criteria of relevance. The technical implementation of such a customisation relies on a skilled person's general knowledge, the application leaving structural details of a functional "customisation element" to the skilled reader.

13. For completeness, the Board notes that the three groups of distinguishing features asserted by the appellant (see point 4 supra) do not entail any non-obvious working-interrelationship beyond the sum of their individual effects. The fact that the monitored vehicle is an aircraft does not provide any additional aspect over a selective output of information and a means for inputting the user's selection or preference.

14. Therefore, the Board judges that the system as defined in claim 1 does not involve any inventive step over D1 (Article 56 EPC 1973).

Auxiliary Request

15. As claim 1 is common to both requests, the auxiliary request fails on the same ground (Article 56 EPC 1973).

Order

For these reasons it is decided that:

The appeal is dismissed.