一种用于用户设备“UE”(12a、12b)中的多媒体通信服务处理的方法，所述方法由所述UE执行，包括以下步骤；经由第一用户接口应用处理(S102)进行中的多媒体通信服务；在所述处理期间，接收(S104)建立其它多媒体通信服务的请求；其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务需要访问UE中一次只能够服务于一个进行中的多媒体通信服务的资源；其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务通过操作系统来保持独立；以及通过IMS服务管理器(21n)来协调(S106)所述进行中的多媒体通信服务和所述其它多媒体通信服务的处理；其中协调包括向用于处理所述其它多媒体通信服务的应用通知所述建立其它多媒体通信服务的请求，其中所述用于处理所述其它多媒体通信服务的应用包括其它用户接口应用；以及其中所述方法还包括：所述用于处理所述其它多媒体通信服务的应用通过启动其它用户接口应用并且使用所述其它用户接口应用获取用户指令来响应所述通知，所述用户指令指示接受还是拒绝所述建立其它多媒体通信服务的请求。

作为一名经验丰富的专利代理师，我将为您深度解析目标专利权利要求1，并结合目标专利说明书以及4份对比文件（D1-D4）的原文进行特征比对与创造性、无效可行性分析。

首先，通过核对公开号，我们发现以下两组对比文件实际上是**同族专利**：

* **D1 (CN101453453A)** 与 **D3 (EP2230814A1)**、**D4 (US20100238841A1)** 属于同族，均关注IMS集中业务（ICS）架构下通过电路域（CS）承载不同媒体类型时的呼叫保持（Call Hold）技术。

* **D2 (US20090316685A1)** 则涉及P2P或VoIP通信系统下，向未参与群组通信的成员通知参与状态的机制。

---

## 一、 权利要求特征比对表

基于目标专利说明书的解释，权利要求1的核心在于：**在应用层被操作系统相互隔离（独立）的现代UE中，当两个不同的UI应用（如两个第三方通信App，或一个默认App与一个第三方App）发生资源冲突时，由底层的IMS服务管理器在中间进行跨应用的通信协调与UI控制流协调。**

以下是权利要求1与各对比文件的详细特征比对：

---

## 二、 最接近的对比文件（D1 / D3 / D4 同族）分析

在创造性分析中，**D1（或其同族EP/US件D3、D4）最适合作为最接近的对比文件（D1可作为D1/D3/D4同族的代表）**。

### 1. 领域与技术问题最接近

* **技术领域**：目标专利与D1均属于**IMS（IP多媒体子系统）通信领域**，特别是研究当UE在面临多个多媒体通信服务（如呼叫保持、新呼叫建立）冲突时的处理机制。

* **整体解决的技术问题**：D1旨在解决“当两个呼叫的媒体类型不同（如语音和视频）时如何进行呼叫保持和资源协调”的问题（见D1【发明内容】）。这与目标专利解决“进行中的多媒体通信服务期间，其它多媒体通信服务请求到达，两个服务因冲突产生不确定性”的技术问题在本质上高度契合。

### 2. 技术效果与演进方向一致

D1通过重构终端与网络侧（ICCF/MGCF/VMSC）的信令交互流（如利用SCUDIF特性切换CS媒体连接或释放重建），实现了不同媒体服务的无缝切换，避免了业务中断。目标专利则是将这一协调冲突的阵地从“网络侧控制”或“单一应用内部控制”，转移到了现代智能手机“**现代操作系统隔离了各第三方App，底层IMS服务管理器跨应用协调**”的终端侧场景。因此，将D1作为发明演进的起点（最接近的现有技术）最为顺理成章。

> **为什么D2不适合作为最接近的对比文件？**

> D2是一个典型的P2P/VoIP应用层软件（如Skype类软件）的状态通知机制。它解决的技术问题是如何让未参与通话的群组成员通过IM通道“看到”群组通话状态，其核心是状态同步与显示（UI图标更新），而不涉及底层多媒体硬资源（如底层IMS电信级堆栈、CS/PS域通道切换、音频硬解码器隔离占用）的冲突协调。

---

## 三、 未公开特征的交叉检索与最薄弱技术特征分析

### 1. 未被最接近对比文件（D1同族）公开的特征

主要为：**特征E、F、G、H、I**。

这些特征构成了目标专利的核心发明点，即：**【现代OS下的多应用独立 + 终端侧底层IMS服务管理器 + 跨独立应用UI流拉起与指令获取】**。

这些特征**同样没有被D2公开**。D2虽然提到了通过Client Engine（客户端引擎）控制UI层（特征G的某种上位形式），但其完全局限于**同一个应用软件内部**。D2无法预示、也没有公开在操作系统将应用相互隔离（特征E）的前提下，由一个独立的“IMS服务管理器”去协调并“启动其他UI应用”（特征H、I）来获取指令。

### 2. 无效请求方最薄弱的技术特征（即专利权人最稳固的护城河）

若您代表**无效请求方**去挑战这件专利，最难攻克、最薄弱的武器将用在以下技术特征上（即**目标专利最不易被无效掉的核心技术特征**）：

> #### 特征I 与 特征E、F 的结合体（跨OS隔离应用的协调流）

> * **薄弱原因（对请求方而言）**：在传统的电信标准或早期IMS（如D1、D3、D4所处的2007-2010年阶段）中，手机的IMS终端一般是一个闭源、单一、固化的“Phone App”（即默认多媒体应用）。所有的呼叫等待、呼叫保持业务完全在这个默认App内部逻辑中消化。

> * **目标专利的立足点**：目标专利敏锐地切入了现代移动操作系统（如Android/iOS）的沙盒隔离机制——“应用典型地被操作系统相互隔离（特征E）”。在这种情况下，第三方通信App（如微信、Skype、Teams）无法互相得知对方的状态。目标专利提出了由底层的 **IMS服务管理器（21n）** 站出来，当新呼叫来临且识别出其IARI（应用参考标识符）属于另一个第三方应用时，底层管理器主动去操作系统中**“启动（拉起）其他用户接口应用”**，并由该被拉起的独立应用去获取用户的接受/拒绝指令（特征I）。

> * **无效难点**：现有的D1-D4对比文件完全处于“单应用”或者“网络侧硬切换”的思维定势中。D1只知道由ICCF或者单一增强UE客户端去响应呼叫模式变更；D2只知道在自己的软件群组里刷图标。没有任何一份对比文件给出了**“利用底层IMS管理器作为跨隔离App的桥梁，动态拉起另一个独立App UI获取硬资源控制指令”**的技术启示。

### 代理师建议

作为请求方，若要成功无效该特征，必须跳出传统的3GPP网络架构文件（D1/D3/D4），尝试去检索**操作系统层面的多应用进程间通信（IPC）、底层硬件服务（如AudioFlinger音频策略管理器）对第三方沙盒应用的焦点切换与资源仲裁**相关专利。单纯依靠现有的通信业务层对比文件（D1-D4），由于特征E、F、I的阻隔，很难在“显而易见性（创造性）”上说服专利局。

作为一名经验丰富的专利代理师，我将紧密结合目标专利《多媒体通信服务处理》（申请号：CN201480031201.8，授权公告号：CN105612730B，下称“本专利”）的说明书，对权利要求1进行深入解析，并结合提供的四份对比文件进行详细的比对分析和创造性论证。

### 第一部分：本专利权利要求1的法律解释与技术内涵

权利要求1保护的是一种在用户设备（UE）中处理多媒体通信服务的方法。为了准确界定其保护范围，必须依据本专利说明书（特别是【0007】-【0011】）来理解其解决的技术问题和核心发明构思。

**1. 解决的技术问题（发明背景）**

在现代UE（如智能手机）中，应用通常被操作系统隔离（保持独立）。当一个多媒体通信应用（如VoLTE电话）正在进行时，若另一个多媒体应用（如第三方即时通讯软件的视频呼叫）的请求到达，由于隔离机制，进行中的应用不知道新请求的到达。如果新应用直接启动并接管受限资源（显示器、麦克风、扬声器），会打扰进行中的呼叫，导致故障或用户疑惑。

**2. 核心发明构思**

本专利引入了一个**IMS服务管理器（21n）**。该管理器负责多媒体通信应用需要执行的所有IMS通信。当接收到建立新多媒体服务的请求时，不由网络直接启动新应用，而是通过IMS服务管理器来协调。协调的具体方式是：IMS服务管理器通知用于处理新应用的应用（如第三方应用自身，或其关联的用户接口应用），该应用通过启动**其自身的、独立于第一应用的其它用户接口应用**，使用户能够指示接受还是拒绝新请求。

**3. 特征解析与说明书出处**

* **特征D（一次只能服务于一个服务的资源）：** 说明书【0010】明确列举为“显示器或麦克风和扬声器”。

* **特征F（通过IMS服务管理器协调）：** 这是核心。说明书【0039】指出，IMS服务管理器负责所有IMS通信，能处理并行的若干个应用。

* **特征G、H、I（协调的具体步骤）：** 这些特征限定了通知的对象是“用于处理其它多媒体通信服务的应用”，且该应用包括“其它用户接口应用”。关键在于，响应通知的操作是启动这个**其它**用户接口应用来获取用户指令。这意味着，在用户做出选择之前，进行中的服务和新服务依然保持独立，且由各自对应的（至少用户接口层面是独立的）应用进行处理，通过IMS服务管理器在中间调度。

---

### 第二部分：对比文件特征比对及分析

我们将对四份对比文件进行分析。为了便于表述，使用以下指代：

* **D1：** ES2397967T3 (2013-03-12) / WO2009074103A1 (同族，使用中文文本分析)

* **D2：** US20130156177A1 (2013-06-20)

* **D3：** US8472354B2 (2013-06-25)

* **D4：** 即WO2009074103A1的说明书文本（与D1内容实质相同，以下统一以D1/D4指代该公知技术）

#### 特征比对表格

#### 各对比文件公开特征详细出处及分析

**1. D1/D4 (ES2397967T3 / WO2009074103A1)**

* **技术领域与问题：** D1属于IMS集中业务控制（ICS）领域。它解决的问题是：当UE只能接入CS域，或PS域不支持实时语音/视频时，如何通过CS网承载IMS呼叫，并实现呼叫保持。

* **技术方案：** 核心是引入了ICCF（网络侧实体）。第一呼叫（UE-A到UE-B）建立后，UE-A想呼叫UE-C。D1提出了几种方案。方案一（图2、图5）是UE-A通过VMSC向MGCF发送CS呼叫模式变更请求，请求从语音变为多媒体，再通过网络侧（ICCF, CSCF）传递给UE-C。方案二（图4）是先释放第一CS access call leg，再建立第二CS access call leg。

* **薄弱技术特征比对：** D1虽然公开了UE侧资源受限（特征D），但核心特征**F, G, I**并未公开。D1的ICCF在网络侧，不符合“由UE执行”。D1没有涉及操作系统强制的应用隔离（特征E），其协调过程并非通过通知第三方应用启动新UI来完成，而是通过传统的电路域信令（通过VMSC/MGCF）来变更呼叫模式（特征I）。

**2. D2 (US20130156177A1)**

* **技术领域与问题：** 属于多接口（VoIP, PSTN, 移动电话）下的呼叫控制领域。解决的问题是用户在一个设备上有活动呼叫时，在另一设备上收到来电，用户不方便切换设备。

* **技术方案：** 核心是引入了“呼叫控制应用（12）”和“保持队列”。当新来电到达时，用户按耳机按钮（特征I的用户指令），呼叫控制应用将当前活动呼叫放入保持队列，然后激活新呼叫。它支持多个软电话应用（14, 15）。

* **薄弱技术特征比对：** D2的“呼叫控制应用”位于UE，能协调多个UI应用（特征H实质公开）。它解决的问题非常接近。但是，它**不是基于IMS的服务管理器**（特征F）。在协调机制上，它依赖底层硬件（耳机）事件触发，呼叫控制应用维护队列，并非由它主动通知用于处理新服务的应用去启动新UI（特征G, I）。

**3. D3 (US8472354B2)**

* **技术领域与问题：** 属于IMS（[0015]提及）协议下的传统电路交换网络与新数据基础设施（VoIP）合并的领域。解决的问题是使被叫方在不中断现有重要通话的情况下，处理新来电。

* **技术方案：** 核心是“自定义呼叫等待”。当Bob和Alice通话时，Charlie打进来。Alice在SIP电话上收到来电标识。Alice可以按键盘代码（用户指令）选择一条预录消息发送给网络侧的SIP代理125，由SIP代理发送给Charlie（图5A）。此时Alice和Bob通话未中断。另一种方案是，Alice将Bob置于保持，转去和Charlie通话，同时让网络代理播放消息给保持中的Bob（图6A）。

* **薄弱技术特征比对：** D3使用了SIP协议和IMS概念（特征F部分实质公开）。但它不涉及OS层面的应用独立（特征E）。在协调上，特征I是典型的薄弱特征：网络代理接收用户代码命令来提供媒体内容，未涉及UE内部IMS管理器通知第三方应用启动另一个用户接口应用来指示操作。

---

### 第三部分：创造性分析：最接近对比文件的选择

在无效请求的创造性分析过程中，选择合适的最接近对比文件至关重要。

**本专利解决的核心问题是：在具有应用隔离（应用独立）机制的操作系统中，进行中的多媒体服务不知道新服务请求的到达，直接启动会产生资源冲突，需要协调。**

对比D1-D3：

1. **D1/D4**：位于网络侧的ICCF协调CS与IMS。它侧重于不同媒体类型所需的CS接入支路的变更，而非UE内部不同应用之间的UI和硬件资源（麦克风、扬声器）协调。它不涉及OS应用隔离这一前提。

2. **D2**：位于UE侧的呼叫控制应用协调多个具有GUI的软电话。它解决的问题非常接近，即“用户可能在一种设备上进行活动呼叫，然后在另一个设备（或其他接口）上收到来电……必须因此忽略其中一个来电来回答另一个”。它在结构上和权利要求1非常相似，具有UE内执行协调的实体。

3. **D3**：侧重于网络代理在“呼叫等待”场景下发送自定义媒体。它不关注被隔离的应用如何分享UI资源。

因此，**从整体解决的技术问题以及技术效果角度分析，对比文件D2适合做最接近的对比文件。** D2也具有协调不同UI应用活动状态的实体和机制，尽管它不是专门针对IMS网络架构。

此外，**本代理师指出，对比文件D1/D4也适合做最接近的对比文件**。理由是：D1位于IMS集中业务领域。权利要求1解决问题的核心实体限定为“IMS服务管理器”。D1实质公开了这种管理器（ICCF），虽然在网络侧。本领域技术人员为了解决网络和UE内部信息不对称带来的冲突，可能尝试将这种协调功能下移至UE侧。

---

### 第四部分：无效请求对于请求方来说最薄弱的技术特征

请求方如果要提出无效请求，通常需要论证本专利权利要求1相对于对比文件是不具备创造性的。通过上述比对，可以清晰地识别出本专利最具创造性的特征，即对请求方来说最薄弱的环节。

**1. 特征E（通过操作系统保持独立）：**

本领域技术人员都知道现代OS具有应用隔离机制，但这通常作为背景知识。D1-D3均未明确强调这一特征。权利要求将其作为技术背景特征，在无效过程中，请求方需要结合公知常识来论证这一特征是显而易见的背景。单独依靠此特征无法对抗权利要求的创造性。

**2. 核心最薄弱特征：特征F, G, I的组合**

这三个特征构成了本专利独特的协调机制。

如果以**D2**为最接近对比文件：

* D2公开了由UE执行的呼叫协调应用（实质特征F）协调多个第三方UI应用（实质特征H）。

* 区别在于：本专利限定该应用为“IMS服务管理器”；协调的具体方式是管理器通知第三方应用，该应用通过**启动其它用户接口应用**来响应。

* 请求方的最薄弱环节在于特征I中**“所述用于处理所述其它多媒体通信服务的应用通过启动其它用户接口应用……来响应所述通知”**。即使引入了公知常识（通过弹出UI获取用户输入），本专利明确限定了是“用于处理其它多媒体通信服务的应用”通过“启动其它用户接口应用”来做，实现了管理器、新服务应用、新UI应用之间的三方调度，这在D2中是没有被暗示的（D2通过耳机键硬件中断来队列活动状态）。

如果以**D1/D4**为最接近对比文件：

* D1公开了IMS领域的实体ICCF进行协调。

* 区别在于：ICCF在网络侧，本专利在UE侧；本专利通过OS隔离的应用间在界面层面的启动来协调，实现特征G, I。特征I中的**三方调度机制**在D1中同样没有提及。

**结论**：

综上所述，对于请求方来说，提出无效请求时，在技术特征比对上**最薄弱（即最难论证其被公开或实质公开）的技术特征**在于**特征I（以及关联的G, H）限定的具体协调机制：**

> “协调包括向用于处理所述其它多媒体通信服务的应用通知……所述用于处理所述其它多媒体通信服务的应用包括其它用户接口应用；并且中所述方法还包括：所述用于处理所述其它多媒体通信服务的应用通过启动其它用户接口应用并且使用所述其它用户接口应用获取用户指令来响应所述通知，所述用户指令指示接受还是拒绝所述建立其它多媒体通信服务的请求。”

这一特征通过在IMS管理器、新请求对应的应用、以及新请求对应的用户接口应用之间建立特定的、基于OS隔离运行的通知和启动机制，提供了一种本专利（说明书【0013】）宣称的“在UE中的改进的多媒体通信服务处理”。目前的对比文件D1-D3均不具备这种特定的内部应用间界面层面的协调逻辑。

作为一名经验丰富的专利代理师，我将严格依据《专利审查指南》及相关法律法规，紧密结合目标专利说明书的公开内容，对权利要求1进行深入解析。同时，我将逐一结合四篇对比文件（下称D1至D4）的详细出处与原文，进行全面、客观的特征比对与创造性评价，并最终给出无效宣告请求策略中的最薄弱技术特征分析。

以下为详细的分析报告：

---

## 一、 目标专利权利要求1的边界与技术特征拆解

为了进行精确的特征比对，首先结合目标专利（CN105612730B）说明书的背景技术及具体实施方式，对权利要求1的各个技术特征进行技术内涵和保护范围的边界解释：

* **技术特征A（主题名称及执行主体）：** `一种用于用户设备“UE”(12a、12b)中的多媒体通信服务处理的方法，所述方法由所述UE执行，包括以下步骤；`

* **规范解释：** 明确了方法的执行主体是终端设备（UE），如手机、平板或车载通信终端。

* **技术特征B（进行中服务处理）：** `经由第一用户接口应用处理(S102)进行中的多媒体通信服务；`

* **规范解释：** 对应说明书图5的步骤S102。指UE当前正有一个处于活动状态的多媒体会话（例如图7中的现有VoLTE语音呼叫，由默认应用24在UI界面处理）。

* **技术特征C（新请求接收）：** `在所述处理期间，接收(S104)建立其它多媒体通信服务的请求；`

* **规范解释：** 对应说明书图5的步骤S104。指在上述进行中会话期间，UE接收到触发新多媒体服务的异步请求（例如图7中IMS网络转发的SIP INVITE消息）。

* **技术特征D（资源冲突限定）：** `其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务需要访问UE中一次只能够服务于一个进行中的多媒体通信服务的资源；`

* **规范解释：** 核心物理约束限定。结合说明书\[0010\]及\[0047\]，该资源指“麦克风、扬声器、多媒体处理器、显示器和输入设备”等独占性硬件或底层多媒体资源，无法同时供给两个独立的多媒体应用使用。

* **技术特征E（系统隔离限定）：** `其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务通过操作系统来保持独立；`

* **规范解释：** 核心架构约束限定。结合说明书\[0009\]及\[0117\]，“在现代UE中，应用典型地被操作系统相互隔离”，导致两个独立的应用无法直接通过操作系统或应用进程间直接获知对方的存在和资源占用状态。

* **技术特征F（协调主体）：** `通过IMS服务管理器(21n)来协调(S106)所述进行中的多媒体通信服务和所述其它多媒体通信服务的处理；`

* **规范解释：** 引入第三方集中协调机制。由于OS隔离，底层IMS服务管理器（21n）充当协调枢纽，负责处理并行的多个应用。

* **技术特征G（通知动作）：** `其中协调包括向用于处理所述其它多媒体通信服务的应用通知所述建立其它多媒体通信服务的请求，`

* **规范解释：** 协调的第一阶段限定。IMS服务管理器检测到新请求后，基于如IARI等标识，主动分发并通知对应的另一个处理应用（例如图7中的非默认应用25a）。

* **技术特征H（应用类型限定）：** `其中所述用于处理所述其它多媒体通信服务的应用包括其它用户接口应用；`

* **规范解释：** 限定了处理新请求的应用拥有独立的UI应用（即非默认应用或第三方非捆绑应用，区别于无界面的后台服务）。

* **技术特征I（响应与交互闭环）：** `以及其中所述方法还包括：所述用于处理所述其它多媒体通信服务的应用通过启动其它用户接口应用并且使用所述其它用户接口应用获取用户指令来响应所述通知，所述用户指令指示接受还是拒绝所述建立其它多媒体通信服务的请求。`

* **规范解释：** 整个协调流程的交互闭环限定。新应用被唤醒后，弹出来自该新应用的独立UI界面，通过端用户手动点击“接受”或“拒绝”来返回指令，IMS服务管理器再根据该指令执行后续的挂起（UPDATE/不活动）或拒绝操作。

---

## 二、 对比文件特征比对表格与原文出处分析

为清晰展现各对比文件（D1\~D4）对权利要求1技术特征的公开情况，特制备如下特征比对表，并严格标明对比文件原文对应的段落及公开事实分析。

### 权利要求1技术特征比对表

---

## 三、 对比文件毫无疑问公开或实质公开的特征详细分析

### 1. D1: JP2011505772A (公开号: JP2011505772A)

* **毫无疑问公开的特征：** **特征A、B、C、G、H**。

* *出处与事实：* 根据原文\[2\]及\[0012\]，D1明确公开了一种在IMS集中服务（ICS）架构下保持呼叫的方法。其中“ＵＥ-ＡとＵＥ-Ｂは...第１の呼を実行する（公开了特征A、B）”；在执行期间，通过控制通道发送保持请求并建立与UE-C的第二呼叫（公开了特征C）；在流程第4步中，“ＩＣＣＦはＵＥ-Ｃに呼要求（Ｉｎｖｉｔｅ）を送信する（公开了特征G）”；并且在后续改进中，明确UE-A端“呼を保持するアプリケーション（包含其它UI应用，特征H）”需要做出改进以适配不同的媒体类型。

* **实质公开的特征：** **特征D、F、I**。

* *出处与事实：* 针对**特征D**，D1说明书\[0007\]-\[0009\]指出“異なる呼は異なるＣＳメディア接続を要求するので...異なるメディアタイプの２つの呼を保持”，其实质指出了在多媒体呼叫交替时对底层通道/媒体连接这类独占性资源的争抢与复用；针对**特征F**，D1公开了“ＩＭＳ ＣＳ制御機能（ＩＣＣＦ）”或“制御装置”，用于协调第一呼叫和第二呼叫的处理，虽然其核心协调逻辑位于网络侧或由网络侧控制单元主导，但其实质起到了协调IMS多媒体服务处理的作用；针对**特征I**，其流程中公开了“ＵＥ-Ｃは呼に応答するようにユーザに指示し”，最终返回200 OK或拒绝，实质公开了获取用户指令进行响应的闭环。

### 2. D2: US8036140B2 (公开号: US8036140B2)

* **毫无疑问公开的特征：** **特征A、C、G、H、I**。

* *出处与事实：* D2公开了一种在无服务器对等网络（Serverless P2P）中邀请参与活动的应用编程接口。摘要及\[0010\]-\[0011\]明确指出：在接收端端点（receiving endpoint，特征A），启动第一应用来接收活动邀请（特征C）；如果满足能力，则“launching a computing application on the receiving endpoint to execute the activity（公开了启动应用进行通知，特征G）”；且该接收应用可以是“messenger application, or the computing application（特征H）”；\[0040\]中明确公开了用户拥有“'accept', 'reject', or 'ignore'”的选项，且应用通过启动并获取该用户指令进行响应（公开了特征I）。

* **实质公开的特征：** **特征B**。

* *出处与事实：* 见\[0008\]“initiating a first application for sending an invitation...”，在P2P协作网络中，两端处于进行中的协作应用活动中，实质公开了“处理进行中的多媒体通信服务”。

### 3. D3: US8077702B2 (公开号: US8077702B2)

* **毫无疑问公开的特征：** **特征A、C**。

* *出处与事实：* D3公开了一种提供主叫信息的方法。在\[0020\]-\[0026\]中明确，在建立语音呼叫之前，第二方设备（特征A）通过分组交换网络（PS）接收实时的呼叫相关信息，同时通过电路交换网络（CS）接收呼叫建立消息（特征C）。D3的核心在于利用PS网络动态提前传送主叫的多媒体丰富信息，用以辅助用户在CS呼叫到来时做出决策。对目标专利后半段关于UE内部多应用隔离与协调的架构未予涉及。

### 4. D4: US20120331159A1 (公开号: US20120331159A1)

* **毫无疑问公开的特征：** **特征A、C、G、H**。

* *出处与事实：* D4公开了一种用于识别IMS服务的方法和装置。在说明书\[0023\]中明确指出：“at a user terminal... the IMS stack identifies the appropriate communication service on the basis of a communication service identifier... and forwards the message to the functional entity that implements this service.（毫无疑问公开了特征A、C、G）”；同时，在\[0049\]及图5中公开了该服务应用可以是vendor提供的“default”应用，也可以是“vendor/operator specific applications（如其它用户接口应用，特征H）”。

* **实质公开的特征：** **特征B、D、F**。

* *出处与事实：* 针对**特征F**，D4通过图5及\[0023\]公开了由终端本地的“IMS Stack”识别服务标识符（ICSI/IARI）并进行精准分发，这与目标专利的“IMS服务管理器（21n）”在逻辑层面上属于相同的技术组件，实质公开了特征F；针对**特征D**，\[0013\]-\[0014\]指出：“Different functional entities... designated to handle different services... For example, voice (audio) in PoC does not require the same Quality of Service support in the network as P2P multimedia, and therefore media will be allocated accordingly”，这指出了不同的IMS应用对底层媒体流资源、QoS分配存在差异和排他性冲突，实质公开了特征D。

---

## 四、 最接近对比文件（最接近的现有技术）的选择与创造性评价

### 1. 最接近对比文件的确立：**D4 (US20120331159A1)**

基于《专利审查指南》中“最接近的现有技术”选择原则（领域相同、技术问题最接近、公开特征最多），本案中**D4（公开号：US20120331159A1）最适合作为最接近的对比文件**。

* **理由：**

1. **技术领域与架构完全一致：** D4与目标专利均属于IMS通信领域，且均聚焦于**用户设备（UE）终端本地**的IMS架构改良。D4图5所展示的“IMS Stack + Default/Specific Applications”三层架构，与目标专利图2c展示的“IMS栈 + IMS服务管理器 + 默认/第三方应用”逻辑完全同构。

2. **解决的技术问题最相关：** D4解决的正是如何在本地识别不同的IMS多媒体服务（如PoC、P2P多媒体等）并将其准确分发给不同应用的问题，这与目标专利在\[0004\]-\[0006\]中描述的通过IARI分发多媒体电话邀请的技术背景完全契合。

3. **公开特征最多：** 相比于侧重网络侧（ICCF）控制的D1或Serverless P2P架构的D2，D4在终端本地实现了“IMS Stack（对应IMS服务管理器）”向“不同UI应用”分发通知的机制，公开了特征A、B、C、D、F、G、H，是最理想的创造性分析起点。

### 2. 未被最接近对比文件（D4）公开的特征及其他对比文件的披露情况

通过上述比对，未被最接近对比文件D4公开的特征为：**特征E** 和 **特征I**。

* **关于特征E（操作系统保持独立/隔离）：**

* *其他对比文件披露情况：* **D1、D2、D3均未公开此特征**。D1至D3均未从终端操作系统（OS）对应用进行进程隔离、导致活动应用与新启动应用之间无法感知资源冲突这一“软件架构障碍”的角度来提出技术方案。

* **关于特征I（应用启动其它UI并通过该其它UI获取用户接受/拒绝指令的交互响应闭环）：**

* *其他对比文件披露情况：* **D2公开了此特征**。D2在\[0011\]及\[0040\]中明确公开了接收端在收到通知后，启动/运行相应的计算应用（如P2P协作应用或信使应用），并在该应用界面上为用户提供“接受、拒绝或忽略”的显式选项，用户做出选择后应用再向发起源做出接受或拒绝的响应。

---

## 五、 结论：无效宣告请求方最薄弱的技术特征

作为无效宣告请求方（即试图推翻该专利的一方），在针对权利要求1进行创造性攻击时，**最薄弱的技术特征（即最难被攻破、专利权人最稳固的防线）是：特征E**。

### 深度原因分析：

1. **技术盲区（特征E的独特性）：**

特征E限定了“*所述进行中的多媒体通信服务和所述其它多媒体通信服务通过操作系统来保持独立*”。结合目标专利说明书\[0009\]-\[0011\]可知，本发明的发明高度恰恰在于解决了“现代智能手机操作系统（如Android/iOS）为了安全对第三方App进行沙盒隔离，导致App之间无法感知对方的资源占用，从而在IMS多媒体请求交替时引发硬件争抢（如麦克风/屏幕冲突）”这一特有矛盾。现有的IMS标准文件（如D1、D4）普遍是从网络侧信令（SIP/IARI）或IMS公共协议栈的分发能力来考虑问题的，默认认为终端内部是统一受控的，**完全忽略了本地操作系统层面的应用隔离所带来的协同故障**。在现有技术（D1\~D4）均未提及“操作系统隔离”这一技术障碍的情况下，请求方极难通过常规的结合将特征E论证为“本领域普通技术人员的公知常识或显而易见的选择”。

2. **特征I的防御力稍逊（可被D4+D2组合尝试攻破）：**

虽然D4本身没有明确公开特征I中“启动UI并获取接受/拒绝指令”的详细交互，但D2（US8036140B2）在P2P应用邀请领域已经非常明确地公开了“接收端唤醒相应应用UI并弹出‘接受/拒绝/忽略’供用户选择”的完整闭环。请求方可以尝试以D4为最接近的现有技术，结合D2关于用户交互界面的披露，来论证特征I属于显而易见的结合。

### 请求方应对策略建议：

由于**特征E**是防御体系中最坚固的堡垒，无效请求方若想成功，**不能**仅仅依靠目前的D1\~D4标准通信文献。**建议请求方立即扩大检索范围，补充检索“操作系统内核”、“移动终端沙盒隔离机制”或“智能手机音频/视频硬件资源统一调度管理器”相关的计算机系统架构类专利或技术文献**。只有证明在操作系统应用隔离的前提下，利用底层公共管理服务（如本案的IMS服务管理器）跨进程协调应用资源是移动软件开发领域的通用手段，才有可能彻底瓦解特征E的创造性防线。

根据权利要求1所述的方法，还包括响应于所获得的指示应当接受所述建立其它多媒体通信服务的请求的用户指令而接受所述其它多媒体通信服务；其中，接受所述其它多媒体通信服务包括：发起(S108a)所述进行中的多媒体通信服务的暂停过程；以及激活(S108b)所述其它多媒体通信服务。

根据权利要求1所述的方法，还包括响应于所获得的指示应当拒绝所述建立其它多媒体通信服务的请求的用户指令而拒绝所述其它多媒体通信服务；其中，拒绝所述其它多媒体通信服务包括：继续进行(S110a)所述进行中的多媒体通信服务；以及拒绝(S110b)接受所述其它多媒体通信服务。

根据权利要求1所述的方法，其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务中的一个是用于在所述UE上执行第一多媒体类型的多媒体服务的默认应用(24)。

根据权利要求1所述的方法，其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务二者是用于在所述UE上执行第一多媒体类型的多媒体服务的非默认应用(25a、25b)。

根据权利要求1所述的方法，其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务使用所述UE的默认因特网协议多媒体子系统“IMS”通信服务。

根据权利要求4所述的方法，其中，所述默认IMS通信服务负责传送应用命令和所述第一多媒体类型的多媒体通信服务的数据。

根据权利要求1所述的方法，其中，所述进行中的多媒体通信服务和所述其它多媒体通信服务中的至少一个与IMS应用参考标识符“IARI”相关联。