-
Die
vorliegende Erfindung betrifft im Allgemeinen das Gebiet der mobilen
Multimedia-Middleware, Computernetzwerke, verteilten Verarbeitungssysteme,
(Benutzerprofil-)Datenbanken, tragbare Computer, Web-Browser und
drahtlosen Kommunikation.
-
Insbesondere
betrifft die vorliegende Erfindung ein Verfahren zum Managen einer
Benutzerprofilinformation in Netzwerkdiensten, ein Computer-Softwareprogramm
zum Implementieren eines solchen Verfahrens sowie eine grafische
Benutzerschnittstelle.
-
Aus
der
EP 00 104 259.7 im
Namen von Sony International (Europe) GmbH, eingereicht am 01. März 2000,
ist eine Technik zum bequemen Abrufen von zuvor gesammelten Informationen
aus einer Benutzerprofildatenbank bekannt.
-
Benutzerprofildatenbanken
werden z. B. bei Mitteilungsdiensten verwendet. Das Ziel eines Nachrichtendienstes
besteht darin, eine Information wie Mitteilungen, die von einem
Diensteabonnenten an einen weiteren gesendet werden, anhand von
durch den Letztgenannten bereitgestellten Instruktionen auszuliefern. Diese
Instruktionen können
innerhalb des Systems, das den Dienst implementiert, gespeichert
werden, und können
verwendet werden, das System so zu steuern, dass ein bevorzugtes
Endgerät
der angerufenen Partei ausgewählt
wird. Wenn dieses ausgewählt
ist, verwendet das System ein solches Endgerät zum Ausliefern der Information
der anrufenden Partei an die angerufene Partei. Die angerufene Partei
hat auch die Möglichkeit, Kopien
einer vorgegebenen Eingangsmitteilung in weiteren Endgeräten zu empfangen.
-
Vorausgesetzt,
dass der Typ des Endgerätes
der angerufenen Parteien sich von dem der anrufenden Partei unterscheiden
kann, kann es für
das Mitteilungssystem erforderlich sein, eine geeignete Mitteilungsformatumwandlung
vorzunehmen. Diese Informationsverarbeitung kann sogar weiterhin
mit der zusätzlichen Funktionalität erweitert
werden, wie z. B. das Hinzufügen
eines Bezahlen-bei-Ansehen-Inhalts zu der Ursprungsinformation.
Jedem Abonnenten des Systems wird ein Benutzerbereich innerhalb
des Benutzerprofils des Systems zugeordnet. Innerhalb dieser Art
eines persönlichen
Accounts können
Abonnenten ihre eigenen Vorzüge
organisieren (hinsichtlich der persönlichen Information, der Endgeräte, Anwendungen
und verwendeten Dienste und der vielfältigen Orte/Situationen, in
denen die vorbestimmten Dienste stattfinden können), wie in
EP 00 104 259.7 beschrieben ist.
Hinsichtlich weiterer Details des Konzepts einer Benutzerprofildatenbank und
deren Management wird ausdrücklich
auf die
Europäische Patentanmeldung
00 104 259.7 im Rahmen der Sony International (Europe)
GmbH Bezug genommen.
-
Benutzerprofile
können
in geordnete Gruppen gruppiert werden, die im folgenden Kontext
genannt werden, um so (i) einen erweiterbaren Mechanismus bereitzustellen
und (ii) Default-Informationen gleichermaßen bereitzustellen. Insbesondere
können
Benutzerprofile, die der Position und/oder Situationsinformation
zugeordnet sind, eine Liste von bevorzugten Frontend-Endgeräten (Frontend-Einheiten)
enthalten, an die die Mitteilungen vorzugsweise gesendet werden
sollen.
-
Das
Dokument
EP 0 611 070
A2 beschreibt ein Mobiltelefon, das sich mit mehreren Betriebseigenschaften,
wie der Lautstärke
eines Ausgangssignals, der Lautstärke des Klingelns und der Erzeugung
von Tönen
befasst. Das Mobiltelefon umfasst eine Einrichtung zum Definieren
mehrerer Gruppen der Eigenschaften, wobei jede Gruppe vorbestimmte
Werte der Eigenschaften umfasst. Eine bestimmte Gruppe von Eigenschaften
kann durch den Benutzer ausgewählt
werden, was dazu führt,
dass mehrere Eigenschaften gleichzeitig modifiziert werden. Wenn
man sich von einer Umgebung in eine weitere bewegt, ist es daher
für einen
Benutzer möglich,
mehrere Betriebseigenschaften gleichzeitig durch Auswahl in einem
einzigen Menü zu
modifizieren.
-
Das
Dokument
WO 00/04730
A stellt ein Verfahren zum Implementieren eines personalisierten
positionsbasierten Dienstes in drahtlosen Netzwerken zur Verfügung. Dieses
Verfahren ermöglicht
es, für
ein Telefon eines Abonnenten, einen bestimmten positionsbasierten
Dienst anzufordern. Abhängig
von der aktuellen Position des Abonnenten sowie von den Positionen
der verschiedenen Diensteanbieter, identifiziert das System geeignete
Kandidatendiensteanbieter. Dann wird ein Abonnentenprofil verwendet,
um einen oder mehrere geeignete Diensteanbieter aus der Liste der
Kandidatendiensteanbieter zu identifizieren. Die Kandidatendiensteanbieter,
die gemäß dem Abonnentenprofil
ausgewählt
werden, werden einem Menü,
das dem Abonnenten bereitgestellt wird, hinzugefügt. Infolge kann der Abonnent
einen Diensteanbieter aus dem Menü auswählen und diese Auswahl an das
System senden, um den gewünschten
Diensteanbieter anzugeben.
-
Dokument
US 5,822,212 offenbart ein
zensierendes Browserverfahren zum Betrachten des Internets. Dieses
Verfahren umfasst das Speichern eines Benutzerprofils, das benutzergewählte Zensierungsparameter umfasst.
Nach dem Browsen des Internets mithilfe dieses Verfahrens werden
empfangene Datenpakete mit den benutzergewählten Zensierungsparametern
verglichen. Infolge dieses Vergleichs werden die empfangenen Datenpaketinhalte
verarbeitet und wahlweise infolge der benutzergewählten Zensierungsparameter
angezeigt. Die benutzergewählten
Zensierungsparameter umfassen Worte, Wortfragmente, Kategorien,
die entfernt werden können
und wahlweise mit geschönten
Zeichen oder akzeptablen Ersatzworten ersetzt werden können.
-
Dadurch
adressiert die vorliegende Erfindung das Problem des Managens von
mehreren Kontexten, wie oben beschrieben, in einer benutzerfreundlichen
Weise.
-
Diese
Aufgabe wird durch die Merkmale der unabhängigen Ansprüche gelöst. Die
abhängigen
Ansprüche
entwickeln die zentrale Idee der vorliegenden Erfindung weiter.
-
Gemäß der vorliegenden
Erfindung wird daher ein Verfahren zum Managen einer Benutzerprofilinformation
vorgeschlagen. Mehrere Kontexte können einem Benutzer zugeordnet
werden, wobei ein Kontext als eine Gruppe von Netzwerkkommunikationsfrontend-Endgeräte, die
einer Umgebung zugeordnet sind (logische oder geografische Bedingung)
definiert ist. Gemäß der Erfindung
wird die Historie von benutzten Kontexten gespeichert, so dass der
Benutzer später
die Liste der besuchten „Kontexte" durchgehen kann,
den Gewünschten
auswählen
kann und von dem aktuellen Kontext zu dem Ausgewählten umschalten kann. Vorzugsweise
werden nur kürzlich
verwendete Kontexte gespeichert. Zumindest der historisch erste
Kontext kann einem sog. Heimkontext entsprechen, der direkt, ohne
die folgenden Kontexte zu Durchscrollen, ausgewählt (zugegriffen) werden kann.
-
Gemäß einem
weiteren Aspekt der vorliegenden Erfindung wird ein Verfahren zum
Managen von Benutzerprofilen vorgeschlagen, gemäß dem mindestens ein Kontext
eines Benutzers als ein Heimkontext eingestellt (aktiviert) wird,
so dass der Benutzer diesen direkt auswählen (auf diesen zugreifen)
kann.
-
Mindestens
ein Heimkontext kann als ein zeitweilig gesetzter Heimkontext eingestellt
werden.
-
Mehrere
Heimkontexte können
eingestellt werden, wobei jeder Heimkontext mindestens einer Bedingung
zugeordnet ist.
-
Einer
der mehreren Heimkontexte kann automatisch bei der Detektion der
entsprechenden Bedingung aktiviert werden, wobei die Bedingung sich
auf die Zeit, Position oder Situation beziehen kann.
-
Ein
Zeitstempel der letzten Aktualisierung kann jedem Kontext hinzugefügt werden.
Weiterhin kann ein Zeitstempel der letzten Aktualisierung jedem
Frontend-Endgerät
eines Kontextes als Attribut zugefügt werden.
-
Der
Kontext kann lokal in einem Frontend-Endgerät zwischengespeichert und/oder
auf einem Benutzerprofilserver gespeichert werden.
-
Gleichermaßen können mit
einem Abrufen eines Kontextes die zugeordneten Zeitstempel der lokal
in dem Frontend-Endgerät
und dem Server zwischengespeicherten Version auf Konsistenz überprüft werden. Wenn
die Konsistenzüberprüfung der
Zeitstempel eine Diskrepanz zeigt, übernimmt die Server-Version
die Priorität
und die lokal zwischengespeicherte Version wird überschrieben.
-
Gemäß einem
weiteren Aspekt der vorliegenden Erfindung wird ein Computer-Software-Programm vorgeschlagen,
das ein obiges Verfahren implementiert, wenn es in den Speicher
eines Netzwerk-Verarbeitungsgeräts
geladen wird.
-
Gemäß einem
weiteren Aspekt der vorliegenden Erfindung wird eine grafische Benutzerschnittstelle zum
Managen von Benutzerprofilen vorgeschlagen, wobei die grafische
Benutzerschnittstelle eine Navigationsleiste zum Durchführen eines
obigen Verfahrens umfasst.
-
Weitere
Aspekte, Merkmale und Aufgaben der vorliegenden Erfindung werden
für den
Fachmann offensichtlich, wer die nachfolgenden ausführlichen
Beschreibungen der Ausführungsform
der vorliegenden Erfindung in Verbindung mit den Figuren der beigefügten Zeichnungen
liest.
-
1 zeigt
ein Beispiel einer gegenseitigen Umgebung eines Mitteilungsdienstes,
-
2 zeigt
eine Navigationsleiste gemäß der vorliegenden
Erfindung
-
3 zeigt
ein Benutzungsfalldiagramm
-
4 zeigt
die Erfindung von einem Informationsstandpunkt,
-
5 zeigt
die Erfindung von einem Datenverarbeitungsstandpunkt, und
-
6 zeigt
eine Darstellung der vorliegenden Erfindung gemäß einem Ingenieursstandpunkt.
-
Die
vorliegende Beschreibung wird im Bezug auf eine Benutzerprofildatenbank
vorgenommen, die in Verbindung mit einem sog. einheitlichen Sofortmitteilungssystem
(Unified Instant Messaging System) verwendet wird. Es ist jedoch
wichtig anzumerken, dass das Benutzerprofildatenbankkonzept auf
jegliche Arten von Netzwerkdiensten verwendet werden kann.
-
Abkürzungen
-
-
- ACTS
- Advanced Telecommunication
Technologies and Services
- C
- OTS Commercial Off-The-Shelf
- EGS
- Eingangs-Gateway-Dienst
- sEGSS
- Eingangs-Gateway-Dienste-Server
- EGSC
- Eingangs-Gateway-Dienste-Client
- FS
- Frontend-Einheit
- FST
- Frontend-Einheits-Vorlage
- HW
- Hardware
- GUI
- Grafische Benutzerschnittstelle
- IMB
- Sofortmitteilungs-Broker
- IP
- Internetprotokoll
- ITU-T
- International Telecommunication
Union-Telecommunication
- MASS
- Mobile Application
Support Environment Mobile Anwendungsunterstützungsumgebung
- ODP
- Offene verteilte Verarbeitung
- PDA
- Persönlicher
Datenassistent
- PSE
- Persönliche-Dienste-Umgebung
- SW
- Software
- UIM
- Einheitliche Sofortmitteilung
- UML
- Vereinheitlichte Modellierungssprache
- UMTS
- Universal Mobile Telecommunication
System Universelles Mobiltelekommunikationssystem
-
Die
folgenden Paragraphen beschreiben die vorliegende Erfindung, unter
Berücksichtigung
der ODP-Methode (siehe z. B. G. Blair, J. Bernard Stefani, „Open Distributed
Processing and Multimedia",
Addison Wesley, ISBN 0-201-17794-3
als Richtlinie. Insbesondere werden die fünf ODP-Standpunkte (nachfolgend aufgeführt) hierdurch
in einer informellen Weise verwendet.
- 1. Unternehmen
(Zweck des Systems, Rolle in dem Unternehmen, Grenzen des Systems,
Anforderungen der Anwendungsfälle
aus Kundensicht)
- 2. Information (Struktur der Information, die durch das System
gemanagt wird)
- 3. Computerbezogen (Systemfunktionalität)
- 4. Ingenieursbezogen (Mechanismen, die die Systemfunktionalität implementieren
und Verteilungstransparenzen bereitstellen)
- 5. Technologie (technische Lösungen,
die zum Erreichen der Ziele der vorstehenden Gesichtspunkte verwendet
werden).
-
Anwendungsbeispiel
-
Es
kann erforderlich sein, IMB-Abonnenten überall zu kontaktieren, da
sie auf Reisen sein können
(d. h. an verschiedenen Orten/Büros
erreichbar sein sollen) und/oder sie können ihre Gruppe verfügbarer Endgeräte zu jedem
bestimmten Zeitpunkt umkonfigurieren.
-
1 stellt
den einfachsten Fall eines IMB-Systems dar.
-
Eine
anrufende Partei, die ihren Standort in Moskau hat, versucht eine
Sofortmitteilung an den Geschäftsmann
HJK (das ist die angerufene Partei) zu senden, indem das IMB-System
2 über eine
Webschnittstelle
5 (mithilfe eines PCs mit Internetzugang)
verbunden wird. Die anrufende Partei weiß nicht, wo sich der Geschäftsmann
momentan aufhält.
Alles, was die anrufende Partei über
die angerufene Partei weiß,
ist der IMB-Abonnenten-Name des Geschäftsmann (z. B. imb://
[email protected]).
-
Anhand
der in der (globalen) Benutzerprofildatenbank gespeicherten Information
löst das
IMB-System 2 die aktive Frontend-Einheit (i) des Geschäftsmanns
auf und (ii) das aktuelle Endgerät.
-
Hat
das IMB-System 2 diese Information erhalten, kann es letztendlich
die Sofortmitteilung an die angerufene Partei weiterleiten (mit
dem geeigneten Datenformat, wie es durch das ausgewählte Endgerät vorbeschrieben
ist).
-
Die
angerufene Partei kann sich an verschiedene Positionen bewegen (z.
B. kann er bei dem Untemehmen XYZ in Stuttgart sein) oder in verschiedenen
Situationen (auf Reisen könnte
er nur ein Mobiltelefon 19 und einen Labtop 20 verwenden
oder zu Hause, wo er mit einem Anrufbeantworter 3 und einem
Fax 4 ausgestattet ist). In einem speziellen Fall kann
das Hotel ABC in Los Angeles ein neues Zuhause für den Geschäftsmann für eine bestimmte Zeitdauer
werden. Zwischenzeitlich würde
der Geschäftsmann
gerne auf seinem Mobiltelefon (durch das IMB-System) erreicht werden
und nicht Sofortnachrichten an dem öffentlichen Faxgerät 4 des
Hotels empfangen (z. B. aus privaten Gründen). Um dies durchzuführen, hat
er das FST, das durch das Hotel IGS 21 angeboten wird,
kundenspezifisch eingestellt, indem sein Mobiltelefon 19 hinzugefügt wurde
und das Faxgerät 4 des
Hotels entfernt wurde. Das Hotel kann weiterhin die Verwendung eines
Besprechungsraumes 6 anbieten.
-
Ein
IMB-Anbieter kann entscheiden, zu einem der voran ausgewählten Kontexte
zurückzuschalten und
somit die Möglichkeit,
diese Operation rückgängig zu
machen, entweder vollständig
oder teilweise (Konzept der Historie).
-
Weiterhin
kann ein IMB-Argument wünschen,
jederzeit zu dem Kontext zurückzukehren,
auf dem das Default-Benutzerprofil des Abonnenten Bezug nimmt (siehe
EP 00 104 259.7 ). Dieser
Heimkontext kann als ein PSE betrachtet werden. Zusätzlich kann
der IMB-Abonnent wünschen,
den Heimkontext so zu ändern, dass
er sich auf einen weiteren Kontext innerhalb des Default-Benutzerprofils
bezieht. Diese Änderung
kann manuell oder automatisch durchgeführt werden, wobei die letztere
auf der Übereinstimmung
der konfigurierten Information mit den aktuellen Bedingungen der
Benutzererfahrung basiert.
-
Aus
Gründen
der Leistungsfähigkeit
können
die Heimkontextidentität,
die Kontexthistorie und die Kontextinformation lokal in denjenigen
Frontends zwischengespeichert werden, die mit einer sekundären Speichereinheit
ausgestattet sind.
-
2 stellt
ein Beispiel einer „Kontext-Navigationsleiste" einer grafischen
Benutzerschnittstelle dar, wobei alle Funktionalitäten, die
in den vorangehenden Abschnitten beschrieben werden, visuell als
eine Gruppe von Knöpfen
dargestellt werden. Einige Knöpfe
sind mit einer direkten Handlung verbunden (z. B. Gehe einen Schritt
zurück),
wobei weitere mit einem Dropdown Menü verbunden sind, aus dem der
Benutzer ein bestimmtes Funktionselement auswählen kann.
-
Der „Kontext-Management"-Knopf ist mit einem
Dialogfenster verbunden, wobei der Benutzer die folgende Funktionalität durchführen kann:
- – Erzeuge
einen neuen Kontext
- – Editiere
einen Kontext
- – Lösche einen
Kontext
- – Speichere/speichere
als einen Kontext
-
Gemäß den Standard
GUI Design-Richtlinien kann diese Funktionalität in noch geeigneterer Weise Dateielemente
und Editiermenüelemente
zugeordnet sein. Daher kann in einem solchen Fall der „Kontext-Management"-Knopf, der in dieser
Figur angegeben ist, aus der Menüleiste
weggelassen werden.
-
Alle
möglichen
Szenarien werden in dem UML-Benutzungsfalldiagramm, das in 3 gezeigt
ist, zusammengefasst.
-
Beispielszenarium
-
Ein
Geschäftsmann
kann einen Einheits-Sofortmitteilungsdienst mit einem IMB-Diensteanbieter
abonniert haben. Zum Zeitpunkt des Abonnierens hat er seine Bürotelefonnummer
und Faxnummer, seine Mobiltelefonnummer, seine Geschäfts-E-Mail-Adresse
in eine Frontend-Einheit eingegeben, die als das sog. Default-Nutzerprofil
bestimmt ist. Zu einem späteren
Zeitpunkt besucht der Geschäftsmann
eine Ausstellung im Ausland und entdeckt dort einen Eingangs-Gateway-Server,
der eine Frontend-Einheits-Vorlage bewirkt, die der Besucher kundenspezifisch
anpassen kann, um Mitteilungen auf die lokal verfügbaren,
gemeinsam genutzten Endgeräte
(z. B. ein Faxgerät)
umzuleiten. Dieser Prozess kann mehrere Male durchgeführt werden.
-
Am
Ende seiner Geschäftsreise
bemerkt der Geschäftsmann,
dass er eine Reihe von kundenspezifischen Kontexten gesammelt hat,
die er in naher oder ferner Zukunft benötigen könnte. In dem erstgenannten Fall
wäre es
bequem, die Liste der kürzlich „besuchten" Kontexte zu durchscrollen,
um denjenigen auszuwählen,
den er zum gegebenen Zeitpunkt benötigen könnte. Vorausgesetzt, dass eine
solche Liste ziemlich lang sein könnte (und/oder die Anfangskontextidentität könnte nicht
so leicht in Erinnerung zu behalten sein), kann der Geschäftsmann
weiterhin wünschen,
sich direkt zu dem Default-Profil zu bewegen, indem einfach ein Heim-Ul-Element
(z. B. ein Knopf) ausgewählt
wird. Alternativ könnte
er es nützlich
finden, eine der „besuchten" Frontend-Einheiten als sein
zeitweiliges neues Heim auszuwählen.
Daher sollte dem Geschäftsmann
die Fähigkeit
bereitgestellt werden, den Kontext, der die Heimrolle übernimmt,
zu ändern.
-
Weiterhin
kann es der Geschäftsmann
bequem finden, mehrere Heimkontexte zu besitzen, die jeweils einer
unterschiedlichen Gruppe von Bedingungen zugeordnet sind (z. B.
die Art des verwendeten Endgeräts, Position
und/oder Situation, Typ und/oder verwendete Anwendung, Zeit/Datum).
Diese Heimkontexte können zueinander
vollständig
ohne Bezug sein oder voneinander abgeleitet sein gemäß eines
Spezialisierungsschemas, das in der
EP
00 104 259.7 beschrieben ist.
-
Zum
Beispiel kann der Geschäftsmann
seinen Benutzerbereich so konfigurieren, dass jedes Mal, wenn er
sein Mobiltelefon in einem bestimmten Land benutzt, die einen Heimkontext
reflektierende lokale Information erhält. Weiterhin erhält er automatisch
einen weiteren Heimkontext, der für diesen verschiedenen Benutzungsfall
spezialisiert ist, während
er eine Webschnittstelle verwendet (das ist ein COTS-Webbrowser zum
Zugreifen auf ein bestimmtes Internet-Portal).
-
Das Heimkonzept
-
Wie
in
4 gezeigt ist, ist jedem IMB-Abonnent ein Benutzerbereich
zugeordnet, der neben anderer Information das sog. Default-Benutzerprofil,
ein (<Benutzer>, Default, Default,
Default, Default, Default, Default)-Tupel, das eine persönliche Information
des Benutzers enthält
(siehe
EP 00 104 259.7 ).
Im Bezug dazu drückt
das (<Benutzer>, Default, Default,
Default, IMB, Default, Default)-Tupel die allgemeinen Präferenzen des
Benutzers aus, z. B. für
das, was den IMB-Dienst betrifft.
-
Das
6-Tupel (Benutzer, Endgerät,
Netzwerk, Anwendung, Situation, Position), das in
EP 00 104 259.7 beschrieben ist,
wird hierdurch mit einer zusätzlichen
Kartennamenkomponentenart, das ist der Dienst, erweitert. Der Dienst
ist eine allgemeine Ressource, die einer Gruppe von autorisierten
Abonnenten angeboten wird. Der Dienst kann direkt durch Anwendungen
in Art eines Komponentenmodells verwendet werden, z. B. Sprachübersetzungsanwendungen,
die über
den IMB-Dienst laufen. Das resultierende 7-Tupel ist somit (Benutzer,
Endgerät,
Netzwerkdienst, Anwendung, Situation, Position). Weiterhin kann
die Anzahl der Benutzerbereichs-Dimensionen erweitert werden, indem
noch ein weiterer Kartennamenkomponententyp, das Zeit-/Datum-Feld
hinzugefügt
wird, das ein relatives Zeitfenster angibt, die verwendet werden
können,
um den Kontext weiter zu spezifizieren. Dadurch wird das zuvor genannte
Tupel zu einem 8-Tupel.
-
In
einem solchen Tupel kann man einfach ein neues Schlüsselwertpaar
einfügen,
das die Identität
des Kontextes angibt, den der Benutzer als denjenigen ausgewählt hat,
der die Heimrolle übernimmt.
-
Mehrfachheimkontexte
-
Wie
zuvor erwähnt
kann der Benutzer wünschen,
nicht nur einen, sondern mehrere Heimkontexte zu konfigurieren,
die jeweils eine bestimmten Gruppe von Bedingungen betrifft, dem
sich der Benutzer in einem bestimmten Moment gegenübersieht.
-
Um
dies vorzunehmen, kann der Benutzer einen Kontext einem bestimmten
8-Tupel zuordnen und/oder
den Begriff des Heimkontextes in einem Schlüssel-Wert-Paar, das einer Frontend-Einheit
zugeordnet ist, einbetten. Das spätere Verfahren ermöglicht es
dem Benutzer, Kontexte frei zu konfigurieren anhand einer benutzerspezifischen
und logischen Zuordnung im Vergleich zu den vorhergehenden Verfahren.
-
Das Historienkonzept
-
Weiterhin
können
zusätzliche
Schlüsselwertpaare
in dem zuvor erwähnten
Tupel die Identitäten
der kürzlich
gesuchten Kontexte enthalten. Kontexte können mit einem Namen (Mnenonic)
identifiziert werden.
-
Die
Historieninformation wird somit in dem System gespeichert. Optional
kann man auch eine solche Information direkt in einer Frontend-Einheit
mithilfe einer lokalen sekundären
Speichereinheit, wenn eine solche verfügbar ist, speichern.
-
Bei
dem späteren
Ansatz gewinnt man an Leistungsfähigkeit
(das ist keine Notwendigkeit, mit dem IMB-System zum Überprüfen der
Historie zu kommunizieren), wodurch der erstere Ansatz den Benutzern
eine globale Historieninformation bereitstellt. Dies bedeutet, dass
man die Historie von verschiedenen Frontend-Einheiten zu verschiedenen
Zeiten benutzen kann.
-
Zwischengespeicherte Kontextinformation
-
Das
Zwischenspeichern der Kontextinformation kann auf der Seite des
Endgeräts
in einer sekundären Speichereinheit,
wenn eine solche verfügbar
ist, erfolgen. Bei diesem Ansatz erhöht man die Leistungsfähigkeit
(d. h. keine Notwendigkeit, mit dem IMB-System zum Überprüfen der
Historie und zum Herunterladen des Kontextinhalts zu kommunizieren.
-
Rechenbezogener Standpunkt
-
Der
IMB-Abonnent kann eine Benutzerschnittstelle zum Zugreifen auf die
folgende Funktionalität
verwenden:
- 1. Heim-Management Client Einheit:
1.1
Schalte zu Heim-Frontend-Einheit
1.2 Ändere Heim-Frontend-Einheit
1.2.1.
Manuell
1.2.2 Automatisch, nach dem Zugriff auf die Frontend-Einheit
(das ist während
der Login-Phase, wenn auf ein Internet-Portal, das IMB-Dienste anbietet,
zugegriffen wird) anhand des aktuellen Kontextes.
- 2. Historien-Management-Client-Einheit
2.1 Schalte zum
nächsten
Kontext in der Vorwärtsrichtung
der Historie
2.2 Schalte zum nächsten Kontext in der Rückwärtsrichtung
der Historie
2.3 Schalte zu dem n-ten nächsten Kontext in der Vorwärtsrichtung
der Historie
2.4 Schalte zu dem n-ten nächsten Kontext in der Rückwärtsrichtung
der Historie
2.5 Historienschnitt (history pruning): Dies ist
ein besonderer Fall des Historienmanagements, der zum Erzwingen
von Zwischenspeicheraktualisierungen verwendet wird.
- 3. Zwischenspeicherregelung und Zwischenspeichersteuereinheiten
(optional)
3.1 Abrufen der Beschreibung des ausgewählten Kontexts
aus dem Zwischenspeicher
3.2 Zwischenspeichere Alterungsregelungen
-
Jedes
Frontend kann mit Client-Einheiten ausgestattet sein, die die zuvor
erwähnten
Ul-Befehle entweder an die lokale sekundäre Speichersteuereinheit (im
Falle des Zwischenspeichermechanismus) oder an das IMB-Account-Managementsystem,
wie es in
EP 00 104 259.7 (siehe
5)
beschrieben ist, weiterleitet:
Gemäß der ODP grafischen Notation
und Terminologie (Gordon Blair, J. Bernard Stefani, „Open Distributed Processing
and Multimedia",
Addison Wesley, ISBN 0-201-17794-3) geben die Kreise in
5 logische
rechenbezogene Objekte an, wobei Kästchen mit abgerundeten Ecken
für Verbindungsabstraktionen
stehen und Bögen
aus Doppelkreuzen die Schnittstellen zwischen den Objekten darstellen.
-
Auf
Seite des Clients 22 kommuniziert eine IMB-Account-Management-Client-Einheit 10 mithilfe
eines Drahtloskanals 18 mit einer IMB-Management-Server-Einheit 11.
Die IMB-Account-Management-Client-Einheit 10 ist logisch
mit einer Heim-Management-Client-Einheit 8 und einer Historien-Management-Client-Einheit 9 verbunden.
Die Historien-Management-Client-Einheit 9 ist logisch mit
einer Zwischenspeicherregelungeneinheit 12 mit einer Zwischenspeichersteuereinheit 13 (siehe 6 zur
weiteren Erläuterung)
verbunden. Die Historien-Management-Client-Einheit 9 und
die Heim-Management-Client-Einheit 8 sind
jeweils mit einer browserartigen Benutzerschnittstelle 7 verbunden.
-
Die
Frontend-Einheit (Client) 22 soll ein geeignetes Zwischenspeicheralterungsverfahren
mit Hilfe einer Zwischenspeicherverfahreneinheit 12 durchsetzen.
Jeder Kontext soll tatsächlich
einen Zeitstempel enthalten, der das Datum der letzten Aktualisierung
der Frontend-Einheit und/oder eine weitere Präferenzeninformation angibt,
in der Benutzerprofildatenbank 1. Wenn man durch die Historie
navigiert, sollen vor dem Umschalten zu dem ausgewählten Kontext
Konsistenzüberprüfungen zwischen
den ausgewählten
zwischengespeicherten Informationen und der entsprechenden Information,
die in der Benutzerprofildatenbank gespeichert ist, anhand der Zeitstempel
durchgeführt
werden. Die Zeitstempel der Kontexte, die in den bestimmten zwischengespeicherten
Kontexten enthalten sind, sollen mit den Zeitstempeln der entsprechenden
offiziellen Versionen, die in der Benutzerprofildatenbank enthalten
sind, übereinstimmen.
Wenn eine Diskrepanz auftritt, wird die zwischengespeicherte Version
mit der Datenbankversion, die die Priorität übernimmt, überschrieben.
-
Um
die Leistungsfähigkeit
zu erhöhen,
kann dieser Mechanismus sogar auf einem niedrigeren Niveau durchgeführt werden:
man kann nicht nur den gesamten Kontext mit einem Zeitstempel versehen,
sondern auch jedes Frontend, das in der Frontendgruppe, die in dem
Kontext enthalten ist, gelistet ist. Auf diese Weise würden nur
Zwischenspeicheraktualisierungen auf ein Frontend-Niveau innerhalb
eines Kontextes stattfinden, im Gegensatz zu einer Aktualisierung
des gesamten Kontextes.
-
Technikbezogener Standpunkt
-
Intern
umfasst die Verarbeitungseinheit eine Menge von Einheiten, die jeweils
eine bestimmte Aufgabe wahrnehmen (siehe
6):
| Einheitenname | Einheitenbeschreibung |
| Browserartige
Ul-Einheit 7 | Stellt
eine Mensch-Maschinen-Schnittstelle |
| | bereit, ähnlich der
eines Web-Browser mit dem Konzept des Rückwärtsgehens (sogar mehrfach mit
einer Anzahl größer 1),
des Vorwärtsgehens
(sogar mehrfach mit einer Anzahl größer 1), des Auffrischens, des
Springens zum nächsten
Heimkontext, des Ändern
des Heimkontexts, des Beschneidens der Historie |
| Heimmanagement-Client-Einheit 8 | Verwendet,
um
1. den Heimkontext als den aktiven festzulegen,
2.
den Heimkontext zu ändern |
| Historienmanagement-Client-Einheit 9 | 1.
Schalte zum nächsten
Kontext in der Vorwärtsrichtung
der Historie
2. Schalte zu nächsten Kontext in der Rückwärtsrichtung
der Historie
3. Schalte zu dem n-nächsten Kontext in der Vorwärtsrichtung
der Historie
4. Schalte zu dem n-nächsten Kontext in der Rückwärtsrichtung
der Historie
5. Historien schneiden
6. Koordinieren des
Zwischenspeichermechanismus (wenn der Zwischenspeicher unterstützt wird) |
| IMB-Account-Management-Client-Einheit 10 | Siehe EP 00 104 259.7 |
| IMB-Account-Management-Server-Einheit 11 | Siehe EP 00 104 259.7 |
| Zwischenspeicher-Durchführungseinheit 14 | 1. Überprüfe Zeitstempel-Alterungsverfahren
2.
Koordiniere die Einführung
und Löschung
des Zwischenspeichers
3. Koordiniert den Abruf des Zwischenspeichers |
| Zwischenspeicher-Steuereinheit 13 | 1.
Zwischenspeicher einfügen
und löschen
2.
Zwischenspeicher-Abruf |
-
In 6 geben
gemäß der ODP-grafischen
Notations- und Terminologie Kreise physikalische technische Grundobjekte
(das sind SW-Untereinheiten, aus denen das System zusammengesetzt
ist) an. Kästchen mit
abgerundeten Ecken stellen Cluster dar (das sind eine Gruppe von
technischen Grundobjekten mit engem Bezug, die in einem einzelnen
Speicheradressraum kopiert sind). Die grau colorierten Rechtecke
stellen physikalische Kanäle
dar, die eine Zwischenclusterkommunikation darstellen.
-
Diese
Kommunikation kann Software-Prozesse (durch IPC-Mechanismen, die
durch das zugrundeliegende OS bereitgestellt werden) oder Hardware-Vorrichtungen (durch
Netzwerkverbindungen) übergreifen. Der
Kern stellt in ODP-Terminologie das zugrundeliegende OS dar. Doppelt
gezeichnete Bögen
stellen die Schnittstellen zwischen den verschiedenen Objekten dar.
-
Auf
diesem Niveau wird kein physikalisches Verteilen von Clustern zwischen
SW-Speicheradressräumen
(auch als Prozesse oder in ODP-Terminologie Kapseln genant) hierdurch
dargestellt, da die hierin beschriebene Architektur ziemlich modular
ist.
-
Die
Gegenstücke
der Heim- und Historienmanagement-Client-Einheiten auf dem Server-Niveau
sind in die IMB-Account-Management-Server-Einheit mit zusätzlichen
Operationen, die durch die Einheit unterstützt werden, eingebettet. Die
Ausnahmen sind:
- 1. Das Informationsschema,
das in 4 dargestellt ist.
- 2. Jegliche Erzeugung/Aktualisierung der Frontend-Gruppe, wird
einem entsprechenden Zeitstempel zugeordnet. Bei solchen Gelegenheiten
soll die IMB-Account-Management-Server-Einheit einen Zeitstempel
in ihren Frontend/Kontext einfügen.
-
Technologiestandpunkt
-
Die
Erfindung ist als Gruppe von Einheiten beschrieben, die vollständig als
Software-Einheiten (SW-Komponenten) implementiert werden kann.
-
Es
ist vorteilhaft, dass die SW-Einheiten eine plattformunabhängige Natur
aufweisen, vorausgesetzt, dass die IMB-Architektur für jede mögliche HW/SW-Implementation ihrer
internen Komponenten und der Frontends offen ist.
-
Es
ist vorteilhaft, dass die Einheiten in einfacher Seite vorsehbar
sind (möglicherweise über ein
Telekommunikationsnetzwerk, z. B. über das Internet) und leicht
umkonfigurierbar sind. Es ist vorteilhaft, dass die Einheiten per
Download über
das Netzwerk installiert oder aktualisiert werden können.
-
Aus
diesen und anderen Gründen
ist die Verwendung der Java-basierten MASE-Middleware als die Zwischenplattform
der Wahl vorteilhaft. Bei einem solchen Kontext sind die oben beschriebenen
Einheiten de facto MASE-Komponenten.
Daher stellt jede Einheit eine API-Spezifikation und ihre Implementierung
zur Verfügung.
-
Die
vorteilhaftesten Unterschiede zwischen der Erfindung und dem Stand
der Technik Verglichen mit dem Stand der Technik ermöglicht diese
Erfindung die Auswahl von mehr als einem Endgerät, indem die Möglichkeit
bereits gestellt wird, einen gesamten Kontext (was bedeutet Frontend-Gruppen
und weitere Benutzerpräferenzen)
auszuwählen.
Der Erweiterungsmechanismus für
das Benutzerprofil, der in
EP
00 104 259.7 beschrieben wurde, erlaubt weiterhin die Möglichkeit,
auf andere Default-Frontend-Gruppen Bezug zu nehmen.
-
Die
Erfindung stellt auch die Möglichkeit
zur Verfügung,
entweder manuell oder automatisch den Heimkontext auszuwählen. In
letztgenanntem Fall kann die Auswahl auf verschiedenen Kriterien
beruhen (das sind Komponenten der zuvor genannten Benutzerprofildatenbank
8-Tupel). Der Benutzer hat die Option, entweder direkt den Kontext
anhand eines solchen Kriteriums auszuwählen oder ein indirektes Schema
zu verwenden, bei dem der gewünschte
Heimkontext als eine Eigenschaft eines Schlüssel-Werte-Paares identifiziert wird,
die in den bestimmten aktuellen 8-Tupel enthalten ist. Der spätere Modus
bietet dem Benutzer die Möglichkeit,
kundenspezifische logische Heimkontexte zu erzeugen, wodurch das
Auswahlkriterium, das durch die 7-Tupel-Komponenten angeboten wird,
erweitert wird.
-
Dadurch
hat der Benutzer die Möglichkeit,
schließlich
mehrere Kontexte als Heimkontexte zu konfigurieren, indem einfach
jeder von Ihnen einer verschiedenen Gruppe von Bedingungen zugeordnet
wird.
-
Weiterhin
sind die Navigationsmechanismen der aktuell verfügbaren COTS-Webbrowser auf Webseiten beschränkt, wobei
diese Erfindung das zugrunde liegende Navigationskonzept für ein effizientes
Abrufen von zwischengespeicherten Datenbankabfrageergebnissen auf
eine Weise ermöglicht,
die die Benutzerprofildatenbankstruktur, die in
EP 00 104 259.7 beschrieben ist,
erweitert.
-
Insbesondere
ist die Historieninformation global verfügbar, wobei diese in dem Default-Profil
des Benutzers gespeichert ist, das von mehreren Frontends und Telekommunikationsnetzwerken
zugreifbar ist.
-
Das
hierin dargestellte Mehrfachheimkonzept kann in existierende Web-Browser eingefügt werden, wodurch
etwaigen Benutzern ermöglicht
wird, entweder manuell (siehe 2) oder
automatisch seine/ihre Heimsite aus der Gruppe von Konfigurierten
auszuwählen.