BPatG, 4. Senat — 4 Ni 61/22 (EP)# 4 Ni 41/23 (EP)

Beide Klägerinnen streben die Nichtigerklärung des Streitpatents in vollem Umfang an.

Die Beklagte ist Inhaberin des auch mit Wirkung für das Hoheitsgebiet der Bundesrepublik Deutschland erteilten europäischen Patents 2 926 290 (Streitpatent), das am 27. November 2013 unter Inanspruchnahme der Priorität der britischen Patentanmeldung GB 201221433 vom 28. November 2012, der US-PatentanmeldungUS 201213706307 vom 5. Dezember 2012 und der britischen Patentanmeldung GB 201303677 vom 1. März 2013 angemeldet worden ist. Die Erteilung des Patents istam 17. Juni 2020 veröffentlicht; das Patent ist in Kraft.

Das Streitpatent betrifft ein Verfahren und ein System zur Authentifizierung eines Nutzers an einer Computerressource über eine Mobilvorrichtung.

Das in der Verfahrenssprache Englisch veröffentlichte und beim Deutschen Patent- und Markenamt unter dem Aktenzeichen DE 60 2013 069 972.0 geführte Streitpatent trägt die Bezeichnung

„A METHOD AND SYSTEM OF PROVIDING AUTHENTICATION OF USER ACCESS TO A COMPUTER RESOURCE VIA A MOBILE DEVICE USING MULTIPLE SEPARATE SECURITY FACTORS“

in deutscher Sprache laut Streitpatentschrift:

„Verfahren und System zur Bereitstellung der Authentifizierung des Benutzerzugangs zu einer Computerressource über eine mobile Vorrichtung mit mehreren separaten Sicherheitsfaktoren“

Es umfasst in der erteilten Fassung 15 Patentansprüche mit den nebengeordneten Patentansprüchen 1 und 9. Die Patentsprüche 2 bis 8 sind mittelbar oder unmittelbar auf den Patentanspruch 1 und die Patentansprüche 10 bis 15 mittelbaroder unmittelbar auf Patentanspruch 9 zurückbezogen.

Dienebengeordneten Patentansprüche 1 und 9 haben in der Verfahrenssprache laut Streitpatentschrift den folgenden Wortlaut:

1. A method of authenticating a user to access a computer resource via a mobile device comprising:

storing an encrypted resource authorization;

transmitting the encrypted resource authorization to at least one separate portable security token device;

on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response;

securely transmitting the generated unlock response to the mobile device; and

providing access via the mobile device to the computer resource if the required unlock response is valid;

wherein a user is required to authenticate on the mobile device or on the at least one separate portable security token device, and the user authentication is validated on the at least one separate portable security token device before the unlock response is sent.

9. A system for authenticating a user to access a computer resource via a mobile device, the system comprising a mobile device and at least one separate portable security token device, which comprise means for carrying out the method of claim 1.

In deutscher Übersetzung lauten die Patentansprüche 1 und 9 nach der Streitpatentschrift wie folgt:

1. Verfahren zum Authentifizieren eines Benutzers für den Zugriff auf eine Computerressource über eine Mobilvorrichtung, umfassend:

Speichern einer verschlüsselten Ressourcenautorisierung; Übertragen der verschlüsselten Ressourcenautorisierung an wenigstens eine getrennte tragbare Sicherheitstoken-Vorrichtung;

auf der wenigstens einen getrennten tragbaren Sicherheitstoken-Vorrichtung, Entschlüsseln der verschlüsselten Ressourcenautorisierung und Generieren, wenigstens teilweise daraus, einer Entsperrantwort;

sicheres Übertragen der generierten Entsperrantwort an die Mobilvorrichtung; und

Gewähren des Zugriffs, über die Mobilvorrichtung, auf die Computerressource, falls die erforderliche Entsperrantwort gültig ist;

wobei sich ein Benutzer auf der Mobilvorrichtung oder auf der wenigstens einen getrennten tragbaren Sicherheitstoken-Vorrichtung authentifizieren muss und die Benutzerauthentifizierung auf der wenigstens einen getrennten tragbaren Sicherheitstoken-Vorrichtung validiert wird, bevor die Entsperrantwort gesendet wird.

9. System zum Authentifizieren eines Benutzers für den Zugriff auf eine Computerressource über eine Mobilvorrichtung, wobei das System eine Mobilvorrichtung und wenigstens eine getrennte tragbare Sicherheitstoken-Vorrichtung umfasst, die Mittel zum Ausführen des Verfahrens nach Anspruch 1 umfassen.

Die Klägerinnen greifen mit ihren Nichtigkeitsklagen vom 22. Juni 2022 und 13. Oktober 2023 das Streitpatent insgesamt an. Die Klägerinnen sind der Ansicht, der Gegenstand des Streitpatents gehe über den Inhalt der Anmeldung in der ursprünglich eingereichten Fassung hinaus, sei nicht so deutlich und vollständig offenbart, dass die Fachperson ihn ausführen könne und sei nicht patentfähig.Sie machen daher übereinstimmend die Nichtigkeitsgründe der unzulässigen Erweiterung, der für die Ausführbarkeit nicht hinreichenden Offenbarung und der fehlenden Patentfähigkeit geltend.Die Beklagte verteidigt ihr Patent in erteilter Fassungen und mit letztlich 36 Hilfsanträgen.

Die Klägerinnen stützen ihr Vorbringen auf folgende Dokumente (Nummerierung und Kurzzeichen nach den Schriftsätzen der Klägerinnen):

Klägerin zu 1 Klägerin zu 2 Im Weiteren Dokument Veröffentlicht D1 D1 US 2010/0228991 A1 09.09.2010 D2 D2 WO 2013/167 043 A2 14.11.2013 D2a EP 2 919 413 A2 16.09.2015 D3 D3 Anlagenkonvolut hoverkey.com, archiviert Mai 2013 D3a How Hoverkey works 14.05.2013 D3b Logging in with Hoverkey 14.05.2013 D3c Hoverkey SDK Developer Overview 06.12.2012 D3d SDK Tutorial 12.12.2012 D3e Hoverkey loves developers 14.05.2013 D4 D4 Hallsteinsen et al: Using the mobile phone as a security token for unified authentication. In: 2007 2 nd Int. Conf. on Systems and Networks Communications (ICSNC 2007) 09.2007 D4a IEEE Xplore: Bibliograph. Daten / Abstract D5 D5 Clark: Hoverkey adds NFC security to Android apps. 13.02.2013 D6 D6 US 8,302,167 B2 30.10.2012 D7 D7 WO 2008/147457 A1 04.12.2008 D8 D8 DE 10 2009 040 009 A1 14.04.2011 D9 D1 D9 Du Sun et al: A New Design of Wearable Token System for Mobile Device Security. IEEE Transactions on Consumer Electronics, Vol. 54, No. 4, November 2008 11.2008 D10 D2 D10 Corner et al: Protecting File Systems with Transient Authentication. Wireless Networks 7. – 19.11.2005 11.2005 D11 D4 D11 Nicholson et al: Mobile Device Security Using Transient Authentication. IEEE Transactions on Mobile Computing, Vol. 5, No. 11, November 2006 11.2008 D12 D12 D12 Stanoevska-Slabeva et al: Grid and Cloud Computing, A Business Perspective on Technology and Applications. November 2009, Seiten 47 bis 61 11.2009 D13 D13 Grandison et al: Towards a Formal Definition of a Computing Cloud. IEEE Computer Society, 2010 IEEE 6 th World Congress on Services 2010 D14 D14 Grossman: The Case for Cloud Computing. IT Professional. IEEE Computer Society, Mai 2009 05.2009 D15 D15 Lu: Accessing Cloud through API in a more Secure and Usable Way. In: Proceedings of the 8 th International Workshop on Security in Information Systems (WOSIS-2011), S. 25-38, ISBN: 978-989-8425-61-4 2011 D16 D16 US 2012/0297190 A1 22.11.2012 D17 D17 Sosinsky: Cloud Computing Bible. Wiley, 2011 (Auszug) 2011 D18 D18 US 2010/0266132 A1 21.10.2010 D19 D19 WO 2012/027708 A2 01.03.2012 D20 D20 Ma et al: IRRES: Intrusion-Resilient Remote Email Storage. 2010 IEEE 30 th Int. Conf. on Distributed Computing Systems Workshops ICDCSW 2010, S. 72-76 2010 D3 D21 EP 1 881 664 B1 15.10.2008 D22 D22 Hiltgen et al: Secure Internet banking authentication. IEEE Security & Privacy, Vol. 4, Issue 2, März/April 2006 04.2006 D23 D23 US 2008/0065892 A1 13.03.2008 D24 D24 EP 1 552 661 B1 13.07.2005 D25 D25 US 8 065 718 B2 22.11.2011 D26 D26 Hunter: An Analysis of the Alternatives to Traditional Static Alphanumeric Passwords. Athabasca University, Athabasca, Kanada, Mai 2012 05.2012 D27 D27 EP 1 739 913 A1 27.10.2005

Die Klägerin zu 1 beantragt,

das europäische Patent 2 926 290 für das Gebiet der Bundesrepublik Deutschland in vollem Umfang für nichtig zu erklären.

Die Klägerin zu 2 beantragt,

das europäische Patent 2 926 290 für das Gebiet der Bundesrepublik Deutschland in vollem Umfang für nichtig zu erklären.

Die Beklagte beantragt,

die Klage abzuweisen,

hilfsweise, die Klage abzuweisen,

soweit sie sich auch gegen eine der Fassungen des Streitpatents nach dem in der mündlichen Verhandlung vom 27. Oktober 2023 (im Verfahren zum Az.: 4 Ni 61/22 (EP)) eingereichten Hilfsantrag 1 und den mit Schriftsätzen vom 18. September 2024 sowie 31. Januar 2025 eingereichten bzw. modifizierten Hilfsanträgen 1 bzw. 2A bis 11 und den in der mündlichen Verhandlung vom 9. April 2025 eingereichten Hilfsanträgen 3Ea, 3Eb und 12 richten,

mit der Maßgabe, dass die Hilfsanträge 1 bzw. 2A bis 11 in der numerischen und darunter in der alphabetischen Reihenfolge geprüft werden sollen und diese Anträge, wie auch die erteilte Fassung des Streitpatents jeweils als geschlossener Anspruchssatz gestellt werden.

Die einzeln verteidigten Patentansprüche nach Hilfsantrag 12 sollen nach der neuen Nummerierung in der Reihenfolge

Patentanspruch 1, Patentanspruch 2, Patentanspruch 3, Patentanspruch 4,

Patentanspruch 5 bezogen auf Patentanspruch 1 und dann auf Patentanspruch 2 (auf die weiteren rückbezogenen Anspruchsfassungen wird verzichtet),

Patentanspruch 6 bezogen auf Patentanspruch 1 und dann auf Patentanspruch 2 (auf die weiteren rückbezogenen Anspruchsfassungen wird verzichtet),

Patentanspruch 7,

Patentanspruch 8 bezogen auf Patentanspruch 1 (auf die weiteren rückbezogenen Anspruchsfassungen wird verzichtet),

Patentanspruch 9 bezogen auf Patentanspruch 1 (auf die weiteren rückbezogenen Anspruchsfassungen wird verzichtet), Patentan-spruch 10 bezogen auf Patentanspruch 1 und dann auf Patentanspruch 2,

Patentanspruch 11,

Patentanspruch 12 bezogen auf Patentanspruch 10 dann auf Patentanspruch 11,

Patentanspruch 13 bezogen auf Patentanspruch 10, dann auf Patentanspruch 11 und dann auf Patentanspruch 12,

Patentanspruch 14 bezogen auf Patentanspruch 10, dann auf Patentanspruch 11, dann auf Patentanspruch 12 und dann auf Patentanspruch 13,

Patentanspruch 15 bezogen auf Patentanspruch 10, dann auch Patentanspruch 11, dann auf Patentanspruch 12, dann auf Patentanspruch 13 und dann auf Patentanspruch 14,

geprüft werden und Patentanspruch 16 wird nicht gestellt.

Die Beklagte tritt der Argumentation der Klägerinnen entgegen und hält den Gegenstand des Streitpatents für bestandskräftig. Insbesondere die Patentansprüche 1 und 9 seien ursprungsoffenbart, ausführbar offenbart, gegenüber dem vorgelegten Stand der Technik neu und beruhten auch auf einer erfinderischen Tätigkeit. Darüber hinaus sei der Gegenstand des Patentanspruchs 1 wenigstens in einer der verteidigten Fassungen nach den eingereichten Hilfsanträgen 1 bis 11 bzw. den Patentansprüchen nach Hilfsantrag 12 schutzfähig.

Patentanspruch 1 in den Fassungen nach den Hilfsanträgen hat die Beklagte gegenüber der erteilten Fassung wie folgt geändert (Änderungen sind durch Unterstreichen bzw. Durchstreichen kenntlich gemacht):

Patentanspruch 1 des Hilfsantrags 1 unterscheidet sich von der erteilten Fassung dadurch, dass nach „... storing an encrypted resource authorization ...“ Folgendes aufgenommen ist:

“, wherein the encrypted resource authorization is stored in the cloud and is retrieved from the cloud to the mobile device.”

Patentanspruch 1 des Hilfsantrags 2A hat die Beklagte wie folgt geändert (Änderungen sind durch Unterstreichen bzw. Durchstreichen kenntlich gemacht):

1. A method of authenticating a user to access a computer resource on a remote server via a mobile device comprising:

storing an encrypted resource authorization, wherein the encrypted resource authorization is stored in the cloud and is retrieved from the cloud to the mobile device;

transmitting the encrypted resource authorization to at least one separate portable security token device;

on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response;

securely transmitting the generated unlock response to the mobile device;

providing access via the mobile device to the computer resource on the remote server if the required unlock response is valid;

wherein a user is required to authenticate on the mobile device or on the at least one separate portable security token device, and the user authentication is validated on the at least one separate portable security token device before the unlock response is sent.

Patentanspruch 1 des Hilfsantrags 2B hat die Beklagte wie folgt geändert (Änderungen sind durch Unterstreichen bzw. Durchstreichen kenntlich gemacht):

1. A method of authenticating a user to access an application computer resource on a remote server via a mobile device comprising:

storing an encrypted resource authorization, wherein the encrypted resource authorization is stored in the cloud and is retrieved from the cloud to the mobile device;

transmitting the encrypted resource authorization to at least one separate portable security token device;

on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response;

securely transmitting the generated unlock response to the mobile device;

providing access via the mobile device to the application computer resource on the remote server if the required unlock response is valid;

wherein a user is required to authenticate on the mobile device or on the at least one separate portable security token device, and the user authentication is validated on the at least one separate portable security token device before the unlock response is sent.

Patentanspruch 1 des Hilfsantrags 3A hat die Beklagte wie folgt geändert (Änderungen sind durch Unterstreichen bzw. Durchstreichen kenntlich gemacht):

1. A method of authenticating a user to access a computer resource on a remote server via a mobile device comprising:

storing an encrypted resource authorization, wherein the encrypted resource authorization is stored in the cloud and is retrieved from the cloud to the mobile device;

transmitting the encrypted resource authorization to at least one separate portable security token device;

on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response, wherein generating the unlock response comprises performing a computation on a plain authorization, obtained by decrypting the encrypted resource authorization, and additional information, wherein the computation is a digital signature function;

securely transmitting the generated unlock response to the mobile device;

providing access via the mobile device to the computer resource on the remote server if the required unlock response is valid;

wherein a user is required to authenticate on the mobile device or on the at least one separate portable security token device, and the user authentication is validated on the at least one separate portable security token device before the unlock response is sent.

Patentanspruch 1 des Hilfsantrags 3B hat die Beklagte wie folgt geändert (Änderungen sind durch Unterstreichen bzw. Durchstreichen kenntlich gemacht):

1. A method of authenticating a user to access a computer resource via a mobile device comprising:

storing an encrypted resource authorization, wherein the encrypted resource authorization is stored in the cloud and is retrieved from the cloud to the mobile device;

transmitting the encrypted resource authorization to at least one separate portable security token device;

on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response, wherein generating the unlock response comprises performing a computation on a plain authorization, obtained by decrypting the encrypted resource authorization, and additional information, wherein the computation is a digital signature function;

securely transmitting the generated unlock response to the mobile device;

providing access via the mobile device to the computer resource if the required unlock response is valid;

wherein a user is required to authenticate on the mobile device or on the at least one separate portable security token device, and the user authentication is validated on the at least one separate portable security token device before the unlock response is sent.

Patentanspruch 1 des Hilfsantrags 3C hat die Beklagte wie folgt geändert (Änderungen sind durch Unterstreichen bzw. Durchstreichen kenntlich gemacht):

1. A method of authenticating a user to access a computer resource via a mobile device comprising:

storing an encrypted resource authorization;

transmitting the encrypted resource authorization to at least one separate portable security token device;

on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response, wherein generating the unlock response comprises performing a computation on a plain authorization, obtained by decrypting the encrypted resource authorization, and additional information, wherein the computation is a digital signature function;

securely transmitting the generated unlock response to the mobile device;

providing access via the mobile device to the computer resource if the required unlock response is valid;

wherein a user is required to authenticate on the mobile device or on the at least one separate portable security token device, and the user authentication is validated on the at least one separate portable security token device before the unlock response is sent.

Patentanspruch 1 des Hilfsantrags 3D hat die Beklagte wie folgt geändert (Änderungen sind durch Unterstreichen bzw. Durchstreichen kenntlich gemacht):

1. A method of authenticating a user to access a computer resource on a remote server via a mobile device comprising:

storing an encrypted resource authorization;

transmitting the encrypted resource authorization to at least one separate portable security token device;

on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response, wherein generating the unlock response comprises performing a computation on a plain authorization, obtained by decrypting the encrypted resource authorization, and additional information, wherein the computation is a digital signature function;

securely transmitting the generated unlock response to the mobile device;

providing access via the mobile device to the computer resource on the remote server if the required unlock response is valid;

wherein a user is required to authenticate on the mobile device or on the at least one separate portable security token device, and the user authentication is validated on the at least one separate portable security token device before the unlock response is sent.

Patentanspruch 1 des Hilfsantrags 3E hat die Beklagte wie folgt geändert (Änderungen sind durch Unterstreichen bzw. Durchstreichen kenntlich gemacht):

1. A method of authenticating a user to access a computer resource on a remote server via a mobile device comprising:

storing an encrypted resource authorization;

transmitting the encrypted resource authorization to at least one separate portable security token device;

on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response, wherein generating the unlock response comprises performing a computation on a plain authorization, wherein the plain authorization is a private signing key obtained by decrypting the encrypted resource authorization, and additional information, wherein the computation is a digital signature function;

securely transmitting the generated unlock response to the mobile device;

providing access via the mobile device to the computer resource on the remote server if the required unlock response is valid;

wherein a user is required to authenticate on the mobile device or on the at least one separate portable security token device, and the user authentication is validated on the at least one separate portable security token device before the unlock response is sent.

Patentanspruch 1 des Hilfsantrags 3Ea unterscheidet sich von Hilfsantrag 3E dadurch, dass nach „... wherein the computation is a digital signature function ...“ Folgendes aufgenommen ist:

“, and wherein the plain authorization is not included in the unlock response”.

Patentanspruch 1 des Hilfsantrags 3Eb unterscheidet sich von Hilfsantrag 3E dadurch, dass Folgendes geändert ist:

In dem Teilsatz “on the at least one separate portable security token device, decrypting the encrypted resource authorization” ist nach “decrypting” eingefügt “and verifying” und

in dem Teilsatz “wherein the plain authorization is a private signing key obtained by decrypting the encrypted resource authorization, and additional information;” “additional information” ersetzt ist durch “additional information including a hash of a massage” und der Teilsatz ergänzt ist um den Zusatz “, and wherein the plain authorization is not included in the unlock response”.

Zum Wortlaut von Hilfsantrag3F wird auf den Urteilstenor Bezug genommen. Hinsichtlich des Wortlauts der weiteren Patentansprüche in den zuvor genannten Hilfsanträgen sowie den Patentansprüchen nach den weiteren Hilfsanträgen wird auf die Akte verwiesen.

Die Klägerinnen treten auch den Hilfsanträgen entgegen und sehen die Gegenstände nach den Patentansprüchen in der Fassung der jeweiligen Hilfsanträge als nicht klar, unzulässig erweitert, nicht ausführbar, nicht neu bzw. nicht erfinderisch an. Zudem rügen sie die Stellung der Hilfsanträge 3E und 3F erst mit Schriftsatz vom 31. Januar 2025 und der Hilfsanträge 3Ea,3Eb und 12 erstmals in der mündlichen Verhandlung vom 9. April 2025 als verspätet.

Der Senat hat den Parteien im Verfahren mit dem Az.: 4 Ni 61/22 (EP) einen qualifizierten Hinweis vom 16. Januar 2023, ergänzt mit Hinweis vom 24. Juli 2024, und im Verfahren mit dem Az.: 4 Ni 41/23 (EP) einen Hinweis vom 24. Juli 2024 zugeleitet und hierin Fristen (letztere jeweils verlängert bis zum 31. Januar 2025) zur Stellungnahme gesetzt.

Wegen der weiteren Einzelheiten des Sach- und Streitstands wird auf die zwischen den Parteien gewechselten Schriftsätze nebst Anlagen, das Protokoll der mündlichen Verhandlung vom 9. April 2025 sowie den weiteren Akteninhalt Bezug genommen.

Die zulässigen Klagen haben in der Sache nur teilweise Erfolg, und zwar hinsichtlich der erteilten Fassung des Streitpatents sowie hinsichtlich der jeweiligen Fassung nach den Hilfsanträgen 1, 2A, 2B, 3A, 3B, 3C, 3D, 3E, 3Ea und 3Eb. Denn insoweit ist der Nichtigkeitsgrund der mangelnden Patentfähigkeit gemäß Art. II § 6 Abs. 1 Nr. 1 IntPatÜG, Art. 138 Abs. 1 Buchst. a) EPÜ i. V. m. Art. 52, 56 EPÜ bzw. der unzulässigen Erweiterung Art. II § 6 Abs. 1 Nr. 3 IntPatÜG, Art. 138 Abs. 1 Buchst. c) EPÜ gegeben.

In der Fassung nach dem Hilfsantrag 3F erweist sich das Patent hingegen als schutzfähig, so dass die Klagen, soweit sie sich auch gegen diese Fassung richten, abzuweisen sind. Auf die Frage, ob das Streitpatent auch in der Fassung nach den weiteren Hilfsanträgen Bestand hätte, kommt es bei dieser Sachlage nicht mehr an.

I. Gegenstand des Streitpatents, Aufgabe, Fachperson, Merkmalsgliederung und Auslegung

1. Das Streitpatent betrifft ein Verfahren und ein System zum Authentifizieren eines Nutzers gegenüber einer Computerressource, auf die über ein mobiles Gerät zugegriffen wird, unter Verwendung eines tragbaren Sicherheitstokens (beispielsweise einer kontaktlosen Smartcard oder eines Armbands), zusammen mit einem Geheimnis, an das sich der Benutzer leicht erinnern kann (z. B. ein PIN-Code). Dieses Geheimnis stellt einen zweiten, separaten, vorzugsweise unabhängigen Sicherheitsfaktor bereit, der die Computerressource schützen kann, selbst wenn der tragbare Sicherheitstoken und das mobile Gerät zusammen verloren gehen oder gestohlen werden(vgl. Streitpatentschrift, Absatz 0001).

Das Streitpatent geht von bekannten Systemen zur Authentifizierung eines Nutzers aus, welche einfache Passwörter oder PINs verwenden. Ein ideales Passwort müsse einerseits lang und schwer vorherzusagen, andererseits jedoch leicht zu merken sein. Dieser Widerspruch verstärke sich bei einer Vielzahl von Anwendungen (Apps) mit unterschiedlichen Passwörtern. Außerdem wollten einige Nutzer zusätzlich zum Zugriff auf Anwendungen ein hohes Maß an Sicherheit für Daten auf ihrem Gerät gewährleistet haben. Das könne durch eine Verschlüsselung auf Ebene des mobilen Betriebssystems erreicht werden, bei dem ein kryptographischer Schlüssel aus dem Entsperrpasswort des Geräts abgeleitet werde. Auch hierbei sei die Verwendung eines langen und komplexen Passworts sehr unbequem für den Nutzer (Absätze 0003 - 0007).

Ferner seien verschiedene Verfahren bekannt, die einen tragbaren physischen Token für ein zusätzliches Maß an Sicherheit verwendeten. Die Mobilvorrichtung (mobile device) überprüfe fortlaufend, ob sich der Token in der Nähe der Mobilvorrichtung befinde. Ein solches System habe den Nachteil, dass die häufige Kommunikation zwischen Mobilvorrichtung und Token leicht abgefangen und analysiert werden könne. Zudem könne ein Dieb die Mobilvorrichtung weiter nutzen, wenn er sich in der Nähe des Tokens aufhalte oder diesen gemeinsam mit der Mobilvorrichtung entwende (Absätze 0007 - 0009).

Aus der Patentanmeldung US 2011/0212707 A1 sei eine generische Authentifizierungslösung mit einem zusätzlichen Token bekannt, der einem Mobiltelefon einen asymmetrischen Schlüssel bereitstelle, den das Mobiltelefon zum Erstellen einer digitalen Signatur verwende, mit dem sich das Mobiltelefon bei einem außenstehenden Dienstanbieter authentifiziere. Bei Verlust eines solchen Tokens seien die darauf gespeicherten Anmeldedaten gefährdet. Die Verwendung des Tokens sei aus verschiedenen Gründen äußerst aufwendig und nicht mit bestehenden Anwendungen möglich (Absätze 0010, 0011).

Ein weiterer Ansatz zur Mehrfach-Faktor-Authentifizierung sei aus der Patentanmeldung US 2008/0289030 A1 bekannt. Die Authentifizierungslösung verwende einen kontaktlosen Token, der nach der Validierung den Zugriff auf die auf der Mobilvorrichtung gespeicherten Authentifizierungsdaten ermögliche. Dies setze die Verwendung eines sicheren Speichers in der Mobilvorrichtung voraus, der aber in der Regel vom Hersteller der Mobilvorrichtung oder dem Anbieter des Betriebssystems kontrolliert werde und Anwendungsentwicklern in der Regel nicht zur Verfügung stehe. Zudem könnten RFID-Tokens von jedem kompatiblen Lesegerät gelesen und einfach geklont werden (Absätze 0012, 0013).

Ein weiterer Ansatz sei in der Patentanmeldung WO 2011/089423 A1 beschrieben. Dabei erlaube das Vorhandensein eines kontaktlosen Tokens den Zugriff auf eine gesicherte Funktion oder Anwendung. Wesentlicher Nachteil sei, dass eine logische Kontrolle verwendet werde, die leicht zu umgehen sei (Absätze 0014, 0015).

Im Allgemeinen sieht das Streitpatent insbesondere im Unternehmensumfeld ein erhebliches Sicherheitsrisiko, wenn Benutzern das Verbinden von Mobilvorrichtungen mit dem Netzwerk des Unternehmens erlaubt werde. Dadurch steige die Wahrscheinlichkeit eines unbefugten Datenzugriffs – der zu einem Verlust der Vertraulichkeit und/oder Integrität der Daten führe – aufgrund von beispielsweise versehentlich (z. B. durch Über-die-Schulter-Schauen)offengelegten Passcodes wie PINs oder alphanumerischen Codes oder leicht zu erratenden Passcodes oder verlorenen oder gestohlenen Geräten oder nicht überwachten Geräten von Drittanbietern (Absatz 0016).

Durch die Ausführungsformen des beanspruchten Systems sollen Lösungen bereitgestellt werden, um diesen Gefahren entgegenzuwirken. Der Nutzer könne einen kryptographischen Hauptschlüssel (master key) mit hoher kryptographischer Stärke (128 Bit oder mehr) auf dem tragbaren Sicherheitstoken speichern und dieser Schlüssel könne verwendet werden, um entweder direkt den Datenverschlüsselungsschlüssel einer Anwendung oder ein langes und komplexes Passwort zu schützen, aus dem ein ausreichend langer und sicherer Verschlüsselungsschlüssel abgeleitet werden kann. Dies erlaube dem Nutzer, jegliche Daten auf der Mobilvorrichtung mit einer starken Verschlüsselung zu schützen, ohne dass ein Angreifer diese ohne Besitz des zugehörigen Tokens entschlüsseln könne (Absatz 0017). Der Token werde zusammen mit einem Geheimnis, z. B. einem PIN-Code, verwendet, das der Nutzer sich leicht merken könne (Absatz 0001).

2. Dem Streitpatent liege daher die Aufgabe zugrunde, ein Verfahren und ein System zum Authentifizieren eines Benutzers gegenüber einer Computerressource anzugeben, auf die über eine Mobilvorrichtung zugegriffen wird, unter Verwendung eines tragbaren Sicherheitstokens (z. B. einer kontaktlosen Chipkarte oder eines Armbands), zusammen mit einem Geheimnis, das sich der Benutzer leicht merken kann (z. B. einem PIN-Code) (vgl. Absätze 0001, 0016).

3. Die maßgebliche Fachperson zur Bearbeitung dieser Aufgabe verfügt über einen Fachhochschulabschluss der Fachrichtung Informatik und mehrjähriger Berufserfahrung im Bereich der Implementierung von Zugriffs- und Authentifizierungsverfahren in Computersystemen.

4. Die vom Streitpatent vorgeschlagene Lösung der Aufgabe nach Patentanspruch 1 lässt sich auf der Grundlage der von den Parteien vorgeschlagenen Merkmalsgliederung wie folgt gliedern:

1 in der Verfahrenssprache Englisch Übersetzung gemäß Streitpatent 1.1 A method of authenticating a user to access a computer resource via a mobile device comprising: Verfahren zum Authentifizieren eines Benutzers für den Zugriff auf eine Computerressource über eine Mobilvorrichtung, umfassend: 1.2 storing an encrypted resource authorization; Speichern einer verschlüsselten Ressourcenautorisierung; 1.3 transmitting the encrypted resource authorization to at least one separate portable security token device; Übertragen der verschlüsselten Ressourcenautorisierung an wenigstens eine getrennte tragbare Sicherheitstoken-Vorrichtung; 1.4 on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response; auf der wenigstens einen getrennten tragbaren Sicherheitstoken-Vorrichtung, Entschlüsseln der verschlüsselten Ressourcenautorisierung und Generieren, wenigstens teilweise daraus, einer Entsperrantwort; 1.5 securely transmitting the generated unlock response to the mobile device; and sicheres Übertragen der generierten Entsperrantwort an die Mobilvorrichtung; und 1.6 providing access via the mobile device to the computer resource if the required unlock response is valid; Gewähren des Zugriffs, über die Mobilvorrichtung, auf die Computerressource, falls die erforderliche Entsperrantwort gültig ist; 1.7 wherein a user is required to authenticate on the mobile device or on the at least one separate portable security token device, and wobei sich ein Benutzer auf der Mobilvorrichtung oder auf der wenigstens einen getrennten tragbaren Sicherheitstoken-Vorrichtung authentifizieren muss und 1.8 the user authentication is validated on the at least one separate portable security token device before the unlock response is sent. die Benutzerauthentifizierung auf der wenigstens einen getrennten tragbaren Sicherheitstoken-Vorrichtung validiert wird, bevor die Entsperrantwort gesendet wird.

Der Patentanspruch 9lässt sich danach wie folgt gliedern:

9 in der Verfahrenssprache Englisch Übersetzung gemäß Streitpatent A system for authenticating a user to access a computer resource via a mobile device, System zum Authentifizieren eines Benutzers für den Zugriff auf eine Computerressource über eine Mobilvorrichtung, the system comprising a mobile device and at least one separate portable security token device, wobei das System eine Mobilvorrichtung und wenigstens eine getrennte tragbare Sicherheitstoken-Vorrichtung umfasst, which comprise means for carrying out the method of claim 1. die Mittel zum Ausführen des Verfahrens nach Anspruch 1 umfassen.

5. Die Fachperson versteht die Lehre des Streitpatents und die Merkmale der sich im Wesentlichen entsprechendennebengeordneten Ansprüche, Verfahrensanspruch 1und Systemanspruch 9,wie folgt:

5.1 Gegenstand des Verfahrens gemäß Patentanspruch 1 ist nach Merkmal 1.1 das Authentifizieren eines Benutzers für den Zugriff auf eine Computerressource über eine Mobilvorrichtung (A method of authenticating a user to access a computer resource via a mobile device).

Nach den Angaben in der Beschreibung kann die Computerressource auf der Mobilvorrichtung oder auf einem entfernten Server angeordnet sein (vgl. Streitpatentschrift, Abs. 0002: …user access to a computer resource on the mobile device and secondly on a remote server; Abs. 0042: The resource may comprise data, or an application running or stored on the mobile device; sowie Abs. 0023, 0049). Aber auch ausgehend von einer Computerressource auf der Mobilvorrichtung liest die Fachperson mit, dass sich jedenfalls ein Teil der Computerressource auf einem externen Server befinden kann, denn Anwendungen (app/ application) speichern regelmäßig einen Teil ihrer Daten nicht auf den Mobilvorrichtungen, sondern auf einem Server (vgl. auch Abs. 0066: mobile apps and web apps; Abs. 0068: application server).

In beiden Fällen erfolgt gemäß Merkmal 1.1 der Zugriff auf die Computerressource durch den Nutzer über die Mobilvorrichtung (via a mobile device). Diese Formulierung versteht die Fachperson so, dass der Zugriff auf die Computerressource unter Verwendung der Mobilvorrichtung erfolgt. Sie stellt jedoch keine Beschränkung des Anspruchs auf Computerressourcen dar, die ausschließlich außerhalb der Mobilvorrichtung vorliegen.

Der Begriff „Computerressource“ (computer resource) selbst ist im Streitpatent nicht definiert. Der Beschreibung einer Ausführungsform in Absatz 0001 und weiteren Ausführungsbeispielen entnimmt die Fachperson, dass das Streitpatent unter den zu schützenden Ressourcen ganz allgemein Anwendungen und gespeicherte Daten versteht, auf die unter Verwendung einer Mobilvorrichtung zugegriffen werden kann (vgl. Abs. 0001: A preferred embodiment relates to providing data protection and secure access to applications and stored data accessed via a mobile device…; sowie Abs. 0042: The resource may comprise data, or an application running or stored on the mobile device; und Abs. 0085: At the minimum, a suitable service preferably supports the following functions: … Storage of arbitrary data on the server in an arbitrarily named file and directory). Das beanspruchte System und Verfahren soll den Schutz jeglicher Art von Daten unter Verwendung eines starken Schlüssels ermöglichen (vgl. Abs. 0017: This allows the user to protect any data stored on the device with a very strong encryption key.).

Vom Zugriff auf die Computerressource zu unterscheiden ist die zusätzlich – vor dem zu erlaubenden Zugriff (access) auf die Computerressource – durchzuführende Authentifizierung des Nutzers. Hierfür muss der Nutzer gemäß Merkmal 1.7 entweder an der Mobilvorrichtung (on the mobile device) oder an der separaten, tragbaren Sicherheitstoken-Vorrichtung (on the … token device) eine Eingabe vornehmen.

Bei der Mobilvorrichtung kann es sich um ein beliebiges mobiles Gerät handeln, das geeignet ist, die erforderlichen Funktionen gemäß den vorliegenden Patentansprüchen (in Verbindung mit dem Token) auszuführen. Als Beispiele für Mobilvorrichtungen sind u. a. Mobiltelefone, Tablets, Laptops, Smartphones und Smart Watches genannt (vgl. Abs. 0048).

Merkmal 1.2 sieht vor, dass eine verschlüsselte Ressourcenautorisierung (encrypted resource authorization) gespeichert wird. Das Streitpatent nennt als Beispiele für eine Autorisierung ein Passwort, eine PIN, einen kryptographischen Schlüssel oder eine biometrische Information (vgl. Abs. 0027, 0031). Wo die Speicherung der verschlüsselten Ressourcenautorisierung erfolgt, ist im Anspruch 1 nicht festgelegt (s. u.); die Fachperson erkennt allerdings, dass eine Speicherung auf der tragbaren Sicherheitstoken-Vorrichtung (portable security token device) ausscheidet, da die verschlüsselte Ressourcenautorisierung erst im Verfahrensablauf mit Merkmal 1.3 zur Entschlüsselung an diese übertragen wird (vgl. auch Abs. 0047, 0062). Dabei ist zwischen der (verschlüsselten) Ressourcenautorisierung (encrypted resource authorization) und dem Schlüssel zu deren Entschlüsselung (Password Encryption Key (PEK)) (vgl. Abs. 0034, 0093, 0100, 0134) durch den Token zu unterscheiden (vgl. Abs. 0036). Dieser Schlüssel zum Entschlüsseln der verschlüsselten Ressourcenautorisierung ist auf dem Token gespeichert (vgl. Abs. 0132: ...never leave the applet (nor the physical token)), bspw. als Teil der dort jeweils gespeicherten „user credentials“ (vgl. Abs. 0029, 0034, 0036). Durch das Speichern der verschlüsselten Ressourcenautorisierung außerhalb des Tokens, bspw. auf der Mobilvorrichtung (vgl. Abs. 0036: encrypted authorization stored on the mobile device) soll sichergestellt werden, dass allein der Besitz des Tokens oder allein die Kenntnis der verschlüsselten Ressourcenautorisierung jeweils nicht ausreicht, um auf die Computerressource zugreifen zu können (vgl. Abs. 0036: …can be decrypted solely with the corresponding user credentials stored on the token).

Die Speicherung der verschlüsselten Ressourcenautorisierung versteht die Fachperson als ein Bereithalten für deren spätere oder wiederholte Nutzung. Keine Speicherung im Sinne des Streitpatents stellt dagegen dar, wenn die verschlüsselte Ressourcenautorisierung im Rahmen einer Verarbeitung oder Übertragung – technisch bedingt – kurzzeitig in einem lokalen Speicher gehalten werden muss, bspw. während der Entschlüsselung auf dem Token nach Merkmal 1.4 oder in der Mobilvorrichtung während der Übertragung von einem Cloudspeicher über die Mobilvorrichtung zum Token (vgl. Abs. 0114, Schritte 3 und 5).

Die verschlüsselte Ressourcenautorisierung wird gemäß Merkmal 1.3 an wenigstens eine separate tragbare Sicherheitstoken-Vorrichtung (separate portable security token device) übertragen.

Bei der Sicherheitstoken-Vorrichtung (im Folgenden kurz: Token) handelt es sich um ein beliebiges tragbares bzw. mobiles Gerät, das einen Speicher und ein Betriebssystem (executable system) aufweist, das geeignet ist, die erforderlichen Kommunikations- und kryptografischen Funktionen auszuführen. Als Beispiele nennt das Streitpatent unter anderem Mobiltelefone, Tablets, Laptops, Smartphones, aber auch Smartcards (vgl. Abs. 0048, 0065). Aus der Bezeichnung als separater tragbarer Token folgt, dass dieser nicht Bestandteil der Mobilvorrichtung (mobile device) ist, über die der Zugriff auf die Computerressource erfolgt, bzw. diese Mobilvorrichtung nicht zugleich als Token dient. Ausgehend von den vorgenannten Beispielen gibt es keinen Hinweis darauf, dass ein anspruchsgemäßer Token aus mehreren Vorrichtungen besteht, bspw. ein (externes) Kartenlesegerät für Smartcards als „Teil“ des Tokens und nicht als Teil der Mobilvorrichtung angesehen wird, auch wenn dies im Streitpatent nicht explizit ausgeschlossen ist.

Der Patentanspruch legt auch in Merkmal 1.3 nicht fest, wo die verschlüsselte Ressourcenautorisierung (encrypted resource authorization) gespeichert ist (vgl. Merkmal 1.2). Damit ist in Anspruch 1 umfasst, dass die Speicherung lokal auf der Mobilvorrichtung (vgl. Abs. 0036) oder in einem externen Gerät (Server, Cloud) erfolgt. Anspruch 1 umfasst damit auch, dass die verschlüsselte Ressourcenautorisierung erst von der Mobilvorrichtung aus der Cloud – also von einem externen Server – abgerufen wird und von dieser an den Token übertragen wird, wie dies bspw. das Ausführungsbeispiel nach Figur 6der Streitpatentschrift vorsieht (vgl. Abs. 0114, Schritte 3 und 5):

In Anspruch 1 bleibt auch offen, wodurch die Übertragung der verschlüsselten Ressourcenautorisierung (encrypted resource authorization) an den Token ausgelöst wird.

Zur Bedeutung des möglichen Übertragens der verschlüsselten Ressourcenautorisierung an mehr als einen Token (Merkmal 1.3: to at least one … token device) sind dem Streitpatent keine näheren Angaben zu entnehmen. Vielmehr sind die Verfahrensabläufe im Streitpatent lediglich unter Verwendung einer Mobilvorrichtung zusammen mit nur einem einzelnen Token beschrieben (Each mobile device may only be paired with one token; vgl. Abs. 0077).

Auf der wenigstens einen separaten tragbaren Sicherheitstoken-Vorrichtung erfolgt gemäß Merkmal 1.4 ein Entschlüsseln der verschlüsselten Ressourcenautorisierung (decrypting encrypted resource authorization) und – wenigstens teilweise daraus – ein Generieren einer Entsperrantwort (unlock response).

Bei der Entsperrantwort kann es sich um die entschlüsselte Ressourcenautorisierung selbst handeln, die im Streitpatent als „plain authorization“ bezeichnet wird (vgl. Abs. 0025). Sie kann aber auch auf weiteren Berechnungen ausgehend von der entschlüsselten Ressourcenautorisierung, ggf. unter Verwendung weiterer, Token-basierter Daten beruhen, wie bspw. eine digitale Signatur, eine Schlüsselableitung oder eine Wiederverschlüsselung (vgl. Abs. 0026).

Merkmal 1.5 sieht ein sicheres Übertragen der generierten Entsperrantwort an die Mobilvorrichtung vor. In welcher Weise die Sicherheit der Übertragung gewährleistet wird, geht aus dem Anspruch 1 nicht hervor. Als bevorzugte Implementierung der Kommunikation zwischen Mobilvorrichtung und Token sieht das Streitpatent NFC oder andere Arten der Funkkommunikation, wie bspw. Bluetooth, vor (vgl. Abs. 0044, 0057, 0059, 0066). Das Streitpatent spricht dabei von einer Ausgestaltung der Implementierung der Kommunikation zwischen Mobilvorrichtung und Token durch jede Art der Kommunikation, die in ausreichender Weise für die Übertragung von Authentifizierungsdaten gesichert werden kann (vgl. Abs. 0058: …communication between the mobile device and the portable token may be implemented using any form of communication that can be sufficiently secured for the transmission of authentication credentials…), und nennt als Beispiele für Kommunikationsformen, die grundsätzlich für eine sichere Kommunikation geeignet sind, unter anderem ein lokales WLAN-Netzwerk, eine „WiFi direct“-Verbindung, eine direkte Verbindung mit USB-Kabel sowie die Verwendung von Kamera oder Mikrofon und Lautsprecher von Mobilvorrichtung und Token (vgl. Abs. 0058).

Dem Begriff „sicheres Übertragen“ in Merkmal 1.5 kommt damit eine technische Bedeutung zu. Im Kontext des Streitpatents bedeutet dies, dass eine ausreichend sichere Übertragung der Entsperrantwort gewährleistet werden soll, was die Fachperson zumindest als Verhindern eines direkten Zugriffs durch Dritte bei der Übertragung der Daten versteht. Als Beispiel hierfür sieht Absatz 0028 des Streitpatents vor, dass die Entsperrantwort (unlock response) durch einen kryptographischen Schlüssel, bspw. einen Session Key, geschützt werden kann. Eine direkte USB-Verbindung, wie sie beispielgebend in Absatz 0058 genannt ist, wird die Fachperson insoweit als „sicher“ verstehen, als kein direkter externer Zugriff auf diese Kommunikationsverbindung zwischen Token und Mobilvorrichtung erfolgen kann (bspw. kein „Mithören“).

Falls die erforderliche Entsperrantwort (unlock response) gültig ist, erfolgt gemäß Merkmal 1.6 über die Mobilvorrichtung das Gewähren des Zugriffs auf die Computerressource. Dem Streitpatent ist nicht zu entnehmen, wie der Zugriff erfolgt. Auch findet sich im Streitpatent keine Angabe dazu, wie die Gültigkeit der Entsperrantwort (…if the required unlock response is valid) festgestellt wird (vgl. auch Abs. 0043, 0059, 0060, 0062, 0063). Die Fachperson versteht dies so, dass keine explizite – d. h. zusätzliche – Überprüfung der Gültigkeit der Entsperrantwort erfolgen muss, sondern die Mobilvorrichtung die an sie übertragene Entsperrantwort unmittelbarverwendet, um auf die Computerressource zugreifen zu können. Wenn die Entsperrantwort nicht gültig ist, z. B. wegen einer Manipulation, wird die Mobilvorrichtung diese Ungültigkeit daran erkennen, dass sie auf die Computerressource nicht zugreifen kann.

Entsprechend der Authentifizierung für den Zugriff auf eine Computerressource über die Mobilvorrichtung (via a mobile device) nach Merkmal 1.1 erfolgt der Zugriff auf die Computerressource nach Merkmal 1.6 über die Mobilvorrichtung. Die Computerressource kann sich – wie dargelegt – ganz oder teilweise auf der Mobilvorrichtung oder auf einem Server befinden; jedenfalls erfolgt der Zugriff auf die Computerressource unter Verwendung der Mobilvorrichtung.

Bei dem anspruchsgemäßen Verfahren muss sich der Benutzer gemäß Merkmal 1.7 (zusätzlich) auf der Mobilvorrichtung oder auf der wenigstens einen getrennten tragbaren Sicherheitstoken-Vorrichtung authentifizieren. Eine solche Authentifizierung gemäß Merkmal 1.7 auf der Mobilvorrichtung ist in Absatz 0030 des Streitpatents beschrieben (vgl. auch Ausführungsbeispiele in den Absätzen 0041, 0045, 0059, 0060, 0061, 0114) und die Alternative der Authentifizierung auf dem Token ist in den Absätzen 0062, 0063 und 0064 genannt. Sofern die Authentifizierung auf dem Token erfolgt, muss dieser eine Eingabevorrichtung, beispielsweise ein Display und/oder eine Tastatur, aufweisen. Ein Token kann dabei auch ein Smartphone, eine Smartwatch, ein Tablet o. Ä. sein (vgl. Abs. 0065).

Nach Merkmal 1.8 muss die Benutzerauthentifizierung (siehe Merkmal 1.7) auf der wenigstens einen getrennten tragbaren Sicherheitstoken-Vorrichtung validiert werden, bevor die Entsperrantwort gesendet wird (siehe Merkmal 1.5). Zur Validierung selbst macht das Streitpatent keine näheren Angaben. Die Fachperson versteht unter der Validierung ein Überprüfen der Benutzerauthentifizierung, also bspw. der eingegeben PIN bzw. des Passworts, das entweder an der Mobilvorrichtung oder am Token selbst eingegeben wurde (vgl. Abs. 0030 bis 0032, 0041, 0114). Mithin beschreibt die Authentifizierung auf (on) einem Gerät (Mobilvorrichtung oder Token) nach Merkmal 1.7 nur die Eingabe dieses Nutzergeheimnisses am entsprechenden Gerät, deren Validierung im Sinne einer Prüfung dann gemäß Merkmal 1.8 auf dem Token erfolgt (vgl. Abs. 0030), bspw. durch Vergleich mit einer auf dem Token hinterlegten PIN (vgl. Abs. 0114).

Die Fachperson versteht Merkmal 1.8 so, dass die im Merkmal 1.5 genannte Übertragung der im Token generierten Entsperrantwort nur bei erfolgreich validierter Authentifizierung erfolgt, d. h. wenn die eingegebene PIN bzw. das Passwort gültig ist. Dabei legt Anspruch 1 nicht fest, zu welchem Zeitpunkt die Validierung auf dem Token erfolgt, vielmehr folgt aus Merkmal 1.8 nur, dass diese vor dem Übertragen der Entsperrantwort, d. h. vor dem Verfahrensschritt gemäß dem Merkmal 1.5, erfolgen muss. So ist in der Beschreibung des Streitpatents bspw. auch vorgeschlagen, dass die Validierung bereits vor der Entschlüsselung der verschlüsselten Ressourcenautorisierung, d. h. vor dem Verfahrensschritt gemäß dem Merkmal 1.4, erfolgen kann (vgl. Abs. 0045:The device communications system may send a user secret to the token which is validated by the token before the decryption operation takes place; sowie Abs. 0041). Zur Vorgehensweise bei nicht erfolgreicher Validierung trifft das Streitpatent keine Aussage. Anspruch 1 fordert auch nicht, dass die Authentifizierung nach Merkmal 1.7 und deren Validierung nach Merkmal 1.8 bei jedem Zugriff auf die Computerressource bzw. im Rahmen dieses Zugriffs durchgeführt werden müssen, sondern gemäß Merkmal 1.8 nur, dass die Validierung vor dem Senden der Entsperrantwort erfolgt ist.

Die erste Alternative einer Authentifizierung nach Merkmal 1.7, also die Authentifizierung auf der Mobilvorrichtung, dient dabei dazu, die Eingabemittel der Mobilvorrichtung für die Nutzereingabe zu nutzen. Dadurch benötigt der Token in diesem Fall nicht zwangsläufig eine eigene Tastatur oder andere Eingabemittel, um eine Benutzerauthentifizierung nach Merkmal 1.8 validieren zu können.

Die Authentifizierung mit ihrer Validierung gemäß den Merkmalen 1.7 und 1.8 bildet damit neben der aus der verschlüsselten Ressourcenautorisierung im Token generierten Entsperrantwort den zweiten Teil der Zwei-Faktor-Authentifizierung (two-factor authentication) zum Zugriff auf die Computerressource (vgl. Abs. 0030).

5.2 Gegenstand des Patentanspruchs 9 ist ein System zum Authentifizieren eines Benutzers für den Zugriff auf eine Computerressource über eine Mobilvorrichtung, wobei das System eine Mobilvorrichtung und wenigstens eine getrennte tragbare Sicherheitstoken-Vorrichtung umfasst, aber nicht auf diese Vorrichtungen beschränkt ist. Das System umfasst weiterhin Mittel zum Ausführen des Verfahrens nach Patentanspruch 1, d. h. es weist geeignet gestaltete und eingerichtete Mittel zur Ausführung des Verfahrens nach Patentanspruch 1 auf.

II. Zur erteilten Fassung

Die Patentansprüche 1 bis 9 der erteilten Fassung erweisen sich als nicht rechtsbeständig. Insoweit ist jedenfalls der Nichtigkeitsgrund der mangelnden Patentfähigkeit gemäß Art. II § 6 Abs. 1 Nr. 1 IntPatÜG, Art. 138 Abs. 1 Buchst. a) EPÜ i. V. m. Art. 52, 56 EPÜ gegeben.

1. Zum Nichtigkeitsgrund der mangelnden Ausführbarkeit

Die Erfindung ist im Streitpatent hinreichend deutlich und vollständig offenbart, so dass eine Fachperson die beanspruchte Lehre ausführen kann.

Das Streitpatent muss nicht für alle denkbaren Ausgestaltungen über die gesamte Anspruchsbreite Ausführungsbeispiele liefern, solange die Fachperson sinnvolle Ausgestaltungen „ohne erfinderisches Zutun“ ausführen kann (EPA-Prüfungsrichtlinien, D. V. 4. und F. III. 1.-3.; BGH, Urteil vom 12. Dezember 2006 – X ZR 131/02, GRUR 2007, 309 - Schussfädentransport). Eine Erfindung ist ausführbar offenbart, wenn die Fachperson ohne erfinderisches Zutun und ohne unzumutbare Schwierigkeiten in der Lage ist, die Lehre des Patentanspruchs auf Grund der Gesamtoffenbarung der Patentschrift in Verbindung mit dem allgemeinen Fachwissen und Fachkönnen so zu verwirklichen, dass der angestrebte Erfolg erreicht wird. Dazu genügt es, wenn die Patentschrift ansatzweise erkennen lässt, durch welche Mittel und auf welche Weise die beanspruchte technische Lehre verwirklicht werden kann (BGH, Urteil vom 29. März 2022 – X ZR 16/20,juris – Übertragungsleistungssteuerungsverfahren, Leitsatz 2). Es ist daher nicht erforderlich, dass mindestens eine praktisch brauchbare Ausführungsform als solche unmittelbar und eindeutig offenbart ist. Vielmehr reicht es aus, wenn die Fachperson ohne eigenes erfinderisches Bemühen Unvollständigkeiten ergänzen und sich notfalls mit Hilfe orientierender Versuche Klarheit verschaffen kann (BGH, Urteil vom 13. Juli 2010 – Xa ZR 126/07, GRUR 2010, 916 – Klammernahtgerät, juris Leitsatz und Rn. 17). Denn sie entnimmt bereits die zur Ausführung der Erfindung in den Ansprüchen regelmäßig nicht vollständig enthaltenen aber für die praktische Verwirklichung erforderlichen Einzelangaben der allgemeinen Beschreibung (BGH, Urteil vom 28. März 2017 – X ZR 17/15, juris Rn. 23 m. w. N.).

Auch wenn das beanspruchte Verfahren mit den Merkmalen 1.3 und 1.8 abweichend von der Beschreibung das Verfahren auch für mehr als einen Tokenformuliert, ist die Fachperson in der Lage, dies auszuführen. Eine solche Verwendung von mehr als einem Token stellt die Fachperson nicht vor größere Hindernisse, da die Verwendung eines zweiten Tokens bereits durch analoge Durchführung der Verfahrensschritte für den ersten Token gelöst werden kann, bspw. indem zur Gewährung des Zugriffs auf die Ressource bspw. beide Token bzw. beide Entsperrantworten zum Zugriff auf die Computerressource vorliegen müssen.

Soweit die Klägerin zu 1 die Schwierigkeiten bei Verlust des Tokens beschreibt, stellt dies kein Problem der Ausführbarkeit dar, da sich das Streitpatent nicht mit der Frage von Lösungen für einen Verlust von Authentifizierungsmitteln befasst. Letztere sind der Fachperson zudem durchaus bekannt in Form von zusätzlichen Sicherheitsabfragen („Super-PIN“, Pass-Phrase oder insbesondere mehreren Authentifizierungsmerkmalen) sowie von Lösungen unter Verwendung von Administratorrechten, bspw. durch den Anbieter des Dienstes oder der Computerressource.

2. Zur Patentfähigkeit des Streitpatents in der erteilten Fassung

Der Gegenstand des Patentanspruchs 1 erweist sich in der erteilten Fassung (Hauptantrag) gegenüber Dokument D10 (Corner et al.) oder auch ausgehend von Dokument D1 (US 2010/0228991 A1) in Verbindung mit dem Fachwissen als nicht patentfähig.

2.1 Zur Frage der wirksamen Inanspruchnahme der Priorität

Der Senat hat durchaus Zweifel, dass die Priorität der britischen Patentanmeldung GB 1221433.4 (Anlage NK3), der US-Patentanmeldung US 13/706,307 (Anlage NK4) und der britischen Patentanmeldung GB 1303677.7 (Anlage NK5) materiell wirksam in Anspruch genommen sind, da sich aus keiner der drei Prioritätsanmeldungen ein Authentifizieren eines Benutzers für den Zugriff auf eine Computerressource über eine Mobilvorrichtung ergibt, bei dem sich der Benutzer auf der wenigstens einen getrennten tragbaren Sicherheitstoken-Vorrichtung authentifizieren muss (Merkmal 1.7, zweite Alternative).

Diese Frage kann allerdings im Hinblick auf die für die Beurteilung der Patentfähigkeit des Patentanspruchs 1 in erteilter Fassungbedeutsamen Dokumente D1 und D10 dahinstehen, da beide Dokumente vor dem frühesten Prioritätsdatum veröffentlicht sind.

2.2 Der jeweilige Gegenstand der unabhängigen Patentansprüche 1 und 9 gemäß Hauptantrag (erteilte Fassung) ist nicht neu gegenüber dem Dokument D10(Corner et al.; wobei der Senat die Bezeichnung D10 gewählt hat für das ursprünglich als Dokument D2 ins Verfahren 4 Ni 41/23 (EP) eingeführte und als Dokument D10 ins Verfahren 4 Ni 61/22 (EP) übernommene Dokument).

a) Das Dokument D10 befasst sich – wie das Streitpatent – mit dem sicheren Zugriff auf Computerressourcen, hier insbesondere auf Dateien, die mit einem Dateischlüssel (file key) Ke verschlüsselt sind. Die Entschlüsselung der Datei (file) erfolgt jeweils mit dem entschlüsselten Dateischlüssel.

Der Dateischlüssel (file key) Keselbst ist durch einen Schlüssel-verschlüsselnden Schlüssel Kk verschlüsselt, der nur durch Verwendung des Tokens entschlüsselt werden kann (vgl. Abschnitt 2.2 Key-encrypting keys: In ZIA, each on-disk object is encrypted by some symmetric key, K e . The link connecting the laptop and token is slow, and the token is much less powerful than the laptop. Consequently, file decryption must take place on the laptop, not the token. The file system stores each K e , encrypted by some key-encrypting key, K k ; we write this as K k (K e ). Only tokens know key-encrypting keys; they are never divulged. A token with the appropriate K k can decrypt K e , and hence enable reading any file encrypted by K e .).

Auch zeigt das Dokument D10eine Zwei-Faktor-Authentifizierung, die eine Authentifizierung des Nutzers beim Zugriff auf eine Datei, also beim Zugriff auf eine Computerressource darstellt. Denn die Authentifizierung des Nutzers gegenüber dem Token ist Voraussetzung und somit Teil der Authentifizierung zum Zugriff auf diese Computerressource (file) unter Verwendung des Tokens, der nur dann eine gültige Entsperrantwort (File key) aus einer verschlüsselten Ressourcenautorisierung (Encrypted File key) generieren kann, wenn sich der Nutzer mittels eines Codes (PIN) gegenüber dem Token identifiziert hat. Damit schaffen nur beide Teile dieser Zwei-Faktor-Authentifizierung gemeinsam die Grundlage für das Vorliegen einer validen Entsperrantwort (File Key).

b) Aus dem Dokument D10 sind – in den Worten des Streitpatents – die folgenden Merkmale des Anspruchs 1 zu entnehmen:

1.1 A method of authenticating a user to access a computer resource via a mobile device comprising: [DieD10 befasst sich mit dem sicheren Zugriff eines Nutzers auf verschlüsselte Dateien, wobei der Dateischlüssel (file key) selbst durch einen Schlüssel-verschlüsselnden Schlüssel verschlüsselt ist, der nur durch Verwendung eines Tokens entschlüsselt werden kann (vgl. Abschnitt2.2 Key-encrypting keys: In ZIA, each on-disk object is encrypted by some symmetric key, K e . … A token with the appropriate K k can decrypt K e , and hence enable reading any file encrypted by K e .)] 1.2 storing an encrypted resource authorization; [Dokument D10 sieht eine gespeicherte, als „encrypted file key“ bezeichnete verschlüsselte Ressourcenautorisierung vor (vgl. Fig. 1: Encrypted File keys are read from disk…).] 1.3 transmitting the encrypted resource authorization to at least one separate portable security token device; [Die Ressourcenautorisierung wird vom Token empfangen (vgl. Fig. 1: Encrypted File keys are … shipped to the token).] 1.4 on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response; [Auf dem Token erfolgt die Entschlüsselung der verschlüsselten Ressourcenautorisierung und das Erzeugen einer Entsperrantwort, d. h. des „File key” (vgl. Fig. 1: The token decrypts it and returns the File key.).] 1.5 securely transmitting the generated unlock response to the mobile device; [Die Entsperrantwort wird verschlüsselt an die Mobilvorrichtung übertragen (vgl. Fig. 1: The token decrypts it and returns the File key. Traffic between the laptop and token is encrypted…); und Abschnitt 2. Design: Second, the token cannot send decrypted File keys over the wireless link in cleartext form. Therefore, the token and laptop use an authenticated, encrypted link.] 1.6 providing access via the mobile device to the computer resource if the required unlock response is valid; [Sofern der richtige Schlüssel (file key K e ) als Entsperrantwort übermittelt wurde, ist dieser auch gültig und erlaubt den Zugriff auf die Computerressource (vgl. Abschnitt 2.2 Key-encrypting keys: In ZIA, each on-disk object is encrypted by some symmetric key, K e . … A token with the appropriate K k can decrypt K e , and hence enable reading any file encrypted by K e .).] 1.7 2.Alt. wherein a user is required to authenticate on the mobile device or on the at least one separate portable security token device, and [Die Token-Vorrichtung ist durch eine PIN geschützt, durch deren Eingabe der Nutzer den Token entsperren kann (vgl. Abschnitt 2.3 Token vulnerabilities: The most serious vulnerability surrounding token loss is the extraction of key-encrypting keys. PIN-protected, tamper-resistant hardware [40] makes this more difficult, … Bounding the authentication session between the user and token also prevents an attacker from profitably stealing a token, and then later a laptop. After the authentication period expires, the token will no longer be able to supply any requested K e ; und Abschnitt 2. Design: Before the first use of a token, the user must unlock it using a PIN . [Unterstreichungen jeweils ergänzt]).] 1.8 the user authentication is validated on the at least one separate portable security token device before the unlock response is sent. [Da die Token-Hardware selbst „PIN-protected“ sein soll, liest die Fachperson eine Authentifizierung und Validierung im Token mit (vgl. Abschnitt2.3 Token vulnerabilities: The most serious vulnerability surrounding token loss is the extraction of key-encrypting keys. PIN-protected, tamper-resistant hardware [40] makes this more difficult, … ).]

Dass die Authentifizierung des Nutzers am Token in Dokument D10 nur einmalig für einen bestimmten Zeitraum (authentication period) erfolgt, steht nicht im Widerspruch zu den Merkmalen 1.7 (zweite Alternative) und 1.8, da eine solche, nur einmalige Authentifizierung des Nutzers am Token in Patentanspruch 1 nicht ausgeschlossen ist. Die Authentifizierung nach den Merkmalen 1.7 und 1.8 ist weder direkt mit einem konkreten Zugriffsversuch auf eine bestimmte Computerressource verknüpft, noch erfolgt ein Prüfen der Authentifizierung zwingend erst nach dem Entschlüsseln bzw. Erzeugen der Entsperrantwort. Vielmehr fordert Merkmal 1.8 nur, dass die Validierung der Nutzerauthentifizierung auf dem Token erfolgt, bevor eine Entsperrantwort – also im Fall der D10 ein entschlüsselter Dateischlüssel – vom Token an die Mobilvorrichtung gesendet wird (Merkmal 1.8: …before the unlock response is sent). Die Lehre der D10 steht insbesondere auch im Einklang mit Absatz 0045 des Streitpatents, der vorsieht, dass die Validierung der Nutzerauthentifizierung auf dem Token erfolgt, bevor die Entschlüsselung der Ressourcenautorisierung erfolgt (vgl. Streitpatent, Abs. 0045: The device communications system may send a user secret to the token which is validated by the token before the decryption operation takes place.; entsprechend auch Absatz 0041).

Es steht ebenfalls nicht im Widerspruch zum Streitpatent, dass durch die Entschlüsselung im Token gemäß der D10 direkt eine Entsperrantwort (file key) erzeugt wird, da Anspruch 1 nur fordert, dass die Entsperrantwort zumindest teilweise auf der entschlüsselten verschlüsselten Ressourcenautorisierung basiert (Merkmal 1.4). Das Streitpatent sieht zudem eine solche Möglichkeit expliziert vor (vgl. Streitpatent, Abs. 0025: The unlock response may comprise a plain authorization, obtained by decrypting the encrypted authorization.).

Schließlich steht auch die aus Performance-Gründen in der D10 gewählte Vorgehensweise in Bezug auf Daten im Cache der Mobilvorrichtung nicht im Widerspruch zur Lehre des Streitpatents, da auf der Festplatte der Mobilvorrichtung gespeicherte Dateien, mithin Computerressourcen im Sinne des Streitpatents, grundsätzlich verschlüsselt sind und somit in der D10 erst bei einem Zugriff unter Verwendung des Tokens entsprechend dem Verfahren nach Anspruch 1 des Streitpatents eine Entsperrantwort (file key) bestimmt wird (vgl. Figur 1 in Verbindung mit Abschnitt 2. Design: All on-disk files are encrypted for safety, but all cached Files are decrypted for performance.).

Die Gegenstände des auf ein Verfahren gerichteten Patentanspruchs 1 und des nebengeordneten, auf ein System zur Durchführung des Verfahrens gerichteten Patentanspruchs 9 erweisen sich daher jeweils als nicht neu gegenüber Dokument D10.

2.3 Der jeweilige Gegenstand der unabhängigen Patentansprüche 1 und 9 gemäß Hauptantrag (erteilte Fassung) istneu gegenüber dem Dokument D1(US 2010/0228991 A1; Bezeichnung als D1 übernommen nachdem das Dokument ursprünglich als Dokument D1 ins Verfahren 4 Ni 61/22 (EP) eingeführt worden ist). Er beruht jedoch ausgehend von der D1 nicht auf einer erfinderischen Tätigkeit.

a) Ziel des Dokuments D1 ist das Bereitstellen einer Zwei-Faktor-Authentifizierung unter Verwendung einer Sicherheitstoken-Vorrichtung bei einem Zugriff auf Computer, Server oder Datenspeichergeräte und -einrichtungen, die ein Passwort erfordern (Abs. 0009: It is an object of the present invention to provide means of dual factor authentication that will allow a security token device to control access to an unlimited number of Secure Systems, which could be computers, servers, other data storage devices or facilities, each requiring a unique password, without the usual requirement for storing each password inside of the security token.). Dokument D1 lehrt die Verwendung eines solchen Sicherheitstokens für einen Computer, bspw. einen Windows XP Computer, zur Zwei-Faktor-Authentifizierung eines Nutzers beim Zugriff auf den Computer bzw. auf ein Nutzerkonto (user account) auf diesem Computer (vgl. Abs. 0027). Der Token wird mit dem USB-Port des Computers verbunden (vgl. Abs. 0029).

Dokument D1 – Fig. 3

b) Aus DokumentD1 sind – in den Worten des Streitpatents – folgende Merkmale des Anspruchs 1 zu entnehmen:

1.1 teil A method of authenticating a user to access a computer resource via a mobile device comprising: [Dokument D1 spricht von verschiedenartigen sicheren Systemen (computers, servers, other data storage devices or facilities, vgl. Abs. 0009), ohne dass mobile Vorrichtungen explizit erwähnt sind (vgl. Abs. 0009: dual factor authentication that will allow a security token device to control access to an unlimited number of Secure Systems; sowie Abs. 0028: login to the user account). Bei dem Nutzerkonto (user account) handelt es sich um eine Computerressource im Sinne des Streitpatents (Merkmale 1.1, 1.6), insbesondere, da die D1 darunter nicht den Zugang zur Hardware, sondern den Zugriff auf die mit dem Nutzer verknüpften Ressourcen versteht, wie bspw. in der Verwendung des Begriffs Nutzerkonto (user account) in Bezug auf einen „Server“ als Speicherort für Nutzerdaten deutlich wird, wobei hierbei ein Zugriff auf diese (externe) Ressource über eine erste Vorrichtung erfolgt (Abs. 0079; Fig. 7).] 1.2 storing an encrypted resource authorization; [DokumentD1 sieht eine gespeicherte, als „Hidden Secret“ bezeichnete verschlüsselte Ressourcenautorisierung vor (vgl. Abs. 0014, le. Satz und Abs. 0028, le. Satz).] 1.3 transmitting the encrypted resource authorization to at least one separate portable security token device; [Die Ressourcenautorisierung wird vom Token empfangen (vgl. Abs. 0015, 0029: …the token receives the Hidden Secret).] 1.4 on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response; [Auf dem Token erfolgt die Entschlüsselung der verschlüsselten Ressourcenautorisierung, d. h. des „hidden secret”, und das Erzeugen einer Entsperrantwort (vgl. Abs. 0029: The user token 1 decrypts the Hidden Secret 10 using its internally stored, Primary Secret 5. The plain-text, decrypted password is given … back to the Windows machine; sowie Abs. 0015).] 1.5 teil securely transmitting the generated unlock response to the mobile device; [Die Entsperrantwort wird über eine USB-Verbindung an das Computersystem übertragen (vgl. Abs. 0029: The plain-text, decrypted password is given from inside the token, back to the Windows machine via the USB port…; sowie Abs. 0015). Eine „sichere“ Übertragung ist zwar in der D1 nicht explizit genannt oder thematisiert. Jedoch versteht die Fachperson die in derD1 vorgesehene Übertragung der Entsperrantwort, d. h. des entschlüsselten Passworts, über den USB-Port bereits als eine “sichere Übertragung” im Sinne von Merkmal 1.5 des Streitpatents (vgl. auch Ausführungen zur Auslegung von Merkmal 1.5).Auch wenn die D1 diese Eigenschaft der USB-Verbindung zwischen Token und Computer nicht thematisiert, versteht die Fachperson diese schon deshalb als “sichere Übertragung”, da eine Übertragung des entschlüsselten Passworts vom Token zum Computer über eine nicht „sichere“ Verbindung im Widerspruch zur Zielsetzung desDokumentsD1 stünde (vgl. Abs. 0001, 0009). Zudem erkennt die Fachperson aufgrund ihres Fachwissen und dem Sinn und Zweck der Ausgestaltung, dass es sich bei der in derD1 vorgeschlagene USB-Verbindung – wie auch in Absatz 0058 des Streitpatents beispielgebend vorgesehen – als eine geeignete, gegen „Mithören“ sichere Übertragung handelt.] 1.6 teil providing access via the mobile device to the computer resource if the required unlock response is valid; [Der Zugriff auf das Nutzerkonto bzw. die damit verbundenen Ressourcen wird durch das an die Vorrichtung übermittelte Passwort, d. h. das im Token entschlüsselte „Hidden Secret“, ermöglicht (vgl. Abs. 0015, letzter Satz:…which can then be transferred back to the computer as the login password, and access is granted; sowie Abs. 0029, letzter Satz). Bei dem Nutzerkonto (user account) handelt es sich um eine Computerressource im Sinne des Streitpatents (vgl. Ausführungen zu Merkmal 1.1).] 1.7 1.Alt/teil wherein a user is required to authenticate on the mobile device or on the at least one separate portable security token device, and [Die Eingabe der PIN zum Authentifizieren des Nutzers erfolgt am Computer beim Einloggen, eine Prüfung dieser Eingabe im Sinne einer Validierung erfolgt auf dem Token, da es sich um eine Authentifizierung für die Verwendung des Tokens handelt (vgl. Abs. 0015, erster Satz: When the user attempts to log into the computer, the token requires the user to enter a PIN (Personal Identification Number) to verify that the user is authorized to use the token…, i. V. m. Abs. 0029).] 1.8 the user authentication is validated on the at least one separate portable security token device before the unlock response is sent. [Die Benutzerauthentifizierung mit PIN wird im Token validiert, bevor das „Hidden Secret“ zur Entschlüsselung an den Token übertragen wird. Damit erfolgt die Validierung zwangsläufig auch bevor die Entsperrantwort, d. h. das entschlüsselte Passwort, über die USB-Verbindung an den Computer zurückgegeben wird (vgl. Abs. 0029).]

DokumentD1 zeigt, ebenso wie das Streitpatent, eineZwei-Faktor-Authentifizierung.Abgesehen davon, dass das DokumentD1 diese Zwei-Faktor-Authentifizierung ausdrücklich so bezeichnet(dual factor method of authentication, vgl. Abs. 0001; dual factor authentication, vgl. Abs. 0009), umfasst die Lehre desDokumentsD1 zwei voneinander unabhängige Prüfungen. Einen ersten Faktor der Authentifizierung bildet die Nutzer-Authentifizierung durch PIN-Eingabe (PIN 8), die im Token validiert wird (vgl. Abs. 0029, erster und zweiter Satz), und einen zweiten Faktor bildet das entschlüsselte „Hidden Secret“ als Login-Passwort, das durch den Token entschlüsselt und bereitgestellt wird (Hidden Secret 10 bzw. encrypted version of the password 10). Beim „Hidden Secret“ handelt es sich um eine verschlüsselte Zufallszahl, die ursprünglich im Token erzeugt wurde und die als Login-Passwort (password 6) dient (vgl. Abs. 0028, erster, zweiter und letzter Satz).

Es steht nicht im Widerspruch zum anspruchsgemäßen Generieren der Entsperrantwort, dass die Entsperrantwort nach DokumentD1 dem entschlüsselten „Hidden Secret“ entspricht. Denn Merkmal 1.4 des Anspruchs 1 des Streitpatents fordert nur, dass die Entsperrantwort zumindest teilweise auf der entschlüsselten Ressourcenautorisierung basiert, was auch erfüllt ist, wenn sie vollständig der entschlüsselten Ressourcenautorisierung entspricht. Entsprechendes ist auch Absatz 0025 des Streitpatents zu entnehmen, wonach die Entsperrantwort beispielsweise allein durch Entschlüsseln der Ressourcenautorisierung erzeugt werden kann (The unlock response may comprise a plain authorization, obtained by decrypting the encrypted authorization, vgl. Streitpatent, Abs. 0025).

Damit unterscheidet sich DokumentD1 vom Gegenstand des Patentanspruchs 1 des Streitpatents darin, dass eine Mobilvorrichtung für die Sicherheitsprüfung (Merkmale 1.1, 1.5, 1.6, 1.7) nicht explizit genannt ist.

Die Gegenstände des Patentanspruchs 1 und des auf diesen rückbezogenen Patentanspruchs 9 erweisen sich daher jeweils als neu gegenüber DokumentD1.

c) Der jeweilige Gegenstand der Patentansprüche 1 und 9 des Streitpatents ist der Fachperson jedoch ausgehend von DokumentD1 in Verbindung mit ihrem Fachwissen nahegelegt und beruht daher nicht auf einer erfinderischen Tätigkeit.

Eine „Mobilvorrichtung“ war, insbesondere in Form von Laptops und PDAs, zum Anmeldezeitpunkt vom fachmännischen Verständnis der nur allgemein genannten Computersysteme von dem DokumentD1 mit umfasst, so dass die Fachperson die Lehre der D1 ohne Weiteres auf solche Mobilvorrichtungen angewandt hat. Insbesondere stützt sich das Verfahren gemäß Anspruch 1 des Streitpatents nicht auf besondere Eigenschaften mobiler Geräte und ist nicht auf bestimmte Arten von mobilen Geräte beschränkt. Aus der Lehre der D1 ergeben sich auch keine technischen Gründe, die gegen eine Anwendung in Mobilvorrichtungen im Sinne des Streitpatentssprechen (Merkmale 1.1, 1.5, 1.6, 1.7).

Die Gegenstände des auf ein Verfahren gerichteten Patentanspruchs 1 und des nebengeordneten, auf ein System zur Durchführung des Verfahrens gerichteten und auf Anspruch 1 rückbezogenen Patentanspruchs 9 beruhen daher jeweils ausgehend von Dokument D1 nicht auf einer erfinderischen Tätigkeit.

2.4 Die weiteren angegriffenen Patentansprüche in der Fassung nach Hauptantrag bedürfen keiner weiteren, isolierten Prüfung, weil die Beklagte das Streitpatent im Hauptantrag als geschlossenen Anspruchssatz versteht und das Streitpatent auch insoweit nur als Ganzes verteidigt; dies rechtfertigt, das Patent in der Fassung nach Hauptantrag im Umfang aller Ansprüche für nichtig zu erklären, nachdem sich der Gegenstand eines Patentanspruchs aus dem von der Patentinhaberin verteidigten Anspruchssatz als nicht patentfähig erweist (vgl. BGH, Urteil vom 13. September 2016 – X ZR 64/14, GRUR 2017, 57 – Datengenerator).

III. Zu den Hilfsanträgen 1, 2A und 2B

Die Beklagte kann das Streitpatent auch in den Fassungen der Hilfsanträge 1, 2A und 2B nicht erfolgreich verteidigen, da diesen jeweils zumindest der Nichtigkeitsgrund der fehlenden Patentfähigkeit entgegensteht, Art. II § 6 Abs.1 Nr. 1 IntPatÜG, Art. 138 Abs. 1 Buchst. a) EPÜ i. V. m. Art. 52, 56 EPÜ.

1. Hilfsantrag 1

Der Gegenstand des Patentanspruchs 1 nach Hilfsantrag 1(wortgleich in der mündlichen Verhandlung vom 27. Oktober 2023 und im Schriftsatz vom 18. September 2024 formuliert) beruht ausgehend von Dokument D1 (US 2010/0228991 A1) und dem Fachwissen der Fachperson nicht auf einer erfinderischen Tätigkeit.

1.1 Patentanspruch 1 nach Hilfsantrag 1 unterscheidet sich von Anspruch 1 der erteilten Fassung darin, dass Merkmal 1.2 – im Folgenden als Merkmal 1.2H1 bezeichnet –, wie hervorgehoben, ergänzt ist:

1.2 H1 storing an encrypted resource authorization, wherein the encrypted resource authorization is stored in the cloud and is retrieved from the cloud to the mobile device;

Im Streitpatent findet sich keine Definition des Begriffs „Cloud“. Die Formulierung in Absatz 0018 stellt einen Zusammenhang zwischen externer Cloud-Speicherung und lokaler Speicherung in der Mobilvorrichtung her (Abs. 0018: Credentials may be stored either on the mobile device or, remotely, in the cloud.). Im Absatz 0087 wird ein zum Prioritätszeitpunkt des Streitpatents bereits populärer Cloud-basierter Speicherdienst genannt, der für Privat- und Firmenkunden Speicherplatz bereitstellt (Abs. 0087: In practice, Hoverkey can support popular cloud services such as DropBox or may provide its own bespoke service for Hoverkey users.).

Zum Prioritätszeitpunkt des Streitpatents existierte unstreitig keine einheitliche Definition des Begriffs „Cloud“ in der Literatur. Vielmehr wurde der Begriff unterschiedlich verwendet, bspw. im Sinne eines Dienstes, aber auch hinsichtlich dafür geeigneter Hardware-Realisierungen, sowie für lokale (firmeninterne bzw. „private“) Cloud-Lösungen bis hin zu Cloud-Diensten im Internet.

Mangels Definition und einem nicht klar einzugrenzenden fachmännischen Verständnis ergibt sich eine entsprechend breite Auslegung des Begriffs, wodurch das Merkmal bei einer (externen) Speicherung in einem nicht weiter konkretisierten Netzwerk bzw. auf einem (aus Sicht der Mobilvorrichtung externen) Server bereits erfüllt ist. Insbesondere liest die Fachperson im Begriff „Cloud“ keine implizite Beschränkung auf eine Speicherung der Daten auf Servern mit, die vom Endnutzer über das Internet zu erreichen sind.

1.2 Die Änderungen in Merkmal 1.2 H1 des Hilfsantrags 1 sind der Figur 6 der ursprünglich eingereichten Unterlagen (Stammanmeldung WO 2014/083335 A2, im Verfahren als Dokument NK2) und entsprechend Figur 6 des Streitpatents (Anlage NK1) in Verbindung mit Abs. 0018 (NK1) bzw. S. 4, Z. 30 (NK2) („Credentials may be stored either on the mobile device or, remotely, in the cloud.“), zweifelsfrei und eindeutig als zur Erfindunggehörend zu entnehmen. Denn im Kontext der Gesamtoffenbarung ist für die Fachperson klar ersichtlich, dass sich die vorgenannte Textstelle auf alle zum Zugriff des Nutzers auf die Computerressource erforderlichen „Credentials“ bezieht und damit die „encrypted resource authorisation“ mit umfasst, deren Speicherort im Streitpatent sonst nicht näher spezifiziert ist.

Hinsichtlich der ursprünglich nur allgemein genannten Speicherung der verschlüsselten Ressourcenautorisierung konkretisiert der Hilfsantrag 1 in Merkmal 1.2H1 den Speicherort gegenüber der erteilten Fassung, die den Speicherort offenlässt. Damit stellt das geänderte Merkmal eine Beschränkung des Anspruchsgegenstands und keine Schutzbereichserweiterung dar.

1.3 Ausgehend vom vorstehend erläuterten Verständnis des Senats bzgl. der Verwendung des Begriffs „Cloud“ im Streitpatent erweist sich Anspruch 1 gemäß Hilfsantrag 1 für die Fachperson auch als ausführbar, da das geänderte Merkmal hinsichtlich der Speicherung der Ressourcenautorisierung in der „Cloud“ sich allenfalls als breitgefasst erweist und ganz allgemein als eine, aus Sicht der Mobilvorrichtung externe Speicherung in einem lokalen oder externen Netzwerk bzw. auf einem entsprechenden Server verstanden werden kann.

1.4 Der Gegenstand des Patentanspruchs 1 nach Hilfsantrag 1ist der Fachperson ausgehend von Dokument D1(US 2010/0228991 A1) und ihrem Fachwissen nahegelegt und beruht nicht auf einer erfinderischen Tätigkeit.

Die Lehre der D1 sieht unter anderem vor, dass Ressourcen einschließlich der verschlüsselten Nutzerautorisierung (Hidden Secret) auch extern von der Nutzervorrichtung auf einem Server vorliegen können (Abs. 0079 und Fig. 7: Linux Server; sowie Abs. 0081: …the password 42 that is stored on the server is called the User Hidden Secret 42 since although it is stored in the open on Server 40,it cannot be used to log into the Server without first being decrypted inside the User Token 1.).

Ungeachtet dessen, dass auch das Streitpatent zur Speicherung der verschlüsselten Nutzerautorisierung in der „Cloud“ keine näheren Angaben macht, steht der Vorwegnahme des Merkmals durch die D1 nicht entgegen, dass das Passwort nach dem Verständnis der Beklagten vermeintlich „offen“ auf dem Server liegt. Vielmehr wird diese Frage in der D1 ausdrücklich adressiert, wie die o. g. Fundstelle in Abs. 0081 zeigt: Bei dem gespeicherten Passwort handelt es sich um das „Hidden Secret“, das verschlüsselt gespeichert und nur mit Hilfe des Tokens zu entschlüsseln werden kann (vgl. Abs. 0081) und damit der verschlüsselten Ressourcenautorisierung (encrypted resource authorization) des Streitpatents entspricht. Unabhängig davon war auch die Vergabe und Überwachung von Zugriffsrechten für Server- bzw. Cloud-Zugriffe zum Anmeldezeitpunkt des Streitpatents fachüblich, was auch das Streitpatent voraussetzt, da es – außer den Angaben in Absatz 0081 zur Nutzung eines kommerziellen Cloud-Speicherdienstes – keine näheren Angaben zur Realisierung einer entsprechenden Speicherung der verschlüsselten Ressourcenautorisierung „in der Cloud“ macht.

Es ergibt sich zwangsläufig aus der weiteren Verwendung des „Hidden Secret“ im Token gemäß Dokument D1, dass das auf dem Server gespeicherte „Hidden Secret“ durch die Mobilvorrichtung (hier: allgemein durch den Computer) abgerufen wird, da der dortige Token nur über eine (direkte) USB-Verbindung mit dem Computer verbunden ist und damit außer über den Computer keine Möglichkeit des Abrufs vom Server bietet (vgl. u. a. Fig. 7).

Für die weiteren Merkmale des Anspruchs 1 nach Hilfsantrag 1 gelten die Ausführungen zur Anspruchsfassung nach Hauptantrag in gleicher Weise.

Der Gegenstand des Patentanspruchs 1 gemäß Hilfsantrag 1 ergibt sich daher für die Fachperson ausgehend von Dokument D1 in naheliegender Weise.

Die weiteren angegriffenen Patentansprüche in der Fassung nach Hilfsantrag 1 bedürfen keiner weiteren, isolierten Prüfung, weil die Beklagte Hilfsantrag 1 als geschlossenen Anspruchssatz versteht und das Streitpatent auch insoweit nur als Ganzes verteidigt; dies rechtfertigt, dem Patent in der Fassung nach Hilfsantrag 1 insgesamt den Schutz zu versagen, nachdem sich der Gegenstand eines Patentanspruchs aus dem von der Patentinhaberin verteidigten Anspruchssatz als nicht patentfähig erweist(vgl. BGH, Urteil vom 13. September 2016 – X ZR 64/14, GRUR 2017, 57 – Datengenerator).

2. Hilfsantrag 2A

Der Gegenstand des Patentanspruchs 1 nach Hilfsantrag 2A beruht ausgehend von Dokument D1 (US 2010/0228991 A1) und dem Fachwissen nicht auf einer erfinderischen Tätigkeit.

2.1 Patentanspruch 1 nach Hilfsantrag 2A unterscheidet sich von Anspruch 1 der Fassung nach Hilfsantrag 1 darin, dass sich die Computer-Ressource gemäß den Merkmalen 1.1 und 1.6 – im Folgenden als Merkmal 1.1H2Aund 1.6H2Abezeichnet – auf einem externen Server befindet. Darüber hinaus hat die Beklagte Anspruch 1 entsprechend der Alternativen des Merkmals 1.7 in zwei Ansprüche aufgespalten:

Patentanspruch 1 gemäß Hilfsantrag 2A lautet mit gegenüber Anspruch 1 der erteilten Fassung hervorgehoben Änderungen:

1.1 H2A A method of authenticating a user to access a computer resource on a remote server via a mobile device comprising: 1.2 H1 storing an encrypted resource authorization, wherein the encrypted resource authorization is stored in the cloud and is retrieved from the cloud to the mobile device; 1.3 transmitting the encrypted resource authorization to at least one separate portable security token device; 1.4 on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response; 1.5 securely transmitting the generated unlock response to the mobile device; and 1.6 H2A providing access via the mobile device to the computer resource on the remote server if the required unlock response is valid; 1.7 H2.1 wherein a user is required to authenticate on the mobile device or on the at least one separate portable security token device, and 1.8 the user authentication is validated on the at least one separate portable security token device before the unlock response is sent.

Patentanspruch 2 lautet gemäß Hilfsantrag 2A mit gegenüber Anspruch 1 der erteilten Fassung hervorgehobenen Änderungen:

2.1 A method of authenticating a user to access a computer resource via a mobile device comprising: 2.2 H1 storing an encrypted resource authorization, wherein the encrypted resource authorization is stored in the cloud and is retrieved from the cloud to the mobile device; 2.3 transmitting the encrypted resource authorization to at least one separate portable security token device; 2.4 on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response; 2.5 securely transmitting the generated unlock response to the mobile device; and 2.6 providing access via the mobile device to the computer resource if the required unlock response is valid; 2.7 H2.2 wherein a user is required to authenticate on the mobile device or on the at least one separate portable security token device, and 2.8 the user authentication is validated on the at least one separate portable security token device before the unlock response is sent.

2.2 Die ursprüngliche, in der Anmeldung enthaltene Figur 6 (Bezeichnung der „App“ als „Web App“) offenbart zwar entgegen dem Verständnis der Beklagten für sich genommen nicht eindeutig, dass der dargestellte Passwort-Abruf den Nutzerzugriff auf diese Anwendung (App) auf einem externen Server selbst ermöglichen soll und nicht einen Ressourcenzugriff mittels dieser App beschreibt, auch wenn einleitend zum Ausführungsbeispiel auf Anwendungen als Ressourcen auf einem „application server“ verwiesen wird (S. 15, Z. 6).Allerdings erkennt die Fachperson bei einem Ressourcenzugriff, ausgehend von einer Anwendung (App) auf einem externen Server, d. h. dem Datenzugriff durch diese App, dass sich auch die entsprechende Ressource (d. h. die Daten) nicht auf der Mobilvorrichtung, sondern ebenfalls auf dem externen Server befindet.

Daher ist die Einschränkung des Speicherorts auf „on the remote server“ in Merkmal 1.1H2A und 1.6H2A für die Ressource, auf die zugegriffen werden soll, als ursprungsoffenbart anzusehen.

2.3 Die Aufspaltung des in der erteilten Anspruchsfassung mit dem als eigenständiger Alternative formulierten Merkmal 1.7 – Authentifizierung auf der Mobilvorrichtung oder („or“) auf dem Sicherheitstoken – in zwei nebengeordnete Patentansprüche ist zulässig, da hierdurch kein neuer, in der erteilten Anspruchsfassung von Anspruch 1 nicht umfasster Gegenstand geschaffen wird, insbesondere da entsprechend der Alternativen des Merkmals 1.7 in der erteilten Fassung keine Verknüpfung der beiden so entstandenen unabhängigen Ansprüche 1 und 2 besteht (d. h. eine „und“-Verknüpfung ist weder in der aufgespaltenen noch in der erteilten Fassung umfasst).

Darüber hinaus sind die Patentansprüche 1 und 2 gemäß Hilfsantrag 2A gegenüber beiden Alternativen der erteilten Fassung beschränkt (Merkmale 1.1H2A, 1.6H2A und 1.2H1 sowie 2.2H1).

Schließlich führt auch die unterschiedliche Beschränkung der beiden neu geschaffenen unabhängigen Ansprüche nicht zur Unzulässigkeit der Patentansprüche 1 und 2 gemäß Hilfsantrag 2A, da dies auch ausgehend von den Alternativen der erteilten Fassung in einem einzigen Anspruch möglich wäre.

2.4 Der Gegenstand des Patentanspruchs 1 nach Hilfsantrag 2A ist der Fachperson ausgehend von Dokument D1(US 2010/0228991 A1) und ihrem Fachwissen nahegelegt und beruht nicht auf einer erfinderischen Tätigkeit.

Denn die Lehre der D1 sieht unter anderem vor, dass Ressourcen auch extern von der Nutzervorrichtung auf einem Server vorliegen können (Abs. 0079 und Fig. 7: Linux Server).

Hierbei stellt – wie einleitend zur Patentfähigkeit des Anspruchs 1 nach Hauptantrag näher erläutert– bereits ein aus Dokument D1 bekanntes Nutzerkonto, bspw. auf einem externen Server wie dem Linux Server in der Ausführungsform nach Figur 7, eine Computer-Ressource im Sinne des Streitpatents dar.

Darüber hinaus verlangt Patentanspruch 1 nur das Ermöglichen des Zugriffs auf die genannte gespeicherte Ressource (Merkmal 1.6H2A: providing access via the mobile device to the computer resource on the remote server…), so dass von Anspruch 1 gemäß Hilfsantrag 2A auch umfasst ist, dass ein Zugriff auf die einzelnen Ressourcen in einem externen Speicher aufgrund der Zugriffsberechtigung (in Form der „Entsperrantwort“) für diesen Speicher bzw. für ein Verzeichnis in diesem Speichergewährt wird – d. h. aufgrund der Berechtigungen für das genannte Nutzerkonto. Die geänderten Merkmale 1.1 H2A und 1.6 H2A ergeben sich somit aus Dokument D1.

Für die weiteren Merkmale des Anspruchs 1 nach Hilfsantrag 2A gelten die Ausführungen zur Anspruchsfassung nach Hilfsantrag 1 in gleicher Weise.

Patentanspruch 1 gemäß Hilfsantrag 2 ist daher der Fachperson ausgehend von Dokument D1 nahegelegt.

Die weiteren angegriffenen Patentansprüche in der Fassung nach Hilfsantrag 2A bedürfen keiner weiteren, isolierten Prüfung, weil die Beklagte Hilfsantrag 2A als geschlossenen Anspruchssatz versteht und das Streitpatent auch insoweit nur als Ganzes verteidigt; dies rechtfertigt, dem Patent in der Fassung nach Hilfsantrag 1 insgesamt den Schutz zu versagen, nachdem sich der Gegenstand eines Patentanspruchs aus dem von der Patentinhaberin verteidigten Anspruchssatz als nicht patentfähig erweist(vgl. BGH, Urteil vom 13. September 2016 – X ZR 64/14, GRUR 2017, 57 – Datengenerator).

3. Hilfsantrag 2B

Der Gegenstand des Patentanspruchs 1 nach Hilfsantrag 2B beruht ausgehend von Dokument D1 (US 2010/0228991 A1) und dem Fachwissen der Fachperson nicht auf einer erfinderischen Tätigkeit.

3.1 Patentanspruch 1 nach Hilfsantrag 2B unterscheidet sich von Anspruch 1 der Fassung nach Hilfsantrag 1 darin, dass es sich bei der Computer-Ressource gemäß den Merkmalen 1.1 und 1.6 – im Folgenden als Merkmal 1.1H2B und 1.6H2B bezeichnet – um eine Anwendung (application) handelt, die sich auf einem externen Server befindet.

Wie bereits in Hilfsantrag 2A wurde Anspruch 1 auch gemäß Hilfsantrag 2B entsprechend der Alternativen des Merkmals 1.7 der erteilten Fassung in zwei Ansprüche aufgespalten.

Patentanspruch 1 gemäß Hilfsantrag 2B lautet mit gegenüber Anspruch 1 der erteilten Fassung hervorgehoben Änderungen:

1.1 H2B A method of authenticating a user to access an application a computer resource on a remote server via a mobile device comprising: 1.2 H1 storing an encrypted resource authorization, wherein the encrypted resource authorization is stored in the cloud and is retrieved from the cloud to the mobile device; 1.3 transmitting the encrypted resource authorization to at least one separate portable security token device; 1.4 on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response; 1.5 securely transmitting the generated unlock response to the mobile device; and 1.6 H2B providing access via the mobile device to the application computer resource on the remote server if the required unlock response is valid; 1.7 H2.1 wherein a user is required to authenticate on the mobile device or on the at least one separate portable security token device, and 1.8 the user authentication is validated on the at least one separate portable security token device before the unlock response is sent.

Patentanspruch 2 gemäß Hilfsantrag 2B entspricht der Anspruchsfassung nach Hilfsantrag 2A.

3.2 Die Änderungen der Merkmale 1.1H2B und 1.6H2Bsindzwar nicht an einer konkreten Stelle der ursprünglichen Anmeldeunterlagen unmittelbar offenbart. Die Fachperson versteht jedoch die Offenbarung der ursprünglichen Anmeldung und des Streitpatents dahingehend, dass die Erfindung für die Autorisierung zum Zugriff auf jegliche Art von Computerressourcen geeignet sein soll und zwar unabhängig von ihrem Speicherort, da das Streitpatent keine technischen Besonderheiten der Ressourcenautorisierung für bestimmte Arten von Ressourcen oder deren Speicherung voraussetzt. Die Verwendung der verschlüsselten Ressourcenautorisierung ist auch unabhängig davon, dass im Ausführungsbeispiel „Hoverkey“ weitere Parameter (bspw. AppID) zum Zugriff auf (externe) Ressourcen erforderlich sind und ggf. geprüft werden.Gestützt wird dieses Verständnis durch Unterscheidung zwischen „Web App“ und „Native App“ im Ausführungsbeispiel nach Figur 6, die ebenfalls auf eine mögliche externe (Cloud-)Speicherung (d. h. „remotely“ gemäß Abs. 0018 des Streitpatents (NK1) bzw. S. 4, Z. 30 der Stammanmeldung (NK2)) hinweist.

Die gemäß Hilfsantrag 2B geänderten Merkmale 1.1H2B und 1.6H2B erweisen sich daher als ursprungsoffenbart.

3.3 Wie zu Hilfsantrag 2A dargelegt, ist die Aufspaltung des Merkmals 1.7 der erteilten Anspruchsfassung (Authentifizierung auf der Mobilvorrichtung oder („or“) auf dem Sicherheitstoken)in zwei nebengeordnete Patentansprüche zulässig.

3.4 Der Gegenstand des Patentanspruchs 1 nach Hilfsantrag 2B ist der Fachperson ausgehend von Dokument D1(US 2010/0228991 A1) und ihrem Fachwissen nahegelegt und beruht nicht auf einer erfinderischen Tätigkeit.

Die Lehre der D1 sieht unter anderem vor, dass Ressourcen auch extern von der Nutzervorrichtung auf einem Server vorliegen können (Abs. 0079 und Fig. 7: Linux Server).

Dem Naheliegen steht auch nicht entgegen, dass die Lehre der D1 sich nur mit der Zugriffsberechtigung auf ein Nutzerkonto näher befasst, da dies fachüblich umfasst, dass dadurch der Zugriff auf alle damit verbundenen Ressourcen – mithin auch auf Anwendungen, die fachüblich zumindest teilweise auf einem Server gespeichert sind – für den Nutzer ermöglicht wird. Denn Patentanspruch 1 verlangt nur das Gewähren des Zugriffs auf die anspruchsgemäß auf dem Server gespeicherte Ressource (Merkmal 1.6H2A: providing access via the mobile device to the computer resource on the remote server…), nicht aber, dass jede der einzelnen Ressourcen(hier: Anwendungen / Apps)separat durch ein eigenes Passwort geschützt sind oder einen eigenen Schlüssel erfordern. Damit ist in Anspruch 1 nach Hilfsantrag 2B aber auch umfasst, dass der Zugriff auf eine auf dem Server für dieses Nutzerkonto gespeicherte Ressource aufgrund der Zugriffsberechtigung (Entsperrantwort) für das Nutzerkontogewährt wird. Die geänderten Merkmale 1.1 H2B und 1.6 H2B ergeben sich somit aus Dokument D1.

Für die weiteren Merkmale des Gegenstands des Anspruchs 1 nach Hilfsantrag 2B gelten die Ausführungen zur Anspruchsfassung nach Hilfsantrag 1 in gleicher Weise.

Patentanspruch 1 gemäß Hilfsantrag 2B ist daher der Fachperson ebenfalls ausgehend von Dokument D1 nahegelegt.

Die weiteren angegriffenen Patentansprüche in der Fassung nach Hilfsantrag 2B bedürfen keiner weiteren, isolierten Prüfung, weil die Beklagte Hilfsantrag 2B als geschlossenen Anspruchssatz versteht und das Streitpatent auch insoweit nur als Ganzes verteidigt; dies rechtfertigt, dem Patent in der Fassung nach Hilfsantrag 1 insgesamt den Schutz zu versagen, nachdem sich der Gegenstand eines Patentanspruchs aus dem von der Patentinhaberin verteidigten Anspruchssatz als nicht patentfähig erweist(vgl. BGH, Urteil vom 13. September 2016 – X ZR 64/14, GRUR 2017, 57 – Datengenerator).

IV. Zu den Hilfsanträgen3A bis 3Eb

Die Beklagte kann das Streitpatent auch in den Fassungen der Hilfsanträge 3A bis 3E, 3Ea und 3Eb nicht erfolgreich verteidigen, da deren Gegenstand über den Inhalt der Anmeldung in der ursprünglich eingereichten Fassung hinausgeht, Art. II § 6 Abs. 1 Nr. 3 IntPatÜG, Art. 138 Abs. 1 Buchst. c) EPÜ i. V. m. Art. 123 Abs. 2 EPÜ.

1. Zum Hilfsantrag 3A

Der Gegenstand des Patentanspruchs 1 nach Hilfsantrag 3A geht über den Inhalt der Anmeldung in der ursprünglich eingereichten Fassung hinaus. Hilfsantrag 3A erweist sich daher als nicht zulässig.

1.1 Patentanspruch 1 nach Hilfsantrag 3Abasiert auf Anspruch 1 gemäß Hilfsantrag 2A, wobei Merkmal 1.4 – im Folgenden als Merkmal 1.4H3A bezeichnet – dahingehend ergänzt ist, dass es sich beim Erzeugen der Entsperrantwort um eine Berechnung auf Basis der entschlüsselten Ressourcenautorisierung und weiteren Informationen handelt, wobei die Berechnung eine digitale Signaturfunktion ist.

Patentanspruch 1 lautet gemäß Hilfsantrag 3A mit gegenüber Anspruch 1 gemäß erteilter Fassung hervorgehoben Änderungen:

1.1 H2A A method of authenticating a user to access a computer resource on a remote server via a mobile device comprising: 1.2 H1 storing an encrypted resource authorization, wherein the encrypted resource authorization is stored in the cloud and is retrieved from the cloud to the mobile device; 1.3 transmitting the encrypted resource authorization to at least one separate portable security token device; 1.4 H3A on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response, wherein generating the unlock response comprises performing a computation on a plain authorization, obtained by decrypting the encrypted resource authorization, and additional information, wherein the computation is a digital signature function; 1.5 securely transmitting the generated unlock response to the mobile device; and 1.6 H2A providing access via the mobile device to the computer resource on the remote server if the required unlock response is valid; 1.7 H2.1 wherein a user is required to authenticate on the mobile device or on the at least one separate portable security token device, and 1.8 the user authentication is validated on the at least one separate portable security token device before the unlock response is sent.

Wie bereits in Hilfsantrag 2A hat die Beklagte Anspruch 1 auch gemäß Hilfsantrag 3A entsprechend den Alternativen des Merkmals 1.7 der erteilten Fassung in zwei Ansprüche aufgespalten.

Patentanspruch 2 gemäß Hilfsantrag 3A entspricht der Anspruchsfassung nach Hilfsantrag 2A.

1.2 Auch wenn die Aufspaltung des Merkmals 1.7 der erteilten Anspruchsfassung (Authentifizierung auf der Mobilvorrichtung oder („or“) auf dem Sicherheitstoken) in zwei nebengeordnete Patentansprüche – wie oben bereits ausgeführt – zulässig ist, ist der Gegenstand von Patentanspruch 1 gemäß Hilfsantrag 3A der Stammanmeldung (Dokument NK2) nicht zweifelsfrei und eindeutig zu entnehmen und damit nicht ursprungsoffenbart i. S. v. Art. II § 6 Abs. 1 Nr. 3 IntPatÜG, Art. 138 Abs. 1 Buchst. c) EPÜ.

Anspruch 1 gemäß Hilfsantrag 3A ist gegenüber der Ursprungsoffenbarung der Stammanmeldung (Dokument NK2)in unzulässiger Weise zwischenverallgemeinert.

Anspruch 3 der Stammanmeldung spricht allgemein davon, dass die Entsperrantwort eine Funktion der „einfachen“ oder „reinen“ Ressourcenautorisierung ist, die durch Entschlüsseln der verschlüsselten Ressourcenautorisierung erhalten wurde und weitere Informationenumfasst (Anspruch 3: A method as claimed in claim 1 in which the unlock response comprises a function of a plain authorization, obtained by decrypting the encrypted authorization, and additional information.). Eine digitale Signaturfunktion ist im ursprünglichen Anspruch 3 nicht genannt, vielmehr lässt dieser Anspruch offen, ob „function“ eine mathematische bzw. logische Funktion bezeichnet oder nur allgemein die Abhängigkeit der Entsperrantwort von der „plain authorization“ und den „additional information“ beschreibt.

Die „digitale Signaturfunktion“ gemäß Merkmal 1.4H3A wird in der gesamten Stammanmeldung nur als eines von drei Beispielen auf Seite 5, Zeile 31 bis Seite 6, Zeile 16 erwähnt(entsprechend Absatz 0026 des Streitpatents) und nur in diesem Kontext als „digitale Signaturfunktion“ bezeichnet: „The unlock response may alternatively comprise a function (such as a hash) of a plain authorization, obtained by decrypting the encrypted authorization, and additional information. Thus, in one usage mode, the token may verify and decrypt the encrypted authorization. Then, instead of returning a plain authorization to the device, protected by a session or other encryption key, the token may perform some computation on the plain authorization and possibly some other information (eg token-based information), and return the result to the device. Examples include the following:

•Example 1: Digital Signature: computation = digital signature function, plain authorization = private signing key; parameter = hash of message; output = digital signature on message hash

•Example 2: Key Derivation: computation = key derivation function; plain authorization = key derivation master secret; parameters = context information, output length; output = key derived from master secret

•Example 3: Re-encryption: computation = encryption function; plain authorization = encryption key; parameter = (another) encryption key; output = the plain authorization encrypted with a different key”

Von diesem Beispiel „Example 1“ ist in Merkmal 1.4H3Anur das Teilmerkmal übernommen, dass die Berechnung die Anwendung der digitalen Signaturfunktion ist (computation = digital signature function). Diese digitale Signaturfunktion ist aber nur in Verbindung mit den weiteren Angaben ursprungsoffenbart, wonach die entschlüsselte Ressourcenautorisierung ein privater Signaturschlüssel (plain authorization = private signing key) der digitalen Signaturfunktion ist und ein Parameter der digitalen Signaturfunktion der „Hash“-Wert der Nachricht ist (parameter = hash of message). Dabei bleibt offen, ob die Nachricht nur durch die weiteren Informationen oder beispielsweise durch die entschlüsselte Ressourcenautorisierung und die weiteren Informationen gebildet wird. Das Ergebnis, mithin die Entsperrantwort, ist gemäß „Example 1“ die auf den Hash-Wert der Nachricht angewandte digitale Signatur (output = digital signature on message hash), also der mit dem privaten Schlüssel signierte Hash-Wert. Schlüssel, Parameter und Nachricht sind somit bezüglich der Verwendung einer digitalen Signaturfunktion nicht voneinander unabhängig offenbart.

Bei Merkmal 1.4H3A des Patentanspruchs 1 gemäß Hilfsantrag 3A handelt es sich daher um eine unzulässige Zwischenverallgemeinerung, da die oben wiedergegebene einzige Beschreibung einer „digitalen Signaturfunktion“ in der Stammanmeldung Vorgaben dazu macht, wie und worauf die digitale Signatur angewandt wird, nämlich durch Verwenden der reinen Ressourcenautorisierung als privater Schlüssel der digitalen Signaturfunktion, die auf dem Hash-Wert einer Nachricht gebildet wird. Auch wenn die Stammanmeldung das „Example 1“ nur als Beispiel bezeichnet, das sich mit den weiteren Beispielen unter der allgemeinen Lehre des Anspruchs 3 der Stammanmeldung subsumieren lässt, findet sich im „Example 1“ die einzige ursprüngliche Offenbarungsstelle für die explizite Verwendung einer„digitalen Signaturfunktion“, denn die weiteren Beispiele zur Verwendung des Tokens betreffen nicht etwa alternative Verwendungen der digitalen Signaturfunktion (computation = digital signature function), sondern die Ableitung eines Schlüssels (computation = key derivation) und Wiederverschlüsselung (computation = re-encryption) sowie das im Absatz zuvor genannte direkte Verwenden der reinen oder einfachen entschlüsselten Ressourcenautorisierung (Seite 5, Zeile 28-30: plain authorization).

Zwar könnte es sich auch bei einer „Wiederverschlüsselung“, wie sie „Example 3“ beschreibt, um ein Signieren handeln. Dieses Signieren wird jedoch nicht als digitale Signaturfunktion bezeichnet.Hierbei dient die Bezeichnung „digital signature function“ auch insoweit der Abgrenzung zwischen den Beispielen, in dem „Example 3“ allenfalls ein Signieren (bspw. im Sinne der Verwendung von sog. „Session Keys“)der „plain authorization“ umfasst und „Example 1“ dagegen die Verwendung der „plain authorization“ als Signaturschlüssel vorsieht. Ungeachtet dessen wären auch die Merkmale des „Example 3“ nur unvollständig in den Anspruch 1 gemäß Hilfsantrag 3A übernommen.

Patentanspruch 1 gemäß Hilfsantrag 3A erweist sich damit als nicht zulässig.

Ob die Änderungen nach Hilfsantrag 3A darüber hinaus so ausreichend deutlich und knapp gefasst sind, dass sie entgegen der Ansicht der Klägerinnen dem Klarheitserfordernis des § 84 EPÜ genügen und patentfähig wären, kann daher dahinstehen.

2. Hilfsantrag 3B

Auch der Gegenstand des Patentanspruchs 1 nach Hilfsantrag 3B geht über den Inhalt der Anmeldung in der ursprünglich eingereichten Fassung hinaus. Hilfsantrag 3B erweist sich daher ebenfalls als nicht zulässig.

2.1 Patentanspruch 1 nach Hilfsantrag 3Bbasiert auf Anspruch 1 gemäß Hilfsantrag 1, wobei Merkmal 1.4H3Aaus Hilfsantrag 3A in den Anspruch 1 gemäß Hilfsantrag 3B aufgenommen und die Alternativen des Merkmals 1.7 wie auch in Hilfsantrag 3A in zwei Patentansprüche 1 und 2 aufgespalten wurden.

Patentanspruch 1 lautet gemäß Hilfsantrag 3B mit gegenüber Anspruch 1 gemäß erteilter Fassung hervorgehoben Änderungen:

1.1 A method of authenticating a user to access a computer resource via a mobile device comprising: 1.2 H1 storing an encrypted resource authorization, wherein the encrypted resource authorization is stored in the cloud and is retrieved from the cloud to the mobile device; 1.3 transmitting the encrypted resource authorization to at least one separate portable security token device; 1.4 H3A on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response, wherein generating the unlock response comprises performing a computation on a plain authorization, obtained by decrypting the encrypted resource authorization, and additional information, wherein the computation is a digital signature function; 1.5 securely transmitting the generated unlock response to the mobile device; and 1.6 providing access via the mobile device to the computer resource if the required unlock response is valid; 1.7 H2.1 wherein a user is required to authenticate on the mobile device or on the at least one separate portable security token device, and 1.8 the user authentication is validated on the at least one separate portable security token device before the unlock response is sent.

Patentanspruch 1 nach Hilfsantrag 3B ist damit weiter gefasst als Anspruch 1 des Hilfsantrags 3A, da die Einschränkungen in den Merkmalen1.1H2A und 1.6H2A fehlen.

Wie bereits in Hilfsantrag 2A hat die Beklagte Anspruch 1 gemäß Hilfsantrag 3B auch hier entsprechend den Alternativen des Merkmals 1.7 der erteilten Fassung in zwei Ansprüche aufgespalten.

Patentanspruch 2 gemäß Hilfsantrag 3B entspricht der Anspruchsfassung nach Hilfsantrag 2A.

2.2 Der Gegenstand des Patentanspruchs 1 gemäß Hilfsantrag 3B ergibt sich nicht zweifelsfrei und eindeutig aus der Stammanmeldung des Streitpatents.

Anspruch 1 gemäß Hilfsantrag 3B weist – wie bereits gemäß Hilfsantrag 3A – das Merkmal 1.4H3A in unveränderter Form und ohne weitere Ergänzungen auf. Es gelten daher zu Anspruch 1 gemäß Hilfsantrag 3B die Ausführungen zur fehlenden Ursprungsoffenbarung des Merkmals 1.4H3Azu Hilfsantrag 3A in gleicher Weise: Wie bereits zu Hilfsantrag 3A ausgeführt, handelt es sich bei Merkmal 1.4H3A des Patentanspruchs 1 gemäß Hilfsantrag 3B um eine unzulässige Zwischenverallgemeinerung hinsichtlich der einzigen Beschreibung einer digitalen Signaturfunktion in der Stammanmeldung (Seite 6, Zeilen 6 bis 8: „Example 1“).

Ob die Änderungen nach Hilfsantrag 3B darüber hinaus so ausreichend deutlich und knapp gefasst sind, dass sie dem Klarheitserfordernis des § 84 EPÜ genügen und sich als patentfähig erweisen würden, kann daher dahinstehen.

3. Hilfsantrag 3C

Der Gegenstand des Patentanspruchs 1 nach Hilfsantrag 3C geht über den Inhalt der Anmeldung in der ursprünglich eingereichten Fassung hinaus. Hilfsantrag 3C erweist sich daher als nicht zulässig.

3.1 Patentanspruch 1 nach Hilfsantrag 3Cbasiert auf Anspruch 1 gemäß Hauptantrag, wobei Merkmal 1.4 – wie bereits in Hilfsantrag 3A – dahingehend ergänzt ist, dass es sich beim Erzeugen der Entsperrantwort um eine Berechnung auf Basis der entschlüsselten Ressourcenautorisierung und weiteren Informationen handelt, wobei die Berechnung eine digitale Signaturfunktion ist.

Patentanspruch 1 lautet gemäß Hilfsantrag 3Cmit gegenüber Anspruch 1 gemäß erteilter Fassung hervorgehoben Änderungen:

1.1 A method of authenticating a user to access a computer resource via a mobile device comprising: 1.2 storing an encrypted resource authorization; 1.3 transmitting the encrypted resource authorization to at least one separate portable security token device; 1.4 H3A on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response, wherein generating the unlock response comprises performing a computation on a plain authorization, obtained by decrypting the encrypted resource authorization, and additional information, wherein the computation is a digital signature function; 1.5 securely transmitting the generated unlock response to the mobile device; and 1.6 providing access via the mobile device to the computer resource if the required unlock response is valid; 1.7 H2.1 wherein a user is required to authenticate on the mobile device or on the at least one separate portable security token device, and 1.8 the user authentication is validated on the at least one separate portable security token device before the unlock response is sent.

Patentanspruch 1 nach Hilfsantrag 3C ist damit weiter gefasst als der jeweilige Anspruch 1 der Hilfsanträge 3A oder 3B, da die Einschränkungen in Merkmal 1.1H2A, 1.6H2Aund 1.2H1fehlen.

Wie bereits in Hilfsantrag 2A hat die Beklagte Anspruch 1 auch gemäß Hilfsantrag 3C entsprechend der Alternativen des Merkmals 1.7 der erteilten Fassung in zwei Ansprüche aufgespalten.

Patentanspruch 2 gemäß Hilfsantrag 3C entspricht der Anspruchsfassung nach Hilfsantrag 2A.

3.2 Der Gegenstand des Patentanspruchs 1 gemäß Hilfsantrag 3C ergibt sich nicht zweifelsfrei und eindeutig aus der Stammanmeldung des Streitpatents.

Anspruch 1 gemäß Hilfsantrag 3C weist – wie bereits gemäß Hilfsantrag 3A – das Merkmal 1.4H3A in unveränderter Form und ohne weitere Ergänzungen auf. Es gelten daher zu Anspruch 1 gemäß Hilfsantrag 3C die Ausführungen zur fehlenden Ursprungsoffenbarung des Merkmals 1.4H3Azu Hilfsantrag 3A in gleicher Weise: Wie bereits zu Hilfsantrag 3A ausgeführt, handelt es sich bei Merkmal 1.4H3A des Patentanspruchs 1 gemäß Hilfsantrag 3C um eine Zwischenverallgemeinerung hinsichtlich der einzigen Beschreibung einer digitalen Signaturfunktion in der Stammanmeldung (Seite 6, Zeilen 6 bis 8: „Example 1“).

Ob die Änderungen nach Hilfsantrag 3C darüber hinaus so ausreichend deutlich und knapp gefasst sind, dass sie dem Klarheitserfordernis des § 84 EPÜ genügen und sich als patentfähig erweisen, kann daher dahinstehen.

4. Hilfsantrag 3D

Der Gegenstand des Patentanspruchs 1 nach Hilfsantrag 3D geht über den Inhalt der Anmeldung in der ursprünglich eingereichten Fassung hinaus. Hilfsantrag 3D erweist sich daher als nicht zulässig.

4.1 Patentanspruch 1 nach Hilfsantrag 3Dumfasst die erstmals in Hilfsantrag 3A verwendete Einschränkungen des Merkmals 1.4H3Asowie die Beschränkung des Speicherorts der Computerressource auf einem externen Server (Merkmale1.1H2A und 1.6H2A).

Im Unterschied zu den Hilfsanträgen 3A bis 3C umfasst Hilfsantrag 3D nicht die Aufspaltung der Alternativen des Merkmals 1.7 der erteilten Fassung in zwei Patentansprüche.

Patentanspruch 1 lautet gemäß Hilfsantrag 3Dmit gegenüber Anspruch 1 gemäß der erteilten Fassung hervorgehoben Änderungen:

1.1 H2A A method of authenticating a user to access a computer resource on a remote server via a mobile device comprising: 1.2 storing an encrypted resource authorization; 1.3 transmitting the encrypted resource authorization to at least one separate portable security token device; 1.4 H3A on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response, wherein generating the unlock response comprises performing a computation on a plain authorization, obtained by decrypting the encrypted resource authorization, and additional information, wherein the computation is a digital signature function; 1.5 securely transmitting the generated unlock response to the mobile device; and 1.6 H2A providing access via the mobile device to the computer resource on the remote server if the required unlock response is valid; 1.7 wherein a user is required to authenticate on the mobile device or on the at least one separate portable security token device, and 1.8 the user authentication is validated on the at least one separate portable security token device before the unlock response is sent.

4.2 Der Gegenstand des Patentanspruchs 1 gemäß Hilfsantrag 3D ergibt sich nicht zweifelsfrei und eindeutig aus der Stammanmeldung des Streitpatents.

Anspruch 1 gemäß Hilfsantrag 3D weist – wie bereits gemäß Hilfsantrag 3A – das Merkmal 1.4H3A in unveränderter Form und ohne weitere Ergänzungen auf. Es gelten daher zu Anspruch 1 gemäß Hilfsantrag 3D die Ausführungen zur fehlenden Ursprungsoffenbarung des Merkmals 1.4H3Azu Hilfsantrag 3A in gleicher Weise: Wie bereits zu Hilfsantrag 3A ausgeführt, handelt es sich bei Merkmal 1.4H3A des Patentanspruchs 1 gemäß Hilfsantrag 3D um eine Zwischenverallgemeinerung hinsichtlich der einzigen Beschreibung einer digitalen Signaturfunktion in der Stammanmeldung (Seite 6, Zeilen 6 bis 8: „Example 1“).

Ob der geänderte Anspruch 1 nach Hilfsantrag 3Dsich darüber hinaus als patentfähig erweisen würde, kann daher dahinstehen.

5. Hilfsantrag 3E

Der Gegenstand des Patentanspruchs 1 nach Hilfsantrag 3E geht über den Inhalt der Anmeldung in der ursprünglich eingereichten Fassung hinaus. Hilfsantrag 3E erweist sich daher als nicht zulässig.

5.1 Der von der Beklagten mit Schriftsatz vom 31. Januar 2025 und demnach binnen der zweiten auf den qualifizierten bzw. ergänzenden Hinweis vom 24. Juli 2024 eingeräumten bzw. verlängerten Frist eingereichte Hilfsantrag 3E war entgegen der Annahme und Rüge der Klägerinnen nicht gemäß § 83 Abs. 4 Satz 1 PatG als verspätet zurückzuweisen.

Hilfsantrag 3E war fristgemäß am Tag des Ablaufs der auf den qualifizierten Hinweis gesetzten bzw. verlängerten weiteren (zweiten) Frist zur Stellungnahme auf das Vorbringen der Gegenseite, am 31. Januar 2025,eingegangen.Für eine Zurückweisung wegen Verspätung fehlt es daher bereits an einem Versäumnis der im qualifizierten Hinweis gesetzten Frist (vgl. § 84 Abs. 4 Satz 1 PatG). Zudem haben sich die Klägerinnen mit Schriftsätzen vom 11. März 2025 und 1. April 2025 sowie in der mündlichen Verhandlung zu der Frage der unzulässigen Erweiterung eingelassen.

5.2 Patentanspruch 1 nach Hilfsantrag 3Eumfasst die Beschränkung des Speicherorts der Computerressource auf einem externen Server (Merkmale1.1H2A und 1.6H2A) sowie eine gegenüber Merkmal 1.4H3A der Hilfsanträge 3A bis 3D weitere Konkretisierung des Merkmals 1.4H3E.

Im Unterschied zu den Hilfsanträgen 3A bis 3C umfasst Hilfsantrag 3E nicht die Aufspaltung der Alternativen des Merkmals 1.7 der erteilten Fassung in zwei Ansprüche.

Patentanspruch 1 gemäß Hilfsantrag 3Eunterscheidet sich von Hilfsantrag 3D (neben der fehlenden Aufspaltung der Alternativen des Merkmals 1.7 in zwei Ansprüche)nur in folgendem hervorgehobenen Teilmerkmal:

1.4 H3E on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response, wherein generating the unlock response comprises performing a computation on a plain authorization, wherein the plain authorization is a private signing key obtained by decrypting the encrypted resource authorization, and additional information, wherein the computation is a digital signature function;

Unter dem in Merkmal 1.4H3E als „plain authorization“ genannten privaten Signaturschlüssel (private signature key) versteht die Fachperson einen geheimen Signaturschlüssel, der durch den Nutzer zum Erstellen digitaler Signaturen, also zum Signieren digitaler Daten verwendet wird und der beim Nutzer verbleibt. Ein zugehörigeröffentlicher Schlüssel wird verwendet, um die Signatur zu verifizieren (PKI, Public Key Infrastructure). Der private Signaturschlüssel (private signature key) ist daher – obwohl fachüblich oft als privater Schlüssel (private key) bezeichnet – in seiner Verwendung zu unterscheiden von dem privaten Schlüssel, der bei der asymmetrischen Verschlüsselung zum Entschlüsseln der mit einem öffentlichen Schlüssel verschlüsselten digitalen Daten dient, oder einem Schlüssel zur symmetrischen Verschlüsselung wie bspw. ein sog. Session-Key.

5.2 Anspruch 1 gemäß Hilfsantrag 3E ist der Stammanmeldung (Dokument NK2) nicht zweifelsfrei und eindeutig zu entnehmen.

Anspruch 1 gemäß Hilfsantrag 3E weist das gegenüber Merkmal 1.4H3Agemäß den Hilfsanträgen 3A bis 3Dweiter konkretisierte Merkmal 1.4H3E auf, wonach die „plain authorization“ ein privater Signaturschlüssel ist, der durch Entschlüsseln der verschlüsselten Ressourcenautorisierung gewonnen wird (…wherein the plain authorization is a private signing key obtained by decrypting the encrypted resource authorization…).

Auch wenn in der Fassung des Merkmals 1.4H3E nunmehr die Zuordnung des privaten Schlüssels zur entschlüsselten verschlüsselten Ressourcenautorisierung ergänzt wurde, handelt es sich bei Merkmal 1.4H3E des Patentanspruchs 1 gemäß Hilfsantrag 3Eweiterhin um eine unzulässige Zwischenverallgemeinerung, da die einzige Offenbarungsstelle einer „digitalen Signaturfunktion“ in der Stammanmeldung („Example 1“) die zusätzlichen Vorgaben enthält, dass die digitale Signatur bei einer Berechnung entsprechend einer digitalen Signaturfunktion auf den Hash-Wert einer Nachricht angewandt wird.

Schließlich beschreibt Merkmal 1.4H3E mit der Anwendung der „digitalen Signaturfunktion“ auch kein Anwenden einer (Hash-)Funktion einer „plain authorization“ entsprechend Seite 5, Zeilen 31-32 der Stammanmeldung (…a function (such as a hash) of a plain authorization, ...), sondern das Signieren von Daten.

Ob die Änderungen nach Hilfsantrag 3E sich darüber hinaus als patentfähig erweisen würden, kann daher dahinstehen.

6. Hilfsantrag 3Ea

Der Gegenstand des Patentanspruchs 1 nach Hilfsantrag 3Ea geht über den Inhalt der Anmeldung in der ursprünglich eingereichten Fassung hinaus. Hilfsantrag 3Ea erweist sich daher als nicht zulässig.

6.1 Der von der Beklagten in der mündlichen Verhandlung am 9. April 2025 eingereichte Hilfsantrag 3Ea war entgegen der Annahme und Rüge der Klägerinnen nicht gemäß § 83 Abs. 4 Satz 1 PatG als verspätet zurückzuweisen.

Die Regelung in § 83 PatG sieht grundsätzlich die Möglichkeit vor, verspätetes Vorbringen zurückzuweisen und bei der Entscheidung unberücksichtigt zulassen. Voraussetzung hierfür ist nach § 83 Abs. 4 PatG, dass das Vorbringen unter Versäumung der nach § 83 Abs. 2 PatG gesetzten Frist erfolgt, die betroffene Partei die Verspätung nicht genügend entschuldigt und die Berücksichtigung des neuen Vortrags eine Vertagung des Termins zur mündlichen Verhandlung erfordert hätte.

Der Hilfsantrag 3Ea ist zwar nach Ablauf der nach § 83 Abs. 2 PatG gesetzten Frist eingereicht worden.Die Beklagte hat die Verspätung jedoch zum einen im Hinblick auf die Erörterung in der mündlichen Verhandlung entschuldigt. In der neuen Fassung des Merkmals 1.4H3Eanach Hilfsantrag 3Ea sieht die Beklagte die Notwendigkeit, auf das erstmals in der mündlichen Verhandlungerkennbar gewordene Verständnis von der Zuordnung des privaten Schlüssels zur entschlüsselten Ressourcenautorisierung zu reagieren und mit der Aussage, dass diese nicht in der Entsperrantwort enthalten sein soll, zu begegnen. Zum anderen hat die Berücksichtigung des neuen Hilfsantrags keine Vertagung des Termins zur mündlichen Verhandlung erforderlich gemacht.

Der Gegenstand des Patentanspruchs 1 nach Hilfsantrag 3Ea, der auf Hilfsantrag 3E aufbaut, beseitigt dessen Mängel letztlich nicht und geht damit ebenfalls über den Inhalt der Anmeldung in der ursprünglich eingereichten Fassung hinaus. Dies konnte der Senat aus und nach dem bisherigen Vortrag der Parteien beurteilen. Vor diesem Hintergrund war es nicht erforderlich, den Klägerinnen die Gelegenheit zu einer weiteren Stellungnahme einzuräumen; demnach bestand auch kein Grund die mündliche Verhandlung zu vertagen.

6.2 Patentanspruch 1 nach Hilfsantrag 3Eaunterscheidet sich von Hilfsantrag 3E nur in folgendem hervorgehobenen Teilmerkmal:

1.4 H3Ea on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response, wherein generating the unlock response comprises performing a computation on a plain authorization, wherein the plain authorization is a private signing key obtained by decrypting the encrypted resource authorization, and additional information, wherein the computation is a digital signature function, and wherein the plain authorization is not included in the unlock response;

Anspruch 1 gemäß Hilfsantrag 3Ea weist gegenüber Anspruch 1 gemäß Hilfsantrag 3E das weiter konkretisierte Merkmal 1.4H3Ea auf, wonach die „plain authorization“ nicht in der Entsperrantwort enthalten sein soll (…and wherein the plain authorization is not included in the unlock response…).

Diese Aussage kann nur so verstanden werden, dass die „plain authorization“, die nach Merkmal 1.4H3Ea einen privaten Signaturschlüssel darstellt, weder im Klartext noch in (wieder-)verschlüsselter Form in der Entsperrantwort enthalten sein soll. Dies bedeutet, dass dieser private Schlüssel nicht entnehmbar – d. h. auslesbar oder decodierbar – in der Entsperrantwort enthalten sein soll, sondern allenfalls der Signatur der Entsperrantwort oder von Teilen der Entsperrantwort dient. Dies steht im Einklang damit, dass die „plain authorization“ im Sinne des Beispiels „Example 1“ (Streitpatent, Abs. 0026) als der private Schlüssel zu verstehen ist, der mittels einer „digitalen Signaturfunktion“ auf den Hash-Wert einer Nachricht angewandt wird.

6.3 Anspruch 1 gemäß Hilfsantrag 3Ea ist der Stammanmeldung (Dokument NK2) dennoch nicht zweifelsfrei und eindeutig zu entnehmen.

Anspruch 1 gemäß Hilfsantrag 3Ea weist ein gegenüber Anspruch 1 gemäß Hilfsantrag 3E weiter konkretisiertes Merkmal 1.4H3Ea auf, wonach die „plain authorization“ nicht in der Entsperrantwort enthalten sein soll (…and wherein the plain authorization is not included in the unlock response…).

Zwar ist in der Fassung des Merkmals 1.4H3Ea nunmehr die Zuordnung des privaten Schlüssels zur entschlüsselten Ressourcenautorisierung ergänzt um die Aussage, dass diese nicht in der Entsperrantwort enthalten sein soll. Aus der Ergänzung, wonach die „plain authorization“ nicht in der Entsperrantwort enthalten sein soll (…and wherein the plain authorization is not included in the unlock response…), geht jedoch nicht hervor, wie die Formulierung „computation on a plain authorization“ [Unterstreichung hinzugefügt] mit einer digitalen Signaturfunktion als „computation“ zu verstehen ist.

Selbst bei der Annahme, dass die „digitale Signaturfunktion“ die Verwendung der „plain authorization“ als „privaten Signaturschlüssel“ impliziert, geht aus Patentanspruch 1 nach Hilfsantrag 3Ea nicht hervor, was auf diese Weise signiert werden soll. Dagegen ist eine – als solche bezeichnete – „digitale Signaturfunktion“ in der Stammanmeldung ausschließlich zu „Example 1“ offenbart. Dieses Beispiel sieht jedoch keine Signatur eines beliebigen Parameters (im Sinne der „additional information“ des Anspruchsmerkmals) vor, sondern in Verbindung mit der Verwendung der „plain authorization“ als privatem Signaturschlüssel nur das Signieren eines Hash-Wertes einer Nachricht als Ergebnis der digitalen Signaturfunktion, so dass es sich bei Merkmal 1.4H3Ea um eine unzulässige Verallgemeinerung handelt.

Ob der geänderte Gegenstand des Anspruchs 1 nach Hilfsantrag 3Ea sich darüber hinaus als patentfähig erweisen würde, kann daher dahinstehen.

7. Hilfsantrag 3Eb

Der Gegenstand des Patentanspruchs 1 nach Hilfsantrag 3Eb geht über den Inhalt der Anmeldung in der ursprünglich eingereichten Fassung hinaus. Hilfsantrag 3Eb erweist sich daher als nicht zulässig.

7.1 Der von der Beklagten in der mündlichen Verhandlung am 9. April 2025 eingereichte Hilfsantrag 3Eb war entgegen der Annahme und Rüge der Klägerinnen nicht gemäß § 83 Abs. 4 Satz 1 PatG als verspätet zurückzuweisen. Insoweit wird auf die Ausführungen zu Hilfsantrag 3Ea Bezug genommen, die auch hier entsprechend gelten.

7.2 Patentanspruch 1 nach Hilfsantrag 3Ebumfasst gegenüber dem Hilfsantrag 3Ea eine weitere Konkretisierung des Merkmals 1.4H3Eb.

Patentanspruch 1 gemäß Hilfsantrag 3Ebunterscheidet sich von Hilfsantrag 3E in folgenden hervorgehobenen Teilmerkmalen:

1.4 H3Eb on the at least one separate portable security token device, decrypting and verifying the encrypted resource authorization and generating at least partially therefrom an unlock response, wherein generating the unlock response comprises performing a computation on a plain authorization, obtained by decrypting the encrypted resource authorization, and additional information including a hash of a message, wherein the computation is a digital signature function, and wherein the plain authorization is not included in the unlock response;

7.3 Anspruch 1 gemäß Hilfsantrag 3Eb ist der Stammanmeldung (Dokument NK2) nicht zweifelsfrei und eindeutig zu entnehmen.

Anspruch 1 gemäß Hilfsantrag 3Eb weist gegenüber Anspruch 1 gemäß Hilfsantrag 3E das weiter konkretisierte Merkmal 1.4H3Eb auf, wonach die „plain authorization“ nicht in der Entsperrantwort enthalten sein soll (…and wherein the plain authorization is not included in the unlock response…) und die Berechnung auf der „plain authorization“ und zusätzlichen Informationen erfolgt, die den Hash-Wert einer Nachricht umfassen (…performing a computation on a plain authorization, …, and additional information including a hash of a message). Die weitere einleitende Ergänzung bezüglich einer Überprüfung der verschlüsselten Ressourcenautorisierung entspricht Seite 5, Zeile 33 der Stammanmeldung (…the token may verify and decrypt the encrypted authorization.).

Zwar ist in der Fassung des Merkmals 1.4H3Eb nunmehr die Zuordnung des privaten Schlüssels zur entschlüsselten „verschlüsselten Ressourcenautorisierung“ ergänzt und die Aussage, dass diese nicht in der „Entsperrantwort“ enthalten sein soll. Selbst bei der Annahme, dass die „digitale Signaturfunktion“ die Verwendung der „plain authorization“ als einem privaten Signaturschlüssel impliziert, geht aus Patentanspruch 1 nach Hilfsantrag 3Eb jedoch nicht zweifelsfrei und eindeutig hervor, was auf diese Weise signiert werden soll. Denn Merkmal 1.4H3Eb spricht nur davon, dass die digitale Signaturfunktion auf die „plain authorization“ und die zusätzliche Information angewandt werden soll, wobei der in „Example 1“ als Parameter bezeichnete Hash-Wert einer Nachricht als eine zusätzliche Information (additional information) im Sinne des Merkmalswortlauts zu verstehen ist. Die einzige Offenbarungsstelle, die auf eine digitale Signaturfunktion und den Hash-Wert einer Nachricht Bezug nimmt (Stammanmeldung, S. 6, Zeilen 6 bis 8, Example 1), sieht jedoch nicht vor, dass eine Signaturfunktion nur irgendwie auf zusätzliche Informationen angewandt wird, die (auch) einen Hash-Wert einer Nachricht umfassen, sondern, dass das Ergebnis der Anwendung der digitalen Signaturfunktion die digitale Signatur „auf dem“ (bzw. des) Hash-Wert der Nachricht ist und die „plain authorization“ als privater Signaturschlüssel dient. Daher ist auch Merkmal 1.4H3Ebgegenüber der Ursprungsoffenbarung unzulässig verallgemeinert.

Ob der geänderte Gegenstand des Anspruchs 1 nach Hilfsantrag 3Eb sich darüber als patentfähig erweisen würde, kann daher dahinstehen.

V. Zu Hilfsantrag 3F

Der jeweilige Gegenstand der nebengeordneten Patentansprüche 1 und 7gemäß Hilfsantrag 3Fgeht nicht über den Inhalt der ursprünglichen Anmeldung hinaus, ist so deutlich und vollständig offenbart, dass die Fachperson ihn ausführen kann, und patentfähig. Keines der im Verfahren befindlichen Dokumente des Standes der Technik zeigt ein Verfahren mit allen Merkmalen des Patentanspruchs 1, das somit neu ist. Der jeweilige Gegenstand der nebengeordneten Patentansprüche 1 und 7 gemäß Hilfsantrag 3Fberuht auch auf einer erfinderischen Tätigkeit, denn aus keinem der im Verfahren befindlichen Dokumente ergibt sich ein Verfahren gemäß dem Patentanspruch 1 bzw. ein System gemäß dem Patentanspruch 7für die Fachperson in naheliegender Weise.

1. Soweit die Klägerinnen – zuletzt in der mündlichen Verhandlung– die Verspätung von Hilfsantrag 3F gerügt haben, u. a., weil „erst in der mündlichen Verhandlung das Verständnis der Beklagten hinsichtlich dieser Hilfsanträge deutlich geworden sei“, führt dies nicht zur Zurückweisung des Hilfsantrags als verspätet.

Auch der von der Beklagten erst mit Schriftsatz vom 31. Januar 2025 und demnach binnen der zweiten auf den qualifizierten Hinweis eingeräumten bzw. verlängerten Frist eingereichte Hilfsantrag 3Fwar entgegen der Annahme und Rüge der Klägerinnen nicht gemäß § 83 Abs. 4 Satz 1 PatG als verspätet zurückzuweisen.

Wie bereits zuvor ausgeführt, sieht § 83 PatG mit den in das Nichtigkeitsverfahren eingeführten Präklusionsregeln grundsätzlich die Möglichkeit vor, verspätetes Vorbringen – neue Angriffs- und Verteidigungsmittel, eine Klageänderung oder eine Verteidigung des Beklagten mit einer geänderten Fassung des Patents – zurückzuweisen und bei der Entscheidung unberücksichtigt zulassen. Voraussetzung hierfür ist nach § 83 Abs. 4 PatG, dass das Vorbringen unter Versäumung der nach § 83 Abs. 2 Satz 1 PatG gesetzten Frist erfolgt, die betroffene Partei die Verspätung nicht genügend entschuldigt und die Berücksichtigung des neuen Vortrags eine Vertagung des Termins zur mündlichen Verhandlung erfordert hätte. Hierfür ist es demnach stets erforderlich, dass dieser Vortrag tatsächliche oder rechtliche Fragen aufkommen lässt, die in der mündlichen Verhandlung nicht oder nur mit unverhältnismäßigem Aufwand zu klären sind (vgl. Begründung zum Entwurf eines Gesetzes zur Vereinfachung und Modernisierung des Patentrechts, BlPMZ 2009, 307, 315). Selbst für das nach Fristsetzung eingereichte Angriffs- und Verteidigungsmittel liegen die Voraussetzungen für eine Zurückweisung nach § 83 Abs. 4 PatG allerdings auch dann nicht vor, wenn das an sich verspätete Vorbringen noch ohne Weiteres in die mündliche Verhandlung einbezogen werden kann, ohne dass es zu einer Verfahrensverzögerung kommt(s. a. BPatG, Urteil vom 30. April 2024 – 7 Ni 3/23, juris Rn. 206; vgl. Keukenschrijver, Patentnichtigkeitsverfahren, 7. Aufl. 2021, Rn. 223 mit umfangreichen Nachweisen zur Rechtsprechung des BPatG in Rn. 125).

Der weitere Hilfsantrag 3F ist bereits fristgemäß am Tag des Ablaufs der auf den qualifizierten Hinweis gesetzten bzw. verlängerten weiteren (zweiten) Frist zur Stellungnahme auf das Vorbringen der Gegenseite, nämlich am 31. Januar 2025, eingegangen.

In Bezug auf den weiteren Hilfsantrag 3Fbestand auch kein Vertagungserfordernis. Die Klägerinnen hatten vorliegend noch bei Zugang des weiteren Hilfsantrags 3F mehr als zwei Monate vor der mündlichen Verhandlung nicht nur ausreichend Zeit zur Vorbereitung ihres Vorbringens in der mündlichen Verhandlung, sondern auch zur schriftsätzlich vollinhaltlichen Stellungnahme. Dies haben sie mit ihren diesbezüglichen ausführlichen Darlegungen in ihren Schriftsätzen vom 11. März2025 und 1. April 2025 auch getan und sich damit zudem in der Sache eingelassen.

Soweit die Klägerinnen geltend machen, erst in der mündlichen Verhandlung sei das Verständnis der Beklagten hinsichtlich des Hilfsantrags 3F deutlich geworden, ist dies für die Beurteilung nicht erheblich. Denn nach Auslegung und Verständnis des Senats ist auch hier nur der bereits zu den Hilfsanträgen 3A bis 3Czur Ursprungsoffenbarung genannte und von den Parteien bereits zuvor eingehend auch schriftsätzlich diskutierte Absatz 0026 des Streitpatents mit „Example 1“ maßgeblich.

2. Patentanspruch 1 nach Hilfsantrag 3Fumfasst eine Definition des Speicherorts der Computerressource auf einem externen Server (Merkmale1.1H2A und 1.6H2A) sowie eine weitere Konkretisierung des Merkmals 1.4H3F gegenüber der Fassung gemäß Hilfsantrag 3E.

Patentanspruch 1 gemäß Hilfsantrag 3Funterscheidet sich damit von Hilfsantrag 3E in folgendem hervorgehobenen Teilmerkmal:

1.4 H3F on the at least one separate portable security token device, decrypting the encrypted resource authorization and generating at least partially therefrom an unlock response, wherein generating the unlock response comprises performing a computation on a plain authorization, wherein the plain authorization is a private signing key obtained by decrypting the encrypted resource authorization, and additional information, wherein the computation is a digital signature function on a message hash;

Der dem Patentanspruch 1 nebengeordnete Patentanspruch 7 gemäß Hilfsantrag 3Fentspricht nach seinem Wortlaut mit dem Rückbezug auf Patentanspruch 1 der erteilten Fassung des auf Anspruch 1 rückbezogenen Anspruchs 9.

Im Kontext des Merkmals 1.4H3F versteht die Fachperson den privaten Signaturschlüssel (private signature key), der als „plain authorization“ durch Entschlüsselung der verschlüsselten Ressourcenautorisierung (encrypted resource authorization) gewonnen wird, als den Schlüssel für die Anwendung der digitalen Signaturfunktion auf den Hash-Wert einer Nachricht (wherein the computation is a digital signature function on a message hash).

3. Anspruch 1 gemäß Hilfsantrag 3F ist dem „Example 1“ der Stammanmeldung (Dokument NK2, Seite 6, Zeilen 6 bis 8) zu entnehmen.

In Merkmal 1.4H3Fist nunmehr klargestellt, dass die „plain authorization“ ein privater Signaturschlüssel ist und (gemäß der Ergänzung im letzten Teilmerkmal) die digitale Signaturfunktion auf den Hash-Wert einer Nachricht angewandt wird.Damit gibt Merkmal1.4H3Fdas „Example 1“ mit dem die drei Beispiele einleitenden Abschnitt (Seite 5, Z. 31 bis Seite 6, Zeile 8 der Stammanmeldung)inhaltlich vollständig wieder, da das Anwenden der digitalen Signaturfunktion auf den Hash-Wert einer Nachricht (Merkmal 1.4H3F: „the computation is a digital signature function on a message hash“) im Ergebnis die Signatur auf dem Hash-Wert ist (S. 6, Z. 6 – 8: „computation = digital signature function, …, parameter = hash of a message, output = digital signature on message hash“).

Die Einschränkung des Speicherorts gegenüber der erteilten Anspruchsfassung auf „on the remote server“ in Merkmal 1.1H2A und 1.6H2A für die Ressource, auf die zugegriffen werden soll, ist ebenfalls als ursprungsoffenbart anzusehen (vgl. Ausführungen zu Hilfsantrag 2A).

4. Der Gegenstand des Patentanspruchs 1 gemäß Hilfsantrag 3F erweist sich als hinreichend klar und für die Fachperson deutlich und vollständig ausführ- bzw. nacharbeitbar offenbart.

Bereits in der erteilten Fassung lässt Merkmal 1.4 des Streitpatents offen, in welcher Weise die Entsperrantwort (zumindest teilweise) auf Basis der entschlüsselten verschlüsselten Ressourcenautorisierung (plain authorization) generiert wird. Hierdurch erweist sich Merkmal 1.4 in der erteilten Fassung jedoch nicht als unklar (i. S. v. Art. 84 EPÜ), sondern ist nur weit gefasst. Mit umfasst ist bereits in der erteilten Fassung das „Example 1“ in Absatz 0026, auf welches Merkmal 1.4H3F in der Fassung des Hilfsantrags 3F nunmehr beschränkt ist.

Die zugrundeliegende Nachricht, auf deren Hash-Wert gemäß Hilfsantrag 3F die Signaturfunktion angewandt werden soll, bedarf keiner näheren Erläuterung und stellt die Fachperson nicht vor Schwierigkeiten, da für die Fachperson selbstverständlich ist, dass es auf den Inhalt der Nachricht nicht ankommt. Diese kann vielmehr im Rahmen des beanspruchten Verfahrens ohne Weiteres aus beliebigen anspruchsgemäßen „weiteren Informationen“oder bspw. auch auf Basis der Anfrage zur Autorisierung des Nutzers an den Token gebildet werden. Wesentlich für den Erfolg des Verfahrens ist nicht der Inhalt dieser Nachricht, sondern vielmehr die Signatur des Hash-Werts der Nachricht. Denn die Signatur des Hash-Wertes ermöglicht durch Verwendung eines zugehörigen öffentlichen Schlüssels das Authentifizieren des Nutzers (im Sinne von Merkmal 1.1H2A), während der Hash-Wert das Prüfen der Integrität der Nachricht(im Sinne der Gültigkeit der Entsperrantwort nach Merkmal 1.6H2A) ermöglicht. Dies ergibt sich für die Fachperson hinreichend klar und insbesondere nacharbeitbar aus der Beschreibung des „Example 1“ und der Zielsetzung des Streitpatents, eine Authentifizierung des Nutzers beim Zugriff auf eine Computerressource zu ermöglichen.

5. Der jeweilige Gegenstand der nebengeordneten Patentansprüche 1 und 7gemäß Hilfsantrag 3F erweist sich als neu gegenüber dem in Verfahren eingeführten Stand der Technik und ist der Fachperson durch den Stand der Technik auch nicht nahegelegt.

5.1 Der Gegenstand des Patentanspruchs 1 nach Hilfsantrag 3F unterscheidet sich von Dokument D1(US 2010/0228991 A1)– neben den zum Hauptantrag und den Hilfsanträgen 1 bis 2B abgehandelten Unterschieden, die der Fachperson ausgehend von Dokument D1 zumindest aufgrund ihres Fachwissens nahegelegt sind – insbesondere in der Anwendung einer digitalen Signaturfunktion (digital signature function) auf die entschlüsselte „verschlüsselte Ressourcenautorisierung“ (plain authorization) beim Erzeugen der Entsperrantwort (unlock response) im Token gemäß Merkmal 1.4H3F (…performing a computation on a plain authorization, obtained by decrypting the encrypted resource authorization, and … additional information, wherein the computation is a digital signature function …).

Dokument D1 betrifft das Bereitstellen einer Zwei-Faktor-Authentifizierung unter Verwendung einer Sicherheitstoken-Vorrichtung bei einem Zugriff auf Computer, Server oder Datenspeichergeräte und -einrichtungen, die ein Passwort erfordern (Abs. 0009: It is an object of the present invention to provide means of dual factor authentication that will allow a security token device to control access to an unlimited number of Secure Systems, which could be computers, servers, other data storage devices or facilities, each requiring a unique password, without the usual requirement for storing each password inside of the security token.). DokumentD1 befasst sich somit mit der sicheren Verwaltung und Verwendung von Passwörtern. Es findet sich in der D1 in diesem Zusammenhang kein Hinweis auf die Anwendung einer digitalen Signaturfunktion im Rahmen der Zwei-Faktor-Authentifizierung. Auch ergibt sich für die Fachperson ausgehend von der D1 keine Veranlassung, von einer Passwort-Verwaltung zur Verwendung von Signaturen zu wechseln.

Es besteht ausgehend von der D1 auch keine Veranlassung der Fachperson zur (zusätzlichen) Verwendung einer Signaturfunktion bei der Übertragung der Entsperrantwort vom Token zum Computer, da dieUSB-Verbindung von der Fachperson bereits als sichere Übertragung im Sinne des Streitpatents verstanden wird.

Selbst dann, wenn die Fachperson ausgehend von der D1 einen Anlass hätte, deren Lehre bspw. mit Dokument D15 zu kombinieren, würde allein die dortige Erwähnung, dass der beschriebene Cloud-Zugang mit Signaturen oder Passwörtern gesichert sein kann, nicht naheliegend dazu führen, eine digitale Signaturfunktion mit der im Token entschlüsseltenverschlüsselten Ressourcenautorisierung anzuwenden. Denn die D15 weist nur allgemein auf die Möglichkeit hin, an Stelle eines Schlüssels zum Ermöglichen des Zugriffs auf eine verschlüsselte (Cloud-)Ressource (nur) ein Passwort als Entsperrantwort zu verwenden (vgl. Dokument D15, S. 31, Abschnitt 4.3 Cryptographic Computations, erster Absatz), nicht aber, mit der an den Token übertragenen, vom Token entschlüsselten Ressourcenautorisierung (plain authorization) eine Berechnung in Form einer digitalen Signaturfunktion gemäß Hilfsantrag 3Fauf den Hash-Wert einer Nachricht anzuwenden, um damit eine Entsperrantwort für eine Ressource zu generieren.

Somit ergibt sich auch in Verbindung mit dem Fachwissen der Fachperson, wonach neben einem Passwort auch ein digitaler Schlüssel zur Autorisierung des Zugriffs auf eine Computerressource verwendet werden kann (belegt bspw. mit Dokument D15), der Gegenstand des Patentanspruchs 1 gemäß Hilfsantrag 3F nicht naheliegend ausgehend von Dokument D1.

Der Patentanspruch 1 gemäß Hilfsantrag 3F erweist sich daher als neu gegenüber Dokument D1 und ist der Fachperson ausgehend von Dokument D1 auch nicht nahegelegt.

5.2 Dokument D9 (Da-Zhi Sun et al., bezeichnet vom Senat als D9, nachdem es als Dokument D9 in das Verfahren 4 Ni 61/22 (EP) eingeführt worden ist und als Dokument D1im Verfahren 4 Ni 41/23 (EP) bezeichnet ist) ist bereits nicht zu entnehmen, dass eine Validierung des Passworts PW stattfindet und bei falschem Passwort keine Übertragung der Entsperrantwort vom Token an die Mobilvorrichtung gemäß dem Merkmal 1.8 erfolgt. Dokument D9 spricht nur davon, dass bei falschem Passwort ein falscher Wert des Schlüssels (root key) bestimmt wird, wodurch keine gültige Entsperrantwort (file key) erzeugt wird. Die Gültigkeit der Entsperrantwort (und damit implizit die Gültigkeit des Passworts) zeigt sich jedoch erst beim versuchten Zugriff auf die Computerressource.Die in der D9 für diesen Fall genannte nicht erfolgreiche Interaktion besagt gerade nicht, dass es bei einer falschen Passwort-Eingabe zu keiner Interaktion mit der Mobilvorrichtung kommt, sondern dass in diesem Fall keine der folgenden Interaktionen erfolgreich abgeschlossen werden kann (D9, S. 1787, rechte Spalte, Abschnitt B. Wearable token loss concern: …else the wearable token derives a wrong value and cannot successfully complete any following interaction with the mobile device [Unterstreichung hinzugefügt]).

Ungeachtet dessen befasst sich Dokument D9 nur mit der Schlüsselverwaltung für ein lokales verschlüsseltes Dateisystemeiner Mobilvorrichtung (Mobile device), bei der zur Entschlüsselung von verschlüsselten Dateischlüsseln (File keys encrypted by root key) ein Token (Wearable token) vorliegen sein muss, um wiederum die Dateien (cryptographic files) entschlüsseln zu können (vgl. S. 1787, Fig. 4Key management model; sowie Beschreibung, S. 1786, rechte Spalte bis S. 1787, Abschnitt C. Key Management Principle):

Darüber hinaus unterscheidet sich der Gegenstand des Patentanspruchs 1 nach Hilfsantrag 3F von Dokument D9 in der Anwendung einer digitalen Signaturfunktion (digital signature function) mit der entschlüsselten verschlüsselten Ressourcenautorisierung (plain authorization) beim Erzeugen der Entsperrantwort (unlock response) im Token auf den Hash-Wert einer Nachricht gemäß Merkmal 1.4H3F (…wherein generating the unlock response comprises performing a computation on a plain authorization, wherein the plain authorization is a private signing key obtained by decrypting the encrypted resource authorization, and additional information, wherein the computation is a digital signature function on a message hash).

Dokument D9 lehrt dagegen das Bereitstellen eines Schlüssels (Rootkey), mit dem Dateischlüssel verschlüsselt sind (Encrypted file key) und die nur unter Verwendung des auf einem tragbaren Token (Wearable token) bereitgestellten „Rootkey“ entschlüsselt werden können. Für ein Anwenden einer digitalen Signaturfunktion auf den Hash-Wert einer Nachricht unter Verwendung einer entschlüsselten verschlüsselten Ressourcenautorisierung gemäß Merkmal 1.4H3F – hier des entschlüsselten, mit dem „Root key“ verschlüsselten „Filekey“ – findet sich in Dokument D9 weder ein Hinweis, noch ist ein Anlass für die Fachperson hierzu ersichtlich. Auch führt die Kenntnis über die Anwendung von Dateischlüsseln nicht naheliegend zu einer Abwandlung der Lehre der D9, um an Stelle des Bereitstellens des entschlüsselten „Encrypted file key“ mittels eines separaten Tokens diesen Schlüssel zur Signatur des Hash-Werts einer Nachricht im Token heranzuziehen.

Daneben ist der D9 kein Ermöglichen des Zugriffs auf externe, auf einem Server befindliche Dateien im Sinne der Merkmale 1.1H2A und 1.6H2A zu entnehmen. Denn die Lehre der D9 zielt darauf ab, ein lokales Dateisystem eines mobilen Geräts, bspw. im Falle des Verlusts des Geräts, vor unberechtigtem Zugriff zu schützen, wobei der Zugriff auf die verschlüsselten Dateien nur mit einem mit dem „Root key“ verschlüsselten „File key“ möglich ist, der wiederum nur entschlüsselt werden kann, wenn auch der separate tragbare Token zur Entschlüsselung des jeweiligen Dateischlüssels vorliegt. Für ein Übertragen dieser Lehre auf eine Speicherung von Computerressourcen auf einem externen Server findet sich in Dokument D9 weder ein Hinweis, noch ist ein Anlass für die Fachperson hierzu ersichtlich.

Der Patentanspruch 1 gemäß Hilfsantrag 3F erweist sich daher als neu gegenüber Dokument D9 und ist der Fachperson ausgehend von Dokument D9 auch nicht nahegelegt.

5.3 Der Gegenstand des Patentanspruchs 1 nach Hilfsantrag 3F unterscheidet sich von Dokument D10(Corner et al) bzw. Dokument D11 (Nicholson et al)– wie auch von DokumentD9 – in der Anwendung einer digitalen Signaturfunktion (digital signature function) mit der entschlüsselten„verschlüsselten Ressourcenautorisierung“ (plain authorization) beim Erzeugen der Entsperrantwort (unlock response) im Token auf den Hash-Wert einer Nachricht gemäß Merkmal 1.4H3F (…wherein generating the unlock response comprises performing a computation on a plain authorization, wherein the plain authorization is a private signing key obtained by decrypting the encrypted resource authorization, and additional information, wherein the computation is a digital signature function on a message hash).

Dokument D10 lehrt – vergleichbar Dokument D9 – das Bereitstellen eines „Schlüsselverschlüsselungs-Schlüssels“ (Key-Encrypting Key), mit dem Dateischlüssel (File Key) verschlüsselt sind und die nur unter Verwendung des auf einem Token bereitgestellten „Key-Encrypting Key“ entschlüsselt werden können. Für ein Anwenden einer digitalen Signaturfunktion auf den Hash-Wert einer Nachricht unter Verwendung einer entschlüsselten verschlüsselten Ressourcenautorisierung gemäß Merkmal 1.4H3F – hier des entschlüsselten, mit dem „Key-Encrypting Key“ verschlüsselten „File Key“ – findet sich in Dokument D10 weder ein Hinweis, noch ist ein Anlass hierzu ersichtlich. Auch führt die Kenntnis über die Anwendung von Dateischlüsseln nicht naheliegend zu einer Abwandlung der Lehre der D10, um an Stelle des Bereitstellens des entschlüsselten verschlüsselten „File Key“ mittels eines separaten Tokens diesen Schlüssel zur Signatur des Hash-Werts einer Nachricht im Token heranzuziehen.

Daneben ist der D10 kein Ermöglichen des Zugriffs auf externe, auf einem Server befindliche Dateien im Sinne der Merkmale 1.1H2A und 1.6H2A zu entnehmen, da die Lehre der D10 darauf abzielt, ein lokales Dateisystem eines mobilen Geräts, bspw. im Falle des Verlusts des Geräts, vor unberechtigtem Zugriff zu schützen, wobei der Zugriff auf die verschlüsselten Dateien nur mit einem mit dem „Key-Encrypting Key“ verschlüsselten „File Key“ möglich ist, der wiederum nur entschlüsselt werden kann, wenn auch der separate Token zur Entschlüsselung des jeweiligen Dateischlüssels vorliegt. Auch für ein Übertragen dieser Lehre auf eine Speicherung von Computerressourcen auf einem externen Server findet sich in Dokument D10 weder ein Hinweis, noch ist ein Anlass für die Fachperson hierzu ersichtlich.

Dokument D11 ist in Dokument D9 zitiert (Referenz [3]) und entspricht im Wesentlichen der dort ebenfalls genannten Lehre der D10 (Referenz [1]). Die Überlegungen zum Dokument D10 gelten daher in gleicher Weise für das in wesentlichen Punkten inhaltlich übereinstimmende Dokument D11.

Der Patentanspruch 1 gemäß Hilfsantrag 3F erweist sich daher als neu gegenüber den Dokumenten D10 bzw. D11 und ist der Fachperson ausgehend von Dokument D10 bzw. D11 auch nicht nahegelegt.

5.4 Dokument D21 (EP 1 881 664 B1, im Verfahren 4 Ni 41/23 (EP) als Dokument D3 eingeführt) ist zu entnehmen, dass ein dem Streitpatent vergleichbarer Token dazu verwendet wird, den privaten (Entschlüsselungs-)Schlüssel verschlüsselt aufzubewahren, der nach der Authentifizierung des Nutzers zum Entschlüsseln von E-Mails verwendet werden kann (Abs. 0018). Zwar ist DokumentD21 auch zu entnehmen, eine digitale Signatur für eine zu versendende Ressource (E-Mail-Nachricht) aus einem Hash-Wert der Nachricht und dem privaten Signaturschlüssel, der im Token gespeichert ist, im Token zu erzeugen (Abs. 0019). Dieser private Signaturschlüssel gemäß Absatz 0019 der D21, der von der Verwendung eines privaten (Entschlüsselungs-)Schlüssel zum lokalen Entschlüsseln einer E-Mail nach Absatz 0018 zu unterscheiden ist, entspricht aber bereits aufgrund seiner Speicherung im Token nicht der entschlüsselten, vom Token in verschlüsselter Form empfangenen Ressourcenautorisierung. Zudem dient er der Signatur einer zu versendenden Ressource, nämlich einer E-Mail, und nicht dem anspruchsgemäßen Ermöglichen des Zugriffs auf eine extern gespeicherte Ressource (vgl. Merkmale 1.1H2A, 1.6H2A).

Eine Veranlassung der Fachperson, die Abläufe zur Signatur einer E-Mail auf das Erzeugen einer Entsperrantwort für eine Ressource zu übertragen und zusätzlich den dafür vorgesehenen Signaturschlüssel in verschlüsselter Form außerhalb des Tokens zu speichern, ist in der D21 nicht ersichtlich. Gleiches gilt für die Möglichkeit, die Abläufe zum Entschlüsseln einer empfangenen E-Mail abzuwandeln und auf das Versenden einer E-Mail anzuwenden und das Signieren der Nachricht vorzusehen, die als „Entsperrantwort“ den Zugriff auf eine (nach Merkmal 1.1H2A/1.6H2A extern) gespeicherte Ressource ermöglichen soll.

Der Patentanspruch 1 gemäß Hilfsantrag 3F erweist sich daher als neu gegenüber Dokument D21 und ist der Fachperson ausgehend von Dokument D21 auch nicht nahegelegt.

5.5 Die Lehre des Dokuments D4 (Hallsteinsen) unterscheidet sich vom Gegenstand des Patentanspruchs 1 bereits dadurch, dass keine Übertragung des geheimen Schlüssels an den Token im Sinne von Merkmal 1.3 stattfindet. Vielmehr werden Daten übertragen, aus denen jeweils im Authentifizierungsserver (Authentication Server) und im Token (mobile phone) der geheime Schlüssel erzeugt werden kann(vgl. 5. Seite, li. Spalte, Kap. VI. A. Java Midlet, Abschnitt Key exchange).

Als Entsperrantwort wird nach Dokument D4 ein Einmalpasswort an den Computer (Laptop) des Nutzers (User Computer) bspw. über eine gesicherte Bluetooth-Verbindung übertragen und von dort an den Authentifizierungsserver des Dienstanbieters weitergeleitet (vgl. 5. Seite, re. Spalte, Kap. VI. A. Java Midlet, Abschnitt OTP generation, vorl. Abs.; und 6. Seite, li. Spalte Kap. VI. B. Java Applet). Damit ist Dokument D4 auch kein Anwenden einer digitalen Signaturfunktion auf den Hash-Wert einer Nachricht gemäß Merkmal 1.4H3F zu entnehmen.

Der Gegenstand des Patentanspruchs 1 gemäß Hilfsantrag 3Ferweist sich daher als neu gegenüber der Entgegenhaltung D4. Ein Naheliegen des Patentanspruchs 1 ausgehend von der D4 haben die Klägerinnen bereits im Hinblick auf die erteilte Anspruchsfassung nicht geltend gemacht und ist im Hinblick auf Patentanspruch 1 gemäß Hilfsantrag 3F auch nicht ersichtlich. Insbesondere ist ausgehend von der Generierung eines Einmalpassworts in der D4 kein Anlass zur Anwendung einer digitalen Signaturfunktion entsprechend Merkmal 1.4H3F erkennbar.

5.6 In Dokument D6 (US 8,302,167 B2)sind bereits die Merkmale 1.3 bis 1.5 nicht realisiert, da keine Entschlüsselung einer (gespeicherten)„verschlüsselten Ressourcenautorisierung“erfolgt, sondern das Berechnen eines Einmalpasswortes bzw. einer Transaktionssignatur aus verschiedenen übermittelten oder auf einer (zusätzlichen) Smartcard gespeicherten Daten. Die Überprüfung der an den Token gesendeten „Server Challenge“ (vgl. Sp. 12, Z. 62 bis Sp. 13 Z. 8; Sp. 14, Z. 44 bis Sp. 15, Z. 63; Sp. 15, Z. 64 ff) oder die Prüfung der an den Token übertragenen Transaktionsdaten (vgl. Sp. 13, Z. 28-59; Sp. 15, Z. 27-63) stellen keine Entschlüsselung einer vom Server übertragenen verschlüsselten Ressourcenautorisierung dar, aus der (zumindest zum Teil) die Entsperrantwort erzeugt wird, auch wenn bspw. die Transaktionssignatur unter Verwendung der übermittelten Transaktionsdaten erzeugt wird (vgl. bspw. Sp. 8, Z. 37-41).

Zwar erfolgt als Voraussetzung für die Passwort- bzw. Signaturerzeugung eine Authentifizierung des Nutzers am Token durch Eingabe einer PIN (vgl. Sp. 11, Z. 55-61), womit diese Authentifizierung zwangsläufig eine Voraussetzung für das Erzeugen einer Entsperrantwort (PIN bzw. Transaktionssignatur) ist. Merkmal 1.8 ist jedoch allenfalls teilweise erfüllt, da der Token nach Dokument D6 keine Entsperrantworten versendet.

Darüber hinaus zeigt Dokument D6 auch kein Anwenden einer digitalen Signaturfunktion auf den Hash-Wert einer Nachricht gemäß Merkmal 1.4H3F und liefert der Fachperson auch keinen Anlass dazu, was die Klägerinnen im Übrigen auch nicht geltend gemacht haben.

Für eine Zusammenschau der Dokumente D5 und D6, wie sie im Hinblick auf die erteilte Anspruchsfassung geltend gemacht wurde, fehlt es bereits aufgrund der unterschiedlichen Konzepte und der dafür verschiedenen Hardwareanforderungen an einer Veranlassung für die Fachperson, um dadurch einzelne Merkmale der beiden Dokumente so zu kombinieren, um zur Merkmalskombination des Anspruchs 1 zu gelangen.

Der Patentanspruch 1 gemäß Hilfsantrag 3F erweist sich daher als neu gegenüber Dokument D6 und ist der Fachperson ausgehend von Dokument D6 auch nicht nahegelegt.

5.7 Das Dokument D15(Lu) sieht eine Methode für den Zugriff auf Cloud-Computing-Ressourcen, bspw. eine Web-Anwendung in einer Cloud, über eine Anwendungsprogrammierschnittstelle („API“) vor, bei der jede API-Anforderung einer Client-Anwendung eine Client-Authentifizierung gegenüber dem Cloud-Dienst umfassen muss.Die D15 sieht dabei abweichend vom Streitpatent vor, dass eine verschlüsselte Ressourcenautorisierung auf dem Token gespeichert ist (DS. 36, Kap. 4), während es sich beim Identifizierer Idk um keine verschlüsselte Ressourcenautorisierung im Sinne des Streitpatents handelt. Damit erfüllt die D15 die Merkmale 1.3 und 1.4 bereits nicht. Zudem ist die Anwendung der Lehre der D15 auf einer Mobilvorrichtung nicht vorgesehen (S. 37, Kap. 7, vorl. Abs.).

In der D15 ist zwar allgemein auf die Möglichkeit hingewiesen, an Stelle eines Schlüssels zum Ermöglichen des Zugriffs auf eine verschlüsselten (Cloud-)Ressource (nur) ein Passwort zu verwenden (vgl. S. 31, Abschnitt 4.3 Cryptographic Computations, erster Absatz), nicht aber, mit einer an den Token übertragenen, vom Token entschlüsselten Ressourcenautorisierung (plain authorization) eine Berechnung in Form einer digitalen Signaturfunktion gemäß Hilfsantrag 3F auf den Hash-Wert einer Nachricht durchzuführen, um damit eine Entsperrantwort für eine Ressource zu generieren. Eine Veranlassung für die Fachperson zur Abwandlung der Lehre der D15 im Sinne des Patentanspruchs 1 ist nicht ersichtlich. Daher ergibt sich der Gegenstand des Patentanspruchs 1 gemäß Hilfsantrag 3F nicht naheliegend ausgehend von Dokument D15.

5.8 Wie vorstehend bereits zur Frage der Patentfähigkeit des Patentanspruchs 1 gemäß Hauptantrag ausgeführt, hat der Senat bereits Zweifel, dass die Prioritäten der britischen Patentanmeldung GB 1221433.4 (Anlage NK3), der US-Patentanmeldung US 13/706,307 (Anlage NK4) und der britischen Patentanmeldung GB 1303677.7 (Anlage NK5) materiell wirksam in Anspruch genommen sind.

Dies kann jedoch auch im Hinblick auf Hilfsantrag 3F dahinstehen, da der Gegenstand der nebengeordneten Patentansprüche 1 und 7 nach Hilfsantrag 3F der Fachperson auch nicht ausgehend von einem der nach der zweiten bzw. dritten Prioritätsanmeldung, aber vor dem Anmeldetag des Streitpatents veröffentlichten Dokumente D2 (WO 2013/167 043 A2), D3(Anlagenkonvolut hoverkey.com) oder D5(Clark: Hoverkey adds NFC security to Android apps) nahegelegt wird.

So sieht Dokument D2 (WO 2013/167 043 A2) bereits keine Mehrfaktorenauthentifizierung für den Zugriff auf die Computerressource vor, denn für den Zugriff auf eine Computerressource reicht hier das Vorliegen der als Token fungierenden Mobilvorrichtung alleine aus. Das Setzen und Erzeugen des auf dem Mobilgerät (= Token) gespeicherten Passworts unter Verwendung eines Superpassworts umfasst zwar auch eine Nutzer-Authentifizierung. Diese Authentifizierung wird jedoch nicht im Sinne von Merkmal 1.8 nach Hilfsantrag 3F im Rahmen der Erzeugung und Übertragung der Entsperrantwort validiert. Das Superpasswort spielt vielmehr nur bei der (ggf. einmaligen) Einrichtung des Tokens eine Rolle.

Dem Dokumentenkonvolut D3zum Hoverkey-Systemist kein Validieren der Benutzerauthentifizierung (PIN-Eingabe nach Merkmal 1.7) auf dem Token zu entnehmen. Somit fehlt es der D3 bereits an der anspruchsgemäßen Voraussetzung der verifizierten Benutzerauthentifizierung für das Erzeugen und Senden der Entsperrantwort.

Das Dokument D5(Clark)betrifft – wie die Dokumente zu D3 – das Hoverkey-System. Dem Fachartikel sind ebenfalls keine Angaben zur Benutzerauthentifizierung auf dem Token nach den Merkmalen 1.7 und 1.8 zu entnehmen, so dass Dokument D5 bereits die anspruchsgemäße Mehrfaktorenauthentifizierung nicht zeigt.

Darüber hinaus offenbart keines der Dokumente D2, D3 und D5 eine Ausgestaltung zum Anwenden einer digitalen Signaturfunktion auf den Hash-Wert einer Nachricht gemäß Merkmal 1.4H3F im Rahmen des jeweils beschriebenen Zugriffs auf eine extern gespeicherte Computerressource unter Verwendung eines separaten Tokens.

Patentanspruch 1 gemäß Hilfsantrag 3F erweist sich daher als neu gegenüber dem Stand der Technik nach den Dokumenten D2, D3 oder D5. Ein Naheliegen des Patentanspruchs 1, jeweils ausgehend von einem dieser Dokumente, wurde bereits im Hinblick auf die erteilte Anspruchsfassung nicht geltend gemacht und ist insbesondere im Hinblick auf Patentanspruch 1 gemäß Hilfsantrag 3F auch nicht ersichtlich.

5.9 Weitere Dokumente haben die Klägerinnen nur im Zusammenhang mit einzelnen Merkmalen oder angegriffenen Unteransprüchen sowie zum Beleg des Fachwissens in das Verfahren genannt; sie stehen der Patentfähigkeit der Ansprüche des Streitpatents in der Fassung nach Hilfsantrag 3F demnach ebenfalls nicht entgegen.

Die DokumentD7 (WO 2008/147457 A1) betrifft eine NFC-Smartcard mit Mitteln zur biometrischen Authentifizierung eines Nutzers, DokumentD8 (DE 10 2009 040 009 A1) befasst sich mit der 2-Faktor-Authentifizierung mittels einer NFC-Smartcard zur manipulationssicheren Verschlüsselung fürOnline-Accounts. Beide Dokumente haben die Klägerinnen nur im Hinblick auf weitere Ausgestaltungen des Streitpatents in den Unteransprüchen in das Verfahren benannt, insbesondere zu Aufbau und Verwendung einer sicheren Verbindung zwischen dem Token und der mobilen Vorrichtung des Nutzers.

Die Dokumente D12 (Stanoevska-Slabeva et al.) und D17 (Sosinski B.) hat die Klägerin zu 2und die Dokumente D13 (Grandison et al.) undD14 (Grossmann) die Klägerin zu 1zum Beleg des fachmännischen Verständnisses des Begriffs „Cloud“ genannt.

Die Dokumente D15 (Lu) und Dokument D16 (US 2012/0297190 A1) haben die Klägerinnen zum Beleg eingeführt, dass auch das Auslagern von sicherheitsrelevanten Daten, wie etwa von verschlüsselten Zugangsdaten bzw. Authentifizierungsdaten in die Cloud, zum Prioritätstag des Streitpatents zum Stand der Technik zählte und auch im Rahmen des Cloud-Zugriffs eine Zwei-Faktor-Authentifizierung verwendet wurde.

Die Dokumente D18 (US 2010/0266132 A1) und D19 (WO 2012/027708 A2) hat die Klägerin zu 1nur in Zusammenschau mit dem jeweiligen Dokument D9 und D10 genannt.

Dokument D20 (MA D., et al.) hat die Klägerin zu 2nur in Zusammenschau mit dem Dokument D21 genannt.

Dokument D22 (Kramp et al.) betrifft die sichere Authentifizierung beim Online-Banking. Die D22 hat die Klägerin zu 1 im Zusammenhang mit der Nutzerautorisierung zum Zugriff auf Anwendungen auf einem Server bzw. auf Webanwendungen, das digitale Signieren mittels Smartcard sowie hinsichtlich Zertifikaten als möglichen Anwendungskennungen genannt.

Dokument D22 führt hinsichtlich der Anwendung einer digitalen Signaturfunktion nach Anspruch 1 gemäß Hilfsantrag 3F auch ausgehend von einem der weiteren Dokumente D1, D10 oder D21 nicht naheliegend zum Gegenstand des Hilfsantrags 3F, da Dokument D22 nur die Verwendung eines Tokens (Smartcard) als Träger eines Signaturschlüssels (und -zertifikates) lehrt (vgl. D22, Fig. 5 mit Beschreibung), das abweichend von der Lehre des Streitpatents einerseits die Speicherung von Authentifizierungs- und Signaturschlüsseln auf dem Token vorsieht und andererseits dessen Einsatz die Verwendung eines zusätzlichen, zur Mobilvorrichtung externen Kartenlesegerätes voraussetzt.

Auch Dokument D23 (US2008/0065892A1) betrifft Authentifizierungsverfahren unter der Verwendung von tragbaren Sicherheitstokens. Die D23 hat die Klägerin zu 2 im Zusammenhang mit der digitalen Signaturfunktion genannt. Jedoch wird abweichend vom Streitpatent nach Dokument D23 der geheime Signaturschlüssel auf der Mobilvorrichtung des Nutzers gespeichert. Dokument D23 führt somit hinsichtlich der Anwendung einer digitalen Signaturfunktion nach Anspruch 1 gemäß Hilfsantrag 3F auch ausgehend von einem der weiteren Dokumente D1, D10 oder D21 nicht naheliegend zum Gegenstand des Hilfsantrags 3F.

Auf Dokument D24 (EP1552661B1)haben die Klägerinnen insbesondere im Hinblick auf die Nutzer-Authentifizierung beim Zugriff auf Anwendungen und die Verwendung von Anwendungskennungen in das Verfahren verwiesen. Auch dem Dokument D24 ist nicht zu entnehmen, dass mit der an den Token übertragenen, vom Token entschlüsselten Ressourcenautorisierung (plain authorization) eine Berechnung in Form einer digitalen Signaturfunktion gemäß Hilfsantrag 1.4H3F auf den Hash-Wert einer Nachricht angewendet wird.

Auch in Dokument D25 (US8065718B2) wird eine digitale Signatur beschrieben. Zur Authentifizierung des Nutzers erfolgt in einem Token (Hardware token) die Signatur einer Challenge-Response-Antwort R‘, wobei die Signatur, bspw. des Hash-Werts mit einem „geteilten“ Geheimnis (shared secret), mit einem privaten Schlüssel erfolgt (vgl. D25, Spalte 5, Zeile 59 bis Spalte 6, Zeile 20).Hierbei ist jedoch der D25 nicht zu entnehmen, ob der private Schlüssel bereits auf dem Token vorliegt oder ob dieser anspruchsgemäß vor dessen Verwendung an den Token übertragen und von diesem entschlüsselt wird.

Zwar zeigt die Lehre der D25 ein Signieren mittels eines privaten Signaturschlüssels auf einem Token. Jedoch fehlt ausgehend von einem der weiteren Dokumente D1, D10 oder D21 die Veranlassung für die Fachperson, nicht eine Entsperrantwort zum Zugriff auf eine Ressource zu generieren, die einen Schlüssel oder ein Passwort enthält, sondern als Entsperrantwort stattdessen den Hash-Wert einer nicht näher definierten Nachricht zu signieren. Umgekehrt ist bei der Verwendung des Tokens nach Dokument D25 keine Veranlassung ersichtlich, für das Durchführen einer Signatur mittels Token einen verschlüsselten privaten Signaturschlüssel erst an den Token zu übermitteln, um diesen dann zur Verwendung bei der Signatur einer Challenge-Response-Antwortzu entschlüsseln, da der Token nach der D25 ohne erkennbare weitere Maßnahmen selbstständig bei Übermittlung der Challenge-Response-Antwort R‘ die Signatur durchführen kann. Dokument D25 führt somit hinsichtlich der Anwendung einer digitalen Signaturfunktion nach Anspruch 1 gemäß Hilfsantrag 3F auch in Zusammenschau mit einem der weiteren Dokumente D1, D10 oder D21 nicht naheliegend zum Gegenstand des Hilfsantrags 3F.

Das Dokument D26 (Hunter) haben die Klägerinnen als Beispiel einer Zwei-Faktor-Authentifizierung genannt, bei der ein Token (YubiKey) eine Taste aufweist, mit dem ein Einmalpasswort(OTP) für den Nutzer generiert wird (D25, Seite 62, Zeilen 6 bis 8).

Dokument D27 (EP 1 739 913 A1)haben die Klägerinnen im Hinblick aufDRM-Daten genannt, die verschlüsselt in der Cloud vorgehalten und mittels eines Tokens entschlüsselt werden, womit die Inhalte, welche durch die DRM-Daten verwaltet werden, auf einer Mobilvorrichtung verwendet werden können. Nachrichten, mit denen die verschlüsseltenDRM-Daten übermittelt werden, enthalten wiederum die Schlüssel zum Entschlüsselnder DRM-Daten(vgl. D27, Abs. 0031), wobei die DRM-Daten für Anwendungen auch Anwendungskennungen darstellen.

Eine Vorwegnahme des Gegenstands des Patentanspruchs 1 gemäß Hilfsantrag 3F oder dessen Naheliegen ausgehend von einem dieser Dokumente D7, D8, D12 bis D20 und D22 bis D27haben die Klägerinnen nicht geltend gemacht und ist für den Senat auch nicht ersichtlich.

Der Gegenstand des Patentanspruchs 1 nach Hilfsantrag 3Fist demnach gegenüber dem verfahrensgegenständlichen Stand der Technik neu und beruht auf einer erfinderischen Tätigkeit.

5.10 Die vorstehenden Ausführungen zu dem auf ein Verfahren gerichteten Patentanspruch 1 nach Hilfsantrag 3F gelten in gleicher Weise für den nebengeordneten und auf ein System gerichteten Patentanspruch 7 nach Hilfsantrag 3F, gemäß dem das System Mittel zur Ausführung des Verfahrens nach Patentanspruchs 1 umfasst. Die Patentfähigkeit der unabhängigen Ansprüche 1 und 7 trägt auch die auf sie rückbezogenen Ansprüche 2 bis 6 und 8 bis 13.

Nebenentscheidungen

Die Kostenentscheidung beruht auf § 84 Abs. 2 PatG i. V. m. § 92 Abs. 1 ZPO.

Die Kostenquote entspricht dem Anteil des Obsiegens und Unterliegens der Parteien. Dabei hat der Senat berücksichtigt, dass der Schutzumfang des nach dem Hilfsantrag 3Feingeschränkten schutzfähigen Patentgegenstands gegenüber demjenigen der erteilten Fassung deutlich geringer ist; denn die erteilte Fassung wies mit

- der Verwendung der Ressourcenautorisierung als Passwort, PIN oder Signaturschlüssel, sowie deren Weitergabe im Klartext oder in wiederverschlüsselter Form und nicht nur als privaten Schlüssel beim Durchführen einer Signaturfunktion durch den Token (Merkmal 1.4H3F), sowie

- der Verwendung des beanspruchten Verfahrens auch für lokal gespeicherte Computerressourcen und nicht nur für solche, die auf externen Servern gespeichert sind (Merkmale 1.1H2A; 1.6H2A),

einen wesentlich größeren Schutzumfang auf. Den infolge der Änderung reduzierten, verbleibenden Schutzumfang schätzt der Senat auf 1/4 des Streitpatents.

Da die mit Hilfsantrag 3F verteidigte Fassung zu einer erheblichen inhaltlichen Beschränkung des geschützten Gegenstands führt, ist das Unterliegen der Beklagten mit 75 % und dementsprechend das der Kläger mit 25 % zu bewerten.

Die Klägerinnen haften für die Kosten des Verfahrens nach Kopfteilen (§ 84 Abs. 2 Satz 2 Halbsatz 1 PatG i. V. m. § 100 Abs. 1 ZPO).

Die Entscheidung über die vorläufige Vollstreckbarkeit beruht auf § 99 Abs. 1 PatG i. V. m. § 709 ZPO.