Patent Application
20080040435
These and other features of this invention will be more readily understood from the following detailed description of the various aspects of the invention taken in conjunction with the accompanying drawings.
Referring first to
In the SMTP model as defined in the RFC 2821, mail user agents (MUAs 100-i) operating in user workstations act as clients for their respective mail servers, also called mail transfer agents (MTAs (110,120,130)). In the present example, mail user agents MUA1 and MUA2 are connected to the same mail transfer agent MTA 110, while mail user agents MUA3 and MUA4 are each connected to their respective MTAs 120, 130. The MTAs are in charge of managing recipient e-mail addresses by transferring and receiving e-mails to and from either local mail user agents or from remote mail user agents over the Internet network 150. In operation, a mail user agent sends an e-mail, which includes message data and the recipient names, to its local MTA. Then, to deliver the e-mail to a local mail user agent, the MTA looks for the addresses of the recipients and deposits the mail in the mailbox 140-i of each mail user agent which is a recipient for the e-mail. The sender and recipient names correspond to their respective mailbox identifiers.
The MUAs further comprise a selective signature generator block (SSG) 160-i to allow the user of the mail user agent 100 to automatically generate an e-mail with as many personalized signatures as required according to the method of the present invention.
Referring now to
To send and receive e-mails for a user, the client mail application comprises a mail user agent 100 interfaced to the user with a graphical user interface (GUI) 210 and comprising at least the following functions:
E) A selective signature generator (SSG) 160. The SSG 160 allows the user of the mail user agent 100 to generate via the GUI 210 the text of the message, the recipients lists, and various elements such as the e-mail subject. The SSG 160 further retrieves appropriate e-mail signatures from a signature repository 290 and associates each signature to a recipient list according to rules predefined by the user and stored in the signature repository 290. The SSG 160 generates e-mails that the submit mail function then handles.
Referring now to
As shown in
A second table 310 (called the rules table) contains a set of rules (R1, . . . , Rn) that are defined by the user, in correspondence with the recipient's categories. The rules define the general environment of the e-mail taking into account the category of the recipient(s), the subject-matter, the nature of the connection, and the like. As an example, a rule R1 may be defined as being: “If recipient category is equal to “internal” and recipient is also in category “personal” then criteria 1 is applied else criteria 8 is applied”.
It is to be appreciated that the rules are not to be limited to those described herein, and that the user may define any type of personalized rules. The rules table 310 allows the user to define the criteria that is/are used by a signature table 320 to select the appropriate signature to be inserted in each e-mail.
A third table 320 (called the signature table) establishes links between the criteria defined in the rules table 310 and the model of signature (S1, S2, . . . ) to be inserted for each recipient of the e-mail.
In operation, the user first enters the text of the message in a text zone, enters the name of each recipient (“Sent to” list or distribution list) of the message in the recipient zone, and optionally fills in the subject matter of the e-mail in the subject zone. Then, the user either directly submits the e-mail if signatures have previously been created and stored, or the user defines a new set of rules and signatures to be used for this e-mail. The creation or modification of rules and signatures is accomplished through the GUI 210. A more detailed description of the GUI 210 used by the present invention is given below with reference to
As shown in view 330 of
In the present example, the message contains 3 recipients or distribution lists. Recipient ‘A’ is a SMTP primary recipient, and defined between tags <to ></to>; recipient ‘B’ is in copy and defined between tags <Cc></cc>; and recipient ‘C’ is in hidden copy and defined between tags <Bcc></Bcc>. The subject of the e-mail is defined between tags <Subject</Subject>. The text of the message is defined between tags <Body></Body>. The signature(s) is(are) defined between tags <Signature></Signature>. The signature may be any kind of element in any format such as text, images, HTML, etc.
Once the e-mail is submitted, the SSG 160 retrieves the category of recipient associated with each recipient address in the recipient table 300, and retrieves from the rules table 310 the rule to be applied to the specific category. For example: “If the mail subject contains the sentence “PROJECT ONE”, and if the recipient's category is ‘a’, then criteria is ‘1’, else if recipient's category is ‘b’, then criteria is ‘2’, else if recipient's category is ‘c’, then criteria is ‘3’.” Once, the rule is found and the corresponding criterion determined, the SSG 160 retrieves the signature to be used for this recipient from the signature table 320. Finally, the SSG 160 generates a unique message (e.g., as shown in view 330) to be used by the submit function 270, that contains the appropriate signatures for each recipient. For example, the SSG 160 can generate the unique message:
In 400, the submit function starts on a SSG request when the message prepared by the user is ready. In 410, a message is created except for the signature section.
If, in 420 the end of the e-mail is reached, the process ends in 480, otherwise the process continues with 430. In 430, a loop is started for each defined recipient. In 440, all the destination recipients are copied into the text area of the e-mail. The text generated for the initial message becomes at this stage:
Next, in 450, the process checks if the recipient is stated as a primary recipient or a copy recipient. If YES in 450, the process removes the Bcc line from the message in 470, otherwise flow passes to 460. In the previous example, the text generated for the message becomes:
Then the process continues in 460 (either coming from branch NO of 450 or from 470) with the insertion of the correct signature corresponding to the designated recipient. Finally, the process loops back to 410. In 420, if the end of the e-mail is reached, meaning that all recipients have been parsed and the signatures inserted, the process ends, otherwise a new iteration is started.
The window 500 includes a signature area (510), a rules area (560), a recipient category area (600), and push buttons to create the links between the recipient category and a rule (640), the link between the criteria and the signature (650), and additional buttons (OK 660, cancel 670, and help 680).
The signature area 510 displays a list of preexisting or newly created signatures. The user may select a predefined signature in this selection list or create 520 a new one. The user is also offered the possibility to delete 530 or modify 540 a signature. Thus, the main window 500 includes several push buttons to manage the signatures: a create button 520 to create a new signature, which is then displayed in the signature area 510; a delete button 530 to delete a signature selected in the signature area 510; and a modify button 540 to modify a preselected signature in the signature area 510.
The main window 500 further includes a preview area 550 to preview the signature selected in the signature area 510.
A second area, called the rules area 560, displays the list of rules to be managed. The user may select one predefined rule in this selection or use a push button to manage the rules: a create button 570 to create a new rule, which is then displayed into the rule area 560; a delete button 580 to delete a rule selected in the rule area 560; and a modify button 590 to modify a preselected rule in the rule area 560.
A third area, called the recipient category area 600, displays the list of the recipient's categories to be managed. The user may select one recipient category in the recipient category area 600. The main window 500 also includes several push buttons to manage the categories: a create button 610 to create a new recipient category which is then displayed in the recipient category area 600; a delete button 620 to delete a recipient category selected in the recipient category area 600; and a modify button 630 to modify a preselected recipient category in the recipient category area 600.
The main window 500 further includes push buttons to manage the links between the different elements: a link categories/rules button 640 to manage the content of the recipient table; a link signature/criteria button 650 to manage the content of the signature table; an OK button 660 to validate all actions performed via the SSG and exit the signature GUI; and a cancel button 670 to ignore the actions and exit the SSG.
The main window 500 may also include a Help button 680 to start a help process for the external interface.
Some/all aspects of the present invention can be provided on a computer-readable medium that includes computer program code for carrying out and/or implementing the various process steps of the present invention, when loaded and executed in a computer system. It is understood that the term “computer-readable medium” comprises one or more of any type of physical embodiment of the computer program code. For example, the computer-readable medium can comprise computer program code embodied on one or more portable storage articles of manufacture (e.g., a compact disc, a magnetic disk, a tape, etc.), on one or more data storage portions of a computer system, such as memory and/or a storage system (e.g., a fixed disk, a read-only memory, a random access memory, a cache memory, etc.), and/or as a data signal traveling over a network (e.g., during a wired/wireless electronic distribution of the computer program code).
It should be appreciated that the teachings of the present invention could be offered as a business method on a subscription or fee basis. For example, a service provider can create, maintain, enable, and deploy an audience response detection interactive presentation tool, as described above.
The foregoing description of the embodiments of this invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and many modifications and variations are possible.
| Number | Date | Country | Kind |
|---|---|---|---|
| 06118821.5 | Aug 2006 | EP | regional |
