Source: http://www.freepatentsonline.com/y2010/0064011.html
Timestamp: 2020-04-06 10:10:34
Document Index: 581893512

Matched Legal Cases: ['arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102', 'arty 102']

Automatic Non-Junk Message List Inclusion - MICROSOFT CORPORATION
Automatic Non-Junk Message List Inclusion
United States Patent Application 20100064011
Method to effectively include a transaction electronic mail (e-mail) message to a non-junk mail list of an email account of a user. The method includes interacting with the user to start to complete a business transaction at a transaction web site of a party. A confirmation step is defined to be a second to last step in a plurality of transaction steps to complete the business transaction. A request associated with the defined confirmation step is provided to the user and the request includes adding a transaction e-mail address to the non-junk mail list. The e-mail account is further received from the user, and properties of the received e-mail account are identified. The method further interacts with the user to log-in to the received e-mail account and interacts with the user to include the transaction e-mail address to the non-junk mail list of the e-mail account of the user.
12/205648
Download PDF 20100064011 PDF help
1. A method to effectively include a transaction electronic mail (e-mail) message to a non-junk mail list of an email account of a user, said method comprising: interacting with the user to start to complete a business transaction at a transaction web site of a party, said business transaction including a plurality of transaction steps; defining a confirmation step being a step in the plurality of transaction steps to complete the business transaction; providing a request associated with the defined confirmation step to the user, said request including adding a transaction e-mail address to the non-junk mail list, said transaction e-mail address being associated with the transaction e-mail message and including transaction information relating to the confirmation step, wherein said adding comprises: receiving the e-mail account from the user; identifying properties of the received e-mail account, said identified properties including log-in information of the received e-mail account; interacting with the user to log-in to the received e-mail account; and interacting with the user to include the transaction e-mail address to the non-junk mail list of the e-mail account of the user.
2. The method of claim 1, wherein adding further comprising generating a link directing the user to log-in to the e-mail account of the user, said generated link including at least the following information: a domain of the e-mail address, an end point that processes the provided request and the e-mail account of the user.
3. The method of claim 1, further comprising providing a list of potential e-mail account providers to the user, and further comprising receiving a selection from the provided list from the user.
4. The method of claim 3, wherein interacting with the user to log-in comprises interacting with the user to log-in to the e-mail account in response to the received selection from the provided list, said interacting including automatically directing the user to a web site of the provider of the e-mail account from the transaction web site.
5. The method of claim 1, further comprising suggesting additional e-mail addresses from the party in response to said adding.
6. The method of claim 1, further comprising providing a web feed to the user in response to said adding, said web feed including a list of address and descriptions thereof for the user to consider to be included in the non-junk mail list.
7. The method of claim 1, further comprising directing the user back to the transaction web site as a last step to complete the business transaction, said last step indicating the confirmation step has completed and that the transaction e-mail address has been successfully included in the non-junk mail list of the user e-mail account.
8. A system to effectively include a transaction electronic mail (e-mail) message to a non-junk mail list of an email account of a user, said system comprising: at least one e-mail provider server from an e-mail provider for providing the e-mail account of the user; at least one transaction party server for interacting with the user to start to finish a business transaction at a transaction web site of a party, said business transaction including a transaction workflow having one or more steps therein; wherein the at least one transaction party server defines a confirmation step being a second to last step in the workflow to finish the business transaction; wherein the at least one transaction party server provides a request associated with the defined confirmation step, said request including adding a transaction e-mail address to the non-junk mail list, said transaction e-mail address being associated with the transaction e-mail message and including transaction information relating to the confirmation step, wherein said adding comprises: receiving e-mail account information from the user, said received e-mail account information identifying the at least one e-mail provider server; interacting with the user to log-in to the received e-mail account with the at least one e-mail provider server; and interacting with the user to include the transaction e-mail address to the non-junk mail list of the e-mail account of the user.
9. The system of claim 8, wherein the at least one transaction party server further generates a link directing the user to log-in to the e-mail account of the user at the at least one e-mail provider server, said generated link including at least the following information: a domain of the e-mail address, an end point associated with the at least one e-mail provider server that processes the provided request and the e-mail account of the user.
10. The system of claim 8, wherein the at least one transaction party server further provides a list of additional e-mail account providers to the user, and further comprising receiving a selection from the provided list from the user.
11. The system of claim 10, wherein the at least one transaction party server interacts with the user to log-in to the e-mail account in response to the received selection from the provided list, said interacting including automatically directing the user to a web site of the provider of the e-mail account from the transaction web site.
12. The system of claim 8, wherein the at least one transaction party server further suggests additional e-mail addresses from the party in response to said adding.
13. The system of claim 8, wherein the at least one transaction party server further provides a web feed to the user in response to said adding, said web feed including a list of address and descriptions thereof for the user to consider to be included in the non-junk mail list.
14. The system of claim 8, wherein the at least one e-mail provider server directs the user back to the transaction web site as a last step of the workflow to complete the business transaction, said last step indicating the confirmation step has completed and that the transaction e-mail address has been successfully included in the non-junk mail list of the user e-mail account, wherein the at least one e-mail provider server and the at least one transaction party server maintains a transaction status as a function of the transaction workflow.
15. A method to effectively include a transaction electronic mail (e-mail) message to a non-junk mail list of an email account of a user, said method comprising: receiving a request from a party for adding a transaction e-mail address to the non-junk mail list of the e-mail account of the user, said party providing a transaction web site for interacting with the user to start to complete a business transaction at the transaction web site of the party, said business transaction including a transaction workflow having one or more steps therein, wherein the party defines a confirmation step being a second to last step in the workflow to complete the business transaction, wherein the received request is associated with the defined confirmation step, said transaction e-mail address being associated with the transaction e-mail message and including transaction information relating to the confirmation step, said request further includes an address of the transaction web site and the e-mail account of the user; in response to the received request, providing the following information to the party: a domain of the e-mail address, an end point associated processes the received request, and a log-in web site for the user to log-in to the e-mail account; interacting with the user to log-in to the log-in web site; and interacting with the user to include the transaction e-mail address to the non-junk mail list of the e-mail account of the user.
16. The method of claim 15, further receiving additional e-mail addresses from the party in response to the transaction e-mail address being included in the non-junk mail list of the e-mail account of the user.
17. The method of claim 15, further receiving a web feed from the party to the user in response to the transaction e-mail address being included in the non-junk mail list, said web feed including a list of address and descriptions thereof for the user to consider to be included in the non-junk mail list.
18. The method of claim 15, further comprising maintaining a state of the transaction workflow as a function of the confirmation step.
19. The method of claim 18, further comprising directing the user back to the transaction web site as a last step of the workflow to complete the business transaction as a function of the maintained state, said last step indicating the confirmation step has completed and that the transaction e-mail address has been successfully included in the non-junk mail list of the user e-mail account.
20. The method of claim 15, wherein providing the following information comprises providing the following information to the party in a uniform resource identifier pattern or a uniform resource locator pattern: a domain of the e-mail address, an end point associated processes the received request, and a log-in web site for the user to log-in to the e-mail account.
Electronic mail (e-mail) usages have become omnipresent in everyday use for online users. Commercial senders or merchants send many of the messages that users receive in their e-mail accounts. These messages include account signup confirmations, order confirmations, receipts, shipping status and newsletters. In other cases, users wish to receive these sorts of messages in their inbox, such as shipping notifications. On the other hand, the users do not want messages to distract them or they are simply uninterested in receiving the messages, such as a newsletter.
Currently, users face at least the following unfortunate situations: 1. E-mail messages that the user wishes to see are forwarded to the junk folder. For example, this includes messages relating to account signup confirmations, account signup verifications, order confirmation, order status, and shipping confirmation. 2. E-mail messages that the user does not wish to receive (but are legitimate) are marked as junk, such as newsletters, sales e-mail messages, e-mail messages that the users might be interested in.
In the first situation, it is problematic because the merchants wish those messages are indeed delivered, because the merchants do not wish to receive inquiries from users who are expecting to receive these types of e-mail messages. In this case, both the sender and the recipient have an interest in the message being delivered to the inbox without being marked as spam or junk. This is also especially true for any website that requires account signup verification.
Both parties would like a solution (senders and recipients) to these problems. Solutions to date have relied on rudimentary tools and don't work very effectively. For example, users end up using a blunt tool (such as the junk button and blacklist) to make the problems go away, which further complicates the ability to receive legitimate messages from the sender.
Some senders try to address this situation by including instructions on how to add the sender to the safelist or whitelist, by joining the sender score certified program, or by using SenderID. Unfortunately, these solutions are not widely adopted and result in frustration on the user and sender's part. Some users may not follow the instructions correctly. Other attempts take a different approach by petitioning to the users in response to receiving the user's e-mail address/account. However, many times users wish to use different e-mail addresses for receiving such types of e-mail messages from those used when signing up or registering the user accounts for online purchases.
Embodiments of the invention attempt to solve the problem by including a step in the workflow of a transaction to include the desirable e-mail address in a non-junk mail list of a user. Embodiments of the invention further leverage a model that has XML feeds (e.g., feed flair) to add the sender's address(es) to the recipient's safe list as well as configure any rules or filtering appropriately. Additional embodiments provide a standard uniform resource locator (URL) pattern that any third party can use to direct users to safelist the originator's email address. Any email provider can then expose this address and allow end users to safelist messages before they are sent to the recipient through a custom workflow.
FIG. 1 is a block diagram illustrating an exemplary embodiment of a system to effectively include a transaction e-mail address to a non-junk mail list of a user according to an embodiment of the invention.
FIGS. 2-9 are exemplary block diagrams illustrating processes to effectively include a transaction e-mail address to a non-junk mail list of a user according to an embodiment of the invention.
FIG. 10 is an exemplary flow chart illustrating operation of effectively including a transaction e-mail address to a non-junk mail list of a user according to an embodiment of the invention.
FIG. 11 is an exemplary flow chart illustrating operations of effectively including a transaction e-mail address to a non-junk mail list of a user by an e-mail provider working in cooperation with a party transacting with the user according to an embodiment of the invention.
Referring now to FIG. 1, a block diagram illustrates an exemplary embodiment of a system 100 to effectively include a transaction e-mail address 252 to a non-junk mail list of a user according to an embodiment of the invention. The system 100 includes at least one party 102 and at least one e-mail provider 104. In one example, the party 102 may be an online merchant that provides services and merchandize for sale to an online user 106. In another example, the party 102 may be a provider of online subscriptions that interacts with the online user 106. Also, the at least one e-mail provider 104 may be the e-mail provider for an e-mail account for the online user 106.
The at least one party 102 uses at least one transaction server 110 for providing the services to the user. In one embodiment, the transaction server 110 may be server computer, a cluster of server computers, computers in a distributed environment, or a cluster of networked, loosely-coupled computers acting in concert to perform tasks. In another embodiment, the transaction server 110 may be a computer 130 illustrated in FIG. 12. Similarly, the e-mail provider 104 may also employ a server 112 which may be similar to the transaction server 110. For example, the server 112 may include a web server, a database server, a front-end server, a back-end server, or the like. In one embodiment, a memory storage 114 is accessible to the server 112 which provides data storage for e-mail accounts, including the e-mail account of the online user 106.
In one embodiment, the user 106 interacts with a user interface (UI) 116 hosted or provided by the transaction server 110 to access the services provided by the party 102. In one example, the service may be an online purchase or online subscription. As such, by interacting with the online purchase service or online subscription service, the user 106 may perform one or more of the following actions: browse through product selection or offerings, select a desirable product, merchandize or scription title, provide payment and shipping information when appropriate and confirm one or more previous actions before completing the transaction. In the online purchase example, the merchant or party 102 typically has a set of steps or a workflow of online purchase steps that one purchaser needs to complete before the online purchase is completed. These online purchase steps include at least one of the following: selecting desirable items, entering payment or shipping information, entering optional gift or special request information, entering discount or coupon information, and confirming purchase order information. FIGS. 2-9 describe how embodiments of the invention can be incorporated into the purchase workflow in further detail.
Referring now to FIG. 2, an exemplary diagram illustrates a typical online purchase order workflow having embodiments of the invention included therein. For example, a web page 200 describes a confirmation page/step defined by the party 102. For example, the confirmation page defines a step or a status 202 in the transaction that the party 102 determines the transaction has reached a stage where additional input from the user 106 is beneficial, in particular with respect to including transaction e-mail addresses from the party 102. In this example, the confirmation step/stage is in the 3 stage (denoted in the status 202 with an underline underneath the number “3”). That is, the user 106 has started or initiated the process from step 1 through step 2 before reaching step 3. The web page 200 also includes a summary 204 of the order. In the situation involving online purchasing transactions, the transaction e-mail addresses include e-mail addresses from the party relating to shipping notification, order confirmation, shipping update, changes to orders, order cancellation confirmation, order returns, and order refunds. In other examples such as online subscription transactions, transaction e-mail addresses include e-mail addresses relating to subscription confirmation, subscription cancellation, subscription renewals, etc. In a further example, online forums or other services that require an online account use transaction e-mail addresses to send e-mail messages to users relating to account sign-up confirmation, account information change confirmation, etc. Not only do these e-mail addresses change over time but also users may change addresses overtime or users may decide to organize e-mail accounts for different purposes. For example, the user may wish to set up an account which receives all shipping confirmation e-mail messages. In another example, the user may use an account for order confirmation e-mail messages.
As such, embodiments of the invention effortlessly integrate aspects of the invention into the existing transaction workflows of the party 102 by incorporating a dialog box 206 or the like as a request on the web page 200 to facilitate the inclusion of the transaction e-mail address 252 to the non-junk mail list of the e-mail account of the user 106. By including the transaction e-mail address 252 to the non-junk mail list, the party 102 can ensure that whatever communication that the party wishes to communicate with the user 106 via the transaction e-mail address 252 is delivered to the user 106. As such, the box 206 includes a first button 208 which asks the user to indicate that he or she wishes to add the transaction e-mail address 252 to the non-junk mail list. A second button 210 indicates that the user has already added the transaction e-mail address 252 to the non-junk mail list and can proceed to the next step in the workflow. Other buttons or controls that facilitate the request may be used or added without departing from the scope of the invention.
Referring now to FIG. 3, another page 220 may be presented to the user 106 to enter the e-mail account where the user 106 wishes to receive transaction relating information from the transaction e-mail address 252 from the party 102. The user 106 may enter the e-mail account by typing the complete e-mail address (username and domain name separated by a symbol “@”) in a field 224 or by enter a username in a field 226 and choose an appropriate domain name from a field 228. The party 102 and the e-mail provider 104 may collaborate together to make the addition or inclusion of the transaction e-mail address 252 to the non-junk mail list even more effective. In one embodiment, after entry of the fields 224 or 226 and 228, the user 106 selects a next button 230 to proceed to the next stage. Upon receiving an indication from the user 106 that the next button 230 has been activated (i.e., depressed by the user via an input device or touch), the party 102 transmits the information or data from the fields 224, 226 or 228 to the e-mail provider 104 such that the e-mail provider 104 generates a link for the party 102 to direct the user 106 to log into the e-mail account. The generated link identifies the e-mail provider 104 and a receiving component within the server 112 that is capable to handle such a request of including the transaction e-mail address 252 to the user's non-junk mail list. For example, the generated link may be in the form of a uniform resource locator (or uniform resource identifier) (URL) link having at least the following information: a domain of the e-mail address, an end point that processes the provided request and the e-mail account (e.g., username) of the user 106. In one embodiment the URL link include the following pattern:
http://<yourDomain>/<endpoint>?address=<emailAddress>&company=<companyName>&description=<Description>&return Url=<returnUrl>
For example, the “<yourDomain>” may indicate the domain name of the e-mail provider 104. “<endpoint>” may indicate the processing component or function that can process such a request. “<emailAddress>” may indicate the e-mail address of the user 106. “<companyName>” may indicate the name of the party 102. “<Description>” may indicate the description of the party 102 or the description of the transaction e-mail address 252. “<return URL>” may indicate a web page to which the user 106 is returned to after the completion of the transaction e-mail address 252 inclusion. It is to be understood that other URL link pattern or link pattern may be used without departing from the scope of embodiments of the invention. Similarly, the link delimiters (e.g., “/” or “&”) may be modified without departing from the scope of embodiments of the invention.
In another embodiment, the e-mail provider 104 may provide the structure or the syntax of the link in advance and the party 102 may insert the appropriate information before directing the user 106 to log-in into the e-mail account. For example, suppose the user 106 chooses to enter the e-mail address in the field 224, the transaction server 114 may parse the information in the field 224 collected from the user 106 by identifying the “username” and “domain name” from the entered e-mail address. The transaction server 114 may next place the appropriate information to the link according to the structure of the link. Similarly, if the user 106 chooses to enter the information via fields 226 and 228, the information collected in these fields will be placed in the link according to the structure thereof. In a further embodiment, the party 102 and the e-mail provider 104 may have a business relationship or arrangement where the user 106 may have already logged into an enterprise domain such that the party 102 and the e-mail provider 104 are just one of the services available within the enterprise domain. For example, the enterprise domain may include an online market place where users can make purchases online and an e-mail communication service where users can sign up e-mail accounts and send e-mail messages. In this situation, after activating the “next” button 230, the user 106 may be taken directly to the e-mail account of the user 106 where junk/non-junk mail list is processed and the transaction e-mail address 252 from the party is automatically included in the non-junk mail list.
In the situation where the user 106 is directed to log-in to the e-mail account of the user 106, the user 106 may see a message 232 indicating that the user 106 is being directed to a log-in page 120 (shown in FIGS. 1 and 5 ) of the e-mail provider 104, as shown in FIG. 4. FIG. 5 describes a typical log-in page 120 in FIG. 5 for the user to log-in to the e-mail account. In one embodiment, the username of the e-mail account of the user 106 may be automatically entered by the e-mail provider 104 or the party 102 based on the information collected in fields 224 or 226. Once the user 106 enters the required credentials, the user 106 may select a “Log-in” button 242 to log-in to the e-mail account or a “forgot password” button 244 to ask the server 112 for assistance to retrieve the password. In one embodiment, the log-in page 120 is hosted by the server 112 and the server 112 maintains a status of the transaction that take place at the transaction server 1 16. For example, the party 102 and the e-mail provider 104 may have a further partnership where security or authentication schemes of secured transactions such as online purchases are seamlessly shared with each other. Under this partnership, the user 106 may smoothly transition from one web site to another web site. In another embodiment, the state may be maintained in conjunction with a client computer, such as a client computer 130 in FIG. 12, of the user 106. For example, the state may be maintained in conjunction with the cookie set by the party 102 and stored by the client computer (e.g., when the user 106 browses to the web site via a web browser). It is to be understood that, to maintain and protect the privacy of the user 106, appropriate notices are displayed, subject to various settings and configurations of the client computer, to the user 106 before reading or accessing information that is already stored on the client computer of the user 106.
In another embodiment, the location where the state information 202 is displayed may be hosted and controlled by the party 102. In other words, while the page 120 may be hosted by the e-mail provider 104, the server 112 may include appropriate code within the page 120 to directly allow the party 102 to place the state information 202 on the log-in page 120.
Referring now to FIG. 6, the user 106 is presented with a page 250 to include the transaction e-mail address 252 to a non-junk mail list 258. In one embodiment, the non-junk mail list 258 may be also known as an e-mail whitelist or safelist which is a list of e-mail addresses that are deemed acceptable by the user 106. The user 106 may choose a “YES” button 254 to add the transaction e-mail address 252 to the non-junk mail list 258 or a “NO” button 256 to reject the inclusion of the transaction e-mail address 252 to the non-junk mail list 258. Once the user 106 selects the “YES” button 254, a page 260 is displayed to the user 106 indicating that the inclusion of the transaction e-mail address to the non-junk mail list 258 is successful in FIG. 7. The user 106 may select a button 262 to return to the party to complete the transaction. In an alternative embodiment, the user 106 may be automatically redirected back to the transaction server 116 after a short delay (e.g., 5 seconds) in response to the <returnURL> information provided by the transaction server 1 16. For example, the returned page represented by the <returnURL> may be the final stage or step in the transaction workflow of the transaction. In a further alternative embodiment, the <returnURL> may be determined as a function of the state information 202. For example, the state information 202 may be linked to a <returnURL> and depending on the state or status the user 106 is in, the <returnURL> may change corresponding to the state information 202.
In an alternative embodiment, the transaction server 116 may further provide additional transaction e-mail addresses to the user 106 for consideration such as those shown in FIG. 8. For example, an additional list 272 may provide one or more transaction e-mail addresses to the user 106 for further consideration, such as “order merchant[dot]com” or “return@merchant[dot]com”. In one embodiment, the additional list 272 may be provided via a web feed, such as an XML feed. It is to be understood that the web feed may be provided at a later time. For example, the additional list 272 may be written in an extensible markup language (XML) format such as the following:
<address>foo@bar.com</address>
<company>Foo Bar</company>
<description>E-mail address used for order confirmations</description>
/record>
/sender>
The user 106 is also presented with appropriate buttons 274 and 276 to indicate the decision to include additional transaction e-mail addresses. In a further embodiment, the e-mail provider 106 may provide a richer user experience by requesting if the user 106 wishes to automatically file all messages sent from the transaction e-mail address 252 into a folder or folders within the user's e-mail account that the user 106 can periodically review and archive without having e-mail messages from the transaction e-mail address 252 fill the inbox of the user's e-mail account unintentionally.
Referring now to FIG. 9, an order completion page 900 illustrates the last step of the transaction workflow indicating the user 106 has completed the ordering process. The state information 202 correspondingly displays the correct state, the state “4,” which indicates that the user 106 has completed or finished the ordering process. Advantageously, embodiments of the invention introduce a workflow or process that will allow merchants or parties (e.g., party 102) to provide a seamless experience for adding the e-mail address required for communicating with the customer to customer's safe list or the non-junk mail list. In one embodiment, an “Add to Safe List” button may appear on merchant's or party's web site and will lead customers to pages, such as the page 220. The pages will allow confirming the addition of the incoming e-mail address to the safe list, specifying the time interval for allowing e-mails from this merchant to come through, and possibly selecting a destination folder for this type of e-mail messages.
Referring now to FIG. 10, a flow diagram illustrates operations to effectively include a transaction electronic mail (e-mail) message to a non-junk mail list of an email account of a user according to an embodiment of the invention. At 1002, a transaction server from a merchant or party interacts with the user (e.g., user 106) to complete a business transaction at a transaction web site of the party. The business transaction includes a plurality of transaction steps, such as a transaction workflow). The transaction server defines a confirmation step being a step in the plurality of transaction steps to complete the business transaction at 1004. In one embodiment, the confirmation step may be the second to last step in the plurality of steps. At 1006, a request associated with the defined confirmation step is provided to the user. The request includes adding a transaction e-mail address to the non-junk mail list of the user's e-mail account. The transaction e-mail address is associated with the transaction e-mail message and includes transaction information relating to the confirmation step. At 1008, the adding further includes receiving the e-mail account from the user. Properties of the received e-mail account are identified at 1010, and the identified properties include log-in information of the received e-mail account. At 1012, the e-mail provider of the e-mail account interacts with the user to log-in to the received e-mail account. At 1014, the e-mail provider interacts with the user to include the transaction e-mail address to the non-junk mail list of the e-mail account of the user.
FIG. 11 is an exemplary flow chart illustrating operations of effectively including a transaction e-mail address to a non-junk mail list of a user by an e-mail provider working in cooperation with a party transacting with the user according to an embodiment of the invention. At 1102, the e-mail provider (e.g., e-mail provider 104) receives a request from a party for adding a transaction e-mail address to the non-junk mail list of the e-mail account of the user. The party provides a transaction web site for interacting with the user to complete a business transaction at the transaction web site of the party at 1104. The business transaction includes a transaction workflow having one or more steps therein at 1106. The party defines a confirmation step being a step or a second to last step in the workflow to complete the business transaction, and the received request is associated with the defined confirmation step at 1108. The transaction e-mail address is associated with the transaction e-mail message and including transaction information relating to the confirmation step at 1108. At 1110, in response to the received request, the e-mail provider provides the following information to the party: a domain of the e-mail address, an end point associated processes the received request, and a log-in web site for the user to log-in to the e-mail account. At 1112, the e-mail provider interacts with the user to log-in to the log-in web site. The e-mail provider further interacts with the user to include the transaction e-mail address to the non-junk mail list of the e-mail account of the user at 1114.
In operation, computer 130 executes computer-executable instructions such as those illustrated in the figures, such as FIG. 10, to implement aspects of the invention.
Previous Patent: ENCOURAGING USER ATTENTION DURING PRESENTATION SESSIONS THROUGH INTERACTIVE PARTICIPATION ARTIFACTS
Next Patent: METHOD, SYSTEM AND APPARATUS TO AUTOMATICALLY ADD SENDERS OF EMAIL TO A CONTACT LIST