Abweisung der Klage; keine Verletzung

Prozessgeschichte

1. Am 26. April 2019 reichte die Klägerin die Klageschrift ein mit folgenden Rechtsbegehren:

«1. Die Beklagte sei unter Androhung einer Ordnungsbusse von CHF 1'000 pro Tag der Nichterfüllung gemäss Art. 343 Abs. 1 lit. c ZPO, mindestens aber CHF 5'000 gemäss Art. 343 Abs. 1 lit. b ZPO, sowie der Bestrafung ihrer Organe nach Art. 292 StGB mit Busse im Widerhandlungsfall zu verpflichten, innert 45 Tagen nach Rechtskraft des Urteils Auskunft zu erteilen und nach anerkannten Grundsätzen der Rechnungslegung Rechnung zu legen über sämtliche Transaktionen mit Tokens, die auf der Ethereum-Blockchain basieren, also insbesondere, aber nicht abschliessend nativer Ethereum Token (ETH und ERC20) und Friendz-Token (FDZ), unter Angabe insbesondere der folgenden Informationen (unter Vorlage der einschlägigen Auszüge aus der Finanz- und Betriebsbuchhaltung sowie der Kostenstellen- und Kostenträgerrechnung, sowie Auszüge aus den genutzten Krypto-Wallets und der Ethereum-Blockchain):

a. Wann wurden die entsprechenden Token generiert?

b. Wann und an welche Token-Adressen wurden die entsprechenden Token versendet?

c. Wann und durch wen wurde welcher Token empfangen?

d. Angabe sämtlicher Primär- und Sekundärmarkt-Transaktionen, bei denen entsprechende Token gegen andere Token ausgegeben, umgetauscht, ge- oder verkauft wurden, unter Angabe der Tokens und deren Anzahl, dem Tauschverhältnis und Tauschzeitpunkt, sowie der jeweiligen Kurse der Token in CHF;

e. Angabe sämtlicher Primär- und Sekundärmarkt-Transaktionen, bei denen entsprechende Token gegen Fiat-Währungen ausgegeben, umgetauscht, ge- oder verkauft wurden, unter Angabe der Tokens und deren Anzahl, dem Tauschverhältnis und Tauschzeitpunkt, sowie der jeweiligen Kurse der Token in CHF;

f. Angabe sämtlicher Transfers, bei denen entsprechende Token zwischen eigenen Wallets der Beklagten oder Wallets von mit ihr verbundenen

Personen transferiert wurden, unter Angabe der Tokens und deren Anzahl, der allfälligen Gegenleistung (inkl. Umtauschverhältnis) und dem Transferzeitpunkt, sowie der jeweiligen Kurse der Token in CHF.

2. Der Klägerin sei im Anschluss an die Rechnungslegung und Auskunftserteilung gemäss Rechtsbegehren 1 Gelegenheit zu geben, den von der Beklagten an sie zu bezahlenden finanziellen Wiedergutmachungsanspruch zu beziffern, und die Beklagte sei zu verpflichten, der Klägerin den so bezifferten Betrag zuzüglich eines Schadenzinses von 5% p.a. zu bezahlen.

3. Alles unter Kosten- und Entschädigungsfolgen (inkl. der Auslagen für den notwendigerweise beigezogenen Patentanwalt) zu Lasten der Beklagten.

und den folgenden prozessualen Anträgen:

1. Das Verfahren sei einstweilen auf die Fragen der Auskunftserteilung und Rechnungslegung, d.h. auf das Rechtsbegehren Nr. 1 zu beschränken, bis über dieses Rechtsbegehren ein vollstreckbares Teilurteil vorliegt;

2. Das Verfahren sei bis zum Vorliegen eines vollstreckbaren Teilurteils mit Bezug auf die Substantiierung und Bezifferung der finanziellen Ansprüche der Klägerin zu sistieren.»

2. Am 3. Juli 2019 erstattete die Beklagte die Klageantwort:

«Präliminar

1. Die Klage sei unzulässig.

2. Unter Kosten- und Entschädigungsfolge.

In der Hauptsache

1. Die Klage sei vollständig abzuweisen, soweit sie zulässig sei.

2. Unter Kosten- und Entschädigungsfolge.

Eventualiter

1. Das Rechnungslegungsbegehren der Sunshine Software Development GmbH gegen die FRIENDZ SA sei zu beschränken auf die Informationen betreffend die Zahl der Token, die die FRIENDZ SA anlässlich ihres Initial Coin Offerings zwischen Februar und März 2018 emittiert hat, auf die Identität der Destinatäre der Token und auf die Identität der Nutzer und der Kunden, wobei die Vornamen und Namen der Destinatäre der Token und der Kunden zu schwärzen und/oder in anonymisierter Form zu produzieren sein werden.

Der FRIENDZ SA sei eine Frist von 45 Tagen ab der Rechtskraft dieses Entscheids anzusetzen, um die Dokumentation von Punkt 1 nach den erwähnten Modalitäten vorzulegen.

2. Unter Kosten- und Entschädigungsfolge.

Auf jeden Fall

1. Das Schadenersatzbegehren der Sunshine Software Development GmbH, Deutschland, gegen die FRIENDZ SA, Schweiz, sei vollständig abzuweisen.

2. Unter Kosten- und Entschädigungsfolge.»

3. Am 7. Oktober 2019 fand eine Instruktions-/Vergleichsverhandlung statt, die indessen zu keiner Einigung führte.

4. Am 24. Oktober 2019 reichte die Klägerin die Replik ein, darin hielt die Klägerin an den bisherigen Rechtsbegehren fest, mit einer Präzisierung des Rechtsbegehrens 2:

«2. Der Klägerin sei im Anschluss an die Rechnungslegung und Auskunftserteilung gemäss Rechtsbegehren 1 Gelegenheit zu geben, den von der Beklagten an sie zu bezahlenden finanziellen Wiedergutmachungsanspruch zu beziffern, und die Beklagte sei zu verpflichten, der Klägerin den so bezifferten Betrag, mindestens aber CHF 100'000, zuzüglich eines Schadenzinses von 5% p.a. zu bezahlen.

und dem prozessualen Antrag: Es sei der Beklagten umgehend eine Frist von vier Wochen zur Einreichung der Duplik anzusetzen.»

5. Am 20. Januar 2020 reichte die Beklagte die Duplik ein mit den folgenden Rechtsbegehren:

«1. Auf die Klage sei nicht einzutreten.

2. Eventualiter:

Die Klage sei vollumfänglich abzuweisen.

3. Unter Kosten- und Entschädigungsfolgen (inkl. Auslagenersatz für den notwendigerweise beigezogenen Patentanwalt).»

6. Am 24. Februar 2020 reichte die Klägerin die Stellungnahme zur Duplik ein.

7. Am 29. April 2020 erstattete Richter Daniel Vogel sein Fachrichtervotum.

8. Die Stellungnahmen der Parteien dazu erfolgten je mit Eingabe vom 16. Juni 2020.

9. Am 30. Juni 2020 fand die Hauptverhandlung statt.

Prozessuales

10. Die Klägerin ist eine Gesellschaft mit beschränkter Haftung mit Sitz in Deutschland. Die Beklagte ist eine Aktiengesellschaft mit Sitz in der Schweiz. Gemäss Art. 1 Abs. 2 IPRG i.V.m. Art. 2 Abs. 1 und Art. 60 Abs. 1 lit. a des Übereinkommens über die gerichtliche Zuständigkeit und die Anerkennung und Vollstreckung von Entscheidungen in Zivil- und Handelssachen (LugÜ, SR 0.275.12) sowie Art. 26 Abs. 1 lit. a PatGG ist die örtliche und sachliche Zuständigkeit des Bundespatentgerichts gegeben.

11. Die Klägerin bedient sich der deutschen Sprache, die Beklagte anfänglich der italienischen Sprache (Klageantwort), später ebenfalls der deutschen Sprache. Verfahrenssprache ist deutsch (Art. 36 Abs. 1 PatGG).

12. Das Verfahren wird einstweilen auf die Frage der Auskunftserteilung und Rechnungslegung beschränkt (Art. 85 Abs. 2; Art. 125 lit. a ZPO).

13. Gemäss Art. 110 Abs. 1 IPRG ist schweizerisches Recht anwendbar.

Rechtsschutzinteresse

14. Prozessvoraussetzung ist unter anderem ein schutzwürdiges Interesse des Klägers (Art. 59 Abs. 2 lit. a ZPO). Erforderlich ist im Regelfall ein persönliches Interesse des Klägers, das in dem Sinn rechtlicher Natur ist, als die verlangte Leistung, die anbegehrte Feststellung oder Gestaltung einer Rechtslage ihm einen Nutzen eintragen muss.1

15. Die Beklagte bestreitet einerseits, dass Art. 66 PatG eine genügende Rechtsgrundlage für die verlangten Auskünfte bilde. Dieser Einwand ist bei der materiellen Begründetheit zu prüfen.

Andererseits behauptet die Beklagte, die für die Bezifferung der (bestrittenen) finanziellen Ansprüche der Klägerin notwendigen Informationen seien öffentlich zugänglich. So seien auf der Website der Beklagten die Zahl der Kunden, der Werbekampagnen und der aktiven Nutzer zu erfahren.

Wie die Klägerin zu Recht bemerkt, erlauben die öffentlich zugänglichen Angaben auf der Website der Beklagten es ihr nicht, ihre finanziellen Wiedergutmachungsansprüche zu beziffern. Die Angaben erlauben weder die Bezifferung des Brutto-Umsatzes noch Rückschlüsse auf den Gewinn, zudem sind sie veraltet (stammt von Anfang 2018, siehe S. 53). Die Klägerin hat daher einen Nutzen an den verlangten Auskünften, erlauben es diese ihr doch, ihre angeblichen finanziellen Wiedergutmachungsansprüche (genauer) zu beziffern.

Das Rechtsschutzinteresse der Klägerin ist daher ausgewiesen.

Bestimmtheit der Rechtsbegehren

16. Ein Rechtsbegehren ist so bestimmt und präzis abzufassen, dass sich mit hinreichender Deutlichkeit erkennen lässt, was der Kläger anstrebt, und dass das Rechtsbegehren bei Gutheissung der Klage ohne Weiteres zum richterlichen Urteil erhoben werden kann.2

Die genügende Bestimmtheit des Rechtsbegehrens ist Prozessvoraussetzung und damit von Amtes wegen zu prüfen, wobei das Bundespatentgericht eine unzureichende Bestimmtheit mangels entsprechender Rüge nur

1 BGE 122 III 279 E. 3a; Urteil 4A_127/2019 vom 7. Juni 2019, E. 4. 2 BGE 137 III 617 E. 4.3; BGer, Urteil A-7040/2009 vom 30. März 2011, E. 3.2.

sehr zurückhaltend annimmt. Folge der mangelnden Bestimmtheit ist Nichteintreten auf die Klage.3

17. Gemäss der Beklagten sind die Auskunfts- und Rechnungslegungsbegehren «weder zweckmässig, noch erforderlich, noch ist der Beklagten möglich, diesen im anbegehrten Umfang überhaupt nachzukommen». Die Beklagte könne über die Empfänger der Token und Sekundärmarkt-Transaktionen aus technischen Gründen keine Angaben machen. Entsprechend seien die Rechtsbegehren unbestimmt und auf die Klage nicht einzutreten.

Die Beklagte bemängelt bei Lichte besehen, dass die Auskunftsbegehren zu weitgehend und/oder objektiv nicht erfüllbar seien. So ist das Begehren «Angabe sämtlicher Primär- und Sekundärmarkt-Transaktionen, bei denen entsprechende Token gegen andere Token ausgegeben, umgetauscht, ge- oder verkauft wurden, unter Angabe der Tokens und deren Anzahl, dem Tauschverhältnis und Tauschzeitpunkt, sowie der jeweiligen Kurse der Token in CHF» durchaus bestimmt, aber es kann sein, dass die Beklagte ohne Verschulden nicht im Besitze dieser Informationen ist und sich diese Informationen auch nicht beschaffen kann. Dann ist das Rechtsbegehren im entsprechenden Umfang materiell abzuweisen. Offenbar erkennt die Beklagte, was von ihr verlangt wird; sie kritisiert, dass sie nicht in der Lage sei, das Verlangte zu leisten. Eine Unbestimmtheit, die zum Nichteintreten führt, liegt nicht vor.

Daher ist auf die Klage einzutreten.

Materielles

Aktivlegitimation der Klägerin

18. Wer über eine ausschliessliche Lizenz verfügt, ist unabhängig von der Eintragung der Lizenz im Register selbständig zur Klage nach Art. 72 oder Art. 73 PatG berechtigt, sofern dies im Lizenzvertrag nicht ausdrücklich ausgeschlossen worden ist (Art. 75 Abs. 1 PatG).

19. Die Beklagte bestreitet die Aktivlegitimation der Klägerin. Die Klägerin habe

3 BPatGer, Urteil O2012_004 vom 24. August 2012, E. 9 – «Leichtbeton»; Teilurteil

O2017_007 vom 1. November 2019, E. 15 – «Beatmungsgerät».

den ausschliesslichen Lizenzvertrag, aus dem sie ihre Klageberechtigung ableite, nicht eingereicht. Daher sei nicht erstellt, dass der Lizenzvertrag die Klageberechtigung nicht ausdrücklich ausschliesse. Die Zeichnungsberechtigung des angeblichen Verwaltungsratspräsidenten der AC Technologies SA sei nicht belegt, und die Unterzeichnung der Bestätigung des Lizenzvertrags sei in Dubai erfolgt, obwohl die AC Technologies SA ihren Sitz in Luxemburg habe. Folglich sei die Wirksamkeit des Lizenzvertrags nach dem anwendbaren Recht zu überprüfen.

20. Die Klägerin reicht zum Nachweis ihrer Klageberechtigung eine Bestätigung der im schweizerischen Patentregister eingetragenen Inhaberin des Patents CH EP 1 151 591 B1 (Klagepatent) ein, der AC Technologies SA, Leithum, Luxemburg. Gemäss der Bestätigung hat die Patentinhaberin der Klägerin eine ausschliessliche Lizenz am Klagepatent erteilt und die Klägerin hat das Recht, das Klagepatent gegen Dritte gerichtlich durchzusetzen. Die Bestätigung ist unterzeichnet von Joachim Günster, Vorsitzender des Verwaltungsrates der AC Technologies SA. Ausweislich des Handelsregisterauszugs der AC Technologies SA ist Joachim Günster einzelzeichnungsberechtigter Geschäftsführer-Direktor der AC Technologies SA.

Das Gericht muss nach freier Beweiswürdigung (Art. 157 ZPO) überzeugt sein, dass die Klägerin ausschliessliche Lizenznehmerin am Klagepatent ist und dass ihre Berechtigung zur selbständigen Klage nicht vertraglich ausgeschlossen wurde. Aufgrund der vorliegenden Bestätigung ist das Gericht überzeugt, dass die Klägerin zur selbständigen Klage ermächtigt ist. Dass die Bestätigung nicht am Sitz der Lizenzgeberin unterzeichnet wurde, vermag ihre Gültigkeit nicht in Frage zu stellen. Ein Anspruch auf Vorlage des vollständigen Lizenzvertrags besteht nicht; der Beweis kann auch auf anderem Weg erbracht werden.

Die Klägerin kann die Ansprüche aus der Verletzung des Klagepatents daher selbständig geltend machen.

Klagepatent

21. Das Klagepatent EP 1 151 591 B1 wurde 11. Januar 2000 angemeldet und seine Erteilung am 22. September 2004 veröffentlicht. Das Klagepatent beansprucht die Priorität der DE19900636 vom 11. Januar 1999.

Das Klagepatent betrifft die Speicherung von und den Zugriff auf Daten in verteilten und vernetzten Rechnerstrukturen (Abs. [0001]).

Im Unterschied zu verteilten und vernetzten Rechnerstrukturen, bei denen Daten von einem zentralen Rechnersystem, mit einem oder mehreren Servern, zur Verfügung gestellt werden, betrifft das Klagepatent ein dezentrales vernetztes System zur Datenverwaltung, das ohne eine zentrale Steuerung auskommt, da die Daten dezentral durch die Teilnehmer des Systems gespeichert und verwaltet werden (so genanntes «Peer to Peer Protokoll»).

Die Erfindung soll eine möglichst schnelle Versorgung mit Daten ermöglichen, wobei zusätzlich gewährleistet sein soll, dass die Übertragungen möglichst fehlertolerant durchgeführt werden (Abs. [0010]). Des Weiteren soll die Erfindung die Funktionsfähigkeit des verteilten, vernetzten Rechnersystems auch bei einem Ausfall von Daten bereitstellenden Einrichtungen und von einzelnen Netzwerkbereichen sicherstellen (Abs. [0011]).

Der Wortlaut der geltend gemachten Ansprüche 1 und 30 des Klagepatents wird bei der Auslegung in E. 28 wiedergegeben.

Technologischer Hintergrund

22. Die Klägerin behauptet, das Klagepatent lasse sich auf die Blockchain- Technologie, insbesondere die so genannte «Ethereum Blockchain», lesen. Es ist deshalb notwendig, kurz einige technische Grundlagen der Ethereum-Blockchain darzustellen. Dabei wird darauf verzichtet, die Technologie umfassend zu erklären, und nur auf diejenigen Aspekte vertieft eingegangen, die für das vorliegende Urteil relevant sind. Soweit nicht anders angegeben, sind die Ausführungen zum technologischen Hintergrund unbestritten und entstammen dem Parteigutachten von Björn Scheuermann vom 25. März 2019.

Ethereum ist eine quelloffene, global dezentralisierte Software, die Programme ausführt, die als «smart contracts» bezeichnet werden. Sie verwendet eine Blockchain, um die Zustandsänderungen des Systems zu synchronisieren und zu speichern, zusammen mit einer Kryptowährung namens «Ether», um die Kosten der Ausführungsressourcen zu messen und zuzuteilen. Anders als die bekannte Bitcoin-Blockchain besteht der Zweck von Ethereum nicht in erster Linie darin, ein Zahlungsnetzwerk für Kryptowährungen zu sein. Während die Kryptowährung Ether sowohl integraler

Bestandteil als auch notwendig für den Betrieb von Ethereum ist, ist Ether als Gebrauchswährung gedacht, um die Nutzung der Ethereum-Plattform zu bezahlen.

Ethereum ist ein verteiltes System, dessen Teilnehmer das Ethereum-eigene Peer-to-Peer-Netzwerk nutzen, um Daten ohne einen zentralen Server auszutauschen. Da dieses Netzwerk über eine vorhandene Netzwerk- Infrastruktur realisiert wird, wird es auch als «Overlay-Netzwerk» bezeichnet.

Alle Teilnehmer von Ethereum arbeiten mit einer gemeinsamen Datenbasis, der Ethereum-Blockchain. Die Sicherheit des Systems hängt massgeblich davon ab, dass alle Teilnehmer die gleiche Sicht auf die in der Blockchain gespeicherten Daten haben und stets auf dem aktuellsten Stand sind. Daher tauschen sich Kommunikationspartner bei jedem Verbindungsaufbau über ihren jeweiligen Stand der Blockchain aus. Stellt ein Teilnehmer durch diesen Austausch fest, dass seine lokale Blockchain nicht der aktuellsten Version im Netzwerk entspricht, so startet er eine Synchronisation der fehlenden Blöcke über den sogenannten Downloader, eine Teilkomponente der Ethereum-Software.

Am Peer-to-Peer Netzwerk teilnehmende Rechner werden auch als «Knoten» oder «nodes» des Netzwerks bezeichnet. Speichert ein Knoten die gesamte Ethereum-Blockchain, wird er als «Full Node» bezeichnet. Er entspricht unstrittig einer «Datenspeichereinheit» des geltend gemachten Anspruchs. Speichert ein Knoten nur den Teil der Blockchain, der für ihn relevant ist, spricht man von einem «Light Node», der unstrittig einer «Rechnereinheit» im Sinne des Klagepatents entspricht.

Die Netzwerk-Verwaltung in Ethereum gliedert sich in drei Hauptbestandteile: Die sogenannte Peer Discovery, die Peer-Verwaltung und darauf aufbauend das Ethereum-Protokoll. Das Zusammenspiel der einzelnen Komponenten der Netzwerk-Verwaltung bestimmt die Menge an aktiven Kommunikationsverbindungen, die ein Knoten unterhält.

In der Regel ist die Sicht eines Netzwerkknotens auf das gesamte Netzwerk unvollständig. Das Ziel der Peer Discovery ist es, geeignete Knoten für potentielle Overlay-Verbindungen zu finden. Jeder Netzwerkknoten umfasst eine Tabelle mit den ihm bekannten Knoten. Die Zeilen der Tabelle werden als «Buckets» bezeichnet. Jeder Bucket enthält maximal 16 Nach- barn einer bestimmten logischen Distanz zum eigenen Knoten. Jedem Bucket ist eine sogenannte Replacement List vorgeschaltet, in der maximal zehn Knoten in einem Ringpuffer gespeichert werden. Soll ein neuer Knoten in einen bereits gefüllten Bucket hinzugefügt werden, so werden alle bestehenden Einträge um eine Position nach hinten verschoben und der letzte Eintrag entfernt.

Es gibt verschiedene Mechanismen, über die ein Netzwerkknoten von anderen Nachbarn erfahren kann, die hier nicht weiter erläutert werden. Wichtig im vorliegenden Zusammenhang ist, dass ein zweistufiger Prozess durchlaufen werden muss, bevor ein Nachbar in der lokalen Tabelle gespeichert wird. Der Prozess besteht aus einem Bonding sowie gegebenenfalls der sogenannten Revalidation.

Das Bonding soll sicherstellen, dass der Nachbarknoten tatsächlich existiert und aktiv kommuniziert. Dazu wird eine Ping-Nachricht an den potentiellen Nachbarn geschickt, welche mit einer Pong-Nachricht beantwortet werden muss. Der Ping/Pong-Austausch muss dabei nicht unbedingt erfolgreich sein. Nach Beendigung des Bondings wird der Knoten dem Bucket hinzugefügt, wenn der Bucket noch nicht voll ist. Ansonsten wird der Knoten in die Replacement List eingetragen, deren bestehende Einträge um eine Position nach hinten verschoben und der letzte Eintrag entfernt.

In Abständen von 0 bis 10 Sekunden wird die Revalidation der Knoten im Bucket durchgeführt. Dazu wird der letzte Knoten in einem Bucket ausgewählt und eine Ping-Nachricht an den besagten Knoten gesendet. Falls innerhalb von 0,5 Sekunden eine Pong-Nachricht empfangen wird, bleibt der Knoten im Bucket und wird an die vorderste Position des Buckets gesetzt. Falls der Empfänger der Ping-Nachricht nicht innerhalb der Zeitfrist antwortet, so wird der entsprechende Knoten durch einen zufälligen Knoten aus der Replacement List ersetzt.

Das beschriebene Verhalten der Tabelle sorgt dafür, dass die Reihenfolge der Nachbarn innerhalb eines Buckets ihre Aktivität widerspiegelt: Der erste Knoten ist dabei der zuletzt aktive, während der letzte am längsten nicht aktiv war. Die Sortierung erfolgt implizit. Bleiben Nachbarn inaktiv, beispielsweise, weil die Datenübertragung zwischen den Nachbarn derzeit gestört oder sehr langsam ist, dann werden sie früher oder später durch aktivere ersetzt. Die Sortierung der Knoten in den Buckets wird somit durch die mittels der Ping- und Pong-Nachrichten ermittelte Nachrichtenlaufzeit beeinflusst.

Die vorstehend beschriebene Peer-Discovery-Tabelle dient als Grundlage für die Peer-Verwaltung in Ethereum, auch DevP2P genannt. DevP2P baut Verbindungen zu anderen Knoten auf/ab und verwaltet die aktiven Kommunikationsverbindungen, basierend auf den Daten der Peer Discovery. Die Peer Discovery sucht neue Nachbarn und liefert diese als mögliche Kandidaten für einen Verbindungsaufbau an die Peer-Verwaltung. Basierend auf diesen Vorschlägen baut die Peer-Verwaltung neue Verbindungen auf und formt dementsprechend das Overlay-Netzwerk. Die eigentlichen Netzwerkprotokolle (wie z.B. das Ethereum-Protokoll) versenden ihre Daten (zum Beispiel Transaktionen und Blöcke) über diese Verbindungen.

Die maximale Anzahl von gleichzeitig aktiven Verbindungen ist auf insgesamt 25 beschränkt. Wenn nicht alle ausgehenden Verbindungsslots ausgefüllt sind, werden Verbindungsaufbauten zu möglichen Nachbarn, die in der Peer-Discovery-Tabelle gespeichert werden, gestartet. Unter Weglassung der Details ist festzuhalten, dass die Auswahl der Knoten aus der Peer-Discovery-Tabelle, zu denen eine Verbindung aufgebaut wird, von der impliziten Sortierung der Knoten in den Buckets in dem Sinne beeinflusst wird, dass ein Verbindungsaufbau zu einem aktiveren Knoten mit geringerer Antwortzeit wahrscheinlicher ist.

Verletzungshandlungen

23. Die Beklagte vertreibt eine Applikation für mobile Plattformen namens «Friendz App», mit der Nutzer digitale Inhalte teilen können. Für die Erstellung von (erfolgreichen) digitalen Inhalten und die Interaktion mit solchen Inhalten erhalten die Nutzer so genannte «Z-Credits», die gegen «Friendz- Token» eingetauscht werden können. Beim «Friendz-Token» handelt es sich um einen Token (eine auf der Blockchain transferierbare Einheit), der auf dem ERC20-Standard («Ethereum Request for Comments 20») beruht. Der ERC20-Standard definiert, welche Funktionen ein Smart Contract besitzen muss, um als ERC20-Token zu gelten.

Im März 2018 führte die Beklagte eine «Initial Coin Offering» durch, d.h. interessierte Dritte konnten im Tausch gegen die Kryptowährung «Ether» Friendz-Token erwerben. Nach Angaben der Beklagten wurden insgesamt 392 Millionen Friendz-Token verkauft und 22’868 Einheiten «Ether» eingenommen, was im März 2018 einem Gegenwert von USD 10 Mio. bis USD 20 Mio. entsprach (da der Ether-Kurs in dem Zeitraum stark schwankte, ist keine genauere Angabe möglich).

Die Klägerin argumentiert, dass Transaktionen mit Friendz-Token (wie der Versand an externe Empfänger), die mit der beklagtischen «Friendz App» ausgeführt werden können, dazu führen, dass ERC-Token bzw. entsprechende Transaktionen von Smart Contracts in der Ethereum-Blockchain abgebildet werden. Da die Ethereum-Software in bestimmten Konstellationen die geltend gemachten Ansprüche des Klagepatents verletze, sei der Vertrieb etc. der «Friendz App» eine der Beklagten zuzurechnende patentverletzende Handlung.

Die Beklagte bestreitet einerseits, dass die Ethereum-Software in den Schutzbereich des Klagepatents fällt (dazu hinten, E. 35 ff.). Andererseits macht sie geltend, die nachweislich dezentralisierten und unabhängigen Rechner- und Speichereinheiten samt aller Transaktionen unbekannter Dritter könnten der Beklagten patentrechtlich überhaupt nicht zugerechnet werden.

Zu letzterem Argument der Beklagten ist zu sagen, dass derjenige, der ein patentrechtlich geschütztes Verfahren oder eine geschützte Vorrichtung benützt, sich nicht dadurch der Verantwortung entziehen kann, dass die Vorrichtung in fremden Eigentum steht oder das Verfahren von Dritten durchgeführt wird, wenn die Vorrichtung oder das Verfahren unter seiner Kontrolle stehen. Die von der Beklagten emittierten Friendz-Token beruhen auf der Ethereum-Software. Transaktionen mit ihnen sind ohne Benutzung der Ethereum-Software nicht möglich. Indem die Beklagte Token emittiert, die auf dem ERC20-Standard beruhen, benutzt sie wissentlich und willentlich die Ethereum-Software. Dass diese auf Rechnern läuft, die ihr nicht gehören, spielt keine Rolle.

Bezüglich Sekundärmarkt-Transaktionen mit Friendz-Token ist die Beklagte zumindest als Gehilfin i.S.v. Art. 66 lit. c PatG zu betrachten, soweit die Sekundärmarkt-Transaktionen als widerrechtliche Haupttaten zu qualifizieren sind. Die Friendz-Token haben keinen anderen Zweck, als mit Hilfe der Ethereum-Blockchain übertragen zu werden, was der Beklagten bewusst ist. Durch die Schaffung der Token ermöglicht die Beklagte erst solche Transaktionen und begünstigt sie damit i.S.v. Art. 66 lit. d PatG.

Nicht zu beantworten ist vorliegend die Frage, ob die Benutzung der Ethereum-Software durch Anwender im Ausland eine Verletzung des schweizerischen Teils eines europäischen Patents darstellt. Die Frage kann offengelassen werden, weil die Ethereum-Software nicht in den

Schutzbereich der geltend gemachten Ansprüche eingreift (hinten, E. 35 ff.).

24. Erstmals anlässlich der Hauptverhandlung bringt die Beklagte vor, das von der Klägerin beschriebene Szenario (d.h. dass ein Knoten A des Peer-to- Peer-Netzwerks ausfällt, kurz nachdem er Daten an einen anderen Knoten C übermittelt hat, dieser andere Knoten C den Ausfall bemerkt und eine Verbindung mit einem weiteren Knoten D aufnimmt, der die von A an C übermittelten Daten noch nicht gespeichert hat und sie deshalb von C kopiert) sei von vielen Zufällen abhängig. Es könne zwar theoretisch vorkommen, aber die Klägerin habe nicht nachgewiesen, dass dieses Szenario im Ethereum-Overlay tatsächlich vorgekommen sei. Entsprechend habe die Klägerin – selbst wenn das beschriebene Szenario patentverletzend wäre, was die Beklagte bestreitet – nicht nachgewiesen, dass es tatsächlich zu Patentverletzungen gekommen sei. In einem komplexen System könnten zufällig fast alle Schrittfolgen irgendwann einmal auftreten. Ein Patent, das auf eine bestimmte Abfolge von Schritten gerichtet sei, werde nicht dadurch verletzt, dass eine Vorrichtung das Potenzial habe, diese Abfolge zufällig zu verwirklichen.

Das Argument, dass sich das von der Klägerin zur Begründung der Patentverletzung herangezogene Szenario tatsächlich nie, oder bloss zufällig, im Ethereum-Overlay verwirklicht habe, ist eine neue Tatsachenbehauptung. Nach Eintritt des Aktenschlusses können neue Tatsachenbehauptungen nur unter den Voraussetzungen von Art. 229 Abs.1 ZPO vorgebracht werden. Bei der Behauptung handelt es sich ersichtlich nicht um eine Tatsache, die erst nach Abschluss des Schriftenwechsels entstanden ist (echtes Novum). Die Beklagte begründet auch nicht, weshalb sie die Behauptung trotz zumutbarer Sorgfalt nicht vorher aufstellen konnte (unechtes Novum). Nachdem die Klägerin das entsprechende Szenario bereits in der Klageschrift vom 26. April 2019 verwendet hat, um die Patentverletzung zu begründen, ist nicht erkennbar, weshalb die Beklagte die entsprechende Behauptung nicht bereits in der Klageantwort oder spätestens in der Duplik hätte in den Prozess einbringen können.

Die Behauptung, das von der Klägerin beschriebene Szenario gemäss Klageschrift, RZ 85 f., komme tatsächlich im Ethereum-Overlay nicht vor, ist daher verspätet und nicht zu hören.

Massgeblicher Fachmann

25. Die Kenntnisse und Fähigkeiten des massgeblichen Fachmannes sind in zwei Schritten zu bestimmen: Zuerst ist das für die zu beurteilende Erfindung massgebliche Fachgebiet, anschliessend Niveau und Umfang der Fähigkeiten und Kenntnisse des Fachmannes des entsprechenden Fachgebiets zu bestimmen. Das massgebliche Fachgebiet bestimmt sich nach dem technischen Gebiet, auf dem das von der Erfindung gelöste Problem liegt.4

Die Fähigkeiten und Kenntnisse des Fachmannes umschreibt das Bundesgericht mit der Formulierung, der durchschnittlich gut ausgebildete Fachmann, auf den bei der Beurteilung der erfinderischen Tätigkeit abgestellt werde, sei «weder ein Experte des betreffenden technischen Sachgebiets noch ein Spezialist mit hervorragenden Kenntnissen. Er muss nicht den gesamten Stand der Technik überblicken, jedoch über fundierte Kenntnisse und Fähigkeiten, über eine gute Ausbildung sowie ausreichende Erfahrung verfügen und so für den in Frage stehenden Fachbereich gut gerüstet sein».5 Was dem fiktiven Fachmann fehlt, ist jede Fähigkeit des assoziativen oder intuitiven Denkens.6

Wo ein Problem mehrere technische Gebiete beschlägt, kann die fiktive Fachperson aus einem Team von Fachleuten aus unterschiedlichen Fachgebieten gebildet werden.7

26. Das Klagepatent verweist beim Hintergrund der Erfindung auf die Optimierung des Zugriffs auf Daten und deren Bearbeitung in verteilten und vernetzten Rechnerstrukturen (Abs. [0001).

Die Parteien definieren nicht ausdrücklich einen massgeblichen Fachmann. Die Klägerin weist darauf hin, dass der Fachmann Netzwerktopologien und Verbindungsgestaltungen zwischen Client und Datenspeicher beurteilen kann. Die Beklagte gibt als technisches Gebiet des Klagepatents

4 BPatGer, Urteil S2017_001 vom 1. Juni 2017, E. 4.4. 5 BGE 120 II 71 E. 2. 6 BGE 120 II 312 E. 4b – «cigarette d‘un diamètre inférieur»; CR-PI-LBI- SCHEUCHZER, Art. 1 N 122. 7 BGE 120 II 71 E. 2 – «Wegwerfwindel»; BPatGer, Urteil S2017_001 vom 1. Juni

2017, E. 4.4.

dezentrale Rechnersysteme zur Dateiverwaltung an, und verweist in diesem Zusammenhang im Anschlusssatz auf den Fachmann.

Als massgeblicher Fachmann wird folglich von einem Informatiker oder Software Ingenieur ausgegangen, insbesondere auf dem Gebiet verteilter und vernetzter Rechnerstrukturen für die Datenverwaltung.

Auslegung der geltend gemachten Patentansprüche

27. Patentansprüche sind aus der Sicht des massgebenden Fachmanns im Lichte der Beschreibung und der Zeichnungen auszulegen (Art. 51 Abs. 3 PatG). Das allgemeine Fachwissen ist als sogenannter liquider Stand der Technik ebenfalls Auslegungsmittel.8 Definiert die Patentschrift einen Begriff nicht abweichend, so ist vom üblichen Verständnis im betreffenden technischen Gebiet auszugehen.

Patentansprüche sind funktional auszulegen, d.h. ein Merkmal soll so verstanden werden, dass es den vorgesehenen Zweck erfüllen kann.9 Der Anspruch soll im Zweifelsfall so gelesen werden, dass die im Patent genannten Ausführungsbeispiele wortsinngemäss erfasst werden;10 andererseits ist der Anspruchswortlaut nicht auf die Ausführungsbeispiele einzuschränken, wenn er weitere Ausführungsformen erfasst.11 Wenn in der Rechtsprechung von einer «breitesten Auslegung» von Anspruchsmerkmalen gesprochen wird,12 so muss das derart verstandene Merkmal immer in der Lage sein, seinen Zweck im Rahmen der Erfindung zu erfüllen. D.h. der Anspruch ist grundsätzlich nicht unter seinem Wortlaut auszulegen, aber auch nicht so, dass Ausführungsformen erfasst werden, die die erfindungsgemässe Wirkung nicht erzielen.13

Die Entstehungsgeschichte bzw. das Erteilungsverfahren sind für die Auslegung der Patentansprüche nicht massgebend. Verzichte und Beschränkungen, die der Anmelder im Erteilungsverfahren vorgenommen hat, sind

8 BGer, Urteil 4A_541/2013 vom 2. Juni 2014, E. 4.2.1 – «Fugenband». 9 BRUNNER, Der Schutzbereich europäisch erteilter Patente aus schweizerischer

Sicht – eine Spätlese, sic! 1998, 348 ff., 354. 10 BPatGer, Urteil O2019_003 vom 19. August 2020, E. 22 – «Lumenspitze». 11 BPatGer, Urteil O2013_008 vom 25. August 2015, E. 4.2 – «elektrostatische

Pulversprühpistole». 12 BPatGer, Urteil O2013_008 vom 25. August 2015, E. 4.2 – «elektrostatische

Pulversprühpistole». 13 BPatGer, Urteil O2016_009 vom 18. Dezember 2018, E. 25 – «Durchflussmessfühler»; BPatGer, Urteil S2018_007 vom 2. Mai 2019, E. 14 – «Werkzeugeinrichtung».

nur insoweit zu berücksichtigen, als sie in den Patentansprüchen sowie allenfalls in der Beschreibung zum Ausdruck kommen.14 Einzig wenn aufgrund eines im Erteilungsverfahren eingeschränkten Anspruchs Schutz gegen eine Verletzung durch Nachahmung (äquivalente Verletzung) verlangt wird, kann ganz ausnahmsweise die Erteilungsgeschichte diesem Schutz entgegenstehen, wenn aus der Einschränkung ein Verzicht auf bestimmte äquivalente Ausführungsformen abgeleitet werden kann.15

28. Der geltend gemachte Anspruch 1 lautet in der Merkmalsgliederung gemäss Klagebeilage Nr. 23 wie folgt:

Datenzugriffs- und -verwaltungssystem für ein Rechnersystem mit

2. wenigstens einer Rechnereinheit (CL), die auf Daten der Datenspeichereinrichtungen (C) zugreift, 3. Datenübertragungseinrichtungen (N) zur Datenübertragung zwischen den Datenspeichereinrichtungen (C) und der Rechnereinheit (CL), 4. wobei die Daten in wenigstens zwei der wenigstens zwei Datenspeichereinrichtungen (C) redundant gespeichert sind, 5. Einrichtungen zur Erfassung vorbestimmter Parameter der Datenübertragung zwischen den Datenspeichereinrichtungen (C) und der Rechnereinheit (CL),

6. wobei Daten in Abhängigkeit von den ermittelten vorbestimmten Parametern in den Datenspeichereinrichtungen (C) redundant gespeichert sind, 7. und wobei die Rechnereinheit (CL) in Abhängigkeit von den ermittelten vorbestimmten Parametern auf eine der Datenspeichereinrichtungen (C) zugreift,

8. dadurch gekennzeichnet, dass die Datenspeichereinrichtungen (C) Einrichtungen zur Erfassung vorbestimmter Parameter für Datenübertragung zwischen den Datenspeichereinrichtungen (C) umfassen, 9. und wobei die Datenspeichereinrichtungen (C) unabhängig von einem Zugriff der Rechnereinheit (CL) in dem System redundant gespeicherte Daten in Abhängigkeit der ermittelten Parameter von Datenübertragungen zwischen den Datenspeichereinrichtungen (C) verschieben.

14 BGE 143 III 666 E. 4.3 – «Pemetrexed II». 15 BGE 143 III 666 E. 5.5.3 f.

Der geltend gemachte Anspruch 30 lautet in der Merkmalsgliederung gemäss Klagebeilage Nr. 23 wie folgt:

Verfahren zum Datenzugriff und zur Datenverwaltung für ein Rechnersystem, das folgende Schritte umfasst:

1. Speichern von Daten in wenigstens zwei Datenspeichereinrichtungen (C), 2. Zugreifen auf die Daten der Datenspeichereinrichtungen (C) mittels wenigstens einer Rechnereinheit (CL) über Datenübertragungseinrichtungen (N), wobei 3. vorbestimmte Parameter der Datenübertragung zwischen den Datenspeichereinrichtungen (C) und der Rechnereinheit (CL) ermittelt werden,

4. die Daten in wenigstens zwei der wenigstens zwei Datenspeichereinrichtungen (C) in Abhängigkeit von den ermittelten Parametern der Datenübertragung redundant gespeichert werden, und 5. das Zugreifen auf die Daten in Abhängigkeit von den ermittelten Parametern der Datenübertragung erfolgt,

6. dadurch gekennzeichnet, dass die Datenspeichereinrichtungen (C) vorbestimmte Parameter für Datenübertragungen zwischen den Datenspeichereinrichtungen (C) erfassen, und

7. wobei redundant gespeicherte Daten unabhängig von einem Zugriff der Rechnereinheit (CL) auf die Daten in Abhängigkeit der ermittelten Parameter von Datenübertragungen zwischen den Datenspeichereinrichtungen verschoben werden.

Auslegung des Begriffs «Verschieben von Daten»

29. Gemäss dem üblichen Sprachgebrauch auf dem Gebiet der Computer- und Netzwerktechnologie bedeutet «Verschieben von Daten» etwas Anderes als «Kopieren von Daten». Während beim Kopieren die in einer Datenspeichereinheit gespeicherten Daten identisch in einer weiteren Datenspeichereinheit repliziert werden, umfasst das Verschieben von Daten aus einer Speichereinheit in eine andere Datenspeichereinheit zwingend zwei Teilschritte, ein Löschen oder ungültig Machen und ein Kopieren (ungültig gemacht sind die Daten, wenn das System davon ausgeht, dass die Daten nicht mehr verfügbar sind, unabhängig davon, ob sie tatsächlich unbrauchbar sind). Dies entspricht auch dem übereinstimmenden Verständnis der Parteien.

Abbildung 1: Abb. 3 aus Gutachten Björn Scheuermann vom 25. März 2019, S. 22

Ein unterschiedliches Verständnis der Parteien des Begriffs «Verschieben von Daten» offenbart sich erst an einem konkreten Beispiel. Es seien A, B, C und D in der Abbildung 1 Datenspeichereinheiten, die über bestehende Verbindungen verbunden sind (ausgezogene Linien) oder zwischen denen zukünftig eine Verbindung aufgebaut werden kann (gestrichelte Linie). Die Datenspeichereinheit A fällt aus, d.h. sie reagiert nicht mehr (rechtzeitig) auf Anfragen der Datenspeichereinheit C. Diese versucht dann, eine Verbindung mit einer weiteren Datenspeichereinheit D aufzubauen, mit der sie bislang nicht verbunden war. Nach dem Verbindungsaufbau mit D stellt die Datenspeichereinheit C fest, dass die Datenspeichereinheit D aktuell nicht alle Daten enthält, die in der ausgefallenen Datenspeichereinheit A gespeichert waren. Diese Daten, die redundant auch bereits bei C gespeichert sind, kopiert C an D. Damit verfügen C und D über die gleichen Daten, und D verfügt über die gleichen Daten wie die ausgefallene Datenspeichereinheit A.

Für die Klägerin liegt darin ein «Verschieben» von Daten: Die bisher bei A gespeicherten Daten seien dort (für C) nicht mehr zugänglich und würden zu D kopiert. Damit würden Daten ungültig gemacht und kopiert, also verschoben im Sinne des Anspruchs. Die Klägerin stützt sich für diese Auffassung primär auf Abs. [0190] des Klagepatents:

Aus dem ersten Spiegelstrich der Aufzählung ergebe sich, dass das Klagepatent das Kopieren von Daten (Spiegel) auf eine andere Datenspeichereinheit (Zellen) nach Ausfall einer Speichereinheit als «Verschiebeoperation», also «Verschieben», bezeichne.

Die Beklagte hält dem entgegen, es müsse ein kausaler Zusammenhang zwischen der Verlegung der Daten an einen anderen Speicherort und der fortan fehlenden Verwendbarkeit der Daten am ursprünglichen Speicherort bestehen. D.h. ein Verschieben sei nur dann gegeben, wenn im Rahmen des Verlegens der Daten neben dem Kopier- auch ein Löschvorgang oder ein ungültig Machen erfolge. Die Beklagte verweist dazu auf Abs. [0195] des Klagepatents. Dort wird ausgeführt, dass eine Datenspeichereinheit, für die eine unzureichende Datenübertragungsleistung festgestellt wird, aus dem Verbund entfernt wird und sich selbst für ungültig erklärt oder von der Verwaltungseinheit für ungültig erklärt wird.

Der von der Klägerin beschriebene Vorgang sei hingegen ein blosses Kopieren von Daten. Nach dem zufälligen Ausfall der Datenspeichereinheit A würden Daten von C nach D kopiert, die im Zeitpunkt des Ausfalls von A bereits in C gespeichert waren. Der Ausfall der Datenspeichereinheit A sei nicht kausal mit dem Kopieren verbunden.

30. Das beklagtische Verständnis entspricht dem üblichen Sprachgebrauch. Gemäss diesem umfasst das Verschieben von digitalen Daten notwendigerweise sowohl das Kopieren der Daten an einen neuen Speicherort als auch das Löschen oder ungültig Machen am alten Speicherort. Die beiden Teilschritte müssen für ein Verschieben insofern im Rahmen der gleichen Operation erfolgen, als bei einer ausgelösten Verschiebeoperation in einem Rechnersystem zwingend beide Teilschritte durch das Rechnersystem ausgeführt werden – das heisst, das Rechnersystem führt das Kopieren der Daten an einen neuen Speicherort aus und das Rechnersystem führt das Löschen oder ungültig Machen der Daten am alten Speicherort aus. Wird durch das Rechnersystem nur einer dieser beiden Teilschritte ausgeführt, handelt es sich um ein blosses Löschen oder ein blosses Kopieren. Die beiden Teilschritte müssen im Rahmen einer (Verschiebe)-operation erfolgen und sie müssen aufgrund der Auslösung dieser Verschiebeoperation ausgeführt werden.

Auch eine funktionale Auslegung führt zu keinem anderen Ergebnis. Die Erfindung bezweckt primär, die Versorgung von Clients mit Daten in einer vernetzten, verteilten Rechnerstruktur so zu optimieren, dass jeder Client möglichst schnell mit Daten versorgt wird (Abs. [0010]). Erreicht wird die schnelle Verfügbarkeit der Daten namentlich durch die Merkmale im Kennzeichen der unabhängigen Ansprüche. Wenn bei der Überwachung der Übertragungsleistung zwischen Datenspeichereinheiten festgestellt wird, dass eine Datenspeichereinheit die geforderte Leistung nicht erbringen kann, erfolgt ein Verschieben auf eine andere Datenspeichereinheit (Abs. [0192, 0193]). Dieses Verschieben erfüllt den erfindungsgemässen Zweck, wenn im Sinne des üblichen Sprachgebrauchs die Daten von der «langsamen» Speichereinheit kopiert und dort anschliessend ungültig gemacht werden. Es ist nicht notwendig oder sinnvoll, sie auf der «langsamen» Speichereinheit weiter bereit zu halten, also nur zu kopieren.

Der von der Klägerin zitierte Abschnitt [0190] aus dem speziellen Teil der Beschreibung stützt das klägerische Verständnis des Begriffs «Verschieben» nicht. Abs. [0190] zählt Gründe auf, die Verschiebeoperationen notwendig machen. Dazu gehört der Ausfall eines Clusters oder einzelner Zellen. Abs. [0190] besagt aber nicht, dass der Ausfall eines Clusters oder einzelner Zellen selber Teil einer Verschiebeoperation ist. Der Ausfall eines Clusters A kann es notwendig machen, dass Daten von einem Cluster B auf einen Cluster C verschoben werden. Der Ausfall von Cluster A mag dann eine Verschiebeoperation notwendig machen und diese auslösen. Der Ausfall von Cluster A ist aber nicht Teil einer Verschiebeoperation und wird auch nicht durch ein Rechnersystem aufgrund einer ausgelösten Verschiebeoperation ausgeführt.

Nicht massgeblich für das Auslegungsergebnis ist die Eingabe der Patentinhaberin im Erteilungsverfahren vom 17. Januar 2001. Dort wird zum geänderten Patentanspruch 1 ausgeführt, dieser sei durch die Merkmale ergänzt worden, «wonach die Datenspeichereinrichtungen Einrichtungen zur Erfassung vorbestimmter Parameter für Datenübertragungen zwischen den Datenspeichereinrichtungen umfassen und die Datenspeichereinrichtungen unabhängig von einem Zugriff der Rechnereinheit in dem System redundant gespeicherte Daten in Abhängigkeit der ermittelten Parameter für Datenübertragungen zwischen den Datenspeichereinrichtungen selbst untereinander kopieren und in den Datenspeichereinrichtungen löschen, in denen die kopierten Daten zuvor gespeichert waren […]». Weiter wird in der Eingabe gesagt, der geänderte Anspruch unterscheide sich von EP 767 585 A1 durch «die erfindungsgemässen Merkmale, wonach die Datenspeichereinrichtungen Parameter für Datenübertragungen untereinander erfassen und unabhängig von einem Datenzugriff redundante Daten verschieben (untereinander kopieren und entsprechend löschen)».

Die Erteilungsgeschichte ist für die Auslegung von Patentansprüchen nicht massgeblich. Sie kann in Ausnahmefällen für die Bestimmung des Schutzbereichs massgeblich sein, aber darum geht es vorliegend nicht.

Entsprechend ist der Begriff «Verschieben von Daten» i.S.d. Klagepatents so zu verstehen, dass das Verschieben zwei zwingend auszuführende Teilschritte aufweist, das Kopieren der Daten von ihrem ursprünglichen Speicherort an einen neuen Speicherort und das Löschen oder ungültig Machen dieser Daten an ihrem ursprünglichen Speicherort. Dabei sind beide Teilschritte als Teil und aufgrund einer ausgelösten Verschiebeoperation durch das Rechnersystem auszuführen. Bei einem Ausfall einer Datenspeichereinrichtung können zwar zufällig Daten gelöscht oder ungültig gemacht werden. Dieser zufällige Ausfall und der damit verbundene Datenverlust ist jedoch kein Schritt, der durch ein Rechnersystem aufgrund einer ausgelösten Verschiebeoperation ausgeführt wird. Es liegt also kein Teilschritt vor, der durch ein Rechnersystem im Rahmen und aufgrund einer ausgelösten Verschiebeoperation ausgeführt wird.

Auslegung des Begriffs «in Abhängigkeit von»

31. Der kennzeichnende Teil der geltend gemachten Ansprüche verlangt, dass Daten «in Abhängigkeit der ermittelten Parameter von Datenübertragungen zwischen den Datenspeichereinrichtungen» verschoben werden. Die Klägerin kritisiert das Fachrichtervotum vom 29. April 2020 dahingehend, dass dieses von einem dichotomen Verständnis von «Abhängigkeit» ausgehe; aus dem seitenübergreifenden letzten Absatz des Fachrichtervotums, S. 26, ergebe sich, dass der Fachrichter «in Abhängigkeit von» als ja/nein-Entscheidung verstehe. Dieses Verständnis sei falsch, vielmehr umfasse «in Abhängigkeit von» jede Art von Einflussnahme der Parameter der Datenübertragungen auf den Vorgang des Verschiebens.

Nach dem üblichen Sprachgebrauch bedeutet «abhängig» «durch etwas bedingt, bestimmt; von etwas beeinflusst». Damit ein Zustand B von einem anderen Zustand A abhängig ist, wird nicht verlangt, dass der Zustand B ausschliesslich von Zustand A bestimmt wird. So hängt der Pegelstand eines Stausees von der Regenmenge, aber auch von weiteren Faktoren wie der Abflussmenge oder der Schneeschmelze ab. Die Beziehung der Abhängigkeit ist nicht umkehrbar (z.B. hängt die Regenmenge nicht vom Pegelstand ab).

Nicht verlangt ist, dass der abhängige Zustand dichotom ist. Die von der Klägerin kritisierte Passage des Fachrichtervotums ist nicht in diesem Sinne zu verstehen. Eine Abhängigkeit besteht auch, wenn ein Zustand graduell von einem anderen Zustand beeinflusst wird.

Entsprechend ist «in Abhängigkeit von» dahingehend zu verstehen, dass ein Zustand einen anderen Zustand kausal beeinflusst, ohne dass es sich um den einzigen kausalen Einfluss handeln müsste, und ohne dass der beeinflusste Zustand dichotom sein muss.

Rechtsbeständigkeit

32. Die Beklagte wendet ein, das Klagepatent sei nicht rechtsbeständig, weil es in einer Weise geändert worden sei, dass sein Gegenstand über den Inhalt der Anmeldung in der ursprünglich eingereichten Fassung hinausgehe (Art. 123(2) EPÜ) und nicht erfinderisch sei ausgehend von WO 98/26559 A1 in Kombination mit WO 98/35302 A2. Die Klägerin verteidigt das Klagepatent in der erteilten Fassung.

Auf die Argumente der Parteien zur angeblich fehlenden Rechtsbeständigkeit des Klagepatents wird nicht weiter eingegangen, da die geltend gemachten Ansprüche bei richtiger Auslegung durch die Beklagte nicht verletzt werden.

Verletzung

33. Die Klägerin macht die Verletzung der Ansprüche 1 (Vorrichtungsanspruch) und 30 (Verfahrensanspruch) des Klagepatents geltend.

Die Beklagte bestreitet einerseits, dass ihr die Verwendung der Ethereum- Technologie zugerechnet werden kann (dazu vorne, E. 23). Weiter bestreitet sie, dass durch die Emittierung von ERC20-Token bzw. Transaktionen mit solchen Token auf der Ethereum-Blockchain die Merkmale 5, 6, 7, 8 und 9 des Anspruchs 1 und die Merkmale 3, 4, 5, 6 und 7 des Anspruchs 30 verwirklicht werden. Die Verwirklichung der weiteren Merkmale wird nicht bestritten und daher nachfolgend auch nicht weiter dargelegt.

Erfassung vorbestimmter Parameter der Datenübertragung (Merkmale 5, 6 und 8 von Anspruch 1 und Merkmale 3, 4 und 6 von Anspruch 30)

34. Gemäss Merkmal 5 umfasst das Datenverwaltungssystem Einrichtungen zur Erfassung vorbestimmter Parameter der Datenübertragung zwischen den Datenspeichereinrichtungen und der Rechnereinheit, wobei Daten in Abhängigkeit von den ermittelten vorbestimmten Parametern in den Datenspeichereinrichtungen redundant gespeichert sind (Merkmal 6) und die Einrichtungen zur Erfassung vorbestimmter Parameter für Datenübertragung zwischen den Datenspeichereinrichtungen Teil der Datenspeichereinrichtungen sind (Merkmal 8).

Die Beklagte wendet ein, dass die Klägerin pauschal den Ping-Mechanismus zur Erfassung bestimmter Datenübertragungsparameter (Nachrichtenlaufzeit) erwähne, ohne jedoch eine konkrete Verwendung bzw. die Datenspeicherung solcher Parameter innerhalb von Ethereum bzw. ERC20 zu belegen. Die Beklagte macht weiter eine fehlende Differenzierung seitens der Klägerin zwischen unterschiedlichen Parametern für die Datenübertragung geltend, und argumentiert mit Verweis auf die Merkmale 5, 6 und 8 von Anspruch 1 und die Merkmale 3, 4 und 6 von Anspruch 30, aus den Darlegungen der Klägerin gehe nicht hervor, dass einerseits vorbestimmte Parameter der Datenübertragung zwischen den Datenspeichereinrichtungen und der Rechnereinheit erfasst würden (Merkmal 5 des Anspruchs 1 bzw. Merkmal 3 des Anspruchs 30) und dass andererseits (andere) vorbestimmte Parameter der Datenübertragung zwischen den Datenspeichereinrichtungen erfasst würden (Merkmal 8 des Anspruchs 1 bzw. Merkmal 6 des Anspruchs 30). Die Klägerin versuche vielmehr, dieselben Daten einmal dem einen Aspekt und ein anderes Mal dem anderen Aspekt zuzuordnen. Die dem Gutachten Scheuermann zugrundeliegende Annahme, wonach im Rahmen des Klagepatents die Speichereinheiten auch über das Internet verbundene Clients sein könnten, treffe nicht zu, es ergäbe sich vielmehr aus Abs. [0073] des Klagepatents, dass die Daten gerade nicht vom bzw. auf dem Client gespeichert würden, sondern in von diesem zu unterscheidenden Datenspeichereinrichtungen.

Die Klägerin hält dem zutreffend entgegen, dass die Knoten (Nodes) des Ethereum-Netzwerks sowohl Clients/Rechnereinheiten als auch Datenspeichereinrichtungen sein können, da ein Knoten derart konfiguriert werden kann, dass er die gesamte Ethereum-Blockchain herunterlädt (Full Node) und für andere Knoten dann als Datenspeichereinrichtung fungiert, oder dass er lediglich diejenigen Teile der Ethereum-Blockchain herunterlädt, die für ihn relevant sind (Light Node), und im Sinne des Klagepatents als Rechnereinheit anzusehen ist.

Ob es sich bei der jeweils gemessenen Nachrichtenlaufzeit um einen Parameter der Datenübertragung zwischen Datenspeichereinrichtungen und der Rechnereinheit handelt oder um einen Parameter der Datenübertragung zwischen den Datenspeichereinrichtungen untereinander, liegt alleine daran, wo bzw. für welche Datenverbindung die Nachrichtenlaufzeit gemessen wird. Wenn die Nachrichtenlaufzeit zwischen dem Empfänger einer Transaktion (hier ein Light Node) und einem Full Node erfasst wird, wird ein Parameter der Datenübertragung zwischen Datenspeichereinrichtungen und der Rechnereinheit erfasst. Ein Parameter der Datenübertragung zwischen den Datenspeichereinrichtungen wird erfasst, wenn eine Nachrichtenlaufzeit zwischen den im Overlay verbundenen Instanzen der Ethereum-Software – und damit auch zwischen Datenspeichereinrichtungen – zum Einsatz kommt. Full Nodes, die alle Blöcke speichern, verteilen diese Blöcke auch untereinander über Datenverbindungen, für die Nachrichtenlaufzeiten erfasst werden und erfassen entsprechend Parameter der Datenübertragung zwischen den Datenspeichereinrichtungen.

Somit werden die Merkmale 5, 6, 7 und 8 des Anspruchs 1 und der Merkmale 3, 4, 5 und 6 des Anspruchs 30 bei der Emittierung von und Transaktionen mit ERC20-Token auf der Ethereum-Blockchain erfüllt.

Verschieben von redundant gespeicherten Daten unabhängig von einem Zugriff der Rechnereinheit in Abhängigkeit der ermittelten Parameter von Datenübertragungen zwischen den Datenspeichereinrichtungen (Merkmal 9 von Anspruch 1; Merkmal 7 von Anspruch 30)

35. Die Klägerin begründet die Verletzung der Ansprüche 1 und 30 durch das

Overlay-Netzwerk der Ethereum-Blockchain mit einem Szenario, das im Basisgutachten von Prof. Björn Scheuermann entwickelt wird (Kapitel 7, Seiten 21-22).

Im laufenden Betrieb von Ethereum könne es zu folgendem Szenario kommen (die Grossbuchstaben beziehen sich auf die Abbildung 1):

1. Knoten A schickt eine Ankündigung eines neuen Blocks X an C. Falls dieser aktueller ist als das bei Knoten C lokal bekannte Ende der Blockchain, dann wird C diesen Block von A anfordern. Danach liegt Block X sowohl bei A also auch bei C vor, er ist also redundant gespeichert.

2. Knoten A fällt aus. Hierdurch geht eine der redundanten Kopien von Block X verloren. Der Ausfall wird von C registriert, beispielsweise über ein Timeout. Dies führt dazu, dass Knoten C in seinen lokalen Peer-Discovery-Tabellen einen neuen Knoten als potentiellen Nachbarn sucht. Die Auswahl wird von den Eigenschaften der Datenübertragung zu potentiellen Kommunikationspartnern beeinflusst. Sei D der Knoten, den C als neuen Nachbarn wählt. Im Weiteren soll der Fall betrachtet werden, dass Knoten D der Block X noch nicht bekannt ist.

3. Eine Verbindung von C zu D wird aufgebaut. Dazu wird der nach der Protokollspezifikation notwendige Nachrichtenaustausch durchgeführt und dabei unter anderem der jeweilige Stand der lokal bekannten Blockchains übermittelt.

4. Knoten C stellt fest, dass seine lokale Blockchain aktueller («höher») ist als die von Knoten D, und insbesondere, dass der Block X bei D noch nicht vorliegt. Aufgrund der unterschiedlichen total difficulty zwischen Knoten C und Knoten D wird der Downloader aktiv. Knoten D fordert die bislang unbekannten Daten von Knoten C an und löst somit eine Übertragung des Blocks X von Knoten C an Knoten D aus; somit entsteht wieder eine redundante Kopie des Blocks.

Der Downloader in Ethereum, der bei Verbindungsausfällen aktiv werde, sorge folglich dafür, dass ein Block X von Knoten A mittels Knoten C auf den Knoten D verschoben werde, nachdem Knoten A ausgefallen sei. Es würden somit Daten (nämlich der Block X) zwischen Datenspeichereinrich- tungen (nämlich den Knoten A, C und D) unabhängig von der Rechnereinheit (nämlich Knoten B sowie einer Vielzahl weiterer Knoten) i.S.d. Anspruchs verschoben. Diese Verschiebung erfolge in Abhängigkeit von ermittelten Parametern der Datenübertragung, weil der Knoten, zu dem der Block X «verschoben» werde, gemäss der vorher gemessenen Nachrichtenlaufzeit ausgewählt werde.

Die Klägerin erachtet die Übertragung des Blocks X vom Knoten C an den Knoten D als unmittelbare Konsequenz des Ausfalls von Knoten A, weshalb sie ein anspruchsgemässes «Verschieben» des Blocks X durch den Knoten C vom ausgefallenen Knoten A an den Knoten D darstelle. So merkt die Klägerin in ihrer Stellungnahme zur Duplik an, dass das Übertragen einer Kopie des fraglichen Blocks X von Knoten C an Knoten D, in unmittelbarer Folge der neu aufgebauten Verbindung von C zu D ausgelöst werde, und dass insbesondere das Austauschen der Höhe der jeweiligen lokalen Blockchain beim Verbindungsaufbau eine entscheidende Rolle spiele, da diese Information benutzt werde, um die Synchronisation zu starten und so den Unterschied anzugleichen. Diese Synchronisation wiederum sei im betrachteten Szenario eine unmittelbare Konsequenz des Ausfalls von Knoten A, da ohne diesen Ausfall keine Verbindung zwischen Knoten C und D entstanden wäre.

Die Beklagte bestreitet, dass im Overlay-Netzwerk der Ethereum-Blockchain Daten i.S.d. Merkmals 9 (Merkmal 7 von Anspruch 30) verschoben werden. Die Beklagte hält mit Verweis auf Abs. [0010] des Klagepatents fest, dass es die Aufgabe des Klagepatents sei, die Übertragungsqualität zwischen Clients und Daten bereitstellenden Einrichtungen einer vernetzten, verteilten Rechnerstruktur so zu optimieren, dass eine möglichst schnelle und fehlertolerante Versorgung mit Daten/Funktionalitäten ermöglicht werden soll. Zudem solle die Erfindung gemäss Abs. [0016] des Klagepatents eine zusätzliche Optimierung des Datenzugriffs und der Datenverwaltung erreichen, wozu die Datenspeichereinrichtungen in dem System redundant gespeicherte Daten in Abhängigkeit der ermittelten Parameter von Datenübertragungen zwischen den einzelnen Datenspeichereinrichtungen und der Rechnereinheit untereinander kopieren und in den Datenspeichereinrichtungen löschen, in denen die kopierten Daten zuvor gespeichert waren, womit Daten innerhalb des erfindungsgemässen Systems von einer Datenspeichereinrichtung zu anderen Datenspeichereinrichtungen verschoben werden.

Auch in einer verteilten, vernetzten Rechnerstruktur sei der zur Verfügung stehende Speicherplatz begrenzt. Dies sei dem Fachmann bewusst, er würde also in einem System, wie es im Klagepatent beschrieben ist, nicht Daten wahllos vervielfältigen, zumal bei einer höheren Anzahl von Spiegeln der Aufwand für die Aktualisierung der Daten in allen Spiegeln stark ansteige, was wiederum – dem übergeordneten Ziel der Erfindung zuwiderlaufend – die verfügbaren Übertragungskapazitäten von den Datenspeichereinrichtungen zur Recheneinheit reduziere.

Bei Transaktionen mit den ERC20-Token der Beklagten werde die Lehre des Klagepatents nicht verwirklicht, denn auf der Ethereum-Blockchain erfolge kein Löschen selbst von als ungültig erkannten Blöcken und dies schon gar nicht in Abhängigkeit der ermittelten Parameter von Datenübertragungen zwischen Datenspeichereinrichtungen. Anders als bei den im Klagepatent beispielhaft aufgeführten Computerspielen müsse in einer Blockchain wie Bitcoin oder Ethereum jederzeit ein redundanter Datenbestand gewährleistet sein, was die Klägerin nicht bestreite (unter Verweis auf die Klage RZ 81 und die Replik RZ 40).

Der Ausfall des Knotens A könne nicht als Teil einer Verschiebeoperation aufgefasst werden, weil er das Kopieren erst auslöse. Dass der Ausfall des Knotens den Wegfall einer redundanten Kopie des Blocks X zur Folge hat, könne nicht mit einem Löschvorgang oder einem Ungültigmachen gleichgesetzt werden.

36. Gemäss der in E. 29 getroffenen Auslegung des Begriffs «Verschieben von Daten» umfasst ein Verschieben als zwingend auszuführende Teilschritte sowohl das Kopieren als auch das Löschen oder ungültig Machen der kopierten Daten am ursprünglichen Speicherort, wobei das Löschen und Kopieren in dem Sinne als Teilschritte ausgeführt werden, als sie beide im Rahmen einer durch das Rechnersystem ausgelösten Verschiebeoperation ausgeführt werden. Beim klägerischen Beispiel ist dies nicht der Fall. Auslöser des Kopierens der Daten von C nach D ist der Ausfall des Knotens A, der lokal eine ungenügende Redundanz der Daten bewirkt. Der Ausfall des Knotens A hingegen erfolgt durch beliebige Gründe. Der Ausfall des Knotens A ist damit kein Teil einer ausgelösten Verschiebeoperation und wird auch nicht durch ein Rechnersystem ausgelöst und als Teilschritt im Rahmen der ausgelösten Verschiebeoperation ausgeführt. Dadurch unterscheidet sich das von der Klägerin beschriebene Szenario auch von dem in Abs. [0190] erwähnten Ausfall eines Clusters, der ein Verschieben notwendig macht. Dort ist der Ausfall des Clusters Auslöser sowohl des Löschens/ungültig Machens als auch des Kopierens.

Weshalb die Daten ursprünglich vom zwischenzeitlich ausgefallenen Knoten A an den Knoten C kopiert wurden, ist nicht bekannt. Aber auf jeden Fall kann dieser Kopiervorgang nicht durch den Ausfall des Knotens A ausgelöst worden sein, weil nach dessen Ausfall die dort gespeicherten Daten nicht mehr kopiert werden können.

Mit anderen Worten löst der Ausfall des Knotens A zwar das Kopieren des Blocks X vom Knoten C an den Knoten D aus, ist aber unabhängig von diesem Kopieren in dem Sinne, dass der Ausfall nicht als Teilschritt und aufgrund einer ausgelösten Verschiebeoperation ausgeführt wird, sondern einen unbekannten, davon unabhängigen anderen Grund oder Auslöser hat. Da weder die Übertragung des Blocks X vom Knoten A an den Knoten C, noch die Übertragung des Blocks X vom Knoten C an den Knoten D einem anspruchsgemässen «Verschieben von Daten» entspricht, und da der Ausfall des Knotens A und der damit einhergehende Verlust der redundanten Kopie des Blocks X beim Knoten A nicht Teil des dadurch ausgelösten Kopierens des Blocks X vom Knoten C an den Knoten D ist, liegt kein anspruchsgemässes «Verschieben von Daten» vor.

Bei der angegriffenen Ausführungsform werden somit redundant gespeicherte Daten nicht gemäss Merkmal 9 von Anspruch 1 und Merkmal 7 von Anspruch 30 in Abhängigkeit von ermittelten Parametern von Datenübertragungen zwischen den Datenspeichereinrichtungen verschoben.

Folglich werden die geltend gemachten Ansprüche 1 und 30 des Klagepatents durch die Beklagte nicht verletzt.

Kosten und Entschädigungsfolgen

37. Ausgangsgemäss wird die Klägerin kosten- und entschädigungspflichtig (Art. 106 Abs. 1 ZPO). Ausgehend von einem Streitwert von CHF 400’000 ist die Gerichtsgebühr auf CHF 36’000 festzusetzen (Art. 1 Reglement über die Prozesskosten beim Bundespatentgericht, KR-PatGer, SR 173.413.2). Zu den Gerichtskosten gehören die Übersetzungskosten (Art. 95 Abs. 2 lit. d ZPO). Vorliegend sind Kosten in der Höhe von CHF 1’647.80 für die Dolmetscherin und die Miete der Flüsteranlage an der Instruktionsverhandlung angefallen. Diese Kosten sind zusammen mit der Gerichtsgebühr aus dem Kostenvorschuss der Klägerin zu beziehen; der Fehlbetrag von CHF 1’647.80 ist von der Klägerin nachzufordern (Art. 111 Abs. 1 ZPO).

Die Klägerin schuldet der Beklagten eine Entschädigung für die rechtsanwaltliche Vertretung (Art. 95 Abs. 3 lit. e ZPO), die gemäss Tarif auf CHF 40’000 festzusetzen ist (Art. 4, 5 KR-PatGer).

38. Die unterliegende Partei hat der obsiegenden Partei zudem Ersatz für deren notwendigen Auslagen zu erstatten (Art. 32 PatGG i.V.m. Art. 3 lit. a KR-PatGer; entspricht Art. 95 Abs. 3 lit. a ZPO). Praxisgemäss gehören die Auslagen für die patentanwaltliche Unterstützung im Prozess zu den notwendigen Auslagen. Sie sind bis zur tatsächlichen Höhe, oder, wenn diese die Entschädigung für die berufsmässige anwaltliche Vertretung gemäss Tarif übersteigt, «von der Grössenordnung her im Bereich der rechtsanwaltlichen Entschädigung» des Anwalts gemäss KR-PatGer zu erstatten.16

Die Beklagte reicht unter dem Titel notwendige Auslagen eine Kostennote der Kanzlei Keller & Partner Patentanwälte AG für die Unterstützung im Prozess in der Höhe von CHF 18’360 (zzgl. MwSt) ein. Diese Kosten erscheinen notwendig und angemessen und übersteigen den tariflichen Rahmen für die berufsmässige anwaltliche Vertretung nicht, weshalb sie der Beklagten von der Klägerin in dieser Höhe zu ersetzen sind.