EP1695300A1 - Verfahren zur vergeb hrung eines dienstes in einem kommunika tionsnetz - Google Patents

Verfahren zur vergeb hrung eines dienstes in einem kommunika tionsnetz

Info

Publication number
EP1695300A1
EP1695300A1 EP04804651A EP04804651A EP1695300A1 EP 1695300 A1 EP1695300 A1 EP 1695300A1 EP 04804651 A EP04804651 A EP 04804651A EP 04804651 A EP04804651 A EP 04804651A EP 1695300 A1 EP1695300 A1 EP 1695300A1
Authority
EP
European Patent Office
Prior art keywords
service
client
switching device
application server
service switching
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP04804651A
Other languages
English (en)
French (fr)
Inventor
Walter Held
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Solutions and Networks GmbH and Co KG
Original Assignee
Siemens AG
Nokia Siemens Networks GmbH and Co KG
Siemens Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG, Nokia Siemens Networks GmbH and Co KG, Siemens Corp filed Critical Siemens AG
Priority to EP04804651A priority Critical patent/EP1695300A1/de
Publication of EP1695300A1 publication Critical patent/EP1695300A1/de
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements specially adapted for data communications, e.g. authentication, authorisation and accounting [AAA] framework
    • H04L12/1403—Architecture for metering, charging or billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements specially adapted for data communications, e.g. authentication, authorisation and accounting [AAA] framework
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements specially adapted for data communications, e.g. authentication, authorisation and accounting [AAA] framework
    • H04L12/1453—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network
    • H04L12/1467—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network involving prepayment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/562—Brokering proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos

Definitions

  • a packet-oriented communication network with service users (for example SIP clients), service providers (for example application servers) and a brokering application broker (for example SIP proxy) that is not in the service relationship between a service user device (client) and an application server for the duration of the service relationship this relationship is involved, (eg no stateful SIP proxy), it is impossible for the proxy to provide a reliable charging function for registered customers (users and service providers).
  • service users for example SIP clients
  • service providers for example application servers
  • a brokering application broker for example SIP proxy
  • Proxy remains in the communication relationship for the duration of the service relationship (stateful proxy), or billing runs separately between the application server and client without involving the proxy, ie the operator of the proxy is exclusively the access provider.
  • a total invoice from a single source, even for services used, can - if at all - only be achieved with great effort in postprocessing -> distributed billing functions at the proxy operator and at the application server provider.
  • this solution requires ensuring that the user of a service is a customer of the proxy and server operator at the same time, and on the other hand that data is transferred to the central invoice divider.
  • This provider is thus able to offer its end customers a reliable invoice from a single source with package-oriented services from a wide variety of partner service providers.
  • the basic service provider can act both as a simple broker of a service and as an intermediary with "rebranding" ("rebranding" means that the operator of the proxy is a service of a
  • Partner service provider does not offer under the original name of the service but under its own product name).
  • this procedure is: a) to charge registered end customers (clients) with a credit account in real time for user fees for requested and used services, or b) to create a uniform overall bill for all used services from different providers on a regular basis (e.g. monthly) for all used services ,
  • the procedure ensures that a) the customer only pays for what he uses, and b) the service provider is paid for his services.
  • this procedure creates the prerequisite for the customer to be able to be shown as an option in real time which charges have been made for the service or, in the case of prepaid service, how much credit is still available.
  • the basis of this solution is a reliable billing function, in which all partner components (client, proxy / application broker, application server) are integrated during service use.
  • Client Authenticates with the proxy and requests service.
  • Proxy / Application Broker Mediates service and keeps a record of the client's use of this service.
  • Application Server Offers service and uses tickets to inform the proxy about the establishment and course of the service relationship between him and the client.
  • Figure 1 describes the relationships of the partner components with one another and the basic sequence from the authentication of the client through the service request and service provision to charging.
  • the client After the client has authenticated to the authentication-authorization-accounting server (AAA server) using the proxy (l) / (2), it receives from the proxy together with information on where the application server is located ( Destination) a billing reference (pl) that is generated by the proxy to perform the billing function for the upcoming service use (3).
  • AAA server authentication-authorization-accounting server
  • the client uses the information it has received from the proxy to request the desired service from the application server (4). This confirms the service request to the client (5). This establishes the service relationship between the client and the application server.
  • the application server After the service relationship has been established between the client and the application server and as long as the service is in use, the application server creates tickets at regular intervals (e.g. 1 per minute), which are sent to the billing function on the proxy (6). These tickets contain the reference pl, which allows the proxy to be efficiently transferred to the billing table (billing Table), and the reference sl, which the server itself has created, and with which it can later access its data efficiently when it receives feedback from the proxy and terminate an existing service relationship.
  • billing table billing Table
  • the reference sl which the server itself has created, and with which it can later access its data efficiently when it receives feedback from the proxy and terminate an existing service relationship.
  • the proxy After receiving a ticket (6), the proxy determines the client (IP address C1) on the basis of the reference pl contained in the ticket and requests confirmation of this charging data for each ticket received (7). If the confirmation was not received after a certain time (e.g. 1 second), the request (7) is repeated once or twice.
  • the client After receipt of the confirmation request, the client verifies the ticket and, if necessary, sends a confirmation to the proxy (8).
  • the proxy After receiving a confirmation from the client, the proxy saves the ticket for later billing (9) and informs the server that the client has confirmed the ticket.
  • the billing function on the proxy updates the customer's credit balance.
  • the proxy informs the client that the credit has almost been used up. This can be done, for example, with the next request for a ticket (7). If the credit is used up, the proxy will delete the entry in the billing table and the application server will no longer accept further tickets for this customer and negatively acknowledge these tickets to the server, whereupon the server will possibly terminate the service relationship with the client.
  • the proxy informs the application server that a ticket has been negatively acknowledged, and returns the reference sl to the application server. Using the reference sl, the server is then able to terminate the service relationship with the client.
  • the proxy informs the application server that it could not receive a receipt from the client for a ticket, returning the reference sl to the application server. Using the reference sl, the server is then able to terminate the service relationship with the client.
  • Timer tl for billing table entry expires.
  • the proxy monitors the receipt of the tickets from the server. As soon as a ticket (6) arrives, the set timer is reset. When the timer expires, the entry in the table is deleted. Any tickets that subsequently arrive from the server will be negatively acknowledged.
  • this procedure does not require that the server and / or client log off from the proxy when the service relationship is ended. This means that a charge ticket is always sent to the client in advance for the current charging interval. This ensures that the client does not have to pay Uses services without paying for them by simply stopping the service before a charging interval expires to prevent it from being billed for the past interval.
  • the monitoring timer tl in the billing table must in any case be greater than the length of the charging interval that is agreed between the client and the application server. It must be chosen large enough to avoid that a lost (and therefore repeated by the server) ticket message to the proxy causes the proxy to invalidate the billing table entry.
  • tl must not be chosen too large, in order to avoid, for example, that denial-of-service attacks by malicious clients lead to a shortage of the billing table resources and ultimately to the unavailability of these services.
  • a reasonable value for tl is 2-3 times the length of the charging interval. Since the length of the charging intervals of the individual service relationships (see Fig. 1) can be different, the length of the monitoring timer tl is made variable. As soon as the proxy receives a ticket from the server, it uses the length of the charging interval specified therein and uses this to determine the length of tl in order to monitor the receipt of the next ticket from the server for this service relationship.
  • a fixed initial value for this timer is used for the billing table (eg 5 seconds).
  • the conditions for the service relationship are agreed between the client and server. By choosing a short 1st interval and, if necessary, special conditions for it, it can be ensured that even if the service is not provided (e.g. server failure, software error, incompatibility of client and server software) despite the service relationship being established for the Service users experience no or only a slight disadvantage.
  • the application server can possibly cancel the service relationship with the client due to the lack of a receipt on the ticket.
  • - Client functionality can be expanded e.g. at i. Accumulation of the fee messages transmitted by the proxy and display of these fees at the terminal for fee monitoring in real time, i. Possibility for end users to manually reject tickets as an option, e.g. when a certain self-imposed fee limit is reached.
  • the described method allows the operator of a stateless proxy or application broker to offer registered application service providers and registered customers a reliable, accurate and trustworthy billing function at defined intervals in a simple manner by the client and server constantly being in the background during the service provision Notify an independent third party (proxy) about the fees incurred and the billing function is also performed by the independent third party.
  • proxy independent third party

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Das beschriebene Verfahren erlaubt dem Betreiber eines State­less Proxy bzw. Application Brokers auf einfache Art und Wei­se registrierten Application Service Anbietern und regist­rierten Kunden eine zuverlässige, in definierbaren Interval­len genaue und vertrauenswürdige Vergebührungsfunktion anzu­bieten, indem sich während der Diensterbringung Client und Server ständig im Hintergrund in regelmässigen Abständen über einen unabhängigen Dritten (Proxy) über die dafür anfallenden Gebühren verständigen und die Vergebührungsfunktion auch von dem unabhängigen Dritten erbracht wird.

Description

Beschreibung
Verfahren zur Vergebührung eines Dienstes in einem Kommunikationsnetz
Problemstellung der Erfindung
In einem paketorientierten Kommunikationsnetz mit Dienstanwendern (z.B. SIP-Clients) , Diensterbringern (z.B. Applikati- ons-Servern) und einem vermittelnden Applikationsbroker (z.B. 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 Vergebuhrungsfunktion 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 Gesamtrechnung 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 Sicherstellung, daß der Nutzer eines Services auch gleichzeitig Kunde von Proxy- und Serverbetreiber ist, und zum anderen die Übermittlung von Daten an den zentralen Rechnung- sersteiler. Lösung der Problemstellung gemäß der Erfindung
Die Erfindung beschreibt ein Verfahren, wie in einem derartigen 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 Diensten von unterschiedlichsten Partner-Serviceprovidern anzubieten. 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 anbietet) .
Letztendlich ist der Zweck dieses Verfahren, a) Registrierten Endkunden (Clients) mit einem Guthabenkonto in Echtzeit Nutzungsgebühren für angeforderte und genutzte 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 Realzeit 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 Vergebuhrungsfunktion, in die alle Partner-Komponenten (Client, Proxy / Application Broker, Application Server)_ während der Dienstenutzung 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 Tickets den Proxy über Zustandekommen und Verlauf der Servicebeziehung zwischen ihm und dem Client.
Abbildung 1 beschreibt bei einer Realisierungsvariante der Erfindung die Beziehungen der Partner-Komponenten untereinander 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 zusammen mit der Angabe, wo sich der Application Server befindet (Destination) eine Billing-Reference (pl) , die vom Proxy zur Ausübung der Vergebuhrungsfunktion 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 Application 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 Vergebuhrungsfunktion 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 Bestä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- g ng 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 Vergebuhrungsfunktion 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 Anforderung 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 Application Server für diesen Kunden nicht mehr akzeptieren und diese Tickets dem Server negativ quitieren, woraufhin dieser die Servicebeziehung zum Client gegebenenfalls beenden wird.
- Anforderung einer Ticketbestätigung (7) vom Client negativ quitiert : Der Proxy informiert den Application Server, dass ein Ticket 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 Servicebeziehung 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, wobei 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 eintreffende Tickets vom Server werden negativ quittiert.
Bemerkungen :
Zu beachten ist, daß dieses Verfahren nicht erfordert, dass Server und/oder Client sich bei Beendigung der Servicebeziehung 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, indem 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 jeden Fall größer als die Länge des Vergebührungsintervall sein, das zwischen Client und Application Server vereinbart wird. Es muß groß genug gewählt werden, um zu vermeiden, 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 Attacken 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 Servicebeziehungen (siehe Abb. 1) unterschiedlich sein können, wird die Länge des Überwachungstimer tl variabel gestaltet. Sobald 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 Initialwert 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 entsteht. - Bei Ausfall der Vergebuhrungsfunktion des Proxies kann der Application Server aufgrund der ausbleibenden Quittung auf das Ticket die Servicebeziehung zum Client gegebenenfalls abbreche .
- 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 Sonderfä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 Gebühren-Überwachung in Realzeit, i. 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 beschriebene 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 vertrauenswürdige Vergebuhrungsfunktion 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ändigen und die Vergebuhrungsfunktion auch von dem unabhängigen Dritten erbracht wird.
Anwendungsbeispiele der Erfindung
- Auskunftsdienste - Videodienste
- Telefonzusatzdienste, wie z.B. Konferenzen über Konferenzserver
- Mailboxabfragen - anonymes Billing für Gateways, die aus dem offenen Internet angesteuert werden

Claims

Patentansprüche
1. Dienstvermittlungseinrichtung, die a) von einem Client eine Dienstanforderung empfängt, b) daraufhin eine Authentifizierung durchführt und dem Client nach einer erfolgreichen Authentifizierung eine Reference auf einen Application Server zur Durchführung des angeforderten Dienstes mitteilt, c) von dem Application Server erstellte Vergebührungstickets empfängt, wobei die Tickets Informationen hinsichtich der vor bzw. während der Dienstnutzung anfallenden Gebühren enthalten, d) bezüglich eines empfangenen Tickets jeweils eine Bestätigungsanfrage an den Client richtet, e) für das Ticket einer Gebührenregistrierungsaktion durchführt, falls der Client das Ticket bestätigt.
2. Dienstvermittlungseinrichtung nach Anspruch 1 dadurch gekennzeichnet, dass die genannte Gebührenregistrierungsaktion darin besteht, dass die Dienstvermittlungseinrichtung den Guthabenstand oder Gebührenstand des Client aktualisiert.
3. Dienstvermittlungseinrichtung nach Anspruch 1 dadurch gekennzeichnet, dass die genannte Gebührenregistrierungsaktion darin besteht, dass sie das Ticket zu einer späteren Rechungserstellung abspeichert.
4. Dienstvermittlungseinrichtung nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass sie dem Client die für die Gebührenregistrierungsaktion herangezogene Gebühr mitteilt.
5. Application Server, der a) von einem Client eine Dienstanforderung empfängt, wobei die Dienstanforderung eine Reference auf eine Dienstvermittlungseinrichtung enthält, b) bezüglich des Dienstes Vergebührungs-Tickets erstellt und diese an die Dienstvermittlungseinrichtung sendet, wenn er den Service-Request annimmt, wobei die Tickets Informationen hinsichtich der vor bzw. während der Durchführung des Dienstes für den Client fällig werdenden Gebühren enthal- ten, c) von der Dienstvermittlungseinrichtung Mitteilungen darüber empfängt, ob die Tickets durch den Client bestätigt werden, d) die Durchführung des Dienstes aufrechterhält, solange die Tickets durch den Client positiv bestätigt werden.
6. Application Server nach Anspruch 5, dadurch gekennzeichnet, dass er die Servicebeziehung zum Client beendet, wenn er von der Dienstvermittlungseinrichtung die Mitteilung empfängt, dass der Client eine Bestätigungsanfrage bezüglich eines Tickets negativ quittiert hat.
7. Application Server nach Anspruch 5, dadurch gekennzeichnet, dass er die Servicebeziehung zum Client beendet, wenn er von der Dienstvermittlungseinrichtung die Mitteilung empfängt, dass der Client eine Bestätigungsanfrage bzw. mehrere Bestätigungsanfragen bezüglich eines Tickets überhaupt nicht quit- tiert hat.
8. Application Server nach Anspruch 5, dadurch gekennzeichnet, dass er die Servicebeziehung zum Client beendet, wenn er von der Dienstvermittlungseinrichtung überhaupt keine Quittung auf das von ihm generierte Ticket erhält.
9. Application Server nach Anspruch 5, dadurch gekennzeichnet, dass er die Servicebeziehung zum Client beendet, wenn er von der Dienstvermittlungseinrichtung im Falle eines Prepaid- Nutzers bezüglich eines Tickets die Mitteilung erhält, dass kein ausreichendes Guthaben mehr vorhanden ist.
10. Client, der a) an eine Dienstvermittlungseinrichtung eine Dienstanforde- rung stellt, b) nach einer erfolgreichen Authentifizierung der Dienstanforderung von der Dienstvermittlungseinrichtung eine Reference auf den angeforderten Dienst empfängt, c) anhand der genannten Reference eine Servicebeziehung zu einem Application Server des angeforderten Dienstes aufbaut, d) von der Dienstvermittlungseinrichtung Bestätigungsanfragen bezüglich des Dienstes fällig werdender Gebühren empfängt, e) die genannten Bestätigungsanfragen gegenüber der Dienst- Vermittlungseinrichtung verifiziert und beanwortet .
11. Client nach Anspruch 10, dadurch gekennzeichnet, dass er die von der Dienstvermittlungseinrichtung mithilfe der Bestätigungsanfragen übermittelten Gebührennachrichten kumuliert und diese Gebühren dem Endnutzer zur Gebührenüberwachung in Realzeit anzeigt.
12. Client nach Anspruch 10 oder 11, dadurch gekennzeichnet, dass er es dem Endbenutzer erlaubt, eine Gebührennachricht manuell zu beantworten.
13. Verfahren zur Vergebührung eines Dienstes in einem Kommu- nikationsnetz, demgemäß f) von einem Client an eine Dienstvermittlungseinrichtung eine Dienstanforderung gestellt wird, g) daraufhin mithilfe der Dienstvermittlungseinrichtung eine Authentifizierung durchgeführt wird, wobei dem Client von der Dienstvermittlungseinrichtung nach einer erfolgreichen Authentifizierung eine Dienst-Reference auf den angefor- derten Dienst mitgeteilt wird, h) von dem Client anhand der genannten Dienst-Reference eine Servicebeziehung zu einem Application Server des angeforderten Dienstes aufgebaut wird, i) von dem Client dem Application Server eine Reference auf die Dienstvermittlungseinrichtung mitgeteilt wird, j ) von dem Application Server Tickets erstellt und an die Dienstvermittlungseinrichtung gesendet werden, wobei die Tickets Informationen hinsichtlich der vor bzw. während der Dienstnutzung anfallenden Gebühren enthalten, k) von der Dienstvermittlungseinrichtung bezüglich eines Tickets eine Bestätigungsanfrage an den Client gerichtet wird,
1) falls das Ticket bestätigt wird, von der Dienstvermittlungseinrichtung das Ticket zu einer Gebührenregistrie- rungsaktion herangezogen wird.
14. Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass a) das Ergebnis der Bestätigungsanfrage von der Dienstvermittlungseinrichtung an den Application Server weitergeleitet wird, b) die Durchführung des Dienstes seitens des Application Servers aufrechterhalten wird, solange die Tickets durch den Client positiv bestätigt werden.
EP04804651A 2003-12-19 2004-12-02 Verfahren zur vergeb hrung eines dienstes in einem kommunika tionsnetz Ceased EP1695300A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP04804651A EP1695300A1 (de) 2003-12-19 2004-12-02 Verfahren zur vergeb hrung eines dienstes in einem kommunika tionsnetz

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP03029455A EP1544815A1 (de) 2003-12-19 2003-12-19 Verfahren zur Vergebührung eines Dienstes in einem Kommunikationsnetz
PCT/EP2004/053226 WO2005062264A1 (de) 2003-12-19 2004-12-02 Verfahren zur vergebührung eines dienstes in einem kommunikationsnetz
EP04804651A EP1695300A1 (de) 2003-12-19 2004-12-02 Verfahren zur vergeb hrung eines dienstes in einem kommunika tionsnetz

Publications (1)

Publication Number Publication Date
EP1695300A1 true EP1695300A1 (de) 2006-08-30

Family

ID=34486275

Family Applications (2)

Application Number Title Priority Date Filing Date
EP03029455A Withdrawn EP1544815A1 (de) 2003-12-19 2003-12-19 Verfahren zur Vergebührung eines Dienstes in einem Kommunikationsnetz
EP04804651A Ceased EP1695300A1 (de) 2003-12-19 2004-12-02 Verfahren zur vergeb hrung eines dienstes in einem kommunika tionsnetz

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP03029455A Withdrawn EP1544815A1 (de) 2003-12-19 2003-12-19 Verfahren zur Vergebührung eines Dienstes in einem Kommunikationsnetz

Country Status (4)

Country Link
US (1) US20080306747A1 (de)
EP (2) EP1544815A1 (de)
CN (1) CN1898706A (de)
WO (1) WO2005062264A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101562529B (zh) * 2008-04-14 2011-06-01 华为技术有限公司 一种计费处理的方法及装置
CN101860835B (zh) * 2009-04-13 2013-07-31 中国联合网络通信集团有限公司 增值业务付费方法及增值业务付费系统
CN102111742B (zh) * 2011-02-22 2014-04-16 中国联合网络通信集团有限公司 分组域业务计费方法及系统

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10025565A1 (de) * 2000-03-01 2001-09-06 Siemens Ag Anordnung und Verfahren zur Bestätigung eines Kreditkarten-Zahlungsvorgangs über ein Mobilfunknetz
US6529593B2 (en) * 2000-12-21 2003-03-04 At&T Wireless Services, Inc. Prepaid phone service for both wired and wireless telecommunication devices
US20020165783A1 (en) * 2001-05-02 2002-11-07 Jean-Charles Gonthier Accounting in peer-to-peer data communication networks
EP1349359A1 (de) * 2002-03-27 2003-10-01 Siemens Aktiengesellschaft Verfahren zum Vergebühren einer Kommunikationsverbindung zwischen Kommunikationsendgeräten
EP1361550A1 (de) * 2002-05-07 2003-11-12 Siemens Aktiengesellschaft Verfahren zur Vergebührung von Internet-Diensten

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005062264A1 *

Also Published As

Publication number Publication date
EP1544815A1 (de) 2005-06-22
WO2005062264A1 (de) 2005-07-07
CN1898706A (zh) 2007-01-17
US20080306747A1 (en) 2008-12-11

Similar Documents

Publication Publication Date Title
DE69933130T2 (de) Abrechnung in einem Kommunikationsnetz
DE60301196T2 (de) System und verfahren zur vergebührung basierend auf der übermittelten verkehrslast in einem paketorientierten telekommunikationsnetzwerk
DE60314673T2 (de) Mittel und verfahren zur steuerung der dienstprogression zwischen verschiedenen domänen
DE69917447T2 (de) System zur unterstüztung der bereitstellung von diensten
EP1278383A2 (de) Verfahren, Vorrichtungen und Software-Programme zur Nachrichtenübermittlung zwischen Telekommunikations-Netzwerkelementen
DE60204680T2 (de) Verfahren zur erzeugung von abrechnungsdaten in einem datennetzwerk und datennetzwerk
WO2002093513A2 (de) Verfahren zum abrechnen von in einem rechnernetzwerk bereitgestellten diensten
DE602005006094T2 (de) Verarbeitungsverfahren auf der basis eines charging-trigger-ereignisses und eines neuauthorisationsereignisses eines paketdatenflusses
EP1347620B1 (de) Abrechnung einer kostenpflichtigen Nutzung von im Internet bereitgestellten Daten durch ein Mobilfunkendgerät
EP1503538B1 (de) Verfahren zum Ermitteln eines Abrechnungstarifs für eine Datenübertragung
EP1503539B1 (de) Verfahren zum Ermitteln eines Abrechnungstarifs zum Abrechnen einer Datenübertragung
EP1065838A2 (de) Prepaid-Service für mobile Paketdatennetze
DE602004012872T2 (de) System und verfahren zur implementierung einer vorausbezahlung für datendienste
WO2005062264A1 (de) Verfahren zur vergebührung eines dienstes in einem kommunikationsnetz
DE69930537T2 (de) Verfahren und System zur Identifizierung und Angebührung eines mit einem Dienst verknüpften Teilnehmers in einem Kommunikationssystem
EP1488627B1 (de) Verfahren zum vergebühren einer kommunikationsverbindung zwi schen kommunikationsendger ten
WO2005062265A1 (de) Verfahren zur vergebührung eines dienstes in einem kommunikationsnetz
DE60205080T2 (de) Verfahren zur Planung der Dateifernübertragung für drahtlose Netzwerke
EP1302917A2 (de) Verfahren und Anordnung zur elektronischen Bezahlung einer Ware oder Dienstleistung, insbesondere einer Applikation in einem Datennetz
EP1881688A1 (de) Verfahren zum Auswählen eines Kontos für eine Abrechnung eines mittels eines Kommunikationsnetzes angebotenen Dienstes
WO2007124974A1 (de) Verfahren und server zur verwaltung von teilnehmergebühren
EP1522202B1 (de) Erstellen von dienstevereinbarungen zur nutzung netzinterner funktionen von telekommunikationsnetzen
EP1246429B1 (de) Verfahren zur Unterstützung der Übermittlung von Informationen über ein Kommunikationssystem
EP1582027B1 (de) Verfahren zum zugreifen auf ein zahlungssystem
EP1300794A2 (de) Kontroll-Server zur Unterstützung der Vergebührung von Diensten

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060529

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE ES GB

17Q First examination report despatched

Effective date: 20070123

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE ES GB

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS S.P.A.

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20080428