Browse Prior Art Database

Smarter Email System: Removal of Redundant Attachments in Received and Reply Emails

IP.com Disclosure Number: IPCOM000236652D
Publication Date: 2014-May-07
Document File: 4 page(s) / 89K

Publishing Venue

The IP.com Prior Art Database

Abstract

This disclosure demonstrates a smart email system in which users can set up automatic removal of email attachments or screenshots and store them in a location from which the attachments may be accessed when required. This removes the problems of filling up your inbox size quickly, reducing network bandwidth in sending large attachments to many recipients and having a recipient receive the attachment or screenshot many times due to others replying to the mail without first removing the attachment. Other advantages include having the system recognise if you have already received the attachment so that you will not receive the attachment again or if there has been any new recipients added to the reply of the original mail and therefore send the attachment only to the new recipients. Also the system will recognise that an attachment has been updated and will send this new attachment to all recipients.

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

Page 01 of 4

Smarter Email System: Removal of Redundant Attachments in Received and Reply Emails

This disclosure describes a solution for removing email attachments from emails and storing them in a location from which the attachments may be accessed when required.

    Electronic mail (hereafter called 'email') supports the transfer of messages from one user, the sender, to one or more recipients. It works over computer networks, including the Internet. Typically the messages are handled by an email server which receives the message, stores it, and sends it to the recipient's email server. To receive their messages the recipients pull the messages from their email server.

    With the introduction of the Multipurpose Internet Mail Extensions (MIME) Internet standard, the format of email was extended to support non-text attachments. This allows users to attach files of any type or size (text or binary files such as image files, etc) to their email. The recipient receives the email along with any attachments that were added to the email. Allowing files to be attached to emails has caused several problems which this idea solves:

    (a) Attachments can be large files and receiving emails with large attachments can quickly fill your mail file or in-box. This is especially the case if there is an imposed size limit. In some cases exceeding this limit could result in a user's loss of access to the mail system, at least until the mail file or in-box size has been reduced to a size below the maximum limit. This means a lot of manual processing of emails, storing attachments to locations that can be found in the future if needed.

    (b) Emails with attachments or screenshots, big or small, sent to many recipients results in the usage of a large amount of network bandwidth.

    (c) Replying to emails with attachments can result in people receiving the same attachments again and again. This means a needless use of network bandwidth and mail file space. There needs to be a way to determine whether a recipient needs to have the attachment sent to them or not. If not required, then the attachment should not be included in the outgoing email.

    When a recipient's email server receives an email with an attachment it will invoke the proposed system which will strip the email of all attachments and store them in a predefined location determined by the recipient. This could be the recipient's hard drive, a file server or the Cloud. The attachment will be replaced by a file locator tag (e.g. a URL or path) to allow the recipient to retrieve the file

whenever necessary. The difference with this new proposal is that this email attachment processing is done on the recipient's email server, allowing the recipient to minimize the size of their mail file\box.

    If the recipient wishes to forward the mail to another user who has not already received the original mail the proposed system detects the file locator tag and uses it to re-attach the file to the new mail. The new mail will then get...