T 2133/14 (Implant revision/CODMAN) of 3.6.2020

European Case Law Identifier: ECLI:EP:BA:2020:T213314.20200603
Date of decision: 03 June 2020
Case number: T 2133/14
Application number: 09250414.1
IPC class: G06F9/445
A61N1/372
Language of proceedings: EN
Distribution: D
Download and more information:
Decision text in EN (PDF, 337 KB)
Documentation of the appeal procedure can be found in the Register
Bibliographic information is available in: EN
Versions: Unpublished
Title of application: Implant revision recognition by exchanging the revision data during transmission
Applicant name: Codman Neuro Sciences Sàrl
Opponent name: -
Board: 3.5.06
Headnote: -
Relevant legal provisions:
European Patent Convention Art 83 (2007)
European Patent Convention Art 84 (2007)
European Patent Convention Art 56 (2007)
Keywords: Claims - clarity (yes)
Sufficiency of disclosure - (yes)
Inventive step (no)
Catchwords:

An invention is not insufficiently disclosed in the sense of Article 83 EPC just because a lack of support in the sense of Article 84 EPC of a broad claim cannot be resolved by consulting the description.

Cited decisions:
-
Citing decisions:
-

Summary of Facts and Submissions

I. The appeal lies against the decision, dispatched with reasons dated 11 June 2014, refusing European patent application No. 09 250 414.1 for non-compliance with Articles 83 and 84 EPC. In the decision, a number of documents were mentioned, in particular

D2: WO 01/47597 A,

but were not relied upon in its reasons.

II. A notice of appeal was filed on 21 August 2014, the appeal fee being paid on the same day. A statement of grounds of appeal was received on 21 October 2014. The appellant requests that the decision under appeal be set aside and a patent be granted on the basis of the requests subject to the refusal, namely claims 1-17 according to a main or an auxiliary request, in combination with drawing sheets 1/2-2/2 and description pages 1 and 4-12 as originally filed, and description pages 2, 3 and 13 as filed on 27 August 2010.

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

"Method for establishing communication among a first electronic device (110) having a first memory device (130) for storing multiple versions of application software for operation of the first electronic device and a second electronic device (105) having a second memory device (120) for storing a single current version of the application software for operation of the second electronic device, comprising the steps of:

generating (200) an interrogation signal at the first electronic device;

transmitting (205) the generated interrogation signal from the first electronic device to the second electronic device with which it is in communication;

generating (210) at the second electronic device a response signal including identification information associated with the second electronic device;

transmitting (215) the generated response signal from the second electronic device back to the first electronic device with which it is in communication;

extracting (220) the identification information from the response signal received by the first electronic device, the identification information including both of a unique identification number associated with the second electronic device and a current version of application software currently being utilized by the second electronic device; and

based on the extracted identification information associated with the second electronic device, correlating (225) thereto a version of the application software from among the multiple versions of application software associated with the first electronic device that is compatible with the recognized version of the application software currently being utilized by the second electronic device,

wherein the correlating step utilizes a look-up-table."

Claim 1 of the auxiliary request differs from claim 1 of the main request in specifying that the first and second electronics devices are a control device and an implantable medical device, respectively.

IV. With a summons to oral proceedings, the board informed the appellant of its preliminary opinion that the claimed invention was neither unclear nor insuffi­cient­ly disclosed, Articles 83 and 84 EPC 1973, but lacked an inventive step over D2, Article 56 EPC 1973.

V. In response to the summons, the appellant did not file amendments or arguments, but informed the board in a letter dated 26 May 2020 that the applicant would not be represented at the scheduled oral proceedings.

VI. The oral proceedings were then cancelled.

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.

Order

For these reasons it is decided that:

The appeal is dismissed.

Quick Navigation