BPatG 154
05.11
BUNDESPATENTGERICHT
18 W (pat) 4/15
_______________
(Aktenzeichen)
Verkündet am
21. Juli 2017
…
B E S C H L U S S
In der Beschwerdesache
betreffend die Patentanmeldung 10 2011 101 920.4
…
hat der 18. Senat (Technischer Beschwerdesenat) des Bundespatentgerichts auf
die mündliche Verhandlung vom 21. Juli 2017 durch die Vorsitzende Richterin
Dipl.-Ing. Wickborn sowie den Richter Kruppa, die Richterin Dipl.-Phys. Dr. Otten-
Dünnweber und den Richter Dipl.-Ing. Altvater
- 2 -
beschlossen:
1. Die Beschwerde wird zurückgewiesen.
2. Die Rückzahlung der Beschwerdegebühr wird angeordnet.
G r ü n d e
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.
- 3 -
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. Novem-
ber 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.
- 4 -
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;
- 5 -
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.“
- 6 -
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 Anspruchs-
fassungen 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 Fahrzeugsoftwaresimu-
lationssysteme und -verfahren (vgl. Offenlegungsschrift DE 10 2011 101 920 A1,
Abs. [0003]). Fahrzeughardware und Fahrzeugcontroller könnten vor der Pro-
duktion in einer simulierten Umgebung getestet werden, um eine Komponenten-
und Systemgenauigkeit sicherzustellen. Es existierten Fahrzeugsimulations-
systeme 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 ver-
- 7 -
wendet, 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 Be-
schwerdebegrü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 Konfi-
gurationsmodul und ein Modellaktualisierungsmodul und deren jeweiligen Funk-
tionen ergänzt. Beim Anspruch 1 nach Hilfsantrag 2 ist u. a. das Modell-
erstellungsmodul 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
- 8 -
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 Offen-
legungsschrift). 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 Betriebs-
system 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).
- 9 -
Bei dem Fahrzeugsimulationssystem gemäß Hilfsantrag 1 ist für das Modell-
erstellungsmodul (vgl. Merkmal M5) angegeben, dass der Benutzer über eine
grafische Benutzerschnittstelle (GUI-Modul) die gewünschte Konfiguration einge-
ben kann, wozu ein Datenabrufmodul, ein Konfigurationsmodul und ein Modell-
aktualisierungsmodul 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 Kraft-
fahrzeugsteuersimulation 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 Be-
triebssystem des Computers, auf dem das Simulationsmodul läuft.
Gemäß Merkmal M12 soll ein Anlagenmodellauswahlmodul ein Genauigkeits-
niveau 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. Offenle-
gungsschrift, 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 Fahrzeug-
motorsteuerungssystemen in einer simulierten Umgebung des Fahrzeugs oder
anderer Fahrzeugkomponenten und damit ein Fahrzeugsimulationssystem gemäß
- 10 -
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 Simula-
tionsmodul (Soft ECUs) auf, das den Betrieb eines Fahrzeugs mit dem virtuellen
Modell (simulation model) simuliert (vgl. Abs. [0017], [0018], [0052], [0053] /
Merkmal M6).
- 11 -
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üh-
rende 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-Kom-
ponenten 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 Definitionsda-
teien zur Verfügung gestellt werden müssen. Sofern erforderlich wird der Fach-
mann 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 Fahrzeug-
simulationssystem mit den Merkmalen des Anspruchs 1 nach Hauptantrag
- 12 -
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 Benutzer-
schnittstelle, 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 Parametri-
sierungsprogramm stellt somit ein Datenabrufmodul wie in Merkmal M8 bean-
- 13 -
sprucht 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 Modellaktualisie-
rungsmodul 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 Hilfsan-
trag 1 darin, dass in Merkmal M11 klargestellt wird, dass das Modeller-
stellungsmodul (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.
- 14 -
[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 Anlagen-
modells und einen Grad, zu dem das Anlagenmodell tatsächliche Komponenten
oder Systeme der Anlage präzise simuliert (vgl. Abs. [0036] der Offenle-
gungsschrift). 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 Genauig-
keitsniveaus 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
- 15 -
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 An-
sprü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 Verfah-
rensfehlern 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
- 16 -
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:
- 17 -
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.
- 18 -
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ätig-
keit 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
- 19 -
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 La-
dungszusatz wird kein Bezug zu einer schneller ablaufenden Umgebung her-
gestellt. 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 Argumen-
tation, 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).
- 20 -
IV.
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. das beschließende Gericht nicht vorschriftsmäßig besetzt war,
2. 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,
3. einem Beteiligten das rechtliche Gehör versagt war,
4. 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
einen beim Bundesgerichtshof zugelassenen Rechtsanwalt als Bevollmächtigten
schriftlich einzulegen.
Wickborn Kruppa Otten-Dünnweber Altvater
Me
Full & Egal Universal Law Academy