T 1539/09 (Programmiersystem/RENNER) of 18.7.2013

Sachverhalt und Anträge

I. Die Beschwerde richtet sich gegen die Entscheidung der Prüfungsabteilung, die Anmeldung 04 014 708.4 zurückzu wei sen mangels erfinderischer Tätigkeit gegenüber

D3: "BridgeVIEW and LabVIEW - G Programming Reference Manual", National Instruments, January 1998 Edition, Part Number 321296B-01.

II. Beschwerde gegen diese Entscheidung wurde am 25. März 2009 eingelegt und die Beschwerdegebühr wurde am selben Tag entrichtet. Eine Beschwerdebegründung ging am 16. Juni 2009 ein. Die Beschwerdeführerin beantragte, die ange foch tene Ent scheidung aufzuheben und ein Patent zu erteilen auf der Grundlage von Ansprüchen 1-21 gemäß Haupt- oder Hilfs an trag wie mit der Beschwerdebegründung vorgelegt, in Verbindung mit den folgenden Unterlagen:

Beschreibung, Seiten

1-27 eingegangen am 8. März 2008

Zeichnungen, Abbildungen

2-4, 5c, 6a, 6b wie ursprünglich eingereicht

1, 5a, 5b eingegangen am 29. Oktober 2004.

III. Die Beschwerde füh rerin bezweifelte, dass die Hinweise auf das Datum "Januar 1998" in D3 den Schluss zuließen, dass D3 vor dem Anmeldetag der vorliegenden Anmeldung der Öffentlichkeit zugänglich gemacht worden sei (vgl. Beschwerdebegründung, Abschnitt III). Darüber hinaus aber argumentierte sie auch, dass und warum der bean spruchte Gegenstand gegenüber D3 neu und erfinderisch sei (Abschnitte IV und V).

IV. Mit einer Ladung zur mündlichen Verhandlung teilte die Kammer der Beschwerdeführerin ihre vorläufige Meinung mit, dergemäß die Vorveröffentlichung von D3 hinrei chend be legt und die Entscheidung mangelnder erfinderi scher Tä tigkeit gegenüber D3 voraussichtlich zu bestä ti gen sei. Darüber hinaus brachte die Kammer Zweifel daran zum Aus druck, ob die beanspruchte Erfindung einen über die Ver wendung eines Computers hinausgehende technische Wirkung aufwiese und somit einen nicht-naheliegenden techni schen Bei trag leis te, wie er für die Zuerkennung einer er fin de rischen Tätigkeit un erlässlich ist, Artikel 56 EPÜ 1973.

V. In Erwiderung auf die Ladung teilte die Beschwerdefüh re rin mit, dass sie an der angesetzten mündlichen Verhand lung nicht teil nehmen werde. Weitere Änderungen oder Ar gu mente wurden nicht vorgelegt.

VI. Anspruch 1 des Hauptantrags lautet wie folgt:

"Computergestütztes Verfahren zum Erstellen und/oder Abar beiten von Programmcode (Softwarecode), mit zumindest einer Visualisierungsoberfläche zur Darstellung von fest legbaren Objekten, über welche bei der Abarbeitung des Programmcodes Information, insbesondere Daten eingege ben und ausgegeben werden, wobei mittels des erstellten Programmcodes schreibend und lesend auf Objekte der Visualisierungsoberfläche zugegriffen wird, und wobei der Programmcode aus einzelnen Programmbausteinen zusammengesetzt wird, und wobei Programmbausteine der Kategorie Ablauf und Funktion zur Auswahl bereitgestellt werden; dadurch gekennzeichnet, dass die Programmbausteinkategorie Ablauf die Bausteintypen Ablaufbaustein (9), Startbaustein (8, 13), Ereignisbaustein (11) und Endbaustein (10, 17) umfasst, und wobei die Programmbausteinkategorie Funktion den Bausteintyp Funktionsbaustein (12) umfasst, und Vorschriften zum Verknüpfen von Programmbausteinen vorgegeben werden, die den Aufruf der Programmbausteine und deren serielle oder gleichzeitige Abarbeitung regeln,

- so dass Programmbausteine der Kategorie Ablauf immer seriell verknüpft werden wodurch ihre Arbeitsweise chronologisch ist, so dass bei einem Programmablauf zur gleichen Zeit immer nur ein Ablaufbaustein ausgeführt wird,

- so dass bei einer Verzweigung der Programmablauf durch die Festlegung einer Bedingung zu einem von mehreren unterschiedlichen Ablaufbausteinen geführt wird,

- so dass der Start eines Ablaufs durch einen Startbaustein erfolgt und der Startbaustein so eingerichtet ist, dass er einen Ablaufbaustein oder einen Endbaustein aufruft und der Endbaustein den Abschluss eines Ablaufes bildet,

- so dass der Bausteintyp Ereignisbaustein (11) der Kategorie Ablauf durch Ereignisse, die im Programmablauf eintreten, aufgerufen wird, und der Ereignisbaustein seinerseits Ablaufbausteine und Funktionsbausteine aufrufen kann, und

- so dass Funktionsbaustein durch einen Bausteintyp der Kategorie Ablauf aufgerufen wird, und durch den Funktionsbaustein Aufgaben erledigt werden, die parallel zu dem aufrufenden Baustein ausgeführt werden, wobei der Funktionsbaustein selbst keinen Programmbaustein aufrufen kann,

und weiterhin den ausgewählten Programmbausteinen jeweils ein Symbol (8-13) zugeordnet ist, dass [sic] in einem den Programmablauf wiedergebenden Strukturschaubild (4) dargestellt wird und weiterhin die Symbole (8-13) unter Berücksichtigung der vorgegebenen Regeln automatisch mittels Linien zur Darstellung der seriellen und parallelen Abarbeitung miteinander verbunden werden, wodurch die Programmstruktur und der Programmverlauf dargestellt werden."

Anspruch 1 des Hilfsantrags entspricht Anspruch 1 des Haupt an trags, am Ende ergänzt um den folgenden Text:

"..., und wobei weiterhin ein Symbol eines Programmbausteins in dem den Programmablauf wiedergebenden Strukturschaubild (4) einen virtuellen Programmcontainer darstellt, wobei der Zugang zu dem Programmcode des jeweiligen Programmbausteins durch Anwählen des Programmcontainers erfolgt, wobei beim Anwählen des Programmcontainers eine neue Anzeigeoberfläche erzeugt wird, in welcher der Programmcode des betreffenden Programmbausteins textbasiert bearbeitet werden kann und für einige Bausteine, die in dem Strukturschaubild (4) in Form des jeweiligen Symbols angezeigt werden, ein vorläufiger Programmcode auf Textbasis bereitgestellt wird."

Beide Anträgen umfassen zusätzlich je einen unabhängigen Systemanspruch, der dem jeweiligen Verfahrensanspruch weitestgehend entspricht.

VII. Die mündliche Verhandlung fand, wie angekündigt, in Abwesenheit der Beschwerdeführerin statt. An deren Ende verkündete der Vorsitzende die Entscheidung der Kammer.

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.

ENTSCHEIDUNGSFORMEL

Aus diesen Gründen wird entschieden:

Die Beschwerde wird zurückgewiesen.