对比文件名称：2012-07-05_US2012173748A_发明申请_US20120173748A1 HYBRID TRANSPORT-LAYER PROTOCOL MEDIA STREAMING
目标专利名称：用于多跳混合网络的无缝切换CN104813605B
本次调用的模型名称：专利创造性评估模型
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：在混合网络中的设备的第一进入接口处接收与分组流相关联的第一分组以及与所述分组流相关联的第二分组。<br>**《隐含公开》** | “...the client causing receipt of the first portion of the media data transmitted to the client over the first transport-layer protocol, and receipt of the second portion of the media data transmitted to the client over the second transport-layer protocol.” (说明书摘要， [0004]段) | 对比文件公开了客户端（作为接收设备）通过第一传输层协议（如TCP）接收媒体数据的第一部分，并通过第二传输层协议（如UDP）接收媒体数据的第二部分（[0004]， [0055]段）。这相当于在客户端设备处接收与同一媒体流相关联但经由不同传输协议（可视为不同逻辑“路径”）传送的分组。虽然未明确提及“第一进入接口”，但本领域技术人员能够理解，对于支持多协议的网络设备，来自不同协议的数据流可以通过同一物理或逻辑接口（如网络接口卡）进入设备并由协议栈进行处理。因此，对比文件隐含公开了技术特征A。 |
| **技术特征B**：所述第一分组与路径更新之前使用的先前路径相关联。<br>**《隐含公开》** | “...the server partitioning the media data into the first and second portions... delivery of the first portion of the media data to the client over a first transport-layer protocol such as the Transmission Control Protocol (TCP)...” (说明书摘要， [0004]段) | 对比文件公开了服务器将媒体数据划分为第一部分和第二部分，并通过TCP等第一传输层协议传输第一部分（[0004]段）。在会话建立时，服务器选择通过TCP传输第一部分数据。如果后续网络条件变化（如可用带宽降低），服务器可调整传输策略（例如减少UDP流量），这可以被视为一种“路径更新”（即，改变了用于传输第二部分的“路径”或传输协议的比例/选择）。那么，在更新之前，通过TCP传输的第一部分分组就与“先前路径”（即TCP传输路径）相关联。对比文件隐含了这种基于网络状况调整传输路径/协议的场景。 |
| **技术特征C**：并且所述第二分组与所述路径更新之后使用的经更新路径相关联。<br>**《隐含公开》** | “...delivery of a second, different portion of the media data to the client over a second, different transport-layer protocol such as User Datagram Protocol (UDP)...” (说明书摘要， [0004]段)； “In instances in which the server discovers that the available bandwidth drops, the server... may respond by reducing the amount of data delivered over UDP.” ([0064]段) | 对比文件明确公开了通过UDP等第二传输层协议传输第二部分数据（[0004]段）。同时，对比文件描述了服务器可以根据TCP吞吐量或客户端缓冲状态，动态控制通过UDP传输的数据量或速率（[0055]， [0062]-[0064]段）。当服务器基于反馈（如带宽下降）决定减少UDP流量时，这相当于执行了一次“路径更新”（调整了UDP这条“路径”的传输行为）。那么，在更新决定之后，通过UDP传输的第二部分分组就与“经更新路径”（即调整后的UDP传输路径）相关联。 |
| **技术特征D**：对于每个收到分组，确定该收到分组与所述先前路径还是所述经更新路径相关联。<br>**《隐含公开》** | “The client receives the first and second portions of the media data in an at least partially overlapping or even synchronous manner.” ([0004]段)；“...the server may deliver a first portion of data including more important or higher priority data units over TCP... The server may further deliver a second portion of data including less important or lower priority data units over UDP.” ([0056]段) | 对比文件公开了客户端同时或重叠地接收通过TCP和UDP传输的数据部分（[0004]段）。为了使媒体能够正确解码和播放，客户端必须能够区分哪些数据单元（分组）是通过TCP接收的（高优先级，如基本层），哪些是通过UDP接收的（低优先级，如增强层）。这种区分是基于传输层协议（TCP vs UDP）以及可能的应用层封装（如RTP over UDP vs HTTP over TCP）来实现的。本领域技术人员可以毫无疑义地推断，客户端需要对每个收到的分组进行检查（例如，检查传输层报头中的协议字段或端口号），以确定其属于TCP流还是UDP流，从而确定其关联的“路径”。因此，该特征被隐含公开。 |
| **技术特征E**：以所述第一分组和所述第二分组被传送的次序处理所述第一分组和所述第二分组。<br>**《隐含公开》** | “TCP offers a reliable protocol where data is delivered error free, in-order and without duplicates. The error-free delivery may be guaranteed by using acknowledgement and retransmission of lost packets. In-order delivery may be ensured through re-arranging out-of-order packets based on their sequence numbers.” ([0048]段) | 对比文件详细描述了TCP协议提供可靠、按序的交付（[0048]段）。对于通过TCP传输的第一部分（高优先级数据），客户端侧的TCP协议栈会负责将可能乱序到达的分组重新排序，确保按发送顺序提交给应用层。对于通过UDP传输的第二部分，虽然UDP本身不保证顺序，但为了媒体同步播放，客户端应用层（或使用RTP时）通常也需要根据时间戳等信息对数据单元进行排序处理。因此，对比文件公开了客户端需要按照数据单元被编码/发送的次序来处理从两条“路径”接收到的分组，以确保媒体流的正确再现。 |
| **技术特征F**：其特征在于，所述第二分组在所述第一分组之前被接收到，并且所述处理包括缓冲与所述经更新路径相关联的所述第二分组直至与所述先前路径相关联的所述第一分组被处理。<br>**《隐含公开》** | “...the client may continuously measure an amount of media data received over TCP and buffered for use at the client. In instances in which the amount of buffered data drops below a certain threshold, the client may send the server a notification... to thereby notify the server to reduce the amount of media data delivered over UDP.” ([0062]段) | 对比文件公开了客户端会缓冲从TCP接收的数据，并监控缓冲状态（[0062]段）。当TCP缓冲量低时（可能意味着TCP传输延迟大或吞吐量下降），客户端会通知服务器减少UDP流量。这种机制隐含了当高优先级（TCP路径）的数据处理可能跟不上时，需要控制低优先级（UDP路径）数据的输入，以避免后者占用过多资源或导致播放问题。虽然对比文件是通过通知源端（服务器）来限制UDP发送速率，而非在接收端直接缓冲UDP分组，但两者都是为了解决不同优先级/不同路径数据到达和处理速率不匹配的问题，其技术思想本质相同。本领域技术人员可以合理推断，在接收端设置缓冲来暂存UDP数据直至TCP数据被处理，是实现类似控制效果的另一种可行手段。因此，该特征被隐含公开。 |
| **技术特征G**：其特征在于，所述处理是在协议栈中比传输层低的层上执行的。<br>**《未公开》** | 无对应内容。 | 对比文件描述的处理（如区分TCP/UDP流、基于缓冲状态控制UDP流量、媒体解码播放）主要发生在传输层及以上（应用层、表示层等），例如通过检查传输层协议标识符、应用层会话描述（SDP）或媒体时间戳。目标专利强调在“比传输层低的层”（如网络层、链路层、MAC层）执行路径区分和重新排序，以实现更低延迟、更底层的无缝切换。对比文件完全没有涉及在传输层以下进行此类操作，其技术方案和应用场景（媒体流自适应传输）与目标专利（多跳混合网络路径切换）有本质区别。因此，该特征未被公开。 |
| **技术特征H**：其特征在于，所述处理包括：接收与所述经更新路径相关联的流开始标记分组。<br>**《未公开》** | 无对应内容。 | 对比文件描述路径/协议切换或调整是基于网络测量（吞吐量）或缓冲状态反馈动态进行的，并没有使用任何显式的“流开始标记分组”或“流结束标记分组”来通知接收端路径切换事件。其控制信息是通过专门的反馈信道（控制通道）或嵌入在协议交互（如SDP描述更新）中传递的，而非作为标记分组插入到数据流中。因此，该特征未被公开。 |
| **技术特征I**：响应于接收到所述流开始标记分组，缓冲与所述经更新路径相关联的分组直至与所述先前路径相关联的分组已被处理。<br>**《未公开》** | 无对应内容。 | 该特征依赖于技术特征H中的“流开始标记分组”。由于对比文件未公开使用此类标记分组，因此也不存在基于标记分组触发缓冲的机制。其流量控制机制是基于持续监控和反馈的，而非由离散的标记事件触发。因此，该特征未被公开。 |
| **技术特征J**：其特征在于，所述处理包括：接收与所述先前路径相关联的流结束标记分组。<br>**《未公开》** | 无对应内容。 | 同技术特征H，对比文件未使用“流结束标记分组”。因此，该特征未被公开。 |
| **技术特征K**：确定与所述先前路径相关联的分组已被处理。<br>**《隐含公开》** | “...the client may continuously measure an amount of media data received over TCP and buffered for use at the client.” ([0062]段) | 对比文件公开了客户端持续测量从TCP接收并缓冲的媒体数据量（[0062]段）。通过监控TCP缓冲区的状态（例如，剩余播放时间），客户端可以确定来自TCP路径（先前路径）的数据是否已被充分处理（消耗），从而决定是否需要调整UDP路径的流量。这隐含了客户端有能力确定与特定路径（TCP）相关联的分组的处理状态。虽然其目的主要用于拥塞控制而非严格的顺序保证，但“确定分组已被处理”的功能已被隐含公开。 |
| **技术特征L**：其特征在于，所述缓冲与所述经更新路径相关联的分组包括：缓冲与所述经更新路径相关联的分组直至预定缓冲超时时段期满。<br>**《未公开》** | 无对应内容。 | 对比文件提到了基于缓冲阈值进行控制（[0062]段），但未提及“预定缓冲超时时段”。其控制机制是基于缓冲量的实时测量与阈值比较，而非基于时间超时。目标专利中超时机制用于防止因标记分组丢失等原因导致的无限期等待，是对缓冲策略的补充。对比文件未公开此特定机制。 |
| **技术特征M**：其特征在于，所述处理取决于与每个收到分组相关联的协议，所述方法进一步包括：对于每个收到分组，检查该收到分组的协议标识符，如果所述协议标识符与可靠递送传输协议相关联，则以所述第一分组和所述第二分组被传送的次序在处理所述第二分组之前处理所述第一分组，如果所述协议标识符与尽力型传输协议相关联，则以每个收到分组被接收的次序来处理每个收到分组。<br>**《直接公开》** | “...delivery of a first portion of the media data to the client over a first transport-layer protocol such as the Transmission Control Protocol (TCP), and delivery of a second, different portion of the media data to the client over a second, different transport-layer protocol such as User Datagram Protocol (UDP)...” (说明书摘要， [0004]段)； “TCP offers a reliable protocol where data is delivered error free, in-order...” ([0048]段)； “UDP... may not provide reliable transport as UDP generally lacks sequence numbering, in-order delivery...” ([0050]段) | 对比文件明确区分了两种传输协议：可靠的TCP（用于高优先级数据）和尽力的UDP（用于低优先级数据）（[0004]段）。它明确指出TCP保证按序交付（[0048]段），而UDP不保证顺序（[0050]段）。因此，客户端在处理分组时，对于通过TCP（可靠协议）接收的分组，必须（由TCP协议栈）确保按发送顺序处理；而对于通过UDP（尽力型协议）接收的分组，则按照接收顺序（或依赖应用层时序信息）处理。这直接公开了根据协议标识符（隐含在分组报头中）来决定处理次序的技术特征。 |
| **技术特征N**：其特征在于，所述确定所述收到分组与所述先前路径还是所述经更新路径相关联包括：对于每个收到分组，确定新路径标志是否被包括于该收到分组中，所述新路径标志指示与所述经更新路径相关联的分组。<br>**《未公开》** | 无对应内容。 | 对比文件中区分路径（TCP vs UDP）是基于传输层协议本身，而非在分组内设置一个显式的“新路径标志”。分组属于哪条“路径”由其使用的传输协议（TCP或UDP）以及可能的目的端口号决定。因此，该特征未被公开。 |
| **技术特征O**：其特征在于，所述确定所述收到分组与所述先前路径还是所述经更新路径相关联包括：接收标记分组，所述标记分组包括唯一性地标识与所述先前路径相关联的至少一些分组的分组标识信息，所述至少一些分组是由源设备在从所述先前路径到所述经更新路径的路径更新之前传送的。<br>**《未公开》** | 无对应内容。 | 对比文件没有使用“标记分组”来携带“分组标识信息”以帮助区分路径。其路径区分依赖于协议类型，且其路径调整是基于网络状况的反馈控制，不需要标识在特定时间点之前发送的特定分组。因此，该特征未被公开。 |
| **技术特征P**：其特征在于，所述分组标识信息是分组校验和、分组ID、或分组序列号之一。<br>**《未公开》** | 无对应内容。 | 该特征是对技术特征O中“分组标识信息”的具体化。由于技术特征O未被公开，且对比文件中也没有提及使用校验和、ID或序列号来标识属于特定路径的分组，因此该特征未被公开。 |
| **技术特征Q**：其特征在于，所述确定所述收到分组与所述先前路径还是所述经更新路径相关联包括：对于每个收到分组，在接口层IL媒体接入控制MAC第一进入接口处检查与该收到分组相关联的一个或多个MAC协议数据单元PDU的传送地址，其中所述MAC PDU的第一传送地址指示所述先前路径，并且所述MAC PDU的第二传送地址指示所述经更新路径。<br>**《未公开》** | 无对应内容。 | 对比文件描述的技术方案工作在传输层及以上，关注的是端到端的传输协议选择（TCP/UDP）和应用层适配。它完全没有涉及在接口层（IL）或MAC层检查MAC PDU的传送地址（TA）来区分路径。目标专利此特征针对的是多跳混合网络（如IEEE 1905.1）中，分组可能经由不同中继设备但最终从同一接口进入目的地设备的具体场景。对比文件的场景（客户端-服务器媒体流）和技术层次均不涉及此底层网络拓扑和地址信息。因此，该特征未被公开。 |
<<<a>>><<<b>>><<<c>>><<<d>>><<<e>>><<<f>>><<<k>>><<<m>>>