DE69917447T2

DE69917447T2 - System zur unterstüztung der bereitstellung von diensten

Info

Publication number: DE69917447T2
Application number: DE69917447T
Authority: DE
Inventors: Martin John Ellis; Roger Jeffrey FARR; Duncan Charles James-Bell; Nigel Warren
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 1998-05-26
Filing date: 1999-05-26
Publication date: 2005-05-12
Anticipated expiration: 2019-05-27
Also published as: US7222165B1; EP1080586B1; EP1080586A1; CN1303571A; JP4302890B2; CA2330835C; KR20010034890A; GB2352124A; CA2330835A1; GB2352124B; JP2002517054A; AU4052299A; WO1999062272A1; AU753801B2; DE69917447D1; KR100635188B1; GB0025432D0

Description

Diese Erfindung bezieht sich auf ein System zur Unterstützung der Bereitstellung von Diensten, bei dem mehrere verschiedene Arten von Diensten unterstützt werden, die in Form von dienstspezifischen Datenverarbeitungen im Verlauf von Dienstnutzungsphasen bereitgestellt werden.
Es ist bekannt, dass Dienstanbieter Kunden über Zwischenhändler verschiedene Arten von Diensten zur Verfügung stellen, wobei sich der Zugriff auf Dienste wenigstens aus Sicht der Kunden vereinfacht.
Die Kosten, die einem Kunden berechnet werden, werden durch Parameter und Preistabellen festgelegt, die durch den Dienstanbieter aufgestellt werden. Der Dienstanbieter erzeugt eine Benachrichtigung über den in Rechnung gestellten Preis für die Bereitstellung einer bestimmten Dienstart, der letztendlich durch den Dienstzwischenhändler in Rechnung gestellt werden kann. Dienstanbieter implementieren daher eine Preis-Software in ihren Diensten.
In der Veröffentlichung "Operational Support Systems For The Future", D. Freestone und M. Owen, BT Technology Journal, Band 15, Nr. 1, Januar 1997, wird ein Unterstützungsbetriebssystem (Operational Support System, OSS) beschrieben, mit dem Preislisten und Rechnungsstellungsfunktionen neben weiteren Funktionen, wie zum Beispiel Provision, Portfolio-Management und Kundenunterstützung zur Verfügung gestellt werden. In der Veröffentlichung wird ein Ansatz für das Angebot von flexiblen, interoperativen Geschäftsdienstleistungen sowie standardisierten Anwendungsprogrammschnittstellen (Application Programming Interfaces, API) vorgeschlagen, um In formationsdienstleistungen von mehreren Dienstanbietern über gemeinsame Schnittstellen verpackt anbieten zu können. Insbesondere beinhalten die beschriebenen Preislistenfunktionen Informationsdienste, die durch Folgen von abrechnungsfähigen "Events" erzeugt werden. "Events" (Ereignisse) werden in diesem Fall nur durch die Informationsdienste des Anbieters erzeugt, wenn sie als abrechnungsfähig angesehen werden, und die Wahl derartiger abrechnungsfähiger Ereignisse erfolgt zum Zeitpunkt der Planung des Dienstangebots. Beispielgebende Preislistenoptionen beinhalten Teilnehmerpreislisten, die als reduziert abrechnungsfähige Ereignisse (one-off chargeable Event) bekannt sind. Eine weitere Art der Abrechnung sind inhaltsgebundene Preislisten, bei denen die Anzahl der Einheiten mit Inhalt auf Grund der Ereignis-Parameter bekannt sein müssen. Eine weitere Art derartiger Beispiele sind Preislisten auf Grund der Dauer, bei denen der Startzeitpunkt und der Endzeitpunkt aus den Ereignis-Parametern hervorgehen müssen.
In diesem Zusammenhang wurden abrechnungsfähige Ereignisse außer den Teilnahme-Ereignissen in der Vergangenheit nicht als Aufzeichnung eines augenblicklichen Ereignisses erzeugt, sondern als etwas, das man mit "kombiniertem" Ereignis bezeichnen könnte, etwas, das erzeugt wird, wenn augenblickliche Ereignisse logisch kombiniert werden. Bei konventioneller Telefonie wird beispielsweise ein abrechnungsfähiges Ereignis in einer Anrufaufzeichnung aufgezeichnet, wobei die Dauer des Anrufs sowohl durch den Startzeitpunkt als auch durch den Endzeitpunkt festgelegt wird. In diesem Sinn besteht das abrechnungsfähige Ereignis in der Anrufaufzeichnung bei einem "kombinierten" Ereignis aus Daten, die mehr als ein augenblickliches Ereignis festlegen.
In der Veröffentlichung "Tina Service Architecture from Specification to Implementation" von Hellemans et al. in Proceedings TINA'97 – Global Convergence of Telecommunications and Distributed Object Computing, 17.–20. November 1997, Seite 174–183, wird eine Implementierung der TINA-Dienstleistungsarchitektur beschrieben, bei der das Dienstleistungsnutzungsphasen-Subsystem sowohl aus dienstgebundener als auch dienstspezifischer Software besteht.
Gemäß einem Aspekt der vorliegenden Erfindung wird ein System zur Unterstützung der Bereitstellung von Diensten geschaffen, durch das mehrere unterschiedliche Arten von Diensten im Verlauf von Dienstnutzungsphasen unterstützt werden,
wobei das System im Betrieb einen Dienstnutzungsphasenmanager umfasst, der generische Funktionen in Bezug auf jeden der mehreren unterschiedlichen Arten von Diensten im Verlauf der Ereignis-Parameter Dienstnutzungsphasen durchführt, wobei das Unterstützungssystem dadurch gekennzeichnet ist, dass
für jeden der mehreren Arten von Diensten der Dienstnutzungsphasenmanager ausgelegt ist, ein dienstgenerisches Dienstnutzungsphasenobjekt zu bestimmen, um jede Dienstnutzungsphase zu überwachen, wobei die dienstgenerischen Dienstnutzungsphasenobjekte jeweils ausgelegt sind, um im Verlauf einer Dienstnutzungsphase, an der mehrere Teilnehmer teilnehmen:
mehrere Ereignisnachrichten mit Bezug auf dienstgenerisches Dienstnutzungsphasenverhalten während der Dienstnutzungsphase zu erzeugen, wobei jede Ereignisnachricht ein Ereignis anzeigt, das keine Verlaufsdaten enthält, und eine diskrete und unmittelbare Veränderung in Bezug auf den Status im Zusammenhang mit dem Dienstnutzungsphasenverhalten eines einzelnen unter den mehreren Teilnehmern der Dienstnutzungsphasenereignisnachrichten umfasst, die für jeden der mehreren Teilnehmer erzeugt werden, und die Ereignisnachrichten an eine dienstgenerische Ereignisverwaltungsvorrichtung für die weitere Verarbeitung zu übertragen, wobei die dienstgenerische Ereignisverwaltungsvorrichtung Ereignisnachrichten von jedem der dienstgenerischer Dienstnutzungsphasenobjekte empfängt.
Durch den Nutzungsphasenmanager, der Ereignisnachrichten erzeugt, die diskrete Veränderungen in dem Nutzungsphasen-bezogenen Zustand der Anwender während einer Dienstnutzungsphase anzeigen, wird die Notwendigkeit der Vorauswahl von abrechnungsfähigen Ereignissen durch den Dienstanbieter abgemildert. Durch das Filtern von Ereignissen aus einer bekannten Menge von Ereignissen, die durch den Nutzungsphasenmanager mitgeteilt werden, und/oder das logische Kombinieren von Ereignissen, die aus dieser Menge erzeugt werden, können die Preisberechnung und/oder die Kostenermittlung der Nutzung während einer Dienstleistungsnutzungsphase unabhängig von der Dienstleistungsnutzungsphase durchgeführt werden.
Darüber hinaus können die Ereignisse, die durch den Nutzungsphasenmanager erzeugt werden, zum Kontrolleintrag und zur nachfolgenden Analyse in einer Dienstleistungsnutzungsanalysemaschine automatisch weitergeleitet werden.
Gemäß einem weiteren Aspekt der Erfindung wird ein Verfahren zum generischen Benachrichtigen einer dienstgenerischen Ereignisverwaltungsvorrichtung für die Verarbeitung über Ereignisse mit Bezug auf dienstgenerisches Dienstnutzungsphasenverhalten angegeben, wobei die Ereignisse im Verlauf mehrerer Dienstnutzungsphasen auftreten, bei denen mehrere Teilnehmer teilnehmen, wobei die Dienstnutzungsphasen in einem System zur Unterstützung der Bereitstellung von Diensten zur Verfügung gestellt werden, wobei das Verfahren umfasst:
Erzeugen während der Dienstnutzungsphasen von mehreren der Ereignisnachrichten mit Bezug auf das dienstgenerische Dienstnutzungsphasenverhalten für jeden Teilnehmer, wobei jede Ereignisnachricht ein Ereignis ohne Verlaufsdaten enthält und eine diskrete und unmittelbare Veränderung in Bezug auf den Status im Zusammenhang mit dem Dienstnutzungsphasenverhalten eines einzelnen von mehreren Teilnehmern der Dienstnutzungsphasen umfasst, und
Übertragen der mehreren Ereignisnachrichten mit Bezug auf dienstgenerisches Dienstnutzungsphasenverhalten an eine dienstgenerische Ereignisverwaltungsvorrichtung für die Verarbeitung von jeder der Dienstnutzungsphasen.
Ausführungsformen der Erfindung werden im Folgenden als Beispiele beschrieben, wobei Bezug genommen wird auf die beigefügten Zeichnungen.
1 zeigt schematisch ein Blockdiagramm eines Telekommunikationssystems gemäß einer Ausführungsform der vorliegenden Erfindung.
2 zeigt schematisch ein Blockdiagramm von Systemkomponenten auf dem Gebiet des Kunden, Zwischenhändlers und Dienstanbieters in Bezug auf das System nach 1.
3 zeigt schematisch ein Blockdiagramm einer Ausführungsform des Aufbaus nach 1 und 2 mit zueinander in Beziehung stehenden Software-Objekten.
4 ist ein Diagramm, in dem schematisch der Ablauf bei einer Nutzungsphase gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt ist.
5 bis 13 zeigen Wechselwirkungen zwischen den Objekten in 2 bei verschiedenen Prozeduren mit einer Veränderung des Status eines Anwenders des Systems als Folge.
14 zeigt schematisch ein Blockdiagramm von Software-Objektwechselwirkungen in einer Ereignisabrechnungsmaschine gemäß einer Ausführungsform der vorliegenden Erfindung.
15 schematisch ein Blockdiagramm für die Handhabung von Ereignissen durch einen Ereignis-Router gemäß einer Ausführungsform der vorliegenden Erfindung.
1 ist ein Blockdiagramm zur Erläuterung eines Telekommunikationssystems gemäß einer Ausführungsform der vorliegenden Erfindung. Das System besteht aus einem Zwischenhändler-Server RS und mehreren Servern TPS1, TPS2, ..., TPSn Dritter. Die Anwender-Terminals T1, T2, ..., Tn sind mit dem Zwischenhändler-Server RS über ein Datenkommunikationsnetz verbunden, das in dieser Ausführungsform das Internet ist.
Die Server TPS1, TPS2, ..., TPSn Dritter sind entweder über eine Fernverbindung mit dem Zwischenhändler-Server RS durch die Kommunikationsverbindungen 2 verbunden, die separate physikalische und/oder logische Verbindungen sein können, wie es dargestellt ist, oder sie befinden sich am Ort des Zwischenhändler-Servers RS.
Jeder Server Dritter hat Zugang auf eine Datenbank TPDB1, TPDB2, ..., TPDBn zur Speicherung und zum Laden von dienstleistungsbezogenen Daten.
Obgleich die Server RS, TPS1, TPS2, ..., TPSn in 1 als einzelne Server dargestellt sind, kann jeder aus einem oder mehreren Servern bestehen, die in einem Netz zusammengefasst sind. Die Server können jeweils in einem Rechner implementiert sein, wie zum Beispiel einem Workstation-Rechner. Jeder der Nutzer-Terminals T1, T2, ..., Tn kann in Form eines Workstation-Rechners implementiert sein, eines Netzcomputers, eines mobilen Kommunikationsterminals oder irgendetwas anderem dergleichen.
2 zeigt schematisch weitere Einzelheiten des Telekommunikationssystems mit Komponenten als Beispielen in einem Terminal für einen Einzelanwender, den Zwischenhändler-Server und einem einzelnen Server Dritter. Auf der Client-Seite sorgt ein Dienstleistungs-Browser-Anwendungsprogramm 4 für Zugriff und Unterstützung in Bezug auf einen Bereich von Dienstleistungen, die durch die verschiedenen Server TPS1, TPS2, ..., TPSn Dritter über den Zwischenhändler-Server RS bereitgestellt werden. Der Zwischenhändler-Server RS umfasst einen Zugangssteuerungsabschnitt 5, über den ein Client-Terminal zu Anfang auf das Dienstleistungsbereitstellungssystem zugreifen kann, einen Authentifizierungsabschnitt 6, über den Anwender des Systems Berechtigung erlangen können, wie zum Beispiel mittels Passwort-Abfrageprozedur, und einen Teilnehmerabschnitt 7, in welchem die Teilnehmerdaten von Anwendern des Systems gepflegt werden.
Im Verlauf der Teilnahme an einer Dienstleistung umfassen die Client-Terminals, der Zwischenhändler-Server und der Server Drit ter Anwendungsprogrammabschnitte, die auf der Client-Seite einen dienstleistungsspezifischen Anwendungsprogrammabschnitt 8 umfassen, auf der Zwischenhändlerseite einen Nutzungsphasensteuerungsanwendungsprogrammabschnitt 9 umfassen, und auf der Dienstanbieterseite einen Dienstleistungssteuerungsanwendungsprogrammabschnitt 10 umfassen.
Der Zwischenhändler-Server oder das Servernetzwerk umfasst außerdem eine Ereignisverwaltungsvorrichtung 11, die Ereignisse verwaltet, die durch den Nutzungsphasensteuerungsanwendungsabschnitt 9 während einer Dienstleistungsnutzungsphase erzeugt wurden.
Es versteht sich, dass die Unterteilung in Zwischenhändler und Dienstanbieter in 2 nicht unbedingt eine physikalische Unterteilung oder eine Unterteilung in Bezug auf Eigentum oder Kontrolle der verschiedenen Server sein muss. Beispielsweise kann der Dienstanbieter-Dienstleistungssteuerabschnitt 10 auf einem Server angesiedelt sein, der unter Kontrolle des Zwischenhändlers ist, wie es bei demjenigen der Fall ist, der den Zwischenhändler-Server RS selbst besitzt.
3 zeigt eine Ausführungsform der Erfindung, bei der das System als ein Software-Objekt-System implementiert ist. Eine Beschreibung eines objektorientierten Software-Konzepts findet man in "Design Patterns: Elements of Reusable Object-Oriented Software", Erich Gamma et al, Addison-Wesley, ISBN 0-201-63361-2, sowie den darin angegebenen Literaturhinweisen.
Bei dieser Ausführungsform wird jedes der Rechnerelemente T1, T2, ..., Tn; RS; TPS1, TPS2, ..., TPSn nach 1 durch eine verteilte Prozessorumgebung (Distributed Processing Environment, DPE) unterstützt, wodurch verteilte Software-Objekte in verschiedenen physikalischen Teilen des Systems über den Austausch von Nachrichten, beispielsweise unter Verwendung von CORBA (Common Object Request Broker Architecture), über Datenkommunikationsverbindungen miteinander zusammenarbeiten können.
Im Folgenden wird Bezug genommen auf die objektorientierte Sprache Java (Handelsmarke), was jedoch nicht als Einschränkung verstanden werden darf. Andere und sogar heterogene Kombinationen von objektorientierten Sprachen können ebenfalls zum Implementieren des Systems eingesetzt werden.
Das verteilte Objekt-System umfasst dienstleistungsgenerische Codes und dienstleistungsspezifische Codes, die im Verlauf einer Dienstleistungsnutzungsphase zwischen der Client-Seite und der Server-Seite verteilt sind. Der Teil des Systems mit dienstleistungsgenerischem Code wird im Folgenden als Dienstleistungsbereitstellungsunterstützungssystem bezeichnet.
Dienstspezifischer Code auf Seiten des Client wird im Folgenden als "Vordergrund"-Objekt bezeichnet. Das Vordergrundobjekt bei dieser Ausführungsform ist ein Java-Applet, das auf der Client-Maschine läuft. Das Vordergrundobjekt 13 kommuniziert mit anderen System-Objekten, um eine Anwenderteilnahme in einer Nutzungsphase zu unterstützen und zu steuern. Das Vordergrundobjekt 13 sorgt außerdem für die dienstleistungsspezifische Vordergrund-End-Funktion, wie die GUI-Dienstleistung und die Verwaltung der Anwendereingaben in Bezug auf die Dienstleistung.
Der dienstleistungsspezifische Code im Bereich des Dienstanbieters wird hier als "Hintergrund"-Objekt bezeichnet. Das Hintergrundobjekt 32 stellt die Nutzungsphase und die Teilnehmer innerhalb des Bereichs des Dienstanbieters dar und kann mit anderen Hintergrund-End-Systemen wie Servern und Datenbanken im Bereich des Dienstanbieters interagieren. Dadurch werden die Interaktionen zwischen Teilnehmern an einer Nutzungsphase koordiniert und der dienstspezifische Zustand gespeichert, wenn ein Teilnehmer unterbricht. Das Hintergrundobjekt 32 kann außerdem die Kontrolle über eine Nutzungsphase ausüben, beispielsweise kann durch es eine Unterbrechung und eine Beendigung bezüglich eines oder mehrerer Teilnehmer veranlasst werden. Eine mögliche Implementierung des Hintergrundobjekts 32, bei der Objekte die Dienstnutzungsphase wie auch die Dienstleistung steuern, die einzelnen Teilnehmern in der Dienstleistungsnutzungsphase angeboten wird, wird in unserer ebenfalls anhängigen internationalen Patentanmeldung beschrieben, die mit demselben Datum eingereicht wurde und den Titel hat "Multiple Service Provision" (Aktenzeichen des Vertreters: J40600), auf deren Inhalt hiermit Bezug genommen wird.
Client-Software-Objekte
Ein Zwischenhändlerarbeitsraumobjekt (RWS) 12 läuft auf der Client-Maschine und stattet den Client mit der Möglichkeit aus, auf Dienstleistungen zuzugreifen.
Das RWS 12 kann ein herunterladbares Java-Applet sein, das auf einem bekannten Java-fähigen Browser oder einem unabhängigen Java-Applikationsprogramm läuft. Das RWS ermöglicht es dem Anwender, sich in das Dienst-Nutzungsphasensteuerungssystem ein zuloggen und Dienstnutzungsphasen durch Herunterladen von Vordergrundobjekten 13 und Ausloggen über GUI zu nutzen.
Das RWS 12 ist mit Mulit-Thread-Technik ausgestattet, um Vordergrundobjekte 13 parallel nutzen zu können, sowohl miteinander als auch mit dem RWS 12. Beispielsweise kann ein Anwender simultan an zwei Dienstleistungen teilnehmen und zur gleichen Zeit über das RWS 12 eine Aufforderung empfangen, eine dritte Dienstleistung zu nutzen. Damit kann ein Anwender mehrere Vordergrundobjekte 13 derselben oder verschiedener Dienstleistungen haben, die simultan auf dem Client-Terminal laufen.
Wenn der Anwender eine Nutzungsphase beendet oder unterbricht, wird das Vordergrundobjekt 13 gelöscht.
Zwischenhändler-Software-Objekte
Ein Gateway-Objekt 14 dient als Anfangspunkt für den Kontakt eines Anwenders, um auf das System zuzugreifen. Über dieses läuft die Authentifizierung der Identität des Anwenders und des Passworts zu dem RWS 12. Danach stellt das RWS 12 eine Verbindung mit einem Anwenderkontoobjekt 18 her, und das Gateway spielt keine weitere Rolle.
Das Gateway 14 ist mit Multi-Thread-Technik ausgestattet, um Verfügbarkeit zu gewährleisten. Das heißt, dass während der Verarbeitung einer Login-Anfrage von einem Client-Terminal das Gateway 14 in der Lage ist, Login-Anfragen von verschiedenen Client-Terminals zu verarbeiten.
Ein Anwenderadministrationsobjekt 16 hat die Funktion, neue Anwenderkonten zu erzeugen.
Das Anwenderkontoobjekt 18 dient als einzelnes Anwenderkonto innerhalb des Zwischenhändlerbereichs. Es enthält oder bekommt eine Aufzeichnung aller Dienstleistungen, bei denen der Anwender als Teilnehmer registriert ist. Das Anwenderkonto 18 empfängt und speichert oder ermittelt je nach Bedarf Information von anderen Objekten im Zwischenhändlerbereich bezüglich beliebiger unterbrochener Nutzungsphasen, die zu dem Anwender gehören, und alle öffentlichen verfügbaren Nutzungsphasen und alle Nutzungsphasenaufforderungen, die bei dem Anwender eingegangen sein können.
Das Nutzerkontoobjekt 18 vermittelt außerdem Interaktionen zwischen RWS 12 und dem Rest des Zwischenhändlerbereichs bezüglich Start, Einstieg und Wiederaufnahme von Nutzungsphasen. Es werden Benachrichtigungen von einem Nutzungsphasenobjekt 30 verwaltet mit dem Inhalt, dass Nutzungsphasen unterbrochen oder beendet worden sind.
Anwenderkontenobjekte liegen in dem Zwischenhändlerbereich selbst dann vor, wenn die Anwender, die dazugehören, sich aus dem System ausgeloggt haben.
Ein Anwenderkontomanagerobjekt 20 erzeugt und wartet die Anwenderkontenobjekte 18 und liefert einen Bezug zu dem entsprechenden Anwenderkontenobjekt 18, wenn sich ein Anwender in das System einloggt, um Kommunikationsnutzungsphasen mit dem Zwischenhändler-Server RS zu beginnen.
Das Authentifizierungsserverobjekt 22 verwendet gespeicherte Anwender-Authentifizierungsdaten, um Login-Anfragen zu authentifizieren.
Ein Dienstanbieter-Portfolioobjekt (SPP) 24 wartet Information bezüglich verfügbarer Dienstleistungen einschließlich der Dienstanbieteridentität und ihrer Netzadressen und bezüglich der Frage, welche Nutzungsphasenverwaltungsvorrichtung 28 verwendet werden soll, um eine Dienstleistung zu unterstützen (dies ermöglicht, dass Belastungen von mehreren Nutzungsphasenverwaltungseinrichtungen 28 verwaltet werden können).
Ein Nutzungsphasenverwaltungsobjekt 28 löst ein Nutzungsphasenherstellungsobjekt 26 aus sowie ein Hintergrundherstellungsobjekt 34 (das sich im Dienstanbieterbereich befindet), um Nutzungsphasenobjekte 30 und Hintergrundobjekte 32 einzurichten, damit Dienstleistungsnutzungsphasen unterstützt werden, und anschließend wird zwischen den Anwenderkonten 18, den Nutzungsphasenobjekten 30 und den Hintergrundobjekten 32 vermittelt, um weitere Dienstinteraktionen (z. B. Auffordern, Anschließen, Unterbrechen, Wiederaufnehmen) zu unterstützen. Es gibt ein oder mehrere Nutzungsphasenverwaltungsobjekte 28 in dem System.
Das Nutzungsphasenobjekt 30 ist ein dienstleistungsgenerisches Objekt (d. h. ein Objekt, das in mehreren verschiedenen Typen von Dienstleistungen verwendet wird), durch das eine Dienstleistungsnutzungsphase gesteuert wird und die Interaktion der Objekte koordiniert wird, die an dieser Nutzungsphase beteiligt sind. Es werden dadurch generische Nutzungsphasenverhaltensformen wie Aufforderungen und Unterbrechungen verwaltet. Wenn beispielsweise ein Client-Vordergrundgerät 13 die Nutzungsphase eines Anwenders unterbricht, so reagiert das Nutzungsphasenobjekt 30 durch Aufrufe bezüglich des Anwenderkontos 18 und des Kundenhintergrundobjekts 32 und durch Übertragen einer Ereignisnachricht an die Ereignisverwaltungsvorrichtung 31.
Es gibt ein einzelnes Nutzungsphasenobjekt 30, das bei jeder Dienstleistungsnutzungsphase eingerichtet wird, was durch das System gesteuert wird. Das Nutzungsphasenobjekt 30 wird erzeugt, wenn der erste Teilnehmer die Nutzungsphase beginnt, und es wird gelöscht, wenn der letzte Teilnehmer die Nutzungsphase verlässt. Das Nutzungsphasenobjekt 30 wird ansonsten nicht gelöscht, selbst wenn von allen Teilnehmern eine Unterbrechung vorgenommen wurde.
Eine Ereignisverwaltungsvorrichtung 31 ist vorgesehen, um Ereignisnachrichten zu empfangen, die durch andere Objekte im Zwischenhändlerbereich erzeugt wurden, insbesondere die Anwenderkonten 18 und die Nutzungsphasenobjekte 30.
Dienstanbieter-Software-Objekte
Die Hintergrundherstellung 34 richtet Hintergrundobjekte 32 bei Aufruf der Nutzungsphasenverwaltungseinrichtung 28 ein.
Es gibt ein einzelnes Hintergrundobjekt 32 pro Nutzungsphasenobjekt 30. Jedes Hintergrundobjekt 32 existiert nur, solange das Nutzungsphasenobjekt 30 existiert, das dieselbe Dienstleistungsnutzungsphase verwaltet.
Es sollte erwähnt werden, dass Objekte in dem Dienstanbietungsunterstützungssystem, insbesondere das Gateway 14, die Anwender kontenverwaltungseinrichtung 20, der Authentifizierungsserver 22 und das Dienstanbieter-Portfolio 24 aus mehreren miteinander zusammenhängenden Kopien bestehen kann, die ein einzelnes logisches Objekt bilden, um die Skalierbarkeit des Systems sicherzustellen.
4 zeigt ein Beispiel für einen Lebenszyklus einer Nutzungsphase. Die Nutzungsphase beginnt, wenn ein erster Teilnehmer (Teilnehmer 1) die Nutzungsphase beginnt. Über die Lebensdauer der Nutzungsphase wird eine veränderliche Zahl von Teilnehmern die Nutzungsphase besuchen, unterbrechen und beenden. Die Nutzungsphase existiert, bis der letzte Teilnehmer (in dem Beispiel, das gezeigt ist, Teilnehmer 3) die Nutzungsphase verlässt, wenn die Nutzungsphase also beendet wird.
5 bis 13 zeigen Interaktionen zwischen Objekten in dem System bei Veränderungen des auf Nutzungsphasen bezogenen Status eines Anwenders des Systems. Nachrichten, die zwischen den Objekten versendet werden, sind durch durchgezogene Pfeile angedeutet und sind nummeriert, um die Sequenz anzugeben, in der die Nachrichten versendet werden. Ereigniskanäle (angedeutet durch gestrichelte durchgezogene Pfeile) werden in verschiedenen Fällen durch das Nutzungsphasenobjekt 30 verwendet. Nachrichten werden durch Ereigniskanäle versendet, um eine Blockade des Nutzungsphasenobjekts 30 zu vermeiden, die auftreten würde, wenn Anfrage-Antwort-Prozeduren verwendet würden und die sich auf Dienstleistungen für andere Teilnehmer auswirken würden.
Mehrere der Interaktionen zwischen RWS 12 und dem Anwenderkonto 18 identifizieren bestimmte Nutzungsphaseninstanzen. Die Übergabe direkter Bezüge auf Nutzungsphasenobjekte 30 an RWS 12 kann die Sicherheit beeinträchtigen. Um dies zu vermeiden, werden die Nutzungsphasen von RWS 12 mittels gespeicherter "Cookie"-Bezügen identifiziert, die vorher durch das Anwenderkonto 18 hierfür zur Verfügung gestellt wurden, wodurch das Nutzerkonto 18 in die Lage versetzt wird, das tatsächliche Nutzungsphasenobjekt 30 zu identifizieren, auf das Bezug genommen wird.
Aus Gründen der Klarheit wurden Objekte, die an den beschriebenen Interaktionen nicht beteiligt sind, in den 5 bis 13 fortgelassen.
In 5 ist das Gateway 14 der Anfangspunkt für den Kontakt des Anwenders, um auf das System zuzugreifen. RWS 12 veranlasst eine Datenkommunikationsnutzungsphase mit dem Gateway und sendet eine Login-Nachricht mit dem Namen des Anwenders und dem von dem Anwender eingegebenen Passwort ab. Unter der Annahme, dass diese Werte durch den Authentifizierungsserver 22 authentifiziert worden sind, lädt das Gateway 14 anschließend eine Referenzgröße in das Anwenderkonto des Anwenders von der Anwenderkontenverwaltungseinrichtung 20 und kontaktiert dann das entsprechende Anwenderkonto 18, um zu bestätigen, dass der Anwender nun eingeloggt ist. Das Anwenderkonto 18 sendet eine Nachricht an die Ereignisverwaltungsvorrichtung 13, mit der sie von dem Login-Ereignis in Kenntnis gesetzt wird.
Weitere Interaktionen finden dann zwischen RWS 12 und dem Anwenderkonto 18 statt, wobei das Anwenderkonto 18 Anwenderprofilinformation einschließlich abonnierter Dienstleistungen, unterbrochener Nutzungsphasen, öffentlicher Nutzungsphasen und empfangener Aufforderungen zurückgibt, wobei RWS 12 dann dem Anwen der den Zugriff auf diese Information über das Client-Terminal ermöglicht.
In 6 ist gezeigt, dass, wenn der Anwender eine Nutzungsphase über das Client-Terminal initiiert, RWS 12 eine Nutzungsphasenstartnachricht an das Anwenderkonto 18 übermittelt, worin der angeforderte Dienst spezifiziert wird. Um ein Vordergrundobjekt 13 zu erzeugen, erzeugt RWS 12 einen Thread, um das entsprechende Vordergrundobjekt herunterzuladen, und lädt das entsprechende Vordergrundobjekt 13 für die Dienstleistung von dem Zwischenhändler-Server RS herunter.
Das Anwenderkonto 18 erhält Einzelheiten zu der Dienstleistung, die von SPP 24 angefordert wurde, einschließlich der Identität der Nutzungsphasenverwaltungseinrichtung 28, um die Dienstleistungsnutzungsphase zu unterstützen, und es wird eine Nachricht an die Nutzungsphasenverwaltungseinrichtung 28 gesendet, um eine neue Nutzungsphase zu erzeugen. Die Nutzungsphasenverwaltungseinrichtung 28 sendet eine Nachricht an die Hintergrundherstellung 34, um ein neues Hintergrundobjekt 32 einzurichten und sendet eine Nachricht an die Nutzungsphasenherstellung 26, um ein neues Nutzungsphasenobjekt 30 einzurichten. Die Hintergrundherstellung 34 und die Nutzungsphasenherstellung 26 geben Bezugnahmen auf neue Hintergrundobjekte 32 bzw. Nutzungsphasenobjekte 30 zurück, die dann durch die Nutzungsphasenverwaltungseinrichtung 28 verwendet werden, um das neue Nutzungsphasenobjekt 30 zu instruieren, an das neue Hintergrundobjekt 32 anzuhängen. Die Bezugnahme auf das Nutzungsphasenobjekt wird außerdem zu dem Vordergrundobjekt 13 anschließend über RWS 12 zurückgeschickt, um dem Vordergrundobjekt 13 das Anhängen an das Nutzungsphasenobjekt 30 zu ermöglichen.
Das Anwenderkonto 18 sendet dann eine Dienstleistungsbesuchsnachricht an die Nutzungsphasenverwaltungseinrichtung 28, die ihrerseits eine Besuchsanfragenachricht an das erzeugte Nutzungsphasenobjekt 30 schickt, um den Anwender zu veranlassen, eine Nutzungsphase aufzusuchen.
Schließlich instruiert RWS 12 das Vordergrundobjekt 13, eine Anfügungsnachricht an die Nutzungsphase 30 zu senden. Dadurch wird der Kommunikationskanal zwischen dem Vordergrundobjekt 13 und dem Nutzungsphasenobjekt 30 eingerichtet. Das Nutzungsphasenobjekt 30 sendet dann eine Teilnehmerbesuchsnachricht an das Hintergrundobjekt 32. Das Nutzungsphasenobjekt 30 übermittelt ebenso eine Nachricht an die Ereignisverwaltungsvorrichtung 31, um sie darüber zu informieren, dass das Nutzungsphasenstartereignis stattgefunden hat.
Wie in 7 gezeigt, kann ein Anwender eine Nutzungsphase besuchen, zu deren Aufsuchen er aufgefordert wurde. RWS 12 übermittelt eine Nutzungsphasenbesuchsnachricht an das Anwenderkontenobjekt 18, die eine "Cookie"-Referenz weiterleitet, um anzuzeigen, welche Einladung der Anwender annehmen möchte. Das Anwenderkonto 18 erhält Einzelheiten der Dienstleistung von SPP 24 und sendet eine Nachricht an die Nutzungsphasenverwaltungseinrichtung 28, um zu verifizieren, dass die Nutzungsphase nach wie vor andauert. Die Nutzungsphasenverwaltungseinrichtung 28 fragt das Nutzungsphasenobjekt 30 ab wie auch das Kundenhintergrundobjekt 32, um dies zu bestätigen. Mittlerweile richtet RWS 12 einen Thread ein, um das entsprechende Vordergrundobjekt 13 für die ausgewählte Dienstleistung herunterzuladen.
Sobald die Nutzungsphase durch die Nutzungsphasenverwaltungseinrichtung 28 verifiziert worden ist, sendet das Anwenderkontenobjekt 18 eine Besuchsnachricht an die Nutzungsphasenverwaltungseinrichtung 28, was dazu führt, dass eine Besuchsanfragenachricht von der Nutzungsphasenverwaltungseinrichtung 28 an das entsprechende Nutzungsphasenobjekt 30 abgesendet wird. Wenn die Besuchsanfrage Erfolg hat, sendet RWS 12 eine Nachricht, um das Vordergrundobjekt 13 anzuweisen, an das Nutzungsphasenobjekt 30 anzuhängen, was durch Bezugnahme identifiziert wird, die durch das Anwenderkonto 18 übermittelt wird. Das Nutzungsphasenobjekt 30 sendet dann eine Teilnehmerbesuchsnachricht an das Kundenhintergrundobjekt 32 über den Ereigniskanal. Das Nutzungsphasenobjekt 30 übermittelt ebenfalls eine Nachricht an die Ereignisverwaltungseinrichtung 31, um sie davon zu informieren, dass das Nutzungsphasenbesuchsereignis stattgefunden hat.
8 zeigt, dass die Unterbrechung eines Anwenders einer Nutzungsphase initiiert werden kann durch das Vordergrundobjekt 13, das eine Unterbrechungsnachricht an das Nutzungsphasenobjekt 30 sendet. Das Vordergrundobjekt 13 löscht sich dann selbst. Das Nutzungsphasenobjekt 30 sendet eine Teilnehmerunterbrechungsnachricht an das Hintergrundobjekt 32 über den Ereigniskanal und markiert für den fraglichen Teilnehmer eine Unterbrechung. Das Nutzungsphasenobjekt 30 sendet ebenfalls eine Nachricht an das Anwenderkonto 18, um es davon zu unterrichten, was der neue Status des Anwenders ist, und sendet eine Nachricht an die Ereignisverwaltungseinrichtung, um sie davon zu unterrichten, dass das Unterbrechungsereignis stattgefunden hat.
Schließlich sendet das Anwenderkonto 18 eine Nachricht, um RWS 12 von der neuen Unterbrechung zu unterrichten, wobei ein Cookie- Bezug auf die Nutzungsphase 30 weitergeleitet wird, so dass der Anwender in der Lage ist, danach die Nutzungsphase wieder aufzunehmen.
In 9 ist gezeigt, dass eine alternative Nutzungsphasenunterbrechungsprozedur von dem Kundenhintergrundobjekt 32 initiiert werden kann. In diesem Fall wird die Unterbrechung durch das Kundenhintergrundobjekt 32 initiiert, das eine Unterbrechungsnachricht an das Nutzungsphasenobjekt 30 sendet. Das Nutzungsphasenobjekt 30 sendet eine Unterbrechungsnachricht an das fragliche Vordergrundobjekt 13 und löscht sich anschließend selbst. Das Nutzungsphasenobjekt 30 fährt fort mit dem Absenden einer Teilnehmerunterbrechungsnachricht an das Hintergrundobjekt 32 und Übermitteln einer Nachricht an die Ereignisverwaltungsvorrichtung 31, mit der sie informiert wird, dass das Unterbrechungsereignis stattgefunden hat. Der Prozess fährt fort, wie es mit Bezug auf 8 beschrieben wurde.
In 10 ist gezeigt, dass RWS 12 von allen unterbrochenen Nutzungsphasen für den Anwender durch das Anwenderkonto 18 unmittelbar dann informiert wird, wenn der Anwender eingeloggt ist, und dies über den Verlauf einer Zugriffsnutzungsphase. Wenn daher ein Anwender eine Nutzungsphase wiederaufnehmen will, sendet RWS 12 eine Wiederaufnahmenachricht an das Nutzerkonto 18, die andeutet, dass die Nutzungsphase wieder aufgenommen wird, und zwar mittels eines Cookie-Bezugs. Das Anwenderkonto 18 sendet eine Nutzungsphasenverifizierungsnachricht an die entsprechende Nutzungsphasenverwaltung 28, die das Nutzungsphasenobjekt 30 abfragt wie auch das Hintergrundobjekt 32, um zu verifizieren, dass die Nutzungsphase nach wie vor andauert.
Mittlerweise lädt RWS 12 das entsprechende Vordergrundobjekt 13 für die ausgewählte Dienstleistung herunter. Sobald die Nutzungsphasenverwaltung 28 verifiziert hat, dass die Nutzungsphase verfügbar bleibt, instruiert RWS 12 das Vordergrundobjekt 13, eine Anhängungsvordergrundnachricht an das Nutzungsphasenobjekt 30, um die Vordergrundverbindung mit dem Nutzungsphasenobjekt 30 wiederherzustellen. Das Nutzungsphasenobjekt 30 sendet dann eine Teilnehmerwiederaufnahmenachricht an das Hintergrundobjekt 32 über den Ereigniskanal. Das Nutzungsphasenobjekt 30 übermittelt ebenfalls eine Nachricht an die Ereignisverwaltungseinrichtung 31, um sie von der Wiederaufnahme als Ereignis zu informieren.
Indem für die Unterbrechung einer Teilnahme an einer Dienstleistungsnutzungsphase wie beschrieben gesorgt wird, zusätzlich zu dem vollständigen Verlassen der Dienstleistungsnutzungsphase, kann der Status der Teilnahme in dem Hintergrundobjekt 32 für die Dauer der Unterbrechung gespeichert werden und wiederhergestellt werden, wenn der Teilnehmer die Teilnahme wiederaufnehmen will. Die Zerstörung des Vordergrundobjekts 13 bei Unterbrechung ermöglicht eine effizientere Verwaltung der Client-Terminal-Ressourcen, da ein neues Vordergrundobjekt 13 bei Wiederaufnahme ohne weiteres heruntergeladen werden kann.
In 11 ist gezeigt, dass, wenn ein Anwender eine Nutzungsphase zu verlassen wünscht, das Vordergrundobjekt 13 eine Teilnahmebeendigungsnachricht an das Nutzungsphasenobjekt 30 sendet und sich dann selbst löscht. Das Nutzungsphasenobjekt 30 sendet eine Teilnehmerquittierungsnachricht an das Hintergrundobjekt 32. Das Nutzungsphasenobjekt 30 übermittelt ebenfalls eine Nachricht an die Ereignisverwaltungseinrichtung 31, um sie davon zu unterrichten, dass der Teilnehmer ausgestiegen ist. Das Nutzungsphasenob jekt 30 sendet dann eine Nutzungsphasennachricht an das Anwenderkonto 18, um es davon in Kenntnis zu setzen, dass der Anwender die Nutzungsphase verlassen hat. Das Nutzungsphasenobjekt 30 löscht sich dann selbst, wenn es keine weiteren aktiven oder unterbrochenen Teilnehmer in der Nutzungsphase gibt, nachdem eine Nachricht an die Ereignisverwaltungsvorrichtung 31 abgesendet wurde, um sie davon zu unterrichten, dass das Nutzungsphasenbeendigungsereignis eingetreten ist.
Das Verlassen der Nutzungsphase kann alternativ auf ein Ergebnis der Dienstleistungslogikverarbeitung von dem Hintergrundobjekt 32, wie in 12 dargestellt, initiiert sein. In diesem Fall wird das Verlassen initiiert durch das Hintergrundobjekt 32, das eine Teilnahmebeendigungsnachricht an das Nutzungsphasenobjekt 30 sendet. Das Nutzungsphasenobjekt 30 sendet eine Teilnahmebeendigungsnachricht an das Vordergrundobjekt 13, das sich dann selbst löscht. Das Nutzungsphasenobjekt 30 sendet dann eine Teilnehmerquittierungsnachricht an das Hintergrundobjekt 32 und an die Ereignisverwaltungsvorrichtung 31. Der Prozess fährt dann fort, wie es mit Bezug auf 11 beschrieben wurde.
In 13 ist gezeigt, dass, wenn sich der Anwender ausloggt, RWS 12 eine Auslogg-Nachricht an das Anwenderkonto 18 sendet. Das Anwenderkonto 18 übermittelt eine Nachricht an die Ereignisverwaltungseinrichtung 31, um sie davon zu informieren, dass das Auslogg-Ereignis stattgefunden hat.
Außer dem Vordergrundobjekt 13 und dem Kundenhintergrundobjekt 32 sind alle Objekte in 5 bis 13 generisch in Bezug auf verschiedene Dienstleistungen, die in dem System unterstützt wer den, und werden daher für mehrere verschiedene Typen von Dienstleistungen wiederverwendet.
Eine Dienstleistungsnutzungsphase besteht aus einem einzelnen Kundenhintergrundobjekt 32, das innerhalb des Dienstanbieterbereiches angeordnet ist, zusammen mit einer Anzahl von Vordergrundobjekten 13. Ein Vordergrundobjekt 13 gibt es pro Teilnahme an der Dienstleistung. Die Vordergrundobjekte 13 können auf verschiedenen Client-Terminals und/oder innerhalb eines einzelnen Client-Terminals verteilt sein. Die Interaktionen zwischen dem Vordergrundobjekt 13 und dem Hintergrundobjekt 32 werden durch den Rest des Systems vermittelt.
Damit braucht sich ein Entwickler nicht weiter zu bemühen, wenn eine spezielle Dienstleistung entwickelt wird, um Mehrparteien-Nutzungsphasensteuerungsfunktionen zu implementieren, die von dem System zur Verfügung gestellt werden. Diese Funktionen beinhalten die Erzeugung von Ereignisnachrichten, die die dienstspezifische Preisberechnung des jedem Anwender angebotenen Dienstes und die dienstspezifische Kostenberechnung des Dienstes von dem Dienstanbieter gegenüber dem Zwischenhändler ermöglichen. Alles, was der Dienstanbieter benötigt, um eine Dienstleistung zu entwickeln und zu implementieren, die nichtsdestotrotz individuell berechnet und abgerechnet werden soll, ist der Code für die Dienstanbieterfunktionalität in dem dienstspezifischen Vordergrundobjekt 13 und der Code für die Dienstanbieterfunktonalität in dem dienstspezifischen Hintergrundobjekt 32.
Die Ereignismitteilungen durch das Nutzungsphasenobjekt 30 an die Ereignisverwaltungseinrichtung in den 5 bis 13 sind nur als Beispiel möglicher Ereignisnachrichten anzusehen. Eine voll ständigere Liste von Nutzungsphasen bezogenen Ereignissen, die durch das Nutzungsphasenobjekt 30 mitgeteilt werden können, ist die folgende:

i) ein Anwender beginnt mit einer Dienstleistungsnutzungsphase,
ii) ein Teilnehmer besucht eine existierende Dienstleistungsnutzungsphase,
iii) ein Teilnehmer unterbricht die Teilnahme an einer existierenden Dienstleistungsnutzungsphase,
iv) ein Teilnehmer nimmt die Teilnahme an einer existierenden Dienstleistungsnutzungsphase wieder auf,
v) ein Teilnehmer verlässt eine Dienstleistungsnutzungsphase,
vi) ein Teilnehmer fordert einen weiteren Anwender des Systems auf, eine Dienstleistungsnutzungsphase zu besuchen,
vii) ein Teilnehmer wirbt allgemein für eine Dienstleistungsnutzungsphase bei Anwendern des Systems, indem diese Anwender aufgefordert werden, eine Dienstleistungsnutzungsphase zu besuchen,
viii) ein Anwender des Systems lehnt eine Aufforderung zum Besuch einer Dienstleistungsnutzungsphase ab,
ix) ein Teilnehmer zieht eine allgemeine Werbung bei Anwendern des Systems zurück, mit der diese Anwender aufgefordert werden, eine Dienstleistungsnutzungsphase zu besuchen,
x) eine Dienstleistungsnutzungsphase wird beendet.

Es ist ein kennzeichnendes Merkmal der Ereignisnachrichten, die an die Ereignisverwaltungsvorrichtung 31 geschickt werden, dass die Ereignisse mit Einzelheiten in den Ereignisnachrichten keine Ablaufdaten enthalten. Mit anderen Worten, die Ereignisse sind nicht logisch miteinander verknüpft, und jede Nachricht betrifft nur ein augenblickliches Ereignis, das gerade in der Nutzungsphase aufge treten ist. Dies muss verglichen werden mit anderen bekannten Arten zum Erzeugen von Ereignissen, die allgemein die Berechnung einer Dauer enthalten, die sich auf Startdatum/Zeit beim Ablauf bei Empfang eines Stoppdatum/Zeit-Wertes bezieht. Auf Grund der Tatsache, dass die Ereignisse, die an die Ereignisverwaltungseinrichtung übermittelt werden, nicht logisch zusammenhängen, erhält man eine Flexibilität bei der Verarbeitung, die nachfolgend auf die Ereignisse angewendet werden kann, auf einem hohen Niveau.
Jede Ereignisnachricht enthält die folgenden Daten:

1. eine Nutzungsphasen-ID,
2. den Namen der Dienstleistung (oder eine Identifizierung), der im Verlauf der Nutzungsphase vergeben wird,
3. eine Kategorie des Ereignisses (zum Beispiel Nutzungsphasen-bezogen, Teilnehmer-bezogen, definiert durch Dienstanbieter, Aufforderung oder andere Kategorie des Ereignisses),
4. Ereignistyp (zum Beispiel Start, Stopp, Besuch, ...),
5. Datum/Zeit-Stempel,
6. Teilnehmer-ID, die im Zusammenhang der Nutzungsphase eindeutig ist,
7. Anwendername des Teilnehmers,
8. Identität des Rechnungsempfängers, die konstant in Bezug auf einen bestimmten Teilnehmer über eine Nutzungsphase bleibt.

Bei den Ereigniskategorien, die oben genannt wurden, bezieht sich eine Ereigniskategorie auf eine Kategorie, die durch einen Dienstanbieter definiert ist. Die bisherigen Erläuterungen bezogen sich auf Ereignisse, die automatisch durch das Dienstanbietungsunterstützungssystem erzeugt wurden. Um weitere Flexibilität zu gewähren, kann ein dritter Dienstanbieter eine dienstleistungsspezifische Abrechnung beinhalten, die an einem geeigneten Punkt im Verlauf ei ner Server-Nutzungsphase erzeugt wird. Derartige, durch den Dienstanbieter definierte Ereignisse werden in der Dienstleistungssteuerungskomponente, in dem Bereich des Dienstanbieters, initiiert und an die Ereignisverwaltungseinrichtung auf die gleiche Art weitergeleitet wie die bereits oben genannten dienstleistungsgenerischen Nutzungsphasenereignisse.
14 zeigt eine Ausführungsform der Ereignisverwaltungseinrichtung 31, die die Abrechnung von der Nutzung von Dienstleistungen auf einer Basis der Nutzungsphasen durchführt.
Ereignisnachrichten kommen bei der Ereignisverwaltungseinrichtung an einem Ereignis-Router-Objekt 100 an. Bei Empfang einer Ereignisnachricht, mit der der Beginn einer neuen Dienstleistungsnutzungsphase angezeigt wird, erzeugt der Ereignis-Router eine Nachricht, die an ein Nutzungsphasenabrechnungsherstellungsobjekt 102 gesendet wird, einschließlich der Identität der Nutzungsphase. Das Nutzungsphasenabrechnungsherstellungsobjekt 102 fährt fort, indem ein Dienstleistungstarifobjekt 106 von einem Tarifverwaltungsobjekt 104 geladen wird.
Die Dienstleitungstarifanfrage, die durch das Nutzungsphasenabrechnungsherstellungsobjekt abgesendet wurde, enthält die Identität der Dienstleistung, zu der die Nutzungsphase gehört, und der Dienstleistungstarif, der von der Tarifverwaltung zurückgeschickt wird, ist dienstleistungsspezifisch.
Ein oder mehrere Dienstleistungstarife können von der Tarifverwaltung für jede Dienstleistung gespeichert werden, die von dem gesamten Dienstleistungsanbietungsunterstützungssystem bereitgestellt wird. In dem Fall von mehr als einem Dienstleistungstarif für eine Dienstleistung wird der entsprechende Eintrag in Abhängigkeit von Eingangsparametern ausgewählt, wie zum Beispiel Datum/Zeit bei Start der Nutzungsphase, Abrechnungsstatus des ersten Teilnehmers in der Nutzungsphase etc.
Ein Dienstleistungstarif kann auch für verschiedene Dienstleistungen gelten, die auf dieselbe Art abgerechnet werden.
Der Dienstleistungstarif beinhaltet Daten, die festlegen, wie Ereignisse logisch zusammenhängen und/oder gefiltert werden, um eine Teilnahme in einer Nutzungsphase abzurechnen.
Bei Empfang des Dienstleistungstarifs 106 von der Tarifverwaltung 104 richtet das Nutzungsphasenabrechnungsherstellungsobjekt 102 ein Nutzungsphasenabrechnungsverwaltungsobjekt 108 ein, das Ereignisfilterregeldaten 110 und Teilnahmeabrechnungsmaschinenentwicklungsregeldaten 112 enthält, die aus dem Dienstleistungstarif abgeleitet wurden, der speziell für die Dienstleistung gilt, die von der Nutzungsphasenabrechnungsverwaltung bearbeitet werden soll.
Eine Dienstleistungsnutzungsphase wird durch einen einzelnen Teilnehmer gestartet, für den der Nutzungsphasenabrechnungsmanager ein einzelnes Teilnahmeabrechnungsmaschinenobjekt 114 einrichtet. Die Teilnahmeabrechnungsmaschine 114 enthält Abrechnungsregeln, die aus dem Dienstleistungstarif abgeleitet werden, der ursprünglich von der Tarifverwaltung empfangen wurde.
Beim Einrichten des Nutzungsphasenabrechnungsmanagers 108 liefert das Nutzungsphasenabrechnungsherstellungsobjekt 102 eine Zieladresse für die Nutzungsphasenabrechnungsverwaltungseinrichtung 108 an den Ereignis-Router 100 zurück. Bei Empfang der Nut zungsphasenabrechnungsverwaltungsadresse übermittelt der Ereignis-Router 100 eine Nachricht an die Dienstleistungstarifobjekt 106 Nutzungsphasenabrechnungsverwaltung, mit der sie instruiert wird, einen Ereigniskanal zu verbinden, wodurch die Ereignisnachrichten, die von dem Ereignis-Router empfangen werden und zu der Nutzungsphase gehören, die durch die Nutzungsphasenabrechnungsverwaltungseinrichtung bearbeitet werden, zu der Nutzungsphasenabrechnungsverwaltung weitergeleitet werden.
Der Ereignis-Router selbst empfängt Ereignisnachrichten zu einer Anzahl von verschiedenen Nutzungsphasen, die gerade in dem Dienstleistungsanbietungsunterstützungssystem ablaufen, und leitet die Ereignisse an die verschiedenen entsprechenden Nutzungsphaseabrechnungsverwaltungseinrichtungen weiter.
Wie sich aus dem Vorangehenden ergibt, empfängt die Nutzungsphasenabrechnungsverwaltungseinrichtung 108 Ereignisnachrichten, die von einer Dienstleistungsnutzungsphase stammen, wodurch die Nutzungsphasenabrechnungsverwaltungseinrichtung über einen vorgegebenen Satz von Nutzungsphasen-bezogenen Ereignissen informiert wird, ob und wann sie in einer Dienstleistungsnutzungsphase auftreten.
Sobald die Nutzungsphasenverwaltungseinrichtung Ereignisnachrichten empfängt, die neue Teilnehmer melden, die eine Nutzungsphase besuchen, werden zusätzliche Teilnehmerabrechnungsmaschinen eingerichtet.
Die Nutzungsphasenabrechnungsverwaltungseinrichtung 108 wendet Ereignisfilterregeln an, um Ereignisse auszusortieren, die bezüglich der fraglichen Dienstleistung keine Rolle in Bezug auf die Ab rechnung spielen. Die Nutzungsphasenabrechnungsverwaltungseinrichtung kopiert jedes der gefilterten Ereignisse auf mehrere Teilnahmeabrechnungsmaschinen 114, um eine logische Verknüpfung in Übereinstimmung mit einem definierten Berechnungsalgorithmus herzustellen, um berechnete Abrechnungsdaten für jede Teilnahme in der Nutzungsphase zu erzeugen. Die Abrechnungsdaten, die berechnet wurden, und Ereigniszusammenfassungsinformation werden dann an ein Rechnungssystemlogbuch übermittelt, um die Berechnung zu ermöglichen, die einem Konto der verantwortlichen Partei für jede Teilnahme in Rechnung gestellt wird.
Wie sich hieraus ergibt, ermöglicht dieser Aufbau, dass nicht nur der Teilnehmer, für den eine Teilnahme abgerechnet wird, in dem verwendeten Abrechnungsalgorithmus berücksichtigt wird, sondern er ermöglicht es auch, dass Aktionen oder Veränderungen des Status anderer Teilnehmer innerhalb der Dienstleistungsnutzungsphase berücksichtigt werden bei der Ausführung des Berechnungsalgorithmus bezüglich der fraglichen Teilnahme.
Bei Empfang einer Nachricht, die anzeigt, dass die Nutzungsphase beendet worden ist, kopiert die Dienstleistungsabrechnungsverwaltung die Nachricht in jede Teilnahmeabrechnungsmaschine und löscht sich dann selbst. Jede Teilnahmeabrechnungsmaschine erzeugt eine Abfolge von Abrechnungsdaten, die als Ergebnis der Ereignisse erzeugt wurden, die innerhalb der Nutzungsphase aufgetreten sind und Bezug zu dem Teilnehmer haben, für den die Teilnahmeabrechnungsmaschine verantwortlich ist, und die Abrechnungsdaten werden an ein Rechnungslogbuch übermittelt, um gegenüber dem Rechnungskonto der Partei in Rechnung gestellt zu werden. Jede Teilnahmeabrechnungsmaschine löscht sich dann selbst.
Um ein Beispiel für die Berechnung zu geben, die verwendet werden kann bei einem Dienstleistungsbeispiel, kann das System bei einer Konferenzdienstleistung den Organisator einer Konferenznutzungsphase mit einer Eingangsgebühr von N pro Teilnehmer an der Nutzungsphase belasten, und jeder Teilnehmer wird individuell mit einer Nutzungsgebühr von n pro Zeiteinheit belastet.
Bei einem Beispiel einer Nutzungsphase kann für diesen Fall ein Teilnehmer 1 mit einem ersten Anwenderstatus, wie zum Beispiel dem des Organisators dieser Nutzungsphase, vorhanden sein, der die Nutzungsphase startet und die Teilnehmer 2 und 3 einlädt, die Nutzungsphase mit einem zweiten Anwenderstatus zu besuchen, wie zum Beispiel dem normaler Teilnehmer. Die Teilnehmer 2 und 3 nehmen die Einladung an. Danach unterbricht der Teilnehmer 2. Der Teilnehmer 3 verlässt die Nutzungsphase. Der Teilnehmer 2 nimmt sie wieder auf und verlässt danach die Nutzungsphase zusammen mit Teilnehmer 1.
In diesem Beispielszenario empfängt die Teilnahmeabrechnungsmaschine für den Konferenzorganisator (Teilnehmer 1) Ereignisnachrichten, die sie über die weiteren Anwender informieren, die die Nutzungsphase besuchen, in dem obigen Beispiel sind dies die Teilnehmer 2 und 3, die sich zu Besuch aufhalten. Die Eingangsgebühr wird dann dreimal durch die Teilnahmeabrechnungsmaschine für den Teilnehmer 1 in Rechnung gestellt. Die Teilnahmeabrechnungsmaschinen, die die Nutzung durch die Teilnehmer 2 und 3 berechnen, empfangen Ereignisnachrichten einschließlich Nachrichten, mit denen festgelegt wird, wann die Partei, für die sie verantwortlich sind, besucht, unterbricht, wieder aufnimmt und verlässt, und sie berechnen eine Zeit basierende Belastung entsprechend.
Um ein weiteres Beispiel anzugeben, kann eine Dienstleistung in Form eines Spiels mit einer Gebühr X pro Zeiteinheit abgerechnet werden, dividiert durch die Anzahl der Teilnehmer, die zu einem bestimmten Zeitpunkt beteiligt sind, und dies pro Teilnahme.
In diesem Beispiel spielen drei Teilnehmer das Spiel. Der Teilnehmer 1 beginnt die Nutzungsphase und fordert die Teilnehmer 2 und 3 auf, die dann die Nutzungsphase besuchen. Nach einer gewissen Zeit verlässt der Teilnehmer 1 die Nutzungsphase. Später verlassen Teilnehmer 2 und 3.
In diesem Beispielszenario muss die Teilnahmeabrechnungsmaschine für Teilnehmer 1 Kenntnis von dem Nutzungsphasen-bezogenen Status jedes Teilnehmers in der Nutzungsphase haben, auf Grund der zu Grunde gelegten Abrechnungsregeln. Wenn die Teilnehmer 1, 2 und 3 in der Nutzungsphase aktiv sind, wird jeder Teilnehmer mit X/3 pro Zeiteinheit belastet. Wenn der Teilnehmer 1 die Nutzungsphase verlässt, werden die Teilnehmer 2 und 3 mit X/2 pro Zeiteinheit belastet, auf Grund der reduzierten Anzahl der betroffenen Teilnehmer.
Wie sich aus den beiden obigen Szenarios ergibt, ermöglicht die automatische Erzeugung eines umfassenden Satzes von Ereignisnachrichten, die gefiltert und auf individuelle Teilnahmeabrechnungsmaschinen kopiert werden können, Berechnungsregeln für eine Dienstleistung zu Grunde zu legen, die flexibel und individuell konfigurierbar sind, ohne auf die Dienstleistungsnutzungsphasen-Software zurückzugreifen oder sogar die Dienstleistungs-Software selbst, um von den Berechnungsregeln in Kenntnis zu gelangen, die für die Dienstleistung zu Grunde gelegt werden. Außerdem können die Berechnungsgrundlagen dynamisch ohne weiteres im Lauf der Zeit ver ändert werden. Alles, was notwendig ist, um die Berechnungsgrundlagen für eine spezielle Dienstleistung zu verändern, ist die Bereitstellung eines neuen Dienstleistungstarifs aus der Tarifverwaltungseinrichtung für die fragliche Dienstleistung.
Außerdem kann jede individuelle Teilnahmeabrechnungsmaschine konfiguriert werden auf einer anwenderabhängigen Basis. Insbesondere können Teilnehmerdaten der Anwender verwendet werden, um anwenderspezifische Abrechnungen von Teilnahmen in der Nutzungsphase zu ermöglichen. Dies kann Umfangsnachlässe etc. beinhalten, die in Bezug auf die Abrechnung angewendet werden, die durch jede Teilnahmeabrechnungsmaschine angewendet werden. Außerdem können die Teilnahmeabrechnungsmaschinen in Anhängigkeit davon konfiguriert werden, welche Rolle ein Teilnehmer in einer Nutzungsphase spielt. Als Beispiel kann ein Anwender die Rolle eines aktiven Spielers oder passiven Beobachters in einer Nutzungsphase einnehmen. Die Kosten für die Teilnahme können in Abhängigkeit von der gespielten Rolle variieren. Um derartige Rollen berücksichtigen zu können, wendet der Nutzungsphasenabrechnungsmanager bei Erkennen eines weiteren Teilnehmers, der eine Nutzungsphase besucht, die PPE-Einrichtungsregeldaten 102 an, um eine Teilnahmeabrechnungsmaschine 114 nicht nur in Übereinstimmung mit dem Dienstleistungstarif, sondern auch mit den entsprechenden Teilnahmearteneigenschaften einzurichten.
15 zeigt eine weitere Ausführungsform der Erfindung, bei der der Ereignis-Router 100 Ereignisnachrichten kopiert, die von einem einzelnen Nutzungsphasenobjekt 30 stammen, für die Weiterverbreitung auf verschiedene Teile des Ereignisverwaltungssystems, die verantwortlich sind für verschiedene Aspekte der Ereignisverwaltung. Bei der dargestellten Ausführungsform beinhalten diese ver schiedenen Teile eine Kundenabrechnungsmaschine 200, die ähnlich der sein kann, die mit Bezug auf 14 beschrieben wurde, eine Anwendungsanalysemaschine 300 und eine Drittkostenmaschine 400.
Der Ereignis-Router 100 enthält eine Kanalzuordnungstabelle, die ein Register zum Festlegen des Ziels von Ereignissen darstellt, die von verschiedenen Nutzungsphasenobjekten empfangen wurden, und zwar über eine Schnellsuche.
Die Kundenabrechnungsmaschine 200 wendet Filterregeln und Tarife auf die Ereignisse an, die im Verlauf einer Nutzungsphase auftreten, um Abrechnungsabläufe für jeden individuellen Teilnehmer in der Nutzungsphase zu erzeugen.
Die Anwendungsanalysemaschine 300 speichert die Ereignisdaten, die an sie weitergeleitet wurden, für eine große Anzahl von Dienstleistungsnutzungsphasen, so dass eine statistisch signifikante Datenmenge bezüglich der Anwendung von Dienstleistungen in dem System aufgebaut wird. Die Anwendungsanalysemaschine kann dann statistisch ausgewertete Daten für die weitere Verwendung bei der Überwachung und Verbesserung der Qualität und des Umfangs der durch das System bereitgestellten Dienstleistungen erzeugen.
Die Drittkostenmaschine 400 empfängt die Ereignisse von dem Nutzungsphasenobjekt 30 und filtert und wertet die Ereignisse logisch aus, die während der Nutzungsphase auftreten, und zwar in Übereinstimmung mit Drittkosten für die Dienstleistungen in Frage, um ein Verfahren zum Berechnen von Zahlungen bereitzustellen, die durch den Dienstleistungszwischenhändler an die Dienstanbieter geleistet werden müssen.
Wie sich aus 15 ergibt, ist die Bereitstellung einer vorgegebenen Menge von Ereignissen, die automatisch durch das Dienstleistungsbereitstellungsunterstützungssystem erzeugt werden, derart, dass flexible Kundenabrechnungen direkt aus den Nachrichten erzeugt werden können, die von einer Kundenabrechnungsmaschine empfangen wurden. Außerdem können andere Verarbeitungen dieselben Ereignisnachrichten oder eine Kopie davon verwenden.

Claims

System zur Unterstützung der Bereitstellung von Diensten, durch das mehrere unterschiedliche Arten von Diensten im Verlauf von Dienstnutzungsphasen unterstützt werden, wobei das System im Betrieb einen Dienstnutzungsphasenmanager (28) umfasst, der generische Funktionen in Bezug auf jeden der mehreren unterschiedlichen Arten von Diensten im Verlauf der Dienstnutzungsphasen durchführt, wobei das Unterstützungssystem dadurch gekennzeichnet ist, dass: für jeden der mehreren Arten von Diensten der Dienstnutzungsphasenmanager (28) ausgelegt ist, ein dienstgenerisches Dienstnutzungsphasenobjekt (30) zu bestimmen, um jede Dienstnutzungsphase zu überwachen, wobei die dienstgenerischen Dienstnutzungsphasenobjekte (30) jeweils ausgelegt sind, um im Verlauf einer Dienstnutzungsphase, an der mehrere Teilnehmer teilnehmen: mehrere Ereignisnachrichten mit Bezug auf dienstgenerisches Dienstnutzungsphasenverhalten während der Dienstnutzungsphase zu erzeugen, wobei jede Ereignisnachricht ein Ereignis anzeigt, das keine Verlaufsdaten enthält, und eine diskrete und unmittelbare Veränderung in Bezug auf den Status im Zusammenhang mit dem Dienstnutzungsphasenverhalten eines einzelnen unter den mehreren Teilnehmern der Dienstnutzungsphasenereignisnachrichten umfasst, die für jeden der mehreren Teilnehmer erzeugt werden, und die Ereignisnachrichten an eine dienstgenerische Ereignisverwaltungsvorrichtung (31) für die weitere Verarbeitung zu über tragen, wobei die dienstgenerische Ereignisverwaltungsvorrichtung (31) Ereignisnachrichten von jedem der dienstgenerischen Dienstnutzungsphasenobjekte (30) empfängt.
System zur Unterstützung der Bereitstellung von Diensten nach Anspruch 1, bei dem die Ereignisverwaltungsvorrichtung (31) eine Dienstnutzungsüberwachungseinrichtung umfasst und die Ereignisnachrichten für die Abspeicherung und/oder Nutzungsanalyse der Dienste über eine statistisch signifikante Anzahl von Dienstnutzungsphasen verarbeitet.
System zur Unterstützung der Bereitstellung von Diensten nach einem der vorangehenden Ansprüche, bei dem die Ereignisverwaltungsvorrichtung (31) einen Bewertungsdatenprozessor umfasst und die Ereignisnachrichten verarbeitet, um eine dienstspezifische Bewertung der Nutzung eines Dienstes durch einen Teilnehmer im Verlauf der Dienstnutzungsphase bereitzustellen, an der mehrere Teilnehmer teilnehmen.
System zur Unterstützung der Bereitstellung von Diensten nach einem der vorangehenden Ansprüche, bei dem die Ereignisverwaltungsvorrichtung (31) einen Kostendatenprozessor umfasst und die Ereignisnachrichten verarbeitet, um eine Kostenanalyse eines Dienstes bereitzustellen, der von einem Dritten während einer Dienstnutzungsphase, an der mehrere Teilnehmer teilnehmen, einem Wiederverkäufer zur Verfügung gestellt wird, wobei der Wiederverkäufer das System zur Unterstützung der Bereitstellung von Diensten zur Verfügung stellt.
System zur Unterstützung der Bereitstellung von Diensten nach einem der vorangehenden Ansprüche, bei dem ein Ereignis oh ne Verlaufsdaten eine diskrete und unmittelbare Veränderung in Bezug auf den Status in Zusammenhang mit dem Dienstnutzungsphasenverhalten eines einzelnen von den mehreren Teilnehmern an der Dienstnutzungsphase umfasst, wobei die diskrete und unmittelbare Veränderung, die enthalten ist, eines der folgenden Ereignisse beinhaltet: i) eine Dienstnutzungsphase wird durch einen Anwender gestartet, ii) ein Teilnehmer kommt in einer existierenden Dienstnutzungsphase hinzu, iii) ein Teilnehmer unterbricht die Teilnahme an einer existierenden Dienstnutzungsphase, iv) ein Teilnehmer nimmt die Teilnahme an einer existierenden Dienstnutzungsphase wieder auf, v) ein Teilnehmer verlässt eine Dienstnutzungsphase, vi) ein Teilnehmer lädt einen weiteren Anwender des Systems zu einer Dienstnutzungsphase ein, vii) ein Teilnehmer zeigt eine Dienstnutzungsphase allgemein den Anwendern des Systems an und lädt diese Anwender zu einer Dienstnutzungsphase ein, viii) ein Anwender des Systems lehnt eine Einladung zu einer Dienstnutzungsphase ab, ix) ein Teilnehmer zieht eine allgemeine Anzeige gegenüber den Anwendern des Systems mit Einladung dieser Anwender zu einer Dienstnutzungsphase zurück, x) eine Dienstnutzungsphase wird beendet.
Verfahren zum generisch Benachrichtigen einer dienstgenerischen Ereignisverwaltungsvorrichtung (31) für die Verarbeitung über Ereignisse mit Bezug auf dienstgenerisches Dienstnutzungsphasenverhalten, wobei die Ereignisse im Verlauf mehre rer Dienstnutzungsphasen auftreten, bei denen mehrere Teilnehmer teilnehmen, wobei die Dienstnutzungsphasen in einem System zur Unterstützung der Bereitstellung von Diensten zur Verfügung gestellt werden, wobei das Verfahren umfasst: Erzeugen während der Dienstnutzungsphasen von mehreren der Ereignisnachrichten mit Bezug auf das dienstgenerische Dienstnutzungsphasenverhalten für jeden Teilnehmer, wobei jede Ereignisnachricht ein Ereignis ohne Verlaufsdaten enthält und eine diskrete und unmittelbare Veränderung in Bezug auf den Status in Zusammenhang mit dem Dienstnutzungsphasenverhalten eines einzelnen von mehreren Teilnehmern der Dienstnutzungsphasen umfasst, und Übertragen der mehreren Ereignisnachrichten mit Bezug auf dienstgenerisches Dienstnutzungsphasenverhalten an eine dienstgenerische Ereignisverwaltungsvorrichtung (31) für die Verarbeitung von jeder der Dienstnutzungsphasen.
Verfahren nach Anspruch 6, bei dem das Ereignis ohne Verlaufsdaten eine diskrete und unmittelbare Veränderung in Bezug auf den Status in Zusammenhang mit dem Dienstnutzungsphasenverhalten eines einzelnen von mehreren Teilnehmern der Dienstnutzungsphase umfasst, wobei die diskrete und unmittelbare Veränderung, die enthalten ist, eines der folgenden Ereignisse beinhaltet: i) eine Dienstnutzungsphase wird durch einen Anwender gestartet, ii) ein Teilnehmer kommt in einer existierenden Dienstnutzungsphase hinzu, iii) ein Teilnehmer unterbricht die Teilnahme an einer existierenden Dienstnutzungsphase, iv) ein Teilnehmer nimmt die Teilnahme an einer existierenden Dienstnutzungsphase wieder auf, v) ein Teilnehmer verlässt eine Dienstnutzungsphase, vi) ein Teilnehmer lädt einen weiteren Anwender des Systems zu einer Dienstnutzungsphase ein, vii) ein Teilnehmer zeigt eine Dienstnutzungsphase allgemein den Anwendern des Systems an und lädt diese Anwender zu einer Dienstnutzungsphase ein, viii) ein Anwender des Systems lehnt eine Einladung zu einer Dienstnutzungsphase ab, ix) ein Teilnehmer zieht eine allgemeine Anzeige gegenüber den Anwendern des Systems mit Einladung dieser Anwender zu einer Dienstnutzungsphase zurück, x) eine Dienstnutzungsphase wird beendet.