对比文件名称：2005-12-20_US6977888B_发明授权_US06977888B1 Hybrid ARQ for packet data transmission
目标专利名称：用于多跳混合网络的无缝切换CN104813605B
模型名称：本次调用基于专利创造性评估模型
### 特征比对表格
| 技术特征描述及公开性判断 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：在混合网络中的设备的第一进入接口处接收与分组流相关联的第一分组以及与所述分组流相关联的第二分组，《未直接或隐含公开》 | [0012] In data packet transmissions between a transmitter and a receiver, a data packet includes a first type of bits and second type of bits. [0013] ...When a packet is negatively acknowledged by the receiver, the transmitter retransmits information... | 对比文件公开了在发送端和接收端之间传输数据包，以及当接收端发送否定应答时发送端会重传信息。这涉及接收多个数据包（原始包和重传包）。然而，对比文件描述的是点对点链路上的可靠传输（混合ARQ），其“接收”行为发生在单一的、预设的通信链路上，目的是检错和纠错。而目标专利中的“接收”发生在混合网络设备的“第一进入接口”，且第一分组和第二分组属于同一分组流但因路径更新而可能从不同上游路径抵达同一接口，其背景是多跳网络中的路径切换和乱序问题。两者技术领域、网络架构及所要解决的技术问题均不同。本领域技术人员阅读对比文件后，无法毫无疑义地得出或通过合理推理得到目标专利中在多跳混合网络同一进入接口接收因路径切换而乱序的分组流的技术方案。因此，该技术特征未被直接公开，也未被隐含公开。 |
| **技术特征B**：所述第一分组与路径更新之前使用的先前路径相关联，《未直接或隐含公开》 | 未发现相关描述。 | 对比文件通篇涉及的是通过自动重传请求（ARQ）和混合ARQ（HARQ）机制来保证数据传输的可靠性，其核心是反馈（ACK/NACK/LOST）和重传。文中未提及任何关于“路径更新”、“先前路径”或“多跳网络中选择不同路径”的概念。所有传输和重传均发生在发送端和接收端之间预设的或单一的链路上。因此，对比文件完全没有公开“分组与路径相关联”这一概念，更不用说与“路径更新之前的先前路径”相关联。本领域技术人员无法从对比文件中推理出该技术特征。 |
| **技术特征C**：并且所述第二分组与所述路径更新之后使用的经更新路径相关联，《未直接或隐含公开》 | 未发现相关描述。 | 同上，对比文件未涉及任何路径选择、路径更新或经更新路径的概念。其“重传”是对同一数据包的再次发送，目的是纠正错误或补偿丢失，而不是切换到一条新的网络路径来发送后续数据包。因此，该技术特征未被公开。 |
| **技术特征D**：对于每个收到分组，确定该收到分组与所述先前路径还是所述经更新路径相关联，《未直接或隐含公开》 | [0011] ...the receiver decides if an expected data packet is absent or not... [0015] A decision is made whether a packet is successfully decoded... | 对比文件描述了接收端确定预期数据包是否缺失（absent），以及解码是否成功。其确定的是数据包是否正确接收、是否丢失或是否包含错误，以便决定发送ACK、NACK还是LOST反馈信号。这与目标专利中“确定分组与哪条路径相关联”的目的和作用完全不同。目标专利的确定是为了区分乱序分组的来源路径以进行重新排序，而对比文件的确定是为了触发重传以保证数据正确性。两者技术手段和目的有本质区别。因此，该技术特征未被公开。 |
| **技术特征E**：以所述第一分组和所述第二分组被传送的次序处理所述第一分组和所述第二分组。《未直接或隐含公开》 | [0004] ...When the NACK is received, the sender can retransmit the packet. [0005] ...A NACK signal is sent back to the transmitter if an error is detected... | 对比文件公开了在接收到NACK后，发送端会重传数据包。接收端最终需要按正确的顺序解码数据（例如，通过合并多次传输的比特）。然而，这种“按次序处理”是为了纠正传输错误，确保最终获得正确的数据内容，其背景是单链路上的可靠性保障。而目标专利中的“按传送次序处理”是为了解决因多跳网络路径切换导致的、抵达同一接口的分组乱序问题，确保分组流按源端发送的时间顺序被递交，而不涉及纠正分组内容错误。两者要解决的“次序”问题根源不同（路径切换 vs. 传输错误），技术方案侧重点也不同。因此，不能认为对比文件公开了本技术特征。 |
| **技术特征F**：其特征在于，所述第二分组在所述第一分组之前被接收到，并且所述处理包括缓冲与所述经更新路径相关联的所述第二分组直至与所述先前路径相关联的所述第一分组被处理。《未直接或隐含公开》 | [0006] ...A more efficient hybrid ARQ scheme is to save the erroneously received and negatively acknowledged data packet and then combine it in some way with the retransmission. [0054] The received signal information is actually stored in a combiner buffer 54... | 对比文件公开了在混合ARQ合并方案中，接收端会缓冲错误接收的数据包，以便与后续的重传进行合并解码。这是一种“缓冲”，但其目的是为了通过合并提高解码成功率，纠正当前数据包的错误。而目标专利中的“缓冲”是为了等待来自旧路径的、传送顺序在先但可能延迟到达的分组，以确保分组流按源端发送顺序被处理，而非纠正分组内容。两者的缓冲目的、触发条件（解码错误 vs. 检测到路径切换）和缓冲对象（错误包用于合并 vs. 新路径的正确包用于等待）均不相同。本领域技术人员无法从对比文件的缓冲机制推理出目标专利中用于路径切换排序的缓冲机制。 |
| **技术特征G**：其特征在于，所述处理是在协议栈中比传输层低的层上执行的。《直接公开》 | [0004] ...In a pure ARQ system, the channel code is only used for error detection. [0005] In hybrid ARQ (HARQ), features of a pure FEC scheme and a pure ARQ scheme are combined. Error correction and error detection functions are performed... | 对比文件描述的混合ARQ（HARQ）方案，结合了前向纠错（FEC）和自动重传请求（ARQ）。FEC和ARQ操作通常发生在OSI模型的链路层（数据链路层），该层位于网络层和传输层之下。具体地，对比文件中的信道编码、解码、错误检测、ACK/NACK反馈及重传控制，都是在数据链路层或物理层实现的，属于“协议栈中比传输层低的层”。这与目标专利中为处理路径切换导致的乱序而在较低层（如MAC层）执行处理的作用是类似的，都是在传输层之下处理与数据传输可靠性或顺序相关的控制问题。因此，本领域技术人员能够毫无疑义地从对比文件得出该技术特征。 |
| **技术特征H**：其特征在于，所述处理包括：接收与所述经更新路径相关联的流开始标记分组。《未直接或隐含公开》 | 未发现相关描述。 | 对比文件中没有任何关于“流开始标记分组”（flow start marker packet）或类似概念（如Ms,b）的记载。其使用的控制信号是ACK、NACK、LOST等反馈信号，这些信号是接收端发送给发送端的，用于指示数据包状态，而非由发送端插入数据流中、用于指示新路径开始的标记分组。因此，该技术特征未被公开。 |
| **技术特征I**：响应于接收到所述流开始标记分组，缓冲与所述经更新路径相关联的分组直至与所述先前路径相关联的分组已被处理。《未直接或隐含公开》 | 未发现相关描述。 | 由于对比文件未公开“流开始标记分组”（特征H），因此也就不可能存在“响应于接收到流开始标记分组而进行缓冲”的操作。对比文件中的缓冲是基于解码失败或数据包丢失，而非基于接收到的特定标记分组。因此，该技术特征未被公开。 |
| **技术特征J**：其特征在于，所述处理包括：接收与所述先前路径相关联的流结束标记分组。《未直接或隐含公开》 | 未发现相关描述。 | 对比文件中没有任何关于“流结束标记分组”（flow end marker packet）或类似概念（如Ms,e）的记载。其流程的结束是通过接收端发送ACK信号来指示的。因此，该技术特征未被公开。 |
| **技术特征K**：确定与所述先前路径相关联的分组已被处理。《未直接或隐含公开》 | [0015] ...A decision is made whether a packet is successfully decoded... | 对比文件公开了确定一个数据包是否被成功解码。但这与目标专利中“确定与先前路径相关联的分组已被处理”在含义和作用上不同。目标专利的“处理”指按顺序递交分组流，其“确定”可能是通过收到流结束标记或超时来触发。对比文件的“确定解码成功”是为了结束当前数据包的重传循环。两者确定的对象和目的不同。无法从对比文件推理出目标专利的特征。 |
| **技术特征L**：其特征在于，所述缓冲与所述经更新路径相关联的分组包括：缓冲与所述经更新路径相关联的分组直至预定缓冲超时时段期满。《未直接或隐含公开》 | 未发现相关描述。 | 对比文件未提及任何与“预定缓冲超时时段”相关的技术内容。其缓冲的数据包在成功解码合并后会被清除，但未说明基于超时机制来管理缓冲。因此，该技术特征未被公开。 |
| **技术特征M**：其特征在于，所述处理取决于与每个收到分组相关联的协议，所述方法进一步包括：对于每个收到分组，检查该收到分组的协议标识符，如果所述协议标识符与可靠递送传输协议相关联，则以所述第一分组和所述第二分组被传送的次序在处理所述第二分组之前处理所述第一分组，如果所述协议标识符与尽力型传输协议相关联，则以每个收到分组被接收的次序来处理每个收到分组。《未直接或隐含公开》 | 未发现相关描述。 | 对比文件全文专注于通过混合ARQ机制实现可靠数据传输，未讨论或区分“可靠递送传输协议”（如TCP）和“尽力型传输协议”（如UDP），也未记载根据协议标识符对分组采取不同的排序处理策略。其处理方式（解码、合并、重传）是针对需要可靠传输的数据流设计的。因此，该技术特征未被公开。 |
| **技术特征N**：其特征在于，所述确定所述收到分组与所述先前路径还是所述经更新路径相关联包括：对于每个收到分组，确定新路径标志是否被包括于该收到分组中，所述新路径标志指示与所述经更新路径相关联的分组。《未直接或隐含公开》 | 未发现相关描述。 | 对比文件中没有提及任何用于指示数据包属于“新路径”的标志。其数据包中包含的是用于错误检测和纠正的编码比特（如系统比特、校验比特），以及用于标识数据包的序列信息，但没有用于路径区分的“新路径标志”。因此，该技术特征未被公开。 |
| **技术特征O**：其特征在于，所述确定所述收到分组与所述先前路径还是所述经更新路径相关联包括：接收标记分组，所述标记分组包括唯一性地标识与所述先前路径相关联的至少一些分组的分组标识信息，所述至少一些分组是由源设备在从所述先前路径到所述经更新路径的路径更新之前传送的。《未直接或隐含公开》 | 未发现相关描述。 | 对比文件未公开任何用于路径区分、且包含“分组标识信息”的“标记分组”。其讨论的标记或标识主要用于区分不同的数据包传输尝试（如第一次传输、第二次重传），以便于合并解码，而不是用于标识在路径切换前发送的特定分组。因此，该技术特征未被公开。 |
| **技术特征P**：其特征在于，所述分组标识信息是分组校验和、分组ID、或分组序列号之一。《未直接或隐含公开》 | [0011] Packet identifiers are typically included in data packets to specify the sequence as well as identity of a particular packet. | 对比文件提到数据包中通常包含分组标识符（Packet identifiers）来指定序列和特定分组的身份。这可以理解为分组ID或序列号。然而，这些标识符在对比文件中的作用是用于识别特定数据包以进行ARQ操作（如选择性重传）和组合缓冲区的管理，而不是用于在路径切换场景下唯一性地标识属于旧路径的分组。即，公开了“分组标识信息”的某种形式，但未公开其在目标专利特征O的特定上下文和技术目的（路径区分）中的应用。因此，该技术特征未被直接公开。虽然标识符本身被公开，但将其应用于路径切换场景以区分新旧路径分组，需要本领域技术人员进行创造性的组合和转换，不属于隐含公开的合理推理范围。 |
| **技术特征Q**：其特征在于，所述确定所述收到分组与所述先前路径还是所述经更新路径相关联包括：对于每个收到分组，在接口层IL媒体接入控制MAC第一进入接口处检查与该收到分组相关联的一个或多个MAC协议数据单元PDU的传送地址，其中所述MAC PDU的第一传送地址指示所述先前路径，并且所述MAC PDU的第二传送地址指示所述经更新路径。《未直接或隐含公开》 | 未发现相关描述。 | 对比文件未涉及“接口层（IL）”、“媒体接入控制（MAC）PDU的传送地址”或利用MAC地址来区分不同上游路径的技术内容。其通信模型是抽象的发送端和接收端，未深入到多跳网络中基于MAC地址进行路径溯源的层面。因此，该技术特征未被公开。 |
<<<G>>>