Landgericht Düsseldorf
Urteil vom 17. April 2008, Az. 4a O 37/07

I. Die Klage wird abgewiesen.

II. Die Kosten des Rechtsstreits werden der Klägerin auferlegt.

III. Das Urteil ist gegen Sicherheitsleistung in Höhe von 110 % des jeweils zu vollstreckenden Betrages vorläufig vollstreckbar.
Die Sicherheitsleistung kann auch durch eine unwiderrufliche, unbedingte, unbefristete und selbstschuldnerische Bürgschaft einer in der Europäischen Union als Zoll- oder Steuerbürgin anerkannten Bank oder Sparkasse erbracht werden.

Tatbestand:
Die Klägerin, die als Tochterunternehmen der in Luxemburg ansässigen A S.A. der B-Gruppe angehört, ist seit dem 10. September 2007 in das Patentregister eingetragene Inhaberin des deutschen Teils des europäischen Patents 0 475 xxx B1 (Klagepatent). Aus diesem Schutzrecht nimmt sie die Beklagte auf Unterlassung, Rechnungslegung und Feststellung ihrer Verpflichtung zum Schadensersatz in Anspruch.
Das Klagepatent wurde in französischer Verfahrenssprache am 10. September 1991 unter Inanspruchnahme der Priorität der französischen Anmeldung FR 9011xxx vom 12. September 1990 angemeldet, die Anmeldung am 18. März 1992 offengelegt. Die Veröffentlichung der Erteilung des Klagepatents bei dem Europäischen Patentamt erfolgte am 11. August 1993. Die deutsche Übersetzung des Klagepatents, die unter dem Registerzeichen DE 69 100 xxx T2 geführt wird, liegt als Anlage K3 vor. Über die Nichtigkeitsklage der Beklagten gegen den deutschen Teil des Klagepatents vom 06. August 2007 ist bislang nicht entschieden worden.

Das Klagepatent betrifft ein Verfahren zur Verwaltung eines in einem Mikroschaltungsdatenträger gespeicherten Anwender- bzw. Anwendungsprogramms. Der in erster Linie geltend gemachte Anspruch 1 des Klagepatents lautet in deutscher Übersetzung (Anlage K2, Spalte 11, wortgleich der Anspruchsfassung gemäß der T2-Schrift, Anlage K3, Seite 12) wie folgt:
Verfahren zur Verwaltung eines in einen Mikroschaltungs-Datenträger (2) geladenen Anwenderprogramms mit den folgenden Schritten:
a) zum Laden des Anwenderprogramms:
– wird eine chiffrierte Signatur gebildet, die von einem geheimen Code (10) der Mikroschaltung und bestimmten Befehlen des Programms abhängt,
– diese Signatur wird in einen programmierbaren Speicher (14) der Mikroschaltung geladen,
– das Programm wird in einen Programmspeicher (12) der Mikroschaltung geladen;
b) wenn das Anwenderprogramm ausgeführt werden soll:
– lässt man durch den Mikroprozessor der Mikroschaltung vor der Ausführung des Anwenderprogramms eine weitere chiffrierte Signatur bilden (11),
– diese Signatur wird verglichen (17, 18),
– der Ablauf des Programms wird in Abhängigkeit von dem Ergebnis dieses Vergleichs zugelassen.

Hinsichtlich der im Wege von Insbesondere-Anträgen geltend gemachten Unteransprüche 2, 3 und 4 wird auf die Klagepatentschrift verwiesen. Die nachfolgend leicht verkleinert wiedergegebenen Figuren 1 und 2 der Klagepatentschrift illustrieren das patentgemäße Verfahren anhand einer bevorzugten Ausführungsform:

Die Beklagte, ein Technologieunternehmen mit Sitz in Paderborn, das Systemlösungen auf Basis von Kartentechnologie, unter anderem im Bereich der Telekommunikation, entwickelt, stellt unter anderem her und vertreibt SIM-Karten (Subscriber Identity Module) für Mobiltelefone unter der Bezeichnung „C“. Zur „C“-Kartenfamilie der Beklagten gehören drei Typen von Karten, die unter den Bezeichnungen „C native“, „C ON“ und „C SMART“ vertrieben werden (nachfolgend auch: angegriffene Ausführungsformen). Als Anlagen K7, K8 und K9 liegen die Produktbroschüren der angegriffenen Ausführungsformen vor.
Wie zwischen den Parteien unstreitig ist, unterstützen die angegriffenen Ausführungsformen die letzten 3GPP-Normen, insbesondere die technische Spezifikation 3GPP TS23.048 OTA „Remote File & Remote Application Management“, die auch als GSM 03.48 OTA „Remote File & Remote Application Management“ 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 „Global Platform – Open Platform Card Specification Version 2.0.1“ vom 07. April 2000, das die Klägerin in Kopie als Anlage K11 vorgelegt hat. Diese Spezifikation beschreibt Sicherheitsmechanismen für SIM-Anwendungen.
Die Abkürzung „OTA“ steht für eine Datenübertragung über die Luftschnittstelle (Over The Air). Die Unterstützung von OTA-Möglichkeiten erlaubt es dem Mobilfunkbetreiber, aus der Entfernung GSM-Dateien zu aktualisieren und die Karte auch noch nach ihrer Ausgabe zu personalisieren. So heißt es in den Produktbroschüren der angegriffenen Ausführungsformen im Wesentlichen gleichlautend (vgl. Anlagen K7, K8, K9, jeweils Seite 2, linke Spalte):
“The support of OTA capabilities allows Mobile Operators to remotely update […] specific” beziehungsweise “GSM files, thus providing post-issuance personalization capabilities.”

Die Klägerin ist unter Berufung auf die Ausführungen in den als Anlagen K10 und K11 vorliegenden Standards der Ansicht, die angegriffenen Ausführungsformen seien in der Lage, von sämtlichen Merkmalen des Klagepatentanspruchs 1 Gebrauch zu machen. Die Klägerin hatte zunächst 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ände offensichtlich sei, dass die Anwendung des Verfahrens ohne Zustimmung der Klägerin verboten sei und verstoße damit gegen § 9 Satz 2 Nr. 2 PatG; daneben meinte sie, der Beklagten gestützt auf § 10 Abs. 1 PatG untersagen lassen zu können, SIM-Karten für das Verfahren des Klagepatents anzubieten oder zu liefern. Vor der letzten mündlichen Verhandlung hat die Klägerin ihren Klageantrag auf eine mittelbare Verletzung des Klagepatents durch Angebot und Lieferung der angegriffenen Ausführungsformen beschränkt.

Die Klägerin beantragt nunmehr,

I. die Beklagte zu verurteilen,

1. es bei Meidung eines für jeden Fall der Zuwiderhandlung vom Gericht festzusetzenden Ordnungsgeldes bis zu 250.000,– € – ersatzweise Ordnungshaft – oder Ordnungshaft bis zu sechs Monaten, im Falle wiederholter Zuwiderhandlung Ordnungshaft bis zu zwei Jahren,
in der Bundesrepublik Deutschland zu unterlassen,
Abnehmern im Gebiet der Bundesrepublik Deutschland SIM-Karten anzubieten und/oder zu liefern, die geeignet und bestimmt sind, im Gebiet der Bundesrepublik Deutschland für die Anwendung eines
1.1 Verfahrens zur Verwaltung eines in einen Mikroschaltungs-Datenträger geladenen Anwenderprogramms mit den folgenden Schritten:
1.2 zum Laden des Anwenderprogramms:
1.2.1 wird eine chiffrierte Signatur gebildet, die von einem geheimen Code der Mikroschaltung und bestimmten Befehlen des Programms abhängt;
1.2.2 diese Signatur wird in einen programmierbaren Speicher der Mikroschaltung geladen,
1.2.3 das Programm wird in einen Programmspeicher der Mikroschaltung geladen;
1.3 wenn das Anwenderprogramm ausgeführt werden soll:
1.3.1 lässt man durch den Mikroprozessor der Mikroschaltung vor der Ausführung des Anwenderprogramms eine weitere chiffrierte Signatur bilden,
1.3.2 diese Signatur wird verglichen und
1.3.3 der Ablauf des Programms wird in Abhängigkeit von dem Ergebnis dieses Vergleichs zugelassen
verwendet zu werden,
insbesondere, wenn
das Programm in einem programmierbaren und löschbaren Speicher gespeichert wird
und/oder
ein geheimer Code in die Mikroschaltung geladen wird, wobei dieser Code der Bildung der Signatur gewidmet ist
und/oder
die Bildung der weiteren Signatur und der Vergleich dieser Signatur erst im Augenblick des Ladens des Anwenderprogramms in den Arbeitsspeicher erfolgt;

2. der Klägerin 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
a) der einzelnen Lieferungen, aufgeschlüsselt nach Liefermengen, -zeiten und -preisen sowie der Namen und Anschriften der Empfänger;
b) der einzelnen Angebote, aufgeschlüsselt nach Angebotsmengen, -zeiten und –preisen sowie der Namen und Anschriften der Angebotsempfänger;
c) der betriebenen Werbung, aufgeschlüsselt nach Werbeträgern, deren Auflagenhöhe, Verbreitungszeitraum und Verbreitungsgebiet;
d) der mit dem Verkauf der Mikroprozessorkarte gemäß Ziffer I. 1. erzielten Umsätze sowie des hierdurch erzielten Gewinns,
wobei es der Beklagten gestattet ist, die Namen und Anschriften der Angebotsempfänger und der nicht-gewerblichen Abnehmer statt der Klägerin einem durch die Klägerin zu benennenden öffentlich bestellten Wirtschaftsprüfer mitzuteilen, der gegenüber der Klägerin zur Verschwiegenheit verpflichtet ist, sofern die Beklagte die durch die Einführung des öffentlich bestellten Wirtschaftsprüfers verursachten Kosten trägt und den öffentlich bestellten Wirtschaftsprüfer ermächtigt, der Klägerin auf Befragen darüber Auskunft zu geben, ob bestimmte Abnehmer, Angebotsempfänger und/oder Lieferungen in der Rechnung enthalten sind;

II. festzustellen, dass die Beklagte verpflichtet ist, der Klägerin 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,

III. hilfsweise: Vollstreckungsschutz wegen der Kosten.

Die Beklagte beantragt,
die Klage abzuweisen,

hilfsweise,
die Verhandlung bis zum Abschluss des von der Beklagten gegen das Klagepatent eingeleiteten Nichtigkeitsverfahrens auszusetzen.

Die Beklagte bestreitet, dass die angegriffenen „C“ SIM-Karten zur Ausführung des klagepatentgemäßen Verfahrens geeignet seien. Insbesondere komme in den angegriffenen Ausführungsformen der „Load File DAP“ nicht zum Einsatz, auf den sich die Verletzungsargumentation der Klägerin gründet. Der „Load File DAP“ sei als Funktionalität in den angegriffenen SIM-Karten nicht implementiert.
Des Weiteren werde sich das Klagepatent im anhängigen Nichtigkeitsklageverfahren als nicht rechtsbeständig erweisen, weshalb die Verhandlung jedenfalls auszusetzen sei.

Dem tritt die Klägerin entgegen.

Wegen weiterer Einzelheiten des Sach- und Streitstandes wird auf die eingereichten Schriftsätze nebst Anlagen Bezug genommen.

Entscheidungsgründe:
Die Klage ist zulässig, jedoch nicht begründet.
Der Klägerin stehen die geltend gemachten Ansprüche auf Unterlassung, Schadensersatz und Rechnungslegung aus Art. 64 EPÜ in Verbindung mit §§ 10 Abs. 1; 139 Abs. 1 und 2; 140b Abs. 1 und 2 PatG; §§ 242; 259 BGB nicht zu. Sie hat nicht schlüssig dargelegt, dass die angegriffenen „C“ SIM-Karten der Beklagten objektiv geeignet sind, das Verfahren, das Gegenstand des Klagepatents ist, auszuüben (§ 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ägerin allein anhand des Standards und des Load File DAP geführte Verletzungsdiskussion kann eine Benutzung des Klagepatents durch die angegriffenen Ausführungsformen aber allenfalls dann belegen, wenn dieser standardgemäß zwingend zur Anwendung kommt und nicht nur optional vorgesehen ist. Zum anderen hat die Klägerin nicht dargelegt, dass die von ihr vorgetragene Identifizierung gemäß dem Standard nach Anlage K10 anspruchsgemäß im Sinne des Merkmals 1.3 bei einer jeden Ausführung des Anwendungsprogramms erfolgt.

I.
Das Klagepatent betrifft ein Verfahren zur Verwaltung eines in einen Mikroschaltungs-Datenträger 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äger in einer bevorzugten Anwendung eine sogenannte elektronische Chipkarte darstellt.
Nach den Ausführungen des Klagepatents enthält ein Mikroschaltungs-Datenträger einerseits einen Träger und andererseits eine elektronische Schaltung, die auf der Oberfläche des Trägers mit Mitteln für die Kommunikation mit der Außenwelt 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önnen – wie die Klagepatentbeschreibung erläutert – drei Speichertypen unterschieden werden: Ein flüchtiger Arbeitsspeicher (RAM-Speicher, für Random Access Memory, Speicher mit wahlfreiem Zugriff) wird von der Central Processing Unit (CPU, dem Hauptprozessor als Herzstück des Mikroschaltungs-Datenträgers) 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äßig flüchtig (volatil), das heißt die auf ihnen gespeicherten Daten gehen nach Abschaltung der Stromzufuhr verloren. Eine Mikroschaltung enthält ferner einen Festwertspeicher (ROM- oder Programmspeicher, ROM für Read Only Memory), der das Anwendungsprogramm enthält und normalerweise vom Benutzer nicht von außen programmiert werden kann. Er ist nur lesbar, im normalen Betrieb jedoch nicht beschreibbar, und (verständlicherweise) nicht flüchtig, das heißt er behält 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ültig verhindert, was im Allgemeinen durch Unterbrechung einer Sicherung geschieht. Als dritten Speichertyp beschreibt die Klagepatentschrift elektrisch programmierbare und löschbare Speicher, beispielsweise vom Typ EEPROM (für Electrically Erasable Programmable Read Only Memory, also elektrisch löschbarer, 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üchtig. Zur Ausführung der im ROM-Speicher enthaltenen Anwendungsprogramme können die auszuführenden Befehle entweder durch den Mikroprozessor direkt im ROM-Speicher abgelesen werden oder zuvor in den RAM-Speicher übertragen werden, von wo aus sie durch den Mikroprozessor ausgeführt werden (Klagepatentschrift, Anlage K3, Seite 1 bis Seite 2, zweiter Absatz).
Wie die Klagepatentbeschreibung weiter ausführt (Anlage K3, Seite 2, dritter und Seiten 2 und 3 übergreifender Absatz), können 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 Übersetzung der Beschreibung heißt) „unwiderrufliche Unterbrechung der Schreibzugriffssicherung in einem Speicher vom EPROM-Typ“ (gemeint ist erkennbar eine unwiderrufliche Sicherung gegen späteren Schreibzugriff auf die in einem Speicher vom EPROM-Typ gespeicherten Daten) die unlöschbare Programmierung der von ihnen gewünschten Anwendungen. Aus Sicherheitsgründen 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änkt (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ünschte der Ausgeber (Diensteanbieter) dies, musste er nach dem Stand der Technik stets die Herstellung vollständig neuer Chipkarten mit neuen Mikroschaltungen in Auftrag geben. Eine Weiterentwicklung war daher nur dadurch möglich, 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 übergreifender Absatz a.E.).
Andererseits können die Anwendungsprogramme aus Sicherheitsgründen auch nicht schlicht in einen wieder beschreibbaren Speicher der Mikroschaltung geschrieben werden, was dem Dienstanbieter die Möglichkeit schaffen würde, immer dann, wenn er eine neue Dienstleistung bereitstellen will, einfach die entsprechenden neuen Anwendungsprogramme in den veränderbaren Speicher der bestehenden Mikroschaltung zu schreiben. Denn in diesem Fall könnten auch nicht autorisierte Personen gefälschte Anwendungsprogramme in existierende Chipkarten einspeisen, etwa ein unbefugter Dritter ein manipuliertes Bankanwendungsprogramm auf die Karte laden (vgl. Anlage K3, Seite 3, dritter Absatz).

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önnen, ohne andererseits die Gefahr eines unautorisierten Zugriffs in Kauf nehmen zu müssen. Als Kern der vorgeschlagenen technischen Lösung beschreibt es die Klagepatentschrift (Anlage K3, Seite 4, erster vollständiger Absatz), dass von der Anwendung gefordert wird, dass sie sich selbst schützt.

Die zur Lösung dieses Problems vorgeschlagene Lösung lautet, nach Merkmalen gegliedert, wie folgt:

1.1 Verfahren zur Verwaltung eines in einen Mikroschaltungs-Datenträger (2) geladenen Anwenderprogramms mit den folgenden Schritten:
1.2 zum Laden des Anwenderprogramms:
1.2.1 wird eine chiffrierte Signatur gebildet, die von einem geheimen Code (10) der Mikroschaltung und bestimmten Befehlen des Programms abhängt,
1.2.2 diese Signatur wird in einen programmierbaren Speicher (14) der Mikroschaltung geladen,
1.2.3 das Programm wird in einen Programmspeicher (12) der Mikroschaltung geladen;
1.3 wenn das Anwenderprogramm ausgeführt werden soll:
1.3.1 lässt man durch den Mikroprozessor der Mikroschaltung vor der Ausführung des Anwenderprogramms eine weitere chiffrierte Signatur bilden (11),
1.3.2 diese Signatur wird verglichen (17, 18),
1.3.3 der Ablauf des Programms wird in Abhängigkeit von dem Ergebnis dieses Vergleichs zugelassen.

Der allgemeine Teil der Beschreibung (Anlage K3, Seite 4, erster und zweiter Absatz) erläutert, dass anspruchsgemäß in die „sich selbst schützende“ Anwendung ein Chiffrierprogramm eingebaut werde, das die Aufgabe habe, eine Signatur auf der Grundlage einerseits eines der Karte eigentümlichen 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üsse periodisch vom Mikroprozessor gestartet werden, wobei sich sein Ablauf auf die Befehle der Anwendung stütze. Da die Signatur selbst in den Datenspeicher der Karte geladen und in diesem Speicher vollständig 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ämtliche 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önne daher in einem programmierbaren und löschbaren Speicher gespeichert sein, während der Chiffrieralgorithmus nur im nichtprogrammierbaren Festwertspeicher gespeichert sei.
Wenn dann die Verwendung der Karte gewünscht sei, genüge es, bei jeder Verwendung zu überprüfen, 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ängigkeit 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ädt hingegen ein nicht autorisierter Dritter eine Anwendung auf die Chipkarte, so wird das Ergebnis der Berechnung der Signatur verändert, die dann nicht mehr mit der im Speicher der Mikroschaltung gespeicherten Signatur übereinstimmt, mit der Folge, dass die Mikroschaltung nicht länger funktioniert. In Unkenntnis des geheimen Codes der Chipkarte ist ein nicht autorisierter Dritter nicht in der Lage, die richtige Signatur für das gefälschte Anwendungsprogramm auszuarbeiten.

II.
Die Klägerin hat auf der Grundlage des Standards „3GPP TS 23.048 V4.5.0 (2005-06)“ (Anlage K10, nachfolgend auch: Standard 23.048), mit dem die angegriffenen Ausführungsformen unstreitig konform sind, nicht schlüssig dargelegt, dass diese im Sinne des § 10 Abs. 1 PatG für eine Benutzung des vom Klagepatent geschützten Verfahrens geeignet sind.
Zum einen ist eine Verwendung des Load File DAP entgegen der von der Klägerin vertretenen Auffassung im Rahmen des Standards 23.048, der auf das Dokument „Global Platform – Open Platform Card Specification version 2.0.1“ vom 07. April 2000 (Anlage K11; nachfolgend auch: Open Platform-Spezifikation) verweist, nicht obligatorisch (nachfolgend unter 1.). Aus der schlichten Konformität der angegriffenen SIM-Karten mit dem Standard 23.048 lässt sich der von der Klägerin darzulegende und erforderlichenfalls zu beweisende Benutzungstatbestand daher nicht ableiten. Zum anderen ist Merkmal 1.3 des Klagepatentes, das eine Durchführung der eine Verifikation des Anwendungsprogramms darstellenden Verfahrensschritte 1.3.1 bis 1.3.3 verlangt, „wenn das Anwenderprogramm ausgeführt werden soll“, mithin bei jeder Ausführung des Anwendungsprogramms, nicht erfüllt. Denn auch nach dem Vortrag der Klägerin soll standardgemäß in Verbindung mit der Open Platform-Spezifikation nur eine einmalige Verifikation im Anschluss an das vollständige Laden stattfinden, wenn das Anwendungsprogramm in eine ausführbare Form gebracht wird, danach jedoch nicht mehr. Nach dem Gegenstand des Klagepatents, wie er sich für den Fachmann auf dem Gebiet des Klagepatents aus dem Patentanspruch unter Berücksichtigung der Beschreibung und der Zeichnungen ergibt, ist eine Ausführung der Verfahrensschritte nach Merkmalsgruppe 1.3 jedoch immer dann erforderlich, wenn das Anwendungsprogramm ausgeführt werden soll (vgl. unter 2.).

1.
Die Klägerin sieht eine Verwirklichung der Lehre des Klagepatents in den in Abschnitt 9 des Standards 23.048 behandelten „Open Platform commands for Remote Applet Management“, also in denjenigen Befehlen, die für eine Verwaltung (d.h. ein Laden, eine Installation oder ein Entfernen) von Anwendungsprogrammen auf Chipkarten (UICC für Universal Integrated Circuit bzw. Chip Card) und damit Mikroschaltungs-Datenträgern im Sinne des Klagepatents vorgesehen sind. Dabei ist nach dem Vortrag der Klägerin 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äß Abschnitt 9.1.2, mit welchem dem Netzwerkbetreiber oder Diensteanbieter erlaubt wird, ein neues Anwendungsprogramm auf der Chipkarte zu installieren.
Der Verletzungsvorwurf der Klägerin stützt 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 Übersetzung wiedergegeben) eine „kryptografische Überprüfungssumme, eine digitale Signatur oder eine Redundanzüberprüfung, die über die CAD-Datei berechnet wird, wie sie in den darauf folgenden Load-Befehlen übertragen wird“, darstelle. Das Kürzel DAP steht dabei für Data Authentication Pattern (vgl. Anlage K10, Seite 9, Liste der Abkürzungen 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ür Cryptographic Checksum), DS (für Digital Signature) oder RC (für Redundancy Check) durch den Kartenmanager verifiziert. Der in Abschnitt A.1.4 des Standards 23.048 behandelte Install (Load)-Befehl soll („shall“) nach der Open Platform-Spezifikation (Anlage K11) codiert werden, die als Referenz [14] auf Seite 6 des Standards 23.048 ausdrücklich in Bezug genommen wird.
Zur Definition des Load File Data Block DAP beruft sich die Klägerin 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ät eines Load File Data Blocks, der den tatsächlichen Code der Anwendung enthält, zu verifizieren. Über einen kryptografischen (d.h. Verschlüsselungs-) Algorithmus werde eine digitale Signatur bzw. ein Nachrichtenauthentifizierungscode (Message Authentication Code, MAC) über den vollständigen 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ützungsinformation für die Anwendungen enthält, wie es durch die spezifische Plattform erforderlich ist, mit anderen Worten: ein Datenblock, der den Code des Anwendungsprogramms enthält. Aus Sicht des Klagepatents könnten darin die „bestimmten Befehle des Programms“ im Sinne des Merkmals 1.2.1 gesehen werden. Die Klägerin meint, in Verbindung mit dem geheimen Code, der sich in dem für die Verschlüsselung 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.
Die Beklagte wendet sich grundlegend gegen den dargelegten Ansatz der Klägerin, die angenommene Benutzung der technischen Lehre des Klagepatents über das Data Authentication Pattern (DAP) zu begründen, 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ür den Install-Befehl in unmittelbarem Zusammenhang mit der grundsätzlichen Referenz auf die Open Platform-Spezifikation (Anlage K11) darauf hin, dass die Hinweise auf DAP-Felder in der Spezifikation für das OTA Application Management nicht gelten. Wortgleiche Ausschlüsse 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ünden, 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ält, diejenige Integrität sein solle, die man durch den Gebrauch einer kryptografischen Prüfsumme oder digitalen Signatur erhält. In allen Fällen solle diese Sicherheit die bei Open-Platform-Befehlen für eine sichere Nachrichtenübermittlung verwendeten Data Authentication Patterns ersetzen. Nach den klaren Anweisungen des Standards 23.048 im Zusammenhang mit den Install-Befehlen kämen bei der Übertragung von Daten im GSM- oder UMTS-Standard auf eine SIM-Karte über 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.
Für die Datenübertragung und Programmverwaltung über die Luftschnittstelle stellt die Klägerin nicht in Abrede, dass das Load File DAP gemäß 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 über ein Terminal mit einer Lese- und Schreibvorrichtung geladen werden könnten, 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 über einen Personal-Computer in Verbindung mit einem Mobilfunkgerät. Für ein solches drahtgebundenes Laden komme das Load File DAP auch nach dem Standard 23.048 und damit bei den angegriffenen Ausführungsformen zwingend zum Einsatz.
In dieser Annahme vermag die Kammer der Klägerin nicht zu folgen. Die Klägerin hat nicht schlüssig dargetan, dass das Load File DAP zwingend Anwendung findet auf die Nicht-OTA-Übertragung von Anwendungsprogrammen nach Abschnitt 9 des Standards 23.048, mithin auf das nicht über die Luftschnittstelle erfolgende Remote Applet Management der angegriffenen SIM-Karten, auf welche die Klägerin ihre Verletzungsargumentation seit der Replik allein stützt.
Zweifel daran, dass das Load File DAP eine zwingend anzuwendende Methode der Identitätsüberprüfung bei der Übermittlung und Installation von Anwendungsprogrammen darstellt, begründet bereits die Ausgabe 2004 der „Interoperability Stepping Stones“ der Interessenvereinigung SIM Alliance (Anlage B5), eines nicht gewinnorientierten Zusammenschlusses der weltweit größten Hersteller von SIM-Karten, der sich um eine Verbesserung der Interoperabilität zwischen SIM-Karten und Mobiltelefonen bemüht. 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 „C“ (für conditional), nicht jedoch als obligatorisch (mandatory) gekennzeichnet. In den mit „Interoperability Issues“ überschriebenen Ausführungen auf Seite 54 wird unter dem dritten Hauptpunkt zunächst der Wortlaut des Standards 23.048 (Abschnitt A.1.4.1) wiedergegeben und betont, dass es sich bei dem Load File DAP um einen „conditional parameter“ handele, dessen exakte Erzeugung außerhalb des Anwendungsbereiches des Standards 23.048 liege. Als Schlussfolgerung heißt es a.a.O. abschließend, dass gegenwärtig keine Interoperabilität unter Verwendung des Load File DAP gewährleistet sei:
„Consequently, interoperability cannot currently be guaranteed when managing the load file DAP.”
Der dagegen gerichtete Verweis der Klägerin auf die als Anlage K17 vorgelegte Fassung der „Interoperability Stepping Stones, Release 6, Version 1.2.0“ von 2006, in der ausweislich der Ausführungen 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ähig. Wie sich aus Anlage K17 (Seite 172) ergibt und die Klägerin 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ährend die angegriffenen Ausführungsformen bereits vor diesem Zeitpunkt entwickelt waren und sich bereits am Markt befanden. Den entsprechenden Vortrag der Beklagten im Termin hat die Klägerin nicht bestritten.
Über die Empfehlungen der SIM Alliance hinaus, die anders als der Standard 23.048 keinen Anspruch auf Verbindlichkeit erheben können, lassen sich jedoch auch aus dem Standard selbst erhebliche Bedenken dagegen ableiten, dass das Load File DAP auf die drahtgebundene Übertragung von Anwendungsprogrammen auf SIM-Karten zwingende Anwendung findet, wie die Klägerin 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ßt es insoweit vielmehr ausdrücklich (Hervorhebung hier):
„The 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.”
In der Tatsache, dass die exakte Erzeugung des Feldes Load File DAP außerhalb des Standards 23.048 steht, dürfte ein Haupthindernis für die praktische Implementierung des Load File DAP liegen, weil aus Sicht der Kartenhersteller die Interoperabilität ohne Standardisierung nicht gewährleistet ist. Dies belegt der vorstehend bereits gewürdigte Hinweis der SIM Alliance von 2004 (Anlage B5, Seite 54), dass bei der Verwendung des Load File DAP gegenwärtig keine Interoperabilität gewährleistet sei. Die Klägerin sieht in dem vorzitierten Hinweis des Standards 23.048 („outside the scope of the present document“) 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ängig 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üsselungsalgorithmus ergibt. Dass das Feld Load File DAP eine “Cryptographic Checksum” darstellt, ist in Abschnitt A.1.4.1 nur als eine von drei Varianten neben einer Digital Signature“ und einem „Redundancy Check“ aufgeführt. Bei den letztgenannten alternativen Möglichkeiten der Sicherheitsüberprüfung handelt es sich jedoch um solche, die mit einer Verschlüsselung nach Maßgabe der Merkmalsgruppe 1.2 nichts zu tun haben. Auch die Anmerkung („Note“) in Abschnitt A.1.4.1 des Standards 23.048, nach welcher der Kartenmanager das Load File DAP verifiziert, nennt alle drei Varianten („CC, DS or RC“) gleichberechtigt nebeneinander.
Dass es unabhängig 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ägerin, weil sich aus den Ausführungen auf Seite 6-10 ergebe, dass der Load File verifiziert werden müsse, bevor eine ausführbare Fassung des Load File geschaffen und installiert wird. Nach den Ausführungen auf Seite 6-12 (dritter Hauptpunkt) wird nach vollständigem 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üssen im Load File aber keineswegs in jedem Fall Authentifizierungsdaten enthalten gewesen sein (Hervorhebung hier):
„if any authentication data was present in the Load File, request the Security Domain associated with each Data Authentication Pattern (DAP) for verification;”
Eine 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ührbare Version vorliegt. Dies zeigt, dass das Vorhandensein eines Load File DAP auch nach der Open Platform-Spezifikation nur eine von mehreren Möglichkeiten zur Verifizierung darstellt und ein Load File DAP keineswegs zwingend als vorhanden vorausgesetzt wird. Dies bestätigt 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 über DAP verlangt:
„A 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.”

Schließlich belegt auch der von der Klägerin als Anlage K16 vorgelegte Auszug aus dem „Handbuch der Chipkarten“ von Rankl/Effing (4. Auflage 2002) nicht, dass es auch außerhalb der Datenübertragung über die Luftschnittstelle auf SIM-Karten einen Sicherheitsmechanismus gibt, der gerade in der Benutzung des Load File DAP als „Cryptographic Checksum“ liegt. Der Auszug Anlage K16 besagt nur, dass auch außerhalb der Over The Air-Kommunikation Sicherheitsmechanismen für SIM-Karten nach dem Standard GSM 03.48 (dem Vorgängerstandard des Standards 23.048) existieren, benennt diese jedoch nicht. Auch die sachkundige Äußerung in Anlage K16 trifft damit keine Aussage darüber, 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 „in allen Fällen“ („in all cases“) die Data Authentication Patterns durch andere Sicherheitsmaßnahmen ersetzt werden sollen.
Die Klägerin hat damit nicht dargetan, dass die angegriffenen SIM-Karten auf der Grundlage des Standards zwingend geeignet und in der Lage sein müssen, im Rahmen des Remote Applet Management diejenigen Abläufe, aus denen die Klägerin eine Benutzung des Klagepatents ableitet, auszuführen. Die Klägerin hätte jedoch, um ihrer Darlegungslast zu genügen, aus dem Standard schlüssig dartun müssen, dass standardgemäß 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ührt.

2.
Selbst wenn man jedoch zugunsten der Klägerin 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ührung des Anwendungsprogramms, das über das Remote Applet Management gemäß Anlagen K10 und K11 auf die SIM-Karte geladen wurde, eine Verifizierung nach Merkmalsgruppe 1.3 stattfindet. Die Klägerin hat vielmehr im Termin selbst ausdrücklich vorgetragen, dass das Anwendungsprogramm im Zuge des Ladevorgangs einmalig verifiziert und in eine ausführbare Version gebracht werde, eine Verifikation danach jedoch nicht mehr stattfinde.
Der Klägerin ist zuzugeben, dass der erklärte Zweck des Klagepatents, ein Anwendungsprogramm dazu zu befähigen, dass es „sich selbst schützt“ (Anlage K3, Seite 4, erster vollständiger Absatz), auch dann erfüllt werden kann, wenn die Verifizierung, die diesen Schutz gewährleisten soll, nur einmalig im Sinne einer „Freischaltung“ des neuen Anwendungsprogramms stattfindet. Wenn das Anwendungsprogramm hingegen einmal in eine ausführbare Form gebracht wurde, braucht der Vorgang der Verifizierung unter funktionalen Gesichtspunkten nicht bei jeder Ausführung wiederholt zu werden, sofern die Erzeugung einer ausführbaren Form des Anwendungsprogramms seine Verifizierung voraussetzt. Die einmalige Überprüfung, ob das neue Anwendungsprogramm von einem hierzu Berechtigten stammt, der allein Kenntnis von dem auf dem Mikroschaltungs-Datenträger gespeicherten geheimen Code hat, genügt, um das Anwendungsprogramm auf seine Authentizität zu testen und eine ausführbare 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, übereinstimmt. Auch dann könnte im Sinne des Merkmals 1.3.3 davon gesprochen werden, dass der Ablauf des Programms nur in Abhängigkeit von dem Ergebnis des Vergleichs nach Merkmal 1.3.2 zugelassen wird. Dieser „Freischaltungsgedanke“ mag bei rein funktionaler Betrachtung dafür sprechen, nicht bei jeder Ausführung des Anwenderprogramms (d.h. bei jeder Verwendung der Karte zur Ausführung des betreffenden Programms) eine erneute Verifizierung nach Maßgabe der Merkmalsgruppe 1.3 zu verlangen.
Allerdings würde dabei nicht hinreichend berücksichtigt, dass Anspruch 1 des Klagepatents in der erteilten Fassung die Verfahrensschritte nach Merkmalen 1.3.1 bis 1.3.3 vorsieht, „wenn das Anwenderprogramm ausgeführt werden soll“ (Merkmal 1.3; in der maßgeblichen französischsprachigen Fassung: „quand le programme d´application doit être exécuté“). Der Schutzbereich des europäischen Patents wird durch den Inhalt der Patentansprüche bestimmt, wobei zu ihrer Auslegung die Beschreibung und die Zeichnungen heranzuziehen sind (Art. 69 Abs. 1 EPÜ). Dabei darf unter dem Schutzbereich des europäischen Patents nicht der Schutzbereich verstanden werden, der sich aus dem genauen Wortlaut der Patentansprüche ergibt, weil Beschreibung und Zeichnungen nur zur Behebung etwaiger Unklarheiten in den Ansprüchen angewendet werden (Satz 1 des Protokolls über die Auslegung des Art. 69 EPÜ). Andererseits dürfen die Patentansprüche auch nicht lediglich als Richtlinie dienen und darf sich der Schutzbereich nicht auch auf das erstrecken, was sich dem Fachmann nach Prüfung der Beschreibung und der Zeichnungen als Schutzbegehren des Patentinhabers darstellt (Satz 2 des Protokolls über die Auslegung des Art. 69 EPÜ). Die Auslegung soll vielmehr zwischen diesen extremen Auffassungen liegen und einen angemessenen Schutz für den Patentinhaber mit ausreichender Rechtssicherheit für Dritte verbinden (Satz 3 des Protokolls über die Auslegung des Art. 69 EPÜ). Unter Berücksichtigung dieser Grundsätze wird der Fachmann auf dem Gebiet des Klagepatents zur Auslegung des insoweit interpretationsfähigen Merkmals 1.3 auch die Beschreibung der technischen Lehre des Klagepatents heranziehen.
Dabei wird er zunächst die allgemeine Beschreibungsstelle auf Seite 4 (vorletzter Absatz) der deutschen Übersetzung zur Kenntnis nehmen, wo es heißt (Hervorhebung hier):
„Wenn dann die Verwendung der Karte gewünscht ist, genügt es, bei jeder Verwendung zu prüfen, dass die erneute Berechnung der Signatur auf der Grundlage der Programmbefehle und des geheimen Codes genau gleich der bereits eingetragenen Signatur ist.“
In der für die Auslegung nach Art. 70 Abs. 1 EPÜ maßgeblichen Fassung des Klagepatents in der französischen Verfahrenssprache lautet der fragliche Abschnitt der Beschreibung wie folgt (Anlage K2, Spalte 3, Zeile 57 bis Spalte 4, Zeile 3, Unterstreichung hier):
„Quand on veut utiliser la carte il suffit alors, à chaque utilisation de vérifier que le calcul à nouveau de la signature, sur la base des instructions du programme et du code secret, est bien égal à la signature déjà enregistrée.“
Das Klagepatent stellt mithin in seiner Beschreibung ausdrücklich 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äteren Zeitpunkt stattfindenden Verwendung der Karte und des auf ihr geladenen Anwendungsprogramms völlig unabhängig ist. Darüber hinaus spricht die zitierte allgemeine Beschreibungsstelle davon, dass bei jeder Verwendung („à chaque utilisation“) zu prüfen 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 „wenn das Anwenderprogramm ausgeführt werden soll“ 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ührung kommen sollen und ein Validierungs- oder Invalidierungssignal erzeugt werden soll. Für das weitere Verständnis der Klägerin, wonach auch eine einmalige Verifizierung ausreichend wäre, die unabhängig von der späteren Anwendung des Programms im Sinne einer dauerhaft gültigen Freischaltung erfolgen könnte, bietet die Beschreibung keine hinreichenden Anhaltspunkte.
Solche ergeben sich entgegen der von der Klägerin vertretenen Auffassung auch nicht aus der Beschreibung eines Ausführungsbeispiels auf Seite 9 der Beschreibung in der deutschen Übersetzung (Anlage K3), wenn es dort am Ende des ersten Absatzes heißt:
„Statt einer einzigen Prüfung am Anfang des Programms können regelmäßige Prüfungen während des Ablaufs des Programms vorgesehen sein, beispielsweise nach der Ausführung von jeweils zehn Befehlen oder selbst unter der Anleitung des Lesegeräts, das die Verwendung des Programms bewirkt.“
Damit ist lediglich die Alternative angesprochen, die von Merkmal 1.3 grundsätzlich am Anfang des Programms (aber durchaus bei einer jeden Ausführung desselben) vorausgesetzte (einzige) Prüfung weitergehend auch während des Programmablaufs zu wiederholen, also zusätzliche Überprüfungen vorzusehen. Eine Ausnahme von der Notwendigkeit, zumindest am Anfang einer jeden Ausführung des Anwendungsprogramms eine Überprüfung nach Maßgabe der Verfahrensschritte 1.3.1 bis 1.3.3 durchzuführen, stellen die angesprochenen weiteren Überprüfungen während des Programmablaufs nicht dar.
Schließlich sind auch die Ausführungen der Klagepatentschrift zur Anwendung des geschützten Verfahrens im Rahmen des Bezahlfernsehens (Anlage K3, Seite 10/11) nicht für das von der Klägerin vertretene Verständnis heranzuziehen, dass anspruchsgemäß eine einmalige Freischaltung genügen würde. Bei isolierter Betrachtung könnten die Sätze auf Seite 11 (Zeilen 3 bis 5),
„Wenn diese Modifikation einmal ausgeführt ist, enthält die Karte das neue Programm des Algorithmus NL und die neue Signatur SN. Das neue Programm kann ganz oder teilweise ersetzt worden sein.“
so verstanden werden, dass eine einmalige Ausführung der Modifikation genügt. Dieses Verständnis ist jedoch keineswegs zwingend. Denn erst in den folgenden Sätzen (Anlage K3, Seite 11, Zeilen 5 bis 9) widmet sich die Beschreibung der Validierung nach Merkmalsgruppe 1.3:
„Um die Funktion zu validieren, berechnet der Mikroprozessor der Karte beim Starten des Decodierers eine neue Signatur S´N (…). Wenn S´N gleich SN ist, findet die Validierung statt. Im entgegengesetzten Fall findet sie nicht statt.“
Wenn die Signaturen S´N und SN aber „beim Starten des Decodierers“ 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.
Da nach dem eigenen Vorbringen der Klägerin standardgemäß nur eine einmalige Verifizierung des Anwendungsprogramms erfolgen soll, die danach nicht mehr wiederholt wird, fehlt es (unterstellt, die angegriffenen SIM-Karten würden entsprechend dem Vortrag der Klägerin eine Verifizierung mittels des Load File DAP unterstützen) jedenfalls an einer Verwirklichung des Merkmals 1.3.
Eine Eignung der angegriffenen Ausführungsformen zur Benutzung des Klagepatents im Sinne des § 10 Abs. 1 PatG kann daher nicht festgestellt werden.

III.
Die Kostenentscheidung beruht auf §§ 91 Abs. 1 Satz 1 (1. Halbsatz); 269 Abs. 3 Satz 2 ZPO.
Die Entscheidungen zur vorläufigen Vollstreckbarkeit folgen aus §§ 709 Satz 1 und 2; 108 ZPO. Die Voraussetzungen des beantragten Vollstreckungsschutzes (§ 712 ZPO) wegen der Kosten hat die Klägerin weder vorgetragen noch in der durch § 714 Abs. 2 ZPO gebotenen Weise glaubhaft gemacht.

Der Streitwert wird auf 1.000.000,00 € festgesetzt.