{"id":6325,"date":"2016-05-24T17:00:57","date_gmt":"2016-05-24T17:00:57","guid":{"rendered":"https:\/\/www3.hhu.de\/duesseldorfer-archiv\/?p=6325"},"modified":"2016-08-25T08:19:25","modified_gmt":"2016-08-25T08:19:25","slug":"4b-o-1616-datenweiterleitungsverfahren","status":"publish","type":"post","link":"https:\/\/d-prax.de\/?p=6325","title":{"rendered":"4b O 16\/16 – Datenweiterleitungsverfahren"},"content":{"rendered":"

D\u00fcsseldorfer Entscheidungs Nr.: 2522<\/strong><\/p>\n

Landgericht D\u00fcsseldorf<\/p>\n

Urteil vom 24. Mai 2016, Az.\u00a04b O 16\/16 <\/span><\/p>\n

I. Der Antrag auf Erlass einer einstweiligen Verf\u00fcgung wird zur\u00fcckgewiesen.<\/p>\n

II. Die Kosten des Verfahrens tr\u00e4gt die Verf\u00fcgungskl\u00e4gerin.<\/p>\n

III. Das Urteil ist vorl\u00e4ufig vollstreckbar. Die Verf\u00fcgungskl\u00e4gerin kann die Vollstreckung durch Sicherheitsleistung in H\u00f6he von 120 % des aus diesem Urteil zu vollstreckenden Betrages abwenden, wenn nicht die Verf\u00fcgungsbeklagte vor der Vollstreckung Sicherheit in H\u00f6he von 120 % des jeweils zu vollstreckenden Betrages leistet.<\/p>\n

Tatbestand<\/strong><\/p>\n

Die Verf\u00fcgungskl\u00e4gerin nimmt die Verf\u00fcgungsbeklagte im Wege der einstweiligen Verf\u00fcgung wegen Verletzung des deutschen Teils des europ\u00e4ischen Patents 1 855 XXX B1 (Verf\u00fcgungspatent, Anlage Ast18, in deutscher \u00dcbersetzung Anlage Ast19) auf Unterlassung in Anspruch.<\/p>\n

Das Verf\u00fcgungspatent wurde am 23.03.2007 von der A S.A., damals firmierend unter B S.A., sp\u00e4ter unter C S.A., unter Inanspruchnahme zweier franz\u00f6sischer Priorit\u00e4ten jeweils vom 10.05.2006 angemeldet. Die Offenlegung der Anmeldung erfolgte am 14.11.2007. Der Hinweis auf die Erteilung des Verf\u00fcgungspatents wurde am 11.08.2010 ver\u00f6ffentlicht. Das Patent steht in Kraft.<\/p>\n

Die D Europe Co. Ltd. hat unter dem 02.06.2014 Nichtigkeitsklage beim Bundespatentgericht eingereicht mit dem Antrag, das Verf\u00fcgungspatent im Umfang der Anspr\u00fcche 1 und 12 f\u00fcr nichtig zu erkl\u00e4ren. Mit Zwischenbescheid vom 05.10.2015 \u00e4u\u00dferte das Bundespatentgericht erhebliche Zweifel am Rechtsbestand des Verf\u00fcgungspatents (s. Anlage Ast2). Durch Urteil vom 13.01.2016 wies das Bundespatentgericht die Nichtigkeitsklage vollumf\u00e4nglich zur\u00fcck (Anlage Ast3).<\/p>\n

Das Verf\u00fcgungspatent bezieht sich auf ein Verfahren zur Weiterleitung von aus- und eingehenden Daten in ein NFC-Chipset. Die von der Verf\u00fcgungskl\u00e4gerin geltend gemachten Anspr\u00fcche 1 und 12 des Verf\u00fcgungspatents, dessen Verfahrenssprache franz\u00f6sisch ist, lauten in ihrer eingetragenen deutschen \u00dcbersetzung wie folgt:<\/p>\n

1.
\nDatenrouting-Verfahren in einem Chipsatz, umfassend wenigstens einen Hostprozessor (HP1, HP2), eine Steuereinheit (NFCC) und eine kontaktlose Datensende-\/ Empfangsschnittstelle (CLINT) vom RFID-Typ,
\ndadurch gekennzeichnet, dass es die folgenden Schritte umfasst, die darin bestehen:
\n– einen Datenweger\u00f6ffnungsbefehl (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,
\n– als Antwort auf den Datenweger\u00f6ffnungsbefehl (CMD) mittels der Steuereinheit (NFCC) einen Datenweg zu er\u00f6ffnen, 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,
\n– f\u00fcr den Bestimmungspunkt bestimmte, in einem Daten\u00fcbertragungsblock (DF), der ein die Routingkanalnummer umfassendes Header-Feld aufweist, verkapselte Daten mittels des Ausgangspunktes an die Steuereinheit (NFCC) zu senden und
\n– beim Empfang der in einem Daten\u00fcbertragungsblock (DF), der ein die Routingkanalnummer umfassendes Header-Feld aufweist, verkapselten Daten mittels der Steuereinheit (NFCC), unter Verwendung der Routingkanalnummer als Index f\u00fcr die Auswahl des Bestimmungspunktes, einen Bestimmungspunkt der Daten in der Routing-Tabelle zu suchen und die Daten dann an den Bestimmungspunkt zu senden.<\/p>\n

12.
\nDatensende-\/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,
\ndadurch gekennzeichnet, dass die Steuereinheit (NFCC) konfiguriert ist, um:
\n– als Antwort auf einen Datenweger\u00f6ffnungsbefehl (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\u00f6ffnen, 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
\n– beim Empfang von in einem Daten\u00fcbertragungsblock (DF), der ein die Routingkanalnummer umfassendes Header-Feld aufweist, verkapselten Daten, unter Verwendung der Routingkanalnummer als Index f\u00fcr die Auswahl des Bestimmungspunktes einen Bestimmungspunkt der Daten in der Routing-Tabelle zu suchen.<\/p>\n

Bei der Verf\u00fcgungskl\u00e4gerin handelt es sich um eine Patentverwertungsgesellschaft, die 2011 auf Betreiben des franz\u00f6sischen Staates zur F\u00f6rderung des Patentwesens und der Verwertung insbesondere franz\u00f6sischer Patente gegr\u00fcndet wurde. Seit dem 19.12.2014 ist sie ausschlie\u00dfliche Lizenznehmerin am Verf\u00fcgungspatent (vgl. Anlage Ast 21\/22).<\/p>\n

Die Verf\u00fcgungsbeklagte 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\u00fcgungsbeklagte unter anderem Mobilfunkger\u00e4te des Herstellers D.<\/p>\n

Gegen\u00fcber 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\u00fcgungspatents erkannt und zwar im Hinblick auf Mobilfunkger\u00e4te mit dem NFC-Chip \u201eE\u201c der Firma F (nachfolgend: angegriffene Ausf\u00fchrungsform I, hier nicht streitgegenst\u00e4ndlich), der von dem HCI-Standard ETSI TS 102 622 (Anlage Ast 24\/25) Gebrauch macht. Auf den Inhalt des Urteils wird Bezug genommen.<\/p>\n

Die D Germany GmbH hat gegen das Urteil Berufung eingelegt, \u00fcber die noch nicht entschieden ist. Den Antrag auf sofortige Einstellung der Zwangsvollstreckung hat das Oberlandesgericht D\u00fcsseldorf durch Beschluss vom 19.08.2015 zun\u00e4chst zur\u00fcckgewiesen. Nach dem Zwischenbescheid des Bundespatentgerichts stellte das Oberlandesgericht D\u00fcsseldorf die Zwangsvollstreckung aus dem Urteil der Kammer bis zum 13.01.2016 ein. Den dar\u00fcber hinaus gehenden Antrag auf vorl\u00e4ufige Einstellung der Zwangsvollstreckung wies das Oberlandesgericht D\u00fcsseldorf durch Beschluss vom 26.01.2016 zur\u00fcck (Anlage Ast 5).<\/p>\n

Die Verf\u00fcgungsbeklagte stellte auf der IFA 2015 unter anderem das \u201eD G H\u201c und das \u201eD G I\u201c aus, die beide den NFC-Chip \u201eJ\u201c der Firma F aufweisen (nachfolgend: angegriffene Ausf\u00fchrungsform II). Dieser macht \u2013 genauso wie der NFC-Chip \u201eE\u201c \u2013 von dem HCI-Standard ETSI TS 102 622 Gebrauch und wird auch von den Smartphones \u201eD K L\u201c, \u201eD G M\u201c und \u201eD K N\u201c genutzt. Bez\u00fcglich dieser Mobilfunkger\u00e4te mit dem NFC-Chip \u201eJ\u201c erlie\u00df die Kammer mit Beschluss vom 07.09.2015 eine einstweilige Verf\u00fcgung gegen die Verf\u00fcgungsbeklagte. In der auf den Widerspruch der Verf\u00fcgungsbeklagten hin durchgef\u00fchrten m\u00fcndlichen Verhandlung am 08.10.2015 nahm die Verf\u00fcgungskl\u00e4gerin ihren Antrag auf Erlass der einstweiligen Verf\u00fcgung zur\u00fcck, nachdem die Verf\u00fcgungsbeklagte den Zwischenbescheid des Bundespatentgerichts vom 05.10.2015 erhalten und vorgelegt hatte.<\/p>\n

Mit dem vorliegenden Antrag greift die Verf\u00fcgungskl\u00e4gerin zwei weitere Smartphone-Modelle der Firma D an, n\u00e4mlich das \u201eD G O\u201c und das \u201eD K P\u201c. Das \u201eD K P\u201c ist seit August 2015 auf dem Markt und mit dem NFC-Chip \u201eJ\u201c der Firma F ausgestattet. Das \u201eD G O\u201c ist seit Ende November 2015 im Handel und nutzt den NFC-Chip \u201eQ\u201c der Firma F. Auch der NFC-Chip \u201eQ\u201c macht von dem HCI-Standard ETSI TS 102 622 Gebrauch.<\/p>\n

Die Verf\u00fcgungskl\u00e4gerin ist der Ansicht, die den NFC-Chip \u201eJ\u201c und \u201eQ\u201c aufweisenden Smartphones der Firma D w\u00fcrden von der Lehre des Verf\u00fcgungspatents wortsinngem\u00e4\u00df Gebrauch machen. Dies ergebe sich schon daraus, dass beide Chips in gleicher Weise von dem HCI-Standard ETSI TS 102 622 Gebrauch machen w\u00fcrden wie der \u201eE\u201c.<\/p>\n

Der streitgegenst\u00e4ndliche Standard ETSI TS 102 622 sehe statische und dynamische Pipes vor. F\u00fcr die dynamischen Pipes sehe der Standard zwingend die \u00dcbertragung 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\u00f6glichkeit zur \u00dcbertragung dieser Routing-Tabelle kenne der Standard nicht. Es sei aber erforderlich, dass der auf der UICC verortete Host in irgendeiner Weise \u00fcber die mit einer vom Host-Controller vergebenen Pipe-ID verkn\u00fcpften Datenwege informiert werden m\u00fcsse.<\/p>\n

Sie \u2013 die Verf\u00fcgungskl\u00e4gerin \u2013 habe die angegriffenen Ausf\u00fchrungsformen einem Test unterzogen und dabei festgestellt, dass mittels des Befehls \u201eADM_CREATE_PIPE\u201c dynamische Pipes erstellt werden. Dass es sich um dynamische Pipes handele, ergebe sich nicht nur aus der Benutzung des Befehls \u201eADM_CREATE_PIPE\u201c, 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.<\/p>\n

Im \u00dcbrigen unterscheide die erfindungsgem\u00e4\u00dfe Lehre nicht wie der Standard zwischen dynamischen und statischen Pipes. Auch die Verwendung statischer Routingkanalnummern f\u00fchre nicht aus dem Schutzbereich des Verf\u00fcgungspatents heraus. Der Standard gebe in Abschnitt 6.1.3.1 \u201eADM_CREATE_PIPE\u201c und in dem korrelierenden Standardabschnitt 6.1.3.2 \u201eADM_NOTIFY_PIPE_CREATED\u201c 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\u00fcsse 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\u00f6nne als Routing-Information nur verwendet werden, wenn in einer Routingtabelle die zugeh\u00f6rigen Parameter eingetragen seien.<\/p>\n

Soweit die Verf\u00fcgungsbeklagte versuche, die Patentverletzung auf der Quellcodeebene zu bestreiten, \u00fcberzeuge dies nicht. Zun\u00e4chst sei festzustellen, dass die vorgelegten Quellcodedateien allein den Kartenemulationsmodus, nicht aber den Lesemodus betreffen w\u00fcrden. Auch bez\u00fcglich des Kartenemulationsmodus w\u00fcrden ma\u00dfgebliche Programmdateien fehlen. Insbesondere ergebe sich aus den vorgelegten Dateien nicht, wie der Bestimmungspunkt der Daten ermittelt werde. Die vorgelegten Teile des Quellcodes w\u00fcrden vielmehr allein den Befehl ADM_CREATE_PIPE betreffen. Es sei aber Sache der Beklagten, im Wege ihrer sekund\u00e4ren Darlegungs- und Beweislast nachzuweisen, auf welche Weise der Bestimmungspunkt der Daten beim Routing bestimmt werde. Solange sie nichts anderes belege, m\u00fcsse davon ausgegangen werden, dass hierzu auf den entsprechenden Identifizierer des Bestimmungspunktes in einer Routingtabelle zur\u00fcckgegriffen werde.<\/p>\n

Das von der Verf\u00fcgungsbeklagten 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\u00fcr den in Benutzung zu nehmenden Datenweg aus einer vorgegebenen Menge von Kennungen ausgew\u00e4hlt 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 \u201ephSwpNFceeFeCommon.c\u201c, Z. 69-99, oder in der Datei \u201ephHci.h\u201c, 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\u00fcrden in dem Array \u201egphHciCmdParamSave\u201c gesammelt bzw. gespeichert. Diese w\u00fcrden dann in einer ANY_OK-Antwort gem\u00e4\u00df Abschnitt 6.1.3 des HCI-Standards gesendet. Damit aber sei die Erzeugung und Verwendung einer Routing-Tabelle im Sinne der Merkmalsgruppe 3b) gegeben.<\/p>\n

Soweit der Privatgutachter R erl\u00e4utert habe, dass die Pipe-ID in ein Offset umgerechnet bzw. umformatiert w\u00fcrde, stehe dies einer Patentverwirklichung nicht entgegen, weil funktional die Pipe-ID f\u00fcr die Weiterleitung des entsprechend gekennzeichneten Datenpakets genutzt werde. Au\u00dferdem befasse sich die von der Verf\u00fcgungsbeklagten 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\u00dfenden zweiten Stufe, n\u00e4mlich 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\u00f6glichkeiten der Verwendung eines Algorithmus oder einer logischen Schaltung seien theoretischer Natur. Es fehle der Nachweis seitens der Beklagten, dass die angegriffenen Ausf\u00fchrungsformen das Routing der Daten tats\u00e4chlich ohne einen R\u00fcckgriff auf die Identifizierer des Ausgangs- und Bestimmungspunktes vornehmen.<\/p>\n

Dem neuerlichen Verf\u00fcgungsantrag fehle es nicht an der erforderlichen Dringlichkeit.<\/p>\n

Bis zur Anbringung des ersten Verf\u00fcgungsantrags habe sie – die Verf\u00fcgungskl\u00e4gerin – die Verf\u00fcgungsbeklagte nicht gekannt. Erst im Zusammenhang mit der IFA-Messe im September 2015 sei sie auf die Vertriebsaktivit\u00e4ten der Verf\u00fcgungsbeklagten aufmerksam geworden. Die Verf\u00fcgungsbeklagte handele \u00fcberwiegend im Verborgenen. Auf den Internetseiten der D-Konzerngruppe finde sich kein Hinweis auf die Einbindung der Verf\u00fcgungsbeklagten in die Vertriebsaktivit\u00e4ten von D. Im Stra\u00dfenbild sei die Verf\u00fcgungsbeklagte nicht durch Gesch\u00e4fte pr\u00e4sent.<\/p>\n

Der urspr\u00fcngliche Antrag auf Erlass einer einstweiligen Verf\u00fcgung sei nur deshalb zur\u00fcckgenommen worden, weil er aufgrund des Zwischenbescheids des Bundespatentgerichts keine Aussicht auf Erfolg mehr gehabt habe. Es sei legitim, dass sie – die Verf\u00fcgungskl\u00e4gerin – dann zun\u00e4chst 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\u00e4ndigkeit des Verf\u00fcgungspatents ausreichend gesichert gewesen. Die erneute Anbringung des Verf\u00fcgungsantrags sei keineswegs rechtsmissbr\u00e4uchlich. Denn aufgrund des Zwischenbescheids des Bundespatentgerichts habe ein sachlicher Grund vorgelegen, den Verf\u00fcgungsantrag zur\u00fcckzunehmen. Andernfalls h\u00e4tte das Landgericht den urspr\u00fcnglichen Antrag per Urteil zur\u00fcckgewiesen.<\/p>\n

Nach dem 13.01.2016 habe die Verf\u00fcgungskl\u00e4gerin die Produktpalette von D, die zwischenzeitlich umgestellt bzw. erweitert worden sei, neu recherchiert und insbesondere Tests dazu durchf\u00fchren lassen, welche Chips in den aktuell vertriebenen Ger\u00e4ten von D benutzt und verbaut w\u00fcrden. Die entsprechenden Analyseberichte w\u00fcrden ihr erst seit kurzer Zeit vorliegen. Zeitgleich haben sie Vergleichsgespr\u00e4che mit der D-Konzerngruppe gef\u00fchrt. Vor dem Hintergrund dieser Vergleichsgespr\u00e4che habe es keinen Sinn ergeben, gegen die hiesige Verf\u00fcgungskl\u00e4gerin vorzugehen. Dies h\u00e4tte vielmehr die Fortsetzung der Vergleichsgespr\u00e4che gef\u00e4hrdet.<\/p>\n

Mit ihrem am 22.02.2016 bei Gericht eingegangenen Schriftsatz beantragt die Verf\u00fcgungskl\u00e4gerin,<\/p>\n

der Verf\u00fcgungsbeklagten bei Meidung eines f\u00fcr 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\u00e4ftsf\u00fchrer der Verf\u00fcgungsbeklagten zu vollziehen ist, zu untersagen,<\/p>\n

1. Mobiltelefone im deutschen Geltungsbereich des EP 1 855 XXX B1 anzubieten und\/oder zu liefern, die zur Aus\u00fcbung 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:<\/p>\n

– einen Datenweger\u00f6ffnungsbefehl (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,<\/p>\n

– als Antwort auf den Datenweger\u00f6ffnungsbefehl (CMD) mittels der Steuereinheit (NFCC) einen Datenweg zu er\u00f6ffnen, 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,<\/p>\n

– f\u00fcr den Bestimmungspunkt bestimmte, in einem Daten\u00fcbertragungsblock (DF), der ein die Routingkanalnummer umfassendes Header-Feld aufweist, verkapselte Daten mittels des Ausgangspunktes an die Steuereinheit (NFCC) zu senden und<\/p>\n

– beim Empfang der in einem Daten\u00fcbertragungsblock (DF), der ein die Routingkanalnummer umfassendes Header-Feld aufweist, verkapselten Daten mittels der Steuereinheit (NFCC), unter Verwendung der Routingkanalnummer als Index f\u00fcr die Auswahl des Bestimmungspunktes, einen Bestimmungspunkt der Daten in der Routing-Tabelle zu suchen und die Daten dann an den Bestimmungspunkt zu senden,<\/p>\n

und\/oder<\/p>\n

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,<\/p>\n

im deutschen Geltungsbereich des EP 1 855 XXX B1 anzubieten, in Verkehr zu bringen oder zu gebrauchen oder zu den genannten Zwecken entweder einzuf\u00fchren oder zu besitzen, wobei die Steuereinheit (NFCC) konfiguriert ist,<\/p>\n

um als Antwort auf einen Datenweger\u00f6ffnungsbefehl (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\u00f6ffnen, 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\u00fcbertragungsblock (DF), der ein die Routingkanalnummer umfassendes Header-Feld aufweist, verkapselten Daten, unter Verwendung der Routingkanalnummer als Index f\u00fcr die Auswahl des Bestimmungspunktes einen Bestimmungspunkt der Daten in der Routing-Tabelle zu suchen.
\nDie Verf\u00fcgungsbeklagte beantragt,<\/p>\n

den Verf\u00fcgungsantrag zur\u00fcckzuweisen.<\/p>\n

Zur Begr\u00fcndung ihrer Antr\u00e4ge f\u00fchrt die Verf\u00fcgungsbeklagte aus, es fehle sowohl an einem Verf\u00fcgungsanspruch als auch an einem Verf\u00fcgungsgrund.<\/p>\n

Bez\u00fcglich der hier streitgegenst\u00e4ndlichen F-Controller \u201eJ\u201c und \u201eQ\u201c sei die von der Verf\u00fcgungskl\u00e4gerin behauptete Patentverletzung nicht nachgewiesen.<\/p>\n

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 \u201eADM_CREATE_PIPE\u201c gerichtet gewesen. Der Standard schreibe hingegen nicht vor, dass die Erzeugung der Pipes f\u00fcr die Nutzung des Card Emulation Modes erforderlich w\u00e4re. Es sei nach dem Standard auch m\u00f6glich, eine Anzahl bereits in der Schnittstelle zwischen UICC Host und Host Controller fest implementierter Pipes zu verwenden. Eben so w\u00fcrden der \u201eJ\u201c und der \u201eQ\u201c arbeiten, wodurch sie sich grundlegend vom \u201eE\u201c unterscheiden w\u00fcrden. Die hier streitgegenst\u00e4ndlichen Chips w\u00fcrden auf ein \u201eArray\u201c fest im Chip implementierter statischer Pipes zur\u00fcckgreifen, die bedarfsweise ge\u00f6ffnet und geschlossen w\u00fcrden. Auf einen CreatePipe-Befehl hin werde kein Datenweg neu erzeugt, sondern es w\u00fcrden bereits zuvor gespeicherte Informationen in einer R\u00fcckmeldung \u00fcbermittelt, wenn ein existenter Datenweg in Benutzung genommen werde. Der existierende Datenweg k\u00f6nne als \u201egel\u00f6scht\u201c, \u201egeschlossen\u201c oder \u201eoffen\u201c markiert sein. Im Rahmen des CreatePipe-Befehls werde der Status \u201egeschlossen\u201c gesetzt, so dass die Pipe durch einen nachfolgenden Befehl gesondert ge\u00f6ffnet werden k\u00f6nne. Die Pipes seien unver\u00e4nderlich. Jeder Pipe sei eine Pipe-ID fest zugewiesen. Eine \u201eEr\u00f6ffnung\u201c eines Datenweges im Sinne des Verf\u00fcgungspatents finde gerade nicht statt.<\/p>\n

Auch werde f\u00fcr das Routing nicht \u2013 wie von der erfindungsgem\u00e4\u00dfen Lehre gefordert \u2013 auf eine Routing-Tabelle zur\u00fcckgegriffen. Der Standard lasse gerade offen, wie das Routing vorgenommen werde; insbesondere erfordere er nicht zwingend den R\u00fcckgriff auf eine Routing-Tabelle. Abschnitt 8.1.1 beschreibe lediglich, wie der Host die Erzeugung einer dynamischen Pipe durch den Host-Controller anfordern k\u00f6nne. Im Wege der Nachricht ADM_CREATE_PIPE w\u00fcrden 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\u00e4tigt. Es finde sich aber im Standard kein Hinweis darauf, dass der Host-Controller f\u00fcr die Weiterleitung eines Datenpakets die Pipe-ID als Index in einer Routing-Tabelle suchen m\u00fcsste, um ein Datenpaket an seinen Bestimmungspunkt weiterzuleiten.<\/p>\n

Neben der Verwendung einer erfindungsgem\u00e4\u00dfen Routing-Tabelle gebe es alternative, in einer Steuereinheit zu implementierende M\u00f6glichkeiten, ein von einem Ausgangspunkt an eine Steuereinheit \u00fcbermitteltes Datenpaket nur durch Auswertung der ihm beigef\u00fcgten Routingkanalnummer an einen Bestimmungspunkt weiterzuleiten. So k\u00f6nne 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\u00f6nnte 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\u00f6sungen seien klar von der Verwendung einer erfindungsgem\u00e4\u00dfen Routing-Tabelle zu unterscheiden.<\/p>\n

Die angegriffenen Ausf\u00fchrungsformen w\u00fcrden die Datenweiterleitung mittels eines Algorithmus bewerkstelligen. Der diesbez\u00fcgliche Quellcode sei f\u00fcr den \u201eJ\u201c und den \u201eQ\u201c identisch. Die HCI-standardgem\u00e4\u00dfe Implementierung basiere hier auf der Einbettung der m\u00f6glichen 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\u00e4chst ein Offset aus einer Look-Up-Tabelle entnommen. Das Array aPipePackLookup enthalte Offset-Werte f\u00fcr alle zul\u00e4ssigen Pipe-IDs. Das Offset diene der direkten Ermittlung der Routine, die f\u00fcr die restliche Verarbeitung des Pakets aufgerufen werden m\u00fcsse. Dazu werde der ausgelesene Offset-Wert in eine Zahl zwischen 0 und 5 umformatiert, um anschlie\u00dfend aus der sechs Eintr\u00e4ge umfassenden CommonPipeHandlerTable (Datei A 027 Z. 150-155) die zutreffende Funktion f\u00fcr die Weiterverarbeitung auszuw\u00e4hlen. Dementsprechend werde abh\u00e4ngig vom ermittelten Offset direkt eine Verarbeitungsfunktion f\u00fcr die Verarbeitung des Datenpakets am richtigen Gate aufgerufen. Die LookUpTable sei dabei keine erfindungsgem\u00e4\u00dfe Routing-Tabelle, weil es ihr an der patentgem\u00e4\u00df geforderten Eintragung sowohl der Routingkanalnummer als auch eines Identifizierers des Ausgangspunktes und eines Identifizierers des Bestimmungspunktes fehle.<\/p>\n

Die vorstehenden Ausf\u00fchrungen w\u00fcrden in gleicher Weise f\u00fcr den Kartenemulations- und den Lesemodus gelten.<\/p>\n

Im \u00dcbrigen fehle es aber auch an einem Verf\u00fcgungsgrund, da eine Dringlichkeit f\u00fcr den Erlass der einstweiligen Verf\u00fcgung nicht gegeben sei.<\/p>\n

Der Verf\u00fcgungskl\u00e4gerin sei bereits seit langem bekannt, dass es sich bei der Verf\u00fcgungsbeklagten 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 \u201eS\u201c Vertriebspartner der D-Gruppe sei. Das D G H werde von der Verf\u00fcgungsbeklagten bereits seit Anfang April 2015 vertrieben und sei Gegenstand der Unterlassungsvollstreckung aus dem Verletzungsverfahren gegen die D Germany GmbH gewesen. Die Verf\u00fcgungsbeklagte bzw. ihre Rechtsvorg\u00e4ngerin, die T Germany GmbH, w\u00fcrde bereits seit vielen Jahren D-Mobiltelefone auf der IFA ausstellen. Die Unternehmensgruppe der Verf\u00fcgungsbeklagten gelte als weltweit gr\u00f6\u00dfter Distributor f\u00fcr Produkte aus dem Bereich der Informations- und Telekommunikationstechnologie. Dies sei den Fachkreisen hinl\u00e4nglich bekannt. Insofern habe die Verf\u00fcgungskl\u00e4gerin \u2013 sollte sie tats\u00e4chlich keine positive Kenntnis von den Vertriebsaktivit\u00e4ten der Verf\u00fcgungsbeklagten gehabt haben \u2013 jedenfalls die Augen vor den vermeintlichen Verletzungshandlungen verschlossen. Auch in einem solchen Fall d\u00fcrfe eine einstweilige Verf\u00fcgung nicht erlassen werden.<\/p>\n

Jedenfalls aber habe die Zur\u00fccknahme des ersten Verf\u00fcgungsantrags durch die Verf\u00fcgungskl\u00e4gerin eine etwaige fr\u00fchere Dringlichkeit endg\u00fcltig entfallen lassen. Die Verf\u00fcgungskl\u00e4gerin habe ihren ersten Antrag bewusst noch w\u00e4hrend des anh\u00e4ngigen Rechtsbestandsverfahrens gestellt. Es sei allein ihre Entscheidung gewesen, sich in ein f\u00fcr sie unsicheres Verfahren zu begeben, ohne zun\u00e4chst den Ausgang des Rechtsbestandsverfahrens abzuwarten. Der negative Zwischenbescheid des Bundespatentgerichts habe kein irgendwie geartetes Prozesshindernis dargestellt, sondern die Verf\u00fcgungskl\u00e4gerin habe sich dazu entschieden, ihren Antrag auf Erlass einer einstweiligen Verf\u00fcgung zur\u00fcckzunehmen. In einem solchen Fall k\u00f6nne eine Dringlichkeit nicht wieder aufleben.<\/p>\n

Dar\u00fcber hinaus stelle das Verhalten der Verf\u00fcgungskl\u00e4gerin nach der Verk\u00fcndung der Entscheidung im Nichtigkeitsverfahren am 13.01.2016 ein z\u00f6gerliches und nachl\u00e4ssiges Verhalten hinsichtlich der Rechtsverfolgung dar. Die Verf\u00fcgungskl\u00e4gerin habe \u00fcber f\u00fcnf Wochen seit der Entscheidung des Bundespatentgerichts abgewartet, bis sie mit dem vorliegenden Verf\u00fcgungsantrag auf diese Entscheidung reagiert habe. Mit etwaigen Terminverschiebungen im Berufungsverfahren vor dem Oberlandesgericht k\u00f6nne die Verz\u00f6gerung nicht gerechtfertigt werden. Denn dieses Berufungsverfahren werde nicht mit der hiesigen Verf\u00fcgungsbeklagten, sondern mit der D Germany GmbH gef\u00fchrt. Gleiches gelte f\u00fcr etwaige Vergleichsgespr\u00e4che zwischen der Verf\u00fcgungskl\u00e4gerin und der D-Konzerngruppe.<\/p>\n

Die streitgegenst\u00e4ndlichen Modelle aus dem urspr\u00fcnglichen Verf\u00fcgungsverfahren w\u00fcrden sich weiterhin s\u00e4mtlich in Deutschland im Verkauf befinden. Dies k\u00f6nne durch einen kurzen Blick auf die Homepage von D festgestellt werden. Einer umfassenden neuen Recherche seitens der Verf\u00fcgungskl\u00e4gerin habe es nicht bedurft. Soweit die Verf\u00fcgungskl\u00e4gerin 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\u00fcgungskl\u00e4gerin vers\u00e4umt, dieses Modell schon in ihren ersten Verf\u00fcgungsantrag aufzunehmen. Dies k\u00f6nne hingegen keine verl\u00e4ngerte Recherchezeit bei ihrem zweiten Antrag rechtfertigen. In Wikipedia gebe es eine Liste aller NFC-f\u00e4higen Endger\u00e4te (vgl. Anlage HL7). Anhand dieser seien nicht nur die NFC-f\u00e4higen Ger\u00e4te von D, sondern auch die Verwendung des jeweiligen F-Chips auf sehr einfache Weise festzustellen. Der von der Verf\u00fcgungskl\u00e4gerin behauptete mehrw\u00f6chige Rechercheaufwand sei vor diesem Hintergrund v\u00f6llig \u00fcbertrieben.<\/p>\n

Im Hinblick auf das nunmehr erstmals angegriffene Modell \u201eD G O\u201c mit dem F-Chip \u201eQ\u201c k\u00f6nne eine Dringlichkeit ohnehin nicht aufleben, weil dieses Modell im Zeitpunkt des ersten Verf\u00fcgungsverfahrens noch gar nicht auf dem Markt gewesen sei. Dieses sei vielmehr erst Ende November 2015 eingef\u00fchrt worden, was die Verf\u00fcgungskl\u00e4gerin ohne weiteres den einschl\u00e4gigen Fachmedien habe entnehmen k\u00f6nnen.<\/p>\n

Wegen des weiteren Sach- und Streitstandes wird auf die zwischen den Parteien gewechselten Schrifts\u00e4tze nebst Anlagen sowie auf das Protokoll der m\u00fcndlichen Verhandlung vom 03.05.2016 verwiesen.
\nEntscheidungsgr\u00fcnde<\/strong><\/p>\n

Der zul\u00e4ssige Antrag auf Erlass einer einstweiligen Verf\u00fcgung hat in der Sache keinen Erfolg. Es l\u00e4sst sich im Rahmen des vorliegenden Verf\u00fcgungsverfahrens nicht feststellen, dass der Verf\u00fcgungskl\u00e4gerin gegen die Verf\u00fcgungsbeklagte ein Verf\u00fcgungsanspruch zusteht.<\/p>\n

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

Bei RFID-Systemen (\u201eradio-frequency identification\u201c) werden Daten auf einem elektronischen Datentr\u00e4ger \u2013 einem Transponder \u2013 gespeichert. Diese Daten k\u00f6nnen dann von einem Leseger\u00e4t 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\u00e4ts befindet. Die zum Betrieb des Transponders ben\u00f6tigte Energie wird \u00fcber das magnetische oder elektromagnetische Feld des Leseger\u00e4ts an den Transponder \u00fcbertragen. RFID-Systeme gestatten somit das automatisierte und ber\u00fchrungslose Identifizieren und Lokalisieren von mit einem Transponder versehenen Objekten bzw. das Erfassen von in einem Transponder enthaltenen Daten.<\/p>\n

NFC betrifft eine drahtlose Datenschnittstelle zwischen elektronischen Ger\u00e4ten. Die Besonderheit der NFC-Technologie besteht darin, dass der Datenaustausch nur \u00fcber kurze Strecken von einigen Zentimetern funktioniert, die am Datenaustausch beteiligten Ger\u00e4te dementsprechend nah aneinander gehalten werden m\u00fcssen. Die \u00fcber ihre jeweilige NFC-Schnittstelle miteinander verbundenen Ger\u00e4te 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\u00f6nnen, 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.<\/p>\n

Die Verf\u00fcgungspatentschrift beschreibt NFC-Leser mit mehreren Betriebsmodi, n\u00e4mlich einem \u201eLeser\u201c-Modus, einem \u201eKartenemulations\u201c-Modus und einem \u201eDevice\u201c-Modus. Im Leser-Modus funktioniert der NFC-Leser in aktiver Form durch Aussendung eines Magnetfeldes wie ein herk\u00f6mmlicher 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 \u2013 der die NFC-Technologie auszeichnet \u2013 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\u00fcgungspatentschrift Abs. [0004]).<\/p>\n

Aufgrund seiner weitreichenden Kommunikationskapazit\u00e4ten wird der NFC-Leser in tragbare Vorrichtungen wie Mobiltelefone oder PDAs integriert. Hierzu wird ein NFC-Chipsatz ben\u00f6tigt, der einen NFC-Leser und mindestens einen Hostprozessor umfasst (Verf\u00fcgungspatentschrift Abs. [0006]).<\/p>\n

Die nachfolgend abgebildete Figur 1 der Verf\u00fcgungspatentschrift zeigt den typischen Aufbau eines solchen NFC-Chipsatzes in Blockform und kontaktlose Schaltkreise, mit denen der Chipsatz kommunizieren kann:<\/p>\n

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\u00fcgungspatentschrift 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\u00fcgungspatentschrift Abs. 0006]). In Figur 1 teilen sich die beiden Hostprozessoren (HP1 und HP2) die Ressourcen des NFC-Lesers (NFCR1). Sie sind mit ihm \u00fcber Ports verbunden und k\u00f6nnen mit ihm jeweils bidirektional kommunizieren (angedeutet durch die Pfeile).<\/p>\n

Die Hostprozessoren verwalten \u00fcber den NFC-Leser ihre jeweiligen kontaktlosen Anwendungen bzw. Dienste (sog. Apps). \u00dcber den NFC-Leser m\u00fcssen deshalb ein- und ausgehende Datenfl\u00fcsse von den in den Hostprozessoren ausgef\u00fchrten Anwendungen oder Diensten abgewickelt werden. Das hei\u00dft, der NFC-Leser muss mit unterschiedlichen externen Schaltkreisen kommunizieren k\u00f6nnen (Verf\u00fcgungspatentschrift Abs. [0006]). Die Umsetzung eines geeigneten NFC-Chipsatzes erfordert daher jedenfalls das Vorsehen eines Routings von Datenfl\u00fcssen, die \u00fcber einen bidirektionalen, kontaktlosen Daten\u00fcbertragungskanal \u00fcbertragen werden, zwischen den jeweiligen Hostprozessoren (HP1, HP2) und dem NFC-Leser (NFCR1) innerhalb des Chipsatzes (Verf\u00fcgungspatentschrift Abs. [0007]).<\/p>\n

Dieses Routing von Datenfl\u00fcssen zwischen den jeweiligen Hostprozessoren und dem NFC-Leser beschreibt die Verf\u00fcgungspatentschrift exemplarisch anhand der nachfolgend abgebildeten Figuren 3a und 3b:<\/p>\n

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\u00dferhalb des NFC-Lesers befindlichen Hostprozessoren (HP1, HP2) verbunden.<\/p>\n

Figur 3b stellt die den NFC-Chipsatz passierenden Datenfl\u00fcsse von und zu von einem Hostprozessor (HP1, HP2) ausgef\u00fchrten Anwendungen oder Diensten exemplarisch dar. Auf diese Weise k\u00f6nnen die Ressourcen der kontaktlosen Datensende-\/ Empfangsschnittstelle (CLINT) durch die einzelnen Hostprozessoren verwendet werden. Dabei weisen die Datenfl\u00fcsse 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\u00fcgungspatentschrift Abs. [0009]).<\/p>\n

Um das Routing der ausgehenden Daten und die Konfiguration der Schnittstelle CLINT zu erm\u00f6glichen, werden Daten\u00fcbertragungsbl\u00f6cke gebildet, die jeweils Header-Felder und Datenfelder umfassen. Die Header-Felder enthalten die zur Steuerung der Schnittstelle CLINT erforderlichen Informationen, insbesondere Felder mit Angaben \u00fcber Datenausgangs- und Bestimmungspunkte (Verf\u00fcgungspatentschrift Abs. [0011]).<\/p>\n

Das aus dem Stand der Technik bekannte HCI-Protokoll sah ausweislich der Verf\u00fcgungspatentschrift (Verf\u00fcgungspatentschrift Abs. [0012]) Daten\u00fcbertragungsbl\u00f6cke 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 \u201eoverheading\u201c 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 \u00fcbermittelt, wobei der Prozessor, den diese Daten nicht betrafen, nicht darauf antwortete (Verf\u00fcgungspatentschrift Abs. [0014]).<\/p>\n

Vor diesem Hintergrund formuliert die Verf\u00fcgungspatentschrift die Aufgabe (das technische Problem), zum einen ein Datenrouting-Verfahren in einem NFC-Chipsatz bereitzustellen, das einfach umzusetzen ist und keine \u00fcberlangen Header-Felder erfordert (Verf\u00fcgungspatentschrift Abs. [0013]), und zum anderen ein Verfahren bereitzustellen, mit dem in einem NFC-Chipsatz der Hostprozessor festgestellt werden kann, der der Empf\u00e4nger der \u00fcber einen kontaktlosen Daten\u00fcbertragungskanal empfangenen Daten ist, ohne dabei notwendigerweise den Inhalt dieser Daten analysieren zu m\u00fcssen (Verf\u00fcgungspatentschrift Abs. [0017]).<\/p>\n

Dies sucht die Erfindung mit einem Datenroutingverfahren und einer Datensende-\/ Empfangsvorrichtung nach den Anspr\u00fcchen 1 und 12 zu erreichen, die die folgenden Merkmale aufweisen:<\/p>\n

Anspruch 1:
\n1. Datenrouting-Verfahren in einem Chipsatz
\n2. Der Chipsatz umfasst
\na) eine Steuereinheit (NFCC),
\nb) eine kontaktlose Datensende-\/ Empfangsschnittstelle (CLINT) vom RFID-Typ und
\nc) wenigstens einen Hostprozessor (HP1, HP2).
\n3. Das Verfahren umfasst die folgenden Schritte:
\na) Senden eines Datenweger\u00f6ffnungsbefehls (CMD) mittels eines im Hostprozessor lokalisierten Ausgangspunktes (P1, P2) an die Steuereinheit,
\na1) wobei der Datenweger\u00f6ffnungsbefehl einen in der kontaktlosen Datensende-\/Empfangsschnittstelle (CLINT) lokalisierten Bestimmungspunkt (P3) benennt,
\nb) Er\u00f6ffnen eines Datenweges mittels der Steuereinheit (NFCC) als Antwort auf den Datenweger\u00f6ffnungsbefehl (CMD),
\nb1) wobei der Datenweg den Ausgangspunkt mit dem Bestimmungspunkt verbindet,
\nb2) wobei dem Datenweg eine Routingkanalnummer (CHANi) zugewiesen wird und
\nb3) 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,
\nc) Senden von in einem Daten\u00fcbertragungsblock (DF) verkapselten und f\u00fcr den Bestimmungspunkt bestimmten Daten an die Steuereinheit (NFCC) mittels des Ausgangspunktes,
\nc1) wobei der Daten\u00fcbertragungsblock ein die Routingkanalnummer umfassendes Header-Feld aufweist,
\nd) Suchen eines Bestimmungspunktes der Daten in der Routing-Tabelle beim Empfang der in dem Daten\u00fcbertragungsblock (DF) verkapselten Daten mittels der Steuereinheit (NFCC),
\nd1) wobei der Daten\u00fcbertragungsblock ein die Routingkanalnummer umfassendes Header-Feld aufweist und
\nd2) wobei bei der Suche die Routingkanalnummer als Index f\u00fcr die Auswahl des Bestimmungspunktes verwendet wird,
\ne) Senden der Daten an den Bestimmungspunkt.<\/p>\n

Anspruch 12
\n1. Datensende-\/Empfangsvorrichtung (NFCR2)
\n2. Die Datensende-\/Empfangsvorrichtung (NFCR2) umfasst:
\na) eine Steuereinheit (NFCC),
\nb) eine kontaktlose Datensende-\/Empfangsschnittstelle (CLINT) vom RFID-Typ und
\nc) wenigstens einen Eingangs\/Ausgangsport (INT1, INT2), um die kontaktlose Datensende-\/Empfangsschnittstelle (CLINT) mit einem Hostprozessor (HP1, HP2) zu verbinden.
\n3. Die Steuereinheit (NFCC) ist konfiguriert, um
\na) als Antwort auf einen Datenweger\u00f6ffnungsbefehl (CMD) einen Datenweg zwischen dem Ausgangspunkt und einem Bestimmungspunkt zu er\u00f6ffnen,
\na1) wobei der Datenweger\u00f6ffnungsbefehl von einem in einem Hostprozessor (HP1, HP2) lokalisierten Ausgangspunkt gesandt wurde,
\na2) wobei der Datenweger\u00f6ffnungsbefehl einen in der kontaklosen Datensende-\/Empfangsschnittstelle (CLINT) lokalisierten Bestimmungspunkt (P3) benennt,
\na3) wobei dem Datenweg eine Routingkanalnummer (CHANi) zugewiesen ist und
\na4) 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,
\nb) beim Empfang von in einem Daten\u00fcbertragungsblock (DF) verkapselten Daten einen Bestimmungspunkt der Daten in der Routing-Tabelle zu suchen,
\nb1) wobei der Daten\u00fcbertragungsblock ein die Routingkanalnummer umfassendes Header-Feld aufweist und
\nb2) wobei bei der Suche die Routingkanalnummer als Index f\u00fcr die Auswahl des Bestimmungspunktes verwendet wird.<\/p>\n

II.
\nIm Hinblick auf den Streit der Parteien bedarf die Merkmalsgruppe 3 der Anspr\u00fcche 1 und 12 n\u00e4herer Erl\u00e4uterung. Aus Gr\u00fcnden der Vereinfachung wird dabei auf die Merkmale des Anspruchs 1 abgestellt, die sich in Anspruch 12 in (weitgehend) gleicher Weise \u2013 jedoch teilweise mit etwas unterschiedlicher Bezifferung \u2013 wiederfinden.<\/p>\n

Als einschl\u00e4gigen Fachmann sieht die Kammer \u2013 wie das Bundespatentgericht – einen Diplom-Ingenieur der Fachrichtung Elektrotechnik oder Informationstechnik mit Spezialisierung auf dem Gebiet der Nahfeldkommunikation an.<\/p>\n

Die Merkmalsgruppe 3 beschreibt die Umsetzung der erfindungsgem\u00e4\u00dfen 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\u00fcgungspatentschrift:<\/p>\n

Gezeigt ist ein erfindungsgem\u00e4\u00dfer 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.<\/p>\n

Gem\u00e4\u00df Merkmal 3.a) wird zun\u00e4chst mittels eines im Hostprozessor lokalisierten Ausgangspunktes (P1, P2) ein Datenweger\u00f6ffnungsbefehl an die Steuereinheit gesandt. Der Datenweger\u00f6ffnungsbefehl soll nach Merkmal 3.a)a1) den Bestimmungspunkt des Datenweges benennen, der in der kontaktlosen Datensende-\/Empfangsschnittstelle lokalisiert ist. Auf diese Weise erh\u00e4lt die Steuereinheit die f\u00fcr die Identifizierung des Datenweges erforderlichen Routingparameter.<\/p>\n

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\u00e4nger eines solchen Datenflusses sein k\u00f6nnen (Verf\u00fcgungspatentschrift Abs. [0065] sowie Unteranspr\u00fcche 9 und 20).<\/p>\n

Der Datenweger\u00f6ffnungsbefehl geht von dem Ausgangspunkt in einem Hostprozessor aus. Die eigentliche Erzeugung des Datenweges erfolgt sodann durch die Steuereinheit (NFCC) im NFC-Leser (NFCR) (Verf\u00fcgungspatentschrift Abs. [0048]). Als Antwort auf den Datenweger\u00f6ffnungsbefehl wird mittels der Steuereinheit der angefragte Datenweg zwischen Ausgangs- und Bestimmungspunkt er\u00f6ffnet (Merkmal 3.b). Der Begriff des \u201eEr\u00f6ffnens\u201c ist in der Verf\u00fcgungspatentschrift nicht gesondert definiert. In funktionaler Hinsicht meint \u201eEr\u00f6ffnen\u201c das Festlegen\/Bereitstellen eines Datenweges f\u00fcr einen zu einem sp\u00e4teren Zeitpunkt vorzunehmenden Datentransport.<\/p>\n

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\u00fcgungspatent auch die M\u00f6glichkeit, auf eine bereits voreingetragene Routingtabelle zur\u00fcckzugreifen, indem in der Routing-Tabelle ein passender Datenweg gesucht wird, wenn Daten von der kontaktlosen Datensende-\/Empfangsschnittstelle \u00fcber einen kontaktlosen Daten\u00fcbertragungskanal empfangen werden (Verf\u00fcgungspatentschrift Abs. [0025], vgl. auch Abs. [0034], [0035]). Das erfindungsgem\u00e4\u00dfe \u201eEr\u00f6ffnen\u201c des Datenweges besteht in diesem Fall darin, dass die Steuereinheit NFCC in das Feld \u201ebelegt\u201c den Wert \u201e1\u201c eintr\u00e4gt (Verf\u00fcgungspatentschrift Abs. [0050]). Ob und wann \u00fcber den solcherma\u00dfen er\u00f6ffneten Datenweg eine Daten\u00fcbertragung stattfindet, kann Gegenstand eines gesonderten Befehls sein und hat in funktionaler Hinsicht nichts zu tun mit dem erfindungsgem\u00e4\u00dfen \u201eEr\u00f6ffnen\u201c des Datenweges.<\/p>\n

Der \u201eer\u00f6ffnete\u201c Datenweg verbindet den Ausgangspunkt mit dem Bestimmungspunkt (Merkmal 3.b)b1)). Mit dem Er\u00f6ffnen 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\u00fcckgriff auf die Routing-Tabelle der jeweilige Datenweg identifiziert werden.<\/p>\n

Dies erm\u00f6glicht es, bei der \u00dcbermittlung von in einem Daten\u00fcbertragungsblock 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)).<\/p>\n

In funktionaler Hinsicht muss die Routing-Tabelle solcherma\u00dfen ausgestaltet sein, dass die Steuereinheit auf sie zugreifen und die Verkn\u00fcpfung zwischen einer bestimmten Routingkanalnummer und den Identifizierern des zugeh\u00f6rigen Datenweges abfragen kann. Dabei l\u00e4sst das Verf\u00fcgungspatent offen, auf welche Weise dies gew\u00e4hrleistet wird, insbesondere, wie die Routing-Tabelle aufgebaut ist und wo sie gespeichert wird. Es gen\u00fcgt vielmehr jede Zuordnung von Identifizierern des Ausgangs- und Bestimmungspunktes zu einer Routingkanalnummer, die so gespeichert ist, dass der Host-Controller f\u00fcr 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\u00e4nger eines solchen Datenflusses ist. Im Rahmen des Routings muss dann die Routingkanalnummer tats\u00e4chlich als Index f\u00fcr die Auswahl des Bestimmungspunktes verwendet werden (Merkmal 3.d)d2)).<\/p>\n

III.
\nVor diesem Hintergrund ist seitens der Verf\u00fcgungskl\u00e4gerin nicht hinreichend glaubhaft gemacht, dass Angebot und Lieferung der angegriffenen Ausf\u00fchrungsformen II und III eine mittelbare Verletzung von Anspruch 1 des Verf\u00fcgungspatents im Sinne von \u00a7 10 Abs. 1 PatG oder eine unmittelbare Verletzung von Anspruch 12 des Verf\u00fcgungspatents im Sinne von \u00a7 9 PatG begr\u00fcnden.<\/p>\n

Denn es ist jedenfalls nicht hinreichend glaubhaft gemacht, dass beim Empfang von Daten gem\u00e4\u00df der Merkmalsgruppe 3.d) der Bestimmungspunkt in einer Routing-Tabelle gesucht wird, wobei die Routingkanalnummer als Index f\u00fcr die Auswahl des Bestimmungspunktes verwendet wird. Dies l\u00e4sst sich weder anhand des Standards noch anhand der von der Verf\u00fcgungsbeklagten vorgelegten Ausz\u00fcge aus dem Quellcode feststellen.<\/p>\n

Zwischen den Parteien ist unstreitig, dass die angegriffenen NFC-Controller des Typs \u201eJ\u201c und des Typs \u201eQ\u201c nach den Vorgaben des Standards ETSI TS 102 622 V11.0.0 (2011-09) arbeiten. Die Verf\u00fcgungskl\u00e4gerin hat von der Firma A verschiedene Tests durchf\u00fchren lassen, die best\u00e4tigen, dass die streitgegenst\u00e4ndlichen F-Chips in dem f\u00fcr die Entscheidung ma\u00dfgeblichen Umfang gleich funktionieren (vgl. Anlagen Ast33, Ast34). Dies best\u00e4tigt auch die Verf\u00fcgungsbeklagte, die unter Vorlage einer entsprechenden eidesstattlichen Versicherung des Herrn Dubois (Anlage HL9\/HL9a) vortr\u00e4gt, die Quellcodes der beiden Chips seien in den hier ma\u00dfgeblichen Teilen identisch.<\/p>\n

1.
\nDie Umsetzung des Standards durch die angegriffenen Ausf\u00fchrungsformen begr\u00fcndet \u2013 entgegen der Auffassung der Verf\u00fcgungskl\u00e4gerin \u2013 f\u00fcr sich genommen nicht die Verwirklichung der gesamten Merkmalsgruppe 3.<\/p>\n

Der Standard betrifft eine logische Schnittstelle, die kontaktlose Anwendungen, gehostet auf der Universal Integrated Circuit Card (UICC), erm\u00f6glicht. 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\u00e4t verstanden, die mindestens einen Dienst betreibt. Der Host-Controller ist ein Host, der auch f\u00fcr die Verwaltung des Hostnetzwerks zust\u00e4ndig ist. Jeder in einem Host betriebene Dienst verf\u00fcgt \u00fcber einen Eingangspunkt, der als Gate bezeichnet wird. Zwischen den Gates unterschiedlicher Hosts werden Kommunikationskan\u00e4le gebildet, die als Pipe bezeichnet werden.<\/p>\n

Das im Standard beschriebene Datenrouting-Verfahren ist in Abbildung 2 der Anlage AST25 schematisch dargestellt:<\/p>\n

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\u00fcpfungs-Gates und weitere Gates auf (Anlage Ast25 Kapitel 4.3). Zwischen den Gates gibt es logische Kommunikationskan\u00e4le, die sog. Pipes. Die Parteien gehen zu Recht \u00fcbereinstimmend davon aus, dass die Pipe im Sinne des HCI-Standards einen Datenweg im Sinne des Verf\u00fcgungspatents darstellt, wobei die beiden Gates, zwischen denen die Pipe besteht, patentgem\u00e4\u00df den Ausgangs- und Bestimmungspunkt dieses Datenweges bilden. Es gibt statische Pipes, die immer verf\u00fcgbar sind und dynamische Pipes, die erstellt und gel\u00f6scht werden k\u00f6nnen (Anlage Ast25 Kapitel 4.4). Die Pipes zu den Verwaltungsverkn\u00fcpfungsgates 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\u00fcssen im Hostnetzwerk eindeutig sein (Anlage Ast25 Kapitel 4.4).<\/p>\n

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 \u00fcber die bestehende statische Pipe einen Datenweger\u00f6ffnungsbefehl (ADM_CREATE_PIPE, vgl. Anlage Ast25 Tabelle 4) an das Administrations-Gate des Host-Controllers (Merkmal 3.a)). Dieser Datenweger\u00f6ffnungsbefehl 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)<\/p>\n

Der Host-Controller verwendet die vom Zielhost definierte \u201eWei\u00dfe Liste\u201c, um zu \u00fcberpr\u00fcfen, 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).<\/p>\n

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 \u00fcbermittelt (Anlage AST25 Kapitel 6.1.3.2, Tabelle 11). Diese Pipe-ID stellt die erfindungsgem\u00e4\u00dfe 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 \u201e02\u201c bis \u201e6F\u201c zugewiesen bekommen. Jeder dynamische Pipe-Bezeichner muss im Hostnetzwerk eindeutig sein (Anlage Ast25 Kapitel 4.4).<\/p>\n

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 \u00fcbermittelt.<\/p>\n

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

Nach dem Standard tauschen die Hosts Datenpakete aus. Ein solches Paket besteht aus einem Header und der eigentlichen Nachricht. Der Header enth\u00e4lt 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\u00f6nnen alle Gates, die \u00fcber 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 \u00fcbermittelten Datenpakets zu bestimmen, gibt der Standard nicht vor. Insbesondere ist an dieser Stelle nicht von einem R\u00fcckgriff auf die vorhandenen Register die Rede. Insofern hat auch die Verf\u00fcgungskl\u00e4gerin in der m\u00fcndlichen Verhandlung vom 06.05.2016 einger\u00e4umt, dass der Standard keine Informationen zum tats\u00e4chlichen Senden der Datenpakete mittels der Pipe-ID enth\u00e4lt.<\/p>\n

Der von der Verf\u00fcgungsbeklagten beauftragte Privatgutachter Herr Prof. U erl\u00e4utert in seinem Gutachten (Anlage HL8), dass es neben der M\u00f6glichkeit der Entnahme von Informationen aus einer Routing-Tabelle zwei weitere M\u00f6glichkeiten gebe, das zu routende Datenpaket nur durch Auswertung der ihm beigef\u00fcgten 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\u00f6glichkeiten handele. Denn diese w\u00fcrden unterschiedliche technische Vor- und Nachteile insbesondere im Hinblick auf den Implementierungsaufwand und die Flexibilit\u00e4t 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\u00fcckgriff auf eine Routingtabelle im Sinne der Lehre des Verf\u00fcgungspatents m\u00f6glich ist. Die Verf\u00fcgungskl\u00e4gerin hat die von der Beklagten dargestellten technischen M\u00f6glichkeiten als solche best\u00e4tigt, auch wenn sie der Auffassung ist, dass es sich bei der Verwendung eines Algorithmus oder einer Schaltung letztlich nur um theoretische M\u00f6glichkeiten handele. Die Verwendung einer Routing-Tabelle ist f\u00fcr das durchzuf\u00fchrende Routing nach dem Standard damit jedenfalls nicht zwingend, so dass allein der Verweis auf die Standardkonformit\u00e4t der angegriffenen Ausf\u00fchrungsformen nicht geeignet ist, den Verletzungsnachweis zu f\u00fchren.<\/p>\n

2.
\nAuch anhand der von der Verf\u00fcgungsbeklagten vorgelegten Teile des Quellcodes ist der Verf\u00fcgungskl\u00e4gerin ein solcher Nachweis nicht gelungen. Denn sie belegen nicht die Verwendung einer Routing-Tabelle im Sinne des Verf\u00fcgungspatents f\u00fcr die Suche nach dem Bestimmungspunkt eines eingehenden Datenpakets (Merkmalsgruppe 3.d)).<\/p>\n

Die Verf\u00fcgungsbeklagte erl\u00e4utert die Funktionsweise der angegriffenen NFC-Chips anhand der vorgelegten Quellcode Datei A27 wie folgt:
\nBei Eingang eines Datenpaketes mit einer Pipe-ID im Header werde zun\u00e4chst 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\u00fcr den Parameter bPipeOffset gespeichert. Der Offset-Wert f\u00fchre 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\u00dfend 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 \u00fcber den \u00fcbergebenen 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 \u00fcber 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\u00fcr das dem mode zugeordnete Gate CeA, CeB oder CeF aufgerufen.<\/p>\n

Die vorstehend wiedergegebenen Ausf\u00fchrungen der Verf\u00fcgungsbeklagten lassen sich anhand des vorgelegten Quellcodes im Grundsatz nachvollziehen. Ein offensichtlicher Widerspruch ergibt sich f\u00fcr die Kammer nicht. Auch die Verf\u00fcgungskl\u00e4gerin tritt dem Vorbringen der Verf\u00fcgungsbeklagten nicht substantiiert entgegen. Insbesondere vermag sie keine Stellen im Quellcode zu benennen, die definitiv belegen, dass f\u00fcr das Senden der Daten der Bestimmungspunkt in einer Routingtabelle gesucht wird, wobei die Routingkanalnummer als Index dient. Zwar erm\u00f6glicht das in Bezug genommene Array aPipePackLookUp eine Zuordnung zwischen der Pipe-ID und dem jeweiligen Ausgangshost; die dort aufgef\u00fchrten \u201eupper three bits\u201c definieren gem\u00e4\u00df Zeile 61, f\u00fcr welchen Host sie g\u00fcltig sind. Die LookUpTable enth\u00e4lt aber keine eindeutige Zuordnung zum Zielhost\/-gate. Vielmehr bestimmen die \u201elower three bits\u201c nur das Offset f\u00fcr die jeweilige Pipe-ID und damit die Verarbeitungsfunktion f\u00fcr die Verarbeitung am richtigen Gate.<\/p>\n

Aufgrund der Ausf\u00fchrungen der Verf\u00fcgungsbeklagten erscheint es jedenfalls m\u00f6glich, 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\u00e4\u00dfen Routing-Tabelle) entbehrlich macht. Abschlie\u00dfend kann dies nicht beurteilt werden, weil die Einzelheiten der Funktionsweise und die Werte der Parameter nicht ersichtlich sind.<\/p>\n

Soweit die Verf\u00fcgungskl\u00e4gerin einwendet, dass der vorgelegte Quellcode nicht vollst\u00e4ndig sei und gerade nicht die Definition f\u00fcr die zentrale Funktion phSwpFeRom_Send enthalte, kann ihr Einwand nicht zum Erfolg ihres Antrags f\u00fchren. Denn die Darlegungslast im Hinblick auf die Verwirklichung der patentgem\u00e4\u00dfen Lehre tr\u00e4gt grunds\u00e4tzlich die Verf\u00fcgungskl\u00e4gerin. Die Verf\u00fcgungsbeklagte hat ihrer sekund\u00e4ren Darlegungslast dadurch gen\u00fcgt, dass sie anhand der Datei A27 nachvollziehbar die Kommunikation vom Host zur Schnittstelle im Emulationsmodus erl\u00e4utert hat. Warum sich aus anderen Teilen des Quellcodes etwas grunds\u00e4tzlich anderes ergeben sollte, hat die Verf\u00fcgungskl\u00e4gerin nicht substantiiert vorgetragen. Auch sieht die Kammer keine Anhaltspunkte daf\u00fcr, dass im Lesemodus etwas erfindungswesentlich anderes gelten sollte.<\/p>\n

V.
\nDie Kostenentscheidung beruht auf \u00a7 91 Abs. 1 Satz 1 ZPO.<\/p>\n

Die Entscheidung zur vorl\u00e4ufigen Vollstreckbarkeit folgt aus den \u00a7\u00a7 708 Nr. 6, 711 Satz 2, 108 ZPO.<\/p>\n

Der Streitwert wird auf 1.000.000,00 Euro festgesetzt.<\/p>\n","protected":false},"excerpt":{"rendered":"

D\u00fcsseldorfer Entscheidungs Nr.: 2522 Landgericht D\u00fcsseldorf Urteil vom 24. Mai 2016, Az.\u00a04b O 16\/16<\/p>\n","protected":false},"author":25,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[18,2],"tags":[],"class_list":["post-6325","post","type-post","status-publish","format-standard","hentry","category-18","category-lg-duesseldorf"],"acf":[],"_links":{"self":[{"href":"https:\/\/d-prax.de\/index.php?rest_route=\/wp\/v2\/posts\/6325","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/d-prax.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/d-prax.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/d-prax.de\/index.php?rest_route=\/wp\/v2\/users\/25"}],"replies":[{"embeddable":true,"href":"https:\/\/d-prax.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=6325"}],"version-history":[{"count":1,"href":"https:\/\/d-prax.de\/index.php?rest_route=\/wp\/v2\/posts\/6325\/revisions"}],"predecessor-version":[{"id":6326,"href":"https:\/\/d-prax.de\/index.php?rest_route=\/wp\/v2\/posts\/6325\/revisions\/6326"}],"wp:attachment":[{"href":"https:\/\/d-prax.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6325"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/d-prax.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6325"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/d-prax.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6325"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}