**对比文件名称**：2012-11-01_US2012278845A_发明申请_US20120278845A1 METHOD AND DEVICE FOR ENSURING QUALITY OF SERVICE OF INTERNET PROTOCOL TELEVISION LIVE BROADCAST SERVICE
**目标专利名称**：317倒回实时通信会话CN105103520B
**本次调用的模型名称**：专利创造性评估模型
### 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：所述接收方设备在实时通信会话期间从传送方设备接收数据。<br>**《直接公开》** | [0033] “...detecting a live broadcast packet received from an original multicast group...”<br>（……检测从原始多播组接收的直播分组……）<br>[0073] “...after the terminal receives the multicast packet of an original multicast group, the terminal normally decodes the multicast packet and outputs the multicast packet.”<br>（……在终端接收到来自原始多播组的多播分组后，终端正常解码并输出该多播分组。） | 对比文件公开了终端（接收方设备）在IPTV直播服务（一种实时通信会话）期间，从原始多播组（可对应于传送方设备，如头端或重传服务器）接收直播分组数据。该技术特征被直接公开。 |
| **技术特征B**：所述方法包括：在所述接收方设备尝试接收来自所述传送方设备的实时媒体流的同时检测媒体接收间隙。<br>**《直接公开》** | [0033] “...detecting a live broadcast packet received from an original multicast group; if detecting that the live broadcast packet has an error or a loss...”<br>（……检测从原始多播组接收的直播分组；如果检测到该直播分组有错误或丢失……）<br>[0073] “If the terminal detects that the multicast packet received from the original multicast group has an error or a loss...”<br>（如果终端检测到从原始多播组接收的多播分组有错误或丢失……） | 对比文件明确描述了终端在接收原始多播流（实时媒体流）的同时，检测分组是否有错误或丢失。分组错误或丢失即构成媒体接收间隙。该技术特征被直接公开。 |
| **技术特征C**：响应于所述检测而向所述传送方设备传送倒回请求，所述倒回请求被配置成触发所述传送方设备生成和提供所述实时媒体流的包括在所述媒体接收间隙期间丢失的媒体的时间延迟版本。<br>**《隐含公开》** | [0033] “if detecting that the live broadcast packet has an error or a loss, joining a multicast group corresponding to a delay multicast stream sent by a retransmission server...”<br>（如果检测到直播分组有错误或丢失，则加入与重传服务器发送的延迟多播流相对应的多播组……）<br>[0076] “...the terminal may directly request the retransmission server to retransmit the packet.”<br>（……终端可以直接请求重传服务器重传该分组。） | 对比文件公开了两种响应方式：1) 检测到分组丢失后，终端直接加入重传服务器已预先创建并发送的延迟多播流。该延迟多播流是原始多播流的时间延迟版本，包含了丢失的媒体。终端加入该组的动作，可被本领域技术人员理解为一种隐式的“请求”，其触发了服务器向该终端提供（即允许其接收）该延迟流。2) 若延迟流中仍无法恢复，终端直接向重传服务器发送重传请求（Nack消息），这是一种显式请求。这两种方式均是为了获得丢失媒体的时间延迟版本。因此，该技术特征被对比文件隐含公开。 |
| **技术特征D**：响应于所述倒回请求而接收倒回流，其中所述倒回流被配置成由所述接收方设备独立于所述实时媒体流来播放。<br>**《直接公开》** | [0033] “...receiving a delay retransmission packet from the delay multicast stream...”<br>（……从延迟多播流接收延迟重传分组……）<br>[0073] “...the terminal directly discards the packet correctly received from the original multicast stream, and after finding a packet, which is required to be recovered, from the delay multicast stream...”<br>（……终端直接丢弃从原始多播流正确接收的分组，并在从延迟多播流中找到需要恢复的分组后……） | 对比文件明确说明了终端在加入延迟多播组后，从延迟多播流接收延迟重传分组（倒回流）。并且，终端从原始流和延迟流接收分组是独立的，例如会丢弃正确原始分组而从延迟流中恢复丢失分组。这体现了倒回流可独立于实时媒体流被处理（播放/恢复）。该技术特征被直接公开。 |
| **技术特征E**：其特征在于，进一步包括：在所述倒回流被接收的同时继续接收所述实时媒体流。<br>**《未直接或隐含公开》** | [0073] “...the terminal directly discards the packet correctly received from the original multicast stream...”<br>（……终端直接丢弃从原始多播流正确接收的分组……） | 对比文件描述了终端在加入延迟多播流后，对于从原始流正确接收的分组是“直接丢弃”的，其处理逻辑是从延迟流中寻找并恢复丢失分组，而非同时播放两个独立的流。目标专利中“继续接收实时媒体流”强调的是两个流并行存在并可被处理。对比文件的技术方案旨在用延迟流补充和替代原始流中丢失的部分，以实现无缝恢复，未教导或暗示需要同时维持两个独立可播放的流。因此，该技术特征未被公开。 |
| **技术特征F**：其特征在于，在响应于所述倒回请求而接收所述倒回流的同时所述实时媒体流的接收停止。<br>**《未直接或隐含公开》** | [0073] “...after finding a packet, which is required to be recovered, from the delay multicast stream, the terminal withdraws from the multicast group, merely reserves the original multicast group and continuously receives the packet from the original multicast group.”<br>（……在从延迟多播流中找到需要恢复的分组后，终端退出该多播组，仅保留原始多播组并持续从原始多播组接收分组。） | 对比文件说明终端在从延迟流中找到恢复所需分组后，会退出延迟组并继续接收原始流。在接收延迟流期间，并未明确描述原始流的接收被停止。相反，其描述“直接丢弃正确接收的原始分组”暗示原始流仍在被接收（尽管分组被丢弃）。因此，对比文件没有公开在接收倒回流的同时停止接收实时媒体流。该技术特征未被公开。 |
| **技术特征G**：其特征在于，所述倒回请求对应于隐式倒回请求，所述隐式倒回请求传达被配置用于由所述传送方设备评估的信息以准许所述传送方设备独立地触发所述倒回流的生成和递送。<br>**《隐含公开》** | [0076]-[0079] “...the terminal may feed back it to the retransmission server through an extended Real-time Control Protocol (RTCP) message... The extended RTCP message needs to indicate a detection delay and a multicast joining delay of a current terminal...”<br>（……终端可以通过扩展的实时控制协议（RTCP）消息将其反馈给重传服务器……扩展的RTCP消息需要指示当前终端的检测延迟和多播加入延迟……）<br>[0080] “...so that the retransmission server calculates the transmission delay... can estimate the length of the delay... so that the delay of the retransmission stream can be adjusted, or a new retransmission stream is added according to the requirements.”<br>（……以便重传服务器计算传输延迟……可以估计延迟的长度……从而可以调整重传流的延迟，或者根据需求添加新的重传流。） | 对比文件公开了终端可以向重传服务器（传送方设备）发送扩展的RTCP消息，该消息包含检测延迟、加入延迟等信息。重传服务器根据这些反馈信息，可以独立地决定是否调整现有延迟流的延迟或添加新的延迟流（即生成和递送不同参数的时间延迟版本）。这种反馈信息并非直接请求特定倒回流，而是提供了供服务器评估和决策的数据，符合“隐式倒回请求”的定义。因此，该技术特征被隐含公开。 |
| **技术特征H**：其特征在于，所传达的信息与所述媒体接收间隙相关。<br>**《隐含公开》** | [0079] 扩展RTCP消息包含“Detection delay of the terminal (32 bits, ms)”。<br>（终端的检测延迟（32位，毫秒）） | 对比文件中终端通过RTCP消息反馈的“检测延迟”信息，直接源于终端检测分组错误或丢失（即媒体接收间隙）这一事件及其处理耗时。因此，所传达的信息与媒体接收间隙直接相关。该技术特征被隐含公开。 |
| **技术特征I**：其特征在于，所述倒回请求对应于显式倒回请求，所述显式倒回请求显式地请求所述传送方设备提供所述实时媒体流的所述时间延迟版本。<br>**《隐含公开》** | [0033] “...if detecting that the live broadcast packet has an error or a loss, joining a multicast group corresponding to a delay multicast stream...”<br>（……如果检测到直播分组有错误或丢失，加入与延迟多播流相对应的多播组……）<br>[0076] “...the terminal may directly request the retransmission server to retransmit the packet.”<br>（……终端可以直接请求重传服务器重传该分组。） | 对比文件公开了两种行为：1）终端通过加入特定延迟多播组的动作，显式地表达了接收该时间延迟版本流的意图。虽然加入组是网络层操作，但其目的明确，即获取延迟的媒体流以恢复丢失内容。2）终端直接发送重传请求（Nack），这是更明确的显式请求。这两种方式均可被本领域技术人员理解为显式地请求提供时间延迟版本（延迟多播流或其部分）。因此，该技术特征被隐含公开。 |
| **技术特征J**：其特征在于，所述显式倒回请求请求所述传送方设备以相对于所述实时媒体流的第一延迟量提供所述实时媒体流的所述时间延迟版本，所述倒回流包括相对于所述实时媒体流的第二延迟量，所述第二延迟量不同于所述第一延迟量。<br>**《未直接或隐含公开》** | [0070] “...the terminal may select an appropriate multicast group according to a network transmission delay, a delay in detecting that the packet has a loss or an error, and a delay in joining the multicast group, and join the appropriate multicast group.”<br>（……终端可以根据网络传输延迟、检测分组丢失或错误的延迟以及加入多播组的延迟，选择合适的多播组并加入。） | 对比文件描述了终端从服务器提供的多个具有固定延迟量的延迟流中选择一个来加入。终端的选择是基于自身计算，但并未描述终端向服务器“请求”一个特定的、与服务器实际提供的延迟量（第二延迟量）不同的延迟量（第一延迟量）。终端只是从现有选项中选取，服务器提供的延迟量是预设的。因此，该技术特征未被公开。 |
| **技术特征K**：其特征在于，所述接收方设备对应于正参与所述实时通信会话的目标用户装备(UE)，并且所述目标UE播放所述倒回流，或者所述接收方设备对应于正仲裁和/或裁夺所述实时通信会话的服务器，并且所述服务器向参与所述实时通信会话的至少一个目标UE传送所述倒回流。<br>**《直接公开》** | [0033] “...detecting a live broadcast packet received from an original multicast group... joining a multicast group corresponding to a delay multicast stream sent by a retransmission server...”<br>（……检测从原始多播组接收的直播分组……加入与重传服务器发送的延迟多播流相对应的多播组……）<br>[0048] “...the retransmission server retransmits the buffered live broadcast packet encapsulated with a new multicast IP after a certain delay.”<br>（……重传服务器在一定的延迟后，以新的多播IP封装重传缓存的直播分组。） | 对比文件明确公开了两种实体：1）作为接收方设备的“终端”（即目标UE），其检测分组丢失并加入延迟多播流以接收和恢复（播放）媒体。2）作为传送方设备/仲裁者的“重传服务器”，其生成延迟多播流并向加入该组的终端（目标UE）传送。这完全对应于技术特征K的两种情形。该技术特征被直接公开。 |
| **技术特征L**：其特征在于，所述媒体接收间隙对应于(i)其中少于阈值数目的用于所述实时媒体流的可用媒体分组成功抵达所述接收方设备的第一时间间隙，或者(ii)其中所述阈值数目的用于所述实时媒体流的可用媒体分组可用、但所述接收方设备处的条件抑制由所述接收方设备进行的回放的第二时间间隙。<br>**《隐含公开》** | [0033] “...if detecting that the live broadcast packet has an error or a loss...”<br>（……如果检测到直播分组有错误或丢失……） | 对比文件明确公开了媒体接收间隙对应于分组“错误或丢失”，这直接属于技术特征中定义的第一种情况（即分组未成功抵达）。尽管对比文件没有明确提及“少于阈值数目”，但分组错误或丢失必然意味着成功抵达的分组数目少于预期（可视为隐含的阈值）。对比文件未提及第二种情况（条件抑制回放）。然而，对于第一种情况，本领域技术人员可以从公开的“分组错误或丢失”毫无疑义地确定其属于媒体接收间隙。因此，该技术特征被部分公开，整体上可被视为被隐含公开。 |
| **技术特征M**：其特征在于，所述媒体接收间隙基于网络连接降级而发生。<br>**《隐含公开》** | [0007] “However, if the packet loss is not caused by the user side but occurs in an aggregation layer or a core node layer of the transmission network...”<br>（然而，如果分组丢失不是由用户侧引起，而是发生在传输网络的聚合层或核心节点层……） | 对比文件指出分组丢失可能发生在传输网络的中间节点（聚合层或核心层），这属于网络连接问题，可导致连接质量降级。本领域技术人员能够理解，网络连接降级（如拥塞、错误）是导致分组丢失（即媒体接收间隙）的常见原因。因此，该技术特征被隐含公开。 |
| **技术特征N**：其特征在于，所述网络连接降级发生在服务网络与接收方设备之间的连接上和/或回程连接上。<br>**《隐含公开》** | [0007] “...occurs in an aggregation layer or a core node layer of the transmission network...”<br>（……发生在传输网络的聚合层或核心节点层……） | 对比文件提及分组丢失发生在“传输网络的聚合层或核心节点层”。在通信网络架构中，聚合层和核心节点层通常涉及服务网络内部的回程连接以及与服务接入网之间的连接。本领域技术人员可以合理推断，这些位置的故障或拥塞即构成了服务网络与接收方设备之间连接上和/或回程连接上的降级。因此，该技术特征被隐含公开。 |
| **技术特征O**：其特征在于，进一步包括：执行关于所述倒回流的追赶协议，以使得所述倒回流将追赶上所述实时媒体流。<br>**《未直接或隐含公开》** | [0073] “...after finding a packet, which is required to be recovered, from the delay multicast stream, the terminal withdraws from the multicast group, merely reserves the original multicast group and continuously receives the packet from the original multicast group.”<br>（……在从延迟多播流中找到需要恢复的分组后，终端退出该多播组，仅保留原始多播组并持续从原始多播组接收分组。） | 对比文件描述的是终端从延迟流中恢复丢失分组后，即切换回原始流继续接收。这个过程是简单的“切换”而非“追赶”。目标专利中的“追赶协议”指通过快进、跳帧、音频转文本等主动方式加速倒回流以追赶上实时流的进度，这是一种更复杂的同步机制。对比文件完全没有涉及这类主动加速或处理协议。因此，该技术特征未被公开。 |
| **技术特征P**：其特征在于，所述实时通信会话是半双工会话并且所述接收方设备是在所述倒回流被接收的同时作为非发言权持有者参与所述实时通信会话的目标用户装备(UE)，所述方法进一步包括：在所述接收方设备正接收所述倒回流的同时请求所述实时通信会话的发言权。<br>**《未直接或隐含公开》** | 对比文件涉及的是IPTV直播服务，这是一种单向广播式的通信，所有终端都是接收者。文件中没有任何关于半双工、发言权、发言权持有者或发言权请求的描述或暗示。该技术特征涉及交互式会话管理，与对比文件的广播场景有本质区别。因此，该技术特征未被公开。 | |
| **技术特征Q**：响应于所述发言权请求而接收发言权被准予给所述接收方设备的指示。<br>**《未直接或隐含公开》** | 同技术特征P，对比文件不涉及发言权机制，因此没有也不可能公开接收发言权准予指示的相关内容。该技术特征未被公开。 | |
| **技术特征R**：在所述指示被接收到之后继续接收和播放所述倒回流直至(i)所述倒回流追赶上所述发言权被准予给所述接收方设备的时间，和/或(ii)所述接收方设备确定要退出倒回模式。<br>**《未直接或隐含公开》** | 同技术特征P、Q，对比文件不涉及发言权机制，因此没有相关描述。同时，对比文件中终端退出延迟组是基于找到恢复分组，而非“追赶”或“决定退出倒回模式”的复杂逻辑。该技术特征未被公开。 | |
| **技术特征S**：在(i)或(ii)之后作为发言权持有者开始传送用于所述实时通信会话的媒体。<br>**《未直接或隐含公开》** | 同技术特征P、Q、R，对比文件中的终端是纯粹的媒体接收设备，不涉及作为发言权持有者向会话发送媒体。该技术特征未被公开。 | |
| **技术特征T**：其特征在于，进一步包括：监视与所述实时媒体流和/或所述倒回流相关联的一个或多个性能度量。<br>**《直接公开》** | [0076]-[0079] “...the terminal may feed back it to the retransmission server through an extended Real-time Control Protocol (RTCP) message... The extended RTCP message needs to indicate a detection delay and a multicast joining delay of a current terminal...”<br>（……终端可以通过扩展的实时控制协议（RTCP）消息将其反馈给重传服务器……扩展的RTCP消息需要指示当前终端的检测延迟和多播加入延迟……） | 对比文件明确描述了终端需要确定并向服务器报告“检测延迟”、“多播加入延迟”等信息。这些信息是终端在接收和处理实时媒体流（原始流）及倒回流（延迟流）过程中监视和计算得到的性能度量。该技术特征被直接公开。 |
| **技术特征U**：向所述实时媒体流和/或所述倒回流的始发者报告所述一个或多个性能度量。<br>**《直接公开》** | [0076] “...the terminal may feed back it to the retransmission server through an extended Real-time Control Protocol (RTCP) message...”<br>（……终端可以通过扩展的实时控制协议（RTCP）消息将其反馈给重传服务器……）<br>[0080] “After receiving the RTCP message, the retransmission server...”<br>（重传服务器接收到RTCP消息后……） | 对比文件明确说明了终端将监视到的性能度量（如检测延迟、加入延迟）通过扩展的RTCP消息反馈给“重传服务器”。在对比文件系统中，重传服务器正是延迟多播流（倒回流）的始发者，同时也接收原始流。因此，该技术特征被直接公开。 |
| **技术特征V**：其特征在于，所述一个或多个性能度量包括所述实时媒体流和/或所述倒回流的分组差错率(PER)。<br>**《隐含公开》** | [0033] “...if detecting that the live broadcast packet has an error or a loss...”<br>（……如果检测到直播分组有错误或丢失……）<br>[0076] “...if after the terminal joins the delay retransmission multicast stream, the terminal finds that a desired packet is missed...”<br>（……如果在终端加入延迟重传多播流后，终端发现所需的包丢失了……） | 对比文件反复提及终端检测分组“错误或丢失”、“包丢失”。分组差错率（PER）是衡量此类错误的直接和常用性能度量。本领域技术人员在监视媒体流质量时，完全有可能且自然地会计算或评估PER。虽然对比文件没有明确写出“PER”这个术语，但其所描述的核心问题（分组丢失/错误）正是PER度量的对象。因此，该技术特征被隐含公开。 |
<<<A>>><<<B>>><<<D>>><<<K>>><<<T>>><<<U>>><<<c>>><<<g>>><<<h>>><<<i>>><<<l>>><<<m>>><<<n>>><<<v>>>