Bundesgerichtshof, Entscheidung vom 20.04.2010, Az. X ZR 27/07

[X.]IM NAMEN DES VOLKES URTEIL [X.] Verkündet am: 20. April 2010 Anderer Justizangestellte als Urkundsbeamtin der Geschäftsstelle in der [X.]- 2 - [X.] hat auf die mündliche Verhand-lung vom 20. April 2010 durch [X.] Scharen und die [X.], Dr. [X.], [X.] und [X.] für Recht erkannt:
Auf die Berufung der [X.]n wird das am 26. Oktober 2006 [X.] Urteil des 2. Senats ([X.]) des [X.] abgeändert. Die Nichtigkeitsklage wird auf Kosten des [X.] abgewiesen.
Von Rechts wegen

Tatbestand: Die [X.] ist eingetragene Inhaberin des [X.] 0 618 540 (Streitpatents), das am 31. März 1994 unter Inanspruchnahme der Priorität einer [X.] 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 [X.] Verfahrensspra-che folgenden Wortlaut: 2 - 3 - "1. A method of operating a data processing system (10) comprising memory (16) holding an [X.] (17), and a processor (12) for running the [X.] (18), [X.]: 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, [X.], [X.] (20) further holding information (42) indicating the [X.] (20) holds said long filename; and c) in case that the [X.] (17) permits only short filenames and said information (42) is set to make [X.] (20) invisible to the [X.] (17), [X.] first direc-tory entry (18) or, in case that the [X.] (17) permits long filenames and said information (42) is set to make [X.] (20) visible to the [X.] (17), locating the file accessing [X.] (20).
[X.] data processing system (10), comprising: - 4 - (a) memory (16) holding: (i) an [X.] (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, [X.], [X.] (20) further holding information (42) indicating that [X.] (20) holds said long filename; and b) a processor (12) for running the [X.] (17) and, in case that the [X.] (17) permits only short filenames and said information (42) is set to make [X.] (20) invisible to the [X.] (17), [X.] first direc-tory entry (18) or, in case that the [X.] (17) permits long filenames and said information (42) is set to make [X.] (20) visible to the [X.] (17), locating the file by accessing [X.] (20).
[X.] 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 [X.] Ü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 [X.] (12), der das Be-triebssystem (17) ausführt, umfasst, wobei das Verfahren um-fasst: a) Speichern (58, 59) eines ersten [X.] (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 [X.] (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 [X.] (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. [X.] 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."
[X.]insichtlich der weiteren Patentansprüche wird auf die Streitpatentschrift verwiesen. 4 Der Kläger hat beantragt, das Streitpatent für nichtig zu erklären. Zur [X.] 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 "[X.]", Version 1, [X.], Revision 1.09 vom 24. Juli 1991 (Anlage [X.], [X.] Übersetzung) bezogen. [X.] 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 [X.] ist der Klage entgegengetreten. 5 Das [X.] hat das Streitpatent mit Wirkung für die Bun-desrepublik [X.] für nichtig erklärt, weil jedenfalls der [X.] der mangelnden Patentfähigkeit gegeben sei. 6 Gegen diese Entscheidung wendet sich die [X.] mit ihrer Berufung und dem Antrag, das Urteil des [X.]s abzuändern und die [X.] abzuweisen. [X.]ilfsweise verteidigt sie das Streitpatent in eingeschränktem Umfang. [X.]insichtlich des genauen Wortlauts des [X.] wird auf das Sit-zungsprotokoll Bezug genommen. 7 - 8 - 8 Demgegenüber beantragt der Kläger sinngemäß, die Berufung der [X.] 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. [X.] hat die [X.] ein Gutachten von Prof. Dr. rer. nat. habil.

P. , Betriebssysteme und Middleware,

[X.],

, 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 [X.]n hat in der Sache Erfolg. [X.] Das Streitpatent betrifft ein Verfahren zum Betreiben eines [X.], 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 [X.], Version 5.0 jeder Dateina-me auf 11 Zeichen beschränkt. Dabei sind 8 Zeichen für den [X.]auptteil und 3 12 - 9 - Zeichen für eine Erweiterung vorgesehen, so dass ein Dateiname [X.] "[X.]" 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 [X.] aus dem Jahre 1990 verwiesen, in der ein universeller Standard für die Dateibenennung vorgestellt wird, um die [X.] 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 [X.] [X.] 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 [X.]n, 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 [X.] (12), der das Be-triebssystem (17) ausführt, umfasst, wobei das Verfahren um-fasst: - 10 - 1.2 Speichern (58, 59) eines ersten [X.] (18), der einen kurzen Dateinamen für eine Datei enthält, in dem Spei-cher (16), 1.3 Speichern (58, 59) eines zweiten [X.] (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 [X.] als der kurze Dateiname hat, 1.6 wobei der zweite Verzeichniseintrag (20) ferner [X.] (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 [X.] (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 [X.] (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 [X.], das einen Speicher und einen [X.] umfasst, wobei der Speicher ein Betriebssystem enthält, das von dem [X.] ausgeführt wird (Merkmal 1.1). 17 In dem Speicher werden für eine Datei ein erster und ein zweiter [X.] 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 [X.], 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 [X.] in dem Verzeichnis des [X.] abgespeichert. [X.] sind die Formate derartiger erster und zweiter Verzeichniseinträge in den [X.]uren 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 [X.]) Namen für eine (ein- und dieselbe) Datei (Merkmale 1.2, 1.3 und 1.5). Wie bereits erwähnt, lässt das Betriebssystem [X.], 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 [X.] 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 [X.]. 14; Übersetzung S. 4 letzter Abs.). [X.] 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 [X.] angelegt und mit dem langen bzw. dem kurzen Dateinamen 20 - 13 - versehen (vgl. Streitpatentschrift [X.]. 35; Übersetzung S. 10 Abs. 4 f.; [X.] in [X.]. 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 [X.] vorzuhalten. Denn für den Fall, dass das Betriebssystem lange Namen zulässt und die Datei daher durch Zugreifen auf den zweiten [X.] 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 [X.] (vgl. die oben wiedergegebene [X.]ur 3b), in dem eine Prüfsumme für den kurzen Dateinamen gespeichert wird (Schritt 72 in [X.]ur 5a), um die [X.] mit ihrem entsprechenden [X.] 18 zu verknüpfen ("to associate with") (Streitpa-tentschrift [X.]. 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 [X.] 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 [X.], welches Teil des zweiten Verzeichnisein-trages ist (vgl. [X.]ur 3b der Streitpatentschrift), die Information, welche anzeigt, ob der zweite Verzeichniseintrag den langen Dateinamen aufweist. Das [X.] umfasst, wie aus der nachfolgend wiedergegebenen [X.]ur 5b der Streitpatentschrift hervorgeht, ein [X.] "[X.]", ein Schreibgeschützt-Bit "R", ein [X.] "S" und ein Volumenetikett-Bit "V". 25 - 15 - In einem Verzeichniseintrag mit einem langen Dateinamen sind alle vier genannten Bits im [X.] auf den Wert "1" gesetzt. Die [X.] "1111" ist für Betriebssysteme, die nur kurze Dateinamen zulassen, wie beispielsweise [X.], Version 5.0, ungültig. Für diese Betriebssysteme bleibt daher der den zweiten, einen langen Dateinamen beinhaltende [X.] verborgen; der zweite Verzeichniseintrag ist für diese [X.] im Sinne des Merkmals 1.7 "unsichtbar". [X.]ingegen 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 [X.]. 36 ff.; [X.], 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 [X.] Informationen enthält, die anzeigen, dass der zweite [X.] 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 [X.] werde hinsichtlich der Belegung des [X.] des zwei-ten [X.] mit der Bitkombination "1111" lediglich für jedes [X.] 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 [X.] "1111" nur im Fall langer Dateinamen vergeben werde. Der Argumentation des [X.] 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 [X.] weiterhin den Schritt zum Setzen des Attributefelds umfasst, so dass der zweite [X.] 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 [X.] 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 [X.]."; Anlage [X.]). Außerdem wird dem Fachmann in der Beschreibung im [X.]inblick auf das Flussdiagramm in [X.]ur 5a, das die zum Füllen eines Langer-Dateiname-[X.] erforderlichen Schritte zeigt, erläutert, dass in dem [X.] - 17 - attributefeld 42 vier Bits enthalten sind (ein [X.] "[X.]", ein Schreibge-schützt-Bit "R", ein [X.] "S" und ein Volumenetikett-Bit "V") und welche Bedeutung es hat, wenn diese Bits auf "1" gesetzt sind (Anlage [X.], [X.] 4 ff.). Schließlich wird dem Fachmann erklärt, dass wenn die Bits des [X.] ([X.]ur 5 b), wie beschrieben gesetzt werden und das [X.] auf null gesetzt wird, die bevorzugte Ausführungsform der Erfindung die [X.] für Betriebssysteme, die nur kurze Dateinamen unterstützen, beinahe unsichtbar macht (Anlage [X.], [X.] 32 ff.). Der Fachmann schließt daraus aufgrund seines Fach-wissens, dass das Setzen der Bitkombination "1111" im [X.] des Langer-Dateiname-[X.] eine Information beinhaltet, die [X.], dass der zweite Verzeichniseintrag den langen Dateinamen enthält, so dass für ein Betriebssystem, das nur kurze Dateinamen zulässt, der zweite [X.] unsichtbar ist und die Datei durch Zugreifen auf den ersten [X.] 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 [X.]inblick auf die im Vergleich mit der ur-sprünglichen Fassung insoweit gleichlautenden Stellen in der Beschreibung des Streitpatents (Anlage [X.]. 37 ff., [X.]. 42; Übersetzung, [X.], S. 11 Abs. 3 ff., S. 12 Abs. 4) bestätigt. [X.] 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 [X.] 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 [X.] enthalten, die die Lösung eines konkreten technischen Problems mit technischen Mitteln zum Gegenstand haben (BG[X.]Z 149, 68, 74 - Suche fehler-hafter Zeichenketten; BG[X.]Z 159, 197, 204 - elektronischer Zahlungsverkehr; BG[X.]Z 166, 305 [X.]. 17 - [X.]; BG[X.] GRUR 2009, 479 [X.]. 11 - [X.]). 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 [X.] 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 [X.]. b) Der Gegenstand des Patentanspruchs 1 des Streitpatents ist neu (Art. 54 EPÜ). 33 Das [X.], Version 1, [X.], Revision 1.09 vom 24. Juli 1991 (nachfolgend [X.] genannt; Anlage [X.], [X.] Übersetzung) ist eine Erweiterung des [X.] 9660 [X.]s, der ein Dateisystem für CD-ROMs betrifft. CD-ROMs sind [X.], die nur einmalig beschrieben werden können (Anlage [X.] Abschnitt 2; vgl. auch Gutachten Prof. Dr. S.

S. 11; Gutachten Prof. Dr. Dr. h.c. Sp. S. 9). Nach dem [X.] 9660 Standard sind die Dateinamen in einem Dateideskriptor angeordnet, der in das Verzeichnis des [X.]-Dateisystems eingetragen ist. Dateideskriptoren nach dem [X.] 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 [X.] 9660 [X.] kann der nachfolgend wiedergegebenen [X.]ur 6-29 aus dem Blatt "[X.] 9660 Extended by Rock Ridge" entnommen werden (in der Verhandlung vom 26. Oktober 2006 vor dem [X.] von der [X.]n vorgelegte Anlage): Der Dateiname nach dem [X.] 9660 Standard ist auf 8 Zeichen begrenzt, denen ein 3 Zeichen langer Ergänzungsteil folgen kann. Wie sich aus [X.]-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 [X.] festlegt. 36 Das [X.] nutzt den im [X.] 9660 Standard vorgesehenen System Use Bereich und darin insbesondere das System Use Feld "NM", um den Benutzern des [X.] die Abspeicherung eines alternativen Namen zu er-möglichen (vgl. Anlage [X.] Abschnitt 4.1 und 4.1.4). Nach dem [X.] besteht keine Verpflichtung zur Benutzung des "[X.]. Wenn bei einem [X.] das "NM"-Feld nicht belegt ist, wird der Dateiname nach dem [X.] 9660 Standard verwendet (Anlage [X.] Abschnitt 4.1.4). Der Aufbau des "[X.] geht aus der oben wiedergegebenen [X.]-29 hervor (vgl. auch Anlage [X.] 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 [X.] lehrt den Fachmann schließlich, dass für ein Auffinden der Datei auf den Dateinamen nach dem [X.] 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 [X.] Abschnitt 5.2.3). Nach den Erläuterungen des gerichtlichen Sach-verständigen im Verhandlungstermin findet ein Betriebssystem, das nur kurze Dateinamen nach dem [X.] 9660 Standard zulässt, die Datei durch Zugriff auf den Dateinamen nach der [X.] 9660, während einem Betriebssystem, das Da-teinamen nach dem [X.] zulässt, durch das "NM"-Feld angezeigt wird, dass ein langer Dateiname abgespeichert ist. 37 - 21 - b) Das [X.] 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 [X.] 9660 Standard vorgesehen ist (vgl. Anlage [X.] Ab-schnitt 2, 4.1). Insbesondere wird im [X.] das "NM"-System Use Feld definiert, welches die Möglichkeit eröffnet, der Datei - neben dem nach der [X.] 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 [X.] zwar ein Verfahren zum Betreiben eines [X.], 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 [X.] wird im Rahmen des [X.] nach dem [X.] 9660 Standard das Namensfeld dafür genutzt, den mit dem [X.] 9660 Standard konformen kur-zen Dateinamen abzuspeichern, und kann das im [X.] 9660 Standard vorgese-hene System Use Feld zur Speicherung des "alternativen", nicht an die [X.] des [X.] 9660 Standards gebundenen langen Dateinamen verwendet werden. Das [X.] 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) [X.], auf welche der Kläger im [X.] nicht mehr zurückgekommen ist, liegen weiter vom Gegenstand des Streitpatents ab als das vorstehend behandelte [X.]. Die bereits im Erteilungsverfahren berücksichtigte Veröffentlichung von [X.], [X.] [X.], [X.], [X.] 1990, [X.], No. 1, [X.] (Anlage [X.], [X.] Übersetzung) und 39 - 22 - die [X.] Patentanmeldung Showa 64-41039 (Anlage [X.], [X.] Übersetzung) sehen zusätzliche Dateien vor, auf denen zu einer bestehenden Datei erweiterte Attribute, wie etwa ein langer Name, gespeichert werden [X.] und offenbaren damit nicht das Speichern eines ersten Verzeichnisein-trags, der einen kurzen Dateinamen für eine Datei enthält, und eines zweiten [X.], 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 [X.] Patent 0 578 205 (Anlage [X.], [X.] Ü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 [X.]n, die nur kurze Dateinamen zulassen, als auch mit Betriebssystemen, die lange Dateinamen zulassen, zu verwenden, stellte sich dem Fachmann im [X.]in-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 [X.] ([X.]), welches bis einschließlich des Betriebssystems [X.], Version 5.0 41 - 23 - verwendet wurde. Ähnliche [X.] haben seinerzeit auch andere Be-triebssysteme wie etwa [X.] 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 [X.]. Zugleich war jedoch die sog. Abwärtskompatibilität mit den alten [X.] 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 [X.] bzw. dem Betriebssys-tem [X.], 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 [X.] eingerichtet worden. Zwar gibt es in dem Verzeichniseintrag nach [X.] neben dem auf das Format 8/3 limitierten [X.] ein reserviertes Feld 28, das beim Versatz 0Ch beginnt und 10 Byte lang ist (vgl. Streitpatentschrift [X.]. 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 [X.] enthielt für den Fachmann keine darüber hinausgehende Anregung zur Lösung des Problems. Denn das [X.] schlägt vor, den im Dateideskriptor nach dem [X.] 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 [X.] - 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 [X.], 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 [X.] 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 [X.], [X.] und [X.]), führen in eine andere Richtung. 44 Der Fachmann, der dennoch ein Betriebssystem entwickeln wollte, das lange Dateinamen verwenden kann und gleichzeitig mit [X.], Version 5.0 abwärtskompatibel ist, musste sich von den bei anderen Betriebssystemen [X.] Lösungen abwenden und statt dessen versuchen, im Rahmen der [X.]-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 [X.]-Dateisystemstruktur vorhandene, aber noch nicht belegte Funktion genutzt wird, um Zugriff auf eine Datei mit [X.] 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 [X.]-Dateisystemstruktur überhaupt eine solche Funktion enthielt. 45 - 25 - Um herauszufinden, ob eine solche Funktion im Rahmen der [X.]-Datei-systemstruktur angelegt war, musste selbige und dabei insbesondere der [X.]-Verzeichniseintrag analysiert werden, was (wie der gerichtliche Sachver-ständige im Termin nachvollziehbar erläutert hat) jedenfalls für einen [X.], der dieser Aufgabe im Auftrag der [X.]n nachging und deshalb Zu-gang zu dem Quellcode sowie der Dokumentation von [X.] hatte, prinzi-piell möglich war, und auch für einen Fachmann, der diese [X.] 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 [X.]-Verzeichniseinträgen in der [X.]-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 [X.] jeweils eine Bedeutung zu-gewiesen, wenn das zugehörige Bit auf den Wert "1" gestellt ist. Im Einzelnen markiert danach das [X.] ([X.]idden-Bit), eine Datei als "verborgen", so dass diese bei normalem Suchen nicht angezeigt wird, verhindert das Schreib-geschützt-Bit ([X.]), dass eine Datei überschrieben wird, bewirkt das [X.] ([X.]), dass die Datei nicht angezeigt wird, und enthält das [X.] ([X.]) den Bezeichner für das Speichermedium (vgl. [X.] 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 [X.] [X.] 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 [X.], 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 [X.] "1111" konnte daher für Betriebssysteme der Generationen nach [X.], 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 [X.], 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 [X.], Version 5.0 bei gleichzeitiger Abwärtskompatibilität mit Betriebssystemen bis einschließlich [X.], Version 5.0 durch die Anlage eines ersten und eines zweiten [X.] mög-lich ist, wenn eine bislang noch nicht belegte Funktion in der [X.]-Dateisystem-struktur gefunden und für die Weichenstellung zwischen einem Zugriff über den kurzen oder über den langen Dateinamen genutzt werden kann. Das gilt [X.] 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 [X.], Version 5.0 unsichtbar macht, während darin gleichzeitig für Betriebssysteme der [X.] 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 [X.] - 27 - [X.] auch nicht als bloße Routineleistung für einen Fachmann ange-sehen werden. 50 IV. Die Kostenentscheidung beruht auf § 121 Abs. 2 Satz 2 [X.] i.V. mit §§ 91, 97 ZPO. Scharen Gröning [X.]

Grabinski [X.]

Vorinstanzen: [X.], Entscheidung vom 26.10.2006 - 2 Ni 2/05 ([X.]) -