Bundespatentgericht (Bundesrepublik Deutschland, Ordentliche Gerichtsbarkeit)
Urteil vom 2025-05-08, Aktenzeichen 5 Ni 23/22 (EP)
ECLI: ECLI:DE:BPatG:2025:080525U5Ni23.22EP.0

Tenor:
BPatG München, 08.05.2025, 5 Ni 23/22 (EP)
In der Patentnichtigkeitssache
…
betreffend das europäische Patent EP 3 284 238
(DE 60 2016 016 646)
hat der 5. Senat (Nichtigkeitssenat) des Bundespatentgerichts auf Grund der mündlichen Verhandlung vom 8. Mai 2025 durch den Richter Heimen als Vorsitzenden sowie die Richter Dipl.-Geophys. Univ. Dr. Wollny, Schödel, Dr.-Ing. Ball und Dipl.-Ing. Jürgensen
für Recht erkannt:
I. Das europäische Patent EP 3 284 238 wird mit Wirkung für das Hoheitsgebiet der Bundesrepublik Deutschland mit der Maßgabe für nichtig erklärt, dass seine Patentansprüche folgende Fassung erhalten:
Im Übrigen wird die Klage abgewiesen.
II. Von den Kosten des Verfahrens trägt die Klägerin 2/5, die Beklagte 3/5.
III. Das Urteil ist gegen Sicherheitsleistung in Höhe von 120% des jeweils zu vollstreckenden Betrages vorläufig vollstreckbar.

Tatbestand:
Die Beklagte ist eingetragene Inhaberin des europäischen Patents EP 3 284 238 (Streitpatent – SP), das am 07. April 2016 angemeldet und dessen Erteilung am 10. Juli 2019 veröffentlicht worden ist. Das Streitpatent nimmt die Priorität der US-amerikanischen US 201514690302 vom 17. April 2015 in Anspruch. Das in englischer Sprache gefasste Streitpatent trägt die Bezeichnung „RULE-BASED NETWORK-THREAT DETECTION“, ins Deutsche übersetzt „REGELBASIERTE NETZWERKBEDROHUNGSDETEKTION“. Es ist in Kraft und umfasst in der erteilten Fassung insgesamt 15 Patentansprüche, und zwar den auf ein Verfahren gerichteten Patentanspruch 1 und die auf diesen unmittelbar oder mittelbar rückbezogenen Unteransprüche 2 bis 14 sowie den auf eine Vorrichtung gerichteten nebengeordneten Patentanspruch 15.
Die erteilten Patentansprüche 1 und 15 haben in der Verfahrenssprache folgenden Wortlaut:
Patentanspruch 1:
A method comprising:
receiving (702), by a packet-filtering device (144, 146), a plurality of packet-filtering rules (218) configured to cause the packet-filtering device to identify packets corresponding to at least one of a plurality of network-threat indicators (234);
receiving (704), by the packet-filtering device, a plurality of packets;
for each packet of the plurality of packets and responsive to a determination (706) by the packet-filtering device that the packet corresponds to one or more criteria, specified by a packet-filtering rule of the plurality of packet-filtering rules, that correspond to one or more network-threat indicators of the plurality of network-threat indicators:
applying (708), by the packet-filtering device and to the packet, an operator specified by the packet-filtering rule and configured to cause the packet-filtering device to either prevent the packet from continuing toward its destination or allow the packet to continue toward its destination;
generating (710), by the packet-filtering device, a packet-log entry comprising information from the packet-filtering rule that identifies the one or more network-threat indicators and indicating whether the packet-filtering device prevented the packet from continuing toward its destination or allowed the packet to continue toward its destination;
generating (712), by the packet-filtering device and based on the packet-log entry, data indicating whether the packet-filtering device prevented the packet from continuing toward its destination or allowed the packet to continue toward its destination;
communicating (714), by the packet-filtering device and to a user device, the data; and
causing, based on the communicated data, display of the data in a portion of an interface displayed by the user device, the portion of the interface corresponding to the packet-filtering rule and the one or more network-threat indicators, the data indicating (716) whether the packet-filtering device prevented the packet from continuing toward its destination or allowed the packet to continue toward its destination; and
determining an ordering of a plurality of network threats;
wherein a first network threat of the plurality of network threats corresponds to a first packet-filtering rule, the first packet-filtering rule based on one or more network-threat indicators included in a first portion of a plurality of network-threat-intelligence reports; a second network threat of the plurality of network threats corresponds to a second packet-filtering rule, the second packet-filtering rule based on one or more network-threat indicators included in a second portion of the plurality of network-threat-intelligence reports; and
determining the ordering comprises determining an order of the first network threat relative to the second network threat based on a determination of whether the first portion of the plurality of network-threat-intelligence reports was received from a greater number of one or more network-threat-intelligence providers than the second portion of the plurality of network-threat-intelligence reports.
Patentanspruch 15:
An apparatus configured to perform the method of any one of claims 1-14.
Wegen des Wortlauts der auf den Patentanspruch 1 unmittelbar oder mittelbar rückbezogenen Patentansprüche 2 bis 14 wird auf das Streitpatent verwiesen.
Mit ihrer Klage begehrt die Klägerin die vollständige Nichtigerklärung des Streitpatents. Sie macht die Nichtigkeitsgründe der fehlenden Patentfähigkeit, nämlich mangelnde Neuheit und mangelnde erfinderische Tätigkeit (Art. 138 Abs. 1 Buchst. a) i.V.m. Art. 54, 56 EPÜ), sowie der unzulässigen Erweiterung (Art. 138 Abs. 1 Buchst. c) i.V.m. Art. 123 EPÜ) geltend. Sie stützt ihren Vortrag u. a. auf die nachfolgenden Druckschriften:
K4 Offenlegungsschrift, WO 2016 / 168 044 A1
K5 WO 2012 / 164 336 A1
K6/6v A. Henmi et al., Firewall Policies and VPN Configurations, Syngress Publishing, Inc., 2006
K7/7a_Juniper/7v R. Cameron et al., NetScreen Firewalls, Syngress Publishing, Inc., 2005
K7a/NSM Juniper Networks, Network and Security Manager, Administration Guide, Release 2010.2, 01.04.2011
K7b/NSM NSM-Website "NSM Dates & Milestones", Beleg des Zeitrangs der K7a/NSM
K8/8v R. Stephens et al., Check Point NGX VPN-1/FireWall-1, Syngress Publishing, Inc., 2005
K8a Check Point, Firewall R76 Administration Guide, 14.02.2013
K8b Check Point, Application Control and URL Filtering R76 Administration Guide, 24.04.2014
K9/9v T. Shinder, ISA 2006 Migration Guide, Syngress Publishing, Inc., 2007
K12 Wikipedia-Artikel "Softwaretechnik", Version vom 02.02.2015,
K13 R. Elmasri et al., Fundamentals of Database Systems, 3. Aufl., 2000, Inhaltsverzeichnis, S. 135-139, 199-201, 251-261,
K15 Sourcefire 3D System, User Guide, Version 4.10, 16.03.2011
K15a Wayback-Maschine https://web.archive.org/web/ 20110430194135/https://support.sourcefire.com/, Beleg des Zeitrangs der K15
K16a Wayback-Maschine https://web.archive.org/web/ 20130310033030/https://docs.oracle.com/cd/E19859-01/820-3252-11/FP44ucgACL.html, Configuring Access Control Lists (ACLs)
K16b Wayback-Maschine https://web.archive.org/web/ 20140701165444/https://www.digitaltut.com/policy-based-routing-questions, Policy Based Routing Questions
K16c Wayback-Maschine https://web.archive.org/web/ 20140821104118/https://serverfault.com/questions/78060/routing-table-hits, Routing table hits?
Die Beklagte verteidigt das Streitpatent in der geltenden Fassung. Hilfsweise verteidigt sie das Streitpatent in der Fassung von 25 Hilfsanträgen, die sie auf den qualifizierten Hinweis des Senats vom 25. Januar 2023 hin zur hilfsweisen Verteidigung des Streitpatents mit Schriftsatz vom 2. Mai 2023 (Hilfsanträge 1 bis 13), Schriftsatz vom 28. Dezember 2023 (Hilfsanträge 4a, 6a, 7a, 11a, 11b, 11c) sowie mit Schriftsatz vom 14. März 2025 (Hilfsanträge 4b, 5a, 9a, 10a, 11d, 12a, 13a, 13b) eingereicht hat.
Der Patentanspruch 1 gemäß Hilfsantrag 1 unterscheidet sich von der erteilten Fassung dadurch, dass an dessen Ende folgende Ergänzung als Merkmal M5.7_Hi1 angefügt wird:
„and wherein the interface includes an element that when invoked by a user causes the user device to instruct the packet-filtering device to reconfigure the operator to prevent packets corresponding to the one or more criteria from continuing toward their destination.“
Der Patentanspruch 1 gemäß Hilfsantrag 2 unterscheidet sich von der erteilten Fassung dadurch, dass an dessen Ende folgende Ergänzung als Merkmal M5.7_Hi2 angefügt wird:
„and additionally displaying, on the interface, a listing in accordance with the ordering, wherein the listing comprises entries corresponding to the plurality of nerwork threats, and wherein the interface includes one or more block options that when invoked by a user cause the packet-filtering device to prevent packets corresponding to a network threat of the plurality of network threats from continuing toward their destination.“
Der Patentanspruch 1 gemäß Hilfsantrag 3 stellt eine Modifizierung des Hilfsantrags 2 dar. Die Ergänzung des Merkmals M5.7_Hi3 an dessen Ende lautet wie folgt (Änderungen ggü. Hilfsantrag 2 durch Fettdruck bzw. Streichung hervorgehoben):
„and additionally displaying, on the interface, a listing in accordance with the ordering, wherein the listing comprises entries corresponding to the plurality of network threats, and wherein the interface includes one or more block options that, when invoked by a user cause reconfigure the packet-filtering device from allowing packets corresponding to a network threat of the plurality of network threats to preventing packets corresponding to a network threat of the plurality of network threats from continuing toward their destination.“.
Der Patentanspruch 1 gemäß Hilfsantrag 4b unterscheidet sich von der erteilten Fassung dadurch, dass an dessen Ende folgende Ergänzungen als Merkmale M5.7_Hi4b und M5.8_Hi4b angefügt werden:
„and additionally displaying, on the interface, a listing in accordance with the ordering, wherein the listing comprises entries corresponding to the plurality of network threats, and wherein the interface includes one or more block options that, when invoked by a user reconfigure the packet-filtering device from allowing packets corresponding to the network threat of the plurality of network threats to preventing packets corresponding to the network threat of the plurality of network threats from continuing toward their destination,
wherein invoking the one or more block options causes displaying of another interface including specific block options including blocking packets corresponding to the network threat destined for or originating from a host in an internal network, blocking packets corresponding to the network threat destined for or originating from an internal host that has generated or received packets associated with the network threat, blocking packets received from an internal host that has generated or received packets associated with the network threat and destined for an internal host, and blocking packets received from an internal host that has generated or received packets associated with the network threat and destined for an external host.“
Wegen des Wortlauts der Ansprüche im Übrigen sowie hinsichtlich der weiteren Hilfsanträge wird auf die Akte verwiesen.
Die Klägerin vertritt zu den Nichtigkeitsgründen die Auffassung, der Gegenstand des erteilten Patentanspruchs 1 sei gegenüber den Anmeldeunterlagen unzulässig erweitert. Der Gegenstand des Patentanspruchs 1 sei auch nicht patentfähig, insbesondere mangele es ihm an der Neuheit, zumindest beruhe er nicht auf einer erfinderischen Tätigkeit. Dies gelte auch für die erteilten Unteransprüche. Die mangelnde Neuheit des erteilten Patentanspruchs 1 ergebe sich insbesondere aus der Druckschrift K5, die mangelnde erfinderische Tätigkeit insbesondere aus der Druckschrift K5 in Verbindung mit dem Fachwissen bzw. in Verbindung mit den Druckschriften K6, K7, K8, K9 oder K15.
Ebenso mangele es dem Gegenstand von Patentanspruch 1 nach allen Hilfsanträgen wenigstens an der erfinderischen Tätigkeit.
Die Klägerin beantragt,
das europäische Patent EP 3 284 238 mit Wirkung für das Hoheitsgebiet der Bundesrepublik Deutschland in vollem Umfang für nichtig zu erklären.
Die Beklagte beantragt,
die Klage abzuweisen,
hilfsweise die Klage abzuweisen mit der Maßgabe, dass das Streitpatent die Fassung eines der Hilfsanträge 1 bis 13b, eingereicht mit Schriftsätzen vom 2. Mai 2023 bzw. 28. Dezember 2023 bzw. 14. März 2025 erhält.
Die Beklagte erklärt, dass der Hauptantrag und die Hilfsanträge jeweils als geschlossene Anspruchssätze zu verstehen seien und die Hilfsanträge in der angegebenen, alphanumerischen Reihenfolge gestellt seien, wobei jedoch Hilfsantrag 4b direkt nach Hilfsantrag 3 zur Prüfung gestellt werde. Die beiden Hilfsanträge 11b und 11c werden nicht weiterverfolgt.
Sie verteidigt das Streitpatent in der geltenden Fassung und tritt der Klage in allen Punkten entgegen. Die Gegenstände der geltenden Patentansprüche gingen nicht über die ursprünglich eingereichten Unterlagen hinaus und seien neu und erfinderisch. Dies gelte auch für die Gegenstände nach den Hilfsanträgen. Jedenfalls in diesen hilfsweise verteidigten Fassungen seien die Gegenstände dieser Patentansprüche neu und beruhten auch auf einer erfinderischen Tätigkeit.
Wegen der weiteren Einzelheiten des Vorbringens der Parteien wird auf die zwischen den Parteien gewechselten Schriftsätze nebst Anlagen und den weiteren Inhalt der Akte Bezug genommen.

Entscheidungsgründe:
Die Klage ist zulässig und hat in der Sache teilweise Erfolg. Das Streitpatent erweist sich als nicht rechtsbeständig, soweit es über die mit Hilfsantrag 4b verteidigte Fassung hinausgeht. Es ist daher im tenorierten Umfang wegen mangelnder Patentfähigkeit gemäß Art. II § 6 Abs. 1 Nr. 1 IntPatÜG i. V. m Art. 138 Abs. 1 Buchst. a) und Art. 56 EPÜ für nichtig zu erklären.
A.
I. Zum Gegenstand des Streitpatents
1. Das Streitpatent betrifft die Thematik der Netzwerksicherheit, wobei Netzwerkbedrohungen in vielfältigen Formaten vorlägen, wie bspw. nicht-autorisierte Anforderungen und Datentransfers, Viren, Malware und große Datenmengen, um die bereitgestellten, verfügbaren Netzwerkressourcen zu überlasten (SP, Titel und Abs. [0001]).
Viele Organisationen nähmen Netzwerkbedrohungsdienste in Anspruch, die regelmäßig Informationen hinsichtlich (aktueller) Netzwerkbedrohungen umfassend eine Auflistung von Bedrohungsindikatoren zur Verfügung stellten, wobei aber der gesamte protokollierte Netzwerkverkehr ungeachtet der vorliegenden Bedrohungsindikatoren überprüft werde, was sehr umständlich und zeitaufwändig sei (SP, Abs. [0001]).
In diesem technischen Kontext der Netzwerksicherheit bestehe daher ein Bedarf bzw. stelle sich das Streitpatent die Aufgabe, eine regelbasierte Detektion von Netzwerkbedrohungen bereitzustellen (SP, Abs. [0001]).
2. Die nebengeordneten Patentansprüche 1 und 15 gemäß Hauptantrag lassen sich gemäß Streitpatentschrift in der maßgeblichen englischen Verfahrenssprache und der deutschen Übersetzung wie folgt gliedern:
Merkmal M
Lt. Streitpatentschrift in englischer Sprache
Dt. Übers. lt. Streitpatent
1
Verfahren, umfassend:
2
Empfangen (702) durch eine Paketfiltervorrichtung (144, 146) einer Mehrzahl von Paketfilterregeln (218), die so gestaltet sind, dass sie bewirken. dass die Paketfiltervorrichtung Pakete gemäß mindestens einem einer Mehrzahl von Netzwerkbedrohungsindikatoren (234) identifiziert;
3
Empfangen (704) durch die Paketfiltervorrichtung einer Mehrzahl von Paketen;
4
for each packet of the plurality of packets and responsive to a determination (706) by the packet-filtering device
für jedes Paket der Mehrzahl von Paketen und als Reaktion auf eine Bestimmung (706) durch die Paketfiltervorrichtung,
5
that the packet corresponds to one or more criteria, specified by a packet-filtering rule of the plurality of packet-filtering rules, that correspond to one or more network-threat indicators of the plurality of network-threat indicators:
dass das Paket einem oder mehreren Kriterien entspricht, die durch eine Paketfilterregel der Mehrzahl von Paketfilterregeln spezifiziert sind, die einem oder mehreren Netzwerkbedrohungsindikatoren der Mehrzahl von Netzwerkbedrohungsindikatoren entsprechen:
5.1
applying (708), by the packet-filtering device and to the packet, an operator specified by the packet-filtering rule and configuredto cause the packet-filtering device to either prevent the packet from continuing toward its destination or allow the packet to continue toward its destination;
Anwenden (708) durch die Paketfiltervorrichtung und auf das Paket eines Operators, der durch die Paketfilterregel spezifiziert und so gestaltet ist, dass er es bewirkt, dass die Paketfiltervorrichtung es entweder verhindert, dass das Paket weiter in Richtung seines Bestimmungsortes verläuft, oder es zulässt, dass das Paket weiter in Richtung seines Bestimmungsortes verläuft;
5.2
Erzeugen (710) durch die Paketfiltervorrichtung eines Paketprotokolleintrags, der Informationen von der Paketfilterregel umfasst, welche den einen oder die mehreren Netzwerkbedrohungsindikatoren identifizieren und anzeigen, ob die Paketfiltervorrichtung es verhindert hat, dass das Paket weiter in Richtung seines Bestimmungsortes verläuft oder es zugelassen hat, dass das Paket weiter in Richtung seines Bestimmungsortes verläuft;
5.3
Erzeugen (712) durch die Paketfiltervorrichtung und auf der Basis des Paketprotokolleintrags von Daten, die anzeigen, ob es die Paketfiltervorrichtung verhindert hat, dass das Paket weiter in Richtung seines Bestimmungsortes verläuft, oder ob sie es zugelassen hat, dass das Paket weiter in Richtung seines Bestimmungsortes verläuft;
5.4
Kommunizieren (714) durch die Paketfiltervorrichtung und an eine Benutzervorrichtung der Daten; und
5.5
auf der Basis der kommunizierten Daten, Bewirken, dass die Daten in einem Teil einer durch die Benutzervorrichtung angezeigten Schnittstelle angezeigt werden, wobei der Teil der Schnittstelle der Paketfilterregel und dem einen oder den mehreren Netzwerkbedrohungsindikatoren entspricht, wobei die Daten Anzeigen (716), ob es die Paketfiltervorrichtung verhindert hat, dass das Paket weiter in Richtung seines Bestimmungsortes verläuft, oder ob sie es zugelassen hat, dass das Paket weiter in Richtung seines Bestimmungsortes verläuft; und
5.6
Bestimmen einer Rangordnung einer Mehrzahl von Netzwerkbedrohungen;
5.6.1
wherein a first network threat of the plurality of network threats corresponds to a first packet-filtering rule, the first packet-filtering rule based on one or more network-threat indicators included in a first portion of a plurality of network-threat-inteIligence reports;
wobei eine erste Netzwerkbedrohung der Mehrzahl von Netzwerkbedrohungen einer ersten Paketfilterregel entspricht, wobei die erste Paketfilterregel auf einem oder mehreren Netzwerkbedrohungsindikatoren basiert, die in einem ersten Teil einer Mehrzahl von Netzwerkbedrohungsaufklärungsberichten enthalten sind;
5.6.2
a second network threat of the plurality of network threats corresponds to a second packet-filtering rule, the second packet-filtering rule based on one or more network-threat indicators included in a second portion of the plurality of network-threat-intelligence reports; and
wobei eine zweite Netzwerkbedrohung der Mehrzahl von Netzwerkbedrohungen einer zweiten Paketfilterregel entspricht, wobei die zweite Paketfilterregel auf einem oder mehreren Netzwerkbedrohungsindikatoren basiert, die in einem zweiten Teil einer Mehrzahl von Netzwerkbedrohungsaufklärungsberichten enthalten sind; und
5.6.3
wobei das Bestimmen der Rangordnung das Bestimmen eines Rangs der ersten Netzwerkbedrohung im Verhältnis zu der zweiten Netzwerkbedrohung auf der Basis einer Bestimmung umfasst, ob der erste Teil der Mehrzahl von Netzwerkbedrohungsaufklärungsberichten von einer größeren Anzahl eines oder mehrerer Netzwerkbedrohungsaufklärungsanbieter empfangen worden ist als der zweite Teil der Mehrzahl von Netzwerkbedrohungsaufklärungsberichten.
15
An apparatus
Vorrichtung,
15.1
configured to perform the method of any one of claims 1-14.
die zur Ausführung des Verfahrens nach einem der Ansprüche 1 bis 14 gestaltet ist.
3. Als angesprochen Fachmann sieht der Senat einen Ingenieur der Elektrotechnik bzw. Nachrichtentechnik / Informationstechnik mit abgeschlossenem Universitätsstudium und mit mehrjähriger Berufserfahrung in der Entwicklung vernetzter, paketvermittelnder Datenübertragungs- und Kommunikationssysteme, wobei dieser insbesondere detaillierte Kenntnisse hinsichtlich der einschlägigen Netzwerkprotokolle sowie Netzwerksicherheit, bspw. Firewalls, Deep Packet Inspection und Intrusion Detection / Prevention, aufweist.
4. Einige Merkmale bedürfen der näheren Erläuterung. Der Senat legt den Merkmalen nach den Patentansprüchen 1 und 15 folgendes Verständnis zugrunde:
4.1 Zum Patentanspruch 1
Mit dem Merkmal M1 ist ein Verfahren beansprucht, welches gemäß Merkmal M2 das Empfangen einer Vielzahl, d. h. mindestens zwei, von Paketfilterregeln durch eine Paketfiltervorrichtung („packet filtering device“) umfasst, welche die Paketfiltervorrichtung zum Identifizieren von Paketen gemäß mindestens einem einer Vielzahl von Netzwerkbedrohungsindikatoren veranlassen.
Das Streitpatent beschreibt in Absatz [0011], dass Netzwerkbedrohungsaufklärungsanbieter („network-threat-intelligence provider“) Dienste zur Überwachung von Netzwerkbedrohungen bereitstellen und mittels Netzwerkbedrohungsaufklärungsberichten („network-threat-intelligence reports“) entsprechende Netzwerkbedrohungsindikatoren zur Verfügung stellen, welche bspw. Netzwerkadressen, Ports, Domain-Namen, FQDNs, URLs, URIs oder Ähnliches beinhalten. Unter einer Netzwerkbedrohung versteht das Streitpatent u. a. Viren, Malware, bspw. Phishing Malware, Botnet Malware,) sowie große Datenvolumina (SP, Abs. [0001], [0011], [0017]).
Gemäß Streitpatent, Figuren 3A und 3B i.V.m. Absatz [0018], werden die Netzwerkbedrohungen und die Netzwerkbedrohungsindikatoren anschließend von einem Regelprovider in Regeln weiterverarbeitet und der anspruchsgemäßen Paketfiltervorrichtung kommuniziert. Das Streitpatent zeigt einen solchen Regelprovider in Figur 2B i. V. m. den Absätzen [0015] und [0055]. Im gegebenen technischen Kontext handelt es sich bei den Regeln um Richtlinien mit Kriterien umfassenden Prämissen sowie entsprechend zugeordneten Aktionen bzw. Operatoren, bspw. „Wenn-Dann-Regeln“.
Bei der Paketfiltervorrichtung gemäß Patentanspruch 1 handelt es sich um ein eigenständiges Gerät („device“), das bspw. an einer Netzwerkgrenze lokalisiert sein kann und ggf. mit einem Netzwerkgerät, wie bspw. einem Server, Router, Gateway, Switch oder Access Point, assoziiert ist (SP, Fig. 1 und 2A, Abs. [0014]). Der Begriff „assoziiert“ kann sowohl ein Verbunden sein als auch eine Angliederung, Vereinigung bzw. Integration bedeuten, d. h. auch ein in einem Gateway integrierter Paketfilter fällt unter den Anspruchsgegenstand.
Merkmal M3 beansprucht das Empfangen einer Vielzahl, d. h. mindestens zwei, von Paketen durch die Paketfiltervorrichtung. Das Streitpatent zeigt in den Figuren 1 und 2A i.V.m. den Absätzen [0010] und [0012] bis [0014], dass bspw. die Pakete mittels Taps an einem Netzwerkgerät, das an der Netzwerkgrenze in einem Kommunikationspfad zwischen Hosts in einem ersten Netzwerk A und einem weiteren Netzwerk D – wie dem Internet – angeordnet ist, abgegriffen werden können.
Die Paketfiltervorrichtung bestimmt gemäß dem Merkmal M4 für jedes Paket, ob das jeweilige Paket gemäß Merkmal M5 einem oder mehreren Kriterien der Vielzahl von Paketfilterregeln entspricht, die von den Netzwerkbedrohungsindikatoren abgeleitet wurden.
Für jedes derart identifizierte Paket (SP, Abs. [0023], „hit time for the packet“; Abs. [0026] – [0028], „packet hit“) werden sukzessive die Verfahrensschritte M5.1 bis M5.6 abgearbeitet:
· M5.1: Die Paketfiltervorrichtung wendet auf das Paket einen Operator an, wobei das Paket entweder blockiert oder durchgelassen wird (SP, Fig. 4A i. V. m. Abs. [0019], „BLOCK operator“, „ALLOW operator“).
· M5.2: Die Paketfiltervorrichtung generiert einen Paketprotokolleintrag („packet log entry“) umfassend Informationen von der Filterregel hinsichtlich der Netzwerkbedrohungsindikatoren sowie über den auf das Paket angewendeten Operator, d. h. BLOCK oder ALLOW (SP, Fig. 5A – 5G i. V. m. Abs. [0023]). Neben den Paketprotokolleinträgen nennt das Streitpatent ebenfalls Flussprotokolleinträge (SP, Abs. [0025], „flow log entries“).
· M5.3: Die Paketfiltervorrichtung generiert basierend auf dem Protokolleintrag gemäß M5.2 zusätzliche Daten hinsichtlich des auf das Paket angewendeten Operators.
· M5.4: Die Paketfiltervorrichtung sendet diese Daten zu einem Benutzergerät. Gemäß Streitpatent, Absatz [0026], handelt es sich hierbei um ein Benutzergerät eines Administrators.
· M5.5: Das Benutzergerät wird veranlasst, die Daten auf einem Teil seiner graphischen Benutzeroberfläche (GUI) anzuzeigen, welcher der verwendeten Paketfilterregel und den einen oder mehreren Netzwerkbedrohungsindikatoren entspricht (SP, Fig. 6A – 6G, Abs. [0026] – [0027]). Das Streitpatent nennt in den Absätzen [0026] bis [0027] eine graphische Darstellung bspw. als Liniendiagramm, Kuchendiagramm oder als Liste.
· M5.6: Bestimmen einer Rangordnung („ordering“) der Vielzahl von Netzwerkbedrohungen (SP, Abs. [0028]). Gemäß Streitpatent, Absätze [0028] und [0055], kann das Bestimmen der Rangordnung bspw. das Bestimmen einer Punktzahl („score“) umfassen. Das Bestimmen einer Rangordnung bedingt weder unmittelbar ein Sortieren der Netzwerkbedrohungen anhand der Punktzahl noch ein Anzeigen in der sortierten Reihenfolge (SP, Abs. [0028], „… to determine an ordering of the network threats, and listing 606 may be displayed in accordance with the ordering determined by packet-filtering device 144.“). Der Wortlaut des Patentanspruchs lässt offen, ob das Bestimmen der Rangordnung gemäß M5.6 bereits im Paketfilter oder erst im Benutzergerät erfolgen soll. Gemäß Streitpatent, Absatz [0028], wird der Score vom Paketfilter bestimmt und gemäß Streitpatent, Figuren 6A bis 6G, erfolgt die Anzeige der Netzwerkbedrohungen beim Benutzer/Administrator in Abhängigkeit vom Score in einer absteigenden Reihenfolge.
· M5.6.1 und M5.6.2: Die Bestimmung der Rangordnung der Netzwerkbedrohungen wird dahingehend eingeschränkt, dass eine erste/zweite Netzwerkbedrohung jeweils einer ersten/zweiten Paketfilterregel entsprechen sollen, wobei die erste/zweite Paketfilterregel auf den jeweiligen Netzwerkbedrohungsindikatoren basiert, die in einem ersten/zweiten Teil der Vielzahl von Netzwerkbedrohungs-aufklärungsberichten enthalten sind (SP, Fig. 3C und Fig. 4A).
· M5.6.3: Die Bestimmung der Rangordnung der Netzwerkbedrohungen wird weiterhin dahingehend eingeschränkt, dass die Rangordnung der Netzwerkbedrohungen relativ zueinander sein soll und von der jeweiligen ansteigenden Anzahl der Netzwerkbedrohungsaufklärungsberichte versendenden „network-threat-intelligence“-Provider abhängig ist (SP, Fig. 6A i. V. m. Abs. [0029]). Gemäß Streitpatent, Absatz [0028], können jedoch zusätzlich weitere Kriterien zur Bestimmung der Rangordnung bzw. des Scores angewendet werden, wie bspw. die Anzahl der Pakettreffer („packet hits“), d. h. die Anzahl der eine Filterregel erfüllenden Pakete, die seit dem letzten Pakettreffer vergangene Zeit, die Zuordnung zu einer bestimmten Netzwerkadresse oder ggf. weitere Informationen hinsichtlich Geographie, Bedrohungstyp etc.
Zwar konkretisiert die Merkmalsgruppe M5.6, wie die Rangordnung der Bedrohungen für jedes vom Paketfilter identifizierte Paket, also für jeden „packet hit“ separat, zu berechnen ist. Das Streitpatent offenbart dazu bspw. in Absatz [0028], dass insbesondere die „packet hits“ in die Berechnung des Scores einfließen können, so dass sich die Rangordnung bzw. der Score einer Netzwerkbedrohung tatsächlich auf Paketbasis ändert („In such embodiments, the scores may be determined based on a number of associated packet hits …“). Die Merkmalsschritte M5.6.1 bis M5.6.3 können jedoch auch asynchron in einem langsameren Prozess bestimmt werden und die Ergebnisse des langsameren Prozesses können als „semi-statischer“ Summand oder Faktor dann in die entsprechende Berechnung einfließen.
Soweit die Netzwerkbedrohungen dem Regelprovider von den Netzwerkbedrohungsaufklärungsanbietern ausschließlich im Rahmen der o. g. Netzwerkbedrohungsaufklärungsberichte zur Verfügung gestellt werden, ist hinsichtlich des Merkmals M5.6.3 ein Bestimmen eines Scores einer Netzwerkbedrohung anhand der Berichte einer größeren Anzahl von Netzwerkbedrohungsaufklärungsanbietern erst ab zwei verschiedenen Anbietern / Providern sinnvoll zu berechnen. Denn bei einem einzigen Netzwerkbedrohungsaufklärungsanbieter – wie ebenfalls vom Patentanspruch 1 umfasst – lassen sich jedenfalls die Netzwerkbedrohungen mittels M5.6.3 nicht differenzieren.
4.2 Zum Patentanspruch 15
Der nebengeordnete Patentanspruch 15 betrifft eine Vorrichtung („apparatus“) zur Durchführung des Verfahrens u. a. gemäß Patentanspruch 1. Der Senat versteht die Merkmale des nebengeordneten Patentanspruchs 15 daher vom Sachgehalt her analog zur Auslegung der entsprechenden Merkmale des Patentanspruchs 1.
II. Zu den Nichtigkeitsgründen
Der Patentanspruch 1 in der Fassung gemäß Hauptantrag ist zulässig, da sein Gegenstand in den ursprünglich eingereichten Anmeldeunterlagen offenbart ist, und er auch nicht über den Schutzbereich des erteilten Streitpatents hinausgeht (Art. II § 6 Abs. 1 Nr. 3 IntPatÜG i. V. m. Art 138 Abs. 1 c) EPÜ). Er ist jedoch nicht patentfähig, da sein Gegenstand nicht auf einer erfinderischen Tätigkeit beruht (Art. II § 6 Abs. 1 Nr. 1 IntPatÜG i. V. m. Art. 138 Abs. 1 Buchst. a), Art. 56 EPÜ).
1. Zur unzulässigen Erweiterung
Der Fachmann entnimmt den Gegenstand des erteilten Patentanspruchs 1 den ursprünglichen Anmeldeunterlagen unmittelbar und eindeutig.
Der erteilte Patentanspruch 1 wird von der Klägerin aufgrund des anspruchsgemäßen Bestimmens der Rangordnung der Netzwerkbedrohungen in Abhängigkeit der Anzahl von Quellen/Providern für einen assoziierten Bedrohungsindikator für jedes Paket mit dem Argument der unzulässigen Erweiterung gegenüber den ursprünglich eingereichten Anmeldeunterlagen angegriffen.
Die ursprüngliche Offenbarung gemäß K4, Absatz [35], lehrt zu diesem Punkt, dass zur Bestimmung der Rangordnung der Netzwerkbedrohungen ein Score berechnet wird, welcher von der Anzahl der „packet hits“ abhängt, d. h. die Rangordnung erfährt bei jedem Paket mit Erfüllen des Merkmals M5, also jedem „packet hit“, ein Update gemäß Merkmal M5.6. Absatz [35] offenbart zudem im nachfolgenden Kontext, die Anzahl der Quellen bzw. Provider bei der Berechnung des Scores zu berücksichtigen.
Dazu genügt es basierend auf dem Wortlaut gemäß Merkmal M5.6.3 ("determining the ordering comprises“) anspruchsgemäß, die ggf. langsam veränderliche Anzahl der vorhandenen Quellen bzw. Provider pro Bedrohungsindikator vorab zu bestimmen, gelegentlich bspw. beim Empfang eines neuen Netzwerkbedrohungsaufklärungsberichtes anzupassen und gemäß Merkmal M5.6.3 in die Berechnung des Scores bspw. als „quasi-stationärer“ Summand oder Faktor einfließen zu lassen. Die exakte Implementierung obliegt letztlich dem Fachmann aufgrund der sich ihm stellenden Randbedingungen.
Gleiches gilt auch für den nebengeordneten Vorrichtungsanspruch 15 betreffend die Durchführung des Verfahrens u. a. gemäß Patentanspruch 1.
2. Zur Neuheit
Der Gegenstand des Patentanspruchs 1 gemäß Hauptantrag ist gegenüber der Lehre der Druckschriften K5 bis K9 sowie K15 neu (Art. II § 6 Abs. 1 Nr. 1 IntPatÜG i. V. m. Art 138 Abs. 1 Buchst. a), Art. 52, 54 EPÜ), denn es fehlt jeder dieser Druckschriften jeweils mindestens eines seiner Merkmale.
2.1 Aus der Druckschrift K5 (WO 2012 /164 336 A1) sind nicht sämtliche Merkmale des Gegenstands des Patentanspruchs 1 bekannt, denn es fehlen zumindest die Merkmale M5.2, M5.6.1 und M5.6.2 teilweise.
Die K5 betrifft die Verteilung und Verarbeitung von „CYBER THREAT INTELLIGENCE DATA“ in einem Kommunikationsnetzwerk, um potentielle Bedrohungen in Echtzeit zu identifizieren und abzuwenden (K5, Titel und S. 1, Z. 9 - 11, S. 42, Z. 19 - 24).
Die Druckschrift K5 zeigt in Figur 1 eine Netzwerkarchitektur für den Zugriff auf das Internet („peer networks 12, 14“) mit einem Provider-/Carrier-Netzwerk 10 und daran mittels Gateways 22 angeschlossene Kunden- bzw. Unternehmensnetzwerke 16 und 18, wobei die Gateways eine Firewall und ein „Intrusion Detection System (IDS)“ aufweisen (K5, S. 5, Z. 2 - 14 und S. 6, Z. 15 - 16), so dass die Gateways aus dem Datenverkehr Pakete filtern, d. h. verwerfen („discard“) oder durchlassen („release“) können (K5, Fig. 6 i. V. m. S. 30, Z. 1 - 6).
Im Provider-/Carrier-Netzwerk befinden sich zusätzlich „Packet Manipulation Devices (PMD) 32, 42“, welche eingehende („ingress“) bzw. ausgehende („egress“) Pakete markieren („stain“) und ebenfalls als zusätzliche Paketfilter filtern können, wobei das Filtern bspw. ein Verwerfen („discard“) oder ein „in Quarantäne Setzen“ von Paketen umfasst (K5, Fig. 12 i. V. m. S. 32, Z. 16 - 25, S. 41, Z. 31 - 32).
Ein zentrales „Intelligence Headquarter (IHQ) 24“ im Provider-/Carrier-Netzwerk generiert einen „comprehensive Threat Report“, wozu das Headquarter auf viele verschiedene interne und externe Quellen zugreift, umfassend Sensoren und forensische Module im Netzwerk, „open sources“, „websites“, „security vendors“ sowie „web-proxies“ im Kundennetz (K5, Fig. 1 und Fig. 2 BZ 24 i. V. m. S. 7, Z. 3 ff. und S. 9, Z. 23 ff.). Die Gateways und die PMDs gelten ebenfalls als Sensoren (K5, S. 9, Z. 1 - 3). Der Threat-Report wird dabei stetig verbessert und aktualisiert (K5, S. 8, Z. 28 - 31, „threat intelligence data refining process“).
Der Threat-Report umfasst eine Liste von Verkehrsattributen verdächtiger Hosts, bspw. deren Netzwerkadressen, aggregierte „Event Logs“ und darüber hinaus noch jeweils eine Einschätzung der Reputation („reputation score“) einer speziellen Bedrohung, wobei der „reputation score“ umso niedriger ausfällt, je unzuverlässiger ein Host erachtet wird (K5, Fig. 3). Der „reputation score“ wird anhand mehrerer Kriterien ermittelt, u. a. mittels der Anzahl von Quellen, welche die Bedrohung identifizieren konnten, die Glaubwürdigkeit einer Quelle (Open Source, Law Enforcement etc.), dem Monitoring-Typ durch einen Sensor, die Anzahl von der Bedrohung hervorgerufener und geloggter Events oder auch die seit dem Auftreten der Bedrohung vergangene Zeit (K5, S. 21, Z. 19 - S. 22, Z. 21).
Das IHQ kommuniziert mit den Gateways und den PMDs und stellt diesen einen „customized Threat Report“ zur Verfügung, den diese abspeichern und für ihre im Gateway bzw. im PMD generierten Paketfilterregeln verwenden (K5, Fig. 6 und7 i. V. m. S. 27, Z. 6 - 24, S. 29, Z. 20 - S. 30 Z. 8, S. 31, Z. 20 - S. 32, Z. 25, S. 41, Z. 9 - 32).
Für jedes vom Filter empfangene Paket wird zunächst bestimmt, ob das Paket die im „customized Threat Report“ gelisteten Verkehrsattribute aufweist. Bei Übereinstimmung („match“) wird anschließend die Reputation geprüft und eine entsprechende Handlung initiiert („action“). Nach einem Verwerfen des Pakets, bspw. aufgrund einer sehr geringen Reputation, senden die Gateways einen Alarm ans IHQ, während die PMDs den Event loggen und als Feedback ans IHQ signalisieren (K5, S. 30, Z. 5, S. 32, Z. 18 - 21, S. 41, Z. 31 - 33).
Darüber hinaus können die Gateways auch beim Vorliegen einer Netzwerkadresstransformation (NAT) spezielle Endpunkte im Kunden-/ Unternehmensnetzwerk durch Korrelation von geloggten Event-Reports bzw. von geloggten Messages bzw. DNS-Requests der Sensoren im Providernetz, welche vom Threat Report umfasst werden, mit Eventinformation aus dem Kunden-/Unternehmens-Netzwerk identifizieren, falls die Endpunkte bspw. eine DNS-Anforderung an verdächtige Domänen im Internet gerichtet oder Nachrichten mit Viren, Malware, Phishing oder Spam übertragen haben (K5, S. 30, Z. 9 - 30).
Schließlich verfügt das IHQ über eine Schnittstelle für das Sicherheits-Management-Personal, welches per Konsole oder über das Internet zwecks Programmierung, Modifikation von Parametern oder zur Assistenz zugreifen kann (K5, S. 9, Z. 15 - 22).
Der Fachmann entnimmt der K5 somit folgende Lehre:
Die K5 betrifft entsprechend Merkmal M1 ein Verfahren/”Method” (K5, Anspruch 1).
Im Ausgangspunkt übereinstimmend mit Merkmal M2 offenbart die K5 drei verschiedene Paketfiltergeräte, nämlich ein Gateway (K5, Fig. 6 i.V.m. S. 28, Z. 15 - S. 30, Z. 8), ein Ingress PMD (K5, Fig. 8 i.V.m. S. 31, Z. 3 - S. 32, Z. 25) und ein Egress PMD (K5, Fig. 12 i.V.m. S. 40, Z. 18 - S. 41, Z. 32). Die drei unterschiedlichen Paketfiltergeräte empfangen mittels des “(customized) threat intelligence report” vom IHQ insoweit abweichend von Merkmal M2 (“plurality of packet-filtering rules (218)”) noch keine Regeln, sondern lediglich eine Liste von Argumenten für zu implementierende Regeln. Dabei besteht allerdings eine 1:1-Beziehung zwischen der Anzahl der Argumente in der Liste und der Anzahl der Regeln des Filters (K5, S. 29, Z. 24 - Z. 30, “The gateway 22 determines whether the received packet 620 has any of the traffic attributes contained in the customized threat report 610 that was previously stored in the memory. If there is a match, i.e., if the gateway 22 determines a traffic attribute of the received packet 620 that appears in the customized threat report 610, then the gateway 22 obtains the reputation indicator (e.g., a reputation score) associated with that traffic attribute, as specified by the customized threat report 610. The gateway 22 then disposes of the packet 620 based on the reputation score.”). Die Regeln werden erst im Gateway bzw. in den PMDs anhand des empfangenen Bedrohungsberichts generiert. Die Filterfunktion des Gateways ist somit in seiner (integrierten) Firewall lokalisiert, welche vom (übergeordneten) Gateway, entsprechend dem Rule-Provider, die dort generierten Regeln erhält/ empfängt. Da die Kombination aus Gateway und Firewall gemäß K5 ein eigenständiges Gerät (“device”) darstellt, fehlt in der K5 der anspruchsgemäße Empfang von Regeln an diesem eigenständigen Paketfilter im Sinne von Merkmal M2.
Zudem empfangen und verarbeiten die Paketfiltergeräte gemäß Lehre der K5 eine Vielzahl von Paketen entsprechend den Merkmalen M3 und M4 (bzgl. Gateway vgl. K5, S. 29, Z. 23 - 24, “the gateway 22 receives a packet 620”, S. 29, Z. 22, “processing future packets received from the carrier network 10 over the data links.”; bzgl. Ingress PMD vgl. K5, S. 31, Z. 18 - 19, “processing future packets received by the carrier network 10 from peer network 12.”, S. 31, Z. 20 – 21, “ingress packet manipulation device 32 receives a packet 820”; bzgl. Egress PMD vgl. K5, S. 40, Z. 32 - S. 41, Z. 1, “processing future packets received by the carrier network 10 from customer network 16”, S.41, Z. 9 - 11, “egress packet manipulation device 42 receives a packet 1220”).
Gemäß Lehre der K5 identifizieren die drei Paketfilter - also Gateway, Ingress PMD sowie Egress PMD – jeweils die von Netzwerkgefahren betroffene Pakete anhand von Wenn-Dann-Regeln (K5, S. 29, Z. 26, S. 31, Z. 24, S. 41, Z. 13, “If there is a match …”). Damit wird Merkmal M5 erfüllt.
In Übereinstimmung mit Merkmal M5.1 wenden die Paketfilter in der K5 Operatoren auf die identifizierten Pakete an, welche ein Verwerfen (“discard”) des Pakets umfassen (bzgl. Gateway, vgl. K5, Fig. 6, S. 29, Z. 29 - 30, “The gateway 22 then disposes of the packet 620 based on the reputation score.”, S. 30, Z. 1 - 5, “the gateway 22 may discard the packet 620 (step 640) when the reputation score is low and may release the packet 620 into the remainder of the customer network 16 (see step 630) when the reputation score is high, or when no matching traffic attribute could be found.”; bzgl. Ingress PMD, vgl. K5, S. 32, Z. 16 - 21; bzgl. Egress PMD, vgl. K5, Fig. 12, S. 41, Z. 29 - 33).
In der K5 werden die Merkmale M5.2, M5.3 und M5.4 zusammengefasst, wobei die Ingress PMD und Egress PMD Filter-Event-Logs generieren und diese unmittelbar dem IHQ übermitteln, jedoch ohne gemäß Merkmal M5.3 in einem separaten Schritt noch “indicating data” zu extrahieren, wobei Ingress und Egress PMDs das Verwerfen eines Pakets explizit ebenfalls in einem LOG protokollieren und an das IHQ signalisieren (K5, S. 32, Z. 18- 20, “the ingress packet manipulation device 32 discards (or quarantines) the packet 820, logs the event and optionally signals this occurrence to IHQ 24.”, S. 41, Z. 31 - 32, “the egress packet manipulation device 42 discards (or quarantines) the packet 1220, logs the event and optionally signals this occurrence to IHQ 24.”). Das Gateway agiert sowohl als Paketfilter und Firewall, als auch als Sensor. Hinsichtlich des Gateways offenbart die im Falle des Verwerfens des Pakets zumindest das separate Signalisieren eines Alarms an das IHQ (S. 30, Z. 5 - 6, S. 33, Z. 5 - 6, S. 36, Z. 30 - 32, S. 40, Z. 6 - 8, “Another possibility is for the gateway 22 to signal an alarm to IHQ 24 …”). Das Gateway umfasst darüber hinaus ebenso eine (integrierte) Firewallfunktion, welche ebenfalls Eventinformation liefert (K5, S. 6, Z. 15 - 16, “gateway 22 include a firewall and an intrusion detection system (IDS)”, S. 30, Z. 28 - 30, “The gateway 22 can correlate the received event information with event information from firewalls”). Schließlich umfasst das Gateway – wie auch die o. g. PMDs – eine Sensorfunktion mit Monitoring, welche bspw. mit dem “Suspect Report” Event-Logs liefert (K5, S. 9, Z. 1 - 3, “one or more of the gateways 22, the ingress packet manipulation devices 32 and the egress packet manipulation- devices 42 may also have the functionality of a sensor.”, Fig. 3 i.V.m. S. 14, Z. 21 - 30). Zudem offenbart die K5 allgemein für die Sensoren – und somit auch für Gateways und PMDs – ein Protokollieren der Paketdatenflüsse mit NetFlow bzw. PeakFlow (S. 14, Z. 7 - 20).
Jedoch unterscheidet sich das in der K5 genannte Benutzergerät im IHQ lokal und funktional von dem Benutzergerät eines Administrators i.S.d. Streitpatents gemäß der Merkmale M5.4 und M5.5 dahingehend, dass es im Providernetzwerk zur vorgelagerten Generierung der Netzwerkbedrohungen für die Netzwerkbedrohungsaufklärungsberichte durch den Netzwerkbedrohungsaufklärungsanbieter dient und keine Verwaltung, Bedienung und Konfiguration des eigentlichen Firewalls bzw. Paketfilters im Kunden- bzw. Unternehmensnetzwerk durchführt. Dabei bleiben bspw. im IHQ insbesondere die vom Gateway bzw. die von den PMDs anhand der Netzwerkbedrohungen generierten Regeln mangels entsprechenden Feedbacks der Regeln in den “suspect reports” definitiv unbekannt.
Das Merkmal M5.5 ist in der K5 mit Ausnahme der Bezugnahme auf die Paketfilterregeln gemäß Merkmal M2 verwirklicht. Gemäß K5, Seite 9, Zeilen 15 bis 22, umfasst das IHQ eine Benutzerschnittstelle für das Sicherheitsmanagementpersonal, wobei das Personal mittels des Benutzergeräts Konsole 30 oder mittels eines Benutzergeräts im Internet Zugriff erhält und im “threat intelligence data refining process” mitwirkt (vgl. auch K5, Fig. 4). Der vom IHQ produzierte “comprehensive threat report” wird als Tabelle mit multiplen Feldern visualisiert (K5, Fig. 3 Bz. 8 und Fig. 4, Schritt 420 i.V.m S. 18, Z. 19 - 23, “IHQ 2 produce a comprehensive threat report 308 based on the raw cyber threat intelligence data collected at step 410, In a non-limiting embodiment, and with reference to Fig, 3S the comprehensive threat report 308 may be visualized as a table of records, each record having a plurality of fields.”, Hervorhebung hinzugefügt). Dabei liest der Fachmann mit, dass diese Visualisierung in fachüblicher Weise auf den Benutzergeräten des Sicherheitsmanagementpersonals im IHQ erfolgt. Der “comprehensive threat report” umfasst neben den Verkehrsattributen auch eine Aggregation der dazugehörigen Event Logs, welche die Information über “threat indicators” sowie verworfene oder durchgelassene Pakete enthalten (K5, S. 18, Z. 24 – S. 19, Z. 4; vgl. auch Ausführungen zu Merkmal M5.3).
Darüber hinaus offenbart die K5, Seite 26, Zeilen 21 bis 27, zusätzlich noch “comparative dashboards”, in welchen für (Netzwerk-)Manager der Kunden- bzw. Unternehmensnetzwerke die “customized threat reports” präsentiert werden (vgl. K5, Fig. 7 i. V .m. S. 27, Z. 14 - S. 28, Z. 14). Dabei liest der Fachmann in natürlicher Weise mit, dass diese Visualisierung jetzt auf weiteren Benutzergeräten der (Netzwerk-)Manager bzw. Administratoren im Kunden-/Unternehmens-Netzwerk erfolgt. Jedoch betrifft diese Anzeige des “customized threat reports” auf dem “Dashboard” für (Netzwerk-)Manager ebenso lediglich die Netzwerkbedrohungen ohne jegliche Bezugnahme auf die Paketfilterregeln.
Gemäß K5, Figur 3 i. V. m. Seite 19, Zeilen 5 bis 27, umfasst der “comprehensive threat report 308” ein Ranking der Vielzahl von Netzwerkbedrohungen anhand des “reputation scores” mit den Stufen 1 bis 10. Gleiches gilt auch für den davon abgeleiteten “customized threat report”, wobei dort die “reputation indicators” ebenfalls einen Score darstellen (K5, Fig. 7 i.V.m. S. 27, Z. 22 - S. 28, Z. 14, “… the contents of the “reputation indicator” field indicates the reputation indicator (e.g. a ‘reputation score’) …”). Das Merkmal M5.6 liegt damit vor.
Mit Ausnahme des Bezuges auf die (erste/zweite) Paketfilterregel sind auch die Merkmale M5.6.1 und M5.6.2 zumindest teilverwirklicht. Denn der “comprehensive threat report” gemäß K5 umfasst für eine Netzwerkbedrohung neben den Verkehrsattributen auch eine Aggregation der dazugehörigen Event Logs, welche die Information über “threat indicators” sowie verworfene oder durchgelassene Pakete enthalten (K5, S. 18, Z. 24 - S. 19, Z. 4; vgl. auch Ausführungen zu M5.3).
Auch Merkmal M5.6.3, mit dem die Bestimmung einer Rangordnung beansprucht ist, wird in der K5 gelehrt. Gemäß K5 erfolgt die Berechnung des “reputation scores” einer potentiellen Bedrohung u. a. anhand der Anzahl der die Bedrohung nennenden Quellen, wobei eine Bedrohung als umso relevanter eingeschätzt und daher der “reputation score” umso niedriger angesetzt wird, je mehr Quellen diese spezielle Bedrohung nennen (K5, S. 21, Z. 19 - 25, “the number of cyber threat intelligence sources that have revealed the particular traffic attribute as a potential threat. Specifically, a greater number of suspect reports or seed sources on which the particular traffic attribute appears can have a lowering effect on the reputation score;”).
In der K5 fehlt also teilweise das Merkmal M2 hinsichtlich des Empfangens von Regeln im Paketfilter, insoweit die Kombination aus Gateway mit Firewall ein eigenständiges Gerät (“device”) i. S. d. Streitpatents darstellt. Korrespondierend dazu fehlen in der K5 darüber hinaus jeweils teilweise die Merkmale M5.5 hinsichtlich einer Anzeige der Daten an einem Benutzergerät entsprechend den zugehörigen Regeln, sowie die Merkmale M5.6.1 und M5.6.2 hinsichtlich der mit den Netzwerkbedrohungen verknüpften Regeln.
Soweit die Beklagte argumentiert, dass der “Event Report” gemäß K5, Seite 14, letzter Absatz bis Seite 15, erster Absatz, keine Information über durchgelassene bzw. verworfene Pakete in den Paketfiltern enthielte und damit dem IHQ darüber keine Informationen gemeldet werde, kann diese Auffassung nicht überzeugen. Denn – wie oben zu den Merkmalen M5.2 und M5.3 ausgeführt– melden die PMDs diese Information in den “Event Reports” an das IHQ und das Gateway signalisiert diese Information als Alarm ebenso ans IHQ.
2.2 Die Anlagen K6, K7, K7a/NSM, K8, K9 und K15 betreffen jeweils vorveröffentlichte Handbücher für die Benutzerschnittstellen von kommerziell erhältlichen Firewalls, deren Lehre gegenüber dem Gegenstand des Patentanspruchs 1 neu ist. Die Klage vermag nichts Gegenteiliges aufzuzeigen.
Ihr Fokus liegt im Wesentlichen auf einer umfangreichen Beschreibung der Verfahren zum Betrieb der jeweiligen Firewalls mittels graphischer Benutzeroberflächen (GUIs) auf einem Benutzergerät, bspw. dem Terminal eines Administrators (Merkmal M1).
Für diese kommerziellen Firewalls, welche anspruchsgemäße Paketfilter darstellen, können im Rahmen von Abonnements („subscriptions“) regelmäßige Sicherheitsupdates, bspw. aktuelle Policies vom Hersteller bzw. von Providern bezogen werden, so dass Regeln für einen Paketfilter gemäß Merkmal M2 empfangen werden (K6, S. 184, „SmartDefense Subscription Service“; K7v, S. 397, „Automatic DI Updates“; K8, S. 26, „SmartDefense Subscription Service“; K8a, S. 65, „Updating IPS Protections“; K8b, S. 184, „SmartDefense Subscription Service“; K15, S. 1710, „Automating Vulnerability Database Updates“).
Die jeweiligen Firewalls entscheiden für eine Vielzahl empfangener Pakete anhand der empfangenen Policies/Regeln, ob diese blockiert oder durchgelassen werden, wobei auf den GUIs entsprechende Anzeigen u.a. zur Verwaltung und ggf. Konfiguration der typischen Performancedaten bzw. Performancereports, der Statistiken, der Protokolldateien/Logs und der Policies/Regeln bereitgestellt werden (Merkmale M3 bis M5.5).
Die Anlagen K6, K7, K7a/NSM, K8, K9 und K15 verschweigen sich jedoch jeweils zumindest hinsichtlich einer anspruchsgemäßen Bestimmung der Rangordnung von Netzwerkbedrohungen, insbesondere in Abhängigkeit einer Anzahl von Netzwerkbedrohungsberichte liefernden Providern, gemäß der Merkmalsgruppe M5.6.
3. Zur erfinderischen Tätigkeit
Der Gegenstand des Anspruchs 1 gemäß Hauptantrag beruht jedoch jeweils gegenüber der Zusammenschau der Druckschrift K5 mit einer der Druckschriften K6 bis K9 oder K15 nicht auf einer erfinderischen Tätigkeit (Art. II § 6 Abs. 1 Nr. 1 IntPatÜG i. V. m. Art 138 Abs. 1 Buchst. a), Art. 52, 56 EPÜ).
3.1 Wie vorstehend ausgeführt unterscheidet sich die Lehre der Druckschrift K5 vom Verfahren gemäß Patentanspruch 1 lediglich darin, dass sie zum einen kein anspruchsgemäßes Empfangen von Regeln am Paketfiltergerät lehrt (Merkmal M2 teilweise) und zum anderen kein Anzeigen von Regeln zusammen mit den Daten (Merkmal M5.5 teilweise) bzw. kein Entsprechen („corresponds“) der Regeln mit den Netzwerkbedrohungen zeigt (Merkmale M5.6.1, M5.6.2 jeweils teilweise).
Ob es sich beim Merkmal M5.5, das in einem Teilmerkmal das Anzeigen von Daten in einem speziellen Bereich einer Benutzerschnittstelle beansprucht, um die bloße Wiedergabe einer vorhandenen Information, die lediglich das menschliche Vorstellungsvermögen anspricht, handelt oder – wie die Beklagte meint - um ein technisches Lösungsmittel für ein technisches Problem, welches bei der der Prüfung auf erfinderische Tätigkeit zu berücksichtigen ist, kann im Ergebnis offenbleiben.
Denn die von den Druckschriften K6 bis K9 und K15 gelehrten graphischen Benutzeroberflächen (GUIs) im Rahmen von Benutzerendgeräten zeigen jeweils derartige Umsetzungsmöglichkeiten. Entsprechende Verfahren und Einrichtungen wie sie mit diesem Teilmerkmal beansprucht sind, waren dem Fachmann nahegelegt bekannt und beruhen nicht auf erfinderischer Tätigkeit.
Entgegen der Argumentation der Beklagten offenbart die K5 nicht ausschließlich ein vollautomatisches System, sondern auch eine Benutzerschnittstelle im IHQ, so dass das für das Sicherheitsmanagement zuständige Personal, bspw. zur Optimierung bzw. Adaption der IHQ-Parameter in einem kontinuierlichen Verbesserungsprozess (K5, S. 9, Z. 15 - 22, „steps of the threat intelligence data refining process“), eingreifend wirken kann, wobei gemäß K5, Figur 3, Bezugszeichen 308 sowie Figur 4, Schritt 420 i. V. m. Seite 18, Zeilen 19 bis 23 der vom IHQ generierte “comprehensive threat report” als Tabelle mit multiplen Feldern visualisiert wird.
Darüber hinaus offenbart die K5, dass ihre Lehre auch speziell zur Anwendung in Unternehmensnetzen geeignet ist (S. 42, Z. 25 - 29, „… threat assessment in accordance with the principles oft he present invention can be performed in … enterprise networks.“). In diesem Fall befindet sich das IHQ und dessen Management offensichtlich im Verantwortungsbereich des Administrators des Unternehmensnetzwerks, was insbesondere für eine Integration der IHQ-Management-Software in die bereits vorhandene Sicherheitssoftware des Kunden, bspw. für sein Gateway bzw. seine Firewall, spricht.
Gemäß K5 stellt das IHQ dem Kunden-Gateway den auf den Kunden zugeschnittenen, d. h. individualisierten, „customized threat report“ zur Verfügung (K5, Fig. 4, Bezugszeichen 450, 455), wobei automatisch und ohne explizite Bestätigung auf den Gateway bzw. die Firewall zugegriffen, und dadurch der Datenverkehr bzw. die Performance des Unternehmensnetzwerks beeinflusst wird. Hierfür schließt der Kunde ggf. mit einem Internetprovider/ISP einen entgeltlichen Vertrag ab (K5, S. 8, Z. 7 - 11, „subscribe to a threat monitoring and/or assessment service … a fee may or may not be associated“).
Der Kunde hat daher zum einen ein berechtigtes Interesse an einer optischen Anzeige, welche Bedrohungsdaten der IHQ in welcher Aktualität sowie Qualität an sein Gateway liefert. Zum anderen will der kundenseitige Administrator die Eingriffe des IHQ auf das Gateway bzw. die Firewall überwachen und steuern, um ggf. bei auftretenden Problemen mit den automatisch generierten Firewallregeln eingreifen zu können und somit letztlich die vollständige Kontrolle über sein Unternehmensnetzwerk zu behalten.
Hierfür benötigt der Kundenadministrator zwangsläufig eine geeignete Darstellungsmöglichkeit der vom IHQ gelieferten individualisierten („customized“) Threat-Reports sowie der automatisch vom Gateway generierten Firewallregeln in seinen eigenen Tools.
Dafür liefert die K5 auch dem Fachmann die entsprechenden Hinweise und Anregungen, wobei die Eventinformation des „customized threat reports“ mit derjenigen des Gateway-Firewalls korreliert werden soll (K5, S. 30, Z. 18 - 30), und wobei den (Netzwerk-)Managern des Kunden- bzw. Unternehmensnetzwerks der „customized threat report“, also die Netzwerkbedrohungen und deren Score, bereits in einem Dashboard angezeigt werden soll (K5, S. 26, Z. 21 - 27).
In diesem Zusammenhang wird der Fachmann in der K5 auch zumindest das zwangsläufige Vorhandensein eines üblichen Benutzergeräts zur Verwaltung, Bedienung und Konfiguration der dort vorhandenen Firewall bzw. des Paketfilters im Kunden- bzw. Unternehmensnetzwerk durch dessen Administrator erwarten und somit ein solches mit einer zum Anmeldetag typischen Ausgestaltung auch in Betracht ziehen, obwohl die K5 über dieses weitere Benutzergerät sowie jegliche nähere Ausgestaltung desselben schweigt.
Die zum Prioritätsdatum des Streitpatents kommerziell verfügbaren, marktüblichen Firewalls werden bspw. in der K6 beschrieben (K6, Deckblatt, “Covers the Top Market-Leading Firewalls: Cisco PIX, Check Point NGX, Microsoft ISA Server, Juniper's NetScreen Firewall, and SonicWALL”).
Die K6 betrifft allgemein die Konfiguration von Firewall-Policies bzw. VPNs für die gängigen Firewalls („market-leading firewalls“) und lehrt sowohl ein vom Router/Gateway eigenständiges „Firewall-Device“ (K6, Fig. 1.5 i.V.m. S. 33, zweiter Absatz, „Figure 1.5 illustrates the ﬂow pattern for information through a basic single-ﬁrewall setup. This type of trafﬁc control can be achieved through hardware or software“) als auch eine Paketfilter-Firewall im Gateway an der Netzwerkgrenze zum Internet, welche entsprechende Regeln von einem Administrator oder im Rahmen einer „SmartDefense“-Subscription empfangen (vgl. K6, S. 98 und 118, Fig. 3.7 und S. 19, „The security administrator will deﬁne the rule base and conﬁgure the ﬁrewall as deﬁned above, in addition to other industry standard properties as appropriate.“; S. 184, „The goal is to provide ongoing and real-time updates and conﬁguration advisories for defenses and security policies. … If you subscribe to the SmartDefense Services, new ﬁlters and options are added dynamically to the lists through automatic updates.“, Unterstreichungen hinzugefügt; Merkmal M2 teilweise).
Die Firewall gemäß K6 stellt ebenfalls ein Protokollieren des durchgehenden und blockierten Datenverkehrs entsprechend der Firewallregeln bereit (K6, S. 17, zweiter Absatz, „The ﬁrewall should provide extensive logging of trafﬁc passed and blocked.“, Merkmal M5.5 teilweise).
Die K6 zeigt darüber hinaus am Beispiel des Microsoft ISA Servers 2004 eine entsprechende graphische Benutzeroberfläche (GUI) auf einem Benutzergerät für das Management, die Konfiguration, die Netzwerküberwachung und das Einstellen der Firewall-Policies durch einen Administrator („ISA server 2004 console“) hinsichtlich der Internetsicherheit seines Netzwerks, wobei das GUI u. a. in Figur 4.10 ein Dashboard zur Anzeige der Systemperformance („Allowed Packets“, „Dropped Packets“), Alarme, Logs und Reports und in Figur 4.12 eine Darstellung der Regeln umfasst (K6, S. 194 - 196, ebenso Merkmal M5.5 teilweise).
Damit ist es dem Fachmann nahegelegt, die Implementierung einer Anzeige des „customized threat reports“ aus der K5 in der dort vorhandenen GUI gemäß der Lehre der K6 – umfassend eine Darstellung von Netzwerkbedrohungen, diesen zugeordneten Regeln sowie der zugehörigen Rangordnung – umzusetzen.
Eine Möglichkeit hierfür zeigt die K6 bspw. bereits über den Reiter „Reports“ des Menüpunkts „Monitoring“ in Figur 4.10 Darüber hinaus stellt die K6 alternativ bspw. für ein Anzeigen der Netzwerkbedrohungen sowie der vom IHQ veranlassten Regeln den Menüpunkt „Firewall Policy“ gemäß Figur 4.12 zur Verfügung (Merkmale M5.5, M5.6.1, M5.6.2 teilweise).
Damit ergibt sich der Gegenstand des Patentanspruchs 1 aus dem Stand der Technik, wie er durch die Zusammenschau der Druckschriften K5 und K6 belegt ist, ohne dass es für den Fachmann hierfür einer erfinderischen Tätigkeit bedarf.
3.2 Die Druckschrift K9 betrifft den Microsoft ISA Server 2006 und beschreibt somit eine im Vergleich zum ISA Server 2004 gemäß K6 weiterentwickelte GUI mit „Dashboard“, „Monitoring“ und „Firewall Policy“. Die K9 zeigt bspw. eine Darstellung eines Logs mit IP-Adressen, Regeln und zugehörigen Aktionen (S. 604, Fig. 9.40) sowie wiederum die System Performance mit durchgelassenen und verworfenen Paketen (S. 568, Fig. 9.10).
Damit ist in gleicher Weise wie zur K5 und K6 ausgeführt dem Fachmann auch durch eine Zusammenschau der K5 mit der K9 der Gegenstand des Patentanspruchs 1 nahegelegt.
3.3 Gleiches gilt für die Zusammenschau der K5 jeweils mit einer der Druckschriften K7, K7a/NSM, K8 oder K15, welche im Speziellen die Konfiguration des Juniper NetScreen Firewalls, die Konfiguration des Check Point NGX Firewalls oder das Sourcefire 3D System umfassend ebenfalls im Wesentlichen ähnliche GUIs betreffen (vgl. K7, S. 665, S. 670; K7a/NSM, S. 736; K8, S. 126, S. 140 - 141; K15, S.281 - 282, S. 309, S. 1079).
Für den nebengeordneten Patentanspruch 15, der letztlich nur die Umsetzung der Verfahrensmerkmale für eine entsprechende Vorrichtung („apparatus“) beinhaltet, ergibt sich aus den gleichen Gründen wie für den Patentanspruch 1 kein auf einer erfinderischen Tätigkeit beruhender Gegenstand.
4. Da die Beklagte die abhängigen Unteransprüche nicht isoliert verteidigt, bedürfen diese keiner gesonderten Prüfung (vgl. BGH, Urteil vom 30. Juli 2024 – X ZR 105/22 – Spracherkennung in Kabelfernseh- und Videoverteildiensten). Mit dem sich als nicht patentfähig erweisenden Patentanspruch 1 nach erteilter Fassung des Streitpatents sind auch die darauf direkt oder indirekt rückbezogenen Unteransprüche 2 bis 14 der erteilten Fassung des Streitpatents für nichtig zu erklären, da die Beklagte weder geltend gemacht hat noch sonst ersichtlich ist, dass die zusätzlichen Merkmale dieser Patentansprüche zu einer anderen Beurteilung der Patentfähigkeit führen (BGH, Beschluss vom 27. Juni 2007, GRUR 2007, 862– Informationsübermittlungsverfahren II; Urteil vom 29. September 2011, X ZR 109/08– Sensoranordnung).
III. Zu den Hilfsanträgen
1. Hilfsantrag 1
Der Patentanspruch 1 in der Fassung gemäß Hilfsantrag 1 ist zwar zulässig, er ist jedoch nicht patentfähig, da sein Gegenstand nicht auf einer erfinderischen Tätigkeit beruht (Art. II § 6 Abs. 1 Nr. 1 IntPatÜG i. V. m. Art. 138 Abs. 1 Buchst. a), Art. 52, 56 EPÜ).
Der Verfahrensanspruch 1 nach Hilfsantrag 1 enthält gegenüber der erteilten Fassung gemäß Hauptantrag das nach Merkmal M5.6.2 neu hinzugefügte Merkmal M5.7_Hi1:
M5.7_Hi1 „and wherein the interface includes an element that when invoked by a user causes the user device to instruct the packet-filtering device to reconfigure the operator to prevent packets corresponding to the one or more criteria from continuing toward their destination.“
Das neue Merkmal M5.7_Hi1 gemäß Hilfsantrag 1 bildet das mit Patentanspruch 1 beanspruchte Verfahren dahingehend weiter aus, dass nunmehr das Interface auf dem Benutzergerät (aus Merkmal M5.5) ein (Einstell-)Element umfassen soll, womit der Benutzer den Paketfilter hinsichtlich des Operators einer Paketfilter-Regel (gemäß Merkmal M5.1) rekonfigurieren kann, um so Pakete auf ihrem Weg zum Ziel aufzuhalten, d. h. zu blockieren.
Der nebengeordnete Patentanspruch 15 wird über seinen ausdrücklichen Rückbezug auf Patentanspruch 1 in analoger Weise geändert.
Die mit dem Hilfsantrag 1 verbundene Änderung des Patentanspruchs 1 ist zulässig.
Der Fachmann entnimmt das den Gegenstand des Streitpatents beschränkende Merkmal M5.7_Hi1 sowohl dem Streitpatent als auch der ursprünglichen Offenbarung nahezu wortgleich (SP, Abs. [0005], [0033]; K4, Abs. [05], „The interface may comprise an element that when invoked by a user of the user device causes the user device to instruct the packet-filtering device to reconfigure the operator to prevent future packets corresponding to the criteria from continuing toward their respective destinations.“ und Abs. [40]).
Der Gegenstand des Patentanspruchs 1 gemäß Hilfsantrag 1 ist jedoch nicht patentfähig, da er sich in naheliegender Weise aus der Zusammenschau der K5 mit der Lehre einer der Druckschriften K6 bis K9 und K15 ergibt.
Die Druckschrift K6 lehrt ein Benutzerinterface der Microsoft ISA Server 2004 Console mit den entsprechenden Möglichkeiten zum Konfigurieren von Firewall Policies, wobei eine Liste der Regeln mit den entsprechenden Aktionen „allow“ und „deny“ angezeigt wird und mittels auswählbarer Werkzeuge („Tools“) die Regeln erzeugt, bearbeitet und gelöscht werden können (K6, S. 194 - 197, „If you select Firewall Policy, the middle pane displays a list of ﬁrewall policy rules, and the right pane contains tabs labeled Toolbox, Tasks, and Help, as shown in Figure 4.12.“).
Gleiches zeigt die Druckschrift K9, Kapitel 4, Seite 205 ff., exemplarisch für die Microsoft ISA 2006 Firewall beim Blockieren des MSN Messengers anhand Figur 4.28 auf Seite 248.
Auch die K7a/NSM, Seite 756 sowie die K7v, Seite 665 zeigen – diesmal für eine Juniper-Firewall – einen „Policy Manager“ mit einer Log-Ansicht und einem Verändern der Regeln und deren Operatoren.
Darüber hinaus lehrt die K8b, Seite 19, ein Nutzerinterface der CheckPoint Firewall mit äquivalenten Möglichkeiten für Regeländerungen. Schließlich offenbart auch die K15, Seite 281 - 282, die Sourcefire Log-Ansicht mit „Rule Actions“ zur Regeländerung (Merkmal M5.7_Hi1).
Die Ansicht der Beklagten, die Firewalls aus dem genannten Stand der Technik zeigten nur jeweils GUIs mit Einstellmöglichkeiten in einem separaten Interface, wohingegen gemäß Streitpatent, Figur 6b, ein Blockieren mittels der Blockieroption BZ 608 in demselben Interface vorgesehen sei, überzeugt nicht, da dies nicht der streitpatentgemäßen Lehre entspricht. Denn im Streitpatent, Figur 6c i. V. m. Absatz [0033], wird ebenfalls ein alternatives Ausführungsbeispiel mit mehreren Blockieroptionen („block option“) genau in einem solchen separaten Interface bzw. Pop-Up-Fenster BZ 610 beschrieben (ebenda: „Additionally or alternatively, when invoked, such a block option may cause host 110 to display another interface (e.g., an overlay, pop-up interface, or the like) associated with packet-filtering device 144. For example, referring to FIG. 6C, when invoked, block option 608 may cause host 110 to display interface 610. Interface 610 may comprise specific block options 612, 614, 616, and 618, modify option 620, and cancel option 622.“; Unterstreichungen hinzugefügt).
Hinsichtlich der unveränderten Merkmale des Patentanspruchs 1 wird auf die Ausführungen zum Hauptantrag verwiesen.
Für den nebengeordneten Patentanspruch 15 gemäß Hilfsantrag 1, welcher lediglich die Umsetzung der Verfahrensmerkmale in einer entsprechenden Vorrichtung („apparatus“) betrifft, gelten die Ausführungen gleichermaßen.
Da der Anspruchssatz gemäß Hilfsantrag 1 als Ganzes verteidigt wird, sind auch seine übrigen abhängigen Patentansprüche nicht rechtsbeständig.
2. Hilfsantrag 2
Der Patentanspruch 1 in der Fassung gemäß Hilfsantrag 2 ist zwar zulässig, er ist jedoch nicht patentfähig, da sein Gegenstand nicht auf einer erfinderischen Tätigkeit beruht.
Der Verfahrensanspruch 1 nach Hilfsantrag 2 enthält gegenüber der erteilten Fassung das an dessen Ende hinzugefügte Merkmal M5.7_Hi2, wobei Merkmal M5.7_Hi2 das aus Hilfsantrag 1 bekannte Merkmal M5.7_Hi1 ersetzt:
M5.7_Hi2: „and additionally displaying, on the interface, a listing in accordance with the ordering, wherein the listing comprises entries corresponding to the plurality of nerwork threats, and wherein the interface includes one or more block options that when invoked by a user cause the packet-filtering device to prevent packets corresponding to a network threat of the plurality of network threats from continuing toward their destination.“
Gemäß Merkmal M5.7_Hi2 soll das Interface auf dem Benutzergerät (aus Merkmal M5.5) ein Anzeigen der Netzwerkbedrohungen in der bestimmten Reihenfolge/ Rang umfassen, wobei jedoch eine Sortierung nicht explizit beansprucht ist, und es soll für den Benutzer eine Auswahl von einer oder mehreren Blockieroptionen bereitstellen, womit der Benutzer den Paketfilter veranlassen kann, Pakete basierend auf den Netzwerkbedrohungen auf ihrem Weg zum Ziel aufzuhalten. Hinsichtlich der Eingabe der Blockieroptionen genügt anspruchsgemäß bereits eine einzige Blockieroption, wofür schon das manuelle Sperren eines beliebigen einzelnen Hosts mittels einer Regel ausreicht.
Der nebengeordnete Patentanspruch 15 wird aufgrund des Rückbezugs in analoger Weise modifiziert.
Die mit dem Hilfsantrag 2 verbundenen Änderungen im Patentanspruch 1 sind zulässig.
Der Fachmann entnimmt das den Gegenstand des Streitpatents beschränkende geänderte Merkmal M5.7_Hi2 sowohl der Patentschrift als auch der ursprünglichen Offenbarung der K4. Diese beschreiben das geänderte Merkmal in Figur 6a und 6c („Threat Dashboard“ mit „Block Options“) i. V. m. mit dem Streitpatent, Absätze [0027], [0032] - [0034] bzw. mit der Druckschrift K4, Absätze [34], [39] - [41].
Der Gegenstand des Patentanspruchs 1 gemäß Hilfsantrag 2 ist nicht patentfähig, da er sich in naheliegender Weise aus der Lehre der Druckschrift K5 kombiniert mit einer der Druckschriften K6 bis K9 und K15 ergibt.
Die Anzeige der Netzwerkbedrohungen auf einem Benutzergerät als Liste mit Angabe eines jeweiligen Rangs gemäß dem ersten Teilmerkmal M5.7_Hi2 ist in der K5 durch die Anzeige des „comprehensive threat reports“ umfassend den „reputation score“ im IHQ bzw. durch die Visualisierung des „customized threat reports“ umfassend den „reputation indicator“ auf dem Dashboard für den (Netzwerk-)Manager bereits angelegt (K5, Fig. 3 i. V. m. S. 18, Z. 20 - 23 und Fig. 7 i. V. m. S. 26, Z. 21 - 27).
Die Druckschriften K6 bis K9 und K15 zeigen, wie eine GUI mit einem solchen Dashboard ausgestaltet werden kann.
Die K7 (S. 660), die K7v (S. 399) sowie die K7a/NSM (S. 364, 468 und 741) offenbaren einen Log-Viewer bzw. eine Regelansicht mit Angabe einer „Severity“ als Gefahrenlevel.
Darüber hinaus lehrt die K8b eine Regelansicht sowie einen entsprechenden Risikolevel („risk level“) für Applikationen (K8b, S. 18, zweiter Absatz, „To see all applications in a risk level, select the level from the Risk field in the toolbar.“, S. 28).
Auch die ISA Server 2004 Firewall-GUI in der Druckschrift K6 zeigt ein Dashboard mit „ordered list“-Regeln, umfassend u. a. eine „top-listed rule“ (K6, S. 197, erster Absatz, „The ﬁrewall rules represent an ordered list where parameters are ﬁrst compared to the top-listed rule.“).
Das entsprechende Dashboard der ISA Server 2006 Firewall-GUI findet sich in der K9 (S. 560).
Schließlich beschreibt die K15, Seiten 281 bis 282, eine Sortierung der Event-Anzeige mittels Sortierpfeil nach der Zeit bzw. nach der Priorität und eine Sortierung der Event-Tabelle anhand der Prioritäten bspw. in der Reihenfolge aufsteigender Verletzlichkeit in der dortigen GUI (K15, S. 309, „To sort the table in ascending vulnerability order, click Impact Flag again.“; Merkmal M5.7_Hi2 erster Teil).
Die im zweiten Teilmerkmal M5.7_Hi2 des Anspruchs 1 gemäß Hilfsantrag 2 umfasste einzige Blockieroption („one or more block options“) geht schon nicht über das im vorherigen Hilfsantrag 1 mit Merkmal M5.7_Hi1 beanspruchte einzelne Element hinaus bzw. entspricht diesem sogar im Wesentlichen (vgl. SP, Fig. 6b BZ 608, „BLOCK OPTIONS“ i. V. m. Abs. [0033], „For example, interface 600 may include block option 608, …“), womit auf die obige Argumentation zu den Druckschriften K6 bis K9 und K15 im Hilfsantrag 1 verwiesen wird (Merkmal M5.7_Hi2 zweiter Teil).
Hinsichtlich der übrigen, unveränderten Merkmale des Patentanspruchs 1 wird zudem auf die entsprechenden Ausführungen zum Hauptantrag verwiesen.
Für den nebengeordneten Patentanspruch 15 gemäß Hilfsantrag 2, welcher die Umsetzung der Verfahrensmerkmale in einer entsprechenden Vorrichtung („apparatus“) betrifft, gelten die obigen Ausführungen in gleicher Weise.
Da der Anspruchssatz gemäß Hilfsantrag 2 als Ganzes verteidigt wird, sind auch seine abhängigen Patentansprüche nicht rechtsbeständig.
3. Zum Hilfsantrag 3
Der Patentanspruch 1 in der Fassung gemäß Hilfsantrag 3 ist zwar zulässig, er ist jedoch nicht patentfähig, da sein Gegenstand nicht auf einer erfinderischen Tätigkeit beruht.
Ausgehend vom Hilfsantrag 2 wird im Patentanspruch 1 das Merkmal M5.7_Hi2 wie folgt zum Merkmal M5.7_Hi3 abgeändert (Änderungen im Vergleich zur Fassung gemäß Hilfsantrag 2 hervorgehoben):
M5.7_Hi3 and additionally displaying, on the interface, a listing in accordance with the ordering, wherein the listing comprises entries corresponding to the plurality of network threats, and wherein the interface includes one or more block options that, when invoked by a user cause reconfigure the packet-filtering device from allowing packets corresponding to a network threat of the plurality of network threats to preventing packets corresponding to a network threat of the plurality of network threats from continuing toward their destination.
Im Vergleich zum Hilfsantrag 2 betrifft der Gegenstand gemäß Hilfsantrag 3 nunmehr darüber hinaus ein Rekonfigurieren des Paketfilters von „allowing“ nach „preventing“.
Die mit dem Hilfsantrag 3 verbundenen Änderungen in Patentanspruch 1 sind zulässig.
Das den Gegenstand des Patentanspruchs 1 beschränkende Merkmal M5.7_Hi3 findet sich im Streitpatent, Absätze [0004] und [0005], und ist durch die Druckschrift K4, Absätze [04] und [05], ursprünglich offenbart.
Soweit die Klägerin eine Unklarheit dahingehend rügt, dass der Anspruchswortlaut mit einem bestimmten Artikel zu "the network threat of the plurality of network threats" versehen werden müsste, überzeugt dies den Senat nicht. Hier liegt nämlich einer der Fälle vor, bei dem ein Wechsel zwischen unbestimmten und bestimmten Artikel zu keiner patenthindernden inhaltlichen Abweichung des Streitgegenstandes führt (BGH, Urteil vom 12. September 2023, X ZR 65/21 – Tabakfaser).
Der Gegenstand des Patentanspruchs 1 gemäß Hilfsantrag 3 ist nicht patentfähig, da er sich in naheliegender Weise aus der Lehre der Druckschrift K5 kombiniert mit einer der Druckschriften K6 bis K9 und K15 ergibt.
Der Gegenstand gemäß Hilfsantrag 3 geht inhaltlich nicht wesentlich über denjenigen des Hilfsantrags 2 hinaus. Das Einstellen des Paketfilters mittels Regeln zum Durchlassen und/oder Blockieren von Paketen ist die ureigenste Aufgabe eines Paketfilters bzw. einer Firewall und somit eine rein fachübliche Massnahme. Ergänzend hierzu wird Offenbarungsstellen in den Druckschriften K6 bis K9 und K15 verwiesen, welche das Rekonfigurieren des Paketfilters mit einer Policy für bestimmte Pakete von „allowing“ nach „preventing“ nachweisen (vgl. Ausführungen zu Merkmal M5.7_Hi1 in Abschnitt III. 1.; Merkmal M5.7_Hi3).
4. Zum Hilfsantrag 4b
4.1 Der Gegenstand des mit dem Hilfsantrag 4b zulässig verteidigten Patentanspruchs 1 erweist sich gegenüber dem im Verfahren befindlichen Stand der Technik als neu und beruht auch auf einer erfinderischen Tätigkeit.
Der Verfahrensanspruch 1 nach Hilfsantrag 4b umfasst das geänderte Merkmal M5.7_Hi4b und fügt zusätzlich das neue Merkmal M5.8_Hi4b im Anschluss an dieses hinzu (Änderungen zum Merkmal M5.7_Hi3 hervorgehoben):
M5.7_Hi4b: „and additionally displaying, on the interface, a listing in accordance with the ordering, wherein the listing comprises entries corresponding to the plurality of network threats, and wherein the interface includes one or more block options that, when invoked by a user reconfigure the packet-filtering device from allowing packets corresponding to the network threat of the plurality of network threats to preventing packets corresponding to the network threat of the plurality of network threats from continuing toward their destination,“
M5.8_Hi4b: „wherein invoking the one or more block options causes displaying of another interface including specific block options including blocking packets corresponding to the network threat destined for or originating from a host in an internal network, blocking packets corresponding to the network threat destined for or originating from an internal host that has generated or received packets associated with the network threat, blocking packets received from an internal host that has generated or received packets associated with the network threat and destined for an internal host, and blocking packets received from an internal host that has generated or received packets associated with the network threat and destined for an external host.“
Das Merkmal M5.7_Hi4b entspricht inhaltlich dem Merkmal M5.7_Hi3, wobei der dort von der Klägerin gerügten Unklarheit hinsichtlich des unbestimmten Artikels durch Verwendung des bestimmten Artikels bei „the network threat“ begegnet wird.
Mit Merkmal M5.8_Hi4b wird beansprucht, dass bei der Konfiguration des Paketfilters durch den Benutzer ein weiteres Interface aktiviert wird, wobei dort zumindest vier explizit genannte spezifische Blockieroptionen zur Auswahl für den Benutzer angezeigt werden. Die Blockieroptionen – gültig für mit einer Netzwerkbedrohung assoziierte Pakete – umfassen u. a. („including“, d. h. nicht abschliessend) das komplette Blockieren des zu schützenden Netzwerks, das vollständige Blockieren eines lokalen Hosts, das Blockieren des Empfangens durch den lokalen Host sowie das Blockieren des Sendens durch den lokalen Host („Block Threat Network“, „Block Threat Lokal Host“, „Block Local Host Internal“, „Block Local Host External“).
Die mit dem Hilfsantrag 4b verbundenen Änderungen im Patentanspruch 1 sind zulässig. Sie beschränken seinen Gegenstand und der Fachmann entnimmt seine weitere Ausgestaltung mittels Merkmal M5.8_Hi4b – umfassend die vier genannten Blockieroptionen – sowohl der ursprünglichen Offenbarung als auch der Patentschrift in Figur 6c BZ 612, BZ 614, BZ 616, BZ 618 i.V.m. der K4, Absatz [41] bzw. dem Streitpatent, Absatz [0034].
Dem Gegenstand von Patentanspruch 1 in der Fassung gemäß Hilfsantrag 4b steht der Nichtigkeitsgrund der fehlenden Patentfähigkeit nicht entgegen, da das unter Schutz gestellte Verfahren gegenüber dem im Nichtigkeitsverfahren entgegengehaltenen Stand der Technik auf einer erfinderischen Tätigkeit beruht.
Der genannte Stand der Technik offenbart weder im Einzelnen noch in der Zusammenschau, dass dem Benutzer eine GUI mit einem Auswahlmenü unterschiedlicher Blockieroptionen bereitgestellt wird (Merkmal M5.8_Hi4b fehlt). Gegenteiliges wird auch von der Klägerin nicht vorgetragen. Die Argumentation der Klägerin, dass die vier beanspruchten Optionen jedoch den typischen Optionen einer Firewall entsprächen und bspw. bereits in der K7a (S. 756, „Jump to Policy“ i.V.m. S. 433, zweiter Absatz, „A firewall rule must contain the following elements: …“) sämtliche Eingabemöglichkeiten und Bausteine zum spezifischen Erstellen einer Regel entsprechend den Optionen angegeben seien, so dass vom Fachmann nur noch die naheliegende graphische Ausgestaltung der GUI zu implementieren sei, greift nicht durch. Es fehlen nämlich im gesamten genannten Stand der Technik, welcher neben der K5 die kompletten Benutzerhandbücher der zum Prioritätsdatum gängigsten Firewalls im Markt umfasst, bereits jegliche Hinweise und Anregungen für den Fachmann, diese bekannten Firewalls in Richtung der mit Merkmal M5.8_Hi4 beanspruchten Lehre weiterzuentwickeln.
Zwar werden in der K7, Seite 433, für die Juniper-Firewall die für eine Regel benötigten Einzelkomponenten gelistet. Folgt der Fachmann jedoch dem angegebenen Verweis auf Seite 441, findet er dort und auf den folgenden 17 Seiten die umfangreiche Anleitung zum Konfigurieren einer Regel durch Zusammenstellung der Einzelkomponenten mit allen potentiellen Kombinationsmöglichkeiten („Configuring Firewall Rules“). Eine streitpatentgemäße, einfache Strategie für eine Konfiguration einer Regel durch Auswahl aus einer überschaubaren Menge vorgefertigter Blockieroptionen ist dort für den Fachmann nicht zu entnehmen und auch nicht angeregt.
Dies gilt im gegebenen Kontext auch für die Bewertung der Druckschriften K8 und K15.
Hinsichtlich der K8a, Seite 18, sowie K15, Seite 400, wurde von der Klägerin ähnlich wie zur K7 vorgetragen, jedoch vermag der Senat diesen Fundstellen nicht wie vorgetragen eine Auswahl von anspruchsgemäßen Blockieroptionen zu entnehmen.
Zu den übrigen im Verfahren genannten Druckschriften hat die Klägerin hinsichtlich der erfinderischen Tätigkeit des Hilfsantrags 4b nicht weiter substantiiert vorgetragen. Auch vermag der Senat nicht zu erkennen, dass diese Druckschriften im Einzelnen oder in Kombination zum Gegenstand des Patentanspruchs 1 gemäß Hilfsantrag 4b führen.
Das Merkmal M5.8_Hi4b geht jedenfalls über eine reine visuelle Informationswiedergabe – oben hinsichtlich des ursprünglichen Teilmerkmals in Merkmal M5.5 offengelassen – hinaus und dient der Lösung eines technischen Problems mit technischen Mitteln. Denn die Verfahrensschritte bzw. Maßnahmen dienen der effizienten (Re-)Konfiguration des Paketfilters durch den Benutzer (vgl. ebenso Merkmal M5.7_Hi4b). Dies ermöglicht es dem Benutzer, Gefahren in seinem zu schützenden Netzwerk abzuwehren, indem am Benutzergerät die mit einer bestimmten Netzwerkbedrohung assoziierten Pakete schnell und auf einfache Art und Weise durch das Auswählen einer der angezeigten Blockieroptionen von einer Gefährdung des Netzwerks abgehalten werden.
4.2 Entsprechendes gilt für den nebengeordneten Patentanspruch 15, welcher bereits durch seinen Rückbezug auf den patentfähigen Patentanspruch 1 rechtsbeständig ist. Gegenteiliges vermag die Klägerin nicht aufzuzeigen.
4.3 Hinsichtlich der ebenfalls angegriffenen Unteransprüche 2 bis 14, welche vorteilhafte Ausgestaltungen des Erfindungsgegenstands betreffen, gelten auch die vorstehenden, den Patentanspruch 1 betreffenden Ausführungen entsprechend. Die Unteransprüche sind ebenfalls bereits durch ihren unmittelbaren oder mittelbaren Rückbezug auf den patentfähigen Patentanspruch 1 rechtsbeständig. Auch diesbezüglich hat die Klägerin nichts Gegenteiliges vorgetragen.
B.
Die Kostenentscheidung beruht auf § 84 Abs. 2 PatG i.V.m. § 92 Abs. 1 Satz 1 ZPO.
Die Entscheidung über die vorläufige Vollstreckbarkeit folgt aus § 99 Abs. 1 PatG i.V.m. § 709 Satz 1 und 2 ZPO.

Rechtsmittelbelehrung:

Zitierte Normen: § 6 Abs. 1 Nr. 1 IntPatÜG
§ 6 Abs. 1
    Nr. 3 IntPatÜG
§ 6 Abs.
    1 Nr. 1 IntPatÜG
§ 84 Abs. 2 PatG
§ 92 Abs. 1 Satz 1 ZPO
§ 99 Abs. 1 PatG
§ 709 Satz 1 und 2 ZPO

Zitierte Entscheidungen: GRUR 2007, 862
5 Ni 23/22
X ZR 105/22
X ZR 109/08