对比文件名称：2011-02-24_JP2011505772A_发明专利_JP2011505772A A method and apparatus to realize the retention of the call
目标专利名称：1154多媒体通信服务处理CN105612730B
本次调用的模型名称：未提供（用户未指定）
## 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A：所述方法由所述UE执行，包括以下步骤** 《直接公开》 | 对比文件[0009]公开：“呼を保持する方法は、第１のＵＥが、第１のＣＳ接続のコールレグを通して第２のＵＥと第１の呼を実行するステップを含み”（呼叫保持的方法包括：第一UE通过第一CS连接的呼叫支路与第二UE执行第一呼叫的步骤）；[0002]公开：“ＵＥ−ＡはＩＣＣＣを通してＩＣＣＦに現在の呼を保持する要求を送信する”（UE-A通过ICCC向ICCF发送当前呼叫的保持请求）；各实施例步骤均以UE-A为执行主体描述操作。 | 对比文件明确以UE（UE-A）为执行主体，描述了UE执行呼叫保持和发起新呼叫的完整方法步骤，例如UE发送保持请求、发送呼叫请求、接收通知等。本领域技术人员能毫无疑义地确定该方法是由UE执行的，故技术特征A被直接公开。 |
| **技术特征B：经由第一用户接口应用处理(S102)进行中的多媒体通信服务** 《未公开》 | 对比文件[0002]公开：“ＵＥ−ＡとＵＥ−Ｂは第１のＣＳ接続のコールレグを通して音声呼を実行する”（UE-A与UE-B通过第一CS连接的呼叫支路执行语音呼叫）。对比文件未提及“第一用户接口应用”或任何类似的应用层实体。 | 对比文件仅描述UE通过CS连接执行呼叫的底层通信过程，未涉及UE内部通过“用户接口应用”处理多媒体通信服务的概念。对比文件中不存在默认应用或非默认应用的区分，也未公开任何应用层用户接口。本领域技术人员无法从对比文件中得出该技术特征。 |
| **技术特征C：在所述处理期间，接收(S104)建立其它多媒体通信服务的请求** 《未公开》 | 对比文件[0002]公开：“ＵＥ−ＡはＩＣＣＦにＵＥ−Ｃへ発呼する要求を送信する”（UE-A向ICCF发送发往UE-C的呼叫请求）；[0002]公开：“ＵＥ−Ｃは、それが呼び出し中であり、ユーザからの応答を待っていることを示す通知を提供する”（UE-C提供通知表示正在振铃等待用户应答）。对比文件中UE-A是主动发起方，发送请求而非接收请求。 | 对比文件的场景是UE-A在处理第一呼叫期间，主动向网络发送保持请求和发起新呼叫的请求，而不是接收来自外部或内部的建立其他多媒体通信服务的请求。对比文件中UE-A接收的是呼叫状态通知（如振铃通知、应答通知），而非建立请求。本领域技术人员无法得出该特征。 |
| **技术特征D：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务需要访问UE中一次只能够服务于一个进行中的多媒体通信服务的资源** 《隐含公开》 | 对比文件[0002]公开：“呼の保持は、ＵＥが現在の呼を保持し、同時に新たな呼を設定することを意味する”（呼叫保持意味着UE保持当前呼叫，同时设定新呼叫）；[0002]各实施例中必须先将第一呼叫保持（Hold）后才能发起第二呼叫，步骤1均为“UE-A向ICCF发送当前呼叫的保持请求”。 | 对比文件反复强调必须先“保持”当前呼叫才能发起新呼叫，其技术前提是UE的媒体处理资源（如CS连接、编解码器等）一次只能服务于一个活动呼叫，否则无需保持操作。本领域技术人员可以合理推断出UE中存在一次只能服务于一个进行中的多媒体通信服务的资源限制，该限制是呼叫保持功能的逻辑基础。因此技术特征D隐含公开。 |
| **技术特征E：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务通过操作系统来保持独立** 《未公开》 | 对比文件全文未提及“操作系统”以及通过操作系统保持应用独立的概念。对比文件[0002]涉及CS/IMS网络域的信令交互，不涉及UE内部操作系统架构。 | 对比文件的技术方案侧重于网络侧ICCF、MGCF等实体之间的信令交互，完全不涉及UE内部操作系统的应用隔离机制。本领域技术人员无法从对比文件中得出该特征。 |
| **技术特征F：通过IMS服务管理器(21n)来协调(S106)所述进行中的多媒体通信服务和所述其它多媒体通信服务的处理** 《未公开》 | 对比文件[0002]公开：“ＩＣＣＦはＵＥ−Ｂに呼を保持する要求を送信する”（ICCF向UE-B发送呼叫保持请求）；“ＩＣＣＦはＵＥ−Ｃに呼要求（Ｉｎｖｉｔｅ）を送信する”（ICCF向UE-C发送呼叫请求）。对比文件的协调实体为网络侧的ICCF，而非UE内部的IMS服务管理器。 | 对比文件中的协调中心是网络侧的ICCF（IMS CS控制功能），其负责处理呼叫保持、呼叫发起等网络信令交互。而目标专利的IMS服务管理器是UE内部的逻辑单元，负责协调UE内多个应用。两者实体不同、位置不同、功能范围不同。本领域技术人员无法从对比文件中得出UE内部设有IMS服务管理器进行协调的特征。 |
| **技术特征G：其中协调包括向用于处理所述其它多媒体通信服务的应用通知所述建立其它多媒体通信服务的请求** 《未公开》 | 对比文件[0002]公开：“ＩＣＣＦは、ＩＣＣＣを通して、呼が応答されたことを通知する”（ICCF通过ICCC通知呼叫已应答）。对比文件中ICCF向UE-A发送的是呼叫状态通知，而非向应用通知建立请求。 | 对比文件未涉及UE内部应用层面的通知机制。ICCF通过ICCC向UE-A发送的是呼叫进展通知（如呼入、应答），而非向特定的“用于处理其它多媒体通信服务的应用”通知建立请求。对比文件不存在应用层通知的概念。本领域技术人员无法得出该特征。 |
| **技术特征H：其中所述用于处理所述其它多媒体通信服务的应用包括其它用户接口应用** 《未公开》 | 对比文件全文未提及“用户接口应用”或类似的应用实体。对比文件仅描述UE-A通过ICCC与网络交互，未公开UE内运行的应用及其类型。 | 对比文件未涉及UE内部应用架构，没有公开任何类型的用户接口应用，更没有区分默认应用与非默认应用。本领域技术人员无法从对比文件中得出该特征。 |
| **技术特征I：并且中所述方法还包括：所述用于处理所述其它多媒体通信服务的应用通过启动其它用户接口应用并且使用所述其它用户接口应用获取用户指令来响应所述通知，所述用户指令指示接受还是拒绝所述建立其它多媒体通信服务的请求。** 《未公开》 | 对比文件全文未描述通过启动用户接口应用来获取用户指令的过程。对比文件各实施例中用户交互方式未明确。 | 对比文件未公开应用层如何响应用户指令。目标专利明确要求启动用户接口应用并获取用户指示接受或拒绝的指令，这是应用层交互过程。对比文件无任何关于用户接口应用启动、用户指令获取的记载或暗示。本领域技术人员无法得出该特征。 |
| **技术特征J：还包括响应于所获得的指示应当接受所述建立其它多媒体通信服务的请求的用户指令而接受所述其它多媒体通信服务** 《未公开》 | 对比文件各实施例中，UE-A主动发起呼叫请求，不存在“接受”其他方请求的过程。例如[0002]步骤3：“ＵＥ−ＡはＩＣＣＦにＵＥ−Ｃへ発呼する要求を送信する”（UE-A向ICCF发送发往UE-C的呼叫请求）。 | 对比文件中UE-A是主叫方，主动发起新呼叫，不存在作为被叫方“接受”其他多媒体通信服务请求的场景。目标专利的“接受”是基于用户指令对收到的建立请求做出肯定响应，与主动发起有本质区别。本领域技术人员无法得出该特征。 |
| **技术特征K：其中，接受所述其它多媒体通信服务包括：发起(S108a)所述进行中的多媒体通信服务的暂停过程** 《隐含公开》 | 对比文件[0002]各实施例步骤1均公开：“ＵＥ−ＡはＩＣＣＣを通してＩＣＣＦに現在の呼を保持する要求を送信する”（UE-A通过ICCC向ICCF发送当前呼叫的保持请求）。步骤1明确执行了暂停（保持）当前呼叫的操作。 | 对比文件中，为发起新呼叫，UE-A首先执行当前呼叫的保持（Hold）操作，该保持操作与目标专利的“暂停过程”功能相同，都是暂时中断进行中的服务以释放资源。虽然目标专利是通过IMS服务管理器协调，对比文件是通过网络信令，但“发起暂停过程”这一技术功能被对比文件公开。本领域技术人员可以合理推断出接受新服务需要暂停当前服务的逻辑。因此隐含公开。 |
| **技术特征L：激活(S108b)所述其它多媒体通信服务。** 《隐含公开》 | 对比文件[0002]各实施例步骤3均公开：“ＵＥ−ＡはＩＣＣＦにＵＥ−Ｃへ発呼する要求を送信する”（UE-A向ICCF发送发往UE-C的呼叫请求）。随后通过信令交互完成第二呼叫的激活。 | 对比文件中，在保持（暂停）当前呼叫后，UE-A发起对UE-C的呼叫请求并最终建立新呼叫，实现了“激活其他多媒体通信服务”的功能。该功能与目标专利一致。虽然激活的信令路径不同，但“激活其它多媒体通信服务”这一技术功能被对比文件公开。因此隐含公开。 |
| **技术特征M：还包括响应于所获得的指示应当拒绝所述建立其它多媒体通信服务的请求的用户指令而拒绝所述其它多媒体通信服务** 《未公开》 | 对比文件所有实施例均描述接受新呼叫并保持当前呼叫的场景，未描述拒绝新呼叫的场景。 | 对比文件的技术方案聚焦于如何成功保持当前呼叫并建立新呼叫，没有涉及拒绝新呼叫的流程或用户指令处理。本领域技术人员无法从对比文件中得出拒绝机制。 |
| **技术特征N：其中，拒绝所述其它多媒体通信服务包括：继续进行(S110a)所述进行中的多媒体通信服务** 《未公开》 | 对比文件无拒绝场景，未描述继续进行进行中的多媒体通信服务的情况。 | 对比文件未公开任何与拒绝新服务相关的技术内容，包括继续进行当前服务。 |
| **技术特征O：拒绝(S110b)接受所述其它多媒体通信服务。** 《未公开》 | 对比文件无拒绝场景，未描述拒绝接受其他服务。 | 对比文件未公开拒绝接受其他多媒体通信服务的任何步骤或机制。 |
| **技术特征P：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务中的一个是用于在所述UE上执行第一多媒体类型的多媒体服务的默认应用(24)。** 《未公开》 | 对比文件全文未提及“默认应用”的概念。对比文件中的呼叫处理不涉及应用层区分。 | 对比文件不涉及UE内应用层的默认或非默认划分，其描述的是网络层呼叫控制，没有应用实体的概念。本领域技术人员无法得出该特征。 |
| **技术特征Q：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务二者是用于在所述UE上执行第一多媒体类型的多媒体服务的非默认应用(25a、25b)。** 《未公开》 | 对比文件全文未提及“非默认应用”的概念。对比文件不涉及第三方应用或非标准应用。 | 对比文件不涉及UE内应用层的默认或非默认划分，没有第三方应用或非标准应用的概念。本领域技术人员无法得出该特征。 |
| **技术特征R：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务使用所述UE的默认因特网协议多媒体子系统“IMS”通信服务。** 《未公开》 | 对比文件[0002]涉及IMS网络和ICS架构，但未提及“默认IMS通信服务”这一UE侧概念。 | 对比文件涉及IMS核心网，但未公开UE侧使用的“默认IMS通信服务”这一特定服务实体。目标专利的默认IMS通信服务是UE内负责IMS信令的底层服务，对比文件无此概念。 |
| **技术特征S：其中，所述默认IMS通信服务负责传送应用命令和所述第一多媒体类型的多媒体通信服务的数据。** 《未公开》 | 对比文件未公开默认IMS通信服务的功能定义。 | 对比文件未定义任何与“默认IMS通信服务”功能相关的技术内容。 |
| **技术特征T：其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务中的至少一个与IMS应用参考标识符“IARI”相关联。** 《未公开》 | 对比文件全文未提及“IMS应用参考标识符”或“IARI”。 | 对比文件未公开IARI或任何类似的应用标识符。目标专利通过IARI区分默认应用和非默认应用，对比文件无此机制。本领域技术人员无法得出该特征。 |
## 公开性代码输出
基于上述严谨分析，对比文件对目标专利权利要求的各技术特征的公开情况如下：
* 技术特征A被直接公开。
* 技术特征D被隐含公开。
* 技术特征K被隐含公开。
* 技术特征L被隐含公开。
其他技术特征（B、C、E、F、G、H、I、J、M、N、O、P、Q、R、S、T）未被对比文件直接或隐含公开。
<<<A>>>
<<<d>>>
<<<k>>>
<<<l>>>