本次调用的模型名称：专利创造性评估模型。
对比文件的名称：2010-02-12_JP2010034897A_发明专利_JP2010034897A Video receiving apparatus, and method of receiving video
目标专利的名称：317倒回实时通信会话CN105103520B
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：所述接收方设备在实时通信会话期间从传送方设备接收数据，《直接公开》 | 对比文件描述了视频接收装置100通过网络102从视频分发服务器101接收视频流（映像ストリーム）。例如，[2]段记载：“映像受信装置１００は、ネットワーク１０２を介して映像配信サーバ１０１から映像ストリームを受信する”。 | 对比文件公开了接收方设备（视频接收装置100）从传送方设备（视频分发服务器101）接收数据（视频流）。这对应于实时通信会话中的数据接收，因为对比文件明确使用RTP/UDP协议进行实时传输（[2]段：“配信プロトコルとしてRTP...UDP...が採用されている”）。因此，本领域技术人员能够毫无疑义地得出该技术特征。 |
| **技术特征B**：所述方法包括：在所述接收方设备尝试接收来自所述传送方设备的实时媒体流的同时检测媒体接收间隙，《直接公开》 | 对比文件描述了在接收视频流时检测传输错误（パケット欠落）。例如，[2]段记载：“データフロー７０４では、RTPパケットヘッダのシーケンス番号が連続しているか否かをチェックすることによりパケット欠落が発生しているか否かを判定する。また、所定期間、次のRTPパケットが取得できない場合にもパケット欠落が発生したものと判定する”。 | 对比文件公开了接收方设备在接收实时视频流（即实时媒体流）的过程中，通过检查序列号或等待超时来检测数据包丢失，这直接对应于检测“媒体接收间隙”。该检测动作在接收尝试的同时进行。因此，该技术特征被直接公开。 |
| **技术特征C**：响应于所述检测而向所述传送方设备传送倒回请求，所述倒回请求被配置成触发所述传送方设备生成和提供所述实时媒体流的包括在所述媒体接收间隙期间丢失的媒体的时间延迟版本，《直接公开》 | 对比文件描述了在检测到FEC无法恢复的错误（“エラー再送要”）时，向视频分发服务器发送指定了再生开始时间（再生開始時間）的PLAY命令，以请求从该时间点重新发送视频流。例如，[2]段记载：“‘エラー再送要’と判断した場合には、...再生時間を指定したPLAYコマンドを映像配信サーバ１０１に送信する”。图4和对应描述（S404-S408）也展示了通过PAUSE和指定时间的PLAY命令来请求从过去某个时间点重新开始传输。 | 对比文件公开了响应于错误检测，向传送方设备（视频分发服务器）发送请求（PLAY命令），该请求指定一个过去的再生开始时间，从而触发传送方设备从该时间点提供视频流。这相当于提供了实时媒体流的一个时间延迟版本（从过去开始），其中包含了在错误（间隙）期间丢失的媒体。虽然对比文件使用“再送”一词，但其效果是提供从过去时间点开始的媒体流，这与“生成和提供时间延迟版本”在功能上实质相同。因此，该技术特征被直接公开。 |
| **技术特征D**：响应于所述倒回请求而接收倒回流，其中所述倒回流被配置成由所述接收方设备独立于所述实时媒体流来播放，《直接公开》 | 对比文件描述了在发送指定再生时间的PLAY命令后，接收从该时间点开始的视频流（映像ストリーム），并由视频再生部进行播放。例如，[2]段记载：“ステップＳ４０８では、ステップＳ４０６で指定した再生時間に対応したストリーム位置から送られる映像ストリームを受信する”。接收到的视频流由接收装置独立播放。 | 对比文件公开了响应于PLAY请求（倒回请求），接收从指定时间点开始的视频流（倒回流）。该视频流由接收装置（视频接收装置100）的映像再生部104进行播放。在错误恢复过程中，接收方在接收到重新发送的流之前，原实时流传输已被PAUSE命令暂停（图4，S404），因此接收并播放的重新发送流是独立于原先的实时流的。因此，该技术特征被直接公开。 |
| **技术特征E**：其特征在于，进一步包括：在所述倒回流被接收的同时继续接收所述实时媒体流。《未公开》 | 对比文件中，在发生传输错误并请求重新发送时，首先通过PAUSE命令暂停了当前的实时流传输（图4，S404）。随后请求并接收从过去时间点开始的流。未记载在接收重新发送的流（倒回流）的同时，还继续并行接收原先的实时媒体流。 | 对比文件在处理错误时采用的是“暂停-重新从指定点开始”的模式，没有公开同时并行接收两个版本（实时版本和时间延迟版本）的媒体流。本领域技术人员无法从对比文件毫无疑义地得出或通过合理推断得出此特征。因此，该技术特征未被公开。 |
| **技术特征F**：其特征在于，在响应于所述倒回请求而接收所述倒回流的同时所述实时媒体流的接收停止。《直接公开》 | 对比文件图4的流程明确显示，在发送重新开始的PLAY命令（S406）之前，先发送了PAUSE命令（S404）以暂停传输。[2]段也记载：“ステップＳ４０４では、RTSPプロトコルにおけるPAUSEコマンドを映像配信サーバ１０１に対して送信する例を示している”。这意味着在接收重新发送的流（倒回流）时，原先的实时流传输已停止。 | 对比文件公开了在发送倒回请求（指定时间的PLAY命令）之前，先发送PAUSE命令停止实时媒体流的传输。因此，在接收倒回流的同时，实时媒体流的接收已经停止。该技术特征被直接公开。 |
| **技术特征G**：其特征在于，所述倒回请求对应于隐式倒回请求，所述隐式倒回请求传达被配置用于由所述传送方设备评估的信息以准许所述传送方设备独立地触发所述倒回流的生成和递送。《未公开》 | 对比文件中，接收方向传送方发送的是显式的RTSP协议命令（PAUSE和PLAY），其中PLAY命令显式指定了再生开始时间（[2]段：“再生開始位置として所望の再生時間を指定する”）。没有公开一种不直接请求倒回、而是传达信息由传送方自行评估并决定触发倒回流的“隐式”请求。 | 对比文件仅公开了显式的流控制命令来请求从特定点重新开始传输。没有公开任何形式的“隐式倒回请求”及其工作机制。本领域技术人员无法从对比文件内容中合理推断出此特征。因此，该技术特征未被公开。 |
| **技术特征H**：其特征在于，所传达的信息与所述媒体接收间隙相关。《未公开》（依赖于G） | 由于特征G（隐式倒回请求）未被公开，且对比文件中显式PLAY命令所指定的再生时间虽然是根据错误位置（媒体接收间隙）计算得出的，但这属于显式请求的一部分，而非“隐式”传达的信息。 | 该特征是特征G的进一步限定。由于特征G未被公开，且对比文件未独立公开“传达与媒体接收间隙相关的信息以供传送方独立评估触发倒回”这一概念，因此该技术特征未被直接或隐含公开。 |
| **技术特征I**：其特征在于，所述倒回请求对应于显式倒回请求，所述显式倒回请求显式地请求所述传送方设备提供所述实时媒体流的所述时间延迟版本。《直接公开》 | 对比文件明确记载了使用RTSP PLAY命令，并指定再生开始时间，以显式请求视频分发服务器从该时间点开始提供视频流。例如，[2]段：“ステップＳ４０６では、映像配信サーバ１０１に対してPLAYコマンドを送信する。このとき、再生開始位置として所望の再生時間を指定する”。这显式请求了从过去时间点（即时间延迟版本）的流。 | 对比文件公开的PLAY命令指定再生开始时间，正是显式地请求传送方设备提供从该时间点开始的媒体流，即实时媒体流的时间延迟版本。因此，该技术特征被直接公开。 |
| **技术特征J**：其特征在于，所述显式倒回请求请求所述传送方设备以相对于所述实时媒体流的第一延迟量提供所述实时媒体流的所述时间延迟版本，所述倒回流包括相对于所述实时媒体流的第二延迟量，所述第二延迟量不同于所述第一延迟量。《隐含公开》 | 对比文件描述了接收方指定一个再生时间，但视频分发服务器可能根据其内部的“区切りの良いストリーム位置”（如GOP头）来确定实际的再生开始位置，这可能导致接收方请求的延迟量与服务器实际提供的延迟量不同。[2]段记载：“一般には、映像配信サーバ１０１が認識した映像ストリーム位置をそのまま再生開始位置に採用するのではなく、その近傍の区切りの良いストリーム位置を再生開始位置に採用する”。图6也解释了为避免计时误差，会指定一个更靠前的时间点（如GOP中央），以确保涵盖错误位置。 | 对比文件部分公开了请求的延迟量（基于指定再生时间）与实际服务器开始发送的延迟量可能因服务器对起始点的调整而不同。本领域技术人员通过阅读对比文件可以合理推断，接收方计算并请求一个再生时间（第一延迟量），但服务器基于同步符号（如GOP头）确定实际起始点，从而导致实际提供的流具有不同的延迟量（第二延迟量）。这是一种隐含公开。 |
| **技术特征K**：其特征在于，所述接收方设备对应于正参与所述实时通信会话的目标用户装备(UE)，并且所述目标UE播放所述倒回流，或者所述接收方设备对应于正仲裁和/或裁夺所述实时通信会话的服务器，并且所述服务器向参与所述实时通信会话的至少一个目标UE传送所述倒回流。《直接公开》（部分） | 对比文件中的接收方设备是“映像受信装置”（视频接收装置），它可以被视为一种目标用户设备（UE），它接收并播放倒回流（重新发送的视频流）。[2]段记载：“映像受信装置１００は、...映像配信サーバ１０１から映像ストリームを受信する”以及“映像再生部１０４に再生・出力する”。 | 对比文件直接公开了接收方设备是目标用户设备（视频接收装置）并播放倒回流的情况。然而，对比文件没有公开接收方设备是仲裁服务器并向其他目标UE传送倒回流的情况。但由于权利要求K使用了“或者”，表示两种替代方案，对比文件公开了其中一种方案（目标UE播放），因此该技术特征（作为整体）被直接公开。 |
| **技术特征L**：其特征在于，所述媒体接收间隙对应于(i)其中少于阈值数目的用于所述实时媒体流的可用媒体分组成功抵达所述接收方设备的第一时间间隙，或者(ii)其中所述阈值数目的用于所述实时媒体流的可用媒体分组可用、但所述接收方设备处的条件抑制由所述接收方设备进行的回放的第二时间间隙。《直接公开》（部分） | 对比文件公开了检测“パケット欠落”（分组丢失），即成功抵达的分组数目少于预期。[2]段：“RTPパケットヘッダのシーケンス番号が連続しているか否かをチェックすることによりパケット欠落が発生しているか否かを判定する。また、所定期間、次のRTPパケットが取得できない場合にもパケット欠落が発生したものと判定する”。这对应第一时间间隙。 | 对比文件明确公开了媒体接收间隙对应于分组丢失（即少于预期数目的分组成功抵达）的情况，这属于特征L中的第一种情况（i）。对比文件未提及第二种情况（ii）（条件抑制回放）。但由于权利要求L是“或”关系，公开其中一种即构成公开。因此，该技术特征被直接公开。 |
| **技术特征M**：其特征在于，所述媒体接收间隙基于网络连接降级而发生。《隐含公开》 | 对比文件提及传输错误（伝送エラー）、分组丢失（パケット欠落），这些通常是由于网络连接问题（如拥塞、信号差等）导致的。[2]段在背景技术中提到使用UDP/RTP协议，这些协议不保证可靠传输，易受网络状况影响。 | 虽然对比文件没有明确写出“网络连接降级”这一原因，但本领域技术人员结合公知常识，能够合理推断出分组丢失、传输错误这类媒体接收间隙通常是由于网络连接质量下降（降级）引起的。因此，该技术特征被隐含公开。 |
| **技术特征N**：其特征在于，所述网络连接降级发生在服务网络与接收方设备之间的连接上和/或回程连接上。《隐含公开》 | 对比文件未明确区分网络降级发生的具体位置。但其所描述的网络传输（通过网络102）涵盖了从服务器到接收方的整个路径，其中自然包括服务网络与接收方设备之间的连接。回程连接通常是网络基础设施的一部分。 | 本领域技术人员知道，实时媒体流传输中的网络问题可能发生在路径的任何环节，包括接入网（服务网络与设备间）或核心网/回程链路。对比文件提及的通过网络进行的视频流传输，隐含了这些可能的降级发生点。因此，可以合理推断该特征。 |
| **技术特征O**：其特征在于，进一步包括：执行关于所述倒回流的追赶协议，以使得所述倒回流将追赶上所述实时媒体流。《未公开》 | 对比文件描述了请求从过去时间点重新发送流，并从此开始播放。未提及在播放这个重新发送的流时，采用任何“追赶协议”（如快进、跳帧、语音转文字等）来加速播放，以期追赶上当前的实时媒体流进度。 | 对比文件的方案是：在错误恢复后，接收方就从重新开始的点继续按正常速度播放，并未涉及要“追赶”上实时进度。目标专利中的“追赶协议”是特定的加速同步机制，对比文件完全没有公开或提示。因此，该技术特征未被公开。 |
| **技术特征P**：其特征在于，所述实时通信会话是半双工会话并且所述接收方设备是在所述倒回流被接收的同时作为非发言权持有者参与所述实时通信会话的目标用户装备(UE)，所述方法进一步包括：在所述接收方设备正接收所述倒回流的同时请求所述实时通信会话的发言权《未公开》 | 对比文件涉及的是单向视频流传输（从服务器到接收装置），没有提及任何“半双工会话”、“发言权持有者”或“发言权请求”的概念。其实质是点播视频流的错误恢复。 | 对比文件的通信场景与目标专利的（半双工）实时群通信会话（如PTT）完全不同。对比文件未公开任何关于会话控制权（发言权）请求的特征。因此，该技术特征未被公开。 |
| **技术特征Q**：响应于所述发言权请求而接收发言权被准予给所述接收方设备的指示《未公开》 | 同上，对比文件不涉及发言权机制。 | 由于特征P未被公开，且对比文件本身不涉及发言权准予，该技术特征未被公开。 |
| **技术特征R**：在所述指示被接收到之后继续接收和播放所述倒回流直至(i)所述倒回流追赶上所述发言权被准予给所述接收方设备的时间，和/或(ii)所述接收方设备确定要退出倒回模式《未公开》 | 同上，对比文件不涉及发言权及相关的等待追赶或退出倒回模式的逻辑。 | 该特征与发言权机制紧密相关，对比文件未公开任何相关内容。因此，该技术特征未被公开。 |
| **技术特征S**：在(i)或(ii)之后作为发言权持有者开始传送用于所述实时通信会话的媒体。《未公开》 | 同上，对比文件中的接收装置是视频接收方，未描述其作为媒体发送方开始传送媒体。 | 该特征涉及接收方转变为发送方，这超出了对比文件公开的接收并播放视频流的范围。因此，该技术特征未被公开。 |
| **技术特征T**：其特征在于，进一步包括：监视与所述实时媒体流和/或所述倒回流相关联的一个或多个性能度量《直接公开》 | 对比文件描述了监视传输错误，例如检查RTP序列号的连续性以及判断分组丢失，这本身就是一种性能度量（如分组丢失率）的监视。[2]段：“RTPパケットヘッダのシーケンス番号が連続しているか否かをチェックすることによりパケット欠落が発生しているか否かを判定する”。 | 对比文件公开了在接收实时媒体流（视频流）的过程中，持续监视分组是否连续（即是否发生丢失），这直接对应于监视与实时媒体流相关的性能度量（如分组丢失情况）。因此，该技术特征被直接公开。 |
| **技术特征U**：向所述实时媒体流和/或所述倒回流的始发者报告所述一个或多个性能度量。《隐含公开》 | 对比文件中，当检测到FEC无法恢复的错误（“エラー再送要”）时，接收方向视频分发服务器（始发者）发送PLAY命令以请求从特定时间点重新发送。这个PLAY命令的发送，隐含了将检测到的错误（一种性能度量）报告给服务器，并触发相应的动作。 | 虽然对比文件没有明确使用“报告性能度量”的表述，但其技术方案逻辑是：基于监视到的错误（性能度量恶化），向流始发者发送控制信令（PLAY命令）。本领域技术人员可以合理推断，该控制信令实质上传达（报告）了关于流质量（性能度量）的信息，从而触发了倒回（重新发送）动作。因此，该技术特征被隐含公开。 |
| **技术特征V**：其特征在于，所述一个或多个性能度量包括所述实时媒体流和/或所述倒回流的分组差错率(PER)。《直接公开》 | 对比文件监视的“パケット欠落”（分组丢失）是分组差错率(PER)的重要组成部分或直接表现形式。[2]段所述的通过序列号检查判断分组丢失，就是在评估分组是否错误（丢失）到达。 | 对比文件公开的监视分组是否连续/丢失，直接对应于计算或评估分组差错率(PER)的过程。因此，该技术特征被直接公开。 |
<<<A>>><<<B>>><<<C>>><<<D>>><<<F>>><<<I>>><<<K>>><<<L>>><<<T>>><<<V>>><<<j>>><<<m>>><<<n>>><<<u>>>