一种用于一无线通信系统的一接收端中同步一解密参数的方法，其特征在于包含有当一第二协议单元操作于确认模式时；设定一第一协议单元的一接收窗为推进式；且所述接收窗大小大于或等于所述第二协议单元所使用的接收窗大小；其中；所述第一协议单元是一解密单元；并且所述第二协议单元是所述第一协议单元的下层协议单元。

作为一名经验丰富的专利代理师，我将紧密结合目标专利（CN101064594B）的说明书对权利要求1进行深度解析，并结合检索到的三份对比文件（D1: US6415410B、D2: US20020097809A1、D3: JP2003224618A）进行细致的特征比对和创造性评判，最后为您指出诉讼中的最薄弱特征及下一步的检索策略。

---

### 一、 紧密结合说明书对权利要求1的合理解释

目标专利的核心在于解决无线通信系统中，由于上下层协议单元对滑动接收窗类别及大小的配置不当，导致**超视频帧号（HFN）在接收端错误累加（如误将重传包视为下一循环的包），进而造成加解密参数不同步（不同步会导致无法正确解密）或接收窗停滞**的技术问题。

针对权利要求1的技术特征，结合说明书进行如下限定与合理解释：

1. **“第一协议单元”（解密单元）与“第二协议单元”（下层协议单元）**：说明书明确指出，第一协议单元对应于包数据聚合协议层（PDCP）中的解密单元，第二协议单元则对应于无线链接控制层（RLC）或媒体存取控制层（MAC）。

2. **“确认模式”（AM）**：第二协议单元（如RLC）操作于有重传机制的确认模式。

3. **“接收窗为推进式”**：说明书第[0004]段定义，推进式（Push Type）是指**只有在下缘所对应的包被成功接收或被通知删除时，才会推进接收窗的范围**。这意味着解密单元不会因为收到落在当前窗外的较大序号包而盲目向前“拉动”接收窗。

4. **“接收窗大小大于或等于……接收窗大小”**：这是避免错误的核心定量限制。说明书第[0006]和[0028]段给出了反例和正例：若下层接收窗为16（且支持不依序上传），如果解密单元的窗大小仅设为10，当序号为10的包先到时，其因落在窗外会被删除或引起窗停滞。因此，只有当第一协议单元的推进式窗大小 $\ge$ 第二协议单元的操作窗大小时，才能确保下层所有未依序上传的重传包（如序号0）和超前包（如序号10）均落在解密单元的窗内，**从而避免盲目累加HFN**。

---

### 二、 技术特征比对表格

为了清晰展现各对比文件的公开情况，以下将权利要求1分解为特征A~E，并与D1、D2、D3的原文详细出处进行贴合比对：

---

### 三、 最接近的对比文件（D1/D2/D3）分析与评判

在创造性分析中，**最接近的对比文件（D1或D2）**的筛选应当从“整体解决的技术问题”、“技术领域”以及“公开特征数量”三个维度考量。本案中，**D2（US20020097809A1）最适合作为最接近的对比文件**。

#### 1. 为什么选择D2作为最接近的对比文件？

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

* **本发明**解决的是：在无线通信不依序上传（out of sequence delivery）的环境下，由于序列号（SN）循环回绕（rollover），如果接收窗控制不当，会导致接收端将旧包/超前包误判为下一循环，造成高层变量（HFN）同步出错。

* **D2**（背景技术[0007]、[0014]）同样立足于3GPP无线通信环境，其明确指出：由于SN只有12位宽，数值在0~4095之间循环（rollover），如果Capriciously（随意地）重传或推进窗口，接收端会产生混淆（mistake old, retransmitted PDUs for new data），从而导致新旧循环交替出错。为了解决这一问题，D2由范围计算器（Range Calculator）根据下层和高层的互通关系，重新界定重传和接收范围。

* **公开的技术特征最多：** D2完全毫无异议地公开了特征A，并且其实质公开了特征B中关于“推进式”接收窗的运作原理（通过VR(R)的最早包确认来移动窗口下缘），并探讨了窗口大小配置（特征C）。

#### 2. D1与D3为什么不适合单独作为最接近的对比文件？

* **D1 (US6415410B)：** 属于较早期的非透通电路数据流控制技术（如GSM RLP）。虽然它公开了滑动窗、不依序收集和窗口大小的动态调整，但其整体解决的是“当 nominal data transmission capacity（信道带宽）改变时，如何调整窗口大小以避免拥塞或提高吞吐量”的问题，并不涉及SN回绕时高层加解密同步错误这一核心问题。

* **D3 (JP2003224618A)：** 尽管D3公开了特征D、E（涉及HFN超视频帧号的同步，且涉及下层协议如MAC层），但D3整体解决的是“在RLC层RESET和RESET ACK信号传输延迟或丢失时如何避免发送端与接收端HFN失步”的问题，它通过改进重置信令的应答机制来解决失步，完全没有涉及“设定推进式接收窗”及“第一协议单元窗 $\ge$ 第二协议单元窗”这种通过**调整上下层双重窗口大小比对**来解决失步的技术方案。

#### 3. 没有被最接近对比文件（D2）公开的特征，是否被其他对比文件公开？

* D2未明确公开**特征D（第一协议单元是一解密单元）**和**特征E（第二协议单元是解密单元的下层协议单元）**。

* **此二特征已被D3公开：** D3明确公开了在无线通信系统中，利用HFN（超视频帧号，即解密核心参数）进行同步，且高层状态变量依赖于“低い通信層”（较低的通信层，如MAC/物理层，即特征E中的下层协议单元）来传输和调整。

---

### 四、 若提出无效请求，最薄弱的技术特征分析

如果我们要对该目标专利提出无效宣告请求，本权利要求1中**最薄弱（即最容易被攻破、创造性最低）的技术特征是：特征C（接收窗大小大于或等于第二协议单元所使用的接收窗大小）**。

**原因如下：**

1. **属于本领域的常规技术手段或显而易见的逻辑推理：**

在无线通信多层协议架构中，上层（PDCP/解密单元）的数据完全依赖于下层（RLC/下层协议单元）进行依序或不依序的递交。如果下层能够容纳并处理多达 $X$ 个不依序的包（即下层接收窗大小为 $X$），为了让上层解密单元能够顺利接收到下层上传的这些包而不至于因溢出而丢包（避免说明书所述的接收窗停滞），上层接收窗的尺寸必然需要能够“装得下”下层可能递交的最大乱序范围。因此，将上层窗大小设定为 $\ge$ 下层窗大小，对于本领域技术人员而言，在已知下层支持不依序上传时，完全是提高数据缓冲不丢失的**本领域常规设计选择或显而易见的定量配置**。

2. **D2和D1已给出实质性暗示：**

D2和D1中均强调了发送窗（VT(WS)）和接收窗大小必须相匹配（通常相等，或受到最大配置窗的约束）以防止回绕造成的混淆。将这一原则等同施加于相互承接的“解密单元”与“下层传输单元”之间，并不具备出人意料的技术效果。

相反，**抗无效能力相对较强（最牢固）的特征是特征B与特征C的结合体**——即在“解密单元”这一层**特意选用推进式滑动窗**，并将其与下层的窗大小进行联动。因为在已知技术中，如目标专利背景技术所述，解密单元的窗通常未被清楚规范，或者习惯性地采用拉动式滑动窗以快速跟踪最新收到的包。目标专利创造性地发现了拉动式会导致HFN错误累加的盲点，从而限定采用推进式，具有一定的争辩空间。

---

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

鉴于目前的证据链中，特征D、E（解密单元与下层的双层窗协作）在D2中未能完美结合，且特征C的“上层窗 $\ge$ 下层窗”在针对解密领域的显见性说理仍需更直接的文献支持，建议采取以下精准检索策略：

1. **关键词精细化与扩展：**

* **解密/安全层：** `PDCP`, `Ciphering`, `Deciphering`, `Security layer`, `加解密`, `解密单元`, `HFN`, `Hyper Frame Number`, `超视频帧号`.

* **窗口关系：** `Window size`, `Sliding window`, `Push type`, `推进式`, `接收窗`, `大于或等于`, `$\ge$`, `buffer size`, `out-of-sequence`.

* **上下层交互：** `Lower layer`, `RLC`, `AM`, `Confirmation mode`, `下层协议`.

2. **标准文献检索（极重要渠道）：**

由于目标专利（2007年左右申请，2011年授权）明显针对3GPP规范中的PDCP层与RLC层交互进行改进，**3GPP的技术提案（Tdoc/Contributions）和标准变更请求（CR, Change Request）是此类专利的“致命克星”**。

* **检索范围：** 3GPP TS 25.323 (PDCP规范) 和 TS 25.322 (RLC规范) 在2004年至2007年期间的各个版本及会议提案（RAN2会议）。

* **寻找方向：** 重点寻找当时各大电信巨头（如爱立信、诺基亚、高通、华为）在RAN2会议上关于“PDCP HFN desynchronization”（PDCP层HFN失步）或“PDCP window configuration for AM bearers”（AM承载下的PDCP窗口配置）的提案。通常标准提案中会直接讨论“为了防止HFN错误计数，PDCP层的接收窗口必须覆盖整个RLC的重传窗口”等结论，一旦找出，即可构成致命的现有技术公开。

3. **分类号交叉检索：**

锁定国际专利分类号（IPC）：**H04L29/06**（安全通信协议）、**H04W12/02**（无线安全/保密）、**H04L1/18**（重传机制/滑动窗）。将这些分类号与 `PDCP AND RLC AND window` 逻辑组配，在Espacenet、CNIPR及Google Patents中进行追溯检索，重点阻击2006年之前的申请案。

作为一名经验丰富的专利代理师，我针对目标专利权利要求1的创造性及无效可行性，结合涉案专利说明书与D1、D2、D3三份对比文件进行深度法律与技术分析。

---

## 一、 权利要求1的法律解释与技术内涵

权利要求1的核心发明点在于**跨协议层的接收窗协同配置机制**，用以解决无线通信中由于下层重传、不依序上传等导致的上层解密参数（如超视频帧号 HFN）失去同步的技术问题。

* **第一协议单元（解密单元）与第二协议单元（下层协议单元）：** 对应说明书第`[0022]`段，第一协议单元对应**分组数据汇聚协议（PDCP）**层的解密单元，第二协议单元对应其下层的**无线链接控制（RLC）**层（可以是无线链接控制单元、媒体存取控制单元或其结合）。

* **推进式（Push Type）接收窗：** 对应说明书第`[0004]`、`[0027]`段。推进式接收窗的特征是“只有当下缘所对应的包被成功接收或被通知删除时，才会推进接收窗的范围”。这与“拉动式（Pull Type）”（只要收到窗外的包就强行推进并更新上缘）相对立。

* **接收窗大小约束（$\ge$下层接收窗大小）：** 对应说明书第`[0006]`段所述的反面案例（解密窗10 $<$ RLC窗16导致拉动推进或包被强行删除引发HFN步进错误）。本发明要求上层解密窗大到足以容纳下层所有未依序上传的包序列号空间，配合推进式特性，确保在下层重传迟到的低序号包时，该包仍能落在解密窗内，从而避免被误认为是下一个序号循环而错误累加HFN。

---

## 二、 特征比对表格（结合对比文件原文及详细出处）

为了客观评估公开情况，将权利要求1拆解为5个技术特征（A~E），并与D1（US2003157927A1）、D2（JP2003339075A）、D3（US2004235447A1）进行比对。

---

## 三、 最接近的对比文件（最接近现有技术）分析

在创造性评判中，**D1（US20030157927A1）最适合作为本案的最接近对比文件（唯一的主设D1）**。

### 1. 技术领域与组织架构的高度重合

D1 同样属于无线通信系统（UMTS/3GPP）领域。D1 的图2及说明书第`[0015]`-`[0018]`段清晰地勾勒出了系统的协议栈架构：PDCP层（第一协议单元）位于RLC层（第二协议单元）之上。同时，D1 在`[0086]`等段落中详述了加解密（Ciphering）机制，其中 `COUNT-C`（包含 HFN 超视频帧号）作为随时间变化的密钥流输入参数。这与目标专利的技术背景完全一致。

### 2. 解决的技术问题具有同源性

* **目标专利企图解决的问题：** 在SRNS重传或包不依序上传时，接收端由于窗口滑动或类型配置不当，导致 HFN 错误累加，进而使得传输端与接收端加解密参数失去同步（说明书`[0005]`-`[0007]`）。

* **D1 企图解决的问题：** 在SRNS重定位（Relocation）过程中，由于下层 RLC 实体重新建立和初始化，导致序列号SN清零，而终端误认为发生了绕回（Wrap-around），从而错误地将 HFN 加1，导致加解密去同步（D1第`[0102]`、`[0106]`段：*“HFNs become out-of-synchronization... the terminal and UTRAN are considered to be out of synchronization”*）。

两者都敏锐地发现了**无线通信中由于上下层协同及状态变量不匹配导致接收端 HFN 错误进位、解密去同步**这一核心技术痛点。

### 3. 技术效果与演进方向

虽然 D1 提出的解决方案是在重定位期间通过上层容器同步 `VT(US)`、`VT(S)` 或在下层执行 RLC RESET（D1第`[0172]`、`[0185]`段），而目标专利提出的是在常规 AM 模式下直接通过“推进式窗口 + 窗口大小 $\ge$ 下层”这一静态配置来包容下层的不依序上传。但从技术演进角度看，两者处于同一技术演进轴线上。相比之下，D2 聚焦于单层内长度指示符异常的处理，D3 聚焦于位图压缩，均未涉及跨层的解密同步。因此，D1 是无可争议的“最接近现有技术”。

---

## 四、 权利要求1的创造性缺陷与无效突破口

根据上述特征比对，**技术特征B和C（设定解密窗为推进式，且大小 $\ge$ 下层 RLC 窗）**未能被 D1 完整公开，也未在 D2、D3 中被公开。

如果我们要对该权利要求提起无效宣告请求，**最薄弱的技术特征（即专利权人最容易守住、对我方最难攻破的特征）是：特征C（所述接收窗大小大于或等于所述第二协议单元所使用的接收窗大小）结合特征B的“推进式限制”。**

### 无效难点分析（薄弱点）：

专利权人在应对无效诉辩时，必然会强调说明书`[0006]`和`[0028]`段的协同控制效果。他们会主张：如果仅仅将解密窗设为推进式，若其大小小于下层（例如解密窗10，RLC窗16），当收到序号为10的包时，由于超出解密窗，该包依然会被删除或导致解密窗停滞。唯有**同时满足**“推进式”和“大小 $\ge$ 下层 RLC 窗”，才能使下层所有未依序上传、处于重传周期的包全部安全地落在解密窗内，完美规避 HFN 进位错误。这种**跨层窗口定量协作**在 3GPP 早期的标准文本中并不属于显而易见的设计，存在一定的创造性高度。

---

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

鉴于现有文件（D1~D3）对特征B、C的直接结合未能形成强有力的“结合启示”，若要彻底无效掉权利要求1，必须调整检索策略，补充更精准的“X/Y”类销毁性证据：

### 1. 检索方向：聚焦 3GPP TSG-RAN WG2 原始标准提案（Tdoc）

涉案专利的背景是 3GPP UMTS 系统中 PDCP 与 RLC 的协同。这类跨层窗口的底层设计，往往源于某次标准会议上针对“HFN Desynchronization due to out-of-sequence delivery”的缺陷修复提案（CR, Change Request）。

* **检索范围：** 锁定 **3GPP TSG-RAN WG2** 2004年 - 2006年之间的会议文献。

* **关键词组：** `PDCP window`, `RLC window size`, `out-of-sequence delivery`, `HFN desynchronization`, `ciphering window`, `push type`.

* **期望找寻的目标：** 某篇公开在先的标准提案中明确指出：“为了防止PDCP层HFN去同步，PDCP的接收机制应采用类似于RLC AM的推进式滑动窗，且其序列号检测空间不得小于下层RLC的窗口大小”。一旦检索到此类技术公开，即可与 D1 结合，彻底摧毁其创造性。

### 2. 检索方向：拓宽至通用协议栈的“级联窗口”设计（外围扩展）

如果在电信标准中未直接找到，可转向通用计算机网络（如 TCP/IP 变体、卫星通信轻量级协议栈）中关于“安全加密层（如高层 IPsec/TLS 变体）与可靠传输层（如底层 TCP/SR-ARQ）窗口大小配置”的学术论文或专利。

* **检索逻辑：** 寻找在“高层负责抗重放/加解密，底层负责可靠重传”的普遍架构下，论述“上层接收窗（Anti-replay Window / Decryption Window）必须大于或等于底层传输窗（Transmission/ARQ Window），否则会导致上层窗口超前滑动或漏包”的通用技术常识。以此证明在第二协议单元操作于可靠确认模式时，设定第一协议单元（加解密）窗大小 $\ge$ 下层窗，属于本领域网络协议设计专家的**常规惯用手段**。

作为一名经验丰富的专利代理师，我针对目标专利权利要求1进行了深入的法律与技术分析。以下是结合目标专利说明书以及D1、D2、D3三份对比文件原文做出的无效宣告可行性分析报告。

---

## 一、 权利要求特征分解与合理解释

根据目标专利（CN101064594B）的说明书，权利要求1的技术实质是为了解决在下层协议单元（如RLC层）支持“包不依序上传”且操作于**确认模式（AM）**时，上层的解密单元（如PDCP层）因接收窗类别或大小设定不当，导致超视频帧号（HFN，即解密参数）错误累加、失去同步或接收窗停滞的问题。

基于说明书的整体发明意图，对特征的合理解释如下：

* **解密参数同步**：指接收端与传输端维持相同的COUNT-C（由HFN和SN组成）以正确解密。

* **推进式（Push Type）接收窗**：类似于UMTS中AM RLC的接收窗，只有当下缘对应的包被成功接收或通知删除时，窗口才会向前推进；若包落在窗外则删除（参见说明书\[0004\]）。

* **下层协议单元**：指为解密单元提供数据传输支撑的协议层，在3GPP架构中典型为RLC（无线链接控制）层。

---

## 二、 特征比对表与出处分析

以下将权利要求1分解为5个技术特征（A~E），并与D1、D2、D3的原文进行详细比对：

### 权利要求1特征比对表

---

## 三、 最接近的对比文件（最接近现有技术）分析

在创造性评审中，选择**对比文件2（D2）**作为最接近的对比文件最为合适。

### 1. 整体解决的技术问题角度

* **目标专利**解决的问题是：在无线通信中，由于下层包不依序上传，导致接收端的解密参数（超视频帧号 HFN）不同步，进而引起解密失败。

* **D2（US20050245276A1）**在其技术领域和背景技术中明确指出，其发明目的在于：

> \[0001\] "The present invention relates to... avoidance of **deciphering failures** in a cellular mobile radio system..."

> \[0035\] "...avoidance of **cipher synchronization failure**..."

两者聚焦的**技术核心完全一致**，均是解决数据包丢失或乱序时，接收端如何避免解密序号（HFN）错误累加、维持加解密同步的问题。相比之下，D1侧重于RLC窗口大小的协商，D3则完全侧重于MBMS业务下非确认模式（UM）的数据重排序，未聚焦于确认模式（AM）下的解密同步。

### 2. 技术效果角度

* D2通过引入滑动决策窗（Sliding decision-window）和预测机制，排除了由于传输错误导致的异常序号，从而使HFN更新不受乱序包、错误包的影响（参见D2 \[0038\]-\[0041\]）。这与目标专利通过“设定解密单元接收窗为推进式且增大窗口”来容纳乱序包、避免HFN错误累加的技术效果具有极高度的共通性。

* 因此，从技术领域、技术问题和主要技术特征的重合度来看，D2构成了全案逻辑起点最自然的“最接近现有技术”。

---

## 四、 现有技术漏洞与最薄弱技术特征

通过上述特征比对可以清晰地发现，**没有任何一份对比文件单独公开了特征B和特征C**。

本权利要求在无效请求中最难攻克、但也最关键的**最薄弱技术特征**（即专利权人的“防线”）是：

> **“设定一第一协议单元的一接收窗为推进式，且所述接收窗大小大于或等于所述第二协议单元所使用的接收窗大小” （特征B + 特征C的结合）**

### 为什么该特征最难被直接无效？

1. **D3的强烈反向教导**：D3虽然讨论了窗口和重排序，但它通篇针对的是**非确认模式（UM RLC）**，并且其公开的重排序窗（DAR Window）实质上是“拉动式”（Pull Type）——即收到窗外高序号包时强制推进窗口上缘（参见D3 \[0129\]）。这恰恰对应了目标专利说明书\[0006\]中批评的“拉动式会导致不同步”的反向技术方案。

2. **跨层窗口大小的定量协同**：现有技术（如D1、D3）通常只考虑单一协议层（如RLC层内）的窗口管理，而特征C明确要求“上层解密窗 $\ge$ 下层传输窗”。这种跨协议层的定量窗口大小匹配，在常规3GPP标准文献中往往被视为相互独立的参数，很难在单篇文献中找到直接的字面公开。

---

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

鉴于目前的D1~D3文献组合在“解密窗为推进式且大小不小于下层窗”这一核心架构上仍存在明显的特征断层（Gap），若要成功无效权利要求1，建议采取以下进阶检索策略：

### 1. 锁定特定历史时期的3GPP标准提案（Contributions）

目标专利的优先权日大约在2006年前后（基于同族公告案推算）。该技术特征解决的是PDCP层解密与RLC AM层不依序递交（Out-of-sequence delivery）的配合问题。

* **检索源**：3GPP FTP服务器（TSG-RAN WG2 会议文稿）。

* **关键词组合**：`PDCP WINDOW` + `HFN desynchronization` + `out-of-sequence` + `AM RLC`。

* **寻找方向**：在2004~2006年间，3GPP标准专家组曾就“是否在PDCP层引入接收窗以解决HFN去同步”发生过激烈争论，相关提案中极有可能包含“上层PDCP窗口必须配置得比下层RLC窗口大”的技术建议。

### 2. 聚焦于“跨层协议栈优化”的专利文献检索

改变检索着眼点，不局限于“解密参数”，而是从“多层通信协议栈的滑动窗级联控制”这一通用通信规则入手。

* **检索式构建**：`(Upper layer OR PDCP) AND (Lower layer OR RLC) AND (Window size) AND (Greater than OR Larger than) AND (Push type OR In-sequence)`。

* **逻辑支撑**：证明在分层无线通信协议中，当底层支持重传且乱序上传时，为了防止上层过早丢包或窗口停滞，将上层窗口设置为“推进式”且“上层窗口 $\ge$ 下层窗口”属于本领域的**常规设计准则（或公知常识）**。一旦突破这一点，即可结合D2成功重组创造性三步法攻击链。

根据权利要求1所述的方法，其特征在于所述第二协议单元是一无线链接控制单元。

根据权利要求1所述的方法，其特征在于所述第二协议单元是一媒体存取控制单元。

根据权利要求1所述的方法，其特征在于所述第二协议单元的接收窗为推进式。

根据权利要求1所述的方法，其特征在于当所述第二协议单元操作于确认模式时；所述第二协议单元将包删除的信息传送至所述第一协议单元。