Bundesgerichtshof, Urteil vom 01.10.2019, Az. X ZR 139/17

Der Beklagte war bis zum 16. April 2016 Inhaber des mit Wirkung für die [X.] erteilten [X.] Patents 1 259 046 (Streitpatents), das am 22. April 2002 unter Inanspruchnahme der Priorität einer [X.] Patentanmeldung vom 23. April 2001 angemeldet worden ist. Das [X.] wies einen Einspruch gegen das Streitpatent zurück. Die Beschwerde gegen diese Entscheidung blieb erfolglos.

Patentanspruch 1, auf den fünf weitere Ansprüche rückbezogen sind, lautet:

Die Klägerin hat geltend gemacht, der Gegenstand des Streitpatents sei nicht patentfähig. Der Beklagte hat das Streitpatent in der erteilten Fassung und hilfsweise in einer geänderten Fassung verteidigt.

Das Patentgericht hat die Klage abgewiesen. Hiergegen richtet sich die Berufung der Klägerin, die ihren erstinstanzlichen Antrag weiterverfolgt. Der Beklagte tritt dem Rechtsmittel entgegen.

Die zulässige Berufung bleibt erfolglos.

I. Das Streitpatent betrifft eine Anlage zur sicheren Durchführung von Transaktionen zwischen informationsverarbeitenden Systemen.

1. Als Beispiele für Bereiche, in denen solche Transaktionen erfolgen, werden in der [X.]chrift das Online-Banking und der Online-Handel genannt. Im Stand der Technik war es nach Angabe der [X.]chrift bekannt, für die sichere Durchführung von Transaktionen [X.], Passwörter, [X.] (Persönliche Identifikationsnummern) oder [X.]s (Transaktionsnummern) zu verwenden, um den Nutzer zu identifizieren und Transaktionen zu autorisieren. Während [X.] und [X.] bei nachlässiger Handhabung durch den Nutzer ein erhebliches Risiko begründeten, habe sich die Nutzung von [X.]s, die über einen sekundären Leitungsweg übermittelt werden, als relativ sicher erwiesen. Allerdings bestünden auch hier latente Sicherheitsprobleme, etwa wenn eine dem Nutzer zugesendete [X.]-Liste von diesem nicht sicher aufbewahrt werde. Auch bei elektronischer Übermittlung einer [X.] bestünden gewisse Risiken, etwa bei der Fälschung von Anmeldebildschirmen oder in den Fällen, in denen Dritte Zugriff auf das Gerät haben könnten, an das die [X.] übermittelt werde. Es bestehe die Gefahr, dass eine unbefugte Person den kompletten Autorisierungscode erhalte und dadurch in die Lage versetzt werde, eine Transaktion zu autorisieren.

2. Dem Streitpatent liegt vor diesem Hintergrund das technische Problem zugrunde, eine Anlage mit erhöhter Transaktionssicherheit bereitzustellen.

3. Diese Aufgabe soll erfindungsgemäß durch eine Vorrichtung gelöst werden, deren Merkmale sich wie folgt gliedern lassen (Merkmalsgliederung des Patentgerichts in eckigen Klammern):

Der Autorisierungscode ist danach aufgeteilt in einen Sicherheitscode und einen [X.], die auf unterschiedlichen Wegen übermittelt werden. Beide müssen eingegeben und von der Auswerteeinheit als gültig erkannt werden, damit die Transaktion autorisiert wird.

4. Im Hinblick auf einige Merkmale bedarf der Patentanspruch der Erläuterung:

a) Der Begriff der Transaktion ist in der [X.]chrift nicht definiert. Als Beispiele für die Anwendung der Lehre sind dort das Online-Banking, ein Bezahlvorgang im Online-Handel oder die Gewährung des Zutritts zu einem Gebäude genannt. In Absatz 2 der Beschreibung sind mit [X.] und [X.] einige Instrumente benannt, wie sie zur Sicherung etwa von Banküberweisungen, Wertpapierkäufen und -verkäufen und dergleichen eingesetzt werden. Diesen Vorgängen ist gemeinsam, dass sie aus Sicherheitsgründen einer besonderen Autorisierung oder Authentifizierung bedürfen. Charakteristisch für eine Transaktion im Sinne des [X.] ist danach, dass es sich um einzelne Vorgänge innerhalb einer Kommunikation zwischen zwei informationsverarbeitenden Systemen handelt, für die eine besondere, erhöhte Sicherheit gewünscht wird. Dieses Bedürfnis nach einer erhöhten Sicherheit kann sich insbesondere daraus ergeben, dass vermögensrelevante Änderungen vorgenommen oder sensible Daten angezeigt werden sollen.

Die Bedeutung des Begriffs in Patentanspruch 1 ist damit enger als der im Bereich der Datenbanktechnik gebräuchliche Begriff der Transaktion als einer Folge von Programmschritten, die den Datenbestand nach fehlerfreier, vollständiger Ausführung in einem konsistenten Zustand hinterlassen. Zwar wird eine Transaktion im Sinne des [X.] regelmäßig auch eine Veränderung des [X.] bewirken. Nicht jede Veränderung des [X.] ist aber zwangsläufig eine Transaktion im Sinne des [X.]. Erst recht ist mit diesem Begriff nicht jeder Kommunikationsvorgang im [X.], etwa jeder Austausch von Daten nach dem Client-Server-Modell gemeint.

b) Das Patentgericht hat zutreffend angenommen, dass es sich bei einem [X.] im Sinne des [X.] um einen transaktionsspezifischen Code handelt.

Wie sich aus Merkmal 4 ergibt, dienen der Sicherheitscode und der [X.] der Autorisierung der Transaktion, sollen also gewährleisten, dass nur eine berechtigte Person diese auslösen kann. Sicherheitscode wie [X.] müssen daher in einer Beziehung zur Transaktion im oben erläuterten Sinne stehen. Sicherheits- und [X.] sind nach der geschützten Lehre die Instrumente, mit denen dem erhöhten Sicherungsbedürfnis Rechnung getragen wird. Damit handelt es sich beim [X.] - nicht anders als beim Sicherheitscode - um einen Code, der gerade für diese besondere Situation vorgesehen ist. Dies schließt nicht schlechterdings aus, den Code zugleich für andere Zwecke zu nutzen. Es darf sich aber nicht um ein Mittel handeln, mit dem die Kommunikation zwischen den beteiligten informationsverarbeitenden Systemen in ihrer Gesamtheit geschützt oder verwaltet wird. Der [X.] muss vielmehr in einzelnen dafür vorgesehenen Situationen als weiteres Sicherungsmittel zu den Mitteln für die grundlegende Absicherung der Kommunikationsbeziehung hinzutreten.

II. Das Patentgericht hat seine Entscheidung im Wesentlichen wie folgt begründet:

Der Gegenstand von Patentanspruch 1 werde dem Fachmann, der von der [X.] [X.] 197 18 103 ([X.]) oder von der [X.] Patentanmeldung 1 065 634 ([X.]) ausgehe, weder durch das Buch von [X.] und [X.] ([X.] 3.0 in 21 Days, [X.]), noch durch die Aufsätze von [X.] (Techniken für Web-basierte Datenbankanwendungen, Informatik Forsch. Entw. 1998, [X.] ff., [X.]) und [X.] ([X.]: Preserving State on the [X.], [X.] 1997, [X.] ff., [X.]) nahegelegt. In diesen Dokumenten gehe es jeweils nur um die netzwerkseitige Verwaltung von Verbindungen zwischen Server und Client. Die dafür erörterten Instrumente wie [X.], Cookies und Statusparameter mit User-ID beträfen jedoch jeweils die Sitzung (session) und seien nicht transaktionsspezifisch. Aus ihnen ergebe sich daher keine Anregung, einen [X.] vorzusehen, der transaktionsspezifisch sei und der Autorisierung einer Transaktion diene. Zudem vermittele keine dieser Schriften eine technische Lehre, wonach zwei Codegeneratoren und zwei [X.] dem Erzeugen und Senden eines Sicherheits- und eines [X.] dienten.

Eine solche Anregung ergebe sich auch nicht aus dem US-Patent 6 061 741 ([X.]). Der Fachmann, der von [X.] oder [X.] ausgehe, habe bereits keinen Anlass, die [X.] heranzuziehen, denn dieses Dokument befasse sich nicht mit der Autorisierung von Transaktionen, sondern mit der Synchronisation von verbindungslosen Anwendungen in Client-Server-Systemen.

III. Diese Beurteilung hält der Überprüfung im Berufungsrechtszug stand.

1. Das Patentgericht hat mit zutreffenden Erwägungen, die von der Berufung nicht angegriffen werden, dargelegt, warum der Fachmann, der von [X.] oder [X.] ausgeht, durch [X.], [X.] oder [X.] keine Anregung erhält, einen [X.] vorzusehen, der der Autorisierung einer Transaktion dient und über das primäre Netz an das Terminal übertragen wird.

2. Entgegen der Auffassung der Klägerin wurde dem Fachmann, der von [X.] oder [X.] ausgeht, auch durch [X.] keine solche Anregung vermittelt.

a) Zutreffend hat das Patentgericht angenommen, dass [X.] oder [X.], die unter den hier interessierenden Aspekten weitgehend übereinstimmen, den Ausgangspunkt der Bemühungen des Fachmanns darstellten.

[X.] schlägt für die Autorisierung von Transaktionen in Datenübertragungssystemen, etwa für das Online-Banking, vor, dass dem Benutzer, zu dem mittels informationsverarbeitender Systeme, etwa über das [X.], unter Nutzung eines Passworts oder dergleichen eine Verbindung aufgebaut wurde, über einen anderen Übertragungsweg eine [X.] übermittelt wird, die der Benutzer eingibt, die sodann überprüft wird und bei deren Gültigkeit die Autorisierung der Transaktion erfolgt. Als Beispiele sind dort die Übersendung einer [X.] an ein Mobiltelefon, an einen Pager oder ein Faxgerät aufgeführt. Die dort beschriebene Vorgehensweise nimmt die Merkmale 1, 2a bis 2c und 3a und 3b von Anspruch 1 des [X.] vorweg. Die [X.] entspricht dem Sicherheitscode im Sinne von Merkmal 2c und 3b.

Nicht offenbart ist dagegen die Erzeugung und Übermittlung eines [X.] über das primäre Netz, die Ausgabe und Eingabe dieses [X.] und dessen Prüfung zur Autorisierung der Transaktion.

b) [X.] vermittelte dem Fachmann nicht die Anregung, zur Erhöhung der Sicherheit bei der Durchführung von Transaktionen zusätzlich zu einem Sicherheitscode, der über ein sekundäres Netz übermittelt wird, einen [X.] über das primäre Netz zu übermitteln und beide Codes für die Autorisierung der Transaktion einzusetzen.

aa) [X.] erläutert, dass es in Systemen wie dem [X.], in dem die Verbindung zwischen Client und Server nicht dauerhaft besteht, sondern immer wieder unterbrochen und wiederhergestellt wird, vielfach eines Mechanismus zur Synchronisierung der Verbindung bedarf. Dieser solle gewährleisten, dass Server und Client wechselseitig prüfen und erkennen können, auf welchem Stand sich der jeweils andere Teil befindet. Auf diese Weise solle etwa sichergestellt werden, dass die Reaktion eines Verbindungspartners auf eine bestimmte Anfrage richtig zugeordnet werden kann, obwohl die Kommunikation zwischen Client und Server immer wieder unterbrochen wird.

In [X.] ist zwar verschiedentlich auch von Transaktionen (transactions) die Rede. Dieser Begriff bezeichnet dort jedoch, wie sich aus dem Zusammenhang der [X.] ergibt, nicht einzelne Vorgänge mit erhöhtem Sicherheitsbedürfnis, sondern grundsätzlich jeden Schritt eines Kommunikationszyklus oder einer Sitzung (s. insbesondere [X.]. 2 [X.] 46 f., [X.]. 3 [X.] 33 ff.).

[X.] schlägt vor, zur Synchronisierung der Verbindung Sitzungstoken zu verwenden, die einen Client-Token und einen Panel-Token umfassen. Bei einem Client-Token handelt es sich um einen Code, der dazu dient, den Client zu identifizieren, bei einem Panel-Token um einen Code, der Informationen über den aktuellen Zustand dieses Clients vermittelt. Ein solcher Token kann nach [X.] etwa durch die Bildung einer Prüfsumme erstellt werden, die den zuletzt angezeigten Bildschirminhalt repräsentiert.

bb) [X.] spricht darüber hinaus die Möglichkeit an, solche Token zu nutzen, um bestimmte Objekte mit einer „Flagge“ unverwechselbar zu kennzeichnen und weiter vorzusehen, dass ein Anwender über eine bestimmte, „passende“ Signatur verfügen müsse, um in Bezug auf dieses Objekt als berechtigt angesehen zu werden ([X.]. 2, [X.] 49 ff.).

Damit ist zwar aufgezeigt, dass solche Token nicht nur zur Synchronisation genutzt werden können, sondern auch für andere Zwecke, etwa zur Prüfung von Berechtigungen. Entgegen der Auffassung der Klägerin ergab sich daraus jedoch nicht die Anregung, die in [X.] offenbarten Token als zusätzliches Sicherungsmittel für Kommunikationsvorgänge der in [X.] und [X.] offenbarten Art einzusetzen.

Zwar war es im Stand der Technik bekannt, unterschiedliche Maßnahmen zur Berechtigungsprüfung vorzusehen und für einzelne, besonders sicherungsbedürftige Vorgänge mehrere solcher Instrumente nebeneinander zum Einsatz zu bringen. Daraus ergab sich aber nicht die Anregung, die in [X.] in erster Linie für [X.] und damit zur Absicherung der Kommunikationsbeziehung insgesamt eingesetzten Token als zusätzliches Sicherungsmittel für besonders sicherungsbedürftige Vorgänge einzusetzen. Der in [X.] enthaltene Hinweis, dass solche Token auch zur Authentifizierung eines Benutzers eingesetzt werden können, mag dem Fachmann Anlass gegeben haben, sie anstelle eines Passworts, einer [X.] oder möglicherweise einer [X.] in Betracht zu ziehen. Eine Anregung, die in [X.] und [X.] offenbarten Vorgehensweisen, bei denen die [X.] aus Sicherheitsgründen auf einem separaten Weg übertragen wird, dahin zu ergänzen, dass zusätzlich auf dem primären Übermittlungsweg ein Token übersendet und zusammen mit der [X.] zur Autorisierung eines besonders sicherungsbedürftigen Vorgangs herangezogen wird, ergab sich indes auch daraus nicht.

IV. [X.] beruht auf § 121 Abs. 2 [X.] sowie § 97 Abs. 1 ZPO.