对比文件名称：WO2009074103A1_Description_20260428_0948
目标专利名称：1154多媒体通信服务处理CN105612730B
本次调用的模型名称：GPT-4o
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| 技术特征A：所述方法由所述UE执行，包括以下步骤 **《直接公开》** | 全文视角，例如“UE-A通过第一电路域接入呼叫支路...”、“UE-A通过ICCC发送挂起当前呼叫请求到ICCF。”、“UE-A发送呼叫UE-C请求到ICCF。” | 对比文件通篇以UE-A作为执行主体，描述了其在呼叫保持过程中的具体操作步骤，例如发送挂起请求、发送新呼叫请求、进行CS媒体变更等。本领域技术人员可以毫无疑义地确定该方法是由UE执行的。 |
| 技术特征B：经由第一用户接口应用处理(S102)进行中的多媒体通信服务 **《隐含公开》** | “UE-A通过第一电路域接入呼叫支路CS access call leg和UE-B进行语音呼叫通话”；“UE-A的呼叫保持应用程序” | 对比文件公开了UE-A正在处理一个进行中的呼叫（第一呼叫）。UE进行呼叫处理必然通过其内部的电话应用或呼叫保持应用（即用户接口应用）来实现。虽然未明确使用“第一用户接口应用”的措辞，但该功能隐含在常规的呼叫处理过程中。 |
| 技术特征C：在所述处理期间，接收(S104)建立其它多媒体通信服务的请求 **《直接公开》** | “UE-A发送呼叫UE-C请求到ICCF”（步骤3）；“UE-A向VMSC网络发送CS呼叫模式变更请求”（步骤7） | 在进行中的呼叫期间，对比文件明确公开了UE发起（接收自用户或内部应用的指令）建立第二呼叫的请求。UE接收该请求并据此向网络侧发送信令。 |
| 技术特征D：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务需要访问UE中一次只能够服务于一个进行中的多媒体通信服务的资源 **《直接公开》** | “为了实现UE的呼叫保持（call hold）,即UE在一个进行呼叫基础上，可以将当前呼叫hold,再建立一个新的呼叫” | 呼叫保持（Call Hold）的核心前提就是UE的受限资源（如CS接入链路、用户通话接口）一次只能服务于一个激活的呼叫。将当前呼叫保持是建立新呼叫的必要条件，这直接揭示了资源的一次性服务特性。 |
| 技术特征E：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务通过操作系统来保持独立 **《无》** | 未记载 | 对比文件未涉及UE操作系统对应用的隔离，也未将“应用独立”作为需要解决的问题。其协调机制主要是UE内部的呼叫保持应用与网络侧ICCF配合完成，而非通过操作系统隔离后的IMS服务管理器协调。 |
| 技术特征F：通过IMS服务管理器(21n)来协调(S106)所述进行中的多媒体通信服务和所述其它多媒体通信服务的处理 **《无》** | 未记载 | 对比文件中的协调主体是网络侧的ICCF实体和UE侧的“呼叫保持应用程序”，并未在UE内设置一个独立的“IMS服务管理器(21n)”模块来专门负责协调不同应用之间的多媒体通信服务。 |
| 技术特征G：其中协调包括向用于处理所述其它多媒体通信服务的应用通知所述建立其它多媒体通信服务的请求 **《无》** | 未记载 | 对比文件中，处理新呼叫的应用（呼叫保持应用）自身即为发起请求的主体，而不是被动接收来自管理器的“通知”。不存在“管理器通知应用”的流程。 |
| 技术特征H：其中所述用于处理所述其它多媒体通信服务的应用包括其它用户接口应用 **《隐含公开》** | “UE-A的呼叫保持应用程序”；“UE-A通过第二CS access call leg和UE-C进行第二呼叫通话” | 对比文件公开了由“呼叫保持应用程序”来处理第二呼叫的建立和通话过程。该应用必然具有用户界面功能，以供用户进行操作（如接受、挂断），因此隐含公开了其包括用户接口应用。 |
| 技术特征I：并且中所述方法还包括：所述用于处理所述其它多媒体通信服务的应用通过启动其它用户接口应用并且使用所述其它用户接口应用获取用户指令来响应所述通知... **《无》** | 未记载 | 对比文件没有描述“启动其它用户接口应用”来获取指令的流程。指令获取是呼叫保持应用自身的功能，无需通过“启动”一个新应用来实现。 |
| 技术特征J：还包括响应于所获得的指示应当接受所述建立其它多媒体通信服务的请求的用户指令而接受所述其它多媒体通信服务 **《直接公开》** | “UE-C指示用户应答呼叫，发送200OK到ICCF”；“ICCF通过ICCC指示呼叫被应答” | 对比文件公开了用户在应答新呼叫后，网络侧返回成功响应，标志着UE接受了建立其他多媒体通信服务的请求。 |
| 技术特征K：其中，接受所述其它多媒体通信服务包括：发起(S108a)所述进行中的多媒体通信服务的暂停过程 **《直接公开》** | “UE-A通过ICCC发送挂起当前呼叫请求到ICCF”；“ICCF发送呼叫挂起请求到UE-B” | 接受新呼叫的前提是暂停（挂起）当前进行中的通话，对比文件对此步骤有明确且详细的公开。 |
| 技术特征L：激活(S108b)所述其它多媒体通信服务 **《直接公开》** | “UE-A通过第二CS access call leg和UE-C进行第二呼叫通话” | 在暂停第一呼叫后，对比文件公开了UE-A与UE-C建立第二呼叫并进行通话，即激活了其他多媒体通信服务。 |
| 技术特征M：还包括响应于所获得的指示应当拒绝所述建立其它多媒体通信服务的请求的用户指令而拒绝所述其它多媒体通信服务 **《无》** | 未记载 | 对比文件仅描述了成功进行呼叫保持和建立新呼叫的流程，未涉及用户拒绝建立新呼叫的场景。 |
| 技术特征N：其中，拒绝所述其它多媒体通信服务包括：继续进行(S110a)所述进行中的多媒体通信服务 **《无》** | 未记载 | 同上，拒绝场景未公开。 |
| 技术特征O：拒绝(S110b)接受所述其它多媒体通信服务 **《无》** | 未记载 | 同上，拒绝场景未公开。 |
| 技术特征P：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务中的一个是用于在所述UE上执行第一多媒体类型的多媒体服务的默认应用(24) **《无》** | 未记载 | 对比文件未对“默认应用”和“非默认应用”进行区分。 |
| 技术特征Q：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务二者是用于在所述UE上执行第一多媒体类型的多媒体服务的非默认应用(25a、25b) **《无》** | 未记载 | 对比文件未对“默认应用”和“非默认应用”进行区分。 |
| 技术特征R：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务使用所述UE的默认因特网协议多媒体子系统“IMS”通信服务 **《直接公开》** | “在互联网协议多媒体子系统（IMS）集中业务控制下”；“CS承载通过建立UE和新引入的CS接入IMS控制功能（ICCF）实体之间的CS呼叫来实现” | 对比文件的技术方案明确立足于IMS集中业务控制（ICS）架构。第一呼叫和第二呼叫均为IMS呼叫，必然使用UE的默认IMS通信服务（如MMTel）。 |
| 技术特征S：其中，所述默认IMS通信服务负责传送应用命令和所述第一多媒体类型的多媒体通信服务的数据 **《隐含公开》** | “实现UE通过CS网络承载语音或视频媒体来建立IMS呼叫，由IMS中的应用服务器对呼叫进行业务提供” | 在ICS架构下，IMS核心网及其中应用服务器负责业务的提供和媒体数据的传送。默认IMS通信服务作为底层承载，隐含公开了其传送数据和命令的作用。 |
| 技术特征T：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务中的至少一个与IMS应用参考标识符“IARI”相关联 **《无》** | 未记载 | 对比文件未涉及IMS应用参考标识符（IARI）。其通过媒体类型（语音/视频）和CS接入来区分呼叫，而非通过IARI来标识UE内的具体应用。 |
<<<A>>>>><<<b>>>>><<<C>>>>><<<D>>>>><<<h>>>>><<<J>>>>><<<K>>>>><<<L>>>>><<<R>>>>><<<s>>>