Rechtsprechung / BPatG / 2023
BPatG Beschluss vom 26.04.2023 – 20 W (pat) 2/23
20. Senat · ECLI:DE:BPatG:2023:260423B20Wpat2.23.0
BUNDESPATENTGERICHT
20 W (pat) 2/23 ________________________
(Aktenzeichen)
Verkündet am
26. April 2023
…
B E S C H L U S S
In der Beschwerdesache
…
ECLI:DE:BPatG:2023:260423B20Wpat2.23.0
betreffend das Patent 10 2010 014 254
hat der 20. Senat (Technischer Beschwerdesenat) auf die mündliche Verhandlung
vom 26.04.2023 durch den Vorsitzenden Richter Dipl.-Ing. Musiol, die Richterin
Dorn sowie die Richter Dipl.-Phys. Univ. Bieringer und Dr.-Ing. Ball beschlossen:
Der Beschluss der Patentabteilung 31 des Deutschen Patent- und
Markenamts vom 08.09.2022 wird aufgehoben und das Patent
10 2010 014 254 in vollem Umfang widerrufen.
G r ü n d e
I.
Gegen das am 08.04.2010 angemeldete und am 04.06.2019 von der Prüfungsstelle
für Klasse H 04 L des Deutschen Patent- und Markenamts (DPMA) erteilte Patent
10 2010 014 254 mit der Bezeichnung
„System und Verfahren zur Überwachung einer Netzkommunikation auf
multiplen Netzwerkschichten“,
das am 19.09.2019 veröffentlicht wurde, hat die Einsprechende am 19.06.2020
Einspruch eingelegt mit dem Antrag, das Patent zu widerrufen. Zur Begründung hat
sie sich auf die Widerrufsgründe der fehlenden Patentfähigkeit (§ 21 Abs. 1 Nr. 1
PatG), der mangelnden Ausführbarkeit (§ 21 Abs. 1 Nr. 2 PatG) sowie der
unzulässigen Erweiterung (§ 21 Abs. 1 Nr. 4 PatG) gestützt. Die Patentabteilung 31
des DPMA hat das Patent daraufhin mit am Ende der Anhörung vom 08.09.2022
verkündetem Beschluss in vollem Umfang aufrechterhalten.
Gegen diesen Beschluss hat die Einsprechende am 15.12.2022 Beschwerde
eingelegt.
Im Rahmen des Prüfungs-
und Einspruchsverfahrens sind von den
Verfahrensbeteiligten folgende Druckschriften und Dokumente als Stand der
Technik genannt worden:
E1/D1
US 2003/0086425 A1
E2
E3
US 2003/0028634 A1
FlowMon Probe Handbook, The Liberouter Project Team,
Version 1.5.0,
revision 1.15, 18. Februar 2009,
http://www.liberouter.org/package_releases/flowmon-
1.5.0/flowmon-handbook.html
E4
Architecture for IP Flow Information Export, Network Working
Group, Request
for Comments: 5470, March 2009,
https://www.ietf.org/rfc/rfc5470.txt
E5
Requirements for IP Flow Information Export (IPFIX),
Network Working Group, Request for Comments: 3917,
October 2004, https://www.ietf.org/rfc/rfc3917.txt
E6
Cisco Systems NetFlow Services Export Version 9, Network
Working Group, Request for Comments: 3954, October
2004, https://www.ietf.org/rfc/rfc3954.txt
E7/D2
US 2007/0086336 A1
E8
E9
E10
E11
E12
E13
WO 2006/065863 A2
WO 03/060643 A2
US 2008/0002820 A1
DE 600 36 848 T2
EP 1 376 931 A1
US 2009/0013210 A1
US 2004/0172464 A1
US 2007/0081471 A1
US 2007/0252695 A1
US 6,243,454 B1
US 6,411,923 B1
E14
E15
E16
E17
E18
E19/D3
US 2010/0246411 A1
E20
Cisco IOS Flexible NetFlow Technology Q&A, 19. Juni 2006,
https://www.cisco.com/c/en/us/products/collateral/ios-nx-ossoftware/flexible-netflow/prod_qas0900aecd804be091.html
Der Senat hat mit Schreiben vom 07.03.2023 ferner die beiden Druckschriften
E21
Deri, L., „Open Source VoIP Traffic Monitoring“,
In:
Proceedings of SANE, May 2006
und
E22
Lee, C.-Y. et al., „A VoIP Traffic Monitoring System based on
NetFlow v9“, In: International Journal of Advanced Science
and Technology, Vol. 4, pp. 1-8, March 2009
in das Verfahren eingeführt und die Verfahrensbeteiligten gleichzeitig darauf
hingewiesen, dass der Gegenstand des Patentanspruchs 1 in der erteilten Fassung
ausgehend von der Druckschrift E6 (RFC 3954) in Zusammenschau mit einer der
Druckschriften E21 oder E22 mangels erfinderischer Tätigkeit nicht patentfähig sein
dürfte.
Der Bevollmächtigte der Einsprechenden und Beschwerdeführerin beantragt,
den Beschluss der Patentabteilung 31 des Deutschen Patent- und
Markenamts vom 08.09.2022 aufzuheben und das Patent 10 2010 014 254
in vollem Umfang zu widerrufen.
Für die Patentinhaberin und Beschwerdegegnerin hat, wie mit Telefax ihres
Bevollmächtigten vom 18.04.2023 angekündigt, niemand an der mündlichen
Verhandlung teilgenommen. Sie hat im Beschwerdeverfahren auch keine Anträge
gestellt.
Der Patentanspruch 1 in der erteilten Fassung lautet:
Wegen des Wortlauts des nebengeordneten Patentanspruchs 5 sowie der auf die
Patentansprüche 1 bzw. 5 direkt oder indirekt rückbezogenen Patentansprüche 2
bis 4 bzw. 6 bis 8 sowie weiterer Einzelheiten wird auf die Akte verwiesen.
II.
Die zulässige Beschwerde der Einsprechenden ist begründet, da der Gegenstand
des Patentanspruchs 1 in der erteilten Fassung nicht auf einer erfinderischen
Tätigkeit beruht und damit nicht patentfähig ist (§ 21 Abs. 1 Nr. 1, § 1 Abs. 1, § 4
PatG).
1.
Das Streitpatent (DE 10 2010 014 254 B4) betrifft laut Bezeichnung ein
„System und Verfahren zur Überwachung einer Netzkommunikation auf multiplen
Netzwerkschichten“ (vgl. Streitpatent, Titel und Abs. [0001]).
In der Beschreibungseinleitung wird ausgeführt, dass es bereits eine Vielzahl von
Netzüberwachungssystemen gebe, die sich jedoch meist auf die (unteren) OSI
Schichten 1 bis 3 sowie auf die Hardware konzentrierten und die folglich kein
vollständiges Bild aller an einer Kommunikation beteiligten Anwendungen und
Hardware für verschiedene Netzebenen bereitstellten.
Darüber hinaus könnten die bekannten Systeme auch die unterschiedlichen Pfade
für Signalisierungspakete und Mediendaten einer Kommunikation über ein
Netzwerk nicht darstellen, was zu Problemen bei der Fehlerdiagnose führen könne
(vgl. Streitpatent, Abs. [0002]).
Die in der Beschreibungseinleitung genannte Druckschrift US 2003/0086425 A1
erkenne auf den Schichten 2 und 3 nur die Netz-Topologie bzw. die Anordnung der
physikalischen Geräte im Netzwerk, sodass eine Fehlerdiagnose insbesondere bei
Anwendungen oberhalb der Schicht 3 nicht durchzuführen sei (vgl. Streitpatent,
Abs. [0003]).
Die ebenfalls bekannte US 2007/0086336 A1 könne zwar punktuell, sozusagen als
Stichprobe an einer Stelle im Netzwerk eine Schicht-7-Statistik für einen
Abonnenten ermitteln, sei jedoch nicht in der Lage, auf der Schicht 7 alle an einer
Kommunikation beteiligten Geräte, Anwendungen und Pfade zu identifizieren,
sodass eine Diagnose von speziellen Fehlern ohne Verfolgung des kompletten
Kommunikationspfads über multiple Schichten hinweg nicht möglich sei (vgl.
Streitpatent, Abs. [0004]).
Davon ausgehend liege dem Streitpatent - im gegebenen technischen Kontext einer
Netz- bzw. Kommunikationsüberwachung - die Aufgabe zugrunde, die oben
genannten Probleme des Stands der Technik zu lösen und die entsprechenden
Nachteile zu vermeiden (vgl. Streitpatent, Abs. [0005]).
2.
Zur Lösung dieser Aufgabe wird
in der erteilten Fassung des
Patentanspruchs 1 das folgende System zur Überwachung einer Kommunikation
vorgeschlagen (mit hinzugefügter Merkmalsgliederung entsprechend der von der
Patentabteilung 31 vorgenommenen Gliederung):
A1
A2
A3
A4
A5
A6
A7
A8
A9
System zur Überwachung einer Kommunikation, umfassend:
einen Netzwerkmonitor, der so konfiguriert ist,
dass er eine Stückliste eines Medienpfades Kommunikation zwischen Kommunikationsgeräten über ein Netz erhält,
einer
Mehrzahl
für die von
dass er eine Stückliste eines Signalisierungspfades für die Kommunikation von Kommunikationsgeräten über ein Netz erhält,
Mehrzahl
zwischen
einer
wobei die Stückliste des Medienpfades und die Stückliste des Signalisierungspfades jeweils eine Mehrzahl von Elementen umfassen,
und wobei die Stückliste des Medienpfades und die Stückliste des eines Kommunikationspfades umfassen,
Signalisierungspfades
Stückliste
eine
dass er mindestens ein Konfigurationspaket an eine Mehrzahl von Netzwerkanalysatoren sendet,
um ein oder mehrere Pakete, die einen Kommunikationsstatus in Bezug auf mindestens eines aus der Mehrzahl von Elementen in der Stückliste des Kommunikationspfades enthalten, zu überwachen,
dass er ein Antwortpaket, das den Kommunikationsstatus in Bezug auf das mindestens eine aus der Mehrzahl von in der Stückliste des Kommunikationspfades Elementen enthält, empfängt
und dass er den Kommunikationsstatus in Bezug auf das überwachte mindestens eine aus der Mehrzahl von Elementen in der Stückliste des Kommunikationspfades ausgibt,
und Netzwerkanalysatoren, die so konfiguriert sind,
umfassend
ferner
eine
Mehrzahl
von
dass sie das mindestens eine Konfigurationspaket empfangen,
dass sie das eine oder die mehreren Pakete, die den in Bezug auf die Mehrzahl von Kommunikationsstatus Elementen in der Stückliste des Kommunikationspfades enthalten, überwachen
und dass sie das Antwortpaket an den Netzwerkmonitor senden.
A10
A11
A12
A13
A14
3.
Das Streitpatent richtet sich dem technischen Sachgehalt nach an einen
Ingenieur der Elektrotechnik bzw. Nachrichtentechnik mit abgeschlossenem
Hochschulstudium, der über eine mehrjährige Berufserfahrung in der Entwicklung
von Sicherheits- und Überwachungssystemen
für Kommunikations- und
Datennetze verfügt. Zu seinem Fachwissen zählen die einschlägigen Standards.
4.
Dieser Fachmann entnimmt dem Vorrichtungsanspruch 1 (bzw. ebenso dem
nebengeordneten, im Wesentlichen analogen Verfahrensanspruch 5) in seiner
erteilten Fassung folgende Lehre:
Das mit dem geltenden Patentanspruch 1 beanspruchte System zur Überwachung
einer Kommunikation (Merkmal A1) weist als räumlich-körperliche Komponenten
-
-
einen Netzwerkmonitor gemäß Merkmal A2 sowie
eine Mehrzahl von (d.h. mindestens zwei) Netzwerkanalysatoren gemäß
Merkmal A11
auf. Die übrigen Merkmale sind im Wesentlichen auf die vom Netzwerkmonitor bzw.
von den Netzwerkanalysatoren durchzuführenden Verfahrensschritte gerichtet.
Hinsichtlich der Überwachung einer Kommunikation gemäß Merkmal A1 nennt das
Streitpatent als Beispiel explizit eine VoIP-Sprachkommunikation, welche eine SIP-
Signalisierung umfasst (vgl. Streitpatent, Abs. [0013], [0015]).
Der Netzwerkmonitor erhält sowohl eine Stückliste eines Medienpfads als auch eine
Stückliste eines Signalisierungspfads
für die Kommunikation zwischen
Kommunikationsgeräten über ein Netz, wobei beide Stücklisten jeweils eine
Mehrzahl von Elementen umfassen sollen (Merkmale A3, A4 und A5).
Eine Stückliste umfasst nach der allgemeinsten Definition gemäß Streitpatent,
Absatz [0005], eine Mehrzahl von – d.h. mindestens zwei – an der Kommunikation
beteiligten Elementen, wobei es sich bei einem Element bspw. um Hardware,
Software oder um eine Verknüpfung handelt. Die im selben Absatz genannte
Anwendungsschicht (Schicht 7) ist in den Anspruchswortlaut offensichtlich nicht
eingegangen, d.h. die aufgelisteten Elemente in den Stücklisten können ggf. auch
nur die unteren Kommunikationsschichten (bspw. Schicht 3) betreffen (vgl. auch
Streitpatent, Abs. [0024]).
Im Gegensatz zum Ausführungsbeispiel gemäß
Streitpatent, Absätze [0014] und [0015] müssen die jeweiligen Stücklisten
anspruchsgemäß auch nicht alle Elemente umfassen, welche die entsprechenden
Medienpakete bzw. Signalisierungspakete der Kommunikation verarbeiten.
Somit ist es auch anspruchsgemäß, wenn die Stücklisten des Medienpfads lediglich
die zwei an der Kommunikation beteiligten Endgeräte und überhaupt keine
Elemente im Zugangsnetz oder Kernnetz (z.B. Router, Switche) oder auch lediglich
Elemente im Zugangsnetz oder Kernnetz und keine Endgeräte umfassen.
Gleiches gilt auch für die Stückliste des Signalisierungspfads, welche durchaus
sogar die gleichen Elemente wie diejenige des Medienpfads enthalten kann.
Darüber hinaus bleibt im Patentanspruch 1 offen, wie der Netzwerkmonitor die
entsprechenden Stücklisten erhält. Gemäß Streitpatent, Absatz [0013], kann der
Erhalt der Stückliste für einen Medienpfad auf vielfältige Weise, u.a. wie in der
Druckschrift US 2003/0086425 A1 (E1) beschrieben, erfolgen, wobei die E1 eine
Bestimmung der Topologie des Netzwerks mit anschließender Pfad- bzw.
Routensuche betrifft. Zur Überzeugung des Senats ist jedoch eine solche
Pfadbestimmung mit dem geltenden Patentanspruch 1 nicht beansprucht.
Das Streitpatent führt hinsichtlich der Stückliste des Signalisierungspfads in Absatz
[0015] aus, dass diese auch vom Netzwerkmonitor aufgrund der Stückliste des
Medienpfads ermittelt werden kann. Das Streitpatent versteht somit unter der
Begrifflichkeit des „Erhaltens“ im Wesentlichen ein Bestimmen bzw. ein Ermitteln
der Stücklisten durch das Überwachungssystem selbst, wobei jedoch auch ein
Erhalten der Stücklisten von extern umfasst ist. Nach fachmännischem Verständnis
fällt unter den Anspruchsgegenstand daher bspw. ebenfalls ein Erhalten der
Stücklisten durch manuelle Eingabe eines Administrators an einer
Benutzerschnittstelle, bspw. einem GUI.
Mit Merkmal A6 werden die beiden Stücklisten von Medienpfad und
Signalisierungspfad zu einer gemeinsamen Stückliste eines Kommunikationspfads
zusammengefasst. Nach Auffassung des Senats handelt es sich bei vorliegenden
Stücklisten für Signalisierung und Nutzdaten um ein technisches Nullmerkmal.
Gemäß den Merkmalen A7 und A8 sendet der Netzwerkmonitor mindestens ein
Konfigurationspaket an eine Mehrzahl
von,
d.h. mindestens
zwei,
Netzwerkanalysatoren, wobei das Konfigurationspaket die Netzwerkanalysatoren
dahingehend konfiguriert, ein oder mehrere Pakete zu überwachen, wobei die
Pakete einen Kommunikationsstatus bezüglich mindestens einem Element aus der
Stückliste des Kommunikationspfads, also Elemente aus dem Medienpfad und/oder
dem Signalisierungspfad,
enthalten.
Insofern
kann
es
sich
beim
Konfigurationspaket nicht um jedes beliebige Paket handeln.
Das Streitpatent, Figur 1, Bezugszeichen 150, zeigt Netzwerkanalysatoren („NA“),
welche sowohl im Endgerät als auch in den Netzwerkelementen von dem Zugangs-
bzw. Kernnetz integriert sind. Das Streitpatent, Absatz [0011] beschreibt zudem
passive oder überbrückte Netzwerkanalysatoren.
Das Streitpatent führt hinsichtlich der Konfiguration weiter aus, dass diese bspw.
analog zur Druckschrift US 2010/0246411 A1 (E19) erfolgen könne (vgl.
Streitpatent, Abs. [0011]). Gemäß Absatz [0017] beinhaltet das anspruchsgemäße
Konfigurationspaket eine Aufforderung, welche rundgestrahlt („broadcast“) werden
kann, gemäß Absätzen
[0032] bis
[0033] kann das Konfigurationspaket
entsprechende Befehle enthalten, welche den Netzwerkanalysator zur
Überwachung der Pakete veranlassen.
Die Netzwerkanalysatoren überwachen u.a. Pakete mit einer speziellen IP- oder
MAC-Adresse, indem sie die Paketheader untersuchen und Pakete von/an ein(em)
Endgerät zählen oder die Nutzinformation prüfen (vgl. Streitpatent, Abs. [0018],
[0029], [0032] - [0033]).
Das Ermitteln des Kommunikationsstatus im überwachten Paket betrifft gemäß den
Absätzen [0017] bis [0018] bspw. eine Rauschmetrik, eine Echometrik, eine
Signalqualität, Zeitstempel, verlorene/verzögerte Pakete oder auch Pakettypen.
Die Netzwerkanalysatoren melden den ermittelten Kommunikationsstatus an den
Netzwerkmonitor mittels Antwortpaketen zurück (vgl. Streitpatent, Abs. [0019];
Merkmal A9).
Der Netzwerkmonitor gibt gemäß Merkmal A10 nach dem Empfang der
Antwortpakete den in den Antwortpaketen übermittelten Kommunikationsstatus
aus. Das Streitpatent lehrt in Figur 3, Bezugszeichen 370, 371 i.V.m. den Absätzen
[0025] und [0026] ein Anzeigen des empfangenen Kommunikationsstatus und in
Figur 4, Bezugszeichen 404, 405 i.V.m. Absatz [0030] ein Anzeigen des
Kommunikationsstatus in den einzelnen Elementen der Stückliste auf einem
Display. Alternativ könnten die Ergebnisse aber auch an eine Anwendung gesendet
werden.
Die übrigen Merkmale A11 bis A14 betreffen im Wesentlichen die bereits hinsichtlich
des Netzwerkmonitors diskutierten Verfahrensschritte, jedoch nunmehr aus Sicht
der Netzwerkanalysatoren. Der Fachmann versteht somit diese Merkmale in
analoger Weise.
5.
Der Gegenstand des Patentanspruchs 1 in seiner erteilten Fassung beruht
nicht auf einer erfinderischen Tätigkeit gegenüber einer Zusammenschau der
Druckschrift E6 mit jeweils einer der Druckschriften E21 oder E22 (§ 4 PatG).
Die Druckschrift E6 (RFC 3954) betrifft das von der Firma Cisco spezifizierte
Exportprotokoll für NetFlow-Dienste in der Version 9 aus 2004 (vgl. E6, Titel). Cisco
NetFlow dient als Basisprotokoll für das Exportprotokoll IPFIX gemäß E4 / RFC
5470 bzw. E5 / RFC 3917 (vgl. E6, S. 26, „The IPFIX protocol (IP Flow Information
eXport), which has chosen the NetFlow version 9 protocol as the base protocol,
addresses the security considerations discussed in this section. See the security
section of IPFIX requirement draft [RFC3917] for more information.“).
Mit den NetFlow-Diensten lässt sich ein System zur Überwachung einer
Kommunikation aufbauen („network monitoring, …application monitoring …user
monitoring … security analysis“), um bspw. Netzwerkadministratoren einen Zugang
zur IP Flow Information aus ihren Datennetzen bereitzustellen (vgl. E6, S. 2 – S. 3,
„Cisco Systems' NetFlow services provide network administrators with access to IP
flow information from their data networks.“; Merkmal A1).
Dazu werden eine Mehrzahl von Netzwerk-Elementen, wie bspw. vom Administrator
ausgewählte dedizierte Router und Switche, als Netzwerkanalysatoren
(„Observation point“, „Exporter“) konfiguriert, damit sie die im jeweiligen Netzwerk-
Element abgegriffene IP Flow Information für übergeordnete Kollektoren eines
Netzwerkmonitors („Netflow Collector“)
im Rahmen von Flow-Records zur
Verfügung stellen (vgl. E6, S.2, „Network elements (routers and switches) gather
flow data and export it to collectors.“ und S. 4, „Terminology“, dort insbesondere die
Ausführungen zu „Observation Point“, „Exporter“ und „NetFlow Collector“;
Merkmale A2 und A11).
Über die Selektion der dem Monitor zugeordneten Mehrzahl von Routern und
Switchen im Netzwerk, welche mit NetFlow ausgestattet werden, erhält der Monitor
eine Stückliste eines Medienpfads bzw. eines Kommunikationspfads (Merkmale
A3, A5, A6 teilweise).
Die Netzwerkanalysatoren werden vom Netzwerkmonitor konfiguriert, indem der
Monitor ein anspruchsgemäßes Konfigurationspaket umfassend ein „Template“
sendet, welches die Netzwerkanalysatoren – also die oben genannten, vom
Administrator ausgewählten Router und Switche im Netzwerk – veranlasst, ihren
Datenverkehr hinsichtlich der im Template definierten „Regeln“ zu überwachen,
wobei der Netzwerkanalysator die Pakete des Datenverkehrs anhand der Header-
Daten entsprechenden IP-Flows zuordnet, hinsichtlich von in Feld-Typen („field
types“) definierten Kriterien untersucht und entsprechende Paketinformationen in
einem Export-Paket aufnimmt, wobei somit der in den Paketen enthaltene
Kommunikationsstatus in Bezug auf den Netzwerkanalysator selbst überwacht wird
und der Netzwerkanalysator in der Stückliste enthalten ist (vgl. E6, S. 3, „templatebased approach“, S. 19, „field types“; Merkmale A7, A8 und A12, A13).
Der Export betrifft einen Kommunikationsstatus hinsichtlich des IP Flows am
jeweiligen Netzwerkanalysator u.a. hinsichtlich Startzeit, Endzeit, Zeitstempel für
die einzelnen Pakete des Flows, Anzahl der Pakete des Flows, Datenvolumen des
Flows, Protokoll-Typ, Quellen-Adresse, Ziel-Adresse (vgl. E6, S. 18 ff.: „Field Type
Definitions“).
Der Netzwerkanalysator sendet das Export-Paket, bei welchem es sich um ein
anspruchsgemäßes Antwortpaket umfassend den Kommunikationsstatus in Bezug
auf beispielsweise einen als Netzwerkanalysator konfigurierten Router oder Switch
handelt, zum Kollektor bzw. Netzwerkmonitor (vgl. E6, S. 4, „… the Exporter
monitors packets entering an Observation Point and creates Flows from these
packets. The information from these Flows is exported in the form of Flow Records
to the NetFlow Collector.“ und S.7, Abschnitt 3.3, 1. Absatz: „… the NetFlow Export
Packets are encapsulated into UDP [RFC768] datagrams for export to the NetFlow
Collector.“; Merkmale A9 und A14).
Der Netzwerkmonitor gibt den Kommunikationsstatus an den Administrator aus (vgl.
E6, S. 2 - 3, „provide network administrators with access to IP flow information from
their data networks.“ und „Exported NetFlow data is used for a variety of
purposes…network monitoring…“; Merkmal A10). Da NetFlow nach der Lehre der
Druckschrift E6 auf IPFIX gemäß Druckschrift E5 basiert, können hierbei die Export-
Daten unterschiedlicher Netzwerkanalysatoren zusätzlich in den Kollektoren einem
entsprechenden Post-Processing zugeführt, d.h. bspw. korreliert, werden, um bspw.
eine QoS-Überwachung des Flows zu ermöglichen (vgl. E5, S. 8, „QoS monitoring“).
Die Überwachung der Kommunikation mit NetFlow Version 9 gemäß der
Druckschrift E6 umfasst lediglich ein Erfassen und Analysieren von IP-Flüssen an
mehreren, dedizierten Punkten im Netzwerk, wobei eine spezielle Überwachung der
Signalisierung jedoch nicht adressiert wird (Merkmal A4 fehlt komplett und
Merkmal A6 teilweise).
NetFlow Version 9 eignet sich daher in für den Fachmann offensichtlicher Weise
nicht zum Überwachen einer VoIP-Kommunikation, da diese zunächst einen Aufbau
einer VoIP-Sitzung mittels SIP-Signalisierung über einen Signalisierungspfad an
einen SIP-Proxy im Netzwerk benötigt und anschließend einen RTP-Medienpfad für
die Nutzdaten verwendet.
Daher wurde gemäß der Druckschrift E21 die NetFlow Version 9 zur Überwachung
von VoIP durch zwei PlugIns für SIP-Metriken und RTP-Metriken ergänzt und ein
entsprechend konfigurierbarer Netzwerkanalysator „nProbe“ bereitgestellt (vgl. E21,
Table 1, S. 5 i.V.m. S. 6, „Note that these metrics can be exported only using
NetFlow v9 or IPFIX - supported by both nProbe and IPFIX - as previous NetFlow
version such as v5 have no room for carrying extra information. Instead v9/IPFIX
have the ability to define flow templates that dynamically define the flow format and
attributes.“, „nProbe implements VoIP support in two plugins, one for SIP and the
other for RTP. VoIP measurements are exported inside v9/IPFIX flows using custom
flow templates.“).
Zur Überwachung von VoIP wird insbesondere das SIP-Gateway (bzw. der SIP-
Proxy) mit einer
„nProbe“ versehen und somit
in eine Stückliste des
Signalisierungspfads aufgenommen, wobei die übrigen Netzwerkanalysatoren (also
Router, Switche, etc.) sowohl die Nutz- als auch Signalisierungsdaten überwachen
und somit in die Stücklisten von Signalisierungspfad und Medienpfad aufgenommen
werden (vgl. E21, S. 6, „ (cid:127) Time of important call events such as beginning of the
call. These times can be used to identify performance issues on the SIP gateway.
(cid:127) RTP ports where the call will take place. This information is necessary for
associating a signaling flow with the phone call just negotiated.“; Merkmale A4 und
A6).
Im Übrigen zeigt die E22 ebenso ein System für die Überwachung von VoIP-
Kommunikation mit einer Detektion von Netzwerkattacken basierend auf NetFlow
Version 9 und dem o.g. PlugIn für VoIP in „nProbe“ Netzwerkanalysatoren, wobei
die Netzwerkanalysatoren an multiplen Stellen im Netzwerk vorgesehen sind und
dort jeweils SIP/RTP Pakete unterscheiden können, d.h. auch in der E22 umfassen
sowohl die Stückliste des Medienpfads als auch diejenige des Signalisierungspfads
jeweils eine Mehrzahl von Elementen (vgl. E22, Fig. 2 – 4 i.V.m. Kapitel 4 und 5
sowie insbesondere S. 7, Tabelle 3, „SIP traffic heading to SIP proxy server“, „SIP
traffic at each user’s level“, „SIP traffic heading to registrar“; Merkmale A4 und A6).
Der Gegenstand des erteilten Patentanspruchs 1 ist daher jeweils aus der
Zusammenschau der E6 mit der E21 oder der E6 mit der E22 in sämtlichen
Merkmalen nahegelegt, wobei sich die Kombination der vorgenannten
Druckschriften für den Fachmann zwanglos ergibt, wenn er die NetFlow Version 9
zur Überwachung von VoIP durch die genannten PlugIns für SIP-Metriken und RTP-
Metriken ergänzt und einen entsprechend konfigurierbaren Netzwerkanalysator
„nProbe“ bereitstellt. Der Gegenstand des Patentanspruch 1 beruht somit nicht auf
einer erfinderischen Tätigkeit.
6.
Mit dem vorstehend genannten Patentanspruch 1 fallen auch alle anderen
Ansprüche, denn es ist mangels Antragstellung bzw. eines gegenteiligen
Vorbringens der Patentinhaberin im Beschwerdeverfahren davon auszugehen,
dass sie das Patent ausschließlich in der erteilten Fassung verteidigen möchte
(BGH, Beschluss vom 27.02.2008 - X ZB 10/07, GRUR-RR 2008, 456 Rn. 22
m. w. N. – Installiereinrichtung; BGH, Beschluss vom 27.06.2007 – X ZB 6/05,
GRUR 2007, 862 Leitsatz – Informationsübermittlungsverfahren II; BGH, Urteil vom
29.09.2011 - X ZR 109/08 1. Leitsatz – Sensoranordnung).
7.
Vor dem obigen Hintergrund kann dahinstehen, ob die von der
Einsprechenden geltend gemachten weiteren Widerrufsgründe der mangelnden
Ausführbarkeit bzw. der unzulässigen Erweiterung gemäß § 21 Abs. 1 Nr. 2 und Nr.
4 PatG hier ebenfalls durchgreifen würden.
8.
Im Ergebnis war somit das Patent 10 2010 014 254 – unter gleichzeitiger
Aufhebung des angefochtenen Beschlusses – in vollem Umfang zu widerrufen.
Rechtsmittelbelehrung
Gegen diesen Beschluss steht jedem am Beschwerdeverfahren Beteiligten, der durch diesen
Beschluss beschwert ist, die Rechtsbeschwerde zu (§ 99 Abs. 2, § 100 Abs. 1, § 101 Abs. 1 PatG).
Da der Senat in seinem Beschluss die Rechtsbeschwerde nicht zugelassen hat, ist sie nur statthaft, wenn gerügt wird, dass
1.
2.
3.
4.
das beschließende Gericht nicht vorschriftsmäßig besetzt war,
bei dem Beschluss ein Richter mitgewirkt hat, der von der Ausübung des Richteramtes
kraft Gesetzes ausgeschlossen oder wegen Besorgnis der Befangenheit mit Erfolg
abgelehnt war,
einem Beteiligten das rechtliche Gehör versagt war,
ein Beteiligter im Verfahren nicht nach Vorschrift des Gesetzes vertreten war, sofern er
nicht der Führung des Verfahrens ausdrücklich oder stillschweigend zugestimmt hat,
5.
der Beschluss auf Grund einer mündlichen Verhandlung ergangen ist, bei der die
Vorschriften über die Öffentlichkeit des Verfahrens verletzt worden sind, oder
6.
der Beschluss nicht mit Gründen versehen ist
Die Rechtsbeschwerde ist von einer beim Bundesgerichtshof zugelassenen Rechtsanwältin oder
von einem beim Bundesgerichtshof zugelassenen Rechtsanwalt innerhalb eines Monats nach
Zustellung dieses Beschlusses beim Bundesgerichtshof, Herrenstraße 45 a, 76133 Karlsruhe,
einzulegen (§ 102 Abs.1, Abs. 5 Satz 1 PatG).
Musiol
Dorn
Bieringer
Dr. Ball