BGH, 10. Zivilsenat — X ZR 65/24

Die Beklagte ist Inhaberin des mit Wirkung für die Bundesrepublik Deutschland erteilten europäischen Patents 2 966 605 (Streitpatents), das am 7. Juli 2014 angemeldet wurde und die Authentifizierung eines Benutzers betrifft.

Patentanspruch 1, auf den neun Ansprüche zurückbezogen sind, lautet in der Verfahrenssprache:

Patentanspruch 11 schützt sinngemäß ein System zur Ausführung eines solchen Verfahrens.

Die Klägerin zu 1, die zusammen mit einem verbundenen Unternehmen wegen Verletzung des Streitpatents in Anspruch genommen wird, hat mit ihrer am 9. Dezember 2021 erhobenen Klage geltend gemacht, der Gegenstand des Streitpatents sei nicht patentfähig. Die ebenfalls mit ihr verbundene Klägerin zu 2 hat mit ihrer am 3. Juni 2022 erhobenen Klage im Wesentlichen dieselben Angriffe gegen das Streitpatent geführt. Die Beklagte hat beantragt, die Klage der Klägerin zu 2 als unzulässig abzuweisen, und das Streitpatent gegenüber beiden Klägerinnen wie erteilt sowie hilfsweise in vier geänderten Fassungen verteidigt.

Das Patentgericht hat die beiden Verfahren am 23. März 2023 miteinander verbunden und das Streitpatent mit dem angefochtenen Urteil für nichtig erklärt.

Mit ihrer dagegen gerichteten Berufung verfolgt die Beklagte ihr erstinstanzliches Begehren weiter. Die Klägerinnen treten dem Rechtsmittel entgegen.

Das Rechtsmittel ist zulässig, aber nicht begründet.

I. Entgegen der Auffassung der Beklagten ist auch die von der Klägerin zu 2 erhobene Klage zulässig.

1. Wie das Patentgericht zu Recht ausgeführt hat und auch die Beklagte im Ausgangspunkt nicht in Zweifel zieht, kann ein in Kraft stehendes Patent grundsätzlich von jedermann mit der Nichtigkeitsklage angegriffen werden.

Dem liegt die Erwägung zugrunde, dass der Nichtigkeitskläger im Interesse der Allgemeinheit daran handelt, dass zu Unrecht erteilte technische Schutzrechte beseitigt werden (BGH, Urteil vom 21. Juli 2022 - X ZR 110/21, GRUR 2022, 1628 Rn. 12 - Stammzellengewinnung).

2. Entgegen der Auffassung der Berufung ist die Klage der Klägerin zu 2 auch nicht unter dem Aspekt des Rechtsmissbrauchs unzulässig.

a) Nach der Rechtsprechung des Bundesgerichtshofs kann die zeitgleiche Verfolgung desselben wettbewerbsrechtlichen Anspruchs durch zwei Konzernunternehmen in zwei gesonderten Verfahren missbräuchlich sein, sofern kein vernünftiger Grund für diese Vorgehensweise ersichtlich ist (BGH, Urteil vom 6. April 2000 - I ZR 76/98, BGHZ 144, 165 = GRUR 2000, 1089, juris Rn. 21 - Missbräuchliche Mehrfachverfolgung; Urteil vom 26. Juni 2008 - I ZR 221/05, GRUR 2008, 915 Rn. 11 - 40 Jahre Garantie). Ein Missbrauch kann auch dann vorliegen, wenn zwei Klagen zeitlich versetzt erhoben werden, der Kläger des zweiten Verfahrens sich aber ohne weiteres dem ersten Verfahren hätte anschließen können (BGH, Urteil vom 20. Dezember 2001 - I ZR 15/98, GRUR 2002, 713 Rn. 22 - Zeitlich versetzte Mehrfachverfolgung).

b) Diese Grundsätze können auf eine Patentnichtigkeitsklage nicht ohne weiteres übertragen werden.

Im Patentnichtigkeitsverfahren ermöglichen § 84 Abs. 2 Satz 2 und § 121 Abs. 2 Satz 2 PatG eine von den §§ 91 bis 101 ZPO abweichende Kostenentscheidung, wenn die Billigkeit dies erfordert. Dem für die Bejahung eines Missbrauchs in Wettbewerbsstreitigkeiten maßgeblichen Umstand, dass das Kostenrisiko für den Beklagten durch eine zweite Klage im Vergleich zu einem Beitritt als zweiter Kläger zu einem bereits anhängigen Verfahren erheblich erhöht wird, kann regelmäßig schon auf dieser Grundlage angemessen Rechnung getragen werden.

Einer weitergehenden Einschränkung der grundsätzlich jedermann zustehenden Befugnis zur Erhebung einer Nichtigkeitsklage bedarf es vor diesem Hintergrund jedenfalls in der Regel nicht.

Besondere Umstände, die im Streitfall zu einer abweichenden Beurteilung führen könnten, sind nicht ersichtlich.

II. Das Streitpatent betrifft die Authentifizierung eines Benutzers.

1. Nach der Beschreibung des Streitpatents fanden biometrische Lesegeräte im Stand der Technik zunehmend Verbreitung, sogar auf Smartphones.

Im Allgemeinen werde eine damit ermöglichte biometrische Authentifizierung lediglich für lokale Anwendungen eingesetzt, zum Beispiel um den Zugriff auf das Endgerät selbst zu kontrollieren. Externen Anwendungen werde - auch aus Sicherheitsgründen - kein direkter Zugriff von außen auf die biometrischen Lesegeräte gewährt. Um eine biometrische Authentifizierung zu ermöglichen, müssten die Anwendungen zumindest teilweise auf das Endgerät verlagert werden. Dies sei wirtschaftlich kaum sinnvoll (Abs. 2).

Ein aus der europäischen Patentanmeldung 1 102 150 bekanntes Verfahren lasse nicht die Bestätigung bestimmter Transaktionen zu, sondern lediglich die allgemeine Identifizierung des Nutzers. Zudem müsse die Anwendung die Adresse des mobilen Endgeräts ermitteln oder kennen; dementsprechend müsse zwischen der Anwendung und dem mobilen Endgerät ein direktes Vertrauen hergestellt werden, etwa durch Schlüsselaustausch (Abs. 3).

2. Das Streitpatent betrifft vor diesem Hintergrund das technische Problem, die Vorteile biometrischer Authentifizierungen auf möglichst einfache Weise für externe Anwendungen zu eröffnen.

3. Zur Lösung schlägt das Streitpatent in Anspruch 1 ein Verfahren vor, dessen Merkmale sich wie folgt gliedern lassen:

4. Einige Merkmale bedürfen der näheren Erörterung.

a) Eine Authentifizierung im Sinne von Patentanspruch 1 ist ein Vorgang, bei dem die Identität eines Benutzers überprüft wird.

b) Eine externe Anwendung im Sinne von Patentanspruch 1 ist eine Software, die unabhängig von der Software ausgeführt wird, die auf dem mobilen Endgerät die in Merkmalsgruppe 3 vorgesehenen Schritte ausführt.

aa) Die Beschreibung des Streitpatents enthält keine ausdrückliche Definition dieses Begriffs. Soweit dort von einer externen Anwendung die Rede ist, handelt es sich um eine Anwendung, die nicht auf dem mobilen Endgerät im Sinne von Merkmalsgruppe 3 ausgeführt wird.

Die Erläuterungen zum Stand der Technik unterscheiden zwischen externen Anwendungen und Anwendungen auf dem Endgerät (Abs. 2).

Diese Unterscheidung liegt auch dem in der Beschreibung geschilderten Ausführungsbeispiel zu Grunde, das in der nachfolgend wiedergegebenen Figur 1 schematisch dargestellt ist.

Bei diesem Beispiel ist die externe Anwendung (3) eine Internet-Anwendung, deren Benutzerschnittstelle in Form eines Clients (5) auf einem Notebook (2) angezeigt bzw. ausgeführt wird (Abs. 21 Sp. 8 Z. 50-51). Die in Merkmalsgruppe 3 vorgesehenen Schritte werden auf dem mobilen Endgerät (10) ausgeführt, also auf einem anderen Gerät als demjenigen, auf dem die externe Anwendung ausgeführt wird.

bb) Ob eine Software auch dann als externe Anwendung im Sinne von Merkmal 1 angesehen werden kann, wenn sie zwar auf dem mobilen Endgerät im Sinne von Merkmalsgruppe 3 ausgeführt wird, aber von anderen darauf aktiven Anwendungen unabhängig ist und mit diesen nicht in unmittelbaren Kontakt treten kann, braucht der Senat nicht zu entscheiden.

Diese Frage ist für die Entscheidung über den Rechtsbestand nicht erheblich.

cc) Patentanspruch 1 schließt nicht aus, dass die Benutzeraktion, die zu der in Merkmal 1 vorgesehenen Anfrage führt, von dem mobilen Endgerät (10) ausgeht, das zur Authentifizierung eingesetzt wird.

Bei dem in Figur 1 dargestellten Ausführungsbeispiel wird die im Internet angesiedelte externe Anwendung (3) zwar nicht vom mobilen Endgerät (10) aufgerufen, sondern vom Notebook (2). Diese Ausgestaltung hat in Patentanspruch 1 aber keinen Niederschlag gefunden.

Patentanspruch 1 sieht als ersten Verfahrensschritt eine Anfrage vor, die von der externen Anwendung (3) übermittelt wird. Auf welche Weise und von welchem Gerät aus die externe Anwendung (3) dazu veranlasst wird, diesen Schritt auszuführen, bleibt offen.

c) Identifikationsdaten im Sinne von Merkmal 1 sind Daten, anhand derer ein Benutzer identifiziert und die Adresse eines mit diesem Benutzer verknüpften mobilen Endgeräts ermittelt werden kann.

aa) Patentanspruch 1 gibt nicht näher vor, welche Daten zur Identifizierung des Benutzers einzusetzen sind. Damit kommt jede Angabe in Betracht, die einem bestimmten Benutzer zugeordnet werden kann.

Als hierfür geeignete Benutzeridentifikation kommt zum Beispiel eine Karten- oder Kontonummer in Betracht (Abs. 23 Z. 30 f.).

Um auch nach dem Wechsel des mobilen Endgeräts oder bei Verwendung mehrerer mobiler Endgeräte eine Authentifizierung ohne Anpassung der Anfrage zu ermöglichen, ist es günstig, wenn die Identifikationsdaten eine von der Adresse des mobilen Endgeräts unabhängige Benutzerkennung enthalten (Abs. 17).

Patentanspruch 1 gibt diese speziellen Ausgestaltungen nicht zwingend vor.

bb) Aus dem Zusammenhang mit Merkmal 2 ergibt sich, dass die Identifikationsdaten es ermöglichen müssen, die Adresse eines mit dem Benutzer (1) verknüpften mobilen Endgeräts (3) zu ermitteln.

Nach der Beschreibung kann dies dadurch erreicht werden, dass die Identifikationsdaten einen Benutzer identifizieren, so dass die durch diesen Benutzer registrierten mobilen Endgeräte ermittelt werden können. Die Identifikationsdaten können auch auf andere Weise auf das dem Benutzer zugeordnete mobile Endgerät verweisen (Abs. 10 Sp. 4 Z. 26-32).

Bei dem in Figur 1 dargestellten Ausführungsbeispiel greift ein Server (7), auf dem ein Authentifizierungsdienst (8) ausgeführt wird, auf einen als Datenbank eingerichteten Speicher (9) zu und ermittelt anhand der ihm übermittelten Identifikationsdaten und der in der Datenbank hinterlegten Daten die Adresse eines mobilen Endgeräts (Abs. 21 Sp. 9 Z. 10-22).

Merkmal 2 gibt insoweit zwingend vor, dass die Adresse auf Basis der Identifikationsdaten ermittelt wird, lässt aber offen, auf welche Weise dies geschieht. Insbesondere ist nicht erforderlich, dass der Authentifizierungsdienst (8) die Adresse mit Hilfe einer Datenbank ermittelt oder dass diese Datenbank gegebenenfalls auf demselben Rechner angesiedelt ist.

cc) Als Adresse kommen alle Angaben in Betracht, über die mit dem mobilen Endgerät Kontakt aufgenommen werden kann, zum Beispiel eine IP-Adresse, eine Telefonnummer, eine Hardware-Adresse oder vergleichbare Angaben (Abs. 10 Sp. 3 Z. 5-9).

d) Zu Recht ist das Patentgericht davon ausgegangen, dass Merkmal 2 nicht vorgibt, auf welchem Weg der Authentifizierungsdienst (8) die Anforderung (20) mit der Transaktionskennung an das mobile Endgerät (10) übermittelt.

aa) Bei dem in Figur 1 dargestellten Ausführungsbeispiel erfolgt die Übermittlung auf direktem Wege, ohne Beteiligung der externen Anwendung (3). Diese Ausgestaltung hat in Patentanspruch 1 keinen Niederschlag gefunden.

Die in Merkmal 2 vorgesehene Ermittlung einer Adresse des mobilen Endgeräts (10) mag die Möglichkeit eröffnen, dass der Authentifizierungsdienst (8) in direkten Kontakt mit dem Endgerät (10) tritt. Dies ist indes nicht zwingend erforderlich. Eine auf diese Weise ermittelte Adresse eröffnet auch die Möglichkeit, eine Verbindung mit dem Endgerät (10) unter Vermittlung anderer Geräte oder Anwendungen aufzubauen. Patentanspruch 1 enthält auch hierzu keine näheren Vorgaben.

bb) Entgegen der Auffassung der Berufung gibt Patentanspruch 1 nicht zwingend vor, dass der Authentifizierungsdienst (8) als Vermittler das mobile Endgerät (10) und die externe Anwendung (3) voneinander abschirmt.

Bei dem in Figur 1 dargestellten Ausführungsbeispiel ist eine solche Abschirmung zwar möglich. Diese Anforderung hat in Patentanspruch 1 aber keinen Niederschlag gefunden.

Dem Begriff "übermittelt" lässt sich vor dem oben aufgezeigten Hintergrund nicht entnehmen, dass der Authentifizierungsdienst als Vermittler agieren muss und dass eine Abschirmung zwischen dem mobilen Endgerät (10) und der externen Anwendung (3) zwingend erforderlich ist.

e) Vor diesem Hintergrund reicht es zur Ermittlung einer Adresse im Sinne von Merkmal 2 aus, wenn der Authentifizierungsdienst (8) anhand der gemäß Merkmal 1 übermittelten Identifikationsdaten Informationen gewinnen kann, mit deren Hilfe er eine andere Anwendung dazu veranlassen kann, die Anforderung (20) an das mobile Endgerät (10) weiterzuleiten.

Dies kann etwa dadurch geschehen, dass die Anforderung (20), die der Authentifizierungsdienst (8) an eine andere Anwendung zum Zwecke der Weiterleitung übermittelt, eine aus den Identifikationsdaten entnommene oder auf deren Grundlage erstellte Kennung enthält, anhand derer die andere Anwendung erkennen kann, an welches mobile Endgerät die Anforderung weitergeleitet werden muss.

f) Die in den Merkmalen 3 bis 4.2 vorgesehenen Verfahrensschritte dienen der Authentifizierung des Benutzers mit Bezug auf die von der externen Anwendung (3) übermittelte Anfrage.

aa) Die Identität des Benutzers wird nach den Merkmalen 3.1 und 3.2 anhand eines biometrischen Merkmals überprüft.

Hierfür kommen nach der Beschreibung zum Beispiel ein Fingerabdruck, ein Iris-Scan, eine Gesichtserkennung, eine DNA-Analyse (Abs. 10 Sp. 4 Z. 44-46) oder eine Kombination mehrerer solcher Merkmale (Abs. 15 Sp. 7 Z. 7-14) in Betracht. Denkbar ist auch, dass zwei unterschiedliche Benutzer hintereinander zur Eingabe eines solchen Merkmals an demselben mobilen Endgerät aufgefordert werden (Abs. 15 Sp. 7 Z. 14-17).

bb) Eine erfolgreiche Überprüfung des eingegebenen Sicherheitsmerkmals hat nach Merkmal 4.1 zur Folge, dass das mobile Endgerät (10) Zugriff auf einen darauf gespeicherten privaten Schlüssel (13) gewährt, mit diesem (in Merkmal 4.2 versehentlich mit dem Bezugszeichen 14 versehenen) Schlüssel die vom Authentifizierungsdienst (8) übermittelte Transaktionskennung signiert und die signierte Kennung an den Authentifizierungsdienst (8) zurück übermittelt.

Die Signatur kann zum Beispiel dadurch erfolgen, dass die Transaktionskennung oder eine daraus abgeleitete Folge von Bits (Hash) mit dem privaten Schlüssel (13) verschlüsselt und das Ergebnis als Signatur an die Transaktionskennung angehängt wird (Abs. 21 Sp. 10 Z. 9-13).

Der Authentifizierungsdienst kann die Signatur überprüfen, indem er sie mit einem im Speicher (9) abgelegten, mit dem privaten Schlüssel (13) korrespondierenden öffentlichen Schlüssel entschlüsselt und das Ergebnis mit der Transaktionskennung bzw. deren Hash vergleicht (Abs. 21 Sp. 10 Z. 15-22). Wenn die Werte übereinstimmen, ist belegt, dass ein befugter Benutzer auf das gemäß Merkmal 2 ermittelte mobile Endgerät (10) zugegriffen hat, und zwar in Reaktion auf die gemäß Merkmal 2 übersandte Anforderung (20) mit der darin enthaltenen Transaktionskennung.

Patentanspruch 1 gibt nicht im Einzelnen vor, auf welche Weise die Transaktionskennung zu signieren und die Signatur zu verifizieren ist.

cc) Wie Merkmal 2 sieht auch Merkmal 4.2 nicht zwingend vor, dass die signierten Daten unmittelbar an den Authentifizierungsdienst übermittelt werden.

Patentanspruch 1 gibt auch in diesem Zusammenhang nicht vor, auf welchem Weg und auf welche Art die Übermittlung erfolgt. Damit ist ein Versand über Zwischenstationen möglich.

dd) Entgegen der Auffassung der Berufung ist nicht ausgeschlossen, dass das Endgerät (10) weitere Informationen an den Authentifizierungsdienst (8) übermittelt.

Aus Merkmal 5 ergibt sich, dass der Authentifizierungsdienst (8) die von der externen Anwendung (3) übermittelte Anfrage (18) schon dann bestätigt, wenn die vom mobilen Endgerät (10) übersandte Signatur authentisch ist. Daraus folgt nicht zwingend, dass keine weiteren Überprüfungen erfolgen dürfen, bevor die Bestätigung (26) übermittelt wird.

5. Das in Patentanspruch 11 geschützte System wird durch seine Eignung für das in Anspruch 1 geschützte Verfahren geprägt. Dieser Gegenstand unterliegt derselben Beurteilung wie derjenige von Patentanspruch 1.

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

Der Gegenstand von Patentanspruch 1 sei durch einen Entwurf der Spezifikation für ein Universal Authentication Framework (Fido Alliance, Specification Set fido-uaf-v1.0-rd-20140209, archiviert unter archive.org am 2. März 2014, https://web.archive.org/web/20140302045607/http:/fidoalliance.org/specifications/download, NK5a bis NK5f) vollständig vorweggenommen.

NK5c zeige in Abschnitt 3.4 und Figur 3.4 ein Verfahren zur Authentifizierung eines Nutzers. Dabei greife ein Nutzer auf eine als RP Web APP bezeichnete Anwendung zu, die daraufhin eine Anfrage mit Nutzerdaten an einen Authentifizierungsdienst sende, der als FIDO-Server implementiert sei. Der Authentifizierungsdienst erzeuge eine Authentifizierungsanforderung. Diese werde an einen Authenticator weitergeleitet, ein Gerät, das den Nutzer verifiziere und kryptographische, für eine Authentifizierung bedeutsame Daten enthalte. Die Anforderung enthalte unter anderem zwei mit KeyID bzw. AAID bezeichnete Kennungen. Diese ließen auf einen bestimmten Authenticator schließen, der auf dem FIDO-Server für einen Nutzer bzw. dessen Gerät registriert sei. Damit der FIDO-Server einen registrierten Nutzer bzw. dessen Gerät ermitteln könne, sei es unumgänglich, dass die Anfrage der RP Web APP Daten enthalte, die eine Zuordnung zu einem Nutzer bzw. seinem Gerät erlaube. Wenn lediglich KeyID und AAID übermittelt würden, müssten diese entsprechende Angaben umfassen. Weiter sehe NK5c vor, dass ein Gerät des Nutzers als Authenticator bei dem Authentifizierungsdienst registriert sei. Für das Nutzergerät seien eine KeyID und eine AAID im Authentifizierungsdienst gespeichert, die der FIDO-Server anhand der mit der Anforderung übermittelten Daten ermittle. Damit nehme er eine Zuordnung zu dem anfordernden Gerät und implizit auch zu einer Adresse desselben vor. Der FIDO-Server leite die Anforderung über die externe Anwendung an das Nutzergerät weiter. Die Anforderung umfasse eine Zuordnung zu einem eindeutigen Authenticator, also zu einem Nutzer. Darüber hinaus beinhalte sie eine als Challenge bezeichnete Angabe, in der eine Transaktionskennung liege. Außerdem zeige NK5c die Übermittlung einer Anforderung zur Eingabe eines biometrischen Sicherheitsmerkmals vom Authentifizierungsdienst an das Gerät des Nutzers, die Eingabe desselben sowie dessen lokale Überprüfung. Der Authenticator könne etwa in einem Mobiltelefon enthalten sein. Dabei verließen die Daten des biometrischen Sicherheitsmerkmals das Mobiltelefon nicht. Sei die Prüfung des biometrischen Sicherheitsmerkmals erfolgreich, werde die Challenge signiert und als "Final Challenge" dem FIDO-Server übermittelt. NK5 offenbare schließlich eine Prüfung der Signatur durch den Authentifizierungsdienst und eine Weitergabe des Ergebnisses der Prüfung an die Anwendung, welche den begehrten Zugriff auf eine Website gewähre.

Die mit den Hilfsanträgen verteidigten Gegenstände seien ausgehend von NK5c durch die US-Patentanmeldung 2013/0262858 (NK6) nahegelegt gewesen. Deshalb könne offenbleiben, ob diese Gegenstände über den Inhalt der eingereichten Unterlagen hinausgingen.

IV. Dies hält der Überprüfung im Berufungsverfahren stand.

1. Zutreffend ist das Patentgericht zu dem Ergebnis gelangt, dass das Anlagenkonvolut NK5 den Gegenstand von Patentanspruch 1 in der erteilten Fassung vorwegnimmt.

a) Die gemeinsam veröffentlichten und aufeinander Bezug nehmenden Dokumente NK5a bis NK5f enthalten den Entwurf einer Spezifikation für ein als FIDO Universal Authentication Framework (UAF) bezeichnetes System, das Onlinediensten und Websites die Möglichkeit einer starken Authentifizierung ermöglichen soll. Hierzu werden Komponenten, Protokolle und Schnittstellen definiert (NK5b S. 1 Z. 16-21).

aa) Die grundlegenden Komponenten sind in der nachfolgend wiedergegebenen Figur 2.3 (NK5c S. 11) schematisch dargestellt.

Als User Agent wird eine Anwendung bezeichnet, die auf dem Endgerät eines Benutzers aktiv ist. Dies kann zum Beispiel ein Webbrowser oder eine mobile App sein (NK5a S. 16 Z. 352-354).

Der FIDO Client ist eine Softwareeinheit, die Nachrichten nach den in NK5c spezifizierten Protokollen (UAF und U2F) auf dem Endgerät verarbeitet. Sie kann in den User Agent integriert (implemented) oder als eigenständige Software ausgestaltet sein, die von mehreren User Agents genutzt wird (NK5a S. 11 Z. 195-201).

Der FIDO Authenticator ist eine Authentifizierungseinheit (authentication entity), die die Anforderungen der FIDO Alliance erfüllt. Er verwaltet die für die Authentifizierung erforderlichen kryptographischen Daten (NK5a S. 10 Z. 178-181). Als Authenticator kommt zum Beispiel ein Fingerabdrucksensor in einem mobilen Gerät wie etwa Laptop, Telefon oder Tablet in Betracht (NK5d S. 9 Z. 81 und 95), aber auch ein Mobiltelefon, das als Authenticator für ein anderes Gerät fungiert, oder ein USB-Stick mit eingebauter Verifikation (NK5d S. 9 Z. 83 f.).

Als Relying Party wird eine Website oder eine andere Einheit bezeichnet, die ein FIDO-Protokoll nutzt, um Benutzer direkt zu identifizieren (NK5a S. 13 Z. 277-281).

Als Web App oder Web Application wird ein Programm bezeichnet, das http-Anfragen übermittelt oder beantwortet. Ein Teil eines solchen Programms wird auf dem Endgerät ausgeführt, ein anderer Teil auf dem Server der Relying Party (NK5a S. 17 Z. 370-381).

Der FIDO Server ist eine Software, die typischerweise in der Infrastruktur der Relying Party installiert ist und den Anforderungen an einen UAF-Protokoll-Server entspricht (NK5a S. 11 Z. 211-213).

Das UAF-Protokoll ermöglicht einen passwortlosen und durch mehrere Faktoren geschützten Zugang. Die Benutzer können ihre Endgeräte bei dem Onlinedienst registrieren, indem sie einen lokalen Authentifizierungsmechanismus auswählen, etwa das Wischen (swiping) mit einem Finger, einen Blick in die Kamera, Spracheingabe in ein Mikrofon, Eingabe einer PIN oder dergleichen. Nach der Registrierung braucht der Benutzer lediglich die lokale Authentifizierungshandlung vorzunehmen, um sich bei dem Dienst zu authentifizieren. Hierbei können auch mehrere Mechanismen eingesetzt werden, etwa Fingerabdruck und PIN (NK5b S. 5 Z. 75-84).

bb) Das UAF-Protokoll sieht vier grundlegende Arten von Vorgängen (conversations) vor: Registrierung, Authentifizierung, Transaktionsbestätigung und Abmeldung (NK5c S. 9 Z. 77-93).

cc) Die einzelnen Schritte des Authentifizierungsprozesses sind in der nachfolgend wiedergegebenen Figur 3.3 (NK5c S. 32) dargestellt.

In dem dargestellten Beispiel ruft der Nutzer mit seinem Endgerät eine Internetseite auf (Schritt 1). Der User Agent übermittelt den Befehl zum Öffnen der Seite an die Web App auf dem Server der Relying Party (Schritt 1b). Diese veranlasst den FIDO Server zur Erstellung einer Authentifizierungsanfrage (Schritt 3). Der FIDO Server übermittelt diese Anfrage an die Web App (Schritt 4). Diese übermittelt sie an den User Agent (Schritt 5). Dieser reicht sie zusammen mit einer AppID und weiteren Angaben an den FIDO Client weiter (Schritt 6). Dieser veranlasst eine Authentifizierung auf dem Endgerät (Schritt 9). Nach erfolgreicher Authentifizierung werden signierte Daten über den FIDO Client (Schritte 14 und 15), den User Agent (Schritt 16) und die Web App (Schritt 17) an den FIDO Server (Schritt 18) übermittelt. Dieser verifiziert die Daten (Schritt 19) und sendet das Ergebnis an die Web App (Schritt 20). Diese sendet gegebenenfalls die geschützten Daten (Schritt 21).

dd) Der Austausch der kryptographischen Daten bei diesem Authentifizierungsvorgang ist in der nachfolgend wiedergegebenen Figur 3.4 (NK5c S. 33) dargestellt.

(1) Der FIDO Server übermittelt an den FIDO Client eine AppID, eine Authentifizierungsrichtlinie (Policy) und eine so genannte Challenge (Chl) (NK5c S. 33 Z. 732-734).

(a) Die AppID bezeichnet die Anwendung, auf die der Benutzer zugreifen möchte. Diese kann auf mehreren Plattformen verfügbar sein, etwa einer Website, einer Android-App und einer iOS-App (NK5c S. 51 Z. 1208-1221).

(b) Die Richtlinie enthält nähere Vorgaben für die Authentifizierung (NK5c S. 20 Z. 368 ff.).

In der Richtlinie können Angaben enthalten sein, die ein bestimmtes Authenticator-Modell (AAID) oder einen bestimmten Schlüssel (KeyID) kennzeichnen (NK5c S. 20 Z. 370 f.).

(aa) Die AAID besteht aus zwei vierstelligen Hexadezimalzahlen, die mit einem bestimmten Anbieter und einem bestimmten Modell verknüpft sind.

Die Codes für die Anbieter werden unter der Verantwortung der FIDO Alliance zugewiesen. Die Codes für die einzelnen Modelle werden von den Anbietern vergeben. Diese sind dafür verantwortlich, dass Modellen mit unterschiedlichen Sicherheitsmerkmalen unterschiedliche Codes zugewiesen werden (NK5c S. 15 Z. 174-194).

(bb) Die KeyID ist eine eindeutige Kennzeichnung für einen Schlüssel zur Benutzerauthentifizierung (UAuth.key) (NK5c S. 15 Z. 198-200).

Solche Schlüssel werden vom FIDO Authenticator erzeugt. Sie bestehen aus einem öffentlichen (UAuth.pub) und einem privaten (UAuth.priv) Schlüssel. Die allgemeinere Bezeichnung UAuth.key bezieht sich auf den privaten Schlüssel (NK5a S. 16 Z. 338-341).

(cc) Eine Kombination aus AAID und KeyID muss die Registrierung eines Authenticators bei einer Relying Party eindeutig kennzeichnen. Wenn ein FIDO Server spezifische Informationen an einen bestimmten Authenticator übermittelt, muss er eine solche Kombination verwenden (NK5c S. 15 Z. 201-203).

Bei einem Authentifizierungsvorgang muss der FIDO Server dem Authenticator die KeyID zur Verfügung stellen, damit dieser auf den privaten Schlüssel zugreifen und mit ihm eine Signatur erstellen kann (NK5c S. 15 Z. 208-210).

(c) Die Challenge ist ein Zufallswert mit einer Länge von mindestens acht Byte. Dies entspricht einer Dezimalzahl mit bis zu zwanzig Ziffern (NK5c S. 16 Z. 215-226).

(2) Der FIDO Client übermittelt die AppID und endgültige Challenge-Parameter (Final Challenge Params, FCH) an den Authenticator.

Die endgültigen Challenge-Parameter enthalten die AppID, die Challenge, eine faceID, die die eingesetzte Ausprägung der App (zum Beispiel Webdienst oder Android-App) angibt, und Informationen über den sicheren Übertragungsweg (TLS information) (NK5c S. 16 Z. 235-242).

ee) Damit ein solcher Authentifizierungsprozess stattfinden kann, müssen der Authenticator und die Relying Party zuvor gemeinsam registriert worden sein (NK5c S. 32 Z. 728-730).

Bei der Registrierung übermittelt der FIDO Server an den FIDO Client eine AppID, eine Richtlinie, eine Challenge und den Benutzernamen. Der FIDO Client erzeugt aus diesen Daten und einigen anderen Werten die endgültigen Challenge-Parameter und gibt diese an den Authenticator weiter. Dieser erzeugt ein als KeyRegistrationData bezeichnetes Objekt, das die endgültigen Challenge-Parameter, den neu erzeugten öffentlichen Schlüssel des Benutzers (UAuth.pub) und einige andere Werte enthält, und signiert dieses mit einem hierfür vorgesehenen Schlüssel. Der FIDO Server überprüft dieses Objekt (NK5c S. 26 Z. 526-535).

ff) Für die Erstellung einer Authentifizierungsanfrage durch den FIDO Server formuliert NK5c folgende Regeln (S. 36 Z. 841-850):

Wenn eine AAID angegeben ist, dürfen keine anderen Felder angegeben werden, mit Ausnahme der KeyID, einem Anhang und Erweiterungen.

Wenn keine AAID angegeben ist, müssen zumindest die unterstützten Authentifizierungsalgorithmen und Schemata angegeben werden.

Bei einer schrittweisen Authentifizierung (step-up authentication), das heißt wenn zu erwarten ist, dass der Benutzer aufgrund eines vorangegangenen Authentifizierungsschritts bereits bekannt ist, muss jeder Eintrag die AAID und KeyID des für dieses Konto registrierten Authenticators enthalten, um Mehrdeutigkeiten aufgrund des Vorhandenseins mehrerer Konten zu vermeiden.

b) Damit sind die Merkmale 1 und 2 offenbart.

aa) Wie das Patentgericht zutreffend angenommen hat, ist die in den Figuren 2.4 und 3.3 von NK5c dargestellte Web App eine externe Anwendung im Sinne von Merkmal 1, weil sie auf dem Server der Relying Party und damit nicht auf dem Endgerät des Benutzers ausgeführt wird.

Dass die Web App von demselben Gerät aus aufgerufen wird, auf dem im weiteren Verlauf die Authentifizierung stattfindet, ist unerheblich, weil Patentanspruch 1 diese Ausgestaltung aus den oben aufgezeigten Gründen nicht ausschließt.

bb) Ebenfalls zutreffend hat das Patentgericht den FIDO Server als Authentifizierungsdienst im Sinne von Merkmal 1 angesehen.

cc) Zu Recht ist das Patentgericht zu dem Ergebnis gelangt, dass die Web App an den FIDO Server Identifikationsdaten übermittelt und dieser auf deren Basis die Adresse eines mit einem Benutzer verknüpften mobilen Endgeräts ermittelt.

(1) Die Kombination aus einer AAID und einer KeyID ist geeignet, einen Benutzer zu identifizieren.

Dem steht nicht entgegen, dass demselben Benutzer mehrere solcher Kennungspaare zugeordnet sein können. Ausschlaggebend ist, dass jedes einzelne Kennungspaar einen eindeutigen Rückschluss auf einen bestimmten Authenticator und damit auf den Benutzer ermöglicht, dem dieser Authenticator zugeordnet ist.

(2) Wie die Berufung im Ansatz zu Recht geltend macht, ist NK5 nicht ausdrücklich zu entnehmen, dass bereits die Anfrage, die die Web App an den FIDO Server richtet, eine Kombination aus AAID und KeyID enthält.

Die diesbezüglichen Angaben in NK5c beziehen sich auf die Authentifizierungsanfrage, die der FIDO Server erstellt, nicht auf diejenige, die die Web App an ihn versendet.

(3) Aus dem Umstand, dass der FIDO Server AAID und KeyID in die von ihm erstellte Anforderung aufnehmen kann, hat das Patentgericht aber zu Recht die Schlussfolgerung gezogen, dass bereits die Anfrage der Web App Angaben enthalten muss, die es dem FIDO Server ermöglichen, eine einem bestimmten Benutzer zugeordnete Kombination aus AAID und KeyID zu ermitteln.

Für dieses Verständnis sprechen zusätzlich die oben wiedergegebenen Ausführungen in NK5c, wonach der in Figur 3.3 dargestellte Authentifizierungsvorgang voraussetzt, dass bereits eine Registrierung stattgefunden hat, und wonach der FIDO Server dem Authenticator eine KeyID zur Verfügung stellen muss, damit dieser auf den privaten Schlüssel zugreifen und mit ihm eine Signatur erstellen kann.

Ob den ebenfalls oben wiedergegebenen Regeln für die Formulierung einer Authentifizierungsabfrage zu entnehmen ist, dass eine solche Abfrage unter bestimmten Umständen weder AAID noch KeyID enthält, bedarf keiner abschließenden Entscheidung. Selbst wenn diese Frage zu bejahen wäre, reichte es für die Verwirklichung der Merkmale 1 und 2 aus, wenn die Abfrage diese Angaben zumindest in bestimmten Situationen enthält. Diese Voraussetzung ist, wie die Berufungserwiderung zu Recht geltend macht, selbst dann erfüllt, wenn die Angaben nur bei einer step-up authentication verwendet werden.

dd) Die Übermittlung der vom FIDO Server erstellten Anfrage an das Gerät ist eine Übermittlung im Sinne von Merkmal 2.

(1) Die Anfrage wird an ein Endgerät übermittelt, weil sie an den User Agent weitergereicht wird und dieser auf einem Endgerät ausgeführt wird.

Wie bereits oben dargelegt wurde, schließt Merkmal 2 weder eine Übermittlung über Zwischenstationen aus noch eine Übermittlung an dasselbe Gerät, mit dem der Benutzer auf die externe Anwendung zugreift.

(2) Dass das vom Benutzer bediente Endgerät mobil sein kann, ergibt sich schon daraus, dass der darauf ausgeführte User Agent eine mobile Anwendung sein kann.

ee) Vor diesem Hintergrund offenbart NK5c auch, dass der FIDO Server aufgrund der von der Web App übermittelten Anfrage eine Adresse des mit dem Benutzer verknüpften mobilen Endgeräts ermittelt.

Dies ergibt sich daraus, dass bei der in NK5c vorgeschlagenen Vorgehensweise die Kombination aus AAID und KeyID zugleich eine Adresse im Sinne von Merkmal 2 enthält.

Wie die Berufung im Ansatz zu Recht geltend macht, ist NK5c allerdings nicht zu entnehmen, dass der FIDO Server eine IP-Adresse oder sonstige Daten ermittelt, mit der er in direkten Kontakt mit dem Endgerät treten kann. Diesbezügliche Ermittlungen sind nicht erforderlich, weil der FIDO Server die von ihm erstellte Abfrage nicht unmittelbar an das Endgerät übermittelt, sondern an die Web App, die ohnehin in Verbindung mit dem Endgerät steht.

Wie oben dargelegt wurde, reicht es bei einer indirekten Übermittlung zur Ermittlung einer Adresse jedoch aus, wenn der Authentifizierungsdienst eine andere Anwendung aufgrund der übermittelten Identifikationsdaten dazu veranlassen kann, die Anfrage an ein bestimmtes Gerät weiterzuleiten. Wie das Patentgericht zu Recht angenommen hat, ist diese Voraussetzung in NK5c erfüllt, weil der FIDO Server anhand der von der Web App übermittelten Anfragen eine Kombination aus AAID und KeyID ermitteln kann und diese ein mit einem Benutzerkonto verknüpftes Gerät eindeutig kennzeichnen.

c) NK5c offenbart auch die Merkmale 3 bis 3.2.

Wie oben aufgezeigt wurde, veranlasst der User Agent - und damit das Endgerät - nach Empfang einer Authentifizierungsanfrage eine Überprüfung, die zum Beispiel anhand eines Fingerabdrucks und damit eines biometrischen Sicherheitsmerkmals erfolgen kann.

d) Entgegen der Auffassung der Berufung sind auch die Merkmale 4.1 und 4.2 offenbart.

aa) Wie oben dargelegt wurde, signiert der Authenticator nach erfolgreicher Verifikation unter anderem die vom FIDO Server übermittelte Zufallszahl (Challenge) und damit einen Wert, mit dem die betreffende Transaktion identifiziert werden kann.

Die Wahrscheinlichkeit, dass bei einer Zufallszahl mit bis zu 20 Dezimalstellen kurz hintereinander zweimal derselbe Wert auftritt, ist hinreichend gering, um die Gefahr von Verwechslungen auszuschließen.

bb) Merkmal 4.2 ist verwirklicht, weil die Signatur mit einem privaten Schlüssel erfolgt und die signierten Daten vom User Agent über die Web App an den FIDO Server übertragen werden.

Dass die Übertragung nicht unmittelbar vom Endgerät zum FIDO Server erfolgt, steht der Verwirklichung von Merkmal 4.2 aus den oben dargelegten Gründen nicht entgegen.

e) Merkmal 5 ist in NK5c ebenfalls offenbart.

Aus Figur 3.3 ergibt sich, dass der FIDO Server die vom Authenticator signierten Daten überprüft und das Ergebnis an die Web App weiterleitet, die die angeforderten Daten im Erfolgsfall freigibt.

Auch in diesem Zusammenhang ist unerheblich, dass die überprüften Daten nicht unmittelbar vom User Agent an den FIDO Server übertragen werden.

2. Zu Recht hat das Patentgericht die mit den Hilfsanträgen verteidigten Gegenstände ebenfalls als nicht patentfähig angesehen.

a) Der mit Hilfsantrag 1 verteidigte Gegenstand ist durch den Stand der Technik nahegelegt.

aa) Nach Hilfsantrag 1 soll Patentanspruch 1 wie folgt ergänzt werden:

Aus diesem Merkmal ergibt sich, dass die externe Anwendung (3) an der Übermittlung der genannten Daten nicht beteiligt sein und die übermittelten Daten nicht sehen darf.

Ob die Anfrage hierzu unmittelbar an das mobile Endgerät übermittelt werden muss, bedarf keiner abschließenden Entscheidung. Diese Frage ist für die Beurteilung des Rechtsbestands nicht erheblich.

bb) Zu Recht hat das Patentgericht entschieden, dass diese Ausgestaltung ausgehend von NK5 durch NK6 auch dann nahegelegt war, wenn Merkmal 6 eine unmittelbare Übersendung der Anfrage an das mobile Endgerät erfordert.

(1) NK6 befasst sich mit der sicheren Authentifizierung in Systemen mit mehreren Beteiligten.

NK6 führt aus, die Authentifizierung im Internet erfolge üblicherweise mit Benutzername und Passwort, obwohl dies unsicher sei.

Zur Verbesserung schlägt NK6 vor, einen Authentifizierungsserver einzusetzen, der im Falle einer Login-Anforderung eine Zufallszahl erstellt, die die Grundlage für die weitere Überprüfung bildet (Abs. 6).

Die eingesetzten Geräte und Kommunikationsverbindungen sowie die einzelnen Authentifizierungsschritte sind in den nachfolgend wiedergegebenen Figuren 1 und 3 schematisch dargestellt.

Der Benutzer setzt ein mobiles Gerät mit Netzwerkverbindung ein, zum Beispiel ein Smartphone oder Tablet. Darauf ist eine Software (101) installiert, die Verschlüsselungs- und Authentifizierungsfunktionen zur Verfügung stellt. Ferner kommt eine Zugangssoftware zum Einsatz, zum Beispiel ein Webbrowser (102). Dieser kann auf dem mobilen Gerät installiert sein oder auf einem zweiten Gerät wie zum Beispiel einem Desktop-Computer oder einem Laptop (Abs. 54).

Wenn der Benutzer mit einem Desktop- oder Mobilbrowser eine Website (103) aufruft (Schritt 301), erhält deren Betreiber vom Authentifizierungsserver (100) eine Sitzungskennung (Qsid) (Schritt 300). Zusätzlich erzeugt er lokal eine für die Sitzung spezifische Zufallszahl (Qliveness) (Abs. 123 f.).

Die Sitzungskennung (Qsid) wird über einen verschlüsselten Kanal (150) an den Browser übermittelt und von diesem in Form einer Grafik, zum Beispiel eines QR-Codes (Abs. 55) angezeigt. Zumindest bei einigen Ausgestaltungen übermittelt der Benutzer über den Browser eine eindeutige Nutzerkennung an den Provider. Dieser reicht die Nutzerkennung und die beiden Sitzungskennungen (Qsid, Qliveness) an den Authentifizierungsserver weiter (Abs. 125 f.).

Der Benutzer scannt den grafischen Code mit einer Authentifizierungsapp ein (Schritt 302). Diese decodiert den Code, prüft ihn auf Gültigkeit und extrahiert die Sitzungskennung (Qsid). Danach verbindet sie sich mittels Client-Authentifizierung mit dem Authentifizierungsserver, überprüft dessen Zertifikat und übermittelt die Sitzungskennung (Qsid) (Schritt 303) (Abs. 127 f.).

Der Authentifizierungsserver übermittelt die Sitzungsdaten. Wenn die beiden zuletzt genannten Schritte nicht absolviert wurden, nimmt er stattdessen auf der Grundlage der eindeutigen Benutzerkennung Kontakt unmittelbar mit dem Mobilgerät des Benutzers und der darauf installierten Sicherheitssoftware (Qapp) auf und übermittelt eine Login-Aufforderung, aus der die von der Website erzeugte Zufallszahl (Qliveness), die Art der Sitzung (Login oder Registrierung), der Name des Providers und dessen Authentifizierungsrichtlinien (zum Beispiel "keine", "Passwort" oder "biometrisch") hervorgehen (Schritt 304) (Abs. 129-132).

Die Sicherheitssoftware (Qapp) fordert beim Nutzer die erforderlichen Informationen an, also zum Beispiel ein Passwort oder biometrische Daten (Schritt 305), und übermittelt die Netzwerkkomponente dieser Daten an den Authentifizierungsserver (Abs. 133-135).

Der Authentifizierungsserver überprüft diese Daten und übermittelt der Sicherheitssoftware (Qapp) die zweite Hälfte eines geteilten Schlüssels, dessen erste Hälfte auf dem mobilen Gerät gespeichert ist. Mit Hilfe des zusammengesetzten Schlüssels wird der sichere Schlüsselspeicher in der Anwendung entsperrt. Dieser enthält für jeden Provider einen privaten Schlüssel. Mit dessen Hilfe erstellt die Sicherheitssoftware (Qapp) ein vollständiges Authentifizierungspaket, das sie an den Authentifizierungsserver übersendet (Schritt 306). Dieses Paket enthält gegebenenfalls auch biometrische Rohdaten, zum Beispiel ein Abbild des Gesichts oder der Hand (Abs. 136-143).

Der Authentifizierungsserver verifiziert die übermittelten Daten. Biometrische Daten vergleicht er mit Daten, die der Benutzer zuvor hinterlegt hat. Im Erfolgsfall übermittelt er dem Browser eine entsprechende Nachricht. Der Browser nimmt Kontakt zum Provider auf. Dieser bittet den Authentifizierungsserver um Bestätigung. Wenn diese Bestätigung erteilt wird (Schritt 307), gewährt er dem Benutzer Zugang (Abs. 144-153).

(2) Bei der zuletzt geschilderten Variante sind jedenfalls die Merkmale 1, 2, 5 und 6 verwirklicht.

Bei dieser Ausgestaltung ist die Website des Providers eine externe Anwendung im Sinne von Merkmal 1, weil sie nicht auf dem für die Authentifizierung eingesetzten Mobilgerät läuft. Sie übermittelt eine Benutzerkennung, anhand derer der Authentifizierungsserver Kontakt zum Mobilgerät aufnimmt, wie dies Merkmal 2 vorsieht. Der Authentifizierungsserver übermittelt das Ergebnis seiner Überprüfung in Einklang mit den Vorgaben aus Merkmal 5 an die Website. Die Authentifizierungsanforderung an das Mobilgerät, die eine Transaktionskennung (Qliveness) umfasst, und die vom Mobilgerät signierte Kennung werden ohne Einsatz der Website, also unmittelbar, übermittelt und sind für diese nicht sichtbar, wie dies Merkmal 6 vorgibt.

(3) Ob eine Kombination von NK5 mit NK6, wie das Patentgericht ausgeführt hat, schon deshalb nahelag, weil das in NK5 spezifizierte Verfahren erkennbare Nachteile aufweist, bedarf keiner abschließenden Entscheidung.

Anlass zu Überlegungen, wie das in NK5 vorgeschlagene Verfahren verbessert werden kann, ergaben sich jedenfalls aus dem dort formulierten Ziel, eine möglichst große Anzahl von Endgeräten einsetzen zu können (NK5b S. 6 Z. 137-139), und aus dem Hinweis, dass unter anderem auch Mobiltelefone als Authenticator für ein anderes Gerät eingesetzt werden können (NK5d S. 9 Z. 83). Daraus ergab sich zugleich die Anregung, in ähnlichen Systemen nach zusätzlichen Szenarien für die Authentifizierung zu suchen.

Dem steht nicht entgegen, dass dem vorgenannten Hinweis in NK5d nicht eindeutig zu entnehmen ist, ob das weitere Gerät an das erste Gerät des Benutzers angebunden werden oder in direkten Kontakt mit der Web App treten soll. Gerade diese Unklarheit gab Anlass, auf der Suche nach möglichen Ausgestaltungen andere im Stand der Technik bekannte Systeme ergänzend in Betracht zu ziehen.

NK6 bot sich vor diesem Hintergrund als Erkenntnisquelle an, weil es sich ebenfalls mit der sicheren Authentifizierung unter Einsatz eines dafür vorgesehenen Servers befasst und im Detail schildert, wie ein Mobiltelefon zur Authentifizierung eingesetzt werden kann.

(4) Ausgehend von NK5 ergab sich aus NK6 die Erkenntnis, dass die Authentifizierung wahlweise auf demselben Gerät durchgeführt werden kann, welches der Benutzer für den Zugriff auf die externe Anwendung nutzt, oder durch ein separates Mobilgerät. NK6 zeigt auch auf, wie der damit verbundenen Konsequenz Rechnung getragen werden kann, dass der Authentifizierungsserver in direkten Kontakt mit dem Mobilgerät treten muss, nämlich durch Ermittlung einer dafür geeigneten Adresse anhand der übermittelten Benutzerkennung.

Vor diesem Hintergrund ist die Kombination dieser Merkmale entgegen der Auffassung der Berufung keine willkürliche Vermengung von miteinander nicht kompatiblen Architekturen. Der Einsatz eines separaten Endgeräts für den in NK5 spezifizierten Authentifizierungsvorgang und die damit verbundene Konsequenz, dass der FIDO Server mit diesem Gerät unmittelbar Kontakt aufnehmen und zu diesem Zweck dessen Adresse ermitteln muss, ist vielmehr die Umsetzung eines Teilkonzepts, das nicht in zwingendem Zusammenhang mit den übrigen Teilen der in NK6 vorgeschlagenen Architektur steht. Dies zeigt sich insbesondere daran, dass NK6 alternativ auch den Einsatz eines einzigen Endgeräts vorsieht, wie dies in NK5 beschrieben ist.

b) Für Hilfsantrag 2 gilt Entsprechendes.

aa) Nach Hilfsantrag 2 soll die erteilte Fassung von Patentanspruch 1 wie folgt ergänzt werden:

bb) Diese Ausgestaltung ist ausgehend von NK5 aus den bereits zu Hilfsantrag 1 dargelegten Gründen ebenfalls durch NK6 nahegelegt.

Wie bereits oben aufgezeigt wurde, ist der Browser, mit dem der Benutzer auf die Website - die externe Anwendung im Sinne von Merkmal 1' - zugreift, bei der zweiten Variante aus NK6 auf einem Endgerät installiert, das nicht mit dem für die Authentifizierung eingesetzten Mobilgerät identisch ist.

c) Der mit Hilfsantrag 3a verteidigte Gegenstand ist ebenfalls nicht patentfähig.

aa) Nach Hilfsantrag 3a soll die erteilte Fassung von Patentanspruch 1 wie folgt ergänzt werden:

bb) Zu Recht ist das Patentgericht zu dem Ergebnis gelangt, dass diese Ausgestaltung ausgehend von NK5 nahelag.

Nach den Feststellungen des Patentgerichts war der Einsatz einer Signatur auf der Grundlage eines privaten Schlüssels im Stand der Technik ein hinlänglich bekanntes Verfahren, um die Echtheit einer erteilten Bestätigung zu dokumentieren und die Datensicherheit zu erhöhen. Die Berufung zeigt keine konkreten Anhaltspunkte auf, die Zweifel an der Richtigkeit oder Vollständigkeit dieser Feststellung begründen (§ 117 Abs. 1 PatG, § 529 Abs. 1 Nr. 1 ZPO).

Vor diesem Hintergrund ist die vom Patentgericht gezogene Schlussfolgerung, dass der Einsatz dieses Mittels zur zusätzlichen Absicherung der vom Authentifizierungsdienst (8) erteilten Bestätigung (26) keines erfinderischen Zutuns bedurfte, nicht zu beanstanden.

d) Für Hilfsantrag 4a gilt Entsprechendes.

aa) Nach Hilfsantrag 4a soll Patentanspruch 1 in der Fassung des Hilfsantrags 3a wie folgt ergänzt werden:

bb) Dieser Gegenstand unterliegt derselben Beurteilung wie der mit Hilfsantrag 3a verteidigte Gegenstand.

Nach den Feststellungen des Patentgerichts kann eine Signatur mit einem benutzerunabhängigen privaten Schlüssel, wie sie in Merkmal 7 vorgesehen ist und ausgehend von NK5 nahelag, weder einem Benutzer noch einem mobilen Endgerät zugeordnet werden.

Die Berufung zeigt keine konkreten Anhaltspunkte auf, die Zweifel an der Richtigkeit oder Vollständigkeit dieser Feststellung begründen (§ 117 Abs. 1 PatG, § 529 Abs. 1 Nr. 1 ZPO).

V. Die Kostenentscheidung beruht auf § 121 Abs 2 PatG.

1. Auch wenn beide Klägerinnen in vollem Umfang obsiegt haben, entspricht es der Billigkeit, der Klägerin zu 2 abweichend von § 91 Abs. 1 ZPO die Mehrkosten aufzuerlegen, die entstanden sind, weil sie das Streitpatent mit einer zweiten Klage angegriffen hat, statt dem von der Klägerin zu 1 eingeleiteten Verfahren als weitere Klägerin beizutreten.

a) Dabei kann dahingestellt bleiben, ob ein Nichtigkeitskläger unter dem Aspekt der Billigkeit im Sinne von § 84 Abs. 2 Satz 2 und § 121 Abs. 2 Satz 2 PatG grundsätzlich gehalten ist, einer bereits erhobenen Klage beizutreten, statt eine zweite, separate Klage zu erheben.

Wenn ein Kläger die Möglichkeit eines solchen Beitritts nicht nutzt, ist es jedenfalls dann grundsätzlich unbillig, dadurch entstandene Mehrkosten dem Beklagten aufzuerlegen, wenn die beiden Kläger unternehmensrechtlich verbunden sind und keine anderen Verletzungshandlungen ersichtlich sind, wegen derer nur der zweite Kläger in Anspruch genommen werden könnte.

Diese Voraussetzungen sind im Streitfall erfüllt.

b) Ebenfalls keiner abschließenden Entscheidung bedarf die Frage, ob etwas anderes gilt, wenn das bereits anhängige Verfahren einen Stand erreicht hat, der den zweiten Kläger daran hindert, neue Angriffsmittel geltend zu machen.

Im Streitfall hat sich die Klägerin zu 2 im Wesentlichen auf dieselben Angriffsmittel gestützt wie die Klägerin zu 1. Das Patentgericht hatte im Zeitpunkt der zweiten Klage auch noch nicht den in § 83 Abs. 1 PatG vorgeschriebenen Hinweis erteilt.

Der Umstand, dass das Patentgericht im zweiten Verfahren aufgrund der am 1. Mai 2022 in Kraft getretenen Fassung von § 83 Abs. 1 ZPO gehalten war, den dort vorgeschriebenen Hinweis innerhalb von sechs Monaten nach Zustellung der Klage zu erteilen, rechtfertigt keine abweichende Beurteilung. Wenn die Klägerin zu 2 ein besonderes Interesse an einem möglichst frühzeitigen Hinweis gehabt hätte, wäre es ihr möglich und zumutbar gewesen, dieses Interesse nach einem Beitritt zum ersten Verfahren geltend zu machen. Wie der weitere Verlauf des Verfahrens zeigt, bot auch eine separate neue Klage keine Gewähr dafür, dass der Hinweis früher ergeht.

2. Die Kosten des Berufungsverfahrens hat gemäß § 97 Abs. 1 ZPO die Beklagte zu tragen.