对比文件名称：2009-03-04_CN101379732A_发明公开_CN101379732A 在移动通信系统中请求无线资源的方法
目标专利名称：761用于配置多个调度请求触发的方法和装置CN104170491B
本次调用的模型名称：DeepSeek
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| 技术特征A：所述方法包括以下步骤：a.基于所述用户设备的多种业务的业务特性，为所述用户设备确定多个调度请求触发以及对应于所述多个调度请求触发中的每个调度请求触发的传输类型<br>《隐含公开》 | 对比文件说明书第17页第9-20行：“根据本发明的第二方法，终端根据数据服务类型来确定是使用RACH还是使用控制信号。换言之，终端对于不易受延时影响的数据服务使用控制信号，而对于更易受延时影响的数据服务使用RACH。”以及“根据本发明的第三方法，终端根据数据的优先级来确定是使用RACH还是使用控制信号。换言之，终端对于具有高优先级的服务使用RACH，而对于具有低优先级的服务使用控制信号。” | 对比文件公开了根据业务特性（数据服务类型、优先级）来确定传输类型（RACH或控制信号），这与目标专利中根据业务特性确定调度请求触发及传输类型的思路一致。虽然对比文件描述的是终端侧的选择行为，但本领域技术人员可以合理推理出，基站需要根据业务特性隐式或显式地为UE确定对应的调度请求触发方式和传输类型，例如通过配置规则或信令指示。因此，对比文件隐含公开了技术特征A。 |
| 技术特征B：b.将所述多个调度请求触发的配置信息发送至所述用户设备<br>《未公开》 | 未公开 | 对比文件主要描述终端根据自身判断选择RACH或控制信号，没有公开基站主动将“多个调度请求触发”的配置信息发送给用户设备的过程。对比文件未涉及基站侧配置多个调度请求触发并发送配置信息的概念。 |
| 技术特征C：其中所述多个调度请求触发的所述配置信息包括所述多个调度请求触发相对于所述用户设备的多种业务的映射方式以及对应于所述多个调度请求触发中的每个调度请求触发的传输类型<br>《未公开》 | 未公开 | 对比文件没有公开“多个调度请求触发”这一概念，也没有公开配置信息中包含“映射方式”和“传输类型”的具体内容。对比文件仅公开了终端根据业务特性选择发送请求的方式，而非基站配置映射关系。 |
| 技术特征D：其中所述多个调度请求触发中的每个调度请求触发的传输类型是基于对应于该调度请求触发的业务的优先级确定的<br>《直接公开》 | 对比文件说明书第17页第16-20行：“根据本发明的第三方法，终端根据数据的优先级来确定是使用RACH还是使用控制信号。换言之，终端对于具有高优先级的服务使用RACH，而对于具有低优先级的服务使用控制信号。” | 对比文件明确公开了根据数据服务的优先级来确定使用RACH（一种传输类型）还是控制信号（另一种传输类型），这与目标专利中传输类型基于业务优先级确定的原则完全相同。尽管对比文件描述的是终端行为，但该原则本身已被直接公开。 |
| 技术特征E：-在RACH上传输<br>《直接公开》 | 对比文件说明书第17页第9-20行多次提及“使用RACH”，例如“对于更易受延时影响的数据服务使用RACH”。 | 对比文件全文多处公开了在RACH上传输请求信号，RACH作为传输类型已被直接公开。 |
| 技术特征F：-在专用调度请求资源上传输<br>《隐含公开》 | 对比文件说明书第16页第9-15行：“本发明提供了一种方法，当终端处于RRC连接状态并且没有上行无线资源时，如果需要将数据发送到基站，该方法使得终端能够利用上行链路的控制信号以及RACH来请求无线资源。优选的是，该控制信号包括表示下行链路信道状态的CQI信息、HARQ的ACK/NACK信令以及RLC层的状态报告消息之一。” | 对比文件公开了使用“控制信号”（如CQI、ACK/NACK）作为RACH之外的替代方式来请求无线资源。这些控制信号通常在上行控制信道（PUCCH）上传输，PUCCH资源是基站专门分配给UE用于传输控制信息的，其性质类似于目标专利中的“专用调度请求资源”。本领域技术人员可以合理推理出，该控制信号资源属于一种专用的、非竞争的资源，与RACH形成对比，因此隐含公开了专用调度请求资源这一传输类型。 |
| 技术特征G：-所述用户设备的承载的QoS<br>《未公开》 | 未公开 | 对比文件没有提及“承载的QoS”作为业务特性的表征方式。 |
| 技术特征H：-逻辑信道的分组<br>《未公开》 | 未公开 | 对比文件没有提及“逻辑信道的分组”作为业务特性的表征方式。 |
| 技术特征I：-缓存状态报告的不同类型<br>《未公开》 | 未公开 | 对比文件虽然提到了缓存状态（如第15页第3行“终端的缓存状态”），但未提及“缓存状态报告的不同类型”作为区分业务的特性。 |
| 技术特征J：-运行的应用的特性<br>《直接公开》 | 对比文件说明书第17页第9-13行：“根据本发明的第二方法，终端根据数据服务类型来确定是使用RACH还是使用控制信号。换言之，终端对于不易受延时影响的数据服务使用控制信号，而对于更易受延时影响的数据服务使用RACH。” | 对比文件明确公开了“数据服务类型”，包括“易受延时影响”和“不易受延时影响”，这直接对应于目标专利中“运行的应用的特性”（例如后台应用对时延不敏感，视频应用对时延敏感）。因此，该技术特征被直接公开。 |
| 技术特征K：当所述用户设备的一种业务是由后台应用程序产生的业务时，对应于所述后台应用程序产生的业务的调度请求触发被配置为在具有较长周期的专用调度请求资源上传输，而所述多个调度请求触发中的其余调度请求触发被配置为在具有不同RACH配置的RACH上传输<br>《未公开》 | 未公开 | 对比文件没有公开“后台业务”这一特定类型，也没有公开为其配置“较长周期的专用调度请求资源”，更未涉及其他调度请求触发配置在具有不同RACH配置的RACH上。 |
| 技术特征L：当所述用户设备的一种业务是由后台应用程序产生的业务时，所有的所述多个调度请求触发被配置为在具有不同RACH配置的RACH上传输<br>《未公开》 | 未公开 | 对比文件没有公开“后台业务”以及“所有调度请求触发均在具有不同RACH配置的RACH上传输”这一特定场景。 |
| 技术特征M：分配给PRACH的物理资源包括以下任一种：-RACH的时间资源和周期<br>《直接公开》 | 对比文件说明书第8页第22-24行：“例如，如果RACH资源的分配周期是10ms，则终端要等待10ms以使用RACH。”以及第17页第5-7行：“考虑RACH资源周期是TRACH，终端对于下一RACH资源周期（其中为缓存的新数据请求无线资源）的等待时间是TRACH-NOW”。 | 对比文件明确公开了RACH资源的“周期”这一时间资源概念，本领域技术人员可以直接确定其属于PRACH的物理资源的一部分。 |
| 技术特征N：-RACH的前导码的组<br>《隐含公开》 | 对比文件说明书第5页第10-18行：“当终端的MAC层向终端的物理层指示PRACH传输时，该终端的物理层选择一个接入时隙和一个签名，以经由上行链路发送PRACH前导码。...选出16个签名中的一个并在接入时隙的开始部分的特定时长中发送该签名。” | 对比文件公开了通过选择不同的“签名”（即前导码）来区分不同的接入尝试。虽然未明确提及“前导码的组”，但本领域技术人员可以合理推理出，当需要区分不同业务或不同调度请求触发时，可以将这些前导码分为不同的组，并分配不同的组给不同的请求类型。因此，该技术特征被隐含公开。 |
| 技术特征O：所述配置信息通过专用RRC信令或者广播信令发送<br>《未公开》 | 未公开 | 对比文件没有提及通过RRC信令或广播信令发送与“多个调度请求触发”相关的配置信息。 |
| 技术特征P：所述用户设备为RRC连接的用户设备<br>《直接公开》 | 对比文件说明书第15页第12-14行：“本发明提供了一种方法，当终端处于RRC连接状态并且没有上行无线资源时，如果需要将数据发送到基站，该方法使得终端能够利用上行链路的控制信号以及RACH来请求无线资源。” | 对比文件明确公开了终端处于“RRC连接状态”，即目标专利中的“RRC连接的用户设备”。 |
| 技术特征Q：所述通信系统为LTE通信系统<br>《直接公开》 | 对比文件说明书第2页第7-9行：“第三代合作伙伴计划(3GPP)正在开发E-UMTS系统的基本标准。E-UMTS系统可以被称作为长期演进(LTE)系统。” | 对比文件说明书明确将E-UMTS系统称为LTE系统，直接公开了通信系统为LTE。 |
| 技术特征R：所述方法包括以下步骤：i.从所述基站接收与多个调度请求触发相关的配置信息，其中所述配置信息包括所述多个调度请求触发相对于所述用户设备的多种业务的映射方式以及对应于所述多个调度请求触发中的每个调度请求触发的传输类型，其中所述多个调度请求触发中的每个调度请求触发的传输类型是基于对应于该调度请求触发的业务的优先级确定的，并且其中所述传输类型是下列任一种：-在RACH上传输<br>《未公开》 | 未公开 | 对比文件没有公开终端从基站接收“多个调度请求触发”的配置信息。对比文件中终端是自行决定使用RACH还是控制信号，而不是基于基站配置的映射方式。 |
| 技术特征S：-在专用调度请求资源上传输；并且中当所述传输类型为在RACH上传输时，所述传输类型包括RACH配置且所述RACH配置包括PRACH的物理资源<br>《未公开》 | 未公开 | 由于对比文件没有公开“专用调度请求资源”这一明确概念（参见特征F的论述，此处为隐含公开，但特征S要求的是接收包含该传输类型的配置信息，对比文件未公开），也未公开“接收配置信息”这一步骤，因此特征S未被公开。 |
| 技术特征T：其特征在于，所述方法还包括以下步骤：ii.基于当前业务的业务特性以及所述映射方式，选择对应于所述当前业务的调度请求触发<br>《隐含公开》 | 对比文件说明书第17页第9-20行：“根据本发明的第二方法，终端根据数据服务类型来确定是使用RACH还是使用控制信号。...根据本发明的第三方法，终端根据数据的优先级来确定是使用RACH还是使用控制信号。” | 对比文件公开了终端根据当前业务的特性（服务类型、优先级）来选择对应的请求方式（RACH或控制信号）。虽然对比文件没有使用“调度请求触发”这一术语，但其“请求无线资源”的行为本质就是目标专利中的“调度请求触发”。本领域技术人员可以合理推理出，这一选择过程与目标专利中选择对应于当前业务的调度请求触发是一致的。因此，该特征被隐含公开。 |
| 技术特征U：iii.通过对应于所述调度请求触发的传输类型，传输所触发的调度请求<br>《直接公开》 | 对比文件说明书第16页第14-15行：“终端10可以使用控制信号，诸如CQI信息、HARQ的ACK/NACK信令以及RLC层的状态报告，来从基站20请求无线资源。”以及第17页第9-13行：“终端对于更易受延时影响的数据服务使用RACH。” | 对比文件明确公开了终端通过所选择的传输类型（RACH或控制信号）来发送无线资源请求（即目标专利中的调度请求）。例如，若选择RACH，则在RACH上发送前导码；若选择控制信号，则在控制信道上发送包含请求指示的信息。这直接对应于目标专利中通过对应传输类型传输所触发的调度请求。 |
| 技术特征V：所述装置包括：第一单元，用于基于所述用户设备的多种业务的业务特性，为所述用户设备确定多个调度请求触发以及对应于所述多个调度请求触发中的每个调度请求触发的传输类型<br>《未公开》 | 未公开 | 对比文件没有公开基站侧具有用于“确定多个调度请求触发”的特定单元。对比文件中的基站行为是被动分配资源，而非主动为UE配置多个触发。 |
| 技术特征W：第二单元，用于将所述多个调度请求触发的配置信息发送至所述用户设备，其中所述多个调度请求触发的所述配置信息包括所述多个调度请求触发相对于所述用户设备的多种业务的映射方式以及对应于所述多个调度请求触发中的每个调度请求触发的传输类型，其中所述多个调度请求触发中的每个调度请求触发的传输类型是基于对应于该调度请求触发的业务的优先级确定的，并且其中所述传输类型是下列任一种：-在RACH上传输<br>《未公开》 | 未公开 | 对比文件没有公开基站侧具有用于发送“多个调度请求触发的配置信息”的第二单元。 |
| 技术特征X：-在专用调度请求资源上传输；并且中当所述传输类型为在RACH上传输时，所述传输类型包括RACH配置且所述RACH配置包括PRACH的物理资源<br>《未公开》 | 未公开 | 由于对比文件未公开“专用调度请求资源”的装置侧配置（参见特征S的论述），也未公开基站侧用于发送包含这些配置信息的第二单元，因此特征X未被公开。 |
<<<D>>><<<E>>><<<J>>><<<M>>><<<P>>><<<Q>>><<<U>>><<<a>>><<<f>>><<<n>>><<<t>>>