T 2270/10 (Programmieroberfläche/RENNER) 02-07-2014

1. Die ordnungsgemäß geladene Beschwerdeführerin war in der mündlichen Verhandlung nicht anwesend. Gemäß Arti­kel 15 (3) VOBK wurde das schriftliche Vorbringen der Beschwerdeführerin berücksichtigt. Am Ende der münd­li­chen Verhandlung verkündete die Kammer ihre Ent­schei­dung, da die Sache entscheidungsreif war (Artikel 15 (5,6) VOBK) und die Abwesenheit der Beschwerde­füh­rerin kein Grund war, die Entscheidung aufzuschieben (Artikel 15 (3) VOBK).

2. Die folgenden Entscheidungsgründe beschränken sich im We­sent­lichen auf die vorläufige Meinung der Kammer, die im Ladungszusatz der Beschwerdeführerin mitgeteilt wor­den ist.

Die Erfindung

3. Die Anmeldung geht von der Beobachtung aus, dass die konventionelle Programmierung aufgrund ihrer Komple­xi­tät nur noch Spezialisten offenstehe und befasst sich mit der Aufgabe, diesen Umstand zu ändern (ursprüng­liche Anmeldung, S. 2, 1. Satz; S. 3, 1. Abs.).

3.1 Als Lösung schlägt die Anmeldung ein Programmier­system und das entsprechende Verfahren ­vor, das den Pro­grammierer "vom Ballast der Sprach­konventionen und dem komplizierten Formalis­mus ... befreien" soll (S. 3, 1. Satz). Dieses Ziel wird erfin­dungs­gemäß durch eine gra­fische Benutzer­ober­fläche erzielt, die Programm­kom­po­nen­ten zur Auswahl aus Lis­ten (Kontextmenüs) be­reit­stellt und so hilft, das mühsame und fehler­anfälli­ge Eintippen von Text zu vermei­den (S. 3, letzter Abs.).

3.2 Gleichzeitig sind Programmanweisungen vorgesehen, die grundsätzlich aus Operationen und Objekten bestehen (S. 3, vorletzter Abs.), so dass der Programmierer sich auf den zu steuernden Prozess - das "Prozessuale" - kon­zen­trieren kann (S. 4, 1. Abs.). Auf diese Weise wer­de das Programmieren intuitiver und der Pro­gramm­code selbst leichter zu lesen und zu warten (S. 4, 1. Abs.).

3.3 Die Anmeldung stellt fest (S. 5, 2. Abs.), dass "Ob­jekte ... häufig in Baumstrukturen eingebunden [sind], so dass diese mit ei­nem Pfad gekoppelt sein können". Damit laute die typische Grundform einer Anweisung wie folgt: ">Operation: Pfad\Objekt<". Die Teile "Opera­tion" und "Pfad\Objekt" nehmen hierin beschrei­bungs­gemäß die "Funktion von Schlüsselworten" ein, die im "Bedienprozess" bei der Erstellung einer konkreten Anweisung durch "eine spezielle Operation und Objekte ersetzt werden können" (S. 5, letzter Abs.). So er­stellte Anweisungen können in dem Abschnitt, in dem ei­ne Operation oder ein Objekt nach Auswahl aus einer Lis­te eingefügt wurde, eine markierte Stelle aufweisen, mittels derer die relevante Auswahlliste wieder aufge­ru­fen werden kann (S. 28, 2. Abs. und ursprünglicher Anspruch 18). Es wird beschrieben, dass eine solche Mar­kierung vom Softwareentwickler angeklickt werden könne, um so etwa ein gewähltes Objekt durch ein an­de­res zu ersetzen.

3.4 Es sind unterschiedliche Kategorien von Objekten vor­ge­sehen, die als "Hauptobjekte, Objekte und Subobjekte" bezeichnet werden (S. 8, 2.-4. Abs.). Die Beschreibung erläutert, dass "Hauptobjekte" Objekte enthalten und somit zum Beispiel die "Funktion von Containern" an­neh­men können, während "Objekte" keine weiteren Objekte enthalten. Sie erläutert weiter, dass "Subobjekte" ei­nen "Bezug zu einem Objekt oder zu einer Operation ha­ben" und so "die korrespondierende Operation oder das Objekt ergänzen". "Welche Hauptobjekte, Objekte und Subobjekte einem Softwareentwickler zur Verfügung" stünden, hinge "von der Mächtigkeit der Sprache ab, die dem Softwareentwickler zur Verfügung steht" und "davon, welche Objekte er installiert hat" (S. 9, Zn. 1.-4.).

Technischer Charakter

4. Die Erfindung gemäß Anspruch 1 aller Anträge bezieht sich auf ein "[c]om­pu­terge­stütz­tes Verfahren zur impe­ra­tiven Programmie­rung" unter Verwendung einer "gra­fi­schen Benutzer­ober­fläche" sowie das entsprechende Sys­tem. Allein schon wegen der Verwendung eines Computers handelt es sich dabei nach gefestigter Rechtsprechung der Beschwerde­kammern (vgl. etwa G 3/08, ABl. EPA, 2011, 10; Grün­de 10.7) um Gegenstände, die technischen Charakter haben und somit unter Artikel 52 (2,3) EPÜ nicht zu bemängeln sind.

Auslegung der Ansprüche

5. Einige Merkmale der beanspruchten Erfindung definieren Aspekte einer Pro­grammier­sprache, andere Merkmale defi­nieren Aspekte der zugehörigen Pro­grammier­­umgebung, insbesondere ihrer grafischen Benutzeroberfläche.

5.1 Die vorgeschlagene Programmiersprache ist ge­mäß An­spruch 1 des Hauptantrags dadurch charakterisiert, dass sie "imperativ" ist, dass sich ihre Anweisungen aus "Ope­ra­tionen" und "Objekten" zusammensetzen, dass Ob­jekte in einer "hierarchischen Struktur eingebunden" sein können und durch einen "Namen" und ggf. einen "Pfad" adressierbar sind. Zur Definition der Pro­grammier­­spra­che gehört nach Ansicht der Kammer weiter­hin, dass man zu­lässige An­weisungen durch das Er­setzen von "Schlüssel­wörten" durch Operationen und Objekte aus vorgegebenen "Listen" erhält, insofern als die Syntax der Programmiersprache festlegt, welche Schlüssel­­­wörter an welchen Positionen innerhalb von Anweisungen zu­lässig sind und durch welche Namen sie im Einzelnen ersetzt werden dürfen. Keines dieser Merk­male ist nach Ansicht der Kammer der gra­fischen Be­nutzer­oberfläche zuzuordnen. Nur die Formu­lie­rungen, dass Operationen und Objekt aus "Auswahl­"lis­ten "ausge­wählt" und ent­sprechende Namen (und Pfade) in Anweisungen "einge­fügt" werden wird der Fachmann als Aktionen des Soft­ware­­ent­wicklers bei der Verwendung der beanspruchten Benutzer­oberfläche ver­stehen.

5.2 Anspruch 1 der 1. und 2. Hilfsanträge fordert, dass ein "Anweisungsabschnitt, mit dem ein Schlüsselwort in der Anweisung ersetzt wird ... eine markierte Stelle auf­weist, mit der die [einschlägige] Auswahlliste wieder aufgerufen werden kann". Der Anspruchswortlaut legt we­der die Natur dieser "Stelle" fest noch in wel­cher Weise diese es er­möglichen solle, die Auswahl­liste wie­der aufzurufen. Damit würde der Fachmann nach An­sicht der Kammer dieses Merkmal funktional als die For­derung interpretieren, dass die einmal erfolgte Er­setzung ei­nes Schlüssel­wor­tes in einer Anweisung falls notwendig zur Korrektur wiederholt werden könne. Ob und in wel­cher Weise die grafische Benutzeroberfläche diese Funk­tion unterstützt, bleibt dabei offen.

5.3 Anspruch 1 der Hilfsanträge 3 und 4 fordert die Exis­tenz von Objekten unterschiedlicher Kategorie, nämlich "Hauptobjekt", "Objekt" und "Subobjekt". Im Ladungszu­satz (Punkt 7) bezweifelte die Kammer die Klarheit der ein­schlägigen Definition. Diese Frage kann jedoch für die vorliegende Entscheidung dahingestellt bleiben: Ob Containerobjekte (wie z. B. Lis­­ten und Arrays) und "ein­fache" Objekte (bspw. In­tegers) zur Verfügung ge­stellt werden und in welcher Weise Objekte andere Ob­jekte oder Operationen "ergänzen", ist nach Ansicht der Kammer ein Aspekt der Definition der gewünschten Pro­grammiersprache. Auch die Beschreibung offenbart aus­drücklich, dass es insbesondere von der "Mächtigkeit der Sprache" abhängt, welche Hauptobjekte, Objekte und Subobjekte einem Softwareentwickler zur Verfügung ste­hen. Erneut ist festzustellen, dass der Anspruchs­wort­laut nicht festlegt, ob und in welcher Weise die gra­fi­sche Benutzeroberfläche die Handhabung der unter­schied­lichen Objektkategorien unterstützt.

Technische Aufgabe und technischer Beitrag

6. Die Anmeldung gibt als Ziele der vorliegenden Anmeldung an, die Programmierung von imperativen Programmen für Nicht-Spezialisten zu vereinfachen, sowie den so er­zeug­ten Programmcode leichter lesbar und wartbar zu machen. Die Kammer ist der Ansicht, dass keines dieser Ziele als eine technische Aufgabe gelten kann, wie sie nach ständiger Rechtsprechung der Beschwerdekammern als Voraussetzung für eine erfinderische Tätigkeit im Sinne des Artikel 56 EPÜ 1973 unerlässlich ist. Die Kammer folgt in dieser Entscheidung ihren früheren Entschei­dungen T 1539/09 und T 1171/06.

7. In T 1539/09 (1. Orientierungssatz) hat die Kammer fest­­­gestellt, dass die Tätigkeit des Programmierens als ein mentaler Vorgang anzusehen ist, soweit sie nicht im Rahmen einer konkreten Anwendung oder Umgebung in kau­sa­ler Weise der Erzielung einer technischen Wirkung dient.

7.1 Eine solche Wirkung ist im vorliegenden Fall für die Kammer nicht ersichtlich. Insbesondere ist das bean­spruchte Pro­grammiersystem intentions­gemäß uni­ver­sell, nicht auf ein konkretes Anwendungsgebiet be­schränkt und schließt ausdrücklich technische wie nicht-technische Anwendungsgebiete ein (vgl. S. 4, Zeilen 1-3). Ob und inwie­weit die Erfindung daher die Pro­gramm­entwicklung er­leichtert, scheint der Kammer somit für die Bewer­tung der erfinderischen Tätigkeit nicht relevant zu sein.

7.2 Ob und inwieweit ­eine Programmiersprache und ein Pro­grammier­sys­tem das Programmie­ren erleichtert, hängt zum einen von vielen (nicht be­schriebenen oder be­an­spruch­ten) Umständen ab und stellt zum anderen wenig­stens zu einem erheblichen Teil ein sub­­jektives Kri­te­rium dar, das sich nur schwer, falls überhaupt, sinn­voll quanti­fi­zieren und ver­läss­lich fest­stellen lässt. Die Anmel­dung stellt keine belast­bare Grundlage dar, auf der die be­hauptete Verein­fa­chung der Programm­er­stellung zu über­­prü­fen wäre.

7.3 In der Anmeldung wird insbesondere dargestellt, dass die Erfindung eine neue Art des Programmierens - "[p]ro­­­zessuales Programmieren" - unterstütze, gestützt u. a. auf den "Grundgedanken", Programmanweisungen aus Ope­ra­tionen und Objekten" zu bilden und so "[d]ie Denk­weise beim Programmieren ... in eine neue Rich­tung" zu lenken. Die Kammer verweist in dieser Hinsicht darauf, dass Programmiersprachen bekanntermaßen auf unter­schied­lichen sogenannten "Paradigmen" beruhen, die je­weils eine unterschiedliche Sicht auf die zu ent­wickeln­­den Programme ermöglichen oder sogar erzwingen: Bei­spielsweise stehen im Zentrum "objekt-orientierter" Pro­­gramme sogenannte "Objekte", die jeweils die "Metho­den" zu ihrer Bearbeitung gleich selbst bereitstellen, und Lösungen in objekt-orientierten Sprachen müssen als Kooperation solcher, miteinander kommunizierender Ob­jekte konzipiert werden; im Zentrum "funktionaler" Pro­gramme stehen hingegen mathematische Ausdrücke, und Lösungen in solchen Sprachen müssen als die Auswertung bzw. Verein­fachung solcher Ausdrücke konzipiert werden.

7.4 Die Bereitstellung der entsprechenden Pro­grammier­sprache und ihrer Ausdrucksmittel wie Objekt/Methode/Nachricht, Funktion/Auswertung oder eben Operation/Ob­jekt wie im vorliegenden Fall trägt nach Ansicht der Kammer - und gemäß T 1539/09 (2. Orientierungssatz) - nicht zur Lösung eines technischen Problems bei.

8. In T 1171/06 (Orientierungssatz) stellte die Kammer weiter fest, dass einem in der Softwareentwicklung ver­wendeten Modell kein technischer Effekt dadurch zukomme, dass es der Dokumentation oder Kommunikation dient, selbst wenn sein Gegenstand ein technisches System sei.

8.1 In diesem Sinne hält die Kammer auch die behauptete Erleichterung der Lesbarkeit und Wartbarkeit der er­stellten Programme für die Bewertung der erfinderischen Tätigkeit nicht für relevant.

8.2 Auch hier sei aber zudem angemerkt, dass die Frage, ob ein Programm leicht lesbar und wart­bar ist, eine groß­teils subjektive ist, und es ­schwierig bis unmöglich zu sein scheint, einen solchen Schwierig­keits­grad sinnvoll und ver­lässlich zu beziffern.

9. Die Kammer schließt nicht aus, dass konkrete Details einer graphischen Benutzeroberfläche die Bedienung eines Computers als ein technisches Gerät und/oder bei der Anwendung auf eine technische Aufgabe erleichtern, und auf diese Weise einen Beitrag zur Lösung eines tech­nischer Aufgabe dienen können.

9.1 Allerdings legt wenigstens Anspruch 1 aller vor­lie­gen­den Anträge - wie oben ausgeführt - allenfalls fest, dass die Programmierung mit der vorgeschlagenen Pro­grammiersprache durch eine grafische Benutzer­oberfläche unterstützt wird, nicht aber durch welche konkreten Mittel.

9.2 Im Ladungszusatz informierte die Kammer die Beschwerde­führerin darüber, dass es ihr nicht ersichtlich sei, welche konkreten Merkmale der graphischen Benutzer­oberfläche gemäß einem der vorliegenden Anträge einen technischen Beitrag leisten würden.

9.3 Die Beschwerdeführerin hat auf diese Feststellung der Kammer nicht reagiert, also weder Argumente vorgebracht noch Änderungen eingereicht, aus denen der technische Beitrag eines beanspruchten Merkmals der grafischen Benutzeroberfläche hervorgehen würde.

9.4 Daher hat die Kammer keinen Anlass, von ihrer vorläu­fi­gen Meinung abzuweichen.

10. Zusammenfassend also interpretiert die Kammer den Gegenstand von Anspruch 1 aller vorliegenden Anträge als ein computergestütztes Verfahren, demgemäß die Pro­grammierung einer gewünschten imperativen Pro­grammier­sprache durch eine im Wesentlichen undefi­nierte gra­fi­sche Benutzerschnittstelle unter­stützt wird.

10.1 In Übereinstimmung mit T 1539/09 ist die Kammer der An­sicht, dass die Definition der gewünschten Pro­grammier­sprache keine technische Aufgabe löst und somit keinen Beitrag zur erfinderischen Tätigkeit leisten kann. Im Rahmen des Aufgabe-Lösungs-Ansatzes dürfen die ent­sprechenden Merkmale somit, gemäß T T641/00 (ABl. EPA, 2003, 352; Orientierungssatz II), bei der Formulierung der Aufgabe als Teil der Rahmenbedingungen für die zu lösende technische Aufgabe aufgegriffen werden, ins­be­sondere als eine zwingend zu erfüllende Vorgabe.

10.2 Die von der Erfindung gemäß Anspruch 1 aller Anträge gelöste Aufgabe kann somit darin gesehen werden, die Entwicklung von Programmen in einer Programmiersprache mit den geforderten Merkmalen zu unterstützen.

10.3 Programmierumgebungen mit grafischen Benutzerober­flä­chen sind zu diesem Zwecke allgemein bekannt und daher ohne Weiteres naheliegend.

10.4 Daher kommt die Kammer zu dem Schluss, dass der Gegen­stand von Anspruch 1 aller Anträge schon gegenüber dem allgemeinen Fachwissen keine erfinderische Tätigkeit im Sinne von Artikel 56 EPÜ 1973 aufweist.

11. Die im Ladungszusatz darüber hinaus aufgeworfene Frage, ob und warum im Einzelnen es dem beanspruchte Gegen­stand außerdem gegenüber D1 an einer erfinderischen Tätigkeit mangelt, kann somit dahingestellt bleiben.