T 1171/06 (Objekt-orientierte Modellierung/BOSCH) 03-11-2010

Entscheidungsgründe

1. Die Beschwerde ist zulässig, hat aber in der Sache keinen Erfolg.

2. Gegenstand der Erfindung ist die Modellierung eines mechatronischen Systems in einem Kraftfahrzeug, wobei die Gliederung dieses Systems in Komponenten und Kommunikationsbeziehungen gemäß einer Abbildungsvorschrift in eine objektorientierte Modellierungssprache umgesetzt wird.

2.1 Die unabhängigen Ansprüche beider Anträge formulieren, dass die objektorientierte Modellierungssprache vorzugsweise UML sein solle, legen aber gleichzeitig fest, dass diese einen "UML-Stereotyp" aufweisen müsse. Die Kammer ist der Auffassung, dass die objektorientierte Modellierungssprache damit anspruchsgemäß auf UML festgelegt wird. Die Kammer merkt an, dass diese Interpretation für die Beschwerdeführerin die günstigere ist, was die folgende Diskussion angeht.

2.2 Gemäß ihrem jeweiligen Oberbegriff richten sich die unabhängigen Ansprüche beider Anträge auf Verfahren bzw. Vorrichtung "zur Modellierung eines mechatronischen Systems". Wesentlicher Teil eines Modellierungsverfahrens ist es, den zu modellierenden Gegenstand zu analysieren, um seine hinsichtlich des Modellierungszwecks relevanten Elemente, Attribute und Relationen auszuwählen. Dieser Schritt - im vorliegenden Fall z. B. die Spezifikation von Fahrzeugelektronik mittels CARTRONIC - wird vom Gegenstand gemäß Anspruch 1 nicht umfasst, sondern geht diesem voraus und wird von ihm vorausgesetzt (vgl. auch Beschr., S. 5, 3. Absatz). Demnach ist Gegenstand des Anspruchs 1 nicht ein vollständiges Modellierungsverfahren, sondern bestenfalls ein Teil eines solchen. Die Kammer interpretiert Anspruch 1 damit so, dass er sich auf ein "Verfahren (geeignet) zur (Verwendung im Zuge der) Modellierung" bezieht. Eine entsprechende Analyse gilt auch für Anspruch 3.

2.3 Weder das mechatronische System selbst noch seine Komponenten werden in den Ansprüchen näher spezifiziert. Bei den Kommunikationsbeziehungen wird in den Ansprüchen des Hauptantrags beispielhaft zwischen "Abfrage", "Aufforderung" und "Auftrag" unterschieden. Dabei handelt es sich beim Begriff "Aufforderung" im Lichte der Beschreibung ganz offenbar um einen Schreibfehler (vgl. z. B. S. 7, Zeilen 18-20, sowie Tabelle auf S. 8), der im Hilfsantrag zu "Anforderung" korrigiert ist.

2.4 Nach Auffassung der Kammer geht aus dem Anspruchswortlaut nicht eindeutig hervor, ob die beanspruchte Gliederung eine faktische Beschränkung des zu modellierenden Systems darstellt (nämlich auf ein solches, das die geforderten Komponenten und Kommunikationsbeziehungen aufweist), oder ob sie ein Modell bezeichnet, das das mechatronische System mittels der geforderten Komponenten und Kommunikationsbeziehungen beschreibt. Da aber die Konstrukte einer Modellierungssprache, in die besagte Komponenten und Beziehungen anspruchsgemäß mittels "Abbildungsvorschrift" umgesetzt werden sollen, eine Beschreibung des mechatronischen Systems darstellen, erscheint es naheliegender anzunehmen, dass auch Ausgangspunkt dieser Abbildung eine Beschreibung ist.

Diese Interpretation wird durch die Anmeldung bestätigt. Darin wird CARTRONIC als ein "Ordnungskonzept" bezeichnet, das u. a. die beanspruchten Kommunikationstypen vorsieht (vgl. Tabelle auf S. 8) und mit dem Modelle - also Beschreibungen - von mechatronischen Systemen erstellt werden (S. 11, letzter Absatz).

2.5 Intentionsgemäß bezieht sich die Erfindung somit auf Verfahren und Vorrichtung zur Abbildung eines CARTRONIC-Modells in die objektorientierte Modellierungssprache UML (vgl. auch S. 5, vorletzter Absatz; S. 12, letzter Absatz).

Diese im Bescheid der Kammer angesprochene Interpretation hat die Beschwerdeführerin nicht bestritten. Deshalb wird sie im Folgenden zugrunde gelegt, wobei weitere Fragen der Klarheit der CARTRONIC- bzw. UML-spezifischen Terminologie (insbes. "Abfrage", "Anforderung", "Auftrag"; "UML-Sprache", "UML-Stereotyp") oder der konkreten Bezeichner (<> und <>) bzw. deren präzise Bedeutung für diese Entscheidung offen bleiben können.

3. In der Entscheidung T 354/07 hat die dort zur Entscheidung berufene Kammer ausgeführt (vgl. Leitsatz), dass "[k]onzeptionelle Verfahren und Meta-Methoden der Softwareerstellung ... in der Regel keine für die Patentierbarkeit relevanten technischen Merkmale auf[wiesen] und daher ... die erfinderische Tätigkeit nicht begründen [könnten], es sei denn, dass im Einzelfall ein direkter Kausalzusammenhang mit einem für die Lösung eines technischen Problems relevanten technischen Effekt nachgewiesen werden [könne]". Weiter wird ausgeführt (vgl. Gründe 4), dass die "Konzipierung ... komplexer Systeme .. zwar ingenieurmäßiges Handeln und die Anwendung technischer Fachkenntnisse [erfordere], der unmittelbar angestrebte und erzielte Erfolg ... jedoch nicht die technische Lösung eines technischen Problems, sondern" - z. B. - "ein Daten-, Prozess- und/oder Funktionsmodell [sei]".

3.1 Der in T 354/07 diskutierte Anspruch 1 richtet sich auf ein "Verfahren zur Erzeugung von Softwareprogrammen (31) mittels einer EDV-Anlage", wobei, inter alia, das Softwareprogramm eine "Steuerungs- und/oder Regelungsaufgabe" zu bearbeiten hat, und mittels eines plattformunabhängigen "ersten Funktionsplans (7) ein zweiter Funktionsplan erstellt wird, der an spezifische Anforderungen [einer] Zielplattform angepasst ist". Funktionspläne im Sinne der Anmeldung seien dabei "grafische Darstellungen eines Modells des zu erstellenden Steuerungs- und Regelungssystems auf verschiedenen Abstraktionsebenen, ohne dass eine Wechselwirkung mit dem System oder den Steuerungsprozessen stattfände" (vgl. Gründe 7).

3.2 Dieser Gegenstand ist dem vorliegend beanspruchten Verfahren in wesentlichen Punkten sehr ähnlich. Beide Verfahren betreffen die Modellierung vergleichbarer technischer Systeme. Beide Verfahren beziehen sich auf zwei Modelle bzw. deren Darstellungen in einer typischerweise grafischen Notation, sowie auf die Abbildung eines dieser Modelle in das andere.

4. Die Kammer schließt sich im Folgenden den oben in Ziffer 3. zitierten Ausführungen der Entscheidung T 354/07 an.

4.1 Dementsprechend ist zu prüfen, ob für das beanspruchte Verfahren gemäß Anspruch 1 beider Anträge ein Kausalzusammenhang mit einem für die Lösung eines technischen Problem relevanten technischen Effekts nachgewiesen werden kann.

4.2 Die vorliegende Anmeldung benennt den zu modellierenden Gegenstand zwar nicht nur als unspezifisches Steuerungs- oder Regelungssystem, sondern - enger - als ein "mechatronisches System in einem Kraftfahrzeug", aber auch diese Angabe ist sehr generisch und lässt keinen Rückschluss auf eine konkrete Modellierungsaufgabe oder ein in diesem Zusammenhang betrachtetes technisches Problem zu.

4.3 In der vorliegenden Anmeldung ist - im Unterschied zum Gegenstand aus T 354/07 - nicht offenbart, dass die Umsetzung zwischen den Modellen automatisch ("mittels einer EDV-Anlage") erfolgen würde. Ansprüche 1 und 2 beider Anträge nehmen keinen Bezug auf irgendeine Computerunterstützung, während Anspruch 3 zwar auf eine "Vorrichtung" gerichtet ist, aber darin offen bleibt, welche Verfahrensschritte durch die Vorrichtung unterstützt werden oder wie.

4.4 In der vorliegenden Anmeldung geht es auch nicht - wiederum im Unterschied zum Gegenstand aus T 354/07 - um die automatische Erzeugung von Programmcode aus einem Modell, wie der Vertreter in der mündlichen Verhandlung offenbar bestätigt hat (vgl. Protokoll vom 8.3.2006, Abschnitt 2.1, vorletzter Punkt). In der Tat sind weder CARTRONIC (in der Beschreibung als "präformal" bezeichnet, S. 11, Zeile 9 von unten) noch UML ohne Weiteres zur automatischen Erzeugung von Programmcode geeignet.

4.5 Die Anmeldung bezieht sich auf den Software-Lebenszyklus, der so unterschiedliche Phasen wie Problemanalyse und Systemspezifikation, aber auch Implementierung, Realisierung und Pflege umfasst. In diesem Zusammenhang, so wird offenbart, ermögliche es die objektorientierte Vorgehensweise - unter Verwendung z. B. von UML - "Anteile und Konzepte" phasenübergreifend wiederzuverwenden (Beschr., S. 10, Z. 9 ff.). Dabei unterstützten grafikbasierte Modelle als Dokumentationselemente unter anderem die Kommunikation zwischen den an der Entwicklung beteiligten Personengruppen, darunter so unterschiedliche wie Fahrzeughersteller oder Softwareentwickler, aber auch Manager oder Endbenutzer (S. 4, letzter Absatz - S. 5, 1. Absatz). Nach Überzeugung der Kammer kommt einem Modell aber kein technischer Effekt dadurch zu, dass es der Dokumentation des Systems dient oder die Kommunikation darüber vereinfacht, selbst wenn das System selbst ein technisches ist.

4.6 Für UML sind eine Vielzahl von kommerziellen Software-Entwicklungswerkzeugen verfügbar, und es ist ein erklärtes Ziel der Anmeldung, diese Werkzeuge für in CARTRONIC spezifizierte Modelle verfügbar zu machen (vgl. Beschr., S. 5, 3. Absatz, sowie S. 19, letzter Satz). Diese Werkzeuge sind aber im Einzelnen weder beansprucht noch offenbart. Ob durch die bestimmungsgemäße Verwendung eines solchen bekannten Werkzeugs auf ein nach UML umgesetztes CARTRONIC-Modell ein technischer Effekt entsteht, kann daher offen bleiben.

4.7 Die Kammer kann somit keinen für die Lösung eines technischen Problems relevanten technischen Effekt nachweisen, der mit einem der beanspruchten Verfahren in einem Kausalzusammenhang stehen würde. Auch die Beschwerdeführerin hat angesichts dieses mit der Ladung zur mündlichen Verhandlung von der Kammer erhobenen Einwands keinen solchen technischen Effekt benannt.

4.8 Demnach kommt die Kammer zu dem Ergebnis, dass der Gegenstand der Ansprüche 1 und 2 beider Anträge nicht technisch, sondern als Verfahren für eine konzeptionelle oder gedankliche Tätigkeit unter Artikel 52 (2c) (3) EPÜ von der Patentierbarkeit ausgeschlossen ist.

4.9 Der Gegenstand des Anspruchs 3 beider Anträge, der sich jeweils auf eine Vorrichtung bezieht, wird, nach ständiger Rechtsprechung (vgl. z. B. T 258/03, Gründe 3.7; Amtsblatt EPO, 2004, 575) als Erfindung im Sinne von Artikel 52 (1) EPÜ angesehen. Jedoch wird allein durch die unspezifische Angabe einer "Vorrichtung zur" Unterstützung eines nicht-technischen Verfahren kein erkennbarer technischer Beitrag etwa über irgendeinen zum Prioritätszeitpunkt bekannten handelsüblichen PC hinaus geleistet. Somit fehlt dem Gegenstand des jeweiligen Anspruchs 3 eine erfinderische Tätigkeit, Artikel 56 EPÜ 1973.

5. Da somit keiner der beiden Anträge den Erfordernissen des EPÜ entspricht, ist die Beschwerde zurückzuweisen.