70 Zum Patentanspruch 1

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

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

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

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

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

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

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

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

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

80 · M5.3: Die Paketfiltervorrichtung generiert basierend auf dem Protokolleintrag gemäß M5.2 zusätzliche Daten hinsichtlich des auf das Paket angewendeten Operators.

81 · 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.

82 · 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.

83 · 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.

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

85 · 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.

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

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

88 Zum Patentanspruch 15

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

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

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

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

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

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

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

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

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

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

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

110 Der Fachmann entnimmt der K5 somit folgende Lehre:

111 Die K5 betrifft entsprechend Merkmal M1 ein Verfahren/”Method” (K5, Anspruch 1).

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

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

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

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

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

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

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

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

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

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

122 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;”).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

143 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 flow pattern for information through a basic single-firewall setup. This type of traffic 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 define the rule base and configure the firewall as defined above, in addition to other industry standard properties as appropriate.“; S. 184, „The goal is to provide ongoing and real-time updates and configuration advisories for defenses and security policies. … If you subscribe to the SmartDefense Services, new filters and options are added dynamically to the lists through automatic updates.“, Unterstreichungen hinzugefügt; Merkmal M2 teilweise).

144 Die Firewall gemäß K6 stellt ebenfalls ein Protokollieren des durchgehenden und blockierten Datenverkehrs entsprechend der Firewallregeln bereit (K6, S. 17, zweiter Absatz, „The firewall should provide extensive logging of traffic passed and blocked.“, Merkmal M5.5 teilweise).

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

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

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

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

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

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

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

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

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

204 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):

205 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,“

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

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

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

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

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

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

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

213 Dies gilt im gegebenen Kontext auch für die Bewertung der Druckschriften K8 und K15.

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

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

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

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

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