好的，作为一名经验丰富的资深专利代理师，我将对您提供的对比文件和目标专利权利要求进行严谨的公开性评估。
**对比文件名称**：2010-09-22_EP2230814A_发明公开_EP2230814A1 METHOD AND DEVICE FOR REALIZING THE CALL HOLD
**目标专利名称**：1154多媒体通信服务处理CN105612730B
**本次调用的模型名称**：X-UNKNOWN (由于您未提供，此处以X-UNKNOWN代替)
### 特征比对表格
| 技术特征描述及公开性判断 | 对比文件原文引用 (中文翻译) | 公开性论述 |
| **技术特征A**：所述方法由所述UE执行，包括以下步骤 <br> **《直接公开》** | **段落 [0018]**：用户设备A (UE-A) 和用户设备B (UE-B) 通过第一CS接入呼叫支路执行语音呼叫。... 1. 通过ICCC，UE-A向ICCF发送保持当前呼叫的请求。... 3. UE-A向ICCF发送呼叫UE-C的请求。<br><br>**段落 [0034]**：一种用于保持呼叫的UE，所述UE包括：... | 对比文件明确记载了由UE（如UE-A）执行一系列步骤以实现呼叫保持。例如，UE-A发送保持请求、发送呼叫请求等。这与本技术特征描述的“所述方法由所述UE执行”完全一致，因此被直接公开。 |
| **技术特征B**：经由第一用户接口应用处理(S102)进行中的多媒体通信服务 <br> **《未公开》** | **段落 [0018]**：UE-A和UE-B通过第一CS接入呼叫支路执行语音呼叫。第一CS接入呼叫支路建立于UE-A和ICCF之间。信令端点是ICCF，媒体流端点是MGCF。<br><br>**段落 [0034]**：第一呼叫执行单元，用于通过第一CS接入呼叫支路与第二UE执行第一呼叫。 | 对比文件描述了UE-A通过“第一CS接入呼叫支路”处理第一呼叫（语音呼叫）。虽然该呼叫是多媒体通信服务，但其实现方式是基于CS域的网络连接，并由ICCF等网元控制，而非通过UE本地的“第一用户接口应用”进行处理。对比文件未提及任何关于“用户接口应用”的概念，也未涉及应用层对媒体资源的管理。因此，该技术特征未被公开。 |
| **技术特征C**：在所述处理期间，接收(S104)建立其它多媒体通信服务的请求 <br> **《未公开》** | **段落 [0018]**：3. UE-A向ICCF发送呼叫UE-C的请求。 | 在对比文件中，是UE-A主动向网络侧（ICCF）发送建立新呼叫的请求，而不是在处理进行中通信服务时，从外部（网络或用户）接收建立其它服务的请求。对比文件的场景是UE主动发起呼叫保持和新呼叫建立，与目标专利中被动“接收”请求的场景不符。因此，该技术特征未被公开。 |
| **技术特征D**：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务需要访问UE中一次只能够服务于一个进行中的多媒体通信服务的资源 <br> **《隐含公开》** | **段落 [0004]**：呼叫保持意味着UE保持当前呼叫并同时建立新呼叫。<br><br>**段落 [0018]**：UE-A和UE-B执行语音呼叫...步骤1至12描述了建立第二个呼叫并保持第一个呼叫的流程。 | 对比文件的发明名称和核心内容即为“呼叫保持”，其本质就是在处理一个呼叫（第一呼叫）时，建立另一个呼叫（第二呼叫），并暂时搁置或保持第一个呼叫。这种场景隐含地表明，这两个呼叫都需要访问UE的资源（如CS域连接、音频处理等），而这些资源一次只能服务于一个激活的呼叫，否则无需“保持”操作。虽然没有明确指出资源的具体类型（如麦克风、扬声器），但其技术方案的实质就是为了解决资源冲突问题。因此，该技术特征被隐含公开。 |
| **技术特征E**：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务通过操作系统来保持独立 <br> **《未公开》** | **段落 [0017]-[0038]**：通篇描述了UE-A、ICCF、MGCF、MGW等网络实体之间的信令交互流程，以管理CS接入呼叫支路的建立、释放和更改。 | 对比文件的技术方案完全基于网络侧的呼叫控制和CS域连接管理，没有涉及UE操作系统层面的任何内容。它既不讨论操作系统如何管理应用，也未提及应用之间的隔离性或独立性。该特征描述了UE内部的一种特定架构，在对比文件中完全没有对应内容。因此，该技术特征未被公开。 |
| **技术特征F**：通过IMS服务管理器(21n)来协调(S106)所述进行中的多媒体通信服务和所述其它多媒体通信服务的处理 <br> **《未公开》** | **段落 [0006]-[0015]**：描述了ICCF（IMS CS控制功能）在呼叫保持过程中的核心作用。ICCF负责接收来自UE的ICCC请求，发送呼叫保持请求，并与MGCF、UE-B、UE-C等实体交互。<br><br>**段落 [0028]-[0033]**：描述了控制设备（可集成于ICCF）的单元，如保持单元、接收单元、控制单元。 | 对比文件中负责协调两个呼叫处理的核心实体是“ICCF”（IMS CS控制功能），这是一个网络侧的网元。而目标专利中的“IMS服务管理器”是位于UE内部的一个模块。两者的功能类似（协调多媒体通信服务），但所处的位置和角色完全不同。对比文件没有公开任何关于UE内部存在一个“IMS服务管理器”来协调应用层服务的信息。因此，该技术特征未被公开。 |
| **技术特征G**：其中协调包括向用于处理所述其它多媒体通信服务的应用通知所述建立其它多媒体通信服务的请求 <br> **《未公开》** | **段落 [0018]**：步骤7-10描述了UE-A发起改变CS呼叫模式的过程，涉及VMSC和MGCF。步骤11-12描述了ICCF指示呼叫被应答。 | 对比文件中的信令交互主要在UE-A和网络侧（ICCF, VMSC, MGCF）之间进行。没有描述网络侧或UE内部向某个“应用”进行“通知”的过程。该技术特征涉及UE内部IMS服务管理器与应用之间的通信，在对比文件中完全未被提及。因此，该技术特征未被公开。 |
| **技术特征H**：其中所述用于处理所述其它多媒体通信服务的应用包括其它用户接口应用 <br> **《未公开》** | **段落 [0034]-[0038]**：描述了UE的各种单元，如第一呼叫执行单元、保持单元、第二呼叫发起单元等。 | 对比文件将UE的功能抽象为不同的“单元”，如保持单元、呼叫单元等，这些单元是功能逻辑上的划分，并未描述其实现形式为具有“用户接口”的应用。对比文件未涉及UE本地的用户接口应用的概念。因此，该技术特征未被公开。 |
| **技术特征I**：并且所述方法还包括：所述用于处理所述其它多媒体通信服务的应用通过启动其它用户接口应用并且使用所述其它用户接口应用获取用户指令来响应所述通知，所述用户指令指示接受还是拒绝所述建立其它多媒体通信服务的请求。 <br> **《未公开》** | **段落 [0021]**：步骤10. UE-C通过向ICCF发送200 OK指示用户已应答呼叫。<br><br>**段落 [0018]**：11. UE-C通过向ICCF发送200 OK指示用户已应答呼叫。 | 对比文件中，对于新呼叫（第二呼叫），用户是否应答的指示（200 OK）来自被叫方（UE-C），而非主叫方（UE-A）的用户。在呼叫保持流程中，UE-A的用户并未被提示接受或拒绝新呼叫，而是UE-A主动发起并建立了新呼叫。因此，没有获取用户接受或拒绝指令的过程。该技术特征未被公开。 |
| **技术特征J**：还包括响应于所获得的指示应当接受所述建立其它多媒体通信服务的请求的用户指令而接受所述其它多媒体通信服务 <br> **《未公开》** | **段落 [0034]-[0038]**：UE的各单元的功能描述。 | 基于上述分析，对比文件中不存在“获取用户指令指示应当接受”这一前提。新呼叫的建立是UE主动发起，而非响应于用户的接受指令。因此，该技术特征未被公开。 |
| **技术特征K**：其中，接受所述其它多媒体通信服务包括：发起(S108a)所述进行中的多媒体通信服务的暂停过程 <br> **《直接公开》** | **段落 [0018]**：1. 通过ICCC，UE-A向ICCF发送保持当前呼叫的请求。<br><br>**段落 [0010]**：一种用于保持呼叫的方法，包括：第一UE通过第一CS接入呼叫支路与第二UE执行第一呼叫……发送ICCC请求以保持第一呼叫。 | 对比文件的核心就是“呼叫保持”。当UE-A决定建立新呼叫时，首先执行的动作就是通过ICCC发送请求来“保持”当前进行中的第一呼叫。这个“保持”（Hold）过程，在本领域中即为发起进行中通信服务的暂停过程。因此，该技术特征被直接公开。 |
| **技术特征L**：激活(S108b)所述其它多媒体通信服务 <br> **《直接公开》** | **段落 [0018]**：步骤11. UE-C通过向ICCF发送200 OK指示用户已应答呼叫。12. 通过ICCC，ICCF指示呼叫被应答。<br><br>**段落 [0019]**：UE-A通过支持第二媒体类型的第二CS接入呼叫支路与UE-C执行第二呼叫。 | 在保持第一呼叫后，对比文件通过一系列流程（步骤7-12）建立了新呼叫，并激活了与UE-C的第二呼叫。这个新呼叫的建立和连接过程即为激活“其它多媒体通信服务”。因此，该技术特征被直接公开。 |
| **技术特征M**：还包括响应于所获得的指示应当拒绝所述建立其它多媒体通信服务的请求的用户指令而拒绝所述其它多媒体通信服务 <br> **《未公开》** | 全文未提及。 | 对比文件的技术方案是UE主动发起呼叫保持和新呼叫，不存在UE-A的用户拒绝新呼叫的场景。整个方案中，新呼叫的建立是必然发生的，无拒绝的流程和指令。因此，该技术特征未被公开。 |
| **技术特征N**：其中，拒绝所述其它多媒体通信服务包括：继续进行(S110a)所述进行中的多媒体通信服务 <br> **《未公开》** | 全文未提及。 | 由于对比文件不存在拒绝新呼叫的场景，自然也就不存在“继续进行”进行中的多媒体通信服务的步骤。新呼叫建立后，进行中的呼叫是被“保持”而非“继续进行”。因此，该技术特征未被公开。 |
| **技术特征O**：拒绝(S110b)接受所述其它多媒体通信服务 <br> **《未公开》** | 全文未提及。 | 基于上述分析，无此动作。 |
| **技术特征P**：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务中的一个是用于在所述UE上执行第一多媒体类型的多媒体服务的默认应用(24)。<br> **《未公开》** | **段落 [0018]-[0038]**：全部实施例中，第一呼叫和第二呼叫的处理涉及的是CS域连接和ICCF控制，没有提及UE本地的“应用”及其“默认”或“非默认”属性。 | 对比文件没有定义或区分UE上的“默认应用”和“非默认应用”。所有呼叫的处理都是由网络侧（ICCF）和UE的底层通信模块（如ICCC， CS呼叫处理）共同完成，没有上升到UE应用层。因此，该技术特征未被公开。 |
| **技术特征Q**：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务二者是用于在所述UE上执行第一多媒体类型的多媒体服务的非默认应用(25a、25b)。 <br> **《未公开》** | 全文未提及。 | 同上，对比文件不涉及UE应用层，也未区分默认或非默认应用。 |
| **技术特征R**：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务使用所述UE的默认因特网协议多媒体子系统“IMS”通信服务。 <br> **《隐含公开》** | **段落 [0002]**：本发明涉及通信领域，尤其涉及一种在IMS集中服务（ICS）下的呼叫保持方法和设备。<br><br>**段落 [0006]**：ICS UE-A是一个支持ICCC的增强型UE。 | 对比文件基于IMS集中服务（ICS）架构，所有呼叫都通过IMS网络进行控制。UE-A发起的呼叫（包括第一呼叫和第二呼叫）都是IMS呼叫，利用了IMS的底层通信服务。虽然未明确提及“默认IMS通信服务”，但在ICS架构下，用于承载语音和视频的基本IMS服务可以被视为默认服务。因此，该技术特征被隐含公开。 |
| **技术特征S**：其中，所述默认IMS通信服务负责传送应用命令和所述第一多媒体类型的多媒体通信服务的数据。 <br> **《隐含公开》** | **段落 [0006]**：通过ICCC，UE接收和发送与IMS呼叫相关的控制信令。ICCC可以通过USSD或PS域呼叫承载。<br><br>**段落 [0018]**-**[0038]**：各个流程图中的SIP消息（Invite, Update, 200 OK等）交互，用于传送信令和数据。 | 对比文件中，UE通过ICCC传送控制信令（如保持请求、呼叫请求），并通过IMS核心网传送媒体数据。这些SIP信令和媒体数据流正是通过底层的IMS通信服务来承载和传送的。因此，虽然对比文件没有直接使用“默认IMS通信服务负责传送应用命令和数据”的表述，但其技术方案完全依赖于IMS服务来实现此功能，因此该技术特征被隐含公开。 |
| **技术特征T**：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务中的至少一个与IMS应用参考标识符“IARI”相关联。<br> **《未公开》** | 全文未提及“IARI”或类似的“IMS应用参考标识符”。 | 对比文件区分不同呼叫的依据是“媒体类型”（媒体类型，如语音、视频、多媒体），而非“IARI”。目标专利中使用IARI来区分不同的第三方应用，这是其解决的技术问题之一。对比文件中没有关于IARI的任何记载或暗示。因此，该技术特征未被公开。 |
### 结论
根据上述严谨的比对分析，对比文件EP2230814A1直接公开了技术特征A、K、L；隐含公开了技术特征D、R、S。对于其他技术特征（B, C, E, F, G, H, I, J, M, N, O, P, Q, T），对比文件均未公开。
<<<A>>><<<K>>><<<L>>><<<d>>><<<R>>><<<S>>>