{"id":8823,"date":"2021-11-08T17:00:20","date_gmt":"2021-11-08T17:00:20","guid":{"rendered":"https:\/\/www3.hhu.de\/duesseldorfer-archiv\/?p=8823"},"modified":"2021-11-08T20:30:08","modified_gmt":"2021-11-08T20:30:08","slug":"i-2-u-9-17-mobiletan","status":"publish","type":"post","link":"https:\/\/d-prax.de\/?p=8823","title":{"rendered":"I \u2013 2 U 9\/17 – mobileTAN"},"content":{"rendered":"

D\u00fcsseldorfer Entscheidungen Nr. 3150
\n<\/strong><\/p>\n

Oberlandesgericht D\u00fcsseldorf<\/p>\n

Urteil vom 02. September 2021, Az. I – 2 U 9\/17<\/p>\n

Vorinstanz: 4b O 176\/11 <\/p>\n

    \n
  1. I. Auf die Berufung wird das am 17. Januar 2017 verk\u00fcndete Urteil der 4b Zivilkammer des Landgerichts D\u00fcsseldorf abge\u00e4ndert.<\/li>\n
  2. Die Klage wird abgewiesen.II. Die Kl\u00e4gerin hat die Kosten des Rechtsstreits erster und zweiter Instanz zu tragen.<\/li>\n
  3. III. Dieses Urteil ist f\u00fcr die Beklagte wegen ihrer Kosten vorl\u00e4ufig vollstreckbar.<\/li>\n
  4. Die Kl\u00e4gerin kann die Zwangsvollstreckung der Beklagten durch Sicherheitsleistung in H\u00f6he von 120 % des vollstreckbaren Betrages abwenden, wenn nicht die Kl\u00e4gerin vor der Zwangsvollstreckung Sicherheit in H\u00f6he von 120 % des jeweils zu vollstreckenden Betrages leistet.<\/li>\n
  5. IV. Die Revision wird nicht zugelassen.<\/li>\n
  6. V. Der Streitwert des Berufungsverfahrens wird auf 500.000,- \u20ac festgesetzt.<\/li>\n
  7. Gr\u00fcnde<\/strong><\/li>\n
  8. I.<\/li>\n
  9. Die Kl\u00e4gerin nimmt die Beklagte wegen Verletzung des deutschen Teils des europ\u00e4ischen Patents EP 1 259 XXA (nachfolgend: Klagepatent) auf Unterlassung, Rechnungslegung, Erstattung vorgerichtlicher Kosten sowie auf Feststellung der Schadenersatz- und Entsch\u00e4digungspflicht dem Grunde nach in Anspruch.<\/li>\n
  10. Das Klagepatent wurde am 22. April 2002 unter Inanspruchnahme der Priorit\u00e4t der AT 6512XXB vom 23. April 2XXB in deutscher Sprache angemeldet. Die Offenlegung der Patentanmeldung erfolgte am 20. November 2002. Der Hinweis auf die Erteilung des Klagepatents wurde am 26. Oktober 2005 ver\u00f6ffentlicht. Das Klagepatent ist in Kraft.<\/li>\n
  11. Mit Entscheidung vom 28. Juni 2012 (Anlage rop 6) wies die Technische Beschwerdekammer des Europ\u00e4ischen Patentamtes den Einspruch einer \u00f6sterreichischen Bank in letzter Instanz zur\u00fcck. Eine Nichtigkeitsklage der Beklagten blieb ebenfalls in beiden Instanzen erfolglos (Urteil des Bundespatentgerichts vom 11.09 2017, Anlage BK 3; Urteil des Bundesgerichtshofs vom 01.10 2019 \u2013 X ZR 139\/17).<\/li>\n
  12. Gemeinsame Inhaber des Klagepatents waren zun\u00e4chst \u201eB\u201c und \u201eC\u201c. Nachdem \u00fcber das Verm\u00f6gen des letzteren im Jahr 2004 der Konkurs nach \u00f6sterreichischem Recht er\u00f6ffnet wurde, \u00fcbertrug der Masseverwalter mit Vereinbarung vom 07. bzw. 13.09.2004 (Anlage rop 2) alle Rechte und Pflichten von Herrn \u201eC\u201c aus der dem Klagepatent zugrundeliegenden Patentanmeldung auf Herrn \u201eB\u201c. Dieser erteilte der Kl\u00e4gerin mit Vereinbarung vom
    \n03.12.2014 (Anlage rop 4) eine den deutschen Teil des Klagepatents betreffende ausschlie\u00dfliche Lizenz und trat s\u00e4mtliche Entsch\u00e4digungs- und Schadenersatzanspr\u00fcche sowie Auskunfts- und Rechnungslegungsanspr\u00fcche, die ihm auf der Grundlage des deutschen Teils des Klagepatents zustehen, an die Kl\u00e4gerin ab. Schlie\u00dflich \u00fcbertrug Herr \u201eB\u201c das Klagepatent am 16. M\u00e4rz 2016 auf die Kl\u00e4gerin.<\/li>\n
  13. Das Klagepatent tr\u00e4gt die Bezeichnung \u201eAnlage f\u00fcr die sichere Durchf\u00fchrung von Transaktionen mittels mehrerer Authentifizierungscodes\u201c. Sein hier allein streitgegenst\u00e4ndlicher Patentanspruch 1 ist wie folgt gefasst:<\/li>\n
  14. \u201eAnlage f\u00fcr die sichere Durchf\u00fchrung von Transaktionen zwischen informationsverarbeitenden Systemen mit einem Terminal (102), das zur Eingabe einer Benutzerkennung dient, mit einer Auswerteeinheit (106), die mit dem Terminal (102) \u00fcber ein prim\u00e4res Netz (101) verbunden ist, und im Wesentlichen aus einer Speicher- und Prozessoreinheit besteht, welche zur Speicherung von Benutzerstammdaten und laufenden Transaktionsdaten dient, mit einem Codegenerator, der einen Sicherheitscode erzeugt, mit einer Sendeeinrichtung, die den Sicherheitscode \u00fcber ein sekund\u00e4res Netz (107) an ein Empfangsger\u00e4t (108) sendet, und mit einer Eingabem\u00f6glichkeit f\u00fcr den Sicherheitscode am Terminal und einer \u00dcberpr\u00fcfung des eingegebenen Sicherheitscodes auf G\u00fcltigkeit durch die Auswerteeinheit (106),<\/li>\n
  15. dadurch gekennzeichnet, dass<\/li>\n
  16. die Auswerteeinheit (106) einen zus\u00e4tzlichen Codegenerator zur Erstellung eines Zusatzcodes aufweist und eine zus\u00e4tzliche Sendeeinrichtung zur \u00dcbermittlung des Zusatzcodes \u00fcber das prim\u00e4re Netz (101) an das Terminal (102) und zur Ausgabe des Zusatzcodes aufweist, wobei das Terminal neben der Eingabem\u00f6glichkeit des Sicherheitscodes eine Ausgabe- und Eingabem\u00f6glichkeit f\u00fcr den Zusatzcode aufweist und die Auswerteeinheit (106) derart ausgestaltet ist, dass diese den eingegebenen Zusatzcode \u00fcberpr\u00fcft und bei G\u00fcltigkeit von eingegebenem Sicherheitscode und Zusatzcode die Transaktion autorisiert.\u201c<\/li>\n
  17. Die nachfolgend verkleinert wiedergegebenen und zum besseren Verst\u00e4ndnis mit zus\u00e4tzlichen Bezeichnungen versehenen Figuren 1 und 2 der Klagepatentschrift erl\u00e4utern die Erfindung anhand eines bevorzugten Ausf\u00fchrungsbeispiels. Figur 1 gibt eine schematische Darstellung wieder und Figur 2 ein Ablaufdiagramm.<\/li>\n
  18. <\/li>\n
  19. Bei der Beklagten handelt es sich um ein Kreditinstitut. Sie betreibt im Rahmen ihrer T\u00e4tigkeit in der Bundesrepublik Deutschland eine Online-Banking-Plattform (nachfolgend: angegriffene Ausf\u00fchrungsform). Es handelt sich dabei um eine Webanwendung, die von den Servern des zentralen Rechenzentrums der Beklagten angeboten wird und von einem Webbrowser als Client-Programm auf dem Bildschirm eines internetf\u00e4higen Ger\u00e4tes dargestellt und durch entsprechende Eingaben bedient werden kann. Die Kunden haben \u00fcber die Plattform der Beklagten, die \u00fcber die Internetadresse \u201ehttps:\/\/www.\u201cD\u201c.de\u201c sowie bei mobilen Ger\u00e4ten \u00fcber eine App-Oberfl\u00e4che erreichbar ist, insbesondere die M\u00f6glichkeit, Transaktionen, wie z.B. eine \u00dcberweisung, per \u201emobileTAN\u201c zu autorisieren. Dabei wird dem Bankkunden zur Autorisierung einer beantragten Transaktion per SMS eine \u201emobileTAN\u201c zugesandt, die dieser in ein daf\u00fcr vorgesehenes Feld auf der Benutzeroberfl\u00e4che eingibt. Au\u00dferdem wird vom Server an den Client ein HTML-Code \u00fcbertragen, der eine Internetseite anzeigt, wie sie aus der nachfolgend verkleinert eingeblendeten, der Anlage rop 8 entnommenen Abbildung ersichtlich ist:<\/li>\n
  20. <\/li>\n
  21. Die Internetseite bietet die M\u00f6glichkeit zur Eingabe der \u201emobileTAN\u201c. Das Dr\u00fccken des \u201eWeiter-Buttons\u201c (\u201ePfeil-nach-rechts\u201c) f\u00fchrt dazu, dass eine G\u00fcltigkeitspr\u00fcfung durchgef\u00fchrt und \u2013 je nach dem erzielten Ergebnis \u2013 die \u00dcberweisung best\u00e4tigt oder abgelehnt wird.<\/li>\n
  22. In den HTML-Code eingebettet ist unter anderem der Parameter \u201ejavax.faces.portletbridge.STATE_ID\u201c. Bei ihm handelt es sich um ein verstecktes, f\u00fcr den Kunden nicht sichtbares Feld. Der Server der Beklagten erstellt einen Wert f\u00fcr den Parameter. Dieser Parameterwert wird im HTML-Code vom Server der Beklagten zum Terminal des Kunden \u00fcbermittelt. Zur\u00fcckgesandt wird der Wert vom Terminal des Bankkunden zum Server der Beklagten gemeinsam mit der \u201emobileTAN\u201c in einem sog. POST (Aktion \u201eueberweisung.jsf\u201c). Stimmt der Wert des Parameters, der vom Terminal an den Server zur\u00fcckgeschickt wird, nicht mit dem Wert des Parameters \u00fcberein, der zuvor von dem Server erstellt worden ist, wird die Transaktion trotz korrekter \u201emobileTAN\u201c nicht ausgef\u00fchrt, sondern dem Kunden eine Fehlermeldung angezeigt.<\/li>\n
  23. Nach Auffassung der Kl\u00e4gerin verletzt die Beklagte das Klagepatent durch den Gebrauch der angegriffenen Ausf\u00fchrungsform in der Bundesrepublik Deutschland wortsinngem\u00e4\u00df. Sie mahnte die Beklagte daher mit anwaltlichem Schreiben vom 11.03.2015 unter Hinweis auf die Mitwirkung von Patentanwalt Dr. \u201eE\u201c unter Fristsetzung bis zum 07.04.2015 ab und forderte die Beklagte zur Abgabe einer Unterlassungserkl\u00e4rung auf. F\u00fcr die Abmahnung entstanden der Kl\u00e4gerin Rechts- und Patentanwaltskosten in H\u00f6he von 12.912,- \u20ac. Da die Beklagte nicht einlenkte, verfolgt die Kl\u00e4gerin ihr Anspruchsbegehren im Klagewege weiter.<\/li>\n
  24. Die Beklagte hat eine Verletzung des Klagepatents bestritten und erstinstanzlich geltend gemacht, erfindungsgem\u00e4\u00df m\u00fcsse der Zusatzcode dem Nutzer zwingend zur Kenntnis gebracht (Ausgabe) und vom Nutzer auch wieder \u00fcber das Terminal eingegeben werden (Eingabe). Dies sei bei der angegriffenen Ausf\u00fchrungsform nicht der Fall. Das Feld \u201ejavax.faces.portletbridge.STATE_ID\u201c sei ein verstecktes, d.h. f\u00fcr den Nutzer nicht sichtbares Feld in einer HTML-Seite, das beim Zusammenspiel der beiden Framework-Standards JavaServer Faces (JSF) und Portlet Technologie der Programmiersprache Java genutzt werde. Konkret \u00fcbernehme das Feld und der dort eingesetzte Parameterwert die Aufgabe, die aus unterschiedlichen Applikationen erzeugten Teile der dem Bankkunden angezeigten HTML-Seite eindeutig zu kennzeichnen und zusammenzuf\u00fchren, damit sie bei der R\u00fccksendung durch den Kunden wieder diesem und der Online-Session eindeutig zugeordnet werden k\u00f6nnten. Der Einsatz solcher Parameterfelder sei notwendig, um die Zustandslosigkeit des bei Internetanwendungen verwendeten Netzwerkprotokolls HTTP (Hypertext Transfer Protokoll) zu \u00fcberbr\u00fccken. Ohne den Einsatz eines \u201eZustandsmanagements\u201c k\u00f6nnten die beim Rechenzentrum der Beklagten eingegangenen Daten nicht eindeutig einem Kunden bzw. einer Online-Sitzung zugeordnet werden. Soweit im Rahmen der HTML-Applikation daher ein Parameter in das Feld \u201ejavax.faces.portletbridge.STATE_ID\u201c eingef\u00fcgt werde, handele es sich lediglich um einen Teil der HTML-Kommunikation. Im \u00dcbrigen weise das von der Beklagten praktizierte Online-Banking auch keine M\u00f6glichkeit auf, dass dieser Code in irgendeiner Form am Endger\u00e4t des Bankkunden (\u201eTerminal\u201c) ausgegeben und anschlie\u00dfend durch den Bankkunden wieder eingegeben werde.<\/li>\n
  25. Mit Urteil vom 17. Januar 2017 hat das Landgericht D\u00fcsseldorf eine Patentverletzung bejaht und wie folgt erkannt:<\/li>\n
  26. I. Die Beklagte wird verurteilt,<\/li>\n
  27. 1. es bei Meidung eines vom Gericht f\u00fcr jeden Fall der Zuwiderhandlung festzusetzenden Ordnungsgeldes bis zu \u20ac 250.000,00, ersatzweise Ordnungshaft, oder einer Ordnungshaft bis zu sechs Monaten, im Falle mehrfacher Zuwiderhandlung bis zu insgesamt zwei Jahren, zu unterlassen,<\/li>\n
  28. Anlagen f\u00fcr die sichere Durchf\u00fchrung von Transaktionen zwischen informationsverarbeitenden Systemen mit einem Terminal, das zur Eingabe einer Benutzerkennung dient, mit einer Auswerteeinheit, die mit dem Terminal \u00fcber ein prim\u00e4res Netz verbunden ist und im Wesentlichen aus einer Speicher- und Prozessoreinheit besteht, welche zur Speicherung von Benutzerstammdaten und laufenden Transaktionen dient, mit einem Codegenerator, der einen Sicherheitscode erzeugt, mit einer Sendeeinrichtung, die den Sicherheitscode \u00fcber ein sekund\u00e4res Netz an ein Empfangsger\u00e4t sendet, und mit einer Eingabem\u00f6glichkeit f\u00fcr den Sicherheitscode am Terminal und einer \u00dcberpr\u00fcfung des eingegebenen Sicherheitscodes auf G\u00fcltigkeit durch die Auswerteeinheit,<\/li>\n
  29. in der Bundesrepublik Deutschland zu gebrauchen,<\/li>\n
  30. wenn die Auswerteeinheit einen zus\u00e4tzlichen Codegenerator zur Erstellung eines Zusatzcodes aufweist und eine zus\u00e4tzliche Sendeeinrichtung zur \u00dcbermittlung des Zusatzcodes \u00fcber das prim\u00e4re Netz an das Terminal und zur Ausgabe des Zusatzcodes aufweist, wobei das Terminal neben der Eingabem\u00f6glichkeit des Sicherheitscodes eine Ausgabe- und Eingabem\u00f6glichkeit f\u00fcr den Zusatzcode aufweist und die Auswerteeinheit derart ausgestaltet ist, dass diese den eingegebenen Zusatzcode \u00fcberpr\u00fcft und bei G\u00fcltigkeit von eingegebenem Sicherheitscode und Zusatzcode die Transaktion autorisiert;<\/li>\n
  31. 2. der Kl\u00e4gerin unter Vorlage eines einheitlichen, geordneten Verzeichnisses vollst\u00e4ndig dar\u00fcber Rechnung zu legen, in welchem Umfang die Beklagte die zu Ziffer I. 1. bezeichneten Handlungen seit dem 13. September 2004 begangen hat, und zwar unter Angabe<\/li>\n
  32. a) der Anzahl und des jeweiligen Werts der Transaktionen, die unter Gebrauch der Anlage durchgef\u00fchrt wurden, einschlie\u00dflich der Angabe des Datums der Transaktion,<\/li>\n
  33. b) der betriebenen Werbung, aufgeschl\u00fcsselt nach Werbetr\u00e4gern, deren Herstellungs- und Verbreitungsauflage, Verbreitungszeitraum und Verbreitungsgebiet,<\/li>\n
  34. c) der nach den einzelnen Kostenfaktoren aufgeschl\u00fcsselten Gestehungskosten und des erzielten Gewinns,<\/li>\n
  35. wobei von der Beklagten die Angaben zu lit. c) nur f\u00fcr die Zeit seit dem 26. November 2005 zu machen sind.<\/li>\n
  36. II. Es wird festgestellt, dass die Beklagte verpflichtet ist,<\/li>\n
  37. 1. an die Kl\u00e4gerin f\u00fcr die unter Ziffer I. 1. bezeichneten, in der Zeit vom 13. September 2004 bis zum 25. November 2005 begangenen Handlungen eine angemessene Entsch\u00e4digung zu zahlen;<\/li>\n
  38. 2. der Kl\u00e4gerin allen Schaden zu ersetzen, der ihr durch die unter Ziffer I. 1. bezeichneten, seit dem 3. Dezember 2014 begangenen Handlungen entstanden ist, sowie allen Schaden, der dem fr\u00fcheren Patentinhaber, Herrn A. Werner \u201eB\u201c, durch die unter Ziffer I. 1. bezeichneten, seit dem 26. November 2005 bis zum 2. Dezember 2014 begangenen Handlungen entstanden ist oder noch entstehen wird.<\/li>\n
  39. III. Die Beklagte wird verurteilt, an die Kl\u00e4gerin 12.912,00 \u20ac nebst Zinsen in H\u00f6he von 5 Prozentpunkten \u00fcber dem Basiszinssatz seit dem 30. April 2015 zu zahlen.<\/li>\n
  40. IV. Im \u00dcbrigen wird die Klage abgewiesen.<\/li>\n
  41. Zur Begr\u00fcndung hat das Landgericht im Wesentlichen ausgef\u00fchrt: Die Beklagten verletzten das Klagepatent, da die angegriffene Ausf\u00fchrungsform wortsinngem\u00e4\u00df von dessen technischer Lehre Gebrauch mache. Das Klagepatent sei nicht auf die Interaktion mit einer nat\u00fcrlichen Person beschr\u00e4nkt. Mit der Ausgabe, Eingabe und \u00dcberpr\u00fcfung des Zusatzcodes am Terminal solle sichergestellt werden, dass selbst beim Abh\u00f6ren beider Verbindungen sowie bei einer F\u00e4lschung des Terminals keine positive Autorisierung einer Transaktion durchgef\u00fchrt werden k\u00f6nne. Zudem werde die Sicherheit dadurch erh\u00f6ht, dass es f\u00fcr einen Missbrauch durch Dritte zus\u00e4tzlich zu den bestehenden Sicherheitsparametern auch der Kenntnis des Zusatzcodes bed\u00fcrfe. Daf\u00fcr sei nicht erforderlich, dass der Zusatzcode einer nat\u00fcrlichen Person visuell oder auf andere Weise wahrnehmbar zur Kenntnis gebracht und anschlie\u00dfend von der nat\u00fcrlichen Person manuell oder auf andere Weise in das Terminal eingegeben werde. Auch eine automatisierte und f\u00fcr den Benutzer als nat\u00fcrliche Person nicht wahrnehmbare \u00dcbermittlung des Zusatzcodes an das Terminal, die dortige Ausgabe und die erneute Eingabe sei zur Erf\u00fcllung des zus\u00e4tzlichen Sicherheitsschrittes geeignet.<\/li>\n
  42. Was das Klagepatent unter dem Begriff des \u201eZusatzcodes\u201c verstehe, werde weder im Klagepatentanspruch noch in der Klagepatentbeschreibung ausdr\u00fccklich definiert. Von dem \u00fcber ein sekund\u00e4res Netz an ein Empfangsger\u00e4t \u00fcbertragenen Sicherheitscode sei der Zusatzcode dadurch abzugrenzen, dass er durch das prim\u00e4re Netz an das Terminal \u00fcbertragen werde, also \u00fcber dasjenige Netz, \u00fcber das auch die Auswerteeinheit mit dem Terminal verbunden sei. Diese getrennte \u00dcbermittlung des Sicherheits- und des Zusatzcodes verhindere nach dem Klagepatent selbst bei nicht verschl\u00fcsselten Verbindungen oder bei nicht direkt dem Nutzer zuordenbaren Empfangsger\u00e4ten, dass Dritte beide Codes in Erfahrung bringen k\u00f6nnten. Nicht erforderlich sei, dass es sich bei der Heranziehung zur Autorisierung einer Transaktion um die einzige Funktion des Zusatzcodes handele. Zur Ausgestaltung und zum Format des Zusatzcodes enthalte der Patentanspruch keine beschr\u00e4nkenden Vorgaben. Der Zusatzcode k\u00f6nne mithin ein beliebiges Format haben und sowohl wesensgleich zum als auch wesensverschieden vom Sicherheitscode ausgestaltet sein. Entscheidend sei lediglich, dass er durch eine Auswerteeinheit gepr\u00fcft werden k\u00f6nne und dazu geeignet sei, gemeinsam mit dem Sicherheitscode zur Autorisierung einer Transaktion herangezogen zu werden. Daf\u00fcr sei es notwendig, dass er im Zusammenhang mit einer spezifischen Transaktion erstellt werde. Zwar bed\u00fcrfe es hierf\u00fcr keines unmittelbaren zeitlichen Zusammenhangs. Ein solcher m\u00fcsse aber insoweit bestehen, als pro Transaktion ein Zusatzcode zur Verf\u00fcgung stehe. Insbesondere m\u00fcsse sichergestellt werden, dass bei einer Sitzung am Terminal nicht mehrere Transaktionen mit demselben Zusatzcode autorisiert werden k\u00f6nnten. Der Begriff der \u201eTransaktion\u201c sei dabei von demjenigen der Sitzung (\u201esession\u201c) abzugrenzen. Die Sitzung beschreibe eine stehende Verbindung eines Clients mit einem Server. Dagegen sei die Transaktion nach dem Patentanspruch eine einzige Aktion, die einer Autorisierung bed\u00fcrfe.<\/li>\n
  43. Davon ausgehend mache die angegriffene Ausf\u00fchrungsform wortsinngem\u00e4\u00df von der technischen Lehre des Klagepatents Gebrauch.<\/li>\n
  44. Bei dem Wert des Parameters \u201ejavax.faces.portletbridge.STATE_ID\u201c handele es sich um einen Zusatzcode im Sinne des Klagepatents. Nur dann, wenn der vom Terminal an den Server zur\u00fcckgesandte Parameterwert mit dem vom Server erstellten Wert \u00fcbereinstimme und gleichzeitig die korrekte \u201emobileTAN\u201c eingegeben werde, werde die Transaktion ausgef\u00fchrt. Dass der Parameterwert im System der Beklagten nicht zielgerichtet f\u00fcr die Autorisierung der Transaktion eingesetzt werde, sei unerheblich. Ebenso sei unerheblich, dass der Parameterwert im Rahmen des Zustandsmanagements auch dazu diene, die Sitzung aufrechtzuerhalten. Denn die Beklagte bediene sich unstreitig auch einer sog. Session-ID, n\u00e4mlich in Form des Parameters \u201eJSESSIONID\u201c, um die Sitzung aufrechtzuerhalten. Schlie\u00dflich sei der Parameterwert, der bei jedem Sendevorgang ausgehend vom Server neu generiert werde, auch transaktionsspezifisch.<\/li>\n
  45. Das Terminal weise auch eine Eingabe- und Ausgabem\u00f6glichkeit f\u00fcr den Zusatzcode auf. Die Browsersoftware auf dem PC des Bankkunden schreibe den Code zun\u00e4chst in den Speicher (Ausgabe) und anschlie\u00dfend als Parameterwert in das Feld \u201ejavax.faces.portletbridge.STATE_ID\u201c (Eingabe). Unerheblich sei, dass der Wert des Parameters dem Bankkunden nicht zur Kenntnis gebracht werde, sondern der Prozess der Speicherung und erneuten Einbettung in das versteckte Feld automatisiert und f\u00fcr den Benutzer unsichtbar im Hintergrund erfolge.<\/li>\n
  46. Schlie\u00dflich weise die Auswerteeinheit auch einen zus\u00e4tzlichen Codegenerator zur Erstellung des Zusatzcodes auf. Unstreitig werde der Wert des Parameters \u201ejavax.faces. portletbridge.STATE_ID\u201c von dem Server der Beklagten erstellt, womit dieser \u00fcber einen zus\u00e4tzlichen Codegenerator \u2013 neben demjenigen f\u00fcr die Erstellung der \u201emobileTAN\u201c \u2013 verf\u00fcge. Da der Parameterwert von dem Server der Beklagten zum Client (PC des Bankkunden mit Internetbrowser) \u00fcbermittelt und dort weiterverarbeitet (zur\u00fcckgeschickt) werde, stehe auch fest, dass der Server der Beklagten \u00fcber eine entsprechende Sendeeinrichtung zur \u00dcbermittlung des Zusatzcodes \u00fcber das prim\u00e4re Netz an das Terminal und zur Ausgabe des Zusatzcodes verf\u00fcge. Dass es sich jeweils um einen Teil der HTML-Kommunikation handele, stehe einer Verwirklichung der beanspruchten technischen Lehre nicht entgegen.<\/li>\n
  47. Gegen dieses, ihren Prozessbevollm\u00e4chtigten am 18.01.2017 zugestellte Urteil hat die Beklagte mit Schriftsatz vom 07.02.2017 Berufung eingelegt, mit der sie ihr vor dem Landgericht erfolglos gebliebenes Klageabweisungsbegehren weiter verfolgt. Sie wiederholt und erg\u00e4nzt ihr erstinstanzliches Vorbringen und macht geltend:<\/li>\n
  48. Entgegen der Annahme des Landgerichts sei im Wortlaut des Klagepatents eine Interaktion des Nutzers und die kognitive Wahrnehmung des Zusatzcodes als Voraussetzung einer patentgem\u00e4\u00dfen Ein- und Ausgabe des Zusatzcodes zumindest nahegelegt. Die Beschreibung des Klagepatents, die wiederkehrend an eine solche Kenntnisnahme des Zusatzcodes durch den Nutzer und eine durch ihn erfolgte Eingabe des Zusatzcodes im Terminal ankn\u00fcpfe, erw\u00e4hne an keiner Stelle eine automatisierte, im Hintergrund ablaufende Ein- und Ausgabe und korrespondiere daher mit der vom Anspruch geforderten Ein- und Ausgabem\u00f6glichkeit. Entsprechend werde die beanspruchte technische Lehre nicht verwirklicht, wenn \u2013 wie beim Online-Banking der Beklagten \u2013 lediglich im Hintergrund und ohne Wahrnehmung und Interaktion des Bankkunden in der Datenkommunikation \u00fcber das prim\u00e4re Netz im Sinne eines \u201ePing Pongs\u201c f\u00fcr die Dauer einer Online-Sitzung fortlaufend Parameterwerte ausgetauscht w\u00fcrden, die der blo\u00dfen Aufrechterhaltung der Kommunikation zwischen Bankenserver (Auswerteeinheit) und Client (Terminal) dienen und damit keinen patentgem\u00e4\u00dfen Zusatzcode darstellen w\u00fcrden.<\/li>\n
  49. Auch das Bundespatentgericht habe in der das Klagepatent aufrechterhaltenden Entscheidung im Hinblick auf die funktionalen Anforderungen an den Zusatzcode eine gegen\u00fcber dem Landgericht abweichende Auffassung vertreten. Nach Auffassung des Bundespatentgerichts seien Sicherheits- und Zusatzcode funktional gleichwertig. Sie w\u00fcrden sich nur durch ihren \u00dcbertragungsweg unterscheiden. Beide seien transaktionsspezifisch, d.h. sie w\u00fcrden von der Auswerteeinheit (Bankenserver) explizit zum Zwecke der Autorisierung einer Transaktion erstellt, an den Nutzer \u00fcbermittelt, dort ausgegeben und sp\u00e4ter \u00fcberpr\u00fcft. Dagegen werde der Zusatzcode patentgem\u00e4\u00df nicht zur Organisation der prim\u00e4ren Verbindung verwendet. Zusatzparameter, die lediglich im Rahmen des Zustandsmanagements dazu dienten, die Online-Sitzung, d.h. die prim\u00e4re Verbindung, aufrechtzuerhalten, seien, was auch der zentrale Grund f\u00fcr die Abweisung der Nichtigkeitsklage gewesen sei, daher keine anspruchsgem\u00e4\u00dfen Zusatzcodes.<\/li>\n
  50. Dieses Verst\u00e4ndnis zugrunde gelegt, k\u00f6nne es sich bei dem Parameter \u201ejavax.faces. portletbridge.STATE_ID\u201c nicht um einen Zusatzcode im Sinne des Klagepatents handeln. Dieser stehe in keinem Zusammenhang mit einer wie auch immer gearteten Transaktion. Der Parameterwert werde weder im Hinblick auf eine Transaktion erzeugt noch dazu gespeichert oder f\u00fcr eine Autorisierung einer Transaktion gepr\u00fcft. Die STATE_ID und der jeweils eingesetzte Parameterwert seien daher nicht transaktionsspezifisch. Vielmehr werde der Parameterwert ungeachtet und losgel\u00f6st von einer Transaktion im Rahmen des Austausches der HTML-Seiten zwischen Server und Client hin- und hergeschickt, um die Online-Sitzung aufrechtzuerhalten bzw. sie zu synchronisieren.<\/li>\n
  51. Die Beklagte beantragt,<\/li>\n
  52. das Urteil das Landgerichts D\u00fcsseldorf vom 17. Januar 2017 (4b O 79\/15) abzu\u00e4ndern und die Klage abzuweisen.<\/li>\n
  53. Die Kl\u00e4gerin beantragt,<\/li>\n
  54. die Berufung zur\u00fcckzuweisen.<\/li>\n
  55. Die Kl\u00e4gerin verteidigt das angefochtene Urteil und tritt den Ausf\u00fchrungen der Beklagten unter Wiederholung und Erg\u00e4nzung ihres erstinstanzlichen Vorbringens entgegen. Sie hat insbesondere geltend gemacht, dass bei der angegriffenen Online-Banking-Plattform bei der Durchf\u00fchrung einer Transaktion (\u00dcberweisung, Umsatzanzeige) \u2013 anders als bei einer sonstigen, gew\u00f6hnlichen Kommunikation (wie des Aufrufs der Hilfefunktion oder des Impressums) \u2013 eine STATE_ID verwendet werde, n\u00e4mlich eine solche, die zus\u00e4tzlich \u00fcber einen kryptographisch starken Teil (ScopeID bzw. uuid) verf\u00fcge. Jeder Transaktion sei eine STATE_ID zugewiesen, die sich in ihrer Gesamtheit insofern als einmalig darstelle, weil sie in ihrem ersten (ScopeID) bzw. dritten Teil (uuid) zuf\u00e4llig und stets nur ein einziges Mal vergeben werde. Bei Vornahme einer Nicht-Transaktion werde keine STATE_ID verwendet, weil diese nur im Zusammenhang mit einem AJAXRequest zum Einsatz komme, der ausschlie\u00dflich f\u00fcr (formulargest\u00fctzte) Transaktionen (wie einer \u00dcberweisung) vorgesehen sei.<\/li>\n
  56. Der Senat hat Beweis durch Einholung eines Sachverst\u00e4ndigengutachtens erhoben. Wegen des Ergebnisses der Beweisaufnahme wird auf das schriftliche Gutachten von Patentanwalt Dipl.-Ing. \u201eF\u201c vom 11.04.2019 (nachfolgend: Gutachten; Bl. 359 \u2013 407 GA), sein schriftliches Erg\u00e4nzungsgutachten vom 05.08.2020 (nachfolgend: Erg\u00e4nzungs-Gutachten; Bl. 690 \u2013 711 GA) sowie auf die Protokolle \u00fcber seine m\u00fcndliche Anh\u00f6rung vom 23.01.2020 (nachfolgend: Anh\u00f6rungsprotokoll I; Bl. 455 \u2013 514 GA) und 02.09.2021 (nachfolgend: Anh\u00f6rungsprotokoll II; Bl. 869 ff. GA) Bezug genommen.<\/li>\n
  57. Wegen des weiteren Sach- und Streitstandes wird auf den Inhalt der wechselseitigen Schrifts\u00e4tze der Parteien und der von ihnen vorgelegten Anlagen sowie auf den Tatbestand und die Entscheidungsgr\u00fcnde der angefochtenen Entscheidung verwiesen.<\/li>\n
  58. II.
    \nDie Berufung der Beklagten ist zul\u00e4ssig und begr\u00fcndet. Es l\u00e4sst sich nicht feststellen, dass die Beklagte mit der angegriffenen Ausf\u00fchrungsform von der technischen Lehre des Klagepatents Gebrauch macht. Entgegen der Beurteilung des Landgerichts stehen der Kl\u00e4gerin die ihr zuerkannten Klageanspr\u00fcche deswegen nicht zu.<\/li>\n
  59. 1.
    \nDas Klagepatent betrifft eine Anlage zur sicheren Durchf\u00fchrung von Transaktionen zwischen informationsverarbeitenden Systemen.<\/li>\n
  60. Um den Nutzer im Rahmen einer Transaktion zwischen informationsverarbeitenden Anlagen aller Art zu authentifizieren und zu autorisieren, kommen herk\u00f6mmlicherweise User-IDs, PINs (Personal Identification Number), Passw\u00f6rter, Kreditkartennummern, PrePaid-Karten und TAN\u2019s (Transaktionsnummern) zum Einsatz, die sowohl in schriftlicher als auch in elektronischer Form vorliegen k\u00f6nnen. W\u00e4hrend die bekannten Anlagen gerade bei Distanzgesch\u00e4ften f\u00fcr den H\u00e4ndler bzw. Dienstleister eine relativ hohe Sicherheit bieten, ist mit ihnen f\u00fcr den Kunden ein Vertrauensvorschuss und ein hohes Sicherheitsrisiko, etwa im Hinblick auf einen m\u00f6glichen Diebstahl von Kreditkarten oder eine nachl\u00e4ssige Handhabung der Nutzer-IDs und PINs, verbunden. Selbst der relativ sichere Einsatz von TAN-Listen gestaltet sich nicht risikolos, da die schriftlich vorliegenden TANs h\u00e4ufig unsicher aufbewahrt werden, wobei f\u00fcr sie auch kein Ablaufdatum existiert. Zudem ist der Einsatz eines solchen Systems aufwendig und teuer, da die TANs vorab angelegt und dem Nutzer zugesandt werden m\u00fcssen.<\/li>\n
  61. Als eine M\u00f6glichkeit, die Sicherheit einer Transaktion zu erh\u00f6hen, wird im Stand der Technik, etwa in der WO 00\/78009 A2, die \u00dcbermittlung eines Autorisierungscodes \u00fcber einen sekund\u00e4ren Leitungsweg vorgeschlagen. Auch eine derartige L\u00f6sung ist jedoch nicht ohne Sicherheitsrisiken, etwa wenn die Autorisierung allein durch die Eingabe des stets gleichen PIN-Codes am Empfangsger\u00e4t durchgef\u00fchrt wird. Zudem kann der Anmeldebildschirm auch durch Dritte gef\u00e4lscht werden. Schlie\u00dflich kann es ein Sicherheitsrisiko darstellen, wenn dem Empfangsger\u00e4t stets der komplette Autorisierungscode \u00fcbermittelt wird (Abs. [0002]).<\/li>\n
  62. Vor dem geschilderten Hintergrund liegt dem Klagepatent die Aufgabe zugrunde, eine Anlage zur Verf\u00fcgung zu stellen, die die geschilderten Nachteile beseitigt und bei ihrer Handhabung eine sehr hohe Sicherheit bietet.<\/li>\n
  63. Zur L\u00f6sung dieser Problemstellung sieht Patentanspruch 1 eine Kombination der folgenden Merkmale vor:<\/li>\n
  64. 1. Anlage f\u00fcr die sichere Durchf\u00fchrung von Transaktionen zwischen informationsverarbeitenden Systemen.<\/li>\n
  65. 2. Die Anlage weist Folgendes auf:<\/li>\n
  66. 2.1. Ein Terminal (102),<\/li>\n
  67. 2.2. einen Codegenerator,<\/li>\n
  68. 2.3. eine Sendeeinrichtung,<\/li>\n
  69. 2.4. eine Auswerteeinheit (106).<\/li>\n
  70. 3. Das Terminal (102)<\/li>\n
  71. 3.1. dient zur Eingabe einer Benutzerkennung,<\/li>\n
  72. 3.2. weist eine Eingabem\u00f6glichkeit f\u00fcr den Sicherheitscode auf;<\/li>\n
  73. 3.3. weist neben der Eingabem\u00f6glichkeit f\u00fcr den Sicherheitscode eine Ausgabe- und Eingabem\u00f6glichkeit f\u00fcr den Zusatzcode auf.<\/li>\n
  74. 4. Der Codegenerator erzeugt einen Sicherheitscode.<\/li>\n
  75. 5. Die Sendeeinrichtung sendet den Sicherheitscode \u00fcber ein sekund\u00e4res Netz (107) an ein Empfangsger\u00e4t (108).<\/li>\n
  76. 6. Die Auswerteeinheit (106)<\/li>\n
  77. 6.1. besteht im Wesentlichen aus einer Speicher- und Prozessoreinheit,<\/li>\n
  78. 6.1.1. welche zur Speicherung von Benutzerstammdaten und laufenden Transaktionsdaten dient,<\/li>\n
  79. 6.2. ist mit dem Terminal (102) \u00fcber ein prim\u00e4res Netz (101) verbunden,<\/li>\n
  80. 6.3. \u00fcberpr\u00fcft den eingegebenen Sicherheitscode (106) auf G\u00fcltigkeit,<\/li>\n
  81. 6.4. weist einen zus\u00e4tzlichen Codegenerator zur Erstellung eines Zusatzcodes auf,<\/li>\n
  82. 6.5. weist eine zus\u00e4tzliche Sendeeinrichtung zur \u00dcbermittlung des Zusatzcodes \u00fcber das prim\u00e4re Netz (101) an das Terminal (102) und zur Ausgabe des Zusatzcodes auf,<\/li>\n
  83. 6.6. ist derart ausgestaltet, dass sie den eingegebenen Zusatzcode \u00fcberpr\u00fcft und bei G\u00fcltigkeit von eingegebenem Sicherheitscode und Zusatzcode die Transaktion autorisiert.<\/li>\n
  84. 2.
    \nUm die angestrebte erh\u00f6hte Sicherheit der Transaktion zu gew\u00e4hrleisten, ist bei der erfindungsgem\u00e4\u00dfen Anlage eine Zwei-Wege-Autorisierung vorgesehen, bei der zwei verschiedene Codes (sic.: der Sicherheitscode und der Zusatzcode) getrennt voneinander (sic.: durch verschiedene Codegeneratoren) erzeugt und \u00fcber zwei verschiedene Verbindungen (sic.: das sekund\u00e4re Netz und das prim\u00e4re Netz) \u00fcbertragen werden.<\/li>\n
  85. a)
    \nDie Anlage weist dementsprechend drei Hauptkomponenten auf: Ein Terminal (102), bei dem es sich sowohl um ein Hardware- als auch ein Softwareterminal wie etwa einen Internetbrowser handeln kann (Abs. [0005], Gutachten, S. 12 Mitte), eine Auswerteeinheit (106) sowie ein weiteres Empfangsger\u00e4t (108). Die Auswerteeinheit (106) ist mit dem Terminal (102) \u00fcber eine prim\u00e4re Verbindung (101) und mit dem weiteren Empfangsger\u00e4t (108) \u00fcber eine sekund\u00e4re Verbindung (107) verbunden.<\/li>\n
  86. b)
    \nAls Durchschnittsfachmann ist vorliegend ein Diplom-Ingenieur der Nachrichtentechnik anzusehen, der mehrj\u00e4hrige Erfahrungen auf dem Gebiet der sicheren Durchf\u00fchrung von Transaktionen zwischen informationsverarbeitenden Systemen und grundlegende Kenntnisse auf dem Gebiet der Informatik und der sicheren Daten\u00fcbertragung in Netzwerken besitzt (BPatG, Anlage BK 3, S. 7, Ziff. 4.; Anlage rop 10, S. 3 Mitte; vergleichbar auch Gutachten, S. 2, vorletzter Abs.). Er entnimmt den Merkmalen 2.4., 5. und 5.1. der vorstehenden Merkmalsgliederung, dass die Auswerteeinheit (106) im Wesentlichen aus einer Speicher- und einer Prozessoreinheit besteht und damit in der Lage ist, die Benutzerstammdaten und die laufenden Transaktionsdaten zu speichern. Daneben weist die Auswerteeinheit einen Codegenerator auf, der einen Sicherheitscode, etwa in Gestalt eines mehrstelligen alphanumerischen Codes, erzeugen kann (Merkmal 3., vgl. Abs. [0006]). Mangels n\u00e4herer Vorgaben im Klagepatent kann es sich bei dem Codegenerator f\u00fcr den Sicherheitscode um jede beliebige Vorrichtung oder Software handeln, die dazu eingerichtet ist, einen Autorisierungscode hervorzubringen (Gutachten, S. 12 Mitte). Au\u00dferdem verf\u00fcgt die Auswerteeinheit (106) \u00fcber eine Sendeeinrichtung, die dazu hergerichtet ist, den durch den Codegenerator erzeugten Sicherheitscode \u00fcber ein sekund\u00e4res Netz an das Empfangsger\u00e4t (108) zu \u00fcbertragen. Dem Vorsehen des Sicherheitscodes und der \u00dcbertragung \u00fcber ein sekund\u00e4res Netz liegt der Gedanke zugrunde, dass selbst ein vollst\u00e4ndiges Abh\u00f6ren der Kommunikation \u00fcber das prim\u00e4re Netz nicht f\u00fcr die unberechtigte Autorisierung einer Transaktion ausreicht (Gutachten, S. 5). Entscheidend ist daher, dass der Sicherheitscode nicht mittels des gleichen \u00dcbertragungsweges an den Nutzer gelangt, \u00fcber welchen das Terminal des Benutzers mit der Auswerteeinheit f\u00fcr die Benutzeranmeldung und f\u00fcr das Ausl\u00f6sen der Transaktion kommuniziert (vgl. Gutachten, S. 4 unten). Da die Kommunikation in der Praxis regelm\u00e4\u00dfig \u00fcber das Internet erfolgt, kommen f\u00fcr die \u00dcbermittlung des Sicherheitscodes vornehmlich Festnetztelefon-, Fax- oder Mobilfunk\u00fcbertragungen, insbesondere per SMS, in Betracht (Abs. [0006]; Gutachten, S. 5 Mitte).<\/li>\n
  87. c)
    \nDurch den Einsatz eines vom Terminal verschiedenen Empfangsger\u00e4tes wird die Sicherheit der Transaktion gegen\u00fcber anderen aus dem Stand der Technik bekannten L\u00f6sungen, wie etwa TAN-Listen (Abs. [0002]), erh\u00f6ht, denn f\u00fcr einen Missbrauch ben\u00f6tigt ein Dritter nicht nur Zugang zum Terminal und zur Auswerteeinheit. Vielmehr ist er, um Kenntnis vom Sicherheitscode zu erlangen, auf einen Zugriff auch auf die Empfangsvorrichtung des Nutzers angewiesen (Abs. [XXB5]). Da eine derartige Autorisierung \u00fcber einen an ein Empfangsger\u00e4t versandten Sicherheitscode jedoch nach wie vor mit Risiken verbunden ist, speziell wenn das Empfangsger\u00e4t den gesamten Sicherheitscode erh\u00e4lt und\/oder nicht personenbezogen ist, reicht ein so \u00fcbertragener Sicherheitscode gleichwohl nicht aus, um die Transaktion hinreichend abzusichern. Erfindungsgem\u00e4\u00df ist daher neben dem Sicherheitscode mit dem Zusatzcode ein weiteres Autorisierungsmittel vorgesehen. Nur wenn neben dem Sicherheitscode auch der Zusatzcode g\u00fcltig ist, darf eine Autorisierung der jeweiligen Transaktion stattfinden. Dementsprechend ist die Auswerteeinheit derart ausgestaltet, dass sie den eingegebenen Sicherheitscode und den eingegebenen Zusatzcode \u00fcberpr\u00fcft und die Transaktion (nur) bei G\u00fcltigkeit beider Autorisierungscodes ausf\u00fchrt (Merkmale 6.3. und 6.6.).<\/li>\n
  88. Vom Sicherheitscode unterscheidet sich der Zusatzcode dadurch, dass er mithilfe eines zus\u00e4tzlichen Codegenerators der Auswerteeinheit erzeugt und durch eine zus\u00e4tzliche Sendeeinrichtung \u00fcber das prim\u00e4re Netz an das Terminal gesendet wird. Sicherheits- und Zusatzcode werden mithin nicht nur getrennt hervorgebracht, sondern vor allem getrennt \u00fcbermittelt, was selbst bei nicht verschl\u00fcsselten Verbindungen (z.B. WAP, http) oder nicht direkt dem Benutzer zugeordneten Empfangsger\u00e4ten (z.B. Fax, Nebenstellentelefone) verhindert, dass Dritte beide Codes ohne weiteres in Erfahrung bringen k\u00f6nnen (Abs. [0008]).<\/li>\n
  89. d)
    \nSowohl der Sicherheits- als auch der Zusatzcode sind konzeptionell insoweit gleich, als sie beide der Autorisierung einer Transaktion dienen. Sie beide (und gemeinsam) sollen gew\u00e4hrleisten, dass nur eine berechtigte Person eine solche ausl\u00f6sen kann. Sicherheits- und Zusatzcode m\u00fcssen daher beide in einer Beziehung zur Transaktion stehen. Charakteristisch f\u00fcr eine Transaktion im Sinne des Klagepatents ist dabei, dass es sich um einzelne Vorg\u00e4nge innerhalb einer Kommunikation zwischen zwei informationsverarbeitenden Systemen handelt, f\u00fcr die eine besondere, erh\u00f6hte Sicherheit gew\u00fcnscht wird. Sie kann sich vordringlich daraus ergeben, dass der fragliche Vorgang eine Verm\u00f6gens\u00e4nderung zur Folge haben soll (\u00dcberweisung, Wertpapierk\u00e4ufe und \u2013verk\u00e4ufe), aber auch damit im Zusammenhang stehen, dass sensible (sic.: geheimhaltungsbed\u00fcrftige) Daten angezeigt werden sollen. Mit dem Begriff \u201eTransaktion\u201c ist demzufolge nicht jeder beliebige Kommunikationsvorgang im Internet, etwa der Austausch von Daten nach dem Client-Server-Modell, gemeint (BGH, Urt. v. 01.10.2019, Az.: X ZR 139\/17, Rz. 12 f., 27, 31).<\/li>\n
  90. Klagepatentgem\u00e4\u00df sind der Sicherheits- und der Zusatzcode diejenigen Instrumente, mit denen dem Sicherungsbed\u00fcrfnis Rechnung getragen wird, weswegen es sich beim Zusatzcode \u2013 nicht anders als beim Sicherheitscode \u2013 um einen Code handelt, der f\u00fcr die besondere, sicherheitsrelevante Situation vorgesehen ist und zum Einsatz kommt. Dies schlie\u00dft es freilich nicht schlechthin aus, den Code zugleich f\u00fcr andere Zwecke zu nutzen. Es darf sich aber nicht um ein Mittel handeln, mit dem lediglich die allgemeine Kommunikation zwischen den beteiligten informationsverarbeitenden Systemen in ihrer Gesamtheit gesch\u00fctzt oder verwaltet wird.<\/li>\n
  91. e)
    \nDazu, wie die Ein- bzw. Ausgabe von Sicherheits- und Zusatzcode konkret erfolgen sollen, verh\u00e4lt sich Patentanspruch 1 nicht beschr\u00e4nkend. Ausreichend, aber auch erforderlich ist angesichts des Anspruchswortlauts, dass das Terminal<\/li>\n
  92. a) eine Eingabem\u00f6glichkeit f\u00fcr den Sicherheitscode und<\/li>\n
  93. b) eine Ein- und Ausgabem\u00f6glichkeit f\u00fcr den Zusatzcode aufweist,<\/li>\n
  94. wobei die \u201eM\u00f6glichkeit\u201c zur \u201eEingabe\u201c f\u00fcr den die Transaktion durchf\u00fchrenden Benutzer (f\u00fcr wen auch sonst?) und die \u201eM\u00f6glichkeit\u201c zur \u201eAusgabe\u201c an den die Transaktion durchf\u00fchrenden Benutzer (an wen auch sonst?) bestehen muss.<\/li>\n
  95. Zudem muss die Auswerteeinheit derart ausgestaltet sein, dass sie den eingegebenen Zusatzcode \u00fcberpr\u00fcft.<\/li>\n
  96. aa)
    \nDer Fachmann, der sich davon ausgehend die Frage stellt, was klagepatentgem\u00e4\u00df unter der Ein- und Ausgabem\u00f6glichkeit f\u00fcr den Zusatzcode zu verstehen ist, findet einen wichtigen Anhaltspunkt in den zum allgemeinen Teil der Beschreibung des Klagepatents geh\u00f6renden Abs\u00e4tzen [0005] bis [0008], die wie folgt lauten:<\/li>\n
  97. <\/li>\n
  98. An der zitierten Textstelle wird eine L\u00f6sung offenbart, bei welcher dem Benutzer sowohl der Sicherheits- als auch der Zusatzcode zur Kenntnis gebracht und diese sodann durch den Benutzer in das Terminal eingegeben werden. Hierf\u00fcr muss das Terminal einerseits so gestaltet sein, dass es dem Benutzer den Zusatzcode, etwa optisch oder akustisch, zur Wahrnehmung bringt. Andererseits bedarf es der M\u00f6glichkeit zur manuellen Eingabe von Sicherheits- und Zusatzcode. Erg\u00e4nzend dazu beschreibt Abs. [XXB3] der Klagepatentbeschreibung als weitere M\u00f6glichkeit zur Erh\u00f6hung der Sicherheit die Vorgabe einer Eingabereihenfolge f\u00fcr den Sicherheits- und den Zusatzcode sowie ggf. f\u00fcr weitere Identifizierungsmerkmale. Dabei wird die durch einen Generator in der Auswerteeinheit erzeugte Ausgabereihenfolge mittels einer Sendeeinheit an das Terminal \u00fcbermittelt und dem Benutzer zur Kenntnis gebracht. Da nur jener Benutzer die \u201erichtige\u201c, d.h. die Transaktion ausl\u00f6sende Eingabereihenfolge kennt, wird die Sicherheit zus\u00e4tzlich erh\u00f6ht. Auch insoweit kommt es somit entscheidend und geradezu zwingend auf die Kenntnis des Nutzers an, der die entsprechenden Eingaben in das Terminal vornehmen soll. Schlie\u00dflich werden Sicherheits- und Zusatzcode auch in dem in den Figuren 1 und 2 gezeigten und in den Abs\u00e4tzen [XXB8] bis [0023] n\u00e4her beschriebenen Ausf\u00fchrungsbeispiel jeweils dem Benutzer zur Kenntnis bzw. zur Ansicht gebracht (vgl. Abs. [0022] f.]), der diese sodann in der geforderten Reihenfolge im Terminal eingibt.<\/li>\n
  99. Das Klagepatent versteht die Begriffe \u201eEingabe\u201c und \u201eAusgabe\u201c vor diesem Hintergrund durchweg dahingehend, dass sowohl der Sicherheits- als auch der Zusatzcode zun\u00e4chst dem jeweiligen Benutzer zur Kenntnis gegeben und sodann von diesem unter Verwendung einer f\u00fcr diesen Zweck vorgesehenen Eingabevorrichtung bei der Datenverarbeitung eingegeben werden (Gutachten, S. 14 Mitte).<\/li>\n
  100. bb)
    \nDaraus, dass die Eingabe der Benutzerkennung nach Abs. [0005] auch \u00fcber eine Magnet- oder Chipkarte erfolgen kann, folgt selbst dann nichts anderes, wenn die Ausf\u00fchrungen auch als f\u00fcr die Autorisierungscodes bedeutsam betrachtet werden. Auch bei einem Vorgehen, wie es f\u00fcr die Benutzerkennung geschildert wird, ist f\u00fcr die Eingabe eine gewillk\u00fcrte Handlung des Benutzers notwendig. Die Zuhilfenahme eines technischen Hilfsmittels entbindet den Benutzer lediglich von der Notwendigkeit, die immer gleiche Zeichenfolge als Benutzerkennung einzugeben. Auch wenn der Benutzer wom\u00f6glich die Zeichen- oder Signalfolge, durch welche seine Benutzerkennung auf der Chipkarte repr\u00e4sentiert wird, gar nicht kennt, so wei\u00df er doch, dass er durch die Handhabung des jeweiligen technischen Hilfsmittels speziell die Information seiner Benutzerkennung \u00fcbertragen und auf diese Weise eingeben kann (Gutachten, S. 16 unten \u2013 S. 17 oben). Hinweise darauf, dass das Klagepatent unter einer Ein- bzw. Ausgabe auch rein interne Vorg\u00e4nge, wie etwa eine Daten\u00fcbertragung von einem Mikroprozessor in einen Arbeitsspeicher, versteht, finden sich in der gesamten Klagepatentschrift nicht (so auch Gutachten, S. 21, dritter Absatz). Vielmehr bezieht sich ausnahmslos jede Verwendung des Begriffs der \u201eEingabe\u201c (ebenso wie der \u201eAusgabe\u201c) auf eine willk\u00fcrliche Handlung durch einen Benutzer (so auch Gutachten, S. 21 Mitte).<\/li>\n
  101. F\u00fcr das Vorliegen einer Eingabe im Sinne des Klagepatents ist erforderlich, dass der Benutzer die eingegebene Information kennt, was nicht notwendigerweise eine Kenntnis der genauen Codierung der eingegebenen Information bedeutet (Gutachten, S. 15 unten). Eine Eingabe im Sinne des Klagepatents liegt daher nicht vor, wenn das eingegebene Datum nicht direkt oder indirekt kausal von einem Menschen ausgeht, wenn der menschliche Vorgang, welcher die Eingabe bewirkt, nicht gewillk\u00fcrt ist oder wenn zwar eine gewillk\u00fcrte Handlung erfolgt, der Ausf\u00fchrende jedoch keine Kenntnis davon hat, dass durch die Ausf\u00fchrung der Handlung Informationen aufgenommen werden (Gutachten, S. 15 oben). Unter dem Begriff der Ausgabe versteht das Klagepatent demgem\u00e4\u00df das dem Benutzer zur Kenntnis bringen der jeweils vermittelnden Information. Erforderlich ist daher nicht nur, dass \u00fcberhaupt eine Wiedergabe des jeweiligen Datums erfolgt. Die Wiedergabe muss vielmehr auch so erfolgen, dass der Benutzer die Information mit ihrer Bedeutung erfassen kann, ihm die Information also vermittelt wird (Gutachten, S. 26, zweiter Abs.). Daher bedeutet der Ausdruck \u201eAusgabem\u00f6glichkeit\u201c, dass f\u00fcr eine tats\u00e4chlich zu erfolgende Ausgabe eine Mitwirkung des Empf\u00e4ngers der Ausgabe in Gestalt einer Wahrnehmung oder eines geistigen Verst\u00e4ndnisses erforderlich ist (Gutachten, S. 26 unten \u2013 S. 27 oben).<\/li>\n
  102. cc)
    \nDas vorstehende Verst\u00e4ndnis wird durch eine weitere \u00dcberlegung gest\u00fctzt. Nur wenn die Handlungsalternative besteht, von der Eingabe des Zusatzcodes im Einzelfall absehen zu k\u00f6nnen (weil diese nicht unwillk\u00fcrlich, d.h. zwangsl\u00e4ufig, automatisch und unabh\u00e4ngig vom Willen des Benutzers stattfindet), kann von einer \u201eM\u00f6glichkeit\u201c zur Eingabe gesprochen werden, denn die \u201eM\u00f6glichkeit\u201c tr\u00e4gt die Freiheit in sich, von dem entsprechenden (\u201em\u00f6glichen\u201c) Tun auch abzusehen zu k\u00f6nnen.<\/li>\n
  103. dd)
    \nBei der Forderung nach einer Ein- und Ausgabe durch den Benutzer handelt es sich um keinen technischen Selbstzweck. Ein- und Ausgabe tragen vielmehr entscheidend zu der durch das Klagepatent angestrebten Erh\u00f6hung der Sicherheit im Falle einer Transaktion bei.<\/li>\n
  104. Solange ein Internetserver bzw. eine Auswerteeinheit Codes sendet, deren Verarbeitung rein automatisch und damit gem\u00e4\u00df bekannter Protokollstandards zu erfolgen hat, kann ein Angreifer, dessen Computer die Protokolle ebenfalls beherrscht, auf die gesendeten Codes genauso \u201erichtig\u201c reagieren wie der eigentliche Adressat. Anders ausgedr\u00fcckt folgt aus der automatischen Verarbeitung gesendeter Codes gem\u00e4\u00df bekannter Standards die M\u00f6glichkeit einer ebenso automatischen Nachahmung durch einen Angreifer. F\u00e4ngt ein Angreifer einen solchen Code ab, wei\u00df er damit auch, wie mit ihm umzugehen ist. Dieser Automatismus ist nicht mehr gegeben, wenn ein Code erst als Ergebnis einer Eingabe an einen Internetserver bzw. an eine Auswerteeinheit gesendet wird. Denn in einem solchen Fall ist zumindest gew\u00e4hrleistet, dass die \u00dcbertragung des eingegebenen Zusatzcodes an die Auswerteeinheit in einem Datenfeld erfolgt, das sich nicht schon aus der Kenntnis des Protokollstandards ergibt. Es ist also in jedem Fall f\u00fcr die Verwendung des abgefangenen Codes in einer fingierten Nachricht gegen\u00fcber einem Code, der ohne Ein- und Ausgabe \u201ezur\u00fcckgeschickt\u201c wird, eine zus\u00e4tzliche Information erforderlich, welche sich nicht den Protokollstandards entnehmen l\u00e4sst (Gutachten, S. 40, obere H\u00e4lfte). Selbst bei einem Abh\u00f6ren beider unverschl\u00fcsselter Verbindungen ist daher zus\u00e4tzlich erforderlich, dass bei einem unberechtigten Benutzer ein \u00fcber das reine Befolgen der Protokolle hinausgehendes Verst\u00e4ndnis vorliegt, damit der unberechtigte Benutzer die Transaktion autorisieren kann. Dieser Erfolg wird durch die Ausgabe und die anschlie\u00dfende Eingabe des Zusatzcodes erreicht. Die Ein- und Ausgabe des Zusatzcodes ist daher ein Mittel zur Erh\u00f6hung der Sicherheit f\u00fcr den Fall, dass sowohl die prim\u00e4re als auch die sekund\u00e4re Verbindung abgeh\u00f6rt werden (Gutachten, S. 41 oben).<\/li>\n
  105. f)
    \nMit R\u00fccksicht darauf, dass das Klagepatent einen Erzeugnis- und keinen Verfahrensschutz bietet, kommt es f\u00fcr eine Verwirklichung seiner technischen Lehre nicht entscheidend darauf an, ob bei der angegriffenen Ausf\u00fchrungsform tats\u00e4chlich Sicherheits- und Zusatzcodes erzeugt werden. Der Anspruch ist vielmehr auf die Anlage als solche gerichtet, die derart gestaltet sein muss, dass mit ihr die entsprechenden Transaktionen durchgef\u00fchrt werden k\u00f6nnen. Um die avisierte getrennte Generierung und \u00dcbertragung von Sicherheits- und Zusatzcode zu erm\u00f6glichen, muss die Auswerteeinheit daher \u00fcber zwei Codegeneratoren und zwei Sendeeinrichtungen verf\u00fcgen, n\u00e4mlich je eine f\u00fcr den Sicherheits- und den Zusatzcode. W\u00e4hrend die erste Sendeeinrichtung \u00fcber ein sekund\u00e4res Netz mit dem Empfangsger\u00e4t verbunden ist, muss die zweite Sendeeinrichtung in der Lage sein, einen Zusatzcode \u00fcber das prim\u00e4re Netz, also die ohnehin bestehende Verbindung zwischen Terminal und Auswerteeinheit (Merkmal 6.2.), zu \u00fcbermitteln und diesen (nach dessen R\u00fccksendung durch das Terminal) wieder zu empfangen (Merkmal 6.5.). Damit die Auswerteeinheit in der Lage ist, den eingegebenen Sicherheits- und Zusatzcode auf ihre G\u00fcltigkeit zu \u00fcberpr\u00fcfen, muss sie diese kennen, weshalb die Speicher- und Prozessoreinheit erfindungsgem\u00e4\u00df derart ausgestaltet sein muss, dass sie neben den Benutzerstammdaten auch die Transaktionsdaten zum Zwecke ihres sp\u00e4teren Abgleichs speichern kann.<\/li>\n
  106. 3.
    \nDieses Verst\u00e4ndnis des Klagepatents vorausgeschickt, macht die angegriffene Ausf\u00fchrungsform von der technischen Lehre des Klagepatents keinen Gebrauch. Bei der angegriffenen Ausf\u00fchrungsform fehlt es an einer Verwirklichung der Merkmale 3.3., 6.5. und 6.6., da der durch die Kl\u00e4gerin zur Begr\u00fcndung des Verletzungsvorwurfs herangezogene Parameter \u201ejavax.faces.portletbridge.STATE_ID\u201c (nachfolgend auch: STATE_ID) nicht manuell eingegeben, sondern \u2013 unstreitig \u2013 im Internet-Browser auf dem PC des Nutzers und damit am Terminal ausgelesen, zwischengespeichert und anschlie\u00dfend zeitgleich mit der \u201emobileTAN\u201c als Sicherheitscode an den Authentifizierungsserver gesendet wird. Das Terminal bietet dementsprechend weder eine Ausgabe- noch eine Eingabem\u00f6glichkeit f\u00fcr die STATE_ID.<\/li>\n
  107. Die STATE_ID ist zwar Bestandteil der Daten, die beim Anklicken der entsprechenden Schaltfl\u00e4che \u201eWeiter\u201c von dem Terminal an die Auswerteeinheit \u00fcbertragen werden. Es findet aber weder eine Ausgabe der STADE_ID statt noch stellt das Ausl\u00f6sen der \u00dcbertragung durch das Anklicken der Schaltfl\u00e4che seitens des Benutzers eine Eingabe derselben dar. Bei der STATE_ID handelt es sich um einen Bestandteil des HTML-Codes, welcher abweichend davon gegen\u00fcber dem Benutzer versteckt werden soll (\u201ehidden field\u201c). F\u00fcr die STATE_ID wird eine Ausgabe unterdr\u00fcckt und damit verhindert. Das Anklicken der Schaltfl\u00e4che \u201eWeiter\u201c f\u00fchrt auch zu keiner Eingabe der STATE_ID als Zusatzcode. Zwar wird durch das Anklicken der Schaltfl\u00e4che ein Senden der STATE_ID als Datum (Information) von dem Terminal an die Auswerteeinheit ausgel\u00f6st. Jedoch hat der Benutzer keinerlei Kenntnis von diesem Ausl\u00f6sen. Ihm fehlt es sowohl am Wissen der Information, welche dem Datum der STATE_ID entspricht, als auch an dem Bewusstsein, mit dem Anklicken der Schaltfl\u00e4che \u201eWeiter\u201c eine solche Information einzugeben. Hinzu kommt, dass der Benutzer beim Versuch der Autorisierung einer Transaktion noch nicht einmal die M\u00f6glichkeit hat, das Aussenden der STATE_ID zu vermeiden. Denn damit eine Transaktion \u00fcberhaupt autorisiert werden kann, muss die Schaltfl\u00e4che \u201eWeiter\u201c gedr\u00fcckt werden. Der Benutzer ist also ohne sein Wissen dazu gezwungen, ein Aussenden der STATE_ID genau mit dem vorgegebenen Wert auszul\u00f6sen, wenn er die Transaktion autorisieren m\u00f6chte. Es besteht weder die M\u00f6glichkeit, den n\u00e4chsten Schritt ohne das Verursachen dieses Aussendens vorzunehmen noch die Option, den ausgesendeten Wert zu ver\u00e4ndern. Folglich fehlt es auch an der Eingabem\u00f6glichkeit f\u00fcr den Zusatzcode. Auch nach dem Anklicken der Schaltfl\u00e4che \u201eWeiter\u201c wird der Benutzer schlie\u00dflich nicht davon in Kenntnis gesetzt, dass er das Aussenden der STADE_ID veranlasst hat (vgl. hierzu Gutachten, S. 47 unten \u2013 S. 49 oben).<\/li>\n
  108. 4.
    \nFolgt man dem vorstehenden Verst\u00e4ndnis des Klagepatents nicht und legt stattdessen die Patentauslegung im Nichtigkeitsberufungsurteils des BGH zugrunde (die freilich insoweit fragmentarisch ist, als sie sich nicht zur Aus- und Eingabem\u00f6glichkeit f\u00fcr den Zusatzcode, sondern \u2013 losgel\u00f6st davon \u2013 zu den Anforderungen an einen Zusatzcode verh\u00e4lt), so ist das Ergebnis mangelnder Patentverletzung kein anderes.<\/li>\n
  109. Es fehlt n\u00e4mlich daran, dass die STATE_ID nicht hinreichend transaktionsspezifisch ist, womit sich auf der Grundlage der Patentauslegung des BGH ein alternativer, f\u00fcr sich selbst\u00e4ndig tragender Abweisungsgrund ergibt. Er besteht unter zwei Gesichtspunkten. Zun\u00e4chst ist die STATE_ID schon deshalb nicht transaktionsspezifisch, weil sie bei Ausf\u00fchrung mehrerer Transaktionen hintereinander (Umsatzanzeige, Einklappen des Finanzstatus, Ausklappen des Finanzstatus, Detailansicht) gleich bleibt und folglich eben nicht spezifisch f\u00fcr die einzelne Transaktion ist. Aber selbst wenn eine Spezifit\u00e4t (= Anderssein) des Zusatzcodes f\u00fcr jede individuelle Transaktion (wie sie auch die Kl\u00e4gerin in ihrem Schlusspl\u00e4doyer am 02.09.2021 ausdr\u00fccklich verfochten hat) nicht zu fordern sein sollte, scheitert eine Transaktionsspezifit\u00e4t der STATE_ID daran, dass sich nicht feststellen l\u00e4sst, dass die STATE_ID ausschlie\u00dflich bei einer Transaktion eingesetzt wird und nicht zur Anwendung kommt, wenn eine Nicht-Transaktion (Hilfemen\u00fc, Ansicht des Impressums) durchgef\u00fchrt wird.<\/li>\n
  110. a)
    \nWie auch der Senat im Rahmen der Auslegung des Klagepatents dargelegt hat, ist nicht jede Ver\u00e4nderung des Datenbestandes zwangsl\u00e4ufig eine Transaktion im Sinne des Klagepatents. Insbesondere reicht hierf\u00fcr nicht jeder Kommunikationsvorgang im World Wide Web (so auch BGH, Urt. v. 01.10.2019, Az.: X ZR 139\/17, Rz. 12 f.). Bei dem Zusatzcode darf es sich gerade nicht nur um ein Mittel handeln, mit dem die Kommunikation zwischen den beteiligten informationsverarbeitenden Systemen in ihrer Gesamtheit gesch\u00fctzt oder verwaltet wird. Nach dem \u2013 im vorliegenden Zusammenhang als richtig zu unterstellenden \u2013 Verst\u00e4ndnis des BGH muss der Zusatzcode vielmehr in einzelnen daf\u00fcr vorgesehenen, sicherungsbed\u00fcrftigen Situationen (\u201eTransaktion\u201c) als weiteres Sicherungsmittel zu den Mitteln f\u00fcr die grundlegende Absicherung der Kommunikationsbeziehung hinzutreten (BGH, a.a.O., Rz. 15). Dies bedingt, dass ein Zusatzcode bei Vorliegen einer Nicht-Transaktion nicht verwendet wird, oder \u2013 anders gewendet \u2013 dass ein Zusatzcode nur eine solche \u201eKennung\u201c sein kann, die ausnahmslos bei Transaktionen zum Einsatz kommt und ansonsten nicht. Zur geforderten \u201eSpezifizit\u00e4t\u201c des Zusatzcodes f\u00fcr eine \u201eTransaktion\u201c hat der BGH in seinem Nichtigkeitsberufungsurteil insoweit das Folgende festgehalten (Hervorhebungen sind hinzugef\u00fcgt):<\/li>\n
  111. Der Begriff der Transaktion ist in der Streitpatentschrift nicht definiert. \u2026 In Absatz 2 der Beschreibung sind mit PIN und TAN einige Instrumente benannt, wie sie zur Sicherung etwa von Bank\u00fcberweisungen, Wertpapierk\u00e4ufen und -verk\u00e4ufen und dergleichen eingesetzt werden. Diesen Vorg\u00e4ngen ist gemeinsam, dass sie aus Sicherheitsgr\u00fcnden einer besonderen Autorisierung oder Authentifizierung bed\u00fcrfen. Charakteristisch f\u00fcr eine Transaktion im Sinne des Streitpatents ist danach, dass es sich um einzelne Vorg\u00e4nge innerhalb einer Kommunikation zwischen zwei informationsverarbeitenden Systemen handelt, f\u00fcr die eine besondere, erh\u00f6hte Sicherheit gew\u00fcnscht wird. Dieses Bed\u00fcrfnis nach einer erh\u00f6hten Sicherheit kann sich insbesondere daraus ergeben, dass verm\u00f6gensrelevante \u00c4nderungen vorgenommen oder sensible Daten angezeigt werden sollen. \u2026<\/li>\n
  112. Das Patentgericht hat zutreffend angenommen, dass es sich bei einem Zusatzcode im Sinne des Streitpatents um einen transaktionsspezifischen Code handelt. Wie sich aus Merkmal 4 ergibt, dienen der Sicherheitscode und der Zusatzcode der Autorisierung der Transaktion, sollen also gew\u00e4hrleisten, dass nur eine berechtigte Person diese ausl\u00f6sen kann. Sicherheitscode wie Zusatzcode m\u00fcssen daher in einer Beziehung zur Transaktion im oben erl\u00e4uterten Sinne stehen. Sicherheits- und Zusatzcode sind nach der gesch\u00fctzten Lehre die Instrumente, mit denen dem erh\u00f6hten Sicherungsbed\u00fcrfnis Rechnung getragen wird. Damit handelt es sich beim Zusatzcode – nicht anders als beim Sicherheitscode – um einen Code, der gerade f\u00fcr diese besondere Situation vorgesehen ist. Dies schlie\u00dft nicht schlechterdings aus, den Code zugleich f\u00fcr andere Zwecke zu nutzen. Es darf sich aber nicht um ein Mittel handeln, mit dem die Kommunikation zwischen den beteiligten informationsverarbeitenden Systemen in ihrer Gesamtheit gesch\u00fctzt oder verwaltet wird. Der Zusatzcode muss vielmehr in einzelnen daf\u00fcr vorgesehenen Situationen als weiteres Sicherungsmittel zu den Mitteln f\u00fcr die grundlegende Absicherung der Kommunikationsbeziehung hinzutreten.<\/li>\n
  113. b)
    \nDass die STATE_ID den besagten Anforderungen an einen transaktionsspezifischen (Zusatz-)Code gen\u00fcgt, l\u00e4sst sich nach den \u00fcberzeugenden Ausf\u00fchrungen des Sachverst\u00e4ndigen nicht feststellen.aa)
    \nWie aus den unwiderlegten Ausf\u00fchrungen des Privatgutachters der Beklagten hervorgeht (Anlage BK 5, S. 13) und auch die Kl\u00e4gerin selbst einr\u00e4umt (vgl. Schriftsatz v. 04.04.2019, S. 7 oben), wird der Parameter STATE_ID auch in anderen Benutzungssituationen als dem des Ausf\u00fcllens eines \u00dcberweisungsformulars auf methodisch dieselbe Weise eingesetzt und nimmt dabei lediglich einen anderen Wert an. Bespiele sind etwa das Abfragen einer Umsatzanzeige, die Detailansicht zu einem bestimmten Umsatz (Zahlungseingang, Abbuchung), das Einklappen und Ausklappen des Finanzstatus bei der Umsatzanzeige. Dies entspricht auch den Feststellungen des gerichtlichen Sachverst\u00e4ndigen (Anh\u00f6rungsprotokoll II zu Frage 5). Zwar sind zwei verschieden aufgebaute STATE_ID zu unterscheiden, n\u00e4mlich solche mit Zufalls-uuid (Erg\u00e4nzungs-Gutachten S. 3 f.) und solche mit Namespace-uuid (Erg\u00e4nzungs-Gutachten S. 4 f.). Welche der beiden Formen der STATE_ID zum Einsatz kommt, h\u00e4ngt aber nicht von dem Inhalt der zu f\u00fchrenden Kommunikation ab.<\/li>\n
  114. Ohne dass die Kl\u00e4gerin dem widersprochen h\u00e4tte, verh\u00e4lt es sich nach den Darlegungen des gerichtlichen Sachverst\u00e4ndigen (Anh\u00f6rungsprotokoll II zu Frage 5) so, dass die STATE_ID bei mehreren bestimmten nacheinander durchgef\u00fchrten Transaktionen unver\u00e4ndert bleibt. Wird innerhalb der Umsatzanzeige der Finanzstatus ausgeklappt, eingeklappt und\/oder die Detailansicht aktiviert, so wird bei allen genannten Aktionen jeweils dieselbe STATE_ID verwendet. Sie alle, zumindest aber die Umsatzanzeige und die anschlie\u00dfende Detailansicht, repr\u00e4sentieren gleicherma\u00dfen geheimhaltungsbed\u00fcrftige und somit sicherungsrelevante Transaktionen. Denn mit der Detailansicht werden weitere Einzelheiten zu dem fraglichen, in der Umsatzanzeige nur allgemein aufgelisteten Gesch\u00e4ftsvorfall angezeigt, weswegen die Detailansicht weitergehende Informationen liefert, f\u00fcr die eine der allgemeinen Kontostandsanzeige zugebilligte \u2013 und ausdr\u00fccklich auch von der Kl\u00e4gerin eingeforderte Schutz- und Geheimhaltungsbed\u00fcrftigkeit \u2013 nicht verneint werden kann. Stellen aber sowohl die Umsatzanzeige als auch die den fraglichen Buchungsposten spezifizierende Detailansicht jeweils eine sicherungsbed\u00fcrftige Transaktion dar, dann kann die in diesem Zusammenhang verwendete STATE_ID schon deswegen nicht als (transaktionsspezifischer) Zusatzcode aufgefasst werden, weil die geforderte Spezifit\u00e4t nicht nur verlangt, dass es sich um einen Code handelt, der speziell bei Vornahme einer Transaktion zur Anwendung kommt (und sonst nicht), sondern der im Interesse einer sinnvollen Abgrenzung zur Session-ID dar\u00fcber hinaus erfordert, dass er spezifisch auch f\u00fcr die einzelne ins Auge gefasste Transaktion ist, womit der Zusatzcode bei mehreren Transaktionen hintereinander ein individueller, jeweils anderer zu sein hat. Wie die Kl\u00e4gerin im Verhandlungstermin vom 02.09.2021 selbst nachdr\u00fccklich eingefordert hat, muss ein einmal f\u00fcr eine Transaktion gebrauchter Zusatzcode danach verfallen. Solches geschieht bei der STATE_ID im Rahmen der geschilderten Transaktionen (Umsatzanzeige, Detailansicht) nicht.<\/li>\n
  115. Zwar mag es daneben Transaktionskonstellationen geben (Umsatzanzeige \u2013 \u00dcberweisung), bei denen die STATE_ID wechselt. Solche einzelnen F\u00e4lle der Verwendung einer f\u00fcr jede Transaktion individuellen STATE_ID sind jedoch rechtlich irrelevant. Das Klagepatent will dem Benutzer eine Anlage bereitstellen, mit der online durchzuf\u00fchrende Transaktionen nicht nur gelegentlich und in Abh\u00e4ngigkeit von ganz bestimmten Transaktionsma\u00dfnahmen und \u2013abfolgen sicher sind, sondern die dem Benutzer f\u00fcr jedwede Online-Transaktion, die er mit ihrer Hilfe vornimmt, d.h. unter allen Anwendungs- und Gebrauchsbedingungen, einen Schutz gegen Angreifer bietet. Dies bedingt, dass die technische Lehre des Klagepatents und mithin insbesondere die F\u00e4higkeit zum Einsatz eines f\u00fcr jede Transaktion spezifischen (= individuellen) Zusatzcodes immer dann besteht, wenn eine sicherungsbed\u00fcrftige Transaktion (gleich welcher Art) durchgef\u00fchrt wird.<\/li>\n
  116. bb)
    \nZugunsten der Kl\u00e4gerin kann aber \u2013 und darin liegt der dritte, selbst\u00e4ndig tragende Abweisungsgrund \u2013 sogar unterstellt werden, dass die Transaktionsspezifit\u00e4t nicht verlangt, dass der Zusatzcode ein f\u00fcr jede einzelne Transaktionsma\u00dfnahme individueller sein muss, sondern auch gleich bleiben kann, oder dass eine Individualit\u00e4t des Zusatzcodes nur f\u00fcr bestimmte Transaktionsma\u00dfnahmen (Umsatzanzeige \u2013 \u00dcberweisung) ausreicht. Es existiert n\u00e4mlich kein tatrichterliche \u00dcberzeugungen und Feststellungen erlaubender Beweis der (f\u00fcr den Verletzungssachverhalt beweispflichtigen) Kl\u00e4gerin daf\u00fcr, dass bei nicht sicherungsbed\u00fcrftigen Vorg\u00e4ngen keine STATE_ID zum Einsatz kommt. In diesem Zusammenhang kommt es nicht darauf an, ob bereits die eigene Anlage rop 14 der Kl\u00e4gerin belastbare Anhaltspunkte daf\u00fcr liefert, dass auch im Vorfeld und abseits einer Transaktion eine STATE_ID ausgetauscht wird. Selbst wenn insoweit dem Standpunkt der Kl\u00e4gerin gefolgt und der Anlage rop 14 eine dahingehende Aussagekraft nicht beigemessen wird, lassen jedenfalls die bei der Gerichtsakte befindlichen Untersuchungsbefunde eine solche M\u00f6glichkeit ohne weiteres zu und schlie\u00dfen sie keinesfalls aus. Schon deswegen kann das Bestreiten der Beklagten und ihre Behauptung, eine STATE_ID finde bei der angegriffenen Ausf\u00fchrungsform unterschiedslos bei Transaktionen und Nicht-Transaktionen statt, weder als ins Blaue hinein aufgestellt noch als unsubstantiiert betrachtet werden, zumal die Einlassung der Beklagten auch unmittelbar einleuchtet. Es mag \u2013 wie die Kl\u00e4gerin behauptet \u2013 zutreffen, dass die STATE_ID bei der angegriffenen Ausf\u00fchrungsform ausschlie\u00dflich im Zusammenhang mit einem AJAXRequest verwendet wird, der f\u00fcr formulargest\u00fctzte Aktionen vorgesehen ist. Solche auf ein vom Benutzer auszuf\u00fcllendes Formular zur\u00fcckgreifende Aktionen sind aber auch im Bereich der Nicht-Transaktionen problemlos denkbar. Bei Aufrufen des Hilfemen\u00fcs (als zweifelsfrei nicht sicherheitsrelevanter Aktion) beispielsweise macht es durchaus Sinn, dem Benutzer ein Suchformular zur Verf\u00fcgung zu stellen, mit dem er die von ihm ben\u00f6tigte Hilfe thematisch n\u00e4her konkretisieren kann. Dass die angegriffene Ausf\u00fchrungsform solche Mittel au\u00dferhalb des Transaktionsbereichs nirgends vorsieht, ist von der Kl\u00e4gerin nicht dargelegt. Ebenso wenig hat sie auch nur eine Nicht-Transaktion dokumentiert, bei der kein AJAXRequest und\/oder keine STATE_ID zur Anwendung kommt. Mindestens das eine oder das andere aber w\u00e4re vorzutragen und zu beweisen gewesen, um der im Hinblick auf den erhobenen Verletzungsvorwurf bestehenden Vortrags- und Beweislast nachzukommen.<\/li>\n
  117. 5.
    \nSchlie\u00dflich \u2013 und daraus ergibt sich der vierte, selbst\u00e4ndig tragende Klageabweisungsgrund \u2013 erfolgt sowohl das Erzeugen als auch die Abfrage der STATE_ID auf eine Art und Weise, die eine direkte Einflussnahme oder auch nur die Kenntnis eines Softwareteils ausschlie\u00dft, der die unter Zuhilfenahme des Portlets und des Faces-Servers erhaltenen Daten weiterverarbeitet. In Anlehnung an das Schichtenmodell f\u00fcr eine Netzwerkkommunikation finden s\u00e4mtliche auf die STATE_ID bezogenen Vorg\u00e4nge auf einer Protokollschicht statt, auf die diejenige Instanz, die die Autorisierung des Sicherheitscodes durchf\u00fchrt, keinen Zugriff hat. Die auf die STATE_ID bezogenen Programmteile sind nur dazu eingerichtet, im Falle richtig gesetzter Parameter wie der STATE_ID die auf diesem Weg \u00fcbermittelten Nutzdaten \u2013 zu denen die STATE_ID selbst nicht z\u00e4hlt \u2013 an die \u201eoberhalb\u201c des Netzwerks im erweiterten Sinne angeordnete Anwendungsschicht weiterzureichen. Im Falle einer falsch gesetzten STATE_ID resultiert ein Kommunikationsfehler, welcher aber nur durch eine Diskrepanz in der Zustandsverwaltung und nicht durch eine ung\u00fcltige Autorisierung begr\u00fcndet ist. Es ist nicht vorgesehen, dass eine f\u00fcr die Pr\u00fcfung des Sicherheitscodes eingerichtete Programmschicht gleichsam in die Interna der Zustandsverwaltung eingreifen und die STATE_ID zus\u00e4tzlich zu der ohnehin erfolgenden Zustandspr\u00fcfung abfragen oder setzen kann. Vielmehr bleibt eine solche Programmschicht davon abgekapselt. Folglich sorgt der Parameter STATE_ID ausschlie\u00dflich daf\u00fcr, dass innerhalb des Online-Bankings verschiedene Funktionen (Kontoabfrage, T\u00e4tigen einer \u00dcberweisung) unterschieden und (dank der richtigen Zuordnung der einzelnen Kommunikationsbeitr\u00e4ge) ordnungsgem\u00e4\u00df abgewickelt werden k\u00f6nnen. Vor der Autorisierungsinstanz, welche den Sicherheitscode \u00fcberpr\u00fcft, bleibt er jedoch abgeschirmt und kann daher dem Sicherheitscode nicht wesensgleich sein.<\/li>\n
  118. Das Auftreten einer Fehlermeldung f\u00fcr den Fall, dass der zur\u00fcckgesandte, in den Parameter \u201ejavax.faces.portletbridge.STATE_ID\u201c eingesetzte Wert nicht mit dem urspr\u00fcnglich durch das Rechenzentrum \u00fcbermittelten Wert \u00fcbereinstimmt, l\u00e4sst daher nicht darauf schlie\u00dfen, bei der angegriffenen Ausf\u00fchrungsform werde neben der als Sicherheitscode fungierenden \u201emobileTAN\u201c auch ein zun\u00e4chst \u00fcber das prim\u00e4re Netz \u00fcbertragener Zusatzcode durch die Auswerteeinheit \u00fcberpr\u00fcft und die Transaktion davon ausgehend mangels \u00dcbereinstimmung abgelehnt. Sie ist vielmehr Ausdruck dessen, dass es zu einer St\u00f6rung in der Organisation der prim\u00e4ren Verbindung kam. Dass dem so ist, verdeutlicht nicht zuletzt die im Fall der fehlenden \u00dcbereinstimmung des in den vorgenannten Parameter eingesetzten Wertes angezeigte Meldung. Denn anders als im Fall einer falschen \u201emobileTAN\u201c wird nicht auf deren Ung\u00fcltigkeit bzw. deren Nichtvorhandensein hingewiesen. Vielmehr erscheint ein Hinweis, w\u00e4hrend der Verarbeitung sei ein technischer Fehler aufgetreten (vgl. Anlage rop 8, S. 9). Ein Abbruch der Transaktion aus anderen Gr\u00fcnden als der ung\u00fcltigen Autorisierung kann jedoch gerade nicht als Negativpr\u00fcfung eines Zusatzcodes verstanden werden, da die beanspruchte Auswerteeinheit eine \u00dcberpr\u00fcfung im Sinne des Merkmals 5.6. in diesem Fall gar nicht durchf\u00fchren w\u00fcrde (so auch BPatG, Anlage BK 3, S. 10 oben).Im \u00dcbrigen unterscheidet sich der im Streit stehende Parameter \u201ejavax.faces.portletbridge.STATE_ID\u201c in Bezug auf die Frage, ob dieser der Organisation des prim\u00e4ren Netzes zuzuordnen ist oder ob es sich um einen \u00fcber dieses Netz zu \u00fcbermittelten Zusatzcode handelt, auch nicht wesentlich von dem durch die Parteien im Nichtigkeitsverfahren diskutierten Stand der Technik. So erstellt der WSG-Server nach der in der US 6,061,741 (Anlage NK 18) offenbarten Ausgestaltung auf eine http-Anfrage hin einen neuen Token f\u00fcr diese Transaktion und setzt diesen in die http-Antwort als Teil des HTML-Dokuments ein. Wenn der Webbrowser das HTML-Formular zur\u00fccksendet, \u00fcbermittelt er auch den Sitzungs-Token. Der WSG-Server vergleicht den Token mit dem aktuellen, gespeicherten Token und akzeptiert entweder die Transaktion oder weist diese ab (NK 18, S. 11, Z. 33 \u2013 S. 12, Z. 22). Von einer solchen L\u00f6sung grenzt sich die technische Lehre des Klagepatents nach Auffassung des mit technisch versierten Richtern besetzten Bundespatentgerichts, die der Senat als fachkundige Stellungnahme zu ber\u00fccksichtigen hat und auch teilt (vgl. Anlage rop 10, S. 5) und die auch nicht in Widerspruch zu den Ausf\u00fchrungen des Bundesgerichtshofes im Nichtigkeitsberufungsverfahren steht (vgl. BGH, Urt. v. 01.10.2019, Rz. 25 ff.) dadurch ab, dass der Zusatzcode eben nicht Teil der Organisation der prim\u00e4ren Verbindung ist, sondern lediglich \u00fcber das \u2013 auch ohne den Zusatzcode funktionsf\u00e4hige \u2013 prim\u00e4re Netz \u00fcbertragen wird.<\/li>\n
  119. 6.
    \nDen vorstehenden \u00dcberlegungen kann die Kl\u00e4gerin nicht mit Erfolg entgegenhalten, der Umstand des T\u00e4tigwerdens eines Zufallsgenerators beim Generieren der STATE_ID verb\u00fcrge per se ein hohes (im Stand der Technik nicht dagewesenes) Ma\u00df an Sicherheit f\u00fcr jeden Kommunikationsvorgang und folglich auch f\u00fcr eine Transaktion. Das Klagepatent definiert keine konkreten Sicherheitsstandards f\u00fcr das Kommunikationsgeschehen, sondern beruht auf dem Gedanken, dass eine Transaktion dadurch sicherer wird, dass ihr ein spezieller, f\u00fcr die Transaktion spezifischer, gezielt die Sicherheit der Transaktion erh\u00f6hender Code zugewiesen wird, der bei der \u00fcbrigen Kommunikation keine Verwendung findet. Mit welcher Sicherheitsh\u00f6he die Kommunikation stattzufinden hat und welchen genauen Sicherheitsanforderungen der Zusatzcode f\u00fcr die Transaktion gen\u00fcgen muss, besagt das Klagepatent nicht. Die Erfindung beruht nach der Auslegung des BGH allein auf dem Gedanken, die Transaktion als besondere Form der Kommunikation dadurch sicherer zu machen, dass ihr ein zus\u00e4tzlicher, ansonsten nicht zum Einsatz kommender Code zugewiesen wird. Zwischen der normalen Kommunikation und der Transaktion ergibt sich also ein Sicherungsgef\u00e4lle, was das Kennzeichnende der Erfindung ist. Jeden Akt der Kommunikation mit gesteigerter Sicherheit auszustatten, mag zwar im Ergebnis ein gleiches oder sogar \u00fcberlegenes Ma\u00df an Transaktionssicherheit hervorbringen, folgt aber dem Konzept des Klagepatents nicht, sondern stellt einen ganz anderen Sicherheitsansatz dar.<\/li>\n
  120. 7.
    \nSoweit die Kl\u00e4gerin die fachliche Eignung des gerichtlichen Sachverst\u00e4ndigen bezweifelt, auf dessen Expertise sich der Senat f\u00fcr sein Urteil ma\u00dfgeblich st\u00fctzt, sind die Angriffe g\u00e4nzlich haltlos. In seiner ersten Anh\u00f6rung (Anh\u00f6rungsprotokoll I, S.2-3) hat der Sachverst\u00e4ndige seine akademische Ausbildung (Mathematik-Bachelorstudium in Harvard mit der Note \u201ecum laude\u201c, Studium der Elektrotechnik mit der Vertiefungsrichtung \u201eTechnische Informatik\u201c an der RWTH Aachen mit der Note \u201esehr gut\u201c) ebenso detailliert dargelegt wie seine anschlie\u00dfend erworbenen beruflichen Erfahrungen als Softwareentwickler im Auftrag mehrerer namhafter Firmen. Alles das spricht f\u00fcr sich und l\u00e4sst f\u00fcr den Senat nicht den geringsten Zweifel daran, dass der Sachverst\u00e4ndige \u00fcber diejenigen Kenntnisse besitzt, derer es bedarf, um die Beweisfragen sachkundig zu beantworten.<\/li>\n
  121. 8.
    \nSoweit der Sachverst\u00e4ndige bei seiner Anh\u00f6rung vom 02.09.2021 die M\u00f6glichkeit einger\u00e4umt hat, anhand des Quellcodes der angegriffenen Ausf\u00fchrungsform oder durch eine Untersuchung der bei der Beklagten befindlichen Testversion verl\u00e4ssliche Ermittlungen dazu anzustellen, ob die State_ID nur bei Transaktionen im Sinne der BGH-Berufungsentscheidung verwendet wird oder genauso bei Nicht-Transaktionen (Hilfemen\u00fc, Impressum), ergibt sich hieraus kein Anlass f\u00fcr eine weitere gutachterliche Aufkl\u00e4rung in dieser Richtung von Amts wegen. Nach den \u00fcberzeugenden Ausf\u00fchrungen des Sachverst\u00e4ndigen ist derzeit g\u00e4nzlich ungewiss und offen, in welchen F\u00e4llen eine State_ID zum Einsatz kommt. Da auch im Rahmen des Hilfemen\u00fcs Formularfelder (z.B. zum Eintragen eines Suchbegriffs) denkbar und sinnvoll sind, ist es ohne weiteres vorstellbar, den AJAXRequest auch in diesem Zusammenhang zu nutzen. Auf die blo\u00dfe M\u00f6glichkeit eines Nachweises hin ist jedoch keine amtsseitige Beweiserhebung veranlasst. Vielmehr bleibt es dabei, dass es in erster Linie Sache der klagenden Partei ist, die anspruchsbegr\u00fcndenden Tatsachen nachzuweisen oder wenigstens in einem Ma\u00dfe plausibel zu machen, dass sich eine \u00fcberwiegende Wahrscheinlichkeit f\u00fcr ihr Vorhandensein ergibt. Daran fehlt es hier.<\/li>\n
  122. III.<\/li>\n
  123. Die Kostenentscheidung folgt aus \u00a7 91 Abs. 1 ZPO.<\/li>\n
  124. Die Anordnungen zur vorl\u00e4ufigen Vollstreckbarkeit ergeben sich aus \u00a7\u00a7 708 Nr. 10, 711, 108 ZPO.<\/li>\n
  125. F\u00fcr eine Zulassung der Revision besteht keine Veranlassung, weil die in \u00a7 543 ZPO aufgestellten Voraussetzungen ersichtlich nicht gegeben sind. Es handelt sich um eine reine Einzelfallentscheidung ohne grunds\u00e4tzliche Bedeutung, mit der der Bundesgerichtshof auch nicht im Interesse einer Fortbildung des Rechts oder der Sicherung einer einheitlichen Rechtsprechung befasst werden muss (\u00a7 543 Abs. 2 ZPO).<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"

    D\u00fcsseldorfer Entscheidungen Nr. 3150 Oberlandesgericht D\u00fcsseldorf Urteil vom 02. September 2021, Az. I – 2 U 9\/17 Vorinstanz: 4b O 176\/11<\/p>\n","protected":false},"author":23,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[95,20],"tags":[],"class_list":["post-8823","post","type-post","status-publish","format-standard","hentry","category-95","category-olg-duesseldorf"],"acf":[],"_links":{"self":[{"href":"https:\/\/d-prax.de\/index.php?rest_route=\/wp\/v2\/posts\/8823","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/d-prax.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/d-prax.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/d-prax.de\/index.php?rest_route=\/wp\/v2\/users\/23"}],"replies":[{"embeddable":true,"href":"https:\/\/d-prax.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=8823"}],"version-history":[{"count":3,"href":"https:\/\/d-prax.de\/index.php?rest_route=\/wp\/v2\/posts\/8823\/revisions"}],"predecessor-version":[{"id":8839,"href":"https:\/\/d-prax.de\/index.php?rest_route=\/wp\/v2\/posts\/8823\/revisions\/8839"}],"wp:attachment":[{"href":"https:\/\/d-prax.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=8823"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/d-prax.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=8823"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/d-prax.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=8823"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}