对比文件名称：2012-06-21_US2012154516A_发明申请_US20120154516A1 AGGREGATION OF VIDEO RECEIVING CAPABILITIES
目标专利名称：用于群通信中基于动态讲话者ID的媒体处理的框架和方法 CN104885487B
模型名称：DeepSeek
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：包括：在所述群通信会话期间在所述计算设备中接收媒体数据，所述媒体数据至少包括所述媒体数据的发送者的标识符(发送者ID) <br> **《未直接公开，隐含公开》** | 说明书第[0033]段：“When client 1 joins with HD and VGA and CIF and QCIF capability, as illustrated by table 342, the capability information is transmitted to the MCU (343).” <br> 说明书第[0045]段：“One special receiver to be considered is the Primary Dominant Speaker (also referred to as Primary Video Source “PVS”), who may request to Secondary (previous) Dominant Speaker (also referred to as Secondary Video Source “SVS”) as its main video source.” | 对比文件公开了在多点视频会议（一种群通信会话）中，参与者（客户端）会向多点控制单元（MCU）发送其能力信息（[0033]段）。MCU需要管理和协调来自不同源的视频流（例如，主视频源PVS、聚光灯源SVS等），这意味着在会议过程中，接收方设备（计算设备）必然会接收到来自特定发送者（如PVS、SVS或其他参与者）的视频流媒体数据。虽然对比文件没有明确声明媒体数据分组中“包括”发送者标识符，但为了识别视频流的来源（例如，区分主视频源和聚光灯源），本领域技术人员可以毫无疑义地推断出，在MCU分发的媒体流或相关的会话信令中，必然包含了用于标识发送者（源）的信息（如PVS ID、SVS ID等），否则接收方无法区分和处理来自不同源的多个流。因此，对比文件隐含公开了在群通信会话期间，计算设备接收包含发送者标识符的媒体数据。 |
| **技术特征B**：在所述计算设备中标识与所接收到的媒体数据相关联的所述发送者ID以及多个不同媒体类型中与所接收到的媒体数据相关联的媒体类型 <br> **《未直接公开，隐含公开》** | 说明书第[0044]段：“...conference allowed preference table for each source may look like this: ... Primary DS ... Spotlight source 1 ...”。 <br> 说明书第[0020]段：“Video capabilities may be defined as resolution, frame rate, bit rate, number of streams, and the like.” | 对比文件公开了会议中存在多个视频源（如Primary DS, Spotlight source 1等），接收方设备需要区分来自这些不同源的流（[0044]段），这隐含了设备需要标识发送者ID（即源标识）。然而，对比文件始终将传输的媒体描述为“视频”（video），其“能力”（capabilities）也仅涉及视频的参数如分辨率、帧率等（[0020]段）。目标专利中的“媒体类型”明确包括图片、文本消息、视频、声音等多种不同类型（参见说明书[0021]段）。对比文件仅涉及“视频”这一单一媒体类型，并未公开需要标识“多个不同媒体类型”中的一种。因此，对比文件没有公开“标识媒体类型”这一特征。但是，由于对比文件明确处理“视频”流，可以认为其隐含公开了所接收的媒体数据的“媒体类型”是视频。因此，该特征被部分隐含公开（标识发送者ID和标识媒体类型为视频）。 |
| **技术特征C**：在所述计算设备中标识呈现规则，所述呈现规则将所述发送者ID和关联于所接收到的媒体数据的媒体类型与所述计算设备的多个接口中有能力呈现关联于所接收到的媒体数据的媒体类型的一个或多个接口相关， <br> **《未公开》** | 说明书第[0025]段：“To provide each participant with the ability to request multiple video sources and deliver the right streams, MCU 116 has to consider various factors including: receiver's capabilities (e.g. PC or mobile device's processing power, downlink bandwidth to the client during the meeting), sender's capabilities ... viewer's preferences (e.g. number of sources to view, display size of each source)...” <br> 说明书第[0040]段：“Client 1 may also indicate that its preferred capability 468 is VGA main video, CIF spotlight 1, CIF spotlight 2, and CIF spotlight 3 (1 VGA+3 CIF).” | 对比文件的核心在于MCU根据接收方的“偏好能力”（preferred capability）和“会议接收能力”（conference receiving capability）来聚合请求，并为每个发送源确定一个统一的“允许偏好”（allowed preference），即发送方应使用的视频分辨率（如[0040]段）。这个“允许偏好”是MCU计算后下发给发送方的指令，用于控制发送流的格式（分辨率），以确保会议整体优化。它并非目标专利中定义的、存储在接收方“计算设备”本地的“呈现规则”。目标专利的“呈现规则”是接收方设备本地定义的规则，用于根据发送者ID和媒体类型，将媒体路由到特定的硬件或软件接口（如显示器、耳机、扬声器电话等）进行呈现。对比文件完全没有涉及接收方设备根据发送者ID选择不同呈现接口的概念。因此，对比文件既未直接公开也未隐含公开该技术特征。 |
| **技术特征D**：其中所述呈现规则在所述群通信会话期间能由所述计算设备动态地配置以响应于所述一个或多个接口的操作状态在所述群通信会话期间已改变的指示而改变与所述发送者ID和所述媒体类型相关的所述一个或多个接口 <br> **《未公开》** | 说明书第[0027]段：“...and allow one participant to request multiple view sources in addition to allowing receiving capabilities to change anytime during the course of a meeting.” | 对比文件提到参与者的接收能力（receiving capabilities）可以在会议期间随时改变（[0027]段）。这里的“接收能力”指的是设备能够处理的视频分辨率、帧率等参数，这与目标专利中因“接口的操作状态改变”（如耳机被拔除、显示器被连接）而动态改变呈现规则有本质不同。目标专利的“动态配置”是针对本地呈现接口的映射规则，而对比文件的“改变”是针对设备向MCU上报的其能处理的视频格式参数。两者解决的问题和技术手段均不相同。因此，对比文件没有公开该技术特征。 |
| **技术特征E**：经由所述计算设备的与所述发送者ID和关联于所接收到的媒体数据的媒体类型相关的所述一个或多个接口来呈现所接收到的媒体数据。 <br> **《未公开》** | 说明书第[0021]段：“Participant machines 102, 104 may be any computing device with audio/video capability such as desktop or laptop computers with a camera and microphone (as well as a speaker)...” | 对比文件公开了参与者设备（计算设备）接收并呈现视频数据（[0021]段）。然而，如对特征C的分析，对比文件中的呈现是基于MCU确定的统一分辨率格式来接收和播放视频流，并不涉及根据发送者ID和媒体类型选择特定接口（如主显示器、副显示器、耳机等）进行呈现。目标专利的特征E是执行特征C所标识的“呈现规则”的结果。既然特征C未被公开，特征E所定义的基于规则选择特定接口进行呈现的过程也就未被公开。因此，对比文件没有公开该技术特征。 |
| **技术特征F**：其特征在于：所标识的呈现规则将所述发送者ID和关联于所接收到的媒体数据的所述媒体类型与所述多个接口中若存在的有能力呈现所接收到的媒体数据的第一接口相关以及在所述第一接口不存在的情况下与所述多个接口中有能力呈现所接收到的媒体数据的第二接口相关，以及所述用于呈现所接收到的媒体数据的一个或多个接口包括在所述第一接口存在的情况下的所述第一接口或者在所述第一接口不存在的情况下的所述第二接口。 <br> **《未公开》** | 未发现相关内容。 | 该特征限定了呈现规则是一种备用或回退规则：优先使用第一接口，若第一接口不存在则使用第二接口。对比文件全文未提及任何关于根据接口是否存在（例如，耳机是否插入、外部显示器是否连接）来选择不同呈现接口或路径的内容。其技术焦点完全在于视频流的分辨率协商和聚合，与硬件/软件接口的可用性检测和动态切换无关。因此，对比文件既未直接公开也未隐含公开该技术特征。 |
| **技术特征G**：其特征在于，所述呈现规则是用户可配置的，所述方法进一步包括：接收用户输入 <br> **《未直接公开，隐含公开》** | 说明书第[0025]段：“...viewer's preferences (e.g. number of sources to view, display size of each source)...” <br> 说明书第[0040]段：“Client 1 may also indicate that its preferred capability 468 is VGA main video, CIF spotlight 1, CIF spotlight 2, and CIF spotlight 3 (1 VGA+3 CIF).” | 对比文件多次提到参与者的“偏好”（preferences）或“偏好能力”（preferred capability），并且客户端可以向MCU指示其对不同视频源的偏好能力（如希望主视频源以VGA分辨率发送，聚光灯1以CIF分辨率发送等，见[0040]段）。这种“指示”必然来源于用户的配置或输入。因此，本领域技术人员可以合理推断，用户可以通过客户端设备的界面进行配置，以设定这些偏好，即对比文件隐含公开了接收用户输入以配置某种规则（偏好能力）的步骤。 |
| **技术特征H**：响应于所述用户输入而配置所述呈现规则。 <br> **《未公开》** | 说明书第[0040]段：“Client 1 may also indicate that its preferred capability 468 is VGA main video, CIF spotlight 1, CIF spotlight 2, and CIF spotlight 3 (1 VGA+3 CIF).” | 对比文件公开了客户端可以指示其“偏好能力”（preferred capability），这可以看作是响应用户输入配置了一种“规则”。然而，如前面特征C所述，这种“偏好能力”规则与目标专利的“呈现规则”在目的和内容上完全不同。目标专利的“呈现规则”配置的是本地接口选择；对比文件的“偏好能力”配置的是期望从发送方接收的视频流格式参数，并上报给MCU。两者配置的对象和效果不同。因此，虽然对比文件隐含了响应用户输入配置“偏好能力”，但该“偏好能力”并非目标专利所定义的“呈现规则”。故该特征未被公开。 |
| **技术特征I**：其特征在于，接收用户输入和响应于所述用户输入而配置所述呈现规则是在所述群通信会话期间完成的。 <br> **《未直接公开，隐含公开》** | 说明书第[0027]段：“...allowing receiving capabilities to change anytime during the course of a meeting.” | 对比文件明确指出允许接收能力在会议（即群通信会话）期间的任何时间改变（[0027]段）。由于“接收能力”或“偏好能力”的改变是基于用户输入（见特征G分析），因此可以合理推断用户输入以及据此进行的配置（即更新上报给MCU的偏好能力）是发生在群通信会话期间的。因此，该特征被对比文件隐含公开。 |
| **技术特征J**：其特征在于，所述一个或多个接口包括以下一者或多者：显示器、头戴式耳机、扬声器电话、端口、应用或辅助设备。 <br> **《未直接公开，隐含公开》** | 说明书第[0021]段：“Participant machines 102, 104 may be any computing device with audio/video capability such as desktop or laptop computers with a camera and microphone (as well as a speaker)...” <br> 说明书第[0064]段：“Output device(s) 614 such as a display, speakers, printer, etc. may also be included.” | 对比文件描述了参与者机器是具有音频/视频能力的计算设备，如带有摄像头、麦克风和扬声器的台式机或笔记本电脑（[0021]段）。在描述计算设备组件时，也提到了输出设备包括显示器（display）、扬声器（speakers）等（[0064]段）。扬声器可以对应于“扬声器电话”，显示器是明确的接口。因此，对比文件隐含公开了计算设备具有用于呈现媒体的接口，包括显示器和扬声器。虽然未明确列举头戴式耳机、端口、应用或辅助设备，但作为具有音频/视频能力的通用计算设备，本领域技术人员可以理解其必然包含用于输出音频和视频的物理或逻辑接口。因此，该特征被隐含公开。 |
| **技术特征K**：其特征在于，进一步包括：存储对所述计算设备的被用来呈现所接收到的媒体数据的所述一个或多个接口的指示 <br> **《未公开》** | 未发现相关内容。 | 对比文件没有提及计算设备会存储关于“哪个接口被用于呈现媒体数据”的指示或历史记录。其技术方案聚焦于MCU侧的聚合算法和客户端侧的偏好上报，不涉及本地呈现接口使用记录的跟踪和存储。因此，该特征未被公开。 |
| **技术特征L**：至少部分地基于所存储的对用于呈现所接收到的媒体数据的所述一个或多个接口的指示来更新所标识的呈现规则以生成经更新呈现规则 <br> **《未公开》** | 未发现相关内容。 | 该特征依赖于特征K中存储的接口使用指示来更新呈现规则。由于特征K未被公开，且对比文件中完全没有提及基于接口使用历史来自动更新任何本地或上报规则（如偏好能力）的内容，因此该特征未被公开。 |
| **技术特征M**：在所述群通信会话期间在所述计算设备中接收新媒体数据，所述新媒体数据包括另一发送者标识符(另一发送者ID) <br> **《未直接公开，隐含公开》** | 说明书第[0044]段：“An example conference allowed preference table constructed by the MCU for each source may look like this: Source: Primary DS, Spotlight source 1, Spotlight source 2, Spotlight source 3, Spotlight source 4...” | 该特征与技术特征A类似，区别在于接收的是“新媒体数据”和“另一发送者ID”。对比文件公开了会议中可以有多个视频源（如Primary DS, Spotlight source 1, 2, 3, 4），接收方设备会从这些不同的源接收视频流（[0044]段）。当接收来自不同源（即不同发送者）的媒体数据时，该过程即相当于接收包含“另一发送者ID”的“新媒体数据”。因此，该特征被对比文件隐含公开。 |
| **技术特征N**：在所述计算设备中标识与所接收到的新媒体数据相关联的所述另一发送者ID <br> **《未直接公开，隐含公开》** | 同特征M的引用及分析。 | 如特征M所述，对比文件公开了会议中有多个源，接收方设备需要区分来自不同源的流。为了正确处理来自不同聚光灯源或主发言人的视频流，接收方设备必须能够标识当前接收的流来自哪个发送者（源）。因此，标识与新媒体数据相关联的另一发送者ID是该技术方案的必然要求，被隐含公开。 |
| **技术特征O**：在所述计算设备中标识所接收到的新媒体数据的新媒体类型 <br> **《未直接公开，隐含公开》** | 同特征B的引用及分析。 | 该特征与技术特征B中的“标识媒体类型”部分对应。对比文件处理的媒体始终是“视频”，因此当接收新媒体数据时，其标识出的媒体类型自然也是“视频”。因此，该特征被隐含公开。 |
| **技术特征P**：在所述计算设备中标识与所述另一发送者ID和所述新媒体类型相关联的经更新呈现规则 <br> **《未公开》** | 未发现相关内容。 | 该特征依赖于之前步骤中生成的“经更新呈现规则”（见特征L）。由于特征L（更新呈现规则）未被公开，且对比文件中不存在与目标专利“呈现规则”对应的、将发送者ID和媒体类型映射到本地呈现接口的规则，因此，标识与另一发送者ID和新媒体类型相关联的“经更新呈现规则”这一步骤在对比文件中没有对应基础，未被公开。 |
| **技术特征Q**：基于所标识的经更新呈现规则来选择所述计算设备的另一接口以用于呈现所述新媒体数据 <br> **《未公开》** | 未发现相关内容。 | 该特征依赖于特征P中标识的“经更新呈现规则”。由于特征P未被公开，且对比文件未涉及基于发送者ID和媒体类型选择本地呈现接口，因此该特征未被公开。 |
| **技术特征R**：经由所述计算设备的所选另一接口来呈现所述新媒体数据。 <br> **《未公开》** | 未发现相关内容。 | 该特征是执行特征Q的结果。由于特征Q（基于经更新呈现规则选择另一接口）未被公开，因此该特征也未被公开。 |
| **技术特征S**：其特征在于，所述媒体类型是以下一者或多者：图片、文本消息、视频、声音、多用途因特网邮件扩展(MIME)、分辨率、格式或文件扩展。 <br> **《未直接公开，隐含公开》** | 说明书第[0020]段：“While embodiments are described for video conference systems, ... Network-based conferences combining various forms of communication such as audio, video, instant messaging, application sharing, and data sharing may be facilitated using the principles described herein.” | 对比文件在背景和实施例描述中主要聚焦于“视频”会议（video conference），其“媒体类型”明确为视频（video）。但在[0020]段也提及，所描述的原理可用于促进结合了音频（audio）、视频（video）、即时消息（instant messaging）等多种通信形式的基于网络的会议。这表明对比文件所处理的“媒体”不限于视频，还可能包括音频和即时消息（可视为文本消息）。因此，对比文件隐含公开了媒体类型包括视频、音频和文本消息。然而，目标专利列举的其他媒体类型（如图片、MIME、分辨率、格式、文件扩展）在对比文件中并未提及。因此，该特征被部分隐含公开（视频、声音、文本消息）。 |
| **技术特征T**：其特征在于，进一步包括：将对所述计算设备的用于呈现所接收到的媒体数据的所述一个或多个接口的指示从所述计算设备发送给与所标识的发送者ID相关联的计算设备。 <br> **《未公开》** | 说明书第[0045]段：“The MCU may just send the Primary Dominant Speaker's local main video preferred capability (PC) to the Secondary Dominant Speaker.” | 对比文件公开了MCU可以将主发言人的本地主视频偏好能力（PC）发送给次发言人（[0045]段）。这是控制服务器（MCU）在参与者之间转发信息，用于协调发送方的视频参数。而目标专利的特征T要求接收方计算设备将其“用于呈现所接收到的媒体数据的一个或多个接口的指示”发送给发送方计算设备。这是一个完全不同的反馈机制，目的是通知发送方其媒体是如何被呈现的。对比文件没有公开接收方设备向发送方设备发送关于其本地呈现接口的信息。因此，该特征未被公开。 |
| **技术特征U**：其特征在于，进一步包括：将对所述计算设备的用于呈现所接收到的媒体数据的所述一个或多个接口的指示从所述计算设备发送给参与所述群通信会话的所有其他计算设备。 <br> **《未公开》** | 未发现相关内容。 | 该特征与特征T类似，但发送对象是“所有其他计算设备”。对比文件中同样没有公开接收方设备向所有其他参与者设备广播其本地呈现接口信息的内容。MCU聚合的是“能力”和“偏好”，而非“接口使用指示”。因此，该特征未被公开。 |
<<<a>>><<<b>>><<<g>>><<<i>>><<<j>>><<<m>>><<<n>>><<<o>>><<<s>>>