T 0268/22 (Software-Architektur für autonomes Fahren/DIEHL) 12-09-2024

Entscheidungsgründe

1. Technischer Hintergrund

1.1 Das Streitpatent betrifft eine Steuereinrichtung für ein (militärisches) Fahrzeug. Diese Steuereinrichtung ermöglicht einen teilweise autonomen Betrieb des Fahrzeugs. Insbesondere kann es sich bei diesem autonomen Betrieb um Fahrerassistenzfunktionen wie beispielsweise automatisches Einparken, Kollisionsschutz sowie Längs- oder Querführung handeln.

1.2 Der Erfindung liegt die technische Aufgabe zugrunde, die Steuereinrichtung so auszugestalten, dass eine erhöhte Robustheit gegenüber Systemschäden gegeben ist und insbesondere die Steuereinrichtung auf unterschiedlichen Plattformen, d. h. in unterschiedlichen Fahrzeugen, eingesetzt werden kann.

1.3 Diese Aufgabe wird laut Streitpatent dadurch gelöst, dass die Algorithmen, die das "Kernstück" des autonomen Betriebs bilden, auf alle Recheneinheiten der Steuereinrichtung vorhanden oder einladbar sind. Des Weiteren sind die Algorithmen auf verschiedenen Arten von Recheneinheiten (z. B. Computer, DSP, fPGA, IC oder "Microcontroller") ausführbar.

Dabei umfasst eine auf jeder Recheneinheit vorhandene "Konfigurationsdatei" eine Startverteilung der Algorithmen, die dynamisch geändert werden kann, um beispielsweise auf Systemschäden zu reagieren. Ein "Masteralgorithmus" gewährleistet zudem die Koordination zwischen den verschiedenen Recheneinheiten bei der Ausführung der Algorithmen. Einige der Recheneinheiten können hierbei als "Slaves" ohne eigene Speichereinrichtung ausgeführt sein.

2. Hauptantrag: Anspruch 1 - erfinderische Tätigkeit

2.1 In Gründe 14.1 der angefochtenen Entscheidung wird das Dokument E1 als geeigneter Ausgangspunkt für die Beurteilung der erfinderischen Tätigkeit angesehen. Die Einspruchsabteilung war der Ansicht, dass E1 die Merkmale a), b), d) und e) offenbart.

2.2 Die Kammer stimmt dem zu und teilt darüber hinaus die Auffassung der Beschwerdeführerin, dass auch das Merkmal f) aus E1 zumindest implizit bekannt ist. Dies liegt daran, dass die Formulierung "ein kompletter Satz aller Algorithmen" aus diesem Merkmal so verstanden werden kann, dass jede der Recheneinheiten nach Merkmal b) nur alle für die "eigene" Funktion relevanten Algorithmen enthalten soll. Die in E1 erwähnten "ECU-Steuergeräte" implizieren eine Verarbeitungseinheit, wie beispielsweise den in den Absätzen [0198] und [0205] von E1 beschriebenen "Microcontroller" 152, welche zumindest auf die für ihre spezifische Funktion erforderlichen Algorithmen zugreifen können muss. Dies kann entweder, wie in der von der Beschwerdegegnerin angesprochenen ASIC-Ausführung der ECUs, durch eine fest in der Verarbeitungseinheit verankerte ("vorhandene") Programmierung oder durch bedarfsgerechtes Laden der entsprechenden Software ("einladbar") realisiert werden.

Das Argument der Beschwerdegegnerin, dass

"die Algorithmen im Merkmal b) begrifflich eingeführt werden, ohne Unterteilungen vorzunehmen, und sodann wieder erwähnt werden, sodass mit dem Ausdruck nur alle dieser Algorithmen (komplett) gemeint werden sein können", vermag in diesem Zusammenhang nicht zu überzeugen. Nach Auffassung der Kammer deutet die Verwendung der Formulierung "ein kompletter Satz" - anstelle z. B. des Ausdrucks "alle Algorithmen" - darauf hin, dass eine Unterteilung der Algorithmen in der beanspruchten Steuereinrichtung durchaus möglich ist. Ein "Satz" könnte nämlich eine ausgewählte Gruppe von Algorithmen sein, die zusammen eine bestimmte Funktion oder Aufgabe erfüllen. Er muss entsprechend nicht auf redundante Weise auch alle einschlägigen Algorithmen für die Funktionen anderer, d. h. "fremder", Recheneinheiten umfassen.

2.3 Die Beschwerdegegnerin stellte hingegen die Offenbarung von Merkmal a) in E1 in zweierlei Hinsicht in Frage.

2.3.1 Erstens war sie der Ansicht, dass der Begriff "autonomer Betrieb" im gängigen Sprachgebrauch, wie

z. B. auch in den Nachrichten, normalerweise als "autonomer Fahrbetrieb" ausgelegt werde, wobei gemeint sei, dass ein Fahrzeug sich von alleine bewegen würde.

Die Kammer hat keine Zweifel daran, dass ein "autonomes System" im heutigen Sinne in der Tat ein hohes Maß an Unabhängigkeit und Entscheidungsfreiheit des zugrunde liegenden Systems beinhaltet, wobei das autonome System in unbekannten oder unvorhergesehenen Situationen selbstständig Entscheidungen treffen und auch handeln kann, basierend auf seiner Wahrnehmung der Umgebung und seinen Zielen. Es ist jedoch anzumerken, dass das Konzept vom "autonomen Fahren" zum Prioritätszeitpunkt des Streitpatents möglicherweise noch nicht so weit verbreitet oder klar definiert war wie heute. So gilt die Norm "SAE J3016", die die Klassifizierung und Definition von Begriffen für straßengebundene Kraftfahrzeugen mit Systemen zum automatisierten Fahren beschreibt, erst seit Januar 2014.

Die Beschwerdegegnerin räumte ein, dass die Kammer möglicherweise nicht ihrer Auffassung folgt, dass gemäß Artikel 69 (1) Satz 2 EPÜ die Beschreibung stets bei der Anspruchsauslegung heranzuziehen sei. Sie betonte jedoch, dass es der Patentinhaberin dennoch gestattet sein sollte, den Kontext der Erfindung aus der Beschreibung in den Anspruch einfließen zu lassen. Insbesondere argumentierte sie, dass der Begriff "autonomer Betrieb" in Merkmal a) genau diese Funktion erfülle.

Die Kammer merkt hierzu jedoch an, dass sich der "Betrieb" nach Merkmal a) nicht notwendigerweise auf den "Fahrbetrieb" beschränkt. Außerdem geht aus Anspruch 1 nicht hervor, dass die dort genannten "Algorithmen" tatsächlich auf den Fahrbetrieb zugeschnitten wären. Entsprechend kann die Kammer in Merkmal a) keine weitere über die von der Einspruchsabteilung in Gründe 14.1 der angefochtenen Entscheidung anerkannte Einschränkung hinaus erkennen. Dies bedeutet, dass in Merkmal a) lediglich eine "Eignung" zum "teilweise autonomen Betrieb" gefordert wird. Die Kammer teilt auch die in Gründe 14.1 der angefochtenen Entscheidung angeführte Auffassung der Einspruchsabteilung, dass die aus E1 bekannte "Steuereinrichtung" eine solche "Eignung" offenbart. Es sei in diesem Zusammenhang zudem bemerkt, dass die Beschwerdegegnerin im Hinblick auf den Absatz [0015] des Streitpatents ("die Realisierung von autonomen Fähigkeiten und Funktionen im Stand der Technik bezüglich der Algorithmik, der Auswertung von Sensordaten und dergleichen bereits bekannt ist und hier nicht näher dargelegt werden soll") auch eingeräumt hat, dass die dem Streitpatent zugrunde liegende Erfindung nicht das "autonome Fahren" an sich angepeilt habe.

2.3.2 Darüber hinaus war die Beschwerdegegnerin der Ansicht, dass mit dem Begriff "militärischen" in Merkmal a) "klar eine Einschränkung gegenüber einem Fahrzeug im Allgemeinen" vorgenommen werde, so dass "die mit dem Anspruch konfrontierte Fachperson, die diesen mit dem Willen, zu verstehen, liest, zwangsläufig auch ohne weiteres Studium der Beschreibung zu dem Schluss kommt, dass ein militärischer Einsatz des Fahrzeugs und die entsprechenden zusätzlichen Belastungen angesprochen sind". Ein militärisches Fahrzeug müsse grundsätzlich für einen Kampfeinsatz geeignet sein.

Auch dieser Ansicht kann sich die Kammer nicht anschließen. Der Ausdruck "militärischen" definiert keine spezifischen technischen Eigenschaften oder Anforderungen an die beanspruchte Steuereinrichtung. Es gibt keine Angaben zu bestimmten Sensoren, Algorithmen, Kommunikationstechnologien oder anderen technischen Aspekten, die ausschließlich für "militärische Fahrzeuge" gelten würden. Es ist insbesondere für die Kammer nicht ersichtlich, wie sich technisch z. B. ein Militärpolizeifahrzeug von dessen zivilem Pendant unterscheiden würde, jedenfalls nicht in dem Maße, dass der fachkundige Leser dadurch eine Einschränkung der beanspruchten "Steuereinrichtung" erkennen würde. Die Kammer merkt an dieser Stelle auch an, dass es bei dem häufig verwendeten Verweis auf einen "verständniswilligen" fachkundigen Leser darum geht, sich auf einen fachkundigen Leser zu verlassen, der bereit ist, einen Anspruch objektiv auszulegen, und nicht auf einen fachkundigen Leser, dem es darum geht, die angebliche Absicht des Anmelders oder Patentinhabers zu "verstehen" (vgl. T 10/22, Gründe 2.3).

2.4 Dadurch ist bezüglich E1 lediglich die Offenbarung von Merkmalen c), g), h) und i) zu verneinen.

2.5 Im Zusammenhang mit der Beurteilung der erfinderischen Tätigkeit ist zunächst die mit diesen Unterscheidungsmerkmalen einhergehende technische Wirkung zu bestimmen.

2.5.1 Die Beschwerdegegnerin machte in diesem Kontext eine Synergie geltend und zwar dahingehend, dass die Anspruchsmerkmale zusammenwirken würden, "um eine plattformunabhängig einsetzbare, robuste Steuereinrichtung für den militärischen Gebrauch bei der autonomen Fahrzeugführung bereitzustellen, die insbesondere flexibel und schnell auf Ausfälle durch Anpassung der verteilten Ausführung reagieren kann". Sie verwies dabei insbesondere auf die, aus ihrer Sicht, aus den Merkmalen g) und h) hervorgehende flexible Gestaltung der Recheneinheiten bzw. auf die dort angesprochene Ausführung der [übrigen] Algorithmen, und auf die in Merkmal c) genannte "Middleware-Umgebung". Sie betonte, dass der Zusammenhang der Anspruchsmerkmale eindeutig aus der Beschreibung hervorgehe und bezog sich dabei insbesondere auf Absatz [0019] des Streitpatents.

2.5.2 Die Kammer kann jedoch nicht nachvollziehen, wie die von der Beschwerdegegnerin genannte Synergie mit den Merkmalen a) bis i) glaubhaft über den gesamten beanspruchten Bereich erfolgen würde. Zwar verweist Merkmal e) auf einen "Ausfall" oder eine "Überbelastung" des ersten Kommunikationsnetzwerks nach Merkmal c). Die in Anspruch 1 genannten Recheneinheiten sollten dann das in Merkmal e) genannte "zweite" Kommunikationsnetzwerk nutzen. Dies weist auf eine gewisse Fehler-Redundanz hin, lässt aber offen, wie "flexibel und schnell" das Umschalten von dem ersten auf das zweite Kommunikationsnetzwerk geschehen soll. Darüber hinaus ist in Anspruch 1 keinerlei Hinweis auf eine "Plattformunabhängigkeit" zu erkennen. Insbesondere sind dort die "Middleware"-Umgebung nach Merkmal c), der "komplette Satz aller Algorithmen" aus Merkmal f) und die "Konfigurationsdatei" aus Merkmal h) in diesem Zusammenhang nicht weiter präzisiert. Auch von einer "Robustheit" kann in dieser Allgemeinheit keine Rede sein. Die in Merkmal i) suggerierte

"Master/Slave"-Anordnung mindert nach Ansicht der Kammer eine etwaige "Robustheit" der beanspruchten Steuereinrichtung, indem der in diesem Merkmal genannte "Master" als zentraler Schwachpunkt ("single point of failure") das gesamte System lahmlegen könnte.

2.5.3 Aus Sicht der Kammer stellt sich die mit den Merkmalen c), g), h) und i) glaubhaft einhergehende technische Wirkung bestenfalls wie folgt dar. So ermöglicht die "Middleware"-Umgebung aus Merkmal c) eine praktische Umsetzung einer Software-Architektur zur Kommunikation zwischen den Recheneinheiten aus Merkmal b). Hinsichtlich der zu formulierenden objektiven technischen Aufgabe, merkt die Kammer in Bezug auf Dokument E1 Folgendes an.

Die Umsetzung der Kommunikation in E1 zwischen den Recheneinheiten (wie z. B. die mit "135", "140" und "150" in Figur 1 von E1 aufgeführten ECUs) gibt die für die damaligen Zeit gängige Praxis an, einen "Kommunikationsbus" einzusetzen, worüber die ECUs direkt Nachrichten austauschen, die spezifische Protokolle und Datenformate verwenden (s. Absatz [0269] von E1, wo einige dieser Protokolle aufgelistet sind). Ein solcher "Kommunikationsbus" stellt lediglich die physische Verbindung und die grundlegenden Mechanismen für den Datenaustausch bereit. Im Vergleich zu der in E1 gezeigten Umsetzung bietet eine "Middleware"-Umgebung zusätzliche Funktionen über die reine Datenübertragung hinaus, wie z. B. Datenabstraktion, Nachrichtenverwaltung, Datenkonvertierung und Prozessmanagement. Sie erleichtert auch die Integration verschiedener Softwarekomponenten und ermöglicht deren flexible Anordnung. Dies ist jedoch nicht gleichzusetzen mit der von der Beschwerdegegnerin behaupteten Fähigkeit, generell "flexibel und schnell auf Ausfälle" zu reagieren (siehe Punkt 2.5.1 oben). Die hier angesprochene Flexibilität bezieht sich vielmehr auf die modulare Gestaltung und Anpassungsfähigkeit der Softwarearchitektur, nicht auf eine unmittelbare Reaktion auf Systemausfälle.

Des Weiteren kann nach Merkmalen g) und h) jede der Recheneinheiten aus Merkmal b) einen "Masteralgorithmus" ausführen, der "nach dem Booten" die Ausführung von weiteren "eigenen" oder weiteren "fremden" Algorithmen koordiniert (vgl. Punkt 2.2 oben). Dies erzielt höchstens die technische Wirkung, dass nach dem Booten die mit diesen weiteren Algorithmen einhergehenden Prozessabläufe untereinander abgestimmt werden (vgl. auch Absatz [0062] des Streitpatents). Hinsichtlich der zu formulierenden technischen Aufgabe (s. Punkt 2.7.2 unten) ist anzumerken, dass in E1 kein expliziter Startvorgang gezeigt wird. Insbesondere wird in den Absätzen [0191] bis [0195] von E1 zwar beim Normalbetrieb eine bestimmte Reihenfolge beim Ablauf der Prozesse in den einzelnen ECUs angedeutet; es wird jedoch in E1 nicht offenbart, wie die einzelnen durch die ECUs (z. B. 135, 140 und 150 aus Figur 1 von E1) gesteuerten Prozessvorgänge nach dem Starten zu koordinieren sind.

In Bezug auf Merkmal i) hat die Beschwerdegegnerin die technische Wirkung geltend gemacht, dass eine

"Master/Slave"-Anordnung es erlaube, Speicherplatz in den als "Slave" gekennzeichneten Recheneinheiten einzusparen. Obwohl dies in einer "Master/Slave"-Anordnung zwar im Allgemeinen glaubhaft sein kann, ist dies im Kontext von Anspruch 1 nicht notwendigerweise so: die vermeintlich speicherplatzsparende Ausführung kann durch andere Merkmale des Anspruchs beeinflusst oder eingeschränkt werden. Wenn z. B. der "komplette Satz" nach Merkmal f) sehr umfangreich ist, könnte dies den Speicherbedarf der Slave-Einheiten erhöhen, selbst wenn diese Slaves sie nicht alle Algorithmen aktiv ausführen. Auch soll nach Merkmal g) jede Recheneinheit in der Lage sein, den Masteralgorithmus auszuführen. Dies könnte bedeuten, dass auch die Slave-Einheiten über ausreichende Ressourcen verfügen müssen, um diese Aufgabe tatsächlich zu übernehmen. Dies kann wiederum den Speicherbedarf durchaus erhöhen. Nichtsdestotrotz wird die Kammer für die nachstehende Analyse die von der Beschwerdegegnerin für Merkmal i) genannte technische Wirkung heranziehen. Bezüglich der zu formulierenden technischen Aufgabe (s. Punkt 2.7.3 unten) liegt in E1 keinerlei Offenbarung dazu vor, wie die einzelnen ECUs in dieser Hinsicht auszuführen sind.

2.6 Es zeigt sich somit, dass die Unterscheidungsmerkmale in Bezug auf E1 lediglich aneinandergereiht werden, ohne dass sich aus ihrer Kombination eine synergetische Wirkung ergibt: während sich die Merkmale c) und i) auf die Verbindung zwischen den Recheneinheiten der beanspruchten "Steuereinrichtung" bzw. auf die konkrete Ausführung innerhalb einer Recheneinheit beziehen, betrifft die Kombination von Merkmal g) und h) den Betrieb dieser Recheneinheiten.

2.7 Bei einer fehlenden Synergie ist nach der Rechtsprechung die Analyse bezüglich erfinderischer Tätigkeit mittels Teilaufgaben (TA) durchzuführen, die hier jeweils dem Merkmal c), der Merkmalsgruppe g) und h) und dem Merkmal i) zuzuordnen sind. Der vorliegende Fall ist in dieser Hinsicht folgendermaßen gelagert:

2.7.1 Teilaufgabe TA1, betreffend Merkmal c), kann folgendermaßen beschrieben werden: "Auf welche Weise können die Anwendungsprogramme der in E1 offenbarten Kommunikationsumgebung für die Recheneinheiten 135, 140 und 150 entlastet werden?"

2.7.2 Teilaufgabe TA2, bezogen auf die Merkmalskombination g) und h), lässt sich wie folgt darstellen: "Wie kann die Koordinierung zwischen den durch die ECUs gesteuerten Prozessen in E1 nach einem Startvorgang praktisch realisiert werden?"

2.7.3 Teilaufgabe TA3, hinsichtlich Merkmal i), kann wiederum wie folgt formuliert werden: "Auf welche Weise lässt sich der Speicherbedarf der in E1 offenbarten ECU-Anordnung reduzieren?"

2.8 Die Kammer ist der Ansicht, dass der Fachmann aufgrund seines allgemeinen Fachwissens durch die Lösung der einzelnen Teilaufgaben TA1 bis TA3 zum Gegenstand des Anspruchs 1 gelangt wäre, ohne erfinderisch tätig zu werden:

2.8.1 In Bezug auf die technische Aufgabe TA1 wäre dem Fachmann zum Prioritätszeitpunkt des Streitpatents bewusst gewesen, dass die gängigste Art für die Entlastung von Anwendungsprogrammen bei der Netzwerkkommunikation im Zusammenhang mit einer schichtenbasierten Software-Architektur der Einsatz einer Middleware-Technologie als bekanntlich anwendungsneutrale Lösung gewesen wäre, um eine direkte Kommunikation zwischen den entsprechenden

Softwareprozessen zu unterstützen. Unabhängig davon, ob die bloße Verwendung einer schichtenbasierten

Software-Architektur - ohne weitere Implementierungsdetails zu den genauen Aufgaben der hier eingesetzten Middleware-Schicht - überhaupt einen glaubhaften technischen Effekt herbeiführt, wäre der Fachmann aufgrund seines allgemeinen Fachwissens auch mit der Software-Architektur "AUTOSAR®" vertraut gewesen. Diese Architektur war damals bereits ein etablierter Standard in der Automobilindustrie und wurde von vielen Herstellern und Zulieferern eingesetzt. Der Fachmann hätte deren Vorteile für die Kommunikation und Integration von Softwarekomponenten sowie deren flexible Anordnung unmittelbar erkannt. Demzufolge wäre es für den Fachmann naheliegend gewesen, die "AUTOSAR®" Software-Architektur zur Lösung der gestellten Aufgabe heranzuziehen und dadurch zu der "Middleware"-Umgebung aus Merkmal c) zu gelangen.

2.8.2 Bezüglich der technischen Aufgabe TA2 konnte die Beschwerdegegnerin die Kammer nicht davon überzeugen, dass es für den Fachmann keine Lösung geben würde, wobei er, ausgehend von E1, veranlasst gewesen wäre, die Merkmale g) und h) einzubauen. Im Gegenteil, nach Auffassung der Kammer wären dem Fachmann aufgrund seines allgemeinen Fachwissens sogar mehrere Lösungsansätze bekannt gewesen:

1) Zentrale Steuereinheit: Eine dedizierte ECU oder ein Master-Knoten koordiniert den Startvorgang und die Kommunikation der anderen ECUs. Dies könnte durch das Senden von "Wake-up"-Signalen über den Kommunikationsbus oder durch das Aktivieren bestimmter Stromversorgungsleitungen geschehen. Diese zentrale Steuereinheit wäre dann für die Koordination zwischen den anderen ECUs, und somit den dort ablaufenden Prozessvorgängen, verantwortlich.

2) Hierarchischer Startvorgang: ECUs werden in einer bestimmten Reihenfolge gestartet, um entsprechende Abhängigkeiten zu berücksichtigen. Dazu kann die in Punkt 2.5.3 oben gemäß Absätze [0191] bis [0195] von E1 erwähnte Reihenfolge herangezogen werden oder es kann, alternativ, die Reihenfolge nach der Funktion der einzelnen ECUs bestimmt werden. So könnte beispielsweise eine ECU, die für die Motorsteuerung zuständig ist, erst starten, nachdem eine ECU, die für die Kommunikation zuständig ist, bereits hochgefahren ist.

3) Semaphoren: Software-basierte Mechanismen synchronisieren und koordinieren den Zugriff auf gemeinsam genutzte Ressourcen, wie z. B. den Kommunikationsbus oder gemeinsam genutzte Daten.

Auch eine Kombination mehrerer solcher Lösungsansätze wäre für den Fachmann durchaus eine Möglichkeit gewesen, besonders für Fahrzeugklassen mit einer hohen Anzahl an ECUs (beispielsweise 70 oder mehr), wo der Startvorgang typischerweise komplexer ist als bei einem Fahrzeug mit nur wenig ECUs (z. B. weniger als 40). In einem alternativen Szenario könnten so mehrere ECUs, die für kritische Funktionen zuständig sind (z. B. Motorsteuerung, Bremssystem, Kommunikation), wie in Lösungsansatz 1) als "Master" bzw. "Synchronisierer" fungieren und nach dem Einschalten des Fahrzeugs zuerst hochfahren. Diese "Master-ECUs" könnten dann gemäß Lösungsansatz 2) andere, weniger kritische ECUs booten, die von ihren Funktionen abhängig sind. Dem Fachmann wäre es durchaus bewusst gewesen, dass ein solcher "gestaffelter" Start im Vergleich zu einem gleichzeitigen Start eine bessere Verteilung der Ressourcen ermöglicht und auch Konflikte durch "Abhängigkeiten" vermeidet, die auftreten könnten, wenn eine ECU versucht, mit einer anderen zu kommunizieren, die noch nicht bereit ist.

Durch diese Kombination der Lösungsansätze 1) und 2) wäre der Fachmann, nach Ansicht der Kammer, ohne erfinderisch tätig zu werden zu einer Konfiguration gelangt, wo mindestens zwei ECUs zum Ausführen eines Masteralgorithmus zur Koordinierung der Ausführung der übrigen Algorithmen nach dem Booten wie in Merkmal g) ausgebildet sind. Ob die mit der Koordinierung einhergehende Information in den Recheneinheiten mit der "Master"-Rolle selbst vorhanden ist, oder ob diese, wie in Merkmal h), mittels einer Konfigurationsdatei eingelesen bzw. über die "Middleware" zur Verfügung gestellt wird, ist nach Auffassung der Kammer lediglich eine Frage der routinemäßigen Ausgestaltung.

Die Beschwerdegegnerin betonte, dass es bei der Beurteilung der erfinderischen Tätigkeit zu berücksichtigen sei, ob der Fachmann die Erfindung nicht nur hätte durchführen können (z. B. durch eine Auswahl aus den drei von der Kammer herangezogenen Lösungsansätzen), sondern ob er dies auch in der Erwartung getan hätte, die zugrunde liegende technische Aufgabe zu lösen oder eine Verbesserung oder einen Vorteil zu erwarten.

Die Kammer ist jedoch der Ansicht, dass der "Could-Would-Ansatz" im vorliegenden Fall nicht zur Anwendung kommt (siehe z. B. T 894/19, Gründe 3.6). Das liegt daran, dass es sich bei der Konfiguration der Merkmale g) und h) lediglich um eine nicht erfinderische Auswahl aus einer Reihe bekannter und gleichartiger Möglichkeiten handelt. Um alle gleichermaßen naheliegenden Lösungen zu berücksichtigen, reicht es demnach aus, dass der Fachmann die betreffenden Lösungen ohne erfinderische Anstrengungen hätte erkennen können: ein gesonderter Hinweis ist dann nicht erforderlich. Der Fachmann hätte dann eine dieser Lösungen - je nach den vorherrschen Rahmenbedingungen (z. B. Ressourcenverteilung und Vermeiden von Konflikten) - ausgewählt.

2.8.3 Auch bezüglich der technischen Aufgabe TA3 hätte es für den Fachmann aufgrund seines allgemeinen Fachwissens verschiedene Lösungsansätze gegeben:

1) Software-Optimierung: Der Fachmann hätte versuchen können, den Speicherbedarf durch effizientere Programmierung oder Datenkompression zu reduzieren. Auch hätte der Fachmann bei diesem Lösungsansatz versuchen können, die Algorithmen so zu programmieren, dass deren Aufgaben auf mehrere ECUs verteilt werden, um so den Speicherbedarf jeder einzelnen ECU zu reduzieren.

2) Hardware-Reduktion: Eine andere Möglichkeit wäre es, leistungsfähige ECUs mit kleinem Speicher einzusetzen.

3) Datenverarbeitungsmodell-Optimierung: Die Auswahl einer geeigneten Datenverarbeitung-Architektur, wie beispielsweise einer "Master/Slave"-Architektur, kann ebenfalls zu einer Einsparung des benötigten Speicherplatzes führen.

Auch hier hätte der Fachmann zur Lösung der gestellten Aufgabe aus einer Reihe bekannter und gleichartiger Möglichkeiten auszuwählen gehabt. Wäre seine Wahl dabei, den praktischen Rahmenbedingungen entsprechend, auf den dritten Lösungsansatz gefallen, so wäre das Festlegen der Art, wie die Slave-Recheneinheiten gebootet werden, eine routinemäßige Ausführung. Dabei wäre der Fachmann mit dem in Merkmal i) erwähnten Boot-Vorgang der Slave-Einheiten aufgrund seines allgemeinen Fachwissens durchaus vertraut gewesen. Dadurch kann auch das Merkmal i) keine erfinderische Tätigkeit begründen.

2.9 Mithin beruht der Gegenstand von Anspruch 1 wie erteilt nicht auf einer erfinderischen Tätigkeit (Artikel 56 EPÜ). Entsprechend steht der Einspruchsgrund nach Artikel 100 a) EPÜ der Aufrechterhaltung des Streitpatents in der erteilten Fassung entgegen.

3. Hilfsanträge 1 bis 8: Zulassung

3.1 Die Hilfsanträge 1 bis 8 wurden nach Zustellung der Mitteilung nach Artikel 15 (1) VOBK eingereicht (vgl. Punkt II oben). Ihre Zulassung steht somit im Ermessen der Kammer nach Artikel 13 (2) VOBK.

3.2 Unabhängig davon, ob "außergewöhnliche Umstände" im Sinne von Artikel 13 (2) VOBK aufgezeigt wurden und vorliegen, ist die Kammer der Ansicht, dass die Änderungen in den Hilfsanträgen 1 bis 8 prima facie den Einwand der mangelnden erfinderischen Tätigkeit gegen den erteilten Anspruch 1 (siehe Punkt 2 oben) nicht ausräumen können (Kriterium aus Artikel 13 (1) VOBK). Die Merkmale j) bis s) wären nämlich, nach Ansicht der Kammer, dem Fachmann aufgrund seines allgemeinen Fachwissens zum Prioritätszeitpunkt des Streitpatents allesamt bekannt gewesen. Darüber hinaus merkt die Kammer zu den Argumenten der Beschwerdeführerin bezüglich der einzelnen Merkmale l) bis s) Folgendes an:

3.2.1 Der "Steueranschluss" nach Merkmal l) schränkt die "Eignung" der beanspruchten Steuereinrichtung zum "teilweise autonomen Betrieb" nicht notwendigerweise ein, da die Algorithmen nach Merkmal b) dadurch nicht näher präzisiert werden. Das Gleiche gilt für die Merkmale m) und n), da der Ausdruck "betreffen" zu allgemein ist. Ein Hinweis auf eine "weitere Ausfallsicherheit und Robustheit", wie von der Beschwerdegegnerin ins Feld geführt, ist Merkmal n) nicht zu entnehmen.

3.2.2 Bezüglich Merkmal o) argumentierte die Beschwerdegegnerin, dass sich aus diesem Merkmal "eine einfachere Konfiguration für unterschiedliche Plattformen" ergebe, da plattformspezifische Änderungen höchstens auf der "Master-Recheneinheit" vorzunehmen wären.

Die Kammer sieht jedoch keinen Bezug zu "verschiedene[n] Plattformen" in Merkmal o). Auch Merkmal q) liefert keinen Hinweis darauf. Die dort genannten "Plattformeigenschaften" können durchaus mit einer einzigen Plattform in Zusammenhang stehen. Eine "variable Konfiguration" für unterschiedliche Plattformen lässt sich somit aus den Merkmalen o) und q) nicht glaubhaft ableiten.

3.2.3 Die Beschwerdegegnerin führte weiter aus, dass Merkmal o) ebenfalls dazu beitrage, Speicherplatz in den als "Slave" gekennzeichneten Recheneinheiten einzusparen (vgl. die oben in Punkt 2.5.3 für Merkmal i) genannte technische Wirkung).

Auch diese Argumentation vermochte die Kammer aufgrund der Breite des Begriffs "zugeteilt" nicht zu überzeugen. Merkmal o) lässt völlig offen, ob die

Master-Recheneinheit den Slave-Recheneinheiten lediglich beispielsweise Pointer zum "Betriebssystem" bzw. dem "gesamten Satz von Algorithmen" bereitstellt oder diese tatsächlich vollständig in die

Slave-Einheiten geladen werden. Während die erste Alternative in der Tat Speicherplatz sparen könnte, würde die zweite Alternative einen hohen Speicherbedarf verursachen. Da Merkmal o) beide Szenarien umfasst, ist eine Speicherplatzersparnis hier nicht zwingend gegeben.

3.2.4 Hinsichtlich Merkmal p) räumt die Kammer zwar ein, dass eine gewisse Redundanz erkennbar ist, jedoch wäre der Fachmann aufgrund seines allgemeinen Fachwissens mit diesem Konzept durchaus vertraut gewesen.

3.2.5 Des Weiteren braucht die in Merkmal r) genannte "Neuzuordnung" nicht notwendigerweise "dynamisch" zu sein. Sie kann stattdessen manuell oder nach einem festen Zeitplan erfolgen, z. B. während einer Wartung oder Inspektion.

3.2.6 Das Merkmal s) beschreibt zwar eine mehrfache Ausführung von Master-, Slave- und Stromversorgungseinheiten, legt jedoch nicht fest, dass diese Einheiten jeweils identische Funktionen oder Eigenschaften aufweisen. Eine unmittelbare

Fehler-Redundanz ist somit nicht gegeben und eine "verbesserte Robustheit und Ausfallsicherheit" kann daraus nicht zwingend abgeleitet werden.

3.3 Folglich hat die Kammer Hilfsanträge 1 bis 8 nicht in das Verfahren zugelassen (Artikel 13 (2) VOBK).