对比文件名称：2008-01-01_US7315898B_发明授权_US07315898B2 Data communication system, data transmission apparatus, data reception apparatus, data communication method, and computer program
目标专利名称：313用于多跳混合网络的无缝切换CN104813605B
模型名称：DeepSeek
**特征比对表格**
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：在混合网络中的设备的第一进入接口处接收与分组流相关联的第一分组以及与所述分组流相关联的第二分组。 | 对比文件说明书[0131]段：“In step S301, the data reception terminal sequentially receives transmission packets, that is, RTP packets containing encoded data as payloads thereof, from the data transmission apparatus.” | 对比文件公开了数据接收终端从数据发送装置顺序接收传输分组（RTP分组）。这是一种通用的、基础的数据接收操作，任何通信系统中的接收设备都会在接口上接收分组。然而，对比文件并未提及“混合网络”这一特定环境，也未限定分组是在“第一进入接口”接收。其接收操作发生在常规的IP网络中，用于传输实时流媒体（如视频）。该特征在对比文件中的作用是实现数据传输的基础步骤，与目标专利中为解决多跳混合网络路径切换导致乱序问题而设定的接收场景（同一接口接收来自不同路径的同一流的分组）在作用和目的上均不相同。因此，该技术特征未被直接公开。从隐含公开角度看，接收分组是任何通信系统的必然步骤，本领域技术人员可以理解对比文件中的接收设备必然在某个接口上接收分组。但这一推理过于宽泛，且未触及目标专利中“在同一接口接收来自不同路径的同一流的分组”这一特定技术情景，该情景是后续乱序处理和路径区分的基础。因此，该特征也不属于隐含公开。 |
| **技术特征B**：所述第一分组与路径更新之前使用的先前路径相关联。 | 未找到相关描述。 | 对比文件的核心是RTP/RTCP协议下的数据可靠传输与实时播放，其分组通过序列号、时间戳标识，并在IP网络上传输。对比文件未提及“混合网络”，也未涉及分组流在传输过程中因“路径更新”而改变路径的概念。所有分组均视为从同一发送端经由网络（可能包含多跳，但非混合网络）到达接收端。因此，“分组与路径更新之前的先前路径相关联”这一概念在对比文件中没有对应。该特征未被公开。 |
| **技术特征C**：并且所述第二分组与所述路径更新之后使用的经更新路径相关联。 | 未找到相关描述。 | 同上，对比文件没有“路径更新”或“经更新路径”的概念。分组传输路径的变化并非其关注或解决的问题。因此，该特征未被公开。 |
| **技术特征D**：对于每个收到分组，确定该收到分组与所述先前路径还是所述经更新路径相关联。 | 对比文件说明书[0133]段：“When the data reception terminal receives the packet with the sequence number of 6, step S302 evaluates to yes, and the lost-packet detection process of step S309 is executed. At this time, the data reception terminal has received packets with sequence numbers of 1 to 3 and 6, and thus determines that packets with sequence numbers of 4 and 5 have been lost.” | 对比文件公开了接收终端检查收到分组的序列号，以确定是否有分组丢失（如序列号4、5）。这是一种基于分组序列的完整性检查，用于触发重传请求（ARQ）。其作用是保障数据传输的可靠性，以支持实时播放。而目标专利中的“确定分组与哪条路径相关联”，是为了解决由于路径切换导致分组乱序到达时，能够区分它们属于旧路径还是新路径，从而进行正确的排序处理。两者解决的问题（丢包 vs. 乱序）、技术目的（触发重传 vs. 路径区分以重排序）以及具体判断依据（序列号连续性 vs. 路径标识）均完全不同。因此，该特征未被直接公开。隐含公开判断：对比文件仅公开了基于序列号检测分组缺失，完全没有涉及任何与“路径”相关联的判定逻辑或标识信息。本领域技术人员无法从对比文件的内容中合理推断出“确定分组与先前路径或经更新路径相关联”的技术方案。因此，该特征也未被隐含公开。 |
| **技术特征E**：以所述第一分组和所述第二分组被传送的次序处理所述第一分组和所述第二分组。 | 对比文件说明书[0072]段：“For example, each frame constituting a motion picture is composed of data contained in a number of packets, and a common timestamp is set in the headers of the RTP packets containing data constituting a single picture frame. Thus, based on timestamps in the header information accumulated in the index list 118, packets with a common timestamp are passed to the decoder 120 as a group of encoded data constituting a single picture frame, thereby allowing the decoder 120 to decode data on a frame-by-frame basis.” | 对比文件公开了接收端根据时间戳将分组按帧传递给解码器进行解码处理。这确保了属于同一帧的分组被一起处理，并且帧与帧之间按照时间戳顺序处理，这可以视为一种“按传送次序处理”。然而，目标专利中的“按传送次序处理”特指在发生路径切换后，即使新路径的分组先于旧路径的分组到达，也要按照源设备发送的原始顺序（即旧路径分组先于新路径分组）进行处理，其核心是解决乱序问题。对比文件中的按序处理是基于流媒体播放的时序要求（时间戳），处理对象是顺序到达但可能丢包的分组流，其乱序问题（如果存在）并非由路径切换引起，也未在说明书中提及。两者技术问题、场景和处理对象的内在次序依据不同。因此，该特征未被直接公开。隐含公开判断：按时间戳顺序处理分组以实现流媒体播放是RTP协议的常规操作。但这与目标专利中针对特定路径切换场景下的强制性顺序恢复机制有本质区别。本领域技术人员无法从对比文件的按时间戳处理中，推理出针对“不同路径导致的乱序”进行“按原始发送次序处理”的方案。因此，该特征也未被隐含公开。 |
| **技术特征F**：其特征在于，所述第二分组在所述第一分组之前被接收到，并且所述处理包括缓冲与所述经更新路径相关联的所述第二分组直至与所述先前路径相关联的所述第一分组被处理。 | 对比文件说明书[0172]段：“Furthermore, since the data reception terminal issues retransmission requests with consideration of processing time for playing and RTT, the data reception terminal is prevented from transmitting useless retransmission request packets and retransmission packets, thereby avoiding reduction in network bandwidth by retransmission.” 以及，接收终端有缓冲区（buffer 117）用于积累接收到的数据。 | 对比文件公开了接收终端具有缓冲区（117）来积累接收到的分组数据，然后按时间戳传递给解码器。它也存在基于RTT和处理时间决定是否请求重传的机制，这隐含了时间上的考虑。但是，其缓冲的目的是积累足够的数据以进行解码播放，或者等待重传分组到达以填补缺失，而不是专门用于“缓冲新路径分组直至旧路径分组被处理”以解决路径切换导致的乱序。其缓冲逻辑与路径标识无关。因此，该特征未被直接公开。隐含公开判断：虽然对比文件有缓冲区和基于时间的控制，但其技术情景和目标完全不同。本领域技术人员无法从“为解码积累数据”或“为等待重传而延迟处理”的现有技术中，推理出“为等待来自另一条路径的、先发送但后到达的分组而缓冲当前路径分组”这一特定于路径切换场景的方案。因此，该特征也未被隐含公开。 |
| **技术特征G**：其特征在于，所述处理是在协议栈中比传输层低的层上执行的。 | 对比文件说明书[0072]段：“The payload data (i.e., the encoded data) extracted from the packets is accumulated in a buffer 117. Position data indicating positions of the extracted data in the buffer and header information associated with the data are accumulated as an index list 118. The encoded data accumulated in the buffer 117 is passed to a decoder 120 at timings controlled based on the header information accumulated in the index list 118, and the encoded data is decoded by the decoder 120.” | 对比文件公开的处理（将数据传递给解码器进行解码）明显发生在应用层或表示层（解码属于应用功能）。RTP协议本身工作在传输层之上（应用层）。虽然接收分组涉及网络层和传输层，但对比文件描述的“处理”（即决定分组传递顺序、解码）是高层应用行为。目标专利明确强调处理在“比传输层低的层上执行”，例如在MAC层或抽象层，以实现快速、底层的路径切换支持。两者执行的协议栈层级截然不同。因此，该特征未被直接公开。隐含公开判断：对比文件描述的系统架构和处理流程集中在应用层对RTP数据的处理。没有任何内容提示或暗示此类排序和缓冲操作可以在传输层以下（如数据链路层）完成。本领域技术人员无法从中推理出该特征。因此，该特征也未被隐含公开。 |
| **技术特征H**：其特征在于，所述处理包括：接收与所述经更新路径相关联的流开始标记分组。 | 未找到相关描述。对比文件中有“EOS (End of Stream)”分组（[0077], [0125]），用于声明流结束。 | 对比文件公开了“流结束标记分组”（EOS-RTCP），但未公开任何“流开始标记分组”。EOS分组用于通知接收端数据传输完毕，其作用与目标专利中用于指示新路径开始的“流开始标记分组”完全不同。因此，该特征未被直接公开。隐含公开判断：标记分组的概念是存在的，但仅用于标记流结束。本领域技术人员无法从一个孤立的、含义相反的“流结束标记”推理出“流开始标记”的存在及其在路径切换上下文中的特定作用。因此，该特征也未被隐含公开。 |
| **技术特征I**：响应于接收到所述流开始标记分组，缓冲与所述经更新路径相关联的分组直至与所述先前路径相关联的分组已被处理。 | 未找到相关描述。 | 该特征依赖于技术特征H（流开始标记分组）和技术特征F（基于路径的缓冲逻辑），这两者在对比文件中均未被公开。因此，该特征也未被公开。 |
| **技术特征J**：其特征在于，所述处理包括：接收与所述先前路径相关联的流结束标记分组。 | 对比文件说明书[0077]段：“When the sender terminal 104 detects completion of the stream data to be transmitted, the sender terminal 104 transmits an RTCP packet containing an EOS (End of Stream) message created by an RTCP-packet creating unit 107 to the receiver terminal 121 to explicitly declare the end of the data stream.” | 对比文件公开了发送端在流数据传输完毕时，发送一个EOS（流结束）RTCP分组给接收端。这是一个标记分组，用于声明整个流的结束。然而，目标专利中的“流结束标记分组”特指与“先前路径”（旧路径）相关联，用于标记通过该旧路径传输的流的结束，是路径切换过程中的一个信令步骤，并非整个数据流的终结。两者作用（整个流结束 vs. 特定路径上的子流结束）和上下文（常规传输完成 vs. 路径切换过程）不同。因此，该特征未被直接公开。隐含公开判断：虽然都有“流结束”字样的标记，但技术内涵和应用场景差异巨大。本领域技术人员无法从“声明整个传输结束”的EOS分组，推理出在“路径切换”场景中用于标记“旧路径传输结束”的特定分组。因此，该特征也未被隐含公开。 |
| **技术特征K**：确定与所述先前路径相关联的分组已被处理。 | 未找到相关描述。 | 该特征与特征J紧密相关，是基于接收“流结束标记分组”后执行的动作。由于对比文件中的EOS分组用于不同目的，且没有路径关联性，因此不会基于它来“确定与先前路径相关联的分组已被处理”。该特征未被公开。 |
| **技术特征L**：其特征在于，所述缓冲与所述经更新路径相关联的分组包括：缓冲与所述经更新路径相关联的分组直至预定缓冲超时时段期满。 | 对比文件说明书[0150]段：“For example, if the time Ta until start of processing of encoded data of a frame relevant to a lost packet is Ta=100 msec, that is, if it is known from timer measurement that data will be passed to the decoder and decoding will start in 100 msec, and if the latest measured RTT is larger than the time Ta until the start of the processing of the encoded data of the relevant frame, that is, if the latest RTT is larger than 100 msec, it is determined that retransmission packets will not be received in time for the start of decoding even if a NACK-RTCP packet, which serves as a retransmission request, is transmitted, and thus a NACK-RTCP packet is not transmitted.” | 对比文件公开了基于定时器测量和时间限制（如处理开始时间Ta、RTT）来决定是否发送重传请求。这涉及一种超时判断机制。但是，该超时机制用于决策是否放弃重传请求，而不是用于控制“缓冲新路径分组”的时长。其技术目的和应用场景（重传决策 vs. 乱序缓冲控制）不同。因此，该特征未被直接公开。隐含公开判断：超时是常见的网络控制机制。但将其应用于“缓冲新路径分组”这一特定场景，需要先存在“路径区分”和“为排序而缓冲”的技术构思。在对比文件未公开这些前提的情况下，本领域技术人员无法直接推理出该特定应用。因此，该特征也未被隐含公开。 |
| **技术特征M**：其特征在于，所述处理取决于与每个收到分组相关联的协议，所述方法进一步包括：对于每个收到分组，检查该收到分组的协议标识符，如果所述协议标识符与可靠递送传输协议相关联，则以所述第一分组和所述第二分组被传送的次序在处理所述第二分组之前处理所述第一分组，如果所述协议标识符与尽力型传输协议相关联，则以每个收到分组被接收的次序来处理每个收到分组。 | 对比文件说明书[0006]-[0008]段比较了RTP（不确保可靠实时传输）和TCP（高可靠但延迟大）的特点，并在[0118]段末尾提到：“Although the above description only deals with lost packets, also when error packets have been detected, a process similar to the case of lost packets is executed, that is, a retransmission request is issued.” 整个发明围绕为RTP这类非可靠协议增加ARQ机制以提高可靠性。 | 对比文件深刻认识到可靠递送协议（如TCP）和尽力型协议（如RTP/UDP）在可靠性与实时性上的差异，并致力于为RTP/UDP增加选择性重传机制以改善其可靠性。这隐含了协议类型会影响接收端处理策略（是否触发重传请求）。然而，目标专利中基于协议类型的不同处理策略，特指在路径切换场景下，对乱序分组采取不同的排序策略：对可靠协议严格保持发送次序，对尽力型协议则按接收次序处理。对比文件关注的是“是否以及何时请求重传以保证数据完整性和实时性”，而目标专利关注的是“是否需要对乱序分组进行重新排序”。两者处理策略所解决的具体问题不同。因此，该特征未被直接公开。隐含公开判断：虽然都涉及根据协议类型采取不同动作，但动作的具体内容和技术目的不同。本领域技术人员无法从“为RTP增加重传机制以提高可靠性”这一技术思想，推理出“在路径切换时，根据协议类型决定是否对乱序分组进行重新排序”的方案。因此，该特征也未被隐含公开。 |
| **技术特征N**：其特征在于，所述确定所述收到分组与所述先前路径还是所述经更新路径相关联包括：对于每个收到分组，确定新路径标志是否被包括于该收到分组中，所述新路径标志指示与所述经更新路径相关联的分组。 | 未找到相关描述。 | 对比文件的分组格式（RTP、RTCP）中未描述任何用于指示“新路径”的标志字段。其分组标识主要依靠序列号、时间戳等。因此，该特征未被直接公开，也无法从现有内容中隐含推导出。 |
| **技术特征O**：其特征在于，所述确定所述收到分组与所述先前路径还是所述经更新路径相关联包括：接收标记分组，所述标记分组包括唯一性地标识与所述先前路径相关联的至少一些分组的分组标识信息，所述至少一些分组是由源设备在从所述先前路径到所述经更新路径的路径更新之前传送的。 | 对比文件说明书[0098]段描述了NACK-RTCP分组的格式（图6），其中包含“designated retransmission-sequence numbers, which serve as identifiers of packets to be retransmitted”。[0100]段：“As shown in FIG. 6, a single NACK packet is allowed to include one or more sequence numbers, which serve as identifiers of one or more packets to be retransmitted.” | 对比文件公开了接收端发送、发送端接收的NACK-RTCP标记分组，其中包含需要重传的分组的序列号（分组标识信息）。然而，该标记分组的作用是请求重传丢失或出错的分组，其标识的信息是“丢失的分组”，而不是“与先前路径相关联的分组”。其技术目的（重传请求 vs. 路径关联性标识）和上下文（丢包检测 vs. 路径切换）完全不同。因此，该特征未被直接公开。隐含公开判断：虽然都涉及“标记分组包含分组标识信息”，但信息的含义和用途南辕北辙。本领域技术人员无法从“用于标识丢失分组以请求重传”的NACK分组，推理出“用于标识旧路径分组以辅助路径区分”的标记分组。因此，该特征也未被隐含公开。 |
| **技术特征P**：其特征在于，所述分组标识信息是分组校验和、分组ID、或分组序列号之一。 | 对比文件说明书[0098]段：“designated retransmission-sequence numbers, which serve as identifiers of packets to be retransmitted”。 | 对比文件公开了使用序列号（sequence numbers）作为分组标识信息。这属于目标专利列举的“分组序列号”范畴。但是，如特征O所述，该序列号在对比文件中用于标识丢失的分组以进行重传，而在目标专利中用于标识与旧路径相关联的分组以进行路径区分。尽管标识符类型相同，但其被赋予的技术含义和所起的作用在各自的技术方案中是特定的、不同的。从“直接公开”的严谨性判断，本领域技术人员不能毫无疑义地从对比文件中得出“序列号用于标识与先前路径相关联的分组”这一技术方案。因此，该特征未被直接公开。然而，从非常宽松的“隐含公开”标准出发，可以认为对比文件“部分公开”了使用“序列号”作为分组标识信息的技术手段。这是一种通用的网络技术手段。尽管应用场景和目的不同，但“使用序列号标识分组”这一技术特征本身被对比文件所记载。因此，可以认为该技术特征被对比文件隐含公开。 |
| **技术特征Q**：其特征在于，所述确定所述收到分组与所述先前路径还是所述经更新路径相关联包括：对于每个收到分组，在接口层IL媒体接入控制MAC第一进入接口处检查与该收到分组相关联的一个或多个MAC协议数据单元PDU的传送地址，其中所述MAC PDU的第一传送地址指示所述先前路径，并且所述MAC PDU的第二传送地址指示所述经更新路径。 | 未找到相关描述。 | 对比文件完全未提及混合网络、接口层（IL）、抽象层（AL）、MAC PDU或利用MAC传送地址（TA）来区分路径。其技术方案基于IP和RTP/RTCP协议栈，操作在更高层。该特征是目标专利针对混合网络底层特性的特定解决方案，在对比文件中没有任何基础或暗示。因此，该特征既未被直接公开，也未被隐含公开。 |
**结论**：根据上述分析，对比文件US7315898B主要涉及基于RTP/RTCP协议的数据传输系统，通过ARQ机制提高流媒体传输的可靠性以支持实时播放。其技术领域、解决的技术问题（丢包与实时性矛盾）、采用的技术手段（基于序列号、时间戳的丢包检测、重传请求与决策、EOS分组）均与目标专利CN104813605B（解决多跳混合网络中因路径切换导致同一接口接收乱序分组的问题，采用流标记和路径区分技术进行排序）有本质区别。
在目标专利的众多技术特征中，仅技术特征P（分组标识信息是分组序列号）所包含的“使用序列号作为分组标识信息”这一非常宽泛和通用的技术手段，被对比文件以不同的应用目的所“部分公开”。根据非常宽松的隐含公开判断标准，可以认为该特征被隐含公开。
<<<p>>>