Rechtsprechung / Beschwerdekammern des Europäischen Patentamts / Technische Beschwerdekammer 3.5.06 / 2012

Beschwerdekammern des Europäischen Patentamts Entscheidung vom 12.07.2012 – T 2205/08

Technische Beschwerdekammer 3.5.06 · ECLI:EP:BA:2012:T220508.20120712

EuroparechtEU / InternationalVolltext

Als PDF speichern

Aktenzeichen: T 2205/08 - 3.5.06

E N T S C H E I D U N G

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:

Vorsitzender:

Mitglieder:

D. H. Rees M. Müller W. Sekretaruk

Sachverhalt und Anträge

I. Die Beschwerde richtet sich gegen die Entscheidung der Prüfungsabteilung, zugestellt mit Schreiben vom 11. Juli 2008, die europäische Patentanmeldung 04730255.9 zurückzuweisen. Die Entscheidung erging "nach Aktenlage" unter Verweis 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 Kombination 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 Ansprüche 1-11 gemäß Haupt- und Hilfsantrag vor, und beantragte die Erteilung eines Patents auf deren Grundlage.

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 gegenü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 voraussichtlich zu bestätigen sei.

IV. Am 14. Juni 2012 teilte die Beschwerdeführerin ohne Ausführungen zur Sache mit, dass sie ihren Antrag auf mündliche Verhandlung zurückziehe und eine Entscheidung nach Aktenlage beantrage. Nach Interpretation der Kammer verzichtet die Beschwerdeführerin mit diesem Antrag auf weitere schriftliche oder mündliche Stellungnahmen in der Sache und beantragt den Erlass einer Entscheidung aufgrund der aktenkundigen Argumente. Die anberaumte mündliche 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 Zertifikatbasiertes 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 Software in einem Fahrzeug und dabei insbesondere auf ein Verfahren zum "Nachladen" (und Installieren) einer "Updatesoftware" im Bootsektor eines programmierbaren Steuergeräts. Das Nachladen besorgt eine spezielle "Nachladesoftware". Sowohl Nachlade- als auch Updatesoftware werden außerhalb des Bootsektors gespeichert, und mindestens eine von beiden wird digital signiert und im Steuergerät überprüft. Die Updatesoftware kann sich beschreibungs- 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 bemängelten Einwand der Prüfungsabteilung unter Punkt 3.2 des Prüfungsbescheids vom 22. Februar 2008 (vgl. Beschwerdebegründung, Punkt 2.1; S. 2, letzter Abs. und s. 3, 1. Abs.) versteht die Kammer wie folgt: Die Beschwerdeführerin hatte am 19. Februar 2007 einen geänderten Anspruch 1 eingereicht, den Anspruchssatz im übrigen 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 ursprünglichen Ansprüchen 2-15 kombiniert werden sollte. Vor diesem Hintergrund stellt der bemängelte Einwand nur fest, dass die ursprünglichen Ansprüche 3-4 gegenüber dem neuen Anspruch 1 redundant sind. Durch die Eingabe vollständiger Anspruchssätze mit der Beschwerdebegründung hat sich dieser Einwand erledigt.

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

5. Anspruch 1 beider Anträge formuliert, dass das Ausführen der Nachladesoftware einerseits die Updatesoftware installiert und andererseits den (zweiten) Signaturschlüssel ersetzt. Der Anspruchswortlaut lässt das Verhältnis zwischen Updatesoftware und Signaturschlüssel offen. Aus der Beschreibung und insbesondere dem bevorzugten Ausführungsbeispiel (vgl. S. 6 ff.) ergibt sich für den Fachmann eindeutig, dass ausschließlicher "Gegenstand der Aktualisierung" der Schlüssel sein und dass somit der beanspruchte Terminus "Updatesoftware" den "Signaturschlüssel" subsumieren kann (s. auch S. 7, Zn. 14-19, in dem der verschlüsselte Kryptoschlüssel als verschlüsselte Updatesoftware 111 bezeichnet wird). Anspruch 1 lässt hingegen zu, dass neben dem Signaturschlüssel immer eine von diesem verschiedene aber im übrigen undefinierte "Updatesoftware" zu installieren ist. Nach Auffassung der Kammer steht die Beschreibung somit im Widerspruch zu Anspruch 1 beider 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 nachzuladende Software". Die Kammer interpretiert diesen Begriff, wie im Ladungszusatz erwähnt, dass er sich auf die sonst im Anspruch 1 aufgeführte "Updatesoftware" handelt.

Anspruch 1 des Hilfsantrags fordert weiter, dass "die nachzuladende Software bzw. Nachladesoftware auf [einen zu ändernden] Sicherheitsmechanismus ausgerichtet" sein sollen. Während es dem Fachmann ohne Weiteres ersichtlich ist, dass sich eine Änderung des Sicherheitsmechanismus in der nachzuladenden Software niederschlägt, ist es im Allgemeinen unklar, inwieweit die Nachladesoftware selbst darauf "ausgerichtet" sein soll - wenn man von trivialen Überlegungen z. B. darüber absieht, in welchen Speicherbereich die geänderte Software zu laden ist.

Daher ist die genannte Formulierung 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 erfinderischen Tätigkeit Stellung zu nehmen.

8. Die Prüfungsabteilung ging bei ihrer Bewertung der erfinderischen 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 Ausgangspunkt 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 Einspielen der Software im Kraftfahrzeug überprüft wird. Nur wenn diese Überprüfung erfolgreich war, wird die Software als unverändert akzeptiert und im Steuergerät des Kraftfahrzeugs auch betrieben (vgl. Sp. 7, Zn. 4-45).

Der zur Überprüfung verwendete Schlüssel wird im BootSektor des Steuergeräts gespeichert, weil er dort besonders gut gegen Manipulationen geschützt ist (Sp. 3, Zn. 3-13). Die Existenz einer entsprechenden "Nachladesoftware", die in D2 nicht ausdrücklich diskutiert wird, betrachtet 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 signiert.

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 geworden ist und daher das Schlüsselpaar ausgetauscht werden muss.

10.2 Dass die "Nachladesoftware" jeweils neu geladen wird, hat unter anderem die Wirkung, dass der benötigte Speicherplatz nach erfolgtem Update wieder freigegeben werden kann.

10.3 Nach Ansicht der Kammer lösen die Unterschiede a) und b) gegenüber D2 die Aufgabe, die Sicherheit in einer speicherplatzsparenden Weise zu erhöhen.

11. Es ist für den Fachmann elementar, dass die Sicherheit von Verschlüsselungs- und Signaturverfahren unter anderem 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 überschrieben" werden (Sp. 3, Z. 6). Für die Kammer bedeutet diese Formulierung, dass ein solches Überschreiben nicht grundsätzlich unmöglich ist, wenn auch u. U. besondere Maßnahmen dafür nötig sind.

11.3 Wenn der Fachmann also Bedarf hat, den Schlüssel auszutauschen, 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 eine 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 Überschreiben 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 gespeichert 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 Updatesoftware (vgl. Punkt 5) offensichtlich ist, ergibt sich Anspruch 1 des Hauptantrags auf naheliegende Weise aus D2 in Kombination mit D1. Darüber hinaus hält es die Kammer im Rahmen von D2 aber auch für naheliegend, dass die Änderungsroutinen (die Nachladesoftware) selbst aus denselben Sicherheitsgründen wie die Updatesoftware elektronisch 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 Updatesoftware (vgl. Punkt 6) bzw. die Nachladesoftware "auf diesen Sicherheitsmechanismus ausgerichtet sind".

12.1 Nach Ansicht der Kammer ergibt sich die Notwendigkeit, einen einmal gewählten "Sicherheitsmechanismus" zu ändern, umständehalber aus unterschiedlichen, darunter auch nicht-technischen Gründen. Längere Schlüssel können z. B. gesetzlich vorgeschrieben werden oder aus Sicherheitsgründen angesichts technischer Fortschritte notwendig werden. Dasselbe gilt für die Wahl eines symmetrischen oder asymmetrischen Verschlüsselungsverfahrens.

12.2 Es ist offensichtlich wünschenswert, solche Änderungen so durchzuführen, ohne Hardwarekomponenten austauschen zu müssen.

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

12.4 Damit ergibt für die Kammer auch der Gegenstand von Anspruch 1 des Hilfsantrags in offensichtlicher 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