Grafisches Programmiersystem nicht patentierbar (T2270/10)

Programmierer aufgepasst! In dieser aktuellen Entscheidung ging es um die Frage, ob ein Tool zum grafischen Programmieren mit einem Patent geschützt werden kann.

Es ging um Folgendes (Anspruch 1 gemäß Hauptantrag):

“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.”

Durch dieses Verfahren sollte die Programmierung von imperativen Programmen für Nicht-Spezialisten vereinfacht werden. Außerdem sollte der er­zeug­te Programmcode leichter lesbar und wartbar sein.

Die Kammer kam zu dem Schluss, dass keines dieser Ziele eine technische Aufgabe darstellt, wie sie für die Patentfähigkeit notwendig ist (eine Innovation muss eine technische Aufgabe lösen, um patentierbar zu sein). Im Ergebnis lag keine erfinderische Tätigkeit vor.

Aus der Begründung

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.).

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.

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 641/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.

Link zur Entscheidung: T 2270/10 (Programmieroberfläche/RENNER) of 2.7.2014

Leave a Reply