T 2401/13 (Pop-up window/PHILIPS) 13-10-2016

Reasons for the Decision

1. CLAIM 1 OF AUXILIARY REQUEST

Given that claim 1 of the auxiliary request has more limiting features than claim 1 of the present main request, the board considers it expedient to discuss its patentability first.

1.1 Novelty and inventive step

1.1.1 The board concurs with the examining division that document D3 may be regarded as a suitable starting point for the assessment of novelty and inventive step, and finds that it discloses the following limiting features of present claim 1 (based on the labelling of the board):

A) Bedside patient monitor ("monitoring system at each ICU bedside"; see paragraph [0214] in conjunction with Figs. 9 and 12) comprising

B) a first interface for manual patient-related input (see e.g. paragraph [0213], second and third sentences: "A local work station 280 ... which allows data to be input ... provides for ... patient orders ...");

C) a second interface ("vital sign monitoring system 450"; see Fig. 12) for continuous input of sensor signals (see e.g. paragraph [0214], second sentence: "The monitoring system at each ICU bedside comprises a monitoring system for monitoring the vital signs for the patient"; paragraph [0225], second sentence: "The smart alarm system constantly monitors physiologic data (collected once per minute from the bedside monitors) ...");

D) a clinician support system ("workstation 280"; see e.g. paragraph [0045] in conjunction with Fig. 10) comprising

D1) at least one disease-specific module (e.g.

"resident database 524"; "Apache II score assignment manager 538"; see e.g. paragraph [0219] in conjunction with Fig. 15);

D2) an information delivery tool ("patient information front end 228") to deliver requested information requested by at least one of the disease-specific modules (see e.g. paragraph [0203], last sentence: "... each ICU has a patient information front end 228, which receives information concerning ... characteristics of the patient" in conjunction with Figs. 9 and 15).

1.1.2 Distinguishing features

As to feature A), the appellant argued that the workstation of D3 was not a "bedside monitor" but an entirely separate unit. The board notes that workstation 280 used e.g. by an "intensivist" of the clinic may well be located at the patient's bedside, i.e. in the Intensive Care Unit, ICU (see e.g. paragraphs [0045] and [0046]) and that it is, along with its interface for manual input, an integral part of the monitoring system at each ICU bedside 204 (see e.g. Figs. 10 and 11).

As to feature D2), the appellant submitted that the system of D3 did not comprise an information delivery tool to deliver information requested by any disease-specific module. In this regard, it is apparent to the board that D3 consistently teaches that the "patient information front end 228" receives patient data requested by the system and its constituent modules (see e.g. paragraph [0203], last sentence in conjunction with paragraph [0219], seventh sentence: "The system also requests information for operative data 528 ..., vital sign data 530, request for laboratory information 532, past medical history for the patient 534 and patient demographics 536").

Hence, the board concludes that the subject-matter of claim 1 differs from the disclosure of D3 in that the information delivery tool is further configured to

(a) transmit a request for the requested information to a connected remote source in case the requested information is not delivered by the second interface;

(b) generate a pop-up window to trigger manual input through the first interface if the requested information is not available through the second interface or is not delivered by the connected remote source in response to the request transmitted to the connected remote source.

Consequently, the subject-matter of present claim 1 is found to be novel over D3 (Article 54 EPC 1973). The board also notes that features (a) and (b) are supported, for example, by page 2, line 25 to page 3, line 11 of the application as originally filed, and thus comply with Article 123(2) EPC.

1.1.3 Objective technical problem

The appellant submitted in the written and oral proceedings that distinguishing features (a) and (b) had the technical effect that - after the available "electronic sources" were scanned one after the other - the requested information was eventually entered by the user, so that the manual input was chosen as a "backup source".

The board, however, is not convinced that such technical effect matches with the wording of present claim 1. Rather, feature (b) solely indicates that any manual input whatsoever is triggered by the pop-up window generated. It does not indicate at all that the requested information is necessarily to be manually entered by the user. Thus, the alleged technical effect cannot be derived from claim 1. At best, features (a) and (b) could be taken to specify that the user is, firstly, alerted by way of the pop-up window to the fact that requested information is not available through the electronic sources (i.e. via the second interface receiving sensor signals or a connected remote source), and is, secondly, invited to provide some manual input (e.g. his/her credentials, password, user settings, further instructions, etc.) in that particular case.

As a consequence, the appellant's assertion that the "decision support algorithm" (according to paragraphs [0234] to [238]) and the "Apache II score assignment manager" (according to paragraph [0219]) of D3 did not require the input of patient-related data must also fail. Moreover, a formulation of the objective problem to be solved such as "how to achieve more flexibility in using existing information sources to provide the requested information to a

disease-specific module", as was put forward by the appellant at the oral proceedings before the board, cannot be accepted since it would not be credibly solved by present claim 1 based on distinguishing features (a) and (b).

Furthermore, the appellant conceded at the oral proceedings before the board that features (a) and (b) define a certain hierarchy of information retrieval but submitted that this hierarchy was not decisive for the invention. Rather, according to the appellant, the order of scanning the information sources available was inventive over D3.

The board, however, holds that the kind of hierarchical scanning of data according to features (a) and (b) is rather the mere result of an administrative rule, which may be worded, for example, as follows:

"In the first place, rely (i) on medical data retrieved from patient sensors, then (ii) on medical data retrieved from a remote server, and, as a last resort, (iii) on any data input by a user."

Such a rule would most likely be established by an administrator, such as the head of the clinic, rather than by an engineer, and is therefore to be regarded as a non-technical constraint to be met within the meaning of T 641/00 (Headnote 2). Consequently, the board finds that the objective problem may legitimately be formulated as "how to adapt the implementation of the medical system of D3 in order to enforce the above administrative rule".

1.1.4 Obviousness of claim 1

As regards feature (a), the skilled person would be aware from his common general knowledge that, to obtain the information required from electronic sources like sensors and remote servers, electronic messages such as "requests" have to be sent to those sources, which then may trigger some electronic messages in reply thereto (i.e. "responses") containing the requested data if available.

Concerning feature (b), it is apparent to the board that D3 teaches explicitly that manual input of medical data by the user (intensivist) is enabled in the system of D3 (see e.g. paragraphs [0218] and [0234] to [0238], in conjunction with Figs. 21A and 21B). It also states that medical data such as "positive blood cultures" are to be provided to the corresponding user interface to the extent that they are available (see e.g. paragraph [0224]). As to the sequence of operation, D3 further emphasises that its teaching can be implemented "all at once or in stages" (see paragraph [0021], first sentence).

Thus, the board holds that the skilled person in the field of medical data networks, starting out from the teaching of D3 and confronted with the above-identified objective problem, would readily take up those hints and implement the underlying administrative rule, without exercising inventive skills. The board also notes in passing that, even if feature (b) specified that the kind of information entered manually was indeed the requested patient-related data, the skilled person would come up with a solution according to claim 1 in order to ensure that medically sensitive patient data can still be retrieved in the event that no automatic detection is possible for whatever reason.

1.2 In conclusion, the auxiliary request is not allowable under Article 56 EPC 1973.

2. CLAIM 1 OF MAIN REQUEST

Claim 1 of this request is identical to claim 1 of the main request underlying the appealed decision.

2.1 Inventive step

Since claim 1 of the main request has fewer limiting features (in particular, it lacks feature (a)) and thus is broader in scope than claim 1 of the present auxiliary request, the board must self-evidently conclude that a fortiori its subject-matter does not involve an inventive step (in accordance with the appealed decision, Reasons 1), based on the observations on the auxiliary request set out in point 1.1 above.

2.2 Hence, the main request is likewise not allowable under Article 56 EPC 1973.