WO2009019480A2

WO2009019480A2 - Email management

Info

Publication number: WO2009019480A2
Application number: PCT/GB2008/002683
Authority: WO
Inventors: Anthony Kujawa
Original assignee: Anthony Kujawa
Priority date: 2007-08-08
Filing date: 2008-08-07
Publication date: 2009-02-12
Also published as: GB2451654A; GB0715384D0; WO2009019480A3

Abstract

The present invention provides a method of managing an email message having a subject field, the method comprising: determining a status of an addressee of the email; and modifying the subject field of the email for that addressee in dependence upon the status of that addressee. The present invention further provides an email management system for managing emails having respective subject fields, the system comprising: a determining unit operable to determine a status of an addressee of an email; and a modification unit operable to modify a subject field of an email for an addressee in dependence upon a determined status of that addressee.

Description

EMAIL MANAGEMENT

The present invention generally relates to a method of managing incoming emails. More particularly, the present invention relates to a method of email management requiring user response to system prompting to determine action to be taken in respect of the email communication.

Background to the Invention

With the increasing reliance on computer technology in the business world, and the increased convenience of electronic forms of communication, individuals in the workplace are often inundated with email communications throughout the working day. Not only that, as email communications can be sent and held pending on the system until accessed through the destination email account, email communications may be sent during non-working hours and accumulate for collection by the destination account user the next day.

Due to the accessibility of the internet and the ease with which email communications can be sent, both to individual email addresses and groups of such addresses, the vast numbers of emails which are received each day in the workplace results in a significant amount of time being spent by an individual during the working day simply dealing with incoming email communications. In addition, many individuals fail to move the incoming emails from their inbox after reading. As a result, the emails accumulate, in many cases to such an extent that additional time is wasted trying to find particular email communications in order to re-read or action them. Further, accumulation of emails in the inbox of a user's account uses up storage space often resulting in no remaining space in the user's inbox to receive further email communications until one or more existing email communications are deleted or moved out of the inbox. This situation is further exacerbated when the email communications accumulating in the user's inbox include attachment files. The presence of attachments results in the available storage space being used up even more quickly. Such a situation may be critical in a business environment where important email messages fail to be delivered to a destination inbox because the recipient's email folder is full.

Further, if a user has allowed email communications to accumulate in their mailbox, accessing the mailbox from a remote location may result in significant consumption of network bandwidth. Network bandwidth over-utilisation can create problems relating to reduced data transmission speed and potential data corruption issues. Thus, efficient email management is an important way in which network bandwidth over-consumption can be avoided.

Many systems exist in the prior art which automatically carry out specified actions on incoming, and often also outgoing, emails. For example, systems exist which automatically store the email and possibly the attachment at a location remote from the inbox of the user. However, such systems are available in order to archive email communications and attachments in circumstances where, for example, the law requires that all communications are retained for a defined period of time after receipt. This is often the case in the office environment of legal firms and the like. However, such systems are automatic and the location at which the email communication is archived is predefined by the computer system, rather than the individual user of the destination email address. Further, such systems do not assist the individual in managing their incoming email, but rather, operate to store a copy of the incoming email on the computer system. Thus, such systems do not solve the problem of accumulation of emails in a user's inbox and the resultant storage space problems.

Thus, there is thus a need for a system which can avoid the accumulation of read emails in a user's inbox and thus avoid the productivity loss which results from users retaining email communication sin their inbox and the associated time wasted by the user trying to locate particular email communications within the inbox, for example, to re-read or to take action in respect of the email contents. There is also a need to assist a user in avoiding accumulation of read emails in their inbox resulting in the inbox of the user being too full to accept any further incoming email communications.

Summary of the Invention

The present invention seeks to address the problems of the prior art.

A first aspect of the present invention provides a method of managing an email message having a subject field, the method comprising determining a status of an addressee of the email and modifying the subject field of the email for that addressee in dependence upon the status of that addressee.

For example, if the email requires some action on the part of the recipient, the subject field may include a code or other designation text indicating that a response is requested or action required. However, if one of the addressees to whom the email is sent is not a primary addressee, the subject field may be modified to remove or amend the code or other designation text so that there is no confusion over whether a response or action is required from the non-primary addressee receipient. However, the primary recipient of the email will receive the email with the full non-modified subject text.

The term 'primary addressee' is intended to mean an addressee whose email address is input into the 'To' field of the email.

The term 'not a primary addressee' or 'non-primary' addressee is intended to mean an addressee who is not included in the 'To' field of the email, but who is intended to receive a copy of the email. For example, such an address may have their address input into the 'cc' (Carbon Copy) field or the 'bcc' (Blind Carbon Copy) field of the email. In one embodiment, the method further comprises sending the email to the addressee following such modification. Alternatively, the method further comprises receiving the email prior to such modification.

In either embodiment, modifying the subject field may include the addition or removal of at least one of a predetermined set of codes to the subject field. Such codes may be any desired codes such as, but not limited to, text characters, numerical characters and symbols.

The method may further comprise removing such an added code from the subject field if the addressee is not in a predetermined list of addressees.

Alternatively, the method may further comprise removing such an added code from the subject field if the addressee does not use a predetermined email management system. Thus, if a sender of an email uses an email management system that allows the inclusion of codes to the subject field to indicate, for example, when a response is required from the recipient, an addressee receiving such an email who does not use a similar email management system will not see the codes within the subject field. This assists in the prevention of confusion on the part of a recipient who is not familiar with such codes or does not operate within such an email system where such codes are regularly applied.

A further aspect of the present invention provides an email management system for managing emails having respective subject fields, the system comprising a determining unit operable to determine a status of an addressee of an email, and a modification unit operable to modify a subject field of an email for an addressee in dependence upon a determined status of that addressee. In one embodiment, the system further comprises a transmission unit operable to send such an email to the addressee following such modification by the modification unit. In an alternative embodiment, the system further comprises a reception unit operable to receive an email and to pass such an email to the determining and modification units prior to such modification. Thus, modification of subject field may take place before the email is sent, or after the email is received.

In either of the above embodiments, the modification unit may be operable to add at least one of a predetermined set of codes to a subject field of an email. Such codes may be any desired codes such as, but not limited to, text characters, numerical characters and symbols.

The transmission unit may be operable to remove such an added code from the subject-field if the addressee is not in a predetermined list of addressees.

Alternatively, or in addition, the transmission unit may be operable to remove such an added code from the subject-field if the addressee does not use a predetermined email management system.

A further aspect of the present invention provides a method for managing incoming email communications, the method comprising: receiving an email communication; storing that email communication in an inbox; upon closing of an email communication by a user displaying an indication of further processing options for that email communication to the user; receiving a user input in response to display of the indication; and processing the email communication in dependence upon that user input only when a user input is received, wherein the further processing options consist of deleting the email communication and storing the email communication outside of the inbox. By requiring the user to respond to prompts, action must be taken in respect of each email, thereby avoiding the build-up of email communications in the inbox and the subsequent problems such as loss of productivity due to, for example, time wasted by users trying to locate specific email communications within an inbox containing many accumulated emails, as well as the problem of lack of remaining storage space in the inbox with respect to receiving further email communications. This method provides support to the user to manage their email in an efficient and timely manner whilst still allowing the individual freedom to decide on the action to be taken in respect of each email communication. This empowers the user and contributes to a confident, motivated and enabled user, rather than imposing an automated system on a user whereby email destinations are predetermined by the system and cannot be controlled by the user.

In one embodiment of the present invention, the email communication may be stored in another folder within the mailbox for future action, such as a 'pending' or

'task' folder. This allows the user to store the email in a destination which designates it as being due future attention, but still removes the email from the inbox, thus reducing the number of email communications in the inbox. This management of read email communications avoids the significant loss of productivity that results from time being wasted re-reading email communications unnecessarily, for example, to identify email communications which require further action within a large group of email communications stored in the inbox. Instead, email communications requiring further action can be grouped together in a separate location from those requiring no further action, thus contributing to good email management and increased efficiency.

In a further embodiment of the present invention, the email communication may be stored in an archive storage area. This is a particularly effective solution where no action is required in respect of the contents of the email, for example, where the email is provided purely for the purposes of information, but should be retained in case its content is needed for reference purposes in the future. It is the case that for many industries email communications, as well as other written documents, need to be retained by law for several years before destruction or deletion. This facility allows a user the peace of mind of knowing that the email is being archived and can be retrieved if required, but does not have to be retained within the user's inbox and thus is not using up valuable storage space within the user's mailbox.

In one embodiment of the present invention, the email communication may be archived indefinitely. In this case, the email contents will be available to a user whenever required in the future.

Alternatively, the email communication may be assigned an expiry date defining when the email communication will be automatically deleted from the archive storage area. In this way, the lifetime of the email contents is defined. Thus, if the contents of the email will no longer be relevant to, or required by, a user beyond a specified date, the email will be automatically deleted on the designated expiry date provided by the user and will not use up valuable storage space even in an archive facility beyond the expiry date.

Any attachment files associated with the email communication may be extracted and stored remote from the mailbox. This is particularly effective in maximising the storage space available in the inbox and task folders etc. within the mailbox. The attachment files are often very large and storage space hungry, so to detach and store the attachments elsewhere is of great benefit in maximising the effective use of storage space and in reducing the delay incurred and load placed on the network when an individual is working on their email in a location remote from the site of their mail server.

In one embodiment of the present invention, a link to the remotely stored attachment file or files may be automatically created as part of the email communication and thus the attachment file can still be accessed via the email communication. Links to email attachments stored elsewhere may be provided as part of the original email so that the contents of the attachment can immediately be accessed on request by a user.

The extracting and remote storage of the attachment file or files may be automatic on closure of the email communication. This allows the process of detachment and storage of the attached file to be carried out without the input of the user. Thus the process is systemised and never neglected due to human failure to remember to action the removal of the attached file from the email communication and storage of the attached file in another location remote from the mailbox. In addition, the time saved by the user due to automation of this process is significant, especially when multiplied by the number of emails with attachments received by a user over a prolonged period of time.

In another embodiment of the present invention, at predetermined time intervals, for example daily, a message may be provided to the inbox detailing the email communications stored in any one or more of the pending folders within the mailbox. It is preferred that only one of the pending folders is used by a user specifically for the purpose of holding unactioned emails, and a reminder of the contents of that pending folder only could be provided to the user at specified time intervals. In this way, the user will not be able to ignore or forget that an email with content which requires action has been stored for future action at a more convenient time. This is a useful addition to the system which facilitates efficient actioning of emails whilst still allowing a degree of control by the user over the timing at which the email contents are actioned.

The message may be in the form of an email communication sent to the inbox.

Thus no additional effort is required by the user to recall that an email has been stored for future action as a message will be received in the inbox of the user to remind the user that the email is currently stored in a pending folder of the mailbox until such time at the email is moved from the pending folder by the user, for example, into archive storage, or is deleted.

There may be a single pending folder into which email communications may be moved from the inbox. Alternatively, several pending folders may exist into which one or more email communications may be moved from the inbox. For example, any one or more pending folders may comprise a folder optimised as a calendar, or a to-do list, or any other suitable folder for the receipt and retention of email communications which is not an inbox, such as one or more folders created for holding emails for future action.

In one embodiment, the user input may include information relating to the date in, for example, a folder optimised as a calendar, with which the email communication entry is to be associated.

In one embodiment, the system may create a default folder which, for the purposes of this explanation will referred to as the 'A' folder, into which emails are directed when no specific action has been instructed by the user with respect to where the email should be used after closing the email in the inbox. Thus, if after opening an incoming email a user tries to close the email currently residing within the inbox without providing instructions with respect to moving/deleting the email from the inbox, the user will be offered the option of returning to the open email or having the email moved to a folder created by the system, for example, the 'A' folder mentioned above.

If the user chooses to return to the open email, the user will be able to move the email to a folder of their choice, including for example, a pending folder or archive folder, or will be able to delete the email, as has previously been discussed. However, if the user chooses to have the email moved to the 'A' folder, the email will be moved from the user's inbox to the 'A' folder, any attachments being removed and stored outside the mailbox and a link to the attachment provided in the email stored in the 'A' folder.

All emails held in the 'A' folder will remain highlighted as unread, indicating that these emails have been unactioned.

The system will allow the user to specify that the system remind them of the content of the 'A' folder and select when such a reminder should be displayed.

It is intended that the 'A' folder operate in a similar manner to the inbox. For example, once an email is opened in the 'A' folder, the user will be prompted to move the email to a selected pending folder, such as for example, a task folder, calendar folder, or the like, or moved to an archive folder or deleted.

The system may also allow a user to specify the length of time that an email is permitted to reside in the 'A' folder. As the end of such a time period, the user will be prompted to action the email by moving it to a selected pending folder, archiving the email or deleting the email. Alternatively, the system may provide a further default folder, which for the purposes of this explanation will be referred to as the 'B' folder, into which the email can be moved. Such a 'B' folder would operate in a similar manner to the 'A' folder, but emails would be permitted to reside there indefinitely, with a reminder, for example in the form of an email, displayed to the user at specified time intervals, for example monthly, detailing the contents of the 'B' folder. As the email is held in the 'A' and 'B' folders have no attachments, there are no bandwidth or storage implications to be considered.

A system for managing incoming email communications comprising a processing device; a storage device in communication with the processing device and operable to store an incoming email communication in an inbox located therein; a display device in communication with the processing device and operable to display the email communication and; an input device in communication with the processing device and operable to receive user input; wherein on receipt of an email communication in the inbox the processing unit is operable to communicate with the display device to display said email communication and an indication requiring user input and, on receipt of user input via the input device is operable to process the email in dependence upon the user input and only when a user input is received to delete or store the email communication outside of the inbox.

A system according to Claim 14 wherein any attachment files associated with the email communication are extracted and stored separately from the email communication outside of the inbox. Preferably, the extracted emails are stored outside of the mailbox containing the inbox folder.

The email system may be provided as a plug-in for existing email client software solutions and systems.

Brief Description of the Drawings

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

Figure 1 is a block diagram illustrating a computer network as known in the prior art;

Figure 2 is a block diagram illustrating an email processing system embodying one aspect of the present invention; and Figure 3 is a flow chart illustrating an incoming email management system embodying a further aspect of the present invention; and

Figure 4 is a flow chart illustrating a method of managing an email message embodying a further aspect of the present invention.

Detailed Description of the Invention

The present invention relates to the processing of incoming emails in a computer network such as that shown in figure 1. Such a network 1 includes an email server 2, and a user system 4 which communicate with one another over a communications link 6. The server 2, user system 4 and communications link 6 operate in a known manner for communicating data and information between them. The server 2 receives incoming emails via a second communications link 8, and stores these emails for access by the user system 4. As is known, the user system periodically accesses the stored email messages and presents them to a user. The email messages are stored in an 'inbox' associated with a particular user. The inbox can be stored at the server 2 or at the user system 4, as is known. The present invention is concerned with the processing of these emails stored in the inbox of a user.

It will be understood and appreciated that the server may be provided by an email service provider, on a user network, or by any other suitable means. The functionality and capability of the email server could alternatively be provided by the user system.

Figure 2 illustrates one possible configuration of such a system. The system can be provided by the server 2, user system 4 or a suitable combination of the two. As is known, the central processing unit (CPU) 14 processes data stored on storage device 16 and receives user inputs via the input devices 22, and displays data to a user on a display device 20. In this example, storage device 16 stores the email inbox. Figure 3 illustrates a method embodying another aspect of the present invention, which will be described with reference to figures 1 and 2.

At step A, the system 10 receives an incoming email, and stores that email in the inbox located on the storage device 16.

At step B, the CPU 14 displays on the display device 20, an indication to the user that an email has been received in the inbox located on the storage device 16.

At step C, the user then responds to the indication of email receipt via the input devices 22, said input being detected by the CPU 14. On receipt of the user input by the CPU, the CPU causes the email content to be displayed to the user via display device 20, as shown at step D.

The user's intention to close the display showing the email content is accepted by the CPU 14 via input devices 22. On receipt of such an input, CPU 14 operates via display device 20 to display a prompt to the user to select the desired action to be taken in respect of said email, as shown at step F of figure 3. The user then selects the desired action from the displayed options and the user input is received by the CPU 14 via input devices 22. At step G, the options presented to the user in the embodiment illustrated in figure 3 are:

1. to delete the email;

2. to move the email to the task folder for future attention; and 3. to move the email to an archive folder.

In dependence on the user input received by the CPU from the user via the input devices 22, difference processes occur in respect of the email. If the user selects that the email be deleted, the CPU 14 will operate to delete the email from the inbox located in storage device 16, as set out in steps Hl and H2 of figures 3.

If the user selects that the email be moved to the task folder for future action, the CPU operates to move the email from the inbox located in storage device 16 to the task folder where the email is stored pending future action in dependence on future input by the user via input devices 22.

If the user selects that the email be archived, the CPU 14 operates to move the email from the inbox located in storage device 16 to an archive storage area. The archive storage area may be located in processing unit 12 or be located elsewhere on the user network or even by an email provider or any other suitable archiving location.

On receipt of an input from the user to archive the email, CPU 14 operates via display device 20 to display a prompt to the user seeking user input regarding selecting an expiry date. If the resultant input from the user via input devices 22 and received by CPU 14 indicates that the user does not wish to select an expiry date for the email, the email will be archived without an associated expiry date and will remain archived indefinitely or until such time as the email is deleted or an expiry date is attributed to the email.

If the resultant input from the user via input devices 22 and received by CPU 14 specifies an expiry date to be associated with the email, the email will by archived with the associated expiry date and will remain archived until the expiry date, at which point, the email will be automatically deleted from the system.

It will be noted that many variations are possible in relation to the actions presented to the user at step G, provided that the actions require that the email is removed from the user's inbox stored on storage device 16 located in processing unit 12 and that, should the email be moved to any other folder in the user's email client management system, such as the task folder, or a calendar folder, or any other suitable folder, the attachment is automatically stripped from the email and stored elsewhere and a link provided from the email to the removed attachment. In this way, the inbox cannot accumulate emails which have been opened by a user as the system requires user input to move the emails from the inbox. This is an efficient way to ensure that the inbox of a user does not accumulate emails and attachments which may adversely impact on the productivity of the user due to inefficient email management as previously discussed. In addition, removal of the attachments helps to avoid the unnecessary waste of storage space in the mailbox which occurs when attachments remain in the mailbox as part of an email communication.

In one embodiment of the present invention, when emails are moved to another folder within the mailbox, such as a task folder, a message is sent to the user's inbox at predetermined time intervals, typically daily, listing the emails currently being stored in, for example, the task folder awaiting further action. In this way, the emails which have not been deleted or archived, and thus require further action, are not forgotten as the user is provided with daily reminders that the emails are still stored in the task folder awaiting further action.

The options illustrated in figure 3 are shown by way of example only and it will be appreciated that many other options are possible for action to be taken in respect of the email.

Figure 4 illustrates a method embodying another aspect of the present invention which will be described with reference to figures 1 and 2. At step A, a user generates an email via input device 22, inputting primary addressee details, non-primary addressee details, designation code and optionally title in the subject field, and content in the email content field.

The designation code may be any suitable device, whether text, numerals or symbols which would be understood by a primary addressee to indicate whether an action is required in response to the email. For example, 'RXX/XX' may indicate that a response is required by the date indicated by 'XX/XX' where 'X' is a number. Alternatively, 'IO' may indicate that the email is for information only and no action is required by the primary addressee on receipt. It will be appreciated that any suitable designation codes may be used and the example provided is for illustrative purposes only.

In order to send the email, the use then activates the "send' instruction, which typically involves clicking on a button provided as part of the email system or operating a predetermined key or key sequence (step B).

At Cl, the status of the addressee is determined and, where the addressee status is determined as that of primary addressee the subject field contents remain unmodified. However, where the addressee status is identified as non-primary addressee (see step Dl), the contents of the subject field of the email are modified to remove the designation code before the email is provided to the addressee for viewing.

In this way, only the primary addressee (from whom action is required in response to the email) receives the designation code as part of the subject field of the email. There is therefore no confusion on the part of the non-primary addressee when the email is received over whether action from them is also required in response to the email or whether action is required from the primary addressee only. This allows simplified and more efficient email handling processes to be applied. It will be appreciated that steps C, Cl may take place before the email is transmitted from the sender to the addressees or may alternatively take place on receipt of the email from the sender before the email is made available for viewing by the recipient.

The advantage of the former is that the designation code will be removed from the subject field of an email received by a non-primary addressee irrespective of whether the non-primary addressee is using the same email management software as the sender i.e. which is capable of modifying the subject field contents of an email in dependence upon the identified status of the addressee.

In addition, such an email management system may be configured to identify whether an addressee operates the same or a similar email management system as the sender i.e. an email management system that is capable of modifying the subject field contents of an email in dependence upon the identified status of the addressee, and in the case where the sender does not operate such an email management system, any designation codes present in the subject field may be removed before sending the email to the addressee, even when the addressee is a primary addressee. In this way, the addressee need not be confused by seeing designation codes present in the subject field of the email in the event where they are not familiar with the use of such designation codes as instructions for action in association with email communications.

It will be appreciated that some addressees may operate the same or a similar email management system but may not utilise the designation codes function of the system. In such cases, the email management system of the sender may be set to identify emails being sent to such addressees and remove any designation codes provided in the subject field of the email as a default action before the emails are transmitted to the addressee, whether the addressee is a primary or non-primary addressee.

It will be appreciated that the user system 10 of figures 3 and 4 can be any suitable processing device such as a personal computer or equivalent, such as a PDA and the like.

Although aspects of the invention have been described with reference to the embodiment shown in the accompanying drawings, it is to be understood that the invention is not limited to the precise embodiment shown and that various changes and modifications may be effected without further inventive skill and effort.

Claims

1. A method of managing an email message having a subject field, the method comprising: determining a status of an addressee of the email; and modifying the subject field of the email for that addressee in dependence upon the status of that addressee.

2. A method as claimed in claim 1, further comprising sending the email to the addressee following such modification.

3. A method as claimed in claim 2, wherein modifying the subject field includes adding at least one of a predetermined set of codes to the subject field.

4. A method as claimed in claim 3, wherein the codes are text characters.

5. A method as claimed in claim 4, further comprising removing such an added code from the subject field if the addressee is not in a predetermined list of addressees.

6. A method as claimed in claim 4, further comprising removing such an added code from the subject field if the addressee does not use a predetermined email management system.

7. A method as claimed in claim 1, further comprising receiving the email prior to such modification.

8. An email management system for managing emails having respective subject fields, the system comprising: a determining unit operable to determine a status of an addressee of an email; and a modification unit operable to modify a subject field of an email for an addressee in dependence upon a determined status of that addressee.

9. A system as claimed in claim 8, further comprising a transmission unit operable to send such an email to the addressee following such modification by the modification unit.

10. A system as claimed in claim 9, wherein the modification unit is operable to add at least one of a predetermined set of codes to a subject field of an email.

11. A system as claimed in claim 10, wherein the codes are text characters.

12. A system as claimed in claim 11, wherein the transmission unit is operable to remove such an added code from the subject field if the addressee is not in a predetermined list of addressees.

13. A system as claimed in claim 12, wherein the transmission unit is operable to remove such an added code from the subject field if the addressee does not use a predetermined email management system.

14. A system as claimed in claim 8, further comprising a reception unit operable to receive an email and to pass such an email to the determining and modification units prior to such modification.

15. A method for managing incoming email communications, the method comprising: receiving an email communication; storing that email communication in an inbox; upon closing of an email communication by a user displaying an indication of further processing options for that email communication to the user; receiving a user input in response to display of the indication; processing the email communication in dependence upon that user input only when a user input is received, wherein the further processing options consist of deleting the email communication and storing the email communication outside of the inbox.

16. A method according to Claim 15 wherein the email communication is stored in a pending folder for future action.

17. A method according to Claiml5 wherein the email communication is stored in an archive storage area.

18. A method according to Claim 17 wherein the email communication is archived indefinitely.

19. A method according to Claim 17 wherein the email communication is assigned an expiry date defining when the email communication will be automatically deleted from the archive storage area.

20. A method according to one of Claims 15 to 19 wherein any attachment files associated with the email communication are extracted and stored remote from the inbox.

21. A method according to Claim 20 wherein the extracting and remote storage of the attachment file or files is automatic on closure of the email communication.

22. A method according to Claim 20 or Claim 21 wherein a link to the remotely stored attachment file or files is automatically created as part of the email communication and is accessed via the email communication.

23. A method according to Claim 16 wherein at predetermined time intervals a message is provided detailing the email communications stored in the pending folder.

24. A method according to Claim 23 wherein the message is in the form of an email communication sent to the inbox.

25. A method according to any one of Claims 16 to 24 wherein the pending folder comprises a task list folder.

26. A method according to any one of Claims 16 to 15 wherein the pending folder comprises a calendar folder.

27. A method according to any one of Claim 26 wherein the user input includes information relating to the date in the calendar folder with which the email communication entry is to be associated.

28. A system for managing incoming email communications comprising a processing device; a storage device in communication with the processing device and operable to store an incoming email communication in an inbox located therein; a display device in communication with the processing device and operable to display the email communication and; an input device in communication with the processing device and operable to receive user input; wherein on receipt of an email communication in the inbox the processing unit is operable to communicate with the display device to display said email communication and an indication requiring user input and, on receipt of user input via the input device is operable to process the email in dependence upon the user input and only when a user input is received to delete or store the email communication outside of the inbox.

29. A system according to Claim 28 wherein any attachment files associated with the email communication are extracted and stored separately from the email communication outside of the inbox.

30. A method substantially as hereinbefore described and with reference to the accompanying figures.

31. A system for managing incoming email communications substantially as hereinbefore described and with reference to the accompanying figures.