T 2133/14 (Implant revision/CODMAN) 03-06-2020

Reasons for the Decision

The invention

1. The application is concerned with ensuring the compatibility of application software running on two communicating electronic devices, preferably an implantable medical device such as a cardiac pacemaker and an associated control device (see paragraphs 1 and 15).

1.1 More specifically, it is observed that the application software running on the implantable device (the "second" device in claim 1 of the main request) may be updated during its lifetime and stated that, for proper operation, the control device (the "first" device) will need to run a "compatible version of application software" (see paragraph 17).

1.2 According to a prior art solution, discussed in paragraph 4 (U.S. patent application 5,800,473), if it is detected that the implant runs a more recent version of the application software than the control device, then the more recent software "objects" are downloaded from the implant to the control device. In the application, this solution is stated to require an undesirably complex implantable device, too much energy and time, and to have the further disadvantage that the control device will at any point in time only run a single version of the application software, which may not be compatible with all implantable devices (see paragraph 4, lines 11-15, and paragraph 5). The invention is intended to overcome these disadvantages (see paragraph 9).

1.3 As a solution, it is proposed that a control device for communicating with a specific implantable device generate and transmit an "interrogation signal" to the implantable device. In response, the latter generates and transmits a "response signal" to the control device, the response signal comprising "identification information" including one or more of its type and a "unique identification number" and the version of the application software installed on it (see paragraphs 10, 20 and 23-30). The control device stores "multiple, preferably all, updates, versions or generations of the application software for the control device" in question (see paragraphs 16 and 34). Based on the received "identification information", the control device "correlates or maps" to the implantable device a compatible version of the application software using a lookup table (see paragraphs 21 and 22). Subsequently, the control device uses the so-determined compatible version (see para­graph 33). The procedure is depicted in figure 2.

Clarity and sufficiency of disclosure,

Articles 84 and 83 EPC

2. The examining division found the independent claims of both requests to be unclear for the following reasons (see the decision, points 19-22 and 25).

2.1 It was left open what kinds of interrogation and response signals could be processed by all possible electronic devices. At least for some pairs of elec­tronic devices, it would require inventive skill to provide suitable interconnection signals, while the description did not disclose further details. As a consequence, the independent claims were not supported over their full breadth by the description, Article 84 EPC, and, because "said clarity objection" could not be resolved using the description, their subject-matter was insufficiently disclosed, Article 83 EPC (see esp. the recitation of section 9.1.1.2 on pages 6 and 7 of the decision).

2.2 The claimed invention presupposed that the different software versions all had different interfaces. Because this was an unrealistic assumption, the intended "system context" was unclear (see the recitation of sections 9.1.1.3 to 9.1.1.5 on page 7 of the decision).

2.3 The claims left open how the control device was meant to be "'equipped with multiple software versions initially' for all diverse types of 'second electronic devices', [and] for all their respective versions of software", and how it was avoided that the first electronic device had to be modified whenever the application software was changed (i.e. continuously or frequently). Also, for combinatorial reasons it was unrealistic to assume that each first electronic device could store all versions of the application software for all types of second electronic device. This rendered the claims unclear, Article 84 EPC, and meant that their subject-matter was insufficiently disclosed, Article 83 EPC, because "said clarity objection" could not be resolved using the description (see the recitation of sections 9.1.2.1 to 9.1.2.5 on pages 9 and 10 of the decision).

2.4 "Correlating" a version of the application software to the second device did not have a clear technical effect, since the "correlated version of [the] application software" was neither loaded nor used for communication (see esp. the recitation of section 9.1.3 on page 11 of the decision).

The board's view on clarity and sufficiency

3. The board does not share the conclusions of the examining division on clarity of the independent claims.

3.1 While the board agrees with the examining division's view that "correlating" has no clear technical effect (see point 2.4 above), this alone does not imply a lack of clarity.

3.2 The board also agrees with the examining division that the claims do not specify any details about the inter­rogation or response signals, or what it would mean for two devices to be compatible or incompatible. The claims further do not include any feature that would allow an estimate of the number of versions the first electronic device would have to store and when or how the first electronic device would have to be updated.

3.3 None of these omissions however implies, in the board's view, a lack of clarity - or an insufficiency of disclosure, for that matter.

3.3.1 The board considers that the skilled person would have no technical difficulty in implementing a form of interrogation/response-protocol in devices even in a "non-standard scenario" such as a smartphone communicating with a cardiac pacemaker (see paragraph bridging pages 6 and 7 in the decision).

3.3.2 The skilled person would interpret the notion of "compatibility" as used in the claims broadly. In the broadest reasonable sense, two pieces of software would be considered "compatible" if they are intended - and can, thus, be assumed - to interoperate properly. Apparently, this would not be the case if their interfaces did not match. However, even software with matching interfaces might not properly interoperate, for various reasons apparent to anyone skilled in the art of programming. The skilled person would understand that, effectively, "compatibility" is what the "correlating" step establishes, and - for the purposes of the claimed subject-matter - two pieces of software are compatible if the look-up-table "says so".

3.3.3 It would have been evident to the skilled person that the memory requirements on the first electronic device grow with the number of versions of the application software to be stored. The board also agrees with the examining division that this number might well be larger than what a typical such "first electronic device" can actually store (see also "all possible versions" in claim 2). However, while it might be undesirable or impracticable for various reasons, it would not be technically difficult to either enlarge the memory of the first electronic device or to limit the number of versions to some (the most recent say, or only those needed for some "second" device types) to the detriment of others.

3.4 The board takes the view that the skilled person would not need any explicit statement in the application to be able to handle the mentioned situations properly. Hence, in the board's view, the independent claims are neither unclear in the mentioned respects, nor insufficiently supported. Their subject-matter is also not insufficiently disclosed.

4. The findings in point 3 are further corroborated by the following considerations.

4.1 An objection that a claim is too broad to be supported by the description over its full breadth can be addressed by limiting the claim to a breadth which is. For that reason, the limitation of a claim covering standard and non-standard scenarios (claim 1 of the main request) to only the standard scenario of a control device and an implantable medical device (see the auxiliary request) is a valid attempt to overcome at least one of the objections regarding incomplete support by the description labelled "9.1.1.2" (see paragraph bridging pages 6 and 7 of the decision).

4.2 Moreover, the board does not agree that the subject-matter of a claim which is not supported over its full breadth by the description or which is unclear is ipso facto insufficiently disclosed, as the examining division suggests (loc. cit.). Accordingly, the board considers that the objection under Article 83 EPC is not correctly reasoned in the decision.

5. In the following, the board takes the view that the skilled person would construe claim 1 of the auxiliary request as follows. The first electronic device (the control device), storing multiple versions of some application software, asks the second electronic device (the implantable medical device) for identification information which, inter alia, identifies the version of the application software it runs. This information is then used to identify a preferred version of the software to be run on the first electronic device. This version is identified using a look-up table and referred to in the claims as "compatible".

The prior art

6. D2 discloses a system by which an "implantable medical device" (IMD) can be updated - in terms of parameters, settings or upgrades - without requiring the physical presence of a clinician (see e.g. page 2, lines 1-11, and page 6, lines 5-17). A remote "interrogator" and "data center" is disclosed which "interrogate" the IMD for relevant information and, based on this, determine and upload pertinent upgrade data or other information to the IMD (see page 6, lines 10-15 and 22-25). More specifically, the remote system identifies the IMD and then selects a suitable "device agent module" (page 18, line 20, to page 19, line 2). After that, data can be exchanged between the remote system and the IMD, including, in particular, "software [...] or firmware version information" (page 19, lines 3-8) which may have to be upgraded.

6.1 D2 does not disclose that the selection of the device agent software uses a lookup table.

6.2 Moreover, and as the appellant points out, D2 does not disclose the transmission of both the identification of the IMD type and the version of the application software currently utilized by the IMD (see the grounds of appeal, page 6, paragraph 4). Rather, the IMD identification has to be transmitted separately from and before the software version information (see e.g. the paragraph bridging pages 6 and 7 of the grounds of appeal).

Inventive step, Article 56 EPC

7. The device agent software selected at the remote computer is chosen so as to be, in some sense, "compatible" with the "type or model of IMD" and the the preceding "dynamic identification" of the IMD by the remote computer (see page 18, lines 26-29) implies the use of some interrogation-response protocol as claimed, or at least the skilled person reading D2 would consider it as a matter of common practice. The board also regards it as implicit in D2 that several possible "agent device software" modules are available to the remote system for there to be a selection. The board cannot see why an "entire module" cannot reasonably be referred to as a version of the application software (cf. the grounds of appeal, page 7, paragraph 2).

7.1 The alternative "versions" of the agent device software are available to the remote system. It would be obvious to store it on this system. As regards the main request, the remote system qualifies as a first electronic device as claimed. As regards the auxiliary request, the board regards the remote system as a "control device". That said, given that claim 1 of the auxiliary request does not contain any limitation on the control device, the board also cannot see why a selection of the version of the agent device software should not be stored on a more narrowly construed control device with sufficient local memory.

7.2 Moreover, the board considers it to be an obvious possibility that the relevant device agent software might not only depend on the "type or model of IMD" but also on the version of some software installed on it, for example an operating system running on the IMD. In such a situation, it would be obvious, in the board's judgment, that the version number of that software also be transmitted before the selection of the agent device software.

7.3 Furthermore, with regard to the auxiliary request, the use of a look-up-table to implement a mapping, such as that from IMD identification to device agent software, is usual programming practice.

8. The board therefore agrees with the opinion expressed by the examining division in its summons to oral proceedings dated 25 February 2014 (see points 9.2.3 to 9.2.3.6) that the independent claims of both requests lack inventive step over D2, Article 56 EPC.