Rechtsprechung / BPatG / 2025
BPatG Beschluss vom 17.06.2025 – 17 W (pat) 9/23
17. Senat · ECLI:DE:BPatG:2025:170625B17Wpat9.23.0
BUNDESPATENTGERICHT
17 W (pat) 9/23 _______________________
(Aktenzeichen)
…
BESCHLUSS§
In der Beschwerdesache
betreffend die Patentanmeldung 10 2019 217 058.7
hat der 17. Senat (Technischer Beschwerdesenat) des Bundespatentgerichts auf
die mündliche Verhandlung vom 17. Juni 2025 unter Mitwirkung des Richters Dipl.-
Phys. Dr. Forkel als Vorsitzender, der Richterin Akintche, des Richters Dipl.-Phys.
Dr. Städele und des Richters Dr.-Ing. Harth
beschlossen:
Die Beschwerde wird zurückgewiesen.
ECLI:DE:BPatG:2025:170625B17Wpat9.23.0
Gründe§
I.
Die vorliegende Patentanmeldung ist am 6. November 2019 beim Deutschen
Patent- und Markenamt eingereicht worden. Sie trägt die Bezeichnung
„Verfahren und Vorrichtung zum Bereitstellen einer Anwendungssoftware“.
Die Anmeldung wurde durch Beschluss der Prüfungsstelle für Klasse G06F des
Deutschen Patent- und Markenamts vom 27. Januar 2023 zurückgewiesen. Zur
Begründung hat die Prüfungsstelle sinngemäß ausgeführt, dass die Lehre des
Patentanspruchs 1 aufgrund des Patentierungsausschlusses für Datenverarbeitungsprogramme nach § 1 Abs. 3 i. V. m. Abs. 4 PatG weder in der Fassung
nach dem (damaligen) Hauptantrag noch in der Fassung nach dem (damaligen)
Hilfsantrag 1 dem Patentschutz zugänglich sei.
Gegen diesen Beschluss richtet sich die vorliegende Beschwerde.
Die Anmelderin stellt den Antrag,
- den Beschluss der Prüfungsstelle für Klasse G06F vom 27. Januar 2023
aufzuheben und ein Patent auf Grundlage folgender Unterlagen zu erteilen
(„Hauptantrag“):
- Patentansprüche 1 bis 10, überreicht in der mündlichen Verhandlung,
- Beschreibung Seiten 1 bis 7, eingegangen am 6. November 2019
(Anmeldetag) sowie
- 3 Blatt Zeichnungen mit Figuren 1 bis 3, eingegangen am
6. November 2019;
- hilfsweise auf der Grundlage folgender Unterlagen gemäß Hilfsantrag 1:
- Patentansprüche 1 bis 7, überreicht in der mündlichen Verhandlung,
- Beschreibung und Zeichnungen wie Hauptantrag.
Ferner regt die Anmelderin die Zulassung der Rechtsbeschwerde an.
Der geltende Patentanspruch 1 nach Hauptantrag lautet - mit einer möglichen
Merkmalsgliederung versehen:
Verfahren (1-10) zum Bereitstellen einer Anwendungssoftware (16) für
eine Landmaschine,
gekennzeichnet durch folgende Merkmale:
1.2
eine Beschreibung (21) der Anwendungssoftware (16) wird angefertigt
(1),
1.3
anhand der Beschreibung (21) wird ein Programmgerüst (15) erzeugt
(2),
1.4
die Anwendungssoftware (16) wird
1.4.1 mittels Wrappern (14)
mit dem Programmgerüst (15) zu einer Programmdatei zusammengefügt (3) und
1.5
anhand der Beschreibung (21) wird ein Manifest komplettiert,
1.5.1
wobei das Manifest
1.5.1a eine Containertechnologie,
1.5.1b Plattformstruktur und Laufzeitverhalten,
1.5.1c Einschränkung oder Zuweisung von Ressourcen, CPU, RAM
und I/O
beschreibt und
1.5.2
das Manifest gemeinsam mit der Programmdatei derart zu einer
Archivdatei (22) paketiert (4),
1.5.3 dass unter einem vorgegebenen Betriebssystem (17) ein für die
Anwendungssoftware (16) spezifischer Container (13) aus der
Archivdatei (22) extrahiert werden kann.
Der geltende Patentanspruch 1 nach Hilfsantrag 1
lautet
(mit einer
Merkmalsgliederung, die an diejenige des Patentanspruchs 1 nach Hauptantrag
angelehnt ist):
Verfahren (1-10) zum Bereitstellen einer Anwendungssoftware (16) für
eine Landmaschine,
1.1.1 wobei die Anwendungssoftware zur Aktualisierung eines Steuergerätes der Landmaschine eingerichtet ist,
1.1.2 wobei die Aktualisierung eine Wartung, eine Fehlerbereinigung
und/oder eine Erweiterung des Funktionsumfangs der Anwendungssoftware umfasst,
1.1.3 wobei die Erweiterung des Funktionsumfangs ein Bereitstellen
mindestens einer der Funktionen erweiterte Telemetrie und/oder
eine agrartechnische Spezialfunktion zur Unkrautbekämpfung
umfasst,
das Verfahren gekennzeichnet durch folgende Merkmale:
1.2
eine Beschreibung (21) der Anwendungssoftware (16) wird angefertigt
(1),
1.3
anhand der Beschreibung (21) wird ein Programmgerüst (15) erzeugt
(2),
1.4
die Anwendungssoftware (16) wird
1.4.1 mittels Wrappern (14)
mit dem Programmgerüst (15) zu einer Programmdatei zusammengefügt (3) und
1.5
anhand der Beschreibung (21) wird ein Manifest komplettiert,
1.5.1
wobei das Manifest
1.5.1a eine Containertechnologie,
1.5.1b Plattformstruktur und Laufzeitverhalten,
1.5.1c Einschränkung oder Zuweisung von Ressourcen, CPU, RAM
und I/O
beschreibt und
1.5.2 das Manifest gemeinsam mit der Programmdatei derart zu einer
Archivdatei (22) paketiert (4),
1.5.3 dass unter einem vorgegebenen Betriebssystem (17) ein für die
Anwendungssoftware (16) spezifischer Container (13) aus der
Archivdatei (22) extrahiert werden kann und
1.6
die Archivdatei (22) wird nach dem Paketieren in der Cloud (20)
abgelegt (5) und
1.7
die Archivdatei (22) wird aus der Cloud (20) auf ein Zielsystem (18)
heruntergeladen (6) und,
1.8
anhand des Manifests wird eine
Installation des spezifischen
Containers (13) geplant (7) und
1.9
auf dem Zielsystem (18) wird die Installation vorgenommen (8) und
1.10
die Programmdatei wird im spezifischen Container (13) auf dem
Zielsystem (18) ausgeführt (9).
Zu den jeweiligen neben- und untergeordneten Patentansprüchen des Haupt- und
des Hilfsantrags 1 wird auf die Akte verwiesen.
Im Beschwerdeverfahren wurde folgender Stand der Technik berücksichtigt:
D1 US 2019 / 0 050 680 A1;
D2 US 2017 / 0 147 319 A1;
D3 US 2017 / 0 331 823 A1;
D4 Online-Blogbeitrag „Quick hack: extracting the contents of a Docker image to
disk“ vom Michael Still, mit Angabe „Posted on July 29, 2019“;
D5
Aidanpää, S. [et al.]: Flexible Updates of Embedded Systems Using
Containers. Degree Project in Mechanical Engineering, KTH Royal Institute
of Technology, School of
Industrial Engineering and Management,
Stockholm, Sweden, 2016.
Zu den weiteren Einzelheiten wird auf die Akte verwiesen.
II.
Die Beschwerde wurde rechtzeitig eingelegt und ist auch sonst zulässig. Sie führt
jedoch nicht zum Erfolg, weil der Gegenstand des geltenden Patentanspruchs 1 in
den Fassungen nach Haupt- und Hilfsantrag 1 jeweils nicht auf erfinderischer
Tätigkeit beruht (§ 4 PatG).
1.
Die vorliegende Patentanmeldung bezieht sich auf ein Verfahren zum
Bereitstellen
einer
Anwendungssoftware
(vgl.
Absatz
[0001]
der
Offenlegungsschrift; diese wird im Folgenden als „OLS“ bezeichnet).
In der Beschreibungseinleitung der Anmeldung wird ausgeführt, dass im Stand der
Technik Verfahren zum Verteilen oder Aktualisieren von Anwendungssoftware oder
eingebetteter Systemsoftware über eine drahtlose Datenschnittstelle bekannt seien.
Solche Verfahren würden beispielsweise zur Aktualisierung der Steuergeräte
vernetzter Kraftfahrzeuge und Landmaschinen eingesetzt (OLS, Absätze [0002],
[0003]).
Auf diesem Wege lasse sich der Funktionsumfang fahrzeuginterner Steuergeräte
um Leistungsmerkmale erweitern, welche vorhandene Sensoren und Aktoren für
neue Anwendungsfälle nutzten. Entsprechende Anwendungen könnten durch
Hersteller oder Erstausrüster einer Landmaschine
- etwa mittels eines
Entwicklungskits - erstellt und auf einer digitalen Vertriebsplattform in der Cloud
angeboten werden. Als denkbare Erweiterungen kämen zum Beispiel
fortgeschrittene Telemetrie- oder agrartechnische Spezialfunktionen wie die
gezielte Unkrautbekämpfung in Betracht (OLS, Absatz [0004]).
Ferner finde in jüngerer Zeit die im Rechenzentrumsbetrieb bereits seit längerem
übliche Container- oder Betriebssystem-Virtualisierung vermehrt Eingang in die
Praxis der eingebetteten Systeme. Diese Methode erlaube es, mehrere Instanzen
eines Betriebssystems als sogenannte Gäste isoliert voneinander auf einem
Wirtssystem zu betreiben. Auf diese Weise könne der Wirt jeder innerhalb eines
solchen Containers gekapselten Anwendung eine vollständige Laufzeitumgebung
zur Verfügung stellen. Im Gegensatz zur Nutzung eines Hypervisors erlege diese
„leichtgewichtige“ Form der Virtualisierung den Gästen
zwar einige
Einschränkungen auf, berge jedoch den Vorteil, dass alle Container den Kern des
nativen Betriebssystems gemeinsam nutzten. Die Nutzung von Containern schone
somit die knappen Betriebsmittel eingebetteter Systeme (OLS, Absatz [0006]).
Ein Vorzug der erfindungsgemäßen Lösung liege in der eröffneten Möglichkeit zur
individuellen Erzeugung sowie des Startens, Ausführens und Beendens eines
Containers zur Laufzeit auf einem Steuergerät. Hierzu werde ein die
Anwendungssoftware beschreibendes sogenanntes Manifest, eine ausführbare
Programmdatei (Nutzsoftware im Gegensatz zu Software, welche die Infrastruktur
darstelle) und ein Containerframework verwendet (OLS, Absatz [0008]).
2.
Eine Aufgabe wird in der vorliegenden Anmeldung nicht ausdrücklich
angegeben. Den Absätzen [0002] bis [0008] der OLS ist allerdings zu entnehmen,
dass die der Anmeldung zugrundeliegende (subjektive) Aufgabe darin bestehen
soll,
ein
ressourcenschonendes Verfahren
zum Bereitstellen
einer
Anwendungssoftware für ein fahrzeuginternes Steuergerät anzugeben.
3.
Als für die Lösung dieser Aufgabe zuständige Fachmann ist ein Informatiker
oder ein Hochschulingenieur der Fachrichtung Elektrotechnik anzusehen, der über
mehrjährige Erfahrung
in der Entwicklung von Software
für virtualisierte
Umgebungen verfügt und mit den gängigen Plattformen zur Bereitstellung
containerbasierter virtualisierter Anwendungen vertraut ist.
4.
Zur Lehre von Patentanspruch 1
4.1 Patentanspruch 1 nach Hauptantrag
ist auf ein Verfahren zum
Bereitstellen einer Anwendungssoftware für eine Landmaschine gerichtet (vgl.
Merkmal 1), das durch die Verfahrensschritte der Merkmale 1.2 bis 1.5.3
gekennzeichnet ist.
4.1.1 Merkmal 1 verlangt, dass diese Verfahrensschritte geeignet sein sollen, im
Rahmen der Bereitstellung einer Anwendungssoftware für eine Landmaschine
eingesetzt zu werden. Ein darüber hinausgehender Bezug zu einer Landmaschine
ist weder dem Patentanspruch 1 noch den übrigen Anmeldungsunterlagen zu
entnehmen; insbesondere zeigen diese nicht, dass die Anwendungssoftware
Eigenschaften einer Landmaschine berücksichtigt oder dass die beanspruchten
Verfahrensschritte auf einer Recheneinrichtung ausgeführt werden, die Bestandteil
einer Landmaschine ist.
4.1.2 Gemäß Merkmal
1.2 wird
zunächst
eine Beschreibung
der
Anwendungssoftware angefertigt, d. h. es werden Informationen festgelegt, die die
Anwendungssoftware charakterisieren. So können die für „das geplante Feature“
- d. h. für charakteristische Merkmale der Anwendungssoftware - benötigten
Benutzer-
und Programmierschnittstellen
sowie Metadaten wie
IDs,
Ressourcenbedarf, Zielmarkt oder Serverstandort spezifiziert werden (OLS, Absatz
[0016]). Aus fachmännischer Sicht werden die für die Anwendungssoftware
charakteristischen Informationen von einem Softwareentwickler entweder bereits in
einer der Implementierung der Anwendungssoftware vorgelagerten Planungsphase
definiert oder aber im Verlauf der Implementierung beispielweise in einer oder
mehreren Dateien hinterlegt.
4.1.3 Anschließend soll anhand der Beschreibung ein Programmgerüst erzeugt
werden
(Merkmal 1.3), welches eine Anwendungsprogrammierschnittstelle
umfassen und dem Entwickler in seiner Entwicklungsumgebung als Vorlage dienen
kann (OLS, Absatz [0017]).
Unter einem Programmgerüst versteht der Fachmann eine Basisstruktur oder
Vorlage, die grundlegende Funktionalitäten eines Programms enthält oder vorgibt,
jedoch bestimmte programmspezifische Implementierungsdetails offenlässt. Damit
stellen Bibliotheken oder Frameworks, die von der Anwendungssoftware verwendet
werden, anspruchsgemäße Programmgerüste dar, ebenso wie Templates, die die
wichtigsten Bibliotheken enthalten (vgl. OLS, Absatz [0011]). Merkmal 1.3 schreibt
nicht vor, welche Informationen aus der Beschreibung verwendet werden sollen, um
das Programmgerüst zu erzeugen.
4.1.4 Weiterhin wird die Anwendungssoftware mittels Wrappern mit dem
Programmgerüst zu einer Programmdatei zusammengefügt (Merkmale 1.4/1.4.1).
Bei der Programmdatei kann es sich um eine Binärdatei in Maschinensprache, eine
Bytecode-Datei, die direkt oder durch ein Laufzeitsystem ausgeführt werden kann,
oder eine Textdatei handeln, die von einer Betriebssystem-Shell interpretiert wird
(OLS, Absatz [0018]).
Ein anspruchsgemäßer Wrapper ist aus Sicht des Fachmanns ein Programm, das
eine Verbindung zwischen der Anwendungssoftware und dem Programmgerüst
herstellt, wozu er mindestens eine dieser Komponenten gleichsam „umhüllt“ (engl.:
„to wrap“ - einhüllen) und dadurch eine geeignete Schnittstelle zu der mindestens
einen Komponente herstellt. In der Softwareentwicklung werden häufig komplexe
Programmierschnittstellen, Programmteile, die in anderen Programmiersprachen
implementiert wurden, oder auch Bibliotheken oder sonstige Programme, die von
der
Anwendungssoftware
verwendet werden,
über Wrapper mit
Anwendungssoftware verbunden (siehe hierzu OLS, Anspruch 7 sowie D3, Absatz
[0020] - „Managed applications 116 may include […] a library and/or wrapper. The
library may be […] added to the application by wrapping […]“). Zudem können
sogenannte Container-Images als Wrapper betrachtet werden, weil sie eine
vollständige Laufzeitumgebung kapseln - einschließlich Anwendungssoftware, der
von dieser verwendeten Programme („Abhängigkeiten“) und Konfigurationsdaten -
und dadurch eine Schnittstelle zur Interaktion mit der gekapselten Software
bereitstellen (vgl. D2, Absatz [0018] - „Each container image is structured as a
wrapper for content that is included within the container image“ i. V. m. Absätzen
[0019], [0020]; D5, Seite 14, Abschnitt 2.4.1 - „Docker containers are described […]
to “wrap up a piece of software in a complete filesystem that contains everything it
needs to run: code, runtime, system tools, system libraries“ […]“).
4.1.5 Ferner soll anhand der Beschreibung ein Manifest komplettiert werden
(Merkmal 1.5). Das bedeutet, dass aus der Beschreibung stammende Informationen
in eine bereits bestehende, unvollständige Version des Manifests aufgenommen
werden, so dass dieses vervollständigt wird.
Aus den Absätzen [0008] und [0009] der OLS ist abzuleiten, dass ein Manifest eine
Menge von Daten ist, die die Anwendungssoftware beschreiben und zur Erstellung
und Erzeugung sowie zum Starten, Ausführen und Beenden eines Containers zur
Laufzeit verwendet werden können.
Die Merkmale 1.5.1, 1.5.1a, 1.5.1b und 1.5.1c legen fest, dass das Manifest
verschiedene Aspekte einer containerbasierten Ausführungsumgebung beschreibt,
d. h. Informationen enthält, die sich auf diese Aspekte beziehen.
Im Einzelnen soll das Manifest eine Containertechnologie beschreiben, d. h.
Werkzeuge, Standards und Laufzeitumgebungen, mit denen Container erstellt,
ausgeführt, orchestriert und verwaltet werden (Merkmal 1.5.1a), ferner eine
„Plattformstruktur“ (also eine der Container-Implementierung zugrundeliegende
Infrastruktur
und/oder Rechnerarchitektur)
sowie
Informationen
zum
Laufzeitverhalten, mit denen definiert wird, wie sich die im Container ausgeführte
Software zur Laufzeit verhält (Merkmal 1.5.1b), und zudem die Einschränkung oder
Zuweisung von Systemressourcen, CPU, RAM und I/O (Merkmal 1.5.1c), d. h.
inwieweit ein Container die Systemressourcen Rechenleistung („CPU“) und
Arbeitsspeicher („RAM“) nutzen, auf Eingabe-/Ausgabekomponenten („I/O“)
zugreifen und ggf. andere Systemressourcen verwenden darf.
4.1.6 Laut den Merkmalen 1.5.2 und 1.5.3 wird das Manifest gemeinsam mit der
Programmdatei derart zu einer Archivdatei paketiert
(d. h. zu dieser
zusammengestellt bzw. in ein Archivdatei-Datenpaket umgewandelt), dass unter
einem vorgegebenen Betriebssystem ein für die Anwendungssoftware spezifischer
Container aus der Archivdatei extrahiert werden kann.
Ein Container wird in der Fachwelt grundsätzlich als eine isolierte, „leichtgewichtige“
Ausführungsumgebung für Anwendungen angesehen, die zur Laufzeit den
Betriebssystem-Kernel eines Hostsystems mitbenutzt (vgl. OLS, Absätze [0006],
[0008]). Container werden in der Regel aus Container-Images erzeugt, d. h. aus
ausführbaren Softwarepaketen, die sämtliche Komponenten enthalten, die zur
Ausführung einer Anwendung in dem Container erforderlich sind, darunter die
Anwendungssoftware mit ihren „Abhängigkeiten“ sowie Systembibliotheken und
Konfigurationsdaten. Ein Container-Image stellt den Container im inaktiven Zustand
dar und fungiert als strukturierte Vorlage, aus der zur Laufzeit die eigentliche (aktive)
Container-Instanz erzeugt wird.
Vor diesem Hintergrund bezeichnet der in Merkmal 1.5.3 angesprochene
„Container“ ein Container-Image, weil er in der Archivdatei enthalten sein muss, um
daraus extrahiert und anschließend installiert werden zu können (vgl. Merkmal 1.9).
Das Container-Image
ist
insbesondere dann
für die Anwendungssoftware
spezifisch, wenn es diese enthält.
Merkmal 1.5.3 impliziert, dass die Paketierung durch eine Extraktion des Containers
unter einem vorgegebenen Betriebssystem zumindest
teilweise rückgängig
gemacht werden kann. Dazu muss eine entsprechende Extraktionssoftware auf
dem Rechner installiert sein, auf dem sich das vorgegebene Betriebssystem
befindet.
4.2 Patentanspruch 1 nach Hilfsantrag 1 charakterisiert die Anwendungssoftware näher (vgl. Merkmale 1.1.1 bis 1.1.3) und enthält in den Merkmalen 1.6 bis
1.9 weitere Schritte, die der Ausführung der Programmdatei im spezifischen
Container auf einem Zielsystem gemäß Merkmal 1.10 vorgelagert sind.
4.2.1 So soll die Anwendungssoftware zur Aktualisierung eines Steuergerätes der
Landmaschine eingerichtet sein (Merkmal 1.1.1), wobei die Aktualisierung eine
Wartung, eine Fehlerbereinigung und/oder eine Erweiterung des Funktionsumfangs
der Anwendungssoftware umfasst (Merkmal 1.1.2). Die letztgenannte Alternative
soll ihrerseits das Bereitstellen mindestens einer der Funktionen „erweiterte
Telemetrie“ und/oder „agrartechnische Spezialfunktion zur Unkrautbekämpfung“
umfassen (Merkmal 1.1.3).
Die Merkmale 1.1.1 bis 1.1.3 werden von einer Anwendungssoftware verwirklicht,
die es ermöglicht, die Software des Steuergeräts einer Landmaschine zu warten
oder Fehler in dieser Software zu bereinigen - sodass das Steuergerät in beiden
Fällen aktualisiert wird.
4.2.2 Weiterhin wird die Archivdatei nach dem Paketieren in „der Cloud“ abgelegt
(Merkmal 1.6) und aus dieser auf ein Zielsystem heruntergeladen (Merkmal 1.7).
Die „Cloud" ist aus fachmännischer Sicht eine Infrastruktur, die es ermöglicht, Daten
und Anwendungen zentral zu speichern, zu verwalten und auf diese über das
Internet zuzugreifen (vgl. OLS, Absatz [0003] - „Zur […] Verbindung zwischen dem
[…] Bussystem und dem Internet (der sinnbildlichen „Cloud“ […])“).
4.2.3 Ferner wird eine Installation des spezifischen Containers anhand des
Manifests geplant und diese anschließend auf dem Zielsystem vorgenommen
(Merkmale 1.8, 1.9). Zuletzt wird die Programmdatei im spezifischen Container auf
dem Zielsystem ausgeführt (Merkmal 1.10).
Unter einer „Installation“ eines Containers versteht die Anmeldung vorbereitende
Schritte, die der Instanziierung des Containers vorausgehen (vgl. OLS, Absätze
[0023] und [0024] i. V. m. dem ursprünglichen Anspruch 5; vgl. Absatz [0025] im
Hinblick auf die Instanziierung).
Eine Installation des Containers wird anhand des Manifests geplant, wenn sich ein
Nutzer anhand von Informationen aus dem Manifest Gedanken macht, die sich auf
die Installation des Containers auswirken, und das Manifest auf Basis seiner
Überlegungen abändert, oder auch dann, wenn sich die Festlegung der
Informationen aus dem Manifest auf die Installation des Containers auswirkt -
beispielsweise auf deren Zeitpunkt.
5.
Das mit Patentanspruch 1 nach Hauptantrag beanspruchte Verfahren beruht
nicht auf einer erfinderischen Tätigkeit.
5.1
Zunächst ist festzuhalten, dass zumindest die Anweisung des Merkmals 1.3
sowie
das Verwenden
von Wrappern
zum
Zusammenfügen
der
Anwendungssoftware mit dem Programmgerüst zu einer Programmdatei gemäß
Merkmal 1.4.1 bei der Prüfung der erfinderischen Tätigkeit nicht zu berücksichtigen
sind. Denn diese Maßnahmen bestimmen oder beeinflussen nicht die Lösung eines
konkreten technischen Problems mit technischen Mitteln (vgl. BGH, Urteil vom 26.
Oktober 2010, X ZR 47/07, GRUR 2011, 125 - Wiedergabe topografischer
Informationen; BGH, Urteil vom 24. Februar 2011, X ZR 121/09, GRUR 2011, 610
- Webseitenanzeige; BGH, Beschluss vom 22. April 2010, Xa ZB 20/08, GRUR
2010, 613 - Dynamische Dokumentengenerierung).
5.1.1 So betrifft Merkmal 1.3 die Erzeugung einer Basisstruktur oder Vorlage für
ein Programm aus Informationen, die in der in Merkmal 1.2 angesprochenen
Beschreibung enthalten sind - d. h. es werden
Informationen, die die
Anwendungssoftware charakterisieren, in Anweisungen eines an sich beliebigen
Programmgerüsts überführt. Zur Motivation dieser Maßnahme ist der Anmeldung
allenfalls zu entnehmen, dass das Programmgerüst dem Entwickler die Arbeit
erleichtern soll (vgl. OLS, Absatz [0017] - „[…] ein Programmgerüst […], welches
dem Entwickler in seiner Entwicklungsumgebung als Vorlage dient“). Merkmal 1.3
liefert weder Vorgaben hinsichtlich der Art der generierten Informationen, noch lässt
es erkennen, dass der Vorgang des Erzeugens technische Gegebenheiten
innerhalb oder außerhalb einer Datenverarbeitungsanlage berücksichtigt oder dass
das Ergebnis der Erzeugung - das Programmgerüst - von
technischen
Eigenschaften eines Rechners oder sonstigen technischen Systems abhängt.
Die Anweisung des Merkmals 1.3 liegt daher ausschließlich auf den Gebieten der
Softwareentwicklung und der elektronischen Datenverarbeitung, nicht aber auf
technischem Gebiet, und stellt demgemäß kein technisches Mittel dar, das die
Lösung eines konkreten technischen Problems bestimmt oder beeinflusst.
5.1.2 Dies gilt gleichermaßen
für das Verwenden von Wrappern zum
Zusammenfügen der Anwendungssoftware mit dem Programmgerüst zu einer
Programmdatei (Merkmal 1.4.1).
Ein Umhüllen („Wrapping“) einer Softwarekomponente durch einen Wrapper dient
der Einbindung der Komponente an andere Programme über eine definierte
Schnittstelle. Hierbei wird lediglich eine zusätzliche, softwareseitige Zugriffsschicht
etabliert, die einen strukturierten Datenaustausch mit den angebundenen
Programmen ermöglicht, ohne dass dazu technische Überlegungen erforderlich
wären. Damit liegt diese Maßnahme auf der Ebene der Softwareentwicklung,
berührt weder die interne Implementierung der Softwarekomponente noch
technische Eigenschaften etwa eines Computersystems und wirkt sich auch nicht
auf die beanspruchte Weiterverarbeitung der Programmdatei aus.
5.2 Die Anweisungen der restlichen Anspruchsmerkmale 1, 1.2, 1.4 sowie 1.5
bis 1.5.3 vermögen keine erfinderische Tätigkeit zu begründen, da sie aus der Lehre
der Druckschrift D2 entnommen bzw. daraus unmittelbar abgeleitet werden können
oder nicht über das übliche Maß
fachmännischer Überlegungen bei der
Bereitstellung containerbasierter Software hinausgehen.
5.2.1 Die Druckschrift D2 befasst sich mit dem Problem, dass ein aus einem
Container-Image bereitgestellter Dienst von einem oder mehreren anderen
Diensten abhängig sein könne. Daher sei es möglich, dass der im Container-Image
enthaltene Dienst nicht oder nur mit Fehlern ausgeführt werde oder anderweitig
Probleme bei der Konfiguration und Bereitstellung der Dienste verursache (D2,
Absätze [0001], [0002]).
Zur Lösung des Problems sieht D2 vor, sogenannte Multi-Container-Images
bereitzustellen, d. h. Container-Images, die andere Container-Images sowie die
gesamte Ausführungsumgebung der Anwendungen einschließlich der für die
Ausführung der Anwendungen erforderlichen Systemtools, Bibliotheken und
Konfigurationsinformationen enthalten (D2, Figur 1 mit Absätzen [0013] bis [0015],
[0019], [0020], [0023], [0024] - „The container images […] that include multiple
services are referred to herein as composite applications. A composite application
may also be referred to as a multi-container image […]“). Da jeder Dienst einer
Anwendung entspricht, die den Dienst bereitstellt (vgl. Absatz [0024], vorletzter und
letzter Satz), enthalten die Multi-Container-Images mit den anderen Container-
Images auch die anderen Dienste. Ebenso wie übliche Container-Images können
Multi-Container-Images in sich abgeschlossene Archivdateien sein (Absatz [0018]).
Ein Multi-Container-Image kann von einem Container-Manager 112 einer
Entwicklungsumgebung 106 beispielsweise unter Verwendung der Plattform
„Docker“ erzeugt, in einer Container-Registry 102 abgelegt und von dort aus an eine
Laufzeitumgebung 108 übertragen werden, die sich auf einem Gerät befindet, das
mit dem Gerät des Entwicklers über ein Netzwerk 110 verbunden ist. In der
Laufzeitumgebung 108 wird das Multi-Container-Image entpackt und die in ihm
enthaltenen Dienste und Anwendungen werden instanziiert bzw. ausgeführt (D2,
Absätze [0015], [0034] - „[…] container manager 112 may include artifacts such as
DOCKER […]“, [0036], [0040], [0055], [0060]).
5.2.2 Der Fachmann entnimmt der Druckschrift D2 unter Rückgriff auf sein
Fachwissen ein Manifest mit den Merkmalen 1.5.1, 1.5.1a, 1.5.1b und 1.5.1c.
Laut D2 enthält ein Multi-Container-Image neben der Ausführungsumgebung ein
„Nulecule“, d. h. ein Manifest, das die Dienste des Multi-Container-Images definiert
und dazu eine Reihe weiterer Informationen umfassen kann, wie etwa Bezeichner
der Dienste, Verweise auf andere Container-Images, die den jeweiligen Diensten
zugeordnet und in der Container-Registry 102 abgelegt worden sind, Parameter der
Dienste sowie deren Ausführungsreihenfolge und „Abhängigkeiten“ (D2, Titel und
Absatz [0025] - „[…] composite applications are structured to include a nulecule file
[…] a metadata descriptor provided in the nulecule may include identifiers of the
services, references to container images corresponding to the services, parameters
of the services, runtime order of the services, dependencies of the services […] and
so forth“; zu den Eigenschaften eines Nulecules vgl. ferner Absätze [0026] bis
[0030] sowie [0042] bis [0050]). Anhand der Verweise können die anderen
Container-Images, die den Diensten der Anwendungen entsprechen, aus der
Container-Registry 102 abgerufen werden (Absätze [0038], [0058]).
Ein Nulecule kann „Artefakte“ benennen, die zur Verarbeitung der Container-
Images ausgeführt werden sollen, wie etwa einen Container-Manager und einen
Orchestrator, die jeweils zum Verpacken, Übermitteln und Bereitstellen des Multi-
Container-Images verwendet werden (Absatz [0041] - „The nulecule may specify
particular artifacts, such as a container manager and orchestrator, which are to be
used to package, transport and/or deploy the composite application […]“). Dabei
kann ein Container-Manager die Container-Plattform „Docker“ implementieren
(Absatz [0034] - „[…] container manager 112 may include artifacts such as
DOCKER […]“; s. auch Absatz [0049]).
Zudem kann ein Nulecule auf eine für einen Container-Manager bestimmte
Konfigurationsdatei verweisen, die weitere Informationen zur Ausführung der im
Nulecule angegebenen Dienste enthält, wie etwa einen Befehl, der den Container-
Manager veranlasst, die Dienste auszuführen oder auch Konfigurationsparameter,
die zur Instanziierung der Dienste verwendet werden (vgl. Absatz [0050] i. V. m.
Absatz [0041]). Neben den in dem Nulecule enthaltenen Informationen können
diese weiteren Informationen unter das anspruchsgemäße Manifest subsumiert
werden, weil sie beim Starten und Ausführen eines Containers eingesetzt werden.
a)
Da das Nulecule auf einen Container-Manager und auf Container-Images
Bezug nimmt, enthält es Informationen, die sich auf eine Containertechnologie
beziehen (Merkmal 1.5.1a).
b)
Die Informationen über die Ausführungsreihenfolge der Dienste beschreiben
deren Laufzeitverhalten und bilden zusammen mit den im Nulecule definierten
Informationen zu den Diensten, deren Bezeichnern und Abhängigkeiten, den
Informationen zu den
„Artefakten“ und den zu diesen gehörenden
Konfigurationsdateien einschließlich der darin enthaltenen Parameter und Befehle
eine strukturierte Beschreibung der Plattformarchitektur, auf der die Container
ausgeführt werden sollen.
Somit zeigt D2 auch das Merkmal 1.5.1b.
c)
Darüber hinaus ist es eine dem Fachmann wohlbekannte, grundlegende
Gegebenheit der Containervirtualisierung, dass ein auf einem Zielsystem
ausgeführter Container eine mit hinreichenden Ressourcen ausgestattete
Ausführungsumgebung benötigt. Diese Notwendigkeit ergibt sich insbesondere
daraus, dass sich der Container in der Regel die Ressourcen des Zielsystems mit
anderen Containern oder Programmen teilen muss. Um eine zuverlässige
Ausführung der in dem Container enthaltenen Software sicherzustellen, müssen die
benötigten Ressourcen entweder bei der Erstellung des Containers oder zur
Laufzeit festgelegt werden (vgl. hierzu D5, Seite 11 Mitte - „Virtualization can be
used for a number of reasons […] Resource sharing - Sharing the hardware
capabilities of the host as memory, disk and network“; Seite 12 Mitte - „OS-layer
virtualization, also called containers […] Resources like memory, CPU and disk
space can be reassigned both at creation and at runtime […]“).
aa) Vor diesem Hintergrund liest der Fachmann mit, dass die in Absatz [0050]
der Druckschrift D2 angesprochenen Größen (d. h. die Befehle, die einen Container-
Manager oder einen Orchestrator veranlassen, die Dienste auszuführen und/oder
die bei der Instanziierung von Diensten verwendeten Konfigurationsinformationen)
Zuweisungen im Hinblick auf die Ressourcen CPU, RAM und I/O enthalten.
bb) Das Fachwissen im Hinblick auf derartige Zuweisungen wird durch die
Druckschriften D5 und D1 dokumentiert.
So ist in Druckschrift D5 die dem Fachmann wohlbekannte Containerplattform
„Docker“ beschrieben, auf der das aus Druckschrift D2 bekannte
Containerbereitstellungsverfahren „aufsetzen“ kann (vgl. D2, Absatz [0034]). D5
enthält Ausführungen zu „docker run“-Befehlen, mit denen einem Container beim
Start Eingabe- und Ausgabekomponenten zugewiesen werden können, indem
diese Befehle mit den Optionen „−−net=isolated_nw“, „−−ip =172.18.0.2“, „−−it“ und
„/dev/ttyAMA0: /dev/ttyAMA0 –privileged“ versehen werden (vgl. D5, Seite 35,
Abschnitt 3.5.2 sowie Seite XV, Abschnitt D.1). Diese Optionen weisen einem
Container ein isoliertes benutzerdefiniertes Subnetzwerk („isolated_nw“), eine IP-
Adresse (172.18.0.2), eine Standardeingabe und ein virtuelles Ausgabeterminal
sowie eine serielle Schnittstelle („/dev/ttyAMA0“) zu, d. h. Systemressourcen, die
als „I/O“ bezeichnet werden können.
Ebenso kann einem Container mittels der Optionen „−−device /dev/mem:/dev/mem
−−privileged“ der physische Speicher des Hosts (d. h. die Systemressource „RAM“)
zugewiesen werden (vgl. Seite 35, Abschnitt 3.5.2, vorletzter Absatz - „[…] device
flags enabling the container to write to memory […]“).
Zudem weiß der Fachmann, dass ein zu einem Container-Image gehörendes
Manifest Konfigurationsinformationen zu Plattform-Ressourcen und insbesondere
einer Prozessorarchitektur eines Zielsystems umfassen kann, auf der der
zugehörige Container instanziiert werden soll (vgl. D1, Absatz [0055] - „Each image
manifest 342 is associated with […] an image platform specifier 346. The image
platform specifier 346 may include a plurality of data fields that specifies platform
resources […], for example, the processor architecture […] associated with
executing the application image 344 of the image manifest“). Die Angabe einer
Prozessorarchitektur charakterisiert die Systemressource „CPU“.
5.2.3 Die Vorgaben der Merkmale 1.2 und 1.5 sowie das Zusammenfügen der
Anwendungssoftware mit dem Programmgerüst zu einer Programmdatei gemäß
Merkmal 1.4 stellen keine über das
fachübliche Maß hinausgehenden
Besonderheiten bei der Bereitstellung von Anwendungssoftware in einem Container
gemäß Druckschrift D2 dar.
a)
So werden laut D2 die Informationen des Nulecules, die die Dienste eines
Multi-Container-Images charakterisieren, vom Softwareentwickler spezifiziert -
üblicherweise mittels eines Texteditors (D2, Absatz [0052]; s. auch Absatz [0027] -
„In some examples, the nulecule is structured as a text file“ sowie Fig. 2). Gleiches
gilt für die in Absatz [0050] genannten Befehle und Konfigurationsdaten. Nachdem
der Entwickler die
letzte dieser
Informationen spezifiziert hat,
ist das
anspruchsgemäße Manifest somit vollständig („komplett“).
Ferner ist es bei der Softwareentwicklung gang und gäbe, Informationen, die die zu
implementierende Software beschreiben,
in einer der
Implementierung
vorgelagerten Planungsphase rein gedanklich, in Papierform oder auch am
Computer in einer Textdatei festzulegen und die Implementierung anschließend in
Übereinstimmung mit diesen Informationen vorzunehmen. Dies gilt gerade auch für
die oben angesprochenen Informationen, die der Softwareentwickler im Zuge der
Implementierung des aus D2 bekannten Containerbereitstellungsverfahrens
spezifiziert hat.
Damit sind die Merkmale 1.2 und 1.5 erfüllt.
b)
Des Weiteren ist es für den Fachmann selbstverständlich, dass die in einem
Multi-Container-Image enthaltenen Anwendungen ausführbare Programmdateien
(„Executables“) sowie Bibliotheken beinhalten (vgl. D1, Absatz [0030] - „an image
refers to data representing executables […]“; D2, Absatz [0020] - „[…] a container
image may include […] software applications […] libraries corresponding to the
applications […] and so forth“), wobei die Executables aus einem Quellcode und
(statisch) gelinkten Bibliotheken oder auch aus Frameworks
- also
anspruchsgemäßen Programmgerüsten - erzeugt worden sein können (Merkmal
1.4).
5.2.4 Die verbleibenden Merkmale 1.5.2, 1.5.3 und 1 gehen aus Druckschrift D2
hervor oder sind unmittelbar aus deren Lehre abzuleiten.
a)
Gemäß D2 kann ein Multi-Container-Image eine Archivdatei sein, die ein
Nulecule sowie mögliche Container-Images enthält (vgl. D2, Absatz [0018] i. V. m.
Absätzen [0024] und [0025]).
Damit ist das Merkmal 1.5.2 in D2 offenbart.
b)
Laut
D2
können
sämtliche
Container-Images
in
einem
plattformunabhängigen, standardisierten Format vorliegen, das auch von dem
Container-Manager 116 der Laufzeitumgebung 108 interpretiert werden kann, in der
sie entpackt werden (D2, Absätze [0022], [0036], [0037]). Daraus folgt, dass ein
Multi-Container-Image derart gepackt worden sein muss, dass dessen
Komponenten (insbesondere die in ihm enthaltenen Container-Images und
Anwendungen) von einem Rechner der Laufzeitumgebung 108 aus der Archivdatei
extrahiert werden können.
Daher muss auf jedem Rechner, auf dem Multi-Container-Images weiterverarbeitet
werden sollen, Software installiert sein, mit der die Extraktion der Komponenten des
Multi-Container-Images möglich ist - unabhängig von dem Betriebssystem dieses
Rechners und damit insbesondere auch unter einem (beliebigen) vorgegebenen
Betriebssystem. Denn andernfalls könnte das Multi-Container-Image auf dem
Rechner nicht entpackt und somit der zugehörige Container nicht instanziiert
werden.
Somit folgt Merkmal 1.5.3 unmittelbar aus der Lehre der D2.
c)
Schließlich ergibt sich das Merkmal 1 bei Ausführung des in den Abschnitten
5.2.1 bis 5.2.4 beschriebenen Verfahrens, mit dem die Anspruchsmerkmale 1, 1.2,
1.5 bis 1.5.3 sowie die bei der Prüfung der erfinderischen Tätigkeit zu
berücksichtigende Bestandteile des Merkmals 1.4 ohne erfinderisches Zutun
verwirklicht werden.
Denn mit diesem Verfahren wird eine Anwendungssoftware bereitgestellt. Das
Verfahren ist unabhängig von den Eigenschaften der bereitgestellten Software
anwendbar und damit insbesondere zur Bereitstellung einer Anwendungssoftware
für eine Landmaschine geeignet.
5.3 Nach alledem ist der Gegenstand von Patentanspruch 1 nach Hauptantrag
durch den aufgezeigten Stand der Technik nahegelegt.
6.
Dies gilt ebenfalls für das mit dem Patentanspruch 1 des Hilfsantrags 1
beanspruchte Verfahren.
6.1 So sind die Merkmale 1.6, 1.7, 1.9 und 1.10 in Druckschrift D2 offenbart.
6.1.1 Wie vorstehend ausgeführt (vgl. Abschnitt 5.2.1), kann ein Multi-Container-
Image in einer Entwicklungsumgebung 106 erzeugt, in der Container-Registry 102
abgelegt und von dort aus an die Laufzeitumgebung 108 übertragen werden.
Gemäß Absatz [0061] der D2 können die an diesen Vorgängen beteiligten Rechner
der Entwicklungs- und der Laufzeitumgebung über das Internet mit der Container-
Registry verbunden sein.
Damit gehen die Merkmale 1.6 und 1.7 aus D2 hervor.
6.1.2 Ferner werden die im Multi-Container-Image enthaltenen Dienste instanziiert
und im Zuge dessen die zugehörigen Anwendungen - insbesondere die im Multi-
Container-Image enthaltenen ausführbaren Programmdateien - ausgeführt (vgl. D2,
Absatz [0060] - „[…] the orchestrator may then instantiate the services […]
Instantiating a service may include […] executing applications that are included in
the container images […]“). Dies setzt eine Installation des Containers voraus, in
dem die Programmdateien ausgeführt werden.
Auch die Merkmale 1.9 und 1.10 sind somit der D2 zu entnehmen.
6.2 Merkmal 1.8 betrifft lediglich eine Selbstverständlichkeit bei der Entwicklung
und Bereitstellung der in D2 beschriebenen Multi-Container-Anwendung.
In D2 ist beschrieben, dass nach der Übertragung des Multi-Container-Images an
die Laufzeitumgebung 108 zu aktualisierende Dienst-Parameter, die in dem
Nulecule enthalten sind, vom Nutzer über eine Benutzerschnittstelle eingegeben
werden können. Anschließend werden die Container-Images, auf die in dem
Nulecule verwiesen wird, aus der Container-Registry abgerufen, die in den Images
enthaltenen Anwendungen entpackt, die zu den Dienst-Parametern gehörenden
Konfigurationsfiles aktualisiert und schließlich die Dienste instanziiert (vgl. Figur 4 i.
V. m. Absätzen [0056] bis [0060]).
Es ist selbstverständlich, dass sich der Nutzer über die Änderungen an den Dienst-
Parametern Gedanken macht, bevor er deren aktualisierte Werte festlegt und
dadurch die Installation des Containers beeinflusst, der dem Multi-Container-Image
entspricht. Insbesondere wirkt sich die Zeitspanne, die der Nutzer zur Festlegung
der aktualisierten Parameter des Manifests benötigt, auf den Zeitpunkt der
Installation des Containers aus, in dem die im Multi-Container-Image enthaltenen
Dienste ausgeführt werden. Damit ist auch Merkmal 1.8 erfüllt.
6.3 Schließlich ist festzustellen, dass sich Merkmal 1 auch dann ergibt, wenn das
in den Abschnitten 5.2.1 bis 5.2.4 sowie 6.1 und 6.2 beschriebene Verfahren, mit
dem die Anspruchsmerkmale 1, 1.2, 1.4 und 1.5 bis 1.10 ohne erfinderisches Zutun
verwirklicht werden, zur Bereitstellung von Anwendungssoftware eingesetzt wird,
die wie in den Merkmalen 1.1.1 bis 1.1.3 beschrieben eingerichtet ist.
Denn dieses Verfahren genügt bereits deshalb den Anforderungen der Merkmale 1
bis 1.1.3, weil im Rahmen seiner Ausführung Container für beliebige Zielsysteme
bereitgestellt und auf beliebigen Rechnern ausgeführt werden können (vgl. D2,
Absatz [0061] - „FIG.4 illustrates a diagram of a machine in the form of a computer
system […] The machine may be […] any machine capable of executing a set of
instructions […] that specify actions to be taken by that machine […]“). Es ist daher
insbesondere zur Bereitstellung von Anwendungssoftware geeignet, die durch die
Merkmale 1.1.1 bis 1.1.3 charakterisiert ist.
Im Übrigen war dies dem Fachmann zumindest für diejenigen Kombinationen der
Merkmale 1.1.1 bis 1.1.3, bei denen Verfahren zur Bereitstellung von Containern
zur Bereinigung von Fehlern in Steuergerätesoftware oder zur Wartung derartiger
Software eingesetzt werden, aus dem Stand der Technik bekannt (vgl. D5, Titel,
Abschnitte 1.1, 2.5, 3 und 7.1; insbesondere Abschnitt 2.5, letzter Absatz - „The
software of an embedded product may need an updated for several possible
reasons. Repairs when bugs need to be fixed […] and the software might be […] in
need for continuous maintenance […]“).
6.4
Im Ergebnis können auch die gegenüber Patentanspruch 1 nach
Hauptantrag neu hinzukommenden Merkmale des Patentanspruchs 1 nach
Hilfsantrag 1 eine erfinderische Tätigkeit nicht stützen.
7.
Mit dem jeweils nicht gewährbaren Patentanspruch 1 nach Hauptantrag und
Hilfsantrag 1 sind auch die weiteren Patentansprüche der Anträge nicht gewährbar,
da auf diese Patentansprüche kein eigenständiges Patentbegehren gerichtet ist und
über einen Antrag nur einheitlich entschieden werden kann (BGH, Beschluss vom
27. Juni 2007, X ZB 6/05, GRUR 2007, 862 Rn. 18 - Informationsübermittlungsverfahren II).
8.
Bei dieser Sachlage war die Beschwerde zurückzuweisen.
9.
Die Anregung der Anmelderin auf Zulassung der Rechtsbeschwerde war
nicht aufzugreifen.
Die Rechtsbeschwerde ist zuzulassen, wenn eine Rechtsfrage von grundsätzlicher
Bedeutung zu entscheiden ist oder die Fortbildung des Rechts oder die Sicherung
einer einheitlichen Rechtsprechung eine Entscheidung des Bundesgerichtshofs
erfordert (§ 100 Abs. 2 PatG).
Durch die vorliegende Anmeldung wird
jedoch keine Rechtsfrage von
grundsätzlicher Bedeutung aufgeworfen, zu der eine höchstrichterliche
Rechtsprechung nicht vorläge.
In den oben angeführten Entscheidungen
„Wiedergabe topografischer Informationen“, „Webseitenanzeige“ und „Dynamische
Dokumentengenerierung“ des Bundesgerichtshofs sind die Erfordernisse
wiedergegeben, nach denen eine Anweisung bei der Prüfung der erfinderischen
Tätigkeit zu berücksichtigen ist und deren Erfüllung auch beim Gegenstand der
Anmeldung zu überprüfen war. Der Senat sieht sich in Übereinstimmung mit dieser
Rechtsprechung. Eine vom vorliegenden Beschluss abweichende Rechtsprechung
eines anderen Senats des Bundespatentgerichts ist nicht erkennbar.
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
Dr. Harth
Bundespatentgericht
(Aktenzeichen)
Verkündet am
17. Juni 2025
…