作为一名经验丰富的专利代理师，我将为您对目标专利的权利要求1进行深度的技术拆解，并结合其说明书背景进行解释，随后与对比文件D1（WO2006084503A1）进行详尽的特征比对与创造性分析。

一、 结合目标专利说明书对权利要求1的解释

目标专利（CN101843073B）旨在解决实时流媒体信道切换时的延迟问题。在常规技术中（如说明书[0005]段落所述），当检测到内容源改变时，媒体播放器会“重新初始化”，即拆卸现有的再现路径（包括源过滤器、变换过滤器、解码器等）并重新建构新的再现路径，这个过程会导致数秒的延迟、黑屏或图像失真。

权利要求1提出了一种在装置（客户端）侧实现快速信道切换的方法。其核心逻辑在于**“格式比对”与“路径复用”**：

1. 触发切换（特征A、B）： 接收用户的信道切换指示，并从装置的协议栈获取新信道的内容。

2. 格式判定（特征C）： 这是本发明的核心步骤。说明书[0027]-[0029]段落指出，装置会判断新内容与当前内容是否具有相同的格式（例如是否可以使用相同的H264解码器等）。

3. 路径复用（特征D、E）： 如果格式相同，装置将跳过重新初始化的步骤，直接将新内容馈送（输入）到当前现存的第一再现路径中。在具体实现上（如说明书[0057]段落所述），这涉及发送激活消息，并指示新流数据递送到与旧流相同的端点（即相同的单播IP地址和端口）。

二、 对比文件D1（WO2006084503A1）的公开情况分析

对比文件D1（WO2006084503A1）同样致力于解决分组交换网络中按需多信道流媒体（如移动TV）切换时的延迟问题（见D1的[p0012]-[p0013]）。D1的核心思想是通过在初始建立单一的流媒体会话（Single Session），并在服务器端重写RTP包头，使得客户端可以在不重新初始化会话的情况下切换信道。

以下是D1对权利要求1各技术特征的公开情况分析：

• 技术特征A（接收信道选择指示符，识别第二信道...）：

  毫无异议公开。 D1公开了用户触发信道切换，应用向控制单元发出新信道信号。

  • D1原文出处： [p0060] "If the user triggers a switch to a new channel, the mobile TV application signals the new channel to the channel switch control 20C..." 以及 [p0066] "The user's request, 27, for switching a channel is forwarded from the Channel Switch Control, 20C, on the user side to the Channel Switch Control, 20D, on the network side..."

• 技术特征B（从所述装置的协议堆栈获得所述第二内容）：

  实质公开。 D1公开了客户端通过RTP协议接收流媒体数据，并在协议处理单元（RTP processing 20K）中获得数据。

  • D1原文出处： [p0038] "The streaming data from the server is transported over Single 'Mobile TV' RTP Flow, 33 to a RTP processing, 20K..."

• 技术特征C（通过确定第二内容是否具有与第一内容相同的内容格式来确定是否可使用第一再现路径）：

  未公开。 目标专利的特征C是在装置（客户端）侧动态判断新旧信道格式是否一致，以此作为是否复用再现路径的条件。而D1的机制是在服务器端的SDP聚合阶段（建链前）就已经强行要求并验证了同一个Bundle内的所有信道必须具有相同的编码和比特率，客户端在切换时并不执行“格式判断”这一动作。

  • D1相关出处： [p0044] "By comparing the appropriate attribute lines in the various SDP files, the SDP aggregator verifies that within a channel bundle all channels are encoded at the same bitrate with the same codecs."（这表明判定动作发生在服务器端，而非装置执行实时判定）。

• 技术特征D（在确定可使用情况下，将第二内容输入到第一再现路径中）：

  实质公开。 尽管D1没有客户端的“确定”步骤（缺少特征C），但D1确实实现了将第二内容输入到当前现有的解码和播放路径中，而无需拆卸客户端的播放器。

  • D1原文出处： [p0069] "For the client switching between channels is transparent." 以及 [p0038] 描述了数据持续流向现有的 "Media Decoding, 20L and a Playback function, 20M"。

• 技术特征E（发送激活消息和指示所述第二内容将被递送到相同的端点）：

  部分公开/未完全公开。 D1确实发送了切换消息（例如RTSP SET_PARAMETER），并且数据确实是在同一个端点（相同的RTP Session端口）接收。但是，D1发送的消息中仅仅指示了目标信道（如 Channel: 2），而没有明确包含“指示所述第二内容将被递送到相同的端点”这一具体指令信息，因为D1中端点重用是单一会话机制自带的底层属性。

  • D1原文出处： [p0066] "In this example the client sends an RTSP SET_PARAMETER command containing the message 'Channel: 2' to the server, telling the server that it should switch to channel '2'..."

三、 技术特征比对表格

四、 最接近的对比文件与创造性分析

1. D1是否适合作为最接近的对比文件？

非常适合。 从整体解决的技术问题来看，目标专利与D1（WO2006084503A1）解决的是完全相同的痛点：降低分组交换网络中实时流媒体（特别是Mobile TV）信道切换时的延迟。

从技术效果来看，两者都旨在通过复用客户端现有的接收/播放资源（避免媒体播放器重新初始化），从而实现无缝或极低延迟的信道切换。因此，D1与目标专利处于相同的技术领域，面临相同的技术问题，且产生了相似的整体技术效果，是创造性评判中极佳的最接近对比文件。

2. 没有被最接近对比文件公开的特征是否被其他对比文件公开？

目标专利的核心区别技术特征在于特征C（装置侧的内容格式比对）以及特征E后半段（激活消息中包含递送至同端点的指示）。

注：因本次提示词中仅提供了一篇对比文件（D1），故无法判定这些区别特征是否被“其他”对比文件公开。

但在实际的创造性答辩或无效宣告逻辑中，可以将本案的发明构思总结为：“基于客户端（装置侧）自主驱动的格式兼容性判定来实现再现路径复用”，这与D1中**“基于服务器端强制统一格式并欺骗客户端（重写RTP Header）来实现路径复用”**属于截然不同的技术路线。目标专利的技术方案赋予了终端设备更大的自主性和对异构流的适应性（如果格式不同，终端可以选择拆建新路径），这一区别特征使得目标专利在面对D1时具有较强的创造性答辩空间。

你好。作为一名经验丰富的专利代理师，我将根据你提供的目标专利说明书以及对比文件，对权利要求1进行深入的比对与分析。

我们的核心任务是解释权利要求1的保护范围，并重点排查对比文件（D1-D7）是否单独或组合公开了“技术特征E”。

权利要求1及目标专利说明书解析

结合目标专利说明书，权利要求1旨在解决设备在切换实时内容信道时，由于媒体播放器等再现逻辑“重新初始化”（拆卸旧再现路径并建构新再现路径）而导致的时间延迟问题。

其实质性技术方案在于：当接收到信道切换请求时（特征A），设备从协议堆栈获取新内容（特征B），并判断新老内容的内容格式是否相同（特征C）。如果格式相同，则直接复用当前的“第一再现路径”（特征D）。

对于特征E（发送激活消息和指示第二内容将被递送到相同的端点），说明书段落 [0057] 给出了明确的解释：在如MediaFLO的系统中，流内容通过UDP/IP递送。为了避免播放器重新初始化，系统通过客户端发送“激活消息”，并在消息中指示新的流内容需要发送到与旧流相同的单播IP地址和端口（即相同的端点）。这样，底层的协议堆栈会将新的数据流直接“灌入”现有的再现路径中，从而实现极速切换。

对比文件特征比对表

以下是权利要求1各项技术特征与对比文件（D1-D7）的比对情况。

• D1: JP2003523103A

• D2: JP2004104415A

• D3: US6791620B1

• D4: US20040228345A1

• D5: JP2005328269A

• D6: CN2794050Y

• D7: WO2006084503A1

技术特征E的详细分析

结论：对比文件D1-D7无论是单独还是组合，均没有毫无疑义的公开或实质公开技术特征E。

以下为针对各对比文件的具体分析依据：

1. 针对 D7 (WO2006084503A1) 的重点排查

D7是这批对比文件中与“无缝切换流媒体”意图最接近的一篇。D7通过维持一个单一的流媒体会话（Single RTSP Session）来实现快速切换，以避免拆除和重建会话带来的延迟。

• D7的实施方式：根据D7原文的描述，当客户端想要切换频道时，它会向服务器发送一个带外或带内的控制消息（例如 RTSP SET_PARAMETER 消息，原文：RTSP: SET_PARAMETER rtsp://mobiletv.com/Bundle-1 RTSP/1.0... Channel: 2）。服务器端的信道切换控制单元（Channel switch control unit, 20D）收到请求后，在服务器端重写输出RTP数据包的RTP头部（包括SSRC、序列号、时间戳等，见原文：rewriting the relevant fields in the RTP），使客户端认为它仍然在接收同一个视频流。

• 区别分析：D7的切换逻辑完全在服务器端（Server side）实现。客户端播放器只需被动接收被服务器“伪装”过的RTP流。虽然物理上数据可能流向了客户端的同一个网络端口（端点），但D7并未公开本专利权利要求1中由装置（客户端）内部主动执行的控制机制。目标专利的特征E是指：装置在判断格式一致后，主动在内部（例如向自身的FDAI接口或协议堆栈）发送激活消息，并主动指示将第二内容路由到当前的同一个端点（IP:Port）。D7中不存在客户端主动指示其底层协议堆栈更改数据流路由到相同端点的技术启示，它只是被动接收服务器处理后的流。

2. 针对 D1 (JP2003523103A) 的分析

• D1主要探讨的是压缩数字数据的无缝视频切换系统，特别是在MPEG视频流的GOP边界插入拼接点（Splice points）以及利用间隙时间（Gap time）和双调谐器、双缓冲器来掩盖切换延迟（原文提及：ディジタルシステムにおける改善されたシームレス切り換え，利用缓冲区和GOP结构）。

• 区别分析：D1侧重于MPEG帧层面的拼接和缓冲控制，完全没有涉及协议堆栈（Protocol Stack）层面的操作，也没有涉及向协议堆栈发送“激活消息”并指示递送到“相同端点”（如IP/端口映射）的机制。因此D1未公开特征E。

3. 针对 D5 (JP2005328269A) 的分析

• D5涉及通过预测用户的界面操作（例如鼠标移动到切换按钮附近）来提前控制缓冲区（如要求服务器停止发送以降低缓冲区水位），从而在真正点击切换时减少由于缓冲带来的延迟（原文：入力ポインタが...指定領域内に位置することを検出してストリーム切り替え準備の開始を判定する）。

• 区别分析：D5是通过“预测用户操作+控制缓冲区蓄积量”来减少延迟，根本没有提及复用媒体再现路径（Reproduction Path），更没有提及发送指示递送至相同端点的激活消息。

4. 针对 D2、D3、D4、D6 的分析

• D2 涉及在接收端使用代理执行装置来处理不同格式（如XML和JAVA）的数据广播，主要解决跨格式兼容问题，未涉及复用再现路径和端点重定向。

• D3 涉及在不同视频硬件接口格式（如SD和HD）之间进行转换和缩放，属于视频基带信号的格式转换管理，不涉及网络流媒体的协议栈操作和端点控制。

• D4 是在光传输网络（ONU/OLT）中利用ATM虚拟信道连接（VCC）信息和PID进行底层数据包的分类和硬件开关切换，属于网络传输层的路由交换，不涉及终端设备内部媒体播放器路径的复用及端点分配。

• D6 涉及MBMS（多媒体广播/多播服务）中专用信道与共享信道的无线资源调度与切换，属于无线通信底层的物理/逻辑信道分配，与应用层的媒体再现路径毫无关联。

总结

权利要求1的核心在于终端设备（装置）内部的智能化路由复用：通过判断内容格式，若兼容，则装置主动向其协议堆栈发送激活消息，将新流的数据定向到媒体播放器现有的“端点”（如现有的Socket端口），从而免去了播放器重建解码器和渲染器的数秒延迟。

提供的七篇对比文件中，虽然有涉及无缝切换（D1、D7）或提前缓冲控制（D5）的技术，但其解决思路均与目标专利不同（D1基于GOP缓冲拼接，D5基于界面预测，D7基于服务器端RTP包头重写欺骗客户端）。没有任何一篇对比文件给出了在客户端内部通过发送激活消息指示协议堆栈将新流递送到相同端点的技术启示。因此，特征E具备突出的实质性特点，未被对比文件单独或结合公开。