個性化提醒的制作方法
背景技術：
在人們意識到事件時，有時人們不方便對通信或提示(諸如呼叫、電子郵件、文本、通知或其他提醒)做出響應。例如，用戶可能在用戶不方便回電話時接收到未接來電的通知，但在這樣做時消除了該通知。稍后方便時，用戶不記得要做出響應，因為通知被消除了。此外，因為一些錯過的通信事件比其他事件更為緊急，所以即使當不那么方便做出響應時，但由于其重要性，用戶可能期望更早地被提醒關于這些錯過的事件。對于與某些聯(lián)系人或其他實體相關聯(lián)的錯過的事件來說，情況尤其如此，該其他實體基于對這些實體的典型的用戶響應模式而被確定為是更重要的。
技術實現(xiàn)要素：
提供本發(fā)明內(nèi)容，以便以簡化的形式介紹精選的概念，在下文的詳細描述中進一步描述這些概念。本發(fā)明內(nèi)容不旨在標識所要求保護的主題的關鍵特征或基本特征，也不旨在孤立地用作確定所要求保護的主題的范圍的輔助。
本發(fā)明的實施例涉及一種用于向用戶提供關于與用戶相關聯(lián)的事件的個性化通知內(nèi)容的系統(tǒng)和方法。特別地，實施例可以確定被用戶錯過的或以其他方式未被用戶處理的事件(諸如，通信事件、任務或者與用戶相關的新聞事件或社交媒體事件)；例如，來自用戶的老板的用戶尚未回復的電子郵件，或者，基于用戶通常何時或在何地呼叫其母親的所確定的用戶模式的、未發(fā)生的用戶發(fā)起的對其母親的呼叫?？梢源_定基于未處理事件的通知內(nèi)容。通知內(nèi)容可以包括在被確定為用戶有可能更方便處理或響應于未處理事件的未來時間和/或在用戶可能具有適當?shù)胤磻蝽憫哪芰Φ那闆r下向用戶呈現(xiàn)通知的建議，并且在一些情況下可以包括提供與協(xié)助用戶處理事件相關的附加內(nèi)容。此外，在一些情況下，由通知內(nèi)容指定的通知格式(即，(一個或多個)通知可以如何被提供給用戶)和通知呈現(xiàn)的定時可以基于與未處理事件相關聯(lián)的上下文信息，包括例如重要性或緊急性。
因此，本公開的方面涉及為未處理事件定制的服務內(nèi)容。術語“事件”在本文中廣泛地用于包括通信事件，其指代由與用戶相關聯(lián)的計算設備接收或發(fā)起的幾乎任何通信，包括嘗試通信(例如，未接來電)、意圖用于用戶的通信、代表用戶發(fā)起的通信或者可用于用戶的通信。術語“事件”還可以指代提醒、任務、公告或新聞項(包括諸如本地或區(qū)域新聞之類的與用戶相關的新聞、天氣、交通或社交網(wǎng)絡/社交媒體信息)?！拔刺幚硎录笨梢灾复脩羯形错憫⑻幹没蛞云渌绞教幚淼耐ㄐ攀录蚱渌录?，諸如錯過的或未發(fā)起的呼叫、未響應的電子郵件、未確認的通知或提醒、未處理的任務、未處理的請求、未處理的社交媒體項(例如，標簽、推文、新聞推送帖子或與用戶相關的類似事件)等。通過標識未處理事件，可以基于未處理事件的上下文和用戶行為來向用戶提供諸如服務內(nèi)容之類的內(nèi)容，以便針對用戶定制或個性化內(nèi)容。
如將進一步描述的，在一個實施例中，用戶數(shù)據(jù)從一個或多個數(shù)據(jù)源來接收。諸如本文中所描述的，用戶數(shù)據(jù)可以通過利用與用戶相關聯(lián)的(一個或多個)用戶設備上的一個或多個傳感器或部件收集用戶數(shù)據(jù)來接收。事件以及對那些事件的用戶響應可以通過監(jiān)測用戶數(shù)據(jù)來確定，并且由此可以確定事件模式并檢測未處理事件。關于未處理事件的上下文信息還可以從用戶數(shù)據(jù)或從其確定的模式來確定，并且可以用于確定與未處理事件相關聯(lián)的重要性級別或緊急性級別。另外，用于最佳地處理事件的用戶可用性可以基于所確定的用戶模式和/或用戶數(shù)據(jù)來預測，用戶數(shù)據(jù)從與用戶相關聯(lián)的一個或多個用戶設備(諸如，智能電話)以及在某些情況下從與其他用戶相關聯(lián)的設備來感測或以其他方式收集。
通知內(nèi)容可以基于所預測的可用性、未處理事件的所確定的可能的重要性或其他上下文信息來生成，并且還可以包括用于協(xié)助用戶處理未處理事件的補充內(nèi)容。一些實施例還包括使用來自其他用戶的用戶數(shù)據(jù)(諸如，眾包數(shù)據(jù))，以用于確定對類似類型的事件的典型用戶響應模式、通知邏輯和/或相關補充內(nèi)容。
以這種方式，本發(fā)明的實施例可以提供基于上下文、用戶對通知的響應以及具有充分地處理該事件的能力的可能性而針對用戶個性化的通知內(nèi)容，使得用戶更易于以及時且方便的方式來處置事件。
附圖說明
以下參考附圖來詳細描述本發(fā)明的方面，在附圖中：
圖1是適合于實現(xiàn)本發(fā)明的方面的示例操作環(huán)境的框圖；
圖2是描繪適合于實現(xiàn)本發(fā)明的方面的示例計算架構(gòu)的示圖；
圖3描繪了根據(jù)本發(fā)明的實施例的可以呈現(xiàn)給用戶的通知內(nèi)容的一個示例；
圖4-圖6描繪了根據(jù)本發(fā)明的實施例的用于向用戶提供個性化通知內(nèi)容的方法的流程圖；以及
圖7是適合于用于實現(xiàn)本發(fā)明的實施例的示例性計算環(huán)境的框圖。
具體實施方式
在本文中具體描述了本發(fā)明的方面的主題以滿足法定要求。然而，描述本身并不旨在限制本專利的范圍。相反，發(fā)明人已經(jīng)考慮到，所要求保護的主題也可以以其他方式來實施，以包括結(jié)合其他現(xiàn)有或未來技術的、與本文檔中所描述的步驟不同的步驟或類似的步驟的組合。此外，雖然術語“步驟”和/或“框”在本文中可以用于包含所采用的方法的不同元素，但是術語不應當被解釋為意指本文中所公開的各種步驟之間的任何特定順序，除非和除了當各個步驟的順序被明確地描述時。
本文中所描述的技術的方面涉及用于除其他之外向用戶提供與事件有關的個性化通知內(nèi)容的系統(tǒng)、方法和計算機存儲介質(zhì)。特別地，實施例可以確定被用戶錯過或以其他方式未被用戶處理的事件，諸如確定來自用戶的老板的用戶尚未回復的電子郵件，或者，基于用戶通常何時或在何地呼叫其母親的所確定的用戶模式、未發(fā)生的用戶發(fā)起的對其母親的呼叫?？梢源_定基于未處理事件的通知內(nèi)容。通知內(nèi)容可以包括在被確定為用戶有可能更方便響應于未處理事件的未來時間和/或在用戶可能具有適當?shù)仨憫哪芰Φ那闆r下向用戶呈現(xiàn)通知的建議，并且在一些情況可以包括提供與協(xié)助用戶處理事件相關的附加內(nèi)容。此外，通知內(nèi)容的格式(即，其可以如何被提供給用戶)和通知呈現(xiàn)的定時可以基于與未處理事件相關聯(lián)的重要性或上下文。例如，可以在用戶完成工作離開辦公室之后下一次拿起其電話時提醒用戶呼叫其母親，同時，若當老板的郵件被接收時同一用戶正在參加會議，可以在會議之后經(jīng)由呈現(xiàn)在其智能電話上的視覺通知來提醒同一用戶響應其老板的電子郵件。
在某些方面，本公開的方面涉及為未處理事件定制的服務內(nèi)容。術語“事件”在本文中廣泛地用于包括通信事件，其指代由與用戶相關聯(lián)的計算設備接收或發(fā)起的幾乎任何通信，包括未遂的通信(例如，未接來電)、意圖用于用戶的通信、代表用戶發(fā)起的通信或者可用于用戶的通信。術語“事件”還可以指代提醒、任務、公告或新聞項(包括諸如本地或區(qū)域新聞之類的與用戶相關的新聞、天氣、交通或社交網(wǎng)絡/社交媒體信息)。因此，作為示例而非限制，事件可以包括：語音/視頻呼叫，電子郵件，sms文本消息，即時消息，通知，社交媒體或社交網(wǎng)絡新聞項或通信(例如，推文、facebook帖子或“喜歡”、邀請、新聞推送項)，與用戶相關的新聞項，用戶可能處理或響應的任務，rss推送項，網(wǎng)站和/或博客帖子、評論或更新，日歷事件、提醒或通知，會議請求或邀請，包括游戲通知和消息(包括來自其他玩家的通知和消息)的應用內(nèi)通信等。一些通信事件可以與實體(諸如，聯(lián)系人或商家，在一些情況下包括用戶本身)或與一類實體(諸如，親密的朋友、工作同事、老板、家庭、由用戶拜訪的企業(yè)機構(gòu)等)相關聯(lián)。“未處理事件”可以指代用戶尚未響應、處置或以其他方式處理的通信事件或其他事件，諸如錯過的或未發(fā)起的呼叫、未響應的電子郵件、未確認的通知或提醒、未處理的任務、未處理的請求、未處理的社交媒體項(例如，標簽、推文、新聞推送帖子或與用戶相關的類似事件)等。例如，未處理事件可以對應于與處理事件相關聯(lián)的一個或多個用戶響應或活動，諸如：完成或回電話，完成任務；起草電子郵件，確認新的項目通知或社交媒體帖子；安排約會，或購買周年紀念禮物。通過標識未處理事件，可以基于未處理事件的上下文和用戶行為來向用戶提供諸如服務內(nèi)容之類的內(nèi)容，以便針對用戶定制或個性化內(nèi)容。
因此，在高級別處，在一個實施例中，用戶數(shù)據(jù)從一個或多個數(shù)據(jù)源來接收。諸如本文中所描述的，用戶數(shù)據(jù)可以通過利用與用戶相關聯(lián)的(一個或多個)用戶設備上的一個或多個傳感器收集用戶數(shù)據(jù)來接收。結(jié)合圖2的部件214所進一步描述的用戶數(shù)據(jù)的示例可以包括：用戶的(一個或多個)移動設備的位置信息，用戶活動信息(例如，應用使用、在線活動、搜索、呼叫)，應用數(shù)據(jù)，聯(lián)系人數(shù)據(jù)，日歷和社交網(wǎng)絡數(shù)據(jù)，或者可以由用戶設備或其他計算設備感測或確定的用戶數(shù)據(jù)的幾乎任何其他來源。
事件及對那些事件的用戶響應可以通過監(jiān)測用戶數(shù)據(jù)來確定，并且由此可以確定事件模式并且檢測未處理事件。在一些情況下，未處理事件可以基于與事件的確定模式的偏差來檢測，諸如在用戶每個星期日呼叫他的祖母但是在幾周中沒有呼叫她的情況下。關于未處理事件的上下文信息也可以從用戶數(shù)據(jù)或從其確定的模式來確定，并且可以用于確定與未處理事件相關聯(lián)的重要性級別或緊急性級別。在一些實施例中，上下文信息也可以從其他用戶的用戶數(shù)據(jù)(即，眾包數(shù)據(jù))來確定。在這樣的實施例中，數(shù)據(jù)可以以保護其他用戶的隱私的方式來去標識或以其他方式來使用。
另外，用戶處置用于處理未處理事件的某些類型的活動(例如，撥打電話、響應于電子郵件、瀏覽web等)的可用性和/或能力級別可以基于所確定的用戶模式和/或用戶數(shù)據(jù)來預測，所述用戶數(shù)據(jù)從與用戶相關聯(lián)的一個或多個用戶設備(諸如，智能電話)以及在某些情況下從與其他用戶相關聯(lián)的設備來感測。例如，諸如位置、時間、在線活動、(一個或多個)日歷或任何數(shù)目的其他用戶數(shù)據(jù)之類的用戶數(shù)據(jù)可以被收集，并用于確定針對與處理事件有關的不同類型的活動的用戶可用性模式、該用戶通常如何響應于某些事件以及其他用戶通常如何響應。
通知內(nèi)容可以基于所預測的可用性和未處理事件的所確定的可能的重要性(以及在一些情況下，其他的上下文信息)來生成，通知內(nèi)容在某些情況下包括用于呈現(xiàn)通知的通知邏輯。通知邏輯可以指定用于通知用戶未處理事件的條件和/或時間，以及(一個或多個)通知的格式。通知內(nèi)容還可以包括用于協(xié)助用戶處理未處理事件的補充內(nèi)容。例如，如果未處理事件是您的周年紀念日，那么補充信息可以包括關于她最喜歡的餐廳的信息及用于在餐廳進行晚餐預訂的建議。如此，本發(fā)明的實施例可以提供如下的通知內(nèi)容：該通知內(nèi)容基于上下文、用戶對通知的響應以及具有足夠地處理事件的能力的可能性而針對用戶被個性化，使得用戶更易于以及時且方便的方式來處置事件。
本發(fā)明的一些實施例還包括使用來自其他用戶的用戶數(shù)據(jù)(即，眾包數(shù)據(jù))，以用于確定對類似類型的事件的典型用戶響應模式、通知邏輯和/或相關補充內(nèi)容。另外，本發(fā)明的一些實施例可以由個人助理應用或服務來執(zhí)行，如本文中進一步描述的，個人助理應用或服務可以被實現(xiàn)為一個或多個計算機應用、服務或例程，諸如在移動設備或云上運行的應用程序。
現(xiàn)在轉(zhuǎn)到圖1，提供了示出其中可以采用本公開的一些實施例的示例操作環(huán)境100的框圖。應當理解，本文中所描述的這種和其他布置僅作為示例來闡述。除了或代替所示出的那些布置和元件，可以使用其他布置和元件(例如，機器、接口、功能、命令和功能分組等)，并且為了清楚起見，可以干脆省略一些元件。此外，本文中所描述的元件中的許多元件是功能實體，該功能實體可以被實現(xiàn)為離散或分布式部件或者與其他部件結(jié)合，并且可以以任何合適的組合且在任何合適的位置中實現(xiàn)。本文中被描述為由一個或多個實體執(zhí)行的各種功能可以由硬件、固件和/或軟件來執(zhí)行。例如，一些功能可以由執(zhí)行存儲器中所存儲的指令的處理器來實施。
除了未示出的部件，示例操作環(huán)境100包括：多個用戶設備，諸如用戶設備102a和102b至102n；多個數(shù)據(jù)源，諸如數(shù)據(jù)源104a和104b至104n；服務器106；以及網(wǎng)絡110。應當理解，圖1所示的環(huán)境100是一個合適的操作環(huán)境的一個示例。例如，圖1所示的部件中的每個部件可以經(jīng)由任何類型的計算設備來實現(xiàn)，任何類型的計算設備諸如結(jié)合圖7所描述的計算設備700。這些部件可以經(jīng)由網(wǎng)絡110彼此通信，網(wǎng)絡110可以包括但不限于一個或多個局域網(wǎng)(lan)和/或廣域網(wǎng)(wan)。在示例性實現(xiàn)方式中，在各種可能的公共和/或?qū)Ｓ镁W(wǎng)絡中的任何網(wǎng)絡中，網(wǎng)絡110包括因特網(wǎng)和/或蜂窩網(wǎng)絡。
應當理解，在本公開的范圍內(nèi)，可以在操作環(huán)境100內(nèi)采用任何數(shù)目的用戶設備、服務器和數(shù)據(jù)源。每一個可以包括在分布式環(huán)境中協(xié)作的單個設備或多個設備。例如，服務器106可以經(jīng)由布置在分布式環(huán)境中的多個設備來提供，該多個設備共同提供本文中所描述的功能。此外，未示出的其他部件也可以被包括在分布式環(huán)境中。
用戶設備102a和102b至102n可以是在操作環(huán)境100的客戶端上的客戶端設備，而服務器106可以在操作環(huán)境100的服務器端上。服務器106可以包括被設計為與用戶設備102a和102b至102n上的客戶端軟件結(jié)合工作的服務器端軟件，以便實現(xiàn)本公開中討論的特征和功能的任何組合。提供操作環(huán)境100的這種劃分，以說明合適的環(huán)境的一個示例，并且對于每個實現(xiàn)方式不要求服務器106和用戶設備102a和102b至102n的任何組合保持為單獨的實體。
用戶設備102a和102b至102n可以包括能夠由用戶使用的任何類型的計算設備。例如，在一個實施例中，用戶設備102a至102n可以是本文中關于圖7所描述的計算設備的類型。作為示例而非限制，用戶設備可以被實施為個人計算機(pc)、膝上型計算機、移動裝置或移動設備、智能電話、平板計算機、智能手表、可穿戴計算機、個人數(shù)字助理(pda)、mp3播放器、全球定位系統(tǒng)(gps)或設備、視頻播放器、手持通信設備、游戲設備或系統(tǒng)、娛樂系統(tǒng)、車載計算機系統(tǒng)、嵌入式系統(tǒng)控制器、遙控器、家電、消費電子設備、工作站、或這些所描繪的設備的任何組合或任何其他合適的設備。
數(shù)據(jù)源104a和104b至104n可以包括如下的數(shù)據(jù)源和/或數(shù)據(jù)系統(tǒng)：該數(shù)據(jù)源和/或數(shù)據(jù)系統(tǒng)被配置為使數(shù)據(jù)可用于結(jié)合圖2所描述的操作環(huán)境100或系統(tǒng)200的各種組成中的任何組成。(例如，在一個實施例中，一個或多個數(shù)據(jù)源104a至104n向圖2的用戶數(shù)據(jù)收集部件214提供(或使用戶數(shù)據(jù)收集部件214可用于訪問)用戶數(shù)據(jù))。數(shù)據(jù)源104a和104b至104n可以與用戶設備102a和102b至102n及服務器106是離散的，或者可以被并入和/或集成到這些部件中的至少一個部件中。在一個實施例中，數(shù)據(jù)源104a至104n中的一個或多個包括一個或多個傳感器，一個或多個傳感器可以被集成到(一個或多個)用戶設備102a、102b或102n或者服務器106中的一個或多個中，或者與(一個或多個)用戶設備102a、102b或102n或者服務器106中的一個或多個相關聯(lián)。進一步結(jié)合圖2的用戶數(shù)據(jù)收集部件214來描述通過數(shù)據(jù)源104a至104n而實現(xiàn)可用的所感測的用戶數(shù)據(jù)的示例。
操作環(huán)境100可以用于實現(xiàn)圖2中所描述的系統(tǒng)200的部件中的一個或多個部件，包括用于收集用戶數(shù)據(jù)、監(jiān)測事件、生成通知內(nèi)容和/或向用戶呈現(xiàn)通知及相關內(nèi)容的部件。現(xiàn)在參考圖2，與圖1一樣，提供了框圖，該框圖示出適合于實現(xiàn)本發(fā)明的實施例并且總體上被指定為系統(tǒng)200的示例計算系統(tǒng)架構(gòu)的方面。系統(tǒng)200僅表示合適的計算系統(tǒng)架構(gòu)的一個示例。除了或代替所示出的那些布置和元件，可以使用其他布置和元件，并且為了清楚起見，可以干脆省略一些元件。此外，與操作環(huán)境100一樣，本文中所描述的元件中的許多元件是功能實體，該功能實體可以被實現(xiàn)為離散或分布式部件或者與其他部件結(jié)合，并且可以以任何合適的組合且在任何合適的位置中實現(xiàn)。
示例系統(tǒng)200包括結(jié)合圖1所描述的網(wǎng)絡110，并且網(wǎng)絡110通信地耦合系統(tǒng)200的部件，包括用戶數(shù)據(jù)收集部件214、事件監(jiān)測器280、通知引擎260、呈現(xiàn)部件218和存儲裝置225。事件監(jiān)測器280(包括其部件282、284、286和288)、通知引擎260(包括其部件262、264、266和268)、用戶數(shù)據(jù)收集部件214和呈現(xiàn)部件218可以被實施為例如在一個或多個計算機系統(tǒng)(諸如結(jié)合圖7描述的計算設備700)上執(zhí)行的編譯的計算機指令或函數(shù)集、程序模塊、計算機軟件服務、或者過程的布置。
在一個實施例中，由系統(tǒng)200的部件執(zhí)行的功能與一個或多個個人助理應用、服務或例程相關聯(lián)。特別地，這樣的應用、服務或例程可以在一個或多個用戶設備(諸如，用戶設備104a)、服務器(諸如，服務器106)上操作，可以跨一個或多個用戶設備和服務器分布，或者在云中實現(xiàn)。此外，在一些實施例中，系統(tǒng)200的這些部件可以跨云中的網(wǎng)絡分布，所述網(wǎng)絡包括一個或多個服務器(諸如，服務器106)和客戶端設備(諸如，用戶設備102a)，或者系統(tǒng)200的這些部件可以駐留在諸如用戶設備102a的用戶設備上。此外，這些部件、由這些部件執(zhí)行的功能、或者由這些部件執(zhí)行的服務可以在適當?shù)?一個或多個)抽象層處實現(xiàn)，適當?shù)?一個或多個)抽象層諸如(一個或多個)計算系統(tǒng)的操作系統(tǒng)層、應用層、硬件層等。備選地或另外地，本文中所描述的這些部件和/或本發(fā)明的實施例的功能可以至少部分地由一個或多個硬件邏輯部件來執(zhí)行。例如而非限制，可以使用的、說明性類型的硬件邏輯部件包括現(xiàn)場可編程門陣列(fpga)、專用集成電路(asic)、專用標準產(chǎn)品(assp)、系統(tǒng)級芯片系統(tǒng)(soc)、復雜可編程邏輯器件(cpld)等。另外，雖然在本文中關于示例系統(tǒng)200中所示的具體部件來描述功能，但預期的是，在一些實施例中，這些部件的功能可以跨其他部件共享或分布。
繼續(xù)圖2，用戶數(shù)據(jù)收集部件214通常負責從一個或多個數(shù)據(jù)源訪問或接收(并且在一些情況下也標識)用戶數(shù)據(jù)，一個或多個數(shù)據(jù)源諸如圖1的數(shù)據(jù)源104a和104b至104n。在一些實施例中，用戶數(shù)據(jù)收集部件214可以用于支持一個或多個用戶的用戶數(shù)據(jù)(包括眾包數(shù)據(jù))針對事件監(jiān)測器280和通知引擎260的累積。數(shù)據(jù)可以由數(shù)據(jù)收集部件214接收(或訪問)，并且可選地被累積、被重新格式化和/或被組合，并且被存儲在諸如存儲裝置225的一個或多個數(shù)據(jù)存儲庫中，在該處數(shù)據(jù)對事件監(jiān)測器280和通知引擎260來說可以是可用的。例如，如本文中所描述的，用戶數(shù)據(jù)可以存儲在用戶簡檔240中或與用戶簡檔240相關聯(lián)。
可以從各種源接收用戶數(shù)據(jù)，在所述各種源中數(shù)據(jù)可以以各種格式可用。例如，在一些實施例中，經(jīng)由用戶數(shù)據(jù)收集部件214接收的用戶數(shù)據(jù)可以經(jīng)由一個或多個傳感器來確定，一個或多個傳感器可以在以下項上或者與以下項相關聯(lián)：一個或多個用戶設備(諸如，用戶設備102a)、服務器(諸如，服務器106)和/或其他計算設備。如本文中所使用的，傳感器可以包括用于感測、檢測或以其他方式從數(shù)據(jù)源104a獲取諸如用戶數(shù)據(jù)之類的信息的函數(shù)、例程、部件或其組合，并且可以被實施為硬件、軟件或兩者。作為示例而非限制，用戶數(shù)據(jù)可以包括：從一個或多個傳感器感測或確定的數(shù)據(jù)(在本文中被稱為傳感器數(shù)據(jù))，諸如(一個或多個)移動設備的位置信息；智能電話數(shù)據(jù)(諸如，從智能電話獲得的電話狀態(tài)、計費數(shù)據(jù)、日期/時間或其他信息)；用戶活動信息(例如：應用程序使用；在線活動；搜索；諸如自動語音識別的語音數(shù)據(jù)；活動日志；通信數(shù)據(jù)，包括呼叫、文本、即時消息和電子郵件；網(wǎng)站帖子；與事件相關聯(lián)的其他用戶數(shù)據(jù)等)，包括在多于一個用戶設備上發(fā)生的用戶活動；用戶歷史；對話日志；應用數(shù)據(jù)；聯(lián)系人數(shù)據(jù)；日歷和日程表數(shù)據(jù)；通知數(shù)據(jù)；社交網(wǎng)絡數(shù)據(jù)；新聞(包括搜索引擎或社交網(wǎng)絡上的流行或熱門項)；在線游戲數(shù)據(jù)；電子商務活動(包括來自諸如amazon.
事件監(jiān)測器280通常負責監(jiān)測事件和相關信息，以便確定與事件相關聯(lián)的事件模式、事件響應信息、未處理事件和上下文信息。例如，如先前所描述的，事件及對那些事件的用戶響應可以通過監(jiān)測用戶數(shù)據(jù)(包括從用戶數(shù)據(jù)收集部件214接收的數(shù)據(jù))來確定，并且由此，可以確定事件模式并且檢測未處理事件。在一些實施例中，事件監(jiān)測器280跨多個計算設備或在云中監(jiān)測事件及相關信息。
如示例系統(tǒng)200所示，事件監(jiān)測器280包括事件模式標識器282、未處理事件檢測器284、上下文信息提取器286和事件響應分析器288。在一些實施例中，事件監(jiān)測器280和/或其子部件中的一個或多個可以從所接收的用戶數(shù)據(jù)來確定解釋性數(shù)據(jù)。解釋性數(shù)據(jù)對應于由事件監(jiān)測器280的子部件用來解釋用戶數(shù)據(jù)的數(shù)據(jù)。例如，解釋性數(shù)據(jù)可以用于向用戶數(shù)據(jù)提供上下文，這可以支持由子部件進行的確定或推斷。此外，所預期的是，事件監(jiān)測器280及其子部件的實施例可以使用用戶數(shù)據(jù)和/或結(jié)合解釋性數(shù)據(jù)來使用用戶數(shù)據(jù)，以用于實施本文所描述的子部件的目標。
一般而言，事件模式標識器282負責確定事件模式。在一些實施例中，事件模式可以通過監(jiān)測與事件或?qū)δ切┦录挠脩繇憫嘘P的一個或多個變量來確定。這些監(jiān)測的變量可以從結(jié)合用戶數(shù)據(jù)收集部件214所描述的用戶數(shù)據(jù)(例如：位置，時間/日期，通信的(一個或多個)發(fā)起者或(一個或多個)接受者，通信類型(例如，呼叫、電子郵件、文本等)，用戶設備數(shù)據(jù)等)來確定。特別地，變量可以從與事件有關的上下文數(shù)據(jù)來確定，如本文中所描述的，該上下文數(shù)據(jù)可以通過上下文信息提取器286從用戶數(shù)據(jù)中提取。因此，變量可以表示多個事件間的上下文相似度。以這種方式，模式可以通過檢測多個事件上的共同的變量來標識。更具體地，與第一事件相關聯(lián)的變量可以與第二事件的變量相互關聯(lián)，以標識用于確定可能的模式的共同變量。例如，在第一事件包括用戶發(fā)起的在星期六對被標識為“母親”的聯(lián)系人的呼叫并且第二事件包括用戶發(fā)起的在下一星期六對同一聯(lián)系人(“母親”)的呼叫的情況下，則模式可以被確定為用戶在星期六呼叫“母親”。在這種情況下，兩個事件的共同變量包括同一聯(lián)系人實體(母親)、同一天(星期六)、通信是用戶發(fā)起的、通信的同一接收者(母親)以及同一類型或模式的通信(通話)。
構(gòu)成模式的事件實例被重復的頻率越高，所標識的模式變得越強(即，更可能或更可預測)。類似地，具體的變量可以隨著其被重復而變得與模式更強烈地相關聯(lián)。例如，假設每天下午5點后(下班后)且在駕駛時，用戶都會呼叫同一組聯(lián)系人(其可能是她的家庭成員)中的某個人。盡管被呼叫的具體個人(即，用戶呼叫的聯(lián)系人實體)變化，但是存在事件模式，因為用戶重復地呼叫該組中的某個人。
事件模式不一定包括相同的通信模式。例如，一種事件模式可以是用戶每個星期六呼叫或發(fā)送電子郵件給他的母親。此外，在某些情況下，事件模式可以進化，諸如在每個星期六呼叫他的母親的用戶開始發(fā)送電子郵件給他的母親而不是在星期六給她打電話的情況下，在這種情況下，該模式變?yōu)橛脩粼谛瞧诹c他的母親通信。事件模式可以包括：事件相關的例程；與事件相關聯(lián)的典型的用戶活動，或者與至少一個共同變量相關聯(lián)的重復的事件相關的用戶活動。例如，特定用戶具有以下的模式：在駕駛時但僅在下午5:30之后或駕駛持續(xù)時間大于10分鐘時打電話?；蛘撸脩艉芸赡茉谙挛?:00與9:30之間但是很少在下午9:30之后瀏覽因特網(wǎng)和回復個人電子郵件。此外，在一些實施例中，事件模式可以包括可以對事件的用戶響應模式，其可以如下文所描述的那樣從事件響應分析器288確定。
一般而言，事件響應分析器288負責確定針對所監(jiān)測的事件(包括未處理事件)的響應信息，諸如用戶如何響應特定事件和事件響應模式。響應信息通過分析與事件及用戶活動相對應的用戶數(shù)據(jù)(從用戶數(shù)據(jù)收集部件214接收的)來確定，所述用戶活動是在用戶意識到事件、包括在用戶意識到未處理事件之后(諸如，未接來電)發(fā)生的。在一些實施例中，事件響應分析器288從呈現(xiàn)部件218接收數(shù)據(jù)，該數(shù)據(jù)可以包括與用戶已經(jīng)意識到的所監(jiān)測的事件相對應的用戶動作，和/或事件響應分析器288從上下文信息提取器286接收關于所監(jiān)測的事件的上下文信息。事件響應分析器288結(jié)合所監(jiān)測的事件來分析這種信息并且確定針對事件的響應信息集合。基于在多個事件上確定的響應信息，事件響應分析器288可以基于與事件相關聯(lián)的上下文信息來確定特定用戶對某些事件的響應模式。例如，在所監(jiān)測的事件包括來自用戶的老板的傳入電子郵件的情況下，事件響應分析器288可以確定在用戶意識到該電子郵件之后用戶以第一可用機會響應該電子郵件。但是，在所監(jiān)測的事件包括來自用戶的妻子的未接來電的情況下，事件響應分析器288可以確定用戶通常在下午12點與1點之間(即，午餐時)或在下午5點30分之后(即，下班后)給她回電話。類似地，事件響應分析器288可以確定用戶僅在某些條件下響應某些事件(其可以由上下文信息提取器286基于與事件相關聯(lián)的變量來確定)，某些條件諸如當用戶在家、在工作、在汽車中、在計算機前面時等。以這種方式，事件響應分析器288確定包括針對特定事件的用戶響應模式的響應信息。用戶的所確定的響應模式可以存儲在與用戶相關聯(lián)的用戶簡檔240的(一個或多個)事件響應模型的部件244中，并且可以由通知引擎260使用，以用于向用戶提供通知內(nèi)容。
在一個實施例中，由事件響應分析器288確定的這種響應信息被提供給通知引擎260，通知引擎260使用響應信息為用戶準備通知內(nèi)容。例如，如下文所進一步描述的，可用性確定器264可以使用響應信息來確定處理特定類型的事件所需要的用戶能力級別，諸如處理第一類型的事件可能要求用戶讀取其計算機上的文檔，并且因此用戶可用性取決于用戶通過顯示器對計算設備的訪問。然而，第二類型的事件可以通過電話呼叫而可處理，并且因此用戶可用性取決于用戶進行電話呼叫的能力，例如，如果確定用戶正在駕駛，那么這可能發(fā)生，而如果確定用戶在會議中，那么這可能不發(fā)生。
此外，在一些實施例中，事件響應分析器288使用眾包數(shù)據(jù)或來自多個用戶的數(shù)據(jù)來確定響應信息，該響應信息可以被用于基于特定用戶將做出與其他用戶類似的反應的前提，來確定該特定用戶的可能響應模式。例如，用戶模式可以基于以下來確定：確定其他用戶更有可能在晚上呼叫他們的朋友和家庭成員而在白天工作期間不太可能呼叫這些同樣的實體。用戶模式也可以類似地基于以下來確定：確定其他用戶通常會在最早方便的時候回電給他們的配偶，而即使不方便也會盡可能快地回電給他們的老板。此外，在一些實施例中，上下文信息提取器286提供與來自其他用戶的類似事件相對應的上下文信息，該上下文信息可以由事件響應分析器288使用來確定由那些用戶采取的響應?？梢酝ㄟ^確定上下文相似性來標識具有類似事件的其他用戶，上下文相似性諸如其他用戶的事件中與該特定用戶的事件的變量相同的變量。例如，相同變量可以包括各方之間的關系(例如，用戶與通信事件的接受者或發(fā)起者之間的關系)、位置、時間、日期、通信模式或先前描述的任何其他變量。因此，事件響應分析器部件288可以基于從具有類似事件的多個用戶接收的眾包用戶信息(例如，用戶歷史、在相關聯(lián)的事件之后(在一些實施例中，還包括在相關聯(lián)的事件之前)的用戶活動、與聯(lián)系人實體的關系以及其他上下文信息)來學習用戶群的典型響應模式。因此，從響應信息中，可以確定當具有某些特性(例如，上下文特征或變量)的事件發(fā)生時被采取的典型響應是什么。
此外，大多數(shù)用戶對不同的聯(lián)系人或?qū)嶓w表現(xiàn)或反應不同。事件可以與實體相關聯(lián)，可以與一類實體(例如，親密的朋友、工作同事、老板、家庭、用戶時常出入的諸如銀行之類的商家等)相關聯(lián)。使用由上下文信息提取器286(下文描述)提供的上下文信息，事件響應分析器288可以基于用戶如何響應相似類別的實體或其他用戶在類似情形下(諸如，在存在共同變量的情況下)如何響應來推斷用戶的用戶響應信息。因此，例如，在特定用戶接收到來自新的經(jīng)理的未接來電并且此前從未響應過該經(jīng)理的情況下，事件響應分析器288可以考慮該用戶先前如何響應其他經(jīng)理或者用戶的同事(如類似情形下的其他用戶)如何響應同一經(jīng)理或其他經(jīng)理。
一般而言，未處理事件檢測器284負責檢測未處理事件，諸如可能需要用戶響應或動作的事件，或用戶可能希望響應的事件。作為示例而非限制，未處理事件的示例包括：由與用戶相關聯(lián)的計算設備接收到的被錯過或未處理的通信，諸如未接來電或未響應的電子郵件；在與用戶相關聯(lián)的事件模式中的一個事件的錯過實例，諸如用戶每個星期日呼叫他的祖母，但是在上一星期日沒有呼叫她；需要用戶動作的即將到來的事件，諸如在用戶的日歷上指示的即將到來的周年紀念、汽車保險續(xù)簽或者將要到期的優(yōu)惠券或要約；用戶尚未確認的與用戶相關的新聞項、信息項或通知(包括社交媒體新聞項、帖子、推文、標簽等)；或者尚未被用戶響應、處置或以其他方式處理的請求或任務，包括由用戶設置的提醒(例如，用戶向他的移動設備所說的“cortana，提醒我修理漏水的龍頭”)；或者用戶尚未響應、處置或以其他方式處理的其他事件，諸如本文中所描述的其他未處理事件。
未處理事件檢測器284可以基于以下來檢測未決的未處理事件：由事件監(jiān)測器280檢測到的事件，來自從用戶數(shù)據(jù)收集部件214收集的用戶數(shù)據(jù)的信息，以及來自事件響應分析器288的響應信息。例如，在以下情況下可以檢測未處理事件的實例：發(fā)生所監(jiān)測的事件并且用戶尚未進行響應；或者所監(jiān)測的事件將在不久的將來發(fā)生并且由事件響應分析器288對用戶活動的分析指示用戶可能尚未進行與事件相關聯(lián)的活動，諸如用戶數(shù)據(jù)(并且特別是用戶活動信息)不包括與所監(jiān)測的事件相對應的上下文特征。未處理事件信息可以被提供給通知引擎260。
在一些實施例中，未處理事件檢測器284使用來自(一個或多個)用戶賬戶/活動數(shù)據(jù)248的信息來監(jiān)測與用戶相關的社交網(wǎng)絡活動。未處理事件檢測器284還可以監(jiān)測響應于由事件監(jiān)測器280檢測到的事件而進行的用戶活動，由事件監(jiān)測器280檢測到的事件包括與用戶有關的新聞或信息項，這些新聞或信息項可以從諸如數(shù)據(jù)源104a-104n(圖1)的其他數(shù)據(jù)源檢測到。如此，未處理事件檢測器284的一些實施例基于用戶活動來確定用戶可能尚未處理或可能尚未意識到所檢測到的事件。例如，在用戶活動指示用戶沒有訪問社交媒體賬戶的情況下，或者在用戶(或其他用戶)通常以某一用戶活動模式對類似新聞項、信息項或其他事件做出響應或者反應，而這樣的用戶活動尚未被未處理事件檢測器284檢測到的情況下，可以確定用戶可能尚未處理和/或尚未意識到檢測到的事件。
在一些實施例中，未處理事件檢測器284標識可能指示未處理事件的觸發(fā)情形。例如，未被應答的呼入，未被響應或甚至未經(jīng)用戶界面呈現(xiàn)給用戶的電子郵件，或者未被維持的用戶模式。一個或多個檢測到的觸發(fā)情形可以激發(fā)未處理事件檢測器284確定未處理事件是否未決，使得通知引擎260可以確定用于處理該未處理事件的所推薦的動作方案。
在一個實施例中，未處理事件檢測器284考慮針對類似事件的典型的用戶響應模式，其可以經(jīng)由由事件響應分析器288確定的響應信息來提供。用戶響應模式可以與當前或近期的用戶活動數(shù)據(jù)相比較，以便確定用戶是否可能已經(jīng)(或可能)對特定事件做出響應。例如，在用戶的日歷指示他的周年紀念日是下周(潛在的未處理事件)并且用戶數(shù)據(jù)(諸如用戶的電子郵件或網(wǎng)站用戶歷史)指示用戶可能預訂了在周年紀念日期的餐廳，那么可以確定用戶可能已經(jīng)處理了該事件，并且因此通知引擎260不需要準備提醒。盡管如此，然而在一些實施例中，取決于從特別是近期用戶活動的用戶數(shù)據(jù)確定的、用戶已經(jīng)處理了事件的可能性，關于事件(即將到來的周年紀念日)的通知可以被呈現(xiàn)給用戶。
作為另一示例，假設在與用戶相關聯(lián)的賬戶上接收到電子郵件，并且與電子郵件相關聯(lián)的上下文信息指示該電子郵件來自用戶的老板并且包含可能指示緊急性的很多關鍵字。用戶數(shù)據(jù)指示用戶訪問了他的電子郵件、電子郵件在用戶設備上被呈現(xiàn)給了用戶(換言之，用戶可能已經(jīng)閱讀了來自他的老板的電子郵件)，但是用戶尚未回復電子郵件。但是用戶數(shù)據(jù)還指示用戶在訪問該電子郵件之后呼叫了他的老板(從他的智能手機)。那么可以確定用戶可能已經(jīng)處理了該事件，并且不需要被提醒以響應他老板的電子郵件。
作為又一示例，假設觸發(fā)情形指示未接來電，并且與呼叫相關聯(lián)的上下文信息指示是用戶妻子的呼叫。但是，用戶數(shù)據(jù)指示自未接來電以來用戶尚未向其妻子發(fā)出呼叫，并且自未接來電以來也沒有給他妻子發(fā)電子郵件或發(fā)短信。因此，未處理事件檢測器284檢測到可能的未處理事件；即，來自用戶的妻子的未接來電?，F(xiàn)在，進一步假設當發(fā)生未接來電時，用戶與他妻子不在同一位置(位置可以從與用戶相關聯(lián)的諸如智能電話的用戶設備來確定)，但是現(xiàn)在用戶的位置和妻子的位置相同；例如，二者目前都在家里。那么可以確定潛在的未處理事件(未接來電)不太可能未決，因為用戶和他的妻子一起在家，并且可能相互通信。因此，事件很可能得到了處理。
作為又一示例，假設事件模式指示用戶每個星期日呼叫他的祖母。但是用戶數(shù)據(jù)(諸如用戶的日歷和電子郵件)指示用戶將在下個星期日出國旅行。因此，存在未來的未處理事件的可能性。在一些實施例中，未處理事件檢測器284可以確定可能發(fā)生未處理事件，并且類似于上文示例，考慮近期的用戶活動數(shù)據(jù)，以便確定用戶是否可能已經(jīng)(或可能)對未處理事件做出響應。例如，如果用戶代之在星期五呼叫了他的祖母，那么可以確定用戶已經(jīng)處理了該事件。
在另外的示例中，假設事件模式指示用戶通常喜歡或評論來自特定實體的社交媒體帖子，分享來自特定實體的社交媒體帖子。從用戶數(shù)據(jù)收集部件214收集的用戶數(shù)據(jù)指示特定實體已經(jīng)在社交媒體上發(fā)布了新聞項，但是來自事件響應分析器288的響應信息確定用戶尚未響應該項。因此，未處理事件檢測器284基于用戶沒有遵循他響應社交媒體活動或特定實體的典型模式，來檢測可能的未處理事件。備選地，假設從用戶數(shù)據(jù)收集部件214收集的用戶數(shù)據(jù)指示用戶的社交網(wǎng)絡聯(lián)系人中的很多或者甚至絕大多數(shù)對信息項(諸如，新聞項、帖子、熱門話題等)做出響應。但是來自事件響應分析器288的響應信息確定用戶尚未確認或響應該項或者可能甚至不知道該項。未處理事件檢測器284可以確定這是與信息項相對應的未處理事件。在一些實施例中，未處理事件檢測器284可以使確定基于用戶模式或用戶歷史信息，諸如用戶在先前情況下多久響應信息項一次。此外，從信息項中提取的其他上下文信息可以用于確定信息項對于用戶的級別或緊急性或重要性，其可以用于向用戶提供通知，如本文所進一步描述的。
一般而言，上下文信息提取器286負責確定與由事件監(jiān)測器280監(jiān)測的事件相關聯(lián)的上下文信息，諸如與事件和用戶相關活動相關聯(lián)的上下文特征或變量。上下文信息可以從由用戶數(shù)據(jù)收集部件214提供的一個或多個用戶的用戶數(shù)據(jù)來確定。例如，上下文信息提取器286接收用戶數(shù)據(jù)，在某些情況下解析數(shù)據(jù)，并且標識和提取上下文特征或變量。在一些實施例中，變量被存儲作為與事件、響應、或在事件之后的時間間隔內(nèi)的用戶活動(其可以指示用戶響應)相關聯(lián)的上下文信息的相關集合。
特別地，上下文信息提取器286的一些實施例確定與事件、聯(lián)系人實體(或?qū)嶓w，諸如在群發(fā)電子郵件的情況下)、圍繞事件的用戶活動以及當前用戶活動相關的上下文信息。作為示例而非限制，這可以包括上下文特征，諸如：位置數(shù)據(jù)；時間、天和/或日期；通信的數(shù)目和/或頻率；通信中的關鍵字(其可以用于確定重要性或緊急性)；關于聯(lián)系實體的上下文信息(諸如實體身份、與用戶的關系、聯(lián)系實體的位置(如果可確定)、與用戶的先前聯(lián)系的頻率或級別)；歷史信息，包括與聯(lián)系人實體的模式和歷史；(一個或多個)通信的模式或類型；當事件發(fā)生時或者當可能響應事件時用戶參與了什么用戶活動，以及用戶何時、在何地以及多長時間地參與了與事件或?qū)ξ刺幚硎录目赡茼憫嚓P聯(lián)的活動；或者從用戶數(shù)據(jù)可確定的任何其他變量，該用戶數(shù)據(jù)包括來自其他用戶的用戶數(shù)據(jù)。上下文信息的其他示例包括置信度得分、方差得分以及在標識未處理事件或?qū)κ录挠脩繇憫猩傻钠渌畔ⅰ?/p>
如上所述，上下文信息可以被提供給：事件模式標識器282，以用于確定模式(諸如，使用共同變量的事件模式)；未處理事件檢測器284，以用于確定未處理事件是否仍然未決、用戶為處理未處理事件而采取的動作或響應的范圍、或者響應未處理事件已不再相關(諸如，在其中用戶和他妻子都在家里并且因此用戶不需要給他妻子回電話的示例中)；以及事件響應分析器288，以用于確定響應模式(包括其他用戶的響應模式)。特別地，提供給事件響應分析器288的上下文信息可以用于確定關于用戶響應模式的信息、可以與響應未處理事件相對應的用戶活動、用戶參與響應未處理事件多長時間、通信的模式、或者用于確定用于處理某些類型的事件所期望的用戶能力的其他信息，其可以用于確定響應未處理事件的用戶可用性。此外，上下文信息可以被提供給通知引擎260，并且用于確定錯過的事件的緊急性或重要性、用于處置未處理事件的用戶可用性、用于協(xié)助用戶處理未處理事件的補充內(nèi)容、以及用于向用戶呈現(xiàn)通知的邏輯，諸如何時、在何地或如何呈現(xiàn)通知內(nèi)容。
繼續(xù)圖2，通知引擎260通常負責生成和提供關于事件的通知內(nèi)容，其中其可以作為個性化通知被提供給用戶。在一個實施例中，通知內(nèi)容包括通知，該通知可以是以針對用戶處理未處理事件的推薦動作的形式，并且通知內(nèi)容還可以包括用于協(xié)助用戶處理事件的補充內(nèi)容。在一些情況下，通知內(nèi)容包括通知邏輯，通知邏輯指定用于基于用戶數(shù)據(jù)來呈現(xiàn)通知的條件，諸如與呈現(xiàn)來自通知內(nèi)容的通知有關的(一個或多個)時間、(一個或多個)位置、(一個或多個)模式或其他參數(shù)。
例如，通知內(nèi)容可以包括給用戶的關于回撥來自其妻子的呼叫的通知，其中邏輯指定當用戶數(shù)據(jù)指示用戶已經(jīng)開動他的汽車以在工作日結(jié)束下班開車回家時，通知可以被呈現(xiàn)給用戶，或者在指示用戶開啟他的智能電話上的電話應用的用戶數(shù)據(jù)的下一實例時，通知在彈出窗口中被呈現(xiàn)給用戶。通知可以呈現(xiàn)文本或音頻問詢，文本或音頻問詢詢問用戶“你現(xiàn)在要呼叫你妻子嗎？”基于來自用戶的肯定性響應(例如，說“是”或觸摸他的移動設備上的“是”按鈕)，用戶的妻子被自動呼叫，而用戶不必提供電話號碼。繼續(xù)該示例，通知內(nèi)容可以包括補充內(nèi)容，諸如提醒用戶他妻子在45分鐘內(nèi)登機并且這將是她離開之前他呼叫她的唯一機會。
在一些實施例中，通知引擎260生成要呈現(xiàn)給用戶的通知，其可以被提供給呈現(xiàn)部件218。備選地，在一些其他實施例中，通知引擎260生成通知內(nèi)容并且使通知內(nèi)容可用于呈現(xiàn)部件218，呈現(xiàn)部件218基于通知內(nèi)容中的通知邏輯以及應用于通知邏輯的用戶數(shù)據(jù)來確定何時以及如何(即，什么格式)呈現(xiàn)通知。在一些實施例中，與呈現(xiàn)部件218結(jié)合地操作的通知服務或應用確定或支持確定何時以及如何呈現(xiàn)通知。與用戶相關聯(lián)的未決通知可以存儲在用戶簡檔240中，諸如在(一個或多個)通知的部件250中。此外，在一些實施例中，通知引擎260、呈現(xiàn)部件218和/或通知服務或應用管理針對用戶的未決通知，并且可以諸如下文所描述的那樣對哪些通知被呈現(xiàn)排列優(yōu)先級。
如先前所述，通知引擎260可以從用戶數(shù)據(jù)收集部件214和/或事件監(jiān)測器280接收信息(其可以存儲在與用戶相關聯(lián)的用戶簡檔240中)，所述信息包括：事件數(shù)據(jù)；當前用戶信息，諸如用戶活動；未處理事件數(shù)據(jù)，其還可以包括事件未被處理的所確定的可能性；上下文信息；從事件響應分析器288確定的響應信息(在某些情況下包括其他用戶如何對類似事件做出響應或反應)；事件模式信息、用戶可用性模型或可用性模式信息；或來自其他部件或來源的用于創(chuàng)建通知內(nèi)容的信息。在一個實施例中，使用上述接收到的信息，通知引擎260確定與未處理事件相關聯(lián)的重要性或緊急性，并且確定用于處理事件的用戶可用性(下文所進一步描述的)，其可以基于緊急性或重要性來確定并且可以基于用戶處理事件的能力而變化。通知引擎260還可以生成補充內(nèi)容和通知邏輯，其可以基于與未處理事件或其響應相關聯(lián)的所確定的可用性、緊急性和上下文。以這種方式，本發(fā)明的實施例可以提供能夠基于上下文、用戶對通知的響應及具有充分地處理該事件的能力的可能性來針對用戶而被個性化的通知內(nèi)容，使得用戶更易于以及時且方便的方式來處置事件。
如示例系統(tǒng)200所示，通知引擎260包括緊急性/重要性確定器262、可用性確定器264、補充內(nèi)容生成器266和通知邏輯生成器268。一般來說，緊急性/重要性確定器262負責確定未處理事件的重要性級別和/或緊急性級別。重要性級別可以指示用戶處理事件有多重要或有多必要，而緊急性級別可以指示事件應該在多長時間內(nèi)被處理。通知引擎260的一些實施例可以確定緊急性、重要性或二者。此外，未處理事件可以隨著截止日期的接近(諸如前述的周年紀念日示例)而變得更加緊急，并且重要性級別和/或緊急性級別可以基于以下而被更新：上下文信息的改變、當前用戶數(shù)據(jù)、用戶的響應、新檢測到的用戶模式、或被確定為與已經(jīng)出現(xiàn)的事件相關的新的未處理事件。例如，在未響應的電子郵件之后的來自老板的未接電話可以指示用于響應電子郵件的更高的緊急性級別。
在一些實施例中，緊急性/重要性確定器262使用關于未處理事件的信息(其可以從未處理事件檢測器284接收)，連同所接收的用戶數(shù)據(jù)(從用戶數(shù)據(jù)收集部件214)或上下文信息(由上下文信息提取器286提供)或由事件監(jiān)測器280、用戶簡檔240或呈現(xiàn)部件218提供的其他數(shù)據(jù)一起，來確定緊急性級別和/或重要性級別(其可以被實施為得分或數(shù)值)。例如，緊急性/重要性確定器262可以考慮：類似的未處理事件及其頻率(諸如，重復的未接來電或者來自同一聯(lián)系人的未響應的電子郵件和未接來電)；來自用戶或其他用戶的對類似事件的響應(來自事件響應分析器288)，其可以基于(一個或多個)用戶在類似的未處理事件發(fā)生多久之后做出響應，來指示重要性級別或緊急性級別；或模式信息，諸如未處理事件是否與模式相關聯(lián)或未處理事件是否是意外的。例如，在母親通常每個星期日打電話的情況下，與其中用戶在特定星期日錯過了接聽來自母親的呼叫相對應的未處理事件可以被確定為具有比在工作日中間或在半夜發(fā)生的來自母親的未接來電(即，母親在不常見的時間來電，這不符合與她通常來電的時間相關聯(lián)的模式)低的重要性。緊急性/重要性確定器262還可以或者可以備選地考慮：位置信息、一天中的時間和其他上下文信息(例如，在用戶的妻子從醫(yī)院來電或用戶的母親在半夜期間來電的情況下，可以確定更高的重要性級別和緊急性級別)；與處理某些事件的重要性或緊急性有關的用戶設置或偏好、或與特定變量相關聯(lián)的事件，其可以學習或由用戶明確地指定(例如，分配給來自老板的通信的重要性級別或者來自親密的朋友的所有通信)；以及用戶與聯(lián)系人實體的關系(例如，這是熟人、親密的朋友、家庭成員、同事、老板等)，其可以包括用戶在聯(lián)系人名單或社交媒體賬戶中如何標識該實體、和/或用戶與該聯(lián)系人進行通信的歷史記錄以及與該實體的聯(lián)系級別。例如，來自用戶的朋友的未接來電可以被確定為比來自與用戶沒有先前聯(lián)系的銷售員的未接來電更重要。
在一些實施例中，緊急性級別或重要性級別可以基于與未處理事件相關聯(lián)的上下文特征(包括所提取的關鍵字或從類似事件中提取的其他上下文特征)從上下文信息來確定。特別地，如前所述，關鍵詞和其他上下文特征可以由上下文信息提取器286提取，并且由事件響應分析器288使用，以基于與事件相關聯(lián)的某些關鍵字或其他上下文特征來確定關于一個或多個用戶的用戶響應的信息，諸如關于用戶通常如何響應的信息(包括他們最快多久響應)。此外，一些關鍵字可以被預先確定，以指示可能的緊急性(諸如，可能存在于通信中的“緊急”、“立即”或類似詞語)。
在一些實施例中，使用前兩段中所描述的接收到的信息，可以為未處理事件確定緊急性程度或重要性程度，并且將其用于確定表示緊急性級別或重要性級別的值。例如，在實施例中，可以相對于用戶的先前響應或其他用戶的類似響應來確定事件的重要性級別或緊急性級別，用戶的先前響應或其他用戶的類似響應包括處置先前被確定為緊急或重要的或者先前被確定為不重要或不緊急的未處理事件。以這種方式，基于與類似事件及極端情況(緊急/重要事件和非緊急/重要事件)的比較以及那些事件的處置方式，所確定的級別可以跨越某個范圍(諸如，1至10或者“不緊急”至“非常緊急”)。此外，在一些實施例中，可以應用一個或多個閾值來確定所確定的緊急性級別值或重要性級別值是否足以導致呈現(xiàn)與未處理事件相關聯(lián)的通知。例如，用戶可能希望不被與重要性低的未處理事件(諸如，來自隨機的推銷員的未接來電)相對應的通知打擾。因此，在一些實施例中，當重要性級別低時，可以不需要響應于標識日常事務之外的事件的動作。此外，閾值可以基于上下文和通知內(nèi)容而變化，諸如針對用戶處理未處理事件的推薦響應。例如，如果是半夜(從上下文信息確定的)，那么對于向用戶呈現(xiàn)通知的價值的重要性的閾值可以高于如果是在一天的中間且用戶以其他方式可用的情況。此外，基于不同的重要性級別，可以采取或可以推薦采取不同的動作來處理未處理事件。在實施例中，使用緊急性或重要性閾值，閾值可以基于預定規(guī)則、用戶歷史、來自其他用戶的數(shù)據(jù)或者用戶偏好或設置來確定，諸如下文所進一步描述的。
在一些實施例中，緊急性級別或重要性級別具有相關聯(lián)的概率或置信度，相關聯(lián)的概率或置信度指示所確定的緊急性或重要性的可能性。置信度可以基于潛在地指示緊急性或重要性的上下文信息的量和/或與上下文信息的具體片段相關聯(lián)的大小(或權(quán)重)來確定。(例如，被指定為“高度重要性”消息的來自用戶老板的電子郵件將比具有正常重要性的來自老板的電子郵件具有更大的權(quán)重。)在一些實施例中，可以使用置信度來對被呈現(xiàn)給用戶的通知排列優(yōu)先級。例如，在兩個或更多個通知共享類似的緊急性或重要性的情況下，具有更高置信度的通知可以優(yōu)先于其他通知(例如，可以首先或更早地被示出)。
通知引擎260的實施例可以使用重要性級別和/或緊急性級別，來確定用戶用于處理未處理事件的可用性，諸如用于響應未處理事件的相關和最佳時間。用戶的可用性可以基于未處理事件的重要性和緊急性而改變。例如，可以確定否則不可用的用戶可用于非常緊急和重要的事件(諸如，來自他妻子的指示她即將分娩并且在去往醫(yī)院的途中的未接來電)，但對于不緊急或不重要的未處理事件(諸如，來自隨機推銷員的未接來電)保持不可用。
一般而言，可用性確定器264負責確定用于處理未處理事件的用戶可用性，在一些實施例中，包括當前可用性和/或未來可用性(或預測的可用性)。特別地，可用性確定器264的一些實施例基于由事件監(jiān)測器280提供的用戶數(shù)據(jù)和信息，來推斷或預測用于在未來時段處置未處理事件的用戶可用性，如下文所進一步描述的。可以被表示為(一個或多個)可用性得分的集合的所確定的用戶可用性信息可以部分地基于用戶用于實施與處理未處理事件相關聯(lián)的動作的潛力或能力。此外，可用性信息可以由一個或多個可用性模型來表示，在一些實施例中，一個或多個可用性模型可以存儲在與用戶相關聯(lián)的用戶簡檔240中。例如，可以確定用戶每個工作日從上午8:00到8:30進行通勤，并且因此在此期間不具有回復電子郵件的能力，但是可用于做出電話呼叫。然而，在上午8:30之后，用戶可能在她的辦公室中并且登錄到她的計算機，并且因此可用于電子郵件以及可能涉及在計算機處訪問網(wǎng)頁、閱讀文檔、打字或其他動作的任務。在特定的一天，在交通數(shù)據(jù)指示事故并且用戶的通勤延長的情況下，那么用戶的所預測的可用性信息(諸如，在一些實施例中的可用性模型)可以被調(diào)整以考慮通勤中花費的額外時間。
所確定的用戶可用性信息(其可以被稱為可用性計劃表)可以用于向用戶提供通知內(nèi)容。例如，可用性、緊急性和/或重要性可以用于確定與向用戶提供通知內(nèi)容相關聯(lián)的邏輯和其他參數(shù)，諸如：在何地或何時提供(一個或多個)通知；應當如何或以何種格式(例如，作為報警、彈出、通知漏洞、語音建議等)，或者以何種外觀或特性來提供通知內(nèi)容；以及通知內(nèi)容應當包括哪些內(nèi)容(包括應當包含多少內(nèi)容以及應當包含多少補充內(nèi)容)。例如，正在駕駛的用戶可能應當被呈現(xiàn)比正在訪問膝上型計算機的用戶更少的內(nèi)容。以這種方式，在被確定為可能對用戶來說是響應未處理事件的恰當?shù)臅r間(或時期，或時間窗口)處和/或在用戶可能將具有適當?shù)仨憫哪芰Φ那闆r下，基于事件的重要性或緊急性，用戶可以被呈現(xiàn)通知內(nèi)容。在一些實施例中，所推斷的可用性信息可以表示用戶最有可能選擇(或想要)響應未處理事件的(一個或多個)最佳時間，其基于用戶模式、響應信息、上下文信息和/或如本文中所描述的其他用戶數(shù)據(jù)來確定。例如，可以確定：當用戶在家里直到下午8:00而不是更晚時，用戶將響應某種類型的事件；或者特定用戶在下午6:00到7:00之間(這可能對應于該用戶正在吃晚飯的時間)不響應事件。
在一些情況下，處理未處理事件可以涉及與處理事件的不同方式(諸如，如電子郵件或電話的不同通信類型)或者在需要一系列動作來處理事件的情況下要完成的不同任務相對應的不同級別的用戶能力。(處理未處理事件的不同方式和一系列動作可以由來自事件響應分析器288的響應信息來提供。)例如，在未處理事件是用戶的即將到來的周年紀念日的情況下，用戶可以能夠通過電話或在餐廳的網(wǎng)站處在線地在餐廳預訂。此外，處理一些未處理事件可能需要用戶的多個動作，使用先前的示例，諸如以下任務：首先確定哪些餐廳供應用戶的妻子喜歡的菜肴，然后確定那些餐廳中的哪些在周年紀念日可用，確定用戶及他妻子可用于晚餐的時間范圍，并且最后在其中一間餐廳進行預訂。因此，在一些實施例中，用戶可用性信息反映用戶處置各種活動以完成任務的能力。例如，在駕駛時，用戶的可用性信息對于電子郵件是低的(或指示用戶不可用于電子郵件)，并且對于閱讀文檔或瀏覽因特網(wǎng)是低的，但是對于發(fā)起電話呼叫是高的，因為用戶可以在駕駛的同時打電話。在一些這樣的實施例中，可用性信息可以被表示為指示與不同的活動或通信類型相對應的可用性得分的集合的矩陣，不同的活動或通信類型諸如打電話、發(fā)電子郵件、瀏覽因特網(wǎng)、閱讀文檔、打字或簽名、存在于特定位置處等。
用戶可用性信息可以基于對事件的先前響應、上下文信息以及包括當前用戶數(shù)據(jù)的其他用戶數(shù)據(jù)，從用戶模式(包括來自其他用戶的模式)來確定。例如，可以評估與用戶相關聯(lián)的日歷或社交網(wǎng)絡簡檔，以標識與用戶有關的活動，諸如從社交網(wǎng)絡帖子以及用戶與另一用戶之間的消息中標識的棒球游戲活動。在另一示例中，可用性信息可以部分地從與用戶設備相關聯(lián)的上下文特征(例如，設備位置、設備時間、運輸?shù)哪Ｊ?、設備位置簽到、警報、充電狀態(tài)、連接性狀態(tài)、或存儲在設備上的用戶數(shù)據(jù))來確定，諸如存儲在設備上的視頻游戲機預訂收據(jù)可以被評估，以標識視頻游戲機發(fā)行接收活動。在另一示例中，用戶信號可以包括可以用于基于用戶信號來標識活動(例如，再現(xiàn))的時間信息、位置信息和/或各種各樣的信息(例如，設備可以具有與星期六的早餐餐廳相對應的位置，這可能指示用戶在星期六在早餐餐廳處吃早餐的例行程序)。
在又一示例中，用戶可用性可以使用來自一個或多個用戶日歷的日歷信息來確定，一個或多個用戶日歷諸如辦公室日歷、個人日歷、社交媒體日歷、或者甚至在某些情況下來自用戶的家庭成員或朋友的日歷。本發(fā)明的一些實施例可以為用戶構(gòu)建補充或陰影(shadow)日歷，以用于確定可用性。特別地，在這樣的實施例中，補充或陰影日歷可以用于創(chuàng)建用戶的可用性模型。
在實施例中，補充日歷可以基于與設備的用戶相關聯(lián)的傳感器數(shù)據(jù)來構(gòu)造。例如，可以評估社交網(wǎng)絡簡檔(例如，指示用戶的愛好或興趣的社交網(wǎng)絡帖子、社交網(wǎng)絡消息、用戶簡檔等)，以將用戶的活動標識為特定的傳感器數(shù)據(jù)。在另一示例中，可以評估用戶設備的上下文，以將用戶的活動標識為傳感器數(shù)據(jù)(例如，設備位置可以指示用戶在星期二在足球場處進行足球練習；設備位置簽到可以指示用戶在星期日外出進行了電影約會(例如，用戶可以通過社交網(wǎng)絡簽到)；諸如wi-fi連接的連接性狀態(tài)可以指示用戶在家里、在辦公室中或在咖啡店處；諸如汽車充電狀態(tài)之類的充電狀態(tài)可以指示用戶當前正在駕駛；設備上的假期行程文件可以指示用戶將要在一周內(nèi)度假等)。
可以理解，在一些實施例中，可以評估諸如時間信息和/或位置信息的各種各樣的信息，以標識傳感器數(shù)據(jù)和/或補充傳感器數(shù)據(jù)(例如，用戶的主日歷可以用于標識沖突和/或驗證從傳感器數(shù)據(jù)得到的活動；傳感器數(shù)據(jù)可以對比著實時數(shù)據(jù)來評估，實時數(shù)據(jù)諸如交通信息、天氣或補充信息，其可以包括來自用戶的社交媒體賬戶、家庭或朋友社交媒體賬戶、電子郵件、新聞和其他用戶數(shù)據(jù)(例如，眾包數(shù)據(jù))的信息)。以這種方式，補充日歷可以利用從傳感器數(shù)據(jù)得到的一個或多個條目來構(gòu)建(例如，基于推斷的活動自動生成的條目)。在實施例中，補充日歷可以與一個或多個日歷(例如，用戶的主日歷、家庭日歷、社交網(wǎng)絡日歷等)合并以創(chuàng)建包括補充日歷(例如，從傳感器數(shù)據(jù)得到/推斷出的自動生成的條目)中的至少一些補充日歷以及一個或多個日歷(例如，在主日歷內(nèi)由用戶填充的用戶條目)中的至少一些日歷的陰影日歷。安排的沖突可以基于補充日歷和/或陰影日歷而被標識(例如，用戶條目可能指示用戶具有星期一9:00-9:30的工作會議，而補充日歷內(nèi)的條目可能指示基于社交網(wǎng)絡帖子用戶要在星期一的9:15和他的朋友會面喝咖啡)。
如在先前的示例中所描述的，可用性信息可以隨著用戶數(shù)據(jù)或上下文信息的改變而更新。在一個實施例中，基于以下來確定用戶將遵循一個或多個用戶模式的可能性：用戶數(shù)據(jù)(例如，日歷信息、會議請求、社交網(wǎng)絡饋送、位置數(shù)據(jù)等)、來自事件監(jiān)測器280的信息、和/或先前確定的(一個或多個)用戶模式，諸如用戶在工作日的上午8:00與8:30之間通勤上班(其可以從用戶電話的位置和移動信息、來自用戶的車輛的數(shù)據(jù)、示出用戶在工作日的上午8:30之后不久定期地在另一通勤設備(即，用戶的工作計算機)上登錄賬戶的數(shù)據(jù)或者其他類似的用戶數(shù)據(jù)來確定)。與這些模式相關聯(lián)的用戶能力可以基于以下來確定：從模式的先前實例中檢測到的用戶(或其他用戶)的活動(例如，用戶先前在其通勤期間發(fā)起電話呼叫；因此，用戶可能可用于電話通信)；規(guī)則，諸如在駕駛時無法閱讀文檔，或者如果道路結(jié)冰，那么駕駛中的用戶用于電話通信的可用性較低(用戶需要注意道路)；以及用戶設置或偏好(下文進一步描述)?？捎眯孕畔⒖梢员槐硎驹谝粋€或多個用戶可用性模型中。此外，在一些實施例中，使用一個或多個機器學習算法來確定可用性信息(或更新可用性模型)，諸如下文所進一步描述的。
一般而言，補充內(nèi)容生成器266負責確定用于協(xié)助用戶處理未處理事件的輔助內(nèi)容。如前所述，在一些實施例中，用于向用戶提供與未處理事件有關的通知的通知內(nèi)容可以包括補充內(nèi)容。補充內(nèi)容可以包括：有幫助的信息，諸如相關的上下文信息(例如，在用戶為其周年紀念日預訂的示例中，補充內(nèi)容可以包括這是用戶的十周年、在之前的電子郵件中用戶的妻子提到她想嘗試一家特定的餐廳等)；來自其他數(shù)據(jù)源的信息(諸如來自到用戶有用的內(nèi)容的網(wǎng)站或鏈接的內(nèi)容，諸如到用于進行餐廳預訂的網(wǎng)站的鏈接)；暗示或提示，其可以基于從其他用戶對類似事件的響應中得到的信息；推薦或建議；和/或用戶為了處理事件而需要采取的動作或步驟。
在一些情況下，補充內(nèi)容還可以包括關于用戶為了完成未處理事件已經(jīng)采取的動作和/或還剩什么步驟要完成的信息，例如，在用戶已經(jīng)開始研究餐廳以進行預訂但還沒有預訂的情況下，或者在用戶已經(jīng)響應于來自老板的電子郵件而開始起草電子郵件但尚未完成或發(fā)送電子郵件的情況下。此外，在一些實施例中，補充內(nèi)容可以包括已經(jīng)由個人助理應用采取的用于協(xié)助用戶處置未處理事件的動作。例如，在一些實施例中，個人助理應用(或類似服務)可以自動為用戶的周年紀念日進行晚餐預訂，并且提供補充內(nèi)容，該補充內(nèi)容通知用戶該預訂或要求用戶確認用戶希望完成該預訂。類似地，使用本發(fā)明的實施例，在完成為了處理未處理事件的動作時，個人助理應用可以預訂門票、訂購午餐或咖啡、獲得報價、比較價格、安排預約或類似活動，并且可以提供(作為補充內(nèi)容)關于由個人助理應用采取的(一個或多個)動作的信息。(在一些情況下，用戶可以提供針對個人助理應用或服務的授權(quán)來實施諸如先前示例的活動，包括進行購買。)
補充內(nèi)容可以基于其與處置未處理事件的相關性而被排列優(yōu)先級或排序。以這種方式，可用于用戶的補充內(nèi)容的量可以基于用戶的可用性(如由可用性確定器264確定的)。備選地或另外地，補充內(nèi)容可以與用于處理未處理事件的各種選項(例如，備選動作和/或通信類型)相關聯(lián)，諸如用于進行呼叫的補充內(nèi)容，其可以包括相關電話號碼、營業(yè)時間等，以及用于準備電子郵件的補充內(nèi)容，其可以包括到相關網(wǎng)站的鏈接。例如，在用戶正在駕駛并且未處理事件包括用戶的即將到來的周年紀念日的情況下，補充內(nèi)容可以包括到用于進行晚餐預訂的一個或多個餐廳的電話號碼，以及詢問用戶現(xiàn)在是否要進行預訂的請求。但是對于同一未處理事件，在用戶在辦公室中的情況下，補充內(nèi)容可以包括到用于進行預訂的一個或多個餐廳網(wǎng)站的鏈接。
在一些實施例中，補充內(nèi)容可以基于以下來確定：使用關鍵字和模式分析對未處理事件的上下文信息的語義理解，以及來自用戶的先前響應或來自響應類似事件的其他用戶的響應信息，來自其他用戶的響應信息可以包括其他用戶響應類似事件的用戶活動歷史(例如，瀏覽歷史、采取的動作等)。此外，在一些實施例中，補充內(nèi)容可以以類似于搜索引擎結(jié)果的方式來確定，其中查詢與未處理事件相關聯(lián)的上下文特征，并且結(jié)果用于確定或提供補充內(nèi)容。補充內(nèi)容還可以從基于特定類型的未處理事件的規(guī)則和/或處理未處理事件所需的動作來確定，例如，用于提供相關鏈接、電話號碼、營業(yè)時間、上下文背景的規(guī)則，或被確定為可能與未處理事件有關的進行的先前用戶活動，或者用于提供本文中關于補充內(nèi)容所描述的內(nèi)容的其他規(guī)則。
一般而言，通知邏輯生成器268負責確定用于向用戶呈現(xiàn)通知內(nèi)容的邏輯，諸如何時或如何呈現(xiàn)通知內(nèi)容。如前所述，在一些實施例中，用于向用戶提供與未處理事件有關的通知的通知內(nèi)容可以包括通知邏輯。通知邏輯可以指定用于向用戶通知未處理事件的規(guī)則、條件、約束、時間(包括未來的時間或時間窗口)和/或其他參數(shù)，及要被包括在通知中的內(nèi)容，以及指定或推薦用于呈現(xiàn)(一個或多個)通知的格式的邏輯。在一些實施例中，如下文所描述的，通知邏輯可以從用戶偏好或所確定的模式來確定，諸如，指定除非重要性超過用戶指定的級別否則不在半夜呈現(xiàn)通知的邏輯，或者指定不在下午6:00-7:00之間呈現(xiàn)通知因為用戶在此時間期間將不響應(可能是因為用戶正在吃晚飯)的邏輯。
通知邏輯可以基于以下來生成：所確定的可用性，其可以包括一個或多個用戶可用性模型；未處理事件的所確定的緊急性或重要性；以及其他用戶數(shù)據(jù)，諸如當前用戶信息或上下文信息。在一個實施例中，為每個未處理事件生成通知邏輯。在另一實施例中，相同或類似的通知邏輯被包括在與某個類別或種類的未處理事件(諸如，錯過的電子郵件)相對應的通知內(nèi)容中。在一個實施例中，通知邏輯包括優(yōu)先級信息，使得在多于一個未處理事件處于未決狀態(tài)的情況下，可以基于重要性或緊急性以及用于處理未處理事件的用戶可用性來對通知排列優(yōu)先級。以這種方式，可以管理被提供給用戶的通知(諸如，通過呈現(xiàn)部件218或者另一應用或服務)，使得用戶不被未完成的未處理事件所壓倒。
例如，在一個實施例中，未處理事件的重要性或緊急性可以用于對與那些未處理事件相對應的未決的或潛在的通知進行排序或以其他方式排列優(yōu)先級。指示所確定的優(yōu)先級或排序的信息可以被包括在通知邏輯中。此外，在實施例中，基于通知邏輯，未決的或潛在的通知可以基于其對應的未處理事件的重要性或緊急性而相對于其他未決的或潛在的通知來被評分。例如，在實施例中，得分可以包括每個通知的加權(quán)等級，其可以在同一比例上被評分并且用于分配優(yōu)先級。在一些實施例中，未決的或潛在的通知可以基于加權(quán)的排序或得分在邏輯上被組織成隊列。此外，在一些實施例中，在發(fā)生變化(諸如新的通知或新的未處理事件、被消除的通知(或與通知相對應的處理了的事件)、新的上下文信息、或者指示用戶可用性的變化或者緊急性或重要性的變化的其他用戶數(shù)據(jù))，那么潛在的或未決的通知可以被重新評分、重新排序或以其他方式重新排列優(yōu)先級。在一些實施例中，通知邏輯被更新或以其他方式被生成，以反映優(yōu)先級。
例如，假設目前有四個與用戶相關聯(lián)的未處理事件：a)來自用戶的配偶的未接來電；b)來自用戶的老板的未處理的電子郵件；c)對用戶的母親的錯過的事件模式呼叫(即，用戶具有在某一時間呼叫她的母親的模式，但是這次尚未這樣做)；以及d)用戶的汽車保險即將到期。未處理事件中的每一個未處理事件與用于在呈現(xiàn)關于未處理事件的通知時使用的通知內(nèi)容相關聯(lián)，并且通知內(nèi)容包括通知邏輯?；诰o急性或重要性和/或用戶可用性(或者基于指示用戶行為和當前信息或關于用戶的所感測的信息的用戶數(shù)據(jù)、可以包括諸如眾包數(shù)據(jù)的來自其他用戶的信息的上下文信息)，通知邏輯被創(chuàng)建以指示與四個未處理事件相對應的通知的適當性。以這種方式，可以例如按照b、c、d、a的順序?qū)νㄖM行排序或以其他方式對通知排列優(yōu)先級。
應當指出，通知被呈現(xiàn)給用戶的順序不一定與未決的或潛在的通知的排序或優(yōu)先級相對應。例如，假設用戶具有兩個未處理事件：(1)來自其配偶的未接來電，以及(2)續(xù)訂用戶的汽車保險，其當天到期。在該示例中，未處理事件(2)可以被確定為比未處理事件(1)更重要或更緊急，因為用戶的汽車保險將在當天到期。因此，未處理事件(2)可以被評分或排序為具有比未處理事件(1)更高的優(yōu)先級。然而，假設用戶正在駕駛?？梢源_定用戶不可用于處置未處理事件(2)，因為用戶不在他的計算機前。但是用戶可用于處置未處理事件(1)，因為用戶可以在駕駛時打電話。因此，用戶在駕駛時可以被呈現(xiàn)給其配偶回電話的通知，并且諸如在確定用戶在他的計算機旁時，用戶可以被呈現(xiàn)續(xù)訂他的保險的通知。備選地，在實施例中，可以更新通知邏輯，以反映基于用戶的可用性，未處理事件被重新排序或重新排列優(yōu)先級，使得當用戶正在駕駛時，未處理事件(1)具有比未處理事件(2)更高的優(yōu)先級。
在一些實施例中，通知邏輯可以基于用戶偏好或設置來確定，用戶偏好或設置可以由用戶明確地提供或者從由其他用戶提供的用戶模式或設置來推斷。例如，從上述示例，通知邏輯可以指定不在下午6:00-7:00之間呈現(xiàn)通知，因為用戶在此時間期間不太可能做出響應(可能是因為用戶正在吃晚飯)。以這種方式，本發(fā)明的一些實施例是自適應的，并且可以從用戶響應或用戶設置中學習。類似地，用戶可以調(diào)整與個人助理應用或服務相關聯(lián)的通知設置，使得在某些時間期間(諸如，在會議期間或在半夜)只有最重要或緊急的未處理事件引起用戶的注意。例如，在一個實施例中，用戶可以基于未處理事件的類別、緊急性級別或重要性級別(諸如，通過如前所述的那樣指定閾值)、可用性或其他上下文信息來指定通知設置。
在一些實施例中，通知邏輯可以包括用于問詢用戶以確定用戶偏好的內(nèi)容。例如，可以通過選項來提示用戶，以確定何時被提醒未處理事件或某些類別的未處理事件，諸如這種提示：“當個人助理應用確定是(a)未來的3小時、(b)未來的24小時、(c)下個星期之內(nèi)的最佳時間時提醒我；(d)不管是否方便，隨時提醒我；(e)僅當個人助理應用確定是方便時隨時提醒我。
繼續(xù)圖2，事件監(jiān)測器280和通知引擎260的一些實施例使用統(tǒng)計和機器學習技術。特別地，這樣的技術可以用于確定與用戶相關聯(lián)的模式信息，諸如事件模式、用戶響應模式、某些類型的事件、用戶偏好以及未處理事件、緊急性、重要性、用戶可用性及與未處理事件相關聯(lián)的其他通知內(nèi)容。例如，使用眾包數(shù)據(jù)，基于確定其他用戶對其中存在關鍵字或上下文特征的事件如何做出響應或反應，本發(fā)明的實施例可以學習將那些關鍵詞或其他上下文特征(諸如，聯(lián)系人實體與用戶之間的關系)與更高級別的重要性或緊急性相關聯(lián)。在一個實施例中，應用模式識別、模糊邏輯、聚類或類似的統(tǒng)計和機器學習技術。
示例系統(tǒng)200還包括呈現(xiàn)部件218，呈現(xiàn)部件218通常負責基于由通知引擎260確定的通知內(nèi)容來向用戶呈現(xiàn)通知和相關內(nèi)容。呈現(xiàn)部件218可以包括在用戶設備上、跨多個用戶設備或在云中的一個或多個應用或服務。例如，在一個實施例中，呈現(xiàn)部件218跨與用戶相關聯(lián)的多個用戶設備管理向該用戶呈現(xiàn)通知內(nèi)容。基于通知邏輯和用戶數(shù)據(jù)，呈現(xiàn)部件218可以確定在哪個或哪些用戶設備上呈現(xiàn)通知，以及呈現(xiàn)的上下文，包括如何(或以何種格式和多少內(nèi)容，這可以取決于用戶設備或上下文)呈現(xiàn)、何時呈現(xiàn)以及哪些補充內(nèi)容與其一起被呈現(xiàn)。特別地，在一些實施例中，呈現(xiàn)部件218將通知邏輯應用于所感測的用戶數(shù)據(jù)和上下文信息，以便確定通知的呈現(xiàn)。
在一些實施例中，呈現(xiàn)部件218生成與通知相關聯(lián)的用戶界面特征。這樣的功能可以包括界面元素(諸如，圖形按鈕、滑塊、菜單、音頻提示、警報、鬧鐘、振動、彈出窗口、通知欄或狀態(tài)欄項、應用程序內(nèi)通知、或用于與用戶進行接口的其他類似功能)、問詢和提示。例如，呈現(xiàn)部件218可以向用戶問詢關于處理未處理事件的重要性、緊急性或用戶偏好，諸如詢問用戶“將來繼續(xù)示出類似的通知嗎？”或“請從1-5...來評估對該事件進行響應的重要性”。呈現(xiàn)部件218的一些實施例捕獲用戶對通知的響應或與通知相關聯(lián)的用戶活動，并向事件響應分析器288提供這種信息。
如前所述，在一些實施例中，與呈現(xiàn)部件218結(jié)合地操作的個人助理服務或應用確定何時以及如何呈現(xiàn)通知。在這樣的實施例中，通知內(nèi)容可以被理解為是對呈現(xiàn)部件218(和/或個人助理服務或應用程序)何時以及如何呈現(xiàn)通知的建議，其可以被個人助理應用或呈現(xiàn)部件218覆蓋。
此外，呈現(xiàn)部件218的一些實施例包括用于管理針對用戶的未決通知的功能，并且可以基于緊急性或重要性、用戶可用性、用戶偏好或其他上下文信息來對呈現(xiàn)哪些通知排列優(yōu)先級。備選地，在其他實施例中，通知引擎260或通知服務或應用管理針對用戶的未決通知，并且可以對呈現(xiàn)哪些通知排列優(yōu)先級。在一些情況下，通知可以單獨地呈現(xiàn)，或者諸如通過類似的重要性、緊急性、上下文或用戶可用性(例如，在用戶啟動他的汽車時，僅要求撥打電話呼叫的未處理事件可以被一起呈現(xiàn)給用戶)而被分組并一起呈現(xiàn)。因此，在一些實施例中，相同或相似類型的通知可以被聚合，并且在一些情況下被優(yōu)先化。使用先前的示例，在啟動他的汽車之后，呈現(xiàn)部件218可以告知用戶“你需要呼叫你的朋友joe和你的母親。你想要呼叫哪個？”
在實施例中，可以將通知作為待辦事項列表呈現(xiàn)給用戶。例如，星期五下班后，呈現(xiàn)部件218(或個人助理服務)可以告知用戶與用戶的朋友或家人有關的未決的未處理事件。但是在星期一上午，呈現(xiàn)部件218(或個人助理服務)告知用戶與工作有關的未決的未處理事件。
示例系統(tǒng)200還包括存儲裝置225。存儲裝置225通常存儲信息，所述信息包括在本文所描述的本發(fā)明的實施例中使用的數(shù)據(jù)、計算機指令(例如，軟件程序指令、例程或服務)和/或模型。在實施例中，存儲裝置225包括數(shù)據(jù)存儲庫(或計算機數(shù)據(jù)存儲器)。此外，雖然被描繪為單個數(shù)據(jù)存儲部件，但是存儲裝置225可以被實施為一個或多個數(shù)據(jù)存儲庫，或者可以在云中。
在實施例中，存儲裝置225存儲一個或多個用戶簡檔240，在圖2中說明性地提供了用戶簡檔240的示例實施例。示例用戶簡檔240可以包括與特定用戶或在一些情況下與一類別的用戶相關聯(lián)的信息。如所示的，用戶簡檔240包括(一個或多個)事件數(shù)據(jù)242、(一個或多個)事件模式243、(一個或多個)事件響應模型244、(一個或多個)可用性模型246、(一個或多個)用戶賬戶和活動數(shù)據(jù)248以及通知250。存儲在用戶簡檔240中的信息可以可用于示例系統(tǒng)200的例程或其他部件。
(一個或多個)事件數(shù)據(jù)242通常包括涉及與用戶相關聯(lián)的事件的信息，并且可以包括關于由事件監(jiān)測器280確定的事件的信息、上下文信息，并且還可以包括眾包數(shù)據(jù)。(一個或多個)事件模式243通常包括關于與用戶相關聯(lián)的所確定的事件模式的信息；例如，指示用戶在每個星期日呼叫他的母親的模式。存儲在(一個或多個)事件模式243中的信息可以從事件模式標識器282來確定。(一個或多個)事件響應模型244通常包括由事件響應分析器288確定的與特定用戶(或類似用戶)如何響應事件有關的響應信息。如結(jié)合事件響應分析器288所描述的，在一些實施例中，可以確定一個或多個響應模型。響應模型可以基于規(guī)則或設置、事件的類型或類別、上下文特征或變量(諸如，聯(lián)系人與用戶之間的關系)，并且可以諸如從如先前的用戶響應之類的用戶歷史和/或來自其他用戶的響應中學習。
(一個或多個)可用性模型246通常包括可用性模式信息以及與由可用性確定器264確定的用戶可用性有關的其他信息?？捎眯阅Ｐ偷母郊蛹毠?jié)結(jié)合通知引擎260來描述。(一個或多個)用戶賬戶和活動數(shù)據(jù)248通常包括從用戶數(shù)據(jù)收集部件214收集的用戶數(shù)據(jù)(其在一些情況下可以包括與特定用戶相關的眾包數(shù)據(jù))或關于用戶的其他語義知識。特別地，(一個或多個)用戶賬戶和活動數(shù)據(jù)248可以包括：關于用戶電子郵件、文本、即時消息、呼叫和其他通信的數(shù)據(jù)；社交網(wǎng)絡賬戶和數(shù)據(jù)，諸如新聞推送；在線活動；日歷、預約或可能與確定未處理事件有關的其他用戶數(shù)據(jù)；用戶可用性；以及重要性、緊急性或通知邏輯。(一個或多個)用戶賬戶和活動數(shù)據(jù)248的實施例可以跨一個或多個數(shù)據(jù)庫、知識圖譜或數(shù)據(jù)結(jié)構(gòu)存儲信息。
(一個或多個)通知250通常包括關于與用戶相關聯(lián)的未決通知的數(shù)據(jù)，其可以包括與一個或多個未處理事件相對應的通知內(nèi)容。在一些實施例中，(一個或多個)通知250包括與尚未呈現(xiàn)給用戶的通知或者可能不提供給用戶的補充內(nèi)容相對應的數(shù)據(jù)。(此外，在一些實施例中，(一個或多個)通知250還可以包括關于先前未決通知的信息。)
現(xiàn)在轉(zhuǎn)到圖3，描述了基于未處理事件而生成的通知的一個示例。在該示例中，未處理事件包括用戶需要續(xù)訂其保險單。圖3描繪了用戶設備(未示出)的具有用于提供與示例通知相關聯(lián)的內(nèi)容的多個元素的示例用戶界面，其總體上被稱為用戶界面300。在該示例中，用戶界面300包括用戶設備(諸如智能電話)上的圖形用戶界面。示例用戶界面300描繪了根據(jù)本發(fā)明的實施例的被呈現(xiàn)給用戶的通知350的一個示例。示例通知包括用于提醒用戶續(xù)訂其汽車保險的通知消息310。
繼續(xù)總體上參考圖3，通知內(nèi)容可以由通知引擎260確定，并且由呈現(xiàn)部件218使用，以用于準備示例通知350。在一個實施例中，由通知引擎260生成的通知內(nèi)容可以被格式化為標記語言、被標記或被索引，以指示內(nèi)容的具體部分將如何由呈現(xiàn)部件218使用。例如，在一個實施例中，關于通知350，通知內(nèi)容可以包括標記的通知消息310，諸如“<注意>該續(xù)訂您的汽車保險了<注意>”?？梢砸灶愃频姆绞綐酥净驑擞浲ㄖ獌?nèi)容的其他部分，以便指示應如何應用通知內(nèi)容數(shù)據(jù)和/或通知邏輯。
在實施例中，通知引擎260可以確定以下信息，其可以用于生成與示例通知350相對應的通知內(nèi)容。這里，所確定的未處理事件是用戶需要續(xù)訂她的汽車保險。對于該示例，假設有兩個錯過的通信事件(其可以由未處理事件檢測器284檢測)，包括11月8日的來自用戶的保險公司的電子郵件和11月30日的來自保險代理人的呼叫。上下文信息(包括提取自錯過的通信的信息，或從提取自錯過的通信的信息中推斷的信息)可以包括例如：(a)來自與保險公司相關聯(lián)的實體的錯過的通信的數(shù)目；(b)汽車保險單號，以及保險公司是redstate；(c)該保險于12/31日到期；(d)6個月的續(xù)期費用為650美元；以及(e)關于用戶的汽車和駕駛歷史的細節(jié)，包括用戶生活和工作的地點。
由通知引擎260生成的通知內(nèi)容可以包括與未處理事件相關聯(lián)的重要性級別或緊急性級別(諸如，高重要性和緊急性(或數(shù)值，諸如在1至10的數(shù)值范圍上的9.1))。這里，所確定的重要性級別可以保持不變，但是緊急性級別可以基于保險單到期日期的接近而增加(這可以由通知邏輯來指定)。通知內(nèi)容還包括可用性信息，諸如當前的和預測的用戶可用性。在該示例中，假設用戶正在公園里吃午飯，并且只帶了她的智能手機，那么具有可以指示用戶的可用性(或者更具體地，針對用于處理未處理事件的特定活動的用戶能力)的從1到10的對應得分(其中1是不可用)的可用性信息的一個示例實施例，如下：閱讀電子郵件(8)，寫電子郵件(5)，電話呼叫(10)，響應sms消息(9)，訪問網(wǎng)站(7)，閱讀文檔(7)，以及打印和簽署文檔(1)。所預測的可用性可以包括指示以下項的信息：用戶可能將在二十分鐘內(nèi)返回其辦公室并將具有對計算機的訪問；用戶可能將在下午6:00到6:30開車回家；用戶有時在下午7:00與9:00之間在xbox上玩游戲；以及用戶經(jīng)常在下午8:00與10:00之間響應電子郵件并瀏覽因特網(wǎng)。應當注意，這僅是與未處理事件相對應的可用性信息的一部分的一個示例；結(jié)合可用性確定器264來描述其他實施例。
繼續(xù)汽車保險的示例，由通知引擎260生成的通知內(nèi)容還可以包括補充內(nèi)容。這里，除了其他以外，補充內(nèi)容可以包括：對用戶保險單的改變，用戶是否續(xù)訂其當前保險單，來自其他保險公司的對類似保險單的報價(其可以由補充內(nèi)容生成器266使用來自用戶的當前保險單和用戶數(shù)據(jù)的上下文信息來確定)，用戶的當前保險公司和其他保險公司的聯(lián)系信息和/或網(wǎng)站地址，或者可能潛在地有幫助的其他相關信息，諸如可以可用于用戶的折扣或獎勵，或者來自用戶的社交聯(lián)系人的信息，諸如例如“你的鄰居bob使用bluestate保險”或者“你的facebook朋友liz喜歡“gecko保險””。
使用包括先前描述的信息的通知內(nèi)容，呈現(xiàn)部件(諸如，呈現(xiàn)部件218)或者個人助理應用或服務可以生成并向用戶提供一個或多個通知，諸如通知350。如果用戶的可用性指示用戶可以與用戶設備交互，那么可以向用戶提供示例通知350。如果不是這種情況，諸如在用戶正在駕駛汽車的情況下，那么基于相同的通知內(nèi)容，可以生成通知并且以語音提示的格式向用戶呈現(xiàn)通知，諸如“該續(xù)訂您的汽車保險了。您要續(xù)訂當前的保險單嗎？…您想要我安排與您的保險代理人通話嗎？...”備選地，除非確定緊急性級別非常高，否則可以在用戶的可用性指示用戶至少可以通過某個用戶設備瀏覽或讀取信息的稍后時間，向用戶呈現(xiàn)針對該未處理事件(續(xù)訂汽車保險)的通知。在該示例中，除非用戶正在玩xbox，否則在下午8:00與10:00之間在用戶數(shù)據(jù)指示用戶在家之后，可以向用戶提供通知350。(或者備選地，在未處理事件被確定為具有足夠的重要性或緊急性的情況下，可以以xbox圖形用戶界面上的彈出通知向用戶提供提醒。)
參考圖3，用戶界面300包括通知350，并且還可以包括一個或多個其他控制選項，諸如項目設置控制項340或查看更多細節(jié)項330。示例通知350包括通知用戶“該續(xù)訂您的汽車保險單了”的通知消息310。通知350還包括用戶響應選項325a-325e及針對每個響應選項的對應描述320a-320e。通知響應選項325a-325e與用于處理未處理事件的一個或多個任務或用戶動作相對應。(在一些實施例中以及在一些情況下，通知不包括響應選項。)在該示例中，響應選項325a向用戶提供續(xù)訂其當前保險單的選項，并且包括用于參考用戶與redstate保險的當前保險單的鏈接。另一響應選項325b向用戶提供安排與用戶的保險代理人通話的選項。當選擇該響應時，通知引擎260可以生成針對關于該呼叫的未來通知的通知內(nèi)容，該未來通知要在便于撥打該呼叫的未來時間呈現(xiàn)給用戶。響應選項325c向用戶提供來自其他保險公司的報價，其可以由補充內(nèi)容生成器266和用戶數(shù)據(jù)來確定。響應選項325d向用戶給出消除通知并稍后提醒的選項，稍后提醒諸如在可用性確定器264確定用戶方便響應的未來時間。在一些實施例中，在用戶選擇該選項(響應于任何通知)的情況下，當前的用戶數(shù)據(jù)和上下文信息可以被捕獲，并且用于確定用戶為何不響應當時呈現(xiàn)的通知，使得未來的可用性確定更精確。
最后，示例響應選項325e使得用戶能夠指示未處理事件已經(jīng)被處置。在一些實施例中，類似的響應選項可以使得用戶能夠指示“這不再與我有關?！比缃Y(jié)合響應選項325d所描述的，在一些實施例中，在用戶選擇該選項(響應于任何通知)的情況下，當前的用戶數(shù)據(jù)和上下文信息可以被捕獲并且用于確定未處理事件是如何以及何時被處理的，或者為何它不再與用戶有關，使得未來的通知可以針對更好的相關性來定制。
諸如示例通知350的通知可以包括一個或多個控制選項，諸如項目設置控制項340或查看更多細節(jié)項330。設置控制340使得用戶能夠配置諸如先前所描述的設置；例如，與通知相關聯(lián)的設置、要監(jiān)測的事件、靈敏度或閾值(諸如何時通知用戶)、通知的優(yōu)選格式或其他用戶偏好。在一些實施例中，設置控制項340使得用戶能夠查看和/或修改默認設置或?qū)W習的設置。查看更多細節(jié)項330向用戶提供與響應于未處理事件而生成的通知內(nèi)容有關的反饋信息。例如，這里，查看詳細信息項330可以包括：關于11月8日錯過的電子郵件和11月30日錯過的呼叫的信息；緊急性、重要性或可用性信息；用于生成補充內(nèi)容的來源；或與通知內(nèi)容有關的其他信息。
在一些實現(xiàn)方式中，被呈現(xiàn)給用戶的具體通知內(nèi)容可以使用一個或多個內(nèi)容模板或內(nèi)容卡來確定。特別地，內(nèi)容卡可以包括一個或多個靜態(tài)內(nèi)容字段和/或一個或多個動態(tài)內(nèi)容字段。靜態(tài)內(nèi)容字段對應于具有每次呈現(xiàn)內(nèi)容卡時被顯示的對應內(nèi)容的內(nèi)容字段。動態(tài)內(nèi)容字段對應于具有可以在內(nèi)容卡的呈現(xiàn)之間變化的對應內(nèi)容的內(nèi)容字段。因此，靜態(tài)內(nèi)容字段的示例可以包括圖3中的靜態(tài)內(nèi)容字段325a-325e。動態(tài)內(nèi)容字段的示例包括動態(tài)內(nèi)容字段320a-320e。
現(xiàn)在轉(zhuǎn)到圖4，提供了流程圖，該流程圖圖示了用于向用戶提供與未處理事件有關的個性化的通知內(nèi)容的一個示例方法400。方法400以及本文所描述的其他方法的每個框或步驟包括可以使用硬件、固件和/或軟件的任何組合來執(zhí)行的計算過程。例如，各種功能可以由執(zhí)行存儲器中存儲的指令的處理器來實施。這些方法還可以被實現(xiàn)為存儲在計算機存儲介質(zhì)上的計算機可用指令。僅舉幾個例子，這些方法可以由獨立應用、服務或托管服務(獨立或與另一托管服務組合)或到另一產(chǎn)品的插件來提供。
在步驟410處，標識未處理事件。如本文中所述，未處理事件可以指代用戶尚未響應、處置或以其他方式處理的通信相關事件或其他事件。步驟410的實施例可以基于諸如本文中所描述的所監(jiān)測的事件數(shù)據(jù)、用戶數(shù)據(jù)或其他傳感器數(shù)據(jù)、事件模式、和/或響應信息來檢測未處理事件。在一些實施例中，未處理的事件可以通過可能指示未處理事件的觸發(fā)情形(諸如，未應答的來電)來標識。在一些實施例中，未處理事件可以通過分析對類似事件的典型用戶響應模式來確定。用戶響應模式可以與當前或近期的用戶活動數(shù)據(jù)相比較，以便確定用戶是否可能已經(jīng)(或可能)響應特定事件。在一些實施例中，步驟410可以由諸如圖2中所描述的未處理事件檢測器部件來執(zhí)行。結(jié)合圖2中的未處理事件檢測器部件284提供了標識未處理事件的進一步細節(jié)。
在步驟420處，確定與未處理事件有關的上下文信息。上下文信息可以包括與事件、響應或事件之后的用戶活動(其可以指示用戶響應活動)相關聯(lián)的上下文特征或變量，并且可以從用戶數(shù)據(jù)(或傳感器數(shù)據(jù))或從用戶數(shù)據(jù)確定的模式信息中來確定。在一些實施例中，這包括來自多個用戶的用戶數(shù)據(jù)。
在實施例中，步驟420包括接收用戶數(shù)據(jù)以及在一些情況下解析用戶數(shù)據(jù)，以及標識和提取上下文特征或變量的集合，其可以包括關鍵字。在一些實施例中，上下文信息還可以包括從用戶數(shù)據(jù)推斷的數(shù)據(jù)和/或與在步驟410中所標識的未處理事件相關聯(lián)的置信度得分、方差得分或概率，諸如事件未被處理的可能性。在一些實施例中，步驟420可以由諸如圖2中所描述的上下文信息提取器來執(zhí)行。結(jié)合圖2中的上下文信息提取器286提供了確定上下文信息的進一步細節(jié)。
在步驟430處，確定與未處理事件相對應的緊急性級別。在一些實施例中，緊急性級別包括重要性級別，或者包括與未處理事件的緊急性及未處理事件的重要性相對應的信息，并且可以被實施為得分或數(shù)值。步驟430的實施例可以基于以下項來確定緊急性級別：在步驟420中確定的上下文信息、來自用戶或其他類似用戶的響應信息、其他相關的未處理事件、或者從用戶數(shù)據(jù)確定的其他用戶數(shù)據(jù)或模式信息，如結(jié)合圖2中的緊急性/重要性確定器262所描述的。
步驟430的一些實施例包括基于用戶或其他用戶對與步驟410中確定的未處理事件類似的事件的響應來確定緊急性級別。類似的事件可以基于事件間的共同變量或上下文特征(從步驟420中確定)來確定。以這種方式，方法400的這樣的實施例(經(jīng)由步驟430)可以學習基于對類似事件的響應來將上下文特征與緊急性或重要性相關聯(lián)。步驟430的一些實施例還包括與該步驟中確定的緊急性級別相關聯(lián)的概率或置信度，并且概率或置信度在某些情況下可以用于對被呈現(xiàn)給用戶的通知排列優(yōu)先級。
在步驟430的一些實施例中，先前確定的緊急性級別可以通過步驟430基于上下文信息的變化、用戶響應信息、新檢測到的用戶模式、與步驟410中確定的已經(jīng)標識的未處理事件相關的新標識的未處理事件、或其他用戶數(shù)據(jù)來更新。例如，在未處理事件與截止日期相關聯(lián)的情況下，與未處理事件相對應的緊急性級別可以隨著截止日期的臨近而增加。類似地，在來自老板的未響應電子郵件之后的來自老板的未接來電可以指示用于響應電子郵件的更高的緊急性級別。在一些實施例中，步驟430可以由諸如圖2中所描述的緊急性/重要性確定器部件來執(zhí)行。結(jié)合圖2中描述的緊急性/重要性確定器262提供了確定緊急性級別的進一步細節(jié)。
在步驟440處，確定針對用戶用于處理在步驟410中標識的未處理事件的可用性模型。步驟440的實施例基于在步驟430中確定的緊急性級別來確定針對用戶的一個或多個可用性模型，并且在一些實施例中基于在步驟420中確定的上下文數(shù)據(jù)以及用戶數(shù)據(jù)(或傳感器數(shù)據(jù))或從用戶數(shù)據(jù)(在一些實施例中，包括來自其他用戶的用戶數(shù)據(jù))確定的模式信息來確定用戶的一個或多個可用性模型?？捎眯阅Ｐ涂梢园ㄓ糜陧憫谖刺幚硎录漠斍坝脩艨捎眯院?或預測的可用性，并且可以包括部分地基于用戶實施與響應未處理事件相關聯(lián)的動作或任務的能力的可用性得分的集合。在一些實施例中，可用性模型表示基于用戶何時最可能響應關于特定事件的通知而推斷的用戶可用性信息。此外，先前確定的針對用戶的可用性模型可以通過步驟440基于上下文信息或用戶數(shù)據(jù)的所確定的變化來更新，包括基于在步驟430中確定的對緊急性級別或重要性級別的更新來更新。
在步驟440的一些實施例中，基于用戶將遵循一個或多個用戶模式的可能性來確定可用性模型。用于在這些用戶模式內(nèi)實施動作或任務的用戶能力可以基于在這些模式的先前實例期間所檢測到的用戶的(或其他用戶的)活動來確定。在一些實施例中，步驟440可以由諸如圖2中所描述的可用性確定器來執(zhí)行。結(jié)合圖2中描述的可用性確定器264提供了確定可用性模型的進一步細節(jié)。
在步驟450處，基于緊急性級別、可用性模型和未處理事件來生成通知內(nèi)容。在一些實施例中，通知內(nèi)容還可以基于在步驟420中確定的上下文信息來生成。通知內(nèi)容可以用于生成通知，和/或在被確定為可能更便于用戶響應未處理事件的未來時間和/或在用戶可能將具有適當?shù)仨憫哪芰Φ那闆r下，向用戶提供通知，并且在一些情況下，可以包括提供與協(xié)助用戶處理事件相關的附加內(nèi)容。此外，在一些情況下，通知內(nèi)容可以指定針對通知的一種或多種格式(即，可以如何向用戶提供(一個或多個)通知)以及通知呈現(xiàn)的定時，其可以基于與未處理事件相關聯(lián)的上下文信息(包括例如重要性或緊急性)來確定。在一些實施例中，步驟450可以由諸如圖2中所描述的通知引擎部件來執(zhí)行。結(jié)合圖2中的通知引擎260以及結(jié)合圖3描述的示例提供了與在步驟450中生成通知內(nèi)容有關的進一步細節(jié)。
在一些實施例中，在步驟450中生成的通知內(nèi)容包括通知邏輯。通知邏輯可以基于步驟440中確定的可用性、步驟430中確定的未處理事件的緊急性或重要性、或者諸如當前用戶信息或在步驟420中確定的上下文信息之類的其他用戶數(shù)據(jù)來生成。通知邏輯可以指定規(guī)則、條件、約束、時間(包括未來時間或時間窗口)、相對于其他通知的優(yōu)先級、和/或用于向用戶通知未處理事件的其他參數(shù)、要被包括在通知中的內(nèi)容以及指定或推薦用于呈現(xiàn)(一個或多個)通知的格式的邏輯。此外，在一些實施例中，如本文中所描述的，通知邏輯可以從用戶偏好或所確定的模式來確定，諸如指定除非重要性超過用戶指定的級別否則不在夜間呈現(xiàn)通知的邏輯。結(jié)合圖2中的通知邏輯生成器268提供了與通知邏輯有關的附加細節(jié)。
在一些實施例中，通知內(nèi)容可以包括用于協(xié)助用戶處理未處理事件的補充內(nèi)容。如本文所述，補充內(nèi)容可以包括有幫助的信息，諸如相關的上下文信息；來自其他數(shù)據(jù)源的信息；提示或貼士，其可以基于從其他用戶對類似事件的響應中得到的信息；推薦或建議；和/或用戶為了處理事件而需要采取的動作或步驟。在一些情況下，補充內(nèi)容還可以包括關于用戶為了完成未處理事件已經(jīng)采取的動作和/或還有待完成哪些步驟的信息。在一些實施例中，補充內(nèi)容可以基于以下來確定：使用關鍵字和模式分析對在步驟420中確定的未處理事件的上下文信息的語義理解，以及來自用戶的先前響應的響應信息或來自響應類似事件的其他用戶的響應信息，其可以包括其他用戶響應類似事件的用戶活動歷史(例如，瀏覽歷史、采取的動作等)。結(jié)合圖2中的通知邏輯生成器268描述了與補充內(nèi)容有關的附加細節(jié)。
在步驟460處，根據(jù)在步驟450中生成的通知內(nèi)容來向用戶呈現(xiàn)通知。在步驟460的實施例中，可以基于通知內(nèi)容來向用戶提供關于未處理事件和相關內(nèi)容的通知。步驟460的實施例可以由諸如圖2中所描述的呈現(xiàn)部件218的呈現(xiàn)部件來執(zhí)行。在一些實施例中，步驟460包括基于通知內(nèi)容中所提供的信息來生成通知，通知內(nèi)容中所提供的信息包括關于未處理事件的信息、未處理事件的緊急性級別或重要性級別以及與未處理事件相關聯(lián)的用戶可用性。此外，通知可以基于通知內(nèi)容中所提供的通知邏輯來生成，并且可以包括通知內(nèi)容中所提供的補充內(nèi)容。步驟460的一些實施例包括將通知內(nèi)容傳達到一個或多個用戶設備，在一個或多個用戶設備中應用或服務使用通知內(nèi)容來生成和呈現(xiàn)通知。備選地，在一些實施例中，通知內(nèi)容可以在步驟450中在用戶設備上生成，并且在步驟460中在用戶設備上呈現(xiàn)。
在一些實施例中，基于通知邏輯和用戶數(shù)據(jù)，步驟460可以確定在哪個(哪些)用戶設備上呈現(xiàn)通知以及呈現(xiàn)的上下文，包括如何(或以何種格式和多少內(nèi)容，這可以取決于用戶設備或上下文)呈現(xiàn)、何時呈現(xiàn)以及應當隨其呈現(xiàn)哪個(或多少)補充內(nèi)容。特別地，步驟460的一些實施例將通知邏輯應用于所感測的用戶數(shù)據(jù)和上下文信息，以便確定通知及其呈現(xiàn)。
步驟460的一些實施例還包括生成與通知相關聯(lián)的用戶界面特征。這樣的功能可以包括界面元素(諸如，圖形按鈕、滑塊、菜單、音頻提示、警報、鬧鐘、振動、彈出窗口、通知欄或狀態(tài)欄項、應用程序內(nèi)通知或用于與用戶進行接口的其他類似特征)、問詢或提示。此外，步驟460的一些實施例捕獲對通知的用戶響應或與所呈現(xiàn)的通知相關聯(lián)用戶活動，以用于進一步個性化被提供給用戶的未來通知。結(jié)合圖2中的呈現(xiàn)部件218和通知引擎260以及結(jié)合圖3描述的示例提供了與在步驟460中呈現(xiàn)通知有關的附加細節(jié)。
現(xiàn)在參考圖5，提供了流程圖，該流程圖圖示了用于向用戶提供與未處理事件有關的個性化通知內(nèi)容的一個示例方法500。在步驟510處，方法500包括接收與用戶相關聯(lián)的未處理事件的指示以及對應于未處理事件的上下文信息。例如，指示和上下文信息可以從事件監(jiān)測器280(圖2)接收，事件監(jiān)測器280(圖2)可以作為云上的云服務運行，或者可以是用戶設備上的本地服務。在步驟520處，方法500包括確定與步驟510中所指示的未處理事件相對應的緊急性級別。步驟520的實施例可以如方法400(圖4)的步驟430中所述的那樣執(zhí)行。例如，緊急性/重要性確定器262可以基于步驟510中所接收的上下文信息來確定緊急性級別和/或重要性級別。
在步驟530處，方法500包括確定針對用戶響應步驟510中所指示的未處理事件的可用性。步驟530的實施例可以如方法400(圖4)的步驟440中所述的那樣執(zhí)行，其中針對用戶確定一個或多個可用性模型。在一些實施例中，可以如結(jié)合可用性確定器264所描述的那樣來確定步驟530中的可用性。在步驟530的實施例中，所確定的可用性可以包括用于響應未處理事件的當前用戶可用性和/或預測的可用性，并且在一些實施例中可以包括與用戶實施與響應未處理事件相關聯(lián)的動作或任務的能力相對應的可用性得分集合或其他信息。
在步驟540處，方法500包括基于緊急性級別、可用性以及未處理事件的指示來生成通知內(nèi)容。步驟540的實施例可以如方法400(圖4)的步驟450中所述的那樣執(zhí)行。在步驟550處，方法500包括向用于向用戶呈現(xiàn)內(nèi)容的服務提供步驟540中所生成的通知內(nèi)容。特別地，接收在步驟550中所提供的通知內(nèi)容的用戶設備上運行的服務可以呈現(xiàn)通知。通知的呈現(xiàn)可以基于通知內(nèi)容中的諸如通知邏輯的信息、其他用戶數(shù)據(jù)及特定用戶設備的特性。
例如，云服務可以向服務提供上述的通知內(nèi)容，該服務可以在包括云服務的云系統(tǒng)外部。該服務可以是第三方服務，并且可以在用戶設備102a上運行。更具體地，服務可以是應用，諸如通知應用、調(diào)度程序或日歷應用、通信應用、或其他類型的應用或應用程序。應用可以包含用于與云服務通信的api。這可以包括請求數(shù)據(jù)和/或請求數(shù)據(jù)的一個或多個部分。作為請求的備選方案，例如，當檢測到未處理事件時，數(shù)據(jù)中的至少一些可以被推送到應用。應用可以訂閱以接收這些推送消息。api還可以提供用于解譯所接收的數(shù)據(jù)(例如，所推薦的動作和上下文信息)的功能，以及可能用于至少部分地幫助內(nèi)容的呈現(xiàn)的功能。
此外，雖然步驟550參考了單個服務，但是也可以將相同或不同的通知內(nèi)容提供給其他服務。因此，每個服務可以基于未處理事件來接收通知內(nèi)容，而不必分別執(zhí)行方法500的步驟510至步驟540。在一些情況下，那些其他服務中的一些服務可以在同一用戶設備上。此外，在步驟550由服務器執(zhí)行的情況下，在一些情況下，要由用戶設備上的多個服務來使用的信息僅需要被發(fā)送給用戶設備一次以。
在一些情況下，可以使用相同的云系統(tǒng)和/或云服務來執(zhí)行方法500，以便向可以在很多不同的用戶設備上運行的多個服務提供通知內(nèi)容。如此，系統(tǒng)200可以通過集中事件監(jiān)測功能而節(jié)省顯著的處理、帶寬、存儲和計算資源。例如，用戶數(shù)據(jù)收集部件214可以累積針對多個用戶的用戶數(shù)據(jù)和解譯性數(shù)據(jù)，使得每個用戶設備不需要單獨且冗余的數(shù)據(jù)收集和存儲。另外，通過與緊密綁定到用戶的用戶設備解除關聯(lián)，可以使處理和存儲用戶簡檔數(shù)據(jù)變得更安全。
現(xiàn)在轉(zhuǎn)到圖6，提供了流程圖，該流程圖圖示了用于向用戶提供與未處理事件有關的個性化通知內(nèi)容的一個示例方法600。在步驟610處，接收未處理事件的指示。在實施例中，指示可以從事件監(jiān)測器280來接收，并且可以使用諸如圖2中所描述的通知引擎260來接收。未處理事件可以基于所監(jiān)測的事件數(shù)據(jù)、響應信息和/或用戶數(shù)據(jù)或其他傳感器數(shù)據(jù)來確定，這些數(shù)據(jù)可以由用戶數(shù)據(jù)收集部件214來提供并且可以包括從一個或多個數(shù)據(jù)源(例如，圖1中的數(shù)據(jù)源104a-104n)感測或確定的信息，包括用戶數(shù)據(jù)和/或眾包信息。在一些實施例中，事件監(jiān)測器280可以使用諸如圖2中所描述的未處理事件檢測器284來標識未處理事件。此外，步驟610的一些實施例可以如方法400(圖4)的步驟410中所述的那樣執(zhí)行。在步驟620處，確定與未處理事件有關的上下文信息。步驟620的實施例可以如方法400(圖4)的步驟420中所述的那樣執(zhí)行。
在步驟630處，確定用于向用戶提供與未處理事件有關的通知的第一時間幀。第一時間幀可以包括時間跨度或持續(xù)時間，諸如一定數(shù)目的分鐘、小時、天等，并且可以基于步驟620中所確定的上下文信息來確定。在一些實施例中，第一時間幀基于與未處理事件相對應的緊急性或重要性來確定，緊急性或重要性可以至少部分地基于上下文信息來確定。未處理事件的緊急性或重要性可以使用如附圖中所述的緊急性/重要性確定器262來確定。在一些實施例中，緊急性或重要性可以如方法400(圖4)的步驟430中所述的那樣確定。
在一些實施例中，第一時間幀與用戶可能希望被通知未處理事件的時間跨度相對應。例如，在上下文信息指示特定未處理事件很緊急的情況下，那么時間幀可以是較短的跨度或持續(xù)時間。時間跨度可以是未來時間間隔，或者可以是從當前時間開始并且持續(xù)到未來某個時刻的時間間隔。在未處理事件具有時間限制或截止日期的情況下，諸如在續(xù)訂汽車保險的情況下，那么可以確定時間幀在截止日期之后結(jié)束。
在一些實施例中，時間幀還可以基于用戶的可用性或用戶安排信息來確定，諸如結(jié)合圖2的可用性確定器264所描述的。例如，在用戶在白天期間清醒的情況下，第一時間幀可以被確定為接下來的三個小時。但是，在用戶正在睡覺的情況下，第一時間幀可以被確定為從上午7:30至10:30或者在來自用戶數(shù)據(jù)收集部件214的傳感器信息指示用戶清醒之后的用戶清醒的前三個小時。
在步驟640處，在步驟630中所確定的第一時間幀內(nèi)確定用于向用戶呈現(xiàn)與未處理事件有關的通知的一個或多個時間。一個或多個時間可以是具體的時間點(例如，下午3:59)或時間范圍或時間跨度，并且可以被有條件地指定。例如，一個或多個時間中的第一時間可以被指定為上午7:30與8:00之間(諸如，當用戶開車去上班時)，而第二時間可以被指定為下午5:30與6:00之間(諸如，當用戶開車回家時)。作為另一示例，來自一個或多個時間的第一時間可以是晚上在確定用戶已經(jīng)下班到家之后的前15分鐘。因此，在一些實施例中，步驟640包括確定用于向用戶潛在地呈現(xiàn)與未處理事件有關的通知的具體的未來時間。其可以被“潛在地呈現(xiàn)”，因為可能不滿足條件或者傳感器數(shù)據(jù)可能表明用戶的可用性發(fā)生了變化并且因此不應當此時呈現(xiàn)通知。(在這種情況下，如果已經(jīng)確定了第二時間，那么可以在一個或多個時間中的第二時間處呈現(xiàn)通知。)
在步驟640的一些實施例中，基于用戶的可用性來確定一個或多個時間，用戶的可用性可以如在方法400(圖4)的步驟440中描述的那樣從可用性模型來確定。一個或多個時間中的所確定的具體時間的數(shù)目可以基于步驟630中所確定的時間幀的大小，以及用戶的可用性。例如，如果時間幀較短，并且用戶僅在時間幀的一小部分內(nèi)可用于響應未處理事件，那么可以在步驟640中僅確定一個具體時間。但是在時間幀較長并且在時間幀內(nèi)用戶可能在多于一個時間處具有可用性的情況下，那么可以在步驟640中確定多個時間。此外，在一些實施例中，在步驟640中確定的一個或多個時間可以基于用戶的可用性的所感測或所確定的變化和/或基于底層未處理事件的緊急性或重要性的所確定的變化而更新。
在步驟650處，生成通知內(nèi)容，以用于呈現(xiàn)與未處理事件有關的通知。通知內(nèi)容包括通知邏輯，通知邏輯指定步驟640中所確定的用于潛在地呈現(xiàn)通知的一個或多個時間。在一些實施例中，通知內(nèi)容使用通知引擎260和通知來生成。通知邏輯還可以包括諸如用于呈現(xiàn)通知的條件的附加邏輯或如結(jié)合圖2的通知邏輯生成器268所描述的其他邏輯。結(jié)合方法400(圖4)的步驟450描述了生成預期在步驟650中使用的通知內(nèi)容的附加方面，包括例如使用上下文信息、補充內(nèi)容和通知格式。
在步驟660處，根據(jù)步驟650中所生成的通知內(nèi)容來向用戶呈現(xiàn)通知。步驟660的實施例可以如方法400(圖4)的步驟460中所述的那樣執(zhí)行。
在一些實施例中，方法600包括確定第二時間幀或附加時間幀。例如，在其中用戶在第一時間幀期間沒有響應通知并且對應的未處理事件仍然未決且相關(即，它還沒有到期)的一些情況下，那么可以確定第二時間幀。類似地，在用戶已要求再次被提醒或通知未處理事件(諸如，結(jié)合圖3中的項目320d所描述的)的情況下，那么可以確定第二時間幀。(備選地，在一些實施例中，在步驟640中確定的一個或多個時間中的第二時間可以用于向用戶重新呈現(xiàn)通知。)可以如步驟630中針對確定第一時間幀而描述的那樣確定第二時間幀。在一些實施例中，在確定第二(或附加)時間幀并且第一(或先前確定的)時間幀仍然未決的情況下，第二時間幀可以取代第一時間幀。
現(xiàn)在參考架構(gòu)100、系統(tǒng)200以及方法400、500和600(圖1-圖2和圖4-圖6)，描述用于向用戶提供與未處理通信相關事件有關的個性化通知內(nèi)容的若干附加示例。這些示例可以使用本文中所描述的本發(fā)明的各種實施例來執(zhí)行。在第一示例中，john接收到來自他的老板的電子郵件。他點擊或打開電子郵件。(他的電子郵件軟件將其標記為“已讀”)。但是他計劃稍后閱讀并響應，而他忘記了。本發(fā)明的實施例標識，john總是響應來自他的老板的電子郵件，但是這次尚未響應。關于電子郵件的提醒被呈現(xiàn)給john。
在第二示例中，用戶在他駕駛回家時具有呼叫其父母的模式。在工作日期間，用戶錯過了來自姐姐liz的電話。因為用戶具有在駕駛時呼叫的模式，以及下班后還呼叫家人(他的父母)的模式，在下班回家的路上啟動他的汽車之后，本發(fā)明的實施例可以(經(jīng)由可聽見的公告)呈現(xiàn)他的姐姐liz在白天打過電話的通知，并且詢問用戶現(xiàn)在是否想要呼叫l(wèi)iz或呼叫他的父母？此外，在完成第一呼叫(對他的父母或liz)之后，本發(fā)明的實施例可以確定駕駛期間還剩多少時間，并且如果有足夠的時間，那么可以詢問用戶是否想要呼叫(一個或多個)其他家庭成員。例如，如果用戶首先呼叫他的姐姐，那么他可能被詢問現(xiàn)在是否想要呼叫他的父母。是否有足夠的時間可以基于包括用戶的通勤時間模式的用戶數(shù)據(jù)、當前交通信息來確定，和/或基于諸如用戶家的位置及對他父母和姐妹的平均呼叫持續(xù)時間之類的其他上下文數(shù)據(jù)來確定。如果時間可能不足，那么可以在確定為方便的或根據(jù)用戶的可用性模型而確定的下一時間處向用戶呈現(xiàn)呼叫對方的提醒。
在第三示例中，michelle錯過了來自丈夫的電話并且尚未呼叫他。其他用戶數(shù)據(jù)和上下文信息指示她尚未以其他方式與他溝通并且她和她的丈夫不在同一地點。在第一未來時間，當基于michelle的可用性和與未接來電相關聯(lián)的任何確定的緊急性或重要性而被確定為方便時，向michelle提供呼叫她的丈夫的提醒。在一段時間間隔之后，當確定michelle仍然尚未聯(lián)系他時，在第二未來時間處向michelle提供第二提醒，第二未來時間可以如第一未來時間那樣被確定為是方便的。在一些情況下，第二提醒可能會更加明顯(例如，更大，諸如彈出窗口而不是通知漏洞，包括可聽見的啁啾聲等)。備選地，只要michelle試圖訪問她的用戶設備上的電話功能，那么她可以被立即呈現(xiàn)通知。例如，只要她在智能手機上發(fā)起電話應用，她就被示出提示，以告知她她丈夫打過電話并且詢問她現(xiàn)在是否要給他回電話。
在第四示例中，bill注意到他妻子在會議期間打了兩次電話。然而，當bill離開會議時，他與他的兩位同事進行了有趣的討論并且忘了給他妻子回電話。本發(fā)明的實施例確定bill不再處于會議中，并且還確定他在類似的情況下通常給他妻子回電話。因此，生成提醒他給她回電話的通知，并經(jīng)由他的智能手機向bill提供該通知。如果用戶數(shù)據(jù)(或傳感器數(shù)據(jù))指示bill的智能電話在他的口袋中，那么通知可以包括振動或聲音，以引起bill的注意。(例如，通知內(nèi)容可以包括針對該條件的通知邏輯。)
繼續(xù)該示例，bill的妻子每打電話一次(或她在給定的時間幀內(nèi)每打電話一次)，與來自他妻子的未接來電相關聯(lián)的所確定的緊急性就可以增加。如果緊急性足夠高，那么bill在會議期間可以被通知未處理事件(即，來自他妻子的通信)。例如，在她打電話三次并且還發(fā)送了諸如“bill，請盡快打電話給我。這是緊急情況”的短信的情況下，那么緊急性級別可以被更新，并且如果其足夠大(這可以由本文中所描述的閾值來確定)，那么bill將在會議期間被呈現(xiàn)通知。一些實施例還可以考慮關于bill正在參加的會議的重要性的上下文信息。例如，在可以從會議請求、日歷或電子郵件確定的上下文信息指示會議是與bill的老板就其補償而進行的情況下，那么可能需要更高的緊急性級別才能用通知來中斷會議。
在第五示例中，james錯過了電話公司提醒他支付他的電話賬單的來電。個人助理應用(本發(fā)明的實施例)檢測到該未接來電，并且使用上下文信息確定包括用于通知的補充內(nèi)容的通知內(nèi)容。個人助理應用在方便的時候向james提供包括支付電話帳單的鏈接的提醒。備選地，個人助理應用的另一實施例可以自動支付帳單并且將其報告給james或者可以詢問james“你是否要我現(xiàn)在支付你的電話賬單？”(在一些實施例中，可能需要james授權(quán)個人助理應用代表他來付款，這可以被實現(xiàn)為用戶設置中的特征。)
在第六示例中，george的妻子注意到水龍頭在漏水，并且使用個人助理應用設置提醒，諸如“cortana，george需要修理漏水龍頭”。個人助理應用在george可能能夠處理漏水的方便的或個性化的時間(諸如，在星期六早上george醒來之后)向george提供提醒。假設在下班開車回家時，傳感器數(shù)據(jù)指示george停在了五金店旁。與未處理事件和響應信息相對應的上下文信息可以指示修理水龍頭(或修理物體)與用戶去往五金店有關。因此，即使在可能先前已經(jīng)確定george星期四晚上在下班開車回家時不可用，并且因此不應該向他呈現(xiàn)修理水龍頭的通知的情況下，但是可以更新george的可用性，因為他在五金店。因此，在去往五金店時，george可以被呈現(xiàn)關于漏水龍頭的通知。
在第七示例中，牙醫(yī)呼叫bob安排他每兩年一次的清潔和檢查的預約。個人助理應用(本發(fā)明的實施例)檢測到該未處理事件(未接來電)并且在用戶方便的時間與牙醫(yī)診所安排預約。方便或可用的時間可以基于上下文信息和用戶數(shù)據(jù)來確定，上下文信息和用戶數(shù)據(jù)諸如用戶的日歷和用戶的未來預約(例如，其可以從電子郵件、文本或社交網(wǎng)絡數(shù)據(jù)來確定)。個人助理應用可以向牙醫(yī)診所生成可以包括bob可用時間的電子郵件，可以在線安排預約，或者(使用自動語音識別功能)可以呼叫診所并播放與安排預約有關的消息。在確定了牙醫(yī)預約的可用時間后，可以向bob呈現(xiàn)通知，以確認該預約。備選地，可以自動安排預約，并向bob通知與預約有關的通知。
在第八示例中，ido接收到帶有嬰兒食品優(yōu)惠券的電子郵件。個人助理應用(本發(fā)明的實施例)檢測到電子郵件，并且基于包括用戶活動、購買歷史、在線活動等的用戶數(shù)據(jù)確定ido尚未采取任何與購買嬰兒食品有關的動作。上下文信息指示ido定期購買嬰兒相關產(chǎn)品；因此，個人助理應用確定優(yōu)惠券可能對ido是重要(相關)的。此外，個人助理應用確定優(yōu)惠券今天到期，并且因此具有高的緊急性級別。因此，在其下班回家路上經(jīng)過雜貨店之前不久，向ido提供提醒ido關于優(yōu)惠券的通知。(備選地，假設另一用戶的個人助理應用確定用戶沒有嬰兒，那么與優(yōu)惠券相對應的重要性級別低，并且該用戶可能不被呈現(xiàn)關于優(yōu)惠券的通知。)
因此，已經(jīng)描述了涉及用于向用戶提供與未處理的通信相關事件有關的個性化通知內(nèi)容的系統(tǒng)和方法的技術的各個方面。應當理解，本文中所描述的實施例的各種特征、子組合和修改是實用的，并且可以在其他實施例中被使用，而不參考其他特征或子組合。此外，示例方法400和500中所示的步驟的順序和序列并不意味著以任何方式限制本發(fā)明的范圍，并且實際上，這些步驟可以在本發(fā)明的實施例內(nèi)以各種不同的序列來發(fā)生。這樣的變化及其組合也被認為在本發(fā)明的實施例的范圍內(nèi)。
已經(jīng)描述了本發(fā)明的各種實施例，現(xiàn)在描述適合于實現(xiàn)本發(fā)明的實施例的示例性計算環(huán)境。參考圖7，提供了示例性計算設備并且其總體上被稱為計算設備700。計算設備700僅是合適的計算環(huán)境的一個示例，而非旨在暗示對本發(fā)明的使用或功能的范圍的任何限制。計算設備700也不應當被解釋為具有與所示的部件中的任何一個或組合有關的任何依賴性或要求。
本發(fā)明的實施例可以在計算機代碼或機器可用指令的一般上下文中描述，所述計算機代碼或機器可用指令包括由計算機或其他機器(諸如個人數(shù)據(jù)助理、智能電話、平板pc或其他手持設備)執(zhí)行的計算機可用或計算機可執(zhí)行指令，諸如程序模塊。通常，程序模塊指代執(zhí)行特定任務或?qū)崿F(xiàn)特定抽象數(shù)據(jù)類型的代碼，所述程序模塊包括例程、程序、對象、部件、數(shù)據(jù)結(jié)構(gòu)等。本發(fā)明的實施例可以在各種系統(tǒng)配置中實現(xiàn)，各種系統(tǒng)配置包括手持設備、消費電子設備、通用計算機、更專業(yè)的計算設備等。本發(fā)明的實施例還可以在分布式計算環(huán)境中實踐，在分布式計算環(huán)境中任務由通過通信網(wǎng)絡而鏈接的遠程處理設備來執(zhí)行。在分布式計算環(huán)境中，程序模塊可以位于本地和遠程計算機存儲介質(zhì)(包括存儲器存儲設備)兩者中。
參考圖7，計算設備700包括總線710，總線710直接或間接耦合以下設備：存儲器712，一個或多個處理器714，一個或多個呈現(xiàn)部件716，一個或多個輸入/輸出(i/o)端口718，一個或更多i/o部件720，以及圖示性電源622?？偩€710表示可以是一個或多個總線(諸如，地址總線、數(shù)據(jù)總線或其組合)。盡管為了清楚起見用線示出圖7的各個框，但實際上，這些框表示邏輯的部件而不一定是實際的部件。例如，可以將諸如顯示設備的呈現(xiàn)部件視為i/o部件。另外，處理器具有存儲器。本發(fā)明人認識到這是本領域的本質(zhì)，并且重申圖7的示圖僅是可以結(jié)合本發(fā)明的一個或多個實施例來使用的示例性計算設備的說明。沒有在諸如“工作站”、“服務器”、“膝上型計算機”、“手持設備”等類別之間進行區(qū)分，因為預期所有這些都在圖7的范圍內(nèi)并且指代為“計算設備”。
計算設備700通常包括各種計算機可讀介質(zhì)。計算機可讀介質(zhì)可以是可以由計算設備700訪問的任何可用介質(zhì)，并且包括易失性和非易失性介質(zhì)、可移除和不可移除介質(zhì)。作為示例而非限制，計算機可讀介質(zhì)可以包括計算機存儲介質(zhì)和通信介質(zhì)。計算機存儲介質(zhì)包括用于存儲諸如計算機可讀指令、數(shù)據(jù)結(jié)構(gòu)、程序模塊或其他數(shù)據(jù)之類的信息的任何方法或技術中所實現(xiàn)的易失性和非易失性、可移除和不可移除介質(zhì)。計算機存儲介質(zhì)包括但不限于ram、rom、eeprom、閃存或其他存儲器技術、cd-rom、數(shù)字通用盤(dvd)或其他光盤存儲裝置、磁帶盒、磁帶、磁盤存儲裝置或其他磁存儲設備、或者可以用于存儲所需信息并且可以由計算設備700訪問的任何其他介質(zhì)。計算機存儲介質(zhì)不包括信號本身。通信介質(zhì)通常實施計算機可讀指令、數(shù)據(jù)結(jié)構(gòu)、程序模塊、或諸如載波或其他傳輸機制的調(diào)制數(shù)據(jù)信號中的其他數(shù)據(jù)，并且包括任何信息傳遞介質(zhì)。術語“調(diào)制數(shù)據(jù)信號”是指其特性中的一個或多個以能夠?qū)π盘栔械男畔⑦M行編碼的方式設置或改變的信號。作為示例而非限制，通信介質(zhì)包括諸如有線網(wǎng)絡或直接有線連接的有線介質(zhì)，以及諸如聲學、rf、紅外和其他無線介質(zhì)之類的無線介質(zhì)。上述中的任一項的組合也應當被包括在計算機可讀介質(zhì)的范圍內(nèi)。
存儲器712包括易失性和/或非易失性存儲器形式的計算機存儲介質(zhì)。存儲器可以是可移除的、不可移除的或其組合。示例性硬件設備包括固態(tài)存儲器、硬盤驅(qū)動器、光盤驅(qū)動器等。計算設備700包括一個或多個處理器714，其從諸如存儲器712或i/o部件720等各種實體讀取數(shù)據(jù)。呈現(xiàn)部件716向用戶或其他設備呈現(xiàn)數(shù)據(jù)指示。示例性呈現(xiàn)部件包括顯示裝置、揚聲器、打印部件、振動部件等。
i/o端口718運行計算設備700在邏輯上耦合到包括i/o部件720的其他設備，其中一些可以被內(nèi)置。說明性部件包括麥克風、操縱桿、游戲鍵盤、衛(wèi)星天線、掃描儀、打印機、無線設備等。i/o部件720可以提供處理由用戶生成的手勢感應、語音或其他生理輸入的自然用戶界面(nui)。在一些情況下，輸入可以被傳輸?shù)竭m當?shù)木W(wǎng)絡元件，以用于進一步處理。nui可以實現(xiàn)以下項的任何組合語音識別、觸摸和觸筆識別、面部識別、生物計量識別、屏幕上及與屏幕相鄰的手勢識別、手勢感應、頭部和眼睛跟蹤、以及與計算設備上的顯示器相關聯(lián)的觸摸識別。計算設備700可以配備有用于手勢檢測和識別的深度相機，諸如立體相機系統(tǒng)、紅外相機系統(tǒng)、rgb相機系統(tǒng)以及它們的組合。另外，計算設備700可以配備有允許檢測運動的加速度計或陀螺儀。加速度計或陀螺儀的輸出可以被提供給計算設備700的顯示器，以呈現(xiàn)沉浸式增強現(xiàn)實或虛擬現(xiàn)實。
計算設備700的一些實施例可以包括一個或多個無線電724(或類似的無線通信部件)。無線電724傳輸和接收無線電或無線通信。計算設備700可以是適于通過各種無線網(wǎng)絡接收通信和媒體的無線終端。計算設備700可以經(jīng)由諸如碼分多址(“cdma”)、全球移動通信系統(tǒng)(“gsm”)或時分多址(“tdma”)等的無線協(xié)議與其他設備通信進行通信。無線電通信可以是近距離連接、遠距離連接、或近距離和遠距離無線電信連接兩者的組合。當提到“短”和“長”類型的連接時，不意味著指代兩個設備之間的空間關系。相反，通常將近距離和遠距離指代為不同類別或類型的連接(即，主連接和輔助連接)。作為示例而非限制，近距離連接可以包括到提供對無線通信網(wǎng)絡的訪問的設備(例如，移動熱點)的
在不脫離權(quán)利要求的范圍的情況下，所描繪的各種部件以及未示出的部件的很多不同布置是可能的。已經(jīng)描述了本發(fā)明的實施例，其意圖是說明性而非限制。對于本公開的讀者而言，在閱讀本公開之后且由于本公開，備選實施例將變得顯而易見。在不脫離權(quán)利要求的范圍的情況下，可以完成實現(xiàn)上述內(nèi)容的備選手段。某些特征和子組合是實用的，并且可以在不參考其他特征和子組合的情況下使用，并且被預期在權(quán)利要求的范圍內(nèi)。
因此，在一個方面，本發(fā)明的實施例涉及一種計算機化系統(tǒng)，其包括:被配置為提供傳感器數(shù)據(jù)的一個或多個傳感器；被配置為至少部分地基于傳感器數(shù)據(jù)來檢測未處理事件的事件監(jiān)測器；一個或多個處理器；以及存儲計算機可用指令的一個或多個計算機存儲介質(zhì)，計算機可用指令在由一個或多個處理器使用時使得一個或多個處理器執(zhí)行某些操作。這些操作包括：(a)使用事件監(jiān)測器，至少部分地基于傳感器數(shù)據(jù)來標識未處理事件，未處理事件與用戶相關聯(lián)；(b)使用事件監(jiān)測器來確定與所標識的未處理事件相關聯(lián)的上下文信息集合；(c)基于上下文信息集合，來確定與未處理事件相對應的緊急性級別；(d)至少部分地基于與未處理事件相對應的所確定的緊急性級別來確定針對用戶的可用性模型；以及(e)基于緊急性級別、可用性模型和未處理事件來生成通知內(nèi)容集合，通知內(nèi)容集合用于確定與未處理事件有關的通知。
在該系統(tǒng)的一些實施例中，操作還包括根據(jù)所生成的通知內(nèi)容集合來確定通知，并且在與用戶相關聯(lián)的用戶設備上呈現(xiàn)通知，根據(jù)通知內(nèi)容集合通知在從通知內(nèi)容被生成時的未來時間處被呈現(xiàn)。在一些實施例中，針對用戶的所確定的可用性模型包括針對用戶的未來可用性，并且還包括與用戶實施與響應未處理事件相關聯(lián)的動作或任務的能力相對應的可用性得分的集合。在一些實施例中，生成通知內(nèi)容集合包括基于所確定的緊急性級別和可用性模型來確定通知邏輯集合，通知邏輯指定用于呈現(xiàn)與未處理事件相對應的通知的至少一種條件或格式。并且，在一些實施例中，生成通知內(nèi)容集合包括確定用于協(xié)助用戶處理未處理事件的補充內(nèi)容，并且所呈現(xiàn)的通知包括呈現(xiàn)補充內(nèi)容的一部分。
在另一方面，本發(fā)明的實施例涉及其上實施有計算機可執(zhí)行指令的一種或多種計算機可讀設備，計算機可執(zhí)行指令在由具有處理器和存儲器的計算系統(tǒng)執(zhí)行時，使得計算系統(tǒng)執(zhí)行一種用于向用戶提供與未處理的通信相關事件有關的個性化通知內(nèi)容的方法。該方法包括：(a)至少部分地基于來自用戶設備的用戶數(shù)據(jù)來標識未處理事件，未處理事件與用戶相關聯(lián)；(b)確定與所標識的未處理事件相關聯(lián)的上下文信息；(c)基于上下文信息，確定與未處理事件相對應的緊急性或重要性中的至少一項；(d)至少部分地基于與未處理事件相對應的所確定的緊急性或重要性，來確定用戶的可用性模型；(e)基于所確定的緊急性或重要性、可用性模型和未處理事件來生成通知內(nèi)容；(f)根據(jù)所生成的通知內(nèi)容，來確定與未處理事件有關的通知；以及(g)在與用戶相關聯(lián)的用戶設備上呈現(xiàn)通知，根據(jù)通知內(nèi)容集合，通知在從通知內(nèi)容被生成時的未來時間處被呈現(xiàn)。
在又一方面，本發(fā)明的實施例涉及一種由包括至少一個處理器的一個或多個計算設備執(zhí)行的方法，該方法用于確定未被用戶處理的事件的實例。該方法包括：(a)從一個或多個傳感器接收傳感器數(shù)據(jù)，傳感器中的至少一些在與用戶相關聯(lián)的用戶設備上；(b)從第一傳感器數(shù)據(jù)集合確定第一通信事件的發(fā)生；(c)監(jiān)測指示在第一通信事件之后的用戶活動的傳感器數(shù)據(jù)，以確定第一響應信息集合；(d)確定類似于第一通信事件的一個或多個先前發(fā)生的通信事件的集合；(e)基于一個或多個先前發(fā)生的通信事件的集合，確定指示與一個或多個先前發(fā)生的通信事件相關聯(lián)并且在一個或多個先前發(fā)生的通信事件之后發(fā)生的用戶活動的信息集合，指示用戶活動的所確定的信息集合形成第二響應信息集合；(f)基于第一響應信息集合與第二響應信息集合的比較，確定第一通信事件未被處理；以及(g)提供第一通信事件作為未處理事件的指示。
在該方法的一些實施例中，一個或多個先前發(fā)生的通信事件的集合包括與另一用戶相關聯(lián)的至少一個事件。在一些實施例中，該方法還包括：使用傳感器數(shù)據(jù)來確定與未處理事件相關聯(lián)的上下文信息的集合；以及基于上下文信息集合和未處理事件來生成通知內(nèi)容集合，通知內(nèi)容集合用于確定與未處理事件有關的通知。另外，在一些實施例中，該方法還包括根據(jù)所生成的通知內(nèi)容集合來確定通知，并且在與用戶相關聯(lián)的用戶設備上呈現(xiàn)通知，通知根據(jù)通知內(nèi)容集合而被呈現(xiàn)。
在另一方面，本發(fā)明的實施例涉及一種包括計算機存儲器和計算機處理器的移動計算設備，計算機處理器被配置為允許個人數(shù)字助理執(zhí)行任務。移動計算設備包括被配置為提供傳感器數(shù)據(jù)的一個或多個傳感器，以及作為存儲在計算機存儲器上的計算機程序的個人數(shù)字助理。個人數(shù)字助理計算機程序包括代碼(其可以被編譯為機器可讀指令)，代碼被配置為：(a)監(jiān)測傳感器數(shù)據(jù)，以確定未處理事件的指示；(b)在確定未處理事件的指示時，確定與未處理事件相關聯(lián)的上下文信息集合；(c)基于上下文信息集合和未處理事件，來生成通知內(nèi)容集合；以及(d)在移動計算設備上呈現(xiàn)通知，通知根據(jù)通知內(nèi)容集合而被呈現(xiàn)。在一些實施例中，代碼還被配置為確定用于協(xié)助用戶處理未處理事件的補充內(nèi)容并且呈現(xiàn)包括補充內(nèi)容的一部分的通知。另外，在一些實施例中，代碼還被配置為基于上下文信息集合來確定與未處理事件相關聯(lián)的緊急性級別，并且基于與未處理事件相關聯(lián)的緊急性級別來生成通知內(nèi)容。
在另一方面，本發(fā)明的實施例涉及一種計算機化系統(tǒng)，其包括：被配置為提供傳感器數(shù)據(jù)的一個或多個傳感器；被配置為生成用于確定通知的通知內(nèi)容的通知引擎；一個或多個處理器；以及存儲有計算機可用指令的一個或多個計算機存儲介質(zhì)，計算機可用指令在由一個或多個處理器使用時使得一個或多個處理器執(zhí)行操作。這些操作包括：(a)使用通知引擎接收未處理事件的指示，未處理事件與用戶相關聯(lián)并且至少部分地基于傳感器數(shù)據(jù)來確定；(b)確定與未處理事件相關聯(lián)的上下文信息的集合，上下文信息至少部分地基于傳感器數(shù)據(jù)來確定；(c)至少部分基于上下文信息的集合來確定用于向用戶提供與未處理事件有關的第一通知的第一時間幀；(d)確定用于向用戶呈現(xiàn)第一通知的一個或多個時間第一集合，一個或多個時間在第一時間幀內(nèi)；以及(e)生成用于確定第一通知的第一通知內(nèi)容集合，第一通知內(nèi)容集合包括指定用于呈現(xiàn)通知的一個或多個時間的第一集合的通知邏輯。在該系統(tǒng)的一些實施例中，操作還包括根據(jù)所生成的通知內(nèi)容集合來確定通知，以及在與用戶相關聯(lián)的用戶設備上呈現(xiàn)通知，根據(jù)通知內(nèi)容集合，通知在從所確定的一個或多個時間起的特定時間處被呈現(xiàn)。
在另一方面，本發(fā)明的實施例涉及一種計算機化方法。該方法包括(a)在服務器處接收一個或多個網(wǎng)絡通信，包括：(i)與用戶相關聯(lián)的未處理事件的指示，未處理事件至少部分地基于傳感器數(shù)據(jù)來確定，傳感器數(shù)據(jù)由與用戶相關聯(lián)的用戶設備上的一個或多個傳感器提供，以及(ii)與未處理事件相對應的上下文信息；(b)基于上下文信息來確定與未處理事件相對應的緊急性級別；(c)確定用于響應未處理事件的用戶可用性，用戶可用性至少部分基于與未處理事件相對應的所確定的緊急性級別；(d)基于緊急性級別、可用性模型和未處理事件來生成通知內(nèi)容，通知內(nèi)容用于確定與未處理事件有關的通知；以及(e)向與用戶設備相關聯(lián)的服務提供通知內(nèi)容，服務用于基于通知內(nèi)容來向用戶呈現(xiàn)通知。
在另一方面，本發(fā)明的實施例涉及其上實施有計算機可執(zhí)行指令的一種或多種計算機可讀設備，計算機可執(zhí)行指令在由具有處理器和存儲器的計算系統(tǒng)執(zhí)行時，使得計算系統(tǒng)執(zhí)行用于向第一用戶提供個性化通知內(nèi)容的方法。該方法包括(a)接收與第一用戶相關的信息項的指示；(b)確定與信息項相關聯(lián)的上下文信息的集合；(c)至少部分地基于上下文信息，來確定與信息項相對應的緊急性級別；(d)確定第一用戶用于處理信息項的可用性，可用性至少部分基于與信息項相對應的所確定的緊急性級別，以及從響應于類似的信息項的先前通知而發(fā)生的用戶活動所確定的用戶響應模式；以及(e)在用戶設備上呈現(xiàn)與信息項有關的通知，通知基于所確定的可用性而在特定時間被呈現(xiàn)。在一些實施例中，通知可以根據(jù)基于所確定的可用性而確定的格式而被呈現(xiàn)，并且用戶響應模式可以從第二用戶的用戶活動來確定。
- 還沒有人留言評論。精彩留言會獲得點贊！