-
Diese
nicht vorläufige
Patentanmeldung beansprucht die Priorität der älteren vorläufigen U.S.-Patentanmeldungen
mit dem Titel „Evolutions
to OSA/Parlay Interfaces to Support the Virtual Home Environment
(VHE) Business Model and User Profiles", Anmeldenummer 60/330,660, angemeldet
am 26. Oktober 2001 im Namen von Christophe Gourraud, Veröffentlichungsnummer
US2003/0084147.
-
Hintergrund
der Erfindung
-
Gebiet der
Erfindung
-
Die
vorliegende Erfindung betrifft die Verwaltung von Dienstteilnahmeinformationen
bezogen auf Drittdienste, die in einem Telekommunikationsnetz zur
Verfügung
gestellt werden.
-
Beschreibung
des Standes der Technik
-
Gängige zellulare
Telekommunikationsnetze verfolgen überwiegend das Ziel, Teilnehmern
grundlegende Telefondienste zur Verfügung zu stellen. Zusätzliche
Dienste werden von den Netzinhabern oder -betreibern bereitgestellt.
In den kommenden Jahren werden neue Akteure den Teilnehmern eine
größere Auswahl
von erweiterten bzw. Mehrwertdiensten zur Verfügung stellen. Hierzu müssen diese
neuen Akteure Zugriff auf die Infrastruktur und die Fähigkeiten von
Netzen haben. Allerdings muss dies in einer nachvollziehbaren Art
und Weise, ohne Kompromisse zwischen der Netzsicherheit und der
Netzintegrität geschehen.
Aus diesem Grund ist die Entwicklung von standardmäßigen Schnittstellen
für das
Netz eine Notwendigkeit geworden.
-
Seit
einigen Jahren hat das 3GPP zusammen mit anderen Normungsorganen
eine OSA-Spezifikation (Open Service Access) entwickelt, die auch als
Parlay/OSA bezeichnet wird. Das Hauptziel liegt in der Bereitstellung
von Anwendungsprogrammschnittstellen (Application Program Interfaces – APIs) für die Dienstentwicklung
sowie zum Einsatz in Telekommunikationsnetzen. Geschäftsseitig
ist OSA Drittdienstanbietern näher
als Netzbetreibern. Sinngemäß ist die
Gruppe bestrebt, eine große
Bandbreite von netzorientierten APIs zu schaffen. Die APIs werden
hergestellt, um Drittdienstanbietern Zugriff auf die Funktionalitäten der
Netzeinrichtungen des Betreibers zu gewähren.
-
Zur
Zeit werden Benutzerteilnahmeinformationen bezogen auf Drittdienste
von dem Drittdienstanbieter verwaltet. Allerdings basieren die Drittdienste überwiegend
auf Ereignissen, die im Betreibernetz vorkommen. Deshalb muss der
Drittdienstanbieter den Netzbetreiber bitten, für jeden seiner angemeldeten
Benutzer Auslöser
für entsprechende
Ereignisse hinzuzufügen.
Dieser Registrierungsvorgang für
Drittdienste verursacht etliche Probleme. Eines dieser Probleme
betrifft die Anzahl unterschiedlicher Auslöser, die von dem Drittdienstanbieter
einheitlich verwaltet werden muss. Jede Registrierungsänderung
eines Drittdienstes resultiert in Änderungen in der Auslösedatenbank
des Netzbetreibers. Ein weiteres Problem entsteht dadurch, dass
die Registrierung jedes Auslösers
vom Drittdienstanbieter im Betreibernetz durchgeführt wird. Tatsächlich hat
der Netzbetreiber keine Möglichkeit der
Authentifizierung, dass der Benutzer dem Drittdienstanbieter den
Empfang der jedem Auslöser
entsprechenden Mitteilung erlaubt. Ein weiteres Problem wiederum
resultiert aus der Tatsache, dass der Betreiber dem Drittdienstanbieter
Zugriff auf dessen Netzdatenbanken öffnen muss. In einigen Fällen kann
es schwierig sein, einheitliche Daten in den Netzdatenbanken zu
verwalten, wenn neue Einträge und/oder Änderungen
bereits existierender Einträge ohne
Kontrolle durch den Betreiber vorgenommen werden.
-
Das
Dokument GRECH M L F et al. „Delivering
seamless services in open networks using intelligent service mediation" offenbart die Bereitstellung von
Drittdiensten in offenen Netzen. Die Betriebsserverkomponente kann
eine Benutzer-, Anwendungs- und
SLP-(Service-Level Policy)-Unterstützung bereitstellen, die bestimmt,
ob, wann und in welcher Weise ein bestimmter Dienst von einer Anwendung oder
einem Benutzer aufgerufen werden kann.
-
Während Dienstewechselwirkungen
zwischen zwei Netzen sowie die Teilnahmeverwaltung individuell analysiert
und für
eine breite Palette von Protokollen und Netzen umfassend entwickelt
worden sind, gilt es, sich mit der Teilnahmeverwaltung für Dienste,
die von einem Drittdienstanbieter zur Verfügung gestellt werden, weiterhin
zu befassen.
-
Bekanntermaßen besteht
bei der Bereitstellung von Drittdiensten ein Bedarf an einer besseren Verwaltung
von Dienstteilnahmeinformationen. Eine derartige Lösung wird
mit der vorliegenden Erfindung geschaffen.
-
Zusammenfassung
der Erfindung
-
Die
vorliegende Erfindung betrifft eine Vorrichtung zum Verwalten der
Registrierung von Benutzern eines Netzes bei einem Drittdienst,
wobei der Drittdienst von außerhalb
des Netzes bereitgestellt wird. Die Vorrichtung ist in der Lage,
eine Mehrzahl von Registrierungsanforderungen zu empfangen, wobei
jede der Mehrzahl von Registrierungsanforderungen eine Drittdienstreferenz
von dem Benutzer enthält,
sowie einen Registrierungsdatensatz für jede der Mehrzahl von Registrierungsanforderungen
zu erzeugen. Jeder Registrierungsdatensatz umfasst die Drittdienstreferenz
von der entsprechenden Registrierungsanforderung und eine Referenz
zu dem Benutzer, von dem die entsprechende Registrierungsanforderung
empfangen wurde. Die Vorrichtung ist weiterhin in der Lage, eine
Mehrzahl von Auslöseanforderungen
von einem Service Capability Server (SCS) zu empfangen und einen
Auslösedatensatz
für jede
der Mehrzahl von Auslöseanforderungen
zu erzeugen, wobei jede der Mehrzahl von den Auslöseanforderungen
und jeder entsprechende Auslösedatensatz
eine Referenz zu mindestens einem Ereignis für das Netz und die Drittdienstreferenz umfasst.
-
Weiterhin
ist die Vorrichtung in der Lage, nach dem Erkennen eines Ereignisses
in dem Netz mindestens einen der Mehrzahl von Auslösedatensätzen zu
prüfen,
um mindestens eine Korrespondenz zwischen dem erkannten Ereignis
und mindestens einer der Mehrzahl von Referenzen auf mindestens
ein Ereignis festzustellen, und, wenn die mindestens eine Korrespondenz
festgestellt ist, Senden mindestens einer Ereignismitteilung an
den SCS. Die mindestens eine Ereignismitteilung umfasst die entsprechende
Referenz zu mindestens einem Ereignis, die entsprechende Drittdienstreferenz
und die entsprechende Referenz zu dem Benutzer.
-
Die
vorliegende Erfindung betrifft ferner einen Service Capability Server
(SCS) zum Steuern von Wechselwirkungen zwischen einem Netz und einem
Drittdienst, wobei der Drittdienst von außerhalb des Netzes bereitgestellt
wird. Der SCS umfasst Fähigkeiten
zum Empfangen einer Auslöseanforderung für mindestens
ein Ereignis von dem Drittdienst, wobei die Auslöseanforderung eine Referenz
zu dem mindestens einen Ereignis und eine Drittdienstreferenz umfasst.
Der SCS ist ferner in der Lage zum Kommunizieren mit einer Vorrichtung
in dem Netz, um einen Auslöser
in einer Auslösetabelle
der Vorrichtung hinzuzufügen,
wobei der Auslöser
der empfangenen Auslöseanforderung
entspricht, sowie zum Empfangen einer Mitteilung von der Auslösetabelle über ein
Vorkommen des mindestens einen Ereignisses, wobei die Mitteilung
die Drittdienstreferenz, die Referenz zu dem mindestens einen Ereignis
und eine Referenz zu mindestens einem Benutzer, der bei dem Drittdienst
innerhalb des Netzes registriert ist, umfasst. Der SCS ist weiterhin
in der Lage zum Informieren des Drittdienstes über die empfangene Mitteilung über das
Vorkommen des mindestens einen Ereignisses.
-
Ferner
betrifft die vorliegende Erfindung ein Verfahren zum Verwalten einer
Drittdienstregistrierungsinformation von innerhalb eines Netzes,
wobei der Drittdienst von außerhalb
des Netzes bereitgestellt wird, wobei das Netz und der Drittdienst über einen
Service Capability Server (SCS) miteinander in Wechselwirkung stehen.
Das Verfahren umfasst den Schritt des Empfangens einer Auslöseanforderung von
dem Drittdienst an dem SCS, wobei die Auslöseanforderung eine Referenz
zu einem Ereignis des Netzes und eine Referenz zu dem Drittdienst
umfasst. Das Verfahren umfasst weiterhin Schritte des Informieren
des Netzes über
die empfangene Auslöseanforderung
für das
Vorkommen des Ereignisses, und des Empfangens einer Mitteilung von
dem Netz an dem SCS. Die Mitteilungsanforderung umfasst eine Referenz
zu dem Drittdienst, eine Referenz zu mindestens einem Benutzer,
der bei dem Drittdienst innerhalb des Netzes registriert ist, und
eine Referenz zu dem Ereignis. Ferner umfasst das Verfahren den
Schritt des Informierens des Drittdienstes außerhalb des Netzes über die
empfangene Mitteilung über das
Vorkommen des Ereignisses.
-
In
einer optionalen Ausführungsform
der vorliegenden Erfindung umfasst der Schritt des Informierens
des Netzes weiterhin die Schritte des Analysierens einer existierenden
Dienstniveauvereinbarung (Service Level Agreement – SLA) zwischen
dem Netz und dem Drittdienst, und des Hinzufügens mindestens eines Auslösedatensatzes
in einer Vorrichtung des Netzes gemäß dem SLA.
-
Kurze Beschreibung
der Zeichnungen
-
Ein
umfassenderes Verständnis
der vorliegenden Erfindung ergibt sich aus der folgenden ausführlichen
Beschreibung in Verbindung mit den beiliegenden Zeichnungen. Es
zeigen:
-
1 einen
Signalflussablaufplan, der die Verwendung eines Service Capability
Servers (SCS) zur Steuerung der Wechselwirkung zwischen einem Drittdienst
und einem Netz darstellt;
-
2 eine
modulate Darstellung eines Service Capability Servers (SCS);
-
3 eine
modulate Darstellung einer Registrierungs- und Auslösevorrichtung;
und
-
4 eine
schematische Darstellung eines typischen Telekommunikationsnetzes,
die die erfindungsgemäße Verwendung
eines Service Capability Servers (SCS) zur Steuerung der Wechselwirkung zwischen
einem Drittdienst und einem Netz zeigt.
-
Ausführliche
Beschreibung der Erfindung
-
Die
vorliegende Erfindung betrifft die Verwaltung von Diensteilnahmeinformationen
bezogen auf Drittdienste, die Benutzern in einem Netz zur Verfügung gestellt
werden. Derzeit verwalten die Drittdienste Dienstteilnahmeinformationen
außerhalb
des Netzes. Während
den Drittdiensten die vollständige Steuerung
ihrer Registrierungen erlaubt ist, werden – wie oben erläutert – Probleme
verursacht. Die Erfindung verwendet einen Service Capability Server (SCS)
zum Steuern von Wechselwirkungen zwischen den Drittdiensten und
dem Netz. In dem Netz ebenfalls vorgesehen ist eine Vorrichtung
zum Verwalten einer Liste mit Benutzern, die für jeden der Drittdienste registriert
sind. Die Benutzerliste kann als Dienstteilnahmeinformation bezeichnet
werden. Die Vorrichtung verwaltet auch eine Liste mit Auslösern von Ereignissen
des Netzes, für
welche einer der Drittdienste einem der Netzbenutzer zur Verfügung gestellt
werden soll. Der SCS wird von der Vorrichtung zum Senden von Ereignismitteilungen
an die Drittdienste verwendet, und von den Drittdiensten zum Senden
von Auslöseanforderungen
an die Vorrichtung, wie im folgenden erläutert werden soll.
-
Mit
Bezug auf die Zeichnung zeigt die 1 einen
Signalflussablaufplan, der die Verwendung eines Service Capability
Servers (SCS) 120 zur Steuerung der Wechselwirkungen zwischen
einem Drittdienst 110 und einem Netz 105 darstellt.
Das Netz 105 umfasst mindestens einen Benutzer 140 und eine
Vorrichtung 130. Wie oben erwähnt, verwaltet die Vorrichtung 130 eine
Liste der Benutzer 140, die für den Drittdienst 110 registriert
sind. Die Vorrichtung 130 verwaltet ebenfalls eine Liste
mit Auslösern
von Ereignissen des Netzes 105, für welche der Drittdienst 110 den
registrierten Benutzern 140 zur Verfügung gestellt werden soll.
Der SCS 120 bezieht sich im Umfang der vorliegenden Anmeldung
auf Funktionalitäten,
die von einem Knoten des Netzes 105 durchgeführt werden,
und nicht speziell und lediglich auf Aufgaben, die von einem SCS
gemäß dem Stand der
Technik durchgeführt
werden, der dem Fachmann als SCS-Knoten bekannt ist.
-
Gemäß einem
ersten Aspekt nach der vorliegenden Erfindung fügt der Drittdienst 110 der
Liste mit Auslösern
der Vorrichtung 130 neue Auslöser hinzu. Hierzu sendet der
Drittdienst 110 eine Auslöseanforderung 150 an
den SCS 120. Die Auslöseanforderung 150 enthält eine
Referenz zu dem Drittdienst und eine Referenz zu einem Ereignis,
für welches
der Drittdienst 110 benachrichtigt werden muss. Es sei angemerkt,
dass die Referenz zu dem Drittdienst 110 eine Internetprotokoll-(IP)-Adresse oder aber
eine andere Kennung (Service_ID) sein kann, die sowohl vom Netz 105 als
auch dem Drittdienst 110 erkannt wird. Das Ereignis in
der Auslöseanforderung 150 ist mit
keinem der Benutzer 140 verknüpft, da der Drittdienst 110 keine
Kenntnis der Registrierung des Benutzers 140 hierauf hat.
Die Referenz zu dem Ereignis kann eine Kennung (Event_ID) sein,
die sowohl vom Netz 105 als auch dem Drittdienst 110 erkannt wird,
z.B. eine Nummer einer Textsequenz. Ferner kann die Auslöseanforderung
mehrere Referenzen auf mehrere Ereignisse enthalten. Ferner ist
es wichtig zu beachten, dass die Auslöseanforderung keine Referenzen
zu Benutzern des Netzes 105 enthalten muss.
-
Nach
Empfang der Auslöseanforderung 150 kommuniziert
der SCS 120 mit der Vorrichtung 130 über eine
Auslöseanforderung 152,
um der Auslöseliste
einen entsprechenden Auslöser
hinzuzufügen (Schritt 154).
Bei den meisten Implementierungen wird die Auslöseliste in einer Auslösetabelle
verwaltet, und die Liste der Benutzer 140 wird in einer
Registrierungstabelle verwaltet. Beide Tabellen befinden sich gewöhnlich in
einer Datenbank innerhalb der Vorrichtung 130. Der Schritt 154 des
Hinzufügens des
Auslösers
erfolgt normalerweise durch Erzeugen eines Auslösedatensatzes, der die Referenz
zu dem Drittdienst 110 und die Referenz zu dem Ereignis
enthält.
Der Auslösedatensatz
wird dann der Auslösetabelle
hinzugefügt.
-
Eine
weitere Möglichkeit
des Hinzufügens von
Auslösern
in die Auslösetabelle
ist das Analysieren einer existierenden Dienstniveauvereinbarung (Service
Level Agreement – SLA)
zwischen dem Drittdienst 110 und dem Netz 105.
Die SLA könnte beispielsweise
festlegen, dass der Drittdienst 110 standardmäßig über eine
gegebene Ereignisliste informiert werden soll. Die Ereignisliste
würde dann
der Auslöseliste
für den
entsprechenden Drittdienst 110 hinzugefügt werden.
-
Gemäß einem
weiteren Aspekt der vorliegenden Erfindung registriert sich der
Benutzer 140 über
die Vorrichtung 130 bei dem Drittdienst (Schritt 160).
Die Registrierung erfolgt durch Senden einer Registrierungsanforderung 162 an
die Vorrichtung 130. Die Registrierungsanforderung 162 enthält eine Referenz
zu dem Drittdienst 110 sowie eine Referenz zu dem Benutzer 140.
Die Referenz zu dem Benutzer 140 ist eine Kennung (User_ID),
die dem Benutzer 140 vom Netz 105 bereitgestellt
wird. Nach Empfang der Registrierungsanforderung 162 fügt die Vorrichtung 130 den
Benutzer 140 der Benutzerliste hinzu (Schritt 164).
Der Schritt 164 des Hinzufügens des Benutzers 140 erfolgt
normalerweise durch Erzeugen eines Registrierungsdatensatzes, der
die Referenz zu dem Drittdienst 110 und die Referenz zu
dem Benutzer 140 enthält,
sowie durch Hinzufügen
des Registrierungsdatensatzes zu der Registrierungstabelle. Es sei
angemerkt, dass die Reihenfolge, in welcher die Registrierung des
Benutzers 140 für
den Drittdienst 110 und das Hinzufügen des Auslösers in der
Vorrichtung 130 durch den Drittdienst 110 stattfinden,
austauschbar ist, ohne dass dabei eine Auswirkung auf die Lehren
der vorliegenden Erfindung auftritt.
-
Wird
im Netz 105 ein Ereignis erkannt (Schritt 170),
so überprüft die Vorrichtung 130,
ob einer der Auslöser
in der Auslöseliste
dem erkannten Ereignis entspricht. Ist dies der Fall, so wird eine
Ereignismitteilung 172 über
den SCS 120 an den Drittdienst 110 gesendet. Die
Ereignismitteilung 172 enthält eine Referenz zu dem erkannten
Ereignis, eine Referenz zu dem Drittdienst 110 sowie eine
Referenz zu dem Benutzer 140, der für den Drittdienst 110 registriert
ist. Sobald der SCS 120 die Ereignismitteilung empfängt, informiert
er den Drittdienst 110 über die
empfangene Ereignismitteilung mittels einer Ereignismitteilung 174.
Der Drittdienst 110 kann dann dem Benutzer 140 zur
Verfügung
gestellt werden (Schritt 180).
-
Bezug
sei nunmehr genommen auf die 2, die eine
modulare Darstellung des Service Capability Servers (SCS) 120 zeigt.
Der SCS 120 umfasst mindestens eine Anwendungsprogrammschnittstelle
(Application Program Interface – API) 210.
Die API 210 empfängt
Funktionsaufrufe, damit der SCS die hiermit empfangene Information
behandeln kann. Der SCS 120 umfasst ferner ein Kommunikationsmodul 220.
Das Kommunikationsmodul 220 kommuniziert mit dem Drittdienst 110 und
der Vorrichtung 130.
-
Bezug
sei nunmehr genommen auf die 3, die eine
modulare Darstellung einer Vorrichtung 130 zeigt. Die Vorrichtung 130 enthält eine
Registrierungstabelle 310 zum Verwalten der Liste der Benutzer 140,
die für
den Drittdienst 110 registriert sind. Die Registrierungstabelle 310 enthält einen
Registrierungsdatensatz 315 für jede Registrierung eines
jeden Benutzers 140. Jeder der Registrierungsdatensätze enthält die Referenz
zu dem Drittdienst 110 (Service_ID) und die Referenz zu
dem Benutzer 140 (User_ID). Die Vorrichtung umfasst ferner
eine Auslösetabelle 320 zum
Verwalten der Auslöseliste über Ereignisse
im Netz 105. Die Auslösetabelle
enthält
einen Auslösedatensatz 325 für jedes
Ereignis, über
welches der Drittdienst 110 informiert werden möchte. Jeder
der Auslösedatensätze 325 enthält die Referenz
zu dem Drittdienst 110 (Service_ID) und eine Referenz zu
dem Ereignis (Event_ID). Die Service_ID wird zum Verknüpfen mindestens
eines Auslösedatensatzes 325 mit
mindestens einem Registrierungsdatensatz 315 verwendet.
Nach Erkennen eines Ereignisses im Netz 105 (Schritt 170)
sammelt die Vorrichtung 130 einen oder mehrere Auslösedatensätze 325 entsprechend
dem erkannten Ereignis und sammelt einen oder mehrere entsprechende
Registrierungsdatensätze 315.
Die Datensätze 315 und 325 werden
dann von der Vorrichtung 130 zum Erzeugen der Ereignismitteilung 172 verwendet.
-
Bezug
sei nunmehr genommen auf die 4, die eine
schematische Darstellung eines typischen Telekommunikationsnetzes
zeigt, die die erfindungsgemäße Verwendung
des Service Capability Servers (SCS) 120 zur Steuerung
der Wechselwirkung zwischen dem Drittdienst 110 und dem
Netz 105 darstellt. Die 4 zeigt
eine Benutzer-Vorrichtung-Verbindungsstrecke 408, die die Übertragung der
Registrierungsanforderung 160 vom Benutzer 140 an
die Vorrichtung 130 ermöglicht. 4 zeigt ferner,
wie der Drittdienst 110 mit dem SCS 120 auf einer
Service-SCS-Verbindungsstrecke 410 kommuniziert.
Die Service-SCS-Verbindungsstrecke erlaubt die Übertragung der Auslöseanforderung 150 vom Drittdienst 110 an
den SCS 120. Gewöhnlich
empfängt
die API 210 die Auslöseanforderung 150.
Der SCS wiederum kommuniziert über
sein Kommunikationsmodul 220 auf einer SCS-Service-Verbindungsstrecke 412 mit
dem Drittdienst 110.
-
Die
SCS-Service-Verbindungsstrecke 412 ermöglicht es dem SCS 120,
den Drittdienst 110 über den
Empfang der Ereignismitteilung 172 mittels der Ereignismitteilung 174 zu
informieren. Die 4 zeigt weiterhin, wie die Vorrichtung 130 über eine Vorrichtung-SCS-Verbindungsstrecke 414 mit
dem SCS 120 kommuniziert und so die Übertragung der Ereignismitteilung 172 ermöglicht.
Eine SCS-Vorrichtung-Verbindungsstrecke 416 wird vom Kommunikationsmodul 220 des SCS 120 verwendet,
um die Vorrichtung 130 über
die Auslöseanforderung 150 mittels
der Auslöseanforderung 152 zu
informieren. Während
hier direkte Verbindungen bestehen können, bestehen die Verbindungsstrecken 408 bis 416 gewöhnlich aus
mehreren Verbindungsstrecken zwischen Telekommunikationseinrichtungen,
z.B. Routern, Brücken
oder Basisstationssteuerungen (Base Station Controllers – BSC).
Beispielsweise kann die Benutzer-Vorrichtung-Verbindungsstrecke 408 aus einer
Luftverbindung zu einer Basisstation (BS) oder Antenne, einer physikalischen
Ethernet-Verbindungsstrecke von der BS an eine BSC und einer optischen
physikalischen Verbindungsstrecke von der BSC an die Vorrichtung 130 bestehen.
Was die SCS-Service-Verbindungsstrecke
betrifft, so kann diese aus einer optischen physikalischen Verbindungsstrecke
vom SCS an einen Router und einer Ethernet-Verbindungsstrecke vom Router an den Drittdienst 110 bestehen.
Jede der Verbindungsstrecken 408 bis 416 kann
auch den gemeinsamen Standort von zwei Telekommunikationseinrichtungen darstellen.
Es versteht sich, dass die vorstehenden Beispiele als solche aufgezeigt
wurden und die Verwendung anderer Verbindungsstreckenzusammensetzungen
mit Blick auf die vorliegende Erfindung nicht einschränken.
-
Die
innovativen Lehren der vorliegenden Erfindung sind mit besonderem
Bezug auf zahlreiche beispielhafte Ausführungsformen beschrieben worden.
Es versteht sich jedoch, dass diese Klasse von Ausführungsformen
lediglich einige wenige Beispiele aus vielen vorteilhaften Verwendungsmöglichkeiten der
innovativen Lehren gemäß der Erfindung
aufzeigt. Im allgemeinen schränken
die in der Beschreibung der vorliegenden Erfindungen gemachten Angaben
die verschiedenen beanspruchten erfindungsgemäßen Aspekte nicht notwendigerweise
ein. Ferner können
sich einige der Angaben auf Erfindungsmerkmale beziehen, jedoch
nicht auf andere. In den Zeichnungen sind in den mehreren Ansichten
gleichartige oder ähnliche
Elemente mit identischen Bezugszeichen bezeichnet, und die gezeigten
unterschiedlichen Elemente sind nicht notwendigerweise maßstabsgetreu.