好的，作为一名资深专利代理师，我将对您的评估请求进行严谨、专业的分析。在开始之前，我首先明确本次评估的相关信息：
* **对比文件名称：** 2017-11-02_US2017317894A_发明申请_US20170317894A1 METHOD AND APPARATUS FOR COMMUNICATION NETWORK QUALITY OF SERVICE CAPABILITY EXPOSURE
* **目标专利名称：** 1108处理应用的业务的方法和网络功能实体CN111373715B
* **本次调用的模型名称：** 深度思考 (Deep Reasoning)
下面，我将根据目标专利的权利要求划分的技术特征，逐一与对比文件进行比对分析，并创建特征比对表格。
### 特征比对表格
| 技术特征描述及公开性判断 | 对比文件原文引用 (翻译) | 公开性论述 |
| **技术特征A：** 从应用功能AF(135)接收(301，405，407，505，508，510，602，801)用于所述应用(201)的多个候选位置(200a，200b)以及针对所述多个候选位置(200a，200b)中的每一个候选位置的用于所述应用(201)的业务路由信息<br><br>**《未公开》** | 对比文件[0027] 图6E：在步骤410，应用服务器230向无线网络的元件提交请求，以暴露正在进行的服务/流的网络信息和当前网络能力。该请求可以是从应用服务器230上的应用功能到NEF 144或PCF 148。 <br> 对比文件[0027] 图6E：在步骤415，该元件存储流和服务信息（即在数据库中），并用UE移动上下文、分配的QoS参数以及针对同一服务的各个流的可能QoS标签（优先级级别）来响应应用服务器230。 | 对比文件公开了AF（应用服务器）向网络功能（NEF/PCF）请求并接收网络能力信息（如QoS参数、UE上下文）。然而，该请求和响应的核心内容是**网络能力和QoS参数**，并非目标专利所定义的“用于应用的多个候选位置”及其对应的“业务路由信息”。目标专利中的“候选位置”是应用的可选部署点（如DNAI列表），“业务路由信息”是用于将业务从UPF引导至该位置的路径规则。对比文件虽然涉及业务流的管理，但其重点在于**QoS能力的协商和暴露**，而非向SMF提供一组可选的、用于应用业务引导的“位置-路由”信息对。因此，对比文件没有公开本技术特征。 |
| **技术特征B：** 其中，所述应用(201)的业务最初被引导到初始选择的候选位置<br><br>**《未公开》** | 对比文件[0089] 图8A：一个UE正在与网络202通信，所有数据包都通过网络202发送。<br>对比文件[0153] 图14A的步骤1201：为UE建立数据会话。该设置过程配置了UE与网络节点之间的用户面流量管理方式。 | 对比文件描述了UE与网络建立数据会话，并传输业务。然而，它并未明确、单独地定义或公开“应用的业务最初被引导到初始选择的候选位置”这一概念。对比文件中，业务流的路径是由会话建立时的策略和网络功能（如UPF选择）决定的，但未将此过程中的业务路径视为相对于后续“重定位”的、具有特定“初始选择”意义的候选位置。目标专利中的“初始选择的候选位置”是SMF从AF提供的多个候选位置中进行“初始选择”的结果，而对比文件中不存在AF提供“多个候选位置”这一前提，因此也不存在基于此的“初始选择”。故未公开。 |
| **技术特征C：** 在没有接收到相反的指示时，确定(302，409，512，603，604，704，802)所述SMF(108)被允许将所述应用(201)的业务引导到所述多个候选位置中的重新选择的候选位置<br><br>**《未公开》** | 对比文件[0198] 图14C的步骤1272：CP功能140处理QoE报告并调整QoS参数。<br>对比文件[0200] 图14C的步骤1274和1276：如果流的QoS参数发生改变，CP功能140向UP功能和AN 128发送QoS更新消息。 | 对比文件中的SMF或PCF可以根据QoE报告和网络条件调整QoS策略和UPF配置。然而，这种调整是基于网络侧的分析和策略，并非基于“在没有接收到相反的指示时”这一条件。对比文件没有定义“相反的指示”这一概念，也没有定义SMF的“被允许”状态是基于是否收到此类指示。目标专利中SMF的这种自主决定权是独立于AF的明确许可的，而对比文件中网络功能的动作始终受限于从AF/PCF接收到的策略和请求。因此，本特征的逻辑前提和判定机制在对比文件中均未公开。 |
| **技术特征D：** 在从所述AF(135)接收的所述多个候选位置(200a，200b)中重新选择(303，409，512，603，604，704，803)所述多个候选位置(200a，200b)中的一个候选位置<br><br>**《未公开》** | 对比文件[0023] 图6E的步骤420：外部应用服务器230可以将QoS标签应用于流和服务的包。在一个方面，外部应用服务器230可以重新选择传输协议和传输协议参数以匹配接收到的移动性上下文。<br>对比文件[0124] 图6F的步骤445：外部应用服务器230响应于接收到的更新，可以选择一个新的存在点（例如，新的移动边缘计算应用服务器）来向UE 2 240发送数据流。 | 对比文件公开了应用服务器（AF）可以根据网络信息自行“重新选择”传输协议或“新的存在点”（应用服务器实例）。但此处的“重新选择”是由**AF执行**的，其选择的对象是“传输协议”或“一个新的应用服务器”。这与目标专利中由**SMF执行**，从**AF预先提供的一组候选位置**中进行“重新选择”完全不同。对比文件中不存在SMF在AF提供的多个位置中进行选择的技术方案。因此，本特征的核心动作和执行主体在对比文件中均未公开。 |
| **技术特征E：** 通过将所述应用(201)的业务从所述初始选择的候选位置重定位到重新选择的候选位置，将所述业务引导(304，409，512，609，804)到所述重新选择的候选位置(200a，200b)<br><br>**《未公开》** | 对比文件[0127] 图7的步骤506：无线CP功能，如SMF 149，可以请求应用服务器将业务转发到新的UPF功能。<br>对比文件[0127] 图7的步骤510：CP功能，如SMF 149，可以重新选择新的UPF来提供UP连接。<br>对比文件[0124] 图6F的步骤445：外部应用服务器230...可以选择一个新的存在点（例如，新的移动边缘计算应用服务器）来向UE 2 240发送数据流。 | 对比文件描述了SMF可以“重新选择新的UPF”或将业务“转发到新的UPF功能”，以及AF可以“选择一个新的存在点”。这些动作都涉及业务的路径改变或重定位。然而，目标专利中的重定位有一个明确的前提：业务是从“初始选择的候选位置”重定位到“重新选择的候选位置”，这两个位置都来自于AF提供的“多个候选位置”。对比文件中的重定位触发条件多样（如网络条件变化），且新路径的选择并非基于AF预先提供的、与候选位置绑定的业务路由信息。因此，对比文件未公开这种特定模式下的重定位引导过程。 |
| **技术特征F：** 其中，当已经从所述AF(135)接收到所述SMF(108)被允许引导业务的指示时，确定所述SMF(108)被允许将所述应用(201)的业务引导到所述多个候选位置中的重新选择的候选位置<br><br>**《未公开》** | 对比文件[0023] 图6E的步骤410: 应用服务器230提交请求以暴露网络信息...<br>对比文件[0108] 图7的步骤506: 无线CP功能，如SMF，可以请求应用服务器将业务转发到新的UPF功能。这暗示需要AF的参与或请求。 | 本特征明确了SMF被允许是基于从AF接收到的一个**明确指示**。这与特征C的“无相反指示”不同，是正向的授权。对比文件中，SMF的动作（如UPF重选）通常是基于网络策略、条件变化或响应AF的请求，而非基于AF发出的一个抽象的“允许引导业务的指示”。对比文件中的AF与网络交互模式是“请求-响应”或“订阅-通知”，并未定义AF向SMF发送一个“允许你自主决定”的授权指示。因此，未公开。 |
| **技术特征G：** 其中，所述指示指明所述应用(201)是无状态的；并且中，无状态的应用(201)允许所述SMF(108)将所述应用(201)的业务引导到所述重新选择的候选位置(200a，200b)<br><br>**《未公开》** | 对比文件[0098] 图6C的步骤340：应用功能...可以基于网络能力信息为数据流选择一种合适的传输协议和协议参数。<br>对比文件[0124] 图6F的步骤445：外部应用服务器230响应于接收到的更新，可以选择一个新的存在点（例如，新的移动边缘计算应用服务器）来向UE 2 240发送数据流。 | 对比文件讨论了应用服务器根据网络信息选择新的存在点，这隐含了应用可能能够在不同实例间切换。但对比文件完全没有将“应用是无状态的”作为一个**指示信息**从AF发送给SMF，并以此作为**允许SMF自主引导业务的理由**。目标专利明确将“无状态”作为SMF获得自主权的一个关键判断依据。对比文件中，业务重定位或应用实例切换的决策主体是AF，而不是SMF。因此，本特征的逻辑链条在对比文件中完全不成立。 |
| **技术特征H：** 其中，所述多个候选位置(200a，200b)、业务路由信息和所述指示在一个消息中被一起接收<br><br>**《未公开》** | 对比文件[0096] 图6C的步骤332：NEF 144可以从应用服务器135，230上的应用功能接收网络能力请求消息。<br>对比文件[0023] 图6E的步骤410：应用服务器230提交请求...<br>对比文件[0023] 图6E的步骤415：...用UE移动上下文、分配的QoS参数以及可能的QoS标签来响应应用服务器230。 | 对比文件中的信息交互是分步的、请求-响应式的。AF先发送请求，网络再返回信息。并未公开AF将“多个候选位置”、“业务路由信息”和“指示”这三类信息作为一个组合，在一个单一消息中提供给网络节点。综合前述分析，由于对比文件未公开组成该消息的任何一个核心要素（多个候选位置、对应的业务路由信息、允许指示），更不可能公开它们在一个消息中“一起接收”这一具体方式。 |
| **技术特征I：** 还包括：<br>**技术特征J：** 在业务引导已经被执行之后，移除(717，805)处理与旧位置(200a)相关联的业务路径的网络功能<br><br>**《未公开》** | 对比文件[0112] 图6F的步骤450：网络202可以选择一种合适的数据包处理程序来匹配新的传输协议、参数和QoS要求。<br>对比文件[0153] 图14A的步骤1206a/1206b：UP功能执行QoS策略并在需要时进行流量整形。AN执行QoS策略并在需要时进行流量整形。 | 对比文件描述了网络功能根据新配置调整处理程序，但并未明确公开在“业务引导已被执行之后”，主动“移除处理与旧位置相关联的业务路径的网络功能”这一步骤。对比文件侧重于配置的更新和资源的重新分配，而非旧路径的清理和旧网络功能的移除。目标专利的这一步骤强调了SMF在自主完成业务引导后，无需等待AF确认即可立即清理旧路径，以优化网络资源，这是其发明点之一，在对比文件中未体现。 |
| **技术特征K：** 还包括：<br>**技术特征L：** 当已经执行了所述确定时，存储(410，513，806)所述多个候选位置(200a，200b)和所述业务路由信息<br><br>**《未公开》** | 对比文件[0023] 图6E的步骤415：该元件存储流和服务信息（即在数据库中），并用UE移动上下文、分配的QoS参数以及可能的QoS标签（优先级级别）来响应应用服务器230。 | 对比文件确实公开了网络元件可以“存储流和服务信息”。但是，所存储的信息是“UE移动上下文、分配的QoS参数”等，而非目标专利中定义的“多个候选位置”和“业务路由信息”。由于对比文件从未公开过SMF会接收到这些信息，因此也就不可能公开在确定被允许后“存储”这些特定信息的步骤。存储的内容和前提均未公开。 |
| **技术特征M：** 其中，所述多个候选位置(200a，200b)采用数据网络接入标识符DNAI的列表的形式<br><br>**《未公开》** | 对比文件[0099] 图6C的步骤340：应用功能...可以基于网络能力信息为数据流选择一种合适的传输协议和协议参数。<br>对比文件[0124] 图6F的步骤445：外部应用服务器230...可以选择一个新的存在点（例如，新的移动边缘计算应用服务器）。 | 对比文件使用了“新的存在点”、“应用服务器”来描述应用的位置。虽然“存在点”概念上接近“位置”，但对比文件全文未提及3GPP 5G架构中定义的特定术语“数据网络接入标识符(DNAI)”，更没有公开将候选位置表示为“DNAI的列表”这一具体形式。DNAI在目标专利中具有明确的技术含义，是连接UPF和本地DN的关键标识，其列表形式是核心特征之一。对比文件未公开。 |
| **技术特征N：** 对应的业务路由信息是N6业务路由信息<br><br>**《未公开》** | 对比文件[0108]：在网络100外部，QoS信息的通信传输可以在N6接口上进行。 | 对比文件提到了“N6接口”，但这是指UPF与外部DN之间的接口。目标专利中的“N6业务路由信息”特指在N6接口上如何将业务从UPF引导至特定应用位置的规则。对比文件并未公开将“业务路由信息”与“N6接口”或“N6”关联，更未公开其为“N6业务路由信息”这一特定格式。 |
| **技术特征O：** 其中，所述业务路由信息指明如何从在所述候选位置处的用户平面功能UPF(125)到达所述应用(201)<br><br>**《未公开》** | 对比文件[0108]：CN-GW 205（一个UPF）可以操作以剥离调整后的QoS级别，并在将数据包转发到外部应用服务器230之前恢复端到端QoS要求。 | 对比文件描述了UPF与外部应用服务器之间的数据包转发，这隐含了路由的存在。但是，目标专利中的“业务路由信息”是特指从“候选位置处的UPF”到达“应用”的明确规则，它是与每个候选位置绑定的。对比文件并未公开这种以“候选位置”为维度、由AF提供、用于指导SMF进行业务引导的特定路由信息。对比文件中的路由机制是网络固有的QoS策略和转发行为，而非AF提供的、与位置绑定的可配置信息。 |
| **技术特征P：** 其中，经由以下中的至少一个从所述AF(125)接收所述多个候选位置(200a、200b)和所述业务路由信息：策略控制功能PCF(133)，以及网络开放功能NEF(205)<br><br>**《隐含公开》** | 对比文件[0097] 图6C的步骤332-338：NEF 144接收来自AF的请求，发送消息给PCF 148，PCF返回网络能力信息给NEF，NEF再发给AF。这是AF通过NEF和PCF与核心网交互的路径。<br>对比文件[0121]：“...一个在外部应用服务器上实例化的可信应用功能可以直接向PCF 148发送传输，而不经过NEF 144。” | 对比文件明确、多次公开了AF（应用服务器）与核心网控制功能进行信息交互时，可以经由NEF和/或PCF。图6C、图6D以及[0121]段都详细描述了这种信令路径，包括AF -> NEF -> PCF 或 AF -> PCF。目标专利的特征P仅限定了信息的传输路径（通过PCF和/或NEF），而未限定传输的具体信息内容。虽然对比文件中传输的信息是“QoS能力请求/响应”，而非目标专利的“候选位置和业务路由信息”，但从信令架构和路由方式上看，本领域技术人员可以合理推断，AF与SMF之间的任何授权信息交互都可能沿袭这一标准化的核心网路径（通过NEF和/或PCF）。因此，该技术特征被对比文件**隐含公开**。 |
### 结论
经过严谨比对，对比文件**直接公开**了部分网络架构和功能实体，并与目标专利共有一些基础通信概念。然而，针对目标专利权利要求中限定的具体技术特征组合，特别是关于SMF从AF接收**多个候选位置和对应的业务路由信息**，并基于**无状态指示**或**无相反指示**而获得**自主选择与重定位业务**的权限这一核心发明点，对比文件均未进行任何形式的公开或暗示。
具体到每个特征：
* 技术特征A、B、C、D、E、F、G、H、J、L、M、N、O 均未被对比文件以直接或隐含的方式公开。
* 技术特征P，由于对比文件全面公开了AF通过PCF和/或NEF与核心网交互的信令路径，尽管信息内容不同，但在路径层面被认为是隐含公开。
根据输出格式要求，仅在隐含公开的特征后插入对应代码，其他未公开的特征不插入任何代码。
<<<p>>>