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

Method to dynamically transmit byline information and update outdated byline data from the local cache in mail client applications

IP.com Disclosure Number: IPCOM000031206D
Original Publication Date: 2004-Sep-17
Included in the Prior Art Database: 2004-Sep-17
Document File: 2 page(s) / 33K

Publishing Venue



Disclosed is the potential for solving the problem of transmitting and updating outdated email byline data using a local cache in mail client applications. Often in the case of individuals whose location information changes frequently or in the case of consultants, what happens is that the email messages sent by that individual do not have the updated contact information. This results in the earlier email messages having outdated redundant information in the byline. This disclosure presents an implementation to avoid the repeated sending of static information and to make clients more intelligent by being able to update redundant email byline information in an efficient manner using minimum resources. This results in reduced bandwidth usage and less network traffic especially for byline data that contain rich text or images. Current technology sends duplicate static data across network numerous times, as in the case of a mail signature file. It remains static most of the time, and takes up extra bandwidth during transit.

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

Page 1 of 2

Method to dynamically transmit byline information and update outdated byline data from the local cache in mail client applications

Whenever email is sent, it common practice to include signature/closing/byline information with the email (and even information like the Letterhead style option available in some mail client application). Instead of sending this byline information each time an email is sent, this information could be cached on a local machine at the recipient's end, after the first time an email is received from Person A. If the byline information is modified, then:

1. The sender will send mail content and the timestamp when the individual's byline information was last modified

2. On the email receiver's end the idea proposes to cache the byline information and the timestamp when the byline of a particular sender was created. The sender's byline information is resident in the local cache and a look up can be performed and check if the sender has modified the byline by comparing the timestamp of the byline information in cache with the byline timestamp that was sent in the email.

Or in the equivalent, to explain the idea by example, let's say that email 1 from Person A has some byline information. This information is cached on a receiving client. When Person A sends e-mail 2, the byline information is unchanged. However after a few months, email 3 has updated byline information. What happens here is email 3 comes with a "dirty" bit and alerts the recipient that there are some updates to the byline of the sender. The client extracts the latest byline information either from an LDAP setup or from the mail-server itself and updates the client cache for future correspondence.

Thus if the information remains the same, when Person A sends a message, there is no need to include the closing line. What is included is a link for the closing line. Externally, the note is sent out and the message is constructed normally. Closing information might be pulled from the local machine of the sender, an LDAP setup, or from the mail server. If the user has modified the byline file, the user modifications can be sent to the m...