Rechtsprechung / BPatG / 2026
BPatG Beschluss vom 06.05.2026 – 17 W (pat) 10/23
17. Senat · ECLI:DE:BPatG:2026:060526B17
BUNDESPATENTGERICHT
17 W (pat) 10/23 _______________________
(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:
-
-
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; und
M9
Erledigung Abschließen (90) der Aufgabe
M10
und informieren des Systems hierüber.
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