BPatG
10. Juni 2021
>
BGH
7. November 2023
Fachbeiträge • 0
Über die Entscheidung
| Zitat : | BPatG, Urteil vom 10.06.2021 - 2 Ni 36/20 |
|---|---|
| Gericht : | BPatG |
| Aktenzeichen : | 2 Ni 36/20 |
| Entscheidungsdatum : | 10. Juni 2021 |
| Amtliche Quelle : |
Vollständiger Text
Tenor
In der Patentnichtigkeitssache
…
hat der 2. Senat (Nichtigkeitssenat) des Bundespatentgerichts aufgrund der mündlichen Verhandlung vom 10. Juni 2021 durch die Vorsitzende Richterin Hartlieb sowie die Richter Dr. Friedrich, Dr. Zebisch, Dr. Himmelmann und Dr. Kapels für Recht erkannt:
I. Das europäische Patent 1 414 015 wird mit Wirkung für das Hoheitsgebiet der Bundesrepublik Deutschland für nichtig erklärt.
II. Die Kosten des Rechtsstreits trägt die Beklagte.
III. Das Urteil ist gegen Sicherheitsleistung in Höhe von 120 % des zu vollstreckenden Betrages vorläufig vollstreckbar.
Tatbestand
Die Beklagte ist Inhaberin des die Prioritäten US 420347 P vom 22. Oktober 2002 und US 386245 vom 11. März 2003 beanspruchenden, am 17. Oktober 2003 angemeldeten europäischen Patents 1 414 015, dessen Patentschrift als EP 1 414 015 B1 (Streitpatent) am 28. März 2018 in der Verfahrenssprache Englisch unter dem Titel "Video bus for a video decoding system" veröffentlicht wurde. Das Streitpatent wird vom Deutschen Patent- und Markenamt unter der Nummer 603 51 073.6 geführt. Es umfasst 10 Patentansprüche, von denen die Ansprüche 2 bis 5 direkt oder indirekt auf den Verfahrensanspruch 1 und die Ansprüche 7 bis 10 direkt oder indirekt auf den unabhängigen Sachanspruch 6 rückbezogen sind.
Die Klägerin begehrt, das Streitpatent mit Wirkung für das Hoheitsgebiet der Bundesrepublik Deutschland im vollen Umfang für nichtig zu erklären. Die Beklagte verteidigt ihr Patent als Hauptantrag in der erteilten Fassung sowie beschränkt in den Fassungen der Hilfsanträge 1 bis 5 vom 9. März 2021.
Die erteilten selbständigen Patentansprüche 1 und 6 haben gemäß EP 1 414 015 B1 in der Verfahrenssprache Englisch und in deutscher Übersetzung, jeweils versehen mit einer Gliederung, folgenden Wortlaut:
Anspruch 1:
1.1 A method of transmitting data using a bus (612) in a network comprising:
1.2 transmitting (710) the data over the bus (612) at a first rate,
1.3 wherein a sender module (610) is transmitting said data in response to an incoming accept signal (611);
1.4 receiving (712) the data at a processing module (630) in the network;
1.5 storing (714) the data in a storage module (632) in said processing module (630);
1.6 preventing data overrun of said storage module (632)
1.7 by monitoring a state of said storage module and stalling the data flow by shutting off said accept signal (611);
1.8 and processing the data stored in said storage module (632) at a second rate.
Anspruch 1 in deutscher Übersetzung:
1.1 Verfahren zum Übertragen von Daten unter Verwendung eines Busses (612) in einem Netzwerk, das beinhaltet:
1.2 Übertragen (710) der Daten über den Bus (612) mit einer ersten Rate,
1.3 wobei ein Sendermodul (610) die Daten im Ansprechen auf ein ankommendes Zustimmungssignal (611) überträgt;
1.4 Empfangen (712) der Daten an einem Verarbeitungsmodul (630) in dem Netzwerk;
1.5 Speichern (714) der Daten in einem Speichermodul (632) in dem Verarbeitungsmodul (630);
1.6 Verhindern eines Datenüberlaufs des Speichermoduls (632)
1.7 durch Überwachen des Zustands des Speichermoduls und Anhalten des Datenflusses durch Abschalten des Zustimmungssignals (611);
1.8 und Verarbeiten der in dem Speichermodul (632) gespeicherten Daten mit einer zweiten Rate.
Anspruch 6:
6.1 A system for transmitting data in a network from a sender module (610) to a processing module (630),
6.2 wherein the sender module (610) is adapted and configured for transmitting (710) the data over a bus (612) at a first rate
6.3 in response to an incoming accept signal (611),
6.4 and wherein the processing module (630) is adapted and configured for receiving (712) the data
6.5 and for storing (714) the data in a storage module (632) in said processing module (630),
6.6 and for preventing (716) data overrun of said storage module
6.7 by monitoring a state of said storage module (632) and stalling the data flow by shutting off said accept signal (611);
6.8 and for processing the data stored in said storage module at a second rate.
Anspruch 6 in deutscher Übersetzung:
6.1 System zum Übertragen von Daten in einem Netzwerk von einem Sendermodul (610) an ein Verarbeitungsmodul (630),
6.2 wobei das Sendermodul (610) ausgelegt und konfiguriert ist zum Übertragen (710) der Daten über einen Bus (612) mit einer ersten Rate
6.3 im Ansprechen auf ein ankommendes Zustimmungssignal (611),
6.4 und wobei das Verarbeitungsmodul (630) ausgelegt und konfiguriert ist zum Empfangen (712) der Daten
6.5 und zum Speichern (714) der Daten in einem Speichermodul (632) in dem Verarbeitungsmodul (630),
6.6 und zum Verhindern (716) eines Datenüberlaufs des Speichermoduls (632)
6.7 durch Überwachen des Zustands des Speichermoduls (632) und Anhalten des Datenflusses durch Abschalten des Zustimmungssignals (611);
6.8 und zum Verarbeiten der in dem Speichermodul gespeicherten Daten mit einer zweiten Rate.
Zur Stützung ihres Vorbringens hat die Klägerin die folgenden Dokumente genannt:
| NK1 Erweiterung der Verletzungsklage 7 O 58/18 vor dem LG Mannheim, |
Die Klägerin stützt ihre Klage auf den Nichtigkeitsgrund der fehlenden Patentfähigkeit aufgrund fehlender Neuheit und fehlender erfinderischer Tätigkeit sowie auf den Nichtigkeitsgrund, dass das Streitpatent über den Umfang der ursprünglich eingereichten Teil- bzw. Stammanmeldung hinausgeht. Die Verfahren der Ansprüche 1 sämtlicher Hilfsanträge seien nicht neu gegenüber dem Dokument D3 in der Fassung des Dokuments D3b, die Ansprüche 1 der Hilfsanträge 2 bis 5 seien unzulässig erweitert, die Verfahren der Ansprüche 1 nach den Hilfsanträgen 2 und 3 seien nicht ausführbar offenbart.
Die Klägerin stellt den Antrag,
das europäische Patent EP 1 414 015 mit Wirkung für das Hoheitsgebiet der Bundesrepublik Deutschland für nichtig zu erklären.
Die Beklagte beantragt,
die Klage abzuweisen,
hilfsweise
das europäische Patent dadurch teilweise für nichtig zu erklären, dass seine Patentansprüche die Fassung eines der Hilfsanträge 1 bis 5 vom 9. März 2021 in dieser Reihenfolge, erhalten.
Die Beklagte erklärt, dass sie die Patentansprüche gemäß Hauptantrag und Hilfsanträgen als jeweils geschlossene Anspruchssätze ansieht, die jeweils insgesamt beansprucht werden.
Die Beklagte tritt der Argumentation der Klägerin in allen wesentlichen Punkten entgegen.Sie vertritt die Auffassung, dass das Verfahren und System der erteilten Ansprüche 1 und 6 zulässig und patentfähig seien, da sie ursprünglich offenbart seien und die vorgelegten Druckschriften das erteilte Verfahren bzw. System weder neuheitsschädlich vorwegnehmen noch dem Fachmann nahelegen könnten. Die Nichtigkeitsklägerin habe bereits die Vorveröffentlichung des Dokuments D3 nicht nachgewiesen, weshalb das Dokument D3 nicht zu berücksichtigen sei. Das Streitpatent sei jedenfalls in der Fassung einer der fünf zulässigen Hilfsanträge patentfähig.
Anspruch 1 nach Hilfsantrag 1 ergibt sich aus dem erteilten Anspruch 1, indem zwischen die Merkmale 1.3 und 1.4 das folgende Zusatzmerkmal 1.3a eingefügt wird:
1.3a "wherein the accept signal is transmitted over the bus (612)".
Anspruch 1 nach Hilfsantrag 2 ergibt sich aus dem erteilten Anspruch 1, indem das Merkmal 1.2 ersetzt wird durch das folgende Merkmal 1.2':
1.2' "transmitting (710) the data as packets over the bus (612) at a first rate",
und indem zwischen die Merkmale 1.3 und 1.4 das folgende Zusatzmerkmal 1.3b eingefügt wird:
1.3b "wherein the accept signal is transmitted as packets".
Anspruch 1 nach Hilfsantrag 3 umfasst als Präzisierung die Zusatzmerkmale der Hilfsanträge 1 und 2. Er ergibt sich somit aus dem erteilten Anspruch 1, indem das Merkmal 1.2 ersetzt wird durch das obige Merkmal 1.2', und indem zwischen die Merkmale 1.3 und 1.4 das obige Zusatzmerkmal 1.3b eingefügt wird.
Anspruch 1 nach Hilfsantrag 4 ergibt sich aus dem erteilten Anspruch 1, indem zwischen die Merkmale 1.3 und 1.4 das folgende Zusatzmerkmal 1.3c eingefügt wird:
1.3c "as long as it is receiving the accept signal (611)".
Anspruch 1 nach Hilfsantrag 5 ergibt sich aus dem erteilten Anspruch 1, indem in Merkmal 1.8 das "and" gestrichen wird, und an dessen Schluss das folgende Zusatzmerkmal 1.9 angefügt wird:
1.9 "and continue transmitting over the bus (612) in response to receiving the accept signal (611) again in order to ensure that the storage module (632) is never starved for data, wherein said first rate is greater than said second rate".
Wegen der weiteren Einzelheiten wird auf den Akteninhalt verwiesen.
Gründe
Die Klage, mit der der Nichtigkeitsgrund der fehlenden Patentfähigkeit (Art. II § 6 Abs. 1 Satz 1 Nr. 1 IntPatÜG, Art. 138 Abs. 1 lit. a) EPÜ i. V. m. Art. 54 und 56 EPÜ) und der Nichtigkeitsgrund, dass das Streitpatent über den Umfang der ursprünglich eingereichten Anmeldung hinausgeht (Art. II § 6 Abs. 1 Satz 1 Nr. 3 IntPatÜG i. V. m. Art. 138 Abs. 1 lit. c) EPÜ), geltend gemacht werden, ist zulässig.
Die Klage ist auch begründet. Das Streitpatent hat weder in der erteilten Fassung noch in der Fassung eines der Hilfsanträge Bestand, da dem Gegenstand des Patents in der erteilten Fassung und in der Fassung der Hilfsanträge 1, 4 und 5 der Nichtigkeitsgrund der fehlenden Patentfähigkeit entgegensteht und in der Fassung der Hilfsanträge 2, 3 und 5 der Nichtigkeitsgrund, dass das Streitpatent über den Umfang der ursprünglich eingereichten Anmeldung hinausgeht.
I.
1. Das Streitpatent betrifft ein Verfahren zum Übertragen von Daten unter Verwendung eines Busses in einem Netzwerk sowie ein System zum Übertragen von Daten in einem Netzwerk von einem Sendermodul an ein Verarbeitungsmodul.
Nach den Ausführungen in der Beschreibungseinleitung werden bei der Datenübertragung von einem Sender an einen die Daten verarbeitenden Empfänger üblicherweise Handshake-Protokolle eingesetzt, um eine korrekte Datenübertragung zu gewährleisten.
Dazu sendet beispielsweise der Sender an den Empfänger ein erstes Steuersignal, um dem Empfänger die Datenübertragung mitzuteilen, und der Empfänger antwortet mit einem zweiten Steuersignal, um dem Sender den Datenempfang zu bestätigen. Jedoch können derartige Handshake-Protokolle einen Datenüberlauf auf Empfängerseite nicht verhindern, vgl. Abs. [0001] und [0002] des Streitpatents. Ein Datenüberlauf tritt gemäß Abs. [0057] beispielsweise dann auf, wenn der Empfänger die Daten nicht so schnell verarbeiten kann, wie sie vom Sender übermittelt werden und dadurch der Zwischenspeicher des Empfängers überläuft.
Vor diesem Hintergrund liegt dem Streitpatent als technisches Problem die Aufgabe zugrunde, ein System und ein Verfahren zur Datenübertragung unter Verwendung eines Busses in einem Netzwerk bereitzustellen, das einen Datenüberlauf verhindert, vgl. Abs. [0003].
Gelöst wird diese Aufgabe durch das Verfahren des Anspruchs 1 und das System des Anspruchs 6.
Mit den Hilfsanträgen 1 bis 5 wird die Datenübertragung präzisiert.
Als maßgeblicher Fachmann ist ein Ingenieur der Fachrichtung Elektro- und Informationstechnik mit einem Master-Hochschulabschluss zu definieren, der über eine mehrjährige Berufserfahrung und einschlägige Kenntnisse auf dem Gebiet der Datenübertragung verfügt.
2. Im Streitpatent werden das beanspruchte Verfahren und System anhand der Figuren 6 und 7 mit Beschreibung in den Abs. [0046] bis [0054] erläutert.
{BILD:https://testphase.rechtsinformationen.bund.de/v1/case-law/JURE219030182/bild1.png}
| Das System umfasst ein Sendermodul (sender module 610), ein Verarbeitungsmodul (receiver module 630) und einen Bus (bus 612), über den das Sendermodul (610) Daten mit einer ersten Rate zum Verarbeitungsmodul (630) überträgt (710). |
a) das Sendermodul (610) die Daten in Antwort auf ein eingehendes Zustimmungssignal (in response to an incoming accept signal 611) überträgt,
b) der Zustand des Speichermoduls (632) überwacht wird und
c) der Datenfluss durch Abschalten des Zustimmungssignals (611) angehalten wird.
In den Figuren 8A und 8B mit Beschreibung in den Abs. [0055] bis [0058] ist eine weitere Variante des beanspruchten Verfahrens dargestellt.
{BILD:https://testphase.rechtsinformationen.bund.de/v1/case-law/JURE219030182/bild3.png} {BILD:https://testphase.rechtsinformationen.bund.de/v1/case-law/JURE219030182/bild4.png}
Gemäß Fig. 8A werden Daten von einem ersten Videoverarbeitungsmodul (= Sendemodul) mit einer ersten Rate verarbeitet (810), die verarbeiteten Daten mit einer zweiten Rate an ein zweites Videoverarbeitungsmodul (= Empfangsmodul) übertragen (812), von diesem empfangen (814), in einem Speichermodul gespeichert (816) und daraus mit einer Entnahmerate abgerufen (818), wobei, wie in Fig. 8B gezeigt, das Speichermodul überlaufen kann, wenn die Daten nicht schnell genug abgerufen werden. Um dies zu verhindern, wird in diesen Fällen das Zustimmungssignal abgestellt. Darüber hinaus verarbeitet das zweite Videoverarbeitungsmodul die Daten mit einer dritten Rate (822), die kleiner als die erste und zweite Rate ist, damit das Speichermodul für keine signifikante Zeit leerläuft.
Einige Merkmale der Ansprüche sind erklärungsbedürftig.
In den Figuren 6 und 7 und der zugehörigen Beschreibung finden sich die Begriffe Receiver (630), receiving module (630) sowie pixel processing module (622, 634), wohingegen in den Ansprüchen 1 und 6 die Formulierung processing module (630) verwendet wird. Der Begriff Verarbeitungsmodul (630) bzw. processing module (630) umfasst folglich ein Empfangsmodul (receiving module 630), in dem Daten empfangen und auch verarbeitet werden (634, 718).
Unter dem Begriff Bus versteht der Fachmann entsprechend den Ausführungen in Abs. [0024] des Streitpatents und in Übereinstimmung mit seinem üblichen Verständnis ein System zur Datenübertragung zwischen mehreren Teilnehmern über einen gemeinsamen Übertragungsweg, wobei das Streitpatent in der Beschreibung der Figuren 6 bis 8 den Bus auch allgemein als Verbindung ("link") zwischen einem Sender und einem Empfänger bezeichnet, vgl. beispielsweise Abs. [0046], [0053] und [0055].
Das Sendermodul (610) überträgt die Daten gemäß Merkmal 1.3 bzw. 6.3 in Antwort auf ein eingehendes Zustimmungssignal (transmitting said data in response to an incoming accept signal). Diese Formulierung beschränkt zunächst nicht die Art des Zustimmungssignals, d. h. es könnte ein einzelnes, kurzes Signal sein, das den Beginn der Datenübertragung signalisiert, aber auch ein Signal, das für die Datenübertragung kontinuierlich an sein muss.
Nach Merkmal 1.7 bzw. 6.7 wird der Datenfluss durch Abschalten des Zustimmungssignals angehalten (stalling the data flow by shutting off said accept signal). Dies konkretisiert somit das Merkmal 1.3 dahingehend, dass das Zustimmungssignal kein einzelnes kurzes Signal ist, sondern ein Signal, das für die Datenübertragung an sein muss. Insbesondere folgt aus dem Anspruchswortlaut, dass die Daten nur so lange übertragen werden, wie das Zustimmungssignal eingeht, und dass der Datenfluss durch Abschalten des Zustimmungssignals angehalten wird. Dies folgt ebenfalls aus den Ausführungen in den Absätzen [0049], [0051] und [0057] der Beschreibung ([0049]: "[
…] In the same cycle as the input FIFO 632 is full, the accept signal 611 is deasserted. The accept signal 611 is functionally equivalent to a !FifoFull." // [0051]: "[…] When required, receiver 630 shuts off the accept signal 611 preventing FIFO 632 from being overrun with data" // [0057]: "[…] If the retrieval rate is less than the storage rate, the storage device may overrun, and the second video processing module sends a FIFO Full signal (deasserting the accept signal for example) as illustrated by block 824. This enables the second video processing module from being overrun with data."). Denn auch gemäß diesen Fundstellen wird das Zustimmungssignal deaktiviert (deasserted) bzw. abgeschaltet (shut off), wenn der Speicher voll ist, wobei das Zustimmungssignal in funktionaler Hinsicht äquivalent zur Aussage "!FifoFull" (der Speicher ist nicht voll) ist und das Abschalten des Zustimmungssignals äquivalent zur Aussage "FifoFull" (der Speicher ist voll) ist, d. h. die Datenübertragung kann nur so lange erfolgen, wie das Zustimmungssignal an ist.
Demnach ergibt sich sowohl aus dem Wortlaut des Anspruchs 1 bzw. 6 als auch aus der Beschreibung der Figuren 6 bis 8, dass für einen Datenfluss das Zustimmungssignal kontinuierlich an sein muss, was auch mit den Ausführungen der Beschwerdekammer des Europäischen Patentamts in der Entscheidung über den Einspruch gegen das Streitpatent übereinstimmt (vgl. NK8, Seite 8, Zeilen 11 bis 14: "Compared to this operation in D1, the accept signal in the claimed method is generally and constantly asserted (on) and it is shut off only when the flow of data is to be stalled.").
Den Ausführungen der Patentinhaberin, wonach das Zustimmungssignal eine beliebige zeitliche Folge von Impulsen oder Bits enthalten könne, kann daher nicht zugestimmt werden.
In diesem Zusammenhang ist auch das Merkmal 1.3 bzw. 6.3, wonach die Daten in Antwort auf das ankommende Zustimmungssignal gesendet werden, auszulegen. So wird im Ausführungsbeispiel der Figur 6 gemäß Abs. [0048] ein Bereitschaftsakzeptanzprotokoll ("ready-accept protocol") verwendet, wobei aber das "accept"-Signal (611) nicht gemäß dem in Abs. [0002] beschriebenen Stand der Technik vom Empfänger jeweils nach erfolgreichem Empfang gesendet wird (vgl. Abs. [0002]: "The receiver receiving the data responds with a control signal to acknowledge receipt of the data."), sondern permanent, bis der FIFO 632 voll ist (vgl. Abs. [0049] und [0051]).
Die Formulierung "in response to an incoming accept signal (611)" des Merkmals 1.3 bzw. 6.3 besagt demnach, dass das Accept-Signal beim Senden vorliegen muss und dass vom Sender für eine Übertragung zu überprüfen ist, ob ein Accept-Signal vorliegt. Das Zustimmungssignal signalisiert die Bereitschaft des Empfängers für den Datenempfang, so dass Daten vom Sendermodul nur solange an das Empfängermodul übertragen werden können, wie beim Sendermodul das vom Empfängermodul gesendete Zustimmungssignal eingeht.
Was den Start des Sendens auslöst, wird durch das Merkmal 1.3 bzw. 6.3 hingegen nicht vorgegeben und ist auch der Beschreibung und den Figuren des Streitpatents nicht zu entnehmen. Insbesondere kann der Fachmann den die Figuren 6 und 8 erläuternden Absätzen [0047] und [0055] des Streitpatents nur entnehmen, dass die Pixel- oder Datenverarbeitung in Antwort auf das Zustimmungssignal entweder so schnell wie möglich durchgeführt oder angehalten wird. In dem einen Fall wäre das Zustimmungssignal ein Auslöser dafür, mit der Pixel- oder Datenverarbeitung zu beginnen, und im anderen Fall ein Auslöser dafür, diese anzuhalten. Einen Hinweis, dass das Zustimmungssignal ein Auslöser für die Datenübertragung ist, gibt es im Streitpatent aber nicht. Folglich ist eine dahingehende Auslegung des Merkmals 1.3 bzw. 6.3, dass mit dem Empfang des Zustimmungssignals die Datenübertragung ausgelöst wird oder dass das Sendermodul so lange Daten an das Empfängermodul senden muss, wie es das vom Empfängermodul gesendete Zustimmungssignal empfängt, zu eng und nicht im Einklang mit der Lehre des Streitpatents. Vielmehr kommt dem Merkmal 1.3 bzw. 6.3 die Bedeutung zu, dass das Accept-Signal beim Senden vorliegen muss und dass vom Sender für eine Übertragung zu überprüfen ist, ob ein Accept-Signal vorliegt.
II.
Die Verfahren der Ansprüche 1 nach Hauptantrag und nach den Hilfsanträgen 1, 4 und 5 sind nicht patentfähig, da sie nicht neu bezüglich Druckschrift D3b sind oder dem Fachmann durch Druckschrift D3b nahegelegt werden (Art. II § 6 Abs. 1 Satz 1 Nr. 1 IntPatÜG, Art. 138 Abs. 1 lit. a) EPÜ i. V. m. Art. 54 u. 56 EPÜ).
Die Ansprüche 1 der Hilfsanträge 2, 3 und 5 sind unzulässig, da die darin beanspruchten Verfahren ursprünglich nicht offenbart sind (Art. II § 6 Abs. 1 Satz 1 Nr. 3 IntPatÜG, Artikel 138 Abs. 1 lit. c) EPÜ). Zudem sind die Verfahren des jeweiligen Anspruchs 1 der Hilfsanträge 2 und 3 im Streitpatent nicht so deutlich und vollständig offenbart, dass ein Fachmann sie ausführen kann (Art. II § 6 Abs. 1 Satz 1 Nr. 2 IntPatÜG Art. 138 Abs. 1 lit. b) EPÜ).
1. Der als Anlage NK11 vorgelegte, von der "Wayback Machine" am 11. Mai 2000 erstellte Screenshot der Website der S
… AG und die Lieferscheine gemäß den Anlagen NK12 bis NK14 belegen, dass die CD "S… Produktprogramm Product Range CD-Edition 3" gemäß Anlage NK10 zu diesem Zeitpunkt öffentlich verfügbar war und von der S… AG über Fax oder Email kostenlos bezogen werden konnte. Auf dieser CD ist als pdf-Dokument die Druckschrift D3b gespeichert, auf deren letzter Seite die Datumsangabe 2000/01 aufgedruckt ist und deren Dokumenteneigenschaften zu entnehmen ist, dass dieses Dokument nach dem 20. Januar 2000 nicht mehr geändert wurde.
Bei der Druckschrift D3 in der Fassung der Druckschrift D3b handelt es sich folglich um eine technische Produktinformation in Form einer pdf-Datei, die seit dem Januar 2000 ohne jegliche Beschränkung verfügbar war. Es liegen keine Anhaltspunkte dafür vor, dass diese technische Information mit einer Geheimhaltungsverpflichtung versehen war. Es entspricht vielmehr der allgemeinen Lebenserfahrung, dass technische Produktinformationen der Öffentlichkeit zugänglich gemacht werden, so z.B. auch als pdf-Datei auf Anfrage versandt werden. Der Umstand, dass die pdf-Datei auf einer CD-ROM erhältlich und auch im Internet abrufbar war, dient daher als zusätzlicher Beleg für die öffentliche Zugänglichkeit des Dokuments. An der Vorveröffentlichung bestehen für den Senat daher keine Zweifel. Das Dokument D3b ist somit vor dem Prioritätstag des Streitpatents der Öffentlichkeit zugänglich gemacht worden und relevanter Stand der Technik.
2. Inhaltlich befasst sich Dokument D3b entsprechend seinem Titel mit der seriellen Datenübertragung. Wie in dem ersten und zweiten Absatz der Einleitung auf Seite 5 hervorgehoben wird, arbeiten beispielsweise Computernetze der Bürokommunikation, Feldbussysteme in der Prozess-, Gebäude- und Fertigungsautomation, das Internet und ISDN mit serieller Datenübertragung. Dabei ist für die serielle Datenübertragung charakteristisch, dass die Bits über nur eine Datenleitung, zeitlich nacheinander (bitseriell) übertragen werden. Da die Mikroprozessoren in den Geräten die Daten bitparallel verarbeiten, erfolgt beim Sender eine Parallel-Seriell- und beim Empfänger eine Seriell-Parallel-Umsetzung. Diese Aufgabe übernehmen spezielle Sende- und Empfangsbausteine, die für die verschiedenen Netze am Markt verfügbar sind.
Auf den Seiten 24 bis 27 geht Druckschrift D3b genauer auf die Übertragungsverfahren ein und erläutert zunächst den Unterschied zwischen synchroner und asynchroner Datenübertragung.
Demnach sind bei der synchronen Übertragung die Signale auf den Datenleitungen immer dann gültig, wenn ein von beiden Stationen genutztes Taktsignal einen bestimmten, vordefinierten Zustand einnimmt, wohingegen bei der asynchronen Übertragung kein Taktsignal übertragen wird und sich der Empfänger in möglichst kurzen Abständen auf die Sendefrequenz synchronisieren muss. Gemäß der weiteren Beschreibung auf Seite 25, letzter Absatz bis Seite 26, vorletzter Absatz liefert die synchrone bzw. asynchrone Übertragung zwar die Voraussetzung, dass der Empfänger die Bits und Bytes korrekt lesen kann, doch wird nicht geprüft, ob der Empfänger überhaupt zur Datenaufnahme bereit ist. Zur Koordination der Datenübertragung ist daher eine zusätzliche Steuerung erforderlich, was per Software oder mit Hilfe zusätzlicher Steuer- bzw. Handshake-Leitungen realisiert werden kann, wobei in beiden Fällen der Empfänger dem Sender seine Bereitschaft zum Datenempfang signalisieren muss, bevor die Datenübertragung beginnt. Beim Hardware-Handshake wird die Datenübertragung durch zusätzliche Steuerleitungen kontrolliert.
In diesem Zusammenhang verweist Druckschrift D3b auf das nachfolgend wiedergegebene Bild 20, das eine solche Handshake-geführte Übertragung am Beispiel des Steuersignals RTS (Request To Send) zeigt.
{BILD:https://testphase.rechtsinformationen.bund.de/v1/case-law/JURE219030182/bild5.png}
Der Zustand RTS = Eins signalisiert, dass das Gerät bereit ist, Daten zu empfangen. Laufen zu viele Daten auf und besteht die Gefahr, dass der Empfangsdatenpuffer überläuft, wird das Gerät das RTS-Signal zurücknehmen. Daraufhin stoppt der Sender die Datenübergabe und setzt sie erst nach erneuter Freigabe von RTS wieder fort, vgl. Seite 26, vorletzter Absatz.
Wie aus dem Begriff "Request To Send" folgt, ist das Steuersignal RTS ein Signal, mit dem zusätzlich zur Signalisierung der Empfangsbereitschaft des Empfängers die Datenübertragung angefordert bzw. ausgelöst wird (request = Anforderung). Zudem zeigen die von den Flanken des Steuersignals RTS ausgehenden Pfeile, dass in Antwort auf das Umschalten des RTS-Signals von Eins auf Null die Datenübertragung angehalten und in Antwort auf das Umschalten von Null auf Eins wieder aufgenommen wird.
Daher offenbart Druckschrift D3b mit den Worten des Anspruchs 1
1.1 a method of transmitting data (Datenübertragung mit Handshake-Steuerleitung / vgl. Bild 20) using a bus in a network (Computernetze der Bürokommunikation, Feldbussysteme in der Prozess-, Gebäude- und Fertigungsautomation / vgl. S. 5, erster Abs.) comprising:
1.2 transmitting the data over the bus at a first rate (vgl. in Bild 20 den Pfeil Data),
1.3 wherein a sender module (Sender / vgl. Bild 20) is transmitting said data (Data) in response to an incoming accept signal (Steuersignal RTS - Request To Send / vgl. Bild 20 mit Seite 26);
1.4 receiving the data at a processing module in the network (Empfänger mit Pfeil Data / vgl. Bild 20);
1.5 storing the data in a storage module in said processing module (Empfangsdatenpuffer, Empfänger / vgl. S. 26, vorletzter Abs.);
1.6 preventing data overrun of said storage module (Empfangsdatenpuffer)
1.7 by monitoring a state of said storage module and stalling the data flow by shutting off said accept signal (vgl. S. 26, vorletzter Abs.: "Der Zustand = Eins signalisiert, dass das Gerät bereit ist, Daten zu empfangen. Laufen zu viele Daten auf und besteht die Gefahr, dass der Empfangsdatenpuffer überläuft, wird das Gerät das RTS-Signal zurücknehmen. Daraufhin stoppt der Sender die Datenübergabe und setzt sie erst nach erneuter Freigabe von RTS wieder fort.");
1.8 and processing the data stored in said storage module (Empfangsdatenpuffer) at a second rate (vgl. S. 5, erster Abs.: "Da die Mikroprozessoren in den Geräten die Daten bitparallel verarbeiten, [
…].").
Die Patentinhaberin hat demgegenüber die Patentfähigkeit des beanspruchten Verfahrens insbesondere folgendermaßen begründet:
(i) Am linken und rechten Rand von Bild 20 der Druckschrift D3b sei das RTS-Signal jeweils hoch, ohne dass eine Datenübertragung erfolge und Bild 20 zeige auch einen zeitlichen Versatz zwischen den Flanken des RTS-Signals und dem Stoppen bzw. Wiederaufnehmen der Datenübertragung. Folglich sei das Merkmal 1.3 des Anspruchs 1 in D3b nicht offenbart.
(ii) Anspruch 1 verlange, dass sowohl die Daten als auch das Zustimmungssignal über denselben Bus in digitaler Form übertragen würden, wohingegen die Übertragung des in Druckschrift D3b offenbarten RTS-Signals in analoger Form über eine eigene Steuerleitung erfolge. Eine separate Steuerleitung sei aber kein Bestandteil des anspruchsgemäßen Busses, denn Anspruch 1 schließe analoge Signale und zusätzliche Leitungen wie eine Steuerleitung zur Übertragung eines Hardware-Handshakes aus. Dieses enge Verständnis des Anspruchs 1 werde auch durch die Erläuterungen zur Bus-Bandbreite in Abs. [0063], die zahlreichen Verweise auf den MPEG-Standard und Video- bzw. Pixeldaten in der Beschreibung sowie durch die Ausführungen in den Absätzen [0053] und [0056] bestätigt, wonach alle Signale über den Bus übertragen werden.
Diesen Ausführungen konnte sich der Senat nicht anschließen, denn die in Bild 20 gezeigten Pfeile ordnen die Flanken des RTS-Signals in eindeutiger Weise dem Unterbrechen der Datenübertragung (Datenpaket 1) bzw. der Wiederaufnahme der Datenübertragung (Datenpaket 2) zu, was auch den Erläuterungen im vorletzten Absatz von Seite 26 entspricht, wonach das RTS-Signal bei der Gefahr eines Pufferüberlaufs zurückgenommen wird, woraufhin der Sender die Datenübergabe stoppt und erst nach erneuter Freigabe durch das RTS-Signal fortsetzt. Der leichte Versatz zeigt dabei den in einem realen, nicht idealen System unvermeidlichen Zeitversatz, der aufgrund der Reaktionszeiten der Systembauteile entsteht. Zudem kann der Sender zwangsläufig nur dann Daten senden, wenn Daten zum Senden vorhanden sind.
Die Bereiche am linken und rechten Rand von Bild 20 besagen demnach lediglich, dass der Sender zu diesem Zeitpunkt noch über keine zu sendenden Daten verfügt (linker Rand) bzw. alle zu sendenden Daten übermittelt hat (rechter Rand).
Das von der Patentinhaberin unter Punkt ii) vorgetragene Argument ist ebenfalls nicht stichhaltig. Denn weder den von der Patentinhaberin angeführten Fundstellen, noch den Figuren des Streitpatents kann entnommen werden, dass der Bus, auf den in den Ansprüchen 1 und 6 Bezug genommen wird, keine separate Steuer- bzw. Handshakeleitung zur Übertragung eines RTS-Signals aufweisen darf. Vielmehr zeigt Fig. 6 separate Signalwege für das Zustimmungssignal (611, Accept), das Ready-Signal (618, Ready) und das Datensignal mit Control-Information (624, Data, Control), was dem Fachmann den Hinweis gibt, dass von Anspruch 1 auch ein Bus mit einer separaten Handshakeleitung zur Übertragung des Zustimmungssignals umfasst wird. Auch der nachfolgend wiedergegebene Satz in Abs. [0053] der Beschreibung von Fig. 7: "More specifically, the pixels or other data and the control information are transmitted over the bus, interface or link at a first rate as illustrated by block 710." bringt lediglich zum Ausdruck, dass Pixel oder andere Daten sowie die Control-Information über den Bus übertragen werden, ohne aber eine separate Handshakeleitung zur Übertragung des Zustimmungssignals (611) auszuschließen. Für die Ausführungen zur Busbandbreite in Abs. [0063] gilt dies ebenfalls, da auch dort keine Offenbarung für den Ausschluss einer eigenen Handshakeleitung zu finden ist.
Das in Dokument D3b beschriebene Verfahren weist somit sämtliche Merkmale des Verfahrens nach dem erteilten Anspruch 1 gemäß Hauptantrag auf, das folglich wegen fehlender Neuheit nicht patentfähig ist.
In gleicher Weise offenbaren obige Fundstellen der D3b auch ein System mit sämtlichen Merkmalen des nebengeordneten Anspruchs 6, so dass auch dieses wegen fehlender Neuheit nicht patentfähig ist.
Vor diesem Hintergrund kann dahingestellt bleiben, ob die erteilten Ansprüche hinsichtlich der Ursprungsoffenbarung zulässig sind.
3. Anspruch 1 nach Hilfsantrag 1 ergibt sich aus Anspruch 1 des Hauptantrags, indem zwischen die Merkmale 1.3 und 1.4 das folgende Zusatzmerkmal 1.3a eingefügt wird:
1.3a "wherein the accept signal is transmitted over the bus (612)".
Wie zum Hauptantrag bereits ausgeführt wurde, gibt es im Streitpatent keine Offenbarung für den Ausschluss einer eigenen Handshakeleitung als Bestandteil eines Busses. Dementsprechend ist das Zusatzmerkmal 1.3a, wonach das Zustimmungssignal über den Bus übertragen wird, aus Seite 26 der D3a bekannt, da in deren Bild 20 ein Sender und Empfänger gezeigt ist, die über einen eine Datenleitung (Data) und eine Handshake-Leitung (RTS) umfassenden Bus miteinander verbunden sind, wobei das Zustimmungssignal über die Handshake-Leitung als Bestandteil des Busses übertragen wird.
Das Verfahren des Anspruchs 1 nach Hilfsantrag 1 ist somit wegen fehlender Neuheit nicht patentfähig.
4. Anspruch 1 nach Hilfsantrag 2 ergibt sich aus Anspruch 1 des Hauptantrags, indem das Merkmal 1.2 ersetzt wird durch das folgende Merkmal 1.2':
1.2' "transmitting the data as packets over the bus at a first rate",
und indem zwischen die Merkmale 1.3 und 1.4 das folgende Zusatzmerkmal 1.3b eingefügt wird:
1.3b "wherein the accept signal is transmitted as packets".
Demnach sollen sowohl das Daten- als auch das Zustimmungssignal als Pakete übertragen werden.
Eine Übertragung des Zustimmungssignals als Pakete ist jedoch ursprünglich nicht offenbart, denn den ursprünglichen Unterlagen und insbesondere den von der Beklagten angeführten Offenbarungsstellen auf den Seiten 6 und 20 bis 22 der ursprünglichen Anmeldung NK4 ist diesbezüglich lediglich zu entnehmen, dass Pixeldaten und zusätzliche Daten als Pakete gesendet werden, aber nicht, dass auch das Zustimmungssignal als Pakete gesendet wird. Dass nach Seite 21 der ursprünglichen Anmeldung in einem erweiterten Betrieb neben Pixeln und Handshakesteuersignalen auch ein oder mehr zusätzliche Datenpakete auf dem Bus übertragen werden können, offenbart ebenfalls keine Übertragung des Zustimmungssignals als Pakete. Zudem zeigt auch Fig. 6 der NK4, dass die Daten- und Steuersignale (Date, Control 624) nicht mit dem Zustimmungssignal (Accept 611) gleichgesetzt werden können.
Der Anspruch 1 des Hilfsantrags 2 ist daher wegen fehlender Ursprungsoffenbarung des Zusatzmerkmals 1.3b unzulässig.
Zudem folgt aus den Merkmalen 1.3, 1.6 und 1.7 des Anspruchs 1, dass für einen Datenfluss das Zustimmungssignal kontinuierlich an sein muss und der Datenüberlauf des Speichermoduls dadurch verhindert wird, dass dessen Zustand überwacht und der Datenfluss durch Abschalten des Zustimmungssignals angehalten wird. Bei einer Übertragung des Zustimmungssignals als Pakete würde der Datenfluss nur während der jeweiligen Paketlänge erfolgen und somit entgegen obiger Merkmale unabhängig vom Zustand des Speichermoduls in kurzen Abständen unterbrochen bzw. gestartet werden.
Anspruch 1 des Hilfsantrags 2 gibt dem Fachmann somit auch keine ausführbare Lehre.
5. Anspruch 1 nach Hilfsantrag 3 umfasst als Präzisierung die Zusatzmerkmale der Hilfsanträge 1 und 2, so dass auch Anspruch 1 des Hilfsantrags 3 aus obigen Gründen unzulässig und seine Lehre nicht ausführbar ist.
6. Anspruch 1 nach Hilfsantrag 4 ergibt sich aus Anspruch 1 des Hauptantrags, indem zwischen die Merkmale 1.3 und 1.4 das folgende Zusatzmerkmal 1.3c eingefügt wird:
1.3c "as long as it is receiving the accept signal (611)".
Der Sender überträgt demnach die Daten, so lange er das Zustimmungssignal empfängt.
Nach Auffassung der Patentinhaberin soll dies das beanspruchte Verfahren dahingehend beschränken, dass die Datenübertragung mit dem Empfang des Zustimmungssignals gestartet wird und so lange erfolgen muss, wie der Sender das Zustimmungssignal empfängt.
Dies ist aber ein zu enges Verständnis des Zusatzmerkmals 1.3c, das lediglich besagt, dass der Sender die Daten überträgt, so lange er das Zustimmungssignal empfängt. Dies bedeutet weder vom Wortlaut her noch aus fachmännischer Sicht, dass der Sender auch dann, wenn er keine Daten zum Senden (mehr) hat, unter allen Umständen weitere Daten senden muss, sondern lediglich, dass der Sender nur dann Daten übertragen kann, wenn er das Zustimmungssignal empfängt. Dies ist jedoch die Bedeutung, die bereits aus dem erteilten Anspruch 1 folgt, nämlich, dass für einen Datenfluss das Zustimmungssignal kontinuierlich an sein muss.
Das Verfahren des Anspruchs 1 nach Hilfsantrag 4 ist somit wegen fehlender Neuheit nicht patentfähig.
Zudem ist es weder im Streitpatent noch in der ursprünglichen Anmeldung NK4 offenbart, dass der Datenfluss mit dem Empfang des Zustimmungssignals gestartet wird, sondern lediglich, dass der Empfang des Zustimmungssignals einen Effekt auf die Datenverarbeitung des Sendermoduls hat (Abs. [0047] des Streitpatents bzw. NK4, Seite 23 ab Zeile 25), vgl. dazu auch die Ausführungen zum Hauptantrag. Insofern würde eine Auslegung des Zusatzmerkmals 1.3c entsprechend den Ausführungen der Beklagten zur Unzulässigkeit des Anspruchs 1 nach Hilfsantrag 4 führen.
Darüber hinaus muss nach den Ausführungen in den Absätzen [0047] und [0048] des Streitpatents bzw. Seite 23, Zeilen 25 bis Seite 24, Zeile 9 der NK4 der Sender (610) entsprechend der Darstellung in Fig. 6 an den Empfänger (630) ein zusätzliches Ready-Signal (618) senden, um diesem seine Sendebereitschaft mitzuteilen, was so aber nicht Teil des Anspruchs 1 nach Hilfsantrag 4 ist und ebenfalls gegen die enge Auslegung des Zusatzmerkmals 1.3c durch die Beklagte spricht.
7. Anspruch 1 nach Hilfsantrag 5 ergibt sich aus Anspruch 1 des Hauptantrags, indem in Merkmal 1.8 das "and" gestrichen wird, und an dessen Schluss das folgende Zusatzmerkmal 1.9 angefügt wird:
1.9 "and continue transmitting over the bus (612) in response to receiving the accept signal (611) again in order to ensure that the storage module (632) is never starved for data, wherein said first rate is greater than said second rate".
Demnach muss das Sendermodul in Antwort auf einen erneuten Empfang des Zustimmungssignals mit der Datenübertragung über den Bus fortfahren, um sicher zu stellen, dass das Speichermodul nie leerläuft, wobei die erste Rate größer als die zweite Rate ist.
Hinsichtlich der Offenbarung verweist die Patentinhaberin auf die Ausführungen zu Fig. 8 und insbesondere auf NK4, Seite 26, Zeilen 23 bis 29 bzw. Abs. [0058] des Streitpatents. Daraus ist das Zusatzmerkmal 1.9 aber nicht entnehmbar. Denn wie zum Streitpatent bereits ausgeführt wurde, erläutern diese Fundstellen den Fall, dass Daten vom ersten Videoverarbeitungsmodul (= Sendemodul) mit einer ersten Rate verarbeitet (810), die verarbeiteten Daten mit einer zweiten Rate an das zweite Videoverarbeitungsmodul (= Empfangsmodul) übertragen (812), von diesem empfangen (814), in einem Speichermodul gespeichert (816) und daraus mit einer Entnahmerate abgerufen (818) werden, wobei, wie in Fig. 8B gezeigt, das Speichermodul überlaufen kann, wenn die Daten nicht schnell genug abgerufen werden. Um dies zu verhindern, wird in diesen Fällen das Zustimmungssignal abgestellt. Zudem verarbeitet das zweite Videoverarbeitungsmodul die Daten mit einer dritten Rate (822), die kleiner als die erste und zweite Rate ist, damit das Speichermodul für keine signifikante Zeit leerläuft.
Das Zusatzmerkmal 1.9 beschreibt demgegenüber ein anderes Verfahren.
Anspruch 1 des Hilfsantrags 5 ist folglich unzulässig, da das Zusatzmerkmal 1.9 ursprünglich nicht offenbart ist.
Darüber hinaus wird dieses Zusatzmerkmal dem Fachmann durch Druckschrift D3b nahegelegt, vgl. deren Seite 26, vorletzter Abs.: "Der Zustand RTS = Eins signalisiert, dass das Gerät bereit ist, Daten zu empfangen. Laufen zu viele Daten auf und besteht die Gefahr, dass der Empfangsdatenpuffer überläuft, wird das Gerät das RTS-Signal zurücknehmen. Daraufhin stoppt der Sender die Datenübergabe und setzt sie erst nach erneuter Freigabe von RTS wieder fort.
Wie aus dem Begriff "Request To Send" folgt, ist das Steuersignal RTS ein Signal, mit dem zusätzlich zur Signalisierung der Empfangsbereitschaft des Empfängers die Datenübertragung angefordert bzw. ausgelöst wird (request = Anforderung). Zudem zeigen die von den Flanken des Steuersignals RTS ausgehenden Pfeile in Bild 20 des Dokuments D3b, dass in Antwort auf das Umschalten des RTS-Signals von Eins auf Null die Datenübertragung angehalten und in Antwort auf das Umschalten von Null auf Eins wiederaufgenommen wird. Dass die erste Rate, d. h. die Übertragungsrate, größer ist als die zweite Rate, d. h. die Verarbeitungsrate, entnimmt der Fachmann ebenfalls aus obigen das RTS-Signal erläuternden Ausführungen im vorletzten Abs. von Seite 26 der D3b, denn demnach wird der Füllstand des Empfangsdatenpuffers dahingehend überwacht, dass er nicht überläuft, wobei er nur dann überlaufen kann, wenn er schneller befüllt als geleert wird, bzw. wenn die Daten schneller übertragen als verarbeitet werden. Dabei ist es für den Fachmann eine Selbstverständlichkeit, dass die Datenübertragung nur solange angehalten wird, wie der Speicher noch befüllt ist, da ansonsten die Datenübertragung unnötig blockiert wäre und die im Vergleich zur Übertragungsrate langsamere Verarbeitungsrate noch stärker verlangsamt würde.
Anspruch 1 des Hilfsantrags 5 ist deshalb auch wegen fehlender erfinderischer Tätigkeit bezüglich Druckschrift D3b nicht patentfähig.
8. Für die Systeme der nebengeordneten Ansprüche 6 nach den Hilfsanträgen 1 bis 5 gelten obige Ausführungen entsprechend.
9. Als Ergebnis war das europäische Patent 1 414 015 mit Wirkung für das Hoheitsgebiet der Bundesrepublik Deutschland für nichtig zu erklären.
III.
Die Kostenentscheidung beruht auf § 84 Abs. 2 Satz 1 und Satz 2 Halbsatz 1 PatG i. V. m. § 91 Abs. 1 ZPO.
Die Entscheidung über die vorläufige Vollstreckbarkeit beruht auf § 99 Abs. 1 PatG i. V. m. § 709 Satz 1 und 2 ZPO.