T 0517/16 (Quellcodeerzeugung/ALLGEIER) 18-11-2020

Entscheidungsgründe

Berücksichtigung der Anträge IB, IIB, IC, und IIIB

1. Mit der Beschwerdebegründung wurden unter anderem die der Entscheidung zugrundeliegenden Anträge erneut vorgelegt, darunter die von der Prüfungsabteilung nicht zugelassenen Hilfsanträge II und III.

2. In der Entscheidung wird festgestellt, dass die Hilfsanträge II und III "prima facie" die gleichen Offenbarungsmängel wie der Hauptantrag aufweisen.

2.1 Zum Hauptantrag führt die Prüfungsabteilung in dieser Hinsicht insbesondere aus (vgl. Seite 4, 4. Absatz):

"Wegen der mangelnden Erläuterungen [in der Beschreibung] kann der Fachmann nicht ohne erfinderisches Zutun bestimmen, welche Befehle zu erzeugen sind, um zu erreichen, dass der Quellcode nur die Prozessdatei, die für das dazugehörende Subjekt bestimmt sind, analysiert."

2.2 Die Prüfungsabteilung erläutert weder, welche Merkmale die zwei Hilfsanträge dem Hauptantrag hinzufügen, noch diskutiert sie, ob diese tatsächlich oder möglicherweise geeignet sein könnten, dem Einwand unter Artikel 83 EPÜ 1973 zu begegnen. Gleichzeitig stellt die Prüfungsabteilung (ohne die "prima facie"-Einschränkung) fest: "Die Beschreibung ist die gleiche und deswegen gilt der gleiche Einwand gemäß Artikel 83 EPÜ". Diese Bemerkung scheint zu implizieren, dass es bei diesem Einwand auf die neuen Merkmale gar nicht ankäme. Auch das allerdings führt die Prüfungsabteilung nicht aus. Insofern ist die Kammer der Ansicht, dass die Begründung für den Offenbarungsmangel unzureichend ist, unabhängig davon, ob der Einwand "prima facie" erhoben wurde, oder nicht, Regel 68(2) EPÜ 1973.

2.3 Die nicht zugelassenen Anträge II und III sind mit der Beschwerde erneut vorgelegt worden. Artikel 12(4) VOBK 2007 lässt der Kammer ein Ermessen darüber, diese Anträge im Beschwerdeverfahren zu berücksichtigen, soweit diese im erstinstanzlichen Verfahren nicht zugelassen worden sind. Die Kammer ist der Ansicht, dass Artikel 12(4) VOBK 2007 implizit voraussetzt, dass dieses Ermessen im erstinstanzlichen Verfahren korrekt ausgeübt worden ist. Das ist nach Ansicht der Kammer mangels Begründung jedoch nicht der Fall.

2.4 Die Kammer weist auch auf das Folgende hin. Soweit die Prüfungsabteilung der Meinung war, dass "der gleiche Einwand gemäß Artikel 83 EPÜ" für die Hilfsanträge II und III gilt wie für den Hauptantrag, hat sie für diese Hilfsanträge erschöpfend festgestellt, dass Artikel 83 EPÜ einer Erteilung auf Basis der Hilfsanträge II und III entgegensteht (vgl. Artikel 97(2) EPÜ). Eine ähnlich knappe sachliche Analyse durch Verweis auf den Hauptantrag hat der Prüfungsabteilung für die sachliche Zurückweisung des zugelassenen Hilfsantrags I tatsächlich genügt (vgl. Punkt 3 der Gründe). Die Kammer ist unter diesen Umständen der Ansicht, dass nach der sachlichen Analyse der Hilfsanträge II und III kein weiteres Nichtzulassungsermessen bestanden hat (vgl. T 2026/15, Gründe 2.5).

2.5 Damit waren die (inzwischen zurückgenommenen) Hilfsanträge II und III gemäß Artikel 12(4) i.V.m. 12(1) und (2) VOBK 2007 in der Beschwerde zu berücksichtigen und sind in der vorläufigen Meinung der Kammer diskutiert worden.

3. Hauptantrag B sowie Hilfsanträge IB bis IIIB unterschei­den sich in Anspruch 1 vom früheren Hauptantrag und den Hilfsanträgen I bis III dadurch, dass die erzeugten Quellcodedateien nicht mehr "Befehle zum Austausch von Daten mit Quellcodedateien weiterer Subjekte" enthalten müssen, sondern solche "zum Austausch von Daten mit weiteren Subjekten". Diese Änderung ist eine Erwiderung auf einen Klarheitseinwand und Änderungsvorschlag der Prüfungsabteilung (vgl. Punkt 2.1 der Gründe). Durch ein offensichtliches Versäumnis der Beschwerdeführerin fehlte die genannte Änderung jedoch in Hilfsantrag IIIB wie mit der Beschwerdebegründung vorgelegt und wurde im in der mündlichen Verhandlung vorgelegten Hilfsantrag IIIB nachvollzogen. Die Kammer kann keinen Grund erkennen, diesen verspäteten Hilfsantrag nicht zu berücksichtigen, da andernfalls das ergänzte Merkmal im (nun zurückgezogenen) Hilfsantrag III ohnehin hätte diskutiert werden müssen, Artikel 13(2) VOBK 2020. Die Kammer lässt die Frage offen, ob Hauptantrag B und Hilfsanträge IB und IIB hätten schon früher vorlegt werden können und sollen, Artikel 12(4) VOBK 2007, insbesondere da die Beschwerdeführerin die mit "B" markierten Anträge als Ersatz der nicht so markierten Anträge vorgelegt und diese nach Zulassung jener auch zurückgenommen hat.

4. Anspruch 1 des Hilfsantrags IC basiert auf Ansprüchen 1 und 2 des Hilfsantrags IB. Die Gründe der Beschwerdeführerin, warum dieser Hilfsantrag jedoch erst wenige Tage vor mündlichen Verhandlung vorgelegt worden ist, können die Kammer nicht überzeugen.

4.1 Selbst wenn die Kammer einen anderen Einwand als die Prüfungsabteilung erhoben hat, so wäre genügend Zeit gewesen, eine entsprechende Änderung etwa mit der ersten Erwiderung der Beschwerdeführerin am 19. Oktober 2020 vorzulegen.

4.2 Die Kammer sieht darüber hinaus eine Unklarheit darin, ob die Quellcodedatei, die "mit" einem Befehl erzeugt wird, "durch" diesen erzeugt wird, oder ob sie diesen Befehl enthält. Die Kammer widerspricht an dieser Stelle ausdrücklich der Beschwerdeführerin darin, dass die geänderten Ansprüche keinen Anlass zu neuen Einwänden liefern könnten, weil sie schon in der ursprünglichen Patentanmeldung enthalten waren. Aus der Tatsache, dass die Entscheidung auf einem spezifischen Mangel der jeweiligen Ansprüche 1 beruht, folgt nicht, dass keine weiteren Mängel bestehen, insbesondere nicht, was die abhängigen Ansprüche betrifft.

4.3 Schließlich ist in der Ladung als ein Kernproblem der beanspruchten Erfindung die Frage, wie die Erzeugung "separate[r] Quellcodedatei[en]" auszulegen und welche Wirkung ihr zuzuschreiben ist. Die Änderungen am neuen Hilfsantrag IC sind nicht geeignet, die von der Be­schwer­deführerin gewünschte Auslegung sicherzustellen, wie in der folgenden Analyse klar werden wird.

4.4 Daher übt die Kammer ihr Ermessen unter Regel 13(2) VOBK 2020 dahingehend aus, Hilfsantrag IC nicht zuzulassen.

Die Erfindung

5. Die Anmeldung bezieht sich insbesondere auf ein Verfahren zur automatischen Erzeugung von Quellcode (z.B. in Java) für komplexe Prozesse, technischer oder betriebswirtschaftlicher Art, das, anders als bekannte Verfahren, umfangreichen, fehlerbehafteten und langsamen Code erzeugen würden (vgl. die ursprüngliche Beschreibung, Seite 1, letzter Absatz, bis Seite 2, Absatz 1; Seite 6, vorletzter Absatz; Seite 12, Absatz 3 und Seite 21, vorletzter Absatz).

5.1 Die Anmeldung bezeichnet als "Subjekte" diejenigen Komponenten (auch "Akteure" genannt) des Prozesses, seien es Personen, Geräte, Teile von Geräten oder "sonstige Stationen im Prozess", die entweder mit anderen Komponenten oder Akteuren kommunizieren und/oder Handlungen ausführen (Seite 6, vorletzter Absatz). Ein Beispiel für die grafische Definition eines Prozesses und seiner Komponenten/Akteure/Subjekte gibt Abbildung 6 (vgl. auch die Beschreibung, Seite 7).

5.2 Beschreibungsgemäß stehen ein Prozessmanager und ein Subjektmanager bereit, mit denen ein Benutzer solche "Prozessdiagramme" erstellen kann. Aus diesen wird automatisch eine "Prozessdatei in einer Metasprache" erzeugt (vgl. Seite 8 bis Seite 10, Absatz 3). Eine solche XML-Datei ist beispielhaft in Abbildung 7 dargestellt.

5.3 Die Anmeldung offenbart, dass "für jedes Subjekt ein separater Quellcode" (eine "separate Quellcodedatei" nach Anspruch 1) erzeugt werde, und das "Hierdurch [...] sehr komplexe Prozesse in einzelne Teilprozesse zerlegt" würden, "für welche einfach ein Quellcode erzeugbar" sei (Seite 12, Absatz 5). Dazu werde beispielsweise (vgl. Abbildung 3) für jedes Subjekt eine Java-Klasse mit einer Methode "run" angelegt (Seite 13, Absätze 4-6, sowie Seite 14, Absatz 3 ff.).

5.4 Es wird auch beschrieben, dass die einzelnen Quell­codedateien auf unterschiedlichen Computern in einem Netzwerk ausführbar seien (Seite 3, letzter Absatz), sowie, dass im Quellcode Befehle vorgesehen sein können, die mittels des von Hoare 1974 eingeführten "Monitorkonzepts", das "aktive Warten"/"busy waiting" der separaten Programme vermieden werde (Absatz zwischen Seiten 15 und 16).

Klarheit und Anspruchsauslegung, Artikel 84 EPÜ 1973

6. Anspruch 1 aller Anträge richtet sich auf die Erzeugung eines Computerprogramms "zur Ausführung bzw. Simulation eines Prozesses". Auf Rückfrage (vgl. Ladungszusatz, Punkt 6) erläutert die Beschwerdeführerin, dass damit unterschieden sein soll, ob ein "Prozess", bspw. ein Workflow in einem Unternehmen, im Realbetrieb verwendet oder eben nur "simuliert", z.B. getestet, wird. Die Kammer akzeptiert mit dieser Erklärung die Zweckbestimmung als klar, merkt aber an, dass für die beanspruchte Erzeugung von Quellcode nicht von Bedeutung ist, ob der Prozess im Real- oder Testbetrieb ausgeführt wird. Jedenfalls handelt es sich bei der beanspruchten "Simulation" nicht um die Nachbildung eines technischen Systems, so wie sie etwa in der T 1227/05 oder in der derzeit vor der großen Beschwer-dekammer anhängigen Sache G 1/19 betrachtet wird.

7. Die Prüfungsabteilung ist der Ansicht, dass Anspruch 1 aus drei Gründen unklar sei. Der Begriff "Subjekt" sei vage, das "automatische Erzeugen eines Quellcodes" eine unzulässige Definition durch das zu erreichende Ergebnis, und der "Austausch von Daten mit Quellcodedateien weiterer Subjekte" ein typografischer Fehler (Entscheidung, Punkt 2.1 der Gründe).

7.1 Der letztgenannte Einwand ist in allen anhängigen Anträgen behoben.

7.2 Die Kammer hält den Begriff "Subjekt" zwar für in der Tat sehr breit, aber klar.

7.2.1 Als Subjekte werden alle Komponenten eines Prozesses bezeichnet, die einer Prozessdefinition zufolge eine eigenständige Funktion haben (vgl. Seite 6, vorletzter Absatz, der Beschreibung). Allerdings definiert dieser Absatz den Begriff des "Subjekts" nur als Bestandteil des Prozesses, nicht jedoch als Teil der Prozessbe­schreibung oder des daraus erzeugten Quellcodes, wenn auch "für" jedes Subjekt ein Block der Prozessbeschrei­bung und eine separate Quellcodedatei vorgesehen ist.

7.2.2 In diesem Zusammenhang betont die Beschwerdeführerin zweierlei. Der Begriff der "subjektorientierten" Programmierung, wie ihn zwei im Recherchenbericht zitierten Dokumente gebrauchen, habe nichts mit der intendierten Bedeutung von "Subjekten" zu tun. Und "Subjekte" seien zwar mittels objektorientierter Programmierung darstellbar, aber nicht jedes "Objekt" in diesem Sinne sei auch ein "Subjekt", da es passive Objekte gebe, Subjekte hingegen in der Beschreibung als "Akteure" definiert seien.

7.3 Die Beschwerdeführerin weist darauf hin, dass es schon im Stand der Technik bekannt gewesen sei, "aus einer Prozessdatei automatisch einen Quellcode zu erzeugen" (Beschwerdebegründung, Seite 4, letzter Absatz, mit Bezug auf zwei in der Anmeldung zitierte Dokumente). Die Kammer ist ebenfalls der Meinung, dass der einschlägige Fachmann grundsätzlich gewusst hätte, was mit dieser Formulierung gemeint ist.

7.3.1 Gleichzeitig hängt es von der spezifischen Art der Prozessdefinition ab - also der verwendeten grafischen Modellierungs- oder Programmiersprache -, ob die automatische Erzeugung eines Quellcodes aus einem Prozessdiagramm im Allgemeinen oder im Besonderen möglich ist. Weder der Anspruch noch die Beschreibung definieren die betrachteten Prozessdiagramme, den erzeugten Quellcode, oder Details der beanspruchten Übersetzung von einem ins andere. Beispiele für das eine oder das andere (siehe insbesondere Abbildungen 5-7) können nicht als Definition dieser Begriffe, geschweige denn als signifikante Einschränkung der Ansprüche dienen.

7.3.2 An dieser Stelle weist die Kammer darauf hin, dass die oben genannten Anlagen 1-5, alle nachveröffentlicht, nicht geeignet sind, die Beschreibung zu ergänzen und/oder die Auslegung der Ansprüche zu beschränken. Die Beschwerdeführerin hat zur einschlägigen Relevanz dieser Dokumente in der mündlichen Verhandlung auch nicht vorgetragen.

7.3.3 In der Verhandlung erläutert die Beschwerdeführerin durch Verweis auf zwei Dokumente, die schon im Prüfungsverfahren (mit Schreiben vom 20. August 2008) vorgelegt wurden, welche Interpretation von Prozessen, Subjekten, Kommunikation und Prozessbeschreibungen vorschwebt und benennt dabei insbesondere "BPMN" und "BPEL" ("Business Process Modelling Notation" und "Business Process Execution Language"). Allerdings verzichtet die Beschwerdeführerin auf den Antrag, diese Dokumente, die per se ohnehin nachveröffentlicht sind, formal in das Beschwerdeverfahren einzuführen, wenn die Kammer anerkennt, dass es für den Fachmann schwierig sei, aus einer allgemeinen Prozessbeschreibung wegen der darin enthaltenen Parallelität ausführbaren Code zu erzeugen. Die Kammer stimmt dieser Aussage zu, wenn sie auch anmerken muss, dass die Parallelität nicht die einzige Schwierigkeit in der Codeerzeugung darstellt.

7.3.4 Ungeachtet der Details der genannten Dokumente hätte der Fachmann keinen zwingenden Anlass gesehen, angesichts der Beschreibung die beanspruchte Prozessbeschreibung als eine in BPMN oder den erzeugten Quellcode als BPEL zu interpretieren, oder irgendeine spezifische Variante oder Verwandte von diesen. Die Beschreibung jedenfalls gibt darauf keinerlei Hinweis.

7.3.5 Damit die verwendete Formulierung als klar gelten kann, muss man einen Fachmann annehmen, der sich mit grafischen Modellierungssprachen (z.B. UML), objekt-orientierten oder anderen Programmiersprachen (z.B. Java) und der Erzeugung von Quellcode aus Prozessdia-grammen der abgebildeten Art sehr gut auskennt. Die Beschwerdeführerin scheint dem zuzustimmen (vgl. Beschwerdebegründung, Seite 9, Absatz 4).

8. Die Beschwerdeführerin ist der Ansicht, dass jede "sepa­rate Quellcodedatei" - wie im Hauptantrag B und im Hilfsantrag IB beansprucht - zwingend separat ausführ­bar sei. Die Kammer stimmt dem nicht zu. Jede Biblio­thek, die in Quellcode vorliegt, enthält eine oder mehrere Quellcodedateien, die jedoch in der Regel nicht separat ausführbar sind. Die Kammer ist übrigens der Ansicht, dass das für den Fachmann unmittelbar klar und ein weiterer Bezug auf die Beschreibung nicht angezeigt ist. Daher kann offenbleiben, ob die Feststellungen der Beschreibung, dass der "Quellcode eines jeden Subjekts jeweils ein separates Programm" darstellt (Absatz zwi­schen Seiten 20 und 21) und dass es durch die Erzeu­gung "separate[n] Quellcodes" möglich ist, "sehr kom­plexe Prozesse in einzelne Teilprozesse" zu "zerle­g[en]" (Seite 12, vorletzter Absatz) einen Schluss über die beanspruchten "Quellcodedateien" erlaubt.

Hinreichende Offenbarung, Artikel 83 EPÜ 1973

9. Der Einwand der Prüfungsabteilung unter Artikel 83 EPÜ 1973 entspricht im Kern demjenigen unter Artikel 84 EPÜ 1973. Ebenso die Erwiderung der Beschwerdeführerin, dass es keiner weitergehenden Definition bedürfe, da das Notwendige dem Fachmann schon aus dem in der Beschreibungseinleitung genannten Stand der Technik bekannt sei (Beschwerdebegründung, Seite 9, Absatz 3). Für die Nacharbeitung des einzig weiteren Erfindungs-merk­mals, demgemäß für jedes Subjekt eine "separate Quellcodedatei" erzeugt werde (Beschwerdebegründung, Seite 5, Absatz 2) benötige der Fachmann keine weiteren Erläuterungen aus der Beschreibung (Seite 9, Absatz 4).

9.1 Im Besonderen bemängelt die Prüfungsabteilung u.a., dass die Beschreibung nicht spezifiziere, "wie der Teil der Prozessdatei, der von einem Subjekt zu interpretie­ren ist, zu finden" sei (Entscheidungsbegründung, Seite 4, Absatz 3).

9.2 Die Beschwerdeführerin führt demgegenüber an, dass die Prozessdatei für jedes Subjekt einen entsprechenden Datensatz vorsehe (Beschwerdebegründung, Seite 12, Absatz 3), der natürlich leicht auffindbar wäre. Auch ohne einen solchen Hinweis, ist die Beschwerdeführerin der Meinung, dass der Fachmann ohne Weiteres - also insbesondere ohne eine weitergehende Beschreibung zu benötigen - nur die zu einem Subjekt gehörenden Information aus der Prozessdatei lesen würde, um den entsprechenden Quellcode zu erzeugen (Seite 13, Absatz 2, bis Seite 14, Absatz 1).

10. Die Kammer sieht, wie die Beschwerdeführerin, keinen Offenbarungsmangel darin, dass nicht im Einzelnen erläutert wird, wie der Teil der Prozessdatei bestimmt wird, aus dem je Subjekt die separate Quellcodedatei erzeugt wird.

10.1 In einer ("objekt-orientierten") Modellierung wie der in Abbildung 6 dargestellten und teilweise beanspruchten sind die Informationen schon nach "Subjekt" gruppiert, und gleiches gilt für den XML-Code in Abbildung 7. Für den Fachmann wäre es dementsprechend ein Leichtes, die subjekt-spezifischen Abschnitte in der Prozessdatei aufzufinden. Es mag sein, dass diese Abschnitte nicht ausreichen, um den Quellcode für ein Subjekt zu erzeugen. Da der Fachmann in jedem Einzelfall hingegen die verwendete - aber vorliegend nicht spezifizierte - Modellierungs- und Programmiersprache kennt, wird er nach Einschätzung der Kammer wissen, wo ggf. subjekt-spezifische Abschnitte der Prozessbeschreibung aufzufinden wären.

Erfinderische Tätigkeit, Artikel 56 EPÜ 1973

11. Die Kammer hat Verständnis für den Einwand nach Artikel 83 EPÜ 1973 der Prüfungsabteilung, teilt ihn aber nicht. Dem Grundsatz nach ist sie der Ansicht, dass der Fachmann durchaus weiß, wie Quellcode aus einer "Prozessdatei" zu erzeugen wäre, obgleich das im Einzelfall noch sehr kompliziert oder sogar unmöglich sein kann.

11.1 Gleichzeitig ist sie der Meinung, dass diese Frage offenbleiben kann, da es der Erfindung an erfinderischer Tätigkeit mangelt.

11.2 Die Entscheidung stützt sich ausschließlich auf Artikel 83 und 84 EPÜ 1973 und diskutiert keinen Stand der Technik. Gleiches gilt auch für die den Ladungszusatz der Prüfungsabteilung vom 11. Mai 2015, der einen Einwand mangelnder erfinderischer Tätigkeit ohne Bezug auf druckschriftlichen Stand der Technik erhebt (Seite 5).

11.3 Obgleich die Beschwerdeführerin auf ihren Vortrag zur erfinderischen Tätigkeit im Blick ­auf eine konkrete Druckschrift verweist (Beschwerdebegrün­dung, Seite 15), verzichtet die Kammer auf eine detaillierte Diskussion von beidem. Sie erinnert aber daran, dass die folgende Diskussion einen sehr kompetenten Fachmann mit umfangreichem Fachwissen voraussetzen muss.

Generischer Stand der Technik

12. Wie oben unter Punkt 8.3.5 schon angedeutet, geht die Kammer davon aus, dass der Fachmann zum relevanten Zeitpunkt von Prozessbeschreibungssprachen (z.B. UML) sowie deren Umsetzung in textuellen Quellcode einer geeigneten Programmiersprache wusste. Konkrete Details werden dabei nicht angenommen. Der Annahme in dieser Allgemeinheit ist die Beschwerdeführerin weder schriftlich noch mündlich entgegengetreten.

13. Aller­dings legt auch der Anspruchswortlaut solche Details nicht fest. Insbesondere beispielsweise nicht, ob die Prozessbeschreibungs­sprache bestimmte "UND-Konnektoren" wie "Splits" oder "Joins" aufweist (vgl. Schreiben der Beschwerdeführerin vom 19. Oktober 2020, Seite 6, Absatz 2), oder ob solche Konnektoren, sollten sie vorliegen, bei der Prozessbeschreibung tatsächlich verwendet werden oder nicht. Er legt auch nicht fest, dass "Subjekte" nur einen "linearen Kontrollfluss" haben können (vgl. ebda., Seite 7, Absatz 4), noch irgendein Detail der Übersetzung selbst.

Hauptantrag B

14. Bei richtiger - und notwendigerweise sehr breiter - Auslegung unterscheidet sich Anspruch 1 vom angenommenen Stand der Technik dadurch, dass für jedes Subjekt eine separate Quellcodedatei erzeugt wird.

14.1 Die Beschwerdeführerin behauptet, dass im Stand der Technik ein Prozess "nach seinen Zuständen" dargestellt werde, was oft zu komplexem Quellcode führe, während erfindungsgemäß die "auszuführenden Aktionen" den "jeweiligen Subjekten zugeordnet" würden.

14.2 Die Kammer interpretiert diesen Einwand so, dass im Stand der Technik der "Prozess" prozedural modelliert wird, erfindungsgemäß hingegen "objekt-orientiert".

14.3 Die Kammer erinnert erneut daran, dass objekt-orientierte Modellierungssprachen bekannt sind (z.B. UML), und für den Fachmann als bekannt angenommen werden müssen, wenn er denn in der Lage sein soll, Abbildung 6 der Beschreibung zu verstehen.

14.4 Die Kammer sieht es als für einen solchen Fachmann unmittelbar naheliegend an, eine objekt-orientierte Prozess­datei (selbst wenn diese einen "subjekt-orientierten Prozess" darstellen sollte) in Code einer objekt-orien­tierten Sprache zu übersetzen, da sich Modellierungs­sprache und Programmiersprache dann vergleichsweise ähnlich sind und die Übersetzung einfacher sein wird. Aus dem gleichen Grund erscheint es unmittelbar naheliegend, jedes "Subjekt" (oder "Objekt") im Modell in ein programmiersprachliches Objekt zu übersetzen.

14.5 Ob darüber hinaus der Quellcode für jedes Objekt in einer separaten Datei abgelegt wird, ist dabei nebensächlich. Viele kleine oder wenige große Dateien haben für den Fachmann bekannte Vor- und Nachteile, etwa für die Entwicklung oder die Kompilierung des Quellcodes. Der erzeugte Objektcode hingegen hängt von dieser Trennung nicht ab.

15. In der Beschreibung wird behauptet, die beanspruchte Erfindung führe zu weniger umfangreichem, weniger fehlerbehaftetem und schnellerem Quellcode.

15.1 Die Kammer hält das für den beanspruchten Gegenstand in seiner vollen Breite für nicht plausibel und in der Beschreibung auch nicht plausibel gemacht. Auch in der mündlichen Verhandlung konnte der Vortrag der Beschwerdeführerin die Kammer in dieser Hinsicht nicht überzeugen.

15.2 Die Kammer hält es für naheliegend anzunehmen, dass die Komplexität des erzeugten Quellcodes u.a. davon abhängt, in welcher Form die Prozessdatei vorliegt. Eine prozedural definierte Prozessdatei wird vermutlich zu einfacherem Quellcode führen, wenn eine prozedurale Programmiersprache gewählt wird. Auch die Annahme, dieser Quellcode ist dann weniger fehlerbehaftet und schneller, scheint gerechtfertigt. Schon damit aber scheitert die Behauptung, die Erfindung würde die behaupteten Wirkungen i.a. haben.

15.3 Diese Wirkungen müssen daher bei der Bewertung der erfinderischen Tätigkeit unberücksichtigt bleiben.

16. Was die weiter beanspruchten Schritte (Beschreiben und Speichern) betrifft, verweist die Kammer auf die Analyse der Prüfungsabteilung (Ladungszusatz vom 11. Mai 2015, Punkt 7.2), der sie insoweit zustimmt.

17. Zusammenfassend kommt die Kammer zu dem Ergebnis, dass Anspruch 1 des Hauptantrags B und des Hilfsantrags IB gegenüber dem angenommenen generischen Stand der Technik schon mit Blick auf das allgemeine Wissen des Fachmanns naheliegt, Artikel 56 EPÜ 1973.

Zurückverweisung

18. Die Beschwerdeführerin äußerte sich unzufrieden darüber, dass die Kammer zu einem Ergebnis über erfinderische Tätigkeit kommen würde, ohne konkrete Druckschriften zu betrachten, und beantragt die Zurückverweisung zur weiteren Prüfung der erfinderischen Tätigkeit, damit das geschehen könne.

19. Hingegen ist die Kammer der Meinung, dass eine Zurückverweisung im vorliegenden Fall nicht zielführend ist. Um über die vorliegende Frage der hinreichenden Offenbarung zu entscheiden, muss sie zunächst den einschlägigen Fachmann feststellen, und wie dieser die Ansprüche auslegen würde. Wenn die Kammer, nachdem dies geschehen ist, keinen Raum für eine erfinderische Tätigkeit mehr sieht, ist die Zurückweisung und die mögliche Diskussion weiterer Dokumente sinnlos. In einem solchen Fall befindet sich die Kammer hier und entscheidet, gemäß ihrem Ermessen unter Artikel 111(1) EPÜ und weil sonst keine besonderen Gründe für eine Zurückverweisung sprechen, Artikel 11 VOBK 2020, die Sache nicht zurückzuverweisen.

Hilfsantrag IIB

20. Anspruch 1 spezifiziert die Art der Prozessbeschreibung als Blockschaltbild dadurch näher, dass jedes "Subjekt" durch einen Block und die Kommunikation zwischen Subjekten durch Pfeile dargestellt werden. Außerdem wird gefordert, dass der Quellcode für jedes Subjekt "ein separates Programm" darstellt und dass "jedes Subjekt" einen "Puffer zum Empfangen von Nachrichten aufweist". Da der Anspruch sich auf die Erzeugung von Quellcode bezieht, würde der Fachmann diesen Satz so interpretieren, dass im "Quellcode für jedes Subjekt" Code für einen solchen Puffer vorgesehen ist.

21. Zur ersten Änderung trägt die Beschwerdeführerin vor, dass bekannte Prozessbeschreibungssprachen wie UML insbesondere die Pfeile, nicht zur Darstellung von "Kommunikation" zwischen "Subjekten" verwenden würden. Mangels konkreter Schriften zu UML nimmt die Kammer das als richtig an.

21.1 Allerdings kann sie in der Verwendung einer bestimmten grafischen Prozessbeschreibungssprache - hier einer mit den beanspruchten Blöcken und Pfeilen - oder ihrer Verwendung - hier der Abbildung jedes Subjekts auf einen Block - keine technische Wirkung erkennen und folgt dabei der Rechtsprechung, dergemäß weder der Modellierung eines zu programmierenden Gegenstandes, noch dem Bereitstellen einer Programmiersprache oder ihrer Verwendung zum Programmieren im Allgemeinen eine technische Wirkung zukommt, und im Einzelfall nur dann, wenn die beanspruchten Merkmale in kausaler Weise eine technische Wirkung bedingen (vgl. insbesondere T 1539/09, Orientierungssatz; T 2270/10, Punkte 5-8; sowie die weiteren Referenzen in T 1630/11, Punkt 6).

21.2 Eine solche Kausalität kann die Kammer im vorliegenden Fall nicht erkennen, wie im Folgenden diskutiert wird.

22. Der Anspruchswortlaut legt den auszuführenden "Prozess" nicht fest. Die Beschreibung schließt ausdrücklich betriebswirtschaftliche Prozesse ein (Seite 1, letzter Absatz). Damit kann die Natur des beschriebenen Prozesses keine technische Wirkung entfalten.

23. Der Schritt, demgemäß dieser Prozess durch kommunizierende Subjekte entworfen werden soll, ist eine Anweisung an den "Modellierer", ungeachtet seiner Ausbildung oder Kompetenz.

23.1 Die Formulierung des Modells in Form einer Prozessdefinition entspricht dem Vorgang des Programmierens, also der Notation des Modells mittels geeigneter programmiersprachlicher Mittel.

23.2 Die Beschwerdeführerin behauptet, das vorgeschlagene Verfahren würde die Wartbarkeit erleichtern und gut "skalieren". Es sei leicht, Änderungen des Prozesses in der Prozessbeschreibung nachzuvollziehen, weil weitere "Subjekte" einfach hinzugefügt werden könnten und weil zusätzliche Funktionen eines "Subjektes" nur am entsprechenden Block ergänzt werden müssten, und in beiden Fällen nur Code für einzelne Subjekte neu zu erzeugen sei.

23.3 Allerdings gibt der Anspruch keinen Hinweis darauf, ob die vorgeschlagene Art der Modellierung dem Prozess entspricht und demnach wie leicht ein solcher Entwurf fällt. Ebenso wenig ist definiert, welcher Art die typischerweise auftretenden Änderungen am Prozessmodell sind. Während "subjekt-bezogene" Änderungen durch ein "subjekt-zentriertes" Modell möglicherweise einfacher werden, werden Änderungen, die mehrere Subjekte betreffen, nicht besonders unterstützt. Wie häufig welche Art von Änderungen nötig ist, lässt sich dem Anspruch nicht entnehmen, also auch nicht, ob insgesamt eine Vereinfachung eintritt. Mit Bezug auf die von der Kammer eingeräumte grundsätzliche Schwierigkeit der automatischen Quellcodeerzeugung aufgrund von Parallelität (vgl. Punkt 8.3.3 oben), unterstreicht die Kammer, dass in der beanspruchten Allgemeinheit nicht folgt, dass Subjekte einen "linearen Kontrollfluss" haben. A priori ist ohne Weiteres möglich, dass ein einzelnes Subjekt aus mehreren, parallel agierenden Komponenten besteht. Das bedeutet aber, dass die beanspruchte Erfindung in ihrer Allgemeinheit die eingeräumte Schwierigkeit weder ausräumt noch überwindet.

24. Die Übersetzung dieser Prozessdefinition in einen "Quellcode" muss, definitionsgemäß, die relevante Bedeutung ("Semantik") des Programms erhalten. Weitere Details des Übersetzungsvorgangs und etwa seinen Ressourcenverbrauch sind nicht bekannt, geschweige denn beansprucht. Die Kammer ist der Ansicht, dass auch die Übersetzung im allgemeinen keine technische Wirkung entfaltet (vgl. auch T 1125/17, Punkt 5.4 der Gründe).

25. Die Kammer akzeptiert zugunsten der Beschwerdeführerin, abweichend von ihrer vorläufigen Meinung (vgl. La­dungs­zusatz, Punkt 15) und trotz der Spannung mit der Be­schreibung (Seite 11, Absatz 2), dass ein separates "Programm" auch separat ausführbar ist.

25.1 Die Beschwerdeführerin behauptet, das Vorliegen eines separaten Programms je Subjekt erleichtere die parallele oder sogar verteilte Ausführung des erzeugten Programms. Beides ist in der Beschreibung angedeutet, aber nicht näher ausgeführt (vgl. ursprüngliche Beschreibung, Seite 3, Zeilen 29-31; Absatz, der Seiten 15 und 16 verbindet; Seite 21, Absätze 3 und 4). Vor allem aber ist eine parallele oder verteilte Plattform oder deren intendierte Verwendung im Anspruchswortlaut nicht impliziert. Es ist grundsätzlich möglich, mehrere Programme auf einem einzigen Prozessor auszuführen, selbst wenn diese Programme ein paralleles Modell abbilden. Dem Fachmann stehen zu diesem Zweck bekannte Mittel zur Verfügung (z.B. Coroutining). Diese sind auch bei Vorliegen paralleler Hardware nötig, weil es im allgemeinen mehr "Subjekte" als Prozessoren geben kann.

25.2 Im Fall von nicht-paralleler Hardware tritt die behauptete Erleichterung nicht ein. Möglicherweise stellt sogar das, was für eine Parallelisierung von Vorteil sein mag, bei serieller Ausführung einen unerwünschten Mehraufwand und damit sogar einen Nachteil dar.

25.3 Ob eine Erleichterung wie behauptet eintritt, hängt davon ab, welche Art von Plattform zur Ausführung des erzeugten Programms verwendet wird und wie. Mit anderen Worten wird ein Vorteil bei der Parallelisierung nicht schon durch das Programm alleine erzielt, sondern allenfalls dann, wenn das Programm auch tatsächlich parallel ausgeführt wird (in dieser Hinsicht folgt die Kammer den in T 1125/17, Punkt 6 der Gründe, obiter gemachten Ausführungen).

25.4 In der Entscheidung T 1173/97 wurde festgestellt, dass ein Computerprogramm dann nicht unter das Patentierungsverbot fällt, wenn es "beim Ablauf auf einem Computer" einen weiteren technischen Effekt bewirkt, der über die "normale" physikalische Wechselwirkung zwischen dem Programm (Software) und dem Computer (Hardware) hinausgeht (siehe Orientierungssatz und Punkt 13 der Gründe).

25.5 Die Kammer ist der Meinung, dass dieses Argument nur dann ohne Weiteres richtig sein kann, wenn der erwähnte weitere technische Effekt immer eintritt, wenn das Programm ausgeführt wird, d.h. auf jeder geeigneten Hardware- und Ausführungsplattform. Denn wenn der behauptete Effekt nur auf manchen Plattformen eintritt, kann er nicht dem Programm alleine zugeschrieben werden - es sei denn, die bevorzugte Plattform ist im Anspruchswortlaut implizit.

25.6 Im vorliegenden Fall folgt, dass ein Parallelisierungsvorteil nicht berücksichtigt werden kann, weil eine parallele Plattform und ihre Verwendung nicht beansprucht wird.

26. Insgesamt kommt die Kammer zu dem Ergebnis, dass der Erzeugung eines separaten Programms je Subjekt im Rahmen des Anspruchs 1 keine technische Wirkung zugeschrieben werden kann, die dann bei der Analyse der erfinderischen Tätigkeit zu berücksichtigen wäre (vgl. T 641/00, Orientierungsatz I). Da demnach die zusätzlichen Merkmale in Anspruch 1 des Hilfsantrags IIB nicht zur erfinderischen Tätigkeit beitragen, bleibt die Analyse von Anspruch 1 des Hauptantrags B auch für den Hilfsantrag IIB gültig, dem es somit an erfinderischer Tätigkeit mangelt, Artikel 56 EPÜ 1973.

Hilfsantrag IIIB

27. Auch die Änderungen am Anspruch 1 des Hilfsantrags IIIB beziehen sich ausschließlich auf den erzeugten Quellcode, in dem Befehle verwendet werden, die "auf dem Monitorkonzept beruhen". Dass damit "ein aktives Warten [...] vermieden" werden soll, ist dem Monitorkonzept (für den Fachmann bekanntermaßen) eigen. Welche Wirkung hingegen die Verwendung des beanspruchten Codes entfaltet, hängt, wie oben erläutert, entscheidend von der verwendeten Hardwareplattform ab. Da diese weiterhin nicht beansprucht wird, können auch die zusätzlichen Merkmale nicht zur erfinderischen Tätigkeit von Anspruch 1 gemäß Hilfsantrag IIIB beitragen, Artikel 56 EPÜ 1973.