T 0444/10 (Übereinstimmung der Protokollinstanzen bei der … of 20.7.2011

Sachverhalt und Anträge

I. Die Beschwerden der Patentinhaberin und der Einsprechenden 01 richten sich gegen die Zwischenentscheidung der Einspruchsabteilung vom 16. November 2009, die am 15. Januar 2010 zur Post gegeben wurde, das europäische Patent EP 1 226 692 in geändertem Umfang aufrechtzuerhalten.

Gemäß dieser Zwischenentscheidung sind die Ansprüche wie erteilt gemäß Hauptantrag wegen mangelnder erfinderischer Tätigkeit gegenüber

O1: 3GPP TS RAN 25.323 V 0.1.0 (September 1999)

nicht gewährbar.

Der Gegenstand der Ansprüche gemäß Hilfsantrag wie aufrechterhalten wurde hingegen in dieser Zwischenentscheidung als neu und erfinderisch angesehen, in Bezug auf die Dokumente O1,

O2: 3GPP TS 25.331 V 1.1.0 (Juni 1999),

O3: ETSI TS 101 297 V 7.0.0 (September 1999),

O6: 3GPP TS 25.301 V 3.2.0 (Oktober 1999),

O8: 3GPP TS 25.331 V 1.4.2 (September 1999), und

O9 : Tdoc NP-99260, Change Request A043r1

(6-8. Oktober 1999).

II. Am 26. Februar 2010 reichte die Einsprechende 01 (nachstehend die "Beschwerdeführerin I") Beschwerde ein und entrichtete die Beschwerdegebühr.

Die Beschwerdebegründung wurde am 25. Mai 2010 eingereicht. Die Beschwerdeführerin I beantragte, die Zwischenentscheidung der Einspruchsabteilung aufzuheben und das Patent in vollem Umfang wegen mangelnder Neuheit bzw. mangelnder erfinderischer Tätigkeit zu widerrufen. Hilfsweise wurde eine mündliche Verhandlung beantragt.

III. Am 3. März 2010 reichte die Patentinhaberin (nachstehend die "Beschwerdeführerin II") Beschwerde ein und entrichtete die Beschwerdegebühr.

Die Beschwerdebegründung wurde am 3. Mai 2010 eingereicht. Die Beschwerdeführerin II beantragte die Zwischenentscheidung der Einspruchsabteilung aufzuheben und das Patent mit den Ansprüchen wie erteilt gemäß Hauptantrag aufrechtzuerhalten. Hilfsweise wurde eine mündliche Verhandlung beantragt.

IV. Am 27. September 2010 beantragte die Einsprechende /Beitretende den Beitritt zum Einspruchsbeschwerdeverfahren als vermeintliche Patentverletzerin. Sie beantragte das Patent im vollen Umfang zu widerrufen. Sie stützte ihren Einspruch auf die gleichen Einspruchsgründe und Argumente wie die Beschwerdeführerin I.

V. Die Beschwerdeführerin I hat mit Schreiben vom 17. Oktober 2010 zu der Beschwerdebegründung der Beschwerdeführerin II Stellung genommen und hat argumentiert, dass der Gegenstand des Anspruchs 1 wie erteilt gemäß Hauptantrag weder neu noch erfinderisch wäre.

VI. Mit Schreiben vom 29. Oktober 2010 stellte die Beschwerdeführerin I einen Antrag auf Beschleunigung des Beschwerdeverfahren unter Hinweis auf eine in Düsseldorf, DE, durch die Patentinhaberin erhobene Verletzungsklage.

VII. Die Beschwerdeführerin II hat mit Schreiben vom 16. Dezember 2010 zu der Beschwerdebegründung der Beschwerdeführerin I Stellung genommen und beantragt hilfsweise das Patent, wie im Einspruchsverfahren eingeschränkt, d.h. gemäß Hilfsantrag, aufrechtzuerhalten.

VIII. Mit Schreiben vom 4. Februar 2011 hat die Beschwerdeführerin II beantragt den Beitritt der Einsprechende/Beitretende als unbegründet zurückzuweisen.

IX. In einer der Ladung zur mündlichen Verhandlung beigefügten Mitteilung vom 7. April 2011 hat die Kammer angekündigt, dass nach ihrer vorläufigen Meinung der Beitritt der Verfahrensbeteiligten zulässig sei. Ferner teilte die Kammer ihr vorläufiges Verständnis der technischen Inhalte von O1, O2, O3, O6, 08 und O9 sowie Fragen mit, die bezüglich Neuheit und erfinderischer Tätigkeit der Ansprüche 1 gemäß Hauptantrag und Hilfsantrag in Bezug auf den Stand der Technik in der mündlichen Verhandlung diskutiert werden würden.

X. In Reaktion auf die Mitteilung der Kammer hat die Beschwerdeführerin I mit Schreiben vom 17. Juni 2011 ihren Antrag auf Widerruf des Patents bestätigt. Zusätzlich hat sie neue Argumente vorgebracht und das folgende Dokument eingereicht:

O11: ETSI, Draft EN 301 344 V6.1.1, August 1998.

XI. In Reaktion auf die Mitteilung der Kammer hat die Beschwerdeführerin II ihren Hauptantrag mit Schreiben vom 18. Juni 2011 bestätigt. Zusätzlich hat sie Hilfsanträge 1 bis 7 eingereicht, die sich jeweils von dem Hauptantrag durch einen geänderten Anspruch 1 unterscheiden. Als Hilfsantrag 8 hat die Beschwerdeführerin II den früheren Hilfsantrag aufrechterhalten. Sie hat auch angegeben, auf welche Textstellen sich die Änderungen stützen und aufgeführt, wodurch sich der beanspruchte Gegenstand jeweils vom Stand der Technik weiter unterscheidet. Zur Stützung ihrer Argumentation hat die Beschwerdeführerin II die Anlage A1 eingereicht:

A1: 3GPP TSG-RAN Meeting, Nizza, FR, 13-15 Dezember 1999, 3G CHANGE REQUEST R2-99k28.

XII. In Reaktion auf die Mitteilung der Kammer hat die Einsprechende/Beitretende mit Schreiben vom 19. Juni 2011 ihren Antrag auf Widerruf des Patents bestätigt. Sie hat zusätzlich ihre Argumentation auf die folgende neu eingereichte Dokumente gestützt:

H10: 3G TS 24.065 V3.1.0, August 1999,

H11: "Draft minutes of WG2 meeting #7", Malmö, September 20 - 24, 1999, v. 0.1,

H12: R2-99b30: Draft version of 3G TS RAN 25.323 V0.0.1, WG2 meeting #7, September 1999,

H13: R2-99a01: "Draft minutes of WG2 meeting #6", Sophia Antipolis 16-20 August 1999, v. 0.3,

H14: R2-99769: 3G change request 25.301, WG2 meeting #6, August 1999,

H15: R2-99908: 3G change request 25.301, TSG-RAN meeting #5, 6. Oktober 1999,

H16: RP-99575: 3G change request 25.301, TSG-RAN meeting #5, Oktober 6, 1999,

H17: R2-99c25: "Proposed TS 25.323: PDCP Protocol Specification", Nokia und Bosch, RAN27, Malmö, September 1999,

H18: ETSI TS 101 351 V7.0.0, GSM 04.64 version 7.0.0, August 1999.

XIII. Mit Schreiben vom 13. Juli 2011 hat die Beschwerdeführerin II in Reaktion auf die Eingabe der Einsprechenden/Beitretenden neue Argumente vorgebracht und eine frühere Version des bereits im Verfahren befindlichen Dokuments O6 eingereicht:

O6a: TS 25.301 v.3.1.0, Juni 1999, "3rd Generation Partnership Project (3GPP); Technical Specification Group (TSG) RAN; Working Group 2 (WG2); Radio Interface Protocol Architecture".

XIV. In der mündlichen Verhandlung am 19. und 20. Juli 2011, an der Vertreter der Beschwerdeführerin II sowie der Beschwerdeführerin I und der Einsprechenden/Beitretenden teilnahmen, wurde die Zulässigkeit des Beitritts seitens der Beschwerdeführerin II nicht in Frage gestellt. Ferner wurde der Sachverhalt in Bezug auf die Begründetheit der Beschwerden mit den Beteiligten diskutiert. Die Beschwerdeführerin II nahm während der Verhandlung die ursprünglichen Hilfsanträge 1 bis 8 zurück, reichte einen neuen Hilfsantrag 1 ein und verfolgte den Hauptantrag weiter. Sie überreichte als neues Dokument

A19: 3G TS25.322 V3.0.0 (1999-10), Seiten 16 und 17.

XV. Die Beschwerdeführerin II beantragte die Aufhebung der angefochtenen Entscheidung und die Aufrechterhaltung des europäischen Patents wie erteilt (Hauptantrag) oder hilfsweise die Aufrechterhaltung des europäischen Patents in geändertem Umfang auf der Grundlage der Ansprüche 1 bis 13 gemäß Hilfsantrag 1 eingereicht in der mündlichen Verhandlung am 20. Juli 2011. Die mit Schreiben vom 18. Juni 2011 gestellten Hilfsanträge 1 bis 8 wurden zurückgezogen.

Die Beschwerdeführerin I beantragte die Aufhebung der angefochtenen Entscheidung und den Widerruf des europäischen Patents.

Die Einsprechende/Beitretende beantragte die Aufhebung der angefochtenen Entscheidung und den Widerruf des europäischen Patents.

Am Ende der mündlichen Verhandlung wurde die Entscheidung verkündet.

XVI. Anspruch 1 gemäß Hauptantrag lautet wie folgt:

"Verfahren zum Betreiben eines Mobilfunknetzes (30),

in dem Nutzdaten durch eine erste Konvergenzprotokollschicht (1) einer ersten Funkstation (15)

vor dem Übertragen an eine zweite Konvergenzprotokollschicht (2) einer zweiten Funkstation (16), zu mindestens einer ersten Dateneinheit zusammengesetzt werden, wobei die Nutzdaten von mindestens einem Nutzer (21, 22) in einer Netzwerkschicht (5) an die erste Konvergenzprotokollschicht (1) geliefert werden, wobei mindestens eine Protokollinstanz (35) der ersten Konvergenzprotokollschicht (1)

in Abhängigkeit einer von der zweiten Funkstation (16) empfangenen Konfigurationsaufforderung (40, 41, 42) konfiguriert wird,

um aus den von dem mindestens einen Nutzer (21. 22) empfangenen Daten die mindestens eine erste Dateneinheit zu bilden und durch einen Träger (45) an eine Verbindungssteuerungsschicht zu übertragen,

dadurch gekennzeichnet, dass bei der Konfiguration eine Protokollinstanzidentität festgelegt wird, durch die die Protokollinstanz (35) referenzierbar ist."

Anspruch 1 gemäß Hilfsantrag 1 lautet:

" Verfahren zum Betreiben eines Mobilfunknetzes (30),

in dem Nutzdaten durch eine erste Konvergenz-protokollschicht (1) einer ersten Funkstation (15) vor dem Übertragen an eine zweite Konvergenzprotokollschicht (2) einer zweiten Funkstation (16) zu mindestens einer ersten Dateneinheit zusammengesetzt werden, wobei die Nutzdaten von mindestens einem Nutzer (21, 22) in einer Netzwerkschicht (5) an die erste Konvergenzprotokollschicht (1) geliefert werden, wobei mindestens eine Protokollinstanz (35) der ersten Konvergenzprotokollschicht (1) in Abhängigkeit einer von der zweiten Funkstation (16) empfangenen Konfigurationsaufforderung (40, 41, 42) konfiguriert wird, um aus den von dem mindestens einen Nutzer (21, 22) empfangenen Daten die mindestens eine erste Dateneinheit zu bilden und durch einen Träger (45) an eine Verbindungssteuerungsschicht zu übertragen,

dadurch gekennzeichnet, dass bei der Konfiguration

eine Protokollinstanzidentität festgelegt wird, durch die die Protokollinstanz (35) referenzierbar ist, dass bei der Konfiguration der Träger (45) festgelegt wird, über den die Nutzdaten von der Protokollinstanz (35) an die Verbindungssteuerungsschicht (10) übertragen werden, und dass die Protokollinstanzidentität derart festgelegt wird, dass sie der Identität des ihr zugeordneten Trägers (45) entspricht, wobei die Konfigurationsaufforderung (40, 41, 42) in dem Fall, in dem ein Träger (45) mittels einer Trägerkonfigurationsnachricht (70) aufgebaut, rekonfiguriert oder abgebaut wird, in die Trägerkonfigurationsnachricht eingefügt wird."

Entscheidungsgründe

1. Zulässigkeit

1.1 Die Beschwerde der Beschwerdeführerin I wurde am 26. Februar 2010 fristgerecht eingelegt, die Beschwerdebegründung innerhalb der vorgesehenen 4-Monatsfrist eingereicht.

1.2 Die Beschwerde der Beschwerdeführerin II wurde am 3. März 2010 fristgerecht eingelegt, die Beschwerdebegründung innerhalb der vorgesehenen 4- Monatsfrist eingereicht.

Beide Beschwerden sind somit zulässig (Artikel 108, Regel 99 EPÜ).

1.3 Der Antrag zum Beitritt der Einsprechenden/Beitretenden wurde am 27. September 2010 eingereicht. Am gleichen Tag wurden die Begründung eingereicht und die Einspruchsgebühr entrichtet.

Die Einsprechende/Beitretende hat Beweismittel vorgelegt, aus denen hervorgeht, dass die Beschwerdeführerin II in Macerata, Italien, gegen sie Klage wegen Verletzung des Patents erhoben hat und dass sie diese Klage am 25. Juni 2010 zur Kenntnis genommen hat. Der Beitritt ist deshalb gemäß Artikel 105(1) a) EPÜ in Verbindung mit Regel 89 EPÜ zulässig.

Diese Beweismittel betrachtet die Kammer auch als Aufforderung der Beschwerdeführerin II eine angebliche Patentverletzung zu unterlassen. Da die Einsprechende/Beitretende zusätzlich nachgewiesen hat, dass sie am 17. Dezember 2010 gegen die Beschwerdeführerin II Klage auf Feststellung, dass sie das Patent nicht verletze, erhoben hat, ist der Beitritt auch gemäß Artikel 105(1) b) EPÜ in Verbindung mit Regel 89 EPÜ zulässig.

Die Beschwerdeführerin II hat weder im schriftlichen Verfahren noch in der mündlichen Verhandlung Argumente gegen die Zulässigkeit des Beitritts vorgetragen.

2. Stand der Technik

2.1 Dokumente O1, 02, und O6/O6a: UMTS Standard

O1, O2 und O6/O6a sind 3GPP (UMTS) Standardisierungs-dokumente, wobei O2 und O6a in O1 zitiert werden.

O1 bezieht sich auf das "Packet Data Convergence Protocol" PDCP Protokoll im UMTS Standard. Durch dieses Protokoll werden Datenpakete ("PDCP-SDU"), die von höheren Schichten des Mobilfunknetzes stammen, in sogenannten PDCP-Einheiten (PDCP-Protokollinstanzen) konfiguriert. Drei verschiedene Primitive werden hierfür verwendet: CPDCP-Establish-Req./Ind., CPDCP-Release-Req./Ind. und CPDCP-Modify-Req./Ind.. O1 zeigt zusätzlich (siehe Figur 1) für jede PDCP-Einheit eine RB Identity, die unterhalb der Konvergenzprotokollschicht ("PDCP-sublayer") angeordnet ist und zum Referenzieren des zum Transport der PDCP-Einheit zur Nachbarschicht RLC verwendeten Trägers geeignet ist.

O2 betrifft das Protokoll zur Funkressourcensteuerung RRC im UMTS Standard. Durch dieses Protokoll werden die obengenannten Träger RAB auf und abgebaut. O2 offenbart, dass zu jedem Träger RAB, der aufgebaut werden soll, eine korrespondierende RLC Einheit, d.h. eine RLC Instanz, in der RLC Schicht erstellt wird, und dass eine Identität ("RAB identity") gemeinsam mit dem RAB erzeugt wird (siehe Abschnitte 8.3.1.1 und 10.1.5.4). Einer neueren Version von O2, O8, ist zu entnehmen, dass die Begriffe "Radio Access Bearer" RAB und "Radio Bearer" RB den gleichen Träger bezeichnen (siehe Abschnitte 8.2 und 10.1.5.4).

O6 betrifft die Protokollarchitektur für die Funkschnittstelle im UMTS Standard. O6 lehrt, dass die Funkressourcensteuerung RRC die Träger RB für die Verbindung zwischen den PDCP und RLC Schichten zur Verfügung stellt (siehe Abschnitt 5.1, insbesondere Figur 2). O6 zeigt zusätzlich, dass das RRC Protokoll geeignet ist, auf die PDCP-Schicht zuzugreifen, um diese mittels den Steuernachrichten CPDCP zu konfigurieren. O6a betrifft die frühere Version V3.1.0 des gleichen Standardisierungsdokuments TS 25.301, die im O1 zitiert ist. Im Gegensatz zu O6, ist die PDCP Schicht im Dokument O6a nicht erwähnt.

Die Frage, ob die Dokumente O1, O2 und O6 (oder O6a) zusammen als ein einziges Dokument des Standes der Technik für die Neuheitsprüfung betrachtet werden können, wie von der Beschwerdeführerin I und der Einsprechenden/Beitretenden behauptet, hat die Kammer in der mündlichen Verhandlung verneint. Die Gründe dafür sind, dass obwohl diese Dokumente zu der gleichen Gruppe von UMTS-Standardisierungsdokumenten gehören, sie eine willkürliche Auswahl aus den zahlreichen Dokumenten dieser Gruppe darstellen, insbesondere in Bezug auf die Veröffentlichungsdaten und die technischen Inhalte. Die Tatsache, dass O2 und O6a in O1 zitiert sind, ändert daran nichts, da es sich hier um eine völlig allgemeine Bezugnahme und nicht um qualifizierte Verweise handelt. Insbesondere wird keine spezifische technische Lehre aus der O2 oder der O6a in O1 erläutert oder verwendet.

Die Auffassung der Beschwerdeführerin I, dass der gesamte UMTS Standard, und diesbezüglich ein übliches UMTS Mobiltelefon, auch als ein einziges Dokument betrachtet werden sollte, teilt die Kammer daher nicht.

Bei der Prüfung der erfinderische Tätigkeit hingegen ist die Kombination von O1 mit O2 und O6(oder O6a) für den Fachmann naheliegend, da sich diese Dokumente auf verknüpfte UMTS-Protokollschichten beziehen, und O2 und O6 in O1 als Referenzen zitiert werden.

2.2 Dokumente O3 und O9: GSM Standard

O3 und O9 sind Standardisierungsdokumente zum GPRS/GSM Standard, der Vorläufer-Mobilfunktechnologie des UMTS, wobei O9 ein "Change request" zu O3 ist, der Änderungen zu den Abschnitten 6.5 bis 6.8 von O3 vorschlägt. Wegen ihrer zusammenhängenden technischen Lehre werden O3 und O9 als ein einziges Dokument betrachtet.

O3 betrifft die GSM/GPRS Konvergenzschicht SNDCP sowie deren Konfiguration. O3 zeigt, dass eine SNDCP-layer durch das Aussenden eines LL-ESTABLISH.request aufgebaut wird (siehe Abschnitt 6.8). Diese Steuernachricht enthält einen SNDCP-block mit XID Parametern, die dem Konfigurieren von Kompressionseinheiten in der SNDCP-layer dienen. O9 beschreibt zusätzlich, dass diese Kompressionseinheiten während der Konfiguration des SNDCP-layers explizit nummeriert werden können.

3. Hauptantrag

3.1 Die von allen beteiligten Parteien verwendete Merkmalsgliederung des Anspruchs 1 gemäß Hauptantrag lautet wie folgt:

[1] Verfahren zum Betreiben eines Mobilfunknetzes (30),

[2] in dem Nutzdaten durch eine erste Konvergenzprotokollschicht (1)

[3] einer ersten Funkstation (15)

[4] vor dem Übertragen

[5] an eine zweite Konvergenzprotokollschicht (2)

[6] einer zweiten Funkstation (16)

[7] zu mindestens einer ersten Dateneinheit

[8] zusammengesetzt werden,

[9] wobei die Nutzdaten von mindestens einem Nutzer

(21, 22) in einer Netzwerkschicht (5)

[10] an die erste Konvergenzprotokollschicht (1) geliefert werden,

[11] wobei mindestens eine Protokollinstanz (35) der ersten Konvergenzprotokollschicht (1)

[12] in Abhängigkeit einer von der zweiten Funkstation (16) empfangenen Konfigurationsaufforderung (40, 41, 42) konfiguriert wird,

[13] um aus den von dem mindestens einen Nutzer (21, 22) empfangenen Daten die mindestens eine erste Dateneinheit zu bilden und

[14] durch einen Träger (45)

[15] an eine Verbindungssteuerungsschicht (10) zu übertragen, dadurch gekennzeichnet, dass

[16] bei der Konfiguration

[17] eine Protokollinstanzidentität festgelegt wird,

[18] durch die die Protokollinstanz (35) referenzierbar ist.

Auf diese Merkmalsgliederung wird im folgenden Bezug genommen.

3.2 Erfinderische Tätigkeit:

In Bezug auf den Hauptantrag wird das Dokument O1 als nächstliegender Stand der Technik angesehen, da dieses auf dem gleichen technischen Gebiet, dem Betreiben eines Mobilfunknetzes, liegt und über die in der Anmeldung angesprochene Funktionalität des Konvergenzprotokolls (siehe O1, Seite 5, Zeile 12: "PDCP Packet Data Convergence Protocol") mit Protokollinstanzen des Konvergenzprotokolls (siehe O1, Seite 6, Zeile 5: "PDCP entity") verfügt.

Die Merkmale 1 bis 15 des Anspruchs 1 sind im Dokument O1 offenbart werden.

In dieser Hinsicht offenbart O1, mit dem Wortlaut des Anspruchs 1:

[1] Ein Verfahren zum Betreiben eines Mobilfunknetzes ("Radio Network"),

[2] in dem Nutzdaten ("user data", "PDCP-SDU") durch eine erste Konvergenzprotokollschicht ("PDCP sublayer") [3] einer ersten Funkstation ("transmitting entity")

[4] vor dem Übertragen ("point-to-point connection")

[5] an eine zweite Konvergenzprotokollschicht

[6] einer zweiten Funkstation ("receiving entity")

[7] zu mindestens einer ersten Dateneinheit ("RLC-SDU")

[8] zusammengesetzt werden (Siehe PDCP-Block mit zwei Verbindungen zu darüber liegenden PDCP-SDUs in Figur 1),

[9] wobei die Nutzdaten von mindestens einem Nutzer in einer Netzwerkschicht ("Network layer protocols")

[10] an die erste Konvergenzprotokollschicht ("PDCP-sublayer") geliefert werden,

[11] wobei mindestens eine Protokollinstanz (siehe Figur 1, PDCP Block, oder Seite 6, "PDCP entity") der ersten Konvergenzprotokollschicht (siehe Seite 6, Zeilen 5-6: "The PDCP entities are located in the PDCP sublayer")

[12] in Abhängigkeit einer von der zweiten Funkstation empfangenen Konfigurationsaufforderung konfiguriert wird (siehe Seite 6, Zeilen 17-18: "Compression...at the transmitting entity and decompression at the receiving entity" in Verbindung mit Seite 7: "The compression algorithm and its parameter are negociated by RRC for each PDCP entity"),

[13] um aus den von dem mindestens einen Nutzer empfangenen Daten die mindestens eine erste Dateneinheit zu bilden (siehe PDCP Block mit zwei Verbindungen zu darüber liegenden PDCP-SDUs in Figur 1),und

[14] durch einen Träger ("Radio Bearer")

[15] an eine Verbindungssteuerungsschicht (siehe Figur 1, "RLC") zu übertragen.

Der Gegenstand des Anspruchs 1 unterscheidet sich somit von dem Verfahren gemäß O1 dadurch, dass:

[16] bei der Konfiguration

[17] eine Protokollinstanzidentität festgelegt wird,

[18] durch die die Protokollinstanz referenzierbar ist.

Diese Unterschiedsmerkmale haben den technischen Effekt, dass auf eine konfigurierte Protokollinstanz in der Konvergenzprotokollschicht direkt zugegriffen werden kann. Diesem liegt die technische Aufgabe zugrunde, eine Implementierung des aus O1 bekannten Standards anzugeben, durch die insbesondere die Adressierung der Protokollinstanzen in der Konvergenzprotokollschicht ermöglicht wird. Dazu gehört notwendigerweise die in O1 vorgesehene Möglichkeit eine bestehende Protokollinstanz abzubauen oder zu rekonfigurieren (siehe O1, Seite 8: "delete a PDCP entity", "modify a PDCP entity"). Um diese Vorgänge zu ermöglichen, müssen die bestehende Protokollinstanzen angesprochen werden. Dazu ist es erforderlich, jeder Protokollinstanz im Konvergenzprotokollschicht bei ihrer Entstehung, d.h. ihrer Konfiguration, kennzeichnende Merkmale zuzuweisen, die eindeutig diese einzelne Protokollinstanz von den anderen bestehenden Protokollinstanzen differenzieren. Diese zugewiesenen kennzeichnenden Merkmale dienen der Identifikation der Protokollinstanz und stellen deshalb eine Protokollinstanzidentität dar.

Somit ist die Festlegung einer Identität gemäß der Merkmale [16] bis [18] als fachübliche Vorgehensweise zur Lösung der Aufgabe zu betrachten. Folglich beruht der Gegenstand des Anspruchs 1 nicht auf erfinderischer Tätigkeit gegenüber O1.

3.3 Die Beschwerdeführerin II argumentierte, dass die Merkmale [11] bis [15], zusätzlich zu den Merkmalen [16] bis [18], auch nicht in O1 offenbart worden sind.

In diesem Zusammenhang behauptete die Beschwerdeführerin II, dass O1 keine zweite Funkstation zeige und dass die Primitive in O1, Abschnitt 7, die zur Konfiguration der PDCP Einheiten in einer Funkstation dienen, ausschließlich von der RRC-Schicht in dieser Funkstation erzeugt werden und somit von dieser Schicht ausgehen. Deshalb könnten sie keine Konfigurationsaufforderungen darstellen, die, wie von Merkmal [12] verlangt, von der zweiten Funkstation kommen.

Nach Auffassung der Kammer weisen mehrere Stellen in O1 darauf hin, dass die Konfiguration der PDCP Instanzen in einer Funkstation in Abhängigkeit von der zweiten Funkstation stattfindet. In Bezug auf die für PDCP-data Übertragung benutzten Primitive lehrt O1, Seite 8, Abschnitt 7, dass "It is used for data transmission of point-to-point connection between the same level user entities". Das bedeutet, dass sich die Einheiten in der Punkt-zu-Punkt Verbindung auf der gleichen Ebene des Protokollschichtenmodells in zwei verschiedenen Funkstationen befinden. Obwohl die in O1, Abschnitt 7.1, offenbarten Primitive zur Konfiguration der PDCP-Schicht in einer Funkstation dienen, liegt es für den Fachmann auf der Hand, dass eine ähnliche Konfiguration durch ähnliche Primitive in der zweiten Funkstation erfolgen muss, um, z. B. das in O1 erwähnte Aushandeln des Kompressionsalgorithmus und dessen Parametern in den PDCP-Schichten der zwei Funkstationen zu ermöglichen (siehe O1, Seite 6, Abschnitt 5, Absatz 1, und Seite 7, Abschitt 1.3).

Darüber hinaus argumentierte die Beschwerdeführerin II, dass, mit der Formulierung "um...durch einen Träger...zu übertragen" in Merkmalen [13] bis [15], zusätzlich zu den Elementen der PDCP-Konvergenzprotokollschicht auch der Träger zur RLC-Verbindungssteuerungsschicht bestimmt oder konfiguriert wird. Im Stand der Technik gemäß O1 würde der Träger als Bestandteil der unterhalb der PDCP-Schicht liegenden RLC-Schicht nicht mit der PDCP-Schicht konfiguriert.

Diesem Argument vermag die Kammer nicht zu folgen, da mit der "um"-Formulierung eine gemeinsame Konfiguration des Trägers und der PDCP-Schichtinstanz nicht ausdrücklich beansprucht wird. Vielmehr würde der Fachmann Anspruch 1 so verstehen, dass, wie in O1, Figur 1, gezeigt wird, die Übertragung einer PDCP-Instanz zur RLC-Schicht lediglich durch einen nicht weiter im Anspruch spezifizierten Träger erfolgt.

In Bezug auf den Beitrag der übrigen Merkmalen [16] bis [18] zur erfinderischen Tätigkeit argumentierte die Beschwerdeführerin II, dass es in O1 keine Anregung für den Fachmann gebe, eine Protokollinstanzidentität bei der Konfiguration festzulegen. Um den Standard gemäß O1 zu implementieren, insbesondere eine PDCP-Instanz abzubauen oder zu rekonfigurieren, könnte man die Instanz durch den C-SAP (O1, Figur 1) ansprechen, ohne eine feste Instanzidentität oder einen Instanznamen zu brauchen.

Es ist aber für die Kammer nicht erkennbar, wie man eine Protokollinstanz ohne irgendwelche kennzeichnende Merkmale finden kann. Diese Merkmale wiederum stellen eine Instanzidentität dar, mit der die Instanz referenzierbar ist.

4. Hilfsantrag 1

4.1 Anspruch 1 enthält, zusätzlich zu den Merkmalen [1] bis [18] des Anspruchs 1 gemäß Hauptantrag und an diese anschließend, die folgende Merkmale:

[19] dass bei der Konfiguration der Träger (45) festgelegt wird, über den die Nutzdaten von der Protokollinstanz (35) an die Verbindungssteuerungsschicht (10) übertragen werden,

[20] und dass die Protokollinstanzidentität derart festgelegt wird, dass sie der Identität des ihr zugeordneten Trägers (45) entspricht,

[21] wobei die Konfigurationsaufforderung (40, 41, 42) in dem Fall, in dem ein Träger (45) mittels einer Trägerkonfigurationsnachricht (70) aufgebaut, rekonfiguriert oder abgebaut wird, in die Trägerkonfigurationsnachricht eingefügt wird.

4.2 Neuheit und erfinderische Tätigkeit gegenüber UMTS-Standard Dokumente (O1, O2, O6):

4.2.1 Die Merkmale [16] bis [18] sind aus O1 nicht bekannt (siehe Punkt 3.2). Das Merkmal [20] ist aus O1 auch nicht bekannt, weil eine PDCP-Instanz keine zugeordnete Identität besitzt, die sie von anderen aufgebauten

PDCP-Instanzen differenzieren könnte.

Die Merkmale [19] und [21] sind aus O1 auch nicht bekannt. O1 offenbart lediglich auf Seite 8, Punkt b), dass die CPDCP-Primitive ausschließlich die PDCP-Protokollinstanzen konfigurieren und ihre Verbindung zur NAS-Schicht und zum Träger bestimmen, nicht aber den Träger selbst konfigurieren. Vielmehr entnimmt der Fachmann O1, Seite 6, Abschnitt 5, Punkt 2, dass der Träger ("radio bearer") von der RLC-Schicht bereitgestellt wird. Einzelheiten des RLC-Protokolls sind aus O1 nicht zu entnehmen. Diesbezüglich verweist

O1, Seite 4, Abschnitt 2, auf Referenz [5], d.h. auf ein weiteres Dokument. Deshalb kann der Fachmann in O1 allein keine Offenbarung bezüglich der Trägerkonfiguration und erst recht keine Offenbarung bezüglich einer gemeinsamen Konfiguration einer PDCP-Instanz und eines Trägers finden.

4.2.2 Die Unterscheidungsmerkmale [16], [17], [18] und [20] haben lediglich die Wirkung, dass die PDCP-Protokollinstanz bei ihrer Konfiguration mit der RB-Identität referenziert wird. Das Referenzieren der PDCP-Protokollinstanz kann allein keine erfinderische Tätigkeit begründen (siehe Punkt 3.2). Zusätzlich zeigt O1 (siehe Figur 1), dass einem Träger, der eine PDCP-Einheit (= PDCP-Protokollinstanz) in der PDCP-Schicht mit einer RLC-Einheit in der RLC-Schicht verbindet, eine Identität ("RB-Identity") zugewiesen wird und dass es eine eins-zu-eins Verbindung zwischen einer PDCP-Einheit und dem zugehörigen Träger gibt (siehe Seite 6, Zeilen 4 bis 6). Der Fachmann würde erkennen, dass die

RB-Identity als Referenz für die PDCP-Einheit geeignet ist und bei der Vergabe einer Referenz für eine

PDCP-Protokollinstanz deshalb auf diese schon vorhandene RB-Identität des Trägers zurückgreifen, ohne dabei erfinderisch tätig zu sein. Deshalb können die Unterscheidungsmerkmale [16], [17], [18] und [20] allein keine erfinderische Tätigkeit des Anspruchs 1 begründen.

4.2.3 Die Unterscheidungsmerkmale [19] und [21] bewirken, dass die Konfiguration der PDCP-Protokollinstanz gemeinsam mit der Konfiguration des Trägers zur RLC-Schicht angefordert und durchgeführt wird. Auf diese Weise kann ein zusätzliches Informationselement für die Übertragung der PDCP-Konfigurationsaufforderung und somit Übertragungsbandbreite eingespart werden. Deshalb kann die zu lösende technische Aufgabe darin gesehen werden, eine schnellere und effizientere Konfiguration der PDCP-Protokollinstanz zu erreichen.

Da O1 sich weder mit der RRC-Schicht, die den Träger konfiguriert, noch mit der RLC-Schicht, die den Träger zur PDCP-Schicht bereitstellt, befasst, enthält dieses Dokument keinerlei Hinweis auf eine derartige Konfigurierung der PDCP-Protokollinstanz. Aus der bloßen Referenz zur "RLC Protocol specification" in O1 (siehe Seite 4) hat der Fachmann keine Veranlassung, wie seitens der Beschwerdeführerin I und Einsprechenden/Beitretenden behauptet, die Lehre des RLC Protokoll in Bezug auf das Konfigurieren der RLC-Schicht-Instanzen in die Veröffentlichung von O1 einbeziehen, um sie auf das Konfigurieren der PDCP-Schicht-Instanzen zu übertragen.

Ferner ist auch der O2 kein Hinweis zu entnehmen, dass in Abhängigkeit von der empfangenen

PDCP-Konfigurationsaufforderung auch der zu verwendende Träger konfiguriert wird, da die PDCP-Schicht in O2 nicht erwähnt wird (siehe Figur 1). O2 zeigt lediglich, dass die RRC-Schicht zuerst den Träger konfiguriert und dann die damit verbundene RLC-Instanz in der untergeordneten RLC-Schicht konfiguriert (siehe Seite 17, Zeilen 9 bis 13). Dafür benutzt O2 ein Trägerkonfigurationsnachricht (siehe Seite 47 und 52), die ein Trägeridentitätsfeld ("RAB identity") sowie ein "RLC info"-Feld enthält. Die Bedeutung dieses

"RLC-info"-Feldes in Bezug auf die Konfiguration der RLC-Schicht selber wird in O2 nicht weiter erläutert. Es ist somit aus O2 nicht zu entnehmen, dass die

"RLC-info"-Daten eine Konfigurationsaufforderung zur RLC-Schicht darstellen. Deshalb gibt es in O2 keinen Hinweis darauf, dass in die Trägerkonfigurationsnachricht eine Konfigurationsaufforderung für eine Nachbarschicht eingefügt wird. Auch wenn man die "RLC-info"-Daten als eine in die Trägerkonfigurationsnachricht eingefügte Aufforderung, die RLC-Schicht zu konfigurieren, betrachten würde, wie von der Beschwerdeführerin I und der Einspechenden/Beitretenden behauptet wurde, wäre es für den Fachmann nicht naheliegend, die Lehre einer solchen gemeinsamen Konfiguration der RLC-Schicht und des Trägers auf die PDCP-Schicht zu übertragen, da die RLC-Schicht eine dem Träger im Benutzer-Protokollstapel untergeordnete Schicht ist, und der Fachmann eine gemeinsame Konfiguration des Trägers nur mit dem Träger untergeordneten Schichten in Erwägung ziehen würde. Deswegen würde der Fachmann nicht entgegen der Lehre von 02 eine dem Träger übergeordnete Schicht, z.B. die PDCP-Schicht, gemeinsam mit dem Träger konfigurieren, wie von der Beschwerdeführerin I und Einsprechenden/Beitretenden behauptet wurde.

Aus O6 ist in Bezug auf die PDCP-Schicht zwar zu entnehmen, dass diese, wie die RLC-Schicht, durch die RRC-Schicht konfiguriert wird (siehe Seite 12, Zeilen 22 bis 26 und Figur 2). Die Primitive CPDCP (siehe Seite 14), die zur Konfiguration der PDCP-Schicht dienen, können zwar als Konfigurationsaufforderung der PDCP-Instanzen gesehen werden. Es gibt aber keine Offenbarung und keinen Hinweis in O6, dass diese Primitive in eine Trägerkonfigurationsnachricht eingefügt werden könnten.

Die Beschwerdeführerin I und die Einsprechende/Beitretende argumentierten zusätzlich, dass durch die "in dem Fall"-Formulierung im Anspruch 1 die Trägerkonfigurationsnachricht optional sei und der Anspruch deswegen unklar sei. Nach Auffassung der Kammer ist aber diese Formulierung klar. In der Tat, beschreibt das Merkmal [21] einen Verfahrensschritt, der von dem beanspruchten Verfahren ausgeführt wird oder nicht, abhängig davon, ob eine Trägerkonfigurationsnachricht vorhanden ist oder nicht. Dieser Schritt unterscheidet das beanspruchte Verfahren von Verfahren des Standes der Technik, die anders laufen, wenn eine Trägerkonfigurationsnachricht vorhanden ist.

Die Merkmale [19] und [21] sind folglich aus den Dokumenten O1, O2 und O6 im einzelnen oder in Kombination miteinander weder bekannt noch nahegelegt.

Der Gegenstand des Anspruchs 1 beruht somit auf erfinderischer Tätigkeit gegenüber O1, O2 und O6.

4.3 Neuheit und erfinderische Tätigkeit gegenüber GSM/GPRS Standard Dokumente (O3, O9)

4.3.1 Die Merkmale [1] bis [15] sind aus O3/O9 bekannt. O3/O9 offenbart, mit dem Wortlaut des Anspruchs 1:

[1] Ein Verfahren zum Betreiben eines Mobilfunknetzes ("GPRS Network"),

[2] in dem Nutzdaten ("Network layer Protocol Data Units", "N-PDUs") durch eine erste Konvergenzprotokollschicht ("SNDCP entity")

[3] einer ersten Funkstation (Figur 1, MS; Seite 17, Abschnitt 5.2: "transmitting entity")

[4] vor dem Übertragen (Seite 17, "transmitting entity" and "receiving entity")

[5] an eine zweite Konvergenzprotokollschicht

[6] einer zweiten Funkstation (Figur 1, SGSN; Seite 17, "receiving entity")

[7] zu mindestens einer ersten Dateneinheit ("SN-PDU")

[8] zusammengesetzt werden (Seite 10, Zeilen 1 bis 3: "multiplexing of data coming from different sources"; Seite 17, Paragraph 5.2: "Multiplexing of N-PDUs from one or several network layer entities onto the appropriate LLC connection"),

[9] wobei die Nutzdaten von mindestens einem Nutzer in einer Netzwerkschicht ("Network layer protocols")

[10] an die erste Konvergenzprotokollschicht ("SNDCP") geliefert werden,

[11] wobei mindestens eine Protokollinstanz (Siehe

Figur 8: Die "Protocol compr." und "Data compr." Einheiten, die die Nutzdaten durch die SNDCP-Schicht zu eine spezifischen einzigen SAPI übertragen, bilden zusammen eine SNDCP-Protokollinstanz)

[12] in Abhängigkeit einer von der zweiten Funkstation empfangenen Konfigurationsaufforderung konfiguriert wird (Seite 14: "LL-ESTABLISH.request" konfiguriert die Kompressionseinheiten der SNDCP-Schicht; Seite 27, Zeilen 1 bis 8: "negociated entities"; Seite 31, Abschnitt 6.8),

[13] um aus den von dem mindestens einen Nutzer empfangenen Daten die mindestens eine erste Dateneinheit zu bilden (Seite 10: "multiplexing of data coming from different sources"),und

[14] durch einen Träger ("Logical Link LL")

[15] an eine Verbindungssteuerungsschicht (siehe Figuren 2 und 3: "LLC layer") zu übertragen.

Die Merkmale [16], [17], [18] und [20] sind aus O3/O9 nicht bekannt. In dieser Hinsicht stellt die implizite (O3) oder explizite (O9) Nummerierung einer Kompressionseinheit während einer XID-Verhandlung keine Protokollinstanzidentität im Sinne der Merkmale [16] bis [18]. In der Tat, werden die Kompressionseinheitsnummern für alle Träger ("LL") unabhängig verteilt (siehe O9, Seite 1: "The compression entity number is assigned independently for different SAPIs of an MS"), d.h. die gleiche Nummer kann an zwei verschiedene Kompressionseinheiten mit zwei verschiedenen Trägern vergeben werden (siehe O9, Seite 8, Abschnitt 6.6.11.1) so dass diese Nummer nicht eindeutig ist und die Kompressionseinheiten nicht durch diese Nummer referenzierbar sind. Folglich sind die SNDCP-Protokollinstanzen, die diese Kompressionseinheiten beinhalten, auch nicht durch diese Nummer in der SNDCP-Schicht referenzierbar. Die Beschwerdeführerin I und die Beitretende/Einsprechende verwiesen zusätzlich auf H18 (Seiten 12, 13 und 26) und argumentierten, dass der "SAPI", der jede LL-Verbindung identifiziert, auch als Protokollinstanzidentität der korrespondierenden Protokollinstanz in der übergeordneten SNDCP-Schicht dienen könnte. Die Kammer ist aber der Auffassung, dass es keine Offenbarung in O3/O9 gibt, selbst wenn man die Lehre aus H18 einbezieht, dass der SAPI bei der Konfiguration als SNDCP-Protokollinstanzidentität festgelegt wird.

Die Merkmale [19] und [21] sind aus O3/O9 nicht bekannt, weil die LL-ESTABLISH Nachricht keinen Träger (SAPI) konfiguriert, auch wenn sie eine Konfigurationsaufforderung der SNDCP-Instanz darstellt, denn sie konfiguriert Kompressionseinheiten, die Bestandteile einer SNDCP-Instanz sind (siehe 03, Seite 13, Tabelle 2 und Seite 15, Abschnitt 5.1.1.18: der SAPI wird mit dem SNSM-ACTIVATE Nachricht, und nicht mit der LL-ESTABLISH Nachricht konfiguriert).

4.3.2 Die Unterscheidungsmerkmale [16], [17], [18] und [20] haben lediglich die Wirkung, dass die

SNDCP-Protokollinstanz bei ihrer Konfiguration mit der Träger-Identität referenziert wird. Das bloße Referenzieren der SNDCP-Protokollinstanz kann allein keine erfinderische Tätigkeit begründen (siehe auch oben Punkt 3.2). Zusätzlich zeigt O3/O9, dass ein Träger (LLi), der eine SNDCP-Protokollinstanz im SNDCP-Schicht mit der LLC-Schicht verbindet, eine Identifizierungsnummer ("SAPI") zugewiesen wird und dass es eine eins-zu-eins Zuordnung zwischen einer

SNDCP-Instanz und einem Träger gibt (siehe O3, Figur 8). Bei der Vergabe einer Referenz zu einer SNDCP-Protokollinstanz würde deshalb der Fachmann auf diese schon im Verfahren bestehende

SAPI-Identifizierungsnummer des Trägers zurückgreifen, ohne dabei erfinderisch tätig zu sein. Deshalb können die Unterscheidungsmerkmale [16], [17], [18] und [20] allein keine erfinderische Tätigkeit des Anspruchs 1 begründen.

4.3.3 Die Unterscheidungsmerkmale [19] und [21] bewirken, dass die Konfiguration der SNDCP-Protokollinstanz gemeinsam mit der Konfiguration des Trägers zur LLC-Schicht angefordert und durchgeführt wird. Auf diese Weise kann ein zusätzliches Informationselement für die Übertragung der SNDCP-Konfigurationsaufforderung und somit Übertragungsbandbreite eingespart werden. Deshalb wird die zu lösende technische Aufgabe darin gesehen, eine schnellere und effizientere Konfiguration der SNDCP-Protokollinstanz zu erreichen.

Die Feststellung der Träger ("SAPI") erfolgt im O3/O9 durch Primitive zwischen der SNDCP-Schicht und der Session Management SM-Schicht (siehe O3, Tabelle 2, "SNDCP<->SM"), während die Konfiguration der Kompressionseinheiten der SNDCP-Instanz durch Primitive zwischen der SNDCP-Schicht und der LL-Schicht erfolgt. Die Konfiguration der Kompressionseinheiten erfolgt daher unabhängig von der Konfiguration eines Trägers. Der Fachmann kann aus O3/O9 keinen Hinweis auf ein koordiniertes Ausführen dieser verschiedenen Primitive einzelner Protokollebenen entnehmen.

Der Gegenstand des Anspruchs 1 beruht somit auf erfinderischer Tätigkeit gegenüber O3/O9.

4.4 Die Ansprüche 2 bis 13 des Hilfsantrags 1 sind von Anspruch 1 abhängige Ansprüche und schränken den Gegenstand des Anspruchs 1 weiter an. Sie beruhen somit auch auf erfinderischer Tätigkeit.

ENTSCHEIDUNGSFORMEL

Aus diesen Gründen wird entschieden:

1. Die angefochtene Entscheidung wird aufgehoben.

2. Die Angelegenheit wird an die erste Instanz mit der Anordnung zurückverwiesen, das Patent mit den Ansprüchen 1 bis 13 gemäß Hilfsantrag 1 eingereicht in der mündlichen Verhandlung am 20. Juli 2011 und einer noch anzupassenden Beschreibung sowie den Zeichnungen wie erteilt aufrechtzuerhalten.