一种用于经由网络传输数据的方法，方法包括接收针对可靠的数据的单播传输的请求；通过i）根据虑及可靠的数据递送的可靠的运输协议使用递送确认来格式化数据以获得经格式化的数据以及ii）将经格式化的数据提供到网络而对请求进行响应，经格式化的数据包括目的地地址字段；其中网络是包括一个或多个转发节点的可编程网络，在所述转发节点中用于复制数据的规则是可远程编程的，方法进一步包括控制一个或多个转发节点通过如下来实现经格式化的数据的可靠的多播；j）复制经格式化的数据以获得所复制的经格式化的数据；jj）将所复制的经格式化的数据的目的地地址字段设置成源于针对数据的可靠的单播传输的进一步请求的地址；以及jjj）设置所复制的经格式化的数据的确认编号，使得获得与一个或多个转发节点一致的递送确认。

作为一名经验丰富的专利代理师，我将为您对该目标专利的权利要求1进行深入的法律与技术解析，并结合对比文件D1、D2、D3的原文进行逐项特征比对、创造性评述（最接近对比文件的选择），并指出无效请求中防线最薄弱的特征及后续的检索策略。

---

### 一、 目标专利权利要求1的解析与技术本质

本专利权利要求1的核心发明点在于**“在可远程编程的转发节点（如SDN交换机）处，直接对带有可靠运输协议（如TCP）确认机制的单播数据流进行硬件层面的复制与改写，通过动态修改目的地地址和确认编号（Acknowledgment Number），在网络中间层将单播转化为面向多个单播接收终端的‘拟多播’传输”**。

传统TCP组播需要终端支持特殊协议，或者在应用层代理（如D1的APP路由器）处终止并重建TCP连接，这会消耗巨大的CPU内存资源。本专利通过在**转发节点**直接修改报文的**确认编号**（技术特征F），使得网络既能享受组播的带宽红利，又不会破坏两端原有单播TCP连接的滑动窗口与确认机制，实现了底层微操。

---

### 二、 对比文件公开特征分析及详细出处

#### D1：US20070058629A1 (Application driven fast unicast flow replication)

* **技术领域与解决问题**：解决单播流（Unicast Flow）在服务器端占用过多带宽的问题，通过应用层路由器在网络边缘进行流复制。

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

* **特征A**：公开了接收单播传输请求。[0034]中“...is the first to issue a unicast request for content from content provider...”。

* **特征B**：公开了基于可靠运输协议（如TCP/HTTP）格式化数据。[0006]和[0032]提到利用HTTP/TCP传输单播流。

* **特征D、E**：公开了复制数据并将目的地地址设置为进一步请求的地址。[0031]公开“...replicates the unicast content flows to all client subscribes 415 that have requested the same unicast content.”，且[0039]中公开“...APP router 405 terminates the return unicast content flow and creates a new unicast content flow with a destination address identifying the first client subscriber...”。

* **未公开特征**：D1是通过**应用层路由器（APP Router）**完全**终止（Terminate）**协议栈至应用层，然后为每个客户端重新构建独立的单播连接，**并非在可远程编程的转发节点中通过改写确认编号来保持原有连接的一致性**（未公开特征C、F）。

#### D2：US20120259994A1 (IP BROADCAST STREAMING SERVICES DISTRIBUTION USING FILE DELIVERY METHODS)

* **技术领域与解决问题**：主要涉及使用FLUTE/ALC协议在多播/广播网络中分发DASH分片，并利用临时的单播HTTP流来降低换台延迟。

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

* **特征A、B**：公开了单播流接收与响应，如DASH over HTTP/TCP。[0011]、[0036]公开了利用单播协议引导，再切入多播/广播。

* **未公开特征**：D2完全未涉及可远程编程的网络节点，也未涉及在转发节点复制单播流并修改地址与确认编号的技术方案（未公开特征C、D、E、F）。

#### D3：CN104518973A (一种基于SDN环境的数据的可靠组播传输方法)

* **技术领域与解决问题**：在软件定义网络（SDN）环境中，利用SDN控制器动态计算组播树并下发流表，解决传统UDP组播不可靠、易拥塞的问题。

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

* **特征A**：实质公开。步骤(2-2)及具体实施方式[0061]公开了发送端生成与TCP报文格式相同的握手报文。

* **特征B**：实质公开。步骤(3)及[0067]公开了发送端发出包含目的地地址字段的数据报文，接收端返回确认报文。

* **特征C**：毫无异议公开。说明书[0003]公开“SDN是一种新兴的基于软件的网络架构...在网络控制器端可以获得网络的全局信息...”，步骤(2-3)公开“SDN网络控制器...结合当前的网络拥塞状况获取组播转发树，并将组播转发树下发安装到SDN交换机”。这完全对应“可远程编程的转发节点”。

* **特征D、E**：实质公开（针对握手报文）。步骤(2-4)及[0062]公开“对每一个指定的接收端，SDN网络控制器复制第一次握手报文，将得到的第一次握手报文副本的目标地址修改为该指定的接收端的IP地址”。

* **未公开特征**：D3在步骤(3)进行**实际数据传输**时，发送端是以组播地址（ADDRCONN）为目标地址发送组播报文，由SDN交换机根据组播树分发，接收端再以单播形式直接向发送端反馈ACK（[0051]、[0067]）。D3**并未公开在转发节点（交换机）处复制数据报文并修改确认编号（Acknowledgment Number）以契合单播终端**的方案（未公开特征F）。

---

### 三、 技术特征比对表

---

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

在创造性无效宣告的策略中，本案**最适合作为最接近对比文件的是：D3 (CN104518973A)**。

* **原因分析（技术领域与问题最接近）**：

* **技术领域完全一致**：目标专利与D3均聚焦于**可编程网络/软件定义网络（SDN）**环境，且均旨在解决**“如何在维持传输可靠性的同时进行高效的数据多播分发”**这一技术问题。

* **架构体系最接近**：目标专利要求的“可远程编程的转发节点”在D3中得到了完全的对应（SDN控制器+OpenFlow交换机体系），而D1属于传统的应用层代理服务器架构，网络拓扑和硬件控制级别完全不同。

* **创造性三步法评述（以D3为最接近对比文件）**：

* **区别特征**：目标专利权利要求1与D3相比，主要区别特征在于**技术特征F**（在转发节点处设置复制数据的确认编号，以获得一致的递送确认）。

* **实际解决的技术问题**：如何在无需发送端发送组播报文、且不终止两端TCP连接的前提下，在底层转发硬件上直接支持多路单播数据块的硬件级并发复制与确认匹配。

* **结合分析**：检索发现，D1虽然提到了单播流的复制，但其手段是彻底牺牲传输效率的“应用层协议栈拆包与重建”，并没有给出“在SDN底层交换机上直接修改TCP确认编号”的启示。因此，D3 + D1 的结合无法直接导出特征F，权利要求1具备创造性。

---

### 五、 无效请求中最薄弱与最坚固的技术特征

* **防线最薄弱的特征（极易被宣无效或认可公知常识）**：**特征A、B、C、D、E**。

如果仅看特征C、D、E，D3已经在SDN环境下做到了针对SYN握手报文的“复制、改写目的地IP、下发流表规则”。在控制器集中控制下复制报文并改写目的地IP，属于SDN领域的常规技术手段。

* **防线最坚固的特征（整个无效宣告成败的“天王山”）**：**特征F（jjj：设置所复制数据的确认编号……）**。

这是本专利最不易被攻破的特征（对请求人而言最薄弱、最难找网络证据）。因为TCP的`Seq Number`和`Ack Number`是处于内核态/硬件TCP协议栈强校验的。常规的SDN交换机（如标准OpenFlow交换机）只支持修改L2-L4的地址和端口（如MAC、IP、Port），极少有公开文献指导去动态计算并修改TCP内部的`Acknowledgment Number`（这需要维持状态机并计算数据包长度）。这属于通信协议微操创新，现有对比文件均未实质提及。

---

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

鉴于特征F（转发节点修改TCP确认编号）是目前维持创造性的核心支柱，若要彻底无效该权利要求，必须启动第二轮针对性精准检索：

1. **关键词精准扩展**：

* 针对“确认编号”，扩展检索词：`TCP Acknowledgment number modification`, `ACK spoofing`, `TCP sequence translation`, `TCP stateful rewrite`, `TCP transparent proxy inside switch`.

* 针对“转发节点”，扩展检索词：`P4 programmable switch`, `NetFPGA`, `OpenFlow custom action`, `Data plane programmability`.

2. **技术演进路线检索（高度推荐P4语言标准）**：

本专利提及“规则可远程编程的转发节点”，标准的OpenFlow（D3）难以修改TCP序列号，但在**P4可编程数据平面（Programmable Data Plane）**提出后，高级交换机（如Barefoot Tofino芯片）具备了在数据平面动态修改和计算TCP报文头任意字段的能力。建议重点检索**2013-2015年间关于P4语言、数据平面有状态处理（Stateful processing in data plane）的学术论文（如ACM SIGCOMM, IEEE INFOCOM）**，寻找是否有利用P4交换机修改TCP流量Seq/Ack以实现流复制的先驱文献。

3. **转攻非专利文献（NPL）**：

通信协议栈的底层微操往往最先以开源网络框架或学术论文形式发表。建议检索互联网工程任务组（IETF）的草案（Draft）、RFC的边缘计算/网络编码（Network Coding）组，以及GitHub上关于“SDN有状态防火墙”或“NAT444/NAT64序列号重写”的早期技术白皮书，这些技术可能会隐含“转发节点改写确认号”的底层逻辑。

作为一名经验丰富的专利代理师，针对您提供的目标专利权利要求1以及两份对比文件，我为您进行如下深度的专利法律与技术分析。

### 对比文件指代说明

* **D1**：`CN104811393A`（组播报文复制处理方法、装置及开放流控制器，公开日：2015-07-29）

* **D2**：`WO2011047335A1`（ADAPTIVELY STREAMING MULTIMEDIA，公开日：2011-04-21）

---

## 一、 权利要求技术特征分解与对比文件出处分析

为了客观评价创造性，首先将权利要求1拆解为6个独立的技术特征（A至F），并与D1、D2的说明书原文进行严格的比对和出处追踪。

### 1. D1 (CN104811393A) 的特征比对与出处分析

* **技术特征A (单播请求接收)**：**未实质公开**。D1主要关注的是网络侧（NNI）向用户侧（UNI）的组播流量分发和复制控制（参见D1 `[0012]`、`[0064]`），其核心是解决组播复制带来的带宽浪费，并不涉及接收针对可靠数据的“单播传输”请求。

* **技术特征B (确认机制与单播响应格式化)**：**未公开**。D1提及了终端用户的上线认证触发报文（如DHCP或PPPoE）以及组播变更请求（参见D1 `[0013]`、`[0064]`），但未公开根据“考虑可靠数据递送的可靠运输协议（如TCP）”使用“递送确认”来格式化单播数据以响应单播请求。

* **技术特征C (可编程网络及多播控制)**：**实质公开**。D1明确公开了应用于**软件定义网络（SDN）**架构，其中的开放流交换机（OFSW）即为转发节点，开放流控制器（OFC）可以通过标准化的接口（如OpenFlow协议）下发流表条目和组表条目，从而**远程编程/控制转发节点用于复制数据的规则**，实现组播复制处理。

> **D1原文出处**：`[0007]` “SDN/OpenFlow技术...基础设施层由各个转发设备构成...网络控制层的主要设备是网络操作系统（或称SDN/OpenFlow控制器）...对多台转发设备进行控制”；`[0012]` “将确定的所述流表条目和所述组表条目通过所述OFC下发给所述OFSW，其中，所述OFSW依据所述流表条目和所述组表条目对所述组播组报文进行组播复制处理”。

* **技术特征D (复制经格式化的数据)**：**毫无异议公开**。D1公开了开放流交换机（OFSW）依据组表条目（特别是ALL类型的组表）实施组播报文复制。

> **D1原文出处**：`[0070]` “OFSW通过ALL组表条目中存在的Bucket信息，实施组播报文复制”。

* **技术特征E (修改目的地地址为进一步请求的地址)**：**实质公开（手段略有调整）**。D1在遇到当前节点组播资源不足的特殊场景下，会选择在**上一节点额外复制**组播报文，并**将报文的二层头修改为单播封装（将组播目的MAC修改成特定用户的单播MAC地址）**，从而通过后续路径进行转发。这对应了将复制数据的目的地地址字段设置为源于进一步请求的地址。

> **D1原文出处**：`[0070]` “选择在该路径的上一个节点选择按用户复制，新增一个Bucket...该Bucket中设置动作将组播报文的二层信息改成单播的方式（例如，报文的组播目的MAC修改成用户MAC，组播IP不变）”。

* **技术特征F (设置确认编号以获得一致的递送确认)**：**未公开**。D1的上述单播修改仅针对二层封装（MAC层），并不涉及可编程转发节点去**修改或设置第四层传输层（运输协议）的“确认编号（Acknowledgment Number）”**，以在多播转发中维持与各个转发节点/终端一致的可靠递送确认。

### 2. D2 (WO2011047335A1) 的特征比对与出处分析

* **技术特征A (单播请求接收)**：**实质公开**。D2公开了一种基于**HTTP流媒体的自适应流传输方法**（HTTP Adaptive Streaming）。HTTP协议本身是构建在TCP这一“可靠运输协议”之上的，终端用户向媒体服务器（Media Server）发送特定的多媒体分片请求，媒体服务器接收并响应。在网络术语中，基于标准HTTP/TCP的网页或流媒体分片请求，本质上就是针对可靠数据的单播传输请求。

> **D2原文出处**：`[0008]` "requesting a multimedia segment having the target characteristic"; `[0024]` "Thus, the mobile terminal 120 can access the media server 110 to download multimedia content. More specifically, in one embodiment, the mobile terminal 120 can stream audio or video from the media server 110."

* **技术特征B (可靠协议格式化及目的地字段)**：**实质公开**。如上所述，D2使用**HTTP服务器（HTTP Server 270）**传输MPEG-4、H.264等编码的流媒体段，这些段是通过网络协议栈（隐含包含标准TCP协议，即具备递送确认的可靠运输协议）发送的，报文必然包括标准的IP目的地地址字段。

> **D2原文出处**：`[0026]` "...accessible individually via a HTTP server 270... accessed individually via the HTTP server 270 as individual Internet addresses in one embodiment."

* **技术特征C、D、E、F**：**完全未公开**。D2的整体架构是传统的**“媒体服务器-客户端”的端到端单播演进（针对不同用户发送不同码率的单播切片）**，网络内部（如基站130、网络150）仅执行常规的尽力而为的IP转发。D2完全没有涉及“网络是可远程编程的转发节点”、“在转发节点内复制数据”、以及“在转发节点修改目的地地址和TCP确认编号以实现单播转可靠多播”的技术方案。

---

## 二、 特征比对表格

为了直观呈现各特征的公开情况，总结比对如下：

---

## 三、 最接近对比文件（D1）的确定及创造性评述

### 1. 最接近对比文件的选择：D1 (`CN104811393A`)

在创造性审查或无效宣告程序中，**D1最适合作为本专利的最接近对比文件**。

* **技术领域与解决的技术问题高度契合**：

* **本专利**旨在解决如何在网络内部（利用可编程转发节点）将数据有效地分发给多个提出请求的用户，同时兼顾“可靠性”与“多播效率”。

* **D1**同样处于“软件定义网络（SDN）下的报文分发与复制”技术领域，其解决的技术问题是如何克服传统网络在网关处逐用户复制导致的主干/关键链路带宽浪费，利用全网拓扑和可编程节点能力实现“按需动态复制”。

* 相比之下，**D2**属于纯粹的端到端应用层流媒体码率自适应调节（基于传统单播），其网络层是僵硬难变的，与可编程网络架构不符。

* **技术效果与核心架构接近**：

本专利的核心改良点在于网络是“包括可远程编程复制规则的转发节点的可编程网络”，这正是D1引以为傲的SDN/OpenFlow核心发明点。D1贡献了权利要求1中绝大部分关于网络架构、报文复制和地址改写的下层支撑特征（特征C、D、E）。

### 2. 区别技术特征与创造性缺陷分析

以D1为最接近的对比文件，本专利权利要求1与其相比，存在以下**区别技术特征**：

1. **特征A和特征B的一部分**：本专利的输入端接收的是“可靠数据的单播传输请求”，并在源头使用“可靠运输协议的递送确认”来格式化单播数据；而D1接收的是传统的组播组加入请求。

2. **特征F（最核心的区别）**：本专利要求可编程转发节点在复制数据时，**必须设置/改写所复制数据的“确认编号（Acknowledgment Number）”**，从而使网络节点在进行多播复制分发时，能够与后端多个不同的转发节点/接收端达成“一致的递送确认”。

#### 针对区别特征F的法律评价：

特征F展示了本专利的真正发明点：它并非简单的SDN组播，而是一种**在网络内部实现“单播转多播”或“TCP多播加速”的机制**。

普通的可靠协议（如TCP）是严格一对一（单播）的，因为其滑动窗口、序列号和**确认编号（ACK No.）**是端到端强绑定的。本专利为了既利用多播的带宽优势，又保留单播的可靠递送确认，绝妙地让**网络中间的可编程转发节点去代理或拦截改写传输层的“确认编号”**。

D1只公开了为了解决资源不足而在二层将目的MAC改成用户单播MAC，并没有任何关于**在网络中间节点修改运输层协议确认编号以达成多播可靠一致性确认**的启示。D2虽然使用了带确认的HTTP/TCP，但完全是端到端单播，更没有给出在中间节点修改确认编号以支持多播的教导。

---

## 四、 无效请求中最薄弱的技术特征与检索策略

### 1. 最薄弱的技术特征（对无效申请人而言最难攻克、对专利权人最稳固的特征）

**技术特征F：`jjj）设置所复制的经格式化的数据的确认编号，使得获得与一个或多个转发节点一致的递送确认。`**

* **原因分析**：这是将“可编程网络（SDN）”与“传输层可靠协议（TCP）的确认编号改写”进行跨层融合的特征。在传统的网络设计中，中间转发节点（如交换机、路由器）只解析到三层（IP层），极少去动态修改四层（TCP层）的确认编号（除非是NAT或特定的TCP代理网关，但那也不是在多播复制的场景下）。D1和D2在此处均存在严重的**技术盲区**，未能提供任何组合启示。

### 2. 进一步的对比文件检索策略（无效请求突破方案）

为了成功攻克上述薄弱特征F，建议放弃传统的“组播优化”检索方向，转向**“可编程网络中的TCP终止/TCP代理/跨层控制”**领域，采取如下精准检索策略：

* **策略一：变换检索关键词与技术交织点**

* **核心关键词组合**：将（"可编程网络" 或 "SDN" 或 "OpenFlow" 或 "P4"）与（"传输层" 或 "TCP"）以及（"确认号" 或 "确认编号" 或 "acknowledgment number" 或 "sequence number"）和（"复制" 或 "多播" 或 "组播" 或 "multicast" 或 "clone"）进行相交检索。

* **寻找目标**：寻找在可编程网络（特别是支持深度报文解析和修改的P4可编程交换机普及后的技术文献）中，利用中间节点动态剥离或重写TCP头部字段（包括ACK号）以支持某种多路分发或加速的先例。

* **策略二：扩大检索源至学术文献与标准组织草案**

* 该技术特征具有较强的学术超前性，可能最早出现在**计算机网络顶级会议**（如 SIGCOMM, CoNEXT, INFOCOM, NSDI）的论文中。

* 重点检索2010年至2020年期间关于**“Multicast TCP”（多播TCP）**、**“TCP Over SDN”**、**“Programmable In-Network Transport Layer Proxy”（网络内传输层代理）**相关的学术文献。有些学术论文会详细描述如何在可编程交换机上动态维护状态机，为不同的接收方修改TCP的序列号（SEQ）和确认号（ACK），以欺骗两端建立虚假的端到端可靠连接。

* **策略三：追踪大厂在“内容分发网络（CDN）加速”或“数据中心内部网络优化”的专利**

* 重点检索诸如 Cisco、Huawei、Nicira（VMware）、Google、Microsoft 等在数据中心内部为了减少流量冗余而做的私有网络优化专利。数据中心内部为了同时满足大块数据的“可靠传输（TCP）”和“高效分发（组播）”，经常会提出这种在可编程网关/交换机处改写TCP头部的“黑科技”方案。

根据权利要求1所述的方法，其中根据用于通过因特网协议[IP]使用的运输控制协议[TCP]来格式化数据。

根据权利要求2所述的方法，进一步包括如下中的至少一个针对经格式化的数据的分组生成确认编号，并且控制一个或多个转发节点复制具有确认编号的经格式化的数据的分组，以便获得用于所复制的经格式化的数据的分组的相同的确认编号方式；将经格式化的数据和/或所复制的经格式化的数据的分组中的确认控制位 and 确认编号设置成零；以及控制一个或多个转发节点调整经格式化的数据和/或所复制的经格式化的数据的分组中的确认编号以获得与用于TCP确认的规则一致的确认编号方式。

根据权利要求3所述的方法，进一步包括针对特定请求一个接一个地测试在权利要求3中列举的选项中的两个或更多，直至确认消息被接收。

根据权利要求2所述的方法，其中格式化数据以获得经格式化的数据进一步包括使用IP分片将每个分组至少分片成包括确认编号的第一分片和至少包括数据的部分的第二分片；通过单播传输每个分组的第一分片，每个分组的第一分片具有与用于TCP确认的规则一致的确认编号方式；以及将每个分组的第二分片提供到网络以由一个或多个转发节点多播。

根据权利要求2-5中任一项所述的方法，进一步包括在利用同步-确认消息对请求和/或进一步请求进行响应之后，为经格式化的数据 and 或所复制的经格式化的数据的分组提供与相应的同步-确认消息的序列编号一致的序列编号。

根据权利要求6所述的方法，进一步包括在每个同步-确认消息中使用相同的序列编号。

根据权利要求6所述的方法，进一步包括在每个同步-确认消息中使用不同的序列编号；以及控制一个或多个转发节点为经格式化的数据和/或所复制的经格式化的数据的分组提供与相应的同步-确认消息的不同的序列编号一致的序列编号。

根据上面权利要求中任一项所述的方法，进一步包括在将经格式化的数据提供到网络之前，将经格式化的数据的目的地地址字段设置成对应于源于针对数据的可靠的单播传输的请求的接收机地址；或者针对由一个或多个转发节点进行的多播而提供的分离地址。

根据上面权利要求中任一项所述的方法，其中对一个或多个转发节点的控制包括在经格式化的数据被提供到网络之前将一个或多个转发节点预配置用于多播；或者响应于经格式化的数据的第一分组由所述节点接收到而将一个或多个转发节点配置用于多播。

根据上面权利要求中任一项所述的方法，进一步包括如下中的至少一个响应于针对通过经格式化的数据的多播提供的分组的重传的请求，通过单播重传分组；以及响应于针对通过经格式化的数据的多播提供的分组的重传的多个请求，将分组提供到网络以由一个或多个转发节点进行多播。