CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of and claims the benefit of priority from

EPO application number 15003361.1 /EP 15003361, entitled "SYSTEMS AND METHODS FOR CONTENT DISTRIBUTION AND RECOMMENDATION OVER MESSAGING TECHNOLOGY", and filed on November 25, 2015.

TECHNICAL FIELD

Aspects of the disclosure relate to providing content recommendations and content discover .· facilities. More specifically, aspects of thp disclosure are directed to providing content recommendations and content discovery facilities over messaging technology.

MOTIVATION AND PROBLEM DEFINITION Messaging systems, most notably electronic mail (email), but also Instant Messaging (IM) or Short Message Service (SMS), among others, allow a user of the system to create messages and specify a set of recipients, and delivers the message to each intended recipient. Since these systems require the sender to explicitly provide (a reference of) each recipient (whether directly or indirectly through mailing or subscription lists), and messages are typically not intended to be received by users- not directly or indirectly listed in the recipient list, such messaging systems are often used to exchange messages of a personal nature.

Messaging systems, however, are so widely-used (a recent Pew Research survey found email use to be the top online activity, along with search engine use [Purll]), that they are often used not just to exchange personal messages, but also to exchange non-personal information, such as news or opinion articles, videos, documents, images, or URLs, often of general interest to the sender and/or the recipients. Indeed, a Pew research study of 2010 found that "[...] more than 8 in 10 online news consumers get or share links in emails", and that "Of the 71% of the adult population who get news online, 75% of them say they get news forwarded to them through email or posts on social networking sites. [...] Of these internet users who get news online, 50% say they pass along email links to news stories or videos to others. (That represents 48% of all internet users)." And, at least on mobile platforms, sharing seems to be most commonly done over email: a study from 2014 by Rumble found that, among mobile users, "[...] 76 percent of all articles shared were through email" [Ruml4], while a more recent one from RadiumOne found that "82 percent of content shared on mobile is shared through messaging, email or text" [Radl5].

Despite its very extensive use, we argue that, when used to exchange information of a non-personal nature (which we henceforth refer to as content items, and which may take the form of email messages, SMS messages, instant messages, among others), traditional messaging systems suffer from the following drawbacks:

1 (filtering problem) a user of the system may receive content items he or she is not interested in receiving,

2 (discovery problem) the sender of a content item may not be sending the content item to some users who would be interested in receiving the content item; this often happens because the sender forgets to include the interested user in the content item's recipient list, or simply because the sender is unaware of the existence of other interested users,

3 the burden of deciding which users may be interested in receiving the content item is placed on the sender.

Ideally, the burden of deciding which users may be interested in receiving the content item can be taken off the sender, and content items can be delivered to users despite them not being directly or indirectly (e.g. through mailing or subscription lists) addressed in the content item's recipient list.

Recommendation engines are "software tools and techniques providing suggestions for items to be of use to a user" [RRSK10] by predicting a "rating" or preference that a user would give to a content item. Recommendation engines take as input a set of known ratings over user-item pairs, and aim to estimate some or all of the missing ratings (or in some cases a relative ordering of items, or ranking, rather than their estimated ratings). Recommendation engines have long been used to address the above drawbacks 1, 2, and in some cases also 3, in such varied applications as finding interesting music (Pandora, or [EKH ⁺ 14]), recommending products (Amazon), recommending television programs [KSG14], in browser toolbars or extensions to provide users with recommendations and gather explicit webpage ratings from users [SCBL11] , or indeed recommending messages or posts of a non-personal nature (e.g. Twitter's recent so-called "algorithmic timeline" [PIE16]), and have an extensive history of use in practical applications [RRSK10].

Crucially, to accomplish its task, a recommendation engine must receive information of known ratings that users (either explicitly or implicitly) assign to items. In the case of messaging systems, most notably email, there is no natural way to obtain content item rating information from users. Indeed, there is no provision in any standard email protocol (such as SMTP [KleOl], IMAP [Cri03], or. POP [MR96]) for a rating flag on messages, or any other explicit mechanism to assign a rating to a message by the user. The closest the authors could find is the so-called "Flagged" message attribute, which is defined as "Flagged: Message is 'flagged' for urgent/special attention" [Cri03] which, we argue, is not equivalent to an attribute intended to "rate" the message. Indeed, despite the long and extensive use of messaging systems such as email, the "Flagged" attribute, or any other attribute of messages found in email protocols (such as "Answered" , "Deleted" , "Draft" , "Flagged", "Recent", or "Seen" [Cri03]), has, to the author's knowledge, not been previously used to provide rating information to a recommendation engine, further confirming that the original intention of message attributes or flags, such as the "Flagged" attribute, are not to "rate" messages, but rather to aid each user in locating or managing his or her messages (by providing facilities for searching for instance for "Seen" messages that are also either marked "Flagged" or "Answered" , which the IMAP command "SEARCH SEEN (OR FLAGGED ANSWERED)" would query for).

The proposed invention begins by noticing that most messaging systems include facilities for managing messages, which typically include at least the ability to fetch and delete messages (but often more), and that these are sufficient to provide rating information to a recommendation engine, for instance by considering a message deleted or marked for deletion ("Deleted" flag [Cri03]) to be negatively rated, and a message that has been fetched but not deleted (for instance after some predefined amount of time has passed since fetching it, to allow for the user to view the item; or after one or more additional content items have been fetched, indicating that the original content item has been viewed and that the user has "moved on" to other content items; or possibly some combination of the above conditions) to be positively rated. Further message management attributes, such as the "Flagged" or "Draft" attributes [Cri03] (but also other system flags, or even user-defined flags [Cri03]) may be used as well, for instance by considering an item marked as "Flagged" as positively rated (regardless of whether sufficient time has past since the time that the item was fetched), or not generating rating signals for a message marked as "Draft" . Note that, while the above rating signals are implicit (in the sense that they are generated during the course of the user's normal interaction with the messaging system), under some messaging systems, for instance email when managed through the IMAP protocol, it is possible for the user client (or Mail User Agent (MUA)) to define so-called client-defined flags. In this case it is possible for the email client to define a "rating" message attribute, which can be used as an explicit rating. The recommendation engine then uses the rating information to generate rating or ranking estimates of some or all of the unrated items, for some or all of the users in the system, and these are used to make message delivery decisions: possibly delivering messages to users that were not either directly or indirectly (e.g. through mailing or subscription lists) referenced in the recipient list, and thereby addressing all three drawbacks listed above: relieving the sender of the burden of deciding which users may be interested in receiving the message (3), as well as both allowing filtering (1), and content discovery (2). BACKGROUND ART

To the best of the author's knowledge, the closest previous art to the proposed invention

110 is US Patent App. 12/048,789 "Systems and methods for content sharing" [SG09]. In their invention, the sender of a content item is offered a list of suggested recipients (claim l.B [SG09]), and/or a list of suggested content items to share (claim 33. B [SG09]). The user then accepts or rejects the suggested additional recipients, providing the system with a selection of "actual recipients" (claim l.C [SG09], idem, for suggested content items in

115 claim 33). Finally the system transmits the content items to the actual recipients. A recommendation engine receives "sharing records" , each including information identifying the sender, the content item, and each of the actual recipients, as confirmed by the sender. This recommendation engine is used by the system to generate future suggested recipient (or content item) lists to be presented for consideration to future senders of content items,

120 but it is still the user which has full control over the actual recipient list (the user, and only the user, decides which other users are to receive the content item, though this decision is aided by the recommendation engine, which provides suggestions). Given the above, we argue that the invention of [SG09] addresses the filtering (1) and discovery (2) problems from section "MOTIVATION AND PROBLEM DEFINITION" , but not problem 3, since

125 the burden of deciding which users are to receive the content item still falls on the sender.

The invention of [GroOS] considers the sharing of messages or documents (such as emails or other documents). A repository of documents is stored and analyzed, and based on the content analysis as well as information about which users sent which documents to other users (similar to the "sharing records" of [SG09]). When a user is composing a message, "[...]

130 the list of proposed potential new recipients is provided expressly to the user" (paragraph 0026 [Gro08]). These suggestions are presented for the user to consider for addition to the final recipient list (the "actual recipient list" in [SG09]). A similar system that suggests potential recipients to the sender of a document or message is [CKMZ14]. In this sense, all of [SG09], [Gro08], and [CKMZ14] differ from ur invention in that the burden of deciding

135 on a final recipient list rests on the sender (even if this task is aided by suggestions from a recommendation system) , whereas in our invention the system uses recommendation engine ratings (or rankings) to deliver messages to new recipients, without intervention from the message's sender.

Although less important, we also note that our recommendation engine has more sources 140 of information than the set of instances of users explicitly sending messages to recipient users (so-called "sharing records" in [SG09], but also used with a different name in [Gro08] and [CKMZ14]). In our case, the recommendation engine also gathers information from the message management part of the messaging system, such as whether each recipient has either fetched and kept, or fetched and deleted a message.

145 Consider as an example a single event of user A sending content item II to user B. This would be recorded in the system of [SG09], [Gro08], and [CKMZ14] as a single "share record" (possibly with additional information about the content of II, such as which category among a given list of topic categories II belongs to). The same event, in our system, may lead to, for example, user B fetching and keeping (not deleting) the content item (which can

150 be recorded as B positively rating II); from this and the previously recorded information (possibly including similar "sharing records" , and/or information about the content of the shared item), the recommendation engine generates new recipients C,D, and E, and content item II is then delivered to these new recipients, without the intervention of A. After registering rating signals from C,D,E (e.g. whether they deleted the content item after

155 fetching it), we can once again compute new potential recipients (possibly among those that have not yet received II). Note that, once new rating signals from C,D,E are available, the recommendation engine may be able to update its estimated ratings or rankings, and these ratings or rankings may change considerably if, for instance, there are users whose rating or ranking estimates heavily depend on the ratings of C,D,E. In other words, as the

160 content item is delivered to more users, the recommendation engine may receive additional information and may change its internal estimates, and this may in turn trigger additional recommendations leading to deliveries of the content item to additional users.

Note that the amount of useful predictive information gathered from a single "share event" (A sends II to B) can be considerably larger in our system, when compared to

165 simply recording a single event, as in [SG09], [Gro08], and [CKMZ14]. For example, if user B above was not interested in receiving content item II, the systems of [SG09], [Gro08], and [CKMZ14] would have no way of acquiring this information. Our system, however, can infer implicit signals of interest of B in content item II from the way B manages II (e.g. if B deletes II we may infer that B does not find II interesting, and if B flags II as "Flagged" ,

170 or starred, we may infer that B finds II interesting).

It may be argued that systems explicitly designed for the kind of sharing that we discuss in this document (i.e. where a content item can be delivered to users not explicitly or implicitly referenced by the sender in the recipient list) have existed for many years, including services like Twitter (with its algorithmic timeline [PIE16]), and Facebook (with

175 its news feed). Some such services restrict incoming content items to those posted by known users ("contacts" or "friends", as Facebook has traditionally done), or from users to which the recipient is "subscribed" or "follows" (as Twitter does), while some, such as StumbleUpon, do allow the receipt of content items from any sender. These systems, however, do not employ traditional messaging systems (for instance email, SMS, or Instant

180 Messaging) as their underlying technology, and content items are instead displayed and managed over the web using HTTP technology [FGM ⁺ 99]. Indeed, because content items in these systems are not part of a messaging system, they are not constrained to have a recipient list, and are typically referred to as "posts" . We note that the content item having a associated, sender-specified recipient list is an identifying characteristic of the underlying 185 messaging system used by the invention (claim l.ii).

Attempts to address drawbacks 1, 2, and 3, of section "MOTIVATION AND PROBLEM DEFINITION" in messaging systems have been made in the past. Most notably, electronic mailing lists [Kro89] partially address problems 2 and 3 by letting users associate themselves to a mailing list with a single identifier, which can be used by the sender to address a

190 (potentially very large) collection of users. Spam filters [SDHH98] have a long history in addressing problem 1.

Summary. While messages of a personal nature are a very natural fit to messaging systems like email, SMS, or IM, there is a very significant amount of sharing of messages of a non- personal nature over such messaging systems (possibly representing a large fraction, or even

195 a majority, of all non-personal content item sharing online). Sharing of such non-personal content items over messaging technology suffers from 1) filtering and 2) discovery problems, and 3) places the burden of recipient specification on the sender. Most messaging systems provide additional management facilities, such as the ability to fetch or delete a message. Though not original intended for that use, these message management facilities can be used

200 to inform a recommendation engine of user's ratings of items, and this recommendation engine in turn used to make decisions of which content items to deliver to which Users, addressing the above three problems.

Recommendation Engine and Content Discovery System. As described in the previous section, a recommendation system, or recommendation engine takes as input a

205 set of known ratings over user-item pairs and produces estimates of the unspecified ratings (over user-item pairs) or, for a given user, a ranking of items in order of estimated preference or interest (or likewise, for each item, a ranking of users in order of estimated preference Or interest). In this document we refer to a system that delivers content items to users based, at least in part, on information provided by a recommendation engine as a Content

210 Recommendation and Discovery System, though this choice is arbitrary and there is not, to the author's knowledge a well-established term for such a system. In this sense, the proposed invention is for a Content Recommendation and Discovery System over messaging technology. The system includes facilities for sending and receiving messages (e.g. over the SMTP protocol in the case of email), facilities for managing messages (e.g. over the

215 IMAP protocol in the case of email), as well as a recommendation engine, which is therefore only a part of the system. To emphasize this distinction we use throughout the term "Recommendation Engine" , rather than "Recommendation System" .

The recommendation engine's task is to produce, given the current state of the system (for instance the set of implicit ratings and share events, along with the characteristics of

220 content' items shared), suggestions of new recipients for any of the content items previously sent to the system by a user. The set of suggested new recipients may be computed using traditional recommendation system techniques (such as collaborative filtering [SFHS07], or content analysis [RRSK10], or some combination of the two), or using machine learning techniques [HTF09].

225 We finally note that, in the invention, the combination of messaging system and recommendation engine, linked in the manner described here (where the recommendation engine receives, among other, more traditional sources of information like share events and content analysis, implicit signals of interest from the users extracted during the course of the users' management of messages in the system; and where the messaging system receives, from the

230 recommendation engine, addresses of new recipients for existing content items, which the recommendation engine estimates are likely to be interested in receiving the content items) functions as a Content Recommendation and Discover System.

DISCLOSURE OF INVENTION

Many messaging systems, most notably email systems, provide means to fetch and to delete

235 or archive content items, and possibly to flag them. These basic operations can be used as indicators of interest by a recommendation engine. The recommendation engine can provide content recommendations to users by having some control over the content item delivery decisions, whether directly or by replacing part or all of the original recipient list of a content item in favor of recommended recipients. Note that the new recipients of a

240 content item do not have to have any relation with the sender (in particular, there is no requirement for them to subscribe to any source of content, or to be indirectly referenced in the sender's original recipient list for instance through a subscription, or a mailing list). The system may decide to deliver a content item to any of the users, independently of whether the original content item creator included the address of that particular user as a recipient.

245 In particular, this means that the system may deliver the content item to an address that was not in the original recipient list, and was not in any group list referenced in the original recipient list. The decision of which content items are delivered to which users (possibly apart from the recipients that the content item author specifies) is made by the system based on its prediction of the interest the potential recipients may have in the content item. This

250 prediction, which may be performed for instance using machine learning, or recommendation algorithms, is informed by, among other possible signals of interest, the user's history of actions in the system (such as which content items the user chooses to delete, fetch, flag, reply to, forward, mark as draft, or archive). Since the recommendation system also attempts to filter out undesired content, and relieves the sender from the burden of specifying all

255 ultimate recipients of the content item, we argue that this approach addresses all three of the drawbacks listed in section "MOTIVATION AND PROBLEM DEFINITION" .

From the point of view of the user, the described system is, in its more general form, a content delivery system in which content items can be sent to the system from either a user of the system or from a user of an external system, content items are transmitted to the 260 user, and content items can be managed by the user: the user may for instance fetch (e.g. using the "FETCH" command and possibly mark as "Seen" using the "STORE" command in the IMAP protocol), delete (e.g. mark for deletion using the "STORE" command and optionally committing the deletion using the "EXPUNGE" or "CLOSE" commands in the IMAP protocol), flag, reply to content items, forward content items, mark content items as

265 drafts, or save content items to an archive, among others. The system gathers information about the user's operations on the content items, and these are treated as implicit signals of interest in the content item. Note that, by requiring no additional effort from the user than was already employed to manage content items, the gathering of so-called implicit ratings can be more convenient to the user, when compared to the requirement or suggestion that

270 the user explicitly rate content items. Note^ however, that we do not limit the described system to so-called implicit signals. As an example, we describe in section "Recommendation system based on email technology" a mechanism by which a system using the Internet Message Access Protocol (IMAP) can make use of special, client-defined message flags to allow users to explicitly rate emails.

275 We note that, for the analysis of the use of the system by a user, several timers may be applied with respect to the handling of content items. We mention here two timers of particular importance. One is related to the time passing from the moment that a user reads or fetches a content item, and a second one is related to the time between the reading or fetching of a content item, and the deleting, or other significant operation on the content

280 item is performed.

Types of content items. We have previously described content items informally as messages of a non-personal nature. More precisely, content items are simply messages in a messaging system (such as email, Instant Messaging, or SMS), and as such may include text messages, uniform resource locations (URLs) or uniform resource identifiers (URIs), as well 285 as files, such as document files, image files, audio files, video files, or media files, such as files for presentations or multimedia animations, as well as data files such as executables files. In practice, however, because in the described system any content item may potentially be delivered to any user, we expect that the type content items shared would be of a non-personal, rather than personal nature.

290 Distinction between fetching a content item by a user, and delivering a content item to a user.

We use the term "deliver a content item" to indicate a system's action consisting of assigning a content item to a user, typically by storing either the content item or a reference to the content item in an area of the system's computer resources (such as memory or disk 295 space) reserved to the user. Delivering a content item to a user is therefore an internal operation of the system, and requires no intervention by any user.

A user fetches a content item by requesting the contents of the item (e.g. in the IMAP protocol via a "FETCH" command [Cri03]). The action of fetching the content item implies that the system transmits, from one of the servers in which it is implemented, the content 300 item to the user (more specifically to the Mail User Agent). Note that, under this definition, a content item can be fetched by a user if the item had previously been delivered to that user.

Distinction between messaging systems in which content items are stored at the client and those in which they are stored at the server. We note that different

305 messaging systems may store the content items corresponding to a user in the system's servers (a typical example is email managed using the IMAP protocol), or in the user's client (an example can be, in some cases, email managed using the POP protocol), or both. Whenever content items are stored in a user's client, and content item management (e.g. deleting a content item) is performed solely in the client, the client must be modified so that

310 it notifies the system's servers of these content item management operations. In this case, the arrow numbered 104 in Figure 1 does not represent the communication between client and system's servers needed for the management of content items, but rather the notification from the client to the system's servers that the user has performed certain content item management operations.

315 Sources of information to the recommendation system. A number of sources of information may be used by the system, in order to inform its recommendations. These include, but are not limited to, the users' settings in the system, how frequently users access the system, for how long they remain connected, the time of day, or the day of the week, or other information regarding the time at which content items may be delivered.

320 Another source of information to the recommendation system may be the number of unread (or perhaps not marked as "Seen") content items associated with a user. The recommendation system may for instance choose to deliver only a limited number of content items to a user that has a sufficiently large number of unseen content items, with the aim to avoid overwhelming the user with too many unseen content items.

325 A source of information to the recommendation system may be whether a user requests (follows) a URL present in a content item. Note that, in order for the system to detect such a URL request, the system has to first replace the actual URL by a URL of the system, with an appropriate encoding of sufficient data to recover the original URL, as well as to identify the user, and possibly which content item the URL was placed in. The goal of such

330 URL replacement is to intercept the request event, and send notification of the request to the recommendation system before redirecting the user to the actual destination URL. Since content items can often contain URLs that point to external content, requesting these URLs may be an indication by the user of interest in the content, and therefore knowledge of the request of such URLs can be useful to the recommendation system.

335 Example of the operation of the system. Consider, as an example of the operation of the system and its functionality, a user A who receives content items from (or possitively- rated by) two other users, B and C, and often deletes those from B, but rarely deletes those from C. The system receives notification of these deletion operations. The system may then use this information to infer that user A may be more interested in receiving content items

340 coming from (or possitively-rated by) C than items coming from (or positively-rated by) B, and adjust accordingly its recommendation subsystem to favor content items authored by (or positively-rated by) C over those authored by (or positively-rated by) B. Note that none of the above content items delivered to A necessarily had to initially include an address of A as a recipient in order for A to receive them, since the system can make delivery decisions,

345 as well as replace or modify a content item's original recipient list.

Relation between recommendation and messaging subsystems. As has already been pointed out, the recommendation system herein described makes use of an underlying messaging technology, and at least a very basic means of content item manipulation, for instance fetching and deleting content items. The recommendation and messaging subsystems

350 can relate in any of a number of ways.

It is possible to implement separate recommendation and communication and content item management systems, which communicate among themselves. In other instances, the two may be closely integrated. For instance, in the case that the underlying messaging technology is email, a specially-implemented email server may perform the tasks of content

355 item delivery, management, and recommendation. Whether the recommendation and messaging subsystems are loosely or tightly integrated, their functionality from the point of view of the user is equivalent.

DESCRIPTION OF DRAWINGS

Figure 1 depicts the general structure of a content recommendation and discovery system 360 based on a messaging technology. The system (105) communicates with the end users (101) via a client, which acts on behalf of the user (102). The client may send content items to the system (103), and it may receive and manage content items by communicating with the system (104). In some cases in which content items are managed locally by a client on behalf of the user, the client may send notification of the management signals to the system. 365 Figure 2 depicts an embodiment of the system using email technology, and more in particular using the Simple Mail Transfer Protocol (SMTP), and the Internet Message Access Protocol (IMAP). The system (205) communicates with the end users (201) via a client, or Mail User Agent (MUA), which acts on behalf of the user (202). The client may send messages to the system using the SMTP protocol (203), and it may receive and 370 manage content items by communicating with the system using the IMAP protocol (204). Figure 3 depicts a more detailed diagram of the information flow in the invention. When compared to figure 1, the box labelled 305: "Content recommendation and discovery system" has been broken down into two parts, labelled: 306 "Messaging system" , and 307 "Recommendation engine" . The messaging system sends implicit signals (such as user's actions

375 as part of their message management, such as fetching or deleting messages) and possibly explicit signals (such as user's flagging of messages using client-defined rating attributes) to the recommendation engine (308) . The recommendation engine sends addresses of recipients of content items (309), and in turn the messaging system delivers the specified content items to the specified addresses. Note that the recommendation engine may receive further

380 information from the messaging system, such as which content items have been received by which users; so as to avoid producing duplicate deliveries of content items to users.

Finally, note that the distinction between the messaging system, and the recommendation engine, as part of the Content Recommendation and Discovery System is presented as such only as an example, and the Content Recommendation and Discovery System may

385 be implemented in any number of ways, including a tightly-coupled system in which communication occurs internally, or a more loosely-coupled system in which communication occurs across threads, system processes, servers, or even servers residing in separate networks.

BEST MODES FOR CARRYING OUT THE INVENTION

The examples and described embodiments are not limiting, but merely illustrative. It should 390 be noted that the described embodiments may be combined in any way, i.e. the embodiments described in this document are not mutually exclusive, and features described in connection with a certain embodiment may be combined with features described in connection with another embodiment. The best mode for carrying out the invention is the one described in the section below ("Recommendation system based on email technology").

395 Recommendation system based on email technology. Email is a communication technology that has been in wide use for several decades, and relies on well-stablished standard protocols of communication, such as SMTP, POP, POP3, and IMAP. The role of an email messaging system is to receive, transmit, and manage messages. Crucially, a message contains a list of one or more intended recipients, and part of the task of the

400 messaging system is to attempt delivery of the message to its intended recipients, as specified in the message's recipient list.

The recommendation system described in this document can be implemented using email communication technology as its underlying messaging technology. We describe here an implementation that uses SMTP and IMAP as communication protocols between user and

405 system. We make reference to Figure 2. In this case, an end-user (201) makes use of a client, which is also referred to as a Mail User Agent (MUA) (202). The MUA communicates with the system on behalf of the user. The MUA may send messages to the system (205) through the Simple Mail Transfer Protocol (SMTP) (203). The SMTP protocol requires that these messages have an associated recipient list. The MUA receives and manages messages through

410 the Internet Message Access Protocol (IMAP) (204). Note that the user may be a person or a computer, but this may be unknown to the messaging and recommendation system, which interacts with users only through the MUA.

The MUA may request messages delivered to the user to be fetched on behalf of the user, and these fetching operations may change the Seen flag of a message. The user may

415 execute management operations on the messages, such as fetching (and possibly marking the message as "Seen"), flagging, replying, forwarding, deleting messages, or marking messages as drafts. Each of these operations have corresponding IMAP commands which the MUA sends to the messaging subsystem. The system then executes these operations, and keeps note of them for use in its recommendation subsystem.

420 The IMAP protocol has a number of features for managing messages that may be useful to the recommendation system. The recommendation system can keep track of these operations, as requested by the MUA, and incorporate this information to its computations in order to perform its task. Among these features may be the following:

• Messages may have internal flags (so-called system flags [Cri03]) which can be set, 425 cleared, or fetched, and may include the following: Seen (the message has been read),

Answered (the message has been answered), Flagged (the message is "flagged" for urgent or special attention), Deleted (the message is marked for later removal), Draft (the message is not in its final state, but is saved for possible later editing). The "Flagged" flag is commonly depicted in clients (MUAs) as a flag icon or a star icon, 430 and the flag itself is sometimes referred to as "Starred" .

• Messages may have user or client-defined internal flags. The IMAP protocol supports the definition of new message flags other than the ones listed above (servers supporting new message flags advertise this fact to clients by sending "\*" in a "PER- MANENTFLAGS" response [Cri03]). Manipulation of these flags may be used as

435 signals by the recommendation system. As an example, a client may define and use a

"positively-rated" flag. The client may provide a special button to mark any message as "positively-rated" , effectively providing the user with a means to explicitly rate messages.

• Messages may be copied to, moved to, or erased from a number of folders. Certain 440 folders have special designations in the IMAP protocol using the "Special-Use Mailboxes" extension [LN11]. For instance, the specially designated mailboxes may include those tagged in [LN11] as: All (typically a virtual mailbox including all messages, perhaps excluding those in Trash or Spam folders), Archive (for archiving messages), Drafts (typically used to store or list messages marked as Draf ), Flagged (typically 445 used to store or list messages marked as Flagged), Junk (typically used to store or list undesired or unsolicited messages, or those filtered by a spam filter), Sent (typically used to store or list sent messages) , Trash (typically used to store or list messages that have been deleted or marked for deletion).

Example recommendation subsystem.

450 Consider the following, extremely simplified example implementation of a recommendation subsystem, and example use case. The recommendation subsystem simply receives information on user's actions in the system, and recommends content items to users.

Let A, B, and C be users of the system, using separate clients on behalf of each. The users may be physical persons or computers programs, but this makes no difference to the

455 system, since it only communicates directly with the clients. Whenever we speak of a user executing an operation, it is understood that it's the user's client (MUA) that communicates with the system in order to execute the operation.

We will consider how the system can make a decision on which content items to deliver to a specific user A, with the understanding that a similar mechanism will be employed

460 to make delivery decisions for all other users. Let NB _→ A be the total number of content items authored by B that have been delivered so far to A. Similarly, let N _C →A be the total number of content items authored by C that have been delivered so far to A. Let DB→A be the total number of content items authored by B that A has fetched and deleted, and let Dc _→ A be the total number of content items authored by C that A has fetched and deleted.

465 In this example, the system estimates the interest that A has in receiving a content item from B to be

P _B →A = (N _B→A + 1 - D _B→A )/(N _B→A + 1),

and similarly for C. This number is always between 0 and 1, with 0 representing no interest, and 1 representing high interest.

Given the arrival of a content item authored by B, the system chooses to deliver this 470 content item to A with probability P _B →A- This probability of delivery will be low when the system estimates that A is not very interested in receiving content items from B, and high when it estimates that A is very interested in receiving content items from B.

Consider now the following sequence of events. User B begins by sending a content item MB1 to the system, and user C then sends content item MCI to the system. Since at first it 475 is NB→A = 0, Nc _→A = 0, and D _B→ A = 0, DC _→ A ⁼ 0) the initial system estimates of interest for A are P _B → _A = (0 + 1 - 0)/(0 + 1) = 1 and P _C→A = (0 + 1 - 0)/(0 + 1) = 1, and therefore the system estimates that A is very interested in receiving content items from both B and C. Due to the high estimated interest, content items MB1 and MCI are delivered to A.

Later on, A connects to the system and fetches content items MB1 and MCI. A reads 480 both content items and deletes MBl. The system updates its internal counts to N _B→A = 1 _> N _→A — 1 ₎ and D _B -*A = 1 _> D _C -> _A = 0 (A received so far one content item from B and one from C, and deleted one content item from B and none from C), which leads to new estimates of interest P _B →A = (1 + 1 - 1)/(1 + 1) = 0.5 and P _C→A = (1 + 1 - 0)/(l + 1) = 1. Effectively, the system has noticed that A deleted the content item authored by B but not

485 the one authored by C, and adjusted its estimates of interests accordingly, favoring content items authored by C over those authored by B.

As a consequence of A's behavior, future content items considered for delivery to A will be treated differently depending on whether they are authored by B or C. Content items from B will only be delivered to A with probability P _B → _A — 0.5 (on average only 50% of

490 them will be delivered to A), while all content items from C will be delivered to A.

As the users continue to use the system, the system will have more information on which to base its estimates of interest, and consequently to inform its delivery decisions.

Recommendation system based on Short Message Service and Multimedia Message Service technology. Both Short Message Service (SMS) and Multimedia Message

495 Service (MMS) technology provide means for communication between mobile devices that is not based on voice, including sending text, images, and or audio or video files. While SMS and MMS technologies focus on the specification of recipients and delivery of messages, clients typically store the received messages and allow users to delete messages. As described above, this ability to receive, view, and delete messages is sufficient to implement a recom-

500 mendation system that is based on an underlying message communication technology such as SMS or MMS. For example, the recommendation system can use the recommendation method described in the above section entitled "Recommendation system based on email technology" , in combination with signals obtained as a side-effect of the users' management of messages (such as viewing, and deleting messages).

505 Note that, while email services based on the IMAP protocol typically store messages in the server and allow users to manage messages by use of the IMAP protocol, SMS and MMS services typically rely on the client to store and manage messages. Whenever a MMS user deletes a message, the deletion typically happens in the user's mobile client. This means that interest signals to be used in the recommendation system may need to be sent from

510 the mobile client to the recommendation system, whenever this system is external to the mobile client, as would typically be the case.

REFERENCES AND CLAIMS

All references cited herein are incorporated herein by reference in their entirety and for all purposes to the same extent as if each individual publication or patent or patent application 515 was specifically and individually indicated to be incorporated by reference in its entirety for all purposes.

Many modifications and variations of this invention can be made without departing from its spirit and scope, as will be apparent to those skilled in the art. The specific embodiments described herein are offered by way of example only, and the invention is to be limited only 520 by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled.

References

[CKMZ14] W.K. Carrigan, R.P. Konik, T.J. Massaro, and A.J. Ziolkowski. Determining recommended recipients of a communication, March 6 2014. US Patent App.

525 13/605,454.

[Cri03] M. Crispin. Internet message access protocol - version 4revl. RFC 3501, RFC

Editor, March 2003.

[EKH+14] J. Eggink, T. Kemp, W. Hagg, T. Zimmer, and T. Feduszczak. Method for content recommendation, April 1 2014. US Patent 8,688,699.

[FGM+99] Roy T. Fielding, James Gettys, Jeffrey C. Mogul, Henrik Frystyk Nielsen, Larry

Masinter, Paul J. Leach, and Tim Berners-Lee. Hypertext transfer protocol - http/1.1. RFC 2616, RFC Editor, June 1999.

[Gro08] J.N. Gross. Document distribution recommender system and method, August

2008. US Patent 7,996,456.

[HTF09] T. Hastie, R. Tibshirani, and J. Friedman. The Elements of Statistical Learning:

Data Mining, Inference, and Prediction, Second Edition. Springer Series in Statistics. Springer New York, 2009.

[KleOl] J. Klensin. Simple mail transfer protocol. RFC 2821, RFC Editor, April 2001. [Kro89] E. Krol. Hitchhikers guide to the Internet. RFC 1118 (Informational), September

540 1989.

[KSG14] K. Kurapati, J.D. Schaffer, and S. Gutta. Method and apparatus for generating recommendation scores using implicit and explicit viewing preferences, September 23 2014. US Patent 8,843,965.

[LN11] M. Leiba and J. Nicolson. IMAP LIST Extension for Special-Use Mailboxes.

545 RFC 6154 (Proposed Standard), March 2011.

[MR96] John G. Myers and Marshall T. Rose. Post office protocol - version 3. STD 53,

RFC Editor, May 1996. [PIE16] DAVID PIERCE. What you need to know about twitter's algorithmic timeline, February 2016. https://www.wired.com/2016/02/what-you-need-to-know-about- 550 twitters-algorithmnic-timeline / .

[Purll] Kristen Purcell. Search and email still top the list of most popular online activities. August 2011. http://www.pewinternet.org/files/old- media/Files/Reports/2011/PIP JSearch-and-Email.pdf.

[Radl5] RadiumOne. The dark side of mobile sharing, 2015. https://radiumone.com/wp- 555 content /uploads/2016 / 08 /radiumone-the-dark-side-of-mobile-sharing- June- 7-

2016.pdf.

[RRSK10] Francesco Ricci, Lior Rokach, Bracha Shapira, and Paul B. Kantor. Recommender

Systems Handbook. Springer- Verlag New York, Inc., New York, NY, USA, 1st edition, 2010.

560 [Ruml4] Mobile content engagement study, March 2014. http://rumble.me/doc/Rumble- ContentStudy.pdf.

[SCBLll] G. Smith, G. Camp, E. Boyd, and J. LaPrance. Method and system for single- action personalized recommendation and display of internet content, December 13 2011. US Patent 8,078,615.

565 [SDHH98] Mehran Sahami, Susan Dumais, David Heckerman, and Eric Horvitz. A bayesian approach to filtering junk E-mail. In Learning for Text Categorization: Papers from the 1998 Workshop, Madison, Wisconsin, 1998. AAAI Technical Report WS-98-05.

[SFHS07] J. Ben Schafer, Dan Prankowski, Jon Herlocker, and Shilad Sen. The adaptive 570 web. chapter Collaborative Filtering Recommender Systems, pages 291-324.

Springer- Verlag, Berlin, Heidelberg, 2007.

[SG09] T. Schigel and D.E. Goldberg. Systems and methods for content sharing,

September 2009. US Patent App. 12/048,789.