6 W (pat) Ep 3/14

BPatG 253 08.05 BUNDESPATENTGERICHT IM NAMEN DES VOLKES 6 Ni 3/14 (EP) (Aktenzeichen) URTEIL Verkündet am 31. Juli 2014 … In der Patentnichtigkeitssache … - 2 - betreffend das europäische Patent 0 932 865 (DE 697 14 752) hat der 6. Senat (Nichtigkeitssenat) des Bundespatentgerichts auf Grund der mündlichen Verhandlung vom 31. Juli 2014 durch den Vorsitzenden Richter Voit, die Richterin Kortge, den Richter Dipl.-Phys. Dr. Schwengelbeck, die Richterin Dipl.-Phys. Univ. Dr. Otten-Dünnweber und den Richter Dipl.-Ing. Altvater für Recht erkannt: I. Das europäische Patent 0 932 865 wird im Umfang des Pa- tentanspruchs 1 mit Wirkung für das Hoheitsgebiet der Bun- desrepublik Deutschland für nichtig erklärt. II. Die Kosten des Rechtsstreits trägt die Beklagte. III. Das Urteil ist im Kostenpunkt gegen Sicherheitsleistung in Höhe von 120 % des zu vollstreckenden Betrages vorläufig vollstreckbar. T a t b e s t a n d Die Beklagte ist Inhaberin des auch mit Wirkung für das Hoheitsgebiet der Bun- desrepublik Deutschland erteilten europäischen Patents 0 932 865 (Streitpatent), das aus der PCT-Anmeldung PCT/US97/18999 - veröffentlicht am 7. Mai 1998 als WO 98/19237 A1 - hervorgeht und am 22. Oktober 1997 unter Inanspruchnahme der Priorität der US-amerikanischen Patentanmeldung 29,057 vom 25. Oktober 1996 angemeldet worden ist. Das Streitpatent ist in der Verfahrens- sprache Englisch veröffentlicht und wird beim Deutschen Patent- und Markenamt unter der Nummer DE 697 14 752 geführt. Es trägt die Bezeichnung: „Using a high level programming language with a microcontroller” (übersetzt: „Verwendung einer hohen Programmiersprache in einem Mikrokontroller“) und umfasst in der erteilten - 3 - Fassung 33 Ansprüche, von denen nur der Anspruch 1 angegriffen wird. An- spruch 1 lautet in der Verfahrenssprache Englisch wie folgt: „1. A microcontroller (10) having a set of resource constraints and comprising: a memory, an interpreter (16) loaded in memory and operating within the set of resource constraints, the microcon- troller (10) characterized by having: at least one application loaded in the memory to be interpreted by the interpreter, wherein the at least one application is gen- erated by a programming environment comprising: a) a compiler (22) for compiling application source pro- grams (20) in high level language source code form into a compiled form (24), b) a converter (26) for post processing the compiled form (24) into a minimized form (27) suitable for interpreta- tion by the interpreter (16).” In der deutschen Übersetzung hat Anspruch 1 folgenden Wortlaut: „1. Ein Mikrocontroller (10) mit einem Set von Ressourcen- Vorgaben und bestehend aus: einem Speicher, einem im Speicher geladenen Interpreter (16), welcher innerhalb des Sets von Ressourcen-Vorgaben funktioniert, dem Mikrocon- troller (10), dadurch gekennzeichnet, dass er: mindestens eine durch den Interpreter zu übersetzende im Speicher geladene Applikation hat, wobei mindestens eine Applikation durch eine Programmierungsumgebung generiert wird, die folgenden Elementen umfasst: - 4 - a) einem Compiler (22), welcher Anwendungs-Quellpro- gramme (20) in Quellcodeform höherer Programmier- sprache in eine kompilierte Form (24) kompiliert, b) einem Konverter (26) zur Umformatierung der kompi- lierten Form (24) in eine sich zur Übersetzung durch den Interpreter (16) eignende minimierte Form (27).“ Im Übrigen wird auf die Streitpatentschrift EP 0 932 865 B1 (NK1) und deren deut- sche Übersetzung DE 697 14 752 T2 (NK2) Bezug genommen. Die Klägerin macht den Nichtigkeitsgrund der mangelnden Patentfähigkeit des Gegenstands des erteilten Anspruchs 1 geltend (Art. II § 6 Abs. 1 Nr. 1 IntPatÜG i. V. m. Art. 138 Abs. 1 Buchstabe a) EPÜ). Als weiteren Nichtigkeitsgrund führt sie die unzulässige Erweiterung an (Art. II § 6 Abs. 1 Nr. 3 IntPatÜG i. V. m. Art. 138 Abs. 1 Buchstabe c) EPÜ). Sie bezieht sich dabei auf folgenden Stand der Technik: NK5 Dissertation von Olivier Caron, „Méthodologies de conception et d’évaluation d’architectures R.I.S.C. adaptées aux futures cartes à micro- processeur”, vom 20. Januar 1994, Universität Lille mit deutscher Überset- zung NK5a; NK6a Olivier Caron et al., „New architectures for smart cards: the OCEAN ap- proach”, in Proceedings of the Third International Workshop on Hard- ware/Software Codesign, Grenoble, 1994, Seiten 148 bis 155, mit deutscher Übersetzung NK6c; NK6b Olivier Caron u. Georges Grimonprez, „OCEAN: A C compiler for new smart card applications“, in Proceedings of the International Conference in Com- piler Construction, April 1994, Edinburgh, Seiten 31 bis 39, mit deutscher Übersetzung NK6d; NK7 FR 2 667 171 A1 mit deutscher Übersetzung NK7a NK8 JavaTM Card API Frequently Asked Questions, Version 1.1, October 25, 1996, mit deutscher Übersetzung NK8a; - 5 - NK9 Abbildung 64 auf Seite 115 der NK5 NK10 „Sun Microsystems, Inc. Announces Java Card API“, Pressemitteilung vom 29. Oktober 1996 auf der Internetseite der Sun Microsystems, Inc. (www.sun.com), Auszug aus dem Internet-Archiv (web.archive.org) vom 20. Dezember 1996; NK11 Java Commerce Home Page mit Hinweis auf Java Card API, Auszug aus dem Internet-Archiv (web.archive.org) vom 8. Juni 1997; NK12 Scott B. Guthery, „Java Card: Internet Computing on a smart card“, in IEEE Internet Computing, Januar/Februar 1997, Vol. 1, No. 1, Seiten 57 bis 59; NK15 Bildschirmfoto der NK11 mit Download-Link; NK16 „PersonalJava and EmbeddedJava Development Tools“, Internetseite www.javasoft.com vom 30. September 1997, Auszug der aus dem Internet- Archiv (web.archive.org) vom 8. Oktober 1997. Die Klägerin ist der Auffassung, der Gegenstand des erteilten Anspruchs 1 sei gegenüber den Druckschriften NK5, NK6a mit NK6b, NK7, NK8 und NK16 weder neu, noch beruhe er - auch unter Berücksichtigung der NK12 - auf erfinderischer Tätigkeit. Insbesondere könnten dessen Software-Merkmale den beanspruchten Mikrocontroller nicht erfinderisch weiterbilden. Sie verweist dazu auf BPatG, Urt. v. 14. November 2013 – 2 Ni 4/12 (EP), BeckRS 2014, 08225. Die Druckschriften NK10 und NK11 belegten, dass die Entgegenhaltung NK8 vor dem Anmeldetag des Streitpatents öffentlich zugänglich gewesen sei. Dem erteilten Anspruch 1 stehe auch nicht der Anmeldetag der Prioritätsanmeldung zu, weil sich diese aus- schließlich auf Applikationen in der Programmiersprache Java beziehe. Ferner sei er im Hinblick auf die Verallgemeinerung von Konsolidieren und Komprimieren in Minimieren und in Bezug auf die generalisierte Form des Interpreters und des Konverters unzulässig erweitert. - 6 - Die Klägerin beantragt, das europäische Patent 0 932 865 im Umfang des Patentan- spruchs 1 für das Hoheitsgebiet der Bundesrepublik Deutschland für nichtig zu erklären. Die Beklagte beantragt, die Klage kostenpflichtig abzuweisen, hilfsweise verteidigt sie das Streitpatent gemäß dem mit Schrift- satz vom 14. Februar 2013 eingereichten Hilfsantrag 1, weiter hilfsweise nach Maßgabe der Hilfsanträge 2 bis 5 im Schriftsatz vom 23. Mai 2014. In der Fassung des Hilfsantrags 1, der eine Kombination der erteilten Ansprüche 1 und 3 darstellt, lautet Patentanspruch 1 wie folgt (Änderungen gegenüber der Fassung gemäß Streitpatentschrift sind durch Unterstreichung kenntlich gemacht): „1. A microcontroller (10) having a set of resource constraints and comprising: a memory, an interpreter (16) loaded in memory and operating within the set of re- source constraints, the microcontroller (10) characterized by having: at least one application loaded in the memory to be interpreted by the interpreter, wherein the at least one application is generated by a programming environment comprising: a) a compiler (22) for compiling application source programs (20) in high level language source code form into a compiled form (24), b) a converter (26) for post processing the compiled form (24) into a minimized form (27) suitable for interpretation by the interpreter (16). wherein the compiled form (24) is in a standard Java class file format and the con- verter (26) accepts as input compiled form (24) in the standard Java class file for- mat and produces output (27) in a form suitable for interpretation by the interpreter (16).” - 7 - Hilfsantrag 2 ist gegenüber der Fassung gemäß Hilfsantrag 1 in der letzten Merk- malsgruppe wie folgt geändert (Änderungen gegenüber Hilfsantrag 1 sind durch Unterstreichung kenntlich gemacht): „1. A microcontroller […] wherein the compiled form (24) is in a standard Java class file format and the con- verter (26) accepts as input compiled form (24) in the standard Java class file for- mat and produces output (27) in a class file format suitable for interpretation by the interpreter (16).” Hilfsantrag 3 ist gegenüber der Fassung gemäß Hilfsantrag 2 in der letzten Merk- malsgruppe wie folgt geändert (Änderungen gegenüber Hilfsantrag 2 sind durch Streichung bzw. Unterstreichung kenntlich gemacht): „1. A microcontroller […] wherein the compiled form (24) is constituted by a plurality of Java class files in a standard Java class file format and the converter (26) accepts as input the com- piled form (24) in the standard Java class file format and produces as output (27) in a single class file in a form format suitable for interpretation by the interpreter (16).” Hilfsantrag 4 hat gegenüber der Fassung gemäß Hilfsantrag 3 in der letzten Merkmalsgruppe folgenden geänderten Wortlaut (Änderungen gegenüber Hilfsan- trag 3 sind durch Unterstreichung kenntlich gemacht): „1. A microcontroller […] wherein the compiled form (24) is constituted by a plurality of Java class files in a standard Java class file format and the converter (26) accepts as input the com- piled form (24) in the standard Java class file format and produces as output (27) a single class file in a class file format suitable for interpretation by the interpreter (16).” - 8 - Hilfsantrag 5 ist gegenüber der Fassung gemäß Hilfsantrag 4 wie folgt geändert (Änderungen gegenüber Hilfsantrag 4 sind durch Unterstreichung kenntlich ge- macht): „1. A microcontroller (10) having a set of resource constraints and comprising: a memory, an interpreter (16) loaded in memory and operating within the set of re- source constraints, the microcontroller (10) characterized by having: at least one application loaded in the memory to be interpreted by the interpreter, wherein the at least one application is generated by a programming environment comprising: a) a compiler (22) for compiling application source programs (20) in high level language Java source code form into a compiled form (24), b) a converter (26) for post processing the compiled form (24) into a minimized form (27) suitable for interpretation by the interpreter (16). wherein the compiled form (24) is constituted by a plurality of Java class files in a standard Java class file format and the converter (26) accepts as input the com- piled form (24) in the standard Java class file format and produces as output (27) a single class file in a class file format suitable for interpretation by the interpreter (16).” Die Beklagte hält den Gegenstand des Anspruchs 1 in der erteilten Fassung, zu- mindest aber die Anspruchsfassung gemäß eines ihrer Hilfsanträge, gegenüber sämtlichen Angriffen für patentfähig, im Gegensatz zu den Ausführungen der Klä- gerin. Der Senat hat den Parteien mit Schriftsatz vom 1. April 2014 einen frühen gericht- lichen Hinweis gemäß § 83 Abs. 1 PatG zukommen lassen. Wegen weiterer Einzelheiten wird auf das Protokoll der mündlichen Verhandlung sowie auf den gesamten Akteninhalt, insbesondere auf die Schriftsätze der Par- teien mit sämtlichen Anlagen Bezug genommen. - 9 - E n t s c h e i d u n g s g r ü n d e Die zulässige Klage ist begründet. Sie führt zur Nichtigerklärung des Streitpatents im Umfang des Patentanspruchs 1 mit Wirkung für das Hoheitsgebiet der Bundes- republik Deutschland, denn der Anspruch 1 des Streitpatents hat weder in der er- teilten Fassung noch in einer der von der Beklagten hilfsweise beantragten Fas- sungen Bestand (Art. II § 6 Abs. 1 Nr. 1 IntPatÜG, Art. 138 Abs. 1 Buchst. a, Art. 56 EPÜ). I. 1. Soweit die Beklagte den Angriff der Klägerin auf die Neuheit und die erfinderi- sche Tätigkeit des Streitpatents insbesondere in der Fassung der Hilfsan- träge 2 bis 5 mittels der NK16 als verspätet gerügt hat, ist dies nicht begrün- det. Der am 2. Juli 2014 per Telefax eingegangene Schriftsatz der Klägerin mit der Druckschrift NK16 ist innerhalb der einmonatigen Frist bei Gericht eingegan- gen, die im frühen gerichtlichen Hinweis für eine Stellungnahme auf gegneri- sches Vorbringen gesetzt worden war. Da der zum gerichtlichen Hinweis Stellung nehmende Schriftsatz der Beklagten vom 23. Mai 2014 mit ihren Hilfsanträgen 2 bis 5 am 2. Juni 2014 an die Klägerin zugestellt worden ist, hat die einmonatige Erwiderungsfrist für die Klägerin erst am 2. Juli 2014 geendet. Die Ausführungen der Klägerin, dass dem erteilten Anspruch 1 auch nicht der Anmeldetag der Prioritätsanmeldung zustehe, gehen ins Leere, da die im Hin- blick auf die erfinderische Tätigkeit relevante Druckschrift NK7 bereits am 27. März 2002 und damit lange vor dem Anmeldetag des Streitpatents und dem strittigen Prioritätsdatum veröffentlicht worden ist. - 10 - 2. Das Streitpatent betrifft einen Mikrocontroller bzw. die Verwendung einer ho- hen Programmiersprache in einem Mikrocontroller (vgl. Bezeichnung des Streitpatents in der deutschen Übersetzung, DE 697 14 752 T2). Das Streitpatent geht dabei beispielgebend vom Einsatz von Java als höherer Programmiersprache in einem in seinen Ressourcen begrenzten Mikrocon- troller, insbesondere in einer Chipkarte, aus. Für typischerweise in einer Chip- karte angewandte Mikrocontroller gebe es keine herkömmlichen Java-Imple- mentierungen, sondern diese würden üblicherweise nur für Mikroprozessoren bereitgestellt (ebd., S. 2, Zn. 14-19 und Z. 29 bis S. 3, Z. 3). Zudem würden Applikationen für Chipkarten wegen der vorgegebenen begrenzten Ressour- cen typischerweise in einer niedrigen Programmiersprache (z. B. Assembler- Sprache) geschrieben, um Speicherplatz zu sparen (ebd., S. 4, zweiter Abs.). Das Streitpatent beschreibt sinngemäß weiter, dass die Einführung öffentlicher Digitalnetzwerke (z. B. Internet) den Chipkarten neue Anwendungsgebiete er- öffnet habe, was zu einem Bedarf an neuen, auf die Karte ladbaren Anwen- dungen geführt habe. Da diese Anwendungen jedoch die Kartensicherheit nicht kompromittieren sollen, könnten hierzu typischerweise keine herkömmli- chen Karten verwendet werden, die in niedrigen Sprachen programmiert seien (ebd., S. 6, zweiter Abs.). Software-Anwendungen seien in JAVA so konzipiert, dass sie ohne Änderun- gen auf verschiedenen Plattformen lauffähig sind, wobei zur Ausführung der Anwendungen eine so genannte JAVA Virtual Machine (JVM) benötigt werde, die zusammen mit den Bibliotheken als JAVA Runtime Environment (JRE) diene. Damit eine Java-Applikation auf einer spezifischen Plattform ablauffähig sei, müsse eine Java Virtual Machine-Implementierung bereitgestellt werden, welche innerhalb der Plattform-Vorgaben funktioniere. Um eine Anwendung ausführen zu können, würde diese in Byte-Code enthaltende Klassendateien kompiliert, wobei es sich beim Byte-Code um Anweisungen für die Java Virtual Machine (JVM) handele. Solle eine Java-Anwendung dann auf einer be- stimmten Plattform zum Ablauf gebracht werden, werde der vorher kompi- - 11 - lierte, als Klassendateien vorliegende Byte-Code durch die Java Virtual Ma- chine für die gewählte Plattform interpretiert (ebd., S. 1, Z. 10 bis S. 2, Z. 13). Zu bekannten Möglichkeiten der Programmierung von Chipkarten mit höheren Programmiersprachen im Stand der Technik wird im Streitpatent auf die fran- zösische Patentanmeldung FR 2 667 171 A1 (Druckschrift NK7) verwiesen. Als Nachteil dieses Standes der Technik benennt das Streitpatent, dass dort keine Themenbereiche im Zusammenhang mit der Datensicherheit angespro- chen würden oder wie eine Programmierungsumgebung bereitgestellt werden könne, die einen Programmierer befähige, ein Programm für eine Chipkarte in einer Programmiersprache wie JAVA zu erstellen und das Programm mittels einem Interpreter auf der Chipkarte, welcher innerhalb der Ausführungsvorga- ben der Chipkarte arbeitet, ausführen zu können (vgl. DE 697 14 752 T2, S. 4, dritter Abs.). Die Beschreibung des Streitpatents nennt keine explizite Aufgabe; lediglich bei der Würdigung des Standes der Technik wird als dessen Nachteil auf das Fehlen von Sicherheitsmechanismen verwiesen. Die objektive technische Problemstellung, d.h. das durch die Erfindung – für den Fachmann erkennbar – tatsächlich zu lösende technische Problem (vgl. bspw. BGH, Urt. v. 23. Januar 1990 – X ZR 75/87, GRUR 1991, 522 – Feuerschutzabschluss; BGH, Urt. v. 12. Februar 2003 – X ZR 200/99, GRUR, 2003, 693 – Hochdruck- reiniger) besteht darin, einen Mikrocontroller in einer hohen Programmierspra- che zu programmieren, wobei die Programmierung den besonderen techni- schen Randbedingungen („set of resource constraints“) des Mikrocontrollers Rechnung tragen soll. Diese Aufgabe richtet sich an einen Fachmann, der Ingenieur der Elektrotech- nik oder Technischen Informatik mit Hochschulabschluss ist und der eine mehrjährige Erfahrung in der Programmierung von Mikrocontroller-basierten Systemen und dem damit verbundenen Gebiet der Software-Programmie- rungsumgebungen vorweist. - 12 - Zur Lösung der angesprochenen Problemstellung sieht das Streitpatent in An- spruch 1 vor, dass der Mikrocontroller einen in den Speicher geladenen Inter- preter aufweist, welcher innerhalb eines Sets von Ressourcen-Vorgaben des Mikrocontrollers funktioniert und der eine in den Speicher geladene Applika- tion übersetzen kann. Die Applikation soll hierzu durch eine Programmie- rungsumgebung generiert werden, die einen Compiler zum Kompilieren des Anwendungs-Quellprogramms und einen Konverter zum Umwandeln der kompilierten Form in eine sich zur Übersetzung (d. h. zum Interpretieren) durch den Interpreter eignende minimierte Form aufweist. 3. Patentanspruch 1, mit dem die Beklagte das Patent gemäß Hauptantrag verteidigt, lautet unter Hinzufügen einer Gliederung: M1 „A microcontroller (10) having a set of resource constraints and comprising: M1.1 a memory, M1.2 an interpreter (16) loaded in memory and M1.2.1 operating within the set of resource constraints, the microcontroller (10) characterized by having: M2 at least one application loaded in the memory to be interpreted by the interpreter, M2.1 wherein the at least one application is generated by a programming environment comprising: M2.1.1 a) a compiler (22) for compiling application source pro- grams (20) in high level language source code form into a compiled form (24), - 13 - M2.1.2 b) a converter (26) for post processing the compiled form (24) into a minimized form (27) suitable for interpretation by the interpreter (16).“ In deutscher Übersetzung lautet der mit einer Merkmalsgliederung versehene erteilte Patentanspruch 1 (Hauptantrag) wie folgt: M1 „Ein Mikrocontroller (10) mit einem Set von Ressourcen-Vorgaben und bestehend aus: M1.1 einem Speicher, M1.2 einem im Speicher geladenen Interpreter (16), M1.2.1 welcher innerhalb des Sets von Ressourcen-Vorgaben funktio- niert, dem Mikrocontroller (10), dadurch gekennzeichnet, dass er: M2 mindestens eine durch den Interpreter zu übersetzende im Speicher geladene Applikation hat, M2.1 wobei mindestens eine Applikation durch eine Programmie- rungsumgebung generiert wird, die folgenden Elementen um- fasst: M2.1.1 a) einem Compiler (22), welcher Anwendungs-Quellpro- gramme (20) in Quellcodeform höherer Programmierspra- che in eine kompilierte Form (24) kompiliert, M2.1.2 b) einem Konverter (26) zur Umformatierung der kompilierten Form (24) in eine sich zur Übersetzung durch den Interpreter (16) eignende minimierte Form (27).“ Patentanspruch 1 gemäß Hilfsantrag 1 fügt dem Anspruch 1 gemäß Hauptan- trag im Anschluss an Merkmal M2.1.2 die folgenden Merkmale hinzu: - 14 - M2.1.3 „wherein the compiled form (24) is in a standard Java class file for- mat and M2.1.4 the converter (26) accepts as input compiled form (24) in the standard Java class file format and produces output (27) in a form suitable for interpretation by the interpreter (16).” Patentanspruch 1 gemäß Hilfsantrag 2 basiert auf Hilfsantrag 1 und unter- scheidet sich von diesem im geänderten Merkmal M2.1.4* (Änderungen ge- genüber Hilfsantrag 1 sind durch Unterstreichung hervorgehoben): M2.1.4* „the converter (26) accepts as input compiled form (24) in the standard Java class file format and produces output (27) in a class file format suitable for interpretation by the interpreter (16).” Patentanspruch 1 gemäß Hilfsantrag 3 basiert auf Hilfsantrag 1 und unter- scheidet sich von diesem in den geänderten Merkmalen M2.1.3* und M2.1.4** (Änderungen gegenüber Hilfsantrag 1 sind durch Unterstreichung hervorge- hoben): M2.1.3* „wherein the compiled form (24) is constituted by a plurality of Java class files in a standard Java class file format and M2.1.4** the converter (26) accepts as input the compiled form (24) in the standard Java class file format and produces as output (27) a sin- gle class file in a form suitable for interpretation by the interpreter (16).” Patentanspruch 1 gemäß Hilfsantrag 4 verbindet die Änderungen des Hilfsan- trags 2 mit den Änderungen des Hilfsantrags 3 in den Merkmalen M2.1.3* und M2.1.4*** (Änderungen gegenüber Hilfsantrag 1 sind durch Unterstreichung hervorgehoben): - 15 - M2.1.3* „wherein the compiled form (24) is constituted by a plurality of Java class files in a standard Java class file format and M2.1.4*** the converter (26) accepts as input the compiled form (24) in the standard Java class file format and produces as output (27) a sin- gle class file in a class file format suitable for interpretation by the interpreter (16).” Patentanspruch 1 gemäß Hilfsantrag 5 basiert auf Anspruch 1 gemäß Hilfsan- trag 4 unter Änderung des Merkmals M2.1.1* (Änderungen gegenüber Hilfs- antrag 4 sind durch Unterstreichung hervorgehoben): M2.1.1* „a) a compiler (22) for compiling application source programs (20) in high level language Java source code form into a compiled form (24),” 4. Einzelne Merkmale und Merkmalsgruppen der verteidigten Fassungen des Anspruchs 1 bedürfen der Auslegung. In Abgrenzung zu einem Mikroprozessor beinhaltet ein Mikrocontroller im Sinne des Streitpatents eine CPU, eine Speichereinheit und weitere Funkti- onselemente auf einem einzigen Haltleitersubstrat oder einem einzigen inte- grierten Schaltkreis. Der Mikrocontroller weist gemäß der deutschen Fassung des Streitpatents ein Set von „Ressourcen-Vorgaben“ auf (englische Fassung des Streitpatents: „set of resource constraints“; vgl. jeweils Anspruch 1, Merk- male M1, M1.2.1); dabei wird auf die Größe des Speichers verwiesen, auf die ein Mikrocontroller üblicherweise Zugriff hat (vgl. deutsche Fassung des Streitpatents, S. 2, Z. 26 – S. 3, Z. 3). Hinweise auf eine „Vorgabe“ der Res- sourcen finden sich in der Beschreibung nicht. Es handelt sich somit entspre- chend der englischen Fassung des Streitpatents um ein Set von Ressourcen- Beschränkungen des Mikrocontrollers. - 16 - Unter einem Compiler wird in der Regel ein Programm verstanden, das ein Quellprogramm, das in einer bestimmten Programmiersprache geschrieben ist, in ein Format übersetzt, das von einem Computer ausgeführt werden kann. Bei diesem Format kann es sich um eine vom Computer direkt ausführbare Maschinensprache oder auch um einen Byte-Code handeln. Ein Byte-Code ist in der Regel ein hardwareunabhängiger Zwischencode, der von einem Inter- preter meist zur Laufzeit in Maschinensprache übersetzt wird. Im Anspruch 1 des Streitpatents ist die vom Compiler erzeugte kompilierte Form des Anwen- dungs-Quellprogramms ein Zwischencode, der durch einen Konverter nach- bearbeitet und in eine für die Übersetzung durch den Interpreter geeignete Form gebracht wird. In der deutschsprachigen Fassung des Streitpatents wird für die Funktion des Compilers der Begriff „Kompilieren“ (engl. Fassung: „compiling“; vgl. Anspruch 1, Merkmal M2.1.1), für die Funktion des Interpre- ters der Begriff „Übersetzung“ verwendet (engl. Fassung: „interpretation“; vgl. Merkmale M2, M2.1.2). Bei klassenbasierten Programmiersprachen liegt der kompilierte Zwischen- code als Klassendateien in einem Klassendateiformat (engl. Fassung: „class file format“) vor. Ein Beispiel einer solchen klassenbasierten Programmier- sprache, die einen in Klassendateien vorliegenden Byte-Code als Zwischen- code und eine virtuelle Maschine als Interpreter verwendet, ist Java. In den Ausführungsbeispielen des Streitpatents dient eine „Java Virtual Machine“ („JVM“) als Interpreter einer Applikation, die in eine Chipkarte geladen ist, wo- bei die kompilierte Anwendung in einem Java-Klassendateiformat vorliegt. Der Begriff Klassendateiformat („class file format“) wird dabei in seiner üblichen Bedeutung für das Dateiformat eines als Klassendatei vorliegenden kompi- lierten und interpretierbaren Codes einer klassenbasierten Programmierspra- che verwendet (vgl. bspw. deutsche Fassung des Streitpatents, S. 37, Zn. 17- 24). Das Streitpatent unterscheidet hierbei zwischen einem standardmäßigen Java-Klassendateiformat (engl. Fassung: „standard Java class file format“) und einem kompakteren Karten-Klassendateiformat (engl. Fassung: „card class file format“), das für eine Verwendung in Chipkarten angepasst ist und - 17 - auf dem Standard-Java Klassendateiformat basiert (vgl. Streitpatent, Be- schreibung zu Fig. 3 und 4 sowie Anhang A). Der Patentanspruch 1 des Streitpatents weist funktionelle Merkmale zum Er- zeugen eines Anwendungscodes (d. h. zum Erzeugen der in den Speicher des Mikrocontrollers zu ladenden Applikation) einer Programmierungsumgebung auf, die außerhalb des beanspruchten Mikrocontrollers in einer Programmie- rungsumgebung ablaufen (vgl. Merkmale M2.1.1, M2.1.2). Bei Sachansprü- chen, bei denen der beanspruchte Gegenstand zumindest teilweise nicht un- mittelbar durch (räumlich-körperlich oder funktionell umschriebene) Sach- merkmale, sondern durch ein Verfahren definiert ist, ist nach höchstrichterli- cher Rechtsprechung durch Auslegung des Patentanspruchs zu ermitteln, ob und inwieweit sich aus dem angegebenen Verfahren Merkmale ergeben, die den Anspruchsgegenstand qualifizieren (vgl. BGH, Urt. v. 19. Juni 2001 – X ZR 159/98,GRUR 2001, 1129, Leitsatz - Zipfelfreies Stahlband; BGH, Urt. v. 19. Mai 2005 – X ZR 188/01, GRUR 2005, 749, dritter Leitsatz - Aufzeich- nungsträger). Anspruch 1 des Streitpatents sieht in den Merkmalen M2.1 bis M2.1.2 Verfah- rensschritte zur Erzeugung des Anwendungscodes vor, der nach Merkmal M2 in den Speicher des Mikrocontrollers geladen und durch einen Interpreter in- terpretiert werden soll. Da der erteilte Anspruch 1 als Vorrichtungsanspruch auf einen Mikrocontroller gerichtet ist, kann dieser durch die Verfahrensmerk- male zur Erzeugung des geladenen Anwendungscodes in einer Programmie- rungsumgebung nur insofern charakterisiert werden, wie diese Verfahrens- merkmale eindeutig ihren Niederschlag in dem erzeugten Anwendungscode selbst finden und dieser Code – und damit der Mikrocontroller – dadurch von einem auf anderem Wege generierten Anwendungscode unterscheidbar ist. Die einzige Anforderung, welche der in den Mikrocontroller geladene Anwen- dungscode nach dem erteilten Anspruch 1 erfüllen muss, ist dessen Eignung, vom Interpreter interpretiert werden zu können („[…] suitable for interpretation by the interpreter“; vgl. Merkmale M2.1 bis M2.1.2). Diese Anforderung lässt jedoch für den Fachmann anhand des Anwendungscodes keine gesicherten - 18 - Rückschlüsse auf die Zahl oder Art der Erzeugungsschritte oder die Eigen- schaften des Quellprogramms bzw. eines kompilierten, nachbearbeiteten Zwi- schencodes zu. Denn weitergehende Angaben, aus denen eindeutig Inhalte des in den Speicher des Mikrocontrollers geladenen Anwendungscodes selbst ableitbar wären, sind den Verfahrensmerkmalen zur Codeerzeugung des er- teilten Anspruchs 1 nicht zu entnehmen. Dies gilt in gleicher Weise für die weiteren verteidigten Fassungen des Anspruchs 1 in den Hilfsanträgen 1 bis 5. Das Streitpatent sieht vor, dass ein Konverter in Bezug auf eine kompilierte Form des Anwendungsprogramms ein Ergebnis in „minimierter Form“ erzeugt (engl. Fassung: „a minimized form suitable for interpretation by the inter- preter“, vgl. Merkmal M2.1.2). Der Begriff „minimiert“ findet in den ursprünglich eingereichten Anmeldungsunterlagen jedoch keine Verwendung. Mit der Ver- arbeitung des Anwendungscodes durch den Konverter befasst sich die An- meldung in der veröffentlichten ursprünglichen Fassung nur in den Ausfüh- rungsbeispielen (vgl. insbesondere PCT-Veröffentlichung WO 98/19237 A1, Beschreibung zu Fig. 2, S. 16, Z. 5-22; sowie S. 19, Zn. 14-16 zu Fig. 4). Die Anmeldung spricht in diesem Zusammenhang von einem Konsolidieren und Komprimieren der Kartenklassen-Dateien (ebd., „[…] which consolidates and compresses the files […]“). Daneben zeigen weitere Ausführungsbeispiele im Zusammenhang mit der Verwendung von Java verschiedene Möglichkeiten, mit denen ein Karten-Klassendatei-Konverter („card class file converter“) den Umfang eines kompilierten Zwischencodes („Java class file“) verringern oder konsolidieren kann (vgl. Figuren 4 bis 11 mit zugehöriger Beschreibung). Ent- gegen den Ausführungen der Klägerin bezeichnet der Begriff „Minimieren“ nicht zwingend das Erzeugen eines absoluten Minimums, sondern kann auch allgemein ein „Verringern“ oder „Vermindern“ bezeichnen. In der Zielsetzung des Karten-Klassendatei-Konverters zur Nachverarbeitung („post processing“) eines kompilierten Java-Zwischencodes („Java class file“) für einen in seinen Ressourcen beschränkten Mikrocontroller erkennt der Fachmann in der „mi- nimierten Form“ eine zusammenfassende Umschreibung für die in den Aus- - 19 - führungsbeispielen gezeigten Möglichkeiten zum Konsolidieren und Kompri- mieren von Java-Klassendateien. Der erteilte Anspruch 1 des Streitpatents macht keine weiteren Angaben dazu, wie sich die Minimierung auf die kompilierte Form der Anwendungs-Quellpro- gramme auswirkt, sondern beschreibt die minimierte Form nur in Bezug auf ein Zwischenergebnis der Verarbeitung – den kompilierten Quellcode. Für diese minimierte Form des Anwendungscodes folgt aus Anspruch 1 des Streitpatents nur, dass dieser Code zur Interpretierung durch den Interpreter geeignet sein muss (vgl. Merkmal M2.1.2). Anhand dieses Anwendungscodes selbst ist jedoch nicht zu erkennen, ob der Code ausgehend von einem ande- ren Format minimiert oder direkt in einem minimierten Format erzeugt wurde, oder welche Maßnahmen und einzelnen Verarbeitungsschritte zu dem er- zeugten Code geführt haben. Dass der Umfang des in den Mikrocontroller geladenen Anwendungscodes den vorhandenen Ressourcenanforderungen des Mikrocontrollers („resource constraints“) genügen muss, folgt für den Fachmann zwangsläufig aus der Anforderung an den geladenen Code, durch den Interpreter im Mikrocontroller interpretiert werden zu können. Dies gilt in gleicher Weise für die Nachverarbeitung von kompilierten Java-Klassenda- teien gemäß den weiteren verteidigten Fassungen des Anspruchs 1 in den Hilfsanträgen 1 bis 5. II. Der Anspruch 1 des Streitpatents (Hauptantrag) und die jeweiligen Ansprüche 1 der Hilfsanträge 1 bis 5 sind nicht patentfähig (Art. II § 6 Abs. 1 Nr. 1 IntPatÜG, Art. 138 Abs. 1 Buchst. a, Art. 56 EPÜ). Darüber hinaus liegen in Anspruch 1 des Hauptantrags und den jeweiligen Ansprüchen 1 der Hilfsanträge auch unzulässige Erweiterungen vor (Art. II § 6 Abs. 1 Nr. 3 IntPatÜG i.V.m. Art. 138 Abs. 1 Buchst. c EPÜ). - 20 - 1. Hauptantrag Der Gegenstand des erteilten Anspruchs 1 beruht gegenüber dem Stand der Technik gemäß Druckschrift NK7, FR 2 667 171 A1, nicht auf einer erfinderi- schen Tätigkeit (Art. II § 6 Abs. 1 Nr. 1 IntPatÜG i.V.m. Art. 138 Abs. 1 Buchst. a, Art. 56 EPÜ). Denn aus Druckschrift NK7 ist ein Mikrocontroller mit einem Set von Ressour- cen-Beschränkungen („resource constraints“) bekannt („micro-circuit électro- nique“, S. 8, Z. 20 – S. 9, Z. 1; sowie Fig. 1 mit Beschreibung, S. 10, Zn. 23- 25; i.V.m. S. 5, Zn. 7-10 „[…] cette contrainte de place limitée“ / Merkmal M1). Dieser besteht aus einem Speicher („mémoire“ / Merkmal M1.1) und einem im Speicher geladenen Interpreter („[…] programme I représentant le programme interpréteur directement exécutable tel quel par le microprocesseur 7.“, S. 11, Zn. 21-26 und Fig. 1 / Merkmal M1.2). Dass der Interpreter zwangsläufig in- nerhalb des Sets von Ressourcen-Beschränkungen des Mikrocontollers funk- tioniert, liest der Fachmann bei der Ausführung des in den Mikrocontroller ge- ladenen Interpreters und dem Interpretieren des Anwendungsprogramms im Mikrocontroller mit, da sonst eine Ausführung der Anwendung nicht möglich wäre (vgl. S. 11, Zn. 15-26 / Merkmal M1.2.1). Der Mikrocontroller weist dabei mindestens eine durch den Interpreter zu übersetzende und im Speicher gela- dene Applikation auf („Les instructions du programme d'application, dans l'in- vention, doivent être interprétées, au moyen d'un programme d'interprétation contenu […] programme P représentant l'application“, S. 11, Zn. 15-24 und Fig. 1 / Merkmal M2). Aus Druckschrift NK7 ist zudem bekannt, dass die Ap- plikation durch eine Programmierungsumgebung generiert wird (Fig. 2, Schritt 14 i.V.m. Schritt 15 mit Beschreibung, S. 12, Zn. 4-6 und S. 13, Zn. 1-5 / Merkmal M2.1), welche einen Compiler umfasst, der Anwendungs-Quellpro- gramme in Quellcodeform einer höheren Programmiersprache in eine kompi- lierte Form kompiliert („Le programme compilateur qui permet la production du programme d'application sous sa forme intermédiaire […]“, S. 13, Zn. 2-5 / Merkmal M2.1.1). - 21 - Die in Druckschrift NK7 offenbarte Programmierungsumgebung unterscheidet sich von der des erteilten Anspruchs darin, dass keine minimierte Form des kompilierten interpretierbaren Zwischencodes mittels eines Konverters erzeugt wird (Merkmal M2.1.2 fehlt). Wie einleitend zu den Verfahrensmerkmalen zum Erzeugen des in den Mikro- controller geladenen Anwendungscodes dargelegt (vgl. Merkmale M2.1 bis M2.1.2), können diese Merkmale den beanspruchten Mikrocontroller höchs- tens dann charakterisieren, wenn die Verfahrensschritte – hier die zweistufige Aufbereitung des Anwendungsprogramms durch Compiler und Konverter in der Programmierungsumgebung – ihren eindeutig erkennbaren Niederschlag im erzeugten Code des Anwendungsprogramms finden und dieser Code dadurch von einem auf andere Weise erzeugten, für die Übersetzung im Mikrocontroller geeigneten Code der Anwendung unterscheidbar ist, bzw. sich der beanspruchte Mikrocontroller selbst durch den geladenen Anwendungs- code von einem aus dem Stand der Technik bekannten Mikrocontroller mit auf andere Weise erzeugtem Anwendungscode unterscheidet. Ein solcher Anwendungscode, der gegenüber Druckschrift NK7 zu besonde- ren Merkmalen oder Eigenschaften des Mikrocontrollers, also zu einem von Druckschrift NK7 unterscheidbaren, mit Interpreter und Applikation geladenen Mikrocontroller führt, ergibt sich für den beanspruchten Mikrocontroller jedoch nicht aus den Verfahrensschritten der Merkmale M2 bis M2.1.2. Vielmehr ist die einzige Anforderung, die der gemäß Anspruch 1 erzeugte Code des Anwendungsprogramms erfüllen muss, dessen Eignung, vom Interpreter ausgeführt werden zu können (vgl. Merkmal M2.1.2: „[…] suitable for interpretation by the interpreter“). Ein entsprechend geeigneter Anwendungs- code wird auch gemäß Druckschrift NK7 mittels eines Compilers direkt er- zeugt, so dass aus dieser Eignung des jeweils erzeugten Codes kein Unter- schied zum Code gemäß Druckschrift NK7 folgt. Darüber hinausgehende Merkmale, wie die von der Beklagten angesprochenen Sicherheitsmerkmale - 22 - des Codes sind nicht Gegenstand des Anspruchs 1 gemäß Hauptantrag. Denn der beanspruchten minimierten Form des kompilierten Anwendungscodes ge- mäß Anspruch 1 sind keine inhaltlichen Merkmale oder besondere Eigenschaften zu entnehmen, die ihn von einem auf andere Weise erzeugten, für den Interpreter geeigneten Code erkennbar unterscheiden würden (Merk- mal M2.1.2). Das außerhalb des beanspruchten Mikrocontrollers in der Programmierungsumgebung ablaufende zweistufige Verfahren unter Verwen- dung eines Compilers in Verbindung mit einem Konverter zum Erzeugen einer minimierten Form der Anwendung ist daher nicht geeignet, den Mikrocontroller gemäß Anspruch 1 nach Hauptantrag zu charakterisieren und gegenüber der Lehre der Druckschrift NK7 abzugrenzen. Die bestehenden Unterschiede in den (Verfahrens-)Merkmalen zur Erzeugung des Anwendungscodes sind da- bei nicht geeignet, eine erfinderische Tätigkeit zu begründen. Die Beklagte hat darauf verwiesen, dass im Stand der Technik gemäß Druck- schrift NK7 mit einem reduzierten Sprachumfang bzw. Befehlssatz gearbeitet würde (vgl. Druckschrift NK7, S. 14, Zn. 21 ff und S. 8, Zn. 7-9) und hieraus unter anderem eine Unterscheidbarkeit des generierten Codes folge, der in den Mikrocontroller geladen wird. Ungeachtet der Tatsache, dass Druckschrift NK7 von einer Erstellung des Quellcodes ohne Einschränkungen ausgeht („Premièrement, dans une phase 14 on écrit le programme de l’application comme si les problèmes cités relatifs aux cartes à micro-circuit étaient inexisi- tants.“, vgl. S. 12, Zn. 4-6), ist anhand des in den Mikrocontroller geladenen Anwendungscodes nicht zu unterscheiden, ob bestimmte Befehle per Defini- tion nicht verwendet, nicht benötigt, durch einen zusätzlichen Verarbeitungs- schritt entfernt oder durch andere Befehle ersetzt wurden. Aus diesem Grund sind die beanspruchten Verfahrensschritte zur Codeerzeugung nicht geeignet, das geladene Anwendungsprogramm und damit den Mikrocontroller eindeutig zu charakterisieren. - 23 - Der Anspruch 1 nach Hauptantrag ist damit nicht patentfähig. Es kann daher auch dahinstehen, ob der vorgesehene Zwischenschritt zum Konvertieren des kompilierten Quellcodes (Merkmal M2.1.1 i. V. m. Merkmal M2.1.2), der die Verarbeitung des Anwendungsprogramms vom ausschließli- chen Kompilieren eines Zwischencodes nach Druckschrift NK7 unterscheidet (vgl. Fig. 2, Schritt 15, mit Beschreibung, S. 13, Zn. 1 - 18), einen technischen Beitrag zur Lösung der zu Grunde liegenden Problemstellung liefert (vgl. BGH, Urt. v. 18. Dezember 2012 – X ZR 2/12, GRUR 2013, 275, Leitsätze - Routen- planung). Die Aufteilung der Programmierungsumgebung in Compiler und Konverter führt entgegen den Ausführungen der Beklagten neben der fehlen- den Unterscheidbarkeit der geladenen Applikation weder zu erkennbaren technischen Besonderheiten des Codes (der gemäß Anspruch 1 nur zur Ausführung durch den Interpreter geeignet sein muss), noch sind Randbedin- gungen oder Zusammenhänge im erteilten Anspruch 1 des Streitpatents erkennbar, die eine solche Aufteilung der Codeerzeugung in Compiler und Konverter technisch erforderlich machen. 2. Hilfsantrag 1 Der Gegenstand des Anspruchs 1 nach Hilfsantrag 1 beruht gegenüber dem Stand der Technik gemäß Druckschrift NK7 ebenfalls nicht auf einer erfinderi- schen Tätigkeit. Anspruch 1 gemäß Hilfsantrag 1 unterscheidet sich von Anspruch 1 des Hauptantrags darin, dass das Ergebnis des Kompilierungsschrittes in einem standardmäßigen Java-Klassendateiformat vorliegt („standard Java class file format“, Merkmal M2.1.3 i. V. m. M2.1.1) und der Konverter dieses Datenfor- mat verarbeitet, um zu einer für den Interpreter interpretierbaren Form zu ge- langen („[…] in a form suitable for interpretation by the interpreter“, Merkmal M2.1.4 i. V. m. M2.1.2). Zu den gegenüber dem Hauptantrag unveränderten Merkmalen sei auf die Ausführungen zum Hauptantrag verwiesen, die für die - 24 - Merkmale M1 bis M2.1.2 für den Anspruch 1 des Hilfsantrags 1 in gleicher Weise gelten (die Merkmale M1 bis M2.1.1 sind aus Druckschrift NK7 be- kannt; das zusammen mit Merkmal M2.1.1 außerhalb des beanspruchten Mik- rocontrollers liegende Merkmal M2.1.2 ist nicht geeignet, den beanspruchten Mikrocontroller von einem Mikrocontroller abzugrenzen, wie er aus Druck- schrift NK7 bekannt ist). Damit unterscheidet sich Anspruch 1 gemäß Hilfsantrag 1 vom Gegenstand der Druckschrift NK7 im Format des Kompilierungsergebnisses als standard- mäßiges Java-Klassendateiformat („standard Java class file format“), da Druckschrift NK7 für keine der dort genannten Programmiersprachen Angaben zu dem vom Compiler erzeugten Dateiformat macht (Merkmal M2.1.3 teil- weise). Zudem ist Druckschrift NK7 kein Konverter zu entnehmen, der geeig- net ist, aus dem vom Compiler erzeugten Dateiformat eine vom Interpreter in- terpretierbare Ausgabe zu erzeugen (Merkmal M2.1.4 fehlt). Der Fachmann wird durch Druckschrift NK7 nicht zwingend auf die Wahl einer bestimmten Programmiersprache (im Ausführungsbeispiel: C) festgelegt. Vielmehr verweist Druckschrift NK7 auf eine Reihe weiterer, prinzipiell geeig- neter Programmiersprachen (vgl. S. 2, Z. 32 bis S. 3, Z. 1 und Patentanspruch 2). Insbesondere sieht Druckschrift NK7 ausdrücklich die Verwendung eines Interpreters und die Erzeugung eines geeigneten interpretierbaren, kompilier- ten Anwendungscodes vor – mithin ist die Lehre der Druckschrift NK7 weder auf eine beliebige Programmiersprache, noch auf eine spezielle hardwareab- hängige Codeerzeugung gerichtet (vgl. bspw. S. 11, Zn. 15-25), sondern sie gibt eine Vorgehensweise vor, wie sie beispielsweise für Java typisch ist. Aus dem in Druckschrift NK7 beschriebenen Interpreter-Konzept und den Verweisen auf verschiedene geeignete Hochsprachen folgt eine Veranlassung für den Fachmann, ausgehend von der zugrunde liegenden Problemstellung, auch andere geeignete Sprachen aufgrund der diesen innewohnenden Vor- teile in Erwägung zu ziehen. Hierbei stellte Java gerade aufgrund der großen - 25 - Resonanz in Fachkreisen zum Anmeldezeitpunkt des Streitpatents einen hierfür naheliegenden Kandidaten dar. Die Ressourcenangaben hinsichtlich Mikrocontrollern bzw. Chipkarten in der sieben Jahre vor dem Streitpatent angemeldeten Druckschrift NK7 stellten zum Anmeldezeitpunkt des Streitpatents keinen Anlass dar, Java nicht als hö- here Programmiersprache in Erwägung zu ziehen. Denn es wurde in diesem Zeitraum mit Java nicht nur eine neue Programmiersprache entwickelt, son- dern insbesondere auch die in Mikrocontrollern verwendeten Technologien weiterentwickelt. Daher hätte der auf dem Gebiet der Mikrocontroller oder Chipkarten arbeitende Fachmann zum Anmeldezeitpunkt des Streitpatents im Jahr 1997 nicht die Ressourcenanforderungen der Druckschrift NK7 ungeprüft übernommen. Die Wahl von Java als Interpreter-Sprache bzw. die Verwendung eines ent- sprechenden Java Dateiformats für den kompilierten Anwendungscode lag daher zum Anmeldezeitpunkt des Streitpatents im Rahmen der vom Fach- mann in naheliegender Weise in Erwägung zu ziehenden Optionen, um eine höhere Programmiersprache auf Mikrocontrollern zu verwenden und damit von Vorteilen dieser bspw. plattformunabhängigen Programmiersprache zu profitieren (Merkmal M2.1.3 Rest). Im Hinblick auf das gemäß Hilfsantrag 1 gewählte, vom Compiler erzeugte Zwischenformat („standard Java class file format“) ergibt sich für die Anforde- rungen an den Code des Anwendungsprogramms nichts anderes als in An- spruch 1 gemäß Hauptantrag. Auch Anspruch 1 gemäß Hilfsantrag 1 fordert für den in den Mikrocontroller geladenen Code nur eine Eignung zur Überset- zung/Interpretierung durch den Interpreter. Die Verwendung von standardmä- ßigen Java-Klassendateien als kompiliertes Zwischenformat und damit implizit eines Java Compilers im Laufe der Erzeugung der zu ladenden Applikation (Merkmal M2.1.3) kennzeichnet zwar diesen Verfahrensablauf, nicht aber das damit erzeugte Ergebnis. Denn dem Ergebnis (d. h. dem in den Mikrocontrol- ler geladenen Anwendungscode) gemäß Anspruch 1 ist weder entnehmbar, welche besonderen Merkmale dieses Codes aus der Wahl des Zwischencode- - 26 - Formats („standard Java class file format“) folgen, noch welche charakteristi- schen Eigenschaften des Codes sich aus der zweistufigen Verarbeitung mit Compiler und Konverter ergeben. Weder aus der zweistufigen Verarbeitung des Codes bei der zweistufigen Erzeugung einer minimierten Form des Anwendungsprogramms mit Compiler und Konverter (Merkmal M2.1.4 i. V. m M2.1.3), noch aus der Vorgabe des kompilierten Zwischenformats („standard Java class file format“) folgen daher Merkmale oder Eigenschaften der in den Mikrocontroller geladenen Applika- tion, die geeignet wären, den Mikrocontroller selbst zu charakterisieren und diesen von einem Mikrocontroller mit bspw. direkt mittels angepasstem Compi- ler entsprechend Druckschrift NK7 erzeugtem Anwendungscode abzugrenzen (Merkmal M2.1.4). Der von der Beklagten vertretenen Auffassung, der Fachmann würde ausge- hend von Druckschrift NK7 nicht Java als höhere Programmiersprache ver- wenden, kann nicht gefolgt werden. Selbst wenn Bedenken wegen des Spei- cherbedarfs einer Java Virtual Machine zur Interpretierung des Zwischen- codes bestünden, zeigt Druckschrift NK7 allgemein, dass eine Virtual Machine für eine Hochsprache zur Verwendung auf einem ressourcenbegrenzten Mik- rocontroller realisiert werden kann (vgl. Druckschrift NK7, S. 6, Zn. 9-16 i.V.m. S. 8, Z. 20 bis S. 9, Z. 1). Zudem verweist Druckschrift NK7 auf den Zusam- menhang zwischen beschränkten Speicherressourcen und dem Umfang des Befehlssatzes (vgl. S. 14-15, seitenübergreifender Absatz). Der Speicherbe- darf bestimmter Virtual Machines bzw. Interpreter für Hochsprachen wäre an- gesichts des genannten Standes der Technik vielmehr Veranlassung für den Fachmann, Maßnahmen zur Anpassung für bestimmte, gewünschte Merkmale dieser Hochsprachen an die durch das Zielsystem vorgegebenen technischen Randbedingungen in Erwägung zu ziehen. Die von der Beklagten angesprochenen Sicherheitsmerkmale von Java finden auch im Anspruch 1 gemäß Hilfsantrag 1 keinen Niederschlag und ergeben - 27 - sich auch nicht zwangsläufig aus dem Java-Zwischenformat („standard Java class file format“), da Anspruch 1 weder auf Merkmale dieses Zwischenfor- mats, noch auf die Auswirkungen der Minimierung auf den kompilierten Code durch den Konverter eingeht. Wie beispielsweise aus der Beschreibung des Streitpatents ersichtlich ist, kann vielmehr eine Minimierung des kompilierten Codes gerade auch zu Lasten der angesprochenen Sicherheitsmerkmale ge- hen (vgl. deutsche Fassung des Streitpatents, DE 697 14 752 T2, S. 22, Z. 22 bis S. 23, Z. 2). Mögliche besondere Eigenschaften der Programmiersprache Java können daher eine erfinderische Tätigkeit gegenüber Druckschrift NK7 nicht begründen, da solche Besonderheiten der Programmiersprache gemäß Anspruch 1 keinen erkennbaren Niederschlag in der in den Mikrocontroller geladenen Applikation finden und damit dem Mikrocontroller selbst nicht anzu- sehen sind.. Auch aus Merkmal M2.1.4 folgt als einzige Anforderung an die- sen Code die Interpretierbarkeit durch den Interpreter. 3. Hilfsantrag 2 Der Gegenstand des Anspruchs 1 nach Hilfsantrag 2 beruht gegenüber dem Stand der Technik gemäß Druckschrift NK7 ebenfalls nicht auf einer erfinderi- schen Tätigkeit. Anspruch 1 des Hilfsantrags 2 unterscheidet sich von Anspruch 1 des Hilfsan- trags 1 im Merkmal M2.1.4*, das nunmehr auf das Erzeugen einer Ausgabe in einem zum Interpretieren durch den Interpreter geeigneten Klassendatei-For- mat („class file format“) an Stelle einer allgemeinen, zum Interpretieren geeig- neten minimierten Form der kompilierten Anwendung gerichtet ist. Zu den ge- genüber dem Hilfsantrag 1 unveränderten Merkmalen M1 bis M2.1.3 des An- spruchs 1 sei auf die vorstehenden Ausführungen zum Hilfsantrag 1 verwie- sen, die für die Merkmale in Anspruch 1 des Hilfsantrags 2 in gleicher Weise gelten (die Merkmale M1 bis M2.1.1 sind aus Druckschrift NK7 bekannt; die Merkmale M2.1.2 und M2.1.3 sind wiederum nicht geeignet, den beanspruch- - 28 - ten Mikrocontroller von einem Mikrocontroller abzugrenzen, wie er aus Druck- schrift NK7 bekannt ist). Merkmal M2.1.4* sieht nunmehr vor, dass der Konverter als Ergebnis das An- wendungsprogramm in einem bestimmten Format – einem Klassendateiformat („class file format“) – liefert. Die weiteren Anforderungen an diesen Anwen- dungscode gemäß Merkmal M2.1.4* i. V. m. M2.1.2 entsprechen dabei dem Anspruch 1 des Hilfsantrags 1. Die neben dem hinzugefügten Dateiformat ein- zige weitere Bedingung ist daher die Eignung, vom Interpreter interpretiert werden zu können. Somit ergeben sich auch aus Anspruch 1 gemäß Hilfsan- trag 2 keine Merkmale des Anwendungscodes, welche die zweistufige Erzeu- gung oder inhaltliche Besonderheiten des Quell- oder Zwischencodes in dem in den Mikrocontroller geladenen Anwendungscode widerspiegeln würden. Ganz allgemein gilt dabei, dass auch der aus Druckschrift NK7 bekannte Compiler als Ausgabe an den Interpreter den Code des Anwendungspro- gramms in einem definierten Format liefert, wobei der Code zum Überset- zen/Interpretieren durch den Interpreter geeignet ist (Merkmal M2.1.4* teil- weise). Damit liegt die einzige Besonderheit des gemäß Anspruchs 1 generierten An- wendungscodes gegenüber Druckschrift NK7 in der Festlegung des erzeugten Dateiformats als Klassendateiformat („class file format“). Bei Anwendungen in klassenbasierten Programmiersprachen wie Java liegt in der Regel der interpretierbare Byte-Code als Klassendatei vor, d. h. in einem Klassendateiformat. Somit stellt aber das Ergebnisformat („class file format“) nach Merkmal M2.1.4* keine Besonderheit der zweistufigen Code-Erzeugung mit Compiler und Konverter des Streitpatents dar, sondern beschreibt unab- hängig davon für den Fall klassenbasierter Programmiersprachen das übliche Dateiformat des als Klassendateien vorliegenden interpretierbaren Codes. Da gemäß Druckschrift NK7 ein Anwendungscode als kompilierter, interpretierba- rer Code für einen Interpreter erzeugt wird, folgt daraus für den Fachmann im- - 29 - plizit, dass der in den Mikrocontroller geladene interpretierbare Anwendungs- code bei einer klassenbasierten Programmiersprache – beispielsweise bei der naheliegenden Verwendung von Java – auch in einem Klassendatei-Format vorliegt (Merkmal M2.1.4* Rest). Somit ist weder das Vorsehen eines Konverters zum Minimieren eines zuvor mittels Compiler erzeugten Klassendateiformats geeignet, den Mikrocontroller in Abgrenzung zu einem direkt erzeugten Anwendungscode entsprechend Druckschrift NK7 zu charakterisieren, noch ist das Dateiformat („class file for- mat“), in dem das Anwendungsprogramm als Ausgabe an den Interpreter er- zeugt wird, geeignet, gegenüber einem Mikrocontroller gemäß Druckschrift NK7 eine erfinderische Tätigkeit zu begründen. Auch der Anspruch 1 nach Hilfsantrag 2 ist somit nicht patentfähig. 4. Hilfsantrag 3 Der Gegenstand des Anspruchs 1 nach Hilfsantrag 3 beruht gegenüber dem Stand der Technik gemäß Druckschrift NK7 ebenfalls nicht auf einer erfinderi- schen Tätigkeit. Anspruch 1 des Hilfsantrags 3 unterscheidet sich von Anspruch 1 des Hilfsan- trags 1 in den Merkmalen Merkmal M2.1.3* und M2.1.4**, die auf das Erzeu- gen einer Ausgabe in einer einzigen zum Interpretieren durch den Interpreter geeigneten Klassendatei („single class file“) aus einer Mehrzahl kompilierter Java Klassendateien („plurality of Java class files“) gerichtet ist. Zu den ge- genüber dem Hilfsantrag 1 unveränderten Merkmalen sei auf die vorstehen- den Ausführungen zum Hilfsantrag 1 verwiesen, die für die Merkmale M1 bis M2.1.2 des Anspruchs 1 des Hilfsantrags 3 in gleicher Weise gelten (die Merkmale M1 bis M2.1.1 sind aus Druckschrift NK7 bekannt; das Merkmal M2.1.2 ist nicht geeignet, den beanspruchten Mikrocontroller von einem Mik- rocontroller abzugrenzen, wie er aus Druckschrift NK7 bekannt ist). - 30 - Nach Anspruch 1 des Hilfsantrags 3 ist der in den Mikrocontroller geladene Anwendungscode dadurch charakterisiert, dass der Code durch den Interpre- ter interpretierbar ist (Merkmale M2.1.2 i. V. m. M2.1.4**) und als einzelne Er- gebnisdatei („single class file“, Merkmal M2.1.4**) vorliegt. Auch bei der ein- zelnen Ergebnisdatei ist nicht erkennbar, auf welchem Weg sie erzeugt wurde, d. h. ob sie durch einen Compiler, Konverter, einer Kombination daraus oder auf anderem Weg – z. B. durch Eingriffe eines Nutzers – erzeugt wurde. Ins- besondere ist anhand der Ergebnisdatei nicht erkennbar, ob der Quellcode bzw. Zwischencode in mehreren Dateien vorlag. Zwischenschritte der Codeerzeugung, wie die Anzahl von kompilierten und mittels eines Konverters aufbereitenten Dateien finden keinen eindeutig identi- fizierbaren Niederschlag im Anwendungscode, der daher in Bezug auf das Verfahren zur Codeerzeugung den Mikrocontroller nicht charakterisieren kann (Merkmal M2.1.3*; Merkmal M2.1.4** teilweise bzgl. des Dateiformats und der Eignung zur Ausführung durch den Interpreter). Das Vorliegen einer einzelnen Klassendatei ist nicht zwangsläufig das Ergeb- nis eines Minimieren im Sinne eines verringerten Code-Umfangs des Anwen- dungsprogramms, da Anspruch 1 mit dem Verweis auf die Umsetzung von mehreren Klassendateien in eine Klassendatei durch den Konverter keine An- gabe zum Umfang des Codes, sondern nur zur Form des ausgegebenen An- wendungscodes macht. Allein die Wahl des Dateiformats stellt aber allenfalls eine Maßnahme der Datenverarbeitung im Belieben des Programmierers dar, die ohne weitergehende technische Zusammenhänge, insbesondere im Hin- blick auf die Charakterisierung und Funktion des Mikrocontrollers keinen Bei- trag zur Lösung des zu Grunde liegenden technischen Problems im Sinne der ständigen BGH Rechtsprechung (vgl. bspw. BGH Entscheidung Routenpla- nung, a. a. O.) liefert (Merkmal M2.1.4** Rest). Auch die Angaben zur jeweiligen Anzahl der Klassendateien in den einzelnen Verfahrensschritten zur Erzeugung des in den Mikrocontroller geladenen An- - 31 - wendungscodes nach Anspruchs 1 des Hilfsantrags 3 ist daher nicht geeignet, gegenüber Druckschrift NK7 eine erfinderische Tätigkeit zu begründen. 5. Hilfsantrag 4 Der Gegenstand des Anspruchs 1 nach Hilfsantrag 4 beruht gegenüber dem Stand der Technik gemäß Druckschrift NK7 ebenfalls nicht auf einer erfinderi- schen Tätigkeit. Anspruch 1 des Hilfsantrags 4 stellt eine Kombination der jeweiligen Ansprü- che 1 der Hilfsanträge 2 und 3 dar. Zu den gegenüber Hilfsantrag 1 bzw. Hilfsantrag 3 unveränderten Merkmalen sei auf die vorstehenden Ausführun- gen verwiesen, die für die Merkmale M1 bis M2.1.3* des Anspruchs 1 im Hilfsantrag 4 in gleicher Weise gelten (die Merkmale M1 bis M2.1.1 sind aus Druckschrift NK7 bekannt; die Merkmale M2.1.2 und M2.1.3* - vgl. jeweils Hilfsantrag 3 - sind wiederum nicht geeignet, den beanspruchten Mikrocon- troller von einem Mikrocontroller technisch abzugrenzen, wie er aus Druck- schrift NK7 bekannt ist). Merkmal M2.1.4*** umfasst die Beschreibung des vom Konverter erzeugten Anwendungscodes in einem Klassendateiformat („class file format“) entspre- chend Hilfsantrag 2 in Verbindung mit dem Vorliegen des Codes als einzelne Datei („single class file“ entsprechend Hilfsantrag 3). Das Vorliegen des interpretierbaren Anwendungscodes in einem definierten Klassendateiformat ist typisch für ein interpretierbares, kompiliertes Format des Anwendungscodes einer klassenbasierten Programmiersprache wie Java. Allein diese Formatvorgabe ist daher nicht geeignet, eine erfinderische Tätig- keit in Abgrenzung zum Mikrocontroller mit geladenem interpretierbaren An- wendungscode gemäß Druckschrift NK7 zu begründen (vgl. auch vorstehende Ausführungen zu Merkmal M2.1.4* des Hilfsantrags 2). Aus der verringerten Zahl der Dateien des in den Mikrocontroller zu ladenden Anwendungscodes folgt nicht zwangsläufig eine Minimierung im Sinne einer - 32 - verringerten Datenmenge. Das Vorliegen einer einzigen Datei („a single class file“) gemäß Anspruch 1 nach Hilfsantrag 4 beschreibt damit eine Maßnahme der Datenverarbeitung (vgl. vorstehende Ausführungen zu Merkmal M2.1.4** des Hilfsantrags 3), die ebenfalls nicht geeignet ist, eine erfinderische Tätigkeit in Abgrenzung zum Mikrocontroller mit geladenem interpretierbaren Anwen- dungscode zu begründen, wie er aus Druckschrift NK7 bekannt ist (Merkmal M2.1.4***). 6. Hilfsantrag 5 Der Gegenstand des Anspruchs 1 nach Hilfsantrag 5 beruht gegenüber dem Stand der Technik gemäß Druckschrift NK7 ebenfalls nicht auf einer erfinderi- schen Tätigkeit. Anspruch 1 des Hilfsantrags 5 unterscheidet sich vom Gegenstand des An- spruchs 1 des Hilfsantrags 4 allein darin, dass der Quellcode des Anwen- dungsprogramms in der Programmiersprache Java vorliegen soll (Merkmal M2.1.1*). Für die Merkmale M1 bis M2.1 gelten die vorstehenden Ausführun- gen zu Anspruch 1 des Hilfsantrags 4 in gleicher Weise (die genannten Merk- male sind aus Druckschrift NK7 bekannt). Das Vorsehen von Java als Alternative zu der in Druckschrift NK7 verwende- ten Programmiersprache C war dem Fachmann zum Anmeldezeitpunkt durch Hinweise auf weitere, auf der Verwendung einer höheren Programmierspra- che mit einem auf dem Mikrocontroller laufenden Interpreter nahegelegt, wie dies zu Anspruch 1 des Hilfsantrags 1 dargelegt wurde (Merkmal M2.1.1*). Das Format des Quellcodes ist aber für den in den Mikrocontroller geladenen Anwendungscode nicht weiter von Bedeutung, da der erzeugte Code gemäß Anspruch 1 zur Interpretierung durch den Interpreter geeignet sein muss (Merkmal M2.1.2 i. V. m. M2.1.4***), aus einer Datei bestehen (Merkmal M2.1.4***) und in einem Klassendatei-Format vorliegen soll (Merkmal - 33 - M2.1.4***). Wie vorstehend zu Anspruch 1 des Hilfsantrags 4 dargelegt, geben die beanspruchten Verfahrensschritte zur Codeerzeugung aber keinen An- haltspunkt dafür, dass über die genannten Anforderungen an den ausgegebe- nen Code hinaus die Verfahrensschritte selbst (bspw. das vom Compiler er- zeugte Zwischenergebnis) erkennbar und unterscheidbar einen Niederschlag in dem in den Mikrocontroller geladenen Anwendungscode findet. Die oben genannten Merkmale M2.1.2 bis M2.1.4*** sind daher ebenfalls nicht geeignet, eine erfinderische Tätigkeit gegenüber dem Mikrocontroller mit gela- denem interpretierbaren Anwendungscode zu begründen, wie er aus Druck- schrift NK7 bekannt ist (Merkmale M2.1.2 bis M2.1.4***). 7. Darüber hinaus geht der jeweilige Gegenstand des Anspruchs 1 des Streitpa- tents und der Hilfsanträge 1 bis 5 über den Inhalt der Anmeldung in der ur- sprünglich eingereichten Fassung hinaus (Art. II § 6 Abs. 1 Nr. 3 IntPatÜG i. V. m. Art. 138 Abs. 1 Buchst. c EPÜ). Die verteidigten Fassungen des An- spruchs 1 sind jeweils nicht zulässig. Der Gegenstand des erteilten Anspruchs 1 geht über den Inhalt der ursprüng- lich als PCT-Anmeldung eingereichten und als WO 98/19237 A1 veröffent- lichten Unterlagen hinaus, da ein zweistufiges Erzeugen der Applikation aus einem in einer beliebigen Hochsprache vorliegenden Anwendungs-Quellpro- gramm unter Verwendung eines Compilers zum Kompilieren des Quellpro- gramms und eines Konverters zur Nachverarbeitung des kompilierten Codes (Merkmale M2.1, M2.1.1, M2.1.2), nicht zu entnehmen ist. Zwar sieht der allgemeine Teil der ursprünglichen Beschreibung allgemein die Verwendung von Hochsprachen für die in den Mikrocontroller geladenen Ap- plikationen vor (vgl. ursprüngliche Beschreibung, veröffentlicht als WO 98/19237 A1, S. 7, Zn. 15-19 und S. 11, Z. 33 – S. 12, Z. 1). Im allgemeinen Teil der Beschreibung ist daneben jedoch nur eine Umwandlung einer Appli- kation in ein zweites Format unabhängig von einer Programmierungsumge- bung beschrieben (ebd., S. 7, Zn. 20-24 i. V. m. S. 10, Zn. 20-24). Eine zwei- stufige Verarbeitung mit Compiler und Konverter findet sich auch nicht in den - 34 - ursprünglich eingereichten Ansprüchen wieder. Die Verfahrensansprüche sprechen zwar allgemein von einem Konvertieren von Applikationsprogram- men. Das jeweilige Verfahren ist aber auf Chipkarten gerichtet und nimmt nur Bezug auf zwei Anwendungen, die unabhängig von einer Programmierungs- umgebung mit Compiler und Konverter beschrieben sind (vgl. ursprüngliche Ansprüche 67, 79, 87-89). Diese ursprünglichen Ansprüche treffen keine wei- tere Aussage über die Maßnahmen zum Erzeugen dieser Dateien. Eine Programmierungsumgebung mit Compiler und Konverter gemäß An- spruch 1 ist in den ursprünglichen Unterlagen dagegen nur den Anwendungs- beispielen entnehmbar. Die dort beschriebene Vorgehensweise beruht auf ei- nem spezifischen, auf einem Java-Klassendateiformat basierenden Karten- Klassendateiformat und sieht neben der Verwendung von Java als Program- miersprache die Verwendung eines Karten-Klassendatei-Konverters (ebd., Fig. 3, S. 16, Zn. 23-33) und einer Card Java Virtual Machine („Card JVM“) als Interpreter vor (vgl. ebd., S. 16, Zn. 1-4). Die in Anspruch 1 beanspruchte Merkmalskombination aus allgemeiner Hoch- sprache und Programmierungsumgebung mit Compiler und allgemeinem Kon- verters folgt damit nicht direkt und eindeutig aus der ursprünglichen Beschrei- bung des Anmeldungsgegenstands. Die zweistufige Vorgehensweise zur Codeerzeugung gemäß den Ausführungsbeispielen lässt sich dabei auch nicht im Sinne des Anspruchs 1 auf beliebige Programmiersprachen und eine belie- bige kompilierte Form verallgemeinern (vgl. Merkmal M2.1.1), da sich die Ausführungsbeispiele auf die Verwendung von Java als einer klassenbasier- ten Programmiersprache stützen. Denn die ursprüngliche Beschreibung sieht eine zweistufige Verwendung von Compiler und Konverter sowie eine Minimie- rung der kompilierten Anwendung allein im Zusammenhang mit einem spezifi- schen Karten-Klassendateiformat vor, dessen Erzeugung mit einem dafür vor- gesehenen Karten-Klassendatei-Konverter verbunden ist und für dessen Ver- wendung wiederum nur eine daran angepasste Card Java Virtual Machine („Card JVM“) als Interpreter offenbart ist. - 35 - Die Beklagte hat zur ursprünglichen Offenbarung der Merkmalskombination des Anspruchs 1 darauf hingewiesen, dass Ausführungen in der Anmeldung zu anderen Ausführungsformen wie bspw. einer Chipkarte („integrated circuit card“) auch für den beanspruchten Mikrocontroller gelten würden (vgl. PCT- Veröffentlichung, S. 37, Zn. 5-13 und S. 15, Zn. 7-13 und 34-35). Eine Konvertierung des Anwendungscodes sei daher auch in Bezug auf einen Mik- rocontroller offenbart. Den in diesem Zusammenhang zitierten ursprünglichen Ansprüche 1 und 67 und 68 beziehen sich aber nicht auf eine Programmie- rungsumgebung, sondern beschreiben nur allgemein ein konvertieren von Anweisungen („instructions“) einer ersten in Anweisungen einer zweite Appli- kation. Eine Minimierung einer kompilierten Form des in einer beliebigen Hochsprache vorliegenden Quellcodes lässt sich hieraus nicht herleiten. Wei- tere zur Verwendung von Programmiersprachen außer Java genannte Text- stellen (ebd., S. 37, Z. 19 bis S. 38, Z. 7; S. 11, Z. 33 bis S. 12, Z. 4) sehen wiederum keine allgemeine Hochsprache im Sinne des Anspruchs 1, sondern nur klassenbasierte Hochsprachen, d.h. Sprachen, aus deren Quellcode Klas- sendateien erzeugt werden können. Die im erteilten Anspruch 1 (Hauptantrag) beanspruchte Merkmalskombination eines allgemeinen Konverters (Merkmal M2.1.2) und eines allgemeinen Inter- preters (Merkmal M1.2 i.V.m. M2.1.2) in Verbindung mit der Minimierung einer kompilierten Form des in einer beliebigen Hochsprache vorliegenden Quell- codes stellt daher eine Verallgemeinerung dar, die über den ursprünglich of- fenbarten Anmeldungsgegenstand hinausgeht. Der Gegenstand des Anspruchs 1 gemäß Hilfsantrag 1 geht ebenfalls über den Inhalt der Anmeldung hinaus, wie als PCT-Anmeldung ursprünglich einge- reicht worden ist. Im Unterschied zum Hauptantrag sieht der Anspruch 1 ge- mäß Hilfsantrag 1 vor, dass es sich bei der kompilierten Form des Anwen- dungsquellcodes um ein standardmäßiges Java-Klassendateiformat („stan- dard Java class file format“) handelt. Ein Konverter, der eine kompilierte Form des Anwendungs-Quellprogramms in diesem Klassendateiformat als Ein- - 36 - gangsgröße hat und eine allgemeine minimierte Form dieser kompilierten An- wendung zur Ausführung durch einen allgemeinen Interpreter erzeugt, ist der ursprünglichen Anmeldung jedoch nicht zu entnehmen. Diese sieht eine zwei- stufige Verwendung von Compiler und Konverter sowie eine Minimierung der kompilierten Anwendung vielmehr allein im Zusammenhang mit einem spezifi- schen Karten-Klassendateiformat vor, dessen Erzeugung mit einem dafür vor- gesehenen Karten-Klassendatei-Konverter verbunden ist und für dessen Ver- wendung wiederum nur eine dafür geeignete Java Card Class Virtual Machine als Interpreter offenbart ist. Auch für Anspruch 1 gemäß Hilfsantrag 1 gilt da- her, dass sich die beanspruchte Merkmalskombination aus zweistufiger Pro- grammierungsumgebung und allgemeinem Konverter und Interpreter nicht aus der ursprünglichen Beschreibung des Anmeldungsgegenstands ergibt. Der Gegenstand der jeweiligen Ansprüche 1 der Hilfsanträge 2 bis 5 geht ebenfalls über den Inhalt der Anmeldung hinaus, wie sie als PCT-Anmeldung ursprünglich eingereicht worden ist. In den Ansprüchen 1 der Hilfsanträge 2 bis 5 ist jeweils ein Konverter allge- mein beansprucht, der den in einem standardmäßigen Java-Klassendateifor- mat („standard Java class file format“, Merkmal M2.1.3 bzw. M2.1.3*) vorlie- genden kompilierten Anwendungscode nachbearbeitet und ein Ergebnis in ei- nem Klassendateiformat erzeugt („class file format“; Hilfsantrag 2, Merkmal M2.1.4*) oder als Ergebnis eine einzelne Klassendatei erzeugt („single class file“, Hilfsantrag 3, Anspruch 1, Merkmal M2.1.4**), oder beides (Hilfsanträge 4 und 5, Merkmal M2.1.4***). Weiterhin ist ein Interpreter allgemein bean- sprucht, der das so erzeugte Ergebnis interpretiert bzw. übersetzt. In An- spruch 1 der Hilfsanträge 2 bis 5 wird damit das Format der in den Mikrocon- troller geladenen Applikation, d. h. das Ergebnis des Konvertierungsschrittes, näher als Klassendateiformat bzw. einzelne Klassendatei definiert. Solche An- gaben zum Dateiformat bzw. der Anzahl der Klassendateien selbst sind dem allgemeinen Teil der ursprünglichen Beschreibung oder den ursprünglichen Ansprüchen in Verbindung mit einem Konverter nicht zu entnehmen, da die zweistufige Verarbeitung des Anwendungs-Quellprogramms mit Compiler und - 37 - Konverter nur Gegenstand der Ausführungsbeispiele der Anmeldung ist. Der jeweilige Anspruch 1 gibt jedoch auch keines der Ausführungsbeispiele voll- ständig wieder, da sich diese nur auf das spezifische Karten-Klassendateifor- mat gemäß Anhang A der Anmeldung bzw. auf einen dafür geeigneten Kar- ten-Klassendatei-Konverter beziehen (vgl. PCT-Veröffentlichung, Fig. 3, S. 16, Zn. 23-33). Die Ausführungsbeispiele sehen zur Übersetzung der mittels Compiler und Konverter erzeugten Klassendateien in einem speziellen Karten- Klassendateiformats zudem eine entsprechend angepasste Ausgestaltung des Interpreters als eine Card Java Virtual Machine („Card JVM“) vor (ebd., S. 16, Zn. 1-4). Die Erzeugung von nur irgendwie minimierten Klassendateien in einem belie- bigen Klassendateiformat gemäß Anspruch 1 des Hilfsantrags 2 (Merkmal M2.1.4*) aus einem standardmäßigen Java-Klassendateiformat (Merkmal M2.1.3) durch einen allgemeinen Konverter, der nur durch dieses Eingangs- und Ausgangsdateiformat bestimmt ist, lässt sich daher weder aus den ge- nannten Ausführungsbeispielen, noch unter Berücksichtigung der weiteren Beschreibung des Streitpatents herleiten. Dies gilt auch für die damit verbun- dene Verwendung dieser in einem allgemeinen minimierten Klassendateifor- mat vorliegenden Klassendateien durch einen allgemeinen Interpreter beim Ausführen der in den Mikrocontroller geladenen Applikation. Ebenso kann auch das Erzeugen einer einzelnen allgemeinen Klassendatei (Merkmal M2.1.4**) aus einer Mehrzahl an standardmäßigen Java-Klassendateien (Merkmal M2.1.3*) gemäß Anspruch 1 des Hilfsantrags 3 nicht aus den Aus- führungsbeispielen des Streitpatents entnommen werden. Entsprechendes gilt schließlich ein allgemeines minimiertes Klassendateiformat in Verbindung mit einer einzigen Klassendatei gemäß Merkmal M2.1.4*** im jeweiligen An- spruch 1 der Hilfsanträge 4 und 5. Der Senat ist daher zu der Auffassung gelangt, dass für den Fachmann eine Kombination eines allgemeinen Interpreters für höhere Programmiersprachen und eines allgemeinen Konverters zusammen mit einzelnen, aus dem Kontext der Ausführungsbeispiele genommenen Merkmalen zum Erzeugen des An- wendungscodes in einer Programmierungsumgebung nicht eindeutig und - 38 - zweifelsfrei aus den ursprünglich eingereichten Unterlagen folgen (vgl. Merk- male M2.1.4*, M2.1.4** bzw. M2.1.4*** des jeweiligen Anspruchs 1 der Hilfs- anträge 2 bis 5). Der Fachmann müsste dazu die den Ausführungsbeispielen entnehmbare Lehre nicht nur verallgemeinern, sondern vielmehr unter Hinzu- ziehen weiteren Wissens über Klassendateiformate und Programmierspra- chen eine gezielte Auswahl aus den offenbarten Merkmalen treffen. III. Die Kostenentscheidung beruht auf § 84 Abs. 2 PatG i. V. m. § 91 Abs. 1 Satz 1 ZPO, die Entscheidung über die vorläufige Vollstreckbarkeit auf § 99 Abs. 1 PatG i. V. m. § 709 ZPO. IV. Rechtsmittelbelehrung Gegen dieses Urteil steht den Beteiligten das Rechtsmittel der Berufung zu. Die Berufungsschrift muss von einer in der Bundesrepublik Deutschland zugelas- senen Rechtsanwältin oder Patentanwältin oder von einem in der Bundesrepublik Deutschland zugelassenen Rechtsanwalt oder Patentanwalt unterzeichnet und innerhalb eines Monats beim Bundesgerichtshof, Herrenstraße 45a, 76133 Karlsruhe schriftlich eingereicht werden. Die Berufungsfrist beginnt mit der Zustellung des in vollständiger Form abgefassten Urteils, spätestens aber mit dem Ablauf von fünf Monaten nach der Verkündung. Die Berufungsfrist kann nicht ver- längert werden. Die Berufungsschrift muss die Bezeichnung des Urteils, gegen das die Berufung gerichtet wird, sowie die Erklärung enthalten, dass gegen dieses Urteil Berufung - 39 - eingelegt werde. Mit der Berufungsschrift soll eine Ausfertigung oder beglaubigte Abschrift des angefochtenen Urteils vorgelegt werden. Voit Zugleich für die wegen Krank- heit verhinderte Richterin Kortge Voit Dr. Schwengelbeck Dr. Otten-Dünnweber Altvater prö