Rechtsprechung / BPatG / 2. Senat / 2021

BPatG Urteil vom 10.06.2021 – 2 Ni 36/20 (EP)

2. Senat · ECLI:DE:BPatG:2021:100621U2Ni36.20EP.0

Gewerblicher RechtsschutzBundVolltext

2 zitierte Normen Als PDF speichern

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§

1Permalink zu Rn. 1recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_1

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.

2Permalink zu Rn. 2recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_2

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.

3Permalink zu Rn. 3recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_3

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:

5Permalink zu Rn. 5recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_5

1.1 A method of transmitting data using a bus (612) in a network comprising:

6Permalink zu Rn. 6recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_6

1.2 transmitting (710) the data over the bus (612) at a first rate,

7Permalink zu Rn. 7recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_7

1.3 wherein a sender module (610) is transmitting said data in response to an incoming accept signal (611);

8Permalink zu Rn. 8recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_8

1.4 receiving (712) the data at a processing module (630) in the network;

9Permalink zu Rn. 9recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_9

1.5 storing (714) the data in a storage module (632) in said processing module (630);

10Permalink zu Rn. 10recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_10

1.6 preventing data overrun of said storage module (632)

11Permalink zu Rn. 11recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_11

1.7 by monitoring a state of said storage module and stalling the data flow by shutting off said accept signal (611);

12Permalink zu Rn. 12recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_12

1.8 and processing the data stored in said storage module (632) at a second rate.

13Permalink zu Rn. 13recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_13

Anspruch 1 in deutscher Übersetzung:

14Permalink zu Rn. 14recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_14

1.1 Verfahren zum Übertragen von Daten unter Verwendung eines Busses (612) in einem Netzwerk, das beinhaltet:

15Permalink zu Rn. 15recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_15

1.2 Übertragen (710) der Daten über den Bus (612) mit einer ersten Rate,

16Permalink zu Rn. 16recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_16

1.3 wobei ein Sendermodul (610) die Daten im Ansprechen auf ein ankommendes Zustimmungssignal (611) überträgt;

17Permalink zu Rn. 17recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_17

1.4 Empfangen (712) der Daten an einem Verarbeitungsmodul (630) in dem Netzwerk;

18Permalink zu Rn. 18recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_18

1.5 Speichern (714) der Daten in einem Speichermodul (632) in dem Verarbeitungsmodul (630);

19Permalink zu Rn. 19recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_19

1.6 Verhindern eines Datenüberlaufs des Speichermoduls (632)

20Permalink zu Rn. 20recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_20

1.7 durch Überwachen des Zustands des Speichermoduls und Anhalten des Datenflusses durch Abschalten des Zustimmungssignals (611);

21Permalink zu Rn. 21recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_21

1.8 und Verarbeiten der in dem Speichermodul (632) gespeicherten Daten mit einer zweiten Rate.

23Permalink zu Rn. 23recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_23

6.1 A system for transmitting data in a network from a sender module (610) to a processing module (630),

24Permalink zu Rn. 24recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_24

6.2 wherein the sender module (610) is adapted and configured for transmitting (710) the data over a bus (612) at a first rate

25Permalink zu Rn. 25recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_25

6.3 in response to an incoming accept signal (611),

26Permalink zu Rn. 26recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_26

6.4 and wherein the processing module (630) is adapted and configured for receiving (712) the data

27Permalink zu Rn. 27recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_27

6.5 and for storing (714) the data in a storage module (632) in said processing module (630),

28Permalink zu Rn. 28recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_28

6.6 and for preventing (716) data overrun of said storage module

29Permalink zu Rn. 29recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_29

6.7 by monitoring a state of said storage module (632) and stalling the data flow by shutting off said accept signal (611);

30Permalink zu Rn. 30recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_30

6.8 and for processing the data stored in said storage module at a second rate.

31Permalink zu Rn. 31recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_31

Anspruch 6 in deutscher Übersetzung:

32Permalink zu Rn. 32recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_32

6.1 System zum Übertragen von Daten in einem Netzwerk von einem Sendermodul (610) an ein Verarbeitungsmodul (630),

33Permalink zu Rn. 33recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_33

6.2 wobei das Sendermodul (610) ausgelegt und konfiguriert ist zum Übertragen (710) der Daten über einen Bus (612) mit einer ersten Rate

34Permalink zu Rn. 34recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_34

6.3 im Ansprechen auf ein ankommendes Zustimmungssignal (611),

35Permalink zu Rn. 35recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_35

6.4 und wobei das Verarbeitungsmodul (630) ausgelegt und konfiguriert ist zum Empfangen (712) der Daten

36Permalink zu Rn. 36recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_36

6.5 und zum Speichern (714) der Daten in einem Speichermodul (632) in dem Verarbeitungsmodul (630),

37Permalink zu Rn. 37recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_37

6.6 und zum Verhindern (716) eines Datenüberlaufs des Speichermoduls (632)

38Permalink zu Rn. 38recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_38

6.7 durch Überwachen des Zustands des Speichermoduls (632) und Anhalten des Datenflusses durch Abschalten des Zustimmungssignals (611);

39Permalink zu Rn. 39recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_39

6.8 und zum Verarbeiten der in dem Speichermodul gespeicherten Daten mit einer zweiten Rate.

40Permalink zu Rn. 40recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_40

Zur Stützung ihres Vorbringens hat die Klägerin die folgenden Dokumente genannt:

41Permalink zu Rn. 41recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_41
NK1 Erweiterung der Verletzungsklage 7 O 58/18 vor dem LG Mannheim,NK2 EP 1 414 015 B1 (Streitpatent),NK3 Registerauszug vom 24. Juli 2019 zum Aktenzeichen 603 51 073.6, unter dem das DPMA das Streitpatent führt,NK4 EP-Ursprungsanmeldung,NK5 Merkmalsgliederung der erteilten Ansprüche 1 und 6,NK6 Eingabe des Vertreters der Anmelderin im EP-Prüfungsverfahren,NK7 Screenshot der Website des S…AG vom 10. Mai 2000,NK8 Entscheidung der Beschwerdekammer des EPA T 2027/12 vom 7. September 2017,NK9 Screenshots der archivierten Webseite http://www.samson.de/pdf_de/_deti.htm,NK10 CD betreffend das „S… Produktprogramm, CD-Edition 3“,NK11 über das digitale Archiv „Wayback Machine“ erstellten Screenshot der Webseite der S… AG vom 11. Mai 2000,NK12 Lieferschein vom 6. März 2000 über die Lieferung einer CD in der Edition 3 von der S… AG an die C… GmbH,NK13 Lieferschein vom 10. April 2000 über die Lieferung einer CD in der Edition 3 von der S… AG an die Stadtwerke München,NK14 Lieferscheine vom 21. August 2000 bzw. 8. August 2000 über die Lieferung von CDs in der Edition 3 von der S… AG an die Messe „S.A.W. Basel 2000“ mit 50 und an die Messe „PAP FOR St. Petersburg 2000“ mit 25 CDs,D1 Roger Zimmermann u. a.: Yima: Design and Evaluation of a Streaming Media System for Residential Broadband Services; In: W. Jonker (Ed.): Databases in Telecommunications Il LNCS 2209, pp. 116-125, 2001, Springer-Verlag Berlin Heidelberg 2001,D2 US 6 282 462 B1,D3 S…, Technische Information Serielle Datenübertragung, Teil 1 Grundlagen, S… AG V74 / DKE, S… AG MESS- UND REGELTECHNIK …straße …, … Frankfurt, 2000/03 L153,D3a über das digitale Archiv „Wayback Machine“ heruntergeladene Fassung des Dokumenst D3 mit der Datumsangabe 2000/05,D3b auf der CD (NK10) gespeicherte deutsche Fassung des Dokuments D3 mit der Datumsangabe 2000/01,D3c auf der CD (NK10) gespeicherte englische Fassung des Dokuments D3 mit der Datumsangabe 1999/12,D4 WO 03 / 036 848 A1,D5 US 5 606 359 A.
42Permalink zu Rn. 42recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_42

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.

43Permalink zu Rn. 43recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_43

Die Klägerin stellt den Antrag,

44Permalink zu Rn. 44recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_44

das europäische Patent EP 1 414 015 mit Wirkung für das Hoheitsgebiet der Bundesrepublik Deutschland für nichtig zu erklären.

45Permalink zu Rn. 45recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_45

Die Beklagte beantragt,

46Permalink zu Rn. 46recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_46

die Klage abzuweisen,

48Permalink zu Rn. 48recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_48

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.

49Permalink zu Rn. 49recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_49

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.

50Permalink zu Rn. 50recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_50

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.

51Permalink zu Rn. 51recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_51

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:

52Permalink zu Rn. 52recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_52

1.3a „wherein the accept signal is transmitted over the bus (612)”.

53Permalink zu Rn. 53recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_53

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‘:

54Permalink zu Rn. 54recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_54

1.2‘ „transmitting (710) the data as packets over the bus (612) at a first rate“,

55Permalink zu Rn. 55recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_55

und indem zwischen die Merkmale 1.3 und 1.4 das folgende Zusatzmerkmal 1.3b eingefügt wird:

56Permalink zu Rn. 56recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_56

1.3b „wherein the accept signal is transmitted as packets“.

57Permalink zu Rn. 57recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_57

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.

58Permalink zu Rn. 58recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_58

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:

59Permalink zu Rn. 59recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_59

1.3c „as long as it is receiving the accept signal (611)“.

60Permalink zu Rn. 60recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_60

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:

61Permalink zu Rn. 61recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_61

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“.

62Permalink zu Rn. 62recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_62

Wegen der weiteren Einzelheiten wird auf den Akteninhalt verwiesen.

Entscheidungsgründe§

63Permalink zu Rn. 63recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_63

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.

64Permalink zu Rn. 64recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_64

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.

65Permalink zu Rn. 65recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_65

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.

66Permalink zu Rn. 66recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_66

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.

67Permalink zu Rn. 67recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_67

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.

68Permalink zu Rn. 68recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_68

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].

69Permalink zu Rn. 69recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_69

Gelöst wird diese Aufgabe durch das Verfahren des Anspruchs 1 und das System des Anspruchs 6.

70Permalink zu Rn. 70recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_70

Mit den Hilfsanträgen 1 bis 5 wird die Datenübertragung präzisiert.

71Permalink zu Rn. 71recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_71

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.

72Permalink zu Rn. 72recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_72

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.

73Permalink zu Rn. 73recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_73
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).
Im Verarbeitungsmodul (630) werden die Daten empfangen (712), in einem Speichermodul (FIFO (First In First Out) 632) gespeichert (714) und die in dem Speichermodul (632) gespeicherten Daten mit einer zweiten Rate verarbeitet (718).
Wesentlich ist, dass ein Datenüberlauf des Speichermoduls (632) verhindert wird (716), beispielsweise wenn die erste Rate höher ist als die zweite Rate, indem
74Permalink zu Rn. 74recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_74

a) das Sendermodul (610) die Daten in Antwort auf ein eingehendes Zustimmungssignal (in response to an incoming accept signal 611) überträgt,

75Permalink zu Rn. 75recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_75

b) der Zustand des Speichermoduls (632) überwacht wird und

76Permalink zu Rn. 76recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_76

c) der Datenfluss durch Abschalten des Zustimmungssignals (611) angehalten wird.

77Permalink zu Rn. 77recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_77

In den Figuren 8A und 8B mit Beschreibung in den Abs. [0055] bis [0058] ist eine weitere Variante des beanspruchten Verfahrens dargestellt.

78Permalink zu Rn. 78recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_78

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.

79Permalink zu Rn. 79recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_79

Einige Merkmale der Ansprüche sind erklärungsbedürftig.

80Permalink zu Rn. 80recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_80

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).

81Permalink zu Rn. 81recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_81

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].

82Permalink zu Rn. 82recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_82

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.

83Permalink zu Rn. 83recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_83

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.

84Permalink zu Rn. 84recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_84

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.“).

85Permalink zu Rn. 85recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_85

Den Ausführungen der Patentinhaberin, wonach das Zustimmungssignal eine beliebige zeitliche Folge von Impulsen oder Bits enthalten könne, kann daher nicht zugestimmt werden.

86Permalink zu Rn. 86recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_86

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]).

87Permalink zu Rn. 87recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_87

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.

88Permalink zu Rn. 88recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_88

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.

89Permalink zu Rn. 89recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_89

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Ü).

90Permalink zu Rn. 90recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_90

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Ü).

91Permalink zu Rn. 91recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_91

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.

92Permalink zu Rn. 92recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_92

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.

93Permalink zu Rn. 93recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_93

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.

94Permalink zu Rn. 94recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_94

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.

95Permalink zu Rn. 95recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_95

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.

96Permalink zu Rn. 96recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_96

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.

97Permalink zu Rn. 97recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_97

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.

98Permalink zu Rn. 98recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_98

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.

99Permalink zu Rn. 99recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_99

Daher offenbart Druckschrift D3b mit den Worten des Anspruchs 1

100Permalink zu Rn. 100recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_100

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:

101Permalink zu Rn. 101recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_101

1.2 transmitting the data over the bus at a first rate (vgl. in Bild 20 den Pfeil Data),

102Permalink zu Rn. 102recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_102

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);

103Permalink zu Rn. 103recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_103

1.4 receiving the data at a processing module in the network (Empfänger mit Pfeil Data / vgl. Bild 20);

104Permalink zu Rn. 104recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_104

1.5 storing the data in a storage module in said processing module (Empfangsdatenpuffer, Empfänger / vgl. S. 26, vorletzter Abs.);

105Permalink zu Rn. 105recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_105

1.6 preventing data overrun of said storage module (Empfangsdatenpuffer)

106Permalink zu Rn. 106recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_106

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.“);

107Permalink zu Rn. 107recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_107

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, […].“).

108Permalink zu Rn. 108recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_108

Die Patentinhaberin hat demgegenüber die Patentfähigkeit des beanspruchten Verfahrens insbesondere folgendermaßen begründet:

109Permalink zu Rn. 109recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_109

(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.

110Permalink zu Rn. 110recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_110

(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.

111Permalink zu Rn. 111recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_111

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.

112Permalink zu Rn. 112recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_112

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).

113Permalink zu Rn. 113recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_113

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.

114Permalink zu Rn. 114recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_114

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.

115Permalink zu Rn. 115recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_115

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.

116Permalink zu Rn. 116recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_116

Vor diesem Hintergrund kann dahingestellt bleiben, ob die erteilten Ansprüche hinsichtlich der Ursprungsoffenbarung zulässig sind.

117Permalink zu Rn. 117recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_117

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:

118Permalink zu Rn. 118recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_118

1.3a „wherein the accept signal is transmitted over the bus (612)”.

119Permalink zu Rn. 119recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_119

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.

120Permalink zu Rn. 120recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_120

Das Verfahren des Anspruchs 1 nach Hilfsantrag 1 ist somit wegen fehlender Neuheit nicht patentfähig.

121Permalink zu Rn. 121recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_121

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‘:

122Permalink zu Rn. 122recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_122

1.2‘ „transmitting the data as packets over the bus at a first rate“,

123Permalink zu Rn. 123recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_123

und indem zwischen die Merkmale 1.3 und 1.4 das folgende Zusatzmerkmal 1.3b eingefügt wird:

124Permalink zu Rn. 124recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_124

1.3b „wherein the accept signal is transmitted as packets“.

125Permalink zu Rn. 125recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_125

Demnach sollen sowohl das Daten- als auch das Zustimmungssignal als Pakete übertragen werden.

126Permalink zu Rn. 126recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_126

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.

127Permalink zu Rn. 127recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_127

Der Anspruch 1 des Hilfsantrags 2 ist daher wegen fehlender Ursprungsoffenbarung des Zusatzmerkmals 1.3b unzulässig.

128Permalink zu Rn. 128recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_128

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.

129Permalink zu Rn. 129recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_129

Anspruch 1 des Hilfsantrags 2 gibt dem Fachmann somit auch keine ausführbare Lehre.

130Permalink zu Rn. 130recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_130

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.

131Permalink zu Rn. 131recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_131

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:

132Permalink zu Rn. 132recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_132

1.3c „as long as it is receiving the accept signal (611)“.

133Permalink zu Rn. 133recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_133

Der Sender überträgt demnach die Daten, so lange er das Zustimmungssignal empfängt.

134Permalink zu Rn. 134recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_134

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.

135Permalink zu Rn. 135recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_135

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.

136Permalink zu Rn. 136recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_136

Das Verfahren des Anspruchs 1 nach Hilfsantrag 4 ist somit wegen fehlender Neuheit nicht patentfähig.

137Permalink zu Rn. 137recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_137

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.

138Permalink zu Rn. 138recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_138

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.

139Permalink zu Rn. 139recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_139

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:

140Permalink zu Rn. 140recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_140

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“.

141Permalink zu Rn. 141recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_141

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.

142Permalink zu Rn. 142recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_142

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.

143Permalink zu Rn. 143recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_143

Das Zusatzmerkmal 1.9 beschreibt demgegenüber ein anderes Verfahren.

144Permalink zu Rn. 144recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_144

Anspruch 1 des Hilfsantrags 5 ist folglich unzulässig, da das Zusatzmerkmal 1.9 ursprünglich nicht offenbart ist.

145Permalink zu Rn. 145recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_145

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.

146Permalink zu Rn. 146recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_146

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.

147Permalink zu Rn. 147recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_147

Anspruch 1 des Hilfsantrags 5 ist deshalb auch wegen fehlender erfinderischer Tätigkeit bezüglich Druckschrift D3b nicht patentfähig.

148Permalink zu Rn. 148recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_148

8. Für die Systeme der nebengeordneten Ansprüche 6 nach den Hilfsanträgen 1 bis 5 gelten obige Ausführungen entsprechend.

149Permalink zu Rn. 149recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_149

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.

150Permalink zu Rn. 150recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_150

Die Kostenentscheidung beruht auf § 84 Abs. 2 Satz 1 und Satz 2 Halbsatz 1 PatG i. V. m. § 91 Abs. 1 ZPO.

151Permalink zu Rn. 151recht.nulegal.eu/rechtsprechung/bpatg/2021-06-10/2-ni-36-20-ep#rd_151

Die Entscheidung über die vorläufige Vollstreckbarkeit beruht auf § 99 Abs. 1 PatG i. V. m. § 709 Satz 1 und 2 ZPO.