T 1674/09 (Updating firmware/HEWLETT PACKARD) of 7.6.2013

Summary of Facts and Submissions

I. This is an appeal against the decision, announced at oral proceedings held on 8 May 2009, with reasons dispatched on 19 May 2009, by the examining decision to refuse European patent application No. 99 115 489.9 on the basis that claims 1 and 3 according to the then main request contained added subject-matter, Article 123(2) EPC, that the claims according to the main request were inconcise because they contained too many independent method claims, Article 84 and Rule 29(2) EPC 1973, and that claim 1 was unclear, Article 84 EPC 1973. The examining division also commented that the subject-matter of claim 1 lacked inventive step, Article 56 EPC 1973, in view of either D3 alone or D3 combined with D4, these documents being as follows:

D3: U.S. Robotics, "Palm OS Welcome to Developing Palm OS Applications, Part I: System and User Interface Management", [Online] 1996, Internet, XP002510917. Retrieved from the Internet on 16 January 2009,

URL: http://web.mit.edu/pilot/pilot-docs/V1.0/guide1.pdf

D4: U.S. Robotics, "Palm OS Welcome to Developing Palm OS Applications, Part II: Memory and Communications Management" [Online] 1996, Internet, XP002510924. Retrieved from the Internet from the same URL as D3 on 16 January 2009.

The claims according to an auxiliary request were also found not to comply with Article 123(2) EPC and Article 84 and Rule 29(2) EPC 1973.

II. In a combined notice and statement of grounds of appeal, received on 29 July 2009, the appellant requested that the decision be set aside and that, as a main request, a patent be granted on the basis of the following documents:

Description:

Pages 1 to 10, as originally filed.

Claims:

1 to 3, received as the main request on 2 April 2009.

Figures:

1/3 to 3/3, as originally filed.

The appellant stated that "Should the Board of Appeal be of the opinion that the present application is still not in a condition of allowance, it is respectfully requested to schedule a date for Oral Proceedings." If the board were to have only minor objections to the application documents, then the appellant requested a written communication by the board or a telephone call to the representative or the applicant. The appeal fee was paid on 29 July 2009.

III. The claims of the main request received on 2 April 2009 consist of independent method claims 1 and 3 and a dependent claim 2, the independent claims reading as follows:

"1. A method of changing firmware of a device, the method comprising: upon detection of a hard reset or an overall system reset, copying (208) device-identification information which needs to remain unchanged until a next system reset but which may change during a firmware update from a first section of memory that is subject to change during a firmware update to a second section of memory that is not subject to change during a firmware update, and performing (210) a configuration operation using the device-identification information; upon reception of a signal or command to update the firmware, writing new firmware in the first section of memory without changing the second section of memory, wherein the device-identification information changes during the firmware update; after the firmware has been updated, performing (204) a soft reset process comprising tasks involved in a reset process that do not impact the copied information; and using the copied version of the device-identification information during operation, until another hard reset."

"3. A method of changing firmware of a device, the method comprising: upon detection of a hard reset or an overall system reset, performing (210) a configuration operation using a device-identification information, which may change during a firmware update, to obtain configuration information, and saving (212) the configuration information in a second section of memory that is not subject to change during a firmware update; upon reception of a signal or command to update the firmware, changing (206) the firmware in the first section of memory without changing the second section of memory, wherein the device-identification information changes during the firmware update; and after the firmware has been updated, performing (204) a soft reset process comprising tasks involved in a reset process that do not impact the saved information."

Reasons for the Decision

1. Admissibility of the appeal

In view of the facts set out at points I and II above, the appeal fulfils the criteria for admissibility under the EPC and is therefore admissible.

2. The context of the invention

2.1 The invention relates to updating the firmware of a microprocessor-controlled device without the need to do an overall reset of the system containing the device. When a PC is turned on or reset a system initialization process occurs, for example according to the ISA (Industry Standard Architecture) bus standard or the SCSI (Small Computer System Interface) standard, in which the PC CPU discovers and configures all the system peripheral devices so that they can be individually addressed by the CPU. This involves using what is termed in the claims "device-identification information" to assign "logical device numbers" or "SCSI addresses", collectively termed "configuration information" in the claims, according to the ISA and SCSI standards, respectively.

2.2 The invention avoids the need for such a system reset when a firmware update is made to a device which may affect the initialization process. To do this, status and configuration information and information which may change during a firmware update are stored in a memory area unaffected by the firmware update. The description sets out two embodiments which differ as to when information is copied to a memory area unaffected by the firmware update. Only the first embodiment, shown in figure 2, is claimed. According to this embodiment, a hard reset or an overall system reset causes device identification information (step 208) and/or configuration information (step 212) to be saved in a separate portion of memory not subject to change during a firmware update. A subsequent firmware update (step 206) is followed by a "soft reset" (step 204) of the device, but an overall system reset is not required.

3. The amendments to the application, Article 123(2) EPC

3.1 The present claims are the same as those of the main request decided upon in the appealed decision. According to the reasons for that decision, independent claims 1 and 3 contain added subject-matter, Article 123(2) EPC, due to the expressions "copying device-identification information which needs to remain unchanged until a next system reset" and "performing a configuration operation using a device identification information, which may change during a firmware update, to obtain configuration information" in claims 1 and 3, respectively.

3.2 The board disagrees with both objections in the decision. The cited expression in claim 1 is based on page 7, lines 15 to 19. In particular, the empasized expression in claim 1 shown above is based on page 1, lines 23 to 24. The cited expression in claim 3 is based on page 2, lines 4 to 27, page 7, lines 15 to 17, and the sentence bridging pages 7 and 8.

3.3 The board finds that the application has been amended in compliance with Article 123(2) EPC.

4. The conciseness and clarity of the claims

4.1 According to the reasons for the appealed decision, the statement of claims contained too many independent method claims and was thus inconcise, Article 84 and Rule 29(2) EPC 1973, since claims 1 and 3 did not set out alternatives, but merely the same method of changing firmware in a device, albeit in different terms. Moreover, although claim 1 was more generalized than claim 3, claim 3 lacked step 208 (storage of device ID information), set out in claim 1, this step being an essential feature of the invention. It was also unclear what the differences between the various types of reset mentioned in claim 1 were. It was unclear what technical features were implied by resetting the device without impacting the copied information. The relationship between the copied device-identification information and the firmware update was unclear. It was unclear in claim 1 what the "configuration operation" was and what was meant by "using the device-identification information". It was also unclear during which "operation" the copied version of the device-identification information was used.

4.2 The conciseness of the claims, Article 84 and Rule 29(2) EPC 1973

4.2.1 Claims 1 and 3 both relate to the embodiment shown in figure 2, but, as set out in original claims 1 and 3 respectively, in step 208 of claim 1 device ID information is copied to a second section of memory, whilst in step 212 of claim 3 configuration information (the result of the configuration process using the device-identification information) is copied to a second section of memory. The board accepts the appellant's explanation using the example of the Plug and Play ISA Standards (see page 2, lines 4 to 17) that the "unique identifier that includes a vendor identifier and a serial number" (see page 2, line 10) can be regarded as the claimed "device-identification information" and that the "logical device number" (see page 2, line 15) can be regarded as the claimed "configuration information". Similarly, the board agrees with the appellant that, in the case of the SCSI interface standard (see page 2, lines 18 to 27), the "default ID" (see page 2, line 23) and "SCSI address" (see page 2, line 27) fall under the claimed "device-identification information" and "configuration information", respectively.

4.2.2 Hence claims 1 and 3 represent alternative solutions, Rule 29(2)(c) EPC 1973. The board concludes that the claims are concise, Article 84 EPC 1973.

4.3 The clarity of claim 1, Article 84 EPC 1973

4.3.1 The various types of reset mentioned in claim 1 and the technical features implied by resetting the device without impacting the copied information

Claim 1 uses the terms "hard reset", "system reset" and "soft reset". In the board's view, these expressions are terms of art and thus sufficiently clear to the skilled person. According to page 7, lines 4 to 6, the terms in figure 2 "hard reset" and "soft reset" refer only to processes within one firmware controlled device, rather than to an "overall system". According to page 1, lines 24 to 26, the device is part of a system. Page 2, lines 7 to 9, gives an example of a device, namely an I/O board for the ISA bus of a PC. In the context of claim 1, the board understands the terms "hard reset" and "soft reset" to refer to resetting the device, rather than resetting the whole system containing the device, a "hard reset" putting the device into a predefined state and clearing volatile memory, whilst a "soft reset" puts the device into a predefined state and does not clear volatile memory. This interpretation of a "soft reset" is consistent with the explanation given on page 8, lines 19 to 22, that the soft reset process does not impact the stored device identification and configuration information; see figure 2, steps 208 and 212. Whilst, in the light of page 7, lines 4 to 6, the terms "hard reset" and "soft reset" may be used for an overall system and therefore considered as a "system reset", the skilled person would understand from the application, in particular the statement in claim 1 "copying (208) device-identification information which needs to remain unchanged until a next system reset", that the claimed "system reset" affects the device volatile memory and is thus a system hard reset.

The board concludes that the skilled person would understand the meaning of the various types of reset mentioned in claim 1 and the technical features implied by resetting the device without impacting the copied information.

4.3.2 The overwriting of device-identification information by a new firmware upgrade

4.3.3 According to the decision, "Each device has at least one device-identification being stored usually in non-writable piece of memory, which uniquely identifies said device. This device-identification information remains, usually, invariable and is not changed even during the firmware upgrade. Therefore, it is not clear why said device-identification information should be overwritten by a new firmware upgrade." The appellant however correctly points out that claim 1 sets out that the device has identification information which may change during a firmware update. The board also accepts the appellant's argument that devices having different firmware versions should be distinguishable, i.e. that a firmware update should cause the device identification information to change, as disclosed on page 3, lines 15 to 18.

Hence the board finds that claim 1 is clear in this respect.

4.3.4 The "configuration operation" and how it uses the device-identification information

As support for the claimed "configuration operation", the appellant correctly refers inter alia to the automatic configuration processes disclosed in the context of the "Plug and Play" ISA and SCSI standards on page 2, lines 4 to 27, and page 3, lines 6 to 21.

Hence the board finds that claim 1 is clear in this respect.

4.3.5 The "operation" referred to in the expression "using the copied version of the device-identification information during operation, until another hard reset"

The original application only uses the term "operation" three times, namely in the following three passages in the description (emphasis added by the board). According to page 1, lines 26 to 28, "There is a need in some systems for the ability to update firmware within one device but to maintain integrity of some data and to continue operation without requiring an overall system reset or reboot." According to page 2, lines 1 to 3, "The second set of examples involves data that a device may need to communicate to other devices, or data that may affect external operation." According to page 7, lines 17 to 20, "In the example, at step 208, the device identification is copied into a part of memory that is not changed during a firmware update. Then, during autoconfiguration, and during operation until another hard reset, the copied version is used, not the original." In the first and second passages, the term "operation" refers to system program execution, while in the third passage the term refers to "device program execution". This latter meaning applies in claim 1, since claim 1 uses the term "operation" in the context of the device in the expression "using the copied version of the device-identification information during operation, until another hard reset". The board also accepts the appellant's argument that "operation" is a broad term meaning the functionalities ("operations") performed between the copying of the device-identification information and the next hard reset.

4.3.6 Hence the board finds that the claims are clear, Article 84 EPC 1973.

5. The prior art

D3 and D4 are parts I and II, respectively, of the online documentation relating to developing applications for the "Palm OS" operating system which runs on a "Palm OS" device, for instance a personal digital assistant (PDA). D3 concerns system and user interface management, while D4 concerns memory and communications management.

5.1 D3: system and user interface management

5.1.1 Pages 34 to 36 set out the "basic hardware" of the "Palm OS Device". All the RAM and ROM in the device are located on a user-replaceable memory module, there being no disk drive or PCMCIA support. According to page 36, lines 1 to 2, the Palm OS device has a socket for a single such memory module. The memory module shipped with the device comprises 128K of pseudo-static RAM and 512K of ROM, 32K of the RAM being reserved for system use and thus not available for storing data. The ROM is for system software and application code. According to the section entitled "Palm OS Connectivity" on page 35, the Palm OS device comprises a serial port for connecting the device with a desktop PC. And, according to the "Palm OS Device Reset Switch" section on page 36, the device comprises a reset switch for resetting the processor and forcing a boot-up sequence. In particular, simply pressing the reset switch causes a soft reset which does not destroy any user data, while holding down the power button while pressing the reset switch causes a hard reset which erases all user data following a confirmation by the user.

5.1.2 According to pages 38 to 44, an application comprises a "Startup Routine", an "Event Loop" and a "Stop Routine". The "Startup Routine" comprises initialization activities, for instance opening databases and reading saved state data. The "Event Loop" defines how the application responds to events such as user input during the normal running of the program. The "Stop Routine" performs cleanup activities, such as closing databases and saving state information.

5.1.3 The basic operation of the operating system, including system boot and reset, is controlled by the "System Manager"; see the section entitled "System Boot and Reset" on page 149. Booting only occurs when the reset switch is pressed. Otherwise power is always applied to essential subsystems, and the on/off key brings the device into or out of the low-power "sleep mode"; see "power management" on page 150. In the "sleep" mode the memory system (i.e. RAM), real-time clock and interrupt generation circuitry are still powered. All other peripherals, for instance the LCD screen and the serial port, are turned off to conserve battery power.

5.1.4 Applications can call the "SysReset" routine to carry out a soft reset; see "System Reset Calls", page 155. For instance, the "Sync" application, with which the user can copy an "extension" from a PC to the Palm OS device, subsequently calls the "SysReset" routine to allow the extension to install itself. According to the section entitled "Predefined Action Codes" on page 50, the system notifies an application that its data files have been updated by a sync operation. According to page 331, the "SysReset" routine also reinitializes the dynamic memory heap, but preserves all database information.

5.1.5 The reasoning in the decision treats the copying of an "extension" from a PC to the RAM in the memory module of a Palm OS device during synchronisation as a change in the device firmware, the synchronization process triggering a soft reset on completion. The subsequent installation of the "extension" is regarded as the claimed "configuration operation" and its location in RAM (termed "records A") is regarded as the claimed first section of memory. The soft reset is regarded as not impacting "the copied information or saved configuration" in a second section of memory (termed "records B"), the "configuration operation" terminating by saving state information in the second section of memory. Thus, according to the appealed decision, the subject-matter of claim 1 differed from the disclosure of D3 in, upon detection of a hard reset or an overall system reset, copying device-identification information, which needed to remain unchanged, but which might change during a firmware update, from a first section of a memory that was subject to change during a firmware update to a second section of the memory that was not subject to change during the firmware update. However the copying feature had no technical effect, in particular because the skilled person would not have understood, either from claim 1 or from the description (see page 7, lines 11 to 20), the relationship between the firmware update and the information to be stored in a second section of the memory. Hence the copying feature was not relevant for assessing inventive step, and the subject-matter of claim 1 lacked inventive step over D3 alone. Moreover, storing data in a section of memory not subject to change during a firmware update was also apparent from the combined teaching of D3 and D4, which the skilled person would combine, since D4 was a continuation of the teaching of D3. Thus the subject-matter of claim 1 also lacked inventive step over D3 combined with D4.

5.1.6 The board finds that the decision does not explain where all the features allegedly known from D3 are to be found, there being no explanation as to where the features in the last paragraph of claim 1 ("using the copied version of the device-identification information during operation, until another hard reset") are disclosed in D3. The board also agrees with the appellant that D3 does not disclose the claimed device-identification information or the steps of copying device-identification information to a second section of memory in response to the detection of a hard reset and writing new firmware in a first section of memory without changing the second section of memory.

5.1.7 The board however agrees with the position taken in the appealed decision that, contrary to the appellant's argument, the contents of the battery-maintained RAM known from D3 fall within the claimed "firmware", since the application mentions that firmware can be stored in "battery powered volatile memory"; see page 1, lines 17 to 19. The board also disagrees with the appellant's argument that an "extension" is necessarily user data. According to D3, page 155, penultimate paragraph, an extension can "install itself", indicating that it is program code and not merely user data.

5.1.8 Hence the following features of claims 1 and 3 are known from D3: a method of changing firmware of a device, the method comprising, after the firmware has been updated, performing a soft reset process.

5.2 D4: memory and communications management

According to the section entitled "RAM and ROM Use" on page 14, the Palm OS device has a main suite of applications stored in ROM. These applications can be updated or enhanced either by replacing the ROM, i.e. by replacing the memory module, or by loading additional or replacement applications and system extensions into RAM. According to the section headed "PC Connectivity" on the same page, all user data on the device can be synchronized with data on the user's PC. According to the section entitled "Memory Architecture" on page 15, the Palm OS system software divides the RAM into 32K of "dynamic RAM" and the remainder, termed "storage" RAM. The latter is analogous to disk storage on a desktop system. The Palm OS device breaks down data into multiple records which do not have to be adjacent, but instead can be scattered throughout the memory space, thus avoiding the delay involved in moving data around in memory when, for instance, adding or deleting a record; see page 16, "Data storage", third paragraph. According to the section headed "Memory Structure Overview" on page 17, user data on the Palm OS device is managed by the memory manager in a plurality of "heaps" of less than 64K, each heap containing one or more "chunks". Each memory chunk used to hold storage data is also referenced through a database, a database being analogous to a file in a traditional desktop system in that it lists all memory chunks that logically belong to a particular database.

6. Inventive step, Article 56 EPC 1973

6.1 The board agrees with the finding in the appealed decision that D3 forms the closest prior art on file. As stated in the decision and accepted by the appellant, the subject-matter of claim 1 differs from D3 inter alia in the following feature:

a. upon detection of a hard reset or an overall system reset, copying device-identification information which needs to remain unchanged until a next system reset but which may change during a firmware update from a first section of memory that is subject to change during a firmware update to a second section of memory that is not subject to change during a firmware update.

In addition, and contrary to the decision, the subject-matter of claim 1 further differs from D3 in the following features:

b. performing a configuration operation using device-identification information;

c. upon reception of a signal or command to update the firmware, writing new firmware in the first section of memory without changing the second section of memory, wherein the device-identification information changes during the firmware update;

d. upon reception of a signal or command to update the firmware, writing new firmware in the first section of memory without changing the second section of memory, wherein the device-identification information changes during the firmware update;

e. the soft reset comprises tasks involved in a reset process that do not impact the copied information and

f. using the copied version of the device-identification information during operation, until another hard reset.

The subject-matter of claim 3 differs from the disclosure of D3 in the following features:

a. upon detection of a hard reset or an overall system reset, performing a configuration operation using a device-identification information, which may change during a firmware update, to obtain configuration information;

b. saving the configuration information in a second section of memory that is not subject to change during a firmware update;

c. upon reception of a signal or command to update the firmware, changing the firmware in the first section of memory without changing the second section of memory, wherein the device-identification information changes during the firmware update and

d. the soft reset comprising tasks involved in a reset process that do not impact the saved information.

6.2 According to the appealed decision, the difference features over D3 had no technical effect. The board finds that the difference features set out above solve the technical problems (see difference feature "b" in claim 1 and difference feature "a" in claim 3) of building a co-operating system from initially uncoordinated peripheral devices and (the remaining difference features) allowing the system to continue to operate without a hard reset after a device firmware update. Hence all the difference features have technical character and contribute to inventive step. There is no obvious technical problem or solution which would cause the skilled person starting from D3 to add all the difference features set out above in an obvious manner. In particular, the copying difference feature (feature "a" in claim 1 and feature "b" in claim 3) is contrary to the whole philosophy of the memory management of the Palm OS device, which is to avoid moving data around in memory, and, instead, to access and update data directly in place.

6.3 Hence the board finds that the subject-matter of claims 1 and 3 involves an inventive step, Article 56 EPC 1973, over the disclosure of D3.

6.4 The combination of D3 and D4

D4 belongs to the same online documentation for developing Palm OS applications as D3, both documents explaining different aspects of the same software and hardware. Since difference features "a" to "f" of claim 1 and "a" to "d" of claim 3 are neither known from nor derivable from D4, the subject-matter of claims 1 and 3 also involves an inventive step, Article 56 EPC 1973, in view of the combination of D3 and D4.

7. The description

7.1 The board notes that page 10, lines 6 to 15, may require attention in view of Rule 34(1)(c) EPC 1973 and that amendments may be necessary in view of the present claims to comply with Rule 27(1)(c) EPC 1973.

7.2 Since the board is not deciding on matters regarding the description, the conditions for the appellant's conditional requests for oral proceedings, a written communication or a telephone call to the representative or the applicant are not fulfilled.

ORDER

For these reasons it is decided that:

1. The decision under appeal is set aside.

2. The case is remitted to the first instance with the order to grant a patent in the following form:

A description to be adapted.

The claims received as a main request on 2 April 2009

Drawing sheets 1/3 to 3/3 as originally filed.