T 1539/09 (Programmiersystem/RENNER) 18-07-2013

Entscheidungsgründe

1. Die fol genden Gründe stützen sich im Wesentlichen auf solche, die die Kammer der Beschwerdeführerin im Ladungs zusatz mitgeteilt hat.

Die Erfindung

2. Die Anmeldung geht von der Beobachtung aus, dass das Er stellen von Programmen aufwändig und nur Spe zi alis ten mög lich ist. Die Aufgabe der Erfindung ist es somit, "Per sonen ohne besondere Vorkenntnisse ... in die Lage zu versetzen, selbst eigene Computer pro gramme ... zu er stellen" (S. 2, 2. Abs., der ursprünglichen Anmeldung).

2.1 Als Lösung schlägt die Anmeldung ein graphisches Pro grammiersystem vor. Das erfindungsgemäße System stellt un terschiedliche "Programmbausteine" bereit, die gemäß vorgegebenen Regeln miteinander verknüpft wer den können (S. 2, 3. Abs. und S. 3, 2. Abs.). Den Pro grammbau stei nen sind graphische Symbole zugeordnet (S. 5, 2. Abs.; Abb. 2), die der Anwender auf einer "Visu a lisie rungs ober fläche" anordnen kann und die dort (den Regeln ent spre chend) mittels geeigne ter Linien zu einem "Struk tur schau bild" verknüpft werden (Abb. 3). Jeder Programm bau stein eines Strukturschaubilds ent spricht ei nem "Pro grammcodeab schnitt" und das gesamte Struk tur schau bild so mit einem Programm (s. z. B. S. 15, Zn. 5-7; S. 17, 4. Abs. - S. 18, 1. Abs.). So kann der An wen der durch Ma ni pulation graphischer Symbole auf dem Com pu ter bild schirm Programm code "auf Textbasis" definieren, ohne diesen di rekt, also als Text (oder anspruchsgemäß: "textba siert"), ein geben zu müssen. Wenn der Anwender aber einen Pro gramm baustein anwählt (bspw. durch Anklicken), so öffnet sich ein eine Anzeigeoberfläche (bspw. ein Fenster), in dem er den Pro gramm code abschnitt dieses Bausteins be arbei ten kann.

2.2 Programmbausteine sind in zwei Kategorien vorgesehen, die "Ablauf" und "Funktion" genannt und zur Defini tion sequentieller bzw. paralleler Abläufe verwendet wer den. In der Kategorie "Ablauf" werden Programmbausteine des Typs "Ablaufbaustein", "Start baustein", "Ereignis bau stein" und "Endbaustein" beansprucht, in der Kate gorie "Funktion" nur einer des Typs "Funktionsbaustein". Ab lauf bau steine dürfen nur seriell verknüpft werden und de finie ren se quen tielle Ausführung. Verzweigungen sind vorge sehen. Funktionsbausteine können von Ablaufbau stei nen aufge ru fen werden und definieren parallele Ausfüh rung. Ein Funktions baustein seinerseits kann keinen wei teren Pro grammbaustein aufrufen. Jeder "Ablauf" muss mit einem Startbaustein beginnen und mit einem Endbaustein enden.

3. Zunächst sei bemerkt, dass der Gegenstand der vorlie gen den Ansprüche (beider Anträge) als ein computer ge stütz tes Verfahren bzw. ein Computersystem eine Erfindung im Sinne des Artikels 52 (2,3) EPÜ darstellt (s. T 0258/03, Amtsbl. EPA 2004, 575; Leitsatz I). Die Kammer ist je doch der Meinung, dass die bean spruchte Erfindung keine nicht-nahelie gen de "weitere", also über die Ver wen dung eines Computers hinausgehende tech nische Wir kung auf weist, und somit ob keinen für die Zuer ken nung ei ner er fin derischen Tä tig keit unab lässi gen nicht-nahelie gen den tech nischen Bei trag zum Stand der Technik leis tet, Arti kel 56 EPÜ 1973.

4. Die Erfindung richtet sich auf eine graphische Programm sprache und - umgebung, die es einem Anwender ermöglichen soll, ohne großen Lernauf wand oder besondere Expertise Pro grammcode zu erzeugen. Die Wirkung, den mentalen Auf wand des Anwenders bei der Programmerstellung zu redu zie ren, ist an sich nach An sicht der Kammer keine tech nische. Das gilt umso mehr, als sie für alle Pro gramme gleichermaßen angestrebt wird, also unabhängig da von, wel chem Zweck das entwickelte Programm dienen soll.

4.1 Beim Programmieren - im Sinne des Formulierens von Pro gramm code, des "Kodierens" - muss der Programmierer aus dem Repertoire einer Programmiersprache diejenigen For mu lie rungen wählen, die bei Ausführung des Programms zum gewünschten Ergebnis führen. Die Programmiersprache de fi niert dabei zum einen, welche Formulierungen über haupt als "wohlgeformt" zu lässig sind (Syntax), und zum an de ren, welches "Verhalten" ei nem Programm zugeschrie ben wird (operationale Semantik). Die Wahl der Program mier sprache kann im Einzelfall Einfluss da rauf haben, wie leicht (und manchmal ob überhaupt) sich die Lö sung ei nes Prob lems als ein Programm formulieren lässt.

4.2 Die Tätigkeit des Programmierens selbst jedoch ist nach An sicht der Kammer ein im Wesentlichen mentaler Vorgang - ver gleich bar der Verbalisierung eines Gedankens oder der Formulierung eines mathe ma tischen Sachver halts in ei nem Kalkül -, der es mit den Worten der Grossen Beschwer de kammer aus G 0003/08 (Amtsbl. EPA 2011, 10; Gründe 13.5.1) an "wei teren technischen Überle gun gen" fehlt. Das gilt wenigstens dann und insoweit als, wie im vor lie gen den Fall, die Tätigkeit des Programmie rens nicht im Rahmen einer konkreten Anwendung oder Umgebung in kau sa ler Weise der Erzielung einer techni schen Wirkung dient.

4.3 Aus diesem Grund schließt die Kammer, dass die De fini tion und Bereitstellung einer Pro gram mier sprache oder programmiersprachlicher Mittel per se nicht zur Lö sung eines technischen Prob lems beiträgt.

5. Die Erfindung umfasst die Definition einer graphischen Programmiersprache, deren Programme Struk turschaubilder aus Symbolen und Linien sind, die entsprechend gewisser Regeln zusammen gefügt sein müssen (Syntax). Teil dieser Defi ni tion ist die Fest legung, wie jeder einzelne Bau stein aus zuführen ist und wie sich daraus das Ab lauf ver halten eines gesamten Programms ergibt (opera tio nale Se mantik). Insbesondere die Be reit stellung von Funk tions bausteinen zur parallelen Aus führung und die Fest legung, dass diese von Ablaufbau stei nen aufgerufen wer den aber ihrerseits keine Pro grammbausteine aufrufen können, ist nach Ansicht der Kammer ein Teil der defi nier ten Pro grammiersprache.

5.1 In Ansprüchen 1 und 10 des Hauptantrags nicht Teil der Programmsprache sind nur die Bereitstellung einer "Vi su alisierungsoberfläche" sowie dass die "Symbole ... unter Berücksich ti gung der vorgegebenen Regeln automa tisch mittels Li nien zur Dar stellung der seriellen oder pa ralle len Ab arbei tung mit einander verbunden wer den" (Her vorhebung durch die Kammer). Die Kammer rech net diese Merkmale der Pro grammierumgebung zu, die den Anwender dabei unter stützt, konkrete Programme einer gegebenen Pro grammier sprache zu erzeugen.

5.2 Visualisierungsoberflächen sind ein elementarer Bestand teil von Programmierumgebungen aller Art. Darüber hi naus ist es ist eine für den Fachmann allgemein bekannte Tat sache, dass der mechanische Vorgang des Programmie rens, also das Erzeu gen eines konkreten Programms, auf wändig und fehlerhaft sein kann. Das gilt gleichermaßen für text-basierte wie für graphische Pro gramme, also unabhängig davon, ob ein Programmtext "eingetippt" werden muss oder ob graphische Programmbausteine auf dem Bild schirm ange or dnet wer den müssen. Die Kammer hält es da her für nahe liegend - wie im übrigen auch für grundsätz lich bekannt - dass Entwicklungsumgebungen dem Pro grammie rer, soweit mög lich, mechanische Aufgaben bei der Pro grammie rung ab nehmen sollen. Im konkreten Fall hält es die Kammer somit auch für na he lie gend, dem Benutzer die manuelle Eingabe von Ver bin dungslinien zwischen Symbolen abzu neh men und diese au tomatisch vorzunehmen.

5.3 Daher kommt die Kammer zu dem Ergebnis, dass der Gegen stand der Anspruchs 1 gemäß Haupt an trag keine erfin de rische Tätigkeit aufweist, Artikel 56 EPÜ 1973.

6. Ansprüche 1 und 10 des Hilfsantrags legen zusätzlich fest, dass je dem Programmbaustein ein Stück Programmcode entspricht, und dass durch "Anwählen" eines Symbols dem Anwender Zugang zu dem Programmcode des entsprechenden Pro gramm sbaustein ermöglicht wird. Dieser Zugang erfolgt über eine dedizierte "Anzeigeoberfläche", in der der Anwender den Programmcode "auf Textbasis" bearbeiten kann.

6.1 Die Anmeldung geht nach dem Verständnis der Kammer da von aus, dass dieser Pro grammcode einer Programmier spra che ent spricht, deren Ab laufverhalten vorgegeben und be kannt ist (bspw. BASIC). Somit soll der einem Programm bau stein entsprechende Code das Ablaufverhalten dieses Bausteins über den Umweg der bekannten text-basierten Pro grammier sprache zu defi nieren. Die Erfindung ergänzt somit eine text-basierte Programmier sprache um zusätz liche, graphi sche Ausdrucksmittel, die als Abkürzungen für "Programm code auf Textbasis" der zugrundeliegenden text-basierten Programmiersprache dienen. Auf diese Wei se wird eine Pro grammiersprache mit textbasierten und graphischen Anteilen definiert. Die Definition solcher gra phischer pro grammiersprachlicher Ausdrucks mittel aber kann, wie oben ausgeführt, nicht als Lösung für ein tech nisches Prob lem gelten.

6.2 Dasselbe gilt nach Ansicht der Kammer für den Umstand, dass ein kon kreter Programmbau stein den entsprechenden Programm code nicht eindeutig festlegt, sondern dass dieser - als "vorläufiger Programmcode" - um weitere Anga ben (z. B. Parameter) ergänzt werden muss oder kann (vgl. Abb. 5c).

6.3 In welcher Weise das dem Anmelder ermöglicht wird, ist ein Aspekt der Pro grammier um ge bung. Dabei ist die Kammer jedoch der Meinung, dass die text-ba sier te Bear beitung als eine für den Fachmann naheliegende Option gelten muss.

6.4 Somit kommt die Kammer zu dem Ergebnis, dass auch der Gegenstand der Ansprüche 1 und 10 des Hilfs antrags keine erfinderische Tätigkeit aufweist, Artikel 56 EPÜ 1973.