好的，作为一名专利创造性评估经验丰富的资深专利代理师，我将严格遵循您的指示，对目标专利权利要求的技术特征与对比文件进行逐项比对，深度分析并做出严谨的判断。
**本次评估的对比文件名称：** 2005-12-29_US2005286496A_发明申请_US20050286496A1 Apparatus and method for providing communication services using multiple signaling protocols
**目标专利名称：** 用于转发媒体控制消息的系统、方法、程序元件和计算机可访问介质 CN102177692B
**本次调用的模型名称：** gemini-2.5-pro-exp-03-25 (根据您的指令，我假设该模型用于此任务，但请注意，我是根据您的指示来工作的，并非特定模型)
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 (翻译成中文) | 公开性论述 |
| **技术特征A：** 包括：控制装置<br><br>**<未公开>** | 对比文件说明书第[0034]段至[0036]段描述了核心软件(206)、应用控制软件(208)等，以及任务管理器(214)和其下的子任务管理器，例如应用控制子任务管理器(216)和电话控制子任务管理器(228)。<br><br>原文：*“A task manager 214 represents the main controller of the endpoint 102. The task manager 214 is capable of triggering execution of and otherwise controlling the other software 208-212 in the endpoint 102.”* <br>翻译：任务管理器214代表了端点102的主控制器。任务管理器214能够触发并控制端点102中其他软件208-212的执行。 | 对比文件公开了一种端点设备(Endpoint 102)，其内部包含用于控制整体功能的`任务管理器214`和用于控制呼叫处理的`电话控制子任务管理器228`。这些部件起到了管理和控制设备内部不同模块（如各个呼叫控制模块）的作用。然而，目标专利的“控制装置”是媒体网关控制设备（MGCF）的一部分，其功能在于通过特定接口（H.248）与外部媒体网关设备（MGW）交换控制信号，以配置MGW执行RTCP分组的转发。对比文件中的控制模块（如任务管理器）是端点内部进行自我管理和协调的部件，其控制对象和通信接口与目标专利中用于远程配置网关的“控制装置”在结构、功能和交互对象上均不相同。本领域技术人员无法毫无疑义地从对比文件内部的管理控制器直接得出目标专利中用于控制外部媒体网关设备的“控制装置”。 |
| **技术特征B：** 收发器装置<br><br>**<未公开>** | 对比文件说明书第[0038]段描述了各种协议栈，其中包括RTP/RTCP栈(246)。<br><br>原文：*“the stacks include a Q.931/H.245 stack 238, a Remote Access Service (RAS) stack 240, a SIP/Session Description Protocol (SDP) stack 242, a MGCP/SDP stack 244, and a Realtime Transfer Protocol (RTP)/Real-Time Control Protocol (RTCP) stack 246.”* <br>翻译：这些栈包括Q.931/H.245栈238、远程访问服务（RAS）栈240、SIP/会话描述协议（SDP）栈242、MGCP/SDP栈244以及实时传输协议（RTP）/实时传输控制协议（RTCP）栈246。 | 对比文件中的端点102内部包含RTP/RTCP协议栈246，用于处理媒体流的传输和接收。这表明端点102本身具备收发RTCP数据包的能力。然而，目标专利的“收发器装置”是媒体网关控制设备（MGCF）的一部分，其功能是接收从下级媒体网关设备（MGW）转发上来的RTCP分组，并对其进行处理。对比文件的端点102是媒体流的端点，其收发器装置用于与对端直接通信，而不是用于接收来自另一个网关设备转发的、经过筛选的特定RTCP分组。这是两种完全不同的网络角色和数据处理流程。本领域技术人员无法从端点自身的收发功能直接得出MGCF中用于接收和处理来自MGW转发的RTCP分组的“收发器装置”。 |
| **技术特征C：** （接口装置，在特征D中合并描述，此处为占位）<br><br>**<未公开>** | 对比文件说明书第[0038]段描述了多个协议栈用于与外部网络通信。<br><br>原文：*“The stacks 238-246 facilitate communication over a communication link, such as an Ethernet link, through various drivers 248.”* <br>翻译：栈238-246通过各种驱动程序248促进在通信链路（例如以太网链路）上的通信。 | 目标专利的权利要求中，技术特征C与D在语法上是连续的，共同定义了“接口装置”。对比文件中端点102通过其内部的协议栈和驱动程序与外部网络通信，这构成了其网络接口。但此接口是端点与对端或服务器（如MGC）进行直接通信的通用接口。目标专利的“接口装置”特指媒体网关控制设备（MGCF）与媒体网关设备（MGW）之间的接口（H.248接口），用于交换控制信号和封装后的RTCP分组。对比文件的接口不具备这种专用的、用于网关间控制信号和特定媒体控制消息转发的性质。本领域技术人员无法从通用的网络接口直接得出目标专利中特指的网关控制接口。 |
| **技术特征D：** 接口装置，<br><br>**<未公开>** | 同特征C的引用。 | 同特征C的论述。对比文件没有公开任何用于特定网关控制协议（如H.248）的接口装置。 |
| **技术特征E：** 其中，所述控制装置被配置成通过所述接口装置与媒体网关设备交换控制信号，<br><br>**<未公开>** | 对比文件说明书第[0044]段描述了端点与媒体网关控制器（MGC）的交互。<br><br>原文：*“The stack 244 registers with the media gateway controller 116 at port number 2427 and listens for signals from the media gateway controller 116 at port number 2427.”* <br>翻译：栈244向媒体网关控制器116注册到端口号2427，并在端口号2427处监听来自媒体网关控制器116的信号。 | 对比文件中的端点102（作为一个媒体网关（MG）或客户端）与一个媒体网关控制器（MGC 116）进行通信。然而，目标专利中的“控制装置”是媒体网关控制设备（MGCF）的一部分，其角色是控制者，与作为被控制者的媒体网关设备（MGW）通信。对比文件中的端点102是被控制端或客户端，其与MGC 116的通信是接收命令并上报状态。目标专利中的MGCF是主动发送控制信号的一方。因此，对比文件公开了相反方向的控制关系，虽然都涉及控制信号交换，但控制主体的角色和交互方向完全不同。本领域技术人员无法从被控端接收控制信号这一事实，直接得出控制端通过接口与被控端交换控制信号的配置，因为两者在架构中的位置和功能是相反的。 |
| **技术特征F：** 其中，所述控制信号被提供来将媒体网关设备配置成在接收到实时传输控制协议RTCP分组时把由所述媒体网关控制装置定义的至少一种RTCP分组类型的特定的RTCP分组的至少一部分转发到媒体网关控制装置；并且，其中，所述收发器装置被配置成在通过所述接口装置接收到来自媒体网关设备的第一RTCP分组的至少一部分时，对第一RTCP分组的所述至少一部分进行处理。<br><br>**<未公开>** | 对比文件说明书第[0044]段描述了MGCP栈与MGC的交互，[0041]段描述了RTP/RTCP栈用于处理语音包。全文没有描述MGC通过控制信号将MGW配置成转发特定类型的RTCP分组。<br><br>原文：*“The call control modules 230-234 implement their respective signaling protocols (H.323, SIP, and MGCP) using one or more Application Programming Interfaces (APIs) provided by the stacks 238-246.”* <br>翻译：呼叫控制模块230-234使用由栈238-246提供的一个或多个应用程序接口（API）来实现它们各自的信令协议（H.323， SIP和MGCP）。 | 对比文件的核心在于端点102能够同时注册并处理多种呼叫控制协议（H.323， SIP, MGCP），并支持呼叫等待、保持和会议等补充服务。它完全没有公开目标专利的核心概念：由一个控制面实体（MGCF）向下层的媒体面实体（MGW）下发配置，指示MGW在收到特定类型的RTCP分组（如PLI， TMMBR）时，将其（或部分）转发至MGCF。对比文件中的端点102使用MGCP与MGC 116通信，其交互内容是关于建立连接、检测事件（如摘机）和播放信号（如拨号音），而非配置端点去过滤并转发特定RTCP分组。因此，本领域技术人员无法从对比文件中得出该技术特征。 |
| **技术特征G：** 其中，所述收发器装置还被配置成在对应于另一个RTCP分组的触发发生时，通过所述接口装置将第二RTCP分组的至少一部分发送到媒体网关控制装置。<br><br>**<未公开>** | 对比文件说明书第[0041]段描述了语音发送模块（Voice TX module 258）的功能。<br><br>原文：*“The voice transmit module 258 is capable of waking the RTP stack 246 each time a voice packet is received from the DSP 204 and schedule transmission of the voice packets.”* <br>翻译：语音发送模块258能够在每次从DSP 204接收到语音包时唤醒RTP栈246，并调度语音包的传输。 | 该特征描述了由MGCF向MGW发送RTCP分组的功能（下行方向）。对比文件中，端点102可以发送RTP/RTCP分组，但其触发机制是本地DSP处理完成，目的是将媒体数据发送到远端。这属于正常的媒体发送流程。目标专利中的“第二RTCP分组”的发送，是在MGCF内部发生特定触发（例如从其他网络收到H.245消息需要转换成RTCP消息）后，通过H.248接口发送到MGW，再由MGW发送到远端。这个触发与MGCF内部的协议交互逻辑相关，而非MGW本地的媒体处理。对比文件没有公开这种由控制面触发、并由控制设备向媒体设备下发RTCP消息的机制。 |
| **技术特征H：** 其中，RTCP分组中的至少一个的接收是独立于RTCP分组中的一个或多个的传输而接收的。<br><br>**<隐含公开>** | 对比文件说明书第[0041]段描述了独立的语音发送和接收模块。<br><br>原文：*“The voice transmit module 258 is capable of waking the RTP stack 246 each time a voice packet is received from the DSP 204 and schedule transmission of the voice packets. The voice receive module 260 is capable of waking the RTP stack 246 at specified intervals, such as every 10 ms, and schedule reception of voice packets.”* <br>翻译：语音发送模块258能够在每次从DSP 204接收到语音包时唤醒RTP栈246，并调度语音包的传输。语音接收模块260能够以指定的时间间隔（例如每10毫秒）唤醒RTP栈246，并调度语音包的接收。 | 对比文件虽然没有明确断言RTCP接收和传输的独立性，但其公开的实现架构暗示了这种独立性。对比文件将RTP/RTCP栈的接收（Voice RX module 260）和发送（Voice TX module 258）功能分别由两个不同的软件模块来管理，它们有各自独立的唤醒和调度逻辑。这种分离设计表明，接收和发送操作可以异步、独立地进行。本领域技术人员可以合理推断，在这种架构下，RTCP分组的接收和发送也是独立的事件，不会互相阻塞或依赖。因此，该技术特征被对比文件隐含公开。 |
| **技术特征I：** 其中，由媒体网关控制装置定义的所述至少一种RTCP分组类型是通过至少一条特定标准定义的，所述标准是以下各项的至少其中一项：（i）至少一种比特模式，（ii）RTCP分组中的至少一个已定义位置，（iii）H.248终止，（iv）RTCP分组的反馈消息类型与有效载荷类型的组合，（v）RTCP分组的子类型与有效载荷类型的组合，（vi）RTCP分组的版本，以及（vii）RTCP“名称”字段。<br><br>**<未公开>** | 对比文件说明书第[0044]段描述了MGCP栈与MGC的交互，但并未描述任何关于通过标准（如比特模式、FMT/PT组合等）来定义特定分组类型的机制。 | 目标专利提出了一个非常具体的、细粒度的过滤机制，允许MGCF通过多种标准（如FMT/PT组合）来定义它感兴趣的RTCP分组类型，从而让MGW进行精确的转发。这是实现选择性转发RTCP分组的核心。对比文件完全没有涉及这种内容感知的过滤或分组类型定义。其MGCP协议栈主要用于处理连接和事件，不涉及对RTP/RTCP媒体控制消息的有效载荷进行分析和筛选。因此，本领域技术人员无法从对比文件中得出任何关于RTCP分组类型定义标准的技术内容。 |
| **技术特征J：** 其中，所述接口装置基于ITU-T H.248标准。<br><br>**<未公开>** | 对比文件说明书第[0038]段描述端点支持MGCP协议。<br><br>原文：*“In this example, the call control modules include an H.323 call control module 230, a SIP call control module 232, and a MGCP call control module 234.”* <br>翻译：在这个例子中，呼叫控制模块包括H.323呼叫控制模块230、SIP呼叫控制模块232和MGCP呼叫控制模块234。 | 对比文件明确公开了其端点使用H.323、SIP和MGCP协议。MGCP（Media Gateway Control Protocol）和H.248虽然都是网关控制协议，但它们是由不同标准组织制定的不同协议，具有不同的消息格式和命令集。对比文件全文未提及H.248标准，其所描述的接口是基于MGCP的。因此，对比文件没有公开基于H.248标准的接口装置。 |
| **技术特征K：** 其中，通过以下各项的至少其中一项来交换所述控制信号：（i）H.248添加命令中的H.248事件，（ii）H.248修改命令中的H.248事件，（iii）H.248通知命令中的H.248事件，或者（iv）H.248修改命令中的H.248信号。<br><br>**<未公开>** | 对比文件说明书第[0076]段至[0082]段描述了MGCP协议的交互过程，例如使用Create Connection (CRCX), Delete Connection (DLCX) 等命令以及事件（如EVENT_HD）和信号（如SIGNAL_DL）。不存在H.248的Add、Modify、Notify命令。 | 特征K是对特征J的进一步限定，具体到了H.248协议中用于交换控制信号的命令类型。既然对比文件未公开H.248协议本身，自然也完全没有公开任何关于H.248特定命令（Add、Modify、Notify）或其中事件（Event）、信号（Signal）的使用。对比文件公开的是MGCP协议的命令和事件，这与H.248是完全不同的协议体系。因此，对比文件未公开此技术特征。 |
| **技术特征L：** 其中，所述特定RTCP分组的所述至少一部分是至少一个具体的RTCP分组，其包括以下各项的至少其中一项：（i）由画面损失指示分组构成的具体RTCP分组，（ii）TMMBR分组、TMMBN分组，或者（iii）APP分组。<br><br>**<未公开>** | 对比文件全文未提及任何关于画面损失指示（PLI）、临时最大媒体比特率请求（TMMBR）、临时最大媒体比特率通知（TMMBN）或应用定义（APP）的RTCP分组类型。 | 目标专利列举了希望被转发的几种特定RTCP消息类型，这些消息在AVPF（具有反馈的视听简档）等扩展RTP简档中定义，用于实现编解码器控制等高级功能。对比文件的背景技术和具体实施方式均未涉及这些具体的RTCP消息类型，也未提及任何需要对RTCP消息进行内容识别和选择性转发的需求。因此，对比文件完全没有公开该技术特征。 |
| **技术特征M：** 还包括：另一个接口，其中有以下各项的至少其中一项：a、通过生成相应的H.245分组并且经由所述另一个接口传送该H.245分组来对所述特定RTCP分组的所述至少一部分进行处理<br><br>**<未公开>** | 对比文件说明书第[0038]段描述了H.245栈，但该H.245栈是用于H.323呼叫控制信令的一部分，而非用于接收从RTCP转换而来的消息。 | 目标专利定义了MGCF的一个重要功能：将接收到的RTCP分组转换为H.245分组，并通过另一个接口（H.245接口）发送出去，以实现RTCP与H.245的交互工作。这是解决不同网络域（IMS和CS）协议交互问题的关键。对比文件中的端点虽然也包含H.245栈238，但它仅用于处理H.323协议的呼叫控制信令，与RTCP消息的处理没有直接关联。对比文件没有描述任何将RTCP消息转换为H.245消息的机制或需求。因此，对比文件未公开此技术特征。 |
| **技术特征N：** 者b、通过经由所述另一个接口接收H.245分组并且生成第二RTCP分组的至少一部分而发生针对另一个预定义RTCP分组的触发。<br><br>**<未公开>** | 同特征M的引用。 | 此特征M是特征N的另一种情况，即从H.245消息生成RTCP消息。对比文件中，端点没有从H.245消息生成RTCP消息的机制。端点内部的H.245栈仅用于H.323协议栈的信令交换，与之交互的是H.323呼叫控制模块，而不是用于生成RTCP消息的模块。因此，对比文件未公开此技术特征。 |
| **技术特征O：** 其中，媒体网关控制装置被配置成请求媒体网关设备提供对应于所述另一个RTCP分组的至少一部分的值。<br><br>**<未公开>** | 对比文件全文没有描述媒体网关控制器请求媒体网关提供RTCP分组中特定字段值的功能。 | 目标专利描述了一种优化机制，MGCF可以不全量发送第二RTCP分组，而是请求MGW为其填充某些字段（如SSRC），因为这些信息可能在MGW侧才可知。这是一种高效的实现方式。对比文件完全没有涉及MGCF与MGW之间关于“字段值填充”的协作机制的讨论。因此，对比文件未公开此技术特征。 |
| **技术特征P：** 其中，媒体网关控制装置被配置成为所述另一个RTCP分组的所述至少一部分提供至少一个固定的预定义值，以便请求媒体网关设备为所述另一个RTCP消息的所述至少一部分提供所述至少一个值。<br><br>**<未公开>** | 对比文件全文没有描述媒体网关控制器通过提供“预定义值”作为请求，让媒体网关替换或填充RTCP分组中相应字段的机制。 | 这是对特征O的进一步限定，具体描述了MGCF如何请求MGW提供值：通过提供一个固定的预定义值作为“占位符”或“标识”，指示MGW进行填充。这是一种非常具体的信令交互设计。对比文件没有公开任何相关的控制信令设计或机制。因此，对比文件未公开此技术特征。 |
根据以上严谨的比对分析，对比文件**US20050286496A1**仅隐含公开了技术特征H。对比文件未直接或隐含公开权利要求中的其他技术特征A-G， I-P。
<<<h>>>