好的，我们开始进行专业的专利创造性评估分析。
**对比文件名称：** 2010-08-12_US2010202420A_发明申请_US20100202420A1 Methods and Systems for Scheduling Resources in a Telecommunication System
**目标专利名称：** 用于配置多个调度请求触发的方法和装置 (CN104170491B)
**本次调用的模型名称：** 深度思考模型 (如GPT-4或Claude等，具体根据实际调用情况，此处泛指)
以下是对比文件相对于目标专利权利要求的特征比对分析表格。
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 (中文翻译) | 公开性论述 |
| **技术特征A**：所述方法包括以下步骤：a.基于所述用户设备的多种业务的业务特性，为所述用户设备确定多个调度请求触发以及对应于所述多个调度请求触发中的每个调度请求触发的传输类型<br><br>**《隐含公开》** | **引用1 (段落[0040]):** 根据本发明的实施例，UE被配置为仅当满足某些预定义条件时才发送SR，例如，UE发送缓冲器内容与先前报告的内容或先前发送的内容相比发生的变化。例如，当数据到达UE的发送缓冲器并且该数据的优先级高于先前报告数据（或发送数据）的优先级时，可以满足预定义条件。触发SR的缓冲器状态变化通常通过无线资源控制（RRC）信令进行配置。<br><br>**引用2 (段落[0042]):** 在一些实施例中，仅当满足以下一个或多个条件时，才认为缓冲器状态已“改变”：(1) 更高优先级的数据已到达缓冲器；(2) 缓冲器大小增加超过预定阈值（阈值A）；或(3) 自上次SR发送以来经过的时间超过预定阈值（阈值B）。阈值A和B通常可以通过RRC信令进行配置。 | 对比文件没有明确公开“基于多种业务的业务特性”来“确定**多个**调度请求触发”。其核心思想是基于缓冲器状态的变化（如高优先级数据到达）来触发一个单一的SR，而不是为不同业务预先配置多个不同的SR触发。然而，对比文件在段落[0040]和[0042]中，明确公开了SR的触发是基于数据的优先级（一种业务特性）以及缓冲器状态的变化。这表明，对比文件隐含地认可了不同优先级（对应不同业务特性）的数据会导致不同的触发行为。本领域技术人员可以合理推断，为了支持这种基于优先级的变化触发，基站侧需要为UE隐式地配置一个“高优先级数据触发”和一个“低优先级数据触发”（或基于计时器/数据量的触发），这实质上对应于为不同业务特性（隐含不同的优先级）确定了不同的SR触发条件。虽然对比文件未明确提及“多个调度请求触发”这个概念，但其基于优先级区分的触发机制，在逻辑上必然导致多个触发条件的共存，从而隐含公开了基于业务特性确定多个SR触发的思想。至于传输类型，对比文件在段落[0007]中公开了两种传输类型：专用SR信道和同步RACH，但并未明确说明如何为不同的调度请求触发分配不同的传输类型，因此该部分未被公开。 |
| **技术特征B**：b.将所述多个调度请求触发的配置信息发送至所述用户设备<br><br>**《隐含公开》** | **引用1 (段落[0040]):** 触发SR的缓冲器状态变化通常通过无线资源控制（RRC）信令进行配置。<br><br>**引用2 (段落[0042]):** 阈值A和B通常可以通过RRC信令进行配置。 | 对比文件明确公开了通过RRC信令将SR触发条件（如阈值、优先级变化等）的配置信息发送给UE。虽然这些信息是针对SR的触发条件而不是“多个调度请求触发”的配置，但如前所述，这些触发条件隐含地对应于不同的“调度请求触发”。因此，将包含这些触发条件的配置信息（即多个SR触发的配置信息）发送给UE，是本领域技术人员根据对比文件教导可以合理推断出的步骤。 |
| **技术特征C**：其中所述多个调度请求触发的所述配置信息包括所述多个调度请求触发相对于所述用户设备的多种业务的映射方式以及对应于所述多个调度请求触发中的每个调度请求触发的传输类型<br><br>**《未公开》** | 未明确公开。 | 对比文件未公开配置信息中包含“映射方式”和“传输类型”。对比文件公开的配置信息是触发SR的阈值和条件（如优先级变化），并未提及如何将某个SR触发映射到某种业务，也没有公开为不同的SR触发配置不同的传输类型（如哪个触发走RACH，哪个走D-SR）。这是对比文件与目标专利的核心区别之一。 |
| **技术特征D**：其中所述多个调度请求触发中的每个调度请求触发的传输类型是基于对应于该调度请求触发的业务的优先级确定的<br><br>**《未公开》** | 未明确公开。 | 对比文件虽然根据优先级确定是否触发SR，但并未公开根据业务的优先级来确定对应于该业务的SR触发的**传输类型**。对比文件中的传输类型（D-SR或RACH）是UE的一种通用配置或备用方案，而非与特定优先级业务绑定的、由基站确定的配置。 |
| **技术特征E**：并且其中所述传输类型是下列任一种：-在RACH上传输<br><br>**《直接公开》** | **段落[0007]:** 或者，同步随机接入信道（RACH）可用于相同目的（即发送调度请求）。<br><br>**段落[0009]:** 同步UE也有机会使用随机接入信道（RACH）作为备用方案来请求UL资源。 | 对比文件在段落[0007]和[0009]中明确公开了将RACH作为传输调度请求的一种方式。 |
| **技术特征F**：-在专用调度请求资源上传输；并且中当所述传输类型为在RACH上传输时，所述传输类型包括RACH配置且所述RACH配置包括PRACH的物理资源<br><br>**《隐含公开》** | **段落[0007]:** 为了告知上行链路（UL）调度器UE的瞬时业务需求，系统支持（i）专用调度请求（SR）信道和（ii）缓冲器状态报告。<br><br>**段落[0009]:** 在专用SR信道方法中，每个活动UE被分配一个专用信道，用于发送指示UE需要UL资源的消息。 | 对比文件在段落[0007]公开了“专用调度请求信道”，在段落[0009]进一步解释了其作为“专用信道”的用途，这实质上等同于在专用调度请求资源上传输。对于RACH配置，虽然对比文件没有列出具体的RACH配置参数（如PRACH的物理资源），但RACH的使用必然涉及物理资源配置，这是通信领域的公知常识。本领域技术人员可以合理推断，当选择RACH作为传输类型时，其配置必然包括PRACH的物理资源（如时频资源、前导码等），因此该特征被隐含公开。 |
| **技术特征G**：其特征在于，所述用户设备的多种业务的业务特性通过以下任一种方式表征：-所述用户设备的承载的QoS<br><br>**《隐含公开》** | **段落[0036]:** UE2使用分配的资源发送包含QoS信息的缓冲器状态报告和一些数据（取决于分配的大小）。<br><br>**段落[0067]:** 本发明实施例的一个优点是，即使使用单比特SR，基站中的调度器也能获得终端缓冲器状态和适当的服务质量（QoS）知识的选择性更新。 | 对比文件在段落[0036]和[0067]中明确提到了“QoS信息”和“服务质量（QoS）知识”。QoS（服务质量）是承载级（bearer-level）的属性，直接反映了承载的业务特性。因此，对比文件隐含公开了通过用户设备的承载的QoS来表征业务特性。 |
| **技术特征H**：-逻辑信道的分组<br><br>**《未公开》** | 未明确公开。 | 对比文件全文未提及“逻辑信道分组”这一概念。 |
| **技术特征I**：-缓存状态报告的不同类型<br><br>**《未公开》** | 未明确公开。 | 对比文件虽然广泛使用了BSR，但仅将其作为携带QoS信息的一种通用报告，并未公开存在“不同类型的BSR”并以此作为划分业务特性的依据。 |
| **技术特征J**：-运行的应用的特性<br><br>**《隐含公开》** | **段落[0036]:** 为了本示例的目的，我们假设UE2的数据优先级低于UE1的数据优先级。<br><br>**段落[0042]:** (1) 更高优先级的数据已到达缓冲器。 | 对比文件中反复提及数据的“优先级”，而数据的优先级通常是由运行的应用的特性所决定的（例如，实时语音的优先级高于后台下载任务）。因此，通过判断数据优先级来触发SR，间接地应用了“运行的应用的特性”来表征业务。本领域技术人员可以合理推断，优先级是应用特性的一个关键体现。 |
| **技术特征K**：其特征在于，当所述用户设备的一种业务是由后台应用程序产生的业务时，对应于所述后台应用程序产生的业务的调度请求触发被配置为在具有较长周期的专用调度请求资源上传输，而所述多个调度请求触发中的其余调度请求触发被配置为在具有不同RACH配置的RACH上传输<br><br>**《未公开》** | 未明确公开。 | 对比文件没有公开将“后台业务”的SR触发配置在具有较长周期的D-SR上，而其他业务的SR触发配置在RACH上这种具体的、差异化的配置方案。对比文件虽然提到了D-SR和RACH两种方式，但并未将它们与特定的业务类型（如后台业务）进行绑定，也未描述这种混合配置的场景。 |
| **技术特征L**：其特征在于，当所述用户设备的一种业务是由后台应用程序产生的业务时，所有的所述多个调度请求触发被配置为在具有不同RACH配置的RACH上传输<br><br>**《未公开》** | 未明确公开。 | 对比文件没有公开将所有SR触发都配置在RACH上，并且使用不同的RACH配置。对比文件将RACH描述为D-SR的备用方案，主要用于非同步UE。虽然提到了RACH配置，但没有公开为不同业务特性的SR触发配置不同RACH参数（如不同周期、不同前导码组）的方案。 |
| **技术特征M**：其特征在于，分配给PRACH的物理资源包括以下任一种：-RACH的时间资源和周期<br><br>**《未公开》** | 未明确公开。 | 对比文件在段落[0007]提到“同步随机接入信道（RACH）”，但未进一步描述RACH的物理资源配置细节，如时间资源、周期等。这些是RACH的基本参数，但对比文件未将其作为与SR触发相关的配置选项进行公开。 |
| **技术特征N**：-RACH的前导码的组<br><br>**《未公开》** | 未明确公开。 | 对比文件未提及RACH前导码的组划分。 |
| **技术特征O**：其特征在于，所述配置信息通过专用RRC信令或者广播信令发送<br><br>**《隐含公开》** | **段落[0040]:** 触发SR的缓冲器状态变化通常通过无线资源控制（RRC）信令进行配置。 | 对比文件明确公开了通过RRC信令进行配置。“专用RRC信令”是RRC信令的一种常见形式，通常用于UE特定配置。虽然未提及“广播信令”，但通过专用RRC信令发送配置信息已经被明确公开。 |
| **技术特征P**：其特征在于，所述用户设备为RRC连接的用户设备<br><br>**《隐含公开》** | **段落[0007]:** 同步随机接入信道（RACH）可以用于相同目的。<br><br>**段落[0009]:** 同步UE也有机会使用随机接入信道（RACH）作为备用方案来请求UL资源。 | 对比文件在段落[0007]和[0009]中多次提到“同步UE”（synchronized UE）。在LTE中，处于RRC连接状态的UE才能与网络保持上行同步。因此，对比文件中描述的、能够使用D-SR或同步RACH发送SR的UE，必然处于RRC连接状态。该特征被隐含公开。 |
| **技术特征Q**：其特征在于，所述通信系统为LTE通信系统<br><br>**《直接公开》** | **段落[0002]:** 目前，正在3GPP标准化组织内开发第三代（3G）系统的进一步演进，即3G长期演进（LTE）。<br><br>**段落[0003]:** LTE系统的主要目标是提供灵活的接入技术。 | 对比文件的背景技术部分（段落[0002]-[0003]）明确将本发明定位于LTE系统，并描述了LTE系统的目标和特点。因此，该技术特征被直接公开。 |
| **技术特征R**：所述方法包括以下步骤：i.从所述基站接收与多个调度请求触发相关的配置信息，其中所述配置信息包括所述多个调度请求触发相对于所述用户设备的多种业务的映射方式以及对应于所述多个调度请求触发中的每个调度请求触发的传输类型，其中所述多个调度请求触发中的每个调度请求触发的传输类型是基于对应于该调度请求触发的业务的优先级确定的，并且其中所述传输类型是下列任一种：-在RACH上传输<br><br>**《隐含公开》** | **引用1 (段落[0040]):** 触发SR的缓冲器状态变化通常通过无线资源控制（RRC）信令进行配置。<br><br>**引用2 (段落[0007]):** 或者，同步随机接入信道（RACH）可用于相同目的（即发送调度请求）。 | 该特征为UE侧接收配置信息。对比文件段落[0040]公开了UE通过RRC信令接收SR触发配置。结合对特征A、B、C的分析，虽然对比文件未公开“映射方式”和“为不同触发分配不同传输类型”，但UE接收由基站发送的SR配置信息这一步骤被隐含公开。关于传输类型为RACH，在段落[0007]被直接公开。 |
| **技术特征S**：-在专用调度请求资源上传输；并且中当所述传输类型为在RACH上传输时，所述传输类型包括RACH配置且所述RACH配置包括PRACH的物理资源<br><br>**《隐含公开》** | **段落[0007]:** 系统支持（i）专用调度请求（SR）信道和（ii）缓冲器状态报告。 | 与特征F的分析一致，对比文件公开了D-SR信道（在专用调度请求资源上传输）和RACH，并且RACH的使用必然隐含其物理资源配置。 |
| **技术特征T**：其特征在于，所述方法还包括以下步骤：ii.基于当前业务的业务特性以及所述映射方式，选择对应于所述当前业务的调度请求触发<br><br>**《未公开》** | 未明确公开。 | 对比文件未公开“映射方式”这一概念。UE是根据预定义的触发条件（如高优先级数据到达）来决定是否发送SR，而不是基于一个预配置的“映射表”来选择一个特定的SR触发。这是本质区别。 |
| **技术特征U**：iii.通过对应于所述调度请求触发的传输类型，传输所触发的调度请求<br><br>**《隐含公开》** | **段落[0035]:** 当数据到达UE1的发送缓冲器时，UE1通过其下一个SR机会向调度器发送SR。<br><br>**段落[0007]:** 为了告知上行链路调度器UE的瞬时业务需求，系统支持（i）专用调度请求（SR）信道和（ii）缓冲器状态报告。或者，同步随机接入信道（RACH）可用于相同目的。 | 对比文件描述了UE通过SR机会发送SR的行为。该SR机会由基站配置，隐含地对应了一种传输类型（D-SR信道或RACH机会）。因此，UE通过基站为其配置的传输类型（无论是D-SR还是RACH）来发送SR，这一基本行为被隐含公开。 |
| **技术特征V**：所述装置包括：第一单元，用于基于所述用户设备的多种业务的业务特性，为所述用户设备确定多个调度请求触发以及对应于所述多个调度请求触发中的每个调度请求触发的传输类型<br><br>**《隐含公开》** | **段落[0006]:** 参考图2，演进NodeB（基站）中的调度器可以执行资源分配。调度器202监测每个UE的业务需求并相应地分配资源。<br><br>**段落[0040]:** 触发SR的缓冲器状态变化通常通过无线资源控制（RRC）信令进行配置。 | 对比文件描述了基站（eNodeB）中的调度器负责资源分配和配置SR触发条件。虽然对比文件中的调度器是为UE配置一个统一的、基于变化的SR触发，但“为UE确定SR触发条件”这一功能是由基站中的单元（如调度器）执行的。该单元可被视为“确定单元”。基于对特征A的隐含公开分析，该单元的功能被隐含公开，尽管其具体实现方式（确定多个触发及其传输类型）与目标专利不完全相同。 |
| **技术特征W**：第二单元，用于将所述多个调度请求触发的配置信息发送至所述用户设备，其中所述多个调度请求触发的所述配置信息包括所述多个调度请求触发相对于所述用户设备的多种业务的映射方式以及对应于所述多个调度请求触发中的每个调度请求触发的传输类型，其中所述多个调度请求触发中的每个调度请求触发的传输类型是基于对应于该调度请求触发的业务的优先级确定的，并且其中所述传输类型是下列任一种：-在RACH上传输<br><br>**《隐含公开》** | **段落[0040]:** 触发SR的缓冲器状态变化通常通过无线资源控制（RRC）信令进行配置。 | 对比文件公开了基站通过RRC信令发送配置信息的功能，该功能可由一个“发送单元”或通信接口实现。基于对特征B、C、D、E的分析，该发送单元发送配置信息这一基本功能被隐含公开。 |
| **技术特征X**：-在专用调度请求资源上传输；并且中当所述传输类型为在RACH上传输时，所述传输类型包括RACH配置且所述RACH配置包括PRACH的物理资源<br><br>**《隐含公开》** | **段落[0007]:** 系统支持（i）专用调度请求（SR）信道和（ii）缓冲器状态报告。或者，同步随机接入信道（RACH）可用于相同目的。 | 与特征F和S的分析一致，对比文件公开了D-SR信道和RACH，并且RACH的使用必然隐含其物理资源配置。 |
### 结论与代码输出
根据以上严谨的分析，对比文件直接公开了技术特征E和Q。对比文件隐含公开了技术特征A、B、F、G、J、O、P、R、S、U、V、W、X。
<<<E>>><<<Q>>><<<a>>><<<b>>><<<f>>><<<g>>><<<j>>><<<o>>><<<p>>><<<r>>><<<s>>><<<u>>><<<v>>><<<w>>><<<x>>>