对比文件名称：2011-05-26_US2011126255A_发明申请_US20110126255A1 System and method for remote-hosted video effects
目标专利名称：317倒回实时通信会话CN105103520B
模型名称：专利创造性评估模型
## 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：所述接收方设备在实时通信会话期间从传送方设备接收数据，《直接公开》 | [0125] "The home or office client device then decodes the compressed video stream and renders the decompressed video images on a monitor or TV." （家庭或办公室客户端设备随后解码压缩视频流并将解压缩的视频图像呈现在监视器或电视上。） | 对比文件描述了客户端设备从托管服务（hosting service）接收压缩视频流的过程，这构成了接收方设备从传送方设备接收数据。这与目标专利中接收方设备在实时通信会话期间从传送方设备接收数据的技术特征作用相同，都是实现媒体流的传输和接收。本领域技术人员能够毫无疑义地得出该技术方案。 |
| **技术特征B**：所述方法包括：在所述接收方设备尝试接收来自所述传送方设备的实时媒体流的同时检测媒体接收间隙《隐含公开》 | [0210] "...while monitoring performance metrics associated with their respective media streams, 1210."（...同时监视与其相应媒体流相关联的性能度量，1210。） | 对比文件公开了客户端设备在接收媒体流的同时，会监视与流相关的性能度量（例如分组差错率）。性能度量的恶化（如高分组丢失率）可以间接表明媒体接收出现了间隙或问题。虽然未明确使用“检测媒体接收间隙”这一表述，但本领域技术人员基于对网络通信和流媒体传输的普遍知识，能够合理推断出通过监视性能度量（如PER）来检测数据接收是否出现中断或质量下降（即媒体接收间隙）是惯用技术手段。因此，该技术特征被隐含公开。 |
| **技术特征C**：响应于所述检测而向所述传送方设备传送倒回请求，所述倒回请求被配置成触发所述传送方设备生成和提供所述实时媒体流的包括在所述媒体接收间隙期间丢失的媒体的时间延迟版本《隐含公开》 | [0368] "For example, FIGS. 25a-b illustrate one embodiment of the invention in which a feedback channel 2501 is established between the client device 205 and the hosting service 210. The feedback channel 2501 is used by the client device 205 to send packetized acknowledgements of successfully received tiles/frames and/or indications of unsuccessfully received tiles/frames."（例如，图25a-b图解了本发明的一个实施例，其中在客户端设备205与托管服务210之间建立了反馈信道2501。反馈信道2501由客户端设备205用于发送关于成功接收的图块/帧的分组化确认和/或关于未成功接收的图块/帧的指示。） | 对比文件公开了客户端设备通过反馈信道向服务器（托管服务）发送关于数据包接收成功或失败的信息（如确认或丢失指示）。服务器在接收到关于数据丢失的反馈后，可以采取行动，例如重新发送丢失的数据包或调整编码策略。虽然对比文件未明确描述“倒回请求”这一具体概念，也未明确提及生成“时间延迟版本”，但本领域技术人员可以理解，发送关于数据丢失的反馈信息，其目的之一就是请求服务器采取措施以恢复丢失的数据，这与“倒回请求”旨在触发服务器提供丢失媒体的意图在功能上具有相似性。通过推理，可以认为这种反馈信息构成了隐含的“倒回请求”，可能触发服务器生成并发送包含丢失数据的补充流（可视为一种时间上滞后的版本）。因此，该技术特征被隐含公开。 |
| **技术特征D**：响应于所述倒回请求而接收倒回流，其中所述倒回流被配置成由所述接收方设备独立于所述实时媒体流来播放。《未公开》 | [0247] "Thus, in one embodiment, each compressed video/audio output 1539 stream being routed to a user client 415 is also being multicasted to a delay buffer 1515. When the video/audio is stored on a delay buffer 1515, a directory on the delay buffer 1515 provides a cross reference between the network address of the app/game server 1521-1525 that is the source of the delayed video/audio and the location on the delay buffer 1515 where the delayed video/audio can be found."（因此，在一个实施例中，每个被路由到用户客户端415的压缩视频/音频输出1539流也被多播到延迟缓冲器1515。当视频/音频存储在延迟缓冲器1515上时，延迟缓冲器1515上的目录提供了延迟视频/音频源的app/game服务器1521-1525的网络地址与延迟缓冲器1515上可以找到延迟视频/音频的位置之间的交叉引用。） | 对比文件描述了将视频流存储到延迟缓冲器（delay buffer）中，用户随后可以从该缓冲器回放（“rewind”）视频。这提供了一种延迟观看的功能。然而，目标专利的“倒回流”是响应于实时会话中的特定“倒回请求”而动态生成的、包含丢失媒体的“时间延迟版本”，旨在使接收方设备能追赶并重新加入实时会话。对比文件的延迟缓冲器是用于存档和事后回放的通用存储，并非针对实时会话中特定间隙的、按需生成的、旨在与实时流并行或替代以追赶会话的“倒回流”。此外，对比文件未描述该延迟回放的流是“独立于实时媒体流来播放”的特定配置。两者在目的、触发机制和与实时流的关系上存在本质区别。 |
| **技术特征E**：其特征在于，进一步包括：在所述倒回流被接收的同时继续接收所述实时媒体流。《未公开》 | 无对应内容。 | 对比文件未描述客户端在接收来自延迟缓冲器的回放流（或任何可类比为倒回流的数据）的同时，继续接收原始的实时媒体流。目标专利中此特征涉及在倒回期间维持对实时流的监听，以实现追赶或并行处理，该特定场景未被公开。 |
| **技术特征F**：其特征在于，在响应于所述倒回请求而接收所述倒回流的同时所述实时媒体流的接收停止。《未公开》 | 无对应内容。 | 对比文件未描述在请求或接收延迟回放内容（或任何类似数据）时，停止接收原始实时媒体流。目标专利中此特征涉及切换到倒回模式时可能中断实时流接收，该特定操作模式未被公开。 |
| **技术特征G**：其特征在于，所述倒回请求对应于隐式倒回请求，所述隐式倒回请求传达被配置用于由所述传送方设备评估的信息以准许所述传送方设备独立地触发所述倒回流的生成和递送。《隐含公开》 | [0368] "The feedback channel 2501 is used by the client device 205 to send packetized acknowledgements of successfully received tiles/frames and/or indications of unsuccessfully received tiles/frames."（反馈信道2501由客户端设备205用于发送关于成功接收的图块/帧的分组化确认和/或关于未成功接收的图块/帧的指示。）[0375] "...the encoder 2600 encodes the next tile/frame using the last tile/frame known to have been successfully received by the decoder 2602."（...编码器2600使用已知被解码器2602成功接收的最后一个图块/帧来编码下一个图块/帧。） | 对比文件公开了客户端通过反馈信道向服务器发送关于数据包接收成功/失败的信息（如确认或丢失指示）。这种反馈信息并非直接请求一个“倒回流”，而是提供了网络状况和数据完整性的状态信息。服务器（传送方设备）可以基于这些信息（如检测到数据包丢失）独立地决定采取纠正措施，例如重新发送丢失的数据或调整后续编码的参考帧。这种由状态信息触发服务器动作的机制，符合“隐式倒回请求”的特征：即传达信息供传送方评估，并由传送方独立决定是否触发某种补救性数据流的生成和递送。因此，该技术特征被隐含公开。 |
| **技术特征H**：其特征在于，所传达的信息与所述媒体接收间隙相关。《直接公开》 | [0368] "...indications of unsuccessfully received tiles/frames."（...关于未成功接收的图块/帧的指示。） | 对比文件明确记载了客户端向服务器发送“未成功接收的图块/帧的指示”。未能成功接收图块或帧直接对应于媒体数据的丢失或接收失败，这与目标专利中“媒体接收间隙”期间丢失媒体的概念直接相关。因此，该技术特征被直接公开。 |
| **技术特征I**：其特征在于，所述倒回请求对应于显式倒回请求，所述显式倒回请求显式地请求所述传送方设备提供所述实时媒体流的所述时间延迟版本。《未公开》 | 无对应内容。 | 对比文件未描述客户端向服务器发送一个明确请求提供“实时媒体流的时间延迟版本”的消息。反馈信道传输的是接收状态（确认/丢失），而非对特定格式或内容（如时间延迟版本）的显式请求。 |
| **技术特征J**：其特征在于，所述显式倒回请求请求所述传送方设备以相对于所述实时媒体流的第一延迟量提供所述实时媒体流的所述时间延迟版本，所述倒回流包括相对于所述实时媒体流的第二延迟量，所述第二延迟量不同于所述第一延迟量。《未公开》 | 无对应内容。 | 对比文件未涉及任何关于请求特定延迟量（第一延迟量）的倒回版本，以及实际提供的版本具有不同延迟量（第二延迟量）的内容。 |
| **技术特征K**：其特征在于，所述接收方设备对应于正参与所述实时通信会话的目标用户装备(UE)，并且所述目标UE播放所述倒回流，或者所述接收方设备对应于正仲裁和/或裁夺所述实时通信会话的服务器，并且所述服务器向参与所述实时通信会话的至少一个目标UE传送所述倒回流。《未公开》 | 无对应内容。 | 对比文件描述了客户端设备接收和播放视频流，以及服务器（托管服务）向客户端传送视频流。然而，并未区分这些流是“实时媒体流”还是专门生成的“倒回流”，也未描述在实时会话上下文中的仲裁服务器代表目标UE请求并转发倒回流的具体场景。目标专利中关于接收方设备身份（UE或服务器）及其在倒回过程中的特定角色（播放或转发倒回流）的限定未被公开。 |
| **技术特征L**：其特征在于，所述媒体接收间隙对应于(i)其中少于阈值数目的用于所述实时媒体流的可用媒体分组成功抵达所述接收方设备的第一时间间隙，或者(ii)其中所述阈值数目的用于所述实时媒体流的可用媒体分组可用、但所述接收方设备处的条件抑制由所述接收方设备进行的回放的第二时间间隙。《隐含公开》 | [0210] "For example, as illustrated in FIG. 12, while playing a video game or using an application at the user premises 211 via a keyboard, mouse, game controller or other input device 421, control signal logic 413 on the client 415 transmits control signals 406a-b (typically in the form of UDP packets) representing the button presses (and other types of user inputs) actuated by the user to the hosting service 210."（例如，如图12所示，当用户在用户场所211通过键盘、鼠标、游戏控制器或其他输入设备421玩视频游戏或使用应用程序时，客户端415上的控制信号逻辑413将代表用户所按下按钮（及其他类型的用户输入）的控制信号406a-b（通常以UDP分组形式）传送到托管服务210。）[0210] "...while monitoring performance metrics associated with their respective media streams, 1210."（...同时监视与其相应媒体流相关联的性能度量，1210。） | 对比文件公开了客户端在接收媒体流的同时监视性能度量（如分组差错率PER）。性能度量的恶化，例如高PER，意味着大量分组未能成功抵达客户端，这直接对应于技术特征L的第(i)种情况（少于阈值数目的分组成功抵达）。虽然对比文件未明确设定一个具体的“阈值数目”，但本领域技术人员理解，在实际系统中，判断网络是否出现“间隙”或“中断”通常会基于一个预定义或动态调整的阈值（如连续丢失N个分组）。因此，通过公开的性能监视和分组丢失概念，可以合理推断出存在基于分组成功抵达数目来判断媒体接收间隙的技术方案。第(ii)种情况（条件抑制回放）在对比文件中没有明确对应内容。因此，技术特征L的第(i)部分被隐含公开。 |
| **技术特征M**：其特征在于，所述媒体接收间隙基于网络连接降级而发生。《直接公开》 | [0184] "For example, there may be too much network traffic at the DSL central office or on the local cable modem loop, or there may be noise on the cabling causing dropped packets..."（例如，DSL中心局或本地电缆调制解调器环路上可能有太多网络流量，或者线缆上可能有噪声导致丢包...） | 对比文件明确描述了网络连接问题（如拥塞、噪声）会导致数据包丢失。数据包丢失是媒体接收间隙的一种典型表现形式。因此，媒体接收间隙基于网络连接降级而发生这一特征被直接公开。 |
| **技术特征N**：其特征在于，所述网络连接降级发生在服务网络与接收方设备之间的连接上和/或回程连接上。《直接公开》 | [0184] "For example, there may be too much network traffic at the DSL central office or on the local cable modem loop..."（例如，DSL中心局或本地电缆调制解调器环路上可能有太多网络流量...） | 对比文件提到的“DSL central office”（DSL中心局）和“local cable modem loop”（本地电缆调制解调器环路）正是服务网络（运营商网络）与接收方设备（用户端）之间的连接部分。这直接对应于目标专利中“服务网络与接收方设备之间的连接上”的网络连接降级。因此，该技术特征被直接公开。 |
| **技术特征O**：其特征在于，进一步包括：执行关于所述倒回流的追赶协议，以使得所述倒回流将追赶上所述实时媒体流。《未公开》 | 无对应内容。 | 对比文件未描述任何旨在使一个延迟的流（或回放流）加速以“追赶”上实时流的协议或机制。目标专利中的“追赶协议”（如快进、跳帧）是倒回功能中的一个特定步骤，未被公开。 |
| **技术特征P**：其特征在于，所述实时通信会话是半双工会话并且所述接收方设备是在所述倒回流被接收的同时作为非发言权持有者参与所述实时通信会话的目标用户装备(UE)，所述方法进一步包括：在所述接收方设备正接收所述倒回流的同时请求所述实时通信会话的发言权《未公开》 | 无对应内容。 | 对比文件主要涉及视频流的单向或双向传输（如游戏、应用），但未具体限定为“半双工会话”模式，也未描述在接收某种延迟/回放流（类比倒回流）的同时请求“发言权”（即发送权）的场景。目标专利中此特征涉及半双工会话中倒回模式与发言权管理的交互，未被公开。 |
| **技术特征Q**：响应于所述发言权请求而接收发言权被准予给所述接收方设备的指示《未公开》 | 无对应内容。 | 对比文件未涉及发言权请求和准予的机制。 |
| **技术特征R**：在所述指示被接收到之后继续接收和播放所述倒回流直至(i)所述倒回流追赶上所述发言权被准予给所述接收方设备的时间，和/或(ii)所述接收方设备确定要退出倒回模式《未公开》 | 无对应内容。 | 对比文件未涉及在发言权准予后继续处理倒回流直至特定条件的场景。 |
| **技术特征S**：在(i)或(ii)之后作为发言权持有者开始传送用于所述实时通信会话的媒体。《未公开》 | 无对应内容。 | 对比文件未涉及从倒回模式切换到发言权持有者并开始传送媒体的场景。 |
| **技术特征T**：其特征在于，进一步包括：监视与所述实时媒体流和/或所述倒回流相关联的一个或多个性能度量《直接公开》 | [0210] "...while monitoring performance metrics associated with their respective media streams, 1210."（...同时监视与其相应媒体流相关联的性能度量，1210。） | 对比文件明确记载了客户端设备监视与其媒体流相关的性能度量。这与目标专利中监视与实时媒体流相关的性能度量的技术特征完全相同。因此，该技术特征被直接公开。 |
| **技术特征U**：向所述实时媒体流和/或所述倒回流的始发者报告所述一个或多个性能度量。《直接公开》 | [0215] "UE 2...N each receive, buffer and play their respective media streams, 1205, while monitoring with their respective media streams associated performance metrics, 1210. In 1215, UE 2...N report performance metrics to UE 1."（UE 2...N各自接收、缓冲和播放它们相应的媒体流，1205，同时监视与其相应媒体流相关联的性能度量，1210。在1215，UE 2...N向UE 1报告性能度量。） | 对比文件明确描述了客户端设备（UE）在监视性能度量后，向媒体流的始发者（例如，另一个UE或服务器）报告这些性能度量。这与目标专利中向始发者报告性能度量的技术特征相同。因此，该技术特征被直接公开。 |
| **技术特征V**：其特征在于，所述一个或多个性能度量包括所述实时媒体流和/或所述倒回流的分组差错率(PER)。《直接公开》 | [0210] "For example, UE 2...N in 1210 monitor performance metrics can include packet error rate (PER) etc."（例如，UE 2...N在1210监视的性能度量可包括分组差错率(PER)等。） | 对比文件明确将分组差错率（PER）列举为被监视的性能度量之一。这与目标专利中性能度量包括PER的技术特征完全相同。因此，该技术特征被直接公开。 |
<<<A>>><<<H>>><<<M>>><<<N>>><<<T>>><<<U>>><<<V>>><<<b>>><<<c>>><<<g>>><<<l>>>