-
Die
Erfindung betrifft eine Datenbank für die Speicherung und Verwaltung
von Benutzerprofildaten, ein Softwareprogramm zum Implementieren
einer solchen Datenbank, ein Verfahren zum Verwalten einer Benutzerprofil-Datenbank
sowie ein Softwareprogramm zum Implementieren eines solchen Verfahrens.
-
Warum
investieren Menschen soviel Zeit und Geld in die Telekommunikation?
Hauptsächlich
aus zwei Gründen:
(i) um zeiteffizienter zu sein (d.h. Zeit zu sparen) und (ii) um
omnipräsent
zu sein (d.h. überall
und zu jeder Zeit erreichbar zu sein). Moderne Telekommunikationstechnologien,
wie Telefon, Fax, Mobiltelefone und das Internet, wenden sich diesen
Themen zu, indem sie ein weites Spektrum an Diensten anbieten. Miteinander
kombiniert helfen diese Dienste den Menschen, Zeit zu sparen und
sogar Kosten zu reduzieren. Diese verschiedenen netzwerkbasierten
Dienste versorgen die Benutzer typischerweise mit einer Funktionalität, die durch
eine spezifische QoS (Quality-of-Service) [Servicequalität] beschränkt ist.
-
UMS
(Unified Messaging Systems) überbrücken die
Lücken
zwischen verschiedenen Kommunikationsmitteln, indem sie analoge
und digitale Nachrichten, wie Fax, Voice-Mail, E-Mail, WWW und den
Kurznachrichtenservice (SMS) von Mobiltelefonen miteinander verschmelzen.
Man kann speziell unterscheiden zwischen (i) Nachrichten, wie Facsimile
oder Voice-Mail (die im Prinzip über
ein analoges Telekommunikationsnetz gesendet werden können) und
(ii) digital generierten, verarbeiteten und übertragenen Nachrichten. Neben einer
rein homogenen Übertragung,
sind auch heterogene analoge/digitale Nachrichtanwendungen denkbar (z.B.
Voice-Mail, Spracherkennung mit E-Mail-Übertragung, Fax zu Daten, Daten
zu Fax).
-
Heutige
UMS ermöglichen
es, Nachrichten unabhängig
von ihrem Typ zu erzeugen, zu verarbeiten, zu übertragen und zu speichern.
Diese Lösung
erlaubt es den Benutzern, unterschiedliche Netzwerkdienste in einer
vereinheitlichten und integrierten Weise zu nutzen. So kann z.B.
ein Telefonanruf, der als Sprachnachricht in einer Voice-Mailbox
aufgezeichnet wird, dem Empfänger
als Anhang an eine E-Mail zugesendet werden. Weitere Fortschritte
in der Spracherkennung könnten
sogar eine qualitativ hochwertige Umwandlung von Sprach-Anlagen
in Text ermöglichen.
Zusammenfassend läßt sich
sagen, daß UMS
mit der Heterogenität
unterschiedlicher netzwerkbasierter Dienste zu Rande kommt, indem
sie sich mit Themen der Formatumwandlung befaßt. So bietet UMS ein nahtloses
Gefüge, über das
Benutzer kommunizieren können,
indem sie irgendein Endgerät
benutzen, das gerade zur Hand ist.
-
Ein
typischer Nachteil von UMS ist der Mangel an Unterstützung für die zeitgerechte
Informationsauslieferung: Um Empfänger pünktlich zu erreichen verläßt UMS sich
auf die darunterliegenden Netzwerkdienste. Zur Lösung dieses Problems wurden
vereinheitlichte (Unified) Instant-Messaging-Systeme (UIM-Systeme) entwickelt, die
es ermöglichen,
Nachrichten nahezu in Echtzeit zwischen Benutzern zu übertragen.
Um dieses Ziel zu erreichen, müssen
UIM-Systeme die inhärenten
QoS-Eigenschaften des darunterliegenden Netzwerk-Services berücksichtigen.
Außerdem
stützen
UIM-Systeme sich für
die Interaktion mit Roaming-Service-Benutzern in starkem Maß auf mobile
Kommunikation. Wenn man alle diese neuen Themen berücksichtigt,
läßt sich
der ursprüngliche
Problem-Bereich in zwei neue Problem-Unterbereiche auflösen: (i)
Benutzermobilität
und (ii) Kontext-Bewußtsein.
-
Benutzermobilität beschreibt
die Fähigkeit
des Benutzers, sich zwischen unterschiedlichen Endgeräten (z.B.
vom Schreibtisch-PC im Büro
zum heimischen Laptop) zu bewegen. Dies unterscheidet sich von dem Fall
der Endgeräte-Mobilität, bei der
das Endgerät
bewegt wird, ohne die Verbindung zu dem Netzwerk zu verlieren. Die
Endgeräte
müssen
dann entweder horizontales Handover zwischen verschiedenen Zellen
eines gegebenen zellularen Netzwerks bewältigen (das sich auf Mobilitäts-Management-Funktionen
innerhalb des Netzwerks abstützt)
oder vertikales Handover zwischen verschiedenen Netzwerken (z.B.
einem hausinternen LAN und den öffentlichen
Outdoor-Netzwerken).
-
Was
das Kontext-Bewußstein
betrifft, so muß der
UIM-Service die Möglichkeiten
des Endgeräts
und die Beschränkungen
des benutzten Netzwerk-Service in Rechnung stellen. Bei Benutzung
des Short-Message-Service
(SMS) von GSM Phase 2+ kann der UIM-Service lediglich bis zu 160
Zeichen übertragen.
Wenn der SMS-Service benutzt wird, muß UIM deshalb die übertragene
Datenmenge reduzieren (indem entweder nur bestimmte Abschnitte der
ursprünglichen
Nachricht gesendet werden oder indem gerade die Verfügbarkeit der
Instant Message dem Benutzer signalisiert wird). Zukünftige Entwicklungen
von mobilen Datendiensten (z.B. die Einführung der Paketvermittlung,
wie des GSM-GPRS-Systems
oder des Systems der 3. Generation) werden den Benutzern die Nutzung
eines noch größeren Umfangs
an Diensten ermöglichen.
In einem solchen Fall wird das UIM-System den Netzwerk-Service mit
dem besten Qualitäts-/Preisverhältnis zu
wählen
haben.
-
UIM-Systeme,
die sich diesen beiden Aspekten zuwenden, bieten Benutzern de facto
einen neuen Typ von Service. Die Art des Service ist, soweit es
dieses Papier betrifft, nicht Bestandteil des Angebots von Betreibern
irgendwelcher verfügbarer
Internet- und/oder (mobiler) Telekommunikationsdienste.
-
Da
der UIM-Service eine Informations-Vermittlungs-Funktionalität mit sich
bringt, wurde das UIM-System
als Instant Message Broker (IMB) bezeichnet. Das IMB-System wurde
entwickelt, um einen flexiblen und erweiterbaren UIM-Service zur
Verfügung
zu stellen, der sich wirksam auf eine große Nutzergemeinschaft erweitern
läßt.
-
Um
zwischen Unified Instant Messaging (UIM) und Unified Instant Messages
zu unterscheiden, werden letztere zur Klarstellung als IMails bezeichnet.
-
Das
IMB-System kann entweder zu einer existierenden Infrastruktur hinzugefügt oder
als unabhängiger
Mehrwert-Service benutzt werden. Existierende Infrastrukturen könnten entweder
diejenigen sein, die von Internet-Service-Providern (ISP) angeboten
werden, oder diejenigen, die von Mobilfunkbetreibern zur Verfügung gestellt
werden. In einem solchen Fall muß das IMB-System wohldefinierte
Schnittstellen zu externen Systemen (wie der Benutzer-Datenbank
oder den Abrechnungssystemen) zur Verfügung stellen, die von den involvierten
Dritten verwaltet werden. Im Fall eines nichtvernetzten Mehrwert-Service,
der von einem IMB-Service-Provider angeboten wird, benutzt das IMB-System
die gleichen Schnittstellen zu seinen eigenen Infrastruktur-Komponenten.
-
Der
UIM-Service wird von einem IMB-Service-Provider angeboten, der ein
IMB-System verwaltet. Das IMB-System ist die physikalische Realisierung
des UIM-Service. Das IMB-System ist ein verteiltes Verarbeitungssystem,
das Netzwerktechnologien, wie PSTN, IP und mobile Telekommunikationsnetze
integriert, um (i) Benutzern den Zugang zu seiner Funktionalität zu ermöglichen,
(ii) seine Aufgaben zu erfüllen
und (iii) die verarbeitete Information an die gerufenen Teilnehmer
zu liefern.
-
Vom
geschäftlichen
Standpunkt aus bieten IMB-Systeme registrierten Benutzern (im folgenden
den Teilnehmern) Dienste an. Das Abonnement kann entweder privat
vorgenommen werden oder durch die Vermittlung einer Organisation,
die ihren Mitgliedern den Zugriff auf den IMB-Service ermöglichen.
-
2 zeigt
die Akteure, die in den UIM-Service involviert sind (Organisation,
Benutzergemeinschaft, IMB-Service-Provider) und die Ressourcen,
die zur Erfüllung
der Service-Ziele erforderlich sind (IMB-System, PSTN, IP und mobile
Telekommunikationsnetze). Die Benutzergemeinschaft ist die Menge
der IMB-Service-Teilnehmer, die weiter klassifiziert werden können, entweder
als private Benutzer oder als Mitglieder einer Organisation. Letztere
sind Teil von Organisationen, d.h. Akteure mit der Vollmacht, persönliche IMB-Service-Abrechnungen
zugunsten einer ausgewählten
Untermenge ihrer Mitglieder einzurichten. Dieses Delegationsschema
kann auch benutzt werden, um der Benutzerbasis eines ISP oder Netzbetreibers
IMB-Service-Zugang zu gewähren.
-
Der
primäre
Zweck des Instant Messaging ist die Übertragung einer Information
mit beliebig hoher Priorität
als Nachricht in (nahezu) Echtzeit. Instant Messages können von
verschiedenen Geräten
ausgehen und empfangen werden, wie Mobiltelefonen (GSM Kurznachrichtenservice),
PDAs (Personal Digital Assistants), E-Mail, WWW, Facsimile oder
Voice-Mail. Zusätzlich
enthalten Instant Messages eine Funktionalität zur Alarmgenerierung, Nachrichten-Geheimhaltung
und Bezahlung. Eine vereinheitlichte Instant Message kann enthalten:
- • Nachrichtendaten
(Text- und Multimediadaten),
- • Aktionen,
z.B. die Erzeugung einer Alarmmeldung,
- • Nachrichten-Geheimhaltung
(RSA),
- • Authentifizierung
der Nachrichtenquelle und des Inhalts (verschlüsseltes Hashing für die Nachrichten-Authentifizierung),
- • Geographische
Information (begrenzte Nachrichten-Dauerhaftigkeit).
-
Der
IMB-Service führt
die folgenden Schritte aus: (i) Er empfängt eine Nachricht von einem
Teilnehmer, (ii) er transformiert die Nachricht entsprechend den
Präferenzen
des Benutzers und (iii) er liefert die transformierte Information
an das bevorzugte Endgerät
des Empfängers.
Der Prozeß muß zeitliche
Zwänge
berücksichtigen,
um eine schnelle und echtzeitnahe Verarbeitung und Auslieferung
sicherzustellen.
-
Das
IMB-System (siehe 1) besteht aus vier Hauptkomponenten,
die alle z.B. in Java implementiert sind:
- 1.
Instant Message Gateway (MG) 4 – wandelt beliebige Nachrichten
(GSM/SMS, E-Mail, Fax, WWW) in/aus IMails um;
- 2. Message Broker [Nachrichten-Vermittler] (MB) 3 – verwaltet
die Umwandlung von Kundenadressen, die Behandlung von Benutzerprofilen,
das IMail-Routing, die Sicherheit und die Rechnungsstellung;
- 3. Verarbeitungs-Einheiten 2 – liefert die Möglichkeiten
zum Modifizieren des Nachrichteninhalts;
- 4. Ablagen für
Teilnehmerinformationen 1 – enthält persönliche Informations- und Rechnungsaufzeichnungen.
-
Das
IMB-System wurde nach den Standards für das Open Distributed Processing
[Offene Verteilte Verarbeitung] (ODP-Standards) entwickelt. 3 zeigt
eine logische Darstellung (die ODP-Computer-Perspektive) des IMB-Systems.
In diesem Bild bezeichnen Kreise logische Berechnungsobjekte, Kästen mit
abgewinkelten Ecken stehen für
Verbindungs-Abstraktionen und doppelt durchkreuzte Bögen repräsentieren
die Schnittstellen zwischen Objekten.
-
Benutzer
können
für den
Zugriff auf IMB-Dienste verschiedene Typen von Front-Ends benutzen.
Wie in dem Bild dargestellt, ist ein mögliches Front-End ein Internet-Browser,
der die Nachricht über
einen Web-Server zu einem Message-Gateway weiterleitet (Web-Service).
Andere Front-Ends können
direkt mit Message-Gateways kommunizieren.
-
Originating
Message Gateways [Nachrichten-Ursprungs-Gateways] (OMG) empfangen
Nachrichten in unterschiedlichen Formen (GSM/SMS, E-Mail, Telefax
usw.) und wandeln sie in IMails um. Destination MG [Nachrichten-Ziel-Gateways]
(DMG) bieten die inverse Funktionalität und senden Nachrichten direkt
an den Benutzer.
-
OMG
muß die
Authentizität
der IMail gewährleisten.
Das Front-End auf Web-Service-Basis kann den Benutzer auffordern,
eine Anmelde-(Login)-Prozedur durchzuführen. Andere Front-Ends können die
Benutzer-Authentifizierung durch digitale Signaturen oder durch
andere Authentifizierungsprozeduren ausführen.
-
In
dem IMB-System werden IMails in nahezu Echtzeit über sichere TCP/IP-Verbindungen übertragen. Der
MB führt
die Aufgaben die Nachrichten-Vermittlung aus. Die IMB-Profil-Datenbank
enthält
Informationen über
das gegenwärtig
benutzte Endgerät
und eine Liste von bevorzugten Endgeräten/Übertragungsmodi, die alternativ
benutzt werden können,
um den gegebenen Teilnehmer zu erreichen. In Abhängigkeit von dem ausgewählten Übertragungsverfahren
entscheidet der MB über
die Einbeziehung zusätzlicher
Verfahrensschritte, legt die erforderliche Adresseninformation fest
und wählt
ein Destination Message Gateway (DMG). Dem MB obliegen noch einige
Buchhaltungs-Aktivitäten,
wie das Aktualisieren der Abrechnungs-Datenbank. Ein DMG sendet
schließlich
die IMail an den Empfänger
nach Maßgabe
der aus dem MB empfangenen Adressierungsinformation. Im Fall eines
Netzwerks, das eine Quittungsnachricht liefern kann, sendet das
DMG diese Information an den MB zurück.
-
Das
IMB-System stellt Teilnehmern verschiedene Möglichkeiten für den Zugriff
auf den UIM-Service zur Verfügung.
Im folgenden sind alternative Front-Ends aufgelistet:
- 1. Web-Interface – ermöglicht einem
Benutzer die Verwendung eines Desktop um eine IMail direkt an andere
Teilnehmern zu senden;
- 2. Mobiltelefon – kann
zum Senden von SMS benutzt werden, die dann in IMails umgewandelt
werden;
- 3. Command-Line Tool- ermöglicht
es Skripts (z.B. einem Ressourcen-Überwachungs-Daemon-Prozeß) Ereignis-Zeichen
automatisch an das Verwaltungspersonal zu senden;
- 4. E-Mail-Tool – zum
Filtern, Umleiten (Redirecting) und/oder Weiterleiten von ankommenden
E-Mails als IMails;
- 5. Kalender-Tool- zum Senden von Meldungen über herannahende Verabredungen
oder Geburtstage an den Benutzer.
-
Um
einen skalierbaren und dynamisch erweiterbaren Service-Zugriff zur
Verfügung
zu stellen, benutzen die Tools verschiedene Typen von Gateways,
um auf den Service zuzugreifen. Spezialisierte IM B-Gateways konzentrieren
sich darauf, einem spezifischen Netzwerk-Service ein kosteneffektives
Interface zur Verfügung
zu stellen. Message Gateways können
dynamisch erzeugt und in das System eingefügt werden.
-
Optional
kann das IMB-System verteilte Verarbeitungseinheiten für die IMail-Zwischenverarbeitung benutzen.
Diese Einheiten werden angerufen, nachdem der IMB das Profil des
Empfängers
aufgerufen hat.
-
Der
IMail-Verarbeitungsschritt wandelt ein IMail-Objekt in ein anderes
IMail-Objekt mit dem verarbeiteten Inhalt um. Die Verarbeitungsschritte
können
ausführen:
- 1. Aufwertung des Nachrichteninhalts (Message
Content Enhancement)
IMB-Teilnehmer können das IMB-System zwingen,
in ankommende IMails zusätzlichen
Inhalt einzubeziehen. Solche zusätzlichen
Informationen (wie Wettervorhersage, Nachrichtenschlagzeilen usw.)
können IMB-Teilnehmern
nach verschiedenen Kriterien (z.B. kostenlos, auf Abonnentenbasis,
auf Anforderungsbasis) angeboten werden.
- 2. Nachrichten-Format-Umwandlung (Message Format Transformation)
In
diesem Verarbeitungsschritt wird das Codierformat der Instant Message
geändert.
Dies kann eine Transcodierung von einem Format in ein anderes (z.B.
aus einem Bildformat in ein anderes oder aus einem Dokumentenformat
in Postskript) beinhalten. Diese Art der Umwandlung kann angewendet
werden, wenn das Ziel-Endgerät
nur eine begrenzte Anzahl von Nachrichtenformaten verarbeiten kann. Üblicherweise
bleiben die dem Benutzer präsentierte
Information und die für
die Präsentation
benutzte Medien unverändert.
- 3. Reduzierung des Nachrichteninhalts (Message Content Reduction)
Dieser
Prozeß wird
angewendet, wenn das Ziel-Endgerät
nicht in der Lage ist, umfangreiche Nachrichten zu verarbeiten,
oder wenn die erkannte Netzwerk-QoS nicht ausreicht, um die IMail
richtig zu übertragen. Eine
Inhaltsreduktion ist insoweit verlustbehaftet, als ein Teil der
ursprünglichen
Information verloren gehen kann.
- 4. Nachrichten-Interpretation
Das IMB-Konzept kann erweitert
werden, um Benutzern das Einfügen
von Meta-Information in ihre IMails zu ermöglichen. Diese Meta-Information
enthält
Befehle, die von dem IMB-System verarbeitet werden. Als Beispiel
würde der
Befehl "translate
:Eng :Ger hunter (übersetze
das Wort hunter vom Englischen ins Deutsche)" das IMB-System zwingen, eine Verarbeitungseinheit
zur Sprachübersetzung
anzusteuern, um das englische Wort "hunter" in das deutsche Wort "Jäger" zu übersetzen.
- 5. Aktionen
Die in dem vorangehenden Punkt beschriebenen
Befehle können
sogar dazu benutzt werden, spezifische Vorrichtungen nach Prämissen des
Kunden oder an einem anderen Ort fernzusteuern (man könnte z.B. problemlos
ein Anlagensteuersystem erzeugen, indem man das IMB-System als Netzwerkmedien,
Klebesensoren, Steuerungen und Aktoren benutzt). Ein anderes Beispiel
wäre die
Integration von IMB-Systemen in Heim-Automatisierungssysteme [5].
-
Nachrichten-Auslieferung
-
IMails
werden über
DMGs an die Empfänger
geliefert. Wie bei zukommenden Message-Gateways ist jedes abgehende
Gateway auf eine spezifische Netzwerk-Technologie zugeschnitten.
Wenn die IMail an den Benutzer ausgeliefert wird, kann der Message-Gateway
zusätzliche
Schritte zur Benutzer-Authentifizierung ausführen, um
sicherzustellen, daß der
Ziel-Benutzer sicher identifiziert wird. In einigen Fällen muß der Message-Gateway
zusätzliche
Umwandlungsschritte vorsehen, um die IMail in das von dem Netzwerk-Service
geforderte Format zu ändern.
So können
z.B. nicht alle ASCII-Zeichen über
den GSM-SMS-Service übertragen werden.
Wie oben erwähnt
wurde, sehen einige Netzwerk-Technologien eine Rückkopplung vor, die anzeigt, daß eine Nachricht
an das Endgerät
des Endbenutzers ausgeliefert wurde (z.B. der GSM-SMS-Service).
Diese Rückkopplung
kann an den MB zurückgesendet
werden, wo sie eingetragen werden könnte.
-
Da
MGs die Schnittstellen des IMB-Systems mit der realen Welt bilden,
weisen sie eine modulare Architektur auf, die IMB-Service-Provider
in die Lage versetzt, ihre Ausrüstung
rasch zu aktualisieren, sobald neue Telekommunikations-Technologien
verfügbar
sind. Dieses Ziel wird erreicht, indem das MG als Rahmenwerk strukturiert
wird, dessen Kern eine gemeinsame Funktionalität zur Verfügung stellt, die technologiespezifische
Protokoll-Umwandlungsmodule (z.B. SMS-Treiber) als eine Art von
Plug-Ins anpaßt
(siehe 4).
-
Nachrichten-Authentifizierung
und -Geheimhaltung
-
Durch
Nachrichten-Authentifizierung können
die kommunizierenden Teilnehmern sicherstellen, daß die gesendeten
und empfangenen Nachrichten (sowie der wahre und der geltend gemachte
Ursprung) identisch sind. Das IMB-System benutzt das verschlüsselte Hashing
als Nachrichten-Authentifizierungscode (HMAC) mit der kryptographischen
MD-5-Hash-Funktion. HMAC ist in RFP 2104 beschrieben und wurde für die IP-Sicherheit,
wie z.B. Transportschicht-Sicherheit (TLS, das bald das SSL ersetzen
wird) und sichere elektronische Transaktion (SET) gewählt. Im
Gegensatz zu symmetrischen Block-Chiffren unterliegen mächtige kryptographische
Hash-Funktionen keinen Anwendungs- oder Exportrestriktionen. Die Nachrichtenverschlüsselung
ist noch nicht implementiert. Wir favorisieren Kryptographie mit öffentlichem
Schlüssel
auf der Basis des RSA-Algorithmus.
-
Beispiel
-
Um
das bisher Beschriebene zusammenzufassen, zeigt 5 als
Beispiel, wie sich das IMB-System als Reaktion auf eine Teilnehmeranforderung
(über ein
Web-Interface) zur Lieferung einer Nachricht als SMS an den gerufenen
Teilnehmer verhält.
-
Aus
WO 00/04462 A ist ein Netzwerk-Kommunikationssystem bekannt, das
mehrere Konfigurationen von Benutzerstationen, jeweils mit entsprechenden
Verarbeitungs- und Anzeigefähigkeiten,
aufweist. Den Benutzern werden Dienste verfügbar gemacht, indem der Inhalt
der Dienste für
die optimale Anpassung an die Präferenzen
des Benutzers und an verschiedene Client-Fähigkeiten, d.h. Geräte-Fähigkeiten,
arrangiert wird. Diese Information ist durch eine Kombination von
Benutzer-/Durchgangs-Räumen strukturiert,
wobei diese Räume
eine Metapher für
den funktionellen Kontext sind, in dem sich ein Benutzer oder Objekt
befinden kann.
-
In
dem Papier "Real
time stock price distribution utilising the GSM short messaging
service", 1997, IEEE,
USA ISBN: 0-7803-4298-4, Seiten 399–403, von Kilmartin L. et al.
wird ein Service für
den Empfang von Aktienpreisaktualisierungen in einem GSM-Mobiltelefon
vorgeschlagen. Ein System hält
eine Datenbank von Benutzerprofilen, einschließlich einer Information, wie
z.B. die interessierenden Aktien oder die Rufnummer des Mobiltelefons
des Teilnehmers. Das System fragt einen entfernten Aktienpreis-Server
ab, um für
den Teilnehmer mit Hilfe einer GSM-Kurznachricht einen aktuellen
Datensatz der laufenden Parameter jeder interessierenden Aktie zu
unterhalten, und nimmt kontinuierlich auf die Teilnehmerprofil-Datenbank
Bezug, um die reguläre Übertragung
der laufenden Aktieninformationen aufzulisten.
-
Das
Dokument WO 98/15091 A schlägt
ein Informationsübertragungssystem
mit einem Datenendgerät
vor, das in der Lage ist, mit Netzwerken und einer zentralen Einrichtung
Verbindung aufzunehmen, die über das
Netzwerk mit einer Vielzahl von Datenendgeräten Verbindung aufnehmen kann,
die sich in ihren Möglichkeiten
und/oder Merkmalen voneinander unterscheiden können. Außerdem ist für das Datenendgerät ein Modell-Code
vorgesehen, um jedesmal, wenn das Datenendgerät mit der zentralen Einrichtung
verbunden wird, einer zentralen Einrichtung seine Fähigkeiten
und/oder Merkmale anzuzeigen. Die zentrale Einrichtung sendet dann
an das Datenendgerät
Informationen in einer Weise, die an die Fähigkeiten und/oder Merkmale
des Datenendgeräts
angepaßt
sind.
-
Es
ist das Ziel der vorliegenden Erfindung, die oben erwähnte Instant-Messaging-Lösung für ein Umfeld
mit veränderbaren
Eigenschaften zu modifizieren. Solche veränderbaren Eigenschaften können dadurch entstehen,
daß die
Teilnehmer ihre persönlichen
Benutzerprofile tatsächlich
frei modifizieren können,
wenn sich die Situationen ändern
und/oder wenn sie sich an andere geographische Orte bewegen.
-
Das
oben erwähnte
Ziel wird durch die Merkmale der unabhängigen Ansprüche erreicht.
Die abhängigen
Ansprüche
stellen Weiterentwicklungen der zentralen Idee der Erfindung dar.
-
Gemäß vorliegender
Erfindung ist eine Datenbank für
die Speicherung und Verwaltung von Benutzerprofildaten vorgesehen.
Die Benutzerprofildaten repräsentieren
Sätze von
Benutzerinformationen und/oder von Benutzerpräferenzen, die die Endgeräte betreffen,
auf welche Benutzer innerhalb eines Informationsübertragungsnetzwerks Zugriff
haben. Die Datenbank umfaßt
für jeden
Benutzer zumindest ein kundenanpaßbares Benutzerprofil, das
von dem Benutzer erzeugt, editiert und/oder gelöscht werden kann. Jedes kundenanpaßbare Benutzerprofil
ist mit einem Umfeld des Benutzers verknüpft, das einen physikalischen
Ort und/oder einen logischen Kontext des Benutzers repräsentiert.
-
Die
Datenbank kann eine Mehrzahl von Benutzerprofilen für einen
Benutzer umfassen, wobei nur ein Benutzerprofil eines Benutzers
zur gleichen Zeit aktiv ist.
-
Jeder
Teilnehmer kann mehrere Benutzerprofile in einem sogenannten Benutzerraum
haben, der der eigene Datenraum des Benutzers ist, wie er in der
oben erwähnten
Benutzerprofil-Datenbank vorgesehen ist.
-
Benutzerprofile
können
völlig
unabhängig
voneinander oder korreliert sein. Im letzteren Fall können Benutzerprofile
als Knoten eines Graphen betrachtet werden, in dem die gerichteten
Bögen logische
Verknüpfungen
repräsentieren,
die Benutzerprofile in einer geordneten Weise verketten.
-
Jeder
gerichtete Pfad mit offener Schleife wird hiermit als Kontext definiert.
-
Spezifische
Benutzerprofile (im folgenden als Front-End-Satz-Profile oder einfach
als FES bezeichnet) sind so definiert, daß sie die Beschreibung eines
Satzes von Front-Ends enthalten. Wenn FESs nicht miteinander korreliert
sind, verkettet jeder Kontext einfach ein FES und ein oder mehrere
Benutzerprofile.
-
Der
Mechanismus zur Benutzerprofil-Verkettung kann dazu benutzt werden,
die von einem vorexistierenden Benutzerprofil (oder einem verketteten
Satz desselben) transportierte Information effizient mit zusätzlichen
neuen Exemplaren zu erweitern, indem ein Vererbungsschema verfolgt
wird.
-
Dieses
Vererbungsschema kann eventuell so erweitert werden, daß es Benutzerprofile
beinhaltet, die nicht zu dem gegebenen reinen Benutzerraum gehören, sondern
für alle
Teilnehmer (oder einen Satz von Teilnehmern) verfügbar sind.
Dieses Schema implementiert das Konzept der gemeinsam genutzten
Information.
-
Der
vorerwähnte
Graph ist topologisch äquivalent
zu einer schleifenlosen freien Baumstruktur, bei der die Wurzel
die Vorgabe-Konfiguration des IMB-Gesamtsystems repräsentiert.
-
Benutzerräume sind
schleifenlose freie Unterbäume
des vorerwähnten
allgemeinen Baums. Innerhalb des Umfangs des Benutzerraums fällt die
Wurzel des Unterbaums mit dem Benutzerprofil des Teilnehmers zusammen,
das die persönliche
Information des Teilnehmers enthält.
Aus diesem Benutzerprofil beziehen alle die anderen verketteten
Exemplare die Vorgabe. In diesem Fall repräsentiert jeder Baumzweig (ein
schleifenloser gewichteter Pfad, der einige Knoten des gegebenen
Unterbaums verbindet – nicht
zu verwechseln mit dem Unterbaum-Konzept) eine Kontext-Projektion
auf den gegebenen Benutzerraum.
-
Die
vorerwähnten
Konzepte werden hier mit Ausdrücken
beschrieben, die in dem MASE-Profil-Patent beschrieben sind. Das
heißt,
ein Benutzerprofil ist eine Karte, ein Kontext ist ein Satz von
Karten und die auf den Kontext angewendete Reihenfolge ist die sogenannte
Such-Reihenfolge.
-
Für die Benutzer
kann eine oder eine Mehrzahl von Präsenzmarken [Präsenz-Token]
vorgesehen sein, wobei jedes Präsenz-Token
die Verfügbarkeit
eines Benutzers für
den Empfang von Kopien ankommender Instant Messages in einem der
in dem gegebenen Benutzerprofil konfigurierten Endgeräte repräsentiert.
-
Der
Benutzerraum ist mit einem speziellen Benutzerprofil, dem sogenannten
Vorgabe-Benutzerprofil, verknüpft,
das die persönliche
Information des Teilnehmers und (als Option) eine servicespezifische
Information enthält.
Dieses Benutzerprofil kann nur von dem Benutzerprofil-Datenbank-Administrator
erzeugt und gelöscht
werden. Teilnehmer können
ihr eigenes Vorgabe-Benutzerprofil nur partiell modifizieren.
-
Das
hierarchische Schema der Benutzerprofile kann wie ein Baum sein,
wobei das Vorgabe-Benutzerprofil die Wurzel des Baums ist.
-
Jedem
Endgerät
eines Benutzerprofils kann eine Prioritätsinformation zugeordnet sein.
-
Die
Datenbank kann eine Information über
das Zugangsnetzwerk, die Netzwerkadresse und die Eigenschaften jedes
Endgeräts
enthalten.
-
Jedem
Endgerät
kann eine Mnemonik für
den Benutzer zugeordnet sein.
-
Jedem
Benutzer kann ein vereinheitlichter Name zugeordnet sein.
-
Der
Datenbank-Inhalt kann verteilt in Karten gespeichert sein.
-
Ein
Benutzer kann Informationen direkt erfragen und abrechnen.
-
Nach
einem weiteren Aspekt der Erfindung ist ein Softwareprogramm vorgesehen,
das, wenn es in den Speicher einer Rechenvorrichtung in eine Netzwerkumgebung
geladen ist, eine Datenbank implementiert, wie sie oben beschrieben
wurde.
-
Nach
einem weiteren Aspekt der Erfindung ist ein Verfahren zum Verwalten
einer Benutzerprofil-Datenbank
für die
Speicherung von Benutzerprofildaten vorgesehen, die die Sätze von
Benutzerendgeräten
in einem Informationsübertragungsnetzwerk
repräsentieren.
Die Datenbank umfaßt
für jeden
Benutzer einen Satz von Benutzerprofilen, die von dem Benutzer erzeugt,
editiert und/oder gelöscht
werden können
(mit Ausnahme des Vorgabe-Benutzerprofils, das der Benutzer nur
partiell aktualisieren kann), wobei jedes kundenanpaßbare Benutzerprofil
mit einem Umfeld des Benutzers verknüpft ist, das einen physikalischen
Ort und/oder einen logischen Kontext des Benutzers repräsentiert.
-
Die
Datenbank kann eine Mehrzahl von Benutzerprofilen für einen
Benutzer umfassen, wobei nur ein Benutzerprofil eines Benutzers
zur gleichen Zeit aktiv ist.
-
Nach
einem weiteren Aspekt der Erfindung ist ein Softwareprogramm vorgesehen,
das, wenn es in den Speicher eines Rechengeräts in einer Netzwerkumgebung
geladen ist, ein Verfahren implementiert, wie es oben angegeben
wurde.
-
Um
den zeitlichen Zwängen
von UIM-Systemen zu begegnen, muß das IMB-System festlegen,
ob der IMB-Benutzer online oder durch andere schnelle Übertragungsmittel
erreicht werden kann. Deshalb hält
das IMB-System die Information des IMB-Teilnehmers in einer IMB-Benutzerprofil-Datenbank
fest. Jedem IMB-Teilnehmer ist ein Benutzerraum zugeordnet, in dem
die Kundeninformation in einem Satz von Benutzerprofilen organisiert
ist. Dieser Satz wird im folgenden als Kontext bezeichnet. Der Benutzer
kann verschiedene Kontexte für
verschiedene Situationen definieren und zwischen ihnen dynamisch
umschalten. Zu einer gegebenen Zeit wird nur einer der in dem Benutzerraum
enthaltenen Kontexte von dem IMB-System tatsächlich benutzt. Ein solcher
Kontext wird im folgenden als Aktivkontext bezeichnet. Der Benutzerraum
hält einen
Aktivkontext-Indikator, der den gegenwärtig benutzten Kontext definiert.
Der Benutzer kann zu einer beliebigen Zeit auf einen anderen Kontext
umschalten (Kontext-Schalter). Die Benutzung von mnemotechnischen
Namen für jedes
Benutzerprofil und jeden Kontext verbessert die Verwendbarkeitsaspekte
dieses Mechanismus erheblich.
-
Der
aktuell benutzte Aktivkontext beschreibt voll und ganz, wie der
Teilnehmer erreicht werden kann. Dies beinhaltet eine Angabe darüber, ob
der Benutzer auf dem bevorzugten Endgerät gegenwärtig online ist, und zusätzlich einen
Satz von alternativen Endgeräten,
auf denen der gegebene IMB-Teilnehmer kontaktiert werden könnte, wenn
er auf dem bevorzugten Endgerät
nicht erreichbar ist. Diese alternativen Endgeräte können auch für den Empfang zusätzlicher
Kopien von Instant Messages benutzt werden. Neben dieser Information
enthält
das Benutzerprofil eine Information über jedes Endgerät. Die folgende
Kontext-Information wird während
der Nachrichten-Vermittlung benutzt:
- 1. Online – Angabe,
ob der Benutzer im gegenwärtigen
Zeitpunkt online ist.
- 2. Bevorzugtes Endgerät – das Endgerät, an dem
der Benutzer im gegenwärtigen
Zeitpunkt arbeitet.
- 3. Prioritätsliste – zeigt
die Reihenfolge an, der das IMB-System bei der Auswahl von Endgeräten folgen sollte:
Endgerät
mit hoher Priorität
sollten zuerst ausgewählt
werden. Wenn das ausgewählte
Endgerät
im Augenblick nicht verfügbar
ist, soll das IMB-System ein anderes Gerät mit der gleichen oder der
nächst niedrigeren
Priorität
auswählen
(Fallback-Mechanismus [Mechanismus zur Reduzierung der Übertragungsgeschwindigkeit]).
- 4. Präsenz-Token – die Zahl
von käuflich
erworbenen Präsenz-Token
und die Zahl der Token (außer
dem käuflich
erworbenen Exemplar), die der Teilnehmer zu einer gegebenen Zeit
tatsächlich
benutzen möchte.
-
Für jedes
Endgerät
kann der MB die folgenden Informationen abrufen:
- 1.
Netzwerktyp – spezifiziert, über welche
Telekommunikationsmedien und/oder Service-Provider das IMB-System
das ausgewählte
Endgerät
kontaktieren kann. Der Netzwerktyp enthält die QoS-Information, die benötigt wird, um die Rechtzeitigkeit
der Informationslieferung über
dieses Netzwerk zu bestimmen.
Netzwerkadresse – legt fest,
wie das IMB-System das adressierte Endgerät über das gegebene Netzwerk kontaktieren
kann.
- 2. Endgeräte-Eigenschaften – das IMB-System
benutzt dieses Attribut für
die Auswahl des passenden Mechanismus für die Umwandlung des Informationsformats,
der für
die Lieferung der Information in gebrauchsfertiger Form an das bevorzugte
Endgerät
des rufenden Teilnehmers erforderlich ist.
-
Für administrative
und Verwaltungszwecke ist jedes in einem Benutzerprofil aufgelistete
Endgerät
mit einer Mnemonik (Name) verknüpft,
die es den Menschen ermöglicht,
leicht auf ein beliebiges Endgerät
Bezug zu nehmen. Darüber
hinaus enthalten Benutzerräume
zusätzlich
Kundeninformationen des Teilnehmers, wie (für die Geheimhaltung der Nachricht
benutzte) öffentliche
Schlüssel,
Freundschaftslisten, Benutzungsstatistiken usw.
-
Der
Benutzer kann sein Profil durch unterschiedliche Mittel, wie ein
Web-basiertes Benutzer-Interface, SMS oder eine Kunden-Applikation,
manipulieren. Dies macht es möglich,
die im gegenwärtigen
Zeitpunkt benutzten Geräte
zu definieren und verschiedene Profile für verschiedene Situationen
zu definieren. Der laufende Aktivkontext-Indikator kann jederzeit
auf ein anderes Profil umgeschaltet werden.
-
Weitere
Aspekte, Merkmale und Vorteile der Erfindung ergeben sich für den einschlägigen Fachmann aus
der Lektüre
der folgenden detaillierten Beschreibung der Erfindung, die auf
die Figuren der anliegenden Zeichnungen Bezug nimmt.
-
1 zeigt
die Grundkomponenten der Architektur eines vereinheitlichten Instant-Messaging-Systems,
-
2 zeigt
eine vereinheitlichte Instant-Messaging-Oberfläche aus der geschäftlichen
Perspektive [Business Viewpoint],
-
3 zeigt
einen Instant-Message-Broker aus der Computer-Perspektive [Computational
Viewpoint],
-
4 zeigt
ein Instant-Message-Gateway mit Protokoll-Interface-Modulen,
-
5 zeigt
einen Informationsfluß durch
das Instant-Message-Broker-System,
-
6 zeigt
den Kontext und die funktionale Zerlegung einer Instant-Message-Broker-Abrechnungsverwaltung,
-
7 zeigt
Details der Instant-Message-Broker-Datenbanken aus einer Informations-Perspektive
[Information Viewpoint],
-
8 zeigt
eine globale Übersicht
der Funktionalität
der Instant-Message-Broker-Abrechnungsverwaltung aus der Computer-Perspektive,
-
9 zeigt
Details des Instant-Message-Broker-Systems aus der Computer-Perspektive,
-
10 zeigt eine verbesserte Profilstruktur,
-
11 zeigt
ein unvollständiges
Beispiel des Datenmodells (UML-Klassen-Diagramm),
-
12 zeigt
die Abbildung des Referenzdatenmodells auf das EMPP,
-
13 zeigt
ein Beispiel einer veränderbaren
Umgebung des Instant-Message-Brokers,
-
14 zeigt
Details des Kern-Message-Gateway-Systems aus einer Engineering-Perspektive,
-
15 zeigt
Details des Message-Broker-Kerns aus einer Engineering-Perspektive.
-
-
Die
Erfindung verallgemeinert das IMB-Konzept, indem sie sich mit einem
veränderbaren
Umfeld befaßt
statt mit dem statischen, an das sich die ursprüngliche IMB-Erfindung richtet.
In einem veränder baren
Umfeld kann sich der Kontext, in welchem der Benutzer mit dem IMB-System
interagiert, über
die Zeit ändern.
-
Die
Veränderbarkeit
des Umfelds kann aus zwei unabhängigen
Ursachen hervorgehen: (i) der Satz an Endgeräten, die von den Teilnehmern
des IMB-Service benutzt werden, um über diesen Service erreichbar
zu sein, kann sich mit der Zeit ändern
(Benutzer können
z.B. den Mobilfunk-Service-Provider wechseln); (ii) Teilnehmer können verreisen.
Im letzteren Fall können
Teilnehmer Orte erreichen, an denen einige ihrer Endgeräte (z.B.
ein Telefaxgerät)
nicht zur Hand sind und/oder zusätzliche
Geräte
mit einem besseren Qualitäts-Preis-Verhältnis (z.B.
Voice-Mail-Geräte)
angeboten werden können.
-
Diese
Faktoren sollten deshalb in der Entwurfsphase des IMB-Systems berücksichtigt
werden, indem Teilnehmern die Möglichkeit
gegeben wird, ihre ursprüngliche
Benutzerprofil-Information in einem beliebigen Zeitpunkt und auf
bequemste Weise zu ändern.
-
Darüber hinaus
können
Teilnehmer es nützlich
finden, eine gewisse Informationskonfiguration für den späteren Gebrauch zu speichern.
So sollte z.B. ein Geschäftsmann,
der sich häufig
in einem bestimmten Hotel aufhält,
wenn er einen bestimmten Ort besucht, in der Lage sein, seine IMB-Benutzerprofilinformation
in eine vorgespeicherte Information zu ändern, die die Hoteleinrichtungen
bereits berücksichtigt.
Teilnehmer sollten in der Lage sein, diese Auswahl vorzunehmen,
indem sie einfach eine für
den Menschen verständliche
Mnemonik zur Identifizierung des Kunden-IMB-Benutzerprofils benutzen.
-
Dieses
Merkmal würde
die Nutzung von IMB-Services durch den Teilnehmer erleichtern, indem
es das Wiederholen von allgemeinen Interaktionen mit dem IMB-System
zur Änderung
der Benutzerprofilinformation erübrigt.
-
Zusätzlich bietet
die vorliegende Erfindung einem Teilnehmer eine schnelle Möglichkeit,
Abrechnungsinformationen zu den IMB-Services abzufragen.
-
Die
Gründe
für die
Bereitstellung all dieser Merkmale sind:
- • Automatische Änderungen:
das IMB-System kann automatisch unterrichtet werden, wie die Teilnehmer
an ihrem bequemsten Endgerät
(oder Satz von Endgeräten)
erreichbar sind, sobald das veränderbare
Umfeld wechselt,
• dieses
Merkmal ist besonders interessant, wenn mobile Ad-Hoc-Netzwerk-Themen
angesprochen werden.
- • Leichte Änderungen:
IMB-Teilnehmer sollten in der Lage sein, mit dem IMB-System auf
eine benutzerfreundliche Weise (z.B. durch die Benutzung von Kunden-Mnemoniks)
zu interagieren, was Wartungs- und Verwaltungszwecke betrifft.
-
Sowohl
das intelligente Netzwerk als auch TINA-Standards sind auf ähnliche
Punkte fokussiert, sie sind jedoch beide auf die Telekommunikationswelt
beschränkt
(z.B. Dienste mit IN Call Forwarding [Weiterleitung ankommender
Rufe] und Call Redirection [Rufumleitung]). In der Tat nähert die
TINA-Lösung
den Fokus des Trägers
von reinen Telefondiensten an Multimediadiensten an, wobei diese
Standardisierungsbemühung seit
dem vorliegenden Papier auf dem Telekommunikationsmarkt noch keine
Stoßkraft
gewonnen hat. Darüber hinaus
befaßt
sich TINA im Vergleich zu dem IMB-Service mit komplexeren Szenarios und
hat keinen großen Einfluß auf existierende
World-Wide-Web-(WWW)-basierte
Dienste, mobile Multimedia-Anwendungen und Hand-Rechner, die drahtlos
mit dem WWW verbunden sind.
-
Einführung
-
Der
Kontext eines veränderbaren
IMB-Umfelds ist in 6 dargestellt, in der auch eine
funktionale Zerlegung auf hoher Ebene (durch frühes Einführen von Konzepten aus der
ODP-Engineering-Perspektive, die in späteren Abschnitten erarbeitet
werden) präsentiert
ist.
-
Eine
Folge von SW-(Software)-Einheiten ist über den Satz von HW-(Hardware)-Entitäten verteilt,
die beim Aufbau des IMB-Systems konkurrieren. Diese SW-Einheiten
erfüllen
ihre Aufgaben kooperativ, um es IMB-Teilnehmern zu ermöglichen,
ihre IMB-Profil- und Abrechnungs-Informationen zu verwalten.
-
Und
zwar bestehen diese SW-Einheiten aus IMB-Abrechnungs-, -Verwaltungs-,
-Client- und Servereinheiten. Die Servereinheit dient als Front-End
für Teilnehmer,
die auf ihre IMB-Benutzerprofil- und -Abrechnungsinformationen zugreifen
möchten.
Die letztere Einheit enthält
die Kernfunktionalität
der IMB-Abrechnungs-Verwaltung und zerfällt ihrerseits in mehrere HW-Einheiten,
die in den IMB-Message-Gateways (MG), in den IMB-Message-Brokers
(MB), in der IMB-Benutzerprofil-Datenbank und in der IMB-Abrechnungs-Datenbank
zusammengestellt sind.
-
Bemerkungen
zur IMB-Benutzerprofil-Datenbank
-
Die
IMB-Benutzerprofil-Datenbank-HW-Einheit ist in 6 einfach
als Benutzerprofil-Datenbank 1 dargestellt und außerhalb
der Ellipse angeordnet, die das IMB-System 7 identifiziert.
Diese Figur schlägt
in der Tat eine Trennung zwischen der Benutzerprofil-Datenbank 1 und
dem IMB-System 7 vor, insoweit als die von einer solchen
Datenbank verwaltete Information bequem von anderen Sy stemen benutzt
werden kann, die sich auf sie abstützen können, um ihre Dienste zur Verfügung zu
stellen.
-
Der
Hauptvorteil, den diese Lösung
der unabhängigen
Benutzerprofil-Datenbank bietet, ist tatsächlich die Verfügbarkeit,
um den laufenden Zustand eines Teilnehmers in einem gegebenen Zeitpunkt
hinsichtlich darauf abzufragen, auf welchem Endgerät (und welchen
alternativen Endgeräten)
der Teilnehmer derzeit erreichbar ist.
-
Diese
Art von Information kann mit einem dynamischen Telefonverzeichnis
(Weiße
Seiten) verglichen werden, einem Mechanismus, der z.B. von IN-Standardisierungskörperschaften
angesprochen wird, um den Nummernportabilitätsdienst (auf den reinen Telekombereich
beschränkt)
zu definieren.
-
Das
IMB-System 7 stützt
sich auf eine vereinheitlichte Namenkonvention, um IMB-Teilnehmer
eindeutig zu identifizieren. Durch Befolgen der vorangehend erwähnten Lösung kann
dieser Punkt deshalb aus dem reinen IMB-System-Kontext in die allgemeinere
Benutzerprofil-Datenbank 1 verlegt werden.
-
Wie
bei der IN-Nummernportabilität
können
Benutzer sich bei der Benutzerprofil-Datenbank 1 anmelden,
um einen vereinheitlichten Namen (UN) zu erhalten, und dort eine
Information speichern, die notwendig sein könnte, wenn, wie im Fall des
IMB-Service die IMB-Benutzerprofil-Information, spezielle Dienste
abonniert werden. In einem solchen Fall können vereinheitlichte Namen
auch dazu benutzt werden, in geeigneter Weise auf die IMB-Abrechnungs-Datenbank 8 zuzugreifen.
-
Die
Erfindung präsentiert
eine gemeinsame Datenbankstruktur, die effektiv für die Speicherung
von allgemeiner kontextbewußter
Information in der Benutzerprofil-Datenbank 1 benutzt werden
kann, während
Probleme der vereinheitlichten Namensgebung weiter unten detaillierter
beschrieben werden.
-
Das Verfahren
-
Dieser
Abschnitt führt
aus einer logischen Perspektive in das hiermit vorgeschlagene Verfahren
ein, in dem er beschreibt:
- – das logische Datenstrukturmodell
(beschrieben auf der Ebene der ODP-Informations-Perspektive);
- – die
logischen Operationen, die benutzt werden können, um solche Daten zu manipulieren
(beschrieben auf der Ebene der ODP-Computer-Perspektive).
-
6 zeigt
sowohl den Kontext eines veränderbaren
IMB-Umfelds als auch eine funktionale Zerlegung auf einer hohen
Ebene, wobei die vorerwähnten
Haupt-SW-Einheiten so dargestellt sind, als ob sie in den HW-Einheiten
des IMB-Systems und in den HW-Einheiten der Benutzerprofil-Datenbank
und des Datenbank-Verwaltungssystems angeordnet wären.
-
7 bietet
ein Detail aus der IMB-System-ODP-Informations-Perspektive in Bezug
auf die IMB-Datenbanken.
Die benutzte graphische Notation ist die UML. Die Figur faßt die Datenstruktur,
wie beschrieben, auf einem hohen Niveau zusammen.
-
8 bietet
eine ODP-Computer-Perspektive des gesamten IMB-Systems, wobei Kreise
logische Berechnungsobjekte angeben, Boxen mit runden Ecken für Verbindungsabstraktionen
stehen und doppelt gekreuzte Bögen
die Schnittstellen zwischen den verschiedenen Objekten repräsentieren.
Die Front-End-Funktionalität
kann sich sowohl an den IMB-Service-Zugang als auch an die IMB-Abrechnungs-Verwaltungs-Klienteneinheit
anpassen.
-
In
dieser Figur bezeichnen die ISP-Profil-DB- und ISP-DB-Verbindungsblasen
einen möglichen
Fall, in welchem das IMB-System die Identitäten von IMB-Teilnehmern verifizieren
kann, indem es sich einfach auf die DB eines Dritten abstützt (im
dargestellten Fall eines Internet-Service-Providers). Es kann auch
einige andere Möglichkeiten
geben, um den gleichen Zweck (d.h. den Zugriff auf die Teilnehmer-Authentifizierungsinformation)
zu erreichen, z.B. durch die Benutzung einer GSM-Operator-DB oder der eigenen
DB eines IMB-Service-Providers (die mit der IMB-Abrechnungs-DB zusammenfallen
kann).
-
In
Bezug auf das in 7 dargestellte UML-Klassen-Diagramm
und die in 8 und 9 dargestellten
Diagramme der Computer-Perspektive [Computational Viewpoint] bietet
das vorgeschlagene Verfahren die folgenden Merkmale:
- 1. Es versorgt IMB-Teilnehmer mit einem IMB-Service-Benutzerraum:
• ein IMB-Service-Benutzerraum
gruppiert das (ursprünglich
bei der Abonnierung erzeugte) Vorgabe-Benutzerprofil mit keinem
oder vielen erweiterten Benutzerprofilen;
• erweiterte Benutzerprofile
sind gespeicherte, vorkonfigurierte Benutzerprofile, die als Ersatz
des und/oder integriert mit dem Vorgabe-Benutzerprofil benutzt werden
können;
• das Vorgabe-Benutzerprofil
kann geändert,
abgefragt, jedoch nicht gelöscht
werden, während
die erweiterten Benutzerprofile erzeugt, geändert, abgefragt und gelöscht werden
können;
• das Vorgabe-Benutzerprofil
wird, wie erwähnt,
nur einmal bei der Abonnierung von dem IMB-Service-Provider erzeugt;
• ähnlich kann
nur der IMB-Service-Provider die Löschung des Vorgabe-Benutzerprofils
vornehmen. Wenn dies geschieht, wird tatsächlich der ganze Benutzerraum
des gegebenen Teilnehmers de facto gelöscht;
• die Erfindung ist deshalb
auf diese Kernpunkte gerichtet, indem sie verschiedene Autorisierungsebenen in
die IMB-Abrechnungs-Management-Funktionalität einführt;
• aus Gründen der Effizienz können erweiterte
Benutzerprofile (falls notwendig) stets Vorgabe-Benutzerprofil-Informationen und gemeinsam
genutzte Benutzerprofil-Informationen vorgeben (und so eine Informationswiederholung
vermeiden);
• ein
solches hierarchisches Schema kann außerdem rekursiv erweitert werden
und führt
so zu dem Schluß, daß der IMB-Service-Benutzerraum
topologisch einem schleifenlosen, freien, gerichteten Graphen äquivalent
ist. Innerhalb eines Benutzerraum-Rahmens nimmt ein solcher Graph
eine schleifenlose, freie Baumtopologie an, in der der Wurzelknoten
mit dem Vorgabe-Benutzerprofil
zusammenfällt.
- 2. Es bietet das Aktivkontext-Konzept: Zu einer gegebenen Zeit
wird nur einer der Benutzer-Kontexte von dem IMB-System effektiv
verwendet; alle anderen können
als in einem Bereitschaftszustand befindlich betrachtet werden:
• Teilnehmer
können
in der Laufzeit von einem Aktivkontext auf einen anderen Umschalten
(Kontext-Umschaltung). Diese Operation wird durchgeführt, indem
ein Aktivkontext-Indikator einfach umgeschaltet wird, der Teil des
Benutzerraums ist und eine Referenz zu dem gerade benutzten Kontext
als aktivem Kontext aufrechterhält;
• jede Änderung
des Aktivkontextes (einschließlich
der Kontext-Umschaltung) findet unter gegenseitigem Ausschluß bezüglich der
normalen MB-Routing-Aktivität
statt. Änderungen
an irgendeinem anderen bereitstehenden Profil können bezüglich der normalen MB-Routing-Aktivität gleichzeitig
durchgeführt
werden.
- 3. Es erlaubt IMB-Teilnehmern, die MB-Benutzerprofil- und -Abrechnungs-Information
direkt abzufragen:
• die
Abfrageergebnisse werden dem Teilnehmer unter Benutzung der einfachen
IMB-Funktionalität
zugesendet (die Abrechnungs-Information kann z.B. den Abfragenden
entsprechend sei nem/ihrem Benutzerprofil als SMS-Nachricht zugesendet
werden, wenn der Teilnehmer dies bevorzugt).
- 4. Es erlaubt IMB-Teilnehmern eine Aktualisierung der IMB-Benutzerprofil-Information.
• Updates
können
zu dem Benutzerprofil, das geändert
wird, oder zu einem frischen Benutzerprofil übertragen werden;
• neue (erweiterte)
Benutzerprofile können
erzeugt werden, indem die neue Information (die für das IMB-System
völlig
neu ist und/oder eine vorher vorhandene überschreiben kann) einfach
gespeichert wird: zu diesem Zweck beziehen sich neue erweiterte
Benutzerprofile logisch auf eine vorherige Information. Dieses Bezugsschema
wird von der vorerwähnten
logischen, gerichteten Graphen-Struktur des IMB-Benutzerraums geboten.
Dies soll unterstreichen, daß kein
irgendwie gearteter Informations-Klon-Mechanismus benutzt wird.
- 5. Es erlaubt Teilnehmern, ihre Verfügbarkeit an einem bestimmten
Endgerät
außerhalb
des Satzes der in dem Aktivkontext konfigurierten Endgeräten zu signalisieren.
• Die Verfügbarkeit
des Teilnehmers an einem oder mehreren Endgeräten ist an das Konzept des
Präsenz-Tokens
gebunden, das von dem IMB-System zur Auswahl des passenden Endgeräts benutzt
wird, an das Nachrichten geleitet werden sollen;
• in dem
(normalen) Fall eines viele-zu-einem-Tokens gibt es nur ein einziges
Präsenz-Token,
das der Benutzer logisch von einem Gerät zu einem anderen bewegen
kann;
• in
dem Fall eines viele-zu-n-Tokens kann der Teilnehmer frei und unabhängig seine/ihre
Verfügbarkeit
an mehreren Endgeräten
bis zu einer maximalen Zahl von n signalisieren. Der Service einer
Vielzahl größer als
Eins wird als optionales Merkmal ins Auge gefaßt, das Teilnehmer gegen eine
Zusatzgebühr
erwerben können.
- 6. Teilnehmer können
alle vorerwähnten
Verwaltungs-Operationen mit Hilfe eines Front-End-Geräts ausführen. Diese
Entität
stellt eine sichere Verbindung zu dem IMB-System zur Verfügung, das
verantwortlich ist für:
6.1
Verifizierung der Teilnehmer-Authentifizierung (entweder durch Vermittlung
eines Web-Servers oder direkt durch die Message-Gateway-Funktionalität);
6.2
Festlegung der Teilnehmer-Autorisierungsebene (z.B. durch die Message-Broker-Funktionalität auf der Basis
der in dem Benutzerprofil und/oder der Abrechnungs-Datenbank enthaltenen
Information);
6.3 Erfüllung
der Teilnehmer-Anforderungen und Rückübertragung der Ergebnisse zu
dem Teilnehmer (z.B. durch die Message-Broker-Funktionalität auf der
Basis der in dem Benutzerprofil und/oder der Abrechnungs-Datenbank
enthaltenen Information).
-
Wie
in den folgenden Abschnitten näher
erläutert
wird, ist diese Funktionalität
auf mehrere SW-Einheiten aufgeteilt.
-
Die Implementierung
des Verfahrens
-
Die
folgenden Abschnitte beschreiben die Abbildung aus dem logischen
Modell (ODP-Informations- und
Computer-Perspektive) auf dessen Implementierung (ODP-Kontruktions-
und -Technologie-Perspektiven).
-
Zunächst wird
die in dem vorherigen Absatz dargestellte logische Datenstruktur
auf eine erweiterte Version des Profil-Konzepts abgebildet.
-
Das
Folgende ist die Beschreibung der physikalischen Realisierung der
vorerwähnten
Modells aus der ODP-Computer-Perspektive in Form von SW- und HW-Einheiten,
bezogen auf die ursprüngliche
IMB-Systemarchitektur.
-
Die Konvention
der vereinheitlichten Namensgebung
-
Da
IMB-Service-Teilnehmer und, allgemeiner gesprochen, Benutzerprofil-Datenbank-Einträge irgendwie
eindeutig mit einem logischen Namen identifiziert werden sollen,
schlägt
die Erfindung folgendes vor:
- 1. Benutzerprofil-Datenbank-Einträge werden
durch einen vereinheitlichten Namen (UN), der ein Primärschlüssel nach
Art einer E-Mail-Adresse ist, eindeutig identifiziert;
• ein Geschäftsmann
kann beispielsweise einen UN (z.B. john-d-smith-123@imb.sony.de)
haben, der weltweit eindeutig ist: Der Geschäftsmann kann dann an irgendeinem
der in seinem IMB-Benutzerprofil
aufgelisteten Endgeräte
erreicht werden, indem einfach Instant Messages an den vorerwähnten UN
gesendet werden;
- 2. Benutzerprofil-Datenbank-Einträge werden durch eine persönliche Information
des Benutzers, wie erster, mittlerer und letzter Name, Geburtstag,
Geburtsort, Heimadresse usw. identifiziert. Diese Information wirkt als
Sekundärschlüssel, während der
UN als Primärschlüssel wirkt.
Auf diese Weise können
Kombinationen dieser Eigenschaften (im folgenden die Eigenschaften)
dazu benutzt werden, bei Anforderungen Dritter die UNs des Benutzers
abzufragen;
- 3. Die UNs sollen von der Autorität zugeteilt werden, die die
Benutzerprofil-Datenbank verwaltet. Im einfachsten Fall gehört die Benutzerprofil-Datenbank
tatsächlich
dem IMB-Service-Provider selbst;
- 4. Die IMB-Service-Teilnehmer können ihre UN und/oder individuelle/Gruppen-Aliasnamen
benutzen, um über
das IMB-System erreichbar zu sein. Die UNs und die Aliasnamen (beide
als Zeichenketten implementiert, wobei letztere jedoch nicht an
irgendein spezifisches Schema gebunden sind) verbergen de facto
die Adresse des laufenden Endgeräts,
an dem der Teilnehmer erreicht werden kann, so daß die für das Zurverfügungstellen
der IMB-Dienste benutzte Technologie abstrahiert wird;
- 5. als IMB-systemspezifisches Merkmal können Benutzerprofilen selbst
logische Namen (Aliasnamen) zugeteilt werden, um die Verwendbarkeit
des Gesamtsystems, wie es von den Teilnehmern wahrgenommen wird,
zu verbessern.
-
Die Struktur
der Benutzerprofil-Datenbank
-
Die
Vorgabe-Benutzerprofile und die erweiterten Benutzerprofile werden
als Sätze
von Eigenschaften (Karten) implementiert, wobei jeder Eigenschafts-Schlüssel eine
gegebene Eigenschaft eindeutig identifiziert und der Eigenschafts-Wert
dem gegebenen Eigenschafts-Inhalt entspricht.
-
Der
Schlüssel-Namenraum
hängt von
dem Kartennamen ab und kann eventuell eine Intraset-Schlüssel-Taxonomie
enthalten (z.B. würde <a-fully-qualified-card-name>.terminal.speed eine
bestimmte Karte – innerhalb
einer gegebenen Benutzerprofil-Datenbank – eindeutig identifizieren,
die unter anderem die Untereigenschaft der Geschwindigkeit der Endgeräte-Eigenschaft
beinhaltet).
-
Diese
Sätze können logisch
durch Namen identifiziert werden, die von der MASE-Profil-Namengebungskonvention
Gebrauch machen: Namen sind eine Verkettung von (in der Reihenfolge
des Auftretens) Benutzername, Endgerätenamen, Netzwerkname, Anwendungsname
und Situationsname.
-
Zusätzlich wird
hier ein sechster Name eingeführt,
der Ortsname, um eine Information darüber, wo der Benutzer derzeit
erreichbar ist, zu übertragen.
Der Ort repräsentiert
einen physikalischen Ort getreu (z.B. eine Stadt, ein Hotel oder
einen Flughafen), während
die Situation einen Kontext (z.B. "Heim" gegenüber "Arbeit") repräsentiert.
Das so modifizierte MASE-Profil-Paradigma wird im folgenden als
verbessertes MASE-Profil-Paradigma bezeichnet und als EMPP abgekürzt.
-
10 zeigt, wie Karten in EMPP tatsächlich organisiert
sind: Die Information ist nicht in Vorgabe- und erweiterten Benutzerprofil-Datenstrukturen
gespeichert, wie dies in dem vorerwähnten logischen Datenmodell ursprünglich vorgeschlagen
wurde. Statt dessen ist der Datenbankinhalt in Karten gespeichert,
die auf mehrere unterschiedliche Arten logisch gruppiert sind.
-
Zunächst können Karten
in Kartentypen organisiert sein. Ein Kartentyp repräsentiert
einen Satz von Vorgabewerten, auf die andere Karten sich abstützen können. Jeder
Kartentyp ist eindeutig auf einer der vorerwähnten Kartennamen-Komponenten
abgebildet. Karten innerhalb eines Kartentyps können logisch in Baumstrukturen
organisiert sein.
-
Eine
reine Endgeräte-Karte
(d.h. eine Karte, die zu dem Kartentyp Endgerät gehört) enthält z.B. den Schlüssel/die
Wertepaare, die ein gegebenes Endgerät beschreiben; andere Karten
können
solche Werte benutzen, um irgendeine spezifische Eigenschaft des
Endgeräts
vorzugeben.
-
Durch
logisches Kombinieren reiner Endgeräte-Karten (die alle zusammen
in einem T1-Satz gruppiert sein können, wobei das Suffix die
Zahl der Kartennamenkomponenten bezeichnet, die spezifiziert sind – im vorliegenden
Fall gerade eine) erhält
man einen neuen Kartensatz T2.
-
T2-Elemente
enthalten eine neue und/oder Überschreib-Information,
die auf den Elementen des T1-Satzes
aufbaut. Wie oben erläutert
wurde, sind T2-Elemente logische Kombinationen, und es liegt an
dem Datenbank-Management-System, in geeigneter Weise zu erzwingen,
daß der
T2-Inhalt sich auf den Inhalt derjenigen T1-Elemente voreinstellt,
die durch den gegebenen Kartennamen identifiziert sind.
-
Ein
T2-Element, das beispielsweise eine Kombination (Benutzer, Endgerät) enthält, spezifiziert
die Kunden-Information über
das zu benutzende Endgerät,
während
die benutzer- und endgerätespezifische
Information auf die T1-Elemente voreingestellt sein kann, die die
Benutzer- bzw. Endgeräte-Information
enthalten.
-
Dieser
Prozeß kann
rekursiv wiederholt werden, bis alle Kartennamenkomponenten spezifiziert
sind. Jeder Schritt in der Rekursion identifiziert einen Satz, der
von T0 bis T6 reicht, wobei T0 die Vorgaben des Gesamtsystems repräsentiert
(die Vorgabeinformation, die das noch zu konfigurierende System
beschreibt) und T6 die am meisten spezifische Benutzeranpassung
der Information repräsentiert.
-
Das
Konzept der Vorgabeinformation wird so in einer verteilten Weise
implementiert, indem man beachtet, daß:
- 1.
gewisse Informationen exklusiv von einem spezifischen Akteur (d.h.
dem Benutzer oder dem System-Administrator) verwaltet werden;
- 2. gewisse Informationen sich auf einen perspektivischen Aspekt
des Service (z.B. die benutzte Applikation oder den Kontext) beziehen;
- 3. diese Basisinformation weiter in Zwischen-Vorgaben (T2-,
T3-, T4-, T5-Sätze)
verfeinert werden kann;
- 4. jeder Akteur entscheiden kann, die Information über die
verschiedenen verfügbaren
Vorgaben (d.h. den T0-Satz und allen Zwischen-Sätze) an den Benutzer anzupassen.
-
Dieses
Datenmodell ist insoweit sehr flexibel, als es sich seinem Entwurf
entsprechend an sehr komplexe Szenarios richtet, wie dem Verteilen
von Information über
mehrfach vernetzte HW-Einheiten. Auf der anderen Seite ist das Modell
sehr komplex (siehe 11), da die Zahl
der Elemente in jedem der Tx-Sätze
sehr hoch sein kann (z.B. weist der T3-Satz bis zu 20 Kombinationen
von Kartenkomponentennamen auf). Es ist jedoch nicht die Benutzung
aller möglichen
Tx-Karten obligatorisch, und deshalb liegt es an dem Benutzer und/oder
dem System-Administrator so viele Tabellen zu erzeugen, wie sie
für nötig halten.
-
Implementieren
der IMB-Benutzerprofil-Datenbank mit dem verbesserten MASE-Profil-Paradigma
-
Dieser
Absatz erläutert
abschließend,
wie das in 7 dargestellte Datenmodell auf
das EMPP abzubilden ist. Das Abbilden ist in 12 dargestellt.
-
Der
IMB-Abrechnungs-Benutzerraum und der IMB-Benutzerraum können zusammenfallen
und auf das T1-Element abgebildet werden, wobei nur der Kartenkomponentenname
benutzerspezifiziert ist. In dieser Karte kann neben der persönlichen
Information des Benutzers der Aktivkontext-Indikator als ein Paar
von Schlüssel-/Wertepaarungen
implementiert sein: Indikator des derzeitigen Orts und Indikator
der laufenden Situation. Einer oder beide von ihnen können dazu
benutzt werden, das T2-Element auszuwählen, das den laufenden Aktivkontext
spezifiziert.
-
Der
laufende Aktivkontext hängt
stark von diesen beiden Konzepten ab (wie in 12 durch
eine mehrfache Vererbungsverknüpfung
zwischen dem Kontext (einer logischen Darstellung des physikalischen und/oder
logischen Umfelds) und den T2-Elementen Benutzer-Ort und Benutzer-Situation
dargestellt), und zwar aus den folgenden Gründen:
- • Der Kontext
kann nur von dem physikalischen Ort abhängen, insoweit als lokale Autoritäten und/oder
Organisationen IMB-Services an Benutzer anpassen können. So
kann z.B. ein Hotel seinen Kunden – soweit sie IMB-Service-Teilnehmer
sind – einen
Satz von Endgeräten
zur Verfügung
stellen, an denen die Kunden – im
Vergleich zu dem Vorgabe-Satz von Endgeräten – bequemer und schneller erreicht
werden können.
- • Der
Kontext kann ausschließlich
von der Situation abhängen,
in der sich ein Teilnehmer zufällig
befindet. So kann der Teilnehmer z.B. auf einem Meeting arbeiten,
sich im Urlaub befinden oder irgendeine Freizeitaktivität ausüben. In
jedem Fall kann die Situation das IMB-System veranlassen, seinen
Service an verschiedene Sätze
von Endgeräten
und mit unterschiedlichen Vorgehensweisen (wie unverzügliche oder spätere Auslieferung)
zu liefern;
- • der
Kontext kann von der Kombination aus Situation und Ort abhängen: Geschäftstreffen
in einem gewissen Hotel, Geschäftsreise
in einem Auto usw.. Ortsbasierte Kontexte können situationsbasierte Kontexte implizieren
und umgekehrt.
-
Sobald
der Kontext (durch Identifizieren der Benutzer-Orts- und/oder Benutzer-Situations-Karten)
ausgewählt
wurde, kann der IMB-Teilnehmer das laufende Endgerät auswählen, an
dem sie/er mit der höchsten Priorität erreicht
werden möchte.
Dies wird durch die Verwendung einer Schlüssel-/Wertepaarung, den Indikator
des laufenden Endgeräts,
erreicht, der sowohl in den Benutzer-Orts- als auch in den Benutzer-Situations-Karten
enthalten ist. Alternative verfügbare
Endgeräte
sind in solchen Karten ebenfalls aufgelistet: Diese Liste wird von
dem IMB-MB benutzt, um alternative Endgeräte auszuwählen, an die Instant-Messages
geschickt werden sollen. Wenn die Token-Vielfalt n größer als
Eins ist, kann der IMB die ersten n Elemente in einer solchen Liste
auswählen
und Kopien von ankommenden Instant Messages an alle entsprechenden
Endgeräte
senden.
-
Schließlich kann
unter Verwendung der T4, T5 und T6 eine Information aufgerufen werden,
die eine bessere Kundenanpassung besitzt.
-
Als
Schlüsselmerkmal
ermöglicht
das EMPP es Benutzern, über
die Vorgabe-Suchreihenfolge hinaus ihre bevorzugte Suchreihenfolge
zu implementieren.
-
Zusätzlich zu
dem obigen Mechanismus ermöglicht
das EMPP als optionales Merkmal die Anreicherung von Eigenschaften,
indem jedem von ihnen eine spezifische Auflösungsvorschrift (Attribut-Auflösungsvorschrift)
hinzugefügt
wird. Dieser Lösungsweg
kann dazu benutzt werden, den Suchprozeß über den Gesamtsatz von EMPP-Karten
zu verfeinern, indem spezifiziert wird, wie die Vorgabe-Information übergangen
werden kann. Grundsätzlich
werden die Schlüssel-/Wertepaare
mit einem neuen Parameter vergrößert, der
die anzuwendende Vorschrift angibt (und so zu einem logischen Schlüssel-/Gesetz-/Wert-Tripel
führt).
Solche Gesetze sind folgende:
- • Blockieren:
das erste Auftreten der gegebenen Eigenschaften, die bei einem Suchlauf
gefunden wird, ist als endgültig
zu betrachten, und der Suchprozeß kann beendet werden.
• In Abhängigkeit
von der Suchreihenfolge kann diese Vorschrift zu unterschiedlichen
Ergebnisse führen:
• Wenn – als typischer
Fall – die
Suchreihenfolge zuerst das allgemeinste Auftreten einer Eigenschaft
(z.B. von einem T0- bis zu einem T6-Element) prüft, hat dies Vorrang gegenüber jedem
anderen spezifischeren Auftreten der gegebenen Eigenschaft, die
danach mit einem Suchlauf ermittelt werden kann;
• wenn als
Ausnahmefall die Suchreihenfolge zunächst das am meisten spezifische
Auftreten einer Eigenschaft (z.B. von einem T6- zu einem T0-Element)
prüft,
liefert diese Vorschrift die gleichen Ergebnisse wie die Vorschrift
des Übergehens
(siehe unten);
- • Übergehen:
Das spezifischste Auftreten der gegebenen Eigenschaft ist als endgültig zu
betrachten, und der Suchprozeß kann
beendet werden;
- • Anhängen: Das
Vereinigen der Inhalte jedes Auftretens einer gegebenen Eigenschaft,
so wie sie während eines
Suchlaufs gefunden wird, ist als endgültig zu betrachten. Diese Vorschrift
ist nur für
einen bestimmten Typ von Eigenschaften (z.B. Zeichenketten) sinnvoll.
-
Die
Information über
die Auflösungsvorschrift
ist tatsächlich
mit dem Eigenschafts-Schlüssel
verknüpft und über die
gesamte Datenbank eindeutig. Durch Ändern der Vorschrift erzeugt
man im Grundsatz einen neuen Eigenschafts-Typ, selbst wenn der Schlüssel der
gleiche ist.
-
Das
Gesamt-EMPP kann z.B. als relationale Datenbank implementiert werden
(siehe Tabelle I).
-
13 veranschaulicht
die Benutzung des IMB-Service durch Hervorheben der veränderbaren
Eigenschaft des typischen IMB-Umfelds.
-
Die Einheiten
-
Die
IMB-Abrechnungs-Management-Funktionalität kann zerlegt werden in einen
Satz von kooperierenden SW-Einheiten, die über mehrere Prozesse verteilt
sein können.
Diese Prozesse können
letzlich über mehrere
HW-Einheiten verteilt sein (siehe 6). In diesem
Umfang kann es vorteilhaft sein, die MASE-Komponenten-Architektur
zu benutzen. Dieser Lösungsweg
basiert auf dem Konzept der ODP-Engineering-Perspektive.
-
Die
folgenden Abschnitte beschreiben jede dieser SW-Einheiten detaillierter.
-
Die IMB-Abrechnungs-Management-Client-Einheit
-
Teilnehmer
können
auf ihre IMB-Abrechnungs-Information (mit Nurlese-Erlaubnis) und
auf ihre IMB-Benutzerprofile (mit Lese-Schreib-Erlaubnis) zugreifen,
indem sie eine IMB-Abrechnungs-Management-Client-Einheit benutzen.
-
Das
Gegenstück
zu dieser Client-Einheit, die IMB-Abrechnungs-Management-Server-Einheit
wird – in verschiedene
SW-Einheiten zerlegt – in
den nächsten
Abschnitten untersucht.
-
Die
Client-Einheit kann entweder direkt in dem Endgerät lokalisiert
sein, das der Benutzer derzeit benutzt, oder in einem spezifischen
Endgerät
(z.B. in dem PC eines Dritten, falls der Teilnehmer nur zu unintelligenten
Endgeräten,
wie einem Telefaxgerät,
Zugang hat).
-
Die
Client-Einheit etabliert eine sichere und authentifizierte Verbindung
mit einem MG (entweder direkt oder z.B. durch die Vermittlung eines
Web-Servers), übermittelt
die Anforderungen des Teilnehmers an das MG und präsentiert
dem Teilnehmer schließlich
die Ergebnisse, sobald das MG eine Rückantwort auf die Anforderung
liefert.
-
Schließlich verwaltet
diese Client-Einheit eine Logout-Prozedur, entweder auf eine explizite
Anforderung des Benutzers hin oder implizit nach Ablauf eines Halte-Timers.
Der Halte-Timer wird jedesmal zurückgesetzt, wenn der Benutzer
Anforderungen an das MG sendet.
-
Die
Einheit stellt Teilnehmern ein UI zum Durchsuchen des IMB-Benutzerprofils
und der Abrechnungs-Information zur Verfügung. Dieses UI kann eine unabhängige SW-Einheit
sein (die der Benutzer bei der Abonnierung von dem IMB-Service-Provider
enthält
und auf seinem/ihrem PC/Laptop/PDA installiert), oder es kann durch
die Unterstützung
eines IMB-Web-Servers, durch Benutzen eines COTS-Web-Browsers darauf
zugegriffen werden. Alternative UI-Implementierungen können sein:
- • GUI
- • Web-Interface
(z.B. durch Benutzung der Java-Servlet-Technologie)
- • SMS
- • WAP
- • Telefon
- • Befehlszeile
(Skripts)
- • usw.
-
In
gewissen Fällen,
in denen ein Endgerät
keine bequeme und benutzbare GUI-Lösung bietet, bietet die Client-Einheit
einen eingeschränkten
Satz seiner Funktionalität.
Ein Teilnehmer kann z.B. ein GSM/SMS-Mobiltelefon für einen
eingeschränkten
Funktionalitätssatz
benutzen, wie das Signalisieren einer Online-Indikation, das Herunterladen
der Liste von IMB-Benutzerprofil-Namen (Alias- oder Kartennamen)
aus seinem/ihrem IMB-Benutzerraum, die Kontext-Umschaltung oder
einfach das Abfragen der IMB-Abrechnungs-Information.
-
Darüber hinaus
kann ein solcher eingeschränkter
Satz von Operationen auch durch Verwendung zahlreicher alternativer
Technologien (z.B. Spracherkennung) angefordert werden.
-
Deshalb
variiert diese Client-Einheit-Funktionalität in Abhängigkeit von den Eigenschaften
der von den Teilnehmern benutzten Endgeräte.
-
Die IMB-Abrechnungs-Management-Server-Einheit
-
Diese
Server-Einheit stellt die zu der Funktionalität der IMB-Abrechnungs-Management-Client-Einheit komplementäre Funktionalität zur Verfügung.
-
Diese
Server-Einheit, die das hiermit vorgeschlagene Verfahren de facto
implementiert, ist insofern eine logische Einheit, als sie weiter
zerlegt wird in einen Satz von SW-Einheiten, die über mehrere
IMB-Baublöcke
verteilt sind. Diese SW-Einheiten kooperieren, um die gewünschte Funktionalität der IMB-Abrechnungs-Management-Server-Einheit
zur Verfügung
zu stellen.
-
Message-Gateway-Abrechnungs-Management-Server-Einheit
-
14 zeigt
das Message-Gateway aus der ODP-Engineering-Perspektive. Der graphischen ODP-Notation und -Terminologie
folgend bezeichnen Kreise physikalische Basis-Engineering-Objekte
(z.B. die SW-Untereinheiten, aus denen das System zusammengesetzt
ist). Boxen mit abgerundeten Ecken repräsentieren Cluster (d.h. einen
Satz von nahe verwandten Basis-Engineering-Objekten, die in einem
einzigen Speicheradressenraum gruppiert sind. Die grau eingefärbten Rechtecke
repräsentieren
physikalische Kanäle, die
Inter-Cluster-Kommunikationen abstrahieren. Diese Kommunikationen
können
SW-Prozesse (durch von dem darunterliegenden OS zur Verfügung gestellte
IPC-Mechanismen) oder HW-Geräte
(durch Vernetzung) umfassen. Der Nucleus repräsentiert, in der ODP-Terminologie,
das darunterliegende OS. Doppelt gekreuzte Bögen repräsentieren die Schnittstellen
zwischen den verschiedenen Objekten.
-
Auf
dieser Ebene wird hierdurch keine physikalische Verteilung von Clustern
zwischen SW-Speicheradressenräumen
(auch als Prozesse oder, in ODP-Terminologie, als Kapseln bekannt)
und HW-Ein heiten (in ODP-Terminologie auch als Knoten bekannt) präsentiert,
da die IMB-Architektur völlig
modular ist.
-
Die
Figur repräsentiert
praktisch ein Ursprungs-MG (d.h. ein MG, das so konfiguriert ist,
daß es
nur ankommende Anforderungen verarbeitet, um IMs zu erzeugen). Das
Kern-MG hängt
jedoch nicht von der MG-Konfiguration ab.
-
Die
MG-Abrechnungs-Management-Funktionalität ist exakt in dem Kern-MG
lokalisiert. Die MG-Abrechnungs-Management-Funktionalität modelliert
die MG-IMB-Abrechnungs-Management-Server-Einheit.
-
Diese
Einheit residiert in dem IMB-MG (siehe 14) und
befaßt
sich mit (i) der Einrichtung einer sicheren Verbindung zu dem Teilnehmer,
(ii) der Authentifizierung der Teilnehmeridentität, (iii) dem Halte-Timer-Management
und (iv) der Nachrichtenweitergabe von dem Teilnehmer zu dem IMB-MB
und umgekehrt. Alternativ kann ein Web-Server diese ersten drei
Funktionen bieten.
-
Das
MG kommuniziert über
sichere IP-Verbindungen mit der MB-Abrechnungs-Management-Einheit.
-
Message-Broker-Abrechnungs-Management-Einheit
-
15 zeigt
eine ODP-Engineering-Perspektive des Message Brokers und der IMB-Datenbanken. Die
MB-Koordinations-Funktion enthält
sowohl das Benutzerprofil als auch die Client-Einheiten für den Zugriff auf
die IMB-Abrechnungs-Datenbank; die Benutzerprofil-Datenbank- und
die IMB-Abrechnungs-Datenbank-Kanäle modellieren die Kanäle zwischen
dem Benutzerprofil-Datenbank-Zugriff-Client und den Server-Einheiten bzw.
zwischen dem IMB-Abrechnungs-Datenbank-Zugriffs-Client und den Server-Einheiten.
Das Engineering-Objekt für
den Datenbank-Zugriff, das sowohl in der Benutzerprofil-Datenbank
als auch in den IMB-Abrechnungs-Clustern vorhanden ist, rechnet
die systemspezifische COTS-DB-Management-Funktionalität ab, die
den Kern der Server-Einheit für
den Zugriff auf die Benutzerprofil-Datenbank bzw. die Server-Einheit
für den
Zugriff auf die IMB-Abrechnungs-Datenbank implementiert.
-
Diese
Figur zeigt auch die IM-Verarbeitungs-Entität, die Aufgabe der speziellen
IM-Verarbeitungs-Funktionalität ist.
-
Die
MB-Architektur erlaubt es dem Konstrukteur, in Abhängigkeit
von den Anforderungen für
die spezifische Lösung
unter zahlreichen alternativen Implementierungen zu wählen. In
Abhängigkeit
von den Verwaltungskosten oder von Leistungsfaktoren, die von Implementierung
zu Implementierung variieren können, könnte es
in der Tat nützlich
sein, den MB und die Datenbanken in demselben Knoten zusammenzulegen
oder sie auf mehrere Knoten zu verteilen.
-
Diese
SW-Einheit ist in dem IMB-MB lokalisiert (siehe 15)
und bildet die IMB-Abrechnungs-Management-Operationen
des Teilnehmers auf Operationen der Benutzerprofil-Datenbank-Abfrageaktualisierung,
-erzeugung und -löschung
ab. Die beiden letzteren Operationen sind nur autorisierten Personen
erlaubt: Deshalb verifiziert die MB-Abrechnungs-Management-Einheit
immer die Autorisierungsebene des Teilnehmers, um zu prüfen, ob
die angeforderten Operationen verarbeitet oder zurückgewiesen
werden sollen.
-
Darüber hinaus
bildet diese Einheit die IMB-Abrechnungs-Management-Operationen
des Teilnehmers auch in IMB-Abrechnungs-Datenbank-Abfrageoperationen
ab. Die Abrechnungs-Information wird exklusiv von dem IMB-System
in einer geschützten
Weise erzeugt und verwaltet. Lediglich für Ausnahmefälle (und mit Autorisierung
des entsprechenden Teilnehmers) kann es System-Administratoren erlaubt
werden, die Abrechnungs-Information zu modifizieren (z.B. in dem
Fall einer Auseinandersetzung wegen einer Rechnung). Diese SW-Einheit
achtet deshalb darauf, daß Aktualisierungsprozeduren
zur Abrechnungs-Information nur autorisierten Personen zur Verfügung gestellt
werden.
-
Um
eigene empfindliche und proprietäre
Daten des Teilnehmers (wie Paßwörter, Geheimschlüssel usw.)
zu schützen,
die in einer der beiden erwähnten
Datenbanken gespeichert sind, sollten auf der anderen Seite System-Administratoren/IMB-Service-Provider
daran gehindert werden, an solchen Informationen irgendwelche Abfrage-
und Aktualisierungsoperationen vorzunehmen. Dem IMB-Service-Provider
sollte es einfach erlaubt sein, sensitive Informationen des Teilnehmers
zu erzeugen und zu löschen.
Zu diesem Zweck soll der IMB-Service-Vertrag spezielle Vorschriften
vorsehen, um implizite Fristen des Vertragsablaufs zu bestimmen,
falls vorhanden.
-
Sowohl
diese Einheit als auch die Kern-MB-Routing-Funktionalität benutzen
zwei Client-Untereinheiten für
den Datenbank-Zugriff, eine für
die Benutzerprofil-Datenbank und eine für die Abrechnungs-Datenbank: Jede
dieser Untereinheiten koordiniert alle entsprechenden Datenbank-Zugriffe.
-
Diese
SW-Einheit verwaltet schließlich
die Übertragung
der Ergebnisse der angeforderten Operationen zurück zu dem Teilnehmer.
-
Client-Einheit
für den
Zugriff auf die Benutzerprofil-Datenbank
-
Die
Einheit für
den Zugriff auf die MB-Datenbank kommuniziert über einen logischen Kanal mit
der Benutzerprofil-Datenbank. Dieser Kanal bildet eine Schnittstelle
mit der Einheit für
den Zugriff auf die MB-Datenbank über die Benutzerprofil-Datenbank-Zugriffseinheit.
Eine solche SW-Einheit reguliert den Kanalzugriff und verkapselt
Implementierungsdetails (die sich in Abhängigkeit davon ändern kann,
ob auf die Datenbank lokal – z.B.
durch IPC-Mechanismen – oder
entfernt – z.B.
durch TCP/IP- Verbindungen – zugegriffen
wird). Unabhängig
von der Implementierung des Kanals ist die Sicherheit aller Kommunikationen über ihn
zu gewährleisten.
-
Client-Einheit
für den
Zugriff auf die IMB-Abrechnungs-Datenbank
-
Die
Einheit für
den Zugriff auf die MB-Datenbank kommuniziert über einen logischen Kanal mit
der IMB-Abrechnungs-Datenbank. Dieser Kanal stellt eine Schnittstelle
für die
Einheit für
den Zugriff auf die MB-Datenbank zu der Einheit für den Zugriff
auf die IMB-Abrechnungs-Datenbank dar. Eine solche SW-Einheit reguliert
den Kanalzugriff und verkapselt Implementierungsdetails (die sich
in Abhängigkeit
davon ändern kann,
ob auf die Datenbank lokal – z.B.
durch IPC-Mechanismen – oder
entfernt – z.B.
durch TCP/IP-Verbindungen – zugegriffen
wird). Unabhängig
von der Implementierung des Kanals ist die Sicherheit aller Kommunikationen über ihn
zu gewährleisten.
-
IMB-Datenbank-Einheiten
-
Diese
Einheiten enthalten die Schlüsselinformation
des IMB-Gesamtsystems, das, wie oben beschrieben, als EMPP-Datenmodell
ausgedrückt
ist. Diese SW-Einheiten können
entweder unter Verwendung von COTS-Datenbank-Management-Systemen
oder als proprietäre
Lösung
implementiert sein. In jedem Fall besteht die strengste Anforderung,
die zu erfüllen
ist, in der Tatsache, daß IMB-Systeme
für eine
große
Verkehrsmenge mit extrem hohen Anforderungen an die Verfügbarkeit
konzipiert sind. Deshalb werden COTS-Lösungen bevorzugt, da sie erprobte
Lösungen
mit hoher Leistungsfähigkeit
zur Verfügung
stellen.
-
Die
Datenbanken sind so strukturiert, daß sie die IMB-Benutzerräume nach
dem EMPP-Modell in die spezifische Technologie der Wahl einpassen.
So wird z.B. als allgemeinste Lösung
die richtige Abbildung des EMPP auf relationale Datenbankmodelle
ins Auge gefaßt,
da viele bekannte COTS-Lösungen
das relationale Modell implementieren. Eine weitere alternative
Lösung
kann auf dem (reinen Java) Javaraum des Sun-Mikrosystems aufgebaut
sein, einem hochwertigen Werkzeug zur Prozeß-Koordination auf der Basis
des Tuple-Space-Konzepts.
-
Als
Beispiel wird in der folgenden Tabelle eine mögliche Abbildung des EMPP-Modells
auf ein Datenmodell einer relationalen Datenbank abgebildet:
-
Tabelle
I: Beispiel
einer EMPP-Daten-Modell-Abbildung auf einer relationalen Datenbank
mit einer einzigen Tabelle
-
Beispiel einer EMPP-Daten-Modell-Abbildung
auf einer relationalen Datenbank mit einer einzigen Tabelle
-
Server-Einheit
für den
Zugriff auf die Benutzerprofil-Datenbank
-
Die
Server-Einheit für
den Zugriff auf die Benutzerprofil-Datenbank kommuniziert über sichere
Datenkanäle
mit der Client-Einheit für
den Zugriff auf die Benutzerprofil-Datenbank und liefert die Grundfunktionalität für den Zugriff
auf die Benutzerprofil-Datenbank durch Lese-Schreib-Operationen.
-
Server-Einheit
für den
Zugriff auf die IMB-Abrechnungs-Datenbank
-
Die
Server-Einheit für
den Zugriff auf die IMB-Abrechnungs-Datenbank kommuniziert über sichere
Datenkanäle
mit der Client-Einheit für
den Zugriff auf die IMB-Abrechnungs-Datenbank und liefert die Grundfunktionalität für den Zugriff
auf die IMB-Abrechnungs-Datenbank durch Lese-Schreib-Operationen.
-
Die vorteilhaften
Hauptunterschiede der Erfindung zum Stand der Technik
-
Das
Folgende ist eine Liste der Vorteile, die diese Erfindung gegenüber dem
Stand der Technik bietet.
- 1. Direkter Zugriff
auf die persönliche
IMB-Benutzerprofil-Information, einschließlich der Abrechnungs-Information.
- 2. Ein kundenanpaßbarer
logischer Benutzerraum, den Teilnehmer benutzen können, um
existierende Benutzerprofile in Abhängigkeit von Änderungen
in dem Umfeld, in dem sie agieren, existierende Benutzerprofile
zu erzeugen und/oder zu modifizieren. Das Umfeld kann einen physikalischen
Ort repräsentieren (z.B.
ein Hotel oder einen Flughafen) oder einen logischen Kontext (z.B. "Heim" gegenüber "Arbeit"). Umfeldänderungen
können
partiell sein (immer wenn sich der Satz von in dem Umfeld verfügbaren Endgeräten aus
irgendwelchen Gründen ändert – z.B. ein
neues Telefaxgerät
zur Verfügung
gestellt wird oder eine GSM-Telefonnummer geändert wird) oder global (der
Teilnehmer zieht von einem Umfeld in ein anderes um).
- 3. Das ursprüngliche
EMPP-Modell ist gut geeignet für
die Informationsverteilung über
mehrere SW-Einheiten
(Prozesse, OS) und/oder HW-Einheiten (Computer).
- 4. Teilnehmer können
den Inhalt des Benutzerraums erweitern, sobald Endgeräte und/oder
neue Technologien verfügbar
sind.
- 5. Benutzerräume
können
nahtlos quer über
verschiedene Umfelder benutzt werden.
- 6. Innerhalb eines gegebenen Umfelds können Teilnehmer die Endgeräte-Priorität (die dem
MB anzeigt, an welches Endgerät
die ankommende Information bevorzugt gesendet werden soll) durch
das Konzept der Präsenz-Token-Signalisierung ändern. Die
Token-Vielfalt kann größer sein
als Eins, so daß man
gegen eine Zusatzgebühr
eine Instant Message gleichzeitig auf mehreren Geräten empfangen
kann.
- 7. Komplexere Anwendungen (wie ein Kalender zur Erzeugung von
Verabredungsnotizen, Weckrufen usw.) können in das IMB-System integriert
werden, indem letzteres mit zusätzlichen
IMB-Einheiten (die die gegebene Anwendung ausführen) und/oder mit COTS-Werkzeugen
(wie Microsoft Outlook, das das Kalenderbeispiel fortsetzt) verbunden
wird. In solchen Fällen
sollten anwendungsspezifische Daten in das Benutzerprofil eingefügt werden,
um das IMB-System zu instruieren, wie die externe Anwendung zur
Verarbeitung von Daten zu benutzen ist.
Ein weiteres Beispiel
für solche
einsetzbaren Anwendungen wäre
die Integration eines Sprachübersetzers: Der
IMB-MB benutzt eine externe Übersetzerapplikation
zur Bestimmung des endgültigen
Inhalts des zu sendenden IMB. In all diesen (und vielen anderen ähnlichen)
Fällen
spielt diese Erfindung insoweit eine Schlüsselrolle, als die durch sie
präsentierte
Benutzerprofil-Datenbank-Struktur flexibel genug ist, um irgendeine
Teilnehmer-Kundeninformation an ein Format anzupassen, das sich
gut für
ein Umfeld mit verteilter Verarbeitung eignet, wie es das IMB-System
darstellt.
• Durch
Erweiterung des in den vorangehenden Abschnitten benutzten Grundprinzips
können
IMB-Teilnehmer nicht nur die Anwendungen ihrer Wahl individuell
anpassen, sie können
sie vielmehr auch mit Mnemoniks benennen, d.h. mit einfach zu merkenden
logischen Namen (z.B. my_calendar, german_to_english_translator,
usw.).
- 8. Dieser Lösungsansatz
ebnet den Weg zu einer sauberen Integration zwischen IMB-Services
und mobilen Ad-Hoc-Netzwerk-Umfeldern: Änderungen des Umfelds können automatisch
detektiert und an das IMB-System signalisiert werden. Dieser Mechanismus
ermöglicht
ein schnelles adaptives Verhalten des Systems, das irgendwie mit
dem Mobilfunk-Handover-Mechanismus vergleichbar ist. Die Erfindung
richtet sich jedoch an eine sehr viel größere Menge von Diensten als
an reine Telefondienste.
-
Beispiel
-
Wie
in den vorhergehenden Abschnitten beschrieben wurde, befriedigt
die vorliegende Erfindung das Bedürfnis, die veränderbaren
Eigenschaften eines typischen IMB-Services-Szenarios (auch als veränderbares IMB-Umfeld
bekannt, siehe 13) anzusprechen und zu nutzen.
-
IMB-Teilnehmer
können überall kontaktiert
werden, insofern als sie verreisen können (d.h. an verschiedenen
Orten/Büros
erreichbar sind) und/oder ihren Satz an verfügbaren Endgeräten zu jeder
gegebenen Zeit rekonfigurieren können.
-
In
dem Beispiel von 13 versucht ein rufender Teilnehmer,
der sich in Moskau aufhält,
durch Verbindung mit dem IMB-System über ein Web-Interface (durch
Benutzen eines PC mit Internetzugang) eine IM an einen Geschäftsmann
HJK (d.h. den gerufenen Teilnehmer) zu senden. Der rufende Teilnehmer
weiß nicht, wo
sich der Geschäftsmann
derzeit befindet. Alles was der rufende Teilnehmer weiß, ist der
UN (z.B. HJK@sony.de) des Geschäftsmanns.
-
Auf
der Basis der in der Benutzerprofil-Datenbank gespeicherten Information
analysiert das IMB-System (i) den Aktivkontext und (ii) das derzeitige
Endgerät
des Geschäftsmannes.
-
Sobald
es diese Information erhalten hat, kann das IMB-System die IM (in
dem richtigen Datenformat, wie es von dem ausgewählten Endgerät vorgeschrieben
wird) an den gerufenen Teilnehmer weiterleiten.
-
Der
gerufene Teilnehmer kann sich zu verschiedenen Orten bewegen (z.B.
zu der Gesellschaft XYZ in Stuttgart) und/oder sich in verschiedenen
Situationen befinden (auf der Reise – er kann nur das Mobiltelefon und
ein vernetztes drahtloses Laptop benutzen – oder zuhause). Es ist leicht
ersichtlich, wieso der Aktivkontext ein lockeres Konzept ist. Die
Heim-Situation kann z.B. verschiedene Orte umfassen: Der Geschäftsmann
kann wählen,
daß sein
Aktiverkontext Heim auf sein physikalisches Heim und auf sein Büro auf dem
Gelände
der Gesellschaft XYZ in Stuttgart abbildet.
-
Auf
der anderen Seite kann das Hotel ABC in Los Angeles für die gesamte
Dauer eines bestimmten Geschäfts
zu dem neuen Heim des Geschäftsmanns
werden. Deshalb kann der Geschäftsmann
entscheiden, einen einzelnen Ort (Hotel in Los Angeles) oder zwei
Kontexte, Heim (für
private Nachrichten) und auf Reisen (für geschäftliche Angelegenheiten ) abzubilden.
-
Der
Geschäftsmann
kann die hier dargestellte Erfindung jederzeit dazu benutzen, sein
IMB-Benutzerprofil zu konfigurieren, um alle diese Merkmale anzusprechen.
Darüber
hinaus kann er das IMB-System zwingen, IMs an entfernte Orte nachzusenden
(z.B. immer eine Kohlepapier-Kopie jeder ankommenden IM an das Telefaxgerät in dem "physikalischen" Heim zu senden).
Dieses Ziel läßt sich
durch Benutzung des Token-Konzepts problemlos erreichen.