对比文件名称：2009-07-02_JP2009524978A_发明专利_JP2009524978A Radio resource request method in a mobile communication system
目标专利名称：761用于配置多个调度请求触发的方法和装置CN104170491B
模型名称：DeepSeek
### 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| 技术特征A：所述方法包括以下步骤：a.基于所述用户设备的多种业务的业务特性，为所述用户设备确定多个调度请求触发以及对应于所述多个调度请求触发中的每个调度请求触发的传输类型<br>**未公开** | 无直接引用 | 对比文件描述的是UE基于业务特性选择使用RACH或控制信号请求资源，并未涉及基站为用户设备确定多个调度请求触发及对应的传输类型，也没有基站配置多个调度请求触发的步骤。因此未公开。 |
| 技术特征B：b.将所述多个调度请求触发的配置信息发送至所述用户设备<br>**未公开** | 无直接引用 | 对比文件未涉及基站向用户设备发送多个调度请求触发的配置信息。 |
| 技术特征C：其中所述多个调度请求触发的所述配置信息包括所述多个调度请求触发相对于所述用户设备的多种业务的映射方式以及对应于所述多个调度请求触发中的每个调度请求触发的传输类型<br>**未公开** | 无直接引用 | 对比文件没有公开配置信息中包含映射方式。 |
| 技术特征D：其中所述多个调度请求触发中的每个调度请求触发的传输类型是基于对应于该调度请求触发的业务的优先级确定的<br>**隐含公开** | “本发明的第三方法中，所述终端根据数据优先级判断使用RACH还是控制信号。即，所述终端在服务优先级高时使用RACH，在服务优先级低时使用控制信号。”（对应对比文件第[2]段中关于第三方法的描述） | 对比文件明确公开了根据业务优先级确定传输类型（RACH或控制信号），虽然是以UE决策的角度，但公开了传输类型基于优先级确定的核心内容。目标专利的特征D强调传输类型基于业务优先级，对比文件公开了此关联，因此隐含公开。 |
| 技术特征E：并且其中所述传输类型是下列任一种：-在RACH上传输<br>**直接公开** | “本发明的第三方法中，所述终端根据数据优先级判断使用RACH还是控制信号。”以及“所述终端使用RACH向基站请求用于数据传输的无线资源。” | 对比文件多处提到通过RACH传输资源请求，例如UE使用RACH请求无线资源，直接公开了传输类型为在RACH上传输。 |
| 技术特征F：-在专用调度请求资源上传输；并且中当所述传输类型为在RACH上传输时，所述传输类型包括RACH配置且所述RACH配置包括PRACH的物理资源<br>**未公开** | 对于RACH配置部分：“终端的MAC指示终端的物理层进行PRACH传输时，终端的物理层选择一个接入时隙和一个签名，在UL上传输PRACH前导码。所述前导码以1.33ms长度的接入时隙间隔传输。在接入时隙的预定长度初始部分，从16个签名中选择一个签名传输。” | 对比文件公开了PRACH的物理资源（接入时隙、前导码），但未公开“专用调度请求资源”这一传输类型。特征F整体未公开，其中关于RACH配置包括PRACH物理资源的部分虽被公开，但不足以使整个特征公开。 |
| 技术特征G：其特征在于，所述用户设备的多种业务的业务特性通过以下任一种方式表征：-所述用户设备的承载的QoS<br>**未公开** | 无直接引用 | 对比文件未提及承载的QoS。 |
| 技术特征H：-逻辑信道的分组<br>**未公开** | 无直接引用 | 对比文件未提及逻辑信道分组。 |
| 技术特征I：-缓存状态报告的不同类型<br>**未公开** | 无直接引用 | 对比文件未提及缓存状态报告类型。 |
| 技术特征J：-运行的应用的特性<br>**隐含公开** | “本发明的第二方法中，所述终端根据数据服务类型判断使用RACH还是控制信号。即，所述终端在数据服务对延迟不敏感时使用控制信号，在数据服务对延迟敏感时使用RACH。”（对应对比文件第[2]段中关于第二方法的描述） | 对比文件中的数据服务类型（如延迟敏感或不敏感）可以看作是运行的应用的特性，因此隐含公开了业务特性可通过运行的应用的特性表征。 |
| 技术特征K：其特征在于，当所述用户设备的一种业务是由后台应用程序产生的业务时，对应于所述后台应用程序产生的业务的调度请求触发被配置为在具有较长周期的专用调度请求资源上传输，而所述多个调度请求触发中的其余调度请求触发被配置为在具有不同RACH配置的RACH上传输<br>**未公开** | 无直接引用 | 对比文件未涉及后台应用程序及对应的调度请求触发配置。 |
| 技术特征L：其特征在于，当所述用户设备的一种业务是由后台应用程序产生的业务时，所有的所述多个调度请求触发被配置为在具有不同RACH配置的RACH上传输<br>**未公开** | 无直接引用 | 对比文件未涉及后台应用程序及不同RACH配置。 |
| 技术特征M：其特征在于，分配给PRACH的物理资源包括以下任一种：-RACH的时间资源和周期<br>**直接公开** | “所述前导码以1.33ms长度的接入时隙间隔传输。” | 对比文件公开了RACH的时间资源（接入时隙）和周期（间隔），因此直接公开。 |
| 技术特征N：-RACH的前导码的组<br>**直接公开** | “在接入时隙的预定长度初始部分，从16个签名中选择一个签名传输。” | 对比文件公开了前导码（签名）组（16个签名），因此直接公开。 |
| 技术特征O：其特征在于，所述配置信息通过专用RRC信令或者广播信令发送<br>**未公开** | 无直接引用 | 对比文件未提及配置信息的发送方式。 |
| 技术特征P：其特征在于，所述用户设备为RRC连接的用户设备<br>**直接公开** | “在传统方法中，处于RRC连接状态且没有上行无线资源的终端...” | 对比文件明确提到了RRC连接状态的用户设备，因此直接公开。 |
| 技术特征Q：其特征在于，所述通信系统为LTE通信系统<br>**直接公开** | “所述E-UMTS也称为长期演进（LTE）系统。” | 对比文件直接指出其系统为LTE系统，因此直接公开。 |
| 技术特征R：所述方法包括以下步骤：i.从所述基站接收与多个调度请求触发相关的配置信息，其中所述配置信息包括所述多个调度请求触发相对于所述用户设备的多种业务的映射方式以及对应于所述多个调度请求触发中的每个调度请求触发的传输类型，其中所述多个调度请求触发中的每个调度请求触发的传输类型是基于对应于该调度请求触发的业务的优先级确定的，并且其中所述传输类型是下列任一种：-在RACH上传输<br>**未公开** | 无直接引用 | 对比文件未公开从基站接收多个调度请求触发的配置信息。 |
| 技术特征S：-在专用调度请求资源上传输；并且中当所述传输类型为在RACH上传输时，所述传输类型包括RACH配置且所述RACH配置包括PRACH的物理资源<br>**未公开** | 同技术特征F的引用 | 对比文件未公开专用调度请求资源，整体未公开。 |
| 技术特征T：其特征在于，所述方法还包括以下步骤：ii.基于当前业务的业务特性以及所述映射方式，选择对应于所述当前业务的调度请求触发<br>**隐含公开** | “本发明的第二方法中，所述终端根据数据服务类型判断使用RACH还是控制信号。”以及第三方法根据优先级判断。 | 对比文件公开了UE基于业务特性（服务类型或优先级）选择使用RACH或控制信号，这相当于选择对应于当前业务的传输方式。虽然未明确提及“映射方式”，但基于业务特性选择对应的传输方式等同于选择调度请求触发（因为传输类型与触发关联），因此隐含公开了该步骤。 |
| 技术特征U：iii.通过对应于所述调度请求触发的传输类型，传输所触发的调度请求<br>**隐含公开** | 同上，以及描述通过RACH或控制信号发送资源请求。 | 对比文件公开了通过所选择的RACH或控制信号发送资源请求（相当于调度请求），因此隐含公开了通过对应传输类型传输所触发的调度请求。 |
| 技术特征V：所述装置包括：第一单元，用于基于所述用户设备的多种业务的业务特性，为所述用户设备确定多个调度请求触发以及对应于所述多个调度请求触发中的每个调度请求触发的传输类型<br>**未公开** | 无直接引用 | 对比文件未公开基站中的相应单元。 |
| 技术特征W：第二单元，用于将所述多个调度请求触发的配置信息发送至所述用户设备，其中所述多个调度请求触发的所述配置信息包括所述多个调度请求触发相对于所述用户设备的多种业务的映射方式以及对应于所述多个调度请求触发中的每个调度请求触发的传输类型，其中所述多个调度请求触发中的每个调度请求触发的传输类型是基于对应于该调度请求触发的业务的优先级确定的，并且其中所述传输类型是下列任一种：-在RACH上传输<br>**未公开** | 无直接引用 | 对比文件未公开基站中的相应单元。 |
| 技术特征X：-在专用调度请求资源上传输；并且中当所述传输类型为在RACH上传输时，所述传输类型包括RACH配置且所述RACH配置包括PRACH的物理资源<br>**未公开** | 无直接引用 | 对比文件未公开相应单元。 |
<<<d>>><<<E>>><<<j>>><<<M>>><<<N>>><<<P>>><<<Q>>><<<t>>><<<u>>>