一种管理第一网络（10）的方法，至少一个用户设备（11、12、13、14）和网关设备（18）连接到所述第一网络（10）；所述网关设备还连接到第二网络（20）；并且被配置成与容纳在第二网络中的虚拟网关应用（28）合作；并且其中特定的网关功能由虚拟网关应用而不是由网关设备执行；所述特定的网关功能包括网络地址转换、防火墙功能、路由、动态主机配置协议和域名系统中的至少一个；所述方法包括如下步骤；在所述至少一个用户设备（11、12、13、14）中容纳辅助虚拟网关应用（28A）；所述辅助虚拟网关应用（28A）被配置用于在网关设备（18）与虚拟网关应用（28）之间的通信丢失时提供虚拟网关应用（28）的特定的网关功能中的至少一些。

作为一名专业的专利代理师，在深入解析目标专利（权利要求1）与三份对比文件（公开号分别为 **CN103873339A**、**EP2782316A1**、**EP2782318A1**）的技术方案后，现为您出具以下专业的权利要求解释、特征比对、最接近对比文件选择、无效请求薄弱特征分析及后续检索策略。

---

## 一、 本案权利要求1的技术特征拆解与说明书解释

为了准确划定保护范围并进行新颖性/创造性比对，首先依据目标专利说明书对权利要求1进行技术特征拆解与合理解释：

* **技术特征 A**：`至少一个用户设备（11、12、13、14）和网关设备（18）连接到所述第一网络（10）`

* **说明书解释**：第一网络通常指局域网/本地网络（如家庭网、企业内网），用户设备（如手机、PC、智能终端）与本地网关设备（如Home Router、 CPE、Residential Gateway）均接入该第一网络。

* **技术特征 B**：`所述网关设备还连接到第二网络（20）`

* **说明书解释**：第二网络通常指广域网、运营商网络或云端网络（如Internet、蜂窝核心网/PDN）。网关设备作为第一网络与第二网络之间的桥梁。

* **技术特征 C**：`被配置成与容纳在第二网络中的虚拟网关应用（28）合作；并且中特定的网关功能由虚拟网关应用而不是由网关设备执行`

* **说明书解释**：即“云化网关”或“网关功能上移/卸载（Offloading）”。原本由本地物理网关设备承担的核心网关功能（如NAT、路由等）被剥离，改由部署在第二网络（云端/服务器）中的虚拟网关应用（vGW App）来实际执行，物理网关设备仅作为数据转发或配合接续的通道。

* **技术特征 D**：`所述特定的网关功能包括网络地址转换、防火墙功能、路由、动态主机配置协议和域名系统中的至少一个`

* **说明书解释**：限定了被云化/虚拟化的具体网关功能类型（NAT, Firewall, Routing, DHCP, DNS中的至少一种）。

* **技术特征 E**：`在所述至少一个用户设备（11、12、13、14）中容纳辅助虚拟网关应用（28A）`

* **说明书解释**：在局域网内部的用户终端（UE）本地安装/部署一个轻量级或备份性质的网关应用（Auxiliary vGW App），作为云端主虚拟网关应用的本地备份。

* **技术特征 F**：`所述辅助虚拟网关应用（28A）被配置用于在网关设备（18）与虚拟网关应用（28）之间的通信丢失时提供虚拟网关应用（28）的特定的网关功能中的至少一些`

* **说明书解释**：**核心发明点/容灾备份机制**。当本地网关与云端虚拟网关之间的网络连接中断（通信丢失）时，由用户设备上容纳的辅助虚拟网关应用接管并提供基本的网关功能，确保局域网内通信或本地服务的连续性。

---

## 二、 对比文件特征比对明细表

为清晰对比，将三份对比文件分别简称为：

* **D1**：CN103873339A（《一种虚拟网关路由器的分配方法和装置》）

* **D2**：EP2782316A1（《Localizing and placement of network node functions in a network》）

* **D3**：EP2782318A1（《Allocating resources between network nodes for providing a network node function》）

### 特征比对表格（附原文详细出处）

---

## 三、 整体解决的技术问题、技术效果与最接近对比文件选择

### 1. 各对比文件解决的技术问题与效果分析

* **目标专利**：

* **解决的技术问题**：在“云化/虚拟化网关”架构下，当本地网关设备与云端虚拟网关（第二网络）之间的通信链路发生中断故障时，会导致局域网内用户设备无法获得必要的网关服务（如路由、DHCP、NAT等），造成网络瘫痪。

* **技术效果**：通过在本地UE中预先部署“辅助虚拟网关应用”，在云端通信丢失时由UE本地接管网关功能，实现了极低成本且高可靠的**网络中断容灾保护（Fail-over/Survivability）**。

* **D1 (CN103873339A)**：

* **解决的技术问题**：解决大二层跨站点互联网络中，三层流量跨隧道无效往返浪费带宽的问题。

* **技术效果**：通过站点标识与VRRPE主设备感知，就近分配同站点的虚拟网关。

* **D2 (EP2782316A1)**：

* **解决的技术问题**：解决云服务/网络功能在网络中的部署位置无法根据客户端需求灵活优化的技术问题（降低延时、减少网络开销）。

* **技术效果**：根据客户端上下文动态决定将网络节点功能（如网关、防火墙）放置在最合适的云端/网络节点（第二节点）。

* **D3 (EP2782318A1)**：

* **解决的技术问题**：解决服务器资源瓶颈及网络延迟问题，实现网络节点资源的有效分配与功能卸载（Offloading）。

* **技术效果**：将第二节点的网络功能/服务器功能透明地卸载到第一节点（客户端）或第三方节点运行。

### 2. 最接近对比文件的确定

在创造性评估中，**D2 (EP2782316A1)** 和 **D3 (EP2782318A1)** 均适合作为**最接近的对比文件（第一最接近对比文件与平行最接近对比文件）**：

1. **首选最接近对比文件：D2 (EP2782316A1)**

* **理由**：D2与本发明的**架构与技术领域最为契合**。D2明确提出了将网关功能（Internet Gateway, DHCP, NAT, Firewall等）从本地（第一节点）虚拟化并部署到云端/第二网络节点（第二节点）上运行，完整覆盖了权利要求1的前序部分（特征A、B、C、D）。

2. **平行最接近对比文件：D3 (EP2782318A1)**

* **理由**：D3提出了网络功能的“卸载（Offloading）”概念，且明确包含了将部分网络/服务器功能下发到客户端设备（Client Device）运行的机制（覆盖了部分特征E）。

---

## 四、 审查与无效视角下的创造性与薄弱特征分析

针对以 **D2 为最接近对比文件** 的创造性路线分析：

### 1. 区别技术特征

将权利要求1与最接近对比文件D2对比，区别技术特征为：

> **区别特征 1（对应特征E+部分F）**：在至少一个用户设备（UE）中容纳辅助虚拟网关应用；

> **区别特征 2（对应特征F核心）**：该辅助虚拟网关应用被配置为**在网关设备与云端虚拟网关之间的通信丢失（通信中断）时**，接管并提供特定的网关功能。

### 2. 区别特征是否被其他对比文件（D1、D3）公开？

* **D1** 仅涉及数据中心大二层网关冗余，未公开在UE中部署辅助网关应用，也未公开通信中断时由UE接管网关功能的机制。

* **D3** 虽然公开了将网络/服务器功能卸载到客户端设备（Client Device）上执行，但其目的在于“利用客户端空闲资源缓解服务器压力”或“降低正常通信延时”，**完全未涉及/未公开“在主网关与云端通信丢失故障时，作为辅助备份应用（Auxiliary App）启动以提供容灾接管”的触发条件和技术方案**。

### 3. 无效请求中最薄弱的技术特征（即本专利的“坚固防线”）

在提出专利无效请求时，**最薄弱（即最难被现有技术组合无效掉、本专利最坚固）的技术特征是：**

> **特征 F 及其与特征 E 的组合**：`所述辅助虚拟网关应用被配置用于在网关设备与虚拟网关应用之间的通信丢失时提供虚拟网关应用的特定的网关功能中的至少一些`。

* **薄弱原因分析（对无效发起方而言）**：

1. **技术偏离与结合阻碍**：现有技术（如D2、D3）对网关虚拟化的研究重点在于“性能优化”、“流量卸载”或“云端冗余（云端节点A切换到云端节点B）”。而本特征解决的是**“云端不可达/断网”**这一特定故障场景下的**本地生存（Local Survivability / Standalone operation）**问题。

2. **显而易见性不足**：从“云端虚拟网关”跨越到“在终端UE上预装辅助网关进行断网接管”，并非本领域的公知常识或常规选择。通常本领域技术人员的思维惯性是在本地物理网关设备（Router）上做双机热备（如VRRP），而不是将网关功能直接下放到普通用户终端（UE）上作为辅助备份。

---

## 五、 进一步的对比文件检索策略（针对无效请求）

为了成功发起无效宣告，必须打破**特征F（通信丢失时的UE本地容灾接管）**的防御。建议采取以下精准检索策略：

### 1. 检索方向与核心技术概念转换

不要局限于传统的“路由器分配”或“云网关”，应将检索重点转向以下技术领域：

1. **LTE / 5G 专网与边缘计算的“本地生存/断网自愈”机制（Local Survivability / Standalone mode / Breakout）**：

* 例如：在蜂窝网络（5G MEC / Local UPF）中，当MEC与 Central Core（中心核心网）通信中断时，本地网关/终端接管会话的机制。

2. **VoIP / IMS 领域的“本地存活代理”（Local Survivable Processor / Survivable Remote Site Telephony, SRST）**：

* 在IP电话体系中，当分支机构与总部云端PBX断连时，分支机构的终端或本地节点自动切换为临时PBX提供路由和呼叫功能。

3. **SD-WAN 与 软网关（vCPE）的高可用备份机制**：

* 当 vCPE 与云端控制器（Cloud Controller）Link-Down 时，客户端设备（Customer Premises Endpoint / Client）上的 Controller Agent 触发本地接管。

### 2. 关键词与逻辑检索式构建（以英文/中文数据库为例）

* **核心控制词组 1（网关/网络功能虚拟化）**：

`"virtual gateway"` OR `"vGW"` OR `"virtual router"` OR `"vCPE"` OR `"cloud gateway"` OR `"network function virtualization"` OR `"NFV"`

* **核心控制词组 2（终端/客户端部署）**：

`"user equipment"` OR `"UE"` OR `"client device"` OR `"terminal"` OR `"user device"`

* **核心控制词组 3（通信丢失/故障断连）**：

`"communication lost"` OR `"link failure"` OR `"connection loss"` OR `"disconnection"` OR `"unreachable"` OR `"outage"`

* **核心控制词组 4（容灾接管/本地生存/备份）**：

`"fallback"` OR `"failover"` OR `"survivability"` OR `"local breakout"` OR `"backup"` OR `"take over"` OR `"stand-alone"`

**推荐组合检索式**：

$$\text{((virtual NEAR/2 gateway) OR vCPE OR (cloud NEAR/2 gateway))} \ \text{AND}$$

$$\text{(UE OR "user equipment" OR "client device")} \ \text{AND}$$

$$\text{((loss OR failure OR disconnect*) NEAR/3 (communication OR connection OR link))} \ \text{AND}$$

$$\text{(fallback OR failover OR survivab* OR "take over" OR backup)}$$

### 3. 重点专利分类号（IPC / CPC）锁定

建议限定以下IPC/CPC分类号进行交叉检索：

* **H04L 41/0659**：网络故障管理 — 恢复、切换或冗余保护机制（Failover / Disaster Recovery）

* **H04L 45/28**：利用备用路径应对网络故障的路由机制（Link Failure Routing）

* **H04L 67/10**：分布式或云端网络中的服务与功能分配（Network Function Placement）

* **H04L 12/66**：网关互连（Gateway Interconnection）

---

### 总结建议

若您拟针对该目标专利发起无效宣告，目前D1-D3已成功覆盖了权利要求1的绝大部分前序架构特征。**无效成功的唯一突破口在于找出一篇公开了“在云端/主网关断连故障下，利用终端（UE）上的辅助应用/软件进行网关功能接管/本地生存”的技术文件**。建议按照上述检索策略，重点在 **5G边缘计算（MEC）本地生存** 以及 **SD-WAN/vCPE 断网容灾** 领域的专利和标准草案（如 3GPP TS 23.501/23.502 关于 MEC Local Survivability 的讨论）中进行深度追溯。

作为一名处理过大量通信与云网络领域无效案的专利代理师，我将为你对涉案权利要求1进行深入的法律与技术剖析。

在专利无效宣告与侵权诉讼实践中，**“权利要求的解释”**必须紧密结合说明书的本意。本案权利要求1的核心逻辑在于**通过网络架构演进实现网关功能（如NAT、DNS等）的虚化与下沉**。

---

### 一、 权利要求1的解构与技术特征拆解

我们首先对权利要求1进行特征拆解（特征A~F）：

* **特征A**：至少一个用户设备（11、12、13、14）和网关设备（18）连接到所述第一网络（10）；

* **特征B**：所述网关设备还连接到第二网络（20）；

* **特征C**：被配置成与容纳在第二网络中的虚拟网关应用（28）合作；并且特定的网关功能由虚拟网关应用而不是由网关设备执行；

* **特征D**：所述特定的网关功能包括网络地址转换（NAT）、防火墙功能、路由、动态主机配置协议（DHCP）和域名系统（DNS）中的至少一个；

* **特征E**：在所述至少一个用户设备（11、12、13、14）中容纳辅助虚拟网关应用（28A）；

* **特征F**：所述辅助虚拟网关应用（28A）被配置用于在网关设备（18）与虚拟网关应用（28）之间的通信丢失时提供虚拟网关应用（28）的特定的网关功能中的至少一些。

---

### 二、 对比文件原文比对分析与特征对照表

我们在分析对比文件时，引入两个公开文件：

* **D1**：WO2014146996A1（公开日：2014-09-25）

* **D2**：WO2014147000A1（公开日：2014-09-25）

#### 权利要求1与D1、D2的技术特征比对表

---

### 三、 最接近的对比文件（D1 vs D2）分析

从技术领域、解决的技术问题及技术效果来看：

#### 1. D1（WO2014146996A1）

* **技术领域与问题**：侧重于移动通信网络（LTE/3GPP）中，如何通过在云端（Cloud/Second Network Node）动态放置网络功能（Network Node Functions，如网关、DHCP、防火墙等），以降低网络延迟、优化资源配置并避免传输网（Backhaul）拥堵（[p0004]-[p0013]）。

* **匹配度**：D1的网络拓扑（UE - Home Router/eNodeB - Cloud Virtual Network Node）与本专利的架构完全贴合，完整阐述了虚拟网关应用在第二网络（云端）中的部署与运行。

#### 2. D2（WO2014147000A1）

* **技术领域与问题**：侧重于如何利用客户端（First Network Node/Client Device）及其周边可用的本地计算资源，将服务器/网关的功能“下沉/卸载”（Offload）到客户端本地运行（[p0017]-[p0022]）。

* **匹配度**：D2完美覆盖了**特征E（在UE中部署辅助应用/卸载功能）**，并详细说明了客户端如何宣告本地资源并运行卸载的网络功能。

#### 结论：

**D1 适合作为最接近的对比文件。**

* **理由**：D1从整体上构建了“网络网关功能虚拟化并置于远端云网络”的主架构（特征A、B、C、D、E），其解决的降低网关冗余、提升接入灵活性等问题与本专利最为接近。D2可作为结合对比文件，用于论证将网关功能卸载至UE端（特征E）是本领域的公知常识或常规选择。

---

### 四、 无效分析中最薄弱的技术特征与突破口

在对权利要求1进行创造性攻击（如中国专利法第22条第3款或EPC Art. 56）时，**最薄弱的技术特征（即审查员或专利权人最容易守住防线的特征）是：特征F**。

> **特征F**：*“所述辅助虚拟网关应用（28A）被配置用于在网关设备（18）与虚拟网关应用（28）之间的通信丢失（loss of communication）时提供虚拟网关应用（28）的特定的网关功能中的至少一些。”*

#### 薄弱性分析（为什么特征F是防守要塞）：

1. **D1与D2的局限**：

* D1提及了云端的 Fail-over（故障转移）和负载均衡（[p0017]），但其 Fail-over 是在**云服务提供商（CSP）之间**进行服务器复制和转移，并没有教导当“网关与云端虚拟网关通信丢失”时，由**UE端**的辅助应用接管。

* D2提及了当UE端资源变化时重新调整功能分配（[p0074]），但其触发条件是资源动态调整，而非**“主通信链路丢失”**这一容灾/容错场景。

2. **专利权人的反驳点**：专利权人会强调“通信丢失下的本地降级/容灾接管”产生了意想不到的技术效果——即在网络中断（如断网、光纤切断）的极端情况下，UE自身能够作为“微型网关”维持局域网内的基础服务（如本地DNS解析、本地DHCP分配），确保局域网不瘫痪。

---

### 五、 进一步的对比文件检索策略（针对特征F的精准打击）

为了彻底无效掉权利要求1，下一步的检索策略必须**放弃纯粹的“NFV/SDN网络架构”宏观检索，转而聚焦于“边缘计算/终端容灾（Edge Local Survivability/Failover）”的细分场景**。

具体检索策略如下：

#### 1. 核心技术主题词与逻辑构建

针对特征F，需将**【网关/虚拟网关】+【通信中断/链路失效】+【终端/UE接管/本地降级模式】**进行组合：

* **表达“网关/虚拟功能”**：`Virtual Gateway`, `vGW`, `vCPE`, `Virtual Network Function`, `VNF`, `Edge Gateway`

* **表达“通信丢失/中断”**：`Communication loss`, `Connection loss`, `Link failure`, `Disconnection`, `Outage`, `Fallback`, `Network failure`

* **表达“UE/终端接管或本地运行”**：`Local survival`, `Survivability`, `Local breakaway`, `Stand-alone mode`, `On-device fallback`, `Local host`

#### 2. 重点检索分类号（IPC / CPC）

* **H04L 41/0654**：网络故障管理；通过切换到备用组件或路径进行恢复（Fault recovery using backup components）。

* **H04L 67/10**：分布式应用；中央与边缘/终端之间的协调与备份。

* **H04L 61/00**：网络中的寻址/域名解析（针对NAT/DNS/DHCP在本地断网时的容灾）。

* **H04W 24/04**：无线通信网络中的故障管理与容灾。

#### 3. 推荐的精准检索公式（以CPC/Keywords为例）

```text

(vCPE OR "virtual gateway" OR "virtual network function" OR VNF OR "router")

AND ("link failure" OR "connection loss" OR "network disconnected" OR "outage")

AND ("local mode" OR "survivability" OR "fallback" OR "on-device" OR "user equipment")

AND (DHCP OR DNS OR NAT OR routing)

```

#### 4. 重点关注的文献来源与技术标准（3GPP / Broadband Forum）

* **3GPP TR/TS 规范**：重点检索与 **ProSe (Proximity-based Services)**、**LIPA/SIPTO (Local IP Access)** 以及 **5G LAN/Unconnected/Offline Mode** 相关的标准提案（TDoc）。在3GPP规范中，当UE与蜂窝网失连时，UE切换为 Group Owner 或 Local Gateway 维持局域网通信是经典方案。

* **Broadband Forum (BBF) TR-317 (vCPE Architecture)**：BBF在2014-2015年前后大量讨论了虚拟家庭网关（vCPE/vG）在WAN口断网（Loss of WAN connection）时，本地LAN侧如何通过CPE或终端进行本地生存（Local Survivability）的标准架构。

---

### 总结建议

1. **组合无效方案**：以 **D1（或D2）作为第一对比文件** 结合 **公知常识** 铺垫基本架构（特征A-E）；

2. **补充检索**：补检索一篇明确公开**“网关与云端断连时，终端/本地节点启动辅助应用接管NAT/DHCP/DNS等网关功能以实现本地生存”**的对比文件D3；

3. **最终突破**：采用 **D1 + D3 (+ D2)** 的组合，以“特征F属于本领域为了解决网络断连容灾问题而采用的常规技术手段”为由，彻底攻破权利要求1的创造性。

作为一名经验丰富的专利代理师，我将为您对该目标专利的权利要求1进行深度解析，并结合给出的三份对比文件（D1、D2、D3）进行实质性技术特征比对，为您梳理出无效宣告请求阶段的最优策略、最薄弱特征及后续检索方向。

---

### 一、 权利要求1的技术特征分解

为了进行精确的比对，首先将权利要求1的方法拆解为以下6个独立的技术特征：

* **特征A（前序部分）**：一种管理第一网络（10）的方法，至少一个用户设备（11、12、13、14）和网关设备（18）连接到所述第一网络（10）；

* **特征B（前序部分）**：所述网关设备还连接到第二网络（20）；

* **特征C（前序部分）**：被配置成与容纳在第二网络中的虚拟网关应用（28）合作；并且其中特定的网关功能由虚拟网关应用而不是由网关设备执行；

* **特征D（前序部分）**：所述特定的网关功能包括网络地址转换（NAT）、防火墙功能、路由、动态主机配置协议（DHCP）和域名系统（DNS）中的至少一个；

* **特征E（步骤部分）**：在所述至少一个用户设备（11、12、13、14）中容纳辅助虚拟网关应用（28A）；

* **特征F（步骤部分）**：所述辅助虚拟网关应用（28A）被配置用于在网关设备（18）与虚拟网关应用（28）之间的通信丢失时提供虚拟网关应用（28）的特定的网关功能中的至少一些。

---

### 二、 对比文件技术特征公开情况分析（结合原文出处）

#### 1. 对比文件D1：US20030012204A1 (Extension of fibre channel addressing)

* **技术领域**：基于光纤通道（Fibre Channel, FC）协议的存储区域网络（SAN）的数据传输与地址扩展。

* **特征公开分析**：

* **特征A、B**：D1公开了在一个SAN内部包含交换机和网关（Gateway 26），网关连接本地SAN A并连接到耦合通道54以连接到另一个SAN B（参见原文`[0011]`、`[0053]-[0054]`）。这与通用网络中的第一网络、第二网络、用户设备与网关的拓扑有一定对应性。

* **特征C、D**：D1的网关主要执行的是“地址转换（本地地址与全局虚拟地址的映射）”（参见原文`[0013]`、`[0054]`），但这种转换是依靠物理网关26内部的定制集成电路（ASIC）中的硬件转换表（Table 31, 33）来实现的（参见原文`[0054]`），**而非由容纳在外部第二网络中的“虚拟网关应用”来代替物理网关执行**。

* **特征E、F**：D1在`[0014]`和`[0074]`中提到了“网关冗余”（Gateway Redundancy），即当一个网关或链路断开时，数据可以通过同一个SAN中的另一个备用物理网关（如Gateway 102机制）流出。但是，**D1完全没有公开在“用户设备/客户端”中容纳辅助虚拟网关应用来做容灾备份的机制**。

#### 2. 对比文件D2：CN1956440A (家庭网络系统)

* **技术领域**：采用生活网络控制通信协议（LnCP）的家庭网络系统。

* **特征公开分析**：

* **特征A、B**：D2公开了家庭网络系统1通过网关10连接到因特网2（外网），内网包含网络管理器20-23（主控设备）和各类电器设备40-49（从属设备）（参见原文【图1】及“具体实施方式”第3段）。

* **特征C、D**：D2中虽然提到了外部存在LnCP服务器3，但该服务器的作用是接收控制命令、储存信息或提供内容下载（参见“具体实施方式”第2段），家庭网络内部的控制、协议堆栈处理、网点地址识别仍然是由本地的网络管理器、路由器或电器设备自身完成，**并非将特定的网关功能移交到云端的虚拟应用上执行**。

* **特征E、F**：未公开。D2仅在“具体实施方式”第4段提到网络管理器可以是“混合设备”，逻辑上同时执行主控和从属功能，用于与其他网络管理器进行情报同步，但**不涉及在上行通信丢失时由用户设备托管网关功能**的容灾设计。

#### 3. 对比文件D3：US20110299543A1 (Method and System for Providing Virtual Gateway Services)

* **技术领域**：提供虚拟网关服务的通信系统（核心领域完全相同）。

* **特征公开分析**：

* **特征A、B（毫无异议公开）**：公开了本地/家庭网络中的本地设备（Devices 104a-104d）和专用的、被剥离简化功能的本地网关设备（Dedicated gateway device 102b）连接到本地网络，且网关设备通过分发网络110连接到云端（Cloud 112）（参见原文`[0062]`、`[0066]`及【图1A】）。

* **特征C、D（毫无异议公开）**：明确公开了“虚拟宽带网关102”包含网络部分102a（部署在云端/网络设备140的虚拟机141上）和本地部分102b。**网关功能被分配在网络侧的虚拟机上执行，本地网关设备102b被大幅度简化（"stripped down"）**（参见原文`[0068]`）；其执行的功能明确包括数据格式转换、加密解密、路由/交换等（参见原文`[0060]`、`[0069]`、`[0085]`）。这与特征C、D完全吻合。

* **特征E（实质公开）**：D3在`[0077]`、`[0079]`和【图1B】、【图1C】中明确指出：“虚拟宽带网关102可以分布式部署在本地设备1041-104N上（distributed over the devices）...根据本地设备的性能和容量来分担资源和网关功能”。由于本地设备104（如电视、电脑）分担并容纳了虚拟网关的本地部分功能，这在实质上等于**在至少一个用户设备中容纳了辅助或本地的虚拟网关应用**。

* **特征F（未明确公开）**：D3虽然在`[0077]`、`[0084]`等段落中提到了根据设备的可用性、带宽和能耗动态分配/调度这些分布式功能，但其**未明确公开“当本地网关设备与云端虚拟网关应用之间的通信丢失时，由用户设备中的应用来接管并提供特定的网关功能”这一特定的容灾触发条件和控制逻辑**。

---

### 三、 权利要求1与对比文件的技术特征比对表

---

### 四、 最接近的对比文件（D1-D3）选择与创造性评述

#### 1. 最接近的对比文件：**D3 (US20110299543A1)**

* **理由**：

1. **技术领域及整体解决的技术问题完全一致**：D3与目标专利均属于现代网络通信技术中“虚拟网关/云化网关”这一细分领域，解决的都是如何将传统物理网关的重度计算功能移向云端虚拟机（瘦客户端化），以及如何利用本地网络设备资源进行分布式网关功能扩展的问题。而D1属于传统的存储局域网（SAN）光纤通道架构，D2属于传统的智能家居控制总线协议（LnCP），外延较远。

2. **技术特征覆盖度最高**：从上表可见，D3已经公开了权利要求1中除“通信丢失作为触发条件接管功能（特征F）”之外的几乎所有前序拓扑特征和核心架构特征（特征A、B、C、D、E）。

* **技术效果与最薄弱特征分析**：

* **最薄弱的技术特征：特征F**。

* 在以D3为最接近的对比文件（D1）的基础上，目标专利权利要求1相对于D3的**实际解决的技术问题**是：“当瘦网关架构在面临上行链路故障（云端失联）时，如何确保本地网络基础功能的连续性与容灾自愈”。

* 目标专利给出的手段是：利用本就容纳在用户设备（UE）中的辅助应用（28A）作为“影子网关”，在检测到心跳或通信丢失时，动态激活本地的NAT/路由/DHCP等基础网关功能。

#### 2. 特征F是否被D1或D2公开？

* **结论：没有。**

* D1面对链路丢失（Fail）时，采用的是经典的“**双物理网关冗余**”（见D1的`[0014]`："complete gateway redundancy is achieved"），即通过Gateway 26和Gateway 102两个硬件实体互相备份，这完全不同于目标专利“由用户设备（终端）虚拟接管”的思路。

* D2完全未涉及云端失联后的自愈机制。

* 因此，**仅凭当前的D1、D2、D3三份文件组合，权利要求1具有创造性，无法被成功无效**。

---

### 五、 进一步的无效请求检索策略（针对特征F）

既然目前的D3+D1/D2组合无法攻下最薄弱的“特征F”，为了成功提出无效宣告请求，必须进行精准的补充检索。以下是为您制定的进一步检索策略：

1. **确定检索关键词与逻辑表达式**：

* **核心控制逻辑**：通信丢失、链路断开、失联、故障、云端不可达、Link fail\*、Communication lost\*、Disconnect\*、Connection failure。

* **备份/接管行为**：辅助、备用、本地接管、影子、代理、恢复、自愈、Backup\*、Auxiliary\*、Take over\*、Failover\*、Local fallback、Local proxy。

* **执行主体**：用户设备、终端、电视、手机、客户端、User Equipment、Client\*、End device\*、STA、STB。

2. **寻找经典的“本地坍塌/本地自治”技术通用常识（Bridge the Gap）**：

* 在传统电信/网络网络云化（如SD-WAN、云路由、虚拟CPE/vCPE）的发展过程中，“当vCPE与云端控制器（Controller）失联时，本地设备（如Thin CPE或本地LAN内的主机）启动本地DHCP/NAT以维持局域网互通”是极为经典的容灾设计。

* **重点检索方向**：建议重点检索2008年~2013年期间，思科（Cisco）、华为（Huawei）、中兴（ZTE）、锐捷或电信运营商（如AT&T、中国电信）关于**“虚拟CPE（vCPE）故障自愈”**、**“SD-WAN边缘设备本地生存（Local Survivability）”**或**“混合云网关逃生通道”**的相关专利。

3. **目标检索文献类型**：

* 寻找一份公开了“在云网关架构下，终端（如STB/PC）在物理网关与云端失联时激活本地网关服务功能”的对比文件（作为新的D2）。将其与当前的D3（作为D1）进行组合，以“特征F属于本领域在面临链路故障时为了保证业务连续性而普遍采用的惯用技术手段/容灾常识”为由，完成对权利要求1创造性的完全摧毁。

作为一名经验丰富的专利代理师，我将紧密结合目标权利要求1的技术方案，对对比文件D1、D2、D3进行细致的侵权/无效技术特征比对与创造性分析。

首先，为便于清晰表述，对三份对比文件明确公开号代称：

* **D1**：CN102571474A 虚拟化的Radius测试系统及方法

* **D2**：US20130166723A1 DUPLICATE IP ADDRESS DETECTION BY A DHCP RELAY AGENT

* **D3**：US20130166737A1 DUPLICATE IP ADDRESS DETECTION BY A DHCP RELAY AGENT （注：D3为D2的延续案，核心技术公开内容基本一致）

---

### 一、 权利要求1技术特征比对表格

以下将权利要求1分解为技术特征A至F，并与各对比文件的原文及详细出处进行客观比对（“+”表示公开，“-”表示未公开，“/”表示实质等同/高度相关）：

---

### 二、 对比文件技术特征毫无异议公开/实质公开的详细分析

#### 1. D2 (US20130166723A1) & D3 (US20130166737A1)

D2与D3的核心架构极度贴近本申请的前序部分（特征A、B、C、D）：

* **特征A、B、D的毫无异议公开**：

* **原文出处**：D2 Paragraph \[0015\] / D3 Paragraph \[0016\] 指出：“system 100 includes a plurality of DHCP clients 135_1-4 located across two subnets 140_1,3... connected to a intranetwork 120 via DHCP relay agents 125_1-2.”。

* **解析**：这完美对应了第一网络（子网140）、用户设备（DHCP客户端135）及网关设备（DHCP中继代理125），且网关设备连接至第二网络（内部网络120）。其执行的特定功能为“动态主机配置协议（DHCP）”，属于特征D的并列选项之一。

* **特征C的实质公开**：

* **原文出处**：D2 Paragraph \[0066\] / D3 Paragraph \[0067\] 指出：“Cloud computing generally refers to the provision of scalable computing resources as a service over a network... the cloud resources could be communicatively coupled across multiple subnets and a DHCP relay agent configured with a duplicate IP detection component 650 could reside between two of these subnets.”。

* **解析**：在此云操作环境下，核心的DHCP应用（DHCP server application 580）运行在云端虚拟化架构中，即属于“容纳在第二网络中的虚拟网关应用”，且正常情况下特定网关功能（DHCP分配）由其执行。

#### 2. D1 (CN102571474A)

D1主要公开了一种虚拟化的RADIUS**测试系统**。

* 它公开了“虚拟化网关模块（1）...虚拟了大部分现实网关硬件单元”\[0046\]，并能提供诸如“路由”功能（“减少虚拟路由实例所设定的内存空间”\[0067\]）。

* 但是，D1中所有虚拟化网关、独立虚拟机和测试工具的配合，其整体技术出发点是“对AAA/Radius服务器在功能和性能两个方面提供综合的测试服务”\[0005\]，其网络连接关系是为搭建测试拓扑而虚拟出来的。

---

### 三、 最接近对比文件的选择与分析

在创造性分析中，**D2（或其延续案D3）最适合作为本权利要求1最接近的对比文件（D1不适合）**。

#### 1. 技术领域与解决的技术问题角度

* **目标专利**：解决的是当网关设备与远端第二网络中的虚拟网关应用（云端服务）**通信丢失/中断时**，如何确保第一网络内的用户设备仍能获得特定的网关服务，避免业务彻底中断的问题。

* **D2/D3**：解决的是当网关/中继代理与中心DHCP服务器由于网络问题断开（"network disconnect 230"）或服务器故障导致不可用（"unavailable"）时，**如何进行失效转移（Failover），保证本地子网客户端能持续获得DHCP服务**。其技术问题与目标专利高度一致。

* **D1**：解决的是如何在不消耗大量资金的情况下，快速、动态地**搭建Radius测试环境**。它并不关注由于突发网络中断而带来的冗余备份接管问题。

#### 2. 技术效果角度

* **目标专利与D2/D3**均达到了“在主干网络连接中断时，提供特定网关功能的本地维持，保障网络服务连续性”的技术效果。

因此，**D2或D3是无可争议的最接近对比文件**。

---

### 四、 未公开特征的交叉检索与无效请求最薄弱特征

通过上述比对可以发现，无论是D1、D2还是D3，均**没有完全公开特征E和特征F**。

#### 1. 最薄弱的技术特征（对无效请求方而言最难攻克的点）

本权利要求1的核心发明点（最具创造性的部分）在于**特征E + 特征F的结合**：

> **将“辅助虚拟网关应用（28A）”容纳在“用户设备（11-14）”内**，并在网关与云端通信丢失时，由**用户设备本地的辅助应用**来替代执行特定的网关功能。

* **对比文件的痛点**：在D2/D3中，网络断开（230）时，执行备份接管功能（担任backup DHCP server）的“失效转移组件130”是运行在**网关设备（DHCP中继代理120/125）**上的。

* **无效最薄弱特征**：网关设备坏了，或者网关与云端断开了，传统的做法（如D2）是在网关上做本地代理。而目标专利将其做在“用户设备（Client）”上。因此，“**在用户设备中容纳辅助虚拟网关应用并在通信丢失时接管网关功能**”是无效请求中**最难攻克、也是最薄弱的技术特征**。目前案卷中的D1、D2、D3均未公开“由客户端/用户设备去容纳并接管特定网关功能”的手段。

---

### 五、 进一步的对比文件检索策略

为了成功无效掉权利要求1，必须针对上述“最薄弱特征”（用户设备容纳辅助应用在网关通信丢失时接管服务）进行精准的补充检索。建议采取以下策略：

#### 1. 扩展关键词与功能性检索

不要局限于“网关”或“DHCP”等具体功能，应放大至**分布式计算、边缘计算（Edge Computing）、对等网络（P2P）以及哑客户端演进为胖客户端/本地代理**的机制。

* **中文控制词/关键词**：

* (用户设备 OR 客户端 OR 终端 OR 手机 OR PC) 控制 (容纳 OR 内置 OR 运行 OR 托管) 具有 (本地代理 OR 影子应用 OR 辅助 OR 备用 OR 冗余)

* (网关中断 OR 链路丢失 OR 掉线 OR 脱机 OR 离线模式) 控制 (接管 OR 代替 OR 维持功能 OR 本地解析)

* **英文控制词/关键词**：

* (UE OR "user equipment" OR "client device" OR terminal) 3A (host* OR container* OR run*) 5A ("local proxy" OR "fallback application" OR "backup agent" OR "shadow gateway")

* ("communication loss" OR "link failure" OR "offline mode" OR disconnect*) 3A (takeover OR fallback OR "local execution")

#### 2. 变换IPC/CPC分类号检索

除了传统的通信网关分类号外，重点引入计算机软件架构和分布式应用接管的分类号：

* **H04L67/289**（通过在终端用户或客户端设备上执行的临时或专门的代理来适应或改变应用服务的协议）；

* **H04L67/10**（分布式应用，如云、P2P等在断连时的本地容错机制）；

* **H04L41/0654**（使用中继、备份或失效转移恢复网络故障）。

#### 3. 目标领域锁定（寻找“离线本地接管”的实际应用场景）

在物联网（IoT）、智能家居（Smart Home）或SD-WAN（软件定义广域网）领域，这种“网关断连，终端接管”的架构非常常见。

* **典型场景检索**：例如在智能家居中，当本地网关（Router/Hub）与云端服务器断开时，智能手机App（用户设备）或某个高算力的智能终端可以通过内置的本地微服务（辅助虚拟应用）临时接管路由、NAT或DNS解析功能，维持家庭物联网的运转。建议向智能家居巨头（如涂鸦智能、小米、苹果、谷歌、华为）的智能物联网本地联动/离线控制相关专利进行定向检索。

根据权利要求1所述的方法，包括如下进一步的步骤；当网关设备（18）与虚拟网关应用（28）之间的通信丢失时，利用辅助虚拟网关应用（28A）。

根据权利要求1或2所述的方法，在所述至少一个用户设备（11、12、13、14）中容纳辅助虚拟网关应用（28A）的步骤之前，包括如下进一步的步骤；询问所述至少一个用户设备用户设备是否能够容纳辅助虚拟网关应用；询问优选地由虚拟网关应用（28）执行。

根据权利要求1或2所述的方法，其中不止一个用户设备（11、12、13、14）连接到第一网络；并且辅助虚拟网关应用（28A）被容纳在不止一个用户设备中。

根据权利要求1或2所述的方法，进一步包括在网关设备（18）中容纳激活应用的步骤；所述激活应用被配置用于在网关设备（18）与虚拟网关应用（28）之间的通信丢失时激活辅助虚拟网关应用（28A）。

根据权利要求1或2所述的方法，其中虚拟网关应用（28）和辅助虚拟网关应用（28A）具有不同但重叠的功能性集合。

根据权利要求1或2所述的方法，其中虚拟网关应用（28） and 辅助虚拟网关应用（28A）中的每个具有DHCP功能性。