T 1736/08 (Programmieren einer Sicherheitssteuerung/PILZ) of 11.11.2011

Sachverhalt und Anträge

I. Zwei Einsprüche wurden gegen das europäische Patent Nr. 1362269 in seiner Gesamtheit gestützt auf die Einspruchsgründe nach Artikel 100 a) EPÜ in Verbindung mit den Artikeln 52 (1), 54 und 56 EPÜ eingelegt.

Die Einspruchsabteilung hat mit der Entscheidung vom 30. Juni 2008 das Patent widerrufen. Sie hat in ihrer Entscheidung die behaupteten offenkundigen Vorbenutzungen "ELOP II" und "Asimon" als hinreichend bewiesen erachtet. Sie ist zu dem Ergebnis gelangt, dass der Gegenstand des Anspruchs 1 des Patents nicht neu sei im Hinblick auf die offenkundige Vorbenutzung "ELOP II". Zu dem gleichen Ergebnis gelangte sie hinsichtlich des Anspruchs 1 der damaligen Hilfsanträge 1 und 2. Im Hinblick auf Anspruch 1 der damaligen Hilfsanträge 3, 4a, 5a gelangte die Einspruchsabteilung zu dem Ergebnis, dass ihr Gegenstand nicht neu sei im Hinblick auf die offenkundige Vorbenutzung "Asimon". Hinsichtlich Anspruch 1 des damaligen Hilfsantrags 6a gelangte die Einspruchsabteilung zu dem Ergebnis, dass sein Gegenstand nicht auf einer erfinderischen Tätigkeit im Hinblick auf die Kombination der offenkundigen Vorbenutzungen "Asimon" und "ELOP II" beruhe.

Die Einspruchsabteilung hat außerdem in Hinblick auf Anspruch 1 des damaligen Hilfsantrags 3 den Einspruchsgrund des Ausschlusses von der Patentierbarkeit gemäß Artikel 52 (2)c) EPÜ ins Verfahren eingeführt und geprüft und ist zu dem Ergebnis gelangt, dass ein solcher Ausschluss nicht vorliegt.

II. Gegen diese Entscheidung legte die Beschwerdeführerin (Patentinhaberin) mit einem am 9. September 2008 eingegangenen Schreiben Beschwerde ein. Die Beschwerdebegründung wurde fristgerecht eingereicht. Es wurde beantragt, die angefochtene Entscheidung aufzuheben und das Patent in der erteilten Fassung bzw. hilfsweise auf der Grundlage der Ansprüche gemäß Hilfsanträgen B1 bis B5, eingereicht mit der Beschwerdebegründung, aufrechtzuerhalten. Hilfsweise wurde eine mündliche Verhandlung beantragt.

III. Die Einsprechende 1 (Beschwerdegegnerin 1; Leuze electronic GmbH + Co. KG als Rechtsnachfolgerin von Leuze lumiflex GmbH + Co. KG) hat in einem Schreiben vom 12. März 2009 (eingegangen am 16. März 2009) zur Beschwerde Stellung genommen und die Zurückweisung der Beschwerde beantragt. Hilfsweise wurde eine mündliche Verhandlung beantragt.

IV. Die Einsprechende 2 (Beschwerdegegnerin 2; Sick AG) hat in einem Schreiben vom 25. März 2009 zur Beschwerde Stellung genommen und implizit die Zurückweisung der Beschwerde beantragt. Hilfsweise wurde eine mündliche Verhandlung beantragt.

V. Gegen die Beschwerdegegnerin 2 wurde von der Patentinhaberin Klage wegen Verletzung des Streitpatents vor dem Landgericht Düsseldorf erhoben, über die mit Urteil, verkündet am 13. Februar 2007, entschieden wurde (Anlage E31 der Unterlagen des Einspruchsverfahrens).

VI. Die Kammer lud die Parteien mit Schreiben vom 27. April 2011 zur mündlichen Verhandlung. In einem den Parteien zugestellten Bescheid gemäß Artikel 15 (1) der Verfahrensordnung der Beschwerdekammern nahm die Kammer zum Sachverhalt vorläufig Stellung.

VII. Die Beschwerdeführerin hat in einem Schreiben vom 8. Oktober 2011 (eingegangen am 9. Oktober 2011) zu dem Bescheid Stellung genommen und geänderte Hilfsanträge B1a, B2a, B2b, B3b und B4b eingereicht, die dem Verfahren anstelle der mit der Beschwerdebegründung vorgelegten Hilfsanträge B1 bis B5 zugrunde gelegt werden sollen. Ferner reichte sie die technischen Unterlagen PilzD4 bis PilzD7 ein.

VIII. Die Beschwerdegegnerin 2 hat mit Schreiben vom 18. Oktober 2011 zu dem Schreiben und den neu eingereichten Hilfsanträgen der Beschwerdeführerin Stellung genommen.

Die Beschwerdegegnerin 1 hat mit Schreiben vom 20. Oktober 2011 zu dem Schreiben und den neu eingereichten Hilfsanträgen der Beschwerdeführerin Stellung genommen und die weiteren Dokumente D16 und D17 eingereicht.

IX. Die mündliche Verhandlung vor der Kammer fand am 9. und 11. November 2011 statt. In ihrem Verlauf reichte die Beschwerdeführerin zwei Anspruchssätze gemäß Hilfsanträgen 1* und 2* ein und beantragte die Aufhebung der angefochtenen Entscheidung und die Aufrechterhaltung des Patents wie erteilt oder gemäß Hilfsantrag 1* oder 2*. Die Beschwerdegegnerinnen beantragten die Zurückweisung der Beschwerde.

Nach Beendigung der sachlichen Debatte und Beratung der Kammer verkündete der Vorsitzende die Entscheidung der Kammer.

X. Anspruch 1 gemäß Hauptantrag entspricht Anspruch 1 der erteilten Fassung und lautet wie folgt:

"Verfahren zum Programmieren einer Sicherheitssteuerung (18), mit den Schritten:

- Festlegen von logischen Verknüpfungen zwischen Eingangssignalen (28) der Sicherheitssteuerung (18) und

- Zuordnen von Verknüpfungsprodukten (M4, M5) zu Ausgangssignalen (32) der Sicherheitssteuerung (18),

wobei das Festlegen der Verknüpfungen und das Zuordnen anhand vordefinierter funktionsspezifischer Programmodule (62-72, 76-80) erfolgt, die aus einer Menge (60) derartiger Programmodule ausgewählt werden, dadurch gekennzeichnet, dass jedes ausgewählte Programmodul (76, 78, 80) eindeutig einer definierten Funktionsgruppe (54, 56, 58) zugeordnet wird, wobei eine erste Funktionsgruppe (54) Programmodule (76) enthält, die Eingangssignale (28) der Sicherheitssteuerung (18) aufnehmen und in Abhängigkeit davon erste Zwischengrössen (M1, M2, M3) bereitstellen, wobei eine zweite Funktionsgruppe (56) Programmodule (78) enthält, die die ersten Zwischengrössen (M1, M2, M3) logisch miteinander verknüpfen und in Abhängigkeit davon zweite Zwischengrössen (M4, M5) bereitstellen, wobei eine dritte Funktionsgruppe (58) Programmodule (80) enthält, die die zweiten Zwischengrössen (M4, M5) den Ausgangssignalen (32) der Sicherheitssteuerung (18) zuordnen, und wobei jedes Programmodul (76) der ersten Funktionsgruppe (54) eine definierte Signalquelle (30) fehlersicher auswertet."

Anspruch 1 gemäß Hilfsantrag 1* umfasst im Wesentlichen folgende zusätzlichen Merkmale:

"wobei die Programmodule (62-72, 76-80) mittels graphischer Symbole auf einer graphischen Benutzeroberfläche (50) dargestellt und mittels einer Drag & Drop-Funktion (74) ausgewählt werden, und wobei die Darstellung eines ausgewählten Programmoduls (76, 78, 80) auf der Benutzeroberfläche (50) aus einem abgespeicherten, zugehörigen Programmodul-Funktionsaufruf generiert wird."

Anspruch 1 gemäß Hilfsantrag 2* umfasst neben den Merkmalen von Anspruch 1 gemäß Hilfsantrag 1* im wesentlichen die Merkmale, dass die Programmodule "zu einem Anwenderprogramm verknüpft werden, wobei mindestens ein Programmodul ausgebildet ist, einen Not-Aus-Taster eigenständig fehlersicher auszuwerten" und dass jedes Programmodul der ersten Funktionsgruppe "als erste Zwischengröße (M1, M2, M3) eine fehlersichere Information darüber liefert, in welchem Zustand sich die definierte Signalquelle (30) befindet, so dass die erste Zwischengröße (M1, M2, M3) eine physikalische Bedeutung besitzt". Ferner erfolgt die fehlersichere Auswertung einer definierten Signalquelle "eigenständig".

Entscheidungsgründe

1. Vorbemerkungen

1.1 Bei dem in Anspruch 1 aller Anträge beanspruchten Verfahren handelt es sich um ein Verfahren zum Programmieren einer Sicherheitssteuerung. Dabei werden ausgewählte Programmodule, die gemäß Anspruch 1 des Hilfsantrags 2* zu einem Anwenderprogramm verknüpft werden, drei Funktionsgruppen, nämlich einer ersten Funktionsgruppe, die Eingangssignale aufnimmt und erste Zwischengrößen bereitstellt, einer zweiten Funktionsgruppe, die die ersten Zwischengrößen logisch miteinander verknüpft und zweite Zwischengrößen bereitstellt, und einer dritten Funktionsgruppe, die die zweiten Zwischengrößen Ausgangssignalen zuordnet, eindeutig zugeordnet.

Gemäß Streitpatent bewirkt die dadurch erreichte Zuordnung eines ausgewählten Programmoduls zu einer definierten Funktionsgruppe eine sehr übersichtliche und strukturierte Programmierung der Sicherheitssteuerung, wodurch Fehler beim Programmieren reduziert werden (Absatz [0013] des Streitpatents).

1.2 Die Kammer stellt fest, dass die Form der Zuordnung zu den Funktionsgruppen in dem beanspruchten Verfahren in keinem der Anträge näher bestimmt ist.

2. Anspruch 1 (Hauptantrag): Neuheit (Artikel 54 EPÜ)

2.1 Die Kammer geht von der offenkundigen Vorbenutzung "Asimon" als nächstliegendem Stand der Technik aus. Bei dieser Vorbenutzung handelt es sich um den sogenannten AS-i Sicherheitsmonitor, kurz "Asimon", der eine Vorrichtung zur Programmierung von Sicherheitssteuerungen bildet. Diese setzt auf dem AS-i (Aktuator-Sensor-Interface)-Bus auf und steuert und überwacht sicherheitsgerichtete Komponenten in einem auf diesem Bus basierenden Netz. Der Funktionsumfang des "Asimon" ist in der vom 31. August 2000 datierenden Spezifikation der Funktionsbausteine, während des Einspruchsverfahrens eingereicht als Dokument D7, beschrieben. Ferner sind für diese Entscheidung relevante Bestandteile dieser Vorbenutzung Unterlagen einer Präsentation datierend vom 30./31. Oktober 2000 als Dokument D10 und ein Vortrag von Herrn Rolf Becker "AS-i Safety at Work Die letzte Domäne der herkömmlichen Verdrahtung fällt", veröffentlicht im SPS-Magazin, Ausgabe 11/2000, als D15, beide ebenfalls während des Einspruchsverfahrens eingereicht.

Der Status dieser Vorbenutzung als Stand der Technik wurde nicht bestritten.

2.2 Insbesondere umfasst die offenkundige Vorbenutzung "Asimon" ein Verfahren zum Programmieren einer Sicherheitssteuerung, nämlich des Sicherheitsmonitors (auch "Safety at Work", siehe D10, Seite 11: "lässt sich ... schnell und einfach konfigurieren"). Dabei werden Slaves, die mit Sensoren und somit mit Eingangssignalen verbunden sind (D10, Seite 6), Ausgangsschaltelementen zugeordnet (D10, Seite 11), die zwangsläufig Ausgangssignale ausgeben (siehe auch D7, Seite 3 (die Kammer übernimmt die angegebene Seitennummerierung beginnend mit Seite 1 von 45), Kapitel 3.1, Zeilen 1-3 und D15, Seite 2, letzter Absatz). Dies erfolgt unter Verwendung logischer Verknüpfungen (D10, Seite 6 und D7, Seite 4, Abbildung 1).

Somit umfasst das durch die offenkundige Vorbenutzung "Asimon" bekannte Verfahren die Schritte:

- Festlegen von logischen Verknüpfungen zwischen Eingangssignalen der Sicherheitssteuerung und

- Zuordnen von Verknüpfungsprodukten zu Ausgangssignalen der Sicherheitssteuerung.

Die Abbildung 1 auf Seite 4 von D7 zeigt den Ablauf der Auswertung im Sicherheitsmonitor. Die Blöcke der dort gezeigten Funktionen hat der Anwender in der Konfigurationsphase ausgewählt und parametriert (D7, Seite 3, Absatz 3.2, Zeilen 1 und 2). Das Ablaufprogramm entsteht somit durch das Festlegen der Verknüpfungen und das Zuordnen anhand vordefinierter funktionsspezifischer Programmodule, die aus einer Menge derartiger Programmodule ausgewählt werden.

Ferner sind, wie in der Abbildung 1 auf Seite 4 von D7 zu erkennen, die ausgewählten Programmodule eindeutig einer definierten Funktionsgruppe zugeordnet, wobei eine erste Funktionsgruppe Programmodule enthält, die Eingangssignale der Sicherheitssteuerung aufnehmen. Hierbei handelt es sich um Module Monitor, Tür 1, Tür 2, Notaus, EDM (siehe auch D7, Kapitel 4.1). Wie weiter in der Abbildung 1 erkennbar, stellen die Programmodule in Abhängigkeit von den Eingangssignalen erste Zwischengrößen bereit. Eine zweite Funktionsgruppe enthält Programmodule, die die ersten Zwischengrößen logisch miteinander verknüpfen und in Abhängigkeit davon zweite Zwischengrößen bereitstellen. Hierbei handelt es sich in Abbildung 1 um die Programmodule OR und AND (siehe auch D7, Kapitel 4.2). Eine dritte Funktionsgruppe enthält Programmodule, die die zweiten Zwischengrößen den Ausgangssignalen der Sicherheitssteuerung zuordnen. Hierbei handelt es sich in Abbildung 1 um die Programmodule Zeitgeber und Relais (siehe auch D7, Kapitel 4.5).

Die Kammer geht hierbei davon aus, dass die Zuordnung der ausgewählten Programmodule zu einzelnen Funktionsgruppen allein schon dadurch entsteht, dass diese Programmodule, wie in Abbildung 1 zu sehen, mit ihrer Funktion als Tür, Not-Aus, OR, AND usw. gekennzeichnet werden. In den Kapiteln 4.1, 4.2 und 4.5 von D7 werden diese Bausteine als Überwachungsbausteine, Verknüpfungsbausteine beziehungsweise als Zeitgeber-Funktionsbausteine gruppenweise beschrieben. Dadurch sind sie eindeutig einer Funktionsgruppe zugeordnet.

Ferner ergibt sich aus den auf Seite 45 von D7 dargestellten Konfigurationsregeln, dass beim Konfigurieren des Sicherheitsmonitors, also beim Programmieren der Sicherheitssteuerung, Regeln überprüft werden, deren zweite "Es gibt mindestens einen Überwachungsbaustein", fünfte "Es gibt mindestens eine Startfunktion für jeden unabhängigen Ausgangskreis" und siebte und achte "Es gibt genau eine Zeitgeberfunktion für jeden unabhängigen Ausgangskreis" und "Die Zeitgeberfunktion steht am Ende" das Vorhandensein von Funktionsgruppen, die den beanspruchten ersten bis dritten Funktionsgruppen entsprechen, erfordern. Durch die in Abbildung 1 auf Seite 4 von D7 ersichtliche Bezeichnung der Programmodule in Verbindung mit den in den Kapiteln 4.1, 4.2 und 4.5 aufgeführten Zuordnungen der Programmodule zu Funktionsgruppen wird durch die aus Seite 45 von D7 aufgestellten Konfigurationsregeln gewährleistet, dass die Funktionsgruppen, die den beanspruchten ersten bis dritten Funktionsgruppen entsprechen, tatsächlich ausgewählte Programmodule enthalten.

Schließlich wertet jedes Programmodul der ersten Funktionsgruppe eine definierte Signalquelle aus. Hierbei geht die Kammer davon aus, dass die als sichere Slaves bezeichneten Vorrichtungen, von denen auf Seite 6 von D10 ein Beispiel gezeigt ist, einer definierten Signalquelle entsprechen. Eine Einschränkung nur auf den Sensorteil des Slaves, wie ursprünglich von der Beschwerdeführerin vorgeschlagen, ist vom Anspruchswortlaut nicht gedeckt. Ferner ist das sichere AS-Interface-System von "Asimon" für Sicherheitsanwendungen bis Kategorie 4 nach EN 954-1 vorgesehen (D7, Seite 1, Absatz 1.2). Dies entspricht den im Streitpatent erwähnten, für Sicherheitssteuerungen erforderlichen Sicherheitsnormen (Absatz [0005]). Daraus ergibt sich, dass die Auswertung der definierten Signalquellen fehlersicher erfolgt. Dies steht im Einklang mit der Auffassung des Landgerichts Düsseldorf, dass die als Patentverletzung angegriffene Ausführungsform der Kategorie 4 nach EN 954-1 entspricht und die Signalquelle daher fehlersicher auswertet (D31, Seite 22, letzter Absatz und Seite 23, erster Absatz). Die fehlersichere Auswertung wird gemäß "Asimon" dadurch erreicht, dass, wie auf Seite 6 von D10 beispielhaft zu sehen ist, im Sicherheitsmonitor eine Auswertung von zweikanalig von dem sicheren Slave mit seinem Sensor übertragenen digitalen Signalen durchgeführt wird, wobei durch das Verwenden eines definierten Algorithmus zur dynamischen Erzeugung eines Vier-Bit-Datentelegramms im Normalbetrieb des Slaves eine sichere Überprüfung seiner Funktion gewährleistet wird und der Sicherheitsmonitor in all den Teilen redundant ausgelegt ist, die nicht durch den dynamischen Datentransfer kontrolliert werden können (D15, letzter Satz).

2.3 Da alle Merkmale des Anspruchs 1 gemäß Hauptantrag aus der offenkundigen Vorbenutzung "Asimon" bekannt sind, ist der beanspruchte Gegenstand nicht neu (Artikel 52 (1) und 54 (1) und (2) EPÜ).

2.4 Dagegen argumentiert die Beschwerdeführerin im Wesentlichen, dass gemäß "Asimon" keine Gruppierung von ausgewählten Programmodulen stattfände und die Überwachungs- und Verknüpfungsbausteine, wie z.B. in Abbildung 1 auf Seite 4 von D7 gezeigt, in beliebiger Reihenfolge, also nicht gruppiert, angeordnet wären. Eine patentgemäße Gruppierung von ausgewählten Programmodulen sei weder realisiert noch vorgesehen und auch die Überprüfung der typgerechten Verwendung entsprechend den Konfigurationsregeln in Kapitel 5 von D7 könne eine solche Gruppierung nicht gewährleisten (Punkte 6.5 und 6.6 der Beschwerdebegründung).

Die Kammer konnte dieser Argumentation nicht folgen, da sie ein bestimmtes Verständnis des Begriffs "Gruppierung" voraussetzt, das vom Wortlaut des Anspruchs 1 nicht gedeckt ist und auch durch die Beschreibung des Streitpatents nicht gestützt wird.

Wie schon oben unter Punkt 2.2 ausgeführt, ist die Zuordnung von Programmodulen zu einer Funktionsgruppe dadurch erfüllt, dass die Programmodule eindeutig als Teil einer Gruppe erkennbar sind. Wie dies erreicht wird, sei es durch die Bezeichnung der Programmodule wie in D7, durch eine farbliche Kennzeichnung oder durch räumliche Anordnung, wie in Figur 2 des Streitpatents, spielt keine Rolle, da die patentgemäß gestellte Aufgabe unabhängig davon gelöst wird, wie eine solche Gruppierung konkret erreicht wird. Allein schon durch die Zuordnung eines ausgewählten Programmoduls zu einer definierten Funktionsgruppe als solche wird eine sehr übersichtliche und strukturierte Programmierung der Sicherheitssteuerung bewirkt, so dass Fehlermöglichkeiten beim Programmieren reduziert werden (Absatz [0013] des Streitpatents).

Somit ergibt sich, dass auch für den verständigen Leser des Streitpatents in seiner Gesamtheit die beanspruchte Zuordnung von Programmodulen zu Funktionsgruppen in dem Sinne auszulegen ist, dass sie die Zuordnung der Programmodule zu Funktionsgruppen durch entsprechendes Bezeichnen mitumfasst.

An ihrem in der Beschwerdebegründung geäußerten Einwand, dass gemäß "Asimon" keine fehlersichere Auswertung definierter Signalquellen durch Programmodule der ersten Funktionsgruppe erfolge und statt dessen eine fehlersichere Signalverarbeitung in den vorgesehenen Slaves statt fände, die nicht programmiert würden (Punkt 6.4 der Beschwerdebegründung), hielt die Beschwerdeführerin im Hinblick darauf, dass die sicheren Slaves, wie sie beispielhaft auf Seite 6 von D10 abgebildet sind, in ihrer Gesamtheit als definierte Signalquelle im Sinne des Anspruchs zu betrachten sind, nicht mehr fest.

2.5 Da dem Gegenstand von Anspruch 1 gemäß Hauptantrag somit die erforderliche Neuheit fehlt, ist der Antrag nicht gewährbar.

3. Hilfsantrag 1*, erfinderische Tätigkeit (Artikel 56 EPÜ)

3.1 Anspruch 1 gemäß Hilfsantrag 1* umfasst neben den Merkmalen von Anspruch 1 des Streitpatents auch die Merkmale der abhängigen Ansprüche 6, 7 und 9 des Streitpatents.

Von diesen Merkmalen ist das Merkmal "wobei die Programmodule mittels graphischer Symbole auf einer graphischen Benutzeroberfläche dargestellt und mittels einer Drag & Drop-Funktion ausgewählt werden" unstreitig aus der offenkundigen Vorbenutzung "Asimon" (siehe D10, Seite 11: "Per Drag&Drop lässt sich Safety at Work schnell und einfach konfigurieren") bekannt.

Das weitere Merkmal "wobei die Darstellung eines ausgewählten Programmoduls auf der Benutzeroberfläche aus einem abgespeicherten, zugehörigen Programmodul-Funktionsaufruf generiert wird" bedeutet, dass nach Auswahl eines Programmoduls ein zugehöriger Programmodul-Funktionsaufruf (durch den das entsprechende Programmodul aufgerufen wird, wie z.B. in Absatz [0007] des Streitpatents in Hinblick auf den Stand der Technik erklärt) in einem (beliebigen) Speicher (in einem beliebigen Format) gespeichert wird. Die Darstellung der ausgewählten Programmodule auf der graphischen Benutzeroberfläche wird durch die abgespeicherten Programmodul-Funktionsaufrufe erzeugt. Die eigentlichen Programmodule können in einem anderen Speicher und in einem anderen Format gespeichert sein, wie sich z.B. aus Absatz [0020] des Streitpatents ergibt. Auszugehen ist dabei davon, dass die Darstellung eine graphische ist, da sich anders die Auswahl von Programmodulen mittel Drag & Drop schwerlich vorstellen lässt.

Dieses Merkmal soll laut Beschwerdeführerin die Verifikation des tatsächlich erstellten Anwenderprogramms deutlich vereinfachen, wodurch Fehler beim Programmieren nochmals reduziert werden (siehe Absatz [0032] des Streitpatents).

3.2 Ein solches Merkmal ist nicht unmittelbar der offenkundigen Vorbenutzung "Asimon" zu entnehmen. Aus Seite 11 von D10 ergibt sich zwar, dass ein Protokoll der Konfiguration erstellt wird. Ein solches Protokoll enthält sicher Informationen über die ausgewählten Programmodule. Seine Darstellung wird aber nicht notwendigerweise aus einem Programmodul-Funktionsaufruf erzeugt noch ist sie notwendigerweise graphisch.

Folglich ist der beanspruchte Gegenstand neu gegenüber der Lehre der offenkundigen Vorbenutzung "Asimon". Dies wurde auch von den Beschwerdegegnerinnen nicht anders gesehen.

3.3 Jedoch ist es für eine Auswahl mittels Drag & Drop, wie sie auch in der offenkundigen Vorbenutzung "Asimon" verwendet wird, technisch notwendig, dass die auf der graphischen Benutzeroberfläche mittels graphischer Symbole dargestellten Programmodule vor, während und nach ihrer Auswahl in geeigneter Form in einem geeigneten Speicher vorliegen und die angezeigten graphischen Symbole von diesen Modulen erzeugt werden. Das liegt in der Natur einer graphischen Benutzeroberfläche, wie sie auch in "Asimon" verwendet wird. Von dieser technischen Notwendigkeit unterscheidet sich das beanspruchte Merkmal nur dadurch, dass es die Darstellung der ausgewählten Programmodule durch abgespeicherte, zugehörige Programmodul-Funktionsaufrufe vorsieht. Die Erzeugung durch abgespeicherte Programmodul-Funktionsaufrufe bringt den Vorteil, dass die Programmodule als solche an ihren Speicherplätzen verbleiben können, wodurch der benötigte Speicherplatz klein gehalten und eine mögliche Fehlerquelle ausgeschlossen wird (Absatz [0020] des Streitpatents).

In einem Programm, wie zum Beispiel bei der hier zu programmierenden Sicherheitssteuerung, Programmodule durch Programmaufrufe in das Programm einzubinden, womit die Programmodule als solche in einem geeigneten Speicher verbleiben, stellt jedoch eine fachübliche Programmiermaßnahme dar, die keine erfinderische Tätigkeit (Artikel 56 EPÜ) begründen kann.

3.4 Die Beschwerdeführerin berief sich in ihrer Argumentation im wesentlichen auf Absatz [0032] des Streitpatents, demzufolge das Merkmal der Erzeugung der Darstellung eines ausgewählten Programmoduls aus einem abgespeicherten, zugehörigen Programmodul-Funktionsaufruf erst nach einem Umweg visualisiert würde. Dieser Umweg bestünde darin, zunächst den Programmodul-Funktionsaufruf in einem Format, in dem er der Sicherheitssteuerung zugeführt wird, in der Sicherheitssteuerung selbst abzuspeichern, und dann anschließend die Darstellung des ausgewählten Programmoduls aus dem abgespeicherten Programmodul-Funktionsaufruf zu generieren. Somit entspreche die Visualisierung stets dem tatsächlich in der Sicherheitssteuerung abgespeicherten Programmodul-Funktionsaufruf, wodurch Fehler beim Programmieren erheblich reduziert würden.

Die Kammer kann diesem Argument nicht folgen, da der angesprochene Umweg nicht erkennbar ist. Wie schon unter Punkt 3.3 ausgeführt, ist es eine technische Notwendigkeit, dass die auf der graphischen Benutzeroberfläche mittels graphischer Symbole dargestellten Programmodule vor, während und nach ihrer Auswahl in geeigneter Form in einem geeigneten Speicher vorliegen und die angezeigten graphischen Symbole von diesen Modulen erzeugt werden. Somit ist das Abspeichern von - in diesem Falle - Programmodul-Funktionsaufrufen kein Umweg sondern notwendig. Die Kammer versteht die Beschwerdeführerin dahingehend, dass die Abspeicherung in einem bestimmten Format, nämlich demjenigen, das der Sicherheitssteuerung zugeführt wird, erfolgen soll. Ein solches Merkmal ist jedoch nicht Gegenstand des Anspruchs. Ebenso wenig ist die Abspeicherung des Programmodul-Funktionsaufrufs in der Sicherheitssteuerung Gegenstand des Anspruchs. Dieses Merkmal folgt noch nicht einmal aus der Beschreibung; ein Umstand, auf den die Kammer während der mündlichen Verhandlung hinwies.

3.5 Da der Gegenstand von Anspruch 1 gemäß Hilfsantrag 1* keine erfinderische Tätigkeit aufweist, ist der Antrag nicht gewährbar.

4. Hilfsantrag 2*, erfinderische Tätigkeit (Artikel 56 EPÜ)

4.1 Anspruch 1 gemäß Hilfsantrag 2* umfasst neben den Merkmalen von Anspruch 1 gemäß Hilfsantrag 1* im wesentlichen die Merkmale, dass die Programmodule "zu einem Anwenderprogramm verknüpft werden, wobei mindestens ein Programmodul ausgebildet ist, einen Not-Aus-Taster eigenständig fehlersicher auszuwerten" und dass jedes Programmodul der ersten Funktionsgruppe "als erste Zwischengröße (M1, M2, M3) eine fehlersichere Information darüber liefert, in welchem Zustand sich die definierte Signalquelle (30) befindet, so dass die erste Zwischengröße (M1, M2, M3) eine physikalische Bedeutung besitzt". Ferner erfolgt die fehlersichere Auswertung einer definierten Signalquelle "eigenständig".

4.2 Hinsichtlich des Merkmals, dass die Programmodule zu einem Anwenderprogramm verknüpft sind, ist festzustellen, dass dies auch gemäß der offenkundigen Vorbenutzung "Asimon" der Fall ist, wie sich z.B. aus Seite 11 von D10 ergibt, wobei dort "Konfiguration" mit "Anwenderprogramm" gleichzusetzen ist. Dies wurde auch nicht bestritten.

Auch das Merkmal, dass mindestens ein Programmodul ausgebildet ist, einen Not-Aus-Taster eigenständig fehlersicher auszuwerten, ist aus der offenkundigen Vorbenutzung "Asimon" bekannt, wie sich z.B. aus der Auflistung der Überwachungsbausteine auf Seite 7 von D7 ergibt. Weitere Hinweise ergeben sich aus dem letzten Absatz auf Seite 2 von D15 und aus Seite 5 von D10. Hierbei ist in Einklang mit dem vorstehenden Verständnis (siehe Punkt 2.2 oben) zu berücksichtigen, dass gemäß der offenkundigen Vorbenutzung "Asimon" ein sicherer Slave, wie er allgemein auf Seite 6 von D10 gezeigt ist, einer definierten Signalquelle entspricht, und als solcher die erforderlichen Eingangssignale liefert, die von einem entsprechenden Programmodul im Sicherheitsmonitor fehlersicher ausgewertet werden, wie z.B. im letzten Absatz auf Seite 2 von D15 deutlich gemacht wird.

Das Merkmal, dass jedes Programmodul der ersten Funktionsgruppe als erste Zwischengröße eine fehlersichere Information darüber liefert, in welchem Zustand sich die definierte Signalquelle befindet, so dass die erste Zwischengröße eine physikalische Bedeutung besitzt, ergibt sich ebenfalls aus der offenkundigen Vorbenutzung "Asimon". Dies wird im letzten Absatz auf Seite 2 von D15 deutlich, aus dem hervorgeht, dass ein Datentelegramm 0-0-0-0 vom Sicherheitsmonitor als Not-Aus gedrückt interpretiert wird, also das entsprechende Programmodul des Sicherheitsmonitor als Zwischengröße eine Information liefert, die den Zustand des Not-Aus-Schalters, in diesem Falle "gedrückt", angibt. Dies trifft auch für die anderen, in Kapitel 4.1 von D7 aufgeführten Signalquellen zu.

Auch das Merkmal, dass jedes Programmodul der ersten Funktionsgruppe eine definierte Signalquelle "eigenständig" fehlersicher auswertet, ist aus der offenkundigen Vorbenutzung "Asimon" bekannt. Dieses Merkmal folgt z.B. aus dem letzten Absatz auf Seite 2 von D15, demzufolge der Sicherheitsmonitor ohne erkennbare Intervention zusätzlicher Elemente oder Module und somit "eigenständig" allein auf der Basis der Eingangssignale des Sicherheits-Slaves sicherheitsgerichtete Ausgänge abschaltet. Auch hierbei ist in Einklang mit dem vorstehenden Verständnis (siehe Punkt 2.2 oben) zu berücksichtigen, dass gemäß der offenkundigen Vorbenutzung "Asimon" ein sicherer Slave eine definierten Signalquelle darstellt.

4.3 Da alle Merkmale von Anspruch 1 gemäß Hilfsantrag 2*, die über die Merkmale von Anspruch 1 gemäß Hilfsantrag 1* hinausgehen, aus der offenkundigen Vorbenutzung "Asimon" bekannt sind, erfüllt auch Anspruch 1 gemäß Hilfsantrag 2* nicht das Erfordernis nach einer erfinderischen Tätigkeit (Artikel 56 EPÜ).

Daher ist der Hilfsantrag 2* nicht gewährbar.

5. Damit liegt insgesamt kein gewährbarer Antrag vor.

ENTSCHEIDUNGSFORMEL

Aus diesen Gründen wird entschieden:

Die Beschwerde wird zurückgewiesen.