好的，作为一名资深专利代理师，我将严格遵循您的要求，对对比文件 JPWO2011099150A1 相对于目标专利 CN104170491B 的各个技术特征进行严谨的公开性评估。
本次分析使用的模型名称为：专利审查推理模型
### 特征比对表格
| 技术特征描述及公开性判断 | 对比文件原文引用（翻译） | 公开性论述 |
| **技术特征A：** 所述方法包括以下步骤：a.基于所述用户设备的多种业务的业务特性，为所述用户设备确定多个调度请求触发以及对应于所述多个调度请求触发中的每个调度请求触发的传输类型 | **未公开** | 对比文件公开了UE根据“发送的数据类型”（例如是否为RRC消息）或“可用无线资源的类型”（CB资源、PUCCH资源）来选择多种上行接入方法（随机接入、调度请求、竞争型上行接入）中的一种。然而，该选择是在UE侧基于数据特性和可用资源做出的，并非由基站（eNB）基于“多种业务的业务特性”来主动“确定多个调度请求触发”。对比文件中，基站虽然配置了资源，但并未基于业务特性为UE确定多个不同的SR触发及其对应的传输类型。对比文件的核心在于UE如何选择不同的发送机制，而非基站如何配置多个SR触发。 |
| **技术特征B：** b.将所述多个调度请求触发的配置信息发送至所述用户设备 | **未公开** | 对比文件中，基站（无线通信装置1）会向移动台（无线通信装置2）发送“CB-RNTI”、“CB送信许可”（CB grant）或“PUCCH的无线资源”等信息，这些属于无线资源的配置信息。但是，这些信息并非用于“多个调度请求触发”的配置，而是用于指示移动台可以使用哪种上行接入机制。对比文件没有公开将“多个调度请求触发”的配置信息（如映射方式、传输类型）发送给UE。 |
| **技术特征C：** 其中所述多个调度请求触发的所述配置信息包括所述多个调度请求触发相对于所述用户设备的多种业务的映射方式以及对应于所述多个调度请求触发中的每个调度请求触发的传输类型 | **未公开** | 对比文件公开了移动台可以根据“发送数据的种类”（例如RRC消息）来选择接入方式，这隐含了数据类型与接入方式之间的关联。然而，这并非基站配置的“多个调度请求触发相对于多种业务的映射方式”。对比文件未公开基站侧将“映射方式”作为配置信息的一部分发送给UE。对比文件中的UE是基于自身判断选择接入方式，而非基于基站配置的映射表。 |
| **技术特征D：** 其中所述多个调度请求触发中的每个调度请求触发的传输类型是基于对应于该调度请求触发的业务的优先级确定的 | **未公开** | 对比文件在第4实施方式中公开了根据数据类型（如RRC消息）选择接入方式。虽然RRC消息通常具有高优先级，但这并非直接基于“业务的优先级”来确定传输类型。对比文件未明确提及基于优先级来确定传输类型（例如，高优先级业务使用D-SR，低优先级业务使用RACH）。对比文件更侧重于避免接入过程冲突，而非区分业务优先级。 |
| **技术特征E：** 并且其中所述传输类型是下列任一种：-在RACH上传输 | **直接公开** | 对比文件大量公开了通过RACH（PRACH）进行传输的方案，例如[0034]-[0038]描述了随机接入过程，[0035]明确提到“物理随机接入信道（PRACH）”。这完全属于在RACH上传输。 |
| **技术特征F：** -在专用调度请求资源上传输；并且中当所述传输类型为在RACH上传输时，所述传输类型包括RACH配置且所述RACH配置包括PRACH的物理资源。 | **直接公开** | 对比文件明确公开了专用调度请求资源（D-SR）和RACH传输。 [0040]描述了基站为移动台分配用于发送调度请求的“上行链路物理控制信道（PUCCH）”资源，这即专用调度请求资源。 [0034]-[0035]描述了在PRACH上发送随机接入前导码，PRACH即物理随机接入信道，属于PRACH的物理资源。这两部分内容被直接公开。 |
| **技术特征G：** 其特征在于，所述用户设备的多种业务的业务特性通过以下任一种方式表征：-所述用户设备的承载的QoS | **未公开** | 对比文件没有提及“承载的QoS”。其特征G-J所列举的业务特性表征方式（QoS，逻辑信道分组，BSR类型，应用特性）均未在对比文件中明确或隐含公开。对比文件仅提及“数据类型”（如RRC消息）作为选择接入方式的依据，但这与目标专利中基于多种业务特性来配置多个SR触发的概念完全不同。 |
| **技术特征H：** -逻辑信道的分组 | **未公开** | 对比文件没有提及“逻辑信道的分组”。 |
| **技术特征I：** -缓存状态报告的不同类型 | **未公开** | 对比文件在[0516]提到了BSR，但只是作为SR过程的一部分，并未提及将“不同的BSR类型”作为业务特性来配置多个SR。 |
| **技术特征J：** -运行的应用的特性。 | **未公开** | 对比文件没有提及“运行的应用的特性”。 |
| **技术特征K：** 其特征在于，当所述用户设备的一种业务是由后台应用程序产生的业务时，对应于所述后台应用程序产生的业务的调度请求触发被配置为在具有较长周期的专用调度请求资源上传输，而所述多个调度请求触发中的其余调度请求触发被配置为在具有不同RACH配置的RACH上传输。 | **未公开** | 对比文件未公开任何关于“后台应用程序产生的业务”的特定配置。对比文件虽然公开了不同接入方式（RACH, D-SR, CB），但并未将它们与“后台业务”或类似低优先级业务进行关联，也没有公开为不同业务配置不同周期的D-SR资源或不同的RACH配置。 |
| **技术特征L：** 其特征在于，当所述用户设备的一种业务是由后台应用程序产生的业务时，所有的所述多个调度请求触发被配置为在具有不同RACH配置的RACH上传输。 | **未公开** | 与特征K类似，对比文件未公开针对“后台应用程序产生的业务”的配置。 |
| **技术特征M：** 其特征在于，分配给PRACH的物理资源包括以下任一种：-RACH的时间资源和周期 | **直接公开** | 对比文件在[0042]提到“用于RS0传输的RACH配置具有较短的PRACH周期”，[0043]提到“RS0在其上传输的RACH的时间和/或频率资源以及周期”。虽然上下文不同，但对比文件明确公开了RACH配置可以包括“PRACH的周期”和“时间和/或频率资源”。这直接公开了RACH的时间资源和周期。 |
| **技术特征N：** -RACH的前导码的组。 | **直接公开** | 对比文件在[0043]提到“用于RS0传输的RACH配置可包括RACH中传输RS0的前导码的组；用于RS1传输的RACH配置可包括该RACH中传输RS1的前导码的组”。这直接公开了RACH配置包括“前导码的组”。 |
| **技术特征O：** 其特征在于，所述配置信息通过专用RRC信令或者广播信令发送。 | **隐含公开** | 对比文件[0062]提到“控制プレーン部２４は、ＲＲＣの処理を行う”，说明移动台支持RRC处理。虽然对比文件没有明确说配置信息是通过RRC信令发送的，但在LTE系统中，基站向UE发送无线资源配置信息，例如PUCCH资源、CB-RNTI等，通常是通过RRC专用信令或系统广播消息。本领域技术人员可以合理推断，这些配置信息是通过RRC信令或广播信令发送的。 |
| **技术特征P：** 其特征在于，所述用户设备为RRC连接的用户设备。 | **隐含公开** | 对比文件[0002]和全文描述的场景是UE需要从“休止状态”（Dormant state）恢复数据传输，这通常对应于RRC空闲态或非连续接收（DRX）状态。然而，要执行SR或RACH过程，UE必须处于RRC连接态。对比文件[0040]描述了基站为UE分配PUCCH资源，这仅在RRC连接态下进行。因此，本领域技术人员可以合理推断该UE是RRC连接的用户设备。 |
| **技术特征Q：** 其特征在于，所述通信系统为LTE通信系统。 | **直接公开** | 对比文件[0003]明确提到“ＬＴＥ（Long Term Evolution）と呼ばれる通信規格”，并在[0009]引用了大量LTE标准文档，[0028]提到“ＬＴＥ−Ａの移動通信システム”。因此，该通信系统为LTE/LTE-A系统被直接公开。 |
| **技术特征R：** 所述方法包括以下步骤：i.从所述基站接收与多个调度请求触发相关的配置信息，其中所述配置信息包括所述多个调度请求触发相对于所述用户设备的多种业务的映射方式以及对应于所述多个调度请求触发中的每个调度请求触发的传输类型，其中所述多个调度请求触发中的每个调度请求触发的传输类型是基于对应于该调度请求触发的业务的优先级确定的，并且其中所述传输类型是下列任一种：-在RACH上传输 | **未公开** | 与特征A、C、D的分析相同。对比文件中的UE从基站接收的是关于可用资源（PUCCH, CB资源）和许可（CB-RNTI）的信息，而非“多个调度请求触发的配置信息”，更没有“相对于多种业务的映射方式”和“基于业务优先级确定的传输类型”。虽然RACH作为传输类型被公开，但其上下文完全不同。 |
| **技术特征S：** -在专用调度请求资源上传输；并且中当所述传输类型为在RACH上传输时，所述传输类型包括RACH配置且所述RACH配置包括PRACH的物理资源。 | **部分公开** | 对比文件公开了“在专用调度请求资源上传输”（[0040]的PUCCH资源）和“在RACH上传输”（[0034]的PRACH）作为不同的接入方式。但并未将它们作为“多个调度请求触发”的配置信息的一部分。 |
| **技术特征T：** 其特征在于，所述方法还包括以下步骤：ii.基于当前业务的业务特性以及所述映射方式，选择对应于所述当前业务的调度请求触发 | **未公开** | 对比文件的UE是基于“可用资源”（Step S122）或“数据类型”（Step S313）来选择接入方式，而不是基于基站配置的“映射方式”来选择“对应的调度请求触发”。 |
| **技术特征U：** iii.通过对应于所述调度请求触发的传输类型，传输所触发的调度请求。 | **隐含公开** | 对比文件中，UE在选择了某个接入方式（例如SR或RACH）后，会通过对应的资源（PUCCH或PRACH）发送请求（SR或前导码）。例如[0041]的Step S22，UE通过PUCCH发送SR；[0034]的Step S11，UE通过PRACH发送前导码。这本质上就是“通过对应于所述调度请求触发的传输类型，传输所触发的调度请求”。虽然不涉及“多个SR触发”的配置，但该动作本身被隐含公开。 |
| **技术特征V：** 所述装置包括：第一单元，用于基于所述用户设备的多种业务的业务特性，为所述用户设备确定多个调度请求触发以及对应于所述多个调度请求触发中的每个调度请求触发的传输类型 | **未公开** | 与特征A的分析相同。对比文件中的基站（图6）的“リソース割当部１６”（资源分配部）和“制御部１４”（控制部）负责确定UE使用哪些资源（CB资源或PUCCH资源），但并非基于“多种业务的业务特性”来“确定多个调度请求触发”。 |
| **技术特征W：** 第二单元，用于将所述多个调度请求触发的配置信息发送至所述用户设备，其中所述多个调度请求触发的所述配置信息包括所述多个调度请求触发相对于所述用户设备的多种业务的映射方式以及对应于所述多个调度请求触发中的每个调度请求触发的传输类型，其中所述多个调度请求触发中的每个调度请求触发的传输类型是基于对应于该调度请求触发的业务的优先级确定的，并且其中所述传输类型是下列任一种：-在RACH上传输 | **未公开** | 与特征B、C、D、E的分析相同。对比文件中的基站通过“通知部１ｂ”（通知部）发送资源分配信息，但并非发送“多个调度请求触发的配置信息”。 |
| **技术特征X：** -在专用调度请求资源上传输；并且中当所述传输类型为在RACH上传输时，所述传输类型包括RACH配置且所述RACH配置包括PRACH的物理资源。 | **部分公开** | 与特征S的分析相同。基站会分配专用调度请求资源（PUCCH）和配置RACH资源（PRACH），但并非作为“多个调度请求触发”的配置信息。 |
### 公开性代码输出
基于以上分析，对比文件直接公开了技术特征E、F、M、N、Q。
对比文件隐含公开了技术特征O、P、U。
因此，结尾的代码为：
<<<E>>><<<F>>><<<M>>><<<N>>><<<Q>>><<<o>>><<<p>>><<<u>>>