 |
| Sending an interrogation signal |
How much can the skilled person bring to the table when establishing the meaning and enablement of a claim? This application was refused by the Examining division for being neither clear nor sufficiently disclosed. But the board has a higher opinion of the skilled person, and consider him capable enough to bridge the gaps.
The claims relate to a first device that stores 'multiple versions of application software'. The first device want to communicate with a second device, but its software may not be compatible. This is solved according to Claim 1 by sending 'an interrogation signal' to the second device and receiving back 'identification information'. The first device's method then comprises, based on
the identification information:
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."
An auxiliary request restricts claim 1 to a control device and an implantable medical device. Although the board reverses the Examining division on clarity and sufficient disclosure, in the end the claims are found to be non-inventive.
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 paragraph 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 electronic 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 interrogation 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".
