BGH, 10. Zivilsenat — X ZR 27/07

Die Beklagte ist eingetragene Inhaberin des europäischen Patents 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.

Patentansprüche 1, 12 und 23 haben in der englischen Verfahrenssprache folgenden Wortlaut:

In der veröffentlichten deutschen Übersetzung lauten Patentansprüche 1, 12 und 23 wie folgt:

Hinsichtlich der weiteren Patentansprüche wird auf die Streitpatentschrift verwiesen.

Der Kläger hat beantragt, das Streitpatent für nichtig zu erklären. Zur Begrü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 Interchange Protocol", Version 1, Rock Ridge Technical Working Group, Revision 1.09 vom 24. Juli 1991 (Anlage NK 7, deutsche Übersetzung) bezogen. Außerdem 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.

Das Bundespatentgericht hat das Streitpatent mit Wirkung für die Bundesrepublik Deutschland für nichtig erklärt, weil jedenfalls der Nichtigkeitsgrund der mangelnden Patentfähigkeit gegeben sei.

Gegen diese Entscheidung wendet sich die Beklagte mit ihrer Berufung und dem Antrag, das Urteil des Bundespatentgerichts abzuändern und die Klage abzuweisen. Hilfsweise verteidigt sie das Streitpatent in eingeschränktem Umfang. Hinsichtlich des genauen Wortlauts des Hilfsantrags wird auf das Sitzungsprotokoll Bezug genommen.

Demgegenüber beantragt der Kläger sinngemäß, die Berufung der Beklagten 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. Zudem hat die Beklagte ein Gutachten von Prof. Dr. rer. nat. habil. P., Betriebssysteme und Middleware, ... Institut für Softwaresystemtechnik, ..., und hat der Kläger ein Gutachten von Prof. Dr. Dr. h.c. Sp., Lehrstuhl Informatik 4, ..., vorgelegt.

Die zulässige Berufung der Beklagten hat in der Sache Erfolg.

I. Das Streitpatent betrifft ein Verfahren zum Betreiben eines Datenverarbeitungssystems, ein Datenverarbeitungssystem und ein computerlesbares Medium mit von einem Computer ausführbaren Anweisungen, die einem Datenverarbeitungssystem die Ausführung eines solchen Verfahrens ermöglichen.

In der Streitpatentschrift wird ausgeführt, dass viele Betriebssysteme nur kurze Dateinamen unterstützen. Beispielsweise ist aufgrund von Beschränkungen des Dateisystems im Betriebssystem MS-DOS, Version 5.0 jeder Dateiname auf 11 Zeichen beschränkt. Dabei sind 8 Zeichen für den Hauptteil und 3 Zeichen für eine Erweiterung vorgesehen, so dass ein Dateiname beispielsweise "EXAMPLE1.EXE" lauten kann. Das Dateisystem verwendet eine Verzeichnisstruktur, in der jede Datei einen mit ihr assoziierten Verzeichniseintrag aufweist.

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-Programmen 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 Patentanmeldung 0 578 205 erwähnt, welche ein Mehrfach-Dateinamen-Referenzierungssystem beschreibt.

Dem Streitpatent liegt das Problem zugrunde, ein Verfahren bzw. ein System anzugeben, welches es ermöglicht, Dateien sowohl mit Betriebssystemen, die nur kurze Dateinamen zulassen, als auch mit Betriebssystemen, die lange Dateinamen zulassen, zu verwenden.

Um dies zu erreichen, sieht Patentanspruch 1 folgendes Verfahren vor:

Das streitpatentgemäße Verfahren dient dem Betrieb eines Datenverarbeitungssystems, das einen Speicher und einen Prozessor umfasst, wobei der Speicher ein Betriebssystem enthält, das von dem Prozessor ausgeführt wird (Merkmal 1.1).

In dem Speicher werden für eine Datei ein erster und ein zweiter Verzeichniseintrag angelegt (Merkmale 1.2 und 1.3). Aus Sicht des Fachmanns, bei dem es sich um einen oder mehrere als Team zusammenarbeitende Informatiker oder Ingenieure mit Studienschwerpunkt Informatik, die über mehrjährige praktische Erfahrungen im Bereich der Systemprogrammierung verfügen, handelt (nachfolgend immer nur als "Fachmann" bezeichnet), ergibt sich daraus, 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 Sachverständige bei seiner Anhörung erläutert hat, dem Inhaltsverzeichnis eines Buches vergleichbar, dem entnommen werden kann, auf welcher Seite ein bestimmtes Kapitel beginnt.

Nach der Lehre des Streitpatents werden ein erster und ein zweiter Eintrag in dem Verzeichnis des Datenverarbeitungssystems abgespeichert. Beispielhaft sind die Formate derartiger erster und zweiter Verzeichniseinträge in den Figuren 3a und 3b der Streitpatentschrift aufgeführt, die nachfolgend wiedergegeben werden:

Der erste Verzeichniseintrag enthält einen kurzen Namen und der zweite Verzeichniseintrag einen langen (aus mehr Zeichen als der kurze Name bestehenden) 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 Zeichen 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-Verzeichniseintrag auch ein Langer-Dateiname-Verzeichniseintrag erforderlich, werden sowohl ein Langer-Dateiname-Verzeichniseintrag als auch ein Kurzer-Dateiname-Verzeichniseintrag angelegt und mit dem langen bzw. dem kurzen Dateinamen versehen (vgl. Streitpatentschrift Rdn. 35; Übersetzung S. 10 Abs. 4 f.; Flussdiagramm in Fig. 4, Schritte 57, 58 und 59).

Der zweite Verzeichniseintrag ist mit dem ersten Verzeichniseintrag verknü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 abzulegen. Vielmehr ist es ausreichend, diese Informationen allein in dem ersten Verzeichniseintrag vorzuhalten. Denn für den Fall, dass das Betriebssystem lange Namen zulässt und die Datei daher durch Zugreifen auf den zweiten Verzeichniseintrag auffindet (vgl. Merkmal 1.8), kann es über die Verknüpfung des zweiten 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 erfindungsgemäßen Ausführungsbeispiel erfolgt die Verknüpfung durch das Prüfsummenbytefeld 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") (Streitpatentschrift Rdn. 31, 41, 42; Übersetzung S. 9 Abs. 4; S. 12 Abs. 3 und 4).

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 Verzeichniseintrag 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, welches nur kurze Dateinamen zulässt, den zweiten Verzeichniseintrag nicht zur Kenntnis nimmt.

In dem Ausführungsbeispiel, welches in der Streitpatentschrift offenbart ist, enthält das Dateiattributefeld 42, welches Teil des zweiten Verzeichniseintrages ist (vgl. Figur 3b der Streitpatentschrift), die Information, welche anzeigt, ob der zweite Verzeichniseintrag den langen Dateinamen aufweist. Das Dateiattributefeld 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".

In einem Verzeichniseintrag mit einem langen Dateinamen sind alle vier genannten Bits im Dateiattributefeld 42 auf den Wert "1" gesetzt. Die Bitkombination "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 Verzeichniseintrag verborgen; der zweite Verzeichniseintrag ist für diese Betriebssysteme im Sinne des Merkmals 1.7 "unsichtbar". Hingegen erkennen Betriebssysteme, die lange Dateinamen zulassen, aufgrund der Bitkombination "1111" im Attributefeld 42, dass ein zweiter Verzeichniseintrag vorhanden ist. Für Betriebssysteme, die lange Dateinamen zulassen, ist der zweite Verzeichniseintrag folglich im Sinne des Merkmals 1.6 "sichtbar", so dass sie unter Zugriff auf diesen die Datei lokalisieren können (Streitpatentschrift Rdn. 36 ff.; Übersetzung 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.).

II. Der Gegenstand des Patentanspruchs 1 des Streitpatents geht nicht über den Inhalt der Anmeldung in der ursprünglich eingereichten Fassung hinaus (Art. 138 Abs. 1 c EPÜ).

Der Kläger weist darauf hin, dass Merkmal 1.6, wonach der zweite Verzeichniseintrag Informationen enthält, die anzeigen, dass der zweite Verzeichniseintrag den langen Dateinamen enthält, erst während des Prüfungsverfahrens 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 Beschreibung werde hinsichtlich der Belegung des Dateiattributefelds 42 des zweiten Verzeichniseintrags mit der Bitkombination "1111" lediglich für jedes einzelne Bit die Wirkung des Wertes "1" erklärt. Später werde dann noch ausgeführt, dass der Verzeichniseintrag für einfachere Betriebssysteme "beinahe unsichtbar" sei. Es sei jedoch keine Rede davon, dass die Bitkombination "1111" anzeige, dass der Verzeichniseintrag einen langen Dateinamen enthalte. Der Fachmann könne der Beschreibung überdies nicht entnehmen, dass die Bitkombination "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 Verzeichniseintrag 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 directory 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 Dateiattributefeld 42 vier Bits enthalten sind (ein Versteckt-Bit "H", ein Schreibgeschü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 Dateiattributefelds 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 Fachwissens, dass das Setzen der Bitkombination "1111" im Dateiattributefeld 42 des Langer-Dateiname-Verzeichniseintrags eine Information beinhaltet, die anzeigt, dass der zweite Verzeichniseintrag den langen Dateinamen enthält, so dass für ein Betriebssystem, das nur kurze Dateinamen zulässt, der zweite Verzeichniseintrag unsichtbar ist und die Datei durch Zugreifen auf den ersten Verzeichniseintrag 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 Sachverständige im Verhandlungstermin im Hinblick auf die im Vergleich mit der ursprü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 patentierbar (Art. 138 Abs. 1 a, 52 EPÜ)

a) Der Gegenstand des Patentanspruchs 1 bezieht sich nicht auf ein Programm für Datenverarbeitungsanlagen als solche (Art. 52 Abs. 2 c, Abs. 3 EPÜ).

Nach der gefestigten Rechtsprechung des Bundesgerichtshofs muss eine Anmeldung, die ein Computerprogramm oder ein durch ein Datenverarbeitungsprogramm verwirklichtes Verfahren zum Gegenstand hat, über die für die Patentfähigkeit unabdingbare Technizität hinaus verfahrensbestimmende Anweisungen enthalten, die die Lösung eines konkreten technischen Problems mit technischen Mitteln zum Gegenstand haben (BGHZ 149, 68, 74 - Suche fehlerhafter 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 Anforderungen genügt die in Patentanspruch 1 des Streitpatents unter Schutz gestellte Lösung. Denn diese betrifft das technische Problem, wie bestimmte Daten in einem Speicher von Datenverarbeitungsanlagen zum Zugriff für unterschiedliche 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Ü).

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 Standards, der ein Dateisystem für CD-ROMs betrifft. CD-ROMs sind Speichermedien, 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 maximale Gesamtlänge beträgt 255 Bytes (Gutachten Prof. Dr. S. S. 12). Der Aufbau eines Dateieintrags nach dem ISO 9660 Standard 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 Figur 6-29 ergibt, wird die Länge des (einschließlich des Ergänzungsteils) maximal 11 Zeichen langen Dateinamens durch das unmittelbar vorangehende Byte "L" definiert, während das erste Byte (Directory entry length) die Gesamtlänge des Dateideskriptors festlegt.

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 ermö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 Verzeichniseintrag 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 Figur 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 Sachverstä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 Dateinamen nach dem RRIP zulässt, durch das "NM"-Feld angezeigt wird, dass ein langer Dateiname abgespeichert ist.

b) Das RRIP definiert zur effektiven Unterstützung des POSIX-Dateisystems Einträge für den System Use Bereich, der als Teil eines Verzeichniseintrags nach dem ISO 9660 Standard vorgesehen ist (vgl. Anlage NK 7 Abschnitt 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 vorgesehenen, 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 langer Dateiname für eine (ein- und dieselbe) Datei gespeichert wird. Jedoch werden 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 kurzen Dateinamen abzuspeichern, und kann das im ISO 9660 Standard vorgesehene System Use Feld zur Speicherung des "alternativen", nicht an die Längenbeschrä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.

c) Die weiteren Entgegenhaltungen, auf welche der Kläger im Verhandlungstermin 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, January 1990, Vol. 10, No. 1, S. 111-117 (Anlage NK 3, deutsche Übersetzung) und 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önnen und offenbaren damit nicht das Speichern eines ersten Verzeichniseintrags, 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 anwendungsformatierter Dateiname (kurzer Name) basierend auf einem bekannten betriebssystemformatierten 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Ü).

Das dem Streitpatent zugrunde liegende Problem, ein Verfahren bzw. ein System anzugeben, welches es ermöglicht, Dateien sowohl mit Betriebssystemen, die nur kurze Dateinamen zulassen, als auch mit Betriebssystemen, die lange Dateinamen zulassen, zu verwenden, stellte sich dem Fachmann im Hinblick auf Betriebssysteme, die zu einer Zeit entwickelt worden waren, als Speicherplatz 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 verwendet wurde. Ähnliche Namensformate haben seinerzeit auch andere Betriebssysteme 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önnen. Zugleich war jedoch die sog. Abwärtskompatibilität mit den alten Betriebssystemen 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 kurzen Namen zuließ.

Die Lösung dieses Problems hing entscheidend von den Vorgaben des jeweiligen Dateisystems ab. Bei dem Dateisystem FAT bzw. dem Betriebssystem 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 Dateinamensfeld 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.

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 vornherein vorhandenen System Use Bereich mittels des "NM"-System USE Feldes zur Speicherung eines alternativen langen Dateinamens zu nutzen. Für diesen alternativen 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 weiter. Die dort vorgeschlagene Anlage zusätzlicher Dateien, auf denen erweiterte Attribute wie der lange Dateiname gespeichert werden können, oder die Speicherung 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.

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 verwendeten Lösungen abwenden und statt dessen versuchen, im Rahmen der FAT-Dateisystemstruktur die Möglichkeit für einen langen Dateinamen zu schaffen. 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.

Um herauszufinden, ob eine solche Funktion im Rahmen der FAT-Dateisystemstruktur angelegt war, musste selbige und dabei insbesondere der MS-DOS-Verzeichniseintrag analysiert werden, was (wie der gerichtliche Sachverständige im Termin nachvollziehbar erläutert hat) jedenfalls für einen Fachmann, der dieser Aufgabe im Auftrag der Beklagten nachging und deshalb Zugang zu dem Quellcode sowie der Dokumentation von MS-DOS hatte, prinzipiell möglich war, und auch für einen Fachmann, der diese Zugangsmöglichkeiten nicht hatte, nicht von vornherein ausgeschlossen war, weil sich dieser die insoweit erforderlichen Informationen durch Disassemblieren der binär codierten Maschinensprache erschließen konnte. Auf der Grundlage einer solchen Analyse musste der Fachmann sodann die Vorstellung entwickeln, dass möglicherweise die vier Attribute im Attributefeld von MS-DOS-Verzeichniseinträgen in der FAT-Dateisystemstruktur für den genannten Zweck verwendet werden können.

Insoweit kam allerdings nicht eines der Attribute für sich genommen in Betracht. Denn diesen war bereits durch MS-DOS jeweils eine Bedeutung zugewiesen, 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 Schreibgeschü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. Gutachten Prof. Dr. P. S. 54).

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 vorkommen kann, deshalb ungültig ist und dies dazu führt, dass die Namensfunktion 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 Bitkombination "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 werden, wobei weiterhin die Zugriffsmöglichkeit für die Betriebssysteme bis MS-DOS, Version 5.0 über den kurzen Dateinamen des ersten Verzeichniseintrags 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öglich ist, wenn eine bislang noch nicht belegte Funktion in der FAT-Dateisystemstruktur 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 Information, die einen zweiten, den langen Dateinamen beinhaltenden Verzeichniseintrag für Betriebssysteme bis einschließlich MS-DOS, Version 5.0 unsichtbar macht, während darin gleichzeitig für Betriebssysteme der Nachfolgegenerationen 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 Erkenntnisgewinn auch nicht als bloße Routineleistung für einen Fachmann angesehen werden.

IV. Die Kostenentscheidung beruht auf § 121 Abs. 2 Satz 2 PatG i.V. mit §§ 91, 97 ZPO.