Terminrobot
Die vorliegende Erfindung bezieht sich auf ein System, ein Verfahren und Vorrichtungen für einen Terminrobot gemäss den Oberbeg riffen der unabhängigen Ansprüche.
Verschiedene Systeme zur Terminerfassung , Terminverwaltung und zum Abgleich von Terminen sind heute bekannt, häufig auch unter dem Begriff Organizer oder ähnlichen Bezeichnungen . Die meisten dieser Systeme dienen der reinen Terminerfassung und Verwaltung und können, soweit sie sich elektronischer Technologien verwenden , unter dem Überbeg riff Elektronische Agenda zusammengefasst werden. Entsprechende bekannte Lösungen erfordern aufwendige Interaktionen von Bedienpersonen und sind daher in komplexeren Umgebungen nicht nur sehr umständlich, sondern kaum tauglich . Wenngleich die vorliegende Erfindung gänzlich andere Ansätze verfolgt, soll auf die entsprechenden H intergrundtechnologien kurz eingegangen werden.
M it dem Betriebssystem Mac OS X™ wird beispielsweise das Programm Kalender (je nach Version auch unter dem Namen iCal oder Calendar bekannt) ausgeliefert. Das Prog ramm unterstützt verschiedene Kalender für Termine und Aufgaben. Zur Anzeige der Kalender kann jedem Kalender eine Farbe zugewiesen werden. Jeder eigene Kalender kann über einen Server (z. B. WebDAV) veröffentlicht werden. Andere veröffentlichte Kalender ( Feiertage, Kinoprogramm, etc. ) können abonniert werden. Gruppen kalender, bei welchen eine Gruppe von Personen sich zum gegenseitigen Abgleichen von Terminen gegenseitig Kalendereinträge zum Lesen und Schreiben freigeben könnten, werden nicht unterstützt.
RFC 5545 ( Request for Comment) der I ETF ( Internet Engineering Task Force) definiert ein iCalendar Datenformat, um Kalenderinformationen wie z. B. Ereignisse, Aufgaben, Handbucheinträge, Verfügbarkeitsinformationen auszutauschen . Das iCalendar Format ist als Austauschformat zwischen Applikationen und Systemen geeignet und ist über Datennetze übermittelbar. Es werden Aufgaben wie Terminanfragen, Terminantworten, Terminänderungen oder Terminabsagen unterstützt. Ferner ist die Benutzung des Daten formats im Sinne von Anfragen und Antworten betreffend freier oder besetzter Zeiten möglich .
Von Elektronischen Agenden sind Systeme zu unterscheiden, welche nicht die eigentli chen Terminerfassung, Terminbestätigung oder Terminfixierung betreffen , sondern den vorgeschalteten , hier Terminsynchronisation bzw. Terminkoordinierung genannten Pro- zess. Derartige Systeme sind heute noch wenig verbreitet. Eines dieser Systeme ist Dood- le™, welches vorgesehen ist, für mehrere Personen einen passenden Termin zu finden. Die Personen sind in einen Termin- Koordinator und mehrere ( potenzielle) Termin- Teilnehmer unterteilt. Der Termin- Koordinator erfasst manuell mehrere Terminvorschläge entsprechend der eigenen Agenda und lädt mehrere Termin -Teilnehmer ein , denjenigen Terminvorschlägen durch manuelle Eingabe zuzustimmen , welche zu der jeweils eigenen Agenda passend sind. Der Termin -Koordinator überwacht, ob die eingeladenen Termin - Teilnehmer zu den Terminvorschlägen Stellung genommen haben und übermittelt Einladungserinnerungen, welche vom System auch automatisch an diejenigen Personen übermittelt werden können , welche zu den Terminvorschlägen noch nicht Stellung genommen haben . Nachdem alle Termin -Teilnehmer ihre Eingaben vorgenommen haben, ist eine manuelle Auswertung durch den Termin- Koordinator erforderlich, wobei bei ungünstiger Konstellation , falls z. B. mehreren Terminen gleich häufig zugestimmt wurde oder keinem Termin von allen Termin-Teilnehmern zugestimmt wurde, zusätzliche Abklärungen oder eine neue Terminumfrage erforderlich sind. Schliesslich erfolgt - wiederum
durch Handarbeit - eine Terminbestätigung an die Termin-Teilnehmer resp. eine Terminfixierung .
Heutige elektronische Agenden erlauben es, für einen bestimmten Benutzer Termine zu erfassen, diese zu speichern, abzurufen und zu modifizieren . In der Regel ist es zwar auch möglich , auf Elektronische Agenden weiterer Benutzer zuzug reifen, diese ( insbesondere innerhalb von Unternehmenseinheiten ) einzusehen und möglicherweise Kollisionen mit diesen Terminen manuell zu erkennen und solche bei der Terminerfassung zu vermeiden. Solche Systeme setzen einerseits voraus, dass die mehreren Benutzer das gleiche System verwenden und über geeignete Hard- oder Softwareeinstellungen die gegenseitige Einsicht in die Elektronischen Agenden erlauben . Die Terminerfassung und Synchronisation erfolgt auch hier grundsätzlich manuell und erfordert erheblichen Personenaufwand.
Besonders wenn eine Terminsynchronisation schnell und zwischen mehreren Personen erfolgen soll, scheitern herkömmliche Systeme, da der Synchronisationsaufwand nichtlinear in die Höhe steigt und derartige teil-automatisierte Prozesse gegen über einer rein manuellen Lösung kaum mehr Vorteile bringen bzw. eher hinderlich werden . Der Erfas- sungs- und Verwaltungsaufwand in solchen Systemen führt zu einem unverhältnismässi gem Aufwand . Gänzlich ungenügend sind bekannte Lösungen, wenn eine schnelle Terminsynchronisation innert Sunden oder gar M inuten erforderlich wären . H ier verunmög- licht die notwendige manuelle Ü berprüfung durch die beteiligten Personen eine Lösung. Oft werden mehrere Feedback-Loops erforderlich, bis eine Terminsynchronisation überhaupt erfolgreich abgeschlossen werden kann.
Ein weiteres bisher ungelöstes Problem ist die Tatsache, dass die bekannten Terminkoordinationssysteme verhältn ismässig grosse Benutzerinterfaces erfordern, um die gewünschten Terminvergleiche vornehmen zu können. Selbst bessere dieser Systeme erlau-
ben es nicht, gleichzeitig über grössere Zeiträume zu synchronisierende Termine mit bestehenden Terminen abzug leichen .
Es ist Aufgabe der Erfindung, mindestens einzelne der oben erwähnten Nachteile des Standes der Technik zu überwinden und eine schnelle sowie hocheffizient automatisierte Terminsynchronisation zu erlauben .
Diese Aufgabe wird durch die Merkmale der unabhängigen Patentansprüche gelöst.
Das erfindungsgemässe System für einen Terminrobot umfasst ein Mastermodul und eines oder mehrere Clientmodule. Das Mastermodul ist vorgesehen , auf Kalendereinträge zuzug reifen und einen Terminrobot mit daran angeschlossenem Parameterset sowie Befehlsset zu erstellen und über ein Datennetz an eines oder mehrere Clientmodule zu übermitteln , und von den Clientmodulen je Gruppen bzw. Listen mit provisorischen Termineinträgen zu empfangen und auszuwerten , um eine oder mehrere Kalenderbuchungen zu ermitteln . Das eine oder die mehreren Clientmodule sind vorgesehen, einen Terminrobot mit daran angeschlossenem Parameterset sowie Befehlsset von einem Mastermodul entgegenzunehmen und auf Kalendereinträge zuzug reifen und eine Gruppe bzw. Liste mit provisorischen Terminen zu erstellen und an das Mastermodul zu übermitteln . Das System ist aufgrund des Terminrobots in der Lage, eine Termin- bzw. Kalenderbuchung vollkommen automatisch zu ermitteln und vorzunehmen.
Die Erfindung geht aus von dem Gedanken eines Terminrobots, welcher bevorzugt in einer Kapsel gesichert ist, um Sicherheitsrichtlinien zu entsprechen. Der Terminrobot wird peer-to-peer zwischen den beteiligten Modulen, welche bevorzugt in mobilen Endgeräten wie Smartphones etc. installiert sind , übermittelt. Zur Übermittlung des Terminrobots kommen Datennetze zum Einsatz, welche bei den mobilen Endgeräten jeweils verfügbar
sind . Der Terminrobot kann rasch erstellt und ebenso rasch den beteiligten Mod ulen verfügbar gemacht werden. Zudem ist die Auswertung des Terminrobots aufgrund des daran angeschlossenen Parameterset sowie Befehlset flexibel und hocheffizient, um zwischen den beteiligten Modulen eine Synchronisation von Terminen durchzuführen und einen gewünschten Abgleich von Terminen in Kalender zu erhalten , welche von den beteiligten Mod ulen zugreifbar sind .
In einer Ausgestaltung ist das Mastermod ul vorgesehen, eine ermittelte Kalenderbuchung an eine oder mehrere Clientmodule zu übermitteln und von dem einen oder den mehreren Clientmodulen eine Quittierung entgegenzunehmen und die Kalenderbuchung abzuspeichern. Das Mastermodul ist in der Lage, eine (definitive oder optionale bzw. provisorische) Kalendererbuchung zu übermitteln und die entsprechende Quittierung entgegenzunehmen . Die Kalenderbuchung kann vor oder nach der Quittierung in einem Kalender auf dem Master eingetragen werden.
In einer Ausgestaltung sind das eine oder die mehreren Clientmodule vorgesehen, eine Kalenderbuchung von einem Mastermodul entgegenzunehmen und die Kalenderbuchung abzuspeichern und eine Quittierung an das Mastermod ul zu übermitteln . Das eine oder die mehreren Clientmodule sind in der Lage, aufgrund des Empfangs einer Kalenderbuchung eine Quittierung an das Mastermod ul zu übermitteln . Die Kalenderbuchung resp. der entsprechende Kalendertermin wird auf dem betreffenden Client in einem Kalender eingetragen.
In einer Ausgestaltung sind das Mastermod ul resp. das eine oder die mehreren Clientmodule vorgesehen, auf in mehreren Kalenderdatenbanken abgespeicherte Kalendereinträge zuzug reifen, wobei die Kalenderdatenbanken mindestens eine Kalenderdatenbank eines dem Master- bzw. Clientmodul zugeordneten Benutzers und eine Kalenderdaten -
bank zum Abspeichern von provisorischen Terminen umfassen . Für das Ermitteln einer Termin - bzw. Kalenderbuchung können mehrere Kalender berücksichtigt werden . Wenn in vorliegendem Zusammenhang von davon gesprochen wird , dass auf die abgespeicherten Kalendereinträge zugegriffen wird, ist dies nicht derart zu verstehen, dass deren Inhalt zug reifbar sein muss. Vielmehr wird im Rahmen der Erfindung der Vorteil gen utzt, dass das Clientmodul (vermittels Kenntnis der abgespeicherten Kalendereinträge) nur die freien Terminmöglichkeiten (quasi die Leerstellen ) ausgelesen und übermittelt werden .
Die Erfindung geht aus vom Gedanken, dass ein erster Kalender vorgesehen ist, um die Kalenderdaten des Benutzers einzutragen und anzuzeigen . Ferner ist ein zweiter Kalender vorgesehen , um provisorische Termine einzutragen und anzuzeigen . Durch die Aufteilung in die fixen Benutzertermine und die provisorischen Termine ergibt sich einerseits die Möglichkeit einer für den Benutzer übersichtlich und beq uem verwaltbaren Benutzerschnittstelle. Ferner kann durch das Abspeichern von fixen Benutzerterminen in einem ersten Kalender und das Abspeichern von provisorischen Terminen in einem zweiten Kalender der Abgleich und die Synchronisation von Terminen durch das System automatisch , effizient, präzise und zuverlässig erfolgen.
Die Erfindung geht aus vom Gedanken, dass dem Benutzer betreffende Kalender, also zumindest der erste Kalender mit den fixen Terminen des Benutzers, der zweite Kalender mit den provisorischen Kalender sowie weitere abonnierte Kalender in einer Kalendermatrix dargestellt wird. Die Kalendermatrix ermöglicht eine effiziente Verwaltung von Terminen durch den Benutzer. Mehrere Kalender sind zeilenweise angeordnet, wobei die einzelnen Kalender zeitlich aufeinander ausgerichtet sind. Ein Matrixelement der Kalendermatrix ist somit durch eine Identifikation eines Kalenders sowie einen Zeitpunkt, ein Zeitintervall , etc. definiert. Die zeitliche Ausrichtung der einzelnen Kalenderzeilen ermöglicht einen direkten Vergleich der Termine. Durch eine Tages-, Wochen-, Monatsdarstel-
lung etc. kann der Benutzer fixe und provisorische Termine rasch überprüfen. Kalender verfügen über Lese- und/oder Schreibberechtigung. Das Eintragen eines Termins in einen Kalender mit Schreibberechtigung kann rasch und übersichtlich mit drag-and-drop erfolgen, wobei der Benutzer wegen der Darstellung als Kalendermatrix beim Eintragen die verschiedenen Kalender gleichzeitig berücksichtigen kann. Dies ermöglicht die rasche Erstellung eines Termins, welcher für eine Terminsynchronisation mit anderen Teilnehmern des Systems herangezogen werden soll . Es ermöglicht auch das rasche Überprüfen und ggf. Bestätigen eines oder mehrerer provisorischen Termine, welche aufgrund eines dem betreffenden mobilen Endgeräts des Benutzers zur Verfügung gestellten Terminrobots eingetragen wurden.
In einer Ausgestaltung sind das Mastermod ul resp. das eine oder die mehreren Clientmodule vorgesehen, auf Kalendereinträge in einem dem Master- bzw. Clientmodul zugeordneten lokalen Speicher zuzugreifen und/oder auf Kalendereinträge in einem über ein Datennetz zug reifbaren Speicher zuzugreifen. Der Zugriff auf den lokalen Speicher kann in einer Variante über ein Kalendermodul erfolgen, welches einen Kalenderspeicher verwaltet. Der Zugriff auf über ein Datennetz zugreifbaren Speicher kann ein auf einem Internetserver publizierten Kalender betreffen .
In einer Ausgestaltung sind das Mastermod ul resp. das eine oder die mehreren Clientmodule vorgesehen, das am Terminrobot angeschlossene Parameterset und Befehlsset, die Gruppen bzw. Listen mit provisorischen Kalenderterminen und/oder einen ermittelten Kalendereintrag in einem Datenformat zu erstellen , das einen oder mehrere Einträge in einem iCalendar Datenformat umfasst. Dadurch wird insbesondere die Kompatibilität zu bestehenden Kalender verbessert.
In einer Ausgestaltung sind das Mastermod ul resp. das eine oder die mehreren Clientmodule vorgesehen, Daten zwischen einem Mastermod ul gemäss einem Extensible Messa ging and Presence Protocol auszutauschen . Dadurch kann die Datenübermittlung auf einem robusten Datenübermittlungsprotokoll aufbauen, welches erprobt und weit verbreitet ist. Entsprechende Kommunikationsprotokolle können in anderen Ausführungsformen zum Einsatz kommen .
In einer Ausgestaltung sind das Mastermod ul resp. das eine oder die mehreren Clientmodule vorgesehen, Daten wie insbesondere einen Terminrobot mit angeschlossenem Parameterset sowie Befehlset, provisorische Termineinträge, etc. vor einer Übermittlung in einer Kapsel umfassend einen Hash , eine elektronische Signatur und/oder eine elektroni sche Verschlüsselung zu sicheren bzw. die gesicherte Kapsel beim Empfang zu überprüfen . Durch die Sicherung des Terminrobots in einer Kapsel wird die Datenintegrität gewährleistet.
In einer Ausgestaltung sind das Mastermod ul resp. das eine oder die mehreren Clientmodule vorgesehen, ein am Terminrobot angeschlossenes Parameterset zu erstellen und übermitteln resp. entgegenzunehmen welches einen oder mehrere der folgenden Para meter umfasst: Kalenderdatum, Start- und Endzeit, Adressinformationen von Terminteil nehmern , Termintreffpunkt, Termintitel. Die für das Ermitteln einer Termin- bzw. Kalen derbuchung erforderlichen Parameter können dadurch zur Verfügung gestellt werden.
In einer Ausgestaltung sind das Mastermod ul resp. das eine oder die mehreren Clientmodule vorgesehen, ein am Terminrobot angeschlossenes Befehlset zu erstellen und übermitteln resp. entgegenzunehmen das einen oder mehrere der folgenden Befehle umfasst: Priorisierung von im Parameterset enthaltenen Informationen , zwingende Vorgaben betreffend im Parameterset enthaltenen Informationen, Kriterien um Gruppen bzw. Lis-
ten mit freien Terminen zu ermitteln. Dadurch können flexible und leistungsfähige Befehle definiert werden, welche zum Ermitteln einer Termin - bzw. Kalenderbuchung erforderlich sind .
In einer besonderen Ausführungsform des Systems können Kalenderinformationen des Master- und/oder einzelner Clientmodule auch als Repräsentationen auf einem Server ganz oder teilweise abgebildet sein . Eine teilweise Repräsentation kann insbesondere bevorzugt die freien Terminbereiche („Leerstellen") eines Clients umfassen . Diese Leerstellen können für besondere Zeiträume, unter Berücksichtigung von Filterkriterien oder auch für einen Client gesamthaft (vollständig ) auf einem Server abgebildet sein . Die Kontrolle über die bzw. Beeinflussung der bereitgestellten Informationen liegt beim jeweiligen Client oder erfolgt nach Massgabe von Defaultwerten . Die seitens des Masterclients initiierte Terminkoordination nutzt diesfalls die vom Client (oder mehreren Clients) bereitgestellten Leerstellen -Informationen erfindungsgemäss auf dem Server (oder mehreren vernetzten Servern ). Die peer-to-peer Kommunikation kann diesfalls ebenfalls vermittels dieser Repräsentationen oder aber auch direkt zwischen den Clients erfolgen. Diese bevorzugte Ausführungsform trägt einer hohen Datensicherheit Rechnung und kann den Datenverkehr zwischen Master und den Clients selber reduzieren. Diese Ausführungsform erlaubt es weiterhin, dass auch der Masterclient seine Termininformationen ( Leerstellen ) auf dem Server (synchronisiert oder ephemer übermittelt) zur Verfügung stellt und die Terminfindung serverseitig ausgewertet werden kann und so dem Master nur ein Ergebnis (Terminoptionen von allen möglichen Terminen oder eine Selektion davon ) übermittelt wird.
Es wäre weiterhin möglich - unter Inkaufnahme einer weniger guten Ausnutzung des sich aus der Vermeidung eines serversynchronisierten Kalenders ( nicht nur der Leerstellen , sondern der eigentlichen Termine und deren Inhalten ) ergebenden Vorteils der Datenver-
traulichkeit (vgl. dazu weiter unten ) - auf diese Weise voll serversynchronisierte („cloud- basierte") Kalender zu unterstützen .
In einer entsprechend bevorzugten Variante besitzt mindestens ein Client mindestens ein Clientmodul, das als Repräsentation auf einem Server repräsentiert ist, wobei diese Rep- räsentation alle oder Teile der auf diesem Clientmodul gespeicherten freien Terminbereiche enthält.
In einem erfind ungsgemässen Verfahren für einen Terminrobot wird von einem Mastermodul auf Kalendereinträge zugeg riffen und ein Terminrobot mit daran angeschlossenem Parameterset sowie Befehlsset erstellt. Über ein Datennetz wird dieser Terminrobot an eines oder mehrere Clientmodule übermittelt. Von den Clientmodulen werden auf dem Mastermod ul je Gruppen bzw. Listen mit provisorischen , möglichen Termineinträgen empfangen und ausgewertet, um eine oder mehrere Kalenderbuchungen zu ermitteln . Von einem oder mehreren Clientmodulen wird ein Terminrobot mit daran angeschlossenem Parameterset sowie Befehlsset von einem Mastermodul entgegengenom- men und es wird auf Kalendereinträge zugeg riffen und eine Gruppe bzw. Liste mit provisorischen Terminen erstellt und an das Mastermodul übermittelt.
In einer Ausgestaltung wird vom Mastermod ul eine ermittelte Termin- bzw. Kalenderbuchung an eines oder mehrere Clientmodule übermittelt und von dem einen oder den mehreren Clientmodulen eine Quittierung entgegengenommen und die Kalenderbu- chung abgespeichert.
In einer Ausgestaltung wird von einem oder mehreren Clientmodulen eine Termin- bzw. Kalenderbuchung von einem Mastermod ul entgegengenommen und die Kalenderbuchung abgespeichert und eine Quittierung an das Mastermod ul übermittelt.
In einer Ausgestaltung wird vom Mastermodul resp. von dem einen oder den mehreren Clientmodulen auf in mehreren Kalenderdatenbanken abgespeicherte Kalendereinträge zugeg riffen, wobei die Kalenderdatenbanken mindestens eine Kalenderdatenbank eines dem Master- bzw. dem einen oder den mehreren Clientmodulen zugeordneten Benut- zers und eine Kalenderdatenbank zum Abspeichern von provisorischen Terminen umfassen .
In einer Ausgestaltung wird vom Mastermodul resp. von dem einen oder den mehreren Clientmodulen auf Kalendereinträge in einem dem Master- bzw. Clientmodul zugeordneten lokalen Speicher zugeg riffen und/oder auf Kalendereinträge in einem über ein Da- tennetz zug reifbaren Speicher.
In einer Ausgestaltung werden vom Mastermod ul resp. von dem einen oder den mehreren Clientmodulen ein Terminrobot mit angeschlossenem Parameterset, Gruppen bzw. Listen mit provisorischen Kalenderterminen und/oder ermittelte Kalenderbuchungen in einem Datenformat erstellt, das einen oder mehrere Einträge in einem iCalendar Daten- format umfasst.
In einer Ausgestaltung werden zwischen dem Mastermod ul und dem einen oder den mehreren Clientmodulen Daten gemäss einem Extensible Messaging and Presence Proto- col ausgetauscht.
In einer Ausgestaltung werden vom Mastermod ul resp. von dem einen oder den mehre- ren Clientmodulen Daten wie insbesondere einen Terminrobot mit angeschlossenem Parameterset sowie Befehlset, provisorische Termineinträge, etc. vor einer Ü bermittlung in einer Kapsel umfassend einen Hash, eine elektronische Signatur und/oder eine elekt-
ronische Verschlüsselung gesichert bzw. die gesicherte Kapsel wird beim Empfang überprüft.
In einer Ausgestaltung wird vom Mastermodul resp. von dem einen oder den mehreren Clientmodulen ein am Terminrobot angeschlossenes Parameterset erstellt und übermittelt resp. entgegengenommen , welches einen oder mehrere der folgenden Parameter um- fasst: Kalenderdatum, Start- und Endzeit, Adressinformationen von Terminteilnehmern , Termintreffpunkt, Termintitel .
In einer Ausgestaltung wird vom Mastermodul resp. von dem einen oder den mehreren Clientmodulen ein am Terminrobot angeschlossenes Befehlset B erstellt und übermittelt resp. entgegengenommen , der einen oder mehrere der folgenden Befehle umfasst: Prio- risierung von im Parameterset enthaltenen Informationen, zwingende Vorgaben betreffend im Parameterset enthaltenen Informationen, Kriterien umfassend Abfrageintervalle um Gruppen bzw. Listen mit freien Terminen zu ermitteln .
Ein erfind ungsgemässer Master für einen Terminrobot umfasst ein Mastermod ul das vor- gesehen ist, auf Kalendereinträge zuzugreifen und einen Terminrobot mit daran angeschlossenem Parameterset sowie Befehlsset zu erstellen , die in einer Kapsel gesichert sind, und über ein Datennetz an eines oder mehrere Clientmodule zu übermitteln und von den Clientmodulen je Gruppen bzw. Listen mit provisorischen Termineinträgen zu empfangen und auszuwerten, um eine oder mehrere Kalenderbuchungen zu ermitteln . In einer Ausgestaltung des Master ist eine grafische Benutzerschnittstelle eingerichtet, Kalendereinträge eines Benutzers des Masters in einem ersten Kalender und provisorische Termineinträge in einem zweiten Kalender gleichzeitig darzustellen, wobei diese Kalender in der Zeitachse aufeinander ausgerichtet sind.
Ein erfind ungsgemässer Client für einen Terminrobot umfasst ein Clientmodul, das vorgesehen ist, einen Terminrobot mit daran angeschlossenem Parameterset sowie Befehlsset, die in einer Kapsel gesichert sind , von einem Mastermodul entgegenzunehmen und auf Kalendereinträge zuzug reifen und eine Gruppe bzw. Liste mit provisorischen Terminen zu erstellen und an das Mastermodul zu übermitteln .
In einer Ausgestaltung des Client ist eine grafische Benutzerschnittstelle eingerichtet, Kalendereinträge eines Benutzers des Clients und provisorische Termineinträge gleichzeitig darzustellen , insbesondere indem diese auf nebeneinanderliegenden , hinsichtlich der Zeitachse aufeinander ausgerichteten Kalender dargestellt werden .
In einer Ausgestaltung des Client ist ein Eingangsgate vorgesehen, einen Terminrobot mit angeschlossenem Parameterset und Befehlset entgegenzunehmen , die in einer Kapsel gesichert sind, und die Sicherheitselemente zu überprüfen und das Parameterset sowie das Befehlset auf das Einhalten einer Sicherheitsrichtlinie zu überprüfen.
In einer Ausgestaltung des Client ist ein Ausgangsgate vorgesehen , eine Gruppe bzw. Liste mit provisorischen Terminen auf das Einhalten einer Sicherheitsrichtlinie zu überprüfen .
Die Erfindung soll nachfolgend anhand von Ausführungsbeispielen im Zusammenhang mit den Zeichnungen erläutert werden . Es zeigen :
Fig. 1 a schematisch ein System umfassend ein Mastermod ul und mehrere Clientmodule;
Fig. 1 b schematisch ein System umfassend ein Mastermod ul und mehrere Clientmodule, davon ein Clientmodul mit einer Repräsentation auf einem Server;
Fig. 2 schematisch einen Terminrobot mit angeschlossenen Parameterset und Be- fehlset;
Fig. 3 schematisch ein Clientmodul mit einem Eingangsgate und einem Ausgangsgate;
Fig. 4 schematisch eine grafische Benutzerschnittstelle für ein Mastermodul; und
Fig. 5 schematisch eine grafische Benutzerschnittstelle für ein Clientmodul.
Figur 1 a zeigt ein System mit einem Mastermodul MA und mehreren Clientmodulen CA 1 , CA2, CA3. Das Mastermod ul MA ist in einem als Master M bezeichneten Mobilgerät (Smartphone, Handheld etc. ) enthalten . Die Clientmodule CA 1 , CA2, CA3 sind je in als Clients C 1 , C2 , C3 bezeichneten Mobilgeräten (ebenfalls Smartphones, Handheids etc. ) enthalten . Das Mastermod ul MA und die Clientmodule CA 1 , CA2, CA3 sind insbesondere als ASIC oder als Softwareapplikationen oder aus einer M ischung dieser beiden Varianten ausgeführt. In einer bevorzugten Variante sind das Mastermodul MA und/oder die Clientmodule CA 1 , CA2, CA3 als Softwareapplikationen auf den in Figur 1 a schematisch dargestellten Mobilgeräten M , C 1 , C2, C3 installiert, welche dort auf einem Prozessor ausgeführt werden. In einer bevorzugten Variante sind das Mastermod ul MA und/oder die Clientmodule CA 1 , CA2, CA3 als Hardwarebauteile ausgeführt, beispielsweise als ASIC (ASIC: Application -specific integrated circuit), welche in den Mobilgeräten M, C 1 , C2, C3 eingesetzt sind. Die Mobilgeräte M , C 1 , C2, C3 sind als Smartphones, Mobiltelefone, Tablet oder auch als Armbanddisplay etc. ausgeführt. Ein Mobilgerät M , C 1 , C2, C3 umfasst Kommunikationsschnittstellen , Benutzerschnittstellen , M ikroprozessoren und andere elektronische Schaltungen. Kommunikationsschnittstellen umfassen eine Mobilfunkschnittstelle oder eine Schnittstelle zu einem WLAN (Wireless Local Area Networt)
oder eine andere Kommunikationsnetzanbindung . Benutzerschnittstellen umfassen einen Touchscreen, einen Display und/oder ein Pointerdevice bzw. eine Tastatur.
M it dem im Master M enthaltenen Mastermodul MA und den in den Clients C 1 , C2, C3 enthaltenen Clientmodulen CA 1 , CA2, CA3 werden die nachfolgend im Einzelnen erläuterten Funktionen des Systems für einen Terminrobot durchgeführt, wobei diese Funktionen durch das Mastermodul MA und die Clientmodule CA 1 , CA2, CA3 gesteuert werden . In einer Variante werden das Mastermodul MA und/oder die Clientmodule CA 1 , CA2, CA3 in einem Softwarestore (sog. App Stores) als herunterladbare bzw. installierbare App zur Verfügung gestellt, welche entweder ein Mastermod ul, ein Clientmodul oder beides umfasst. Dieser Schritt entfällt, soweit die betreffenden Module als ASIC oder Softwareapplikation im Mobilgerät M , C 1 , C2, C3 vorinstalliert sind . Im Falle von als App ausgeführtem Mastermod ul MA und/oder Clientmodulen CA 1 , CA2, CA3 können diese vor Manipulation in herkömmlicher Weise durch Sicherheitssysteme geschützt sein . Wie erwähnt ist in einer Variante das Mastermod ul MA und je ein Clientmodul CA 1 , CA2, CA3 in einem einzelnen Mod ul zusammengefasst, d. h. die beschriebenen Funktionen des Mastermoduls MA und der Clientmodule CA 1 , CA2, CA3 werden von einer einheitlichen App zur Verfügung gestellt, welche sich auf dem Master M als Mastermodul MA verhält und auf den Clients C 1 , C2, C3 als Clientmodul CA 1 , CA2, CA3. Die Clientmodule CA 1 , CA2, CA3 sind hier als identische Module ausgeführt, welche durch Einstellungen des Clients C 1 , C2 , C3 wie z. B. eine I M EI ( International Mobile Equipment Identity), Benutzerangaben, Telefonnummer etc. individualisiert werden. Im in Figur 1 a dargestellten System für einen Terminrobot wird nun eine Terminanfrage nicht wie im Stand der Technik als blosse Informationseinheit, umfassend beispielsweise ein iCalendar Objekt, von einem Master M an Clients C 1 , C2, C3 übermittelt, sondern die Terminsynchronisation basiert auf dem in Figur 2 schematisch dargstelltem Terminrobot R, der den Clients C 1 , C2, C3 verfügbar gemacht wird. Wie in Figur 2 schematisch dargestellt, ist im Terminro-
bot R ein Parameterset P sowie ein Befehlsset B enthalten . Im vorliegenden Ausführungsbeispiel sind der Terminrobot R, das Parameterset P und/oder das Befehlsset B gekapselt in einer durch einen Hashwert 1 1 und/oder eine elektronische Signatur 1 2 verifizierten Kapsel K, die den Clients C 1 , C2 , C3 verfügbar gemacht wird . Optional kann die Kapsel K durch eine elektronische Verschlüsselung 1 3 zusätzlich gesichert sein . Der Hashwert 1 1 , die elektronische Signatur 1 2 und die elektronische Verschlüsselung 1 3 bilden Sicherheitselemente der Kapsel K. Neben den Sicherheitselementen 1 1 , 1 2, 1 3 enthält die Kapsel K oder der Terminrobot R als Informationen über einen Hersteller oder Absender eine Mobiltelefon nummer, eine I M EI ( International Mobile Equipment Identity), eine MSISDN ( Mobile Subscriber Integrated Services Digital Network Number), eine E-mail Adresse, und/oder andere Angaben . Vorzugsweise ist mindestens ein Teil dieser Daten, insbesondere eine Telefonnummer (oder deren Substitut) als Identifier in einem Kapselheader enthalten . Der Kapselheader ist diesfalls unverschlüsselt.
Im vorliegenden Fall generiert der Master M eine Kapsel K 1 , die wie in Figur 1 a schematisch dargestellt über herkömmliche Datennetze (z. B. ein TCP/I P Netzwerk) den Clients C 1 , C2, C3 übermittelt bzw. verfügbar gemacht werden kann. In abweichenden Ausführungsformen kann die Kapsel K 1 durch einen bereits bei einem Client vorhandenen Befehlsset B und einem vom Master M übermittelten Parameterset P gebildet werden ( Hashwert, Signatur und Verschlüsselung können analog in bekannter Weise für die Kapsel sichergestellt werden ). Der Vorteil einer solchen Aufteilung liegt in der geringeren Datenmenge, die vom Master M zu den Clients C 1 , C2, C3 gesendet werden müssen . In einer weiteren Ausgestaltung der Erfindung können wie in Figur 1 a schematisch durch die Kapseln K2, K3 dargestellt das Parameterset P und Befehlsset B pro Client C 1 , C2, C3 verschieden sein, z. B. wenn die Terminsynchronisation für die Clients C 1 , C2, C3 nicht vollständig identische Parameter voraussetzt. Auch bei dieser Ausgestaltung können die Kapseln K 1 , K2, K3 bei Bedarf wiederum erst beim Client C 1 , C2 , C3 gebildet werden.
Beim Empfang einer Kapsel K 1 , K2, K3 auf einem Client C 1 , C2 , C3 , werden auf dem betreffenden Client C 1 , C2 , C3 insbesondere der Hersteller oder Absender der Kapsel K 1 , K2, K3 überprüft. Ferner werden die Sicherheitselemente 1 1 , 1 2, 1 3 der Kapsel K 1 , K2, K3 ausgewertet, wobei eine Ü berprüfung der Signatur und/oder eines Hashwerts und/oder eine Entschlüsselung vorgenommen wird . Falls Hersteller oder Absender bekannt sind und die Auswertung der Sicherheitselemente erfolgreich ist, steht der Termin robot R sowie die daran angeschlossenen Parameterset P und Befehlsset B dem betreffenden Client C 1 , C2, C3 zur Verfügung.
Figur 1 b zeigt eine Ausführungsform des erfind ungsgemässen Systems, die weitgehend Figur 1 a entspricht, aber einen Client C aufweist, bei dem das Clientmodul CA 1 als Repräsentation CA T auf einem Server S repräsentiert ist. Diese Repräsentation CA T enthält hier bevorzugt nur Teile der auf diesem Clientmodul CA 1 gespeicherten freien Terminbereiche. Es können aber bei Bedarf auch alle freien Terminbereiche (also alle„Leerstellen" im Kalender des Clientmoduls C 1 ) mit der Repräsentation CA 1 ' abgeglichen werden .
Diese Leerstellen sind im vorliegenden Beispiel - wiederum aus Gründen der Datensi cherheit - bevorzugt Teilmengen aller freien Termine des Clientmoduls C 1 , d. h. sie umfassen nur einen oder mehrere besondere, vorgegebene Zeiträume (z. B. 2 Monate oder ein Jahr in die Zukunft) oder sind aufgrund vorgegebener oder dynamischer feiner Filterkriterien bestimmt (z. B. nicht mehr als drei Halbtage pro Woche, nicht vor 07 :00 Uhr und/oder „jeweils nie am M ittwoch Nachmittag" etc. ). Die Filterkriterien können im Client C vom Benutzer, ausgehend von Defaultwerten , modifiziert und bearbeitet werden . In einer Weiterbildung dieser Lösung können die Filterkriterien vom Client selbstlernend bestimmt werden (z. B. wenn Termine an Donnerstagen vom Benutzer immer abgewiesen werden usw. ). H ierzu weist der Client ein Selbstlernmod ul SM 1 auf, welches eine Selbstlernlogik bzw. ein entsprechendes Mod ul und einen Speicher aufweist.
Die seitens des Masterclients initiierte Terminkoordination bzw. der Terminrobot nutzt diesfalls Informationen, die in der Repräsentation CA T bereit gestellt sind. Es ist weiterhin möglich, dass alle Clients C 1 , C2, C3 und auch der Masterclient eine entsprechende Repräsentation auf dem Server S (oder vernetzten Servern ) bereitstellen . Die Terminsynchronisation erfolgt ansonsten erfind ungsgemäss analog zu Figur 1 a bzw. dem nachbeschriebenen Verfahren .
In besonderen weiteren Ausführungsvarianten, insbesondere bei einer dem Master M nur beschränkt zur Verfügung stehenden Bandbreite kann das Parameterset P und/oder der Kapselheader Weiterleitungsinformationen enthalten . Auf diese Weise kann vom Master M nur eine Kapsel K 1 versandt werden , die dann beispielsweise vom Client C 1 empfangen und von diesem an die weiteren Clients C2 und C3 weitergeleitet wird . Die Weiterleitung durch den Client C 1 ist durch Berechtigungseinstellungen individuell freigegeben, limitiert oder ganz untersagt, wobei bei Limitierungen und Weiterleitungssper- ren dem ursprünglichen Absender, hier dem Master M , bevorzugt eine entsprechende Meldung zugestellt wird, so dass ein weiterer Sendevorgang über einen alternativen Client C2 usw. vorgesehen werde kann . In analoger Weise kann anstelle der Weiterleitung über einen Client durch eine entsprechende Netzwerkressource ( bspw. einen Kommunikationsserver) eine Kapselverteilung bevorzugt an mehrere Clients C 1 , C2 , C3 bzw. bis Cn ermöglicht werden.
Das Parameterset P umfasst Daten, welche hier vorzugsweise in einem iCalendar Daten format strukturiert sind. Das Befehlset B enthält hier in einer maschineninterpretierbaren Sprache abgefasste Befehlsdefinitionen . Standardparameter oder Standardbefehle können in auf dem Master M und den Clients C 1 , C2, C3 abgespeicherten Tabellen hinterlegt sein , so dass zur Ü bermittlung eines betreffenden Standardparameters oder Standardbe-
fehls im Parameterset P oder im Befehlset B nur die Angabe der betreffenden Tabellenzei - len -I D erforderlich ist. Dadurch lässt sich die zu übermittelnde Datenmenge reduzieren.
Die im Parameterset P in einem iCalender Datenformat abgelegten Daten enthalten eine Liste von Informationskomponenten . Die Komponenten beziehen sich auf ein Ereignis, eine To-do- Liste, einen Journaleintrag, eine Zeitzonen Information , eine Frei/Gebucht- Zeit oder eine Alarmzeit. Die Listeneinträge mit den Komponenten sind vorliegend zeilenweise angeord net und können Einträge wie U I D: , DTSTAM P:, ORGAN IZER: , DTSTART:, DTEN D: oder ZUSAM M EN FASSU NG: aufweisen . Alternativ sind strukturierte Auszeichnungssprachen für die Zusammenstellung des Parametersets P einsetzbar.
Das Parameterset P umfasst entsprechend Daten für einen oder mehrere angefragte Termine, welche beispielsweise Kalenderdaten , Startzeiten , Endzeiten , Termindauer, Daten über den Termininhalt, Dring lichkeit des Termins, Daten mit Ortsangaben , Daten über Terminteilnehmer, etc. enthalten .
Die im Befehlset B in einer maschineninterpretierbaren Sprache abgefassten Befehle sind vorgesehen, Abfragen und/oder Code zu definieren, welche auf einem Client C 1 , C2 , C3 durchzuführen bzw. von diesen interpretierbar sind . Die Abfragen erlauben bevorzugt das Auffinden von freien Terminen in einem Kalender, wie z. B. für das Auffinden von freien Terminen einer bestimmten Dauer, an bestimmten Tagen, innerhalb bestimmter Zeitintervalle, etc. Es kann beispielsweise eine Cod ierung definiert sein , um alle freien halbstündigen Termine an einem Morgen während der nächsten vier Arbeitswochen zu ermitteln . Eine entsprechende Codierung kann ergänzend z. B. Limitierungen enthalten , wie beispielsweise„retourniere nicht mehr als sieben Terminmöglichkeiten". Durch die in einer maschineninterpretierbaren Sprache abgefassten Befehle können Abfragen so sehr flexibel zusammengestellt werden. Das Befehlsset B kann Quellcode, Scriptbefehle oder
binären Code umfassen, welcher von einem Compiler, Interpreter oder Prozessor auf dem Empfangenden Client C 1 , C2 , C3 direkt ausführbar ist. Dies ermöglicht das Ausführen von sehr leistungsfähigen und flexiblen Befehlen . Auch hier kann alternativ für das Befehlsset eine besondere Auszeichnungssprache vorgesehen werden. Der Befehlsset B kann Instruktionen umfassen, welche eine Businesslogik parametrisiert, also beispielsweise Instruktionen betreffend die Priorisierung von normalen Bürozeiten gegen über Randzeiten , Instruktionen betreffend die Priorisierung von Lokalitäten oder geographischen Orten, flexible (fuzzy) Parameter (wie beispielsweise Cod ierungen wie „bevorzugt in Randzeiten") etc. Auf dem betreffenden Client C 1 , C2 , C3 ergibt sich somit, dass aufgrund des übermittelten Terminrobots R die Clientmodule CA 1 , CA2, CA3 definierte Funktionen ausführen, insbesondere wie sie gemäss dem an den Terminrobot R angeschlossenen Parameterset P und Befehlsset B definiert sind . Anders als bei herkömmlichen Terminkoordinationslösun gen ermöglicht die Übermittlung des Terminrobots einen zentralen Kalenderserver in bevorzugten Ausführungsformen zu vermeiden, auf dem die Kalender aller Clients kopiert bzw. synchronisiert sein müssten . Dies ist besonders wegen der in Kalendern enthaltenen sensiblen Daten ein wesentlicher technischer Vorteil.
Die Erstellung des Parametersets P und des Befehlssets B erfolgt aufgrund einer Termin anfrage, welche ein Benutzer am Master M vorgibt bzw. eingegeben hat. Eine solche Terminanfrage umfasst Daten mit Angaben betreffend gewünschter oder erforderlicher Termin -Teilnehmer, Datumsangaben , Zeitangaben , Ortsangaben , etc.. Beispielsweise kann der Benutzer interaktiv am Master M die Eingabe „Meeting Geschäftsleitung 4 Stunden nächste 2 Wochen, bevorzugt am Nachmittag" eingeben. Der Teil „Meeting Geschäftsleitung" (Teilnehmer) sowie„4 Stunden" ( Dauer) ist dem Parameterset P zuge-
ordnet. Der Teil „nächste 4 Wochen..." ( Intervall, in welchem nach Terminen gesucht werden soll ) und„...bevorzugt am Nachmittag" ist dem Befehlsset B zugeordnet. Die für die Terminanfrage erforderlichen Termin -Teilnehmer sowie deren Clients C 1 , C2 , C3 werden beispielsweise aufgrund abgespeicherter Kontaktdaten ermittelt. Der Ort des Meetings und/oder weitere für die Terminfixierung notwendigen Angaben ergeben sich beispielsweise aus abgespeicherten Standardwerten . Kontaktdaten und/oder Standard werte können userspezifisch lokal auf dem Master M oder auf einem zentralen Server wie beispielsweise einem Internetserver abgespeichert sein . Diese zusätzlichen Angaben ( Ort, weitere Personen etc. ) sind beim Schritt der Terminanfrage optional, können also in der Kapsel enthalten sein oder nicht. Erst beim nachfolgenden Schritt einer Terminfixierung sind diese Angaben i.d. R. erforderlich.
Bei der Erstellung des Parametersets P und des Befehlssets B wird auf lokale Kalender des Clients oder alternativ auf Internetkalender (d. h. auf Kalender, welche von einem Server beispielsweise über das Internet freigegeben sind ) zugeg riffen, insbesondere auf derartige Kalender welche dem Benutzer des Masters M zugeordnet sind. Der Zugriff erfolgt hier in herkömmlicher Weise über ein API (Application Programming Interface), welches vom Betriebssystem des Master M zur Verfügung gestellt wird . Im vorgängigen Beispiel betreffend das„Meeting Geschäftsleitung" werden aus den lokalen Kalender, Internetkalender, etc. des Benutzers Terminvorschläge zusammengestellt und als Parameterset P sowie Befehlsset B an einen Terminrobot R angeschlossen , der in einer Kapsel K verpackt, einem oder mehreren Clients C 1 , C2, C3 zur Verfügung gestellt wird. Beim Erstellen des Terminrobots werden auf dem Master M (falls im Parameterset P bereits Terminzeiten enthalten sind ), in einem Kalender für provisorische Termine die entsprechenden provisorischen Termine TM eingetragen und damit vorgemerkt.
Wie oben beschrieben wird auf den Clients C 1 , C2, C3 aufgrund des zur Verfügung gestellten Terminrobots R vom betreffenden Clientmodul CA 1 , CA2, CA3 die am Terminrobot R angeschlossenen Parameterset P und Befehlsset B zugegriffen. Das Clientmodul CA 1 , CA2 , CA3 greift ferner auf lokale Kalender und/oder Internetkalender, etc. zu, welche insbesondere dem betreffenden Benutzer des Clients C 1 , C2, C3 zugeordnet sind . Der Zugriff auf den Clients C 1 , C2 , C3 zugeordnete Kalender erfolgt ebenfalls über API . Das Clientmodul CA 1 , CA2, CA3 erstellt unter Berücksichtigung des Parametersets P, des Befehlssets B sowie von lokalen Kalender, Internetkalender, etc. für den betreffenden Client C 1 , C2 , C3 provisorische Termine T1 , T2, T3 , welche in einem vom Client C 1 , C2, C3 zug reifbaren Kalender mit provisorischen Terminen eingetragen und somit vorgemerkt werden . Zur Verdeutlichung sei hier erwähnt, dass diese provisorischen Termine Einzeltermine sein können, aber auch Zeiträume, welche mehrere mögliche Terminoptionen eines Clients C 1 , C2, C3 umfassen .
Die provisorischen Termine T 1 , T2, T3 werden an den Master M übermittelt und dort ausgewertet, wobei eine Terminfixierung bzw. Termin- bzw. Kalenderbuchung bestimmt wird , welche an die Clients C 1 , C2, C3 übermittelt wird. Die Termin - bzw. Kalenderbuchung ( umfassend einen provisorischen Termin bzw. einen Termin innerhalb der vom Master erhaltenen , möglichen Zeiträume der provisorischen Termine) wird in einem definitiven Kalender (einem lokalen Kalender oder alternativ einem Internetkalender) des Masters M sowie der Clients C 1 , C2, C3 eingetragen. Das Eintragen wird bei Bedarf von den Clients C 1 , C2, C3 gegen über dem Master M ( und/oder umgekehrt) quittiert. Nach dem Eintragen der Termin- bzw. Kalenderbuchung werden auf dem Master M und den Clients C 1 , C2 , C3 die der zugehörigen Terminanfrage entsprechenden provisorischen Termine T1 , T2, T3 im Kalender mit den provisorischen Terminen deaktiviert, ausgeblendet oder gelöscht. Dies wird ermög licht durch Vergabe entsprechender I Ds bei der Terminanfrage bzw. Terminfixierung.
Die nachfolgende Tabelle zeigt provisorische Termine T1 , T2, T3 von Clients C1 , C2, C3, welche in Bezug auf provisorische Termine TM des Masters M ausgewertet werden. Die provisorischen Termine TM, T1 , T2, T3 werden wie nachfolgend dargestellt in einer Tabelle aufgeführt und diejenigen Termine ermittelt, welche sowohl für den Master M also auch die Clients C1 , C2, C3 übereinstimmen.
Termin TM T1 T2 T3
1 Mo 8-9 X x
2 Di 12-13 X x x X
3 Mi 14-16 X x
4 Fr 8-9 X x x X
Der Termin 2 Di 12-13 und der Termin 4 Fr 8-9 sind für den Master M als auch für alle Clients C1, C2, C3 als provisorische Termine eingetragen und können für eine Terminbzw. Kalenderbuchung in Frage kommen. Aufgrund einer zusätzlichen Regel, immer den frühesten Termin zu buchen, würde der Master M die Buchung des Termins 2 Di 12-13 vornehmen. In einer Variante, falls eine solche zusätzliche Regel auf dem Master M nicht konfiguriert ist, würden dem Benutzer des Masters M die beiden Termine 2 Di 12-13 und 4 Fr 8-9 zur Auswahl angezeigt. Die Terminbuchung kann selbstredend den ganzen Termin dieser einzelnen provisorischen Termine oder einen zeitlichen Teil davon beschlagen.
Wie dargestellt, erfordert die Erstellung eines Termineintrags für einen Master M und mehrere Clients C1 , C2, C3 nur die manuelle Eingabe einer Terminanfrage auf dem Master M. Anschliessend läuft das Bestimmen und Eintragen einer Termin- bzw. Kalenderbu-
chung auf dem Master M und den Clients C 1 , C2 , C3 aufgrund des Terminrobots R vollkommen automatisch ab. In diesem automatischen Prozess kann bei einem oder mehreren Schritten eine manuelle Bestätigung oder eine manuelle Anpassung durch einen Benutzer des Masters M oder einen Benutzer eines Clients C 1 , C2, C3 wahlweise vorgesehen sein . So können vor dem Versenden provisorische Termine T1 , T2, T3 auf dem betreffenden Client C 1 , C2, C3 angezeigt werden und dem Benutzer die Möglichkeit gegeben werden , provisorische Termine T1 , T2, T3 abzuändern , zu löschen etc. Bevor die Kapseln K 1 , K2, K3 bzw. die entsprechenden Terminrobots R zur Verfügung gestellt werden, kann eine manuelle Ü berprüfung, Abänderung, etc. durch den Benutzer des Masters M vorgesehen sein . Auch die Quittierung einer Termin- bzw. Kalenderbuchung durch die Clients C 1 , C2, C3 wird bevorzugt von einer manuellen Eingabe durch den Benutzer des betreffenden Clients C 1 , C2 , C3 abhängig gemacht. Solche manuellen Eingriffe sind optional, können aber beispielsweise dazu dienen , dass die Benutzer des Terminsynchronisationssystems besser informiert bleiben oder deren Privatsphäre optimal gewahrt bleibt. Solche manuellen Eingaben sind bevorzugt, um bestehenden Sicherheitsrichtlinien insbesondere betreffend den Zugriff auf und das Abspeichern von Kalendereinträgen zu entsprechen.
Figur 3 zeigt schematisch einen Client C, welcher ein Clientmodul CA mit einem Eingangsgate EG und einem Ausgangsgate AG aufweist. Das Eingangsgate EG ist vorgesehen, eine Ü berprüfung einer Kapsel K oder eines Robots R vorzunehmen, welche oder welcher dem Client C verfügbar gemacht wurde. Das Ausgangsgate AG ist vorgesehen, eine Ü berprüfung von provisorischen Terminen T vorzunehmen, welche für die Übermittlung an einen Master M vorgesehen sind. In einer Variante ist das Eingangsgate EG und das Ausgangsgate AG im Clientmodul CA enthalten .
Das Eingangsgate EG ist derart ausgeführt, dass in einem ersten Schritt beim Empfang einer Kapsel K oder eines Robots R Absender, Hersteller sowie Sicherheitselemente überprüft werden , die bevorzugt mindestens teilweise im Kapselheader enthalten sind . Dazu führt das Eingangsgate EG einen Vergleich entsprechender Daten aus und führt entsprechende Kontrollfunktionen aus. Ist diese Ü berprüfung erfolgreich , dann überprüft das Eingangsgate EG in einem zweiten Schritt das Parameterset P und das Befehlset B gemäss einer hier bevorzugten dreistufigen Sicherheitsrichtlinie. In einer ersten Sicherheitsstufe F 1 wird der Parameterset P und der Befehlset B nicht weiter überprüft und dem Clientmodul CA unmittelbar zur weiteren Verarbeitung freigegeben . In einer zweiten Sicherheitsstufe F2 wird für ausgewählte Absender oder Hersteller des Terminrobot R überprüft, ob durch das Parameterset P oder das Befehlset B unzulässige Zugriffe auf Kalenderdaten erfolgen. Die ausgewählten Absender betreffen Absender, die dem Benutzer des Client C nicht bekannt sind, also nicht in einer Kontaktdatenbank des Client C enthalten sind. Die ausgewählten Absender können auch Absender betreffen, welche in einer Kontaktda tenbank des Client C entsprechend markiert sind. In einer dritten Sicherheitsstufe F3 wird für alle Absender des Terminrobots R resp. der Kapsel K überprüft, ob durch das Parameterset P oder das Befehlset B unzulässige Zugriffe auf Kalenderdaten erfolgen. Die Sicherheitsstufen F 1 , F2 , F3 können vom Benutzer des Client C konfiguriert werden .
Die Definition eines unzulässigen Zugriffs auf Kalenderdaten basiert auf Standardwerten ( Defaultwerten ), welche der Benutzer des Clients C nach eigenen Bedürfnissen einstellen kann. Der Benutzer des Clients C kann dadurch definieren, dass Zugriffe auf Kalenderdaten über einen längeren Zeitraum als z. B. die nächsten acht Wochen unzulässig sind. Der Benutzer des Clients C kann auch definieren, dass Terminanfragen, welche eine grosse Anzahl wie z. B. mehr als zwanzig Resultate ergeben könnten, unzulässig sind . In besonderen Ausführungsvarianten der Erfindung können solche Einschränkungen bzw. Limitie-
rungen auch direkt im entsprechenden Code vorgesehen werden , um hier unzulässige Abfragen durch einen Terminrobot zu unterbinden.
Wird auf dem Client C ein unzulässiger Zugriff festgestellt, dann wird dem Benutzer des Clients C eine Meldung angezeigt und die Möglichkeit gegeben, den unzulässigen Zugriff trotzdem auszuführen , den Zugriff zu ändern und einzuschränken oder diesen Zugriff abzulehnen .
Das Ausgangsgate AG ist derart ausgeführt, dass eine Ü berprüfung der ermittelten provisorischen Termine T vorgenommen wird. Die Ü berprüfung erfolgt hier gleichfalls bevorzugt gemäss einer dreistufigen Sicherheitsrichtlinie. In einer ersten Sicherheitsstufe E 1 werden die provisorischen Termine nicht weiter überprüft und zur Ü bermittlung an den betreffenden Master M unmittelbar freigegeben. In einer zweiten Sicherheitsstufe E2 werden die provisorischen Termine für ausgewählte Master M überprüft. Die ausgewählten Master M sind gemäss Standardwerten definiert oder gemäss Vorgaben eines Benutzers des Clients C. An einen Master M , welcher beispielsweise noch nicht bekannt ist, werden provisorische Termine T nur nach einer einen Benutzereing riff ermög lichende Überprüfung übermittelt. In einer dritten Sicherheitsstufe E3 wird für alle Master M einer Überprüfung der provisorischen Termine vorgenommen .
Eine Überprüfung von provisorischen Terminen T basiert wiederum auf Standardwerten , welche der Benutzer des Clients C nach eigenen Vorgaben einstellen kann . Der Benutzer des Clients C kann definieren , dass nur eine maximale Anzahl von z. B. acht provisorischen Terminen an einen Master M übermittelt werden können. Für ausgewählte Master M kann der Benutzer definieren, dass nur provisorische Termine übermittelt werden , welche beispielsweise einen bestimmten Ort betreffen.
Falls die Überprüfung der provisorischen Termine T fehlschlägt, dann wird dies dem Benutzer des Clients C angezeigt und die Mög lichkeit gegeben, vor einer Freigabe von provisorischen Terminen diese manuell zu löschen oder zu ändern.
Figur 4 zeigt eine grafische Benutzerschnittstelle G 1 zur Anzeige und Eingabe von Terminen auf dem Master M . Die grafische Benutzerschnittstelle G 1 ist bevorzugt für einen berührungsempfindlichen Bildschirm wie einem Touchscreen des Master M vorgesehen. Die Anzeigen der entsprechenden Clients sind entsprechend ausgestaltet.
Auf der grafischen Benutzerschnittstelle G 1 ist hier eine Wochenansicht dargestellt, im konkreten Beispiel die Kalenderwoche 37 ( KW37 ) im Jahr 20 1 2. Die grafische Benutzerschnittstelle G 1 weist eine Titelzeile Z 1 mit der Angabe der betreffenden Kalenderwoche, sieben in vier Zeilen und zwei Kolonnen angeord nete Felder für die Wochentage, ein in der vierten Zeile der Wochentage angeord netes Feld für eine Monatsansicht Q 1 und eine Fusszeile Z2 mit Steuerelementen auf.
Für jeden Wochentag sind mehrere Kalender 1 , 2, 3 , 4, 5 gleichzeitig dargestellt, in Figur 4 sind die mehreren Kalender 1 , 2, 3 , 4, 5 in den jeweiligen Wochentagen als aufeinanderfolgende Zeilen dargestellt. Die Besonderheit der Darstellung liegt darin, dass pro Wochentag in neuartiger Weise eine Kalendermatrix angezeigt wird , wie sie weiter unten genauer beschrieben ist. Die Termine der betreffenden Kalender 1 , 2, 3 , 4, 5 sind bevorzugt in mehren lokalen Kalendern des Masters M abgespeichert. Die mehreren Kalender der Kalendermatrix werden in unterschiedlicher Weise dargestellt, indem bspw. unterschiedliche Schraffuren, Farben, etc. verwendet werden . Die Längen der als horizontale Zeilen dargestellten Kalender 1 , 2, 3 , 4, 5 entsprechen einem Zeitintervall wie den Bürozeiten , den erweiterten Bürozeiten , etc. des betreffenden Tages. Die Bürozeiten können von beispielsweise 8- 1 7 U hr definiert sein, während die erweiterten Bürozeiten von bei-
spielsweise 7- 1 9 U hr definiert sind . Die Längen der horizontalen Zeilen der dargestellten Kalender 1 , 2, 3 , 4, 5 können einem anderen Zeitintervall entsprechen. Die Terminein tragungen in jedem dieser Kalender 1 , 2, 3 , 4, 5 der Kalendermatrix werden chronologisch und proportional innerhalb der jeweiligen Kalenderzeile dargestellt, so dass die Kalender bezüglich der Zeitachse aufeinander ausgerichtet sind.
Eine wesentliche Besonderheit der hier gezeigten Ausführungsform liegt darin , dass in jeder Tages- Kalendermatrix ein separater Kalender für definitive und für provisorische Termine vorgesehen ist. Diese ermög licht die effiziente, automatisierte und (durch den Nutzer überhaupt wahrnehmbare) übersichtliche automatisierte Schreibvorgänge der jeweiligen Terminrobots. Der Terminrobot kann einen vom Master identifizierten möglichen Termin mittels einer Terminbuchung in den definitiven oder aber auch in den Kalender für provisorische Termine übergeben oder speichern ( Master- bzw. Client-seitig ). Für das Userinterface gemäss dieser Ausführungsvariante ist diese Aufteilung in zwei separierte Kalender ein sehr wesentlicher Vorteil der Erfindung.
Ein erster Kalender 1 ist somit für die Anzeige und Eingabe von gespeicherten , definitiven Terminen des Benutzers des Masters M vorgesehen . Um einen Termin von einer Stunde einzugeben, zieht der Benutzer bevorzugt ein Steuerfeld 1 h der Fusszeile 1 mittels Ziehen und Loslassen (drag-and-drop) auf die betreffenden Stelle des angezeigten ersten Kalenders 1 . Daraufhin öffnet sich ein Dialog , so dass Detail -Terminangaben wie Titel, Ort, etc. vornehmbar sind. Bei einer längeren Berührung (ohne Bewegung ) von z. B. mehr als einer Sekunde kann der entsprechende Standardtermin modifiziert werden (z. B. durch „Kundenmeeting im Sitzungszimmer" ) und vorzugsweise unterstützt durch einen sog. Wizzard , welcher die Eingabe des Parametersets P und des Befehlssets B vorsieht, kann dann ( nach Abschluss des Wizzards) mittels drag-and-drop ein Termin sehr flexibel und effizient erstellt werden . U m einen Termin im ersten Kalender 1 zu modifizieren , berührt
der Benutzer den betreffenden Termin, wobei sich ein Fenster öffnet, um Termineinträge wie Zeit, Ort, etc. zu modifizieren . Um einen Termin zu löschen , zieht der Benutzer den betreffenden Termin beispielsweise aus der Kalenderdarstellung heraus auf eine Löschtaste. Termine können in einer anderen Weise verwaltet werden . Die Erstellung von Terminen mittels drag-and -drop mittels Steuerfeldern in der Fusszeile ist jedoch von Vorteil.
Ein in Figur 4 dargestellter separater zweiter Kalender 2 in der jeweiligen Tages- Kalendermatrix ist für die Anzeige und Eingabe von provisorischen Terminen des Benutzers des Masters M vorgesehen. Die provisorischen Termine können unterteilt werden in provisorische Termine, für welche noch eine Terminumfrage in Bearbeitung ist und in provisorische Termine, für welche eine neue Terminumfrage gestartet werden soll . Zur Unterscheidung werden provisorische Termine die zu einer anhängigen Terminumfrage gehören beispielsweise gestrichelt oder in einer ersten Farbe dargestellt, während provisorische Termine die zu einer neuen Terminumfrage gehören beispielsweise durchgezogen oder in einer zweiten Farbe dargestellt werden. Im in Figur 4 dargestellten Beispiel sind am Montag und Dienstag je ein provisorischer Termin eingetragen , welche zu einer anhängigen Terminumfrage gehören , während am M ittwoch und Freitag provisorische Termine eingetragen sind, welche zu einer neuen Terminumfrage gehören. U m der Terminumfrage einen weiteren provisorischen Termin mit der Zeitdauer von 1 Stunde hinzuzufügen, kann wie in Figur 4 schematisch dargestellt beispielsweise das Steuerelement mit der Bezeichnung„1 h" aus der Fusszeile Z2 an die betreffende Stelle des zweiten Kalenders 2 gezogen und dort losgelassen werden. Im in Figur 4 dargestellten Beispiel wird in dieser Weise zum betreffenden Zeitpunkt ein provisorischer Termin mit der Zeitdauer von 1 Stunde für den Samstag erfasst. Die Terminerfassung erfolgt analog zu dem für den ersten Kalender 1 beschriebenen Vorgang.
Der in Figur 4 dargestellte dritte Kalender 3 , der vierte Kalender 4 und der fünfte Kalender 5 enthalten Termine, welche beispielsweise von einem anderen Clientkalender oder auch einem Internetkalender abonniert sind. Diese Termine können beispielsweise von Arbeitskollegen , Familienmitgliedern , Vereinen, Konzertve ran stalter, etc. bezogen und auf der grafischen Benutzerschnittstelle G 1 dargestellt werden . So können im dritten Kalender 3 beispielsweise die Termine eines Arbeitskollegen , im vierten Kalender 4 die Termine des Lebenspartners und im fünften Kalender 5 die Termine eines Vortragszyklus dargestellt sein . Durch die gleichzeitige Darstellung der Kalender 1 , 2, 3 , 4, 5 ist der Benutzer sofort informiert, zu welchen Zeiten noch weitere Termine eingetragen werden könnten . Beispielsweise bei einer kurzfristigen Absage eines im ersten Kalender 1 eingetragenen Termins ist der Benutzer damit sofort informiert, ob stattdessen die Teilnahme an einem Vortragszyklus, an einem Gruppen meeting, etc. in Frage kommt.
Diese gleichzeitige balkenartige mit Segmenteintragungen für Termine und zeitlich aufeinander abgestimmte Darstellung eines ersten Kalenders 1 mit definitiven Terminen, eines separaten zweiten Kalenders 2 mit provisorischen Terminen und mit einer Anzahl n von abonnierten (eingebundenen ) Fremd kalendern bildet eine Kalendermatrix, die durch zusätzliche angezeigte Kalender ergänzt sein kann. In jedem Kalender können eine Vielzahl von einzelnen Terminen erfasst sein . Die jeweiligen Kalender 1 -5 sind so aufeinander ausgerichtet, dass sie chronologisch übereinstimmen und ein direkter optischer Vergleich ermög licht ist. Innerhalb jeder Kalendermatrix wird vorzugsweise eine wählbare Reihen folge und/oder ein Scroll- Mechanismus vorgesehen, wobei der erste und der zweite Kalender 1 , 2 bevorzugt fest eingeblendet bleiben . Diese Kalendermatrix erlaubt hochdynamische und trotzdem durch einen Benutzer optisch erkennbare automatisierte Schreibvorgänge innerhalb der Kalender durch die jeweiligen Terminrobots. Die Kalendermatrizen sind hier jeweils als Tages-Kalendermatrix gezeigt. Entsprechend kann eine Einzeltag -, eine Monats-, eine Wochen- oder eine Perioden-Kalendermatrix vorgesehen werden.
Wichtig ist hier, dass jeder Kalender separat darstellbar ist, dass Schreibrechte pro Kalender klar definierbar sind und dass der Benutzer insbesondere seinen ( lokalen ) ersten und zweiten Kalender 1 , 2 verfügbar hat.
M it einer solchen grafischen Benutzerschnittstelle G 1 hat der Benutzer des Master M eine rasch erfassbare, vollständige Übersicht über alle Termine, welche beim Erstellen einer Terminumfrage berücksichtigt werden müssen . Statt fünf Kalender 1 , 2, 3 , 4, 5 können auch mehr oder weniger Kalender gleichzeitig dargestellt werden. Vorzugsweise ist zumindest der erste Kalender 1 mit den Terminen des Benutzers sowie der zweite Kalender 2 mit den provisorischen Terminen des Benutzers gleichzeitig (fest) dargestellt.
Die grafische Benutzerschnittstelle G 1 ist ferner beispielsweise auch dazu vorgesehen, dass Steuerelemente aus der Fusszeile Z2 auf einen einzelnen Tag der angezeigten Woche, auf in der Monatsdarstellung Q 1 angezeigte Kalenderwochen , den angezeigten Monat, etc. gezogen werden können , um eine entsprechende Terminumfrage zu starten. Beispielsweise kann ein in der Fusszeile Z2 mit dem Label F 1 markiertes Steuerelement dafür vorgesehen sein , eine Terminumfrage für ein spontanes Treffen nach der Arbeit zu starten , wobei eine bestimmte Teilnehmergruppe, beispielsweise einer Gruppe von Freunden, durch Ziehen und Loslassen des Steuerelements auf ein Datum, eine Zeit, etc. in die Terminumfrage einbezogen wird, wobei ein Robot R erstellt und betreffenden Clients C 1 , C2 , C3 verfügbar gemacht wird. Stattdessen kann das Steuerelement mit dem Label F 1 dafür vorgesehen sein , durch Ziehen und Loslassen des Steuerelements auf eine in der Monatsansicht dargestellten Kalenderwoche für die betreffende Kalenderwoche eine Terminumfrage für eine Besprechung von 2 Stunden zu starten , wobei ein Robot R erstellt und betreffenden Clients C 1 , C2, C3 verfüg bar gemacht wird , um mit M itgliedern einer Arbeitsgruppe eine Termin - bzw. Kalenderbuchung zu vereinbaren. Die Eigenschaften der in der Fusszeile Z2 dargestellten Elemente lassen sich beispielsweise mit dem mit
dem Label # bezeichneten Steuerelement einstellen , wobei sich bei Berührung dieses Steuerelements eine Maske öffnet, um insbesondere Terminteilnehmer und Zeitdauer zu definieren. Ferner weist die Fusszeile Z2 ein Steuerelement auf, welches mit dem Label = bezeichnet ist und dafür vorgesehen ist, eine wiederkehrende Terminumfrage schnell zu starten , also beispielsweise für eine Arbeitsgruppe eine Terminumfrage für den nächstmöglichen Besprechungstermin von 30 M inuten , beispielsweise um ein dringendes Problem, welches die Arbeitsgruppe betrifft, rasch untereinander absprechen zu können.
Aufgrund der gestarteten Terminumfrage werden auf dem Master M bzw. durch die Masterapplikation ein Parameterset P sowie ein Befehlsset B erstellt und an einen Terminrobot R angeschlossen . Bevor diese wie oben beschrieben einem oder mehreren Clients C 1 , C2, C3 zur Verfügung gestellt werden, wird je nach Einstellungen oder Vorgaben gegebenenfalls eine (ganz oder teilweise verschlüsselte) Kapsel K gebildet. Wie oben beschrieben, wird aufgrund des Terminrobots R und dem daran angeschlossenem Parameterset P sowie Befehlset B in einer Variante vollkommen automatisch im Zusammen wirken mit auf den Clients C 1 , C2, C3 definierten Kalender eine der Terminumfrage entsprechende Termin- bzw. Kalenderbuchung vorgenommen und in betreffenden Kalender des Masters M und der Clients C 1 , C2 , C3 eingetragen. Während dem Ermitteln der Termin- bzw. Kalenderbuchung für die Terminumfrage, werden bevorzugt temporär provisorische Termine in den betreffenden Kalender des Masterclients M sowie der Clients C 1 , C2, C3 eingetragen.
Verschiedene manuelle Schritte können beim Ermitteln der der Terminumfrage entsprechenden Termin- bzw. Kalenderbuchung vorgesehen sein, insbesondere um Benutzer aufgrund von zu bestätigenden Meldungen zu informieren , Benutzer die Möglichkeit für manuelle Anpassungen zu bieten , Terminumfragen kurzzeitig zu ändern, etc.
Nachdem ein Terminrobot R sowie die daran angeschlossenen Parameterset P sowie Befehlsset B auf einem Client C 1 , C2 , C3 ausgewertet und somit provisorische Termine T 1 , T2, T3 bestimmt sind , werden die provisorischen Termine T 1 , T2, T3 dem Benutzer beispielsweise wie in Figur 5 schematisch dargestellt in einer grafischen Benutzerschnittstelle G2 zur Anzeige von provisorischen Terminen dargestellt, welche Benutzerschnittstelle G2 ähnlich zur oben beschriebenen Benutzerschnittstelle G 1 zur Eingabe einer Terminumfrage auf einem Master M aufgebaut ist. Als Alternative zu dieser Benutzerschnittstelle G2 können die Steuerelemente von Client C 1 , C2, C3 und Master M in einer einheitlichen Fusszeile zusammengefasst sein ( Fusszeile von Master und Client sind diesfalls übereinstimmend ). Wiederum werden für die Wochentage die Termine des Benutzers in einem ersten Kalender 1 , die provisorischen Termine in einem Kalender 2 mit den provisorischen Terminen , sowie weitere lokale oder entfernte Kalender 3 , 4, 5 angezeigt. Bevor der Benutzer die provisorischen Termine bestätigt, werden diese im Kalender 2 mit den provisorischen Terminen beispielsweise blinkend oder mit einer anderen Markierung dargestellt. Wie in Figur 5 schematisch dargestellt, sind in der Fusszeile Z2 andere Steuerelemente angeordnet als die bei der im Zusammenhang mit der Eingabe einer Terminumfrage auf einem Master M beschriebenen Steuerelemente. Die Fusszeile Z2 der Benutzerschnittstelle G2 zur Anzeige von provisorischen Terminen umfasst ein Steuerelement V zur Bestätigung einzelner oder mehrerer provisorischer Termine gemäss einer vordefinierten Einstellung , ein Steuerelement V V zu r Bestätigung aller provisorischen Termine, Steuerelemen te B 1 , B2 für eine ben utzerspezifische Bestätig ung von provisorischen Terminen , beispielsweise einer Bestätigung aller provisorischen Termine welche nicht mit einem Termin des Kalenders K 1 mit darin enthaltenen definitiven Terminen kollidieren (welcher ggf. manuell erfasst oder bei der Ermittlung der provisorischen Termine nicht berücksichtigt wurde) oder eine Bestätigung aller provisorischen Termine welche nicht mit dem dritten Kalender 3 oder vierten Kalender 4 kollidieren ( im in Figur 5 gezeigten Beispiel ist dies kein Termin ). Ferner ist ein Steuerelement # vorgesehen , um Benutzereinstellungen vor-
zunehmen, beispielsweise zur Festlegung der benutzerspezifischen Bestätig ungen B 1 , B2, und ein Steuerelement =, um die ermittelten provisorischen Termine in einem Standardablauf zu akzeptieren , wobei der Standardablauf konfiguriert sein kann, bestimmte provisorische Termine, wie z. B. Termine an einem Wochenende, zu verwerfen.
Statt einer Monatsansicht Q 1 kann an der entsprechenden Stelle der grafischen Benutzerschnittstelle G 1 , G2 eine Funktionsfläche W 1 vorgesehen sein . In der hier bevorzugten Variante sind der Kalender 1 mit den Terminen eines Benutzer und der Kalender 2 mit den provisorischen Terminen übereinander dargestellt und durch farbliche oder andere grafische Unterscheidungsmerkmale dargestellt.
In einer bevorzugten Ausgestaltung erfolgt die Auswertung des Parameterset P sowie Befehlsset B in Bezug auf die Kalender des Benutzers eines Clients C 1 , C2 , C3 derart, dass keine Kollision zwischen dem Kalender 1 mit den Terminen des Benutzers und dem Kalender 2 mit den provisorischen Terminen besteht. In einer weiteren Variante wird beim Bestimmen der provisorischen Termine eine allfällige Reise zwischen die Termine betreffenden geographischen Orten automatisch berücksichtigt.
Die Datenübermittlung zwischen dem Master M und den Clients C 1 , C2, C3 erfolgt über ein Datennetz wie das TCP/I P basierte Internet. In einer möglichen Ausgestaltung basiert die Datenübertragung auf einem Extensible Messaging and Presence Protocol XM PP gemäss einem von der I ETF in RFC 61 20-61 22 sowie 3922, 3923 veröffentlichtem Internetstandard für XM L Routing (XM L: Extensible Markup Language). Der Robot R, der daran angeschlossenen Parameterset P und Befehlset B, ggf. die Kapsel K, provisorische Termine T1 , T2, T3 welche von den Clients C 1 , C2 , C3 an den Master M übermittelt werden sowie eine Termin- bzw. Kalenderbuchung sind bevorzugt in einem iCal bzw. XM L Datenformat strukturiert und abgefasst.
In einer weiteren Variante ist das Mastermod ul M und/oder eines oder mehrere Clientmodule C 1 , C2 , C3 als auf einem Personalcomputer ( PC) , Notebook, etc. installierbaren und ablauffähige Applikation oder als ein in ein solches Gerät einsetzbaren Hardwarebaustein oder als eine M ischung dieser beiden Varianten ausgeführt.
Weitere besondere Ausführungsformen ergeben sich aus einer oder mehreren der nachfolgend dargestellten Ausführungsformen.
In einer bevorzugten Variante des Systems für einen Terminrobot R sind das Mastermodul MA resp. das eine oder die mehreren Clientmodule CA 1 , CA2, CA3 vorgesehen , auf Kalendereinträge in einem dem Master- MA bzw. Clientmodul CA 1 , CA2, CA3 zugeordneten lokalen Speicher zuzugreifen und/oder auf Kalendereinträge in einem über ein Datennetz zugreifbaren Speicher zuzugreifen .
In einer bevorzugten Variante des Systems für einen Terminrobot R sind das Mastermodul MA resp. das eine oder die mehreren Clientmodule CA 1 , CA2, CA3 vorgesehen, das am Terminrobot R angeschlossene Parameterset P und Befehlsset B, d ie Gruppen mit provisorischen Kalenderterminen T 1 , T2, T3 und/oder einen ermittelten Kalendereintrag in einem Datenformat zu erstellen , das einen oder mehrere Einträge in einem iCalendar Datenformat umfasst.
In einer Variante des Systems für einen Terminrobot R das sind das Mastermod ul MA resp. das eine oder die mehreren Clientmodule CA 1 , CA2, CA3 vorgesehen, Daten zwischen einem Mastermod ul MA und dem einen oder mehreren Clientmodulen CA1 , CA2, CA3 gemäss einem Extensible Messaging and Presence Protocol auszutauschen.
I n einer bevorzugten Variante des Systems für einen Terminrobot R sind das Mastermod ul MA resp. das eine oder die mehreren Clientmodule CA 1 , CA2, CA3 vorgesehen, ein
am Terminrobot R angeschlossenes Parameterset P zu erstellen und übermitteln resp. entgegenzunehmen welches einen oder mehrere der folgenden Parameter umfasst: Kalenderdatum, Start- und Endzeit, Adressinformationen von Terminteilnehmern , Termin treffpunkt, Termintitel . In einer bevorzugten Variante des Verfahrens für einen Terminrobot wird vom Mastermodul MA resp. von dem einen oder den mehreren Clientmodulen CA 1 , CA2, CA3 auf Kalendereinträge in einem dem Master- MA bzw. Clientmodul CA 1 , CA2, CA3 zugeordneten lokalen Speicher zugegriffen und/oder auf Kalendereinträge in einem über ein Datennetz zug reifbaren Speicher zugeg riffen. In einer bevorzugten Variante des Verfahrens für einen Terminrobot R werden vom Mastermodul MA resp. von dem einen oder den mehreren Clientmodulen CA 1 , CA2, CA3 ein Terminrobot mit angeschlossenem Parameterset P, Gruppen mit provisorischen Kalen derterminen und/oder ermittelte Kalenderbuchungen in einem Datenformat erstellt, das einen oder mehrere Einträge in einem iCalendar Datenformat umfasst. In einer Variante des Verfahrens für einen Terminrobot R werden zwischen dem Mastermodul MA und dem einen oder den mehreren Clientmodulen CA 1 , CA2, CA3 Daten gemäss einem Extensible Messaging and Presence Protocol ausgetauscht.
In einer bevorzugten Variante des Verfahrens für einen Terminrobot R werden vom Mastermodul MA resp. von dem einen oder den mehreren Clientmodulen CA 1 , CA2, CA3 ein am Terminrobot angeschlossenes Parameterset P erstellt und übermittelt resp. entgegen genommen, welches einen oder mehrere der folgenden Parameter umfasst: Kalenderdatum, Start- und Endzeit, Adressinformationen von Terminteilnehmern , Termintreffpunkt, Termintitel.
In einer bevorzugten Variante eines Client für einen Terminrobot ist ein Eingangsgate EG vorgesehen, einen Terminrobot R mit angeschlossenem Parameterset P und Befehlset B entgegenzunehmen , die in einer Kapsel K gesichert sind , und die Sicherheitselemente 1 1 , 1 2, 1 3 zu überprüfen und das Parameterset B sowie das Befehlset B auf das Einhalten einer Sicherheitsrichtlinie E 1 , E2, E3 zu überprüfen.
In einer bevorzugten Variante eines Client für einen Terminrobot ist ein Ausgangsgate vorgesehen, eine Gruppe mit provisorischen Terminen auf das Einhalten einer Sicherheitsrichtlinie zu überprüfen.