T 1196/07 (Remote programming of a peristaltic pump/CURLIN) of 16.7.2010

Summary of Facts and Submissions

I. This appeal is against the decision of the examining division dispatched 26 February 2007, refusing European patent application No. 03771777.4 because of lack of inventive step (Article 52(1) EPC and Article 56 EPC 1973) having regard to the disclosure of prior art document:

D1: US 2001/031944 A1.

II. The notice of appeal was filed with letter received on 13 April 2007. The appeal fee was paid on 24 April 2007. The statement setting out the grounds of appeal was received on 26 June 2007. The cancellation of the appealed decision was requested. The appellant argued on the basis of the claim sets of the main request and first to third auxiliary requests on which the decision under appeal was based. Oral proceedings were requested on an auxiliary basis.

III. A summons to oral proceedings to be held on 16 July 2010 was issued on 1 April 2010. In an annex accompanying the summons the board expressed the preliminary opinion that the subject-matter of the independent claims of the main request and of the auxiliary requests did not fulfil the requirements of Article 56 EPC 1973 having regard to the disclosure of

D2: US 6 269 340 B1,

which had been cited in the first instance proceedings. Further, the subject-matter of the independent claims of all requests appeared to lack an inventive step (Article 56 EPC 1973) having regard to the disclosure of D1 when combined with the skilled person's common general knowledge, as argued by the examining division. The board gave its reasons for the objections and stated that the appellant's arguments were not convincing.

IV. With a letter dated 13 June 2010 the appellant submitted two independent claims 1 according to a primary request and an auxiliary request named auxiliary position together with arguments that these claims were novel and met the requirements of Article 56 EPC 1973. With a further letter dated 14 June 2010 the appellant filed two amended sets of claims named primary request and auxiliary request and amended pages 3, 3a and 3b.

V. At oral proceedings, held on 16 July 2010, the requests submitted with letter dated 14 June 2010 were discussed.

VI. Independent claim 10 according to the primary request reads as follows:

"10. A system for storing protocol information for a drug for administration to a patient via a

peristaltic pump on a remote storage device, the system comprising:

- a peristaltic pump with a keypad and logic software and the remote storage device;

- a communications path between the peristaltic pump and the remote storage device;

- a keypad for entering the protocol information for the drug into the peristaltic pump;

- means for storing a protocol file of data and keypad commands;

- means for transferring the protocol file as protocol information from the peristaltic pump to

the remote storage device;

- means for storing the protocol information for the drug on the remote storage device;

- means for editing a precautions field associated with the protocol information;

- means for enabling communication of the edited protocol information to the peristaltic pump which causes a precaution window to display the precaution information for the protocol via a display; and

- a noted button, wherein the administrator of the drug protocol is required to review the precautions and indicate that the precautions have been reviewed by processing the noted button."

Independent claim 9 according to the auxiliary request differs from claim 10 of the main request by the following additional feature:

"- a single therapy button enabling a user to restrict the use of the peristaltic pump to a single therapy by disabling all but one therapeutic mode on the peristaltic pump."

Independent claims 1 of both requests are directed to a corresponding method, respectively.

VII. The appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of one of the two sets of claims filed with letter dated 14 June 2010 as primary and auxiliary requests.

VIII. After deliberation the board announced its decision.

Reasons for the Decision

1. Admissibility

The appeal complies with the provisions of Articles 106 to 108 EPC 1973, which are applicable according to J 0010/07, point 1 (see Facts and Submissions, point II above). Therefore the appeal is admissible.

Inventive step (Article 56 EPC 1973)

Primary request

2. D2 discloses an infusion pump with an electronically loadable drug library. The pump may be operated according to a drug entry selected from the drug library or according to data entered by the user by means of an empty template. Pump events recorded in an event log may be downloaded from the pump to a personal computer (see column 8, lines 4 to 7; column 11, lines 64 to 66; column 20, line 67 to column 21, line 4 and column 28, line 15 to 34). Therefore, the board considers D2 to be the most relevant prior art document.

2.1 D2 discloses a portable infusion pump with an internal memory for storing an electronically loadable drug library (see column 8, lines 4 to 7). A user can electronically load a customized drug library and supplementary configuration data into the pump from an external computer source, e.g. a PC (see column 10, line 64 to column 11, line 4). The drug library may be stored in the memory of the PC or on a disk storage (see column 11, lines 16 to 19). Thus, D2 discloses a system for storing protocol information for a drug for administration to a patient via an infusion pump on a remote storage device, as claimed in claim 10. The system comprises a pump (figure 1, column 8, lines 4 to 7) with a keypad (figure 3, column 8, lines 7 and 8).

The internal circuit of the infusion pump includes microprocessors and various memories (RAM 44, ROM 46, EEPROM 48) into which the pump operating system and executable code are loaded (see figure 2, column 9, lines 1 to 4 and 19 to 21, column 10, lines 10 to 17). Thus, the system comprises logic software.

The PC's memory or the disk storage storing the drug library (see figure 5, column 11, lines 16 to 19) correspond to the remote storage device, required in claim 10.

The user can electronically load the drug library from the PC, i.e. the PC's memory, into the pump (see figure 5 and column 10, line 64 to column 11, line 1). This implies a communications path between the pump and the PC, i.e. the remote storage device.

The keyboard on the front of the pump (see column 21, lines 2 to 4; figure 19a, step 302; figure 25, steps 419 and 420) represents a keypad for entering the protocol information for the drug into the pump.

The pump includes program code that generates an event log in the pump's EEPROM (see column 28, lines 15 to 34 and column 16, lines 33 to 39), implying means suitable for storing a protocol file of data and keypad commands.

The event log can be retrieved from the pump, downloaded into the PC and stored on disk (see column 28, lines 27 to 32 and column 6, lines 51 to 55), implying means for transferring the protocol file as protocol information from the pump to the remote storage device and means for storing the protocol information for the drug on the remote storage device.

D2 discloses that a drug entry may be modified (see column 12, lines 7 to 10) and that the user can read a selected configuration file into active memory on the PC for further editing (see column 16, lines 23 to 25), implying means for editing said protocol information. D2 discloses that a user can electronically load a customized drug library and supplementary configuration data into the pump, implying means for sending the edited protocol information to the pump for administration to the patient (column 10, lines 64 to 67; column 16, lines 26 to 30). In addition, D2 discloses a variety of security features (see column 18, line 59 onwards). In particular, D2 teaches measures in order to prevent loading unapproved drug libraries to the pump (see column 18, lines 60 to 64). For this purpose, inter alia, an "approval field" 264 is used in which a person having supervisory access level has to indicate that this configuration has been approved. The approval field also contains information about date and time of the approval (see column 19, line 48 to column 20, line 49). If a newly created or modified configuration of the pump has not been approved, it is not permitted to load the configuration file to the pump. Only if the file received its approval after the last change to the file, does the program allow the user to proceed with loading the file. The board judges that this approval process represents a precaution measure. Since the precaution field according to claim 10 is not limited to a special type of precaution information, the board considers the approval field disclosed in D2 to be a precaution field associated with the configuration of the pump, i.e. the protocol information, which can be edited as required according to the further feature of claim 10. The edited protocol information can also be communicated to the pump, as claimed according to claim 10.

2.2 The appellant interpreted claim 10 at oral proceedings as meaning that the means for enabling such a communication cause a precaution window to display the precaution information at the remote device. The board judges that the approval field 264 in D2 has to be displayed at the remote device in order that the supervisor can input the required approving information. The use of a window is regarded as an obvious standard implementation of displaying any kind of information on displays. The supervisor necessarily has to operate at least one key or button to input the corresponding approval. This key or button corresponds to a "noted button" required according to the last feature of claim 10.

2.3 According to a further possible interpretation of claim 10 the precaution information is displayed in a precaution window at the pump. The board notes that D2 further discloses an additional input option according to which a user can input relevant information into the pump through the touch memory contacts 33 (see figure 1). If this option is used after the pump has been configured, the pump performs a verification function (see figure 26). D2 (column 28, lines 4 to 13) reads as follows: "If inconsistencies are found, the pump reports those inconsistencies to the user and disables the pump from running the drug until the user either overrides the program or in some other way satisfactorily reconciles the inconsistency (step 434)". Reporting inconsistencies implies a display of corresponding information. The use of a window as display and the use of the pump's keyboard, i.e. of at least one key or button, for a reaction from the user required to operate the disabled pump are regarded as obvious standard implementations. The key or button of the pump's keyboard corresponds to a "noted button" as claimed according to the last feature of claim 10.

According to claim 10 the "noted button" is further specified as follows: "the administrator of the drug protocol is required to review the precautions and indicate that the precautions have been reviewed by processing the noted button". The board notes that D2 discloses that a programmed configuration has to be reviewed and approved by a supervisor, who is considered to be an administrator of the drug protocol, as required according to claim 10. However, this aspect of the claimed subject-matter does not contribute to the solution of the underlying problem of improving security of the infusion pump. If the noted button is operated by either a different person or an administrator who by error does not understand the precaution information correctly, security of the infusion pump will not be improved. Therefore, this aspect of the claimed subject-matter does not contribute to the technical character of claim 10. Thus, it cannot support the presence of inventive step, in accordance with established case law (see e.g. T0641/00).

2.4 The appellant further argued that the approval field in D2 did not correspond to precaution information, since it was purely related to access control. This argument does not convince, because D2 discloses that relevant information which can be input by a user can be, for example, the drug expiration date (see column 27, line 30), which the board considers to be precaution information.

2.5 Furthermore, the board judges that the content of the data displayed in the precaution window is to be considered purely cognitive data which, in contrast to functional data (see e.g. T1194/97, reason 3.3), does not affect the functioning of the system and, hence, that the type of data does not contribute to the technical character of claim 10. Even if for the sake of argument there were such a difference in the type of data (see the afore mentioned disclosure in D2, point 2.4 above), this would not contribute to an inventive step of claim 10.

2.6 A technical difference between the subject-matter of claim 10 and the disclosure of D2 is that the type of pump according to claim 10 is a peristaltic pump, whereas D2 discloses the use of an infusion pump in general, in particular a syringe pump (see e.g. figure 1). However, the features specifying independent claim 10 are not linked to the internal construction of the pump, since there is no synergistic effect between these features and the pump being a peristaltic pump. Thus, the teaching disclosed in D2 would be applied by the skilled person to a peristaltic pump without the need of inventive skills.

Thus, the subject-matter of claim 10 lacks an inventive step over the disclosure of D2.

Auxiliary request

3. Claim 9 of this request further specifies a single therapy button enabling a user to restrict the use of the peristaltic pump to a single therapy by disabling all but one therapeutic mode on the peristaltic pump. The underlying objective technical problem is, according to the appellant's submissions, to prevent a therapy being mistakenly programmed and sent to a patient for whom only a single therapy is appropriate.

3.1 D2 suggests means for limiting the number of modes available to the user (see the table on column 25, second entry "Select Modes?" in line 60).

In the light of such a motivation in the closest prior art D2, the skilled person would look for concrete solutions in the further prior art. He would therefore consider D1, which is in the same technical field and also deals with the communication capabilities of infusion pumps.

D1 provides a solution to the objective problem by suggesting that "only one application be stored in flash memory 240 as a safety precaution against the caregiver or the patient inadvertently running the wrong program" (see paragraph [0290]). Furthermore, D1 suggests "Also, pump 100 may be simpler to operate if only one application is stored in the memory of pump 100. With only one application program stored in the memory, it is not possible for the wrong application program to be selected, once pump 100 is properly programmed. This is a safety feature for protecting the patient from inadvertently receiving the wrong therapy…" (see paragraph [0299]).

3.2 Thus, D1 discloses the claimed solution except for the use of a dedicated button ("single therapy button") for this purpose, which, however, is considered an obvious design alternative within the routine skills. The solution according to claim 9 is therefore obvious.

3.3 The board does not agree with the appellant's argument that there is a combinative effect caused by this added feature and the afore-mentioned security measures according to claim 9.

While these features all contribute to improving the security of the pump, there is no interaction between displaying precaution information and the use of a noted button on the one hand, and a single therapy button one the other hand. Since there is no synergistic or surprising effect which would justify an inventive activity, the subject-matter of claim 9 of this request also lacks an inventive step having regard to the disclosure of D2 combined with the teaching of D1.

4. Thus, neither of the two requests is allowable.

ORDER

For these reasons it is decided that:

The appeal is dismissed.