DE69631373T2

DE69631373T2 - Abrechnungsverwaltung für telekommunikationsbenutzung

Info

Publication number: DE69631373T2
Application number: DE69631373T
Authority: DE
Inventors: Stephen David ALLISON; Martin David HAWTHORNE; Andrew Mairs; George William GLASS
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 1995-07-27
Filing date: 1996-07-29
Publication date: 2004-11-11
Anticipated expiration: 2016-07-30
Also published as: KR19990036053A; AU713964B2; MX9800742A; EP0840977A1; CN1192310A; EP0840977B1; CA2227914A1; CA2227914C; NO980329D0; JPH11510336A; US6052450A; AU6624496A; WO1997005734A1; BR9610027A; DE69631373D1; NO980329L; NZ313717A

Description

Diese Erfindung betrifft das Abrechnen für die Benutzung von Kommunikationsmitteln. Insbesondere betrifft es ein Abrechnungssystem, welches auf Benutzungsereignisse in einem Kommunikationsnetzwerk reagiert, um Ereignisdaten zur Unterstützung einer Rechnungsstellung zu verarbeiten.
In Kommunikationsnetzwerken wie den öffentlichen Fernsprechnetzwerken (PSTN) entstehen dem Kunden Kosten auf Grundlage der Benutzung des Netzwerks. Somit muss ein Abrechnungssystem die Benutzung des Netzwerks erfassen und Daten hinsichtlich dieser Benutzung verarbeiten, um so eine Rechnung oder einen anderen Abrechnungsmechanismus auszugeben.
Wenn zum Beispiel Telefongespräche über das britische Fernsprechnetz hergestellt werden, werden an den Vermittlungsstellen Aufzeichnungen erzeugt, die Details über das Gespräch aufzeichnen. Die Details umfassen Information wie die Länge des Gesprächs, Tageszeit des Gesprächs, Beginn und Ende, die anrufende Telefonleitung und die Ziel-Telefonleitung. Auf diese Information wird regelmäßig von Abrechnungssystemen zugegriffen und in Rechnungen verarbeitet, welche dem Kunden zugesendet werden.
Die internationale Patentanmeldung WO 93/08661 offenbart ein Gesprächsdetail-Aufzeichnungs-System, durch welches die Telefongesellschaft, welche eine Vermittlungsstelle betreibt, Entscheidungstabellen modifizieren kann, welche zu Entscheidung darüber benutzt werden, ob eine Rechnungsaufzeichnung für jedes einzelne Gespräch erzeugt werden soll oder nicht.
Ein Problem vorliegender Abrechnungssysteme liegt darin, dass sie sehr unflexibel sein können. Wenn zum Beispiel ein Anbieter von Kommunikationsdiensten seine Gebühren aktualisieren oder neue Dienste über das PSTN einführen möchte, kann ein längeres und schwieriges Aktualisierungsverfahren erforderlich werden, damit das Abrechnungssystem dem neue Gebührensystem gerecht wird.
Gemäß einem ersten Aspekt der Erfindung ist ein Verfahren zum Verarbeiten von Daten zum Erstellen einer Rechnung für Benutzung eines Kommunikationsnetzwerks vorgesehen, wobei das Verfahren aufweist

i) Empfangen von Ereignisdaten von dem Kommunikationsnetzwerk, wobei die Ereignisdaten eine Vielzahl von Netzwerkbenutzungsereignissen durch einen Benutzer über eine Zeitdauer betreffen;
ii) Vorsehen eines Satzes von Schemen, welche auf für Benutzer zur Verfügung stehende Kommunikationsdienste mittels des Netzwerks anwendbar sind, wobei jedes Schema dienstspezifische Daten und zumindest eine Regel, oder einen Identifikator für zumindest eine Regel, zur Verwendung bei der Verarbeitung von erhaltenen Ereignisdaten hinsichtlich dieses Dienstes aufweist;
iii) Speichern benutzerspezifischer Information, die einen Satz von Diensten identifiziert, welche durch den Benutzer aus den über das Netzwerk zur Verfügung stehenden Kommunikationsdiensten ausgewählt und zur Benutzung zugeteilt werden;
iv) Wählen eines Schemas oder mehrerer Schemen, das/die auf die erhaltenen Ereignisdaten anwendbar ist/sind, aus dem Satz von Schemen gemäß der für diesen Benutzer gespeicherten benutzerspezifischen Information; und
v) Anwenden des gewählten Schemas/der gewählten Schemen auf die Ereignisdaten, um die Ereignisdaten zur Rechnungserstellung zu verarbeiten. Vorzugsweise weist das Verfahren ferner auf
vi) Speichern einer generischen Datenverarbeitungsstruktur mit einer geordneten Menge von Datenverarbeitungsknoten, die zum Verarbeiten von Ereignisdaten, welche sich auf die über das Netzwerk verfügbaren Kommunikationsdienste beziehen, strukturiert sind, wobei jeder Netzknoten ein zugehöriges Schema aus dem Satz von Schemen aufweist, wobei der Schritt des Wählens eines Schemas oder mehrerer Schemen ausgeführt wird, indem eine Untermenge der geordneten Menge von Datenverarbeitungsknoten gewählt wird, welche Schemen zum Verarbeiten von Netzwerk-Ereignisdaten hinsichtlich des gewählten Dienstsatzes für den Benutzer zugeordnet haben.

Die Schemen können in den Netzknoten der generischen Datenverarbeitungsstruktur gespeichert werden, aber es könnte einfacher sein, sie in einer getrennten Datenstruktur zu speichern, da die generische Datenverarbeitungsstruktur Identifikatoren für die Schemas anstatt die Schemen selbst enthält.
Obwohl oben der Begriff „Benutzer" verwendet wird, kann der Benutzer tatsächlich einer von vielen Repräsentanten eines Kunden sein. Zum Beispiel kann es sich bei dem Kunden um ein multinationales Unternehmen handeln. In diesem Fall ist offensichtlich, dass die „benutzerspezifische Information" tatsächlich für alle Benutzer eines bestimmten Kunden relevant sein kann.
Ausführungsbeispiele der vorliegenden Erfindung haben den Vorteil, dass sie relativ einfach modifiziert werden können, um beispielsweise Änderungen in einem Gebührensystem gerecht zu werden. Zuerst können sich die über das Netzwerk verfügbaren Dienste ändern. In diesem Fall kann der Satz von Schemen oder die generische Datenverarbeitungsstruktur aktualisiert werden. Alternativ kann der Kunde wählen, einen Dienst zu seinem spezifischen Satz von Diensten hinzuzufügen oder daraus zu entfernen oder die Spezifikation für einen bestimmten Dienst zu ändern. In diesem Fall kann die kundenspezifische Information aktualisiert werden.
Gemäß einem zweiten Ausführungsbeispiel der Erfindung ist eine Vorrichtung zum Verarbeiten von Daten vorgesehen, um eine Rechnung für die Benutzung eines Kommunikationsnetzwerks zu erstellen, wobei das Verfahren aufweist

i) Mittel, die eingerichtet sind, um im Betrieb Ereignisdaten (117) von dem Kommunikationsnetzwerk zu empfangen, wobei die Ereignisdaten (117) eine Vielzahl von Netzwerkbenutzungsereignissen durch einen Benutzer über eine Zeitdauer betreffen;
ii) Mittel, die eingerichtet sind, um im Betrieb einen Satz von Schemen (70, 75) vorzusehen, welche auf für Benutzer zur Verfügung stehende Kommunikationsdienste mittels des Netzwerks anwendbar sind, wobei jedes Schema (70, 75) dienstspezifische Daten und zumindest eine Regel, oder einen Identifikator für zumindest eine Regel, zur Verblendung bei der Verarbeitung von erhaltenen Ereignisdaten (117) hinsichtlich dieses Dienstes aufweist;
iii) Mittel, die eingerichtet sind, um im Betrieb benutzerspezifische Information zu speichern, die einen Satz von Diensten identifiziert, welche durch den Benutzer aus den über das Netzwerk zur Verfügung stehenden Kommunikationsdiensten ausgewählt und zur Benutzung zugeteilt werden;
iv) Mittel, die eingerichtet sind, um im Betrieb aus dem Satz von Schemen (70, 75) gemäß der für diesen Benutzer gespeicherten benutzerspezifischen Information ein Schema oder mehrere Schemen (70, 75) zu wählen, das/die auf die erhaltenen Ereignisdaten anwendbar ist/sind; und
v) Mittel, die eingerichtet sind, um im Betrieb das gewählte Schema/die gewählten Schemen (70, 75) auf die Ereignisdaten (117) anzuwenden, um die Ereignisdaten (117) zur Rechnungserstellung zu verarbeiten.

Ein spezifisches Ausführungsbeispiel der Erfindung wird nun, nur auf beispielhafte Weise, unter Bezugnahme auf die Zeichnungen beschrieben, wobei
1 in Form eines schematischen Blockdiagramms ein Abrechnungssystem gemäß der Erfindung darstellt;
2 in Form eines schematischen Blockdiagramms einen Preis- und Aufbaumechanismus zeigt, welcher eine Komponente des in 1 gezeigten Systems ist;
3 in Form eines schematischen Blockdiagramms ein Modul des in 2 gezeigten Mechanismus zeigt;
4 eine erläuternde Darstellung ist, welche in einer Erläuterung des Konzepts eines zellularen Netzwerks von Schemen verwendet wird, welches auf von einem Telekommunikationsnetzwerk erhaltene Daten angewendet wird, um eine Rechnung für die Benutzung zu erzeugen;
5 ein generisches zellulares Netzwerk (Graph) zeigt und darstellt, wie Zellen des Graphen gewählt werden können, um einen kundenspezifischen Graphen zu erzeugen;
6 ein erläuterndes Ablaufdiagramm des Betriebs des Systems ist;
7 eine erläuternde Darstellung ist, die zeigt, wie Zellen eines Graphen mit Datenfeldern vorgesehen sind, einschließlich Zeigern zu anderen Zellen, um ein zellulares Netzwerk zu errichten;
8 die Abschnitte bei der Errichtung eines Graphen als ein zellulares Netzwerk zeigt;
9 ein erläuterndes Ablaufdiagramm des Vorgehens ist, wie ein Graph auf Kundendaten (Ereignisse) angewendet wird;
10 eine schematische Darstellung des Vorgehens ist, wie die Schemen des kundenspezifischen Graphen Ereignisse verarbeiten, erzeugen und kombinieren, und wie die Ereignisse in dem Graphen von Zelle zu Zelle fließen;
11 eine erläuternde Darstellung ist, welche das Vorgehen zeigt, wie die Ergebnisse der Schemen auf ihre Ursprünge hinzeigen; und
12 eine schematische Darstellung des Vorgehens ist, wie eine datenabhängige Änderung in den kundenspezifischen Daten in einen kundenspezifischen Graph eingebaut werden kann.
Folgendes ist ein Glossar von in dieser Spezifikation verwendeter Akronyme zur Hilfe beim Lesen der Spezifikation:

– PDG (Primary Data Generator): Primärer Daten-Generator (wie eine Netzwerk-Vermittlungsstelle)
– NMP (Network Mediation Processor): Netzwerk-Vermittlungs-Prozessor
– PIUR (Platform Independent Usage Record): plattformunabhängiger Benutzungs-Datensatz
– SDP (Service Domain Processor): Dienst-Domain-Prozessor
– PSLM (Products and Services Life-Cycle Manager): Manager für die Lebensdauer von Produkten und Diensten
– MEL (Master Event List): Haupt-Ereignisverzeichnis
– PEL (Processed Event List): verarbeitetes Ereignisverzeichnis
– CBP (Customer Billing Processor): Kunden-Abrechnungs-Prozessor
– IPE (Invoice Production Engine): Rechnungserstellungs-Mechanismus
– PAE (Pricing and Assembly Engine Module): Preis- und Aufbaumechanismus-Modul
– CDM (Customer Data Module): Kundendaten-Modul
– CFM (Common Functions Module): Gemeinsame-Funktionen-Modul
– ECM (Environmental Control Module): Umgebungssteuerungsmodul
– ELM (Event List Module): Ereignisverzeichnis-Modul
– GMM (Graph Manipulation Module): Graph-Handhabungs-Modul
– PDM (PSLM Data Module): PSLM-Daten-Modul
– RIP (Rules Interpretation Processor): Regel-Interpretations-Prozessor
– RCM (Rules Compiler Module): Regel-Compiler-Modul
– SMM (Shared Memory Module): Shared-Memory-Modul

Unter Bezugnahme auf 1 weist ein Abrechnungssystem 1 zum Erstellen von Rechnungen für Benutzung eines Telekommunikationsnetzwerks eine Anzahl von Software-Modulen auf, welche das System mit Funktionalität ausstatten. Das System kann auf jeder geeigneten Rechenplattform implementiert werden, wird aber im Allgemeinen über eine Anzahl von vernetzten Computer-Systemen verteilt werden, um eine angemessene Interaktion zu ermöglichen.
Im Detail umfasst das System 1 eine Anzahl von Schnittstellen 2 mit dem Netzwerk, von denen drei gezeigt werden, obwohl normalerweise mehr als diese zur Benutzung mit einem Netzwerk, wie einem PSTN, vorgesehen sind. Jede der Schnittstellen 2 ist mit einer entsprechenden Vielzahl von Vermittlungsstellen in dem Telekommunikationsnetzwerk über Verbindungen 3 verbunden. Die Schnittstellen 2 sind wiederum mit einem Kunden-Abrechnungs-Prozessor CBP 4 verbunden.
Eine Anzahl von Preis- und Aufbaumechanismus-Modulen (PAE) 5, von denen drei gezeigt werden, sind angeordnet, um mit dem CBP 4 in Wechselwirkung zu treten. Sie sind auch angeordnet, um mit einem Regel-Bibliotheks-Modul 6 und einem Manager für die Lebensdauer von Produkten und Diensten (PSLM) 7 in Wechselwirkung zu treten.
Aus der Figur wird offensichtlich, dass der PSLM 7 ebenfalls angeordnet ist, um mit dem Regel-Bibliotheks-Modul 6 in Wechselwirkung zu treten.
Die Schnittstellen 2 fragen zyklisch die Vermittlungsstellen, mit denen sie verbunden sind, hinsichtlich Information über eine Benutzung des Netzwerks ab. Die Information wird dann in eine Form verarbeitet, welche zur Speicherung durch den CBP 4 geeignet ist. Der CBP 4 speichert die Information in einer Datenbank 4a.
Die Module des Systems 1 werden nun detaillierter erläutert.
Jede Schnittstelle 2 weist zwei Prozessoren auf, einen Netzwerk-Vermittlungs-Prozessor (NMP) 2a und einen Dienst-Domain-Prozessor (SDP) 2b.
Der NMP 2a ist ein Prozessor zum Sammeln ereignisbezogener Daten von Elementen in dem Telekommunikationsnetzwerk. Diese Elemente können zum Zweck von Ausführungsbeispielen der vorliegenden Erfindung als primäre Daten-Generatoren (PDGs) bezeichnet werden. In einem Telekommunikationsnetzwerk des Typs, welcher heutzutage im Allgemeinen benutzt wird, weisen sie gewöhnlich Vermittlungsstellen auf. In diesem Ausführungsbeispiel läuft der NMP 2a auf einer UNIX-Plattform auf einer ICL DRS 6000 Workstation. Der NMP 2a ist verbunden mit den primären Daten-Generatoren und sammelt Benutzungsdatensätze von den primären Daten-Generatoren. Die Benutzungsdatensätze enthalten Daten für abrechenbare Ereignisse und können zum Beispiel Datensätze des Ursprungs, des Ziels, Beginn und Dauer von Telefongesprächen sein, die von einer Vermittlungsstelle des Netzwerks weitergeleitet werden.
Um die Daten zu erhalten, ruft der NMP 2a zyklisch ein Verzeichnis der Vermittlungsstellen ab, die er bedient.
Die Benutzungsdatensätze werden je nach Typ und Hersteller des Daten-Generators im Format variieren und ein Teil der Aufgabe des Prozessors liegt darin, die Datensätze zu standardisieren und zusammenzuführen. Die zusammengeführten Datensätze werden als plattformunabhängige Benutzungsdatensätze (PIURs) bezeichnet und an den SDP 2b ausgegeben, indem die Datensätze gemäß ASN 1, einem OSI-Protokoll (Open Systems Interconnection protocol), codiert werden.
Der SDP 2b erhält die PIURs von dem NMP 2a und wendet einen Satz nicht-ermäßigter einfacher Tarife darauf an, um Gesprächsdatensät ze zu erstellen, welche auf einer Preisberechnung gemäß einer transaktionsbasierten verstrichenen Zeit bewertet sind. Diese Gesprächsdatensätze mit Gebührenangabe werden an den CBP 4 übermittelt.
Der CBP 4 nimmt die von den SDPs 2a erzeugten Dateien der Gesprächsdatensätze mit Gebührenangabe und bringt die Information in einer einzelne Datendatei zusammen. Diese Datei wird in der Datenbank 4a zur weiteren Verarbeitung durch ein PAE 5 gespeichert.
Der CBP 4 enthält einen Rechnungs-Scheduling-Prozess, welcher eine Kunden-Abrechnungs-Datenbank verarbeitet, um zu ermitteln, welchen Kunden eine Rechnung gestellt wird. Dies geschieht durch Prüfen von Fälligkeitsdaten von Rechnungen und anderen speziellen Flags, die anzeigen, dass eine Rechnung erforderlich ist, wie ein „erstelle eine Rechnung"-Flag oder „Schwelle erreicht"-Flag. Dies löst eine Auswahl eines verfügbaren PAE 5 aus, an das dann kundenspezifische Daten zur Verarbeitung gesendet werden.
Da eine Abrechnung in regelmäßigen Zeitabständen stattfindet, kann die gesamte Information für einen Abrechnungszeitraum zusammengefasst werden und es ist möglich, viele Aspekte der Benutzung zu berücksichtigen, einschließlich natürlich einer Ermäßigung auf die Benutzung. Es ist auch möglich, kundenspezifische Information zu berücksichtigen, wie eine Gebührenerstellung über mehrere Konten.
Jedes PAE 5 ist im Wesentlichen ein Ereignis-Prozessor. Ein „Ereignis" für die Zwecke des PAE 5 ist das Errichten einer Verbindung auf dem Netzwerk, welches abgerechnet wird. Zum Beispiel kann ein Ereignis ein Gespräch auf dem PSTN, ein Miet-Ereignis für eine private Schaltung oder ein Gebühren-Ereignis für eine Weiterleitung sein. Die Datei, die aus den Dateien der Gesprächsdatensätze mit Gebührenangabe zusammengefügt und von dem PAE 5 von dem CP 4 erhalten wurde, wird in dem PAE 5 in ein Haupt-Ereignisverzeichnis MEL konvertiert. Jedes Ereignis in dem MEL ist ein PIUR.
Die Ausgabe des CBP 4 an den PAE 5 wird nach „Dienst" und innerhalb jedes „Dienstes" in chronologischer Reihenfolge des unterschiedlichen Datums/der unterschiedlichen Zeit geordnet. Jedes Ereignis kann ein einzelnes Datum/eine einzelne Zeit zugeordnet haben, in welchem Fall dies das unterscheidende Datum/die unterscheidende Zeit ist. Alternativ kann es mehrere Daten/Zeiten geben, wie Anfangs- und End-Daten/-Zeiten, oder ein Anfangs-Datum/eine Anfangs-Zeit und eine Dauer. In diesen Fällen ist es das Anfangs-Datum/die Anfangs-Zeit, welche das unterscheidende Datum/die unterscheidende Zeit ist. Das PAE 5 benötigt eine chronologische Datums-/Zeit-Information aufgrund mehrerer Gründe, wie beispielsweise falls es einen Anfang/ein Ende/eine Wiederaufnahme eines Dienstes in der von einer Rechnung abgedeckten Zeitspanne gegeben hat. Es ist einfacher, wenn der CBP 4 ein Ereignisverzeichnis in chronologischer Reihenfolge zur Verfügung stellt, so dass das PAE 5 ein Sortieren nicht unterstützen muss. Dies bedeutet jedoch, dass Ereignisse in einer gemeinsamen Zeitzone vorgesehen sein mussten.
Das PAE 5 verarbeitet Ereignisse des MEL entweder einzeln oder in Gruppen und erzeugt ein verarbeitetes Ereignisverzeichnis (PEL). Jedes PEL ist eine Untermenge der Ereignisse in dem MEL zusammen mit Information, wie die Ereignisse in dem PAE verarbeitet wurden. Somit weist das PEL ein Verarbeitungs-Audit auf, welches ermöglicht, wenn ein Fehler in dem Abrechnungsverfahren auftreten sollte, dass der Ursprung des Fehlers ermittelt und ein korrigierender Eingriff durchgeführt wird, um zu verhindern, dass der Fehler wiederholt auftritt.
Das PAE 5 verarbeitet Ereignisse für einen Kunden gemäß einem Satz verwandter Schemen für diesen Kunden. Ein Schema ist ein logischer Prozess (kein Unix-Prozess), welcher eine von dem PSLM 7 vorgesehene Regel ausführt, um zum Beispiel eine Gebühr für ein Produkt oder eine Information für die Rechnung zu erzeugen. Der PSLM 7 liefert Regeln (in Klar-Text), die von einem Satz von Schemen identifiziert wurden, welche sich mit der Verarbeitung der Telekommunikationsbenutzung befassen. Diese Regeln können für die Gebührenerstellung eines weiten Bereichs von Diensten sorgen, wie beispielsweise Gebühren von Zeiteinheiten, Mietgebühren und Gesprächsdienste. Offensichtlich können sich diese Gebühren über eine Zeitspanne ändern, für die eine Rechnung erstellt werden soll, und dies wird unter Bezugnahme auf das unterscheidende Datum/die unterscheidende Zeit für jedes oben erwähnte Ereignis und die Anwendung der Schemen gelöst. Die Schemen werden als ein generischer Graph auf eine Art gespeichert, welche später erläutert wird. Ein Satz verwandter Schemen für einen Kunden wird durch Anwenden kundenspezifische Daten auf den generischen Graphen erzeugt. Dies wird ebenfalls im Folgenden genauer erläutert.
Die Regeln für die Schemen sind in dem Regel-Bibliotheks-Modul 6 gespeichert.
Das PAE 5 umfasst ein Regel-Compiler-Modul (RCM) 8. Dieses Modul erhält Regeln in Klartext-Format von dem PSLM 7 und wandelt diese in eine Form eines Pseudo-Maschinencodes (p-code) um, welcher die Maschinenanweisungen für eine virtuelle Maschine basierend auf einem Stapelspeicher darstellt. Das PAE 5 weist ebenso einen Regel-Interpretations-Prozessor (RIP) 9 auf, welcher die p-code-Form der Regeln versteht. Der Interpreter 9 läuft als ein getrennter Prozess zur Skalierbarkeit, da mehrere Interpreter zur gleichen Zeit laufen können.
Das PAE wird nun unter Bezugnahme auf 2 detaillierter beschrieben. Das PAE 5 umfasst eine Anzahl von Modulen. Module sind Ansammlungen von Softwarecode, der Funktionalität für das PAE liefert, und somit funktionelle Komponenten und nicht architektonische Komponenten. Die ersten zwei Module wurden bereits erwähnt, wobei es sich um den RIP 9 und das RCM 8 handelt. Ein drittes Modul ist ein Graph-Manipulations-Modul (GMM) 10. Ein viertes Modul ist ein Kundendaten-Modul (CDM) 11. Ein fünftes Modul ist ein Shared-Memory-Modul (SMM) 12. Ein sechstes Modul ist ein Gemeinsame-Funktionen-Modul (CFM) 13. Ein siebtes Modul ist ein Ereignisverzeichnis-Modul (ELM) 14. Ein achtes Modul ist ein PSLM-Daten-Modul (PDM) 15. Ein neuntes Modul ist ein Umgebungssteuerungsmodul (ECM) 16.
Die von jedem der Module gelieferte Funktionalität wird nun erläutert.
Das GMM 10 ist ein Kernmodul des PAE 4, da es eine Funktion zum Erstellen und Manipulieren von Graphen der Gebühren- und Abrechnungs-Schemen in einem zellularen Rahmen vorsieht (das Konzept von Graphen wird später beschrieben). Dieses Modul verbindet Schemen, um einen Schema-Graphen zu erstellen, überprüft den entstehenden Graphen, um sicherzustellen, dass dieser azyklisch ist, das heißt, dass keine Endlosschleifen vorkommen, instantiiert einen Graphen für eine bestimmte Instanz eines Kunden und ruft die Ausführung dieses Graphen auf. Diese Vorgänge werden später detaillierter erläutert.
Das CDM 11 liefert die zum Verwalten von Kundendaten erforderliche Funktionalität in dem PAE 5. Die Kundendaten können sowohl Bestandsdaten als auch Ereignisdaten sein. Das CDM 11 erhält ankommende Dateien von dem CBP 4 und parst sie in getrennte Dateien für jeden Kunden. Dann parst das CDM jede einzelne kundenspezifische Datei und gibt die Bestandsdaten in einen Shared Memory. Die Ereignisdaten werden in ein Haupt-Ereignisverzeichnis MEL gestellt und an das ELM 14 übermittelt, welches dann das MEL in den von dem SMM 12 gesteuerten Shared Memory gibt. Dieses Modul ermöglicht auch den Zugriff auf die Bestandsdaten in dem Shared Memory und kombiniert für eine Rechnung fertige Dateien (von dem PAE verarbeitete Dateien) und sendet sie an den CBP 4 zurück, insbesondere an einen Rechnungserstellungs-Mechanismus (IPE) 4b, welcher die Rechnung druckt.
Das SMM 12 sieht Funktionen vor, um eine Speicherzuweisung innerhalb eines Speichers zu verwalten, welcher von den Modulen geteilt wird.
Das CFM 13 sieht einen Satz von Funktionen allgemeinen Zwecks oder Hilfsmittel zur Benutzung von anderen Modulen vor, falls erforderlich. Die Hilfsmittel umfassen Dateizugriff, Rundungs- und Fehler-Protokoll-Hilfsmittel.
Das ELM 14 sieht die zum Manipulieren von Ereignissen erforderliche Funktionalität vor. Es ermöglicht das Erstellen eines MEL aus den von dem CBP 4 erhaltenen Ereignisdaten, ermöglicht einen Zugriff auf die von dem CBP 4 erhaltenen originalen Ereignisdaten, erzeugt PELs und fügt den PELs Gebühren- und Aufbauinformation hinzu. Es ermöglicht auch die Auswahl und Manipulation von Ereignisverzeichnissen innerhalb von PELs und erzeugt die für eine Rechnung fertigen Dateien, welche an den CBP 4 zurückgesendet werden.
Das PDM 15 weist eine Anzahl von Unter-Modulen auf, wie in 3 gezeigt wird. Die Unter-Module umfassen eine PSLM-Schnittstelle 15a, ein Modul 15b zum Speichern eines Schema-Graphen, einen plattformunabhängigen Datensatz-Definitions-Speicher 15c und eine PDM API 15d, welche einen Zugang anderer Module zu den in dem Speicher 15c gespeicherten PIRs ermöglicht. Das Modul 15b zum Speichern eines Schema-Graphen speichert die zum Erstellen des Schema-Graphen erforderlichen Schema-Regeln und -Informationen. Es speichert die Schema-Regeln in einer internen Form, nachdem sie diese von dem RCM 8 erhalten hat. Das RCM 8 konvertiert die Regeln von der Form, in welcher sie von dem PSLM 7 erhalten werden, in die interne Form.
Das ECM 16 sieht eine Koordination für die anderen Module vor und steuert den Arbeitsablauf zwischen den anderen Prozessoren. Insbe sondere erfasst es, wenn eine Aktualisierung, zum Beispiel des oben erwähnten generischen Graphen, erforderlich ist. Wenn eine Aktualisierung erforderlich ist, ist es das ECM 16, welches verhindert, dass ein neues Verfahren beginnt, und wartet, bis schon im Ablauf befindliche Prozesse beendet sind, bevor es die erforderlichen Aktualisierungs- und Neustart-Verfahren auslöst.
Das Prinzip, welchem das PAE 5 folgt, ist, dass die von dem Kunden benutzten Produkte und Dienste des Unternehmens als ein Graph dargestellt werden können, in welchem die Netzknoten Ereignisse, die von einem Kunden erzeugt werden, verarbeiten können. Jeder Netzknoten des Graphen weist ein zugehöriges Schema auf und die Verbindung des Netzknoten definiert die zwischen den Schemen existierende Wechselbeziehung. Jeder Netzknoten verarbeitet einen relevanten Satz von Ereignissen, die von den Kunden erzeugt wurden, und der Fluss der Ereignisse von einem ersten Netzknoten zu einem letzten Netzknoten resultiert in einer fertigen Kundenrechnung. Dieses Konzept wird in 4 dargestellt.
In 4 werden die verschiedenen Prozesse, welche auf den in das PAE 4 eingegebenen Ereignisdaten durchgeführt weiden können, als Knoten A, B, C und D dargestellt. Die Netzknoten sind untereinander über die Verbindungen 40 bis 43 verbunden. Netzknoten A ist über die Verbindung 40 mit Netzknoten B und über Verbindung 41 mit Netzknoten C verbunden. Netzknoten C ist über die Verbindung 43 mit Netzknoten D verbunden.
Daten „fließen hinein in" den Graphen an dem in der Fig. unten dargestellten Netzknoten, welches in diesem Fall der Netzknoten A ist.
Netzknoten A führt seine Verfahren an den Daten durch und leitet die Ergebnisse dieser Verfahren an Netzknoten B und Netzknoten C weiter, wie von den Datenfluss-Pfeilen 44 und 45 dargestellt wird. Netzknoten B führt seine Verfahren an den von dem Netzknoten A erhaltenen Daten durch und leitet die Ergebnisse dieser Verfahren an Netzknoten C, wie von dem Datenfluss-Pfeil 46 dargestellt wird. Netzknoten C führt seine Verfahren an den von dem Netzknoten A und dem Netzknoten B erhaltenen Daten durch und leitet die Ergebnisse dieser Verfahren an Netzknoten D, wie von dem Datenfluss-Pfeil 47 dargestellt wird. Netzknoten D führt seine Verfahren durch und da er der letzte Netzknoten ist, „fließen" die verarbeiteten Daten aus dem Graph „hinaus".
Der Graph ist in diesem Fall azyklisch, da es keine Endlosschleifen gibt. Man betrachte denselben Graph mit einer zusätzlichen Verbindung 48 (durch die unterbrochene Linie angezeigt), welche den Netzknoten D wieder mit Netzknoten B verbindet. Die Verbindung 48 leitet Daten von Netzknoten D zurück an Netzknoten B, wie von dem Datenfluss-Pfeil 49 dargestellt wird. Diese Daten würden dann an den Netzknoten C geleitet werden und dann wieder zurück zu Netzknoten D. Somit würde eine endlose Verarbeitungsschleife entstehen. Ein Teil der Funktion des GMM 10 liegt darin, den Graph zu verifizieren, um sicherzustellen, dass keine endlosen Verarbeitungsschleifen während der Erstellung des Graphen eingebaut werden.
Der PSLM 7 enthält einen generischen Graphen, welcher Verarbeitungsknoten für jeden möglichen Dienst und jedes mögliche Produkt aufweist, die von dem Telefonbetreiber angeboten werden. 5 zeigt einen derartigen generischen Graph, obwohl der Einfachheit halber die Anzahl der Netzknoten verringert wurde. Nicht alle Kunden werden alle zur Verfügung stehenden Produkte und Dienste benutzen. Somit würden, wenn der generische Graph direkt benutzt würde, viele Verarbeitungsschritte unnötigerweise ausgeführt oder unnötigerweise Verarbeitungsleistung der Aufgabe zugewiesen. Dies würde wertvolle Rechenzeit verschwenden, wenn eine Rechnung erstellt wird.
Angenommen zum Beispiel, ein Kunde benutzt die Produkte oder Dienste, welche die mit X bezeichneten Netzknoten erfordern, dann sind sechs der Netzknoten (ohne Beschriftung) überflüssig.
Um dies zu vermeiden, benutzt das PAE 5 das GMM 10, um den generischen Graph gemäß den Waren und Diensten anzupassen, die der Kunden in Anspruch genommen hat.
6 zeigt ein Ablaufdiagramm des Betriebs des PAE 5. Ein erster Schritt für das PAE 5 besteht darin, die generischen Graph-Daten von dem PSLM 7 anzufordern, wie von dem Kästchen 60 dargestellt wird. Die Daten werden dazu verwendet, um in einem von Kästchen 61 dargestellten Schritt einen generischen Graph zu erstellen. Der generische Graph wird in einem Vorgang, der als „Anschalten des Graphen" („lighting up") bezeichnet wird (wird später beschrieben) spezifisch auf einen Kunden zugeschnitten, wie von Kästchen 62 dargestellt wird. Der passende Graph wird dann auf die Kundenereignisse angewendet, die an das PAE 5 von dem CBP 4 geleitet werden; dieser Schritt wird von dem Kästchen 63 dargestellt. Das PAE 5 leitet die verarbeiteten Daten zurück an den CBP 4, wie von dem Kästchen 64 dargestellt wird, wo es an den IPE 4b geleitet und eine Rechnung ausgedruckt und an den Kunden versendet wird. Neue Kundendaten werden von dem CBP 4 angefordert, wie von dem Kästchen 65 dargestellt wird, und die Schritte werden dann wiederholt.
Die ersten beiden Schritte 60 und 61 werden nun detaillierter erläutert.
Der PSLM 7 enthält Information über:

1. Produktpreise und verwandte Information, die von dem PAE 5 dazu verwendet wird, um einen Preis für ein Produkt zu erzeugen. Zum Beispiel die Mietgebühr für eine Telefonleitung oder der Preis für ein Teil der Ausstattung, wie ein Telefon oder ein Anrufbeantworter;
2. Die Regeln zum Erstellen eines Preises für ein Produkt oder zum Erzeugen von Information für ein bestimmtes Abrechnungsschema. Ein Beispiel dafür wäre ein ermäßigter Dienst wie „Freunde und Familie" („Friends and Family"), der von British Telecommunications Plc, 82 Newgate Street, London, United Kingdom, angeboten wird. Bei diesem Dienst wird eine Ermäßigung gewährt auf Anrufe an einen festgelegten Satz von Nummern; und
3. Die Beziehungen zwischen den verschiedenen Produkten oder Rechnungen, einschließlich Datumsinformation.

Im Wesentlichen sind die Punkte 1 und 2 der Information individuelle Schemen, die zu den Netzknoten in 5 äquivalent sind, und Punkt 3 ist äquivalent zu den Verbindungen zwischen den Netzknoten. Obwohl der generische Graph nicht auf die in 5 dargestellte Weise gespeichert ist, das heißt auf eine bildliche Weise, ist somit die gesamte Information gespeichert, die später zum Bilden des Schema-Graphen erforderlich ist.
Die Schemen sind logische Prozesse, die eine Regel ausführen, um einen Preis oder eine Information zu erzeugen, die auf der Rechnung erscheinen soll (zum Beispiel die Gesamtzahl der benutzten Telefoneinheiten). Die in dem Schema implementierten Regeln werden von dem PSLM 7 vorgesehen und ein Schema kann mehr als einmal in jeder Rechnungserstellung ausgeführt werden. In anderen Worten, ein Netzknoten in dem Graphen von 5 kann mehr als einmal bei der Verarbeitung von Kundendaten verwendet werden, aber nicht auf demselben Datenelement, da der Graph azyklisch ist, wie oben erwähnt.
Diese Teile von Kundeninformation, auf die ein Schema angewendet werden kann, werden befristete Schemeninstanzen genannt. Dieses Konzept ist ähnlich dem Konzept von Objektklassen und Objektinstanzen bei der objektorientierten Programmierung. Ein Schema wird einmal für jede Schemeninstanz ausgeführt, die für dieses Schema existiert. Jedes Mal, wenn ein Schema ausgeführt wird, wird ein PEL als eine Aufzeichnung von allem erzeugt; was mit der Schemeninstanz durchgeführt wird.
Im Wesentlichen ist deswegen der Graph eine „Abbildung" der auf den Kundendaten auszuführenden Prozesse, wobei der Graph die Wege vorgibt, welchen die Produkte dieser Prozesse zu anderen Prozessen folgen sollen. Es sollte hervorgehoben werden, dass der Schema-Graph nur aus den von dem PSLM 7 gespeicherten Daten besteht. In den Netzknoten und Verbindungen werden keine kundenspezifischen Daten gespeichert. Es ist ein generischer Graph, der einem fiktiven Kunden gerecht wird, welcher alle von dem Netzbetreiber angebotenen Produkte und Dienste benutzen würde.
Der PSLM 7 sendet zwei Typen von Daten an das PAE 5, um den Schema-Graphen zu erstellen. Der erste Typ betrifft die Regeln – diese werden in einer Klartext-Form gesendet. Der zweite Typ ist eine Tabelle, welche jedes Schema einem der Eltern-Schemen zuordnet, die bei einer von diesem Schema erzeugten Ausgabe wirksam werden.
Das PDM 15 des PAE 5 überträgt die Tabelle in eine zur Verwendung mit dem GMM 10 geeignete Form. Aus dieser Tabelle bildet das GMM 10 den generischen Graph, indem es die Daten in einen Netzknoten mit Eltern und Kindern strukturiert, das heißt, es wird eine Eltern-Kind-Struktur erzeugt. Eine vereinfachte Eltern-Kind-Struktur wird in 7 gezeigt und es ist zu sehen, dass jeder Netzknoten eine Speicherstruktur ist, die eine Anzahl von Identifikatoren umfasst. Zum Beispiel weist der Netzknoten 70 ein Zellen-Identifikator-Feld 71, ein Feld 72 mit einem Zeiger zu Kindern dieses Netzknotens, ein Feld 73 mit einem Zeiger zu Eltern dieses Netzknotens und ein Feld 74 auf, welches das Schema identifiziert. Somit ist anhand der Fig. zu sehen, dass der Netzknoten 75 das Schema C ist, dass er, wie von dem Zeiger 76 angezeigt wird, ein Eltern-Schema A aufweist, und dass er ein Kind-Schema aufweist, welches Schema D ist.
In dieser Stufe des Prozesses wurde kein echter Graph erstellt, nur ein Satz von Tabellenstrukturen mit Zeigern zu anderen Tabellen strukturen. Die nächste Stufe besteht darin, dies in Zellen und Synapsen eines zellularen Netzwerks umzuwandeln. Der Umwandlungsvorgang wird nach der Erstellung eines Wurzelknotens und eines Konzentratorknotens, wie in dem folgenden Pseudo-Code beschrieben, durchgeführt.
8 zeigt die bei der Erstellung eines einfachen Graphen erforderlichen Stufen. 8(a) zeigt die erste Stufe des Erstellungsprozesses des Graphen; die Erstellung von Wurzel-(R) und Konzentrator(C)-Knoten. 8(b) zeigt die Erstellung des ersten Kindes 81 und in der in 8(c) gezeigten, nächsten Stufe wird ein Kind 82 des Kindes 81 erstellt. Dieses Kind 82 wird dann mit dem Konzentrator C verbunden. In der letzten Stufe wird ein weiteres Kind 83 des Wurzelknotens erstellt und mit seinem Kind 82 verbunden, welches ein vorher erstelltes Kind von Zelle 81 ist.
Die nächste Stufe stellt die „Überprüfung der Gültigkeit" des erstellten Schema-Graphen dar. Dies ist eine Überprüfung, die durchgeführt wird, um sicherzustellen, dass keine Meldungen verloren gehen oder in Endlosschleifen geraten und sich im Kreis durch dieselben Zellen des Graphen bewegen. Der Graph sollte ein gerichteter azyklischer Graph (DAG) sein und um dies zu überprüfen, darf eine von einer Zelle an ein Kind gesendete Meldung nicht von einer Elternzelle als eine Eingabe an diese Zelle zurückkommen.
Eine mit GRAPHCHECK bezeichnete Meldung wird an die Wurzelzelle gesendet und von dort auf eine synchrone Weise an jede Zelle und deren Kinder. Die Meldung GRAPHCHECK enthält ein Verzeichnis von Zell-Identifikatoren, durch welche die Meldung hindurchgegangen ist. Die Ankunft der Meldung an einer Zelle ruft einen Vergleich der Zell-ID dieser Zelle mit denen des Verzeichnisses von Zell-IDs auf, die bereits besucht wurden. Gibt es eine Übereinstimmung, dann wurde diese Zelle vorher besucht und es ist eine Schleife in dem Graph vorhanden. Bei derartigen Umständen wird der Graph als ungültig angesehen. Die Fehler werden festgehalten, indem der Zellstatus entsprechend gekennzeichnet wird.
Kindern jeder Zelle wird die Meldung zugesendet und wenn sie von jeder Kinderzelle ohne Fehler zurückkommt, wird der Zellstatus als gültig gekennzeichnet und diese Zell-ID wird aus dem Verzeichnis der Meldung entfernt. Die Meldung wird dann an die Elternzelle zurückgesendet, welche sie gesendet hat. Wenn diese Zelle von einer anderen Zelle überprüft wird, wird sie sofort das Ergebnis zurückschicken, dass sie gültig ist, indem sie ihren Status überprüft.
Der Pseudo-Code für die Meldung GRAPHCHECK lautet wie folgt:
Nachdem der generische Schema-Graph erstellt und überprüft ist, liegt der nächste Schritt darin, diesen generischen Graph auf einen kundenspezifischen Graphen zuzuschneiden. Dieser Schritt ist der von Kästchen 62 in 6 dargestellte Schritt. Er wird als „Anschalten" des Graphen oder Instantiieren des Graphen bezeichnet. Im Wesentlichen umfasst dieser Anschalt-Prozess ein Zuordnen von Kunden-Bestandsinformation, welche in dem CDM 11 gespeichert ist, zu dem Schema-Graphen, welcher in dem PDM 15 gespeichert ist, um einen Graph zu erstellen, der spezifisch für diesen Kunden ist.
Jeder Kunde weist eine Anzahl von Elementen auf, die abzurechnende Ereignisse erzeugen. Diese Elemente werden als Merkmals-Elemente (FI – Feature Items) bezeichnet und sie umfassen Telefonleitungen, Gebührenkarten und private Schaltungen. Die von den Merkmals-Elementen erzeugten Ereignisse werden gemäß von in der Kunden-Bestandsliste gespeicherten Abrechnungsoptionen berechnet. Die Optionen werden als Produkte bezeichnet. Ein Beispiel eines Produkts ist „Freunde und Familie", das oben beschrieben wurde.
Die Kunden-Bestandsliste umfasst alle Instanzen der Produkte, für die sich der Kunde anmeldet. Ein Produkt kann mehr als eine Instanz aufweisen, zum Beispiel weist das Produkt „Freunde und Familie" zwei Instanzen auf, wenn der Kunde zwei Telefonleitungen hat, die das Produkt benutzen. Jede Produktinstanz in der Kunden-Bestandsliste enthält alle kundendefinierten Attribute und Daten, die sich auf diese Instanz des Produkts beziehen.
Der Vorgang des „Anschalten" des Graphen erfordert ein Anweisen jeder Zelle des Graphen, wo die Produktinstanzen und die Instanzen der Schemen, die diese benutzen soll, zu finden sind. Um dies durchzuführen, weist jede Zelle zumindest eine Instanz-Tabelle auf. Ein Beispiel einer Tabelle wird unten angeführt:
Der angepasste Graph kann dann auf die Kundenereignisse angewendet werden (Kästchen 63 in 6), um die Rechnung zu erstellen.
Die an diesem Verfahren beteiligten Schritte werden in 9 gezeigt. Ein erster Schritt in dem Verfahren liegt darin, das Kundenereignisverzeichnis an die Konzentratorzelle des kundenspezifischen Graphen zu senden, dieser Schritt wird von dem Kästchen 90 dargestellt. Die Konzentratorzelle sendet die passenden Ereignisse über die geeigneten Verbindungen an ihre Elternzellen, wie von dem Kästchen 91 dargestellt wird. Die Konzentratorzelle wird dann zurückgesetzt, wie von dem Kästchen 92 dargestellt wird. Dies umfasst das Entfernen von kundenspezifischer Information. Die Zelle ist dann nicht länger „angeschaltet" und ist bereit, „angeschaltet" zu werden, um eine Zelle eines dem nächsten Kunden spezifischen Graphen zu bilden.
Jede Elternzelle erzeugt bei Erhalt der Ereignisse ein PEL für jede Schemeninstanz, die sie aufweist, wie von dem Kästchen 93 dargestellt wird. Die Schemeninstanzen laufen ab, wie von dem Kästchen 94 dargestellt wird, und die Ergebnisse werden an die entsprechenden Eltern dieser Zelle gesendet, wie von dem Kästchen 95 dargestellt wird. Wenn die Elternzelle die Wurzelzelle ist (Kästchen 96), dann haben die Daten den Graph durchflossen und der Vorgang endet, wie von dem Kästchen 97 dargestellt wird. Wenn die Elternzelle nicht die Wurzelzelle ist, werden die von den Kästchen 92 bis 96 dargestellten Schritte nochmals ausgeführt.
Somit müssen, indem der Graph auf die Kundendaten angewendet wird, eine Reihe von PELs den Graph „nach oben durchfließen" (nach oben im Sinn von Konzentrator zu Wurzel). 10 zeigt einen Teil eines derartigen Kunden-Graphen. Die Fig. zeigt drei Zellen 100, 101 und 103. Die Zelle 100 betrifft ein mit „PSTN-U" bezeichnetes Produkt, die Zelle 103 betrifft ein mit „OPTION 15" bezeichnetes Produkt und die Zelle 101 betrifft ein mit „Freunde und Familie" bezeichnetes Produkt. Daten fließen in diesen Teil des Graphen mittels der Verbindung 104 zu Zelle 100 und verlassen den Graphen mittels der Verbindung 105 von der Zelle 103. Eine Verbindung 106 besteht zwischen der Zelle 100 und der Zelle 101. Zwischen der Zelle 101 und der Zelle 103 gibt es eine Verbindung 107 und zwischen der Zelle 103 und der Zelle 100 gibt es eine Verbindung 108.
Man betrachte die Situation, wenn der Kunde zwei Leitungen besitzt, die mit 123 und 456 bezeichnet sind. Da es zwei Nummern gibt, gibt es zwei Instanzen des Schemas PSTN-U, eine Instanz für jede Nummer, und diese Zelle gibt zwei PELs 109 und 110 aus. PEL 109 bezieht sich auf Leitung 456 und PEL 110 bezieht sich auf Leitung 123. Der Kunde hat „OPTION 15" auf der Leitung 123 und sowohl „Freunde und Familie" als auch „OPTION 15" auf der Leitung 456 gewählt.
Somit wird das PEL 109 in der Richtung des Pfeils 111 zu Zelle 101 geleitet, da die Leitung 456 die Option „Freunde und Familie" aufweist. Die Zelle 101 wendet das Schema auf das eingegangene PEL 109 an und gibt ein anderes PEL 112 in der Richtung des Pfeils 113 über die Verbindung 107 aus. PEL 112 betrifft somit Anrufe über die Verbindung 456 zu Telefonnummern, die gemäß der Option „Freunde und Familie" ermäßigt sind.
Die Zelle 103 erwartet die Ankunft von sowohl PEL 112 als auch PEL 110. PEL 110 wird über die Verbindung 108 in der Richtung des Pfeils 114 zu Zelle 103 geleitet. Diese Zelle verarbeitet die eingegangenen PELs, indem sie die gesamte Telefonbenutzung auf beiden Leitungen ermäßigt. Ein PEL 115 wird von der Zelle 113 über die Verbindung 105 in der Richtung des Pfeils 116 an die nächste Zelle in dem Graphen geleitet (nicht gezeigt). Das ausgegebene PEL 115 enthält alle Datensätze der Telefonbenutzung für beide Leitungen, auf welche die entsprechenden Ermäßigungen angewendet wurden.
Ein wichtiger hier anzumerkender Punkt liegt darin, dass jedes PEL ein Datenfeld aufweist, welches das PEL anzeigt, von dem es abstammt. Dadurch können Abrechnungsfehler zu dem fehlerhaften Schema zurückverfolgt werden. Wenn die Schemeninstanzen ausgeführt werden, wird ein PEL-„Arbeitsblatt" erstellt. Das „Arbeitsblatt" enthält Information über die Ausführung des kundenspezifischen Graphen. Für das in 10 dargestellte Beispiel würde das PEL-„Arbeitsblatt" wie in 11 gezeigt sein.
Ein MEL 117 weist eine Anzahl von Ereignissen auf, die in der 11 mit a bis k bezeichnet werden. Von diesen Ereignissen werden a, c, e, f, h, j an die Zelle 100 geleitet und durchfließen den Teil des in 10 dargestellten Graphen. Diese Ereignisse bilden das über die Verbindung 104 an die Zelle 100 gesendete eingegebene PEL, aber weisen Zeiger 118 zurück zu ihren Gegenstücken in dem MEL 117 auf. Das eingegebene PEL wird von der Zelle 100 effektiv aufgeteilt in das PEL 100, welches direkt an die Zelle 103 gesendet wird und die Ereignisse c, f, j enthält, und das PEL 111, welches an die Zelle 101 gesendet wird und die Ereignisse a, e und h enthält. Die an die Zelle 101 gesendeten Ereignisse werden verarbeitet, um PEL 112 zu bilden, und diese weisen Zeiger 121 zurück zu PEL 120 auf. Die Ereignisse von PEL 109 werden von der Zelle 101 verarbeitet, um PEL 112 zu bilden, welche an die Zelle 103 gesendet wird. Das Ausgabe-PEL 115 weist die Ereignisse a, e, h, j mit Zeigern 122 zurück zu PEL 109 auf.
Nachdem die Ereignisse verarbeitet sind und den Graphen verlassen, werden sie an den IPE 4b des CBP 4 geleitet, wo die Rechnung ausgedruckt und an den Benutzer gesendet wird, wie von dem Kästchen 64 in 6 dargestellt wird.
Das Verfahren (Schritt 62 bis 64) wird dann für den nächsten Kunden wiederholt, wie von Kästchen 65 in 6 dargestellt wird.
Das oben beschriebene Verfahren berücksichtigt nicht die Information über das „unterscheidende Datum", welche sich in einem Ereignis befindet. Dies wird wichtig, weil die kundenspezifischen Daten eine Änderung der Bedingungen während des Abrechnungszeitraums erfahren können, so dass ein Ereignis, das verarbeitet wird, verschiedenen Verbindungen zwischen Zellen (oder Schemen) zu unterschiedlichen Zeiten folgen muss. Beispielsweise kann sich der Abrechnungszeitraum von Januar bis Februar erstrecken, aber der Kunde kann erst im Februar begonnen haben, an der Option „Freunde und Familie" für seine Leitung 456 teilzunehmen, obwohl er den Dienst „OPTION 15" die gesamte Zeit für diese Leitung benutzt.
Unter Bezugnahme auf 12 und der Betrachtung der Verbindungen von dem Konzentratorknoten 130 an den Netzknoten 131 mit der „OPTION 15" und den Netzknoten 132 mit „Freunde und Familie" werden diese Verbindungen zugehörige Datum/Zeit-Daten erfordern, um die Veränderung der Beziehung anzuzeigen, so dass ein Ereignis korrekt „geleitet" werden kann. Dies gilt deswegen, weil bis Februar ein Kundenereignis von dem Konzentratorknoten 130 direkt zu dem Netzknoten 131 mit der „OPTION 15" fließen sollte. Mit Beginn des Februars jedoch sollten Ereignisdaten für die Leitung 456 der Verbindung zu dem Netzknoten 132 mit „Freunde und Familie" folgen und erst dann zu dem Netzknoten 131 mit der „OPTION 15".
Es ist möglich, hinsichtlich dieses Umstandes eine Verbindung zwischen zwei Zellen zu „markieren". Sobald zwei Zellen instantiiert sind, ist es möglich, in den Instanzen-Tabellen der beiden Zellen Überlappungen zu finden. Diese Überlappungen zeigen dann an, welche Bereiche auf welche Verbindungen angewendet werden, so dass Ereignisdaten über die richtige Verbindung fließen, wenn die Daten von dem Graph verarbeitet werden.

Claims

Verfahren zum Verarbeiten von Daten zum Erstellen einer Rechnung für Benutzung eines Kommunikationsnetzwerks, wobei das Verfahren aufweist i) Empfangen von Ereignisdaten (117) von dem Kommunikationsnetzwerk, wobei die Ereignisdaten (117) eine Vielzahl von Netzwerkbenutzungsereignissen durch einen Benutzer über eine Zeitdauer betreffen; ii) Vorsehen eines Satzes von Schemen (70, 75), welche auf für Benutzer zur Verfügung stehende Kommunikationsdienste mittels des Netzwerks anwendbar sind, wobei jedes Schema (70, 75) dienstspezifische Daten und zumindest eine Regel, oder einen Identifikator für zumindest eine Regel, zur Verwendung bei der Verarbeitung von erhaltenen Ereignisdaten (117) hinsichtlich dieses Dienstes aufweist; iii) Speichern benutzerspezifischer Information, die einen Satz von Diensten identifiziert, welche durch den Benutzer aus den über das Netzwerk zur Verfügung stehenden Kommunikationsdiensten ausgewählt und zur Benutzung zugeteilt werden; iv) Wählen eines Schemas oder mehrerer Schemen (70, 75), das/die auf die erhaltenen Ereignisdaten (117) anwendbar ist/sind, aus dem Satz von Schemen (70, 75) gemäß der für diesen Benutzer gespeicherten benutzerspezifischen Information; und v) Anwenden des gewählten Schemas/der gewählten Schemen (70, 75) auf die Ereignisdaten (117), um die Ereignisdaten (117) zur Rechnungserstellung zu verarbeiten.
Verfahren gemäß Anspruch 1, wobei das Verfahren ferner aufweist vi) Speichern einer generischen Datenverarbeitungsstruktur mit einer geordneten Menge von Datenverarbeitungsknoten, die zum Verarbeiten von Ereignisdaten (117), welche sich auf die über das Netzwerk verfügbaren Kommunikationsdienste beziehen, strukturiert sind, wobei jeder Netzknoten ein zugehöriges Schema (70, 75) aus dem Satz von Schemen (70, 75) aufweist, wobei der Schritt iv) des Wählens eines Schemas oder mehrerer Schemen (70, 75) ausgeführt wird, indem eine Untermenge (A, B, C, D) der geordneten Menge von Datenverarbeitungsknoten gewählt wird, welche Schemen (70, 75) zum Verarbeiten von Netzwerk-Ereignisdaten (117) hinsichtlich des gewählten Dienstsatzes für den Benutzer zugeordnet haben.
Verfahren gemäß Anspruch 2, welches ferner aufweist, bevor das gewählte Schema/die gewählten Schemen (70, 75) auf die Ereignisdaten (117) angewendet wird/werden, Instantiieren jedes Knoten der Untermenge (A, B, C, D) der Datenverarbeitungsknoten mit benutzerspezifischen Daten in Bezug auf den gewählten Satz von Diensten.
Verfahren gemäß einem der Ansprüche 2 oder 3, wobei ein Element der Ereignisdaten (a–k) zumindest ein unterscheidendes Datum aufweist und der Schritt, in welchem Schemen (70, 75) zum Verarbeiten dieses Elements der Ereignisdaten (a–k) gewählt werden, den Schritt des Lesens des unterscheidenden Datums und Auswählens eines Schemas aus alternativen Schemen gemäß dem Datum umfasst.
Verfahren gemäß einem der Ansprüche 3 oder 4, wobei zumindest ein Knoten der Untermenge (A, B, C, D) der Datenverarbeitungsknoten mit benutzerspezifischen Daten, welche eine Datumsinformation hinsichtlich eines Dienstes umfassen, instantiiert wird, wobei die Datumsinformation beim Verarbeiten von Netzwerk-Ereignisdaten (117) hinsichtlich zumindest eines Dienstes des gewählten Satzes von Diensten verwendet wird.
Verfahren gemäß Anspruch 1, wobei die auf die Daten anzuwendenden Schemen (70, 75) als eine verbundene Knotenstruktur von untereinander zusammenhängende Schemen (70, 75) ausgebildet sind und die zu verarbeitenden Ereignisse in die Struktur eingegeben werden.
Verfahren gemäß Anspruch 6, wobei die Ereignisse in einem Haupt-Ereignisverzeichnis (117) gelistet werden und die verbundene Knotenstruktur als ein Graph von Schemen (70, 75) ausgebildet ist, wobei jedes Schema (70, 75) zumindest einige der Ereignisse (109, 115, 120) des Haupt-Ereignisverzeichnisses (117) verarbeitet und die verarbeiteten Ereignisse (a–k) an andere Zellen weitergibt und zumindest einige der Ereignisse (a–k) des Haupt-Ereignisverzeichnisses (117) in einen ersten Netzknoten des Graphen derart eingibt, dass die Ereignisse durch Zellen in dem Graphen an eine letzte Zelle gehen, von welcher sie von dem Graphen in einer verarbeiteten Form ausgegeben werden.
Verfahren gemäß einem der Ansprüche 6 oder 7, wobei der Graph gebildet wird, indem zumindest einige der Zellen in einem generischen Graphen aktiviert werden.
Verfahren gemäß einem der Ansprüche 6 bis 8, wobei der generische Graph aus einem Satz von Information über Produkte und Dienste aufgebaut wird, welche in oder in Verbindung mit dem Kommunikationsnetzwerk verfügbar sind.
Verfahren gemäß Anspruch 9, wobei der Satz von Information in einer Datenbank gespeichert wird, welche aktualisiert werden kann, um auf eine Änderung bei den Produkten und Diensten, welche in oder in Verbindung mit dem Kommunikationsnetzwerk verfügbar sind, zu reagieren.
Verfahren gemäß einem der Ansprüche 6 bis 10, wobei zumindest einige der verarbeiteten Ereignisse (a, c, e, f, h, j) Zeiger zu den Ereignissen umfassen, von welchen sie abgeleitet werden.
Verfahren gemäß einem der Ansprüche 6 bis 11, wobei jedes Schema (70, 75) eine oder mehrere aus einer Datenbank von Regeln stammende Regel(n) aufweist.
Verfahren gemäß Anspruch 12, wobei zumindest eine Regel für mehr als ein Schema (70, 75) entweder alleine oder in Kombination mit einer anderen Regel verwendet wird.
Verfahren gemäß Anspruch 12 oder Anspruch 13, das den Schritt des Bildens von zumindest einem Schema (70, 75) aus einer oder mehreren Regel(n) umfasst.
Verfahren gemäß einem der Ansprüche 6 bis 14, wobei zwischen Zellen Verbindungen errichtet werden, entlang denen verarbeitete Ereignisse zwischen den Zellen fließen können, wobei zumindest einige der Verbindungen von einem zeitlichen Kriterium abhängen, ob Ereignisse auf der Verbindung zugelassen werden.
Verfahren gemäß einem der Ansprüche 6 bis 15, wobei die Ergebnisse der verarbeiteten Ereignisse (a, c, e, f, h, j) eine Anzeige der Ereignisse umfassen, von welchen sie abgeleitet werden.
Vorrichtung zum Verarbeiten van Daten, um eine Rechnung für die Benutzung eines Kommunikationsnetzwerks zu erstellen, wobei das Verfahren aufweist i) Mittel, die eingerichtet sind, um im Betrieb Ereignisdaten (117) von dem Kommunikationsnetzwerk zu empfangen, wobei die Ereignisdaten (117) eine Vielzahl von Netzwerkbenutzungsereignissen durch einen Benutzer über eine Zeitdauer betreffen; ii) Mittel, die eingerichtet sind, um im Betrieb einen Satz von Schemen (70, 75) vorzusehen, welche auf für Benutzer zur Verfügung stehende Kommunikationsdienste mittels des Netzwerks anwendbar sind, wobei jedes Schema (70, 75) dienstspezifische Daten und zumindest eine Regel, oder einen Identifikator für zumindest eine Regel, zur Verwendung bei der Verarbeitung von erhaltenen Ereignisdaten (117) hinsichtlich dieses Dienstes aufweist; iii) Mittel, die eingerichtet sind, um im Betrieb benutzerspezifische Information zu speichern, die einen Satz von Diensten identifiziert, welche durch den Benutzer aus den über das Netzwerk zur Verfügung stehenden Kommunikationsdiensten ausgewählt und zur Benutzung zugeteilt werden; iv) Mittel, die eingerichtet sind, um im Betrieb aus dem Satz von Schemen (70, 75) gemäß der für diesen Benutzer gespeicherten benutzerspezifischen Information ein Schema oder mehrere Schemen (70, 75) zu wählen, das/die auf die erhaltenen Ereignisdaten (117) anwendbar ist/sind; und v) Mittel, die eingerichtet sind, um im Betrieb das gewählte Schema/die gewählten Schemen (70, 75) auf die Ereignisdaten (117) anzuwenden, um die Ereignisdaten (117) zur Rechnungserstellung zu verarbeiten.
Vorrichtung gemäß Anspruch 17, wobei Mittel vorgesehen sind, um aus dem Schema (70, 75) eine verbundene Knotenstruktur zu bilden.
Vorrichtung gemäß Anspruch 17 oder Anspruch 18 mit Mitteln, um aus den Ereignissen ein Haupt-Ereignisverzeichnis zu bilden.