DE60106721T2

DE60106721T2 - Verwaltung von Ereignisinformationsdaten mit einem mobilen Kommunikationsgerät

Info

Publication number: DE60106721T2
Application number: DE60106721T
Authority: DE
Inventors: Ernö Kovacs; Fritz Hohl
Original assignee: Sony International Europe GmbH
Current assignee: Sony Deutschland GmbH
Priority date: 2001-03-15
Filing date: 2001-03-15
Publication date: 2005-04-28
Anticipated expiration: 2021-03-16
Also published as: DE60106721D1; ES2225331T3; ATE281034T1; EP1241830B1; EP1241830A1

Description

Verwaltung von Ereignisinformationsdaten mit einem mobilen Kommunikationsgerät Die vorliegende Erfindung betrifft ein Verfahren zur Verwaltung von Ereignisinformationsdaten, ein Computersoftwareprogrammprodukt zur Implementierung eines solchen Verfahrens sowie ein mobiles Kommunikationsgerät, das ein Ereignisverwaltungsmodul aufweist.
Aus dem Stand der Technik sind verschiedene Systeme bekannt, die Veranstaltungen bzw. Ereignisse entsprechend dem Benutzerprofil und dem laufenden Datum filtern, beispielsweise durch Verwendung von Personal- bzw. Softwareagenten. Außerdem sind viele statische Listen oder Ereignisse beispielsweise im Internet vorhanden. Überdies gibt es Systeme, die es erlauben, Ereignismitteilungen und -erinnerungen an spezifische Benutzergruppen zu senden. Schließlich erlauben Kalendersysteme, Ereignisse einzugeben, Ereignisse zu organisieren, sowie Ereignisse wiederzugewinnen.
Jedoch leiden alle bekannten Systeme an mehreren verschiedenen Nachteilen. Beispielsweise wird weder der Ortsaspekt eines Ereignisses noch der Zeitaspekt zum Reisen bzw. Fahren bzw. Bewegen zum Ort eines Ereignisse in Betracht gezogen.
Hinsichtlich dieser Nachteile ist die Aufgabe der vorliegenden Erfindung, eine Technik vorzuschlagen, die eine korrelierte Zeit- und Positionsverwaltung einer Veranstaltungs- bzw. Ereignisinformation erlaubt.
WO 97/41654 offenbart ein Telekommunikations- und Informationsweitverbreitungssystem zu einer Weiterverbreitung von Information zu Teilnehmen eines mobilen Telekommunikationsnetz werks bzw. -netzes von wenigstens einer Informationsquelle, die Daten enthält, welche kontinuierlich oder in Intervallen aktualisiert werden.
WO 98/08314 zeigt ein Verfahren und Gerät zur Bereitstellung positionsbezogener Information mobilen Empfängern.
Diese Aufgabe wird mittels der Merkmale der unabhängigen Ansprüche gelöst. Die abhängigen Ansprüche entwickeln die zentrale Idee der vorliegenden Erfindung weiter.
Gemäß einem ersten Aspekt der vorliegenden Erfindung ist deshalb ein Verfahren zur Verwaltung von Veranstaltungs- bzw. Ereignisinformationsdaten vorgeschlagen. Die laufende Zeit in der Position eines mobilen Kommunikationsgeräts wird abgefragt. Die laufende Zeit in der Positionsinformation zum Erzeugen einer Schablone verwendend wird eine Veranstaltungs- bzw. Ereignisquelle wie beispielsweise eine Ereignisdatenbank abgefragt. Die Ereignisquelle enthält Ereigniseinträge bzw. – eingaben, die durch die Kategorie, Zeit und Ort parameterisiert sind. Schließlich wird eine Liste von zugreifbaren Veranstaltungen bzw. zugreifbaren Ereignissen auf dem mobilen Kommunikationsgerät präsentiert, worin die Liste aus zugreifbaren Ereignissen mittels der Abfrage erzeugt wird. Die zugreifbaren Ereignisse werden berechnet, indem die Differenzen zwischen der Startzeit und dem Ort eines Ereignisses und der laufenden Zeit und der Position des mobilen Kommunikationsgeräts berücksichtigt werden.
Wahlweise kann Profilinformation über den Benutzer des mobilen Kommunikationsgeräts Teil der für die Abfrage der Ereignisquelle verwendeten Schablone sein.
Wenigstens für einzelne bzw. besondere bzw. gesonderte der zugreifbaren Ereignisse kann eine Transportationsinformation für mögliche Wege, um von der laufenden Position des mobilen Kommunikationsgeräts zu einem Veranstaltungs- bzw. Ereigni sort zu kommen, berechnet und auf dem mobilen Kommunikationsgerät präsentiert werden.
Die Liste von zugreifbaren Ereignissen kann dynamisch präsentiert werden. In anderen Worten kann die Liste von zugreifbaren Ereignissen aktualisiert werden, um eine Liste von verbleibenden zugreifbaren Ereignissen jedesmal zu erzeugen, wenn der Benutzer des mobilen Kommunikationsgeräts ein Ereignis der Liste akzeptiert. Beim Erzeugen der aktualisierten Version der Ereignisliste werden die Parameter (Zeit, Ort usw.) von vom Benutzer schon akzeptierten Ereignissen berücksichtigt.
Vom Benutzer des mobilen Kommunikationsgeräts akzeptierte zugreifbare Ereignisse können als Eingaben in eine elektronische Kalenderdatei automatisch übertragen werden.
Der Benutzer des mobilen Kommunikationsgeräts kann Veranstaltungen bzw. Ereignisse für die Liste zugreifbarer Ereignisse und/oder für die Ereignisquelle (beispielsweise Ereignisdatenbank) erzeugen.
Dies kann beispielsweise durch manuelles Erzeugen von Ereignissen durch kundenspezifische Anpassung von vom mobilen Kommunikationsgerät vorgeschlagenen generischen Ereignissen erzielt werden.
Es kann ein Lernmodus bereitgestellt werden, in welchem das mobile Kommunikationsgerät Ereignispräferenzen des Benutzers durch Auswertung der Interaktion mit dem Benutzer lernt.
Der Benutzer kann Rangordnungen bzw. stehende Ordnungen für Ereignisse derart vorkonfigurieren, dass korrespondierende Ereignisse automatisch gewählt werden, wenn sie in der Ereignisquelle wiedergewonnen werden.
Die Ereigniseingaben der Ereignisquelle können durch Durchsuchen eines Netzwerks bzw. Netzes wie beispielsweie des Internets automatisch erzeugt werden.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung ist ein Computersoftwareprogrammprodukt vorgeschlagen, das ein Verfahren wie das obige implementiert, wenn es auf einem mobilen Berechnungsgerät läuft.
Gemäß einem noch weiteren Aspekt der vorliegenden Erfindung ist ein Kommunikationsgerät mit einem Veranstaltungs- bzw. Ereignisverwaltungsmodul vorgeschlagen. Das Ereignisverwaltungsmodul weist eine Einrichtung zur Bestimmung der tatsächlichen Zeit und der laufenden geographischen Position des mobilen Kommunikationsgeräts auf. Außerdem sind eine Einrichtung zur Abfrage einer internen und/oder externen Ereignisquelle vorhanden. Die Ereignisquelle enthält Ereigniseingaben, die durch Kategorie, Zeit und Ort parameterisiert sind. Eine Abfrage kann auf der Basis einer Schablone, die wenigstens die laufende Zeit und die geographische Position des mobilen Kommunikationsgeräts enthält, ausgeführt werden. Schließlich sind Mittel zum Präsentieren einer Liste von zugreifbaren Ereignissen, die von der Abfrageinrichtung ausgegeben werden, vorgesehen.
Die von der Abfrageinrichtung verwendete Schablone kann außerdem Profilinformation des Benutzers des mobilen Kommunikationsgeräts aufweisen.
Außerdem kann das mobile Kommunikationsgerät ein Navigationsmodul zur Berechnung und Präsentierung möglicher Wege, um von der laufenden Position des mobilen Kommunikationsgeräts zum Ort eines Ereignisses zu gelangen, aufweisen.
Eine Berechnungseinrichtung kann die Liste von zugreifbaren Ereignissen dynamisch aktualisieren, um eine Liste verbleibender zugreifbarer Ereignisse jedesmal, wenn der Benutzer des mobilen Kommunikationsgeräts ein vorgeschlagenes Ereignis von der Liste akzeptiert, zu erzeugen.
Schließlich können Mittel zur automatischen Übertragung von vom Benutzer des mobilen Kommunikationsgeräts akzeptierten zugreifbaren Ereignissen als Eingaben in eine elektronische Kalenderdatei vorhanden sein.
Weitere Vorteile, Merkmale, Eigenschaften und Aufgaben der vorliegenden Erfindung werden dem Fachmann beim Lesen der folgenden detaillierten Beschreibung einer Ausführungsform anhand der Figuren der beigefügten Zeichnungen evident.
1 zeigt eine schematische Darstellung eines Systems der Implementierung der vorliegenden Erfindung.
2 zeigt schematisch die Anpassung bzw. Adaption von Ereignissen und
3 zeigt schematisch eine mögliche Verteilungsstruktur zur Implementierung der vorliegenden Erfindung.
In Bezug auf 1 wird ein erstes System zur Implementierung der vorliegenden Erfindung erläutert.
Zu diesem Zweck werden zuerst einige Begriffe und Ausdrücke erläutert. Eine „Veranstaltung" bzw. ein „Ereignis" im Sinne der vorliegenden Erfindung ist eine soziale bzw. gesellige Ansammlung oder Aktivität, die üblicherweise eine gewisse Startzeit, eine Zeitdauer und deshalb auch eine Endezeit aufweist. Im Gegensatz zu Zusammenkünften ist oft nicht die Zusammenkunft mit anderen Leuten wichtig, sondern der Zweck des Ereignisses, der gewisse Resourcen (beispielsweise ein Filmprojektor, ein gewisser Ort usw.) erfordert, die nur an gewissen Plätzen verfügbar sind. Deshalb ereignet sich eine Veranstaltung bzw. ein Ereignis an einem gewissen Ort. Ein Benutzer muss vom derzeitigen bzw. laufenden Ort zu diesem Ort kommen, was üblicherweise eine gewisse Zeit in Anspruch nimmt. Außerdem sind möglicherweise Ressourcen wie Transportationsmittel notwendig. Veranstaltungen bzw. Events bzw. Ereignisse werden von einer gewissen Zahl Leute besucht. Ereignisse können als eine Struktur wie:
Ereigniszweck, Ort, Datum, Startzeit, Dauer, Teilnehmer, beschrieben werden.
Eine "Schablone" ist eine Ereignisspezifikation, die aus einer Zahl spezifizierter Attribute besteht. Ein Beispiel einer Schablone ist:
"Filmvorführung", Hedelfinger-Str. 61 + 5km, 24.10.00, 18:00 GMT.
Eine "Abfrage" ist eine Aufgabe zum gleichzeitigen Wählen, das heißt während der Benutzer auf das Resultat wartet.
„Rangordnung" bzw. "stehende Ordnung" ist eine Aufgabe zum Wählen von Ereignissen zum Informieren des Benutzers über das Auftreten dieser Ereignisse als synchron, das heißt während der Benutzer vom System getrennt ist.
Nun werden die Komponenten eines Systems zum Implementieren der vorliegenden Erfindung anhand 1 erläutert.
Ein Abfrageverwaltungsmodul 12 verwaltet die Abfragen und Rangordnungen bzw. stehenden Ordnungen von Benutzern. Im Fall einer Abfrage empfängt das Abfrageverwaltungsmodul diese Aufgabe von einem Präsentationsadaptions- und Interaktionsmodul (PIAM) 6, frägt das Ereignissammlungsmodul 9 nach Ereignissen ab, die in die Schablone der Aufgabe passen, und sendet diese Ereignisse zu einem Selektions- und Ordnungsmodul 10. Nachdem es die Resultate aus dem Selektions- und Ordnungsmodul 10 empfangen hat, leitet das Abfragverwaltungsmodul 12 sie zum PIAM 6 zur Anzeige auf einem mobilen Kommunikationsgerät wei ter. Um einige bzw. gewisse Interaktionsschritte zu ermöglichen, speichert das Abfragverwaltungsmodul 12 alle die Abfrage betreffenden Daten, um auf die Interaktionen des Benutzers zu reagieren. Es gibt zwei mögliche Interaktionsschritte.
Wenn ein Benutzer vom System vorgeschlagene Ereignisse akzeptiert, werden diese Ereignisse in das Kalendermodul 5 eingegeben, und die Abfrage wird durch erneutes Senden der Ereignisse zum Selektions- und Ordnungsmodul 10 wieder verarbeitet. Da es nun Zeiteinschränkungen gibt, kann das vom Selektions- und Ordnungsmodul 10 zum Abfrageverwaltungsmodul 12 zurückgebrachte Resultat vom ersten Schritt differieren. Wenn ein Benutzer ein Ereignis im Kalendermodul 5 entfernt (aufgibt), wird das Abfrageverwaltungsmodul 12 benachrichtigt, und die Abfrage wird wieder verarbeitet, um wieder neue Resultat zu erzeugen, die vom Selektions- und Ordnungsmodul 10 zum Abfrageverwaltungsmodul 12 zurückgebracht werden.
Im Fall einer stehenden Ordnung empfängt das Abfragverwaltungsmodul 12 diese Aufgabe vom PIAM 6. Es frägt das Ereignissammlungsmodul 9 ab, um das Abfragverwaltungsmodul 12 im Fall des Auftretens von in die Schablone passenden Ereignisses zu informieren. Die Verarbeitung dieser Aufgabe wird dann gestoppt, jedoch werden alle die Aufgabe betreffenden Daten im Abfragverwaltungsmodul 12 gespeichert. Sobald das Ereignissammlungsmodul 9 das Abfragemanagementmodul 12 über das Auftreten korrespondierender Ereignisse unterrichtet, sendet das Abfragverwaltungsmodul 12 die Ereignisse zum Selektions- und Ordnungsmodul 10, das seinerseits das Resultat empfängt, das eine Liste zugreifbarer Ereignisse ist. Das Abfrageverwaltungsmodul 12 frägt das Präsentationsadaptions- und Interaktionsmodul (PIAM) 6 ab, um den Benutzer unter Verwendung der vom Benutzer gewählten Mittel bzw. Bedeutung über das Resultat zu informieren.
Schließlich leitet das Abfrageverwaltungsmodul 12 Ansichtsselektionsinformation vom PIAM 6 zum Kontextverwaltungsmodul 7 weiter, wenn es passt.
Im Folgenden wird die Funktion des Ereignissammlungsmoduls 9 erläutert. Diese Komponente sammelt Ereignisse und gibt Sätze von Ereignissen ab, die zu einer gegebenen Schablone passen. Es gibt für das Ereignissammlungsmodul 9 mehrere Möglichkeiten, um Ereignisse zu sammeln. Eine ist, nach geeigneten Informationsquellen zu suchen, wenn Ereignisse benötigt werden, beispielsweise durch Verwendung einer Suchmaschine im Internet 3 durch Konsultieren von Ereigniswebseiten im Internet 3. Eine andere Möglichkeit ist, geeignete Ereignisquellen derart zu abonnieren, dass das Ereignissammlungsmodul 9 über das Auftreten neuer Ereignisse informiert wird. Um auf Abfragen schnell zu reagieren, kann das Ereignissammlungsmodul 9 Suchinformationsquellen (Internet 3 usw.) auch, ohne schon Aufgaben zu kennen, voraktivieren. Dazu kann es eine eigene Ereignisdatenbank 17 zum Speichern von Ereignissen verwenden. Um dritten Teilnehmern zu ermöglichen, Ereignisse manuell direkt einzusetzen, kann das Ereignissammlungsmodul 9 eine Manuelleingabeschnittstelle 14 offerieren, um dies zu tun.
Im Fall einer Abfrage empfängt das Ereignissammlungsmodul 9 eine Schablone vom Abfrageverwaltungsmodul 12 und antwortet ihm durch Zurückbringen einer Liste von akzeptierbaren Ereignissen, die in die Schablone passen. Im Fall einer stehenden Ordnung empfängt das Ereignissammlungsmodul 9 eine Schablone vom Abfrageverwaltungsmodul 12. Sobald das Ereignissammlungsmodul 9 ein Ereignis findet, das in die Schablone passt, informiert es das Abfragverwaltungsmodul 12 durch Zurückbringen einer Liste von Ereignissen, die in die Schablone passen.
Um diese Aufgabe zu erfüllen, kann das Ereignissammlungsmodul 9 auf eine Ortsdatenbank 8 zugreifen, um den Ort und den Abstand zu den wiedergewonnenen Ereignissen zu bestimmen. Nach Zugriff auf die Ortsdatenbank 8 wird jede Ortseingabe in ein Ereignis um die geographische Position des Orts erweitert. Deshalb kann die geographische Position beispielsweise zusammen mit der Ereigniseingabe in der Ereignisdatenbank 17 ge speichert werden. Die Ortsdatenbank 8 kann Positionen symbolischen (logischen) Ortsdaten, wie sie in den Ereignissen vorgesehen sind, zuordnen. Eine solche Zuordnung kann beispielsweise sein:
"Gloria 1" = 34,00078 N, 4,8901 W 134,3 Meter).
Der erste Strang bzw. die erste (Zeichen-)Kette bezeichnet den symbolischen (logischen) Namen. Der zweite Teil enthält die graphische Position, beispielsweise im WGS 84-Format. Symbolische (logische) Namen können Namen, ein Ort ist unter ("Münchner Hofbräuhaus") bekannt, eine Adresse ("Hedelfingerstr. 61") und andere Bezugnahmen auf Orte enthalten. Symbolische (logische) Namen werden vom Ereignissammlungsmodul 9 abgegeben. Die Ortsdatenbank 8 antwortet auf eine solche Anfrage mit der korrespondierenden geographischen Position.
Nun werden die Funktion und Operation des Selektions- und Ordnungsmoduls (SOM) 10 erläutert. Diese Komponente bekommt einen Satz von Ereignissen vom Abfrageverwaltungsmodus 12 und wählt und ordnet Ereignisse davon zu einem Satz von Attributen. Es antwortet dem Abfrageverwaltungsmodul 12 durch zurückbringen einer geordneten Liste von Ereignissen. Der Satz von Attributen wird vom Kontextverwaltungsmodul 7 angefordert. Er besteht aus einem offenen Satz von Daten wie:

– Benutzerpräferenz wie – Ereigniskategorien, – Schlüsselwörter, – Namen bevorzugter Teilnehmer (und ihrer Rollen), – bevorzugte Orte,
– offene Zeit/Orts-Schlitze.

Um den Zeitabstand von und den Weg zu Ereignissen zu bestimmen, kann das Selektions- und Ordnungsmodul 10 auf das Navigationsmodul 11 zugreifen. Es fordert diese Daten durch Abgabe eines Starts in einen Zielort eines möglichen Transportmittels an.
Eine Beschreibung des Wegs und eine Abschätzung der benötigten Zeit wird vom Navigationsmodul 7 zurückgebracht.
Das Navigationsmodul 11 ist mit einer Positionsbestimmungseinrichtung wie beispielsweise eines GPS verbunden. Die Positionsbestimmungseinrichtung 15 kann außerdem mit dem Abfrageverwaltungsmodul 12 verbunden sein. Das Navigationsmodul 11 kann einen Pfad, um von einem Ort zu einem anderen zu gehen, berechnen, was in einer Beschreibung des Weges und der notwendigen Zeit, die als ein Satz möglicher Transportmittel gegeben sind, resultiert.
Das Kontextverwaltungsmodul 7 bzw. 11 sammelt und speichert Kontextdaten und gibt sie an das SOM 10, um den Selektions- und Ordnungsprozess zu konfigurieren, und an das PIAM 6 ab, um den Präsentationsadaptions- und Interaktionsprozess zu konfigurieren. Kontextdaten können enthalten:

– den Ort des Benutzers
– Daten und Zeit am Ort des Benutzers,
– die Temperatur am Ort des Benutzers,
– personelle Benutzerdaten wie seine/ihre Schablone,
– die Historie seines/ihrer Dienstbenutzung,
– die tatsächliche Bedingung des Netzwerks, mit dem der Benutzer verbindet,
– die tatsächliche Bedingung des Benutzergeräts,
– das Benutzerprofil (beispielsweise Alter, Geschlecht, Nationalität und Benutzerpräferenzen),
– die Fähigkeit des Benutzergeräts,
– die soziale Situation, die der Benutzer laufend bzw. derzeit erfährt.

Teile dieser Daten werden vom KM 5 gesammelt.
Wenn im "Lernmodus", so versucht der KVM 7 Benutzerprofilinformation automatisch durch Prüfen der Interaktionen des Be nutzers mit dem Dienst (siehe G in 1) und, wenn möglich, auch durch Beobachten einer anderen Internetbenutzung dieses Benutzers außerhalb des Dienstes zu sammeln. Diese Information wird wieder im KVM 7 gespeichert.
Um Benutzern zu erlauben, verschiedene Sätze von Kontextdaten zu benutzen (beispielsweise um verschiedene Präferenzen gemäß dem Modus (Geschäftsreise oder Ferienreise) zu haben), können Kontextdatensätze in verschiedene "Ansichten" organisiert werden. Der Benutzer kann diese Ansichten unter Verwendung des PIAM 6 (welches das AVM 12 informiert, das schließlich das KVM 7 über die laufend gewählte Anwendung informiert) wählen. Bei Abgabe von Kontextinformation wird die laufend gewählte Ansicht verwendet.
Das Präsentationsadaptions- und Interaktionsmodul PIAM 6 präsentiert die Resultate von Abfragen und einer stehenden Ordnung einem Benutzer. Diese Präsentation wird entsprechend Kontextdaten angepasst, wie:

– Typ der verwendeten Geräts,
– die tatsächliche Bedingung des Netzwerks,
– und so weiter.

Zusätzlich erlaubt das PIAM 6 dem Benutzer die folgenden Dinge zu tun:

– Eingabe einer neuen Anforderung. Der Benutzer kann alle relevanten Attribute und Präsentationsmoden (beispielsweise Sortierung betreffend usw.) spezifizieren. Dies resultiert in einer Abfrage, die zum AVM 12 gesendet wird.
– Eingabe einer neuen stehenden Ordnung. Der Benutzer kann alle relevanten Attribute spezifizieren. Dies resultiert in einer Abfrage, die zum AVM 12 gesendet wird.
– Modifizieren einer stehenden Ordnung. Dies wird durch Abfragen einer stehenden Ordnung aus dem AVM 12 ausgeführt und lässt sie den Benutzer modifizieren. Die stehende Ordnung wird dann zum AVM 12 zurückgesendet.
– Beobachten der Resultate von Anfragen oder stehenden Ordnungen.
– Akzeptieren eines Ereignisses einer Ereignisliste. Im Fall einer Akzeptanz wird das Ereignis in den KM 5 eingegeben, dann wird der AVM 12 benachrichtigt, um die neuen Zeit/Orts-Einschränkungen, die aus dieser Wahl resultieren, in Betracht zieht.
– Wählen einer Ansicht
– Wählen eines Mitteilungsmittels.

Zusätzlich kann das PIAM 6 Notifikationen bzw. Mitteilungen senden, um Benutzer offline bzw. abgetrennt zu machen, wenn das System ein Ereignis detektierte, das in eine stehende Ordnung passt.
Das Kalendermodul 5 präsentiert dem Benutzer eine kalenderähnliche Präsentation. Ereignisse, die der Benutzer akzeptiert hat, werden in diesen Kalender eingegeben. Im Fall beispielsweise einer Sinnesänderung oder wenn Alternativen entdeckt werden, kann der Benutzer auch akzeptierte Ereignisse im Kalender aufgeben. In diesem Fall wird das Abfrageverwaltungsmodul informiert. Zur Integration in eine existierende Amts- bzw. Büroumgebung kann das Kalendermodul ein existierendes Produkt (beispielsweise Microsoft Outlook) sein, solange andere Programme Ereignisse eingeben können und solange andere Programme die Entfernung von Ereignissen im Kalender abfühlen können.
Außerdem ist der Kalender eine Informationsquelle für das Kontextverwaltungssystem.
Flüsse innerhalb des Systems
Eine Abfrage wird verarbeitet
Der Benutzer startet einen Abfrageprozess beim PIAM 6. Der Benutzer gibt eine Abfrage beim PIAM 6 ein, spezifiziert so beispielsweise das Datum, die Zeit und den Ort der zu bekommenden Ereignisse. Das PIAM 6 erzeugt daraus eine Schablone und sendet sie zusammen mit anderen Daten (beispielsweise Präsentationsoptionen und die Ansicht zur Verwendung) zum AVM 12. Das AVM 12 erzeugt eine Abfrageeingabe und speichert sie. Danach sendet es die Schablone zum ESM 9. Das ESM 9 sammelt Ereignisse, die in diese Schablone passen, beispielsweise durch Verwendung seiner internen Datenbank. Es verwendet auch die OD 8, um zu bestimmen, ob ein Ereignis in die Schablone passt. Schließlich erweitert es die Ereignisse, die in die Schablone passen mit den von der OD 8 gesammelten geographischen Positionen. Dieser Satz von Ereignissen wird zum AVM 12 zurückgebracht, wo er in der Abfrageingabe gespeichert wird. Das AVM 12 sendet diesen Satz zum SOM 10. Das SOM 10 wendet seinen Selektions- und Ordnungsalgorithmus unter Verwendung der im KVM 7 gesammelten Daten an. Um zu bestimmen, in welcher Zeit Ereignisse erreicht werden können, verwendet das SOM 10 das NM 11, das auch eine Beschreibung der Wege zum Erreichen des Ereignisses abgibt. Diese Beschreibung erweitert auch die Ereignisse. Das SOM 10 gibt dann eine geordnete Liste von Ereignissen zum AVM 12 zurück. Das AVM 12 sendet diese Liste zum PIAM 6, wo sie dem Benutzer durch Anwendung der Präsentationsadaptionsmechanismen unter Verwendung von Kontextdaten aus dem KVM 7 präsentiert wird.
Der Benutzer kann nun Ereignisse aus dieser Liste akzeptieren oder Ereignisse in den Kalender entfernen.
Nachdem er die Abfrage beendet hat, stoppt der Benutzer den Abfrageprozess.
Der Benutzer akzeptiert ein Ereignis
Wenn der Benutzer ein Ereignis im PIAM 6 akzeptiert, wird das Ereignis zum KM 5 gesendet, wo es in den Kalender dieses Benutzers eingegeben wird. Zusätzlich sendet das PIAM 6 die Akzeptanzmitteilung zum AVM 12, das seinerseits den Selektions- und Ordnungsprozess durch Senden dem SOM 10 den vorher vom ESM 9 empfangene Satz von Ereignissen, aber wo das akzeptierte Ereignis entfernt worden ist, startet. Da das akzeptierte Ereignis die Zeit/Orts-Verfügbarkeit des Benutzers weiter einschränkt, kann eine andere Liste von Ereignissen aus diesem Prozess resultieren (das SOM 10 kennt diese Einschränkung, wenn es diese Kontextdaten vom KVM 7, das seinerseits das CM 5 abfrägt, empfängt). Wie oben wird die neue Liste von Ereignissen dem Benutzer präsentiert, und der Benutzer kann wieder ein Ereignis akzeptieren.
Der Benutzer gibt ein Ereignis auf
Ereignisse im KM 5 (das heißt akzeptierte Ereignisse) kann der Benutzer jederzeit aufgeben. In diesem Fall wird das Ereignis durch das KM 5 aus dem Benutzerkalender entfernt. Wenn laufend keine Abfrage verarbeitet wird, werden keine weiteren Schritte ausgeführt. Wenn laufend eine Abfrage verarbeitet und das aufgegebene Ereignis eines ist, das aus dieser Abfrage herstammte, wird dieses Ereignis zum AVM 12 gesendet und der ganze Abfrageprozess wird neu gestartet. Der einzige Unterschied ist, dass das Ereignis wieder zu dem beim AVM 12 gespeicherten Ereignissatz hinzugefügt wird. Wenn laufend eine Abfrage verarbeitet wird und die verzichteten Ereignisse nicht aus diesem Abfrageprozess herrühren, wird der komplette Abfrageprozess vom AVM 12 wieder gestartet, das heißt, es wird auch das ESM 9 nach Ereignissen abgefragt, die in die Abfrageschablone passen.
Eine stehende Ordnung wird eingegeben
Der Benutzer spezifiziert beim PIAM 6 eine stehende Ordnung auf ähnliche Weise, wie er/sie eine Abfrage spezifiziert, mit dem einzigen Unterschied, dass auch das Kommunikationsmittel spezifiziert wird, das zum Informieren des Benutzers über das Auftreten eines korrespondierenden Ereignisses benutzt werden soll. Das PIAM 6 sendet dann diese stehende Ordnung zum AVM 12, wo eine Stehendordnungseingabe erzeugt wird. Schließlich sendet das AVM 12 die korrespondierende Schablone zum ESM 9.
Eine stehende Ordnung wird verarbeitet
Wenn das ESM 9 ein oder mehrere Ereignisse findet, die in die Schablone der stehenden Ordnung passen (unter Verwendung der OD 8 in der gleichen Weise wie bei den Abfragen), sendet es diese Ereignisse zum AVM 12, wobei die stehende Ordnung, zu denen sie gehören, spezifiziert wird. Das AVM 12 startet dann den Selektions- und Ordnungsprozess in der gleichen Weise wie im Abfrageprozess. Wenn das AVM 12 die Ereignisliste zum ESM 9 sendet, addiert es auch die vom Benutzer gewählte Kommunikationsmittelspezifikation. Schließlich wird der Benutzer über die Ereignisliste unter Verwendung der vom ESM 9 gewählten Kommunikationsmittel unterrichtet. Der Benutzer kann dann mit dem System verbunden werden und in der gleichen Weise wie während einer Abfrage interagieren (das heißt Ereignisse akzeptieren oder aufgeben).
Im Folgenden werden Datenstrukturen für das System erläutert.
Eine einzelne Datenstruktur ist das Ereignis bzw. die Ereignisschablone, wie bzw. da sie bestimmen, welche Arten von Ereignissen gefunden werden können. Wie oben beschrieben bestehen Ereignisse hauptsächlich aus sechs Elementen, nämlich:

– Ereigniszweck,
– Ort,
– Datum,
– Startzeit,
– Dauer,
– Liste von Teilnehmern,

8

Ereignisschablonen haben Wahrscheinlichkeiten bzw. Möglichkeiten zum Spezifizieren dieser Elemente in einer Fuzzy-Weise zu offerieren. Pro Element enthalten diese Möglichkeiten abgesehen davon, dass ein Element unspezifiziert belassen wird (durch "*" gekennzeichnet):

Ereigniszweck Hier ist das Problem, dass wir generelle und mehr spezialisierte Kategorien wie "Performance (Vor- bzw. Aufführung)" – "Oper" haben. Deshalb benötigen wir etwas wie einen Baum von Kategorien, so dass ein Ereignis durch Kategorien höheren Niveaus beschrieben werden können. Zusätzlich sollten einige Zwecke durch mehrere Kategorien beschrieben werden, deshalb benötigen wir eine Liste von Kategorien, die ein Ereignis beschreiben. Es ist offensichtlich, dass wir Parameter für dieses Element benötigen, beispielsweise zum Spezifizieren eines gewissen Films (wie "Casablanca").
Ort Dieses Element enthält die graphische Position des Ereignisses. Zusätzlich kann dieses Element ein "threshold:x"-Attribut („Schwelle:x"-Attribut) enthalten, das den Bereich von x Metern um diese Daten von Ereignissen, die in eine Schablone passen, spezifiziert.
Datum Dieses Element enthält das Datum des Ereignisses. Zusätzlich kann dieses Element ein „threshold:x-Attribut ("Schwelle:x"-Attribut) enthalten, das den Bereich von x Tagen um dieses Datum für Ereignisse, die in diese Schablone passen, spezifiziert.
Startzeit Dieses Element enthält die Startzeit von Ereignissen. Sicherheitshalber wird auch die Zeitzone dieser Zeit codiert, um Fehlberechnungen zu verhindern. Zusätzlich kann dieses Element ein „threshold:x-Attribut ("Schwelle:x"-Attribut) enthalten, das den Bereich von x Sekunden um diese Daten von Ereignissen, die in diese Schablone passen, spezifiziert.
Dauer Dieses Element enthält eine Dauer, beispielsweise in Minuten. Zusätzlich kann dieses Element ein „threshold:x-Attribut ("Schwelle:x"-Attribut) enthalten, das den Bereich von x Sekunden um diese Daten für Ereignisse, die in diese Schablone passen, spezifiziert.
Liste von Teilnehmern Dieses Element enthält Referenzen zu Personen.
Ordnen Jedes der obigen Elemente kann zusätzlich ein "ordering:n"-Attribut („Ordnung:n"-Attribut) enthalten, das angibt, dass dieses Element auch zum Ordnen des Ereignissatzes benutzt werden soll. Der Parameter n dieser Attribute bezeichnet die Reihe bzw. den Rang des Ordnungselements.

Beispiele von Ereignisschablonen
Was ist jetzt und hier zu tun?

(Ereigniszweck = *;
Ort = ORDER (Ordnung) : 1,34.7894N.85993W.374m, threshold:10 000 m;
Datum = 19.10.00;
Start = ORDER:2,13:41MET,threshold:3600s;
Dauer = ORDER:3,*;
Liste von Teilnehmern = *)

Planen eines Ausgehtages in Paris

(Ereigniszweck = *;
Ort = ORDER:1,17.7894N.81.993W.374m,threshold:10 000 m; //war "Paris, Boulevard Saint Germain"
Datum = 15.11.00
Start = ORDNER:2,8:00MET, threshold:36000 s;
Dauer = ORNDER:3, *;
Liste von Teilnehmern = *)

Ein wahrer Fan

(Ereigniszweck = Musikaufführung von "The Jellybabies";
Ort = ORDER:1,34.7894N, 85.933W.374m, threshold:50 000 m;
Datum = *;
Start = *;
Dauer = *;
Liste von Teilnehmern = *)

Spezifikation von Abfragen und stehenden Ordnungen
Der leichteste Weg zum Implementieren dieses Aspektes ist sicherlich, dem Benutzer eine Schnittstelle zu offerieren, wo er/sie jedes einzelne Element mit all den gegebenen Möglichkeiten spezifizieren kann. Unglücklicherweise würde dies die Kenntnis, wie diese Dinge zu spezifizieren sind, erfordern.
Deshalb ist diese Möglichkeit nur für Expertenbenutzer geeignet. Außerdem offerieren speziell mobile Geräte wie Mobiltelefone normalerweise nur sehr eingeschränkte Eingabemöglichkeiten (da sie selten eine Tastatur enthalten und nur kleine Displays haben).
Normale Benutzer oder Benutzer, die diese Gerätetypen benutzen, können eine eingeschränkte Schnittstelle verwenden, die es erlaubt, nur einige wenige Möglichkeiten zu wählen. Eine dieser Möglichkeiten ist, der "Was ist jetzt und hier zu tun"-Modus, bei dem das System eine wie oben beschriebene Schablone unter Verwendung der laufenden Zeit und des Ortes, die vom KVM (das seinerseits diese Information am Benutzergerät abgefühlt haben kann) genommen werden, erzeugt.
Der einfachste Weg mit dem System zu interagieren, ist, aktive Vermutungen auf der Basis implizit gesammelter Profile zu erlauben, da dann der Benutzer Abfragen oder Präferenzen nicht weiter spezifizieren muss. Eine andere Möglichkeit dem Benutzer beim Spezifizieren von Abfragen und stehenden Ordnungen zu helfen, ist, Vorabwerte, die auch im KVM gespeichert sind, zu benutzen.
Sammeln von Ereignissen:
Ereignisse können über manuelle Eingabe direkt eingegeben werden. In diesem Fall kann alle relevante Information leicht unter Verwendung einer geeigneten Form gesammlt werden.
Ereignisse können auch durch Durchsuchen geeigneter Informationsquellen wie beispielsweise Webseiten, e-Mails (wenn dies unter Geheimhaltungsaspekten möglich ist) und Datenbanken gesammelt werden. Speziell im Web gibt es viele Seiten, die Ereignisdaten in menschlich lesbarer Form offerieren, beispielsweise http://www.Stuttgart.de/sixcms/list.php3?pageid=25. Es gibt auch einige Datenbanken im Internet, beispielsweise http://www.lift-online.com/cgi/setkalender.pl, wo Ereignisdaten automatisch abgefragt werden können. Da es keinen Stan dard zum Offerieren solcher Daten gibt, und da die Zuhörerschaft von Ereignisdaten normalerweise eine menschliche ist, bieten die meisten Informationsquellen ein eigenes Ereignisdatenformat an, das oft für menschlichen Gebrauch geeignet ist. Deshalb muss eine Architektur, die diese Informationsquellen benutzen will, den verschiedenen Formaten begegnen, die auch der Gegenstand häufiger, unangekündigter Änderungen sein können. Das ESM 9 hat dann einfach das Ereignisdatenformat der Informationsquellen in ein im System benutztes zu übersetzen.
In naher Zukunft können solche Ereignisse auf Quellen wie Webserver als XML-Dokumente offeriert werden. In diesem Fall muss das ESM die korrespondierenden DTDs kennen und verstehen.
Ereignisse werden in einer Ereignisdatenbank 17 innerhalb oder außerhalb des ESM 9 gespeichert, beispielsweise in XML-Form, um auf Abfragen durch das AVM 12 schnell zu reagieren.
Bekommen von Ereignissen aus dem ESM
Um einen Satz von Ereignissen, die in eine gegebene Ereignisschablone passen, zurückzubringen, muss das ESM 12 bzw. 9 alle Element einer Ereignisschablone in Betracht ziehen. Damit ein Element qualifiziert ist, im Ereignissatz enthalten zu sein, müssen sich alle seine Elemente qualifizieren. Ein Element ist qualifiziert, wenn es nicht spezifiziert ist ("*"). Ob ein spezifiziertes Element qualifiziert ist, hängt vom Element ab:

Ereigniszweck Dieses Element ist qualifiziert, wenn die spezifizierte Kategorie ein Vorgänger in einer der Kategoriehierarchien des Ereignisses ist, und wenn die Parameter, wenn spezifiziert, gleich sind.
Ort Dieses Element ist qualifiziert, wenn der geographische Ort des Ereignisses (wie er durch die OD 8 bestimmt ist) in dem durch die Ereignisschablone spezifizierten Bereich liegt.
Datum Dieses Element ist qualifiziert, wenn das Datum des Ereignisses in dem durch die Ereignisschablone spezifizierten Bereich liegt.
Startzeit Dieses Element ist qualifiziert, wenn das Datum des Ereignisses in dem durch die Ereignisschablone spezifizierten Bereich liegt.
Dauer Dieses Ereignis ist qualifiziert, wenn das Datum des Ereignisses in dem durch die Ereignisschablone spezifizierten Bereich liegt.
Liste von Teilnehmern Dieses Element ist qualifiziert, wenn die Liste von in der Ereignisschablone spezifizierten Personen in der Liste von Teilnehmern eines Ereignisses enthalten ist.

Selektions- und Ordnungsalgorithmus
Der Selektions- und Ordnenalgorithmus ist ein Zweistufenprozess. In der ersten Stufe werden Ereignisse aus dem hereinkommenden Ereignissatz entsprechend gewisser, vom KVM empfangener Kriterien durch eine vom Benutzer gewählte Ansicht bestimmt. Eines dieser Kriterien ist der Kalender der Benutzer: Es werden nur Ereignisse gewählt, die nicht mit existierenden Eingaben kollidieren. Ein anderes Kriterium ist die Zeit, die zum Erreichen des Ortes eines Ereignisses benötigt wird. Vom NM 11 berechnet, wird dieses Zeiterfordernis in Betracht gezogen, wenn Ereignisse gewählt werden, die in den Zeitbereich der Ereignisschablone passen.
In der zweiten Stufe werden die Ereignisse entsprechend den Ordnungskriterien geordnet. Diese Kriterien sind in den Ereignisschablonen spezifiziert.
Präsentationsadaption
Die Präsentation wird innerhalb des PIAM 6 in Richtung des Benutzers in Relation zu einer ganzen Zahl von Faktoren adaptiert. Der Präsentationsprozess besteht aus wenigstens drei Stufen (siehe 2).
Die erste Stufe ist die "Datenadaption", welche die Präsentation entsprechend den Charakteristiken der Daten (das heißt der Ereignisse) selbst adaptiert. Wenn ein Ereignis beispielsweise in der Nähe ist, können gerade die Ereignisbeschreibung und der Ort des Ereignisses angezeigt werden, wenn ein Ereignis nicht in der Nähe, aber in der gleichen Stadt ist, werden zusätzlich die öffentlichen Transportdaten (Zeittabellen, Wege zu einer Station) angezeigt usw. Diese Adaption kann beispielsweise durch Verwendung eines Regelmechanismus, der Dinge wie „if (event.location = „nearby") then show (event.description,event.location)" ("wenn (Ereignis.Ort = "in der Nähe"), dann zeige (Ereignis.Beschreibung,Ereignis.Ort)") oder „if (event.location = „intown") then show (event.description,event.location,event.transportation.timetabl es)" ("wenn "Ereignis.Ort = "in Stadt"), dann zeige (Ereignis.Beschreibung, Ereignis.Ort, Ereignis.Transportation.Zeittabellen)") spezifizieren kann, realisiert werden.
Die zweite Stufe ist die "Benutzeradaption", welche die Präsentation in Relation zum Benutzer adaptiert. Diese enthält Einstellungen entsprechend den expliziten Einstellungen durch den Benutzer, seine/ihre Präferenzen, die vom System gelernt worden sind, usw.
Die dritte Stufe ist die "Gerätadaption", welche die Präsentation entsprechend den Charakteristiken des tatsächlichen Benutzergeräts und der Datenverbindung mit diesem Gerät adaptiert. Diese Adaption enthält Einstellungen zu Dingen wie der Schirmgröße, den Farbfähigkeiten, dem benötigten Präsentationsformat (beispielsweise auf HTML oder WML), die tatsächliche Bandbreite und die Bedingung des Netzwerks.
Die Komponenten des Systems können wie in 3 gezeigt verteilt sein. Die PIAM 6-Komponente kann in ein systemseitiges PIAM-Modul 6 und ein benutzergerätseitiges Clientprogramm 4 zerlegt sein. Das letztere kann einfach aus einem Web- oder WAP-Browser bestehen. Alternativ dazu kann es aus einem speziellen Clientprogramm bestehen, das Interaktionen des Benutzers mit dem System handhabt. Das KM 5 kann auf dem Benutzergerät residieren. In diesem Fall kann es aus einem existierenden Kalenderprogramm (wie Microsoft Outlook) bestehen.
Das ganze System kann als ein Dienst eines Vielfachzugriff-Dienstportals realisiert sein.
Der ESM 9-Sammlungsprozeß kann unter Verwendung von Translator- und Adaptorkomponenten realisiert sein, welche die Ereignisse vom Format bei der Quelle in das Format, das innerhalb des System benutzt wird, übersetzen bzw. die den Abfrageprozess der Ereignisquelle umfassen. Es kann erwartet werden, dass in Zukunft auf Ereignisse im Web in einem XML-basierten Format zugegriffen werden kann.
Das ESM 9 kann eine SQL-Datenbank zum Speichern der gesammelten Ereignisse verwenden. Die Ereignisschablonen können dann durch SQL-Anweisungen, die benutzt werden, um in der ESM-Datenbank ausgeführt zu werden, realisiert werden.
Das KM 5 kann entweder auf dem Benutzergerät, im System oder einem anderen Computer in einem verbundenen Netzwerk lokalisiert sein. Das KM 5 kann beispielsweise durch Verwendung von Micosoft Outlook unter Verwendung seiner COM-Schnittstelle auf dem Benutzergerät realisiert sein.

Claims

Verfahren zur Verwaltung von Ereignisinformationsdaten, wobei das Verfahren die folgenden Schritte aufweist: – Abfragen der laufenden Zeit (16) und der laufenden geografischen Position (15) eines mobilen Kommunikationsgeräts (1), – Verwenden der Information über die laufende Zeit (16) und geografische Position (15) für eine Schablone zur Abfrage (12) einer Ereignisquelle (9), wobei die Ereignisquelle (9) Ereigniseingaben enthält, die durch ihre Kategorie, Zeit und ihren Ort parameterisiert sind, – Berechnen einer Liste von Ereignissen, die für einen Benutzer des mobilen Kommunikationsgeräts (1) bei Berücksichtigung der Differenzen zwischen der Startzeit und dem Ort eines Ereignisses und der laufenden Zeit und Position des mobilen Kommunikationsgeräts (1) zugreifbar sind, und – Präsentieren (6) der Liste zugreifbarer Ereignisse auf dem mobilen Kommunikationsgerät (1).
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Schritt der Berechnung einer Liste zugreifbarer Ereignisse den Schritt einer Berücksichtigung von Transportressourcen von der laufenden Position des mobilen Kommunikationsgeräts (1) zum Ort eines Ereignisses aufweist.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass außerdem Profilinformation des Benutzers des mobilen Kommunikationsgeräts (1) Teil der Schablone zur Abfrage (12) der Ereignisquelle (9) ist.
Verfahren nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, dass wenigstens für einen Teil der zugreifbaren Ereignisse eine Transportinformation für mögliche Wege, um von der laufenden Position des mobilen Kommunikationsgeräts (1) zu einem Ereignisort zu kommen, berechnet (11) und präsentiert wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Liste zugreifbarer Ereignisse dynamisch präsentiert wird (6), das heißt die Liste zugreifbarer Ereignisse aktualisiert wird, um eine Liste bleibender zugreifbarer Ereignisse jedes Mal, wenn der Benutzer des mobilen Kommunikationsgeräts (1) ein Ereignis akzeptiert, zu erzeugen.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass vom Benutzer des mobilen Kommunikationsgeräts (1) akzeptierte zugreifbare Ereignisse automatisch als Eingaben in eine elektronische Kalenderdatei (5) übertragen werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Benutzer des mobilen Kommunikationsgeräts (1) Ereignisse für die Liste zugreifbarer Ereignisse und/oder für die Ereignisquelle (9) erzeugen kann.
Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass der Benutzer Ereignisse durch manuelle kundenspezifische Anpassung auswählbarer Ereignisse, die vom mobilen Kommunikationsgerät (1) vorgeschlagen werden, erzeugen kann.
Verfahren nach einem der vorhergehenden Ansprüche, gekennzeichnet durch einen Lernmodus, bei dem das mobile Kommunikationsgerät (1) Ereignispräferenzen des Benutzers durch Bewerten der Interaktion mit dem Benutzer lernt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Benutzer stehende Ordnungen für Ereignisse derart vorkonfigurieren kann, dass korrespondierende Ereignisse automatisch gewählt werden, wenn sie in der Ereignisquelle (9) wieder aufgefunden werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Ereigniseingaben der Ereignisquelle (9) durch Suchen eines Netzes (3) automatisch erzeugt werden.
Computersoftwareprogrammprodukt, dadurch gekennzeichnet, dass es ein Verfahren gemäß einem der vorhergehenden Ansprüche implementiert, wenn es auf einem mobilen Kommunikationsgerät (1) läuft.
Mobiles Kommunikationsgerät, das ein Ereignisverwaltungsmodul aufweist, wobei das Ereignisverwaltungsmodul (1, 2) aufweist: – eine Einrichtung (15, 16) zur Bestimmung der aktuellen Zeit und der laufenden geografischen Position des mobilen Kommunikationsgeräts (1), – eine Einrichtung zur Abfrage (12) einer internen und/oder externen Ereignisquelle (9), die durch ihre Kategorie, Zeit und ihren Ort parameterisierte Ereigniseingaben enthält, wobei die Abfrage auf der Basis einer Schablone, die wenigstens die laufende Zeit und geografische Position des mobilen Kommunikationsgeräts (1) enthält, ausgeführt wird, – eine Einrichtung zur Berechnung einer Liste von Ereignissen, die für einen Benutzer des mobilen Kommunikationsgeräts (1) bei Berücksichtigung der Differenzen zwischen der Startzeit und dem Ort eines Ereignis und der laufenden Zeit und Position des mobilen Kommunikationsgeräts (1) zugreifbar sind, und – eine Einrichtung zum Präsentieren (6) der Liste zugreifbarer Ereignisse.
Mobiles Kommunikationsgerät nach Anspruch 13, dadurch gekennzeichnet, dass die Einrichtung zur Berechnung einer Liste aus zugreifbaren Ereignissen Transportressourcen von der laufenden Position des mobilen Kommunikationsgeräts (1) zum Ort eines Ereignisses berücksichtigt.
Mobiles Kommunikationsgerät nach Anspruch 13 oder 14, dadurch gekennzeichnet, dass die von der Abfrageeinrichtung (12) verwendete Schablone außerdem Profilinformation des Benutzers des mobilen Kommunikationsgeräts (1) aufweist.
Mobiles Kommunikationsgerät nach einem der Ansprüche 13 bis 15, dadurch gekennzeichnet, dass es außerdem ein Navigationsmodul (11) zur Berechnung und Präsentierung möglicher Wege, um von der laufenden Position des mobilen Kommunikationsgerät (1) zum Ort eines Ereignisses zu kommen, aufweist.
Kommunikationsgerät nach einem der Ansprüche 13 bis 16, gekennzeichnet durch: eine Berechnungseinrichtung (6) zur dynamischen Aktualisierung der Liste zugreifbarer Ereignisse, um eine Liste bleibender zugreifbarer Ereignisse jedes Mal, wenn der Benutzer des mobilen Kommunikationsgeräts (1) ein Ereignis akzeptiert, zu erzeugen.
Mobiles Kommunikationsgerät nach einem der Ansprüche 13 bis 16, gekennzeichnet durch: eine Einrichtung (12) zur automatischen Übertragung zugreifbarer Ereignisse, die vom Benutzer des mobilen Kommunikati onsgeräts akzeptiert sind, als Eingaben in eine elektronische Kalenderdatei (5).