T 0971/07 () of 12.5.2011

Sachverhalt und Anträge

I. Die europäische Patentanmeldung 02 792 774 wurde von der Prüfungsabteilung wegen eines Verstoßes gegen Artikel 123 (2) EPÜ 1973 zurückgewiesen.

II. Des Weiteren erwähnte die Prüfungsabteilung obiter dicta in ihrer Entscheidung, sowohl dass der Anmeldung das Prioritätsrecht nicht zuerkannt werden könne, als auch, dass die beanspruchte Erfindung anscheinend nicht auf einer erfinderischen Tätigkeit beruhe, da sie nur auf für den Fachmann durch sein Allgemeinwissen nahe liegenden Maßnahmen zur schnelleren Datenverarbeitung beruhe.

III. Zusätzlich verwies die Prüfungsabteilung auf das folgende Dokument,

D1 = XP000962443 "SAP INFO - Banken & Versicherungen", Oktober 2002

das nach ihrer Ansicht die grundlegende Struktur des beanspruchten Gegenstands offenbarte.

IV. In der mündlichen Verhandlung vor der Kammer beantragte die beschwerdeführende Anmelderin die Erteilung des Patents mit der zusammen mit der schriftlichen Eingabe vom 11. April 2011 vorgelegten Fassung der Ansprüche.

V. Die unabhängigen Ansprüche 1 und 6 des Antrags lauten wie folgt.

"1. Verfahren zum computerimplementierten Verarbeiten von elektronischen Zahlungsaufträgen, bei dem in einem ersten Schritt ein Auftragseingangsbearbeiter (Input Manager) von einem Vorsystem, das einen Zahlungsauftrag als Datei empfängt, unter Weitergabe von Datei-Informationen aufgerufen wird, in dem Auftragseingangsbearbeiter in dem Zahlungsauftrag enthaltene Gesamtauftragsdaten analysiert, die in dem Zahlungsauftrag enthaltenen Gesamtauftragsdaten in dem Auftragseingangsbearbeiter in zu einer Bearbeitung des Zahlungsauftrags notwendige Zahlungsauftragsdaten und in nicht zur Bearbeitung des Zahlungsauftrags notwendige Buchungsdaten aufgetrennt werden und der Auftragseingangsbearbeiter anhand der Datei-Informationen einen Format-Konverter erkennt, welcher die Zahlungsauftragsdaten in ein einheitliches Metaformat zur Bearbeitung in einer nachgeschalteten Zahlungsabwicklungseinrichtung (Payment Engine) konvertiert, in einem zweiten Schritt die Zahlungsauftragsdaten zur Bearbeitung an die nachgeschaltete Zahlungsabwicklungseinrichtung (Payment Engine) weitergegeben und die Buchungsdaten mit einer Verknüpfungsanweisung in einer Datenbank zwischen- gespeichert werden, in einem dritten Schritt die in das Metaformat konvertierten Zahlungsauftragsdaten in der nachgeschalteten Zahlungsabwicklungseinrichtung formal geprüft, Zusatzinformationen in einer Datenbank abgelegt, für jeden Zahlungsempfänger automatisch eine Leitwegerkennung und eine Clearingvereinbarung ermittelt wird sowie, abhängig von der Clearingvereinbarung, eine interne Bereitstellung eines Zahlungsauftragspostens erfolgt und in einem vierten Schritt automatisch erzeugte Angaben zu einem ausgehenden Zahlungsauftrag an einen Auftragsausgangsbearbeiter (Output Manager) übergeben, von diesem auf ein Zieldatenformat konvertiert und durch die in der Datenbank zwischengespeicherten Daten ergänzt werden.

"6. Vorrichtung zum computerimplementierten Verarbeiten von elektronischen Zahlungsaufträgen mit einem Auftragseingangsbearbeiter (Input Manager), einer Zahlungsabwicklungseinrichtung (Payment Engine), einem Auftragsausgangsbearbeiter (Output Manager) und einer Datenbank (File Handler Datenbank), wobei der Auftragseingangsbearbeiter, nachdem er durch ein einen Zahlungsauftrag als Datei empfangendes Vorsystem unter Weitergabe von Datei-Informationen aufgerufen wurde, eine Analyse der in einem Zahlungsauftrag enthaltenen Gesamtauftragsdaten und eine Trennung der Gesamtauftragdaten in zu einer Bearbeitung des Zahlungsauftrags notwendige Zahlungsauftragsdaten und in nicht zur Bearbeitung des Zahlungsauftrags notwendige Buchungsdaten vornimmt und anhand der Datei-Informationen einen Format-Konverter erkennt, der die Zahlungsauftragsdaten in ein einheitliches Metaformat zur Bearbeitung in der nachgeschalteten Zahlungsabwicklungseinrichtung (Payment Engine) konvertiert, und, wobei die Buchungsdaten mit einer Verknüpfungsanweisung in der Datenbank zwischengespeichert werden, die nachgeschaltete Zahlungsabwicklungseinrichtung die in das Metaformat konvertierten Zahlungsauftragsdaten formal prüft, Zusatzinformationen in einer Datenbank ablegt, für jeden Zahlungsempfänger automatisch eine Leitwegerkennung und eine Clearingvereinbarung ermittelt sowie, abhängig von der Clearingvereinbarung, eine interne Bereitstellung des Zahlungsauftragspostens in der Zahlungsabwicklungseinrichtung vornimmt, und automatisch erzeugte Angaben zu einem ausgehenden Zahlungsauftrag an den Auftragsausgangsbearbeiter (Output Manager) übergibt, die der Auftragsausgangsbearbeiter auf ein Zieldatenformat konvertiert und durch die in der Datenbank zwischengespeicherten Daten ergänzt."

VI. Die Argumente der Beschwerdeführerin lassen sich wie folgt zusammenfassen.

Die in der Entscheidung der Prüfungsabteilung und in der Mitteilung der Kammer bezüglich Artikel 123 (2) EPÜ beanstandeten Ansprüche seien entsprechend geändert und die dort angesprochenen diesbezüglichen Mängel behoben worden.

Die beanspruchte Erfindung beruhe auf der Erkenntnis, dass eine schnellere Abwicklung von Zahlungsaufträgen erzielt werden könne, wenn man eine Trennung der Eingangsdaten in zur Bearbeitung des Auftrags notwendige und nicht-notwendige Daten vornehme, dann die zur Bearbeitung notwendigen Daten in ein Metadatenformat umwandle und diese erst nach Abschluss der Zahlungsbearbeitung und Umwandlung in ein Zieldatenformat wieder mit den entsprechend gekennzeichneten, zur Bearbeitung nicht notwendigen Daten zusammenführte.

Das Argument der Prüfungsabteilung, dass der Fachmann erkannt hätte, dass ein kompakter Datensatz schneller verarbeitbar sei und dass daher die erfindungsgemäßen Maßnahmen für ihn naheliegend gewesen wären, beruhe auf einer rückblickenden Betrachtungsweise. Auch das schon aus Dokument D1 bekannte Zahlungsverfahren ändere daran nichts, denn Dokument D1 gebe keine Hinweise auf die konkrete Realisierung der Vorgehens weise wie sie schrittweise in den Ansprüchen 1 und 6 dargelegt sei.

Entscheidungsgründe

1. Die Beschwerde ist zulässig.

2. Änderungen (Artikel 123 (2) EPÜ)

2.1 Die Prüfungsabteilung hat die Anmeldung auf Grund der Verletzung von Artikel 123 (2) zurückgewiesen. Insbesondere hat die Prüfungsabteilung die Merkmale "... in einem ersten Schritt ... als File analysiert" und "in einem zweiten Schritt ... die Zahlungsauftragsdaten in der nachgeschalteten Zahlungs abwicklungs einrichtung durch Zerlegung des Prozesses in eine Folge von Verarbeitungsschritten und Prüfungen verarbeitet werden, in dem für jeden Zahlungsempfänger automatisch eine Leitwegeerkennung und eine Clearingerkennung ..." beanstandet. Diese gingen über den Inhalt der ursprünglich eingereichten Fassung hinaus, im letzteren Fall speziell deswegen, weil der Wortlaut vielfältige Interpretationsmöglichkeiten erlaube.

2.2 Die gegenständlichen Merkmale sind aus den Ansprüchen entfernt worden und die diesbezügliche Beanstandung der Prüfungsabteilung ist somit behoben.

2.3 Zugleich wurden durch die vorgenommenen Änderungen auch die im Bescheid der Kammer angesprochenen Mängel behoben.

2.3.1 Anspruch 1 als auch Anspruch 6 verlangen jetzt ausdrücklich, dass die Gesamtauftragsdaten zuerst im Auftragseingangs bearbeiter analysiert werden bevor sie in zur Bearbeitung des Zahlungsauftrags notwendige Zahlungsauftragsdaten und zur Bearbeitung des Zahlungsauftrags nicht notwendige Buchungsdaten unterteilt werden.

2.3.2 Es findet jetzt in den Ansprüchen 1 und 6 die Umwandlung der für die Zahlung notwendigen Zahlungsauftragsdaten in ein "einheitliches Metaformat" ihren Niederschlag, wie es auch in den ursprünglich eingereichten Ansprüchen der Fall war.

2.3.3 Ebenfalls wie in den ursprünglich eingereichten Ansprüchen zu finden, wird jetzt in den Ansprüchen verlangt, dass für jeden Zahlungsempfänger automatisch eine Leitwegerkennung und eine Clearingerkennung sowie, abhängig von der Clearingerkennung, eine interne Bereitstellung des Zahlungsauftragspostens erfolgt.

2.3.4 Der letzte Teil der Ansprüche 1 und 6 stellen jetzt jeweils klar, dass es automatisch erzeugte Angaben zu einem ausgehenden Zahlungsauftrag sind, die auf ein Zieldatenformat konvertiert werden.

2.4 Die Kammer sieht damit die Einwände unter Artikel 123 (2) EPÜ als ausgeräumt.

3. Priorität (Artikel 87 bis 89 EPÜ)

3.1 Die Beschwerdeführerin hat die in der Mitteilung der Kammer dargelegten Gründe für die Nicht-Anerkennung der Priorität nicht in Frage gestellt. Das Prioritätsrecht kann dem beanspruchten Gegenstand der vorliegenden Anmeldung nicht zuerkannt werden kann, da die in den Ansprüchen beanspruchten Merkmale der Erfindung weder in der früheren Anmeldung beansprucht worden, noch der Gesamtheit der früheren Anmeldung deutlich entnehmbar sind, wie dies in Artikel 88 (4) EPÜ vorgeschrieben ist. Es folgt, dass Dokument D1 zum Stand der Technik gehört.

4. Patentierbarkeit (Artikel 52 (2) EPÜ)

Das Verfahren des Anspruchs 1 wird mit Bezugnahme auf eine Mehrzahl von im Anspruch ausdrücklich erwähnten technischen Komponenten beansprucht, wie, z.B., ein Auftragseingangsbearbeiter (Input Manager), ein Format-Konverter welcher die Zahlungsauftragsdaten in ein einheitliches Metaformat ... konvertiert, eine Zahlungsabwicklungseinrichtung (Payment Engine) usw. Es bestehen somit keine Zweifel bezüglich des technischen Charakters des beanspruchten Verfahrens. Ipso facto hat auch die in Anspruch 6 in ähnlicher Weise beanspruchte Vorrichtung technischen Charakter.

5. Erfinderische Tätigkeit (Artikel 56 EPÜ 1973)

5.1 Die Ansprüche 1 und 6 definieren ein Verfahren bzw. eine Vorrichtung zum computerimplementierten Verarbeiten von elektronischen Zahlungsaufträgen. Wie schon von der Prüfungsabteilung festgestellt, besteht dieses Verarbeiten aus dem Auftrennen, Konvertieren, Speichern und Kontrollieren von elektronischen Daten, die als Buchungsdaten und Zahlungsauftragsdaten (d.h. nichttechnische Informationen) beschrieben werden.

5.2 Der für die Beurteilung der erfinderischen Tätigkeit nächstliegende Stand der Technik ist durch Dokument D1 gegeben.

5.3 Dokument D1 offenbart in allgemeiner Form die gleiche Struktur wie die des beanspruchten Zahlungsvorgangs, mit Modulen für Input Manager, Prüfung und Prozess-Steuerung, Leitwegsteuerung, Clearing und Output Manager (Siehe Diagramm auf Seite 31 "Payment Engine im SAP Core Banking").

5.4 Dokument D1 umreißt auch schemenhaft den Vorteil einer formatneutralen Verarbeitung, d.h., eines formatunabhängigen und damit allgemein verwendbaren Zahlungsauftrags, da dieser eine einheitliche Verarbeitungslogik ermöglicht (S.30, Spalte 1, letzter Absatz). Auch wird dargelegt, dass Funktionalitäten für Zuordnung und Verteilung von Zahlungsposten bereitgestellt wird, und dass die Einhaltung der STP-Kriterien (IBAN, BIC) Kostensenkungen ermöglicht.

5.5 Die erfinderische Tätigkeit wird beurteilt unter Zugrundelegen des Unterschieds zwischen dem nächstliegenden Stand der Technik und der beanspruchten Erfindung. Nur Merkmale die zum technischem Charakter der Erfindung beitragen, werden bei dieser Beurteilung berücksichtigt.

5.6 Ausgehend von Dokument D1 als nächstliegendem Stand der Technik, ergibt sich als die Aufgabe der Erfindung, eine verfahrensmäßige (Anspruch 1) und gerät-bezogene (Anspruch 6) Ausführung der in Dokument D1 offenbarten Gesamtstruktur zu erstellen, welche eine effiziente Zahlungsbearbeitung erlaubt.

5.7 Die erfindungsgemäßen Unterschiede der beanspruchten Erfindung zur Offenbarung in Dokument D1, welche zur Lösung der gestellten Aufgabe führen sind:

(a) die Analyse der Eingangsdaten und die Aufspaltung dieser Daten in zur Bearbeitung des Zahlungsauftrags notwendige Zahlungsauftragsdaten und zur Bearbeitung des Zahlungsauftrags nicht notwendige Buchungsdaten, wobei die Zahlungsauftragsdaten weiterbearbeitet werden, während die Buchungsdaten lediglich zwischengespeichert werden um nach der Zahlungsbearbeitung mit den betreffenden Zahlungsausgangsdaten zusammengeführt zu werden;

(b) die Konvertierung der zur Zahlungsbearbeitung notwendigen Daten in ein einheitliches Metaformat.

5.8 Die Prüfungsabteilung war der Meinung, dass keiner dieser beiden Unterschiede eine erfinderische Tätigkeit begründen könne. Es sei nämlich für den Fachmann alleine schon auf Grund seines Allgemeinwissens naheliegend, nur diejenigen Daten zu bearbeiten welche zur Bearbeitung notwendig seien und auch diese Bearbeitung selbst in einem Metadatenformat durchzuführen.

5.9 Dem hat die Beschwerdeführerin in für die Kammer überzeugender Weise entgegengesetzt, nicht nur dass das Allgemeinwissen des Fachmanns nicht zu der beanspruchten Lösung führe, sondern dass auch ausgehend von Dokument D1 die Erfindung nicht naheliegend sein kann, da Dokument D1 keine Information darüber enthält, wie sich die dort nur umrissenen Merkmale in einem Zahlungssystem praktisch umsetzen ließen.

Die aus Dokument D1 bekannte Struktur, welche die Elemente Input Manager, Prüfung und Prozess steuerung, Leitwegsteuerung, Clearing und Output manager in dieser Reihenfolge enthält, entspricht generell dem Inhalt der Figur 6 der Anmeldung. Dokument D1 erwähnt auch kurz, dass die Verarbeitung der Zahlungsaufträge formatneutral erfolgt. Es ist jedoch Dokument D1 nicht zu entnehmen,

(a) dass die Eingangsdaten "in zu einer Bearbeitung des Zahlungsauftrags notwendige Zahlungsauftragsdaten und in nicht zur Bearbeitung des Zahlungsauftrags notwendige Buchungsdaten aufgetrennt werden",

(b) dass die format-unabhängige Verarbeitung dadurch erzielt wird, dass die "Zahlungsauftragsdaten in ein einheitliches Metaformat zur Bearbeitung in einer nachgeschalteten Zahlungsabwicklungs einrichtung (Payment Engine) konvertiert" werden,

(c) dass die nicht zur Bearbeitung des Zahlungsauftrags notwendigen "Buchungsdaten mit einer Verknüpfungsanweisung in einer Datenbank zwischengespeichert werden",

(d) und dass zuletzt "automatisch erzeugte Angaben zu einem ausgehenden Zahlungsauftrag an einen Auftragsausgangsbearbeiter (Output Manager)" übergeben, von diesem "auf ein Zieldatenformat konvertiert und durch die in der Datenbank zwischengespeicherten Daten ergänzt" werden.

5.10 Somit fehlt also in Dokument D1 jeglicher Hinweis auf genau die erfindungsgemäßen Schritte die der praktischen Lösung der gestellten Aufgabe dienen, auch wenn dem Fachmann, wie von der Prüfungsabteilung argumentiert, das Problem der effizienteren Daten verarbeitung immer gegenwärtig ist.

5.11 Aus den vorhergehenden Gründen schließt die Kammer, dass weder das in Anspruch 1 beanspruchte Verfahren zur Zahlungs abwicklung, noch die in Anspruch 6 beanspruchte, dem Verfahren entsprechende Vorrichtung zur Zahlungs abwicklung für den Fachmann naheliegend sind.

5.12 Die Kammer entscheidet daher, dass der Gegenstand Ansprüche 1 und 6 auf einer erfinderischen Tätigkeit gemäß Artikel 56 EPÜ 1973 beruht.

ENTSCHEIDUNGSFORMEL

Aus diesen Gründen wird entschieden:

1. Die angefochtene Entscheidung wird aufgehoben.

2. Die Angelegenheit wird and die 1. Instanz mit der Anordnung zurückverwiesen, ein Patent mit folgender Fassung zu erteilen:

(a) Ansprüche 1 bis 13, eingereicht mit Schreiben vom 11. April 2011,

(b) Beschreibung, Zeichnungen wie ursprünglich eingereicht.