Beschwerdekammern des Europäischen Patentamts Entscheidung vom 18.07.2013 – T 1539/09

Aktenzeichen: T 1539/09 - 3.5.06

E N T S C H E I D U N G

der Technischen Beschwerdekammer 3.5.06 vom 18. Juli 2013 Beschwerdeführer:

(Anmelder) Vertreter:

Zusammensetzung der Kammer:

(DE) Lippert, Stachow & Partner Patentanwälte Postfach 30 02 08 D-51412 Bergisch Gladbach Angefochtene Entscheidung:

Vorsitzender:

Mitglieder:

Renner, Peter Heiligenstock 2 D-51515 Kürten D. H. Rees M. Müller W. Sekretaruk (DE) Entscheidung der Prüfungsabteilung des Europäischen Patentamts, die am 6. Februar 2009 zur Post gegeben wurde und mit der die europäische Patentanmeldung Nr. 04014708.4 aufgrund des Artikels 97 (2) EPÜ zurückgewiesen worden ist.

Sachverhalt und Anträge

I. Die Beschwerde richtet sich gegen die Entscheidung der Prüfungsabteilung, die Anmeldung 04 014 708.4 zurückzuweisen 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 angefochtene Entscheidung aufzuheben und ein Patent zu erteilen auf der Grundlage von Ansprüchen 1-21 gemäß Haupt- oder Hilfsantrag wie mit der Beschwerdebegründung vorgelegt, in Verbindung mit den folgenden Unterlagen:

Beschreibung, Seiten 1-27 eingegangen am 8. März 2008 Zeichnungen, Abbildungen III. 2-4, 5c, 6a, 6b wie ursprünglich eingereicht 1, 5a, 5b eingegangen am 29. Oktober 2004. Die Beschwerdeführerin 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 beanspruchte 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 hinreichend belegt und die Entscheidung mangelnder erfinderischer Tätigkeit gegenüber D3 voraussichtlich zu bestätigen sei. Darüber hinaus brachte die Kammer Zweifel daran zum Ausdruck, ob die beanspruchte Erfindung einen über die Verwendung eines Computers hinausgehende technische Wirkung aufwiese und somit einen nicht-naheliegenden technischen Beitrag leiste, wie er für die Zuerkennung einer erfinderischen Tätigkeit unerlässlich ist, Artikel 56 EPÜ 1973.

V. In Erwiderung auf die Ladung teilte die Beschwerdeführerin mit, dass sie an der angesetzten mündlichen Verhandlung nicht teilnehmen werde. Weitere Änderungen oder Argumente wurden nicht vorgelegt.

VI. Anspruch 1 des Hauptantrags lautet wie folgt:

"Computergestütztes Verfahren zum Erstellen und/oder Abarbeiten von Programmcode (Softwarecode), mit zumindest einer Visualisierungsoberfläche zur Darstellung von festlegbaren Objekten, über welche bei der Abarbeitung des Programmcodes Information, insbesondere Daten eingegeben 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 Hauptantrags, 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.

1. Die folgenden Gründe stützen sich im Wesentlichen auf solche, die die Kammer der Beschwerdeführerin im Ladungszusatz mitgeteilt hat. Die Erfindung 2. Die Anmeldung geht von der Beobachtung aus, dass das Erstellen von Programmen aufwändig und nur Spezialisten möglich ist. Die Aufgabe der Erfindung ist es somit, "Personen ohne besondere Vorkenntnisse ... in die Lage zu versetzen, selbst eigene Computerprogramme ... zu erstellen" (S. 2, 2. Abs., der ursprünglichen Anmeldung).

2.1 Als Lösung schlägt die Anmeldung ein graphisches Programmiersystem vor. Das erfindungsgemäße System stellt unterschiedliche "Programmbausteine" bereit, die gemäß vorgegebenen Regeln miteinander verknüpft werden können (S. 2, 3. Abs. und S. 3, 2. Abs.). Den Programmbausteinen sind graphische Symbole zugeordnet (S. 5, 2. Abs.; Abb. 2), die der Anwender auf einer "Visualisierungsoberfläche" anordnen kann und die dort (den Regeln entsprechend) mittels geeigneter Linien zu einem "Strukturschaubild" verknüpft werden (Abb. 3). Jeder Programmbaustein eines Strukturschaubilds entspricht einem "Programmcodeabschnitt" und das gesamte Strukturschaubild somit einem Programm (s. z. B. S. 15, Zn. 5-7; S. 17, 4. Abs. - S. 18, 1. Abs.). So kann der Anwender durch Manipulation graphischer Symbole auf dem Computerbildschirm Programmcode "auf Textbasis" definieren, ohne diesen direkt, also als Text (oder anspruchsgemäß:

"textbasiert"), eingeben zu müssen. Wenn der Anwender aber einen Programmbaustein anwählt (bspw. durch Anklicken), so öffnet sich ein eine Anzeigeoberfläche (bspw. ein Fenster), in dem er den Programmcodeabschnitt dieses Bausteins bearbeiten kann.

2.2 Programmbausteine sind in zwei Kategorien vorgesehen, die "Ablauf" und "Funktion" genannt und zur Definition sequentieller bzw. paralleler Abläufe verwendet werden. In der Kategorie "Ablauf" werden Programmbausteine des Typs "Ablaufbaustein", "Startbaustein", "Ereignisbaustein" und "Endbaustein" beansprucht, in der Kategorie "Funktion" nur einer des Typs "Funktionsbaustein". Ablaufbausteine dürfen nur seriell verknüpft werden und definieren sequentielle Ausführung. Verzweigungen sind vorgesehen. Funktionsbausteine können von Ablaufbausteinen aufgerufen werden und definieren parallele Ausführung. Ein Funktionsbaustein seinerseits kann keinen weiteren Programmbaustein aufrufen. Jeder "Ablauf" muss mit einem Startbaustein beginnen und mit einem Endbaustein enden.

3. Zunächst sei bemerkt, dass der Gegenstand der vorliegenden Ansprüche (beider Anträge) als ein computergestütztes 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 jedoch der Meinung, dass die beanspruchte Erfindung keine nicht-naheliegende "weitere", also über die Verwendung eines Computers hinausgehende technische Wirkung aufweist, und somit ob keinen für die Zuerkennung einer erfinderischen Tätigkeit unablässigen nicht-naheliegenden technischen Beitrag zum Stand der Technik leistet, Artikel 56 EPÜ 1973. 4. Die Erfindung richtet sich auf eine graphische Programmsprache und -umgebung, die es einem Anwender ermöglichen soll, ohne großen Lernaufwand oder besondere Expertise Programmcode zu erzeugen. Die Wirkung, den mentalen Aufwand des Anwenders bei der Programmerstellung zu reduzieren, ist an sich nach Ansicht der Kammer keine technische. Das gilt umso mehr, als sie für alle Programme gleichermaßen angestrebt wird, also unabhängig davon, welchem Zweck das entwickelte Programm dienen soll.

4.1 Beim Programmieren - im Sinne des Formulierens von Programmcode, des "Kodierens" - muss der Programmierer aus dem Repertoire einer Programmiersprache diejenigen Formulierungen wählen, die bei Ausführung des Programms zum gewünschten Ergebnis führen. Die Programmiersprache definiert dabei zum einen, welche Formulierungen überhaupt als "wohlgeformt" zulässig sind (Syntax), und zum anderen, welches "Verhalten" einem Programm zugeschrieben wird (operationale Semantik). Die Wahl der Programmiersprache kann im Einzelfall Einfluss darauf haben, wie leicht (und manchmal ob überhaupt) sich die Lösung eines Problems als ein Programm formulieren lässt.

4.2 Die Tätigkeit des Programmierens selbst jedoch ist nach Ansicht der Kammer ein im Wesentlichen mentaler Vorgang - vergleichbar der Verbalisierung eines Gedankens oder der Formulierung eines mathematischen Sachverhalts in einem Kalkül -, der es mit den Worten der Grossen Beschwerdekammer aus G 0003/08 (Amtsbl. EPA 2011, 10; Gründe 13.5.1) an "weiteren technischen Überlegungen" fehlt. Das gilt wenigstens dann und insoweit als, wie im vorliegenden Fall, die Tätigkeit des Programmierens nicht im Rahmen einer konkreten Anwendung oder Umgebung in kausaler Weise der Erzielung einer technischen Wirkung dient.

4.3 Aus diesem Grund schließt die Kammer, dass die Definition und Bereitstellung einer Programmiersprache oder programmiersprachlicher Mittel per se nicht zur Lösung eines technischen Problems beiträgt.

5. Die Erfindung umfasst die Definition einer graphischen Programmiersprache, deren Programme Strukturschaubilder aus Symbolen und Linien sind, die entsprechend gewisser Regeln zusammengefügt sein müssen (Syntax). Teil dieser Definition ist die Festlegung, wie jeder einzelne Baustein auszuführen ist und wie sich daraus das Ablaufverhalten eines gesamten Programms ergibt (operationale Semantik). Insbesondere die Bereitstellung von Funktionsbausteinen zur parallelen Ausführung und die Festlegung, dass diese von Ablaufbausteinen aufgerufen werden aber ihrerseits keine Programmbausteine aufrufen können, ist nach Ansicht der Kammer ein Teil der definierten Programmiersprache.

5.1 In Ansprüchen 1 und 10 des Hauptantrags nicht Teil der Programmsprache sind nur die Bereitstellung einer "Visualisierungsoberfläche" sowie dass die "Symbole ... unter Berücksichtigung der vorgegebenen Regeln automatisch mittels Linien zur Darstellung der seriellen oder parallelen Abarbeitung miteinander verbunden werden" (Hervorhebung durch die Kammer). Die Kammer rechnet diese Merkmale der Programmierumgebung zu, die den Anwender dabei unterstützt, konkrete Programme einer gegebenen Programmiersprache zu erzeugen.

5.2 Visualisierungsoberflächen sind ein elementarer Bestandteil von Programmierumgebungen aller Art. Darüber hinaus ist es ist eine für den Fachmann allgemein bekannte Tatsache, dass der mechanische Vorgang des Programmierens, also das Erzeugen eines konkreten Programms, aufwändig und fehlerhaft sein kann. Das gilt gleichermaßen für text-basierte wie für graphische Programme, also unabhängig davon, ob ein Programmtext "eingetippt" werden muss oder ob graphische Programmbausteine auf dem Bildschirm angeordnet werden müssen. Die Kammer hält es daher für naheliegend - wie im übrigen auch für grundsätzlich bekannt - dass Entwicklungsumgebungen dem Programmierer, soweit möglich, mechanische Aufgaben bei der Programmierung abnehmen sollen. Im konkreten Fall hält es die Kammer somit auch für naheliegend, dem Benutzer die manuelle Eingabe von Verbindungslinien zwischen Symbolen abzunehmen und diese automatisch vorzunehmen.

5.3 Daher kommt die Kammer zu dem Ergebnis, dass der Gegenstand der Anspruchs 1 gemäß Hauptantrag keine erfinderische Tätigkeit aufweist, Artikel 56 EPÜ 1973. 6. Ansprüche 1 und 10 des Hilfsantrags legen zusätzlich fest, dass jedem Programmbaustein ein Stück Programmcode entspricht, und dass durch "Anwählen" eines Symbols dem Anwender Zugang zu dem Programmcode des entsprechenden Programmsbaustein 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 davon aus, dass dieser Programmcode einer Programmiersprache entspricht, deren Ablaufverhalten vorgegeben und bekannt ist (bspw. BASIC). Somit soll der einem Programmbaustein entsprechende Code das Ablaufverhalten dieses Bausteins über den Umweg der bekannten text-basierten Programmiersprache zu definieren. Die Erfindung ergänzt somit eine text-basierte Programmiersprache um zusätzliche, graphische Ausdrucksmittel, die als Abkürzungen für "Programmcode auf Textbasis" der zugrundeliegenden text-basierten Programmiersprache dienen. Auf diese Weise wird eine Programmiersprache mit textbasierten und graphischen Anteilen definiert. Die Definition solcher graphischer programmiersprachlicher Ausdrucksmittel aber kann, wie oben ausgeführt, nicht als Lösung für ein technisches Problem gelten.

6.2 Dasselbe gilt nach Ansicht der Kammer für den Umstand, dass ein konkreter Programmbaustein den entsprechenden Programmcode nicht eindeutig festlegt, sondern dass dieser - als "vorläufiger Programmcode" - um weitere Angaben (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 Programmierumgebung. Dabei ist die Kammer jedoch der Meinung, dass die text-basierte Bearbeitung 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 Hilfsantrags keine erfinderische Tätigkeit aufweist, Artikel 56 EPÜ 1973.

Entscheidungsformel

Aus diesen Gründen wird entschieden:

Die Beschwerde wird zurückgewiesen. Die Geschäftsstellenbeamtin:

Der Vorsitzende:

B. Atienza Vivancos D. H. Rees