好的，作为一名经验丰富的专利代理师，我将严格遵循您设定的评估规则，对目标专利的权利要求技术特征与对比文件进行严谨、深度的比对分析。
**对比文件名称：** 2015-10-01_US2015282219A_发明申请_US20150282219A1 APPARATUS AND METHOD FOR PROVIDING SERVICE IN COMMUNICATION NETWORK SUPPORTING MULTIPATH TRANSPORT CONTROL PROTOCOL
**目标专利名称：** 1063用于通信系统中的增强型数据分组流处理的方法和装置CN112313991B
**本次调用的模型名称：** 无
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用（翻译） | 公开性论述 |
| **技术特征A：** 包括：由网络实体检测数据分组的两个或更多个流是相关的 <br> **《直接公开》** | **[0123]** 在操作723，TIC服务器713可以使用TCP选项字段的种类选项字段和子类型字段来检测UE 711与原始服务器715之间的连接是否是MPTCP连接。 <br> **[0141]** 在从UE 711接收到MP_JOIN消息时，TIC服务器713可以使用选项字段来确定接收到的MP_JOIN消息是否是MPTCP控制消息。如果接收到的MP_JOIN消息是MPTCP控制消息，则TIC服务器713检测包括在MPTCP分组中的子类型(MP_JOIN)。 | 对比文件中的**TIC服务器（网络实体）** 明确执行了**检测MPTCP连接**的操作。一个MPTCP连接本质上由**两个或更多个相关的子流（数据分组的流）** 构成。通过检测MP_CAPABLE和MP_JOIN等MPTCP特有的控制消息（参见[0123]、[0141]、[0156]），TIC服务器能够识别出多个子流（数据流）归属于同一个MPTCP连接，即这些数据流是“相关的”。这完全对应于目标专利中“检测分组的两个或更多个流是相关的”的技术特征，且作用相同，均为识别流之间的关联性以进行后续处理。因此，技术特征A被对比文件直接公开。 |
| **技术特征B：** 向至少一个较低层通知所述检测到的分组的流是相关的并且向所述至少一个较低层通知所述分组的服务质量(QoS)约束 <br> **《未公开》** | **未明确公开** | 对比文件全文描述了TIC服务器、UE和原始服务器之间的交互，以及TIC服务器如何管理MPTCP连接（如源IP迁移、服务类型决策等）。然而，对比文件的所有操作均集中在应用层和传输层（MPTCP/TCP），其“较低层”指的是MPTCP层之下的IP层（参见图1协议栈）。对比文件完全没有提及TIC服务器向例如3GPP网络中的SDAP、PDCP或RLC等更低层实体通知流的相关性或QoS约束的概念。因此，本领域技术人员无法从对比文件中毫无疑义地得出该技术特征，也无任何信息暗示或引导这一特征。技术特征B未被公开。 |
| **技术特征C：** 指导所述至少一个较低层以确保所述分组的流的等待时间、可用性或可靠性要求中的至少一项被满足。 <br> **《未公开》** | **未明确公开**** | 承上所述，对比文件不涉及向“较低层”的指导和配置。对比文件中TIC服务器通过管理子流的创建和删除（如[0148]-[0161]的源IP迁移，[0163]-[0175]的服务类型决策）来影响数据传输路径，但这是在上层（传输/应用层）完成的。它并没有将任何关于如何在空口或下层进行调度以确保等待时间、可用性或可靠性等特定QoS要求的指导信息传递给更低层的实体。因此，本领域技术人员无法从对比文件中得出该技术特征。技术特征C未被公开。 |
| **技术特征D：** 其中所述相关的分组的流包括冗余分组。 <br> **《隐含公开》** | **[0010]** MPTCP具有获取流量工程效益的好处，并且适用于为诸如IP语音(VoIP)、IP电视(IPTV)游戏等具有相对较大用户请求的服务提供可靠性。 <br> **[0066]** 另一方面，在MPTCP中，用于一个应用的数据通过源节点和目的节点之间的多个TCP会话进行发送和接收，这提高了数据通信的可靠性和效率。 | 对比文件明确提到使用MPTCP的目的之一是为了**提供可靠性**（[0010]），并通过**多个子流（即多个流）** 传输数据以提高可靠性（[0066]）。在MPTCP中，将数据通过多个路径（子流）进行复制或分割传输是提高可靠性的常用机制。虽然对比文件没有直接使用“冗余分组”一词，但本领域技术人员根据公知常识和对比文件的上下文（强调MPTCP用于提高可靠性，并通过多子流实现），可以合理推断出这些相关的流（子流）中被传输的数据分组，完全可能是为了可靠性而进行的冗余复制，即这些流包含了冗余分组。因此，技术特征D被对比文件隐含公开。 |
| **技术特征E：** 其中所述检测包括确定所述分组的流是否是用于互联网协议(IP)/以太网流的冗余分组。 <br> **《隐含公开》** | **[0085]-[0089]** 图4描述了MPTCP连接建立过程，包括MP_CAPABLE和MP_JOIN消息的交换。 <br> **[0123]** 在操作723，TIC服务器713可以使用TCP选项字段的种类选项字段和子类型字段来检测UE 711与原始服务器715之间的连接是否是MPTCP连接。 | 对比文件中的TIC服务器通过检测MPTCP特有的控制消息（如MP_CAPABLE、MP_JOIN）来检测一个连接是否为MPTCP连接。MPTCP连接的本质特征之一就是能够通过多个子流（IP流）进行数据传输，这些子流可以用于冗余传输。本领域技术人员知晓，MPTCP协议的一个核心应用场景就是进行冗余传输以增强可靠性。因此，当TIC服务器检测到一个连接是MPTCP连接时，它隐含地确定该连接可能用于（或配置为用于）通过多个IP流进行冗余分组传输。尽管对比文件未明示“确定是否是冗余分组”，但结合MPTCP协议的本质和对比文件上下文，可以合理推断出该检测动作包含了识别可能用于冗余传输的MPTCP流的意图。因此，技术特征E被对比文件隐含公开。 |
| **技术特征F：** 其中所述检测包括以下至少一项：将所述分组的相关子流彼此相关联 <br> **《直接公开》** | **[0085]-[0089]** 主机A 411使用IP地址A1与主机B 413建立MPTCP连接。... 主机A 411可以生成使用IP地址A2的第二子流。... 主机A 411向主机B 413发送MP_JOIN消息（SYN: MP_JOIN [Token-B, ID-A2]）。这里，Token-B表示生成的子流将被添加到的MPTCP连接的令牌标识符（ID）。 <br> **[0141]** 在从UE 711接收到MP_JOIN消息时，... TIC服务器713确定包含在MP_JOIN消息中的令牌是否是TIC服务器713中存在的MPTCP连接的ID。 | 对比文件详细描述了MPTCP通过**令牌（Token）** 将一个新的子流（sub-flow）关联到一个已经存在的MPTCP连接上的过程（[0089]）。TIC服务器在执行缓存业务时，正是通过检测MP_JOIN消息中的令牌是否与自身维护的MPTCP连接ID匹配，来将新到达的子流与现有的相关子流进行关联（[0141]）。这个过程就是“将分组的相关子流彼此相关联”。因此，技术特征F被对比文件直接公开。 |
| **技术特征G：** 检查所述分组的流中的至少一个分组或者从外部系统接收信息以检测所述分组的至少两个子流正在传输相关数据。 <br> **《直接公开》** | **[0123]** 在操作723，TIC服务器713可以使用TCP选项字段的种类选项字段和子类型字段来检测UE 711与原始服务器715之间的连接是否是MPTCP连接。 <br> **[0156]** TIC服务器913可以检测到MP_JOIN消息是MPTCP控制消息。在这种情况下，TIC服务器913可以使用TCP选项字段的种类选项字段和子类型字段来检测UE 911与原始服务器915之间的连接是MPTCP连接。 | 对比文件明确公开了TIC服务器通过**检查分组**（即MP_JOIN或MP_CAPABLE消息）的TCP选项字段（Kind和Subtype）来检测一个连接是否为MPTCP连接。一旦识别为MPTCP连接，即意味着该连接包含至少两个子流（[0066]），且这些子流传输的是与同一个应用相关的数据。此外，虽然未明确，但TIC服务器与外部系统（如UE，通过MPTCP控制信令）的信息交换也是其获取信息的方式之一。因此，通过检查分组来检测多个子流传输相关数据这一特征被对比文件明确公开。技术特征G被直接公开。 |
| **技术特征H：** 其中所述指导包括向所述至少一个较低层转发所述检测到的分组的流以及指示所述至少一个较低层将所述分组视为不相关的添加的指示或报头。 <br> **《未公开》** | **未明确公开** | 对比文件涉及TIC服务器对MPTCP数据流的处理，但未涉及将流相关信息转发给“较低层”（如3GPP协议栈的SDAP、PDCP等），更没有教导在这些较低层添加指示或报头以指导其将分组视为不相关。对比文件中的TIC服务器自身就是一个中间网络节点，它处理的是传输层及以上的逻辑，其决策（如是否缓存、是否进行源IP迁移）不涉及对下层协议的配置指令。因此，技术特征H未被公开。 |
| **技术特征I：** 其中所述指导包括操纵所述分组的报头或控制信息以确保所述至少一个较低层将所述分组视为不相关。 <br> **《未公开》** | **[0134]-[0136]** TIC服务器713使用原始服务器715的IP地址提供服务... 然而，由于UE 711使用原始服务器715的IP地址发送MP_JOIN消息，因此需要将用于提供服务的IP地址更改为TIC服务器713的IP地址。... 源IP地址迁移方案使用...MP_JOIN操作和REMOVE_ADDR操作。 | 对比文件确实存在“操纵”分组报头（IP地址）的操作，即“源IP地址迁移”（[0134]-[0136]）。但这种操纵是为了让TIC服务器能接管数据传输，并维持对UE的透明性，其目的和对象（IP层报头）与目标专利中“指导较低层”完全不同。目标专利的“操纵报头”目的是为了确保**较低层**（如SDAP）能够**将分组视为不相关**，从而进行差异化调度。对比文件没有提及任何关于较低层的概念，其操纵IP地址的动作完全是上层逻辑，与指导下层无关。因此，技术特征I未被公开。 |
| **技术特征J：** 还包括标识针对所述分组需要被满足的所述服务质量(QoS)约束。 <br> **《未公开》** | **[0143]** TIC服务器713基于UE 711的订阅信息确定是使用多路径（即通过WiFi网络和蜂窝网络）向UE 711提供服务，还是通过WiFi网络执行流量卸载操作。 | 对比文件提到了基于**订阅信息（subscription information）** 来决定服务类型（多路径或卸载），这可以看作是一种粗略的服务等级区分。但是，对比文件没有明确“标识”或“确定”具体的、可量化的QoS约束（如等待时间、可用性、可靠性指标）。更关键的是，目标专利中的“QoS约束”是后续指导较低层（如SDAP）满足特定要求的依据。对比文件中的决策是基于用户等级的业务策略，其作用和上下文与目标专利完全不同。对比文件也未公开如何从外部系统获取或推断QoS约束。因此，技术特征J未被公开。 |
| **技术特征K：** 其中所述指导还包括仅将所述分组的子集转发给所述至少一个较低层并且缩放要由所述至少一个较低层满足的所述服务质量(QoS)约束。 <br> **《未公开》** | **未明确公开** | 对比文件完全没有公开将分组的**子集**转发给**较低层**，更没有公开**缩放QoS约束**的概念。对比文件中TIC服务器可能会在收到缓存命中后，减少向原始服务器的请求（例如不再请求全部数据），但这与向“较低层”转发分组子集完全不同。目标专利中的“缩放QoS约束”是一种智能的流处理策略，旨在优化资源利用，对比文件未涉及任何类似的技术构思。因此，技术特征K未被公开。 |
| **技术特征L：** 其中所述网络实体包括附接到用户平面功能的数据分组复制管理器。 <br> **《未公开》** | **未明确公开** | 对比文件中的网络实体是**TIC服务器**，其功能是内容缓存和转发，位于运营商网络内部，用于优化视频流量。目标专利中的网络实体是**复制管理器（RM）**，其核心功能是检测和处理复制数据流，并且明确指出RM是**附接到用户平面功能（UPF）** 的。这两个实体在功能、架构位置和作用上存在本质区别。对比文件没有描述TIC服务器与UPF的关系，也没有“复制管理器”的概念。因此，技术特征L未被公开。 |
---
### 结论
根据上述严谨的对比分析，对比文件公开了技术特征A、F、G，隐含公开了技术特征D、E，但未公开技术特征B、C、H、I、J、K、L。
<<<A>>><<<F>>><<<G>>><<<d>>><<<e>>>