DE69730735T2

DE69730735T2 - Softwaresystem mit universelle kompatibilität für dienste in kommunikations-und informationsverarbeitungsnetze

Info

Publication number: DE69730735T2
Application number: DE69730735T
Authority: DE
Inventors: Peter David STRICKLAND; Matthew Gordon DEANS
Original assignee: Nortel Networks Ltd
Current assignee: Nortel Networks Ltd
Priority date: 1996-11-29
Filing date: 1997-11-25
Publication date: 2005-02-10
Anticipated expiration: 2017-11-26
Also published as: WO1998024223A2; JP2002516652A; CA2275132C; WO1998024223A3; EP0947085B1; CA2275132A1; EP0947085A2; DE69730735D1

Description

Hintergrund der Erfindung
1. Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich allgemein auf die Bereitstellung von Diensten in Kommunikationsnetzen und insbesondere auf Software-Systeme zur Sicherstellung einer Kompatibilität zwischen Netzwerk-Teilsystemen, die Endbenutzer-Dienste und dergleichen bereitstellen. Weiter bezieht sich die Erfindung insbesondere auf eine universelle Systemarchitektur und ein universelles Verfahren, das unabhängig von der Art irgendeines bestimmten Teilsystems, Dienstes oder Gerätes ist. In einer besonders speziell bevorzugten Anwendung umfasst das Kompatibilitätssystem eine Familie von Software-Paketen, die ein Echtzeit-Zusammenwirken zwischen unabhängigen autonomen Netzwerk-Diensten ermöglichen, eine Verknüpfung zwischen Funktionalitäten, wie z. B. Sprachpost, Fernsprechauskunft, interaktive Sprachausgabe und Internetdiensten bereitstellen. Obwohl diese Anwendung für Telekommunikationsdienste dient, kann das universelle System ein Zusammenwirken von unabhängigen autonomen Informationsverarbeitungssysteme bewirken. Es hat einen unerreichten Wert, wenn ein stabiles Echtzeit-Betriebsverhalten erforderlich ist und die Wechselwirkung zwischen den Diensten eine explizite Kontext abhängige Konkurrenzbereinigung erfordert.
2. Verwandter Stand der Technik
Bei der vorliegenden Systemumgebung, beispielsweise in der Telefonie, ist ein unabhängiger autonomer Dienst ein Dienst, der so entwickelt wurde, dass er eine bestimmte gut definierte Funktionalität bereitstellt. Diese unabhängigen autonomen Dienste werden aufgerufen und verwendet, und sie können aufgerufen werden, um einen Dienst zu realisieren. Die unabhängigen autonomen Geräte haben jedoch keine Möglichkeiten, mit anderen autonomen Geräten zu kommunizieren. Somit sind die Geräte und Dienste nicht integriert und kommunizieren insgesamt nicht miteinander (das heißt sie nutzen keine Daten oder Ressourcen gemeinsam). Wenn eine Integration erfolgt, so erfolgt sie von Fall zu Fall, wobei Programmierer spezielle Lösungen für spezielle Probleme entwickeln, und sie wird normalerweise von Ausrüstungs-Herstellern bereitgestellt, die proprietäre, eine von einem Hersteller stammende Gruppe von Systemen verkaufen.
In dem US-Patent 5 404 396 vom 4. April 1995 auf den Namen von Brennan mit dem Titel FEATURE INTERACTION MANAGER erfolgt eine Befassung mit einem speziellen Problem, das in Telefonsystemen als „Merkmals-Wechselwirkung" bekannt ist, bei dem, wenn die Anzahl von verfügbaren Merkmalen, die in einem Telekommunikations-Vermittlungsnetzwerk angeboten werden, ansteigt, die mögliche (unkontrollierte) Wechselwirkung zwischen den Merkmalen von sehr hoher Bedeutung wird und eine Quelle einer möglichen Verwirrung des Teilnehmers sowie von Fehlern in dem Netzwerk darstellt. Aus diesem Grund sind Merkmals-Verwaltungseinrichtungen innerhalb des Vermittlungssystems vorgesehen, die die Funktionalität jedes Merkmals in einer derartigen Weise verwalten, dass die unterschiedlichen Aspekte der Funktionalität koordiniert werden. Eine Merkmalsverwaltung überwacht jedes Ereignis, das eintritt, und lenkt dieses Ereignis an die Merkmalslogik des Softwareblockes, der ein Merkmal realisiert, das dieses Ereignis für einen Aufruf und/oder eine Steuerung erfordert. Wenn jedoch mehr als ein Merkmal das gleiche Ereignis erfordert, so wird die Situation komplizierter und erfordert, dass der Zugang an bestimmte Merkmale ausgesetzt und/oder mit Prioritäten versehen wird, wenn andere Merkmale durch einen Teilnehmer in Gebrauch sind. Die Lösung besteht darin, eine Merkmal-Wechselwirkungs-Verwaltung (FIM) zwischen einer Telekommunikations-Vermittlungsplattform innerhalb eines Netzwerkes und der Merkmals-Logik einzufügen, die Verbindungsmerkmale an Teilnehmer bereitstellt, die die Plattform verwenden. Die Steuerung wird innerhalb der Schnittstelle zwischen der Feststellung der Ereignisse innerhalb des Vermittlungssystems und der Realisierung der Telekommunikationsdienste durch die Merkmals-Logik eingefügt, um die Wechselwirkung verschiedener einzelner der Vielzahl von Merkmalen zu verwalten, die für einen Teilnehmer bereitgestellt werden. Das System wertet Ereignisse in dem Netzwerk aus, um jedes Merkmal von den anderen Merkmalen zu isolieren, und ordnet sie lediglich über die Merkmal-Wechselwirkungs-Verwaltung zu.
Auf dem Gebiet der Informationsverarbeitung weist die internationale Anmeldung PCT/US95/15432, veröffentlicht am 6. Juni 1996 als WO 96/17296 mit dem Titel METHOD AND APPARATUS FOR IMPLEMENTING A MESSAGE DRIVEN PROCESSOR IN A CLIENT-SERVER ENVIRONMENT die folgende Zusammenfassung auf:
Ein Mitteilungs-gesteuerter Prozessor arbeitet als Middleware zwischen Klienten und Unterstützungsrechnern oder Servern in einem großen Klienten-Server-System, um die Anzahl von gleichzeitigen Sitzungen zu verringern, die durch das Netzwerk unterstützt werden müssen, und um eine gemeinsame Klienten-Benutzer-Schnittstelle für divergierende Unterstützungsrechner-Systeme zu ermöglichen. Anforderungen höherer Ebene von einem Klienten zur Unterstützung einer Geschäftsfunktion werden in Arbeitsabläufe umgesetzt, die mehrfache Anforderungen an Unterstützungsserver durch den Mitteilungs-gesteuerten Prozessor beinhalten können. Informationen, die sich aus Arbeitsabläufen ergeben, und Informationen, die von Unterstützungsservern zurückgewonnen werden, können in eine einzige Antwort-Mitteilung an den anfordernden Klienten integriert werden.
Zusammenfassung der Erfindung
Das Problem in der Telefonie besteht darin, dass eine Verletzung von Annahmen eine Hauptquelle von unvorhersagbaren Merkmalen von Wechselwirkungen ist. Diese Wechselwirkungen entstehen typischerweise, wenn neue Merkmale und Netzwerkfähigkeiten, die, ohne es zu wissen, vorher vorhandene technologische Annahmen verletzen, eingeführt werden. Die übliche Antwort besteht darin, Definitionen und Realisierungen für vorhandene (sogenannte „überkommene") Dienste komplizierter zu machen, um jede neue Änderung in der Umgebung zu berücksichtigen. Als Ergebnis wird das System weniger testbar und weniger elastisch für zukünftige Änderungen.
Als Beispiel sei der Anklopfdienst betrachtet. Die grundlegende Idee eines Anklopfdienstes besteht darin, den Benutzer darüber zu informieren, dass ein neuer Anruf angekommen ist, und einen Mechanismus für den Benutzer bereitzustellen, auf den Anruf zu antworten. In idealer Weise sollte die Dienstelogik so einfach sein. In der Praxis bettet die Dienstelogik große Anzahlen von Annahmen über Beschränkungen darüber ein, wann ein Hinweis gegeben werden kann (nur wenn der Anruf „stabil" ist, was bedeutet, dass die Anrufverarbeitung nicht mehr im Ablauf begriffen ist), welche Art von Hinweis geliefert werden sollte (spezieller „Piepton"), wieviele Anrufe sich im „Warte"-Zustand befinden dürfen (einer), und wie auf einen Anruf geantwortet wird (beispielsweise durch Schließen des Gabelschalters). Obwohl diese Zwangsbedingungen in einer POTS- (einfacher alter Telefondienst) Umgebung von Bedeutung sind, machen sie bei Systemen mit ISDN, höher entwickelten Endgeräten oder fähigeren Brückenschaltungen keinen Sinn. Die Zwangsbedingungen führen auch zu Problemen, wenn der Benutzer andere Dienste hat, die die gleichen Signale (wie z. B. die gleichen DTMF-Signale) für unterschiedliche Zwecke verwenden. Solche Zwangsbedingungen sollten keinen Teil einer Dienstedefinition bilden und sollten nicht in Realisierungen codiert werden. Statt dessen sollten sie dadurch behandelt werden, dass ein umfangreicherer Satz von Wechselwirkungen (das heißt eine breitere intelligentere Kapazität für eine Kommunikation) zwischen Netzwerk-Ressourcen und der Dienstelogik ermöglicht wird. Die vorgeschlagene Architektur der vorliegenden Erfindung unterstützt diese intelligenteren Wechselwirkungen.
Das Konzept von Rollen ist weiterhin nützlich beim Verständnis der Typen von Wechselwirkungen, die aus einer Verletzung von Annahmen entstehen können. Viele Rollen werden von verschiedenen Einheiten in dem derzeitigen Telekommunikationssystem gespielt. Benutzer können die Rollen von Inhabern, Teilnehmern, Rechnungszahlern, eines angerufenen Teilnehmers, eines Anrufkoordinators und andere Rollen ausfüllen. Dienste füllen Rollen einer Besetztzustands-Behandlungsfunktion, einer Anrufabschluss-Blockierung, einer Anrufumlenkung und andere Rollen aus, wobei das Vorgabeverhalten der üblichen Verbindungsverarbeitung ersetzt wird. Eine fehlende Trennung zwischen den verschiedenen Rollen, die diese Einheiten spielen, stellt eine wichtige Quelle von FI (Merkmals-Wechselwirkung) in heutigen Systemen dar. Eine Rollenverwechslung wird in der folgenden Weise offenkundig:

– die Abrechnung könnte an den falschen Teilnehmer gehen, beispielsweise wenn ein Dienst hinsichtlich der Annahme fest codiert ist, dass der Benutzer des Telefons der Dienstebenutzer ist.
– Anrufe könnten zugestellt werden, wenn dies unerwünscht ist, sie könnten in fehlerhafter Weise gesperrt werden, oder sie könnten an den falschen Teilnehmer gelenkt werden, weil das System nicht in geeigneter Weise das Ziel des Anrufes feststellen konnte.

Eine Rollenverwirrung trägt teilweise zu Signalisierungs-Zweideutigkeiten bei, weil die Dienstelogik in vielen Fällen anzunehmen scheint, dass ein einzelner Dienst der einzige Benutzer eines bestimmten Signals oder Merkmals ist, wie z. B. eines speziellen Hinweismusters auf die Logik für einen bestimmten Anrufdienst. Die Dienstelogik nimmt in vielen Fällen beispielsweise an, dass kein anderer Dienst das kurzzeitige Schließen des Gabelschalters verwendet. Dienste nehmen auch in manchen Fällen an, dass der einzig zutreffende Begriff von „Belegt" das Ereignis ist, das von der Vermittlung berichtet wird (das heißt dass die Teilnehmerleitung belegt ist), wobei die Möglichkeit ignoriert wird, dass ein Satz von Diensten eine logische Sammelgruppe erzeugen könnte, wobei in diesem Fall „Belegt" bedeuten könnte, dass alle Endgeräte in dieser Gruppe im Gebrauch sind.
Allgemeine Attribute der Lösung
Es gibt viele gute Gründe, die Komponenten eines großen Systems, wie z. B. eines Telefonnetzwerkes, in kleinere getrennte Teilsysteme zu zerlegen. Ein Hauptgrund besteht darin, dass das System einfacher zu verstehen und zu modifizieren wird. Wenn man sich mit FI befasst, so wird ein weiterer Grund wichtig: die Unterteilung eines Telekommunikationssystems in Komponenten-Einheiten bestimmt den Satz von Charakteristiken und Voraussetzungen, die für Systementwickler und Systembenutzer verfügbar sind. Wenn die Voraussetzungen richtig gewählt sind, ermöglichen sie es Entwicklern und Benutzern, die Unterschiede auszudrücken, die erforderlich sind, damit die Dienste eine Konfusion, eine Zweideutigkeit und die resultierende unkontrollierte FI vermeiden.
Frühere Arbeiten hinsichtlich der Quellen und Ursachen einer unkontrollierten FI und hinsichtlich der Analysen von Telekommunikations-Merkmalbeschreibungen und Breitband-Diensteanforderungen haben gezeigt, dass spezielle Aufteilungen von Angelegenheiten innerhalb eines Telekommunikationssystems dazu beitragen, viele Fälle von FI zu verringern oder zu beseitigen. Speziell stellt die Trennung von:

– Benutzern von Endgeräten;
– Anrufen von Verbindungen;
– Benutzersitzungen von Diensten; und
– Diensten und Benutzersitzungen von der Verwaltung des Netzwerkes/der Ressourcen

Zusätzlich zu den vorstehend ausgeführten speziellen Trennungen oder Unterscheidungen bedingt die Trennung von Angelegenheiten in einer Telekommunikationsarchitektur die Unterscheidung zwischen Charakteristiken (wie z. B. Belegt-Hinweis) und physikalischen Manifestationen dieser Merkmale (beispielsweise bestimmte Signale). Eine Trennung bedingt auch das Unterteilen des Systems in Komponenten, denen jeweils bestimmte Rollen zugewiesen werden können.
Die vorgeschlagene Architektur trennt Angelegenheiten durch Unterstützen getrennter Logikfunktionen für:

– Programme, die Benutzerprofile und Vorlieben durchsetzen,
– Programme, die Ressourcen, wie z. B. Endgeräte, Vermittlungen, Brücken, interaktive Sprache- (oder Video-) Beantwortungseinheiten steuern; und
– Programme, die die grundlegende Logik von Diensten ausführen.

Diese Trennung von Angelegenheiten wird durch die Verwendung von Software-Agenten erzielt, die jede der Arten von Einheiten darstellen – Benutzer, Ressourcen und Dienste – in einer Agenten basierten Architektur, um die erforderliche Kompatibilität bereitzustellen. Das Ziel der Architektur besteht darin, sehr stark die Anzahl von Annahmen zu verringern, die direkt in der Architektur verwirklicht sind, und dadurch die Wahrscheinlichkeit zu vergrößern, dass neue Dienste in geeigneter Weise mit vorhandenen (als „überkommene" bezeichnet) Diensten zusammenwirken.
In der Architektur sind die grundlegenden Einheiten wie folgt:

– Ressourcen (Endgeräte-Ausrüstungen, Netzwerk-Ausrüstungen, Sprachkreise, Brücken, Signalsierungskanäle, Signale und Datenbanken);
– Benutzer (unter Einschluss von Anrufern, angerufenen Teilnehmern, Abrechnungs-Teilnehmern, Diensteanbietern, Ausrüstungsbesitzern);
– Diensten (die Logikfunktion als solche); und
– Signale, die zwischen und unter Benutzern, Ressourcen und Diensten ausgesandt werden).

Die Kompatibilität ermöglicht es Diensten, wie z. B. Anrufzentralen, Kunden-Datenbanken, Sprachpost-Systemen und Datenbanken, in der Lage zu sein, Sitzungsinformationen gemeinsam zu nutzen und zusammenwirkend auf Sitzungsereignisse anzusprechen (wie z. B. den Anruf-Ursprung oder eine Benutzer-Dateneingabe). Die Architektur kann weiterhin an mehreren Stellen angeordnete Telekommunikationsdienste so stromlinienförmig ausgestalten, dass Ressourcen, wie z. B. Sprachpost-Server und Netzwerk-Datenbanken in effektiverer und kohärenter Weise benutzt werden.
Heute gibt es sehr wenige Fälle, in denen dieser Grad der Integration erzielt wird. In einer stärker typischen Weise werden einzelne Sprache- oder Daten-Telekommunikationsdienste auf unabhängig funktionierenden Systemen bereitgestellt. Beispielsweise kann die Sprachpost von dem Produkt eines Vertreibers bereitgestellt werden, die automatische Anrufverteilung (ACD) von einem anderen, und interaktive Sprachbeantwortungsdienste (IVR) von einem dritten Produkt. Kundendaten oder Firmenverzeichnisse werden üblicherweise auf Datenbanken gehalten, die von diesen Produkten getrennt sind. Für jeden Dienst, den ein Unternehmen oder ein Betreiber bereitstellen will, müssen sie ein oder mehrere ausschließlich für diesen Zweck bestimmte Systeme kaufen. Weiterhin können, obwohl jedes System ein gewisses Ausmaß an „Programmierbarkeit" bereitstellen kann, sie nicht zusammenwirken, mit Ausnahme von sehr begrenzten Fällen. Schließlich sind, obwohl nunmehr einige wenige Systeme vorhanden sind, die eine gewisse Verknüpfung zwischen unabhängigen autonomen Telekommunikationsdiensten oder Datenbanken bereitstellen, diese Systeme üblicherweise auf Produkte eines bestimmten Vertreibers oder auf ein bestimmtes Produkt beschränkt, wie z. B. ein ACD-System. Um diese Integration zu erzielen behandelt die Kompatibilität jedes der autonomen Systeme als eine Ansammlung von Objekten, die dann in einen Software-Bus „eingestöpselt" werden, genauso wie ein Satz von unabhängigen Computern und Druckern in ein körperliches Kommunikations-LAN eingesteckt werden kann. Sobald die unabhängigen autonomen Systeme ineinander gesteckt sind, erleichtert die Kompatibilität ein Zusammenwirken zwischen diesen. Die unabhängigen autonomen Plattformen können Produkte von irgendwelchen Vertreibern sein.
Insgesamt liegt der Wert der Kompatibilität nicht in einer „Killer-Anwendung" sondern in ihrer Fähigkeit, in kosteneffektiver Weise überkommene (das heißt vorhandene) Dienste und Fähigkeiten miteinander sowie mit neuen Netzwerkfunktionen und Produkten zu integrieren. Dies ermöglicht es Besitzern von unabhängigen autonomen Diensteplattformen, Dienste so kundenspezifisch anzupassen, dass sie spezialisierte Marktnotwendigkeiten erfüllen und die Vergeudung von Ressourcen in ihrer sich entwickelnden Telekommunikationsumgebung zu vermeiden.
Das vorliegende Verfahren stellt eine Kompatibilität zwischen ungleichartigen Diensten bereit, die von einer Vielzahl von Dienste-Ressourcengeräten in einem Kommunikationsnetzwerk oder in einem Informationsverarbeitungsnetzwerk bereitgestellt werden, gekennzeichnet durch:

(a) Zuordnen eines Software-Agentenmoduls SAM zu jedem Diensteressourcengerät SRD zur Schnittstellenverbindung des SRD mit einem Software-Mitteilungsbus SMB;
(b) Schaffen eines temporären Softwarekompatibilitäts-Steuerungs-Moduls CC für jede Dienstesitzung, die durch Netzwerk-Teilnehmer eingeleitet wird;
(c) Unterteilen des CC-Moduls in zumindest zwei Teilmodule von denen eines RH zur Abwicklung von Diensten dient, an denen mehrere SRD's beteiligt sind, und eines EH zur Abwicklung von Ereignissen dient, die von RH erzeugt werden, indem bewirkt wird, dass ein Ereignis einen Zugriff auf ein ausgewähltes SRD über sein SAM ausführt, wodurch eine Kompatibilität zwischen den SRD's erzielt wird, auf die der Zugriff erfolgt.

Netzwerk-Teilnehmer bedeutet hier irgendwelche Dienste, Ressourcen oder Einheiten, die durch einen Proxy oder einen Agenten dargestellt sind.
Kurze Beschreibung der Zeichnungen
Die bevorzugte Ausführungsform der vorliegenden Erfindung wird nunmehr in Verbindung mit den beigefügten Zeichnungen beschrieben, in denen:
1 ein Hintergrund-Blockschaltbild ist, das die bevorzugte Verteilung der Kompatibilitätskontrolle in einem intelligenten Telefonnetzwerk zeigt;
2 ein Blockdiagramm höherer Ebene ist, das Funktionsblöcke der in 1 gezeigten Kompatibilitätssteuerung zeigt;
3 die Agenten basierte Architektur der Kompatibilitätssteuerung nach 2 zeigt;
4 ein Ablaufdiagramm höherer Ebene ist, das den Ablauf der Wechselwirkung nach einer Anforderung für ein vorgegebenes Diensteressourcengerät zeigt;
5 ein Ablaufdiagramm höherer Ebene zeigt, das den Ablauf der Verarbeitung zeigt, sobald ein Ereignis aus der Wechselwirkung in 4 erzeugt wurde; und
6 den Ablauf der Wechselwirkung zwischen CC-Agenten/Proxies für das spezielle Beispiel eines persönlichen Agenten-Meta-Dienstes zeigt.
Ausführliche Beschreibung der bevorzugten Ausführungsformen
In 1 der Zeichnungen ist in allgemeinen Ausdrücken die Netzwerkumgebung erläutert, in der das vorliegende Kompatibilitätssystem arbeitet. Das gezeigte Telefonie-Netzwerk umfasst Einrichtungen zur Bereitstellung einer Anschluss möglichkeit, wie z. B. einer DMS (®)-Vermittlung der Firma Northern Telecom oder einer #5 ESS-Vermittlung der Firma Lucent in einem Vermittlungsamt, einer Nebenstellenanlage (PCX), einer ACD und dergleichen (SO) 10, und einen Mitteilungs-Kompatibilitätsbus 11, auf den eine Kompatibilitätssteuerung (CC) 12 zugreift. Das Kompatibilitäts-Steuerungs- (CC-) Modul 12A befindet sich in einer Rechenplattform in dem SO 10 und tauscht Mitteilungen mit Kompatibilitäts- (C-) Modulen 12B, 12C, 12D, 12E, 12F und 12G aus, die sich in einer Dienstesteuerungsstelle SCP 13 des Telefonsystems und anderen Ressourcen befinden und mit diesen in Schnittstellenverbindung stehen, von denen lediglich einige vorhanden sein können, wie z. B. eine allgemeine Rechenplattform 14 (die eine weitere Kompatibilitätssteuerung unterstützen kann) ein interaktives Sprachbeantwortungs-IVR-System 15, ein Sprachpostsystem 16, ein E-Mail-Mitteilungsaustauschsystem 17 oder ein Spracherkennungssystem 18. Dies sind lediglich Beispiele von Ressourcen, und andere (nicht gezeigte) Ressourcen können vorhanden sein. Diese Ressourcen und Systeme (das heißt Merkmale) können anderenfalls in unkontrollierter Weise miteinander in Wechselwirkung treten, wenn eine Kompatibilität der Wechselwirkung nicht über die Kompatibilitäts-Steuermodule vorhanden ist. Bezüglich der SCP 13 ist festzustellen, dass diese vorhanden sein kann oder auch nicht, in Abhängigkeit von der Art des Telefonsystems. Im Allgemeinen würde sie in einem intelligenten Netzwerk (IN) vorhanden sein, doch kann dies nicht der Fall sein, wenn das Vermittlungsamt SO 10 einfach eine Nebenstellenanlage oder eine ACD (automatische Anrufverteilung) sein würde.
2 der Zeichnungen zeigt mit weiteren Einzelheiten die Software-Systemkomponenten für die Kompatibilitätssteuerung. Die wesentlichen Teilsysteme der CC 12A (die sich auch in einer allgemeinen Rechenplattform wie z. B. 12C befinden könnten) sind eine Anforderungsabwicklung (RH) 20 und eine Ereignis-Abwicklung (EH) 21. Software-Agenten oder Proxies (A/P) 1–J, die (beispielsweise) den CC-Teilmodulen 12D–12G entsprechen, stellen Schnittstellenverbindungen der jeweiligen Ressourcengeräte (RD) 1–J mit dem Rest des Systems über den C-Bus 11 her. Eine Datenbank (DB) 16 ist außerdem über die Instanzierungseinrichtung 17 über den C-Bus 11 zugänglich.
3 erläutert die Laufzeitumgebung des Kompatibilitätssystems. In allgemeinen Ausdrücken unterstützt die Laufzeitumgebung die Ausführung der Software für Sitzungen. Dies schließt den Zugang an verschiedene Unterstützungsfunktionen (Lokalisierungseinrichtungen, Adressenauflösungseinrichtungen, usw.) ein, die von den Sitzungen verwendet werden, jedoch keinen Teil der speziellen Instanzen bilden, die für die Sitzung geschaffen werden. Beispielsweise würde eine Laufzeitumgebung ein Betriebssystem und einen ORB (Objektanforderungsvermittler), verschiedene Datenbanken und irgendwelche Softwarefunktionen einschließen, die von den Sitzungen während einer Ausführung verwendet werden. Software außerhalb der Laufzeitumgebung ist in vielen Fällen zum Zweck der Änderung von Informationen innerhalb der Datenbanken oder Unterstützungsfunktionen vorhanden. Somit besteht das Kompatibilitätssystem aus einer Laufzeitumgebung und einer Umgebung, die die Laufzeitumgebung unterstützt. Die Laufzeitumgebung umfasst Steuerungen, Agenten und Proxies. Eine Steuerung ist für jede aktive Benutzer-Dienstesitzung vorhanden. Die Steuerung wickelt Ereignisse und Anforderungen während der Ausführung einer Dienstesitzung ab. Agenten stellen die Funktionalität in dem System dar und wirken mit der Steuerung über Ereignisse oder Anforderungen zusammen. Proxies sind ein spezieller Typ von Agent, die überkommene Dienste behandeln, die nicht in der Lage sind, Kompatibilitätsereignisse zu verstehen.
Agenten stellen irgendeine Art von Funktion oder Dienst innerhalb des Kompatibilitätssystems dar. Sie wirken in zwei Hauptrollen. Wenn sie einen Dienst darstellen, fordern Agenten Ressourcen und Dienste der Kompatibilitätssteuerung in irgendeiner logischen Weise an, um Funktionskomponenten eines Dienstes oder möglicherweise einen gesamten Dienst zu schaffen. Der Agent macht eine Anforderung an die Steuerung, die, falls möglich, an den anfordernden Agenten die angeforderte Ressource oder Information zurückliefert. Weil die Steuerung an den Agenten zurückgeliefert wird, kann der Agent eine Dienstelogik realisieren. Wenn er eine Ressource darstellt, ist der Agent in der Lage, auf Ereignisse anzusprechen und ihre Funktionalität anzufordern. In dieser Betriebsart ist es möglich, dass ein Agent die Funktionalität anderer Agenten verwendet, um die erforderliche Aufgabe zu erfüllen.
Proxies sind Einheiten (spezielle Agenten) die irgendwelche der Übersetzungs- oder Umsetzungsfragen behandeln, die entstehen, wenn versucht wird, verschiedenartige Hardware- und Software-Systeme miteinander zu verbinden. Proxies übersetzen Informationen von einer Form auf eine andere, wie dies für miteinander kommunizierende Dienste erforderlich ist. Proxies sind von ihrer Art her sowohl syntaktisch als auch semantisch. In semantischer Form stellt ein Proxy sicher, dass eine Aussage Sinn für jede der beteiligten Parteien macht; diese Aussage ist aussagekräftig. Wenn er andererseits syntaktisch ist, so stellt ein Proxy sicher, dass die Parameter einer bestimmten Mitteilung die richtige Reihenfolge haben. Beide Attribute eines Proxies sind erforderlich, damit effektive Kommunikationen erfolgen können. Proxies wirken als eine Schnittstelle zwischen den zwei Systemen, die kommunizieren müssen. Der Proxy und Agenten-Schnittstellen sind der Kompatibilitätssteuerung (12A oder 12C) unterworfen. Das heißt, die Steuerung versteht die verfügbaren „Systemaufrufe", die sie ausführen darf. Dies bedeutet, dass das Kompatibilitätssystem weiterhin weiß, in welcher Reihenfolge ihre Parameter anzuordnen sind.
Auf der grundlegendsten Ebene ist die Kompatibilitätssteuerung ein Ereignis-Router und ein Anforderungs-Prozessor. Es ist die Aufgabe der Kompatibilitätssteuerung, mehrfache Agenten zu verwalten. Die Steuerung wird von jedem der Dienste, die sie aufrufen kann, mit Regeln versorgt, und diese Regeln bestimmen das Verhalten der Steuerung. Ein Systementwickler, der einen Dienst schafft, stellt ein Diensteverhalten bereit. Im Wesentlichen registriert ein Agent ein Interesse an bestimmten Ereignissen bei der Steuerung. Wenn ein Ereignis eintritt, leitet die Steuerung die Ereignis-Information an irgendeinen der Agenten weiter, die vorher ein Interesse registriert haben. Die Steuerung muss nicht wissen, wie die Dienste arbeiten, sondern sie muss lediglich wissen, wo sie den angeforderten Dienst findet (und dies kann über eine „Ressourcenabwicklung" erfolgen), und wie sie unterscheiden kann, welche Mitteilungen für einen vorgegebenen Dienst von Interesse sind. Eine Steuerung wird von jedem „Benutzer" in einer Anrufinstanz aufgerufen, so dass, wenn sich lediglich ein Benutzer in einer Anrufinstanz befindet (wie z. B. für die Rückgewinnung einer Sprachpost), lediglich eine Steuerung vorhanden ist. In dem Fall, in dem mehrfache Benutzer in einer Anrufinstanz sind, wie z. B. in einer Konferenzverbindung, bei der Benutzer andere aktive Dienste haben können, wird für diese Benutzer jeweils eine eigene Steuerung gebildet.
Die Steuerung, beispielsweise 12A, wird durch die Instanzierungseinrichtung 23 zu Beginn einer Benutzer/Anrufinstanz-Sitzung durch die Unterstützungsumgebung instantiert. Zu dieser Zeit wird in die Steuerung dessen Profil von der DB 22 für den Verlauf der Sitzung geladen. Dieses Profil wird in Form von Regeln geliefert, die die erforderliche Informationen darstellen, damit die Steuerung in der Lage ist, Ereignisse und Anforderungen abzuwickeln, die ihr geliefert werden.
Die Kompatibilitätssteuerung umfasst Teilmodule, die spezielle Aufgaben in der Rolle der Steuerung ausführen. Die zwei primären Teilkomponenten der Steuerung 12A (oder 12C) sind: die Ereignis-Abwicklungseinrichtung (EH) 20, die die erforderliche Verarbeitung bereitstellt, um Ereignisse abzuwickeln, und die Anforderungs-Abwicklungseinrichtung (RH) 21, die Anforderungen abwickelt, die an die Steuerung gerichtet werden. Eine der Hauptfunktionen der Steuerung ist die Abwicklung von Wechselwirkungen zwischen Merkmalen. Sie tut dies durch die Art und Weise, wie sie die Ereignis-Abwicklungseinrichtung (mit gelieferten Regeln) verwendet, um den Informationsfluss zu verwalten. Sie ermöglicht weiterhin die erneute Verwendung von Funktionen innerhalb des Netzwerkes mit Hilfe der Anforderungs-Abwicklungseinrichtung.
Innerhalb der CC 12A verwendet die EH 21 Regeln, die an die CC 12A geliefert werden, um zu entscheiden, welche Agenten oder Proxies (A/P1–A/PJ) über die Ereignisse informiert werden sollten. Die Regeln können statisch (das heißt die Regeln sind unveränderbar, sobald die Steuerung geschaffen wurde) oder dynamisch sein (das heißt dass es möglich ist, die Regeln zu ändern oder sie zu entfernen). Die dynamischen Regeln können hinzugefügt, geändert oder entfernt werden, nachdem eine Steuerung geschaffen wurde. Diese neuen Regeln oder Änderungen hiervon können von Diensten angefordert werden, die durch entweder ihre Agenten oder Proxies dargestellt sind. Bei Empfang eines neuen Ereignisses verwendet die EH 21 die Regeln und Daten, die mit dem Ereignis bereitgestellt werden, um zu bestimmen, welchem Agenten oder Proxy das Ereignis zur Verfügung gestellt werden sollte. Dies ergibt einen sehr flexiblen und dennoch robusten Mechanismus zur Bereitstellung eines Flusses von Steuerungen und Informationen durch das System. Dies wird zur Realisierung von Merkmal-Wechselwirkungs-Verwaltungsmechanismen verwendet, um es zu ermöglichen, dass mehrfache Dienste (die durch Agenten oder Proxies dargestellt sind) effektiv zusammenwirken, ohne dass eine Notwendigkeit besteht, vorhandene Dienste zu ändern, wenn neue Dienste hinzugefügt werden.
Die RH 20 wickelt Anforderungen ab, die an die Steuerung gemacht werden. Die RH 20 verwendet die mit der Anforderung gelieferte Information, um entweder einen Proxy oder einen Agenten zu finden, der in der Lage ist, die Anforderung zu erfüllen oder um dynamische Regeln innerhalb der Steuerung zu modifizieren. Wenn ein Proxy oder Agent gefunden wird, kann die RH 20 dann ein Ereignis erzeugen, um diesen Agenten oder Proxy aufzurufen. Dieses Ereignis wird an die EH 21 weitergeleitet, um sicherzustellen, dass irgendwelche Merkmals-Wechselwirkungs-Einzelheiten von der EH 21 behandelt werden können, bevor der spezielle Agent oder Proxy seine Funktion ausführt. In dem Fall, in dem die Anforderung dynamische Regeln innerhalb der Steuerung ändern soll, versucht die RH 20, dies zu tun. Unter der Annahme, dass geeignete Berechtigungen vorliegen, können die Regeln innerhalb der Steuerung geändert werden, um den Fluss der Steuerung oder Information zu ändern. Dieser Mechanismus ermöglicht es, dass Agenten oder Proxies beantragen, dass das Verhalten der Steuerung geändert wird, um das Verhalten des Restes der Anrufinstanz zu beeinflussen.
Ein wichtiger Vorteil des Vorhandenseins der RH 20 besteht darin, dass die Agenten oder Proxies (die bestimmte Funktionalitäten anfordern) nicht von Haus aus eine Kenntnis von Folgendem benötigen:

– welche Funktionalität verfügbar ist;
– wo sich die Funktionalität befindet; oder
– wie die Funktion realisiert ist.

Die RH 20 ist in der Lage, Anforderungen abzuwickeln, um eine Ressourcenfunktionalität sowie Anforderungen für den Aufruf vorhandener Dienste zu finden. Dies ermöglicht die Fähigkeit, eine vorhandene Funktionalität über das Netzwerk hinweg für neue Dienste erneut zu verwenden und es zu ermöglichen, dass Dienste andere Dienste aufrufen, so dass in sehr einfacher Weise integrierte Diensteangebote an Endbenutzer bereitgestellt werden können.
Somit ist die CC 12A in der Lage, grundlegende Mechanismen bereitzustellen, die das Zusammenwirken mehrfacher Dienste ermöglichen. Diese Mechanismen ermöglichen die Kombination von Diensten über mehrfache Netzwerkelemente hinweg in einer Weise, die für die Dienste selbst transparent ist. Die Grundlage für diese Mechanismen ist, dass sie ereignisgesteuert sind (daher die Verwendung einer EH). Das Verhalten irgendwelcher Wechselwirkungen wird mit Hilfe von Regeln gesteuert, die an die CC 12A von zwei Quellen geliefert werden. Die erste sind die Dienste, während die zweite ein Diensteintegrator oder Vermittler oder Broker ist, der für die Schaffung einer Benutzer-Dienstegruppe verantwortlich ist.
Einige Merkmal-Zusammenwirkungsregeln sind generisch und werden verwendet, wenn keine andere Regel vorhanden ist, um übersteuert zu werden. Diese Regeln schließen die Weiterleitung von Ereignissen an den zuletzt aktivierten Dienst und nachfolgende Dienste ein, bis das Ereignis von einem der Dienste „verbraucht" ist.
Unter Bezugnahme auf 3 wird eine allgemeine Beschreibung des Kompatibilitätssystems in Ausdrücken seiner agentenbasierten Architektur gegeben. Die Architektur besteht aus einem Satz von Agenten, die zusammenwirken, um Telefoniedienste für Endbenutzer bereitzustellen. Jeder Agent hat bestimmte Rollen in dem Netzwerk und verhält sich entsprechend. Mit jedem Agenten ist eine Daten- und Programmlogik verbunden, die es dem Agenten ermöglicht, diese Rollen zu spielen.
Drei Arten von Agenten sind in der Architektur vorhanden: Benutzer-Agenten, Ressourcen-Agenten und Dienste-Agenten. Die grundlegenden Charakteristiken jeder Art von Agent, zusammen mit ihren Charakteristiken die die FI zu einem Minimum machen und steuern, sind nachfolgend beschrieben.
Die explizite Zuordnung von Angelegenheiten zu bestimmten Agenten stellt sicher, dass eine Trennung erzielt wird. Die Trennung von Benutzern und Endgeräten wird durch die Schaffung von deutlich verschiedenen Benutzer- und Endgeräte-Ressourcen-Agenten erzielt; eine Trennung von Anrufen und Verbindungen wird durch die Verwaltung von Anrufen durch Benutzer-Agenten (das heißt durch Sitzungen) und von Verbindungen durch Verbindungs-Ressourcen-Agenten erzielt, die die Fähigkeiten von verteilten Netzwerk-Ressourcen darstellen; die Trennung der Benutzer-Sitzungssteuerung und Dienste ist ebenfalls in den ausgewählten Agenten explizit; und die Identifikation von Ressourcen-Agenten ermöglicht eine Trennung der Ressourcen-Verwaltung von der Dienste- und Sitzungssteuerung. Der „Leim", der die verschiedenen Agenten verbindet, wird durch das Verarbeitungsmodell bereitgestellt. Dieses Modell steuert, wie Mitteilungen zwischen Agenten weitergeleitet werden. Es schließt Mechanismen ein, um sicherzustellen, dass die Agenten auf Mitteilungen in bestimmten Folgen und Weisen einwirken, die mit den Absichten der Dienste und den Wünschen der Teilnehmer übereinstimmt.
Eine Hauptverantwortlichkeit des Benutzer-Agenten besteht darin, irgendwelche Anrufe zu verwalten, an denen der Benutzer beteiligt ist, das heißt die Kommunikationssitzungen des Benutzers zu verwalten. Kommunikationen zwischen Benutzern werden anfänglich durch die Benutzer-Agenten der beteiligten Parteien hergestellt und koordiniert. Um einen abgehenden Anruf auszubilden, würde ein Benutzer-Agent zunächst anderen Benutzer-Agenten den Wunsch für einen derartigen Anruf mitteilen. Sobald die Benutzer-Agenten vereinbart haben, ob ein Anruf möglich ist und Zielinformationen für den Anrufaufbau vereinbart haben, fordert dann der Ursprungsbenutzer-Agent dann an, dass der Verbindungs-Ressourcen-Agent die erforderlichen Fähigkeiten des Übertragungsmediums koordiniert. Diese Lösung führt zu einer Trennung von Anruf und Verbindung und zu einem ausgehandelten Verbindungsaufbau. Die Unabhängigkeit der Aushandlungsphase von dem Verbindungsaufbau vereinfacht die Auflösung von Wechselwirkungen, die sich aus Beschränkungs- (beispielsweise Aussortierungs-) Merkmalen ergeben. In der Agenten-Architektur ist der Benutzer-Agent eine nicht intelligente Mitteilungszentrale, die Mitteilungen von anderen Benutzer-Agenten und Ressourcen-Agenten empfängt und weiterleitet. Er spricht niemals direkt auf derartige Mitteilungen an. Antworten werden von Dienste-Agenten geschaffen. Der Benutzer-Agent führt das Verarbeitungsmodell aus, um zu bestimmen, wann verschiedene Dienste-Agenten Mitteilungen empfangen sollten und wann Mitteilungen zur Aussendung an andere Agenten bereit sind. Eine präzisere Beschreibung des Prozesses des Aufbaus eines abgehenden Anrufes würde angeben, dass der Benutzer-Agent die verschiedenen Ereignisse bestimmt, und dass Anfragen an einen Dienste-Agenten weitergeleitet werden sollten (möglicherweise an den POTS-Diensteagenten), der Mitteilungen erzeugt, die der Benutzer-Agent an weitere Benutzer-Agenten oder Ressourcen-Agenten weiterleiten sollte.
Die Vorlieben von Benutzern und deren Profile werden in der Wahl der Dienste, für die der Benutzer Teilnehmer ist, in Teilnehmer abhängigen Daten, auf die diese Dienste zugreifen, und die Benutzer-Agentenregeln bezüglich der Absendung von Mitteilungen und Ereignissen an Dienste-Agenten ausgedrückt. Der Benutzer-Agent ist in der Lage, die Rollen einers Abrechnungsteilnehmers, eines angerufenen Teilnehmers, eines Endgeräteinhabers usw. durch die Verwendung von Dienste-Agenten zu erfüllen, die so entwickelt sind, dass sie auf Ereignisse ansprechen, die diese Rollen betreffen. Der Benutzer-Agent ist sowohl ein Klient als auch ein Server für andere Benutzer-Agenten, weil er Anforderungen an andere Benutzer-Agenten sendet und auf Anforderungen und Benachrichtigungen von anderen Benutzer-Agenten antwortet. Er ist ausschließlich ein Klient bezüglich der Dienste-Agenten. Im Allgemeinen ist er außerdem ein Klient bezüglich der Ressourcen-Agenten, doch könnten Ressourcen-Agenten ihm auch asynchrone Benachrichtigungen über Ereignisse senden, wie dies von einem Benutzer-Agenten angefordert wird.
Der Dienste-Agent stellt die Verarbeitung dar, die zur Ausführung der Absichten eines Dienstes erforderlich ist. In Übereinstimmung mit dem Verarbeitungsmodell stellt jeder beanspruchte Dienste-Agent Regeln für den Benutzeragenten bereit, die anzeigen, wann der Dienste-Agent auf Ereignisse ansprechen sollte. Ein Dienste-Agent spricht auf Ereignisse dadurch an, dass er von dem Benutzer-Agenten an andere Benutzer-Agenten oder Ressourcen-Agenten zu sendende Mitteilungen schafft oder modifiziert. Als Teil der Antwort auf ein Ereignis kann der Dienste-Agent neue Versandregeln an den Benutzer-Agenten bereitstellen. Allgemein verwirklicht der Dienste-Agent die Verarbeitung für einen hiermit in Beziehung stehenden Satz von Merkmalen. Die tatsächliche Gruppierung von Merkmalen zu Diensten könnte beeinflussen, wie zugehörige Daten gruppiert und ein Zugriff auf diese ausgeführt wird und somit die Betriebsleistung, beeinflusst jedoch nicht die logische Betriebsweise der Agenten-Architektur. Es ist wichtig, dass ein Dienste-Agent nicht „zu viel" als Antwort auf eine einzige Anforderung von einem Benutzer-Agenten tut. Dies würde ähnlich einer Übernahme von zu vielen Rollen gleichzeitig sein, das heißt Aussortieren, Blockieren, Umlenken, ohne dass andere Dienste-Agenten an der Entscheidung teilnehmen könnten. Es gibt einen Kompromiss zwischen Betriebsleistung und der Ermöglichung einer zusammenwirkenden Wechselwirkung zwischen Merkmalen.
Dienste-Agenten kommunizieren nicht direkt mit anderen Dienste-Agenten. Sie würden im Allgemeinen noch nicht einmal etwas über das Vorhandensein anderer Dienste-Agenten wissen. Dienste-Agenten „schaffen" Ereignisse, die von dem Benutzer-Agenten festgestellt und dann an andere Dienste-Agenten versandt werden, die ein Interesse an diesen Ereignissen ausgedrückt haben. Auf diese Weise ergibt sich eine indirekte Kommunikation zwischen Dienste-Agenten.
Es ist wesentlich, dass Dienste-Agenten fest codierte Zuordnungen von Akteuren zu Rollen vermeiden, insbesondere eine feste Codierung bestimmter Signale. Signale sollten in Ausdrücken von logischen Namen ausgedrückt werden (beispielsweise „Teenager-Anrufer-Warnung", nicht „unterschiedliches Rufmuster 2"). Dienste-Agenten müssen so ausgelegt werden, dass sie auf Ereignisse ansprechen, die eine Dienste-Aktivierung oder eine neue Endgeräte-Zuordnung anzeigen. Als Antwort auf diese Ereignisse muss der Dienste-Agent den Benutzer bitten, den Endgeräte-Ressourcen-Agenten nach einem geeigneten Signal zu befragen. Dienste-Agenten müssen für das Ereignis vorbereitet sein, dass nicht genügend eindeutige Signale verfügbar sind. Sie müssen weiterhin Mechanismen zur Information des menschlichen Benutzers darüber liefern, welche Signale verwendet werden. Ein spezieller Dienste-Agent ist der POTS-Agent, der so ausgelegt ist, dass er grundlegende Anrufe verwaltet, die von einem für einen Benutzer registrierten Endgerät ausgehen oder an diesem enden. Die Einzelheiten eines POTS-Dienste-Agenten werden in einem späteren Abschnitt angegeben. Die Versandregeln für den POTS-Agenten ermöglichen es anderen Dienste-Agenten, den POTS-Agenten vorher zu belegen. Dadurch, dass POTS als Dienst wie irgendein anderer dargestellt ist, vermeiden wir die Architektur-Nachteile, die sich ergeben würden, wenn es erforderlich ist, „spezielle Dienste" und POTS unterschiedlich zu behandeln.
Ressourcen-Agenten haben die Rolle der Verwaltung einer Funktionalität, die in Ressourcen enthalten ist. Sie verfolgen die verfügbare Funktionalität, die verwendete Funktionalität, die für einen bestimmten Benutzer oder andere Agenten reservierte Funktionalität und ob andere Benutzer-Agenten informiert werden müssen, wenn ein Zugriff auf eine bestimmte Funktionalität erfolgt. Daten stellen eine Ressource dar, während Daten-basierte Ressourcen-Agenten Daten finden und verwalten, die helfen könnten, andere Agenten oder Ressourcen zu lokalisieren oder die Informationen darüber liefern könnten, welche Protokolle zu verwenden sind, um einen Agenten zu verwenden. Zwei spezielle Fälle von Ressourcen-Agenten sind der Endgeräte-Ressourcen-Agent, der Endgeräte darstellt, und der Verbindungs-Ressourcen-Agent, der Netzwerk-Ressourcen zur Manipulation von Verbindungen darstellt.
Ein Endgeräte-Ressourcen-Agent kennt die Fähigkeiten eines Endgerätes (beispielsweise Schriftzeichensätze, MPEG-Decodierung, Alarmierungsverfahren) und die Signale, die das Endgerät zur Kommunikation mit dem Netzwerk und mit dem Benutzer verwendet. Er könnte den Namen oder die Adresse eines bestimmten Benutzer-Agenten speichern, der informiert werden sollte, wenn bestimmte Ereignisse eintreten, beispielsweise Fragen einer gemeinsamen Nutzung lösen.
Ein Verbindungs-Ressourcen-Agent stellt den Netzwerk-Anbieter beim Aufbau von Trägerkanälen dar. (Ein Benutzer mit Zugang an mehrfache Netzwerk-Anbieter könnte direkt mit mehrfachen Verbindungs-Ressourcen-Agenten kommunizieren). Dieser Agent hat Algorithmen zur Herstellung von Verbindungen zwischen unterschiedlichen physikalischen Stellen. Die Stellen werden gegenüber dem Agenten in Anforderungen von Benutzer-Agenten identifiziert. Die Anforderung kann gewünschte Randbedingungen einschließen, wie z. B. annehmbare Kosten, minimale Bitrate, optimale Bitrate und maximale Verzögerung, sowie die zwei physikalischen Stellen, zwischen denen ein Trägerkanal herzustellen ist und irgendeine zusätzliche Funktionalität, die erforderlich ist, wie z. B. Konferenzbrücken. Der Verbindungs- Ressourcen-Agent kann einen großen Satz von verteilten Ressourcen mit Hilfe von Protokollen niedrigerer Ebene (außerhalb der Agenten-Architektur) steuern. Obwohl die Agenten-Architektur für eine derartige Signalisierung im Wesentlichen naheliegend ist, könnten Mitteilungen an beispielsweise die Netzwerk-Ports eines Endgerätes bis zu dem Ressourcen-Agenten für dieses Endgerät berichtet werden, wodurch andere Aktionen zwischen den Agenten ausgelöst werden.
Eine wichtige Funktion eines Ressourcen-Agenten ist die Verringerung der Signalzweideutigkeit. Zum Zeitpunkt der Teilnahme oder zum Zeitpunkt des Diensteaufbaus bittet ein Dienste-Agent den Benutzer-Agenten, eine Mitteilung an einen Ressourcen-Agenten zu senden, das bestimmte Charakteristiken erfüllt. Beispielsweise könnte ein Anruf-Wartet-Dienste-Agent einen Endgeräte-Ressourcen-Agenten um ein Alarmierungsmuster bitten, das anwendbar ist, während sich ein Anruf in seinem Ablauf befindet. Der Endgeräte-Ressourcen-Agent könnte mit einem eindeutigen Signal antworten oder er könnte anzeigen, dass keine eindeutigen Signale verfügbar sind. Im letzteren Fall ist er bereit, auf Anfragen zu antworten, wie passende Signale derzeit zugeordnet werden. Dienste-Agenten könnten sich dann damit befassen, wie oder ob ein Signal gemeinsam genutzt werden sollte und wie der Benutzer informiert werden sollte.
Ressourcen-Agenten verfolgen weiterhin, welche Benutzer-Agenten belegte Ressourcen benutzen, und sie können Regeln haben, wie anzusprechen ist oder welcher Benutzer-Agent befragt werden sollte, wenn ein anderer Benutzer-Agent versucht, eine belegte oder reservierte Ressource zu steuern.
Ressourcen-Agenten können Abrechnungsautorisierungen für die Verwendung ihrer Ressourcen erfordern. Dienste-Agenten, die die Benutzung dieser Ressourcen benötigen, können eine Autorisierung von anderen Parteien benötigen (die durch Benutzer-Agenten dargestellt sind), wenn die Rechnungsstellung nicht von dem versendenden Benutzer-Agenten zu zahlen ist.
Unter Bezugnahme auf die 2, 4, 5 und 6 wird der Verarbeitungsablauf des Kompatibilitätssystems nunmehr beschrieben.
Unter spezieller Bezugnahme auf 2 wird der Prozess der Bildung einer „Steuerung" in dem CC-Modul 12A (oder 12C) als Antwort auf ein Ursprungsereignis beschrieben:

(1) Der Agent/Proxy 1 ist der Urheber eines Ereignisses. Dieses wird über das Kompatibilitätssystem an eine Steuerungsverwaltung gesandt. Es wird an die Steuerungsverwaltung gesandt, weil diesem Ereignis keine Steuerung zugeordnet ist. Das Ereignis enthält Ereignisdaten, die beschreiben, was passiert ist, um das Ereignis hervorzurufen.
(2) Die Steuerungsverwaltung liefert die Ereignisdaten an eine verfügbare Steuerung (dies kann eine wartende Steuerung sein, oder eine Steuerung kann geschaffen werden). Dies bewirkt, dass die Steuerung ihre Initialisierung beginnt.
(3) Die Steuerung fordert ein Profil von einer Profilverwaltung an. Diese Anforderung schließt die Ereignisdaten ein, die die Profilverwaltung verwenden wird, um ein passendes Profil zu identifizieren.
(4) Das Profil wird an die Steuerung zurückgeliefert. Das Profil enthält Informationen zur Konfiguration von EH und RH. Das Profil enthält weiterhin die Ereignis-Abwicklungslogik (die die EH zur Klärung der Frage auswerten muss, wie Ereignisse abzuwickeln sind). Diese Logik kann durch verschiedene Maßnahmen bereitgestellt werden: a) die gesamte Logik ist in dem Profil enthalten, dies erfordert, dass Logik bezüglich der Frage, wann ein Dienst (über einen Agenten) aktiviert werden sollte, dem Profil bereitgestellt wird. b) Lediglich die Zwischendienste-Logik wird innerhalb des Profils bereitgestellt. In diesem Fall enthält das Profil jedoch eine Liste von Diensten. Die Steuerung würde dann die verbleibende Logik (die für den Dienst spezifisch ist) von dem den Dienst darstellenden Agenten zurückgewinnen.
(5) Die Steuerungsverwaltung leitet nunmehr das Ereignis an die EH der Steuerung weiter (in einer Hinsicht hat die Steuerungsverwaltung nunmehr eine passende Steuerung initialisiert und leitet das erste Ereignis ein, mit dem sich diese Steuerung befassen muss. Die EH verwendet die Ereignis-Abwicklungslogik, um festzustellen, was mit diesem Ereignis passieren sollte (der Prozess setzt sich nunmehr vom Schritt 1 des üblichen Ereignis-Abwicklungsprozesses fort).

Anforderungen
Eine Anforderung R1 kann von einem Gerät, beispielsweise RD 1 über dessen Agenten oder Proxy A/P1 eingeleitet werden, was über den C-Bus 11 an CC 12A weitervermittelt wird. Innerhalb der CC 12A bestimmt die RH 20, ob dies eine legale Anforderung ist, in Abhängigkeit von dem Ursprungs-Agenten/Proxy, und dem Benutzer, wie diese Instanz der CC darstellt. Die RH 20 findet den passenden Agenten oder Proxy und liefert irgendwelche erforderlichen Initialisierungsinformationen. Die RH kann Unterstützungsfunktionen innerhalb der Umgebung unterstützen, in der sie existiert, um einen geeigneten Agenten oder Proxy (beispielsweise A/P2) zu finden, der in der Lage ist, die Anforderung im Auftrag des anfordernden auszuführen. Die RH 20 erzeugt ein Ereignis, das an die EH 21 weitergeleitet wird, um die Aktivierung von A/P2 aufzurufen. Dies ermöglicht es den Merkmals-Zusammenwirkungs-Mechanismen der CC, dass sie vollständig aufgerufen wird, falls dies erforderlich ist. Das Aktivierungsereignis wird an A/P2 gesandt, um die spezielle ursprünglich angeforderte Funktion zu aktivieren.
Regeln
Regeln sind grundlegend Module einer Logik, die ausgewertet werden muss, gefolgt von einer Aktion, die von dem Ergebnis der Logik abhängt. Regeln werden für die Steuerung für zwei Quellen bereitgestellt. Die erste sind die Agenten/Proxies, die Regeln bereitstellen, um interessierende Ereignisse für den Dienst oder die Funktion bereitstellen, die sie darstellen. Die zweite Quelle ist ein „Dienste-Integrator", der zusätzliche Regeln bereitstellt, um zwischen den Regeln zu vermitteln, die von den Agenten/Proxies bereitgestellt werden. Beispielsweise ist ein Anwähldienst, wie z. B. ein „persönlicher Assistent" (man wählt eine bestimmte Nummer für einen Zugang an den Dienst) an irgendeinem Anrufankunfts-Ereignis interessiert. In diesem Fall würde der Agent oder Proxy, der den persönlichen Assistenten-Dienst darstellt, eine Regel wie folgt bereitstellen:

Ereignis: Anruf-Ankunft;

Logik: Wahr (bedeutet „irgendein"); und

Aktion: Sende Ereignis an Agenten/Proxy.
Ereignisse

(a) A/P1 erzeugt ein Ereignis, das an die CC weitergeleitet wird, in der die EH 21 das Ereignis abwickelt.
(b) Die EH 21 verwendet die Regeln, die ihr von den Diensten und Dienste-Vermittlern geliefert wurden, um festzustellen, welcher Agent oder Proxy das Ereignis empfangen sollte (eine Vorgaberegel des zuletzt aktivierten Dienstes wird verwendet, wenn dies von keiner Regel übersteuert wird).
(c) Wenn der Agent, dem das Ereignis gesandt wird, das Ereignis „verbraucht", so würde der Prozess an dieser Stelle enden. Der Agent oder Proxy könnte jedoch das Ereignis in irgendeiner Weise modifizieren oder nicht ändern. Wenn das Ereignis nicht geändert wird, so wird es zu der CC zurückgesandt.
(d) Der Prozess setzt sich von (a) fort, und die Regeln innerhalb der CC werden dazu verwendet, zu bestimmen, welchem Agenten oder Proxy das nächste Ereignis angeboten werden sollte.
(e) Der Agent oder Proxy könnte wiederum das gleiche Ereignis modifizieren oder erneut anwenden, und der Prozess würde sich fortsetzen.

Und so weiter.
Unter spezieller Bezugnahme auf 6 wird eine beispielhafte Realisierung des Kompatibilitätssystems unter Verwendung von zwei vorhandenen Diensten beschrieben, der Sprachpost und der Verfolgung einer Aktualisierung, in einer Meta-Dienste-Anwendung eines persönlichen Agenten.

(1) Wenn ein Anruf an der Anrufkontrollfunktion ankommt, erzeugt der Anruf-Steuerproxy (der die Anrufkontrollfunktion innerhalb des Kompatibilitätssystems darstellt) ein Ereignis, um die Ankunft eines Anrufes anzuzeigen.
(2) Die Steuerungs-Regeln zeigen an, dass irgendwelche Anruf-Ankünfte an den persönlichen Agenten weitergeleitet werden sollten.
(3) Um seine Funktion auszuführen, muss der persönliche Agent eine PIN von dem Benutzer einholen. Zu diesem Zweck sendet er eine Anforderung für eine PIN und sammelt diese von dem Benutzer.
(4) Die Steuerung ist in der Lage, den „Aufforderungs- und Sammel-Proxy" zu finden, der in der Lage ist, die Anforderung von dem persönlichen Agenten auszuführen.
(5) Der Aufforderungs- und Sammel-Proxy ruft eine Aufforderungs- und Sammelfunktion auf (dies würde über eine Schnittstelle hinweg erfolgen, weil der Proxy die Einzelheiten des tatsächlichen Protokolls verdeckt, das zur Bereitstellung der Funktion verwendet wird) und liefert das Ergebnis an die Steuerung zurück.
(6) Die Steuerung liefert das Ergebnis an die ursprüngliche anfordernde Stelle in dem persönlichen Agenten zurück.
(7) Um seinen Dienst fortzusetzen, erfordert es der persönliche Agent, dass ein Menü für den Benutzer abgespielt wird, um festzustellen, welcher Dienst aktiviert werden sollte (entweder Sprachpost oder FMU). Er fordert erneut die Steuerung auf, eine Aufforderungs- und Sammelfunktion zu finden.
(8) Die Steuerung findet wiederum den Aufforderungs- und Sammel-Proxy, der in der Lage ist, die Anforderung zu erfüllen.
(9) Der Aufforderungs- und Sammel-Proxy wirkt mit der Ressource zusammen, die die Fähigkeit zur Aufforderung und zum Sammeln bereitstellt, und liefert das Ergebnis an die Steuerung zurück.
(10) Die Steuerung liefert das Ergebnis wiederum an den persönlichen Agenten zurück.
(11) Wenn der Benutzer Sprachpost angefordert hat, fordert der persönliche Agent die Aktivierung eines Dienstes (mit einem Namen des Dienstes) an.
(12) die Steuerung findet den angeforderten Dienst (in dem Sprachpost-Proxy) und ruft den Proxy auf.
(13) Wenn der Dienst abgeschlossen ist, empfängt die Steuerung eine Benachrichtigung darüber, dass der Dienst von dem Sprachpost-Proxy freigegeben wurde.
(14) Das Dienste-Freigabeereignis wird an die zuletzt aktivierten Dienste weitergeleitet (dem persönlichen Agenten in diesem Fall), weil die Steuerung keine Regel hat, die dieses Vorgabeverhalten übersteuert.
(15) Um seinen Dienst fortzusetzen, erfordert es der persönliche Agent, dass ein Menü an den Benutzer abgespielt wird, um festzustellen, welcher Dienst aktiviert werden sollte (entweder Sprachpost oder FMU). Er fordert wiederum die Steuerung auf, eine Aufforderungs- und Sammelfunktion zu finden.
(16) Die Steuerung findet wiederum den Aufforderungs- und Sammel-Proxy, der in der Lage ist, die Anforderung zu erfüllen.
(17) Der Aufforderungs- und Sammel-Proxy wirkt mit der Ressource zusammen, die die Fähigkeit zur Aufforderung und zum Sammeln bereitstellt, und liefert das Ergebnis an die Steuerung.
(18) Die Steuerung liefert das Ergebnis wiederum an den persönlichen Agenten zurück, und in Abhängigkeit von der Antwort des Benutzers ist der persönliche Agent in der Lage, die Steuerung aufzufordern, einen Dienst (Sprachpost, wie vorher oder einen anderen Dienst, wie z. B. den Verfolgungs-Aktualisierungsdienst) zu aktivieren.

Claims

Verfahren zur Bereitstellung einer Kompatibilität zwischen verschiedenartigen Diensten, die von einer Anzahl von Diensteressourcengeräten in einem Kommunikationsnetzwerk oder in einem Informationsverarbeitungsnetzwerk bereitgestellt werden, gekennzeichnet durch: (a) Zuordnen eines Software-Agentenmoduls SAM zu jedem Diensteressourcengerät SRD zur Schnittstellenverbindung des SRD mit einem Software-Mitteilungsbus SMB (11); (b) Schaffen eines temporären Softwarekompatibilitäts-Steuer- CC-Moduls (12A) für jede Dienstesitzung, die durch Netzwerk-Teilnehmer eingeleitet wird; (c) Unterteilen des CC-Moduls in zumindest zwei Teilmodule, von denen eines RH (20) Anforderungen von Netzwerk-Teilnehmern für Dienste abwickelt, die mehrere SRD's beteiligen kann, und eines EH (21) zur Abwicklung von Ereignissen dient, die von dem RH erzeugt werden, indem bewirkt wird, dass ein Ereignis einen Zugriff auf ein ausgewähltes SRD über dessen SAM ausführt, wodurch eine Kompatibilität zwischen den SRD's erzielt wird, auf die der Zugriff erfolgt.
Verfahren nach Anspruch 1, bei dem der Schritt der Schaffung eines temporären Softwarekompatibilitäts-Steuermoduls (12A) den Schritt umfasst, bei dem bewirkt wird, dass das CC-Modul Anforderungen und Ereignisse in seinen zumindest zwei Teilmodulen (20, 21) durch Verarbeiten der Anforderungen und Ereignisse entsprechend vorgegebener Verarbeitungsregeln abwickelt.
Verfahren nach Anspruch 2, das weiterhin den Schritt des Speicherns der vorgegebenen Verarbeitungsregeln in einer Kompatibilitäts-Datenbank CDB (22) umfasst.
Verfahren nach Anspruch 3, das weiterhin den Schritt des Rückgewinnens einer Teilmenge der vorgegebenen Verarbeitungsregeln von der CDB (22) jedesmal dann umfasst, wenn ein CC-Modul (12A) im Schritt (b) geschaffen wird.
Verfahren nach Anspruch 1, bei dem der Schritt (b) jedesmal dann instanziert wird, wenn ein SRD über sein zugehöriges SAM eine anfängliche Ereignismitteilung auf dem SMB (11) hervorruft.
Verfahren nach Anspruch 4, wobei der Schritt (b) jedesmal dann instanziert wird, wenn ein SRD über sein zugehöriges SAM eine anfängliche Ereignismitteilung auf dem SMB (11) hervorruft.
Verfahren nach Anspruch 6, bei dem der Schritt (a) weiterhin die Zuordnung eines SAM zu jedem Benutzer des Netzwerkes umfasst.
Verfahren nach Anspruch 6, wobei der Schritt (a) weiterhin die Zuordnung eines SAM zu jedem Endgerät des Netzwerkes umfasst.