BPatG 03.05.2018 - 6 Ni 54/16 (EP

Die Beklagte ist eingetragene Inhaberin des aufgrund der internationalen Anmeldung PCT/DE1998/003807 vom 28. Dezember 1998, die als WO 99/37101 A1 am 22. Juli 1999 veröffentlicht wurde, unter Inanspruchnahme der Priorität aus der deutschen Anmeldung DE 198 01 784 vom 19. Januar 1998 erteilten europäischen Patents 1 050 170 (Streitpatent).

Das Streitpatent trägt die Bezeichnung

„VERFAHREN UND KOMMUNIKATIONSSYSTEM ZUR BEHANDLUNG VON ALARMEN DURCH EIN MEHRERE MANAGEMENTEBENEN AUFWEISENDES MANAGEMENTNETZ“

und umfasst in der geltenden Fassung 19 Patentansprüche.

Mit ihrer am 8. Juli 2016 eingereichten und mit Schriftsatz vom 13. April 2018 erweiterten Nichtigkeitsklage begehrt die Klägerin die Nichtigerklärung des Streitpatents im Umfang der Ansprüche 1, 2, 5, 12, 13 und 16. Hintergrund der Nichtigkeitsklage ist ein zwischen den Parteien vor dem Landgericht D… (Az 4b O 56/16) anhängiger Rechtsstreit wegen angeblicher Verletzung des Streitpatents, in welchem das Landgericht D… aufgrund der mündlichen Verhandlung vom 22. Februar 2018 ein klageabweisendes, noch nicht rechtskräftiges Urteil erlassen hat.

Die angegriffenen erteilten unabhängigen Patentansprüche 1 und 12 lauten in der Verfahrenssprache wie folgt:

1. Verfahren zur Behandlung von Alarmen in einem Kommunikationssystem durch ein mehrere Managementebenen (A, B, C) aufweisendes Managementnetz, wobei für einen Alarmdatenabgleich zwischen einem Agent (AG) einer Managementebene (B, C) und zumindest einem Manager (MA1, MA2) einer nächsthöheren Managementebene (A, B) die Alarmdaten aktiver Alarme übertragen werden, bei dem

 – von dem Manager (MA1, MA2) jeweils eine oder mehrere Anforderungsnachrichten (repAA) zum Übermitteln der Alarmdaten an den Agent (AG) gesendet werden,

 – von dem Manager (MA1, MA2) Korrelationsinformationen (alaAH, aliNl) für eine Zuordnung der jeweiligen Anforderung zu den vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten empfangen werden, und

 – von dem Manager (MA1, MA2) der Alarmdatenabgleich abhängig von zumindest einem zum Agent (AG) gesendeten Parameter (par) gesteuert wird.

12. Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen (A, B, C) aufweisendes Managementnetz, wobei für einen Alarmdatenabgleich zwischen einem Agent (AG) einer Managementebene (z. B. B) und zumindest einem Manager (MA1, MA2) einer nächsthöheren Managementebene (z. B. A) die Alarmdaten aktiver Alarme übertragen werden,

 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für das Senden einer oder mehrerer Anforderungsnachrichten (repAA) zum Übermitteln der Alarmdaten an den Agent (OMC1), und

 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für das Empfangen von Korrelationsinformationen (alaAH, aliNl) für eine Zuordnung der jeweiligen Anforderung zu den vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten, und

 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für eine Steuerung des Alarmdatenabgleich abhängig von zumindest einem zum Agent (AG) gesendeten Parameter (par).

Die nach der Klageerweiterung nunmehr ebenfalls streitgegenständlichen weiteren Patentansprüche 2, 5, 13 und 16 sind jeweils auf einen der vorgenannten Patentansprüche unmittelbar oder mittelbar rückbezogen.

Die Klägerin ist der Ansicht, dass das Streitpatent in seiner erteilten Fassung mangels Patentfähigkeit im angegriffenen Umfang für nichtig zu erklären sei und die Beklagte es im angegriffenen Umfang auch nicht mit einer der beschränkten Fassungen nach den Hilfsanträgen verteidigen kann, da diesen die Nichtigkeitsgründe der fehlenden Patentfähigkeit und der unzulässigen Erweiterung entgegenstehe. Ihre Auffassung stützt sie dabei auf die Druckschriften (Nummerierung und Kurzzeichen nach Klageschriftsatz):

NiK 1a Auszüge aus dem GSM Standardisierungsdokument Draft EN 301 251 V4.1.1 (1997-08); Digital cellular telecommunications system (Phase 2); Fault management of the Base Station System (BSS) (GSM 12.11 version 4.1.1).

NiK 1a’ Auszüge aus dem GSM Standardisierungsdokument EN 301 251 V4.1.2 (1997-12); Digital cellular telecommunications system (Phase 2); Fault management of the Base Station System (BSS) (GSM 12.11 version 4.1.2).

NiK 1b Auszüge aus der ITU-T Recommendation Q.821 (03/93); Stage 2 and Stage 3 Description for the Q3 Interface - Alarm Surveillance.

NiK 1c Auszüge aus der ITU-T Recommendation X.710 (10/97); Information technology – Opens Systems Interconnection – Common Management Information Service.

NiK 1c’ Auszüge aus der ITU-T/CCITT Recommendation X.710 (03/91); Common Management Information Service Definition for CCITT Applications.

NiK 1d Auszüge aus der ITU-T/CCITT Recommendation X.733 Information technology – Opens Systems Interconnection – Systems Management: Alarm Reporting Function.

Die Klägerin beantragt,

das europäische Patent 1 050 170 mit Wirkung für das Hoheitsgebiet der Bundesrepublik Deutschland im Umfang der Ansprüche 1, 2, 5, 12, 13 und 16 für nichtig zu erklären.

Die Beklagte beantragt,

die Klage abzuweisen,

hilfsweise die Klage abzuweisen, soweit sie sich auch gegen eine Fassung nach den Hilfsanträgen 0 vom 3. Mai 2018, 1 bis 3 vom 9. März 2018 und 4 vom 3. Mai 2018, in dieser Reihenfolge, richtet.

Die Ansprüche 1 und 12 nach den Hilfsanträgen 1 bis 3, welche die Beklagte mit Schriftsatz vom 9. März 2018 zur Akte gereicht hatte, sowie der Hilfsanträge 0 und 4, welche die Beklagte in der mündlichen Verhandlung vorgelegt hat, lauten wie folgt (Änderungen gegenüber der erteilten Fassung unterstrichen):

Hilfsantrag 0

1. Verfahren zur Behandlung von Alarmen in einem Kommunikationssystem durch ein mehrere Managementebenen (A, B, C) aufweisendes Managementnetz, wobei für einen Alarmdatenabgleich zwischen einem Agent (AG) einer Managementebene (B, C) und zumindest einem Manager (MA1, MA2) einer nächsthöheren Managementebene (A, B) die Alarmdaten aktiver Alarme übertragen werden, bei dem

 – von dem Manager (MA1, MA2) jeweils eine oder mehrere Anforderungsnachrichten (repAA) zum Übermitteln der Alarmdaten an den Agent (AG) gesendet werden, wobei in einem Nachrichtenfeld der Anforderungsnachricht (repAA) eine vom Manager (MA1, MA2) definierte Korrelationsinformation (alaAH) mitgesendet wird,

 – von dem Manager (MA1, MA2) Korrelationsinformationen (alaAH, aliNl) für eine Zuordnung der jeweiligen Anforderung zu den vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten empfangen werden, wobei die Korrelationsinformationen (alaAH, aliNI) die Korrelationsinformation (alaAH) und eine weitere Korrelationsinformation (aliNI) aufweisen, die beide gemeinsam in einer vom Agent (AG) gesendeten Nachricht (staAA) enthalten sind, und die vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten jeweils die weitere Korrelationsinformation (aliNI) aufweisen, und

 – von dem Manager (MA1, MA2) der Alarmdatenabgleich abhängig von zumindest einem zum Agent (AG) gesendeten Parameter (par) gesteuert wird, wobei in den auf die Nachricht (staAA) folgenden Nachrichten (alNO) die Alarmdaten ausgewählter Alarme unter Verwendung eines M-EVENT-REPORT Service gesendet werden.

12. Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen (A, B, C) aufweisendes Managementnetz, wobei für einen Alarmdatenabgleich zwischen einem Agent (AG) einer Managementebene (z. B. B) und zumindest einem Manager (MA1, MA2) einer nächsthöheren Managementebene (z. B. A) die Alarmdaten aktiver Alarme übertragen werden,

 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für das Senden einer oder mehrerer Anforderungsnachrichten (repAA) zum Übermitteln der Alarmdaten an den Agent (AG), wobei in einem Nachrichtenfeld der Anforderungsnachricht (repAA) eine vom Manager (MA1, MA2) definierte Korrelationsinformation (alaAH) enthalten ist, und

 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für das Empfangen von Korrelationsinformationen (alaAH, aliNl) für eine Zuordnung der jeweiligen Anforderung zu den vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten, wobei die Korrelationsinformationen (alaAH, aliNI) die Korrelationsinformation (alaAH) und eine weitere Korrelationsinformation (aliNI) aufweisen, die beide gemeinsam in einer vom Agent (AG) gesendeten Nachricht (staAA) enthalten sind, und die vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten jeweils die weitere Korrelationsinformation (aliNI) aufweisen, und

 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für eine Steuerung des Alarmdatenabgleich abhängig von zumindest einem zum Agent (AG) gesendeten Parameter (par), wobei in den auf die Nachricht (staAA) folgenden Nachrichten (alNO) die Alarmdaten ausgewählter Alarme unter Verwendung eines M-EVENT-REPORT Service gesendet werden.

Hilfsantrag 1

1. Verfahren zur Behandlung von Alarmen in einem Kommunikationssystem durch ein mehrere Managementebenen (A, B, C) aufweisendes Managementnetz, wobei für einen Alarmdatenabgleich zwischen einem Agent (AG) einer Managementebene (B, C) und zumindest einem Manager (MA1, MA2) einer nächsthöheren Managementebene (A, B) die Alarmdaten aktiver Alarme übertragen werden, bei dem

 – von dem Manager (MA1, MA2) jeweils eine oder mehrere Anforderungsnachrichten (repAA) zum Übermitteln der Alarmdaten an den Agent (AG) gesendet werden, wobei in einem Nachrichtenfeld der Anforderungsnachricht (repAA) eine vom Manager (MA1, MA2) definierte Korrelationsinformation (alaAH) mitgesendet wird,

 – von dem Manager (MA1, MA2) Korrelationsinformationen (alaAH, aliNl) für eine Zuordnung der jeweiligen Anforderung zu den vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten empfangen werden, wobei die Korrelationsinformationen (alaAH, aliNI) die Korrelationsinformation (alaAH) und eine weitere Korrelationsinformation (aliNI) aufweisen, und die vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten jeweils die weitere Korrelationsinformation (aliNI) aufweisen, und

 – von dem Manager (MA1, MA2) der Alarmdatenabgleich abhängig von zumindest einem zum Agent (AG) gesendeten Parameter (par) gesteuert wird.

12. Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen (A, B, C) aufweisendes Managementnetz, wobei für einen Alarmdatenabgleich zwischen einem Agent (AG) einer Managementebene (z. B. B) und zumindest einem Manager (MA1, MA2) einer nächsthöheren Managementebene (z. B. A) die Alarmdaten aktiver Alarme übertragen werden,

 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für das Senden einer oder mehrerer Anforderungsnachrichten (repAA) zum Übermitteln der Alarmdaten an den Agent (AG), wobei in einem Nachrichtenfeld der Anforderungsnachricht (repAA) eine vom Manager (MA1, MA2) definierte Korrelationsinformation (alaAH) enthalten ist, und

 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für das Empfangen von Korrelationsinformationen (alaAH, aliNl) für eine Zuordnung der jeweiligen Anforderung zu den vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten, wobei die Korrelationsinformationen (alaAH, aliNI) die Korrelationsinformation (alaAH) und eine weitere Korrelationsinformation (aliNI) aufweisen, und die vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten jeweils die weitere Korrelationsinformation (aliNI) aufweisen, und

 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für eine Steuerung des Alarmdatenabgleich abhängig von zumindest einem zum Agent (AG) gesendeten Parameter (par).

Hilfsantrag 2

1. Verfahren zur Behandlung von Alarmen in einem Kommunikationssystem durch ein mehrere Managementebenen (A, B, C) aufweisendes Managementnetz, wobei für einen Alarmdatenabgleich zwischen einem Agent (AG) einer Managementebene (B, C) und zumindest einem Manager (MA1, MA2) einer nächsthöheren Managementebene (A, B) die Alarmdaten aktiver Alarme übertragen werden, bei dem

 – von dem Manager (MA1, MA2) jeweils eine oder mehrere Anforderungsnachrichten (repAA) zum Übermitteln der Alarmdaten an den Agent (AG) gesendet werden, wobei in einem Nachrichtenfeld der Anforderungsnachricht (repAA) eine vom Manager (MA1, MA2) definierte Korrelationsinformation (alaAH) mitgesendet wird,

 – von dem Manager (MA1, MA2) Korrelationsinformationen (alaAH, aliNl) für eine Zuordnung der jeweiligen Anforderung zu den vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten empfangen werden, wobei die Korrelationsinformationen (alaAH, aliNI) die Korrelationsinformation (alaAH) und eine weitere Korrelationsinformation (aliNI) aufweisen, die beide gemeinsam in einer vom Agent (AG) gesendeten Nachricht (staAA) enthalten sind, und die vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten jeweils die weitere Korrelationsinformation (aliNI) aufweisen, und

 – von dem Manager (MA1, MA2) der Alarmdatenabgleich abhängig von zumindest einem zum Agent (AG) gesendeten Parameter (par) gesteuert wird.

12. Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen (A, B, C) aufweisendes Managementnetz, wobei für einen Alarmdatenabgleich zwischen einem Agent (AG) einer Managementebene (z. B. B) und zumindest einem Manager (MA1, MA2) einer nächsthöheren Managementebene (z. B. A) die Alarmdaten aktiver Alarme übertragen werden,

 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für das Senden einer oder mehrerer Anforderungsnachrichten (repAA) zum Übermitteln der Alarmdaten an den Agent (AG), wobei in einem Nachrichtenfeld der Anforderungsnachricht (repAA) eine vom Manager (MA1, MA2) definierte Korrelationsinformation (alaAH) enthalten ist, und

 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für das Empfangen von Korrelationsinformationen (alaAH, aliNl) für eine Zuordnung der jeweiligen Anforderung zu den vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten, wobei die Korrelationsinformationen (alaAH, aliNI) die Korrelationsinformation (alaAH) und eine weitere Korrelationsinformation (aliNI) aufweisen, die beide gemeinsam in einer vom Agent (AG) gesendeten Nachricht (staAA) enthalten sind, und die vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten jeweils die weitere Korrelationsinformation (aliNI) aufweisen, und

 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für eine Steuerung des Alarmdatenabgleich abhängig von zumindest einem zum Agent (AG) gesendeten Parameter (par).

Hilfsantrag 3

1. Verfahren zur Behandlung von Alarmen in einem Kommunikationssystem durch ein mehrere Managementebenen (A, B, C) aufweisendes Managementnetz, wobei für einen Alarmdatenabgleich zwischen einem Agent (AG) einer Managementebene (B, C) und zumindest einem Manager (MA1, MA2) einer nächsthöheren Managementebene (A, B) die Alarmdaten aktiver Alarme übertragen werden, bei dem

 – von dem Manager (MA1, MA2) jeweils eine oder mehrere Anforderungsnachrichten (repAA) zum Übermitteln der Alarmdaten an den Agent (AG) gesendet werden, wobei in einem Nachrichtenfeld der Anforderungsnachricht (repAA) eine vom Manager (MA1, MA2) definierte Korrelationsinformation (alaAH) mitgesendet wird,

 – von dem Manager (MA1, MA2) Korrelationsinformationen (alaAH, aliNl) für eine Zuordnung der jeweiligen Anforderung zu den vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten empfangen werden, wobei die Korrelationsinformationen (alaAH, aliNI) die Korrelationsinformation (alaAH) und eine weitere Korrelationsinformation (aliNI) aufweisen, die beide gemeinsam in einer vom Agent (AG) gesendeten Nachricht (staAA) enthalten sind, wobei jede der Korrelationsinformationen (alaAH, aliNI) in einem jeweiligen Nachrichtenfeld der Nachricht (staAA) enthalten ist, und die vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten jeweils die weitere Korrelationsinformation (aliNI) aufweisen, und

 – von dem Manager (MA1, MA2) der Alarmdatenabgleich abhängig von zumindest einem zum Agent (AG) gesendeten Parameter (par) gesteuert wird.

12. Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen (A, B, C) aufweisendes Managementnetz, wobei für einen Alarmdatenabgleich zwischen einem Agent (AG) einer Managementebene (z. B. B) und zumindest einem Manager (MA1, MA2) einer nächsthöheren Managementebene (z. B. A) die Alarmdaten aktiver Alarme übertragen werden,

 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für das Senden einer oder mehrerer Anforderungsnachrichten (repAA) zum Übermitteln der Alarmdaten an den Agent (AG), wobei in einem Nachrichtenfeld der Anforderungsnachricht (repAA) eine vom Manager (MA1, MA2) definierte Korrelationsinformation (alaAH) enthalten ist, und

 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für das Empfangen von Korrelationsinformationen (alaAH, aliNl) für eine Zuordnung der jeweiligen Anforderung zu den vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten, wobei die Korrelationsinformationen (alaAH, aliNI) die Korrelationsinformation (alaAH) und eine weitere Korrelationsinformation (aliNI) aufweisen, die beide gemeinsam in einer vom Agent (AG) gesendeten Nachricht (staAA) enthalten sind, wobei jede der Korrelationsinformationen (alaAH, aliNI) in einem jeweiligen Nachrichtenfeld der Nachricht (staAA) enthalten ist, und die vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten jeweils die weitere Korrelationsinformation (aliNI) aufweisen, und

 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für eine Steuerung des Alarmdatenabgleich abhängig von zumindest einem zum Agent (AG) gesendeten Parameter (par).

Hilfsantrag 4

1. Verfahren zur Behandlung von Alarmen in einem Kommunikationssystem durch ein mehrere Managementebenen (A, B, C) aufweisendes Managementnetz, wobei für einen Alarmdatenabgleich zwischen einem Agent (AG) einer Managementebene (B, C) und zumindest einem Manager (MA1, MA2) einer nächsthöheren Managementebene (A, B) die Alarmdaten aktiver Alarme übertragen werden, bei dem

 – von dem Manager (MA1, MA2) jeweils eine oder mehrere Anforderungsnachrichten (repAA) zum Übermitteln der Alarmdaten an den Agent (AG) gesendet werden, wobei in einem Nachrichtenfeld der Anforderungsnachricht (repAA) eine vom Manager (MA1, MA2) definierte Korrelationsinformation (alaAH) mitgesendet wird,

 – von dem Manager (MA1, MA2) Korrelationsinformationen (alaAH, aliNl) für eine Zuordnung der jeweiligen Anforderung zu den vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten empfangen werden, wobei die Korrelationsinformationen (alaAH, aliNI) die Korrelationsinformation (alaAH) und eine weitere Korrelationsinformation (aliNI) aufweisen, die beide gemeinsam in einer vom Agent (AG) gesendeten Nachricht (staAA) enthalten sind, wobei jede der Korrelationsinformationen (alaAH, aliNI) in einem jeweiligen Nachrichtenfeld der Nachricht (staAA) enthalten ist, und die vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten jeweils die weitere Korrelationsinformation (aliNI) aufweisen,

und

 – von dem Manager (MA1, MA2) der Alarmdatenabgleich abhängig von zumindest einem zum Agent (AG) gesendeten Parameter (par) gesteuert wird, wobei in den auf die Nachricht (staAA) folgenden Nachrichten (alNO) die Alarmdaten ausgewählter Alarme unter Verwendung eines M-EVENT-REPORT Service gesendet werden.

12. Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen (A, B, C) aufweisendes Managementnetz, wobei für einen Alarmdatenabgleich zwischen einem Agent (AG) einer Managementebene (z. B. B) und zumindest einem Manager (MA1, MA2) einer nächsthöheren Managementebene (z. B. A) die Alarmdaten aktiver Alarme übertragen werden,

 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für das Senden einer oder mehrerer Anforderungsnachrichten (repAA) zum Übermitteln der Alarmdaten an den Agent (AG), wobei in einem Nachrichtenfeld der Anforderungsnachricht (repAA) eine vom Manager (MA1, MA2) definierte Korrelationsinformation (alaAH) enthalten ist, und

 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für das Empfangen von Korrelationsinformationen (alaAH, aliNl) für eine Zuordnung der jeweiligen Anforderung zu den vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten, wobei die Korrelationsinformationen (alaAH, aliNI) die Korrelationsinformation (alaAH) und eine weitere Korrelationsinformation (aliNI) aufweisen, die beide gemeinsam in einer vom Agent (AG) gesendeten Nachricht (staAA) enthalten sind, wobei jede der Korrelationsinformationen (alaAH, aliNI) in einem jeweiligen Nachrichtenfeld der Nachricht (staAA) enthalten ist, und die vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten jeweils die weitere Korrelationsinformation (aliNI) aufweisen, und

 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für eine Steuerung des Alarmdatenabgleich abhängig von zumindest einem zum Agent (AG) gesendeten Parameter (par), wobei in den auf die Nachricht (staAA) folgenden Nachrichten (alNO) die Alarmdaten ausgewählter Alarme unter Verwendung eines M-EVENT-REPORT Service gesendet werden.

Die Beklagte tritt der Argumentation der Klägerin entgegen und hält den Gegenstand des Streitpatents in der erteilten Fassung, hilfsweise in einer der Fassungen nach den Hilfsanträgen für schutzfähig.

Der Senat hat den Parteien einen qualifizierten Hinweis vom 12. Januar 2018 zugeleitet und hierin Fristen zur Stellungnahme auf den Hinweis und auf etwaiges Vorbringen der jeweiligen Gegenpartei gesetzt.

Wegen der weiteren Einzelheiten wird auf den Akteninhalt verwiesen.

A.

Zur Zulässigkeit der Klage

Die Klage ist zulässig. Dies gilt auch, soweit mit Schriftsatz vom 13. April 2018 die Klage auf die Nichtigerklärung auch der Patentansprüche 2, 5, 13 und 16 erweitert wurde. Zwar handelt es sich hierbei nicht nur um eine Klageerweiterung i. S. d. § 264 Nr. 2 ZPO, sondern nach der Rechtsprechung des Bundesgerichtshofs um eine Klageänderung nach § 263 ZPO (vgl. hierzu BGH, Urteil vom 20. März 2012 - X ZR 58/09, Rn 43 [juris], sowie Urteil vom 19. Juli 2011 – X ZR 25/09, Rn. 9 [juris]; Busse/Keukenschrijver, PatG, 8. Aufl., § 82 Rn. 32; Schulte/Voit, PatG, 10. Aufl., § 81 Rn. 70, jeweils m. w. N.), welcher die Beklagte nicht zugestimmt hat. Die erweiterte Klage ist aber nach § 99 Abs. 1 PatG i. V. m. § 263 ZPO als sachdienlich zuzulassen, weil hierdurch zwischen den Parteien vor dem Hintergrund der anhängigen Verletzungsklage ein sich aus dem Verletzungsverfahren, insbesondere aus den Ausführungen im Urteil des Landgerichts Düsseldorf vom 22. Februar 2018, möglicherweise ergebender weiterer Streit über die Schutzfähigkeit des Streitpatents im angegriffenen Umfang vermieden wird.

Obwohl diese Klageerweiterung erst mit Schriftsatz vom 13. April 2018 und damit nach der am 9. April 2018 abgelaufenen letzten Stellungnahmefrist auf den Hinweis des Senats vom 12. Januar 2018 eingereicht worden ist, ist sie nicht nach § 83 Abs. 4 Satz 1 PatG als verspätet zurückzuweisen, weil die Voraussetzungen hierfür nicht vorliegen.

Denn zum einen hat die Klägerin die erst zu diesem Zeitpunkt eingereichte Klageerweiterung dadurch genügend entschuldigt (§ 83 Abs. 4 Satz 1 Nr. 2 PatG), dass sich ihr die Erstreckung der Nichtigkeitsklage über die bislang im anhängigen Verletzungsverfahren herangezogenen Patentansprüche 1 und 12 hinaus auf weitere Ansprüche erst aufgrund des ihr am 11. April 2018 zugestellten Urteils des Landgerichts D… aufgedrängt habe, nachdem dort Ausführungen gemacht worden seien, die möglicherweise im Sinne einer Verletzung der mit der Klageerweiterung zusätzlich angegriffenen Ansprüche verstanden werden könnten.

Zum anderen erfordert die Klageerweiterung auch keine Vertagung der mündlichen Verhandlung i. S. d. § 83 Abs. 4 Satz 1 Nr. 1 PatG. Denn die Zulassung der Klageerweiterung macht keine Berücksichtigung neuer Tatsachen erforderlich, nachdem die Klägerin zu den in der Erweiterung nunmehr auch angegriffenen Patentansprüchen vorgetragen und sich hierbei für die von ihr behauptete Schutzunfähigkeit dieser Patentansprüche ausschließlich auf die Druckschriften berufen hat, die sie bereits zu der von ihr geltend gemachten Schutzunfähigkeit der ursprünglich allein angegriffenen Patentansprüche 1 und 12 herangezogen hatte. Durch die Klageerweiterung haben sich somit die Tatsachengrundlagen für die Beurteilung der Schutzfähigkeit der angegriffenen Patentansprüche nicht geändert. Da die Beurteilung der Schutzfähigkeit nach der höchstrichterlichen Rechtsprechung vorrangig Rechtserkenntnis ist, erfordert die Beurteilung der Schutzfähigkeit der nunmehr angegriffenen Patentansprüche mangels neuen Tatsachenvortrags nur noch die Äußerung von Rechtsansichten. Der vorliegende Zeitraum von rund zwei Wochen zwischen Zugang der Klageerweiterung bei der Beklagten und dem Termin der mündlichen Verhandlung war für eine Vorbereitung der Beklagten zu entsprechenden Erklärungen in der mündlichen Verhandlung ausreichend, so dass ein Grund für eine Vertagung der mündlichen Verhandlung nicht bestand.

Da die gesetzliche (Mindest-)Frist zur Einreichung neuen Vorbringens von einer Woche (§ 99 Abs. 1 PatG i. V. m. § 132 Abs. 1 ZPO) vorliegend gewahrt war, so dass die Beklagte nach dieser gesetzlichen Wertung ausreichend Zeit zur Vorbereitung ihres Vorbringens in der mündlichen Verhandlung auf die Klageerweiterung und das damit verbundene (überschaubare) Vorbringen der Klägerin hatte, war der Beklagten mangels Bestehens der Voraussetzungen nach § 99 Abs. 1 PatG i. V. m. § 283 ZPO auf ihren Antrag auch kein Schriftsatznachlass zur Klageerweiterung einzuräumen.

B.

Zur Begründetheit der Klage

Die somit zulässige Klage ist auch begründet. Das Streitpatent ist gemäß Artikel II § 6 Absatz 1 Nr. 1 IntPatÜG, Art. 138 Abs. 1 Buchst. a) EPÜ im angegriffenen Umfang für nichtig zu erklären, weil insoweit sowohl gegenüber der erteilten Fassung des Streitpatents als auch gegenüber seinen Fassungen nach den Hilfsanträgen 1 bis 3 der Nichtigkeitsgrund der mangelnden Patentfähigkeit nach Art. 52, 56 EPÜ besteht und die beschränkte Verteidigung der Beklagten mit den erst in der mündlichen Verhandlung eingereichten zusätzlichen Hilfsanträgen 0 und 4 als verspätet zurückzuweisen ist.

I. Zum Gegenstand des Streitpatents

1. Die Erfindung betrifft ein Verfahren sowie ein entsprechendes Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz, wobei für einen Alarmdatenabgleich zwischen einem Agent einer Managementebene und zumindest einem Manager einer nächsthöheren Managementebene die Alarmdaten aktiver Alarme übertragen werden.

Zum technischen Hintergrund führt die Streitpatentschrift in den Absätzen 0002 bis 0004 der Beschreibung aus, dass die Prinzipien eines Managementnetzes, die auch als TMN-Prinzipien (Telecommunications Management Network) bezeichnet würden, mehrere Managementebenen für das Management eines Kommunikationssystems – beispielsweise eines Mobil-Kommunikationssystems – definierten, wobei jede Ebene eine doppelte Funktion habe. Diese bestehe darin, dass im managenden System jede Ebene außer der untersten eine Manager-Funktion für die darunterliegende Ebene und im gemanagten System jede Ebene außer der obersten eine Agenten-Funktion für die nächsthöhere Ebene habe.

Das Fehlermanagement (Fault Management) sei ein wichtiger Teil des TMN-Managements. Grundsätzlich spiele hier der Agent die aktive Rolle, indem er Fehler der eigenen Managementebene rechtzeitig und genau erkenne und an den Manager der nächsthöheren Ebene als Alarme übertrage. Die Übertragung von Alarmdaten vom Agent zum Manager sei unkritisch, solange der Kommunikationsmechanismus zwischen diesen Systemen nicht gestört ist. Wenn die Verbindung zwischen den beiden Managementebenen, also zwischen Agent und Manager, für eine bestimmte Zeit nicht mehr gewährleistet sei, müsse der Agent die während dieses Intervalls aufgetretenen Alarme zwischenspeichern, um sicherzustellen, dass nach dem Wiederherstellen der Kommunikationsmöglichkeit dem Manager zum einen möglichst schnell eine Übersicht der z. Zt. aktiven Alarme – z. B. in Form einer Liste – zur Verfügung gestellt werde, und der Manager zum anderen eine möglichst lückenlose Alarmgeschichte (alarm history) sowohl der aktiven als auch der beendeten Alarme (cleared alarms) aufbauen könne. Zu diesem Zweck werde ein Alarmdatenabgleich (alarm realignment) zwischen Agent und Manager bei jedem neuen Verbindungsaufbau nach einem Verbindungsabbruch oder nach einer Initialisierung des Agenten oder des Managers ausgeführt. Alle Alarmdaten aktiver Alarme, zu denen Fehler im Agent noch nicht behoben seien – erkennbar daran, dass sie nicht als „cleared alarms“ gekennzeichnet seien –, seien daher schnellstmöglich und vollständig der nächsthöheren Managementebene zur Verfügung zu stellen.

Das Streitpatent geht von einem Stand der Technik nach den Druckschriften P 19752614.4, WO 96/24899 und WO 96/20547 aus, die sie in den Absätzen 0005 bis 0007 näher beschreibt. ln der älteren Patentanmeldung P 19752614.4 (Anlage B1 der Widerspruchsbegründung) seien ein Verfahren und Kommunikationssystem zur Behandlung von Alarmen angegeben, die eine Basisfunktionalität für den Manager zur Anforderung aller Alarme vom Agent beschrieben. Dabei sende der Agent die aktiven Alarme als Sequenz standardisierter M-EVENT-REPORTS, die zu der jeweiligen Anforderung durch Verwendung von Korrelationsinformationen eindeutig korreliert seien. Dies erlaube dem Manager, diese M-EVENT-REPORTS einer bestimmten Anforderung zuzuordnen und darüber hinaus von anderen, „regulären“ M-EVENT-REPORTS zu unterscheiden. Aus der internationalen Patentanmeldung WO 96/24899 (Anlage B2 der Widerspruchsbegründung) sei ein Verfahren mit einem oder mehreren Managern sowie einem Agent bekannt, bei dem die Anzahl der Nachrichten im Agent reduziert werden solle. Hierzu werde bereits die Erzeugung der Nachrichten im „managed system“ vom Operator am „managing system“ kontrolliert, so dass der Agent nur solche Nachrichten generiere, die für den Manager relevant und daher anschließend als „Event reports“ über die Manager-Agent-Schnittstelle zu übertragen seien. Da das Erzeugen der Nachrichten im Agent abhängig von einem „notification stop“- Attribut bei der Definition der einzelnen Objektinstanz erfolge, werde das Aussenden der Nachrichten lastabhängig erlaubt oder verhindert. Aus der internationalen Patentanmeldung WO 96/20547 sei ein Verfahren zur Behandlung von Alarmen in einem Kommunikationssystem bekannt, bei dem zwei Ringpuffer von entkoppelten Agent-Prozessoren verwendet würden, mit denen eine „snaps-hot“-Kopie des Systemzustands im Agent zu einem Zeitpunkt, wenn die Kommunikation zwischen Manager und Agent nicht mehr läuft, erzeugt werde.

Nach Absatz 0008 sei es daher die Aufgabe der Erfindung, ein derartiges Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz anzugeben, durch das ein Alarmdatenabgleich zwischen einem Agent und zumindest einem Manager weiter verbessert werde.

Diese Aufgabe löse die Erfindung hinsichtlich des Verfahrens durch die Merkmale des Patentanspruchs 1 und hinsichtlich des Kommunikationssystems durch die Merkmale des Patentanspruchs 12. Weiterbildungen der Erfindung seien den Unteransprüchen zu entnehmen.

2. Die Merkmale der in den Ansprüchen 1 und 12 der erteilten Fassung beanspruchten Gegenstände lassen sich wie folgt gliedern:

Anspruch 1 :

1. Verfahren zur Behandlung von Alarmen in einem Kommunikationssystem durch ein mehrere Managementebenen (A, B, C) aufweisendes Managementnetz, wobei für einen Alarmdatenabgleich zwischen einem Agent (AG) einer Managementebene (B, C) und zumindest einem Manager (MA1, MA2) einer nächsthöheren Managementebene (A, B) die Alarmdaten aktiver Alarme übertragen werden, bei dem

1.1 – von dem Manager (MA1, MA2) jeweils eine oder mehrere Anforderungsnachrichten (repAA) zum Übermitteln der Alarmdaten an den Agent (AG) gesendet werden,

1.2 – von dem Manager (MA1, MA2) Korrelationsinformationen (alaAH, aliNl) für eine Zuordnung der jeweiligen Anforderung zu den vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten empfangen werden, und

1.3 – von dem Manager (MA1, MA2) der Alarmdatenabgleich abhängig von zumindest einem zum Agent (AG) gesendeten Parameter (par) gesteuert wird.

Anspruch 12:

12. Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen (A, B, C) aufweisendes Managementnetz, wobei für einen Alarmdatenabgleich zwischen einem Agent (AG) einer Managementebene (z. B. B) und zumindest einem Manager (MA1, MA2) einer nächsthöheren Managementebene (z. B. A) die Alarmdaten aktiver Alarme übertragen werden, mit

12.1 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für das Senden einer oder mehrerer Anforderungsnachrichten (repAA) zum Übermitteln der Alarmdaten an den Agent (OMC1), und

12.2 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für das Empfangen von Korrelationsinformationen (alaAH, aliNl) für eine Zuordnung der jeweiligen Anforderung zu den vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten, und

12.3 – Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für eine Steuerung des Alarmdatenabgleich abhängig von zumindest einem zum Agent (AG) gesendeten Parameter (par).

3. Der zuständige Fachmann – der ein Ingenieur der Elektrotechnik mit der Fachrichtung Nachrichtentechnik ist und über eine mehrjährige Erfahrung auf dem Gebiet von Telekommunikationssystemen im Zusammenhang mit digitalen Mobiltelefonsystemen verfügt – wird diese Ansprüche und die in ihnen enthaltenen Begriffe wie folgt verstehen:

Das Streitpatent (SP) betrifft gemäß den jeweiligen unabhängigen Ansprüchen 1 und 12 ein Verfahren bzw. ein Kommunikationssystem zur Behandlung von Alarmen durch ein Managementnetz, welches mehrere Management-Ebenen (A, B, C) aufweist (vgl. Fig. 1).

Abbildung in Originalgröße in neuem Fenster öffnen

Für einen Alarmdatenabgleich zwischen einer – in Anlehnung an den fachüblichen englischen Sprachgebrauch als „Agent“ (AG) bezeichneten – Einrichtung einer Managementebene (z. B. Ebene B) und „zumindest einem Manager (MA1, MA2)“ einer nächsthöheren Managementebene (z. B. Ebene A) sollen gemäß den jeweiligen einleitenden Merkmalen der Ansprüche 1 und 12 die Alarmdaten aktiver Alarme übertragen werden. Figur 4 des Streitpatents zeigt hierzu einen Nachrichtenfluss für einen Alarmdatenabgleich zwischen einem Agent (AG) und einem Manager (MA1/MA2).

Vom Wortlaut der Ansprüche 1 und 12 sind dementsprechend sowohl ein Alarmdatenabgleich mit nur einem Manager als auch ein Alarmdatenabgleich mit mehreren Managern umfasst. Gemäß Streitpatentschrift erfolgt der Nachrichtenfluss beim Alarmdatenabgleich in einer ersten anspruchsgemäßen Variante zwischen einem Agent und nur einem einzigen Manager in serieller Weise, während die Nachrichten in der zweiten anspruchsgemäßen Variante zwischen dem Agenten und mehreren Managern parallel übertragen werden können (vgl. SP, Abs. 0034, letzter Satz, sowie auch Fig. 4 und Abs. 0033).

Die Beklagte hat zur Auslegung des Begriffs „Alarmdatenabgleich“ ausgeführt, dass das beanspruchte Verfahren bzw. das beanspruchte Kommunikationssystem eine Alarmhistorie bzw. „Alarm-History“ gemäß Absatz 0003 des Streitpatents zur Verfügung stelle. Dem kann seitens des Senats nicht beigetreten werden. Denn eine Einschränkung des beanspruchten Verfahrens bzw. des beanspruchten Kommunikationssystems auf das Abfragen einer Alarmhistorie bzw. „Alarm-History“ und damit eine Einschränkung auf bestimmte, standardisierte Nachrichten zur Ermittlung der Alarmhistorie bei einem Alarmdatenabgleich ergibt sich weder aus dem Wortlaut der jeweiligen Ansprüche noch aus Absatz 0003 des Streitpatents. Vielmehr macht das Streitpatent im folgenden Absatz 0004 deutlich, dass ein Abgleich (alarm realignment) der aktuellen, nicht behobenen Alarme für die Erfindung wesentlich ist.

Als Agent (AG) ist gemäß Absatz 0025 der Streitpatentschrift beispielsweise ein Basisstationssystem (vgl. u. a. BSS11 in Ebene C in Fig. 1) oder ein Betriebs- und Wartungszentrum (vgl. u. a. OMC1 in Ebene B in Fig. 1) anzusehen. Bei dem Manager handelt es sich gemäß Absatz 0025 der Streitpatentschrift entweder um Anwendungsprogramme eines Betriebs- und Wartungszentrums (vgl. Fig. 1, u. a. Bezugszeichen OMC1 in Ebene B) oder eines Netzmanagementzentrums (vgl. Fig. 1, u. a. Bezugszeichen NMC1 in Ebene A). Mittels entsprechender Einrichtungen (M-CTR) werden jeweils eine oder auch mehrere Anforderungsnachrichten (repAA = report Active Alarms) zum Übermitteln der Alarmdaten von einem Manager (z. B. MA1) an den Agent (AG) gesendet (vgl. Merkmale 1.1 und 12.1 sowie Fig. 4). Seitens des Managers (z. B. MA1) sollen dabei Korrelationsinformationen empfangen werden, die einer Zuordnung der jeweiligen Anforderung zu den vom Agent (AG) nachfolgend gesendeten Nachrichten mit den Alarmdaten dienen (vgl. Merkmal 1.2 bzw. Merkmal 12.2 der Ansprüche 1 und 12 sowie Abs. 0035 und 0038 der Streitpatentschrift). Außerdem soll der Alarmdatenabgleich von dem Manager in Abhängigkeit von zumindest einem zum Agent gesendeten Parameter gesteuert werden (vgl. Merkmale 1.3 und 12.3 der Ansprüche 1 und 12 sowie Abs. 0034).

II. Zur erteilten Fassung (Hauptantrag)

In der erteilten Fassung ist das Streitpatent nach Art. II § 6 Abs. 1 Nr. 1 IntPatÜG i. V. m. Art. 138 Abs. 1 Buchst. a), Art. 52, 56 EPÜ für nichtig zu erklären, weil es gegenüber dem Stand der Technik nach den Druckschriften NiK 1a‘ und NiK 1b nicht auf einer erfinderischen Tätigkeit beruht.

1. Unabhängiger Anspruch 1

Der unstreitig vorveröffentlichte ETSI-Standard EN 301 251 gemäß Druckschrift NiK 1a‘ beschreibt ein Verfahren zur Behandlung und Überwachung von Alarmen (Alarm Surveillance) durch Managementdienste in einem mobilen GSM Mobil-Kommunikationssystem (GSM PLMN), welches zwei verschiedene Managementebenen in Form einer Ebene für Netzwerkelemente (NE / Managed System / managed network elements NE) und einer übergeordneten bzw. nächsthöheren Betriebssystem-Ebene (OS) aufweist, welche miteinander durch ein Q3-Interface verbunden sind (vgl. NiK 1a‘, S. 12, Kapitel 4 letzter Abs. und Abschnitt 4.1.1 i. V. m. S. 14, Abschnitt 5.1.1, mitsamt Fig. 1 und Abkürzungsliste gem. Abschnitt 3.2). Die verwalteten Netzwerkelemente umfassen beispielsweise Basisstationssysteme (BSS), womit die Ebene für Netzwerkelemente der Netzeinrichtungsebene („Network Element Level“) des Streitpatents entspricht und die Netzwerkelemente – in gleicher Weise wie in der Streitpatentschrift in den Absätzen 0024 bis 0026 und 0033 definiert – als Agent (AG) einer Managementebene anzusehen sind (vgl. NiK 1a‘ u. a. S. 14, Abschnitt 5.1.1, zweiter Abs., sowie S. 5 letzter Abs. und Kap. 1, erster Satz).

Abbildung in Originalgröße in neuem Fenster öffnen

Für einen Alarmdatenabgleich ([…] to align alarm information) werden die Daten aktueller aktiver Alarme (current outstanding alarm conditions) von der Ebene der Netzwerkelemente (Managed System / managed NE) an die übergeordnete Managementebene (Betriebssystem-Ebene OS) übertragen (vgl. Abschnitt 5.1, S. 13 unter d) i. V. m. Abschnitt 4.1.1, zweiter Satz: […] an alarm report is forwarded […] as soon as possible to the OS […]). Dabei beschreibt der ETSI-Standard gemäß Druckschrift NiK 1a‘ auch, dass die Alarmdaten aktiver Alarme zwischen der Managementebene in Form der Ebene der Netzwerkelemente (NE) als Agent dieser Managementebene und einem Manager der Betriebssystem-Ebene (OS) als höhere Managementebene für einen Alarmdatenabgleich übertragen werden (vgl. Titel und Abschnitt 4.1.1, Abschnitt 5.1, S. 13 unter d) letzter Satz, sowie Abschnitt 5.4.1 und die weiteren Zitatstellen a. a. O.). Dies entspricht bereits der mit den jeweiligen einleitenden Merkmalen der Ansprüche 1 und 12 umfassten Variante mit einem Manager. In dem vorstehend genannten Zusammenhang offenbart der ETSI-Standard gemäß Druckschrift NiK 1a‘ auch, dass von der Managementebene (Betriebssystem-Ebene OS) zumindest eine Nachricht (Request current alarm summary) an den Agent (NE / Managed System) gesendet wird, wobei diese Nachricht eine Anforderung (Request) zur Übermittlung einer Zusammenfassung von Alarmdaten (current alarm summary) beinhaltet (vgl. Abschnitt 5.1, S. 13 unter d): […] in a summary on demand; sowie Abschnitt 5.1.5 und Abschnitt 6.1.4, zweiter Abs.: The OS requests the NE to send a current alarm summary / Merkmal 1.1 bzw. Merkmal 12.1).

Der ETSI-Standard gemäß Druckschrift NiK 1a‘ offenbart zudem, dass der Alarmdatenabgleich von dem Manager in Abhängigkeit von Filterkriterien (depending on the filter and forwarding criteria) (vgl. Abschnitt 4.1.1) durchgeführt wird. In Bezug auf das Merkmal 1.3 wird dazu im ETSI-Standard gemäß Druckschrift NK 1a‘ weiterhin ausgeführt, dass das Betriebssystem (OS) als Manager eine Anforderung (request / requestTransferUp action) hinsichtlich Alarm-Informationen an Netzwerkelemente (NE / Managed System / managed NE) sendet, welche als Agent fungieren (vgl. S. 20, Abschnitt 5.1.5, alarm summary criteria, i. V. m. S. 20, le. Abs.). Damit steuert der Manager (OS) den Alarmdatenabgleich – für den Fachmann offenkundig – entsprechend Merkmal 1.3 bzw. 12.3 in Abhängigkeit von einem Filter-Parameter, der an den Agent (NE / Managed System / managed NE) gesendet wird.

In Bezug auf das verbleibende Merkmal 1.2 des Anspruchs 1 bzw. Merkmal 12.2 des Anspruchs 12 gemäß Hauptantrag ist dem ETSI-Standard gemäß Druckschrift NiK1a‘ zu entnehmen, dass der Agent (NE / Managed System / managed NE) die ausstehenden Alarmdaten bzw. die jeweilige Alarm-Information zu den aktiven Alarmen mittels einer Zusammenfassung eines Alarms an den Manager in der Betriebssystem-Ebene (OS) übermittelt (vgl. Abschnitt 5.1 Alarm surveillance, S. 13 unter d): The outstanding alarm information may be reported in a summary on demand […] to the OS; Abschnitt 6.1.4 fünfter Abs.: Report current alarm summary: The NE provides the OS […] with a current alarm summary report). Des Weiteren wird in Abschnitt 5.1 ausgeführt, dass die vorstehend genannte Funktionalität zum Bereitstellen der Alarm-Information (alarm information) genutzt werden kann, um einen Abgleich der zwischen der Betriebssystem-Ebene (OS) und dem Agent (NE) ausgetauschten Information vorzunehmen (vgl. Abschnitt 5.1, S. 13 unter d) letzter Satz: This functionality can also be used to align alarm information between the OS and NE […]). Die Möglichkeit eines Abgleichs von Alarm-Informationen wird im Zusammenhang mit einem Verbindungsfehler, einem Neustart des Betriebssystems oder einem Neustart des Netzwerkelements beschrieben (vgl. a. a. O.; e. g. link failure, OS restart, NE restart). Des Weiteren wird in Abschnitt 5.1 bzw. in den Abschnitten 6.1.4 und 6.1.5 der Druckschrift NiK 1a‘ bezüglich einer konkreten Handhabung eines Alarmdatenabgleichs auf die Druckschrift NiK 1b (ITU-T Recommendation Q.821) verwiesen. Der Fachmann hat damit hinreichend Veranlassung, die im ETSI-Standard gemäß Druckschrift NiK 1a‘ genannte Druckschrift NiK 1b bezüglich der Handhabung von Alarmdaten bzw. eines Alarmdatenabgleichs heranzuziehen. In dieser Druckschrift werden als Anforderungs-Identifizierer (Invoke Identifier) und als weiterer Identifizierer (Linked Identifier) bezeichnete Nachrichtenfelder (parameter name) im Zusammenhang mit dem Anfordern und Senden von Alarm-Informationen zwischen einem verwalteten System („managed system“, hier: Netzwerkelementebene NE / Agent) und einem verwaltenden System („managing system“, hier: Betriebssystem-Ebene / OS) aufgeführt (vgl. NiK 1b, insbesondere Abschnitt 5.3.10.1, S. 23, Tabelle 8/Q.821 und Definitionen nach Kap. 2 bis 4 sowie beispielsweise Fig. 11/Q.821 und S. 2: managed system: one or more application processes that act as agents).

Abbildung in Originalgröße in neuem Fenster öffnen

Die beiden genannten Identifizierer beinhalten zwei Korrelationsinformationen, nämlich eine Information zur Anforderungsidentifizierung als Invoke Identifier sowie eine Information zur Verbindungsidentifizierung als Linked Identifier, welche von dem Manager (Managing System) als Antwort (Rsp) auf eine Anfrage (Req) entsprechend Merkmal 1.2 bzw. Merkmal 12.2 empfangen werden (vgl. NiK 1b, Abschnitt 5.3.10.1, Tabelle 8/Q.821 auf S. 23 mit zugehörigen Erläuterungen). Die in Abschnitt 5.3.10.1 im Zusammenhang mit den genannten Identifizierern als Teile einer Anfrage (Req) zum Liefern von aktuellen Alarmdaten (Current Alarm Summary) genannten weiteren Nachrichtenfelder (Scope and Filter parameters) enthalten dabei die Filter-Parameter, die sowohl entsprechend dem ETSI-Standard gemäß Druckschrift NiK1a‘ als auch den Merkmalen 1.3 und 12.3 entsprechend an das Managed System und damit an den Agent gesendet werden (vgl. NiK 1b, S. 23 und S. 24 erster, dritter und vierter Abs.).

Den Ausführungen der Beklagten, dass das beanspruchte Verfahren bzw. das beanspruchte Kommunikationssystem eine Alarmhistorie bzw. „Alarm-History“ gemäß Absatz 0003 des Streitpatents betreffe und dass – im Gegensatz zu dem aus dem Stand der Technik gemäß NiK1a‘ mitsamt der zugehörigen Tabelle 1 (S. 31) bekannten seriellen Abgleich von Alarmen – ein paralleler Austausch von Anforderungen und Alarmdaten mit mehreren Managern gefordert sei, kann seitens des Senats nicht gefolgt werden. Denn eine Einschränkung im Zusammenhang mit einer Alarm-Historie und einem parallelen Abgleich von Alarmen mit Managern, wie es die Beklagte geltend macht, ist weder den Ansprüchen 1 und 12 noch der Beschreibung des Streitpatents zu entnehmen, wie in Abschnitt B. I. 3. ausgeführt. Vielmehr wird in den Ansprüchen 1 und 12 offen gelassen, ob es sich um einen seriellen Alarmdatenabgleich mit nur einem Manager oder um einen Austausch von Alarmdaten mit mehreren Managern handelt, da in den jeweils einleitenden Merkmalen der Ansprüche 1 und 12 von „zumindest einem Manager“ und in den folgenden Merkmalen 1.1 bis 1.3 des Anspruchs 1 bzw. den Merkmalen 12.1 bis 12.3 des Anspruchs 12 auch jeweils von dem „Manager“ die Rede ist. Anders als die Beklagte die jeweiligen Ansprüche verstanden wissen will, bedeutet dies nichts anderes, als dass die Ansprüche 1 und 12 zumindest eine Merkmalsalternative beinhalten, die auch einem Alarmdatenabgleich zwischen einem Agent und einem einzelnen Manager entspricht, wie es sowohl der Beschreibung des Streitpatents im Zusammenhang mit einem seriellen Abgleich (vgl. SP, Abs. 0034, letzter Satz, sowie Fig. 4, und Abs. 0033) als auch bereits dem Stand der Technik gemäß NiK1a‘ bzw. NiK1b zu entnehmen ist. Für einen Abgleich (alarm realignment) der aktuellen, nicht behobenen Alarme, wie das Streitpatent im Absatz 0004 deutlich macht, sieht der ETSI-Standard EN 301 251 (vgl. Druckschrift NiK 1a‘, Abschnitt 5.1, S. 13 unter d)) in Verbindung mit der ITU-T Empfehlung Q.821 gemäß Druckschrift NiK 1b (vgl. Abschnitt 5.3.10) ein Ermitteln der current outstanding alarm conditions vor.

Der Fachmann gelangt damit – entgegen den Ausführungen der Beklagten – in Kenntnis des ETSI-Standards gemäß Druckschrift NiK1a‘ und dem darin enthaltenen Hinweis auf die ITU-T Empfehlung Q.821 gemäß Druckschrift NiK1b in naheliegender Weise zu dem im Anspruch 1 gemäß Hauptantrag genannten Verfahren bezüglich eines Alarmdatenabgleichs zwischen einem Agent und zumindest einem Manager mitsamt den Merkmalen 1.1 bis 1.3. Der Gegenstand des erteilten Anspruchs 1 ist daher wegen fehlender erfinderischer Tätigkeit nicht patentfähig.

2. Unabhängiger Anspruch 12

Die vorstehenden Ausführungen gelten in gleicher Weise in Bezug auf den Gegenstand des nebengeordneten Anspruchs 12 mit den Merkmalen 12.1 bis 12.3, welche den Merkmalen 1.1 und 1.3 entsprechen. Damit ist auch der erteilte Anspruch 12 wegen fehlender erfinderischer Tätigkeit nicht patentfähig.

3. Abhängige Ansprüche 2, 5, 13 und 16

Hinsichtlich der abhängigen Ansprüche, welche die Beklagte im Übrigen auch nicht gesondert verteidigt hat, hat weder die Beklagte vorgetragen noch ist für den Senat anderweitig ersichtlich, dass die in den abhängigen Ansprüchen 2, 5, 13 und 16 enthaltenen weiteren Merkmale etwas Erfindungswesentliches enthalten, das geeignet wäre, in Kombination mit den übrigen Merkmalen abweichend von den unabhängigen Ansprüchen die Patentfähigkeit dieser Ansprüche zu begründen; vielmehr handelt es sich um Weiterbildungen des mit den unabhängigen Ansprüchen beanspruchten Gegenstandes mit üblichen Mitteln.

III. Zu den Hilfsanträgen 0 und 4

Die erst in der mündlichen Verhandlung eingereichten Hilfsanträge 0 und 4 sind nach § 83 Abs. 4 PatG als verspätet zurückzuweisen.

Denn die Zulassung dieser erst nach Ablauf der mit dem Hinweis des Senats vom 12. Januar 2018 gesetzten letzten Frist (9. April 2018), über deren Versäumnisfolgen die Parteien belehrt worden waren (§ 83 Abs. 4 Satz 1 Nr. 3 PatG), eingereichten Hilfsanträge hätte eine Vertagung der mündlichen Verhandlung erforderlich gemacht (§ 83 Abs. 4 Satz 1 Nr. 1 PatG). Nach beiden Hilfsanträgen ist in den unabhängigen Ansprüchen 1 und 12 jeweils das zusätzliche neue Merkmal

wobei in den auf die Nachricht (staAA) folgenden Nachrichten (alNO) die Alarmdaten ausgewählter Alarme unter Verwendung eines M-EVENT-REPORT-Service gesendet werden.

aufgenommen, welches die Beklagte nach eigener Darstellung den Ausführungen in der Beschreibung auf Seite 18 Zeilen 16 ff. der veröffentlichten Anmeldung WO 99/37101, welche mit Absatz 0042 der Streitpatentschrift identisch sind, entnommen hat. Zusammen mit den übrigen Merkmalen handelt es sich mithin bei den nach diesen Fassungen nunmehr beanspruchten Gegenständen um solche, welche die Beklagte bislang weder mit den erteilten Ansprüchen noch mit denen nach einem der von ihr zuvor eingereichten Hilfsanträge beansprucht hatte. Da eine solche Merkmalskombination, wie sie nach den Fassungen des Streitpatents laut den Hilfsanträgen 0 und 4 nunmehr jeweils beansprucht werden soll, mithin zuvor zu keinem Zeitpunkt streitgegenständlich war, musste die Klägerin sich auf eine Anspruchsfassung mit einer solchen Merkmalskombination bislang nicht einstellen. Sie hat in der mündlichen Verhandlung dementsprechend nicht nur die Verspätung dieser Hilfsanträge gerügt, sondern auch erklärt, dass sie sich außer zur Frage der Ursprungsoffenbarung (welche sie ausführlich bestritten hat) dazu, ob eine solche Merkmalskombination patentfähig ist, in der mündlichen Verhandlung nicht äußern könne und dementsprechend auch einen Schriftsatznachlass beantragt. Diese Einwendungen der Klägerin sind auch naheliegend, denn eine Beurteilung der Patentfähigkeit dieser neuen Merkmalskombination allein anhand des bereits im Verfahren befindlichen Standes der Technik würde angesichts des Umstands, dass es gerade Ziel der Beklagten ist, sich von diesem Stand der Technik mit den neuen Hilfsanträgen abzusetzen, für den Fall, dass die Rechtsansicht der Beklagten zuträfe, ersichtlich für eine solche Beurteilung nicht ausreichen; vielmehr wäre der Klägerin Gelegenheit zu geben, hinsichtlich der Frage der Patentfähigkeit der neuen Anspruchsfassungen eine neue Recherche durchzuführen, zu der sie bislang wie bereits ausgeführt mangels Streitgegenständlichkeit dieser neuen Anspruchsfassungen keine Veranlassung hatte. Mit einem bloßen Schriftsatznachlass (§ 99 Abs. 1 PatG i. V. m. § 283 ZPO) könnte diesem berechtigten Begehren der Klägerin allein nicht Rechnung getragen werden, denn zu ihrem zu unterstellenden neuen Vorbringen in einem nachgelassenen Schriftsatz müsste dann der Beklagten wiederum rechtliches Gehör gewährt werden, was nur mittels einer neu anzusetzenden mündlichen Verhandlung möglich wäre. Die Zulassung der neuen Hilfsanträge würde daher eine Vertagung der mündlichen Verhandlung unumgänglich machen, was das Gesetz aber mit der Regelung nach § 83 Abs. 4 PatG gerade ausdrücklich ausschließt.

Darüber hinaus hat die Beklagte die Vorlage der neuen Hilfsanträge erst in der mündlichen Verhandlung nicht – und damit auch nicht genügend – entschuldigt (§ 83 Abs. 4 Satz 1 Nr. 2 PatG). Die Aufnahme des neuen Merkmals ist weder durch entsprechende Ausführungen des Senats in der mündlichen Verhandlung noch durch das Vorbringen der Klägerin in der mündlichen Verhandlung oder in einem dieser unmittelbar vorangegangenen Schriftsätze, insbesondere durch die Stellungnahmen der Klägerin, die sie nach dem Hinweis des Senats nach § 83 Abs. 1 PatG eingereicht hatte, veranlasst. Sie beruht nach eigenem Bekunden der Beklagten vielmehr allein auf ihrem Eindruck, dass Begriffe des Streitpatents anders als nach ihrem Verständnis ausgelegt werden könnten. Aus welchem Grund die Hilfsanträge dann aber nicht bereits früher hätten eingereicht werden können, ist weder seitens der Beklagten dargetan worden noch anderweitig ersichtlich. Das von ihr beanstandete, angeblich nicht zutreffende Verständnis hatte vielmehr die Klägerin bereits in der Klageschrift zum Ausdruck gebracht; soweit die Beklagte befürchtet hätte, dass der Senat dieser Ansicht folgen könnte, hätte sie diese Befürchtung bereits spätestens mit Zugang des Hinweises nach § 83 Abs. 1 PatG haben müssen. Dann hätte sie aber hinreichend Anlass gehabt, die von ihr mit den Hilfsanträgen 0 und 4 nunmehr geltend gemachten Anspruchsfassungen innerhalb der Äußerungsfristen auf den Hinweis einzureichen; weshalb das stattdessen erst in der mündlichen Verhandlung erfolgte, hat die Beklagte nicht erläutert und ist auch bei der gebotenen objektiven Betrachtung nicht nachvollziehbar.

Da somit sämtliche Voraussetzungen nach § 83 Abs. 4 Satz 1 PatG bestehen, waren die Hilfsanträge 0 und 4 als verspätet zurückzuweisen.

IV. Zu den Hilfsanträgen 1 bis 3

In den Fassungen laut den Hilfsanträgen 1 bis 3 kann die Beklagte das Streitpatent nicht erfolgreich verteidigen, weil der danach jeweils beanspruchte Gegenstand ungeachtet der von der Klägerin bereits jeweils bestrittenen Zulässigkeit, die daher dahinstehen kann, auf jeden Fall ebenfalls nicht auf einer erfinderischen Tätigkeitgegenüber dem Stand der Technik beruht (Art. 52, 56 EPÜ).

1. Hilfsantrag 1

In den Ansprüchen 1 und 12 gemäß Hilfsantrag 1 kommt gegenüber den Ansprüchen 1 und 12 der erteilten Fassung des Streitpatents (Hauptantrag) zusätzlich zum Ausdruck, dass eine vom Manager definierte Korrelationsinformation in einem Nachrichtenfeld der Anforderungsnachricht mitgesendet wird (vgl. jeweils erster Spiegelstrich der Ansprüche 1 und 12), die Korrelationsinformationen die Korrelationsinformation und eine weitere Korrelationsinformation aufweisen (vgl. jeweils zweiter Spiegelstrich der Ansprüche 1 und 12) sowie die vom Agent nachfolgend gesendeten Nachrichten mit den Alarmdaten jeweils die weitere Korrelationsinformation aufweisen. Diese Ergänzungen gegenüber der erteilten Fassung des Streitpatents (Hauptantrag) können eine erfinderische Tätigkeit ebenfalls nicht begründen.

Wie vorstehend zum Hauptantrag ausgeführt, offenbart der ETSI-Standard gemäß Druckschrift NiK 1a‘, dass von einer Managementebene (Management System / OS) eine Anforderungsnachricht an einen Agent (Managed System / managed NE) gesendet wird, wobei eine solche Nachricht eine Anforderung zur Übermittlung von Alarmdaten beinhalt (vgl. Abschnitt 6.1.4, zw. Abs.: Request current alarm summary). Dazu wird im ETSI-Standard gemäß NiK 1a‘ auf die ITU-T Empfehlung Q.821 (NiK 1b) verwiesen, in der Details zu dem aus dem Standard EN 301 251 (NiK 1a‘) bekannten Abruf von Alarmdaten durch eine Anforderungsnachricht aufgeführt werden, wobei die Anforderungsnachricht (Req) unter anderem einen Anforderungsidentifizierer in Form eines Invoke Identifier aufweist (vgl. NiK 1b, Abschnitt 5.3.10.1, S. 23, Tabelle 8/Q.821). Der Fachmann liest dabei mit, dass der vom Manager (Management System / OS) im Rahmen einer Anforderungsnachricht gesendete Invoke Identifier eine Korrelationsinformation für die Zuordnung der Anforderung enthält, wobei diese Information in fachüblicher Weise – entsprechend den Ergänzungen in den Ansprüchen 1 und 12 gemäß Hilfsantrag 1 – in einem dafür vorgesehenen Nachrichtenfeld der vorstehend genannten Anforderungsnachricht zu senden ist, damit ein Agent (Managed System / managed NE) diese Informationen auch an einer dafür vorgesehenen bzw. definierten Stelle der Anforderungsnachricht auslesen kann (vgl. NiK 1b, S. 23, Abschnitt 5.3.10.1, erster Abs. / erster Spiegelstrich der Ansprüche 1 und 12 nach Hilfsantrag 1).

In Bezug auf die weitere Ergänzung in den jeweiligen Ansprüchen 1 und 12 gemäß Hilfsantrag 1 entnimmt der Fachmann der rechten Spalte der Tabelle 8/Q.821 auf Seite 23 der Druckschrift NiK 1b, dass die vom Manager (Managing System) empfangene Korrelationsinformation in den Antworten des Agent (Rsp) die beiden in den Ausführungen zum Hauptantrag genannten Korrelationsinformationen – nämlich einerseits die im Nachrichtenfeld Invoke Identifier und andererseits die im Nachrichtenfeld Linked Identifier als weitere Korrelationsinformation – aufweist. Für den in den Ansprüchen 1 und 12 des Streitpatents angesprochenen Fall, dass der Agent mit mehreren Nachrichten auf eine Anfrage antwortet (vgl. jeweils zw. Spiegelstrich: „…nachfolgend gesendete Nachrichten“) ist damit Druckschrift NiK 1b zu entnehmen, dass alle diese Nachrichten zwei Korrelationsinformationen, d. h. die in den Nachrichtenfeldern Invoke Identifier und Linked Identifier angegebenen Informationen aufweisen, wobei die vom Agent (Managed System / managed NE) im Rahmen einer Antwort (Rsp / response) nachfolgend gesendeten Nachrichten mit den Alarmdaten jeweils die weitere, im Nachrichtenfeld Linked Identifier übermittelte Korrelationsinformation zur Identifizierung aufweisen, wie es in der jeweiligen Ergänzung der Ansprüche 1 und 12 gemäß Hilfsantrag 1 aufgeführt ist (vgl. NiK 1b, Tabelle 8/Q.821 und die weiteren Zitatstellen a. a. O. / zweiter Spiegelstrich der Ansprüche 1 und 12 gemäß Hilfsantrag 1).

Den Ausführungen der Beklagten, dass die als Invoke Identifier und als Linked Identifier übermittelten Korrelationsinformationen bei einer Verwendung gemäß der ITU-T Empfehlung Q.821 (NiK 1b) und der CCITT-Empfehlung X.710 (NiK 1c‘), auf die in NiK 1b in Verbindung mit den Erläuterungen zu Tabelle 8/Q.821 verwiesen wird (vgl. NiK 1b, S. 23, Absätze zu Invoke Idenitifier und Linked Identifier), nicht das Merkmal gemäß zweitem Spiegelstrich in Verbindung mit dem Merkmal des ersten Spiegelstrichs der Ansprüche 1 und 12 des Hilfsantrags 1 erfüllten, kann seitens des Senats nicht beigetreten werden. Denn die vom Manager definierte, also festgelegte Korrelationsinformation, die in der Anfrage (Req) als Wert des Nachrichtenfelds Invoke Identifier übermittelt wird, wird vom Agenten in allen seinen Antworten als eine erste Korrelationsinformation im Nachrichtenfeld Linked Identifier der Antworten (Rsp) verwendet, welche der Manager empfängt (vgl. NiK 1b, S. 23, Tabelle 8/Q.821 und Abschnitt Linked Identifier, sowie NiK 1c‘, S. 25, Abs. 8.3.3.1.2 i. V. m. Tabelle 8/X.710). Darüber hinaus wird vom Agenten in seinen Antworten eine weitere Korrelationsinformation verwendet, die im Nachrichtenfeld Invoke Identifier angegeben ist. Damit erfüllen Nachrichten zum Alarmdatenabgleich gemäß ITU-T Empfehlung Q.821 (NiK 1b) in Verbindung mit der CCITT-Empfehlung X.710 (NiK 1c‘) die Anforderungen des ersten und zweiten Spiegelstrichs der Ansprüche 1 und 12 des Hilfsantrags 1.

Dass für den Fall einer mehrteiligen Antwort des Agenten auf eine Anfrage der Wert des Linked Identifier dem Wert des vom Manager in der Anfrage vergebenen Invoke Identifier entspricht (vgl. NiK 1b, S. 23, Absatz Linked Identifier), steht nicht im Widerspruch dazu, dass im Sinne der Absätze 0010 und 0030 des Streitpatents die vom Manager übermittelte erste Korrelationsinformation der Zuordnung der Nachrichten zu dem vom Manager mit seiner Anfrage gestarteten Alarmdatenabgleich und die vom Agenten gesendete weitere eindeutige Korrelationsinformation dem Zuordnen zusammengehöriger mehrteiliger Antworten dient. Ob der Wert des Invoke Idenitifiers gemäß der CCITT-Empfehlung X.710 (NiK 1c‘), die in Q.821 (Nk 1b) zitiert wird (vgl. a. a. O.), für jede einzelne Nachricht im Sinne von einzelnen Mitteilungen (notification) nach dem Verständnis der Beklagten unterschiedlich sein muss (vgl. NiK 1c‘, S. 25, Abschnitt 8.3.3.1.1: Each response shall have a unique invoke Identifier…) oder sich der Wert des Identifiers auf eine eindeutige Information für eine Operationen (operation) und damit auf zusammengehörige Anfragen und Antworten bezieht (vgl. S. 28, erster Spiegelstrich: duplicate invocation: the invoke Identifier specified was allocated to another notification or operation), kann damit dahinstehen.

Wegen der weiteren Merkmale, die mit den Merkmalen der Ansprüche 1 und 12 gemäß Hauptantrag übereinstimmen, wird auf vorstehende Ausführungen verwiesen, die hier in gleicher Weise gelten.

Damit gelangt der Fachmann in Kenntnis des ETSI-Standards gemäß Druckschrift NiK 1a‘ und der darin zitierten ITU-T Empfehlung Q.821 (NiK 1b) ebenfalls in naheliegender Weise zu den Gegenständen der Ansprüche 1 und 12 gemäß Hilfsantrag 1, ohne erfinderisch tätig werden zu müssen.

2. Hilfsantrag 2

In den Ansprüchen 1 und 12 gemäß Hilfsantrag 2 wird gegenüber den Ansprüchen 1 und 12 gemäß Hilfsantrag 1 zusätzlich konkretisiert, dass beide Korrelationsinformationen gemeinsam in einer vom Agent gesendeten Nachricht enthalten sein sollen (vgl. jeweils zweiten Spiegelstrich der Ansprüche 1 und 12). Auch diese Konkretisierung kann eine Patentfähigkeit nicht begründen.

Wie vorstehend ausgeführt, entnimmt der Fachmann der rechten Spalte der Tabelle 8/Q.821 auf Seite 23 der Druckschrift NiK 1b, dass die vom Manager (Managing System) empfangene Nachricht zwei Korrelationsinformationen (Invoke Identifier und Linked Identifier) aufweist, wobei die vom Agent (Managed System / managed NE) im Rahmen einer Antwort (Rsp) nachfolgend gesendeten Alarmdaten-Nachrichten auch jeweils den Linked Identifier als weitere Korrelationsinformation zur Identifizierung aufweisen. Für den in den Ansprüchen 1 und 12 des Streitpatents angesprochenen Fall, dass der Agent mit mehreren Nachrichten auf eine Anfrage antwortet (vgl. jeweils zweiten Spiegelstrich: „…nachfolgend gesendete Nachrichten“), ist damit NiK 1b zu entnehmen, dass alle diese Nachrichten beide Korrelationsinformationen, d. h. die Nachrichtenfelder Invoke Identifier und Linked Identifier aufweisen. Damit umfasst die erste Nachricht des Agenten gemeinsam eine erste und eine weitere Korrelationsinformation, und alle weiteren Nachrichten umfassen (zumindest) die weitere Korrelationsinformation gemäß den Ergänzungen im jeweils zweiten Spiegelstrich der Ansprüche 1 und 12 gemäß Hilfsantrag 2. Wegen der weiteren Merkmale, die mit den Merkmalen der Ansprüche 1 und 12 gemäß Hauptantrag bzw. Hilfsantrag 1 übereinstimmen, wird auf vorstehende Ausführungen verwiesen, die hier in gleicher Weise gelten.

Damit ergeben sich die Gegenstände der Ansprüche 1 und 12 gemäß Hilfsantrag 2 für den Fachmann ebenfalls in naheliegender Weise aus einer Kenntnis des ETSI-Standards gemäß NiK 1a‘ und der darin zitierten ITU-T Empfehlung Q.821 gemäß NiK 1b; auch die Gegenstände der Ansprüche 1 und 12 gemäß Hilfsantrag 2 beruhen somit nicht auf einer erfinderischen Tätigkeit.

3. Hilfsantrag 3

Die weitere Präzisierung in den jeweiligen Ansprüchen 1 und 12 gemäß Hilfsantrag 3 gegenüber den Ansprüchen 1 und 12 gemäß Hilfsantrag 2 (vgl. zweiten Spiegelstrich der Ansprüche 1 und 12) dergestalt, dass jede der Korrelationsinformationen in einem jeweiligen Nachrichtenfeld der vom Agent gesendeten Nachricht enthalten sind, kann ebenfalls keine erfinderische Tätigkeit begründen.

Wie in Bezug auf die vorherigen Anträge ausgeführt, wird im ETSI-Standard gemäß NiK1a‘ auf die ITU-T Empfehlung Q.821 (NiK 1b) hingewiesen, wobei der Fachmann in NiK 1b mitliest, dass der vom Manager (Management System) im Rahmen einer Anforderungsnachricht bzw. Anfrage (Req) gesendete Invoke Identifier eine Korrelationsinformation für die Zuordnung bzw. Identifizierung der Anforderung enthält, um damit diese Information in fachüblicher Weise in einem dafür vorgesehenen Nachrichtenfeld der vorstehend genannten Anforderungsnachricht zu senden, damit ein Agent diese Informationen an einer vorgesehenen Stelle der Anforderungsnachricht auslesen kann. In gleicher Weise geht der Fachmann auch davon aus, dass in der vom Agent (Managed System / managed NE) im Rahmen einer Antwort (Rsp) gesendeten Nachricht jede der beiden Korrelationsinformationen in einem jeweiligen Nachrichtenfeld (Invoke Identifier und Linked Identifier) der vom Agent gesendeten Nachricht enthalten ist, damit auch der Manager (Management System) diese Informationen an einer definierten Stelle der Nachricht auslesen kann, wie es in den jeweiligen Ansprüchen 1 und 12 gemäß Hilfsantrag 3 zusätzlich aufgeführt ist (vgl. NiK 1b, Tabelle 8/Q.821 und den zugehörigen Text auf S. 23 und S. 24).

Wegen der weiteren Merkmale, die mit den Merkmalen der Ansprüche 1 und 12 der vorherigen Anträge übereinstimmen, wird auf die entsprechenden Ausführungen zum Hauptantrag bzw. den Hilfsanträgen 1 und 2 verwiesen, die hier in gleicher Weise gelten.

Damit ergeben sich auch die Gegenstände der Ansprüche 1 und 12 gemäß Hilfsantrag 3 für den Fachmann in naheliegender Weise aus einer Kenntnis des ETSI-Standards gemäß NiK1a‘ und der darin genannten ITU-T Empfehlung Q.821 gemäß NiK1b. Die Gegenstände der Ansprüche 1 und 12 gemäß Hilfsantrag 3 beruhen daher ebenfalls nicht auf einer erfinderischen Tätigkeit.

IV. Ergebnis

Da somit das Streitpatent im angefochtenen Umfang weder in der erteilten Fassung noch in einer der zu berücksichtigenden beschränkten Fassungen, mit denen die Beklagte es verteidigt hat, sich als patentfähig erweist, war das Streitpatent im angefochtenen Umfang für nichtig zu erklären.

C.

Nebenentscheidungen

Die Kostenentscheidung beruht auf § 84 Abs. 2 PatG i. V. m. § 91 Abs. 1 ZPO, die Entscheidung über die vorläufige Vollstreckbarkeit auf § 99 Abs. 1 PatG i. V. m. § 709 ZPO.