WO2022175678A1

WO2022175678A1 - Messaging and calendaring method and system

Info

Publication number: WO2022175678A1
Application number: PCT/GB2022/050450
Authority: WO
Inventors: Ryan BRODIE
Original assignee: Onin Ltd
Current assignee: Onin Ltd
Priority date: 2021-02-22
Filing date: 2022-02-18
Publication date: 2022-08-25
Anticipated expiration: 2023-08-22
Also published as: GB202102473D0

Abstract

Disclosed is a calendaring and messaging system comprising a main server, a computer program and a communications interface to communicate with a network. The calendaring and messaging system is operable to: receive a first item from a user device over said network, said first item specifying an event and identifying one or more second user devices; create a conversation group comprising said first user device and one or more second user devices; generate group address for the conversation group; and send a calendar message to each of said first user device and one or more second user devices to create an entry in a calendar application within each respective user device.

Description

Messaging and Calendaring Method and System

The present disclosure relates to a messaging and calendaring system for multiple users.

The Internet Calendaring and Scheduling Core Object Specification format (RFC 5545), otherwise known as iCalendar, was first created in 1998 and allows different services to understand and process calendaring items. Such items include events, tasks, notes, alarms, and free/busy time. It is used and supported by many products, including Google Calendar, Apple Calendar, AOL Calendar, Yahoo! Calendar, IBM Notes, and partially by Microsoft Outlook.

The iCalendar Message-Based Interoperability Protocol (iMIP, RFC 6047) enables users of any calendaring software to schedule iCalendar items between users over internet email.

Such calendaring methods, and the CalDav standard behind them, are decentralised by nature. Each participant holds their own copy of the event and updates (changes to the event or participant status changes, e.g. going/not going) are exchanged by email. Because of this decentralised architecture, multiple participants cannot contribute to the same event. When a first user creates an event, they become the designated organizer, with any invitees being designated attendees. These designations are typically fixed, and organizers and attendees have set permissions which rise inherently from the iCalendar format. In particular, the attendees are not able to amend the item or the attendees other than their own status (i.e., whether they are attending or not). Any other amendments made by an attendee will be saved locally to their device, and not shared with other users.

It would be desirable to improve on such an arrangement, while maintaining compatibility with the iCalendar format.

SUMMARY OF INVENTION

In a first aspect of the invention there is provided a calendaring and messaging system comprising a main server, a computer program and a communications interface to communicate with a network, wherein the calendaring and messaging system is operable to: receive a first item from a user device over said network, said first item specifying an event and identifying one or more second user devices; creating a conversation group comprising said first user device and one or more second user devices; generating a group address for the conversation group; and sending a calendar message to each of said first user device and one or more second user devices to create an entry in a calendar application within each respective user device

In a second aspect of the invention there is provided a calendaring and messaging system comprising a user interface operable to display a plurality of items chronologically in a conversation stream; wherein the plurality of items comprise one or more conversation items and one or more item occurrence items, wherein one or more item occurrence messages relate to the occurrence of an event at an event time, and said user interface is operable to display the one or more item occurrence messages in said conversation stream at the event time even when the event time is in the future.

Other non-essential features of the invention are as claimed in the appended dependent claims.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described, by way of example only, by reference to the accompanying drawings, in which:

Figures 1A and IB comprise flow diagrams illustrating an event creation flow according to a known method;

Figure 2 is a schematic illustration of a calendaring and messaging system according to an embodiment in relation to a network and user devices;

Figures 3A and 3B comprise flow diagrams illustrating an event creation flow method in accordance with an embodiment;

Figures 4A to 4F comprise screen representations chronologically illustrating an event creation flow method in accordance with an embodiment;

Figures 5Ato 5D comprise screen representations chronologically illustrating a navigation icon forming part of user interface in accordance with an embodiment;

Figures 6A and 6B each comprise screen representations illustrating a tutorial generated when the end of a flow is encountered in accordance with an embodiment;

Figures 7A and 7B each comprise screen representations illustrating a chat group and an event group respectively; and

Figure 8A, 8B and 8C comprises screen representations illustrating a calendar drawer function. DETAILED DESCRIPTION OF THE EMBODIMENTS

When a user (designated the organiser) sets up an item or event using present calendaring software which operates in accordance with the iCalendar specification format, the organiser typically sends an invite to a number of other users (designated attendees). The organiser of the item is able to designate which users/attendees will receive the invite. These attendees are able to respond with their availability via an iMIP email. When updates are made to the item by the organiser, the latest copy is exchanged with the attendees via this iMIP email transport method. For collaboration purposes, only the organiser can make changes to the item and its attendees. Only attendees are allowed to make changes to their own availability in regards to the scheduled item.

Many providers allow non-organisers to make private edits to their copy of the iCalendar items, however these are not synced to other attendees. These private edits are overwritten whenever the organiser makes their own modification and the iCalendar item is synchronised via iMIP.

Some providers allow non-standards compliant multi-organiser editing of iCalendar items for calendar users exclusively within their own ecosystem. This is made possible by non-iMIP syncing inside their own system amongst their own users.

Organising an item that is to be shared with attendees invariably involves preceding and subsequent communication with all parties. In recent times, some chat services have added integrations with calendaring services to facilitate such conversations. iCalendar’ s single organiser model has such restrictive collaboration due to its decentralised design: each participant holds their own copy of the item on their own server, such that there is no canonical shared resource. Such decentralisation makes it extremely difficult to enforce mutual exclusion on shared resource editing. For example, if multiple organisers were permitted and both organisers were to make an edit at the same time, a race condition will result in one of the organiser’s edits being lost. It is for this reason that only a single organiser can edit the item and only the attendees can edit their own statuses. With this model, any merge conflicts are trivial to resolve as the permissions are clearly set out. For example, if an attendee sends the organiser an update to the item that has a difference beyond their own attending status, the organiser will discard such an update.

Furthermore, the iCalendar/iMIP system has no concept of versioning as its database structure is flat, only storing the latest copy of the event. Items are kept synchronised between servers but its design has no shared record of the changes made to them, and as such there is no historical record. This is again due to its decentralised design. Keeping such a record in sync between servers is impossible without an intentional design to detect errors that may have been introduced during transmission or storage. Without such a design, delivery of synchronisation updates would not be fault tolerant.

With only one organiser having write privileges, the attendees are powerless to make their own changes. In some scenarios this is preferred, but in many others this a source of inefficiency. All edits have to be routed through a single point of failure: the organiser. If the organiser is delayed in editing an item, then all attendees will be delayed in receiving this change, even if they have all agreed to the change; e.g., via a shared communication channel.

Figures 1A and IB illustrate the present flow for event creation. In Figure 1A an organiser (Sam) sends 10 two attendees (Jane, Sally) an iCalendar item via iMIP comprising an invite for an event (lunch). In Figure IB one attendee (Jane) responds 20 to the invite by changing their status as going in the iCalendar item and sending it via iMIP back to the organiser. The organiser updates 30 their copy of the item to reflect this change and sends it on to the other attendee (Sally) via iMIP

The ability for non-organisers to make their own unsynchronised private edits to iCalendar items further limits the potential for collaboration as this means that differences can be found between each participant's copy of the event. The non-canonical, non-atomic nature of iCalendar/CalDAV (Calendaring Extensions to WebDAV) does not readily lend itself to implementation of a real time, canonical environment such as a collaborative messaging service. This makes their integration with such existing services inevitably incompatible.

The internal-only, multi -organiser approach some providers have adopted is, by its very nature, limited to users of the same service. It is also obscure and non-obvious to participants who do not expect such functionality within a user interface that is identical to the single-organiser model, and opaque in highlighting that such functionality is only available to users of that same service. For example, a user of Google Calendar can enable the “modify event” privilege for attendees but, despite this being enabled, if a user of Microsoft Outlook is included as an attendee, they are unable to make such modifications as they are not a Google Calendar user. This confusion leads to such functionality being rarely utilised, and to go unnoticed when it is enabled.

Any integration with calendars offered by chat services or communication services, is typically limited to the form of a message in the conversation at the time when the item has been scheduled or updated by an organiser. As many communication services support identities that are not email addresses, such as phone numbers, usernames, identification numbers, etc., not all members of the service can receive such iCalendar invites.

However, once scheduled, a message is only created to confirm the scheduling or updating of said item. As iCalendar is non-canonical, this message will reflect the organiser’s copy of the event. As participants can make private edits to their own copy, this message is less relevant and makes collaboration unreliable.

The item is not visible within the chat feed in a time relative manner. Therefore secondary views are required to list upcoming or historic items chronologically. Furthermore, without such time accurate positioning of when the item is set to occur, and if it has a duration, when the item is set to end, the conversation is structured around when the item was created or updated and not the more natural structure of when the item is scheduled. If the user were to scroll back through the conversation, it would not be demarcated around the occurrence of the item(s) which, due to the nature of the system, is often the topic of the discussion. This lack of relevant context makes navigating the conversation difficult.

End-to-end encryption E2EE provides significant privacy and security benefits for users by encrypting their data with a private key only they can access. This means not even the service they are using can access the data they are inputting. In recent times, E2EE has become popular in Instant Messaging services but communication mostly still occurs through unencrypted channels such as email. No major provider offers E2EE calendaring. With the aforementioned preceding and subsequent communication around the event as well as the event not being E2EE, sensitive details are readily accessible by the calendar and communication providers as well as to the public in a data breach.

Furthermore, the user’s name and email address are held in plain text on the iCalendar item within each attendee’s copy. This again exposes this personally identifiable information to first party providers as well as to the public in a data breach.

The iCalendar standard allows the customisation of a calendar’s appearance to those who have access to it. With iCalendar items being synced between different user’s calendars, the customisation is not shared. iCalendar items cannot be customised beyond their text values as per the standard. This leads to a lack of shared categorisation and organisation of the event, making items non-glanceable and hard to scan for subject.

As communication is necessary to organise the event, and this communication often being around scheduling and availability, the lack of quickly accessible calendars in the current state of the art forces users to switch between multiple applications (instant messaging, email, calendar) to coordinate and plan the event.

Furthermore, due to this lack of centralisation between communication and calendaring, it is not currently possible to view the events shared between users. For example, if a user is messaging a friend, they cannot access the shared events that they are both attending within the same application.

To address the issues described above a combined messaging and calendaring system is proposed, which allows all users to modify a single canonical copy of an item (e.g., event or task) whether they are an organiser or invitee/attendee. Regardless of which user amends the item, all users of a conversation group will be notified of the change, and will have their calendars updated accordingly. The proposed method and system will be backward compatible with iCalendar.

The proposed system may comprise an E2EE combined messaging and calendaring system. In such a system, each user holds a symmetric pair of private and public keys. Their private key is in their full control and only accessible to them. Their public key is stored on the system. The system allows the lookup of public keys by index of the user’s identity document ID. IDs can only be retrieved by the requester by knowing the respective user’s phone number, email address, or other unique identifier. The system encrypts shared data, notably the event group and its messages as detailed below, by use of the user’s private key and the known public keys of the group. This encryption is carried out entirely on the user’s device removing the possibility of the system from ever accessing the sensitive information. The encrypted payload is then distributed by the system to all relevant parties. Those parties can only decrypt the information with their respective private keys.

As it is common for users to upgrade their devices from time to time, a method of securely transferring their private key between devices is proposed. The system allows the secure backup of private keys by envelope encryption. This method encrypted the private key with a secret password only known to the user. The encrypted private key is then stored by the system and is only decryptable with knowledge of the user’s secret password. The system stores no copies or references of this secret password.

To protect user’s profiles, as well as give them access to previous messages sent within an event group before they joined, the system may use a mutable group key to encrypt such information. Access to this key can be modified by participants to enable access to new participants of the event group. This allows previously encrypted messages and event information to be accessible by future participants of the event group.

Furthermore, the same technique may be used to secure the user’s profile data. Their data is encrypted with a group key of their control. The group key is only accessible to the participants in their event groups. By requiring users to opt-in to joining event groups, they can reassured that only known users can access their private profile data (such as Personally Identifiable Information including their full name, phone number, email address, etc.).

In an embodiment, the creation (or editing) of an event will generate a future message or entry in the conversation timeline, located at the time when the event is scheduled to start. A further future message or entry for a scheduled finish may optionally also be generated at the appropriate time in the conversation timeline. In this way, one or more upcoming items may be displayed within a conversation timeline, not only at the time they were created or modified, but also at the time they are set to occur.

As such, the user interface may comprise a conversation UI which generates a conversational stream of collaborative updates on each event. In implementing this, the group and all its items are stored together. This is a monomorphic design as opposed to the typical polymorphic design seen in present arrangements, where message items, task items, event items etc. are treated as fundamentally different items. As such, the group data and item data in the proposed system will be of the same type (an event group). The resulting system is much more versatile and easier to optimise as a result.

The proposed system may comprise two or more group types. One group type may comprise a chat group (e.g., a group of users for particular chat topics such as (purely for example) a family group, a work group, a football group etc.). At a basic level, the chat group may work in a similar way to well-known chat applications. A second type of group may comprise the aforementioned event group, with an event group corresponding to a particular event (e.g., comprising all the invitees and inviter, and/or all attendees of an event). Event groups may be initiated from within chat groups or elsewhere (e.g., from within direct messages or the calendar view/calendar tab). Both types of groups may have instant messaging functionality, and both may be end-to-end encrypted, including their details.

In addition, many present messaging applications integrate with third party systems. This means that the event data may be stored on a completely different server/system than corresponding message data; this can be a major issue if one of the systems should go down. In the proposed system, each event is stored on the event group; this results in zero redundancy and removes the aforementioned problems.

Figure 2 is a diagram of a system according to an embodiment. The system may be based around a main server MS or operator server which hosts a server application for providing the calendaring and messaging functionality as will be described. The main server MS connects to (any number of) multiple user devices UD1, UD2, UD3 (which may comprise any computing device such as inter alia a (e.g., desktop or laptop) computer, tablet or smartphone) other over a network NW (e.g., the internet). Each of the user devices UD1, UD2, UD3 may be connected to the other user devices over network NW.

In particular, the server application may provide the functionality to store all canonical versions (latest versions) of all event groups and messages on the main server MS including any iCalendar item, and communicate these to the user devices as required. It will also have the functionality to generate a group address (an email address for any new group e.g., of attendees inclusive of an organiser). Through this email address, the group becomes the organiser of the iCalendar item within the context of the iCalendar standard; all participants of the group are included only as attendees on the item. Optionally each of the user devices may comprise a client application resident thereon. The server application may provide the user interface described below and in relation to Figures 4, 5 and 6. Alternatively, this user interface may be provided by the (or another) server application on the main server and accessed through a browser or other suitable software on a user device.

Because the main server holds the canonical copy of the iCalendar item, the system provides a centralised calendaring system which is compatible with the iCalendar standard. An “organiser” or originator of an event will no longer have organiser privileges to amend externally (of the server environment) the item via sync. Instead, all of the participants, including the organiser, are actually attendees within the context of the iCalendar standard and can only modify their attendee status externally via sync. This allows for multi-organiser collaboration inside of the server environment which synchronises to participants’ calendars regardless of their provider.

Furthermore, due to the centralised nature of the system, the system can extend the standard iCalendar properties and make these accessible to its users within its system. For example, a category can be set on an event group or on individual event items. These categories may be used to organise the user’s shared events in their diaries. Categories can include, but are not limited to, one or more of: General, Reminder, Shopping, Home, Party, Holiday, Activity, Entertainment, Travel, Drink, Learning, Wellbeing, Meal, and/or Work. These are purely example categories. The categories may be colour coordinated and/or have a dedicated icon (e.g., knife/fork for a meal, aeroplane for a flight/travel etc.) and shared between all participants of the event group, meaning that each categorised event appears with the same visual style within the systems calendar. This allows the user to see a breakdown of where they spend their time between the categories.

Conversations within the proposed system are made up of chat groups and event groups of users (both of which may comprise conversation groups). One or many iCalendar items can easily be added to an event group with a 1 : 1 mapping of group participants to attendees on the items.

An event group itself can also be scheduled. This makes an event group in such a system a facsimile of a shared calendar. Scheduling such items are optional, and may be done for example when an idea is proposed but a specific plan is yet to be finalised (e.g., with respect to date and time). Furthermore, all details of the event group and iCalendar items are optional allowing the conversation group to capture all of the necessary planning without restriction.

Before the scheduling of the event group, discussions may be had within the conversation group to coordinate details. A detail often coordinated on via such communication is the group’s availability. In an embodiment, the system may provide a readily accessible calendar drawer from within the conversation screen. This allows for quick access to the user’s calendar when discussing such availability with others. This calendar drawer can be viewed at approximately half height, allowing the user to not obscure the conversations whilst still cross referencing their diary. For example, the calendar drawer may be displayed in much the same way as the keyboard/text input is typically displayed. The system can optionally sync in a user’s third- party calendar provider’s events to interlace with the system’s own within this calendar. This allows each user to see an accurate depiction of their agenda within this calendar screen.

A tabs functionality within the Keyboard Calendar may be provided, for example, when the user is Direct Messaging one or more other users. Such tabs may comprise an “all” tab to show all events of the user and a “shared” tab to show only the events shared with the other one or more users.

The proposed system may interlace all the items and messages (e.g., conversational messages, events, item creation messages, item edited messages, and item occurrence messages) together and display them chronologically. The UI may comprise a past section which displays historical items and/or historical messages chronologically and a future section which displays future items and/or future messages chronologically. The UI may also comprise an input bar to insert user messages and send updates to items into the conversation. In an embodiment, the input bar may be located between the future section and past section (at least when the message stream is displaying messages which are in the vicinity of the present time). For example, the future section may be below the input bar and the past section above the input bar or vice versa. Item occurrence messages and user messages together form the structure of the conversation relative to when the items occurred.

When a user scrolls or moves the message stream further along into the past or future, the input bar may move to the top or bottom of the screen as appropriate. For example, if the user device is only showing historic items/messages, the input bar may be at the bottom of the display, with the remainder of the display showing only the past section and no future section. Similarly, if the user device is only showing future items/messages, the input bar may be at the top of the display, with the remainder of the display showing only the future section and no past section.

For example, a creation message may display as: “user created X”. Updates to the item are possible via an item edited message where the previous value of the item is amended to the user’s desired new value. Such an update item message may displays as: ’’user updated X to Y”. iCalendar items are optionally synced to each group member’s calendars via any suitable method, e.g. one or more of: iMIP emails, user-subscribable calendar feed URL, an Application Programming Interface with the user’s calendar provider. In the proposed system, instead of a user being the organiser on the iCalendar item, the group’s automatically generated email address is the organiser. All iMIP emails may be sent from this address, ensuring that the system is backwards compatible with iMIP. External attendees are able to respond to the event from within their calendars as well as within the system. This reflects the true nature of the item: the group of participants is the true organiser, not a single individual.

The aforementioned categorisation of events can be made backwards compatible with the iCalendar standard by the system automatically prefixing the event title with an appropriate emoji character when optionally syncing the event. For example, an event group or event item categorised as Party in the system could be synced with an event title prefixed with a balloon emoji.

As the iCalendar items are individually synced by the system for each user, they can be tailored to each attendee. Furthermore, by accessing such uniquely synced iCalendar items, the attendee has verified access to that calendar provider and their identity. In conjunction, the system can therefore send alterations to the invitation specific to that user for their benefit. For example, the iCalendar item’s description sent to user A can contain a secured link to quickly access their specific account in the system. Whereas the iCalendar item’s description sent to user B can contain a different secured link specific to their account. This enables fast but secure access to the system without requiring users to again confirm access to their email address.

Another benefit of tailored iCalendar item sync is that, when the group comprises only two participants as a "Direct Message", the other person’s name may be displayed to make this contextual for either participant: e.g., user A sees "Call (with user B)" and user B sees "Call (with user A)" in their respective calendars.

Figures 3A and 3B illustrate an event creation flow according to an embodiment. An organiser (Sam) sends 40 two (or any other number of) attendees an iCalendar item via a server application on the main server. In this scenario, Sam is the creator of the event within the server application, but the event’s organiser in the context of the iCalendar is the group’s unique email address as generated by the server application. This means attendee responses are sent via iMIP to this server generated email address and not Sam’s. An attendee responds 50 to an invite by changing their status as going in the iCalendar item and sending it via iMIP back to the “organiser”, in this case the group’s email, irrespective of how the calendar item was synced to the user’s calendar provider. The server application processes this inbound iMIP email, updates the canonical copy to reflect Jane’s status change, and optionally distributes 60 the updated item to Sam and Sally via iCalendar item sync.

The proposed system further provides the ability to sequence updates to events in a chronological conversation via versioning. As already explained, to create an event, an event group is sent optionally containing the event.

The system extracts the information held within the iCalendar item stored with the group to compute a future or historical preview of this item as an item occurrence message. If the item has a set duration, a second item occurrence message may be generated to reflect its end time. The messages are merged with the computed item occurrence messages and are sorted chronologically to form the sequence of the conversation. The system may divide the messages by the present time, bifurcating the stream into an historical thread and an upcoming thread intersected by an input bar.

Figures 4A to 4L comprise a method flow in terms of screenshots for event generation and collaboration (e.g., within an already established event group) according to an embodiment. In this system, user 1 U 1 can create a message group with user 2 U2 via their email address and/or their phone number and/or via a shareable URL (Figure 4A). By default, user 1 and user 2 both have admin privileges (although this can be configured to be otherwise) and so can add or remove other participants and add or update events in the group (Figure 4B). User 1 can add an event into the group by an appropriate action e.g., via the input bar IB such as tapping (+) next the input bar IB. This action adds a pill PL or chip to the input bar which represents the addition of the event (Figure 4C). User 1 can also include a text message with the addition of the event (Figure 4C). To submit this event and message, user 1 presses the (†) button in the input bar. User 2 then receives this event and message in the group (Figure 4D). User 2 can then respond to this event’s invitation by tapping/clicking on the event in the future section or future window FW of the conversation, either in the message sent by User 1, or by tapping/clicking the Respond button visible in Figure 4D. The past section or past window PW comprising historic messages may be located above the input bar IB. Doing so presents the display of Figure 4E, where User 2 can choose their attending status e.g., as one of : “Not Going”, “Interested”, or “Going”. Once selected, a pill or chip is added to the input bar to represent the changing of their status. User 2 can tap/click (†) to send this into the group.

User 2, as an admin of the group, can also tap/click on the event to modify its details or their attending status (Figure 4F). In Figure 4F, user 2 adds a Location detail to the event. User 2 can tap/click (†) to send this into the group with an optional message (Figure 4F). Once user 2 has sent the update in Figure 4F to the group, user 1 can clearly see the changes and respond accordingly (Figure 4G). Both User 1 and User 2 will receive a calendar invitation for this event that reflects their attendee status according to the server application (Figure 4H). This event invitation may comprise a unique description per attendee with a secured link to access their account (Figure 41). As can be seen in this Figure, the event title in the invite may automatically comprise the group name in parentheses. This provides helpful context for the participants without them having to write such typical titles (e.g. "Daily Design Review" vs simply "Daily Review" being automatically expanded to "Daily Review (Design Team)" in the corresponding event).

Entering the group automatically centres the scroll position offset to the input bar with a preview of future events (Figure 4J). If the User scrolls up, they see further future events below (Figure 4K). If the user scrolls beyond the natural inline position of the input bar it “pins” to the bottom/top of the screen and an icon or floating button FB to navigate the user “Back to now” is automatically displayed (Figure 4L). Tapping/clicking this button returns the scroll position to that in Figure 4J. Referring to Figures 5A to 5D, these describe optional additional functionality for the icon or floating button FB illustrated in Figure 4L. This floating button may also operate to navigate the user to unresponded event invitations in the conversation. In this scenario, the contents of the floating button FB states the date and time of the unresponded event (Figure 5A). This button will navigate the user to each unresponded event invitation until all have been responded to, at which time it will revert to navigating the user back to “now” (Figure 4L). This button may automatically pin and display a directional arrow based on the user’s offset to now. For example, if a user scrolls into the past section and the navigational element directs them to an later time, the button will pin to the bottom of the screen and point downwards (Figure 5B). Similarly, if a user scrolls into the future section and the navigational element directs them to an earlier time, the button will pin to the top of the screen and point upwards (Figure 5C).

Once the user has tapped the navigation button to take them to a corresponding unresponded event invitation, the feed item may comprise a “respond” button to highlight the need to respond to the event (Figure 5D). Tapping this “respond” button presents the user with the invitation UI shown in Figure 4E.

Figure 6A illustrates the scenario where there are no upcoming events in the feed and Figure 6B illustrates the scenario where the user has reached the end of the feed. In each case, the system displays a tutorial informing the user that there is no upcoming or further events respectively. In both cases, the user can tap “add” within the tutorial to quickly navigate to the add event screen (Figure 4C).

Figure 7A shows an example of a chat group and Figure 7B show an example of an event group. Both of these group types may be provided with instant messaging functionality. Furthermore, both of these group types may be E2EE, including their details.

Figure 8A illustrates the proposed Calendar drawer CD (calendar pop-up navigation or keyboard calendar) functionality. The Calendar drawer may replace the keyboard below the input bar in a conversation, while letting the user quickly switch back to their keyboard by tapping in the text input area of the input bar. As such, the Calendar drawer may mimic the exact height and placement of a device's software keyboard.

In an embodiment, the Calendar drawer may be contextual to where it has been accessed from. For example, the calendar drawer may present particular calendar entries, dates, event groups and/or chat groups relevant to the item/group from which the calendar draw was accessed. For example, the Calendar drawer of Figure 8A may be that seen if it were accessed from the Event Group “Dinner” as illustrated in Figure 7B. The user can be presented with contextual actions within the Calendar drawer. For example, within a Chat Group, a contextual action may be an icon or entry to create a new Event Group. From within an Event Group, a contextual action may be to schedule or reschedule the event tied to the current Event Group. For example, if the user taps "Reschedule Dinner to Sat 15 Jan" in the Calendar drawer shown in Figure 8A, they may be shown a corresponding form with the alteration pre-filled to the Event Group's schedule, where they can modify and confirm accordingly.

In another example, if a user has taps a detected date within a message or conversation item within a chat group or event group, the Calendar drawer may automatically open, deep linking to that date, e.g., listing entries for that date (e.g., and possibly neighbouring dates) and/or inviting a new event to be scheduled.

The Calendar drawer may act as a navigation aid within the system, e.g., it can be used to navigate quickly between event groups and/or chat groups. For example, when from a first event group, a second event group is selected via the Calendar drawer, the display may be switched to the second event group while preserving as much of the UI state as possible bar the specific details and messages of the second event group.

In Figure 8B, a tab feature of the calendar drawer is shown. When the user is Direct Messaging one or more other users within the system and outside of a group or event chat, the calendar drawer may comprise two tabs: a first tab or “shared” tab which lists all of the events that the current user shares with the users they are corresponding with in that direct messaging group and a second tab or “all” tab which displays all of their events. The use of such tabs within the drawer allows quick switching between what is shared with those other users and what is private to that user.

In Figure 8C, a similar tab feature is shown in relation to a chat group. As has been described, Chat Groups may be invited to Event Groups, in which case the event group may be a facsimile of the chat group. For example, you could have a Chat Group called “Uni Friends” and another called “Home Friends”. The user may invite one or both groups to Event Groups, for example "Birthday Party" . Then, inside each Chat Group, the Keyboard Calendar can show an additional "Group" tab.

In an embodiment, a new event groups may be created from any one or more of the following three places: from a main calendar display (e.g., a tab within the calendar display), from a chat group (e.g., via the (+) tab in the top comer of the display shown in Figure 7A), or from within the Calendar drawer: In each case, a New Event Group form may be presented which may be similar regardless of from where it was accessed, but may take contextual information from where it was navigated. For example, if accessed from the Calendar, the date selected in the Calendar may be pre selected in the New Event Group form. If accessed from a Chat Group, the participant(s) of that group may be preselected as participants of the new Event Group (although editable such that a user can add more participants than the original participants of the Chat Group), but no schedule pre-fdled. If accessed from a Chat Group's Calendar drawer's New Event action, both the schedule and participants may be pre-fdled.

In an embodiment, new Chat Groups are created from one place only (e.g., the Chats tab). Chat Groups are designed to be stable, i.e., should the same participants who already exist in a present Chat Group be selected when setting up a new Chat Group, tapping Done will then navigate to that present group rather than set up a duplicate Chat Group. The app will only create a new Chat Group if the participants differ from one already created. The benefit of this is that it reduces groups with the same participants.

It may be appreciated that where E2EE is used, the nature of E2EE profiles means users have to accept invitations with other users to join Event Groups and Chat Groups: By accepting, the user is re-encrypting their profile with E2EE and giving it access to current and future members of that Event Group and Chat Group.

In summary, a system is described herein comprising (at least according to some embodiments) an E2EE calendaring and messaging system which provides the ability for users of different calendar systems to collaborate on the creation and editing of an iCalendar item in a fully secure manner. Also provided is the ability to navigate items in the conversation thread according to when they were created or updated and also to when they are set to occur and (optionally) end. The proposed user interface provides seamless integration with upcoming items and previous messages within the same view and accessible at all times to users within the conversation. As the item is optionally synced in a method of the user’s choosing, users of competing calendaring services can all collaborate on the same event inside the server application and have it sync seamlessly into their calendar using the iCalendar protocol.

Claims

1. A calendaring and messaging system comprising a main server, a computer program and a communications interface to communicate with a network, wherein the calendaring and messaging system is operable to: receive a first item from a user device over said network, said first item specifying an event and identifying one or more second user devices; create a conversation group comprising said first user device and one or more second user devices; generate a group address for the conversation group; and send a calendar message to each of said first user device and one or more second user devices to create an entry in a calendar application within each respective user device.

2. A system as claimed in claim 1, wherein said calendar message comprises an email message compliant with the iCalendar Message-Based Interoperability Protocol and/or a successor protocol.

3. A system as claimed in claim 2, being operable such that the conversation group is the organiser of the event via said group address and each of said first user devices and one or more second user devices is an attendee in the context of the Internet Calendaring and Scheduling Core Object Specification format.

4. A system as claimed in any preceding claim, being operable to store each of user generated items, item creation items, item edited items, and item occurrence items with a respective said conversation group.

5. A system as claimed in claim 4, wherein said user generated items comprise at least conversational items and event items.

6. A system as claimed in any preceding claim, being operable such that the items stored by the calendaring and messaging system are stored on said server.

7. A system as claimed in claim 6, wherein each of said items stored on said server comprise canonical versions of and/or a source of truth for said items.

8. A system as claimed in claim 6 or 7, being operable such that at least said first item is editable by each of said first user device and one or more second user devices.

9. A system as claimed in claim 8 wherein, when one of said user devices edits said first item, said system is operable to: synchronise each of said first user device and one or more second user devices to amend said entry in a calendar application within each respective user device; and amend a respective one or more item occurrence items corresponding to said event.

10. A system as claimed in claim 9, wherein, when one of said user devices edits said first item, said system is further operable to generate an item edited item.

11. A system as claimed in any of claims 6 to 9, wherein the system is operable to sequence updates to said first item chronologically.

12. A system as claimed in any preceding claim, being operable to generate an occurrence item for at least one occurrence time corresponding to said event, said occurrence item for display in a user device as a future item.

13. A system as claimed in claim 12, being operable wherein the calendaring and messaging system comprises a user interface which displays all of said items chronologically in a conversation stream.

14. A system as claimed in claim 13, wherein the conversation stream comprises a future section comprising future items, wherein future items comprise said occurrence items at each of said at least one occurrence times in the conversation stream.

15. A system as claimed in claim 14, wherein the conversation stream comprises a past section displaying historical items.

16. A system as claimed in claim 15, wherein the user interface comprises an input bar displayed between said future section and past section at least when said conversation stream is centred at or near the present time.

17. A system as claimed in claim 16, wherein the user interface is operable to move the input bar to a first of the top or bottom of the display when the conversation stream is displaying only historical items and to a second of said the top or bottom of the display when the conversation stream is displaying only future items.

18. A system as claimed in claim 17, wherein said user interface additionally displays an icon when the conversation stream is displaying only past items or future items, the selection of which will navigate back to the present time in the conversation stream.

19. A system as claimed in claim 18, wherein said user interface may be operable such that selection of said icon or another icon navigates to an item requiring response.

20. A system as claimed in any of claims 13 to 19, wherein the user interface is implemented: within an application on each of said first user device and one or more second user devices; or on said main server.

21. A system as claimed in any preceding claim, wherein said calendar message is tailored individually for each user device to which it is sent.

22. A system as claimed in any preceding claim, wherein the system provides at least two types of conversation group, an event group and a chat group; and said step of creating a conversation group comprising said first user device and one or more second user devices comprises creating an event group.

23. A system as claimed in claim 22, being operable such that an event group may be initiated from within a chat group or a calendar display.

24. A system as claimed in claim 22 or 23, wherein each event is associated with a dedicated event group.

25. A system as claimed in claim 22, 23 or 24, being operable to enable an event group to be created without a location and/or time being specified, the event group enabling these to be discussed and specified within the event group.

26. A system as claimed in any preceding claim, operable to present a calendar drawer on a user device as a result of a user action.

27. A system as claimed in claim 26, wherein the calendar drawer uses a window functionality of, and temporarily replaces as appropriate, a software keyboard of a user device.

28. A system as claimed in claim 26 or 27, being operable such that an event group may be initiated from within the calendar drawer.

29. A system as claimed in any of claims 26 to 28, wherein the calendar drawer provides a contextualised calendar display and/or options based on where it was navigated from.

30. A system as claimed in any preceding claim, comprising end-to-end encryption such that the system only stores encrypted item, group and/or user information.

31. A system as claimed in claim 30, wherein each user holds a symmetric pair of a private key and a public key, the private key being only accessible to that user and the public key being stored on the system.

32. A system as claimed in claim 31, wherein each private key is encrypted with a secret password known only to the respective user.

33. A system as claimed in any of claims 30 to 32, being configured to use a mutable group key to encrypt previously encrypted messages and event information and allow it to be accessible to new participants of a particular conversation group.

34. A system as claimed in any of claims 30 to 33, wherein the system is configured to encrypt a user’s profile data with a group key in the user’s control, the group key being accessible only to participants in each conversation group.

35. A calendaring and messaging system comprising a user interface operable to display a plurality of items chronologically in a conversation stream; wherein the plurality of items comprise one or more conversation items and one or more item occurrence items, wherein one or more item occurrence messages relate to the occurrence of an event at an event time, and said user interface is operable to display the one or more item occurrence messages in said conversation stream at the event time even when the event time is in the future.

36. A system as claimed in claim 35, wherein the conversation stream comprises a future section comprising future items, wherein future items comprise said occurrence items at each of said at least one occurrence times in the conversation stream when said at least one occurrence times are in the future, and a past section displaying historical items.

37 A system as claimed in claim 36, wherein the user interface comprises an input bar displayed between said future section and past section at least when said conversation stream is centred at or near the present time.

38. A system as claimed in claim 37, wherein the user interface is operable to move the input bar to a first of the top or bottom of the display when the conversation stream is displaying only historical items and to a second of said the top or bottom of the display when the conversation stream is displaying only future items.

39. A system as claimed in claim 38, wherein said user interface additionally displays an icon when the conversation stream is displaying only past items or future items, the selection of which either: navigates back to the present time in the conversation stream or navigates to an item requiring response.

40. A system as claimed in any of claims 35 to 39, where said items comprise said message items, other user generated items, item creation items, item edited items, and said item occurrence items.