European Case Law Identifier: | ECLI:EP:BA:2012:T067210.20121219 | ||||||||
---|---|---|---|---|---|---|---|---|---|
Datum der Entscheidung: | 19 Dezember 2012 | ||||||||
Aktenzeichen: | T 0672/10 | ||||||||
Anmeldenummer: | 99114722.4 | ||||||||
IPC-Klasse: | H04L 12/56 H04L 29/06 |
||||||||
Verfahrenssprache: | DE | ||||||||
Verteilung: | D | ||||||||
Download und weitere Informationen: |
|
||||||||
Bezeichnung der Anmeldung: | Verfahren zur Signalisierung von Applikationen zwischen mindestens zwei Teilnehmern eines digitalen Kommunikationsnetzes sowie Einrichtung hierfür | ||||||||
Name des Anmelders: | IPCom GmbH & Co. KG | ||||||||
Name des Einsprechenden: | - | ||||||||
Kammer: | 3.5.05 | ||||||||
Leitsatz: | - | ||||||||
Relevante Rechtsnormen: |
|
||||||||
Schlagwörter: | Erfinderische Tätigkeit - (nein) Erfinderische Tätigkeit - Bestimmung des nächstliegenden Stands der Technik |
||||||||
Orientierungssatz: |
- |
||||||||
Angeführte Entscheidungen: |
|
||||||||
Anführungen in anderen Entscheidungen: |
|
Sachverhalt und Anträge
I. Die Beschwerde richtet sich gegen die Entscheidung der Prüfungsabteilung, zur Post gegeben am 20. Oktober 2009, auf Zurückweisung der europäischen Patentanmeldung Nr. 99114722.4 aufgrund mangelnder erfinderischer Tätigkeit (Artikel 56 EPÜ) bezüglich eines Hauptantrags und eines Hilfsantrags gegenüber dem folgenden Stand der Technik:
D1: Handley/Schulzrinne/Schooler/Rosenberg: "SIP:
Session Initiation Protocol", Internet Draft,
ietf-mmusic-sip-08.txt, 7. August 1998;
D1-1: M. Handley and V. Jacobson: "SDP: Session
Description Protocol", RFC 2327, April 1998.
II. Die Beschwerdeschrift ging am 17. Dezember 2009 ein. Die Beschwerdegebühr wurde am 18. Dezember 2009 entrichtet. Mit der Beschwerdebegründung, eingegangen am 16. Februar 2010, wurden Ansprüche gemäß einem Hauptantrag (Ansprüche 1 bis 9), einem Hilfsantrag I (Ansprüche 1 bis 6) und einem Hilfsantrag II (Ansprüche 1 bis 5) eingereicht. Die Beschwerdeführerin beantragte hierbei, die angefochtene Entscheidung aufzuheben und ein Patent auf der Grundlage des Hauptantrags oder hilfsweise des Hilfsantrags I bzw. II zu erteilen.
III. Die Kammer hat am 28. August 2012 zu einer für den 19. Dezember 2012 anberaumten mündlichen Verhandlung geladen. Mit der Anlage zur Ladung für eine mündliche Verhandlung gemäß Artikel 15(1) VOBK teilte die Kammer ihre vorläufige Meinung zur Beschwerde mit. Hierbei wurden insbesondere Einwände nach Artikel 52(1) und 56 EPÜ in Bezug auf D1 erhoben und die Gründe hierfür dargelegt. In diesem Zusammenhang wurde mitgeteilt, dass das Dokument
D2: US-A-5 621 894
nicht als nächstliegender Stand der Technik betrachtet werden kann.
IV. Mit Schreiben vom 19. November 2012 brachte die Beschwerdeführerin daraufhin Gegenargumente zu den mit der Mitteilung gemäß Artikel 15(1) VOBK erhobenen Einwänden der Kammer vor. Unterstützend zu diesen Argumenten wurden zudem Auszüge aus verschiedenen Internet-Seiten mit unbekanntem Veröffentlichungsdatum als Anlagen A1 bis A5 eingereicht.
V. Am 19. Dezember 2012 fand eine mündliche Verhandlung statt, in deren Verlauf alle vorliegenden Anträge erörtert wurden. Die Beschwerdeführerin beantragte in der Sache abschließend, die angefochtene Entscheidung aufzuheben und ein Patent auf der Grundlage der Ansprüche des Hauptantrags oder einer der Hilfsanträge I oder II zu erteilen.
Am Ende der mündlichen Verhandlung wurde die Entscheidung der Kammer verkündet.
VI. Der unabhängige Anspruch 1 des Hauptantrags hat folgenden Wortlaut:
"Verfahren zur Signalisierung von Applikationen zwischen mindestens zwei Anwendern (1,4) eines digitalen Kommunikationsnetzes,
wobei zur Signalisierung einer Applikation eine Applikationskennung (UAID), bestehend aus einem binären Wort, verwendet wird, welche beim Verbindungsaufbau in einem leitungsvermittelnden Kommunikationsnetz zwischen den Anwendern (1,4) übertragen wird und welche einem Zielanwender (4) angibt, wie ein hierzu gehöriger Datenstrom zu verarbeiten ist,
wobei eine Applikationskennung (UAID) von einer Applikationsschicht des OSI-Referenzmodells gesetzt wird und von den tieferen Schichten des Kommunikationsprotokolls transparent übertragen wird und wobei mittels der Applikationskennung zwischen den Anwendern die Art einer Datenverbindung, beispielsweise hinsichtlich Kanalcodierung, Datenrate, Datenformat, im Dialogverkehr ausgehandelt wird."
Die weiteren unabhängigen Ansprüche 8 und 9 des Hauptantrags sind auf die entsprechenden Sende- und Empfangseinrichtungen zur Durchführung des Verfahrens gemäß Anspruch 1 gerichtet.
Der unabhängige Anspruch 1 des Hilfsantrags I enthält alle Merkmale des Anspruchs 1 gemäß Hauptantrag und umfasst zusätzlich das folgende Merkmal:
"wobei zwischen Anwendern (1,4) mehrere Applikationen gleichzeitig austauschbar sind und mittels der jeweiligen Applikationskennung (UAID) unterschiedliche Datenkanäle im Parallelbetrieb bereitgestellt werden."
Der unabhängige Anspruch 1 des Hilfsantrags II enthält alle Merkmale des Anspruchs 1 gemäß Hilfsantrag I und umfasst zusätzlich das folgende Merkmal:
"wobei der Wertebereich der Applikationskennung (UAID) in verschiedene Klassen unterteilt ist."
Entscheidungsgründe
1. Zulässigkeit der Beschwerde
Die Beschwerde erfüllt die Erfordernisse der Artikel 106 bis 108 und Regel 99 EPÜ (vgl. Punkt II oben). Die Beschwerde ist daher zulässig.
2. HAUPTANTRAG
Dieser Antrag entspricht dem der angefochtenen Entscheidung zugrunde liegenden Hauptantrag.
2.1 Artikel 52(1) EPÜ: Neuheit und erfinderische Tätigkeit
Die Kammer urteilt, dass die unabhängigen Ansprüche 1, 8 und 9 dieses Antrags nicht die Erfordernisse des Artikels 52(1) EPÜ in Verbindung mit Artikel 56 EPÜ erfüllen. Die Gründe sind wie folgt:
2.1.1 Die Kammer betrachtet D1 als den nächstliegenden Stand der Technik, da dieses Dokument demselben technischen Gebiet der "digitalen Kommunikationsnetze" wie die Erfindung zuzuordnen ist und sich mit dem gleichen Verwendungszweck, nämlich der Signalisierung von unterstützten Applikationen, befasst.
2.1.2 In Bezug auf die Terminologie des Anspruchs 1 offenbart nun D1 ein Verfahren zur Signalisierung von Applikationen ("media types") zwischen Anwendern ("participants") eines digitalen Kommunikationsnetzes (siehe z. B. Seite 1, Abschnitt "Abstract", zweiter Absatz: "SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types ..."). Hierbei wird eine binäre Applikationskennung ("m"-Feld) zur Signalisierung der entsprechenden Applikation (z. B. "audio" oder "video"-Dienste) verwendet (siehe z. B. Seite 104, Abschnitt 15.3, dritter Absatz: "m=audio 3456 RTP/AVP 0 3 4 5").
Das m-Feld wird mit einer "SIP-INVITE"-Nachricht, die wiederum üblicherweise zum Aufbau einer Verbindung ("session") verwendet wird (siehe z. B. Seite 23, Abschnitt 4.2.1, erster Absatz: "The INVITE method indicates that the user or service is being invited to participate in a session ..."), von einem Anwender ("C") an einen anderen Anwender ("S") über ein digitales Kommunikationsnetz ("Internet") geschickt (siehe z. B. Seite 104, Abschnitt 15.3, zweiter Absatz: "C->S: INVITE ..."). Darüber hinaus gibt das m-Feld dem Zielanwender ("S") hier an, welche Kodierungsarten für Audio-Applikationen unterstützt werden (siehe Seite 104, Abschnitt 15.3, erster Absatz), d. h. wie der entsprechende Audio-Datenstrom zu verarbeiten ist.
Zudem wird das m-Feld durch das hier verwendete Signalisierungsprotokoll SIP, d. h. auf der Applikationsschicht des OSI-Referenzmodells, gesetzt (siehe z. B. Seite 2, Abschnitt 1.1, erster Absatz: "The Session Initiation Protocol (SIP) is an application-layer control protocol that can establish, modify and terminate multimedia sessions or calls ...") und von den niedrigen Kommunikationsprotokollschichten unabhängig, mithin transparent, übertragen (siehe z. B. Seite 1, letzte Zeile bis Seite 2, erste Zeile: "... SIP is designed to be independent of the lower-layer transport protocol ..."). Mittels der Angaben im m-Feld wird auch die Art der entsprechenden Datenverbindung wie die Datenrate oder das Datenformat (obgleich diese Beispiele zu den optionalen Merkmalen des Anspruchs 1 zuzurechnen sind) im Dialogverkehr ausgehandelt (siehe z. B. Seite 104, Abschnitt 15.3, erster Absatz und Seite 113, Abschnitt 15.8, letzter Absatz).
2.1.3 Die Kammer stimmt daher der Feststellung der Prüfungsabteilung zu, wonach der einzige Unterschied zwischen dem Gegenstand des Anspruchs 1 und der Offenbarung von D1 darin besteht, dass die Applikationskennung in einem leitungsvermittelnden Kommunikationsnetz zwischen den Anwendern übertragen wird.
Folglich ist der Gegenstand des Anspruchs 1 dieses Antrags neu gegenüber D1 (Artikel 54 EPÜ).
2.1.4 Die durch den Anspruch 1 zu lösende objektive Aufgabe wird nun in der analogen Anwendung des obigen Signali-sierungsverfahrens auf verschiedene Vermittlungs-prinzipien in einem digitalen Kommunikationsnetz gesehen.
2.1.5 Ausgehend von Dokument D1, in dem ausdrücklich darauf hingewiesen wird, dass das Signalisierungsprotokoll SIP auch die Implementierung von (leitungsvermittelnden) ISDN bzw. von Intelligenten Netzen sicherstellen kann (siehe Seite 2, Abschnitt 1.1, dritter Absatz: "SIP transparently supports name mapping and redirection services, allowing the implementation of ISDN and Intelligent Network telephony subscriber services ...") oder auch auf Leitungsvermittlung ausgerichtete Protokolle wie RSVP unterstützt (siehe Seite 3, Zeilen 16-18: "SIP is designed as part of the overall IETF multimedia data and control architecture currently incorporating protocols such as RSVP ... for reserving network resources ..."), würde der mit der objektiven Aufgabe konfrontierte Fachmann auf dem Gebiet der digitalen Kommunikationsnetze die Anregung erhalten, das entsprechende Signalisierungsverfahren auch auf leitungsvermittelnde statt nur paketvermittelnde Kommunikationsnetze anzuwenden.
Unter Einsatz seines allgemeinen Fachwissens würde daher der Fachmann die jeweilige Applikationskennung (d. h. das m-Feld in den SIP-INVITE-Nachrichten) beim initialen Verbindungsaufbau im Hinblick auf ein ISDN?Netz oder ein RSVP-basiertes Datennetz verschicken, um sicherzustellen, dass das Signalisierungsverfahren auch auf diese Art von Netzen erweiterbar ist. Da dies im Übrigen impliziert, dass lediglich die Signalisierungsinformation vorab, d. h. vor der Leitungsbelegung (bei ISDN) bzw. der Pfadreservierung (bei RSVP) übertragen wird anstatt während der paketbasierten Datenübertragung, würde sich der Fachmann keinen besonderen Schwierigkeiten in der Implementierung einer solchen Anpassung gegenübersehen.
Zudem zeigt der Hinweis auf das Internet-basierte Ressourcenreservierungsprotokoll RSVP in D1 gerade, dass die in der Telekommunikation bewährten Techniken der Leitungs- und Paketvermittlung durchaus kombinierbar sind, im Gegensatz zur Auffassung der Beschwerdeführerin.
2.1.6 Die obigen Ausführungen gelten mutatis mutandis für die korrespondierenden Vorrichtungsansprüche 8 und 9 dieses Antrags.
2.1.7 Aus diesen Gründen beruht der Gegenstand der Ansprüche 1, 8 und 9 dieses Antrags nicht auf einer erfinderischen Tätigkeit gegenüber D1 und dem allgemeinen Fachwissen des Fachmanns (Artikel 56 EPÜ).
2.1.8 Die Beschwerdeführerin brachte unter Bezugnahme auf die Richtlinie für die Prüfung C-IV, 11.7.1 (in der Fassung von 2007; seit Juni 2012: G-VII, 5.1) in diesem Zusammenhang vor, dass D1 nicht demselben Gebiet der Technik, nämlich der leitungsvermittelnden Kommunikationsnetze, wie die beanspruchte Erfindung angehöre. Vielmehr sei das auf leitungsvermittelnde Netze gerichtete Dokument D2 als der nächstliegende Stand der Technik anzusehen, da leitungs- und paketvermittelnde Netze strukturell wie funktionell komplett anders gelagert seien.
Dem folgt die Kammer nicht. Zunächst ist anzumerken, dass die Prüfungsrichtlinien für die Beurteilung der Rechtslage in der Beschwerdeinstanz ohnehin keine Bindungswirkung entfalten. Die Auffassung der Kammer steht aber auch nicht im Widerspruch zu ihnen. Die Anmeldung gibt als Ausgangspunkt für die Erfindung in diesem Zusammenhang die Signalisierung von Applikationen in digitalen Kommunikationsnetzen an (vgl. Seite 1, erster Absatz der ursprünglichen Anmeldung) und wählt damit einen breiten Ansatz, der leitungs- und paketvermittelnde Netze gleichermaßen umfasst. Daher wäre das technische Feld der "leitungsvermittelnden Kommunikationsnetze" sowohl für den Fachmann der Telekommunikationsnetze als auch im Lichte der Anmeldung eine zu eingeschränkte Gebietsfestlegung.
Im Übrigen ist die Zuordenbarkeit des zu bestimmenden nächstliegenden Stands der Technik zu demselben Gebiet der Technik wie die beanspruchte Erfindung nur eines von vielen Kriterien zur Feststellung des nächstliegenden Stands der Technik (vgl. Rechtsprechung der Beschwerdekammern des Europäischen Patentamts, 6. Auflage, 2010, I.D.3, die sich auch in der Richtlinie für die Prüfung C-IV, 11.7.1 in der Fassung von 2007 widerspiegelt). Zudem waren nach Auffassung der Kammer die Übermittlungsprinzipien der Leitungsvermittlung, in der den Kommunikationspartnern für die gesamte Kommunikationsdauer ein bestimmter Übertragungspfad bzw. eine feste Bandbreite exklusiv zur Verfügung gestellt wird, und der Paketvermittlung, bei der die zwischen den Kommunikationspartnern zu sendenden Nachrichten als Pakete einzeln durch das Netz geleitet werden, zum Prioritätszeitpunkt der Anmeldung bereits derart miteinander verzahnt, dass der Fachmann auf dem Gebiet der Kommunikationsnetze - entgegen der Auffassung der Beschwerdeführerin - diese Prinzipien nicht als eigenständige und unvereinbare Fachbereiche oder gar Studiengänge angesehen hätte.
Dagegen weist D2 zu viele strukturelle wie funktionelle Differenzen zur beanspruchten Erfindung auf, als dass es gerechtfertigterweise als nächstliegender Stand der Technik in diesem Fall angesehen werden könnte.
2.1.9 Zur Abgrenzung von einem generellen "Dienst" unternahm die Beschwerdeführerin auch den Versuch, die beanspruchte "Applikation" mit einer speziellen Anwendung wie z. B. Windows Media Player bzw. Skype gleichzusetzen. Daher sei in diesem Kontext eine Applikation enger zu interpretieren als ein Dienst, der in diesem Zusammenhang als Grundfunktion mehrere Applikationen umfassen könne.
Die Kammer bemerkt hierzu nur, dass selbst die ursprüngliche Anmeldung die Begriffe "Applikation" und "Dienst" als Synonyme verwendet (vgl. z. B. Seite 3, Zeilen 16-18: "... die Applikationen, d. h. verschiedene Dienste, ..." oder zumindest hierbei nicht die Verwendung einer speziellen Anwendung nahelegt (vgl. Seite 5, Zeilen 29-32, wonach gewöhnliche Kodierungsarten als Applikationen angesehen werden).
2.1.10 Die Beschwerdeführerin behauptete zudem mit Verweis auf die Anlagen A4 und A5 (vgl. Punkt IV oben), dass das in D1 verwendete SIP-Protokoll kein Protokoll der "Applikationsschicht des OSI-Referenzmodells" im Sinne des Anspruchs 1 sei, sondern vielmehr - wie die entsprechende Bezeichnung "Session Initiation Protocol" bereits suggeriere - der Sitzungsschicht des OSI?Referenzmodells zuzuordnen wäre.
Dieser Behauptung kann die Kammer nicht zustimmen. Auch wenn offenbar in der Fachwelt gegenwärtig keine konsistente Lehre zur Einordnung des SIP-Protokolls innerhalb des OSI-Referenzmodells vorliegt (vgl. Anlage A1 aus Wikipedia, Seite 1, dritter Absatz: "The SIP protocol is an Application Layer protocol" bzw. Anlage A5, Seite 3, zweiter Absatz: "At the Session layer you can find ... Session Initiation Protocol (SIP) ...") gibt der Stand der Technik D1 unmissverständlich an, dass es sich bei SIP um ein Signalisierungsprotokoll der Applikationsschicht handelt und folglich die Applikationskennung ("m-Feld") im Sinne des Anspruchs 1 auch von einer Applikationsschicht gesetzt wird (siehe Seite 2, Abschnitt 1.1, erster Absatz: "The Session Initiation Protocol (SIP) is an application-layer control protocol ..." und Seite 6, vorletzter Absatz: "... A user agent client is a client application that initiates the SIP request ...").
2.1.11 Das zusätzliche Argument der Beschwerdeführerin, dass bei paketvermittelnden Kommunikationsnetzen wie jenes in D1 kein Verbindungsaufbau erforderlich sei, kann allein schon dadurch widerlegt werden, dass die übliche Verwendung des TCP-Protokolls in paketvermittelnden Netzen wie dem Internet den hierbei typischen Aufbau von logischen Verbindungen für einen zuverlässigen Datentransport auch in solchen Netzen belegt. Daher ist auch dieses Argument fachlich nicht korrekt und geht somit ins Leere.
2.2 Aus diesen Gründen ist dieser Antrag nicht gewährbar nach Artikel 52(1) und 56 EPÜ.
3. HILFSANTRAG I
Dieser Antrag basiert auf dem der angefochtenen Entscheidung zugrunde liegenden Hilfsantrag.
Der Anspruch 1 dieses Antrags enthält neben den Merkmalen des Anspruchs 1 gemäß Hauptantrag zusätzlich das folgenden Merkmal:
(a) wobei zwischen Anwendern mehrere Applikationen
gleichzeitig austauschbar sind und mittels der
jeweiligen Applikationskennung unterschiedliche
Datenkanäle im Parallelbetrieb bereitgestellt
werden.
3.1 Artikel 52(1) EPÜ: Neuheit und erfinderische Tätigkeit
3.1.1 Die Merkmalsanalyse bezüglich des Hauptantrags gemäß Punkt 2.1.2 gilt mutatis mutandis auch für den Anspruch 1 dieses Antrags.
3.1.2 Im Gegensatz zur Auffassung der Prüfungsabteilung (vgl. angefochtene Entscheidung, II.2-1.1 und II.2-1.2) offenbart D1 aufgrund der breiten Auslegbarkeit des Begriffs "Datenkanäle" auch das zusätzliche Merkmal (a) des Anspruchs 1, wonach mehrere Applikationen (wie "audio" und "video") gleichzeitig übertragbar sind und durch die Angabe der jeweiligen Port-Nummern (z. B. "3456" für "audio" bzw. "2232" für "video") innerhalb der entsprechenden m?Felder unterschiedliche Datenkanäle (also Ports) im Sinne des Anspruchs 1 parallel unterstützt werden können (siehe Seite 113, Abschnitt 15.8: "m=audio 3456 RTP/AVP 7 0 13" und "m=video 2232 RTP/AVP 31").
3.1.3 Folglich gelten die Feststellungen bezüglich des Hauptantrags gemäß Punkte 2.1.3 bis 2.1.5 mutatis mutandis auch für den Anspruch 1 dieses Antrags.
3.1.4 Hierzu brachte die Beschwerdeführerin lediglich vor, dass es sich bei den beanspruchten "Datenkanälen" um reine Kommunikationskanäle bzw. -pfade handele.
Diese Interpretation kann jedoch nach Ansicht der Kammer weder dem Anspruch 1 noch der ursprünglichen Anmeldung entnommen werden.
3.2 Somit ist auch dieser Antrag nicht gewährbar nach Artikel 52(1) und 56 EPÜ.
4. HILFSANTRAG II
Dieser Antrag entspricht dem der angefochtenen Entscheidung zugrunde liegenden Hilfsantrag.
Der Anspruch 1 dieses Antrags umfasst neben den Merkmalen des Anspruchs 1 gemäß Hilfsantrag I zusätzlich das folgende Merkmal:
(b) wobei der Wertebereich der Applikationskennung in
verschiedene Klassen unterteilt ist.
4.1 Artikel 52(1) EPÜ: Neuheit und erfinderische Tätigkeit
4.1.1 Die Merkmalsanalyse bezüglich des Hauptantrags gemäß Punkt 2.1.2 und des Hilfsantrags I gemäß Punkt 3.1.2 gilt mutatis mutandis auch für den Anspruch 1 dieses Antrags.
4.1.2 Nach Ansicht der Kammer offenbart D1 auch das zusätzliche Merkmal (b) des Anspruchs 1, wonach die Applikationskennungen in verschiedene Klassen (wie "audio" oder "video" mit inhärent binären Werten) unterteilt werden (siehe z. B. Seite 113, Abschnitt 15.8: "m=audio ..." und "m=video ...").
4.1.3 Daher gelten die Feststellungen bezüglich des Hauptantrags gemäß Punkte 2.1.3 bis 2.1.5 mutatis mutandis auch für den Anspruch 1 dieses Antrags.
4.1.4 Die Beschwerdeführerin argumentierte im Hinblick auf diesen Antrag, dass die in D1 angegebenen Bezeichnungen "audio", "video" oder "application" keine Applikationsklassen im Sinne der Erfindung zur flexibleren Differenzierung für spezielle Kompatibilitätsfälle seien, sondern nur Medientypen darstellten.
Diese Argumentation kann die Kammer schon deshalb nicht überzeugen, da die ursprüngliche Anmeldung selbst Audio-, Video- oder Datendienste als Beispiele für solche Applikationsklassen nennt (vgl. Seite 6, Zeilen 1-4).
4.2 Demnach ist auch dieser Antrag nicht gewährbar nach Artikel 52(1) und 56 EPÜ.
Entscheidungsformel
Aus diesen Gründen wird entschieden:
Die Beschwerde wird zurückgewiesen.