T 0336/08 (Software-Authentifikation/BMW) of 28.7.2011

European Case Law Identifier: ECLI:EP:BA:2011:T033608.20110728
Datum der Entscheidung: 28 Juli 2011
Aktenzeichen: T 0336/08
Anmeldenummer: 04740198.9
IPC-Klasse: G06F 1/00
Verfahrenssprache: DE
Verteilung: D
Download und weitere Informationen:
Text der Entscheidung in DE (PDF, 25.984K)
Alle Dokumente zum Beschwerdeverfahren finden Sie im Register
Bibliografische Daten verfügbar in: DE
Fassungen: Unpublished
Bezeichnung der Anmeldung: Verfahren zur Authentifikation von einer insbesondere in ein Steuergerät eines Kraftfahrzeugs ladbaren Softwarekomponente
Name des Anmelders: Bayerische Motoren Werke Aktiengesellschaft
Name des Einsprechenden: -
Kammer: 3.5.06
Leitsatz: -
Relevante Rechtsnormen:
European Patent Convention 1973 Art 56
Schlagwörter: Erfinderische Tätigkeit (alle Anträge) - nein
Orientierungssatz:

-

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

Sachverhalt und Anträge

I. Die Beschwerde richtet sich gegen die Entscheidung der Prüfungsabteilung, zugestellt mit Schreiben vom 26. November 2007, die europäische Patentanmeldung 04740198.9 zurückzuweisen.

II. Die Entscheidung erging "nach Aktenlage" durch Verweis auf den Prüfungsbescheid vom 22. Juni 2007, der seiner seits mit Bezug auf

D1: DE 101 40 721 A

ausführt, dass der beanspruchte Gegenstand gegenüber D1 nicht die erforderliche erfinderische Tätigkeit aufweise.

III. Beschwerde gegen diese Entscheidung ging am 3. Dezember 2007 ein, und die Beschwerdegebühr wurde am selben Tag ent richtet. Eine Beschwerdebegründung ging am 25. Januar 2008 ein.

IV. Es wird beantragt, die angefochtene Entschei dung aufzu heben und ein Patent auf Basis der Ansprüche 1-9 in der ursprünglichen Fassung zu erteilen, oder hilfs weise auf der Basis von Ansprüchen 1-8 bzw. 1-7 gemäß zweier Hilfs anträge, die mit der Beschwerdebe grün dung eingereicht wurden. Eine mündliche Verhandlung wur de beantragt für den Fall, dass dem Hauptantrag nicht statt gege ben werden könnte.

V. Anspruch 1 gemäß Hauptantrag lautet:

"Verfahren zur Authentifikation eines von einem Software-Bereitsteller bereitgestellten Softwarepaketes, welche [sic] eine in ein Endgerät ladbare Softwarekomponente enthält, wobei die Softwarekomponente mit einem Authentifikationsanhang versehen wird, welcher zur Durchführung einer Authentizitätsprüfung in dem Endgerät überprüft wird, wobei eine übergeordnete Authentisierungsstelle vorgesehen ist, welche zur Erhöhung der Sicherheit authentisierende Maßnahmen an dem Softwarepaket durchführt, dadurch gekennzeichnet, dass die von der übergeordneten Authentisierungsstelle (15,16) durchgeführten Maßnahmen nach erfolgreicher Prüfung des von dem Software-Bereitsteller (11, 12) bereitgestellten und neben der Softwarekomponente (SW, FSC) einen ersten Authentifikationsanhang (XZ) umfassenden Softwarepaketes (13, 14) das Versehen des Softwarepaketes (13, 14; 18,19) mit wenigstens einem zweiten Authentifikationsanhang (IZ) an Stelle des ersten Authentifikationsanhangs (XZ) umfassen."

Gegenüber Anspruch 1 des Hauptantrags ist Anspruch 1 des 1. Hilfsantrags am Ende durch das folgende Merkmal ergänzt:

"wobei die Prüfung des Softwarepakets (13, 14) durch die übergeordnete Authentisierungsstelle (15, 16) eine Prüfung der aktuellen Berechtigung des Software-Bereitstellers (11, 12) zum Bereitstellen von Softwarekomponenten (SW, FSC) umfasst."

Anspruch 1 des 2. Hilfsantrags enthält demgegenüber am Ende ein weiteres Merkmale wie folgt:

"und die Softwarekomponenten Programmcodes (SW) und/oder Freischaltcodes (FSC) für im Endgerät installierte Programmcodes enthalten."

VI. Mit einer Ladung zur mündlichen Verhandlung informierte die Kammer die Beschwerdeführerin über ihre vorläufige Meinung. Die Kammer diskutierte die unterschiedlichen Interpretationen des Dokuments D1, die den Argumenten der Prüfungsabteilung und der Beschwerdeführerin zugrunde lagen, und vermutete terminologisch bedingte Missverständnisse. Um diese zu vermeiden, stützte die Kammer ihre Analyse der erfinderischen Tätigkeit nicht auf D1 sondern in analoger Weise auf D2, dem im inter na tio nalen Recherchenbericht zweitgenannten Dokument

D2: US2002/0120856 A1

VII. Mit Schreiben vom 29. Juni 2011 teilte die Beschwerde füh rerin mit, dass sie an der mündlichen Verhandlung nicht teilnehmen würde. Gleichzeitig zog sie ihren Antrag auf mündliche Verhandlung zurück und beantragte Fort setzung des Verfahrens ins schriftlicher Form. Die Kammer teilte daraufhin der Beschwerdeführerin mit, dass der Termin zur mündlichen Verhandlung aufrecht erhalten bliebe.

VIII. Die mündliche Verhandlung fand wie angekündigt in Abwe senheit der Beschwerdeführerin statt. Am Ende verkündete der Vorsitzende die Entscheidung der Kammer.

Entscheidungsgründe

1. Die Beschwerde ist zulässig (vgl. Punkte I und III).

2. Die Anmeldung befasst sich mit dem Problem sicher zu stellen, dass keine unberechtigten und/oder schädlichen Softwarekomponenten in ein softwaregesteuertes Endgerät geladen werden (Beschreibung, S. 1, Zn. 15-17).

Hauptantrag

3. Die Kammer betrachtet D2 als einen im Sinne des Aufgabe-Lösungs-Ansatzes geeigneten Aus gangs punkt für die Analyse der erfinderischen Tätigkeit.

3.1 D2 offenbart ein Verfahren zur Authentifikation eines Softwarepakets, welches eine in ein Endgerät ladbare Softwarekomponente enthält (vgl. Zusammenfassung, 1. Satz; Abs. 50, 1. Satz; Abb. 4). Die Software wird gemäß D2 von einem Händler bereitgestellt (Abs. 50, loc. cit.). Der Händler sendet die Software an eine übergeordnete Authentisierungsstelle, die die Softwarekomponente mit einem Authentifikationsanhang versieht (und somit eine "authentisierende Maßnahme" durchführt), welcher wiederum in dem Endgerät überprüft wird (Abs. 50, letzter und vorletzter Satz; Abb. 4, Nr. 104, 106 und 108).

3.2 Im Unterschied zu Anspruch 1 offenbart D2 nicht,

a) dass der Händler (als Software-Bereitsteller) die Software mit einem ersten Authentifikationsanhang versieht,

b) der vom Trust Center (als übergeordnete Authenti sie rungsstelle) geprüft wird, und

c) dass nach erfolgreicher Prüfung die Software mit dem genannten Authentifikationsanhang versehen wird, der als "zweiter" nun "an Stelle des" ersten tritt.

3.3 Im Endgerät ist gemäß D2 nur die Prüfung der Signatur des Trust Centers (der "zweite" Authentifikationsanhang) vorgesehen und die genannten Unterschiede ändern diese Situation nicht (vgl. insbesondere Merkmal c).

3.4 Nach Ansicht der Kammer lösen die Unterschiede a-c somit die Aufgabe, die Sicherheit des Verfahrens nach D2 zu stei gern, ohne dabei die Funktion des Endgerät zu verändern.

3.5 Das Trust Center gemäß D2 ist eine von den Händlern im allgemeinen administrativ und räumlich verschiedene Ein richtung. D2 offenbart, dass der Händler die zu signie rende Software an das Trust Center "sendet", lässt aber die Natur dieser Übertragung offen. Es erscheint der Kammer unter diesen Umständen aus fachmännischer Sicht offensichtlich, für die Übertragung ein öffentliches Datennetz - bspw. das Internet - zu wählen.

3.6 D2 lässt offen, was genau geschieht, bevor und damit das Trust Center die bereitgestellte Software signieren kann. Es ist aber nach Ansicht der Kammer für den Fachmann offen sichtlich - wie auch auf dem Gebiet der Krypto-grafie wohlbekannt - dass die Zertifizierungsstelle die Vertrauenswürdigkeit des Zertifizierungsauftrags und der zu zertifizierenden Informationen sicherstellen muss. In praxi geschieht das je nach Umständen und Sicherheits-anforderungen auf unterschiedliche Weise.

3.7 Es ist allgemein bekannt, dass Daten, die über das Inter net (oder andere öffentliche Datennetze) übertragen werden, manipuliert werden können und es ist fachüblich, diesem Problem zum Beispiel dadurch zu begegnen, dass die Daten vom Sender kryptografisch signiert werden (vgl. auch D2, Abs. 15).

3.8 Somit ist es nach Ansicht der Kammer naheliegend, dass der Händler die zu zertifizierende Software vor Über tragung an das Trust Center mit einer digitalen Signatur versieht, die vom Trust Center geprüft wird. Eine solche Signatur stellt einen (ersten) Authenti fi zierungs anhang gemäß Anspruch 1 dar.

3.9 Das Endgerät aus D2 prüft nur das vom Trust Center aus-gestellte Zertifikat. Da nach der obigen Analyse die Signatur des Händlers nur zur Sicherung der Datenüber-tragung an das Trust Center dient, gibt es auch keinen Anlass, das Endgerät in dieser Hinsicht zu ändern. Insofern tritt die Signatur des Trust Centers "an die Stelle" der Signatur des Händlers.

3.10 Ob die Signatur des Händlers dabei an das Endgerät übertragen und dort ignoriert wird, oder aber ob es vom Trust Center entfernt wird, ist dabei unerheblich. Die Entscheidung, das eine oder das andere zu tun, wird der Fachmann durch Abwägung von Aufwand und Nutzen (etwa Programmierungsaufwand vs. Speicherbedarf im Endgerät) auf naheliegende Weise treffen.

3.11 Die Kammer kommt daher zu dem Ergebnis, dass Anspruch 1 des Hauptantrags nicht erfinderisch gegenüber D2 ist, entgegen Artikel 52 (1) EPÜ und Artikel 56 EPÜ 1973.

Hilfsantrag 1

4. Im Vergleich zum Hauptantrag legt Anspruch 1 zusätzlich fest, dass die übergeordnete Authentisierungsstelle über prüft, ob der Software-Bereitstellers derzeit berechtigt ist Software bereitzustellen.

4.1 Nach Ansicht der Kammer ist eine solche Prüfung ein unmittelbar naheliegender Aspekt der Prüfung auf Vertrauenswürdigkeit des Zertifizierungsauftrags.

4.2 Dass dieser Aspekt überhaupt zu prüfen ist, mag aus rein geschäftlichen Erwägungen folgen: Zum Beispiel kann der Vertrag zwischen dem Fahrzeughersteller und einem Soft ware-Zulieferer nur auf bestimmte Software beschränkt oder sogar ausgelaufen sein, und es wäre dann offen sicht lich wünschens wert, die Einhaltung dieser ver trag lichen Situation mit technischen Mitteln sicherzu stellen.

4.3 Anspruch 1 lässt offen, wie die beanspruchte Berech ti gungsprüfung ausgestaltet ist. Diese aber überhaupt zu im ple mentieren, stellt den Fachmann nach Ansicht der Kammer vor keinerlei Schwierigkeiten: Eine nahelie gende Implementierung wäre zum Bei spiel, den Händler anhand der oben angenommenen krypto grafischen Signatur zu identi f i zieren und dessen Berechtigungen in einer ein schlä gi gen Datenbank nachzuschlagen.

4.4 Die Kammer kommt daher zu dem Ergebnis, dass auch Anspruch 1 des 1. Hilfsantrags nicht erfinderisch gegenüber D2 ist.

Hilfsantrag 2

5. Gegenüber dem 1. Hilfsantrag legt Anspruch 1 zusätzlich fest, dass "die Softwarekomponenten Programmcodes und/oder Freischaltcodes für im Endgerät installierte Programm codes enthalten" können.

5.1 Die erste Option ("Programmcodes") ist schon durch die Analyse des Hauptantrags abgedeckt, da D2 klar von Software und somit von "Programmcodes" spricht (Abs. 50). Schon aus diesem Grund folgt, dass Anspruch 1 des 2. Hilfsantrags keine erfinderische Tätigkeit aufweist.

5.2 Was die zweite Option angeht, so ist die Verwendung von Freischaltcodes zur Aktivierung schon vorinstallierter Software per se bekannt. Unstrittig aber ist zudem, dass D1 die Verwendung solcher Freischaltcodes im relevanten Kontext offenbart (vgl. u. a. Beschreibung, S. 1, Z. 28; sowie D1, Abb. 1, linke Seite). Um im Rahmen von D2 die Möglichkeit vorzusehen, dass der Händler den Kunden wunsch durch bloßes Freischalten einer vorinstallierten Funktion befriedigen kann, liegt es nahe, das Zertifi zie rungs verfahren unverändert von Programmcodes auf Freischaltcodes zu übertragen.

5.3 Dementsprechend weist auch Anspruch 1 des 2. Hilfsan trags keine erfinderische Tätigkeit gegenüber D2 auf, weder im Lichte des üblichen Fachwissens noch im Lichte von D1.

Zusammenfassung

6. Da somit kein gewährbarer Antrag vorliegt, ist die Beschwerde zurückzuweisen.

ENTSCHEIDUNGSFORMEL

Aus diesen Gründen wird entschieden:

Die Beschwerde wird zurückgewiesen.

Quick Navigation