对比文件名称：2009-08-06_US2009198827A_发明申请_US20090198827A1 METHOD AND APPARATUS FOR EXPEDITING DELIVERY OF PROGRAMMING CONTENT OVER A BROADBAND NETWORK
目标专利名称：倒回实时通信会话CN105103520B
本次调用的模型名称：DeepSeek最新版本模型
特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| 技术特征A：所述接收方设备在实时通信会话期间从传送方设备接收数据，《直接公开》 | 说明书第[0017]段：“In this environment, the client module typically must store a prescribed amount of media information in a buffer before it begins to play the media information to the user.”；第[0041]段：“The device 230 generally includes a front end 430 (e.g., a network interface such as an Ethernet interface) for interfacing with the IP or other broadband access network 210 of FIG. 1”。 图5流程：步骤505、515。 | 对比文件公开了客户端设备（client device 230，对应于接收方设备）在用户请求节目（如切换频道）后，从流服务器（streaming server 208，对应于传送方设备）接收节目内容数据流（如追赶流catch up stream和多播流multicast stream）。该数据接收发生在提供编程内容的会话期间。因此，技术特征A被直接公开。 |
| 技术特征B：所述方法包括：在所述接收方设备尝试接收来自所述传送方设备的实时媒体流的同时检测媒体接收间隙，《未公开》 | 说明书第[0017]段：“When changing channels in an IPTV environment using a multicast join request, there is generally a perceptible delay of up to several seconds between the time at which the channel is changed and the time when the content can be decoded and displayed by the client device.”；第[0044]段：“In step 505 the client device receives the user request. In step 510 the client device transmits the request to the streaming server in the headend...”。 | 对比文件公开的是用户主动发起频道切换请求（user request），客户端设备响应该请求并与流服务器交互以获取新频道内容。这个过程是用户主动触发的、有意的频道切换行为，目的是开始接收新内容。而目标专利的“检测媒体接收间隙”是指在尝试接收实时媒体流的过程中，由于网络降级、信号丢失等原因被动检测到的内容接收中断或不可用的状态。两者触发原因和场景本质不同：一个是有意切换，一个是被动检测故障。因此，对比文件未公开技术特征B。 |
| 技术特征C：响应于所述检测而向所述传送方设备传送倒回请求，所述倒回请求被配置成触发所述传送方设备生成和提供所述实时媒体流的包括在所述媒体接收间隙期间丢失的媒体的时间延迟版本，《未公开》 | 说明书第[0044]段：“In step 505 the client device receives the user request. In step 510 the client device transmits the request to the streaming server in the headend, which causes the streaming server to create a unicast catch up stream that commences with a key frame.” | 对比文件公开了客户端设备向流服务器传送“频道切换请求”（user request），该请求触发流服务器生成并传送“追赶流”（catch up stream）。虽然“追赶流”是相对于实时多播流有时间延迟的版本，但该请求的触发原因是用户主动切换频道，而非目标专利中所述的“响应于检测媒体接收间隙”。请求的目的和所解决问题的上下文不同。因此，对比文件未公开技术特征C。 |
| 技术特征D：响应于所述倒回请求而接收倒回流，其中所述倒回流被配置成由所述接收方设备独立于所述实时媒体流来播放。《隐含公开》 | 说明书第[0017]段：“The client device uses the unicast catch up stream until it catches up with the multicast stream...”；第[0044]段：步骤515：“the client device receives the catch up stream”；步骤525：“the client device begins decoding and presenting the content.” | 对比文件公开了客户端设备响应于其发送的频道请求，从流服务器接收“追赶流”（catch up stream）。该“追赶流”是一个独立的单播流，客户端设备可以对其解码和呈现（播放）。虽然对比文件主要描述该追赶流用于追赶多播流，但“接收”该流并能够“播放”该流的技术事实已被公开。该流是独立于实时多播流（对应于实时媒体流）的另一个流。因此，技术特征D被隐含公开。 |
| 技术特征E：其特征在于，进一步包括：在所述倒回流被接收的同时继续接收所述实时媒体流。《隐含公开》 | 说明书第[0044]段：步骤545：“the client device also begins to buffer the multicast stream as it continues to play the buffered catch up stream.” | 对比文件公开了在客户端设备播放已缓冲的追赶流的同时，开始缓冲多播流。要开始缓冲多播流，必然需要先“接收”多播流。这隐含公开了在接收（或播放）追赶流（对应于倒回流）的同时，继续接收多播流（对应于实时媒体流）。因此，技术特征E被隐含公开。 |
| 技术特征F：其特征在于，在响应于所述倒回请求而接收所述倒回流的同时所述实时媒体流的接收停止。《未公开》 | 无相应内容。 | 对比文件未描述在接收追赶流（catch up stream）的同时，停止接收多播流（multicast stream）。相反，其流程是在接收追赶流后，加入并开始接收多播流（步骤535、545）。没有公开停止接收实时媒体流的情形。因此，技术特征F未被公开。 |
| 技术特征G：其特征在于，所述倒回请求对应于隐式倒回请求，所述隐式倒回请求传达被配置用于由所述传送方设备评估的信息以准许所述传送方设备独立地触发所述倒回流的生成和递送。《未公开》 | 无相应内容。 | 对比文件中客户端设备发送的“频道切换请求”（user request）是显式的用户指令，目的是请求新的频道内容。说明书未描述任何“隐式”的请求，也未描述传送用于让流服务器独立评估以决定触发生成追赶流的信息。因此，技术特征G未被公开。 |
| 技术特征H：其特征在于，所传达的信息与所述媒体接收间隙相关。《未公开》 | 无相应内容。 | 由于对比文件未公开“隐式倒回请求”（特征G），自然也未曾开所传达的信息与“媒体接收间隙”相关。因此，技术特征H未被公开。 |
| 技术特征I：其特征在于，所述倒回请求对应于显式倒回请求，所述显式倒回请求显式地请求所述传送方设备提供所述实时媒体流的所述时间延迟版本。《隐含公开》 | 说明书第[0044]段：“In step 505 the client device receives the user request. In step 510 the client device transmits the request to the streaming server in the headend, which causes the streaming server to create a unicast catch up stream...” | 对比文件公开的“频道切换请求”（user request）是客户端设备明确发送给流服务器的请求。该请求直接导致流服务器创建并发送“追赶流”（catch up stream），而追赶流正是相对于实时多播流（实时媒体流）有时间延迟的版本（起始于关键帧，加速播放以追赶）。虽然该请求的表述是“请求节目”或“频道改变”，但其技术效果是触发服务器提供时间延迟版本（追赶流）。因此，技术特征I被隐含公开。 |
| 技术特征J：其特征在于，所述显式倒回请求请求所述传送方设备以相对于所述实时媒体流的第一延迟量提供所述实时媒体流的所述时间延迟版本，所述倒回流包括相对于所述实时媒体流的第二延迟量，所述第二延迟量不同于所述第一延迟量。《未公开》 | 无相应内容。 | 对比文件未描述客户端设备在请求中指定一个期望的延迟量（第一延迟量）。追赶流的延迟量（第二延迟量）是由流服务器根据关键帧间隔、追赶比率等因素计算决定的（见[0023]段）。没有公开请求的延迟量与最终提供的延迟量不同的情形。因此，技术特征J未被公开。 |
| 技术特征K：其特征在于，所述接收方设备对应于正参与所述实时通信会话的目标用户装备(UE)，并且所述目标UE播放所述倒回流，或者所述接收方设备对应于正仲裁和/或裁夺所述实时通信会话的服务器，并且所述服务器向参与所述实时通信会话的至少一个目标UE传送所述倒回流。《直接公开》 | 说明书第[0001]段：“...streaming programming content to a client device...”；第[0041]段：“FIG. 4 shows one example of a client device 230, which may be, for example, a set top box.”；第[0044]段：步骤525：“the client device begins decoding and presenting the content.”；第[0012]段：“headend 220 may include a streaming server 208 for broadcasting/multicasting/unicasting the programming content...”。 | 对比文件明确公开了两种情形：1) 客户端设备（client device 230，如机顶盒，对应于目标UE）接收并解码呈现（即播放）追赶流（catch up stream，对应于倒回流）。2) 头端（headend 220）中的流服务器（streaming server 208，对应于仲裁/裁夺内容分发的服务器）生成并向客户端设备传送追赶流。这与技术特征K描述的两种设备角色及其行为完全一致。因此，技术特征K被直接公开。 |
| 技术特征L：其特征在于，所述媒体接收间隙对应于(i)其中少于阈值数目的用于所述实时媒体流的可用媒体分组成功抵达所述接收方设备的第一时间间隙，或者(ii)其中所述阈值数目的用于所述实时媒体流的可用媒体分组可用、但所述接收方设备处的条件抑制由所述接收方设备进行的回放的第二时间间隙。《未公开》 | 无相应内容。 | 对比文件未定义或检测“媒体接收间隙”。其触发事件是用户主动的频道切换请求，而非检测分组成功抵达数目是否低于阈值，也非检测设备条件抑制回放。因此，技术特征L未被公开。 |
| 技术特征M：其特征在于，所述媒体接收间隙基于网络连接降级而发生。《未公开》 | 无相应内容。 | 对比文件未将频道切换或内容获取延迟归因于“网络连接降级”。其描述的延迟主要源于加入多播组和等待关键帧的固有过程（[0017]段）。因此，技术特征M未被公开。 |
| 技术特征N：其特征在于，所述网络连接降级发生在服务网络与接收方设备之间的连接上和/或回程连接上。《未公开》 | 无相应内容。 | 由于特征M未被公开，特征N的具体位置也无从谈起。对比文件未提及此类网络连接降级。因此，技术特征N未被公开。 |
| 技术特征O：其特征在于，进一步包括：执行关于所述倒回流的追赶协议，以使得所述倒回流将追赶上所述实时媒体流。《直接公开》 | 说明书第[0017]段：“The short-lived transport stream, also referred to herein as a catch up stream, is unicast to the client device. The client device uses the unicast catch up stream until it catches up with the multicast stream...”；第[0023]段：“If the catch up stream is transmitted at the target bit rate Rt instead of the catch up bit rate Rc, the catch up ratio can be used... to determine how long the unicast catch up stream needs to operate before it reaches temporal synchronization with the multicast stream.” | 对比文件明确公开了“追赶流”（catch up stream）以快于实时的速率（a rate faster than real time， [0044]段）传输，其目的就是让客户端设备使用该流直到其“赶上”（catches up with）多播流（即实时媒体流）。这本身就是一种“追赶协议”的执行。因此，技术特征O被直接公开。 |
| 技术特征P：其特征在于，所述实时通信会话是半双工会话并且所述接收方设备是在所述倒回流被接收的同时作为非发言权持有者参与所述实时通信会话的目标用户装备(UE)，所述方法进一步包括：在所述接收方设备正接收所述倒回流的同时请求所述实时通信会话的发言权。《未公开》 | 无相应内容。 | 对比文件涉及的是电视节目内容的分发（IPTV），是单向的广播/多播场景，不存在“半双工会话”、“发言权持有者”的概念。因此，技术特征P未被公开。 |
| 技术特征Q：响应于所述发言权请求而接收发言权被准予给所述接收方设备的指示。《未公开》 | 无相应内容。 | 同特征P，对比文件不涉及发言权管理。因此，技术特征Q未被公开。 |
| 技术特征R：在所述指示被接收到之后继续接收和播放所述倒回流直至(i)所述倒回流追赶上所述发言权被准予给所述接收方设备的时间，和/或(ii)所述接收方设备确定要退出倒回模式。《未公开》 | 无相应内容。 | 同特征P、Q，对比文件不涉及发言权管理及在此场景下的倒回播放控制。因此，技术特征R未被公开。 |
| 技术特征S：在(i)或(ii)之后作为发言权持有者开始传送用于所述实时通信会话的媒体。《未公开》 | 无相应内容。 | 同特征P、Q、R，对比文件不涉及半双工会话及发言权持有者传送媒体。因此，技术特征S未被公开。 |
| 技术特征T：其特征在于，进一步包括：监视与所述实时媒体流和/或所述倒回流相关联的一个或多个性能度量。《未公开》 | 无相应内容。 | 对比文件未描述客户端设备或服务器监视与数据流（如多播流或追赶流）相关的性能度量（如分组差错率）。因此，技术特征T未被公开。 |
| 技术特征U：向所述实时媒体流和/或所述倒回流的始发者报告所述一个或多个性能度量。《未公开》 | 无相应内容。 | 由于特征T（监视性能度量）未被公开，特征U（报告性能度量）自然也未被公开。因此，技术特征U未被公开。 |
| 技术特征V：其特征在于，所述一个或多个性能度量包括所述实时媒体流和/或所述倒回流的分组差错率(PER)。《未公开》 | 无相应内容。 | 同特征T、U，对比文件未提及分组差错率（PER）或其他具体性能度量。因此，技术特征V未被公开。 |
<<<A>>><<<K>>><<<O>>>
<<<d>>><<<e>>><<<i>>>