用于实现具有至少一个运营和支持系统（2）和被连接到其的多个网络元件（30…33）的移动网络（1）中的策略的方法，其中： 由每个网络元件（30…33）单独地验证策略的集合，；所述策略集合与所述每个网络元件（30…33）相关；以及基于所述网络元件（30…33）的策略库（4）和所述网络元件（30…33）的系统状态（5）来完成验证，；并且其中在第一个步骤中，在没有系统变量的情况下检查所述策略库（4）的策略的一致性，并且在第二个步骤中，关于当前系统状态（5）来检查所述策略的一致性。

尊敬的委托人：

作为一名经验丰富的专利代理师，我接受您的委托，紧密结合目标专利说明书（CN106465155B，以下简称“本专利”）的公开内容，对权利要求1进行深入解析，并结合您提供的三份对比文件原文进行详细的比对分析和创造性论述。

以下是我的法律分析意见：

### 第一部分：目标专利权利要求1的解释

紧密结合本专利说明书背景技术[0002]-[0003]段以及具体实施方式部分，权利要求1所保护的技术方案应做如下解读：

该方法应用于包含运营和支持系统（OSS）及多个网络元件（NE）的移动网络中。其核心思想在于改变传统的仅在OSS端集中式管理策略的方式，转而在**每个网络元件内部**非集中化地、独立地执行策略库的验证。

特别地，权利要求1限定了一种**两步式（分层）验证**的具体机制：

1. **静态检查（第一个步骤）：** “在没有系统变量的情况下检查……策略的一致性”。结合说明书[0012]段（系统变量示例为系统时间）和[0015]段（霍恩子句），这指的是纯粹基于策略自身的逻辑、语法或规则间的静态冲突进行检查，不依赖网络当前的实时运行状态。

2. **动态检查（第二个步骤）：** “关于当前系统状态来检查……策略的一致性”。这指的是结合网络元件当下的实时运行参数（即系统状态）来校验策略。

这种分层验证的方式利于较容易地发现错误，并能评估策略在实际系统状态下的隐含式[0013]-[0014]。

---

### 第二部分：技术特征比对及出处分析

现将权利要求1的技术特征拆解，并与对比文件原文进行详细比对。对比文件指代如下：

* **D1：** US20050273851A1 (2005-12-08公开)

* **D2：** US20120039175A1 (2012-02-16公开)

* **D3：** US20130086241A1 (2013-04-04公开)

#### 特征比对表

#### 特征比对详细出处及分析

##### D1 (US20050273851A1) 分析

D1主要关注网络安全合规性审计。

* 对于**特征A（元件单独验证）**，D1是**不公开**的。D1描述其架构在[0058]段：“路由器208进一步耦合到托管网络安全智能引擎402的网络管理站220……”。在具体实施方法中，[0050]段指出：“……检索运行配置……并将检索到的配置与配置策略进行比较。”这些操作均暗示验证过程是在中央的管理站/引擎402中完成的，而非由网络元件“单独”完成。

* 对于**特征C（两步验证）**，D1提及[0074]段有“规则验证逻辑412”，但如上所述，该逻辑运行在中央引擎，不满足在元件端执行。且D1未区分静态（无变量）和动态（有变量）的两步分层检查机制。

##### D2 (US20120039175A1) 分析

D2关注在扩展SON网络中动态分发策略以实现负载均衡。

* 对于**前序部分**和**特征B**，D2在摘要和[0006]段明确公开：“……将一个或多个策略更新传播（disseminating）到无线网络中的……至少一个非PGW节点（即基站eNB）……在非PGW节点本地强制执行（locally enforcing）策略更新”。满足移动网络、OSS向NE发布与NE相关的策略。

* 对于**特征A（元件单独验证）**，D2在[0025]段原文公开：“……其中**每个实体自主地基于策略信息做出决定（every entity autonomously makes decisions based on policy information）**”。这毫无异议地公开了NE单独独立执行策略验证/决策。

* 对于**特征C（验证依据及动态步骤）**，D2公开了基于状态的验证。原文[0027]段：“……基站……能够基于网络管理中测量的网络负载和用户流量动态地调整（dynamically adapt）其策略……”。特征C-3（动态步骤）被实质公开，因为动态调整必然包含关于当前状态校验策略适用的过程。

* 但是，D2**未公开特征C-2（静态步骤）**。D2的全部教导在于如何根据实时测量数据（动态变量）来传播和调整策略，并未提及在元件端进行不依赖系统变量的纯策略逻辑一致性检查。

##### D3 (US20130086241A1) 分析

D3关注SOA架构中Web服务策略的运行时条件附加和验证。

* 对于**特征A（元件单独验证）**，D3原文[0063]段描述：“Agent 110和112可以在应用程序运行时实施确定的策略……Agent 110可以确定……用户名/密码验证策略应附加到WS客户端端点106，因此可以实施该要求……”。由于Agent运行在应用端（网络元件端），这毫无异议公开了NE单独验证/实施策略。

* 对于**特征C-3（动态步骤）**，D3原文[0095]段明确公开了在运行时（runtime），Agent提取实时信息更新“运行时上下文组件（runtime context component）”，通过约束组件评估约束表达式（该表达式依赖运行时参数[0074]），从而确定策略是否附加。这毫无异议公开了关于当前系统状态检查策略一致性。

* 对于**特征C-2（静态步骤）**，D3在[0111]-[0112]段以及图8描述了在**初始化阶段（prior to runtime / initialization phase）**执行的验证过程，其目的是确保策略间没有冲突或不兼容。由于是在运行时之前，此时没有“运行时上下文（系统变量）”，因此实质公开了在没有系统变量的情况下检查策略一致性。

* **本专利权利要求1与D3的区别在于：** D3虽然公开了静态检查（初始化阶段）和动态检查（运行时阶段），但并未教导将这两个步骤组合成一个统一的、用于在网络元件端单独实现策略的、**显式的“第一个步骤”和“第二个步骤”**。在D3中，静态检查是可选的初始化行为，动态检查是运行时的必要行为，二者并非本专利限定的为了综合验证策略库而设计的紧密的分层验证流程。

---

### 第三部分：最接近对比文件分析

在创造性分析过程中，判断哪个对比文件适合做“最接近的对比文件（Gold Standard）”，需要从**整体解决的技术问题**以及**技术效果**角度进行衡量。

本代理师认为：**对比文件D2适合作为权利要求1创造性分析的最接近对比文件。**

**分析如下：**

1. **技术领域和整体架构最为接近：**

* **本专利**解决的问题是在自组织网络（SON）中，OSS发布分布式策略到NE， NE需要自主执行策略，且需要确保自动生成的策略与人类策略间的一致性，期望通过元件端非集中式验证来减轻努力[0002]-[0005], [0011]。技术领域是移动网络（SON）。架构是OSS->NE独立执行。

* **D2**的技术领域也是移动网络（LTE WCDMA/CDMA）。其明确提及背景技术是3GPP的集中式策略架构（PCRF侧），要解决的问题是基站无法根据网络状态动态做准入控制和负载均衡[0003]。其解决方法的整体架构是建立一个“扩展SON”网络，让PCRF将自定义策略分发到 targeted nodes（基站），并且强制特征是[0025]段所述的“每个实体自主地（autonomously）基于策略信息做出决定”。

* **比对结论：** D2与本专利的技术领域完全相同（移动网络SON），技术架构也高度一致（OSS->NE，NE自主决策/执行策略）。相比之下，D1是中央审计架构，D3是SOA网络服务领域，在领域和基础架构上均不如D2接近。

2. **解决的技术问题和技术效果最为接近：**

* 本专利通过元件端独立验证策略集合，其技术效果是利于较容易发现策略错误，避免数据业务量（若完全自主验证），减轻网络运营努力，并提高过程稳定性（若移除不一致添加）[0011], [0013], [0016], [0048]。

* D2通过让基站本地自主强制PCRF下发的、定制化的策略更新，实现动态准入控制和负载均衡。虽偏重网络运行优化，但其实现基础完全依赖于NE对策略库的自主处理和应用（即广义的验证与执行）。D2公开了元件依据动态状态（变量）来决策策略，这与本专利强调的基于系统状态（特征C-1和特征C-3）来完成验证高度吻合。

* **比对结论：** D2已经教导了本专利最核心的架构改变（元件非集中化自主处理策略）以及基于动态状态的处理。本专利相对于D2的改进在于将这种元件端的策略处理具体化为了显式的“静态+动态”分层验证步骤。因此，从D2出发去评估这种分层验证步骤的创造性是最为自然的路径。

综上所述，对比文件D2构成了权利要求1最接近的现有技术。本代理师在后续的创造性防御或攻击中，将紧密结合特征比对表中D2未公开特征C-2以及D3相关公开内容进行论述。特征C-2实质上提供了一种分层检查的技术手段，在评估其创造性时需重点关注D2和D3组合是否存在技术启示。

---

### 第四部分：无效请求中最薄弱的技术特征

若针对权利要求1提出无效宣告请求，本代理师认为最薄弱的技术特征是：**特征C-2（在第一个步骤中，在没有系统变量的情况下检查策略库的策略的一致性）。**

**理由如下：**

1. **技术实质属于常规逻辑检查：** 结合说明书[0013]和[0118]段（参考记号列表：7 验证代码/验证模块），特征C-2定义的“没有系统变量下检查一致性”实质上就是一种计算机领域的常规逻辑检查、语法检查或静态代码分析技术。任何包含策略或规则的系统（如防火墙规则、QoS规则），对其进行纯逻辑层面的静态查错都是本领域技术人员的通用常识，无需特别的技术教导。本专利仅是将其应用在了移动网络元件端策略库的特定场景。

2. **已被对比文件其实质公开：** 如比对表所示，对比文件D3虽然是SOA领域，但其代理在网络服务节点执行策略。D3公开了策略包含约束（依赖运行时参数），并且明确在[0111]-[0112]段教导了在“初始化阶段（即运行时之前）”对由于约束不同而分组的策略集应用验证规则，检查冲突或不兼容。由于初始化阶段不具备“运行时上下文（系统变量）”，该教导在实质上等同于特征C-2的静态检查。

3. **组合启示强烈：** 一旦以对比文件D2作为创造性分析的基础（D2已公开元件端非集中化自主处理策略，依据动态状态处理策略），本领域技术人员为了提高元件处理策略的稳健性和效率（不必要静态错误导致动态执行失败），极其容易想到引入常规的静态检查技术。对比文件D3给出了在依赖运行时变量的策略系统中引入运行时前（无变量）验证的明确教导，这种跨领域的普通技术移植对本领域技术人员而言是不费吹灰之力的。

因此，特征C-2虽然构成了本专利相对于最接近对文件D2的显著区别特征之一，但其技术实质的常规性以及其在D3中的实质公开，使其成为了权利要求1创造性链条中最脆弱的一环，极易被现有技术组合击破。

以上意见，供您参考。

专利代理师

[日期]

你好。作为一名经验丰富的专利代理师，我仔细阅读了权利要求1以及你提供的目标专利说明书和对比文件原文。现紧密结合目标专利说明书解释权利要求，并依据对比文件原文进行详细的特征比对和创造性分析。

### 第一部分：权利要求1解释

权利要求1保护一种用于实现移动网络（1）中的策略的方法。为了准确确定其保护范围，需要理解其中的关键术语，特别是说明书如何对其进行定义或描述：

* **移动网络（1）：** 包括至少一个运营和支持系统（OSS）（2）和多个网络元件（NE）（30…33）。

* **策略（Policies）：** 说明书明确（[0002]）策略用于使得NE和OSS能够自主执行预定义运营，特别是在自组织网络（SON）中。策略库（4）由专家人员创建（[0003]）。机器学习可以自动扩充策略（[0020]）。策略可以被解释为霍恩子句（[0015]）。

* **网络元件单独验证：** 验证由“每个网络元件 单独地”完成。说明书进一步解释（[0011]）这意味着逐个网络元件执行验证，无需必定完全由专家人员在中央创建，减轻了运营负担。此外，说明书指出（[0016]），NE可以在没有与OSS数据交换的情况下进行验证，避免了数据业务量。

* **与每个网络元件相关：** 策略集合视为一个逻辑域（[0011]）。

* **策略库（4）：** 网络元件包括具有多个策略的策略库（[0029]）。

* **系统状态（5）：** 通常由多个系统变量定义，例如系统时间（[0012]、[0029]）。系统变量越多，验证质量越改进。

* **第一个步骤（没有系统变量）：** 检查策略库的策略的一致性。这是分层验证的第一步（[0013]），较容易发现错误。

* **第二个步骤（关于当前系统状态）：** 再次检查策略的一致性。

基于上述解释，权利要求1的核心发明点在于：将SON网络中的策略验证非集中化，由每个NE基于自身的策略库和系统状态单独验证，且验证过程分为“不考虑系统变量的初步一致性检查”和“结合当前系统状态的具体一致性检查”两个步骤。其技术效果是较容易发现策略错误，且避免验证引起的OSS与NE间的数据业务量。

---

### 第二部分：特征比对分析

我们将权利要求1拆解为技术特征，并与各对比文件进行比对。

**对比文件代号及公开号对照表：**

* D1: US20050273851A1

* D2: US20120039175A1

* D3: US20130086241A1

#### 特征比对表格

---

### 第三部分：创造性分析 - 最接近对比文件分析

在进行创造性分析之前，我们从整体解决的技术问题以及技术效果角度确定最接近的对比文件：

* **目标专利的核心：** SON网络策略验证非集中化，由NE单独进行分层验证（不带变量验证->当前变量验证）。其解决了专家人员中央创建分布式策略昂贵、且难以在机器学习自动扩充策略背景下保证NE本地一致性的技术问题。

* **D1 (US20050273851A1):**

* **整体技术问题：** 网络安全审计，即如何确定网络整体或单个网络设备是否符合定义的安全性规则。

* **技术效果：** 管理员能够集中定义策略，并将策略关联到设备，由集中式管理系统（“网络安全智能引擎402” FIG. 2, [0058]）检索设备的运行配置，集中式地验证这些配置是否满足策略。这属于集中管理式策略验证，并未解决NE单独非集中化验证移动网络SON策略的一致性问题。

* **结论：** D1不适合作为最接近的对比文件。

* **D2 (US20120039175A1):**

* **整体技术问题：** 解决在eNB和MME这类非网关节点动态、近实时地负载均衡的技术问题。conventional base stations must have their admission control and load balancing policies configured manually... [0003]

* **技术效果：** 通过 closed loop feedback 在 OSS（PCRF）收集网络状态（拥塞、QoS），PCRF确定特定目标NE（如 congested eNB FIG. 4, [0032]）的策略调整（策略更新 [0006]），将更新下发给NE本地执行。这虽然在执行和动态调整层面涉及NE本地化，但策略调整和验证依然是集中式的由PCRF完成。并未解决NE“单独验证”其内部SON策略一致性的问题。

* **结论：** D2虽然领域最接近（移动网络NE策略本地执行），但在发明构思、非集中式验证和分层验证特征上与本发明相距甚远。

* **D3 (US20130086241A1):**

* **整体技术问题：** 解决 SOA架构中Web服务端点策略不能在运行时根据上下文（runtime condition）条件式附加的技术问题。Existing solutions have no way to conditionally attach policies... regardless of the context... Manual approach is cumbersome. [0006].

* **技术效果：** 通过在 Web服务代理上实现 conditional policy attachment 特征（[0008]），定义约束表达式（constraint expressions [0010]），依附逻辑在 Web端点运行时单独、本地化完成。最关键的是，D3 分阶段：在初始化代理阶段进行 policy validation process 以避免errors on conditionally attached policies ([0009], [0113])，并在运行时根据当前 context 评估约束 ([0010], [0095])。这完美地契合了目标专利非集中化、由NE端单独进行分层验证（初步冲突检查->具体变量验证）的核心构思。

* **结论：** D3 虽然领域（SOA）不同，但在**整体发明构思**、**解决非集中化条件策略验证的技术问题**以及**实现分层验证的技术效果**上，与目标专利最接近。本领域技术人员为了解决机器学习生成SON策略一致性这一类似的非集中化策略校验问题，有动机在D3 分阶段（预检和运行时评估）验证的启示下寻求解决方案。

综上所述，我认为：

1. **D3 (US20130086241A1) 最适合作为最接近的对比文件进行创造性分析。**

2. 对于权利要求1的移动网络（领域特征），可以认为本领域技术人员容易结合D2（移动网络策略本地执行）的启示，将D3的分层验证构思应用于移动网络。

3. 最值得注意的是特征D。特征D限定了两个具体的步骤：不考虑系统变量和结合当前系统状态。如特征比对表格所述，D3在初始化阶段不考虑具体系统变量分组进行冲突预检，并在运行时（关于 runtime context 变量）具体评估，实质上公开了这一分层验证构思。

因此，根据特征比对表格，没有被最接近的对比文件D3公开的特征（特征P、B关于移动网络NE特征）是否被其他对比文件公开？是的，已被D2公开。

### 第四部分：最薄弱的技术特征

基于对比文件比对结果，如果提出无效请求，对于请求方来说最薄弱的技术特征（即：请求方证据最不充足、目标专利专利权人最容易辩驳、本领域技术人员最难以认为是被对比文件公开的技术特征）是：

**技术特征A：由每个网络元件单独地验证策略的集合。**

理由如下：

1. 目标专利明确指出（[0011], [0016]），验证是“单独的验证”，并且“NE在没有与运营支持系统数据交换的情况下”进行。这意味着完全的本地非集中化。

2. D1公开的是纯中央集中式验证（管理站检索设备配置验证）。D1显而易见未公开特征A。专利权人容易论证D1的发明构思与本发明本质不同。

3. D2公开的是NE执行PCRF下发的更新策略，NE仅上报测量数据（ feedback FIG. 2, [0023]-[0025]）。策略调整和决定是在PCRF进行的。并没有“网络元件单独地验证策略集合”。核心发明点不匹配。专利权人可以极力主张本发明的“单独验证策略”是本地化的、无需OSS参与的逻辑一致性检查，区别于D2的测量数据上报和集中策略调整。

4. D3虽然最接近分层验证的构思，但其领域在SOA应用程序/Web服务代理上处理策略主体依附，验证是 Web服务的逻辑主体层面。专利权人可以主张将Web服务代理策略逻辑验证等同于移动网络网络元件（通常指具备完整网络功能的物理或逻辑单元）对自身内部复杂的SON策略集合的一致性校验，在特征A的实现上存在技术障隘。专利权人可能会抗辩，移动网络 NE 的 SON 策略涉及复杂的网络状态、机器学习生成的相关性，且无需与OSS交换数据直接在NE内部“单独完成”，不同于Web服务端点基于约束进行的逻辑预检。

在特征A上，D1、D2明显没有公开NE端主动的策略逻辑验证，而D3虽然形式上在端点代理验证，但在移动网络 NE 的具体特定背景下，专利权人有较大的空间申辩特征A涉及 NE 自身基于霍恩子句等特定策略形式和本地状态的独立完整校验过程，从而主张创造性。因此，特征A是请求方在证据层面最薄弱、专利权人最可能守住、使权利要求最终维持有效的特征。

尊敬的委托人：

作为一名经验丰富的专利代理师，我接受您的委托，紧密结合目标专利说明书（CN106465155B，以下简称“本专利”）的公开内容，对权利要求1进行深入解析，并结合您提供的三份对比文件原文进行详细的比对分析和创造性论述。

以下是我的法律分析意见：

### 第一部分：目标专利权利要求1的解释

紧密结合本专利说明书背景技术[0002]-[0003]段以及具体实施方式部分，权利要求1所保护的技术方案应做如下解读：

该方法应用于包含运营和支持系统（OSS）及多个网络元件（NE）的移动网络中。其核心思想在于改变传统的仅在OSS端集中式管理策略的方式，转而在**每个网络元件内部**非集中化地、独立地执行策略库的验证。

特别地，权利要求1限定了一种**两步式（分层）验证**的具体机制：

1. **静态检查（第一个步骤）：** “在没有系统变量的情况下检查……策略的一致性”。结合说明书[0012]段（系统变量示例为系统时间）和[0015]段（霍恩子句），这指的是纯粹基于策略自身的逻辑、语法或规则间的静态冲突进行检查，不依赖网络当前的实时运行状态。

2. **动态检查（第二个步骤）：** “关于当前系统状态来检查……策略的一致性”。这指的是结合网络元件当下的实时运行参数（即系统状态）来校验策略。

这种分层验证的方式利于较容易地发现错误，并能评估策略在实际系统状态下的隐含式[0013]-[0014]。

---

### 第二部分：技术特征比对及出处分析

现将权利要求1的技术特征拆解，并与对比文件原文进行详细比对。对比文件指代如下：

* **D1：** US20050273851A1 (2005-12-08公开)

* **D2：** US20120039175A1 (2012-02-16公开)

* **D3：** US20130086241A1 (2013-04-04公开)

#### 特征比对表

#### 特征比对详细出处及分析

##### D1 (US20050273851A1) 分析

D1主要关注网络安全合规性审计。

* 对于**特征A（元件单独验证）**，D1是**不公开**的。D1描述其架构在[0058]段：“路由器208进一步耦合到托管网络安全智能引擎402的网络管理站220……”。在具体实施方法中，[0050]段指出：“……检索运行配置……并将检索到的配置与配置策略进行比较。”这些操作均暗示验证过程是在中央的管理站/引擎402中完成的，而非由网络元件“单独”完成。

* 对于**特征C（两步验证）**，D1提及[0074]段有“规则验证逻辑412”，但如上所述，该逻辑运行在中央引擎，不满足在元件端执行。且D1未区分静态（无变量）和动态（有变量）的两步分层检查机制。

##### D2 (US20120039175A1) 分析

D2关注在扩展SON网络中动态分发策略以实现负载均衡。

* 对于**前序部分**和**特征B**，D2在摘要和[0006]段明确公开：“……将一个或多个策略更新传播（disseminating）到无线网络中的……至少一个非PGW节点（即基站eNB）……在非PGW节点本地强制执行（locally enforcing）策略更新”。满足移动网络、OSS向NE发布与NE相关的策略。

* 对于**特征A（元件单独验证）**，D2在[0025]段原文公开：“……其中**每个实体自主地基于策略信息做出决定（every entity autonomously makes decisions based on policy information）**”。这毫无异议地公开了NE单独独立执行策略验证/决策。

* 对于**特征C（验证依据及动态步骤）**，D2公开了基于状态的验证。原文[0027]段：“……基站……能够基于网络管理中测量的网络负载和用户流量动态地调整（dynamically adapt）其策略……”。特征C-3（动态步骤）被实质公开，因为动态调整必然包含关于当前状态校验策略适用的过程。

* 但是，D2**未公开特征C-2（静态步骤）**。D2的全部教导在于如何根据实时测量数据（动态变量）来传播和调整策略，并未提及在元件端进行不依赖系统变量的纯策略逻辑一致性检查。

##### D3 (US20130086241A1) 分析

D3关注SOA架构中Web服务策略的运行时条件附加和验证。

* 对于**特征A（元件单独验证）**，D3原文[0063]段描述：“Agent 110和112可以在应用程序运行时实施确定的策略……Agent 110可以确定……用户名/密码验证策略应附加到WS客户端端点106，因此可以实施该要求……”。由于Agent运行在应用端（网络元件端），这毫无异议公开了NE单独验证/实施策略。

* 对于**特征C-3（动态步骤）**，D3原文[0095]段明确公开了在运行时（runtime），Agent提取实时信息更新“运行时上下文组件（runtime context component）”，通过约束组件评估约束表达式（该表达式依赖运行时参数[0074]），从而确定策略是否附加。这毫无异议公开了关于当前系统状态检查策略一致性。

* 对于**特征C-2（静态步骤）**，D3在[0111]-[0112]段以及图8描述了在**初始化阶段（prior to runtime / initialization phase）**执行的验证过程，其目的是确保策略间没有冲突或不兼容。由于是在运行时之前，此时没有“运行时上下文（系统变量）”，因此实质公开了在没有系统变量的情况下检查策略一致性。

* **本专利权利要求1与D3的区别在于：** D3虽然公开了静态检查（初始化阶段）和动态检查（运行时阶段），但并未教导将这两个步骤组合成一个统一的、用于在网络元件端单独实现策略的、**显式的“第一个步骤”和“第二个步骤”**。在D3中，静态检查是可选的初始化行为，动态检查是运行时的必要行为，二者并非本专利限定的为了综合验证策略库而设计的紧密的分层验证流程。

---

### 第三部分：最接近对比文件分析

在创造性分析过程中，判断哪个对比文件适合做“最接近的对比文件（Gold Standard）”，需要从**整体解决的技术问题**以及**技术效果**角度进行衡量。

本代理师认为：**对比文件D2适合作为权利要求1创造性分析的最接近对比文件。**

**分析如下：**

1. **技术领域和整体架构最为接近：**

* **本专利**解决的问题是在自组织网络（SON）中，OSS发布分布式策略到NE， NE需要自主执行策略，且需要确保自动生成的策略与人类策略间的一致性，期望通过元件端非集中式验证来减轻努力[0002]-[0005], [0011]。技术领域是移动网络（SON）。架构是OSS->NE独立执行。

* **D2**的技术领域也是移动网络（LTE WCDMA/CDMA）。其明确提及背景技术是3GPP的集中式策略架构（PCRF侧），要解决的问题是基站无法根据网络状态动态做准入控制和负载均衡[0003]。其解决方法的整体架构是建立一个“扩展SON”网络，让PCRF将自定义策略分发到 targeted nodes（基站），并且强制特征是[0025]段所述的“每个实体自主地（autonomously）基于策略信息做出决定”。

* **比对结论：** D2与本专利的技术领域完全相同（移动网络SON），技术架构也高度一致（OSS->NE，NE自主决策/执行策略）。相比之下，D1是中央审计架构，D3是SOA网络服务领域，在领域和基础架构上均不如D2接近。

2. **解决的技术问题和技术效果最为接近：**

* 本专利通过元件端独立验证策略集合，其技术效果是利于较容易发现策略错误，避免数据业务量（若完全自主验证），减轻网络运营努力，并提高过程稳定性（若移除不一致添加）[0011], [0013], [0016], [0048]。

* D2通过让基站本地自主强制PCRF下发的、定制化的策略更新，实现动态准入控制和负载均衡。虽偏重网络运行优化，但其实现基础完全依赖于NE对策略库的自主处理和应用（即广义的验证与执行）。D2公开了元件依据动态状态（变量）来决策策略，这与本专利强调的基于系统状态（特征C-1和特征C-3）来完成验证高度吻合。

* **比对结论：** D2已经教导了本专利最核心的架构改变（元件非集中化自主处理策略）以及基于动态状态的处理。本专利相对于D2的改进在于将这种元件端的策略处理具体化为了显式的“静态+动态”分层验证步骤。因此，从D2出发去评估这种分层验证步骤的创造性是最为自然的路径。

综上所述，对比文件D2构成了权利要求1最接近的现有技术。本代理师在后续的创造性防御或攻击中，将紧密结合特征比对表中D2未公开特征C-2以及D3相关公开内容进行论述。特征C-2实质上提供了一种分层检查的技术手段，在评估其创造性时需重点关注D2和D3组合是否存在技术启示。

---

### 第四部分：无效请求中最薄弱的技术特征

若针对权利要求1提出无效宣告请求，本代理师认为最薄弱的技术特征是：**特征C-2（在第一个步骤中，在没有系统变量的情况下检查策略库的策略的一致性）。**

**理由如下：**

1. **技术实质属于常规逻辑检查：** 结合说明书[0013]和[0118]段（参考记号列表：7 验证代码/验证模块），特征C-2定义的“没有系统变量下检查一致性”实质上就是一种计算机领域的常规逻辑检查、语法检查或静态代码分析技术。任何包含策略或规则的系统（如防火墙规则、QoS规则），对其进行纯逻辑层面的静态查错都是本领域技术人员的通用常识，无需特别的技术教导。本专利仅是将其应用在了移动网络元件端策略库的特定场景。

2. **已被对比文件其实质公开：** 如比对表所示，对比文件D3虽然是SOA领域，但其代理在网络服务节点执行策略。D3公开了策略包含约束（依赖运行时参数），并且明确在[0111]-[0112]段教导了在“初始化阶段（即运行时之前）”对由于约束不同而分组的策略集应用验证规则，检查冲突或不兼容。由于初始化阶段不具备“运行时上下文（系统变量）”，该教导在实质上等同于特征C-2的静态检查。

3. **组合启示强烈：** 一旦以对比文件D2作为创造性分析的基础（D2已公开元件端非集中化自主处理策略，依据动态状态处理策略），本领域技术人员为了提高元件处理策略的稳健性和效率（不必要静态错误导致动态执行失败），极其容易想到引入常规的静态检查技术。对比文件D3给出了在依赖运行时变量的策略系统中引入运行时前（无变量）验证的明确教导，这种跨领域的普通技术移植对本领域技术人员而言是不费吹灰之力的。

因此，特征C-2虽然构成了本专利相对于最接近对文件D2的显著区别特征之一，但其技术实质的常规性以及其在D3中的实质公开，使其成为了权利要求1创造性链条中最脆弱的一环，极易被现有技术组合击破。

以上意见，供您参考。

专利代理师

[日期]

如权利要求1所述的方法，其中在第三个步骤中关于潜在的系统状态来检查所述策略的一致性。

如权利要求1所述的方法，其中策略被解释为霍恩子句。

如权利要求1所述的方法，其中所述网络元件（30…33）在没有与运营和支持系统（2）的数据交换的情况下验证所述策略集合。

如权利要求1所述的方法，其中运营和支持系统（2）向所述网络元件（30…33）发送验证代码（7），并且所述网络元件（30…33）应运营和支持系统（2）的请求借助于接收到的验证代码（7）来验证所述策略集合。

如权利要求1所述的方法，其中所述网络元件（30…33）从运营和支持系统（2）请求验证代码（7）并且借助于接收到的验证代码（7）来验证所述策略集合。

如权利要求1所述的方法，其中运营和支持系统（2）从所述网络元件（30…33）请求策略库（4）和系统状态（5），并借助于接收到的策略库（4）和接收到的系统状态（5）来验证所述策略集合。

如权利要求1所述的方法，其中所述网络元件（30…33）将其策略库（4）和系统状态（5）上传到运营和支持系统（2），并且其中运营和支持系统（2）应所述网络元件（30…33）的请求来验证所述策略集合。

如权利要求1所述的方法，其中，借助于机器学习（8）来自动地扩充策略集合。

如权利要求1所述的方法，其中，在识别到不一致的策略集合时，移除对策略库（4）的最后添加，并且在另外的步骤中重新验证策略库（4）。

用于移动网络（1）的多个网络元件（30…33）当中的网络元件（30…33），包括用于验证其策略库（4）的部件（7）和用于从所述移动网络（1）的运营和支持系统（2）接收验证代码（7）的部件，其中： 由网络元件（30…33）中的每一个单独地验证策略的集合，所述策略集合与所述每一个网络元件（30…33）相关；以及基于所述网络元件（30…33）的系统状态（5）来完成验证，并且其中在第一个步骤中，在没有系统变量的情况下检查所述策略库（4）的策略的一致性，并且在第二个步骤中，关于当前系统状态（5）来检查所述策略的一致性。

用于移动网络（1）的运营和支持系统（2），包括用于向被连接到运营和支持系统（2）的多个网络元件（30…33）之一发送验证代码（7）和/或从所述网络元件（30…33）接收策略库（4）和系统状态（5）的部件，其中： 由每个网络元件（30…33）单独地验证策略的集合，所述策略集合与所述每个网络元件（30…33）相关；以及基于所述网络元件（30…33）的所述策略库（4）和所述网络元件（30…33）的所述系统状态（5）来完成验证，并且其中在第一个步骤中，在没有系统变量的情况下检查所述策略库（4）的策略的一致性，并且在第二个步骤中，关于当前系统状态（5）来检查所述策略的一致性。

移动网络（1），包括至少一个运营和支持系统（2）和被连接到其的多个网络元件（30…33）、用于由每个网络元件（30…33）单独地验证策略集合的部件，所述策略集合与所述每个网络元件（30…33）相关，以及用于基于所述网络元件（30…33）的策略库（4）和所述网络元件（30…33）的系统状态（5）的验证的部件（7），并且其中在第一个步骤中，在没有系统变量的情况下检查所述策略库（4）的策略的一致性，并且在第二个步骤中，关于当前系统状态（5）来检查所述策略的一致性。

如权利要求13所述的移动网络（1），包括用于在运营和支持系统（2）与网络元件（30…33）之间交换如下的部件- 所述网络元件（30…33）的策略库（4）和所述网络元件（30…33）的系统状态（5）和/或- 用于验证的验证代码（7）。