SIP Proxy), der für die Dauer der Servicebeziehung zwischen einer Dienstnutzereinrichtung (Client) und einem Application Server nicht in diese Beziehung eingebunden ist, (d. h. z. B. kein Stateful SIP-Proxy), ist es für den Proxy unmöglich eine zuverlässige Vergebührungsfunktion für registrierte Kunden (Anwender und Diensteanbieter) bereitzustellen.

Bisherige Lösungen der Problemstellung - Proxy bleibt in der Kommunikationsbeziehung für die Dauer der Servicebeziehung (Stateful Proxy), oder - Vergebührung läuft separat zwischen Application Server und Client ohne Einbeziehung des Proxies, d. h. der Betreiber des Proxies ist ausschließlich Access-Provider. Eine Ge- samtrechnung aus einer Hand auch für in Anspruch genommene Dienste lassen sich-wenn überhaupt-dann nur mit großem Aufwand im Postprocessing erreichen-> Verteilte Billing- funktionen beim Proxy-Betreiber und beim Application Ser- ver Provider. Diese Lösung erfordert zum einen die Sicher- stellung, daß der Nutzer eines Services auch gleichzeitig Kunde von Proxy-und Serverbetreiber ist, und zum anderen die Übermittlung von Daten an den zentralen Rechnung- sersteller.

Lösung der Problemstellung gemäß der Erfindung Die Erfindung beschreibt ein Verfahren, wie in einem derarti- gen Scenario mit Client, Proxy (=Applikationsbroker, Applika- tionsvermittlungseinrichtung). und Applikationsserver eine für alle Partner zuverlässige Vergebührung erreicht werden kann, die zudem für den Anbieter (Provider) des Grunddienstes (Betreiber des Proxy) einen Mehrwertdienst darstellt. Dieser Provider ist damit in der Lage, seinem Endkunden eine zuver- lässige Rechnung aus einer Hand mit paketorientierten Diens- ten von unterschiedlichsten Partner-Serviceprovidern anzubie- ten. Dabei kann der Grunddienstanbieter sowohl als einfacher Vermittler eines Dienstes, als auch als Zwischenhändler mit "Rebranding"auftreten (Unter"Rebranding"wird hierbei ver- standen, dass der Betreiber des Proxy einen Dienst eines Partner-Serviceprovider nicht unter dem ursprünglichen Namen des Dienstes sondern unter einem eigenen Produktnamen anbie- tet).

Letztendlich ist der Zweck dieses Verfahren, a) Registrierten Endkunden (Clients) mit einem Guthabenkon- to in Echtzeit Nutzungsgebühren für angeforderte und ge- nutzte Dienste zu verrechnen, oder b) Registrierten Endkunden regelmäßig (z. B. monatlich) eine einheitliche Gesamtrechnung für alle genutzten Services von unterschiedlichen Providern zu erstellen.

Mit dem Verfahren wird sichergestellt, dass a) der Kunde nur das bezahlt, was er nutzt, und b) der Diensterbringer für seine Leistungen bezahlt wird.

Daneben schafft dieses Verfahren die Voraussetzung dafür, daß dem Kunden als Option schon während der Dienstenutzung in Re- alzeit angezeigt werden kann, welche Gebühren für den Dienst aufgelaufen sind, bzw. bei Prepaid-Service, wie viel Guthaben noch vorhanden ist.

Grundlage dieser Lösung ist eine zuverlässige Vergebührungs- funktion, in die alle Partner-Komponenten (Client, Proxy/ Application Broker, Application Server) _ während der Dienste- nutzung eingebunden sind.

Client : Authentifiziert sich beim Proxy und fordert Dienst an.

Proxy/Application Broker : Vermittelt Dienst und führt Buch über die Nutzung dieses Dienstes durch den Client.

Application Server : Bietet Dienst an und informiert mit Ti- ckets den Proxy über Zustandekommen und Verlauf der Service- beziehung zwischen ihm und dem Client.

Abbildung 1 beschreibt bei einer Realisierungsvariante der Erfindung die Beziehungen der Partner-Komponenten untereinan- der und den prinzipiellen Ablauf von der Authentifizierung des Clients über die Dienstanforderung und Diensterbringung bis hin zur Vergebührung.

- Nachdem sich der Client mithilfe des Proxy bei dem Authen- tification-Authorization-Accounting-Server (AAA-Server) authentifiziert hat (l)/ (2) erhält er von dem Proxy zusam- men mit der Angabe, wo sich der Application Server befin- det (Destination) eine Billing-Reference (pl), die vom Proxy zur Ausübung der Vergebührungsfunktion für die an- stehende Dienstnutzung generiert wird (3).

- Der Client fordert mit der Information, die er vom Proxy erhalten hat, beim Application Server den gewünschten Dienst an (4). Dieser bestätigt die Dienstanforderung an den Client (5). Hiermit ist die Servicebeziehung zwischen Client und Application Server eingerichtet.

- Nachdem die Servicebeziehung zwischen Client und Applica- tion Server aufgebaut worden ist, und solange der Dienst genutzt wird, erstellt der Application Server in regelmä- ßigen Abständen (z. B. 1 pro Minute) Tickets, die an die Vergebührungsfunktion auf dem Proxy gesendet werden (6).

Diese Tickets enthalten die Reference pl, die dem Proxy erlaubt, effizient auf die Vergebührungstabelle (Billing-

Tabelle) zuzugreifen, und die Reference sl, die der Server selbst erstellt hat, und mit welcher er gegebenenfalls später bei einer Rückmeldung vom Proxy effizient auf seine Daten zugreifen und eine bestehende Service Relationship beenden kann.

- Nach Erhalt eines Tickets (6) ermittelt der Proxy anhand der in dem Ticket enthaltenen Reference pl den Client (IP- Adresse Cl) und fordert von diesem für jedes empfangene Ticket eine Bestätigung dieser Vergebührungsdaten an (7).

Falls nach einer bestimmten Zeit (z. B. 1 Sekunde) die Bes- tätigung nicht empfangen wurde, wird die Anforderung (7) ein-oder zweimal wiederholt.

- Nach Empfang der Bestätigungsanforderung verifiziert der Client das Ticket und sendet gegebenenfalls eine Bestäti- gung an den Proxy (8).

Nach Empfang einer Bestätigung vom Client speichert der Proxy das Ticket zu einer späteren Rechnungserstellung ab (9) und informiert den Server, dass der Client das Ticket bestätigt hat. Im Falle eines Prepaid-Kunden aktualisiert die Vergebührungsfunktion auf dem Proxy den Guthabenstand des Kunden.

Sonderfälle bei der beschriebenen Realisierungsvariante der Erfindung : - Prepaid-Kunde : Wenn das Guthaben eine bestimmte Schwelle unterschreitet informiert der Proxy den Client, daß das Guthaben fast aufgebraucht ist. Dies kann z. B. mit der nächsten Anforde- rung einer Bestätigung für ein Ticket erfolgen (7). Falls das Guthaben aufgebraucht ist, wird der Proxy den Eintrag in der Billing Table löschen und weitere Tickets vom Ap- plication Server für diesen Kunden nicht mehr akzeptieren

und diese Tickets dem Server negativ quitieren, woraufhin dieser die Servicebeziehung zum Client gegebenenfalls be- enden wird.

Anforderung einer Ticketbestätigung (7) vom Client negativ quitiert : Der Proxy informiert den Application Server, dass ein Ti- cket negativ quittiert wurde, wobei er dem Application Server die Reference sl zurückgibt. Anhand der Reference sl ist der Server daraufhin in der Lage, die Servicebezie- hung zum Client zu beenden.

Ticketbestätigung vom Client trotz mehrmaliger Anforderung nicht erhalten : Der Proxy informiert den Application Server, dass er für ein Ticket keine Quittung vom Client erhalten konnte, wo- bei er dem Application Server die Reference sl zurückgibt.

Anhand der Reference sl ist der Server daraufhin in der Lage, die Servicebeziehung zum Client zu beenden.

Timer tl für Billing Table Eintrag läuft ab.

Um die Gültigkeit eines Billig Table Eintrags zu sichern, überwacht der Proxy den Eingang der Tickets vom Server.

Sobald ein Ticket (6) eintrifft, wird der eingestellte Ti- mer zurückgesetzt. Bei Ablauf des Timers wird der Eintrag in der Tabelle gelöscht. Eventuell nachfolgend eintreffen- de Tickets vom Server werden negativ quittiert.

Bemerkungen : Zu beachten ist, daß dieses Verfahren nicht erfordert, dass Server und/oder Client sich bei Beendigung der Servi- cebeziehung beim Proxy abmelden. So erfolgt auch die Versendung eines Vergebührungstickets an den Client immer im Voraus für das aktuelle Vergebührungsintervall. Damit ist sichergestellt, daß der Client nicht kostenpflichtige

Dienste in Anspruch nimmt, ohne dass er dafür bezahlt, in- dem er vor Ablauf eines Vergebührungsintervalls einfach den Dienst abbricht, um zu verhindern, dass er für das vergangene Intervall vergebührt wird.

Der Überwachungstimer tl in der Billing Table muss auf je- den Fall größer als die Länge des Vergebührungsintervall sein, das zwischen Client und Application Server verein- bart wird. Es muß groß genug gewählt werden, um zu vermei- den, dass eine verloren gegangene (und deshalb vom Server wiederholte) Ticketnachricht an den Proxy dazu führt, dass dieser den Billing Table Eintrag für ungültig erklärt.

Gleichzeitig darf tl aber nicht zu groß gewählt werden, um zu vermeiden, dass beispielsweise Denial-of-Service Atta- cken von böswilligen Clients zu einer Verknappung der Bil- ling Table Resourcen und letztlich zu einer Nichtverfüg- barkeit dieser Dienste führt. Ein vernünftiger Wert für tl ist 2-3 Mal die Länge des Vergebührungsintervalls. Da die Länge der Vergebührungsintervalle der einzelnen Servicebe- ziehungen (siehe Abb. 1) unterschiedlich sein können, wird die Länge des Überwachungstimer tl variabel gestaltet. So- bald der Proxy ein Ticket vom Server erhält, verwendet er die darin angegebene Länge des Vergebührungsintervall und bestimmt daraus die Länge von tl, um den Empfang des nächsten Tickets vom Server für diese Servicebeziehung zu überwachen. Bis zum Empfang des ersten Tickets vom Server wird ein für die Billing Table einheitlicher fester Initi- alwert für diesen Timer verwendet (z. B. 5 Sekunden).

Mögliche vertrauensbildende Maßnahmen zwischen Client und Application Server : Die Konditionen für die Servicebezie- hung (Länge und Kosten des 1. Intervals, Länge und Kosten der Folgeintervalle) werden zwischen Client und Server vereinbart. Durch die Wahl eines kurzen 1. Intervals und ggf. Sonderkonditionen dafür kann sichergestellt werden, daß auch im Falle einer Nichterbringung der Leistung (z. B.

Serverausfall, SW-Fehler, Inkompatibilität von Client und Serversoftware) trotz aufgebauter Servicebeziehung für den

Dienstanwender kein oder nur ein geringer Nachteil ent- steht.

- Bei Ausfall der Vergebührungsfunktion des Proxies kann der Application Server aufgrund der ausbleibenden Quittung auf das Ticket die Servicebeziehung zum Client gegebenenfalls abbrechen.

- Bei Ausfall des Clients wird das Gebührenkonto des Kunden nicht fälschlicherweise weiter vom Server belastet, da Client nicht mehr in der Lage ist, weitere Ticketbestäti- gungsanforderungen des Proxy zu quittieren (siehe Sonder- fälle).

- Funktionalität beim Client erweiterbar z. B. um i. Kummulierung der vom Proxy übermittelten Gebührennach- richten und Anzeige dieser Gebühren am Terminal zur Ge- bühren-überwachung in Realzeit. ii. Möglichkeit für Endbenutzer als Option Tickets manuell zurückzuweisen, z. B. bei Erreichen eines bestimmten selbstgesetzten Gebührenlimits.

Zusammenfassend kann folgendes gesagt werden. Das beschriebe- ne Verfahren erlaubt dem Betreiber eines Stateless Proxy bzw.

Application Brokers auf einfache Art und Weise registrierten Application Service Anbietern und registrierten Kunden eine zuverlässige, in definierbaren Intervallen genaue und ver- trauenswürdige Vergebührungsfunktion anzubieten, indem sich während der Diensterbringung Client und Server ständig im Hintergrund in regelmäßigen Abständen über einen unabhängigen Dritten (Proxy) über die dafür anfallenden Gebühren verstän- digen und die Vergebührungsfunktion auch von dem unabhängigen Dritten erbracht wird.

Anwendungsbeispiele der Erfindung - Auskunftsdienste

- Videodienste - Telefonzusatzdienste, wie z. B. Konferenzen über Konferenz- server - Mailboxabfragen - anonymes Billing für Gateways, die aus dem offenen Inter- net angesteuert werden