Landgericht Düsseldorf·4b O 33/20·09.12.2021

EP-Patentverletzung: NetFlow/Stealthwatch verwirklicht Paket-Korrelation und Regelbereitstellung nicht

Gewerblicher RechtsschutzPatentrechtAbgewiesen

KI-Zusammenfassung

Die Klägerin verlangte wegen Verletzung des deutschen Teils eines EP Unterlassung, Auskunft, Rechnungslegung, Rückruf, Vernichtung und Schadensersatzfeststellung im Zusammenhang mit NetFlow-/Stealthwatch-Komponenten. Streitpunkt war u.a., ob unterscheidbare Log-Einträge zu empfangenen und gesendeten Paketen vorliegen, ob eine Korrelation i.S.d. Anspruchs erfolgt und ob daraufhin Regeln an eine Paketfiltervorrichtung bereitgestellt werden. Das LG Düsseldorf wies die Klage ab, weil die angegriffenen NetFlow-Records/Flows keine getrennten Log-Einträge für eingehende und ausgehende Pakete bereitstellen und weder ein anspruchsgemäßes Korrelieren noch ein kausal darauf beruhendes Erzeugen/Bereitstellen von Regeln festgestellt werden konnte.

Ausgang: Klage auf patentgestützte Unterlassungs- und Folgeansprüche mangels Verwirklichung der Anspruchsmerkmale abgewiesen.

Abstrakte Rechtssätze

Der unbestimmte/bestimmte Artikel („eine/die“) in einem Patentanspruch ist nicht zwingend zahlenmäßig zu verstehen; aus der Beschreibung kann folgen, dass eine „Netzwerkvorrichtung“ ein oder mehrere Geräte umfasst.

„Log-Einträge, die Paketen entsprechen“, erfordern keine Eins-zu-Eins-Zuordnung zwischen Paket und Eintrag; auch aggregierte oder kumulierte Log-Einträge können anspruchsgemäß sein, sofern eine Zuordnung zu den betreffenden Paketen besteht.

Verlangt der Anspruch Log-Einträge zu empfangenen und gesendeten Paketen als Grundlage der Korrelation, müssen diese Log-Einträge für beide Richtungen unterscheidbar vorliegen; bloße Schnittstellenangaben innerhalb flowbezogener Aufzeichnungen genügen hierfür nicht ohne Weiteres.

„Korrelieren“ von gesendeten mit empfangenen Paketen bedeutet einen auf Log-Einträgen beruhenden Vergleich, aus dem sich eine (auch statistische) Aussage über das Verhältnis von übertragenen zu empfangenen Paketen ableiten lässt; ein Abgleich von Flow-Mustern mit Bedrohungsmustern ist hiervon zu unterscheiden.

Regeln, die „in Reaktion auf“ die Korrelation erzeugt und an eine Paketfiltervorrichtung bereitgestellt werden, setzen einen Kausalzusammenhang zwischen Korrelationsergebnis und Regelgenerierung voraus; bloße Alarmierung oder administratorgesteuerte Auswahl/Setzung von Maßnahmen erfüllt dies nicht.

Relevante Normen

§ 91 Abs. 1 Satz 1 ZPO§ 709 Satz 1 und Satz 2 ZPO§ 51 Abs. 1 GKG

Tenor

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 X (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 X) 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 4210, 5200 und 5210, der auf dem Flow Collector installierten Software B Stealthwatch sowie der über die Amazon Webservices (AWS) betriebenen cloud-basierten Anwendung B Cognitive Intelligence, die zusammen mit mindestens einem der folgenden Netzwerkgeräte angeboten und vertrieben werden:

B Catalyst Switches der Serien 9300, 9400 und 9500, jeweils mit dem Betriebssystem IOS-XE Version 16.5 oder höher,

B Catalyst Wireless Controller der Serie 9800, mit dem Betriebssystem IOS-XE Version 16.10 oder höher,

B Aggregation Services Router der Serie 1000 mit dem Betriebssystem IOS-XE 16.5 oder höher,

B Integration Services Router der Serien 1000 und 4000 mit dem Betriebssystem IOS-XE 16.5 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 B (Stealthwatch) FlowCollector wird vom Administrator über die Benutzeroberfläche einer Stealthware Management Console gesteuert. Die Stealthware Management Console steuert ihrerseits mehrere physische Flow Collectoren, 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, B IOS Release 15S 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 „Flow Collector“ (auch bezeichnet als „Stealthwatch Collector“) typischerweise gebündelt gesendet. Der Flow Collector erzeugt aus den NetFlowRecords sogenannte „Stealthwatch Flows“ und sendet diese an die B Cognitive Intelligence. 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 B Cognitive Intelligence verfügbaren Informationen werden durch Auswertung zahlreicher Datenquellen unter Einsatz von „Machine Learning“ generiert. Anhand der ausgewerteten Daten erzeugt die B Cognitive Intelligence 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 Flow Collectors und der B Cognitive Intelligence 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 B Cognitive Intelligence ausgewertet. Durch die Korrelation der Pakete zu einem Flow könne die B Cognitive Intelligence 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 StealthWatch Management Console und die mit dieser verbundenen Stealthwatch 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 B Cognitive Intelligence 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 B Secure Firewall“ dem Betriebssystem der Firewall oder im Rahmen der „SecureX Threat Response and B 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 B Secure Firewall und B 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,

die Beklagten zu verurteilen

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,

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 Flow Collector 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;

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

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, Flow Collectoren, virtuelle Maschinen und Software nicht ohne Zustimmung des Klägers als Inhaber des deutschen Teil des Europäischen Patents EP 3 257 202 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;

Switches, Router oder Controller jeweils gemeinsam mit Flow Collectoren 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;

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:

100

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

101

102

Abnehmern im Gebiet der Bundesrepublik Deutschland anzubieten und/oder an solche zu liefern, ohne

103

- im Falle des Anbietens im Angebot ausdrücklich und unübersehbar darauf hinzuweisen, dass die Switches, Router, Controller, Flow Collectoren, virtuelle Maschinen und Software nicht ohne Zustimmung des Klägers als Inhaber des deutschen Teil des Europäischen Patents EP X mit einer Vorrichtung verwendet werden dürfen, welche konfiguriert ist, um das oben genannte Verfahren auszuführen;

104

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

105

106

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

107

a) der Namen und Anschriften der Hersteller, Lieferanten und anderer Vorbesitzer,

108

b) der Namen und Anschriften der gewerblichen Abnehmer sowie der Verkaufsstellen, für die die Erzeugnisse bestimmt waren,

109

c) der Menge ausgelieferten, erhaltenen oder bestellten Erzeugnisse sowie der Preise, die für die betreffenden Erzeugnisse bezahlt wurden,

110

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;

111

112

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:

113

a) der einzelnen Lieferungen, aufgeschlüsselt nach Liefermengen, -zeiten, -preisen und Typenbezeichnungen sowie den Namen und Anschriften der Abnehmer,

114

b) der einzelnen Angebote, aufgeschlüsselt nach Angebotsmengen, -zeiten, -preisen und Typenbezeichnungen sowie den Namen und Adressen der gewerblichen Angebotsempfänger,

115

c) der betriebenen Werbung, aufgeschlüsselt nach Werbeträgern, deren Auflagenhöhe, Verbreitungszeitraum und Verbreitungsgebiet,

116

d) der nach den einzelnen Kostenfaktoren aufgeschlüsselten Gestehungskosten und des erzielten Gewinns,

117

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;

118

119

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;

120

121

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;

122

II.

123

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.

124

Die Beklagten beantragen,

125

die Klage abzuweisen,

126

hilfsweise

127

den Rechtsstreit bis zur rechtskräftigen Entscheidung im Nichtigkeitsverfahren (Az. 5 Ni 50/20 (EP)) gegen den deutschen Teil des EP X auszusetzen.

128

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.

129

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.

130

Weiterhin finde bei der angegriffenen Ausführungsform ein Korrelieren im Sinne des Klagepatents nicht statt. An die Cognitive Intelligence würden keine NetFlow Records sondern lediglich aggregierte Stealthwatch Flows gesendet. Diese Stealthwatch Flows seien nicht detailliert genug, dass B Cognitive Intelligence 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 Stealthwatch Flows 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.

131

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.

132

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 B Cognitive Intelligence ein Alarmsignal zur bloßen Anzeige an den Administrator (Stealthwatch Management Console), aufgrund des Ermittelns einer Bedrohung. Hierbei handele es sich nicht um eine erzeugte Regel, sondern um bereits vor der Korrelation feststehende Bedrohungserkennungskriterien.

133

Schließlich würden keine Regeln an die Hardwarekomponenten gesendet. Denn es bestehe keine Rückverbindung zwischen der cloud-basierten B Cognitive Intelligence an die Hardwarekomponenten. Vielmehr sende B Cognitive Intelligence ein Alarmsignal zur bloßen Anzeige an den Administrator (Stealthwatch Management Console), wenn eine Bedrohung erkannt werde.

134

Der Flow Collector, der mit dem Stealthwatch 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.

135

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

136

Die zulässige Klage ist nicht begründet.

137

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

138

139

Die Erfindung des Klagepatents betrifft das Korrelieren von Paketen in Kommunikationsnetzen.

140

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.

141

Aus der US X 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.

142

Weiter offenbare die US X 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.

143

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.

144

Dies soll durch die unabhängigen Klagepatentansprüche 1 und 15 erreicht werden, deren Merkmale wie folgt gegliedert werden können:

145

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.

146

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.

147

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

148

II.

149

Vor dem Hintergrund des Streites der Parteien bedarf es einer Auslegung der Merkmalsgruppen 2 bis 5 sowie der Merkmale 6 und 9.

150

151

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

152

153

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.

154

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

155

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

156

„Netzwerkvorrichtung(en) 122 jedoch ein oder mehrere Geräte enthalten […]“

157

158

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.

159

Dem Teilmerkmal

160

„die Log-Einträge entsprechen der Vielzahl von Paketen“

161

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.

162

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

163

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

164

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.

165

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.

166

167

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.

168

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

169

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]

170

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

171

172

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.

173

174

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.

175

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.

176

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.

177

178

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.

179

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.

180

III.

181

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

182

183

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.

184

185

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.

186

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 Stealthwatch Collectors erzeugten „Stealthwatch Flows“ 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.

187

188

Die NetFlow Records bzw. die Stealthwatch Flows 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.

189

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.

190

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

191

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.

192

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.

193

194

Das Rechensystem der angegriffenen Ausführungsform führt den Verfahrensschritt des Korrelierens nach Merkmal 6 nicht durch.

195

Das Rechensystem der angegriffenen Ausführungsform wird durch den Flow Collector bzw. Stealthwatch Collector sowie die Stealthwatch Management Console und die B Cognitive Intelligence gebildet und führt die Erstellung der „Stealthwatch Flows“ und deren Auswertung durch. Dass aus dieser Auswertung eine statistische Aussage über die eingehenden und weitergeleiteten Datenpakete abgeleitet wird, lässt sich nicht feststellen.

196

Nach dem insoweit bestrittenen Vortrag der Klägerin in der mündlichen Verhandlung soll das eigentliche Korrelieren auf der Ebene der Cognitive Intelligence stattfinden, die die gesammelten Stealthwatch Flows 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.

197

Stattdessen haben die Beklagten in der mündlichen Verhandlung hinsichtlich der Funktionsweise der angegriffenen Ausführungsform klargestellt, dass auf der Ebene der Cognitive Intelligence 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):

198

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

199

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.

200

201

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.

202

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 „B 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

203

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

204

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.

205

Die Kostenentscheidung folgt aus § 91 Abs. 1 S. 1 ZPO.

206

Die Entscheidung über die vorläufige Vollstreckbarkeit ergibt sich aus § 709 S. 1 und 2 ZPO.

207

Der Streitwert wird gemäß §§ 51 Abs. 1 GKG auf 500.000,00 Euro festgesetzt.

208

Dr. Voß Dr. Gräwe Dr. Gruneberg