一种在多个网络管理处理元件上分发网络管理处理负载的方法，每个网络管理处理元件是集群的成员，一个成员是更新集群状态的集群头部，并且所述集群的成员跟随所述集群状态，所述方法包括：所述集群头部监控在所述集群的成员上的网络管理处理负载；以及在检测到所述集群负载不均衡时，一旦所述集群的至少一个子集处理的任务已经完成，则所述集群头部更新所述集群状态，以发起在所述至少一个子集上的网络管理处理负载的自动再均衡。

你好。作为一名经验丰富的专利代理师，我仔细研读了目标专利（CN106068626B）的说明书和权利要求1，以及对比文件D1（US2003/0126265A1）。

以下是基于目标专利说明书对权利要求1的合理解释，以及紧密结合对比文件原文的特征比对和创造性分析。

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

在解释权利要求时，我们必须紧密结合目标专利说明书的公开内容，以确定技术术语的真正含义、所述方法解决的技术问题以及达到的技术效果。

#### 1. 权利要求1的技术方案整体分析

权利要求1保护一种在多个网络管理处理元件（即运行网络管理应用实例的计算实体/服务器）上分发网络管理处理负载的方法。该方法采用了一种协作集群的架构，包含以下关键要素：

* **集群头部（Cluster Head）：** 负责监控负载、更新集群状态。

* **集群跟随（Following）：** 集群成员跟随（匹配）集群头部更新的状态。

* **再均衡时机（Timing）：** 在检测到负载不均衡时，更新集群状态以发起再均衡，但必须满足一个特定条件——“一旦所述集群的至少一个子集处理的任务已经完成”。

#### 2. 关键技术特征的说明书依据与解释

* **“网络管理处理元件” (Network management processing element)：**

* **说明书依据：** [0001]、[0004]。

* **解释：** 指运行网络管理应用实例的计算实体（例如，部署在刀片式服务器上的进程）。这些应用实例水平缩放，每个执行所管理的网络的一小部分负载（管理特定的网络元件NE）。

* **“集群的成员” (Member of a cluster) 与 “集群头部” (Cluster head)：**

* **说明书依据：** [0021]、[0042]、[0060]、图5。

* **解释：** 所有元件共同构成一个协作集群。集群头部是从成员中选出的（例如，通过最低ID或最早成员规则，[0060]），负责整体协调。说明书强调这是“分布式动态负载均衡”，不存在单点失败，因为任何实例失败，剩余实例可通过均衡补偿，并选出新的头部（[0085]）。

* **“更新集群状态” 与 “跟随所述集群状态”：**

* **说明书依据：** [0043]、[0056]、[0058]、图7。

* **解释：** 这是一种**异步协同**机制。集群头部设置一个总的“集群状态”（例如，从运行S2变为暂停Sn-1），个体成员自主且异步地检查该状态，并执行必要操作使自身状态匹配集群状态（[0058]）。这避免了复杂的集中控制和强同步，提高了系统的鲁棒性和灵活性。

* **“一旦所述集群的至少一个子集处理的任务已经完成”：**

* **说明书依据：** 背景技术 [0005]-[0007]（指出现有技术中集中控制、要求所有NE和实例协作关停、重启的问题），发明内容 [0010]、具体实施方式 [0063]、[0064]、图10。

* **解释：** 这是本发明的核心改进点。它针对网络管理应用与NE之间存在“状态会话语义”（会话期长，不易关停，[0005]）的问题。该特征意味着，负载均衡**不是**强制立即关停所有成员，而是允许元件在“处理的任务已经完成”（例如，收集完统计文件，[0063]）后再进入暂停状态准备再均衡。这允许在暂停操作前完成所有进行中的传送（[0063]）。

* **解决的技术问题：** 现有技术在水平缩放的管理应用实例间重分布网络元件（NE）时，由于NE与实例间面向会话的语义，导致重分布需要集中控制、强协作、甚至强制关闭/重启，不灵活且自动化难度高（[0007]）。

* **技术效果：** 通过集群状态引导各成员异步、自主地在完成当前任务后暂停，实现了鲁棒、灵活且高自动化的分布式动态负载均衡，避免了强制中止长会话任务导致的数据丢失或系统震荡。

---

### 第二部分：特征比对表格

以下紧密结合对比文件D1的原文，指出各技术特征的详细出处，并给出特征比对表格。

**对比文件D1信息：**

* **公开号：** US 2003/0126265 A1

* **公开日：** 2003年7月3日

* **名称：** Request queue management

D1公开了一种用于控制计算网格（computing grid）的方法和装置，该网格可逻辑划分为多个虚拟服务器农场（VSF），每个VSF可动态改变CPU数量以适应流量变化（摘要，[0049]）。D1特别描述了一个实施例，即使用请求队列来处理工作请求，并提及了“人类干预”和“请求阻塞”（[0189]-[0201]）。

---

### 第三部分：创造性分析

作为代理师，我将进行整体创造性分析，并确定最接近的对比文件。

#### 1. 确定最接近的对比文件 (Closest Prior Art)

从整体解决的技术问题和技术效果角度分析：

* **目标专利（CN106068626B）**：

* **解决问题：** 针对网络管理应用与元件之间具有面向长会话的语义，水平缩放时集中控制、强协作关停NE导致系统不灵活、自动化难度高的问题。

* **技术手段：** 采用异步协同的集群架构（头部设置状态，成员异步完成任务后匹配状态），在重新均衡前明确等待“正在处理的任务完成”。

* **技术效果：** 鲁棒、灵活、高自动化的分布式网络应用动态负载均衡，避免强制中止任务，提高系统稳定性。

* **对比文件D1 (US2003/0126265A1)**：

* **技术领域和核心架构：** 计算网格控制，VSF动态逻辑划分。

* **技术手段：**

1. **架构：** 高鲁棒性的Master/Slave控制平面（特征A）。通过选举产生的Master监控负载，控制Slave动态分配/取消分配VSF中的CPU成员（特征B1, B3）。这解决了网格资源分配、可用性和经济性的问题。

2. **请求队列管理：** [0189]-[0201]部分主要解决是个别请求需要“人类干预”的问题，它是将特定请求在“开始处理前”在队列中**阻塞**。

* **技术效果：** 实现网格资源弹性的自动调整、经济性。请求阻塞提高了安全性或处理特定审批流程。

**代理师分析结论：**

* **对比文件D1是唯一的对比文件，且其技术领域（计算网格资源管理）与目标专利（分布网络管理架构负载均衡）非常接近。其整体Master/Slave协同架构、选举机制、以及通过动态分配/删除CPU成员（VSF自动伸缩）来实现負荷均衡的方法，公开了权利要求1特征A的绝大部分和特征B的部分内容。**

* **虽然D1提及了“请求阻塞”和“暂停”，但其解决的技术问题是处理“人类干预”，技术手段是阻塞个别未开始任务，未描述针对长会话正在进行任务的优雅处理。** 目标专利核心解决由于长会话导致再均衡时需集中控制强关停的问题，采用了完全不同的协同机制和时机控制。

* **然而，由于D1公开了除关键特征B2之外的绝大部分架构和方法流程，基于“三步法”，D1是做最接近对比文件的最佳且唯一选择。**

#### 2. 最薄弱的技术特征

请求方如果要提出无效请求，**最薄弱（最难以论证为显而易见）的技术特征是特征B2：**

> “一旦所述集群的至少一个子集处理的任务已经完成，则所述集群头部更新所述集群状态”

**论证其创造性的核心理由如下：**

* **D1不仅未公开该特征，还给出了不同的技术导向。** D1描述的“人类干预阻塞请求”（[0189]-[0201]）并未解决，也未预见到目标专利所面临的问题：在长会话场景下如何优雅地进行系统级的再均衡流程。D1是将任务阻塞在未开始阶段，而目标专利是等待已开始任务完成。

* **结合本发明整体架构的协同机制。** 特征B2不仅是一个时机（Timing），它更是目标专利所采用的“异步 synergistic（Synergy，协同）集群管理”的一部分。说明书描述了各成员自主、异步地检查集群状态，在完成当前任务后设置完成标记（[0065]），全部完成标记设置后，集群头部再将状态转变为“运行”（[0065]、[0082]）。这是一种独特的异步协商机制。D1是Master强制Slave执行分配/取消分配指令，更倾向于集中式控制，未给出此类异步协商且等待已任务完成的启示。

#### 3. 创造性结论

鉴于关键技术特征B2未被D1公开，且该特征结合整体架构巧妙解决了网络管理应用场景特有的长会话语义导致的再均衡难题，取得了避免任务强制中止、提高系统鲁棒性和自动化程度的技术效果，且D1并未给出相应的启示，因此，**权利要求1具有创造性。**

---

### 第四部分：进一步检索策略

若需要对该发明进行进一步的新颖性/创造性检索（例如，为无效宣告请求做准备），检索点应**聚焦于特征B2：即“在动态负载均衡流程中，优雅地（Gracefully）处理元件上正在进行的、长任务，等待其完成后再真正暂停/重新均衡”的技术手段。** 具体的检索方向建议如下：

#### 1. 关键词和IPC的细化

* **关键词组：**

* (负载均衡 或 負荷均等 或 水平缩放 或 弹性伸缩 或 NE分发) AND (任务处理 或 会话完成 或 长任务 或 优雅处理 或 数据传送完成 或 暂停处理) AND (集群 或 協作 或 异步协同 或 头部跟随)。

* (Load Balanc* 或 Horizontal Scal* 或 Auto Scal* OR Elastic* ) AND ( Task finish* 或 Session complet* 或 Graceful* shut*down OR Waiting processing finish* ) AND ( Cluster OR Coordin* OR Asynchronous协同 OR Follow* state )。

* **IPC：** 聚焦于负载均衡（G06F9/50）、网络管理（H04L41/xx）、网络数据交换（H04L12/24）。

#### 2. 聚焦的专利类别和具体场景

* **场景1：** **状态会话语义（Stateful Session Semantics）的网络协议或应用。** 寻找那些涉及由于底层连接（如报警收集、性能文件传输）长期存在，不易关停，因而在进行管理元件水平缩放（Scaling）时，设计了优雅关闭（Graceful Shutdown）机制，即允许当前正在进行的任务在真正断开连接或负载转移之前完成的专利。

* **场景2：** **具有选举或动态Master功能的分布式协调系统。** 检索如Apache ZooKeeper、Etcd等强协调软件或其相关专利，寻找那些在变更配置（变更资源分配）时，各成员不仅仅是机械执行指令，而是包含类似于“等待当前事务/任务完成”再回复头部，进而推动系统进入下一状态的协同专利。

* **场景3：** **网管应用或业务应用软件厂商。** 重点检索如Ericsson、Nokia、Cisco、华为等主要通信设备商在网络管理系统架构方面的早期专利，这些厂商对长会话的网管 NE 管理最为了解。

通过上述分析和检索策略，可以更加精准地评估权利要求的稳定性。

作为一个经验丰富的专利代理师，我将紧密结合目标专利说明书（CN106068626B）来解释权利要求1，并结合对比文件D1（US20050262246A1）和D2（US20090027402A1）的原文进行详细的创造性比对分析。

### 第一部分：权利要求1的代理师解释与技术特征分解

目标专利（CN106068626B）的核心是解决在分布式网络管理架构中，由于网络管理应用与被管理元件之间存在“状态会话语义”（说明书[0005]），导致传统的基于负载测量直接重分布的均衡策略难以实施（会话中断、需要重启实例）的问题（说明书[0006]-[0007]）。

目标专利提出的技术方案是一种“自主且异步”的协作均衡机制。

**权利要求1：**

一种在多个网络管理处理元件上分发网络管理处理负载的方法，每个网络管理处理元件是集群的成员，一个成员是更新集群状态的集群头部，并且所述集群的成员跟随所述集群状态，所述方法包括：

所述集群头部监控在所述集群的成员上的网络管理处理负载；以及

在检测到所述集群负载不均衡时，一旦所述集群的至少一个子集处理的任务已经完成，则所述集群头部更新所述集群状态，以发起在所述至少一个子集上的网络管理处理负载的自动再均衡。

根据说明书的记载，我将权利要求1分解为以下两个核心技术特征，以便后续比对：

* **技术特征A（集群架构与监控）：**

* 应用场景：在多个**网络管理处理元件**上分发网络管理处理负载。

* 架构特征：每个元件是集群成员；存在一个**集群头部**用于**更新集群状态**；其他成员**跟随该集群状态**。

* 动作特征：集群头部**监控**成员上的网络管理处理负载。

* **技术特征B（基于任务完成状态的异步均衡发起）：**

* 触发条件：检测到集群负载不均衡。

* 核心限定（均衡时机）：**“一旦所述集群的至少一个子集处理的任务已经完成”**。

* 执行动作：集群头部**更新所述集群状态**，以发起自动再均衡。

**代理师深度解析：**

特征B是本发明的核心发明点。紧密结合说明书[0005]、[0006]和[0013]、[0063]，此处的“任务已经完成”在网络管理语境下，特指在暂停操作或状态转变之前，允许进行中的面向会话的任务（如文件传送、交易会话）处理完成，而不是强行中断。例如，说明书[0063]提到：“当被要求转变到暂停状态时，集群成员可以延缓任一新的文件传送，不过在暂停操作之前完成所有进行中的传送。”这种“一旦任务完成”才更新状态并发起再均衡的设计，实现了在保持网络管理状态会话完整性的前提下进行动态负载均衡。

---

### 第二部分：对比文件原文分析与特征比对

我将分别分析对比文件D1和D2是否公开了上述技术特征。

#### 1. 对比文件D1 (US2005/0262246 A1) 分析

D1公开了一种用于实时流媒体的、基于集群的可扩展架构中的负载均衡存储和流媒体请求的系统和方法。

**特征比对表格（D1 vs. 目标专利）：**

**D1分析结论：**

D1公开了基于集群的负载均衡架构，其中一个成员可作为中央调度器（集群头部）监控其他成员负载，这与特征A高度对应（除了具体的网络管理应用领域）。但是，D1未能公开核心特征B，即以“任务已经完成”作为更新集群状态和发起自动再均衡的前提条件。在实时流媒体语境下，D1倾向于立即通过复制机制应对高负载，而不是等待特定处理子集的当前任务流完成。

#### 2. 对比文件D2 (US2009/0027402 A1) 分析

D2公开了一种控制主机系统中体现的多模式并行图形处理系统（MMPGPS）的并行操作模式的方法。

**特征比对表格（D2 vs. 目标专利）：**

**D2分析结论：**

D2在多GPU并行图形处理架构中公开了特征A。关键在于特征B，尽管领域不同（图形vs.网络管理），D2的技术方案高度相关。D2公开了根据负载监控结果，动态自动控制并行模式（即负载在GPU间的分发策略，属一种再均衡）。D2明确界定，这种状态/模式的转变是以“帧”为单位进行剖析（[0046]），并在帧终止（如执行Flush and Swap操作）之后进行（[0385]）。这意味着D2实质公开了“一旦（帧处理）任务已经完成”才更新集群状态并发起再均衡。

---

### 第三部分：创造性分析——最接近对比文件的选择

在创造性分析中，确定哪个对比文件适合做最接近的对比文件（D1还是D2），需要结合目标专利整体解决的技术问题和达到的技术效果进行评估。

* **技术问题：**

目标专利旨在解决在具有“状态会话语义”的分布式网络管理系统中，如何自动化地实现动态负载均衡，同时保持状态会话不被强行中断（说明书[0005]-[0007]）。

* **对比文件分析：**

* **D1（流媒体服务器集群）：**

* **优点：** 同样是网络服务语境（D1是媒体流服务，目标专利是网络管理服务），面临在处理流/会话（媒体播放请求）时的负载均衡问题。领域上更接近。

* **缺点：** D1未能提供目标专利的核心技术特征B（即等待当前任务完成的异步发起机制）。D1的复制均衡倾向于立即执行以保证实时性，这与目标专利解决如何不重启实例、不中断会话的问题的技术手段不同。

* **D2（多模式图形处理）：**

* **优点：** 尽管是非网络管理领域，但其处理的任务（3D图形渲染）具有极强的会话/状态限定特征（以帧为单位）。为了在模式切换（均衡策略调整）时保持渲染结果的有效性，D2采用了明确的“状态/模式转变跟随任务单元（帧）完成（ termination）”的技术手段（[0385]），且D2也强调保留状态一致性（ state validity [0248]）。这与目标专利利用“一旦任务完成”才更新状态以避免会话重启的技术问题和手段具有高度的实质相关性。

* **缺点：** 具体应用领域（GPU处理）与网络管理存在差异，部分术语如“网络管理处理元件”未完全对应。

* **最接近对比文件的建议：**

作为请求方代理师，我建议将**对比文件D2（US2009/0027402A1）适合做为最接近的对比文件**。

**分析理由（整体问题与效果角度）：**

最接近对比文件的选择不仅看应用场景，更看重实质解决的技术问题和采用的技术逻辑。

目标专利不仅需要一个集群均衡架构（D1和D2都提供），其核心发明点在于均衡的发起时机（特征B）应当与当前正在进行的任务的完成状态挂钩（异步均衡），以解决保持状态会话的技术问题。D2（图形模式切换）比D1（流媒体复制均衡）更深刻地公开了这一特定技术逻辑：为了维持状态有效性（[0248]），在任务完成（帧终止[0385]）之间进行均衡模式状态更新（[0370]）。

---

### 第四部分：请求方最薄弱的技术特征分析与检索策略

作为请求方代理师，我必须客观地指出目前证据链中针对权利要求1对于请求方来说**最薄弱的技术特征**。

基于以上比对，特征B已被D2实质公开。目前最薄弱的特征（即没有被任何一篇对比文件完美公开的特征）在于**特征A的应用场景限定**：

**薄弱特征限定：** **“所述方法包括：...所述集群头部更新所述集群状态，以发起...网络管理处理负载的自动再均衡。”**

**分析：**

本申请权利要求1被撰写为一种特定的应用方法（“一种在多个网络管理处理元件上分发...的方法”）。虽然D2公开了类似的均衡技术架构和利用任务完成完成均衡的技术手段，但其明确限定在GPU图形处理领域。

**审查难点预计：**

专利权人（代理师）在应对基于D2的创造性挑战时，其最强有力的防御理由（说明书[0005]、[0006]）将是：网络管理领域中由于具有特定的“状态会话语义（如长存活的统计收集、配置操作会话）”，使得人工分配或集中控制困难。虽然D2公开了以任务为单位均衡图形模式，但网络管理中的会话远比图形帧复杂，不能直接应用图形学技术。

因此，请求方仅仅证明上述技术手段在图形处理中是常识是不够的。

#### 进一步检索策略建议：

为了克服上述最薄弱环节，需要进行**具体的领域针对性检索**，目的是找到在“网络管理”或“网络应用服务”领域（而非图形学领域）中公开了针对状态会话利用任务完成状态进行异步均衡的证据。

**进一步检索策略：**

* **应用领域：** 网络管理系统（NMS），网元管理系统（EMS），电信运营支持系统（OSS），网络会话均衡器，或由于会话（Session）特性难以水平扩展的网络服务。

* **关键词组A（状态限定）：** "状态会话（Stateful Session）", "长存活会话（Long-lived Session）", "面向会话语义", "会话完整性", "文件传输任务（File Transfer Task）", "统计收集（Statistics Collection）"。

* **关键词组B（均衡策略限定）：** "异步负载均衡（Asynchronous Load Balancing）", "延迟发起均衡", "任务/作业完成（Completion of Task/Job）", "不允许强行中断（Non-forced interrupt）", "优雅暂停（Graceful pause）", "等待进行中任务结束（Waiting for ongoing tasks to end）", "均衡后切换状态（Change status after balancing）"。

**检索目标示例（结合目标专利特征）：**

例如，检索公开了在集群式网元管理服务器上，检测到负载均衡时，不会立即通过强行切断长存活统计会话来重启实例，而是标记在这些会话对应的后台文件分发或查询交易任务处理完成后（once tasks are completed），才更新该实例状态，允许新的会话在新实例上建立，从而实现异步均衡的文献。这种证据将完美填补将D2逻辑嫁接到D1领域的鸿沟。

希望上述基于经验丰富的专利代理师角度做出的深度比对与策略分析对您有用。

你好。作为一名经验丰富的专利代理师，我仔细研读了目标专利（CN106068626B）的说明书和权利要求1，以及对比文件D1（US2003/0126265A1）。

以下是基于目标专利说明书对权利要求1的合理解释，以及紧密结合对比文件原文的特征比对和创造性分析。

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

在解释权利要求时，我们必须紧密结合目标专利说明书的公开内容，以确定技术术语的真正含义、所述方法解决的技术问题以及达到的技术效果。

#### 1. 权利要求1的技术方案整体分析

权利要求1保护一种在多个网络管理处理元件（即运行网络管理应用实例的计算实体/服务器）上分发网络管理处理负载的方法。该方法采用了一种协作集群的架构，包含以下关键要素：

* **集群头部（Cluster Head）：** 负责监控负载、更新集群状态。

* **集群跟随（Following）：** 集群成员跟随（匹配）集群头部更新的状态。

* **再均衡时机（Timing）：** 在检测到负载不均衡时，更新集群状态以发起再均衡，但必须满足一个特定条件——“一旦所述集群的至少一个子集处理的任务已经完成”。

#### 2. 关键技术特征的说明书依据与解释

* **“网络管理处理元件” (Network management processing element)：**

* **说明书依据：** [0001]、[0004]。

* **解释：** 指运行网络管理应用实例的计算实体（例如，部署在刀片式服务器上的进程）。这些应用实例水平缩放，每个执行所管理的网络的一小部分负载（管理特定的网络元件NE）。

* **“集群的成员” (Member of a cluster) 与 “集群头部” (Cluster head)：**

* **说明书依据：** [0021]、[0042]、[0060]、图5。

* **解释：** 所有元件共同构成一个协作集群。集群头部是从成员中选出的（例如，通过最低ID或最早成员规则，[0060]），负责整体协调。说明书强调这是“分布式动态负载均衡”，不存在单点失败，因为任何实例失败，剩余实例可通过均衡补偿，并选出新的头部（[0085]）。

* **“更新集群状态” 与 “跟随所述集群状态”：**

* **说明书依据：** [0043]、[0056]、[0058]、图7。

* **解释：** 这是一种**异步协同**机制。集群头部设置一个总的“集群状态”（例如，从运行S2变为暂停Sn-1），个体成员自主且异步地检查该状态，并执行必要操作使自身状态匹配集群状态（[0058]）。这避免了复杂的集中控制和强同步，提高了系统的鲁棒性和灵活性。

* **“一旦所述集群的至少一个子集处理的任务已经完成”：**

* **说明书依据：** 背景技术 [0005]-[0007]（指出现有技术中集中控制、要求所有NE和实例协作关停、重启的问题），发明内容 [0010]、具体实施方式 [0063]、[0064]、图10。

* **解释：** 这是本发明的核心改进点。它针对网络管理应用与NE之间存在“状态会话语义”（会话期长，不易关停，[0005]）的问题。该特征意味着，负载均衡**不是**强制立即关停所有成员，而是允许元件在“处理的任务已经完成”（例如，收集完统计文件，[0063]）后再进入暂停状态准备再均衡。这允许在暂停操作前完成所有进行中的传送（[0063]）。

* **解决的技术问题：** 现有技术在水平缩放的管理应用实例间重分布网络元件（NE）时，由于NE与实例间面向会话的语义，导致重分布需要集中控制、强协作、甚至强制关闭/重启，不灵活且自动化难度高（[0007]）。

* **技术效果：** 通过集群状态引导各成员异步、自主地在完成当前任务后暂停，实现了鲁棒、灵活且高自动化的分布式动态负载均衡，避免了强制中止长会话任务导致的数据丢失或系统震荡。

---

### 第二部分：特征比对表格

以下紧密结合对比文件D1的原文，指出各技术特征的详细出处，并给出特征比对表格。

**对比文件D1信息：**

* **公开号：** US 2003/0126265 A1

* **公开日：** 2003年7月3日

* **名称：** Request queue management

D1公开了一种用于控制计算网格（computing grid）的方法和装置，该网格可逻辑划分为多个虚拟服务器农场（VSF），每个VSF可动态改变CPU数量以适应流量变化（摘要，[0049]）。D1特别描述了一个实施例，即使用请求队列来处理工作请求，并提及了“人类干预”和“请求阻塞”（[0189]-[0201]）。

---

### 第三部分：创造性分析

作为代理师，我将进行整体创造性分析，并确定最接近的对比文件。

#### 1. 确定最接近的对比文件 (Closest Prior Art)

从整体解决的技术问题和技术效果角度分析：

* **目标专利（CN106068626B）**：

* **解决问题：** 针对网络管理应用与元件之间具有面向长会话的语义，水平缩放时集中控制、强协作关停NE导致系统不灵活、自动化难度高的问题。

* **技术手段：** 采用异步协同的集群架构（头部设置状态，成员异步完成任务后匹配状态），在重新均衡前明确等待“正在处理的任务完成”。

* **技术效果：** 鲁棒、灵活、高自动化的分布式网络应用动态负载均衡，避免强制中止任务，提高系统稳定性。

* **对比文件D1 (US2003/0126265A1)**：

* **技术领域和核心架构：** 计算网格控制，VSF动态逻辑划分。

* **技术手段：**

1. **架构：** 高鲁棒性的Master/Slave控制平面（特征A）。通过选举产生的Master监控负载，控制Slave动态分配/取消分配VSF中的CPU成员（特征B1, B3）。这解决了网格资源分配、可用性和经济性的问题。

2. **请求队列管理：** [0189]-[0201]部分主要解决是个别请求需要“人类干预”的问题，它是将特定请求在“开始处理前”在队列中**阻塞**。

* **技术效果：** 实现网格资源弹性的自动调整、经济性。请求阻塞提高了安全性或处理特定审批流程。

**代理师分析结论：**

* **对比文件D1是唯一的对比文件，且其技术领域（计算网格资源管理）与目标专利（分布网络管理架构负载均衡）非常接近。其整体Master/Slave协同架构、选举机制、以及通过动态分配/删除CPU成员（VSF自动伸缩）来实现負荷均衡的方法，公开了权利要求1特征A的绝大部分和特征B的部分内容。**

* **虽然D1提及了“请求阻塞”和“暂停”，但其解决的技术问题是处理“人类干预”，技术手段是阻塞个别未开始任务，未描述针对长会话正在进行任务的优雅处理。** 目标专利核心解决由于长会话导致再均衡时需集中控制强关停的问题，采用了完全不同的协同机制和时机控制。

* **然而，由于D1公开了除关键特征B2之外的绝大部分架构和方法流程，基于“三步法”，D1是做最接近对比文件的最佳且唯一选择。**

#### 2. 最薄弱的技术特征

请求方如果要提出无效请求，**最薄弱（最难以论证为显而易见）的技术特征是特征B2：**

> “一旦所述集群的至少一个子集处理的任务已经完成，则所述集群头部更新所述集群状态”

**论证其创造性的核心理由如下：**

* **D1不仅未公开该特征，还给出了不同的技术导向。** D1描述的“人类干预阻塞请求”（[0189]-[0201]）并未解决，也未预见到目标专利所面临的问题：在长会话场景下如何优雅地进行系统级的再均衡流程。D1是将任务阻塞在未开始阶段，而目标专利是等待已开始任务完成。

* **结合本发明整体架构的协同机制。** 特征B2不仅是一个时机（Timing），它更是目标专利所采用的“异步 synergistic（Synergy，协同）集群管理”的一部分。说明书描述了各成员自主、异步地检查集群状态，在完成当前任务后设置完成标记（[0065]），全部完成标记设置后，集群头部再将状态转变为“运行”（[0065]、[0082]）。这是一种独特的异步协商机制。D1是Master强制Slave执行分配/取消分配指令，更倾向于集中式控制，未给出此类异步协商且等待已任务完成的启示。

#### 3. 创造性结论

鉴于关键技术特征B2未被D1公开，且该特征结合整体架构巧妙解决了网络管理应用场景特有的长会话语义导致的再均衡难题，取得了避免任务强制中止、提高系统鲁棒性和自动化程度的技术效果，且D1并未给出相应的启示，因此，**权利要求1具有创造性。**

---

### 第四部分：进一步检索策略

若需要对该发明进行进一步的新颖性/创造性检索（例如，为无效宣告请求做准备），检索点应**聚焦于特征B2：即“在动态负载均衡流程中，优雅地（Gracefully）处理元件上正在进行的、长任务，等待其完成后再真正暂停/重新均衡”的技术手段。** 具体的检索方向建议如下：

#### 1. 关键词和IPC的细化

* **关键词组：**

* (负载均衡 或 負荷均等 或 水平缩放 或 弹性伸缩 或 NE分发) AND (任务处理 或 会话完成 或 长任务 或 优雅处理 或 数据传送完成 或 暂停处理) AND (集群 或 協作 或 异步协同 或 头部跟随)。

* (Load Balanc* 或 Horizontal Scal* 或 Auto Scal* OR Elastic* ) AND ( Task finish* 或 Session complet* 或 Graceful* shut*down OR Waiting processing finish* ) AND ( Cluster OR Coordin* OR Asynchronous协同 OR Follow* state )。

* **IPC：** 聚焦于负载均衡（G06F9/50）、网络管理（H04L41/xx）、网络数据交换（H04L12/24）。

#### 2. 聚焦的专利类别和具体场景

* **场景1：** **状态会话语义（Stateful Session Semantics）的网络协议或应用。** 寻找那些涉及由于底层连接（如报警收集、性能文件传输）长期存在，不易关停，因而在进行管理元件水平缩放（Scaling）时，设计了优雅关闭（Graceful Shutdown）机制，即允许当前正在进行的任务在真正断开连接或负载转移之前完成的专利。

* **场景2：** **具有选举或动态Master功能的分布式协调系统。** 检索如Apache ZooKeeper、Etcd等强协调软件或其相关专利，寻找那些在变更配置（变更资源分配）时，各成员不仅仅是机械执行指令，而是包含类似于“等待当前事务/任务完成”再回复头部，进而推动系统进入下一状态的协同专利。

* **场景3：** **网管应用或业务应用软件厂商。** 重点检索如Ericsson、Nokia、Cisco、华为等主要通信设备商在网络管理系统架构方面的早期专利，这些厂商对长会话的网管 NE 管理最为了解。

通过上述分析和检索策略，可以更加精准地评估权利要求的稳定性。

作为一个经验丰富的专利代理师，我将紧密结合目标专利说明书（CN106068626B）来解释权利要求1，并结合对比文件D1（US20050262246A1）和D2（US20090027402A1）的原文进行详细的创造性比对分析。

### 第一部分：权利要求1的代理师解释与技术特征分解

目标专利（CN106068626B）的核心是解决在分布式网络管理架构中，由于网络管理应用与被管理元件之间存在“状态会话语义”（说明书[0005]），导致传统的基于负载测量直接重分布的均衡策略难以实施（会话中断、需要重启实例）的问题（说明书[0006]-[0007]）。

目标专利提出的技术方案是一种“自主且异步”的协作均衡机制。

**权利要求1：**

一种在多个网络管理处理元件上分发网络管理处理负载的方法，每个网络管理处理元件是集群的成员，一个成员是更新集群状态的集群头部，并且所述集群的成员跟随所述集群状态，所述方法包括：

所述集群头部监控在所述集群的成员上的网络管理处理负载；以及

在检测到所述集群负载不均衡时，一旦所述集群的至少一个子集处理的任务已经完成，则所述集群头部更新所述集群状态，以发起在所述至少一个子集上的网络管理处理负载的自动再均衡。

根据说明书的记载，我将权利要求1分解为以下两个核心技术特征，以便后续比对：

* **技术特征A（集群架构与监控）：**

* 应用场景：在多个**网络管理处理元件**上分发网络管理处理负载。

* 架构特征：每个元件是集群成员；存在一个**集群头部**用于**更新集群状态**；其他成员**跟随该集群状态**。

* 动作特征：集群头部**监控**成员上的网络管理处理负载。

* **技术特征B（基于任务完成状态的异步均衡发起）：**

* 触发条件：检测到集群负载不均衡。

* 核心限定（均衡时机）：**“一旦所述集群的至少一个子集处理的任务已经完成”**。

* 执行动作：集群头部**更新所述集群状态**，以发起自动再均衡。

**代理师深度解析：**

特征B是本发明的核心发明点。紧密结合说明书[0005]、[0006]和[0013]、[0063]，此处的“任务已经完成”在网络管理语境下，特指在暂停操作或状态转变之前，允许进行中的面向会话的任务（如文件传送、交易会话）处理完成，而不是强行中断。例如，说明书[0063]提到：“当被要求转变到暂停状态时，集群成员可以延缓任一新的文件传送，不过在暂停操作之前完成所有进行中的传送。”这种“一旦任务完成”才更新状态并发起再均衡的设计，实现了在保持网络管理状态会话完整性的前提下进行动态负载均衡。

---

### 第二部分：对比文件原文分析与特征比对

我将分别分析对比文件D1和D2是否公开了上述技术特征。

#### 1. 对比文件D1 (US2005/0262246 A1) 分析

D1公开了一种用于实时流媒体的、基于集群的可扩展架构中的负载均衡存储和流媒体请求的系统和方法。

**特征比对表格（D1 vs. 目标专利）：**

**D1分析结论：**

D1公开了基于集群的负载均衡架构，其中一个成员可作为中央调度器（集群头部）监控其他成员负载，这与特征A高度对应（除了具体的网络管理应用领域）。但是，D1未能公开核心特征B，即以“任务已经完成”作为更新集群状态和发起自动再均衡的前提条件。在实时流媒体语境下，D1倾向于立即通过复制机制应对高负载，而不是等待特定处理子集的当前任务流完成。

#### 2. 对比文件D2 (US2009/0027402 A1) 分析

D2公开了一种控制主机系统中体现的多模式并行图形处理系统（MMPGPS）的并行操作模式的方法。

**特征比对表格（D2 vs. 目标专利）：**

**D2分析结论：**

D2在多GPU并行图形处理架构中公开了特征A。关键在于特征B，尽管领域不同（图形vs.网络管理），D2的技术方案高度相关。D2公开了根据负载监控结果，动态自动控制并行模式（即负载在GPU间的分发策略，属一种再均衡）。D2明确界定，这种状态/模式的转变是以“帧”为单位进行剖析（[0046]），并在帧终止（如执行Flush and Swap操作）之后进行（[0385]）。这意味着D2实质公开了“一旦（帧处理）任务已经完成”才更新集群状态并发起再均衡。

---

### 第三部分：创造性分析——最接近对比文件的选择

在创造性分析中，确定哪个对比文件适合做最接近的对比文件（D1还是D2），需要结合目标专利整体解决的技术问题和达到的技术效果进行评估。

* **技术问题：**

目标专利旨在解决在具有“状态会话语义”的分布式网络管理系统中，如何自动化地实现动态负载均衡，同时保持状态会话不被强行中断（说明书[0005]-[0007]）。

* **对比文件分析：**

* **D1（流媒体服务器集群）：**

* **优点：** 同样是网络服务语境（D1是媒体流服务，目标专利是网络管理服务），面临在处理流/会话（媒体播放请求）时的负载均衡问题。领域上更接近。

* **缺点：** D1未能提供目标专利的核心技术特征B（即等待当前任务完成的异步发起机制）。D1的复制均衡倾向于立即执行以保证实时性，这与目标专利解决如何不重启实例、不中断会话的问题的技术手段不同。

* **D2（多模式图形处理）：**

* **优点：** 尽管是非网络管理领域，但其处理的任务（3D图形渲染）具有极强的会话/状态限定特征（以帧为单位）。为了在模式切换（均衡策略调整）时保持渲染结果的有效性，D2采用了明确的“状态/模式转变跟随任务单元（帧）完成（ termination）”的技术手段（[0385]），且D2也强调保留状态一致性（ state validity [0248]）。这与目标专利利用“一旦任务完成”才更新状态以避免会话重启的技术问题和手段具有高度的实质相关性。

* **缺点：** 具体应用领域（GPU处理）与网络管理存在差异，部分术语如“网络管理处理元件”未完全对应。

* **最接近对比文件的建议：**

作为请求方代理师，我建议将**对比文件D2（US2009/0027402A1）适合做为最接近的对比文件**。

**分析理由（整体问题与效果角度）：**

最接近对比文件的选择不仅看应用场景，更看重实质解决的技术问题和采用的技术逻辑。

目标专利不仅需要一个集群均衡架构（D1和D2都提供），其核心发明点在于均衡的发起时机（特征B）应当与当前正在进行的任务的完成状态挂钩（异步均衡），以解决保持状态会话的技术问题。D2（图形模式切换）比D1（流媒体复制均衡）更深刻地公开了这一特定技术逻辑：为了维持状态有效性（[0248]），在任务完成（帧终止[0385]）之间进行均衡模式状态更新（[0370]）。

---

### 第四部分：请求方最薄弱的技术特征分析与检索策略

作为请求方代理师，我必须客观地指出目前证据链中针对权利要求1对于请求方来说**最薄弱的技术特征**。

基于以上比对，特征B已被D2实质公开。目前最薄弱的特征（即没有被任何一篇对比文件完美公开的特征）在于**特征A的应用场景限定**：

**薄弱特征限定：** **“所述方法包括：...所述集群头部更新所述集群状态，以发起...网络管理处理负载的自动再均衡。”**

**分析：**

本申请权利要求1被撰写为一种特定的应用方法（“一种在多个网络管理处理元件上分发...的方法”）。虽然D2公开了类似的均衡技术架构和利用任务完成完成均衡的技术手段，但其明确限定在GPU图形处理领域。

**审查难点预计：**

专利权人（代理师）在应对基于D2的创造性挑战时，其最强有力的防御理由（说明书[0005]、[0006]）将是：网络管理领域中由于具有特定的“状态会话语义（如长存活的统计收集、配置操作会话）”，使得人工分配或集中控制困难。虽然D2公开了以任务为单位均衡图形模式，但网络管理中的会话远比图形帧复杂，不能直接应用图形学技术。

因此，请求方仅仅证明上述技术手段在图形处理中是常识是不够的。

#### 进一步检索策略建议：

为了克服上述最薄弱环节，需要进行**具体的领域针对性检索**，目的是找到在“网络管理”或“网络应用服务”领域（而非图形学领域）中公开了针对状态会话利用任务完成状态进行异步均衡的证据。

**进一步检索策略：**

* **应用领域：** 网络管理系统（NMS），网元管理系统（EMS），电信运营支持系统（OSS），网络会话均衡器，或由于会话（Session）特性难以水平扩展的网络服务。

* **关键词组A（状态限定）：** "状态会话（Stateful Session）", "长存活会话（Long-lived Session）", "面向会话语义", "会话完整性", "文件传输任务（File Transfer Task）", "统计收集（Statistics Collection）"。

* **关键词组B（均衡策略限定）：** "异步负载均衡（Asynchronous Load Balancing）", "延迟发起均衡", "任务/作业完成（Completion of Task/Job）", "不允许强行中断（Non-forced interrupt）", "优雅暂停（Graceful pause）", "等待进行中任务结束（Waiting for ongoing tasks to end）", "均衡后切换状态（Change status after balancing）"。

**检索目标示例（结合目标专利特征）：**

例如，检索公开了在集群式网元管理服务器上，检测到负载均衡时，不会立即通过强行切断长存活统计会话来重启实例，而是标记在这些会话对应的后台文件分发或查询交易任务处理完成后（once tasks are completed），才更新该实例状态，允许新的会话在新实例上建立，从而实现异步均衡的文献。这种证据将完美填补将D2逻辑嫁接到D1领域的鸿沟。

希望上述基于经验丰富的专利代理师角度做出的深度比对与策略分析对您有用。

根据权利要求1所述的方法，其中再均衡所述网络管理处理负载的步骤包括：在当前任务的处理完成后，暂停所述多个成员的子集的每个成员的操作；在所述子集的所有成员暂停后，自动再均衡所述网络管理处理负载。

根据权利要求2所述的方法，其中所述自动再均衡负载的步骤包括：从该集群的开始成员池中加入网络管理处理元件至该子集；或者将网络管理处理元件从该子集移除至该集群的开始成员池。

根据权利要求2或3所述的方法，其中所述自动再平衡负载的步骤包括：该子集的至少一个成员运行负载均衡算法，以根据在集群成员之间共享的处理负载数据，设置由所述网络管理处理元件处理的网络管理处理负载。

根据权利要求1‑3的任一项所述的方法，其中所述方法进一步包括：检测该集群已经将状态从第一状态改变到第二状态；一旦正处理的任务已经完成，将集群成员的状态从第一状态改变为第二状态。

根据权利要求5所述的方法，其中所述改变集群成员状态的步骤包括：在当前任务的处理完成后暂停成员的操作；将集群成员的状态从第一状态改变为第二状态。

根据权利要求5所述的方法，进一步包括：出现触发事件时检查集群状态；其中触发事件包括时限超期或者网络事件的至少一个。