**对比文件名称**：2009-06-11_US2009150715A_发明申请_US20090150715A1 DELIVERY OF STREAMS TO REPAIR ERRORED MEDIA STREAMS IN PERIODS OF INSUFFICIENT RESOURCES
**目标专利名称**：317倒回实时通信会话CN105103520B
**本次调用模型名称**：DeepSeek-R1
---
### **特征比对表格**
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：所述接收方设备在实时通信会话期间从传送方设备接收数据，<br>**判断结果**：未公开 | [0019] “DHCT 130 stores at least at a portion of the received program in storage 150, for retrieval and/or playback.” | **未公开**。目标专利中的“实时通信会话”（如说明书[0008]所述电话呼叫）指双向、交互式的实时媒体交换（如语音通话）。对比文件中的“program stream”（如[0020]所述广播电视频道）是单向广播或点播的媒体流，DHCT（客户端）是被动接收者，不参与双向“会话”。两者技术领域和作用不同：目标专利用于维持实时双向通信的连续性，对比文件用于确保单向媒体内容的完整交付。因此，对比文件未公开“在实时通信会话期间从传送方设备接收数据”这一技术特征。 |
| **技术特征B**：所述方法包括：在所述接收方设备尝试接收来自所述传送方设备的实时媒体流的同时检测媒体接收间隙<br>**判断结果**：《隐含公开》<<<b>>> | [0024] “DHCT 130 examines the packets and tracks missing programs segments within the last time window (e.g., 1 minute).” <br>[0041] “DHCT 130 determines (610) that packets 520-540 are missing (e.g., from a timeout), then detects (620) a subscriber link error.” | **隐含公开**。目标专利的“检测媒体接收间隙”（如说明书[0070]所述）指在接收实时媒体流时识别出媒体分组丢失或不可用的时段。对比文件中，DHCT会“检查分组并跟踪缺失的节目段”（[0024]），以及“确定分组缺失…检测用户链路错误”（[0041]），这实质是在接收媒体流的同时检测媒体接收问题或间隙。虽然对比文件未使用“媒体接收间隙”这一术语，但本领域技术人员根据其描述（跟踪缺失段、检测链路错误）能够合理推断出DHCT具备检测媒体接收出现问题的能力，即隐含公开了“检测媒体接收间隙”这一技术特征。 |
| **技术特征C**：响应于所述检测而向所述传送方设备传送倒回请求，所述倒回请求被配置成触发所述传送方设备生成和提供所述实时媒体流的包括在所述媒体接收间隙期间丢失的媒体的时间延迟版本<br>**判断结果**：未公开 | [0024] “When the threshold is reached..., DHCT 130 notifies error repair delivery component 120 through a first error report 410...” <br>[0047] “DHCT 130 notifies error repair delivery component 120 of missing packets 520-540 through an error report 635.” | **未公开**。目标专利的“倒回请求”核心在于请求“实时媒体流的**时间延迟版本**”，其目的是让接收方能“倒回”并听到/看到过去错过的内容，同时可能希望追赶实时会话（参见说明书[0073], [0093]）。对比文件的“错误通知/报告”（error report）仅用于报告错误或丢失的数据段，其触发的是“修复流”（repair stream）的传送。该修复流是补发丢失的原始内容，而非目标专利所强调的、相对于实时流具有特定延迟的“时间延迟版本”。两者触发目的和产生的流性质不同：目标专利旨在创建时间偏移的并行流以实现会话倒回与追赶；对比文件旨在补发丢失数据以修复原始流。因此，对比文件未公开“配置成触发生成和提供实时媒体流的时间延迟版本”的倒回请求。 |
| **技术特征D**：响应于所述倒回请求而接收倒回流，其中所述倒回流被配置成由所述接收方设备独立于所述实时媒体流来播放。<br>**判断结果**：《隐含公开》<<<d>>> | [0023] “error repair delivery component 120 uses program stream 135 in storage 170 to provide the affected content to DHCT 130 as segmented repair stream 175...” <br>[0024] “DHCT 130 stores received segmented repair stream 175 in storage 150. Repair logic 190 within DHCT 130 combines content within segmented repair stream 175 with content within program stream 135 to produce a corrected program...” | **隐含公开**。目标专利的“倒回流”是时间延迟的实时媒体流版本，可独立播放（说明书[0072]）。对比文件中，DHCT接收“分段修复流”（segmented repair stream 175），该流包含出错或丢失的媒体内容。DHCT将修复流与原始流结合以产生校正后的节目（[0024]）。这意味着修复流是一个独立的数据流，DHCT可以存储并处理它。虽然对比文件未明确说明修复流被“配置成独立于实时媒体流播放”，但根据其工作方式（接收、存储、后续合并），本领域技术人员能够合理推断出修复流可以被独立处理，即隐含公开了“接收被配置成可由接收方设备独立于实时媒体流播放的流”这一技术特征。 |
| **技术特征E**：其特征在于，进一步包括：在所述倒回流被接收的同时继续接收所述实时媒体流。<br>**判断结果**：未公开 | （未明确描述在接收修复流的同时是否继续接收原始流。图7显示了多播修复流，但未说明单个DHCT的接收行为。） | **未公开**。目标专利明确给出了两种操作模式：在接收倒回流的同时，可以继续接收实时媒体流（特征E），也可以停止接收实时媒体流（特征F）。对比文件未明确教导或暗示DHCT在接收“分段修复流”的同时，其对于原始“节目流”的接收状态。说明书描述了修复流用于补全或替换错误部分，但未涉及两个流是否并发接收的调度策略。本领域技术人员无法从对比文件中毫无疑义地得出或合理推断出“在接收修复流的同时继续接收原始实时媒体流”这一具体技术方案。 |
| **技术特征F**：其特征在于，在响应于所述倒回请求而接收所述倒回流的同时所述实时媒体流的接收停止。<br>**判断结果**：未公开 | （同上） | **未公开**。理由同技术特征E。对比文件未描述在接收修复流时，原始节目流的接收是否停止。缺乏相关教导或启示。 |
| **技术特征G**：其特征在于，所述倒回请求对应于隐式倒回请求，所述隐式倒回请求传达被配置用于由所述传送方设备评估的信息以准许所述传送方设备独立地触发所述倒回流的生成和递送。<br>**判断结果**：《直接公开》<<<G>>> | [0024] “DHCT 130 notifies error repair delivery component 120 through a first error report 410, containing a stream state 410S and a reason code 410R.” <br>[0031] “In some embodiments, error repair delivery component 120 learns or configures... bandwidth and transmits at a guaranteed rate...” <br>[0032] “In some embodiments, segmented repair stream 175 is generated once a threshold number of errored or missing packets have been reported, and is transmitted to the reporting DHCT 130 upon generation.” | **直接公开**。目标专利的“隐式倒回请求”指传达信息（如性能度量、间隙信息）供传送方评估并独立决定触发倒回（说明书[0088]-[0089]、[0120]）。对比文件中，DHCT向错误修复组件发送“错误报告”（error report），其中包含流状态、原因码等信息（[0024]）。错误修复组件基于这些报告信息（如达到阈值、资源可用性等）独立决定何时生成并发送修复流（[0031], [0032]）。这完全符合“隐式请求”的定义：客户端传达状态信息，服务器端评估该信息并独立触发修复流的生成和递送。因此，该技术特征被对比文件直接公开。 |
| **技术特征H**：其特征在于，所传达的信息与所述媒体接收间隙相关。<br>**判断结果**：《直接公开》<<<H>>> | [0024] “stream state 410S indicates current condition and stream position... the reason code 410R indicates packet errors.” <br>[0047] “Error report 635 contains a missing packets list 635L and a reason code 635R. In this example scenario, the reason code indicates a subscriber link error.” | **直接公开**。目标专利中隐式倒回请求所传达的信息与媒体接收间隙相关（说明书[0089]）。对比文件的错误报告中所包含的“流状态”、“原因码”（如分组错误、用户链路错误）以及“缺失分组列表”，正是与媒体接收出现问题（即间隙）直接相关的信息。因此，该技术特征被对比文件直接公开。 |
| **技术特征I**：其特征在于，所述倒回请求对应于显式倒回请求，所述显式倒回请求显式地请求所述传送方设备提供所述实时媒体流的所述时间延迟版本。<br>**判断结果**：未公开 | （对比文件中DHCT发送的是“错误通知/报告”，其内容是报告错误或丢失，并非明确请求一个“时间延迟版本”的流。） | **未公开**。目标专利的“显式倒回请求”明确要求传送方提供实时媒体流的“时间延迟版本”（说明书[0090]）。对比文件中DHCT发送的“错误报告”仅用于通知错误或丢失的发生，其语义是“报告问题”，而非“请求一个具有特定时间延迟属性的流”。本领域技术人员无法从“错误报告”中毫无疑义地得出或合理推断出其中包含了“显式请求提供实时媒体流的时间延迟版本”这一技术特征。 |
| **技术特征J**：其特征在于，所述显式倒回请求请求所述传送方设备以相对于所述实时媒体流的第一延迟量提供所述实时媒体流的所述时间延迟版本，所述倒回流包括相对于所述实时媒体流的第二延迟量，所述第二延迟量不同于所述第一延迟量。<br>**判断结果**：未公开 | （对比文件未描述DHCT在请求中指定延迟量，也未描述错误修复组件提供的修复流具有与请求不同的延迟量。） | **未公开**。该特征涉及显式请求中指定延迟量，且实际提供的延迟量可能不同。对比文件既未公开客户端请求特定延迟量（第一延迟量），也未公开服务器提供的修复流具有一个可能不同的、相对于实时流的延迟量（第二延迟量）。对比文件的修复流内容由错误报告确定的丢失段决定，其“延迟”是内容补发的自然结果，并非一个可独立于丢失内容指定的“延迟量”参数。因此，该技术特征未被公开。 |
| **技术特征K**：其特征在于，所述接收方设备对应于正参与所述实时通信会话的目标用户装备(UE)，并且所述目标UE播放所述倒回流，或者所述接收方设备对应于正仲裁和/或裁夺所述实时通信会话的服务器，并且所述服务器向参与所述实时通信会话的至少一个目标UE传送所述倒回流。<br>**判断结果**：未公开 | [0019] “DHCT 130... eventually consumed by a subscriber.” （接收方为客户端设备）<br>[0049] “error repair delivery component 120 generates an appropriate segmented repair stream 175 and multicasts this single segmented repair stream 175 to the group of DHCTs 130.” （发送方为服务器，向多个客户端多播） | **未公开**。目标专利中接收方设备有两种可能：1) 作为参与会话的UE，自身播放倒回流；2) 作为仲裁服务器，接收倒回流并转发给其他目标UE（说明书[0094]）。对比文件中，接收修复流的是客户端设备（DHCT），它自身消费内容，符合第一种情况的部分（DHCT播放内容）。但是，对比文件完全没有公开第二种情况：即一个作为“接收方设备”的服务器，从“传送方设备”接收修复流，然后再将该修复流传送给其他目标客户端。在图7的多播示例中，错误修复组件是“发送方”，而非“接收方”。因此，对比文件仅部分涉及第一种情况，但未公开第二种情况，且整体上未公开目标专利权利要求中限定的两种可选架构。 |
| **技术特征L**：其特征在于，所述媒体接收间隙对应于(i)其中少于阈值数目的用于所述实时媒体流的可用媒体分组成功抵达所述接收方设备的第一时间间隙，或者(ii)其中所述阈值数目的用于所述实时媒体流的可用媒体分组可用、但所述接收方设备处的条件抑制由所述接收方设备进行的回放的第二时间间隙。<br>**判断结果**：部分《隐含公开》<<<l>>> | [0024] “DHCT 130 examines the packets and tracks missing programs segments... When the threshold is reached (here, with receipt of packet 340), DHCT 130 notifies...” （对应于情况i）<br>（未描述情况ii） | **部分隐含公开（仅情况i）**。目标专利定义了两种媒体接收间隙。情况(i)与对比文件公开内容相符：DHCT检查分组并跟踪缺失段，当达到阈值时报告（[0024]），这隐含了“少于阈值数目的可用媒体分组成功抵达”的间隙。对于情况(ii)，即“条件抑制回放”（如用户环境嘈杂，说明书[0086]），对比文件完全没有涉及。因此，对比文件隐含公开了技术特征L中情况(i)的内容，但未公开情况(ii)。 |
| **技术特征M**：其特征在于，所述媒体接收间隙基于网络连接降级而发生。<br>**判断结果**：《直接公开》<<<M>>> | [0024] “Missing or errored content may be a result of a variety of conditions. Some instances... are caused by conditions on the backbone or access network, such as network congestion, or outages...” | **直接公开**。目标专利说明媒体接收间隙可基于网络连接降级发生（说明书[0097]）。对比文件明确列举了缺失或出错内容的原因包括“骨干网或接入网络上的状况，例如网络拥塞或中断”（[0024]），这直接对应于“网络连接降级”。因此，该技术特征被直接公开。 |
| **技术特征N**：其特征在于，所述网络连接降级发生在服务网络与接收方设备之间的连接上和/或回程连接上。<br>**判断结果**：《直接公开》<<<N>>> | [0024] “...conditions on the backbone or access network...” <br>[0024] “Other instances... are caused by conditions at the subscriber location, such as congestion on the subscriber link, outage on the subscriber link...” | **直接公开**。目标专利具体化了网络连接降级的位置（服务网络与设备间连接、回程连接）。对比文件明确提到了“骨干网或接入网络”（对应回程及服务网络连接）以及“用户链路上的拥塞或中断”（对应服务网络与接收设备之间的连接）。因此，该技术特征被对比文件直接公开。 |
| **技术特征O**：其特征在于，进一步包括：执行关于所述倒回流的追赶协议，以使得所述倒回流将追赶上所述实时媒体流。<br>**判断结果**：未公开 | （对比文件未描述任何对修复流进行加速播放、跳帧或转换文本等以追赶实时流的协议。） | **未公开**。目标专利的“追赶协议”（如快进、跳帧、音频字幕等，说明书[0093]）是倒回功能的重要组成部分，旨在使接收方能尽快重新加入实时会话。对比文件仅描述了修复流的传送、存储和合并，以实现内容的完整修复，但完全没有涉及任何旨在“追赶”实时流的加速或处理协议。本领域技术人员无法从对比文件中得出或推断出该技术特征。 |
| **技术特征P**：其特征在于，所述实时通信会话是半双工会话并且所述接收方设备是在所述倒回流被接收的同时作为非发言权持有者参与所述实时通信会话的目标用户装备(UE)，所述方法进一步包括：在所述接收方设备正接收所述倒回流的同时请求所述实时通信会话的发言权<br>**判断结果**：未公开 | （对比文件涉及单向媒体广播，不存在“半双工会话”、“发言权持有者”的概念。DHCT不会向流源请求“发言权”以发送媒体。） | **未公开**。该组特征（P-S）涉及实时双向通信（尤其是半双工）场景下的发言权控制机制，是目标专利特有的应用场景（参见说明书[0110]-[0118]）。对比文件是纯粹的单向内容分发系统（如电视广播），DHCT是接收终端，不存在“发言权”的概念，更不存在在接收修复流的同时请求发言权并开始向流源发送媒体的操作。因此，该组技术特征完全未被对比文件公开。 |
| **技术特征Q**：响应于所述发言权请求而接收发言权被准予给所述接收方设备的指示<br>**判断结果**：未公开 | （同上） | **未公开**。理由同技术特征P。 |
| **技术特征R**：在所述指示被接收到之后继续接收和播放所述倒回流直至(i)所述倒回流追赶上所述发言权被准予给所述接收方设备的时间，和/或(ii)所述接收方设备确定要退出倒回模式<br>**判断结果**：未公开 | （同上） | **未公开**。理由同技术特征P。 |
| **技术特征S**：在(i)或(ii)之后作为发言权持有者开始传送用于所述实时通信会话的媒体。<br>**判断结果**：未公开 | （同上） | **未公开**。理由同技术特征P。 |
| **技术特征T**：其特征在于，进一步包括：监视与所述实时媒体流和/或所述倒回流相关联的一个或多个性能度量<br>**判断结果**：《直接公开》<<<T>>> | [0024] “DHCT 130 examines the packets and tracks missing programs segments...” <br>[0041] “DHCT 130 determines (610) that packets 520-540 are missing (e.g., from a timeout)...” | **直接公开**。目标专利的“监视性能度量”（说明书[0120]）包括分组差错率等。对比文件中，DHCT“检查分组并跟踪缺失节目段”（[0024]）、“确定分组缺失”（[0041]），这些行为本身就是对媒体流性能（如分组丢失）的监视。因此，该技术特征被直接公开。 |
| **技术特征U**：向所述实时媒体流和/或所述倒回流的始发者报告所述一个或多个性能度量。<br>**判断结果**：《直接公开》<<<U>>> | [0024] “DHCT 130 notifies error repair delivery component 120 through a first error report 410...” <br>[0047] “DHCT 130 notifies error repair delivery component 120 of missing packets 520-540 through an error report 635.” | **直接公开**。目标专利中，性能度量被报告给流的始发者（说明书[0120]）。对比文件中，DHCT将错误信息（即一种性能度量）通过“错误报告”通知给错误修复组件，而错误修复组件可被视为修复流的始发者，在上下文中也与原始流的分发相关。因此，该技术特征被直接公开。 |
| **技术特征V**：其特征在于，所述一个或多个性能度量包括所述实时媒体流和/或所述倒回流的分组差错率(PER)。<br>**判断结果**：《直接公开》<<<V>>> | [0024] “the reason code 410R indicates packet errors.” <br>[0024] “DHCT 130 examines the packets and tracks missing programs segments...” | **直接公开**。目标专利明确列举了“分组差错率(PER)”作为性能度量。对比文件的错误报告中包含指示“分组错误”的原因码（[0024]），并且DHCT通过检查分组和跟踪缺失段来评估流的质量，这直接对应于对分组差错情况的度量。因此，该技术特征被直接公开。 |
<<<G>>><<<H>>><<<M>>><<<N>>><<<T>>><<<U>>><<<V>>><<<b>>><<<d>>><<<l>>>