对比文件名称：2011-08-25_None_发明专利_JPWO2009133599A1 無線通信システムにおける接続処理方法並びに無線基地局及び無線端末
目标专利名称：1884在无线通讯系统中改善等待时间的方法及装置CN103096472B
本次调用的模型名称：大规模语言模型（未指定具体版本）
以下为特征比对表格。表格中对每个技术特征按权利要求划分进行逐项比对，第二栏提供对比文件的原文引用（日文及中文翻译）并标注段落标号，第三栏进行公开性论述。公开性结论分为《直接公开》《隐含公开》《未公开》。
| 第一栏：技术特征描述及公开性判断结果 | 第二栏：对比文件原文引用（含中文翻译） | 第三栏：公开性论述 |
| 技术特征A：包括在一使用者设备中接收一消息<br>《直接公开》 | [0032]“eNBは、UEに対して、前記Msg4として接続を許可しない（拒否又は保留）ことを意味するメッセージ“radio resource control（RRC） connection reject”を通知する。”（译：eNB向UE通知表示不允许连接（拒绝或保留）的消息“RRC connection reject”作为Msg4。）<br>此外[0069]同样明确UE接收该RRC connection reject消息。 | 对比文件直接公开了eNB向UE发送RRC连接拒绝消息，该消息由UE接收，因此技术特征“UE接收一消息”被毫无疑义地公开。 |
| 技术特征B：其中该消息用以指示一eWaitTime<br>《直接公开》 | [0032]“このメッセージには、ＲＡを再実行すべきタイミング（待機時間）に関する情報を含めることができる。”（译：该消息可以包含关于应重新执行RA的定时（等待时间）的信息。） | 对比文件明确公开RRC连接拒绝消息中包含“待機時間”（等待时间）信息，该等待时间与目标专利中的eWaitTime作用相同，用于控制UE后续连接尝试的延迟，因此特征B被直接公开。 |
| 技术特征C：该使用者设备进入对应于该eWaitTime的一等待时间；并且使用者设备在该等待时间内不允许启动一延迟容忍或低优先级的无线电资源控制连接请求<br>《隐含公开》 | [0032]公开了消息中包含等待时间信息；[0070]描述UE根据消息内容进行处理，隐含了等待时间内不发起新连接（常规退避行为）。但未明确提及“延迟容忍”或“低优先级”。（译：UE在接收到RRC连接拒绝及等待时间后，通常会在等待时间内禁止发起新的RRC连接请求。） | 对比文件直接公开了进入等待时间（对应eWaitTime），并且本领域公知在定时器T302运行期间UE通常不允许发起RRC连接请求（除非紧急呼叫）。虽然对比文件未特别限定“延迟容忍或低优先级”原因，但其公开的等待时间机制可以涵盖此类原因，且MTC相关原因为3GPP标准中已知，因此通过推理可以合理得出该特征，故判断为隐含公开。 |
| 技术特征D：当该使用者设备在该等待时间内收到传呼该使用者设备的一传呼消息时<br>《未公开》 | 对比文件中没有发现任何关于在等待时间内接收寻呼消息的记载。 | 对比文件全文未涉及通过寻呼消息来打断或影响等待时间，也未提及UE在等待时间内监听寻呼并响应。本领域技术人员无法从对比文件推导出该场景，因此特征D未公开。 |
| 技术特征E：将该等待时间视为结束<br>《未公开》 | 对比文件中没有发现等待时间因寻呼而结束的公开内容。 | 对比文件仅提到等待时间用于退避，但未给出任何提前结束等待时间的触发条件，更未涉及寻呼消息，因此特征E未公开。 |
| 技术特征F：还包括响应传呼该使用者设备的该传呼消息<br>《未公开》 | 对比文件中没有发现响应寻呼消息的步骤。 | 对比文件未公开任何与寻呼相关的操作，因此特征F未公开。 |
| 技术特征G：该使用者设备启动一连接建立程序<br>《未公开》 | 对比文件中没有公开在等待时间内因寻呼而启动连接建立程序。 | 对比文件仅描述在等待时间结束后（或使用优先信息）重新发起随机接入，但并未涉及在等待时间内响应寻呼发起连接建立，因此特征G未公开。 |
| 技术特征H：其中该连接请求中指出的原因为延迟容忍或低优先级<br>《未公开》 | 对比文件中没有提及连接请求中携带“延迟容忍”或“低优先级”原因。 | 对比文件未公开任何关于连接请求原因的分类，特别是MTC特有的延迟容忍或低优先级原因，因此特征H未公开。 |
| 技术特征I：其中在该等待时间内<br>《隐含公开》 | [0032]等段落公开了UE会进入一段由等待时间控制的时期。 | 对比文件明确公开了“等待时间”这一时间段，因此“在该等待时间内”这一时间范围被隐含公开。 |
| 技术特征J：允许该使用者设备启动一原因为紧急情况的无线电资源控制连接请求<br>《未公开》 | 对比文件中没有关于紧急呼叫处理的记载。 | 对比文件未对紧急情况下的连接请求作任何例外规定，因此特征J未公开。 |
| 技术特征K：而该等待时间不受影响<br>《未公开》 | 对比文件中没有提及紧急呼叫与等待时间的关系。 | 对比文件未公开紧急呼叫是否会影响等待时间，因此特征K未公开。 |
| 技术特征L：其中在该使用者设备接收不是传呼该使用者设备的一传呼消息时<br>《未公开》 | 对比文件中没有涉及区分寻呼消息归属的描述。 | 对比文件未公开收到非自身寻呼消息的情况及其对等待时间的影响，因此特征L未公开。 |
| 技术特征M：该使用者设备并不将该等待时间视为结束<br>《未公开》 | 对比文件中没有关于等待时间结束条件的任何限定。 | 对比文件未公开任何关于等待时间结束的规则，更未区分是否收到自身寻呼，因此特征M未公开。 |
| 技术特征N：其中该消息为无线电资源控制连接拒绝消息或无线电资源控制连接解除消息<br>《直接公开》 | [0032]明确公开了消息为“radio resource control（RRC） connection reject”。（译：RRC连接拒绝消息。） | 对比文件直接公开了作为特征B中的消息是RRC连接拒绝消息（RRC Connection Reject），因此特征N被直接公开。 |
| 技术特征O：其中该传呼消息包含一过载信息用以指示一核心网络过载结束<br>《未公开》 | 对比文件中没有公开通过寻呼消息指示核心网络过载结束的内容。 | 对比文件虽然提及过载情况，但未涉及核心网络过载，也未公开在寻呼中包含过载结束信息，因此特征O未公开。 |
| 技术特征P：其中将该等待时间视为结束包括该使用者设备停止一对应该等待时间的定时器<br>《未公开》 | 对比文件中没有公开停止定时器作为等待时间结束的操作。 | 对比文件未公开任何关于停止定时器的机制，因此特征P未公开。 |
| 技术特征Q：其中该等待时间是由一定时器所控制<br>《隐含公开》 | [0032]提及“待機時間”但未明确说明定时器。在LTE标准中，这类等待时间通常由定时器T302实现。 | 本领域技术人员公知，在3GPP LTE系统中，RRC连接拒绝后UE会启动定时器T302来控制等待时间。对比文件虽然未明确写出“定时器”，但根据其公开的等待时间概念，结合标准常识可以合理推断该等待时间由定时器控制，因此特征Q被隐含公开。 |
| 技术特征R：其中在接收到该eWaitTime后则开始该等待时间<br>《直接公开》 | [0032]公开了消息中包含等待时间信息；[0070]等描述了UE根据消息中的信息执行后续操作（包括开始等待）。 | 对比文件直接公开了UE在接收到包含等待时间（eWaitTime）的RRC连接拒绝消息后进入等待时间，因此特征R被直接公开。 |
根据上述比对结果，对比文件直接公开了技术特征A、B、N、R，隐含公开了技术特征C、I、Q。其余技术特征（D、E、F、G、H、J、K、L、M、O、P）未被公开。
结尾代码（按特征字母顺序排列）：
<<<A>>><<<B>>><<<N>>><<<R>>><<<c>>><<<i>>><<<q>>>