BPatG 21.07.2017 - 18 W (pat) 4/15

I.

Die am 18. Mai 2011 beim Deutschen Patent- und Markenamt eingereichte Patentanmeldung 10 2011 101 920.4 mit der Bezeichnung

„Fahrzeugsystemmodellerstellungssysteme und -verfahren“,

die die US-amerikanischen Prioritäten vom 24. Mai 2010 (61/347,629) und vom 23. August 2010 (12/861,176) in Anspruch nimmt, wurde von der Prüfungsstelle für Klasse G 06 F des Deutschen Patent- und Markenamts mit Beschluss vom 24. November 2014 zurückgewiesen, weil die gemäß dem Protokoll zur Anhörung vom 26. August 2014 diskutierten Mängel nicht beseitigt worden seien. In dem Anhörungsprotokoll war ausgeführt worden, die Ansprüche gemäß Haupt- und Hilfsantrag ließen keine erfinderische Tätigkeit auf einem Gebiet der Technik erkennen; im Prüfungsverfahren waren die Druckschriften

T1: US 2010/0082303 A1 und

T2: WO 2010/004572 A2

genannt worden.

Gegen diesen Beschluss richtet sich die Beschwerde der Anmelderin.

Mit Anlage zur Ladung zur mündlichen Verhandlung vom 7. Juni 2017 hat der Senat u. a. auf die Druckschrift

F1: US 2006 / 0277010 A1

hingewiesen.

In der mündlichen Verhandlung begehrt die Anmelderin die Erteilung des Patents mit unveränderten Anspruchsfassungen nach Hauptantrag und nach Hilfsantrag 1 sowie einer geänderten Anspruchsfassung nach Hilfsantrag 2.

Die Anmelderin beantragt:

1. den Beschluss der Prüfungsstelle für Klasse G06F des Deutschen Patent- und Markenamts vom 24. November 2014 aufzuheben und das Patent auf der Grundlage der folgenden Unterlagen zu erteilen:

Patentansprüche 1 bis 10, eingegangen am 17. August 2011,

hilfsweise gemäß Hilfsantrag 1

Patentansprüche 1 bis 8, eingegangen am 26. August 2014,

hilfsweise gemäß Hilfsantrag 2

Patentansprüche 1 bis 7, eingereicht in der mündlichen Verhandlung,

Beschreibung Seiten 1 bis 32, eingegangen am 22. November 2013,

Figuren 1A, 1B, 2 bis 15, eingegangen am 17. August 2011,

2. die Rückzahlung der Beschwerdegebühr anzuordnen.

Der seitens des Senats mit einer Gliederung versehene Patentanspruch 1 nach Hauptantrag lautet:

M1 „Fahrzeugsimulationssystem, umfassend:

M2… ein Compiler-Modul,

M2.1 das Objektcode, der mit einem ersten Typ von Betriebssystem kompatibel ist,

 M2 auf der Grundlage von Sourcecode erzeugt,

M2.2 der durch ein Fahrzeugsteuermodul ausgeführt werden kann und der mit einem zweiten Typ von Betriebssystem kompatibel ist;

M3 ein Parser-Modul, das eine Definitionsdatei und eine Extensible Markup Language-Datei (XML-Datei) auf der Grundlage des Sourcecodes und des Objektcodes erzeugt;

M4 ein Wrapper-Modul, das eine Bibliotheksdatei auf der Grundlage des Objektcodes und der Definitionsdatei erzeugt;

M5 ein Modellerstellungsmodul, das einen modellbasierten Sourcecode für ein virtuelles Modell auf der Grundlage der XML-Datei und einer Benutzerkonfiguration des virtuellen Modells erzeugt; und

M6 ein Simulationsmodul, das den Betrieb einer Anlage eines Fahrzeugs mit dem virtuellen Modell simuliert.“

Wegen der abhängigen Ansprüche 2 bis 10 nach Hauptantrag wird auf die Akte verwiesen.

Der Patentanspruch 1 nach Hilfsantrag 1 entspricht dem Anspruch 1 nach Hauptantrag unter Anfügung der folgenden Merkmale:

M7 „wobei das Modellerstellungsmodul umfasst: ein Modul einer grafischen Benutzerschnittstelle (GUI-Modul), das ein konfigurierbares Modul in einer ersten GUI anzeigt und das eine zweite GUI anzeigt, wenn das konfigurierbare Modul ausgewählt ist;

M8 ein Datenabrufmodul, das Daten für das virtuelle Modell aus der XML-Datei abruft und das selektiv Menüs der zweiten GUI auf der Grundlage der abgerufenen Daten füllt,

M9 wobei das Modellerstellungsmodul ferner umfasst:

ein Konfigurationsmodul, das den modellbasierten Sourcecode auf der Grundlage der XML-Datei und des Benutzerkonfigurationseingangs über die zweite GUI erzeugt; und

M10 ein Modellaktualisierungsmodul, das das konfigurierbare Modul, das in der ersten GUI angezeigt wird, auf der Grundlage des Benutzerkonfigurationseingangs über die zweite GUI aktualisiert.“

Wegen der abhängigen Ansprüche 2 bis 8 nach Hilfsantrag 1 wird auf die Akte verwiesen.

Der Patentanspruch 1 nach Hilfsantrag 2 entspricht dem Anspruch 1 nach Hilfsantrag 1 unter Anfügung der nachfolgend aufgeführten Merkmale M11, M12 und M13:

M11 „wobei das Modellerstellungsmodul SIL-Modelle erzeugt, wobei das Modellerstellungsmodul ein Modell der Anlage erzeugt;

M12 wobei ein Anlagenmodellauswahlmodul ein Genauigkeitsniveau des Modells der Anlage auswählt, wobei sich das Genauigkeitsniveau darauf bezieht, wie präzise die Simulation des Modells der Anlage erfolgt;

M13 wobei sich das erste und das zweite Betriebssystem unterscheiden.“

Wegen den nach Hilfsantrag 2 geltenden abhängigen Ansprüchen 2 bis 7 wird auf die Akte verwiesen.

Die Beschwerdeführerin macht hierzu geltend, dass die geänderten Anspruchsfassungen zulässig seien, die Gegenstände der Ansprüche neu seien und auf einer erfinderischen Tätigkeit beruhen würden und dem Patentschutz zugänglich seien.

Wegen der weiteren Einzelheiten wird auf den Akteninhalt verwiesen.

II.

Die zulässige Beschwerde hat in der Sache keinen Erfolg. Denn die Gegenstände des jeweiligen Anspruchs 1 nach Hauptantrag sowie nach den Hilfsanträgen 1 und 2 beruhen nicht auf einer erfinderischen Tätigkeit (§ 4 PatG). Die Fragen der Zulässigkeit der geltenden Ansprüche nach Hauptantrag und nach den Hilfsanträgen 1 und 2 sowie der Neuheit der Anspruchsgegenstände können somit dahinstehen (vgl. BGH, Urteil vom 18. September 1990 - X ZR 29/89, GRUR 1991, 120, Abschnitt II. 1. - Elastische Bandage).

1. Die Anmeldung betrifft Fahrzeughardware- und Fahrzeugsoftwaresimulationssysteme und -verfahren (vgl. Offenlegungsschrift DE 10 2011 101 920 A1, Abs. [0003]). Fahrzeughardware und Fahrzeugcontroller könnten vor der Produktion in einer simulierten Umgebung getestet werden, um eine Komponenten- und Systemgenauigkeit sicherzustellen. Es existierten Fahrzeugsimulationssysteme für ein Hardware in the Loop-Testen (HIL-Testen), wobei eingebettete Software verwendet werde, die an einem Zielsteuermodul ausgeführt werde, das eine Schnittstelle mit physikalischen und mit simulierten Lasten bilde. Beim HIL-Testen würden Hardwareeinrichtungen wie etwa Fahrzeugsteuermodule verwendet, weswegen das Testen teuer sei und erst in einem späten Entwicklungsstadium möglich sei (vgl. Offenlegungsschrift, Abs. [0005], [0006]).

Eine Aufgabe ist in der Anmeldung nicht explizit angegeben. In der Beschwerdebegründung (vgl. S. 6, vorle. Abs.) ist als Aufgabe genannt, das Testen von Fahrzeugmodulen zu beschleunigen und zugleich Ressourcen, nämlich ein reales Steuermodul einzusparen.

Als Fachmann zur Lösung dieser Aufgabe sieht der Senat einen Ingenieur der Fachrichtung Fahrzeugtechnik oder Informationstechnik an, der bspw. bei einem Fahrzeughersteller mit der Entwicklung und Anwendung von softwarebasierten Simulationssystemen betraut ist.

Die Aufgabe soll durch ein Fahrzeugsimulationssystem gelöst werden, das gemäß Anspruch 1 nach Hauptantrag ein Compiler-Modul, ein Parser-Modul, ein Wrapper-Modul, ein Modellerstellungsmodul und ein Simulationsmodul und deren jeweiligen Funktionen umfasst. Beim Anspruch 1 nach Hilfsantrag 1 sind ein Modul einer grafischen Benutzerschnittstelle, ein Datenabrufmodul, ein Konfigurationsmodul und ein Modellaktualisierungsmodul und deren jeweiligen Funktionen ergänzt. Beim Anspruch 1 nach Hilfsantrag 2 ist u. a. das Modellerstellungsmodul näher spezifiziert und ein Anlagenmodellauswahlmodul und dessen Funktion ergänzt.

2. Einige der im jeweiligen Anspruch 1 nach Hauptantrag und nach den Hilfsanträgen 1 und 2 aufgeführten Merkmale bedürfen der Auslegung.

Anspruch 1 gemäß Hauptantrag ist auf ein Fahrzeugsimulationssystem gerichtet und soll gemäß Merkmal M6 ein Simulationsmodul umfassen, das den Betrieb einer Anlage - etwa eines Getriebes oder einer Maschine - eines Fahrzeugs mit einem virtuellen Modell simuliert (vgl. Offenlegungsschrift, Abs. [0033]). Bei diesem Simulationsmodul kann es sich um reine Software handeln, etwa eine Kraftfahrzeugsteuersystemsimulation, also um ein simuliertes Steuermodul (vgl. Abs. [0028] u. [0095] der Offenlegungsschrift). Als virtuelles Modell wird in der Anmeldung das Software in the Loop-Modul zusammen mit seinen Ein- und Ausgängen bezeichnet (vgl. Offenlegungsschrift, Abs. [0062]).

Das Fahrzeugsimulationssystem umfasst weitere Software-Module (vgl. auch Abs. [0009] der Offenlegungsschrift), welche als Eingangsgröße Sourcecode (vgl. Merkmal M2) und eine Benutzerkonfiguration eines virtuellen Modells (vgl. Merkmal M5) haben. Der Sourcecode kann automatisiert oder auch von Hand entworfen worden sein (vgl. Abs. [0043] der Offenlegungsschrift, le. Satz); bei der Benutzerkonfiguration handelt es sich um Eingabewerte, die der Benutzer über eine grafische Benutzerschnittstelle (GUI) eingibt (vgl. Abs. [0098] der Offenlegungsschrift). Abgesehen von dem Simulationsmodul (vgl. Merkmal M6) wird im Anspruch ein Bezug zu einem Fahrzeugsteuermodul und damit zu technischen Gegebenheiten dadurch hergestellt, dass der von einem Compilermodul auf der Grundlage des eingehenden Sourcecodes zu erzeugende Objektcode durch ein Fahrzeugsteuermodul ausgeführt werden können soll (vgl. Merkmale M2 bis M2.2). Der Objektcode ist dabei mit einem ersten und mit einem - gemäß Hauptantrag nicht notwendigerweise davon verschiedenen - zweiten Betriebssystem kompatibel (vgl. Merkmale M2.1, M2.2). Merkmal M3 legt fest, dass ein Parser-Modul auf der Grundlage des Sourcecodes und des Objektcodes zwei verschiedene Dateien (Definitionsdatei und XML-Datei) erzeugt; dabei beinhaltet bereits die Verarbeitung von Objektcode, welcher auf der Grundlage von Sourcecode erzeugt wurde, dass die Dateien „auf der Grundlage“ des Sourcecodes erzeugt werden. Unter dem in Merkmal M4 benannten Wrapper-Modul ist eine Software-Schnittstelle zu verstehen, die auf Basis des Objektcodes und der Definitionsdatei eine Bibliotheksdatei erzeugt. Ein Modellerstellungs-Modul erzeugt für das virtuelle Modell einen modellbasierten Sourcecode, wobei als Eingangsdaten die XML-Datei und eine Benutzerkonfiguration eingehen (vgl. Merkmal M5).

Bei dem Fahrzeugsimulationssystem gemäß Hilfsantrag 1 ist für das Modellerstellungsmodul (vgl. Merkmal M5) angegeben, dass der Benutzer über eine grafische Benutzerschnittstelle (GUI-Modul) die gewünschte Konfiguration eingeben kann, wozu ein Datenabrufmodul, ein Konfigurationsmodul und ein Modellaktualisierungsmodul mit der XML-Datei interagieren (vgl. Merkmale M7 bis M10; Offenlegungsschrift, Abs. [0048] - [0050]).

In Anspruch 1 nach Hilfsantrag 2 ist präzisiert, dass das Modellerstellungsmodul als virtuelle Modelle der Anlage des Fahrzeugs (vgl. Merkmale M5 und M6) SIL-Modelle, also Software in the Loop-Modelle erzeugt, dass also bei der Kraftfahrzeugsteuersimulation das Verhalten des Steueralgorithmus durch Ausführen der Software in einer virtuellen Simulationsumgebung erhalten wird, so dass keine mit der Anlage in Verbindung stehende Hardware erforderlich ist (vgl. Abs. [0027] der Offenlegungsschrift). Merkmal M13 stellt dabei klar, dass sich das erste und das zweite Betriebssystem unterscheiden; darunter fällt etwa die Ausgestaltung, dass der von dem Compiler erzeugte Objektcode mit dem Betriebssystem des zu simulierenden Fahrzeugsteuermoduls kompatibel ist, wie auch mit dem Betriebssystem des Computers, auf dem das Simulationsmodul läuft.

Gemäß Merkmal M12 soll ein Anlagenmodellauswahlmodul ein Genauigkeitsniveau des Modells der Anlage auswählen; dabei soll sich das Genauigkeitsniveau darauf beziehen, wie präzise die Simulation des Modells der Anlage erfolgt. Dies betrifft etwa die Komplexität des Modells, beispielsweise die Anzahl der bei der Simulation zu berücksichtigenden Komponenten der Anlage (vgl. Offenlegungsschrift, Abs. [0036]).

3. Das Verfahren des Patentanspruchs 1 gemäß Hauptantrag beruht für den Fachmann in Kenntnis von Druckschrift F1 nicht auf einer erfinderischen Tätigkeit.

Druckschrift F1 offenbart eine Testumgebung zur Simulation von Fahrzeugmotorsteuerungssystemen in einer simulierten Umgebung des Fahrzeugs oder anderer Fahrzeugkomponenten und damit ein Fahrzeugsimulationssystem gemäß Merkmal M1 (vgl. Abs. [0002] i. V. m. Abs. [0013] u. [0032]). Beschrieben wird, dass das simulierte Modell, das dem virtuellen Modell der vorliegenden Anmeldung entspricht, in C-Code transferiert wird, dann kompiliert wird und auf einer Simulations-Hardware implementiert werden kann (vgl. Abs. [0014]). Damit ist ein Compiler-Modul offenbart, welches auf der Grundlage von Sourcecode (C-code) Objektcode erzeugt, welcher jedenfalls mit dem Betriebssystem des Simulationssystems kompatibel ist (Merkmale M2, M2.1); der Objektcode wird letztlich auf einer Fahrzeugsteuereinheit (control unit) mit ihrem Betriebssystem ausgeführt (vgl. Abs. [0009] i. V. m. Abs. [0002] u. [0051]; Anspruch 8 / Merkmal M2.2) Die offenbarten Entwicklungswerkzeuge, mit denen eine Parametrisierung der virtuellen Modelle erfolgt, verwenden XML-Dateien und ermöglichen die Eingabe von Benutzerkonfigurationen und erzeugen daraus wiederum einen modellbasierten Sourcecode; sie stellen somit ein Modellerstellungsmodul gemäß Merkmal M5 dar (vgl. Abs. [0014], [0015] u. [0034]). Die automatische Generierung einer deskriptiven Datei, bei der es sich auch um eine XML-Datei handeln kann, anhand des virtuellen Modells ist als ein Parsen anzusehen (vgl. Abs. [0062], [0063], [0034], [0066]); dafür wird das virtuelle Modell analysiert (vgl. Abs. [0062], [0066]), was somit zumindest mittelbar auf der Grundlage von Source- und Objektcode erfolgt (Merkmal M3). Druckschrift F1 offenbart nicht explizit ein Wrapper-Modul; es wird aber beschrieben, dass bestimmte Software-Schnittstellen zur Verfügung gestellt werden müssen, womit ein Hinweis auf Bibliotheksdateien gegeben ist (vgl. Abs. [0014] / teilweise Merkmal M4). Als eine Variante offenbart Druckschrift F1, dass auch das Fahrzeugsteuermodul simuliert wird und das simulierte Modell zur Ausführung auf einen Prozessor verlagert wird (vgl. Abs. [0052], [0053] u. [0012]: … can be tested with the aid of a simulated environment); das Fahrzeugsimulationssystem weist somit auch ein Simulationsmodul (Soft ECUs) auf, das den Betrieb eines Fahrzeugs mit dem virtuellen Modell (simulation model) simuliert (vgl. Abs. [0017], [0018], [0052], [0053] / Merkmal M6).

Der Argumentation der Anmelderin, Druckschrift F1 offenbare allein Hardware in the Loop-Verfahren, bei denen die erstellten Simulationsmodelle auf einer Simulations-Hardware ausgeführt werden, kann nicht beigetreten werden. Denn die Druckschrift beschreibt neben den HIL-Verfahren (vgl. Abs. [0011]) als eine Variante auch sogenannte Off-Line Simulationen, bei denen das virtuelle Modell zur Ausführung auf eine simulierte Steuereinheit übertragen wird, so dass auf aufwendige Simulationshardware verzichtet werden kann (vgl. Abs. [0052], [0053]: Off-line simulations, Soft ECUs). Dies stellt ein Testen der Software mit einem Software in the Loop-Verfahren dar. Der Fachmann entnimmt Druckschrift F1 somit unmittelbar, dass sowohl das Hardware in the Loop-Verfahren wie auch die ein Software in the Loop-Verfahren darstellenden Off-line Simulationen zur Ausführung kommen können, um die auf einem Fahrzeugsteuermodul auszuführende Software zu testen (vgl. Abstract, Abs. [0002] u. [0011]).

Druckschrift F1 offenbart dem Fachmann somit bis auf Merkmal M4 sämtliche Merkmale des Anspruchs 1 nach Hauptantrag. Mit dem in Merkmal M4 beanspruchten Wrapper-Modul wird ein Zusammenstellen der für den jeweiligen Objektcode und dessen Definitionen benötigten Bibliotheksroutinen sichergestellt. Druckschrift F1 gibt hierzu den Hinweis, dass neben der Kompilierung das Erstellen von Schnittstellen erforderlich ist (vgl. Abs. [0014]) und dass für das jeweilige virtuelle Modell zur Laufzeit die passende Sammlung der Modell-Komponenten zusammenzustellen ist (vgl. Fig. 5 u. Abs. [0036]). Für den Fachmann ist dabei klar, dass in Abhängigkeit von der in der Simulationsumgebung und für das Fahrzeugsteuermodul verwendeten Betriebssystem-Software und den vom Objektcode benötigten Bibliotheksroutinen Bibliotheksdateien und Definitionsdateien zur Verfügung gestellt werden müssen. Sofern erforderlich wird der Fachmann daher - sofern benötigt - solche Dateien, und somit eine Art Wrapper-Modul im Sinne von Merkmal M4 vorsehen.

Somit ist dem Fachmann in Kenntnis von Druckschrift F1 ein Fahrzeugsimulationssystem mit den Merkmalen des Anspruchs 1 nach Hauptantrag nahegelegt, so dass der Gegenstand des Anspruchs 1 nicht auf einer erfinderischen Tätigkeit beruht.

Der Patentanspruch 1 nach Hauptantrag ist somit nicht patentfähig.

4. Die in den Anspruch 1 nach Hilfsantrag 1 zusätzlich aufgenommenen Merkmale können eine erfinderische Tätigkeit ebenfalls nicht begründen.

Anspruch 1 nach Hilfsantrag 1 unterscheidet sich von Anspruch 1 nach Hauptantrag darin, dass das Modellerstellungsmodul (vgl. Merkmal M5) ein Modul einer grafischen Benutzerschnittstelle (GUI-Modul), ein Datenabrufmodul, ein Konfigurationsmodul und ein Modellaktualisierungsmodul umfassen soll (vgl. Merkmale M7 bis M10), wobei u. a. in einer ersten GUI die Anzeige eines konfigurierbaren Moduls erfolgt und eine zweite GUI mit Menüs auf Basis der XML-Datei befüllt wird und dem Benutzer die Eingabe einer Konfiguration erlaubt.

Ob es sich bei den in den Merkmalen M7 bis M10 aufgeführten Angaben zur Befüllung von Menüs der GUI mit Daten und zur Aktualisierung der angezeigten Module um technische Mittel zur Lösung eines technischen Problems handelt, kann dahingestellt bleiben, da diese Merkmale für den Fachmann sämtlich ebenfalls aus Druckschrift F1 entnehmbar sind.

Denn Druckschrift F1 zeigt in Figur 4 ein Modul einer grafischen Benutzerschnittstelle, das mehrere konfigurierbare Module in einer GUI (representative GUI) anzeigt und das weitere GUI anzeigt, wenn bestimmte konfigurierbare Module (particular model implementation) ausgewählt sind (vgl. Abs. [0035], [0039] / Merkmal M7). Dabei analysiert ein Parametrisierungsprogramm, welches ein Modellerstellungsmodul im Sinne der Anmeldung darstellt, das virtuelle Modell und befüllt die GUI nur mit den benötigten Komponenten, welche aus der XML-Datei entnommen werden (vgl. Abs. [0071] u. [0067]), dieses Parametrisierungsprogramm stellt somit ein Datenabrufmodul wie in Merkmal M8 beansprucht dar. Für den Fachmann ist dabei klar, dass der modellbasierte Sourcecode auf Grundlage des Benutzerkonfigurationseingangs, welcher über die (zweite) GUI letztlich auf Grundlage der XML-Datei erfolgt, erzeugt wird (vgl. Abs. [0015] i. V. m. Abs. [0044] u. [0058] u. Fig. 4 / Merkmal M9). Die in den GUIs gezeigten Module werden ständig aktualisiert und miteinander abgeglichen; diese Verwaltung der virtuellen Modelle (administration of simulation models) mit einer dynamischen Anpassung (dynamic user interface) stellt ein Modellaktualisierungsmodul gemäß Merkmal M10 dar (vgl. Abs. [0045], [0046], [0061] u. [0072]).

Somit ist dem Fachmann auch der Gegenstand des Anspruchs 1 nach Hilfsantrag 1 in Kenntnis von Druckschrift F1 nahegelegt.

Der Anspruch 1 nach Hilfsantrag 1 ist damit ebenfalls nicht patentfähig.

5. Auch die Präzisierung gemäß Anspruch 1 nach Hilfsantrag 2 kann eine erfinderische Tätigkeit nicht begründen.

Anspruch 1 nach Hilfsantrag 2 unterscheidet sich von Anspruch 1 nach Hilfsantrag 1 darin, dass in Merkmal M11 klargestellt wird, dass das Modellerstellungsmodul (vgl. Merkmal M5) SIL-Modelle, also Software in the Loop-Modelle erzeugt, wobei es sich bei dem Modell um ein Modell der Anlage eines Fahrzeugs (vgl. Merkmal M6) handelt. Präzisiert ist auch, dass sich die in den Merkmalen M2.1 und M2.2 aufgeführten Betriebssysteme voneinander unterscheiden (vgl. Merkmal M13). Zusätzlich soll mit einem Anlagenmodellauswahlmodul ein Genauigkeitsniveau des Modells der Anlage ausgewählt werden können, welches sich darauf bezieht, wie präzise die Simulation erfolgt (vgl. Merkmal M12).

Wie in Abschnitt II. 3. zum Hauptantrag ausgeführt, ist aus Druckschrift F1 ein Modellerstellungsmodul bekannt, das Software in the Loop-Modelle erzeugt (vgl. Abs. [0052], [0053]: Off-line simulations, Soft ECUs). Dabei werden auch Modelle der Anlage erzeugt, welche zum Testen herangezogen werden können (vgl. Abs. [0012] u. [0013] i. V. m. Abs. [0053], fünfter Satz: … there are model parts in the simulation model which can be tested off-line on the PC development processor …/ Merkmal M11).

Das in Merkmal M12 benannte Genauigkeitsniveau soll sich darauf beziehen, wie präzise die Simulation des Modells der Anlage erfolgt. Die Anmeldung gibt dazu an, das Genauigkeitsniveau beziehe sich auf die Komplexität eines Anlagenmodells und einen Grad, zu dem das Anlagenmodell tatsächliche Komponenten oder Systeme der Anlage präzise simuliert (vgl. Abs. [0036] der Offenlegungsschrift). Eine solche Auswahl von einzelnen Komponenten der Simulation ist auch in Druckschrift F1 beschrieben, wobei insbesondere nicht benötigte Komponenten des Simulationsmodells gelöscht werden können (vgl. Abs. [0041] u. [0042]) oder Modellkomponenten wieder hinzugefügt werden können (vgl. Abs. [0047]). Damit ist ein Anlagenmodellauswahlmodul beschrieben, welches je nach der Anzahl der ausgewählten Modellkomponenten zu einer unterschiedlichen Präzision der Simulation des Modells und damit zu unterschiedlichen Genauigkeitsniveaus gemäß Merkmal M12 führt.

Merkmal M13 legt lediglich fest, dass der Objektcode mit zwei verschiedenen Betriebssystemen kompatibel ist. Bei dem aus Druckschrift F1 bekannten Fahrzeugsimulationssystem wird der durch die Kompilierung erzeugte Objektcode (vgl. Abs. [0014]) in der Variante des Software in the Loop-Verfahrens zum Testen auf einem PC Entwicklungs-Prozessor ausgeführt, welcher mit einem üblichen PC Betriebssystem laufen wird, der Objektcode ist damit mit einem ersten Betriebssystem kompatibel. Da der getestete Objektcode letztlich auf einem realen Fahrzeugsteuermodul mit eigenem Betriebssystem ausgeführt werden soll (vgl. Abs. [0009]), wobei üblicherweise ein anderes Betriebssystem als in einem zur Simulation vorgesehenen herkömmlichen PC genutzt wird, liest der Fachmann bei dem aus Druckschrift F1 bekannten Fahrzeugsimulationssystem mit, dass der letztlich erzeugte Objektcode auch mit dem Betriebssystem der Anlage des Fahrzeugs kompatibel sein muss und damit mit einem weiteren, zweiten Betriebssystem, das sich von dem ersten Betriebssystem unterscheidet (Merkmal M13).

Dem Fachmann ist daher in Kenntnis von Druckschrift F1 auch der Gegenstand des Anspruchs 1 nach Hilfsantrag 2 nahegelegt.

Der Anspruch 1 nach Hilfsantrag 2 ist somit ebenfalls nicht patentfähig.

6. Mit dem nicht patentfähigen Anspruch 1 nach Hauptantrag und nach den Hilfsanträgen 1 und 2 sind auch die auf diese Ansprüche direkt oder indirekt rückbezogenen jeweiligen Unteransprüche nicht schutzfähig, da auf diese Ansprüche kein eigenständiges Patentbegehren gerichtet war (vgl. BGH, Beschluss vom 27. Juni 2007 - X ZB 6/05, GRUR 2007, 862, Abschnitt III. 3. a) aa) – Informationsübermittlungsverfahren II).

7. Nachdem die jeweiligen Anspruchssätze nach Hauptantrag und nach den Hilfsanträgen 1 und 2 nicht schutzfähig sind, war die Beschwerde zurückzuweisen.

III.

Die Rückzahlung der Beschwerdegebühr war nach § 80 Abs. 3 PatG anzuordnen.

Nach dieser Vorschrift kann die Rückzahlung der Beschwerdegebühr angeordnet werden, wenn dies der Billigkeit entspricht. Dies kommt insbesondere bei Verfahrensfehlern oder unsachgemäßer Sachbehandlung in Betracht (vgl. Schulte/Püschel, PatG, 10. Aufl., § 80 Rdn 113 f. und § 73 Rdn 134 ff.; Busse/Keukenschrijver - Engels, PatG, 8. Aufl., § 80 Rdn 85 ff. u. Rdn. 92 ff.).

Im angefochtenen Beschluss liegen Verfahrensfehler vor (Schulte/Püschel, a. a. O., § 73 Rdn 146, 148). Die von der Prüfungsstelle herangezogene Begründung im Anhörungsprotokoll vom 26. August 2014 weist Mängel auf, da sie nicht nachvollziehbar und unvollständig ist.

Die Anmelderin beantragt die Rückzahlung der Beschwerdegebühr mit der Begründung, die Prüfungsstelle hätte rechtsfehlerhaft eine Auslegung der Patentansprüche zugrunde gelegt, die nicht auf einem sinnvollen technischen Verständnis beruhe. In einer zweiten Auslegungsvariante sei die Prüfungsstelle von einem sinnvollen technischen Verständnis ausgegangen, eine detaillierte Analyse und Würdigung der einzelnen Merkmale sei jedoch nicht erfolgt. Eine Prüfung der tatsächlich beanspruchten Gegenstände habe folglich nicht stattgefunden.

In einem ersten Prüfungsbescheid wurde von der Prüfungsstelle die Druckschrift T1 pauschal genannt und der Anmelder - ohne inhaltlich auf den Anspruch oder die Druckschrift einzugehen - aufgefordert, „gemäß seiner Mitwirkungspflicht“ einen technischen Effekt im Anspruch 1 aufzuzeigen und sich dabei gegenüber der Druckschrift T1 abzugrenzen. Nachdem die Anmelderin ausführlich zur Technizität und erfinderischen Tätigkeit gegenüber Druckschrift T1 Stellung genommen hat und die Patentansprüche unverändert aufrechterhielt, fand am 26. August 2014 eine Anhörung statt; zuvor war in einem kurzen Zusatz zur Ladung sinngemäß ausgeführt worden, der Gegenstand des Anspruchs 1 beruhe gegenüber Druckschrift T2 nicht auf einer erfinderischen Tätigkeit, wiederum ohne Merkmalsvergleich mit den beanspruchten Merkmalen. In der Anhörung hat die Anmelderin eine Erteilung mit den ursprünglichen Ansprüchen als Hauptantrag und mit veränderten Ansprüchen gemäß Hilfsantrag beantragt. Im Protokoll der Anhörung wird zur Auslegung ausgeführt:

Abbildung in Originalgröße in neuem Fenster öffnen

Abbildung in Originalgröße in neuem Fenster öffnen

Die Prüfungsstelle fährt damit fort, dass aus T1 eine Modellerstellung und Konfiguration seiner Eingangsparameter über ein GUI bekannt sei. Weiter macht die Prüfungsstelle Ausführungen dazu, was für den Fachmann selbstverständlich wäre oder beliebig sei. Die Ansprüche 1 bis 10 gemäß Hauptantrag ließen „so verstanden“ keine erfinderische Tätigkeit auf einem Gebiet der Technik erkennen. Gestalterische Überlegungen zur Ausgestaltung eines GUIs, soweit sie in den Patentansprüchen anklängen, lägen nicht auf einem Gebiet der Technik.

Zum Hilfsantrag 1 wird lediglich aufgeführt, dass dieser die Merkmale der Ansprüche 1 bis 3 nach Hauptantrag umfassen würde, die bei der Interpretation des Anspruchs 1 nach Hauptantrag bereits eingeflossen seien.

Mit Schreiben vom 18. November 2014 bat die Anmelderin um den Erlass eines beschwerdefähigen Beschlusses. Darauf erfolgte am 24. November 2014 die Zurückweisung, da die im Anhörungsprotokoll diskutierten Mängel nicht beseitigt worden seien.

Die Ausführungen im Anhörungsprotokoll sind widersprüchlich und unvollständig. Die Prüfungsstelle behauptet zunächst, „ein Patentanspruch sei mit Hilfe der Beschreibung nicht so auszulegen, dass er sinnvoll wird“ und „dies bedeutet auch nicht, dass der beanspruchte Gegenstand ausführbar sein muss“, um dann festzustellen, der Anspruch 1 nach Hauptantrag lasse als technische Lösung eines technischen Problems die Kompilierung eines Quellcodemoduls erkennen, welche sich für den Fachmann in naheliegender Weise ergebe.

In einer zweiten Interpretation, die die Prüfungsstelle „entgegen obiger Maßgabe“ offenbar so vorgenommen haben will, dass ein sinnvoller technischer Gegenstand umschrieben wird, werden zwei verschiedene Quellcodes gefordert. Die weitere Argumentation - ohne Angabe jeglicher Zitatstellen - dürfte so zu verstehen sein, dass aus Druckschrift T1 einzelne der aufgeführten Merkmale bekannt seien, weitere Merkmale für den Fachmann selbstverständlich seien. Daran schließt sich im Anhörungsprotokoll der eigentliche Zurückweisungsgrund an, dass die Ansprüche 1 nach Hauptantrag und nach Hilfsantrag 1 keine erfinderische Tätigkeit auf einem Gebiet der Technik erkennen lassen würden, offensichtlich unter Nichtberücksichtigung nichttechnischer Merkmale.

Eine solch verworrene Argumentation kann nicht als die in § 45 PatG geforderte Angabe der Anmeldungsmängel angesehen werden, auf die ein Anmelder reagieren könnte. Schon die beiden aufgeführten Auslegungsvarianten lassen den Anmelder im Unklaren, in welcher Weise die Prüfungsstelle einen gegebenenfalls neu eingereichten Anspruch auslegen würde. Zudem werden beide von der Prüfungsstelle vorgenommenen Auslegungen dem Gegenstand des Anspruchs 1 gemäß Hauptantrag nicht gerecht. Insbesondere hat die Prüfungsstelle, die angibt, den Blick auf die technische Funktion des beanspruchten Gegenstands gerichtet zu haben, ein Großteil der Merkmale des Anspruchs 1 nach Hauptantrag nicht gewürdigt. So ist im gesamten Anhörungsprotokoll weder das beanspruchte Fahrzeugsimulationssystem (vgl. Merkmal M1), noch das Fahrzeugsteuermodul, das letztlich den Objektcode ausführen soll (vgl. Merkmal M2.2), oder das Simulationsmodul, das den Betrieb einer Anlage eines Fahrzeugs simulieren soll (vgl. Merkmal M6), erwähnt.

Die einzelnen Merkmale des Anspruchs 1 nach Hauptantrag werden, wie die Anmelderin korrekt rügt, nicht gewürdigt und keiner Prüfung gegenüber dem Stand der Technik unterzogen. Ein konkreter Merkmalsvergleich mit Druckschrift T1, welche wohl die Druckschrift sein soll, gegenüber der der Gegenstand des Anspruchs nicht auf einer erfinderischen Tätigkeit beruht, hat im gesamten Prüfungsverfahren nicht stattgefunden. Ferner sind im Protokoll keine Zitatstellen genannt und auch bei der erstmaligen Nennung der Druckschrift T2 im Ladungszusatz wird kein Bezug zu einer schneller ablaufenden Umgebung hergestellt. Daher ist bei der Nennung von Druckschrift T2 auf Seite 2 des Anhörungsprotokolls nicht nachvollziehbar, ob es sich möglicherweise um einen Tippfehler handelt und Druckschrift T1 gemeint sein sollte, oder doch Druckschrift T2 inhaltlich gemeint ist. Die von der Prüfungsstelle vorgenommene Argumentation, welche einen Großteil der technischen Merkmale des Anspruchs 1 nach Hauptantrag nicht berücksichtigt, ist insgesamt als nicht nachvollziehbar und unvollständig zu bezeichnen.

Zum Patentanspruch 1 nach Hilfsantrag 1 findet sich ebenfalls keine Begründung mit einem konkreten Merkmalsvergleich.

Der Senat sieht diese nicht nachvollziehbare und unvollständige Begründung und die neben der Sache liegende Auslegung des Patentanspruchs als eine mangelhafte Begründung und mängelbehaftete Sachbehandlung der Anmeldung durch die Prüfungsstelle an, so dass eine Einbehaltung der Beschwerdegebühr unbillig erschiene (Schulte/Püschel, a. a. O., § 73 Rdn 140, 146, 148 und Busse/Keukenschrijver - Engels, a. a. O., § 80 Rdn 97, 129).