Source: https://www.damm-legal.de/bgh-softwarepatent-von-microsoft-fuer-dateinamen-fat-bleibt-bestandskraeftig
Timestamp: 2019-03-19 03:34:17
Document Index: 144930651

Matched Legal Cases: ['BGH', 'BGH', 'BGH', 'Art. 138', 'Art. 138', 'Art. 52', 'Art. 54', 'Art. 56', '§ 121', '§ 91']

BGH: Softwarepatent von Microsoft für Dateinamen (FAT) bleibt bestandskräftig › Dr. Ole Damm | Rechtsanwalt & Fachanwalt
Der BGH hat kurz vor seinem Urteil zur grundsätzlichen Patentierbarkeit von Software entschieden, dass ein Programm, welches einem System lange Dateinamen gestattet und trotzdem mit einem System, welches nur kurze Dateinamen gestattet, kompatibel ist, patentfähig ist. Sachverständig beraten entschied der BGH gegen das Bundespatentgericht und führte aus, dass sich der Gegenstand des Patentanspruchs für den Fachmann nicht in naheliegender Weise aus dem Stand der Technik ergebe. Der Fachmann, der ein Betriebssystem entwickeln wollte, das lange Dateinamen verwenden kann und gleichzeitig mit MS-DOS, Version 5.0 abwärtskompatibel ist, habe sich von den bei anderen Betriebssystemen verwendeten Lösungen abwenden und statt dessen versuchen müssen, im Rahmen der FAT-Dateisystemstruktur die Möglichkeit für einen langen Dateinamen zu schaffen. Dies sei mit Hilfe der streitigen Lehre in innovativer Art und Weise gelungen. Das gelte 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 sei, sowie 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 mache, während darin gleichzeitig für Betriebssysteme der Nachfolgegenerationen die Information liege, das ein oder mehrere weitere Verzeichniseinträge vorhanden seien, die einen langen Dateinamen beinhalten.
Der X. Zivilsenat des Bundesgerichtshofs hat auf die mündliche Verhandlung vom 20. April 2010 durch … für Recht erkannt:
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.
„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:
23. A computer-readable medium having computer-executable instructions adapted to enable a data processing system to perform the method of one of claims 1 to 11.“
„1. Verfahren zum Betreiben eines Datenverarbeitungssystems (10), das einen Speicher (16), der ein Betriebssystem (17) enthält, sowie einen Prozessor (12), der das Betriebssystem (17) ausführt, umfasst, wobei das Verfahren umfasst:
23. Computerlesbares Medium mit von einem Computer ausführbaren Anweisungen, die ein Datenverarbeitungssystem in die Lage versetzen, das Verfahren nach einem der Ansprüche 1 bis 11 auszuführen.“
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 Bundespatentgerichthat das Streitpatent mit Wirkung für die Bundesrepublik Deutschland für nichtig erklärt, weil jedenfalls der Nichtigkeitsgrund der mangelnden Patentfähigkeit gegeben 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.
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.
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 Infor-matiker 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.
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.; Fluss-diagramm 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, dassder 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).
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 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.).
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.
Der Gegenstand des Patentanspruchs 1 des Streitpatents ist patentierbar (Art. 138 Abs. 1 a, 52 EPÜ)
Der Gegenstand des Patentanspruchs 1 bezieht sich nicht auf ein Programm für Datenverarbeitungsanlagen als solche (Art. 52 Abs. 2 c, Abs. 3 EPÜ).
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.
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 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 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.
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.).
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 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.
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 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-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 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.
Die Kostenentscheidung beruht auf § 121 Abs. 2 Satz 2 PatG i.V. mit §§ 91, 97 ZPO.
Bundespatentgericht, Entscheidung vom 26.10.2006, Az. 2 Ni 2/05 (EU)