**对比文件**：2008-07-24_JP2008172380A_发明专利_JP2008172380A Base station device used for mobile communication system, and user device and method
**目标专利**：1884在无线通讯系统中改善等待时间的方法及装置CN103096472B
**调用的模型名称**：gpt-4（自定义模型）
---
## 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用（翻译） | 公开性论述 |
| 技术特征A：包括在一使用者设备中接收一消息（未公开） | 对比文件在图3的步骤S6及图6的步骤S1中记载了“决定的事件参数（イベントパラメータ）通知给用户装置”以及“用户装置从服务小区的基站接收事件参数”。（原说明书记载：“イベントパラメータがユーザ装置に通知される”、“在圏セルの基地局からイベントパラメータを受け取る”） | 目标专利的特征A是在使用者设备中接收一消息，该消息用于后续指示等待时间（eWaitTime），而对比文件接收的是用于配置测量报告的事件参数消息，两者消息的内容、目的和作用完全不同。因此，对比文件未公开特征A所述的在目标专利特定场景下接收消息的技术方案。 |
| 技术特征B：其中该消息用以指示一eWaitTime（未公开） | 对比文件全文未出现“eWaitTime”“等待时间”或“延长等待时间”等相关描述。 | 目标专利的特征B要求消息明确用于指示一个延长等待时间（eWaitTime），而对比文件中接收的事件参数仅用于配置测量报告条件，没有任何涉及等待时间或过载控制的指示。因此，对比文件未公开该特征。 |
| 技术特征C：该使用者设备进入对应于该eWaitTime的一等待时间；并且使用者设备在该等待时间内不允许启动一延迟容忍或低优先级的无线电资源控制(RRC)连接请求（未公开） | 对比文件全文未涉及“等待时间”“禁止连接请求”“延迟容忍”或“低优先级”等概念。 | 目标专利的特征C描述了与eWaitTime对应的等待时间以及在此期间的连接限制，对比文件没有等待时间机制，也没有对连接请求原因进行限制，更没有延迟容忍或低优先级的教导。因此，对比文件未公开该特征。 |
| 技术特征D：当该使用者设备在该等待时间内收到传呼该使用者设备的一传呼消息时（未公开） | 对比文件在图6的步骤说明及图7的描述中提到“空闲状态下用户装置间歇监测寻呼频道（ページングチャネル）等待来电”。（原说明书记载：“アイドル状態では、ユーザ装置は間欠的にページングチャネルをモニタし、着信を待ち受けている”） | 目标专利中的特征D明确限定在“等待时间内”收到传呼消息，而对比文件描述的是正常空闲状态下的寻呼监测，不存在等待时间的前提。因此，对比文件未公开该特征。 |
| 技术特征E：将该等待时间视为结束（未公开） | 对比文件全文未出现“将等待时间视为结束”或类似概念。 | 特征E是在等待时间内收到传呼消息后的一种特定操作，对比文件没有任何等待时间管理机制，也未公开任何将等待视为结束的操作。因此，未公开。 |
| 技术特征F：还包括响应传呼该使用者设备的该传呼消息（**直接公开**） | 对比文件在说明书中明确记载：“在响应来叫通知（着信通知）时，也会建立RRC连接”（原文明：“着信応答時にもＲＲＣコネクションが設定される”）；同时，图6及图7描述了空闲状态下用户装置响应寻呼消息并执行连接建立的过程。 | 对比文件明确公开了用户设备响应寻呼消息（传呼消息）的动作，即当接收到寻呼消息后会发起RRC连接建立，这与目标专利中响应传呼消息的操作完全相同。虽然目标专利中的响应是在特定场景（等待时间视为结束之后）进行，但特征F本身仅描述“响应传呼消息”这一基本动作，对比文件公开了该动作，且两者作用均为对寻呼作出应答，因此构成直接公开。 |
| 技术特征G：该使用者设备启动一连接建立程序（**直接公开**） | 同上，对比文件记载：“在响应来叫通知时，也会建立RRC连接”（原文明：“着信応答時にもＲＲＣコネクションが設定される”），并且详细描述了在收到寻呼后启动RRC连接建立程序的过程。 | 特征G描述的是响应传呼消息后启动连接建立程序，对比文件明确公开了这一操作：用户设备在收到寻呼消息后会启动RRC连接建立程序（例如进行RRC CONNECTION SETUP）。该操作在对比文件中与目标专利中均为建立连接，作用相同。因此，对比文件直接公开了特征G。 |
| 技术特征H：其中该连接请求中指出的原因为延迟容忍或低优先级（未公开） | 对比文件全文未提及“延迟容忍”“低优先级”或任何连接请求原因值的设置。 | 目标专利的特征H要求连接请求中携带特定的原因（延迟容忍或低优先级），对比文件虽涉及连接请求，但未指定任何原因值，更没有延迟容忍或低优先级的教导。因此，未公开。 |
| 技术特征I：其中在该等待时间内（未公开） | 对比文件无等待时间概念。 | 特征I限定在等待时间内，对比文件无对应内容。 |
| 技术特征J：允许该使用者设备启动一原因为紧急情况的无线电资源控制连接请求（未公开） | 对比文件全文未提及“紧急情况”或“紧急连接请求”。 | 特征J要求在等待时间内允许紧急呼叫，对比文件未涉及紧急情况下的特殊处理，未公开。 |
| 技术特征K：而该等待时间不受影响（未公开） | 对比文件无等待时间影响的概念。 | 特征K与等待时间管理相关，对比文件未公开任何等待时间的管理机制，未公开。 |
| 技术特征L：其中在该使用者设备接收不是传呼该使用者设备的一传呼消息时（未公开） | 对比文件仅有普通寻呼监测的描述，未区分是否传呼自己。 | 特征L限定接收非传呼自己的消息的情况，对比文件未涉及此区分，未公开。 |
| 技术特征M：该使用者设备并不将该等待时间视为结束（未公开） | 对比文件无等待时间结束的概念。 | 特征M是与等待时间结束判断相关的否定操作，对比文件未公开任何等待时间操作，未公开。 |
| 技术特征N：其中该消息为无线电资源控制连接拒绝消息或无线电资源控制连接解除消息（未公开） | 对比文件中的消息是事件参数（イベントパラメータ），并非RRC连接拒绝或连接解除消息。原说明书记载：“イベントパラメータが報知情報として又は特定のユーザ装置宛の個別制御情報として通知されてもよい”。 | 特征N限定了消息的具体类型（RRC连接拒绝或连接解除消息），对比文件的消息类型为测量报告配置消息（事件参数），完全不同。因此，未公开。 |
| 技术特征O：其中该传呼消息包含一过载信息用以指示一核心网络过载结束（未公开） | 对比文件未涉及核心网络过载或过载信息。 | 特征O要求传呼消息携带过载信息指示核心网络过载结束，对比文件无任何过载相关内容，未公开。 |
| 技术特征P：其中将该等待时间视为结束包括该使用者设备停止一对应该等待时间的定时器（未公开） | 对比文件未公开等待时间定时器及其停止操作。 | 特征P描述了停止定时器的具体动作，对比文件无对应定时器机制，未公开。 |
| 技术特征Q：其中该等待时间是由一定时器所控制（未公开） | 对比文件未公开任何与等待时间相关的定时器。 | 特征Q涉及等待时间由定时器控制，对比文件未披露任何等待时间定时器，未公开。 |
| 技术特征R：其中在接收到该eWaitTime后则开始该等待时间（未公开） | 对比文件无eWaitTime或类似参数的接收及等待时间开始。 | 特征R要求接收到eWaitTime后开始等待时间，对比文件不存在该触发逻辑，未公开。 |
---
根据以上比对，对比文件直接公开了技术特征F和技术特征G。
未公开的技术特征未在结尾插入相应代码。
<<<F>>><<<G>>>