X ZR 27/07

BUNDESGERICHTSHOF IM NAMEN DES VOLKES URTEIL X ZR 27/07 Verkündet am: 20. April 2010 Anderer Justizangestellte als Urkundsbeamtin der Geschäftsstelle in der Patentnichtigkeitssache - 2 - Der X. Zivilsenat des Bundesgerichtshofs hat auf die mündliche Verhand- lung vom 20. April 2010 durch den Vorsitzenden Richter Scharen und die Rich- ter Gröning, Dr. Berger, Dr. Grabinski und Hoffmann für Recht erkannt: Auf die Berufung der Beklagten wird das am 26. Oktober 2006 ver- kündete Urteil des 2. Senats (Nichtigkeitssenats) des Bundespa- tentgerichts abgeändert. Die Nichtigkeitsklage wird auf Kosten des Klägers abgewiesen. Von Rechts wegen Tatbestand: Die Beklagte ist eingetragene Inhaberin des europäischen Pa- tents 0 618 540 (Streitpatents), das am 31. März 1994 unter Inanspruchnahme der Priorität einer US-Patentanmeldung vom 1. April 1993 angemeldet wurde. Das Streitpatent betrifft einen "gemeinsamen Speicherbereich für lange und kurze Dateinamen" und umfasst 23 Patentansprüche. 1 Patentansprüche 1, 12 und 23 haben in der englischen Verfahrensspra- che folgenden Wortlaut: 2 - 3 - "1. A method of operating a data processing system (10) comprising memory (16) holding an operating system (17), and a processor (12) for running the operating system (18), the method comprising: a) storing (58, 59) in the memory (16) a first directory en- try (18) holding a short filename for a file; b) storing (58, 59) in the memory (16) a second directory en- try (20) being associated with the first directory entry (18) and holding a long filename for the file, said long filename having more characters than said short filename, said second directory entry (20) further holding information (42) indicating the said second directory entry (20) holds said long filename; and c) in case that the operating system (17) permits only short filenames and said information (42) is set to make said second directory entry (20) invisible to the operating system (17), locating the file by accessing said first direc- tory entry (18) or, in case that the operating system (17) permits long filenames and said information (42) is set to make said second directory entry (20) visible to the operating system (17), locating the file accessing said second directory entry (20). 12. A data processing system (10), comprising: - 4 - (a) memory (16) holding: (i) an operating system (17), (ii) a first directory entry (18) holding a short filename for a file, and (iii) a second directory entry (20) being associated with the first directory entry (18) and holding a long filename for the file, said long filename having more characters than said short filename, said second directory entry (20) further holding information (42) indicating that said second directory entry (20) holds said long filename; and b) a processor (12) for running the operating system (17) and, in case that the operating system (17) permits only short filenames and said information (42) is set to make said second directory entry (20) invisible to the operating system (17), locating the file by accessing said first direc- tory entry (18) or, in case that the operating system (17) permits long filenames and said information (42) is set to make said second directory entry (20) visible to the operating system (17), locating the file by accessing said second directory entry (20). 23. A computer-readable medium having computer-executable in- structions adapted to enable a data processing system to per- form the method of one of claims 1 to 11." In der veröffentlichten deutschen Übersetzung lauten Patentansprüche 1, 12 und 23 wie folgt: 3 - 5 - "1. Verfahren zum Betreiben eines Datenverarbeitungssys- tems (10), das einen Speicher (16), der ein Betriebssys- tem (17) enthält, sowie einen Prozessor (12), der das Be- triebssystem (17) ausführt, umfasst, wobei das Verfahren um- fasst: a) Speichern (58, 59) eines ersten Verzeichniseintrags (18), der einen kurzen Dateinamen für eine Datei enthält, in dem Speicher (16); b) Speichern (58, 59) eines zweiten Verzeichnisein- trags (20), der mit dem ersten Verzeichniseintrag (18) verknüpft ist und einen langen Dateinamen für die Datei enthält, in dem Speicher (16), wobei der lange Dateiname mehr Zeichen hat als der kurze Dateiname und der zweite Verzeichniseintrag (20) des Weiteren Informationen (42) enthält, die anzeigen, dass der zweite Verzeichnisein- trag (20) den langen Dateinamen enthält; und c) wenn das Betriebssystem (17) nur kurze Dateinamen zu- lässt und die Informationen (42) so eingestellt sind, dass der zweite Verzeichniseintrag (20) für das Betriebssys- tem (17) unsichtbar ist, Auffinden der Datei durch Zugrei- fen auf den ersten Verzeichniseintrag (18), oder, wenn das Betriebssystem (17) lange Dateinamen zulässt und die Informationen (42) so eingestellt sind, dass der zweite Verzeichniseintrag (20) für das Betriebssystem (17) sicht- bar ist, Auffinden der Datei durch Zugreifen auf den zwei- ten Verzeichniseintrag (20). - 6 - 12. Datenverarbeitungssystem (10), das umfasst: (a) einen Speicher (16), der enthält: 1. ein Betriebssystem (17), 2. einen ersten Verzeichniseintrag (18), der einen kurzen Dateinamen für eine Datei enthält; 3. einen zweiten Verzeichniseintrag (20), der mit dem ers- ten Verzeichniseintrag (18) verknüpft ist und einen lan- gen Dateinamen für die Datei enthält, wobei der lange Dateiname mehr Zeichen hat als der kurze Dateiname und der zweite Verzeichniseintrag (20) des Weiteren In- formationen (42) enthält, die anzeigen, dass der zweite Verzeichniseintrag (20) den langen Dateinamen ent- hält; und (b) einen Prozessor (12), der das Betriebssystem (17) aus- führt und, wenn das Betriebssystem (17) nur kurze Datei- namen zulässt und die Informationen (42) so eingestellt sind, dass der zweite Verzeichniseintrag (20) für das Be- triebssystem (17) unsichtbar ist, die Datei durch Zugreifen auf den ersten Verzeichniseintrag (18) auffindet, oder, wenn das Betriebssystem (17) lange Dateinamen zulässt und die Informationen (42) so eingestellt sind, dass der zweite Verzeichniseintrag (20) für das Betriebssystem (17) sichtbar ist, die Datei durch Zugreifen auf den zwei- ten Verzeichniseintrag (20) auffindet. - 7 - 23. Computerlesbares Medium mit von einem Computer ausführ- baren Anweisungen, die ein Datenverarbeitungssystem in die Lage versetzen, das Verfahren nach einem der Ansprüche 1 bis 11 auszuführen." Hinsichtlich der weiteren Patentansprüche wird auf die Streitpatentschrift verwiesen. 4 Der Kläger hat beantragt, das Streitpatent für nichtig zu erklären. Zur Be- gründung hat er geltend gemacht, dass sein Gegenstand nicht neu sei, sich zumindest aber für den Fachmann in naheliegender Weise aus dem Stand der Technik ergebe, und sich insoweit insbesondere auf das "Rock Ridge Inter- change Protocol", Version 1, Rock Ridge Technical Working Group, Revision 1.09 vom 24. Juli 1991 (Anlage NK 7, deutsche Übersetzung) bezogen. Außer- dem hat er sich darauf berufen, dass der Gegenstand des Streitpatents nicht hinreichend deutlich und vollständig offenbart worden sei und über den Inhalt der prioritätsbegründenden Anmeldung hinausgehe. Die Beklagte ist der Klage entgegengetreten. 5 Das Bundespatentgericht hat das Streitpatent mit Wirkung für die Bun- desrepublik Deutschland für nichtig erklärt, weil jedenfalls der Nichtigkeitsgrund der mangelnden Patentfähigkeit gegeben sei. 6 Gegen diese Entscheidung wendet sich die Beklagte mit ihrer Berufung und dem Antrag, das Urteil des Bundespatentgerichts abzuändern und die Kla- ge abzuweisen. Hilfsweise verteidigt sie das Streitpatent in eingeschränktem Umfang. Hinsichtlich des genauen Wortlauts des Hilfsantrags wird auf das Sit- zungsprotokoll Bezug genommen. 7 - 8 - 8 Demgegenüber beantragt der Kläger sinngemäß, die Berufung der Be- klagten zurückzuweisen. Er bringt weiterhin vor, dass der Gegenstand des Streitpatents über den Inhalt der ursprünglichen Anmeldung hinausgehe und nicht patentfähig sei. Im Auftrag des Senats hat Prof. Dr.-Ing. habil. S. , Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme), , ein schriftliches Gutachten erstattet, das er in der mündlichen Verhandlung erläutert und ergänzt hat. Zu- dem hat die Beklagte ein Gutachten von Prof. Dr. rer. nat. habil. P. , Betriebssysteme und Middleware, Institut für Softwaresystem- technik, , und hat der Kläger ein Gutachten von Prof. Dr. Dr. h.c. Sp. , Lehrstuhl Informatik 4, , vorgelegt. 9 Entscheidungsgründe: Die zulässige Berufung der Beklagten hat in der Sache Erfolg.10 I. Das Streitpatent betrifft ein Verfahren zum Betreiben eines Datenverar- beitungssystems, ein Datenverarbeitungssystem und ein computerlesbares Me- dium mit von einem Computer ausführbaren Anweisungen, die einem Daten- verarbeitungssystem die Ausführung eines solchen Verfahrens ermöglichen. 11 In der Streitpatentschrift wird ausgeführt, dass viele Betriebssysteme nur kurze Dateinamen unterstützen. Beispielsweise ist aufgrund von Beschränkun- gen des Dateisystems im Betriebssystem MS-DOS, Version 5.0 jeder Dateina- me auf 11 Zeichen beschränkt. Dabei sind 8 Zeichen für den Hauptteil und 3 12 - 9 - Zeichen für eine Erweiterung vorgesehen, so dass ein Dateiname beispielswei- se "EXAMPLE1.EXE" lauten kann. Das Dateisystem verwendet eine Verzeich- nisstruktur, in der jede Datei einen mit ihr assoziierten Verzeichniseintrag auf- weist. 13 Für den Benutzer sind Beschränkungen der Namenslänge unpraktisch, weil beschreibende Dateinamen in vielen Fällen abgekürzt werden müssen. In der Streitpatentschrift wird auf eine Veröffentlichung von Y.E. Gail Wang aus dem Jahre 1990 verwiesen, in der ein universeller Standard für die Dateibenennung vorgestellt wird, um die Software-Kompatibilität von Ada-Pro- grammen zu verbessern, wobei universelle Dateinamen in Übereinstimmung mit Benennungskonventionen von verschiedenen Betriebssystemen festgelegt werden. Zudem wird die nach Art. 54 Abs. 3 EPÜ relevante europäische Pa- tentanmeldung 0 578 205 erwähnt, welche ein Mehrfach-Dateinamen-Referen- zierungssystem beschreibt. 14 Dem Streitpatent liegt das Problem zugrunde, ein Verfahren bzw. ein System anzugeben, welches es ermöglicht, Dateien sowohl mit Betriebssyste- men, die nur kurze Dateinamen zulassen, als auch mit Betriebssystemen, die lange Dateinamen zulassen, zu verwenden. 15 Um dies zu erreichen, sieht Patentanspruch 1 folgendes Verfahren vor:16 1.1 Verfahren zum Betreiben eines Datenverarbeitungssys- tems (10), das einen Speicher (16), der ein Betriebssys- tem (17) enthält, sowie einen Prozessor (12), der das Be- triebssystem (17) ausführt, umfasst, wobei das Verfahren um- fasst: - 10 - 1.2 Speichern (58, 59) eines ersten Verzeichniseintrags (18), der einen kurzen Dateinamen für eine Datei enthält, in dem Spei- cher (16), 1.3 Speichern (58, 59) eines zweiten Verzeichniseintrags (20) in dem Speicher (16), 1.4 der mit dem ersten Verzeichniseintrag (18) verknüpft ist, und 1.5 einen langen Dateinamen für die Datei enthält, der mehr Zei- chen als der kurze Dateiname hat, 1.6 wobei der zweite Verzeichniseintrag (20) ferner Informatio- nen (42) enthält, die anzeigen, dass der zweite Verzeichnis- eintrag (20) den langen Dateinamen enthält; 1.7 Auffinden der Datei durch Zugreifen auf den ersten Verzeich- niseintrag (18), wenn das Betriebssystem (17) nur kurze Da- teinamen zulässt und die Informationen (42) so eingestellt sind, dass der zweite Verzeichniseintrag (20) für das Betriebs- system unsichtbar ist, oder 1.8 Auffinden der Datei durch Zugreifen auf den zweiten Ver- zeichniseintrag (20), wenn das Betriebssystem (17) lange Da- teinamen zulässt und die Informationen (42) so eingestellt sind, dass der zweite Verzeichniseintrag (20) für das Betriebs- system (17) sichtbar ist. Das streitpatentgemäße Verfahren dient dem Betrieb eines Datenverar- beitungssystems, das einen Speicher und einen Prozessor umfasst, wobei der Speicher ein Betriebssystem enthält, das von dem Prozessor ausgeführt wird (Merkmal 1.1). 17 In dem Speicher werden für eine Datei ein erster und ein zweiter Ver- zeichniseintrag angelegt (Merkmale 1.2 und 1.3). Aus Sicht des Fachmanns, 18 - 11 - bei dem es sich um einen oder mehrere als Team zusammenarbeitende Infor- matiker oder Ingenieure mit Studienschwerpunkt Informatik, die über mehrjähri- ge praktische Erfahrungen im Bereich der Systemprogrammierung verfügen, handelt (nachfolgend immer nur als "Fachmann" bezeichnet), ergibt sich dar- aus, dass das Datenverarbeitungssystem ein Verzeichnis aufweist, in dem alle Dateien mit ihren beiden Namen eingetragen sind und das seinerseits als Datei implementiert ist. Der Verzeichniseintrag ermöglicht es, den Ort aufzufinden, an dem eine Datei abgespeichert ist, und ist insoweit, wie der gerichtliche Sach- verständige bei seiner Anhörung erläutert hat, dem Inhaltsverzeichnis eines Buches vergleichbar, dem entnommen werden kann, auf welcher Seite ein be- stimmtes Kapitel beginnt. Nach der Lehre des Streitpatents werden ein erster und ein zweiter Ein- trag in dem Verzeichnis des Datenverarbeitungssystems abgespeichert. Bei- spielhaft sind die Formate derartiger erster und zweiter Verzeichniseinträge in den Figuren 3a und 3b der Streitpatentschrift aufgeführt, die nachfolgend wie- dergegeben werden: 19 - 12 - Der erste Verzeichniseintrag enthält einen kurzen Namen und der zweite Verzeichniseintrag einen langen (aus mehr Zeichen als der kurze Name beste- henden) Namen für eine (ein- und dieselbe) Datei (Merkmale 1.2, 1.3 und 1.5). Wie bereits erwähnt, lässt das Betriebssystem MS-DOS, Version 5.0, auf das in der Streitpatentschrift beispielhaft Bezug genommen wird, nur Dateinamen zu, die (einschließlich einer Erweiterung von bis zu 3 Zeichen) höchstens 11 Zei- chen umfassen. Bei diesem Ausführungsbeispiel sind also kurze Dateinamen solche, die insgesamt höchstens 11 Zeichen umfassen, und lange solche, die aus mehr als insgesamt 11 Zeichen bestehen (vgl. Streitpatentschrift Rdn. 14; Übersetzung S. 4 letzter Abs.). Weist eine Datei einen Dateinamen von mehr als 11 Zeichen auf und ist deshalb neben dem Kurzer-Dateiname-Verzeichnis- eintrag auch ein Langer-Dateiname-Verzeichniseintrag erforderlich, werden so- wohl ein Langer-Dateiname-Verzeichniseintrag als auch ein Kurzer-Dateiname- Verzeichniseintrag angelegt und mit dem langen bzw. dem kurzen Dateinamen 20 - 13 - versehen (vgl. Streitpatentschrift Rdn. 35; Übersetzung S. 10 Abs. 4 f.; Fluss- diagramm in Fig. 4, Schritte 57, 58 und 59). 21 Der zweite Verzeichniseintrag ist mit dem ersten Verzeichniseintrag ver- knüpft ("associated with"; Merkmal 1.4). Eine solche Verknüpfung ermöglicht es Betriebssystemen, die einen langen Dateinamen zulassen und die Datei durch Zugreifen auf den zweiten Verzeichniseintrag auffinden können (Merkmal 1.8), auch auf Informationen zuzugreifen, die im ersten Verzeichniseintrag abgelegt sind. Wie der gerichtliche Sachverständige im Verhandlungstermin erläutert hat und von den Parteien bestätigt worden ist, entfällt mit der Verknüpfung des zweiten mit dem ersten Dateieintrag die Notwendigkeit, bestimmte die Datei betreffende Informationen (redundant) in beiden Verzeichniseinträgen abzule- gen. Vielmehr ist es ausreichend, diese Informationen allein in dem ersten Ver- zeichniseintrag vorzuhalten. Denn für den Fall, dass das Betriebssystem lange Namen zulässt und die Datei daher durch Zugreifen auf den zweiten Verzeich- niseintrag auffindet (vgl. Merkmal 1.8), kann es über die Verknüpfung des zwei- ten mit dem ersten Verzeichniseintrag auf diese Informationen zugreifen. Eine solche Redundanz vermeidende Anordnung von Informationen allein in dem ersten Verzeichniseintrag vereinfacht den Verwaltungsaufwand etwa dann, wenn selbige gespeichert, aktualisiert oder gelöscht werden müssen und spart überdies Speicherkapazität. In dem in der Beschreibung der Streitpatentschrift erläuterten erfindungs- gemäßen Ausführungsbeispiel erfolgt die Verknüpfung durch das Prüfsummen- bytefeld 44 (vgl. die oben wiedergegebene Figur 3b), in dem eine Prüfsumme für den kurzen Dateinamen gespeichert wird (Schritt 72 in Figur 5a), um die Langer-Dateiname-Verzeichniseinträge 20 mit ihrem entsprechenden Kurzer- Dateiname-Verzeichniseintrag 18 zu verknüpfen ("to associate with") (Streitpa- tentschrift Rdn. 31, 41, 42; Übersetzung S. 9 Abs. 4; S. 12 Abs. 3 und 4). 22 - 14 - 23 Der zweite Verzeichniseintrag enthält Informationen, die anzeigen, dass der zweite Verzeichniseintrag den langen Dateinamen aufweist (Merkmal 1.6). Dieser Informationen bedarf ein Betriebssystem, das lange Dateinamen zulässt und für welches die Informationen so eingestellt sind, damit der zweite Ver- zeichniseintrag sichtbar ist, so dass es die Datei durch Zugreifen auf diesen zweiten Verzeichniseintrag auffinden kann (Merkmal 1.8). Demgegenüber sind die Informationen für ein Betriebssystem, das nur kurze Dateinamen zulässt, so einstellbar, dass der zweite Verzeichniseintrag für dieses unsichtbar ist. Bei entsprechender Einstellung wird die Datei deshalb durch Zugreifen auf den ersten Verzeichniseintrag aufgefunden (Merkmal 1.8). Die Einstellung der Informationen bewirkt also, dass ein Betriebssystem, wel- ches nur kurze Dateinamen zulässt, den zweiten Verzeichniseintrag nicht zur Kenntnis nimmt. 24 In dem Ausführungsbeispiel, welches in der Streitpatentschrift offenbart ist, enthält das Dateiattributefeld 42, welches Teil des zweiten Verzeichnisein- trages ist (vgl. Figur 3b der Streitpatentschrift), die Information, welche anzeigt, ob der zweite Verzeichniseintrag den langen Dateinamen aufweist. Das Datei- attributefeld 42 umfasst, wie aus der nachfolgend wiedergegebenen Figur 5b der Streitpatentschrift hervorgeht, ein Versteckt-Bit "H", ein Schreibgeschützt-Bit "R", ein System-Bit "S" und ein Volumenetikett-Bit "V". 25 - 15 - In einem Verzeichniseintrag mit einem langen Dateinamen sind alle vier genannten Bits im Dateiattributefeld 42 auf den Wert "1" gesetzt. Die Bitkombi- nation "1111" ist für Betriebssysteme, die nur kurze Dateinamen zulassen, wie beispielsweise MS-DOS, Version 5.0, ungültig. Für diese Betriebssysteme bleibt daher der den zweiten, einen langen Dateinamen beinhaltende Verzeich- niseintrag verborgen; der zweite Verzeichniseintrag ist für diese Betriebssyste- me im Sinne des Merkmals 1.7 "unsichtbar". Hingegen erkennen Betriebssys- teme, die lange Dateinamen zulassen, aufgrund der Bitkombination "1111" im Attributefeld 42, dass ein zweiter Verzeichniseintrag vorhanden ist. Für Be- triebssysteme, die lange Dateinamen zulassen, ist der zweite Verzeichnisein- trag folglich im Sinne des Merkmals 1.6 "sichtbar", so dass sie unter Zugriff auf diesen die Datei lokalisieren können (Streitpatentschrift Rdn. 36 ff.; Überset- zung S. 11, Abs. 2 ff.; vgl. auch Gutachten von Prof. Dr. S. S. 8 f.; Gutachten von Prof. Dr. P. S. 26; Gutachten von Prof. Dr. Dr. h.c. Sp. S. 16 f.). 26 II. Der Gegenstand des Patentanspruchs 1 des Streitpatents geht nicht über den Inhalt der Anmeldung in der ursprünglich eingereichten Fassung hin- aus (Art. 138 Abs. 1 c EPÜ). 27 - 16 - 28 Der Kläger weist darauf hin, dass Merkmal 1.6, wonach der zweite Ver- zeichniseintrag Informationen enthält, die anzeigen, dass der zweite Verzeich- niseintrag den langen Dateinamen enthält, erst während des Prüfungsverfah- rens hinzugefügt worden sei. Er ist der Ansicht, dass der Fachmann Merkmal 1.6 der ursprünglichen Anmeldung nicht habe entnehmen können. In der Be- schreibung werde hinsichtlich der Belegung des Dateiattributefelds 42 des zwei- ten Verzeichniseintrags mit der Bitkombination "1111" lediglich für jedes einzel- ne Bit die Wirkung des Wertes "1" erklärt. Später werde dann noch ausgeführt, dass der Verzeichniseintrag für einfachere Betriebssysteme "beinahe unsicht- bar" sei. Es sei jedoch keine Rede davon, dass die Bitkombination "1111" an- zeige, dass der Verzeichniseintrag einen langen Dateinamen enthalte. Der Fachmann könne der Beschreibung überdies nicht entnehmen, dass die Bit- kombination "1111" nur im Fall langer Dateinamen vergeben werde. Der Argumentation des Klägers kann nicht gefolgt werden. Dabei wird übersehen, dass in Anspruch 18 der Anmeldung in der ursprünglichen Fassung beschrieben ist, dass der zweite Verzeichniseintrag ein Attributefeld enthält, welches so gesetzt werden kann, dass der zweite Verzeichniseintrag unsichtbar wird und der Schritt zum Speichern des zweiten Verzeichniseintrags weiterhin den Schritt zum Setzen des Attributefelds umfasst, so dass der zweite Ver- zeichniseintrag für das Betriebssystem unsichtbar ist ("... the second directory entry includes an attributes field which may be set to make the second directory entry invisible to the operating system and the step of storing the second direc- tory entry further comprises the step of setting the attributes field so that the second directory entry is invisible to the operating system."; Anlage NK 15 S. 23). Außerdem wird dem Fachmann in der Beschreibung im Hinblick auf das Flussdiagramm in Figur 5a, das die zum Füllen eines Langer-Dateiname- Verzeichniseintrags erforderlichen Schritte zeigt, erläutert, dass in dem Datei- 29 - 17 - attributefeld 42 vier Bits enthalten sind (ein Versteckt-Bit "H", ein Schreibge- schützt-Bit "R", ein System-Bit "S" und ein Volumenetikett-Bit "V") und welche Bedeutung es hat, wenn diese Bits auf "1" gesetzt sind (Anlage NK 15 S. 13, Z. 4 ff.). Schließlich wird dem Fachmann erklärt, dass wenn die Bits des Datei- attributefelds 42 (Figur 5 b), wie beschrieben gesetzt werden und das Erste- Plattencluster-Feld 50 auf null gesetzt wird, die bevorzugte Ausführungsform der Erfindung die Langer-Dateiname-Verzeichniseinträge für Betriebssysteme, die nur kurze Dateinamen unterstützen, beinahe unsichtbar macht (Anlage NK 15 S. 14, Z. 32 ff.). Der Fachmann schließt daraus aufgrund seines Fach- wissens, dass das Setzen der Bitkombination "1111" im Dateiattributefeld 42 des Langer-Dateiname-Verzeichniseintrags eine Information beinhaltet, die an- zeigt, dass der zweite Verzeichniseintrag den langen Dateinamen enthält, so dass für ein Betriebssystem, das nur kurze Dateinamen zulässt, der zweite Ver- zeichniseintrag unsichtbar ist und die Datei durch Zugreifen auf den ersten Ver- zeichniseintrag aufgefunden werden kann, während für ein Betriebssystem, das lange Dateinamen zulässt, der zweite Verzeichniseintrag sichtbar ist und die Datei durch Zugreifen auf den zweiten Verzeichniseintrag aufgefunden werden kann. Ein solches fachmännisches Verständnis hat auch der gerichtliche Sach- verständige im Verhandlungstermin im Hinblick auf die im Vergleich mit der ur- sprünglichen Fassung insoweit gleichlautenden Stellen in der Beschreibung des Streitpatents (Anlage NK 1 Rdn. 37 ff., Rdn. 42; Übersetzung, NK 17, S. 11 Abs. 3 ff., S. 12 Abs. 4) bestätigt. III. 1. Der Gegenstand des Patentanspruchs 1 des Streitpatents ist paten- tierbar (Art. 138 Abs. 1 a, 52 EPÜ) 30 a) Der Gegenstand des Patentanspruchs 1 bezieht sich nicht auf ein Pro- gramm für Datenverarbeitungsanlagen als solche (Art. 52 Abs. 2 c, Abs. 3 EPÜ). 31 - 18 - 32 Nach der gefestigten Rechtsprechung des Bundesgerichtshofs muss eine Anmeldung, die ein Computerprogramm oder ein durch ein Datenverarbei- tungsprogramm verwirklichtes Verfahren zum Gegenstand hat, über die für die Patentfähigkeit unabdingbare Technizität hinaus verfahrensbestimmende An- weisungen enthalten, die die Lösung eines konkreten technischen Problems mit technischen Mitteln zum Gegenstand haben (BGHZ 149, 68, 74 - Suche fehler- hafter Zeichenketten; BGHZ 159, 197, 204 - elektronischer Zahlungsverkehr; BGHZ 166, 305 Tz. 17 - vorausbezahlte Telefongespräche; BGH GRUR 2009, 479 Tz. 11 - Steuerungseinrichtung für Untersuchungsmodalitäten). Diesen An- forderungen genügt die in Patentanspruch 1 des Streitpatents unter Schutz ge- stellte Lösung. Denn diese betrifft das technische Problem, wie bestimmte Da- ten in einem Speicher von Datenverarbeitungsanlagen zum Zugriff für unter- schiedliche Betriebssysteme abgelegt werden müssen, und löst es mittels einer bestimmten Anordnung der Speicherbelegung. b) Der Gegenstand des Patentanspruchs 1 des Streitpatents ist neu (Art. 54 EPÜ). 33 Das Rock Ridge Interchange Protocol, Version 1, Rock Ridge Technical Working Group, Revision 1.09 vom 24. Juli 1991 (nachfolgend RRIP genannt; Anlage NK 7, deutsche Übersetzung) ist eine Erweiterung des ISO 9660 Stan- dards, der ein Dateisystem für CD-ROMs betrifft. CD-ROMs sind Speicherme- dien, die nur einmalig beschrieben werden können (Anlage NK 7 Abschnitt 2; vgl. auch Gutachten Prof. Dr. S. S. 11; Gutachten Prof. Dr. Dr. h.c. Sp. S. 9). Nach dem ISO 9660 Standard sind die Dateinamen in einem Dateideskriptor angeordnet, der in das Verzeichnis des ISO- Dateisystems eingetragen ist. Dateideskriptoren nach dem ISO 9660 bestehen aus einem festen (Bytes 0-31) und einem variablen Bereich (ab Byte 32). Die 34 - 19 - maximale Gesamtlänge beträgt 255 Bytes (Gutachten Prof. Dr. S. S. 12). Der Aufbau eines Dateieintrags nach dem ISO 9660 Stan- dard kann der nachfolgend wiedergegebenen Figur 6-29 aus dem Blatt "ISO 9660 Extended by Rock Ridge" entnommen werden (in der Verhandlung vom 26. Oktober 2006 vor dem Bundespatentgericht von der Beklagten vorgelegte Anlage): Der Dateiname nach dem ISO 9660 Standard ist auf 8 Zeichen begrenzt, denen ein 3 Zeichen langer Ergänzungsteil folgen kann. Wie sich aus Fi- gur 6-29 ergibt, wird die Länge des (einschließlich des Ergänzungsteils) maxi- mal 11 Zeichen langen Dateinamens durch das unmittelbar vorangehende Byte 35 - 20 - "L" definiert, während das erste Byte (Directory entry length) die Gesamtlänge des Dateideskriptors festlegt. 36 Das RRIP nutzt den im ISO 9660 Standard vorgesehenen System Use Bereich und darin insbesondere das System Use Feld "NM", um den Benutzern des POSIX-Dateisystems die Abspeicherung eines alternativen Namen zu er- möglichen (vgl. Anlage NK 7 Abschnitt 4.1 und 4.1.4). Nach dem RRIP besteht keine Verpflichtung zur Benutzung des "NM"-Felds. Wenn bei einem Verzeich- niseintrag das "NM"-Feld nicht belegt ist, wird der Dateiname nach dem ISO 9660 Standard verwendet (Anlage NK 7 Abschnitt 4.1.4). Der Aufbau des "NM"-Felds geht aus der oben wiedergegebenen Fi- gur 6-29 hervor (vgl. auch Anlage NK 7 Abschnitt 4.1.4, Tabelle 10). Die ersten beiden Bytes betreffen die Zeichenfolge "N" und "M". Das nächste Byte gibt die Länge des alternativen Namens an. Nach der Versionsnummer (hier 1) und dem Flaggenfeld folgt der alternative Name, der einen Maximalwert von 222 Bytes haben kann (255 Bytes - [32 + 1 Bytes], vgl. Gutachten Prof. Dr. S. S. 13). Das RRIP lehrt den Fachmann schließlich, dass für ein Auffinden der Datei auf den Dateinamen nach dem ISO 9660 Standard oder den alternativen Dateinamen zurückgegriffen wird, je nachdem ob ein "NM"- System Use Feld für eine Komponente dieses Dateinamens vorhanden ist (vgl. Anlage NK 7 Abschnitt 5.2.3). Nach den Erläuterungen des gerichtlichen Sach- verständigen im Verhandlungstermin findet ein Betriebssystem, das nur kurze Dateinamen nach dem ISO 9660 Standard zulässt, die Datei durch Zugriff auf den Dateinamen nach der ISO 9660, während einem Betriebssystem, das Da- teinamen nach dem RRIP zulässt, durch das "NM"-Feld angezeigt wird, dass ein langer Dateiname abgespeichert ist. 37 - 21 - b) Das RRIP definiert zur effektiven Unterstützung des POSIX-Datei- systems Einträge für den System Use Bereich, der als Teil eines Verzeichnis- eintrags nach dem ISO 9660 Standard vorgesehen ist (vgl. Anlage NK 7 Ab- schnitt 2, 4.1). Insbesondere wird im RRIP das "NM"-System Use Feld definiert, welches die Möglichkeit eröffnet, der Datei - neben dem nach der ISO 9660 vor- gesehenen, auf eine Länge von 8 Zeichen plus einer Ergänzung von 3 Zeichen begrenzten Namen - einen weiteren alternativen Namen zu verleihen, der bis zu 222 Bytes umfassen kann. Damit offenbart das RRIP zwar ein Verfahren zum Betreiben eines Datenverarbeitungssystems, nach dem ein kurzer und ein lan- ger Dateiname für eine (ein- und dieselbe) Datei gespeichert wird. Jedoch wer- den der kurze und der lange Dateinamen nicht - wie in den Merkmalen 1.2 und 1.3/1.5 vorgesehen - in einem ersten und in einem zweiten Verzeichniseintrag gespeichert, sondern in einem (einzigen) Verzeichniseintrag. Denn nach dem RRIP wird im Rahmen des Verzeichniseintrags nach dem ISO 9660 Standard das Namensfeld dafür genutzt, den mit dem ISO 9660 Standard konformen kur- zen Dateinamen abzuspeichern, und kann das im ISO 9660 Standard vorgese- hene System Use Feld zur Speicherung des "alternativen", nicht an die Län- genbeschränkung des ISO 9660 Standards gebundenen langen Dateinamen verwendet werden. Das RRIP schlägt also einen Dateieintrag vor, der sowohl einen kurzen als auch einen langen Dateinamen für eine Datei enthält, was - wie der gerichtliche Sachverständige bei seiner Anhörung bestätigt hat - nicht den Anforderungen des Patentanspruchs 1 entspricht. 38 c) Die weiteren Entgegenhaltungen, auf welche der Kläger im Verhand- lungstermin nicht mehr zurückgekommen ist, liegen weiter vom Gegenstand des Streitpatents ab als das vorstehend behandelte Rock Ridge Interchange Protocol. Die bereits im Erteilungsverfahren berücksichtigte Veröffentlichung von Y.E. Gail Wang, UNIVERSAL-FILE-NAMES FOR Ada, Ada Letters, Janua- ry 1990, Vol. 10, No. 1, S. 111-117 (Anlage NK 3, deutsche Übersetzung) und 39 - 22 - die japanische Patentanmeldung Showa 64-41039 (Anlage NK 10, deutsche Übersetzung) sehen zusätzliche Dateien vor, auf denen zu einer bestehenden Datei erweiterte Attribute, wie etwa ein langer Name, gespeichert werden kön- nen und offenbaren damit nicht das Speichern eines ersten Verzeichnisein- trags, der einen kurzen Dateinamen für eine Datei enthält, und eines zweiten Verzeichniseintrags, der einen langen Dateinamen für die Datei aufweist (vgl. Gutachten Prof. Dr. S. S. 20 f., 23 und 29; Gutachten Prof. Dr. P. S. 30, 39 und 51). Das europäische Patent 0 578 205 (Anlage NK 4, deutsche Übersetzung) beschreibt ein Verfahren, nach dem ein anwendungs- formatierter Dateiname (kurzer Name) basierend auf einem bekannten be- triebssystemformatierten Dateinamen (langer Name) oder vice versa erzeugt wird und die Namen in einem Anwendungs- und einem Betriebssystemeintrag in einer B-Baum-Struktur gespeichert werden und lehrt damit gleichfalls nicht die Speicherung eines langen und eines kurzen Dateinamens in einem ersten und einem zweiten Verzeichniseintrag (vgl. Gutachten Prof. Dr. S. S. 21; Gutachten Prof. Dr. P. S. 46 ff.). 2. Der Gegenstand von Patentanspruch 1 ergibt sich für den Fachmann auch nicht in naheliegender Weise aus dem Stand der Technik (Art. 56 EPÜ). 40 Das dem Streitpatent zugrunde liegende Problem, ein Verfahren bzw. ein System anzugeben, welches es ermöglicht, Dateien sowohl mit Betriebssyste- men, die nur kurze Dateinamen zulassen, als auch mit Betriebssystemen, die lange Dateinamen zulassen, zu verwenden, stellte sich dem Fachmann im Hin- blick auf Betriebssysteme, die zu einer Zeit entwickelt worden waren, als Spei- cherplatz für Rechner, insbesondere persönliche Rechner (personal computer) äußerst knapp und teuer war, so dass die Länge von Dateinamen beschränkt wurde, wie das Namensformat 8.3 bei dem Dateisystem FAT (File Allocation Table), welches bis einschließlich des Betriebssystems MS-DOS, Version 5.0 41 - 23 - verwendet wurde. Ähnliche Namensformate haben seinerzeit auch andere Be- triebssysteme wie etwa UNIX vorgesehen. Diese Limitierungen wurden jedoch Anfang der 90er Jahre zunehmend als störend empfunden, so dass der Wunsch entstand, die Beschränkungen hinsichtlich der Länge des Dateinamens bei neuen Betriebssystemen aufzugeben. Eine Datei sollte also durch einen langen Dateinamen, der vom Benutzer verliehen wurde, adressiert werden kön- nen. Zugleich war jedoch die sog. Abwärtskompatibilität mit den alten Betriebs- systemen zu gewährleisten. Dateien, die von einem neuen Betriebssystem mit einem langen Dateinamen aufgefunden werden konnten, sollten weiterhin auch von dem alten Betriebssystem aufgefunden werden können, das nur einen kur- zen Namen zuließ. Die Lösung dieses Problems hing entscheidend von den Vorgaben des jeweiligen Dateisystems ab. Bei dem Dateisystem FAT bzw. dem Betriebssys- tem MS-DOS, Version 5.0, lag die Schwierigkeit darin, dass in dem Dateieintrag kein Feld für einen langen Dateinamen vorgesehen ist. Das System war nicht von Anfang an vorwärtskompatibel eingerichtet worden. Zwar gibt es in dem Verzeichniseintrag nach FAT neben dem auf das Format 8/3 limitierten Datei- namensfeld 24 ein reserviertes Feld 28, das beim Versatz 0Ch beginnt und 10 Byte lang ist (vgl. Streitpatentschrift Rdn. 28; Übersetzung S. 8, Abs. 3). Die damit zur Verfügung stehende Speicherreserve ist jedoch nicht hinreichend, um den Anwendern die angestrebte, weitgehend restriktionsfreie Namensvergabe zu ermöglichen. 42 Das Rock Ridge Interchange Protocol enthielt für den Fachmann keine darüber hinausgehende Anregung zur Lösung des Problems. Denn das RRIP schlägt vor, den im Dateideskriptor nach dem ISO 9660 Standard von vornher- ein vorhandenen System Use Bereich mittels des "NM"-System USE Feldes zur Speicherung eines alternativen langen Dateinamens zu nutzen. Für diesen al- 43 - 24 - ternativen Dateinamen steht mit einer maximalen Länge von 222 Bytes auch hinreichend Raum zur Verfügung. Ein solcher Ansatz ließ sich jedoch bei MS-DOS, Version 5.0 nicht verwirklichen, weil das insoweit allein in Betracht kommende reservierte Feld 28 mit 10 Bytes und einer zwingend vorgegebenen Größe des gesamten Verzeichniseintrags von 32 Bytes (vgl. Gutachten Prof. Dr. S. S. 9) zu klein ist. Auch die anderen Entgegenhaltungen halfen dem Fachmann nicht wei- ter. Die dort vorgeschlagene Anlage zusätzlicher Dateien, auf denen erweiterte Attribute wie der lange Dateiname gespeichert werden können, oder die Spei- cherung des kurzen und des langen Dateinamens in einer B-Baum-Struktur (vgl. Anlagen NK 3, NK 10 und NK 4), führen in eine andere Richtung. 44 Der Fachmann, der dennoch ein Betriebssystem entwickeln wollte, das lange Dateinamen verwenden kann und gleichzeitig mit MS-DOS, Version 5.0 abwärtskompatibel ist, musste sich von den bei anderen Betriebssystemen ver- wendeten Lösungen abwenden und statt dessen versuchen, im Rahmen der FAT-Dateisystemstruktur die Möglichkeit für einen langen Dateinamen zu schaf- fen. Dafür bedurfte es der Erkenntnis, dass dies dadurch realisiert werden kann, dass neben dem Verzeichniseintrag mit dem kurzen Dateinamen, ein weiterer oder mehrere weitere Verzeichniseinträge für den langen Dateinamen angelegt werden und eine bereits in der FAT-Dateisystemstruktur vorhandene, aber noch nicht belegte Funktion genutzt wird, um Zugriff auf eine Datei mit MS-DOS bis Version 5.0 unter einem kurzen Dateinamen und mit den nachfolgenden neuen Betriebssystemen unter dem langen Dateinamen nehmen zu können. Diese Überlegung war aus damaliger Sicht spekulativ, weil zu Beginn der Arbeiten noch nicht feststehen konnte, ob die FAT-Dateisystemstruktur überhaupt eine solche Funktion enthielt. 45 - 25 - Um herauszufinden, ob eine solche Funktion im Rahmen der FAT-Datei- systemstruktur angelegt war, musste selbige und dabei insbesondere der MS- DOS-Verzeichniseintrag analysiert werden, was (wie der gerichtliche Sachver- ständige im Termin nachvollziehbar erläutert hat) jedenfalls für einen Fach- mann, der dieser Aufgabe im Auftrag der Beklagten nachging und deshalb Zu- gang zu dem Quellcode sowie der Dokumentation von MS-DOS hatte, prinzi- piell möglich war, und auch für einen Fachmann, der diese Zugangsmöglichkei- ten nicht hatte, nicht von vornherein ausgeschlossen war, weil sich dieser die insoweit erforderlichen Informationen durch Disassemblieren der binär codier- ten Maschinensprache erschließen konnte. Auf der Grundlage einer solchen Analyse musste der Fachmann sodann die Vorstellung entwickeln, dass mögli- cherweise die vier Attribute im Attributefeld von MS-DOS-Verzeichniseinträgen in der FAT-Dateisystemstruktur für den genannten Zweck verwendet werden können. 46 Insoweit kam allerdings nicht eines der Attribute für sich genommen in Betracht. Denn diesen war bereits durch MS-DOS jeweils eine Bedeutung zu- gewiesen, wenn das zugehörige Bit auf den Wert "1" gestellt ist. Im Einzelnen markiert danach das Versteckt-Bit (Hidden-Bit), eine Datei als "verborgen", so dass diese bei normalem Suchen nicht angezeigt wird, verhindert das Schreib- geschützt-Bit (Read-Only-Bit), dass eine Datei überschrieben wird, bewirkt das System-Bit (System-Bit), dass die Datei nicht angezeigt wird, und enthält das Volumen-Bit (Volume-Bit) den Bezeichner für das Speichermedium (vgl. Gut- achten Prof. Dr. P. S. 54). 47 Vielmehr bedurfte es erst der weiteren Erkenntnis, dass die Einstellung aller vier genannten Attribute auf den Wert "1" - also die Bitkombination "1111" - im normalen Betrieb auf einem MS-DOS FAT formatierten Medium niemals vor- kommen kann, deshalb ungültig ist und dies dazu führt, dass die Namensfunkti- 48 - 26 - on aller Betriebssysteme bis einschließlich MS-DOS, Version 5.0, den zweiten, den langen Namen beinhaltenden Dateieintrag nicht zur Kenntnis nimmt und infolgedessen für diese Betriebssysteme im Sinne der Lehre des Streitpatents "unsichtbar" ist (Gutachten Prof. Dr. S. S. 8; Gutachten Prof. Dr. P. S. 54 f.; Gutachten Prof. Dr. Dr. h.c. Sp. S. 26). Die Bitkombinati- on "1111" konnte daher für Betriebssysteme der Generationen nach MS-DOS, Version 5.0 zum Speichern bzw. Anzeigen eines langen Dateinamens in einem zweiten Verzeichniseintrag bzw. weiteren Verzeichniseinträgen verwendet wer- den, wobei weiterhin die Zugriffsmöglichkeit für die Betriebssysteme bis MS-DOS, Version 5.0 über den kurzen Dateinamen des ersten Verzeichnisein- trags bestand. Die vorgenannten Überlegungen lagen für den Fachmann nicht nahe. Das gilt zunächst für die Erwägung, dass der Zugriff auf lange Dateinamen mit neuen Nachfolgebetriebssystemen zu MS-DOS, Version 5.0 bei gleichzeitiger Abwärtskompatibilität mit Betriebssystemen bis einschließlich MS-DOS, Version 5.0 durch die Anlage eines ersten und eines zweiten Verzeichniseintrags mög- lich ist, wenn eine bislang noch nicht belegte Funktion in der FAT-Dateisystem- struktur gefunden und für die Weichenstellung zwischen einem Zugriff über den kurzen oder über den langen Dateinamen genutzt werden kann. Das gilt dar- über hinaus aber auch für das Auffinden der Bitkombination "1111" als Informa- tion, die einen zweiten, den langen Dateinamen beinhaltenden Verzeichnisein- trag für Betriebssysteme bis einschließlich MS-DOS, Version 5.0 unsichtbar macht, während darin gleichzeitig für Betriebssysteme der Nachfolgegeneratio- nen die Information liegt, das ein oder mehrere weitere Verzeichniseinträge vorhanden sind, die einen langen Dateinamen beinhalten. Anregungen dafür gab es bei anderen Betriebssystemen zum Prioritätszeitpunkt nicht und, wie der gerichtliche Sachverständige in seinem Gutachten ausgeführt (Gutachten Prof. Dr. S. S. 28 ff.) und im Termin bestätigt hat, kann dieser Er- 49 - 27 - kenntnisgewinn auch nicht als bloße Routineleistung für einen Fachmann ange- sehen werden. 50 IV. Die Kostenentscheidung beruht auf § 121 Abs. 2 Satz 2 PatG i.V. mit §§ 91, 97 ZPO. Scharen Gröning Berger Grabinski Hoffmann Vorinstanzen: Bundespatentgericht, Entscheidung vom 26.10.2006 - 2 Ni 2/05 (EU) -