DE602004001016T2

DE602004001016T2 - Kontrollverfahren mit Verwaltung eines opaken Benutzeridentifikators zur vollständigen Lieferung eines Dienstes mit mehreren Servern

Info

Publication number: DE602004001016T2
Application number: DE602004001016T
Authority: DE
Inventors: Christophe Giraud-Sauveur; Fabien Guinet; Frederic Vignaud
Original assignee: Societe Francaise du Radiotelephone SFR SA
Current assignee: Societe Francaise du Radiotelephone SFR SA
Priority date: 2003-06-06
Filing date: 2004-03-05
Publication date: 2006-12-14
Anticipated expiration: 2024-03-06
Also published as: DK1484859T3; CN100388206C; EP1484859A1; FR2855924B1; US20040260719A1; KR20040105588A; ES2264554T3; FR2855924A1; ATE328421T1; PT1484859E; CN1573699A; EP1484859B1; JP2004362591A; DE602004001016D1

Description

Die vorliegende Erfindung betrifft das Gebiet der Telekommunikation und das Management der Multimedia-Dienste. Die vorliegende Erfindung betrifft insbesondere ein Verfahren, das durch Managen eines opaken Anwenderidentifizierers das Steuern der vollständigen Lieferung eines über eine Gesamtheit von "Enabler"-Servern gelieferten Dienstes ermöglicht.
Im Folgenden wird als "Enabler" oder "Enabler-Dienst" jedes Serverelement bezeichnet, das einen Dienst liefern kann. Die Definitionen der im Folgenden verwendeten technischen Begriffe englischen Ursprungs sind nachstehend dargelegt:

– Commit: Aktion auf eine Transaktion, mit der ihr Zustand in einen definitiv validierten Zustand versetzt werden kann
– Rollback: Aktion auf eine fehlgeschlagene Transaktion, mit der das Verlassen der laufenden Transaktion und das Zurückversetzen des Systems in seinen Anfangszustand mitgeteilt werden kann
– Begin: Aktion, die den Beginn einer Transaktion markiert
– TimeOut: Ende des Wartezeit
– Mask: Maskieren
– Unmask: Demaskieren
– Start: Starten
– Completed: Melden des erfolgreichen Abschlusses
– Error: Melden des Fehlers
– Update: Aktualisieren
– OpenTransaction: Eröffnen der Transaktion
– CloseTransaction: Schließen der Transaktion

Im Stand der Technik sind Identifizierer-Manager (GID) in Form von Datenverarbeitungssystemen bekannt, die mit Schnittstellen versehen sind, die das Maskieren und Demaskieren der Identität eines Anwenders mit Hilfe eines opaken Identifizierers ermöglichen. Solche GID-Manager stellen den externen Systemen ein Mittel bereit, mit einem Anwender zu kommunizieren, ohne ihm jedoch seine Identität mitzuteilen. Die GID-Identifizierer-Manager sind auf Grund von Gesetzesvorschriften, die darauf abzielen, die Vertraulichkeit bestimmter Informationen zu garantieren, eingeführt. Die GID sind jedoch nicht geeignet, Sitzungs- oder Transaktionsbegriffe, die gleichzeitig mit einem Dienst und einem gegebenen Anwender oder einer gegebenen Gruppe von Anwendern verknüpft sind, zu managen.
Es sind ebenso Dialog-Manager (GD) bekannt, die durch ein Datenverarbeitungssystem gebildet sind, das in ein System zum Managen der Fakturierung von Diensten eingebunden ist. Die GD-Dialog-Manager gewährleisten einerseits einen Dialog mit dem Anwender, um diesen über den Preis eines Dienstes zu informieren und seine Bestätigung zu erlangen, und andererseits die Auslösung der Fakturierung am Ende eines Dienstes. Der GD-Dialog-Manager ist ausschließlich auf Fakturierungsprobleme gerichtet, wobei die Ausführungen eines GD-Managers von dem Serverelement, das in der Lage ist, "Enabler"-Dienste zu erzeugen und bereitzustellen, technologisch unabhängig sind.
Es gibt außerdem Angebots-Manager (GO), die dazu dienen, den richtigen Ablauf des Dienstangebots zu verifizieren. Die GO sind in der Mehrzahl von dem Serverelement, das in der Lage ist, "Enabler"-Dienste zu erzeugen und bereitzustellen, technologisch unabhängig. Sie sind folglich oft "Einelement-Server" oder sogar solche mit einer Anforderung. Sie sind folglich nicht in der Lage, den richtigen Ablauf eines "Mehrelement-Server"-Dienstes von Anfang bis Ende zu behandeln.
Im Übrigen sind "Framework"-Logikplattformen für die Dienstentwicklung bekannt, die im Allgemeinen den Partnern einen gesteuerten Zugriff auf die Betriebsmittel des Netzes des Operators bieten. Diese Partner können Mehrwert- Dienstanbieter (auf englisch Value Added Service Provider) sein. Die Plattformen OSA (Open Service Architecture) oder PARLAY sind Beispiele solcher "Framework"-Plattformen. OSA ermöglicht so das Definieren einer Schnittstelle mit einem Mobilfunk-Fernsprechnetz, das Standardfähigkeiten bietet. PARLAY ist OSA vergleichbar, jedoch für ein Fernsprech-Festnetz. Solche Dienstentwicklungsplattformen arbeiten:

– entweder im Proxy-Modus, was eine technische Integration der "Framework"-Logikplattform durch die Mehrwert-Dienstanbieter-Partner, VASP-Partner, und außerdem eine Aktualisierung der Framework"-Logikplattform erzwingt, um dort neue "Enabler"-Serverelemente, die in der Lage sind, Dienste zu erzeugen und bereitzustellen, oder einfach neue Schnittstellen zu Serverelementen, die in der Lage sind, "vorhandene" Dienste zu erzeugen und bereitzustellen, zu integrieren,
– oder im Verzeichnismodus "Directory", was erzwingt, dass, sobald durch die "Framework"-Logikplattform der Verweis auf das Serverelement, das in der Lage ist, "Enabler"-Dienste zu erzeugen und bereitzustellen, zugeteilt ist, keinerlei statistische Informationen mehr über es laufen.

So ist aus dem Dokument WO 02/102018 ein System für den Zugriff auf Dienste über das Netz Internet bekannt, das ermöglicht, Berechtigungen für einen bestimmten Typ von Diensten auszugeben und über einen oder mehrere bestimmte Server Dienste an eine Anwender-Endeinrichtung zu liefern. Dieser Systemtyp kann das Authentisieren des Anwenders bei jedem bestimmten Server erübrigen, jedoch erlaubt es kaum das Aktualisieren neuer zugänglicher Dienste oder das Berücksichtigen neuer Bedürfnisse des Anwenders.
Es gibt folglich keine aktuelle Lösung, die geeignet ist, einem Abonnenten, der mehrere "Enabler"-Serverelemente des Netzes des Telekommunikationsoperators verwendet, das Management einer Dienstsitzung zu gewährleisten. Es ist also nicht möglich, Ereignisse über die vollständige (oder unvollständige) Ausführung des Dienstes zu erzeugen.
Eine Aufgabe der vorliegenden Erfindung ist, diese Nachteile des Standes der Technik zu beseitigen. Somit liefert die in diesem Dokument beschriebene Erfindung eine Lösung, die es ermöglicht, sich den folgenden Fragestellungen zuzuwenden:

– Zusicherung der erfolgreichen Lieferung eines Dienstes, der die "Enabler"-Serverelemente eines Operatornetzes verwendet,
– Garantie der QoS (Dienstqualität) von Anfang bis Ende,
– Steuerung des Zugriffs auf "Enabler"-Serverelemente für einen gegebenen Anwender und einen gegebenen Dienst,
– Erlangung von statistischen Informationen über die Verwendung und die Ausführung eines Dienstes sowohl im Modus Pull/MO (Mobile Originated), der von einer Anforderung der beweglichen Einrichtung herrührt, als auch im Modus Push/MT (Mobile Terminated), der von einer Anforderung eines Serverelements in Richtung einer beweglichen Einrichtung herrührt,
– Management der opaken Identifizierer, das dem Operator ermöglicht, die Vertraulichkeit des Anwenders gegenüber den Dienstanbietern zu garantieren.

Dazu betrifft die Erfindung ein Verfahren zum Steuern, einschließlich Management, eines opaken Anwenderidentifizierers der vollständigen Lieferung eines Dienstes unter Verwendung wenigstens eines Servers, dadurch gekennzeichnet, dass es über ein Transaktionsidentifizierer-Servermittel ausgeführt wird, das in einem Speicher für jeden Anwender eine Beschreibung mehrerer Dienstangebote speichert, die von dem Anwender bei Dienstanbietern unterschrieben worden sind, wobei das Transaktionsidentifizierer-Servermittel ein Management-Modul aufweist, das ermöglicht, einem Anwender oder einer Gruppe von Anwendern und wenigstens einem bestimmten Dienst einen opaken Transaktionsidentifizierer zuzuordnen, wobei das Verfahren die folgenden Schritte umfasst:

– Senden einer Anforderung zum Eröffnen einer Transaktion wenigstens eines Dienstes, der wenigstens ein "Enabler"-Serverelement erfordert, das Unter transaktionen ausführt, durch ein "Enabler"-Serverelement, das eine Dienstanforderung eines Anwenders empfangen hat, oder durch einen der Dienstanbieter, wobei diese Anforderung mit einem Satz von offenen Primitiven, die an eine Kommunikationsschnittstelle des Transaktionsidentifizierer-Servermittels adressiert sind und eine Anwenderidentifizierung angeben, sequentiell beschrieben wird,
– Analysieren der Anforderung und Erzeugen eines opaken Transaktionsidentifizierers durch die Management- und Steuermittel des Transaktionsidentifizierer-Servers, anschließend
– einen Schritt des Ausführens der Transaktion unter Verwendung des opaken Transaktionsidentifizierers.

Die Erfindung ermöglicht folglich das Zugreifen auf das Angebot eines Dienstes, wobei durch Verwendung eines opaken Sitzungsidentifizierers für einen berechtigten Anwender die Vertraulichkeit des Anwenders gegenüber Dienstanbietern garantiert ist.
Gemäß einem weiteren Merkmal der Erfindung umfasst der Analyseschritt eine durch das Managementmodul erfolgende Verifikation der Entsprechung der bestimmten "Enabler"-Serverelemente mit einem verzeichneten Dienstangebot, auf das vom Anwender unter mehreren Dienstangeboten zugegriffen werden kann, und eine Steuerung der Berechtigung zum Eröffnen der Transaktion durch die Steuermittel des Transaktionsidentifizierer-Servermittels für den von den "Enabler"-Serverelementen bereitgestellten Dienst und den bestimmten Anwender insbesondere in Abhängigkeit von der Anwenderidentifizierung.
Gemäß einem weiteren Merkmal der Erfindung wird der Schritt der Ausführung der Transaktion durch einen Mehrwert-Dienstanbieter initiiert, der den opaken Transaktionsidentifizierer von Seiten des Transaktionsidentifizierer-Servermittels empfangen hat, wobei der Dienstanbieter eine Anfrage an ein bestimmtes Enabler-Serverelement mit parametrisiertem opakem Transaktionsidentifizierer eines bestimmten Dienstes, der eine Untertransaktion bildet, ausführt, um in Re aktion auf das bestimmte Enabler-Serverelement das Schicken einer Demaskierungsanforderung "unmask" auszulösen, die anhand des opaken Identifizierers die Lieferung einer nicht opaken Identifizierungsnummer, die dem opaken Transaktionsidentifizierer entspricht, ermöglicht, wobei anschließend durch die Steuermittel des Transaktionsidentifizierer-Servermittels eine Steuerung ausgeführt wird, um zu verifizieren, ob das bestimmte "Enabler"-Serverelement für diesen Dienst und für diesen Anwender berechtigt ist oder nicht, derart, dass im Fall der Berechtigung die nicht opake Identifizierungsnummer (MS-ISDN) über eine Kommunikationsschnittstelle, die Enabler-Schnittstelle genannt wird, an das bestimmte Serverelement übertragen wird, um die Ausführung der Untertransaktion zu ermöglichen.
Gemäß einem weiteren Merkmal der Erfindung ist der Transaktionsidentifizierer aus höchstens 15 Stellen gebildet und mit der Nummierungsebene UIT-T E-164 konform, wobei die nicht opake Identifizierungsnummer die MSISDN-(Mobile Station Integrated Services Digital Network)-Nummer ist.
Gemäß einem weiteren Merkmal der Erfindung umfasst das Transaktionsidentifizierer-Servermittel (GIDT) einerseits einen Transaktionsmotor, der Transaktionsereignis-Sendungen erzeugt, die aus dem einen oder dem anderen der folgenden Befehle gebildet sind: BEGIN, COMMIT, ROLLBACK, und andererseits einen Verfolgbarkeitsmotor umfasst, der in dem Speicher jedes Ereignis des Transaktionsmotors und die Gesamtheit der Informationen, die während der Verwendung des Transaktionsidentifizierer-Servermittels gesendet werden, hinterlegt.
Gemäß einem weiteren Merkmal der Erfindung wird der opake Transaktionsidentifizierer an den Mehrwert-Dienstanbieter geschickt, nachdem in dem Speicher des Transaktionsidentifizierer-Servermittels ein Transaktionskontext gespeichert worden ist, der insbesondere angibt:

– die Identifizierungsnummer des Anwenders,
– den Transaktionsidentifizierer,
– das der Transaktion zugeordnetes Angebot,
– den Fortschrittszustand der Transaktion für das ihr zugeordnete Angebot (Anzahl von erledigten Untertransaktionen, noch auszuführende Untertransaktionen,...).

Gemäß einem weiteren Merkmal der Erfindung geht dem Schicken des opaken Transaktionsidentifizierers an den Dienstanbieter außerdem eine Erzeugung eines Transaktionsereignisses vorher, das einen Beginn einer Transaktion an wenigstens ein externes System über eine zweite Kommunikationsschnittstelle des Transaktionsidentifizierer-Servermittels, die Transaktionsmeldeschnittstelle genannt wird, darstellt.
Gemäß einem weiteren Merkmal der Erfindung erfolgt die Erzeugung eines Transaktionsereignisses, das einen Beginn einer Transaktion an wenigstens ein externes System darstellt, durch einen Befehl BEGIN, der durch einen Transaktionsmotor des Transaktionsidentifizierer-Servermittels erzeugt wird.
Gemäß einem weiteren Merkmal der Erfindung überträgt das Transaktionsidentifizierer-Servermittel von der Transaktionsmeldeschnittstelle an wenigstens ein externes System Daten, die die vollständige Ausführung des Angebots durch einen von dem Transaktionsmotor erzeugten Befehl COMMIT darstellen, um dem externen System, beispielsweise einem Fakturierungssystem, anzuzeigen, dass die Transaktion vollständig ausgeführt worden ist.
Gemäß einem weiteren Merkmal der Erfindung sendet das Transaktionsidentifizierer-Servermittel über die Transaktionsmeldeschnittstelle ein Transaktionsereignis des Typs ROLLBACK-Wiederaufnahmeende, um wenigstens einem externen System zu melden, dass die Anzahl von Wiederaufnahmevorgängen der Transaktion bei einem Fehler überschritten ist und dass die Transaktion annulliert wird, um an einem Dialog-Manager Daten zu liefern und um den Dienst zu fakturieren oder nicht.
Gemäß einem weiteren Merkmal der Erfindung führen die Management- und Steuermittel des Transaktionsidentifizierer-Servers die Analyse der Transaktionseröffnungsanforderung aus, insbesondere für die Auflösung einer Entsprechung zwischen einer technischen Adresse des in der Transaktionseröffnungsanforderung gemeldeten Dienstes und einem verzeichneten Dienstangebot unter mehreren Dienstangebot-Beschreibungen, die im Speicher des Transaktionsidentifizierer-Servermittels gespeichert sind.
Gemäß einem weiteren Merkmal der Erfindung speichert der Speicher des Transaktionsidentifizierer-Servermittels Beschreibungen von Dienstangeboten, die von den Anbietern validiert werden, die über eine dritte Kommunikationsschnittstelle, die Dienstbeschreibungs-Lieferschnittstelle genannt wird, erfasst werden.
Gemäß einem weiteren Merkmal der Erfindung umfasst die Beschreibung eines Dienstangebots Daten, die in einer Metasprache oder in äquivalenter Form formuliert sind, was den Steuermitteln des Transaktionsidentifizierer-Servermittels ermöglicht, den richtigen Ablauf des Dienstes zu steuern und hiervon den Anfang und das Ende zu erfassen.
Gemäß einem weiteren Merkmal der Erfindung umfasst das Transaktionsidentifizierer-Servermittel eine zusätzliche Kommunikationsschnittstelle, die für die Mehrwert-Dienstanbieter bestimmt ist, wobei die erste Schnittstelle für die Serverelemente bestimmt ist.
Gemäß einem weiteren Merkmal der Erfindung weist das Transaktionsidentifizierer-Servermittel eine interne Logik auf, die die folgenden Abläufe ausführt: Start, Completed, Error, Mask, Unmask, Update, OpenTransaction, CloseTransaction.
Gemäß einem weiteren Merkmal der Erfindung erzeugt der Vorgang Start des Transaktionsidentifizierer-Servermittels einen Transaktionsidentifizierer, erzeugt im Speicher einen Transaktionskontext, erzeugt ein Transaktionsereignis des Typs BEGIN und leitet den Transaktionsidentifizierer zu dem Dienstanbieter zurück.
Gemäß einem weiteren Merkmal der Erfindung stellt der Vorgang Completed des Transaktionsidentifizierer-Servermittels durch einen Test fest, ob eine Untertransaktion der Transaktion ausgeführt worden ist, modifiziert als Folge den Transaktionskontext, stellt durch Untersuchen der Beschreibung des Angebots fest, ob es notwendig ist, dass das Transaktionsidentifizierer-Servermittel ein externes Ereignis abwartet, lässt die Logik entweder eine Ablaufzeit "TimeOut" warten oder lässt die Transaktion schließen "CloseTransaction", verifiziert, ob die Transaktion beendet ist, und erzeugt ein Transaktionsereignis des Typs COMMIT.
Gemäß einem weiteren Merkmal der Erfindung verifiziert der Vorgang Error des Transaktionsidentifizierer-Servermittels, ob die Wiederaufnahmeanzahl bei einem Fehler überschritten ist, und erzeugt im positiven Fall ein Transaktionsereignis des Typs ROLLBACK.
Gemäß einem weiteren Merkmal der Erfindung wird der Vorgang Mask durch ein "Enabler"-Serverelement ausgesendet, um die Informationen des anhand der technischen Adresse und der mehreren Angebote angesprochenen Angebots wiederzugewinnen, den Zugriff eines auf das Dienstangebot abonnierten Anwenders zu steuern und entweder eine Zugriffsverweigerung auszusenden oder den Vorgang Start auszulösen.
Gemäß einem weiteren Merkmal der Erfindung wird der Vorgang Unmask von einem "Enabler"-Serverelement ausgesendet, um die Informationen des Angebots, das anhand von Daten, die die technische Adresse und den Transaktionsidentifizierer (trid) repräsentieren, und anhand des Katalogs der Angebote angesprochen wird, wiederzugewinnen, um den Zugriff eines Partner-Anwenders auf das "Enabler"-Serverelement zu steuern, um zu verifizieren, dass die an das Serverelement gerichtete Anforderung mit dem aktuellen Kontext der Transaktion in Übereinstimmung ist, und um dem Serverelement zu melden, dass das Transaktionsidentifizierer-Servermittel auf eine Aktualisierung wartet, um die MSISDN-Nummer, die dem opaken Transaktionsidentifizierer zugeordnet ist, zurückzuleiten, um auf die Aktualisierung zu warten und um zu verifizieren, dass die empfangene Aktualisierung die Informationen enthält, die für die Ausführung des An gebots notwendig sind, um entweder einen Vorgang Completed oder einen Vorgang Error auszusenden.
Gemäß einem weiteren Merkmal der Erfindung wird der Vorgang Update von einem "Enabler"-Serverelement ausgesendet und ist durch das Versetzen in einen Zustand des Wartens auf die Aktualisierung bezüglich der Ausführung der Anforderung des Transaktionsidentifizierer-Servers gebildet.
Gemäß einem weiteren Merkmal der Erfindung wird der Vorgang OpenTransaction von einem Dienstanbieter mit zugeschriebenem Wert ausgesendet, um den Zugriff eines Partners auf einen Abonnenten des Operators zu steuern und um entweder eine Zugriffsverweigerung zu erzeugen oder einen Vorgang Start auszulösen.
Gemäß einem weiteren Merkmal der Erfindung wird der Vorgang CloseTransaction von einem Mehrwert-Dienstanbieter ausgesendet und erzeugt ein Ereignis, das die Entriegelung des Wartens "TimeOut" der Logik des Transaktionsidentifizierer-Servermittels ermöglicht.
Die Erfindung mit ihren Merkmalen und Vorteilen wird deutlicher beim Lesen der Beschreibung, die unter Bezugnahme auf die begleitende Zeichnung erstellt worden ist, die anhand von nicht einschränkenden Beispielen gegeben wird und worin:
1 schematisch ein Beispiel eines in der Erfindung ausgeführten Prozesses in einer Variante im Modus Push/MT zeigt,
2 drei Verknüpfungsglieder zeigt, die von dem Identifizierer-Servermittel verwendet werden,
3 Schemata von Zustandslogiken zeigt, die den Interaktionen zwischen den "Enabler"-Serverelementen des Netzes und dem Identifizierer-Servermittel zugeordnet sind,
4 ein Beispiel für Zustandslogiken zeigt, die den Interaktionen zwischen Mehrwert-Dienstanbietern und dem Identifizierer-Servermittel zugeordnet sind,
5 schematisch ein Beispiel eines in der Erfindung ausgeführten Prozesses in einer Variante im Modus Pull/MO zeigt. Ferner präzisiert der Anhang die in der vorliegenden Anmeldung verwendeten Abkürzungen.
Die Erfindung wird nun in Verbindung mit den 1 und 2 beschrieben.
Das erfindungsgemäße Verfahren wird über ein Transaktionsidentifizierer-Servermittel ausgeführt, das im Folgenden als Transaktionsidentifizierer-Manager (GIDT) bezeichnet wird. Dieses Identifizierer-Servermittel (GIDT) ermöglicht das Zuordnen eines Identifizierungselements (Userid), das einem Anwender (oder einer Gruppe von Anwendern) entspricht, für eine Transaktion oder eine Untertransaktion auf einen gegebenen Dienst. Dieser Transaktionsidentifizierer (trid) wird als Substitution der MS-ISDN-(Mobile Station – Integrated Services Digital Network)-Nummer in der Kommunikation mit den Dienstanbieter-Partnern (33) wie etwa VASP, Anbietern spezieller Anwendungen und Portale oder anderen Partnern verwendet und besitzt als eine Eigenschaft, mit der Empfehlung einer normierten Nummerierungsebene wie beispielsweise UIT-T E.164 konform zu sein, was eine Folge von höchstens 15 Stellen erfordert, von denen ein Informationsteil das Identifizieren des Operators, der geeignet ist, diesen Transaktionsidentifizierer (trid) zu interpretieren, ermöglichen kann. Der Transaktionsidentifizierer-Manager (GIDT) umfasst eine erste Kommunikationsschnittstelle (21), um die Übertragung von Daten mit Servern oder Enabler (31) zu ermöglichen. Dieser Manager (GIDT) umfasst außerdem eine zweite Kommunikationsschnittstelle (22), die Transaktionsmeldeschnittstelle genannt wird und die die Erzeugung von Transaktionsereignissen ermöglicht, die einen Beginn (ST), eine Erledigung (CT) oder eine Annullierung (ET) einer Transaktion an ein beliebiges externes System (40) darstellen. Diese Schnittstelle (22) ermöglicht beispielsweise das Verbinden des Managers (GIDT) mit einem oder mehreren externen Fakturierungssystemen (40) und/oder mit einem Dialog-Manager.
Wie in 1 gezeigt ist, umfasst der Transaktionsidentifizierer-Manager (GIDT) ein Management-Modul (27), das ermöglicht, einem Anwender oder einer Gruppe von Anwendern und wenigstens einem bestimmten Dienst einen so genannten transaktionellen Identifizierer oder Transaktionsidentifizierer (trid) zuzuordnen. Der Manager (GIDT) kann beispielsweise das Abonnement der Anwender auf Dienstangebote bei Dienstanbietern (33) managen. In einer Variante kann sich der Transaktionsidentifizierer-Manager (GIDT) auch mit einem Abonnnement-Manager verbinden. Der Speicher (25) des Managers (GIDT) ermöglicht insbesondere das Speichern von durch die Anbieter (31) validierten Dienstangebotsbeschreibungen sowie das Speichern mehrerer Transaktionskontexte, die sich auf einen Anwender oder eine Gruppe von Anwendern beziehen, für einen Dienst. Jeder Transaktionskontext gibt insbesondere die Identifizierungsnummer (Userid) des Anwenders, den Transaktionsidentifizierer (trid), das der Transaktion zugeordnete Angebot und den Fortschrittszustand der Transaktion an. Dieser Fortschrittszustand kann beispielsweise durch die Anzahl erledigter Untertransaktionen (R'), noch auszuführender Untertransaktionen (R') usw. beschrieben sein. Die Dienstangebotsbeschreibungen können durch ein Beschaffungssystem (32) mit einer dritten Kommunikationsschnittstelle, die Dienstbeschreibungs-Lieferschnittstelle (IFDS) genannt wird, erfasst werden.
Wie in 1 gezeigt ist, kann der Transaktionsidentifizierer-Manager (GIDT) im Herz einer Logikplattform angeordnet sein, die geeignet ist:

– die Transaktionsidentifizierer (trid) zu managen,
– die statistischen Informationen der Zugriffe auf die Demaskierungsanforderungen durch die Enabler (31) des Netzes zu managen,
– eine Darstellung des Dienstes und insbesondere seiner Abfolge/seines Ablaufs zu speichern,
– den Ablauf eines Dienstes zu steuern und folglich seine Ausführung von Anfang bis Ende zu gewährleisten,
– Transaktionsauslöser, beispielsweise BEGIN (ST), um zu beginnen, COMMIT (CT), um auszuführen, ROLLBACK (ET), um zu annullieren, zu senden (2).

Um die Transaktionsidentifizierer (trid) managen zu können, ist das Management-Modul (27) mit dem Speicher (25) und mit der Dienstbeschreibungs-Lieferschnittstelle (IFDS) verbunden. In einer Ausführungsform der Erfindung speichert der Speicher (25) des Transaktionsidentifizierer-Managers (GIDT) durch das Beschaffungssystem (32) übertragene Dienstangebotsbeschreibungen als Dienstbeschreibungen, die die Lieferschnittstelle (IFDS) verwendet. Dieses Beschaffungssystem (32), die die Partner-Anbieter (33) berücksichtigen, ermöglicht das Liefern einer vollständigen Beschreibung eines Dienstes. In einer Ausführungsform der Erfindung speichert der Speicher (25) Beschreibungen, die die Dienste, insbesondere die Kommunikationsweise mit den Enabler-Elementen (LOC, SMS, MMS), die Teil des Angebots sind, näher angeben. Diese Beschreibung könnte anhand einer Metasprache, beispielsweise Regulärer Ausdruck, XML-Schema oder DTD, oder in irgendeiner anderen Form, die dem Transaktionsidentifizierer-Manager (GIDT) das Steuern des richtigen Ablaufs eines Dienstes und das Erkennen dessen Anfangs und dessen Endes ermöglicht, definiert sein. Die Partner-Anbieter (33) haben von der Beschreibungsweise ihres Dienstes Kenntnis, derart, dass ein Angebot, das der erwarteten Beschreibung entspricht und einen oder mehrere Dienste einbezieht, wirksam verwirklicht werden kann.
Beispielsweise kann im Fall eines Dienstangebots, das einen Lokalisierungs-Enabler (LOC), einen Kurznachrichten-Enabler (SMS) und einen Multimedia-Nachrichten-Enabler (MMS) einschaltet, die Beschreibung des Dienstes in der folgenden Form wiedergegeben sein: "(SMS_MO, LOC, MMS)", d. h., dass der vollständige Dienst aus einem SMS_MO, einer Lokalisierungsanfrage und dem Schicken einer Multimedia-Nachricht zusammengesetzt sein muss. In einem weiteren Beispiel kann die Beschreibung wie folgt formuliert sein: "(LOC, WAP-PUSH+, [close-transaction|timeout(2 Tage)])", was bedeutet, dass der Dienst aus einer Lokalisierungsanfrage, gefolgt von 1 bis n push WAP, zusammengesetzt sein muss. Das Ende des Dienstes wird entweder nach einer Wartezeit, timeout genannt, oder durch einen Befehl zum Schließen der Transaktion, close-transaction genannt, explizit für einen Enabler-Server (31) oder den Dienstanbieter (33), ausgelöst.
Die Dienstbeschreibung kann außerdem einem Enabler-Serverelement (31) den Inhalt jeder Anforderung wie beispielsweise "(SMS_MO:'^BLAGUE*', MMS)" näher angeben, um mitzuteilen, dass der Dienst aus einem SMS_MO, das mit BLAGUE beginnt, und einer Multimedia-Nachricht zusammengesetzt sein muss. In einer Ausführungsvariante der Erfindung kann die Beschreibung des Dienstes eventuell Transaktionsunterabschnitte enthalten, die beispielsweise in verschachtelter Form definiert sein können. So können im Fall einer Beschreibung XML die Import- oder Verweismechanismen verwendet werden. In diesem bestimmten Fall kann die Ausführung eines Dienstes durch die Ausführung von Transaktionsunterabschnitten bedingt sein. Die Letzteren werden eventuell durch ein externes Fakturierungssystem (40) getrennt berechnet. Die Enabler-Server (LOC, SMS, MMS) von 1 sind nur beispielhalber angeführt. In dem mit dem Transaktionsidentifizierer-Manager (GIDT) ausgeführten Prozess kann ein beliebiges anderes Enabler-Serverelement wie etwa CAMEL, WAP-server usw. verwendet werden.
In einer Ausführungsform der Erfindung umfasst das Transaktionsidentifizierer-Servermittel (GIDT) eine zusätzliche Kommunikationsschnittstelle (23), die für die Mehrwert-Dienstanbieter (33) oder dergleichen vorgesehen ist, wobei die erste Schnittstelle (21) für die Serverelemente (LOC, SMS, MMS) des Netzes vorgesehen sind. Diese zusätzliche Schnittstelle (23) ermöglicht einem Partner-Anbieter (33) das Eröffnen einer Transaktion für einen gegebenen Anwender auf einen Diensttyp. Diese Schnittstelle (23) ist nur in dem Fall erforderlich, in dem ein Dienstanbieter (33) den Dienst zum Abonnenten hin, d. h. im Modus PUSH wie beispielsweise in der Ausführungsform von 1, initiiert. Im Fall einer offenen Dienstbeschreibung kann dem Partner-Anbieter (33) des Typs VASP oder dergleichen ein Ablauf oder Vorgang zur Verfügung stehen, der ihm das Mitteilen ermöglicht, dass von seiner Seite der Dienst ausgeführt worden ist. Da im Übrigen diese zusätzliche Schnittstelle (23) optional ist, bildet der Manager (GIDT) in den meisten Fällen eine für die VASP-Partner oder vergleichbaren Partner transparente Komponente.
Die Erfindung wird nun in Verbindung mit 2 beschrieben.
2 zeigt drei Verknüpfungsglieder einer internen Logik, die von dem Management-Modul (27) verwendet werden, um mit einem opaken Transaktionsidentifizierer (trid) des Anwenders die vollständige Lieferung des Dienstes gemäß dem Prozess der Erfindung zu managen. Unter den drei durch diese interne Logik verwirklichten Abläufen führt der allgemein mit START (S) bezeichnete Ablauf nach vorheriger Wiedergewinnung (SO) der MSISDN-Identifizierungsnummer (Userid) nacheinander die folgenden Operationen aus:

– Erzeugen (S1), nachdem die Daten, darunter insbesondere die MSISDN-Nummer geliefert worden sind, eines Transaktionsidentifizierers,
– Erzeugen (S2) eines Transaktionskontextes, der die MSISDN-Identifizierungsnummer (Userid), den Transaktionsidentifizierer (trid), das der Transaktion zugeordnete Angebot und den Fortschrittszustand der Transaktion umfasst,
– Speichern des Transaktionskontextes in dem Speicher (25) des Managers (GIDT),
– Erzeugen eines Transaktionsereignisses BEGIN (ST), das zu den externen Systemen (40) geschickt wird, um den Beginn der Transaktion mitzuteilen, anschließend
– Schicken (3) des Transaktionsidentifizierers (trid), der dem Dienst entspricht, durch den Transaktionsidentifizierer-Manager (GIDT) an den Dienstanbieter (31).

Der allgemein mit Completed (C) bezeichnete Vorgang des Transaktionsidentifizierer-Servermittels (GIDT) ermittelt durch einen Test (C1), ob eine Unter transaktion der Transaktion ausgeführt worden ist (CO), modifiziert dann (C2) als Folge den Transaktionskontext. Außerdem stellt der Vorgang Completed (C) durch Untersuchen der Beschreibung des Angebots (C3) fest, ob es notwendig ist, dass das Transaktionsidentifizierer-Servermittel (GIDT) ein externes Ereignis abwartet, lässt die Logik entweder eine Ablaufzeit "TimeOut" warten (C5) oder lässt die Transaktion schließen "CloseTransaction". Schließlich ermöglicht dieser Vorgang das Verifizieren (C4), ob die Transaktion beendet ist, und das Erzeugen eines Transaktionsereignisses des Typs COMMIT (CT). Es ist deutlich geworden, dass das dem Vorgang COMPLETED (C) entsprechende Verknüpfungsglied das Ausführen einer Steuerung des Verlaufs der Transaktion ermöglicht. Mit diesem Vorgang können innerhalb derselben Transaktion nacheinander mehrere Untertransaktionen (R') ausgeführt werden. In der Ausführungsform von 2 umfasst der Vorgang COMPLETED (C) somit die folgenden Operationen:

– eventuell, Testen (C1) der Steuerung des Endes der Ausführung (CO) einer Untertransaktion (R') und Modifizieren (C2) des in dem Transaktionskontext gespeicherten Fortschrittszustands der Transaktion, indem dort die ausgeführte Untertransaktion (R') integriert wird,
– Durchsuchen der Beschreibung des Angebots (C3), um festzustellen, ob es notwendig ist, dass der Manager (GIDT) ein äußeres Ereignis abwartet,
– in einem ersten Fall, Versetzen der Logik in das Warten (C5) auf ein Ereignis, wobei dieses Warten mit dem Verstreichen einer Zeit oder Verzögerung "TimeOut" oder mit dem Schließen der Transaktion "CloseTransaction" endet, andernfalls, wenn auf kein bestimmtes Ereignis gewartet wird, Verifizieren (C4) des Fortschrittszustands der Transaktion, anschließend,
– Erzeugen eines Transaktionsereignisses COMMIT (CT), das zu den externen Systemen (40) geschickt wird, um das Ende der Untertransaktion mitzuteilen.

Der Transaktionsidentifizierer-Manager (GIDT) kann von der Transaktionsmeldeschnittstelle (22) zu einem beliebigen externen System (40) Daten, die die vollständige Ausführung eines Dienstes repräsentieren, durch den Befehl COMMIT (CT) übertragen, der durch den Transaktionsmotor (28) erzeugt wird, um dem externen System (40), beispielsweise einem Fakturierungssystem, anzugeben, dass die Transaktion vollständig ausgeführt ist. Der Manager (GIDT) speichert ferner diese Entwicklung des Transaktionskontextes in dem Speicher (25). Der Schritt des Verifizierens (C4) ermöglicht insbesondere das Treffen der Unterscheidung zwischen dem Ende der gesamten letzten Untertransaktion (R') und dem Ende einer dazwischen liegenden Untertransaktion (R'). Der Fortschrittszustand der Ausführung der Transaktion kann folglich ermittelt werden.
Die interne Logik des Transaktionsidentifizierer-Servermittels (GIDT) wickelt außerdem einen allgemein mit ERROR (E) bezeichneten Vorgang ab, der ermöglicht, das Auftreten eines Fehlers, der in dem erfindungsgemäßen Prozess eine Auswirkung hat, zu erfassen und mitzuteilen. Von einem Vergleichs- oder Komparatormittel, das die Anzahl von Wiederaufnahmen bei einem Fehler verifiziert, wird ein Fehlercode (EO) empfangen. Ein Vergleich (E1) wird zwischen der Anzahl von Wiederaufnahmen bei einem Fehler und einer vorgegebenen Schwelle ausgeführt. Solange die Schwelle nicht erreicht ist, wird der Fehler ignoriert (E2) und bringt keine Konsequenz für den Transaktionskontext mit sich. Andernfalls wird ein Transaktionsereignis ROLLBACK (ET) zu den externen Systemen (40) geschickt, um den Transaktionskontext zu annullieren. In einer Ausführungsform wird der Transaktionsidentifizierer (trid) sogleich unterdrückt.
Die Erfindung wird nun in Verbindung mit den 1, 2 und 3 beschrieben.
Die erste Kommunikationsschnittstelle (21) ermöglicht das Initialisieren einer Transaktion für einen gegebenen Dienst und einen gegebenen Anwender. Sie verschafft außerdem einen Zugriff auf die Demaskierungsanforderung (5, 10) des Transaktionsidentifizierers (trid), die von einem Enabler-Element (31) initiiert wird. Diese Anforderung (5, 10) ermöglicht die meiste Zeit das Wiederfinden der Identifizierungsnummer (Userid), die beispielsweise durch die MSISDN-Nummer gebildet ist. Es ist außerdem möglich, eine an diese Schnittstelle (21) adressierte Anforderung (301) nach einer Aktualisierung oder Update auszuführen. Wie in 3 gezeigt ist, kann die Anforderung (301) Update zum Aktualisieren der kon kreten Ausführung der Enabler-Anforderung (LOC, SMS, MMS) bis zu dem auf das Dienstangebot abonnierten Anwender hin zugeordnet sein, mit dem Ziel, die richtige Lieferung des Dienstes sicherzustellen. Die Anforderung Update ist beispielsweise auch dem Inhalt der Informationen, die das Enabler-Element (31) zu dem Abonnenten befördert, zugeordnet, um das Verifizieren des Inhalts des Dienstes zu ermöglichen.
In einer Ausführungsform der Erfindung wird der Aktualisierungsvorgang Update durch ein Enabler-Serverelement (31) gesendet. Er ist durch das Versetzen des Transaktionsidentifizierer-Servers (GIDT) bezüglich der Ausführung der Anforderung in einen Wartezustand gebildet. Die Aktualisierung kann in einer zur Ausführung der Anforderung an ein Enabler-Element (31) synchronen Weise ausgeführt werden, jedoch kann sie das transaktionelle COMMIT (CT) des gesamten Dienstangebots oder eines Teils von diesem bedingen. Beispielsweise können im Fall eines Kurznachrichten-(SMS)-Enabler asynchrone Nachrichten zur Auslieferungsbenachrichtigung verwendet werden, um sicherzustellen, dass der Inhalt an den Anwender ausgestellt worden ist.
Der erfindungsgemäße Prozess kann sowohl im Modus Push/MT als auch im Modus Pull/MO ablaufen, wobei das Senden einer Anforderung zum Eröffnen der Transaktion (1) wenigstens eines bestimmten Dienstes entweder durch einen Anwender oder durch eine Dienstanbieter (33) initiiert werden kann. Im Beispiel von 1 verlangt der Anbieter (33) vom Manager (GIDT) das Eröffnen einer Transaktion auf Rechnung eines Anwenders, der in der Anforderung durch einen Identifizierer (Userid) des Typs Telephonnummer oder irgendeinen anderen Anwenderidentifizierer dargestellt ist. Diese Anforderung (1) wird im Modus Push an die erste Kommunikationsschnittstelle (21) des Managers (GIDT) adressiert. Der Letztere nimmt dann über Management- und Steuermittel (26, 27) des Managers (GIDT) die Analyse (1') der Anforderung (1) vor, um die Entsprechung des den Gegenstand der Anforderung bildenden Dienstes mit einem verzeichneten Dienstangebot unter den mehreren in dem Speicher (25) gespeicherten Dienstangeboten zu verifizieren. Diese Management- und Steuermittel (26, 27) führen die Analyse (1') insbesondere durch Auflösung einer Entsprechung zwischen einer in der Anforderung (1) zum Eröffnen einer Transaktion mitgeteilten technischen Dienstadresse und einem verzeichneten Dienstangebot unter den mehreren in dem Speicher (25) des Identifizierer-Servermittels (GIDT) gespeicherten Dienstangebotbeschreibungen aus. In der Ausführungsform von 1 wird in die Anforderung zum Eröffnen einer Transaktion (1) eine technische Adresse eingefügt, um den Dienst, der durch den Anbieter (31) geliefert wird, der die Anforderung (1) ausgelöst hat, zu beschreiben. Diese technische Adresse wird durch den Manager (GIDT) "aufgelöst", wobei der Letztere dieser technischen Adresse einen Transaktionsidentifizierer (trid) zuordnet.
In einer Ausführungsform der Erfindung umfasst der Analyseschritt (1') eine durch das Management-Modul (27) erfolgende Verifikation der Entsprechung der "Enabler"-Serverelemente (31), die in der technischen Adresse bezeichnet sind, mit einem für den Anwender zugänglichen verzeichneten Dienstangebot unter den mehreren Dienstangeboten sowie eine Steuerung der Berechtigung zum Eröffnen der Transaktion durch die Steuermittel (26) des Transaktionsidentifizierer-Servermittels (GIDT) für den von diesen "Enabler"-Serverelementen (31) gelieferten Dienst und den bestimmten Anwender insbesondere in Abhängigkeit von der Anwenderidentifizierung (Userid). Der Schritt der Ausführung (R) der Transaktion, die den opaken Transaktionsidentifizierer (trid) verwendet, folgt auf den Schritt der Analyse (1') der Anforderung (1).
In der Ausführungsform von 1 betrifft die von dem Dienstanbieter (33) ausgesendete Anforderung zum Eröffnen einer Transaktion (1) einen Dienst, der drei "Enabler"-Serverelemente (LOC, SMS, MMS), die Untertransaktionen (R') ausführen, erfordert. Diese an die Kommunikationsschnittstelle (23) mit den Anbietern des Transaktionsidentifizierer-Managers (GIDT) adressierte Anforderung (1) kann mit einem Satz von offenen Primitiven in sequentieller Weise beschrieben werden und teilt eine Anwenderidentifizierung (Userid) mit. In einer weiteren Ausführungsform der Erfindung kann die Anforderung (1) wenigstens einen Dienst betreffen, der eines oder mehrere "Enabler"-Serverelemente (31) erfordert.
Der Schritt der Ausführung (R) der Transaktion wird durch den Dienstanbieter (33) initiiert, nachdem er den opaken Transaktionsidentifizierer (trid) empfangen hat. Der Dienstanbieter (33) führt mit Transaktionsidentifizierer (trid) als Parameter eine Anfrage an einen bestimmten Server (LOC, SMS, MMS) unter den Enabler-Serverelementen (31) nach einem bestimmten Dienst aus, der eine Untertransaktion (R') bildet, wie in 1 gezeigt ist. In Reaktion auf diese Anfrage schickt das bestimmte Enabler-Serverelement (LOC, SMS, MMS) eine Demaskierungsanforderung (5, 10) "unmask" an den Transaktionsidentifizierer-Manager (GIDT), um anhand des opaken Identifizierers (trid) die Lieferung einer nicht opaken Identifizierungsnummer (Userid), die dem Transaktionsidentifizierer (trid) entspricht, zuzulassen. Anschließend wird von den Steuermitteln (26) des Transaktionsidentifizierer-Servermittels (GIDT) eine Steuerung (5', 10') ausgeführt, um zu verifizieren, ob das bestimmte "Enabler"-Serverelement (LOC, SMS, MMS) für diesen Dienst und für diesen Anwender berechtigt ist oder nicht, derart, dass im Fall der Berechtigung die nicht opake Identifizierungsnummer (Userid) über die erste Kommunikationsschnittstelle (21) an das bestimmte Serverelement (LOC, SMS, MMS) übertragen wird (7, 12), um die Ausführung der Untertransaktion (R') zu ermöglichen.
Im Beispiel von 1 betrifft die erste Untertransaktion (R') einen Lokalisierungsdienst, der einen Lokalisierungsserver (LOC) einschaltet. Diese erste Untertransaktion (R') beginnt mit einer Lokalisierungsanfrage (4), die durch den Dienstanbieter (33) ausgeführt wird und mit dem Transaktionsidentifizierer (trid) als Parameter an den Lokalisierungsserver (LOC) adressiert ist. Nach dem Empfang der nicht opaken Identifizierungsnummer (Userid), die durch den Manager (GIDT) übertragen wird (7), überträgt (8) der Lokalisierungsserver (LOC) die verlangten Lokalisierungsinformationen an den Dienstanbieter (31).
In der bevorzugten Ausführungsform der Erfindung umfasst der Transaktionsidentifizierer-Manager (GIDT) einerseits einen Transaktionsmotor (28), der Transaktionsereignis-Sendungen erzeugt, die aus dem einen oder dem anderen der folgenden Befehle gebildet sind: BEGIN (ST), COMMIT (CT), ROLLBACK (ET), und andererseits einen Verfolgbarkeitsmotor (29), der in dem Speicher (25) jedes Ereignis des Transaktionsmotors (28) und die Gesamtheit der Informationen, die während der Verwendung des Transaktionsidentifizierer-Managers (GIDT) gesendet werden, hinterlegt. Wie in 1 gezeigt ist, folgt dem Analyseschritt (1') mit der Steuerung der Berechtigung für das Eröffnen der Transaktion unmittelbar das Schicken eines Transaktionsbeginnereignisses in Form eines von dem Transaktionsmotor (28) erzeugten Befehls BEGIN (ST) an wenigstens ein externes System (40). Die Erzeugung des Transaktionsbeginnereignisses wird über die Transaktionsmeldeschnittstelle (22) des Managers (GIDT) ausgeführt.
Das externe System (40) kann beispielsweise aus einem Fakturierungssystem, um einen Fakturierungsschein zu reservieren, bestehen. Dem Analyseschritt (1') folgt außerdem eine Registrierung durch den Verfolgbarkeitsmotor (29) von Statistiken des Eröffnens eines Dienstes, die im Wesentlichen zum selben Moment wie die Erzeugung des Befehls BEGIN (ST) ausgeführt wird. Sobald das Transaktionsbeginnereignis an das externe System (40) geschickt worden ist, kann eine Untertransaktion (R') ausgeführt werden. Der Verfolgbarkeitsmotor (29) registriert außerdem Statistiken (6, 11) am Ende jeder der Untertransaktionen (R'). Der Transaktionskontext wird am Ende der Ausführung einer Untertransaktion (R') aktualisiert. Natürlich können Systeme des Typs Dialog-Manager IHM, Zahlungssysteme nach Leistung oder Pauschale und andere gleich geartete Systeme zu dem Transaktionsmotor (28) hinzukommen. In einer Ausführungsform der Erfindung verfügt der Verfolgbarkeitsmotor (29) über sämtliche Informationen, die durch die Verwendung des Transaktionsidentifizierer-Managers (GIDT) gesendet werden, beispielsweise über die Steuerung des Zugriffs, unabhängig davon, ob diesem zugestimmt wird oder nicht, über die Ausführung des Angebots, unabhängig davon, ob dieses vollständig oder in Abwicklung ist, usw.
Im Beispiel von 1 setzt die zweite Untertransaktion (R') einen Kurznachrichtenserver (SMS) ein, wobei der Dienstanbieter (33) eine Anfrage (4) an den Server (SMS) ausführt. Die Kommunikationsweise gleicht dem oben bei der Untertransaktion (R') mit dem Lokalisierungsserver (LOC) erwähnten Fall. Diesmal sendet (13) der Server (SMS), nachdem er die nicht opake Identifizierungsnummer (Userid), die von dem Manager (GIDT) gesendet wird (12), empfangen hat, die verlangten Informationen der Kurznachrichten an den Dienstanbieter (33). Eine dritte Untertransaktion setzt einen Enabler-Server für Multimedia-Nachrichten (MMS) ein. Im Beispiel für diese dritte Untertransaktion wird durch den Manager (GIDT) eine Inkohärenz zwischen der in dem Speicher (25) gespeicherten Dienstbeschreibung und der Anforderung zum Aufruf des Enabler-Servers für Multimedia-Nachrichten (MMS) erfasst. Ein solcher Fehler kann beispielsweise erfasst werden, wenn die Beschreibung des Dienstes das Schicken einer Email vorsieht. Die zwei ersten Schritte (14, 15) gleichen den zwei ersten Schritten (4, 5) der ersten Untertransaktion (R'), die den Lokalisierungsserver (LOC) betrifft. Dann wird die Inkohärenz bei der Ausführung des Demaskierungsvorgangs erfasst, wie durch die 3 entsprechende schematische Darstellung gezeigt ist. Der Verfolgbarkeitsmotor (29) registriert statistische Informationen (16), die den Misserfolg der Transaktion repräsentieren. Anschließend schickt der Transaktionsidentifizierer-Manager (GIDT) über die erste Kommunikationsschnittstelle (21) eine negative Antwort (17) an das Enabler-Serverelement (MMS). Das Letztere (MMS) teilt dem Dienstanbieter (31) die Verweigerung der Berechtigung (18) zum Schicken einer kurzen Multimedia-Nachricht mit. Um abzuschließen, sendet der Transaktionsidentifizierer-Manager (GIDT) über die Transaktionsmeldeschnittstelle (22) ein Transaktionsereignis des Typs Wiederaufnahmeende ROLLBACK (ET), um dem externen System (40) mitzuteilen, dass der Dienst von Anfang bis Ende fehlgeschlagen ist und die Häufigkeit der Wiederaufnahme der Transaktion bei einem Fehler überschritten ist. Dieses Transaktionsereignis ROLLBACK (ET) meldet, daß die Transaktion annulliert ist. In einer Ausführungsform der Erfindung werden die mit dem Transaktionsereignis ROLLBACK (ET) gelieferten Daten an einen Dialog-Manager übertragen und ermöglichen gegebenenfalls das Fakturieren des Dienstes.
Die Erfindung wird nun in Verbindung mit den 3 und 4 beschrieben.
3 zeigt die Abläufe oder Vorgänge mit den Interaktionen zwischen den Enabler-Serverelementen (31) und dem Manager (GIDT) zugeordneten logischen Zuständen. Der Mask genannte Maskierungsvorgang des Transaktionsidentifizierer-Managers (GIDT) findet in einer ersten Zeit (202) die Informationen des angesprochenen Angebots (203) für den Identifizierer (Userid) anhand der technischen Adresse (201) und der mehreren in dem Speicher (25) gespeicherten Dienstangebote. Anschließend steuert der Vorgang Mask den Zugriff (204) eines auf das Dienstangebot (203) abonnierten Anwenders und sendet entweder eine Zugriffsverweigerung (R1) oder löst den Vorgang Start (S) aus.
Der Unmask genannte Demaskierungsvorgang des Transaktionsidentifizierer-Managers (GIDT) findet in einer ersten Zeit (205) die Informationen des angesprochenen Angebots (206) anhand von Daten, die die technische Adresse und den Transaktionsidentifizierer (trid) repräsentieren, und anhand der mehreren Angebote. Anschließend, wie in 3 gezeigt ist, steuert der Vorgang Unmask den Zugriff (207) eines Partners (33) auf das Enabler-Serverelement (LOC, SMS, MMS) und verifiziert (208), ob die an das Serverelement (LOC, SMS, MMS) erstellte Anforderung in Entsprechung mit dem aktuellen Kontext der Transaktion ist. Danach fährt der Vorgang Unmask im Fall, in dem eine Aktualisierung notwendig ist, mit dem Melden an das Enabler-Serverelement (LOC, SMS, MMS), dass der Transaktionsidentifizierer (GIDT) auf eine Aktualisierung wartet, fort, gibt die MSISDN-Nummer oder gleichwertige Identifizierung (Userid), die dem opaken Transaktionsidentifizierer (trid) zugeordnet ist, zurück (210), wartet (211) auf die Aktualisierung Update, verifiziert (302) anschließend, ob die empfangene Aktualisierung die Informationen enthält, die für die Ausführung des Angebots notwendig sind, um entweder einen Vorgang Completed (C) oder einen Vorgang Error (E) auszusenden. Eine Zugriffsverweigerung (R2) wird gemeldet, wenn der Zugriff bei der Steuerung (207) nicht zugelassen worden ist. In der Ausführungsform von 3 beteiligt sich ein Schritt zum Steuern (209) der Aktualisierung nach dem Schritt des Verifizierens (208), um im Fall, in dem die Aktualisierung Update nicht erforderlich ist, die Ausführung des Angebots mit einem Vorgang Completed (C) unmittelbar zu aktivieren.
4 zeigt die Kommunikationsvorgänge zwischen einem Dienstanbieter (33) und dem Transaktionsidentifizierer-Manager (GIDT), die zum Eröffnen und zum Schließen einer Transaktion dienen. Der Vorgang OpenTransaction wird von einem Mehrwert-Dienstanbieter (33) zu der Schnittstelle für Anbieter (23) des Managers (GIDT) gesendet, um den Zugriff eines Partners (33) auf einen Abonnenten des Operators zu steuern (100) und entweder eine Zugriffsverweigerung (R3) zu erzeugen oder einen Vorgang Start (S) auszulösen. Der Vorgang CloseTransaction, der von einem Anbieter (33) zu der Schnittstelle für Anbieter (23) des Managers (GIDT) gesendet wird, erzeugt ein Ereignis, das das Entriegeln des Wartezustands "TimeOut" der Logik des Transaktionsidentifizierer-Managers (GIDT) ermöglicht.
Die Erfindung wird nun in Verbindung mit 5 beschrieben.
Im Modus Pull/MO weist die Kinematik der Lieferung eines Dienstes einige Unterschiede im Vergleich zu einer Arbeitsweise im Modus Push auf. 5 zeigt den Fall eines Dienstes, der in dem Speicher (25) so beschrieben ist, dass er aus einer Lokalisierungsanfrage, der das Schicken einer Kurznachricht SMS folgt, zusammengesetzt ist. Wie im Modus Push wird über den Ablauf des Dienstes, insbesondere die Aufrufe zu den Enabler, in der Beschreibung des Dienstes informiert, wobei die technische Adresse des Dienstanbieters (31) durch den Manager (GIDT) bekannt ist.
Zuallererst muss von einem Anwender eine Anfrage nach einem Dienst über eine Nachricht MO, die über das Mobiltelephon des Anwenders übertragen wird, an ein Enabler-Serverelement für die Nachrichten (SMS) geschickt werden. Das Enabler-Serverelement (SMS) fängt dann die von dem Anwender stammende Anfrage nach einem Dienst ab. Da der Großkunde des Enabler (SMS) einer technischen Adresse des Dienstes zugeordnet ist, verlangt der Enabler (SMS) folglich vom Transaktionsidentifizierer-Manager (GIDT) das Eröffnen (O) einer Transaktion für den Anwender und den betreffenden Dienst. Diese Anforderung zum Eröffnen (O), die an die erste Kommunikationsschnittstelle (21) des Managers (GIDT) adressiert ist, ist mit einem Satz von offenen Primitiven sequentiell be schrieben und teilt eine Identifizierung des Anwenders (Userid) mit. Es wird also eine Analyse (1') der Anforderung (O) ausgeführt, wobei im Fall der Zulassung durch die Steuermittel (26) des Managers (GIDT) von dem Transaktionsmotor (28) ein Befehl BEGIN (ST) erzeugt wird, um dem externen System (40) ein Transaktionsbeginnereignis mitzuteilen.
An den Enabler-Großkunden von Kurznachrichten (SMS) wird ein Transaktionsidentifizierer (trid), der dem Dienst und dem Anwender entspricht, zurück geleitet (3'). Anschließend empfängt (3'') der Mehrwert-Dienstanbieter (33) die Anforderung des Anwenders in Form einer über den Enabler (SMS) geschickten Kurznachricht, ohne jedoch die genaue Identität von diesem zu kennen, da ihm lediglich der Transaktionsidentifizierer (trid) geliefert wird. Die Untertransaktionen (R') können in der gleichen Weise wie bei der Kommunikationsweise im Modus Push ausgeführt werden (1). Am Ende der letzten Untertransaktion (R') erfasst der Transaktionsidentifizierer-Manager (GIDT) den erfolgreichen Abschluss der Ausführung (R) der Transaktion für den Dienst. Er meldet dem externen System (40) durch Erzeugung eines Transaktionsereignisses COMMIT (CT), dass der Dienst für den betreffenden Anwender von Anfang bis Ende ausgestellt worden ist.
Einer der Vorteile des erfindungsgemäßen Verfahrens ist, das Managen eines Dienstsitzung mit einem Abonnenten, die mehrere Enabler des Netzes des Operators verwendet, zu ermöglichen, indem es Ereignisse über den Fortschritt ihrer Ausführung erzeugt, was beispielsweise das Fakturieren eines Dienstes in Abhängigkeit von der Anzahl wirklich ausgeführter Untertransaktion ermöglicht.
Ein weiterer der Vorteile der Erfindung im Vergleich zu vorhandenen Techniken ist, dass der Operator die Vertraulichkeit der Daten des Anwenders gegenüber Dienstanbietern garantieren kann.
Für Fachleute auf dem Gebiet ist erkennbar, dass die vorliegende Erfindung Ausführungsformen in zahlreichen anderen spezifischen Formen ermöglicht, ohne von dem Anwendungsbereich der Erfindung, wie sie beansprucht ist, abzuwei chen. Folglich müssen die vorliegenden Ausführungsformen als zur Veranschaulichung dienend betrachtet werden, jedoch können sie innerhalb des durch den Umfang der beigefügten Ansprüche definierten Bereichs modifiziert werden, wobei die Erfindung nicht auf die oben angegebenen Einzelheiten beschränkt sein muss.
ANHANG
Technische Adresse: Zeichenkette, die für einen Enabler einen gegebenen Dienst beschreibt. Eine technische Adresse kann im Fall der SMS- und GD-Medien eine Kurznachricht oder ein Kurzcode (Beispiel "2222") oder im Fall des Wap-Mediums eine URL-Adresse (Beispiel: http://wap.sfr.net) sein. Die Zeichenkette, die die technische Adresse bildet, kann auch mit dem Zeichen * enden.

CAMEL:: Customized Applications for Mobile network Enhanced Logic. (Gattungsbezeichnung von Anwendungen für die mobilen Einrichtungen)
DTD:: Definition des Typs eines Dokuments
GD:: (Gestionaire de Dialogue) Dialog-Manager
GID:: (Gestionaire d'Identifiant) Identifizierer-Manager
GIDT:: (Gestionaire d'Identifiant Transactionnel) Transaktionsidentifizierer-Manager
G: O: (Gestionaire d'Offre) Angebotsmanager
L: OC enabler: Lokalisierungsplattform
SMS: enabler: Plattform, die das Schicken von Kurznachrichten ermöglicht
MMS: enabler: Plattform zum Schicken von Multimedia-Nachrichten
IHM:: (Interaction Homme – Machine) Mensch-Maschine-Interaktion
M: O/MT: Mobile Originated/Mobile Terminated
MS-ISDN:: Mobile Station – Integrated Services Digital Network. Dies ist die Rufnummer des Mobiltelephons.
OSA:: Open Service Access (definiert eine Schnittstelle mit einem Mobilfunk-Fernsprechnetz)
PARLAY:: zu OSA äquivalent, jedoch für das Festnetz
UIT:: Union Internationale des Telecommunications
VASP:: Value Added Service Provider
WAP:: (Wireless Application Protocol) Protokoll für Funkanwendung
WAP-server:: WAP-Server, der von Mobiltelephonen über eine WAP-Verbindungsbrücke (WAP-gateway), die die über eine mobiles Netz übertragenen Informationen in ein mit dem Internet kompatibles Format umwandelt und die umgekehrte Umsetzung ausführen kann, verwendet werden kann
XML:: eXtensible Mark-up Language. HTML ähnliche Metasprache.

Claims

Verfahren zum Steuern, einschließlich Management, eines opaken Anwenderidentifizierers der vollständigen Lieferung eines Dienstes unter Verwendung wenigstens eines Servers (31), dadurch gekennzeichnet, dass es über ein Transaktionsidentifizierer-Servermittel (GIDT) ausgeführt wird, das in einem Speicher (25) für jeden Anwender eine Beschreibung mehrerer Dienstangebote speichert, die von dem Anwender bei Mehrwert-Dienstanbietern (33) unterschrieben worden sind, wobei das Transaktionsidentifizierer-Servermittel (GIDT) ein Management-Modul (27) aufweist, das ermöglicht, einem Anwender oder einer Gruppe von Anwendern und wenigstens einem bestimmten Dienst einen opaken Transaktionsidentifizierer (trid) zuzuordnen, wobei das Verfahren die folgenden Schritte umfasst: – Senden einer Anforderung zum Eröffnen einer Transaktion (1) wenigstens eines Dienstes, der wenigstens einen bestimmten Server (31) erfordert, der Untertransaktionen (R') ausführt, durch einen Server (31), der eine Dienstanforderung eines Anwenders empfangen hat, oder durch einen der Dienstanbieter (33), wobei diese Transaktionseröffnungsanforderung (1) mit einem Satz von offenen Primitiven, die an eine Kommunikationsschnittstelle (21, 23) des Transaktionsidentifizierer-Servermittels (GIDT) adressiert sind und eine Anwenderidentifizierung (User-Id) angeben, sequentiell beschrieben wird, – Analysieren (1') der Anforderung und Erzeugen eines opaken Transaktionsidentifizierers (trid) durch die Management- und Steuermittel (26, 27) des Transaktionsidentifizierer-Servers (GIDT), anschließend – einen Schritt des Ausführens (R) der Transaktion unter Verwendung des opaken Transaktionsidentifizierers (trid).
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Analyseschritt (1') eine durch das Management-Modul (27) erfolgende Verifikation der Entsprechung der bestimmten Server (31) mit einem verzeichneten Dienstangebot, auf das vom Anwender unter mehreren Dienstangeboten zugegriffen werden kann, und eine Steuerung der Berechtigung zum Eröffnen der Transaktion durch die Steuermittel (26) des Transaktionsidentifizierer-Servermittels (GIDT) für den von den bestimmten Servern (LOC, SMS, MMS) bereitgestellten Dienst und den bestimmten Anwender insbesondere in Abhängigkeit von der Anwenderidentifizierung (UserId) umfasst.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass der Schritt (R) der Ausführung der Transaktion durch einen Mehrwert-Dienstanbieter (33) initiiert wird, der den opaken Transaktionsidentifizierer (trid) von seiten des Transaktionsidentifizierer-Servermittels (GIDT) empfangen hat, wobei der Dienstanbieter (33) eine Anfrage an einen bestimmten Server (31) mit parametrisiertem opakem Transaktionsidentifizierer (trid) eines bestimmten Dienstes, der eine Untertransaktion bildet, ausführt, um in Reaktion auf den bestimmten Server (LOC, SMS, MMS) das Schicken einer Demaskierungsanforderung (5) "unmask" auszulösen, die anhand des opaken Identifizierers (trid) die Lieferung einer nicht opaken Identifizierungsnummer (UserId), die dem opaken Transaktionsidentifizierer (trid) entspricht, ermöglicht, wobei anschließend durch die Steuermittel (26) des Transaktionsidentifizierer-Servermittels (GIDT) eine Steuerung (5', 10') ausgeführt wird, um zu verifizieren, ob der bestimmte Server (LOC, SMS, MMS) für diesen Dienst und für diesen Anwender berechtigt ist oder nicht, derart, dass im Fall der Berechtigung die nicht opake Identifizierungsnummer (UserId) über eine Kommunikationsschnittstelle, die Enabler-Schnittstelle (21) genannt wird, an den bestimmten Server (31) übertragen wird, um die Ausführung der Untertransaktion (R') zu ermöglichen.
Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass der Transaktionsidentifizierer (trid), der aus höchstens 15 Stellen gebildet ist, mit der Nummierungsebene UIT-T E-164 konform ist und die nicht opake Identifizierungsnummer (UserId) die MSISDN-Nummer ist.
Verfahren nach einem der Ansprüche 1 bis 4, bei dem das Transaktionsidentifizierer-Servermittel (GIDT) einerseits einen Transaktionsmotor (28) umfasst, der Transaktionsereignis-Sendungen erzeugt, die aus dem einen oder dem anderen der folgenden Befehle gebildet sind: BEGIN (ST), COMMIT (CT), ROLLBACK (ET), und andererseits einen Verfolgbarkeitsmotor (29) umfasst, der in dem Speicher (25) jedes Ereignis des Transaktionsmotors (28) und die Gesamtheit der Informationen, der während der Verwendung des Transaktionsidentifizierer-Servermittels (GIDT) gesendet werden, hinterlegt.
Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass der opake Transaktionsidentifizierer (trid) an den Mehrwert-Dienstanbieter (33) geschickt wird, nachdem in dem Speicher (25) des Transaktionsidentifizierer-Servermittels (GIDT) ein Transaktionskontext gespeichert worden ist, der insbesondere angibt: – eine Identifizierungsnummer (UserId) des Anwenders, – den Transaktionsidentifizierer (trid), – ein der Transaktion zugeordnetes Angebot, – den Fortschrittszustand der Transaktion für das ihr zugeordnete Angebot.
Verfahren nach Anspruch 6, bei dem dem Schicken (3) des opaken Transaktionsidentifizierers (trid) an den Mehrwert-Dienstanbieter (33) außerdem eine Erzeugung eines Transaktionsereignisses vorhergeht, das einen Beginn einer Transaktion an wenigstens ein externes System (40) über eine zweite Kommunikationsschnittstelle des Identifizierer-Servermittels, die Transaktionsmeldeschnittstelle (22) genannt wird, darstellt.
Verfahren nach Anspruch 7, bei dem die Erzeugung eines Transaktionsereignisses, das einen Beginn einer Transaktion an wenigstens ein externes System (40) darstellt, durch einen Befehl BEGIN (ST) erfolgt, der durch einen Transaktionsmotor (28) des Transaktionsidentifizierer-Servermittels (GIDT) erzeugt wird.
Verfahren nach Anspruch 7 oder 8, bei dem das Transaktionsidentifizierer-Servermittel (GIDT) von der Transaktionsmeldeschnittstelle (22) an wenigstens ein externes System (40) Daten überträgt, die die vollständige Ausführung des Angebots durch einen von dem Transaktionsmotor (28) erzeugten Befehl COMMIT (CT) darstellen, um dem externen System (40), beispielsweise ein Fakturierungssystem, anzuzeigen, dass die Transaktion vollständig ausgeführt worden ist.
Verfahren nach einem der Ansprüche 7 bis 9, bei dem das Transaktionsidentifizierer-Servermittel über die Transaktionsmeldeschnittstelle (22) ein Transaktionsereignis des Typs ROLLBACK-Wiederaufnahmeende sendet, um wenigstens einem externen System (40) zu melden, dass die Anzahl von Wiederaufnahmevorgängen der Transaktion bei einem Fehler überschritten ist und dass die Transaktion annulliert wird, um an einem Dialog-Manager Daten zu liefern und um den Dienst zu fakturieren oder nicht.
Verfahren nach einem der Ansprüche 1 bis 10, bei dem die Management- und Steuermittel (26, 27) des Transaktionsidentifizierer-Servers (GIDT) die Analyse (1') der Transaktionseröffnungsanforderung insbesondere für die Auflösung einer Entsprechung zwischen einer technischen Adresse des in der Transaktionseröffnungsanforderung (1) gemeldeten Dienstes und einem verzeichneten Dienstangebot unter mehreren Dienstangebot-Beschreibungen, die im Speicher (25) des Transaktionsidentifizierer-Servermittels (GIDT) gespeichert sind, ausführen.
Verfahren nach einem der Ansprüche 1 bis 11, bei dem der Speicher des Transaktionsidentifizierer-Servermittels (GIDT) Beschreibungen von Dienstangeboten speichert, die von den Anbietern validiert werden, die über eine dritte Kommunikationsschnittstelle, die Dienstbeschreibungs-Lieferschnittstelle IFDS genannt wird, erfasst werden.
Verfahren nach einem der Ansprüche 1 bis 12, bei dem die Beschreibung eines Dienstangebots Daten umfasst, die in einer Metasprache oder in äquivalenter Form formuliert sind, was den Steuermitteln des Identifizierer-Servers ermöglicht, den richtigen Ablauf des Dienstes zu steuern und hiervon den Anfang und das Ende zu erfassen.
Verfahren nach einem der Ansprüche 1 bis 13, bei dem das Transaktionsidentifizierer-Servermittel (GIDT) eine zusätzliche Kommunikationsschnittstelle (23) umfasst, die für die Mehrwert-Dienstanbieter (33) bestimmt ist, wobei die erste Schnittstelle (21) für die bestimmten Server (31) bestimmt ist.
Verfahren nach einem der Ansprüche 1 bis 14, bei dem das Transaktionsidentifizierer-Servermittel (GIDT) eine interne Logik aufweist, die die folgenden Abläufe ausführt: Start (S), Completed (C), Error (E), Mask, Unmask, Update, OpenTransaction, CloseTransaction.
Verfahren nach Anspruch 15, bei dem der Vorgang Start (S) des Transaktionsidentifizierer-Servermittels (GIDT) einen Transaktionsidentifizierer (trid) erzeugt (S1), im Speicher einen Transaktionskontext erzeugt (S2), ein Transaktionsereignis des Typs BEGIN (ST) erzeugt und den Transaktionsidentifizierer (trid) zu dem Mehrwert-Dienstanbieter (33) zurückleitet.
Verfahren nach Anspruch 15 oder 16, bei dem der Vorgang Completed (C) des Transaktionsidentifizierer-Servermittels (GIDT) durch einen Test (C1) feststellt, ob eine Untertransaktion (R') der Transaktion ausgeführt worden ist (CO), als Folge den Transaktionskontext modifiziert (C2), durch Untersuchen der Beschreibung des Angebots feststellt (C3), ob es notwendig ist, dass das Transaktionsidentifizierer-Servermittel (GIDT) ein externes Ereignis abwartet (C5), die Logik entweder eine Ablaufzeit "TimeOut" warten lässt oder die Transaktion schließen lässt "CloseTransaction", verifiziert (C4), ob die Transaktion beendet ist, und ein Transaktionsereignis des Typs COMMIT (CT) erzeugt.
Verfahren nach einem der Ansprüche 15 bis 17, bei dem der Vorgang Error (E) des Transaktionsidentifizierer-Servermittels (GIDT) verifiziert, ob die Wiederaufnahmeanzahl bei einem Fehler überschritten ist, wobei sie im positiven Fall ein Transaktionsereignis des Typs ROLLBACK (ET) erzeugt.
Verfahren nach einem der Ansprüche 15 bis 18, bei dem der Vorgang Mask durch einen bestimmten Server (31) ausgesendet wird, um die Informationen des anhand der technischen Adresse (201) und der mehreren Angebote angesprochenen Angebots (203) wiederzugewinnen, den Zugriff (204) eines auf das Dienstangebot abonnierten Anwenders zu steuern und entweder eine Zugriffsverweigerung (R1) auszusenden oder den Vorgang Start (S) auszulösen.
Verfahren nach einem der Ansprüche 15 bis 19, bei dem der Vorgang Unmask von einem bestimmten Server (31) ausgesendet wird, um die Informationen des Angebots (206), das anhand von Daten, die die technische Adresse und den Transaktionsidentifizierer (trid) repräsentieren, und anhand der mehreren Angebote angesprochen wird, wiederzugewinnen, um den Zugriff (207) eines Partner-Anbieters (33) auf den bestimmten Server (31) zu steuern, um zu verifizieren (208), dass die an diesen bestimmten Server (31) gerichtete Anforderung mit dem aktuellen Kontext der Transaktion in Übereinstimmung ist, und um dem bestimmten Server (31) zu melden, dass das Transaktionsidentifizierer-Servermittel (GIDT) auf eine Aktualisierung wartet, um die MSISDN-Nummer, die dem opaken Transaktionsidentifizierer (trid) zugeordnet ist, zurückzuleiten, um auf die Aktualisierung zu warten (211) und um zu verifizieren (302), dass die empfangene Aktualisierung die Informationen enthält, die für die Ausführung des Angebots notwendig sind, um entweder einen Vorgang Completed (C) oder einen Vorgang Error (E) auszusenden.
Verfahren nach einem der Ansprüche 15 bis 20, bei dem der Vorgang Update von einem bestimmten Server (31) ausgesendet wird und durch das Versetzen in einen Zustand (211) des Wartens auf die Aktualisierung bezüglich der Ausführung der Anforderung des Transaktionsidentifizierer-Servers (GIDT) gebildet ist.
Verfahren nach einem der Ansprüche 15 bis 21, bei dem der Vorgang OpenTransaction von einem Dienstanbieter mit zugeschriebenem Wert (33) ausgesendet wird, um den Zugriff (100) eines Partners auf einen Abonnenten des Operators zu steuern und um entweder eine Zugriffsverweigerung (R3) zu erzeugen oder einen Vorgang Start (S) auszulösen.
Verfahren nach einem der Ansprüche 17 bis 22, bei dem der Vorgang CloseTransaction von einem Mehrwert-Dienstanbieter (33) ausgesendet wird und ein Ereignis erzeugt, das die Entriegelung des Wartens "TimeOut" der Logik des Transaktionsidentifizierer-Servermittels (GIDT) ermöglicht.