DE10311074A1

DE10311074A1 - Verfahren und Anordnungen in einem Telekommunikationsnetz

Info

Publication number: DE10311074A1
Application number: DE10311074A
Authority: DE
Inventors: De Miguel Angel Boveda; Hernandez Manuel Lorenzo; Jens Jonsson; Anders Eriksson; Ingvar Berg; Lars Jensen
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2002-04-25
Filing date: 2003-03-13
Publication date: 2003-12-11
Also published as: JP4088549B2; CN1453956A; SE0201287D0; JP2003333182A; GB2387990B; ITMI20030818A1; US20040039807A1; CN1453956B; GB0305838D0; ITMI20030653A1; GB2387990A; KR20030084582A; KR100989479B1

Abstract

Die vorliegende Erfindung betrifft eine Anordnung und ein Verfahren zum Bereitstellen einer Integration unterschiedlicher Daten, die unterschiedliche Dienste betreffen, in einem Kommunikationsnetz mit einer Vielzahl von Diensteanbietern und Diensteeinrichtern. Das System gemäß der Erfindung stellt eine gemeinsame Teilnehmer/Benutzer-Datenbank (300) und Teilnehmer/Benutzer-Datensätze (803) mit Benutzer- und Teilnehmerinformation bereit. Die Teilnehmer/Benutzer-Datensätze umfassen: Zumindest ein Identifikationsfeld (805, 810), das einen Teilnehmer und einen Benutzer identifiziert; und zumindest ein Dienstefeld (635, 640), das zumindest einen ausgewählten Dienst aus der Vielzahl von Diensten spezifiziert, die in einem Dienstenetz (200) bereitgestellt sind, wobei der zumindest eine ausgewählte Dienst von dem Benutzer oder Teilnehmer ausgewählt ist. Zumindest eines des zumindest einen Dienstefelds stellt Verbindungen zu angegliederten Daten (860) bereit, die den Teilnehmer/Benutzer betreffen, und die außerhalb der gemeinsamen Teilnehmer/Benutzer-Datenbank gespeichert sind.

Description

Gebiet der Erfindung

Die vorliegende Erfindung betrifft allgemein das Gebiet einer Datenverteilung in Kommunikationsnetzen, und insbesondere eine Integration unterschiedlicher Daten, die unterschiedliche Dienste betreffen, in ein Kommunikationsnetz mit einer Vielzahl von Diensteanbietern und Diensteeinrichtern.

Hintergrund der Erfindung

In herkömmliche Weise sind Kommunikationsnetze wie etwa Mobiltelefonnetze (PLMN), Festnetze (PSTN) und Datenkommunikationsnetze getrennte Systeme gewesen. Die Telekommunikationsnetze sind als vertikal integriert gekennzeichnet worden, was bedeutet, dass Anwendungen und Dienst eng mit der Technik eines Transports verbunden sind. Das Mobilsystem GSM stellt beispielsweise einen Satz von Diensten und Anwendungen bereit, deren Auftreten, Vorteile und Einschränkungen zumindest in hohem Maße durch die Kommunikationstechnik vorgegeben ist. Ein Festnetz (PSTN) hat einen unterschiedlichen Satz von Diensten und Anwendungen bereitgestellt, die eng mit der Kommunikationstechnik, die in dem System verwendet wird, verbunden sind, und die Dienste unterscheiden sich in einem Gebrauch und einem Auftreten von einem ähnlichen Dienst in einem PLMN. Dienste, die dem Endnutzer ähnlich erscheinen, können aufgrund der gleichen engen Verbindungen mit der Technik sehr unterschiedlich in den unterschiedlichen Netzen implementiert sein.
Die enge Verbindung zwischen den Diensten und der Kommunikationstechnik ist zusätzlich ein wichtiger Grund für die Tatsache gewesen, dass der Netzbetreiber auch der dominierende Anbieter von Diensten für den Endnutzer gewesen ist. Um einen Dienst bereitzustellen, ist eine Kenntnis von, und ein Zugriff auf das vollständige Netz ausschlaggebend gewesen. Ein vertikal integriertes Netz ist in Fig. 1 veranschaulicht.
Es besteht ein zunehmender Bedarf nach einer größeren Variation von Diensten, komplexen Diensten und danach, einen Wettbewerb unter Diensteanbietern zuzulassen. Gleichzeitig haben sich Tele- und Datenkommunikationsnetze entwickelt. Die neuen Generationen von Kommunikationssystemen integrieren unterschiedliche Kommunikationstechnologien wie etwa Mobiltlefonie und IP-basierte Datenkommunikation. Die neuen System werden oft als horizontal geschichtet veranchaulicht, mit z. B. einer Zugriffsschicht, einer Kernschicht und einer Dienstschicht. In Fig. 2 ist ein geschichtetes Kommunikationssystem dargestellt. In diesem Szenario wechselwirken vorhandene und neue Teilnehmer, beispielsweise Betreiber, Diensteanbieter, Diensteeinrichter, Inhalteanbieter und Anwendungs-(Internet-)Diensteanbieter, um dem Endnutzer eine große Vielfalt von Diensten anzubieten. Die Dienste werden in der Diensteschicht angeboten und verwaltet, die die Form eines Netzes, des Dienstnetzes 200 aufweist. Das Dienstenetz 200 wechselwirkt mit dem Kernnetz 210, das typischerweise eine IP-Architektur aufweist und eine Transport- und Vermittlungsfunktionalität bereitstellt. Es ist möglich, von dem Kernnetz mit einer Vielzahl von Zugriffsnetzen zu kommunizieren. Die Zugriffsnetze können verschiedener Art sein, die Mobilsysteme 220 mit unterschiedlicher Kapazität und unterschiedlichen Eigenschaften wie etwa GSM oder UMTS, Festnetztelefonie (PSTN) 230, IP-basierte Datenkommunikation 240 und Kabel-TV 250 einschließen. Das Dienstenetz 200 weist vorzugsweise eine offene Architektur auf, beispielsweise eine offene Dienstearchitektur OSA und eine offene Schnittstelle, beispielsweise eine ASA-Anwenderprogrammschnittstelle API, um es so einer Vielzahl von Teilnehmern zu ermöglichen, zum Bereitstellen von Diensten für die Endnutzer wechselzuwirken. Ein Vergleich zwischen vertikal integrierten Netzen und geschichteten Netzen kann in der Ericsson Review Nr. 2,2001 gefunden werden.
Die angebotenen Dienste können vorzugsweise nach einer persönlichen Präferenz des Endnutzers, dem Zugriffsverfahren (Mobilsystem, Festsystem etc.), den Eigenschaften des Zugriffsanschlusses (z. B. der Kapazität eines Mobilanschlusses), dem Subskriptionstyp etc. maßgeschneidert werden. Obwohl das Zugriffsverfahren beispielsweise die Ausführung des Dienstes in dem Dienstenetz beeinflussen wird, werden viele Teile der Ausführung eines Dienstes ähnlich oder identisch ungeachtet von z. B. dem Zugriffsverfahren sein. Somit kann eine Diensteanbieter die gleichen "Aufbaublöcke" verwenden, um unterschiedliche Dienste, die für unterschiedliche Endnutzer ausgelegt sind, aufzubauen. Der Aufbaublock kann z. B. ein Adressdienst, ein Nachrichtendienst oder ein Positionierungswerkzeug sein. Die Offenheit der Dienstenetze wie auch die Möglichkeit, Aufbaublöcke für mehr als einen bestimmten Dienst zu verwenden, werden als Schlüsselfaktoren bei einem Anwerben von sowohl Teilnehmern wie Betreibern, Diensteanbietern und Diensteeinrichtern als auch Endnutzern wahrgenommen, um neue Dienste zu entwickeln bzw. zu benutzen.
Der angebotene Dienst wird von grundlegenden Telefondiensten, wie etwa einem Einrichten eines Anrufs zwischen zwei mobilen Teilnehmern, bis hin zu komplexen Diensten, die unterschiedliche Zugriffsnetze, eine oder mehrere Internetz- Anwendungen und Sicherheitsdienste einschließen, reichen.
Komplexe Dienste können Dienste unter Verwendung eines Positionierens, eines Benachrichtigens und von E-Handel einschließen. Ein Positionierungs-basierter Dienst könnte z. B. ein Hotel in der Nähe der Position des Endnutzers finden. Ein derartiger Dienst könnte ein Verwenden der Positionierungswerkzeuge des Mobilsystems über das Mobilpositionierungszentrum, eine oder mehrere Internetanwendungen zum Finden und Kategorisieren von Hotels in einem bestimmten Gebiet, Anwendungen, die die Information in ein Format transformieren, das für eine Präsentation an dem Anschluss des Endnutzers, z. B. WAP, geeignet ist und E-Handelanwendungen, die ein sicheres Buchen und Bezahlen eines Zimmers unterstützen, einschließen.
Ein weiteres Beispiel komplexer Dienste betrifft das, was als eine Flottenverwaltung bekannt ist. Eine Information über die Position jedes individuellen Nutzers in einer ausgewählten Gruppe von Nutzern wird einem oder sämtlichen der Nutzer in der Gruppe präsentiert. Die Position jedes Nutzers wird von dem Positionierungssystem bereitgestellt. Ein Benutzer kann auf dieser Weise eine aktualisierte Information über die Positionen sämtlicher anderen in der Gruppe erhalten. Dieser Typ von Diensten kann beispielsweise bei einem Verwalten einer Flotte von Zulieferfahrzeugen nützlich sein. Um derartige Dienste anzubieten und auszuführen, ist eine große Anzahl von Schnittstellen zwischen unterschiedlichen Dienstesystemen erforderlich, und da unterschiedliche Dienstesysteme von unterschiedlichen Diensteeinrichtern bereitgestellt werden können, sollte der Bedarf nach einem Dienstenetz und einem Dienstenetz, das eine offene Architektur und standardisierte Schnittstellen aufweist, offensichtlich sein.
Die Menge von Diensten, die in einem Dienstenetz von einer Menge von Diensteanbietern, -Einrichtern etc. bereitgestellt werden, die Endnutzer, die in unterschiedlichen Zugriffsnetzen und mit dem Bedarf nach personalisierten Diensten verteilt sind und unterschiedliche Arten einer Bezahlung werden den Bedarf nach korrekten Endnutzerdaten erhöhen, und ein unmittelbarer Zugriff auf diese Daten ist ausschlaggebend. In den heutigen Netzen sind Daten, die die Endnutzer betreffen, über das Netz verstreut, und in vielen Fällen werden redundante Endnutzerdaten gespeichert und verwendet. Das verstreute Speichern der Daten und die Redundanz macht es schwierig, die Endnutzerinformation wiederzugewinnen und zu aktualisieren. Es wird in den vorhandenen Netzen mit ihren verstreuten Endnutzerdaten sehr schwierig sein, eine stabile Funktionalität komplexer Dienste zu implementieren und sicherzustellen. Ein Nachteil in Bezug auf die verstreuten Endnutzerdaten kann vermöge des Beispiels eines Endnutzers veranschaulicht werden, der sein Abonnement für einen komplexen Dienst beendet, der beispielsweise auf einem Positionierungsdienst beruht. Sämtliche Daten, die diesen Teilnehmer betreffen, werden dann von dem Dienstesystem entfernt, das den Positionierungsdienst bereitstellt. Der Endnutzer kann es dennoch wünschen, andere komplexe Dienste zu verwenden, die das Positionieren verwenden, aber da die den Endnutzer betreffenden Daten von dem Dienstesystem, das den Positionierungsdienst bereitstellt, entfernt worden sind, werden dem anderen komplexen Dienst ausschlaggebende, auf den Endnutzer bezogene Daten fehlen. Die komplexen Dienste können in manchen Fällen möglicherweise nicht ausgeführt werden, und in anderen Fällen wird, wenn die Endnutzerdaten noch von irgendwo in dem Netz wiedergewonnen werden können, die Ausführung des komplexen Dienstes verzögert sein und/oder zu einer erhöhten Verkehrslast führen.
Überdies kann ein Benutzer durch unterschiedliche IDs, Namen oder Alias in Abhängigkeit von dem Dienst identifiziert werden. Beispielsweise kann eine Telefonnummer eines Benutzers von herkömmlichen Telefondiensten, eine E-Mail- Adresse von E-Mail-Kommunikations-basierten Diensten und ein Benutzer-Alias von Kalender-basierten Diensten verwendet werden. Ein komplexer Dienst kann es erfordern, auf Benutzerdaten mit unterschiedlichen Einrichtungen einer Identifikation zuzugreifen, und wenn die Benutzerdaten verstreut sind, muss jeder komplexe Dienst sämtliche Benutzeridentitäten speichern und aktualisieren.
Die Probleme mit einer vorhandenen Handhabung von Endnutzerdaten können wie folgt zusammengefasst werden:

a) Auf die Endnutzerdaten, die einen Dienst betreffen, kann nicht unmittelbar zugegriffen werden, und es kann, um auf vollständige Endnutzerdaten zuzugreifen, sehr schwierig und zeitaufwendig sein,
b) Es ist nicht einfach, eine Information darüber zu erlangen, wie sich ein Dienstesystem auf ein anderes Dienstesystem bezieht, so dass, wenn z. B. Endnutzerdaten geändert werden, keine Kenntnis vorhanden ist, wie andere Dienstesysteme beeinflusst werden,
c) Das Verbreiten von Endnutzerdaten und der Mangel an Kenntnis der Beziehungen zwischen unterschiedlichen Dienstesystemen schwächt die Datenkonsistenz beträchtlich und erhöht die Verkehrslast in den Systemen.

Zusammenfassung der Erfindung

Die objektive Aufgabe besteht darin, in einem Dienstenetz zum Bereitstellen eines komplexen Dienstes und/oder einer Menge von Diensten, ein Verfahren, ein System und Speichereinheiten bereitzustellen, die zum Speichern von und zum Zugreifen auf Endnutzer- und Teilnehmer-Daten ausgelegt sind, derart, dass ein unmittelbarer Zugriff auf die Daten sichergestellt ist und die Konsistenz der Daten aufrechterhalten wird.
Die Aufgabe wird durch das System nach Anspruch 1, den Datensatz nach Anspruch 15, das Verfahren nach Anspruch 35 und das Computerprogrammprodukt nach den Ansprüchen 40 und 41 gelöst.
Das System gemäß einer Ausführungsform der Erfindung stellt eine gemeinsame Teilnehmer/Benutzerdatenbank und Teilnehmer/Benutzerdatensätze mit einer Benutzer- und Teilnehmerinformation bereit. Der Teilnehmer/Benutzerdatensatz umfasst: zumindest ein Identifikationsfeld, das einen Teilnehmer und einen Benutzer identifiziert; und zumindest ein Dienstefeld, das zumindest einen ausgewählten Dienst von der Vielzahl der Dienste, die dem Dienstenetz bereitgestellt sind, spezifiziert, wobei der zumindest eine ausgewählte Dienst von dem Benutzer oder dem Teilnehmer ausgewählt wird. Zumindest eines des zumindest einen Dienstefelds ist ausgelegt, um Verbindungen bereitzustellen, um Daten anzugliedern, die den Teilnehmer/Benutzer betreffen und die außerhalb der gemeinsamen Teilnehmer/Benutzerdatenbank gespeichert sind. Somit unterstützen die gemeinsame Teilnehmer/Benutzerdatenbank und die Teilnehmer/Benutzerdatensätze einen einzigen Zugriffspunkt zum Zugreifen auf Benutzer- und/oder Teilnehmer-Daten in dem Dienstenetz.
Gemäß einer weiteren Ausführungsform der Erfindung umfassen die Teilnehmer/Benutzerdatensätze zumindest zwei Dienstefelder: Ein Dienstesubskriptionsfeld, das eine erste Gruppe von Diensten spezifiziert, die für den Teilnehmer verfügbar sind, wobei die Dienste in der ersten Gruppe von Diensten aus der Vielzahl von Diensten ausgewählt werden, die in dem Dienstenetz bereitgestellt sind; und zumindest ein Diensteaktivierungsfeld, wobei jedes Diensteaktivierungsfeld einen durch den Benutzer aktivierten Dienst, der aus der ersten Gruppe von Diensten ausgewählt ist, spezifiziert. Das Dienstesubskriptionsfeld und/oder die Diensteaktivierungsfelder sind ausgelegt, um Verbindungen bereitzustellen, um Daten anzugliedern, die die Teilnehmer/Benutzer betreffen, und wobei die angegliederten Daten außerhalb der gemeinsamen Teilnehmer/Benutzerdatenbank gespeichert werden.
Der Datensatz, der zum Speichern und Aufrechterhalten von Benutzer- und Teilnehmerdaten in ein Dienstenetz ausgelegt ist, umfasst gemäß der vorliegenden Erfindung: Zumindest ein Identifikationsfeld, das einen Teilnehmer und einen Benutzer identifiziert; und zumindest ein Dienstefeld, das zumindest einen ausgewählten Dienst aus der Vielzahl von Diensten, die in dem Dienstenetz bereitgestellt sind, spezifiziert, wobei der zumindest eine ausgewählte Dienst von dem Benutzer oder dem Teilnehmer ausgewählt wird. Zumindest eines des zumindest einen ausgewählten Dienstefelds ist ausgelegt, um Verbindungen bereitzustellen, um Daten anzugliedern, die den Teilnehmer/Benutzer betreffen, und die außerhalb der gemeinsamen Teilnehmer-/Benutzerdatenbank gespeichert sind.
Dank der Erfindung stellen die gemeinsamen Teilnehmer-/Benutzerdatenbank und die Benutzerdatensätze dadurch einen einzigen Zugriffspunkt zum Zugreifen auf Benutzer- und Teilnehmerdaten in dem Dienstenetz bereit. Somit ist ein rascher Zugriff auf Benutzerdaten sichergestellt, und da auf die Benutzerdaten nur über den einzigen Zugriffspunkt zugegriffen und möglicherweise etwas hinzugefügt, aktualisiert oder entfernt wird, kann eine Datenkonsistenz erreicht werden.
Das Verfahren gemäß einer Ausführungsform der Erfindung umfasst die Schritte:

- Zugreifen auf den einzigen Zugriffspunkt in dem Dienstenetz, der von dem System und dem Datensatz, der oben beschrieben ist, bereitgestellt ist;
- Anfordern, Daten von dem einzigen Zugriffspunkt zu lesen und/oder in diesen zu schreiben,
- Wiedergewinnen oder Übertragen von Daten von oder zu dem Benutzerdatensatz über den einzigen Zugriffspunkt.

Ein Vorteil, der durch das Verfahren gemäß der Erfindung erreicht wird, besteht darin, dass vorzugsweise sämtliche Anfragen nach Benutzer-/Teilnehmerdaten an eine Stelle, den einzigen Zugriffspunkt, in dem Dienstenetz gerichtet werden.
Ein weiterer Vorteil, der durch die Erfindung erreicht wird, besteht darin, dass Verbindungen, um Daten und Information anzufordern, die erforderlich ist, um auf die angegliederten Daten zuzugreifen, anzugliedern, von dem System gemäß der Erfindung bereitgestellt wird, indem das Verfahren gemäß der Erfindung zum Wiedergewinnen der Daten verwendet wird.

Definitionen

Dienstenetz (SN, Service Network) - entspricht der Diensteschicht in der horizontal geschichteten Ansicht eines Kommunikationssystems. Knoten und eine Vielzahl von Dienstesystemen, die notwendig sind, um dem Endnutzer Dienste bereitzustellen, werden als Teile des Dienstenetzes angesehen. Welche Knoten genau angesehen werden, zu dem Dienstenetz zu gehören, wird von der Implementierung abhängen. Bestimmte Knoten können auch zu mehr als einer Schicht/einem Netz gehören.
Dienstesystem - System zum Bereitstellen eines Dienstes, oder eines Teils eines Dienstes. Das Dienstesystem gehört typischerweise zu dem Dienstenetz. Ein Dienstesystem kann andere Dienstesysteme verwenden (mit diesen kommunizieren), um einem Endnutzer einen spezifischen Dienst bereitzustellen. Ein Dienstesystem kann einen oder mehrere unterschiedliche Dienste, oder eine Gruppe von Diensten bereitstellen.
Komplexer Dienst - ein Dienst, der mit zwei oder mehreren Dienstesystemen wechselwirken muss, um dem Endnutzer einen spezifischen Dienst bereitzustellen.

Kurze Beschreibung der Figuren

Die Merkmale und Vorteile der vorliegenden Erfindung, die obenstehend skizziert ist, werden untenstehend in der detaillierten Beschreibung in Verbindung mit den Zeichnungen vollständiger beschrieben werden, wobei gleiche Bezugszeichen durchweg gleiche Elemente bezeichnen.
In den Zeichnungen zeigen:
Fig. 1 eine schematische Zeichnung eines herkömmlichen, vertikal integrierten Netzes;
Fig. 2 eine schematische Zeichnung eines horizontal geschichteten Netzes, das ein Dienstenetz umfasst;
Fig. 3 eine schematische Zeichnung der gemeinsamen Benutzer-/Teilnehmerdatenbank, die in der vorliegenden Erfindung benutzt wird;
Fig. 4 eine schematische Zeichnung des einzigen Zugriffspunkts der vorliegenden Erfindung;
Fig. 5 die Beziehungen zwischen grundlegenden Einheiten der vorliegenden Erfindung;
Fig. 6 eine schematische Zeichnung des Benutzerdatenmodells gemäß der vorliegenden Erfindung;
Fig. 7 ein Beispiel, das das Benutzerdatenmodell gemäß der vorliegenden Erfindung verwendet;
Fig. 8 eine schematische Zeichnung des Benutzerdatensatzes gemäß der vorliegenden Erfindung; und
Fig. 9 eine schematische Zeichnung, die das Verfahren gemäß der vorliegenden Erfindung veranschaulicht.

Detaillierte Beschreibung der Erfindung

Ausführungsformen der Erfindung werden nun unter Bezugnahme auf die Zeichnungen beschrieben werden.
Die vorliegende Erfindung wendet sich den Problemen zu, die von dem Verteilen der auf einen Endnutzer bezogenen Daten über die Netze herrühren, indem ein einziger Zugriffspunkt (SAP, Single Access Point) für auf einen Endnutzer bezogene Daten in einem Dienstenetz bereitgestellt wird. Auf der höchsten Stufe umfasst ein SAP eine gemeinsame Teilnehmer- Benutzer-Datenbank (CSD, Common Subscriber-user-Database) und Datensätze, die innerhalb der CSD gespeichert sind. Die Datensätze speichern Benutzer-bezogene Daten und stellen Verbindungen mit anderen Sätzen bereit, die Benutzer-bezogene Daten speichern. Abhängigkeiten zwischen unterschiedlichen Dienstesystemen, die wechselwirken, um einen komplexen Dienst zu bilden, sind vorzugsweise auch in der CSD gespeichert. Die CSD ist von dem Dienstenetz 200 zugänglich und liegt typischerweise in dem Dienstenetz 200.
In Fig. 3 ist eine Rolle der CSD veranschaulicht. Benutzer- oder Teilnehmer bezogene Daten, auf die typischerweise von einer Vielzahl von Dienstesystemen zugegriffen wird, sind in der CSD 300 gespeichert. Auch sind in der CSD 300 Verbindungen gespeichert, die die Endnutzerdaten, die innerhalb der CSD 300 gespeichert sind, mit Endnutzerbezogenen Daten, die nicht in der CSD 300 gespeichert sind, verbinden, diese Daten, die als angehängte Daten bezeichnet werden, sind typischerweise für einen Dienst oder eine Gruppe von Diensten spezifisch, und nur für ein spezifisches Dienstesystem relevant. Ein Dienstesystem A 310, ein Dienstesystem B 320 und ein Dienstesystem C 330 sind Beispiele von Systemen in dem Dienstenetz 200, die einen Dienst oder eine Gruppe von Diensten bereitstellen. Eine Verbindung A 340, eine Verbindung B 350 und eine Verbindung C 360 veranschaulichen, dass die Datensätze innerhalb der CSD 300 Verbindungen oder Bezugnahmen auf die angegliederten Daten bereitstellen. Gemeinsame Benutzer- und Teilnehmerdaten sind in den Dienstesystemen A 310, B 320 oder C 330 nicht dupliziert, sondern in der CSD 300 gespeichert. Somit ist eine Datenkonsistenz sichergestellt.
In dem Fall eines komplexen Dienstes, der eine Verwendung von mehr als einem Dienstesystem, z. B. von den Dienstesystemen B 320 und C 330 erfordert, sind die Abhängigkeiten zwischen den beiden Systemen B und C in der CSD 300 gespeichert, was durch die Verbindung B + C 370 veranschaulicht ist. In einer Implementierung könnte das Dienstesystem A beispielsweise Verzeichnisdienste, das Dienstesystem B eine Positionierung von Mobilanschlüssen bereitstellen, und das Dienstesystem C könnte eine Internet-Anwendung zum Finden von Hotels, Taxis und Restaurants in einer Stadt sein. Das Dienstesystem B und das Dienstesystem B und das Dienstesystem C müssten dann wechselwirken, um einen Positions-basierten Dienst für den Endnutzer bereitzustellen.
In einem implementierten Dienstenetz wird die Anzahl von Dienstesystemen typischerweise viel größer als die hier veranschaulichte sein, und die Abhängigkeiten und Wechselwirkungen zwischen den Systemen können mehr als zwei Systeme einschließen. Somit sollte das obenstehende als ein nicht-einschränkendes Beispiel betrachtet werden. Ungeachtet der Anzahl von Systemen zum Bereitstellen von Diensten und komplexer Abhängigkeiten zwischen diesen Systemen sind gemeinsame Benutzer-bezogene Daten nicht dupliziert. Somit kann eine Datenkonsistenz sichergestellt werden. Der Aufbau der Datensätze, die innerhalb der CSD gespeichert sind und eine Datenkonsistenz ermöglichen, wird im Detail untenstehend beschrieben werden.
Die CSD wird in den meisten Realisationen eine sehr große Datenbank sein, da sie Benutzer-bezogene Daten für Endnutzer, die eine Vielzahl von Diensten verwenden, die von dem Dienstenetz angeboten werden, enthalten wird. Dies könnte durch Benutzung einer verteilten Datenbank, wie sie in Fig. 4 veranschaulicht ist, gehandhabt werden. Die Daten der CSD 300 sind auf mehrere Datenbanken 400 aufgeteilt, die in unterschiedlichen Einheiten enthalten sind. Eine CSD- Indextabelle 410 verbirgt die interne Verteilung der Daten in den Datenbanken 400. Die CSD-Indextabelle 410 kann in einer der Einheiten, die eine der Datenbanken umfasst, oder in einer getrennten Einheit gespeichert werden. Die Datenbanken 400 und die CSD-Indextabelle 410 sind mit einem Front-End 420 verbunden, das in Kombination mit den Datensätzen, die innerhalb der Datenbänke 400 gespeichert sind, eine Verwirklichung des SAP 430 ist. Das CSD-Front-End 420 empfängt alle Anfragen nach Daten, veranschaulicht durch den Teil in der Figur, und gewinnt die Daten aus den Datenbanken 400 durch die Verwendung der CSD-Indextabelle 410 wieder. Von außerhalb wird die CSD 300 als eine Datenbank mit einem Zugriffspunkt wahrgenommen werden, aber innerhalb kann eine große Anzahl getrennter Datenbanken 400 verwendet werden. Der detaillierte Aufbau der verteilten Datenbanken ist in dem Stand der Technik bekannt und deswegen in der vorliegenden Beschreibung weggelassen. Es sei darauf hingewiesen, dass die Einheiten, die hier beschrieben sind, als logische Einheiten zu betrachten sind. Wie erwähnt, können die Datenbanken verteilt und in physikalisch unterschiedlichen Einheiten bereitgestellt sein, aber die anderen Einheiten wie das CSD- Front-End 420 und die CSD-Indextabelle 410 können auch auf unterschiedliche Arten verwirklicht werden, einschließlich derjenigen, über physikalische getrennte Einheiten verteilt zu sein. Der Ausdruck einziger Zugriffspunkt SAP sollte auf eine begriffliche Weise verstanden werden, was einen logischen Zugriffspunkt für die Endnutzer bezogenen Daten in dem Dienstenetz bedeutet. Bei einer Verwirklichung muss das CSD-Front-End 420 befähigt sein, eine große Anzahl gleichzeitiger Zugriffe wie auch einen Zugriff durch unterschiedliche Einrichtungen und Verfahren einschließlich beispielsweise eines Zugriffs unter Verwendung einer IP- Adresse, einer HTML-Adresse, einer E.136-Adresse oder durch eine URL handzuhaben.
Die Benutzer-bezogenen Daten, die in der CSD 300 gespeichert sind, sind um drei grundlegende Einheiten herum aufgebaut. Die drei Einheiten, der Teilnehmer, der Benutzer und der Dienst, und ihre Beziehungen sind in Fig. 5 veranschaulicht. Die Einheit Teilnehmer 510 abboniert einen oder mehrere Sätze oder Pakete von Diensten 525, die in dem Dienstenetz bereitgestellt sind. Der Teilnehmer 510 besitzt einen oder mehrere Benutzer 505. Die Benutzer 505 sind diejenigen, die aus einem Dienst 520 aktiv Nutzen ziehen. Der Benutzer kann nur Dienste benutzen, die zu einem Satz von Diensten 525 gehören, die der Teilnehmer 510 abboniert. Der Benutzer 505 wird immer zu einem Teilnehmer 510 gehören müssen. Der Teilnehmer 510 wird immer eine oder mehrere Benutzer 505 besitzen. In vielen Fällen wird der Teilnehmer 510 und der Benutzer 505 die gleiche Person sein, aber es kann für z. B. einen Geschäftsteilnehmer der Teilnehmer die Firma sein, und die Benutzer werden die Angestellten der Firma sein.
Auf einer begrifflichen Stufe sind die Datenidentifizierenden Benutzer, Teilnehmer und Dienste und Definitionen der Beziehungen zwischen diesen Einheiten gemäß eines Datenmodells aufgebaut, das als das Benutzerdatenmodell bezeichnet wird. Das Benutzerdatenmodell UDM (User Data Model) umfasst tatsächliche Benutzer-bezogene Daten und Dienste-bezogene Daten wie auch die Endnutzersubskriptionen zu den Diensten. Es ist auch das Modell, das als das Schlüsselelement in dem Dienstenetz wirkt, das verantwortlich ist, den Benutzerkontext in den Diensten wiedergewinnbar und verwaltbar auszuführen, indem Bezugnahmen auf die Speicherplätze für die angegliederten Daten gehalten werden. In der vorliegenden Erfindung sind die Endnutzer ezogenen Daten, die in der CSD 300 gespeichert sind, gemäß den Prinzipien des Benutzerdatenmodells aufgebaut. Die sich ergebenden Datenbänke werden als Benutzerdatenbänke UDR (User Data Records) bezeichnet, die in der CSD 300 gespeichert sind. Die Bezugnahmen auf Speicherplätze für angegliederte Daten entsprechen den Verbindungen 340, 350, 360 von den Sätzen in der CSD 300 zu den Teilen der Benutzer-bezogenen Daten, die in den Systemen A, B und C gespeichert sind, um die Dienste 310, 320, 330 bereitzustellen. Der UDR kann auch Verbindungen zu anderen Typen von Daten, beispielsweise einer Information über verfügbare Dienste und ihrer Eigenschaften umfassen.
Das Prinzip des Benutzerdatenmodells wird unter Bezugnahme auf Fig. 6 beschrieben werden. Der Benutzerdatensatz UDR wird nach den Prinzipien des UDM aufgebaut werden. Der Aufbau der Daten, die in der CSD 300 gespeichert sind, muss sorgfältig ausgelegt werden, um eine interne Replikation der Daten zu vermeiden, korrekte Verbindungen zu den Systemen zum Bereitstellen von Diensten bereitzustellen und die benötigten Daten auf die logischte Weise aufrechtzuerhalten. Die Daten sind logisch in Objekte gruppiert, wobei die Schlüsselobjekte der Teilnehmer, der Benutzer und der Dienst sind, in Übereinstimmung mit den Haupteinheiten, die oben beschrieben sind. Die Pfeile in der Figur zeigen Verbindungen zwischen den Objekten an. Die Implementierung kann in Abhängigkeit von der Technologie, die verwendet wird, um die CSD aufzubauen, variieren, aber das logische Gruppieren sollte das gleiche sein.
Die folgenden Objekte sollten vorzugsweise von dem UDM umfasst sein:

- Benutzer 605: enthält grundlegende Benutzerinformation (z. B. Benutzeridentitäten). Ein Benutzer 605 gehört immer zu einem Teilnehmer 610;
- Teilnehmer 610: enthält grundlegende Teilnehmerinformation (z. B. Teilnehmeridentitäten);
- Kundensegment 615: verwendet, um Teilnehmer 610 zu klassifizieren. Enthält Kundensegmentbeschreibung und grundlegende Daten;
- Angebotener Dienst 620: enthält grundlegende Diensteinformation;
- Dienstepaket 625: verwendet, um angebotene Dienste 620 zusammenzupacken;
- Dienstepaket-Subskription 630: verwendet, um eine wirksame Subskription für ein Dienstepaket 625 durch einen Teilnehmer 610 wiederzugeben;
- Dienstesubskription 635: verwendet, um wirksame Subskriptionen zu einzelnen Diensten 620 in einem Dienstepaket durch einen Teilnehmer, der durch die Dienstepaket-Subskription 630 spezifiziert ist, wiederzugeben;
- Dienstaktivierung 640: verwendet, um eine wirksame Aktivierung zu einem einzelnen Dienst von der Dienstesubskription 635 durch einen Benutzer 605 wiederzugeben;
- Teilnehmer-geteilte Ressource 645: enthält grundlegende Daten der geteilten Ressource, die in einem bestimmten Dienst verwendet werden, der von einem Teilnehmer 610 abboniert ist und von der Dienstesubskription 635 spezifiziert ist. Eine geteilte Ressource ist jedwedes System zum Bereitstellen eines Dienstes, der benötigt wird, um eine Diensteausführung durch ein anderes Dienstesystem zu unterstützen;
- Benutzer-geteilte Ressource 650: enthält grundlegende Daten der geteilten Ressource, die in einem bestimmten Dienst verwendet wird, der von einem Benutzer 605 aktiviert 640 wird. Diese geteilte Ressource ist jedwedes System, das benötigt wird, um eine Diensteausführung von einem anderen Dienstesystem zu unterstützen.

Das Benutzerobjekt 605 und das Teilnehmerobjekt 610 sind Beispiele von Identifikationsobjekten. Das Dienstesubskriptionsobjekt 635 und das Diensteaktivierungsobjekt 640 sind Beispiele von Diensteobjekten. Sämtliche Dienste, die in dem Netz 200 vorhanden sind, sind durch das UDM bekannt. Der Teilnehmer 610 kann dann einen Dienst abbonieren. Das Objekt, das von dem Dienst 620 angeboten wird, enthält eine Information über sämtliche der angebotenen Dienste und kann Bezugnahmen auf Dienste-bezogene Daten, die in anderen Systemen gespeichert sind, halten. Vorzugsweise ist die detaillierte Information über eine Vielzahl von Diensten in einer gemeinsamen Dienstedatenbank gespeichert. Die gemeinsame Dienstedatenbank enthält detaillierte Information über die Dienste, und der Inhalt des angebotenen Diensteobjekts 620 stellt eine Spezialisierung der Diensteinformation, die für einen Benutzer ausgelegt ist, dar. Der angebotene Dienst 620 kann somit als der Kontaktpunkt zwischen der CSD 300 und der gemeinsamen Dienstedatenbank angesehen werden. Ein Teilnehmer 610 könnte Dienste nacheinander abbonieren, aber dies würde das Bereitstellen mühsam machen. Vorzugsweise sind ähnliche Dienste, oder ein Dienst, der wahrscheinlicher Weise von dem gleichen Teilnehmer angefordert wird, zusammen gruppiert, was in dem Objektdienstepaket 625 wiedergegeben wird. Ein bestimmter Dienst kann in einer Vielzahl von Dienstepaketen angeboten werden. Zusätzlich kann ein Dienstepaket einer Gruppe von Teilnehmern mit den gleichen Eigenschaften und erwarteten Bedürfnissen angeboten werden. Somit können Teilnehmer 610 in ein Kundensegment 615 gruppiert werden, und der Teilnehmer 610 kann sämtliche Dienste abbonieren, die dem Kundensegment angeboten werden, zu dem er gehört. Ein Dienst wird zu einem Kundensegment hinzugefügt, indem er in ein oder mehrere Dienstepakete 625 eingeschlossen wird. In Kürze gruppiert das Dienstepaket 625 angebotene Dienste 620, und das Kundensegment 615 gruppiert Teilnehmer 610.
Der Teilnehmer 610 abboniert Dienste, die seinem Kundensegment angeboten werden, in der Form von Dienstepaketen 625, nicht in der Form von einzelnen Diensten. Wenn es erforderlich ist, dass ein Dienst getrennt angeboten wird, muss er in ein Dienstepaket 625 eingeschlossen werden. Die Objekt-Dienstepaket-Subskription 630 hält die Information der Dienstepakete, welcher der Teilnehmer abboniert, und die Objektdienstesubskription 635 hält Information über die eingeschlossenen, einzeln angebotenen Dienste 620. Diese sind die Dienste, die dem einzelnen Benutzer 605 angeboten werden. Der Benutzer kann wählen, sämtliche der Dienste, die der Teilnehmer abboniert, zu benutzen, aber höchstwahrscheinlich wird der Benutzer eine Auswahl von Diensten treffen. Die Benutzerwahl von Diensten ist in der Objektdienstaktivierung 640 enthalten. Die Objektdienstaktivierung enthält Bezugnahmen auf die angegliederten Daten.
Ein komplexer Dienst erfordert oft eine Beteiligung von zwei oder mehreren Systemen zum Bereitstellen von Diensten, wie beispielsweise in dem zuvor beschriebenen Beispiel zum Buchen eines Hotels. Ein Positionierungs-basierter Dienst würde typischerweise das System des Mobilpositionszentrums MPC und dem Heim-Teilnehmerserver HSS, wo das Profil des Benutzers für das Mobilnetz (Zugriffsnetz) gespeichert ist, einschließen. Die Systeme wie MPC und HSS sind ein Beispiel von geteilten Ressourcen oder Diensteeinrichtern. Die Objekteteilnehmer-geteilte Ressourcen 645 und Benutzergeteilte Ressourcen 650 enthalten die Abhängigkeiten zwischen unterschiedlichen Systemen, um einen komplexen Dienst bereitzustellen, und die Bezugnahmen auf die angegliederten Daten dieser Systeme. Die spezifizierten Abhängigkeiten verhindern, dass Daten, die für ein Dienstesystem erforderlich sind, von einem anderen geändert oder entfernt werden, beispielsweise, dass ein Dienstesystem, das das MPC verwendet, die Subskription/Aktivierung des MPC beendet, wenn ein anderer Dienst die Subskription/Aktivierung benötigt, um seinen komplexen Dienst durchzuführen.
Ein weiteres Beispiel einer geteilten Ressource, die von einer Vielzahl komplexer Dienste benutzt wird, ist ein Kalender. Ein Benutzer wünscht typischerweise nur einen Kalender, der sämtliche Einträge ungeachtet dessen zeigt, wie die unterschiedlichen Einträge geschaffen worden sind. In dem obigen Beispiel zum Buchen eines Hotels greift der Dienst, der ein Hotel bucht, vorzugsweise auch auf den Kalender zu, um die Reservation automatisch einzugeben. Der Benutzer verwendet den gleichen Kalender, um Meetings zu buchen, sich an Geburtstage zu erinnern, etc. In einem Geschäftsszenario kann es ein Teilnehmer wünschen, dass sämtliche seiner Benutzer auf einen gemeinsamen Kalender Zugriff haben, oder auf jeweils andere Kalender, um befähigt zu sein, Funktionen zu verwenden, die beispielsweise automatisch überprüfen, wenn eine Gruppe von Benutzern frei ist, ein Meeting abzuhalten. Somit kann der Dienst "Kalender" in Abhängigkeit von der Verwendung als ein einzelner Dienst oder ein "Aufbaublock" oder ein Diensteeinrichter für komplexe Dienste betrachtet werden.
In einer alternativen Ausführungsform der vorliegenden Erfindung sind die Abhängigkeiten zwischen Diensten, um einen komplexen Dienst zu bilden oder die Verwendung einer geteilten Ressource nicht innerhalb der CSD geteilt, sondern in der gemeinsamen Dienstedatenbank. In dieser Ausführungsform sind die Abhängigkeiten zwischen Diensten auf einer Stufe pro Dienst in der gemeinsamen Dienstedatenbank, nicht auf einer Benutzer-/Teilnehmerstufe in der CSD gespeichert. Durch diese alternative Anordnung müssen weniger Abhängigkeiten in dem Dienstesystem gespeichert werden, da die Abhängigkeiten für eine große Anzahl von Benutzern gemeinsam sein werden, und die Anzahl von Benutzern typischerweise die Anzahl von Diensten in hohem Maße übertrifft. Auf der anderen Seite muss die gemeinsame Dienstedatenbank adressiert werden, um Kenntnis über die Abhängigkeiten zwischen Diensten zu gewinnen, beispielsweise, wenn ein Benutzer einen komplexen Dienst deaktiviert. Um das Konzept aufrechtzuerhalten, nur einen Zugriffspunkt für sämtliche Benutzer/Teilnehmerbezogenen Daten aufzuweisen, wird der Zugriff auf die gemeinsame Dienstedatenbank vorzugsweise in den Fällen eines Überprüfens von Abhängigkeiten zwischen Diensten zum Zweck eines Aktualisierens von Benutzer/Teilnehmerdaten angeordnet, um den SAP sorgfältig auszuführen.
Das Dienstenetz kann Dienste für eine Vielzahl unterschiedlicher Zugriffsnetze unter Verwendung unterschiedlicher Kommunikationstechnologien bereitstellen, beispielsweise Schaltungs-vermittelte Mobilsysteme wie GSM, Paket-vermittelte Systeme wie GPRS oder kombinierte Systeme wie UMTS. Das UDM stellt einen Speicher von Information darüber bereit, welcher Zugriffsnetze ein Endnutzer benutzen kann, wie auch Benutzer-ids und Attribute für die Zugriffsnetzes.
Ein Beispiel, dass die Prinzipien des UDM veranschaulicht, wird unter Bezugnahmen auf Fig. 7 beschrieben werden. Die schematische Ansicht veranschaulicht einen Teilnehmer und zwei Benutzer, die einen Nutzen aus einigen Diensten ziehen, die in dem Dienstenetz angeboten werden. Dies dient dazu, das Beispiel klar zu halten und legt der Erfindung keine Einschränkungen auf. In Wirklichkeit verwendet ein Teilnehmer/Benutzer typischerweise eine große Anzahl von Diensten.
Die Richman-Familie sind Dienstenetz-Kunden, die für das Kundensegment 615 registriert sind: FamilienVIPS. Die Richman-Familie besteht aus Herrn Richman, Frau Richman und einem Junior, und der einzige, der berechtigt ist, Dienste zu abbonnieren, ist der Vater, Teilnehmer 615: Herr Richman. Ihr Kundensegment bietet ihnen ein Dienstepaket 625: Das Party- Paket und das Dienstepaket: Finanzen.
Der "Kasten" angehängte Daten 660 stellt sämtliche angehängten Daten dar, die an den Diensten teilnehmen. In diesem Fall die angegliederten Daten 660 für angebotene Dienste 620 Buche Limo und Buche Jet-Dienste, wie auch die angehängten Daten für die geteilte Ressource 650 MPC. Es sei darauf hingewiesen, das in diesem Beispiel der angebotene Dienst 620: Buche Limo ein Orts-basierter Dienst ist, deswegen abhängig von der Benutzer-geteilten Ressource 650 MPC.
Das Dienstepaket 625: Party-Paket ist das eine, das sie wirklich benötigen. So haben sie es gekauft, da es mit dem Vorhandensein des entsprechenden Dienstepaketobjekts wiedergegeben wird, das sich auf den Teilnehmer 610: Herr Richman und das Dienstepaket 625: Party-Paket bezieht. Ein Kaufen dieses Dienstepakets führt zu der Schaffung von drei Dienstesubskriptionen 635, eines pro angebotenen Dienst 620, der in dem Dienstepaket 625: Party-Paket eingeschlossen ist.
Auf der anderen Seite ist das Dienstepaket 625; Finanzen für diese Familie noch nicht so attraktiv, wie es aus der Tatsache hergeleitet werden kann, dass keine Dienstepaket- Subskription 630 für diesen Zweck in dem Bild ersehen werden kann.
Eine Benutzerin 605: Frau Richman ist berechtigt, den angebotenen Dienst 620: Buche Limo zu verwenden. Dies wird durch das Vorhandensein eines Diensteaktivierungsobjekts 640 dargestellt, das wiederum auf die Subskription 635 bezogen ist, die auf den angebotenen Dienst 620: Buche Limo bezogen ist. Es ist auch das entsprechende Benutzerdatenobjekt in der Buche Limo-Angliederung für den Benutzer: Frau Richman vorhanden. Man beachte, dass dies der einzige angebotene Dienst ist, den sie bisher nutzen kann, so dass, wenn sie an der Verwendung eines anderen Dienstes Interesse findet, dann ein neues Diensteaktivierungsobjekt 640 dementsprechend zu schaffen ist. Teilnehmer 610: Herr Richman muss seine Zustimmung dazu geben, da der die Rechnungen bezahlt.
Der andere Benutzer 605-Junior-, der vom Fliegen begeistert ist, ist berechtigt, den angebotenen Dienst 620: Buche Jet zu verwenden, der auch in dem Teilnehmerdienstepaket 625: Party- Paket eingeschlossen ist. Es ist auch das entsprechende Benutzerdatenobjekt in dem Buche-Jet-Angegliederten Daten für den Benutzer: Junior vorhanden. Man beachte bitte, dass dies der einzige angebotene Dienst ist, den er bisher verwenden kann, so dass, wenn er an einer Verwendung eines anderen Dienstes Interesse findet, dann ein neues Diensteaktivierungsobjekt 640 dementsprechend zu schaffen ist. Wieder muss Teilnehmer: Herr Richman seine Zustimmung dazu geben, da er schließlich die Rechnungen bezahlt.
Der dritte angebotene Dienst 620: Richte Party ein in dem Dienstepaket 625: Party-Paket ist für irgendeinen der Benutzer nicht abboniert worden, so dass weder ein Subskriptions-Aktivierungsobjekt noch Benutzerdaten in den angehängten Daten für diesen Dienst und diese Benutzer vorhanden sind.
Da der angebotene Dienst 620: Buche Limo ein Orts-basierter Dienst ist, ist der Benutzer: Frau Richman auch für die MPC vorgesehen worden, wie sie in dem Vorhandensein der entsprechenden Benutzer-geteilten Ressource 650 und dem Benutzerdatenobjekt in den MPC-Angegliederten Daten wiedergegeben ist.
Im Gegensatz dazu ist es erforderlich, dass der angebotene Dienst Buche Jet in einer geteilten Ressource vorgesehen ist, so dass kein Benutzer-geteiltes Ressourcenobjekt für den Benutzer: Junior, der sich auf diesen Dienst bezieht, geschaffen worden ist.
In diesem Beispiel sind weder Teilnehmerdatenobjekte in den angegliederten Daten noch Teilnehmer-geteilte Ressourcenobjekte vorhanden, da keiner der abbonierten Dienste in dem Beispiel eine gemeinsame Umgebung für seine unterschiedlichen Benutzer fordert (deswegen besteht in diesem Beispiel kein Bedarf, Teilnehmerdaten für irgendwelche angegliederten Daten bereitzustellen, obwohl die Erfindung diesen Typ eines Bereitstellens zulässt). In diesem Beispiel besteht die Rolle der Dienstesubskriptionsobjekte darin, einfach die Subskriptionen mit den angebotenen Diensten auf die sie bezogen sind, zu verbinden.
Die Benutzer-, Teilnehmer- und Dienstedaten, die in der CSD 300 gespeichert sind, sind gemäß des oben beschriebenen UDM aufgebaut. Ein sich ergebender Datensatz wird unter Bezugnahmen auf Fig. 8 beschrieben werden. In Fig. 8 zeigen Pfeile Abhängigkeiten zwischen Feldern, die dünneren Pfeile eine Eins-zu-Eins-Abhängigkeit und die dickeren Pfeile zeigen eine Abhängigkeit zwischen einer Vielzahl von Feldern an. Der Benutzerdatensatz UDR 803 wird ein Teilnehmerfeld 810 umfassen, das eine grundlegende Teilnehmerinformation, z. B. Teilnehmeridentitäten enthält. Ein oder mehrere Benutzerfelder 805 spezifizieren die Benutzer, die von dem Teilnehmer erfasst werden. Das Benutzerfeld 805 und das Teilnehmerfeld 810 sind Beispiele von Identifikationsfeldern. Ein Kundensegmentfeld 815 kennzeichnet den Teilnehmer und definiert, welche Dienstepakete dem Teilnehmer angeboten werden. Dienstepaketfelder 825, eines für jedes Paket, definieren die verfügbaren Dienstepakete, und verbunden mit jedem Dienstepaketfeld 825 sind Felder für angebotene Dienste (820), die grundlegende Diensteinformation für jeden getrennten Dienst enthalten. Das Dienstepaket- Subskriptionsfeld 830 definiert, welches Dienstepaket der Teilnehmer abonniert, und die Dienstesubskriptionsfelder 835, eines für jeden Dienst, definieren sämtliche der einzeln verfügbaren Dienste. Wie zuvor beschrieben, kann jeder Benutzer wählen, welche Dienste zu aktivieren sind (aus den Diensten der Diensteaktivierungsfelder 835), und jede Benutzerauswahl von Diensten ist in dem Diensteaktivierungsfeld 840 spezifiziert. Somit ist jedes Benutzerfeld 805 mit Diensteaktivierungsfeldern 840 verbunden. Die Diensteaktivierungsfelder 840 enthalten die Verbindungen zu angegliederten Daten, d. h. den Teil der Endnutzerdaten, die in dem Dienstesystem 340, 350, 360 gespeichert sind. Eine Verbindung kann vorzugsweise eine Adresse, z. B. eine IP-Adresse sein, zu dem Speicherplatz für angegliederte Daten. Das Dienstesubskriptionsfeld 835 und das Diensteaktivierungsfeld 840 sind Beispiele von Dienstefeldern. Wenn irgendeiner der Dienste, der von den Benutzern ausgewählt wird, die Verwendung von geteilten Ressourcen erfordert, d. h. mehr als ein komplexer Dienst verwendet das gleiche Dienstesystem, werden die Abhängigkeiten zwischen den Systemen wie auch die Verbindungen zu den angegliederten Daten, die in diesen Systemen gespeichert sind, in einem Benutzer-geteilten Ressourcenfeld 850 enthalten sein. Auf die gleiche Weise enthält ein Teilnehmer-geteiltes Ressourcenfeld 845 die Abhängigkeiten zwischen Systemen auf der Teilnehmerstufe.
Der UDR kann nicht nur die Verbindungen zu angegliederten Daten umfassen, sondern auch eine Information, die erforderlich ist, um auf die angegliederten Daten zuzugreifen oder um beispielsweise eine geteilte Ressource zu verwenden. Ein Beispiel einer derartigen Information sind die unterschiedlichen Einrichtungen zum Identifizieren eines Benutzers, die in unterschiedlichen Diensten verwendet werden. Herkömmliche Telefondienste verwenden typischerweise die Telefonnummer als das Identifizierungsmittel, ein E-Mail- Dienst verwendet eine E-Mail-Adresse und eine Kalenderfunktion verwendet einen Alias. Ein komplexer Dienst, in dem er dann unterschiedliche Dienstesysteme verwendet, einen oder mehrere dieser Einrichtungen zum Identifizieren eines Benutzers benötigen. Die unterschiedlichen Einrichtungen zum Identifizieren eines Benutzers müssen miteinander verbunden sein, eine sogenannte Identitätskarte. Dies wird durch das Datenmodell und dem Datensatz gemäß der Erfindung bereitgestellt, indem in der UDR die unterschiedlichen Einrichtungen einer Identifikation und zu welchem Dienst sie gehören eingeschlossen sind, vorzugsweise in den Feldern, die auch die Verbindungen zu dem Dienstesystem, d. h. dem Teilnehmer-geteilten Ressourcenfeld 845, dem Benutzer-geteilten Ressourcenfeld 850 und den Diensteaktivierungsfeldern 840 halten.
Der beschriebene Datensatz und das enthaltene Feld könnten auf mehrfache Weise verwirklicht werden, die in erster Linie von der Technologie abhängt, die in der Datenbank verwendet wird. Derartige Implementierungsdetails werden als für den Durchschnittsfachmann offensichtlich angesehen. Auch können andere Felder als die oben erwähnten Beispiele Verbindungen zu angegliederten Daten bereitstellen. Jedoch sollte, um die Implementierung einfach zu halten und eine Datenkonsistenz zu fördern, die Anzahl von unterschiedlichen Feldern, die derartige Verbindungen bereitstellen, vorzugsweise beschränkt werden, und Vorsicht ist angebracht, nicht unnötige und/oder duplizierende Verbindungen bereitzustellen.
Die Verbindungen, die in den Diensteaktivierungsfeldern 840 enthalten sind, das Teilnehmer-geteilte Ressourcenfeld 845 und das Benutzer-geteilte Ressourcenfeld 850 sind die einzigen Verbindungspunkte zwischen den Hauptbenutzerdaten, die in der CSD 300 gespeichert sind, und den angegliederten Daten der Dienstesysteme 340, 350, 360. Diese ist zum Aufrechterhalten der Konsistenz der Benutzerdaten wichtig. Die angegliederten Daten sollten nur innerhalb ihres Dienstesystems verwendet werden. Eine Anforderung nach Benutzer- und Teilnehmerdaten sollte an den einzigen Zugriffspunkt gerichtet werden, der vorzugsweise durch das CSD-Front-End 420 und den UDR 803, von welchem das CSD-Front- End 420 die Teilnehmer- und Benutzerdaten wiedergewinnt, verwirklicht werden.
In Übereinstimmung mit der zuvor beschriebenen alternativen Ausführungsform der vorliegenden Erfindung werden die das Benutzer-geteilte Ressourcenfeld 850 und das Teilnehmergeteilte Ressourcenfeld 845 nicht benötigt, wenn die Abhängigkeiten zwischen den Diensten in der gemeinsamen Dienstedatenbank gespeichert sind. Entsprechende Felder sind stattdessen innerhalb der Datensätze der gemeinsamen Dienstedatenbank bereitgestellt.
Auf den SAP kann zum Durchführen einer Datenverwaltung wie etwa einem Aktualisieren von Endnutzerdaten und für Echtzeitanwendungen wie etwa ein Wiedergewinnen von Daten, die notwendig sind, um einen Dienst durchzuführen, zugegriffen werden. Die Datenverwaltung umfasst eine Benutzerverwaltung, eine Teilnehmerverwaltung, eine Diensteverwaltung, eine Kundensegmentverwaltung, eine Dienstesubskription und -Aktivierung und eine Dienstepaketverwaltung. Echtzeitanwendungen treten während einer Ausführung einer Anwendung in einem Dienstesystem auf. Die Anwendung stellt beispielsweise einen Orts-basierten Dienst bereit. Die Anwendung muss dem Orts-basierten Dienst bestimmte Benutzerdaten bereitstellen, Daten, die von dem SAP wiedergewonnen werden. Ein weiteres Beispiel ist dann eine Anwendung, die Bezugnahmen auf angegliederte Daten und eine Kenntnis mancher der unterschiedlichen Benutzer-ids, Namen und Alias, die einem Benutzer zugeordnet sind, benötigt.
Das Verfahren zum Zugreifen auf Benutzer-Teilnehmerdaten gemäß der vorliegenden Erfindung unter Benutzung des SAP der vorliegenden Erfindung wird unter Bezugnahme auf die schematische Zeichnung der Fig. 9 beschrieben werden. Die Zugriffsfunktionalität wird hier durch einen Client 900 dargestellt, der die oben beschriebenen Datenverwaltungsfunktionen oder Echtzeitanwendungen durchführen kann. Detaillierte Beispiele sind in dem Unterabschnitt "Anwendungsfälle" untenstehend dargestellt. Die Verwendung des Clients wird typischerweise durch eine Anwendung in einem Dienstesystem zum Durchführen eines Dienstes oder durch eine Datenverwaltungsanwendung, die von einem Diensteanbieter oder einem anderen Teilnehmer in dem Dienstenetz initialisiert wird, initialisiert. Somit ist ein bestimmter Client oft aber nicht notwendiger Weise mit einem bestimmten Dienstesystem verbunden. Das Verfahren umfasst die Schritte:
910: Der Client greift auf den SAP über das CSD-Front- End 420 zu. Der Zugriff kann vorzugsweise eine Anforderungs- /Bewilligungsprozedur einschließen, um die Rechte zum Zugreifen auf die Datenverwaltungsfunktion, beispielsweise Lese- und/oder Schreiberlaubnis einzurichten.
920: Die Client-Anforderung, Daten von dem CSD-Front-End 420 zu lesen und/oder zu schreiben, in dem typischerweise auf einen Benutzer oder eine Teilnehmer-ID Bezug genommen wird.
930: Durch die Verwendung der CSD-Indextabelle 410 greift das CSD-Front-End 420 auf die korrekte Datenbank in der verteilten Datenbank zu; und
940: Das CSD-Front-End 420 gewinnt Daten aus dem UDR 803 wieder oder überträgt Daten zu diesem.
950: Das CSD-Front-End 420 gibt die angeforderten Daten zu dem Client zurück.
Das Verfahren kann wahlweise die Schritte umfassen:
955: Wenn der Client einen Zugriff auf Benutzerdaten benötigt, die nicht innerhalb des SAP gespeichert sind, d. h. die angegliederten Daten, wird auf den SAP zuerst gemäß der obigen Schritte zugegriffen. Von z. B. dem Diensteaktivierungsfeld 840 wird der Client mit einer Verbindung zu den angegliederten Daten und einer Information wie etwa einer Benutzer-id oder einem Benutzernamen versehen, die erforderlich sind, um auf die angegliederten Daten zuzugreifen.
960: Der Client greift auf den Speicherbereich für angegliederte Daten unter Verwendung der Information von dem SAP zu und fordert Benutzer-bezogene Daten an.
965: Der Speicherbereich für angegliederte Daten gibt die Benutzer-bezogenen Daten zu dem Client zurück.
Das Verfahren kann weiter wahlweise den Schritt umfassen:
970: Wenn der Client beabsichtigt, Benutzerdaten zu ändern, zu entfernen oder hinzuzufügen, sollte der UDR 803 nach Abhängigkeiten zwischen unterschiedlichen Dienstesystemen überprüft werden, d. h. in der beschriebenen beispielhaften Implementierung das Benutzer-geteilte Ressourcenfeld 850 und das Teilnehmer-geteilte Ressourcenfeld 845 nach Abhängigkeiten zwischen unterschiedlichen Dienstesystemen überprüft werden. Der Client wird, falls derartige Abhängigkeiten vorhanden sind, informiert, dass Benutzerdaten von anderen Dienstesystemen verwendet werden können und normalerweise nicht geändert oder entfernt werden sollten.
In Abhängigkeit von dem Typ der Verwaltungsaktion werden die Details jedes Schritts variieren. Das Schlüsselmerkmal, das die Änderung von Benutzer- und Teilnehmerdaten ist, wird auf den SAP gerichtet. Um die angegliederten Daten, die typischerweise in den Dienstesystemen gespeichert sind, zu ändern, wird auf den SAP zugegriffen, um eine Information darüber zu erhalten, wo geeignete angegliederte Datenspeicherplätze zu finden sind, d. h. eine Information, die in dem Diensteaktivierungsfeld 840, dem Benutzergeteilten Ressourcenfeld 850 und dem Teilnehmer-geteilte Ressourcenfeld 845 gegeben sind. Auf die angegliederten Daten wird dann direkt an ihrem Speicherplatz zugegriffen. Alternativ kann, wenn der SAP eine derartige Funktionalität bereitgestellt ist, auf die angegliederten Daten über den SAP zugegriffen werden.
Der Zugriff des Schritts 910 kann auf eine Anzahl unterschiedlicher Weisen durchgeführt werden, die die Verwendung einer IP-Adresse oder eine URL einschließen, und der SAP ist über das CSD-Front-End 420 befähigt, eine Vielfalt unterschiedlicher Zugriffsverfahren und unterschiedlicher Einrichtungen eines Zugriffs handzuhaben, wie auch eine Vielzahl von gleichzeitigen Zugriffen. Unterschiedliche Zugriffsverfahren sind in dem Stand der Technik bekannt.
Das oben beschriebene Verfahren gemäß der Erfindung kann als ein Computerprogrammprodukt oder ein Teil eines Computerprogrammprodukts verwirklicht werden. Das Computerprogrammprodukt wird beispielsweise auf einem Computer ausgeführt, der zu einem Dienstesystem in dem Dienstenetz 200 gehört.
Der SAP und das Verfahren gemäß der Erfindung ist beschrieben worden, sich über alle Dienste in einem Dienstenetz zu erstrecken. Dies ist eine bevorzugte Implementierung. Jedoch kann der SAP mit Dienstesystemen, die die Erfindung nicht benutzen, in einem Dienstenetz koexistieren, aber nur die Dienstesysteme, die den SAP verwenden, werden einen Nutzen aus den Vorteilen, die von der Erfindung geleistet werden, ziehen.
Während die Erfindung in Verbindung mit dem beschrieben worden ist, was gegenwärtig als die praktischten und bevorzugtesten Ausführungsformen angesehen werden, ist es zu verstehen, dass die Erfindung nicht auf die offenbarten Ausführungsformen beschränkt ist, sondern es ist im Gegenteil beabsichtigt, verschiedene Modifikationen und äquivalente Anordnungen abzudecken, die innerhalb des Grundgedankens und Umfangs der angehängten Ansprüche eingeschlossen sind.

Beispiele von Anwendungsfällen

In dem Beispiel bezieht sich der Ausdruck Administrator auf eine Verwaltungsfunktionalität in dem Dienstenetz und ein typisches Betreiben über einen Software-Client in einem Client-Server-Szenario.

Datenverwaltung

Benutzerverwaltung

Hole Benutzer

Erwartetes Ergebnis:
Information, die auf einen Benutzer in dem SN-Benutzerdatenmodell bezogen ist, wird wiedergewonnen.
Vorbedingungen:
Zumindest ein Benutzer muss vorhanden sein.
Beschreibung des Falls:
Ein Administrator muss eine Benutzerinformation wiedergewinnen und fordert sie von dem SAP an. Die angeforderte Information (Benutzerinformation und/oder Subskriptionsdaten und/oder Netzzugriffsdaten und/oder Benutzergeteilte Ressourcen) ist wiedergewinnbar, vorausgesetzt, dass der Administrator die richtige Erlaubnis hat, die zu lesen.
Mit dieser Information, die durch das SN-Benutzerdatenmodell bereitgestellt ist, kann das System, das von dem Administrator verwendet wird (beispielsweise ein Bereitstellungswerkzeug) es erfordern, eine Benutzer-Info außerhalb des SN- Benutzerdatenmodells wiederzugewinnen, das heißt, manche Speicherbereiche für angegliederte Daten erreichen, wo die tatsächlichen Subskriptions-Daten und/oder Benutzer-geteilten Ressourcendaten liegen. Zu diesem Zweck sollten die wiedergewonnenen Bezugnahmen (die Benutzer-ids und Diensteadressen bereitstellen), die den SN-SAP hält, zu diesen angegliederten Daten verfolgt werden, und das geeignete Datenadressprotokoll, das durch diese Angliederung veröffentlich ist, sollte verwendet werden.

Schaffe Benutzer

Erwartetes Ergebnis:
Ein neuer Benutzer wird definiert.
Vorbedingungen:
Zumindest ein Teilnehmer muss vorhanden sein. In dem Fall von privaten Benutzern wird der Bezugnahme in dem gleichen Prozess wie der Benutzer geschaffen.
Beschreibung des Falls:
Ein Administrator wünscht einen neuen Benutzer zu schaffen. Zu diesem Zweck gibt der Administrator die Basisdaten für den Benutzer ein und wählt einen Teilnehmer, dem der Benutzer zugeordnet werden wird. Ein neuer Benutzersatz wird dann in dem SAP geschaffen und einem Teilnehmer zugeordnet. Diese Zuordnung ist dem Prozess inhärent, da ein Benutzer nicht isoliert existieren kann, da er von genau den Subskriptionen, die von seinem Teilnehmer geschaffen sind, Gebrauch machen muss.

Entferne Benutzer

Erwartetes Ergebnis:
Ein spezifischer Benutzer und sämtliche seiner in Beziehung stehenden Informationen werden von dem SAP entfernt.
Vorbedingungen:
Zumindest ein Benutzer muss vorhanden sein.
Beschreibung des Falls:
Ein Administrator wünscht einen Benutzer von dem SAP zu löschen. Das System, das von dem Administrator verwendet wird (typischerweise ein Bereitstellungssystem) wird zuerst die Dienste-Referenzen und die Benutzer-geteilten Ressourcenreferenzen zu den Speicherbereichen für angegliederte Daten, wo Dienstedaten liegen, holen, um in jeden Speicherbereich zu gehen und die Benutzerdienstedaten zu entfernen, die in jedem gespeichert sind. Dann werden das Benutzerobjekt plus die Subskriptionsobjekte und/oder Netzzugriffsobjekte und/oder Benutzer-geteilten Ressourcenobjekte gelöscht werden.

Aktualisiere Benutzer

Erwartetes Ergebnis:
Ein Administrator modifiziert Benutzerdaten.
Vorbedingungen:
Zumindest ein Benutzer muss vorhanden sein.
Beschreibung des Falls:
Ein Administrator (könnte der Benutzer selbst sein) wünscht Benutzer-Basisdaten zu ändern (das einzige betroffene Objekt ist das Benutzer-Objekt). Benutzerobjektinformation wird in dem SAP aktualisiert.

Teilnehmerverwaltung

Hole Teilnehmer

Erwartetes Ergebnis:
Information, die sich auf einen Teilnehmer in dem SN- Benutzerdatenmodell bezieht, wird wiedergewonnen.
Vorbedingungen:
Zumindest ein Teilnehmer ist definiert worden.
Beschreibung des Falls:
Ein Administrator fordert eine auf eine Teilnehmer bezogene Info von dem SAP. Dies Information kann aus irgendeiner der folgenden bestehen:
Teilnehmer-Basisdaten, Dienstepaket- Subskription, Dienste- Subskriptionsdaten, Kundensegmentdaten, Teilnehmergeteilten Ressourcendaten, und eine Liste von Benutzern.
Mit dieser Information, die durch das SN-Benutzerdatenmodell bereitgestellt wird, kann es das System, das von dem Administrator (beispielsweise ein Bereitstellungswerkzeug) verwendet wird, erfordern, eine Teilnehmer- Info außerhalb des SAP wiederzugewinnen, das heißt, einige Speicherbereiche für angegliederte Daten zu erreichen, wo die tatsächlichen Dienste- Subskriptionsdaten und/oder Teilnehmer-geteilten Ressourcendaten liegen. Zu diesem Zweck sollten die wiedergewonnenen Referenzen (die Benutzer-ids und Dienste-Adressen bereitstellen), die den SAP hält, zu diesen angegliederten Daten verfolgt werden, und das geeignete Datenzugriffsprotokoll, das durch diese Angliederung veröffentlicht ist, sollte verwendet werden.

Diensteverwaltung

Hole Dienst

Erwartetes Ergebnis:
Ein angebotener Dienst wird von dem SAP geholt.
Vorbedingungen:
Zumindest ein Dienst ist definiert worden.
Beschreibung des Falls:
Ein Administrator fordert eine Info über angebotene Dienste von dem SN- SAP an. Die Daten, die in dem Diensteobjekt enthalten sind, werden wiedergewonnen.

Füge einen Dienst hinzu

Erwartetes Ergebnis:
Ein neuer angebotener Dienst ist bereit, verpackt zu werden.
Vorbedingungen:
Dienst ist entwickelt, eingesetzt und konfiguriert worden, das heißt, es ist ein angebotener Dienst vorhanden, dessen Information von anderen Teilen des SN verfügbar ist.
Beschreibung des Falls:
Um einen angebotenen Dienst zur Subskription verfügbar zu machen, besteht der erste Schritt darin, den SAP davon in Kenntnis zu setzen, indem ein Objekt eines angebotenen Dienstes geschaffen wird.
Bei einer Schaffung des angebotenen Dienstes muss die Vorlage für den angebotenen Dienst von dem Administrator bereitgestellt werden.

Kundensegnent

Hole Kundensegment

Erwartetes Ergebnis:
Ein Kundensegment und eine zugeordnete Information wird von dem SAP wiedergewonnen.
Vorbedingungen:
Zumindest ein Kundensegment muss vorhanden sein.
Beschreibung des Falls:
Ein Administrator kann es benötigen, typischerweise über ein Bereitstellungssystem, die Information, die einem Kundensegment zugeordnet ist, zu wissen. Eine derartige Information wird von dem SN-SAP angefordert, die die Kundensegmentinformation plus die Dienste Paketinformation, die dieser zugeordnet ist, sendet (sie schließt die Dienste ein, die in jedem Dienstepaket enthalten sind).
Variationen:
Zusätzlich kann die Liste von Teilnehmern, die zu diesem Kundensegment gehören, wiedergewonnen werden.

Schaffe Kundensegnent

Erwartetes Ergebnis:
Ein neues Kundensegment wird definiert, und Teilnehmer können diesem zugeordnet werden.
Vorbedingungen:
Zumindest ein Dienstepaket muss vorhanden sein.
Beschreibung des Falls:
Eine Kundensegmentation lässt eine Teilnehmerkategorisierung und eine Dienstegruppierung zu. Jeder Teilnehmer muss zu einem (Eins) Kundensegment gehören, daher müssen diese geschaffen werden, bevor Teilnehmer definiert werden.
Zu diesem Zweck schafft ein Administrator ein Kundensegment, indem einige der verfügbaren Dienstepakete diesem zugeordnet werden. Die Dienste, die in diesen Dienstepaketen enthalten sind, bilden den Dienst, der jedem Teilnehmer angeboten wird, der diesem neuen Kundensegment zugeordnet ist. Ein neues Kundensegmentobjekt wird in dem SAP hinzugefügt, verbunden mit den ausgewählten Diensten.

Dienste-Subskription & Aktivierung

Schaffe eine Subskription

Erwatetes Ergebnis:
Es wird möglich, einen bestimmten angebotenen Dienst für einen bestimmten Benutzer zu aktivieren. Siehe nächste 0.
Vorbedingungen:
Der Ausführende (Teilnehmer) hat bereits das Dienstepaket abonniert.
Beschreibung des Falls:
Der Teilnehmer wünscht es zu ermöglichen, dass ein Dienst aktiviert und von den Benutzern benutzt werden kann. Ein Subskriptionsobjekt muss geschaffen und dem angebotenen Dienst über die vorher vorhandene Benutzerunabhängige Dienstesubskription zugeordnet werden.
Eine Benutzerbereitstellung muss gemäß dem angegliederten Bereitstellungsvertrag und durch ein Bereitstellen der festen Subskriptionsbezogenen Information zu der Angliederung, wie sie in der angegliederten Dienstevorlage eingerichtet ist, durchgeführt werden. Dies führt zu der Schaffung eines neuen Benutzerdatenobjekts in den angegliederten Daten.
Das Subskriptionsobjekt wird auf diesen Benutzerkontext in der Angliederung zeigen, so dass eine weitere Aktivierung und andere Bereitstelungs-bezogene Aktivitäten unterstützt werden. Diese Referenz wird aus der Benutzer-id, die von der Anwendung zugewiesen ist, und der Adresse der Angliederung bestehen.

Aktiviere Dienst

Erwatetes Ergebnis:
Ein Dienst ist bereit, zum ersten Mal verwendet zu werden.
Vorbedingungen:
Eine Subskription, die auf diesen Benutzer bezogen ist, und dieser angebotene Dienst ist gemäß dem Obigen geschaffen worden.
Beschreibung des Falls:
Der letzte Schritt, um einen bestimmten angebotenen Dienst zur Verwendung bereit zu haben, besteht in seiner Aktivierung. Ein Administrator (kann in manchen Fällen einfach der Benutzer sein) stellt eine persönliche Information bereit, für die Diensteaktivierung gemäß seiner Bereitstellungsvorlage erforderlich ist. Die Aktivierungseinstellungen werden an die Speicherbereiche für angegliederte Daten gemäß ihrem angegliederten Bereitstellungsvertrag gesendet.
Das entsprechende Objekt in dem SAP (das Subskriptionsobjekt) wird aktualisiert, um wiederzugeben, dass der Dienst aktiviert worden ist.
Referenzen (die Dienste-Benutzer-id plus die angegliederte Adresse) zu dem Speicherbereich für angegliederte Daten, wo der Dienst liegt, und die Beziehung zwischen dem Dienst und den geteilten Ressourcen, die er benötigt, muss auch eingerichtet werden.

Echtzeit-Anriwendungsfälle

Hole geteilten Ressourcen

Erwartetes Ergebnis:
Eine Anwendung holt die geteilten Ressourcen, die von einem Benutzer oder einem Teilnehmer verwendet werden. Die Anwendung kann diese Information verwenden, um auf die Ressource zu Dienste- Ausführungszwecken zuzugreifen.
Vorbedingungen:
Zumindest ein Dienst für den Benutzer muss zur Verwendung bereit sein.
Beschreibung des Falls:
Die Dienste, die von den Anwendungen angeboten werden, können es erfordern, zur Ausführungszeit auf die geteilten Ressourcen zuzugreifen, die den Diensteausführungsprozess unterstützen. Beispielsweise wird es eine Anforderung, die einen Ortsbasierten Dienst anbietet, erfordern, auf einen Einrichter zuzugreifen, der die Orts-Info von dem Zugriffsnetz holt und diese für Anwendungen sichtbar macht.
Zu diesem Zweck werden die Anwendungen, die eine Info über geteilte Ressourcen, die zu einem Benutzer/Teilnehmer gehören, zu holen wünscht, diese anfordern, indem die Identität des Benutzers verwendet wird. Da sämtliche möglichen Identitäten in dem SN- Benutzerdatenmodell gehalten werden, und auch eine Zuordnung jedes Dienstes zu seinen geteilten Ressourcen vorhanden ist, wird die angeforderte Information zu der Anwendung geliefert.

Hole Benutzer-Ids

Erwartetes Ergebnis:
Eine Anwendung holt irgendeine der Benutzer Ids. Die Anwendung kann diese Information für Diensteausführungszwecke verwenden.
Vorbedingungen:
Zumindest ein Benutzer muss vorhanden sein.
Beschreibung des Falls:
Ein Dienst, der von einer Anwendung angeboten wird, kann jedwede Identifikation für einen Benutzer verwenden, aber es kann aufgrund von Diensteeigenschaften erforderlich sein, andere Identitäten des Benutzers zu kennen (beispielsweise indem die E-Mail-Adresse vorhanden ist, könnte es interessant sein, die MSISDN zu kennen, um eine E-Mail in einem SMS-Format zu senden). Der SN- SAP weist eine Kenntnis sämtlicher Benutzer-Identitäten auf, somit wird die angeforderte Information gesendet.

Hole Dienstellste

Erwartetes Ergebnis:
Die Liste abbonierter Dienste wird zu einer Einheit gesendet, die auf den SN-SAP zugreift.
Vorbedingungen:
Zumindest ein Benutzer ist vorhanden.
Beschreibung des Falls:
Zu Autorisierungszwecken sind manche Einheiten, die an einem Erhalt der Liste abbonierter Dienste für einen Benutzer interessiert sein könnten, vorhanden, so dass dann, wenn ein Versuch unternommen wird, diesen Dienst zu benutzen, überprüft wird, ob dieser Benutzer Rechte besitzt, diesen Dienst zu verwenden. Zu diesem Zweck ist der SAP befähigt, diese Liste aufzubauen und zu senden, wenn sie angefordert wird.

Claims

1. System zum Speichern und Aufrechterhalten von Benutzer- und Teilnehmerdaten in einem Dienstenetz (200) mit einer Vielzahl von Dienstesystemen (310, 320, 330) zum Bereitstellen einer Vielzahl von Diensten, wobei das System eine Teilnehmer/Benutzer-Datenbank umfasst, die Teilnehmer/Benutzer-Datensätze mit Benutzer- und Teilnehmerinformation umfasst, dadurch gekennzeichnet, dass die Teilnehmer/Benutzer-Datenbank eine gemeinsame Teilnehmer/Benutzer-Datenbank (300) ist, die Teilnehmer/Benutzer-Information hält, die für eine Vielzahl von Diensten relevant ist, und dadurch, dass die Teilnehmer/Benutzer-Datensätze (803) umfassen:

- zumindest ein Identifikationsfeld (805, 810), das einen Teilnehmer und einen Benutzer identifiziert; und

- zumindest ein Dienstefeld (835, 840), das zumindest einen ausgewählten Dienst von der Vielzahl von Diensten spezifiziert, die in dem Dienstenetz bereitgestellt sind, wobei der zumindest eine ausgewählte Dienst von dem Benutzer oder Teilnehmer ausgewählt ist,

wobei zumindest eines des zumindest einen Dienstefelds ausgelegt ist, um Verbindungen zu angegliederten Daten (860) bereitzustellen, die den Teilnehmer/Benutzer betreffen, und wobei die angegliederten Daten außerhalb der gemeinsamen Teilnehmer/Benutzer-Datenbank gespeichert sind,
wodurch die gemeinsame Teilnehmer/Benutzer-Datenbank und die Teilnehmer/Benutzer-Datensätze einen einzigen Zugriffspunkt zum Zugreifen auf Benutzer- und/oder Teilnehmerdaten in dem Dienstenetz unterstützen.

2. System nach Anspruch 1, dadurch gekennzeichnet, dass die Teilnehmer/Benutzer-Datensätze zumindest zwei Dienstefelder umfassen:

- ein Dienstesubskriptionsfeld (835), das eine erste Gruppe von Diensten spezifiziert, die für den Teilnehmer verfügbar sind, wobei die Dienste in der ersten Gruppe der Dienste aus der Vielzahl von Diensten ausgewählt werden, die in dem Dienstenetz bereitgestellt sind; und

- zumindest ein Diensteaktivierungsfeld (840), wobei jedes Diensteaktivierungsfeld einen durch den Benutzer aktivierten Dienst spezifiziert, der aus der ersten Gruppe von Diensten ausgewählt ist,

wobei das Dienstesubskriptionsfeld und/oder die Diensteaktivierungsfelder ausgelegt sind, Verbindungen zu angegliederten Daten bereitzustellen, die den Teilnehmer/Benutzer betreffen, und wobei die angegliederten Daten außerhalb der gemeinsamen Teilnehmer/Benutzer-Datenbank gespeichert sind.

3. System nach Anspruch 2, dadurch gekennzeichnet, dass die Benutzerdatensätze umfassen:

- eine Vielzahl von Benutzerfeldern (805), wobei jedes Benutzerfeld einen Benutzer identifiziert und jeder Benutzer zu dem Teilnehmer gehört; und

- zumindest ein Diensteaktivierungsfeld (840) für jeden Benutzer, wobei die Diensteaktivierungsfelder mit dem jeweiligen Benutzerfeld (805) verbunden sind, die Diensteaktivierungsfelder (840) eine Gruppe von Diensten pro Benutzer, die dem jeweiligen Benutzer verfügbar sind, spezifizieren, die Gruppe von Diensten pro Benutzer eine Auswahl von Diensten aus der ersten Gruppe von Diensten ist, und wobei die Diensteaktivierungsfelder Verbindungen zu angegliederten Daten (860) bereitstellen, die außerhalb der gemeinsamen Teilnehmer/Benutzer-Datenbank gespeichert sind.

4. System nach Anspruch 3, dadurch gekennzeichnet, dass die gemeinsame Teilnehmerdatenbank eine verteilte Datenbank (400) ist.

5. System nach Anspruch 3, dadurch gekennzeichnet, dass die Benutzerdatensätze Abhängigkeiten zwischen unterschiedlichen Dienstesystemen zum Durchführen eines komplexen Dienstes speichern.

6. System nach Anspruch 3, dadurch gekennzeichnet, dass die Verbindungen zu angegliederten Daten in der Form einer IP-Adresse, einer URL einer HTML-Adresse oder einer E 163-Adresse vorliegen.

7. System nach Anspruch 3, dadurch gekennzeichnet, dass die Verbindungen zu angegliederten Daten in der Form einer Adresse vorliegen, die in einem IP-basierten Netz erkennbar ist.

8. System nach Anspruch 5, dadurch gekennzeichnet, dass die Benutzerdatensätze für jeden Benutzer ein Benutzergeteiltes Ressourcenfeld (850) umfassen, das mit dem Benutzerfeld und dem Diensteaktivierungsfeld verbunden ist, und das Benutzer-geteilte Ressourcenfeld Abhängigkeiten zwischen Dienstesystemen, deren Abhängigkeiten auf einer Benutzerstufe sind, speichert.

9. System nach Anspruch 5, dadurch gekennzeichnet, dass die Benutzerdatensätze ein Teilnehmer-geteiltes Ressourcenfeld umfassen, das mit dem Teilnehmerfeld (845) und dem Dienstesubskriptionsfeld verbunden ist, wobei das Teilnehmer-geteilte Ressourcenfeld Abhängigkeiten zwischen Dienstesystemen, deren Abhängigkeiten auf einer Teilnehmerstufe sind, speichert.

10. System nach Anspruch 3, dadurch gekennzeichnet, dass die Benutzerdatensätze für jeden Benutzer eine Vielzahl von Mitteln zum Identifizieren des jeweiligen Benutzers speichern.

11. System nach Anspruch 10, dadurch gekennzeichnet, dass die Mittel zur Identifikation eines oder mehrere der folgenden sind: Eine Telefonnummer, ein persönlicher Identifikationscode, eine E-Mail-Adresse, ein Name oder ein Alias.

12. System nach Anspruch 10, dadurch gekennzeichnet, dass die Mittel zur Identifikation in Feldern gespeichert sind, die auch Abhängigkeiten zwischen Dienstesystemen speichern.

13. System nach Anspruch 2, dadurch gekennzeichnet, dass die unterschiedlichen Dienstesysteme in Kombination einen komplexen Dienst oder ein Dienstesystem bilden, das als eine geteilte Ressource für eine Vielzahl anderer Dienste dient, und die Abhängigkeiten zwischen den unterschiedlichen Dienstesystemen in einer gemeinsamen Dienstedatenbank gespeichert sind.

14. System nach Anspruch 3, dadurch gekennzeichnet, dass die Benutzerdatensätze weiter eine Vielzahl von Feldern umfassen, die Dienste spezifizieren, die den Benutzern verfügbar sind, wobei die Vielzahl von Feldern umfasst:

- zumindest ein Dienstepaketfeld (825), wobei jedes Dienstepaketfeld eine Gruppe von Diensten spezifiziert, die dem Teilnehmer verfügbar sind, der in dem Teilnehmerfeld spezifiziert ist;

- ein Kundensegmentfeld (815), das zum Kennzeichnen des Teilnehmers des Teilnehmerfelds und zum Spezifizieren von Dienstepaketen ausgelegt ist; und

- zumindest ein Feld für angebotene Dienste (820), das eine Diensteinformation für jeden getrennten Dienst umfasst, der in dem Dienstepaket eingeschlossen ist, das durch die Dienstepaketfelder spezifiziert ist.

15. Datensatz, ausgelegt zum Speichern und Aufrechterhalten von Benutzer- und Teilnehmerdaten in einem Dienstenetz (200) mit einer Vielzahl von Dienstesystemen (310, 320, 330) zum Bereitstellen einer Vielzahl von Diensten, wobei das System eine Teilnehmer/Benutzer-Datenbank umfasst, die Teilnehmer/Benutzer-Datensätze mit Benutzer- und Teilnehmerinformation umfasst, dadurch gekennzeichnet, dass die Teilnehmer/Benutzer-Datenbank eine gemeinsame Teilnehmer/Benutzer-Datenbank (300) ist, die eine Teilnehmer/Benutzer-Information hält, die für eine Vielzahl von Diensten relevant ist, und dadurch, dass die Teilnehmer/Benutzer-Datensätze (803) umfassen:

wobei zumindest eines des zumindest einen Dienstefelds ausgelegt ist, Verbindungen zu angegliederten Daten (860) bereitzustellen, die den Teilnehmer/Benutzer betreffen, und wobei die angegliederten Daten außerhalb der gemeinsamen Teilnehmer/Benutzer-Datenbank (300) gespeichert sind,
wodurch die gemeinsame Teilnehmer/Benutzer-Datenbank und die Teilnehmer/Benutzer-Datensätze einen einzigen Zugriffspunkt zum Zugreifen auf Benutzer- und/oder Teilnehmerdaten in dem Dienstenetz unterstützen.

16. Datensatz nach Anspruch 15, dadurch gekennzeichnet, dass die Teilnehmer/Benutzer-Datensätze (803) zumindest die beiden Dienstefelder umfassen:

- ein Dienstesubskriptionsfeld (835), das eine erste Gruppe von Diensten spezifiziert, die dem Teilnehmer verfügbar sind, wobei die Dienste in der ersten Gruppe von Diensten aus der Vielzahl von Diensten ausgewählt sind, die in dem Dienstenetz bereitgestellt sind; und

- zumindest ein Diensteaktivierungsfeld (840), wobei jedes Diensteaktivierungsfeld einen von dem Benutzer aktivierten Dienst spezifiziert, der aus der ersten Gruppe von Diensten ausgewählt ist,

17. Datensatz nach Anspruch 16, dadurch gekennzeichnet, dass die Datensätze umfassen:

- zumindest ein Diensteaktivierungsfeld (840) für jeden Benutzer, wobei die Diensteaktivierungsfelder mit dem jeweiligen Benutzerfeld verbunden sind, die Diensteaktivierungsfelder eine Gruppe von Diensten pro Benutzer spezifizieren, die dem jeweiligen Benutzer verfügbar sind, die Gruppen von Diensten pro Benutzer, eine Auswahl von Diensten aus der ersten Gruppe von Diensten ist, und wobei die Diensteaktivierungsfelder Verbindungen zu angegliederten Daten (860) bereitstellen, die außerhalb der gemeinsamen Teilnehmer/Benutzer-Datenbank gespeichert sind.

18. Datensatz nach Anspruch 16, wobei die Benutzerdatensätze Abhängigkeiten zwischen unterschiedlichen Dienstesystemen zum Durchführen eines komplexen Dienstes speichern.

19. Datensatz nach Anspruch 18, dadurch gekennzeichnet, dass die Benutzerdatensätze für jeden Benutzer ein Benutzer-geteiltes Ressourcenfeld (850) umfassen, das mit dem Benutzerfeld und dem Diensteaktivierungsfeld verbunden ist, und das Benutzer-geteilte Ressourcenfeld Abhängigkeiten zwischen Dienstesystemen speichert, wobei die Abhängigkeiten auf einer Benutzerstufe sind.

20. Datensatz nach Anspruch 18, dadurch gekennzeichnet, dass die Benutzerdatensätze ein Teilnehmer-geteiltes Ressourcenfeld (840) umfassen, das mit dem Teilnehmerfeld und dem Dienstesubskriptionsfeld verbunden ist, wobei das Teilnehmer-geteilte Ressourcenfeld Abhängigkeiten zwischen Dienstesystemen speichert, wobei die Abhängigkeiten auf einer Teilnehmerstufe sind.

21. Datensatz nach Anspruch 17, dadurch gekennzeichnet, dass die Benutzerdatensätze für jeden Benutzer eine Vielzahl von Mitteln zur Identifikation des jeweiligen Benutzers speichern.

22. Datensatz nach Anspruch 21, dadurch gekennzeichnet, dass die Mittel zur Identifikation eines oder mehrere der folgenden sind: Eine Telefonnummer, ein persönlicher Identifikationscode, eine E-Mail-Adresse, ein Name oder ein Alias.

23. Datensatz nach Anspruch 21, dadurch gekennzeichnet, dass die Mittel zur Identifikation in Feldern gespeichert sind, die auch Abhängigkeiten zwischen Dienstesystemen speichern.

24. Datensatz nach Anspruch 17, dadurch gekennzeichnet, dass die Benutzerdatensätze weiter eine Vielzahl von Feldern umfassen, die Dienste spezifizieren, die den Benutzern verfügbar sind, wobei die Vielzahl von Feldern umfasst:

ein Kundensegmentfeld (815), das zum Kennzeichnen des Teilnehmers des Teilnehmerfelds und zum Spezifizieren von Dienstepaketen ausgelegt ist; und

25. Benutzerdatenmodell, ausgelegt zum Speichern und Aufrechterhalten von Benutzer- und Teilnehmerdaten in einem bienstenetz (200) mit einer Vielzahl von Dienstesystemen (310, 320, 330) zum Bereitstellen einer Vielzahl von Diensten, wobei das System eine Teilnehmer/Benutzer-Datenbank umfasst, die Teilnehmer/Benutzer-Datensätze mit Benutzer- und Teilnehmerinformation umfasst, dadurch gekennzeichnet, dass das Benutzerdatenmodell ausgelegt ist, eine Speicherung von Benutzer- und Teilnehmerdaten in einer gemeinsamen Teilnehmer/Benutzer-Datenbank (300) zu unterstützen, und dadurch, dass die gemeinsame Teilnehmer/Benutzer-Datenbank eine Teilnehmer/Benutzer- Information hält, die für eine Vielzahl von Diensten relevant ist, und dadurch, dass das Benutzerdatenmodell umfasst:

- zumindest ein Identifikationsobjekt (605, 610), das einen Teilnehmer und einen Benutzer identifiziert; und

- zumindest ein Diensteobjekt (635, 640), das zumindest einen ausgewählten Dienst aus der Vielzahl von Diensten spezifiziert, die in dem Dienstenetz bereitgestellt sind, wobei der zumindest eine ausgewählte Dienst von dem Benutzer oder Teilnehmer ausgewählt ist,

wobei zumindest eines des zumindest einen Diensteobjekts Verbindungen zu angegliederten Daten (660) bereitstellt, die den Teilnehmer/Benutzer betreffen, und wobei die angegliederten Daten außerhalb der gemeinsamen Teilnehmer/Benutzer-Datenbank gespeichert sind,
wodurch die gemeinsame Teilnehmer/Benutzer-Datenbank und das Datenmodell einen einzigen Zugriffspunkt zum Zugreifen auf Benutzer- und/oder Teilnehmerdaten in einem Dienstenetz unterstützen.

26. Datenmodell nach Anspruch 25, dadurch gekennzeichnet, dass die Teilnehmer/Benutzer-Datensätze zumindest die beiden Diensteobjekte umfassen:

- ein Dienstesubskriptionsobjekt (635), das eine erste Gruppe von Diensten spezifiziert, die dem Teilnehmer verfügbar sind, wobei die Dienste in der ersten Gruppe von Diensten aus der Vielzahl von Diensten ausgewählt sind, die in dem Dienstenetz bereitgestellt sind; und

- zumindest ein Diensteaktivierungsobjekt (640), wobei jedes Diensteaktivierungsobjekt einen von dem Benutzer aktivierten Dienst spezifiziert, der aus der ersten Gruppe von Diensten ausgewählt ist,

wobei das Dienstesubskriptionsobjekt und/oder die Diensteaktivierungsobjekte ausgelegt sind, Verbindungen zu angegliederten Daten bereitzustellen, die den Teilnehmer/Benutzer betreffen, und wobei die angegliederten Daten außerhalb der gemeinsamen Teilnehmer/Benutzer-Datenbank gespeichert sind.

27. Datenmodell nach Anspruch 26, dadurch gekennzeichnet, dass das Benutzerdatenmodell umfasst:

- eine Vielzahl von Benutzerobjekten (605), wobei jedes Benutzerobjekt einen Benutzer identifiziert und jeder Benutzer zu dem Teilnehmer gehört; und

- zumindest ein Diensteaktivierungsobjekt (640) für jeden Benutzer, wobei das Diensteaktivierungsobjekt mit dem jeweiligen Benutzerobjekt verbunden ist, jedes Diensteaktivierungsobjekt eine Gruppe von Diensten pro Benutzer spezifiziert, die dem jeweiligen Benutzer verfügbar sind, die Gruppe von Diensten pro Benutzer eine Auswahl von Diensten aus der ersten Gruppe von Diensten ist, und wobei die Diensteaktivierungsobjekte Verbindungen zu angegliederten Daten bereitstellen, die außerhalb der gemeinsamen Teilnehmer/Benutzer-Datenbank (300) gespeichert sind.

28. Datenmodell nach Anspruch 27, dadurch gekennzeichnet, dass das Benutzerdatenmodell Abhängigkeiten zwischen unterschiedlichen Dienstesystemen zum Durchführen eines komplexen Dienstes definiert.

29. Datenmodell nach Anspruch 28, dadurch gekennzeichnet, dass das Benutzerdatenmodell für jeden Benutzer ein Benutzer-geteiltes Ressourcenobjekt (650) umfasst, das mit dem Benutzerobjekt und dem Diensteaktivierungsobjekt verbunden ist, und das Benutzer-geteilte Ressourcenobjekt Abhängigkeiten zwischen Dienstesystemen definiert, wobei die Abhängigkeiten auf einer Benutzerstufe sind.

30. Datenmodell nach Anspruch 28, dadurch gekennzeichnet, dass das Benutzerdatenmodell ein Teilnehmer-geteiltes Ressourcenobjekt (645) umfasst, das mit dem Teilnehmerobjekt und dem Dienstesubskriptionsobjekt verbunden ist, und das Teilnehmer-geteilte Ressourcenobjekt Abhängigkeiten zwischen Dienstesystemen definiert, wobei die Abhängigkeiten auf einer Teilnehmerstufe sind.

31. Datenmodell nach Anspruch 28, dadurch gekennzeichnet, dass das Benutzerdatenmodell für jeden Benutzer eine Vielzahl von Mitteln zur Identifikation des jeweiligen Benutzers definiert.

32. Datenmodell nach Anspruch 31, dadurch gekennzeichnet, dass die Mittel zur Identifikation eines oder mehrere der folgenden sind: Eine Telefonnummer, ein persönlicher Identifikationscode, eine E-Mail-Adresse, ein Name oder ein Alias.

33. Datenmodell nach Anspruch 31, dadurch gekennzeichnet, dass das Mittel zur Identifikation in Objekten definiert ist, die auch Abhängigkeiten zwischen Dienstesystemen speichern.

34. Datenmodell nach Anspruch 27, dadurch gekennzeichnet, dass das Benutzerdatenmodell weiter eine Vielzahl von Objekten umfasst, die Dienste spezifizieren, die den Benutzern verfügbar sind, wobei die Vielzahl von Objekten umfasst:

- zumindest ein Dienstepaketobjekt (625), wobei jedes Dienstepaket eine Gruppe von Diensten spezifiziert, die . dem Teilnehmer verfügbar sind, der durch das Teilnehmerobjekt (610) spezifiziert ist;

- ein Kundensegmentobjekt (615), das zum Kennzeichnen des Teilnehmers des Teilnehmerobjekts und zum Spezifizieren von Dienstepaketen ausgelegt ist; und

- zumindest ein Angebotsdiensteobjekt (620), das eine Diensteinformation für jeden getrennten Dienst umfasst, der in dem Dienstepaket eingeschlossen ist, das durch die Dienstepaketobjekte spezifiziert ist.

35. Verfahren zum Zugreifen auf Benutzer- und Teilnehmerdaten in einem Dienstenetz, wobei das Dienstenetz eine Vielzahl von Dienstesystemen umfasst, die eine Vielzahl von Diensten anbieten, wobei das Verfahren die Schritte umfasst:

- Zugreifen (910) auf einen einzigen Zugriffspunkt in dem Dienstenetz;

- Anfordern (920), Daten von dem einzigen Zugriffspunkt zu lesen und/oder in diesen zu schreiben, und

- Wiedergewinnen oder Übertragen (930-950) von Daten von oder zu einem Teilnehmer/Benutzer-Datensatz über den einzigen Zugriffspunkt, wobei der Teilnehmer/Benutzer-Datensatz nach einem der Ansprüche 15 bis 24 definiert ist.

36. Verfahren nach Anspruch 35, weiter umfassend den Schritt:
Überprüfen (970), ob der Benutzerdatensatz Informationen über Abhängigkeiten zwischen unterschiedlichen Dienstesystemen umfasst.

37. Verfahren nach Anspruch 36, dadurch gekennzeichnet, dass der Schritt eines Überprüfens umfasst:

- Überprüfen des Diensteaktivierungsfelds (840), des Benutzer-geteilten Ressourcenfelds (850) und des Teilnehmer-geteilten Ressourcenfelds (845) auf Verbindungen, die Abhängigkeiten zwischen unterschiedlichen Dienstesystemen anzeigen.

38. Verfahren nach Anspruch 35, weiter umfassend die Schritte, die zu unternehmen sind, wenn angegliederte Daten, die nicht innerhalb des einzigen Zugriffspunkts gespeichert sind, benötigt werden:

- Zugreifen (955) auf den einzigen Zugriffspunkt zum Wiedergewinnen von Verbindungen zu den angegliederten Daten und der Information, die erforderlich ist, um auf die angegliederten Daten zuzugreifen; und

- Zugreifen (960) auf einen Speicherbereich für angegliederte Daten unter Verwendung der Verbindung und der Information, die in dem vorherigen Schritt wiedergewonnen ist.

39. Verfahren nach einem der Ansprüche 35-38, dadurch gekennzeichnet, dass die Schritte von einem Software- Client durchgeführt werden.

40. Computerprogrammprodukt, das direkt in den internen Speicher einer Verarbeitungseinrichtung innerhalb einer Einheit in dem Dienstenetz ladbar ist, umfassend die Softwarecodeeinrichtung, die ausgelegt ist, um die Schritte von Anspruch 35-39 zu steuern.

41. Computerprogrammprodukt, das auf einem Computerbenutzbaren Medium gespeichert ist, umfassend ein lesbares Programm, das ausgelegt ist, eine Verarbeitungseinrichtung in einer Verarbeitungseinheit für eine Einheit in dem Dienstenetz zu veranlassen, eine Ausführung der Schritte von einem der Ansprüche 35-39 zu steuern.