BPatG, Beschluss vom 06.05.2026

BUNDESPATENTGERICHT

_______________________

(Aktenzeichen) …

BESCHLUSS§

In der Beschwerdesache

betreffend die Patentanmeldung 10 2020 123 911.4

hat der 17. Senat (Technischer Beschwerdesenat) des Bundespatentgerichts auf die mündliche Verhandlung vom 6. Mai 2026 unter Mitwirkung des Richters Dipl.- Phys. Dr. Forkel als Vorsitzender, der Richterin Akintche, des Richters Dipl.-Phys. Dr. Städele und des Richters Dipl.-Ing. Hofmeister

beschlossen:

ECLI:DE:BPatG:2026:060526B17 Wpat10.23.0 1. Die Beschwerde wird zurückgewiesen.

2. Die Rückzahlung der Beschwerdegebühr wird angeordnet.

Gründe§

I. Die vorliegende Patentanmeldung, die zwei US-amerikanische Prioritäten vom 14. September 2019 und vom 11. September 2020 in Anspruch nimmt, wurde am 14. September 2020 beim Deutschen Patent- und Markenamt in englischer Sprache eingereicht. In der deutschen Übersetzung trägt sie die Bezeichnung „Synchronisierung des Verhaltens mehrerer Instrumente mithilfe von Aufträgen und Zwischenzielen“.

Die Anmeldung wurde durch Beschluss der Prüfungsstelle für Klasse G06F des Deutschen Patent- und Markenamtes vom 2. Februar 2023 zurückgewiesen. Zur Begründung führte die Prüfungsstelle aus, dass der Gegenstand des jeweiligen Patentanspruchs 1 gemäß dem damaligen Hauptantrag und dem damaligen 1. Hilfsantrag auf keiner erfinderischen Tätigkeit beruhe. Im Übrigen handle es sich beim Gegenstand des Patentanspruchs 1 gemäß dem damaligen Hauptantrag um die Ausführungsart einer Lösung einer nicht-technischen Problemstellung auf dem Gebiet der nicht-technischen Informationslogistik und damit um ein dem Patentschutz nicht zugängliches Programm für Datenverarbeitungsanlagen als solches. Weiterhin sei der Gegenstand des Patentanspruchs 1 gemäß dem damaligen 2. Hilfsantrag unzulässig erweitert.

Gegen diesen Beschluss ist die Beschwerde der Anmelderin gerichtet. Die Anmelderin beantragt, den Beschluss der Prüfungsstelle für Klasse G06F des Deutschen Patent- und Markenamts vom 2. Februar 2023 aufzuheben und ein Patent auf Grundlage folgender Unterlagen zu erteilen:

gemäß Hauptantrag:

Patentansprüche 1 bis 14, überreicht in der mündlichen Verhandlung (mit handschriftlichen Änderungen), Beschreibung Seiten 1 bis 17 vom 15. Dezember 2022, 3 Blatt Zeichnungen mit Figuren 1 bis 4 vom 5. November 2020. gemäß Hilfsantrag 1:

Patentansprüche 1 bis 14, überreicht in der mündlichen Verhandlung (mit handschriftlichen Änderungen), im Übrigen wie Hauptantrag. gemäß Hilfsantrag 2:

Patentansprüche 1 bis 14, überreicht in der mündlichen Verhandlung (mit handschriftlichen Änderungen), im Übrigen wie Hauptantrag. Hilfsweise beantragt die Anmelderin, die Sache zur weiteren Prüfung und Entscheidung an das Deutsche Patent- und Markenamt zurückzuverweisen.

Im Prüfungsverfahren vor dem Deutschen Patent- und Markenamt ist die Druckschrift D1: Rajeev Singh: Java CompletableFuture Tutorial with Examples, Jul 18, 2017. Im Internet:

<URL:https://web.archive.org/web/20190614071114/ https://www.callicoder.com/java-8-completablefuture-tutorial/> genannt worden. Vom Senat wurden zusätzlich die Druckschriften D2: US 2008/0021951 A1 und D3: US 2018/0341516 A1 eingeführt. Der geltende Patentanspruch 1 gemäß Hauptantrag, hier senatsseitig mit einer Merkmalsgliederung versehen, lautet (Änderungen gegenüber dem ursprünglichen Patentanspruch 1 sind markiert):

M1 Verfahren zur Synchronisierung von Aufgaben in einem Test- und Messsystem, umfassend:

M2 Empfangen (60) eines Aufgabeneingangs an einem Client (30) im System; M3 Empfangen, an einem Auftragsmanager (38), der auf einem ersten Vorrichtungsprozessor (10) im System läuft, eines Aufrufs (80) vom Client (30), um einen mit der Aufgabe verbundenen Auftrag (40) zu erstellen, M4 wobei der Auftragsmanager (38) eine vom Client (30) festgelegte Fertigstellungsrichtlinie und eine globale eindeutige Kennung (GUID) zum Identifizieren des Clients (30) erhält, M4a wobei die Fertigstellungsrichtlinie ein oder mehrere Zwischenziele umfassen kann, die Einstellungszwischenziele und/oder Datenzwischenziele sein können; M5 Zurückgeben (64) vom Auftragsmanager (38) einer Aktion, die mindestens einen mit dem Auftrag (40) verknüpften Auftragscodeblock enthält, an den Client (30); M6 Empfangen eines Aufrufs zur Aufrufen der Aktion; M7 Ausführen (68) des mindestens einen Auftragscodeblocks (42) durch mindestens einen Prozessor im System (10); M8 Feststellen (70) durch den Auftragsmanager (38), dass der Auftrag gemäß der Fertigstellungsrichtlinie abgeschlossen ist, M8a wobei die Fertigstellungsrichtlinie durch einen Auftragsmisserfolg oder einen Auftragserfolg erfüllt wird, M8b wobei ein Auftragserfolg eintritt, wenn der Auftrag nicht mehr aktiv ist und einer der folgenden vom Client bestimmten Punkte zutrifft:

Der geltende Patentanspruch 1 gemäß Hilfsantrag 1, hier mit einer Gliederung versehen, lautet (Änderungen gegenüber dem ursprünglichen Patentanspruch 1 sind markiert):

M1H1 Verfahren zur Synchronisierung von Aufgabenzum Verbessern eines Durchsatzes in einem Test- und Messsystem (10), umfassend:

M2´ Empfangen (60) eines ersten Aufgabeneingangs an einem Client (30) im System; M3´ Empfangen, an einem Auftragsmanager (38), der auf einem ersten Vorrichtungsprozessor (10) im System läuft, eines Aufrufs (80) vom Client (30), um einen mit der ersten Aufgabe verbundenen Auftrag (40) zu erstellen, M4 wobei der Auftragsmanager (38) eine vom Client (30) festgelegte Fertigstellungsrichtlinie und eine globale eindeutige Kennung (GUID) zum Identifizieren des Clients (30) erhält; M4a wobei die Fertigstellungsrichtlinie ein oder mehrere Zwischenziele umfassen kann, die Einstellungszwischenziele und/oder Datenzwischenziele sein können; M5 Zurückgeben (64), vom Auftragsmanager (38), einer Aktion, die mindestens einen mit dem Auftrag (40) verknüpften Auftragscodeblock enthält, an den Client (30); M6 Empfangen eines Aufrufs zur Aufrufen (66) der Aktion; M7 Ausführen (68) des mindestens einen Auftragscodeblocks (42) durch mindestens einen Prozessor im System (10); Feststellen, dass der Auftrag abgeschlossen ist; und Erledigung der Aufgabe .

M11H1 Empfangen (60), bei einem Client (30), eines zweiten Aufgabeneingangs, M12H1 Empfangen, beim Auftragsmanager (38), eines Aufrufs (80) vom Client (30) des zweiten Aufgabeneingangs, um einen mit der zweiten Aufgabe verbundenen zweiten Auftrag zu erstellen, M13H1 wobei der Auftragsmanager (38) eine vom Client (30) des zweiten Aufgabeneingangs festgelegte zweite Fertigstellungsrichtlinie und eine globale eindeutige Kennung (GUID) zum Identifizieren des Clients (30) erhält und der zweite Auftrag ein Abschließen (90) des ersten Auftrags verlangt, und M14H1 nach einem Feststellen (70), durch den Auftragsmanager (38), dass der erste Auftrag gemäß der entsprechenden Fertigstellungsrichtlinie abgeschlossen ist und M15H1 einem Abschließen (90) der Aufgabe, M8a wobei die Fertigstellungsrichtlinie durch einen Auftragsmisserfolg oder einen Auftragserfolg erfüllt wird, M8b wobei ein Auftragserfolg eintritt, wenn der Auftrag nicht mehr aktiv ist und einer der folgenden vom Client bestimmten Punkte zutrifft:

- - alle Einstellungszwischenziele sind erreicht; alle Einstellungszwischenziele sind erreicht und es ist entweder keine Datenerfassung erfolgt oder alle Datenzwischenziele sind erreicht; und - alle Einstellungszwischenziele und Datenzwischenziele sind erreicht, M16H1 Zurückgeben (64), durch den Auftragsmanager (38) an den Client (30) des zweiten Auftrags, einer mindestens einen mit dem zweiten Auftrag verbundenen Auftragscodeblock (42) umfassenden zweiten Aktion zum Ausführen (68) dieses Auftragscodeblocks (42).

Der geltende Patentanspruch 1 gemäß Hilfsantrag 2, hier mit einer Gliederung versehen, lautet (Änderungen gegenüber dem ursprünglichen Patentanspruch 1 sind markiert):

M1 Verfahren zur Synchronisierung von Aufgaben in einem Test- und Messsystem, umfassend:

M2 Empfangen (60) eines Aufgabeneingangs an einem Client (30) im System; M3 Empfangen, an einem Auftragsmanager (38), der auf einem ersten Vorrichtungsprozessor (10) im System läuft, eines Aufrufs (80) vom Client (30), um einen mit der Aufgabe verbundenen Auftrag (40) zu erstellen, M4 wobei der Auftragsmanager (38) eine vom Client (30) festgelegte Fertigstellungsrichtlinie und eine globale eindeutige Kennung (GUID) zum Identifizieren des Clients (30) erhält, M4a wobei die Fertigstellungsrichtlinie ein oder mehrere Zwischenziele umfassen kann, die Einstellungszwischenziele und/oder Datenzwischenziele sein können; M5 Zurückgeben (64) vom Auftragsmanager (38) einer Aktion, die mindestens einen mit dem Auftrag (40) verknüpften Auftragscodeblock enthält, an den Client (30); M6 Empfangen eines Aufrufs zur Aufrufen der Aktion; M7 Ausführen (68) des mindestens einen Auftragscodeblocks (42) durch mindestens einen Prozessor im System (10); M8 Feststellen (70) durch den Auftragsmanager (38), dass der Auftrag gemäß der Fertigstellungsrichtlinie abgeschlossen ist, M8a wobei die Fertigstellungsrichtlinie durch einen Auftragsmisserfolg oder einen Auftragserfolg erfüllt wird, M8b´ wobei ein Auftragserfolg eintritt, wenn der Auftrag nicht mehr aktiv ist und der folgende Punkt zutrifft:

- alle Einstellungszwischenziele sind erreicht; und M9 Erledigung Abschließen (90) der Aufgabe M10 und informieren des Systems hierüber. Zu den übrigen Patentansprüchen und den weiteren Einzelheiten wird auf die Akte verwiesen.

II. Die Beschwerde wurde rechtzeitig eingelegt und ist auch sonst zulässig. Sie hat jedoch keinen Erfolg, da das Verfahren des jeweiligen Patentanspruchs 1 gemäß Hauptantrag sowie gemäß den Hilfsanträgen 1 und 2 nicht auf erfinderischer Tätigkeit beruht (§ 1 Abs. 1 in Verbindung mit § 4 Satz 1 PatG). Die Frage, ob die in den Anträgen vorgenommenen Änderungen über den ursprünglichen Inhalt der Anmeldung hinausgehen und damit zu einer unzulässigen Erweiterung führen, kann insoweit dahinstehen.

1. Die Anmeldung betrifft Systeme und Verfahren zur Synchronisierung des Betriebs mehrerer Instrumente, wobei es sich bei den Instrumenten um Test- und Messinstrumente, wie z. B. Oszilloskope, handelt (vgl. Offenlegungsschrift, Abstract; Absatz [0002]). Ausweislich der Anmeldung definiere das Protokoll „Standard Commands for Programmable Instruments“ (SCPI) einen Standard für Syntax und Befehle zur Verwendung bei der Steuerung programmierbarer Test- und Messvorrichtungen. Zwei Standard-SCPI-Befehle, die in jeder Vorrichtung implementiert werden müssten, die SCPI unterstütze, seien „*OPC?“ („Operation Complete Query“), was eine Abfrage in Bezug auf den Abschluss einer Operation bedeute, und „*WAI“ („Wait-to-Continue“), was einen Befehl zum Warten auf die Fortsetzung darstelle. Diese beiden Standardbefehle würden zusammen mit einem „*OPC“-Befehl („Operation Complete“) von einer Vorrichtungssteuerung, z. B. einem computergesteuerten automatischen Testsystem, verwendet, um die Ausführung ihres Programms mit dem tatsächlichen Betrieb der zu testenden Vorrichtung (DUT) zu synchronisieren. Dies sei in der SCPI-99-Spezifikation zu finden (vgl. Offenlegungsschrift, Absatz [0003]).

In der Test- und Messtechnik sei jedoch hinlänglich bekannt, dass sich die Reaktionen der Instrumente auf die Befehle „*OPC“, „*WAI“ und „*OPC?“ aufgrund unterschiedlicher und inkonsistenter Implementierungen von SCPI in verschiedenen Test- und Messinstrumenten nicht vorhersehbar und zuverlässig verhielten. Beispielsweise gäben einige Instrumente eine Antwort auf die Abfrage in Bezug auf den Abschluss einer Operation zurück, die anzeige, dass das Instrument eine Operation abgeschlossen habe, obwohl dies in Wirklichkeit nicht der Fall sei. Andere Instrumente schlössen eine Operation tatsächlich ab, gäben jedoch keine rechtzeitige Antwort auf die Abfrage bezüglich des Abschlusses der Operation zurück. Dieses inkonsistente Verhalten habe viele Testingenieure und andere Autoren von Vorrichtungssteuerungsprogrammen dazu veranlasst, verschiedene Wartezeiten, Verzögerungen, Bereitschaftsmodi und/oder Timeouts in ihre Testprogramme einzufügen, um die unterschiedlichen Antworten der Instrumente auszugleichen. Während diese Verzögerungen und Timeouts manchmal für ein Testprogramm notwendig seien, um einige Instrumente zu steuern, seien diese Verzögerungen und Timeouts in anderen Fällen irrelevant oder ineffizient und führten zu einer unnötigen Reduzierung des Durchsatzes von automatisierten Testsystemen, was in Fertigungsbetrieben ein erhebliches Problem darstellen könne (vgl. Offenlegungsschrift, Abs. [0004]).

Die der Anmeldung zugrundeliegende Aufgabe sieht der Senat darin, einerseits die Synchronisation von Prozessen auf unterschiedlichen Vorrichtungen sicherzustellen und andererseits die Prozesse im zeitlichen Ablauf zu optimieren. Der maßgebliche Durchschnittsfachmann, auf dessen Wissen und Können es insbesondere für die Auslegung der Merkmale der Anmeldung und für die Interpretation des Standes der Technik ankommt, ist ein Ingenieur der Fachrichtung Elektrotechnik, der über eine mehrjährige Berufserfahrung auf dem Gebiet der Steuerung und Programmierung von Test- und Messgeräten verfügt und der fundierte Kenntnisse auf dem Gebiet verteilter Systeme besitzt.

2. Einige Begriffe bedürfen der Auslegung (in Klammern die entsprechenden Begriffe aus einer der prioritätsbegründenden Anmeldungen). Zum Begriff „Aufgabe“ („task“):

Die Patentanmeldung versteht unter dem Begriff „Aufgabe“ einen zu erledigenden Arbeitsvorgang. Einen solchen Arbeitsvorgang kann z. B. das Hinzufügen einer neuen Messung durch das System, die Anzeige von Wellenformen oder die Reaktion auf Mauseingaben darstellen. Diese „Aufgaben“ können alle zur gleichen Zeit auftreten und die Threads, die sie verarbeiten, müssen gewöhnlich zusammenarbeiten (vgl. Offenlegungsschrift, Absatz [0010]).

Zum Begriff „Auftrag“ („job“):

Laut Beschreibung handelt es sich bei einem „Auftrag“ um ein Objekt, das mit einer zu erledigenden Aufgabe verknüpft ist. Ist ein „Auftrag“ im System angelegt, kann ein Client, d. h. eine clientseitige Anwendung, das Auftragsobjekt verwenden und mit anderen Teilen des Systems gemeinsam nutzen (vgl. Offenlegungsschrift, Absatz [0017]). Ein solcher „Auftrag“ kann „Zwischenziele“ beinhalten (vgl. Offenlegungsschrift, Absatz [0031]).

Zum Begriff „Auftragsmanager“ („job manager“):

Beim anspruchsgemäßen „Auftragsmanager“ handelt es sich um eine Softwarekomponente, die auf einem Prozessor im System ausgeführt wird und die „Aufträge“ verwaltet. Auf die Anforderung eines Clients hin erstellt der „Auftragsmanager“ einen „Auftrag“, der mit einem „Auftragscodeblock“ beginnt (vgl. Offenlegungsschrift, Absätze [0015], [0017], [0022]).

Zum Begriff „Zwischenziel“ („milestone“):

Laut Absatz [0031] der Offenlegungsschrift steht ein „Zwischenziel“ für ein Auftragsergebnis, das aus der Zusammenarbeit mit einer anderen Aktivität außerhalb des Auftrags resultiert. Das „Zwischenziel“ repräsentiert somit einen Meilenstein, d. h. einen wichtigen Kontrollpunkt, der zwar in einem Auftragsobjekt mit angelegt ist, dessen zugehöriges Ergebnis aber von einem Prozess auf einem der Subsysteme im Test- und Messsystem herrührt, z. B. auf einem Subsystem, das Messwerte berechnet. Ein solcher Prozess stellt eine Aktivität dar, die außerhalb des Auftragsobjekts und des Auftragsmanagers bzw. der Auftragsverwaltung stattfindet.

Zu den Begriffen „Einstellungszwischenziel“ und „Datenzwischenziel“ („settings milestone“, „data milestone“):

In der Anmeldung wird nicht festgelegt, was unter einem „Einstellungszwischenziel“ bzw. „Datenzwischenziel“ zu verstehen ist. Aus dem Kontext heraus wird der Fachmann unter einem „Einstellungszwischenziel“ einen Meilenstein verstehen, an dem Einstellungen an einem Subsystem im Test- und Messsystem durchgeführt worden sind. In einem „Datenzwischenziel“ ist hingegen ein Meilenstein zu sehen, an dem an einem Subsystem im Test- und Messsystem Daten ermittelt worden sind, z. B. per Messung oder Berechnung.

Zum Begriff „Auftragscodeblock“ („job code block“):

Laut Beschreibung könne es sich bei „Auftragscodeblöcken“ „um .NET System.Action handeln“ (vgl. Offenlegungsschrift, Absatz [0021]). Nach fachmännischem Verständnis sind in diesem Zusammenhang z. B. sogenannte Delegates in der objektorientierten Programmiersprache C# von Bedeutung, die von der plattformübergreifenden Entwicklungsplattform .NET unterstützt wird. Ein solcher Delegate ist ein Sprachkonstrukt und stellt technisch gesehen eine normale Klasse dar. Ein Delegate-Objekt kann auf eine oder mehrere Methoden verweisen und fungiert insoweit als eine Art Funktionszeiger, der für synchrone und asynchrone Funktionsaufrufe genutzt werden kann. Wichtige Einsatzbereiche für Delegates sind bekanntlich Rückrufe (callbacks) und die Verarbeitung von Ereignissen (events). Der in Absatz [0021] mit „System.Action“ angesprochene Action-Delegate stellt aus fachmännischer Sicht einen der in C# vordefinierten Delegatetypen dar und wird verwendet, wenn eine Methode ausgeführt werden soll, die keinen spezifischen Rückgabewert zurückgibt, sondern sich stattdessen auf die bloße Ausführung von Operationen konzentriert. Der Action-Delegate kapselt demnach eine Methode mit keinem oder wenigstens einem Parameter, die aber keinen Rückgabewert liefert. Nach allem wird der Fachmann eine solche in einem Delegate-Objekt gekapselte Methode als „Auftragscodeblock“ verstehen. Der Begriff „Auftragscodeblock“ ist aber nicht bloß auf Delegates beschränkt. Vielmehr ist mit einem „Auftragscodeblock“ jegliches Sprachkonstrukt gemeint, das spezielle Funktionsaufrufe beinhaltet und mit dem insbesondere Callback-Funktionen implementiert werden können, z. B. in einem Skript verpackte Funktionsaufrufe in einem verteilten System sowie Callback-Befehle (z. B. in C, Python oder Java), die auf vordefinierte Benutzeraktionen oder abgeschlossene Operationen hin ausgeführt werden.

Zum Begriff „Aktion“ („action“):

Mit Blick auf Absatz [0024] der Offenlegungsschrift kann es sich bei der anspruchsgemäßen „Aktion“ um eine eingehüllte Aktion handeln, z. B. ein Objekt .NET System.Action, in dem sich der „Auftragscodeblock“ befindet. Ganz allgemein ist in der „Aktion“ irgendein instanziiertes Objekt zu sehen, auf dem eine vordefinierte Methode bzw. Funktion mit einer Reihe von Anweisungen – darunter eben auch eine Callback-Funktion – ausgeführt wird.

Zum Begriff „Fertigstellungsrichtlinie“ („completion policy“):

Gemäß Absatz [0037] der Offenlegungsschrift können Aufträge eine „Fertigstellungsrichtlinie“ beinhalten. Demnach ist eine „Fertigstellungsrichtlinie“ diejenige Regel, die ein Auftrag verwendet, um zu entscheiden, wann der Auftrag abgeschlossen ist. Dabei können verschiedene Aufträge unterschiedliche Richtlinien haben. Der Client muss die „Fertigstellungsrichtlinie“ angeben, wenn er den Auftragsmanager dazu aufruft, den Auftrag zu erstellen. Unter den Begriff „Fertigstellungsrichtlinie“ fallen somit alle Angaben, die Bedingungen anzeigen, unter denen ein Auftrag als beendet angesehen werden kann, z. B. welche Aufträge bzw. Aufgaben – auch aufgrund von Abhängigkeiten - abgearbeitet worden sein müssen, bevor ein bestimmter Auftrag überhaupt als erledigt betrachtet werden kann.

3. Zum Hauptantrag Der Patentanspruch 1 gemäß Hauptantrag ist nicht gewährbar, da sein Gegenstand nicht auf erfinderischer Tätigkeit beruht.

3.1 Zur Lösung der oben genannten Aufgabe schlägt der Patentanspruch 1 gemäß Hauptantrag ein Verfahren vor, das der Synchronisierung von Aufgaben in einem Test- und Messsystem dient (Merkmal M1). Merkmal M2 sieht vor, dass ein Client im Test- und Messsystem eine Aufgabe empfängt, d. h. ein Client im System erhält als Eingabe eine Aufgabe.

Gemäß Merkmal M3 fordert der Client von einem Auftragsmanager einen Auftrag an, der mit der Aufgabe verknüpft ist. Der Auftragsmanager, der auf einem ersten Vorrichtungsprozessor im System läuft, soll diesen Auftrag erstellen. Mit Merkmal M4 wird beansprucht, dass der Auftragsmanager eine vom Client festgelegte Fertigstellungsrichtlinie und eine globale eindeutige Kennung zum Identifizieren des Clients erhält.

Merkmal M4a besagt, dass die Fertigstellungsrichtlinie ein oder mehrere Zwischenziele umfassen kann, wobei die Zwischenziele Einstellungszwischenziele und/oder Datenzwischenziele sein können. Ausgehend von den Absätzen [0018] und [0039] der Offenlegungsschrift wird der Fachmann Merkmal M4a derart verstehen, dass die Fertigstellungsrichtlinie unter Einbeziehung von Einstellungs- und/oder Datenzwischenzielen formuliert sein kann.

Der Auftragsmanager gibt eine Aktion an den Client zurück. Diese enthält mindestens einen mit dem Auftrag verknüpften Auftragscodeblock (Merkmal M5). Damit ist gemeint, dass der Auftragsmanager ein Objekt instanziiert, das wenigstens eine Methode bzw. Funktion kapselt und dem Client bereitgestellt wird. Laut Merkmal M6 wird die Aktion aufgerufen. Das bedeutet, dass die wenigstens eine Methode bzw. Funktion auf dem Objekt aufgerufen wird. Objekt und Methode bzw. Funktion werden miteinander verknüpft. Gemäß den Absätzen [0024] und [0026] der Offenlegungsschrift ist es ein Client, ein anderer Thread usw., der den Auftragscodeblock, d. h. die wenigstens eine Methode bzw. Funktion „ins Feld“ führt. Demnach ist diejenige Instanz, die die Erstellung eines Auftrags beim Auftragsmanager anfordert, auch dafür verantwortlich, dass die wenigstens eine Methode bzw. Funktion „auf die eine oder andere Weise aufgerufen wird.“ Merkmal M7 sieht vor, dass der mindestens eine Auftragscodeblock durch mindestens einen Prozessor ausgeführt wird.

Nachdem der Auftragsmanager festgestellt hat, dass der Auftrag entsprechend der Fertigstellungsrichtlinie abgeschlossen ist (Merkmal M8) und die Aufgabe abgeschlossen ist (Merkmal M9), wird das System darüber informiert (Merkmal M10). Hierbei sieht Merkmal M8a vor, dass die Fertigstellungsrichtlinie durch einen Auftragsmisserfolg oder einen Auftragserfolg erfüllt wird.

Laut Merkmal M8b soll ein Auftragserfolg dann eintreten, wenn der Auftrag nicht mehr aktiv ist und einer der folgenden vom Client bestimmten Punkte zutrifft:

- alle Einstellungszwischenziele sind erreicht; - alle Einstellungszwischenziele sind erreicht und es ist entweder keine Datenerfassung erfolgt oder alle Datenzwischenziele sind erreicht; und - alle Einstellungszwischenziele und Datenzwischenziele sind erreicht. Bei dem von der Anmelderin zugrunde gelegten Verständnis und bei Auslegung entsprechend Absatz [0039] der Offenlegungsschrift – wovon der Senat im Folgenden ausgeht – besagt Merkmal M8b, dass ein Auftrag dann erfolgreich abgeschlossen ist, wenn er nicht mehr aktiv ist und eine mit der vom Client gewählten Fertigstellungsrichtlinie verknüpfte Voraussetzung erfüllt ist, wobei diese Voraussetzung einer der drei folgenden Punkte ist:

- alle Einstellungszwischenziele des Auftrags sind erreicht; - alle Einstellungszwischenziele des Auftrags sind erreicht, und es sind entweder keine Datenerfassungen mehr am Laufen oder alle Datenzwischenziele des Auftrags sind erreicht oder - alle Einstellungszwischenziele und alle Datenzwischenziele des Auftrags sind erreicht.

3.2 Zur Beurteilung der beanspruchten Lehre ist die Druckschrift D2 von besonderer Bedeutung. So führt die Druckschrift D2 den Fachmann zu einem Verfahren, das die Messung, Analyse, Verifizierung und Validierung von Daten in einer verteilten Rechnerumgebung unterstützt, welche Messgeräte aber auch Testumgebungen umfasst (vgl. D2, Abs. [0002]; [0169]; [0178] ff).

Im Verfahren der D2 wird ein aus einem oder mehreren Tasks bestehender Job, also ein aus einer oder mehreren Aufgaben bestehender Auftrag, an einen automatischen Verteilmechanismus 260 bzw. einen Job-Manager 265 übergeben, um den einen oder die mehreren Tasks an „computing workers“ zu verteilen, die technische Berechnungen sowie Messungen ausführen (vgl. D2, Abs. [0005]; [0042]; [0043]; [0047]; [0060]; Fig. 3D). Die Tasks können unabhängig voneinander und gleichzeitig oder aber aufeinander folgend ausgeführt werden (vgl. D2, Abs. [0069], siehe „… technical computing workers 270A-270N can either execute tasks independently and in parallel to each other, or also execute tasks serially and subsequent to each other.“). Die im System der D2 befindlichen Jobs werden außerdem nach dem FIFO-Prinzip abgewickelt (vgl. D2, Abs. [0074]). Insoweit sorgt das aus der D2 bekannte Verfahren dafür, dass Vorgänge zur Abarbeitung von Tasks und Jobs zeitlich abgeglichen werden, also aufeinander synchronisiert sind. Merkmal M1 ist somit in der D2 offenbart.

Die D2 lehrt außerdem, dass ein Benutzer an einem Client wenigstens einen Task angibt, d. h. der Client empfängt wenigstens eine Aufgabe (vgl. D2, Abs. [0042], siehe „Tasks can be declared on a technical computing client …“ – Merkmal M2). Bei dem Client kann es sich um eine Anwendung zur Durchführung von Berechnungen und zur grafischen Modellierung handeln, um Blockdiagramme zu erzeugen und mathematische Algorithmen für Simulationen festzulegen.

Insbesondere kann der Client ein MATLAB-basierter Client sein, der wenigstens einen Teil der gesamten Funktionalität der MATLAB-Programmiersprache und Entwicklungsumgebung zur Verfügung stellt (vgl. D2, Abs. [0054]). Weiterhin wird der wenigstens eine Task auf dem Computersystem des Clients in einem Job organisiert, was wiederum nichts anderes bedeutet, als dass mittels des Clients auf eine Anforderung hin ein mit der wenigstens einen Aufgabe verbundener Auftrag erstellt wird (vgl. D2, Abs. [0041], siehe „The instrument-based distributed computing system may include a client for creating the job.“; Abs. [0042], siehe „Tasks can be declared on a technical computing client and additionally organized into jobs.“). Allerdings ist es in der D2 nicht der auf dem Server 160 (also einem Vorrichtungsprozessor im System) ablaufende Job-Manager 265, der in Antwort auf die Anforderung eines Clients einen Job erstellt. Merkmal M3 ist sonach nur teilweise erfüllt.

Weil ein Job immer erst dann als beendet gilt, wenn all die darin enthaltenen Tasks abgearbeitet sind (vgl. D2, Abs. [0074]; [0087]; [0102]), ist mit der Übergabe eines Jobs an den Job-Manager 265 gleichzeitig eine Regel verbunden, die konkret besagt, welche Tasks erledigt sein müssen, bevor der zugehörige Job als abgeschlossen gilt. Eine solche Regel fungiert als Fertigstellungsrichtlinie i. S. d. Merkmals M4. Weiterhin kann über die „timeout property“ eines Job-Objekts eine Zeitbeschränkung für die Laufzeit eines Jobs festgelegt werden, wodurch eine zusätzliche Regel für die Beendigung eines Jobs vom Client an den Job-Manager 265 kommuniziert werden kann (vgl. D2, Abs. [0144], [0157]). Demnach hat der Client die Möglichkeit auszuwählen, ob eine Fertigstellungsrichtlinie mit oder ohne Zeitbeschränkung zur Anwendung kommen soll.

Weiterhin geht aus der D2 hervor, dass ein Client beim Job-Manager 265 eine „callback“-Funktion registriert, über die der Client benachrichtigt werden kann, wenn ein von ihm abgesetzter Job abgearbeitet worden ist (vgl. D2, Abs. [0087]). Der Fachmann wird erkennen, dass eine solche Registrierung mit der Vergabe und Übermittlung eines Kennzeichners, einer Adresse o. ä. an den Job-Manager 265 verbunden sein muss, anhand dessen bzw. anhand der der Job-Manager 265 erkennt, welcher Client mittels der „callback“-Funktion in Kenntnis gesetzt werden soll.

Damit ergibt sich Merkmal M4 aus der D2. Die aus der D2 bekannten Regeln beinhalten auch Zwischenziele i. S. d. Anmeldung. So korrespondiert jeder Task mit einem Zwischenziel, das aus der Zusammenarbeit mit einer Aktivität außerhalb des Auftrags bzw. Jobs resultiert. Denn jeder Task der D2 wird einem „computing worker“ oder einem Instrument zugewiesen, um dort außerhalb der Jobverwaltung und des Job-Managers 265 abgearbeitet zu werden. Die von den Tasks eines Jobs erzielten Resultate repräsentieren insbesondere Zwischenziele, die Einstellungs- und Datenzwischenziele beinhalten können. Nichts anderes folgt aus den Absätzen [0179] ff der D2, wonach Testumgebungen konfiguriert (vgl. D2, Abs. [0179], siehe „… users may input control data 1240 for setting conditions for testing the units under test 1230 in the test environment 1200.“; „The users may also input the variables and parameters of the test that can be used as arguments to call the functions provided by the resources 1210.“) und Berechnungen auf einem Instrument durchgeführt, also Daten erfasst werden können (vgl. D2, Abs. [0183]). Merkmal M4a geht sonach aus der D2 hervor.

Der Job-Manager 265 entnimmt den wenigstens einen Task aus einer Warteschlange und schreibt das wenigstens eine Task-Objekt in ein „object exchange repository“ 662, das als JavaSpace implementiert sein kann (vgl. D2, Abs. [0095]; [0096]). Damit wird vom Job-Manager 265 nicht nur das wenigstens eine Task-Objekt bereitgestellt bzw. instanziiert, sondern der Aufruf der auf dem Task- Objekt vordefinierten Methoden bzw. Funktionen wird zumindest vorbereitet. Schließlich entnimmt ein „computing worker“ das wenigstens eine Task-Objekt aus dem „object exchange repository“ 662 und ruft die zugehörigen Methoden bzw. Funktionen auf (vgl. D2, Abs. [0096], siehe „The technical computing worker 270 obtains the function to be executed from the definition of the function in data structure of the task object, …“).

Allerdings lehrt die D2 nicht, dass die mit einem Job verknüpften Methoden bzw. Funktionen vom Job-Manager 265 an einen Client zurückgegeben und von diesem aufgerufen werden, weswegen die Merkmale M5 und M6 lediglich zum Teil in der D2 offenbart sind. Der in Absatz [0096] der D2 angesprochene „computing worker“ führt die auf einem Task-Objekt definierten Methoden bzw. Funktionen aus, d. h. ein Prozessor im bekannten System führt einen Auftragscodeblock iSd Merkmals M7 aus (vgl. D2, Abs. [0096], siehe „The technical computing worker 270 … performs the function and generates a result of the function for the task.“) – Merkmal M7. Wenn der Job-Manager 265 feststellt, dass das letzte Resultat der in einem Job enthaltenen Tasks ermittelt worden ist, und der Job demnach als beendet zu betrachten ist, werden die Tasks noch dadurch abgeschlossen, dass die Resultate der Tasks für den komplettierten Job an den zugehörigen Client übertragen werden (vgl. D2, Abs. [0102], siehe „The job manager 265 checks to see if this is the last result to be obtained from a technical computing worker 270A-270N for the job currently being processed. If the result is the last result, the job manager 265 can provide the set of task results for the completed job to the technical computing client 250.“ – Merkmale M8, M9).

Der Fachmann wird erkennen, dass die aus der D2 bekannten Regeln mit einem Auftragserfolg oder einem Auftragsmisserfolg erfüllt werden können. Ein Auftragserfolg liegt in der Lehre der D2 ersichtlich dann vor, wenn die zu einem Job gehörigen Tasks alle positiv evaluiert werden und bei deren Ausführung keine Fehlermeldung erfolgt. Eine solche Fehlermeldung ist als Eigenschaft im „result object“ angelegt (vgl. D2, Abs. [0121] mit davorstehender Textzeile, siehe „ErrorMessage“, sowie Abs. [0116], letzter Satz), das vom Job-Manager 265 aus dem „object exchange repository“ 662 abgeholt wird und dessen Resultat zusammen mit den Resultaten der anderen „result-objects“ des Jobs an den Client weitergereicht wird, wenn der Job als beendet gilt (vgl. D2, Abs. [0095], siehe „The job manager 265 listens and waits for the result to appear in the object exchange repository 662.“; Abs. [0096], siehe „… the technical computing client 250 then interfaces with the job manager 265 to retrieve the results from the job manager 265, which the job manager 265 retrieves from the object exchange repository 662 by performing a take operation.“; Abs. [0102], siehe „If the result is the last result, the job manager 265 can provide the set of task results for the completed job to the technical computing client 250.“).

Umgekehrt liegt ein Auftragsmisserfolg dann vor, wenn zumindest ein Task mit einer Fehlermeldung endet. Merkmal M8a ist damit in der D2 offenbart. Insbesondere tritt in der D2 ein Auftragserfolg dann ein, wenn der Auftrag unter der vom Client bestimmten Fertigstellungsrichtlinie abgearbeitet, also nicht mehr aktiv ist, und wenn jeder seiner Tasks fehlerfrei und somit erfolgreich war, so dass auch alle durch die Tasks des Auftrags festgelegten Einstellungs- und Datenzwischenziele erreicht worden sind (Merkmal M8b), wie z. B. Berechnungen sowie Einstellungen von Variablen und Parametern an Testumgebungen (vgl. D2, Abs. [0183], [0179]). Damit geht zumindest eine Alternative bzw. ein Punkt des Merkmals M8b aus der D2 hervor.

Der Client wird dabei vom Job-Manager 265 über die registrierte „callback“-Funktion benachrichtigt, dass der Job abgearbeitet worden ist (vgl. D2, Abs. [0087], siehe „If the job manager 265 received the last result of the job, the job manager 265 will notify the technical computing client 250 that the job is completed via the registered callback function (step 595).“) – Merkmal M10. 3.3 Die Würdigung dieses Materials aus dem Stand der Technik ergibt, dass der mit dem Patentanspruch 1 gemäß Hauptantrag beanspruchte Gegenstand für den Fachmann nahegelegen hat.

Von der Lehre der D2 unterscheidet sich die Lehre nach dem Patentanspruch 1 gemäß Hauptantrag zum einen dadurch, dass nicht wie in der D2 der Client eine Anforderung erhält, den wenigstens einen Task in einem Job zu organisieren, und diesen Job auch erstellt, sondern dass der auf dem Server 160 ablaufende Job- Manager vom Client eine solche Anforderung empfängt (restlicher Teil von Merkmal M3) und einen Job für diesen wenigstens einen Task generiert. Zum anderen unterscheidet sich die beanspruchte Lehre von der Lehre der D2 noch dadurch, dass nicht wie in der D2 ein „computing worker“ das wenigstens eine Task-Objekt aus dem „object exchange repository“ 662 per Take-Operation holt und die darin festgelegten Methoden bzw. Funktionen aufruft, sondern dass der Client das vom Job-Manager 265 stammende wenigstens eine Task-Objekt holt, dieses per „write“- oder „submit“-Anweisung aufruft (vgl. D2, Abs. [0092]; [0116]) und über das „object exchange repository“ 662 an den zuständigen „computing worker“ durchreicht (restlicher Teil der Merkmale M5 und M6).

Die verbliebenen Unterschiedsmerkmale erschöpfen sich aber darin, bestimmte Operationen der Datenverarbeitung von einem Client auf den Server 160 zu verlagern sowie die Kommunikation zwischen Server und „computing worker“ über das „object exchange repository“ 662 in eine Kommunikation zwischen Server, Client und „computing worker“ umzuordnen. Die hierfür nötigen Schritte sind aber nicht mehr als eine äußerlich-organisatorische Umverlagerung der Datenverarbeitung zwischen mehreren Netzwerkkomponenten und stellen somit lediglich Maßnahmen der Datenverarbeitung dar, hingegen nicht die Lösung eines konkreten technischen Problems (vgl. BGH GRUR 2011, 610 – Webseitenanzeige). Weil die Anweisungen der Unterschiedsmerkmale die Lösung des technischen Problems mit technischen Mitteln weder bestimmen noch zumindest beeinflussen, sind sie bei der Beurteilung der erfinderischen Tätigkeit nicht zu berücksichtigen (vgl. BGH GRUR 2011, 125 – Wiedergabe topografischer Informationen).

3.4 Die von der Anmelderin vorgetragenen Einwände greifen nicht durch.

3.4.1 Nach Auffassung der Anmelderin kommt mit den im Patentanspruch 1 vorgenommenen Änderungen zum Ausdruck, dass der Client eine Fertigstellungsrichtlinie festlegt, in der spezifisch definiert werden kann, welche Einstellungen an den einzelnen Vorrichtungen des Systems vorgenommen werden müssen, damit der Auftrag erfüllt ist, und/oder welche Daten erfasst werden müssen, damit der Auftrag erfüllt ist.

Demgegenüber enthalte die D2 allenfalls die systemimmanente Regel, dass ein Job abgeschlossen ist, wenn das letzte Ergebnis vorliegt, d. h., dass alle Threads des Jobs bis zum Ende ausgeführt worden sind. Eine solche Regel müsse aber nicht individuell vom Client erstellt werden. Somit enthalte die D2 keinerlei Anregung, dass ein Client individuelle Regeln erstellt, wann ein Auftrag als abgeschlossen zu beurteilen ist.

Den Ausführungen war nicht zu folgen. So offenbart die D2 eine Regel, wonach ein Job erst dann als abgeschlossen gilt, wenn alle darin enthaltenen Tasks abgearbeitet worden sind (vgl. D2, Abs. [0074]; [0087]; [0094]; [0102]). Wie viele Tasks sowie welche Art von Tasks in einem Job (Einstellungen oder Berechnungen) untergebracht sind, wird dabei von einem Client bestimmt. Ebenso wird vom Client festgelegt, ob und welche Time-Limits für den Job und die darin enthaltenen Tasks gelten. Wird z. B. der Job aus Tasks zusammengesetzt, die Meilensteine betreffend Einstellungs- und Datenzwischenziele repräsentieren, so ergibt sich unmittelbar, dass ein Auftrag erst dann als erfolgreich ausgeführt gilt, wenn er gemäß Absatz [0094] der D2 abgeschlossen ist und zugleich alle Einstellungs- und Datenzwischenziele ohne Fehler erreicht worden sind. Insoweit bestimmt der Client zumindest indirekt, dass die zuletzt in Merkmal M8b genannte Voraussetzung vorliegt, damit ein Auftragserfolg eintritt.

Alles in allem handelt es sich bei der aus der D2 bekannten Regel um eine Richtlinie, die zumindest teilweise von einem Client angepasst werden kann.

3.4.2 Auch der Einwand, die Lehre der D2 sehe keinerlei Rückmeldung von Zwischenergebnissen an einen Client vor, vermochte nicht zu überzeugen. So lehrt die D2, dass der Job-Manager 265 ein „result object“ aus dem „exchange repository“ 662 abholen kann, nachdem er über ein Ereignis davon in Kenntnis gesetzt worden ist, dass ein solches Objekt neu vorliegt. Die Resultate aller „result objects“ eines Jobs werden immer dann vom Job-Manager 265 an den zuständigen Client kommuniziert, wenn der Job abgearbeitet ist (vgl. D2, Abs. [0095]; [0096]; [0102]).

Mit dem „result object“ erhält der Client zugleich Resultate über die Ausführung eines Tasks, welche in der Datenstruktur des „result objects“ definiert sind (vgl. D2, Abs. [0093]; [0096]; [0102]). Dabei ist das „result object“ mit einem ganz bestimmten Task verbunden und repräsentiert ein Zwischenziel bzw. einen Meilenstein innerhalb der Abarbeitung eines Auftrags, so dass der Client stets ein Wissen darüber hat, ob ein bestimmter Task des Auftrags erfolgreich ausgeführt werden konnte oder nicht.

3.5 Nach allem ergab sich der Gegenstand des Patentanspruchs 1 gemäß Hauptantrag in naheliegender Weise aus dem in der Druckschrift D2 aufgezeigten Stand der Technik.

4. Zum Hilfsantrag 1 Hilfsantrag 1 konnte nicht günstiger beurteilt werden, da der Gegenstand seines Patentanspruchs 1 nicht auf erfinderischer Tätigkeit beruht.

4.1 Der Patentanspruch 1 gemäß Hilfsantrag 1 unterscheidet sich von Patentanspruch 1 gemäß Hauptantrag dadurch, dass die Merkmale M1 bis M3 durch die Merkmale M1H1, M2´ und M3´ ersetzt werden. Die Merkmale M8 bis M10 werden gestrichen. Auf Merkmal M7 sollen die Merkmale M11H1 bis M16H1 folgen. Ferner werden zwischen den Merkmalen M15H1 und M16H1 noch die Merkmale M8a und M8b eingefügt.

4.2 Patentanspruch 1 gemäß Hilfsantrag 1 betrifft ein Verfahren, das dazu dient, den Durchsatz in einem Test- und Messsystem zu verbessern (Merkmal M1H1). Gemäß dem gegenüber Patentanspruch 1 gemäß Hauptantrag neu hinzugekommenen Merkmal M11H1 wird an einem Client im System eine zweite Aufgabe eingegeben.

Merkmal M12H1 sieht vor, dass dieser Client beim Auftragsmanager einen mit der zweiten Aufgabe verknüpften zweiten Auftrag anfordert. Der zweite Auftrag soll vom Auftragsmanager erstellt werden. Laut Merkmal M13H1 erhält der Auftragsmanager eine von dem Client der zweiten Aufgabe festgelegte zweite Fertigstellungsrichtlinie sowie eine globale eindeutige Kennung zum Identifizieren des Clients. Dabei setzt der zweite Auftrag voraus, dass der erste Auftrag abgeschlossen ist.

Nachdem der Auftragsmanager festgestellt hat, dass der erste Auftrag gemäß der entsprechenden Fertigstellungsrichtlinie abgeschlossen ist (Merkmal M14H1), und nach einem Abschließen der Aufgabe (Merkmal M15H1) gibt der Auftragsmanager an den Client des zweiten Auftrags eine zweite Aktion zurück, die mindestens einen mit dem zweiten Auftrag verbundenen Auftragscodeblock umfasst und über die dieser Auftragscodeblock ausgeführt werden soll (Merkmal M16H1).

Mit der Lehre des Patentanspruchs 1 gemäß Hilfsantrag 1 soll im Wesentlichen beansprucht werden, dass während bzw. nachdem die Verfahrensschritte M2 bis M7 ausgeführt werden bzw. ausgeführt worden sind, die Verfahrensschritte M11H1 bis M13H1 durchgeführt werden. Erst nachdem der Auftragsmanager dann festgestellt hat, dass der erste Auftrag gemäß der entsprechenden Fertigstellungsrichtlinie und auch die Aufgabe abgeschlossen sind (vgl. Merkmale M14H1 und M15H1), erhält der Client des zweiten Auftrags einen mit dem zweiten Auftrag verbundenen Auftragscodeblock zur Ausführung (Merkmal M16H1).

4.3 Die in Patentanspruch 1 gemäß Hilfsantrag 1 gegenüber dem Hauptantrag vorgenommenen Änderungen können eine Patentfähigkeit nicht begründen. So sieht die Lehre der D2 Sprachkonstrukte zur Implementierung von Programmbefehlen vor, welche eine parallele Verarbeitung von Jobs und Tests auf einer Mehrzahl von „computing workers“ verwirklichen (vgl. D2, Abs. [0184]). Somit dient das bekannte Verfahren auch dazu, den Durchsatz in einem Test- und Messsystem zu verbessern, d. h. die Anzahl von fertiggestellten Aufträgen bzw. Jobs pro Zeiteinheit zu vergrößern. Merkmal M1H1 ist in der D2 sonach offenbart. Weil die Merkmale M2 bis M9 aus der D2 zumindest nahegelegt sind, gilt dies gleichermaßen für die Merkmale M2´, M3´, M11H1 bis M15H1 und M16H1; denn im Verfahren der D2 ist nicht nur eine Mehrzahl von Clients vorgesehen (vgl. D2, Fig. 3A bis 4; Abs. [0074], siehe „Additionally, the job manager 265 using the queue 267 supports handling multiple job submissions and task distribution from multiple technical computing clients 250“; [0081], siehe „Additionally, the distributed system 400 is depicted supporting multiple clients 250A-250N communicating with multiple job managers 265A-265N …“), die unabhängig voneinander Tasks empfangen und diese in Jobs organisieren, um sie dann an einen Job-Manager 265 zu übergeben. Die D2 sieht darüber hinaus vor, die von den Clients abgesetzten Jobs in einer Warteschlange abzulegen und nach dem FIFO-Prinzip zu verwalten (vgl. D2, Abs. [0074]; [0094], siehe „While Job1 is being processed, the job manager 265 does not start to process the next job, Job2, until there are no tasks from the Job1 remaining to be processed in the object exchange repository 662.“). Demnach verarbeitet der Job-Manager 265 den nächsten Job immer erst dann, wenn alle Tasks des aktuellen Jobs abgewickelt sind, der aktuelle Job also entsprechend der mit der Warteschlange verknüpften Fertigstellungsrichtlinie abgeschlossen ist. Erst zu diesem Zeitpunkt werden die im nächsten Job enthaltenen Tasks bzw. die darin definierten Methoden bzw. Funktionen aufgerufen und ausgeführt.

Im Übrigen gelten die Ausführungen zum Hauptantrag.

4.4 Nach alledem waren für den Fachmann lediglich fachgemäße Überlegungen erforderlich, um in Kenntnis der Druckschrift D2 zu einem Gegenstand mit den Merkmalen des Patentanspruchs 1 gemäß Hilfsantrag 1 zu gelangen.

5. Zum Hilfsantrag 2 Auch der Hilfsantrag 2 konnte keinen Erfolg haben, weil der Gegenstand seines Patentanspruchs 1 mangels erfinderischer Tätigkeit nicht patentfähig ist.

5.1 Patentanspruch 1 gemäß Hilfsantrag 2 geht aus von Patentanspruch 1 gemäß Hauptantrag, wobei Merkmal M8b durch Merkmal M8b´ ersetzt worden ist.

5.2 Merkmal M8b´ besagt, dass ein Auftragserfolg dann eintreten soll, wenn der Auftrag nicht mehr aktiv ist und alle Einstellungszwischenziele erreicht sind.

5.3 Patentanspruch 1 gemäß Hilfsantrag 2 kann keinen Erfolg haben, da Merkmal M8b´ aus der Druckschrift D2 zumindest ableitbar ist. So wird der Fachmann erkennen, dass ein Job in der Lehre der D2 ausschließlich aus Tasks bzw. Anweisungen zusammengesetzt sein kann, die die Eingabe von Steuerdaten, Variablen und Parametern an einer Testumgebung betreffen (vgl. D2, Abs. [0179]). In einem solchen Fall tritt ein Auftragserfolg dann ein, wenn sämtliche Tasks des Jobs abgearbeitet sind – der Auftrag also als abgeschlossen gilt – und keine Fehlermeldung an den Client übermittelt worden ist, so dass also keines der „result objects“ eine „ErrorMessage“ beinhaltet (vgl. D2, Abs. [0121]). Der Fachmann liest in der D2 mit, dass alternativ oder zusätzlich hierzu der Fehlerstatus eines jeden Tasks mittels logischer Variablen in der Eigenschaft „OutputArguments“ seines jeweils korrespondierenden „result objects“ angezeigt werden kann. Signalisiert der Status demnach für jedes „result object“, dass sein Task fehlerlos war, wurde der Auftrag mit all seinen Einstellungen erfolgreich beendet. Weil „result objects“ Zwischenziele repräsentieren, sind damit gleichzeitig alle Einstellungszwischenziele des Auftrags erreicht.

Im Übrigen gelten die Ausführungen zum Hauptantrag.

5.4 Mit Rücksicht auf die Ausführungen zum Hauptantrag hat der Gegenstand des Patentanspruchs 1 gemäß Hilfsantrag 2 somit ausgehend von der D2 nahegelegen.

6. Mit dem nicht patentfähigen Patentanspruch 1 in der Fassung des Hauptantrags und der Hilfsanträge sind auch die weiteren Patentansprüche des Hauptantrags und der Hilfsanträge nicht schutzfähig, da auf diese Patentansprüche kein eigenständiges Patentbegehren gerichtet ist und über einen Antrag nur einheitlich entschieden werden kann (vgl. BGH GRUR 2007, 862 Rn. 18 – Informationsübermittlungsverfahren II).

Bei dieser Sachlage war die Beschwerde zurückzuweisen.

7. Eine Zurückverweisung der Sache an das Deutsche Patent- und Markenamt kam nicht in Betracht. Eine Zurückverweisung steht nach § 79 Abs. 3 PatG im Ermessen des Gerichts, wobei Instanzverlust, Verfahrensverzögerung und ausreichende Prüfung in der Sache gegeneinander abzuwägen sind. Bei Entscheidungsreife kommt eine Zurückverweisung nicht in Betracht, auch wenn neuer Stand der Technik ermittelt wurde (vgl. Schulte, PatG, 12. Auflage, § 79 Rn. 16-18 mit Verweis auf BGH BIPMZ 92, 496 – Entsorgungsverfahren). Wie oben ausgeführt, beruht die Lehre des jeweiligen Patentanspruchs 1 aller Anträge im Lichte der Lehre der vom Senat neu ermittelten Druckschrift D2 nicht auf erfinderischer Tätigkeit. Zu dieser Feststellung war der Senat aufgrund des ihm vorliegenden Materials in der Lage. Die Anmelderin ist ferner zur mündlichen Verhandlung vor dem Bundespatentgericht erschienen und hat erkennen lassen, dass sie sich nach der Zustellung der Druckschrift D2 mit deren Lehre inhaltlich auseinandergesetzt hat, was insbesondere auch zur Einreichung eines neuen Hauptantrages und zweier Hilfsanträge führte. Die Sache war somit entscheidungsreif und eine Zurückverweisung an das Deutsche Patent- und Markenamt nicht angezeigt.

8. Die Rückzahlung der Beschwerdegebühr war aus Billigkeitsgründen anzuordnen (§ 80 Abs. 3 PatG). Im vorliegenden Fall liegt eine unsachgemäße Sachbehandlung durch das Deutsche Patent- und Markenamt vor, was eine Rückzahlung der Beschwerdegebühr rechtfertigt. Denn sowohl die Vorgehensweise wie auch die Begründung der Prüfungsstelle in dem angefochtenen Beschluss sind mängelbehaftet.

So erweist sich der Zurückweisungsbeschluss der Prüfungsstelle schon deshalb als nicht sachgerecht, weil die von ihr angegebene Aufgabenstellung technische Lösungsansätze beinhaltet. Die Argumentation der Prüfungsstelle im Zurückweisungsbeschluss geht von einem äußerst eng formulierten Problem aus, das in der Bereitstellung des beanspruchten Algorithmus bzw. Verfahrens besteht. Dieses Verfahren beinhaltet jedoch durchaus Lösungsmerkmale, die auf technischen Überlegungen beruhen. So sieht es z. B. vor, Aktionen zusammen mit Auftragscodeblöcken zu erzeugen und zu verwenden, die asynchrone Funktionsaufrufe unterstützen, was sich wiederum auf die Performanz des Mess- und Testsystems vorteilhaft auswirkt, und beschreibt einen asynchronen Steuerungsmechanismus für ein solches System. Insoweit nimmt das von der Prüfungsstelle formulierte Problem bereits den Ablauf des beanspruchten technischen Verfahrens weitgehend vorweg, was wiederum der Einbeziehung von Lösungsgedanken gleichkommt. Da das technische Problem aber grundsätzlich von Elementen der Lösung freizuhalten ist, erweist sich die Argumentation der Prüfungsstelle als nicht sachgerecht.

Die Prüfungsstelle hat den Gegenstand des jeweiligen Patentanspruchs 1 gemäß (damaligem) Hauptantrag und (damaligem) Hilfsantrag 1 schließlich wegen fehlender erfinderischer Tätigkeit zurückgewiesen und gründet dieses Ergebnis auf ein behauptetes Grundwissen des Fachmannes, also ein allgemeines Fachwissen. Nach anerkannten Beurteilungsgrundsätzen wird das allgemeine Fachwissen aber erst dann herangezogen, wenn ein Stand der Technik ermittelt ist und es darauf ankommt, zu beurteilen, was diese Kenntnisse offenbaren und ob die beanspruchte Lehre gegenüber diesem Offenbarungsgehalt neu ist und auf erfinderischer Tätigkeit beruht (vgl. BGH, Beschluss vom 23. Januar 2007 – X ZB 3/06 Rn. 19; BPatGE 30, 250; BGH GRUR 2004, 1023 Rn. 33 – Bodenseitige Vereinzelungseinrichtung; Schulte, a.a.O. § 3 Rn. 11, § 34 Rn. 339). Insoweit leidet das Prüfungsverfahren an einem weiteren wesentlichen Mangel, da der Zurückweisungsbeschluss der Prüfungsstelle in Hinblick auf die Würdigung der beanspruchten Lehre jegliche konkrete Auseinandersetzung mit dem Offenbarungsgehalt von zum Stand der Technik ermittelten Druckschriften vermissen lässt.

Im Übrigen erschöpfen sich die Ausführungen der Prüfungsstelle zum Patentierungsverbot der beanspruchten Lehre des Patentanspruchs 1 gemäß (damaligem) Hauptantrag in der Feststellung, es handle sich bei der Lehre um die Ausführungsart einer Lösung einer nicht-technischen Problemstellung auf dem Gebiet der nicht-technischen Informationslogistik und damit um ein dem Patentschutz nicht zugängliches Programm für Datenverarbeitungsanlagen als solches. Darüber hinausgehende Ausführungen, die z. B. die Frage betreffen, welche Merkmale des Patentanspruchs 1 es denn konkret sein sollen, die der von der Prüfungsstelle beschriebenen nicht-technischen Informationslogistik zuzurechnen sind und aus welchem Grund, lässt die Prüfungsstelle im Zurückweisungsbeschluss vermissen.

In ihrer Summe rechtfertigen die aufgezeigten schwerwiegenden Fehler der Prüfungsstelle die Rückzahlung der Beschwerdegebühr (vgl. BPatG, Beschluss vom 9. September 2025 – 17 W (pat) 1/23, GRUR-RS 2025, 38862, GRUR 2026, 396-398 – Kontaktplanprogramm-Erzeugungsvorrichtung; BPatG, Beschluss vom 16. September 2025 – 17 W (pat) 20/23, GRUR-RS 2025, 38861, MittdtPatA 2026, 122 – Logistikverfahren – personenlose Auslieferung von Waren).

Rechtsmittelbelehrung

Gegen diesen Beschluss steht den am Beschwerdeverfahren Beteiligten das Rechtsmittel der Rechtsbeschwerde zu. Da der Senat die Rechtsbeschwerde nicht zugelassen hat, ist sie nur statthaft, wenn gerügt wird, dass 1. 2. 3. 4. das beschließende Gericht nicht vorschriftsmäßig besetzt war, bei dem Beschluss ein Richter mitgewirkt hat, der von der Ausübung des Richteramtes kraft Gesetzes ausgeschlossen oder wegen Besorgnis der Befangenheit mit Erfolg abgelehnt war, einem Beteiligten das rechtliche Gehör versagt war, ein Beteiligter im Verfahren nicht nach Vorschrift des Gesetzes vertreten war, sofern er nicht der Führung des Verfahrens ausdrücklich oder stillschweigend zugestimmt hat, 5. der Beschluss aufgrund einer mündlichen Verhandlung ergangen ist, bei der die Vorschriften über die Öffentlichkeit des Verfahrens verletzt worden sind, oder 6. der Beschluss nicht mit Gründen versehen ist.

Die Rechtsbeschwerde ist innerhalb eines Monats nach Zustellung des Beschlusses beim Bundesgerichtshof, Herrenstr. 45 a, 76133 Karlsruhe durch eine beim Bundesgerichtshof zugelassene Rechtsanwältin oder durch einen beim Bundesgerichtshof zugelassenen Rechtsanwalt einzulegen.

Dr. Forkel Akintche Dr. Städele Hofmeister