BPatG 13.01.2016 - 6 Ni 72/14 (EP)

Die Beklagte ist eingetragene Inhaberin des auch mit Wirkung für das Hoheitsgebiet 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 Verfahrenssprache Französisch veröffentlicht und wird beim Deutschen Patent- und Markenamt 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.

Die angegriffenen Patentansprüche 1 und 12 in der erteilten Fassung lauten in der Verfahrenssprache wie folgt:

Abbildung in Originalgröße in neuem Fenster öffnen

Abbildung in Originalgröße in neuem Fenster öffnen

In der deutschen Übersetzung laut Streitpatentschrift lauten sie wie folgt:

Abbildung in Originalgröße in neuem Fenster öffnen

Abbildung in Originalgröße in neuem Fenster öffnen

Abbildung in Originalgröße in neuem Fenster öffnen

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

D2-EN JP 2000-182007 A

deutsche Übersetzung der D2 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 Requirements”, 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 Version 2.0 + EDR, Specification Volume 0-3, 4 November 2004 (vollstä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 4^th Annual IEEE Conf. on Pervasive Computing and Communications, 13.-17.3.2006

oder

MN13 HALL, E.S. et al, RF Rendez Blue: Reducing Power and Inquiry Costs in Bluetooth-Enabled Mobile Systems. 11^th 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.

Die Beklagte beantragt,

die Klage abzuweisen,

hilfsweise, die Klage teilweise in Bezug auf Patentanspruch 1 abzuweisen,

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 Gegenstä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 angegriffenen Patentansprüche 1 und 12 von der erteilten Fassung lediglich hinsichtlich der einleitenden Worte der angegriffenen Patentansprüche, die in Patentanspruch 1 (Abweichungen von der erteilten Fassung unterstrichen) „Datenrouting-Verfahren in einem NFC-Chipsatz, umfassend wenigstens […]“ und in Patentanspruch 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. November 2015

berufen.

Der Senat hat den Parteien einen qualifizierten Hinweis vom 5. Oktober 2015 zugeleitet. Auf den Hinweis wird Bezug genommen.

Zu weiteren Einzelheiten wird auf die Akte verwiesen.

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 angegriffenen 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 Nichtigerklärung gerichtete Klage abzuweisen ist.

I. Zum Gegenstand des Streitpatents

1. Die Erfindung betrifft ein Datenrouting-Verfahren in einem Chipsatz, umfassend wenigstens einen Hostprozessor und eine kontaktlose Datensende-/ Empfangsschnittstelle vom RFID Typ (Anspruch 1), sowie eine Datensende-/ Empfangsvorrichtung, umfassend eine kontaktlose Datensende-/ Empfangsschnittstelle vom RFID Typ, eine Steuereinheit und wenigstens einen Eingangs-/ Ausgangsport, um wenigstens eine Datensende-/Empfangsschnittstelle mit einem Hostprozessor zu verbinden (Anspruch 12). Das Streitpatent zeige, so dessen Beschreibungseinleitung, insbesondere die Umsetzung solcher Schaltkreise für einen NFC-(Near Field Communication) Chipsatz (vgl. Streitpatent, Abs. [0001] bis [0003]).

Das Streitpatent geht davon aus, dass die NFC-Technologie auf der RFID-Technologie (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 Transponders. Der Leser sende kein Magnetfeld aus, sondern empfange Daten durch Demodulation 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.

Abbildung in Originalgröße in neuem Fenster öffnen

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 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 Verwaltung von kontaktlosen Anwendungen ermöglichten. Folglich erfordere die Realisierung eines solchen NFC-Chipsatzes das Vorsehen eines Routings von Datenflü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-/ Empfangsschnittstelle (CLINT), die von den mehreren Prozessoren verwendet werden könne, entsprechend eingestellt werden. Dies bedeute, dass der Prozessor für jede zu sendende Datenkette die von der Schnittstelle für die Übertragung dieser Daten zu verwendende Konfiguration aus Betriebsmodus und Kommunikationsprotokoll angeben müsse. Um das Routing der ausgehenden Daten und gleichzeitig die Konfiguration der Schnittstelle des NFC-Lesers zu ermöglichen, sei ein HCI („Host Controller Interface“) 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-Protokoll sehe Datenübertragungsblöcke vor, die jeweils Header-Felder (mit Informationen 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 Verarbeitungsaufwand erfordere. Ein anderes Problem betreffe das Routing der eingehenden Daten, 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, 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 festgestellt werden könne, welcher der Empfänger der über einen kontaktlosen Datenübertragungskanal empfangenen Daten sei, ohne den Inhalt dieser Daten analysieren 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-/ Empfangsvorrichtung mit den Merkmalen des erteilten nebengeordneten Patentanspruchs 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 Hostprozessor lokalisierten Ausgangspunktes (P1, P2) an die Steuereinheit (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 Ausgangspunkt 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 Ausgangspunktes und einen Identifizierer (IDdp) des Bestimmungspunktes umfassende Routingparameter

M4 - für den Bestimmungspunkt bestimmte, in einem Datenübertragungsblock (DF) verkapselte Daten mittels des Ausgangspunktes an die Steuereinheit (NFCC) zu senden

M4.1 [wobei der Datenübertragungsblock] ein die Routingkanalnummer umfassendes Header-Feld aufweist, und

M5 - beim Empfang der in einem Datenübertragungsblock (DF), der ein die Routingkanalnummer umfassendes Header-Feld aufweist, verkapselten 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 Bestimmungspunkt zu senden.

Anspruch 12

N1 Datensende-/Empfangsvorrichtung (NFCR2) umfassend

N1.1 eine kontaktlose Datensende-/Empfangsschnittstelle (CLINT) vom RFID-Typ,

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 Bestimmungspunkt 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-/ Empfangsschnittstelle (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, verkapselten 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 Auffassung der Klägerin, der die Beklagte insoweit nicht widersprochen hat – einen Diplom-Ingenieur der Fachrichtung Elektrotechnik oder Informationstechnik mit Spezialisierung auf dem Gebiet der Nahfeldkommunikation, insbesondere basierend auf RFID-, Infrarot-, WLAN- oder Bluetooth-Technologie, und mehrjähriger praktischer 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 Anspruchsfassung 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 „indem“ 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 Datensende-/ Empfangsschnittstelle vom RFID Typ (Anspruch 1), sowie eine Datensende- bzw. Empfangsvorrichtung, die eine kontaktlose Datensende-/ Empfangsschnittstelle 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 Streitpatent von einer auf der RFID-Technologie basierenden NFC-Ausgestaltung mit 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 (drahtlose) Empfangsschnittstelle und die Steuereinheit des NFC-Lesers nicht von vornherein 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 Hostprozessor (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 Ausgangs- und Bestimmungspunkt (P1…P3) werden jeweils die Endpunkte der jeweiligen 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. Bestimmungspunkten in den Hostprozessoren kann es sich um eine Mehrzahl verschiedener Softwarekomponenten – d. h. um verschiedene Anwendungen – handeln, von denen ein Datenfluss ausgehen kann oder die Empfänger eines solchen Datenflusses sein können (vgl. Streitpatent, Abs. [0065]).

Abbildung in Originalgröße in neuem Fenster öffnen

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öffnungsbefehl benannten Bestimmungspunkt in der kontaktlosen Datensende-/ Empfangsschnittstelle (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 Bestimmungspunkt. Hierzu wird dem Datenweg durch die Steuereinheit eine Routingkanalnummer (CHANi) zugewiesen (vgl. Merkmal M3.1) und diese - ebenfalls durch die Steuereinheit - zusammen mit Routingparametern in eine Routingtabelle eingetragen. Die eingetragenen Routingparameter umfassen wenigstens einen Identifizierer des Ausgangspunktes und einen Identifizierer des Bestimmungspunktes (vgl. Merkmalsgruppe M3.2). Die Routingtabelle beschreibt damit die Zuordnung eines durch die Routingkanalnummer bezeichneten logischen Kommunikationskanals 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.

Werden für den in der kontaktlosen Datensende-/Empfangsschnittstelle lokalisierten 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 encapsulé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 Datensende-/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 kontaktlosen Schnittstelle gesendet (vgl. Merkmale M5 bis M5.2).

Die Datensende-/Empfangsvorrichtung (NFCR2) gemäß Anspruch 12 umfasst eine kontaktlose Datensende-/Empfangsschnittstelle vom RFID-Typ, eine Steuereinheit (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 funktionale 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.

II. Zum geltend gemachten Nichtigkeitsgrund hinsichtlich der erteilten Fassung

Entgegen der Auffassung der Klägerin erweisen sich die allein angegriffenen nebengeordneten 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 ausgefü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 innerhalb der Steuereinheit (vgl. S. 15, erster Abs., dritter Satz). Das Druckschrift D1 entnehmbare Verfahren weist daher zumindest keine Funktionen einer Steuereinheit 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 berührungsloses Datenträgerkommunikationssystem. Ihr ist ebenfalls keine Erzeugung und Verwendung einer Routingtabelle zu entnehmen. Der jeweilige Datenwegeröffnungsbefehl („Kommunikationsstart-Anforderungsbefehl“) des Host-Geräts an das Lese-Schreib-Gerät unterscheidet nicht zwischen verschiedenen (internen) Empfängern bei der Kommunikation zwischen dem Hostprozessor („Host-Gerät“) und der Steuereinheit („Lese-Schreib-Gerät“) (vgl. Abs. [0030]). Die aufgrund des Datenwegeröffnungsbefehls angelegte Korrespondenztabelle (vgl. Abs. [0030]-[0033]) dient daher nicht der Speicherung interner Routinginformationen 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 Hostprozessors 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 („Bluetooth 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 („Bluetooth 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).

Abbildung in Originalgröße in neuem Fenster öffnen

Fig. 1.2

Weiterhin ist ein Datenwegeröffnungsbefehl entnehmbar (Befehl „HCI_Create_Connection“), der mittels eines im Hostprozessor lokalisierten Ausgangspunktes („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 Datenwegerö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 vorgenannten Datenwegeröffnungsbefehl und der zugehörigen Statusmeldung (vgl. 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-/ Empfangskomponenten 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 externen Verbindung zu dem mit dem Parameter „BD_ADDR“ benannten  Gerät („Device A pages Device B“; vgl. Vol. 3, Figur 3.2, a. a. O.), bei welchem die kontaktlose Schnittstelle genutzt wird, ist kein Bestimmungspunkt in der Schnittstelle selbst benannt. Der Aufbau des internen Kommunikationskanals erfolgt somit entgegen 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, erster 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 Controller (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 Routinginformation die Routingkanalnummer („Connection Handle“) zeigt. Darüber hinaus findet 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 erforderlichen Routinginformation – d. h. das Anlegen einer Routingtabelle – in der Steuereinheit liest der Fachmann daher aus der vorstehend beschriebenen Kommunikation 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übertragungsblocks (Datenbereich vor den Nutzdaten „Data“) eine Routingkanalnummer („Connection Handle“) aufweist (vgl. Vol. 3, S. 379 von 814, Fig. 5.2 mit einleitender Beschreibung / Merkmale M4, M4.1). Das Senden des Datenübertragungsblocks („HCI ACL Data Packet”) erfolgt vom Host an einen Bestimmungspunkt innerhalb des Controllers, ohne dass dabei ein Bestimmungspunkt in der kontaktlosen 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 handelt 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 entsprechend den Verfahrensschritten M5.1 und M5.1a oder zum Senden des Datenübertragungsblocks an einen solchen Bestimmungspunkt entnehmbar (vgl. Merkmal M5.2).

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, Bluetooth; vgl. S. 30, Zn. 14-15 und Fig. 3 / teilweise Merkmal M1.3; keine Schnittstelle vom RFID-Typ).

Abbildung in Originalgröße in neuem Fenster öffnen

Der Fachmann liest weiter im Rahmen des „Service Request“ (Fig. 22 mit Beschreibung, S. 32, vorl. Abs.) einen Datenwegeröffnungsbefehl mit, der Voraussetzung für das Übertragen eines Datenstroms („data flow“) ist. Der „Service Request“ 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 Antwort 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 Routinginformationen – 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 Routingkanalnummer („Packet Flow ID“) vergeben wird (Merkmal M3.2, M3.2a; teilweise Merkmale M3.1, M3.2b).

Beim Senden eines Datenübertragungsblocks werden mittels des Ausgangspunktes Daten an die Steuereinheit übersendet, ohne dass dabei die Angabe eines Bestimmungspunkts in der kontaktlosen Schnittstelle erfolgt (Fig. 13 / Merkmal M4.1, teilweise Merkmal M4), wobei beim Empfang des Datenübertragungsblockes mittels der Steuereinheit ein Transportkanal für die Daten in der Routingtabelle 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 (Merkmale M5, M5.1a, teilweise Merkmale M5.1 und M5.2).

Bei der kontaktlosen Datensende-/Empfangsschnittstelle in Druckschrift D15 handelt es sich im Unterschied zum Streitpatent um keine Schnittstelle vom RFID-Typ (vgl. Merkmal M1.3), sondern um UMTS-, GPRS-, WLAN- bzw. Bluetooth-Schnittstellen. Ein Benennen eines internen Bestimmungspunktes in der jeweiligen kontaktlosen 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 Request“ (einschließlich „Create Socket“-Befehl, vgl. Fig. 22) die Benennung eines solchen Bestimmungspunkts ersichtlich. Der Entgegenhaltung sind zudem keine Angaben zum Vorsehen eines solchen internen Bestimmungspunktes in der jeweiligen kontaktlosen Datensende-/Empfangsschnittstelle beim Erzeugen einer Routingtabelle 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 Rahmen der gebotenen Amtsermittlung (§ 87 PatG) zu prüfen, ob die Druckschriften D1 und D2 dem Fachmann den Anspruch 1 des Streitpatents auch unter Einbeziehung seines Fachwissens nahe legen. Dies ist indessen nicht der Fall.

In der Entgegenhaltung D1 findet sich kein Hinweis auf ein Ermitteln eines Bestimmungspunkts 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. Streitpatent, Merkmalsgruppen M3.2 und M5.1). Vielmehr wird der Bestimmungspunkt der Daten in der dortigen Steuereinheit („smart card router 33“) ganz allgemein aus 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 Anlegen und Verwenden einer anspruchsgemäßen Routingtabelle in der Steuereinheit ableiten, da nach der Lehre der Druckschrift D1 zum Routing durch die Steuereinheit („smart card router 33“) jegliche geeignete Adressierung im Header der Datenübertragungsblöcke umfasst ist und bei nur einem Host und einer kontaktlosen 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 ausgehend 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 Anwendungsprogramm des Hostprozessors. Unabhängig davon sind auch hierzu keine näheren Angaben zum Routing – d. h. insbesondere nicht zu einer Verwendung von Kanalnummern – gemacht, die einen Hinweis auf die Gestaltung und Verwendung einer Routingtabelle in der Steuereinheit im Sinne der Merkmalsgruppen M3.2 und M5.1 gemäß Anspruch 1 geben würden.

Für den Fachmann besteht daher bei einem aus Druckschrift D1 bekannten Verfahren keine Veranlassung, die Erzeugung und Verwendung einer Routing-Tabelle in der Steuereinheit für die chipsatzinterne Kommunikation zwischen Hostprozessor und kontaktloser Schnittstelle vorzusehen.

Der Entgegenhaltung D2 (vgl. jeweils deutsche Übersetzung D2-DE) ist keine Erzeugung 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. Merkmalen M5.1 und M5.1a). Selbst wenn man für die in der Entgegenhaltung beschriebene Kommunikation mit externen Datenträgern das Vorhandensein eines Bestimmungspunkts in der kontaktlosen Schnittstelle voraussetzt, fehlt es auch in Druckschrift D2 an der Veranlassung für den Fachmann, eine Routingtabelle 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 verschiedenen (internen) Empfängern unterschieden wird. Selbst in Bezug auf externe 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 Ergebnis, da keiner der beiden Druckschriften Anregungen zur Verwendung einer Routingtabelle 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 angegriffenen 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-/Empfangsvorrichtung mit solchen Merkmalen zu ergänzen.

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 Routingkanalnummer („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 anspruchsgemäß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 asynchronen Verbindungen) einen weiteren Befehl zum Eröffnen eines Datenwegs, aus dem das Vorhandensein von zumindest einem zweiten internen Ausgangspunkt im Hostprozessor im Sinne des Merkmals M2 abgeleitet werden könne. Diese Betrachtung greift aber zu kurz, da es sich hierbei nicht um einen Datenwegerö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 voraus, sondern das Einrichten dieser Verbindung erfolgt zudem unter Verwendung der Routingkanalnummer („Connection_Handle“) der zugrunde liegenden asynchronen Verbindung. Daher wird beim Eröffnen einer synchronen Verbindung kein 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 vielmehr nur die Einrichtung einer synchronen Verbindung auf einem bestehenden Kanal. Damit stellt auch der Ausgangspunkt der Anforderung der synchronen Verbindung keinen zusätzlichen Ausgangspunkt im Sinne des Datenwegeröffnungsbefehls 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 Unterscheidung ebenfalls kein Hinweis darauf, für diesen Ausgangspunkt einen Eintrag in einer Routingtabelle durch die Steuereinheit der Datensende-/ Empfangsvorrichtung und nicht im Host selbst zu erzeugen. Denn der Aufruf eines Datenwegeröffungsbefehls „HCI_Create_Connection“ für eine asynchrone Verbindung (oder ggf. auch „HCI_Setup_Synchronous_Connection“ für eine synchrone Verbindung) erfolgt innerhalb des Hosts durch Aufruf des HCI Treibers („HCI Driver“, vgl. beispielsweise Fig. 1.2, Vol. 3, S. 344 von 814). Dem jeweiligen Befehl ist kein Ausgangspunkt zu entnehmen, der im Rahmen des Treiber-Aufrufs an die Steuereinheit ü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 Hostprozessoren innerhalb des Chipsatzes und kein Routing zwischen solchen Hostprozessoren und Schnittstellen vor, die eine Unterscheidung verschiedener Ausgangspunkte von Datenwegen in einer Routingtabelle der Steuereinheit erforderlich 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.

Abbildung in Originalgröße in neuem Fenster öffnen

Fig. 2.1

Ebenso findet sich in der Druckschrift D3 kein Hinweis auf das Benennen eines internen Bestimmungspunkts innerhalb der kontaktlosen Datensende-/Empfangsschnittstelle („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 verweist hierzu darauf, dass der Datenwegeröffnungsbefehl an den „Bluetooth Controller“ – 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 Bestimmungspunktes 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 asynchronen 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 Verbindung auf. Der Datenwegeröffnungsbefehl, also die jeweiligen HCI-Steuerbefehle zur Einrichtung des Kanals bzw. der darauf aufbauenden synchronen Verbindung, 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 Hostprozessor zwischen internen Bestimmungspunkten in der kontaktlosen Schnittstelle 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 anspruchsgemäße Zuordnung von Routingkanalnummern zu Identifizierern von Bestimmungspunkten 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 Entgegenhaltung D3 weder zu entnehmen, noch ist sie dem Fachmann daraus nahegelegt.

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 Controller dienen, unterscheiden nicht zwischen Bestimmungspunkten in der kontaktlosen 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-/ Empfangsschnittstelle (d. h. im „Radio Interface“) unter Verwendung der Routingkanalnummer 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äß Anspruch 1 des Streitpatents vorzusehen, die neben der Routingkanalnummer den Identifizierer eines im Hostprozessor lokalisierten Ausgangspunkts und den Identifizierer eines Bestimmungspunktes in der kontaktlosen Datensende-/ Empfangsschnittstelle enthält, und diese Routingtabelle zum internen Zuleiten von Datenpaketen 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 Bestimmungspunkten 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 Realisierung 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 Kombinationen mit dem übrigen im Verfahren befindlichen Stand der Technik.

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 zutreffend 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 lokalisierten Bestimmungspunkts im Datenwegeröffnungsbefehl ist jedoch Druckschrift D15 ebenfalls nicht zu entnehmen (vgl. Merkmale M2, M2.1). Denn die Entgegenhaltung strebt an, dass die jeweils zur externen Kommunikation verwendete Schnittstelle für die Anwendungen auf dem Hostprozessor transparent ist und die Zuordnung der Schnittstelle für einen Datenstrom („packet flow“) durch eine Steuereinheit („SIMAC Module“ mit „Link Manager“) bei Bedarf unabhängig von der Anwendungssoftware geändert werden kann (vgl. S. 15, Z. 15 bis S. 16, Z. 5). Dies widerspricht 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äß Druckschrift D15 erfolgt aufgrund der vorstehend beschriebenen Zielsetzung das Zuordnen 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 connection 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 Verbindung für das Senden der Datenpakete des Datenstroms („packet flow“) an und benennt weder explizit den Ausgangspunkt im Hostprozessor noch den Bestimmungspunkt in einer der kontaktlosen Schnittstellen. Selbst wenn man nur den einleitenden „Create Socket“-Befehl des Verfahrensablaufs gemäß Figur 22 als Datenwegeröffnungsbefehl ansieht, fehlt diesem die Festlegung des „Identifizierers des Datenstroms“ („packet flow ID“), den die Klägerin als Routingkanalnummer beim Versenden von Datenpakete eines Datenstroms identifiziert haben will. Ein Ableiten der Eröffnung eines internen Datenwegs im Sinne des anspruchsgemäßen Datenwegeröffnungsbefehls und ein Anlegen einer Routingtabelle auf Basis 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 Fachmann 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 kontaktlosen Schnittstelle anhand der Routingkanalnummer („packet flow ID“) als Index 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 Veranlassung für den Fachmann, die Lehre der Druckschrift D15 im Sinne des im Streitpatent vorgesehenen internen Routingverfahrens zu modifizieren. Auch eine Zusammenschau der Druckschrift D15 mit den weiteren im Verfahren befindlichen Druckschriften, die insbesondere die Nähe verschiedener Kommunikationstechnologien 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 bekannte Datenrouting-Verfahren im Sinne des Anspruchs 1 des Streitpatents zu modifizieren.

Der Gegenstand des Patentanspruchs 1 ist damit dem Fachmann aus dem vorliegenden Stand der Technik nicht nahegelegt.

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 gegenüber dem im Verfahren befindlichen Stand der Technik auf einer erfinderischen Tätigkeit.

Für die funktionalen Merkmale der Komponenten der Datensende- und Empfangsvorrichtung gemäß des angegriffenen Anspruchs 12 gelten sinngemäß die vorstehenden Ausführungen zu Anspruch 1 in gleicher Weise, da diese funktionalen 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 abzuweisen, ohne dass es noch weiterer Ausführungen hinsichtlich der beiden Hilfsanträ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.