T 2270/10 (Programmieroberfläche/RENNER) of 2.7.2014

Sachverhalt und Anträge

I. Die Prüfungsabteilung wies die Europäische Patent­an­mel­dung Nr. 07012983.8 mit der Begründung zurück, die be­an­spruchte Erfindung weise gegenüber dem Dokument

D1: EP 1 610 219 A1

keine erfinderische Tätigkeit auf, Artikel 56 EPÜ.

II. Gegen diese Entscheidung legte die Anmelderin am 29. Juli 2010 Beschwerde ein. Die Beschwerdegebühr wurde am 28. Juli 2010 entrichtet und die Beschwerde­begründung ging am 4. November 2010 ein.

III. Die Beschwerdeführerin beantragt, den Beschluss der Prü­fungsabteilung aufzuheben und ein Patent zu erteilen auf der Basis geänderter Ansprüche 1-30 gemäß einem Hauptantrag und Hilfsanträgen 2 und 3, Ansprüchen 1-29 gemäß einem Hilfsantrag 1 oder Ansprüchen 1-28 gemäß einem Hilfsantrag 4, die mit der Beschwerdebegründung eingereicht wurden. Die übrigen Anmeldungsunterlagen sind wie folgt:

Zeichnungen, Blatt

1-8 eingegangen mit Schreiben vom 13. Nov. 2007

Beschreibung, Seiten

Hauptantrag und Hilfsantrag 1 oder 2

1, 3, 3a, 27-29, 31, 33, 35, 36, 38-43

eingegangen mit der Beschwerdebegründung

2, 4-26, 30, 32, 34, 37

wie ursprünglich eingereicht

Hilfsantrag 3 oder 4

1, 3, 8, 14, 15, 17-19, 21-29, 31, 33, 35, 36, 38-43

eingegangen mit der Beschwerdebegründung

2, 4-7, 9-13, 16, 20, 30, 32, 34, 37

wie ursprünglich eingereicht

IV. Mit einer Ladung zur mündlichen Verhandlung teilte die Kammer der Beschwerdeführerin ihre vorläufige Meinung mit, dergemäß der beanspruchte Gegenstand schon deshalb keine erfinderische Tätigkeit aufwiese, weil er gegen­über dem allgemeinen Fachwissen keine technische Auf­gabe lösen würde, Artikel 56 EPÜ 1973. Darüber hinaus wiese der beanspruchte Gegenstand keine erfinderische Tätigkeit gegenüber D1 auf, da die Unterschiedsmerkmale entweder fachüblich seien oder kein erkennbares tech­nisches Problem lösten. Schließlich wiesen Ansprüche aller Anträge Klarheitsmängel auf, Artikel 84 EPÜ 1973.

V. Auf die Ladung ging keine Erwiderung der Beschwerdefüh­rerin ein.

VI. Die mündliche Verhandlung fand am 2. Juli 2014 in Ab­wesenheit der Beschwerdeführerin statt.

VII. Anspruch 1 des Hauptantrags lautet wie folgt:

"Computergestütztes Verfahren zur imperativen Programmierung von Computern mit mehreren Programmanweisungen umfassendem Programmcode, wobei Schlüsselworte und Auswahllisten vorgesehen sind, mit einer grafischen Benutzeroberfläche wobei sich Programmanweisungen aus Operationen und Objekten zusammensetzen, wobei Objekte adressierbar sind sowie Operationen und Objekte aus Auswahllisten ausgewählt werden,

dadurch gekennzeichnet, dass

einem individuellen Namen eines Objektes, das durch das Ersetzen eines Schlüsselwortes in eine Anweisung eingefügt wird, ein Pfad zugeordnet ist, welcher zusammen mit dem individuellen Namen in die Anweisung eingefügt wird, wenn dieses Objekt in einer hierarchischen Struktur eingebunden ist."

Anspruch 1 des 1. Hilfsantrags entspricht Anspruch 1 des Hauptantrags, an dessen Ende der folgende Text angefügt wurde:

"... und dass ein Anweisungsabschnitt, mit dem ein Schlüsselwort in der Anweisung ersetzt wird und der den individuellen Namen eines Objektes sowie den möglicherweise zugeordneten Pfad umfasst, eine markierte Stelle aufweist, mit der die Auswahlliste wieder aufgerufen werden kann, mit welcher der Anweisungsabschnitt erstellt worden ist."

Anspruch 1 des 2. und 3. Hilfsantrags stimmen mit Anspruch 1 des Hauptantrags in der Präambel überein, während der kennzeichnende Teil jeweils ersetzt wurde. Der kennzeichnende Teil von Anspruch 1 des 2. Hilfs­an­trags lautet wie folgt:

"... dadurch gekennzeichnet, dass nach dem Ersetzen eines Schlüsselwortes durch einen Anweisungsabschnitt in diesem Abschnitt eine markierte Stelle vorgesehen ist, mit der die Auswahlliste wieder aufgerufen werden kann, mit welcher der Anweisungsabschnitt erstellt worden ist."

Der kennzeichnende Teil von Anspruch 1 des 3. Hilfs­antrags lautet wie folgt:

"... dadurch gekennzeichnet, dass Objekte Kategorien zugeordnet sind, wobei als Kategorien Hauptobjekte Ob­jekte und Subobjekte vorgesehen sind, wobei Hauptob­jek­te weitere Hauptobjekte, Objekte oder Subobjekte und Datensätze (Datenbanken, Dateien) enthalten können, wobei Objekte und Subobjekte Daten enthalten, wobei Hauptobjekte, Objekte und Subobjekte in den Auswahllisten in verschiedenen Ebenen zugeordnet sind, und wobei Subobjekte entweder einen Bezug zu einem Hauptobjekt, zu einem Objekt oder zu einer Operation haben."

Anspruch 1 des 4. Hilfsantrags stimmt mit Anspruch 1 des 1. Hilfsantrags überein, wobei zwischen die Wörter "dadurch gekennzeichnet, dass" und die Merkmale des kennzeichnenden Teils von Anspruch 1 des 1. Hilfs­an­trags die Merkmale des kennzeichnenden Teils des 3. Hilfsantrags eingefügt wurden.

Alle Anträge enthalten zusätzlich einen unabhängigen Anspruch auf ein computergestütztes System, der weit­gehend den entsprechenden Verfahrensansprüchen ent­spricht, nämlich Anspruch 23 des Hauptantrags, Anspruch 19 des 1. Hilfs­antrags, Anspruch 20 des 2. und 3. Hilfs­antrags und Anspruch 18 des 4. Hilfsantrags. Der genaue Wortlaut der Systemsansprüche ist für die Ent­scheidung der Kammer nicht von Bedeutung.

VIII. Am Ende der mündlichen Verhandlung verkündete der Vorsitzende die Entscheidung der Kammer.

Entscheidungsgründe

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.

Entscheidungsformel

Aus diesen Gründen wird entschieden:

Die Beschwerde wird zurückgewiesen.