DE60217471T2

DE60217471T2 - Verfahren zur verfügungstellung von vermittlungsdiensten

Info

Publication number: DE60217471T2
Application number: DE60217471T
Authority: DE
Inventors: Lothar Reith; Marian Putala
Original assignee: Nortel Networks Ltd
Current assignee: Nortel Networks Ltd
Priority date: 2001-03-22
Filing date: 2002-03-13
Publication date: 2007-11-29
Anticipated expiration: 2022-03-14
Also published as: DE60217471D1; DE60116405D1; WO2002078316A3; AU2002249268A1; US20040102182A1; WO2002078316A2; EP1371220B1; EP1246445A1; EP1371220A2; DE60116405T2; ATE315309T1; EP1246445B1

Description

Hintergrund der Erfindung
Die Erfindung bezieht sich auf ein Verfahren für die Bereitstellung von Telekommunikationsdiensten, wobei Nutzer authentifiziert und zu einem ersten Dienstprofil autorisiert werden bevor eine Nutzersitzung mit einer Netzdienstvermittlungsanlage beginnt.
Insbesondere bezieht sich die Erfindung auf eine Methode zur Bereitstellung von Telekommunikationsdiensten an authentifizierte Nutzer mit flexiblen Abrechnungsoptionen wie zum Beispiel Abrechnung bei Vorauszahlung oder bei Zahlung im Nachhinein, Abrechnung in Echtzeit, nahezu in Echtzeit oder nicht in Echtzeit. Das Verfahren ist anwendbar auf alle Telekommunikationsdienste, bei denen Nutzer durch eine Nutzerkennung oder irgendeine andere einzigartige Identifikation identifiziert werden vor Beginn einer Nutzersitzung mit einer Netzdienstvermittlungsanlage dergestalt, dass es ermöglicht wird, eine Rechnung an den Besitzer (Vertragsnehmer) der Nutzerkennung zu präsentieren, die der Vertragsnehmer unter normalen Umständen verpflichtet ist zu bezahlen (kein Abstreiten).
Die Folgenden sind Beispiele von Nutzerkennungen, auf die das Verfahren anwendbar ist:

1) „Nutzername" – in RADIUS Accounting Start Request und RADIUS Accounting Stop Requests von Internet Protokoll (IP) Einwahldiensten und anderen Internet Zugangsdiensten, welche das Einwahl-Paradigma nutzen, einschließlich Ethernet-Zugang gemäß dem IEEE 8022.1x Standard und gemäß der Ethernet UNI Dienst-Definitionen. Es sollte vermerkt werden, dass für die Authentifizierung ein zusätzliches Authentifizierungs-Token wie ein Passwort benötigt wird wenn die Authentifzierung mittels des Standard RADIUS Protokolls er folgt (RADIUS = Remote Authentification Dial-in User Service).
2) „IMSI" – International Mobile Subscriber Identification. Es sollte vermerkt sein, dass die Bereitstellung einer „IMSI" durch ein Mobilfunknetz impliziert, dass der Nutzer bereits erfolgreich im Voraus authentifiziert wurde, weshalb kein separates Passwort oder Authentifizierungstoken erforderlich ist.
3) „CLID" Identifikation des rufenden Anschlusses im öffentlichen Fernsprechnetz identifiziert wer den Telefonanruf oder die Einwahl zu einer Online Sitzung verursacht hat. Wiederum wurde die CLID bereits im Voraus authentifiziert und ihre Präsenz in einem Rufaufbauversuch (wie etwa einer SS7 IAM Initial Address Message) ist daher allein ausreichend für die Authentifizierung des Nutzers.

Wenn Aufsummieren oder Abrechnung angewendet wird, dann kann eine „Nutzungssitzung" wie folgt definiert werden: Die Sitzung beginnt, wenn das Abrechnungssystem informiert wird durch ein Netzelement, dass Aufsummierung (und damit Echtzeit-Abrechnung) für diesen Nutzer mit sofortiger Wirkung wirksam werden soll (z.B. via eines RADIUS Accounting, etwa Start Request, der zu einem externen RADIUS Server oder zu einer Aufsummierungs-Logik gesandt wird. Oder durch Erzeugen eines oder mehrerer Vorausbezahlt-Konten oder Kreditzählern innerhalb der Netzdienstvermittlungsanlage). Andererseits, wenn das Netzelement einen akkuraten Zeitstempel zur Verfügung stellt, dann beginnt die Sitzung zu dem durch den Zeitstempel angegebenen Zeitpunkt. Natürlich werden Online-Sitzungen abgedeckt, bei denen ein Nutzer oder ein Gerät für die Dauer der Online Sitzung eine IP-Adresse erhält oder einen Teil einer IP Adresse (bei Nutzung von Netzadressübersetzung), die es dem Nutzer erlaubt erreichbar zu sein von anderen IP Adressen.
Ebenfalls eingeschlossen sind Ethernet Sitzungen, die es einem Nutzer oder Gerät erlauben, über eine Ethernet LAN zu kommunizieren unter Nutzung einer bestimmten MAC Adresse – optional nachdem der Nutzer oder das Gerät erfolgreich authentifiziert wurde gemäß dem 802.1x Standard. Darüber hinaus kann eine Sitzung betrachtet werden als ein volles Ethernet Segment oder ein VLAN wenn ein Ethernet VPN Dienste oder Ethernet UNI Dienste angeboten werden mit Echtzeit-Abrechnung, wie implementiert in den Produkten des Antragstellers OPTera Metro 1200 oder OPTera Metro 8000.
Wenn ein Nutzer einen Vertrag über einen Telekommunikationsdienst abschließt, wird eine Nutzerkennung zugeordnet und eine Nutzerdatensatz wird gespeichert in einer Nutzerdatenbank, die es dem Diensteanbieter erlaubt, Daten zu speichern für die Erstellung der Rechnung und diese Daten für Abrechnungszwecke wieder aufzufinden unter Verwendung der Nutzerkennung als Schlüssel für den effizienten Zugang zur Datenbank.
Das Netzelement, welches den „Accounting Start Request" zu Beginn der Sitzung und den „Accounting Stop Request" am Ende der Sitzung originiert, wird als Netzdienstvermittlungsanlage (NDV) bezeichnet. Die NDV sendet einen Accounting Start Request nachdem der Nutzer erfolgreich authentifiziert wurde und mit einem (ersten) Serviceprofil autorisiert wurde. Die NDV stellt den Teilnehmerrand eines IP Netzes oder Ethernet UNI Service dar, zum Beispiel (UNI = User to Network Interface bzw. Nutzer zu Netz Schnittstelle) und setzt die Dienstrichtlinie durch, die der Nutzer vertraglich angenommen hat. Zugang zur NDV kann erreicht werden durch unterschiedliche Telekommunikationssysteme, entweder über drahtlose Zugangsnetze (wie z.B. UMTS, GPRS, GSM, CDMA, Wireless LAN, Satelit, usw) oder über drahtgebundene Netze (wie z.B. xDSL, ATM, Kabelnetze, Frame Relay Netze, IP basierte Zugangsnetze, Frame Realy, Mietleitung (PDH oder SDH) Glasfasernetze, Ethernet Netze, oder das öffentliche Telefonnetz über Einwahlverfahren). Im Falle, dass das Zugangsnetz bereits IP basiert ist, können standardisierte Tunnelverfahren genutzt werden wie zum Beispiel L2TP (Layer 2 Tunneling Protokoll) oder PPP über Ethernet, oder GTP in UMTS oder GPRS Netzen, um den Teilnehmerrand zur NDV zu verlegen.
Während der Authentifizierung des Nutzers sendet der Nutzer seine Nutzerkennung und optional zusätzlich ein Authentifizierungstoken wie zum Beispiel ein Passwort zur NDV. Im Falle, dass der Nutzer zuvor bereits im Zugangsnetz authentifiziert wurde, (welches zum gleichen oder zu einem anderen Netzbetreiber gehören kann), kann es hinreichend für die Authentifizierung sein, dass der Nutzer oder der andere Diensteanbieter seine Nutzerkennung überträgt). Dies würde im Normalfall ausreichen, wenn das Zugangsnetz zu dem selben Diensteanbieter gehört, oder wenn ein Inkasso-Abkommen besteht zwischen den Diensteanbietern, welches es dem Diensteanbieter erlaubt, über den Diensteanbieter des Zugangsnetzes abzurechnen.
Die NDV kann eine Richtlinie haben nach der Nutzer mit einer bereits zuvor authentisierten Nutzerkennung stets erfolgreich authentifiziert werden. Zum Beispiel ist dies oft der Fall in Telefonnetzen, die einen sogenannten Offenes Call by Call Dienst anbieten wie verfügbar in Deutschland.
Alternativ kann die NDV eine Richtlinie haben, nicht stets erfolgreich zu authentifizieren, sondern den Nutzer nur dann zu authentifizieren, wenn zusätzlich ein Authentifizierungstoken bereitgestellt wird wie zum Beispiel ein Passwort oder eines der anderen unten aufgezählten Beispiele, die überprüft werden können anhand einer lokalen oder entfernten Datenbank, und der Nutzer wird nur dann erfolgreich authentifiziert, wenn die bereitgestellten Nutzerkennung und Authentifizierungstoken übereinstimmen (oder im Falle von auf biometrischen Daten basierenden Authentifizierungstoken hinreichend genug) mit Datenbankeinträgen für die Nutzerkennung und einem zugeordneten Authentifizierungstoken (wie z.B. Passwort, Secure-ID, biometrischer Information zur Nutzeridentifikation, wie z.B. die Iris Struktur der Augen des Nutzers, Daten über Fingerabdrücke des Nutzers, Daten über Sprach-Charakteristika des Nutzers für automatische Sprechererkennung usw.).
In herkömmlichen Telekommunikationsnetzen war die Nutzerdatenbank oft lokal in der NDV – so wie im Falle, dass die NDV eine traditionelle Sprachvermittlungsanlage ist. In modernen Telekommunikationsnetzen wird die Nutzerdatenbank oft zentral gehalten und nicht lokal in der NDV. Daher involviert die Nutzerauthentifizierung eine Kommunikation mit einer entfernten Datenbank. Diese Kommunikation kann auf Standardprotokollen basieren, wie als wichtigstem dem RADIUS Protokoll (Remote Access Dial In User Service), welches von der IETF (Internet Engineering Task Force) definiert wurde. Während das RADIUS Protokoll den so genannten AAA Prozess (Authentication/Authentifizierung, Authorisation/Autorisierung, Accounting/Nutzungsdatenerfassung und Sammlung für Abrechnungs- und andere Zwecke) zwischen einem RADIUS Client (der NDV) und einem RADIUS Server (der Anwendung, die Zugriff auf die Nutzerdatenbank hat) gut definiert, stellt es keine Mittel zur Verfügung, um eine Re-Autorisierung mit einem neuen Diensteprofil während einer Sitzung aufzurufen. Bis vor kurzem gab es noch nicht einmal einen weg, eine Verbindung auszulösen durch Initiative der Datenbank, erst vor kurzem wurde eine Funktion hinzugefügt für einen „RADIUS Disconnect Request", der es erlaubt, flexiblere Prepaid Lösungen zu implementieren.
Ein Beispiel einer NDV ist insbesondere beim Anbieten von IP Diensten der „Shasta 5000 BSN" der Antragstellerin (BSN steht für Breitband Dienst Knoten). Der BSN ist entworfen um platziert zu sein an der „Teilnehmerkante" eines Diensteanbieters mit IP Diensteangebot, am strategischen Punkt, wo der Teilnehmer auf das IP Netz des Diensteanbieters trifft. Auf dem BSN können IP-Dienste eingerichtet und durchgesetzt werden auf Basis pro Teilnehmer.
Ebenfalls können Dienstprofile definiert werden für individuelle Nutzer oder Klassen von Nutzern, die einem Nutzer zugewiesen werden nach erfolgreicher Authentifizierung während einer so genannten Autorisierung. Vor dieser Erfindung waren Diensteprofile stets statisch während einer Nutzersitzung eines authentifizierten Nutzers. Es gab Anwendungen für den Wechsel des Dienstprofils von einem initialen Standardprofil im Zusammenhang mit der kostengünstigen Aufstellung von DSL Diensten. Dieses Leistungsmerkmal kann genutzt werden für die Selbst-Einrichtung im Zusammenhang mit dem initialen Dienste Abonnement von DSL-Kunden (wenn sie zum ersten Mal das in einem Geschäft gekaufte DSL Modem verbinden). Dies wird erreicht durch die Fähigkeit der NDV ein Dienstprofil durchzusetzen, das jedweden Verkehr außer HTTP Verkehr zu einer bestimmten IP Adresse, die den Server für die anfängliche Einzeichnung des bisher unauthentifizierten Nutzers repräsentiert. Sobald der Nutzer genügend Information geliefert hat, die erlaubt, ihn in diesem Moment zu authentifizieren (die dann in einer Nutzerdatenbank gespeichert wird für künftige Authentifizierungen), wird der zum ersten Mal authorisiert mit einem vom Nutzer ausgewählten Dienstprofil.
Es ist deshalb wichtig festzuhalten, dass kein Diensteanbieter vor dieser Erfindung jemals einen authentisierten Nutzer re-authorisiert hat mit einem unterschiedlichen Dienstprofil, insbesondere nicht im Bereich IP Dienste, oder, allgemeiner, packetvermittelten Netzdienste wie zum Beispiel Ethernet Dienst, ATM Dienste, und Frame Relay Dienste, „Voice over IP" SIP usw, und insbesondere nicht mit wahrer Echtzeit Abrechnung von volumen-tarifierten Diensten, die differenzierte Volumentarife in Abhängigkeit vom Typ des Pakets einschließen.
Die während der Sitzung geleisteten Dienste werden dem Nutzer in den meisten Fällen auf Zeitbasis in Rechnung gestellt. Dies bedeutet, dass der Geldbetrag mit dem der Nutzer für die Sitzung belastet wird, abhängig ist davon wie lange die Sitzung gedauert hat. Allerdings kann der Preis auch von anderen Kriterien abhängen, zum Beispiel von dem Datenvolumen, das zum Nutzer gesendet wurde während der Sitzung. In jedem Fall gibt es einen oder mehrer Arten von Diensteinheiten (z.B. Zeit und Volumen), die jede ihren Preis in einer passenden Währung hat. In einem im Bezahlsystem für Nachzahlung wird der Wert der verbrauchten Diensteinheiten erfasst in einem Zählkonto, und der Nutzer wird später abgerechnet auf Basis dieses Zählkontos. Demgegenüber sind Bezahlsysteme bei Vorauszahlung bekannt in denen der Nutzer im Voraus mit einem bestimmten Geldbetrag kreditiert wird, der bezahlt werden muss entweder im Voraus oder später, und das Zählkonto des wird dann dekrementiert entsprechend des Wertes der verbrauchten Diensteinheiten. Wenn der Nutzer versäumt sein Zählkonto wieder aufzuladen und das Zählkonto entleert wird, wird der Nutzer vom Netz getrennt oder auf ein anderes Dienstprofil umgeschaltet, wie zum Beispiel zu einem Dienst der den Nutzer so limitiert, dass er nur Zugang hat zum Wiederaufladungs-Server und oder zu Werbeinformationen.
Es ist so zu verstehen, dass der Preis, den der Nutzer zu bezahlen hat, abhängt vom Dienstprofil zu dem der Nutzer abonniert ist. Das Dienstprofil ist definiert durch eine Megne von nutzerspezifischen Dienstparametern die die so genannte Nutzerdienstrichtlinie spezifizieren. Die Nutzerdienstrichtlinie kann eine Reihe von unterschiedlichen Aspekten umfassen, deren wichtigste nachfolgend aufgezählt werden:
Dienstgüterichtlinie:
Die Richtlinie, die die dem Nutzer bereitgestellte Dienstgüte regelt, z.B. in Bezug auf die zur Verfügung gestellte Bandbreite oder die den Daten des Nutzers zugeordnete Priorität (z.B. bezüglich der Einstellungen des Vorrang und Prioritätsfelder im TOS Feld (Diensteart) von IP Paketen um differenzierte Dienste gemäß des DiffServ Standards zu implementieren oder bezüglich einer garantierten Bandbreite, die dem Nutzer verfügbar ist.
Abrechnungsrichtlinie:
Die Richtlinie, die bestimmt, auf welche Weise die Aufsummierung und Abrechnung erfolgt und die unter anderem die kostenpflichtigen Einheiten spezifiziert (z.B. ob Zeit in Minuten oder Sekunden abgerechnet wird), den Bezahlmodus, Vorauszahlung oder Zahlung im Nachhinein, Rechnungsbegrenzung bei Nachzahlung, den anwendbaren Tarif, die Richtlinie zur Rechnungslegung (z.B. in Echtzeit in einem Browser oder nur wenn der Nutzer ein spezielle Webseite aufruft; weiterhin ob nur der aktuelle Tarif angezeigt wird oder auch der aktuelle Stand des vorausbezahlten-Zählkontos oder die aktuelle Summe der Belastungen, z.B. für eine monatliche Rechnung, die Wiederaufladerichtlinie (z.B. ob das Wiederaufladen eines vorausbezahlten Zählkontos mit Kreditkarte möglich ist), usw.
Schutz der Privatsphäre/Zurechnungsfähigkeit:
Die Richtlinie, die einerseits bestimmt das Ausmaß der gesammelten Daten über das Verhalten des Nutzers und die Menge an nutzerspezifischer Information die für Kommunikationspartner einsehbar ist, und andererseits bestimmt das Ausmaß der gesam melten Daten, die es dem Nutzer erlauben, die Richtigkeit einer Rechnung anzufechten. Zum Beispiel kann es vorkommen, dass ein Nutzer nicht will, dass ein Dienstanbieter Informationen über die Art der Pakete sammelt, die er im Auftrag des Nutzers weiterleitet, da dies die Privatsphäre des Nutzers verletzen könnte. Andererseits könnte der Dienstanbieter einen Tarif anwenden wollen, der verschiedene Paketarten mit unterschiedlichen Volumenpreisen belastet (wertbasierte volumenorientierte Abrechnung). Heute gibt es keine Lösung die gleichzeitig die Privatsphärenanforderungen des Nutzers und die kommerziellen Anforderungen des Dienstanbieters zur Einführung wertbasierter Echtzeitabrechnung inklusive für vorausbezahlende Kunden erfüllt. Eine Lösung für dieses Problem ist ein Privatsphärenmodus, der dadurch charakterisiert ist, dass ein Dienstprofil genutzt wird mit einer Vielzahl von Bezahlregeln eines bestimmten Bezahltyps, die angewendet werden auf einen einzigen Kreditzähler des Nutzers. Eine andere Privatsphärenrichtlinie könnte bestimmen inwieweit der Nutzer das Subjekt von Anonymisierungsdiensten des Dienstanbieters ist, wie zum Beispiel das Verbergen der IP Adresse durch Adressübersetzung, das Unterdrücken von Cookies, die Entfernung von html tags die Information über zuvor besuchte Webseiten zur Verfügung stellen usw.
IP-Diensterichtlinie
Die Richtlinie die bestimmt, welche IP Dienste der Nutzer erlaubt ist zu benutzen (zum Beispiel: http für WWW, Sprache über IP, FTP, Telnet, smtp, usw.).
Andere Beispiele beinhalten die Richtung der IP Pakete bestimmten Typs, (abgehende vom Netz zum Nutzer oder eingehende vom Nutzer zum Netz), die Klasse der IP Adresse des Nutzers (ob der Dienstanbieter Information codiert durch den Adressbereich aus dem er die IP Adresse dem Nutzer zuweist, was zum Beispiel erlaubt zu unterscheiden einen GPRS Nutzer, einen UMTS Nutzer und einen Einwahlnutzer mit V.110, wenn terminierend auf der gleichen NDV). Die Richtlinie kann auch unterscheiden nach der IP Adresse des Ziels, die von Dienstprofilen für Kinder für das Filtern von Inhalten genutzt werden kann.
Sicherheitsrichtlinie:
Die Richtlinie, die bestimmt, gegen welche Sicherheitsrisiken der Nutzer durch den Dienstanbieter geschützt ist, z.B. netzwerkbasierte Firewalls und dergleichen oder Verschlüsselung von Nutzerkommunikation.
Inhaltsrichtlinie:
Die Richtlinie, die bestimmt für welche Inhalte und/oder Webseiten dem Nutzer Zugang gestattet ist.
Gewöhnlich sind diese durch das Dienstprofil definierten Richtlinien statisch zumindest im gesamten Verlauf einer Sitzung. Nur im Ausnahmefall eines so genannten Selbsteinrichtungssystems, in dem ein unauthorisierter Nutzer die Möglichkeit hat online zu abonnieren, wird ein neuer Teilnehmer zuerst autorisiert zu einem eingeschränkten Dienstprofil, das erlaubt, nur die notwendigen Daten einzugeben für die Einrichtung des Dienstes. Dann, sobald das Dienstprofil speziert wurde, wird dieses Profil fixiert für die zu beginnende Sitzung und für jedwede künftige Sitzung desselben Nutzers, insbesondere für volumenabhängig abgerechnete Dienste und für voraus bezahlte Dienste, die volumenabhängige Abrechnung einschließen mit mehreren differenzierten Preisen, die vom Pakettyp abhängen.
Zum Beispiel beschreibt US 5,822,411 A ein Telekommunikations-Gebührenberechnungssystem, wobei, wenn eine Verbindung zwischen einem anrufenden Teilnehmer und einem angerufenen Teilnehmer hergestellt wurde, der anrufende und/oder der angerufene Teilnehmer die Möglichkeit hat, eine Anforderung einzugeben, um während der Verbindung das Dienstprofil der Anruferbindung zu wechseln. In diesem Kontext betrifft der Begriff "Dienstprofil" jedoch nur Merkmale der Anruferbindung, wie zum Beispiel Abrechnung für den angerufenen Teilnehmer, die während dieser spezifischen Verbindung gültig sind.
Zusammenfassung der Erfindung:
Es ist ein Ziel der Erfindung ein Verfahren bereitzustellen für die Bereitstellung von Telekommunikationsdiensten, das mehr Flexibilität bietet durch Adaption von Dienstprofilen an die Anforderungen der Nutzer, Dienstanbieter und anderen Teilhabern im Netzwerk.
Gemäß der Erfindung wird dieses Ziel erreicht durch ein Verfahren in dem das Dienstprofil dynamisch variert wird im Verlaufe der Sitzung nach der Logon Prozedur.
Somit kann ein Nutzer, sobald er zu einer Sitzung authentifiziert ist, einfach zu einem anderen Dienstprofil umschalten ohne die gegenwärtige Sitzung beenden zu müssen und eine neue Sitzung aufbauen zu müssen. Im Resultat kann ein und dieselbe Sitzung in eine Vielzahl von Untersitzungen segmentiert werden, für die unterschiedliche Dienstprofile gelten. Der Vorteil für den Nutzer kann durch folgende einfache Beispiele beleuchtet werden:
Man stelle sich vor das der Nutzer eingeloggt hat zu einem relativ billigen oder gar kostenfreien Dienstprofil. Im Verlaufe der Sitzung mit Nutzung dieses Profils gelangt der Nutzer auf eine Webseite wo eine Datei mit einem großen Datenvolumen angeboten wird zum Herunterladen. Da das gegenwärtige Dienstprofil nur eine schwache Dienstgüte bietet, z.B. eine beschränkte Bandbreite und eine geringe Priorität für die Übertragung von Datenpaketen, würde der Prozess des Herunterladens unvernünftig viel Zeit benötigen. Jetzt kann der Nutzer einfach ein Kommando eingeben um das Dienstprofil zu einem teueren Profil aufzubessern, dass indes eine signifikant höhere Dienstgüte bietet, so dass der Herunterladeprozess beschleunigt wird. Danach könnte der Nutzer wieder zum billigeren Modus zurückkehren um das Surfen im Internet fortzusetzen.
Andererseits ist es nicht nur der Nutzer sondern auch der Dienstanbieter, welcher die Initiative ergreifen könnte um das Dienstprofil zu ändern. Der Dienstanbieter könnte kann dieses Leistungsmerkmal unter anderem für das Anbieten von Diensten nutzen, die zumindest teilweise durch effizientere Werbung finanziert werden.
Heute erscheint die Werbung im Internet hauptsächlich in der Form von Bannern, die nur einen kleinen Teil der sichtbaren Webseite auf einem Bildschirm belegen. Allerdings, da die Nutzer dazu tendieren, die Werbebanner zu ignorieren und sich auf die Hauptinhalte der Webseiten zu fokussieren oder schnell zu einer anderen Webseite zu klicken, ist diese Art der Werbung signifikant weniger effizient als zum Beispiel Werbung im kostenlos empfangbaren Fernsehkanälen, wo das reguläre Programm durch Werbespots unterbrochen wird, so dass der Zuschauer gezwungen ist die Werbespots anzuschauen, und seine Aufmerksamkeit nicht abgelenkt wird durch andere Inhalte. Die Erfindung bietet ein Hilfsmittel mit dem dieses Werbemodell einfach im Internet implementiert werden kann. Zu diesem Zweck ist ein Werbeblock bestehend aus einer im Voraus bestimmten Folge von den Bildschirm teilweise oder ganz füllender Werbung und/oder multimedialer Werbespots definiert als ein spezifisches Dienstprofil zur Steuerung des gesamten Werbeblocks, oder eine vordefinierte Folge von Dienstprofilen wobei die Abfolge dynamisch adaptiert werden kann. Wenn der Nutzer mit seinem vorhergehenden oder Standard Dienstprofil für eine bestimmte Zeit gearbeitet hat, schaltet der Internet Dienstanbieter zwangsweise in das Dienstprofil „Werbeblock", so dass der Nutzer gezwungen ist, Werbung anzuschauen bevor er mit seinem eigenen Dienstprofil fortfahren kann. Das Profil „Werbeblock" könnte auch interaktive Elemente enthalten, die es dem Nutzer erlauben, Werbung zu einem speziellen Thema auszuwählen, an dem er besonders interessiert ist. Dies ist vorteilhaft für den Werbenden, da in diesem Fall der potentielle Klient zielgenauer erreicht werden kann. Um dem Nutzer einen zusätzlichen Anreiz zu geben sich mit der Werbung zu befassen, könnte der Werbeblock auch Spiele enthalten, Preiswettbewerbe und ähnliches. Überdies könnte das Dienstprofil eine Verlinkung erlauben zu den Webseiten der Firmen, zu deren Vorteil die Werbung, so dass der Nutzer direkt auf die Werbung antworten könnte und die entsprechenden Waren und Dienstleitungen bestellen könnte.
Es versteht sich dass das Merkmal, ob ein vom Nutzer ausgewähltes Dienstprofil von einem Werbeblock unterbrochen werden kann, selbst wiederum ein Leistungsmerkmal ist, das Dienstprofile von einander unterscheidet. Demnach könnte der Nutzer ein Dienstprofil auswählen, welches relativ preisgünstig ist, das aber von Zeit zu Zeit von Werbeblöcken unterbrochen wird, und – wenn er über die Werbeblöcke verärgert wird – kann er noch in der gleichen Sitzung das Umschalten wählen zu einem teureren Dienstprofil, in dem keine Werbeblöcke zugelassen sind, oder regelmäßig eingefügt werden mit einer reduzierten Frequenz Das Einblenden von Werbung könnte bestimmt werden durch Dienstprofile, die den Nutzer auf Werbeinhalte beschränken. Alternativ kann Werbeeinblendung erreicht werden durch das Einfügen zusätzlicher Pakete gleichen Typs mit Werbung am Anfang, in der Mitte und am Ende eines Paketstroms, wie etwa HTML Pakete für ein Pop-up-Fenster, VoIP Pakete mit Sprachwerbung, WAP Pakete mit WAP Werbung, usw. Eine externe Werbeeinfügungsanwendung könnte die Werbeeinblendung steuern und kann ausgelöst werden bei Ankunft eines ersten Paketes eines betreffenden Typs, nach einem Zeitraum während dessen betreffende Pakete weitergeleitet werden ohne Auslösen der Werbeeinblendungsanwendung. Die Periode des werbefreien Bereitstellens der Diensteinheiten könnte eine feste Mindestlänge haben oder könnte bestimmt werden durch eine Anzahl von werbefreien Diensteinheiten (wie etwa Bytes) die bereitgestellt werden bevor der Auslöser erneut aufgerufen wird mit der nächsten Einheit die dem Nutzer bereitgestellt wird (Zeit oder Paket).
Bei Verwendung eines einzigen credit_counter-Objekts und mehrerer differenzierter Tarife pro Diensteinheit, die von dem Typ des Pakets abhängen können, kann die Periode ohne Werbungseinfügung der Sitzung sehr flexibel definiert werden, wobei eine Mischung von Zeit- und verschiedenen Pakettypgewichten honoriert wird. Der Auslöser wird durch eine Aktion ausgegeben, die mit einer Echtzeit-Abrechnungsschwelle assoziiert ist. Es kann eine lokale Bezahlungsquellenanwendung (lokal für die NDV) verwendet werden, um Pseudobezahlungen zu produzieren, die das Verhalten des lokalen Bezahlungstyps regeln (der Pseudobezahlungen von Guthaben verwendet, die außerhalb der NDV keinen kommerziellen Wert darstellen, wie zum Beispiel mit verschiedenen Pakettypen assoziierte künstliche Paketgewichte oder eine Kreditwährung von Sekunden, mit der die werbefreie Periode beendet werden kann, wenn der durch einen credit_counter repräsentierte "Pseudo-Timer", der Sekunden als Währung in dem Bezahlungstyp verwendet, ausgeschöpft wird oder eine Schwellenbedingung erfüllt.
Die Einfügung von Werbung durch den Dienstanbieter kann auch durch eine Echtzeit-Abrechnung mit einem Echtbezahlungstyp gesteuert werden, so dass der Werber im Austausch für Diensteinheiten (Zeit oder Pakete), die mit dem Werbeinhalt assoziiert sind, Bezahlungen zu einem Konto des Nutzers und/oder einem Konto des Dienstanbieters transferiert.
Im Fall eines auf Zeitbasis abgerechneten Profils kann der Nutzer Werbeblöcke akzeptabler finden, wenn der Werbeblock als ein kostenloses Profil konfiguriert ist, und eine entsprechende Nachricht auf dem Bildschirm kann dem Nutzer mitteilen, dass ihm für die Zeit, in der er die Werbeblöcke anschaut, nichts berechnet wird. Der Nutzer kann sogar für das Anschauen der Werbung belohnt werden, indem in dem Dienstprofil "Werbeblock" spezifiziert wird, dass das Prepaid-Konto des Nutzers für jede Minute oder Sekunde, in der er die Werbung anschaut, nicht dekrementiert, sondern statt dessen inkrementiert wird. Dann kann es auch vorteilhaft sein, wenn der Nutzer die Möglichkeit hat, freiwillig zu einem "Werbeblock"-Profil zu wechseln, um sein Konto zu vergrößern oder Guthaben eines anderen payment_type, wie zum Beispiel Bonuspunkte in einem Kundenloyalitätssystem, zu verdienen. Bei Verwendung eines Dienstprofils, das wenigstens eine Bezahlungsregel mit einem Tarif eines Bezahlungstyps, der loyalty_bonus als Guthabenwährung verwendet, kann der Kunde kann die Gelegenheit haben, Guthaben wie etwa Loyalitäts-Bonuspunkte zu verdienen und auszugeben. Negative Tarife führen zu einem Verdienst von Bonus-Meilen, während positive Tarife zu Prepaid-Abrechnungsarten führen. Diensteinheiten, die mit einer Bezahlungsregel assoziiert sind, die einen negativen Tarif aufweist, führen dazu, dass der Nutzer Guthaben (wie zum Beispiel Loyalitäts-Bonuspunkte) verdient, während positive Tarife zu einem "Ausgeben" von Guthaben führen. Bei Verwendung eines Dienstprofils, das Bezahlungsregeln enthält, die sowohl positive als auch negative Tarife derselben Bezahlungstypen enthalten, kann Guthaben gleichzeitig verdient und ausgegeben werden.
In einem bestehenden Netzwerksystem kann das erfindungsgemäße Verfahren implementiert werden, indem man im Namen des Dienstanbieters ein als Sitzungsmanageranwendung (SMA) bezeichnetes Softwareelement installiert, das die Authentifikations- und Autorisierungssoftware, die Nutzerdatenbank und die die Auswahl vorkonfigurierter Dienstprofile oder die dynamische Bereitstellung von Dienstprofilen in den Netzdienstvermittlungsanlagen steuernde Software verknüpft. Wenn der Wechsel von einem Dienstprofil zu einem anderen vom Nutzer eingeleitet werden kann, enthält das System auch ein "Inhalts- und Richtlinienauswahlportal" (PSP) zum Behandeln der Nutzeranweisungen, durch die das Dienstprofil gewechselt wird.
Als Alternative kann eine Schnittstellen-Softwareanwendung von "Unternehmen zu Teilnehmer" (B2S) verwendet werden, um einen Wechsel von einem Dienstprofil zu einem anderen einzuleiten. Die B2S-Schnittstelle kann direkt an ein Nutzerendgerät ankoppeln, das eine physische Steuerfähigkeit aufweist, wie zum Beispiel eine Schaltfläche auf einem mobilen Handapparat, die betätigt werden kann, um einen Wechsel zu einem spezifischen Dienstprofil aufzurufen, oder mehrere Schaltflächen, die mit spezifischen Dienstprofilen assoziiert sind. Diese Schaltflächen können vom Hersteller und vom Dienstanbieter vorkonfiguriert oder abhängig von individuellen Nutzerpräferenzen softwarekonfiguriert werden. Als Alternative kann die B2S an eine Software ankoppeln, die auf einem vom Nutzer verwendeten Endgerät abläuft, wie etwa ein Browser auf einem PC, ein Micro-Browser auf einem mobilen in der Hand gehaltenen Gerät, ein Telefon mit einem softwaregesteuerten Display usw. Allen diesen Alternativen ist gemeinsam, dass der Nutzer eine Richtlinienänderung über Ankopplung an die B2S-Anwendung oder das PSP einleiten kann, die bzw. das die Nutzerdatenbank manipuliert, um die SMA über den angeforderten Wechsel zu informieren. Diese Anwendungen können direkt an die SMA ankoppeln, oder über die Nutzerdatenbank. Änderungen an der Datenbank wirken sich auf den Nutzerdatensatz des einen Dienstrichtlinienwechsel anfordernden Nutzers aus. Die B2S-Anwendung und auch die PSP-Anwendung fügen außerdem den Nutzernamen zu einer speziellen verketteten Liste von Nutzernamen hinzu, die einen Richtlinienwechsel angefordert haben, falls über die Nutzerdatenbank angekoppelt wird. Die SMA prüft diese Liste (oder die anwendungsspezifischen Listen regelmäßig in sehr kurzen Intervallen, um sicherzustellen, dass der von den Nutzern angeforderte Richtlinienwechsel nahezu in Echtzeit implementiert wird.
Da der Wechsel von einem Dienstprofil zu einem anderen, ob durch den Nutzer oder durch den Dienstanbieter eingeleitet, in den meisten Fällen die Verrechnung beeinflusst (oder mindestens den betreffenden Tarif bzw. die betreffenden Tarife), wird das erfindungsgemäße Verfahren vorzugsweise mit einem flexiblen und effizienten Verrechnungsverfahren kombiniert. Bei einer bevorzugten Ausführungsform basiert dieses Verrechnungsverfahren auf einem Prepaid-System, bei dem ein Prepaid- Konto des Nutzers entsprechend den verbrauchten Diensteinheiten dekrementiert wird. In dieser Hinsicht bedeutet der Begriff "Prepaid-Konto" jedoch nicht unbedingt, dass der für das Belasten des Prepaid-Kontos zu zahlende Betrag tatsächlich im Voraus gezahlt werden muss.
Gemäß einer vorteilhaften Ausführungsform enthalten die Datensätze in der Nutzerdatenbank für jedes Prepaid-Konto eines Nutzers ein oder mehrere Felder "Prepaid-Konto-Dekrementierer" (Tarife), die in beliebigen geeigneten Einheiten den Betrag angeben, um den das Prepaid-Konto für jede Diensteinheit dekrementiert wird, z.B. für jede Minute oder Sekunde, die die Sitzung dauerte, oder für jedes in einem empfangenen Paket eines bestimmten Typs enthaltene Byte. Bei Verwendung von Zeittarifen ist der gerade geltende Tarif deshalb gleich der Anzahl der Echtzeit-Verrechnungseinheiten, die am Anfang jedes Verrechnungsschrittintervalls dekrementiert werden. Bei Verwendung von Volumentarifen gibt der für bestimmte Pakettypen geltende aktuelle Tarif die Anzahl der Verrechnungseinheiten an, um die das Prepaid-Konto des Nutzers dekrementiert (oder inkrementiert) werden soll. Wenn mehrere Prepaid-Konto oder mehrere verschiedene Tarife pro Pakettyp verwendet werden, differenziert man sie nach dem Typ des Prepaid-Kontos (credit_counter) und dem Typ des Tarifs. Dieser Typ kann auch als payment_type oder ptype bezeichnet werden, da er auch den verwendeten Typ der Verrechnungseinheiten und die Bezahlungsquelle für diese Verrechnungseinheiten (wie etwa einen Bezahlungsdienstanbieter) spezifiziert. Wenn das Dienstprofil gewechselt wird, kann die Verrechnungsrichtlinie leicht angepasst werden, indem man den Eintrag in dem "Prepaid-Konto-Dekrementierer" oder in einer Teilmenge aller "Prepaid-Konto-Dekrementierer" (Tarife) ändert, die in dem neuen Dienstprofil enthalten sind, wodurch effektiv neue Tarife angewandt werden. Es ist sogar möglich, den Eintrag in dem Prepaid-Konto-Dekrementierer und daher den Tarif in jedem Verrechnungsschrittintervall abhängig von den Inhalten, die der Nutzer angeschaut hat, oder von dem Datenvolumen, das im vergangenen Intervall zu dem Nutzer übertragen wurde, zu ändern.
Gemäß einem optionalen, aber besonders nützlichen Merkmal der Erfindung wird das Verrechnen mittels Transaktionen erzielt, bei denen eine bestimmte Menge von Verrechnungseinheiten, die positiv oder negativ sein können, von einem Konto zu einem anderen transferiert wird. Wenn dem Nutzer zum Beispiel Sitzungszeit minutenweise berechnet wird und der Nutzer zwischen einem teueren Dienstprofil "erste Klasse", bei dem keine Werbeblöcke erlaubt sind, und einem billigeren Dienstprofil "Economy-Klasse", bei dem Werbeblöcke erlaubt sind, wählen kann, können an dem Verrechnungsverfahren zusätzlich zu dem Prepaid- Konto des Nutzers mehrere Konto beteiligt sein. Eines dieser Konten ist dann dem Profil "erste Klasse" zugeordnet, ein anderes dem Profil "Economy-Klasse" und jeder der Firmen bzw. jedem der Firmenpools, die die Werbeblöcke beauftragt haben, ein weiteres. Wenn dann der Nutzer das Profil "erste Klasse" gewählt hat, wird ein hohes Dekrement in dem "Prepaid-Konto-Dekrementierer" gesetzt, und nach jeder Verrechnungsperiode von einer Minute wird ein entsprechender Betrag von dem Prepaid-Konto in das "erste Klasse"-Konto transferiert. Wenn der Nutzer zu dem Profil "Economy-Klasse" wechselt, wird der Eintrag in dem "Prepaid-Konto-Dekrementierer" vermindert, und nach jeder Verrechnungsperiode wird ein entsprechend kleinerer Betrag von Verrechnungseinheiten von dem Prepaid-Konto in das "Economy-Klasse"-Konto transferiert. Somit geben die verschiedenen Konten zu jedem Zeitpunkt an, wieviel der akkumulierten Ausgaben des Nutzers für die "erste Klasse"-Dienste ausgegeben wurden und wieviel für die "zweite Klasse"-Dienste". Diese ausführlicheren Informationen werden nicht nur für den Nutzer wertvoll sein, sondern auch für den Dienstanbieter. Weiterhin kann der "Prepaid-Konto-Dekrementierer" während eines Werbeblocks zum Beispiel auf einen negativen Wert gesetzt werden, was bedeutet, dass der Nutzer für das Anschauen der Werbeblöcke bezahlt wird. Dann werden (positive) Beträge von Zähleinheiten von den Werbungs-Konto zu dem Prepaid-Konto des Nutzers transferiert. Folglich kann der Nutzer jederzeit sehen, wieviel er durch Anschauen der Werbung "verdient" hat, und umgekehrt kann der Dienstanbieter die Werbungs-Konto zur Rechnungsstellung bei den Firmen verwenden, die die Werbespots beauftragt haben. Zusätzlich erhalten diese Firmen wertvolle Rückmeldungsinformationen über das Ausmaß, zu dem die Werbung angeschaut wurde, und es kann jederzeit online auf diese Informationen zugegriffen werden.
Eine andere nützliche Anwendung des Verrechnungsverfahrens in Verbindung mit den dynamisch variierten Dienstprofilen ist die Unterstützung von Sponsoring. Wenn eine Person oder Firma Nutzerzugriffe im Allgemeinen oder spezifische Websites oder Inhalte, die im Internet angeboten werden, sponsern möchte, kann man ein spezifisches Dienstprofil für diesen Zweck erzeugen. Genauer gesagt begrenzt die durch dieses Dienstprofil definierte Inhaltsrichtlinie den Zugang zu Inhalten oder Websites, die der Sponsor sponsern möchte. Als Alternative können Pakete, die für die Website eines Sponsors bestimmt sind oder von dieser stammen, mit einem negativen Tarif belegt werden, wodurch ein Prepaid-Konto eines Nutzers, das zum Beispiel ein Loyalitätspunkte-Konto sein könnte, vergrößert wird. Weiterhin wird ein Sponsor-Konto als Prepaid- oder Postpaid-Konto vorgesehen, das dem Sponsor in Rechnung gestellt wird. Wenn die Suite voll gesponsert wird, wird dann nach jeder Verrechnungs periode das für diesen Dienst spezifizierte Dekrement nicht von dem Prepaid-Konto des Nutzers abgezogen, sondern wird stattdessen von dem Konto des Sponsors abgezogen. Als Alternative erreicht man denselben Effekt, indem weiterhin das Prepaid-Konto des Nutzers mit einem negativen Betrag dekrementiert wird (Verdienst), während gleichzeitig derselbe negative Betrag dem Sponsor-Konto inkrementiert wird – was mit der Zeit zu einer Erschöpfung des Sponsor-Kontos führt, wenn es nicht wiederaufgefüllt wird. Wenn die Site nur teilweise gesponsert wird, gilt für das Prepaid-Konto des Nutzers ein reduziertes Dekrement, und der Rest des Dekrements wird von dem Konto des Sponsors abgezogen, wodurch effektiv 2 Bezahlungsregeln und 2 Bezahlungstypen implementiert werden. Wahlweise wird ein spezifisches Konto für das gesponserte Profil für den Nutzer bereitgestellt, und die von dem Konto des Sponsors abzuziehenden Beträge werden zu dem Konto für das gesponserte Profil addiert, so dass der Nutzer jederzeit prüfen kann, wieviel er von dem Sponsor erhalten hat.
Als Alternative kann das Sponsoring erzielt werden, indem zu einem Zeitpunkt, an dem der Nutzer zu dem gesponserten Profil wechselt, eine begrenzte Menge von Verrechnungseinheiten von dem Konto des Sponsors zu dem Prepaid-Konto oder einem spezifischen gesponserten Konto des Nutzers transferiert wird. Nach jeder Verrechnungsperiode wird dann das Dekrement entweder von dem Prepaid-Konto oder von dem gesponserten Konto abgezogen, solange dieses nicht erschöpft ist.
Als Alternative zu der Verwendung spezieller Konto, die bei Erschöpfung eine Aktion auslösen, kann es mehrere verwendete Schwellen pro Konto geben, wobei jede Schwelle eine Aktion auslösen kann. Es sind zwei Typen von Schwellen zu differenzieren, ein Typ, der die aktuelle Teilsitzung beendet (kritische Schwelle) und ein Typ, der nur zum Auslösen einer Aktion immer dann verwendet wird, wenn die Schwelle überschritten wird.
Obwohl das oben beschriebene Verrechnungsverfahren auf Transaktionsbasis besonders in Verbindung mit dynamisch variierten Dienstprofilen nützlich ist, ist das Anwendungsgebiet des Verrechnungsverfahrens nicht darauf beschränkt.
Zum Beispiel findet das Verrechnungsverfahren auch Verwendung für sichere und leicht abzuwickelnde Bezahlungen, bei Aktivitäten von B2B (Unternehmen zu Unternehmen) oder B2C (Unternehmen zu Kunde), E-Business-Aktivitäten oder sogar bei P2P-Transaktionen (Peer to Peer). Dies ist besonders in Verbindung mit Mikrobezahlungen nützlich, d.h. Bezahlungen, bei denen die bezahlten Beträge so klein sind, dass die Transaktionskosten eines normalen Bezahlungsmodus wie etwa Bezahlung per Kreditkarte, unverhältnismäßig hoch wären. Wenn zum Beispiel private Nutzer über das Internet per E-Mail oder in einem Chatroom oder in einer Newsgroup miteinander kommunizieren, und ein Nutzer einen anderen Nutzer dafür belohnen möchte, dass er eine wertvolle Information gegeben hat oder ihm erlaubt hat, eine interessante Datei herunterzuladen, kann eine Bezahlung, die einem kleinen Geldbetrag entspricht, durch Transfer einer entsprechenden Menge von Verrechnungseinheiten erfolgen. Im Namen der die Bezahlung erhaltenden Person können diese Verrechnungseinheiten zu dem Prepaid-Konto addiert werden. Auf ähnliche Weise können Bezahlungen an kommerzielle Anwendungsdienstanbieter (ASP), an einen Informations-Makler oder dergleichen erfolgen. Somit wäre es möglich, dass zum Beispiel ein Anbieter kommerzieller Inhalte ein Online-Wörterbuch oder eine Online-Enzyklopädie anbietet und für jedes in dem Wörterbuch nachgeschlagene Stichwort eine kleine Gebühr beansprucht. Die Gebühr wird dann in Verrechnungseinheiten bezahlt. Als Mehrwertdienst kann der Internet-Dienstanbieter dann als Transaktionsvermittler handeln. Der Vermittler stellt dem Kunden-Nutzer das Belasten seines persönlichen Prepaid-Konto in legaler Währung in Rechnung. Die Bezahlungen an den Inhaltsanbieter akkumulieren sich auf einem Konto des ASP und dieses Konto wird von Zeit zu Zeit durch Umwandeln der Verrechnungseinheiten in legale Währung und durch Transfer eines entsprechenden Betrags in legaler Währung von dem Vermittler zu dem Inhaltsanbieter beglichen. In diesem Fall dienen die in dem Netzverrechnungssystem verwendeten Verrechnungseinheiten nicht nur Abrechnungszwecken des Internetdienstanbieters, sondern haben auch die Funktion einer virtuellen Währung für andere Geschäftstransaktionen.
Das beschriebene Echtzeit-Verrechnungsverfahren gilt nicht nur für Prepaid- sondern auch für Postpaid-Verrechnung und -Abrechnung. Abhängig von dem Verrechnungsmodus handelt die SMA entweder als Prepaid-System oder als Postpaid-System. Es versteht sich, dass die hier vorgestellten Lösungen nicht auf Prepaid beschränkt sind, sondern gleichzeitig auch auf Postpaid anwendbar sind. Immer wenn die vorliegende Schrift Prepaid bespricht, kann folgendermaßen eine äquivalente Postpaid-Lösung abgeleitet werden: Wenn das Prepaid-System (den Tarif) dekrementiert, inkrementiert ein Postpaid-System. Wenn ein Prepaid-System auf Konto-Erschöpfung prüft, ist das für ein Postpaid-System nicht notwendig, es prüft aber, ob ein optionales Bezahlungslimit erreicht wurde. Einmal pro Monat oder vierteljährlich oder alternativ dazu in kürzeren Intervallen wird eine Rechnung für Postpaid-Kunden erstellt. Bei Verwendung einer Verrechnungslogik MPL, die in dem NDV selbst verankert ist, bezieht sich Echtzeit-Postpaid-Abrechnung auf Bezahlungstypen, die Echtzeit-Postpaid-CDRs erzeugen, als Reaktion auf eine Schwellenaktion, die den Transfer einer Bezahlung zu der Bezahlungsquelle, dem Bezahlungsvermittler oder dem Anwendungsdienstanbieter auslöst.
Das Verrechnungsverfahren gemäß einer vorteilhaften Ausführungsform kann auch für statistische Zwecke im allgemeinen Sinne verwendet werden. In diesem Kontext sind die Konten eines individuellen Nutzers möglicherweise nicht mit verschiedenen Dienstprofilen verknüpft, können aber mit verschiedenen Kategorien von Diensten und/oder Inhalten in demselben Profil verknüpft sein. Zum Beispiel kann es ein oder mehrere Konten für verschiedene Typen von Werbung geben, die der Nutzer angeschaut hat, ein Konto für Online-Käufe des Nutzers, wofür der Internet-Dienstanbieter eine Kommission erhält oder die auf andere Weise für den ISP profitabel sind, und dergleichen. Dadurch kann der Internet-Dienstanbieter u.a. die Nutzer permanent bezüglich ihrer Profitabilität einstufen. Dies kann auch in einem Flatrate-Szenario attraktiv sein, bei dem der Nutzer nicht pro Dienst eine Rechnung erhält, sondern er einen festen monatlichen Betrag für den Zugang zu dem Netz bezahlt. In Verbindung mit dynamisch wechselnden Dienstprofilen kann diese Einstufung dazu dienen, profitable Nutzer automatisch in ein extensiveres Dienstprofil wechseln zu lassen oder umgekehrt das Dienstprofil von weniger profitablen Nutzern einzuschränken. Diese Einstufungsprozedur und ihre Konsequenzen können für den Nutzer entweder sichtbar oder unsichtbar sein.
Solche statistischen Informationen können auch für den Nutzer nützlich sein, da sie zum Beispiel zum Einrichten eines automatischen Betrugsdetektionssystems verwendet werden können, indem z.B. für den Kunden sichtbare oder unsichtbare Bezahlungslimits implementiert werden oder auf abnormes Nutzerverhalten überwacht wird, wodurch auf betrügerische Nutzung hingewiesen werden könnte.
Das Gleichgewicht zwischen Privatsphäre und Rechenschaftspflicht, d.h. wie weit das Verhalten des Nutzers verfolgt werden kann, hängt von der Auswahl von nutzerspezifischen und globalen Kontos ab. Nutzerspezifische Konten ermöglichen das Verfolgen des Verhaltens individueller Nutzer mit einer Auflösung, die von der durch die verschiedenen Konten repräsentierten Definition von Dienstkategorien und/oder Inhaltskategorien abhängt. Andererseits spiegelt sich in globalen Konten nur das kollektive Verhalten der Nutzer wider, ohne jede Möglichkeit, die Nutzer zu identifizieren, die die entsprechenden Dienste genutzt haben.
Ein anderer Privatsphärenmodus liegt vor, wenn mehrere Tarife (Dekrementierer) auf einen einzigen Kredit-Zähler (oder ein Prepaid-Konto) angewandt werden. Somit gehen die Informationen verloren, welches Dienstprofil wie lange benutzt wurde (im Fall einer Sitzung mit mehreren Teilsitzungen gehen die Informationen, wie lange die Teilsitzungen dauerten und welcher Tarif in der Teilsitzung vorlag, absichtlich verloren. Bei Verwendung von Abrechnung auf Volumenbasis mit mehreren Tarifen abhängig von dem Pakettyp kann ähnlich ein Privatsphärenmodus nur ein einziges Konto (Prepaid-Konto oder Kredit-Zähler) zum Inkrementieren der verschiedenen Tarife verwenden, was zu der Situation führt, dass der Dienstanbieter das Nutzerverhalten nicht verfolgen muss, aber immer noch differenzierte Volumentarife mit Echtzeit-Abrechnung anwenden kann. Dadurch werden die heutigen Probleme überwunden, dass zu viele Abrechnungsinformationen gesammelt werden müssen, um solche Arten von Diensten anzubieten, die auch von den Kunden nicht angenommen werden, da es ihnen unbehaglich ist, dass der Dienstanbieter ihr Verhalten im Detail untersucht.
Die Funktionalität, die durch das Verrechnungsverfahren gemäß der Erfindung ermöglicht wird, führt zu vielfältigen Merkmalen, die ihrerseits zur Spezifikation verschiedener Dienstprofile verwendet werden können. Zum Beispiel kann man die Dienstprofile bezüglich der nachfolgend beschriebenen Richtlinien unterscheiden:
Werbe-Richtlinie:
Eine Richtlinie, die regelt, wie der Nutzer Werbung ausgesetzt wird (und gezwungen wird, sie anzuschauen), einschließlich zum Beispiel des Tarifs und der Länge der Werbeblöcke, die die normale Nutzung des Nutzers unterbrechen und ihn dazu zwingen, die Werbung anzuschauen, der Art der Werbung und ob für diesen Nutzer gezielte Werbung anwendbar ist.
Einstufungsrichtlinie:
Die Richtlinie, die regelt, wie ein Kunde in Bezug auf Profitabilität für den Dienstanbieter oder andere vom Dienstanbieter spezifizierte Kriterien eingestuft wird. Wenn zum Beispiel die Einstufung dem Nutzer über Kundenloyalitäts-Bonuspunkte teilweise sichtbar ist, kann die Richtlinie auch regeln, wie auf die Einstufung des Nutzers reagiert wird, indem z.B. ein profitabler Nutzer auf eine bessere Dienstgütestufe oder ein weniger profitabler Nutzer auf eine niedrigere Dienstgütestufe gebracht wird – natürlich immer innerhalb der Grenzen des Dienstvertrags.
Richtlinie in Bezug auf Betrugsdetektion:
Die Richtlinie, die unsichtbare Bezahlungslimits, Klassifikation von Nutzern gemäß normalen Nutzungsmustern, Nutzerbenachrichtigungsrichtlinien usw. regelt.
Da das oben beschriebene Verrechnungsverfahren nicht auf den Fall beschränkt ist, dass das Dienstprofil dynamisch variiert wird, betrifft ein weiterer Aspekt der vorliegenden Erfindung ein Verrechnungsverfahren für Telekommunikationsdienste, wobei Nutzer Telekommunikationsdienste in vordefinierten Diensteinheiten verbrauchen, die jeweils einen spezifischen Wert aufweisen, der in Verrechnungseinheiten ausgedrückt wird, und jeder Nutzer mindestens ein Konto besitzt, das im Wesentlichen in Echtzeit gemäß den verbrauchten Diensteinheiten inkrementiert oder dekrementiert wird, mit Transaktionen, bei denen eine positive oder eine negative Menge von Verrechnungseinheiten von einem Konto eines Nutzers zu einem anderen Konto transferiert wird.
In diesem Kontext bedeutet der Ausdruck "im Wesentlichen in Echtzeit", dass die Verrechnungsinformationen genau und rechtzeitig genug bereitgestellt werden, um vom Dienstanbieter und/oder von den Nutzern oder anderen Teilnehmern in dem Netz in Echtzeit wahrgenommen zu werden, wenn man unvermeidliche Ansprechzeiten in den Systemen auf Netzbasis berücksichtigt.
Kurze Beschreibung der Zeichnungen
Bevorzugte Ausführungsformen der Erfindung werden nun in Verbindung mit den Zeichnungen beschrieben. Es zeigen:
1 ein Blockdiagramm eines multifunktionalen Prepaid-Systems, wobei eine erste Ausführungsform der Erfindung dargestellt ist;
2 ein Diagramm eines persönlichen Prepaid-Datensatzes (PPR);
3 ein Flussdiagramm der Grundschritte des Verfahrens gemäß der Erfindung;
4 ein Flussdiagramm einer Verrechnungsroutine;
5 eine vereinfachte Darstellung eines Nutzerschirmbildes;
6 ein Blockdiagramm eines Echtzeit-Abrechnungssystem, wobei eine zweite Ausführungsform der Erfindung dargestellt ist;
7 ein Beispiel für eine in dem Echtzeit-Abrechnungssystem verwendete Abrechnungsrichtlinie;
8 ein Funktionsdiagramm eines Einstufungsschritts in dem Echtzeit-Abrechnungssystem;
9 ein Funktionsdiagramm eines Verrechnungs- und Prüfschritts in dem Echtzeit-Abrechnungssystem;
10 ein Funktionsdiagramm eines Lese-Schritts in dem Echtzeit-Abrechnungssystem.
Beschreibung bevorzugter Ausführungsformen
1 bis 5 beschreiben ein multifunktionales Prepaid-System als eine erste Ausführungsform der Erfindung. Dieses System ist besonders nützlich für die Echtzeit-Verrechnung von E-Business-Aktivitäten von B2B oder B2C und von Netzzugangskosten (über verdrahtete und drahtlose Netze) mit Privatsphären-Schutzfähigkeit mit mehreren Privatsphärenmodi und der Möglichkeit eines Bezahlungslimit, Sponsor-Finanzierung und Werbungs-Finanzierung mit der Möglichkeit der Unterbrechung der uneingeschränkten Nutzung über Werbeblöcke mit eingeschränkter Alternativnutzung sowie mit der Möglichkeit der Feinabstimmung von Werbekampagnen in Echtzeit gemäß regionalen oder anderen anonymisierten Kundendaten sowie mit der Möglichkeit, dass der Nutzer sein Nutzungsprofil mehrmals in einer Nutzungssitzung wechselt, einschließlich des geltenden Tarifs und der geltenden Sicherheitsrichtlinie und der geltenden Privatsphärenrichtlinie, und auch mit der Möglichkeit, dass der Nutzer die aktuelle Dienstrichtlinie und den Status seiner betreffenden Konten in Echtzeit überwacht.
Das multifunktionale Prepaid-System, das im Folgenden als MPS abgekürzt wird, ist ein Gesamtsystem, das aus mehreren Hardware- und Softwareelementen besteht, die auf spezielle Weise zusammenarbeiten, um wie oben umrissen eine extensive Menge von Merkmalen zu liefern.
1 zeigt die Kernelemente des multifunktionalen Prepaid-Systems sowie bestimmte ergänzende Elemente.
Eine (als MPL abgekürzte) multifunktionale Prepaid-Logik 10 umfasst eine als persönliche Benutzerdatenbank 12 (Abkürzung PUD) bezeichnete Datenbank und mindestens eine als Sitzungsmanageranwendung 14 (Abkürzung SMA) bezeichnete Anwendung sowie mindestens eine RADIUS-Serveranwendung 16 für Authentifizierungszwecke. Die MPL 10 implementiert die vollständige Dienstelogik, die die Internetnutzer (Teilnehmer) und andere Teilnehmer des multifunktionalen Prepaid-Systems, wie zum Beispiel Sponsoren und Werbende, beschreibt. Die multifunktionale Prepaid-Logik wird in der Datenbankstruktur in Verbindung mit den Ausführungsprinzipien der Sitzungsmanageranwendung 14 beschrieben.
Ein Benutzer 18 greift über eine Netzdienstvermittlungsanlage 20 (NDV) auf die MPL 10 zu. Die NDV wird durch die MPL 10 gesteuert und bestimmt die Inhalte, zu denen der Nutzer 18 Zugang hat. Zu diesen Inhalten kann die Gesamtheit oder eine eingeschränkte Auswahl der Inhalte 22 gehören, die über das Internet zugänglich sind, darunter Inhalte, die von Inhaltsanbietern, Anwendungsdienstanbietern (ASP), Streaming-Anbietern und dergleichen gehostet werden. Eine spezifische Klasse von Inhalten 24 wurde separat gezeigt. Diese Inhalte 24 werden von einem Sponsor gesponsert, so dass sie zu verringerten Kosten oder kostenlos angeschaut werden können.
Eine weitere Klasse von Inhalten 26 besteht aus Werbespots, die vom Dienstanbieter zusammengestellt wurden, um die Dienste zumindest teilweise durch Werbung zu finanzieren.
Der Dienstanbieter hat ferner eine Anzahl spezieller Websites 28, 30 und 32 bereitgestellt, darunter eine Startperioden-Website 28, zu der der Nutzer zwangsweise geleitet wird, wenn er sich in das Netzwerk einloggt. Eine andere Website 30, die als "Inhalts- und Richtlinienauswahlportal" (PSP) bezeichnet wird, kann vom Benutzer zu einem beliebigen Zeitpunkt während der Sitzung besucht werden und ermöglicht es dem Benutzer, sein Dienstprofil innerhalb der Sitzung zu wechseln.
Wenn das Prepaid-Konto des Nutzers erschöpft ist, wird er zwangsweise zu einer "Übergangsperioden-Website" 32 geleitet, die dem Nutzer mitteilt, dass er sein Konto wieder aufladen muss oder andernfalls von dem Netzwerk getrennt wird.
Die multifunktionale Prepaid-Logik 10 ist auch durch eine Anzahl von Schnittstellen 34 zugänglich, wie zum Beispiel B2B-Schnittstellen, B2C-Schnittstellen und P2P-Schnittstellen, die für verschiedene Arten von Geschäftstransaktionen benutzt werden.
In der persönlichen Nutzerdatenbank 12 hat jeder Nutzer einen persönlichen Prepaid-Datensatz (PPR) 36 dessen Struktur in 2 gezeigt ist.
Der PPR 36 enthält verschiedene Felder, wie zum Beispiel die folgenden, sehr wichtigen Felder: Nutzer-ID 38, Passwort 40, persönliches Prepaid-Konto (PPA) 42, Prepaid-Konto- Dekrementierer (PAD) 44, ein Erschöpfungsrichtlinienfeld 46, einen Zeiger auf Erschöpfungsrichtlinien-Parameter 47 und einen Zeiger auf Zähler-Konto 48.
Die Nutzer-ID identifiziert den Nutzer, das Passwort dient zum Authentifizieren des Nutzers, das persönliche Prepaid-Konto enthält den aktuellen Wert des Prepaid-Konto in Verrechnungseinheiten, der im Prinzip dem Nutzer einen Wert darstellt, den er durch Vorbezahlung oder durch andere Mittel angeschafft hat. Der Prepaid-Konto-Dekrementierer repräsentiert den zurzeit geltenden Tarif, da er die Anzahl der Verrechnungseinheiten beschreibt, die pro Verrechnungsintervall ausgegeben werden (vergleichbar mit einer Ausgabengeschwindigkeit). Der Betrag, um den das persönliche Prepaid-Konto dekrementiert wird, wird zu einem Zähler-Konto 50 transferiert, das nicht unbedingt in dem PPR enthalten ist. Es kann vielfältige Konten geben, die als Zähler-Konto für eine spezifische Transferaktion dienen, abhängig von dem tatsächlichen Dienstprofil oder von der Art der Transaktion. Aus diesem Grund enthält der PPR das Feld Zeiger auf Zähler-Konto, das das betreffende Zähler-Konto spezifiziert. Abhängig von dem gewählten Privatsphärenmodus kann das Zähler-Konto ein persönliches Konto sein, das in dem PPR desselben Nutzers enthalten ist, oder ein globales Konto, das dem Internet-Dienstanbieter oder einem anderen Teilnehmer, z.B. einem Werbenden, einem Sponsor oder dergleichen, gehört. Im Fall von P2P-Transaktionen kann das Zähler-Konto auch ein persönliches Prepaid-Konto oder ein anderes Konto eines anderen Nutzers sein.
Das Erschöpfungsrichtlinienfeld 46 und der Zeiger auf Erschöpfungsrichtlinien-Parameter 47 spezifizieren, welche Aktionen unternommen werden sollen, wenn das persönliche Prepaid-Konto erschöpft wird.
Der PPR enthält ferner ein persönliches Steuerfeld 52 und ein dynamisches Steuerfeld 54, deren Funktionen später erläutert werden.
Abhängig von dem gewählten Betriebsmodus oder Dienstprofil kann der PPR im Klarformat oder im erweiterten Format vorliegen. Das Klarformat enthält die oben beschriebenen Felder sowie einen Zeiger auf Erweiterung 56, einen Zeiger auf Werbungssteuerung 58 und andere Felder 60, die für andere Zwecke benutzt werden können.
Weiterhin enthält das Klarformat mehrere Werbungs-Steuerblöcke, von denen einer in 2 gezeigt ist. Ein Werbungsblock-Dauer-Konto 62 wird um einen Betrag dekrementiert, der am Anfang jedes Verrechnungsintervalls, in dem der Nutzer darauf beschränkt war, einen spezifischen Werbeblock anzuschauen, der mit dem Konto-Feld 62 und mit einem entsprechenden globalen Zähler-Konto des Werbenden verknüpft ist, in einem Werbungsblock-Dauerdekrementierer 64 spezifiziert wird. Ein Erschöpfungsrichtlinienfeld 66 spezifiziert die zu unternehmende Aktion, wenn das Werbungsblock-Dauer-Konto erschöpft wird, z.B. Zurückkehren zum Vorgabeprofil des Nutzers. Zusätzliche Felder 68 steuern die Dauer jedes einzelnen Werbespots innerhalb des Werbeblocks auf analoge Weise.
Die in dem Feld 46 oder 66 spezifizierte Erschöpfungsrichtlinie kann implizieren, dass der Zugang des Nutzers auf bestimmte IP-Adressen eingeschränkt wird. In diesem Fall ist das zu verwendende Dienstprofil nicht unbedingt voll in der NDV vordefiniert. Statt dessen enthält der PPR die Felder "Zeiger auf Erschöpfungsrichtlinienparameter" 47, 68, die mit dem Erschöpfungsrichtlinienfeld assoziiert sind und auf Parameter wie etwa eine IP-Adresse zeigen, die die SMA an die NDV weitergeben muss, wenn die NDV mit einer neuen Richtlinie instruiert wird. Dieses Verfahren kann auch für exklusiven Premium-Inhalt verwendet werden.
Das Klarformat reicht aus, wenn der Nutzer einen Privatsphärenmodus benutzt, der keine Verrechnungsmöglichkeit benötigt, und wenn der Werbemodus nicht verfolgen muss, welche Werbung der Nutzer angeschaut hat. Es wird erwartet, dass der größte Teil der Nutzer größtenteils Betriebsarten verwenden wird, die mit dem Klarformat assoziiert sind (es wird erwartet, dass die mit dem Klarformat assoziierten Dienste billiger als Dienste mit erweitertem Format sein werden).
Der Zeiger auf Erweiterung 56 zeigt auf eine Erweiterung, die das erweiterte Format repräsentiert, und das in dem gezeigten Beispiel Felder 70 bis 80 enthält.
Wenn der Nutzer 18 auf den Dienst zugreift, verbindet er sich logisch mit der Netzdienstvermittlungsanlage 20 (NDV). Die NDV stellt die "Teilnehmerkante" dar, an der die Kommunikation des Teilnehmers (Kunden) verankert ist, gleichgültig, welches Zugangsverfahren der Kunde benutzt. Die NDV 20 kommuniziert dann über das RADIUS-Protokoll mit dem RADIUS-Server 16, um den Nutzer zu authentifizieren. Der RADIUS-Server 16 schlägt den Nutzerdatensatz (den PPR – persönlicher Prepaid-Datensatz) in der persönlichen Nutzerdatenbank 12 nach, und wenn er den Nutzer findet und wenn das Passwort oder ein anderes verwendetes Authentifikationsverfahren stimmt, sendet der RADIUS-Server eine positive Authentifikation zu der NDV 20. Der RADIUS-Server modifiziert den PPR in der Datenbank, um anzuzeigen, dass es sich aktuell um einen aktiven Nutzer handelt und fügt die Nutzer-ID zu einer Wechsel-Anforderungs-Liste in der Datenbank 12 hinzu. Die SMA 14 unterbricht regelmäßig (z.B. nach dem Manipulieren einer Anzahl von Nutzer-Konto in ihrem lokalen Cache), um in der Datenbank nachzuschlagen, ob ein Wechsel angefordert wurde. Sie ruft den PPR ab und speichert eine Kopie des PPR in ihrem lokalen Cache. Der Cache hält alle aktiven Nutzer. Die Kopie des PPR bleibt in dem schnelleren Speicher (dem Cache), bis sich der Nutzer trennt. Wenn sich der Nutzer trennt, wird der RADIUS-Server 16 über eine RADIUS-Verrechnungsstoppnachricht darüber informiert und zeigt in dem PPR an, dass der Nutzer nicht mehr aktiv ist und informiert die SMA 14 wieder über die Datenbank, den PPR dieses Nutzers aus dem Aktiv-Nutzer-Cache zu entfernen.
Die Netzdienstvermittlungsanlage 20 (NDV), die durch die MPL 10 gesteuert wird, erlaubt einen Wechsel des Nutzerprofils (wodurch effektiv derselbe Nutzer umautorisiert wird) mehrmals während einer Sitzung. Dadurch wird eine Nutzersitzung effektiv in mehrere Teilsitzungen aufgeteilt, wobei am Anfang jeder Teilsitzung eine Neuautorisierung des Nutzers stattfindet – wobei ein getrenntes Nutzerprofil und ein getrennter Tarif und potentiell auch Verrechnungsmodus für jede Teilsitzung angewandt wird.
Die Grundschritte des Verfahrens des Bereitstellens von Internet-Zugang und insbesondere des Wechselns des Dienstprofils sind in 3 dargestellt, worin eine Ansicht auf hoher Ebene der durch die MPL 10 durchgeführten Funktionen als ganzes gegeben wird. Eine Sitzung beginnt, wenn die NDV, z.B. über eine Radiusverrechnungsstartanforderung, anfordert, dass Dienstablieferung unter Verwendung der anfänglichen Autorisierung tatsächlich gestartet hat. Im Schritt SO aktualisiert der RADIUS-Server 16 den PPR, um ihn als aktiven Nutzer zu markieren, und fordert außerdem über die Datenbank von der SMA an, den PPR zu ihrem lokalen Cache hinzuzufügen. Im Schritt S1 wird geprüft, ob eine Anforderung, das Dienstprofil zu wechseln, vorliegt. Diese Anforderung kann vom Benutzer eingegeben werden oder kann das Ergebnis eines Ereignisses sein, das in der Verrechnungsprozedur erkannt wird, wie zum Beispiel das Ereignis, das das Prepaid-Konto des Nutzers erschöpft ist. Schritt S1 wird zyklisch wiederholt, bis eine Anforderung eines neuen Dienstprofils auftritt. Dann wird im Schritt S2 der persönliche Prepaid-Datensatz PPR aktualisiert, und die Netzdienstvermittlungsanlage 20 wird im Schritt S3 angewiesen, das Dienstprofil für den Nutzer neu zu konfigurieren. Im Schritt S4 wird dann geprüft, ob die Sitzung beendet ist. Wenn dies nicht der Fall ist, kehrt die Routine in einer Schleife zum Schritt S1 zurück, und die oben beschriebene Sequenz von Schritten wird wiederholt, bis sich der Nutzer ausloggt oder zwangsweise von dem Netzwerk getrennt wird. Wenn im Schritt S4 erkannt wurde, dass die Sitzung beendet ist, z.B. bei Empfang einer RADIUS-Verrechnungsstoppnachricht durch den RADIUS-Server 16, wird der PPR des Nutzers aus dem Cache gelöscht und der Nutzer wird nicht mit als aktiver Nutzer behandelt.
Die SMA 14 ist eine Anwendung, die durch das System automatisch in bestimmten (als Verrechnungsschritt) bezeichneten Intervallen gestartet wird und die Datensätze in der persönlichen Nutzerdatenbank (PUD) 12 in jedem Verrechnungsschritt manipuliert, indem Verrechnungseinheiten von einem Konto zu einem oder mehreren anderen Konten transferiert werden, wobei strikt sichergestellt wird, dass sich die Summe aller Verrechnungseinheiten in dem Gesamt-MPS in einem Verrechnungsschritt nicht ändert. Eine MPS-Einheit kann Geld in beliebiger Währung oder skaliertes Geld sein, wie zum Beispiel 1/10 Cent. Als Alternative kann es sich bei einer MPS-Einheit auch um Zeit in Sekunden oder Minuten oder eine beliebige andere Zeiteinheit handeln. Als Alternative kann es sich bei einer MPS-Einheit um Bonuspunkte eines Kundenloyalitätssystems handeln, ähnlich wie bei dem von Fluglinien verwendeten Airmiles-Belohnungssystemen, oder um andere Belohnungen, die Firmen ihren Kunden als Kundenbindungsanreiz geben. Als Alternative können Verrechnungseinheiten neu erzeugte Einheiten sein, die es heute noch nicht gibt, wie zum Beispiel "Prepaid-Meilen", wobei eine Prepaid-Meile zu einem bestimmten Zeitpunkt (den Zeitpunkt des Kaufs) einen festen Preis hat, der sich jedoch mit der Zeit ändern kann, oder Sponsor-"Meilen" oder Werbungs-"Meilen", die eine spezielle Einheit zur Verrechnung mit Werbenden und Sponsoren repräsentiert. Als Alternative kann es sich bei einer MPS-einheit auch um Privatsphären-Meilen handeln, die einen Zugang zum Internet mit differenzierten Privatsphären-Graden ermöglichen und den Grad der Privatsphäre mehrmals innerhalb einer Nutzersitzung ändern, wobei der Nutzer den entsprechenden Grad der Privatsphäre für die jeweilige Internetaktivität auswählt.
Im Allgemeinen besteht ein Konflikt zwischen dem Wunsch des Nutzers von Privatsphäre und dem Wunsch des Nutzers von Verrechnungsmöglichkeit. Verrechnungsmöglichkeit ermöglicht es dem Benutzer, seinen Dienstanbieter für den bereitgestellten Dienst verantwortlich zu machen, z.B. durch Weigerung, für einen Posten in einer Rechnung zu bezahlen, von dem der Nutzer behauptet, dass er ihn nicht gekauft oder vielleicht nur mit verschlechterter Qualität erhalten wurde. Für den Dienstanbieter bedeutet Verrechnungsmöglichkeit, dass er die Möglichkeit benötigt, E-Commerce-Transaktionen zurückzurollen oder zu erstatten, wenn der Nutzer mit dem bereitgestellten Dienst oder den abgelieferten Waren nicht zufrieden ist. Der Nutzer kann dann verlangen, die Transaktion zurückzurollen (z.B. die Waren auf der Basis der Gesetze für den Verbraucherschutz zurückzugeben), und deshalb muss der Dienstanbieter Daten über das Nutzerverhalten behalten, um in der Lage zu sein, die E-Commerce-Transaktion zurückzurollen oder zumindest zu verifizieren, ob die Beschwerde des Nutzers berechtigt ist. Folglich müsste der Dienstanbieter Daten über das Nutzerverhalten sammeln, wie zum Beispiel seine E-Commerce-Transaktionen, verbrauchten Inhalt usw. Das Sammeln dieser Daten steht jedoch in Konflikt zu dem Wunsch des Nutzers von Privatsphäre. Das MPS löst dieses Problem, indem dem Nutzer zu allen Zeiten die Wahl gegeben wird, welchen Grad der Privatsphäre er für die aktuelle Internet-Aktivität anwenden möchte. Wenn er Privatsphäre so durchsetzen möchte, dass der Dienstanbieter das Nutzerverhalten für die nächste Teilsitzung nicht verfolgen soll, muss er gleichzeitig zustimmen, sein Beschwerderecht aufzugeben, wenn die Qualität des Dienstes nicht zufriedenstellend war.
Es werden sechs Grade der Privatsphäre in dem MPS implementiert:

– Grundlegende Verrechnungsmöglichkeit (z.B.: Dienstanbieter verfolgt den Fluss der Verrechnungseinheiten für Zurückroll-Fähigkeit)
– Erweiterte Verrechnungsmöglichkeit (z.B. zusätzlich: Dienstanbieter führt IP-Abrechnung an Paketen volumenweise durch). Dies wird dadurch erreicht, dass die SMA 14 vor der Dekrementierung auf der Basis der Anzahl durch die NDV 20 gezählten Pakete in bis zu 64 Buckets gemäß dem Wert des TOS-Feldes in dem IP-Paket dynamisch das Dekrementiererfeld ändert.
– Premium-Verrechnungsmöglichkeit (z.B. handelt der Dienstanbieter als Vermittler für E-Commerce-Transaktionen)
– Grundlegende Privatsphäre (z.B.: Dienstanbieter weiß nicht, zu welchem Konto Verrechnungseinheiten Transferiert wurden – keine Verfolgung, keine Rückroll-Fähigkeit, keine technische Möglichkeit, zu sagen, welchen Inhalt oder welche Werbung der Nutzer angeschaut hat).
– Erweiterte Privatsphäre (wie grundlegende Privatsphäre, aber zusätzlich z.B. grundlegende Anonymität für E-Mail, Cookie-Filterung)
– Premium-Privatsphäre (z.B.: erweiterte Anonymität des Nutzers wird durch Alias-Schnittstellen gewährt).

Mit dem Privatsphärenmodus stehen Werbungs-Betriebsarten in Beziehung. Werbungs-Betriebsarten können nutzerwählbar sein oder auch nicht (als Alternative können sie fest mit einem bestimmten Dienst verknüpft sein). Es gibt mehrere Werbungs-Betriebsarten (es sind Kombinationen möglich, wenn sie sich nicht widersprechen), zum Beispiel:

– Keine Werbung (Premium-Tarif)
– Anonyme Werbung
– Werbung zum Sitzungsbeginn
– Werbung am Sitzungsende
– Werbung bei Richtlinienwechsel
– Werbung im Zeitintervall
– Werbung in Zusammenarbeit mit Client
– Client-getriggerte Werbung
– Im Client eingebettete Werbung
– In Zwischenräumen gelegene Werbung auf Vollbildschirm
– Exklusive Werbung (Sperrung aller anderen Verwendungszwecke)
– Nicht exklusive Werbung (Benutzer kann parallel andere Aktivitäten durchführen)
– Abgezielte Werbung
– Target Plus: abgezielte Werbung mit Verfolgung, welche Werbung der Benutzer angeschaut hat
– Ereignis- und kontextgesteuerte Werbung

In 4 sind die Grundschritte der Verrechnungsprozedur zusammengefasst. Im Schritt S11 wird geprüft, ob das Verrechnungsschrittintervall abgelaufen ist. Dieser Schritt wird wiederholt, bis das Intervall tatsächlich abgelaufen ist. Dann erfolgt im Schritt S12 die Verrechnung für alle aktiven Nutzer. Zu diesem Zweck wird das aktuelle Dienstprofil des Nutzers bestimmt und es wird entschieden, welche Konten gemäß diesem Dienstprofil geändert werden können oder müssen und welche Zähler-Konten mit diesen Konten verknüpft sind. Dann wird jedes auf diese Weise bestimmte Konto geändert, indem das für dieses Konto spezifizierte Dekrement subtrahiert wird. Wenn das Konto zum Beispiel das in 2 gezeigte persönliche Prepaid-Konto 42 ist, wird das entsprechende Dekrement durch den Prepaid-Konto-Dekrementierer 44 angegeben. Dasselbe Dekrement wird dann zu dem mit diesem Konto assoziierten Zähler-Konto 48 addiert. In einem Verrechnungsmöglichkeitsmodus kann das Zähler-Konto für das persönliche Prepaid-Konto ein persönliches Empfangs-Konto sein, das in den Erweiterungsfeldern 70, 72 des PPR enthalten ist. Ähnlich kann der Verrechnungsschritt den Transfer einer Anzahl von Verrechnungseinheiten, die in dem Feld 78 spezifiziert wird ("Dekrementierer X") von dem Feld 74 ("Konto X") zu dem Feld 76 ("Zähler-Konto X") umfassen. Ähnlich können als Dekrement von dem Werbungsblock-Dauer-Konto subtrahierte Verrechnungseinheiten zu dem entsprechenden Zähler-Konto addiert werden, wodurch der Werbende in Echtzeit überwachen kann, wieviel Zeit die Nutzer kollektiv mit dem Anschauen dieses Werbeblocks verbracht haben.
Im Schritt S12 wird auch für jeden aktiven Nutzer und für jedes Konto geprüft, ob das Konto erschöpft wurde. Wenn dies der Fall ist, weist die SMA die NDV an, die Dienstrichtlinie auszuwählen, die durch den Wert in dem Feld Erschöpfungsrichtlinie definiert wird, und wahlweise durch zusätzliche Parameter, die durch eine Liste verketteter Parameter definiert werden, die durch den Parameterzeiger auf Erschöpfungsrichtlinie verankert werden. Im Anschluss an Schritt S12 kehrt die Routine zu der Startposition zurück und wird erneut ausgeführt, wenn das nächste Verrechnungsschrittintervall abgelaufen ist.
Ein wesentliches Merkmal der MPL ist der Umstand, dass sie gemäß den Verrechnungsprinzipien arbeitet, bei denen die Summe aller Konten in einem Verrechnungsschritt konstant bleibt. Es ist natürlich möglich, Konten über eine externe Schnittstelle zu füllen oder anderweitig zu manipulieren – die SMA 14 ändert jedoch kein Konto, ohne die Bilanz zu einem anderen Konto in dem System zu transferieren, wodurch die Bilanz aller Konten in der Datenbank konstant gehalten wird. Dies impliziert, dass es ein globales Konto "Dienstanbieter – verdienter Nettoumsatz" (repräsentiert durch das Zähler-Konto 48 in 2) gibt, das weiter in Teil-Konten aufgeteilt werden kann. In diesem Konto kann der Dienstanbieter prüfen, wie viele der Verrechnungseinheiten (z.B. Prepaid-Geld) die Nutzer tatsächlich ausgegeben haben, reduziert um den Betrag, den andere Teilnehmer (z.B. Dienstanbieter) in ihren globalen Konten erhalten haben.
Im Verrechnungsmöglichkeitsmodus und in dem Werbungs-Modus Target Plus transferiert die SMA 14 Verrechnungseinheiten nur innerhalb des PPR. Der PPR enthält deshalb im erweiterten Modus Empfangs-Konten (wie zum Beispiel in den Feldern 70, 72), in die Prepaid-Berechnungseinheiten in jedem Verrechnungsschritt transferiert werden, sowie Spende-Konten, wie zum Beispiel Sponsor-Konten, in die (negative) MPS-Einheiten addiert (somit subtrahiert) werden, wenn Sponsern stattfindet oder eine gesponserte Werbung angeschaut wird. Damit kann man kundenweise und auch Sponsor-weise eine persönliche maximale Sponserungs-Schwelle implementieren und außerdem die maximale Zeit begrenzen, für die ein einzelner Benutzer eine bestimmte Werbung anschauen (und Verrechnungseinheiten dafür erhalten) kann. Man kann damit auch unter Berücksichtigung, welche Werbung der einzelne Benutzer zuvor gesehen hat, Werbung abziehen.
Wenn der erweiterte Modus nicht benutzt wird, ist es normal, dass die SMA Verrechnungseinheiten während eines Verrechnungsschritts zwischen einem PPR und einem oder mehreren globalen Konten transferiert. In diesem Fall ist es nicht möglich, dass für jeden einzelnen Sponsor oder Werbenden zu verfolgen, welchem Nutzer die Verrechnungseinheiten transferiert wurden (wer aus dem Sponsern Nutzen zog und wer eine bestimmte Werbung oder einen bestimmten exklusiven Inhalt gesehen hat). Damit kann man Schutz der Privatsphäre sicherstellen. Die MPL und jeder PPR kann im gemischten Modus ablaufen, wobei bestimmte Konten im voll personalisierten Modus behandelt werden, während andere Konten im globalen Modus behandelt werden. Bei der Variante "Global-Modus" wird die Summe aller sogenannten globalen Konten und aller aktiven PPR nach jedem abgeschlossenen Verrechnungsschritt immer bilanziert (null). Für Dienstprofile mit Zeittarif führt die Sitzungsmanageranwendung 14 (SMA) regelmäßig in bestimmten als Verrechnungsschrittintervall bezeichneten Intervallen Verrechnungsschritte aus. Jeder PPR kann wahlweise ein Feld "Verrechnungsschrittintervall" enthalten, das einen Wert enthält, der das geltende Verrechnungsschrittintervall als Vielfaches einer systemweiten Variablen definiert, die als "kleinstes Verrechnungsschrittintervall" bezeichnet wird. Diese Variable ist als konstanter Wert, der ein Zeitintervall mit systemweiter Bedeutung bestimmt, konfigurierbar. Wenn das kleinste Verrechnungsschrittintervall eine Sekunde ist, bedeutet ein Wert von 60 in dem Feld "Verrechnungsschrittintervall" des PPR, das die Verrechnung für diesen Kunden minutenweise erfolgt. Jeder PPR enthält mindestens das persönliche Prepaid-Konto 42 sowie den Prepaid-Konto-Dekrementierer 44, worin die derzeitige Geschwindigkeit (Rate) des Ausgebens von Verrechnungseinheiten gehalten wird. Der Einfachheit halber gilt, wenn das Feld "Verrechnungsschritte" nicht in dem PPR vorliegt, ein Vorgabewert von einer Sekunde. Zusätzlich enthält die Datenbank ein Konto (Dienstanbieter-Umsatz), zu dem die Verrechnungseinheiten transferiert werden, wenn sie in den individuellen persönlichen Prepaid-Konten dekrementiert werden – als Alternative kann man mehrere Konten verwenden, um den Umsatz gemäß der Kostenstruktur des Dienstanbieters oder gemäß anderen Kriterien, die flexibel durch den Dienstanbieter konfiguriert werden können, auf mehrere Konten zu verteilen.
Der PPR enthält die beiden oben erwähnten Steuerfelder, d.h. das persönliche Steuerfeld 52 und das dynamische Steuerfeld 54. Diese Steuerfelder (einschließlich optionaler Erweiterungen) bestimmen wie die SMA 14 in jedem Verrechnungsschritt mit dem PPR 36 umgeht. Das persönliche Steuerfeld ist statisch und kann nicht durch die SMA verändert werden, und das dynamische Steuerfeld ist dynamisch und kann durch die SMA verändert werden. Das persönliche Steuerfeld enthält vorkonfigurierte Steuerelemente, während das dynamische Steuerfeld das dynamische Verhalten innerhalb einer Nutzersitzung steuert.
Das persönliche Steuerfeld:

Bit 1: Wenn es auf 0 gesetzt ist, arbeitet es im globalen Prepaid-Modus, wenn es auf 0 gesetzt ist, arbeitet es im persönlichen Prepaid-Modus. Im persönlichen Modus darf die SMA Verrechnungseinheiten aus dem Prepaid-Konto in dem PPR in einem Verrechnungsschritt nur zu einem oder mehreren anderen Konten in demselben PPR transferieren.
Bit 2: Wenn es auf 0 gesetzt ist, bedeutet es einfache Konten (alle Konten weisen dieselbe MPS-Einheit auf, es gelten keine Konto-Einschränkungen. Wenn es auf 1 gesetzt ist, besteht für jedes Konto ein zusätzliches Datenbankfeld, das als Konto-Steuerfeld bezeichnet wird. Es kann ein getrenntes Feld sein, oder eine Anzahl von Bit aus dem Dekrementierer-Feld, wodurch der Wertebereich des Dekrementierer-Felds produziert wird. Wenn es vorliegt, bestimmt das Konto-Steuerfeld, in welchen Verrechnungseinheiten das Konto betrieben werden kann. Beim Betrieb im Misch-MPS-Einheit-Modus verwendet die SMA eine Umsetzungstabelle zum Umsetzen aus einer MPS-Einheit in eine andere in jedem Verrechnungsschritt wenn notwendig. Diese Umsetzungstabelle (die die geltenden Umrechnungstarife enthält), können dynamisch sein und können über eine externe B2B-Schnittstelle (eine der Schnittstellen 34 in 1) geändert werden. Das Konto-Steuerfeld kann auch Begrenzungen für das Konto bestimmen, z.B. ob ein Konto und ein assoziiertes Dekrementiererfeld niemals verkleinert werden können, oder ob es niemals vergrößert werden kann, z.B. durch eine externe Schnittstelle.
Bit 3: Wenn es auf 0 gesetzt ist: Erweiterter Modus (für jedes Konto gibt es ein variables Dekrementiererfeld). Wenn es auf 1 gesetzt ist: Simplistischer Modus, d.h. es liegen keine Dekrementiererfelder vor, alle Dekrementierer betragen 1 Einheit und können nicht geändert werden, d.h. die SMA subtrahiert in jedem Verrechnungsschritt den Wert 1 von den jeweiligen Konten.
Bit 4: reserviert
Bit 5: Wenn es auf 0 gesetzt ist, beginnt eine Sitzung mit dem Vorgabemodus, wenn es auf 1 gesetzt ist, beginnt die Sitzung mit einer speziellen Startperiode (Website 28).
Bit 6: Wenn es auf 0 gesetzt ist, gilt keine "Übergangsperiode", wenn es auf 1 gesetzt ist, gilt eine Übergangsperiode, nachdem das Prepaid-Konto erschöpft wurde.
Bit 7: Wenn es auf 0 gesetzt ist, gilt globaler Werbemodus, wenn es auf 1 gesetzt ist, gilt der persönliche Werbemodus.
Bit 8: Wenn es auf 0 gesetzt ist: Das Dekrementiererfeld basiert nicht auf Volumen, nur auf Zeit. Wenn es auf 1 gesetzt ist: Es gilt ein Prepaid-Dekrementierer auf Volumenbasis, das heißt, die SMA muss den Prepaid-Dekrementierer auf Volumenbasis (PVD) am Ende des Verrechnungsschritts auf 0 setzen und die Volumeneinheiten zu einem Gesamt-Volumen-Konto transferieren. Dabei wird angenommen, dass das Netzwerkelement Volumeneinheiten weniger oft sendet als Verrechnungsschritte auftreten. Eine auf Volumen basierende Schnittstelle ermöglicht es der NDV 20 Verkehrsvolumenparameter zu messen und den Prepaid-Dekrementierer auf Volumenbasis entsprechend zu setzen. Der PVD ist 0, wenn keine Verkehrsvolumen gemessen werden (somit ändert eine Subtraktion von 0 das Prepaid-Konto nicht). Nachdem der PVD von dem Prepaid-Konto subtrahiert wurde, wird der PVD auf 0 gesetzt, wodurch sichergestellt wird, dass ein benutztes Volumen nur einmal verrechnet wird.
Bit 9: Wenn es auf 0 gesetzt ist, arbeitet das System im globalen Sponsor-Modus, wenn es auf 1 gesetzt ist, arbeitet es in einem persönlichen Sponsor-Modus.
Bit 10: Wenn es auf 0 gesetzt ist, arbeitet das System im globalen Inhaltsmodus, wenn es auf 1 gesetzt ist, arbeitet es in persönlichem Inhaltsmodus.
Bit 11: Wenn es auf 0 gesetzt ist, gilt für diesen Nutzer keine gemeinsam benutzte Werbung, wenn es auf 1 gesetzt ist, gilt sie.
Bit 12: Wenn es auf 0 gesetzt ist, gilt für diesen Nutzer keine exklusive Werbung, wenn es auf 1 gesetzt ist, gilt sie.
Bit 13: reserviert
Bit 14: reserviert
Bit 15: reserviert
Bit 16: Wenn es auf 0 gesetzt ist, liegt kein persönliches Steuerfeld der Erweiterung vor, wenn es auf 1 gesetzt ist, liegt ein solches Feld vor.

Das dynamische Steuerfeld:

Bit 1: Moduswechselanzeige
Bit 2: reserviert
Bit 3: Wenn es auf 0 gesetzt ist, befindet sich der PPR gerade im Vorgabemodus, wenn es auf 1 gesetzt ist, befindet er sich im Nicht-Vorgabe-Modus
Bit 4: Wenn es auf 0 gesetzt ist, befindet sich der PPR gerade im Nicht-Werbungs-Modus (d.h. der Nutzer wird gerade nicht durch einen Werbeblock unterbrochen), wenn es auf 1 gesetzt ist, befindet sich der PPR in dem Werbungsmodus, d.h. der Nutzer wird durch einen Werbeblock unterbrochen.
Bit 5: Wenn es auf 0 gesetzt ist, befindet sich der Nutzer gerade nicht im Startmodus, wenn es auf 1 gesetzt ist, befindet er sich im Startmodus.
Bit 6: Wenn es auf 0 gesetzt ist, befindet sich der Nutzer gerade nicht in einer "Übergangsperiode", wenn es auf 1 gesetzt ist, befindet sich der Nutzer gerade in der Übergangsperiode (er sieht nur die Website 32).
Bit 7: Wenn es auf 0 gesetzt ist, befindet sich der Nutzer gerade nicht im Werbungs-Modus, wenn es auf 1 gesetzt ist, befindet er sich im Werbungs-Modus.
Bit 8: reserviert
Bit 9: Wenn es auf 0 gesetzt ist, arbeitet es im globalen Sponsor-Modus, wenn es auf 1 gesetzt ist, arbeitet es im persönlichen Sponsor-Modus.
Bit 10: Wenn es auf 0 gesetzt ist, arbeitet es im globalen Inhaltsmodus, wenn es auf 1 gesetzt ist, arbeitet es im persönlichen Inhaltsmodus.
Bit 11: Wenn es auf 0 gesetzt ist, befindet sich der PPR gerade nicht in einem Premium-Modus (z.B. Zugriff auf Premium-Inhalt), wenn es auf 1 gesetzt ist, befindet er sich gerade im Premium-Modus und deshalb muss ein Konto, das die maximale Premium-Zeit begrenzt, dekrementiert werden.
Bit 12: Wenn es auf 0 gesetzt ist, befindet sich der PPR gerade nicht in einem Sponsor-Modus, wenn es auf 1 gesetzt ist, befindet er sich gerade im Sponsor-Modus. Damit kann man die Dauer einer Sponsor-Modus-Teilsitzung begrenzen.
Bit 13: reserviert
Bit 14: reserviert
Bit 15: reserviert
Bit 16: Wenn es auf 0 gesetzt ist, liegt kein dynamisches Steuerfeld der Erweiterung vor, wenn es auf 1 gesetzt ist, liegt ein dynamisches Steuerfeld der Erweiterung vor.

Alle Konten eines PPR, die die jeweiligen Dekrementiererfelder enthalten, können so gewählt werden, dass sie eine der folgenden Verrechnungseinheiten aufweisen: lokale Währung des Nutzers, eine andere Währung, Bonuspunkte eines Kundenloyalitätsprogramms, Bonuspunkte, die gekauft oder anderweitig erworben werden können, z.B. über E-Commerce-Aktivitäten oder durch Anschauen von Werbung, existieren Loyalitätsprogrammeinten, wie z.B. Airmiles, Belohnungen usw., neue Bonusprogramme, Werbe-"Meilen", die eine Einheit für flexible Verrechnung mit Werbenden spezifizieren (die Ausstrahlung eines Werbespots in eine Hauptzeit kann mehr Werbe-Meilen pro Sekunde als während einer anderen Tageszeit kosten, für den Kunden unsichtbare Einheiten, wie zum Beispiel Profitabilitäts-Meilen, die dem Kunden verborgen sind, aber Einfluss auf die Dienstgüte haben, die der Kunde innerhalb der Grenzen seines Vertrages erhält, unsichtbare Verrechnungs-Meilen, mit denen eine Rechnung für Kunden produziert werden, bei denen es sich nicht um Prepaid-, sondern um Postpaid-Mikrobezahlungseinheiten von einem beliebigen Mikrobezahlungssystem auf dem Markt oder um neue Mikrobezahlungssystemeinheiten handelt, Meilen mit vagem Wert, wo bei der genaue Wert der Meile von der Tageszeit oder anderen Kriterien verschieden sein können, die für den Benutzer oder Eigentümer der Meile nicht transparent sind. Falls die MPL parallel mit mehreren Verrechnungseinheiten oder im Mischmodus zwischen Prepaid-Meilen und Währungen arbeitet, besitzt jedes Konto auch ein Feld, das die für dieses Konto geltende Währung angibt. Das System kann auch eine systemweite konfigurierbare Umsetzungstabelle zum Umsetzen zwischen verschiedenen Formen von Verrechnungseinheiten enthalten. Diese Umsetzungstabelle kann über zusätzliche Parameter und Schnittstellen zu anderen Systemen, wie zum Beispiel durch die B2B-Schnittstelle 34, manipuliert werden, um es zu ermöglichen, dass die Tabellenkalkulation nicht linear ist, und das Umsetzungsergebnis kann abhängig von der Tageszeit oder anderen Faktoren, unterschiedlich sein, wie zum Beispiel abhängig von einem Echtzeitkurs, der auf einer B2B-Börse für Verrechnungseinheiten auf einem Markt bestimmt wird, der der Börse NASDAQ ähnlich ist, aber 24 Stunden rund um die Uhr handelt.
In jedem Verrechnungsschritt subtrahiert die MPL von allen PPR aktiver Nutzer den tatsächlichen Wert aller Prepaid-Dekrementiererfelder von ihren assoziierten Prepaid-Konten und transferiert denselben Wert zu einem anderen Konto in dem System (im persönlichen Modus ist dieses Konto auch Teil desselben PPR, bei der globalen Variante kann dieses Konto als Alternative ein systemweites Konto sein).
Zusätzlich zu dem Kunden-Prepaid-Konto kann es zusätzliche Konten in dem PPR und systemweit in dem MPS geben, die nach demselben Prinzip wie das Kunden-Prepaid-Konto arbeiten. Das heißt, sie besitzen ein assoziiertes Dekrementiererfeld (sogenannte uneingeschränkte Dekrementiererfelder), wobei der Dekrement-Wert ein negativer Wert werden kann was zu einer Zunahme in dem assoziierten Konto führt, während die Subtraktion in dem Verrechnungsschritt erfolgt (und zu einer assoziierten Abnahme in dem Zähler-Konto, das ein Sponsor-Konto sein könnte). Bestimmte Konten können als eingeschränkte Konten klassifiziert werden. In diesem Fall stellt die MPL automatisch sicher, das sich der Konto-Wert nur in einer Richtung ändern kann, d.h. entweder immer während eines Verrechnungsschritts zunimmt (oder auf demselben Wert bleibt) oder während eines Verrechnungsschritts abnimmt (oder auf demselben Wert bleibt). Ein Sponsor-Konto ist gewöhnlich ein Konto, das nur während eines Verrechnungsschritts abnimmt (während es zu einer Zunahme in den Konten führt, die von dem Sponsor Nutzen ziehen).
Der PPR kann auch Konten enthalten, die zur Steuerung von Werbeblöcken verwendet werden. Der Benutzer hat normalerweise ein Vorgabeprofil, das am Anfang der Sitzung angewandt wird. Dem Vorgabeprofil kann ein Profil vorausgehen, das den Nutzer beim Start zu einer bestimmten Homepage zwingt. Diese könnte das "Inhalts- und Richtlinienauswahlportal" 30 sein, oder die Startperioden-Website 28, die den Nutzer zu der Website eines Sponsors oder zu einem anfänglichen Werbespot leitet. Nach der optionalen Startperiode (die durch ein Startperioden-Konto mit assoziiertem Dekrement gesteuert wird) wird der Nutzer in sein Vorgabeprofil zugewiesen. Wenn der Nutzerdienst Unterbrechung durch Werbeblöcke umfasst, liegt ein Konto vor, das die Zeit steuert, bis die Teilsitzung mit dem Vorgabeprofil endet und ihr ein Werbeblock folgt. Dieses Konto wird als Vorgabeprofil-Konto bezeichnet und dient zusammen mit seinem assoziierten Dekrementiererfeld zur Steuerung der Zeit zwischen Werbeblöcken, in der der Nutzer sein Vorgabeprofil zugewiesen bekommt. Das Vorgabeprofil könnte ihm zum Beispiel erlauben, frei im Internet zu surfen. Als Alternative kann das Vorgabeprofil den Nutzer auf einen sehr einfachen Dienst beschränken, wie zum Beispiel Zugang nur zu Webseiten über http. In diesem Fall kann uneingeschränkter Internetzugang als Premium-Dienst angeboten werden. Es steht dem Dienstanbieter frei, das Vorgabeprofil gemäß den Marktanforderungen zu definieren. Wenn das Vorgabeprofil dieses Kontos erschöpft ist, wechselt die Sitzungsmanageranwendung 14 das Profil des Nutzers in das Profil des ersten Werbespots in dem Werbeblock um und transferiert den PPR in den Werbungs-Modus. Das Umwechseln zu dem Werbungs-Modus wird automatisch durch die Sitzungsmanageranwendung durchgeführt. Die Dauer des Werbeblocks wird durch das Konto "Werbeblock-Dauer" und sein assoziiertes Dekrementiererfeld bestimmt. Die Dauer des Werbeblocks kann somit entweder als Zeit (Vorgabe: Sekunden) gemessen werden, oder als Verrechnungseinheiten, darunter speziell erzeugte Werbe-Meilen. Das Zähler-Konto in der persönlichen Variante ist ein PPR-Konto, bei dem die Menge an konsumierter Werbung pro Kunde entweder als Zeit oder in Verrechnungseinheiten (z.B. Werbe-Meilen) gemessen wird. Das Zähler-Konto ist bei der globalen Variante ein äquivalentes globales Konto für alle aktiven Kunden oder alle Kunden in dem System.
Innerhalb des Werbeblocks ist es möglich, verschiedene Werbespots in einer bestimmten Sequenz einzuteilen, wobei die Dauer des aktuellen Werbespots durch ein "Werbespot-Konto" und seinen assoziierten Dekrementierer gesteuert wird, wenn die Vorgabe von einer Sekunde Dekrement und 1 Sekunde Verrechnungsschritt während Werbeblöcken nicht benutzt wird. Das Dekrement kann als Zeit oder in Verrechnungseinheiten vorliegen. Werbe-Meilen sind eine Option für die Verrechnungseinheit, die zur Faktorierung und Verrechnung mit den Werbefirmen verwendet werden kann. Die Sequenz des Werbespots wird durch einen Zeiger in dem PPR bestimmt, der auf den nächsten Werbespot ver weist. Die Werbespots werden in einer Datenstruktur organisiert, die als Kette oder (optional auch als Ring) bezeichnet werden kann, und die Sequenz in der Kette oder in dem Ring bestimmt die Sequenz des Werbespots. Es kann eine globale Kette oder ein globaler Ring vorliegen, wobei der PPR zu jeder Zeit, die der nächste dem Nutzer zu zeigende Werbespot ist, auf einen spezifischen Werbespot zeigt. Als Alternative kann es eine persönliche Werbedatenstruktur pro PPR (pro Benutzer) geben, die die Sequenz der Werbespots bestimmt, die einem spezifischen Nutzer gezeigt wird, und die für abgezielte Werbung benutzt werden kann, einschließlich der Option, die Sequenz der Werbung abhängig von Ereignissen dynamisch zu ändern.
Der Eigentümer des MPS-Systems kann die Sequenz der Werbespots kundenweise auf flexible und dynamische Weise konfigurieren, und er kann auch während eines Werbespots abhängig von bestimmten Ereignissen die Sequenz ändern.
Während Werbeblöcken werden normale Konten nicht geändert – stattdessen gelten Verrechnungsschritte nur für Werbe-Konten. Wenn die Vorgabe für Werbeschritte gilt, wird nur ein Werbeschritt pro Sekunde ausgeführt, und es werden nur die Werbe-Konten dekrementiert. Wenn die Vorgabe nicht gilt, gilt das folgende allgemeinere Verfahren: In jedem Werbeschritt wird der Wert des assoziierten Dekrementiererfelds von den Werbe-Konten subtrahiert und zu einem Zähler-Konto transferiert (addiert) (im persönlichen Modus ist ein Werbe-Konto Teil des PPR, im globalen Modus ist es ein systemweites Konto, das die Summe aller konsumierten Werbung sowie die Summe der Sekunden/Dekremente jedes konsumierten Werbespots zusammenfasst). Auf diese Weise ist es im persönlichen Modus möglich, zu sehen, wie viele Werbespots jeder Benutzer im persönlichen Modus angeschaut hat, im globalen Modus ist es nur möglich, zu bestimmen, wieviel Werbung konsumiert wurde und welche Werbespots, aber nicht von welchen Nutzern.
Die Werbenden können zu einem beliebigen Zeitpunkt über das Internet oder eine andere Schnittstelle auf das System zugreifen und den aktuellen Wert des globalen Werbe-Konten anschauen. Auf diese Weise können sie genau die Rate untersuchen, mit der die Werbekampagne von den Nutzern angeschaut wird. Sie können diese Informationen mit parallelen Aktivitäten korrelieren, wie zum Beispiel das Sammeln von Rückmeldungen über Telefonumfragen, Echtzeit-Statistiken über E-Business-Aktivitäten, Verkaufsumsätze usw., um die Kampagne besser abzustimmen. Als zusätzliche Option kann der Systemeigentümer anonymisierte Daten über die Kunden anbieten, die den Werbespot angeschaut haben und/oder die Werbung regional oder auf der Basis anderer anonymisierter Kriterien zurechtschneiden, um eine noch bessere Abstimmung der Werbekampagne zu ermöglichen, wobei in einem gewissen Sinne das Konzept eines regionalen Testmarkts mit zusätzlichen Kriterien, die nicht regional sind, sondern auf bestimmte Verbrauchergruppen als Testmarkt abgezielt sind, auf das Internet erweitert wird.
Die Sitzungsmanageranmeldung 14 läuft regelmäßig (einmal pro Verrechnungsschritt) und wird an allen PPR aktiver Nutzer ausgeführt. Die Funktionsweise der Sitzungsmanageranwendung an einem individuellen PPR wird durch das persönliche Steuerfeld und das dynamische Steuerfeld gesteuert. Aktive Nutzer sind Nutzer, die eine Sitzung begonnen haben, und sie noch nicht beendet haben. Sitzungsstart und Sitzungsende erfolgen durch den RADIUS-Server auf derselben Datenbank. Während die Sitzung aktiv ist, dekrementiert die Sitzungsmanageranwendung in jedem Verrechnungsschritt die entsprechenden Konten (im Vorgabemodus das Prepaid-Konto und das Vorgabeprofil-Konto, im Werbemodus die werbungsbezogenen Konten, im Premium-Modus das Konto maximale Premium-Zeit und das Prepaid-Konto. Im Sponsor-Modus (der mit den anderen Betriebsarten koexistieren kann) dekrementiert sie auch die Sponsor-Konten (global oder persönlich) und transferiert die Sponsor-Verrechnungseinheiten zu dem Nutznießer.
Das "Inhalts- und Richtlinienauswahlportal" 30 (PSP) ist eine Benutzeroberfläche, über die der Benutzer Werte in der persönlichen Nutzerdatenbank ändern kann – wodurch effektiv das Nutzerprofil (und implizit der Dienst) während der Nutzungssitzung geändert wird, was zu dem unmittelbaren oder verzögerten Start einer neuen Teilsitzung mit einem neuen Tarif und potentiell einem neuen Verrechnungsmodus führt. Dadurch kann der Nutzer den Verrechnungsmodus innerhalb einer Sitzung ändern, z.B. Wechsel von minutenweiser Verrechnung zu sekundenweiser Verrechnung. Der Nutzer kann sein Prepaid-Konto unter Verwendung des PSP wiederaufladen. Das Prepaid-Konto kann durch den Nutzer über alle üblichen Bezahlungsmethoden geladen und wieder aufgeladen werden (Bargeld, Überweisung, Kreditkarte, Mobil-Karte, Telefonrechnung usw.). Über das PSP kann der Nutzer steuern, sein Nutzerprofil mit sofortiger Auswirkung, einer festen Verzögerung oder gebunden an ein bestimmtes Ereignis zu ändern – einschließlich einer quasi augenblicklichen Tarifänderung. Über das PSP kann der Nutzer das Nutzungsprofil der nächsten Teilsitzung auswählen. Beispiele für Nutzungsprofile sind die folgenden:
Standard: Uneingeschränkte Nutzung, Best-Effort-Dienst, kein Hacker-Schutz, kein Zugang zu geschützten Intranet-Bereichen ohne separate Autorisierung, keine Werbeblöcke, die andere Ak tivitäten blockieren (entspricht im Prinzip den heutzutage am häufigsten benutzten Profilen).
Bronze: Wie Standard, aber mit tolerierten Werbeblöcken in bestimmten Intervallen, die andere Aktivitäten während des Werbeblocks blockieren.
Silber: Wie Bronze, aber mit verbesserter QoS (Dienstgüte), z.B. mit höherer Bandbreite zum Backbone und in dem Backbone für diesen Nutzer, in dem dem Verkehr dieses Nutzers relativ zu Bronze-Dienst-Nutzern und Standard-Dienst-Nutzern Nutzerprioritätsbehandlung gegeben wird, oder durch Geben von absoluten Bandbreitengarantien.
Gold: Wie Silber, aber ohne Unterbrechung durch Werbeblöcke.
Kinder: Wie Bronze, aber mit Inhaltsfilterung in Bezug auf unerwünschten Inhalt und nur mit für Kinder geeigneter Werbung.
Gold-Sicher: Wie Gold, aber mit einer speziellen Firewall auf Netzwerk-Basis, die vor bestimmten beliebten Hacker-Methoden schützt (z.B. mit Anti-Spoofing-Schutz).
IP-VPN/Intranet: Uneingeschränkte Nutzung, potentiell mit Premium-QoS über garantierte Bandbreite oder Diff-Serv-Priorisierung beim Zugang zu einem Firmennetzwerk, automatische Mitgliederschaft ohne separate Autorisierung.
Werbe-Block: Für die Dauer des Werbe-Blocks ist die Nutzung auf den Konsum von Werbung in einer Sequenz von Werbespots beschränkt, die dynamisch geändert werden kann (hinzuzufügen: freiwilliges Anschauen von Werbung).
Werbespot-Firma X: Eingeschränkte Nutzung (nur bestimmte IP-Adressen oder Web-Server, die die Werbung oder eine Teilmenge davon hosten. Potentiell zusätzlich Zugang zu verknüpften Webseiten von Produkten, für die geworben wird, für direkte E-Business-Aktivitäten.
Gesponserte Seite der Firma Y: Eingeschränkte Nutzung, beschränkt auf bestimmten Inhalt oder bestimmte Web-Server, z.B. kostenlosen Zugang für Banktransaktionen mit der Bank Y, die das Prepaid-Konto nicht dekrementieren, so lange der Nutzer nur auf gesponserten Inhalt zugreift. Sobald der Nutzer den gesponserten Sektor verlässt, d.h. eine nicht unter dem gesponserten Nutzerprofil abgedeckte Aktivität beginnt, wird er gewarnt, dass er den gesponserten Sektor verlässt und dass von nun an der Vorgabetarif in dem nicht gesponserten Sektor gel ten wird. Rückkehr zu dem gesponserten Sektor ist über Auswahl in dem PSP möglich.
Gesponsert durch Firma Z: Begrenzte Nutzung, Zugang nur zur Firma Z und zu Inhalt, den die Firma Z sponsern will. Das Prepaid-Dekrement ist negativ, da Firma Z tatsächlich den Nutzer für den Zugriff auf ihren Inhalt bezahlt. Firma Z bezahlt entsprechend den Eigentümer des MPS.
Prepaid-Konto erschöpft: Es gibt zwei Varianten, wie die Erschöpfung eines Prepaid-Konten gehandhabt werden kann:

1: Der Nutzer wird sofort von den Dienst getrennt und gegebenenfalls (z.B. in Einwähl-Szenarien) auch von dem Netzwerk.
2: Wenn der Systemeigentümer es auf diese Weise konfiguriert hat, kann dem Nutzer eine letzte Übergangsperiode gegeben werden, in der er vor bevorstehender Trennung gewarnt wird und eine letzte Chance erhält, sein Prepaid-Konto wiederaufzuladen. Sein Nutzerprofil wird darauf begrenzt, die Warnung über bevorstehende Trennung und über Wiederaufladen seines Prepaid-Konto (Website 32) anzuschauen. Wenn die letzte Übergangsperiode abläuft, ohne dass das Konto wieder aufgeladen wird, wird der Nutzer von dem Dienst und gegebenenfalls auch von dem Netzwerk getrennt.

Premium-Inhalt Gold erlaubt: Nutzung erlaubt zu allem Inhalt, einschließlich Inhalt, der als Gold, Silber und Bronze klassifiziert ist. Möglichkeit zum Zugriff auf mehrere Inhalte mehrerer Klassen parallel.
Premium-Inhalt Silber erlaubt: Nutzung erlaubt zu allem Inhalt, einschließlich Inhalt, der als Silber und Bronze klassifiziert ist. Möglichkeit zum Zugriff auf mehrere Inhalte mehrerer Klassen parallel.
Premium-Inhalt Bronze erlaubt: Nutzung erlaubt zu allem Inhalt, einschließlich Inhalt, der als Bronze klassifiziert ist. Möglichkeit zum Zugriff auf mehrere Inhalte mehrerer Klassen parallel.
Premium-Inhalt exklusiv: Nutzung begrenzt auf den Zugang auf Premium-Websites eines bestimmten Inhaltsanbieters oder nur auf sehr spezifischen Inhalt, wie zum Beispiel ein Baseballspiel, aber nicht parallel auf anderen Inhalt. Der Inhaltsanbieter kann entscheiden, Zugang zu verwandten Websites zu erlauben, wie zum Beispiel E-Commerce-Sites in Bezug auf den Premium-Inhalt (z.B. DVD-Kauf eines Films nach dem Anschauen einer Streaming-Media-Vorschau). Wenn der Nutzer andere Akti vitäten einleitet, wird er gewarnt, dass er versucht, den exklusiven Premium-Inhaltsbereich zu verlassen und dass er bestätigen soll, dass er zu dem Vorgabedienstprofil zurückkehren (oder mit dem Premium-Inhalt fortfahren möchte).
Am Anfang einer Nutzungssitzung wird der Nutzer mit einem bestimmten Profil autorisiert, dass als sein Vorgabeprofil bezeichnet wird. Der Nutzer kann in der Lage sein, sein Vorgabeprofil zu ändern. Der Nutzer kehrt zu seinem Vorgabeprofil zurück, wenn er eine maximale Zeit spezifiziert, die er in einem Premium-Tarif-Profil verbringen möchte. Der Nutzer kann ein neues Profil aus einer Auswahl vorkonfigurierter Profile mit dem PSP 30 auswählen und zu beliebiger Zeit während der Sitzung eine neue Teilsitzung starten. Nutzerprofile werden in der NDV 20 vorkonfiguriert, so dass die Kommunikation zwischen dem PSP und der NDV in den meisten Fällen nur das gewählte Profil übermitteln muss, außer wenn eine Nutzerrichtlinie das Weitergeben zusätzlicher Parameter zum Instruktionszeitpunkt erfordert.
In Verbindung mit dem Sponsern kann jeder Nutzer ein Sponserungs-Empfänger-Konto besitzen, auf das durch die externe B2B-Schnittstelle 34 zugegriffen werden kann. Dieses Konto kann von Dritten vergrößert werden (so genannten "einfachen Sponsoren" wie zum Beispiel Werbenden im Austausch für einen Seiteneindruck oder einen Besuch einer Website des Werbenden. Als Alternative kann der Sponsor die Möglichkeit haben, das Prepaid-Konto direkt zu vergrößern.
Ferner kann eine Sponserungs-Schnittstelle mit der Möglichkeit zum Ändern des Nutzerprofils bereitgestellt werden. Diese Schnittstelle hat Zugang zu dem Prepaid-Dekrementiererfeld 44 dergestalt, dass der Sponsor den Wert des Dekrementiererfelds (der zeitabhängig ist) und potentiell auch ein volumenabhängiges Dekrementiererfeld vermindern kann. Wenn der Dekrementierer 0 wird, repräsentiert dies effektiv ein volles Sponsern des Dienstes, also effektiv einen vom Sponsor bezahlten "kostenlosen" Dienst. Es ist auch teilweises Sponsern möglich. Wenn der Wert des Dekrementierers negativ wird, geht der Sponsor sogar noch weiter und bezahlt Verrechnungseinheiten in die Taschen des Nutzers (in sein Prepaid-Konto in jedem Verrechnungsschritt, da die Subtraktion eines negativen Werts das Prepaid-Konto vergrößert). Die Sponserungs-Schnittstelle darf das Nutzerprofil im Austausch für das Sponsern während der gesponserten Teilsitzung ändern. Beispielsweise kann die Sponserungs-Schnittstelle den Nutzer zwingen, nur in der Lage zu sein, auf bestimmte Websites zuzugreifen oder bestimmte Dienste zu nutzen, während andere Websites oder Dienste für die Dauer der gesponserten Teilsitzung blockiert werden. Dieses Merkmal ermöglicht die Implementierung eines effektiven Werbungs-Finanzierungsverfahrens mit der Implementierung von Werbeblöcken, die dem Unternehmensmodell des kostenlosen TV ähneln.
Wenn der Nutzer versucht einen gesponserten Sektor zu verlassen, d.h. wenn er gegen die im Namen des Sponsors im Austausch für das Sponsern gesetzte Richtlinie verstößt, wird er zu einer Sponsor-Ausgangs-Website geleitet. Hier wird der Nutzer gewarnt, dass er den gesponserten Sektor verlässt, und erhält Gelegenheit, im gesponserten Sektor fortzufahren oder wird zu dem Richtlinienauswahlportal 30 weitergeleitet.
Wahlweise kann ferner eine E-Unternehmenstransaktionsschnittstelle (B2B-Schnittstelle) bereitgestellt werden, die der Nutzer zur Bezahlung an anderen Websites, wie zum Beispiel Auktions-Sites oder Tausch-Sites verwenden kann. Die Transaktion für Bezahlung oder Tausch oder Austausch oder Aktion oder Spenden kann in einer beliebigen der Verrechnungseinheiten ausgeführt werden, außer Zeit und Einheitswert 1. Dies kann für Mikrotransaktionen verwendet werden (z.B. Mikrobezahlung, Mikrotausch, Mikroauktion, Mikroaustausch, Mikrospenden). Ein Sponsor könnte spezifizieren, dass 1 MPS-Einheit (z.B. eine Prepaid-Meile) mit jedem angeschauten Werbespot einem dritten gespendet wird, wie zum Beispiel einer Nicht-Regierungs-Organisation wie Greenpeace. Beim Anschauen oder anderweitigen Konsumieren von Premium-Inhalt, wie zum Beispiel Musik, kann der Zuschauer eine Möglichkeit haben, direkt an den Künstler zu spenden, der das angeschaute oder anderweitig konsumierte intellektuelle Eigentum erstellt hat. Diese Schnittstelle kann auch zur Beeinflussung des Werts von Verrechnungseinheiten über dynamische Umsetzungstabellen verwendet werden.
Um einen Eindruck zu geben, wie das oben beschriebene System vom Standpunkt des Nutzers erscheinen kann, zeigt 5 ein Beispiel für ein Nutzerschirmbild 82. Wie gewöhnlich wird der Hauptteil des Schirmbilds von der Webseite 84 eingenommen, die der Nutzer gerade besucht. In dem gezeigten Beispiel wird angenommen, dass diese Webseite 84 eine Seite ist, die von einer Firma XY gesponsert wird. Unter der Webseite 84 informiert eine Nachricht 86 den Nutzer über das Dienstprofil, das er gerade benutzt. Im vorliegenden Fall lautet die Nachricht 86: "Gesponsert von Firma XY". Somit wird der Nutzer informiert, dass er die Webseite 84 für einen reduzierten Preis oder sogar kostenfrei betrachtet. Wahlweise kann auch der aktuelle Tarif angegeben werden.
Der Nutzer kann eine Schaltfläche 88 "Profil wechseln" anklicken, wenn er zu einem anderen Dienstprofil wechseln möchte.
Dann wird der Nutzer zu dem in 1 gezeigten Inhalts- und Richtlinienauswahlportal 30 geleitet.
Eine weitere Schaltfläche 90 "Konten ansehen" erlaubt es dem Nutzer, den aktuellen Status seines Prepaid-Kontos und etwaiger möglicher anderer Konten zu prüfen. Die auf diese Weise zur Verfügung gestellten Informationen werden im Wesentlichen in Echtzeit aktualisiert, d.h. nach jedem Verrechnungsschrittintervall.
Eine Nachricht 92 gibt den aktuellen Tarif an, und mehrere Schaltflächen 94 stellen Abkürzungen für einen schnellen Wechsel zu anderen Profilen bereit, wie zum Beispiel "Privatsphäre", "Verrechnungsmöglichkeit", "Gold" und "Silber".
6 bis 10 zeigen eine weitere Ausführungsform der Erfindung. Diese Ausführungsform hat die Form eines Echtzeit-Abrechnungssystems, das sowohl für Prepaid als auch für Postpaid verwendbar ist. Als ausgezeichnetes Merkmal eignet sich diese Ausführungsform für Abrechnung auf Volumenbasis in Echtzeit, einschließlich Abrechnung für Tarife, die eine Mischung von Zeittarifen und Volumentarifen umfassen, und für Tarife, die mehrere differenzierte Tarife für Pakete abhängig von dem Pakettyp umfassen. Der Pakettyp kann gemäß den in dem Paket enthaltenen Informationen differenziert werden, darunter Richtung des Pakets, Typ des Teilnehmers (falls in einem Teilnehmer-IP-Adressenbereich codiert), Ziel, Informationen von Schicht 4 bis 7, wie zum Beispiel benutztes Protokoll oder benutzter Port, URL, auf die zugegriffen wird, usw.
In der IP-Welt besteht eine zunehmende Nachfrage nach Systemen zur Abrechnung auf Volumenbasis, da diese Art der Abrechnung im Gegensatz zu Festgebühren als risikogerechte und viel versprechende Möglichkeit zur Erzielung von Anlagenrenditen an IP-Diensten höheren Werts angesehen wird. Ein effizientes System zur Echtzeit-Abrechnung auf Volumenbasis konnte jedoch bisher aus einer Anzahl praktischer Gründe noch nicht implementiert werden, die kurz gefasst durch die extreme Komplexität des Datenverkehrs verursacht werden, die bei herkömmlichen Ansätzen zu einem unvernünftigen Overhead für das Abrechnungssystem und zu einer unerwünschten Fragmentierung des Datenflusses und der Abrechnungsprozeduren führen würde.
Die hier vorgeschlagene Ausführungsform liefert eine Lösung dieser Probleme und ist zusätzlich weithin in vielfältigen existierenden Standards kompatibel. Sie ist in existierenden Netzwerkarchitekturen leicht zu implementieren und ermöglicht dennoch viel Flexibilität und Skalierbarkeit.
Das Schlüsselkonzept des hier vorgeschlagenen Ansatzes besteht darin, dass die Verrechnung genau an dem Ort erfolgen sollte, an dem die Datenpakete zwischen dem Nutzer und dem Netzwerk weitergeleitet werden, da an diesem Ort die notwendigen Informationen über das Volumen, den Ursprung und das Ziel der Datenpakete verfügbar sind. Folglich können die Verrechnungsprozeduren ohne weiteres durchgeführt werden, ohne dass zusätzlicher Datenverkehr oder anderes Overhead zum Sammeln der erforderlichen Informationen notwendig sind.
Wenn man 6 mit 1 vergleicht, sieht man, dass die multifunktionale Prepaid-Logik (MPL) 10 von 1 durch ein Echtzeit-Abrechnungssystem (RTB) 100 ersetzt wurde, das nun jedoch in die Netzwerkdienstvermittlungsanlage (NDV) 20 integriert ist. Andererseits wurden die persönliche Nutzerdatenbank 12 und der RADIUS-Server 16 für Authentifizierungszwecke aus dem RTB 100 entfernt und wurden als separate Entitäten eingerichtet.
Das in 6 gezeigte Echtzeit-Abrechnungssystem 100 kann alle oben in Verbindung mit der multifunktionalen Prepaid-Logik 10 besprochenen Funktionen ausführen, einschließlich der Verrechnung auf Zeitbasis mit in regelmäßigen Verrechnungszeitintervallen ausgeführten Verrechnungsschritten. Zusätzlich ist das in 6 gezeigte System jedoch auch dafür ausgelegt, abhängig von dem Volumen, dem Typ, dem Ursprung und dem Ziel der durch die NDV 20 gehenden Datenpakete zur Ablieferung zu oder von dem Benutzer 18 Abrechnung auf Volumenbasis durchzuführen. Der geltende Gebührentarif kann von Typ und Ziel oder Ursprung und daher auch von der Flussrichtung der Datenpakete abhängen, sowie es in einer sogenannten Abrechnungsrichtlinie festgelegt wird, wofür ein Beispiel in 7 gezeigt ist.
Die Abrechnungsrichtlinie ist eine Datenstruktur oder ein Programmobjekt mit einem Kopfteil 102 und einem Hauptteil 104. Zu Darstellungszwecken kann angenommen werden, dass die in 7 gezeigte Abrechnungsrichtlinie für ein Prepaid-System gilt. Der Kopfteil 102 spezifiziert die Daten, die für normale Abrechnung auf Zeitbasis erforderlich sind, d.h. eine Variable "Time_unit_interval", die das Verrechnungszeitintervall spezifiziert (z B. eine Minute oder eine Sekunde), eine Variable "Time_unit_Rate_Type", die einen Bezahlungstyp spezifiziert, und eine Variable "Time_unit_Rate", die den für jedes Zeitintervall, in dem der Dienst benutzt wurde, zu berechnenden Tarif spezifiziert. Die Variable "Time_unit_Rate" entspricht dem Eintrag in das Dekrementiererfeld 44 bei der vorherigen Ausführungsform.
Die Variable "Time_unit_Rate_Type", die den Bezahlungstyp spezifiziert, implementiert ein neues Konzept, das weiter erläutert werden muss. Diese Variable zeigt auf eine Datenstruktur oder ein Objekt, die bzw. das die Grundparameter des Bezahlungs- und Verrechnungsprozesses spezifiziert, darunter zum Beispiel den Abrechnungsmodus (Prepaid oder Postpaid), die Kreditquelle, d.h. wie Finanztransaktionen zwischen dem Teilnehmer und dem Dienstanbieter gehandhabt werden sollen, die verwendete Kreditwährung, z.B. Euro, US-Dollar, Zeiteinheiten, Loyalitätspunkte und dergleichen, die Kreditgranularität, z.B. 0,00001 Euro im Fall von Euro-Währung, logische Variablen, die steuern, ob negative oder positive Kredite erlaubt sind oder nicht und dergleichen. Die Kreditquelle kann zum Beispiel in Form eines persönlichen Konto des Teilnehmers oder in Form einer IP-Adresse oder Subadresse einer Behörde vorliegen, die die Finanztransaktionen verwaltet, zusammen mit einer Identifikation des Teilnehmers.
Bei dem oben in Verbindung mit 2 bis 5 beschriebenen Beispiel besaß jeder Teilnehmer nur ein einziges persönliches Konto, d.h. das persönliche Prepaid-Konto 42, und es galt für alle Nutzer ein systemweiter Bezahlungstyp. Das Konzept variabler Bezahlungstypen fügt mehr Flexibilität zu dem System hinzu und ermöglicht die Versorgung unterschiedlicher Ansprüche der Nutzer, darunter die Möglichkeit, dass ein Nutzer mehrere nach ihrem Bezahlungstyp differenzierte Konten besitzt. Es wird somit ein und demselben Benutzer möglich, parallel verschiedene Bezahlungstypen zu benutzen und den Bezahlungstyp abhängig von dem genutzten Dienst auszuwählen.
Der Hauptteil 104 der in 7 gezeigten Abrechnungsrichtlinie listet eine Anzahl von Bezahlungsregeln 106 auf, die jeweils durch eine einzige Zeile repräsentiert werden. Die Bezahlungsregeln 106 werden für Abrechnung auf Volumenbasis verwendet, indem für jedes Datenpaket, das durch die NDV 20 zu oder von dem Nutzer 18 übertragen wird, ein Tarif oder Preis bestimmt wird. In dem gezeigten Beispiel werden die individuellen Datenpakete nach ihrer Quelle, nach Ziel und Typ des Dienstes (z.B. HTRP, E-Mail, WAP und dergleichen) differenziert. Wenn ein Paket durch die NDV 20 fließt, wird die geltende Bezahlungsregel identifiziert, indem die erste der Zeilen ausgewählt wird, für die die Einträge in den ersten drei Spalten "Quelle", "Ziel" und "Dienst" mit dem Datenpaket übereinstimmen. Dann identifizieren die Einträge in der Spalte "Aktion" dem Bezahlungstyp und den Tarif, die für dieses Datenpaket gelten. Die Spalte "statistischer Zähler" identifiziert einen mit der Bezahlungsregel assoziierten Zähler zum Zählen der Datenpakete für statistische Zwecke. Die Inhalte dieser statistischen Zähler können dem Benutzer abhängig von der gewählten Privatsphärenrichtlinie zur Verfügung gestellt werden oder auch nicht.
Es versteht sich, dass das Konzept der Bezahlungsregeln beim Zuweisen verschiedener Tarife (und sogar Bezahlungstypen) zu den verschiedenen Datenpaketen abhängig von ihrem Ursprung, ihrem Ziel und dem Diensttyp sehr viel Flexibilität gewähren. Zum Beispiel können für Datenpakete, die von verschiedenen Inhaltsanbietern kommen, verschiedene Tarife berechnet werden.
Wie in der vierten Zeile des Hauptteils 104 in 7 exemplifiziert wird, kann eine einzelne Bezahlungsregel sogar zwei verschiedene Bezahlungstypen und Tarife umfassen, die ein und demselben Datenpaket zugewiesen werden. Dieses Merkmal kann zum Beispiel benutzt werden, wenn der Dienst gesponsert wird, so dass einem Sponsor ein erster Tarif berechnet wird und nur der Rest der Kosten (zweiter Tarif) dem Nutzer berechnet wird. Als ein weiteres Beispiel kann der zweite Tarif Loyalitätspunkte spezifizieren, die dem Nutzer dafür angerechnet werden, dass er diesen spezifischen Dienst genutzt hat.
Während bei der vorherigen Ausführungsform jeder Nutzer nur ein einziges Prepaid-Konto 42 besaß und der Gebührentarif eindeutig durch die Inhalte des Prepaid-Konto-Dekrements 44 definiert wurde, das nur in Verbindung mit dem Wechsel des Dienstprofils geändert wurde, ermöglicht die vorliegende Ausführungsform dem Nutzer nicht nur verschiedene Kredit-Zähler oder Prepaid-Konten (einen für jeden Bezahlungstyp), sondern gestattet auch die Verwendung verschiedener Tarife für verschiedene Posten sogar innerhalb ein und desselben Dienstprofils.
Es versteht sich, dass die Bezahlungsrichtlinie, wie zum Beispiel die in 7 gezeigte, Teil des vom Nutzer auszuwählenden Dienstprofils bildet, so dass die geltenden Tarife auch gemäß dem ausgewählten Dienstprofil variieren werden.
Ein anderer wichtiger Unterschiede zwischen der zuvor beschriebenen Ausführungsform und der vorliegenden Ausführungsform besteht darin, dass die von dem Abrechnungssystem 100 ausgeführte Verrechnungsoperation nicht unbedingt in regelmäßigen Zeitintervallen ausgeführt wird, sondern ereignisgesteuert ist.
Wie in 8 dargestellt, kann ein erster Schritt 108 der Verrechnungsoperation einerseits durch Zeitereignisse 110 und andererseits durch Paketereignisse 112 ausgelöst werden. Ein Zeitereignis ist ein Ereignis, das den Ablauf des Verrechnungszeitintervalls signalisiert, das in dem Kopfteil 102 der Abrechnungsrichtlinie spezifiziert wurde, und löst den Schritt 108 zur Bestimmung der Zeiteinheitsrate aus, die auch in dem Kopfteil 102 spezifiziert wurde. Ein Paketereignis 112 gibt dagegen die Ankunft eines Datenpakets an, für das ein Tarif gemäß dem Hauptteil 104 der Abrechnungsrichtlinie bestimmt werden muss. Im allgemeinsten Fall wird Schritt 108 somit regelmäßig ausgelöst (jedes Mal nach dem Ablauf des Verrechnungszeitintervalls) und zusätzlich bei der Ankunft jedes Datenpakets, für das ein Tarif berechnet werden muss. Es kann natürlich auch in der Abrechnungsrichtlinie vorgeschrieben werden, dass bestimmte Pakete, z.B. die zu einem spezifischen Diensttyp gehörenden oder die von einem spezifischen Bereich von Datenquellen stammenden oder die zu einem spezifischen Bereich von Zielen gesendeten kostenlos sind und ohne Auslösung einer Verrechnungsoperation durch die NDV 20 geleitet werden.
Streng genommen sollten die in der Abrechnungsrichtlinie spezifizierten Tarife als Rohtarife betrachtet werden, die abhängig von anderen Umständen modifiziert werden können, wie zum Beispiel abhängig von der Tageszeit (TODA; Tageszeit-Abrechnung) oder abhängig von dem aktuellen Ort des Nutzers 18, so dass der letztendlich für den Dienstposten (Dienstzeit oder Paket) berechnete Preis auch von diesen Faktoren abhängen wird. Zu diesem Zweck enthält Schritt 108 in 8 zwei zusätzliche Eingaben 114, 116. Die Eingabe "TODA" 114 repräsentiert die Tageszeit und kann zum Beispiel dazu verwendet werden, den Rohtarif in Zeiten mit hohem Verkehr um einen bestimmten Faktor zu vergrößern oder um den Rohtarif in der Nacht zu reduzieren. Die Eingabe 116 "LOC_CH" gibt einen Wechsel des Orts des Nutzers 18 an, z.B. im Fall von mobilem Zugang, wenn der Nutzer 18 in ein anderes Land roamt oder in eine vordefinierte Heimatzone eintritt, wo ein reduzierter Tarif gilt. Der als Reaktion auf das Zeitereignis 110 oder das Paketereignis 112 spezifizierte Rohtarif kann somit abhängig von der Eingabe 114 mit einem ersten Faktor und abhängig von der Eingabe 116 mit einem zweiten Faktor multipliziert werden. Als Alternative können die Eingaben 114 und 116 auch in Form des Addierens eines konstanten Werts zu dem Rohtarif verarbeitet werden oder durch Modifizieren des Rohtarifs gemäß einer beliebigen anderen Funktion. Innerhalb dieses Rahmens ist es sogar möglich, einen monatlichen Grundtarif zu berechnen, indem man einen diesem Grundtarif entsprechenden Betrag zu dem Preis für den ersten Dienstposten addiert, wenn ein neuer Monat angefangen hat. In jedem Fall ist das Ergebnis von Schritt 108 ein bestimmter Gebührenbetrag 118 (in der durch den Bezahlungstyp spezifizierten Währung), und dem Nutzer wird dieser Betrag für den Dienstposten berechnet, der die Verrechnungsoperation ausgelöst hat. Die Gebühr 118 könnte dann wie bei der vorherigen Ausführungsform von dem persönlichen Prepaid-Konto (dem mit dem spezifizierten Bezahlungstyp assoziierten) abgezogen werden. Bei dem gezeigten Beispiel wurde jedoch aus Sicherheitsgründen eine etwas andere Verrechnungsprozedur verwendet, wie nun in Verbindung mit 9 erläutert werden wird.
Da die Verrechnung in der Netzdienstvermittlungsanlage (NDV) 20 geschieht, die normalerweise von der persönlichen Nutzerdatenbank 12 abgesetzt sein wird, besteht ein Risiko, dass die Daten über die gesamte Verrechnungsprozedur im Fall eines Systemausfalls verloren gehen. Da der Dienstanbieter die Beweislast hat, dass die Dienste tatsächlich geleistet wurden, würde ein solcher Datenverlust den Dienstanbieter beträchtlich schädigen. Aus diesem Grund ist es ratsam, dass mindestens Zwischenergebnisse der Verrechnungsprozedur regelmäßig in einem ausfallsicheren Speicher "gesichert" werden, so wie es bereits in Abrechnungssystemen für Mobiltelefondienste Gang und Gebe ist. Wie in 9 gezeigt, wird ein sogenanntes vereinigtes Prepaid-Konto 120 für jeden Nutzer sicher in einer Datenbank gespeichert, um so vor Datenverlust geschützt zu sein. Diese Datenbank kommuniziert mit dem Abrechnungssystem 100, das sich in der NDV 20 befindet. In dem gezeigten Beispiel wird diese Kommunikation durch eine Bezahlungsvermittlungsinstanz 122 vermittelt, die zum Beispiel durch das Produkt "Nortel Prepaid Data Node" des Anmelders gebildet werden kann und die selbst über ein CTP-Protokoll mit dem Abrechnungssystem 100 kommuniziert.
Nach Logon und Authentifizierung des Benutzers wird ein bestimmter Kreditbetrag, der zum Beispiel einem Wert von 2,00 Euro entsprechen kann, von dem vereinigten Prepaid-Konto 120 zu einem akkumulierten Lease-Register 124 in dem Abrechnungssystem 100 transferiert ("geleast"). Dann besteht die in dem Abrechnungssystem 100 erfolgende Verrechnung im Prinzip daraus, zu prüfen, ob der geleaste Kreditbetrag, der in das Register 124 transferiert wurde, die akkumulierten Gebühren für die Dienstposten immer noch abdeckt. Zu diesem Zweck werden die im Schritt 108 bestimmten Gebühren 118 in einem Kreditzähler 126 addiert (akkumuliert), und es wird geprüft, ob der Kreditzähler 126 eine von mehreren Schwellen TH1, TH2, TH3 und TH4 überschreitet. Die absoluten Höhen der Schwellen sind mit den Inhalten des akkumulierten Lease-Registers 124 verknüpft.
Der Kreditzähler 126 ist ein Objekt, das durch seinen Bezahlungstyp und durch seine Schwellen definiert wird. Jede Schwelle wird durch einen Wert (relativ zu den Inhalten des akkumulierten Lease-Registers 124), eine "Richtung" und eine "Aktion", die unternommen werden muss, wenn der Schwellenwert in der durch den Parameter "Richtung" spezifizierten Richtung (nach oben oder nach unten) überschritten wird, definiert.
Wenn eine Sitzung beginnt, wird eine geeignete Anzahl von Kreditzählern 126 entsprechend der Anzahl der in der Abrechnungsrichtlinie spezifizierten Bezahlungstypen geöffnet.
Wie in 9 symbolisiert, hat das Addieren der Gebühren 118 zu den Inhalten des Kreditzählers 126 den Effekt, dass die niedrigste Schwelle TH1 in der Aufwärtsrichtung überschritten wurde. Die für dieses Ereignis spezifizierte Aktion besteht darin, eine Anforderung zu dem vereinigten Prepaid-Konto 120 zu senden, einen weiteren Lease-Kreditbetrag (weitere 2,00 Euro) in das akkumulierte Lease-Register 124 zu transferieren.
10 zeigt das Ergebnis dieser Aktion. Es ist zu sehen, dass die Inhalte des Registers 124 zugenommen haben und alle Schwellen TH1–TH4 um einen entsprechenden Betrag nach oben verschoben wurden.
Immer wenn ein Ereignis 110 oder 112 auftritt, berechnet Schritt 108 die entsprechende Gebühr 118 und addiert diese Gebühr zu dem betreffenden Kreditzähler 126. Dann wird geprüft, ob eine der Schwellen TH1–TH4 überschritten wurde. So lange nicht die höchste Schwelle TH4 überschritten wurde, wird entschieden, dass der Kredit des Nutzers noch ausreicht und die Sitzung wird fortgesetzt. Wenn das Ereignis ein Paketereignis 112 war, wird entschieden, dass das Paket durchgelassen wird.
Wenn der Kreditzähler 126 die niedrigste Schwelle TH1 erreicht, d.h. wenn der Lease-Betrag von 2,00 Euro fast aufgebraucht worden ist, wird das akkumulierte Lease-Register 124 wie in 10 aufgerüstet, und die Sitzung und der Datenfluss können ohne Verzögerung fortgesetzt werden. Der vom Nutzer verbrauchte akkumulierte Kredit wird durch die schrittweise Reduktion des vereinigten Prepaid-Konto 120 des Nutzers widergespiegelt. Im Fall eines Datenverlusts aufgrund eines Systemausfalls wird somit das finanzielle Risiko für den Dienstanbieter auf 2,00 Euro pro Nutzer begrenzt.
Wenn der Nutzer seine Sitzung beendet hat, wird die Differenz zwischen den Inhalten des Registers 124 und denen des Kreditzählers 126, d.h. der Kreditbetrag, der nicht verbraucht wurde, auf das vereinigte Prepaid-Konto 120 rückerstattet. Dann können der Kreditzähler 126 und das Register 124 für eine nächste Sitzung zurückgesetzt werden.
Wenn während einer Sitzung das vereinigte Prepaid-Konto 120 des Nutzers erschöpft wird, ist die Anforderung, einen weiteren Betrag von 2,00 Euro zu dem Register 124 zu leasen, nicht erfolgreich oder mindestens nicht vollständig erfolgreich, d.h. die Inhalte des Registers 124 werden um weniger als 2,00 Euro vergrößert oder werden überhaupt nicht vergrößert. Folglich kann der Kreditzähler 126 über die niedrigste Schwelle TH1 hinaus anwachsen und kann sukzessive die Schwellen TH2–TH4 erreichen. Die für die Schwellen TH2 und TH3 spezifizierten Aktionen können zum Beispiel Warnnachrichten sein, die zu dem Nutzer zu senden sind, um ihn dazu einzuladen, sein Prepaid-Konto wieder aufzuladen oder zu einem billigeren Profil mit einer niedrigeren Dienstgüte zu wechseln. Die ultimative Schwelle TH4 wird als "kritische" Schwelle definiert und die damit assoziierte Aktion besteht dann darin, den Nutzer im Fall eines Zeitereignisses 110 zu trennen oder im Fall eines Paketereignisses 112 das Datenpaket zu blockieren und fallen zu lassen.
So lange die Sitzung fortdauert, können die Inhalte des Registers 124 und des Kreditzählers 126 unendlich zunehmen. Um ein Überlaufen zu verhindern, reicht es aus, zu beobachten, ob bevorsteht, dass das Register 124 eine Überlaufbedingung erreicht, weil dieses Register den Kreditzähler 126 immer voraus ist. Wenn die Überlaufbedingung erfüllt ist, werden die Inhalte sowohl des Registers 124 als auch des Kreditzählers 126 um denselben Betrag reduziert und die Verrechnungsprozedur kann ohne jede weiteren Abänderungen fortgesetzt werden.
Obwohl das oben angegebene Beispiel im Hinblick auf einen Prepaid-Modus dargestellt wurde, kann diese Ausführungsform auf unkomplizierte Weise für einen Postpaid-Echtzeit-Abrechnungsmodus ausgelegt werden. Das vereinigte Prepaid-Konto 120 würde dann durch ein Guthaben-Konto des Nutzers ersetzt, und dieses Konto wird zum Beispiel durch Transferieren von negativen Lease-Beträgen in das Register 124 vergrößert. Entsprechend würden in dem "Kreditzähler" 126 negative Gebühren 118 akkumuliert, und die Reihenfolge der Schwellen TH1–TH4 wäre umgekehrt. Wieder wäre das Register 124 dem Zähler 126 immer voraus, nun aber in der negativen Richtung. Die oben beschriebene Definition des Kreditzählers 126 ergibt ausreichend Flexibilität zur Durchführung von Anpassungen dieser Art. Es versteht sich jedoch, dass im Postpaid-Fall möglicherweise keine kritischen Schwellen wie etwa TH4 notwendig sind, weil es für das Erschöpfen eines Prepaid-Konto kein wirkliches Äquivalent gibt. Dennoch könnte man solche Schwellen zur Implementierung von Bezahlungsobergrenzen oder dergleichen oder ansonsten zur Steuerung von Werbeblöcken oder dergleichen wie bei der ersten Ausführungsform beschrieben verwenden. Man erinnere sich, dass das oben beschriebene Echtzeit-Abrechnungssystem 100 die gesamte Funktionalität enthalten kann, die zuvor in Verbindung mit der ersten Ausführungsform beschrieben wurde.
In der US-Patentanmeldung, lfd. Nr. 09/999,267 hat der vorliegende Anmelder ein Abrechnungssystem vorgeschlagen, bei dem Internet-Dienste durch virtuelle Telefonnummern identifiziert und die Dienste abgerechnet werden, indem Datensätze in dem Format der Call Detail Records (CDR) abgerechnet werden, die zu einem Telefon-Abrechnungssystem gesendet werden. Folglich erscheinen die Gebühren für Internet-Dienste auf der Telefonrechnung und werden durch ihre virtuellen Telefonnummern identifiziert. Die vorliegende Erfindung kann im Postpaid-Modus ohne Weiteres mit dieser zuvor vorgeschlagenen Erfindung kombiniert werden. In diesem Fall würde die Kommunikation zwischen dem Echtzeit-Abrechnungssystem 100 und dem Konto des Nutzers und/oder dem Bezahlungsvermittlungssystem 122 durch das Erstellen der besagten Datensätze des CDR-Typs ersetzt.

Claims

Netzwerkvermittlungsanlage (20), eingerichtet für das Erlauben oder das Verwehren des Zugangs eines Nutzers zu mindestens einem vorbestimmten Netzdienst, indem entschieden wird, ob Datenpakete durch die Vermittlungsanlage durchgelassen werden sollen, dadurch gekennzeichnet, dass die Netzdienstvermittlungsanlage eine Berechnungslogik (100) für die Echtzeit-Berechnung einer Belastungshöhe (118) enthält, die dem Nutzer belastet wird für jedes einzelne Datenpaket, welches durchgelassen wurde, und für die Echtzeit-Belastung eines Kontos (126) des Nutzers in der Berechnungslogik (100) mit der besagten Belastungshöhe.
Verfahren für das Erlauben oder Verwehren des Zugangs eines Nutzers zu mindestens einem vorbestimmten Netzdienst, indem entschieden wird, ob Datenpakete durch die Vermittlungsanlage durchgelassen werden sollen, dadurch gekennzeichnet, dass in einer Berechnungslogik (100) innerhalb einer Netzdienstvermittlungsanlage Nutzerkonten (120, 126) in Echtzeit geändert werden in Berechnungsschritten (108), die durch vorbestimmte Ereignisse ausgelöst werden (110, 112), wobei mindestens eines dieser Ereignisse (112) die Ankunft eines einzelnen Datenpakets ist, welches zu oder von einem Endgerät des Nutzers (18) zu übertragen ist.
Verfahren nach Anspruch 2, enthaltend die Schritte: – Definieren mindestens einer Bezahlregel (106), die vorschreibt, wie eine Belastung (118) zu berechnen ist für ein Datenpaket abhängig von Typ, Ursprung und/oder Ziel des besagten Datenpakets.
Verfahren nach Anspruch 3, enthaltend die Schritte: – Definieren für jeden aktiven Nutzer mindestens eines Kreditzählobjektes, welches mindestens einen Schwellwert (TH1–TH4) enthält mit einer zugeordneten Schwellwertbedingung, und zu jedem Schwellwert einer zugeordneten Aktion, und – bei Ankunft eines Datenpakets Verändern des Inhalts eines Kreditzählers (126) in besagtem mindestens einem Kreditzählobjekt, um die für das besagte Datenpaket berechnete Belastung (118), und – Testen für jeden Schwellwert, ob der Inhalt des besagten Kreditzählers (126) die Schwellwerttestbedingung erfüllt und, wenn dies der Fall ist, Ausführen der besagten Aktion, die dem besagten Schwellwert zugeordnet ist.
Verfahren nach Anspruch 4, wobei die Schritte des Definierens mindestens einer Bezahlregel (106) und des Definierens mindestens eines Kreditzählobjektes die Definition einer Vielzahl von Bezahlregeln und Kreditzählobjekten für unterschiedliche Bezahltypen beinhalten.
Verfahren nach Anspruch 5, wobei mindestens eine Bezahlregel (106) vorschreibt, wie eine Vielzahl von Belastungen (118) für ein und dasselbe Datenpaket zu berechnen ist, wobei unterschiedliche Kreditzähler (126) mit besagten Belastungen (118) belastet werden.
Verfahren nach einem der Ansprüche 4 bis 6, wobei eine einer Schwellwertüberschreitung zugeordnete Aktion den Transfer einer Zahlung auslöst zwischen einem Bezahldienstleistungserbringer und einem Konto des Nutzers, wobei diese besagte Zahlung eine reservierende Verleihung (Lease) im Zusammenhang mit Vorauszahlungsanrechnungsverfahren (Prepaid-Billing- Verfahren) und eine Zwischenablesungstandsmitteilung (Interim Call Detail Record (CDR)) im Zusammenhang mit Echtzeit-Abrechnungsverfahren bei Zahlung auf Rechnung (Echtzeit-Postpaid Billing-Verfahren) darstellt.
Verfahren nach Anspruch 7, wobei Echtzeit-Betrugsschutz (Fraud Protection) durchgeführt wird durch Benutzung eines Echtzeit-Abrechnungsverfahrens bei Zahlung auf Rechnung (Echtzeit-Postpaid Billing Verfahren) anstelle oder zusätzlich zu herkömmlichem Abrechnungsverfahren bei Zahlung auf Rechnung (Postpaid-Billing Verfahren).
Verfahren nach Anspruch 7, wobei die Einhaltung von Zahlungslimits in Echtzeit überwacht wird durch Echtzeit-Abrechnungsverfahren bei Zahlung auf Rechnung (Echtzeit Postpaid Billing Verfahren) anstelle oder zusätzlich zu herkömmlichem Abrechnungsverfahren bei Zahlung auf Rechnung (Postpaid Billing).
Verfahren nach Anspruch 7, wobei elektronische Rechnungslegung und Bezahlung durchgeführt wird auf Basis von Echtzeit-Abrechnungsverfahren bei Zahlung auf Rechnung (Echtzeit Postpaid Billing Verfahren) anstelle von oder zusätzlich zu herkömmlichem Abrechnungsverfahren bei Zahlung auf Rechnung (Postpaid Billing).
Verfahren nach Anspruch 7, wobei ein einheitliches Berechnungsverfahren benutzt wird sowohl für Dienste mit Abrechnungsverfahren bei Zahlung auf Rechnung (Postpaid services) als auch für Dienste mit Anrechnungsverfahren bei Vorauszahlung (Prepaid services), dadurch gekennzeichnet, dass ein einzelner Dienst mit einer gespaltenen Belastung (split charge) angeboten werden kann, die eine Bezahlregel mit zwei Raten benutzt, einschließlich der Rate eines Vorauszahlungs-Bezahltyps (Prepaid-Bezahltyp) und einer Rate eines Bezahltyps für ein Echtzeit-Abrechnungsverfahrens bei Zahlung auf Rechnung (Postpaid-Bezahltyps).
Verfahren nach Anspruch 7, wobei ein einheitliches Berechnungsverfahren eingesetzt wird für Dienste mit Abrechnungsverfahren bei Zahlung auf Rechnung (Postpaid services) und für Dienste mit Anrechnungsverfahren bei Vorauszahlung (Prepaid services), dadurch gekennzeichnet, dass ein einzelner Nutzer innerhalb einer Nutzungs-Sitzung (User-Session) sowohl Dienste mit Anrechnungsverfahren bei Vorauszahlung (Prepaid-Dienste) als auch Dienste mit Abrechnungsverfahren bei Zahlung auf Rechnung (Postpaid Dienste) nutzen kann, und zwar bei Nutzung von mindestens zwei Diensterbringungs-Einheiten, für die Bezahlregeln zutreffen, die sowohl eine Rate eines Bezahltyps für Echtzeit-Anrechnungsverfahren bei Vorauszahlung (Prepaid) enthalten als auch eine Rate eines Bezahltyps für Echtzeit-Abrechnungsverfahren bei Zahlung auf Rechnung (Postpaid payment type rate).
Verfahren nach Anspruch 11 oder 12, wobei ein einheitliches Berechnungsverfahren eingesetzt wird für Dienste mit Abrechnungsverfahren bei Zahlung auf Rechnung (Postpaid Dienste) und für Dienste mit Anrechnungsverfahren bei Vorauszahlung (Prepaid Dienste), dadurch gekennzeichnet, dass ein Dienste-Erbringer ein herkömmliches Abrechnungsverfahren bei Zahlung auf Rechnung emuliert durch Nutzung eines Echtzeit-Abrechnungsverfahrens zusätzlich zu Echtzeit Anrechnungsverfahren bei Vorauszahlung.