+

WO2008011534A2 - Système et procédé permettant une modification dynamique d'état d'éléments dans des messages de courrier électronique statique - Google Patents

Système et procédé permettant une modification dynamique d'état d'éléments dans des messages de courrier électronique statique Download PDF

Info

Publication number
WO2008011534A2
WO2008011534A2 PCT/US2007/073920 US2007073920W WO2008011534A2 WO 2008011534 A2 WO2008011534 A2 WO 2008011534A2 US 2007073920 W US2007073920 W US 2007073920W WO 2008011534 A2 WO2008011534 A2 WO 2008011534A2
Authority
WO
WIPO (PCT)
Prior art keywords
status
email
items
message
server
Prior art date
Application number
PCT/US2007/073920
Other languages
English (en)
Other versions
WO2008011534A3 (fr
Inventor
Ari Teman
Original Assignee
Ari Teman
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ari Teman filed Critical Ari Teman
Publication of WO2008011534A2 publication Critical patent/WO2008011534A2/fr
Publication of WO2008011534A3 publication Critical patent/WO2008011534A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/107—Computer-aided management of electronic mailing [e-mailing]

Definitions

  • the present invention relates generally to the field of electronic mail using a networked communications system. More particularly, the invention relates to systems and methods for dynamically changing the status of items in an email digest or a notification email.
  • Mail digests are increasingly popular and well known in the art.
  • Many portals such as Yahoo!TM, allow individuals and groups to setup virtual communities or groups where members of the community can post messages to a message board requesting information or action.
  • These message boards enable growing virtual communities to stay tightly-knit, informed, and cooperative. Because these services, which are often free, provide such benefit to communities, it is common for a single message board to receive a few hundred messages a day.
  • the service providers often send emails to members of the community with a digest of the messages posted to the board over an interval of time.
  • the community member or the service provider can customize the email digest service to send a digest of messages on a set interval, such as once per day, or after a certain number of messages have been posted to the board since the last digest was sent. On popular message boards, a user may receive several digests per day.
  • notification email messages sent from community web sites or portals are also well known.
  • notification emails are often sent to alert a user that he has received a new contact or some other event has occurred relating to his account. The user may then log on to the website to view the event. Sometimes, however, the user will have logged on to the website and viewed the event before reading the email notification. In such a case, the user no longer needs to view the notification and may, in fact, be confused by it, believing, for example, that an additional event has occurred.
  • a principal object of the present invention is to provide systems and methods for dynamically changing the status of an item in a static email message, by embedding instructions in the static email message for retrieving and displaying the current status of the item in the message.
  • a system for dynamically changing a static email message comprising one or more servers for maintaining an online community in data communication with one or more client computers of a plurality of subscribers to the community, the client computers adapted to enter and send a plurality of items to the servers and receive a plurality of emails from the servers, a database for storing the plurality of items and a status of the plurality of items, a status processing component for maintaining the status of the items in response to communication with the plurality of subscribers and an email processing component for creating a plurality of email messages containing one or more items and sending the email messages to the plurality of subscribers, the email messages containing or calling for a set of instructions for displaying on the client computers the status of the one or more items contained in the email messages as maintained by the status processing component.
  • a method for dynamically changing a status of a posting in a static email message comprising the steps of storing in a database at a server a plurality of items sent to a provider of an online service from a plurality of users of the online service, each of the items having a status indicating whether the item has been addressed by any of the users of the online service, updating the status of the items in response to communications with users of the online service having permission to update the status, creating an email message containing one or more items and embedded instructions for retrieving from the server the status of the included items, sending the email message to one or more users of the online service, and opening in a client computer of a recipient user the email message, executing the embedded instructions for retrieving from the server the status of the items contained therein and displaying the current status of the items on the client computer.
  • FIG. 1 is a diagram of an example mail digest displaying inventive functionality
  • FIG. 2 is another diagram of an example mail digest displaying inventive functionality
  • FIG 3. is diagram depicting the architecture of the system for dynamically changing the status of static email messages
  • FIG. 4 is a block diagram of the system allowing the changing of status and notification of a change in status
  • FIG. 5 is another block diagram of the system depicting the use of aliases to allow the changing of status and notification of a change in status
  • FIG. 6 is another block diagram of the system depicting the use of script or program to allow the changing of status and notification of a change in status
  • FIG. 7 is another block diagram of the system depicting the use of unique stylesheets per digest to hide or format messages or change the image source per image.
  • FIG. 8 is another block diagram of components of the system
  • FIG. 9a is another diagram depicting the architecture of the system for dynamically changing the status of static email messages
  • FIG. 9b is another diagram depicting the architecture of the system for dynamically changing the status of static email messages
  • FIG. 10 is a flow chart depicting the process of posting a message to a group board, moderating that message, generating statuses for the message, and then compiling that message and additional items into a digest, and finally emailing that digest to the recipient;
  • FIG. 11 is a flow chart depicting the process of a recipient's email client downloading and formatting the email message by downloading remote stylesheets;
  • FIG. 12 is a flow chart depicting the functionality of the toolbar extension
  • FIG. 13 is a flow chart depicting the process of a user replying to a message, where they do not have the toolbar extension, via a web browser;
  • FIG. 14 is a flow chart depicting the process of parsing and updating an item in an email digest
  • FIG. 14a is a continuation of FIG. 14.
  • FIG. 15 is a flow chart depicting the updating of a single notification email
  • FIG. 16 is a flow chart depicting the updating of a non-message item, such as an advertisement or event listing, which may be embedded into any email; and
  • FIG. 17 is a flow chart depicting the functionality of this invention for use with person-to-person(s) emailing through a mail server.
  • FIG. 1 shown therein is an example layout of a dynamically updating email digest 102 where a remotely hosted status image 106 is placed at the side of each posting 104 noting the status of the posting 104.
  • the image 106 must be clicked to reply to a message so a user will not reply to a closed message.
  • FIG. 2 shows another example of a dynamically updating email digest 102 where a remotely served stylesheet is called changing the color, pattern, or font of a posting 104 to show it is void, open or featured or another status.
  • the stylesheet also calls the correct status image 106 if desired.
  • a closed posting 202 is not displayed.
  • a previously hidden div for that posting, displaying a status 203 is now unhidden and displaying the current status to the user.
  • the tag 'generic header' would apply the standard style that is defined for all divs with the class generic header, and then the tag 'header l ' would further define the style for that specific header. For example, all 'generic header' divs might be displayed as bold with a blue background, but 'header_l ' might also have its text italicized for emphasis. Thus, the div would first be set to bold with a blue background, and then the text would be italicized. Further, a class can be set to not display. This is useful for hiding outdated information, as well as hiding information until it is relevant.
  • HTML parsers may allow you to create a novel tag, one not previously defined by HTML, and then define its style via a stylesheet or style tag, A style tag is when the style of an item is embedded right into the tag.
  • the next posting 204 shows a message that has been updated after the digest 102 was sent out.
  • a status message 210 is unhidden according to the stylesheet alerting the reader that there is an updated version which they can read online.
  • the system can also download or embed a personal stylesheet which overrides the global and per-digest styles, the user can hide messages from specific senders 212 or categories 214. The user may also choose to highlight 220 a category.
  • the stylesheet may be used to highlight a posting as a sponsored posting, in the per- digest message. On the right, the stylesheet is used to hide an advertisement 218 which was embedded into the email but is now expired, perhaps because the advertiser is no longer paying.
  • FIG. 3 is a drawing depicting a schematic of the system architecture of a dynamic email system 300 according to one aspect of the present invention.
  • the system 300 will be discussed in connection with a message board email digest program; however, it should be noted that the system 300 could easily be employed in any email system in which static emails are to be dynamically updated after having been sent, such as for emails with a single notification which prompts the recipient for action.
  • the system 300 includes a service provider 302 and a plurality of subscribers 304.
  • the invention contemplates that a subscriber 304 will submit a new posting to the service provider 302 using an add posting interface 306 in data communication over a communications network 310 with a service interface 312 in a server subsystem 314 of the service provider 302.
  • the posting may be saved by the server system 314 to a database 316.
  • a status process 318 will mark the posting as "open" as necessary to indicate that the subject of the posting has yet to be addressed.
  • a digest process 319 in the server subsystem 302 will periodically compile an email digest of the postings that have been received by the system 300 since the last digest.
  • the interval at which an email digest is created can be determined by the service provider or the subscriber receiving the email digest.
  • the service provider or subscriber can elect to have a digest created following the passing of a certain period of time, the receiving by the system of a certain number of postings, or some other criteria.
  • the digest is compiled, it is sent to the subscriber 304 over the communications network 310.
  • the subscriber 304 opens the email digest at any time in an email client 320, embedded instructions in the email message retrieve the current status of a posting as maintained in the posting database 316 by the status process 318. This can be accomplished by downloading a remotely hosted status image or stylesheet.
  • the subscriber 304 is then able to tell whether a particular posting in the email digest has current status of open, closed, void, or some other status.
  • the service provider 302 is capable of interfacing with one or more databases 316 as shown in FIG. 3.
  • the database 316 could be, for example, a database containing items and the status of items. Items could be, for example, message board postings, emails, invitations to join an online community, online forum postings, messages sent via private messaging, or community profile page postings. Statuses could be, for example, "open,” “closed,” “featured,” or "void.”
  • the service provider 302 and the subscriber 304 are connected to a data communications network 310.
  • the particular connectivity of the service provider 302 and the subscriber 304 is for illustrative purposes only.
  • the network 310 may be, for example, a wireless network used by mobile computing devices like cellular telephones, the Internet, an intranet, or some other network system.
  • the network 310 is a packet-switched network capable of routing hypertext, extensible, or other types of markup language code and data in accordance with the standard Internet Protocol or some other protocol in order to generate web pages.
  • the Internet Engineering Task Force is the standards body that creates and maintains the basic standards on which the Internet depends, including the Internet Protocol specification published in 1981.
  • the service provider 302 maintains a server subsystem 314, which can include one or more server computers that are adapted to, among other things, store and process data, generate responses to subscriber requests for markup language files and information, and maintain online communities.
  • Subscribers 304 can use one or more interfaces 306, 322 to access the server subsystem 314, preferably via a web site graphical user interface that is generated on the subscriber client 304 using markup language commands and data provided to those devices by the server subsystem 314.
  • An add posting interface 306 allows the user to add a posting the online community.
  • the status system 318 assigns all new messages the default of "open.”
  • the posting and the status are stored in the database 316.
  • the posting will be added to the next email digest according to the rules of the service provider 302 and the subscribers 304.
  • the add posting interface 306 can be a standard Internet-based form.
  • An edit posting interface 322 allows a poster to change the status of his posting. For example a posting with a request that has been fulfilled may be set to "closed" by the requesting poster using a status entry field 404 in the edit posting interface 322, as shown in FIG. 4. The status process 318 will update the status associated with posting in the posting database 316. Subsequently, any subscribers 304 viewing an email digest containing the posting will have the current status of the posting displayed in their email client 320, Displaying this information will prevent readers of the digest from calling, messaging, or emailing the poster needlessly.
  • the edit posting interface 322 can be a standard Internet-based form.
  • This status process 318 can work in multiple methods depending on the desires of the service provider 302. For example, it can copy the status image and assign it a name matching the ID of the new posting as shown by the status process 318a in FIG. 4. Alternatively, it can update an Alias file 502 as shown by the status process 318b in FIG. 5. In still another alternative, the status process 318c can return the correct image data in response to a direct call by the subscriber's email client 320 as shown in FIG. 6. In another alternative, the status process 318d can return a stylesheet that defines, according to the current status of the postings, how the postings in the email digest should be displayed as shown in FIG. 7. The status process 318 may be coded in any combination of languages that can interact with existing email digests.
  • a static email message 102 may call for remotely hosted images 106.
  • this image 106 is remote it can be modified by the status process 318 on the sending server 314, using, for example, server-side scripts.
  • that status process 318a copies a corresponding image 408 from a status types images directory 412 into the current status image directory 410.
  • the image file copied is renamed to the file name expected by an email digest containing the posting and overwrites the image 422 currently in the current status image directory 410. For example void.gif 408 is renamed to posting_2.gif 422 and overwrites the file currently stored as posting_2.gif 422.
  • an email digest 102 of postings currently received by the message board system may be created 416 and sent 418 to users of the online community.
  • This invention does not modify the way email digests are sent to users. Usually these are sent after a certain amount of time 414 or number of new postings has accumulated for a specific message or news board.
  • the message is compiled 416 and mailed 418 to each subscriber's mailbox 420 where it sits until it is called by the subscriber's email client 320.
  • the email client 320 reads it as a static email message 102 but can load images 422 stored remotely by the service provider 302 in the current status images folder 410.
  • the static email message 102 can be dynamically updated with the status of the postings contained therein.
  • the status can be set by a posting user through the add posting interface 306 or the edit posting interface 322, by a moderator using the moderator interface 402, or by another authorized user before, during or after the email digest 102 is sent.
  • the email digest 102 will update with the most current status of the postings whenever the email digest 102 is displayed because the status is not stored in the static email 102 itself.
  • the service provider may prefer simply to alias all remote images per a single status call to a single image for that status, as shown in FIG. 5.
  • the server 314 knows by looking at its alias file 502 that Posting 123.gif really points to VOID.gif 504 in the status types images folder 412 and returns the image 504 showing the status of posting 123 as void.
  • Calling an alias can be much less taxing on a server than running a script as shown in FIG. 6 or copying each image so each posting has one corresponding status image as shown in FIG. 4.
  • the status process 318c is called directly by the static email message 102 from the subscriber's email client 320 and returns the correct image data. For example, a call to the status process 318c by the email client 320 as shown in FIG. 6 reveals that posting 1 and posting 2 are still active, but posting 3 is void. Because the status process 318c is being called directly it can return a custom image each time it is called. That enables the status process 318c to return custom data based on the preferences of the particular user viewing the email digest 102.
  • the status process 318c might also send data for that posting giving an indication to the viewing user that he is the author of the posting by, for example, displaying a button saying "Edit Your Posting.”
  • the static email message 102 may call for a remotely hosted stylesheet 318d.
  • a stylesheet is a set of computer instructions used to describe the presentation of electronic documents. Stylesheets may be embedded into a document or may be separate documents called remotely by the document. An HTML, or similar, document can use multiple stylesheets, and may even combine locations of the stylesheets, with some embedded into the HTML document and others called remotely. If a style is defined twice, within a single stylesheet or across multiple stylesheets, the latest line to be parsed overrules earlier definitions.
  • style "headline 1" is defined with its color set to blue in a first stylesheet
  • the document includes a second stylesheet where "headlinel” is defined with its color set to red
  • all items with the style "headlinel” will be colored red.
  • Embedded in the static email message 102 is a call 702 to a remotely hosted stylesheet 318d.
  • a remotely hosted image 422 or alias file 502 can be edited by the status process 318, so can the stylesheet 318d in response to changes in the status made by an authorized user. Therefore when the user goes to view the email message 102 in his email client 320, the email client 320 will download the most recent stylesheet 318d.
  • This stylesheet 318d will define unique styles 704 for each posting 104 in the email digest 102.
  • the stylesheet 318d may be used to hide an entire posting 202 or reformat a featured posting 204 as shown in FIG. 2.
  • Each user can specify senders and categories of messages they would like not to see. All postings 706 are encased in tags defining their sender ID and category ID 708. That encasement can be a tag such as a DIV or SPAN which specifies a class of style 704 for that posting.
  • the user's custom stylesheet 710 sets all tags with that ID to display in a desired way or to not display at all. The same can be done to highlight favorite categories. For example, a user who does not want to see ads for babysitters can specify his stylesheet 710 to hide all messages encased in a DIV or SPAN or other tag with a class or ID equal to that of childcare. If the same user prefers to see all messages related to cars, he can set his stylesheet 710, via a web interface, to highlight all messages encased in that category ID 708.
  • a user may have his own stylesheet 710 dictating which categories to display and how to display them 712.
  • the stylesheet may also hide or highlight messages by a certain sender ID 714.
  • the category encasement 708 triggers that category's style 712 from the user's stylesheet 710 which is stored on the service provider's 302 database 324 or in a folder on the server 314.
  • the sender encasement 716 triggers the style that the recipient has set 714 for the sender.
  • the email client extension 802 adds more robust status features to the status system described herein. While what has been described so far is enough to prevent hassle and harassment for millions of users, these features allow highly active users access to their data more quickly. It also protects all users against fraudulent copies of the mail digests which may seek private information from unsuspecting users, a technique commonly known as "email phishing.”
  • the parsing process function 804 of the client extension 802 parses the static email digest 806 and checks the database 316 on the server 314 to see the status of each posting in the static email digest 806.
  • the parsing process 804 modifies the digest 806 on the local computer or user's mailbox to create an edited digest 808 that displays the current status of each posting. That edited digest 808 will contain only relevant postings or news items. That allows for functionality in secure situations where a user cannot download any image or stylesheet files which may be blocked by firewalls or otherwise prohibited.
  • a malicious programmer may attempt to send a fake digest hoping that users will respond to postings with private information. For example, someone who believes they are responding to a neighbor or co-worker's posting may reveal private addresses or history.
  • the function to verify the validity of an email digest 810 activates an icon on the tool bar 812 and will alert the subscriber 304 that the message in question is fake and hide its contents until the subscriber 304 acknowledges the warning.
  • the server 314 will have in a database 316 an exact copy of the message, allowing a comparison 816 of the recipient's local copy of the message to the copy on the server 314, While the module can and should also compare the IP addresses recorded in the message header 814 to those of the server 314 from which the mail was sent, this is inferior to comparing the entire content of the message, including the header 814, because the IP address sent to the recipient may be forged. Comparing the entire content of the messages, however, would cause a false match and activate the warning from the toolbar 812 with even one false link.
  • the module 810 may compare 816 only links, image tag source locations, and URLs, which are what is usually used to direct users to fake, 'phishing' websites which are then used to steal private information,
  • a poster may want to ask an anonymous question or a responder may not want to share their identification.
  • the function to allow anonymous correspondence 818 enables both users to remain anonymous by using a script 820 which knows both ID's to send mail between users.
  • a responder When a responder responds to a posting in a digest, 806 a request 820 for an anonymous email address is made that would link to this message and responder, such as responder7891 O@example.com. The response is then sent to the poster of the message using that anonymous email 822. Further, because the server 314 knows the true email of the responder, a moderator may still block a user from sending anonymous messages to prevent abuse.
  • this filter digest feature 826 allows them to do this instantly, without needing to revisit the service provider's 302 service interface 312. They can also filter digests based on keyword.
  • server-based personal stylesheets are able to filter messages based on tags such as those identifying the sender ID or category ID, it may be impractical to place a tag for each word in every posting. In such a situation, keyword-based filtering can be done when the recipient activates it in real-time.
  • the toolbar module 802 would be able to find a word in the document. While that is a function included already in most email clients, this extension would recognize in a digest 806 using a PC-based script 828 which were the opening and closing tags of each posting.
  • the resulting edited digest 808 will hide and display postings according to a search done by the recipient with their toolbar 812. Thus, only relevant postings would be displayed or highlighted and the recipient doing the search would not have to scroll through useless information.
  • a script on the server 820 sends a message to the user's toolbar 812, or makes the status viewable in a database to alert the user that they have responses to their posting. In that way, a poster can choose not to receive individual responses in his mailbox, but go online to view them all at once.
  • the toolbar 812 would have the user ID assigned to the user by the service provider 302, it would be able to frequently check the status of open postings made by that user by communicating directly with the server 314.
  • toolbar 812 While the toolbar 812 is open on the user's computer or within their email client 320, it would constantly ping the server which would notify the service provider 302 that the user's toolbar 812 was still functioning and therefore status updates could be displayed via the toolbar 812, rather than having the server 314 generate and send additional mails 218. This would cut down on the number of notification emails required and thus reduce the bandwidth and computing power employed. It would also ensure that the user does not have to constantly open or view their inbox to see what new messages have come in.
  • the toolbar 812 can display the number of messages and number of responses, the user can decide whether to login to the website to check those responses or wait for more responses. For example, if the user was looking to get a consensus of opinions in response to his posting, he could wait until his posting had received multiple responses before logging in, as indicated by the toolbar 812. Further, if a user receives hundreds of responses to a posting, rather than getting hundreds of notification emails in his inbox, a simple number could be displayed on the toolbar 812, thus saving him from having to delete or move those hundreds of notification emails.
  • the PC-based script 828 filters the mail digests 806 without action from the remote server 314, displaying only the postings matching the subscriber's 304 settings in an edited digest 808. If it connects to the remote server 314 it can filter out closed or voided messages and even edit the content of edited messages.
  • a server-based reply form and script 820 handles all replies and updates to postings.
  • the script is called to activate status changes. For example, when the script is called within a reply form, the poster is notified via his email client extension 812 on a toolbar via an icon that he has received a response to a posting. He could them click the icon for more information and to view the responses.
  • the script 820 reads and updates the server databases 316.
  • the reply form can be displayed by the email client extension 812 without opening an outside browser window. That makes it easy to give an immediate response from the email, without sending mail from a private email address, guaranteeing anonymity.
  • FIG. 9a an alternative single notification email 917 is depicted instead of the previously described email digest. Millions of these single notification emails 917 are sent every day by member-based community services such as MySpace (TM), Facebook (TM) and other community and dating websites. Often, these notification emails 917 alert 920 a user that a message has been sent to their user account on the community website and that it can be retrieved by logging in to the site. In this embodiment, the email 917 is alerting 920 a recipient 916 that another user 902 has sent him a message. However, the recipient 916 may have been logged in to the community website 904 when the message was sent by the other user 902 and may have already read the message before checking his email 320 and receiving the notification 917. Therefore the notification 917 is unnecessary and the recipient may return to the site expecting to see a new message from the sender 904 and be disappointed to find there is nothing new.
  • TM MySpace
  • TM Facebook
  • a remote stylesheet 914 is called 918 for this message 917 displaying the correct status 921, 921a, 921b, 921c, 92 Id of the notification message 920.
  • a user 902 sends 906 a message to the user/recipient 916 on the community website 904.
  • the community website 904 generates 908 a notification email 917 to be sent to the recipient 916 to alert him that a message from another user 902 is waiting for him on the community website 904.
  • the notification 917 is sent to the recipient 916 and a user database 910 and a notifications database 912 are updated to reflect that another user 902 has sent a message 906 to the user/recipient 916 and that a notification email 917 was sent to the user/recipient 916 alerting him of this 920.
  • the notifications database 912 maintains the status of the notification. If the user was logged into the community website 904 when the other user 902 sent him a message, the notifications database 912 would be updated to reflect that the user 916 has already read this message.
  • the email 917 will call 918 for the remotely hosted stylesheet 914 to determine how to display the notification email 917.
  • the stylesheet 914 will reflect that the notifications database 912 indicates that the message has already been read by the user/recipient 916 and the email notification 917 will be displayed accordingly 921. Because there is only a single mail 917 being sent to one or a few recipients 916, in one embodiment, the stylesheet may be generated 914 dynamically when requested 918 by the client 320 and not before.
  • the notification can be marked with other statuses telling the recipient the message had been marked as spam 921b, deleted 921c, or other useful statuses 921d, which perhaps the original sender 902 can define, thus saving the recipient 916 a useless trip to the website 904.
  • the server 904 when the server 904 receives the call 918 for the stylesheet 914, it knows that email 917 has been downloaded by the email client 320 and can notify the sender 902 that their message has been received. This is commonly done by mass mailings and email digests and would give individuals a more reliable read-receipt system.
  • the present invention can be used for person-to-person emails, by individuals who send email, as shown in FIG. 9b.
  • the stylesheets 964 could be actual text documents or simply a link to a script which returns styles based on the message ID.
  • the server digest process 318d will embed into the email message 967 a stylesheet 968 containing some pre-set or default statuses 981a, 981b, 981c, 981d and a call 970 to a remote stylesheet 964. If the sender 952 needs to update the message, or feels that the message is now outdated, the sender 952 can update 404 the status of that message via a web-based control panel or compatible toolbar 954, and the updated status would display when the recipient 966 opens that message 967 in their email client 320.
  • a stylesheet script can update the database 960 to reflect that the message has been read, which may be useful to the sender 952.
  • This enables the same functionality described previously to be used by individual email senders 952, Example statuses 981 which would be useful for emails are, 'the sender is asking you to disregard this email,' 981 a 'the sender has re-sent an updated version of this email,' 981b 'the sender says this email's content is expired', 'you have responded to this email', 'someone else has responded to this email'.
  • FIG. 10 is a process flow diagram depicting the server-side process flow steps according to an embodiment of the present invention.
  • a poster posts a message to the group 1002 and the system assigns that message a Unique ID 1004. If messages require approval 1006 from a moderator, the moderator will have to review the posting 1008 and approve the message 1010. If not approved 1012, a rejection message is sent to the poster. If approved 1014, the message is activated 1014 and listed on the group or community website or feed 1016. Once there are sufficient postings or a certain time limit has been reached 1018 the server will compile an email digest 1022. The system compiles each message 1022 with each item tagged with its own unique ID, including any items which are in addition to digest postings.
  • these additional items may be advertisements 1024 or upcoming events 1028 from the group calendar.
  • Embedded advertising 1026 and embedded events 1030 both can have expiration dates and the system will be able to update the remote stylesheets to hide expired items. It is also possible that the digest will embed hidden Advertising and hidden Events which it will unhide when the original items become expired, thus enabling more relevant information.
  • the system will then embed a global stylesheet 1032 and a link to a remote per-digest stylesheet 1034 which can overrule, and thus update the embedded global stylesheet 1032. It is recommended to embed at least part of the global stylesheet 1032 in case the email client fails to download any stylesheets. If the service provider enables each recipient to customize their digests 1036, it will also embed a link to their personalized stylesheet 1038. It then emails a copy of the digest to each group member 1040, the recipients.
  • FIG. 11 is a process flow diagram depicting the client-side process flow steps according to an embodiment of the present invention.
  • the recipient's email client downloads the email digest from the mail server 1102.
  • the client will then parse the document and first act upon the embedded or linked global stylesheet 1104 which defines the styles for everything in that digest. That is a static, non- updated stylesheet.
  • the digest code then has the client download a remote stylesheet 1106 that will update the items in that stylesheet, such as each posting and any advertisements, events and other items needing updating. If the stylesheet does not download properly 1108, a Download Failed note will be visible to the user 1 110. Otherwise, the Download Failed note will be hidden 1112.
  • the per- digest styleheet will update all items 1112, hiding closed messages, unhiding current status messages, hiding expired items, and unhiding newly current items. If a link to a remote personalized stylesheet has been embedded 1 114, the system will download the personalized stylesheet 1116. If the download fails 1118 a notice will remain visible showing that the message has not been personalized because the download failed 1120. Otherwise, if the download was successful 1 118 it will overrule the styles defined by the global and per-digest stylesheets 1122, highlighting or hiding messages based on sender and category.
  • the toolbar will then re-parse the document and perform additional updates and functions 1130 (see FIG. 12). Otherwise, a link may remain visible 1 126 in the digest alerting the user that such a toolbar extension is available.
  • FIG. 12 is a process flow diagram depicting the client-side process flow steps according to an embodiment of the present invention where the user has the additional toolbar module.
  • the toolbar when the email client downloads a message, the toolbar will parse the message 1202 and first verify the message is authentic 1204. If the message fails the authenticity test 1206, meaning it does not match the copy of the digest on the server, or variables which define that digest (perhaps it was sent by a spammer to 'phish' for personal information) the toolbar will hide the contents of the email digest and warn the recipient that it is a fraudulent copy 1208. If it is authentic 1210, each posting will be examined 1212 to check if the posting's status is still open 1214. If the posting has been closed it will hide the posting 1216.
  • the toolbar can check with the system's database, and it would not matter if the per-digest stylesheet had been updated yet. If the posting has been updated 1218 it can display the updated posting 1222. (Whereas recipients without the toolbar will only see a notice that the message has been updated, those will the toolbar will see the current version, as the toolbar can update the text of the email.) Otherwise, the original posting will be displayed 1220. If there have been replies to the posting 1224, the toolbar can download and display the number of replies in the notification 1226, and if the replies are public 1228 it can display them 1232 under each message in the digest, thus the recipient does not have to visit a website or click any links to view the current information.
  • the toolbar can open a form 1240 for the user to reply directly in the email client, and the toolbar will handle the reply. If the responder wishes to reply anonymously and this is allowed by the group 1236, the toolbar will assign an anonymous name or email address 1238, such as 'responderl2345@example.com 1 to the responder. It will then show the reply form 1240. When the responder submits the form, the server will add the reply to the database 1242.
  • the per-digest stylesheet can be updated 1246 to reflect that this message has been updated.
  • the poster of the message is then notified 1248 that a response has been made to the message.
  • FIG. 13 is a process flow diagram depicting the process flow steps according to an embodiment of the present invention where the user clicks to reply to a message.
  • the process would act as in FIG. 12 1304.
  • a user without such an extension to their email client would effect the opening of a link in their browser displaying a reply form 1306.
  • replies 1310 to prevent the user from doing needless redundant work by repeating an answer.
  • the system would display a form to collect the user's reply 1312. Upon submission of the form the reply would be stored in a database 1314.
  • FIG. 14 and FIG. 14a are process flow diagrams depicting the steps according to an embodiment of the present invention where an email client would parse a mail digest 1400, taking into account the various stylesheets to update the digest. For each item 1460 in the digest, the per-digest stylesheet will dictate whether the item is open 1402.
  • the item will hide 1404 the item 1460 and unhide the status message 1406 for that item which informs the recipient that it is closed 1462. Then, for the item, the personal-stylesheet will over-rule all previous stylesheets. If in the personal stylesheet the recipient has dictated that all messages from the sender of this message should be hidden 1408, the system will hide 1410 the message by hiding the sender container 1464 and it will unhide 1412 the status message 1466 saying this sender has been hidden by the recipient.
  • the personal stylesheet will modify the style 1420 of the sender container 1464, and inform the user that they have requested to highlight messages from this sender by un-hiding 1418 the sender highlight note 1468.
  • Modifying the style 1420 can include such things as changing colors, fonts, and sizes to make the posting more noticeable.
  • the system may unhide 1436 the note 1478 indicating that this is a sponsored message and may modify the styles 1438 of the sponsored message container 1476 for this message to signal to the recipient that this message is different from all others.
  • Such a system enables moderators and service providers to highlight important messages, and accept sponsorships for fundraising or profit.
  • the sponsorship can be defined in the remote per-digest stylesheet 1438, it can be modified after the digest is mailed, thus enabling sponsors to pay either for an amount of time or an amount of viewers. For example, they may pay only for the message to be highlighted until a certain date, or until 5000 people download the digest. If the message is not sponsored, the stylesheets do not modify 1434 the style of the sponsored container.
  • the per-digest stylesheet may unhide 1444 a note 1482 informing the user that there is an updated version of this posting available online and perhaps providing a direct link to the posting's page on the service provider's website.
  • the system can unhide 1450 a note 1484 informing the recipient that there have been replies to this posting. This helps recipients avoid losing time providing answers that would only be redundant, and it lets viewers know that someone may have added additional useful information to the original posting since it was compiled. Without this functionality, users would only know about updates that happened before the digest was compiled and mailed, thus missing much of this information.
  • some posters may not wish to receive replies to their posting. Sometimes they may know this before posting, however, the present invention enables them to change their mind 1452, even after the digest has been sent.
  • the per-digest stylesheet can be updated at any time to hide 1456 or show 1454 response options 1488, such as 'Reply' or 'Click to call.' This can be useful for broadcast-type messages such as "school will be closed due to snow," where the school administrator does not want to receive questions about that message from thousands of parents. This is also useful where the poster has received a useful answer and does not need further responses, but wishes to enable other recipients to see the question and benefit from the answers.
  • FIG. 15 is a process flow diagram depicting the steps according to an embodiment of the present invention where an email client would parse a single- notification email 1500.
  • a message might be: "You have a new message on the website, click here to visit the website and read it.” However, if the recipient was on the website while that notification was sent to him, the recipient is likely to have read the message before seeing the notification, thus the notification is outdated and clicking its link would be redundant and useless.
  • the notification email would call to a remote stylesheet 1501 which would indicate if the status of that notification email had changed. If it had changed 1502 it would unhide a status note 1504 which corresponds to the status of the email.
  • FIG, 16 is a process flow diagram depicting the steps according to an embodiment of the present invention where an email client would parse a non- message item 1600, such as an advertisement or event listing, in any email.
  • the client having called a remote stylesheet 1602 would follow the rules dictated for that item's style. If the item is not closed or expired 1604, the item would remain visible to the recipient 1606. If the item has expired, however, the stylesheet would hide the item 1608, setting its display property to hidden. This method would also enable systems to embed replacement items into the message 1610 and unhide them 1614 when the original item is hidden 1608.
  • a digest might display an advertisement at the top of the screen, and the advertiser may wish to pay only for the first 1000 recipients to view the advertisement, or may wish to hide the advertisement after a certain date. If the digest only hides that message it will make no more revenue. However, it can embed a hidden advertisement which will be made visible at the time the original advertisement is hidden.
  • FIG. 17 is a process flow diagram depicting the steps according to an embodiment of the present invention where a customized mail server would enable one individual to send email to another individual and then update the status of the sent email 1712.
  • the user would send an email using their email client or a web- based control panel 1702. In either case, the message would go through the user's email server 1704. If the user is using an email client they would accomplish this by specifying it as their outgoing-mail or SMTP server. A modification to the server would assign the message a unique ID 1706.
  • a link would then be embedded to a corresponding stylesheet or a stylesheet-generating script for that message ID 1708.
  • the message and its status would then be indexed 1710 in a database or in a static stylesheet. Once the link is embedded into the email, the server can transmit the email to the recipient mail server 1714.
  • the sending server When the recipient downloads the message 1716 from their mail server, if their email client calls the sender's server to download the remote stylesheet 1718, the sending server will retrieve or generate a stylesheet for that message ID with the current status 1722. The sender's server can then mark the message as read 1724 by the email client. If the sender requested notification of when the recipient opens the email 1730, the sending server can send a message to the sender 1732. Unlike traditional read receipts which are sent by the recipient's server, and are at the mercy of that server, this notification is done by the sender's server, so the notifcation can be done via email, instant message, text message or an alert via their email client, or any method the sender prefers.
  • the status of the message is updated as read 1724 and the sender will see this status in their mail control panel 1734, and they may also see if their mail server saved a copy of the sent email in their Sent Mail folder, with a link to a dynamic stylesheet, just as with the mail sent to the recipient.
  • Such status and notification functionality is useful today when many legitimate and important emails are accidently deleted or blocked by spam filters. If the sender sees that a message has not been opened, they may re-send it or contact the user by another means to ensure they receive important information.
  • the sender updates the message status at any time, or if the recipient replies, the stylesheet can be modified, and the recipient will see the current status of the message 1728. Statuses might include "The sender says to disregard this message,” "The sender has sent an updated message which should appear in your inbox,” and "You have replied to this message.” If the sender feels the original message is no longer relevant they may choose to hide it 1726, so the recipient does not waste time reading it.
  • HTML tags As well as header lines which instruct HTML parsers not to store the message and the linked stylesheets in cached memory, such as the HTML "no-cache" meta tag. While these tags are sometimes not honored by the parsers, they may ensure the email client opens current versions of all remote stylesheets and images each time the user refers to an email, thus always showing them the current statuses.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Operations Research (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne un système et un procédé qui permettent la mise à jour dynamique d'un message de courrier électronique statique tout en maintenant l'état du contenu du message de courrier électronique sur un serveur et en servant à distance des images ou des feuilles de style relayant l'état actuel au client de courrier électronique d'un utilisateur quand le résumé de courrier électronique statique est affiché. D'autres applications du système et du procédé comportent, entre autres, la mise à jour de l'état d'articles postés sur des tableaux électroniques de messagerie en ligne dans un résumé de courrier électronique une fois que la personne qui a posté l'article a accompli ce que l'article demandait, pour qu'elle ne soit pas recontactée par la suite au sujet de l'article posté par des utilisateurs lisant le résumé de courrier électronique.
PCT/US2007/073920 2006-07-19 2007-07-19 Système et procédé permettant une modification dynamique d'état d'éléments dans des messages de courrier électronique statique WO2008011534A2 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US82676906A 2006-07-19 2006-07-19
US80781206P 2006-07-19 2006-07-19
US60/807,812 2006-07-19
US11/826,769 2006-07-19

Publications (2)

Publication Number Publication Date
WO2008011534A2 true WO2008011534A2 (fr) 2008-01-24
WO2008011534A3 WO2008011534A3 (fr) 2008-09-12

Family

ID=38957632

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2007/073920 WO2008011534A2 (fr) 2006-07-19 2007-07-19 Système et procédé permettant une modification dynamique d'état d'éléments dans des messages de courrier électronique statique

Country Status (1)

Country Link
WO (1) WO2008011534A2 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5548753A (en) * 1994-09-14 1996-08-20 Johnson Service Company Automatic electronic mail notification of database events
US20030200272A1 (en) * 2002-04-18 2003-10-23 Leon Campise System and method for data collection and update utilizing surrogate e-mail addresses using a server
US20030233420A1 (en) * 2000-04-03 2003-12-18 Juergen Stark Method and system for content driven electronic messaging

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5548753A (en) * 1994-09-14 1996-08-20 Johnson Service Company Automatic electronic mail notification of database events
US20030233420A1 (en) * 2000-04-03 2003-12-18 Juergen Stark Method and system for content driven electronic messaging
US20030200272A1 (en) * 2002-04-18 2003-10-23 Leon Campise System and method for data collection and update utilizing surrogate e-mail addresses using a server

Also Published As

Publication number Publication date
WO2008011534A3 (fr) 2008-09-12

Similar Documents

Publication Publication Date Title
US20090248806A1 (en) System and method for dynamically changing item status in static email messages
US7587678B1 (en) Email-based customer support management system
US10606930B2 (en) System and method for managing content on a network interface
EP1447765B1 (fr) Méthode, appareil, et interface utilisateur pour contrôler le courrier électronique et les messages d'alerte
US8244815B1 (en) Enabling electronic logging through an instant message system
US9189479B2 (en) Semantic web portal and platform
US7620996B2 (en) Dynamic summary module
US8090776B2 (en) Dynamic content change notification
US7127515B2 (en) Delivering electronic content
US7640322B2 (en) Systems and methods for producing, managing, delivering, retrieving, and/or tracking permission based communications
US20070234207A1 (en) Method And Apparatus For Inserting And Removing Advertisements
US6615238B1 (en) Evolving interactive dialog box for an internet web page
US20070244977A1 (en) Dynamic e-mail system and method
US20080066080A1 (en) Remote management of an electronic presence
US20080065974A1 (en) Template-based electronic presence management
US20040039778A1 (en) Internet communication
EP2449481A1 (fr) Système et procédé pour améliorer un contenu numérique
US20050080854A1 (en) Internet-based system and method for providing selected information to recipients
US20080216023A1 (en) Method and a system for creating a website guide
US20030167250A1 (en) Information delivery system
US11775754B1 (en) Systems and methods for improved user-reviewer interaction using enhanced electronic documents linked to online documents
US20020170040A1 (en) Computer implemented user relationship maintenance technique for target software application
KR100422435B1 (ko) 다수간의 이메일 전송 관리 방법
WO2008011534A2 (fr) Système et procédé permettant une modification dynamique d'état d'éléments dans des messages de courrier électronique statique
US20030225842A1 (en) Distribution of messages using an address book of a user

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07840449

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase in:

Ref country code: DE

NENP Non-entry into the national phase in:

Ref country code: RU

122 Ep: pct application non-entry in european phase

Ref document number: 07840449

Country of ref document: EP

Kind code of ref document: A2

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载