4b O 33/20 – Rechensystem-Verfahren | Düsseldorfer Entscheidungen

Düsseldorfer Entscheidungen Nr. 3175

Landgericht Düsseldorf

Urteil vom 10. Dezember 2021, Az. 4b O 33/20

Die Klage wird abgewiesen.
Die Kosten des Rechtsstreits trägt die Klägerin.
Das Urteil ist vorläufig vollstreckbar gegen Sicherheitsleistung in Höhe von 110 % des jeweils zu vollstreckenden Betrages.
Tatbestand
Die Klägerin macht gegen die Beklagten als im Patentregister eingetragene Inhaberin (vgl. Registerauszug Stand 29. April 2020, Anlage A 4) auf die Verletzung des deutschen Teils des europäischen Patents 3 257 XXX B 1 (im Folgenden Klagepatent, Anlage A 2, in deutscher Übersetzung vorgelegt als Anlage A 3) gestützte Ansprüche auf Unterlassung, Auskunftserteilung, Rechnungslegung, Rückruf und Vernichtung sowie Feststellung der Schadensersatzpflicht dem Grunde nach geltend.
Die in englischer Verfahrenssprache verfasste Anmeldung des Klagepatents mit der Bezeichnung „Correlating packets in communications networks“ datiert vom 25. November 2015. Das Klagepatent nimmt eine Priorität vom 10. Februar 2015 (US 201514618XXX) in Anspruch. Die Offenlegung der Anmeldung erfolgte am 20. Dezember 2017, die Veröffentlichung des Hinweises auf die Patenterteilung datiert vom 13. März 2019.
Der Wortlaut der hier maßgeblichen Klagepatentansprüche 1 und 15 lautet wie folgt:
„1. A method comprising:
identifying (5, 402), by a computing system, a plurality of packets (P1, P2, P3) received by a network device (122) from a host (114) located in a first network (104);
generating (6, 404), by a computing system, a plurality of log entries (306, 308, 310) corresponding to the plurality of packets received by a network device;
identifying (8, 406), by the computing system, a plurality of packets (P1’, P2’, P3’) transmitted by the network decide to a host (108) located in a second network (102);
generating (9, 408), by the computing system, a plurality of log entries (312, 314, 316) corresponding to the plurality of packets transmitted by the network device;
correlating (16, 410), by the computing system and based on the plurality of log entries corresponding to the plurality of packets received by the network device and the plurality of log entries corresponding to the plurality of packets transmitted by the network device, the plurality of packets transmitted by the network device with the plurality of packets received by the network device; and
responsive to correlating the plurality of packets transmitted by the network device with the plurality of packets received by the network device:
generating (30), by the computing system, one or more rules (140) configured to identify packets received from the host located in the first network; and
provisioning (31, 32) a packet-filtering device (124, 126) with the one or more rules configured to identify packets received from the host located in the first network.”
“15.An apparatus configured to perform each step of the method of any one claims 1-14.”
und in deutscher Übersetzung:
„1. Verfahren, umfassend:
Identifizieren (5, 402), durch ein Rechensystem, einer Vielzahl von Paketen (P1, P2, P3), die durch eine Netzwerkvorrichtung (122) von einem Host (114) empfangen werden, der sich in einem ersten Netzwerk (104) befindet;
Erzeugen (6, 404), durch das Rechensystem, einer Vielzahl von Log-Einträgen (306, 308, 310), die der Vielzahl von Paketen entsprechen, die durch die Netzwerkvorrichtung empfangen werden;
Identifizieren (8, 406), durch das Rechensystem, einer Vielzahl von Paketen (P1‘, P2‘, P3‘), die durch die Netzwerkvorrichtung an einen Host (108) übertragen werden, der sich in einem zweiten Netzwerk (102) befindet;
Erzeugen (9, 408), durch das Rechensystem, einer Vielzahl von Log-Einträgen (312, 314, 316), die der Vielzahl von Paketen entsprechen, die durch die Netzwerkvorrichtung übertragen werden;
Korrelieren (16, 410), durch das Rechensystem und auf Grundlage der Vielzahl von Log-Einträgen, die der Vielzahl von Paketen entsprechen, die durch die Netzwerkvorrichtung empfangen werden, und der Vielzahl von Log-Einträgen, die der Vielzahl von Paketen entsprechen, die durch die Netzwerkvorrichtung übertragen werden, der Vielzahl von Paketen, die durch die Netzwerkvorrichtung übertragen werden, mit der Vielzahl von Paketen, die durch die Netzwerkvorrichtung empfangen werden; und als Reaktion auf das Korrelieren der Vielzahl von Paketen, die durch die Netzwerkvorrichtung übertragen werden, mit der Vielzahl von Paketen, die durch die Netzwerkvorrichtung empfangen werden:
Erzeugen (30), durch das Rechensystem, von einer oder mehreren Regeln (140), die konfiguriert sind, um Pakete zu identifizieren, die von dem Host empfangen werden, der sich in dem ersten Netzwerk befindet;
und
Bereitstellen (31, 32) einer Paketfiltervorrichtung (124, 126) mit der einen oder den mehreren Regeln, die konfiguriert sind, um Pakete zu identifizieren, die von dem Host empfangen werden, der sich in dem ersten Netzwerk befindet.“
„15. Vorrichtung, die konfiguriert ist, um jeden Schritt des Verfahrens nach einem der Ansprüche 1-14 durchzuführen.“
Die nachfolgenden Abbildungen veranschaulichen einige Merkmale der Erfindung beispielhaft. Figur 1 zeigt eine veranschaulichte Umgebung zum Korrelieren von Paketen in Kommunikationsnetzen:
Die Figuren 2A bis 2D zeigen eine veranschaulichte Ereignissequenz zum Korrelieren von Paketen in Kommunikationsnetzen:
Das Klagepatent steht in Kraft.
Gegen das Klagepatent ist beim Bundespatentgericht Nichtigkeitsklage erhoben worden, über die noch nicht entschieden worden ist.
Die Beklagte zu 1) ist die Muttergesellschaft der Beklagten zu 2) und vertreibt weltweit Hard- und Software auf dem Gebiet der Netzwerksicherheit und des Netzwerkmanagements wie beispielsweise Router, Switches und Firewalls jeweils mit zugehöriger Software. Die Beklagte zu 2) ist die deutsche Tochtergesellschaft der Beklagten zu 1) und ist Betreiberin der deutschsprachigen Internetpräsenz des Konzerns, die in Auszügen als Anlagen A 19, A 20 und A 25 vorliegt.
Mit ihrer Klage wendet sich die Klägerin gegen Angebot und Vertrieb von Kombinationen einzelner Hardware- und Software-Komponenten bestehend aus A der Serien B, C und D, der auf dem E installierten Software F sowie der über die Amazon Webservices (AWS) betriebenen cloud-basierten Anwendung G, die zusammen mit mindestens einem der folgenden Netzwerkgeräte angeboten und vertrieben werden:
H der Serien X, X und X, jeweils mit dem Betriebssystem I Version X oder höher,
J der Serie X, mit dem Betriebssystem I Version X oder höher,
K der Serie 1000 mit dem Betriebssystem I X oder höher,
L der Serien 1000 und 4000 mit dem Betriebssystem I X oder höher
(nachfolgend gemeinsam „angegriffene Ausführungsform“)
sowie hilfsweise gegen Angebot und Vertrieb einzelner Komponenten dieser Kombination, nämlich die Switches, Controller, Router und Flow Collektoren.
Die räumlich-funktionale Anordnung der angegriffenen Ausführungsform kann nachfolgender Abbildung entnommen werden (Anlage A 10, S. 10):
Der M wird vom Administrator über die Benutzeroberfläche einer N gesteuert. Die N steuert ihrerseits mehrere physische Ebenen, die mit den angegriffenen Routern, Switches und Wireless Controllern kommunizieren.
Die Betriebssoftware dieser Router, Switches und Wireless Controller verfügt über die „NetFlow“-Funktionalität. Die angegriffenen Router, Switches und Wireless Controller sammeln Informationen über die Datenpakete, die durch den betreffenden Router, Switch oder Wireless Controller fließen. Typischerweise werden dabei folgende Informationen gesammelt (Anlage A 11, Seite 3, Spalte „Inspect Packet“):
Auf Basis dieser Informationen erstellen die angegriffenen Router, Switches und Wireless Controller sogenannte „NetFlow Records“ bzw. „Flexible NetFlow Records (FNF)“. Ein solcher NetFlow Record kann beispielsweise wie folgt graphisch dargestellt werden (Anlage S 12, Figur 2, Anlage A 11, Seiten 3 und 4):
Der als Anlage A 13 vorgelegte Flexible Netflow Configuration Guide, O gibt verschiedene vordefinierte Aufzeichnungsformate für FNFs an wie folgt (Seite 46, 47):
Die NetFlow Records werden von dem betreffenden Router, Switch bzw. Wireless Controller an den „E“ (auch bezeichnet als „E“) typischerweise gebündelt gesendet. Der E erzeugt aus den NetFlowRecords sogenannte „P“ und sendet diese an die G. Dort werden die empfangenen und gesendeten Datenpakete einer Kommunikationsverbindung („Flow“) zugeordnet, wobei diese Zuordnung wie folgt veranschaulicht werden kann (Anlage A 13, Seite 3):
Die betreffende Kommunikation kann weiterhin als Bedrohung („Threat“) für das Netzwerk eingeordnet werden. Die hierzu in der G verfügbaren Informationen werden durch Auswertung zahlreicher Datenquellen unter Einsatz von „Machine Learning“ generiert. Anhand der ausgewerteten Daten erzeugt die G eine sogenannte „Threat Response“. Anhand verschiedener Bedrohungserkennungskriterien können Signale, bspw. Alarme und Warnungen ausgelöst werden.
Die Klägerin ist der Ansicht, bei der von den Beklagten vertriebenen angegriffenen Ausführungsform handele es sich um klagepatentgemäße Vorrichtungen, die das klagepatentgemäße Verfahren zum Korrelieren von Paketen in Kommunikationsnetzwerken nutzen.
Das Rechensystem sei funktional in den Prozessoren der angegriffenen Router, Switches und Wireless Controller, den Prozessoren des Es und der G verwirklicht.
Die von den angegriffenen Router, Switches und Wireless Controller erzeugten „Original NetFlow Records“ und „Flexible NetFlow Records (FNF)“ umfassten insbesondere die Felder „Interface Input“ und „Interface Output“. Das Feld „Interface Input“ enthalte Informationen aus der Schnittstelle des Netzwerkes, durch die Datenpakete empfangen werden, also Informationen zu den diese passierenden eingehenden Datenpaketen. Das Feld „Interface Output“ enthalte dagegen Informationen aus der Schnittstelle des Netzwerkgeräts, durch die Datenpakete vom Netzwerkgerät weitergesendet werden, also Informationen zu den diese passierenden ausgehenden Datenpaketen. Das Feld „Input Interface“ bezüglich des eingehenden Datenpakets werde in dem Log-Eintrag „Input Interface“ des FNF gespeichert. Das Feld „Output Interface“ bezüglich des ausgehenden Datenpakets werde in dem Log-Eintrag „Output Interface“ des FNF gespeichert. Durch das gemeinsame Speichern der beiden Log-Einträge in einem FNF würden die entsprechenden Paketflüsse auf Grundlage der Log-Einträge miteinander in Bezug gebracht, mithin korreliert.
Diese Log-Einträge würden dann von der G ausgewertet. Durch die Korrelation der Pakete zu einem Flow könne die G erkennen, wer mit wem kommuniziere, beispielsweise einen externen Kommunikationspartner als bösartigen Host erkennen und diese Kommunikation als Bedrohung für das Netzwerk einordnen. Über die Q und die mit dieser verbundenen R Systeme würden sodann in Reaktion automatisierte sicherheitsrelevante Entscheidungen getroffen. Dies sei den als Anlage A 14 bis A 18 in Kopie vorgelegten Dokumenten der Beklagten zu entnehmen. So könne die G in Reaktion auf die Ermittlung eines Flows mit einem bösartigen Host die Regel erstellen, diese Pakete nicht weiterzuleiten. Das Betriebssystem könne dann diejenigen Pakete identifizieren, die nicht weitergeleitet werden sollen und stelle somit eine Paketfilterfunktion bereit. Beispielsweise könne der Adminstrator über den „Incident Manager“ der angegriffenen Software auf eine erkannte und gemeldete Bedrohung einen „Incident“ erstellen. Dieser „Incident“ könne im Rahmen der „SecureX Threat Response and S Secure Firewall“ dem Betriebssystem der Firewall oder im Rahmen der „SecureX Threat Response and S Secure Endpoint“ unmittelbar an die Paketfiltervorrichtung bereitgestellt werden. Firewall bzw. Netzwerkvorrichtung setzten dann bestimmungsgemäß Regeln zur Paketfilterung ein und führten zum Beispiel eine Isolation des Hosts oder das Blockieren bestimmter Domains durch. Basierend auf den Alarmen aus der S Secure Firewall und S Secure Network Analytics könnten Vorgänge im System der Beklagten sogar automatisch ausgeführt werden.
Das System der Beklagten könne sogar ganze Regelsätze, sogenannte „Access Control Lists, ACL, wie der „GACL“, „VACL, „PACL“, „SACL und „RBACL“ bereitstellen, anhand welcher die Endgeräte insbesondere Pakete beim Ein- und Austritt aus Routern und Switches auf der Grundlage der jeweiligen Kennzeichnung blockierten oder zuließen.
Die Klägerin beantragt,
I.
die Beklagten zu verurteilen
1.
es bei Meldung eines für jeden Fall der Zuwiderhandlung vom Gericht festzusetzenden Ordnungsgeldes bis zu 500.000 EUR – ersatzweise Ordnungshaft – oder einer Ordnungshaft bis zu sechs Monaten, im Falle wiederholter Zuwiderhandlung bis zu insgesamt zwei Jahren, wobei die Ordnungshaft an dem Chairman & Chief Executive Officer der Beklagten zu 1) bzw. an dem Geschäftsführer der Beklagten zu 2) zu vollziehen ist, zu unterlassen,
a)
Vorrichtungen
in der Bundesrepublik Deutschland anzubieten, in Verkehr zu bringen und/oder zu gebrauchen, oder zu den genannten Zwecken einzuführen und/oder zu besitzen,
die konfiguriert sind, jeden Schritt eines Verfahrens durchzuführen, umfassend:
Identifizieren, durch ein Rechensystem, einer Vielzahl von Paketen, die durch eine Netzwerkvorrichtung von einem Host empfangen werden, der sich in einem ersten Netzwerk befindet;
Erzeugen, durch das Rechensystem, einer Vielzahl von Log-Einträgen, die der Vielzahl von Paketen entsprechen, die durch die Netzwerkvorrichtung empfangen werden;
Identifizieren, durch das Rechensystem, einer Vielzahl von Paketen, die durch die Netzwerkvorrichtung an einen Host übertragen werden, der sich in einem zweiten Netzwerk befindet;
Erzeugen, durch das Rechensystem, einer Vielzahl von Log-Einträgen, die der Vielzahl von Paketen entsprechen, die durch die Netzwerkvorrichtung übertragen werden;
Korrelieren, durch das Rechensystem und auf Grundlage der Vielzahl von Log- Einträgen, die der Vielzahl von Paketen entsprechen, die durch die Netzwerkvorrichtung empfangen werden und der Vielzahl von Log-Einträgen, die der Vielzahl von Paketen entsprechen, die durch die Netzwerkvorrichtung übertragen werden, der Vielzahl von Paketen, die durch die Netzwerkvorrichtung übertragen werden mit der Vielzahl von Paketen, die durch die Netzwerkvorrichtung empfangen werden; und
als Reaktion auf das Korrelieren der Vielzahl von Paketen, die durch die Netzwerkvorrichtung übertragen werden, mit der Vielzahl von Paketen, die durch die Netzwerkvorrichtung empfangen werden:
Erzeugen, durch das Rechensystem, von einer oder mehreren Regeln, die konfiguriert sind, um Pakete zu identifizieren, die von dem Host empfangen werden, der sich in dem ersten Netzwerk befindet; und
Bereitstellung der einen oder den mehreren Regeln an eine Paketfiltervorrichtung, die konfiguriert sind, um Pakete zu identifizieren, die von dem Host empfangen werden, der sich in dem ersten Netzwerk befindet;
hilfsweise:
Switches, Router oder Controller, die geeignet sind, in Verbindung mit einem E und einer virtuellen Maschine und der dazugehörigen Software eine Vorrichtung darzustellen, die konfiguriert ist, jeden Schritt eines Verfahrens durchzuführen bzw. Flow-Collectoren, die geeignet sind, in Verbindung mit Switches, Routern oder Controllern und einer virtuellen Maschine und der dazugehörigen Software eine Vorrichtung darzustellen, die konfiguriert ist, jeden Schritt eines Verfahrens durchzuführen,
umfassend:
Identifizieren, durch ein Rechensystem, einer Vielzahl von Paketen, die durch eine Netzwerkvorrichtung von einem Host empfangen werden, der sich in einem ersten Netzwerk befindet;
Erzeugen, durch das Rechensystem, einer Vielzahl von Log-Einträgen, die der Vielzahl von Paketen entsprechen, die durch die Netzwerkvorrichtung empfangen werden;
Identifizieren, durch das Rechensystem, einer Vielzahl von Paketen, die durch die Netzwerkvorrichtung an einen Host übertragen werden, der sich in einem zweiten Netzwerk befindet;
Erzeugen, durch das Rechensystem, einer Vielzahl von Log-Einträgen, die der Vielzahl von Paketen entsprechen, die durch die Netzwerkvorrichtung übertragen werden;
Korrelieren, durch das Rechensystem und auf Grundlage der Vielzahl von Log- Einträgen, die der Vielzahl von Paketen entsprechen, die durch die Netzwerkvorrichtung empfangen werden und der Vielzahl von Log-Einträgen, die der Vielzahl von Paketen entsprechen, die durch die Netzwerkvorrichtung übertragen werden, der Vielzahl von Paketen, die durch die Netzwerkvorrichtung übertragen werden mit der Vielzahl von Paketen, die durch die Netzwerkvorrichtung empfangen werden; und
als Reaktion auf das Korrelieren der Vielzahl von Paketen, die durch die Netzwerkvorrichtung übertragen werden, mit der Vielzahl von Paketen, die durch die Netzwerkvorrichtung empfangen werden:
Erzeugen, durch das Rechensystem, von einer oder mehreren Regeln, die konfiguriert sind, um Pakete zu identifizieren, die von dem Host empfangen werden, der sich in dem ersten Netzwerk befindet; und
Bereitstellung der einen oder den mehreren Regeln an eine Paketfiltervorrichtung, die konfiguriert sind, um Pakete zu identifizieren, die von dem Host empfangen werden, der sich in dem ersten Netzwerk befindet,
Abnehmern im Gebiet der Bundesrepublik Deutschland anzubieten und/oder an solche zu liefern, ohne
– im Falle des Anbietens im Angebot ausdrücklich und unübersehbar darauf hinzuweisen, dass die Switches, Router, Controller, Een, virtuelle Maschinen und Software nicht ohne Zustimmung des Klägers als Inhaber des deutschen Teil des Europäischen Patents EP 3 257 XXX mit einer Vorrichtung verwendet werden dürfen, welche konfiguriert ist, um das oben genannte Verfahren auszuführen;
– im Falle der Lieferung den Abnehmern unter Auferlegung einer an den Patentinhaber zu zahlenden Vertragsstrafe von 100.000,00 Euro pro Gerät, mindestens jedoch 500.000,00 Euro für jeden Fall der Zuwiderhandlung, die schriftliche Verpflichtung aufzuerlegen, die Geräte und/oder Software nicht ohne Zustimmung des Patentinhabers für Vorrichtungen zu verwenden, welche konfiguriert sind, um das oben genannte Verfahren auszuführen;
b)
Switches, Router oder Controller jeweils gemeinsam mit Een und virtuellen Maschinen und der jeweiligen Software
welche geeignet sind, ein Verfahren auszuführen, umfassend:
Identifizieren, durch ein Rechensystem, einer Vielzahl von Paketen, die durch eine Netzwerkvorrichtung von einem Host empfangen werden, der sich in einem ersten Netzwerk befindet;
Erzeugen, durch das Rechensystem, einer Vielzahl von Log-Einträgen, die der Vielzahl von Paketen entsprechen, die durch die Netzwerkvorrichtung empfangen werden;
Identifizieren, durch das Rechensystem, einer Vielzahl von Paketen, die durch die Netzwerkvorrichtung an einen Host übertragen werden, der sich in einem zweiten Netzwerk befindet;
Erzeugen, durch das Rechensystem, einer Vielzahl von Log-Einträgen, die der Vielzahl von Paketen entsprechen, die durch die Netzwerkvorrichtung übertragen werden;
Korrelieren, durch das Rechensystem und auf Grundlage der Vielzahl von Log- Einträgen, die der Vielzahl von Paketen entsprechen, die durch die Netzwerkvorrichtung empfangen werden und der Vielzahl von Log-Einträgen, die der Vielzahl von Paketen entsprechen, die durch die Netzwerkvorrichtung übertragen werden, der Vielzahl von Paketen, die durch die Netzwerkvorrichtung übertragen werden mit der Vielzahl von Paketen, die durch die Netzwerkvorrichtung empfangen werden; und
als Reaktion auf das Korrelieren der Vielzahl von Paketen, die durch die Netzwerkvorrichtung übertragen werden, mit der Vielzahl von Paketen, die durch die Netzwerkvorrichtung empfangen werden:
Erzeugen, durch das Rechensystem, von einer oder mehreren Regeln, die konfiguriert sind, um Pakete zu identifizieren, die von dem Host empfangen werden, der sich in dem ersten Netzwerk befindet; und
Bereitstellung der einen oder den mehreren Regeln an eine Paketfiltervorrichtung, die konfiguriert sind, um Pakete zu identifizieren, die von dem Host empfangen werden, der sich in dem ersten Netzwerk befindet,
Abnehmern im Gebiet der Bundesrepublik Deutschland anzubieten und/oder an solche zu liefern, ohne
– im Falle des Anbietens im Angebot ausdrücklich und unübersehbar darauf hinzuweisen, dass die Switches, Router, Controller, Een, virtuelle Maschinen und Software nicht ohne Zustimmung des Klägers als Inhaber des deutschen Teil des Europäischen Patents EP 3 257 XXX mit einer Vorrichtung verwendet werden dürfen, welche konfiguriert ist, um das oben genannte Verfahren auszuführen;
– im Falle der Lieferung den Abnehmern unter Auferlegung einer an den Patentinhaber zu zahlenden Vertragsstrafe von 100.000,00 Euro pro Gerät oder Softwarelizenz, mindestens jedoch 500.000,00 Euro für jeden Fall der Zuwiderhandlung, die schriftliche Verpflichtung aufzuerlegen, die Geräte und/oder Software nicht ohne Zustimmung des Patentinhabers für Vorrichtungen zu verwenden, welche konfiguriert sind, um das oben genannte Verfahren auszuführen;
2.
der Klägerin darüber Auskunft zu erteilen, in welchem Umfang sie seit dem 13.04.2019 die unter Ziffer I.1. bezeichneten Handlungen begangen haben und zwar unter Angabe
a) der Namen und Anschriften der Hersteller, Lieferanten und anderer Vorbesitzer,
b) der Namen und Anschriften der gewerblichen Abnehmer sowie der Verkaufsstellen, für die die Erzeugnisse bestimmt waren,
c) der Menge ausgelieferten, erhaltenen oder bestellten Erzeugnisse sowie der Preise, die für die betreffenden Erzeugnisse bezahlt wurden,
wobei zum Nachweis der Angaben die entsprechenden Kaufbelege (nämlich Rechnungen, hilfsweise Lieferscheine) in Kopie vorzulegen sind, wobei geheimhaltungsbedürftige Details außerhalb der auskunftspflichtigen Daten geschwärzt werden dürfen;
3.
der Klägerin darüber Rechnung zu legen, in welchem Umfang sie die unter Ziffer I.1. bezeichneten Handlungen seit dem 13.04.2019 begangen haben, und zwar unter Angabe:
a) der einzelnen Lieferungen, aufgeschlüsselt nach Liefermengen, -zeiten, -preisen und Typenbezeichnungen sowie den Namen und Anschriften der Abnehmer,
b) der einzelnen Angebote, aufgeschlüsselt nach Angebotsmengen, -zeiten, -preisen und Typenbezeichnungen sowie den Namen und Adressen der gewerblichen Angebotsempfänger,
c) der betriebenen Werbung, aufgeschlüsselt nach Werbeträgern, deren Auflagenhöhe, Verbreitungszeitraum und Verbreitungsgebiet,
d) der nach den einzelnen Kostenfaktoren aufgeschlüsselten Gestehungskosten und des erzielten Gewinns,
wobei es der Beklagten vorbehalten bleibt, die Namen und Anschriften der nichtgewerblichen Abnehmer und der Angebotsempfänger statt der Klägerin einem von der Klägerin bezeichneten, ihr zur Verschwiegenheit verpflichtetet, in der Bundesrepublik Deutschland ansässigen, vereidigten Wirtschaftsprüfer mitzuteilen, sofern die Beklagten dessen Kosten tragen und ihn ermächtigen und verpflichten, der Klägerin auf konkrete Anfrage mitzuteilen, ob ein bestimmter Abnehmer oder Angebotsempfänger in der Aufstellung enthalten ist;
4.
nur gerichtet gegen die Beklagte zu 2): die in ihrem unmittelbaren oder mittelbaren Besitz oder in ihrem Eigentum befindlichen unter Ziffer l.1.a) bezeichneten Erzeugnisse nach ihrer Wahl zu vernichten oder an einen von der Klägerin zu benennenden Gerichtsvollzieher zum Zwecke der Vernichtung auf Kosten der Beklagten zu 2) herauszugeben;
5.
die unter Ziffer l.1.a) bezeichneten in Verkehr gebrachten Erzeugnisse gegenüber gewerblichen Abnehmern unter Hinweis auf den gerichtlich festgestellten patentverletzenden Zustand der Sache und mit der verbindlichen Zusage zurückzurufen, etwaige Entgelte zu erstatten sowie notwendige Zoll- und Lagerkosten zu übernehmen und die Erzeugnisse wieder an sich zu nehmen;
II.
festzustellen, dass die Beklagten verpflichtet sind, der Klägerin allen Schaden zu ersetzen, der ihr durch die unter Ziffer l.1. bezeichneten, seit dem 13.04.2019 begangenen Handlungen entstanden ist und noch entstehen wird.
Die Beklagten beantragen,
die Klage abzuweisen,
hilfsweise
den Rechtsstreit bis zur rechtskräftigen Entscheidung im Nichtigkeitsverfahren (Az. 5 Ni 50/XX (EP)) gegen den deutschen Teil des EP 3 257 XXX auszusetzen.
Die Beklagten sind der Ansicht, sie würden das klagepatentgemäß geschützte Verfahren nicht zur Anwendung bringen, auch machten die angegriffenen Ausführungsformen von der Lehre des Klagepatents keinen Gebrauch.
Das Klagepatent verlange, dass von der Netzwerkvorrichtung in undirektionaler Richtung empfangene und übertragene Datenpakete identifiziert würden und die erzeugten Log-Einträge den Datenpaketen entsprechen müssten. Die von der angegriffenen Ausführungsform genutzten Flexible Netflow Records ermöglichten hingegen keine Eins-zu-Eins-Zuordnung von identifiziertem Datenpaket und erzeugtem Log-Eintrag. Ein Flexible Netflow Record stelle nur einen Log-Eintrag für einen ganzen Datenfluss, mithin eine Vielzahl von Datenpaketen dar. Dazu würden mehrere Datenpakete mit identischen Headerinformationen gebündelt erfasst und ein Record für einen Fluss erstellt. Dies erfolge nur dann, wenn bestimmt werde, dass ein neuer Fluss im Cache erstellt werden müsse.
Weiterhin finde bei der angegriffenen Ausführungsform ein Korrelieren im Sinne des Klagepatents nicht statt. An die T würden keine NetFlow Records sondern lediglich aggregierte P gesendet. Diese P seien nicht detailliert genug, dass G anhand dieser feststellen könne, dass ein von den angegriffenen Hardwarekomponenten empfangenes Paket dasselbe sei, das von den angegriffenen Hardwarekomponenten übertragen werde. Vielmehr enthielten die P nur aggregierte Informationen über den Datenfluss zwischen zwei Hosts als Ganzes und keine differenzierten Informationen über Pakete auf einzelnen Segmenten von einem oder mehreren angegriffenen Hardwarekomponenten.
Bei der Erstellung der Flexible NetFlow Records finde ebenfalls kein Korrelieren im Sinne des Klagepatents statt. Durch das bloße Abspeichern von Informationen wie input interface und output interface würden Datenpakete nicht in Bezug gebracht.
Bei der angegriffenen Ausführungsform erfolge kein Erstellen einer Regel in Reaktion auf das Korrelieren der Vielzahl von empfangenen Datenpaketen mit der Vielzahl von übertragenen Datenpaketen im Sinne des Klagepatents. Vielmehr sende G ein Alarmsignal zur bloßen Anzeige an den Administrator (Q), aufgrund des Ermittelns einer Bedrohung. Hierbei handele es sich nicht um eine erzeugte Regel, sondern um bereits vor der Korrelation feststehende Bedrohungserkennungskriterien.
Schließlich würden keine Regeln an die Hardwarekomponenten gesendet. Denn es bestehe keine Rückverbindung zwischen der cloud-basierten G an die Hardwarekomponenten. Vielmehr sende G ein Alarmsignal zur bloßen Anzeige an den Administrator (Q), wenn eine Bedrohung erkannt werde.
Der E, der mit dem R Management Center verbunden sei, stelle keine Paketfiltervorrichtung im Sinne des Klagepatents dar. Denn dieser könne nicht auf Datenpakete einwirken und diese somit auch nicht identifizieren und bei Bedarf filtern.
Wegen der weiteren Einzelheiten des Sach- und Streitstandes wird auf die zwischen den Parteien gewechselten Schriftsätze und auf die zu den Akten gereichten Unterlagen Bezug genommen.
Entscheidungsgründe
Die zulässige Klage ist nicht begründet.
Der Klägerin stehen die geltend gemachten Ansprüche auf Unterlassen, Auskunft und Rechnungslegung, Rückruf und Vernichtung sowie Feststellung einer Schadensersatzpflicht dem Grunde nach gemäß Art. 64 Abs. 1 EPÜ i. V. m. § 139 Abs. 1 und 2, § 140a Abs. 1 und 3, § 140b Abs. 1 und 3 PatG, §§ 242, 259 BGB nicht zu (dazu unter Ziffer II).
I.
Die Erfindung des Klagepatents betrifft das Korrelieren von Paketen in Kommunikationsnetzen.
Zum Hintergrund der Erfindung führt das Klagepatent einleitend aus, dass Kommunikationen zwischen Endpunkten von paketvermittelten Netzwerken als Flüsse von zugehörigen Paketen charakterisiert werden könnten (Abs. [0002] des Klagepatents; nachfolgend sind Abschnitte ohne Bezeichnung solche des Klagepatents). Ein bestimmter Fluss könne Pakete beinhalten, die Informationen enthielten (z.B. innerhalb von Headern der Pakete), die Pakete von Paketen unterschieden, die anderen Flüssen zugeordnet seien. Zwischen Endpunkten angeordnete Netzwerkvorrichtungen könnten Pakete ändern, die einem Fluss zugeordnet sind, und dadurch möglicherweise den Fluss verschleiern, dem ein bestimmtes Paket von anderen Netzwerkvorrichtungen zugeordnet ist. Dementsprechend bestehe Bedarf an der Korrelation von Paketen in Kommunikationsnetzen.
Aus der US 2014/281XXX sei eine Ende-zu-Ende-Überwachung des virtuellen Netzwerkflusses in einem virtuellen Rechenzentrum bekannt, bei der den Benutzern basierend auf der Benutzerrolle unterschiedliche Ansichten bereitgestellt werden. Ein Zielflussmuster, das Datenpakete, die von Interesse sind, beschreibt, werde an eine Vielzahl von Anwendungen verteilt, die VMs in dem virtuellen Datenzentrum verwalten, wie etwa Hosts, virtuelle Gateways und andere virtuelle Netzwerkanwendungen. Jede der Anwendungen überwache Datenpakete, die von der Anwendung geroutet werden, indem sie die Datenpakete mit dem Flussmuster vergleicht und selektiv Kontextdaten sammelt, die die Datenpakete beschreiben. Die von den Anwendungen gesammelten Kontextdaten würden auf einem Remote-Server zur Analyse und Berichterstattung aggregiert.
Weiter offenbare die US 2004/073XXX ein Netzwerküberwachungssystem mit einer Speicherschaltung zum Speichern von Netzwerkpaketinformationen, wobei die Netzwerkpaketinformation einen vorhergesagten Identifikator enthalte. Das Netzwerküberwachungssystem umfasse auch mindestens eine Überwachungsschaltung, die mit einem Netzwerk verbunden sei und entlang dem Netzwerkverkehr in Form von Paketen fließe. Die mindestens eine Überwachungsschaltung sei, so das Klagepatent, programmiert, um die Schritte des Empfangens eines über das Netzwerk übertragenen Pakets und des Bestimmens, ob das empfangene Pakte zwischen einer Quelle und einem Ziel in einem ersten Satz von Netzwerkknoten kommuniziert werde, durchzuführen. Dabei enthalte jedes Paket in einer Sequenz von Kommunikationen zwischen der Quelle und dem Ziel einen Paket-Identifikator, der das Paket eindeutig von allen anderen Kommunikationen in einem Fluss zwischen der Quelle und dem Ziel identifiziere. Die mindestens eine Überwachungsschaltung sei so programmiert, das sie als Reaktion auf das Bestimmen, dass das empfangene Paket zwischen einer Quelle und einem Ziel in der ersten Gruppe der Netzwerkknoten kommuniziert werde, den Schritt des Vergleiches des Paket-Identifikators des empfangenen Pakets mit dem vorhergesagten Identifikator durchführt, um eine Identifikationsabweichung zwischen dem Paket-Identifikator und dem vorhergesagten Identifikator zu bestimmen zur Identifikation einer Unregelmäßigkeit im Netzwerkverkehr.
Das Klagepatent hat es sich vor diesem Hintergrund zur Aufgabe gemacht, ein Verfahren und eine Vorrichtung zur Verfügung zu stellen, um Pakete, deren Zuordnung zu einem Datenfluss verschleiert ist, zu identifizieren.
Dies soll durch die unabhängigen Klagepatentansprüche 1 und 15 erreicht werden, deren Merkmale wie folgt gegliedert werden können:
1. Verfahren, umfassend:
2. Identifizieren (5, 402) einer Vielzahl von Paketen (P1, P2, P3) durch ein Rechensystem,
2.1 die Pakete werden durch eine Netzwerkvorrichtung (122) von einem Host empfangen,
2.2 der sich in einem ersten Netzwerk (104) befindet;
3. Erzeugen (6, 404) einer Vielzahl von Log-Einträgen (306, 308, 310) durch das Rechensystem,
3.1 die Log-Einträge entsprechen der Vielzahl von Paketen, die durch die Netzwerkvorrichtung empfangen werden;
4. Identifizieren (8, 406) einer Vielzahl von Paketen (P1‘, P2‘, P3‘) durch das Rechensystem,
4.1 die Pakete werden durch die Netzwerkvorrichtung an einen Host (108) übertragen,
4.2 der sich in einem zweiten Netzwerk (102) befindet;
5. Erzeugen (9, 408) einer Vielzahl von Log-Einträgen (312, 314, 316) durch das Rechensystem,
5.1 die Log-Einträge entsprechen der Vielzahl von Paketen
5.2 die durch die Netzwerkvorrichtung übertragen werden;
6. Korrelieren (16, 410)
6.1 der Vielzahl von Paketen, die durch die Netzwerkvorrichtung übertragen werden, mit der Vielzahl von Paketen, die durch die Netzwerkvorrichtung empfangen werden,
6.2 durch das Rechensystem,
6.3 auf der Grundlage
6.3.1 der Vielzahl von Log-Einträgen, die der Vielzahl von Paketen entsprechen, die durch die Netzwerkvorrichtung empfangen werden, und
6.3.2 der Vielzahl von Log-Einträgen, die der Vielzahl von Paketen entsprechen, die durch die Netzwerkvorrichtung übertragen werden, und
7. Erzeugen (30) von einer oder mehreren Regeln (140) durch das Rechensystem,
7.1 die Regeln sind konfiguriert, um Pakete zu identifizieren, die von dem Host empfangen werden, der sich im ersten Netzwerk befindet; und
8. Bereitstellen (31, 32) einer Paketfiltervorrichtung (124, 126) mit der einen oder den mehreren Regeln,
8.1 die Regeln sind konfiguriert, um Pakete zu identifizieren, die von dem Host empfangen werden, der sich in dem ersten Netzwerk befindet;
9. das Erzeugen und Bereitstellen [erfolgt] als Reaktion auf das Korrelieren einer Vielzahl von Paketen, die durch die Netzwerkvorrichtung übertragen werden, mit der Vielzahl von Paketen, die durch die Netzwerkvorrichtung empfangen werden.
Das Klagepatent sieht in dem unabhängigen Vorrichtungsanspruch 15 weiter eine Vorrichtung vor, die konfiguriert ist, um jeden Schritt des Verfahrens mit den Merkmalen des Anspruchs 1 durchzuführen.
Nach der Erfindung kann ein Rechensystem von einer Netzwerkvorrichtung empfangene Pakete von einem Host, der sich in einem ersten Netzwerk befindet, identifizieren (Abs. [0006]). Das Rechensystem kann sodann Log-Einträge erzeugen, die den von der Netzwerkvorrichtung empfangenen Paketen entsprechen. Zudem kann das Rechensystem Pakete identifizieren, die von der Netzwerkvorrichtung an einen Host übertragen werden, der sich in einem zweiten Netzwerk befindet. Das Rechensystem kann wiederum Log-Einträge erzeugen, die den von der Netzwerkvorrichtung übertragenen Paketen entsprechen. Unter Verwendung der Log-Einträge, die den von der Netzwerkvorrichtung empfangenen Paketen entsprechen, und der Log-Einträge, die den von der Netzwerkvorrichtung übertragenen Paketen entsprechen, kann das Rechensystem die von der Netzwerkvorrichtung gesendeten Pakete mit den von der Netzwerkvorrichtung empfangenen Paketen korrelieren. Durch das Korrelieren der von der Netzwerkvorrichtung gesendeten Pakete mit den von der Netzwerkvorrichtung empfangenen Pakete kann das Rechensystem bestimmen, ob die von der Netzwerkvorrichtung gesendeten Pakete einem Datenfluss zugeordnet sind, auch wenn die Netzwerkvorrichtung die Pakete in einer Weise ändert, die ihre Zuordnung zu einem Datenfluss vom Rechensystem verschleiert (Abs. [0007]).
II.
Vor dem Hintergrund des Streites der Parteien bedarf es einer Auslegung der Merkmalsgruppen 2 bis 5 sowie der Merkmale 6 und 9.
1.
Das Identifizieren von Paketen und das Erzeugen von Log-Einträgen erfolgen nach den Merkmalsgruppen 2 bis 5 sowohl in Bezug auf Datenpakete, die von einer Netzwerkvorrichtung empfangen werden (eingehende Datenpakete) als auch in Bezug auf Datenpakete, die von der Netzwerkvorrichtung gesendet werden (ausgehende Datenpakete). Damit geben diese Merkmale vor, dass es für empfangene und gesendete Datenpakete unterscheidbare Log-Einträge geben muss, die Grundlage für das Korrelieren sind (Merkmal 6, siehe hierzu nachfolgend Ziffer 2.).
a)
Nach dem gemäß Artikel 69 Abs. 1 Satz 1 EPÜ für die Anspruchsauslegung maßgeblichen Wortlaut der Merkmale 2.1. und 4.1. empfängt bzw. überträgt die Netzwerkvorrichtung die Datenpakete und ist mithin entlang der Flussrichtung des Paketdatenstroms zu verorten. Aus dem so in Bezug genommenen Anspruchswortlaut „die Netzwerkvorrichtung“ folgt noch nicht zwingend, dass die Vorrichtung auch mehrere Geräte umfassen kann. Allerdings legt der Wortlaut durch die Verwendung der Artikel „eine“ in Merkmal 2.1. und – darauf bezogen – „die“ in Merkmal 4.1. nicht fest, dass die klagepatentgemäße Netzwerkvorrichtung zwingend nur ein Einzelgerät umfassen darf.
Ziel der Auslegung ist nicht ein bloß philologisches Verständnis. Zu ermitteln ist vielmehr der technische Sinngehalt des Patentanspruchs. Aus der Beschreibung und den Zeichnungen, die gemäß Artikel 69 Abs. 1 Satz 2 EPÜ zur Auslegung heranzuziehen sind, kann sich ergeben, dass die Patentschrift Begriffe eigenständig definiert und insoweit ein patenteigenes Lexikon darstellt (BGH GRUR 2021, 942 Rn. 22 – Anhängerkupplung II; BGH GRUR 1999, 909 – Spannschraube; BGH, GRUR 2015, 875 Rn. 16 – Rotorelemente).
Nach diesen Grundsätzen ist der Begriff „eine“ bzw. „die“ im Sinne des Merkmals 2.1. bzw. 4.1. nicht als zahlenmäßige Angabe zu verstehen, sondern als unbestimmter bzw. bestimmter Artikel. Dieses Verständnis wird gestützt durch die für die Auslegung heranzuziehende Beschreibung des Klagepatents in Abschnitt [0041], wonach
„Netzwerkvorrichtung(en) 122 jedoch ein oder mehrere Geräte enthalten […]“
b)
Nach den Merkmalen 3.1. und 5.1. ist zwischen Log-Einträgen zu unterscheiden, die die von der Netzwerkvorrichtung empfangenen Datenpakete und solche, die die von der Netzwerkvorrichtung übertragenen Datenpakete betreffen. Der jeweilige Log-Eintrag wird dabei für ein oder mehrere empfangene oder gesendete Datenpakete erzeugt.
Dem Teilmerkmal
„die Log-Einträge entsprechen der Vielzahl von Paketen“
ist ein Verständnis dahingehend zu entnehmen, dass eine Zuordnung der Log-Einträge zu den Paketen erfolgt, wobei diese Zuordnung nicht zwingend dadurch gegeben sein muss, dass für jedes einzelne Paket ein Log-Eintrag tatsächlich erzeugt wird und dadurch eine Eins-zu-Eins-Zuordnung besteht. Die Erstellung von kumulierten oder aggregierten Log-Einträgen für mehrere Pakete ist aufgrund des Wortlauts „entsprechen“ ebenfalls umfasst.
Dieses Verständnis wird weiter gestärkt, wenn die Funktion der Log-Einträge im Rahmen des klagepatentgemäßen Verfahrens in den Blick genommen wird. Die Log-Einträge bilden die Grundlage für den in Merkmal 6 beschriebenen Verfahrensschritt der Korrelation der empfangenen und gesendeten Datenpakete, die eine Eins-zu-Eins-Zuordnung von Log-Eintrag und Datenpaket nicht zwingend erfordert. Die Patentschrift formuliert den technischen Erfolg der Erfindung zunächst in Abschnitt [0007] vielmehr dahin, dass
„Das Korrelieren der von der Netzwerkvorrichtung gesendeten Pakete mit den von der Netzwerkvorrichtung empfangenen Pakete […] es dem Rechensystem ermöglichen [kann], zu bestimmen, ob die von der Netzwerkvorrichtung gesendeten Pakete dem/den Flow(s) zugeordnet sind.“
Einer Eins-zu-Eins- Zuordnung bedarf es dafür nicht; es genügen unterscheidbar vorliegende Log-Einträge. So wäre es auch denkbar, eine Vielzahl von Paketen mit bestimmten identischen Headerdaten zu einem Log-Eintrag zusammenzufassen und im Wege der Korrelation mit anderen, ähnlich aggregierten Log-Einträgen einem bestimmten Flow zuzuordnen.
Dabei ist zu berücksichtigen, dass der Zweck, mittels einer Korrelation von Datenpaketen auf Grundlage der Log-Einträge die Zuordnung von Datenpaketen zu bestimmten Flows zu ermöglichen, in keinem der Klagepatentansprüche angesprochen ist, sondern erst Gegenstand der Unteransprüche 10 und 11 bzw. bevorzugter Ausführungsformen in den Abschnitten [0041] ff. und [0052] ist. Damit genügt aber jedes Korrelieren von Datenpaketen, selbst wenn es kein Zuordnung von Datenpaketen zu einem bestimmten Flow ermöglicht. Für die Log-Einträge ergibt sich daraus noch weniger, dass ihnen einen Eins-zu-Eins-Zuordnung zu einzelnen Paketen zugrunde liegen muss.
2.
Nach Merkmal 6 erfolgt das Korrelieren der übertragenen mit den empfangenen Datenpaketen auf Grundlage der Log-Einträge. Unter dem Korrelieren von Datenpaketen ist ein Vergleich zu verstehen mit dem Ziel, aus dem Zusammenhang oder dem Verhältnis der empfangenen und übertragenen Datenpakete eine – wenn auch nur statistische – Aussage über die Datenpakete ableiten zu können. Dabei werden die Datenpakete nicht unmittelbar selbst miteinander verglichen, sondern der Vergleich erfolgt auf der Grundlage der zuvor erzeugten Log-Einträge, also bestimmter Daten aus den oder über die empfangenen und übertragenen Datenpakete. Da der Anspruch ein Korrelieren von übertragenen Paketen mit empfangenen Paketen vorgibt, muss sich infolgedessen auch der Vergleich und insbesondere die daraus gewonnene Erkenntnis auf das Verhältnis von übertragenen zu empfangenen Paketen beziehen.
Ausschlaggebend für dieses Verständnis sind der Wortlaut des Anspruchs und der Begriff des Korrelierens in seiner allgemeinen Form. Insofern ist zu berücksichtigen, dass der Wortlaut des Merkmals weder eine Zweckrichtung für das Korrelieren noch eine Eignung vorgibt. Insbesondere stellt der Wortlaut nicht darauf ab, eine Zuordnung zu einem Datenfluss zu ermöglichen oder eine Verschleierung von Datenpaketen zu erkennen (siehe oben unter Ziffer 1.).
Auch aus der Beschreibung des Klagepatents folgt ein solches Verständnis nicht- Insoweit sind besondere Ausführungsformen nur beispielhaft beschrieben und haben keinen Eingang in den hier streitgegenständlichen Anspruchswortlaut gefunden: Aus den Abschnitten [0019] bis [0021] folgt, wie die Zuordnung eines Datenpakets zu einem Flow verschleiert werden kann. Eine Möglichkeit, wie die empfangenen und übertragenen Datenpakete verglichen werden können, wird in den Abschnitten [0034] bis [0036] beschrieben. Wie der Vorgang des Korrelierens durchgeführt werden kann, erläutert Abschnitt [0046]
„indem bestimmt wird, dass die Daten der Anfrage(n) in den Paket(en) enthalten sind, die von den Netzwerkvorrichtung(en) 122 übertragen werden, den Daten der Anfragen entsprechen, die in den Paket(en) enthalten sind, die von den Netzwerkvorrichtung(en) 122 empfangen werden (z.B. wenn die Netzwerkvorrichtung(en) 122 einen Proxy beinhalten).
3.
Nach Merkmal 9 werden in Reaktion auf das Korrelieren Regeln erzeugt, die an die Paketfiltervorrichtung bereitgestellt werden und konfiguriert sind, um von einem Host empfangene Pakete zu identifizieren.
a)
Der Begriff der „Regel“ („rule“) im Sinne des Merkmals 9 beschreibt eine allgemeine Programmanweisung, die an die Paketfiltervorrichtung gerichtet ist und von dieser verarbeitet wird (vgl. Merkmal 8). Von dieser Regel unterscheidet das Klagepatent die Nachricht („message“), die das Rechensystem erzeugen kann und bei der es sich allgemein um Mitteilungen an andere Einheiten im Netzwerk handelt, beispielsweise betreffend einen Host oder eine Kommunikationsverbindung.
Die Regel muss – da sie an eine Paketfiltervorrichtung bereitgestellt wird – geeignet sein, von einer Paketfiltervorrichtung dahingehend umgesetzt zu werden, dass mit dieser Regel Datenpakete identifiziert werden können. Dieses Verständnis folgt aus dem Begriff der „Paketfiltervorrichtung“. Denn mithilfe einer Paketfiltervorrichtung kann aus einer Menge an Paketen eine Teilmenge herausgenommen werden. Die Kriterien, nach denen diese Teilmenge bestimmt wird, legt die Regel fest, die der Paketfiltervorrichtung bereitgestellt wird. Die Regel enthält mithin Kriterien, nach denen einzelne der empfangenen Dateien von anderen empfangenen Dateien unterschieden und mithin identifiziert werden können.
Dieses Verständnis wird gestützt durch die Beschreibung des Klagepatents in Abschnitt [0049]. Anhand der bereitgestellten Regel kann die Paketfiltervorrichtung im Ausführungsbeispiel Datenpakete identifizieren, verwerfen oder fallen lassen, wobei sich das Identifizieren nicht auf den Fall der Verschleierung von Datenpaketen beschränkt, sondern die Identifizierung empfangener Datenpakete allgemein in Bezug nimmt.
b)
Das Erstellen der Regel folgt nach Merkmal 9 in Reaktion auf das Korrelieren. Aus dem Korrelationsergebnis wird die Regel abgeleitet. Es besteht somit ein Kausalzusammenhang zwischen dem Korrelieren und dem Erstellen der Regel.
Diesen Kausalzusammenhang beschreibt das Klagepatent anhand eines Ausführungsbeispiels in Abschnitt [0048] und [0049] genauer. Als Reaktion auf das Korrelieren der gesendeten und empfangenen Datenpakete kann der Paketkorrelator basierend auf einem oder mehreren Einträgen in den Logs beispielsweise Nachrichten generieren, die einen Host identifizieren, oder mitteilen, dass ein Host mit einer bösartigen Entität kommuniziert. Der Paketkorrelator kann beispielsweise auch Nachrichten generieren, um den Administrator über die Kommunikation des Hosts mit der böswilligen Entität zu benachrichtigen. Während hier allerdings nur Nachrichten in Reaktion auf das Korrelieren erzeugt werden, verlangen die Klagepatentansprüche das Erzeugen von ein oder mehreren Regeln.
III.
Es lässt sich nicht feststellen, dass die angegriffene Ausführungsform von der Lehre des Klagepatentanspruchs 15 Gebrauch macht. Ebenso wenig lässt sich feststellen, dass sie geeignet ist, ein Verfahren im Sinne des Klagepatentanspruchs 1 durchzuführen. Schließlich ist auch nicht erkennbar, dass die mit dem Hilfsantrag angegriffenen Komponenten der angegriffenen Ausführungsform geeignet sind, zusammen mit weiteren Komponenten und entsprechender Software eine Vorrichtung im Sinne des Klagepatentanspruchs 1 zu bilden. In allen Fällen fehlt es an der Verwirklichung der Merkmalsgruppen 2 bis 5 sowie der Merkmale 6 und 9
1.
Die von den Routern, Switches oder Wireless Controllern erzeugten Original NetFlow Records bzw. Flexible NetFlow Records enthalten keine Log-Einträge in Form von unterscheidbaren Informationen zu an der Netzwerkvorrichtung empfangenen und gesendeten Datenpaketen im Sinne der Merkmale 3.1. und 5.1.
a)
Die Router, Switches und Wireless Controller der angegriffenen Ausführungsform leiten die im Netzwerk ankommenden Datenpakete durch- bzw. weiter. Sie sind nach dem hier vertretenen Verständnis Netzwerkvorrichtungen im Sinne des Klagepatents.
Mittels der „Netflow“-Funktionalität erzeugen die Netzwerkvorrichtungen der angegriffenen Ausführungsform verschiedene „Records“ – (Original) NetFlow Records bzw. Flexible NetFlow Records. Diese „Records“ enthalten verschiedene Informationen betreffend die durchgeleiteten Datenpakete wie beispielsweise „source IP address“, „destination IP address“, „input interface“, „output interface“ und stellen somit Log-Einträge im Sinne der Merkmale 3 und 5 dar. Soweit es sich bei diesen „NetFlow Records“ oder bei den auf Ebene des R Collectors erzeugten „P“ um aggregierte Informationen über den Datenfluss zwischen zwei Hosts als Ganzes und nicht um differenzierte Informationen über Datenpakete auf einzelnen Segmenten der betreffenden Netzwerkvorrichtung handelt, stellen auch diese aggregierten Informationen Log-Einträge dar, da es nach dem hier maßgeblichen Verständnis auf die Form der Aufbereitung der Daten nicht ankommt.
b)
Die NetFlow Records bzw. die P ermöglichen keine Unterscheidung zwischen Log-Einträgen, die die von der Netzwerkvorrichtung empfangenen Datenpakete und solche, die die von der Netzwerkvorrichtung übertragenen Datenpakete betreffen und verwirklichen damit nicht die Merkmale 3.1. und 5.1. Für diese Unterscheidung ist nach dem hier maßgeblichen Verständnis zwar nicht zu fordern, dass eine Eins-zu-Eins-Zuordnung von identifiziertem Datenpaket und erzeugtem Log-Eintrag erfolgt. Die Log-Einträge, die die von der Netzwerkvorrichtung empfangenen Datenpakete betreffen, müssen jedoch von den Log-Einträgen, die die von der Netzwerkvorrichtung übertragenen Datenpakete betreffen, unterscheidbar vorliegen.
Soweit die Klägerin eine solche Unterscheidung darin sieht, dass die Log-Einträge „Interface Input“ und „Interface Output“ generiert werden, enthalten diese Einträge Informationen aus der Schnittstelle des Netzwerkgeräts, durch die Datenpakete vom Netzwerkgerät empfangen bzw. weitergesendet werden. Damit ist nicht aufgezeigt, dass unterscheidbare Log-Einträge für empfangene und für gesendete Datenpakete erzeugt werden, denn eine Zuordnung der Datenpakete zu einem Datenfluss („Flow“) ist auch möglich, indem Datenpakete mit identischen Headerinformationen für einen Datenfluss gebündelt erfasst werden, ohne nach Eingang und Ausgang unterscheidbare Log-Einträge zu generieren.
Auch für die Analyse des eingehenden Datenverkehrs („Ingress“) sowie des ausgehenden Datenverkehrs („Egress“) durch die angegriffene Ausführungsform ist nicht dargetan, dass unterscheidbare Log-Einträge in Bezug auf eingehende und weitergesendete Datenpakete vorliegen. Die Klägerin hat hierzu in der mündlichen Verhandlung auf die als Anlage A 29a (in deutscher Übersetzung als A 29b) vorgelegten Auszüge aus Unterlagen der Beklagten und dem Zitat aus einer Stellungnahme des Herrn X im US-Verfahren verwiesen und erklärt, dass jedes der angegriffenen Geräte „ingress“- und „egress“-Daten erzeugen kann, die angegriffene Ausführungsform mithin zwischen dem Eingang und dem Ausgang der Datenpakete unterscheide. Beschrieben werde diese Unterscheidung in der vorlegten Anlage A 29a auf Seite 1 in Bezug auf den Flow Monitor, der für die Datenanalyse allein den Eingangsverkehr („Ingress“) oder allein den Ausgangsverkehr („Egress“) nutzt. Die Netzwerkvorrichtung identifiziere mithin die ein- und ausgehenden Datenpakete und kennt – da die Datenpakete lediglich durchgeleitet werden – die Zuordnung des jeweiligen eingehenden zu dem jeweiligen ausgehenden Datenpakets.
Allerdings sind die eingehenden und ausgehenden Datenpakete – dies haben die Beklagten in der mündlichen Verhandlung ausgeführt – identisch und somit ist lediglich die Zuordnung der Datenpakete zu einem Datenfluss von Interesse sowie ggf. die Schnittstelle, über die das betreffende Datenpaket an die Netzwerkvorrichtung gelangt oder aus ihr weitergeleitet wird. Eine Aussage über das Verhältnis von eingehenden und ausgehenden Datenpaketen, was die Erzeugung unterscheidbarer Log-Einträge für eingehende und für weitergeleitete Datenpakete voraussetzt, trifft die angegriffene Ausführungsform damit nicht.
Darin kommt die grundsätzlich im Verhältnis zur Lehre des Klagepatents andere Funktionsweise der angegriffenen Ausführungsform zum Ausdruck. Nach dem patentgemäßen Verfahren ist zwischen eingehenden und ausgehenden Paketen zu unterscheiden. Das Klagepatent geht davon aus, dass – etwa aufgrund veränderter Headerinformationen – nicht sicher bekannt ist, ob eingehende und ausgehende Pakete identisch sind. Daher identifiziert das Rechensystem, das von der Netzwerkvorrichtung zu unterscheiden ist, die bei der Netzwerkvorrichtung eingehenden und ausgehenden Pakete und erzeugt paketbezogen Log-Einträge. Bei der angegriffenen Ausführungsform werden hingegen die Log-Einträge – jedenfalls wenn man von den Original oder Flexible Netflow Records ausgeht und nicht von den aggregierten Netflows – durch die Netzwerkvorrichtung selbst, also durch die Router, Controller und Switches erzeugt. Diesen ist aber bekannt, welches Paket eingeht und welches ausgeht. Daher sind die Netflow Records nicht Paket- sondern Flow-bezogen. Das heißt, die Netzwerkvorrichtung unterscheidet grundsätzlich nicht zwischen ein- und ausgehenden Paketen, sondern kennt nur das eine Paket, das es beispielsweise aufgrund bestimmter Headerdaten einem konkreten Flow zuordnet. Und erst im Rahmen dieser Zuordnung werden zum Beispiel Schnittstellenangaben und dergleichen als Log-Einträge in den jeweiligen Flow aufgenommen. Das sind jedoch keine Log-Einträge im Sinne der Merkmale 3.1 und 5.1.
2.
Das Rechensystem der angegriffenen Ausführungsform führt den Verfahrensschritt des Korrelierens nach Merkmal 6 nicht durch.
Das Rechensystem der angegriffenen Ausführungsform wird durch den E bzw. R Collector sowie die Q und die G gebildet und führt die Erstellung der „P“ und deren Auswertung durch. Dass aus dieser Auswertung eine statistische Aussage über die eingehenden und weitergeleiteten Datenpakete abgeleitet wird, lässt sich nicht feststellen.
Nach dem insoweit bestrittenen Vortrag der Klägerin in der mündlichen Verhandlung soll das eigentliche Korrelieren auf der Ebene der T stattfinden, die die gesammelten P empfange, in Bezug zueinander setze und sodann Wahrscheinlichkeiten hinsichtlich der Vorgänge in den Datenflüssen des Netzwerks ermittle. Dieser Vortrag lässt nicht erkennen, was in welcher Form korreliert wird. Selbst wenn man dem Verständnis der Klägerin folgt, ist nicht dargetan, wie hier ein Vergleich von aus- und eingehenden Paketen stattfinden kann, zumal es insoweit an unterscheidbaren Log-Einträgen in Bezug auf eingehende und auf ausgehende Datenpakete fehlt.
Stattdessen haben die Beklagten in der mündlichen Verhandlung hinsichtlich der Funktionsweise der angegriffenen Ausführungsform klargestellt, dass auf der Ebene der T die aus den Netflows gewonnenen Datenflussmuster mit Bedrohungsmustern in Bezug gesetzt werden. Der mit der in der mündlichen Verhandlung als Anlage A 29a vorgelegte Passus (Seite 3 der Anlage A 29a):
„R will then correlate the received syslog and relates it to the flows collected from network devices before and after the proxy, providing deeper visibility into customers web traffic.“
betreffe somit den Abgleich bestimmter Flow-Muster, die auf Grundlage der weiterverarbeiteten NetFlow Records erstellt werden mit vorerkannten Mustern von Bedrohungen und nicht – wie die Klägerin meint – ein Korrelieren im Sinne des Merkmals 6. Ein Korrelieren von übertragenen Paketen mit empfangenen Paketen auf Grundlage von Log-Einträgen ist das nicht und lässt sich anhand des Klägervortrags auch nicht feststellen.
3.
Schließlich verwirklicht die angegriffene Ausführungsform Merkmal 9 nicht. Folgt man dem Verständnis der Klägerin, wonach die angegriffene Ausführungsform Log-Einträge hinsichtlich eingehender und ausgehender Datenpakete korreliert, fehlt es an dem Erzeugen und Bereitstellen einer Regel in Reaktion auf das Korrelieren.
Die angegriffene Ausführungsform sieht verschiedene Reaktionen auf das Feststellen einer Bedrohung vor – neben Alarmen auch sogenannte „Incidents“, die in der Folge unterschiedliche Aktionen des Systems auslösen können, beispielsweise die Isolation eines Hosts oder das Blockieren bestimmter Domains (siehe hierzu das in Auszügen als Anlage A 26 vorgelegte Dokument „S SecureX threat response Data Sheet“). Damit ist jedoch nicht aufgezeigt, dass der betreffende „Incident“ auch tatsächlich aus dem Korrelationsergebnis abgeleitet wird. Ein solches Verständnis folgt auch nicht aus dem als Anlagenkonvolut A 30a (in deutscher Übersetzung als Anlage A 30b) vorgelegten Dokument „Rapid Threat Containment“. Aus dem von der Klägerin in Bezug genommenen Absatz
„Upon detecting a flagrant threat in an endpoint, a pxGrid eco-system partner can instruct ISE to contain the infected endpoint either manually or automatically“
folgt, dass die auf eine Bedrohung folgenden Handlungsanweisungen von einem Administrator gesetzt („manually“) oder zumindest vorab gewählt („ISE Partner can instruct … automatically“) werden. Die Beklagten haben hierzu in der mündlichen Verhandlung dargelegt, dass der System-Administrator bei der angegriffenen Ausführungsform entscheidet, welche Regel auf eine festgestellte Bedrohung hin ins Werk gesetzt werden soll. Dies gelte auch im Hinblick auf Alarme, die nicht den Automatismus einer bestimmten Handlung auslösen. Es fehlt somit nach dem hier maßgeblichen Verständnis an der Erzeugung eines Incidents in Reaktion auf die detektierte Bedrohung.
C
Die Kostenentscheidung folgt aus § 91 Abs. 1 S. 1 ZPO.
Die Entscheidung über die vorläufige Vollstreckbarkeit ergibt sich aus § 709 S. 1 und 2 ZPO.
Der Streitwert wird gemäß §§ 51 Abs. 1 GKG auf 500.000,00 Euro festgesetzt.

Düsseldorfer Entscheidungen

D-Prax.de

4b O 33/20 – Rechensystem-Verfahren

Schreibe einen Kommentar