T 2205/08 (Nachladen von Software/BMW) of 12.7.2012

European Case Law Identifier: ECLI:EP:BA:2012:T220508.20120712
Datum der Entscheidung: 12 Juli 2012
Aktenzeichen: T 2205/08
Anmeldenummer: 04730255.9
IPC-Klasse: G06F 9/445
Verfahrenssprache: DE
Verteilung: D
Download und weitere Informationen:
Text der Entscheidung in DE (PDF, 29.346K)
Alle Dokumente zum Beschwerdeverfahren finden Sie im Register
Bibliografische Daten verfügbar in: DE
Fassungen: Unpublished
Bezeichnung der Anmeldung: Verfahren zum Nachladen einer Software in den Bootsektor eines programmierbaren Lesespeicher
Name des Anmelders: Bayerische Motoren Werke Aktiengesellschaft
Name des Einsprechenden: -
Kammer: 3.5.06
Leitsatz: -
Relevante Rechtsnormen:
European Patent Convention 1973 Art 56
European Patent Convention 1973 Art 84
Schlagwörter: Klarheit - beide Anträge (nein)
Erfinderische Tätigkeit - beide Anträge (nein)
Aktenzeichen: T 2205/08 - 3.5.06
ENTSCHEIDUNG
der Technischen Beschwerdekammer 3.5.06
vom 12. Juli 2012
Beschwerdeführer:
(Anmelder)
Bayerische Motoren Werke Aktiengesellschaft
Petuelring 130
D-80809 München (DE)
Vertreter:
Grüter, Klaus Peter
Bayerische Motoren Werke AG
Patentabteilung AJ-3
D-80788 München (DE)
Angefochtene Entscheidung:
Entscheidung der Prüfungsabteilung des Europäischen Patentamts, die am 11. Juli 2008 zur Post gegeben wurde und mit der die europäische Patentanmeldung Nr. 04730255.9 aufgrund des Artikels 97 (2) EPÜ zurückgewiesen worden ist.
Zusammensetzung der Kammer:
Orientierungssatz:

-

Angeführte Entscheidungen:
-
Anführungen in anderen Entscheidungen:
-

Sachverhalt und Anträge

I. Die Beschwerde richtet sich gegen die Entscheidung der Prü fungs abteilung, zugestellt mit Schreiben vom 11. Juli 2008, die europäische Patentanmeldung 04730255.9 zurück zu wei sen. Die Entscheidung erging "nach Aktenlage" unter Ver weis auf Prüfungsbescheide, die mit Bezug auf die Dokumente

D1: DE 101 12 056 A

D2: DE 100 08 974 A

argumentieren, dass es der beanspruchten Erfindung an einer erfinderischen Tätigkeit gegenüber D1 in Kom bi nation mit D2 fehle, Artikel 56 EPÜ 1973.

II. Beschwerde gegen diese Entscheidung wurde am 19. Juli 2008 eingelegt und die Beschwerdegebühr wurde am selben Tag entrichtet. Mit der Beschwerdebegründung, die am 17. November 2008 einging, legte die Beschwerdeführerin An sprü che 1-11 gemäß Haupt- und Hilfsantrag vor, und bean tragte die Erteilung eines Patents auf deren Grund lage.

III. Mit einer Ladung zur mündlichen Verhandlung teilte die Kammer der Beschwerdeführerin ihre vorläufige Meinung mit, nach der die vorliegenden Ansprüche nicht klar und ge genüber D1, D2 und allgemeinen Fachwissen, wie es z. B. aus dem neu eingeführten Dokument

D3: US 5 844 986

aus dem Recherchenbericht hervorgehe, nicht erfinderisch seien, Artikel 84 und 56 EPÜ 1973, und dass somit die strittige Entscheidung vo raus sicht lich zu bestätigen sei.

IV. Am 14. Juni 2012 teilte die Beschwerdeführerin ohne Aus führungen zur Sache mit, dass sie ihren Antrag auf münd liche Verhandlung zu rückziehe und eine Entscheidung nach Aktenlage bean trage. Nach Interpretation der Kammer ver zichtet die Beschwer de füh rerin mit diesem Antrag auf wei tere schrift liche oder münd liche Stellungnahmen in der Sache und beantragt den Erlass einer Entscheidung auf grund der aktenkundigen Argumente. Die anberaumte münd liche Verhandlung wurde daraufhin abgesagt.

V. Anspruch 1 des Hauptantrags lautet wie folgt:

"Verfahren zum Nachladen einer Updatesoftware (22) in einen beschreibbaren Speicherbereich (20) eines Bootsektor [sic] eines programmierbaren Steuergerätes (1) eines Fahrzeugs, umfassend die folgenden Schritte:

Bereitstellen einer in einen außerhalb des Bootsektors gelegenen, beschreibbaren Speicherbereich (10) des programmierbaren Steuergerätes (1) ladbaren Nachladesoftware (121, 122, 123), die in der Lage ist, im Steuergerät (1) die Installation der Updatesoftware (22) in den beschreibbaren Speicherbereich (20) des Bootsektor [sic] zu steuern,

Laden der Nachladesoftware (121, 122, 123) und der Updatesoftware (22) in den außerhalb des Bootsektors gelegenen, beschreibbaren Speicherbereich (10),

Ausführen der Nachladesoftware (121, 122, 123) im Steuergerät zur Installation der Update-Software (22) in den beschreibbaren Speicherbereich (20) des Bootsektors,

dass wenigstens auf einen Teil der Nachladesoftware (121, 122, 123) und/oder der Updatesoftware (22) ein Signaturverfahren angewendet wird, wobei die Software (121, 122, 123; 22) vor ihrer Übertragung in das Steuergerät (1) mittels eines ersten Signaturschlüssels (21) signiert und nach ihrer Übertragung in das Steuergerät (1) mittels eines zweiten, im Steuergerät (1) abgelegten Signaturschlüssels (21), auf ihre Unverfälschtheit hin überprüft wird,

dass der zweite Signaturschlüssel (21) in dem beschreibbaren Speicherbereich des Bootsektors abgelegt ist, und

der zweite Signaturschlüssel (21) im Bootsektor des Steuergeräts durch das Ausführen der Nachladesoftware (123) ersetzt wird."

Antrag 1 des Hilfsantrags enthält zusätzlich zu Anspruch 1 des Hauptantrags an dessen Ende das Merkmal:

"... dass zusätzlich zum Ersetzen des zweiten Signaturschlüssels eine Veränderung des Sicherheitsmechanismus erfolgt, beispielsweise Veränderungen der Schlüssellänge oder der Ersatz eines symmetrischen Signaturverfahrens durch ein asymmetrisches Signaturverfahren oder ein Zertifikat-basiertes Verfahren, und die nachzuladende Software bzw. Nachladesoftware auf diesen Sicherheitsmechanismus ausgerichtet wird."

Entscheidungsgründe

1. Die folgende Begründung stützt sich ausschließlich auf Argumente, mit denen die Kammer im Ladungszusatz ihre vorläufige Meinung begründet hat.

Die Erfindung

2. Die Erfindung bezieht sich auf sicherheitskritische Soft ware in einem Fahrzeug und dabei insbesondere auf ein Verfahren zum "Nachladen" (und Installieren) einer "Up datesoftware" im Bootsektor eines programmierbaren Steu ergeräts. Das Nachladen besorgt eine spezielle "Nach ladesoftware". Sowohl Nachlade- als auch Update soft ware werden außerhalb des Bootsektors gespeichert, und mindestens eine von beiden wird digital signiert und im Steuergerät überprüft. Die Updatesoftware kann sich be schrei bungs- wie anspruchsgemäß auf den relevanten Signaturschlüssel beschränken (s. insbes. S. 6, Zn. 22-23 und S. 7, Zn. 15-16; vgl. auch Punkt 5 infra).

Begründungsmangel

3. Den von der Beschwerdeführerin als unverständlich be män gel ten Einwand der Prüfungs ab teilung unter Punkt 3.2 des Prüfungsbescheids vom 22. Februar 2008 (vgl. Beschwerde be gründung, Punkt 2.1; S. 2, letzter Abs. und s. 3, 1. Abs.) versteht die Kammer wie folgt: Die Be schwerde füh re rin hatte am 19. Februar 2007 einen geän der ten Anspruch 1 eingereicht, den An spruchssatz im üb rigen aber nicht ausdrücklich definiert. Die Prüfungsabteilung war gemäß der im Bescheid vom 22. Februar 2008 definierten Anmeldungsunterlagen davon ausgegangen, dass der neue Anspruch 1 mit den ur sprünglichen Ansprüchen 2-15 kom bi niert werden sollte. Vor diesem Hintergrund stellt der bemängelte Ein wand nur fest, dass die ursprünglichen An sprü che 3-4 gegenüber dem neuen Anspruch 1 redundant sind. Durch die Eingabe vollständiger Anspruchssätze mit der Beschwerde be gründung hat sich dieser Einwand erle digt.

Klarheit

4. Die Beschwerdekammer stimmt der Beschwerdeführerin darin zu, dass die Verwendung von "und/oder" jedenfalls im vor liegenden Fall die drei genannten Alternativen klar zum Ausdruck bringt und daher keinen Klarheitsmangel be dingt (vgl. Beschwerdebegründung, Punkt 2.1, 2. Abs.).

5. Anspruch 1 beider Anträge formuliert, dass das Ausführen der Nachladesoftware einerseits die Updatesoftware in stalliert und andererseits den (zweiten) Signatur schlüs sel er setzt. Der Anspruchswortlaut lässt das Verhältnis zwischen Up date software und Signaturschlüssel offen. Aus der Be schrei bung und insbesondere dem bevorzugten Aus füh rungs beispiel (vgl. S. 6 ff.) ergibt sich für den Fach mann eindeutig, dass aus schließ licher "Ge gen stand der Ak tualisierung" der Schlüssel sein und dass somit der beanspruch te Terminus "Updatesoftware" den "Sig na tur schlüssel" sub sumieren kann (s. auch S. 7, Zn. 14-19, in dem der ver schlüssel te Kryptoschlüssel als ver schlüsselte Update software 111 bezeichnet wird). Anspruch 1 lässt hingegen zu, dass neben dem Signatur schlüssel immer eine von diesem ver schie dene aber im übrigen unde finierte "Up datesoftware" zu installieren ist. Nach Auffassung der Kammer steht die Beschreibung somit im Wider spruch zu Anspruch 1 bei der Anträge, entgegen die Erfordernisse von Artikel 84 EPÜ 1973.

6. Anspruch 1 des Hilfsantrags bezieht sich im letzten Absatz (vor- und drittletzte Zeile) auf "die nachzu la dende Software". Die Kammer interpretiert diesen Begriff, wie im Ladungszusatz erwähnt, dass er sich auf die sonst im Anspruch 1 aufgeführte "Up datesoftware" han delt. Anspruch 1 des Hilfsantrags for dert weiter, dass "die nach zuladende Software bzw. Nachladesoftware auf [einen zu ändernden] Sicherheitsme cha nismus ausgerichtet" sein sollen. Während es dem Fach mann ohne Weiteres er sicht lich ist, dass sich eine Änderung des Sicherheits mecha nis mus in der nachzula den den Software niederschlägt, ist es im Allgemeinen unklar, inwieweit die Nachlade software selbst darauf "ausgerich tet" sein soll - wenn man von trivialen Überlegungen z. B. darüber absieht, in welchen Speicherbereich die geän derte Software zu laden ist. Daher ist die genannte For mulierung unklar und somit im Widerspruch zu Artikel 84 EPÜ 1973.

Erfinderische Tätigkeit

7. Ungeachtet der zwei genannten Klarheitsmängel hält es die Kammer für angebracht, auch zur Frage der erfinde ri schen Tätigkeit Stellung zu nehmen.

8. Die Prüfungsabteilung ging bei ihrer Bewertung der er fin derischen Tätigkeit von Dokument D1 aus. Die Kammer zieht stattdessen D2 als Ausgangspunkt vor, das auch in der Anmeldung (S. 1, Zn. 9-16) als ein Ausgangs punkt für die Erfindung genannt wird.

9. D2 offenbart ein Verfahren zum sicheren Nachladen einer Software in ein Steuergerät eines Kraftfahrzeugs. Diese "Update"-Software wird in einem Trust-Center mit einer elektronischen Signatur versehen, die dann nach dem Ein spielen der Software im Kraftfahrzeug über prüft wird. Nur wenn diese Überprüfung erfolgreich war, wird die Soft ware als unverändert akzeptiert und im Steu er gerät des Kraftfahrzeugs auch betrieben (vgl. Sp. 7, Zn. 4-45). Der zur Überprüfung verwendete Schlüssel wird im Boot-Sek tor des Steuergeräts gespeichert, weil er dort beson ders gut gegen Manipulationen geschützt ist (Sp. 3, Zn. 3-13). Die Existenz einer entsprechenden "Nachladesoft ware", die in D2 nicht ausdrücklich diskutiert wird, be trach tet die Kammer als implizit.

Hauptantrag

10. Anspruch 1 des Hauptantrags unterscheidet sich wie folgt von D2.

a) Gegenstand der Aktualisierung ist insbesondere der im Steuergerät abgelegte Schlüssel.

b) Die Nachladesoftware wird ihrerseits "geladen", und zwar in einen außerhalb des Bootsektors gelegenen Speicherbereich, und (optional) elektronisch sig niert.

10.1 Die Aktualisierung des Schlüssels dient unter anderem dem Zweck, die Sicherheit des Systems aus D2 zu erhöhen wenn beispielsweise der geheime Schlüssel bekannt ge wor den ist und daher das Schlüsselpaar ausgetauscht werden muss.

10.2 Dass die "Nachladesoftware" jeweils neu geladen wird, hat un ter anderem die Wirkung, dass der benötigte Speicher platz nach erfolgtem Update wieder freigegeben wer den kann.

10.3 Nach Ansicht der Kammer lösen die Unter schie de a) und b) gegenüber D2 die Aufgabe, die Sicher heit in einer speicher platz sparenden Weise zu erhöhen.

11. Es ist für den Fachmann elementar, dass die Sicherheit von Verschlüsselungs- und Signaturverfahren unter ande rem davon abhängt, dass geheime Schlüssel geheim bleiben und dass somit geheime Schlüssel, die bekannt geworden sind, ausgetauscht werden müssen.

11.1 Aus dem allgemeinen Bedürfnis nach erhöhter Sicherheit ergibt sich somit für die Kammer auf unmittelbare Weise die konkrete Aufgabe, den Austausch des Schlüssels in D2 zu ermöglichen.

11.2 Gemäß D2 kann der Bootsektor "nicht ohne Weiteres überschrie ben" werden (Sp. 3, Z. 6). Für die Kammer bedeu tet diese Formulierung, dass ein solches Überschrei ben nicht grundsätzlich unmöglich ist, wenn auch u. U. be sondere Maßnahmen dafür nötig sind.

11.3 Wenn der Fachmann also Bedarf hat, den Schlüssel auszu tauschen, steht dem die Ausgestaltung des Bootsektors aus D2 nicht entgegen. Es wäre weiter für den Fachmann offensichtlich, einen neu einzuspielenden Schlüssel in gleicher Weise wie neu einzuspielende Software durch ei ne elektronische Signatur des Trust-Centers zu schützen, und zwar offenbar mittels des zu diesem Zeitpunkt (noch) gültigen Schlüssels.

11.4 D2 enthält keinerlei Details darüber, wie ein Über schrei ben des Bootsektors auszugestalten ist. Daher würde der Fachmann im Stand der Technik nach bekannten Lösungen suchen.

11.5 Dokument D1 offenbart ein Verfahren zur Änderung von Daten in einem nicht-flüchtigen, elektrisch löschbaren Speicher, z. B. in einem Flash-Speicher (Abs. 1 und 12).

11.6 Die Kammer sieht es als eine fachübliche Maßnahme an, den Bootbereich in einem Flash-Speicher unterzubringen (vgl. auch die gleichlautende Bemerkung in D3, Sp. 1, Zn. 40-42). Weil sich D1 darüber hinaus wie D2 eindeutig auf Fahrzeugelektronik bezieht (vgl. insbes. Abs. 11) würde der Fachmann nach Ansicht der Kammer erkennen, dass D1 eine Lösung für die gestellte Aufgabe liefert.

11.7 D1 offenbart die Verwendung von Änderungsroutinen (also von "Nachladesoftware"), die über den Bus empfangen (also ihrerseits "geladen") wird (s. Abs. 14) und im RAM ge speichert wird. Bei Anwendung des Verfahrens aus D1 auf D2 kommen die Änderungsroutinen somit außerhalb des Bootsektors zu liegen.

11.8 Da die elektronische Signatur der Nachladesoftware gemäß Anspruch 1 nur optional ist, während die elektronische Signatur des Schlüssels (s. Punkt 11.3) und somit der Update soft ware (vgl. Punkt 5) offensichtlich ist, ergibt sich Anspruch 1 des Hauptantrags auf nahe lie gen de Weise aus D2 in Kombi na tion mit D1. Da rü ber hinaus hält es die Kammer im Rahmen von D2 aber auch für naheliegend, dass die Ände rungs rou tinen (die Nach lade software) selbst aus denselben Sicher heits grün den wie die Updatesoftware elektro nisch signiert werden.

11.9 In summa hält die Kammer den Gegenstand von Anspruch 1 des Hauptantrags für nicht erfinderisch, Artikel 56 EPÜ 1973.

Hilfsantrag

12. Anspruch 1 des Hilfsantrags fordert, dass "zusätzlich zum Ersetzen des ... Signaturschlüssels eine Veränderung des Sicherheitsmechanismus erfolgt" und dass die Update software (vgl. Punkt 6) bzw. die Nachladesoftware "auf diesen Sicherheitsmechanismus ausgerichtet sind".

12.1 Nach Ansicht der Kammer ergibt sich die Notwendigkeit, ei nen einmal gewählten "Sicherheitsmechanismus" zu ändern, umständehalber aus unterschiedlichen, darunter auch nicht-technischen Gründen. Länge re Schlüssel können z. B. gesetzlich vorgeschrieben wer den oder aus Sicher heits gründen angesichts tech ni scher Fortschritte not wen dig werden. Dasselbe gilt für die Wahl eines sym me tri schen oder asymme tri schen Verschlüsselungsverfah rens.

12.2 Es ist offensichtlich wünschenswert, solche Än de rungen so durchzuführen, ohne Hardwarekomponenten aus tauschen zu müssen.

12.3 Unter dieser Annahme hält es die Kammer für unmittelbar nahe lie gend, das aus D2 bekannten Verfahren (vgl. Abb. 4) auch zum Austausch von Sicherheitssoftware einzusetzen.

12.4 Damit ergibt für die Kam mer auch der Gegenstand von Anspruch 1 des Hilfsantrags in offen sicht li cher Weise aus D2 in Verbindung mit D1, Artikel 56 EPÜ 1973.

ENTSCHEIDUNGSFORMEL

Aus diesen Gründen wird entschieden:

Die Beschwerde wird zurückgewiesen.

The Registrar The Chairman:

B. Atienza Vivancos D. H. Rees

Quick Navigation