一种用于在软件定义联网SDN中支持多租赁的方法，所述方法包括：由处理实体（10）向虚拟网络系统的SDN控制实体（20）发送请求（S1），；以针对由所述处理实体（10）处理的应用执行具体功能；以及由所述处理实体（10）在所述请求中向所述SDN控制实体（20）指示（S1）与所述应用相关联的虚拟网络运营商的标识； 由所述SDN控制实体（20）接收（S1）所述请求； 由所述SDN控制实体（20）基于所述虚拟网络运营商的标识执行（S2）所述具体功能，；其中所述SDN控制实体（20）将所述请求包括在所述SDN控制实体（20）和提供所述具体功能的服务实体（30）之间的封装协议中，；并且将包括在所述封装协议中的请求传送给所述服务实体（30）； 由所述服务实体（30）接收（S3）和处理（S4）包括在所述封装协议中的请求； 由所述服务实体（30）使用所述封装协议向所述SDN控制实体（20）返回（S5）对所述请求的响应； 由所述SDN控制实体（20）接收（S5）使用所述封装协议的响应； 由所述SDN控制实体（20）评估（S6）所述响应；以及在评估了所述响应之后，由所述SDN控制实体（20）对从所述处理实体（10）接收的请求进行响应（S7）。

你好，我是你的专利代理师。针对目标专利 **CN106464743B**（以下简称“本申请”）的权利要求1，我将结合说明书及两份对比文件 **D1 (US20130054761A1)** 和 **D2 (CN103067268A)** 进行深度解析与比对分析。

### 一、 目标专利权利要求1 技术内幕解析

本申请的核心发明点在于**SDN架构下的多租户支持机制**。

* **背景痛点：** 在多租户（多运营商）环境下，像 DHCP、DNS 这种服务实体（Service Entity）通常不支持识别“虚拟网络运营商标识（VNO ID）”。如果要支持多租户，通常需要修改这些现有的标准协议，成本极高。

* **本申请方案：** 引入了一个**“封装协议（Wrapper/Container Protocol）”**（对应特征F-J）。SDN控制器不直接修改原始服务请求（如DHCP请求），而是将其“套”在一个封装协议里，并在封装头部加上VNO ID。这样，服务实体端的“分派器”只需解析封装头就能将请求发给正确的租户实例，而无需修改底层服务协议。

---

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

以下是本申请权利要求1与对比文件 D1、D2 的特征比对：

---

### 三、 详细对比分析与出处说明

#### 1. D1 (US20130054761A1) 分析

* **公开内容：** D1公开了在云环境中利用OpenFlow支持多运营商（Multi-operator）的架构。其[0080]段落明确指出：“The managed services cloud computing facility 1401 runs separate instances of the 3G PC control plane for every mobile operator... Each 3G PC instance is in a VPC 1403A,B that isolates the mobile operator's traffic.”。

* **实质公开部分：** D1公开了多租户的物理隔离和逻辑标识（特征A-E）。

* **差异点：** D1解决多租户的方法是为每个租户运行独立的控制平面实例（VPC隔离）。而本申请权利要求1的核心在于**特征F**：由SDN控制器使用一种“封装协议”与提供具体功能的服务实体（如共享的DHCP服务器）通信。D1虽然在[0005]提到配置开关进行封装（Encapsulate），但那是数据面的GTP封装，不是本申请所述的控制面为适配多租户而对服务协议进行的“二次包装”。

#### 2. D2 (CN103067268A) 分析

* **公开内容：** D2公开了虚拟家庭网关（vHGW）方案。其[0052]段描述：“家庭网关...增加了虚拟局域网（VLAN）标识发送给运营商侧设备”。

* **实质公开部分：** D2公开了利用VLAN ID作为租户标识（特征C），并由服务器（SDN控制实体）基于该标识处理请求（特征E）。

* **差异点：** D2的封装行为发生在路由器上报（Packet-In）阶段（[0103]：“路由器将该DHCP报文封装上报给第一服务器”）。然而，本申请权利要求1的**特征F-I**描述的是：SDN控制实体将请求嵌入封装协议发送给**服务实体**，且服务实体也用该协议返回响应。D2中的“第一服务器”通常被视为集成了业务逻辑的实体，其内部处理流程并未体现出与另一个独立“服务实体”之间通过特定的“Wrapper协议”进行多租户信息的传递。

---

### 四、 无效请求的最薄弱技术特征（即：最具创造性的特征）

如果作为请求人尝试无效此权利要求，**最薄弱（即最难被现有技术覆盖、本申请创造性最强）的技术特征**是：

**特征F及相关特征（G、H、I、J）：**

> “其中所述SDN控制实体（20）将所述请求包括在所述SDN控制实体（20）和提供所述具体功能的服务实体（30）之间的**封装协议**中……由所述服务实体（30）使用所述**封装协议**向所述SDN控制实体（20）返回（S5）对所述请求的响应。”

**理由如下：**

1. **现有技术的惯常做法：** 在SDN中，处理多租户标识通常有两种方式：一是修改北向/南向接口协议以包含租户ID（如修改OpenFlow协议或DHCP协议），二是完全的物理/逻辑隔离（如D1的VPC）。

2. **本申请的非显而易见性：** 本申请提出在控制器与服务实体（30）之间建立一层特殊的“包装（Wrapper）”。说明书[0065]对此解释得非常清楚：“可以避免需要通过向该特定协议添加VNO ID修改与服务实体30相关的每个协议，而是代之以通过向封装/容器协议添加VNO ID”。

3. **技术效果：** 这种“不改原有协议、只加外壳”的方式，使得现有的单租户服务软件能够无缝接入多租户SDN架构。在D1和D2中，虽然都有“封装”和“标识”的术语，但都没有明确公开**“在控制实体与外部服务实体交互过程中，为了透明传输租户标识而专门引入封装协议”**这一架构设计。

[Image of SDN Multi-tenancy Wrapper Protocol Architecture]

**总结建议：**

在进行无效或侵权分析时，应重点审查“服务实体（30）”是否为独立于控制器的实体（如独立的DHCP/DNS服务器），以及两者间的报文是否真的存在一层“壳协议”来承载VNO ID。如果对比文件仅提及了内部处理或通用的协议扩展，则很难挑战该特征的创造性。

你好，我是你的专利代理师。针对目标专利 **CN106464743B**（以下简称“本申请”）的权利要求1，我将结合说明书及两份对比文件 **D1 (US20130054761A1)** 和 **D2 (CN103067268A)** 进行深度解析与比对分析。

### 一、 目标专利权利要求1 技术内幕解析

本申请的核心发明点在于**SDN架构下的多租户支持机制**。

* **背景痛点：** 在多租户（多运营商）环境下，像 DHCP、DNS 这种服务实体（Service Entity）通常不支持识别“虚拟网络运营商标识（VNO ID）”。如果要支持多租户，通常需要修改这些现有的标准协议，成本极高。

* **本申请方案：** 引入了一个**“封装协议（Wrapper/Container Protocol）”**（对应特征F-J）。SDN控制器不直接修改原始服务请求（如DHCP请求），而是将其“套”在一个封装协议里，并在封装头部加上VNO ID。这样，服务实体端的“分派器”只需解析封装头就能将请求发给正确的租户实例，而无需修改底层服务协议。

---

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

以下是本申请权利要求1与对比文件 D1、D2 的特征比对：

---

### 三、 详细对比分析与出处说明

#### 1. D1 (US20130054761A1) 分析

* **公开内容：** D1公开了在云环境中利用OpenFlow支持多运营商（Multi-operator）的架构。其[0080]段落明确指出：“The managed services cloud computing facility 1401 runs separate instances of the 3G PC control plane for every mobile operator... Each 3G PC instance is in a VPC 1403A,B that isolates the mobile operator's traffic.”。

* **实质公开部分：** D1公开了多租户的物理隔离和逻辑标识（特征A-E）。

* **差异点：** D1解决多租户的方法是为每个租户运行独立的控制平面实例（VPC隔离）。而本申请权利要求1的核心在于**特征F**：由SDN控制器使用一种“封装协议”与提供具体功能的服务实体（如共享的DHCP服务器）通信。D1虽然在[0005]提到配置开关进行封装（Encapsulate），但那是数据面的GTP封装，不是本申请所述的控制面为适配多租户而对服务协议进行的“二次包装”。

#### 2. D2 (CN103067268A) 分析

* **公开内容：** D2公开了虚拟家庭网关（vHGW）方案。其[0052]段描述：“家庭网关...增加了虚拟局域网（VLAN）标识发送给运营商侧设备”。

* **实质公开部分：** D2公开了利用VLAN ID作为租户标识（特征C），并由服务器（SDN控制实体）基于该标识处理请求（特征E）。

* **差异点：** D2的封装行为发生在路由器上报（Packet-In）阶段（[0103]：“路由器将该DHCP报文封装上报给第一服务器”）。然而，本申请权利要求1的**特征F-I**描述的是：SDN控制实体将请求嵌入封装协议发送给**服务实体**，且服务实体也用该协议返回响应。D2中的“第一服务器”通常被视为集成了业务逻辑的实体，其内部处理流程并未体现出与另一个独立“服务实体”之间通过特定的“Wrapper协议”进行多租户信息的传递。

---

### 四、 无效请求的最薄弱技术特征（即：最具创造性的特征）

如果作为请求人尝试无效此权利要求，**最薄弱（即最难被现有技术覆盖、本申请创造性最强）的技术特征**是：

**特征F及相关特征（G、H、I、J）：**

> “其中所述SDN控制实体（20）将所述请求包括在所述SDN控制实体（20）和提供所述具体功能的服务实体（30）之间的**封装协议**中……由所述服务实体（30）使用所述**封装协议**向所述SDN控制实体（20）返回（S5）对所述请求的响应。”

**理由如下：**

1. **现有技术的惯常做法：** 在SDN中，处理多租户标识通常有两种方式：一是修改北向/南向接口协议以包含租户ID（如修改OpenFlow协议或DHCP协议），二是完全的物理/逻辑隔离（如D1的VPC）。

2. **本申请的非显而易见性：** 本申请提出在控制器与服务实体（30）之间建立一层特殊的“包装（Wrapper）”。说明书[0065]对此解释得非常清楚：“可以避免需要通过向该特定协议添加VNO ID修改与服务实体30相关的每个协议，而是代之以通过向封装/容器协议添加VNO ID”。

3. **技术效果：** 这种“不改原有协议、只加外壳”的方式，使得现有的单租户服务软件能够无缝接入多租户SDN架构。在D1和D2中，虽然都有“封装”和“标识”的术语，但都没有明确公开**“在控制实体与外部服务实体交互过程中，为了透明传输租户标识而专门引入封装协议”**这一架构设计。

[Image of SDN Multi-tenancy Wrapper Protocol Architecture]

**总结建议：**

在进行无效或侵权分析时，应重点审查“服务实体（30）”是否为独立于控制器的实体（如独立的DHCP/DNS服务器），以及两者间的报文是否真的存在一层“壳协议”来承载VNO ID。如果对比文件仅提及了内部处理或通用的协议扩展，则很难挑战该特征的创造性。

作为一名经验丰富的专利代理师，我将严格依据《专利审查指南》，紧密结合目标专利（CN106464743B）的说明书背景及多租赁（Multi-Tenancy）技术本质，对权利要求1进行拆解，并与两份对比文件（D1: US20130054761A1, D2: CN103067268A）的原文及出处进行逐项特征比对与创造性、无效风险分析。

---

### 一、 目标专利说明书对权利要求的合理解释与技术本质

目标专利解决的核心技术问题是在**软件定义联网（SDN）的多租赁环境**下，如何让高层应用（如P-GW-C、BRAS-C等处理实体）真正独立于底层的网络拓扑和具体的服务实体（如DHCP/DNS/PCE服务器等），同时支持多租户隔离。

根据说明书第`[0065]`段，其技术本质在于**引入了封装协议（Wrapper Protocol / 容器协议）**。SDN控制实体（开放流控制器）在收到处理实体的请求后，不改变原有服务实体（如DHCP服务器）的标准协议，而是**将原有协议分组作为净荷，并在其报头前“预挂起（pre-pending）”虚拟网络运营商的标识（VNO ID）**。这样既实现了多租户标识的透传，又避免了对现有服务实体协议进行伤筋动骨的修改，限制了对现有服务器的影响。

---

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

以下将权利要求1拆解为技术特征A~L，并与对比文件D1、D2的原文进行严谨比对。

---

### 三、 最接近对比文件（D1/D2）的选择与分析

在创造性分析中，**D1 (US20130054761A1)** 最适合作为本专利技术方案的**最接近对比文件**（第一最接近对比文件）。

**分析原因如下：**

1. **领域与技术架构最为接近**：本专利旨在解决SDN网络中的多租赁（Multi-Tenancy）和多虚拟网络运营商（VNO）的隔离支持。D1同样公开了一种利用OpenFlow（SDN）协议在云计算机中实现3G分组核心网（移动核心网）控制面与数据面分离的技术架构。

2. **解决的技术问题重合度极高**：D1的第`[0034]`段及图14明确指出，其解决的技术问题是“如何使托管服务公司能够在单个数据中心内管理**多个运行商网络（Multiple Operator Networks）**，且确保各运营商的信令与数据流量相互隐私和隔离”。这与本专利“SDN中的多租赁/多租户支持”处于完全相同的场景。

3. **技术手段重合度高**：D1公开了处理实体（SGSN/GGSN控制面）向OpenFlow控制器（SDN控制实体）通过RPC发送请求，由控制器识别并隔离配置不同运营商的网元。

*注：D2（CN103067268A）公开的是宽带接入网中的虚拟家庭网关（vHGW）架构，虽然其利用VLAN标识作为家庭租户标识，在广义上也属于多租户范畴，但其核心解决的是家庭网关瘦化、将三层转发业务上移到运营商侧服务器的问题，其架构属于“家庭网关-宽带路由器-第一服务器-标准DHCP服务器”，非电信核心网的多VNO多租赁环境。因此，D2可作为辅助对比文件，证明特征C、E中“利用标识隔离进行多设备/多租户管理”属于本领域的通用技术手段。*

---

### 四、 未被最接近对比文件公开的特征及无效请求突破口分析

#### 1. 未被公开的特征（即本专利的“区别技术特征”）

通过上述比对可知，**技术特征F、G、H、I、J、K**（即“SDN控制实体将请求包括在与服务实体之间的**封装协议（Wrapper Protocol）**中传送、处理并返回”这一整套技术闭环），**既没有被D1公开，也没有被D2公开**。

#### 2. 无效请求方最薄弱的技术特征（即对请求方来说最难攻克的特征）

对于请求方（无效宣告申请人）而言，本专利**最薄弱（即最难打掉、专利权人防御最强）的技术特征是：特征F及其关联的特征G~J——“使用封装协议携带VNO标识，在SDN控制器与标准服务实体之间透传”。**

**原因深度剖析：**

* **技术效果的显著性**：在标准的SDN多租户架构中（如D1所示），为了支持多租户，通常需要要么在云内为每个租户单独实例化一套全套的服务服务器（导致资源浪费），要么必须修改具体的底层应用协议（如修改DHCP、DNS、Diameter等协议报头以加入租户ID），这会导致底层的标准服务器无法兼容。本专利通过在SDN控制器和服务实体之间拉起一层**封装协议报头（Wrapper Header）**，将原始协议分组原封不动作为净荷，只在封装层挂载VNO ID。这一手段成功实现了“在不修改现有大量成熟标准应用服务器协议的前提下，低成本支持多租赁隔离”的技术效果，具有显著的进步。

* **现有技术无暗示**：无论是D1的GTP隧道流表匹配，还是D2中路由器将标准DHCP报文引流给第一服务器，其底层的SDN控制器与传统服务器交互时，均未引入“封装协议/容器协议”来对标准协议进行再次打包。现有技术中缺乏将“Wrapper/封装机制”引入到“SDN控制器与外置标准服务实体交互”以解决多租户透传问题的技术启示。

### 五、 总结与无效策略建议

本案如果发起无效宣告请求：

1. **创造性评述流向**：应以D1为最接近的现有技术（基本公开了SDN架构、多运营商租户隔离、控制实体接收高层应用请求执行具体功能），结合D2（公开了利用VLAN标识在引流时标识具体家庭租户）。

2. **攻坚难点与策略**：特征F~K的“封装协议（Wrapper）”机制是本专利的“坚固堡垒”。请求方若想成功无效该权利要求，**不能仅限于网络路由领域的常规检索**，必须将检索视野扩大至**“分布式计算、云计算多租户隔离、通用网关/中间件通信协议”**等上位领域，寻找是否存在“在通用协议外层封装Wrapper报头以透传租户标识，从而避免修改底层微服务/传统服务协议”的公知常识或对比文件。否则，仅凭目前案卷中的D1和D2，权利要求1由于特征F的存在，将具有极高的稳定性。

根据权利要求1所述的方法，其中 所述具体功能是根据DHCP和ATM中的至少一个的针对用户实体的地址分配，和/或所述具体功能是针对网络实体的地址分配，和/或所述服务实体（30）是DHCP服务器、DNS、PCE服务器、Diameter服务器和H.248服务器中的至少一个，和/或所述封装协议的净荷包括DHCP分组、DNS协议分组以及PCEP分组中的至少一个。

根据权利要求2所述的方法，其中，在所述处理实体和/或所述用户实体和/或所述网络实体中分离用户平面和控制平面。

根据权利要求2所述的方法，其中，所述请求和指示与在所述处理实体（10）和所述SDN控制实体（20）之间交换消息一起执行，以用于在所述用户实体和另一用户实体之间建立隧道和/或用于在所述用户实体和所述网络实体之间建立隧道和/或用于在所述网络实体和另一网络实体之间建立隧道。

根据权利要求2至4中任一项所述的方法，其中 所述处理实体（10）包括处理设备和/或应用，和/或所述SDN控制实体（20）包括SDN控制设备和/或应用，和/或所述网络实体包括网络设备和/或应用，和/或 所述用户实体包括用户设备和/或应用，和/或 所述服务实体（30）包括服务设备和/或应用。

一种用于在软件定义联网SDN中支持多租赁的系统，所述系统包括处理实体（10）、SDN控制实体（20）和服务实体（30），其中，所述处理实体（10）包括： 用于向虚拟网络系统的SDN控制实体（20）发送请求以针对由所述处理实体（10）处理的应用执行具体功能的装置；以及用于在所述请求中向所述SDN控制实体（20）指示与所述应用相关联的虚拟网络运营商的标识的装置； 所述SDN控制实体包括： 用于接收所述请求的装置；以及 用于基于所述虚拟网络运营商的标识执行所述具体功能的装置，其中所述SDN控制实体（20）被配置为将所述请求包括在所述SDN控制实体（20）和提供所述具体功能的服务实体（30）之间的封装协议中，并且将包括在所述封装协议中的请求传送给所述服务实体（30）； 其中所述服务实体（30）被配置为接收和处理包括在所述封装协议中的请求，并且使用所述封装协议向所述SDN控制实体（20）返回对所述请求的响应，以及其中所述SDN控制实体（20）被配置为接收使用所述封装协议的响应，评估所述响应，以及在评估了所述响应之后，对从所述处理实体（10）接收的请求进行响应。

根据权利要求6所述的系统，其中 所述具体功能是根据DHCP和ATM中的至少一个的针对用户实体的地址分配，和/或所述具体功能是针对网络实体的地址分配，和/或所述服务实体是DHCP服务器、DNS、PCE服务器、Diameter服务器和H.248服务器中的至少一个，和/或所述封装协议的净荷包括DHCP分组、DNS协议分组以及PCEP分组中的至少一个。

根据权利要求7所述的系统，其中，在所述处理实体和/或所述用户实体和/或所述网络实体中分离用户平面和控制平面。

根据权利要求7所述的系统，其中用于发送的装置和用于指示的装置包括与在所述处理实体（10）与所述SDN控制实体（20）之间交换消息一起的所述请求和所述指示，以用于在所述用户实体和另一用户实体之间建立隧道和/或用于在所述用户实体和所述网络实体之间建立隧道和/或用于在所述网络实体和另一网络实体之间建立隧道。

根据权利要求7至9中任一项所述的系统，其中所述处理实体（10）包括处理设备和/或应用，和/或所述SDN控制实体（20）包括SDN控制设备和/或应用，和/或所述网络实体包括网络设备和/或应用，和/或 所述用户实体包括用户设备和/或应用，和/或 所述服务实体（30）包括服务设备和/或应用。