{"id":3913,"date":"2008-04-17T17:00:36","date_gmt":"2008-04-17T17:00:36","guid":{"rendered":"https:\/\/www3.hhu.de\/duesseldorfer-archiv\/?p=3913"},"modified":"2016-04-29T11:45:17","modified_gmt":"2016-04-29T11:45:17","slug":"4a-o-3707-sim-karte","status":"publish","type":"post","link":"https:\/\/d-prax.de\/?p=3913","title":{"rendered":"4a O 37\/07 – SIM-Karte"},"content":{"rendered":"
\n
\n
\n
D\u00fcsseldorfer Entscheidung Nr.: 870<\/strong><\/div>\n<\/div>\n<\/div>\n<\/div>\n

Landgericht D\u00fcsseldorf
\nUrteil vom 17. April 2008, Az. 4a O 37\/07<\/p>\n

<\/p>\n

I. Die Klage wird abgewiesen.<\/p>\n

II. Die Kosten des Rechtsstreits werden der Kl\u00e4gerin auferlegt.<\/p>\n

III. Das Urteil ist gegen Sicherheitsleistung in H\u00f6he von 110 % des jeweils zu vollstreckenden Betrages vorl\u00e4ufig vollstreckbar.
\nDie Sicherheitsleistung kann auch durch eine unwiderrufliche, unbedingte, unbefristete und selbstschuldnerische B\u00fcrgschaft einer in der Europ\u00e4ischen Union als Zoll- oder Steuerb\u00fcrgin anerkannten Bank oder Sparkasse erbracht werden.<\/p>\n

Tatbestand:
\nDie Kl\u00e4gerin, die als Tochterunternehmen der in Luxemburg ans\u00e4ssigen A S.A. der B-Gruppe angeh\u00f6rt, ist seit dem 10. September 2007 in das Patentregister eingetragene Inhaberin des deutschen Teils des europ\u00e4ischen Patents 0 475 xxx B1 (Klagepatent). Aus diesem Schutzrecht nimmt sie die Beklagte auf Unterlassung, Rechnungslegung und Feststellung ihrer Verpflichtung zum Schadensersatz in Anspruch.
\nDas Klagepatent wurde in franz\u00f6sischer Verfahrenssprache am 10. September 1991 unter Inanspruchnahme der Priorit\u00e4t der franz\u00f6sischen Anmeldung FR 9011xxx vom 12. September 1990 angemeldet, die Anmeldung am 18. M\u00e4rz 1992 offengelegt. Die Ver\u00f6ffentlichung der Erteilung des Klagepatents bei dem Europ\u00e4ischen Patentamt erfolgte am 11. August 1993. Die deutsche \u00dcbersetzung des Klagepatents, die unter dem Registerzeichen DE 69 100 xxx T2 gef\u00fchrt wird, liegt als Anlage K3 vor. \u00dcber die Nichtigkeitsklage der Beklagten gegen den deutschen Teil des Klagepatents vom 06. August 2007 ist bislang nicht entschieden worden.<\/p>\n

Das Klagepatent betrifft ein Verfahren zur Verwaltung eines in einem Mikroschaltungsdatentr\u00e4ger gespeicherten Anwender- bzw. Anwendungsprogramms. Der in erster Linie geltend gemachte Anspruch 1 des Klagepatents lautet in deutscher \u00dcbersetzung (Anlage K2, Spalte 11, wortgleich der Anspruchsfassung gem\u00e4\u00df der T2-Schrift, Anlage K3, Seite 12) wie folgt:
\nVerfahren zur Verwaltung eines in einen Mikroschaltungs-Datentr\u00e4ger (2) geladenen Anwenderprogramms mit den folgenden Schritten:
\na) zum Laden des Anwenderprogramms:
\n– wird eine chiffrierte Signatur gebildet, die von einem geheimen Code (10) der Mikroschaltung und bestimmten Befehlen des Programms abh\u00e4ngt,
\n– diese Signatur wird in einen programmierbaren Speicher (14) der Mikroschaltung geladen,
\n– das Programm wird in einen Programmspeicher (12) der Mikroschaltung geladen;
\nb) wenn das Anwenderprogramm ausgef\u00fchrt werden soll:
\n– l\u00e4sst man durch den Mikroprozessor der Mikroschaltung vor der Ausf\u00fchrung des Anwenderprogramms eine weitere chiffrierte Signatur bilden (11),
\n– diese Signatur wird verglichen (17, 18),
\n– der Ablauf des Programms wird in Abh\u00e4ngigkeit von dem Ergebnis dieses Vergleichs zugelassen.<\/p>\n

Hinsichtlich der im Wege von Insbesondere-Antr\u00e4gen geltend gemachten Unteranspr\u00fcche 2, 3 und 4 wird auf die Klagepatentschrift verwiesen. Die nachfolgend leicht verkleinert wiedergegebenen Figuren 1 und 2 der Klagepatentschrift illustrieren das patentgem\u00e4\u00dfe Verfahren anhand einer bevorzugten Ausf\u00fchrungsform:<\/p>\n

Die Beklagte, ein Technologieunternehmen mit Sitz in Paderborn, das Systeml\u00f6sungen auf Basis von Kartentechnologie, unter anderem im Bereich der Telekommunikation, entwickelt, stellt unter anderem her und vertreibt SIM-Karten (Subscriber Identity Module) f\u00fcr Mobiltelefone unter der Bezeichnung \u201eC\u201c. Zur \u201eC\u201c-Kartenfamilie der Beklagten geh\u00f6ren drei Typen von Karten, die unter den Bezeichnungen \u201eC native\u201c, \u201eC ON\u201c und \u201eC SMART\u201c vertrieben werden (nachfolgend auch: angegriffene Ausf\u00fchrungsformen). Als Anlagen K7, K8 und K9 liegen die Produktbrosch\u00fcren der angegriffenen Ausf\u00fchrungsformen vor.
\nWie zwischen den Parteien unstreitig ist, unterst\u00fctzen die angegriffenen Ausf\u00fchrungsformen die letzten 3GPP-Normen, insbesondere die technische Spezifikation 3GPP TS23.048 OTA \u201eRemote File & Remote Application Management\u201c, die auch als GSM 03.48 OTA \u201eRemote File & Remote Application Management\u201c bekannt ist. Die technische Spezifikation 3GPP TS 23.048 V4.5.0 liegt als Anlage K10 vor. Sie nimmt Bezug (vgl. Anlage K10, Seite 7 unter [14] der References) auf das Dokument \u201eGlobal Platform – Open Platform Card Specification Version 2.0.1\u201c vom 07. April 2000, das die Kl\u00e4gerin in Kopie als Anlage K11 vorgelegt hat. Diese Spezifikation beschreibt Sicherheitsmechanismen f\u00fcr SIM-Anwendungen.
\nDie Abk\u00fcrzung \u201eOTA\u201c steht f\u00fcr eine Daten\u00fcbertragung \u00fcber die Luftschnittstelle (Over The Air). Die Unterst\u00fctzung von OTA-M\u00f6glichkeiten erlaubt es dem Mobilfunkbetreiber, aus der Entfernung GSM-Dateien zu aktualisieren und die Karte auch noch nach ihrer Ausgabe zu personalisieren. So hei\u00dft es in den Produktbrosch\u00fcren der angegriffenen Ausf\u00fchrungsformen im Wesentlichen gleichlautend (vgl. Anlagen K7, K8, K9, jeweils Seite 2, linke Spalte):
\n\u201cThe support of OTA capabilities allows Mobile Operators to remotely update [\u2026] specific\u201d beziehungsweise \u201cGSM files, thus providing post-issuance personalization capabilities.\u201d<\/p>\n

Die Kl\u00e4gerin ist unter Berufung auf die Ausf\u00fchrungen in den als Anlagen K10 und K11 vorliegenden Standards der Ansicht, die angegriffenen Ausf\u00fchrungsformen seien in der Lage, von s\u00e4mtlichen Merkmalen des Klagepatentanspruchs 1 Gebrauch zu machen. Die Kl\u00e4gerin hatte zun\u00e4chst vorgetragen, die Beklagte wende das Verfahren, das Gegenstand des Klagepatents ist, selbst an und biete es Dritten im Anwendungsbereich des Patentgesetzes zur Anwendung an, obwohl sie wisse oder es aufgrund der Umst\u00e4nde offensichtlich sei, dass die Anwendung des Verfahrens ohne Zustimmung der Kl\u00e4gerin verboten sei und versto\u00dfe damit gegen \u00a7 9 Satz 2 Nr. 2 PatG; daneben meinte sie, der Beklagten gest\u00fctzt auf \u00a7 10 Abs. 1 PatG untersagen lassen zu k\u00f6nnen, SIM-Karten f\u00fcr das Verfahren des Klagepatents anzubieten oder zu liefern. Vor der letzten m\u00fcndlichen Verhandlung hat die Kl\u00e4gerin ihren Klageantrag auf eine mittelbare Verletzung des Klagepatents durch Angebot und Lieferung der angegriffenen Ausf\u00fchrungsformen beschr\u00e4nkt.<\/p>\n

Die Kl\u00e4gerin beantragt nunmehr,<\/p>\n

I. die Beklagte zu verurteilen,<\/p>\n

1. es bei Meidung eines f\u00fcr jeden Fall der Zuwiderhandlung vom Gericht festzusetzenden Ordnungsgeldes bis zu 250.000,– \u20ac – ersatzweise Ordnungshaft – oder Ordnungshaft bis zu sechs Monaten, im Falle wiederholter Zuwiderhandlung Ordnungshaft bis zu zwei Jahren,
\nin der Bundesrepublik Deutschland zu unterlassen,
\nAbnehmern im Gebiet der Bundesrepublik Deutschland SIM-Karten anzubieten und\/oder zu liefern, die geeignet und bestimmt sind, im Gebiet der Bundesrepublik Deutschland f\u00fcr die Anwendung eines
\n1.1 Verfahrens zur Verwaltung eines in einen Mikroschaltungs-Datentr\u00e4ger geladenen Anwenderprogramms mit den folgenden Schritten:
\n1.2 zum Laden des Anwenderprogramms:
\n1.2.1 wird eine chiffrierte Signatur gebildet, die von einem geheimen Code der Mikroschaltung und bestimmten Befehlen des Programms abh\u00e4ngt;
\n1.2.2 diese Signatur wird in einen programmierbaren Speicher der Mikroschaltung geladen,
\n1.2.3 das Programm wird in einen Programmspeicher der Mikroschaltung geladen;
\n1.3 wenn das Anwenderprogramm ausgef\u00fchrt werden soll:
\n1.3.1 l\u00e4sst man durch den Mikroprozessor der Mikroschaltung vor der Ausf\u00fchrung des Anwenderprogramms eine weitere chiffrierte Signatur bilden,
\n1.3.2 diese Signatur wird verglichen und
\n1.3.3 der Ablauf des Programms wird in Abh\u00e4ngigkeit von dem Ergebnis dieses Vergleichs zugelassen
\nverwendet zu werden,
\ninsbesondere, wenn
\ndas Programm in einem programmierbaren und l\u00f6schbaren Speicher gespeichert wird
\nund\/oder
\nein geheimer Code in die Mikroschaltung geladen wird, wobei dieser Code der Bildung der Signatur gewidmet ist
\nund\/oder
\ndie Bildung der weiteren Signatur und der Vergleich dieser Signatur erst im Augenblick des Ladens des Anwenderprogramms in den Arbeitsspeicher erfolgt;<\/p>\n

2. der Kl\u00e4gerin Rechnung zu legen, in welchem Umfang die Beklagte die in Ziffer I. 1. bezeichneten Handlungen seit dem 11. September 1993 begangen hat und zwar unter Angabe
\na) der einzelnen Lieferungen, aufgeschl\u00fcsselt nach Liefermengen, -zeiten und -preisen sowie der Namen und Anschriften der Empf\u00e4nger;
\nb) der einzelnen Angebote, aufgeschl\u00fcsselt nach Angebotsmengen, -zeiten und \u2013preisen sowie der Namen und Anschriften der Angebotsempf\u00e4nger;
\nc) der betriebenen Werbung, aufgeschl\u00fcsselt nach Werbetr\u00e4gern, deren Auflagenh\u00f6he, Verbreitungszeitraum und Verbreitungsgebiet;
\nd) der mit dem Verkauf der Mikroprozessorkarte gem\u00e4\u00df Ziffer I. 1. erzielten Ums\u00e4tze sowie des hierdurch erzielten Gewinns,
\nwobei es der Beklagten gestattet ist, die Namen und Anschriften der Angebotsempf\u00e4nger und der nicht-gewerblichen Abnehmer statt der Kl\u00e4gerin einem durch die Kl\u00e4gerin zu benennenden \u00f6ffentlich bestellten Wirtschaftspr\u00fcfer mitzuteilen, der gegen\u00fcber der Kl\u00e4gerin zur Verschwiegenheit verpflichtet ist, sofern die Beklagte die durch die Einf\u00fchrung des \u00f6ffentlich bestellten Wirtschaftspr\u00fcfers verursachten Kosten tr\u00e4gt und den \u00f6ffentlich bestellten Wirtschaftspr\u00fcfer erm\u00e4chtigt, der Kl\u00e4gerin auf Befragen dar\u00fcber Auskunft zu geben, ob bestimmte Abnehmer, Angebotsempf\u00e4nger und\/oder Lieferungen in der Rechnung enthalten sind;<\/p>\n

II. festzustellen, dass die Beklagte verpflichtet ist, der Kl\u00e4gerin allen Schaden zu ersetzen, der durch die in Ziffern I. 1. bezeichneten, seit dem 11. September 1993 begangenen Handlungen entstanden ist und noch entstehen wird,<\/p>\n

III. hilfsweise: Vollstreckungsschutz wegen der Kosten.<\/p>\n

Die Beklagte beantragt,
\ndie Klage abzuweisen,<\/p>\n

hilfsweise,
\ndie Verhandlung bis zum Abschluss des von der Beklagten gegen das Klagepatent eingeleiteten Nichtigkeitsverfahrens auszusetzen.<\/p>\n

Die Beklagte bestreitet, dass die angegriffenen \u201eC\u201c SIM-Karten zur Ausf\u00fchrung des klagepatentgem\u00e4\u00dfen Verfahrens geeignet seien. Insbesondere komme in den angegriffenen Ausf\u00fchrungsformen der \u201eLoad File DAP\u201c nicht zum Einsatz, auf den sich die Verletzungsargumentation der Kl\u00e4gerin gr\u00fcndet. Der \u201eLoad File DAP\u201c sei als Funktionalit\u00e4t in den angegriffenen SIM-Karten nicht implementiert.
\nDes Weiteren werde sich das Klagepatent im anh\u00e4ngigen Nichtigkeitsklageverfahren als nicht rechtsbest\u00e4ndig erweisen, weshalb die Verhandlung jedenfalls auszusetzen sei.<\/p>\n

Dem tritt die Kl\u00e4gerin entgegen.<\/p>\n

Wegen weiterer Einzelheiten des Sach- und Streitstandes wird auf die eingereichten Schrifts\u00e4tze nebst Anlagen Bezug genommen.<\/p>\n

Entscheidungsgr\u00fcnde:
\nDie Klage ist zul\u00e4ssig, jedoch nicht begr\u00fcndet.
\nDer Kl\u00e4gerin stehen die geltend gemachten Anspr\u00fcche auf Unterlassung, Schadensersatz und Rechnungslegung aus Art. 64 EP\u00dc in Verbindung mit \u00a7\u00a7 10 Abs. 1; 139 Abs. 1 und 2; 140b Abs. 1 und 2 PatG; \u00a7\u00a7 242; 259 BGB nicht zu. Sie hat nicht schl\u00fcssig dargelegt, dass die angegriffenen \u201eC\u201c SIM-Karten der Beklagten objektiv geeignet sind, das Verfahren, das Gegenstand des Klagepatents ist, auszu\u00fcben (\u00a7 10 Abs. 1 PatG). Dies scheitert zum einen daran, dass eine zwingende Benutzung des Load File DAP durch die angegriffenen SIM-Karten auf der Grundlage des Standards 3GPP TS 23.048, Version 4.5.0 (2005-06) (Anlage K10) nicht ersichtlich ist. Die von der Kl\u00e4gerin allein anhand des Standards und des Load File DAP gef\u00fchrte Verletzungsdiskussion kann eine Benutzung des Klagepatents durch die angegriffenen Ausf\u00fchrungsformen aber allenfalls dann belegen, wenn dieser standardgem\u00e4\u00df zwingend zur Anwendung kommt und nicht nur optional vorgesehen ist. Zum anderen hat die Kl\u00e4gerin nicht dargelegt, dass die von ihr vorgetragene Identifizierung gem\u00e4\u00df dem Standard nach Anlage K10 anspruchsgem\u00e4\u00df im Sinne des Merkmals 1.3 bei einer jeden Ausf\u00fchrung des Anwendungsprogramms erfolgt.<\/p>\n

I.
\nDas Klagepatent betrifft ein Verfahren zur Verwaltung eines in einen Mikroschaltungs-Datentr\u00e4ger geladenen Anwenderprogramms (zwischen den Parteien besteht Einigkeit, dass richtigerweise von einem Anwendungsprogramm gesprochen werden sollte, weshalb beide Begriffe hier synonym verwendet werden), wobei der Mikroschaltungs-Datentr\u00e4ger in einer bevorzugten Anwendung eine sogenannte elektronische Chipkarte darstellt.
\nNach den Ausf\u00fchrungen des Klagepatents enth\u00e4lt ein Mikroschaltungs-Datentr\u00e4ger einerseits einen Tr\u00e4ger und andererseits eine elektronische Schaltung, die auf der Oberfl\u00e4che des Tr\u00e4gers mit Mitteln f\u00fcr die Kommunikation mit der Au\u00dfenwelt versehen ist. Eine Mikroschaltung des Typs, der in elektronischen Chipkarten verwendet wird, umfasst einerseits einen Mikroprozessor und andererseits eine Gesamtheit von Speichern mit unterschiedlichen Funktionen. Im Wesentlichen k\u00f6nnen – wie die Klagepatentbeschreibung erl\u00e4utert – drei Speichertypen unterschieden werden: Ein fl\u00fcchtiger Arbeitsspeicher (RAM-Speicher, f\u00fcr Random Access Memory, Speicher mit wahlfreiem Zugriff) wird von der Central Processing Unit (CPU, dem Hauptprozessor als Herzst\u00fcck des Mikroschaltungs-Datentr\u00e4gers) als Arbeitsbereich zum Laden und Handhaben von Anwendungen und Daten genutzt. RAM-Speicher sind, wie sie auch in der Beschreibung des Klagepatents bezeichnet werden (Seite 1, Absatz 3), regelm\u00e4\u00dfig fl\u00fcchtig (volatil), das hei\u00dft die auf ihnen gespeicherten Daten gehen nach Abschaltung der Stromzufuhr verloren. Eine Mikroschaltung enth\u00e4lt ferner einen Festwertspeicher (ROM- oder Programmspeicher, ROM f\u00fcr Read Only Memory), der das Anwendungsprogramm enth\u00e4lt und normalerweise vom Benutzer nicht von au\u00dfen programmiert werden kann. Er ist nur lesbar, im normalen Betrieb jedoch nicht beschreibbar, und (verst\u00e4ndlicherweise) nicht fl\u00fcchtig, das hei\u00dft er beh\u00e4lt seine Daten auch im stromlosen Zustand. Ein ROM-Speicher muss entweder durch Maskierung durch den Hersteller der Mikroschaltung oder durch den Ausgeber der Karte programmiert worden sein, bevor der Ausgeber den Schreibzugriff auf den ROM-Festwertspeicher endg\u00fcltig verhindert, was im Allgemeinen durch Unterbrechung einer Sicherung geschieht. Als dritten Speichertyp beschreibt die Klagepatentschrift elektrisch programmierbare und l\u00f6schbare Speicher, beispielsweise vom Typ EEPROM (f\u00fcr Electrically Erasable Programmable Read Only Memory, also elektrisch l\u00f6schbarer, programmierbarer Nur-Lese-Speicher). Diese beschreibbaren Speicher gestatten die Eingabe von auf die Anwendung bezogenen Daten. Sie sind wie der ROM-Speicher normalerweise nicht fl\u00fcchtig. Zur Ausf\u00fchrung der im ROM-Speicher enthaltenen Anwendungsprogramme k\u00f6nnen die auszuf\u00fchrenden Befehle entweder durch den Mikroprozessor direkt im ROM-Speicher abgelesen werden oder zuvor in den RAM-Speicher \u00fcbertragen werden, von wo aus sie durch den Mikroprozessor ausgef\u00fchrt werden (Klagepatentschrift, Anlage K3, Seite 1 bis Seite 2, zweiter Absatz).
\nWie die Klagepatentbeschreibung weiter ausf\u00fchrt (Anlage K3, Seite 2, dritter und Seiten 2 und 3 \u00fcbergreifender Absatz), k\u00f6nnen bei der Verwendung von Mikroschaltungskarten als Teilnehmer die Hersteller, die Ausgeber und die Verwender der Karten unterschieden werden. Die Ausgeber der Karten fordern im Allgemeinen vom Hersteller der Mikroschaltung entweder durch Maskierung in einem ROM-Festwertspeicher oder durch Software-Programmierung und eine (wie es in der \u00dcbersetzung der Beschreibung hei\u00dft) \u201eunwiderrufliche Unterbrechung der Schreibzugriffssicherung in einem Speicher vom EPROM-Typ\u201c (gemeint ist erkennbar eine unwiderrufliche Sicherung gegen sp\u00e4teren Schreibzugriff auf die in einem Speicher vom EPROM-Typ gespeicherten Daten) die unl\u00f6schbare Programmierung der von ihnen gew\u00fcnschten Anwendungen. Aus Sicherheitsgr\u00fcnden wurde die Anwendung nach dem Stand der Technik also entweder bereits durch den Hersteller in einen ROM-Speicher geladen oder die Anwendungsprogramme wurden zwar in programmierbare Speicher geladen, der Zugriff auf die Programmierung dieser Speicher jedoch unwiderruflich beschr\u00e4nkt (vgl. Anlage K3, Seite 3, letzter Absatz). Beide Vorgehensweisen haben zur Folge, dass die Anwendungsprogramme von Anfang an starr waren und durch kein Mittel mehr modifiziert werden konnten, etwa wenn der Karte andere bzw. weitere Funktionseigenschaften verliehen werden sollten. W\u00fcnschte der Ausgeber (Diensteanbieter) dies, musste er nach dem Stand der Technik stets die Herstellung vollst\u00e4ndig neuer Chipkarten mit neuen Mikroschaltungen in Auftrag geben. Eine Weiterentwicklung war daher nur dadurch m\u00f6glich, dass der Hersteller andere Karten mit anderen Maskierungen schuf, bei denen die neuen Anwendungsprogramme in den ROM-Speicher geschrieben wurden. Die Klagepatentschrift kritisiert diesen Prozess als langwierig und wenig flexibel (Anlage K3, Seiten 2 und 3 \u00fcbergreifender Absatz a.E.).
\nAndererseits k\u00f6nnen die Anwendungsprogramme aus Sicherheitsgr\u00fcnden auch nicht schlicht in einen wieder beschreibbaren Speicher der Mikroschaltung geschrieben werden, was dem Dienstanbieter die M\u00f6glichkeit schaffen w\u00fcrde, immer dann, wenn er eine neue Dienstleistung bereitstellen will, einfach die entsprechenden neuen Anwendungsprogramme in den ver\u00e4nderbaren Speicher der bestehenden Mikroschaltung zu schreiben. Denn in diesem Fall k\u00f6nnten auch nicht autorisierte Personen gef\u00e4lschte Anwendungsprogramme in existierende Chipkarten einspeisen, etwa ein unbefugter Dritter ein manipuliertes Bankanwendungsprogramm auf die Karte laden (vgl. Anlage K3, Seite 3, dritter Absatz).<\/p>\n

Vor dem Hintergrund dieses technischen Problems hat es sich das Klagepatent zur Aufgabe gesetzt, einerseits einen Weg bereitzustellen, existierende Chipkarten (Mikroschaltungen) leicht mit neuen Anwendungsprogrammen versehen zu k\u00f6nnen, ohne andererseits die Gefahr eines unautorisierten Zugriffs in Kauf nehmen zu m\u00fcssen. Als Kern der vorgeschlagenen technischen L\u00f6sung beschreibt es die Klagepatentschrift (Anlage K3, Seite 4, erster vollst\u00e4ndiger Absatz), dass von der Anwendung gefordert wird, dass sie sich selbst sch\u00fctzt.<\/p>\n

Die zur L\u00f6sung dieses Problems vorgeschlagene L\u00f6sung lautet, nach Merkmalen gegliedert, wie folgt:<\/p>\n

1.1 Verfahren zur Verwaltung eines in einen Mikroschaltungs-Datentr\u00e4ger (2) geladenen Anwenderprogramms mit den folgenden Schritten:
\n1.2 zum Laden des Anwenderprogramms:
\n1.2.1 wird eine chiffrierte Signatur gebildet, die von einem geheimen Code (10) der Mikroschaltung und bestimmten Befehlen des Programms abh\u00e4ngt,
\n1.2.2 diese Signatur wird in einen programmierbaren Speicher (14) der Mikroschaltung geladen,
\n1.2.3 das Programm wird in einen Programmspeicher (12) der Mikroschaltung geladen;
\n1.3 wenn das Anwenderprogramm ausgef\u00fchrt werden soll:
\n1.3.1 l\u00e4sst man durch den Mikroprozessor der Mikroschaltung vor der Ausf\u00fchrung des Anwenderprogramms eine weitere chiffrierte Signatur bilden (11),
\n1.3.2 diese Signatur wird verglichen (17, 18),
\n1.3.3 der Ablauf des Programms wird in Abh\u00e4ngigkeit von dem Ergebnis dieses Vergleichs zugelassen.<\/p>\n

Der allgemeine Teil der Beschreibung (Anlage K3, Seite 4, erster und zweiter Absatz) erl\u00e4utert, dass anspruchsgem\u00e4\u00df in die \u201esich selbst sch\u00fctzende\u201c Anwendung ein Chiffrierprogramm eingebaut werde, das die Aufgabe habe, eine Signatur auf der Grundlage einerseits eines der Karte eigent\u00fcmlichen geheimen Codes und andererseits von Befehlen des Nutzprogramms selbst herzustellen (Merkmal 1.2.1). Wenn dieses Chiffrierprogramm nicht in der Anwendung selbst enthalten sei, sei es dennoch vorhanden und m\u00fcsse periodisch vom Mikroprozessor gestartet werden, wobei sich sein Ablauf auf die Befehle der Anwendung st\u00fctze. Da die Signatur selbst in den Datenspeicher der Karte geladen und in diesem Speicher vollst\u00e4ndig lesbar sei (Merkmal 1.2.2), enthalte die Karte in ihrem Datenspeicher den geheimen Code und die Signatur. In ihrem Programmspeicher enthalte die Karte einerseits das Anwendungsprogramm (d.h. s\u00e4mtliche Befehle dieses Programms; Merkmal 1.2.3) und andererseits einen Chiffrieralgorithmus, der mit demjenigen identisch ist, mit dem die auf der Karte gespeicherte Signatur (Merkmal 1.2.2) gebildet worden sei. Die Anwendung k\u00f6nne daher in einem programmierbaren und l\u00f6schbaren Speicher gespeichert sein, w\u00e4hrend der Chiffrieralgorithmus nur im nichtprogrammierbaren Festwertspeicher gespeichert sei.
\nWenn dann die Verwendung der Karte gew\u00fcnscht sei, gen\u00fcge es, bei jeder Verwendung zu \u00fcberpr\u00fcfen, ob die erneute Berechnung der Signatur auf der Grundlage der Programmbefehle und des geheimen Codes (Merkmal 1.3.1) genau gleich der bereits eingetragenen Signatur ist (Anlage K3, Seite 4, vorletzter Absatz). Nur in Abh\u00e4ngigkeit von dem Ergebnis dieses Vergleichs (Merkmal 1.3.2) wird der Ablauf des Programms zugelassen (Merkmal 1.3.3), mit der Folge, dass nur der autorisierte Chipkartenanbieter, der den Geheimcode der Chipkarte kennt, in der Lage ist, erfolgreich neue Anwendungsprogramme auf die Chipkarte zu laden. L\u00e4dt hingegen ein nicht autorisierter Dritter eine Anwendung auf die Chipkarte, so wird das Ergebnis der Berechnung der Signatur ver\u00e4ndert, die dann nicht mehr mit der im Speicher der Mikroschaltung gespeicherten Signatur \u00fcbereinstimmt, mit der Folge, dass die Mikroschaltung nicht l\u00e4nger funktioniert. In Unkenntnis des geheimen Codes der Chipkarte ist ein nicht autorisierter Dritter nicht in der Lage, die richtige Signatur f\u00fcr das gef\u00e4lschte Anwendungsprogramm auszuarbeiten.<\/p>\n

II.
\nDie Kl\u00e4gerin hat auf der Grundlage des Standards \u201e3GPP TS 23.048 V4.5.0 (2005-06)\u201c (Anlage K10, nachfolgend auch: Standard 23.048), mit dem die angegriffenen Ausf\u00fchrungsformen unstreitig konform sind, nicht schl\u00fcssig dargelegt, dass diese im Sinne des \u00a7 10 Abs. 1 PatG f\u00fcr eine Benutzung des vom Klagepatent gesch\u00fctzten Verfahrens geeignet sind.
\nZum einen ist eine Verwendung des Load File DAP entgegen der von der Kl\u00e4gerin vertretenen Auffassung im Rahmen des Standards 23.048, der auf das Dokument \u201eGlobal Platform – Open Platform Card Specification version 2.0.1\u201c vom 07. April 2000 (Anlage K11; nachfolgend auch: Open Platform-Spezifikation) verweist, nicht obligatorisch (nachfolgend unter 1.). Aus der schlichten Konformit\u00e4t der angegriffenen SIM-Karten mit dem Standard 23.048 l\u00e4sst sich der von der Kl\u00e4gerin darzulegende und erforderlichenfalls zu beweisende Benutzungstatbestand daher nicht ableiten. Zum anderen ist Merkmal 1.3 des Klagepatentes, das eine Durchf\u00fchrung der eine Verifikation des Anwendungsprogramms darstellenden Verfahrensschritte 1.3.1 bis 1.3.3 verlangt, \u201ewenn das Anwenderprogramm ausgef\u00fchrt werden soll\u201c, mithin bei jeder Ausf\u00fchrung des Anwendungsprogramms, nicht erf\u00fcllt. Denn auch nach dem Vortrag der Kl\u00e4gerin soll standardgem\u00e4\u00df in Verbindung mit der Open Platform-Spezifikation nur eine einmalige Verifikation im Anschluss an das vollst\u00e4ndige Laden stattfinden, wenn das Anwendungsprogramm in eine ausf\u00fchrbare Form gebracht wird, danach jedoch nicht mehr. Nach dem Gegenstand des Klagepatents, wie er sich f\u00fcr den Fachmann auf dem Gebiet des Klagepatents aus dem Patentanspruch unter Ber\u00fccksichtigung der Beschreibung und der Zeichnungen ergibt, ist eine Ausf\u00fchrung der Verfahrensschritte nach Merkmalsgruppe 1.3 jedoch immer dann erforderlich, wenn das Anwendungsprogramm ausgef\u00fchrt werden soll (vgl. unter 2.).<\/p>\n

1.
\nDie Kl\u00e4gerin sieht eine Verwirklichung der Lehre des Klagepatents in den in Abschnitt 9 des Standards 23.048 behandelten \u201eOpen Platform commands for Remote Applet Management\u201c, also in denjenigen Befehlen, die f\u00fcr eine Verwaltung (d.h. ein Laden, eine Installation oder ein Entfernen) von Anwendungsprogrammen auf Chipkarten (UICC f\u00fcr Universal Integrated Circuit bzw. Chip Card) und damit Mikroschaltungs-Datentr\u00e4gern im Sinne des Klagepatents vorgesehen sind. Dabei ist nach dem Vortrag der Kl\u00e4gerin zu unterscheiden zwischen dem Ladevorgang (Package Loading), der in Abschnitt 9.1.1 des Standards 23.048 angesprochen ist, und der Installation des Anwendungsprogramms (Applet Installation) gem\u00e4\u00df Abschnitt 9.1.2, mit welchem dem Netzwerkbetreiber oder Diensteanbieter erlaubt wird, ein neues Anwendungsprogramm auf der Chipkarte zu installieren.
\nDer Verletzungsvorwurf der Kl\u00e4gerin st\u00fctzt sich darauf, dass der Load File DAP, der nach ihrer Auffassung synonym mit Load File Data Block DAP verwendet werden kann, ausweislich Abschnitt A.1.4.1 (Anlage K10, Seite 28, nachfolgend in deutscher \u00dcbersetzung wiedergegeben) eine \u201ekryptografische \u00dcberpr\u00fcfungssumme, eine digitale Signatur oder eine Redundanz\u00fcberpr\u00fcfung, die \u00fcber die CAD-Datei berechnet wird, wie sie in den darauf folgenden Load-Befehlen \u00fcbertragen wird\u201c, darstelle. Das K\u00fcrzel DAP steht dabei f\u00fcr Data Authentication Pattern (vgl. Anlage K10, Seite 9, Liste der Abk\u00fcrzungen in Abschnitt 3.2), also ein Daten-Authentifizierungsmuster. Ausweislich der Anmerkung in Abschnitt A.1.4.1 des Standards 23.048 (Anlage K10, Seite 28) wird der Load File DAP CC (f\u00fcr Cryptographic Checksum), DS (f\u00fcr Digital Signature) oder RC (f\u00fcr Redundancy Check) durch den Kartenmanager verifiziert. Der in Abschnitt A.1.4 des Standards 23.048 behandelte Install (Load)-Befehl soll (\u201eshall\u201c) nach der Open Platform-Spezifikation (Anlage K11) codiert werden, die als Referenz [14] auf Seite 6 des Standards 23.048 ausdr\u00fccklich in Bezug genommen wird.
\nZur Definition des Load File Data Block DAP beruft sich die Kl\u00e4gerin auf die Open Platform-Spezifikation (Anlage K11), Seite 4-5, Abschnitt 4.3.1.2, wonach der Load File Data Block DAP den Zweck habe, die Integrit\u00e4t eines Load File Data Blocks, der den tats\u00e4chlichen Code der Anwendung enth\u00e4lt, zu verifizieren. \u00dcber einen kryptografischen (d.h. Verschl\u00fcsselungs-) Algorithmus werde eine digitale Signatur bzw. ein Nachrichtenauthentifizierungscode (Message Authentication Code, MAC) \u00fcber den vollst\u00e4ndigen Load-File-Data-Block hinweg erzeugt. Nach der Definition in Anlage K11 (Seite 1-3, Abschnitt 1.3) ist ein Load File Data Block ein Block von Daten, der eine oder mehrere Anwendungen und Bibliotheken oder Unterst\u00fctzungsinformation f\u00fcr die Anwendungen enth\u00e4lt, wie es durch die spezifische Plattform erforderlich ist, mit anderen Worten: ein Datenblock, der den Code des Anwendungsprogramms enth\u00e4lt. Aus Sicht des Klagepatents k\u00f6nnten darin die \u201ebestimmten Befehle des Programms\u201c im Sinne des Merkmals 1.2.1 gesehen werden. Die Kl\u00e4gerin meint, in Verbindung mit dem geheimen Code, der sich in dem f\u00fcr die Verschl\u00fcsselung verwendeten Algorithmus (dem asymmetrischen Kryptografiealgorithmus RSA oder dem symmetrischen DES) verbirgt, ergebe sich in der von Merkmal 1.2.1 angesprochenen Weise aus den Befehlen des Load File Data Block DAP der MAC (Message Authentication Code). Dieser stelle die chiffrierte Signatur im Sinne des Klagepatents dar.
\nDie Beklagte wendet sich grundlegend gegen den dargelegten Ansatz der Kl\u00e4gerin, die angenommene Benutzung der technischen Lehre des Klagepatents \u00fcber das Data Authentication Pattern (DAP) zu begr\u00fcnden, weil dieses im Falle des Over The Air (OTA) Application Managements keine Anwendung finde. So weist der Standard 23.048 (Anlage K10) in Abschnitt A.1.4 (Seite 28) f\u00fcr den Install-Befehl in unmittelbarem Zusammenhang mit der grunds\u00e4tzlichen Referenz auf die Open Platform-Spezifikation (Anlage K11) darauf hin, dass die Hinweise auf DAP-Felder in der Spezifikation f\u00fcr das OTA Application Management nicht gelten. Wortgleiche Ausschl\u00fcsse wie bei dem Install-Befehl finden sich auch im Zusammenhang mit den Befehlen Delete (Abschnitt A.1.1) und Get Data (Abschnitt A.1.2). Die Beklagte meint, dieser Ausschluss sei damit zu begr\u00fcnden, dass (wie Abschnitt A.1, Anlage K10, Seite 27 einleitend klarstelle) die Mindestsicherheit, die auf ein Security Packet angewendet wird, das Applet-Management-Befehle enth\u00e4lt, diejenige Integrit\u00e4t sein solle, die man durch den Gebrauch einer kryptografischen Pr\u00fcfsumme oder digitalen Signatur erh\u00e4lt. In allen F\u00e4llen solle diese Sicherheit die bei Open-Platform-Befehlen f\u00fcr eine sichere Nachrichten\u00fcbermittlung verwendeten Data Authentication Patterns ersetzen. Nach den klaren Anweisungen des Standards 23.048 im Zusammenhang mit den Install-Befehlen k\u00e4men bei der \u00dcbertragung von Daten im GSM- oder UMTS-Standard auf eine SIM-Karte \u00fcber die Luftschnittstelle (OTA) Data Authentication Patterns (DAP) nicht zum Einsatz. Dementsprechend – so die Beklagte – seien die angegriffenen SIM-Karten zu einer Verarbeitung des Load File DAP auch nicht in der Lage.
\nF\u00fcr die Daten\u00fcbertragung und Programmverwaltung \u00fcber die Luftschnittstelle stellt die Kl\u00e4gerin nicht in Abrede, dass das Load File DAP gem\u00e4\u00df dem Standard nicht zur Anwendung kommt. Sie wendet jedoch ein, dass auf die SIM-Karten der Beklagten neue Anwendungsprogramme nicht nur Over The Air, sondern alternativ auch \u00fcber ein Terminal mit einer Lese- und Schreibvorrichtung geladen werden k\u00f6nnten, das mit der SIM-Karte in direkten Kontakt tritt. Dies geschehe etwa bei der Personalisierung der SIM-Karten vor ihrem Verkauf oder beim Laden von Anwendungsprogrammen \u00fcber einen Personal-Computer in Verbindung mit einem Mobilfunkger\u00e4t. F\u00fcr ein solches drahtgebundenes Laden komme das Load File DAP auch nach dem Standard 23.048 und damit bei den angegriffenen Ausf\u00fchrungsformen zwingend zum Einsatz.
\nIn dieser Annahme vermag die Kammer der Kl\u00e4gerin nicht zu folgen. Die Kl\u00e4gerin hat nicht schl\u00fcssig dargetan, dass das Load File DAP zwingend Anwendung findet auf die Nicht-OTA-\u00dcbertragung von Anwendungsprogrammen nach Abschnitt 9 des Standards 23.048, mithin auf das nicht \u00fcber die Luftschnittstelle erfolgende Remote Applet Management der angegriffenen SIM-Karten, auf welche die Kl\u00e4gerin ihre Verletzungsargumentation seit der Replik allein st\u00fctzt.
\nZweifel daran, dass das Load File DAP eine zwingend anzuwendende Methode der Identit\u00e4ts\u00fcberpr\u00fcfung bei der \u00dcbermittlung und Installation von Anwendungsprogrammen darstellt, begr\u00fcndet bereits die Ausgabe 2004 der \u201eInteroperability Stepping Stones\u201c der Interessenvereinigung SIM Alliance (Anlage B5), eines nicht gewinnorientierten Zusammenschlusses der weltweit gr\u00f6\u00dften Hersteller von SIM-Karten, der sich um eine Verbesserung der Interoperabilit\u00e4t zwischen SIM-Karten und Mobiltelefonen bem\u00fcht. Danach findet sich das Load File DAP in der Tabelle in Abschnitt 9.9.3.1 auf Seite 53 der Anlage B5 in der sechsten Zeile als mit \u201eC\u201c (f\u00fcr conditional), nicht jedoch als obligatorisch (mandatory) gekennzeichnet. In den mit \u201eInteroperability Issues\u201c \u00fcberschriebenen Ausf\u00fchrungen auf Seite 54 wird unter dem dritten Hauptpunkt zun\u00e4chst der Wortlaut des Standards 23.048 (Abschnitt A.1.4.1) wiedergegeben und betont, dass es sich bei dem Load File DAP um einen \u201econditional parameter\u201c handele, dessen exakte Erzeugung au\u00dferhalb des Anwendungsbereiches des Standards 23.048 liege. Als Schlussfolgerung hei\u00dft es a.a.O. abschlie\u00dfend, dass gegenw\u00e4rtig keine Interoperabilit\u00e4t unter Verwendung des Load File DAP gew\u00e4hrleistet sei:
\n\u201eConsequently, interoperability cannot currently be guaranteed when managing the load file DAP.\u201d
\nDer dagegen gerichtete Verweis der Kl\u00e4gerin auf die als Anlage K17 vorgelegte Fassung der \u201eInteroperability Stepping Stones, Release 6, Version 1.2.0\u201c von 2006, in der ausweislich der Ausf\u00fchrungen unter Abschnitt 18.2.1 auf Seite 130 den Mitgliedern der SIM Alliance nicht mehr von der Verwendung des Load File DAP abgeraten wird, ist nicht tragf\u00e4hig. Wie sich aus Anlage K17 (Seite 172) ergibt und die Kl\u00e4gerin im Termin nicht bestritten hat, beruht die von ihr vorgelegte Version 1.2.0 auf einem Treffen der SIM Alliance vom 20. Februar 2007, w\u00e4hrend die angegriffenen Ausf\u00fchrungsformen bereits vor diesem Zeitpunkt entwickelt waren und sich bereits am Markt befanden. Den entsprechenden Vortrag der Beklagten im Termin hat die Kl\u00e4gerin nicht bestritten.
\n\u00dcber die Empfehlungen der SIM Alliance hinaus, die anders als der Standard 23.048 keinen Anspruch auf Verbindlichkeit erheben k\u00f6nnen, lassen sich jedoch auch aus dem Standard selbst erhebliche Bedenken dagegen ableiten, dass das Load File DAP auf die drahtgebundene \u00dcbertragung von Anwendungsprogrammen auf SIM-Karten zwingende Anwendung findet, wie die Kl\u00e4gerin behauptet. Der Standard 23.048 selbst legt nicht fest, wie das Feld Load File DAP konkret gebildet wird. In Abschnitt A.1.4.1 (Anlage K10, Seite 28) hei\u00dft es insoweit vielmehr ausdr\u00fccklich (Hervorhebung hier):
\n\u201eThe Load File DAP field is a Cryptographic Checksum, a Digital Signature or an Redundancy Check calculated over the CAP file as transmitted in the subsequent Load commands. The exact generation of this field is outside the scope of the present document.\u201d
\nIn der Tatsache, dass die exakte Erzeugung des Feldes Load File DAP au\u00dferhalb des Standards 23.048 steht, d\u00fcrfte ein Haupthindernis f\u00fcr die praktische Implementierung des Load File DAP liegen, weil aus Sicht der Kartenhersteller die Interoperabilit\u00e4t ohne Standardisierung nicht gew\u00e4hrleistet ist. Dies belegt der vorstehend bereits gew\u00fcrdigte Hinweis der SIM Alliance von 2004 (Anlage B5, Seite 54), dass bei der Verwendung des Load File DAP gegenw\u00e4rtig keine Interoperabilit\u00e4t gew\u00e4hrleistet sei. Die Kl\u00e4gerin sieht in dem vorzitierten Hinweis des Standards 23.048 (\u201eoutside the scope of the present document\u201c) einen schlichten Verweis auf die Open Platform-Spezifikation (Anlage K11), wonach sich alle Angaben, auf die im Standard 23.048 verzichtet wird, aus der Open Platform-Spezifikation ergeben sollen. Unabh\u00e4ngig von der Frage, ob dem in dieser Allgemeinheit zu folgen ist (dazu nachfolgend), bleibt auf der Grundlage des Standards jedenfalls offen, aus welchem Grund das Feld Load File DAP in jedem Fall einen Message Authentication Code (MAC) enthalten sollte, der sich als chiffrierte Signatur im Sinne des Klagepatentes mittels eines Verschl\u00fcsselungsalgorithmus ergibt. Dass das Feld Load File DAP eine \u201cCryptographic Checksum\u201d darstellt, ist in Abschnitt A.1.4.1 nur als eine von drei Varianten neben einer Digital Signature\u201c und einem \u201eRedundancy Check\u201c aufgef\u00fchrt. Bei den letztgenannten alternativen M\u00f6glichkeiten der Sicherheits\u00fcberpr\u00fcfung handelt es sich jedoch um solche, die mit einer Verschl\u00fcsselung nach Ma\u00dfgabe der Merkmalsgruppe 1.2 nichts zu tun haben. Auch die Anmerkung (\u201eNote\u201c) in Abschnitt A.1.4.1 des Standards 23.048, nach welcher der Kartenmanager das Load File DAP verifiziert, nennt alle drei Varianten (\u201eCC, DS or RC\u201c) gleichberechtigt nebeneinander.
\nDass es unabh\u00e4ngig von der Auswahl einer der drei im Standard angesprochenen Varianten des Load File DAP auch nach der Open Platform-Spezifikation nicht einmal zwingend Authentifizierungsdaten im Load File geben muss, belegt deren Abschnitt 6.6.1 (Anlage K11, Seiten 6-10 ff.), der sich mit dem Lade- und Installationsprozess von Daten auf der Chipkarte befasst. Auf ihn beruft sich die Kl\u00e4gerin, weil sich aus den Ausf\u00fchrungen auf Seite 6-10 ergebe, dass der Load File verifiziert werden m\u00fcsse, bevor eine ausf\u00fchrbare Fassung des Load File geschaffen und installiert wird. Nach den Ausf\u00fchrungen auf Seite 6-12 (dritter Hauptpunkt) wird nach vollst\u00e4ndigem Erhalt des Load File (mit Eingang des letzten Load-Befehls) der Load File DAP verifiziert, der in dem Install (for load)-Befehl empfangen wurde. Wie der zweite Unterpunkt belegt, m\u00fcssen im Load File aber keineswegs in jedem Fall Authentifizierungsdaten enthalten gewesen sein (Hervorhebung hier):
\n\u201eif any authentication data was present in the Load File, request the Security Domain associated with each Data Authentication Pattern (DAP) for verification;\u201d
\nEine Verifizierung ist damit auch nach der Open Platform-Spezifikation nur dann vorgesehen, wenn im Einzelfall Authentifizierungsdaten im Load File enthalten sind. Zudem muss selbst dann noch ein Installationsprozess stattfinden (vgl. Anlage K11, Seite 6-13), bevor eine ausf\u00fchrbare Version vorliegt. Dies zeigt, dass das Vorhandensein eines Load File DAP auch nach der Open Platform-Spezifikation nur eine von mehreren M\u00f6glichkeiten zur Verifizierung darstellt und ein Load File DAP keineswegs zwingend als vorhanden vorausgesetzt wird. Dies best\u00e4tigt Anlage K11 (Abschnitt 9.6.2.3, Seite 9-17), indem sie einen DAP-Block innerhalb des Load Files als optional bezeichnet, wenn nicht die den Load File empfangende Karte eine entsprechende Verifikation \u00fcber DAP verlangt:
\n\u201eA DAP block is optional within a Load File unless the card to which the Load File is being transferred contains a Security Domain with Mandated DAP verification privileges.\u201d<\/p>\n

Schlie\u00dflich belegt auch der von der Kl\u00e4gerin als Anlage K16 vorgelegte Auszug aus dem \u201eHandbuch der Chipkarten\u201c von Rankl\/Effing (4. Auflage 2002) nicht, dass es auch au\u00dferhalb der Daten\u00fcbertragung \u00fcber die Luftschnittstelle auf SIM-Karten einen Sicherheitsmechanismus gibt, der gerade in der Benutzung des Load File DAP als \u201eCryptographic Checksum\u201c liegt. Der Auszug Anlage K16 besagt nur, dass auch au\u00dferhalb der Over The Air-Kommunikation Sicherheitsmechanismen f\u00fcr SIM-Karten nach dem Standard GSM 03.48 (dem Vorg\u00e4ngerstandard des Standards 23.048) existieren, benennt diese jedoch nicht. Auch die sachkundige \u00c4u\u00dferung in Anlage K16 trifft damit keine Aussage dar\u00fcber, dass es sich bei den Sicherheitsmechanismen bei einem Remote Applet Management zwingend um solche handelt, die den Load File DAP verwenden. Dies geht konform mit der Aussage in Abschnitt A.1 des Standards 23.048 (Anlage K10, Seite 27), dass \u201ein allen F\u00e4llen\u201c (\u201ein all cases\u201c) die Data Authentication Patterns durch andere Sicherheitsma\u00dfnahmen ersetzt werden sollen.
\nDie Kl\u00e4gerin hat damit nicht dargetan, dass die angegriffenen SIM-Karten auf der Grundlage des Standards zwingend geeignet und in der Lage sein m\u00fcssen, im Rahmen des Remote Applet Management diejenigen Abl\u00e4ufe, aus denen die Kl\u00e4gerin eine Benutzung des Klagepatents ableitet, auszuf\u00fchren. Die Kl\u00e4gerin h\u00e4tte jedoch, um ihrer Darlegungslast zu gen\u00fcgen, aus dem Standard schl\u00fcssig dartun m\u00fcssen, dass standardgem\u00e4\u00df zwingend ein Load File DAP erzeugt und als Grundlage der Verifizierung herangezogen wird, wenn sie die Verletzungsdiskussion – wie geschehen – allein auf der Grundlage des Standards f\u00fchrt.<\/p>\n

2.
\nSelbst wenn man jedoch zugunsten der Kl\u00e4gerin unterstellt, dass eine Benutzung des Load File DAP in der von ihr vorgetragenen Weise zwingender Bestandteil des Standards ist, ergibt sich daraus keine Verwirklichung der technischen Lehre des Klagepatents. Denn es ist nicht ersichtlich, dass bei einer jeden Ausf\u00fchrung des Anwendungsprogramms, das \u00fcber das Remote Applet Management gem\u00e4\u00df Anlagen K10 und K11 auf die SIM-Karte geladen wurde, eine Verifizierung nach Merkmalsgruppe 1.3 stattfindet. Die Kl\u00e4gerin hat vielmehr im Termin selbst ausdr\u00fccklich vorgetragen, dass das Anwendungsprogramm im Zuge des Ladevorgangs einmalig verifiziert und in eine ausf\u00fchrbare Version gebracht werde, eine Verifikation danach jedoch nicht mehr stattfinde.
\nDer Kl\u00e4gerin ist zuzugeben, dass der erkl\u00e4rte Zweck des Klagepatents, ein Anwendungsprogramm dazu zu bef\u00e4higen, dass es \u201esich selbst sch\u00fctzt\u201c (Anlage K3, Seite 4, erster vollst\u00e4ndiger Absatz), auch dann erf\u00fcllt werden kann, wenn die Verifizierung, die diesen Schutz gew\u00e4hrleisten soll, nur einmalig im Sinne einer \u201eFreischaltung\u201c des neuen Anwendungsprogramms stattfindet. Wenn das Anwendungsprogramm hingegen einmal in eine ausf\u00fchrbare Form gebracht wurde, braucht der Vorgang der Verifizierung unter funktionalen Gesichtspunkten nicht bei jeder Ausf\u00fchrung wiederholt zu werden, sofern die Erzeugung einer ausf\u00fchrbaren Form des Anwendungsprogramms seine Verifizierung voraussetzt. Die einmalige \u00dcberpr\u00fcfung, ob das neue Anwendungsprogramm von einem hierzu Berechtigten stammt, der allein Kenntnis von dem auf dem Mikroschaltungs-Datentr\u00e4ger gespeicherten geheimen Code hat, gen\u00fcgt, um das Anwendungsprogramm auf seine Authentizit\u00e4t zu testen und eine ausf\u00fchrbare Fassung nur dann zu erzeugen, wenn die nach Merkmal 1.3.1 gebildete weitere chiffrierte Signatur mit derjenigen, die nach Merkmalen 1.2.1 und 1.2.2 gebildet und gespeichert wurde, \u00fcbereinstimmt. Auch dann k\u00f6nnte im Sinne des Merkmals 1.3.3 davon gesprochen werden, dass der Ablauf des Programms nur in Abh\u00e4ngigkeit von dem Ergebnis des Vergleichs nach Merkmal 1.3.2 zugelassen wird. Dieser \u201eFreischaltungsgedanke\u201c mag bei rein funktionaler Betrachtung daf\u00fcr sprechen, nicht bei jeder Ausf\u00fchrung des Anwenderprogramms (d.h. bei jeder Verwendung der Karte zur Ausf\u00fchrung des betreffenden Programms) eine erneute Verifizierung nach Ma\u00dfgabe der Merkmalsgruppe 1.3 zu verlangen.
\nAllerdings w\u00fcrde dabei nicht hinreichend ber\u00fccksichtigt, dass Anspruch 1 des Klagepatents in der erteilten Fassung die Verfahrensschritte nach Merkmalen 1.3.1 bis 1.3.3 vorsieht, \u201ewenn das Anwenderprogramm ausgef\u00fchrt werden soll\u201c (Merkmal 1.3; in der ma\u00dfgeblichen franz\u00f6sischsprachigen Fassung: \u201equand le programme d\u00b4application doit \u00eatre ex\u00e9cut\u00e9\u201c). Der Schutzbereich des europ\u00e4ischen Patents wird durch den Inhalt der Patentanspr\u00fcche bestimmt, wobei zu ihrer Auslegung die Beschreibung und die Zeichnungen heranzuziehen sind (Art. 69 Abs. 1 EP\u00dc). Dabei darf unter dem Schutzbereich des europ\u00e4ischen Patents nicht der Schutzbereich verstanden werden, der sich aus dem genauen Wortlaut der Patentanspr\u00fcche ergibt, weil Beschreibung und Zeichnungen nur zur Behebung etwaiger Unklarheiten in den Anspr\u00fcchen angewendet werden (Satz 1 des Protokolls \u00fcber die Auslegung des Art. 69 EP\u00dc). Andererseits d\u00fcrfen die Patentanspr\u00fcche auch nicht lediglich als Richtlinie dienen und darf sich der Schutzbereich nicht auch auf das erstrecken, was sich dem Fachmann nach Pr\u00fcfung der Beschreibung und der Zeichnungen als Schutzbegehren des Patentinhabers darstellt (Satz 2 des Protokolls \u00fcber die Auslegung des Art. 69 EP\u00dc). Die Auslegung soll vielmehr zwischen diesen extremen Auffassungen liegen und einen angemessenen Schutz f\u00fcr den Patentinhaber mit ausreichender Rechtssicherheit f\u00fcr Dritte verbinden (Satz 3 des Protokolls \u00fcber die Auslegung des Art. 69 EP\u00dc). Unter Ber\u00fccksichtigung dieser Grunds\u00e4tze wird der Fachmann auf dem Gebiet des Klagepatents zur Auslegung des insoweit interpretationsf\u00e4higen Merkmals 1.3 auch die Beschreibung der technischen Lehre des Klagepatents heranziehen.
\nDabei wird er zun\u00e4chst die allgemeine Beschreibungsstelle auf Seite 4 (vorletzter Absatz) der deutschen \u00dcbersetzung zur Kenntnis nehmen, wo es hei\u00dft (Hervorhebung hier):
\n\u201eWenn dann die Verwendung der Karte gew\u00fcnscht ist, gen\u00fcgt es, bei jeder Verwendung zu pr\u00fcfen, dass die erneute Berechnung der Signatur auf der Grundlage der Programmbefehle und des geheimen Codes genau gleich der bereits eingetragenen Signatur ist.\u201c
\nIn der f\u00fcr die Auslegung nach Art. 70 Abs. 1 EP\u00dc ma\u00dfgeblichen Fassung des Klagepatents in der franz\u00f6sischen Verfahrenssprache lautet der fragliche Abschnitt der Beschreibung wie folgt (Anlage K2, Spalte 3, Zeile 57 bis Spalte 4, Zeile 3, Unterstreichung hier):
\n\u201eQuand on veut utiliser la carte il suffit alors, \u00e0 chaque utilisation de v\u00e9rifier que le calcul \u00e0 nouveau de la signature, sur la base des instructions du programme et du code secret, est bien \u00e9gal \u00e0 la signature d\u00e9j\u00e0 enregistr\u00e9e.\u201c
\nDas Klagepatent stellt mithin in seiner Beschreibung ausdr\u00fccklich auf die Verwendung der Karte ab, nicht auf einen einmaligen Vorgang nach Abschluss des Ladevorgangs des Anwendungsprogramms, der von der gegebenenfalls erst zu einem wesentlich sp\u00e4teren Zeitpunkt stattfindenden Verwendung der Karte und des auf ihr geladenen Anwendungsprogramms v\u00f6llig unabh\u00e4ngig ist. Dar\u00fcber hinaus spricht die zitierte allgemeine Beschreibungsstelle davon, dass bei jeder Verwendung (\u201e\u00e0 chaque utilisation\u201c) zu pr\u00fcfen sei, ob die erneute Berechnung der Signatur genau gleich der bereits eingetragenen Signatur ist. Dem entnimmt der Fachmann auf dem Gebiet des Klagepatents, dass das Anspruchsmerkmal 1.3 \u201ewenn das Anwenderprogramm ausgef\u00fchrt werden soll\u201c so zu verstehen ist, dass immer dann, wenn eine Anwendung des Programms beabsichtigt ist, die Verfahrensschritte nach Merkmalen 1.3.1 bis 1.3.3 zur Ausf\u00fchrung kommen sollen und ein Validierungs- oder Invalidierungssignal erzeugt werden soll. F\u00fcr das weitere Verst\u00e4ndnis der Kl\u00e4gerin, wonach auch eine einmalige Verifizierung ausreichend w\u00e4re, die unabh\u00e4ngig von der sp\u00e4teren Anwendung des Programms im Sinne einer dauerhaft g\u00fcltigen Freischaltung erfolgen k\u00f6nnte, bietet die Beschreibung keine hinreichenden Anhaltspunkte.
\nSolche ergeben sich entgegen der von der Kl\u00e4gerin vertretenen Auffassung auch nicht aus der Beschreibung eines Ausf\u00fchrungsbeispiels auf Seite 9 der Beschreibung in der deutschen \u00dcbersetzung (Anlage K3), wenn es dort am Ende des ersten Absatzes hei\u00dft:
\n\u201eStatt einer einzigen Pr\u00fcfung am Anfang des Programms k\u00f6nnen regelm\u00e4\u00dfige Pr\u00fcfungen w\u00e4hrend des Ablaufs des Programms vorgesehen sein, beispielsweise nach der Ausf\u00fchrung von jeweils zehn Befehlen oder selbst unter der Anleitung des Leseger\u00e4ts, das die Verwendung des Programms bewirkt.\u201c
\nDamit ist lediglich die Alternative angesprochen, die von Merkmal 1.3 grunds\u00e4tzlich am Anfang des Programms (aber durchaus bei einer jeden Ausf\u00fchrung desselben) vorausgesetzte (einzige) Pr\u00fcfung weitergehend auch w\u00e4hrend des Programmablaufs zu wiederholen, also zus\u00e4tzliche \u00dcberpr\u00fcfungen vorzusehen. Eine Ausnahme von der Notwendigkeit, zumindest am Anfang einer jeden Ausf\u00fchrung des Anwendungsprogramms eine \u00dcberpr\u00fcfung nach Ma\u00dfgabe der Verfahrensschritte 1.3.1 bis 1.3.3 durchzuf\u00fchren, stellen die angesprochenen weiteren \u00dcberpr\u00fcfungen w\u00e4hrend des Programmablaufs nicht dar.
\nSchlie\u00dflich sind auch die Ausf\u00fchrungen der Klagepatentschrift zur Anwendung des gesch\u00fctzten Verfahrens im Rahmen des Bezahlfernsehens (Anlage K3, Seite 10\/11) nicht f\u00fcr das von der Kl\u00e4gerin vertretene Verst\u00e4ndnis heranzuziehen, dass anspruchsgem\u00e4\u00df eine einmalige Freischaltung gen\u00fcgen w\u00fcrde. Bei isolierter Betrachtung k\u00f6nnten die S\u00e4tze auf Seite 11 (Zeilen 3 bis 5),
\n\u201eWenn diese Modifikation einmal ausgef\u00fchrt ist, enth\u00e4lt die Karte das neue Programm des Algorithmus NL und die neue Signatur SN. Das neue Programm kann ganz oder teilweise ersetzt worden sein.\u201c
\nso verstanden werden, dass eine einmalige Ausf\u00fchrung der Modifikation gen\u00fcgt. Dieses Verst\u00e4ndnis ist jedoch keineswegs zwingend. Denn erst in den folgenden S\u00e4tzen (Anlage K3, Seite 11, Zeilen 5 bis 9) widmet sich die Beschreibung der Validierung nach Merkmalsgruppe 1.3:
\n\u201eUm die Funktion zu validieren, berechnet der Mikroprozessor der Karte beim Starten des Decodierers eine neue Signatur S\u00b4N (…). Wenn S\u00b4N gleich SN ist, findet die Validierung statt. Im entgegengesetzten Fall findet sie nicht statt.\u201c
\nWenn die Signaturen S\u00b4N und SN aber \u201ebeim Starten des Decodierers\u201c verglichen werden sollen, ist davon auszugehen, dass dies auch bei jedem Starten des Decodierers, mithin bei jeder Anwendung des Programms erfolgen soll, wie dies schon der Auslegung auf der Grundlage der allgemeinen Beschreibung entspricht.
\nDa nach dem eigenen Vorbringen der Kl\u00e4gerin standardgem\u00e4\u00df nur eine einmalige Verifizierung des Anwendungsprogramms erfolgen soll, die danach nicht mehr wiederholt wird, fehlt es (unterstellt, die angegriffenen SIM-Karten w\u00fcrden entsprechend dem Vortrag der Kl\u00e4gerin eine Verifizierung mittels des Load File DAP unterst\u00fctzen) jedenfalls an einer Verwirklichung des Merkmals 1.3.
\nEine Eignung der angegriffenen Ausf\u00fchrungsformen zur Benutzung des Klagepatents im Sinne des \u00a7 10 Abs. 1 PatG kann daher nicht festgestellt werden.<\/p>\n

III.
\nDie Kostenentscheidung beruht auf \u00a7\u00a7 91 Abs. 1 Satz 1 (1. Halbsatz); 269 Abs. 3 Satz 2 ZPO.
\nDie Entscheidungen zur vorl\u00e4ufigen Vollstreckbarkeit folgen aus \u00a7\u00a7 709 Satz 1 und 2; 108 ZPO. Die Voraussetzungen des beantragten Vollstreckungsschutzes (\u00a7 712 ZPO) wegen der Kosten hat die Kl\u00e4gerin weder vorgetragen noch in der durch \u00a7 714 Abs. 2 ZPO gebotenen Weise glaubhaft gemacht.<\/p>\n

Der Streitwert wird auf 1.000.000,00 \u20ac festgesetzt.<\/p>\n","protected":false},"excerpt":{"rendered":"

D\u00fcsseldorfer Entscheidung Nr.: 870 Landgericht D\u00fcsseldorf Urteil vom 17. April 2008, Az. 4a O 37\/07<\/p>\n","protected":false},"author":25,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[28,2],"tags":[],"class_list":["post-3913","post","type-post","status-publish","format-standard","hentry","category-28","category-lg-duesseldorf"],"acf":[],"_links":{"self":[{"href":"https:\/\/d-prax.de\/index.php?rest_route=\/wp\/v2\/posts\/3913","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/d-prax.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/d-prax.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/d-prax.de\/index.php?rest_route=\/wp\/v2\/users\/25"}],"replies":[{"embeddable":true,"href":"https:\/\/d-prax.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3913"}],"version-history":[{"count":1,"href":"https:\/\/d-prax.de\/index.php?rest_route=\/wp\/v2\/posts\/3913\/revisions"}],"predecessor-version":[{"id":3914,"href":"https:\/\/d-prax.de\/index.php?rest_route=\/wp\/v2\/posts\/3913\/revisions\/3914"}],"wp:attachment":[{"href":"https:\/\/d-prax.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3913"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/d-prax.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3913"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/d-prax.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3913"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}