CN114556295A - 用户显示器上的基于上下文的通知 - Google Patents

Abstract

描述了用于管理通知的技术。在一个示例中，计算装置基于应用的执行而在应用窗口中呈现内容。通知数据由计算装置接收。基于与所述计算装置相关联的上下文，诸如所述应用窗口是否为前台以及所述通知数据是否与所述应用相关联，或诸如所述计算装置的操作模式，确定是在所述应用窗口内的上下文内还是在弹出窗口中呈现对应的通知。否则，将所述通知添加至通知列表并且可在通知概要中概括所述通知。

Description

用户显示器上的基于上下文的通知

背景技术

图形用户界面(GUI)是用户可用来与计算机系统交互的主要类型的界面。GUI能够操作以向用户呈现通知。例如，在接收到消息数据之后，消息接发应用在GUI上呈现文本消息。类似地，在接收到新闻提示之后，新闻应用在GUI上呈现新闻通知。

通常，当第一应用在GUI上呈现内容(例如，视频游戏应用呈现视频游戏内容并且通知数据去往第二应用(例如，消息接发应用)时，可不在所述GUI上呈现完整的通知数据(例如，整个文本消息)，除非暂停对所述内容的呈现并且执行从所述第一应用至所述第二应用的切换。因此，在呈现通知数据之前可需要用户输入以切换至所述第二应用。可需要附加的用户输入来消除所述通知数据并且恢复对内容的呈现。

因此，尽管GUI可以是有效的用户界面，但在应用之间切换可能不是无缝的并且对信息的呈现可受到限制。需要允许更好地呈现通知的改进的GUI。

发明内容

描述了用于呈现通知的技术。在一个示例中，计算机系统基于应用的执行而在显示器上的应用窗口中呈现内容。所述计算机系统还接收通知数据并且确定与所述通知数据相关联的第一上下文和与所述应用相关联的第二上下文之间的匹配。所述计算机系统基于所述匹配而在所述应用窗口中呈现通知。所述通知对应于所述通知数据并且在对内容的呈现继续时呈现。

附图说明

图1说明根据本公开的一个实施方案的用于呈现通知的计算环境的示例。

图2说明根据本公开的一个实施方案的呈现通知的计算机系统。

图3说明根据本公开的一个实施方案的用于呈现通知的模块的示例。

图4说明根据本公开的实施方案的直插通知的示例。

图5说明根据本公开的实施方案的应用内通知的示例。

图6说明根据本公开的实施方案的流内通知的示例。

图7说明根据本公开的实施方案的弹出通知的示例。

图8说明根据本公开的实施方案的通知的状态的示例。

图9说明根据本公开的实施方案的用于呈现上下文内通知的流的示例。

图10说明根据本公开的实施方案的装置的操作模式的示例。

图11说明根据本公开的实施方案的与操作模式相关联的通知设置的示例。

图12说明根据本公开的实施方案的替换通知的示例。

图13说明根据本公开的实施方案的替换与累加通知的示例。

图14说明根据本公开的实施方案的修改通知的示例。

图15说明根据本公开的实施方案的将通知分组的示例。

图16说明根据本公开的实施方案的用于根据操作模式来呈现通知的流的示例。

图17说明根据本公开的实施方案的根据操作模式的通知概要的示例。

图18说明根据本公开的实施方案的通知概要的状态的示例。

图19说明根据本公开的实施方案的汇总通知的示例。

图20说明根据本公开的实施方案的用于汇总和呈现通知的流的示例。

图21说明根据本公开的实施方案的用于在视频游戏控制台上呈现上下文内通知和弹出通知的流的示例。

图22说明根据本公开的实施方案的适合于实施计算机系统的硬件系统的示例。

具体实施方式

一般来讲，描述了用于更好地管理通知的系统和方法。在一个示例中，计算机系统在显示器上呈现GUI。在执行应用之后，在所述GUI中呈现所述应用的内容。计算机系统还确定与所述应用的用户和/或一个或多个应用的执行相关联的上下文。所述上下文指示用户与所述应用的交互和对所述应用的兴趣。另外，计算机系统存储通知规则，所述通知规则指定了应基于上下文在何时、如何、在何处呈现通知和/或呈现什么通知。在接收到通知数据之后，计算机系统基于上下文和通知规则来管理对相应通知的呈现。管理所述通知包括多个方面。在第一方面，计算机系统确定是否应在GUI中呈现通知以及呈现的类型(例如，上下文内或弹出)或者是否应约束此类呈现。在第二方面，当作出约束确定时，计算机系统可向通知概要添加通知并且可基于通知的优先级而随时间更新所述通知概要。在上下文改变之后，在显示器上呈现通知概要。在第三方面，可向通知列表添加未向用户呈现的通知。所述通知列表随时间被更新，由此替换、修改和/或分组所述通知的一些或全部。另外，在呈现通知之后，对基础内容的呈现继续，由此可不需要用户输入来切换回并且恢复此内容的呈现。还可在上下文改变的情况下更新所呈现的通知，使得在所述通知中呈现的任何信息和/或可选择动作继续与最当前的上下文相关。

为了说明，考虑操控视频游戏应用、聊天应用、视频流式传输应用、社交媒体应用和多个其他应用的视频游戏系统的示例。在视频游戏玩家登录之后，视频游戏系统在显示器上呈现家庭用户界面。视频游戏玩家可从此界面启动视频游戏应用，并且可在显示器上的前台中的应用窗口内呈现视频游戏内容。在从第二用户的装置接收到通知数据之后，视频游戏系统确定通知数据与聊天应用相关联。在前台中的应用窗口对应于视频游戏应用而不是聊天应用的情况下，视频游戏系统在平铺在应用窗口上的弹出窗口中呈现对应的通知。以折叠状态呈现通知，从而指示消息是从第二用户发送，同时对视频游戏内容的呈现继续并且应用窗口保持在前台中。在用户与通知交互之后，视频游戏系统以展开状态呈现通知，其中呈现所述通知的实际内容和所响应的可选择选项。在此状态下，对视频游戏内容的呈现也继续并且应用窗口保持在前台中。

接下来，视频游戏玩家完成某一关卡的视频游戏，并且视频游戏系统接收到用户输入以发起用于下载和启动下一关的流。在显示器上呈现新的应用窗口。在一个示例中，执行不同于视频游戏应用的应用，诸如菜单应用，并且所述应用可呈现新的应用窗口。新的应用窗口呈现对用户输入的确认(例如，正在下载下一关卡)。当执行流内的任务时，视频游戏系统接收关于这些任务的系统通知，并且在新的应用窗口内呈现流内通知。所述流内通知提供关于所述任务的更新。

随后，视频游戏玩家启动聊天应用。在前台中的聊天应用的应用窗口内呈现与其他用户的聊天。在与第二用户的活动聊天期间，视频游戏系统从第二装置接收第二通知数据并且在应用窗口中呈现对应的文本。在所述文本在应用窗口的查看区域内可用的情况下，视频游戏系统可通过在所述文本周围呈现视觉指示符(例如，蓝色矩形、闪光矩形或任何其他视觉提示)而向视频游戏玩家提示所述文本。此视觉指示符对应于指示新的通知数据在可查看区域内可用的直插通知。

在向上滚动以查看先前文本之后，从第二装置接收到第三通知数据。此处，应呈现对应的文本，但所述文本的呈现将不在当前查看区域中。因此，视频游戏系统在所述查看区域内呈现应用内通知，所述应用内通知指示新的文本可用并且将在向下滚动之后呈现。

视频游戏玩家从聊天应用切换至视频流式传输应用。视频游戏系统执行视频游戏应用并且在前台中呈现此应用的应用窗口。所述应用窗口呈现从网络源流式传输的视频内容。视频操作模式指示在流式传输视频时，社交媒体通知应受约束。因此，在所述流式传输期间，视频游戏系统接收到与邀请第二用户至在五分钟内开始的第一社交媒体事件相对应的第一通知数据。对应的第一社交媒体通知受到抑制，而不是在出现视频流时呈现，并且被发送至通知列表。在十分钟后，并且在视频流继续时，视频游戏系统接收与邀请第二用户至在一小时内开始的第二社交媒体事件相对应的第二通知数据。因为第一事件到期并且所述两个社交媒体通知是来自同一第二用户，所以视频游戏系统在通知列表中使用第二社交媒体通知替换第一社交媒体通知。在视频流结束之后，通知列表可呈现在显示器上，使得可查看第二社交媒体通知并且可接受至第二媒体事件的邀请。

在另一图解中，当视频游戏玩家正在玩视频游戏并且在前台中呈现视频游戏内容时，视频游戏系统接收到社交媒体通知数据。在给出游戏名称并且用户与视频游戏交互的情况下，在上下文指示沉浸式游戏会话的情况下，视频游戏系统确定对应的社交媒体通知应进行排队而不是呈现。因此，视频游戏系统将社交媒体通知添加至队列，并且任选地向与视频游戏玩家相关联的移动装置发送所述社交媒体通知。所述队列中的通知根据优先级进行组织，其中可基于对应的通知与当前上下文的相关性并且基于通知的新近度来更新每个优先级。在上下文改变(诸如某一视频游戏关卡结束)之后，视频游戏系统可呈现识别已经排队的通知的总数的通知概要。在用户与所述通知概要交互之后，视频游戏系统以展开状态呈现所述通知概要。在所述展开状态下，视频游戏系统呈现前三个(或某一其他数目)最高优先级通知并且提供查看其余通知的选项。所述三个通知中的每一者以折叠状态呈现，并且可进一步选择所述三个通知中的每一者以在展开状态下呈现。所汇总的通知中的每一者中的内容(例如，信息和可选择动作)基于当前上下文进行更新。

本公开的实施方案提供优于现有的计算机系统和它们的基础GUI的若干优势。例如，GUI的功效以及基础处理和存储器的效率得到提高。具体地，GUI可提供提高的用户体验，但是在GUI上向用户呈现及时和相关的通知，同时进行中的内容呈现继续，并且汇总了其他通知和/或向通知列表添加所述其他通知以供稍后呈现。以此方式，用户可及时地查看相关的通知，并且在需要时在不中断进行中的内容呈现的情况下展开此类通知中的任一者。因为呈现了相关的通知，所以可相对于现有的系统减少处理和存储器的使用，现有的系统会呈现所有通知并且会需要在前台应用与后台应用之间来回切换。

出于解释清楚起见，可结合视频游戏系统描述实施方案。然而，所述实施方案不受此限制，并且类似地适用于任何其他类型的计算机系统。一般来讲，计算机系统可包括一个或多个用户装置，每个用户装置与一个或多个显示器通信地耦合。所述计算机系统还可包括后端系统，诸如服务器，所述后端系统跟踪跨一个或多个装置的上下文以及对通知的接收、排队、区分优先级和/或交互和其他功能性。

图1说明根据本公开的一个实施方案的用于呈现通知的计算环境的示例。如所说明，所述计算环境包括与显示器120通信地耦合的视频游戏系统110、集成有显示器的移动装置130、后端服务器150和用户装置140。视频游戏系统110和移动装置130可由视频游戏玩家112使用(例如，由视频游戏玩家112操作或在用户账户下与视频游戏玩家112相关联)。相比之下，用户装置140可由用户142(例如，另一视频游戏玩家)使用。后端服务器150提供用以控制应在何时、如何、在何处呈现通知和/或呈现什么通知的管理功能性。

在一个示例中，用户142操作用户装置140以发送指向视频游戏玩家112的通知数据144。后端服务器150接收通知数据144，并且确定视频游戏玩家112与视频游戏控制台110和移动装置130相关联。后端服务器150还确定与视频游戏玩家112和/或视频游戏控制台110相关联的上下文。基于所述上下文，后端服务器150确定是否应向视频游戏控制台110发送对应的通知数据152以便作为通知114呈现在显示器120上或者是否应约束此类呈现。如果将要呈现通知114，则后端服务器150确定通知114的类型，诸如所述通知应为上下文内通知还是弹出通知。视频游戏玩家112可操作用户输入装置，诸如视频游戏控制器，以与视频游戏系统110交互。所述用户输入装置可包括能够操作以与通知114交互的按钮。与通知114交互可包括：以一个或多个状态查看通知；消除通知114；请求包括通知114的通知概要；请求包括通知114的通知列表；或任何其他类型的交互。

另外，后端服务器150确定是否应将对应的通知数据154发送至移动装置130以便作为通知132呈现在移动装置130的显示器上。在图解中，如果通知114不应由视频游戏控制台110呈现，则后端服务器150将通知数据154发送至移动装置130。在此图解中，可将通知数据152发送至用于通知概要的队列，并且可基于用户与由移动装置呈现的通知132的交互是否发生来更新所述队列中的所述通知数据的优先级。

在一个示例中，通知表示能够在诸如GUI的用户界面上呈现的输出，并且通过包括可呈现信息和/或可选择动作来通知用户。文本消息、社交媒体帖子和/或比如多媒体(例如，音频、视频、视频游戏内容)下载状态、多媒体购买是通知的示例。通知数据表示可用于在呈现之后填充通知的数据和限定所述通知的呈现参数的元数据。在现有的系统中，通知通常呈现在专用的通知区域(诸如显示器上的GUI的右下栏或顶栏)中。通知数据是。相比之下，本公开的实施方案允许在GUI的其他区域中呈现通知。具体地，通知可以是可在平铺在前台中的应用窗口上的弹出窗口中呈现的弹出通知。通知可以是可在应用窗口内呈现的上下文内通知。不同类型的上下文内通知是可能的，诸如直插通知、应用内通知和流内通知。所述类型中的每一者对应于一种呈现式样。直插通知对应于直插呈现的式样，并且表示具有位于应用窗口内的用户查看区域中的可呈现信息的通知。应用内通知对应于应用内呈现的式样，并且表示具有位于所述用户查看区域之外但在应用窗口内的可呈现信息的通知。流内通知对应于流内呈现的式样，并且表示具有关于所执行的流的任务的可呈现信息的通知。

可基于最当前的上下文动态地更新弹出通知、直插通知、应用内通知和流内通知。另外，弹出通知、直插通知、应用内通知和流内通知中的每一者可与多个属性相关联，所述多个属性包括源应用(例如，生成通知的应用)、目的地应用(例如，应呈现通知的应用)、通知类型(例如，消息)、通知主题(例如，消息线程)、累加参数(例如，计数器，诸如消息的数目)、时间敏感度(例如，应立即呈现；否则通知过时)、优先级、时间戳(例如，接收到通知的时间)和/或到期时间(例如，通知在超过到期时间时不再有意义)。此类属性可用于管理通知的呈现。

一般来讲，后端服务器150后端服务器150还可确定当前上下文。后端服务器150还存储规则，所述规则指定了应基于上下文在何时、如何、在何处呈现通知和/或呈现什么通知。所述规则可根据通知设置来限定，所述通知设置可具有默认值并且经由视频游戏控制台110处的视频游戏玩家112的用户输入来配置。可基于人工智能模型，诸如使用机器学习算法的模型，来动态地配置和更新所述通知设置中的一些或全部，所述人工智能模型是基于多个视频游戏玩家的历史数据来训练。

尽管将后端服务器150示出为与视频游戏控制台110分开的计算机系统，但后端服务器150的功能性中的一些或全部可由视频游戏系统110实施(例如，视频游戏系统110可包括专用于视频游戏玩家112的视频游戏控制台和多个玩家可用的云服务器)。例如，规则可在本地存储在视频游戏系统110上，而通知设置可与用户配置文件相关联地在本地存储或也与用户配置文件相关联地远程地存储在后端服务器150上。可在本地在视频游戏控制台110上执行上下文确定。另外，视频游戏玩家112可与不同数目和其他类型的装置相关联。例如，作为与移动装置130相关联的补充或代替，视频游戏玩家112可与平板计算机、桌上型计算机或任何其他用户装置相关联。

图2说明根据本公开的一个实施方案的呈现通知的计算机系统。如所说明，计算机系统包括视频游戏控制台210和显示器220。虽然未示出，但计算机系统还可包括与视频游戏控制台210通信地耦合的后端系统，诸如一组云服务器。视频游戏控制台210与视频游戏控制器(未示出)和显示器220(例如，经由通信总线)通信地耦合。视频游戏玩家操作视频游戏控制器以与视频游戏控制台210交互。这些交互可包括玩在显示器220上呈现的视频游戏以及与视频游戏控制台210的其他应用的交互。

视频游戏控制台210包括处理器和存储计算机可读指令的存储器(例如，非暂时性计算机可读存储介质)，所述计算机可读指令可由所述处理器执行并且在由所述处理器执行之后致使视频游戏控制台210执行与各种应用相关的操作。具体地，计算机可读指令可对应于视频游戏控制台210的各种应用，包括视频游戏应用240、音乐应用242、视频应用244、社交媒体应用246、聊天应用248和通知应用250，以及视频游戏控制台210的其他应用(例如，促进显示器220上的主页的主用户界面(UI)应用)。

视频游戏控制器是输入装置的示例。其他类型的输入装置是可能的，包括键盘、触摸屏、触摸板、鼠标、光学系统或适合于接收用户的输入的其他用户装置。

在一个示例中，在执行视频游戏应用240之后，视频游戏控制台210的渲染过程在显示器220的GUI上的应用窗口中呈现视频游戏内容(例如，说明为赛车视频游戏内容)。所述应用窗口呈现在GUI的前台中，指示视频游戏应用是活动的并且视频游戏控制器处的用户输入可用于与所述视频游戏应用交互。相比之下，其他应用也可在后台中执行，或者可在GUI的后台中呈现它们的应用窗口，从而指示用户输入不可用于与此类应用交互。

在从另一装置接收到通知数据之后，通知应用250确定对应的通知212的属性，包括(例如)通知数据是指向视频游戏应用240、音乐应用242、视频应用244、社交媒体应用246还是聊天应用246。通知应用250还可确定上下文，诸如用户交互和活动应用的层级(例如，视频游戏应用240具有前台应用窗口)，并且可应用规则以确定对应的通知212是应呈现在前台应用窗口上的弹出窗口中还是作为上下文内通知呈现在前台应用窗口内，或者对应的通知212是否应受约束(例如，在通知概要中排队或添加至通知列表)。如果应呈现通知212，则通知应用250通过(例如)应用编程接口(API)传递用于向活动应用(例如，视频游戏应用240)呈现通知212(例如，作为弹出或上下文内)的通知数据和指令。继而，活动应用将通知212呈现为前台应用窗口上的弹出通知或前台应用窗口内的上下文内通知。

尽管图2说明了在视频游戏控制台210上执行的不同应用，但本公开的实施方案不受此限制。而是，所述应用可在后端系统(例如，云服务器)上执行和/或它们的执行可分布在视频游戏控制台210与后端系统之间。

图3说明根据本公开的一个实施方案的用于呈现通知的模块的示例。如所说明，在接收到通知数据302之后，使用模块来确定应使用具有上下文内呈现式样的上下文内通知312(例如，直插呈现、应用内呈现或流内呈现中的任一者的式样)、通知概要322还是弹出通知324。具体地，第一模块实施上下文内逻辑310来确定是否应呈现上下文内通知312。如果否，则第二模块实施操作模式逻辑320来确定是否应呈现通知概要322。如果否，则确定呈现弹出通知324。

在一个示例中，将上下文内逻辑310和操作模式逻辑320中的每一者实施为可由处理器执行的计算机可读指令，诸如软件代码。此类指令可存储在诸如计算机存储器的非暂时性计算机可读介质中，并且可以是通知应用(诸如图2的通知应用250)的一部分。存储在非暂时性计算机可读介质和处理器中的所述计算机可读指令表示模块。所述模块可以是诸如图1的视频游戏系统110的视频游戏系统的计算部件、诸如图1的后端服务器150的后端服务器的计算部件或分布在视频游戏系统与后端服务器之间的计算部件。

在一个示例中，上下文内逻辑310包括或有权访问一组规则，所述一组规则指定了是否应基于与通知数据302、一个或多个用户和/或一个或多个应用相关联的上下文来呈现上下文内通知312。所述一组规则可被预定义为条件语句并且可基于用户偏好来定制。可在用户设置中指示所述用户偏好和/或可基于机器学习算法来执行所述定制。

类似地，操作模式逻辑320包括或有权访问一组规则，所述一组规则指定了是否应基于装置的操作模式来呈现通知概要322。所述一组规则可被预定义为条件语句并且可基于用户偏好来定制。可在用户设置中指示所述用户偏好和/或可基于机器学习算法来执行所述定制。

尽管图3说明了两个模块，但不同数目的模块和/或模块的不同布置是可能的。例如，可实施第三模块以确定是否应将通知添加至通知列表。进一步结合接下来的图来说明这些模块的操作。

转向图4至图7，所述图说明直插通知、应用内通知、流内通知和弹出通知的示例。所呈现的通知的类型取决于与通知数据、用户和/或用户可用的应用相关联的上下文。理解用户关注何处以及在用户错过通知的情况下会是什么反应是所考虑的因素。如果用户未转移注意力和/或如果通知与当前上下文相关，则上下文内通知(直插通知、应用内通知或流内通知)。如果所述通知将导致用户懊恼、困惑或负面和/或不大相关，则弹出通知是可能的。可定义实施此方法的一组规则。

在一个示例中，通知一般涉及活动、更新、事件或关于来自所执行的流的任务的反馈。如果活动、更新或事件出现在位于前台中的应用窗口内的查看区域中，则可使用直插通知。如果活动、更新或事件出现在查看区域之外但在应用窗口内，则可使用应用内通知。如果应用窗口呈现关于流的信息，则可呈现流内通知以提供反馈。另一方面，如果活动、更新或事件出现在后台中或在后台中呈现的应用窗口中，则可使用弹出通知。类似地，如果反馈是关于敏感任务的完成、任务失败或远程地发起并且在用户登入装置时仍然在处理的任务，则还可使用弹出通知。

图4说明根据本公开的实施方案的直插通知的示例。一般来讲，当可呈现信息(例如，所通知的内容)的位置在用户当前查看的区域(例如，用户查看区域)中时，使用直插通知。所述可呈现信息被更新和/或动画化为在用户的视野中。

如所说明，GUI 410呈现在显示器上。应用在执行(例如，聊天应用)并且在GUI 410上的应用窗口420中呈现内容(例如，聊天内容)。所呈现的内容涉及主题422(例如，聊天线程)。另外，第二窗口430呈现在GUI 410上，并且提供关于其他应用(例如，最近执行的视频游戏)的信息。

接收通知数据(例如，来自朋友A的聊天的文本)。确定所述通知数据与所述应用而不是第二窗口430相关联(例如，聊天应用是聊天的目的地)，并且与主题422相关联(例如，文本属于聊天线程)。因此，确定呈现上下文内通知。

接下来，确定通知数据(例如，来自朋友A的文本)可呈现在应用窗口420的用户查看区域内的位置(例如，通知数据将在呈现时位于用户的视野内)。因为所述位置在查看区域内，所以直插通知450是可能的。直插通知450提供通知数据的视觉指示符，诸如将通知数据更新和/或动画化的指示符(例如，在聊天的文本周围的蓝色矩形，或任何其他类型的视觉指示符)。

图5说明根据本公开的实施方案的应用内通知的示例。一般来讲，当通知的可呈现信息(例如，所通知的内容)的位置位于前台(例如，专注区域)中的应用窗口内但在查看区域之外时，使用应用内通知。所述应用内通知呈现在查看区域内并且可提示用户可呈现信息在查看区域之外。所述应用内通知可为交互式的，使得在用户与应用内通知交互之后，所述查看区域改变为展示可呈现信息的位置。

如所说明，GUI 510呈现在显示器上。应用在执行(例如，聊天应用)并且在GUI 510上的应用窗口520中呈现内容(例如，聊天内容)。所呈现的内容涉及主题522(例如，聊天线程)。另外，第二窗口530呈现在GUI 510上，并且提供关于其他应用(例如，最近执行的视频游戏)的信息。

接收通知数据(例如，来自朋友A的聊天的文本)。确定所述通知数据与所述应用而不是第二窗口530相关联(例如，聊天应用是聊天的目的地)，并且与主题522相关联(例如，文本属于聊天线程)。因此，确定呈现上下文内通知。

接下来，确定通知数据(例如，来自朋友A的文本)可呈现在应用窗口520的用户查看区域之外的位置(例如，通知数据将在聊天线程末端处展示，但用户已经向上滚动并且当前查看区域不包括聊天线程末端)。因为所述位置在查看区域之外，所以应用内通知550是可能的。应用内通知550提供以下视觉指示符：用户能够在查看区域之外但在应用窗口520内的位置得到可呈现信息(例如，所述通知包括以下描述：接收到新的文本并且能够在向下滚动至聊天线程末端时得到)。

图6说明根据本公开的实施方案的流内通知的示例。一般来讲，当前台中的活动的流向用户传送和提供关于正在执行的流的一个或多个任务的反馈时，使用流内通知。

如所说明，GUI 610呈现在显示器上。应用在执行(例如，视频游戏应用)并且在GUI610上的应用窗口620中呈现关于流的内容(例如，下载、安装或购买视频游戏应用、视频游戏关卡、另一应用或任何其他内容)。

接收通知数据(例如，从网络源接收下载的进度)。确定所述通知数据与所述应用(例如，视频游戏应用)相关联，并且与流(例如，下载)相关联。因此，确定呈现流内通知650。流内通知650提供关于流的进度和/或正在执行的任务的视觉指示符。流内通知650呈现在应用窗口620内并且经更新以反映所述进度。一旦流完成(例如，下载完成)，流内通知650经更新以呈现与所述流相关的可选择动作(例如，用以启动所下载的应用的启动按钮)。

图7说明根据本公开的实施方案的弹出通知的示例。一般来讲，当通知数据不与在前台中的应用窗口中呈现内容的应用(例如，活动应用)相关联时并且当通知数据是时间敏感和/或与用户和/或应用的上下文相关时，使用弹出通知。弹出通知呈现在平铺在应用窗口上的弹出窗口中。内容的呈现在应用窗口中继续，并且用户焦点仍在应用上(例如，使用控制器处的用户输入与所呈现的内容交互)。

如所说明，GUI 710呈现在显示器上。应用在执行(例如，聊天应用)并且在GUI 710上的应用窗口720中呈现内容(例如，聊天内容)。所呈现的内容与主题722(例如，聊天线程)相关。另外，第二窗口730呈现在GUI 410上，并且提供关于其他应用(例如，最近执行的视频游戏)的信息。

在一个示例中，接收通知数据(例如，系统通知、与最近执行的视频游戏应用相关联的数据等)。确定通知数据不与应用相关联(例如，聊天应用不是通知数据的目的地)。因此，确定不呈现上下文内通知。在另一示例中，通知数据与应用相关联。然而，在此示例中，确定通知数据不与主题722相关联(例如，通知数据与不同的聊天线程相关)。因此，在此示例中也确定不呈现上下文内通知。

接下来，确定是否应呈现弹出通知750。如果通知数据与不同的线程或第二窗口730相关联、是系统通知或者是关于敏感任务的完成、任务失败或远程地发起并且在用户登入呈现GUI 710的装置时仍然在处理的任务的反馈，则确定可以是呈现弹出通知750。弹出通知750可平铺在应用窗口720上或位于GUI 720的任何其他区域上。例如，通知750可在GUI720的顶侧上从右向左滑动或者可在GUI 720的顶侧上从上到下滑动。如果另一弹出通知已经呈现在GUI 720上，则可在现有的弹出通知下方展示新的弹出通知750，或者所述新的弹出通知可滑动并且将现有的弹出通知向下推。

一般来讲，当呈现上下文内通知或弹出通知时，活动应用的执行继续，并且前台中的应用窗口中的活动应用对内容的呈现也继续。可依据通知的类型而将不同类型的信息用于所述通知。例如，直插通知可在视觉上指示通知数据能够在用户查看区域内的位置处得到。应用内通知可在视觉上指示通知数据能够在用户查看区域之外并且可不包括通知数据的位置处得到。相比之下，流内通知或弹出通知可包括所述通知数据中的一些或全部。另外，可依据通知的类型而使用通知的不同状态。例如，可根据一个状态而呈现直插通知，而可根据多个可能的状态中的一者而呈现其他类型的通知。如果使用多个状态，则可呈现信息的类型和/或量在状态之间改变。

图8说明根据本公开的实施方案的通知的状态的示例。第一状态对应于折叠状态，其中呈现最少信息以向用户提示接收通知数据。第二状态对应于展开状态，其中可呈现通知数据中的一些或全部。

在一个示例中，以折叠状态810呈现通知。在此状态810下，通知包括标头812，所述标头一般识别通知的类型和/或标题(例如，针对聊天通知的“来自朋友的文本消息”)。

在展开状态850下，通知的大小得以增加，并且其内容得到更新以提供补充信息。例如，通知包括标头852(其可与标头812相同；换句话说，所述标头中的大小和可呈现信息在状态之间不改变)。所述通知还包括主体854和动作856。主体854提供从通知数据得到的补充信息(例如，来自文本消息的实际文本)。动作856表示可触发相关应用以执行任务或触发流的可选择图标(例如，用于对文本消息作出响应的响应图标)。如果选择了动作856，则可呈现和使用相关应用的应用窗口，或者可在提供此类应用窗口的功能性的第三状态下展示通知。

一旦呈现了通知，无论在折叠状态810还是展开状态850下，其内容(例如，标头、主体和/或动作中的信息)便可随时间更新。例如，当呈现流入通知时，此类通知的主体可展示流的进度并且依据进度的状态进行更新。

图9说明根据本公开的实施方案的用于呈现上下文内通知的流的示例。可将流的操作实施为硬件电路和/或作为计算机可读指令存储在诸如视频游戏系统或后端服务器的计算机系统的非暂时性计算机可读介质上。在实施时，指令表示包括电路的模块或能够由计算机系统的处理器执行的代码。此类指令的执行会配置计算机系统以执行本文描述的特定操作。每个电路或代码与处理器的组合表示用于执行相应操作的构件。虽然以特定顺序说明操作，但应理解，不要求特定顺序。

如所说明，流在操作902处开始，其中计算机系统在应用窗口中呈现内容。例如，应用在执行并且在显示器的GUI上的应用窗口中呈现内容。

在一个示例中，在操作904处，计算机系统接收通知数据。所述通知数据是从另一装置接收并且与上下文相关联。所述上下文指示源应用、目的地应用、通知类型和/或通知主题以及其他属性。上下文还可指示其他信息。

在一个示例中，在操作906处，计算机系统确定通知数据是否与应用相关联。具体地，如果通知数据的目的地应用与所述应用相同，则确定通知数据与所述应用相关联。在此情况下，操作908跟在操作906之后。否则，操作912跟在操作906之后。

在一个示例中，在操作908处，计算机系统确定应用窗口是否在前台中。如果是，则通知数据与活动应用相关联，并且相应地确定呈现上下文内通知。在此情况下，操作910跟在操作908之后。否则，操作912跟在操作908之后。

在一个示例中，在操作910处，计算机系统在应用窗口内呈现上下文内通知。不同类型的上下文内通知是可能的。在图解中，如果通知数据能够在应用窗口的用户查看区域内的位置呈现，则使用直插通知。如果通知数据能够在用户查看区域之外的位置呈现，则使用应用内通知。如果通知数据涉及已经触发的流并且应用窗口呈现关于所述流的信息，则使用流内通知。

在一个示例中，在操作912处，计算机系统已经确定通知数据不与活动应用相关联和/或应用窗口不在前台中。因此，计算机系统确定应约束对上下文内通知的呈现。而是，计算机系统可确定是否应呈现弹出通知，是否应将通知数据发送至队列以便添加至通知概要和/或是否应将通知发送至通知列表。执行此确定的不同技术是可能的。在一种示例性技术中，使用一组规则来确定是否应使用弹出通知。否则，可将通知数据添加至通知概要和/或通知列表。所述一组规则一般指定如果通知是时间敏感的和/或具有与用户的一定相关水平，则应使用弹出通知。例如，如果与通知数据相关的活动、更新或事件出现在后台中或在后台中呈现的应用窗口中，则可使用弹出通知。类似地，如果反馈是关于敏感任务的完成、任务失败或远程地发起并且在用户登入装置时仍然在处理的任务，则也可使用弹出通知。否则，可将通知数据添加至通知概要和/或通知列表。在另一示例性技术中，可使用操作模式。此处，所述操作模式可与指示是准许还是约束弹出通知的通知设置相关联。在准许的情况下，呈现弹出通知。否则，可将通知数据添加至通知概要和/或通知列表。结合接下来的图进一步描述操作模式的使用。

在对流的以上描述中，通知数据与应用关联以及所述应用在前台应用窗口中呈现内容是匹配的上下文的示例。使用上下文和/或其他类型的上下文的其他方式也是可能的。

在一个示例中，计算机系统可确定在与通知数据相关联的上下文和与应用相关联的上下文之间是否存在匹配。如果存在匹配，则计算机系统可确定在操作910下说明的上下文内通知的呈现式样(例如，直插呈现式样、应用内呈现式样和/或流内呈现式样)。否则，计算机系统可确定应呈现弹出通知，或者将使用约束对上下文内应用的呈现的某一其他形式。在这里在此示例中，与通知数据相关联的上下文包括以下各项中的至少一者：与应用的第一用户相关联的第一用户标识符；与生成通知数据的源应用的第二用户相关联的第二用户标识符；通知数据的主题；通知数据的类型；与应用相关联的第一应用标识符；与第二应用相关联的第二应用标识符；与托管应用的第一平台(例如，视频游戏平台)相关联的第一平台标识符；或与托管源应用的第二平台(例如，社交媒体平台)相关联的第二平台标识符。与应用相关联的上下文包括以下各项中的至少一者：第一用户标识符；第一应用标识符；第一平台标识符；操作模式；或应用窗口是在显示器的前台中的指示。当例如第一用户标识符在两个上下文中相同(或可被映射至同一用户账户)，第一应用标识符在两个上下文中相同和/或第一平台标识符在两个上下文中相同时，存在匹配。当操作模式和/或前台状态指示通知数据的主题、通知数据的类型、第二用户标识符、第二应用标识符和/或第二平台标识符与呈现通知数据的许可相关联(例如，在例外列表上)时，也存在匹配。

可在操作906和/或908下通过其他方式类似地使用这些上下文中的一些或全部。例如，可进一步使用通知源、通知类型和/或通知主题来确定是否应呈现上下文内通知。如果通知源在准许应用的例外列表上，则可呈现上下文内通知。另外或可替代地，如果通知类型与准许类型匹配和/或通知主题与在前台应用窗口中呈现的内容的主题匹配，则可呈现上下文内通知。为了说明，活动应用是在第一用户的第一装置上运行的聊天应用。第二用户操作第二装置以执行聊天应用的另一实例并且发送文本作为通知数据。假设通知源(例如，聊天应用的另一实例)和通知类型(例如，聊天)被许可，则在文本对应于进行中的聊天线程的情况下可呈现上下文内通知。否则，使用弹出通知。

其他类型的上下文也是可能的。用户上下文和应用上下文是此类可能的上下文的示例。用户上下文指示用户对内容的关注(或专注)水平。可使用不同的技术来确定此水平。在一种示例性技术中，装置的操作模式指示用户关注水平。例如，观看电影的用户可对应于比玩视频游戏的用户更低的关注水平。在另一示例性技术中，内容的类型指示用户关注水平。例如，玩国际象棋视频游戏的用户可对应于比玩第一人称射击视频游戏的用户更低的关注水平。在另一技术中，由眼睛跟踪系统检测到的凝视信息或由运动跟踪系统检测到的运动数据可指示用户关注水平。例如，指示用户未看向GUI的凝视信息或指示相对低的运动水平的运动信息可对应于比当凝视在GUI上或检测到较高的运动水平时更低的关注水平。应用上下文指示用户与应用交互的水平。还可使用不同的技术来确定此水平。在一种示例性技术中，装置的操作模式指示用户交互水平。例如，在电影模式下，预期与游戏模式相比之下的相对更低的用户交互水平。在另一示例性技术中，内容的类型指示用户关注水平。例如，对于国际象棋视频游戏，预期与第一人称射击视频游戏相比之下的相对更低的用户交互水平。在另一技术中，在输入装置(例如，视频游戏控制器)处接收的用户输入的数量和/或频率指示用户交互水平。数量越大和/或频率越高，用户交互水平越高。

在给定的用户上下文和/或应用上下文的情况下，可定义触发特定类型的上下文内通知或弹出通知或使用通知概要或通知列表的规则。例如，如果用户关注水平和/或用户交互水平较高(例如，超过预定义的阈值水平)，则仅在通知数据涉及用户参与的活动(例如，与活动应用相关联)的情况下才展示上下文内通知。否则，在通知数据是时间敏感的或与用户上下文和/或应用上下文相关的情况下使用弹出通知。而且除此之外，将通知数据发送至通知概要和/或通知列表。

此外，以上流是结合可作为一组规则存储的条件语句来说明的。所述条件语句可以是预定义的并且基于用户输入而手动地更新以反映用户偏好和/或用户设置。另外，可由计算机系统自动学习此类规则和/或其他类型的规则。例如，可针对用户以及跨不同的用户跟踪关于用户上下文和/或应用上下文的数据。基于此类数据来训练机器学习(ML)算法以输出定义规则的参数。然后可将此类规则推向计算机系统或者所训练的ML算法自身可托管在计算机系统上，由此用户上下文和/或应用上下文用作输入，并且接收到指示是否应呈现通知和通知类型的输出。

图10说明根据本公开的实施方案的装置的操作模式的示例。所述装置在显示器上呈现GUI 1010。GUI 1010包括与通知设置相关的不同字段。第一字段1020对应于通用设置，第二字段1030对应于操作模式，并且第三字段对应于通知类型(说明为不同的通道，诸如提供社交媒体通知的社交媒体通道，提供游戏通知的游戏通道、提供媒体和事件通知的媒体和事件通道、提供下载和上传通知的下载和上传通道、提供促销和出价通知的促销和出价通道等)。可选择所述三个字段中的每一者以进一步呈现可在选定字段下定义的通知设置。图10说明了对操作模式字段1030的选择。

如所说明，多个操作模式是可能的(图10示出了此类模式中的四个模式)。可在不同字段1032中识别此类模式，并且可选择此类字段中的每一者以进一步呈现适用于对应的操作模式的通知设置，如在图11中进一步说明。每个模式指示装置的一个操作模式。在此类模式中的每一者内，可预期不同的用户上下文和/或不同的应用上下文。换句话说，用户关注水平和/或用户交互水平可在操作模式之间改变。可在操作模式之间改变通知设置以反映此改变。

为了说明，装置是视频游戏控制台。操作模型包括游戏模式、按需内容模式(例如，电影和视频模式)、内容广播模式或虚拟现实模式。在游戏模式下，可预期相对于按需内容模式或内容广播模式的更高的用户关注水平和/或用户交互水平，但低于虚拟现实模式的用户关注水平和/或用户交互水平。

图11说明根据本公开的实施方案的与操作模式相关联的通知设置的示例。例如，在用户选择了在图10的字段1032中呈现的“操作模式A”之后，呈现适用于选定操作模式的通知设置。

在一个示例中，GUI 1110识别操作模式1120并且呈现示出了不同通知类型1130(例如，下载完成、上传完成、朋友在线、邀请至游戏、邀请至广播、音轨改变、组活动等)的例外列表。可选择此类通知类型1130中的每一者。例如，可在每个通知类型旁边显示复选框1140，并且当选中时指示选择了通知类型。对来自例外列表的通知类型的选择会指示：当接收到通知数据并且通知数据与选定通知类型相关联时，可在装置处于操作模式1120时呈现对应的通知(是上下文内还是弹出)。换句话说，操作模式1120与例外列表相关联，并且仅当选择例外列表上的通知类型时可呈现对应的通知。如果未选择通知类型，则对应通知的呈现受约束。

尽管图11说明了例外列表，但可使用其他类型的列表。例如，许可列表是可能的。当未选择所述许可列表下的通知类型时，准许对应通知的呈现。如果选定，则通知的呈现受约束。另外，尽管说明了通知类型，但可以使用其他参数来定义每个操作模型的许可和约束。例如，例外列表可识别源应用、目的地应用和/或源应用和/或目的地应用的类型(例如，社交媒体应用、游戏应用等)。如果选择这些参数中的任一者，则与选定参数相关联的通知数据(例如，与选定的源应用、目的地应用或应用类型相关联的通知数据)可导致对应通知的呈现。

所述操作模式中的每一者可与其自身的一组通知设置相关联。此类设置可被设置为某些默认配置(例如，默认选择和默认的通知类型)。还可接收用户输入以改变所述默认配置(例如，以取消选择选定的通知设置以及选择未选定的通知设置)。另外，可从计算机系统(例如，其包括后端服务器)推送对默认或定制的配置的改变。在一个示例中，为了支持推送，计算机系统自动学习所述改变。例如，可在所述操作模式中的每一者下针对用户以及跨不同的用户跟踪关于用户上下文和/或应用上下文的数据。基于此类数据来训练ML算法以输出定义配置的参数。

在一个示例中，装置处于与通知设置相关联的操作模式下。接收通知数据。相对于通知设置而选中与通知数据相关联的通知类型(并且另外或可替代地，源应用、目的地应用、源应用的类型、目的地应用的类型)。如果通知设置准许呈现对应的通知，则进一步使用通知数据来呈现上下文内通知或弹出通知。否则，可将对应的通知发送至用于添加至通知概要的队列，或者可添加至通知列表，使得可在不同的时间点检索和呈现所述通知。

通知概要支持根据优先级来组织尚未示出的通知以及向用户呈现最高优先级通知的子集以及用以查看其余通知的选项。图17至图20描述了通知概要的示例。相比之下，通知列表表示组织通知的不同方式，如在图12至图16中进一步说明。一般来讲，通知列表包括具有不同属性(例如，不同的通知类型，与不同的源应用和/或目的地应用相关联等)的通知。另外，在通知列表中，可使用其他通知对通知进行替换、替换并累加、修改和/或分组，使得当向用户呈现所述通知列表时，呈现最新的通知。另外，通知在某一上下文的情况下被添加至通知列表(例如，在装置处于约束呈现的特定操作模式的情况下)，可随后在所述上下文改变(例如，装置改变为准许呈现的不同操作模式)时呈现为上下文内通知或弹出通知。因此，替换、替换与累加、修改和分组操作还可影响上下文内通知和弹出通知的呈现。

图12说明根据本公开的实施方案的替换通知的示例。通知替换表示以下方法：移除第一通知并且第二通知替换所述第一通知。一般来讲，第二通知具有比第一通知更近的时间戳。通知替换可产生新的通知(例如，上下文内或弹出)，并且可将此类通知放置在通知列表的顶部处。

在一个示例中，通知替换不包括被替换的前一通知的任何信息或指示。因此，此替换方法通常在向用户告知已经被替换的先前内容不再有价值的情况下使用。可定义一组规则来反映此方法。例如，当先前内容过时(例如，其时间戳是在过去)或不再相关(例如，通知数据与不再活动的应用相关联)时，使用通知替换。当被替换的内容是关于流内的任务的状态(例如，下载曾在进行中并且现在完成)时，也使用通知替换。当通知数据包括被更新的信息但所述更新不影响通知数据的相关度时(例如，当通知数据指示视频游戏队伍的名称第三次改变时，其中数量“二”不影响相关度)，也使用通知替换。

如图12中说明，第一通知1210涉及任务(例如，下载)。第一通知1210具有第一时间戳(例如，两小时)并且指示任务状态(例如，下载开始)。随着任务进行，接收到指示任务的进度的附加的通知数据。因为通知数据是关于任务状态，所以使用通知数据来替换第一通知1210。具体地，第二通知1250替换第一通知1210，并且具有指示那个时间戳处的状态(例如，下载在三分钟前完成)的第二时间戳(例如，三分钟)。

因此，如果将通知1210添加至通知列表，则更新所述通知列表以替代地包括第二通知1250。第二通知1250根据所述第二时间戳而布置在所述通知列表中。类似地，如果第一通知1210呈现为上下文内通知或弹出通知，则更新所述呈现以替代地示出第二通知1250。

图13说明根据本公开的实施方案的替换与累加通知的示例。通知替换与累加是通知替换的另一方法。此处，除了替换通知之外，所述方法使用计数器(例如，累加参数)将已经执行替换的次数加起来。因此，可不仅向用户通知已经替换了通知，而且可通知已经存在关于所替换的通知的附加的活动。对计数器的呈现可在通知内、与所述通知分开或在不呈现通知的情况下单独展示。

在一个示例中，当先前内容未过时和/或仍然具有相关度时，使用通知替换与累加。另外，当计数器的值的数量可影响所替换的内容的所感知的重要性时，使用通知替换与累加。

如图13中说明，第一通知1310涉及事件(例如，由用户在社交媒体平台上贴出的照片)。第一通知1310具有第一时间戳(例如，两小时)并且包括关于所述事件的通知数据(例如，朋友A对照片点赞)。随着时间的推移，接收其他通知数据并且所述其他通知数据涉及同一事件。例如，在不同的时间接收到指示来自三个其他朋友的照片点赞的第二通知数据、第三通知数据和第四通知数据。最新的通知数据(第四个，来自朋友B的照片点赞)具有第四时间戳(例如，三分钟)并且用作最后的替换。另外，每当接收到通知数据中的一者时便增加计数器，并且因此其当前值是三。因此，新的通知1350替换第一通知1310并且具有第四时间戳。新的通知1350包括最新的通知数据(例如，来自朋友D的照片点赞)并且展示计数器的最新的值(例如，另外三个)。

因此，如果将通知1310添加至通知列表，则更新所述通知列表以替代地包括新的通知1350。新的通知1350根据第四时间戳而布置在所述通知列表中。类似地，如果第一通知1310呈现为上下文内通知或弹出通知，则更新所述呈现以替代地示出新的通知1350。

图14说明根据本公开的实施方案的修改通知的示例。通知修改表示以下方法：通知在未在前台中通知用户的情况下具有添加至所述通知的附加的通知数据。此方法不向用户重新通知改变并且将在通知列表内以通知的时间顺序维持所述通知。

在一个示例中，当现有的通知尚未呈现并且附加的通知数据不影响最初的通知数据的相关度或时间敏感度时，或者当附加的通知数据将去往同一目的地应用并且包括与最初的通知数据相同的动作时，使用通知修改。还使用通知修改来避免生成新的通知并且改变其在通知列表中的顺序。

如图14中说明，第一通知1410涉及事件(例如，邀请去游戏)。第一通知1410具有第一时间戳(例如，两小时)并且包括关于所述事件的通知数据(例如，来自朋友A的游戏邀请)。随后，接收附加的通知数据，所述附加的通知数据涉及所述事件，并且不改变第一通知的相关度。例如，附加的通知数据指示朋友A仍然在等待对游戏邀请的接受或拒绝。因此，呈现经修改的通知1450，其中此经修改的通知1450与第一通知1450相同，不同之处在于其内容已经改变(例如，指示朋友A仍然在等待)。可在经修改的通知1450中示出第一通知1410的时间戳。

图15说明根据本公开的实施方案的将通知分组的示例。通知分组表示以下方法：将一个通知与至少另一通知分组在一起。将通知分组在一起，但视为单独的通知。此方法允许用户查看通知活动的高级概要。当在通知列表中查看时，仍然单独地并且按照时间顺序显示通知。

在一个示例中，当通知共享至少一个共同属性时，使用通知分组。例如，当多个通知具有相同的通知类型(例如，聊天消息)时，在对应于通知类型的组下将所述通知分组在一起。类似地，当多个通知与同一源应用、目的地应用和/或源应用和/或目的地应用的类型相关联时，可将这些通知分组在一起。

如图15中说明，将第一组1510通知添加至通知列表。第一组1510包括具有第一时间戳(两小时以前)的第一聊天通知、具有第二时间戳(一小时以前)的社交媒体通知以及具有第三时间戳(三十分钟以前)的第二聊天通知。所述两个聊天通知被分组在一起，但社交媒体通知未进行分组。所述分组不更改通知或它们的时间戳中的任一者。因此，在完成分组之后，定义第二组1550通知。第二组1550表示对第一组1510的重新组织。在第二组1550中，第一聊天通知和第二聊天通知根据它们的时间顺序被分组在一起(例如，首先列出第一聊天通知)。

图16说明根据本公开的实施方案的用于根据操作模式来呈现通知的流的示例。可将流的操作实施为硬件电路和/或作为计算机可读指令存储在诸如视频游戏系统或后端服务器的计算机系统的非暂时性计算机可读介质上。在实施时，指令表示包括电路的模块或能够由计算机系统的处理器执行的代码。此类指令的执行会配置计算机系统以执行本文描述的特定操作。每个电路或代码与处理器的组合表示用于执行相应操作的构件。虽然以特定顺序说明操作，但应理解，不要求特定顺序。

如所说明，流在操作1602处开始，其中计算机系统在应用窗口中呈现内容。例如，应用在执行并且在与装置通信地耦合的显示器的GUI上的应用窗口中呈现内容。所述装置可以是计算机系统的计算部件。

在一个示例中，在操作1604处，计算机系统接收通知数据。所述通知数据是从另一装置接收并且与源应用、目的地应用、通知类型和/或通知主题以及其他属性相关联。

在一个示例中，在操作1606处，计算机系统确定装置的操作模式。一般来讲，操作模式对应于在接收通知数据的时间点处或在包括此时间点的时间窗口中的装置的操作模式。可使用不同的技术来确定操作模式。在一种示例性技术中，接收用户输入以启动操作模式。此用户输入表示用户对操作模式的选择。在另一示例性技术中，所述确定不需要依赖于用户选择。而是，基于正在呈现的内容的类型、内容的标题、内容的来源、应用的类型、用户关注水平和/或用户交互水平来确定操作模式。例如，当内容表示视频游戏内容并且用户交互水平指示用户正在主动地玩视频游戏时，确定视频游戏模式。

在一个示例中，在操作1608处，计算机系统确定通知是否对应于应呈现的通知数据。具体地，通知模式与通知设置相关联。通知设置可指定基于诸如源应用、目的地应用、通知类型和/或通知主题的通知数据的属性而是否准许呈现通知。如果准许，则操作1610跟在操作1608之后。否则，操作1612跟在操作1608之后。

在一个示例中，在操作1610处，计算机系统将通知呈现为上下文内通知或弹出通知。可以使用一组规则来确定通知的类型，如上文结合图4至图9所描述。

在一个示例中，在操作1612处，计算机系统已经确定应约束对通知的呈现。因此，计算机系统将通知发送至通知列表(或发送至通知概要，如结合接下来的图所描述)。

在一个示例中，在操作1614处，计算机系统更新通知列表中的通知。不同类型的更新是可能的，包括通知替换、通知替换与累加、通知修改和/或通知分组。所述更新可取决于通知的属性和一组更新规则，如上文结合图12至图15所描述。

在一个示例中，在操作1616处，计算机系统呈现通知列表。触发此呈现的不同触发是可能的。在一个图解中，接收用户输入并且所述用户输入指示对通知的请求。具体地，可在GUI上呈现可选择的图标并且用户对此图标的选择指示所述请求。在通知列表中以折叠状态示出各种通知并且所述通知根据它们的时间顺序进行布置。用户对这些通知中的一者的选择将所述通知的呈现改变为展开状态。

如上文在操作1608和1612中所指示，如果与操作模式相关联的通知设置指示对通知的呈现受约束，则可不呈现此通知并且替代地将所述通知添加至通知列表。然而，可能存在计算机系统确定操作模式改变为与第二组通知设置相关联的第二操作模式的情况。在此情况下，计算机系统确定所述第二组是否准许所述呈现。如果是，则呈现通知并且从通知列表移除所述通知。例如，当处于操作模式时，可能已经接收到通知并且未呈现所述通知。在确定改变为第二操作模式之后，计算机系统可确定一组此类通知并且至少呈现被接收且未被呈现的通知的子集。此处，呈现(例如，呈现哪些通知、此类通知的总数、呈现式样以及其他呈现因素)可取决于第二操作模式的通知设置。

以上流是结合通知设置和规则来说明。通知设置和规则可以是预定义的并且基于用户输入而手动地更新以反映用户偏好和/或用户设置。另外，可由计算机系统自动学习此类通知设置和规则。例如，可在不同的操作模式下针对用户以及跨不同的用户跟踪关于用户上下文和/或应用上下文的数据。基于此类数据来训练ML算法以输出定义通知设置和规则的参数。然后可将此类通知设置和规则推送给计算机系统或者所训练的ML算法自身可托管在计算机系统上，由此用户上下文和/或应用上下文用作输入，并且接收到指示是否应呈现通知和通知类型的输出。

图17说明根据本公开的实施方案的根据操作模式的通知概要的示例。一般来讲，应用可执行并且在GUI上的应用窗口中呈现内容。在确定不应在通知(上下文内或弹出)中呈现通知数据之后，可将通知数据添加至队列。可从所述队列生成通知概要，其中所述通知概要包括尚未呈现的通知。这些通知可具有不同属性(例如，不同的通知类型，与不同的源应用和/或目的地应用相关联等)。概要中的通知基于它们的优先级来组织。可基于通知的相关度和新近度来定义通知的优先级。随着时间的推移，优先级可改变并且通知可被重新组织。通知概要可在诸如折叠状态的第一状态下呈现在GUI上，从而指示通知概要中的通知的总数。在用户选择通知概要之后，通知概要以诸如展开状态的第二状态呈现，从而示出所述通知中的一些或全部。以此方式，用户可快速地确定未示出的通知的总数并且可快速且有效地访问最高优先级通知。

如图17中说明，应用(例如，视频游戏应用)在显示器的GUI 1710上的应用窗口1720中呈现内容(例如，视频游戏内容)。接收对应于多个通知的通知数据。在给出特定上下文(例如，通知数据不与应用相关联并且应用窗口1720在前台中)的情况下，确定不呈现所述通知。而是，通知概要1730以第一状态呈现在GUI 1710上，从而指示所述通知被接收并且可查看。

在一个示例中，通知概要1730呈现在应用窗口1720之外的弹出窗口中。在另一示例中，通知概要1730呈现在至少部分地在应用窗口1720上的弹出窗口中。在另一示例中，通知概要1730作为动态图标呈现在GUI 1710的预定义区域(例如，右上隅角)中，从而示出通知的总数。在另一示例中，在特定上下文改变之前不呈现通知概要1730。例如，一旦应用停止执行或应用窗口1720移动至后台，便呈现通知概要1730。

在用户与通知概要1730的指示用户选择的交互之后，以第二状态呈现通知概要1730(图17将处于第二状态的通知概要1730说明为通知概要1750)。在第二状态下，可呈现与通知相关的附加的信息。例如，识别通知中的一者或多者。

图18说明根据本公开的实施方案的通知概要的状态的示例。在一个示例中，多个状态是可能的，并且可在每个状态下示出不同水平的信息。

第一状态1810对应于折叠状态并且示出了通知概要的标头。所述标头指示通知尚未呈现(例如，通过包括诸如以下文本：“当您[离开/在游戏/在查看等]时……”)和此类通知的总数(例如，“八个新的通知”)。另外，所述标头可指示呈现通知概要的原因。可存在不同的原因，这一般取决于用户上下文和/或应用上下文，并且对应于导致将通知排队而不是立即呈现所述通知的状况。例如，通知概要呈现在耦合到计算装置的显示器上。一个原因对应于阻止即时呈现的计算装置的操作模式(例如，“当您在游戏时接收到八个通知”)。另一原因对应于当计算装置断电时接收到一个或多个通知(例如，“当您离开时接收到八个通知”)。另一原因对应于相关用户未登入到计算装置上(例如，“当您退出时接收到八个通知”)。以此方式，通知概要和通知概要的原因同时在第一状态1810下呈现。

第二状态1840对应于展开状态，并且示出了标头、通知的选定子集的预览以及未在预览中的其余通知的总数。标头可保持相同或可经修改(例如，不包括文本，不需要但可示出通知概要的原因等)。尽管如此，标头通常示出位于通知概要中的通知的总数。选定子集对应于预定义数目的最高优先级通知(例如，前三个通知)。预览示出了处于折叠状态的每个此类通知(如结合图8所描述)。在通知概要的底部处，示出其余通知的总数，并且此数目对应于通知概要中的通知的总数减去预览中的通知的总数(例如，“五个其余通知”)。

如上文阐释，通知在预览中以折叠状态从通知概要呈现。可接收用户输入并且所述用户输入可指示用户对通知的选择。作为响应，通知可以展开状态呈现。用于以展开状态呈现通知的不同技术是可能的。在一种技术中，进一步展开通知概要(例如，增加其窗口的大小)，并且所展开的通知仍然呈现在所述通知概要内(例如，通过从预览将其他通知向下推而在所述窗口内)。在另一技术中，在单独的窗口中从通知概要示出展开的通知。在此情况下，可通过从通知概要移除通知来更新所述通知概要。

第三状态1870还对应于展开状态。然而，此处预览所有通知而不是子集。如果预览通知需要比通知概要的窗口更大的区域，则可以使用滚动机制来滚动通过通知。这些通知根据它们的优先级来组织，其中在通知概要的顶部处预览最高优先级通知，并且在通知概要的底部处预览最低优先级通知。

图19说明根据本公开的实施方案的汇总通知的示例。在一个示例中，通知根据它们的优先级来组织。在展开状态下，通知概要预览通知的子集，其中基于优先级来选择所述子集。可将通知的优先级定义为其相关度和其新近度中的任一者或两者。相关度指示通知与诸如用户上下文和/或应用上下文的当前上下文的相关程度。新近度指示当前时间与接收到对应的通知数据的时间之间的差异。

如所说明，已经将一组1910通知(或通知数据)排队(图19示出了八个通知)。此类通知中的每一者与表示在接收到对应的通知数据时的时间点的时间戳相关联。可将通知的新近度确定为当前时间与所述时间戳之间的差异(例如，如所说明，“通知A”具有一分钟新近度，从而指示在一分钟以前接收到对应的通知数据)。

可使用不同的技术来确定通知的相关度。在一种技术中，相关度取决于通知的类型。具体地，可根据每个通知类型(或通知类型的任何其他属性，诸如源应用、目的地应用、计数器、源应用和/或目的地应用的类型等)来预定义相关度。例如，如果通知是视频游戏通知，则其相关度高于社交媒体通知的相关度，所述社交媒体通知又高于促销通知。在另一技术中，相关度可依据操作模式而改变。具体地，每个操作模式可与每个通知类型(或任何其他属性)的预定义的相关度相关联。例如，如果操作模式是社交媒体模式，则社交媒体通知与最高相关度相关联。在另一技术中，相关度取决于通知是否与在前台或后台中具有应用窗口的应用相关联。如果在前台中，则相关度高于与后台应用窗口相关联的通知的相关度。在另一技术中，相关度取决于用户上下文和/或应用上下文。如果此类上下文指示活动、事件、更新或反馈并且如果通知与活动、事件、更新或反馈相关联，则增加其相关度。例如，如果用户上下文指示用户注意力在视频游戏内容上并且如果应用上下文指示用户与特定视频游戏应用交互，则与视频游戏应用相关的通知具有比与另一视频游戏应用相关的通知更高的相关度，与另一视频游戏应用相关的所述通知又具有比与非视频游戏应用相关的通知更高的相关度。在另一技术中，当将通知数据发送至队列并且将对应的第一通知添加至通知概要时，还可将通知数据发送至用户的第二装置，诸如发送至用户的移动装置。监测用户与第二装置上的对应的第二通知的交互。如果呈现所述第二通知，则将通知概要中的第一通知的相关度减小至最小，或甚至从通知概要移除所述第一通知。如果消除所述第二通知而不呈现，则可将第一通知的相关度减小至预定义水平(但不是最小)。如果未检测到用户与第二通知的交互，则不改变第一通知的相关度。在另一技术中，可以使用ML算法来生成通知的相关度。具体地，可针对用户以及跨不同的用户跟踪关于用户上下文和/或应用上下文的数据以及如何呈现和消除或约束且随后查看通知。基于此类数据来训练ML算法以输出通知的相关度。

随着时间的推移，通知概要中的通知的优先级基于所述通知的相关度和新近度中的一者或两者而改变。在时间间隔(例如，每五分钟)下或当检测到优先级改变时，可重新布置通知概要中的通知。另外或可替代地，在当将要在GUI上呈现通知概要时的时间点处，确定通知的最新的优先级并且相应地重新布置这些通知。

在一个示例中，首先基于指派给每个通知的相关度来组织通知概要。然后基于新近度对通知进行排序(例如，最新的消息在较老的消息上方展示)。可在预览通知概要时呈现预定义数目(例如，三个)的最高优先级通知(例如，通知概要中的前三个通知)。

如图19中说明，可以展开状态呈现一组1910通知的通知概要1950，所述展开状态还指示呈现通知概要1950的原因。在呈现时，“通知D”具有最高相关度，紧接着是“通知A”和“通知G”，尽管“通知A”是在“通知D”之前接收的。

图20说明根据本公开的实施方案的用于汇总和呈现通知的流的示例。可将流的操作实施为硬件电路和/或作为计算机可读指令存储在诸如视频游戏系统或后端服务器的计算机系统的非暂时性计算机可读介质上。在实施时，指令表示包括电路的模块或能够由计算机系统的处理器执行的代码。此类指令的执行会配置计算机系统以执行本文描述的特定操作。每个电路或代码与处理器的组合表示用于执行相应操作的构件。虽然以特定顺序说明操作，但应理解，不要求特定顺序。

如所说明，流在操作2002处开始，其中计算机系统在应用窗口中呈现内容。例如，应用在执行并且在与装置通信地耦合的显示器的GUI上的应用窗口中呈现内容。所述装置可以是计算机系统的计算部件。

在一个示例中，在操作2004处，计算机系统接收通知数据。所述通知数据是从另一装置接收并且与源应用、目的地应用、通知类型和/或通知主题以及其他属性相关联。可以使用通知数据在GUI上呈现通知。

在一个示例中，在操作2006处，计算机系统确定是否将通知排队。具体地，计算机系统确定对通知的呈现受约束(例如，通知将不被呈现为上下文内通知或弹出通知)。用以确定是约束还是呈现通知的不同技术是可能的，如上文描述。如果应约束通知，则计算机系统可确定是否将通知排队。在图解中，计算机系统基于确定通知数据不与应用相关联并且在显示器的前台中呈现应用窗口而确定将通知排队。在另一图解中，计算机系统基于确定通知数据与应用相关联并且在显示器的后台中呈现应用窗口而确定将通知排队。如果将要呈现通知，则操作2008跟在操作2006之后。否则，操作2010跟在操作2006之后。

在一个示例中，在操作2008处，计算机系统将通知呈现为上下文内通知或弹出通知。可以使用一组规则来确定通知的类型，如上文结合图4至图9所描述。

在一个示例中，在操作2010处，计算机系统在第一时间点处将通知发送至通知队列。所述队列中的通知中的每一者与通知优先级相关联。可将所述通知优先级定义为相关度和新近度。

在一个示例中，在操作2012处，计算机系统在第二时间点处更新所述队列中的通知。例如，如上文结合图19所描述来更新每个通知的相关度。还基于所述通知的时间戳来更新每个通知的新近度。所述通知根据它们的相关度而被重新组织(例如，进行排名)并且根据它们的新近度而被排序。

在一个示例中，在操作2014处，计算机系统选择通知的子集。例如，应选择预定义数目(例如，三个)的通知。选择三个最高优先级(或预定义数目的)通知并且形成所述子集。

在一个示例中，在操作2016处，计算机系统生成通知概要。所述通知概要包括根据优先级而组织的各种通知。所述通知概要还可包括指示通知的总数的标头、通知的子集的预览以及指示其余通知的总数的页脚。

在一个示例中，在操作2018处，计算机系统呈现通知概要。例如，以示出标头的第一状态呈现通知概要。基于用户与标头的交互，以进一步示出预览和页脚的第二状态呈现通知概要。在用户与页脚交互之后，在通知概要中预览各种通知。

尽管图20说明当在应用窗口中呈现内容时接收到通知数据，但所述流类似地适用于当在断开给装置的电力时接收到通知数据时或当用户未登入到装置时呈现通知概要。另外，计算机系统可生成包括不同组通知的通知列表。第一组可对应于已经接收但呈现的第一通知。第二组可对应于已经接收且呈现的通知。在呈现通知概要的触发之后，可从通知列表生成通知概要，其中所述通知概要包括对应于第一通知中的一者或多者的子集。

图21说明根据本公开的实施方案的用于在视频游戏控制台上呈现上下文内通知和弹出通知的流的示例。可将流的操作实施为硬件电路和/或作为计算机可读指令存储在视频游戏控制台的非暂时性计算机可读介质上。在实施时，指令表示包括电路的模块或能够由视频游戏控制台的处理器执行的代码。此类指令的执行会配置视频游戏控制台以执行本文描述的特定操作。每个电路或代码与处理器的组合表示用于执行相应操作的构件。虽然以特定顺序说明操作，但应理解，不要求特定顺序。

在一个示例中，视频游戏控制台接收通知数据。在操作2102处，视频游戏控制台确定是否存在用户对视频游戏控制台的登录。如果是，则操作2104跟在操作2102之后。否则，操作2126跟在操作2102之后。

在一个示例中，在操作2104处，视频游戏控制台确定是否正在提供沉浸式用户体验。在图解中，沉浸式用户体验对应于视频游戏控制台的预定义操作模式中的一者。例如，如果操作模式是游戏模式，则视频游戏控制台确定正在提供沉浸式用户体验。另外，沉浸式用户体验可取决于用户上下文(例如，用户关注水平)和应用上下文(例如，用户交互水平)。当用户关注水平和/或用户交互水平超过预定义水平时，确定提供沉浸式用户体验。如果是，则操作2106跟在操作2104之后。否则，操作2120跟在操作2104之后。

在一个示例中，在操作2106处，视频游戏控制台确定是否正在玩视频游戏。例如，视频游戏应用可在执行并且在应用窗口中呈现视频游戏内容。如果应用窗口在前台中，则确定正在玩视频游戏。如果是，则操作2108跟在操作2106之后。否则，操作2110跟在操作2106之后。

在一个示例中，在操作2108处，视频游戏控制台确定应呈现弹出通知。具体地，视频游戏控制台的用户参与沉浸式用户体验并且正在玩视频游戏。因此，可呈现弹出通知以提示用户。

在一个示例中，在操作2110处，确定用户是否与移动装置或有权访问网络的装置相关联。此确定可由视频游戏控制台基于用户配置文件或基于后端服务器来执行。如果使用后端服务器，则后端服务器还可监视移动装置上的活动和/或在线活动。在此情况下，还确定是否存在此类活动。如果是(用户与移动装置或有权访问网络的装置相关联，并且任选地检测到活动)，则操作2112跟在操作2110之后。否则，操作2114跟在操作2110之后。

在一个示例中，在操作2112处，视频游戏控制台将推送通知发送至移动装置或另一装置。

在一个示例中，在操作2114处，视频游戏控制台确定通知是否为时间敏感的(例如，基于通知的属性；例如，系统通知是时间敏感的)。如果时间敏感，则操作2116跟在操作2114之后。否则，操作2118跟在操作2114之后。

在一个示例中，在操作2116处，视频游戏控制台确定应呈现弹出通知。具体地，由于时间敏感度而需要弹出通知。因此，可呈现弹出通知以提示用户。

在一个示例中，在操作2118处，视频游戏控制台将通知发送至通知和/或队列以添加至通知概要。

在一个示例中，在操作2120处，视频游戏控制台确定用户专注于由视频游戏控制台呈现的内容(或所提供的任何服务)。用户焦点可取决于用户上下文和/或应用上下文。当用户关注水平和/或用户交互水平超过预定义水平时，确定用户焦点在所述内容上。如果是，则操作2122跟在操作2120之后。否则，操作2124跟在操作2120之后。

在一个示例中，在操作2122处，视频游戏控制台确定应呈现上下文内通知。因此，可将上下文内通知呈现为直插、应用内或流内。

在一个示例中，在操作2124处，游戏控制台确定应呈现弹出通知。因此，可呈现弹出通知以提示用户。

在一个示例中，在操作2126处，与操作2110类似地，确定用户是否与移动装置或有权访问网络的装置相关联。如果是(用户与移动装置或有权访问网络的装置相关联，并且任选地检测到活动)，则操作2128跟在操作2126之后。否则，操作2134跟在操作2126之后。

在一个示例中，在操作2128处，视频游戏控制台确定移动装置或另一装置是否连接到局域网。例如，此确定是基于移动装置或其他装置连接到的接入点的服务集标识符(SSID)而作出。如果是，则操作2130跟在操作2128之后。否则，操作2132跟在操作2128之后。

在一个示例中，在操作2130处，视频游戏控制台将通知发送至通知和/或队列以添加至通知概要。视频游戏控制台还将推送通知发送至移动装置或另一装置。可经由局域网执行所述推送。

在一个示例中，在操作2132处，视频游戏控制台将通知发送至通知和/或队列以添加至通知概要。视频游戏控制台还将推送通知发送至移动装置或另一装置。可经由远程网络执行所述推送。

在一个示例中，在操作2134处，视频游戏控制台将通知发送至通知和/或队列以添加至通知概要。

图22说明根据本公开的实施方案的适合于实施计算机系统的硬件系统2200的示例。计算机系统2200表示(例如)视频游戏系统、后端的一组服务器或其他类型的计算机系统。计算机系统2200包括用于运行软件应用和任选地操作系统的中央处理单元(CPU)2205。CPU2205可由一个或多个同构或异构处理核心构成。存储器2210存储供CPU 2205使用的应用和数据。存储装置2215为应用和数据提供非易失性存储装置和其他计算机可读介质并且可包括固定磁盘驱动器、可移除磁盘驱动器、闪存存储器装置和CD-ROM、DVD-ROM、蓝光光碟、HD-DVD或其他光学存储装置，以及信号传输和存储介质。用户输入装置2220将来自一个或多个用户的用户输入传达到计算机系统2200，所述计算机系统的示例可包括键盘、鼠标、操纵杆、触摸板、触摸屏、静态相机或摄像机和/或麦克风。网络接口2225允许计算机系统2200经由电子通信网络与其他计算机系统通信，并且可包括在局域网和诸如互联网的广域网上的有线或无线通信。音频处理器2255适于从由CPU 2205、存储器2210和/或存储装置2215提供的指令和/或数据生成模拟或数字音频输出。计算机系统2200的部件，包括CPU2205、存储器2210、数据存储装置2215、用户输入装置2220、网络接口2225和音频处理器2255，经由一条或多条数据总线2260进行连接。

图形子系统2230进一步与数据总线2260和计算机系统2200的部件连接。图形子系统2230包括图形处理单元(GPU)2235和图形存储器2240。图形存储器2240包括用于存储输出图像的每个像素的像素数据的显示存储器(例如，帧缓冲器)。图形存储器2240可与GPU2235集成在同一装置中，作为单独的装置与GPU 2235连接和/或实施在存储器2210内。可将像素数据直接从CPU 2205提供到图形存储器2240。可替代地，CPU 2205向GPU 2235提供限定期望的输出图像的数据和/或指令，GPU 2235根据所述数据和/或指令生成一个或多个输出图像的像素数据。限定期望的输出图像的数据和/或指令可存储在存储器2210和/或图形存储器2240中。在一个实施方案中，GPU 2235包括3D渲染能力，用于根据指令和数据生成输出图像的像素数据，所述像素数据限定场景的几何形状、照明、着色、纹理化、运动和/或相机参数。GPU 2235还可包括能够执行着色器程序的一个或多个可编程执行单元。

图形子系统2230周期性地输出来自图形存储器2240的图像的像素数据以在显示装置2250上显示。显示装置2250可以是能够响应于来自装置系统2200的信号而显示视觉信息的任何装置，包括CRT、LCD、等离子体和OLED显示器。计算机系统2200可向显示装置2250提供模拟或数字信号。

根据各种实施方案，CPU 2205是一个或多个具有一个或多个处理核心的通用微处理器。可使用具有特别适于诸如媒体和交互式娱乐应用的高度并行和计算密集的应用的微处理器架构的一个或多个CPU 2205来实施其他实施方案。

系统的部件可经由网络进行连接，所述网络可以是以下各项的任何组合：互联网、IP网络、内联网、广域网络(“WAN”)、局域网络(“LAN”)、虚拟专用网络(“VPN”)、公共交换电话网络(“PSTN”)或支持本文在不同的实施方案中描述的装置之间的数据通信的任何其他类型的网络。网络可包括有线连接和无线连接，包括光学链接。鉴于本公开，许多其他示例是可能的并且对于本领域技术人员来说是显而易见的。在本文的讨论中，可能特别指出或可能未特别指出网络。

可鉴于以下条款来描述本公开的实施方案的示例：

条款1.一种用于呈现通知并且由计算机系统实施的方法，所述方法包括：基于应用的执行而在显示器上的应用窗口中呈现内容；接收通知数据；确定与所述通知数据相关联的第一上下文和与所述应用相关联的第二上下文之间的匹配；以及基于所述匹配而在所述应用窗口中呈现通知，所述通知对应于所述通知数据并且在对所述内容的呈现继续时呈现。

条款2.根据条款1所述的方法，所述方法还包括：确定所述应用窗口内的用于呈现所述通知数据的位置；确定用户查看区域包括所述位置；以及在所述位置呈现所述通知数据，其中将所述通知呈现为所述通知数据的至少一部分的视觉指示符。

条款3.根据任一前述条款所述的方法，所述方法还包括：确定所述应用窗口内的用于呈现所述通知数据的位置；以及确定所述位置在用户查看区域之外，所述通知被呈现为用户查看区域内的通知窗口并且指示通知数据可用于呈现。

条款4.根据任一前述条款所述的方法，其中在所述应用窗口中呈现所述内容与由所述应用执行的任务的流相关联，其中所述通知被呈现为对所述流的更新。

条款5.根据任一前述条款所述的方法，所述方法还包括：接收第二通知数据；确定所述第二通知数据与第二应用相关联；确定所述第二应用的第二应用窗口在所述显示器的后台中；以及基于所述第二通知数据与所述第二应用相关联并且所述第二应用窗口在所述后台中而在所述应用窗口上的弹出窗口中呈现第二通知，所述第二通知对应于所述第二通知数据并且在对所述内容的所述呈现继续时呈现。

条款6.根据条款5所述的方法，其中所述第二通知以第一状态呈现，所述第一状态指示所述第二通知的通知类型或标题中的至少一者。

条款7.根据条款6所述的方法，所述方法还包括：接收用户与所述第二通知的交互；以及在对所述内容的所述呈现继续时基于所述用户交互而在所述弹出窗口中以第二状态呈现所述第二通知，其中所述第二状态指示从所述通知数据对所述第二通知的描述和可选择动作。

条款8.根据条款7所述的方法，所述方法还包括：接收对所述描述或所述可选择动作中的至少一者的更新；以及在对所述内容的所述呈现和以所述第二状态对所述第二通知的呈现继续时在所述第二通知中呈现所述更新。

条款9.根据任一前述条款所述的方法，其中通过计算机系统的用户装置呈现所述内容，并且所述方法还包括：确定所述用户装置的操作模式；接收第二通知数据；基于以下各项中的至少一者而确定所述操作模式约束对第二通知数据的呈现：所述第二通知数据与第二应用的关联或所述第二通知数据的类型；以及将所述第二通知数据发送至队列。

条款10.根据任一前述条款所述的方法，其中所述第一上下文包括以下各项中的至少一者：与所述应用的第一用户相关联的第一用户标识符、与生成所述通知数据的源应用的第二用户相关联的第二用户标识符、所述通知数据的主题、所述通知数据的类型、与所述应用相关联的第一应用标识符、与所述第二应用相关联的第二应用标识符、与托管所述应用的第一平台相关联的第一平台标识符，或与托管所述源应用的第二平台相关联的第二平台标识符，并且其中所述第二上下文包括以下各项中的至少一者：所述第一用户标识符、所述第一应用标识符、所述第一平台标识符、操作模式，或所述应用窗口是在所述显示器的前台中的指示。

条款11.一种计算机系统包括：一个或多个处理器；以及一个或多个存储器，所述一个或多个存储器存储计算机可读指令，所述计算机可读指令在由所述一个或多个处理器执行之后配置所述计算机系统进行以下操作：基于应用的执行而在显示器上的应用窗口中呈现内容；接收通知数据；确定与所述通知数据相关联的第一上下文和与所述应用相关联的第二上下文之间的匹配；以及基于所述匹配而在所述应用窗口中呈现通知，所述通知对应于所述通知数据并且在对所述内容的呈现继续时呈现。

条款12.根据条款11所述的计算机系统，其中所述第一上下文指示源应用、通知类型和通知主题，其中确定所述匹配包括确定所述源应用与所述应用之间的第一匹配，以及至少所述通知类型与所述内容的类型或所述通知主题与所述通知的主题之间的第二匹配。

条款13.根据条款11或12所述的计算机系统，其中所述内容向用户呈现，并且其中对所述计算机可读指令的所述执行进一步配置所述计算机系统进行以下操作：响应于接收到所述通知数据，确定以下各项中的至少一者：所述用户对所述内容的关注水平，或用户与所述应用交互的水平；以及基于所述关注水平或所述用户交互水平中的至少一者而从多个呈现模式选择用于所述通知的第一呈现模式，所述第一呈现模式指示在所述应用窗口中呈现所述通知，所述多个呈现模式包括指示在所述应用窗口上的弹出窗口中进行呈现的第二模式。

条款14.根据条款13所述的计算机系统，其中所述通知包括关于所述通知的描述或可选择动作中的至少一者，其中对所述计算机可读指令的所述执行进一步配置所述计算机系统进行以下操作：确定对所述关注水平或所述用户交互水平中的至少一者的更新；基于所述更新而确定关于所述通知的更新后的描述或更新后的可选择动作中的至少一者；以及在所述应用窗口中的所述通知中呈现所述更新后的描述或所述更新后的可选择动作中的至少一者。

条款15.根据条款13所述的计算机系统，其中确定所述匹配包括：确定所述通知数据与所述应用相关联；以及确定所述应用窗口在所述显示器的前台中。

条款16.一种或多种存储计算机可读指令的非暂时性计算机可读存储介质，所述计算机可读指令在计算机系统上执行之后致使计算机系统执行包括以下各项的操作：基于应用的执行而在显示器上的应用窗口中呈现内容；接收通知数据；确定与所述通知数据相关联的第一上下文和与所述应用相关联的第二上下文之间的匹配；确定用于呈现对应于所述通知数据的通知的呈现式样，所述呈现式样是基于所述匹配；以及根据所述呈现式样在所述显示器上呈现所述通知，所述通知在对所述内容的呈现继续时呈现。

条款17.根据条款16所述的一种或多种非暂时性计算机可读存储介质，其中从包括直插呈现、应用内呈现和流内呈现的多种呈现式样确定所述呈现式样。

条款18.根据任一前述条款16到17所述的一种或多种非暂时性计算机可读存储介质，其中所述应用窗口由视频游戏控制台呈现，并且其中所述操作还包括：接收第二通知数据；确定所述视频游戏控制台不在所述显示器的前台中呈现视频游戏内容；确定所述视频游戏控制台的用户的用户上下文，所述用户上下文指示所述用户不在查看所述内容；以及基于所述用户上下文而在所述应用窗口上的弹出窗口中呈现第二通知。

条款19.根据任一前述条款16到18所述的一种或多种非暂时性计算机可读存储介质，其中所述应用是视频游戏应用，其中所述内容是视频游戏内容，并且其中所述操作还包括：接收第二通知数据；确定用户的用户上下文，所述用户上下文指示所述用户正在玩所述视频游戏应用；以及基于所述用户上下文而在所述应用窗口上的弹出窗口中呈现第二通知。

条款20.根据任一前述条款16到19所述的一种或多种非暂时性计算机可读存储介质，其中所述应用是视频游戏应用，其中所述内容是视频游戏内容，并且其中所述操作还包括：接收第二通知数据；确定用户的用户上下文，所述用户上下文指示所述用户不在玩所述视频游戏应用；以及基于所述用户上下文而将所述第二通知数据发送至队列。

在前面的说明书中，参考了本发明的具体实施方案描述本发明，但本领域技术人员将认识到，本发明不受此限制。可单独地或联合地使用上述发明的各种特征和方面。此外，在不脱离说明书的更广的精神和范围的情况下，可在除了本文描述的环境和应用之外的任何数目个环境和应用中利用本发明。说明书和图因此将被视为说明性的，而非约束性的。

应注意，预期上文论述的方法、系统和装置仅仅是示例。必须要强调的是，在适当时各种实施方案可省略、替代或添加各种过程或部件。例如，应了解，在替代性实施方案中，可通过不同于所描述的顺序的顺序来执行方法，并且可添加、省略或组合各种步骤。而且，关于某些实施方案所描述的特征可在各种其他实施方案中组合。实施方案的不同方面和元件可通过类似方式组合。而且，应着重的是，技术演变，并且因此许多元件是示例并且不应解释为限制本发明的范围。

在描述中给出具体细节来提供对实施方案的透彻理解。然而，本领域技术人员将理解，可在没有这些具体细节的情况下实践所述实施方案。举例来说，已经在没有不必要的细节的情况下示出了众所周知的电路、过程、算法、结构和技术，以便避免使所述实施方案模糊不清。

而且，应注意，可将所述实施方案描述为过程，所述过程被描绘为流程图或框图。虽然可将操作描述为连续过程，但许多操作可并行地或同时地执行。另外，操作的顺序可重新布置。过程可具有在图中未包括的附加的步骤。

另外，如本文公开，术语“存储器”或“存储器单元”可表示用于存储数据的一个或多个装置，包括只读存储器(ROM)、随机存取存储器(RAM)、磁性RAM、核心存储器、磁盘存储介质、光学存储介质、闪存存储器装置或用于存储信息的其他机器可读介质。术语“计算机可读介质”包括(但不限于)便携式或固定存储装置、光学存储装置、无线信道、sim卡、其他智能卡和能够存储、含有或携载指令或数据的各种其他介质。

此外，实施方案可由硬件、软件、固件、中间件、微码、硬件描述语言或其任何组合来实施。当实施于软件、固件、中间件或微代码中时，用以执行必要任务的程序代码或代码段可存储在诸如存储介质的计算机可读介质中。处理器可执行所述必要任务。

除非另有规定，否则在本说明书中包括在所附权利要求书中陈述的所有测量结果、值、额定值、位置、量值、大小和其他规格是近似的，不是精确的。它们旨在具有与它们涉及的功能和在本领域中它们相关的习惯的东西一致的合理范围。“约”包括在±0.01％、±0.1％、±1％、±2％、±3％、±4％、±5％、±8％、±10％、±15％、±20％、±25％的公差内，或者如在本领域中另外已知的。“基本上”是指多于66％、155％、80％、90％、95％、99％、99.9％或是在本领域中另外已知的值，这取决于术语基本上在其内出现的上下文。

在描述了若干实施方案的情况下，本领域技术人员将认识到，可在不脱离本发明的精神的情况下使用各种修改、替代性构造和等同物。举例来说，以上元件可仅为较大系统的部件，其中其他规则可优先于或以其他方式修改本发明的应用。而且，可在考虑以上元件之前、期间或之后来着手一定数目的步骤。因此，以上描述不应视为限制本发明的范围。

Claims (15)

1.一种用于呈现通知并且由计算机系统实施的方法，所述方法包括：

基于应用的执行而在显示器上的应用窗口中呈现内容；

接收通知数据；

确定与所述通知数据相关联的第一上下文和与所述应用相关联的第二上下文之间的匹配；以及

基于所述匹配而在所述应用窗口中呈现通知，所述通知对应于所述通知数据并且在对所述内容的呈现继续时呈现。

2.如权利要求1所述的方法，所述方法还包括：

确定所述应用窗口内的用于呈现所述通知数据的位置；

确定用户查看区域包括所述位置；以及

在所述位置呈现所述通知数据，其中将所述通知呈现为所述通知数据的至少一部分的视觉指示符。

3.如权利要求1所述的方法，所述方法还包括：

确定所述应用窗口内的用于呈现所述通知数据的位置；以及

确定所述位置在用户查看区域之外，所述通知被呈现为用户查看区域内的通知窗口并且指示通知数据可用于呈现。

4.如权利要求1所述的方法，其中在所述应用窗口中呈现所述内容与由所述应用执行的任务的流相关联，其中所述通知被呈现为对所述流的更新。

5.如权利要求1所述的方法，所述方法还包括：

接收第二通知数据；

确定所述第二通知数据与第二应用相关联；

确定所述第二应用的第二应用窗口在所述显示器的后台中；以及

基于所述第二通知数据与所述第二应用相关联并且所述第二应用窗口在所述后台中而在所述应用窗口上的弹出窗口中呈现第二通知，所述第二通知对应于所述第二通知数据并且在对所述内容的所述呈现继续时呈现。

6.如权利要求5所述的方法，其中所述第二通知以第一状态呈现，所述第一状态指示所述第二通知的通知类型或标题中的至少一者，并且所述方法还包括：

接收用户与所述第二通知的交互；

在对所述内容的所述呈现继续时基于所述用户交互而在所述弹出窗口中以第二状态呈现所述第二通知，其中所述第二状态指示从所述通知数据对所述第二通知的描述和可选择动作；

接收对所述描述或所述可选择动作中的至少一者的更新；以及

在对所述内容的所述呈现和以所述第二状态对所述第二通知的呈现继续时在所述第二通知中呈现所述更新。

7.如权利要求1所述的方法，其中通过所述计算机系统的用户装置呈现所述内容，并且所述方法还包括：

确定所述用户装置的操作模式；

接收第二通知数据；

基于以下各项中的至少一者而确定所述操作模式约束对所述第二通知数据的呈现：所述第二通知数据与第二应用的关联或所述第二通知数据的类型；以及

将所述第二通知数据发送至队列。

8.如权利要求1所述的方法，其中所述第一上下文包括以下各项中的至少一者：与所述应用的第一用户相关联的第一用户标识符、与生成所述通知数据的源应用的第二用户相关联的第二用户标识符、所述通知数据的主题、所述通知数据的类型、与所述应用相关联的第一应用识别符、与所述第二应用相关联的第二应用识别符、与托管所述应用的第一平台相关联的第一平台标识符，或与托管所述源应用的第二平台相关联的第二平台标识符，并且其中所述第二上下文包括以下各项中的至少一者：所述第一用户标识符、所述第一应用识别符、所述第一平台标识符、操作模式，或所述应用窗口是在所述显示器的前台中的指示。

9.一种计算机系统，所述计算机系统包括：

一个或多个处理器；以及

一个或多个存储器，所述一个或多个存储器存储计算机可读指令，所述计算机可读指令在由所述一个或多个处理器执行之后配置所述计算机系统进行以下操作：

基于应用的执行而在显示器上的应用窗口中呈现内容；

接收通知数据；

确定与所述通知数据相关联的第一上下文和与所述应用相关联的第二上下文之间的匹配；以及

基于所述匹配而在所述应用窗口中呈现通知，所述通知对应于所述通知数据并且在对所述内容的呈现继续时呈现。

10.如权利要求9所述的计算机系统，其中所述第一上下文指示源应用、通知类型和通知主题，其中确定所述匹配包括确定所述源应用与所述应用之间的第一匹配，以及至少所述通知类型与所述内容的类型或所述通知主题与所述通知的主题之间的第二匹配。

11.如权利要求9所述的计算机系统，其中所述内容向用户呈现，并且其中对所述计算机可读指令的所述执行进一步配置所述计算机系统进行以下操作：

响应于接收到所述通知数据，确定以下各项中的至少一者：

所述用户对所述内容的关注水平，或

用户与所述应用交互的水平；以及

基于所述关注水平或所述用户交互水平中的至少一者而从多个呈现模式选择用于所述通知的第一呈现模式，所述第一呈现模式指示在所述应用窗口中呈现所述通知，所述多个呈现模式包括指示在所述应用窗口上的弹出窗口中进行呈现的第二模式。

12.一种或多种存储计算机可读指令的非暂时性计算机可读存储介质，所述计算机可读指令在计算机系统上执行之后致使所述计算机系统执行包括以下各项的操作：

基于应用的执行而在显示器上的应用窗口中呈现内容；

接收通知数据；

确定与所述通知数据相关联的第一上下文和与所述应用相关联的第二上下文之间的匹配；

确定用于呈现对应于所述通知数据的通知的呈现式样，所述呈现式样是基于所述匹配；以及

根据所述呈现式样在所述显示器上呈现所述通知，所述通知在对所述内容的呈现继续时呈现。

13.如权利要求12所述的一种或多种非暂时性计算机可读存储介质，其中从包括直插呈现、应用内呈现和流内呈现的多种呈现式样确定所述呈现式样。

14.如权利要求12所述的一种或多种非暂时性计算机可读存储介质，其中所述应用窗口由视频游戏控制台呈现，并且其中所述操作还包括：

接收第二通知数据；

确定所述视频游戏控制台不在所述显示器的前台中呈现视频游戏内容；

确定所述视频游戏控制台的用户的用户上下文，所述用户上下文指示所述用户不在观看所述内容；以及

基于所述用户上下文而在所述应用窗口上的弹出窗口中呈现第二通知。

15.如权利要求12所述的一种或多种非暂时性计算机可读存储介质，其中所述应用是视频游戏应用，其中所述内容是视频游戏内容，并且其中所述操作还包括：

接收第二通知数据；

确定用户的用户上下文，所述用户上下文指示所述用户正在玩所述视频游戏应用；以及

基于所述用户上下文而在所述应用窗口上的弹出窗口中呈现第二通知。

Images