17 W (pat) 9/23

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. - 2 - 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 Datenverar- beitungsprogramme 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; - 3 - - 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: 1 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 zusammenge- fü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, - 4 - 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): 1 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 Anwendungs- software 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: - 5 - 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 zusammenge- fü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 - 6 - 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. - 7 - 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 - 8 - 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. - 9 - 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, - 10 - 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 - 11 - [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. - 12 - 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 Anwendungs- software näher (vgl. Merkmale 1.1.1 bis 1.1.3) und enthält in den Merkmalen 1.6 bis - 13 - 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 - 14 - [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 - 15 - 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. - 16 - 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]). - 17 - 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- - 18 - 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 - 19 - 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 […]“). - 20 - 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 - 21 - 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 - 22 - 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. - 23 - 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]). - 24 - 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 - 25 - 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übermittlungs- verfahren 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 - 26 - 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. - 27 - 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 eine beim Bundesgerichtshof zugelassene Rechtsanwältin oder durch einen beim Bundesgerichtshof zugelassenen Rechtsanwalt einzulegen. Dr. Forkel Akintche Dr. Städele Dr. Harth - 28 - Bundespatentgericht 17 W (pat) 9/23 (Aktenzeichen) Verkündet am 17. Juni 2025 …