T 0193/15 (Anpassbare Chipkarte/SWISSCOM) of 25.10.2018

Sachverhalt und Anträge

I. Gegen die Entscheidung der Einspruchsabteilung, das europäische Patent Nr. 1 230 780 zu widerrufen, legte die Patentinhaberin Beschwerde ein. Die Entscheidung wurde damit begründet, dass der Gegenstand des Anspruchs 1 in der erteilten Fassung gemäß dem Hauptantrag und in den Fassungen gemäß den Hilfsanträgen 1 und 3 nicht neu ist und dass der Gegenstand des Anspruchs 1 des Hilfsantrags 4 nicht auf einer erfinderischen Tätigkeit beruht. Weitere Hilfsanträge wurden zurückgenommen.

II. Mit ihrer Beschwerdebegründung beantragte die Patentinhaberin (Beschwerdeführerin), die Entscheidung der Einspruchsabteilung aufzuheben und das Patent in geänderter Fassung auf der Grundlage der Ansprüche eines Hauptantrags, hilfsweise eines der Hilfsanträge I bis III aufrecht zu erhalten, wobei alle vorgenannte Anträge mit der Beschwerdebegründung eingereicht wurden.

III. Die Einsprechende (Beschwerdegegnerin) beantragte mit ihrer Erwiderung, die Beschwerde zurückzuweisen.

IV. Beide Parteien beantragten hilfsweise eine mündliche Verhandlung.

V. In einer der Ladung zur mündlichen Verhandlung beigefügten Mitteilung gemäß Artikel 15 (1) VOBK nahm die Kammer zum Sachverhalt, unter anderem zu der Frage, ob der Gegenstand des Anspruchs 1 der vorliegenden Anträge neu ist beziehungsweise auf einer erfinderischen Tätigkeit beruht, Stellung.

VI. Mit Schreiben vom 19. Oktober 2018 teilte die Patentinhaberin mit, dass sie nicht an der mündlichen Verhandlung teilnehmen werde und dass sie ihre vorliegenden Anträge aufrechterhält.

VII. Am 25. Oktober 2018 fand in Abwesenheit der Patentinhaberin eine mündliche Verhandlung vor der Kammer statt.

Die Beschwerdeführerin (Patentinhaberin) beantragte schriftlich, die angefochtene Entscheidung aufzuheben und das Patent in geänderter Fassung auf der Grundlage der Ansprüche eines Hauptantrags, hilfsweise eines der Hilfsanträge I bis III aufrechtzuerhalten, alle Anträge wie mit der Beschwerdebegründung eingereicht.

Die Beschwerdegegnerin (Einsprechende) beantragte, die Beschwerde zurückzuweisen.

Am Ende der Verhandlung verkündete der Vorsitzende die Entscheidung der Kammer.

VIII. Das folgende Dokument, auf das in der angefochtenen Entscheidung Bezug genommen wurde, ist für die vorliegende Entscheidung relevant:

D4: Wolfgang Rankl/Wolfgang Effing: "Handbuch der

Chipkarten", März 1999, Seiten 252 bis 254,

281 bis 286, 297 und 392 bis 397,

ISBN: 978-3-446-21115-5.

IX. Der unabhängige Anspruch 1 gemäß dem Hauptantrag lautet wie folgt:

"Chipkarte (5), die über eine logische Schnittstelle (4) mit einer externen Vorrichtung (3) kommunizieren kann,

wobei standardisierte APDU-Dataeinheiten (20) für diese Kommunikation definiert sind,

wobei die Chipkarte über ein ROM und über ein EEPROM verfügt,

wobei verschiedene Komponenten (F1, F2, ..G1, G2..) vorgesehen sind, die verschiedene Funktionalitäten zur Verfügung stellen,

wobei ein APDU-Handler (511, 512) vorgesehen ist, um zu bestimmen, welche der verschiedenen Komponenten abgerufen wird, wenn eine bestimmte der standardisierten APDU-Dataeinheiten (20) über die benannte logische Schnittstelle (4) empfangen wird, und um einen mit der bestimmten standardisierten APDU-Dataeinheit empfangenen Befehl an eine zuständige der verschiedenen Komponenten (F1, F2, ..., G1, G2, ...) in der Chipkarte (5) weiterzuleiten, wobei die zuständige der verschiedenen Komponenten (F1, F2, ..., G1, G2, ...) den Befehl ausführen kann,

dadurch gekennzeichnet, dass der APDU-Handler (511, 512) so im benannten EEPROM abgelegt ist, dass der APDU-Handler (511, 512) so geändert werden kann, dass der APDU-Handler (511, 512) auf eine Funktionalität der Chipkarte (5) zugreifen kann, für welche eine APDU-Dataeinheit (20) erst nach der Herstellung der Chipkarte standardisiert worden ist."

X. Anspruch 1 der beiden Hilfsanträge I und II unterscheidet sich von Anspruch 1 des Hauptantrags dadurch, dass das Bezugszeichen für den "APDU-Handler" an vier Stellen von "(511, 512)" in "(511)" geändert, im fünften Absatz "welche der verschiedenen Komponenten" durch "welche Komponente" ersetzt, und am Ende folgender Absatz hinzugefügt ist:

"wobei ein Test-Modul (510) vorgesehen ist, das derart ausgeführt ist, dass es bestimmte empfangene APDU-Dataeinheiten an einen konventionellen APDU-Handler (500) im ROM (50) und andere APDU Dataeinheiten (20) oder von dem konventionellen APDU-Handler (500) nicht bearbeitbare APDU-Dataeinheiten (20) an den APDU-Handler (511) im EEPROM weiterleitet"

XI. Anspruch 1 des Hilfsantrags III unterscheidet sich von Anspruch 1 der Hilfsanträge I und II dadurch, dass vor dem Absatz beginnend mit "wobei ein Test-Modul (510)" folgende Formulierung hinzugefügt ist:

"wobei eine der verschiedenen Komponenten (G3) im ROM abgelegt ist und eine der verschiedenen Funktionalitäten zur Verfügung stellt, wobei der APDU- Handler (511) ausgebildet ist, die im ROM abgelegte Komponente (G3), die für eine der in dem APDU-Handler empfangenen APDU-Dataeinheiten vorgesehen ist, aufzurufen;"

Entscheidungsgründe

1. Hauptantrag - Neuheit (Artikel 52 (1) und 54 EPÜ)

1.1 Anspruch 1 richtet sich im Wesentlichen auf eine Chipkarte mit einem ROM, einem EEPROM und einem APDU-Handler, der bestimmt, welche der verschiedenen Funktionalitäten bereitstellenden Komponenten der Chipkarte aufgerufen wird, wenn eine bestimmte von standardisierten APDU-Dataeinheiten empfangen wird. Ein mit der empfangenen APDU-Dataeinheit empfangener Befehl wird an die zuständige Komponente, die den Befehl ausführen kann, weitergeleitet.

Anspruch 1 enthält das Merkmal, dass der APDU-Handler so im EEPROM abgelegt ist, dass er so geändert werden kann, dass er auf eine Funktionalität der Chipkarte zugreifen kann, für welche eine APDU-Dataeinheit erst nach Herstellung der Chipkarte standardisiert worden ist. Die Kammer merkt an, dass dadurch nicht ausgeschlossen ist, dass Teile des APDU-Handlers ausserhalb des EEPROM abgelegt sind und dass Anspruch 1 somit nicht auf Fälle beschränkt ist, in denen ein APDU-Handler ausschließlich im EEPROM abgelegt ist.

1.2 D4 offenbart auf Seite 392, Punkt 7 "Kommandos von Chipkarten", dass die Kommunikation zwischen einer Chipkarte und einem Terminal immer im Rahmen eines festgelegten Übertragungsprotokolls abläuft, wobei Daten, eingebettet in APDUs (Application Protocol Data Unit), zur Chipkarte hin und wieder zurückgesendet werden. D4 offenbart an dieser Stelle weiter, dass die APDUs die Befehle sind, die vom Terminal an die Chipkarte gesendet werden, und dass es eine Vielzahl von Kommandos gibt. Die Kammer ist dabei der Ansicht, dass die Übertragung zwischen der Chipkarte und dem Terminal auf beiden Seiten eine logische Schnittstelle impliziert und dass weiter die APDUs implizit standardisiert sein müssen, da sie zum einen gemäß einem festgelegten Protokoll übertragen werden und zum anderen Kommandos beziehungsweise Befehle übertragen, für die notwendigerweise eine entsprechende Funktionalität definiert sein muss, um mit einem Befehl eine bestimmte Aktion der Chipkarte auslösen zu können.

Weiter merkt die Kammer an, dass bei programmgesteuerten Vorrichtungen wie Chipkarten die verschiedenen Funktionalitäten in Form von entsprechenden Programmcodes implementiert sind, die jeweils die von einem Kommando aufzurufende Funktionalität bereitstellen und die in der vorliegenden Patentschrift als Komponenten bezeichnet werden (Spalte 3, Zeile 44 bis Spalte 4, Zeile 4 und Spalte 4, Zeilen 36 bis 46).

D4 verweist im Rahmen der Beschreibung eines bestimmten Chipkarten-Betriebssystems und eines darin enthaltenen Kommandointerpreter auch auf andere, in der Praxis gebräuchliche Kommandointerpreter (Seite 297, Kopfzeile und Abschnitt "Kommandointerpreter"). Kommandointerpreter dienen allgemein der Bearbeitung beziehungsweise Decodierung von erhaltenen Kommandos und rufen dazu den entsprechenden Programmcode auf.

Da die Kommandos in APDUs übertragen werden (vgl. D4, Seite 392), bearbeiten Kommandointerpreter APDUs und sind somit APDU-Handler. Weiter wird ausgeführt, dass die in der Praxis üblichen Kommandointerpreter selbst in einem ROM untergebracht sind und dass die Möglichkeit vorhanden ist, bei der Komplettierung des Betriebssystems Programmcode in einem EEPROM nachzuladen (Seite 297, zweiter Absatz). Dazu wird eine Sprungtabelle verwendet die im EEPROM abgelegt ist und somit änderbar ist. Da der Kommandointerpreter im ROM die Sprungtabelle im EEPROM bei der Decodierung der empfangenen Kommandos mit einbezieht, ist die Kammer der Ansicht, dass die Sprungtabelle Teil des Kommandointerpeters ist. Die D4 offenbart auf Seite 297, zweiter Absatz, weiter, dass diese Sprungtabelle bei Bedarf auch ergänzt wird.

1.3 Unter Verwendung des Wortlauts des Anspruchs 1 des Hauptantrags offenbart D4 somit eine Chipkarte, die über eine logische Schnittstelle mit einer externen Vorrichtung (Terminal) kommunizieren kann,

wobei standardisierte APDU-Dataeinheiten für diese Kommunikation definiert sind (Befehle, eingebettet in APDUs, Seite 392),

wobei die Chipkarte über ein ROM und über ein EEPROM verfügt (in der Praxis gebräuchlicher Kommandointerpreter, Seite 297),

wobei verschiedene Komponenten vorgesehen sind, die verschiedene Funktionalitäten zur Verfügung stellen (Softwarecodes für die verschiedenen Kommandos, Seite 392),

wobei ein APDU-Handler (in der Praxis gebräuchlicher Kommandointerpreter einschließlich Sprungtabelle im EEPROM) vorgesehen ist, um zu bestimmen, welche der verschiedenen Komponenten (Programmcodes) abgerufen wird, wenn eine bestimmte der standardisierten APDU-Dataeinheiten über die benannte logische Schnittstelle empfangen wird, und um einen mit der bestimmten standardisierten APDU-Dataeinheit empfangenen Befehl an eine zuständige der verschiedenen Komponenten in der Chipkarte weiterzuleiten, wobei die zuständige der verschiedenen Komponenten den Befehl ausführen kann (implizit Funktion der Programmcodes), und

wobei der APDU-Handler so im benannten EEPROM abgelegt ist (Sprungtabelle im EEPROM), dass der APDU-Handler so geändert werden kann, dass der APDU-Handler auf eine Funktionalität der Chipkarte (nachgeladener Programmcode im EEPROM) zugreifen kann, für welche eine APDU-Dataeinheit erst nach der Herstellung der Chipkarte standardisiert worden ist (APDU mit dem Befehl zum Aufruf des nachgeladenen Programmcodes).

1.4 Argumente der Beschwerdeführerin

Die Beschwerdeführerin argumentierte, dass D4 eine Vielzahl von Ausführungsbeispielen im Rahmen eines Buchs offenbare, die im Rahmen der Neuheit nicht vermischt werden dürfen.

Die Kammer merkt dagegen an, dass Druckschrift D4 eine Sammlung von Auszügen aus einem Lehrbuch der Chipkartentechnologie ist, das naturgemäß nicht einzelne Ausführungsbeispiele einer Chipkarte vollständig beschreibt, sondern jeweils technische Teilbereiche separat behandelt. Dies widerspricht aber nicht grundsätzlich einer Offenbarung von Details verschiedener Teilbereiche als Kombination, sofern keine gegenteiligen Gründe genannt werden, die aber nach Ansicht der Kammer nicht vorliegen und von der Beschwerdeführerin auch nicht vorgebracht wurden. Die D4 offenbart im Gegenteil in Bezug auf die Kommandos von Chipkarten (Seite 392) sogar, dass die Kommunikation immer im Rahmen eines Übertragungsprotokolls abläuft, und nimmt bei den nachfolgend offenbarten Merkmalen zur Übertragung von Kommandos in APDUs auch Bezug auf dieses Protokoll. Die Kammer ist daher der Ansicht, dass die Merkmale auf Seite 392 auch mit Gültigkeit für eine Chipkarte mit einem auf Seite 297 beschriebenen Kommandointerpreter offenbart sind.

Die Beschwerdeführerin argumentierte außerdem, dass die Sprungtabelle nicht Teil des APDU-Handlers sei.

Die Kammer ist von diesem Argument nicht überzeugt. Die Sprungtabelle wird für die Decodierung von APDU-Dataeinheiten zum Aufruf von durch nachgeladenem Programmcode bereitgestellten Funktionen verwendet und ist dazu auch unverzichtbar. Weiter fordert, wie gesagt, Anspruch 1 auch nicht, das der APDU-Handler ausschließlich im EEPROM abgelegt ist.

Die Beschwerdeführerin argumentierte weiter, D4 offenbare in Bezug auf die Sprungtabelle im EEPROM nicht, ob es sich bei dem nachladbaren Programmcode um eine neue Funktion der Chipkarte handelt, die mit einer neuen APDU-Dataeinheit aufrufbar ist, da es sich bei dem nachladbaren Programmcode nur um eine Verbesserung oder Fehlerkorrektur der Funktionalität von bereits bei der Herstellung der Chipkarte vorhandenen Befehle handeln könnte.

Die Kammer kann diesem Argument aus folgenden Gründen nicht folgen. Anspruch 1 nimmt nicht auf neue APDU-Dataeinheiten Bezug, sondern auf eine Funktionalität, für welche eine APDU-Dataeinheit erst nach Herstellung der Chipkarte standardisiert worden ist und umfasst somit auch Fälle, in denen einer bereits bekannten APDU-Dataeinheit nach Herstellung der Chipkarte durch Standardisierung eine andere Funktionalität zugeordnet wird. In diesem Zusammenhang offenbart D4, dass bei dem in der Praxis gebräuchlichen Kommandointerpreter der nachgeladene Programmcode der Komplettierung des Betriebssystems dient. Eine Komplettierung impliziert, dass dem Betriebssystem neue Funktionalitäten hinzugefügt werden. Weiter nennt D4 verschiedene Zwecke für das Nachladen von Programmcode (Seite 252). Zunächst wird im fünften Absatz der Zweck genannt, Programmcode nach der Personalisierung in die Chipkarte laden können und so einem Anwendungsanbieter die Möglichkeit zu bieten, Programmcode in der Chipkarte auszuführen, den der Betriebssystem-Hersteller nicht kennt. Im folgenden Absatz wird als "weiterer gewichtiger Grund", d.h. als vom vorgenannten Grund verschiedener Grund, die Beseitigung von Programmfehlern genannt.

1.5 Folglich ist der Gegenstand des Anspruchs 1 des Hauptantrags nicht neu gegenüber der Offenbarung des Dokuments D4 (Artikel 52 (1) und 54 EPÜ).

1.6 Somit ist der Hauptantrag nicht gewährbar.

2. Hilfsanträge I und II - erfinderische Tätigkeit

(Artikel 52 (1) und 56 EPÜ)

2.1 Anspruch 1 des Hilfsantrags I sowie II fügt im Wesentlichen dem Gegenstand des Anspruchs 1 des Hauptantrags ein derart ausgeführtes Test-Modul hinzu, dass es bestimmte empfangene APDU-Dataeinheiten an einen konventionellen ADPU-Handler im ROM und andere sowie vom konventionellen APDU-Handler nicht bearbeitbare APDU-Dataeinheiten an einen APDU-Handler im EEPROM weiterleitet. Im Ergebnis bestimmt das Test-Modul somit, ob ein Befehl von einem APDU-Handler im ROM oder einem im EEPROM bearbeitet wird. Da im hinzugefügten Merkmal offen gelassen wird, wie die APDU-Dataeinheiten bestimmt sind, die an den konventionellen APDU-Handler geleitet werden, ist nach Ansicht der Kammer auch der Fall umfasst, dass die vom konventionellen APDU-Handler bearbeitbaren APDU-Dataeinheiten an den konventionellen und die übrigen APDU-Dataeinheiten an den APDU-Handler im EEPROM geleitet werden.

Die Kammer merkt an, dass in der Chipkarte gemäß Anspruch 1 der Hilfsanträge I und II sowohl der APDU-Handler im ROM und als auch der im EEPROM die APDU-Dataeinheiten über dieselbe Schnittstelle und über dasselbe Test-Modul empfangen. Die Funktionen der beiden APDU-Handler und des Test-Moduls sind somit nicht voneinander unabhängig. Das Test-Modul und die beiden APDU-Handler können daher auch als Teile eines verteilten Kommandointerpreters zur Bearbeitung von APDU-Dataeinheiten betrachtet werden, wobei die Teile die entsprechende Funktionalität besitzen und am entsprechenden Speicherort, ROM oder EEPROM, abgelegt sind. Die Kammer ist in diesem Zusammenhang weiter der Ansicht, dass es die Funktionalität eines APDU-Handlers ist, APDU-Dataeinheiten decodieren und an entsprechende Komponenten zur Ausführung weiterleiten zu können, so dass in der Chipkarte gemäß Anspruch 1 der Hilfsanträge I und II eine Decodierung sowohl allein im ROM als auch allein im EEPROM möglich ist.

2.2 Da die in der Praxis gebräuchlichen Kommandointerpreter gemäß D4, Seite 297, unterscheiden können müssen, ob für einen empfangenen Befehl die Sprungtabelle im EEPROM in Anspruch genommen wird oder nicht, müssen diese Kommandointerpreter implizit auch ein Test-Modul für die Unterscheidung von ADPU-Dataeinheiten danach umfassen, ob sie ausschließlich im ROM oder auch unter Zuhilfenahme des EEPROM zu bearbeiten sind. D4 macht für letztere Fälle keine Aussagen dazu, ob die Decodierung der APDU-Dataeinheiten ausschließlich im EEPROM stattfindet.

2.3 Die Chipkarte gemäß Anspruch 1 unterscheidet sich von der aus D4 bekannten somit dadurch, dass das Test-Modul derart ausgeführt ist, dass es APDU-Dataeinheiten, die nicht vom APDU-Handler beziehungsweise Teil eines verteilten Kommandointerpreters im ROM bearbeitet werden können, an einen APDU-Handler beziehungsweise Teil eines verteilten Kommandointerpreters im EEPROM weiterleitet, der die Fähigkeit zur Decodierung von APDU-Dataeinheiten besitzt.

Ein sich daraus ergebender technischer Effekt ist, dass die vollständige Information der im ROM allein nicht bearbeitbaren APDU-Dataeinheiten an den im EEPROM abgelegten Teil eines verteilten Kommandointerpreters geleitet wird und dort für eine Decodierung im EEPROM zur Verfügung steht, die damit unabhängig von der Decodierung durch den im ROM abgelegten Teil des verteilten Kommandointerpreters ist.

2.4 Ausgehend von einer Chipkarte mit einem auf ROM und EEPROM verteilten Kommandointerpreter gemäß D4 kann die Aufgabe daher darin gesehen werden, die Flexibilität bei der Bereitstellung von Funktionen durch nachgeladenen Programmcode zu erhöhen.

Da ein EEPROM im Gegensatz zu einem ROM wiederbeschreibbar ist, ist diese Flexibilität in Bezug auf durch nachgeladenen Programmcode bereitgestellte Funktionen und die APDU-Dataeinheiten zu deren Aufruf umso höher, je mehr Funktionen zu deren Decodierung im EEPROM abgelegt sind.

Ein vor die vorgenannte Aufgabe gestellter und von der D4 ausgehender Fachmann würde daher nach Ansicht der Kammer die Decodierung von nicht im ROM allein bearbeitbaren APDU-Dataeinheiten nicht nur teilweise sondern vollständig in den EEPROM verlegen und diese APDU-Dataeinheiten dazu an den Teil des verteilten Kommandinterpreters im EEPROM weiterleiten und das Test-Modul entsprechend ausgestalten. Die Kammer weist in diesem Zusammenhang darauf hin, dass D4 bereits lehrt, Programmcode, also Anweisungen zur Ausführung komplexer Funktionen durch den Mikroprozessor wie sie auch zur Decodierung verwendet werden können, im EEPROM nachzuladen (D4, Seite 297).

2.5 Folglich beruht der Gegenstand des Anspruchs 1 der Hilfsanträge I und II für den von D4 ausgehenden Fachmann unter Berücksichtigung des allgemeinen technischen Fachwissens nicht auf einer erfinderischen Tätigkeit (Artikel 52 (1) EPÜ und 56 EPÜ).

2.6 Somit sind Hilfsanträge I und II nicht gewährbar.

3. Hilfsantrag III - erfinderische Tätigkeit

(Artikel 52 (1) und 56 EPÜ)

3.1 Anspruch 1 des Hilfsantrags III fügt dem Gegenstand des Anspruchs 1 der Hilfsanträge I und II im Wesentlichen das Merkmal hinzu, dass eine der verschiedenen vom APDU-Handler aufgerufenen Komponenten im ROM abgelegt ist. Die Kammer merkt an, dass der APDU-Handler zum Aufruf dieser Komponente auch im ROM abgelegt sein kann.

3.2 D4 offenbart, dass die in der Praxis gebräuchlichen Kommandointerpreter, auf die in den obigen Punkten 1 und 2 Bezug genommen wurde, sich im ROM befinden und bei einer Komplettierung des Betriebssystem im EEPROM nachladbaren Programmcode erkennen und aufrufen können (Seite 297). Dies impliziert, dass vor einem Nachladen beziehungsweise einer Komplettierung bereits Komponenten vorhanden sind und dass diese wie der Kommandointerpreter im ROM abgelegt ist.

Das hinzugefügte Merkmal trägt somit nicht zu einer erfinderischen Tätigkeit bei.

3.3 Folglich und aus den Gründen in Punkt 2 oben beruht der Gegenstand des Anspruchs 1 des Hilfsantrags III für den von D4 ausgehenden Fachmann unter Berücksichtigung des allgemeinen technischen Fachwissens nicht auf einer erfinderischen Tätigkeit (Artikel 52 (1) EPÜ und 56 EPÜ).

3.4 Somit ist Hilfsantrag III nicht gewährbar.

Entscheidungsformel

Aus diesen Gründen wird entschieden:

Die Beschwerde wird zurückgewiesen