**对比文件名称**：发明申请_US20200146054A1 Random Access Response Reception
**目标专利名称**：随机接入响应类型区分
**本次调用模型名称**：DeepSeek
### **特征比对表格**
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **A：一种由用户设备(UE)执行的无线通信方法**<br>**判断结果：隐含公开** | 对比文件全文多处描述了UE（无线设备）执行的随机接入操作，例如第[0253]段：“A wireless device may monitor a downlink control channel (e.g., after or in response to transmitting an RAP) for a downlink control message (e.g., an RAR) corresponding to the RAP.” | 根据目标专利说明书[0007]段及图5、图8的描述，该方法由UE执行。对比文件通篇以“wireless device”为主体，详细描述了其在随机接入过程中的一系列操作，包括发送前导码、监听控制信道、接收响应等。这些操作的集合，构成了由UE执行的无线通信方法。本领域技术人员可以直接从对比文件的整体描述中，确定其公开了一种由UE执行的无线通信方法，这与目标专利中技术特征A所定义的主体和范畴是相同的。因此，该技术特征被对比文件隐含公开。 |
| **B：接收指示与随机接入响应(RAR)类型相关联的传输参数的配置信息，其中所述传输参数包括物理下行链路控制信道(PDCCH)通信中携带的下行链路控制信息(DCI)的循环冗余校验(CRC)掩码**<br>**判断结果：未公开** | 对比文件未找到明确记载“CRC掩码”作为用于区分RAR类型的传输参数的相关内容。 | 目标专利的技术特征B明确限定了传输参数的具体类型为“DCI的CRC掩码”，并用于与RAR类型关联。对比文件虽然广泛讨论了随机接入配置（如RACH-ConfigCommon等），并提到了PDCCH、DCI和CRC的概念（例如在描述DCI格式和RAR接收时），但全文并未提及使用CRC掩码作为区分不同RAR类型的传输参数或方案。本领域技术人员无法从对比文件的任何内容中，直接或通过合理推理得出“使用DCI的CRC掩码来指示RAR类型”这一特定技术手段。因此，该技术特征未被对比文件公开。 |
| **C：发送与所述RAR类型相关联的随机接入消息**<br>**判断结果：隐含公开** | 第[0253]段：“A wireless device may monitor a downlink control channel (e.g., after or in response to transmitting an RAP) for a downlink control message (e.g., an RAR) corresponding to the RAP.” | 目标专利中，“随机接入消息”对应于msgA或msg1。对比文件中的“RAP”（随机接入前导码）或“Msg1”即为随机接入消息。虽然对比文件未明确使用“与RAR类型相关联”这一表述，但其第[0451]段及图43、44的描述揭示了系统帧号(SFN)可用于区分不同RAR，而UE发送前导码的时机（特定的slot和symbol）决定了用于计算RA-RNTI的SFN_id等参数，这些参数最终关联到不同的RAR。因此，UE发送的随机接入消息（RAP）实质上与一个由SFN等参数隐含指示的特定RAR类型相关联。本领域技术人员可以合理推断出这一关联性。故该技术特征被隐含公开。 |
| **D：在发送所述随机接入消息之后，使用传输参数来获得物理下行链路控制信道(PDCCH)通信**<br>**判断结果：隐含公开** | 第[0256]-[0258]段描述了在发送RAP后，启动RAR窗口并监视PDCCH以接收RAR，RAR由RA-RNTI标识。例如第[0258]段：“The wireless device may monitor the first downlink control channel occasion of the SpCell for RAR(s) identified by an RA-RNTI.” | 目标专利中“使用传输参数来获得PDCCH通信”指UE利用配置的特定参数（如加扰ID、CRC掩码等）来解码PDCCH。对比文件中，UE在发送RAP后，使用基于RAP发送资源（s_id, t_id, f_id等）计算出的RA-RNTI来识别和接收PDCCH（具体为承载RAR的PDCCH）。这里的RA-RNTI是根据传输随机接入消息的特定参数生成的，其作用等同于一个用于获取特定PDCCH通信的“传输参数”。虽然对比文件未使用“传输参数”这一概括术语，但RA-RNTI所起的作用和实现方式，与本领域技术人员所理解的“用于获得PDCCH通信的参数”是一致的。因此，该技术特征被对比文件隐含公开。 |
| **E：其中所述PDCCH通信与具有随机接入响应(RAR)类型的随机接入响应相关联，并且其中所述传输参数用于在不同RAR类型之间进行区分。**<br>**判断结果：隐含公开** | 第[0438]段：“A downlink control message (e.g., an medium access control packet comprising an RAR, a downlink control signal) may be configured to indicate a system frame number corresponding to an RA procedure to avoid collision. A radio network identifier (e.g., an RA-RNTI) used in an RA procedure may be calculated based on an indication of a system frame number (e.g., an SFN_id) corresponding to the RA procedure.” 以及图43及相关描述。 | 目标专利中，PDCCH调度特定RAR类型的RAR，传输参数用于区分类型。对比文件第[0438]段和附图43明确为了解决RAR窗口重叠导致的碰撞问题，提出了在RA-RNTI计算中引入系统帧号(SFN_id)。这意味着，在不同系统帧中发送RAP的UE，即使其他资源参数相同，也会计算出不同的RA-RNTI，从而对应不同的PDCCH/RAR。这实质上建立了一种基于SFN的RAR类型区分机制。PDCCH通信（通过其携带的RA-RNTI）与一个特定的SFN（可视为一种RAR类型标识）相关联，而SFN_id作为计算RA-RNTI的输入参数，起到了在不同RAR类型（对应不同SFN）之间进行区分的作用。因此，该技术特征被对比文件隐含公开。 |
| **F：还包括至少部分地基于是否使用所述传输参数成功地获得所述PDCCH通信而获得或制止获得由所述PDCCH通信调度的物理下行链路共享信道(PDSCH)通信，其中获得或制止获得所述PDSCH通信包括：如果使用所述传输参数成功接收到所述PDCCH通信，则获得所述PDSCH通信；或者如果使用所述传输参数没有成功接收到所述PDCCH通信，则制止获得所述PDSCH通信。**<br>**判断结果：未公开** | 对比文件描述了在RAR窗口内监视PDCCH以获得RAR（该RAR在PDSCH上传输），例如第[0258]段。但未描述UE基于是否成功解码PDCCH（例如通过匹配某个特定参数）来主动决定是否继续解码PDSCH的逻辑。 | 目标专利的技术特征F的核心在于UE的一种“提前终止”机制：UE使用与自身RAR类型匹配的传输参数尝试解码PDCCH，若失败（参数不匹配），则推断该PDCCH调度的PDSCH中的RAR不是自己需要的，从而提前放弃接收PDSCH，以节省功耗。对比文件仅描述了常规的RAR接收流程：UE在窗口内监听PDCCH，如果检测到匹配的RA-RNTI，则接收对应的PDSCH以获取RAR。它没有揭示或暗示UE可以根据用于解码PDCCH的“传输参数”是否匹配，来在解码PDCCH阶段就做出是否继续处理PDSCH的决策。这种基于参数匹配的早期过滤机制是目标专利的特定改进点，对比文件中未见记载或暗示。因此，该技术特征未被公开。 |
| **G：其中不同的RAR类型与不同的随机接入模式、不同的UE能力、不同的优先级、不同长度的RAR窗口或其组合中的至少一个相关联。**<br>**判断结果：隐含公开** | 第[0430]-[0432]段及图43讨论了延长RAR窗口（如20ms）以应对LBT失败，并指出这可能导致需要区分不同系统帧的RAR。第[0466]段及图46提到了RAR窗口大小与系统帧数量的关系。 | 目标专利说明书记载了RAR类型可与多种因素关联，包括RAR窗口长度（参见[0070]段）。对比文件为了解决未授权频谱上因LBT导致的延迟，提出了使用大于10ms（一个系统帧）的RAR窗口（如20ms）。如图43和46所示，更长的RAR窗口意味着响应可能覆盖多个系统帧。为了区分这些不同系统帧内的RAR，对比文件引入了基于SFN的RA-RNTI计算。在这里，**“不同长度的RAR窗口”**（例如10ms常规窗口 vs. 20ms扩展窗口）这一场景，直接关联到了需要使用不同标识（即基于不同SFN的RA-RNTI，可视为不同RAR类型的体现）来区分的RAR。因此，对比文件隐含公开了不同的RAR（类型）与不同长度的RAR窗口相关联。技术特征G中列举的其他关联因素（随机接入模式、UE能力、优先级）在对比文件中未见明确关联。 |
| **H：其中所述RAR是基于所述随机接入消息使用不同的RAR类型区分方案并发发送的具有不同RAR类型的多个RAR之一。**<br>**判断结果：未公开** | 第[0435]段描述了在重叠的RAR窗口时间内，基站发送的RAR可能被多个UE接收，但无法区分是针对哪个UE的。第[0438]段提出了解决方案：在RA-RNTI或RAR中指示SFN。 | 目标专利的特征H强调“并发发送”具有不同RAR类型的“多个RAR”。对比文件第[0435]段描述的问题场景（图43中重叠时间4310/4312）确实涉及基站可能在同一时间段内发送对应于不同SFN（即不同RAR类型）的RAR。然而，对比文件提出的解决方案（第[0438]段）旨在**避免**这种无法区分的并发传输，例如通过使用包含SFN的RA-RNTI来唯一标识PDCCH，或者通过在RAR中携带SFN信息供UE筛选。其目的是使每个RAR都能被正确区分和接收，而非描述一个“并发发送多个不同类型RAR”的既定方案。目标专利的该特征更侧重于描述存在多种RAR类型并发传输的系统状态，而对比文件侧重于描述该状态引发的问题及解决方案。因此，对比文件未直接或隐含公开此特征。 |
| **I：其中使用所述传输参数来获得所述PDCCH通信包括使用CRC掩码来对所述PDCCH通信执行CRC。**<br>**判断结果：未公开** | 对比文件未提及使用CRC掩码。 | 如特征B所述，对比文件完全未涉及“CRC掩码”这一特定技术手段。因此，使用CRC掩码来执行CRC的操作自然也未被公开。 |
| **J：还包括接收配置信息，所述配置信息指示用于调度具有第一RAR类型的RAR的PDCCH通信的第一组循环冗余校验(CRC)掩码，以及用于调度具有第二RAR类型的RAR的PDCCH通信的第二组CRC掩码。**<br>**判断结果：未公开** | 对比文件未提及CRC掩码组。 | 由于对比文件未公开“CRC掩码”作为传输参数，因此更不可能公开通过配置信息指示多组CRC掩码以对应不同RAR类型的技术特征。 |
| **K：其中所述第一组CRC掩码和所述第二组CRC掩码是互斥的。**<br>**判断结果：未公开** | 对比文件未提及CRC掩码组。 | 该特征是对特征J中CRC掩码组属性的进一步限定。由于特征J未被公开，此限定特征自然也未被公开。 |
| **L：其中所述传输参数包括与所述PDCCH通信相关联的控制资源集(CORESET)配置、与所述PDCCH通信相关联的搜索空间(SS)配置，或者其组合。**<br>**判断结果：隐含公开** | 第[0342]段：“A wireless device may be configured control resource sets for every type of common search space and for wireless device-specific search space, for example, for each DL BWP in a set of DL BWPs on the primary cell.” 第[0256]-[0258]段提到在特定的PDCCH occasion（可关联到特定的搜索空间）上监听RAR。 | 目标专利中，CORESET/SS配置可作为区分RAR类型的传输参数。对比文件明确记载了为UE配置控制资源集(CORESET)和搜索空间(SS)，并且UE在特定的PDCCH时机（与搜索空间相关）上监听RAR。虽然对比文件未明确将这些配置作为“区分RAR类型”的参数，但本领域技术人员知晓，不同的CORESET/SS配置天然地定义了不同的PDCCH监听时机和资源。在逻辑上，基站可以通过为不同类型RAR的PDCCH分配不同的CORESET或搜索空间，来实现区分。这种应用是配置功能的合理延伸。因此，对比文件隐含公开了传输参数可以包括CORESET配置或SS配置。 |
| **M：其中使用所述传输参数来获得所述PDCCH通信包括针对与所述RAR类型相关联的所述PDCCH通信，监视根据所述CORESET配置而配置的CORESET或根据所述SS配置而配置的SS中的至少一个。**<br>**判断结果：隐含公开** | 第[0258]段：“The wireless device may monitor the first downlink control channel occasion of the SpCell for RAR(s) identified by an RA-RNTI.” 结合第[0342]段关于配置CORESET/SS的描述。 | 目标专利的特征M描述了UE根据特定的CORESET/SS配置来监视PDCCH。对比文件记载了UE在配置的搜索空间/控制资源集上监视PDCCH以获得RAR。虽然未明确将此监视动作与“RAR类型”挂钩，但根据特征L的推理，如果不同的RAR类型对应不同的CORESET/SS配置，那么UE要获得某种类型的RAR，自然需要去监视对应的CORESET/SS。这是配置与监视行为之间的直接逻辑关系。因此，对比文件隐含公开了该技术特征。 |
| **N：还包括接收配置信息，所述配置信息指示用于调度具有第一RAR类型的RAR的PDCCH通信的第一控制资源集(CORESET)配置或第一搜索空间配置，以及用于调度具有第二RAR类型的RAR的第二CORESET配置或第二搜索空间配置。**<br>**判断结果：未公开** | 第[0342]段提到了配置CORESET和SS，但未提及这些配置与不同的RAR类型相关联。 | 对比文件虽然公开了配置CORESET和SS，但并未记载或暗示这些配置被用于区分和指示不同的RAR类型。目标专利的特征N明确要求配置信息将不同的CORESET/SS配置与不同的RAR类型关联起来。这一特定的关联性在对比文件中缺失。因此，该技术特征未被公开。 |
| **O：其中所述传输参数与用于区分不同RAR类型的传输方案相关联。**<br>**判断结果：隐含公开** | 第[0438]段及图43、44、45描述了通过修改RA-RNTI计算公式（引入SFN_id）来区分不同系统帧的RAR，这是一种具体的RAR类型区分方案。 | 目标专利的特征O指出传输参数关联于一个区分RAR类型的“传输方案”。对比文件第[0438]段等描述的内容，正是为了解决RAR碰撞问题而提出的一种具体的“传输方案”：通过使用包含SFN_id的RA-RNTI来区分RAR。在该方案中，SFN_id（以及计算RA-RNTI所需的其他参数）就是用于区分的“传输参数”。因此，对比文件公开了一种传输方案（基于SFN的RA-RNTI计算），并且该方案明确与用于区分的传输参数（SFN_id等）相关联。这隐含公开了技术特征O。 |
<<<a>>><<<c>>><<<d>>><<<e>>><<<g>>><<<l>>><<<m>>><<<o>>>