4 W (pat) Ep 61/22

ECLI:DE:BPatG:2025:010925U4Ni 61.22EP.0 BUNDESPATENTGERICHT IM NAMEN DES VOLKES URTEIL 4 Ni 61/22 (EP) verbunden mit 4 Ni 41/23 (EP) ______________________________________ (Aktenzeichen) In der Patentnichtigkeitssache … Seite 2/88 betreffend das europäische Patent 2 926 290 (DE 60 2013 069 972) hat der 4. Senat (Nichtigkeitssenat) des Bundespatentgerichts auf die mündliche Ver- handlung vom 9. April 2025 durch die Richterin Werner M. A. als Vorsitzende und die Richter Kätker, Dipl.-Ing. Altvater, Dipl.-Ing. Matter und Dipl.-Ing. Tischler für Recht erkannt: I. Das Patent 2 926 290 wird teilweise für nichtig erklärt, soweit es über folgende Fassung hinausgeht: 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 on a message hash; securely transmitting the generated unlock response to the mobile de- vice; Seite 3/88 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 au- thentication is validated on the at least one separate portable security token device before the unlock response is sent. 2. A method as claimed in any one of the preceding claims in which the unlock response is transmitted to the mobile device under the protection of an encryption key, such as a session key. 3. A method as claimed in any one of the preceding claims in which the at least one separate portable security token stores user credentials, the decryption on the at least one separate portable security token device being based on the user credentials, in which, optionally, the user cre- dentials are generated by the at least one separate portable security to- ken device and never leave the at least one separate portable security token device. 4. A method as claimed in claim 3, in which the encrypted resource author- ization can be decrypted solely with the corresponding user credentials stored on the at least one separate portable security token device. 5. A method as claimed in any one of the preceding claims in which the mobile device and the at least one separate portable security token de- vice perform cryptographic mutual authentication before transmission of the encrypted resource authorization. 6. A method according to any preceding claim, wherein user authentication on the mobile device is via biometric information, for example, a finger- print and/or iris pattern. 7. 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 car- rying out the method of claim 1. Seite 4/88 8. A system as claimed in claim 7 wherein the at least one separate portable security token device is configured to transmit the unlock response to the mobile device under the protection of an encryption key such as a ses- sion key. 9. A system as claimed in claims 7 or 8, wherein the user authentication is via biometric information, for example, a fingerprint and/or iris pattern. 10. A system as claimed in any one of claims 7 to 9 wherein the at least one separate portable security token device is configured to verify the integ- rity of the encrypted resource authorization prior to decryption. 11. A system as claimed in any one of claims 7 to 10 in which the mobile device and the at least one separate portable security token device are configured to perform cryptographic mutual authentication before trans- mission of the encrypted resource authorization. 12. A system as claimed in any one of claims 7 to 11 wherein the at least one separate portable security token device is configured to send the unlock response only on positive confirmation by the user, for example by pressing a button on the token. 13. A system as claimed in any one of claims 7 to 12, wherein the at least one separate portable security token device is provided by any one of a keyfob, a badge, an NFC smartcard, a watch, a wearable ring, a fitness band, a wireless headset, a piece of jewellery, or a mobile computing device. II. Im Übrigen werden die Klagen abgewiesen. III. Die Gerichtskosten des Rechtsstreits tragen die Klägerinnen als Gesamt- schuldner zu 25 % und die Beklagte zu 75 %. Die außergerichtlichen Kosten der Beklagten tragen die Klägerinnen je- weils zu 12,5 %. Die außergerichtlichen Kosten der Klägerinnen trägt die Beklagte jeweils zu 75 %. Seite 5/88 Im Übrigen tragen die Parteien ihre außergerichtlichen Kosten selbst. IV. Das Urteil ist gegen Sicherheitsleistung in Höhe von 120 % des jeweils zu vollstreckenden Betrages vorläufig vollstreckbar. T a t b e s t a n d 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 Bundesre- publik Deutschland erteilten europäischen Patents 2 926 290 (Streitpatent), das am 27. November 2013 unter Inanspruchnahme der Priorität der britischen Patentanmel- dung GB 201221433 vom 28. November 2012, der US-Patentanmeldung US 201213706307 vom 5. Dezember 2012 und der britischen Patentanmeldung GB 201303677 vom 1. März 2013 angemeldet worden ist. Die Erteilung des Patents ist am 17. Juni 2020 veröffentlicht; das Patent ist in Kraft. Das Streitpatent betrifft ein Verfahren und ein System zur Authentifizierung eines Nut- zers 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 Benutzerzu- gangs zu einer Computerressource über eine mobile Vorrichtung mit mehreren separaten Sicherheitsfaktoren“ Seite 6/88 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 mittelbar oder unmittel- bar auf Patentanspruch 9 zurückbezogen. Die nebengeordneten 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 port- able security token device; on the at least one separate portable security token device, decrypting the en- crypted 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 port- able 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 Streitpatent- schrift wie folgt: 1. Verfahren zum Authentifizieren eines Benutzers für den Zugriff auf eine Com- puterressource über eine Mobilvorrichtung, umfassend: Seite 7/88 Speichern einer verschlüsselten Ressourcenautorisierung; Übertragen der verschlüsselten Ressourcenautorisierung an wenigstens eine getrennte trag- bare 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 ei- nen getrennten tragbaren Sicherheitstoken-Vorrichtung authentifizieren muss und die Benutzerauthentifizierung auf der wenigstens einen getrennten trag- baren Sicherheitstoken-Vorrichtung validiert wird, bevor die Entsperrantwort gesendet wird. 9. System zum Authentifizieren eines Benutzers für den Zugriff auf eine Compu- terressource über eine Mobilvorrichtung, wobei das System eine Mobilvorrich- tung und wenigstens eine getrennte tragbare Sicherheitstoken-Vorrichtung um- fasst, die Mittel zum Ausführen des Verfahrens nach Anspruch 1 umfassen. Die Klägerinnen greifen mit ihren Nichtigkeitsklagen vom 22. Juni 2022 und 13. Okto- ber 2023 das Streitpatent insgesamt an. Die Klägerinnen sind der Ansicht, der Gegen- stand des Streitpatents gehe über den Inhalt der Anmeldung in der ursprünglich ein- gereichten 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 über- einstimmend die Nichtigkeitsgründe der unzulässigen Erweiterung, der für die Ausführ- barkeit 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): Seite 8/88 Klägerin zu 1 Klägerin zu 2 Im Weiteren Dokument Veröffent- licht 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 authentica- tion. In: 2007 2nd 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 An- droid 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 Electron- ics, Vol. 54, No. 4, November 2008 11.2008 D10 D2 D10 Corner et al: Protecting File Systems with Transient Authentication. Wireless Net- works 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 Defini- tion of a Computing Cloud. IEEE Com- puter Society, 2010 IEEE 6 th World Con- gress on Services 2010 D14 D14 Grossman: The Case for Cloud Compu- ting. IT Professional. IEEE Computer Soci- ety, Mai 2009 05.2009 Seite 9/88 D15 D15 Lu: Accessing Cloud through API in a more Secure and Usable Way. In: Pro- ceedings of the 8 th International Work- shop 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 Re- mote 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 au- thentication. 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 Pass- words. 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, Seite 10/88 soweit sie sich auch gegen eine der Fassungen des Streitpatents nach dem in der mündlichen Verhandlung vom 27. Oktober 2023 (im Ver- fahren 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 nume- rischen und darunter in der alphabetischen Reihenfolge geprüft wer- den sollen und diese Anträge, wie auch die erteilte Fassung des Streit- patents 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, Patentan- spruch 4, Patentanspruch 5 bezogen auf Patentanspruch 1 und dann auf Pa- tentanspruch 2 (auf die weiteren rückbezogenen Anspruchsfassungen wird verzichtet), Patentanspruch 6 bezogen auf Patentanspruch 1 und dann auf Pa- tentanspruch 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 Patentan- spruch 2, Patentanspruch 11, Patentanspruch 12 bezogen auf Patentanspruch 10 dann auf Pa- tentanspruch 11, Seite 11/88 Patentanspruch 13 bezogen auf Patentanspruch 10, dann auf Pa- tentanspruch 11 und dann auf Patentanspruch 12, Patentanspruch 14 bezogen auf Patentanspruch 10, dann auf Pa- tentanspruch 11, dann auf Patentanspruch 12 und dann auf Patentan- spruch 13, Patentanspruch 15 bezogen auf Patentanspruch 10, dann auch Pa- tentanspruch 11, dann auf Patentanspruch 12, dann auf Patentan- spruch 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 Gegen- stand 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 Fassun- gen 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 auf- genommen 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 (Änderun- gen sind durch Unterstreichen bzw. Durchstreichen kenntlich gemacht): Seite 12/88 Patentanspruch 1 des Hilfsantrags 2B hat die Beklagte wie folgt geändert (Änderun- gen sind durch Unterstreichen bzw. Durchstreichen kenntlich gemacht): Patentanspruch 1 des Hilfsantrags 3A hat die Beklagte wie folgt geändert (Änderun- gen sind durch Unterstreichen bzw. Durchstreichen kenntlich gemacht): Seite 13/88 Patentanspruch 1 des Hilfsantrags 3B hat die Beklagte wie folgt geändert (Änderun- gen sind durch Unterstreichen bzw. Durchstreichen kenntlich gemacht): Seite 14/88 Patentanspruch 1 des Hilfsantrags 3C hat die Beklagte wie folgt geändert (Änderun- gen sind durch Unterstreichen bzw. Durchstreichen kenntlich gemacht): Patentanspruch 1 des Hilfsantrags 3D hat die Beklagte wie folgt geändert (Änderun- gen sind durch Unterstreichen bzw. Durchstreichen kenntlich gemacht): Seite 15/88 Patentanspruch 1 des Hilfsantrags 3E hat die Beklagte wie folgt geändert (Änderun- gen sind durch Unterstreichen bzw. Durchstreichen kenntlich gemacht): Seite 16/88 Patentanspruch 1 des Hilfsantrags 3Ea unterscheidet sich von Hilfsantrag 3E dadurch, dass nach „... wherein the computation is a digital signature function ...“ Fol- gendes aufgenommen ist: “, and wherein the plain authorization is not included in the unlock re- sponse”. 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” ein- gefügt “and verifying” und in dem Teilsatz “wherein the plain authorization is a private signing key ob- tained 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 re- sponse”. Zum Wortlaut von Hilfsantrag 3F 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. Ja- nuar 2025 und der Hilfsanträge 3Ea, 3Eb und 12 erstmals in der mündlichen Verhand- lung vom 9. April 2025 als verspätet. Der Senat hat den Parteien im Verfahren mit dem Az.: 4 Ni 61/22 (EP) einen qualifi- zierten Hinweis vom 16. Januar 2023, ergänzt mit Hinweis vom 24. Juli 2024, und im Seite 17/88 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. E n t s c h e i d u n g s g r ü n d e A. 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 Int- PatÜ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 schutz- fähig, so dass die Klagen, soweit sie sich auch gegen diese Fassung richten, abzu- weisen 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, Merk- malsgliederung und Auslegung 1. Das Streitpatent betrifft ein Verfahren und ein System zum Authentifizieren ei- nes Nutzers gegenüber einer Computerressource, auf die über ein mobiles Gerät zu- gegriffen wird, unter Verwendung eines tragbaren Sicherheitstokens (beispielsweise Seite 18/88 einer kontaktlosen Smartcard oder eines Armbands), zusammen mit einem Geheim- nis, an das sich der Benutzer leicht erinnern kann (z. B. ein PIN-Code). Dieses Ge- heimnis stellt einen zweiten, separaten, vorzugsweise unabhängigen Sicherheitsfaktor bereit, der die Computerressource schützen kann, selbst wenn der tragbare Sicher- heitstoken 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 Zu- griff auf Anwendungen ein hohes Maß an Sicherheit für Daten auf ihrem Gerät ge- währleistet haben. Das könne durch eine Verschlüsselung auf Ebene des mobilen Be- triebssystems erreicht werden, bei dem ein kryptographischer Schlüssel aus dem Ent- sperrpasswort 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 de- vice) überprüfe fortlaufend, ob sich der Token in der Nähe der Mobilvorrichtung be- finde. Ein solches System habe den Nachteil, dass die häufige Kommunikation zwi- schen 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 (Ab- sätze 0007 - 0009). Aus der Patentanmeldung US 2011/0212707 A1 sei eine generische Authentifizie- rungslösung mit einem zusätzlichen Token bekannt, der einem Mobiltelefon einen asymmetrischen Schlüssel bereitstelle, den das Mobiltelefon zum Erstellen einer digi- talen Signatur verwende, mit dem sich das Mobiltelefon bei einem außenstehenden Dienstanbieter authentifiziere. Bei Verlust eines solchen Tokens seien die darauf ge- Seite 19/88 speicherten Anmeldedaten gefährdet. Die Verwendung des Tokens sei aus verschie- denen 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 Patentanmel- dung US 2008/0289030 A1 bekannt. Die Authentifizierungslösung verwende einen kontaktlosen Token, der nach der Validierung den Zugriff auf die auf der Mobilvorrich- tung 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 ge- sicherte Funktion oder Anwendung. Wesentlicher Nachteil sei, dass eine logische Kon- trolle verwendet werde, die leicht zu umgehen sei (Absätze 0014, 0015). Im Allgemeinen sieht das Streitpatent insbesondere im Unternehmensumfeld ein er- hebliches Sicherheitsrisiko, wenn Benutzern das Verbinden von Mobilvorrichtungen mit dem Netzwerk des Unternehmens erlaubt werde. Dadurch steige die Wahrschein- lichkeit 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 alphanu- merischen Codes oder leicht zu erratenden Passcodes oder verlorenen oder gestoh- lenen Geräten oder nicht überwachten Geräten von Drittanbietern (Absatz 0016). Durch die Ausführungsformen des beanspruchten Systems sollen Lösungen bereitge- stellt werden, um diesen Gefahren entgegenzuwirken. Der Nutzer könne einen kryp- tographischen Hauptschlüssel (master key) mit hoher kryptographischer Stärke (128 Bit oder mehr) auf dem tragbaren Sicherheitstoken speichern und dieser Schlüs- sel könne verwendet werden, um entweder direkt den Datenverschlüsselungsschlüs- sel einer Anwendung oder ein langes und komplexes Passwort zu schützen, aus dem Seite 20/88 ein ausreichend langer und sicherer Verschlüsselungsschlüssel abgeleitet werden kann. Dies erlaube dem Nutzer, jegliche Daten auf der Mobilvorrichtung mit einer star- ken Verschlüsselung zu schützen, ohne dass ein Angreifer diese ohne Besitz des zu- gehö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 Sys- tem zum Authentifizieren eines Benutzers gegenüber einer Computerressource anzu- geben, 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. ei- nem PIN-Code) (vgl. Absätze 0001, 0016). 3. Die maßgebliche Fachperson zur Bearbeitung dieser Aufgabe verfügt über ei- nen Fachhochschulabschluss der Fachrichtung Informatik und mehrjähriger Berufser- fahrung im Bereich der Implementierung von Zugriffs- und Authentifizierungsverfahren in Computersystemen. 4. Die vom Streitpatent vorgeschlagene Lösung der Aufgabe nach Patentan- spruch 1 lässt sich auf der Grundlage der von den Parteien vorgeschlagenen Merk- malsgliederung 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 compris- ing: Verfahren zum Authentifizieren eines Be- nutzers für den Zugriff auf eine Compu- terressource über eine Mobilvorrichtung, umfassend: 1.2 storing an encrypted resource authorization; Speichern einer verschlüsselten Res- sourcenautorisierung; 1.3 transmitting the encrypted resource authorization to at least one separate portable security token device; Übertragen der verschlüsselten Ressour- cenautorisierung an wenigstens eine ge- trennte tragbare Sicherheitstoken-Vor- richtung; Seite 21/88 1.4 on the at least one separate portable security to- ken 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 Res- sourcenautorisierung und Generieren, wenigstens teilweise dar- aus, einer Entsperrantwort; 1.5 securely transmitting the generated unlock re- sponse to the mobile device; and sicheres Übertragen der generierten Ent- sperrantwort an die Mobilvorrichtung; und 1.6 providing access via the mobile device to the computer resource if the required unlock re- sponse is valid; Gewähren des Zugriffs, über die Mobil- vorrichtung, 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 Mobilvor- richtung 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 be- fore the unlock response is sent. die Benutzerauthentifizierung auf der we- nigstens einen getrennten tragbaren Si- cherheitstoken-Vorrichtung validiert wird, bevor die Entsperrantwort gesendet wird. Der Patentanspruch 9 lä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 Be- nutzers für den Zugriff auf eine Compu- terressource ü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 entsprechenden nebengeordneten Ansprüche, Verfahrensan- spruch 1 und 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 Seite 22/88 eine Mobilvorrichtung (A method of authenticating a user to access a computer re- source via a mobile device). Nach den Angaben in der Beschreibung kann die Computerressource auf der Mobil- vorrichtung 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 Ver- wendung der Mobilvorrichtung erfolgt. Sie stellt jedoch keine Beschränkung des An- spruchs auf Computerressourcen dar, die ausschließlich außerhalb der Mobilvorrich- tung vorliegen. Der Begriff „Computerressource“ (computer resource) selbst ist im Streitpatent nicht definiert. Der Beschreibung einer Ausführungsform in Absatz 0001 und weiteren Aus- führungsbeispielen entnimmt die Fachperson, dass das Streitpatent unter den zu schützenden Ressourcen ganz allgemein Anwendungen und gespeicherte Daten ver- steht, 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. Seite 23/88 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 Au- thentifizierung des Nutzers. Hierfür muss der Nutzer gemäß Merkmal 1.7 entweder an der Mobilvorrichtung (on the mobile device) oder an der separaten, tragbaren Sicher- heitstoken-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üs- selten Ressourcenautorisierung erfolgt, ist im Anspruch 1 nicht festgelegt (s. u.); die Fachperson erkennt allerdings, dass eine Speicherung auf der tragbaren Sicherheits- token-Vorrichtung (portable security token device) ausscheidet, da die verschlüsselte Ressourcenautorisierung erst im Verfahrensablauf mit Merkmal 1.3 zur Entschlüsse- lung 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 autho- rization stored on the mobile device) soll sichergestellt werden, dass allein der Besitz Seite 24/88 des Tokens oder allein die Kenntnis der verschlüsselten Ressourcenautorisierung je- weils 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 Fachper- son als ein Bereithalten für deren spätere oder wiederholte Nutzung. Keine Speiche- rung im Sinne des Streitpatents stellt dagegen dar, wenn die verschlüsselte Ressour- cenautorisierung im Rahmen einer Verarbeitung oder Übertragung – technisch bedingt – kurzzeitig in einem lokalen Speicher gehalten werden muss, bspw. während der Ent- schlü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 Betriebssys- tem (executable system) aufweist, das geeignet ist, die erforderlichen Kommunikati- ons- und kryptografischen Funktionen auszuführen. Als Beispiele nennt das Streitpa- tent unter anderem Mobiltelefone, Tablets, Laptops, Smartphones, aber auch Smart- cards (vgl. Abs. 0048, 0065). Aus der Bezeichnung als separater tragbarer Token folgt, dass dieser nicht Bestandteil der Mobilvorrichtung (mobile device) ist, über die der Zu- griff auf die Computerressource erfolgt, bzw. diese Mobilvorrichtung nicht zugleich als Token dient. Ausgehend von den vorgenannten Beispielen gibt es keinen Hinweis da- rauf, 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 Res- sourcenautorisierung (encrypted resource authorization) gespeichert ist (vgl. Merkmal Seite 25/88 1.2). Damit ist in Anspruch 1 umfasst, dass die Speicherung lokal auf der Mobilvorrich- tung (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 6 der Streitpatentschrift vorsieht (vgl. Abs. 0114, Schritte 3 und 5): In Anspruch 1 bleibt auch offen, wodurch die Übertragung der verschlüsselten Res- sourcenautorisierung (encrypted resource authorization) an den Token ausgelöst wird. Zur Bedeutung des möglichen Übertragens der verschlüsselten Ressourcenautorisie- rung 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 Verfahrensab- lä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). Seite 26/88 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üs- selten Ressourcenautorisierung, ggf. unter Verwendung weiterer, Token-basierter Da- ten beruhen, wie bspw. eine digitale Signatur, eine Schlüsselableitung oder eine Wie- derverschlü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 Kom- munikation zwischen Mobilvorrichtung und Token sieht das Streitpatent NFC oder an- dere Arten der Funkkommunikation, wie bspw. Bluetooth, vor (vgl. Abs. 0044, 0057, 0059, 0066). Das Streitpatent spricht dabei von einer Ausgestaltung der Implementie- rung der Kommunikation zwischen Mobilvorrichtung und Token durch jede Art der Kommunikation, die in ausreichender Weise für die Übertragung von Authentifizie- rungsdaten gesichert werden kann (vgl. Abs. 0058: …communication between the mo- bile device and the portable token may be implemented using any form of communi- cation that can be sufficiently secured for the transmission of authentication creden- tials…), 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 Ver- wendung von Kamera oder Mikrofon und Lautsprecher von Mobilvorrichtung und To- ken (vgl. Abs. 0058). Dem Begriff „sicheres Übertragen“ in Merkmal 1.5 kommt damit eine technische Be- deutung zu. Im Kontext des Streitpatents bedeutet dies, dass eine ausreichend sichere Übertragung der Entsperrantwort gewährleistet werden soll, was die Fachperson zu- mindest 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 bei- Seite 27/88 spielgebend in Absatz 0058 genannt ist, wird die Fachperson insoweit als „sicher“ ver- stehen, als kein direkter externer Zugriff auf diese Kommunikationsverbindung zwi- schen 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 Computer- ressource. 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 Mobil- vorrichtung die an sie übertragene Entsperrantwort unmittelbar verwendet, 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 er- kennen, 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 Computerres- source 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 trag- baren Sicherheitstoken-Vorrichtung authentifizieren. Eine solche Authentifizierung ge- mäß Merkmal 1.7 auf der Mobilvorrichtung ist in Absatz 0030 des Streitpatents be- schrieben (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ät- zen 0062, 0063 und 0064 genannt. Sofern die Authentifizierung auf dem Token erfolgt, muss dieser eine Eingabevorrichtung, beispielsweise ein Display und/oder eine Tas- tatur, aufweisen. Ein Token kann dabei auch ein Smartphone, eine Smartwatch, ein Tablet o. Ä. sein (vgl. Abs. 0065). Seite 28/88 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 Au- thentifizierung auf (on) einem Gerät (Mobilvorrichtung oder Token) nach Merkmal 1.7 nur die Eingabe dieses Nutzergeheimnisses am entsprechenden Gerät, deren Validie- rung 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 Übertra- gung der im Token generierten Entsperrantwort nur bei erfolgreich validierter Authen- tifizierung 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 Entsperrant- wort, 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 val- idated by the token before the decryption operation takes place; sowie Abs. 0041). Zur Vorgehensweise bei nicht erfolgreicher Validierung trifft das Streitpatent keine Aus- sage. 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 Authentifizie- rung 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 Seite 29/88 zwangsläufig eine eigene Tastatur oder andere Eingabemittel, um eine Benut- zerauthentifizierung 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 generier- ten Entsperrantwort den zweiten Teil der Zwei-Faktor-Authentifizierung (two-factor au- thentication) 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, wo- bei das System eine Mobilvorrichtung und wenigstens eine getrennte tragbare Sicher- heitstoken-Vorrichtung umfasst, aber nicht auf diese Vorrichtungen beschränkt ist. Das System umfasst weiterhin Mittel zum Ausführen des Verfahrens nach Patentan- spruch 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 rechtsbe- stä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 An- spruchsbreite Ausführungsbeispiele liefern, solange die Fachperson sinnvolle Ausge- staltungen „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 Seite 30/88 Fachperson ohne erfinderisches Zutun und ohne unzumutbare Schwierigkeiten in der Lage ist, die Lehre des Patentanspruchs auf Grund der Gesamtoffenbarung der Pa- tentschrift in Verbindung mit dem allgemeinen Fachwissen und Fachkönnen so zu ver- wirklichen, dass der angestrebte Erfolg erreicht wird. Dazu genügt es, wenn die Pa- tentschrift 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, Leit- satz 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 – Klammernahtge- rät, juris Leitsatz und Rn. 17). Denn sie entnimmt bereits die zur Ausführung der Erfin- dung in den Ansprüchen regelmäßig nicht vollständig enthaltenen aber für die prakti- sche 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 Token formuliert, 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 Sicherheitsabfra- gen („Super-PIN“, Pass-Phrase oder insbesondere mehreren Authentifizierungsmerk- malen) sowie von Lösungen unter Verwendung von Administratorrechten, bspw. durch den Anbieter des Dienstes oder der Computerressource. Seite 31/88 2. Zur Patentfähigkeit des Streitpatents in der erteilten Fassung Der Gegenstand des Patentanspruchs 1 erweist sich in der erteilten Fassung (Haupt- antrag) 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 An- spruch genommen sind, da sich aus keiner der drei Prioritätsanmeldungen ein Authen- tifizieren eines Benutzers für den Zugriff auf eine Computerressource über eine Mobil- vorrichtung ergibt, bei dem sich der Benutzer auf der wenigstens einen getrennten tragbaren Sicherheitstoken-Vorrichtung authentifizieren muss (Merkmal 1.7, zweite Al- ternative). Diese Frage kann allerdings im Hinblick auf die für die Beurteilung der Patentfähigkeit des Patentanspruchs 1 in erteilter Fassung bedeutsamen Dokumente D1 und D10 da- hinstehen, 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 Do- kument D2 ins Verfahren 4 Ni 41/23 (EP) eingeführte und als Dokument D10 ins Ver- fahren 4 Ni 61/22 (EP) übernommene Dokument). a) Das Dokument D10 befasst sich – wie das Streitpatent – mit dem sicheren Zu- griff auf Computerressourcen, hier insbesondere auf Dateien, die mit einem Datei- schlüssel (file key) K e verschlüsselt sind. Die Entschlüsselung der Datei (file) erfolgt jeweils mit dem entschlüsselten Dateischlüssel. Seite 32/88 Der Dateischlüssel (file key) K e selbst ist durch einen Schlüssel-verschlüsselnden Schlüssel Kk verschlüsselt, der nur durch Verwendung des Tokens entschlüsselt wer- den kann (vgl. Abschnitt 2.2 Key-encrypting keys: In ZIA, each on-disk object is enc- rypted 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 Ke.). Auch zeigt das Dokument D10 eine Zwei-Faktor-Authentifizierung, die eine Authentifi- zierung des Nutzers beim Zugriff auf eine Datei, also beim Zugriff auf eine Computer- ressource darstellt. Denn die Authentifizierung des Nutzers gegenüber dem Token ist Voraussetzung und somit Teil der Authentifizierung zum Zugriff auf diese Computer- ressource (file) unter Verwendung des Tokens, der nur dann eine gültige Entsperrant- wort (File key) aus einer verschlüsselten Ressourcenautorisierung (Encrypted File key) generieren kann, wenn sich der Nutzer mittels eines Codes (PIN) gegenüber dem To- ken identifiziert hat. Damit schaffen nur beide Teile dieser Zwei-Faktor-Authentifizie- rung gemeinsam die Grundlage für das Vorliegen einer validen Entsperrantwort (File Key). Seite 33/88 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: [Die D10 befasst sich mit dem sicheren Zugriff eines Nutzers auf ver- schlü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. Abschnitt 2.2 Key-encrypting keys: In ZIA, each on-disk object is encrypted by some symmetric key, K e. … A token with the appro- priate Kk can decrypt K e, and hence enable reading any file en- crypted by K e.)] 1.2 storing an encrypted resource authorization; [Dokument D10 sieht eine gespeicherte, als „encrypted file key“ be- zeichnete 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 Ab- schnitt 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 re- quired unlock response is valid; [Sofern der richtige Schlüssel (file key Ke) als Entsperrantwort über- mittelt 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 Seite 34/88 token with the appropriate Kk can decrypt K e, and hence enable read- ing 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 to- ken loss is the extraction of key-encrypting keys. PIN-protected, tam- per-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. [Unterstrei- chungen 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. Abschnitt 2.3 Token vulnerabilities: The most serious vulnera- bility surrounding token loss is the extraction of key-encrypting keys. PIN-protected, tamper-resistant hardware [40] makes this more dif- ficult, … ).] 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 Au- thentifizierung 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 kon- kreten 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 Nut- zerauthentifizierung auf dem Token erfolgt, bevor eine Entsperrantwort – also im Fall der D10 ein entschlüsselter Dateischlüssel – vom Token an die Mobilvorrichtung ge- sendet 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, Seite 35/88 dass die Validierung der Nutzerauthentifizierung auf dem Token erfolgt, bevor die Ent- schlü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üsse- lung im Token gemäß der D10 direkt eine Entsperrantwort (file key) erzeugt wird, da Anspruch 1 nur fordert, dass die Entsperrantwort zumindest teilweise auf der ent- schlü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 Vorgehens- weise in Bezug auf Daten im Cache der Mobilvorrichtung nicht im Widerspruch zur Lehre des Streitpatents, da auf der Festplatte der Mobilvorrichtung gespeicherte Da- teien, mithin Computerressourcen im Sinne des Streitpatents, grundsätzlich verschlüs- selt 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 ne- bengeordneten, auf ein System zur Durchführung des Verfahrens gerichteten Pa- tentanspruchs 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) ist neu gegenüber dem Dokument D1 (US 2010/0228991 A1; Bezeichnung als D1 übernommen nachdem das Dokument ur- sprü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. Seite 36/88 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 Com- puter, 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 Seite 37/88 b) Aus Dokument D1 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 Com- puterressource 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 Ressour- cen versteht, wie bspw. in der Verwendung des Begriffs Nutzer- konto (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; [Dokument D1 sieht eine gespeicherte, als „Hidden Secret“ be- zeichnete 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 Er- zeugen 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.5teil securely transmitting the generated unlock response to the mobile device; [Die Entsperrantwort wird über eine USB-Verbindung an das Com- putersystem übertragen (vgl. Abs. 0029: The plain-text, decrypted Seite 38/88 password is given from inside the token, back to the Windows ma- chine 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 der D1 vorgesehene Über- tragung 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 thema- tisiert, versteht die Fachperson diese schon deshalb als “sichere Übertragung”, da eine Übertragung des entschlüsselten Pass- worts vom Token zum Computer über eine nicht „sichere“ Verbin- dung im Widerspruch zur Zielsetzung des Dokuments D1 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 der D1 vorgeschlagene USB-Verbindung – wie auch in Absatz 0058 des Streitpatents beispielgebend vorge- sehen – 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 Res- sourcen 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 Com- puterressource 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 Au- thentifizierung 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).] Seite 39/88 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, be- vor das „Hidden Secret“ zur Entschlüsselung an den Token über- tragen 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).] Dokument D1 zeigt, ebenso wie das Streitpatent, eine Zwei-Faktor-Authentifizierung. Abgesehen davon, dass das Dokument D1 diese Zwei-Faktor-Authentifizierung aus- drücklich so bezeichnet (dual factor method of authentication, vgl. Abs. 0001; dual fac- tor authentication, vgl. Abs. 0009), umfasst die Lehre des Dokuments D1 zwei vonei- nander 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 bereitge- stellt wird (Hidden Secret 10 bzw. encrypted version of the password 10). Beim „Hid- den 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 Entsperrant- wort, dass die Entsperrantwort nach Dokument D1 dem entschlüsselten „Hidden Se- cret“ entspricht. Denn Merkmal 1.4 des Anspruchs 1 des Streitpatents fordert nur, dass die Entsperrantwort zumindest teilweise auf der entschlüsselten Ressourcenautorisie- rung basiert, was auch erfüllt ist, wenn sie vollständig der entschlüsselten Ressour- cenautorisierung 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 com- prise a plain authorization, obtained by decrypting the encrypted authorization, vgl. Streitpatent, Abs. 0025). Seite 40/88 Damit unterscheidet sich Dokument D1 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 Pa- tentanspruchs 9 erweisen sich daher jeweils als neu gegenüber Dokument D1. c) Der jeweilige Gegenstand der Patentansprüche 1 und 9 des Streitpatents ist der Fachperson jedoch ausgehend von Dokument D1 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 An- meldezeitpunkt vom fachmännischen Verständnis der nur allgemein genannten Com- putersysteme von dem Dokument D1 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 Streitpatents sprechen (Merkmale 1.1, 1.5, 1.6, 1.7). Die Gegenstände des auf ein Verfahren gerichteten Patentanspruchs 1 und des ne- bengeordneten, 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 in- soweit 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 Ge- genstand eines Patentanspruchs aus dem von der Patentinhaberin verteidigten An- spruchssatz als nicht patentfähig erweist (vgl. BGH, Urteil vom 13. September 2016 – X ZR 64/14, GRUR 2017, 57 – Datengenerator). Seite 41/88 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ündli- chen 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.2 H1 bezeich- net –, 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 mo- bile 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 pro- vide its own bespoke service for Hoverkey users.). Zum Prioritätszeitpunkt des Streitpatents existierte unstreitig keine einheitliche Defini- tion des Begriffs „Cloud“ in der Literatur. Vielmehr wurde der Begriff unterschiedlich Seite 42/88 verwendet, bspw. im Sinne eines Dienstes, aber auch hinsichtlich dafür geeigneter Hardware-Realisierungen, sowie für lokale (firmeninterne bzw. „private“) Cloud-Lösun- gen bis hin zu Cloud-Diensten im Internet. Mangels Definition und einem nicht klar einzugrenzenden fachmännischen Verständ- nis 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. Insbe- sondere 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 errei- chen sind. 1.2 Die Änderungen in Merkmal 1.2 H1 des Hilfsantrags 1 sind der Figur 6 der ur- sprünglich eingereichten Unterlagen (Stammanmeldung WO 2014/083335 A2, im Ver- fahren 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 Erfindung gehörend zu entnehmen. Denn im Kontext der Gesamtoffenba- rung 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 Speicher- ort im Streitpatent sonst nicht näher spezifiziert ist. Hinsichtlich der ursprünglich nur allgemein genannten Speicherung der verschlüssel- ten Ressourcenautorisierung konkretisiert der Hilfsantrag 1 in Merkmal 1.2 H1 den Spei- cherort 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 Ver- wendung des Begriffs „Cloud“ im Streitpatent erweist sich Anspruch 1 gemäß Hilfsan- trag 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 breit Seite 43/88 gefasst 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 1 ist der Fachperson ausgehend von Dokument D1 (US 2010/0228991 A1) und ihrem Fachwissen nahe- gelegt und beruht nicht auf einer erfinderischen Tätigkeit. Die Lehre der D1 sieht unter anderem vor, dass Ressourcen einschließlich der ver- schlüsselten Nutzerautorisierung (Hidden Secret) auch extern von der Nutzervorrich- tung 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 Vorweg- nahme des Merkmals durch die D1 nicht entgegen, dass das Passwort nach dem Ver- stä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 ver- schlü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 To- ken gemäß Dokument D1, dass das auf dem Server gespeicherte „Hidden Secret“ durch die Mobilvorrichtung (hier: allgemein durch den Computer) abgerufen wird, da Seite 44/88 der dortige Token nur über eine (direkte) USB-Verbindung mit dem Computer verbun- den 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ührun- gen 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ür- fen keiner weiteren, isolierten Prüfung, weil die Beklagte Hilfsantrag 1 als geschlosse- nen Anspruchssatz versteht und das Streitpatent auch insoweit nur als Ganzes vertei- digt; 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 erfinderi- schen 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.1 H2A und 1.6 H2A bezeichnet – auf einem externen Server befindet. Darüber hinaus hat die Beklagte Anspruch 1 ent- sprechend der Alternativen des Merkmals 1.7 in zwei Ansprüche aufgespalten: Seite 45/88 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 re- mote server via a mobile device comprising: 1.2 H1 storing an encrypted resource authorization, wherein the encrypted re- source 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 re- mote 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 erteil- ten Fassung hervorgehobenen Änderungen: 2.1 A method of authenticating a user to access a computer resource via a mo- bile device comprising: 2.2 H1 storing an encrypted resource authorization, wherein the encrypted re- source 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; Seite 46/88 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 re- quired 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 ge- nommen 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 Aus- führungsbeispiel auf Anwendungen als Ressourcen auf einem „application server“ ver- wiesen wird (S. 15, Z. 6). Allerdings erkennt die Fachperson bei einem Ressourcenzu- griff, 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 be- findet. Daher ist die Einschränkung des Speicherorts auf „on the remote server“ in Merkmal 1.1 H2A und 1.6 H2A für die Ressource, auf die zugegriffen werden soll, als ursprungsof- fenbart anzusehen. 2.3 Die Aufspaltung des in der erteilten Anspruchsfassung mit dem als eigenstän- diger 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 Al- ternativen 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). Seite 47/88 Darüber hinaus sind die Patentansprüche 1 und 2 gemäß Hilfsantrag 2A gegenüber beiden Alternativen der erteilten Fassung beschränkt (Merkmale 1.1 H2A , 1.6 H2A und 1.2 H1 sowie 2.2 H1). Schließlich führt auch die unterschiedliche Beschränkung der beiden neu geschaffe- nen 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 Fas- sung 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 nahe- gelegt 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 ei- nem 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.6 H2A : 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 „Entsper- rantwort“) für diesen Speicher bzw. für ein Verzeichnis in diesem Speicher gewährt wird – d. h. aufgrund der Berechtigungen für das genannte Nutzerkonto. Die geänder- ten 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üh- rungen zur Anspruchsfassung nach Hilfsantrag 1 in gleicher Weise. Seite 48/88 Patentanspruch 1 gemäß Hilfsantrag 2 ist daher der Fachperson ausgehend von Do- kument D1 nahegelegt. Die weiteren angegriffenen Patentansprüche in der Fassung nach Hilfsantrag 2A be- dürfen keiner weiteren, isolierten Prüfung, weil die Beklagte Hilfsantrag 2A als ge- schlossenen Anspruchssatz versteht und das Streitpatent auch insoweit nur als Gan- zes verteidigt; dies rechtfertigt, dem Patent in der Fassung nach Hilfsantrag 1 insge- samt den Schutz zu versagen, nachdem sich der Gegenstand eines Patentanspruchs aus dem von der Patentinhaberin verteidigten Anspruchssatz als nicht patentfähig er- weist (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.1 H2B und 1.6 H2B bezeichnet – um eine Anwendung (application) handelt, die sich auf einem externen Server befin- det. Wie bereits in Hilfsantrag 2A wurde Anspruch 1 auch gemäß Hilfsantrag 2B entspre- chend der Alternativen des Merkmals 1.7 der erteilten Fassung in zwei Ansprüche auf- gespalten. 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 re- source on a remote server via a mobile device comprising: Seite 49/88 1.2 H1 storing an encrypted resource authorization, wherein the encrypted re- source 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.1 H2B und 1.6H2B sind zwar nicht an einer kon- kreten Stelle der ursprünglichen Anmeldeunterlagen unmittelbar offenbart. Die Fach- person versteht jedoch die Offenbarung der ursprünglichen Anmeldung und des Streit- patents dahingehend, dass die Erfindung für die Autorisierung zum Zugriff auf jegliche Art von Computerressourcen geeignet sein soll und zwar unabhängig von ihrem Spei- cherort, da das Streitpatent keine technischen Besonderheiten der Ressourcenautori- sierung für bestimmte Arten von Ressourcen oder deren Speicherung voraussetzt. Die Verwendung der verschlüsselten Ressourcenautorisierung ist auch unabhängig da- von, 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. Seite 50/88 Die gemäß Hilfsantrag 2B geänderten Merkmale 1.1 H2B und 1.6 H2B erweisen sich daher als ursprungsoffenbart. 3.3 Wie zu Hilfsantrag 2A dargelegt, ist die Aufspaltung des Merkmals 1.7 der er- teilten 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 nahe- gelegt und beruht nicht auf einer erfinderischen Tätigkeit. Die Lehre der D1 sieht unter anderem vor, dass Ressourcen auch extern von der Nut- zervorrichtung 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 (Merk- mal 1.6 H2A : 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üs- sel 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 auf- grund der Zugriffsberechtigung (Entsperrantwort) für das Nutzerkonto gewä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 ausge- hend von Dokument D1 nahegelegt. Seite 51/88 Die weiteren angegriffenen Patentansprüche in der Fassung nach Hilfsantrag 2B be- dürfen keiner weiteren, isolierten Prüfung, weil die Beklagte Hilfsantrag 2B als ge- schlossenen Anspruchssatz versteht und das Streitpatent auch insoweit nur als Gan- zes verteidigt; dies rechtfertigt, dem Patent in der Fassung nach Hilfsantrag 1 insge- samt den Schutz zu versagen, nachdem sich der Gegenstand eines Patentanspruchs aus dem von der Patentinhaberin verteidigten Anspruchssatz als nicht patentfähig er- weist (vgl. BGH, Urteil vom 13. September 2016 – X ZR 64/14, GRUR 2017, 57 – Da- tengenerator). IV. Zu den Hilfsanträgen 3A 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 3A basiert auf Anspruch 1 gemäß Hilfs- antrag 2A, wobei Merkmal 1.4 – im Folgenden als Merkmal 1.4 H3A bezeichnet – dahin- gehend ergänzt ist, dass es sich beim Erzeugen der Entsperrantwort um eine Berech- nung auf Basis der entschlüsselten Ressourcenautorisierung und weiteren Informatio- nen handelt, wobei die Berechnung eine digitale Signaturfunktion ist. Patentanspruch 1 lautet gemäß Hilfsantrag 3A mit gegenüber Anspruch 1 gemäß er- teilter Fassung hervorgehoben Änderungen: 1.1 H2A A method of authenticating a user to access a computer resource on a re- mote server via a mobile device comprising: Seite 52/88 1.2 H1 storing an encrypted resource authorization, wherein the encrypted re- source 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 re- mote 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 An- sprüche aufgespalten. Patentanspruch 2 gemäß Hilfsantrag 3A entspricht der Anspruchsfassung nach Hilfs- antrag 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 Stammanmel- dung (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Ü. Seite 53/88 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 Ent- schlüsseln der verschlüsselten Ressourcenautorisierung erhalten wurde und weitere Informationen umfasst (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 en- crypted 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.4 H3A wird in der gesamten Stamman- meldung 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 com- prise 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 to- ken 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. Ex- amples include the following: • Example 1: Digital Signature: computation = digital signature function, plain author- ization = private signing key; parameter = hash of message; output = digital signa- ture on message hash • Example 2: Key Derivation: computation = key derivation function; plain authoriza- tion = key derivation master secret; parameters = context information, output length; output = key derived from master secret Seite 54/88 • Example 3: Re-encryption: computation = encryption function; plain authorization = encryption key; parameter = (another) encryption key; output = the plain authoriza- tion encrypted with a different key” Von diesem Beispiel „Example 1“ ist in Merkmal 1.4 H3A nur das Teilmerkmal übernom- men, dass die Berechnung die Anwendung der digitalen Signaturfunktion ist (compu- tation = digital signature function). Diese digitale Signaturfunktion ist aber nur in Ver- bindung 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 Signa- turfunktion 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 ge- bildet 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üs- sel, Parameter und Nachricht sind somit bezüglich der Verwendung einer digitalen Sig- naturfunktion nicht voneinander unabhängig offenbart. Bei Merkmal 1.4 H3A des Patentanspruchs 1 gemäß Hilfsantrag 3A handelt es sich da- her um eine unzulässige Zwischenverallgemeinerung, da die oben wiedergegebene einzige Beschreibung einer „digitalen Signaturfunktion“ in der Stammanmeldung Vor- gaben dazu macht, wie und worauf die digitale Signatur angewandt wird, nämlich durch Verwenden der reinen Ressourcenautorisierung als privater Schlüssel der digi- talen 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 Stamman- meldung subsumieren lässt, findet sich im „Example 1“ die einzige ursprüngliche Of- fenbarungsstelle 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 func- tion), sondern die Ableitung eines Schlüssels (computation = key derivation) und Wie- Seite 55/88 derverschlüsselung (computation = re-encryption) sowie das im Absatz zuvor ge- nannte direkte Verwenden der reinen oder einfachen entschlüsselten Ressourcenau- torisierung (Seite 5, Zeile 28-30: plain authorization). Zwar könnte es sich auch bei einer „Wiederverschlüsselung“, wie sie „Example 3“ be- schreibt, um ein Signieren handeln. Dieses Signieren wird jedoch nicht als digitale Sig- naturfunktion 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 authori- zation“ als Signaturschlüssel vorsieht. Ungeachtet dessen wären auch die Merkmale des „Example 3“ nur unvollständig in den Anspruch 1 gemäß Hilfsantrag 3A übernom- men. 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 Klarheitser- fordernis 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 er- weist sich daher ebenfalls als nicht zulässig. 2.1 Patentanspruch 1 nach Hilfsantrag 3B basiert auf Anspruch 1 gemäß Hilfs- antrag 1, wobei Merkmal 1.4 H3A aus Hilfsantrag 3A in den Anspruch 1 gemäß Hilfsan- trag 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äß er- teilter Fassung hervorgehoben Änderungen: Seite 56/88 1.1 A method of authenticating a user to access a computer resource via a mo- bile device comprising: 1.2 H1 storing an encrypted resource authorization, wherein the encrypted re- source 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 re- quired 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 Merkmalen 1.1 H2A und 1.6 H2A 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 Hilfs- antrag 2A. 2.2 Der Gegenstand des Patentanspruchs 1 gemäß Hilfsantrag 3B ergibt sich nicht zweifelsfrei und eindeutig aus der Stammanmeldung des Streitpatents. Seite 57/88 Anspruch 1 gemäß Hilfsantrag 3B weist – wie bereits gemäß Hilfsantrag 3A – das Merkmal 1.4 H3A in unveränderter Form und ohne weitere Ergänzungen auf. Es gelten daher zu Anspruch 1 gemäß Hilfsantrag 3B die Ausführungen zur fehlenden Ur- sprungsoffenbarung des Merkmals 1.4 H3A zu Hilfsantrag 3A in gleicher Weise: Wie be- reits zu Hilfsantrag 3A ausgeführt, handelt es sich bei Merkmal 1.4H3A des Patentan- spruchs 1 gemäß Hilfsantrag 3B um eine unzulässige Zwischenverallgemeinerung hin- sichtlich der einzigen Beschreibung einer digitalen Signaturfunktion in der Stamman- meldung (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 3C basiert auf Anspruch 1 gemäß Haupt- antrag, 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 3C 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 mo- bile 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; Seite 58/88 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 re- quired 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 An- spruch 1 der Hilfsanträge 3A oder 3B, da die Einschränkungen in Merkmal 1.1 H2A, 1.6 H2A und 1.2 H1 fehlen. 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.4 H3A in unveränderter Form und ohne weitere Ergänzungen auf. Es gelten daher zu Anspruch 1 gemäß Hilfsantrag 3C die Ausführungen zur fehlenden Ur- sprungsoffenbarung des Merkmals 1.4 H3A zu Hilfsantrag 3A in gleicher Weise: Wie be- reits zu Hilfsantrag 3A ausgeführt, handelt es sich bei Merkmal 1.4H3A des Patentan- spruchs 1 gemäß Hilfsantrag 3C um eine Zwischenverallgemeinerung hinsichtlich der Seite 59/88 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 3D umfasst die erstmals in Hilfsantrag 3A verwendete Einschränkungen des Merkmals 1.4 H3A sowie die Beschränkung des Spei- cherorts der Computerressource auf einem externen Server (Merkmale1.1 H2A und 1.6 H2A ). Im Unterschied zu den Hilfsanträgen 3A bis 3C umfasst Hilfsantrag 3D nicht die Auf- spaltung der Alternativen des Merkmals 1.7 der erteilten Fassung in zwei Patentan- sprüche. Patentanspruch 1 lautet gemäß Hilfsantrag 3D mit 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 re- mote 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 per- forming a computation on a plain authorization, obtained by decrypting the Seite 60/88 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 re- mote 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.4 H3A in unveränderter Form und ohne weitere Ergänzungen auf. Es gelten daher zu Anspruch 1 gemäß Hilfsantrag 3D die Ausführungen zur fehlenden Ur- sprungsoffenbarung des Merkmals 1.4 H3A zu Hilfsantrag 3A in gleicher Weise: Wie be- reits zu Hilfsantrag 3A ausgeführt, handelt es sich bei Merkmal 1.4H3A des Patentan- spruchs 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 3D sich 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 bin- nen 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 Seite 61/88 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 Vor- bringen 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äge- rinnen 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 3E umfasst die Beschränkung des Spei- cherorts der Computerressource auf einem externen Server (Merkmale1.1 H2A und 1.6 H2A ) sowie eine gegenüber Merkmal 1.4 H3A der Hilfsanträge 3A bis 3D weitere Kon- kretisierung des Merkmals 1.4 H3E. Im Unterschied zu den Hilfsanträgen 3A bis 3C umfasst Hilfsantrag 3E nicht die Auf- spaltung der Alternativen des Merkmals 1.7 der erteilten Fassung in zwei Ansprüche. Patentanspruch 1 gemäß Hilfsantrag 3E unterscheidet sich von Hilfsantrag 3D (ne- ben 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 per- forming a computation on a plain authorization, wherein the plain authoriza- tion is a private signing key obtained by decrypting the encrypted resource authorization, and additional information, wherein the computation is a digi- tal signature function; Unter dem in Merkmal 1.4 H3E als „plain authorization“ genannten privaten Signatur- schlüssel (private signature key) versteht die Fachperson einen geheimen Signatur- schlüssel, der durch den Nutzer zum Erstellen digitaler Signaturen, also zum Signieren digitaler Daten verwendet wird und der beim Nutzer verbleibt. Ein zugehöriger öffent- Seite 62/88 licher Schlüssel wird verwendet, um die Signatur zu verifizieren (PKI, Public Key Infra- structure). 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üs- selung zum Entschlüsseln der mit einem öffentlichen Schlüssel verschlüsselten digita- len 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.4 H3A gemäß den Hilfsanträgen 3A bis 3D weiter konkretisierte Merkmal 1.4 H3E auf, wonach die „plain authorization“ ein privater Signaturschlüssel ist, der durch Entschlüsseln der ver- schlüsselten Ressourcenautorisierung gewonnen wird (…wherein the plain authoriza- tion is a private signing key obtained by decrypting the encrypted resource authoriza- tion…). 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.4 H3E des Patentanspruchs 1 gemäß Hilfsantrag 3E weiterhin um eine unzulässige Zwischenverallgemeinerung, da die einzige Offen- barungsstelle 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 an- gewandt wird. Schließlich beschreibt Merkmal 1.4 H3E mit der Anwendung der „digitalen Signaturfunk- tion“ auch kein Anwenden einer (Hash-)Funktion einer „plain authorization“ entspre- chend 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. Seite 63/88 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 einge- reichte 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 Vor- bringen zurückzuweisen und bei der Entscheidung unberücksichtigt zulassen. Voraus- setzung 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 Ver- tagung 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.4 H3Ea nach Hilfsantrag 3Ea sieht die Beklagte die Notwendigkeit, auf das erstmals in der mündlichen Verhandlung erkennbar 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 In- halt der Anmeldung in der ursprünglich eingereichten Fassung hinaus. Dies konnte der Senat aus und nach dem bisherigen Vortrag der Parteien beurteilen. Vor diesem Hin- tergrund war es nicht erforderlich, den Klägerinnen die Gelegenheit zu einer weiteren Seite 64/88 Stellungnahme einzuräumen; demnach bestand auch kein Grund die mündliche Ver- handlung zu vertagen. 6.2 Patentanspruch 1 nach Hilfsantrag 3Ea unterscheidet 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 au- thorization 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 in- cluded in the unlock response; Anspruch 1 gemäß Hilfsantrag 3Ea weist gegenüber Anspruch 1 gemäß Hilfsantrag 3E das weiter konkretisierte Merkmal 1.4 H3Ea 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.4 H3Ea 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 deco- dierbar – in der Entsperrantwort enthalten sein soll, sondern allenfalls der Signatur der Entsperrantwort oder von Teilen der Entsperrantwort dient. Dies steht im Einklang da- mit, 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 Sig- naturfunktion“ 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äß Hilfsan- trag 3E weiter konkretisiertes Merkmal 1.4 H3Ea auf, wonach die „plain authorization“ Seite 65/88 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.4 H3Ea 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, wo- nach 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“ [Unterstrei- chung 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 Anspruchs- merkmals) 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.4 H3Ea 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 einge- reichte Hilfsantrag 3Eb war entgegen der Annahme und Rüge der Klägerinnen nicht Seite 66/88 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 gel- ten. 7.2 Patentanspruch 1 nach Hilfsantrag 3Eb umfasst gegenüber dem Hilfsantrag 3Ea eine weitere Konkretisierung des Merkmals 1.4 H3Eb. Patentanspruch 1 gemäß Hilfsantrag 3Eb unterscheidet 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 par- tially therefrom an unlock response, wherein generating the unlock re- sponse comprises performing a computation on a plain authorization, ob- tained 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.4 H3Eb 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 authoriza- tion.). Zwar ist in der Fassung des Merkmals 1.4 H3Eb 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 Seite 67/88 bei der Annahme, dass die „digitale Signaturfunktion“ die Verwendung der „plain au- thorization“ 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.4 H3Eb spricht nur davon, dass die digitale Signaturfunktion auf die „plain authorization“ und die zusätzliche Information ange- wandt 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 digi- tale Signaturfunktion und den Hash-Wert einer Nachricht Bezug nimmt (Stammanmel- dung, S. 6, Zeilen 6 bis 8, Example 1), sieht jedoch nicht vor, dass eine Signaturfunk- tion 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.4 H3Eb gegenüber der Ursprungsoffenbarung unzulässig verallge- meinert. 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 7 gemäß Hilfsantrag 3F geht nicht über den Inhalt der ursprünglichen Anmeldung hinaus, ist so deutlich und vollständig offenbart, dass die Fachperson ihn ausführen kann, und pa- tentfä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äß Hilfsan- trag 3F beruht auch auf einer erfinderischen Tätigkeit, denn aus keinem der im Ver- fahren befindlichen Dokumente ergibt sich ein Verfahren gemäß dem Patentan- spruch 1 bzw. ein System gemäß dem Patentanspruch 7 für die Fachperson in nahe- liegender Weise. Seite 68/88 1. Soweit die Klägerinnen – zuletzt in der mündlichen Verhandlung – die Ver- spätung von Hilfsantrag 3F gerügt haben, u. a., weil „erst in der mündlichen Ver- handlung das Verständnis der Beklagten hinsichtlich dieser Hilfsanträge deutlich ge- worden 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 3F war 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 Vorbrin- gen – neue Angriffs- und Verteidigungsmittel, eine Klageänderung oder eine Verteidi- gung 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 ent- schuldigt 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 Moder- nisierung des Patentrechts, BlPMZ 2009, 307, 315). Selbst für das nach Fristset- zung 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 ein- bezogen 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). Seite 69/88 Der weitere Hilfsantrag 3F ist bereits fristgemäß am Tag des Ablaufs der auf den qua- lifizierten Hinweis gesetzten bzw. verlängerten weiteren (zweiten) Frist zur Stellung- nahme auf das Vorbringen der Gegenseite, nämlich am 31. Januar 2025, eingegan- gen. In Bezug auf den weiteren Hilfsantrag 3F bestand 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 Vor- bereitung ihres Vorbringens in der mündlichen Verhandlung, sondern auch zur schrift- sätzlich vollinhaltlichen Stellungnahme. Dies haben sie mit ihren diesbezüglichen aus- führlichen Darlegungen in ihren Schriftsätzen vom 11. März 2025 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 3C zur 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 3F umfasst eine Definition des Speicher- orts der Computerressource auf einem externen Server (Merkmale 1.1 H2A und 1.6 H2A ) sowie eine weitere Konkretisierung des Merkmals 1.4 H3F gegenüber der Fassung ge- mäß Hilfsantrag 3E. Patentanspruch 1 gemäß Hilfsantrag 3F unterscheidet 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 au- thorization 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; Seite 70/88 Der dem Patentanspruch 1 nebengeordnete Patentanspruch 7 gemäß Hilfsantrag 3F entspricht 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.4 H3F versteht die Fachperson den privaten Signaturschlüs- sel (private signature key), der als „plain authorization“ durch Entschlüsselung der ver- schlü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 mes- sage 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.4 H3F ist 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 Merk- mal 1.4 H3F das „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.4 H3F : „the computation is a digital signature function on a message hash“) im Ergeb- nis 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.1 H2A und 1.6 H2A für die Ressource, auf die zuge- griffen werden soll, ist ebenfalls als ursprungsoffenbart anzusehen (vgl. Ausführungen zu Hilfsantrag 2A). Seite 71/88 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. nach- arbeitbar 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 ver- schlü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.4 H3F in der Fassung des Hilfsan- trags 3F nunmehr beschränkt ist. Die zugrundeliegende Nachricht, auf deren Hash-Wert gemäß Hilfsantrag 3F die Sig- naturfunktion 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.1 H2A ), während der Hash-Wert das Prüfen der Integrität der Nachricht (im Sinne der Gültigkeit der Entsperrantwort nach Merkmal 1.6 H2A ) ermöglicht. Dies ergibt sich für die Fachperson hinreichend klar und insbesondere nacharbeitbar aus der Be- schreibung des „Example 1“ und der Zielsetzung des Streitpatents, eine Authentifizie- rung des Nutzers beim Zugriff auf eine Computerressource zu ermöglichen. 5. Der jeweilige Gegenstand der nebengeordneten Patentansprüche 1 und 7 ge- mäß 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. Seite 72/88 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 – insbe- sondere 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.4 H3F (…performing a computation on a plain authorization, obtained by decrypting the encrypted resource authorization, and … additional information, wherein the com- putation is a digital signature function …). Dokument D1 betrifft das Bereitstellen einer Zwei-Faktor-Authentifizierung unter Ver- wendung 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 Se- cure Systems, which could be computers, servers, other data storage devices or facil- ities, each requiring a unique password, without the usual requirement for storing each password inside of the security token.). Dokument D1 befasst sich somit mit der siche- ren 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 aus- gehend von der D1 keine Veranlassung, von einer Passwort-Verwaltung zur Verwen- dung von Signaturen zu wechseln. Es besteht ausgehend von der D1 auch keine Veranlassung der Fachperson zur (zu- sätzlichen) Verwendung einer Signaturfunktion bei der Übertragung der Entsperrant- wort vom Token zum Computer, da die USB-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 Seite 73/88 entschlüsselten verschlüsselten Ressourcenautorisierung anzuwenden. Denn die D15 weist nur allgemein auf die Möglichkeit hin, an Stelle eines Schlüssels zum Ermögli- chen 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 Berech- nung in Form einer digitalen Signaturfunktion gemäß Hilfsantrag 3F auf 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 aus- gehend 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 nahe- gelegt. 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 Do- kument D1 im 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 Entsper- rantwort (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 Interak- tion besagt gerade nicht, dass es bei einer falschen Passwort-Eingabe zu keiner Inter- aktion mit der Mobilvorrichtung kommt, sondern dass in diesem Fall keine der folgen- den Interaktionen erfolgreich abgeschlossen werden kann (D9, S. 1787, rechte Spalte, Seite 74/88 Abschnitt B. Wearable token loss concern: …else the wearable token derives a wrong value and cannot successfully complete any following interaction with the mobile de- vice [Unterstreichung hinzugefügt]). Ungeachtet dessen befasst sich Dokument D9 nur mit der Schlüsselverwaltung für ein lokales verschlüsseltes Dateisystem einer 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 (cryp- tographic files) entschlüsseln zu können (vgl. S. 1787, Fig. 4 Key management model; sowie Beschreibung, S. 1786, rechte Spalte bis S. 1787, Abschnitt C. Key Manage- ment Principle): Darüber hinaus unterscheidet sich der Gegenstand des Patentanspruchs 1 nach Hilfs- antrag 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.4 H3F (…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 (Root key), mit dem Dateischlüssel verschlüsselt sind (Encrypted file key) und die nur unter Verwendung Seite 75/88 des auf einem tragbaren Token (Wearable token) bereitgestellten „Root key“ ent- schlü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.4 H3F – hier des entschlüsselten, mit dem „Root key“ verschlüsselten „File key“ – 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 Nach- richt im Token heranzuziehen. Daneben ist der D9 kein Ermöglichen des Zugriffs auf externe, auf einem Server be- findliche Dateien im Sinne der Merkmale 1.1H2A und 1.6 H2A 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 Zu- griff 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 nahe- gelegt. 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 Dokument D9 – in der Anwendung einer digitalen Signaturfunktion (digital signa- ture 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.4 H3F (…wherein generating the unlock response comprises performing a computation on a plain authorization, wherein Seite 76/88 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üs- selverschlüsselungs-Schlüssels“ (Key-Encrypting Key), mit dem Dateischlüssel (File Key) verschlüsselt sind und die nur unter Verwendung des auf einem Token bereitge- stellten „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.4 H3F – 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 ent- schlüsselten verschlüsselten „File Key“ mittels eines separaten Tokens diesen Schlüs- sel zur Signatur des Hash-Werts einer Nachricht im Token heranzuziehen. Daneben ist der D10 kein Ermöglichen des Zugriffs auf externe, auf einem Server be- findliche Dateien im Sinne der Merkmale 1.1 H2A und 1.6 H2A 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üs- selten „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 Wesentli- chen 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. Seite 77/88 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 aufzube- wahren, der nach der Authentifizierung des Nutzers zum Entschlüsseln von E-Mails verwendet werden kann (Abs. 0018). Zwar ist Dokument D21 auch zu entnehmen, eine digitale Signatur für eine zu versendende Ressource (E-Mail-Nachricht) aus ei- nem Hash-Wert der Nachricht und dem privaten Signaturschlüssel, der im Token ge- speichert ist, im Token zu erzeugen (Abs. 0019). Dieser private Signaturschlüssel ge- mäß Absatz 0019 der D21, der von der Verwendung eines privaten (Entschlüsse- lungs-)Schlüssel zum lokalen Entschlüsseln einer E-Mail nach Absatz 0018 zu unter- scheiden ist, entspricht aber bereits aufgrund seiner Speicherung im Token nicht der entschlüsselten, vom Token in verschlüsselter Form empfangenen Ressourcenauto- risierung. 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.1 H2A , 1.6 H2A ). Eine Veranlassung der Fachperson, die Abläufe zur Signatur einer E-Mail auf das Er- zeugen 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 Ab- läufe zum Entschlüsseln einer empfangenen E-Mail abzuwandeln und auf das Versen- den einer E-Mail anzuwenden und das Signieren der Nachricht vorzusehen, die als „Entsperrantwort“ den Zugriff auf eine (nach Merkmal 1.1 H2A/1.6 H2A extern) gespei- cherte 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 na- hegelegt. Seite 78/88 5.5 Die Lehre des Dokuments D4 (Hallsteinsen) unterscheidet sich vom Gegen- stand des Patentanspruchs 1 bereits dadurch, dass keine Übertragung des geheimen Schlüssels an den Token im Sinne von Merkmal 1.3 stattfindet. Vielmehr werden Da- ten ü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-Verbin- dung übertragen und von dort an den Authentifizierungsserver des Dienstanbieters weitergeleitet (vgl. 5. Seite, re. Spalte, Kap. VI. A. Java Midlet, Abschnitt OTP genera- tion, 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.4 H3F zu entnehmen. Der Gegenstand des Patentanspruchs 1 gemäß Hilfsantrag 3F erweist sich daher als neu gegenüber der Entgegenhaltung D4. Ein Naheliegen des Patentanspruchs 1 aus- gehend von der D4 haben die Klägerinnen bereits im Hinblick auf die erteilte An- spruchsfassung nicht geltend gemacht und ist im Hinblick auf Patentanspruch 1 ge- mäß Hilfsantrag 3F auch nicht ersichtlich. Insbesondere ist ausgehend von der Gene- rierung eines Einmalpassworts in der D4 kein Anlass zur Anwendung einer digitalen Signaturfunktion entsprechend Merkmal 1.4 H3F 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 Ressour- cenautorisierung“ 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 „Ser- ver 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 Seite 79/88 Teil) die Entsperrantwort erzeugt wird, auch wenn bspw. die Transaktionssignatur un- ter Verwendung der übermittelten Transaktionsdaten erzeugt wird (vgl. bspw. Sp. 8, Z. 37-41). Zwar erfolgt als Voraussetzung für die Passwort- bzw. Signaturerzeugung eine Au- thentifizierung 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 ei- ner Entsperrantwort (PIN bzw. Transaktionssignatur) ist. Merkmal 1.8 ist jedoch allen- falls teilweise erfüllt, da der Token nach Dokument D6 keine Entsperrantworten ver- sendet. Darüber hinaus zeigt Dokument D6 auch kein Anwenden einer digitalen Signaturfunk- tion auf den Hash-Wert einer Nachricht gemäß Merkmal 1.4 H3F und liefert der Fach- person 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 er- teilte Anspruchsfassung geltend gemacht wurde, fehlt es bereits aufgrund der unter- schiedlichen Konzepte und der dafür verschiedenen Hardwareanforderungen an einer Veranlassung für die Fachperson, um dadurch einzelne Merkmale der beiden Doku- mente 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 nahe- gelegt. 5.7 Das Dokument D15 (Lu) sieht eine Methode für den Zugriff auf Cloud-Compu- ting-Ressourcen, bspw. eine Web-Anwendung in einer Cloud, über eine Anwendungs- programmierschnittstelle („API“) vor, bei der jede API-Anforderung einer Client-An- wendung eine Client-Authentifizierung gegenüber dem Cloud-Dienst umfassen muss. Die D15 sieht dabei abweichend vom Streitpatent vor, dass eine verschlüsselte Res- sourcenautorisierung 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. Seite 80/88 Zudem ist die Anwendung der Lehre der D15 auf einer Mobilvorrichtung nicht vorge- sehen (S. 37, Kap. 7, vorl. Abs.). In der D15 ist zwar allgemein auf die Möglichkeit hingewiesen, an Stelle eines Schlüs- sels 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üs- selten 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 Pa- tentanspruchs 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 (An- lage 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ätsanmel- dung, aber vor dem Anmeldetag des Streitpatents veröffentlichten Dokumente D2 (WO 2013/167 043 A2), D3 (Anlagenkonvolut hoverkey.com) oder D5 (Clark: Hov- erkey adds NFC security to Android apps) nahegelegt wird. So sieht Dokument D2 (WO 2013/167 043 A2) bereits keine Mehrfaktorenauthentifi- zierung für den Zugriff auf die Computerressource vor, denn für den Zugriff auf eine Computerressource reicht hier das Vorliegen der als Token fungierenden Mobilvorrich- tung alleine aus. Das Setzen und Erzeugen des auf dem Mobilgerät (= Token) gespei- cherten Passworts unter Verwendung eines Superpassworts umfasst zwar auch eine Seite 81/88 Nutzer-Authentifizierung. Diese Authentifizierung wird jedoch nicht im Sinne von Merk- mal 1.8 nach Hilfsantrag 3F im Rahmen der Erzeugung und Übertragung der Entsper- rantwort validiert. Das Superpasswort spielt vielmehr nur bei der (ggf. einmaligen) Ein- richtung des Tokens eine Rolle. Dem Dokumentenkonvolut D3 zum Hoverkey-System ist kein Validieren der Benut- zerauthentifizierung (PIN-Eingabe nach Merkmal 1.7) auf dem Token zu entnehmen. Somit fehlt es der D3 bereits an der anspruchsgemäßen Voraussetzung der verifizier- ten 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.4 H3F 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 Pa- tentanspruchs 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 einzel- nen Merkmalen oder angegriffenen Unteransprüchen sowie zum Beleg des Fachwis- sens 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 Dokument D7 (WO 2008/147457 A1) betrifft eine NFC-Smartcard mit Mitteln zur biometrischen Authentifizierung eines Nutzers, Dokument D8 (DE 10 2009 040 009 A1) befasst sich mit der 2-Faktor-Authentifizierung mittels einer NFC-Smartcard zur Seite 82/88 manipulationssicheren Verschlüsselung für Online-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 Nut- zers. Die Dokumente D12 (Stanoevska-Slabeva et al.) und D17 (Sosinski B.) hat die Klä- gerin zu 2 und die Dokumente D13 (Grandison et al.) und D14 (Grossmann) die Klä- gerin zu 1 zum Beleg des fachmännischen Verständnisses des Begriffs „Cloud“ ge- nannt. 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 1 nur in Zusammenschau mit dem jeweiligen Dokument D9 und D10 ge- nannt. Dokument D20 (MA D., et al.) hat die Klägerin zu 2 nur in Zusammenschau mit dem Dokument D21 genannt. Dokument D22 (Kramp et al.) betrifft die sichere Authentifizierung beim Online-Ban- king. Die D22 hat die Klägerin zu 1 im Zusammenhang mit der Nutzerautorisierung zum Zugriff auf Anwendungen auf einem Server bzw. auf Webanwendungen, das di- gitale Signieren mittels Smartcard sowie hinsichtlich Zertifikaten als möglichen Anwen- dungskennungen genannt. Dokument D22 führt hinsichtlich der Anwendung einer digitalen Signaturfunktion nach Anspruch 1 gemäß Hilfsantrag 3F auch ausgehend von einem der weiteren Doku- mente D1, D10 oder D21 nicht naheliegend zum Gegenstand des Hilfsantrags 3F, da Seite 83/88 Dokument D22 nur die Verwendung eines Tokens (Smartcard) als Träger eines Sig- naturschlüssels (und -zertifikates) lehrt (vgl. D22, Fig. 5 mit Beschreibung), das abwei- chend von der Lehre des Streitpatents einerseits die Speicherung von Authentifizie- rungs- und Signaturschlüsseln auf dem Token vorsieht und andererseits dessen Ein- satz die Verwendung eines zusätzlichen, zur Mobilvorrichtung externen Kartenlesege- rätes voraussetzt. Auch Dokument D23 (US 2008/0065892 A1) 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 Mobil- vorrichtung des Nutzers gespeichert. Dokument D23 führt somit hinsichtlich der An- wendung 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 (EP 1 552 661 B1) haben die Klägerinnen insbesondere im Hin- blick auf die Nutzer-Authentifizierung beim Zugriff auf Anwendungen und die Verwen- dung 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.4 H3F auf den Hash-Wert ei- ner Nachricht angewendet wird. Auch in Dokument D25 (US 8 065 718 B2) wird eine digitale Signatur beschrieben. Zur Authentifizierung des Nutzers erfolgt in einem Token (Hardware token) die Signa- tur 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. Seite 84/88 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 ent- hält, sondern als Entsperrantwort stattdessen den Hash-Wert einer nicht näher defi- nierten Nachricht zu signieren. Umgekehrt ist bei der Verwendung des Tokens nach Dokument D25 keine Veranlassung ersichtlich, für das Durchführen einer Signatur mit- tels Token einen verschlüsselten privaten Signaturschlüssel erst an den Token zu übermitteln, um diesen dann zur Verwendung bei der Signatur einer Challenge- Response-Antwort zu entschlüsseln, da der Token nach der D25 ohne erkennbare weitere Maßnahmen selbstständig bei Übermittlung der Challenge-Response-Ant- wort R‘ die Signatur durchführen kann. Dokument D25 führt somit hinsichtlich der An- wendung einer digitalen Signaturfunktion nach Anspruch 1 gemäß Hilfsantrag 3F auch in Zusammenschau mit einem der weiteren Dokumente D1, D10 oder D21 nicht nahe- liegend 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 auf DRM-Daten genannt, die verschlüsselt in der Cloud vorgehalten und mittels eines Tokens ent- schlüsselt werden, womit die Inhalte, welche durch die DRM-Daten verwaltet werden, auf einer Mobilvorrichtung verwendet werden können. Nachrichten, mit denen die ver- schlüsselten DRM-Daten übermittelt werden, enthalten wiederum die Schlüssel zum Entschlüsseln der DRM-Daten (vgl. D27, Abs. 0031), wobei die DRM-Daten für An- wendungen 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 D27 haben die Klägerinnen nicht geltend gemacht und ist für den Senat auch nicht ersichtlich. Seite 85/88 Der Gegenstand des Patentanspruchs 1 nach Hilfsantrag 3F ist 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 Pa- tentanspruch 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ück- bezogenen Ansprüche 2 bis 6 und 8 bis 13. B. 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 Par- teien. Dabei hat der Senat berücksichtigt, dass der Schutzumfang des nach dem Hilfs- antrag 3F eingeschrä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 Signa- turschlüssel, sowie deren Weitergabe im Klartext oder in wiederverschlüsselter Form und nicht nur als privaten Schlüssel beim Durchführen einer Signaturfunk- tion durch den Token (Merkmal 1.4 H3F ), sowie - der Verwendung des beanspruchten Verfahrens auch für lokal gespeicherte Computerressourcen und nicht nur für solche, die auf externen Servern gespei- chert sind (Merkmale 1.1 H2A ; 1.6 H2A ), einen wesentlich größeren Schutzumfang auf. Den infolge der Änderung reduzierten, verbleibenden Schutzumfang schätzt der Senat auf 1/4 des Streitpatents. Seite 86/88 Da die mit Hilfsantrag 3F verteidigte Fassung zu einer erheblichen inhaltlichen Be- schrä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. C. Rechtsmittelbelehrung Gegen dieses Urteil ist das Rechtsmittel der Berufung gegeben. Die Berufungsschrift, die auch als elektronisches Dokument eingereicht werden kann, muss von einer in der Bundesrepublik Deutschland zugelassenen Rechtsanwältin oder Patentanwältin oder von einem in der Bundesrepublik Deutschland zugelassenen Rechtsanwalt oder Patentanwalt unterzeichnet oder im Fall der elektronischen Einrei- chung nach den hierfür geltenden gesetzlichen Bestimmungen elektronisch signiert sein, d. h. mit einer qualifizierten elektronischen Signatur nach dem Signaturgesetz oder mit einer fortgeschrittenen elektronischen Signatur versehen sein, die von einer internationalen Organisation auf dem Gebiet des gewerblichen Rechtsschutzes her- ausgegeben wird und sich zur Bearbeitung durch das jeweilige Gericht eignet. Die Berufungsschrift muss die Bezeichnung des Urteils, gegen das die Berufung gerichtet wird, sowie die Erklärung enthalten, dass gegen dieses Urteil Berufung eingelegt werde. Mit der Berufungsschrift soll eine Ausfertigung oder beglaubigte Abschrift des angefochtenen Urteils vorgelegt werden. Die Berufungsschrift muss innerhalb eines Monats schriftlich beim Bundesgerichtshof, Herrenstraße 45a, 76133 Karlsruhe eingereicht oder als elektronisches Dokument in Seite 87/88 die elektronische Poststelle des Bundesgerichtshofes (Informationen unter www.bun- desgerichtshof.de/erv.html) übertragen werden. Die Berufungsfrist beginnt mit der Zu- stellung des in vollständiger Form abgefassten Urteils, spätestens aber mit dem Ablauf von fünf Monaten nach der Verkündung. Die Frist ist nur gewahrt, wenn die Berufung vor Fristablauf beim Bundesgerichtshof eingeht. Werner Kätker Altvater Matter Tischler Seite 88/88 Bundespatentgericht 4 Ni 61/22 (EP) (Aktenzeichen) An Verkündungs Statt zugestellt am 1. September 2025 …