对比文件名称：2006-08-17_WO2006084503A_发明申请_WO2006084503A1 ON-DEMAND MULTI-CHANNEL STREAMING SESSION OVER PACKET-SWITCHED NETWORKS
目标专利名称：用于装置上的实时内容之间的快速信道切换的方法和设备CN101843073B
本次调用的模型名称：DeepSeek最新版本模型
### 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：《直接公开》<br>接收信道选择指示符，所述信道选择指示符识别包括待再现的第二内容的第二信道而不是具有经由在所述装置内的第一再现路径当前正在再现的第一内容的第一信道 | 对比文件[p0060]-[p0066]段描述了用户触发频道切换：“If the user triggers a switch to a new channel, the mobile TV application signals the new channel to the channel switch control 2OC...” 以及用户发送RTSP SET_PARAMETER消息，例如“Channel: 2”，以告知服务器切换到频道“2”。 | 对比文件明确公开了用户（客户端）向服务器发送信道切换请求（如RTSP SET_PARAMETER消息），该请求指示了从当前正在接收/再现的第一信道（如“Channel One”）切换到待接收的第二信道（如“Channel Two”）。这直接对应于接收一个识别新信道（第二信道）而非当前信道的选择指示符。 |
| **技术特征B**：《隐含公开》<br>从所述装置的协议堆栈获得所述第二内容 | 对比文件[p0033]描述了RTP用于实时多媒体数据的传输，[p0078]-[p0096]描述了服务器将属于新信道的RTP包转发给客户端，客户端通过RTP处理（20K）接收数据流（如“Single ‘Mobile TV’ RTP Flow, 33”）。 | 目标专利中，“协议堆栈”是装置内接收和处理网络流（如实时内容）的模块。对比文件中，客户端通过RTP协议从服务器接收流媒体内容，这必然涉及客户端设备内的协议处理栈（如RTP/RTCP处理模块）来接收和解包数据。本领域技术人员可以毫无疑义地理解，为了接收服务器转发的“第二内容”（新信道的RTP包流），客户端装置需要从其协议栈（负责RTP等协议的处理）获得该内容数据。因此，该技术特征被隐含公开。 |
| **技术特征C**：未公开<br>通过确定所述第二内容是否具有与所述第一内容相同的内容格式来确定是否可使用所述第一再现路径再现所述第二内容 | 对比文件[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.” 这是服务器端在生成频道捆绑描述时的验证，以确保捆绑内所有频道使用相同的编解码器和比特率。 | 对比文件公开的是在服务建立前，服务器端（SDP聚合器）为了保证频道捆绑内的兼容性，会验证所有频道使用相同的编解码格式。然而，目标专利的技术特征C是发生在**装置（客户端）侧**的、在信道切换时的一个**动态决策过程**：装置需要确定新信道内容的格式是否与当前正在再现的内容格式相同，以判断是否可重用现有的第一再现路径。对比文件既未描述客户端侧进行此类格式比较的步骤，也未提及基于内容格式比较来决定是否重用现有再现路径（解码/播放路径）的逻辑。其服务器端的格式一致性验证是为了简化服务器端的流切换和RTP头重写，目的和场景均不同。因此，该特征未被对比文件公开。 |
| **技术特征D**：未公开<br>在确定可使用所述第一再现路径再现所述第二内容的情况下，将所述第二内容输入到所述第一再现路径中 | 对比文件[p0077]描述了服务器在确定切换点后，开始转发属于新频道的数据包：“Subsequently the channel selection unit continues to forward packets belonging to the current channel until the playback time has reached the identified switching point . From that point onwards, RTP packets belonging to the new channel are forwarded.” 客户端从同一RTP会话接收数据。 | 对比文件公开了服务器将新信道的数据包流通过同一个会话转发给客户端。然而，目标专利的特征D强调的是在**客户端装置内部**，在确定内容格式兼容（特征C）后，**主动将第二内容数据输入到现存的第一再现路径中**。对比文件仅描述了客户端接收一个统一的RTP流（服务器已切换源），但并未揭示客户端内部存在一个“再现路径”的判断与重用机制。客户端侧的媒体解码和播放（20L, 20M）虽然处理了数据，但对比文件没有描述这是一个需要被评估是否可重用的“现存路径”，也没有描述将新内容“输入”到该路径的决策和控制动作。该特征涉及客户端内部架构和逻辑，未被对比文件公开。 |
| **技术特征E**：《直接公开》<br>其中将所述第二内容输入到所述第一再现路径中包括发送激活消息和指示所述第二内容将被递送到相同的端点。 | 对比文件[p0054]描述：“In addition an ‘a=’ line with a fully specified RTSP control URL was added.” [p0059]描述客户端使用SDP文件中的RTSP URL来建立流会话。[p0062]-[p0066]描述了使用RTSP SET_PARAMETER消息进行频道切换，而RTSP会话本身（包括IP地址和端口）保持不变。 | 目标专利说明书[0057]段解释了“激活消息”和“相同的端点”是为了避免媒体播放器因检测到源（IP地址/端口）改变而重新初始化。对比文件公开了：1) 使用单个RTSP控制URL（即“端点”）来建立和控制整个频道捆绑的流会话（[p0054], [p0059]）；2) 频道切换时，客户端向服务器发送RTSP SET_PARAMETER消息（可视为一种激活或控制消息）请求切换（[p0062]-[p0066]）；3) 切换前后，客户端与服务器之间的RTP数据流继续通过同一个会话（即相同的IP地址和端口，由服务器重写RTP头使其连续，见[p0078]-[p0096]）进行传输。这实质上意味着第二内容（新频道数据）被递送到了相同的网络端点（客户端侧的同一套接字），从而避免了客户端播放器因源改变而重新初始化。因此，该技术特征被直接公开。 |
| **技术特征F**：《直接公开》<br>其中所述接收包括从装置用户接收所述信道选择指示符。 | 对比文件[p0060]段：“If the user triggers a switch to a new channel, the mobile TV application signals the new channel to the channel switch control 2OC...” | 对比文件明确说明了信道切换是由用户（user）触发（triggers）的。移动电视应用（mobile TV application）根据用户的操作向频道切换控制单元发送新频道信号。这直接公开了信道选择指示符来源于装置用户。 |
| **技术特征G**：未公开<br>其中所述第一再现路径包括源过滤器和变换过滤器中的至少一者。 | 目标专利说明书[0020]、[0025]段描述了再现路径包括源过滤器、变换过滤器等功能元件。对比文件中未提及“源过滤器”（source filter）或“变换过滤器”（transform filter）这类具体组件。 | 对比文件描述了客户端侧的“RTP processing”（20K）、“Media Decoding”（20L）和“Playback”（20M）功能模块（[p0038]）。这些模块共同完成了类似于目标专利中“再现路径”的功能（接收、解码、播放）。然而，对比文件并未将这些功能描述或划分为“源过滤器”和“变换过滤器”这样的具体组件。虽然实现类似功能可能需要相应的解码器，但“源过滤器”和“变换过滤器”是目标专利中对其再现路径内部结构的特定定义和划分。该具体结构特征未被对比文件公开。 |
| **技术特征H**：未公开<br>如果确定不可使用所述第一再现路径再现所述第二内容，那么执行以下操作：拆卸所述第一再现路径 | 无相应内容。对比文件假设频道捆绑内所有频道编码格式相同（[p0044]），因此未涉及因格式不同而需要拆卸客户端现有播放/解码路径（即“第一再现路径”）的场景。 | 目标专利的特征H是特征C的相反情况下的后续步骤。由于对比文件未公开客户端侧进行“是否可使用第一再现路径”的确定（特征C），因此自然也未曾提及在确定“不可使用”的情况下，需要“拆卸第一再现路径”这一客户端侧的动作。对比文件的方案设计前提是频道兼容，避免了这种情况的发生。因此，该特征未被公开。 |
| **技术特征I**：未公开<br>建构第二再现路径以再现所述第二内容。 | 无相应内容。对比文件未描述在客户端侧需要为不同格式的内容“建构”新的再现路径。 | 同特征H，该特征是特征C的相反情况下的另一后续步骤。由于对比文件未公开客户端侧基于内容格式判断来决定重用或新建再现路径的机制，因此也未提及在需要时“建构第二再现路径”这一客户端侧的动作。该特征未被公开。 |
<<<A>>><<<E>>><<<F>>><<<b>>>