Beschwerde-Aktenzeichen: T 1367/22 - 3.5.05
E N T S C H E I D U N G
der Technischen Beschwerdekammer 3.5.05 vom 15. März 2024 Beschwerdeführerin:
(Patentinhaberin) Siemens Aktiengesellschaft Werner-von-Siemens-Straße 1 80333 München (DE) Vertreter:
Siemens Patent Attorneys Postfach 22 16 34 80506 München (DE) Beschwerdegegnerin:
Grosse von Hirschhausen Patentdienst GmbH Nymphenburger Str. 14 80335 München (DE) (Einsprechende) Vertreter:
Wittmer, Maximilian Grosse - Schumacher Knauer - von Hirschhausen Patent- und Rechtsanwälte Nymphenburger Straße 14 80335 München (DE) Angefochtene Entscheidung:
Entscheidung der Einspruchsabteilung des Europäischen Patentamts, die am 1. April 2022 zur Post gegeben wurde und mit der das europäische Patent Nr. 3182235 aufgrund des Artikels 101 (3) (b) EPÜ widerrufen worden ist.
Zusammensetzung der Kammer:
Vorsitzender Mitglieder:
K. Bengi-Akyürek K. Schenkel R. Romandini
Sachverhalt und Anträge
I. Die Beschwerde der Patentinhaberin richtet sich gegen die Entscheidung der Einspruchsabteilung, das Streitpatent wegen mangelnder Neuheit bzw. mangelnder erfinderischer Tätigkeit zu widerrufen.
II. Die Beschwerdeführerin (Patentinhaberin) beantragte, die Entscheidung der Einspruchsabteilung aufzuheben und das Patent auf der Grundlage der Ansprüche des Hauptantrags (Patent wie erteilt), hilfsweise der Ansprüche eines der Hilfsanträge 1 bis 3 aufrechtzuerhalten.
III. Die Beschwerdegegnerin (Einsprechende) beantragte, die Beschwerde zurückzuweisen.
IV. Der folgende Stand der Technik ist für die vorliegende Entscheidung relevant:
D5:
D9:
WO 2015/188852 A1 "Handbuch TwinCAT - TC3 OPC-UA"; Version 1.6; Beckhoff; 25. August 2018. V. Am 15. März 2024 fand eine mündliche Verhandlung vor der Kammer statt, an deren Ende die Entscheidung der Kammer verkündet wurde.
VI. Anspruch 1 des Hauptantrags hat folgenden Wortlaut (Merkmalsgliederung der Kammer):
a) "Verfahren zum Aufruf einer Funktion (FB) eines Steuerungsprogramms (PRG) einer industriellen Steuerung (PLC), b) c) d) e) VII. wobei die industrielle Steuerung (PLC) einen OPC UA Server aufweist, wobei die industrielle Steuerung (PLC) mittels des OPC UA Kommunikationsprotokolls mit einem OPC UA Client kommuniziert, und wobei die Funktion (FB) durch einen OPC UA Aufruf des OPC UA Clients aufgerufen wird, dadurch gekennzeichnet, dass zum Aufruf der Funktion (FB) i) - in einem ersten Schritt ein darauf gerichteter OPC UA Aufruf von dem OPC UA Client an den OPC UA Server der industriellen Steuerung (PLC) gesendet wird, ii) - in einem zweiten Schritt der OPC UA Aufruf durch ein Systemprogramm der industriellen Steuerung (PLC) gespeichert wird, iii) - in einem dritten Schritt an einer definierten Stelle eines industriellen Steuerungsprogramms (PRG) eine Systemfunktion (OPC UA Call) des Systemprogramms (PRG) aufgerufen wird, wobei die Systemfunktion (OPC UA Call) überprüft, ob ein OPC UA Aufruf gespeichert ist, und iv) - in einem vierten Schritt bei Vorliegen eines OPC UA Aufrufs die mit diesem Aufruf verknüpfte Funktion (FB) des Steuerungsprogramms (PRG) aufgerufen wird, und anderenfalls das industrielle Steuerungsprogramm (PRG) ohne Verzweigung zu der Funktion (FB) fortgesetzt wird."
Anspruch 1 von Hilfsantrag 1 unterscheidet sich von Anspruch 1 des Hauptantrags dadurch, dass am Ende von Merkmal d) "dadurch gekennzeichnet" gestrichen, am Anfang von Merkmal e) "dass" durch "wobei" ersetzt und am Ende folgendes Merkmal hinzugefügt worden ist (Merkmalsgliederung der Kammer):
f) VIII. Anspruch 1 von Hilfsantrag 2 unterscheidet sich von Anspruch 1 von Hilfsantrag 1 dadurch, dass am Anfang von Merkmal f) "dadurch gekennzeichnet, dass" durch "wobei" ersetzt und am Ende folgendes Merkmal hinzugefügt worden ist (Merkmalsgliederung der Kammer:
g) IX. "dadurch gekennzeichnet, dass zum Aufruf der Systemfunktion (OPC UA Call) des Systemprogramms ein Befehl in einer Programmiersprache des industriellen Steuerungsprogramms (PRG) definiert und abgearbeitet wird." "dadurch gekennzeichnet, dass der Befehl einen Rückgabewert aufweist, wobei mittels des Rückgabewertes durch das Steuerungsprogramm (PRG) entschieden wird, ob die Funktion (FB) aufgerufen wird oder nicht."
Anspruch 1 von Hilfsantrag 3 hat folgenden Wortlaut (Merkmalsgliederung der Kammer):
a) b) c) "Industrielle Steuerung (PLC) mit einem OPC UA Server, wobei die industrielle Steuerung (PLC) zum Ablauf eines industriellen Steuerungsprogramms (PRG) eingerichtet ist, wobei die industrielle Steuerung (PLC) zur Kommunikation mit einem OPC UA Client mittels des OPC UA Kommunikationsprotokolls eingerichtet ist, und d) e) f) g) h) i) j) k) l) wobei eine Funktion (FB) des industriellen Steuerungsprogramms (PRG) mittels eines OPC UA Aufrufs aufrufbar ist, der OPC UA Server zum Empfang eines auf den Aufruf der Funktion (FB) gerichteten OPC UA Aufrufs von dem OPC UA Client eingerichtet ist, dass die industrielle Steuerung (PLC) zur Speicherung des OPC UA Aufrufs mittels eines Systemprogramms der industriellen Steuerung (PLC) eingerichtet ist, dass die industrielle Steuerung (PLC) derart eingerichtet ist, dass an einer definierten Stelle des industriellen Steuerungsprogramms (PRG) eine Systemfunktion (OPC UA Call) des Systemprogramms aufgerufen wird, wobei die Systemfunktion (OPC UA Call) dazu eingerichtet ist, auf das Vorliegen eines OPC UA Aufrufs zu prüfen, und dass die industrielle Steuerung (PLC) derart eingerichtet ist, dass bei Vorliegen eines OPC UA Aufrufs bei dieser Prüfung die mit diesem Aufruf verknüpfte Funktion (FB) des Steuerungsprogramms (PRG) aufgerufen wird, und anderenfalls nicht, wobei vorgesehen ist, dass zum Aufruf der Systemfunktion (OPC UA Call) des Systemprogramms ein Befehl in einer Programmiersprache des industriellen Steuerungsprogramms (PRG) definiert ist und abgearbeitet wird, dadurch gekennzeichnet, dass weiter vorgesehen ist, dass der Befehl einen Rückgabewert aufweist, wobei mittels des Rückgabewertes durch das Steuerungsprogramm (PRG) entschieden wird, ob die Funktion (FB) aufgerufen wird oder nicht."
Entscheidungsgründe§
1. Hauptantrag - erfinderische Tätigkeit (Artikel 100 a) und 56 EPÜ) 1.1 Technischer Hintergrund des Streitpatents Das Patent betrifft eine industrielle Steuerung, auf der ein "Steuerungsprogramm", ein "Systemprogramm" und ein "OPC UA Server" ablaufen können. Der "OPC UA Server" kann mit einem "OPC UA Client" kommunizieren, der wiederum über diese Verbindung eine "Funktion" der "Steuerung" aufrufen kann. Die "Funktion" wird dabei nicht sofort bei Empfang des "OPC UA Aufrufs" aufgerufen, sondern erst wenn das "Steuerungsprogramm" an einer dafür vorgesehenen Stelle eine "Systemfunktion" des "Systemprogramms" aufruft, die prüft, ob ein "OPC UA Aufruf" empfangen und gespeichert worden ist.
Im Streitpatent wird als Vorteil dieses Verfahrens herausgestellt, dass der Ausführungszeitpunkt der "Funktion" vom "Steuerungsprogramm" festgelegt wird und synchron zu einem Anwenderprogramm ist (Absatz [0010], insbesondere zweite Hälfte).
1.2 Dokument D5 stellt den nächstliegenden Stand der Technik dar und richtet sich ebenso auf ein Steuerungssystem.
1.2.1 Betreffend die Merkmale a) bis d) ist die Steuerung eine industrielle Steuerung, bei der ein "OPC UA Server" und ein "OPC UA Client" gemäß dem "OPC UA Standard" miteinander kommunizieren, wobei ein "OPC UA Aufruf" an den "OPC UA Server" übertragen wird (D5, Anspruch 1). Der "OPC UA Aufruf" wird zunächst simuliert und später ausgeführt, was das Aufrufen einer Funktion impliziert (Seite 8, Zeilen 1 bis 10, Anspruch 5). Dass es sich um eine industrielle Steuerung handelt, belegt auch die angegebene Aufgabe der Ausführungsbeispiele, in der die Ventile zweier Farb- und eines Mischtanks durch drei OPC Server "UA-S1" bis "UA-S3" gesteuert werden, die wiederum durch einen Client "UA-C" angesteuert werden (Seite 6, Zeilen 21 - 34). Auch wenn in der Aufgabe nur die "Server", ein "Client" und die "Ventile" erwähnt werden, können die Server implizit auf die Ventile einwirken, so dass durchaus von einer "industriellen Steuerung" gesprochen werden kann. Das Argument der Patentinhaberin, das Dokument D5 würde keine industrielle Steuerung offenbaren, überzeugt daher nicht.
1.2.2 In Bezug auf die Merkmale e), e)_i) und e)_ii) erzeugt und aktiviert der Client in einem Ausführungsbeispiel eine Sitzung ("Session"), indem er "CreateSession" und "ActivateSession"-Nachrichten an den Server sendet (Seite 7, Zeilen 16 - 25). Danach sendet der Client einen "OPC UA Aufruf", nämlich den Write-Aufruf "Write01", an den Server und erhält zunächst ein simuliertes Ergebnis zurück (Seite 7, Zeilen 25 - 28 und Seite 8, Zeilen 1 - 6, Fig. 2, Anspruch 1). Der Server speichert dann den Write-Aufruf (Seite 7, Zeilen 30 bis 32). Die Speicherung des Write-Aufrufs im Server geschieht implizit durch ein Systemprogramm des Servers.
1.2.3 Bezüglich der Merkmale e)_iii) und e)_iv) werden die "gesammelten" Aufrufe "Write01" und "Write02" erst ausgeführt, wenn der Client einen Befehl "CloseSession" gesendet hat (Seite 8, Zeilen 8 - 15). Dies impliziert die Überprüfung, ob Write-Aufrufe gesammelt bzw. gespeichert wurden. Diese Überprüfung wird allerdings vom "OPC UA Client" durch den Befehl "CloseSession" angestoßen.
1.2.4 Die Kammer teilt nicht die in der angefochtenen Entscheidung angegebene Einschätzung (siehe Gründe 9), dass Merkmal e)_iii) durch die "CloseSession"-Anweisung vorweggenommen wird, da diese nicht an einer definierten Stelle des Steuerungsprogramms der industriellen Steuerung ausgeführt wird.
1.2.5 Die Patentinhaberin argumentierte, dass D5 die Merkmale e)_ii) bis e)_iv) nicht offenbare. Das "Systemprogramm" gehöre zur Steuerung und sei nicht Teil des "Steuerungsprogramms". Es handele sich mithin um zwei verschiedene Programme. Da das Systemprogramm die Prüfung auf gespeicherte "OPC UA Aufrufe" übernehme, würde das Steuerungsprogramm entlastet werden. Eine mit der Erstellung des Steuerungsprogramms beauftragte Person müsste sich daher nicht um die Programmierung dieser Überprüfung kümmern, die eben im Hintergrund ablaufen würde. Das Steuerungsprogramm wäre somit nicht gezwungen, "OPC UA Befehle" verarbeiten zu können.
Die Kammer ist davon nicht überzeugt. Bei dem in Fig. 2 dargestellten Ausführungsbeispiel sind zwei Ablaufstränge abgebildet, nämlich derjenige des OPC UA Servers "UA-S" und der des Produktivsystems "P", die beide auf Seiten der industriellen Steuerung liegen und verschiedene Programme oder zumindest Programmteile darstellen. Die Speicherung der "OPC UA Aufrufe" in Merkmal e)_ii) erfolgt nun im Ablaufstrang "UA-S". Gleiches gilt auch für die "Systemfunktion" gemäß Merkmal e)_iii), die das Vorliegen eines gespeicherten "OPC UA Aufrufs" überprüft, da es auf den Erhalt des Befehls "CloseSession" vom "OPC UA Client" erfolgt. Umgekehrt erfolgt die Funktion in Merkmal e)_iv), die bei Vorliegen eines gespeicherten "OPC UA Aufrufs" aufgerufen wird, im Ablaufstrang "P". Da außerdem die Begriffe "Steuerungsprogramm" und "Systemprogramm" in Anspruch 1 nicht weiter definiert sind, können sie den Programmen oder Programmteilen der Ablaufstränge "UA-S" und "P" zugeordnet werden, die die entsprechenden Prozeduren ausführen.
1.3 Dokument D9 betrifft nun ebenfalls ein "OPC UA System" namens "TwinCAT" (vgl. Titelseite).
1.3.1 Ab Seite 12 von D9 wird das Anwendungsbeispiel eines Datenloggers beschrieben, bei dem dezentrale "OPC-UA Clients" Prozessdaten abfragen und an einen "OPC-UA Server" in der "Cloud" schicken (Seite 13, Abschnitte "Technische Beschreibung" und "Dezentralisierter OPC-UA Client").
Bezüglich Merkmal e)_i) stellt der "OPC UA Server" eine Methode "Send(data)" bereit, mit der ein "OPC UA Aufruf" ("OPC-UA Methodenaufruf") an den "OPC UA Server" gesendet werden kann (Seite 13, Abschnitt "Schnittstellenbeschreibung (zur Cloud)", zweiter Absatz).
Betreffend Merkmal e)_ii) basiert der "OPC-UA Server" auf einem sogenannten "SPS-Projekt", das eine Komponente "MethodCall Provider" enthält, die Daten zu auszuführenden Funktionen sammelt und Jobs in einer weiteren Komponente "Queue" hinzufügen und löschen kann, in der eine Liste von auszuführenden Jobs bzw. Funktionen gespeichert ist (Seite 13, Abschnitt "Die Cloud" und die Figur auf Seite 14). Das Speichern erfolgt auf einen Aufruf "addJob(data)" an die Komponente "Queue" hin durch deren Routine "add to queue" (Figur auf Seite 14).
Betreffend Merkmal e)_iii) ist im "SPS-Projekt" außerdem eine Komponente "Aggregator" enthalten, die zyklisch überprüft, ob in der Komponente "Queue" Jobs gespeichert sind, gegebenenfalls den Job übernimmt und mit dessen Verarbeitung beginnt (Seite 13, letzter Absatz). Die Überprüfung wird durch den Aufruf der Funktion "getJob" angestoßen, die somit der "Systemfunktion" in Merkmal e)_iii) entspricht. Damit steuert die Komponente "Aggregator" den Zeitpunkt der Ausführung der in "Queue" gespeicherten Jobs.
1.3.2 Die Begriffe "Steuerungsprogramm" und "Systemprogramm" werden in Anspruch 1 nicht definiert. Daher können sehr wohl in dem System von D9 die Komponente "Queue" dem "Systemprogramm" und die Komponente "Aggregator" dem "Steuerungsprogramm" zugeordnet werden.
1.3.3 Die Pateninhaberin argumentierte, dass D9 keine industrielle Steuerung beschreibe. Nach Ansicht der Kammer kann dies dahingestellt bleiben, da das Dokument D9 im Folgenden nur als Kombinationsdokument verwendet wird und D5 bereits eine industrielle Steuerung offenbart.
1.4 Dokument D5 offenbart nun alle Merkmale von Anspruch 1 außer dass die Überprüfung, ob ein "OPC UA Aufruf" gespeichert ist, nicht gemäß Merkmal e)_iii) von einer Systemfunktion des Systemprogramms an einer definierten Stelle des Steuerungsprogramms aufgerufen, sondern vom "OPC UA Client" durch den Befehl "CloseSession" angestoßen wird.
1.5 Dieser Unterschied bewirkt nun, dass der Ausführungszeitpunkt der Prüfung auf gespeicherte "OPC UA Aufrufe" der Kontrolle des "Steuerungsprogramms" in der industriellen Steuerung unterliegt.
1.6 Die ausgehend von Dokument D5 der beanspruchten Erfindung zugrunde liegende objektive technische Aufgabe kann daher darin gesehen werden, "Fremdeinflüsse auf den Ablauf des Steuerungsprogramms in der industriellen Steuerung von D5 zu verringern". Die Patentinhaberin argumentierte hierbei, dass die objektive Aufgabe auch darin bestehe, die Verzweigung bzw. Ausführung von aufgerufenen Funktionen an eine definierte Stelle im Steuerungsprogramm legen zu können. Die Kammer teilt diese Ansicht nicht, da dies bereits Teil der Lösung ist, die ja gerade darin besteht, die Systemfunktion zur Prüfung auf gespeicherte "OPC UA Aufrufe" an einer bestimmten Stelle des Steuerungsprogramms aufzurufen.
1.7 Die Fachperson auf dem Gebiet der Automatisierungstechnik hätte - ausgehend von D5 und vor die obige Aufgabe gestellt - Dokument D9 durchaus in Betracht gezogen, in dem es ja auch um OPC-UA Funktionsaufrufe eines "OPC-UA Clients" bei einem "OPC-UA Server" geht. Sie hätte ferner die Anregung übernommen, dass die Prüfung auf gespeicherte "OPC UA Aufrufe" auf Seiten der Einheit angestoßen wird, in welcher auch der "OPC UA Server" implementiert wird. Dies ist im System von D5 die industrielle Steuerung. Mithin wäre die Fachperson zu dem Verfahren gemäß Anspruch 1 gelangt, ohne hierbei erfinderisch tätig werden zu müssen.
1.8 Diesbezüglich argumentierte die Patentinhaberin, dass die Fachperson D9 als "fernliegenden" Stand der Technik nicht in Betracht gezogen hätte. Das Dokument beschreibe nur einen Dienstcomputer, der mit dem Netz verbunden sei und Daten verarbeite. Die im industriellen Kontext auftretenden Problematiken, dass Zykluszeiten einzuhalten sind, Ressourcen stark limitiert und für die Steuerung reserviert seien, würden in Dokument D9 nicht adressiert werden, da der "Aggregator" asynchron vom industriellen Prozess entkoppelt sei.
Die Kammer ist hingegen der Ansicht, dass die Verwendung eines System mit einem "OPC UA Server" und einem "OPC UA Client" bereits hinreichend ist, um von der Fachperson in Betracht gezogen zu werden. Dies umso mehr, da sich das "OPC UA Protokoll" der Kommunikation und dem Austausch von Maschinendaten widmet (vgl. Absatz [0002] der Patentschrift) und Dokument D9 insofern kein abseitiges Dokument darstellen kann.
1.9 Ferner sei nach Ansicht der Patentinhaberin in der Figur auf Seite 14 von D9 ein Cloud-Verfahren zum Speichern von Daten eines weltweiten Systems gezeigt, bei dem zum Aufrufen der Prüfung auf gespeicherte "OPC UA Aufrufe" keine "Systemfunktion" eines "Systemprogramms" verwendet werden würde, da hier eben "OPC UA Methoden" zum Einsatz kämen.
Die Kammer ist auch davon nicht überzeugt. Die beiden Begriffe "Steuerungsprogramm" und "Systemprogramm" sind sehr allgemeine Begrifflichkeiten und können auf jedes Programm oder jeden Programmteil in der industriellen Steuerung angewendet werden. Und selbst wenn der Begriff "Systemprogramm" enger als ein "Programm" ausgelegt werden sollte, das Routinen bereitstellt, die von anderen Programmen oder Programmteilen aufrufbar sind, würde dies sowohl auf die Routinen im Ablaufstrang "UA-S" in dem System von D5 als auch auf die Routinen zur Ausführung der Komponente "Queue" in dem System von D9 zutreffen.
Der Einspruchsgrund nach Artikel 100 a) i.V.m. Artikel 56 EPÜ steht somit der Aufrechterhaltung des Streitpatents in der erteilten Fassung entgegen.
2. Hilfsantrag 1 - erfinderische Tätigkeit (Artikel 56 EPÜ) 2.1 Der Befehl gemäß Merkmal f) ruft die Systemfunktion auf, die im Verfahren gemäß Anspruch 1 prüft, ob "OPC UA Aufrufe" gespeichert sind.
2.2 Der entsprechende Befehl "getJob" im System von D9 wird von der Komponente "Queue" bereitgestellt und von der Komponente "Aggregator" in deren Programmablauf aufgerufen bzw. abgearbeitet (Figur auf Seite 14). Der Befehl ist damit notgedrungen in der Programmiersprache definiert, die auch für die Programmierung der Komponente "Aggregator" verwendet wird, die dem Steuerungsprogramm entspricht. Die "Cloud" von D9 entspricht im System gemäß D5 wiederum der "industriellen Steuerung". Die Fachperson hätte daher bei der Kombination der Lehren von D5 und D9 die Ausführung der Abfrage, ob "OPC UA Aufrufe" gespeichert sind, so verstanden, dass sie in der Programmiersprache des Steuerungsprogramms definiert und abgearbeitet werden.
2.3 Der Gegenstand von Anspruch 1 von Hilfsantrag 1 beruht daher auch nicht auf einer erfinderischen Tätigkeit. Hilfsantrag 1 ist daher nicht gewährbar (Artikel 56 EPÜ).
3. Hilfsantrag 2 - erfinderische Tätigkeit (Artikel 56 EPÜ) 3.1 Gemäß Merkmal g) weist der Befehl aus Merkmal f) einen "Rückgabewert" auf, von dem abhängt, ob die Funktion aufgerufen wird.
3.2 Dieser Befehl muss dazu notwendigerweise die entsprechende Information, d. h. ob die Bedingung erfüllt ist, bereitstellen. Dies in Form eines definierten "Flags" bzw. eines "Rückgabewerts" zu tun, gehört zum allgemeinen Fachwissen einer Fachperson, wie auch die Einspruchsabteilung in der angefochtenen Entscheidung folgert (siehe Gründe 28). Aber selbst ohne Verwendung eines solchen "Flags" muss im ausführenden Prozessor zumindest ein entsprechender Bitwert vorhanden sein, der die Verzweigung steuert und der auch einen "Rückgabewert" darstellt.
3.3 Darüber hinaus ist Merkmal g) auch in Dokument D9 offenbart. Die Komponente "Aggregator" prüft hier nämlich zyklisch, ob in der Komponente "Queue" zu bearbeitende Jobs gespeichert sind und führt diese gegebenenfalls aus (Seite 13, letzter Absatz). Der für diese Prüfung eingesetzte Befehl ("getJob", vgl. die Figur auf Seite 14) muss dazu einen Wert an die Komponente "Aggregator" liefern, d. h. einen "Rückgabewert" aufweisen, auf dessen Grundlage entschieden wird, ob ein zu bearbeitender Job bzw. Funktion tatsächlich aufgerufen wird oder nicht.
3.4 Auch der Gegenstand von Anspruch 1 von Hilfsantrag 2 beruht daher nicht auf einer erfinderischen Tätigkeit. Hilfsantrag 2 ist somit ebenfalls nicht gewährbar (Artikel 56 EPÜ).
4. Hilfsantrag 3 - erfinderische Tätigkeit (Artikel 56 EPÜ) 4.1 Anspruch 1 von Hilfsantrag 3 betrifft eine industrielle Steuerung, die für die Verwendung im Verfahren gemäß Anspruch 1 von Hilfsantrag 2 eingerichtet ist. Technische Einschränkungen, die über die zur Durchführung des Verfahrens erforderlichen Einschränkungen hinausgehen, sind hierbei nicht enthalten.
4.2 Die negative Einschätzung zur Frage der erfinderischen Tätigkeit des Verfahrens gemäß Anspruch 1 von Hilfsantrag 2 gilt daher mutatis mutandis auch für die "Steuerung" gemäß Anspruch 1 von Hilfsantrag 3. 4.3 Der Gegenstand von Anspruch 1 von Hilfsantrag 3 beruht mithin auch nicht auf einer erfinderischen Tätigkeit. Hilfsantrag 3 ist somit ebenfalls nicht gewährbar (Artikel 56 EPÜ).
5. Da kein gewährbarer Anspruchssatz vorliegt, ist das Streitpatent zu widerrufen.
Entscheidungsformel
Aus diesen Gründen wird entschieden:
Die Beschwerde wird zurückgewiesen. Der Geschäftsstellenbeamte:
Der Vorsitzende:
T. Buschek K. Bengi-Akyürek