CN118044178A - 视频会议中的上下文消息传送 - Google Patents

Abstract

本文一般讨论的是用于会议中的上下文消息传送的设备、系统和方法。一种方法可以包括由第一用户界面接收数据，该数据指示消息的内容、消息的接收方以及条件，该条件在会议期间被满足时，使消息在视听会议期间可视地被显示，在会议通过视听会议应用正在被举行时，针对条件是否被满足，监视用户上下文数据，响应于条件被满足，增强来自视听会议应用的视听会议数据，以包括产生被增强的视听数据的消息，以及在视听会议应用的第二用户界面上，向接收方提供被增强的视听数据的视图。

Description

视频会议中的上下文消息传送

背景技术

人们通过诸如美国华盛顿州雷德蒙德微软公司的和来自在美国加利福尼亚州圣何塞的Zoom视频通信有限责任公司(Zoom Video Communications,Incorporated)的/>等技术，花费大量时间参加视频和/或音频会议(本文中简称为“会议”)。会议技术的用户可以收听并可以选择性地查看一个或多个主要发言者。会议的参与方可以接入并收听无视频会议，也可以接入视频会议同时查看和收听会议。会议的用户可以有时间与会议中的其他参与方进行交流。然而，会议技术通常缺乏为参与方提供个性化的上下文。例如，考虑一次有关员工健康福利的会议，公司人员在会上描述了健康、牙科、视力或其他福利的最新情况。一些员工可能了解与健康储蓄账户(HSA)、健康维护组织(HMO)计划、首选提供者组织(PPO)计划等相关的高免赔额健康计划(HDHP)之间的区别，但有些员工可能不了解。由于时间限制和效率问题，解释这些健康计划之间的差异可能并不明智。不熟悉这些健康计划差异的参与方可能会对其医疗保健做出不知情的决定。在会议中每天都会遇到许多其他缺乏个性化上下文的类似情况。

发明内容

提供了一种用于视听会议中的上下文消息传送的方法、设备或机器可读介质。该方法、设备或机器可读介质能够以显示的消息的形式向会议提供视听会议中不存在的附加上下文。附加上下文可以提供提醒、视听会议中提供的信息之外的信息、要完成的任务等。附加上下文可以是有条件的，使得仅当某些条件被满足时才呈现消息。附加上下文可以是参与方特定的，使得具有第一特性的参与方和具有不同的第二特性的参与方被提供不同的附加上下文。提供了许多其他细节和改进。

一种用于视听会议中的上下文消息传送的方法可以包括由第一用户界面接收数据，数据指示消息的内容、消息的接收方以及条件，条件在会议期间被满足时，使消息在视听会议期间被可视地显示。该方法还可以包括在会议通过视听会议应用正在被举行时，针对条件是否被满足，监视用户上下文数据。该方法还可以包括，响应于条件被满足，增强来自视听会议应用的视听会议数据，以包括产生被增强的视听数据的消息。该方法还可以包括，在视听会议应用的第二用户界面上，向接收方提供被增强的视听数据的视图。

该数据还可以指示在第二用户界面上用以呈现消息的位置，并且消息的内容被呈现在第二用户界面上的该位置处。该方法还可以包括，其中视听会议应用在客户端或服务器上被执行。该方法还可以包括，其中数据还指示消息的内容的形式，该形式包括内容的呈现的类型，该类型包括滚动条带、思想气泡、通知、超链接或文本框。该形式还可以包括消息的内容的视觉透明度。

数据的接收方还可以包括特性条件，该特性条件指示仅满足特性条件的用户接收消息的内容。该数据还可以包括限定进一步的特性条件的准则，该进一步的特性条件限定消息的内容的哪些部分被提供给接收方。该条件还可以包括该会议的视听数据中发生的事件，该事件包括手势被执行、短语被说出、时间流逝、用户上下文信息的检查或对象出现。用户上下文信息可以包括职称、教育状况、专业知识、任务状况、培训状况、设备类型或当前位置。

该方法还可以包括由第一用户界面接收数据，该数据指示第二消息的内容、第二消息的第二、不同接收方、以及第二条件，该第二条件在被满足时，使该第二消息在会议期间被显示。该方法还可以包括，在会议通过会议应用正在被举行时，由会议应用针对第二条件是否被满足，监视会议的视听数据。该方法还可以包括响应于该第二条件被满足，增强视听数据，以包括产生第二被增强的视听数据的第二消息。该方法还可以包括在会议应用的第三用户界面上，向第二接收方提供被增强的视听数据的视图。该方法还可以包括，其中接收方仅是主持者参与方。

一种用于视听会议兼容应用的用户界面可以被配置为执行包括接收数据的操作，该数据指示消息的内容、消息的接收方以及条件，该条件在会议期间被满足时，使消息在视听会议期间被可视地显示。操作还可以包括存储接收到的数据，使得在会议通过视听会议应用正在被举行时，视听会议应用监视条件是否被满足，并且响应于条件被满足，增强视听数据以包括产生被增强的视听数据的消息。

操作还可以包括接收数据，该数据指示第二消息的内容、第二消息的第二、不同接收方、以及第二条件，该第二条件在被满足时，使第二消息在会议期间被显示。操作还可以包括存储接收到的数据，使得在会议通过视听会议应用正在被举行时，视听会议应用监视该第二条件是否被满足，，并且响应于该第二条件被满足，增强改视听数据，以包括产生第二被增强的视听数据的该第二消息。

附图说明

图1通过示例示出了具有上下文消息的用户界面的实施例的框图。

图2通过示例示出了用于电话会议中的上下文消息传送的系统的实施例的框图。

图3通过示例示出了包括用于参与方的个性化上下文消息的UI的框图。

图4通过示例示出了用户界面的框图，用户可以通过该用户界面定义用于提供给会议的参与方的上下文消息。

图5通过示例示出了用于会议期间上下文消息传送的方法的实施例的框图。

图6通过示例示出了用于实现一个或多个实施例的机器(例如，计算机系统)的实施例的框图。

具体实施方式

在下面的描述中，参考了形成其一部分的附图，并且其中通过说明的方式示出了可以实践的具体实施例。这些实施例被足够详细地描述以使本领域技术人员能够实践实施例。应当理解，可以利用其他实施例，并且可以进行结构、逻辑和/或电气改变，而不脱离该实施例的范围。因此，以下对实施例的描述不应被视为限制意义，实施例的范围由所附的权利要求限定。

人们花费大量时间通过技术进行电话会议。目前可以通过这些通话的音频、视频和聊天频道传达的信息有限。不说话的参与方有额外的能力来使用上下文相关的信息。实施例可以利用主显示器周围的背景或会议技术的界面的附加部分(例如，以滚动条带格式)来呈现此信息。

上下文相关的信息可以采取强化信息或补充信息的形式，这些信息通常涉及(i)会议(有时称为“开会”)，(ii)当前对话，以帮助表达观点(例如，“了解更多信息请参阅此处”消息发送给所有或部分参与方)，(iii)当前时间点(例如，仅当议程中有许多项目时，才会向发言者发送“是时候进行下一步了”消息。)，或者(iv)发言者可以留下消息来提醒自己在开会期间应该做的事情(例如，“询问团队中每个人的意见”)。这些上下文消息可以支持发言者(例如，帮助他们表达观点或提供补充信息，例如提醒、超链接或项目列表)和通话中的其他人(例如，获取附加信息和提醒)。

通过横幅消息对这一概念进行了一些有限的使用(例如，“开会还剩5分钟”、“您正在录制。确保让每个人都知道他们正在被录音。”，“录制已开始。加入开会即表示您同意被录制。”)。但是，/>目前不会考虑超出用户在开会中的角色的用户数据来提供消息。

上下文消息传送至少有三种模式，例如(1)由发言者共享的消息，供通话中的其他人使用，(2)直接共享给当前发言者的消息，仅供当前发言者使用，以及(3)由会议技术自动生成的消息(例如，基于用户提供的规则)。

模式#1中的消息可以出现在可用的视觉用户体验的任何部分(例如，主会议窗口、来自发言者窗口的任何部分，包括发言者背景)。以模式#2直接共享给发言者的消息可以从其他发言者的窗口或背景或在主Teams窗口中共享；但不是在发言者本身的背景中，因为这依赖于他们看着自己，这通常不是发言者正在做的事情，因此发言者很可能没有收到消息。模式#3中的消息由系统基于开会之前和/或开会期间创建的内容生成。

任何模式的消息都可以由以下一项或多项指导：(a)组织政策和支持数据。例如，所有未完成所有培训的人员都可以在人力资源电话会议中看到以下消息：“提醒：在<日期>之前完成你所需的培训。”(b)用户指定。例如，消息的内容可以由发言者或会议管理者在会议之前提供，甚至可以利用用于触发消息的特定关键短语和/或定时进行标记。(c)系统推理。例如，消息的内容可以从开会议程、开会记录或开会之前的通信例如，在电子邮件中提出的请求或约定的提醒自动得出。

消息的格式(消息如何呈现)可能会根据消息的本质、电话会议的本质(例如，正式开会与非正式聊天)和环境而有所不同。该格式可以是用户定义的，也可以基于有关在当前上下文中传达消息的最佳方式的推理而变化。这些消息也可以是可操作的(例如，通过可点击的超链接)。

现在将参考附图描述实施例的进一步细节。附图说明实施例的示例，并且一个实施例的一个或多个组件可以与不同实施例的组件一起使用或代替另一实施例的组件使用。

图1通过示例示出了具有上下文消息106的用户界面100的实施例的框图。用户界面(UI)100仅仅是视频会议界面的示例，并且UI的许多其他变体被认为与实施例相关。UI100包括主要显示区域102和辅助显示区域104。主要显示区域102提供当前发言者、共享文档、开会组织者等的视图。主要显示区域102通常是参与方在参加开会时所看到的区域。开会的主要内容通过主显示区域或控制主要显示区域102中呈现的内容的发言者来提供。

UI 100还包括辅助显示区域104。辅助显示区域104可以包括代表开会的各个与会者的图标或化身、与会者的相机画面或其组合。作为简单的说明性示例，如图所示的辅助显示区域104包括各个与会者的图标108A、108B。

UI 100还提供上下文消息106的视图。上下文消息106对于开会的不同参与方可以是不同的。上下文消息106可以与其他一起作为滚动条带类消息被提供，其在主要显示区域102的未被用来提供内容的部分中具有滚动文本、文本框或其他图形。替选地，可以在辅助显示区域104的图标108A、108B上提供上下文消息106。

虽然辅助显示区域104被示出在主要显示区域102上，但是辅助显示区域104可以位于各种其他位置，例如主要显示区域102之外。此外，有些会议不包括视频，或者用户可以选择通过拨入并收听会议的音频来参加视频会议。通过用音频消息替代图形消息，本文描述的创新也适用于这些情况。

图2通过示例示出了用于电话会议中的上下文消息传送的系统200的实施例的框图。图示的系统200包括上下文建模器250、消息生成器234、以及一个或多个数据源，该数据源包括开会环境数据220、消息和触发器228、外部数据238、知识图256和参与方简档240。上下文建模器250可以耦合到消息生成器234和主持者参与方设备224。消息生成器234可以耦合到主持者参与方设备224和与会者参与设备246和252。消息生成器234可以向开会参与方提供个性化视图(PV)248A、248B、248C、248D。

开会环境数据220可以由上下文建模器250访问。开会环境数据220可以包括日期、时间、开会议程、被邀请者列表、所需与会者列表、可选与会者列表、参与方设备信息(例如，品牌、型号、能力等)、演示(例如，文件或其他要呈现的计算资源)等。上下文建模器250可以从一个或多个设备224、246、252接收音频/视频(A/V)流。来自设备246、252中的每一个的A/V流未被示出，以免模糊图2中提供的视图。然而，可以提供这样的A/V流。这样的A/V是可选的，因为在每个设备224、246、252上运行的会议应用可以包括针对每个参与方的视频数据，因为该数据通常在中央服务器处(例如，在云中)聚合并提供到设备224、246、252中的每一个。上下文建模器250可以确定参与方的情绪、来自参与方的提示等。提示可以包括音频中的口头单词短语、视频中的姿势、视频中的对象等。例如，参与方可以使将要被提供的个性化消息响应于短语“你们每个人都将收到指示你们是否完成了X”、“abracadabra”等。在另一个示例中，参与方可以使将要被提供的个性化消息响应于指定手势(例如，“好的”、沿指定方向滑动、指向指定对象、用鼠标单击软件控件、触摸他们的头、抓脸、眨眼或其他手、脸或身体姿势)。在另一示例中，参与方可以使将要被提供的个性化消息响应于出现在流222中的指定对象。该对象可以在演示文件中的图像中、主持者放置在他们的相机的视野范围中的对象等。

上下文建模器250可以使用用于这样做的多种方式，例如多个不同的机器学习模型来执行对象识别、语音识别、手势识别或其组合。实施例不限于针对对象、语音或手势识别的特定技术。提供这些技术的一些示例只是为了了解对象、语音和手势识别的含义。示例对象检测技术包括那些使用计算机辅助绘图(CAD)的技术，例如对象模型、基于边缘比较的模型、灰度匹配、梯度匹配、感受野响应的直方图、解释树、姿势一致性、姿势聚类、不变性、几何哈希、尺度不变特征变换(SIFT)、加速鲁棒特征(SURF)、词袋、神经网络(NN)等等。示例手势识别技术包括基于三维(3D)模型的技术、基于骨骼的技术、基于外观的技术、基于肌电图的技术等。示例语音识别技术包括隐马尔可夫模型、基于动态时间规整的语音识别、神经网络和端到端自动语音识别。

上下文建模器250可以为消息生成器234生成并提供上下文数据254。上下文数据254可以包括来自开会环境数据220的数据、语音或对象识别的结果、或其组合。上下文数据254可以在其生成时、以指定的时间间隔、周期性地等被提供。

主持者参与方或主持者参与方的代理可以使用他们的设备224来定义消息准则226。在开会设置期间，设备224可以呈现向导。该向导可以向主持者参与方提供消息供应的选项。向导，有时称为设置助手是一种提供用户界面的软件，该用户界面向用户呈现一系列对话框，引导用户完成一系列明确定义的步骤。由于消息生成器234可用的数据可能是有限的，并且个性化视图248A-248D中提供的个性化消息的形式也可能是有限的，所以设置助手可以引导用户通过可能的消息类型并阻止用户尝试使用不受支持的消息条件或消息类型。

使用向导、设置助手或作为会议应用的一部分提供的UI，主持者参与方可以定义消息准则226。消息准则226可以包括消息的内容的指示、当被满足时使消息被呈现给与会者、相应消息的接收方的一个或多个条件、以及消息的形式。条件可以包括一天中的时间、时间流逝、对象、手势、短语、其组合等。内容可以包括图像、文本、音频、视频、可点击的超链接或其他软件控件，例如按钮，或将要提供给被指示为接收方的人的其他数据。内容可以与准则(有时称为特性条件，因为准则是用户具有指定的角色特质或资格的条件)相关联，使得如果用户满足准则，则他们接收该内容。一些内容可以是默认内容(接收该内容不需要任何准则)并且其他内容可以与准则被满足时指示内容将被提供给参与方的准则相关联。内容准则可以是从参与方的用户简档中得出或在用户简档中明确提供的简档参数。简档参数可以指示职称、教育状况、专业知识、任务状况、设备类型、当前位置、关于与会者的以及在参与方简档中可用的其他信息等。

消息的形式可以包括如何呈现消息的指示。该形式可以包括一种类型的消息，例如文本框、思想气泡、视频(例如，作为缩略图或在主要显示区域102或辅助显示区域104上等)、图形、滚动条。文本框等。消息的形式可以包括透明度、字体、文本或视频的尺寸、颜色、消息在显示器上的位置(例如，显示器、显示器上的位置，例如背景、角落、在演示之上、或其组合)、背景图案或用于消息的图片、与消息一起提供的可定制指示符，指示参与方他们有一条消息(例如，视觉、音频或触觉指示符)、其组合等。接收方可以是任何参与方、与会者或主持者参与方。可以通过姓名、电子邮件地址、简档参数等来定义接收方。

消息生成器234可以接收来自上下文建模器250的上下文254、来自消息和触发器228的消息触发数据230、来自参与方简档240的简档数据242、来自外部数据238的其他数据236或其组合。外部数据236是与参与方相关但从设置开会的人员工作的组织外部访问的任何数据。外部数据236可包括公共数据，例如可从社交媒体平台、国家、州或城市记录、人口普查局或其他政府组织、电子邮件(email)服务器、其组合等获得。简档数据242是与参与方相关并且从组织内部访问的数据。简档数据242可以包括工作职位、任务完成情况(例如，作为较大项目或组的一部分)、知识图、其组合等。

消息生成器234可以使用上下文254、外部数据236、简档数据242或其组合来确定消息触发数据230中的条件是否被满足。响应于条件被满足，消息生成器234可以增强A/V流222以包括由消息准则226指示的消息。在确定是否存在与被满足的条件相关联的任何消息时，消息生成器234可以向消息和触发器228发出查询，该查询返回上下文254、外部数据236、简档数据242或其任何组合中的任何一个是否满足消息的条件。消息和触发器228可以返回与已经被满足的条件相关联的任何消息以及指示消息的接收方和消息的格式的数据。消息生成器234然后可以将消息添加到针对每个接收方的A/V流，并将PV 248A-248D提供给对应的接收方。

上下文建模器250和消息生成器234可以包括被布置或编程为执行其操作的电气或电子组件。电气或电子组件可以包括一个或多个晶体管、电阻器、电容器、二极管、放大器、开关、电感器、多路复用器、逻辑门(例如，AND、OR、XOR、求反、缓冲器等)、电源、存储器设备、处理单元(例如，中央处理单元(CPU)、图形处理单元(GPU)、现场可编程门阵列(FPGA)、专用集成电路(ASIC)等)、模数转换器(ADC)、数模转换器(DAC)、调节器、振荡器等。

在一些实施例中，系统200可以自动生成消息和触发器并提供相应的PV 248A-248D(部署后无需人为介入)。自动消息可以是手动定义的消息的补充或替代。消息的自动生成可以包括上下文建模器250、消息生成器234、其组合等，其分析先前消息和触发器228、外部数据238、参与方简档240、开会议程、知识图、其组合，或类似的。

知识图256不是传统意义上的数据库。知识图256不是基于关系或对象数据库模型，而是映射用户及其各种活动之间的关系的图数据库。图数据库基于实体(或“节点”)以及它们之间的映射关系(或“链接”)。知识图谱非常适合Web内容，因为在某种程度上，Web本身就是一个图形数据库——其页面作为节点，并且由连接它们的超链接表示关系。微软公司的知识图和Satori中的实体都是语义数据对象，每个对象都有一个唯一的标识符、基于它们所代表的现实世界主题的属性的特性的集合，以及代表从主题到其他实体的关系的链接。这些实体还包括搜索该主题的人可能想要采取的行动。知识图数据258可以由知识图256提供。

图3通过示例示出了包括针对参与方的个性化上下文消息340、342、344、346的UI300的框图。在图3的例子中，每个主要显示区域包括由主持者参与方演示的演示338。主持者参与方具有第一UI 330。UI 330包括作为对主持者的提醒的消息340。提醒可以是放慢速度、提出问题、看着相机、提及有趣的事实、切换到演示不同的文件，或者主持者希望在演示中的特定点向自己提供的任何其他注释。图3的示例中的UI 332、334、336是针对与会者的，并且每个都包括针对参与方个性化的消息342、344、346。个性化消息342、344、346可以指示与会者当前的健康计划的类型、与会者已经或尚未完成的任务(例如，培训、项目或其他任务)、来自主持者的个性化事实或注释等。个性化消息342、344、346中的两个或更多个可以包括相同或不同的内容。个性化消息342、344、346中的每一个可以分别填充有基于登录到会议并与UI 332、334、336相关联的与会者的特性以及与消息342、344、346相关联的条件是否被满足的内容。

图4通过示例示出了用户界面400的框图，用户可以通过该用户界面400来定义用于提供给会议的参与方的上下文消息。如图所示的UI 400包括输入框440、442，用户可以在其中定义消息的内容。消息的内容可以根据用户指示进行定制。在图4的例子中，括号中的内容是可变的，使得如果满足其他输入框中定义的条件和准则，则基于参与方特性来填充括号中的内容。

参与方特性可以指示用户数据，该用户数据超出他们在会议中的角色。会议中的角色可以指示用户是否是主持人、参与方、组织者、主持者、代理等。会议中的角色可用于确定用户是否可以为会议定义消息。例如，主持人、组织者或主持者可以定义会议的消息。主持人、组织者或主持者可以指示可以定义用于会议的消息的其他用户，这些用户称为“代理”。

输入框444、446提供用户可以在其中定义用于触发消息传递的条件的区域。输入框444、446中定义的条件的满足并不保证具有输入框440、442中的内容的消息被传递，因为用户可以定义为消息传递提供进一步条件的接收方和准则。定义的条件可以存储在消息和触发器228中。上下文建模器250可以使用对象识别、语音识别、启发式等来确定定义的条件是否已经被满足。对于条件“引导到演示文稿的幻灯片2”，上下文建模器250可以识别演示文稿视图包括“幻灯片2”、页码“2”、用户选择的“下一张幻灯片”软件控件等，以确定条件已经被满足。对于条件“手势OK标志”，上下文建模器250可以使用对象识别来识别执行“OK”手势的手。该手势可以仅限于主持者(正在讲话的人或与开会的主持者角色相关联的人)。这些仅仅是提供对实施例的理解的条件的示例。其他条件和手势均在实施例的范围内。例如，用户可以定义手势的列表以及与控制消息部署的手势相对应的标准。

输入框448、450向用户提供在显示器上定义位置(例如，定义的一组位置、可配置位置、自然语言描述等)的能力，如果条件、接收方、准则被满足，则消息将出现在该位置。输入框452、454向用户提供定义消息的内容的形式的能力。输入框456、458向用户提供定义消息的接收方的能力(假设满足条件和标准)。接收方可以提供接收消息的另一个条件。例如，文本框456将接收方限制为出席并使用显示设备访问开会的参与方。在另一示例中，输入框458将接收方限制为出席的参与方和工程团队的成员。该信息可以由消息生成器234从外部数据238或参与方简档240读取。

输入框460允许用户定义针对接收消息的准则。在图4的例子中，响应于检测到手势“OK”标志(i)名为Fritz的出席的参与方(他是工程团队的成员并且已完成X任务)将接收到消息“Fritz，您已完成X任务。谢谢！”，(ii)一位名为Gert的出席的参与方(他是工程团队的成员并且尚未完成X任务的)将收到消息“Gert，您尚未完成X任务。请在您方便的时候尽早完成X任务。在www.task.com上访问任务材料”，以及(iii)不属于工程团队的出席的参与方将不会收到消息。该准则可以由消息生成器234监视。消息生成器234可以访问数据库，例如外部数据238、参与方简档240或知识图256，以确定参与方是否满足准则。该准则能够以与相关数据库中数据的存储的定义一致的格式存储在消息和触发器228。一般而言，可以从上下文建模器250的上下文254获取条件的满足(或不满足)，并且可以从数据库238、240、256的数据获取准则的满足(或不满足)。

对于具有有限选项的文本框，例如输入框444、446、448、450、452、454、456、458、460，下拉菜单、单选按钮菜单或可用选项的其他指示可以提供给用户。

如果用户没有指定参数，例如位置、尺寸、颜色、其他形式参数、准则、接收方、条件等，则可以针对该参数使用默认值。例如，可以选择默认字体、颜色、尺寸、透明度和类型，默认接收方可以是所有参与方，默认准则可以为空，默认条件可以是开会的开始时间，默认位置可以是主要显示区域的背景。其他默认也是可能的，并且其他默认值在实施例的范围内。

考虑背景技术中的示例，其中正在举办有关医疗保健的会议。一些员工参与方可能了解与健康储蓄账户(HSA)、健康维护组织(HMO)计划、首选提供者组织(PPO)计划等相关的高免赔额健康计划(HDHP)之间的区别，但有些员工可能不了解。由于时间限制和效率问题，在演示中解释这些健康计划之间的差异可能并不明智。上下文建模器250、消息生成器234或其组合可以自动地或者在用户帮助下向参与方提供关于他们当前签署的计划的类型的消息、计划之间差异的解释、以及对每个计划对参与方有利的情况的解释等。可以响应于被满足的条件来提供消息，例如主持者提到所提供的不同的医疗保健计划、参与方脸上有困惑的表情、参与方表现出特定的情绪等。

图5通过示例示出了用于视听会议期间进行上下文消息传送的方法500的实施例的框图。如图所示，在操作550，方法500通过第一用户界面接收数据，该数据指示消息的内容、消息的接收方以及条件，该条件当在会议期间被满足时使消息在视听会议期间可视地显示；在操作552，当会议通过视听会议应用正在被举行时，监视用户上下文数据以确定满足是否被满足；在操作554，响应于条件被满足，，增强来自视听会议应用的视听会议数据以包括产生被增强的视听数据的消息；在操作556，在视听会议应用的第二用户界面上，向接收方提供被增强的视听数据的视图。视听会议数据可以包括来自会议的非静音参与方的音频、来自主要显示区域、辅助显示区域、聊天窗口或视听会议应用的其他视觉显示部分的视觉数据。视听会议应用可以由客户端、远程服务器、其组合等提供。用户上下文数据可以包括上下文254、简档参数、来自消息和触发器230中的一个或多个的数据、外部数据236、参与方简档242、知识图258、开会环境数据220、其组合等。

对于严格的音频会议或以纯音频格式体验会议的用户(例如，通过拨入而不体验视频)，可以“暂停”会议，同时向仅以音频方式体验会议的用户提供消息。视频中的暂停可以允许以音频形式呈现消息，而无需继续进行会话的视觉部分。在暂停期间，可以向用视觉参加会议的人员显示消息。该消息可以指示暂停是为了提供音频消息。在录制会议的实施例中，可以增强视听会议以包括与要呈现的消息的内容相对应的附加音频。注意，消息生成器234、上下文建模器250或系统200的其他部分可以执行相同的操作，无论用户正在实时体验视听会议还是稍后体验视听会议。

方法500还可以包括，其中数据还指示在第二用户界面上用以呈现消息的位置，并且消息的内容被呈现在第二用户界面上的该位置处。方法500还可以包括，其中数据还指示消息的内容的形式，该形式包括内容呈现的类型，该类型包括滚动条带、思想气泡、通知、超链接或文本框。消息可以在不同格式、位置或其组合之间移动，具体取决于消息是否已被注意到/被采取行动。例如，如果一条消息是可操作的(包括调查、可点击的超链接或用户的其他动作期望)并且用户应该采取行动但没有采取行动，则可以将该消息移动到更引人注目的位置，该消息的格式消息可以被改变等并且被重新呈现给尚未对该消息采取行动的用户。

方法500还可以包括，其中形式还包括消息的内容的视觉透明度。在一些实施例中，透明度级别可以表示对消息与视听会议的当前上下文的相关性的置信度、消息的重要性等。附加或替代地，可以改变消息的形式的不同组件以指示消息的重要性。例如，视听会议流的背景颜色对于不同的消息可以是不同的，消息的格式可以改变以使其看起来与背景(例如，模拟白板书写)更加融合，等等。

方法500还可以包括，其中数据的接收方包括特性条件，该特性条件指示仅满足特性条件的用户才能接收消息的内容。

方法500还可以包括，其中数据还包括定义进一步特性条件的准则，该特性条件定义消息的内容的哪些部分被提供给接收方。方法500还可以包括，其中条件包括会议的视听数据中发生的事件，该事件包括手势被执行、短语被说出、时间流逝、用户上下文数据的检查或对象出现。

方法500还可以包括由第一用户界面接收数据，该数据指示第二消息的内容、第二消息的第二，不同接收方、以及第二条件，该第二条件在被满足时，使第二消息在该会议期间被显示。方法500还可以包括在会议通过会议应用正在被举行时，由该会议应用针对第二条件是否被满足，监视会议的视听数据。方法500还可以包括响应于第二条件被满足，增强视听数据，以包括产生第二被增强的视听数据的第二消息。方法500还可以包括在会议应用的第三用户界面上，向第二接收方提供被增强的视听数据的视图。

方法500还可以包括，其中接收方仅是主持者参与方。如果接收方仅主持者参与方，则该消息很可能不在主持者的视听流的背景中，因为很多人不喜欢观看自己讲话并且在主持者的视听流的背景中呈现消息可能不会被注意到。视听应用中的其他位置，例如在主要显示区域102、辅助显示区域104、聊天窗口、主会议应用窗口等中显示的当前视频。对于诸如之类的软件，主会议应用窗口保持打开，同时主要显示区域102和辅助显示区域104提供会议的视听内容，从而允许在主会议应用窗口上提供消息。其他视听会议软件也有类似的操作方式。消息可以在主会议应用窗口的聊天窗口中提供，作为通过主会议应用窗口的通知等。

在一些实施例中，可以在第一应用中指定内容、条件、位置、形式、接收方、准则或其他消息相关数据，然后在第二应用中监视和实现。第一应用可以包括向用户提供用于生成演示的界面的演示应用。示例演示应用包括Keynote、Spark、Slides等。用户界面400例如可以被呈现为演示应用的一部分、演示应用的插件、演示应用的扩展等等。消息相关数据可以存储在消息和触发器228中并且例如通过文件名或其他标识符与演示相关联。然后，消息生成器234可以在演示被提供时访问消息相关的数据。

美国专利申请号15/992,795，标题为“Calendar-Aware Resource Retrieval”，于2018年5月30日提交，涉及开会洞察。开会洞察技术可以从电子邮件中提取潜在任务(例如，承诺、请求、后续行动等)，并向用户提供完成任务的提醒。开会洞察可以识别用户设置开会或生成演示的相关文件。实施例可以包括向参与方提供消息，该消息是由开会洞察生成的提醒。开会洞察可以存储在开会环境数据220中。情境建模器250可以生成具有与开会洞察一致的内容、条件、准则和格式的消息。上下文建模器250可以将消息相关数据存储在消息和触发器228中。消息和触发器228可以由消息生成器234监视，并且如果条件、准则或其组合被满足，则可以提供消息。例如，有关提醒用户X提供文档或跟进用户Y，则显示一条消息，内容为指示用户X要跟进用户Y，并且用户X和用户Y均为视听会议参与方的条件可以被生成(例如，由上下文建模器250)并存储在消息和触发器228中。然后，当用户X和用户Y都是视听会议的参与方时，可以向用户X提供消息，指示用户X应该在视听会议期间跟进用户Y或向用户Y提供文档。

图6通过示例示出了用于实现一个或多个实施例的机器600(例如，计算机系统)的实施例的框图。机器600可以实现用于改进会议中的上下文数据供应的技术。上下文建模器250、消息生成器234、设备224、246、252或其组件可以包括机器600的组件中的一个或多个。上下文建模器250、消息生成器234、设备224、246、252、方法500或其组件或操作中的一项或多项可以至少部分地使用机器600的组件来实现。一个示例机器600(以计算机的形式)可以包括处理单元602、存储器603、可移除存储装置610和不可移除存储装置612。尽管示例计算设备被示出和描述为机器600，但是计算设备在不同的实施例中可以采用不同的形式。例如，计算设备可以替代地是智能手机、平板电脑、智能手表或包括有关图6所示和描述的相同或相似元件的其他计算设备。智能手机、平板电脑、智能手表等设备通常统称为移动设备。此外，虽然各种数据存储元件被示为机器600的一部分，但是存储还可以是或替代地包括可经由网络(例如互联网)可访问的基于云的存储。

存储器603可以包括易失性存储器614和非易失性存储器608。机器600可以包括——或有权访问包括——各种计算机可读介质的计算环境，例如易失性存储器614和非易失性存储器608、可移除存储装置610和不可移除存储装置612的计算环境。计算机存储包括随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM)和电可擦除可编程只读存储器(EEPROM)、闪存或其他存储技术、只读光盘存储器(CD ROM)、数字多功能盘(DVD)或其他光盘存储装置、盒式磁带、磁带、磁盘存储装置或能够存储用于执行，以执行本文描述的功能的计算机可读指令的其他磁存储装置。

机器600可以包括或有权访问包括输入606、输出604和通信连接616的计算环境。输出604可以包括显示设备，例如触摸屏，其也可以用作输入设备。输入606可以包括触摸屏、触摸板、鼠标、键盘、相机、一个或多个设备专用按钮、集成在机器600内或通过有线或无线数据连接耦合到机器600的一个或多个传感器、以及其他输入设备中的一种或多种。计算机可以在网络环境中操作，使用通信连接来连接到一台或多台远程计算机，例如数据库服务器，包括基于云的服务器和存储。远程计算机可以包括个人计算机(PC)、服务器、路由器、网络PC、对等设备或其他公共网络节点等。通信连接可以包括局域网(LAN)、广域网(WAN)、蜂窝网络、电气和电子工程师协会(IEEE)802.11(Wi-Fi)、蓝牙或其他网络。

存储在计算机可读存储设备上的计算机可读指令可由机器600的处理单元602(有时称为处理电路)执行。硬盘驱动器、CD-ROM和RAM是包括诸如存储设备之类的非暂态计算机可读介质的制品的一些示例。例如，计算机程序618可用于使处理单元602执行本文描述的一种或多种方法或算法。

本文描述的操作、功能或算法可以在一些实施例中以软件实现。软件可以包括存储在计算机或其他机器可读介质或存储设备上的计算机可执行指令，例如一个或多个非暂态存储器(例如，非暂态机器可读介质)或其他类型的本地或网络的基于硬件的存储设备。此外，这样的功能可以对应于子系统，子系统可以是软件、硬件、固件或其组合。可以根据需要在一个或多个子系统中执行多种功能，所描述的实施例仅是示例。软件可以在数字信号处理器、ASIC、微处理器、中央处理单元(CPU)、图形处理单元(GPU)、现场可编程门阵列(FPGA)或在计算机系统上操作的其他类型的处理器上执行，例如作为个人计算机、服务器或其他计算机系统，将此类计算机系统转变为专门编程的机器。功能或算法可使用处理电路来实现，例如可包括电气和/或电子组件(例如，一个或多个晶体管、电阻器、电容器、电感器、放大器、调制器、解调器、天线、无线电、调节器、二极管、振荡器、多路复用器、逻辑门、缓存、高速缓存、存储器、GPU、CPU、可编程门阵列(FPGA)等)。

附加说明和示例

示例1可以包括用于视听会议中的上下文消息传送的方法，该方法包括由第一用户界面接收数据，该数据指示消息的内容、消息的接收方以及条件，该条件在会议期间被满足时，使消息在视听会议期间被可视地显示，在会议通过视听会议应用正在被举行时，针对该条件是否被满足，监视用户上下文数据，响应于条件被满足，增强来自视听会议应用的视听会议数据以包括产生被增强的视听数据的消息，以及在视听会议应用的第二用户界面上，向接收方提供被增强的视听数据的视图。

在示例2中，示例1还可以包括，其中数据还指示在第二用户界面上用以呈现消息的位置，并且消息的内容被呈现在所述第二用户界面上的该位置处。

在示例3中，示例1-2中的至少一个还可以包括，其中，视听会议应用在客户端或服务器上被执行。

在示例4中，示例1-3中的至少一个还可以包括，其中，数据还指示消息的内容的形式，该形式包括内容的呈现的类型，该类型包括滚动条带、思想气泡、通知、超链接或文本框。

在示例5中，示例4还可以包括，其中该形式还包括消息的内容的视觉透明度。

在示例6中，示例1至5中的至少一个还可以包括：数据的接收方包括特性条件，该特性条件指示仅满足特性条件的用户接收消息的内容。

在示例7中，示例6还可以包括，其中数据还包括限定进一步的特性条件的准则，该进一步的特性条件限定消息的内容的哪些部分被提供给接收方。

在示例8中，示例1-7中的至少一个还可以包括，其中条件包括会议的视听数据中发生的事件，该事件包括手势被执行、短语被说出、时间流逝、用户上下文信息的检查或出现的对象。

在示例9中，示例1-8中的至少一个还可以包括，其中用户上下文信息包括职称、教育状况、专业知识、任务状况、培训状况、设备类型或当前位置。

在示例10中，示例1-9中的至少一个还可以包括由第一用户界面接收数据，该数据指示第二消息的内容、第二消息的第二、不同接收方、以及第二条件，第二条件在被满足时，使第二消息在会议期间被显示，在会议通过会议应用正在被举行时，由会议应用针对第二条件是否被满足，监视会议的视听数据，响应于第二条件被满足，增强视听数据，以包括产生第二被增强的视听数据的第二消息，以及在会议应用的第三用户界面上，向第二接收方提供被增强的视听数据的视图。

在示例11中，示例1-10中的至少一个还可以包括，其中接收方仅是主持者参与方。

示例12可以包括计算设备，该计算设备包括处理电路装置和被耦合到该处理电路装置的存储器，该存储器包括指令，该指令在由处理电路执行时，使处理电路装置执行用于视听会议中的上下文消息传送的操作，该操作包括示例1-11中至少一个的方法。

示例13可以包括非暂态机器可读介质，其包括指令，当由机器执行时，使机器执行用于视听会议中的上下文消息传送的操作，该操作包括示例1-11之一的方法。

示例14可以包括用于视听会议兼容应用的用户界面，该用户界面被配置为执行操作，该操作包括：接收数据，该数据指示消息的内容、消息的接收方以及条件，该条件在会议期间被满足时，使消息在视听会议期间被可视地显示，以及存储接收到的数据，使得在会议通过视听会议应用正在被举行时，视听会议应用监视条件是否被满足，并且响应于条件被满足，增强视听数据以包括产生被增强的视听数据的消息。

在示例15中，示例14还可以包括，其中条件包括会议的视听数据中发生的事件，该事件包括手势被执行、短语被说出、时间流逝或对象出现。

在示例16中，示例14-15中的至少一个还可以包括，其中操作还包括接收数据，该数据指示第二消息的内容、第二消息的第二、不同接收方以及第二条件，该第二条件在被满足时使第二消息在会议期间被显示，以及存储接收到的数据，使得在会议通过视听会议应用正在被举行时，视听会议应用监视第二条件是否被满足，并且响应于第二条件被满足，增强视听数据以包括产生第二被增强的视听数据的第二消息。

尽管上面已经详细描述了一些实施例，但是其他修改也是可能的。例如，图中描绘的逻辑流程不需要按照所示的顺序或连续的顺序来实现期望的结果。可以提供其他步骤，或者可以从所描述的流程中消除步骤，并且可以向所描述的系统添加其他组件或者从所描述的系统中去除其他组件。其他实施例可以在以下权利要求的范围内。

Claims (15)

1.一种用于视听会议中的上下文消息传送的方法，所述方法包括：

由第一用户界面接收数据，所述数据指示消息的内容、所述消息的接收方以及条件，所述条件在所述会议期间被满足时，使所述消息在所述视听会议期间被可视地显示；

在所述会议通过视听会议应用正在被举行时，针对所述条件是否被满足，监视用户上下文数据；

响应于所述条件被满足，增强来自所述视听会议应用的视听会议数据，以包括产生被增强的视听数据的所述消息；以及

在所述视听会议应用的第二用户界面上，向所述接收方提供所述被增强的视听数据的视图。

2.根据权利要求1所述的方法，其中所述数据还指示在所述第二用户界面上用以呈现所述消息的位置，并且所述消息的所述内容被呈现在所述第二用户界面上的所述位置处。

3.根据权利要求1所述的方法，其中所述视听会议应用在客户端或服务器上被执行。

4.根据权利要求1所述的方法，其中所述数据还指示所述消息的所述内容的形式，所述形式包括所述内容的呈现的类型，所述类型包括滚动条带、思想气泡、通知、超链接或文本框。

5.根据权利要求4所述的方法，其中所述形式还包括所述消息的所述内容的视觉透明度。

6.根据权利要求1所述的方法，其中所述数据的所述接收方包括特性条件，所述特性条件指示仅满足所述特性条件的用户接收所述消息的所述内容。

7.根据权利要求6所述的方法，其中所述数据还包括限定进一步的特性条件的准则，所述进一步的特性条件限定所述消息的所述内容的哪些部分被提供给所述接收方。

8.根据权利要求1所述的方法，其中所述条件包括所述会议的视听数据中发生的事件，所述事件包括手势被执行、短语被说出、时间流逝、用户上下文信息的检查或对象出现。

9.根据权利要求1所述的方法，其中所述用户上下文信息包括职称、教育状况、专业知识、任务状况、培训状况、设备类型或当前位置。

10.根据权利要求1所述的方法，还包括：

由所述第一用户界面接收数据，所述数据指示第二消息的内容、所述第二消息的第二、不同接收方、以及第二条件，所述第二条件在被满足时，使所述第二消息在所述会议期间被显示；

在所述会议通过会议应用正在被举行时，由所述会议应用针对所述第二条件是否被满足，监视所述会议的视听数据；

响应于所述第二条件被满足，增强所述视听数据，以包括产生第二被增强的视听数据的所述第二消息；以及

在所述会议应用的第三用户界面上，向所述第二接收方提供被增强的所述视听数据的视图。

11.根据权利要求1所述的方法，其中所述接收方仅是主持者参与方。

12.一种计算设备，所述计算设备包括：

处理电路装置；以及

被耦合到所述处理电路装置的存储器，所述存储器包括指令，所述指令在由所述处理电路装置执行时，使所述处理电路装置执行用于视听会议中的上下文消息传送的操作，所述操作包括：

由第一用户界面接收数据，所述数据指示消息的内容、所述消息的接收方以及条件，所述条件在所述会议期间被满足时，使所述消息在所述视听会议期间被可视地显示；

在所述会议通过视听会议应用正在被举行时，针对所述条件是否被满足，监视用户上下文数据；

响应于所述条件被满足，增强来自所述视听会议应用的视听会议数据以包括产生被增强的视听数据的所述消息；以及

在所述视听会议应用的第二用户界面上，向所述接收方提供所述被增强的视听数据的视图。

13.根据权利要求12所述的计算设备，其中所述数据还指示在所述第二用户界面上用以呈现所述消息的位置，并且所述消息的所述内容被呈现在所述第二用户界面上的所述位置处。

14.根据权利要求12所述的计算设备，其中所述数据还指示所述消息的所述内容的形式，所述形式包括所述内容的呈现的类型，所述类型包括滚动条带、思想气泡或文本框。

15.根据权利要求14所述的计算设备，其中所述形式还包括所述消息的所述内容的视觉透明度。