EP3022692A1

EP3022692A1 - Appointment robot

Info

Publication number: EP3022692A1
Application number: EP14739806.9A
Authority: EP
Inventors: Rudolf A. Rentsch
Original assignee: Speate AG
Current assignee: Speate AG
Priority date: 2013-07-15
Filing date: 2014-07-15
Publication date: 2016-05-25
Also published as: CH708300A2; US20160155094A1; WO2015007700A1

Abstract

The invention relates to a system for an appointment robot (R), the system comprising a master module (MA) and a plurality of client modules (CA1, CA2, CA3). The master module (MA) is provided for the purpose of accessing diary entries and creating an appointment robot (R) with a parameter set (P) and command set (B) connected thereto and using a data network to transmit said appointment robot to one or more client modules (CA1, CA2, CA3), and receiving groups or lists of provisional appointment entries (T1, T2, T3) from each of the client modules (CA1, CA2, CA3) and evaluating said groups or lists in order to ascertain one or more diary bookings. The client modules (CA1, CA2, CA3) are provided for the purpose of each receiving an appointment robot (R) with parameter set (P) and command set (B) connected thereto from a master module (MA) and accessing diary entries and creating a group of provisional appointments (T1, T2, T3) and transmitting said group to the master module (MA).

Description

appointment Robot

The present invention relates to a system, a method and devices for a term robots according to the Oberbeg refen of the independent claims.

Various systems for appointment recording, appointment management and appointment comparison are known today, often under the term organizer or similar names. Most of these systems are for pure appointment recording and management and, as far as they are concerned with electronic technologies, can be grouped under the umbrella of Electronic Agenda. Corresponding known solutions require complex interactions of operators and are therefore not only very complicated in complex environments, but hardly suitable. Although the present invention pursues completely different approaches, the relevant background technologies should be briefly discussed.

For example, with the Mac OS X ™ operating system, the Calendar program (known as iCal or Calendar, depending on the version) is shipped. The program supports various calendars for appointments and tasks. To display the calendars, a calendar can be assigned to each calendar. Each own calendar can be published via a server (eg WebDAV). Other published calendars (holidays, cinema program, etc.) can be subscribed. Group calendars, where a group of people could share calendar entries for reading and writing to synchronize appointments, are not supported. RFC 5545 (Request for Comment) The I ETF (Internet Engineering Task Force) defines an iCalendar data format to provide calendar information such as: For example, events, tasks, manual entries, availability information. The iCalendar format is suitable as an exchange format between applications and systems and can be transmitted via data networks. Tasks such as appointment requests, appointment responses, appointment changes or appointment cancellations are supported. Furthermore, the use of the data format in the sense of inquiries and answers regarding free or busy times is possible.

Electronic agendas are to be distinguished from systems that do not relate to the actual appointment recording, appointment confirmation or appointment fixation, but to the preceding process, here appointment synchronization or appointment coordination. Such systems are still poorly used today. One of these systems is Doodle ™, which is intended to find a suitable date for several people. The persons are divided into an appointment coordinator and several (potential) appointment participants. The appointment coordinator manually records several appointment proposals according to their own agenda and invites several appointment participants to agree to those appointment suggestions by manual entry, which are suitable for their own agenda. The appointment coordinator monitors whether the invited appointment participants have commented on the appointment proposals and transmits invitation reminders, which can also be automatically sent by the system to those who have not yet commented on the appointment proposals. After all appointment participants have made their inputs, a manual evaluation by the appointment coordinator is required, and in unfavorable constellation, if z. B. several appointments was approved equally often or no appointment was approved by all appointment participants, additional clarifications or a new appointment survey are required. Finally - again by handwork - an appointment confirmation to the appointment participants resp. a date fixation.

Today's electronic agendas make it possible to record appointments for a specific user, to store, retrieve and modify them. As a rule, it is also possible to access electronic agendas of other users, to view them (especially within company units) and possibly to detect collisions with these appointments manually and to avoid them when registering appointments. On the one hand, such systems assume that the multiple users use the same system and allow mutual insight into the electronic agendas via suitable hardware or software settings. The appointment recording and synchronization also takes place here manually and requires considerable manpower.

Especially when an appointment synchronization is to take place quickly and between several people, conventional systems fail because the synchronization effort increases non-linearly and such semi-automated processes against a purely manual solution hardly bring more benefits or more hindering. The acquisition and administration effort in such systems leads to a disproportionate effort. Completely inadequate are known solutions, if a fast appointment synchronization would be required within hours or even minutes. Here the necessary manual check by the involved persons makes a solution impossible. Often several feedback loops are required until an appointment synchronization can even be completed successfully.

Another hitherto unresolved problem is the fact that the known appointment coordination systems require relatively large user interfaces in order to be able to make the desired appointment comparisons. Even better ones of these systems It is not necessary to simultaneously synchronize appointments with existing appointments for longer periods of time.

It is an object of the invention to overcome at least some of the above-mentioned disadvantages of the prior art and to allow fast and highly efficient automated appointment synchronization.

This object is solved by the features of the independent claims.

The inventive system for a term robot comprises a master module and one or more client modules. The master module is intended to ripen on calendar entries and to create a deadline robot with attached parameter set and command set and to transmit via a data network to one or more client modules and to receive and evaluate groups or lists of provisional appointment entries from the client modules to find one or more calendar bookings. The one or more client modules are provided to receive a terminating robot with attached parameter set and command set from a master module and to access calendar entries and to create a group or list of provisional appointments and to transmit them to the master module. Due to the appointment robot, the system is able to determine and make an appointment or calendar booking completely automatically.

The invention is based on the idea of an appointment robot, which is preferably secured in a capsule in order to comply with security guidelines. The appointment robot is sent peer-to-peer between the participating modules, which are preferably installed in mobile terminals such as smartphones, etc. To transmit the terminating robot data networks are used, which are available at the mobile terminals each are . The appointment robot can be created quickly and made available to the participating modules as quickly as possible. In addition, the evaluation of the terminator robot is flexible and highly efficient due to the attached set of parameters and command set to perform a synchronization of appointments between the modules involved and to obtain a desired synchronization of appointments in calender, which are accessible from the modules involved.

In one embodiment, the master module is provided to transmit a determined calendar entry to one or more client modules and to receive an acknowledgment from the one or more client modules and to save the calendar entry. The master module is able to transmit a (definitive or optional or provisional) calendar entry and to accept the corresponding acknowledgment. The calendar entry can be entered on the master before or after the acknowledgment in a calendar.

In one embodiment, the one or more client modules are provided to receive a calendar entry from a master module and to save the calendar entry and to transmit an acknowledgment to the master module ul. The one or more client modules are capable of transmitting an acknowledgment to the master module due to the receipt of a calendar entry. The calendar booking resp. the corresponding calendar date is entered on the respective client in a calendar.

In one embodiment, the Mastermod ul. the one or more client modules provide access to calendar entries stored in a plurality of calendar databases, the calendar databases having at least one calendar database of a user assigned to the master or client module and a calendar data item. bank for storing provisional appointments. Several calendars can be considered for determining an appointment or calendar booking. If it is spoken in this context that the stored calendar entries are accessed, this is not to be understood as meaning that their content must be accessible. Rather, in the context of the invention, the advantage is gen utzt that the client module (by means of knowledge of the stored calendar entries) only the free appointment options (quasi the blanks) are read out and transmitted.

The invention is based on the idea that a first calendar is provided to enter and display the calendar data of the user. Furthermore, a second calendar is provided to enter and display provisional appointments. Due to the division into the fixed user appointments and the provisional appointments, on the one hand there is the possibility of a user interface that is clear and comfortable for the user. Furthermore, by storing fixed user appointments in a first calendar and storing provisional appointments in a second calendar, the synchronization and synchronization of appointments by the system can be automatic, efficient, precise and reliable.

The invention is based on the idea that calendars relating to the user, that is to say at least the first calendar with the fixed appointments of the user, the second calendar with the provisional calendars and further subscribed calendars are displayed in a calendar matrix. The calendar matrix allows efficient management of appointments by the user. Several calendars are arranged line by line, whereby the individual calendars are temporally aligned. A matrix element of the calendar matrix is thus defined by an identification of a calendar as well as a time, a time interval, etc. The timing of the individual calendar lines allows a direct comparison of the appointments. Through a daily, weekly, monthly ment, etc., the user can quickly check fixed and provisional appointments. Calendars have read and / or write permission. The entry of an appointment in a calendar with write permission can be done quickly and clearly with drag-and-drop, whereby the user can account for the various calendars at the same time because of the presentation as a calendar matrix when entering. This allows the rapid creation of an appointment, which is to be used for an appointment synchronization with other participants of the system. It also makes it possible to quickly check and, if necessary, confirm one or more provisional appointments which have been entered on the basis of a terminating robot made available to the relevant mobile terminal of the user.

In one embodiment, the Mastermod ul. the one or more client modules provide for accessing calendar entries in a local memory associated with the master or client module and / or for accessing calendar entries in a memory accessible via a data network. Access to the local memory can be done in a variant via a calendar module, which manages a calendar memory. Access to memory accessible via a data network may relate to a calendar published on an Internet server.

In one embodiment, the Mastermod ul. the one or more client modules provide for creating the set of parameters and command set associated with the terminating robot, the provisional calendar appointment schedules, and / or an established calendar entry in a data format comprising one or more entries in an iCalendar data format. This improves compatibility with existing calendars in particular. In one embodiment, the Mastermod ul. the one or more client modules provided to exchange data between a master module according to an Extensible Messa and Presence Protocol. As a result, the data transmission can be based on a robust data transmission protocol that has been tested and widely used. Corresponding communication protocols can be used in other embodiments.

In one embodiment, the Mastermod ul. the one or more client modules provided, data such as a particular appointment robot with attached parameter set and command set, provisional appointment entries, etc. before transmission in a capsule comprising a hash, an electronic signature and / or an electronic cal encryption to secure or secure Check capsule upon receipt. Securing the term robot in a capsule ensures data integrity.

In one embodiment, the Mastermod ul. the one or more client modules provided to create a parameter set connected to the terminating robot and transmit or. which includes one or more of the following parameters: calendar date, start and end time, address information of appointment participants, meeting venue, appointment title. The parameters required for determining an appointment or calendar booking can thus be made available.

In one embodiment, the Mastermod ul. the one or more client modules provided to create a connected to the terminator robot command set and transmit resp. which includes one or more of the following commands: Prioritization of information contained in the parameter set, mandatory specifications concerning information contained in the parameter set, criteria for groups or lists with free appointments. As a result, flexible and powerful commands can be defined, which are required for determining an appointment or calendar booking.

In a particular embodiment of the system, calendar information of the master and / or individual client modules can also be completely or partially mapped as representations on a server. A partial representation may in particular preferably include the free appointment areas ("empty spaces") of a client These spaces may be displayed for particular periods, taking into account filter criteria or also for a client as a whole (completely) on a server. The scheduling coordination initiated by the master client in this case uses the blank information provided by the client (or several clients) on the server (or several networked servers) according to the invention This communication can also be done by means of these representations or else directly between the clients.This preferred embodiment takes into account a high degree of data security and can reduce the data traffic between the master and the clients themselves In addition, the master client also makes its appointment information (empty spaces) available on the server (synchronized or ephemeral) and the appointment determination can be evaluated on the server side, thus giving the master only one result (appointment options of all possible appointments or a selection thereof).

It would also be possible - at the expense of a less than adequate use of the advantage of the data exchange resulting from the avoidance of an server-synchronized calendar (not just the blanks, but the actual appointments and their contents). comfort (see below) - to support fully server-synchronized ("cloud-based") calendars in this way.

In a correspondingly preferred variant, at least one client has at least one client module, which is represented as a representation on a server, this representation containing all or parts of the free appointment areas stored on this client module.

In a method according to the invention for a terminating robot, calendar entries are accessed by a master module and a terminating robot with a parameter set and a command set connected thereto are created. Via a data network, this appointment robot is transmitted to one or more client modules. The client modules receive and evaluate groups or lists of provisional, possible appointment entries on the master module for evaluating one or more calendar entries. One or more client modules accepts a deadline robot with associated parameter set and command set from a master module, accesses calendar entries, and creates a group or list of provisional appointments and sends it to the master module.

In one embodiment, the master module transmits a determined appointment or calendar booking to one or more client modules and accepts an acknowledgment from the one or more client modules and stores the calendar entry.

In one embodiment, one or more client modules accepts an appointment or calendar booking from a master module and stores the calendar entry and transmits an acknowledgment to the master module. In one embodiment, the master module resp. the one or more client modules access calendar items stored in a plurality of calendar databases, the calendar databases including at least one calendar database of a user associated with the master or one or more client modules and a calendar database for storing tentative appointments.

In one embodiment, the master module resp. from the one or more client modules to calendar entries in a local memory associated with the master or client module and / or to calendar entries in a memory ripenable via a data network.

In one embodiment, the Mastermod ul resp. from the one or more client modules, a term robot with attached parameter set, groups or lists with provisional calendar appointments and / or ascertained calendar bookings in a data format that includes one or more entries in an iCalendar data format.

In one embodiment, data is exchanged between the master module and the one or more client modules according to an Extensible Messaging and Presence Protocol.

In one embodiment, the Mastermod ul resp. data such as, in particular, a deadline robot with connected parameter set and command set, provisional appointment entries, etc. before being transmitted in a capsule comprising a hash, an electronic signature and / or an electronic secure encryption or the secured capsule is checked upon receipt.

In one embodiment, the master module resp. from the one or more client modules creates a parameter set connected to the terminator robot and transmits resp. which includes one or more of the following parameters: calendar date, start and end time, appointment information of meeting participants, meeting venue, appointment title.

In one embodiment, the master module resp. from the one or more client modules a command set B connected to the terminator robot creates and transmits resp. which comprises one or more of the following commands: Prioritization of information contained in the parameter set, mandatory specifications relating to information contained in the parameter set, criteria including query intervals for determining groups or lists with free appointments.

A master according to the invention for a terminating robot comprises a master module which is intended to access calendar entries and to create a terminating robot with associated parameter set and command set, which are secured in a capsule, and to be transmitted to one or more client modules via a data network and receive and evaluate each of the client modules groups or lists of provisional appointment entries to determine one or more calendar bookings. In one embodiment of the master, a graphical user interface is set up to simultaneously display calendar entries of a user of the master in a first calendar and provisional appointment entries in a second calendar, these calendars being aligned in the time axis. A client according to the invention for a term robot comprises a client module which is provided to receive a appointment robot with attached parameter set and command set, which are secured in a capsule, from a master module and mature on calendar entries and to a group or list with provisional appointments create and submit to the master module.

In one embodiment of the client, a graphical user interface is set up to simultaneously display calendar entries of a user of the client and provisional appointment entries, in particular by displaying them on adjacent calendars which are aligned with respect to the time axis.

In one embodiment of the client, an input gate is provided to receive a terminator robot with attached parameter set and command set, which are secured in a capsule, and to check the security elements and to check the parameter set and command set for compliance with a security policy.

In one embodiment of the client, an output gate is provided to check a group or list of provisional deadlines for compliance with a security policy.

The invention will be explained below with reference to embodiments in conjunction with the drawings. Show it :

Fig. 1a schematically shows a system comprising a master module and several client modules;

Fig. 1b schematically shows a system comprising a master module and several client modules, thereof a client module with a representation on a server; FIG. 2 schematically shows a term robot with connected parameter set and command set; FIG.

3 schematically shows a client module with an input gate and an output gate;

4 schematically shows a graphical user interface for a master module; and

5 schematically shows a graphical user interface for a client module.

FIG. 1a shows a system with a master module MA and several client modules CA 1, CA2, CA3. The master mod ul MA is contained in a designated as Master M mobile device (smartphone, handheld, etc.). The client modules CA 1, CA 2, CA 3 are each contained in mobile devices designated as clients C 1, C 2, C 3 (likewise smartphones, handhelds, etc.). The master module ul MA and the client modules CA 1, CA2, CA3 are designed in particular as ASIC or as software applications or as a mixture of these two variants. In a preferred variant, the master module MA and / or the client modules CA 1, CA2, CA3 are installed as software applications on the mobile devices M, C 1, C 2, C 3 shown schematically in FIG. 1 a, which are executed there on a processor. In a preferred variant, the master module MA and / or the client modules CA 1, CA 2, CA 3 are embodied as hardware components, for example ASIC (Application Specific Integrated Circuit), which are used in the mobile devices M, C 1, C 2, C 3 are. The mobile devices M, C 1, C 2, C 3 are designed as smartphones, mobile phones, tablets or even as a wristband display etc. A mobile device M, C 1, C 2, C 3 includes communication interfaces, user interfaces, microprocessors and other electronic circuits. Communication interfaces include a mobile radio interface or an interface to a WLAN (Wireless Local Area Network) or another communication network connection. User interfaces include a touch screen, a display and / or a pointer device or a keyboard.

With the master module MA contained in the master M and the client modules CA 1, CA2, CA3 contained in the clients C 1, C2, C3, the functions of the system explained in detail below are carried out for a deadline robot, these functions being performed by the master module MA and the client modules CA 1, CA2, CA3 are controlled. In a variant, the master module MA and / or the client modules CA 1, CA2, CA3 are made available in a software store (so-called app stores) as a downloadable or installable app which comprises either a master module, a client module or both. This step is omitted, as far as the modules concerned are preinstalled as ASIC or software application in the mobile device M, C 1, C2, C3. In the case of master mode ul MA executed as an app and / or client modules CA 1, CA2, CA3, these may be protected by conventional security systems from manipulation. As mentioned, in one variant the master module MA and one client module CA 1, CA 2, CA 3 are combined in a single module, ie the described functions of the master module MA and of the client modules CA 1, CA 2, CA 3 are available from a standard app placed, which behaves on the master M as master module MA and on the clients C 1, C2, C3 as a client module CA 1, CA2, CA3. The client modules CA 1, CA 2, CA 3 are executed here as identical modules, which by settings of the client C 1, C 2, C 3 such. B. an IM EI (International Mobile Equipment Identity), user information, phone number, etc. are customized. In the system for a deadline robot shown in FIG. 1a, an appointment request is not transmitted by a master M to clients C 1, C 2, C 3 as in the prior art as a mere information unit, comprising for example an iCalendar object, but the appointment synchronization is based on the in Figure 2 schematically dargstelltem appointment robot R, the clients C 1, C2, C3 is made available. As shown schematically in FIG. 2, in the terminology R offered a parameter set P and a command set B. In the present exemplary embodiment, the appointment robot R, the parameter set P and / or the command set B are encapsulated in a capsule K verified by a hash value 1 1 and / or an electronic signature 1 2, which is made available to the clients C 1, C 2, C 3. Optionally, the capsule K can be additionally secured by electronic encryption. The hash value 1 1, the electronic signature 1 2 and the electronic encryption 1 3 form security elements of the capsule K. In addition to the security elements 1 1, 1 2, 1 3 contains the capsule K or the terminal robot R as information about a manufacturer or sender a mobile phone number, an IM (International Mobile Equipment Identity) EI, a Mobile Subscriber Integrated Services Digital Network Number (MSISDN), an e-mail address, and / or other information. Preferably, at least part of this data, in particular a telephone number (or its substitute) is contained as an identifier in a capsule header. The capsule header is unencrypted in this case.

In the present case, the master M generates a capsule K 1 which, as shown schematically in FIG. 1 a, can be transmitted or made available to the clients C 1, C 2, C 3 via conventional data networks (eg a TCP / IP network). In different embodiments, the capsule K 1 can be formed by a command set B already present at a client and a parameter set P transmitted by the master M (hash value, signature and encryption can be ensured analogously for the capsule in a known manner). The advantage of such a split is the smaller amount of data that must be sent from the master M to the clients C 1, C 2, C 3. In a further embodiment of the invention, as shown in Figure 1 a schematically represented by the capsules K2, K3, the parameter set P and command set B per client C 1, C2, C3 be different, z. B. if the appointment synchronization for the clients C 1, C2, C3 does not require completely identical parameters. In this embodiment as well, the capsules K 1, K 2, K 3 can in turn only be formed at the client C 1, C 2, C 3, if required. Upon receipt of a capsule K 1, K 2, K 3 on a client C 1, C 2, C 3, in particular the manufacturer or sender of the capsule K 1, K 2, K 3 are checked on the relevant client C 1, C 2, C 3. Furthermore, the security elements 1 1, 1 2, 1 3 of the capsule K 1, K2, K3 are evaluated, wherein a review of the signature and / or a hash value and / or a decryption is performed. If the manufacturer or sender are known and the evaluation of the security elements is successful, the appointment robot R and the associated parameter set P and command set B are available to the relevant client C 1, C 2, C 3.

FIG. 1 b shows an embodiment of the system according to the invention, which largely corresponds to FIG. 1 a but has a client C in which the client module CA 1 is represented as a representation CA T on a server S. This representation CA T here preferably contains only parts of the free appointment areas stored on this client module CA 1. If required, however, all free appointment areas (ie all "empty spaces" in the calendar of the client module C 1) can also be matched with the representation CA 1 '.

These spaces are in the present example - again for reasons of Datensi security - preferably subsets of all available appointments of the client module C 1, ie they include only one or more special, predetermined periods (eg 2 months or a year into the future) or are determined by given or dynamic fine filter criteria (eg not more than three half days per week, not before 07:00 o'clock and / or "never on Wednesday afternoon" etc.) The filter criteria can be set in client C by the user In a further development of this solution, the filter criteria can be determined by the client to be self-learning (eg if appointments on Thursdays are always rejected by the user, etc.) For this purpose the client has a self-learning module SM 1, which has a self-learning logic or a corresponding mod ul and a memory. The appointment coordination initiated by the master client or the appointment robot in this case uses information that is provided in the representation CA. It is also possible that all clients C 1, C 2, C 3 and also the master client provide a corresponding representation on the server S (or networked servers). The appointment synchronization otherwise takes place according to the invention analogous to FIG. 1 a or the method described below.

In particular further embodiment variants, in particular in the case of a bandwidth which is only limitedly available to the master M, the parameter set P and / or the capsule header can contain forwarding information. In this way, only one capsule K 1 can be sent by the master M, which is then received, for example, by the client C 1 and forwarded by the latter to the further clients C 2 and C 3. The forwarding by the client C 1 is individually enabled, limited or completely prohibited by authorization settings, with the original sender, in this case the master M, preferably being given a corresponding message in the case of limitations and forwarding blocks, so that a further transmission via an alternative client C2, etc. may be provided. In an analogous manner, instead of forwarding via a client through a corresponding network resource (for example a communication server), a capsule distribution can preferably be made possible to a plurality of clients C 1, C 2, C 3 or Cn.

The parameter set P comprises data which are preferably structured here in an iCalendar data format. The command set B contains command definitions formulated in a machine-interpretable language. Standard parameters or standard commands can be stored in tables stored on the master M and the clients C 1, C 2, C 3, so that for the transmission of a relevant standard parameter or standard in parameter set P or in command set B, only the specification of the relevant table - line ID is required. This reduces the amount of data to be transmitted.

The data stored in parameter set P in an iCalender data format contains a list of information components. The components refer to an event, a to-do list, a journal entry, a time zone information, a free / busy time, or an alarm time. The list entries with the components are present line by line and can have entries such as U I D :, DTSTAM P :, ORGAN IZER:, DTSTART :, DTEN D: or ZUSAM M EN FASSU NG:. Alternatively, structured markup languages can be used for the compilation of the parameter set P.

The parameter set P accordingly includes data for one or more requested appointments, which include, for example, calendar data, start times, end times, appointment duration, data on the appointment content, urgency of the appointment, data with location information, data on appointment subscribers, etc.

The commands written in the command set B in a machine-interpretable language are provided to define queries and / or codes which can be executed on a client C 1, C 2, C 3 or can be interpreted by the latter. The queries preferably allow the finding of free appointments in a calendar, such. B. for finding free appointments of a certain duration, on certain days, within certain time intervals, etc. It may, for example, a coding defined to determine all free half-hour appointments in a morning during the next four working weeks. A corresponding coding can be supplemented z. For example, there are limitations such as "do not return more than seven appointment possibilities." The commands written in a machine-interpretable language make queries so flexible that command set B can handle source code, script commands, or binary code which is directly executable by a compiler, interpreter or processor on the receiving client C 1, C 2, C 3. This allows very powerful and flexible commands to be executed. Again, a special markup language can alternatively be provided for the command set. The command set B may include instructions that parameterize business logic, such as instructions regarding the prioritizing of normal office hours versus off-peak times, instructions regarding the prioritization of locations or geographical locations, flexible (fuzzy) parameters (such as codes such as "preferred in off-peak times Thus, on the relevant client C 1, C 2, C 3, it results that the client modules CA 1, CA 2, CA 3 execute defined functions due to the transmitted appointment robot R, in particular as described in the parameter set P and command set connected to the terminating robot R In contrast to conventional appointment coordination solutions, the delivery of the appointment robot allows avoiding a centralized calendar server in which the calendars of all clients would have to be copied or synchronized, particularly because of the calendars contained in calendars sensitive data is a significant technical advantage.

The creation of the parameter set P and the command set B takes place on the basis of an appointment request, which specifies or has entered a user on the master M. Such an appointment request includes data with information regarding desired or required appointment participants, dates, times, locations, etc. For example, the user can interactively enter the input "meeting management 4 hours next 2 weeks, preferably in the afternoon" at the master M. The Part "Meeting management" (participant) as well as "4 hours" (duration) is assigned to parameter set P. assigns. The part "next 4 weeks ..." (interval in which to search for appointments) and "... preferably in the afternoon" is assigned to the command set B. The appointment participants required for the appointment request as well as their clients C 1, C 2, C 3 are determined, for example, on the basis of stored contact data. The place of the meeting and / or further information necessary for the date fixation results, for example, from stored standard values. Contact data and / or standard values can be stored locally for specific users on the Master M or on a central server such as an Internet server. These additional details (location, further persons, etc.) are optional at the step request, so they may or may not be included in the capsule. Only at the next step of a date fixation these details are usually required.

When the parameter set P and the command set B are created, local calendars of the client or, alternatively, Internet calendars (ie, calendars shared by a server, for example, over the Internet) are accessed, in particular, calendars associated with the user of the master M. are. The access is done here in a conventional manner via an API (Application Programming Interface), which is provided by the operating system of the master M. In the preceding example concerning the "meeting management" appointment suggestions are compiled from the local calendar, Internet calendar, etc. of the user and connected as a parameter set P and command set B to a terminator robot R packed in a capsule K, one or more clients C 1, C2, C3 When the deadline robot is created, the corresponding provisional appointments TM are entered in a calendar for provisional appointments on the master M (if appointment times are already contained in the parameter set P) and thus marked. As described above, the parameter set P and command set B connected to the terminating robot R are accessed on the clients C 1, C 2, C 3 on the basis of the provided terminating robot R by the relevant client module CA 1, CA 2, CA 3. The client module CA 1, CA2, CA3 also accesses local calendars and / or Internet calendars, etc., which in particular are assigned to the respective user of the client C 1, C 2, C 3. The access to the clients C 1, C 2, C 3 associated calendars is also via API. The client module CA 1, CA2, CA3, taking into account the parameter set P, the command set B as well as local calendar, Internet calendar, etc. for the respective client C 1, C2, C3 provisional appointments T1, T2, T3, which in one of the client C 1, C2, C3 train mature calendar with provisional dates registered and thus be marked. For the sake of clarity, it should be mentioned here that these provisional appointments can be individual appointments, but also periods which comprise several possible appointment options of a client C 1, C 2, C 3.

The provisional appointments T 1, T 2, T 3 are transmitted to the master M and evaluated there, a date fixation or appointment or calendar booking being determined, which is transmitted to the clients C 1, C 2, C 3. The appointment or calendar booking (comprising a provisional appointment or an appointment within the possible periods of the provisional appointments received by the master) is stored in a definitive calendar (a local calendar or alternatively an Internet calendar) of the master M and the clients C 1, C2, C3 registered. If required, the entry is acknowledged by the clients C 1, C 2, C 3 with respect to the master M (and / or vice versa). After entering the appointment or calendar booking are on the master M and the clients C 1, C2, C3 corresponding to the corresponding appointment request provisional appointments T1, T2, T3 disabled in the calendar with the provisional appointments, hidden or deleted. This is made possible by assigning appropriate I Ds in the appointment request or appointment fix. The following table shows provisional appointments T1, T2, T3 of clients C1, C2, C3, which are evaluated with respect to provisional appointments TM of the master M. The provisional appointments TM, T1, T2, T3 are listed in a table as shown below, and those appointments are determined which match both the master M and the clients C1, C2, C3.

Appointment TM T1 T2 T3

1 Mo 8-9 X x

2 Tues 12-13 X x X X

3 Wed 14-16 X x

4 Fr 8-9 X x X X

The appointment 2 Tues 12-13 and the appointment 4 Fr 8-9 are registered for the master M as well as for all clients C1, C2, C3 as provisional appointments and can be used for an appointment. Calendar booking in question. Due to an additional rule to always book the earliest appointment, the Master M would make the booking of the appointment 2 Tues 12-13. In a variant, if such an additional rule is not configured on the master M, the user of the master M would see the two appointments 2 Tues 12-13 and 4 Fr 8-9 available for selection. Of course, the appointment booking can fog up the whole appointment of these individual provisional appointments or a part of it in time.

As shown, the creation of an appointment entry for a master M and several clients C1, C2, C3 only requires the manual entry of an appointment request on the master M. Subsequently, the determination and entry of an appointment or calendar book runs. on the master M and the clients C 1, C 2, C 3 due to the terminating robot R completely automatically. In this automatic process, manual confirmation or manual adaptation by a user of the master M or a user of a client C 1, C 2, C 3 may optionally be provided in one or more steps. Thus, provisional appointments T1, T2, T3 can be displayed on the relevant client C 1, C 2, C 3 before sending, and the user can be given the option of modifying or deleting provisional appointments T 1, T 2, T 3, etc. Before the capsules K 1 , K2, K3 or the corresponding terminating robots R can be provided, a manual Ü checking, modification, etc. by the user of the master M. The acknowledgment of an appointment or calendar booking by the clients C 1, C 2, C 3 is preferably made dependent on a manual input by the user of the respective client C 1, C 2, C 3. Such manual intervention is optional, but can be used, for example, to keep users of the appointment synchronization system better informed or their privacy best preserved. Such manual inputs are preferred to comply with existing security policies, particularly regarding access to and storage of calendar entries.

FIG. 3 schematically shows a client C which has a client module CA with an input gate EG and an output gate AG. The input gate EG is intended to perform a check on a capsule K or a robot R which has been made available to the client C. The output gate AG is intended to carry out a check of provisional deadlines T, which are intended for transmission to a master M. In a variant, the input gate EG and the output gate AG are included in the client module CA. The input gate EG is designed in such a way that in a first step upon receipt of a capsule K or a robot R senders, manufacturers and security elements are checked, which are preferably at least partially contained in the capsule header. For this purpose, the input gate EC performs a comparison of corresponding data and performs appropriate control functions. If this check is successful, the input gate EG checks in a second step the parameter set P and the command set B according to a preferred three-level security policy. In a first security level F 1, the parameter set P and the command set B are no longer checked and immediately released to the client module CA for further processing. In a second security level F2, it is checked for selected senders or manufacturers of the appointment robot R whether the parameter set P or the command set B causes inadmissible access to calendar data. The selected senders concern senders who are not known to the user of the client C, that is, who are not contained in a client C contact database. The selected senders can also concern senders which are marked accordingly in a contact database of the client C. In a third security level F3 for all senders of the terminating robot R resp. The capsule K checks whether the parameter set P or the command set B causes inadmissible access to calendar data. The security levels F 1, F 2, F 3 can be configured by the client C user.

The definition of inadmissible access to calendar data is based on standard values (default values) which the user of client C can set according to his own needs. The user of the client C can thereby define that accesses to calendar data over a longer period than z. B. the next eight weeks are inadmissible. The user of the client C may also define that appointment requests containing a large number, such If, for example, more than twenty results could be found, they are inadmissible. In particular embodiments of the invention, such restrictions or limitative also be provided directly in the appropriate code to prevent inadmissible queries by a deadline robot.

If an inadmissible access is detected on the client C, then the user of the client C is displayed a message and given the opportunity to perform the illegal access anyway, to change the access and restrict or deny this access.

The output gate AG is designed in such a way that a check is made of the determined provisional deadlines T. The check is also carried out here preferably according to a three-level security policy. In a first security level E 1, the provisional appointments are not checked further and immediately released for transfer to the relevant master M. In a second security level E2, the provisional appointments for selected masters M are checked. The selected masters M are defined according to default values or according to the specifications of a user of the client C. To a master M, for example, who is not yet known, provisional appointments T are transmitted only after a check enabling a user re-entry. In a third security level E3, a check of the provisional appointments is made for all the masters M.

A check of provisional appointments T is again based on standard values which the user of the client C can set according to his own specifications. The user of the client C may define that only a maximum number of e.g. B. eight provisional appointments can be transmitted to a master M. For selected masters M, the user can define that only provisional appointments, for example concerning a specific location, are transmitted. If the check of the provisional appointments T fails, then this is displayed to the user of the client C and given the possibility of manually deleting or changing them before releasing provisional appointments.

FIG. 4 shows a graphical user interface G 1 for displaying and inputting appointments on the master M. The graphical user interface G 1 is preferably provided for a touch-sensitive screen such as a touch screen of the master M. The displays of the corresponding clients are designed accordingly.

In the concrete example, the calendar week 37 (KW37) in the year 20 1 2. The graphical user interface G 1 has a title line Z 1 with the indication of the relevant calendar week, seven in four lines and two Columns Planned fields for the days of the week, a field in the fourth line of the weekdays for a month view Q 1 and a footer Z2 with controls on.

For each day of the week several calendars 1, 2, 3, 4, 5 are shown simultaneously, in Figure 4, the plurality of calendars 1, 2, 3, 4, 5 are shown in the respective days of the week as successive lines. The peculiarity of the presentation is that a calendar matrix is displayed in a novel way for each weekday, as described in more detail below. The appointments of the respective calendars 1, 2, 3, 4, 5 are preferably stored in several local calendars of the master M. The multiple calendars of the calendar matrix are displayed in different ways, for example by using different hatchings, colors, etc. The lengths of the calendars 1, 2, 3, 4, 5 shown as horizontal lines correspond to a time interval such as the office hours, the extended office hours, etc. of the relevant day. Office hours can be defined, for example, at 8-1.7 hours, while the extended office hours are For example, 7- 1 9 Uhr are defined. The lengths of the horizontal lines of the illustrated calendars 1, 2, 3, 4, 5 may correspond to a different time interval. The appointment entries in each of these calendars 1, 2, 3, 4, 5 of the calendar matrix are displayed chronologically and proportionally within the respective calendar line, so that the calendars are aligned with respect to the time axis.

An essential feature of the embodiment shown here is that a separate calendar is provided for definite and for provisional appointments in each daily calendar matrix. This enables the efficient, automated and (by the user at all perceptible) clear automated writing processes of the respective appointment robots. The appointment robot can transfer or save a possible appointment identified by the master by means of an appointment booking in the definitive or else in the calendar for provisional appointments (master or client side). For the user interface according to this embodiment, this division into two separate calendars is a very significant advantage of the invention.

A first calendar 1 is thus provided for the display and input of stored, definitive appointments of the user of the master M. To enter an appointment of one hour, the user preferably draws a control field 1 h of the footer 1 by dragging and dropping on the relevant point of the displayed first calendar 1. This will open a dialog, so that detail dates such as title, place, etc. are vornehmbar. For a longer contact (without movement) of z. B. more than a second, the corresponding standard date can be modified (eg., By "meeting in the meeting room") and preferably supported by a so-called. Wizzard, which provides the input of the parameter set P and the command set B, then (after completion of the wizard) an appointment can be created very flexibly and efficiently by means of drag-and-drop. To modify an appointment in the first calendar 1, touched the user the relevant appointment, with a window opens to modify appointment entries such as time, place, etc. To delete an appointment, the user pulls the relevant appointment, for example, from the calendar view on a delete button. Appointments can be managed in a different way. However, creating appointments using drag-and-drop using control fields in the footer is an advantage.

A separate second calendar 2 shown in FIG. 4 in the respective daily calendar matrix is provided for the display and entry of provisional appointments of the user of the master M. The provisional appointments can be subdivided into provisional appointments for which an appointment survey is still in progress and in provisional appointments for which a new appointment survey is to be started. For distinction, provisional appointments that belong to a pending appointment survey, for example, shown in dashed or in a first color, while provisional appointments belonging to a new appointment survey, for example, drawn or displayed in a second color. In the example shown in FIG. 4, a provisional appointment is entered on Monday and Tuesday, which belong to a pending appointment survey, while on Wednesday and Friday provisional appointments are entered which belong to a new appointment survey. In order to add a further provisional appointment with the duration of 1 hour to the appointment poll, as shown schematically in FIG. 4, for example, the control labeled "1 h" can be dragged from the footer Z2 to the relevant location of the second calendar 2 and released there In the example shown in Figure 4, a provisional appointment with the time duration of 1 hour for the Saturday is recorded in this manner at the relevant time point. The appointment recording takes place analogously to the procedure described for the first calendar 1. The third calendar 3 shown in FIG. 4, the fourth calendar 4 and the fifth calendar 5 contain appointments which are subscribed, for example, by another client calendar or also by an internet calendar. These appointments can be obtained, for example, from work colleagues, family members, clubs, concert organizers, etc. and displayed on the graphical user interface G 1. For example, in the third calendar 3, the appointments of a work colleague, in the fourth calendar 4, the appointments of the life partner and in the fifth calendar 5, the appointments of a lecture cycle may be shown. Due to the simultaneous display of the calendar 1, 2, 3, 4, 5, the user is immediately informed, at which times even more appointments could be entered. For example, in the case of a short-term cancellation of an appointment entered in the first calendar 1, the user is thus immediately informed as to whether participation in a lecture cycle, at a group meeting, etc. is an option.

This simultaneous bar-type with segment entries for appointments and time-coordinated presentation of a first calendar 1 with definite appointments, a separate second calendar 2 with provisional appointments and with a number n of subscribed (integrated) foreign calendars forms a calendar matrix supplemented by additional displayed calendars can be. Each calendar can contain a large number of individual appointments. The respective calendars 1 -5 are aligned so that they coincide chronologically and a direct optical comparison is made possible light. Within each calendar matrix preferably a selectable sequence and / or a scroll mechanism is provided, wherein the first and second calendars 1, 2 preferably remain permanently faded in. This calendar matrix allows highly dynamic, but nevertheless optically recognizable automated writing processes within the calendars by the respective appointment robots. The calendar matrices are shown here each as a daily calendar matrix. Accordingly, a single day, a monthly, a weekly or a period calendar matrix may be provided. It is important here that each calendar can be represented separately, that writing rights per calendar are clearly definable and that the user has in particular his (local) first and second calendars 1, 2 available.

With such a graphical user interface G 1, the user of the master M has a quickly comprehensible, complete overview of all appointments, which must be taken into account when creating an appointment survey. Instead of five calendars 1, 2, 3, 4, 5, more or fewer calendars can be displayed simultaneously. Preferably, at least the first calendar 1 with the appointments of the user and the second calendar 2 with the provisional appointments of the user are displayed simultaneously (fixed).

For example, the graphical user interface G 1 is also provided so that controls from footer Z2 can be dragged to a single day of the displayed week, to calendar weeks displayed in the month view Q 1, the displayed month, etc., to request a corresponding date survey start. For example, a control tagged with the label F 1 in footer Z2 may be arranged to start an appointment inquiry for a spontaneous meeting after work, with a particular subscriber group, for example a group of friends, dragging and releasing the control to a date , a time, etc., are included in the appointment poll, making a robot R available to respective clients C 1, C 2, C 3. Instead, the control with the label F 1 may be intended to start a 2-hour meeting poll by dragging and releasing the control on a calendar week shown in the month view for that calendar week, creating a robot R and clients C, respectively 1, C2, C3 is made available in order to arrange an appointment or calendar booking with members of a working group. The properties of the elements shown in the footer Z2 can be, for example, with the set the label # control, which opens a mask when touching this control, in particular to define appointment participants and time duration. Furthermore, the footer Z2 has a control, which is designated by the label = and is intended to start a recurring appointment survey quickly, so for example, for a workgroup a date survey for the next possible meeting date of 30 minutes, for example, an urgent problem, which concerns the working group, to be able to agree rapidly among each other.

On the basis of the started appointment survey, a parameter set P and a command set B are created on the master M or by the master application and connected to a terminating robot R. Before these are made available to one or more clients C 1, C 2, C 3 as described above, a capsule K (completely or partially encrypted) may be formed, depending on the settings or specifications. As described above, due to the appointment robot R and the attached parameter set P and command set B in a variant completely automatically in cooperation with defined on the clients C 1, C2, C3 calendar of the appointment poll corresponding appointment or calendar booking made and in relevant calendar of the master M and the clients C 1, C2, C3 registered. During the determination of the appointment or calendar booking for the appointment poll, temporary provisional appointments are preferably entered in the respective calendar of the master client M and the clients C 1, C 2, C 3.

Various manual steps may be provided in determining the appointment or calendar booking corresponding to the appointment survey, in particular to inform users on the basis of messages to be confirmed, to provide users with the opportunity for manual adjustments, to change appointment polls for a short time, etc. After an appointment robot R as well as the parameter set P and command set B evaluated on a client C 1, C 2, C 3 and thus provisional appointments T 1, T 2, T 3 are determined, the provisional appointments T 1, T 2, T 3 are for the user, for example shown schematically in a graphical user interface G2 for displaying provisional appointments, which user interface G2 is similar to the above-described user interface G 1 for entering an appointment survey on a master M is constructed. As an alternative to this user interface G2, the controls of client C 1, C2, C3 and master M can be combined in a common footer (footer of master and client are coincident). Again, for the weekdays the appointments of the user in a first calendar 1, the provisional appointments in a calendar 2 with the provisional appointments, as well as other local or remote calendars 3, 4, 5 are displayed. Before the user confirms the provisional appointments, these are displayed in calendar 2 with the provisional appointments, for example, blinking or with a different marking. As shown schematically in FIG. 5, other controls are arranged in the footer Z2 than the controls described in connection with the entry of an appointment inquiry on a master M. The footer Z2 of the user interface G2 for displaying provisional appointments comprises a control element V for confirming one or more provisional appointments according to a predefined setting, a control VV ^{for r} confirmation of all provisional appointments, control elements B 1, B2 for a user-specific confirmation of provisional appointments, for example a confirmation of all provisional appointments which do not collide with an appointment of the calendar K 1 with definite appointments contained therein (which was possibly manually recorded or not taken into account in the determination of provisional appointments) or a confirmation of all provisional appointments which not collide with the third calendar 3 or fourth calendar 4 (in the example shown in FIG. 5, this is not an appointment). Furthermore, a # control is provided to pre-set user preferences. for example, to set the user-specific acknowledgments B 1, B 2, and a control = to accept the determined provisional appointments in a standard procedure, wherein the standard procedure may be configured to schedule certain provisional appointments such as appointments. As appointments on a weekend, to discard.

Instead of a monthly view Q 1, a functional area W 1 can be provided at the corresponding location of the graphical user interface G 1, G 2. In the variant preferred here, the calendar 1 with the appointments of a user and the calendar 2 with the provisional appointments are shown one above the other and represented by color or other graphic distinguishing features.

In a preferred embodiment, the evaluation of the parameter set P and command set B with respect to the calendars of the user of a client C 1, C 2, C 3 is such that no collision between the calendar 1 with the user's appointments and the calendar 2 with the provisional appointments consists. In a further variant, when determining the provisional appointments, any travel between the geographical locations concerning appointments is automatically taken into account.

The data transmission between the master M and the clients C 1, C 2, C 3 takes place via a data network such as the TCP / IP-based Internet. In one possible embodiment, the data transmission is based on an Extensible Messaging and Presence Protocol XM PP according to an Internet standard for XM L routing (XM L: Extensible Markup Language) published by the I ETF in RFC 61 20-61 22 and 3922, 3923. The robot R, the connected parameter set P and command set B, possibly the capsule K, provisional appointments T1, T2, T3 which are transmitted from the clients C 1, C2, C3 to the master M and an appointment or calendar booking preferably in an iCal or XM L data format structured and drafted. In a further variant, the Mastermod ul M and / or one or more client modules C 1, C2, C3 as on a personal computer (PC), notebook, etc. installable and executable application or as usable in such a device hardware device or as a M ischung executed these two variants.

Further particular embodiments will become apparent from one or more of the embodiments illustrated below.

In a preferred variant of the system for a term robot R, the master module MA resp. the one or more client modules CA 1, CA 2, CA 3 provide access to calendar entries in a local memory allocated to the master MA or client module CA 1, CA 2, CA 3 and / or to access calendar entries in a memory accessible via a data network.

In a preferred variant of the system for a term robot R, the master module MA resp. the one or more client modules CA 1, CA 2, CA 3 provide the parameter set P and command set B connected to the terminating robot R, the groups with provisional calendar appointments T 1, T 2, T 3 and / or a calender entry determined in a data format one or more entries in an iCalendar data format.

In a variant of the system for a term robot R that are the master mod ul MA resp. the one or more client modules CA 1, CA 2, CA 3 are provided to exchange data between a master module MA and the one or more client modules CA 1, CA 2, CA 3 according to an Extensible Messaging and Presence Protocol.

In a preferred variant of the system for a terminating robot R, the master modules are MA resp. the one or more client modules CA 1, CA2, CA3 provided to create the parameter set P connected to the terminating robot R and transmit or which includes one or more of the following parameters: calendar date, start and end time, appointment information of meeting participants, date of meeting, appointment title. In a preferred variant of the method for an appointment robot is from the master module MA resp. the one or more client modules CA 1, CA 2, CA 3 access calendar entries in a local memory assigned to the master MA or client module CA 1, CA 2, CA 3 and / or access calendar entries in a memory which can be accessed via a data network. In a preferred variant of the method for a term robot R are from the master module MA resp. from the one or more client modules CA 1, CA2, CA3 created a deadline robot with attached parameter set P, groups with provisional calendar dates and / or determined calendar bookings in a data format comprising one or more entries in an iCalendar data format. In a variant of the method for a terminating robot R, data is exchanged according to an Extensible Messaging and Presence Protocol between the master module MA and the one or more client modules CA 1, CA 2, CA 3.

In a preferred variant of the method for a term robot R are from the master module MA resp. from the one or more client modules CA 1, CA2, CA3 creates a parameter set P connected to the terminating robot and transmits it resp. received, which includes one or more of the following parameters: calendar date, start and end time, address information of appointment participants, meeting venue, appointment title. In a preferred variant of a client for a deadline robot, an input gate EG is provided to receive a term robot R with connected parameter set P and command set B, which are secured in a capsule K, and to check the security elements 1 1, 1 2, 1 3 and Check parameter set B and command set B for adherence to a security guideline E 1, E2, E3.

In a preferred variant of a client for a term robot, an output gate is provided to check a group with provisional deadlines for compliance with a security policy.

Claims

claims

A system for an appointment robot (R), the system comprising a master module (MA) and one or more client modules (CA1, CA2, CA3), wherein the master module (MA) is provided to access calendar entries and a term robot (R) with connected parameter set (P) and command set (B) and to transmit over a data network to one or more client modules (CA1, CA2, CA3), and from the client modules (CA1, CA2, CA3) per groups with provisional appointment entries (T1 , T2, T3) to receive and evaluate one or more calendar bookings; and the one or more client modules (CA1, CA2, CA3) are provided to receive a terminating robot (R) with associated parameter set (P) and command set (B) from a master module (MA) and to access calendar entries and a group with provisional ones Appointments (T1, T2, T3) to create and transmit to the master module (MA).

2. System according to claim 1, characterized in that the master module (MA) is provided to transmit a determined calendar booking to one or more client modules (CA1, CA2, CA3) and from the one or more client modules (CA1, CA2, CA3 ) to receive an acknowledgment and to save the calendar booking.

3. System according to claim 1 or 2, characterized in that the one or more client modules (CA1, CA2, CA3) are provided to receive a calendar booking from a master module (MA) and to save the calendar booking and an acknowledgment to the master module (MA ). System according to one of claims 1 to 3, characterized in that the master module (MA) resp. the one or more client modules (CA1, CA2, CA3) are provided to access calendar entries stored in a plurality of calendar databases, the calendar databases having at least one calendar database of a user assigned to the master (MA) or client module (CA1, CA2, CA3) and a calendar database for storing provisional appointments (T1, T2, T3).

System according to one of claims 1 to 7, characterized in that the master module (MA) resp. the one or more client modules (CA1, CA2, CA3) are provided, data such as in particular a deadline robot (R) with attached parameter set (P) and command set (B), provisional appointment entries (T1, T2, T3), etc. before one Transmission in a capsule (K) with security elements comprising a hash (11), an electronic signature (12) and / or an electronic encryption (13) to verify secure or the secured capsule (K) upon receipt.

System according to one of claims 1 to 9, characterized in that the master module (MA) resp. the one or more client modules (CA1, CA2, CA3) are provided to create and transmit a command set (B) connected to the terminating robot (R). to receive one or more of the following commands: Prioritization of information contained in the parameter set (P), mandatory specifications concerning information contained in the parameter set (P), criteria to determine groups with free appointments. Method for a terminating robot (R), wherein calendar entries are accessed by a master module (MA) and a terminating robot (R) with associated parameter set (P) and command set (B) is created and transmitted via one data network to one or more client modules (CA1 , CA2, CA3), and are received by the client modules (CA1, CA2, CA3) for each group of provisional appointment entries (T1, T2, T3) and evaluated to determine one or more calendar bookings; and from one or more client modules (CA1, CA2, CA3) a deadline robot (R) with associated parameter set (P) and command set (B) are received by a master module (MA) and calendar entries are accessed and a group with provisional appointments ( T1, T2, T3) are created and transmitted to the master module (MA).

Method according to Claim 11, characterized in that the master module transmits a determined calendar entry to one or more client modules (CA1, CA2, CA3) and accepts an acknowledgment from the one or more client modules (CA1, CA2, CA3) and the calendar entry is stored.

Method according to claim 11 or 12, characterized in that one or more client modules (CA1, CA2, CA3) receive a calendar entry from a master module (MA) and the calendar entry is stored and an acknowledgment is transmitted to the master module (MA). Method according to one of claims 11 to 13, characterized in that the master module (MA) resp. the one or more client modules (CA1, CA2, CA3) access calendar items stored in a plurality of calendar databases, the calendar databases having at least one calendar database of one of the master (MA) and one or more client modules (CA1, CA2, CA3 ) and a calendar database for storing provisional appointments.

Method according to one of claims 11 to 15, characterized in that the master module (MA) resp. from the one or more client modules (CA1, CA2, CA3), an appointment robot with attached parameter set (P), groups with provisional calendar appointments and / or ascertained calendar bookings are created in a data format which comprises one or more entries in an iCalendar data format.

Method according to one of claims 11 to 17, characterized in that the master module (MA) resp. from the one or more client modules (CA1, CA2, CA3) data such as, in particular, an appointment robot (R) with attached parameter set (P) and command set (B), provisional appointment entries, etc. before a transmission in a capsule with security elements comprising a hash (11), an electronic signature (12) and / or electronic encryption (13) are secured or the secured capsule is checked upon receipt. Method according to one of claims 11 to 19, characterized in that the master module (MA) resp. from the one or more client modules (CA1, CA2, CA3) a command set (B) connected to the terminating robot (R) is created and transmitted resp. receiving one or more of the following commands: prioritization of information contained in the parameter set (P), compulsory specifications relating to information contained in the parameter set (P), criteria including query intervals to determine groups with free appointments.

14. master (M) for a term robot (R), the master (M) comprising a master module (MA), characterized in that the master module (MA) is provided to access calendar entries and a term robot (R) with it connected parameter set (P) and command set (B), which are secured in a capsule (K) and to transmit over a data network to one or more client modules (CA1, CA2, CA3), and from the client modules (CA1, CA2 , CA3) per groups with provisional appointment entries (T1, T2, T3) to receive and evaluate to determine one or more calendar bookings.

15. Master (M) according to claim 21, characterized in that a graphical user interface (G1) is set up, calendar entries of a user of the master (M) in a first calendar (1) and provisional appointment entries (T1, T2, T3) in one second calendar (2) simultaneously, these calendars (1, 2) are aligned in the time axis. Client (C) for a terminating robot (R), the client (C) comprising a client module (CA), characterized in that the client module (CA) is provided, a terminating robot (R) with attached parameter set (P) and command set ( B), which are secured in a capsule (K), received by a master module (MA) and to access calendar entries and to create a group with provisional appointments (T1, T2, T3) and to transmit them to the master module (MA).

17. Client (C) according to claim 23, characterized in that a graphical user interface (G2) is set up to simultaneously display calendar entries of a user of the client (C) and provisional appointment entries (T1, T2, T3), in particular by placing them on adjacent, time-aligned calendars (1, 2).

18. Client (C) according to any one of claims 16 or 17, characterized in that at least one client module (CA1) is represented as a representation (CA1 ') on a server (S), said representation (CAT) all or parts of the This client module (CA1) contains free appointment areas stored.