6 Ni 72/14 (EP) - 6. Senat (Nichtigkeit)

BPatG 253 08.05 BUNDESPATENTGERICHT IM NAMEN DES VOLKES 6 Ni 72/14 (EP) (Aktenzeichen) URTEIL Verkündet am 13. Januar 2016 … In der Patentnichtigkeitssache - 2 - betreffend das europäische Patent 1 855 229 (DE 60 2007 008 313) hat der 6. Senat (Nichtigkeitssenat) des Bundespatentgerichts auf die mündliche Verhandlung vom 13. Januar 2016 durch die Vorsitzende Richterin Friehe, die Richter Schwarz und Dipl.-Phys. Dr. Schwengelbeck, die Richterin Dipl.-Phys. Dr. Otten-Dünnweber sowie den Richter Dipl.-Ing. Altvater f ü r R e c h t e r k a n n t : I. Die Klage wird abgewiesen. II. Die Kosten des Rechtsstreits trägt die Klägerin. III. Das Urteil ist gegen Sicherheitsleistung in Höhe von 110 % des zu vollstreckenden Betrages vorläufig vollstreckbar. T a t b e s t a n d Die Beklagte ist eingetragene Inhaberin des auch mit Wirkung für das Hoheitsge-biet der Bundesrepublik Deutschland erteilten europäischen Patents 1 855 229 (Streitpatent), das am 23. März 2007 unter Inanspruchnahme der Priorität aus den französischen Anmeldungen FR 0604179 und FR 0604180 jeweils vom 10. Mai 2006 angemeldet worden ist. Das Streitpatent wurde in der Verfahrens-sprache Französisch veröffentlicht und wird beim Deutschen Patent- und Marken-amt unter dem Aktenzeichen 60 2007 008 313.3 geführt. Das Streitpatent trägt die Bezeichnung „Procédé de routage de données sortantes et entrantes dans un chipset NFC“ (in Deutsch laut Streitpatentschrift: „Verfahren zur Weiterleitung von aus- und eingehenden Daten in ein NFC-Chipset“) und umfasst in der erteilten Fassung 22 Patentansprüche, von denen mit der am 2. Juni 2014 erhobenen Nichtigkeitsklage die nebengeordneten Ansprüche 1 und 12 angegriffen werden. - 3 - Die angegriffenen Patentansprüche 1 und 12 in der erteilten Fassung lauten in der Verfahrenssprache wie folgt: - 4 - In der deutschen Übersetzung laut Streitpatentschrift lauten sie wie folgt: Die Klägerin ist der Ansicht, dass die mit ihrer Klage angegriffenen Gegenstände des Streitpatents nicht patentfähig und daher für nichtig zu erklären seien. Hierzu führt sie aus, dass sie gegenüber den von ihr benannten Druckschriften D1 D1-DE WO 2004/029860 A1 deutsche Übersetzung der D1 oder D2 D2-DE JP 2000-182007 A deutsche Übersetzung der D2 - 5 - D2-EN englische Maschinenübersetzung der D2 nicht neu seien. Mit Schriftsatz vom 21. Dezember 2015 hat sie geltend gemacht, ein Verfahren gemäß Patentanspruch 1 sei auch gegenüber der Druckschrift D3 (bzw. der D3a) D3 Auszüge aus „Specification of the Bluetooth System, Bluetooth Specification Version 2.0 + EDR“: Vol. 0, “Master Table of Contents and Compliance Require-ments”, S. 1-74 von 74 Vol. 1, “Architecture & Terminology Overview”, S. 1-26 von 92 Vol. 3, “Core System Package [Host Volume]”, S. 1-22 und S. 335-618 von 814 D3a Specification of the Bluetooth System, Bluetooth Specification Ver-sion 2.0 + EDR, Specification Volume 0-3, 4 November 2004 (voll-ständige Fassung) nicht neu. Darüber hinaus beruhten die Gegenstände der angegriffenen Patentansprüche gegenüber dieser Druckschrift oder der D15 D15 WO 02/080452 A2 jeweils insbesondere in Kenntnis der Druckschriften D4 EP 1 499 070 A2 oder MN12 Salminen, T.: Enhancing Bluetooth Connectivity with RFID. In: Proc. of the 4th Annual IEEE Conf. on Pervasive Computing and Communications, 13.-17.3.2006 - 6 - oder MN13 HALL, E.S. et al, RF Rendez Blue: Reducing Power and Inquiry Costs in Bluetooth-Enabled Mobile Systems. 11th Int. Conf. on Computer Communications and Networks, 14.-16.10.2002 nicht auf einer erfinderischer Tätigkeit. Darüber hinaus stützt sie ihre Argumentation u.a. auch auf die Druckschriften D5 WO 02/33644 A1 D6 WO 98/27670 A1 D7 WO 03/017103 A1 D8 Infrared Data Association® (IrDA®) Object Exchange Protocol, OBEX™, Version 1.3, 3. Januar 2003 D9 US 2005/236491 A1 D10 US 2005/259673 A1 D11 US 2003/136829 A1 D12 EP 1 608 123 A1 D13 DE 199 00 345 A1 D14 JP 2003-30596 A MN7 Auszug aus: Finkenzeller, K.: RFID-Handbuch, 5. Auflage, S. 64-67 Die Klägerin beantragt, das europäische Patent 1 855 229 im Umfang der Ansprüche 1 und 12 mit Wirkung für die Bundesrepublik Deutschland für nichtig zu erklären. - 7 - Die Beklagte beantragt, die Klage abzuweisen, hilfsweise, die Klage teilweise in Bezug auf Patentanspruch 1 ab-zuweisen, weiter hilfsweise, die Nichtigkeitsklage abzuweisen, soweit der Hilfsantrag vom 8. Dezember 2015 reicht. Die Beklagte tritt der Argumentation der Klägerin entgegen und hält die Gegen-stände des Streitpatents nach den angegriffenen Patentansprüchen 1 und 12 in der erteilten Fassung, hilfsweise zumindest nach Patentanspruch 1 in der erteilten Fassung, weiter hilfsweise in der Fassung des Hilfsantrages laut Schriftsatz vom 8. Dezember 2015 für patentfähig. Der Hilfsantrag vom 8. Dezember 2015 unterscheidet sich hinsichtlich der ange-griffenen Patentansprüche 1 und 12 von der erteilten Fassung lediglich hinsichtlich der einleitenden Worte der angegriffenen Patentansprüche, die in Patentan-spruch 1 (Abweichungen von der erteilten Fassung unterstrichen) „Datenrouting-Verfahren in einem NFC-Chipsatz, umfassend wenigstens […]“ und in Patentan-spruch 12 „NFC Datensende-/Empfangsvorrichtung (NFCR2) umfassend […]“ lauten. Zur Stützung ihrer Auffassung hat sich die Beklagte u.a. auf die Druckschrift NB1 Stellungnahme des Instituts Fraunhofer ESK vom 30. No-vember 2015 berufen. - 8 - Der Senat hat den Parteien einen qualifizierten Hinweis vom 5. Oktober 2015 zu-geleitet. Auf den Hinweis wird Bezug genommen. Zu weiteren Einzelheiten wird auf die Akte verwiesen. E n t s c h e i d u n g s g r ü n d e A. Die Klage ist zulässig, hat aber in der Sache keinen Erfolg, weil der mit ihr geltend gemachte Nichtigkeitsgrund der mangelnden Patentfähigkeit gemäß Artikel II § 6 Absatz 1 Nr. 1 IntPatÜG, Art. 138 Abs. 1 Buchst. a) EPÜ i. V. m. Art. 52, 54 und 56 EPÜ gegenüber den Gegenständen des Streitpatents nach den allein ange-griffenen erteilten Patentansprüchen 1 und 12 nicht besteht. Vielmehr erweisen sich diese Gegenstände schon in der erteilten Fassung der Patentansprüche 1 und 12 gegenüber dem von der Klägerin geltend gemachten Stand der Technik als neu und auf einer erfinderischen Tätigkeit beruhend, so dass die auf ihre Nich-tigerklärung gerichtete Klage abzuweisen ist. I. Zum Gegenstand des Streitpatents 1. Die Erfindung betrifft ein Datenrouting-Verfahren in einem Chipsatz, umfas-send wenigstens einen Hostprozessor und eine kontaktlose Datensende-/ Emp-fangsschnittstelle vom RFID Typ (Anspruch 1), sowie eine Datensende-/ Emp-fangsvorrichtung, umfassend eine kontaktlose Datensende-/ Empfangsschnitt-stelle vom RFID Typ, eine Steuereinheit und wenigstens einen Eingangs-/ Aus-gangsport, um wenigstens eine Datensende-/Empfangsschnittstelle mit einem Hostprozessor zu verbinden (Anspruch 12). Das Streitpatent zeige, so dessen Be-schreibungseinleitung, insbesondere die Umsetzung solcher Schaltkreise für einen - 9 - NFC-(Near Field Communication) Chipsatz (vgl. Streitpatent, Abs. [0001] bis [0003]). Das Streitpatent geht davon aus, dass die NFC-Technologie auf der RFID-Tech-nologie (Radio Frequency Identification) basiere und NFC-Leser mit mehreren Betriebsmodi verwende. lm „Leser-Modus“ (Reader Mode) funktioniere der NFC-Leser wie ein herkömmlicher RFID-Leser. Der Leser sende ein Magnetfeld aus und übermittle Daten mittels Modulation der Amplitude des Magnetfelds und empfange Daten mittels Lastmodulation und induktiver Kopplung. lm „Emulations-Modus“ funktioniere der NFC-Leser in passiver Form in der Art eines Transpon-ders. Der Leser sende kein Magnetfeld aus, sondern empfange Daten durch De-modulation eines von einem anderen Leser ausgesendeten Magnetfelds und sende Daten durch Modulation der Impedanz seines Antennenschaltkreises (Lastmodulation). lm „Device-Modus“ bringe sich jeder Leser alternierend in einen passiven Zustand, um Daten zu empfangen, und in einen aktiven Zustand, um Daten zu senden. Zusätzlich zu diesen drei Betriebsmodi könne ein NFC-Leser mehrere kontaktlose Kommunikationsprotokolle einsetzen. Ein Beispiel für einen NFC-Chipsatz (CHIPSET) zeige Figur 1 des Streitpatents. Dargestellt sei ein NFC-Chipsatz umfassend einen NFC-Leser (NFCR1) sowie einen ersten und einen zweiten Hostprozessor. Der erste Hostprozessor (HP1) sei beispielsweise ein Basisbandschaltkreis eines Mobiltelefons („baseband" oder - 10 - Sprechfunkschaltung) und der zweite Hostprozessor (HP2) sei beispielsweise eine SIM-Karte (d. h. die Mikrosteuereinheit in einer SIM-Karte). Der NFC-Leser stelle demnach zwei Prozessoren (HP1 und HP2) zur Verfügung, die jeweils eine Ver-waltung von kontaktlosen Anwendungen ermöglichten. Folglich erfordere die Rea-lisierung eines solchen NFC-Chipsatzes das Vorsehen eines Routings von Daten-flüssen zu sendender Daten zwischen dem jeweiligen Prozessor und dem NFC-Leser und von eingehenden Datenflüssen (empfangene Daten) zwischen dem NFC-Leser und dem jeweiligen Prozessor. Aufgrund verschiedener möglicher Kommunikationsprotokolle und Betriebsmodi müsse die im NFC-Leser enthaltene kontaktlose Datensende-/ Empfangsschnitt-stelle (CLINT), die von den mehreren Prozessoren verwendet werden könne, ent-sprechend eingestellt werden. Dies bedeute, dass der Prozessor für jede zu sen-dende Datenkette die von der Schnittstelle für die Übertragung dieser Daten zu verwendende Konfiguration aus Betriebsmodus und Kommunikationsprotokoll an-geben müsse. Um das Routing der ausgehenden Daten und gleichzeitig die Kon-figuration der Schnittstelle des NFC-Lesers zu ermöglichen, sei ein HCI („Host Controller lnterface“) Datenübertragungsprotokoll vorgesehen, welches jedem Hostprozessor ermögliche, an die Schnittstelle zu sendende Daten zu liefern und die dabei zu verwendende Konfiguration zu spezifizieren. Ein solches HCI-Proto-koll sehe Datenübertragungsblöcke vor, die jeweils Header-Felder (mit Informatio-nen zur Steuerung der Schnittstelle) und Datenfelder umfassten (vgl. Streitpatent, Abs. [0004] bis [0011]). Ein erstes Problem ergebe sich daraus, dass das klassische HCI-Protokoll lange und komplexe Header-Felder umfasse und einen erheblichen Verarbeitungsauf-wand erfordere. Ein anderes Problem betreffe das Routing der eingehenden Da-ten, da beim Empfang von eingehenden Daten die kontaktlose Datensende-/ Empfangsschnittstelle und die Steuereinheit des NFC-Lesers nicht unbedingt wüssten, welcher Hostprozessor der interne Datenempfänger innerhalb des Chipsatzes sei. Dies werde im Stand der Technik beispielsweise dadurch gelöst, - 11 - dass die Daten an alle Prozessoren übermittelt würden, wobei der Prozessor, den diese Daten nicht betreffen, nicht darauf antworte. Zu diesen beiden Problemfeldern gibt das Streitpatent zwei Aufgaben an. So solle ein Datenrouting-Verfahren in einem NFC-Chipsatz bereitgestellt werden, welches einfach umzusetzen sei und keine überlangen Header-Felder erfordere, während es die Parametrierung des Protokolls und des Betriebsmodus der kontaktlosen Datensende-/Empfangsschnittstelle ermögliche. Außerdem solle ein Verfahren bereitgestellt werden, mit dem in einem NFC-Chipsatz der Hostprozessor festge-stellt werden könne, welcher der Empfänger der über einen kontaktlosen Daten-übertragungskanal empfangenen Daten sei, ohne den Inhalt dieser Daten analy-sieren zu müssen (vgl. Streitpatent, Abs. [0012] bis [0017]). Zur Lösung der gestellten Aufgaben schlägt das Streitpatent ein Verfahren mit den Merkmalen laut dem erteilten Patentanspruch 1 und eine Datensende-/ Empfangs-vorrichtung mit den Merkmalen des erteilten nebengeordneten Patentan-spruchs 12 vor. Beide Ansprüche können dabei in deutscher Übersetzung wie folgt gegliedert werden. Basierend auf der maßgeblichen französischsprachigen Fassung wurde hierbei das Wort „wobei“ in den Merkmalen M3.1 und M3.2 bzw. N2.1b und N2.1c durch „indem“ ersetzt: Anspruch 1 M1 Datenrouting-Verfahren in einem Chipsatz, umfassend wenigstens M1.1 einen Hostprozessor (HP1, HP2), M1.2 eine Steuereinheit (NFCC) und M1.3 eine kontaktlose Datensende-/Empfangsschnittstelle (CLINT) vom RFID-Typ, dadurch gekennzeichnet, dass es die folgenden Schritte umfasst, die darin bestehen: M2 - einen Datenwegeröffnungsbefehl (CMD) mittels eines im Host-prozessor lokalisierten Ausgangspunktes (P1, P2) an die Steuer-- 12 - Anspruch 12 N1 Datensende-/Empfangsvorrichtung (NFCR2) umfassend N1.1 eine kontaktlose Datensende-/Empfangsschnittstelle (CLINT) vom RFID-Typ, einheit (NFCC) zu senden, M2.1 der einen in der kontaktlosen Datensende-/Empfangsschnittstelle (CLINT) lokalisierten Bestimmungspunkt (P3) benennt, M3 - als Antwort auf den Datenwegeröffnungsbefehl (CMD) mittels der Steuereinheit (NFCC) einen Datenweg zu eröffnen, der den Aus-gangspunkt mit dem Bestimmungspunkt verbindet, M3.1 indem wobei dem Datenweg eine Routingkanalnummer (CHANi) zugewiesen wird und M3.2 indem wobei in eine Routing-Tabelle (RT) eingetragen werden: M3.2a die Routingkanalnummer sowie M3.2b wenigstens einen Identifizierer (IDsp) des Ausgangspunk-tes und einen Identifizierer (IDdp) des Bestimmungspunk-tes umfassende Routingparameter M4 - für den Bestimmungspunkt bestimmte, in einem Datenübertra-gungsblock (DF) verkapselte Daten mittels des Ausgangspunktes an die Steuereinheit (NFCC) zu senden M4.1 [wobei der Datenübertragungsblock] ein die Routingkanal-nummer umfassendes Header-Feld aufweist, und M5 - beim Empfang der in einem Datenübertragungsblock (DF), der ein die Routingkanalnummer umfassendes Header-Feld aufweist, ver-kapselten Daten, M5.1 mittels der Steuereinheit (NFCC) einen Bestimmungspunkt der Daten in der Routing-Tabelle zu suchen M5.1a unter Verwendung der Routingkanalnummer als Index für die Auswahl des Bestimmungspunktes, und M5.2 [mittels der Steuereinheit] die Daten dann an den Bestim-mungspunkt zu senden. - 13 - N1.2 eine Steuereinheit (NFCC) und N1.3 wenigstens einen Eingangs/Ausgangsport (INT1, INT2), um die kontaktlose Datensende-/Empfangsschnittstelle (CLINT) mit einem Hostprozessor (HP1, HP2) zu verbinden, dadurch gekennzeichnet, dass N2 die Steuereinheit (NFCC) konfiguriert ist, um: N2.1 - als Antwort auf einen Datenwegeröffnungsbefehl (CMD) einen Datenweg zwischen dem Ausgangspunkt und einem Bestimmungs-punkt zu eröffnen, N2.1a1 N2.1a2 [wobei der Befehl] von einem in einem Hostprozessor (HP1, HP2) lokalisierten Ausgangspunkt gesandt wurde und der einen in der kontaktlosen Datensende-/ Empfangsschnitt-stelle (CLINT) lokalisierten Bestimmungspunkt (P3) benennt, N2.1b indem wobei dem Datenweg eine Routingkanalnummer (CHANi) zugewiesen wird und N2.1c indem wobei in eine Routing-Tabelle (RT) eingetragen werden: N2.1c1 die Routingkanalnummer sowie N2.1c2 wenigstens einen Identifizierer (IDsp) des Ausgangspunktes und einen Identifizierer (IDdp) des Bestimmungspunktes umfassende Routingparameter N2.2 - beim Empfang von in einem Datenübertragungsblock (DF), der ein die Routingkanalnummer umfassendes Header-Feld aufweist, ver-kapselten Daten, N2.2a unter Verwendung der Routingkanalnummer als Index für die Auswahl des Bestimmungspunktes, N2.2b einen Bestimmungspunkt der Daten in der Routing-Tabelle zu suchen. 2. Fachmann Als zuständigen Fachmann sieht der Senat – in Übereinstimmung mit der Auffas-sung der Klägerin, der die Beklagte insoweit nicht widersprochen hat – einen Dip-- 14 - lom-Ingenieur der Fachrichtung Elektrotechnik oder Informationstechnik mit Spe-zialisierung auf dem Gebiet der Nahfeldkommunikation, insbesondere basierend auf RFID-, Infrarot-, WLAN- oder Bluetooth-Technologie, und mehrjähriger prakti-scher Erfahrung auf diesem Gebiet. 3. Zum Verständnis des Patentgegenstands 3.1 Die Klägerin hat in der Klageschrift zutreffend darauf hingewiesen, dass in der deutschen Anspruchsfassung entgegen der maßgeblichen französischen An-spruchsfassung in den Merkmalen M3.1 und M3.2 des Anspruchs 1, sowie in den Merkmalen N2.1b und N2.1c (Anspruch 12) der Wirkzusammenhang jeweils nicht korrekt wiedergegeben sei. So erfolge bspw. die Eröffnung des Datenwegs gemäß Anspruch 1 indem (franz. Fassung „en“; engl. Fassung „by“) dem Datenweg die Kanalnummer zugewiesen und die Routingparameter in eine Tabelle eingetragen werde. Dies kommt in der deutschen Übersetzung, die „wobei“ an Stelle von „in-dem“ verwendet, nicht hinreichend zum Ausdruck. 3.2 Nach Auffassung des Senats versteht der Fachmann die Gegenstände der unabhängigen Patentansprüche 1 und 12 und die dort verwendeten Begriffe unter Heranziehung der Beschreibung und der Figuren des Streitpatents wie folgt: Das Streitpatent betrifft ein Datenrouting-Verfahren in einem Chipsatz, umfassend wenigstens einen Hostprozessor, eine Steuereinheit und eine kontaktlose Daten-sende-/ Empfangsschnittstelle vom RFID Typ (Anspruch 1), sowie eine Datens-ende- bzw. Empfangsvorrichtung, die eine kontaktlose Datensende-/ Empfangs-schnittstelle vom RFID Typ, eine Steuereinheit und wenigstens einen Eingangs-/ Ausgangsport zum Verbinden der Datensende-/Empfangsschnittstelle mit einem Hostprozessor umfasst (Anspruch 12). Dabei soll das Streitpatent gemäß der Beschreibungseinleitung insbesondere die Umsetzung solcher Schaltkreise für einen NFC-Chipsatz zeigen, wobei das Streit-patent von einer auf der RFID-Technologie basierenden NFC-Ausgestaltung mit - 15 - unterschiedlichen Betriebsmodi ausgeht. Dabei ergebe sich ein Problem daraus, dass das klassische HCI-Protokoll zur Kommunikation zwischen Hostprozessor und Steuereinheit (Controller) einen erheblichen Verarbeitungsaufwand erfordere. Ein weiteres Problem betreffe das Routing der eingehenden Daten, da die (draht-lose) Empfangsschnittstelle und die Steuereinheit des NFC-Lesers nicht von vorn-herein bestimmen können, welcher Hostprozessor der interne Datenempfänger innerhalb des Chipsatzes sei. Zu diesen beiden Problemfeldern gibt das Streitpatent zwei Aufgaben an, wie in Abschnitt A. I. 1. ausgeführt. Die dem Streitpatent tatsächlich zugrunde liegende objektive Aufgabe ist nach Ansicht des Senats darin zu sehen, ein Verfahren bereitzustellen, mit dem innerhalb eines Chipsatzes mit kontaktloser Datensende- und Empfangsschnittstelle der interne Empfänger von zu übermittelnden Daten festgestellt werden kann, ohne den Inhalt dieser Daten analysieren zu müssen oder diese Daten immer parallel an alle denkbaren Empfänger zu übermitteln. Das Datenrouting-Verfahren nach Anspruch 1 ist dadurch gekennzeichnet, dass in einem ersten Schritt ein Datenwegeröffnungsbefehl mittels eines in einem Host-prozessor (HP1, HP2) lokalisierten Ausgangspunktes an die Steuereinheit (NFCC) gesendet wird, der einen Bestimmungspunkt in der kontaktlosen Datensende-/ Empfangsschnittstelle (CLINT) benennt (vgl. Merkmale M2, M2.1). Unter Aus-gangs- und Bestimmungspunkt (P1…P3) werden jeweils die Endpunkte der jewei-ligen Kommunikation innerhalb des Chipsatzes verstanden – also die Endpunkte des Datenflusses im Chipsatz zwischen einem der Hostprozessoren (HP1, HP2) und der Schnittstelle (CLINT) und umgekehrt (vgl. Streitpatent, Fig. 3B und Fig. 4, mit Beschreibung, Abs. [0009], [0042]). Bei den Ausgangs- bzw. Bestimmungs-punkten in den Hostprozessoren kann es sich um eine Mehrzahl verschiedener Softwarekomponenten – d. h. um verschiedene Anwendungen – handeln, von de-nen ein Datenfluss ausgehen kann oder die Empfänger eines solchen Datenflus-ses sein können (vgl. Streitpatent, Abs. [0065]). - 16 - Als Antwort auf den Datenwegeröffnungsbefehl wird durch die Steuereinheit (NFCC) ein Datenweg eröffnet, der den Ausgangspunkt im Hostprozessor (von dem der Datenwegeröffnungsbefehl ausgeht) mit dem im Datenwegeröffnungs-befehl benannten Bestimmungspunkt in der kontaktlosen Datensende-/ Empfangs-schnittstelle (CLINT) verbindet (vgl. Merkmal M3). Beim Eröffnen des Datenwegs handelt es sich um die Definition eines logischen Kommunikationskanals innerhalb des Chipsatzes zwischen dem jeweils angegebenen Ausgangs- und dem Bestim-mungspunkt. Hierzu wird dem Datenweg durch die Steuereinheit eine Routingka-nalnummer (CHANi) zugewiesen (vgl. Merkmal M3.1) und diese - ebenfalls durch die Steuereinheit - zusammen mit Routingparametern in eine Routingtabelle ein-getragen. Die eingetragenen Routingparameter umfassen wenigstens einen Iden-tifizierer des Ausgangspunktes und einen Identifizierer des Bestimmungspunktes (vgl. Merkmalsgruppe M3.2). Die Routingtabelle beschreibt damit die Zuordnung eines durch die Routingkanalnummer bezeichneten logischen Kommunikationska-nals zu dessen Anfangs- und Endpunkt. Das Eröffnen eines Datenwegs unter Verwendung des Datenwegeröffnungsbefehls ist dabei Voraussetzung für ein Senden und Empfangen von Daten über einen Datenweg; es erfolgt aber zeitlich unabhängig von einem (ersten) Sendevorgang (vgl. Merkmalsgruppen M4, M5) über den jeweiligen Datenweg. - 17 - Werden für den in der kontaktlosen Datensende-/Empfangsschnittstelle lokalisier-ten Bestimmungspunkt bestimmte Daten mittels des Ausgangspunktes an die Steuereinheit gesendet, erfolgt dies in Form von verkapselten Daten in einem Datenübertragungsblock, der ein die Routingkanalnummer umfassendes Header-Feld aufweist (vgl. Merkmale M4, M4.1). Die verkapselten Daten („donnés encap-sulées“) im Datenübertragungsblock sind im Sinne einer logischen Struktur der Datenübertragungsblöcke zu verstehen, bei denen zwischen einem Header-Feld und den zu übermittelnden Nutzdaten unterschieden wird (Beispiele beschreibt das Streitpatent in Abs. [0046] und Anhang 1 ab Abs. [0076]). Beim Empfang der in einem Datenübertragungsblock verkapselten Daten durch die Steuereinheit (NFCC) wird deren Bestimmungspunkt in der kontaktlosen Da-tensende-/Empfangsschnittstelle gesucht, wobei der Bestimmungspunkt anhand der im Header des Datenübertragungsblocks enthaltenen Routingkanalnummer ermittelt wird, die dabei als Index in der Routingtabelle dient. Die Daten werden dann durch die Steuereinheit an den internen Bestimmungspunkt in der kontaktlo-sen Schnittstelle gesendet (vgl. Merkmale M5 bis M5.2). Die Datensende-/Empfangsvorrichtung (NFCR2) gemäß Anspruch 12 umfasst eine kontaktlose Datensende-/Empfangsschnittstelle vom RFID-Typ, eine Steuer-einheit (NFCC) und wenigstens einen Eingangs/Ausgangsport, der die kontaktlose Datensende-/Empfangsschnittstelle mit einem Hostprozessor verbindet (vgl. Fig. 5 und Merkmalsgruppe N1). Die Datensende-/Empfangsvorrichtung ist durch funkti-onale Merkmale der Steuereinheit (NFCC) gekennzeichnet (vgl. Merkmalsgruppen N2, N2.1 und N2.2), die den von der Steuereinheit nach Anspruch 1 ausgeführten Verfahrensschritten entsprechen. - 18 - II. Zum geltend gemachten Nichtigkeitsgrund hinsichtlich der erteilten Fassung Entgegen der Auffassung der Klägerin erweisen sich die allein angegriffenen ne-bengeordneten Patentansprüche 1 und 12 gegenüber dem geltend gemachten Stand der Technik als neu und auf einer erfinderischen Tätigkeit beruhend. 1. Zur Neuheit des Patentanspruchs 1 1.1 Stand der Technik gemäß den Druckschriften D1 und D2 Die Entgegenhaltungen D1 und D2 stehen dem Anspruch 1 des Streitpatents nicht neuheitsschädlich entgegen, wie der Senat bereits im qualifizierten Hinweis aus-geführt hat. Druckschrift D1 beschreibt ein Kommunikationsgerät, das eine kontaktlose Schnittstelle für ein Chipkartenlesegerät bereitstellt. Ihr ist keine Erzeugung und Verwendung einer Routingtabelle in der Steuereinheit („Card Access Module and Router 33a“) der Datensende-/Empfangsvorrichtung („Smart Card Router 33“) zu entnehmen (vgl. Fig. 4 und 5 mit Beschreibung). Zwar liest der Fachmann das Vorhandensein einer Zuordnungstabelle für die Kanalnummern („logical channel identifier“) – also eine Routingtabelle – zur Zuordnung von übermittelten Daten zu einzelnen Anwendungen mit. Dies betrifft jedoch nur eine Zuordnung der Daten zu Anwendungsprogrammen innerhalb des Hostprozessors selbst, nicht aber inner-halb der Steuereinheit (vgl. S. 15, erster Abs., dritter Satz). Das Druckschrift D1 entnehmbare Verfahren weist daher zumindest keine Funktionen einer Steuerein-heit gemäß der Merkmale M3.1, M3.2a und M3.2b sowie M5, M5.1 und M5.1a nach Anspruch 1 auf. Die Entgegenhaltung D2 (vgl. deutsche Übersetzung D2-DE) beschreibt ein be-rührungsloses Datenträgerkommunikationssystem. Ihr ist ebenfalls keine Erzeu-gung und Verwendung einer Routingtabelle zu entnehmen. Der jeweilige Daten-wegeröffnungsbefehl („Kommunikationsstart-Anforderungsbefehl“) des Host-Ge-- 19 - räts an das Lese-Schreib-Gerät unterscheidet nicht zwischen verschiedenen (in-ternen) Empfängern bei der Kommunikation zwischen dem Hostprozessor („Host-Gerät“) und der Steuereinheit („Lese-Schreib-Gerät“) (vgl. Abs. [0030]). Die auf-grund des Datenwegeröffnungsbefehls angelegte Korrespondenztabelle (vgl. Abs. [0030]-[0033]) dient daher nicht der Speicherung interner Routinginformatio-nen im Sinne der Merkmale M3.2a, M3.2b gemäß Anspruch 1 des Streitpatents, sondern dem Speichern „eindeutiger Daten“ externer Datenträger (vgl. Abs. [0033]). Diese Korrespondenztabelle wird zwar bei Befehlen des Hostprozes-sors durch die Steuereinheit („Lese-Schreib-Gerät“) abgefragt. Diese Abfrage dient jedoch wiederum nicht der chipsatzinternen Kommunikation im Sinne der Merkmale M5.1 und M5.1a gemäß Anspruch 1 des Streitpatents, sondern dem Erzeugen eines resultierenden Befehls an einen externen Datenträger. Das Druckschrift D2 entnehmbare Verfahren weist daher zumindest keine Merkmale M3.2a, M3.2b, M5.1 und M5.1a gemäß Anspruch 1 auf. 1.2 Stand der Technik gemäß Druckschrift D3 Der Patentgegenstand nach dem angegriffenen Patentanspruch 1 ist hinsichtlich der Merkmale M3.2b sowie M5.1 und M5.1a gegenüber dem Stand der Technik nach der Entgegenhaltung D3 neu (vgl. jeweils Druckschrift D3a, vollständige Bluetooth Spezifikation, Version 2.0). Aus der Druckschrift D3 ist ein Datenrouting-Verfahren in einem Chipsatz („Blue-tooth Host“ und „Bluetooth Controller“) bekannt (vgl. Fig. 1.2 mit Beschreibung, Vol. 3, S. 344 von 814 / Merkmal M1), wobei der Chipsatz wenigstens einen Hostprozessor umfasst („Bluetooth Host“, vgl. Vol. 1, Table 1.1, S. 16 von 92, und Vol. 3, Fig. 1.2, a. a. O. / Merkmal M1.1), sowie eine Steuereinheit („Bluetooth Controller“, vgl. Vol. 1, Table 1.1, S. 15 von 92 und Vol. 3, Fig. 1.2, a. a. O. / Merkmal M1.2) und eine kontaktlose Datensende-/Empfangsschnittstelle („Blue-tooth RF“, vgl. Tabelleneintrag zu „Bluetooth Controller“, Vol. 1, Table 1.1, S. 15 von 92 i. V. m. Vol. 3, Fig. 1.2, a. a. O. / teilweise Merkmal M1.3, Schnittstelle nicht vom „RFID-Typ“ sondern Bluetooth). - 20 - Fig. 1.2 Weiterhin ist ein Datenwegeröffnungsbefehl entnehmbar (Befehl „HCI_Create_Connection“), der mittels eines im Hostprozessor lokalisierten Aus-gangspunktes („Application“, vgl. Tabelleneintrag zu „Connection“, Vol. 1, S. 16 von 92) an die Steuereinheit („Bluetooth Controller“) gesendet wird (vgl. Vol. 3, S. 406 von 814, Kap. 7.1.5, i. V. m. S. 377 von 814, Kap. 5.4.1, erster Satz / Merkmal M2). Da nur ein Hostprozessor beschrieben ist, wird der Aufbau einer Verbindung durch einen Ausgangspunkt in diesem Hostprozessor veranlasst. Zwar gibt der Datenwegeröffnungsbefehl („HCI_Create_Connection“) eine externe Kommunikationsadresse an. Wie die Klägerin zutreffend ausgeführt hat, wird in einem ersten Schritt das Eröffnen eines chipsatzinternen Kommunikationskanals zwischen der Software auf dem Hostprozessor und dem Bluetooth Controller auf der HCI Protokollebene veranlasst, die mit einer Statusmitteilung („HCI_Command_Status“) betätigt wird (vgl. Figur 3.2, Vol. 3, S. 632 von 814). Es erfolgt dabei keine Durchleitung von Daten an die im Datenwegeröffnungsbefehl angegebene externe Adresse. Aus dem an die Steuereinheit gerichteten Daten-wegeröffnungsbefehl ergibt sich implizit ein innerhalb des Bluetooth Controllers liegender Bestimmungspunkt in der HCI Firmware (vgl. Vol. 3, Fig. 1.2 i. V. m. Fig. 3.2, a. a. O.). Beim Aufbau des internen Kommunikationskanals mit dem vor-genannten Datenwegeröffnungsbefehl und der zugehörigen Statusmeldung (vgl. - 21 - Vol. 3, Figur 3.2, i. V. m. Vol. 3, Kap. 7.1.5, a. a. O.) erfolgt jedoch keine Nennung eines in der kontaktlosen Schnittstelle (also innerhalb der Sende-/ Empfangskom-ponenten des Bluetooth Controllers) selbst liegenden Bestimmungspunkts. Auch bei dem im Rahmen des als Datenwegeröffnungsbefehl identifizierten Befehls „HCI_Create_Connection“ in einem zweiten Schritt erfolgenden Aufbau der exter-nen Verbindung zu dem mit dem Parameter „BD_ADDR“ benannten Gerät („De-vice A pages Device B“; vgl. Vol. 3, Figur 3.2, a. a. O.), bei welchem die kontakt-lose Schnittstelle genutzt wird, ist kein Bestimmungspunkt in der Schnittstelle selbst benannt. Der Aufbau des internen Kommunikationskanals erfolgt somit ent-gegen den Ausführungen der Klägerin ohne Nennung eines Bestimmungspunkts in der kontaktlosen Schnittstelle (teilweise Merkmal M2.1). In Antwort auf das Empfangen des Datenwegeröffnungsbefehls („HCI_Create_Connection“) in der Steuereinheit („Bluetooth Controller“) wird ein Datenweg eröffnet, der den Ausgangspunkt im Hostprozessor („Host“) mit einem Bestimmungspunkt (im Bluetooth Controller) verbindet (vgl. Vol. 3, S. 406 von 814, erster Satz und S. 408 von 814, vorl. Abs., i. V. m. S. 376 von 814, Kap. 5.3, ers-ter und zweiter Satz / teilweise Merkmal M3, ohne Bestimmungspunkt in der kontaktlosen Schnittstelle). Beim Einrichten eines solchen Datenwegs wird diesem eine Routingkanalnummer zugewiesen („Connection Handle“, vgl. Vol. 3, S. 376 von 814, Kap. 5.3., erster und zweiter Satz i. V. m. Vol. 3, S. 408 von 814, vorl. Abs. / Merkmal M3.1), die den jeweiligen Datenweg kennzeichnet. Die Beziehung zwischen Routingkanalnummer und einer zugehörigen Routinginformation (d. h. Identifizierer von Ausgangs- und Bestimmungspunkt) muss zwangsläufig im Con-troller (der diesen Datenweg eröffnet hat) im Hinblick auf die chipsatzinterne Kommunikation auch gespeichert werden, da die Adressierung der Datenpakete auf der HCI Protokollebene zwischen Host und Bluetooth Controller ausschließlich unter Verwendung der Routingkanalnummer („Connection Handle“) erfolgt. Dies ist unter anderem im Aufbau des „HCI ACL Data Packets” ersichtlich (vgl. Vol. 3, Kap. 5.4.2 „HCI ACL Data Packets”, S. 379 von 814, i. V. m. Kap. 5.3., S. 376 von 814; ACL = Asynchronous connection-oriented), das als einzige Routinginforma-tion die Routingkanalnummer („Connection Handle“) zeigt. Darüber hinaus findet - 22 - keine weitergehende Auswertung des Inhalts solcher Datenpakete zum chipsatzinternen Routing statt, da der Inhalt der Datenpakete transparent für die Transportschicht im Host an die Steuereinheit (d. h. an den Bluetooth Controller) weitergegeben wird (vgl. Vol. 3, S. 345 von 814). Die Speicherung der erforderli-chen Routinginformation – d. h. das Anlegen einer Routingtabelle – in der Steuer-einheit liest der Fachmann daher aus der vorstehend beschriebenen Kommunika-tion zwischen Host und Controller mit (Merkmale M3.2 und M3.2a). Weiterhin ist Druckschrift D3 ein Senden eines Datenübertragungsblocks („HCI ACL Data Packet”) mittels des Ausgangspunkts („Host“) an die Steuereinheit („Bluetooth Controller“) zu entnehmen, wobei ein Header-Feld des Datenübertra-gungsblocks (Datenbereich vor den Nutzdaten „Data“) eine Routingkanalnummer („Connection Handle“) aufweist (vgl. Vol. 3, S. 379 von 814, Fig. 5.2 mit einleiten-der Beschreibung / Merkmale M4, M4.1). Das Senden des Datenübertragungs-blocks („HCI ACL Data Packet”) erfolgt vom Host an einen Bestimmungspunkt innerhalb des Controllers, ohne dass dabei ein Bestimmungspunkt in der kontakt-losen Datensende-/Empfangsschnittstelle („Radio Interface“) genannt ist („HCI ACL Data Packets are used to exchange data between the Host and Controller“; vgl. Vol. 3, S. 379, Kap. 5.4.2, erster Satz / teilweise Merkmal M5.2). Bei der kontaktlosen Datensende-/Empfangsschnittstelle in Druckschrift D3 han-delt es sich im Unterschied zum Streitpatent um keine Schnittstelle vom RFID-Typ, sondern um eine Bluetooth-Schnittstelle (vgl. Merkmal M1.3). Konkrete Angaben zum Aufbau und Inhalt einer zwangsläufig erforderlichen Routingtabelle sind der Entgegenhaltung nicht zu entnehmen (vgl. Merkmal M3.2b). Der Entgegenhaltung sind auch keine Angaben zu einer Ermittlung eines Bestimmungspunkts in der kontaktlosen Schnittstelle des Chipsatzes für einen Datenübertragungsblock ent-sprechend den Verfahrensschritten M5.1 und M5.1a oder zum Senden des Da-tenübertragungsblocks an einen solchen Bestimmungspunkt entnehmbar (vgl. Merkmal M5.2). - 23 - 1.3 Stand der Technik gemäß Druckschrift D15 Der Patentgegenstand nach dem angegriffenen Patentanspruch 1 ist – was auch die Klägerin so sieht, da sie diese Druckschrift nur zur Frage der erfinderischen Tätigkeit benannt hat – gegenüber dem Stand der Technik nach der Druckschrift D15 (WO 02/080452 A2) ebenfalls neu. Aus der Entgegenhaltung D15 ist ein Datenrouting-Verfahren in einem Chipsatz bekannt (vgl. Fig. 4 und Fig. 5 mit zugehöriger Beschreibung / Merkmal M1). Der Chipsatz umfasst wenigstens einen Hostprozessor (implizit aus der Ausführung einer „Application“ bzw. eines „Application Module“, vgl. Fig. 2, Fig. 4 / Merkmal M1.1), eine Steuereinheit („SIMAC module“ mit „Link Manager“; vgl. Fig. 4 i. V. m. Fig. 5 und S. 14, zweiter Abs. / Merkmal M1.2) und eine kontaktlose Datensende-/Empfangsschnittstelle („Network Interface“, bspw. UMTS, GPRS, WLAN, Blue-tooth; vgl. S. 30, Zn. 14-15 und Fig. 3 / teilweise Merkmal M1.3; keine Schnitt-stelle vom RFID-Typ). Der Fachmann liest weiter im Rahmen des „Service Request“ (Fig. 22 mit Be-schreibung, S. 32, vorl. Abs.) einen Datenwegeröffnungsbefehl mit, der Voraus-setzung für das Übertragen eines Datenstroms („data flow“) ist. Der „Service Re-- 24 - quest“ geht von einem (Anwendungs-)Programm im Hostprozessor aus und ist an die Steuereinheit („Link Manager“ im „SIMAC module“) gerichtet, ohne dass der Ausgangspunkt im Hostprozessor dabei angegeben wird (teilweise Merkmal M2) und ohne dass dabei ein Bestimmungspunkt in einer kontaktlosen Datensende-/ Empfangsschnittstelle des Chipsatzes benannt wird (vgl. Merkmale M2.1). In Ant-wort auf den Datenwegeröffnungsbefehl wird ein Datenweg eröffnet (Fig. 22 / teilweise Merkmal M3, ohne Bestimmungspunkt in der kontaktlosen Datensende-/Empfangsschnittstelle). Hierbei können mehrere Tabellen mit Routinginformatio-nen – also eine „Routingtabelle“ – aktualisiert werden (vgl. Fig. 22 i. V. m. Fig. 11 und 12; S. 29, zweiter und dritter Abs.), jedoch ohne Eintrag von Identifizierern eines Ausgangspunktes und eines Bestimmungspunktes in der Schnittstelle und ohne dass angegeben ist, durch wen im Sinne von Merkmal M3.2 eine Routingka-nalnummer („Packet Flow ID“) vergeben wird (Merkmal M3.2, M3.2a; teilweise Merkmale M3.1, M3.2b). Beim Senden eines Datenübertragungsblocks werden mittels des Ausgangs-punktes Daten an die Steuereinheit übersendet, ohne dass dabei die Angabe ei-nes Bestimmungspunkts in der kontaktlosen Schnittstelle erfolgt (Fig. 13 / Merk-mal M4.1, teilweise Merkmal M4), wobei beim Empfang des Datenübertragungs-blockes mittels der Steuereinheit ein Transportkanal für die Daten in der Routing-tabelle gesucht wird (S. 29, Z. 20 – S. 30, Z. 5; S. 30, Zn. 15-17) und die Daten über die dem Transportkanal zugeordnete Schnittstelle ohne explizite Nennung von Bestimmungspunkten in der jeweiligen Schnittstelle gesendet werden (Merk-male M5, M5.1a, teilweise Merkmale M5.1 und M5.2). Bei der kontaktlosen Datensende-/Empfangsschnittstelle in Druckschrift D15 han-delt es sich im Unterschied zum Streitpatent um keine Schnittstelle vom RFID-Typ (vgl. Merkmal M1.3), sondern um UMTS-, GPRS-, WLAN- bzw. Bluetooth-Schnitt-stellen. Ein Benennen eines internen Bestimmungspunktes in der jeweiligen kon-taktlosen Datensende-/ Empfangsschnittstelle beim Eröffnen eines Datenwegs im Sinne des Anspruchsmerkmals M2.1 wurde von der Klägerin weder aufgezeigt, noch ist in dem als Datenwegeröffnungsbefehl zu identifizierenden „Service Requ-- 25 - est“ (einschließlich „Create Socket“-Befehl, vgl. Fig. 22) die Benennung eines sol-chen Bestimmungspunkts ersichtlich. Der Entgegenhaltung sind zudem keine An-gaben zum Vorsehen eines solchen internen Bestimmungspunktes in der jeweili-gen kontaktlosen Datensende-/Empfangsschnittstelle beim Erzeugen einer Rou-tingtabelle für den Datenweg und beim internen Routing eines zu versendenden Datenübertragungsblocks zu entnehmen (vgl. Merkmale M3 und M3.2b, M4, M5.1 sowie M5.2). 1.4 Weiterer im Verfahren befindlicher Stand der Technik Die übrigen von der Klägerin genannten Druckschriften – die sie teilweise auch nur zum Beleg fachmännischen Wissens zu einzelnen Merkmalen eingeführt hat – liegen weiter ab als die vorgenannten Druckschriften und können die Neuheit des angegriffenen Gegenstands des Patentanspruchs 1 nicht in Frage stellen. Solches hat die Klägerin auch nicht geltend gemacht. Aus dem vorliegenden Stand der Technik ist damit kein Verfahren bekannt, das sämtliche Merkmale des Anspruchs 1 aufweist. 2. Zur erfinderischen Tätigkeit des Gegenstands des Anspruchs 1 2.1 Erfinderische Tätigkeit bezüglich der Druckschriften D1 und D2 Auch wenn die Klägerin dies nicht ausdrücklich geltend gemacht hat, ist im Rah-men der gebotenen Amtsermittlung (§ 87 PatG) zu prüfen, ob die Druckschriften D1 und D2 dem Fachmann den Anspruch 1 des Streitpatents auch unter Einbe-ziehung seines Fachwissens nahe legen. Dies ist indessen nicht der Fall. In der Entgegenhaltung D1 findet sich kein Hinweis auf ein Ermitteln eines Be-stimmungspunkts in der Datensende-/Empfangsschnittstelle („RF-Antenna 33c“ mit „Modulator/ Demodulator 33b“) durch die Steuereinheit („smart card router 33“), welches lediglich anhand einer Routingkanalnummer erfolgt (vgl. Streitpa-tent, Merkmalsgruppen M3.2 und M5.1). Vielmehr wird der Bestimmungspunkt der Daten in der dortigen Steuereinheit („smart card router 33“) ganz allgemein aus - 26 - dem Header des Datenübertragungsblocks („APDU“) bestimmt (vgl. S. 13, Zn. 10-13, sowie S. 16, zweiter Abs.). Hieraus lässt sich keine Notwendigkeit für das An-legen und Verwenden einer anspruchsgemäßen Routingtabelle in der Steuerein-heit ableiten, da nach der Lehre der Druckschrift D1 zum Routing durch die Steu-ereinheit („smart card router 33“) jegliche geeignete Adressierung im Header der Datenübertragungsblöcke umfasst ist und bei nur einem Host und einer kontaktlo-sen Schnittstelle keine Veranlassung besteht, diese nicht direkt, sondern nur unter Verwendung einer Kanalnummer zu adressieren. Die Zuordnung von Daten zu einzelnen Anwendungen (als deren Ausgangs- bzw. Bestimmungspunkt) mittels einer Zuordnungstabelle anhand von Kanalnummern („logical channel identifier“) ist dagegen ausschließlich für den Hostprozessor selbst („card“) vorgesehen (vgl. S. 15, erster Abs., dritter Satz). Das Einrichten von Datenwegen („logical channel“) durch die Steuereinheit aus-gehend von Nutzereingaben (vgl. S. 15, erster Abs., vorletzter Satz) betrifft schließlich nicht die chipsatzinterne Kommunikation zwischen Hostprozessor und kontaktloser Schnittstelle, sondern zwischen Nutzerschnittstelle und einem An-wendungsprogramm des Hostprozessors. Unabhängig davon sind auch hierzu keine näheren Angaben zum Routing – d. h. insbesondere nicht zu einer Verwen-dung von Kanalnummern – gemacht, die einen Hinweis auf die Gestaltung und Verwendung einer Routingtabelle in der Steuereinheit im Sinne der Merkmals-gruppen M3.2 und M5.1 gemäß Anspruch 1 geben würden. Für den Fachmann besteht daher bei einem aus Druckschrift D1 bekannten Ver-fahren keine Veranlassung, die Erzeugung und Verwendung einer Routing-Tabelle in der Steuereinheit für die chipsatzinterne Kommunikation zwischen Hostprozes-sor und kontaktloser Schnittstelle vorzusehen. Der Entgegenhaltung D2 (vgl. jeweils deutsche Übersetzung D2-DE) ist keine Er-zeugung und Verwendung einer Routingtabelle im Sinne des Anspruchs 1 des Streitpatents zu entnehmen (vgl. Merkmale M3.2a, M3.2b und Merkmal M5 i. V. m. - 27 - Merkmalen M5.1 und M5.1a). Selbst wenn man für die in der Entgegenhaltung beschriebene Kommunikation mit externen Datenträgern das Vorhandensein ei-nes Bestimmungspunkts in der kontaktlosen Schnittstelle voraussetzt, fehlt es auch in Druckschrift D2 an der Veranlassung für den Fachmann, eine Routingta-belle zur chipsatzinternen Kommunikation in der Steuereinheit des Lese-Schreib-Geräts vorzusehen. Denn der Entgegenhaltung D2 ist innerhalb des Chipsatzes nur die Kommunikation zwischen einem Hostprozessor („Host-Gerät“) und einer Steuereinheit („Lese-Schreib-Gerät“) zu entnehmen, bei der nicht zwischen ver-schiedenen (internen) Empfängern unterschieden wird. Selbst in Bezug auf ex-terne Ziele enthält der Befehl des Host-Geräts an das Lese-Schreib-Gerät zudem neben einer „Knotenadresse“ auch die „eindeutigen Daten“ des Adressaten (vgl. Abs. [0040]), also die Adresse des (externen) Empfängers des jeweiligen Befehls. Damit enthält der Header des entsprechenden Datenübertragungsblocks jedoch immer die explizite Angabe des Bestimmungsorts, so dass auch hieraus keine Notwendigkeit der Verwendung einer Routingtabelle, insbesondere für ein chipsatzinternes Routing abgeleitet werden kann. Auch eine Zusammenschau der Druckschriften D1 und D2 oder der Druckschriften D1 und D2 mit dem weiteren Stand der Technik führt zu keinem anderen Ergeb-nis, da keiner der beiden Druckschriften Anregungen zur Verwendung einer Rou-tingtabelle zur chipsatzinternen Kommunikation im Sinne des Anspruchs 1 des Streitpatents zu entnehmen sind. 2.2 Erfinderische Tätigkeit bezüglich der Druckschrift D3 Entgegen der Auffassung der Klägerin ist der Patentgegenstand nach dem ange-griffenen Patentanspruch 1 dem Fachmann auch nicht durch die Druckschrift D3 (vgl. jeweils Druckschrift D3a, vollständige Bluetooth Spezifikation, Version 2.0), insbesondere nicht hinsichtlich der Merkmale M3.2b und M5.1/M5.1a nahegelegt. Denn die Druckschrift D3 gibt weder allein noch in Kombinationen mit dem übrigen im Verfahren befindlichen Stand der Technik dem Fachmann eine Anregung, das beschriebene Verfahren bzw. die beschriebene Datensende-/Empfangsvorrich-tung mit solchen Merkmalen zu ergänzen. - 28 - Der Entgegenhaltung D3 ist im Unterschied zum Streitpatent keine kontaktlose Daten-/Empfangsschnittstelle vom „RFID-Typ“, sondern Bluetooth als kontaktlose Schnittstelle zu entnehmen (vgl. Anspruch 1, Merkmal M1.3). Wie die Klägerin zutreffend dargelegt hat, ist die Art der externen Kommunikationsschnittstelle für die Beurteilung der anspruchsgemäßen Kommunikation innerhalb des Chipsatzes jedoch unerheblich, da die interne Kommunikation nicht durch die Art der externen Schnittstelle oder die Kommunikation zu externen Geräten bestimmt wird. Zwar ergibt sich – wie in Abschnitt 1.2 der Neuheitsbetrachtung hinsichtlich der Entgegenhaltung D3 dargelegt – aus der alleinigen Verwendung der Routingka-nalnummer („Channel Handle“) im Rahmen der chipsatzinternen Kommunikation zwischen Hostprozessor und Steuereinheit („Bluetooth Controller“) auf der HCI-Protokollebene für den Fachmann implizit die Notwendigkeit zum Vorhalten von geeigneten Informationen (bspw. als Routingtabelle) in der Steuereinheit, um eine Zuordnung von Befehlen und Datenpaketen zu den Datenwegen zu ermöglichen, die zu externen Bestimmungspunkten eingerichtet sind. Hieraus folgt jedoch keine Veranlassung, eine Routingtabelle mit anspruchsgemäßem Inhalt und anspruchs-gemäßer Verwendung vorzusehen. Die Klägerin sieht im Befehl zum Eröffnen einer synchronen Verbindung (Befehl „HCI_Setup_Synchronous_Connection“, vgl. Vol. 3, S. 437 von 814, Kap. 7.1.26) zusätzlich zum Befehl „HCI_Create_Connection“ (für das Einrichten von asyn-chronen Verbindungen) einen weiteren Befehl zum Eröffnen eines Datenwegs, aus dem das Vorhandensein von zumindest einem zweiten internen Ausgangs-punkt im Hostprozessor im Sinne des Merkmals M2 abgeleitet werden könne. Diese Betrachtung greift aber zu kurz, da es sich hierbei nicht um einen Datenwe-geröffnungsbefehl im Sinne der Merkmale M2 und M2.1 in Verbindung mit den Merkmalen M3 und M3.1 handelt. Denn die synchrone Verbindung setzt nicht nur, wie die Beklagte ausführt, eine bereits eingerichtete asynchrone Verbindung vo-raus, sondern das Einrichten dieser Verbindung erfolgt zudem unter Verwendung der Routingkanalnummer („Connection_Handle“) der zugrunde liegenden asyn-chronen Verbindung. Daher wird beim Eröffnen einer synchronen Verbindung kein - 29 - neuer Routingkanal im Sinne des Streitpatents erzeugt und dieser Verbindung auch keine neue Routingkanalnummer durch die Steuereinheit zugewiesen (vgl. Vol. 3, S. 437 von 814, erster Abs. und zweiter Abs., erster Satz). Es erfolgt viel-mehr nur die Einrichtung einer synchronen Verbindung auf einem bestehenden Kanal. Damit stellt auch der Ausgangspunkt der Anforderung der synchronen Ver-bindung keinen zusätzlichen Ausgangspunkt im Sinne des Datenwegeröffnungs-befehls gemäß Merkmal M2 und dem Routingtabelleneintrag gemäß Merkmal M3.2b dar, der in der Steuereinheit („Bluetooth Controller“) unterschieden werden muss. Sofern der Ausgangspunkt des Datenwegs im Hostprozessor eine Zuordnung zu einem bestimmten Anwendungsprogramm erfordert, folgt aus deren Unterschei-dung ebenfalls kein Hinweis darauf, für diesen Ausgangspunkt einen Eintrag in einer Routingtabelle durch die Steuereinheit der Datensende-/ Empfangsvorrich-tung und nicht im Host selbst zu erzeugen. Denn der Aufruf eines Datenwegeröf-fungsbefehls „HCI_Create_Connection“ für eine asynchrone Verbindung (oder ggf. auch „HCI_Setup_Synchronous_Connection“ für eine synchrone Verbindung) er-folgt innerhalb des Hosts durch Aufruf des HCI Treibers („HCI Driver“, vgl. bei-spielsweise Fig. 1.2, Vol. 3, S. 344 von 814). Dem jeweiligen Befehl ist kein Aus-gangspunkt zu entnehmen, der im Rahmen des Treiber-Aufrufs an die Steuerein-heit übermittelt wird und den diese in der Routingtabelle ablegen könnte. Für eine Unterscheidung zwischen hostinternen Ausgangspunkten von Verbindungen durch die Steuereinheit (d. h. im Bluetooth Controller) findet sich daher in Bezug auf einen Datenwegeröffnungsbefehl kein Hinweis. Darüber hinaus sieht die Bluetooth Spezifikation auch keine Mehrzahl an Hostpro-zessoren innerhalb des Chipsatzes und kein Routing zwischen solchen Hostpro-zessoren und Schnittstellen vor, die eine Unterscheidung verschiedener Aus-gangspunkte von Datenwegen in einer Routingtabelle der Steuereinheit erforder-lich machen. Aus der Entgegenhaltung D3 ergibt sich daher kein Anhaltspunkt dafür, dass Ausgangspunkte im Hostprozessor in einer Routingtabelle von der Steuereinheit – also vom Bluetooth Controller – verwaltet werden müssen. - 30 - Fig. 2.1 Ebenso findet sich in der Druckschrift D3 kein Hinweis auf das Benennen eines internen Bestimmungspunkts innerhalb der kontaktlosen Datensende-/Empfangs-schnittstelle („Radio Interface“), aus dem sich für den Fachmann eine notwendige Zuordnung dieser Bestimmungspunkte zur Routingkanalnummer („Channel Handle“) zum internen Routing der Datenpakete ablesen ließe. Die Klägerin ver-weist hierzu darauf, dass der Datenwegeröffnungsbefehl an den „Bluetooth Con-troller“ – mithin die Steuereinheit – gerichtet ist und ein Bestimmungspunkt in der Schnittstelle implizit beim Senden von Daten über diese Schnittstelle vorhanden sein muss. Hieraus ergibt sich aber noch kein Benennen eines solchen Bestim-mungspunktes oder das Erfordernis, diesen in einer Routingtabelle zur chipsatzinternen Kommunikation einzutragen. Die Datenwege gemäß Druckschrift D3 werden mit Bezugnahme auf eine externe Adresse eröffnet (vgl. Parameter „BD_ADDR“ für das Einrichten eines asynchro-nen Kanals mittels des Befehls „HCI_Create_Connection“, vgl. Vol. 3, S. 406 von 814). Auf diesen Datenwegen setzt, wie oben erläutert, auch eine synchrone Ver-- 31 - bindung auf. Der Datenwegeröffnungsbefehl, also die jeweiligen HCI-Steuerbe-fehle zur Einrichtung des Kanals bzw. der darauf aufbauenden synchronen Ver-bindung, sind dabei alle an den Link-Manager in der Steuereinheit gerichtet (vgl. „control“-Daten als „C-plane and control services“, Vol. 1, Fig. 2.1, S. 21 von 92,), ohne dass hierzu erkennbar durch die aufrufende Anwendungssoftware im Host-prozessor zwischen internen Bestimmungspunkten in der kontaktlosen Schnitt-stelle selbst unterschieden wird oder der jeweilige Befehl einen entsprechenden Punkt benennt. Daher ergibt sich aus dem Eröffnen von Datenwegen gemäß Druckschrift D3 für den Fachmann auch keine Veranlassung, eine anspruchsge-mäße Zuordnung von Routingkanalnummern zu Identifizierern von Bestimmungs-punkten in der kontaktlosen Schnittstelle durch die Steuereinheit vorzusehen. Eine Ausgestaltung der Routingtabelle gemäß Merkmal M3.2b des Streitpatents, also ein Zuordnen der Identifizierer eines Ausgangspunkts im Hostprozessor („Host“) und eines Bestimmungspunkts in der kontaktlosen Schnittstelle („Radio Interface“) zu einer Routingkanalnummer („Channel Handle“) ist daher der Entge-genhaltung D3 weder zu entnehmen, noch ist sie dem Fachmann daraus nahe-gelegt. Hieraus folgt, dass sich auch eine Verwendung der Routingtabelle gemäß der Merkmale M5.1 und M5.1a des Streitpatents nicht aus Druckschrift D3 ergibt. Denn HCI Datenpakete, die der internen Kommunikation zwischen Host und Con-troller dienen, unterscheiden nicht zwischen Bestimmungspunkten in der kontakt-losen Datensende-/ Empfangsschnittstelle (d. h. in der Radio-Schnittstelle gemäß D3), auch wenn sie allein mittels der Routingkanalnummer im Header-Feld des Datenpakets gemäß den Merkmalen M4 und M4.1 einem Datenweg zugeordnet sind. Datenpakete, die dagegen an externe Empfänger gerichtet sind, bedürften allenfalls der Zuordnung der externen Empfängeradresse, die beim Einrichten des jeweiligen Kanals anhand der externen Adresse „BD_ADDR“ als Parameter des Befehls „HCI_Create_Connection“ verwendet wurde. Eine gezielte Adressierung eines internen Bestimmungspunkts in der kontaktlosen Datensende-/ Empfangs-schnittstelle (d. h. im „Radio Interface“) unter Verwendung der Routingkanalnum-- 32 - mer und eine entsprechende Weiterleitung durch die Steuereinheit („Bluetooth Controller“) ist der Entgegenhaltung D3 nicht zu entnehmen. Ausgehend von der Bluetooth Spezifikation (Druckschrift D3) fehlt es daher an einer Veranlassung für den Fachmann, in Abwandlung der dieser entnehmbaren Lehre eine Routingtabelle entsprechend der Merkmalsgruppe M3.2 gemäß An-spruch 1 des Streitpatents vorzusehen, die neben der Routingkanalnummer den Identifizierer eines im Hostprozessor lokalisierten Ausgangspunkts und den Identi-fizierer eines Bestimmungspunktes in der kontaktlosen Datensende-/ Empfangs-schnittstelle enthält, und diese Routingtabelle zum internen Zuleiten von Datenpa-keten vom Hostprozessor zur kontaktlosen Datensende-/ Empfangsschnittstelle gemäß der Merkmale M5.1 und M5.1a zu verwenden. Eine solche Veranlassung ergibt sich auch nicht in Kombination mit dem weiteren im Verfahren befindlichen Stand der Technik, da ausgehend von der Lehre der Druckschrift D3 keine Notwendigkeit der Unterscheidung von Bestimmungspunk-ten gemäß des anspruchsgemäßen chipsatzinternen Routingverfahrens durch die Steuereinheit besteht. Die Druckschriften D4, MN12 und MN13 wurden von der Klägerin zum Beleg der technischen und funktionalen Nähe der Bluetooth- und RFID-Technologie angeführt und befassen sich nicht mit der technischen Realisie-rung von Kommunikationsverfahren unter Verwendung von Routingtabellen. Allein aus der Kenntnis von Routingverfahren auf Basis von Routingtabellen, zu der die Klägerin die Druckschriften D7, D12, D14 und D15 anführt, folgen ebenfalls keine zusätzlichen Hinweise für den Fachmann, diese entsprechend dem Streitpatent zur chipsatzinternen Kommunikation einzusetzen. 2.3 Erfinderische Tätigkeit bezüglich der Druckschrift D15 Auch unter Berücksichtigung des Standes der Technik gemäß Druckschrift D15 (WO 02/080452 A2) ist der Gegenstand des Patentanspruchs 1 entgegen der Auffassung der Klägerin dem Fachmann nicht nahegelegt – auch nicht in Kombi-nationen mit dem übrigen im Verfahren befindlichen Stand der Technik. - 33 - Der Entgegenhaltung D15 ist keine kontaktlose Daten-/Empfangsschnittstelle vom RFID-Typ, sondern nur UMTS, GPRS, WLAN und Bluetooth als kontaktlose Schnittstellen zu entnehmen (vgl. S. 36, le. Zeile und Fig. 3). Wie die Klägerin zu-treffend dargelegt hat, ist die Art der externen Kommunikationsschnittstelle für die Beurteilung der anspruchsgemäßen Kommunikation innerhalb des Chipsatzes unerheblich. Das Benennen eines in der kontaktlosen Daten-/Empfangsschnittstelle lokalisier-ten Bestimmungspunkts im Datenwegeröffnungsbefehl ist jedoch Druckschrift D15 ebenfalls nicht zu entnehmen (vgl. Merkmale M2, M2.1). Denn die Entgegenhal-tung strebt an, dass die jeweils zur externen Kommunikation verwendete Schnitt-stelle für die Anwendungen auf dem Hostprozessor transparent ist und die Zuord-nung der Schnittstelle für einen Datenstrom („packet flow“) durch eine Steuerein-heit („SIMAC Module“ mit „Link Manager“) bei Bedarf unabhängig von der Anwen-dungssoftware geändert werden kann (vgl. S. 15, Z. 15 bis S. 16, Z. 5). Dies wi-derspricht bereits dem Benennen eines Bestimmungspunkts in einer bestimmten Schnittstelle in einem Datenwegeröffnungsbefehl (vgl. Merkmal M2.1 i. V. m. Merkmal M2) oder beim Senden von Daten (vgl. Merkmal M4). Gemäß Druck-schrift D15 erfolgt aufgrund der vorstehend beschriebenen Zielsetzung das Zuord-nen einer geeigneten Schnittstelle (bzw. eines „transport channel“ bzw. „bearer“) für zu sendende Daten durch die Steuereinheit nicht aufgrund einer vorherigen Festlegung unter Verwendung der Routingkanalnummer, sondern abhängig von den für einen Datenstrom („packet flow“) angegebenen Parametern („first connec-tion information associated with one of the packet flows“) und den Eigenschaften der Schnittstelle („second connection information associated with a first network link interface“) (vgl. D15, Anspruch 39). Denn ein „Datenwegeröffnungsbefehl“, welchen die Klägerin im „Service Request“ nach Figur 22 sieht, gibt ausschließ-lich die gewünschten Eigenschaften („first connection information“) einer Verbin-dung für das Senden der Datenpakete des Datenstroms („packet flow“) an und benennt weder explizit den Ausgangspunkt im Hostprozessor noch den Bestim-mungspunkt in einer der kontaktlosen Schnittstellen. Selbst wenn man nur den einleitenden „Create Socket“-Befehl des Verfahrensablaufs gemäß Figur 22 als - 34 - Datenwegeröffnungsbefehl ansieht, fehlt diesem die Festlegung des „Identifizie-rers des Datenstroms“ („packet flow ID“), den die Klägerin als Routingkanalnum-mer beim Versenden von Datenpakete eines Datenstroms identifiziert haben will. Ein Ableiten der Eröffnung eines internen Datenwegs im Sinne des anspruchsge-mäßen Datenwegeröffnungsbefehls und ein Anlegen einer Routingtabelle auf Ba-sis der Angaben im Datenwegeröffnungsbefehl (vgl. Streitpatent, Merkmale M2, M2.1 i. V. m. Merkmal M3.1 und der Merkmalsgruppe M3.2) folgt für den Fach-mann daher nicht naheliegend aus dieser Entgegenhaltung. Aus der Handhabung der Datenpakete eines Datenstroms gemäß Druckschrift D15 ist dem Fachmann auch ein Suchen eines Bestimmungspunkts in der kon-taktlosen Schnittstelle anhand der Routingkanalnummer („packet flow ID“) als In-dex entsprechend der Merkmale M5.1 und M5.1a nicht nahegelegt (vgl. S. 29, Z. 20 – S. 30, Z. 5; i. V. m. S. 29, Zn. 8-12 i. V. m. Fig. 10-12 und Fig. 19). Auch allein aus der Kenntnis von Routingverfahren auf Basis von Routingtabellen, d. h. in der Kombination von Druckschrift D15 mit den weiteren, von der Klägerin hierzu angeführten Druckschriften D7, D12, und D14, ergibt sich keine Veranlas-sung für den Fachmann, die Lehre der Druckschrift D15 im Sinne des im Streit-patent vorgesehenen internen Routingverfahrens zu modifizieren. Auch eine Zu-sammenschau der Druckschrift D15 mit den weiteren im Verfahren befindlichen Druckschriften, die insbesondere die Nähe verschiedener Kommunikationstech-nologien belegen sollen, gibt dem Fachmann aufgrund fehlender Hinweise auf eine anspruchsgemäße Erzeugung und Verwendung von Routingtabellen bei der chipsatzinternen Kommunikation keinen Anlass, das aus Druckschrift D15 be-kannte Datenrouting-Verfahren im Sinne des Anspruchs 1 des Streitpatents zu modifizieren. Der Gegenstand des Patentanspruchs 1 ist damit dem Fachmann aus dem vorlie-genden Stand der Technik nicht nahegelegt. - 35 - 3. Zur fehlenden Patentfähigkeit des Anspruchs 12 Der Patentgegenstand nach dem angegriffenen Patentanspruch 12 ist gegenüber dem im Verfahren befindlichen Stand der Technik ebenfalls neu und beruht ge-genüber dem im Verfahren befindlichen Stand der Technik auf einer erfinderi-schen Tätigkeit. Für die funktionalen Merkmale der Komponenten der Datensende- und Emp-fangsvorrichtung gemäß des angegriffenen Anspruchs 12 gelten sinngemäß die vorstehenden Ausführungen zu Anspruch 1 in gleicher Weise, da diese funktiona-len Merkmale inhaltlich den Verfahrensmerkmalen des Anspruchs 1 entsprechen. Insbesondere die Merkmale N2.1c2, N2.2a und N2.2b gemäß Anspruch 12 finden sich daher entsprechend den korrespondierenden Merkmalen M3.2b, M5.1 und M5.1a gemäß Anspruch 1 weder in dem im Verfahren befindlichen Stand der Technik, noch sind diese dem Fachmann durch den im Verfahren befindlichen Stand der Technik nahegelegt. III. Da die angegriffenen Patentansprüche sich bereits in der erteilten Fassung als schutzfähig erweisen, ist die Nichtigkeitsklage schon aus diesem Grund abzuwei-sen, ohne dass es noch weiterer Ausführungen hinsichtlich der beiden Hilfsan-träge der Beklagten bedarf. B. Die Kostenentscheidung beruht auf § 84 Abs. 2 PatG i. V. m. § 91 Abs. 1 ZPO, die Entscheidung über die vorläufige Vollstreckbarkeit auf § 99 Abs. 1 PatG i. V. m. § 709 ZPO. - 36 - C. R e c h t s m i t t e l b e l e h r u n g Gegen dieses Urteil ist das Rechtsmittel der Berufung gegeben. Die Berufungsschrift, die auch als elektronisches Dokument nach Maßgabe der Verordnung über den elektronischen Rechtsverkehr beim Bundesgerichtshof und Bundespatentgericht (BGH/BPatGERVV) vom 24. August 2007 (BGBl. I S. 2130) eingereicht werden kann, muss von einer in der Bundesrepublik Deutschland zu-gelassenen Rechtsanwältin oder Patentanwältin oder von einem in der Bundes-republik Deutschland zugelassenen Rechtsanwalt oder Patentanwalt unter-zeichnet oder im Fall der elektronischen Einreichung mit einer qualifizierten elekt-ronischen Signatur nach dem Signaturgesetz oder mit einer fortgeschrittenen elektronischen Signatur versehen sein, die von einer internationalen Organisation auf dem Gebiet des gewerblichen Rechtsschutzes herausgegeben wird und sich zur Bearbeitung durch das jeweilige Gericht eignet. Die Berufungsschrift muss die Bezeichnung des Urteils, gegen das die Berufung gerichtet wird, sowie die Erklä-rung enthalten, dass gegen dieses Urteil Berufung eingelegt werde. Mit der Beru-fungsschrift soll eine Ausfertigung oder beglaubigte Abschrift des angefochtenen Urteils vorgelegt werden. Die Berufungsschrift muss innerhalb eines Monats schriftlich beim Bundesge-richtshof, Herrenstraße 45a, 76133 Karlsruhe eingereicht oder als elektronisches Dokument in die elektronische Poststelle des Bundesgerichtshofes (www.bundesgerichtshof.de/erv.html) übertragen werden. Die Berufungsfrist be-ginnt mit der Zustellung des in vollständiger Form abgefassten Urteils, spätestens aber mit dem Ablauf von fünf Monaten nach der Verkündung. Die Frist ist nur gewahrt, wenn die Berufung vor Fristablauf beim Bundesgerichtshof eingeht. Friehe Schwarz Dr. Schwengelbeck Dr. Otten-Dünnweber Altvater prö

Full & Egal Universal Law Academy