一种在使用协议数据单元和伺服数据单元的无线通讯系统中进行接收状态查询的方法，在预定时间内暂禁查询；于查询被暂禁期间，触发一查询机制；该查询机制是一“基于传送窗的”机制；当达到预定比例的传送窗进度时，触发该查询机制；在该预定时间期满后，确认没有安排传输或重传任何协议数据单元；确认有已传送过但尚未被确认收讫的协议数据单元；选择协议数据单元；安排重传，以执行一查询操作。

作为一名经验丰富的专利代理师，我将为您对权利要求1进行深度解析，并结合目标专利说明书（CN101330366B，以下简称“本专利”）与三篇对比文件进行比对分析。

通过对技术的深度剖析，本申请实质上解决的是在3GPP无线通信系统（特别是RLC确认模式，即AM模式）中，**当“查询暂禁定时器（Timer_Poll_Prohibit）”正在计时期间，如果有查询触发被延迟，在定时器期满后，如何避免因不当的查询判断逻辑而导致“数据传输死锁（Deadlock）”**的技术问题。

以下为详细的分析报告、特征比对、最接近对比文件筛选、无效请求最薄弱特征诊断以及检索策略。

---

## 一、 权利要求1的技术特征拆解与说明书支持分析

结合目标专利说明书的记载，我们将权利要求1拆解为以下8个技术特征（A至H），并给出说明书对应的支持说明：

* **技术特征A：在预定时间内暂禁查询**

* *说明书支持*：对应本专利中的“查询暂禁功能”。本专利在第`[0016]`段和`[0114]`段提到：“该查询暂禁功能的定时器长度为Timer_Poll_Prohibit=250ms”，在定时器计时（预定时间）期间，暂时禁止送出查询（暂禁查询）。

* **技术特征B：于查询被暂禁期间，触发一查询机制**

* *说明书支持*：对应本专利第`[0016]`段和`[0115]`段：“于计时期间，如有查询被触发，该查询会被延迟至该定时器期满后才送出”。

* **技术特征C：该查询机制是一“基于传送窗的”机制**

* *说明书支持*：对应本专利第`[0014]`段和`[0056]`段：“基于传送窗的机制，亦即当达到预定比例的传送窗进度时，触发该查询机制”。此即“传送窗进度查询”功能。

* **技术特征D：当达到预定比例的传送窗进度时，触发该查询机制**

* *说明书支持*：对应说明书第`[0014]`段中触发查询的事件(6)：“达到传送窗的特定百分比进度时（此称为‘传送窗进度查询’功能）”。

* **技术特征E：在该预定时间期满后，确认没有安排传输或重传任何协议数据单元**

* *说明书支持*：对应本专利第`[0115]`段、第`[0118]`段及第9图流程。当查询暂禁定时器（预定时间）期满后（对应步骤1006之前），系统检查“是否没有安排传输或重传任何的协议数据单元”（确认没有安排传输或重传）。

* **技术特征F：确认有已传送过但尚未被确认收讫的协议数据单元**

* *说明书支持*：对应本专利第`[0115]`段和第9图步骤1006：“而且有已传送过但尚未被确认收讫的协议数据单元”。

* **技术特征G：选择协议数据单元**

* *说明书支持*：对应本专利第`[0118]`段步骤1008：“系统选择合适的协议数据单元来重传，以传递查询位”。

* **技术特征H：安排重传，以执行一查询操作**

* *说明书支持*：对应本专利第`[0118]`段步骤1009和`[0115]`段：“安排重传该选定的协议数据单元……重传协议数据单元以进行查询，促使接收站台回报接收状态报告”。

---

## 二、 对比文件原文检索与特征比对（详细出处及比对表）

以下对比文件代号及公开号对应关系如下：

* **D1**：WO2002069547A1 (WO2002069547A)

* **D2**：EP1263160A1 (EP1263160A)

* **D3**：JP2003174470A (JP2003174470A)

### 1. 各对比文件的技术公开情况深度挖掘

#### 对比文件1 (D1 - WO2002069547A1)

* **核心方案**：D1 解决的是在 MAC 层和 RLC 层双重重传机制下，避免不必要的 RLC 重传问题。D1 提出了一种对 MAC 层接收和接受的协议数据单元（PDU）打上“延迟（delayed）”或“失败（failed）”标签，并按 PDU 序号顺序上传给 RLC 层的机制。

* **具体段落分析**：

* D1 在第 `[p0024]` 段提到了 3GPP TS 25.322 协议规定的三种状态报告触发器（丢失 PU、定时状态报告、估算 PDU 计数器）。

* D1 在第 `[p0067]` 段至 `[p0074]` 段描述了在接收到偏序 PDU 时将其在 MAC 缓冲区进行缓存，直到没有 delay 标签时才按顺序提交给 RLC 层的技术方案。

* **结论**：**D1 完全没有公开“暂禁查询（Prohibit Poll）”、“查询暂禁定时器”以及“期满后确认无安排传输/重传、有未确认PDU而重传执行查询”的机制（特征A、B、C、D、E、F、G、H 均未公开）。**

#### 对比文件2 (D2 - EP1263160A1)

* **核心方案**：D2 提出了一种改进的 RLC 状态报告控制方法，通过在发送端设置一个与特定 PDU 绑定的“重传禁止定时器（Retransmission Prohibit Timer, RPT）”或通过计时器/计数器单元（timing unit）来防止发送端在往返时间（RTT）内对同一个丢失的 PDU 进行多次不必要的重传，以此来允许接收端频繁发送状态报告而不浪费无线资源。

* **具体段落分析**：

* D2 在第 `[0008]` 段提到了传统的 3GPP RLC 协议允许通过 **“状态禁止定时器（Status Prohibit Timer）”** 来限制接收端发送状态报告的频率，但这会减慢协议速率。

* D2 在第 `[0014]`、`[0016]`、`[0018]` 段提出了发送端（Transmitter）在收到状态报告并重传第一 PDU 时，**“初始化一个定时单元（initialize a timing unit/timer）”**，在定时器未达到阈值（即一倍 RTT）之前，即使收到新的状态报告要求重传该 PDU，也**禁止（prohibit）重传该 PDU**（对应特征A：在预定时间内暂禁/禁止重传）。

* D2 在第 `[0048]` 段步骤5中指出：“The transmitter TR starts a first retransmission prohibit timer RPT1 for this PDU ... The expiry threshold for the timer is set slightly higher than one round trip time.（发送端针对该 PDU 启动第一重传禁止定时器，过期阈值略高于一个RTT时间）”。

* **结论**：**D2 公开的是“暂禁/禁止重传（Retransmission Prohibit）”机制，旨在限制特定PDU的二次重传；而本专利权利要求1要求的是“暂禁查询（Polling Prohibit）”机制，旨在限制发送端主动发送查询位（Polling Bit）的频率。两者概念完全不同，D2 并未公开特征A、B、C、D、E、F、G、H。**

#### 对比文件3 (D3 - JP2003174470A)

* **核心方案**：D3 解决的是发送端与接收端之间由于重传和重传要求“擦肩而过”导致的无必要重复再送问题。D3 引入了“再送控制列表/再送控制表格（Retransmission Control Table）”，记录发送端判定重传时已发送的序号上限值及发送原因等。

* **具体段落分析**：

* D3 在说明书第 `[0016]`、`[0113]`、`[0118]` 段提到了 3GPP TS 25.322 规范中，发送端在 RLC-PDU 的标头中设置 **“Poll位（P位）”** 来要求接收端回报状态消息（STATUS-PDU），这称为 **“状态通知要求”** 或 **“查询（Polling）”**。

* D3 在第 `[0108]` 至 `[0118]` 段（D3 的实施例1）详细描述了：

1. 发送端在发送“状态通知要求消息”（设置有 Poll 位的 PDU）时，自增计数器并添加“要求编号（Poll Counter）”。

2. 接收端在回复状态通知消息（STATUS-PDU）时，回传该要求编号，并带上状态通知发送的原因（Cause，如“Miss”表示检测到丢失，“P1”表示收到Poll要求）。

3. 发送端在收到状态通知消息后，查询其“再送控制表格（再送控制列表）”中的序列号上限值和原因。如果 STATUS-PDU 中的“正常接收的序列号上限值”（LSN）低于“再送控制表格”中的上限值，且要求编号和发送原因匹配，则表明该再送要求是在前一次再送实施前发出的，因此**判定不进行重复的再送（即：暂禁/不安排重传操作）**。

* **结论**：D3 虽然深入探讨了“Poll 位的设置”和“再送控制”，但其核心是基于表格来避免在无线电往返延迟期间发生**重复重传（Duplicate Retransmissions）**。其保护的控制逻辑是“收到重传请求后，查表判定是否重传”，**不包含本专利在“暂禁查询期间触发基于窗的查询机制，等暂禁期满后在没有新数据传输时重传PDU以携带查询位”的逻辑。**

---

### 2. 权利要求1与对比文件1-3的技术特征比对表

为了直观呈现各对比文件的公开情况，以下给出技术特征比对表：

---

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

### 1. 最接近对比文件（最接近现有技术）的筛选

在创造性分析中，确定“最接近的对比文件”需要从**技术领域、解决的技术问题、技术方案和预期技术效果**四个维度进行综合考量：

D1、D2、D3 与本专利均属于 3GPP RLC 层重传控制的技术领域，但它们在解决的具体技术问题上存在显著差异：

1. **D1 (WO2002069547A1)**：

* *技术问题*：解决 MAC 层和 RLC 层双重重传机制冲突，避免 MAC 已成功重传但 RLC 误认为丢失而发生的重复重传。

* *技术方案*：MAC 层偏序缓存与顺序提交机制。

* *与本专利关联度*：极低。D1 侧重于跨层交互，未涉及发送端的查询（Polling）机制设计。

2. **D2 (EP1263160A1)**：

* *技术问题*：解决频繁的状态报告导致发送端对相同丢失 PDU 产生多次无用重传，同时避免放宽状态禁止定时器而导致的协议速度变慢。

* *技术方案*：通过重传禁止定时器（RPT）或区间定时器防止未过 RTT 的 PDU 二次重传。

* *与本专利关联度*：中等。虽然涉及定时器控制和“禁止（Prohibit）”概念，但其控制对象是“重传限制”，而非“发送端的查询行为”。

3. **D3 (JP2003174470A)**：

* *技术问题*：解决在多播/单播数据包传输中，发送端已经发出重传 PDU，但接收端由于空口延迟（RTT）尚未收到，因而继续在 STATUS-PDU 中请求该 PDU，导致发送端发生无用重传。

* *技术方案*：建立“再送控制表格”（记录判定再送时的上限值 `VT(M)` 和发送原因），并在收到状态报告时通过比对 `VT(M)` 决定是否过滤重传。

* *与本专利关联度*：**最高**。D3 深入探讨了 3GPP 协议（TS 25.322）中 Poll 位的触发（详见 D3 第 `[0113]`段“状态通知要求”），且 D3 所采用的“查表控制、对比上限值（对应本专利 LSN 与 VT(M) 比对）”等手段，在底层重传判断逻辑上与本专利最为接近。

**结论**：**D3 (JP2003174470A) 适合作为最接近的对比文件。**

---

### 2. 创造性评述（以D3为最接近现有技术）

如果以 D3 作为最接近的对比文件，对权利要求1进行创造性分析：

* **确定区别特征**：

将权利要求1与 D3 进行比对，其区别特征在于：

1. **特征A/B/C/D**：明确了查询机制为“基于传送窗进度（达到预定比例）的机制（传送窗进度查询功能）”，并且在“查询暂禁定时器（预定时间）暂禁查询期间”触发并延迟该机制。

2. **特征E/F/H**：提出了在“预定时间（暂禁查询定时器）期满后，在确认没有安排传输或重传任何 PDU，但有已传送且未确认收讫的 PDU”时，**通过“选择并重传一个已发过的协议数据单元（PDU）”来强行执行查询操作**的防死锁方案。

* **区别特征在技术方案中解决的实际技术问题**：

在 3GPP RLC AM 模式中，如果最后发送的几个 PDU 丢失了，且查询暂禁定时器仍在计时（暂禁查询），那么发送端无法发送 Poll。若此时定时器期满，且发送端已经没有新数据需要发送（首传缓冲区和重传缓冲区均为空），按照传统协议逻辑，发送端将保持闲置。由于接收端没有收到 Poll 且没有后续 PDU 触发其状态报告，发送端也无法获得确认，从而陷入**“数据传输死锁（Deadlock）”**。

本专利通过**“期满后若无新数据安排，且有未确认PDU，则重传PDU以携带Poll位执行查询”**，完美解决了这一死锁问题。

* **是否存在技术启示**：

* D3 虽然提出了利用“再送控制表格”避免重复重传，但其研究重点在于**“如何抑制由于接收端状态报告滞后而导致的无效重传”**，属于**接收端触发**和**发送端查表抑制**的范畴。

* D3 **完全没有涉及**发送端如何主动破除因“查询暂禁定时器”与“缓冲区排空”叠加导致的发送端死锁问题。D3 也没有给出在暂禁期满后，通过“主动重传一个已传送且未确认的 PDU 以携带 Poll 位”来打破僵局的任何暗示。

* 因此，本领域技术人员在面对“防死锁”这一技术问题时，无法从 D1、D2 或 D3 中获得将上述区别特征结合的启示。**权利要求1相对于 D1-D3 的结合具有突出的实质性特点和显著的进步，具备创造性。**

---

## 四、 无效请求中最薄弱的技术特征分析

若您代表竞争对手对本专利权利要求1提出无效宣告请求，以下特征是**最薄弱的突破口**：

### 1. 最薄弱特征定位：技术特征C和技术特征D（“基于传送窗的”查询机制）

* **理由**：

* 权利要求1中写入了“该查询机制是一‘基于传送窗的’机制”以及“当达到预定比例的传送窗进度时，触发该查询机制”。这两点在 3GPP 协议标准（如规范 3GPP TS 25.322 V6.1.0 或更早版本）中属于**公知常识（Standard Specifications）**。

* 公知常识在专利审查和无效宣告中极易被对方用大量的标准提案（WID/Tdoc）或教科书直接证明。一旦技术特征C和D被认定为公知常识，其创造性权重将完全丧失。

### 2. 实质性防御堡垒：技术特征E + F + H 的逻辑组合

* **分析**：

* 本专利真正的发明点（核心壁垒）在于：**“在预定时间期满后 ＋ 确认没有安排传输或重传任何PDU ＋ 确认有已传送过但尚未被确认收讫的PDU ＋ 安排重传以执行一查询（携带Poll）”**。

* 在传统的 3GPP 协议（D4/TS 25.322）中，步骤1007会强制检查“触发查询的源头是否是定时催询（Timer_Poll）或周期性查询”。本专利通过**去掉步骤1007（如图9流程所示）**，使得“基于传送窗进度触发的查询（特征C、D）”在被暂禁延迟（特征B）并期满后，即使此时没有新数据发送（特征E、F），也能通过重传 PDU（特征H）来打破死锁。

* **无效策略**：在无效该专利时，不能孤立地去证明特征C、D是公知常识，而应该寻找**公开了完整的发送端 Poll 状态机跳转逻辑**的对比文件，重点攻克“暂禁期满后，发送端在缓冲区为空时主动选择旧 PDU 进行 Polling 重传”的逻辑判定。

---

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

为了在无效宣告程序中成功推翻权利要求1的创造性，建议采取以下针对性的检索策略：

### 1. 检索方向与数据库选择

* **锁定标准文献库（最关键）**：由于本专利是标准的“标准必要专利（SEP）”特征，普通的专利数据库（如 CNIPR、Google Patents）很难检索到最底层的技术细节。必须重点检索：

* **3GPP 官方文档库（3GPP FTP Server Server / Portal）**：检索 R1（RAN1）、R2（RAN2）工作组在 2004 年至 2005 年期间（本专利分案申请的母案申请日为 2005年9月15日，**优先权日/检索截止日应定在 2005年9月15日之前**）的会议提案（Tdocs）。

* **3GPP 历史协议版本**：下载 2004-2005 年期间的 `TS 25.322` 各个子版本（如 V6.1.0、V6.2.0、V6.3.0 等），尤其是关于“Timer_Poll_Prohibit”和“Poll trigger”的修订提案（CRs - Change Requests）。

### 2. 检索关键词设计（英文为主）

* **基本主题词**：`RLC` (Radio Link Control), `AM` (Acknowledged Mode), `Polling`, `Poll Prohibit` (Timer_Poll_Prohibit), `Deadlock`, `Stall`, `Retransmission`.

* **逻辑控制词**：`buffer empty` (no PDU to send / transmit), `outstanding PDU` (unacknowledged PDU), `retransmit old PDU` (retransmit PDU to carry poll / poll bit).

### 3. 具体检索切入点（针对死锁机制的逻辑还原）

* **切入点一：寻求 3GPP RAN2 2004-2005 会议中的 CR（修改提案）**。

在 3GPP 历史上，某家公司（如爱立信、诺基亚、高通或三星）可能在会议上提出过“*Avoid deadlock when Timer_Poll_Prohibit expires and transmission buffer is empty*”类似的提案。这类 Tdoc 提案一旦在 2005 年 9 月 15 日前公开，即构成完美的现有技术，可直接一击毙命。

* **切入点二：检索接收端状态报告（STATUS PDU）与发送端 Poll 暂禁的交互规范**。

寻找有无专利或标准提案公开了：“当 Poll Prohibit 计时器期满，若没有新 PDU 可发，且尚有未确认的 PDU 存在，则重传最后一个发送的 PDU（如 `VT(S)-1`）以强制接收端发送状态报告”。在 3GPP 协议的发展中，这种防死锁的机制往往会作为标准漏洞（Bug Fix）被写进标准提案。

作为一个在电信标准（3GPP）和专利法领域深耕多年的专利代理师，我非常理解您在处理无线通讯协议（尤其是RLC层避免死锁机制）案件时的严谨态度。3GPP TS 25.322 协议中的查询（Polling）机制和查询暂禁定时器（Timer_Poll_Prohibit）的交互极其复杂，稍有不慎就容易在创造性阶段发生事实认定偏差。

下面我将紧密结合**目标专利（CN101330366B）**的说明书，对您的权利要求进行深度剖析，比对**对比文件D1（US2004/0013087A1）**与**对比文件D2（EP1424815A1）**的原文，并给出全套的无效宣告/创造性防御分析。

---

## 一、 目标专利说明书对权利要求的原理解读

目标专利的核心在于解决**3GPP RLC确认模式（AM）下的数据传输死锁（Deadlock）问题**。

* **死锁根源：**

根据旧有规范（第4图/第6图），当发送端因查询暂禁定时器（`Timer_Poll_Prohibit`，对应**特征A**）正在计时而将最后几个PDU（如PDU 404, 405）的查询位设为0送出，且此后没有新数据或欠收重传数据时（步骤1001, 1002不满足），由于上层未启动“周期性查询”，且“定时催询”被提前取消（步骤1007不满足），发送端在定时器期满后（**特征E**）将陷入永久闲置。

* **本发明的改良（第7图/第9图）：**

目标专利删除了旧有流程中的步骤1007（[0118]）。这意味着：**无论最初触发该查询的机制是什么**（即使是非定时类的“基于传送窗进度”触发机制，即**特征C、D**），只要在暂禁期满后，确认无新包发送且有已发送未确认包（**特征E、F**），发送端都必须选择一个PDU（**特征G**）安排重传以强行携带查询位1（**特征H**），从而打破死锁。

---

## 二、 对比文件特征比对与详细出处

为了进行客观的技术比对，我们将权利要求1的八个技术特征（A~H）在对比文件 D1（US20040013087A1）和 D2（EP1424815A1）中进行逐一检索和定位。

### 1. 权利要求技术特征比对表

---

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

在创造性分析或无效宣告程序中，选择最接近的对比文件（Closest Prior Art）是重中之重。

### D1 (US2004013087A1) 作为最接近对比文件

* **整体解决的技术问题：**

D1的核心目的就是**“防止协议死锁（preventing protocol stalling/deadlock）”**（见D1的标题及[0001]、[0016]）。它针对的场景是：当没有新数据、无NACK重传包，且因确认包丢失导致发送端无限期等待时，协议如何避免卡死。

* **技术效果：**

D1通过引入自发查询机制（Spontaneous Polling），在“预定时间期满后”，重传一个已发送未确认的包（LTP或ETP）来唤醒接收端。

* **最接近理由：**

D1与目标专利的**技术领域、解决的技术问题（死锁）、核心挽救手段（在期满且无包可发时，重传旧包带Poll）高度一致**。

### D2 (EP1424815A1) 作为最接近对比文件

* **整体解决的技术问题：**

D2的核心目的是**改进窗口查询机制（Window-based Polling）中测试值 $t$ 的计算方法**，避免由于各家标准实现中 $VT(S)$ 更新时机不同、或者重传包反复触发查询而造成的“无线资源浪费（degradation of the efficient utilization of radio resources）”（见D2 [0016]、[0017]）。

* **技术效果：**

D2提出了一种精确的取模算法 $t = \{ (2^{n+1} + S - VT(A)) \pmod{2^n} \} / VT(WS)$，使得窗口比例计算不依赖于模糊的 $VT(S)$，且限定只有初传包能触发该窗口查询。

* **最接近理由：**

D2公开了**特征C、D**（基于传送窗进度的触发机制，即Window-based Polling及预定比例）。

---

> ### ⚖️ 代理师权威结论

> 本案最适合作为最接近对比文件的是 **D1 (US2004013087A1)**。

>

> 因为判断最接近对比文件的首要原则是**“技术领域和所解决的技术问题最相近”**。目标专利与D1都旨在解决“在暂禁期内触发的查询被延迟，导致期满后无新包发送时引发的数据死锁”；而D2纯粹是在研究“如何让正常状态下的窗口进度查询计算得更准，省点流量”，完全没有死锁挽救的架构。

---

## 四、 权利要求创造性评价与最薄弱特征分析

### 1. 组合方案与特征覆盖

如果我们以 **D1** 作为最接近的对比文件：

* **D1已公开的技术特征：** A、B、E、F、G、H。

* **未被D1公开的区别技术特征：** 特征C和特征D（即查询机制是“基于传送窗”的，且在“达到预定比例的传送窗进度时”触发）。

**这些区别特征是否被其他对比文件公开？**

> **是。** 区别特征C、D被 **D2** 毫无疑问地公开了（D2的全文核心即为在达到预定比例的传送窗进度时触发查询，详见 D2 的 `[0013]`, `[0014]` 以及公式 `(4)`）。

### 2. 无效宣告请求中最薄弱的技术特征

作为无效请求人或专利权人，我们需要认识到本权利要求最薄弱、最容易被攻破的特征。

> ### ⚠️ 最薄弱技术特征：特征C + 特征D（基于传送窗比例触发查询）

>

> **理由如下：**

> 1. **标准固有技术：** “基于传送窗进度的查询机制（Window-based polling）”本身就是3GPP TS 25.322规范（目标专利背景技术[0003]、D2背景技术[0004]中均明确提到的标准规范）中**原本就存在并被广泛启用的标准触发事件之一**。

> 2. **显而易见的简单组合：** 目标专利在说明书[0118]中承认，其改进仅在于“删除了第4图的步骤1007”。旧步骤1007限定了“暂禁期满后的强制重传”仅适用于“定时催询”或“周期性查询”。目标专利扩大到“非这两种查询触发的其他查询”（即包括基于传送窗进度的查询）。

>

> 审查指南中，将原本属于平行的标准触发事件（定时催询、定量PDU、基于传送窗等）统一应用到相同的暂禁期满挽救逻辑中，属于**“同类技术特征的显而易见替代”**。D2已经明确教导了传送窗进度查询在RLC层的标准应用，D1教导了死锁挽救，将D1与D2结合，对本领域技术人员而言是顺理成章、毫无创造性可言的。

---

## 五、 针对本案的进一步检索策略（专利代理师专业建议）

为了确保彻底无效掉该专利，或者在 administrative litigation（行政诉讼）中获得绝对优势，建议您启动第二轮定向检索。目前的 D1+D2 结合虽有说服力，但若能检索到以下方向的对比文件，案子将是“一锤定音”：

### 1. 3GPP 原始标准提案（Contributions）检索

* **检索源：** 3GPP FTP Server (TSG RAN WG2 会议文档)。

* **时间窗口：** 2004年6月至2005年9月（目标专利最早申请日）之间。

* **核心线索：** 目标专利所改动的“移除步骤1007”，极有可能是由爱立信、诺基亚、高通等巨头在 RAN2 会议上提交的**标准修正提案（Change Request, CR）**。3GPP为了修正 25.322 协议死锁而提出的 CR 文档，其公开日若早于 2005 年 9 月，将直接构成 **54条（新颖性）** 或 **55条（创造性）** 的绝佳对比文件。

* **检索关键词：** `TS 25.322`、`Timer_Poll_Prohibit`、`stalling`、`deadlock`、`polling trigger`。

### 2. 同族及先申请案的补充

* **检索对象：** 检索高通（Qualcomm）或三星（Samsung）在 2003-2005 年间申请的关于“RLC status report delay”、“Timer_Poll_Prohibit expiration salvage”的专利。

* **目的：** 寻找一份在一件专利里就同时公开了“传送窗进度查询”+“暂禁定时器期满挽救（重传旧包）”的单篇对比文件。

根据权利要求1所述的方法，所选择的协议数据单元为最后一个至少被传输过一次的协议数据单元。

根据权利要求1所述的方法，当传送窗的大小小于该无线通讯系统中协议数据单元的序号空间的值的一半时，所选择的协议数据单元为已传输过但尚未确认收讫的协议数据单元。