T 1392/10 () of 5.6.2014

Summary of Facts and Submissions

I. The proprietors lodged an appeal against the decision of the Opposition Division revoking European patent No. 1 395 170. The Opposition Division held, inter alia, that the then pending first auxiliary request did not fulfill the requirement of inventive step.

II. With their statement setting out the grounds of appeal, dated 24 August 2010, the proprietors requested as a main request that the patent be maintained on the basis of the claims of the first auxiliary request before the Opposition Division.

III. Respondent/opponent 1 withdrew its opposition by letter dated 25 April 2012.

IV. Oral proceedings took place on 5 June 2014.

The appellants (proprietors) requested that the decision under appeal be set aside and that the patent be maintained on the basis of the main request filed with letter dated 24 August 2010 or of the auxiliary request filed during oral proceedings.

Respondent/opponent 2 requested that the appeal be dismissed.

V. The following documents are of importance for the present decision:

D9: WO-A-00/18 449

D10: WO-A-99/18 532.

VI. Claim 1 of the main request reads as follows:

"A method for accessing a medical device (130) via a first and second computing device whereby the medical device is operably coupled to the second computing device (120), the method comprising the steps of:

the first computing device (110) comprising a storage device, a memory, a network interface, and a processor, the processor being operably coupled to the storage device, the memory and the network interface;

the storage device comprising a plurality of protocol components that configure the second computing device to communicate with a plurality of medical devices in accordance with communication protocols supported by the plurality of medical devices;

the memory comprising a plurality of instructions;

the network interface being adapted to communicate with the second computing device via a network;

the processor being adapted to cause receiving identification information that is indicative of a medical device type from the second computing device (120) via the network interface;

the processor causing to transfer a protocol component from the first computing device (110) to the second computing device (120) via the network interface based upon the identification information; and

the processor further being adapted to execute the plurality of instructions to cause said processor to receive measurement data from the medical device (130) via the network interface in response to the second computing device (120) communicating with the medical device (130) via the protocol component comprising the steps of:

the first computing device receiving authentication information from the second computing device;

the first computing device associating the measurement data received from the medical device with previously received measurement data associated with the authentication information;

the first computing device analyzing the measurement data and the previously received measurement data associated with the authentication information to obtain results data; and

providing the second computing device with the results data."

VII. Claim 1 of the auxiliary request reads as follows (amendments with respect to claim 1 of the main request are highlighted by the Board):

"A method for accessing a medical device (130) via a first and second computing device whereby the medical device is operably coupled to the second computing device (120), the method comprising the steps of:

the first computing device (110) comprising a storage device, a memory, a network interface, and a processor, the processor being operably coupled to the storage device, the memory and the network interface;

the storage device comprising a plurality of protocol components that configure the second computing device to communicate with a plurality of medical devices in accordance with communication protocols supported by the plurality of medical devices;

the memory comprising a plurality of instructions;

the network interface being adapted to communicate with the second computing device via a network;

the processor [deleted: being adapted to cause] causing receiving identification information that is indicative of a medical device type from the second computing device (120) via the network interface;

the processor causing to transfer a protocol component from the first computing device (110) to the second computing device (120) via the network interface based upon the identification information; and

the processor further being adapted to execute the plurality of instructions to cause said processor to receive measurement data from the medical device (130) via the network interface in response to the second computing device (120) communicating with the medical device (130) via the protocol component comprising the steps of:

the first computing device receiving authentication information from the second computing device;

the first computing device associating the measurement data received from the medical device with previously received measurement data associated with the authentication information;

the first computing device analyzing the measurement data and the previously received measurement data associated with the authentication information to obtain results data; and

providing the second computing device with the results data."

VIII. The arguments of the appellants relevant for the present decision are summarised as follows.

(i) Main request

1.1 The method of claim 1 differed from D9 in the following features: (i) the storage device (of the first computing device) comprising a plurality of protocol components that configure the second computing device to communicate with a plurality of medical devices in accordance with communication protocols supported by the plurality of medical devices; (ii) the processor (of the first computing device) causing to transfer a protocol component from the first computing device to the second computing device via the network interface based upon the identification information (received by the processor which is indicative of the medical device type); (iii) providing the second computing device with the results data.

Moreover, in D9, the server, or PC 14, was not disclosed as having a network interface adapted to communicate with the communication station 10. In particular, D9 did not disclose that a remote computer PC 14 reported results data to the communication station 10. Moreover, PC 14 of D9 did not ensure proper device/client communications by causing the transfer of communication protocols based on device identification information (feature (ii)). In other words, the server did not actively use the device identification information in the process of causing the protocol transfer. The communication protocols disclosed in D9 (page 10, lines 22 to 26) were either stored in firmware on the communication station 10, manually downloaded to the communication station 10 from a CD or the like (not transferred by PC 14 based on device identification information received from communication station 10), or programmed into the communication station 10 by PC 14 when operating in PC Controlled Mode (page 39, line 20 et seq.). There was no disclosure in D9 of a server that controlled device/client communications by causing the transfer of protocols, let alone a server that caused such protocol transfers based on device identification information from the client. The fact that numerous commands had to be selected by the user (page 39, line 24 et seq.) taught away from further automation.

The passage on page 40, lines 14 to 18 in D9 referred to a second embodiment of a communication station 500 which was a separate embodiment from that of the previously described communication station 10. For this second embodiment, the user had to manually select the device to be communicated with. Hence, the protocol transfers were not based on device identification information from the client.

Features (i) and (ii) related to the objective problem of ensuring proper client/device communications without requiring interaction with the user. Feature (iii) related to the problem of providing test results to the user, so that feature (iii) was integrally linked with features (i) and (ii) and could not be evaluated in isolation. Document D10 suffered from the same deficiencies as D9 and consequently could not successfully be employed to attack the inventive step of the claims of the main request.

(ii) Auxiliary request

Although filed during the oral proceedings, the auxiliary request should be admitted since it had been formulated as a reaction to specific aspects discussed during the oral proceedings. In order to conveniently react to the discussed objection, the claim had been only slightly amended. This minor change did not involve undue complexity which the respondent or the Board could not properly deal with at the oral proceedings.

In D9, the processor of the server, PC 14, was not disclosed as causing the reception of the identification information of the medical device. It was conceivable that it was the communication station which started the process of receiving the identification information. The claim moreover defined the step of causing the reception of the identification information and the subsequent step of causing the transfer of a protocol component in a clear temporal and causal sequence, which was absent from D9 and in no way obvious therefrom.

IX. The arguments of respondent/opponent 2 and former respondent/opponent 1 relevant for the present decision are summarised as follows.

(i) Main request

Claim 1 was not allowable for lack of inventive step, for the reasons stated in the impugned decision. Features (i) and (ii) on the one hand and feature (iii) on the other hand should be evaluated separately for inventive step, as correctly stated in the impugned decision. Regarding features (i) and (ii), D9 disclosed an improved embodiment in which the PC 14 was able to update the protocol used for communication between the communication station and the medical device based upon the identification information of the medical device (page 40, lines 16 to 18). D9 disclosed that the transfer of information was initiated by the PC. Moreover the PC received information indicative of the type of medical device that had uploaded measurement data. Since the communication station and the PC in D9 were connected by a computer network, both comprised a network interface. It was obvious to provide the communication station with the test results from the PC according to feature (iii).

(ii) Auxiliary request

The Board was requested not to admit the auxiliary request. It had been filed at a very late stage, namely during the oral proceedings, even though no fundamentally new aspects had been raised at those proceedings.

Claim 1 did not involve an inventive step. The suitability of the processor of the PC in D9 to cause the reception of identification information from the medical device rendered it obvious that the processor would carry out this step.

Reasons for the Decision

1. The appeal is admissible.

2. The patent in suit

The system structure on which the claimed method is implemented consists, in essence, of a server ("first computing device (110)") connected via a network (150) to a client ("second computing device (120)") which communicates with medical devices (130), notably monitors of physiological conditions, such as glucose or blood pressure monitors (Figure 1; original page 3, paragraph before last; original page 8, paragraph before last).

The patent claims relate to a method for accessing a medical device (130) via a server ("first computing device (110)") and a client computing device ("second computing device (120)") wherein, inter alia, the medical device is operably coupled to the client computing device which is configured to communicate with the medical device via a communication protocol designed for the specific medical device (original page 1, paragraph 3).

3. Main request - inventive step

3.1 Document D9 is considered as the closest prior art. It discloses a system (depicted in Figure 3) which comprises mainly a "first computing device" (host PC 14) connected via a network (page 7, lines 14 to 19) to a "second computing device" (communication station 10) which communicates with medical devices (infusion pump 12, glucose monitor 18, glucose meter 24). The PC 14 receives and analyses measurement data from a medical device (12, 18, 24) in response to the communication station (10) communicating with the medical device via a protocol component to obtain results data (page 16, lines 21 to 22; page 17, lines 10 to 13 and 21 to 25; page 3, lines 15 to 21).

D9 discloses moreover that measurement data are transferred from any of the medical devices to the PC 14 by automatically determining the medical device type and by using the corresponding communication protocol (page 15, lines 26 to 28; page 17, lines 10 to 13), so that, in the language of the claim, "the processor (of the PC 14) is adapted to cause receiving identification information that is indicative of a medical device type from the second computing device (communication station 10) via the network interface", as defined in claim 1.

The appellants alleged in the written procedure that the PC in D9 lacked a network interface. The Board disagrees, however, since D9 explicitly mentions that the communication station 10 is connected to the PC 14 through a wired connection to a communication port 16, a wireless connection, a computer network, or a modem (page 7, lines 14 to 19). All of these connection means implicitly require a connection interface or "network interface" as claimed.

3.2 The method of claim 1 differs from D9 in the following features:

(i) the storage device (of the first computing device) comprising a plurality of protocol components that configure the second computing device to communicate with a plurality of medical devices in accordance with communication protocols supported by the plurality of medical devices;

(ii) the processor (of the first computing device) causing to transfer a protocol component from the first computing device to the second computing device via the network interface based upon the identification information (received by the processor which is indicative of the medical device type);

(iii) providing the second computing device with the results data.

3.3 The objective technical problem(s) solved by these features must be determined on the basis of their technical effect. Features (i) and (ii) have the technical effect of automatically configuring the second computing device with appropriate drivers for communication with a medical device. Feature (iii), instead, has no other effect or purpose than what the feature itself essentially recites, i.e. the provision of test results to the user, which is clearly entirely separate and different from the effect of features (i) and (ii).

There is consequently no synergistic effect or integral link between these two groups of features, as argued by the appellants. The possible contribution to an inventive step is therefore to be evaluated for each of these two groups of features independently, contrary to the appellants' submission.

3.4 Considering first the aforementioned features (i) and (ii), it is noted that D9 discloses a further communication station (500) which, as stated on page 33, lines 17 to 21, includes several improvements over the previously described communication station 10. It is thus obvious, contrary to the appellants' view, that the features or functions of these two embodiments are not mutually exclusive. Amongst other features, the communication station 500 has a microcontroller with the ability to perform several updates including "the PIC (Peripheral Interface Controller) Microcontroller update (which) is responsible for updating certain aspects of the RF protocol used in communicating with the RF data transmitting and programmable devices" (page 40, lines 14 to 18).

In other words, D9 discloses that the microcontroller of the communication station is capable of updating the protocol for transmitting measurement data from a medical device to the PC 14. D9 discloses on page 10, lines 22 to 26 that the communication protocols for the medical devices are contained in the communication station 10, for example in a RAM. As correctly pointed out by the appellants, D9 does not disclose the source of the protocol updates.

The Board considers, however, that when a communication protocol installed on the communication station 10 needs an update, the skilled person would readily recognise the PC 14 as the most obvious source for providing such an update. The update will thus be transferred from a "storage device" of the PC 14 to the communication station "via the network interface".

Moreover, since each protocol is specific to the corresponding medical device, the protocol update in D9 will necessarily be "based upon the identification information" received by the processor of PC 14 "that is indicative of the medical device type" as defined in claim 1.

Hence, once the PC in D9 is chosen as the obvious source for providing a protocol update, the PC will in fact use the previously received device identification information in the process of causing the protocol transfer, contrary to the appellants' submission.

3.5 The appellants argued that there was no disclosure in D9 of a server that controlled device/client communications by causing the transfer of protocols, let alone a server that caused such protocol transfers based on device identification information from the client. In particular, for the second embodiment (communication station 500), the user had to manually select the device to be communicated with, so that the protocol transfers were not based on device identification information from the client.

The Board could not accept this argument. As indicated above, the choice of the PC 14 as a source for any necessary device-specific protocol update is obvious to the skilled person reading D9. Moreover, D9 does in fact disclose in connection with the improved or second embodiment (communication station 500), a "PC Controlled Mode" (paragraph bridging pages 39 and 40), in which, for example, the PC instructs the communication station 500 to download data from any specific device (page 39, line 26 to page 40, line 4). In this process, the PC receives identification information from the device, which the PC will then be capable of using when a protocol update for that device is transmitted to the communication station.

3.6 Consequently, features (i) and (ii) are rendered obvious by the disclosure of D9.

3.7 The objective technical problem underlying feature (iii) is to devise a more versatile way of providing information to the patient.

Feature (iii) has already been disclosed in document D10 for a similar system having a "first computing device" (server 18) connected via a network (24) to a "second computing device" (remote apparatus 26) which communicates with a medical device (28). In Figure 18 of D10, the display of the remote apparatus 26 is shown to present results data provided from the server (page 20, lines 37 to 40; page 21, lines 18 to 26).

Therefore, the skilled person attempting to solve the mentioned problem would readily incorporate this feature known from D10 into the device of D9.

3.8 As a consequence of the above, the subject-matter of claim 1 of the main request lacks an inventive step within the meaning of Article 56 EPC.

4. Auxiliary request

4.1 In response to the discussion of inventive step concerning claim 1 of the main request during the oral proceedings, the appellants filed an amended claim 1 as an auxiliary request.

The respondent/opponent 2 requested the Board not to admit this claim, arguing that it had been filed at a very late stage and no fundamentally new aspects had been raised at the oral proceedings.

The Board did not share this view. Whilst it is true that the requirement of inventive step was discussed during the oral proceedings mainly on the basis of the reasoning presented in the impugned decision, certain aspects or consequences of the disclosure of D9 may have been fully realised only in the course of the debate, thereby prompting the appellants to recite the claimed subject-matter more precisely, in order to overcome the objection discussed. Moreover, the amendment which was offered was just a slight change in the claim involving no undue complexity which the respondent/opponent 2 or the Board could not properly deal with at the oral proceedings.

The Board consequently admitted the auxiliary request, in the exercise of its discretion under Article 13(1) RPBA.

4.2 In claim 1 of the auxiliary request, the processor being suitable for "causing receiving said identification information that is indicative of a medical device type from the second computing device via the network interface" has been changed to recite the processor carrying out the method step itself.

As indicated under point 3.1 above, according to D9, when measurement data are transferred from any of the medical devices to the PC 14 the medical device type is automatically determined and the corresponding communication protocol is used. This requires the processor of the PC 14 to be suitable to cause the reception of the identification information of the medical device. Since the processor is suitable to perform this step, there is no inventive merit in devising it so that it does indeed carry it out. Moreover, once this step is carried out, any later update of the communication protocol will be performed using this identification information. Hence, contrary to the appellants' argument, the temporal and causal sequence of these steps would naturally also result.

4.3 The subject-matter of claim 1 of the auxiliary request therefore lacks an inventive step within the meaning of Article 56 EPC.

Order

For these reasons it is decided that:

The appeal is dismissed.