本次调用的模型名称：专利创造性评估模型（特征比对与公开性判断专用）
**对比文件名称**：2005-01-27_US2005021821A_发明申请_US20050021821A1 Data transmission
**目标专利名称**：倒回实时通信会话 CN105103520B
## 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：所述接收方设备在实时通信会话期间从传送方设备接收数据，《隐含公开》 | [0044] “Multimedia data is transmitted from a client 102 to a network server 104... A third party client 105... may join the session and receive... data...” [0057] “...the receiving client 105 receives the multimedia data that is being captured by the transmitting client 102 in real-time.” | 对比文件公开了数据（多媒体数据）从传送方客户端102向接收方（服务器104或第三方客户端105）传输。虽然对比文件未明确使用“实时通信会话”这一术语，但其应用场景明确为“流式传输实时关键多媒体数据”（[0001]）、“实时观看直播媒体”（[0043]），且描述了第三方客户端105可以加入会话并实时接收正在被捕获的数据（[0057]）。因此，本领域技术人员能够毫无疑义地确定，对比文件公开了在实时流媒体会话期间，接收方设备从传送方设备接收数据。该特征被隐含公开。 |
| **技术特征B**：所述方法包括：在所述接收方设备尝试接收来自所述传送方设备的实时媒体流的同时检测媒体接收间隙，《隐含公开》 | [0055] “The server 104 receives data packets (511)... The RTP module 302 checks (513) for any packets that have been lost during transmission.” [0059] “The RTP module 402 of the receiving client 105 keeps a record of all of the RTP sequence numbers of the lost data packets.” | 对比文件公开了在接收数据包时，服务器104的RTP模块302会检查传输过程中丢失的数据包（[0055]），接收客户端105的RTP模块402会记录所有丢失数据包的RTP序列号（[0059]）。检测丢失的数据包，即意味着检测到了数据接收的间隙。虽然对比文件使用“丢失的数据包”这一表述，而目标专利使用“媒体接收间隙”，但“间隙”在本领域可被理解为数据包丢失导致的数据流不连续。因此，对比文件隐含公开了在尝试接收实时媒体流（数据包）的同时检测媒体接收间隙（数据包丢失）。 |
| **技术特征C**：响应于所述检测而向所述传送方设备传送倒回请求，所述倒回请求被配置成触发所述传送方设备生成和提供所述实时媒体流的包括在所述媒体接收间隙期间丢失的媒体的时间延迟版本，《未公开》 | [0055] “As soon as a packet is recognised as missing by the server 104 a NACK message containing the RTP sequence number of the missing packet is sent (519) to the client reliably using TCP.” [0059] “The receiving client 105 then sends (539) the record of the lost data packets via TCP to the server 104...” | 对比文件公开了响应于检测到丢失数据包，接收方（服务器104或客户端105）会向传送方发送包含丢失数据包身份（如RTP序列号）的消息（NACK或丢失记录）。该消息的作用是请求重传特定的、丢失的原始数据包。然而，目标专利的“倒回请求”旨在触发传送方生成并提供“实时媒体流的包括在所述媒体接收间隙期间丢失的媒体的时间延迟版本”。这意味着传送方需要创建一个相对于实时流有固定时间延迟（滞后）的、包含丢失媒体的新数据流（倒回流）。对比文件仅请求重传丢失的原始数据包，以填补存档或本地副本中的空缺，并未涉及创建或提供一个具有特定时间延迟（相对于实时流）的、独立的媒体流版本。两者的技术手段和目的存在本质区别。因此，该特征未被直接公开，也不属于本领域技术人员能够从对比文件内容中合理推断出的隐含公开。 |
| **技术特征D**：响应于所述倒回请求而接收倒回流，其中所述倒回流被配置成由所述接收方设备独立于所述实时媒体流来播放。《未公开》 | [0055] “...the server 104 retrieves (541) the identified data packets from the archive 303 and re-transmits (543) the lost data packets using reliable TCP.” [0057] “...the server 104 transmits (531) the received data packets to the receiving client at the same time as they are written to the archive 303.” | 对比文件公开了接收方会接收到重传的丢失数据包（[0055]），或者在实时观看时接收来自服务器的数据包（[0057]）。然而，这些接收到的数据是用于填补当前接收流中的空缺（重传包）或者是实时的数据流本身。目标专利的“倒回流”是一个有意创建的、时间上滞后于实时流的独立媒体流，旨在供接收方独立播放以追赶会话。对比文件没有公开这样的独立、延迟版本的数据流。因此，该特征未被公开。 |
| **技术特征E**：其特征在于，进一步包括：在所述倒回流被接收的同时继续接收所述实时媒体流。《未公开》 | [0057] “...the server 104 transmits (531) the received data packets to the receiving client at the same time as they are written to the archive 303.” | 对比文件公开了第三方客户端105可以实时接收服务器104转发的数据包（[0057]），这类似于接收实时媒体流。但对比文件并未描述在接收重传的丢失数据包（可类比为补发数据）的同时，是否继续接收并播放原始的实时流。更重要的是，如特征C、D所述，对比文件没有“倒回流”的概念。因此，接收倒回流的同时继续接收实时媒体流的特征未被公开。 |
| **技术特征F**：其特征在于，在响应于所述倒回请求而接收所述倒回流的同时所述实时媒体流的接收停止。《未公开》 | 未找到相关描述。 | 对比文件没有描述在接收重传数据（丢失包）时停止接收原始实时数据流。其传输机制是：实时流使用UDP传输，丢失包随后使用TCP重传。没有迹象表明在TCP重传期间UDP传输会停止。目标专利中描述的“倒回流”代替实时媒体流的情况，在对比文件中没有对应。因此，该特征未被公开。 |
| **技术特征G**：其特征在于，所述倒回请求对应于隐式倒回请求，所述隐式倒回请求传达被配置用于由所述传送方设备评估的信息以准许所述传送方设备独立地触发所述倒回流的生成和递送。《隐含公开》 | [0055] “...a NACK message containing the RTP sequence number of the missing packet is sent (519) to the client...” [0059] “The receiving client 105 then sends (539) the record of the lost data packets via TCP to the server 104...” | 对比文件公开了接收方向传送方发送包含丢失数据包身份（RTP序列号）的NACK消息或丢失记录。这些消息传达了关于数据接收状态（哪些包丢失）的信息。传送方设备（客户端102或服务器104）在收到这些信息后，可以独立地（例如，在传输完成后）决定并触发丢失数据包的重传。虽然对比文件的重传机制与目标专利的“生成和递送倒回流”不同，但“传达信息以准许传送方设备独立地触发后续动作（重传）”这一逻辑是相同的。因此，可以认为对比文件隐含公开了一种“隐式请求”的形式，即通过传达丢失信息来触发传送方的补救动作。 |
| **技术特征H**：其特征在于，所传达的信息与所述媒体接收间隙相关。《隐含公开》 | [0055] “...a NACK message containing the RTP sequence number of the missing packet...” | 如特征G所述，对比文件中NACK消息包含丢失数据包的序列号，这直接与数据接收间隙（数据包丢失）相关。因此，该特征被对比文件隐含公开。 |
| **技术特征I**：其特征在于，所述倒回请求对应于显式倒回请求，所述显式倒回请求显式地请求所述传送方设备提供所述实时媒体流的所述时间延迟版本。《未公开》 | 未找到相关描述。 | 对比文件中接收方发送的消息（NACK或丢失记录）仅标识丢失的数据包，并未包含任何“显式请求提供实时媒体流的时间延迟版本”的指令或命令。目标专利中的“显式倒回请求”是请求生成一个特定的延迟流，这与对比文件请求重传特定数据包在目的和内容上均不同。因此，该特征未被公开。 |
| **技术特征J**：其特征在于，所述显式倒回请求请求所述传送方设备以相对于所述实时媒体流的第一延迟量提供所述实时媒体流的所述时间延迟版本，所述倒回流包括相对于所述实时媒体流的第二延迟量，所述第二延迟量不同于所述第一延迟量。《未公开》 | 未找到相关描述。 | 对比文件完全没有涉及请求或设置相对于实时流的“延迟量”的概念。所有传输都是基于数据包的序列号进行请求和补发，不涉及创建具有特定时间偏移的新数据流。因此，该特征未被公开。 |
| **技术特征K**：其特征在于，所述接收方设备对应于正参与所述实时通信会话的目标用户装备(UE)，并且所述目标UE播放所述倒回流，或者所述接收方设备对应于正仲裁和/或裁夺所述实时通信会话的服务器，并且所述服务器向参与所述实时通信会话的至少一个目标UE传送所述倒回流。《直接公开》 | [0001], [0044], [0057] 描述了系统包括客户端设备（102， 105）和服务器（104）。服务器104接收并存储来自客户端102的数据，并可向第三方客户端105转发数据。 | 对比文件明确公开了系统包含作为接收方的用户设备（客户端105）和作为接收方/仲裁方的服务器（104）。客户端105可以接收并播放（显示）来自服务器的数据（[0057]）。服务器104可以从客户端102接收数据，并可向其他客户端105传送数据（[0044]， [0057]）。这直接对应于目标专利中描述的两种接收方设备角色：播放媒体的目标UE，以及向目标UE传送媒体的服务器。因此，该特征被直接公开。 |
| **技术特征L**：其特征在于，所述媒体接收间隙对应于(i)其中少于阈值数目的用于所述实时媒体流的可用媒体分组成功抵达所述接收方设备的第一时间间隙，或者(ii)其中所述阈值数目的用于所述实时媒体流的可用媒体分组可用、但所述接收方设备处的条件抑制由所述接收方设备进行的回放的第二时间间隙。《隐含公开（部分）》 | [0055] “The RTP module 302 checks (513) for any packets that have been lost during transmission.” | 对比文件公开了检查传输过程中丢失的数据包（[0055]）。数据包丢失即意味着“少于预期数目（可理解为阈值数目）的数据包成功抵达接收方设备”，这对应于目标专利中第一种时间间隙（i）的情况。虽然对比文件没有明确设定“阈值数目”，但检测到任何丢失即意味着成功抵达的包少于应抵达的总数。对于第二种时间间隙（ii）（条件抑制回放），对比文件没有相关描述。因此，特征L中关于第一种时间间隙（i）的部分被对比文件隐含公开。 |
| **技术特征M**：其特征在于，所述媒体接收间隙基于网络连接降级而发生。《未公开》 | [0045] “Because the protocol is limited it does not introduce any significant delay and is therefore suited to time-critical applications such as streaming live video footage. UDP provides no facilities for ensuring that the data arrives at the receiver...” | 对比文件提到UDP协议不保证数据到达接收方，暗示了数据包可能因网络问题而丢失。但对比文件并未明确将“媒体接收间隙”（数据包丢失）归因于“网络连接降级”这一具体原因。网络问题是数据包丢失的潜在原因之一，但对比文件未建立此特定因果关系。目标专利明确将间隙与网络连接降级挂钩。因此，该特征未被直接或隐含公开。 |
| **技术特征N**：其特征在于，所述网络连接降级发生在服务网络与接收方设备之间的连接上和/或回程连接上。《未公开》 | 未找到相关描述。 | 对比文件完全没有提及“服务网络与接收方设备之间的连接”或“回程连接”的降级。因此，该特征未被公开。 |
| **技术特征O**：其特征在于，进一步包括：执行关于所述倒回流的追赶协议，以使得所述倒回流将追赶上所述实时媒体流。《未公开》 | 未找到相关描述。 | 对比文件的重传机制仅仅是补发丢失的原始数据包，以完成存档或提供完整副本，不存在让一个数据流（倒回流）“追赶”另一个数据流（实时媒体流）的概念。目标专利的“追赶协议”是为使倒回流能重新并入实时会话而设计的特定机制，在对比文件中没有对应。因此，该特征未被公开。 |
| **技术特征P**：其特征在于，所述实时通信会话是半双工会话并且所述接收方设备是在所述倒回流被接收的同时作为非发言权持有者参与所述实时通信会话的目标用户装备(UE)，所述方法进一步包括：在所述接收方设备正接收所述倒回流的同时请求所述实时通信会话的发言权《未公开》 | 未找到相关描述。 | 对比文件描述的数据传输系统（如流媒体、存档）是单向或双向独立的数据流，不涉及“半双工会话”、“发言权持有者”等群组通信或对讲（PTT）会话中的概念。因此，在接收数据（或重传数据）的同时请求发言权的特征在对比文件中完全没有基础，未被公开。 |
| **技术特征Q**：响应于所述发言权请求而接收发言权被准予给所述接收方设备的指示《未公开》 | 未找到相关描述。 | 同上，对比文件不涉及发言权控制机制。因此，该特征未被公开。 |
| **技术特征R**：在所述指示被接收到之后继续接收和播放所述倒回流直至(i)所述倒回流追赶上所述发言权被准予给所述接收方设备的时间，和/或(ii)所述接收方设备确定要退出倒回模式《未公开》 | 未找到相关描述。 | 同上，对比文件不涉及发言权授予与倒回模式退出的交互。因此，该特征未被公开。 |
| **技术特征S**：在(i)或(ii)之后作为发言权持有者开始传送用于所述实时通信会话的媒体。《未公开》 | 未找到相关描述。 | 同上，对比文件不涉及发言权持有者开始传送媒体的场景。因此，该特征未被公开。 |
| **技术特征T**：其特征在于，进一步包括：监视与所述实时媒体流和/或所述倒回流相关联的一个或多个性能度量《隐含公开》 | [0055] “The RTP module 302 checks (513) for any packets that have been lost during transmission.” [0059] “The RTP module 402 of the receiving client 105 keeps a record of all of the RTP sequence numbers of the lost data packets.” | 对比文件公开了接收方（服务器104的RTP模块302或客户端105的RTP模块402）会检查并记录丢失的数据包。记录数据包丢失情况，即是在监视数据传输的一个性能度量（即数据包丢失率或接收完整性）。虽然对比文件没有“倒回流”，但监视实时媒体流性能的行为已被公开。因此，该特征被隐含公开。 |
| **技术特征U**：向所述实时媒体流和/或所述倒回流的始发者报告所述一个或多个性能度量。《隐含公开》 | [0055] “...a NACK message containing the RTP sequence number of the missing packet is sent (519) to the client...” [0059] “The receiving client 105 then sends (539) the record of the lost data packets via TCP to the server 104...” | 对比文件明确公开了接收方将丢失数据包的信息（即一种性能度量）通过NACK消息或丢失记录发送给传送方（客户端102或服务器104）。这对应于向数据流的始发者报告性能度量。因此，该特征被隐含公开。 |
| **技术特征V**：其特征在于，所述一个或多个性能度量包括所述实时媒体流和/或所述倒回流的分组差错率(PER)。《未公开》 | [0055], [0059] 提到了记录和报告“丢失的数据包”（lost data packets）。 | 对比文件提到了“丢失的数据包”，这可以用于计算分组丢失率。分组差错率（PER）通常包括误码和丢失等。虽然“丢失的数据包”是PER计算的一部分，但对比文件并未明确提及“分组差错率(PER)”这一具体的性能度量术语。本领域技术人员可以从“丢失数据包”推断出存在分组丢失问题，但“PER”作为一个具体的、量化的度量指标，在对比文件中没有被明确公开。因此，该特征未被直接公开。从隐含公开的角度看，报告丢失数据包信息已经隐含了报告分组丢失情况，但严格来说，PER是一个更具体的量化概念。为避免遗漏，倾向于认为该特征未被隐含公开。 |
<<<K>>><<<a>>><<<b>>><<<g>>><<<h>>><<<l>>><<<t>>><<<u>>>