## 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用（翻译） | 公开性论述 |
| **技术特征A**：用于一无线通讯系统的一用户端中，该方法包含有接收至少一多媒体广播及群播服务<br><br>**《直接公开》** | 对比文件[0023]：“When one of the UEs 10 powers up, it can receive the BCCH, read the MCCH configuration contained in the BCCH, and determine from the MCCH control information how to receive one or more MTCHs.”<br><br>翻译：当UE 10开机时，它可以接收BCCH，读取BCCH中包含的MCCH配置，并根据MCCH控制信息确定如何接收一个或多个MTCH。 | 对比文件明确描述了UE能够接收一个或多个MTCH（Multicast Traffic Channel），而MTCH正是用于传输多媒体广播及群播服务（MBMS）内容数据的逻辑信道。因此，本领域技术人员可以毫无疑义地确定，该方法步骤中的“接收至少一多媒体广播及群播服务”已被对比文件直接公开（通过接收MTCH实现）。 |
| **技术特征B**：于每个修改周期接收该至少一多媒体广播及群播服务的群播控制通道<br><br>**未公开** | 对比文件未记载“修改周期”或“每个修改周期接收群播控制通道”的相关内容。 | 对比文件仅提到UE在开机时读取MCCH配置，以及MCCH可承载P-MCCH和S-MCCH信息，但完全没有涉及修改周期（modification period）的概念，也未描述UE需要按照每个修改周期来重复读取MCCH。因此，该技术特征未被对比文件直接公开或隐含公开。 |
| **技术特征C**：选择所接收的表示兴趣的一新多媒体广播及群播服务<br><br>**未公开** | 对比文件未记载UE“选择新服务”或“表示兴趣”的相关内容。 | 对比文件主要关注网络侧的MBSFN与MCH映射、MCCH结构等，未描述UE如何通过上层指令或用户操作来表示对某个新MBMS的兴趣并选择该服务。因此，该特征未被公开。 |
| **技术特征D**：根据播送该新多媒体广播及播服务的一广播群播单频网络区域是否属于该用户端正在接收的该至少一多媒体广播及群播服务所在的至少一广播群播单频网络区域中的一个，确定是否监听一群播控制通道通知<br><br>**未公开** | 对比文件未记载“群播控制通道通知（MCCH notification）”或“根据MBSFN区域判断是否监听”的相关内容。 | 对比文件未提及MCCH通知机制，也未描述UE如何根据新服务所在的MBSFN区域是否与当前接收服务的MBSFN区域重叠来决定是否监听该通知。该特征体现的是UE侧基于MBSFN区域比较的监听决策，对比文件完全未涉及。 |
| **技术特征E**：当该新多媒体广播及群播服务所在的该广播群播单频网络区域不属于该至少一多媒体广播及群播服务所在的该至少一广播群播单频网络区域中的一个时，监听该群播控制通道通知<br><br>**未公开** | 对比文件未记载上述情况下的监听操作。 | 基于技术特征D未被公开，技术特征E作为其具体分支自然也未被对比文件公开。 |
| **技术特征F**：当该新多媒体广播及播服务所在的该广播群播单频网络区域属于该至少一多媒体广播及群播服务所在的该至少一广播群播单频网络区域中的一个时，不监听该群播控制通道通知<br><br>**未公开** | 对比文件未记载上述情况下的不监听操作。 | 基于技术特征D未被公开，技术特征F同样未被对比文件公开。 |
| **技术特征G**：其中播送一多媒体广播及群播服务的广播群播单频网络区域的信息是一网络端通过一无线资源控制层的上层传送至该用户端<br><br>**未公开** | 对比文件未记载网络端通过RRC上层传送MBSFN区域信息。 | 对比文件虽然提到了BCCH广播MCCH配置，以及UE通过BCCH获取信息，但未指明是“RRC层的上层”传送MBSFN区域信息，也未涉及服务通告等上层程序。因此，该特征未被公开。 |
| **技术特征H**：其中每一广播群播单频网络区域具有一群播控制通道<br><br>**《隐含公开》** | 对比文件[0030]：“In the case where multiple MTCHs (that is, multiple services) are multiplexed in the same MBSFN, the MTCHs can map to the same MCH. Also, in the case where the S-MCCH and one or more MTCHs are being transmitted in the same MBSFN, the S-MCCH and the MTCHs can map to the same MCH.”<br><br>翻译：在相同MBSFN内复用多个MTCH（即多个服务）的情况下，MTCH可映射到同一个MCH。同样，在S-MCCH和一个或多个MTCH在同一MBSFN内传输的情况下，S-MCCH和MTCH可映射到同一个MCH。<br><br>对比文件[0031]：“a first MCH would be used in the first MBSFN 420 and only in the first MBSFN 420, a second MCH would be used in the second MBSFN 430 and only in the second MBSFN 430, and a third MCH would be used in the third MBSFN 440 and only in the third MBSFN 440.”<br><br>翻译：第一MBSFN 420使用第一MCH且仅用于第一MBSFN 420，第二MBSFN 430使用第二MCH且仅用于第二MBSFN 430，第三MBSFN 440使用第三MCH且仅用于第三MBSFN 440。 | 对比文件明确指示每个MBSFN具有自己的MCH（多播传输信道），而MCH上承载着S-MCCH（Secondary MCCH，即群播控制通道的辅助部分）。结合本领域普通知识，S-MCCH是MBSFN区域特定的控制通道，用于提供该区域的服务控制信息。由此，本领域技术人员可以合理推断：每一广播群播单频网络区域（MBSFN）都拥有其对应的群播控制通道（至少包括S-MCCH）。因此，技术特征H被对比文件隐含公开。 |
| **技术特征I**：其中一广播群播单频网络区域的群播控制通道内容于同一修改周期内维持相同<br><br>**未公开** | 对比文件未记载“修改周期”或“同一修改周期内MCCH内容不变”的相关内容。 | 对比文件未引入修改周期的概念，也未描述MCCH内容是否在固定周期内保持不变。该特征来自LTE标准中关于MCCH修改周期的规定，对比文件未涉及。 |
| **技术特征J**：其中该群播控制通道通知是于指定给多媒体广播及群播服务无线网络暂时识别的实体下链路控制通道上传输<br><br>**未公开** | 对比文件未记载“群播控制通道通知”或“M-RNTI”或“PDCCH”等相关内容。 | 对比文件通篇未提及MCCH通知机制，也未描述通过M-RNTI加扰的PDCCH传输通知。该特征显然未被公开。 |
| **技术特征K**：其中该群播控制通道通知的传输时机是依据传呼时机<br><br>**未公开** | 对比文件未记载“传呼时机”或“paging occasion”与MCCH通知的关联。 | 对比文件中没有出现任何关于群播控制通道通知的内容，更未涉及其传输时机的确定方式。该特征未被公开。 |
| **技术特征L**：其中该群播控制通道通知的传输时机是依据特殊多媒体广播及群播服务无线网络暂时识别时机<br><br>**未公开** | 对比文件未记载“特殊M-RNTI时机”相关内容。 | 同技术特征J、K，对比文件未公开群播控制通道通知的任何细节，因此该特征未被公开。 |
| **技术特征M**：其还包含于接收该群播控制通道通知后，在下一修改周期读取相对应的一群播控制通道<br><br>**未公开** | 对比文件未记载“群播控制通道通知”或“下一修改周期读取MCCH”等内容。 | 对比文件未提及MCCH通知及其后续读取操作，也未涉及修改周期的概念，因此该特征未被公开。 |
| **技术特征N**：其中该播送一多媒体广播及群播服务的广播群播单频网络区域的信息是该网络端经由一服务通告程序所传送<br><br>**未公开** | 对比文件未记载“服务通告程序（Service announcement procedure）”相关内容。 | 对比文件未描述网络端如何向UE传送MBSFN区域信息的具体方式，尤其是未提及服务通告程序。虽然BCCH可能广播部分信息，但未明确为服务通告程序，因此该特征未被公开。 |
---
**代码插入**：
基于以上判断，对比文件直接公开了技术特征A，隐含公开了技术特征H。
<<<A>>><<<h>>>