4b O 16/16 – Datenweiterleitungsverfahren

Düsseldorfer Entscheidungs Nr.: 2522

Landgericht Düsseldorf

Urteil vom 24. Mai 2016, Az. 4b O 16/16

I. Der Antrag auf Erlass einer einstweiligen Verfügung wird zurückgewiesen.

II. Die Kosten des Verfahrens trägt die Verfügungsklägerin.

III. Das Urteil ist vorläufig vollstreckbar. Die Verfügungsklägerin kann die Vollstreckung durch Sicherheitsleistung in Höhe von 120 % des aus diesem Urteil zu vollstreckenden Betrages abwenden, wenn nicht die Verfügungsbeklagte vor der Vollstreckung Sicherheit in Höhe von 120 % des jeweils zu vollstreckenden Betrages leistet.

Tatbestand

Die Verfügungsklägerin nimmt die Verfügungsbeklagte im Wege der einstweiligen Verfügung wegen Verletzung des deutschen Teils des europäischen Patents 1 855 XXX B1 (Verfügungspatent, Anlage Ast18, in deutscher Übersetzung Anlage Ast19) auf Unterlassung in Anspruch.

Das Verfügungspatent wurde am 23.03.2007 von der A S.A., damals firmierend unter B S.A., später unter C S.A., unter Inanspruchnahme zweier französischer Prioritäten jeweils vom 10.05.2006 angemeldet. Die Offenlegung der Anmeldung erfolgte am 14.11.2007. Der Hinweis auf die Erteilung des Verfügungspatents wurde am 11.08.2010 veröffentlicht. Das Patent steht in Kraft.

Die D Europe Co. Ltd. hat unter dem 02.06.2014 Nichtigkeitsklage beim Bundespatentgericht eingereicht mit dem Antrag, das Verfügungspatent im Umfang der Ansprüche 1 und 12 für nichtig zu erklären. Mit Zwischenbescheid vom 05.10.2015 äußerte das Bundespatentgericht erhebliche Zweifel am Rechtsbestand des Verfügungspatents (s. Anlage Ast2). Durch Urteil vom 13.01.2016 wies das Bundespatentgericht die Nichtigkeitsklage vollumfänglich zurück (Anlage Ast3).

Das Verfügungspatent bezieht sich auf ein Verfahren zur Weiterleitung von aus- und eingehenden Daten in ein NFC-Chipset. Die von der Verfügungsklägerin geltend gemachten Ansprüche 1 und 12 des Verfügungspatents, dessen Verfahrenssprache französisch ist, lauten in ihrer eingetragenen deutschen Übersetzung wie folgt:

1.
Datenrouting-Verfahren in einem Chipsatz, umfassend wenigstens einen Hostprozessor (HP1, HP2), eine Steuereinheit (NFCC) und eine kontaktlose Datensende-/ Empfangsschnittstelle (CLINT) vom RFID-Typ,
dadurch gekennzeichnet, dass es die folgenden Schritte umfasst, die darin bestehen:
– einen Datenwegeröffnungsbefehl (CMD), der einen in der kontaktlosen Datensende-/Empfangsschnittstelle (CLINT) lokalisierten Bestimmungspunkt (P3) benennt, mittels eines im Hostprozessor lokalisierten Ausgangspunktes (P1, P2) an die Steuereinheit zu senden,
– als Antwort auf den Datenwegeröffnungsbefehl (CMD) mittels der Steuereinheit (NFCC) einen Datenweg zu eröffnen, der den Ausgangspunkt mit dem Bestimmungspunkt verbindet, wobei dem Datenweg eine Routingkanalnummer (CHANi) zugewiesen wird und wobei die Routingkanalnummer sowie wenigstens einen Identifizierer (iDsp) des Ausgangspunktes und einen Identifizierer (iDsp) des Bestimmungspunktes umfassende Routingparameter in eine Routing-Tabelle (RT) eingetragen werden,
– für den Bestimmungspunkt bestimmte, in einem Datenübertragungsblock (DF), der ein die Routingkanalnummer umfassendes Header-Feld aufweist, verkapselte Daten mittels des Ausgangspunktes an die Steuereinheit (NFCC) zu senden und
– beim Empfang der in einem Datenübertragungsblock (DF), der ein die Routingkanalnummer umfassendes Header-Feld aufweist, verkapselten Daten mittels der Steuereinheit (NFCC), unter Verwendung der Routingkanalnummer als Index für die Auswahl des Bestimmungspunktes, einen Bestimmungspunkt der Daten in der Routing-Tabelle zu suchen und die Daten dann an den Bestimmungspunkt zu senden.

12.
Datensende-/Empfangsvorrichtung (NFCR2), umfassend eine kontaktlose Datensende-/Empfangsschnittstelle (CLINT) vom RFID-Typ, eine Steuereinheit (NFCC) und wenigstens einen Eingangs/Ausgangsport (INT1, INT2), um die kontaktlose Datensende-/Empfangsschnittstelle (CLINT) mit einem Hostprozessor (HP1, HP2) zu verbinden,
dadurch gekennzeichnet, dass die Steuereinheit (NFCC) konfiguriert ist, um:
– als Antwort auf einen Datenwegeröffnungsbefehl (CMD), der von einem in einem Hostprozessor (HP1, HP2) lokalisierten Ausgangspunkt gesandt wurde und der einen in der kontaklosen Datensende-/Empfangsschnittstelle (CLINT) lokalisierten Bestimmungspunkt (P3) benennt, einen Datenweg zwischen dem Ausgangspunkt und einem Bestimmungspunkt zu eröffnen, wobei dem Datenweg eine Routingkanalnummer (CHANi) zugewiesen wird und wobei die Routingkanalnummer sowie wenigstens einen Identifizierer (iDsp) des Ausgangspunktes und einen Identifizierer (iDsp) des Bestimmungspunktes umfassende Routingparameter in eine Routing-Tabelle (RT) eingetragen werden, und
– beim Empfang von in einem Datenübertragungsblock (DF), der ein die Routingkanalnummer umfassendes Header-Feld aufweist, verkapselten Daten, unter Verwendung der Routingkanalnummer als Index für die Auswahl des Bestimmungspunktes einen Bestimmungspunkt der Daten in der Routing-Tabelle zu suchen.

Bei der Verfügungsklägerin handelt es sich um eine Patentverwertungsgesellschaft, die 2011 auf Betreiben des französischen Staates zur Förderung des Patentwesens und der Verwertung insbesondere französischer Patente gegründet wurde. Seit dem 19.12.2014 ist sie ausschließliche Lizenznehmerin am Verfügungspatent (vgl. Anlage Ast 21/22).

Die Verfügungsbeklagte ist ein auf Vertrieb und Marketing spezialisierter Dienstleister, der auf der IFA 2015 in Berlin mit einem eigenen Messestand vertreten war. Auf diesem Messestand bewarb die Verfügungsbeklagte unter anderem Mobilfunkgeräte des Herstellers D.

Gegenüber der D Germany GmbH hat die Kammer durch Urteil vom 26.03.2015 (Az. 4b O 140/13, Anlage Ast 16) auf eine Verletzung des Verfügungspatents erkannt und zwar im Hinblick auf Mobilfunkgeräte mit dem NFC-Chip „E“ der Firma F (nachfolgend: angegriffene Ausführungsform I, hier nicht streitgegenständlich), der von dem HCI-Standard ETSI TS 102 622 (Anlage Ast 24/25) Gebrauch macht. Auf den Inhalt des Urteils wird Bezug genommen.

Die D Germany GmbH hat gegen das Urteil Berufung eingelegt, über die noch nicht entschieden ist. Den Antrag auf sofortige Einstellung der Zwangsvollstreckung hat das Oberlandesgericht Düsseldorf durch Beschluss vom 19.08.2015 zunächst zurückgewiesen. Nach dem Zwischenbescheid des Bundespatentgerichts stellte das Oberlandesgericht Düsseldorf die Zwangsvollstreckung aus dem Urteil der Kammer bis zum 13.01.2016 ein. Den darüber hinaus gehenden Antrag auf vorläufige Einstellung der Zwangsvollstreckung wies das Oberlandesgericht Düsseldorf durch Beschluss vom 26.01.2016 zurück (Anlage Ast 5).

Die Verfügungsbeklagte stellte auf der IFA 2015 unter anderem das „D G H“ und das „D G I“ aus, die beide den NFC-Chip „J“ der Firma F aufweisen (nachfolgend: angegriffene Ausführungsform II). Dieser macht – genauso wie der NFC-Chip „E“ – von dem HCI-Standard ETSI TS 102 622 Gebrauch und wird auch von den Smartphones „D K L“, „D G M“ und „D K N“ genutzt. Bezüglich dieser Mobilfunkgeräte mit dem NFC-Chip „J“ erließ die Kammer mit Beschluss vom 07.09.2015 eine einstweilige Verfügung gegen die Verfügungsbeklagte. In der auf den Widerspruch der Verfügungsbeklagten hin durchgeführten mündlichen Verhandlung am 08.10.2015 nahm die Verfügungsklägerin ihren Antrag auf Erlass der einstweiligen Verfügung zurück, nachdem die Verfügungsbeklagte den Zwischenbescheid des Bundespatentgerichts vom 05.10.2015 erhalten und vorgelegt hatte.

Mit dem vorliegenden Antrag greift die Verfügungsklägerin zwei weitere Smartphone-Modelle der Firma D an, nämlich das „D G O“ und das „D K P“. Das „D K P“ ist seit August 2015 auf dem Markt und mit dem NFC-Chip „J“ der Firma F ausgestattet. Das „D G O“ ist seit Ende November 2015 im Handel und nutzt den NFC-Chip „Q“ der Firma F. Auch der NFC-Chip „Q“ macht von dem HCI-Standard ETSI TS 102 622 Gebrauch.

Die Verfügungsklägerin ist der Ansicht, die den NFC-Chip „J“ und „Q“ aufweisenden Smartphones der Firma D würden von der Lehre des Verfügungspatents wortsinngemäß Gebrauch machen. Dies ergebe sich schon daraus, dass beide Chips in gleicher Weise von dem HCI-Standard ETSI TS 102 622 Gebrauch machen würden wie der „E“.

Der streitgegenständliche Standard ETSI TS 102 622 sehe statische und dynamische Pipes vor. Für die dynamischen Pipes sehe der Standard zwingend die Übertragung der die Zuordnung zwischen der Pipe-ID und den Gate-IDs wiedergebenden Routing-Tabelle im Rahmen der Befehle ADM_CREATE_PIPE, ADM_NOTIFY_CREATE_PIPE und ANY_OK zwischen den Hosts und dem Host Controller vor. Eine andere Möglichkeit zur Übertragung dieser Routing-Tabelle kenne der Standard nicht. Es sei aber erforderlich, dass der auf der UICC verortete Host in irgendeiner Weise über die mit einer vom Host-Controller vergebenen Pipe-ID verknüpften Datenwege informiert werden müsse.

Sie – die Verfügungsklägerin – habe die angegriffenen Ausführungsformen einem Test unterzogen und dabei festgestellt, dass mittels des Befehls „ADM_CREATE_PIPE“ dynamische Pipes erstellt werden. Dass es sich um dynamische Pipes handele, ergebe sich nicht nur aus der Benutzung des Befehls „ADM_CREATE_PIPE“, sondern auch aus dem Umstand, dass diesen Pipe-IDs von 06 und 08 zugewiesen seien. Hierbei handele es sich nach dem Standard (Abschnitt 4.4, Tabelle 3) eindeutig um dynamische Pipes.

Im Übrigen unterscheide die erfindungsgemäße Lehre nicht wie der Standard zwischen dynamischen und statischen Pipes. Auch die Verwendung statischer Routingkanalnummern führe nicht aus dem Schutzbereich des Verfügungspatents heraus. Der Standard gebe in Abschnitt 6.1.3.1 „ADM_CREATE_PIPE“ und in dem korrelierenden Standardabschnitt 6.1.3.2 „ADM_NOTIFY_PIPE_CREATED“ in den Tabellen 9, 10 und 11 zwingend die Speicherung einer Routingkanalnummer (Pipe-ID) sowie Identifizierern des Ausgangs- und des Bestimmungspunktes vor (sogenannte Routingparameter). Dies ergebe sich bereits aus dem Versenden der Routingparameter in der Tabelle 10 von dem Host-Controller an den anfragenden Host sowie auch aus der Versendung der Tabelle 11, die von dem Host-Controller an den Destination Host versandt werde. In beide Richtungen, mithin an den Ausgangspunkt und an den Bestimmungspunkt, werde die Tabelle mit den Routingparametern verschickt. Der Inhalt der Tabelle müsse daher in irgendeiner Form abgespeichert sein, was sich nicht zuletzt daraus ergebe, dass bei dem Versenden der Datenpakete nur eine Pipe-ID verwendet werde. Diese Pipe-ID könne als Routing-Information nur verwendet werden, wenn in einer Routingtabelle die zugehörigen Parameter eingetragen seien.

Soweit die Verfügungsbeklagte versuche, die Patentverletzung auf der Quellcodeebene zu bestreiten, überzeuge dies nicht. Zunächst sei festzustellen, dass die vorgelegten Quellcodedateien allein den Kartenemulationsmodus, nicht aber den Lesemodus betreffen würden. Auch bezüglich des Kartenemulationsmodus würden maßgebliche Programmdateien fehlen. Insbesondere ergebe sich aus den vorgelegten Dateien nicht, wie der Bestimmungspunkt der Daten ermittelt werde. Die vorgelegten Teile des Quellcodes würden vielmehr allein den Befehl ADM_CREATE_PIPE betreffen. Es sei aber Sache der Beklagten, im Wege ihrer sekundären Darlegungs- und Beweislast nachzuweisen, auf welche Weise der Bestimmungspunkt der Daten beim Routing bestimmt werde. Solange sie nichts anderes belege, müsse davon ausgegangen werden, dass hierzu auf den entsprechenden Identifizierer des Bestimmungspunktes in einer Routingtabelle zurückgegriffen werde.

Das von der Verfügungsbeklagten zu den Quellcodes vorgelegte Kurzgutachten des Herrn R (Anlage ASt 28 / HL 5) weise zwar auf die Nutzung von sogenannten C-Programmkonstanten hin, zugleich konzediere Herr R aber auch, dass die Pipe-ID für den in Benutzung zu nehmenden Datenweg aus einer vorgegebenen Menge von Kennungen ausgewählt werde. Diese vorgegebene Menge von Kennungen sei in einer Tabelle in einem Speicherbereich des Systems abgelegt. Die Tabelle mit den Pipe-Kennungen finde sich in der Datei „phSwpNFceeFeCommon.c“, Z. 69-99, oder in der Datei „phHci.h“, Z. 154-188. Zu jeder Pipe-Kennung werde die Kennung des Source Host, des Source Gate, des Destination Host und des Destination Gate gespeichert. Diese Informationen würden in dem Array „gphHciCmdParamSave“ gesammelt bzw. gespeichert. Diese würden dann in einer ANY_OK-Antwort gemäß Abschnitt 6.1.3 des HCI-Standards gesendet. Damit aber sei die Erzeugung und Verwendung einer Routing-Tabelle im Sinne der Merkmalsgruppe 3b) gegeben.

Soweit der Privatgutachter R erläutert habe, dass die Pipe-ID in ein Offset umgerechnet bzw. umformatiert würde, stehe dies einer Patentverwirklichung nicht entgegen, weil funktional die Pipe-ID für die Weiterleitung des entsprechend gekennzeichneten Datenpakets genutzt werde. Außerdem befasse sich die von der Verfügungsbeklagten in Bezug genommene Quellcode-Datei A 27 allenfalls mit der ersten Stufe der Etablierung entsprechender Gates. Die Beurteilung der Verwendung einer Routingtabelle erfolge auf einer sich anschließenden zweiten Stufe, nämlich wenn die dynamische Pipe zwischen den Gates bereits etabliert sei. Dazu verhalte sich die Quellcode-Datei A 27 allerdings nicht. Die von der Beklagten in diesem Zusammenhang genannten Möglichkeiten der Verwendung eines Algorithmus oder einer logischen Schaltung seien theoretischer Natur. Es fehle der Nachweis seitens der Beklagten, dass die angegriffenen Ausführungsformen das Routing der Daten tatsächlich ohne einen Rückgriff auf die Identifizierer des Ausgangs- und Bestimmungspunktes vornehmen.

Dem neuerlichen Verfügungsantrag fehle es nicht an der erforderlichen Dringlichkeit.

Bis zur Anbringung des ersten Verfügungsantrags habe sie – die Verfügungsklägerin – die Verfügungsbeklagte nicht gekannt. Erst im Zusammenhang mit der IFA-Messe im September 2015 sei sie auf die Vertriebsaktivitäten der Verfügungsbeklagten aufmerksam geworden. Die Verfügungsbeklagte handele überwiegend im Verborgenen. Auf den Internetseiten der D-Konzerngruppe finde sich kein Hinweis auf die Einbindung der Verfügungsbeklagten in die Vertriebsaktivitäten von D. Im Straßenbild sei die Verfügungsbeklagte nicht durch Geschäfte präsent.

Der ursprüngliche Antrag auf Erlass einer einstweiligen Verfügung sei nur deshalb zurückgenommen worden, weil er aufgrund des Zwischenbescheids des Bundespatentgerichts keine Aussicht auf Erfolg mehr gehabt habe. Es sei legitim, dass sie – die Verfügungsklägerin – dann zunächst den Ausgang des Nichtigkeitsverfahrens abgewartet habe. Nach der Entscheidung des Bundespatentgerichts vom 13.01.2016 sei die Dringlichkeit neu zu beurteilen. Erst in diesem Moment sei die Rechtsbeständigkeit des Verfügungspatents ausreichend gesichert gewesen. Die erneute Anbringung des Verfügungsantrags sei keineswegs rechtsmissbräuchlich. Denn aufgrund des Zwischenbescheids des Bundespatentgerichts habe ein sachlicher Grund vorgelegen, den Verfügungsantrag zurückzunehmen. Andernfalls hätte das Landgericht den ursprünglichen Antrag per Urteil zurückgewiesen.

Nach dem 13.01.2016 habe die Verfügungsklägerin die Produktpalette von D, die zwischenzeitlich umgestellt bzw. erweitert worden sei, neu recherchiert und insbesondere Tests dazu durchführen lassen, welche Chips in den aktuell vertriebenen Geräten von D benutzt und verbaut würden. Die entsprechenden Analyseberichte würden ihr erst seit kurzer Zeit vorliegen. Zeitgleich haben sie Vergleichsgespräche mit der D-Konzerngruppe geführt. Vor dem Hintergrund dieser Vergleichsgespräche habe es keinen Sinn ergeben, gegen die hiesige Verfügungsklägerin vorzugehen. Dies hätte vielmehr die Fortsetzung der Vergleichsgespräche gefährdet.

Mit ihrem am 22.02.2016 bei Gericht eingegangenen Schriftsatz beantragt die Verfügungsklägerin,

der Verfügungsbeklagten bei Meidung eines für jeden Fall der Zuwiderhandlung vom Gericht festzusetzenden Ordnungsgeldes bis zu 250.000,00 EUR, ersatzweise Ordnungshaft, oder einer Ordnungshaft bis zu sechs Monaten, im Falle wiederholter Zuwiderhandlung bis zu insgesamt zwei Jahren, wobei die Ordnungshaft an dem jeweiligen Geschäftsführer der Verfügungsbeklagten zu vollziehen ist, zu untersagen,

1. Mobiltelefone im deutschen Geltungsbereich des EP 1 855 XXX B1 anzubieten und/oder zu liefern, die zur Ausübung eines Datenroutingverfahrens in einem Chipsatz geeignet sind, umfassend wenigstens einen Hostprozessor, eine Steuereinheit und eine kontaktlose Datensende-/ Empfangsschnittstelle vom RFID-Typ, wobei das Verfahren folgende Schritte umfasst, die darin bestehen:

– einen Datenwegeröffnungsbefehl (CMD), der einen in der kontaktlosen Datensende-/ Empfangsschnittstelle (CLINT) lokalisierten Bestimmungspunkt (P3) benennt, mittels eines im Hostprozessor lokalisierten Ausgangspunktes (P1, P2) an die Steuereinheit zu senden,

– als Antwort auf den Datenwegeröffnungsbefehl (CMD) mittels der Steuereinheit (NFCC) einen Datenweg zu eröffnen, der den Ausgangspunkt mit dem Bestimmungspunkt verbindet, wobei dem Datenweg eine Routingkanalnummer (CHANi) zugewiesen wird und wobei die Routingkanalnummer sowie wenigstens einen Identifizierer (iDsp) des Ausgangspunktes und einen Identifizierer (iDsp) des Bestimmungspunktes umfassende Routingparameter in eine Routing-Tabelle (RT) eingetragen werden,

– für den Bestimmungspunkt bestimmte, in einem Datenübertragungsblock (DF), der ein die Routingkanalnummer umfassendes Header-Feld aufweist, verkapselte Daten mittels des Ausgangspunktes an die Steuereinheit (NFCC) zu senden und

– beim Empfang der in einem Datenübertragungsblock (DF), der ein die Routingkanalnummer umfassendes Header-Feld aufweist, verkapselten Daten mittels der Steuereinheit (NFCC), unter Verwendung der Routingkanalnummer als Index für die Auswahl des Bestimmungspunktes, einen Bestimmungspunkt der Daten in der Routing-Tabelle zu suchen und die Daten dann an den Bestimmungspunkt zu senden,

und/oder

2. Datensende-/ Empfangsvorrichtungen (NFCR2) umfassend eine kontaktlose Datensende-/Empfangsschnittstelle (CLINT) vom RFID-Typ, eine Steuereinheit (NFCC) und wenigstens einen Eingangs/Ausgangsport (INT1, INT2), um die kontaktlose Datensende-/Empfangsschnittstelle (CLINT) mit einem Hostprozessor (HP1, HP2) zu verbinden,

im deutschen Geltungsbereich des EP 1 855 XXX B1 anzubieten, in Verkehr zu bringen oder zu gebrauchen oder zu den genannten Zwecken entweder einzuführen oder zu besitzen, wobei die Steuereinheit (NFCC) konfiguriert ist,

um als Antwort auf einen Datenwegeröffnungsbefehl (CMD), der von einem in einem Hostprozessor (HP1, HP2) lokalisierten Ausgangspunkt gesandt wurde und der einen in der kontaklosen Datensende-/Empfangsschnittstelle (CLINT) lokalisierten Bestimmungspunkt (P3) benennt, einen Datenweg zwischen dem Ausgangspunkt und einem Bestimmungspunkt zu eröffnen, wobei dem Datenweg eine Routingkanalnummer (CHANi) zugewiesen wird und wobei die Routingkanalnummer sowie wenigstens einen Identifizierer (iDsp) des Ausgangspunktes und einen Identifizierer (iDsp) des Bestimmungspunktes umfassende Routingparameter in eine Routing-Tabelle (RT) eingetragen werden, und beim Empfang von in einem Datenübertragungsblock (DF), der ein die Routingkanalnummer umfassendes Header-Feld aufweist, verkapselten Daten, unter Verwendung der Routingkanalnummer als Index für die Auswahl des Bestimmungspunktes einen Bestimmungspunkt der Daten in der Routing-Tabelle zu suchen.
Die Verfügungsbeklagte beantragt,

den Verfügungsantrag zurückzuweisen.

Zur Begründung ihrer Anträge führt die Verfügungsbeklagte aus, es fehle sowohl an einem Verfügungsanspruch als auch an einem Verfügungsgrund.

Bezüglich der hier streitgegenständlichen F-Controller „J“ und „Q“ sei die von der Verfügungsklägerin behauptete Patentverletzung nicht nachgewiesen.

In dem Hauptsacheverfahren 4b O 140/13 gegen die D Germany GmbH sei der Verletzungsvorwurf auf die Erzeugung sogenannter dynamischer Pipes im Card Emulation Mode unter Verwendung des Befehls „ADM_CREATE_PIPE“ gerichtet gewesen. Der Standard schreibe hingegen nicht vor, dass die Erzeugung der Pipes für die Nutzung des Card Emulation Modes erforderlich wäre. Es sei nach dem Standard auch möglich, eine Anzahl bereits in der Schnittstelle zwischen UICC Host und Host Controller fest implementierter Pipes zu verwenden. Eben so würden der „J“ und der „Q“ arbeiten, wodurch sie sich grundlegend vom „E“ unterscheiden würden. Die hier streitgegenständlichen Chips würden auf ein „Array“ fest im Chip implementierter statischer Pipes zurückgreifen, die bedarfsweise geöffnet und geschlossen würden. Auf einen CreatePipe-Befehl hin werde kein Datenweg neu erzeugt, sondern es würden bereits zuvor gespeicherte Informationen in einer Rückmeldung übermittelt, wenn ein existenter Datenweg in Benutzung genommen werde. Der existierende Datenweg könne als „gelöscht“, „geschlossen“ oder „offen“ markiert sein. Im Rahmen des CreatePipe-Befehls werde der Status „geschlossen“ gesetzt, so dass die Pipe durch einen nachfolgenden Befehl gesondert geöffnet werden könne. Die Pipes seien unveränderlich. Jeder Pipe sei eine Pipe-ID fest zugewiesen. Eine „Eröffnung“ eines Datenweges im Sinne des Verfügungspatents finde gerade nicht statt.

Auch werde für das Routing nicht – wie von der erfindungsgemäßen Lehre gefordert – auf eine Routing-Tabelle zurückgegriffen. Der Standard lasse gerade offen, wie das Routing vorgenommen werde; insbesondere erfordere er nicht zwingend den Rückgriff auf eine Routing-Tabelle. Abschnitt 8.1.1 beschreibe lediglich, wie der Host die Erzeugung einer dynamischen Pipe durch den Host-Controller anfordern könne. Im Wege der Nachricht ADM_CREATE_PIPE würden dem Host-Controller dabei die Parameter des Datenweges mitgeteilt, den dieser erzeugen solle, und dem Host durch den Host-Controller die Parameter des Datenweges im Wege der Nachricht ANY_OK (Tabelle 10 des Standards) bestätigt. Es finde sich aber im Standard kein Hinweis darauf, dass der Host-Controller für die Weiterleitung eines Datenpakets die Pipe-ID als Index in einer Routing-Tabelle suchen müsste, um ein Datenpaket an seinen Bestimmungspunkt weiterzuleiten.

Neben der Verwendung einer erfindungsgemäßen Routing-Tabelle gebe es alternative, in einer Steuereinheit zu implementierende Möglichkeiten, ein von einem Ausgangspunkt an eine Steuereinheit übermitteltes Datenpaket nur durch Auswertung der ihm beigefügten Routingkanalnummer an einen Bestimmungspunkt weiterzuleiten. So könne etwa die Steuereinheit mit einem Algorithmus den betreffenden logischen Eingang des Bestimmungspunktes aus der Routingkanalnummer errechnen. In diesem Fall sei das Wissen in dem Algorithmus und nicht in einer Routingtabelle enthalten. Weiter könnte die Steuereinheit auch mit einer (re-)konfigurierbaren logischen Schaltung den betreffenden logischen Eingang des Bestimmungspunktes aus der Routingkanalnummer bestimmen. Dies wiederum bedeute, dass das Wissen in der Schaltung selbst enthalten sei; diese setze einen Algorithmus in Hardware um. Beide dargestellten Lösungen seien klar von der Verwendung einer erfindungsgemäßen Routing-Tabelle zu unterscheiden.

Die angegriffenen Ausführungsformen würden die Datenweiterleitung mittels eines Algorithmus bewerkstelligen. Der diesbezügliche Quellcode sei für den „J“ und den „Q“ identisch. Die HCI-standardgemäße Implementierung basiere hier auf der Einbettung der möglichen Pipe-IDs als C-Programmkonstanten. Insofern komme sie ohne eine Routing-Tabelle aus. Es werde direkt mittels der Pipe-ID eine Funktion aufgerufen, um das Datenpaket weiterzuleiten. Wenn ein Datenpaket mit einer Pipe-Kennung im Header empfangen werde, werde zunächst ein Offset aus einer Look-Up-Tabelle entnommen. Das Array aPipePackLookup enthalte Offset-Werte für alle zulässigen Pipe-IDs. Das Offset diene der direkten Ermittlung der Routine, die für die restliche Verarbeitung des Pakets aufgerufen werden müsse. Dazu werde der ausgelesene Offset-Wert in eine Zahl zwischen 0 und 5 umformatiert, um anschließend aus der sechs Einträge umfassenden CommonPipeHandlerTable (Datei A 027 Z. 150-155) die zutreffende Funktion für die Weiterverarbeitung auszuwählen. Dementsprechend werde abhängig vom ermittelten Offset direkt eine Verarbeitungsfunktion für die Verarbeitung des Datenpakets am richtigen Gate aufgerufen. Die LookUpTable sei dabei keine erfindungsgemäße Routing-Tabelle, weil es ihr an der patentgemäß geforderten Eintragung sowohl der Routingkanalnummer als auch eines Identifizierers des Ausgangspunktes und eines Identifizierers des Bestimmungspunktes fehle.

Die vorstehenden Ausführungen würden in gleicher Weise für den Kartenemulations- und den Lesemodus gelten.

Im Übrigen fehle es aber auch an einem Verfügungsgrund, da eine Dringlichkeit für den Erlass der einstweiligen Verfügung nicht gegeben sei.

Der Verfügungsklägerin sei bereits seit langem bekannt, dass es sich bei der Verfügungsbeklagten um einen Vertriebspartner der D-Gruppe handele. Mit Schreiben vom 08. und 23.06.2015 habe die D Germany GmbH im Rahmen ihrer Auskunftserteilung darauf hingewiesen, dass die „S“ Vertriebspartner der D-Gruppe sei. Das D G H werde von der Verfügungsbeklagten bereits seit Anfang April 2015 vertrieben und sei Gegenstand der Unterlassungsvollstreckung aus dem Verletzungsverfahren gegen die D Germany GmbH gewesen. Die Verfügungsbeklagte bzw. ihre Rechtsvorgängerin, die T Germany GmbH, würde bereits seit vielen Jahren D-Mobiltelefone auf der IFA ausstellen. Die Unternehmensgruppe der Verfügungsbeklagten gelte als weltweit größter Distributor für Produkte aus dem Bereich der Informations- und Telekommunikationstechnologie. Dies sei den Fachkreisen hinlänglich bekannt. Insofern habe die Verfügungsklägerin – sollte sie tatsächlich keine positive Kenntnis von den Vertriebsaktivitäten der Verfügungsbeklagten gehabt haben – jedenfalls die Augen vor den vermeintlichen Verletzungshandlungen verschlossen. Auch in einem solchen Fall dürfe eine einstweilige Verfügung nicht erlassen werden.

Jedenfalls aber habe die Zurücknahme des ersten Verfügungsantrags durch die Verfügungsklägerin eine etwaige frühere Dringlichkeit endgültig entfallen lassen. Die Verfügungsklägerin habe ihren ersten Antrag bewusst noch während des anhängigen Rechtsbestandsverfahrens gestellt. Es sei allein ihre Entscheidung gewesen, sich in ein für sie unsicheres Verfahren zu begeben, ohne zunächst den Ausgang des Rechtsbestandsverfahrens abzuwarten. Der negative Zwischenbescheid des Bundespatentgerichts habe kein irgendwie geartetes Prozesshindernis dargestellt, sondern die Verfügungsklägerin habe sich dazu entschieden, ihren Antrag auf Erlass einer einstweiligen Verfügung zurückzunehmen. In einem solchen Fall könne eine Dringlichkeit nicht wieder aufleben.

Darüber hinaus stelle das Verhalten der Verfügungsklägerin nach der Verkündung der Entscheidung im Nichtigkeitsverfahren am 13.01.2016 ein zögerliches und nachlässiges Verhalten hinsichtlich der Rechtsverfolgung dar. Die Verfügungsklägerin habe über fünf Wochen seit der Entscheidung des Bundespatentgerichts abgewartet, bis sie mit dem vorliegenden Verfügungsantrag auf diese Entscheidung reagiert habe. Mit etwaigen Terminverschiebungen im Berufungsverfahren vor dem Oberlandesgericht könne die Verzögerung nicht gerechtfertigt werden. Denn dieses Berufungsverfahren werde nicht mit der hiesigen Verfügungsbeklagten, sondern mit der D Germany GmbH geführt. Gleiches gelte für etwaige Vergleichsgespräche zwischen der Verfügungsklägerin und der D-Konzerngruppe.

Die streitgegenständlichen Modelle aus dem ursprünglichen Verfügungsverfahren würden sich weiterhin sämtlich in Deutschland im Verkauf befinden. Dies könne durch einen kurzen Blick auf die Homepage von D festgestellt werden. Einer umfassenden neuen Recherche seitens der Verfügungsklägerin habe es nicht bedurft. Soweit die Verfügungsklägerin daneben nunmehr erstmals das D K P angreife, werde auch dieses Modell bereits seit Ende August 2015 auf dem deutschen Markt vertrieben. Insofern habe es die Verfügungsklägerin versäumt, dieses Modell schon in ihren ersten Verfügungsantrag aufzunehmen. Dies könne hingegen keine verlängerte Recherchezeit bei ihrem zweiten Antrag rechtfertigen. In Wikipedia gebe es eine Liste aller NFC-fähigen Endgeräte (vgl. Anlage HL7). Anhand dieser seien nicht nur die NFC-fähigen Geräte von D, sondern auch die Verwendung des jeweiligen F-Chips auf sehr einfache Weise festzustellen. Der von der Verfügungsklägerin behauptete mehrwöchige Rechercheaufwand sei vor diesem Hintergrund völlig übertrieben.

Im Hinblick auf das nunmehr erstmals angegriffene Modell „D G O“ mit dem F-Chip „Q“ könne eine Dringlichkeit ohnehin nicht aufleben, weil dieses Modell im Zeitpunkt des ersten Verfügungsverfahrens noch gar nicht auf dem Markt gewesen sei. Dieses sei vielmehr erst Ende November 2015 eingeführt worden, was die Verfügungsklägerin ohne weiteres den einschlägigen Fachmedien habe entnehmen können.

Wegen des weiteren Sach- und Streitstandes wird auf die zwischen den Parteien gewechselten Schriftsätze nebst Anlagen sowie auf das Protokoll der mündlichen Verhandlung vom 03.05.2016 verwiesen.
Entscheidungsgründe

Der zulässige Antrag auf Erlass einer einstweiligen Verfügung hat in der Sache keinen Erfolg. Es lässt sich im Rahmen des vorliegenden Verfügungsverfahrens nicht feststellen, dass der Verfügungsklägerin gegen die Verfügungsbeklagte ein Verfügungsanspruch zusteht.

I.
Die dem Verfügungspatent zugrunde liegende Erfindung betrifft ein Datenrouting-Verfahren in einem Chipsatz (Verfügungspatentschrift Abs. [0001]) sowie einen Datensende-/ Empfangsschaltkreis (Verfügungspatentschrift Abs. [0002]), jeweils umfassend eine kontaktlose Sende-/Empfangsschnittstelle vom RFID Typ (Radio Frequency Identification). Das Verfügungspatent betrifft dabei insbesondere die Umsetzung eines NFC(Near Field Communication)-Chipsatzes (Verfügungspatentschrift Abs. [0003]).

Bei RFID-Systemen („radio-frequency identification“) werden Daten auf einem elektronischen Datenträger – einem Transponder – gespeichert. Diese Daten können dann von einem Lesegerät unter Verwendung magnetischer oder elektromagnetischer Felder ausgelesen werden. Der Transponder besitzt dabei in der Regel keine eigene Spannungsversorgung. Er wird vielmehr erst aktiviert, wenn er sich in einem Lesebereich des Lesegeräts befindet. Die zum Betrieb des Transponders benötigte Energie wird über das magnetische oder elektromagnetische Feld des Lesegeräts an den Transponder übertragen. RFID-Systeme gestatten somit das automatisierte und berührungslose Identifizieren und Lokalisieren von mit einem Transponder versehenen Objekten bzw. das Erfassen von in einem Transponder enthaltenen Daten.

NFC betrifft eine drahtlose Datenschnittstelle zwischen elektronischen Geräten. Die Besonderheit der NFC-Technologie besteht darin, dass der Datenaustausch nur über kurze Strecken von einigen Zentimetern funktioniert, die am Datenaustausch beteiligten Geräte dementsprechend nah aneinander gehalten werden müssen. Die über ihre jeweilige NFC-Schnittstelle miteinander verbundenen Geräte verhalten sich dabei entsprechend einem RFID-Leser bzw. -Transponder, wobei im Unterschied zu der RFID-Technologie, bei der die passive Einheit (der Transponder) stets passiv ist, bei der NFC-Technologie Einheiten eingesetzt werden können, die sowohl aktiv als auch passiv, auch in wechselnden Rollen, operieren. Die NFC-Technologie ist durch verschiedene technische Standards der ISO, ECMA und ETSI spezifiziert.

Die Verfügungspatentschrift beschreibt NFC-Leser mit mehreren Betriebsmodi, nämlich einem „Leser“-Modus, einem „Kartenemulations“-Modus und einem „Device“-Modus. Im Leser-Modus funktioniert der NFC-Leser in aktiver Form durch Aussendung eines Magnetfeldes wie ein herkömmlicher RFID-Leser, um Lese- und Schreibzugriff auf einen RFID-Chip zu erhalten. Im Emulations-Modus funktioniert der NFC-Leser in passiver Form in der Art eines Transponders, um mit einem anderen, ein Magnetfeld aussendenden Leser zu kommunizieren und durch den anderen Leser wie ein RFID-Chip wahrgenommen zu werden. Im Device-Modus – der die NFC-Technologie auszeichnet – bringt sich der Leser alternierend in einen aktiven und in einen passiven Zustand der vorbeschriebenen Art (Leser- bzw. Kartenemulationsmodus), um mit einem anderen Leser Daten auszutauschen (Verfügungspatentschrift Abs. [0004]).

Aufgrund seiner weitreichenden Kommunikationskapazitäten wird der NFC-Leser in tragbare Vorrichtungen wie Mobiltelefone oder PDAs integriert. Hierzu wird ein NFC-Chipsatz benötigt, der einen NFC-Leser und mindestens einen Hostprozessor umfasst (Verfügungspatentschrift Abs. [0006]).

Die nachfolgend abgebildete Figur 1 der Verfügungspatentschrift zeigt den typischen Aufbau eines solchen NFC-Chipsatzes in Blockform und kontaktlose Schaltkreise, mit denen der Chipsatz kommunizieren kann:

Der NFC-Chipsatz ist durch das gestrichelte Rechteck auf der linken Seite der Abbildung umgrenzt. Er umfasst einen NFC-Leser (NFCR1), dem eine kontaktlose Schnittstelle zugeordnet ist (angedeutet durch die zu erkennende Spule), sowie zwei Hostprozessoren (HP1 und HP2). Den Begriff des Hostprozessors definiert die Verfügungspatentschrift dahingehend, dass hierunter ein integrierter Schaltkreis zu verstehen ist, der einen Mikroprozessor oder eine Mikrosteuereinheit umfasst und der mit dem Port eines NFC-Lesers verbunden ist (Verfügungspatentschrift Abs. 0006]). In Figur 1 teilen sich die beiden Hostprozessoren (HP1 und HP2) die Ressourcen des NFC-Lesers (NFCR1). Sie sind mit ihm über Ports verbunden und können mit ihm jeweils bidirektional kommunizieren (angedeutet durch die Pfeile).

Die Hostprozessoren verwalten über den NFC-Leser ihre jeweiligen kontaktlosen Anwendungen bzw. Dienste (sog. Apps). Über den NFC-Leser müssen deshalb ein- und ausgehende Datenflüsse von den in den Hostprozessoren ausgeführten Anwendungen oder Diensten abgewickelt werden. Das heißt, der NFC-Leser muss mit unterschiedlichen externen Schaltkreisen kommunizieren können (Verfügungspatentschrift Abs. [0006]). Die Umsetzung eines geeigneten NFC-Chipsatzes erfordert daher jedenfalls das Vorsehen eines Routings von Datenflüssen, die über einen bidirektionalen, kontaktlosen Datenübertragungskanal übertragen werden, zwischen den jeweiligen Hostprozessoren (HP1, HP2) und dem NFC-Leser (NFCR1) innerhalb des Chipsatzes (Verfügungspatentschrift Abs. [0007]).

Dieses Routing von Datenflüssen zwischen den jeweiligen Hostprozessoren und dem NFC-Leser beschreibt die Verfügungspatentschrift exemplarisch anhand der nachfolgend abgebildeten Figuren 3a und 3b:

Der NFC-Chipsatz der Figur 3a besteht aus zwei Hostprozessoren (HP1, HP2) sowie dem NFC-Leser (NFCR1; kleineres gestricheltes Rechteck). Letzterer wiederum umfasst eine kontaktlose Datensende-/Empfangsschnittstelle (CLINT), ausgestattet mit einem Antennenschaltkreis (ACT), zwei drahtgebundenen Kommunikationsschnittstellen (INT1, INT2) und einer Steuereinheit (NFCC). Die Kommunikationsschnittstellen sind einerseits mit der Datensende-/Empfangsschnittstelle (CLINT), andererseits mit den zwei außerhalb des NFC-Lesers befindlichen Hostprozessoren (HP1, HP2) verbunden.

Figur 3b stellt die den NFC-Chipsatz passierenden Datenflüsse von und zu von einem Hostprozessor (HP1, HP2) ausgeführten Anwendungen oder Diensten exemplarisch dar. Auf diese Weise können die Ressourcen der kontaktlosen Datensende-/ Empfangsschnittstelle (CLINT) durch die einzelnen Hostprozessoren verwendet werden. Dabei weisen die Datenflüsse jeweils einen Ausgangs- und einen Bestimmungspunkt auf. Je nachdem, in welche Richtung der Datenfluss erfolgt, ist der Ausgangs- oder Bestimmungspunkt entweder in einem Hostprozessor (HP1, HP2) oder in der kontaktlosen Datensende-/Empfangsschnittstelle (CLINT) lokalisiert (Verfügungspatentschrift Abs. [0009]).

Um das Routing der ausgehenden Daten und die Konfiguration der Schnittstelle CLINT zu ermöglichen, werden Datenübertragungsblöcke gebildet, die jeweils Header-Felder und Datenfelder umfassen. Die Header-Felder enthalten die zur Steuerung der Schnittstelle CLINT erforderlichen Informationen, insbesondere Felder mit Angaben über Datenausgangs- und Bestimmungspunkte (Verfügungspatentschrift Abs. [0011]).

Das aus dem Stand der Technik bekannte HCI-Protokoll sah ausweislich der Verfügungspatentschrift (Verfügungspatentschrift Abs. [0012]) Datenübertragungsblöcke mit langen und komplexen Header-Feldern vor. Dies hatte den Nachteil, dass ein erheblicher Verarbeitungsaufwand erforderlich war, bevor die eigentliche Datenverarbeitung stattfinden konnte. Dieses Problem wird auch als „overheading“ bezeichnet. Ein weiteres Problem im Stand der Technik bestand darin, dass die kontaktlose Datensende-/ Empfangsschnittstelle CLINT und die Steuereinheit NFCC nicht unbedingt wussten, an welchen Hostprozessor die eingehenden Daten gesendet werden sollen. Infolgedessen wurden die Daten an zwei Prozessoren übermittelt, wobei der Prozessor, den diese Daten nicht betrafen, nicht darauf antwortete (Verfügungspatentschrift Abs. [0014]).

Vor diesem Hintergrund formuliert die Verfügungspatentschrift die Aufgabe (das technische Problem), zum einen ein Datenrouting-Verfahren in einem NFC-Chipsatz bereitzustellen, das einfach umzusetzen ist und keine überlangen Header-Felder erfordert (Verfügungspatentschrift Abs. [0013]), und zum anderen ein Verfahren bereitzustellen, mit dem in einem NFC-Chipsatz der Hostprozessor festgestellt werden kann, der der Empfänger der über einen kontaktlosen Datenübertragungskanal empfangenen Daten ist, ohne dabei notwendigerweise den Inhalt dieser Daten analysieren zu müssen (Verfügungspatentschrift Abs. [0017]).

Dies sucht die Erfindung mit einem Datenroutingverfahren und einer Datensende-/ Empfangsvorrichtung nach den Ansprüchen 1 und 12 zu erreichen, die die folgenden Merkmale aufweisen:

Anspruch 1:
1. Datenrouting-Verfahren in einem Chipsatz
2. Der Chipsatz umfasst
a) eine Steuereinheit (NFCC),
b) eine kontaktlose Datensende-/ Empfangsschnittstelle (CLINT) vom RFID-Typ und
c) wenigstens einen Hostprozessor (HP1, HP2).
3. Das Verfahren umfasst die folgenden Schritte:
a) Senden eines Datenwegeröffnungsbefehls (CMD) mittels eines im Hostprozessor lokalisierten Ausgangspunktes (P1, P2) an die Steuereinheit,
a1) wobei der Datenwegeröffnungsbefehl einen in der kontaktlosen Datensende-/Empfangsschnittstelle (CLINT) lokalisierten Bestimmungspunkt (P3) benennt,
b) Eröffnen eines Datenweges mittels der Steuereinheit (NFCC) als Antwort auf den Datenwegeröffnungsbefehl (CMD),
b1) wobei der Datenweg den Ausgangspunkt mit dem Bestimmungspunkt verbindet,
b2) wobei dem Datenweg eine Routingkanalnummer (CHANi) zugewiesen wird und
b3) wobei die Routingkanalnummer sowie wenigstens einen Identifizierer (iDsp) des Ausgangspunktes und einen Identifizierer (iDsp) des Bestimmungspunktes umfassende Routingparameter in eine Routing-Tabelle (RT) eingetragen werden,
c) Senden von in einem Datenübertragungsblock (DF) verkapselten und für den Bestimmungspunkt bestimmten Daten an die Steuereinheit (NFCC) mittels des Ausgangspunktes,
c1) wobei der Datenübertragungsblock ein die Routingkanalnummer umfassendes Header-Feld aufweist,
d) Suchen eines Bestimmungspunktes der Daten in der Routing-Tabelle beim Empfang der in dem Datenübertragungsblock (DF) verkapselten Daten mittels der Steuereinheit (NFCC),
d1) wobei der Datenübertragungsblock ein die Routingkanalnummer umfassendes Header-Feld aufweist und
d2) wobei bei der Suche die Routingkanalnummer als Index für die Auswahl des Bestimmungspunktes verwendet wird,
e) Senden der Daten an den Bestimmungspunkt.

Anspruch 12
1. Datensende-/Empfangsvorrichtung (NFCR2)
2. Die Datensende-/Empfangsvorrichtung (NFCR2) umfasst:
a) eine Steuereinheit (NFCC),
b) eine kontaktlose Datensende-/Empfangsschnittstelle (CLINT) vom RFID-Typ und
c) wenigstens einen Eingangs/Ausgangsport (INT1, INT2), um die kontaktlose Datensende-/Empfangsschnittstelle (CLINT) mit einem Hostprozessor (HP1, HP2) zu verbinden.
3. Die Steuereinheit (NFCC) ist konfiguriert, um
a) als Antwort auf einen Datenwegeröffnungsbefehl (CMD) einen Datenweg zwischen dem Ausgangspunkt und einem Bestimmungspunkt zu eröffnen,
a1) wobei der Datenwegeröffnungsbefehl von einem in einem Hostprozessor (HP1, HP2) lokalisierten Ausgangspunkt gesandt wurde,
a2) wobei der Datenwegeröffnungsbefehl einen in der kontaklosen Datensende-/Empfangsschnittstelle (CLINT) lokalisierten Bestimmungspunkt (P3) benennt,
a3) wobei dem Datenweg eine Routingkanalnummer (CHANi) zugewiesen ist und
a4) wobei die Routingkanalnummer sowie wenigstens einen Identifizierer (iDsp) des Ausgangspunktes und einen Identifizierer (iDsp) des Bestimmungspunktes umfassende Routingparameter in eine Routing-Tabelle (RT) eingetragen werden,
b) beim Empfang von in einem Datenübertragungsblock (DF) verkapselten Daten einen Bestimmungspunkt der Daten in der Routing-Tabelle zu suchen,
b1) wobei der Datenübertragungsblock ein die Routingkanalnummer umfassendes Header-Feld aufweist und
b2) wobei bei der Suche die Routingkanalnummer als Index für die Auswahl des Bestimmungspunktes verwendet wird.

II.
Im Hinblick auf den Streit der Parteien bedarf die Merkmalsgruppe 3 der Ansprüche 1 und 12 näherer Erläuterung. Aus Gründen der Vereinfachung wird dabei auf die Merkmale des Anspruchs 1 abgestellt, die sich in Anspruch 12 in (weitgehend) gleicher Weise – jedoch teilweise mit etwas unterschiedlicher Bezifferung – wiederfinden.

Als einschlägigen Fachmann sieht die Kammer – wie das Bundespatentgericht – einen Diplom-Ingenieur der Fachrichtung Elektrotechnik oder Informationstechnik mit Spezialisierung auf dem Gebiet der Nahfeldkommunikation an.

Die Merkmalsgruppe 3 beschreibt die Umsetzung der erfindungsgemäßen Kommunikation innerhalb des Chipsatzes, also den Datenfluss im Chipsatz zwischen einem der Hostprozessoren (HP1, HP2) und der Schnittstelle (CLINT). Anschaulich wird dies anhand der nachstehend eingeblendeten Figur 4 der Verfügungspatentschrift:

Gezeigt ist ein erfindungsgemäßer NFC-Chipsatz mit zwei Hostprozessoren (HP1, HP2) und einem NFC-Leser (NFCR2). Der NFC-Leser umfasst die Steuereinheit NFCC und eine kontaktlose Datensende-/Empfangsschnittstelle CLINT. Die Ausgangs- oder Bestimmungspunkte eines Datenflusses im Chipsatz werden als P1 (im Hostprozessor 1 lokalisierter Punkt), P2 (im Hostprozessor 2 lokalisierter Punkt) und P3 (in der Schnittstelle CLINT lokalisierter Punkt) bezeichnet.

Gemäß Merkmal 3.a) wird zunächst mittels eines im Hostprozessor lokalisierten Ausgangspunktes (P1, P2) ein Datenwegeröffnungsbefehl an die Steuereinheit gesandt. Der Datenwegeröffnungsbefehl soll nach Merkmal 3.a)a1) den Bestimmungspunkt des Datenweges benennen, der in der kontaktlosen Datensende-/Empfangsschnittstelle lokalisiert ist. Auf diese Weise erhält die Steuereinheit die für die Identifizierung des Datenweges erforderlichen Routingparameter.

Unter Ausgangs- und Bestimmungspunkt sind dabei der Anfangs- und Endpunkt der jeweiligen Kommunikation im Chipsatz zu verstehen. Es kann sich dabei um Softwarekomponenten bzw. Anwendungen in den Hostprozessoren und den Komponenten des NFC-Lesers innerhalb des Chipsatzes handeln, von denen ein Datenfluss ausgehen kann oder die Empfänger eines solchen Datenflusses sein können (Verfügungspatentschrift Abs. [0065] sowie Unteransprüche 9 und 20).

Der Datenwegeröffnungsbefehl geht von dem Ausgangspunkt in einem Hostprozessor aus. Die eigentliche Erzeugung des Datenweges erfolgt sodann durch die Steuereinheit (NFCC) im NFC-Leser (NFCR) (Verfügungspatentschrift Abs. [0048]). Als Antwort auf den Datenwegeröffnungsbefehl wird mittels der Steuereinheit der angefragte Datenweg zwischen Ausgangs- und Bestimmungspunkt eröffnet (Merkmal 3.b). Der Begriff des „Eröffnens“ ist in der Verfügungspatentschrift nicht gesondert definiert. In funktionaler Hinsicht meint „Eröffnen“ das Festlegen/Bereitstellen eines Datenweges für einen zu einem späteren Zeitpunkt vorzunehmenden Datentransport.

Dieses Bereitstellen kann sowohl in der (erstmaligen) Erzeugung eines neuen Datenweges als auch in der Aufnahme der Benutzung eines schon bestehenden Datenweges liegen. Insofern kennt das Verfügungspatent auch die Möglichkeit, auf eine bereits voreingetragene Routingtabelle zurückzugreifen, indem in der Routing-Tabelle ein passender Datenweg gesucht wird, wenn Daten von der kontaktlosen Datensende-/Empfangsschnittstelle über einen kontaktlosen Datenübertragungskanal empfangen werden (Verfügungspatentschrift Abs. [0025], vgl. auch Abs. [0034], [0035]). Das erfindungsgemäße „Eröffnen“ des Datenweges besteht in diesem Fall darin, dass die Steuereinheit NFCC in das Feld „belegt“ den Wert „1“ einträgt (Verfügungspatentschrift Abs. [0050]). Ob und wann über den solchermaßen eröffneten Datenweg eine Datenübertragung stattfindet, kann Gegenstand eines gesonderten Befehls sein und hat in funktionaler Hinsicht nichts zu tun mit dem erfindungsgemäßen „Eröffnen“ des Datenweges.

Der „eröffnete“ Datenweg verbindet den Ausgangspunkt mit dem Bestimmungspunkt (Merkmal 3.b)b1)). Mit dem Eröffnen des Datenweges wird diesem zugleich eine Routingkanalnummer (CHANi) zugewiesen (Merkmal 3.b)b2)), die in eine Routing-Tabelle eingetragen wird (Merkmal 3.b)b3)). Der Routingkanalnummer werden in der Routing-Tabelle Routingparameter zugewiesen, die wenigstens einen Identifizierer des Ausgangspunktes und einen Identifizierer des Bestimmungspunktes des jeweiligen Datenweges (IDsp, IDdp) benennen (Merkmal 3.b)b3)). Auf diese Weise kann allein mit Hilfe der Routingkanalnummer durch einen Rückgriff auf die Routing-Tabelle der jeweilige Datenweg identifiziert werden.

Dies ermöglicht es, bei der Übermittlung von in einem Datenübertragungsblock verkapselten Daten ein Header-Feld zu verwenden, das lediglich die Routingkanalnummer ausweist und dementsprechend einfach und schnell verarbeitet werden kann (Merkmal 3.c)). Die Steuereinheit muss zu diesem Zweck lediglich die zu der entsprechenden Routingkanalnummer in der Routing-Tabelle abgespeicherten Routingparameter abrufen und auswerten (Merkmal 3.d)). Auf diese Weise kann der Bestimmungspunkt der Daten festgestellt werden (vgl. Merkmal 3.d)d2)), an den die Daten sodann gesandt werden (Merkmal 3.e)).

In funktionaler Hinsicht muss die Routing-Tabelle solchermaßen ausgestaltet sein, dass die Steuereinheit auf sie zugreifen und die Verknüpfung zwischen einer bestimmten Routingkanalnummer und den Identifizierern des zugehörigen Datenweges abfragen kann. Dabei lässt das Verfügungspatent offen, auf welche Weise dies gewährleistet wird, insbesondere, wie die Routing-Tabelle aufgebaut ist und wo sie gespeichert wird. Es genügt vielmehr jede Zuordnung von Identifizierern des Ausgangs- und Bestimmungspunktes zu einer Routingkanalnummer, die so gespeichert ist, dass der Host-Controller für das Datenrouting auf sie zugreifen kann. Werden die Ausgangs- und Bestimmungspunkte als Anfangs- und Endpunkte eines logischen Datenkanals verstanden, wie er etwa von verschiedenen Anwendungen und Diensten zum Datenverkehr verwendet wird (s.o.), muss mit dem Identifizierer der jeweilige Punkt bzw. der Dienst bezeichnet werden, von dem ein Datenfluss ausgeht bzw. der Empfänger eines solchen Datenflusses ist. Im Rahmen des Routings muss dann die Routingkanalnummer tatsächlich als Index für die Auswahl des Bestimmungspunktes verwendet werden (Merkmal 3.d)d2)).

III.
Vor diesem Hintergrund ist seitens der Verfügungsklägerin nicht hinreichend glaubhaft gemacht, dass Angebot und Lieferung der angegriffenen Ausführungsformen II und III eine mittelbare Verletzung von Anspruch 1 des Verfügungspatents im Sinne von § 10 Abs. 1 PatG oder eine unmittelbare Verletzung von Anspruch 12 des Verfügungspatents im Sinne von § 9 PatG begründen.

Denn es ist jedenfalls nicht hinreichend glaubhaft gemacht, dass beim Empfang von Daten gemäß der Merkmalsgruppe 3.d) der Bestimmungspunkt in einer Routing-Tabelle gesucht wird, wobei die Routingkanalnummer als Index für die Auswahl des Bestimmungspunktes verwendet wird. Dies lässt sich weder anhand des Standards noch anhand der von der Verfügungsbeklagten vorgelegten Auszüge aus dem Quellcode feststellen.

Zwischen den Parteien ist unstreitig, dass die angegriffenen NFC-Controller des Typs „J“ und des Typs „Q“ nach den Vorgaben des Standards ETSI TS 102 622 V11.0.0 (2011-09) arbeiten. Die Verfügungsklägerin hat von der Firma A verschiedene Tests durchführen lassen, die bestätigen, dass die streitgegenständlichen F-Chips in dem für die Entscheidung maßgeblichen Umfang gleich funktionieren (vgl. Anlagen Ast33, Ast34). Dies bestätigt auch die Verfügungsbeklagte, die unter Vorlage einer entsprechenden eidesstattlichen Versicherung des Herrn Dubois (Anlage HL9/HL9a) vorträgt, die Quellcodes der beiden Chips seien in den hier maßgeblichen Teilen identisch.

1.
Die Umsetzung des Standards durch die angegriffenen Ausführungsformen begründet – entgegen der Auffassung der Verfügungsklägerin – für sich genommen nicht die Verwirklichung der gesamten Merkmalsgruppe 3.

Der Standard betrifft eine logische Schnittstelle, die kontaktlose Anwendungen, gehostet auf der Universal Integrated Circuit Card (UICC), ermöglicht. Im speziellen wird eine Konfiguration beschrieben, bei der ein Host in der UICC eingebettet ist, wobei die UICC mit dem Host-Controller verbunden ist, der wiederum im kontaktlosen Frontend (CLF) eingebettet ist. Unter Host wird dabei eine logische Entität verstanden, die mindestens einen Dienst betreibt. Der Host-Controller ist ein Host, der auch für die Verwaltung des Hostnetzwerks zuständig ist. Jeder in einem Host betriebene Dienst verfügt über einen Eingangspunkt, der als Gate bezeichnet wird. Zwischen den Gates unterschiedlicher Hosts werden Kommunikationskanäle gebildet, die als Pipe bezeichnet werden.

Das im Standard beschriebene Datenrouting-Verfahren ist in Abbildung 2 der Anlage AST25 schematisch dargestellt:

Gezeigt ist das Datenrouting zwischen Host A und Host B mittels des als Steuereinheit fungierenden Host-Controllers. Sowohl der Host-Controller als auch die einzelnen Hosts weisen Administrations-Gates, ggf. Verwaltungsverknüpfungs-Gates und weitere Gates auf (Anlage Ast25 Kapitel 4.3). Zwischen den Gates gibt es logische Kommunikationskanäle, die sog. Pipes. Die Parteien gehen zu Recht übereinstimmend davon aus, dass die Pipe im Sinne des HCI-Standards einen Datenweg im Sinne des Verfügungspatents darstellt, wobei die beiden Gates, zwischen denen die Pipe besteht, patentgemäß den Ausgangs- und Bestimmungspunkt dieses Datenweges bilden. Es gibt statische Pipes, die immer verfügbar sind und dynamische Pipes, die erstellt und gelöscht werden können (Anlage Ast25 Kapitel 4.4). Die Pipes zu den Verwaltungsverknüpfungsgates und den Administrationsgates sind statisch; sie stellen die Verbindung zwischen einem Gate eines Hosts und dem Host-Controller her (Anlage Ast25 Kapitel 4.4). Die dynamischen Pipes stellen die Verbindung zwischen zwei Gates aus unterschiedlichen Hosts her. Dynamische Gate-Bezeichner müssen im Hostnetzwerk eindeutig sein (Anlage Ast25 Kapitel 4.4).

Soll ein Datenaustausch zwischen Host A und Host B erfolgen, muss eine dynamische Pipe zwischen den Gates dieser Hosts erstellt werden. Zu diesem Zweck sendet das Administrations-Gate von Host A über die bestehende statische Pipe einen Datenwegeröffnungsbefehl (ADM_CREATE_PIPE, vgl. Anlage Ast25 Tabelle 4) an das Administrations-Gate des Host-Controllers (Merkmal 3.a)). Dieser Datenwegeröffnungsbefehl identifiziert das Gate von Host B, an das die Daten gesendet werden sollen (Merkmal 3.a)a1)). (vgl. hierzu Anlage AST25 Kapitel 6.1.3.1, Kapitel 8.1.1)

Der Host-Controller verwendet die vom Zielhost definierte „Weiße Liste“, um zu überprüfen, ob der Quellhost zum Erstellen einer Pipe autorisiert ist. Ist dies der Fall, wird eine dynamische Pipe zwischen den Gates des Quellhosts (Host A) und des Zielhosts (Host B) erstellt (Merkmale 3.b) und 3.b)b1); vgl. hierzu Anlage AST25 Kapitel 6.1.3.1, Kapitel 8.1.1).

Der Host-Controller weist der erzeugten Pipe eine Pipe-ID zu und meldet diese dem Quellhost mit der Antwort ANY_OK (Anlage Ast25 Kapitel 6.1.3.1, Tabelle 10). Dem Zielhost wird mit dem Befehl ADM_NOTIFY_PIPE_CREATED ebenfalls die Pipe-ID der erzeugten Pipe übermittelt (Anlage AST25 Kapitel 6.1.3.2, Tabelle 11). Diese Pipe-ID stellt die erfindungsgemäße Routingkanalnummer (CHANi) dar (Merkmal 3.b)b2)). Sie umfasst nach dem Standard 7 Bit und wird der Pipe dynamisch vom Host-Controller zugewiesen. Nach Tabelle 3 des Standards kann sie den Wert „02“ bis „6F“ zugewiesen bekommen. Jeder dynamische Pipe-Bezeichner muss im Hostnetzwerk eindeutig sein (Anlage Ast25 Kapitel 4.4).

Mit der Pipe-ID meldet der Host-Controller dem Quellhost und dem Zielhost auch die Identifizierer des Quellhosts, des Quellgates, des Zielhosts und des Zielgates (Anlage Ast25 Kapitel 6.1.3.1, Tabelle 10 und Kapitel 6.1.3.2, Tabelle 11). Insofern werden nach dem Standard die nach Merkmal 3.b)b3) erforderlichen Informationen vom Host-Controller an den Quellhost und den Zielhost übermittelt.

Selbst wenn man annehmen wollte, dass diese Daten bei den Hosts gespeichert werden (beispielsweise in den dort geführten Registern, vgl. hierzu: Anlage Ast25 Kapitel 4.5, Kapitel 6.1.2.1) und dort grundsätzlich abrufbar zur Verfügung stehen, findet sich im Standard jedenfalls kein Hinweis darauf, dass die Steuereinheit beim Empfang der in einem Datenübertragungsblock verkapselten Daten mithilfe der Pipe-ID als Index in einer Routingtabelle (beispielsweise den Registern) den Bestimmungspunkt der Daten sucht (Merkmalsgruppe 3.d)).

Nach dem Standard tauschen die Hosts Datenpakete aus. Ein solches Paket besteht aus einem Header und der eigentlichen Nachricht. Der Header enthält das Chaining-Bit und die Pipe-ID (Merkmal 3.c)c1)). Der Host verwendet den Wert der Pipe-ID, um ein Paket an den Zielhost weiterzuleiten. Der Zielhost leitet das Paket an das Ziel-Gate weiter. Anhand dieses Mechanismus können alle Gates, die über eine Pipe miteinander verbunden sind, Nachrichten austauschen (vgl. zum Ganzen: Anlage Ast25 Kapitel 5.1). Auf welche Weise der Host die Pipe-ID verwendet, um den Bestimmungspunkt des übermittelten Datenpakets zu bestimmen, gibt der Standard nicht vor. Insbesondere ist an dieser Stelle nicht von einem Rückgriff auf die vorhandenen Register die Rede. Insofern hat auch die Verfügungsklägerin in der mündlichen Verhandlung vom 06.05.2016 eingeräumt, dass der Standard keine Informationen zum tatsächlichen Senden der Datenpakete mittels der Pipe-ID enthält.

Der von der Verfügungsbeklagten beauftragte Privatgutachter Herr Prof. U erläutert in seinem Gutachten (Anlage HL8), dass es neben der Möglichkeit der Entnahme von Informationen aus einer Routing-Tabelle zwei weitere Möglichkeiten gebe, das zu routende Datenpaket nur durch Auswertung der ihm beigefügten Routingkanalnummer an einen Bestimmungspunkt weiterzuleiten. Hierbei handele es sich zum einen um die Verwendung eines Algorithmus oder einer Formel, zum anderen um die Verwendung einer (re-)konfigurierbaren logischen Schaltung. Der Fachmann erkenne, dass es sich hierbei um von der Verwendung einer Routing-Tabelle zu unterscheidende technische Möglichkeiten handele. Denn diese würden unterschiedliche technische Vor- und Nachteile insbesondere im Hinblick auf den Implementierungsaufwand und die Flexibilität bieten (vgl. HL8 S. 8). Die Kammer teilt die Auffassung, dass die Implementierung eines Algorithmus oder einer logischen Schaltung zur Weiterleitung eines Datenpaketes nicht auf die Zuordnung einer Routingkanalnummer zu einem bestimmten Identifizierer eines Ausgangs- oder Bestimmungspunktes in der Form eines Routingparameters angewiesen ist und insofern das Routing von Datenpaketen ohne Rückgriff auf eine Routingtabelle im Sinne der Lehre des Verfügungspatents möglich ist. Die Verfügungsklägerin hat die von der Beklagten dargestellten technischen Möglichkeiten als solche bestätigt, auch wenn sie der Auffassung ist, dass es sich bei der Verwendung eines Algorithmus oder einer Schaltung letztlich nur um theoretische Möglichkeiten handele. Die Verwendung einer Routing-Tabelle ist für das durchzuführende Routing nach dem Standard damit jedenfalls nicht zwingend, so dass allein der Verweis auf die Standardkonformität der angegriffenen Ausführungsformen nicht geeignet ist, den Verletzungsnachweis zu führen.

2.
Auch anhand der von der Verfügungsbeklagten vorgelegten Teile des Quellcodes ist der Verfügungsklägerin ein solcher Nachweis nicht gelungen. Denn sie belegen nicht die Verwendung einer Routing-Tabelle im Sinne des Verfügungspatents für die Suche nach dem Bestimmungspunkt eines eingehenden Datenpakets (Merkmalsgruppe 3.d)).

Die Verfügungsbeklagte erläutert die Funktionsweise der angegriffenen NFC-Chips anhand der vorgelegten Quellcode Datei A27 wie folgt:
Bei Eingang eines Datenpaketes mit einer Pipe-ID im Header werde zunächst eine if-Abfrage gestartet, von welchem Ausgangshost das Datenpaket stamme (Z. 172, 176, 182). Sodann werde einer der drei Parameter aus den Zeilen 50-52 gesetzt. Im Anschluss werde aus dem Array aPipePackLookUp (der Look-Up-Tabelle) ein Offset-Wert entnommen (Z. 191). Anhand des Offsets werde zur Fehlerkontrolle ein bitweiser Vergleich mit der d-mask vorgenommen (Z. 69-99). Der erhaltene Offset-Wert werde für den Parameter bPipeOffset gespeichert. Der Offset-Wert führe in maskierter Form zum Aufruf der Funktion phSwpNfceeFe_CommonCeReaderProcess der CommonMaskHandlerTable (Z. 53). Anhand eines bitweisen Vergleichs werde eine der sechs Funktionen mit dem Wert 0-5 aufgerufen (Z. 148-156). Anschließend sei nach den Zeilen 826 ff. vorgesehen, dass die Funktion phSwpNfceeFe_CommonCeProcess aufgerufen werde. Diese Funktion sei in den Zeilen 1029 ff. definiert und werde mit einem Parameter mode aufgerufen. Dieser ergebe sich entsprechend dem Funktionsaufruf in Zeile 832 aus der Vorschrift aPipeToModeLut. Mit dem referenzierten Array aPipeToModeLut werde aus der Pipe-ID ein Modus bestimmt, indem von der Pipe-ID die Konstante PH_HCI_PIPE_CEB abgezogen werde. Welchen Wert diese Konstante habe, ergebe sich aus der Datei phHci.h (Datei A01), Zeile 165. Der Wert betrage stets 6. Um die Verarbeitung des Datenpakets am richtigen Gate sicherzustellen, werde in den Zeilen 1141 und 1151 eine Fallunterscheidung anhand eines weiteren Arrays phSwpFeCeCommonProcessHandlerTable und hierbei speziell über den übergebenen Parameter mode vorgenommen. Das Array phSwpFeCeCommonProcessHandlerTable sei in den Zeilen 129 ff. der Datei phSwpNfceeFeCommon.c definiert und stelle sicher, dass eine Weiterverarbeitung des zu sendenden Datenpakets über eine der gatespezifischen Funktionen phHci_CeA_SendDataEvt, phHci_CeB_SendDataEvt oder phHci_CeF_SendDataEvt erfolge. Diese gatespezifischen Funktionen seien in den Dateien phHci_CeA.c, phHci_CeB.c und phHci_CeF.c definiert. Wenn Daten gesendet werden sollen (HCI_EVT_CE_SEND_DATA), werde die Senderoutine für das dem mode zugeordnete Gate CeA, CeB oder CeF aufgerufen.

Die vorstehend wiedergegebenen Ausführungen der Verfügungsbeklagten lassen sich anhand des vorgelegten Quellcodes im Grundsatz nachvollziehen. Ein offensichtlicher Widerspruch ergibt sich für die Kammer nicht. Auch die Verfügungsklägerin tritt dem Vorbringen der Verfügungsbeklagten nicht substantiiert entgegen. Insbesondere vermag sie keine Stellen im Quellcode zu benennen, die definitiv belegen, dass für das Senden der Daten der Bestimmungspunkt in einer Routingtabelle gesucht wird, wobei die Routingkanalnummer als Index dient. Zwar ermöglicht das in Bezug genommene Array aPipePackLookUp eine Zuordnung zwischen der Pipe-ID und dem jeweiligen Ausgangshost; die dort aufgeführten „upper three bits“ definieren gemäß Zeile 61, für welchen Host sie gültig sind. Die LookUpTable enthält aber keine eindeutige Zuordnung zum Zielhost/-gate. Vielmehr bestimmen die „lower three bits“ nur das Offset für die jeweilige Pipe-ID und damit die Verarbeitungsfunktion für die Verarbeitung am richtigen Gate.

Aufgrund der Ausführungen der Verfügungsbeklagten erscheint es jedenfalls möglich, dass bei Verwendung fest implementierter Datenwege mit einer festen Programmkonstante gearbeitet wird, die eine eindeutige Zuordnung der Pipe-ID zu Identifizierern des Ausgangs- und Bestimmungspunktes (i.S. einer erfindungsgemäßen Routing-Tabelle) entbehrlich macht. Abschließend kann dies nicht beurteilt werden, weil die Einzelheiten der Funktionsweise und die Werte der Parameter nicht ersichtlich sind.

Soweit die Verfügungsklägerin einwendet, dass der vorgelegte Quellcode nicht vollständig sei und gerade nicht die Definition für die zentrale Funktion phSwpFeRom_Send enthalte, kann ihr Einwand nicht zum Erfolg ihres Antrags führen. Denn die Darlegungslast im Hinblick auf die Verwirklichung der patentgemäßen Lehre trägt grundsätzlich die Verfügungsklägerin. Die Verfügungsbeklagte hat ihrer sekundären Darlegungslast dadurch genügt, dass sie anhand der Datei A27 nachvollziehbar die Kommunikation vom Host zur Schnittstelle im Emulationsmodus erläutert hat. Warum sich aus anderen Teilen des Quellcodes etwas grundsätzlich anderes ergeben sollte, hat die Verfügungsklägerin nicht substantiiert vorgetragen. Auch sieht die Kammer keine Anhaltspunkte dafür, dass im Lesemodus etwas erfindungswesentlich anderes gelten sollte.

V.
Die Kostenentscheidung beruht auf § 91 Abs. 1 Satz 1 ZPO.

Die Entscheidung zur vorläufigen Vollstreckbarkeit folgt aus den §§ 708 Nr. 6, 711 Satz 2, 108 ZPO.

Der Streitwert wird auf 1.000.000,00 Euro festgesetzt.