Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

Calendar and Todo Updates Using Deltas

IP.com Disclosure Number: IPCOM000247120D
Publication Date: 2016-Aug-08
Document File: 2 page(s) / 66K

Publishing Venue

The IP.com Prior Art Database


Calendar and todo invitations are exchanged using the iCalendar format which is an update on the vCalendar format. Whenever an invitation is sent, all details of the invitation are always sent in the message whether the invitation is the original or an update. This disclosure proposes an extension to the iCalendar standard such that meeting and todo updates are sent using only a delta of the information contained in the original invitation.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 54% of the total text.

Page 01 of 2

Calendar and Todo Updates Using Deltas

The advantages of this are mainly for the email hosting providers who (especially in todays cloud based services world e.g. GMail, Outlook.com, Yahoo Mail, etc) will

have a reduced need for storage space. There is also some advantage brought about by the reduced payload and hence lower requirement on network usage during transfer.

    Calendar and todo events are sent using the iCalendar format and always contain the full information for the event taking place whether it is the original version or simply an update. This disclosure proposes a new iCalendar block called VEVENTUPDATE (or for todo items VTODOUPDATE) that demarks the information to be a delta upon the current invitation and thus saves storage space and network bandwidth.

    The message sequence ID number is defined to apply the delta to the previous information received. For example, the original message with sequence ID=1 would be followed by a subsequent message with sequence ID=2 and thus the delta would be applied to the original[1]. However, should a further update occur

with sequence ID=3, the delta would be applied to the current version of the information obtained by having already applied the delta from the second message to the original.

    [1] Note: in reality sequence ID=1 is never sent, if this element is missing the message is assumed to be the first in the sequence.

    By example, the wikipedia page on iCalendar ( https://en.wikipedia.org/wiki/ICalendar) contains the following simple calendar invitation example:

PRODID:-//hacksw/handcal//NONSGML v1.0//EN