T 1561/23 (Zeitüberwachungsfunktion/BECKHOFF) of 23.6.2025

Sachverhalt und Anträge

I. Die Beschwerde richtet sich gegen die Entscheidung der Prüfungsabteilung, mit Gründen datiert vom 21. Februar 2023, die Europäische Patentanmeldung 17720035.9 zurückzuweisen wegen unzulässiger Erweiterung (Hauptantrag), mangelnder Neuheit (Hilfsantrag 1) und mangelnder erfinderischer Tätigkeit (Hilfsantrag 2).

II. Das folgende im Prüfungsverfahren eingeführte Dokument wird in dieser Entscheidung genannt:

D5 = Hughes Zemian M. et al.: "Reducing the impact of task overruns in resource-constrained embedded systems in which a time-triggered software architecture is employed", Transactions Of The Institute Of Measurement And Control, Bd. 30, Nr. 5, 1. Dezember 2008 (2008-12-01), Seiten 427-450, XP55854740, GB, ISSN: 0142-3312, DOI: 10.1177/0142331207086183

III. Beschwerde gegen die Entscheidung wurde am 6. März 2023 eingelegt und am selben Tag wurde die Beschwerdegebühr entrichtet. Die Beschwerdebegründung ging am 23. Juni 2023 ein. Die Beschwerdeführerin beantragte die Aufhebung der Entscheidung und die Erteilung eines Patents auf der Basis der Ansprüche 1 bis 12 gemäß Hauptantrag oder 1 bis 10 gemäß Hilfsantrag, beide eingereicht mit der Beschwerdebegründung. Die übrigen Anmeldungsunterlagen sind:

Beschreibung, Seiten

1 bis 4 und 7 bis 37, ursprüngliche Fassung,

5, 6 und 6a, eingegangen am 14. November 2022;

Zeichnungen, Blätter

1 bis 7, ursprüngliche Fassung.

IV. Mit einer Ladung zur mündlichen Verhandlung teilte die Kammer der Beschwerdeführerin ihre vorläufige Meinung mit, laut der die Entscheidung der Prüfungsabteilung zu bestätigen sein würde.

V. Die mündliche Verhandlung fand am 23. Juni 2025 statt. Während der Verhandlung reichte die Beschwerdeführerin mündlich einen neuen Hilfsantrag 1a ein, der in der Reihenfolge nach dem Hauptantrag und vor dem Hilfsantrag 1 stehen und nur noch die Ansprüche 11 und 12 enthalten soll.

VI. Der Anspruch 1 des Hauptantrags lautet wie folgt:

"Verfahren zum Ausführen wenigstens einer Zusatzfunktion innerhalb einer Echtzeitumgebung, in der wenigstens eine Task mit einer vorgegebenen Task-Laufzeit ausgeführt wird, wobei die wenigstens eine Zusatzfunktion mit unbestimmter Funktionslaufzeit innerhalb der vorgegebenen Task-Laufzeit mit Hilfe einer Zeitüberwachungsfunktion abgearbeitet werden soll, wobei die Zeitüberwachungsfunktion als Wrapper-Funktion ausgebildet ist, welche unmittelbar vor und unmittelbar nach dem Programmcode der Zusatzfunktion aufgerufen wird und so den Programmcode der Zusatzfunktion umgibt,

mit den Schritten:

Aufrufen der Zeitüberwachungsfunktion unmittelbar vor dem Programmcode der Zusatzfunktion zum Starten der Zeitüberwachungsfunktion, die einen Abbruchszeitpunkt für die Zusatzfunktion innerhalb der vorgegebenen Task-Laufzeit festlegt,

Ausführen der Zusatzfunktion, wobei die Zeitüberwachungsfunktion die Funktionslaufzeit überwacht und bei Überschreiten des vorgegebenen Abbruchszeitpunktes ein Funktionsabbruch veranlasst wird, und

Aufrufen der Zeitüberwachungsfunktion unmittelbar nach dem Programmcode der Zusatzfunktion zum Beenden der Zeitüberwachungsfunktion."

VII. Der Anspruch 11 des Hauptantrags lautet wie folgt:

"Speicherprogrammierbare Steuerung (3), die über einen Feldbus (4) mit Aktoren (2) und Sensoren (1) einer Produktionsanlage verbunden ist, wobei die speicherprogrammierbare Steuerung (3) ein Verfahren nach einem der Ansprüche 1 bis 10 ausführt, deren Task zum Steuerung von Aktoren (2) und Sensoren (1) dient, wobei die Ausführung der Zusatzfunktion durch die Zeitüberwachungsfunktion mit der Steuerung synchronisiert ist."

VIII. Der einzige unabhängige Anspruch des "Hilfsantrags 1a" entspricht Anspruch 11 des Hauptantrags.

IX. Der Anspruch 1 des "Hilfsantrags" lautet wie folgt:

"Verfahren zum Ausführen wenigstens einer Zusatzfunktion innerhalb einer Echtzeitumgebung, in der wenigstens eine Task mit einer vorgegebenen Task-Laufzeit ausgeführt wird, wobei die wenigstens eine Zusatzfunktion mit unbestimmter Funktionslaufzeit innerhalb der vorgegebenen Task-Laufzeit mit Hilfe einer Zeitüberwachungsfunktion abgearbeitet werden soll, wobei die Zeitüberwachungsfunktion als Wrapper-Funktion ausgebildet ist, welche unmittelbar vor und unmittelbar nach dem Programmcode der Zusatzfunktion aufgerufen wird und so den Programmcode der Zusatzfunktion umgibt, wobei in den Programmcode der Zusatzfunktion eine Zusatzbedingung eingefügt ist, die einer Bearbeitungsschleife der Zusatzbedingung zugeordnet ist,

wobei das Verfahren die Schritte aufweist:

Aufrufen der Zeitüberwachungsfunktion unmittelbar vor dem Programmcode der Zusatzfunktion zum Starten der Zeitüberwachungsfunktion, die einen Abbruchszeitpunkt für die Zusatzfunktion innerhalb der vorgegebenen Task-Laufzeit festlegt,

Ausführen der Zusatzfunktion, wobei die Zusatzbedingung im Programmcode der Zusatzfunktion ein Überschreiten des vorgegebenen Abbruchszeitpunktes durch die Funktionslaufzeit der Zusatzfunktion am Ende der zugeordneten Bearbeitungsschleife prüft, wobei beim Feststellen einer Überschreitung die Zusatzfunktion durch Herauszweigen am Ende der Bearbeitungsschleife kontrolliert abgebrochen und ein Bearbeitungsergebnis der Zusatzfunktion rückgemeldet wird, und

Aufrufen der Zeitüberwachungsfunktion unmittelbar nach dem Programmcode der Zusatzfunktion zum Beenden der Zeitüberwachungsfunktion."

X. Der Wortlaut der anderen Ansprüche des Hauptantrags oder der Hilfsanträge ist für die vorliegende Entscheidung irrelevant.

XI. Am Ende der mündlichen Verhandlung verkündete der Vorsitzende die Entscheidung.

Entscheidungsgründe

1. Die Anmeldung

Die Anmeldung betrifft ein Verfahren zum Ausführen wenigstens einer Zusatzfunktion innerhalb einer Echtzeitumgebung (Anspruch 1), sowie eine speicherprogrammierbare Steuerung (SPS), welche ein solches Verfahren ausführt (Anspruch 11).

Es wird beschrieben, dass die Steuerung auf einer SPS in Form von "Aufgaben, sogenannten Tasks" erfolgt, die innerhalb einer vorgegebenen Task-Laufzeit abgearbeitet werden (Seite 1, Absätze 2 und 3).

In einer "Produktionsanlage" seien neben den Tasks noch "weitere[] Systeme vorhanden, deren Funktionen mit dem Produktionsprozess und dessen Steuerung durch die SPS synchronisiert werden müssen" (Seite 2, Absatz 5). Diese weiteren Systeme werden auch als "Zusatzfunktionen" bezeichnet (z.B. Seite 3, Zeilen 1 bis 2). Als Beispiele für solche Zusatzfunktionen werden komplexe "Vision-Systeme" genannt (Seite 2, letzter Absatz), aber auch Zustandsüberwachung, maschinelles Lernen sowie numerische Steuerungen, die "in der Regel in Form eigenständiger, von der SPS getrennter Softwarekomponenten vor[lägen]" (Seite 2, Absatz 2).

Die Anmeldung sieht es als ihre Aufgabe, eine Integration von dergleichen Zusatzfunktionen mit unbestimmter Funktionslaufzeit in die Echtzeitumgebung zu ermöglichen (Seite 2, Absatz 5).

Hierzu schlägt die Anmeldung eine Zeitüberwachungsfunktion vor, die bei Überschreiten eines vorgegebenen Abbruchszeitpunkts (innerhalb der vorgegebenen Task-Laufzeit) die Zusatzfunktion abbricht. Diese Vorgehens­weise gewährleistet eine zyklische Ausführung der Tasks ohne zeitliche Schwankungen (Jitter) mit einer vorhersehbaren Antwortzeit (Latenzzeit) (Seite 5, Zeilen 11 bis 15).

Anspruchsgemäß wird wenigstens ein Task mit einer vorgegebenen Task-Laufzeit ausgeführt, wobei wenigstens eine Zusatzfunktion innerhalb der vorgegebenen Task-Laufzeit abgearbeitet werden "soll" (Seite 6, Zeilen 21 bis 24). Weder Task noch Zusatzfunktion sind anspruchsgemäß weiter charakterisiert.

Weiter anspruchsgemäß ist die Zeitüberwachungsfunktion als Wrapper-Funktion ausgebildet. Die Anmeldung erklärt (Seite 14, Absatz 3), dass dabei die Zeitüberwachungsfunktion als Programmcode ausgeführt sei, der die Software der (Zusatz)funktion umgebe. So sei kein umfangreicher Eingriff in den Programmcode der Zusatzfunktion nötig und der Programmcode der Zusatzfunktion liefe so "innerhalb des Programmcodes der Zeitüberwachungsfunktion".

2. Hauptantrag

2.1 Das Dokument D5 offenbart eine Echtzeitumgebung (Abschnitt 1.1, erster Absatz: "embedded system", "a typical requirement is that the interval between the start time (the 'jitter') of key periodic tasks does not vary by more than 1 mys (preferably less)").

Dieser Tatsache hat die Beschwerdeführerin nicht widersprochen.

2.2 In dieser Echtzeitumgebung werden Tasks ("co-operative tasks") mit einer vorgegebenen Task-Laufzeit ausgeführt (3 ms, vgl. Abschnitt 1.1, zweiter Absatz).

2.3 In dieser Echtzeitumgebung wird eine Zusatzfunktion ausgeführt ("pre-emptive task"). Ihre Funktionslaufzeit liegt innerhalb der vorgegebenen Task-Laufzeit (D5, Abschnitt 1.1, vorletzter Absatz: "a short pre-emptive task is executed every millisecond, while a co-operative task (with a duration greater than 1 ms) is 'simultaneously' executed every 3 ms").

2.3.1 Laut der Beschwerdeführerin (Beschwerdebegründung Seiten 3 und 5, jeweils vorletzter Absatz) ist in der D5 keine Zusatzfunktion offenbart. Es würden nur Tasks, aber keine Zusatzfunktionen ausgeführt. Die Zusatzfunktionen gemäß der Anmeldung seien komplex und hätten daher eine unbestimmte Funktionslaufzeit. Hingehen hätten pre-emptive Tasks eine feste Laufzeit (Beschwerdebegründung, Seite 3, vorletzter Absatz, letzter Satz).

Genau dies ist in der D5 aber nicht der Fall: die "pre-emptive tasks" können die vorgesehene Zeit überschreiten ("overrun"); siehe D5, Abschnitte 1.4, 2 und 3.2. Die Task-Laufzeit für die "pre-emptive tasks" ist in der D5 somit nicht fest.

In der mündlichen Verhandlung betonte die Beschwerdeführerin, dass die pre-emptive Tasks ihre Laufzeit allenfalls ausnahmsweise, etwa in Fehlersituationen, überschreiten würden, während die Laufzeit der Zusatzfunktionen grundsätzlich unbestimmt sei.

Während der mündlichen Verhandlung betonte die Beschwerde­führerin, dass der Anspruch 1 einen Unterschied macht zwischen "Tasks" und "Zusatzfunktionen". Aus der Beschreibung gehe hervor, dass "Tasks" Aktoren und Sensoren steuern (Seite 1, Zeilen 16 und 17), während beispielsweise Vision-Systeme (Seite 2, letzter Absatz) oder eine Zustandsüberwachung (Seite 3, Zeilen 1 bis 7) "Zusatzfunktionen" darstellen würden.

2.3.2 Die Beschwerdekammer folgt der Beschwerdeführerin in ihrer Unterscheidung zwischen pre-emptive Tasks und Zusatzfunktionen nicht.

Insbesondere ist die Kammer der Ansicht, dass die beanspruchte "Zusatzfunktion" ihrer Natur nach nicht - jedenfalls nicht hinreichend präzise - von einem "Task" zu unterscheiden ist. In beiden Fällen handelt es sich um Programme, die in einer Echtzeitumgebung ein (soweit möglich) vorhersehbares Laufzeitverhalten haben sollen. Der Umstand, dass die "Zusatzfunktion" als "zusätzlich" bezeichnet und damit von dem übrigen beanspruchten "Task" unterschieden ist, wird anspruchsgemäß schon dadurch gefüllt, dass für die Zusatzfunktion ein Abbruch bei Laufzeitüberschreitung verlangt wird, nicht aber von den Tasks. Eine inhaltliche Unterscheidung von Task und Zusatzfunktion folgt daraus nicht.

Außerdem ist den Begriffen - selbst im Lichte der Beschreibung - nicht zu entnehmen, wie komplex die "Zusatzfunktion" im Unterschied zum "Task" ist und wie wahrscheinlich demnach ein Überschreiten der vorgegebenen Task-Laufzeit ist. Zum einen ist die Task-Laufzeit selbst nicht definiert. Zum anderen nennt die Anmeldung als Beispiele für Zusatzfunktionen nicht nur Vision oder maschinelles Lernen, sondern auch die Zustandsüberwachung, die eine "Bewertung des Zustands der Produktionsanlage durch Messung und Analyse von Maschinenparametern" durchführt. Es ist nicht offenbart, und es gibt keinen Grund anzunehmen, dass solche Zustandsüberwachung sonderlich komplex sein und ihre Laufzeit daher in ähnlicher Weise "unvorhersehbar" sein müsse wie etwa ein Vision-System. Darüber hinaus kann die Kammer nicht erkennen, dass Anspruch oder Beschreibung einen Hinweis dazu enthalten würden, dass unterschiedliche Grade an Unvorhersehbarkeit zu unterscheiden wären oder wie.

Schließlich merkt die Kammer an, dass sie nur die "co-operative tasks" aus D5 mit den beanspruchten "Tasks" identifiziert, während sie eine andere "Kategorie" von Tasks, die "pre-emptive tasks" aus D5 mit den "Zusatzfunktionen" identifiziert. Genau wie eine "Zusatzfunktion" in der Anmeldung (Seite 3, erster Absatz) versorgt ein "pre-emptive task" in der D5 z.B. eine regelmäßige Datenerfassung (siehe D5, Seite 429, erster Absatz: "In many designs, the pre-emptive task will be used for periodic data acquisition") in einem Kontrollsystem (ibid.: "such requirements are common in, eg, a wide range of control systems").

2.4 Der "pre-emptive task" in der D5 kann deshalb als eine Zusatzfunktion mit unbestimmter Funktionslaufzeit angesehen werden.

2.5 Die Abarbeitung der Zusatzfunktion innerhalb der vorgegebenen Task-Laufzeit verläuft mit Hilfe einer Zeitüberwachungsfunktion (ausgeführt durch einen sogenannten "pre-emptive task guardian"), welche unmittelbar vor (Starten des Timers, Seite 439, Zeile 10) und unmittelbar nach dem Programmcode der Zusatzfunktion aufgerufen wird (Sleep Mode bis zum Ende der Task-Laufzeit; vgl. Seite 439, Zeilen 13 bis 15) und "so" den Programmcode der Zusatzfunktion umgibt. Die Zeitüberwachungsfunktion wird unmittelbar vor dem Programmcode der Zusatzfunktion aufgerufen (ibid.) und legt einen Abbruchzeitpunkt für die Zusatzfunktion innerhalb der vorgegebenen Task-Laufzeit (Ablauf des Timers) fest, wobei die Zeitüberwachungsfunktion die Funktionslaufzeit überwacht und bei Überschreiten des vorgegebenen Abbruchzeitpunktes ein Funktionsabbruch veranlasst wird (Seite 439, Zeilen 10 bis 13), und unmittelbar nach dem Programmcode der Zusatzfunktion wird die Zeitüberwachungsfunktion zum Beenden der Zeitüberwachungsfunktion aufgerufen (in dem Sinne, dass die Zeitüberwachungs­funktion nach dem Programmcode der Zusatzfunktion beendet wird (Figuren 6 und 7 und Abschnitt 3.2, ibid.).

2.6 Die beanspruchte Zeitüberwachungsfunktion ist anspruchsgemäß als "Wrapper-Funktion" ausgebildet. Diese wird aber im Übrigen nur durch ihre Verwendung charakterisiert: Sie sei "unmittelbar vor und unmittelbar nach dem Programmcode der Zusatzfunktion" aufzurufen und umgebe (die Beschreibung sagt auch: umhülle, vgl. S. 14, Absatz 3) "so" den Programmcode der Zusatzfunktion. Der Programmcode der Wrapperfunktion ist damit nur funktional, aber nicht in weiteren Einzelheiten gefordert. Insbesondere schließt nach Ansicht der Kammer der Begriff "Wrapper-Funktion" nicht aus, dass der Programmcode der Zusatzfunktion in einem separaten Programm (etwa einem Task Guardian) bereitgestellt wird, da auch dessen Aufrufe der Zeitüberwachung einer Funktion diese funktional umgeben und es erlauben, "die Software der Zusatzfunktion auf einfache Weise zu erweitern, ohne umfangreich in den Programmcode der Zusatzfunktion eingreifen zu müssen" (ibid.).

2.7 Es mag zwar stimmen, dass, wie die Beschwerdeführerin anführt (Beschwerde­begründung, Seite 4), die Schritte Update(), [Start], [Start Timer],[Finish update()] und [End] in der Figur 6 der D5 nicht in der Weise mit den Schritten des Anspruchs 1 übereinstimmen, wie in der Entscheidung angegeben. Tatsächlich spielt sich aber in der D5 (Figuren 6 und 7 und Abschnitt 3.2) das Gleiche ab wie im Anspruch 1:

- Aufrufen der Zeitüberwachungsfunktion unmittelbar vor dem Programmcode der Zusatzfunktion zum Starten der Zeitüberwachungsfunktion

In der D5 wird, bevor die Zusatzfunktion (pre-emptive task) startet, die Zeitüberwachungsfunktion ("high-priority (FIQ) timer 'Task Guardian'") gestartet (siehe D5, Seite 439, Zeile 10).

- Ausführen der Zusatzfunktion, wobei die Zeitüberwachungsfunktion die Funktionslaufzeit überwacht

Während die Zusatzfunktion (pre-emptive task) ausgeführt wird, läuft der "high-priority (FIQ) timer" ab. Wenn der "pre-emptive task" vorzeitig endet, wird die verbleibende Zeit im Leerlauf (sleep mode) verbracht, bis der "FIQ timer" abläuft (D5, Seite 439, Zeilen 13 bis 15). Wird die zugelassene Zeit überschritten, unterbricht der FIQ-Timer die Ausführung, und erforderliche Korrekturmaßnahmen werden ergriffen (Setzen eines Überlauf-Flags und Protokollieren eines Fehlers; ibid., Zeilen 11 bis 13).

- Aufrufen der Zeitüberwachungsfunktion unmittelbar nach dem Programmcode der Zusatzfunktion zum Beenden der Zeitüberwachungsfunktion

Sobald die Zusatzfunktion abgeschlossen ist oder (falls die Zeit überschritten wurde) zwangsweise beendet wird, geht die Kontrolle zurück an die Zeitüberwachungs­funktion ("pre-emptive task guardian" Routine; vgl. ibid., Zeilen 15 bis 16). Diese prüft, ob eine Überschreitung aufgetreten ist, und führt anschließend alle abschließenden Aufgaben durch:

- Sie stoppt den "FIQ timer" (oder lässt ihn ablaufen, wenn die Zusatzfunktion vorzeitig beendet wurde).

- Sie gibt die Kontrolle zurück an Update().

2.8 Das Dokument D5 offenbart deshalb alle Schritte des Verfahrens nach Anspruch 1 des Hauptantrags.

2.9 Während der mündlichen Verhandlung verwies die Beschwerde­führerin hinsichtlich der strittigen Auslegungen der Begriffe "Task", "Zusatzfunktion", "unbestimmte Funktionslaufzeit" und "Wrapper-Funktion" auf die Entscheidung G 1/24, laut der bei der Beurteilung der Patentierbarkeit einer Erfindung gemäß den Artikeln 52 bis 57 EPÜ zur Auslegung der Ansprüche stets die Beschreibung und die Zeichnungen heranzuziehen sind ("to be consulted"), und zwar nicht nur dann, wenn der Fachmann einen Anspruch für sich genommen für unklar oder mehrdeutig hält.

2.10 Dazu merkt die Kammer das Folgende an:

In der Entscheidung G 1/24 wird nicht definiert, was es im Einzelfall bedeutet, die Beschreibung und die Zeichnungen heranzuziehen, sondern verweist insofern auf die Rechtsprechung der Beschwerdekammern (vgl. etwa G 1/24, Gründe 10). Die Entscheidung G 1/24 verlangt nicht einmal ausdrücklich, dass die Definition eines Begriffs aus der Beschreibung zwingend für die Auslegung eines Anspruchs heranzuziehen ist. Die einschlägige Vorlagefrage 3 ("may a definition or similar information on a term used in the claims which is explicitly given in the description be disregarded when interpreting the claims [...]") wurde als unzulässig nicht beantwortet und aus der Antwort auf die Vorlagefrage 2 (wie oben unter 3.2 wiedergegeben) folgt jedenfalls, dass eine solche Definition nicht außer Acht gelassen werden kann ("disregarded"), da sie ja als Teil der Beschreibung und der Zeichnungen heranzuziehen ist.

Im vorliegenden Fall hat die Kammer, wie aus der vorangehenden Analyse erkennbar ist, die Beschreibung und die Zeichnungen im Einklang mit der G 1/24 herangezogen. Sie hat auch erläutert, warum dieses Heranziehen ihrer Ansicht nach keine engere Auslegung des Anspruchswortlauts begründen würde. Dabei hat sie insbesondere berücksichtigt, dass die Anmeldung für die strittigen Begriffe keine Definition ("or similar information") angibt, ungeachtet der Frage, ob oder unter welchen Umständen eine solche Definition dann den beanspruchten Gegenstand beschränken würde.

Wie oben ausgeführt, gibt die vorliegende Anmeldung nur Beispiele für Zusatzfunktionen, daraus lässt sich aber nicht ableiten, worin sich "Tasks" und "Zusatzfunktionen" konkret und grundsätzlich unterscheiden würden. Ähnliches gilt auch für die anderen strittigen Begriffen (siehe oben).

2.11 Aus diesen Gründen ist die Kammer der Meinung, dass der Hauptantrag nicht die Bedingungen des Artikels 54 EPÜ erfüllt.

3. Hilfsantrag 1a

3.1 Die Beschwerdeführerin begründete die verspätete Einreichung des Hilfsantrags 1a in der mündlichen Verhandlung mit der Tatsache, dass erst zu diesem Zeitpunkt ersichtlich geworden sei, dass der Unterschied zwischen "Task" und "Zusatzfunktion" deutlicher beansprucht werden müsse, weil die Kammer der Ansicht sei, dass die "pre-emptive task" aus D5 als eine "Zusatzfunktion" im Sinne der Anmeldung zu betrachten sei. Die Beschränkung auf die Ansprüche 11 und 12 des Hauptantrags leiste diese Klarstellung, weil diese Ansprüche auf eine speicherprogrammierbare Steuerung beschränkt seien und festlegten, dass "die Tasks zur Steuerung von Aktoren (2) und Sensoren (1) dient" und die "Ausführung der Zusatzfunktion durch die Zeitüberwachungsfunktion mit der Steuerung synchronisiert ist".

3.2 Die Kammer merkt aber an, dass sie bereits in ihrer vorläufigen Meinung (Punkte 7.3 und 7.4) dem Standpunkt der Beschwerde­führerin widersprochen hat, laut dem der "pre-emptive task" in der D5 keine "Zusatzfunktion" sei. Es war daher schon aus der Ladung erkennbar, dass die behauptete Unterscheidung von Tasks und Zusatzfunktionen entscheidungserheblich sein könnte. Darüber hinaus hat die Kammer in ihrer vorläufigen Meinung die Auffassung vertreten, dass der Gegenstand des Anspruchs 11 des Hauptantrags auch angesichts seiner weiteren Merkmale nicht erfinderisch sei, während sie den Anspruch 1 für nicht neu erachtet hat. Es war daher ebenfalls schon aus der vorläufigen Meinung erkennbar, dass die Patentierbarkeit von Anspruch 1 und 11 des Hauptantrags jedenfalls grundsätzlich unterschiedlich bewertet werden könnte. Aus beiden Gründen kann der vorgetragene Grund für das verspätete Einreichen des Hilfsantrags 1a nicht überzeugen.

Darüber hinaus ist die Kammer weiterhin der Meinung, dass der unabhängige Anspruch des Hilfsantrags 1a jedenfalls prima facie nicht erfinderisch ist. Was die Einschränkung auf eine speicherprogrammierbare Steuerung betrifft, verweist sie in dieser Hinsicht auf ihrer vorläufige Meinung, zur möglichen Relevanz von Tasks und Zusatzfunktionen auf die einschlägigen Betrachtungen oben.

3.3 Aus diesen Gründen lässt die Kammer den Hilfsantrag 1a nicht in das Beschwerdeverfahren zu (Artikel 13(2) VOBK).

4. Hilfsantrag

4.1 Die Beschwerdeführerin führte in der Verhandlung aus, dass der Fachmann verstanden hätte, dass das Wort "Zusatz­bedingung" in Zeile 14 von Anspruch 1 fehlerhaft ist und statt dessen "Zusatzfunktion" gelesen werden müsse. Die Kammer folgt dieser Auslegung: Eine Zusatzbedingung hat nach üblichem Sprachgebrauch keine "Bearbeitungsschleife" und aus dem Rest des Anspruchswortlauts geht hervor, dass die Bearbeitungsschleife zur Zusatzfunktion gehört.

4.2 Hingegen ist nicht ersichtlich, welche technische Wirkung die zusätzlichen Merkmale im Anspruch 1 des Hilfs­antrags 1a in ihrer Allgemeinheit erreichen.

In der Verhandlung argumentierte die Beschwerde­führerin, dass im Unterschied zur D5, in der pre-emptive Tasks, die die vorgesehene Laufzeit überschreiten, schlicht abgebrochen werden, anspruchsgemäß immer ein sinnvolles Bearbeitungs­ergebnis der Zusatzfunktion rückgemeldet werde. Sie verwies auch auf die Beschreibung (etwa auf Seiten 16 und 17), in der offenbart sei, dass ein "sinnvolles" Ergebnis ein Teilergebnis oder ein Ergebnis mit einer immerhin aktuellen Genauigkeit sein könne.

Die Kammer merkt an, dass Anspruch 1 des Hilfsantrags nicht beansprucht, dass das rückgemeldete Bearbeitungsergebnis "sinnvoll" sein muss, ganz abgesehen von der Unschärfe des Begriffs "sinnvoll". Es gibt darüber hinaus keinen Grund, weshalb ein Fehlerbericht nach Abbruch einer Zusatzfunktion (vgl. D5, Abschnitt 3.2) nicht als sinnvoll betrachtet werden kann. Darüber hinaus merkt die Kammer an, dass es nicht selbstverständlich ist, dass ein Algorithmus bei vorzeitiger Beendigung ein sinnvolles Teilergebnis oder ein angenähertes Ergebnis (mit einer geringeren Genauigkeit oder einem geringeren Vertrauen) zurückliefern würde. Viele Algorithmen tun das nicht. Ihr vorzeitiger Abbruch liefert dann systematisch nicht mehr als eben diese Tatsache, also einen Fehlerzustand. Darüber hinaus ist es für die Kammer auch nicht erkennbar, dass ein möglicher Abbruch der Zusatzfunktion (nur) am Ende der Bearbeitungsschleife den Vorteil hätte, dass nur (oder besonders gut) an dieser Stelle sichergestellt werden könne, dass ein sinnvolles Bearbeitungsergebnis vorliegt. Beispielsweise der Beginn der Schleife erscheint in dieser Hinsicht ebenso geeignet. Schließlich sei angemerkt, dass sich der Anspruchswortlaut nur auf irgendeine Bearbeitungsschleife der Zusatzfunktion bezieht, obgleich eine komplexe Zusatzfunktion ohne Weiteres eine Vielzahl von Schleifen enthalten wird. Die behauptete Wirkung der zusätzlichen Merkmale erscheint aus diesem Grund zusätzlich fragwürdig.

Auch in dieser Hinsicht enthält die Beschreibung nur Beispiele, und keine allgemeine Definition oder anderweitige allgemeine Erläuterung, was als ein sinnvolles Bearbeitungs­ergebnis gelten soll und wie sichergestellt wird, dass ein vorzeitiger Abbruch irgendeiner Zusatzfunktion ein solches sinnvolles Ergebnis liefert.

4.3 Die Kammer kann daher nicht erkennen, welche technische Aufgabe die zusätzlichen Merkmale aus Anspruch 1 des Hilfsantrags gegenüber D5 lösen könnten und ist deshalb der Meinung, dass der Hilfsantrag nicht die Bedingungen des Artikels 56 EPÜ erfüllt.

Entscheidungsformel

Aus diesen Gründen wird entschieden:

Die Beschwerde wird zurückgewiesen.