一种在使用协议数据单元和业务数据单元的无线通讯系统中进行接收状态查询的方法，在第一预定时间内暂禁查询功能；于查询功能被暂禁期间，触发查询功能；在该第一预定时间期满后，确认不存在有安排传输或重传的协议数据单元；且至少有一已传送过的协议数据单元尚未被确认收讫；以及选择合适的协议数据单元，安排重传，以执行该查询功能。

作为一名经验丰富的专利代理师，我将为您对目标专利（CN101330511B）的权利要求1进行深度解析，并结合对比文件D1（WO2000062468A）进行技术特征的比对、最接近对比文件选择、无效请求中最薄弱特征分析，以及给出下一步的检索策略。

---

### 一、 目标专利与对比文件概述

* **目标专利**：CN101330511B（《无线通讯系统中防止不必要查询的接收状态查询方法》），分案申请日为2005年9月15日。其核心在于解决3GPP RLC（无线链接控制）协议中，由于“查询暂禁定时器”（Tprohibit）期满后，由于原协议（TS 25.322）对延迟查询的触发源限制（仅限定时催询或周期性查询），导致非此类源触发的查询在无新数据传输时被丢弃，进而引发**“数据传输死锁”**的技术问题。

* **对比文件D1**：WO2000062468A（公开日：2000年10月19日，名称：《FLEXIBLE RADIO LINK CONTROL PROTOCOL》）。该文件公开了一种灵活的无线链接控制协议，其中定义了包括查询暂禁定时器（Tprohibit）、各种查询触发事件（如发送缓冲区最后一个PDU等）在内的多种RLC可选/必选功能。

---

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

以下将权利要求1分解为5个技术特征（A、B、C、D、E），并与D1（WO2000062468A）进行逐项客观比对：

---

### 三、 哪个对比文件适合做“最接近的对比文件”？

在创造性分析中，**最接近的对比文件**应当是具有最类似的技术领域、解决最相似的技术问题、且公开相同或相似技术特征最多的现有技术。

本案中，存在两个极佳的候选“最接近对比文件”：

#### 候选1：目标专利背景技术中引用的标准规范 3GPP TS 25.322 V6.1.0 (2004-06)

* **技术领域与解决的问题**：完全相同。都是3GPP RLC确认模式下的接收状态查询机制。

* **公开的技术特征**：

* 公开了**特征A**（查询暂禁定时器Timer_Poll_Prohibit）和**特征B**（延迟查询机制）。

* 公开了**特征C、D、E的绝大部分架构**。在TS 25.322（即目标专利第4图）中，步骤1006已完全公开了“检查是否没有安排传输或重传，且有已传送未确认的PDU”；步骤1008和1009也公开了“选择合适PDU安排重传以携带查询位”。

* **唯一区别**：TS 25.322在步骤1007中，限制了该重传查询必须是由“定时催询”或“周期性查询”触发。而目标专利将其修改为步骤1007a（只要有未确认收讫的PDU，任何被延迟的查询触发都可以执行重传查询）。

* **结论**：**3GPP TS 25.322 是最适合、也是最危险的“第一最接近对比文件”**。因为它公开了绝大多数流程细节，两者的区别仅在于一个特定分支条件（步骤1007）的放宽。

#### 候选2：D1（WO2000062468A）

* **技术领域与解决的问题**：属于同一技术领域（3GPP RLC协议），旨在提供一种灵活的、可配置的重传和查询（Polling）方案，以提高通道效率、避免不必要的传输。

* **公开的技术特征**：公开了基本的PDU/SDU架构、查询触发源（Table 1）、暂禁定时器 `Tprohibit`（[p0029]）等。

* **与目标专利的差距**：D1偏向于协议的配置框架（RRC如何配置各个可选/必选函数），没有像TS 25.322或目标专利那样具体深入到“定时器到期后如何检查发送队列、如何判断死锁、如何选择特定PDU重传”的状态机执行细节（特征C、D、E未在D1中固化呈现）。

* **结论**：**D1适合作为“第二最接近对比文件”**，主要用来证明“查询暂禁定时器”与“多种查询触发并存”属于本领域的公知常识或基本协议配置。

---

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

若要对该专利提起无效请求，目标专利**最薄弱（最容易被突破）的技术特征是：特征C、D、E的组合（即通过重传已发送PDU来恢复被延迟的查询）**。

#### 为什么说它是最薄弱的？

1. **公知常识与必然选择**：

在无线通信协议（如RLC）中，一旦查询暂禁定时器（Timer_Poll_Prohibit）期满，且此前有被延迟的查询需要发送，此时如果发送缓冲区和重传缓冲区都为空（特征C），为了把这个查询送出去，发送端**唯一可行**的办法就是选择一个已经发送过但对方还没确认收到的PDU（特征D），将其“查询位（Polling bit）”置为1，并重新发送一次（特征E）。

如果不重传PDU，查询位作为PDU头部的一部分，根本没有载体可以发送。因此，**“选择已发送PDU重传以携带查询位”是本领域技术人员在面临无新数据发送时，为了发送查询位而不得不做出的、唯一的、惯用的技术选择**。

2. **TS 25.322的启示**：

在标准规范TS 25.322中，步骤1006-1009已经指明了这一通路（即对于定时催询触发的延迟查询，采取重传未确认PDU的方式发送）。由于标准中已经给出了“重传合适PDU以执行查询”的示范，将这一救济手段横向拓宽应用到“由其他触发源（如Last PDU）引发的延迟查询”中，对于本领域技术人员而言，解决死锁的动机极强，且该改动仅是去掉了步骤1007的触发源限制（放宽条件），属于**显而易见的逻辑优化，不具备突出的实质性特点和显著的进步**。

---

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

由于目标专利解决的是3GPP RLC标准的死锁缺陷（Deadlock），这种协议层面的缺陷在标准制定过程中通常会有极其详尽的讨论记录。建议采取以下精准检索策略：

1. **3GPP Tdoc 专项检索（最有效途径）**：

* **检索源**：3GPP FTP 历史档案（针对 TSG-RAN WG2 会议室）。

* **时间窗口**：重点锁定 **2004年6月（V6.1.0发布后）至 2005年9月15日（目标专利申请日）** 之间的会议提案（Tdocs）。

* **关键词**：`Timer_Poll_Prohibit`、`Tprohibit`、`deadlock`、`polling`、`TS 25.322`、`missing poll`、`reset`。

* **目标**：寻找当时其他电信厂商（如Ericsson, Nokia, Motorola, Huawei等）提交的 **CR（Change Request，标准修改提案）**。在3GPP会议中，很可能有代表已经指出了“当非定时催询触发的查询被Prohibit延迟，且后续无数据时会导致死锁”这一Bug，并提出了“去掉触发源限制”的解决方案。如果能检索到比2005年9月15日更早的、公开了该Bug及解法的Tdoc，将形成强有力的现有技术证据。

2. **专利文献多路组合检索**：

* **检索式设计**：

`(RLC OR "Radio Link Control") AND (poll* OR "status report" OR "查询" OR "接收状态") AND (prohibit* OR "暂禁" OR "禁止") AND (retransmit* OR "重传") AND (deadlock OR "死锁" OR "闲置" OR "idle")`

* **重点关注申请人**：爱立信（Ericsson）、诺基亚（Nokia）、高通（Qualcomm）、三星（Samsung）、摩托罗拉（Motorola）。这些企业是2000-2005年间3GPP RLC层标准的主要贡献者，极有可能在自身专利申请中披露了相似的规避死锁方案。

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

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