用于从第一终端发送第一多媒体流并且在第二终端接收第二多媒体流的方法，其中第一和第二终端被连接到至少一个网关以使能第一多媒体流的发送和第二多媒体流的接收；该方法包括步骤；所述第一终端使用第一协议启动在第一终端和网关之间的第一多媒体会话信息的交换；使用第二协议提供触发到第二终端；以启动在第二终端和网关之间的第二多媒体会话信息的交换；响应于提供所述触发；第二终端使用第三协议启动在第二终端和网关之间的第二多媒体会话信息的交换；第三协议不同于第二协议；从第一终端发送第一多媒体流并且在第二终端接收第二多媒体流。

## 一、 权利要求拆解与对比文件技术特征比对

### 1.1 权利要求1的技术特征拆解

* **技术特征A**：第一和第二终端被连接到至少一个网关以使能第一多媒体流的发送和第二多媒体流的接收；

* **技术特征B**：所述第一终端使用第一协议启动在第一终端和网关之间的第一多媒体会话信息的交换；

* **技术特征C**：使用第二协议提供触发到第二终端；

* **技术特征D**：以启动在第二终端和网关之间的第二多媒体会话信息的交换；

* **技术特征E**：响应于提供所述触发；

* **技术特征F**：第二终端使用第三协议启动在第二终端和网关之间的第二多媒体会话信息的交换；

* **技术特征G**：第三协议不同于第二协议；

* **技术特征H**：从第一终端发送第一多媒体流并且在第二终端接收第二多媒体流。

---

### 1.2 比对结果与详细出处映射表

---

## 二、 最接近对比文件的选择与技术效果分析

### 2.1 最接近对比文件（可以有多个）

在本案中，**D2（CN1947401A）** 与 **D3（CN1976346A）** 均非常适合作为最接近的对比文件（最接近对比文件可为双核心）：

1. **选择 D2（CN1947401A） 作为最接近对比文件的理由：**

* **技术领域与应用场景的高度重合**：D2 与本专利均属于网络通信领域中“通过中间网关/代理触发非活跃/被动终端建立多媒体/SIP会话”的技术。

* **核心发明构思完全一致**：D2 的核心目的在于解决位于网关（NAT/FW）后方的终端无法直接被外部发起端寻址的问题。D2 明确揭示了：主叫发起请求 $\rightarrow$ 网关/代理向被叫发送**非IP的触发信令（如 SMS/WAP Push，对应第二协议）** $\rightarrow$ 被叫响应触发后使用**SIP协议（对应第三协议）**向网关重新注册/启动会话信息交换。

* **特征覆盖度极高**：D2 完整公开了特征 A、B、C、D、E、F、G、H 的绝大部分或全部细节。

2. **选择 D3（CN1976346A） 作为最接近对比文件的理由：**

* **业务应用层面的高度吻合**：D3 针对视频共享（流媒体传输）业务，主叫发送视频共享请求，应用服务器发现被叫未注册（休眠/未激活），通过 **短消息（SMS，第二协议）** 触发被叫终端激活 GPRS 连接并使用 **SIP 协议（第三协议）** 进行 IMS 注册和媒体协商，最后建立 RTP 链路传输多媒体流。

* **技术效果的一致性**：D3 与本发明均解决了移动终端无需时刻保持高功耗在线状态，仅在被触发时才启动会话连接，从而节省网络资源和终端能耗的技术问题。

---

## 三、 创造性与最薄弱技术特征分析

### 3.1 未被最接近对比文件公开的技术特征与薄弱点识别

经比对分析，本专利权利要求1在与 D2 或 D3 进行比对时，**最薄弱的技术特征**集中在：

> **特征G**：“第三协议不同于第二协议” 在 **流式传输/媒体流交互架构下的特定协同**，以及 **“网关”的具体定义与双向/单向流控制**。

1. **关于“第三协议不同于第二协议”（特征G）**：

* 在 D2 与 D3 中，虽然客观上存在“触发信令（SMS）”与“会话信令（SIP）”的区别，但在某些专利审查语境下，专利权人可能会争辩：本专利中的“网关（Gateway）”在第一多媒体流与第二多媒体流传输过程中承担了特定的多媒体协议转换或媒介流转作用（例如第一协议为 RTSP/SIP，第二协议为 WAP Push/SMS，第三协议为 RTSP/HTTP）。

* 若专利权人将“网关”限定为特定硬件流媒体网关而非通用 SIP 代理/应用服务器，则属于对比文件公开不够绝对的“游离特征”。

2. **为什么这是无效请求中最薄弱（即专利权人最企图据守）的防御特征？**

* 权利要求1的撰写非常宽泛（仅限定了“第一协议”、“第二协议”、“第三协议”，以及“网关”）。

* 专利权人可能会反驳：D2 中的网关是 NAT/FW/SIP 代理，仅仅传递信令，并不直接“使能多媒体流的发送和接收（特征A/H）”；而 D1 虽涉及流媒体网关，但其协议触发逻辑与 D2/D3 存在小幅差异。

### 3.2 对比文件组合的无效逻辑（公知常识与结合意图）

* **组合方案 1（以 D2 为主对比文件 + D1/通用技术手册）**：

* **主攻点**：D2 已完全公开了“主叫触发 $\rightarrow$ 网关用第二协议（SMS/WAP Push）触发被叫 $\rightarrow$ 被叫用第三协议（SIP）响应并建立会话”的全流程（特征 B, C, D, E, F, G）。

* **补强点**：对于多媒体流的实际传输（特征 A, H），引入 D1（MMS/流媒体服务器架构）或本领域公知常识（通过媒体网关转换/转发 RTP 流）是本领域技术人员为了实现多媒体流传输而必然采取的技术手段。

* **组合方案 2（以 D3 为主对比文件 + D1/D2）**：

* **主攻点**：D3 揭示了视频共享中通过短消息（第二协议）触发被叫终端进行 GPRS 激活与 IMS 注册（第三协议为 SIP）并最终通过 RTP 链路传输视频流（特征 A-H 全覆盖）。

* **辅助点**：若针对网关的协议转换有微小差异，结合 D2 关于网关/代理在 NAT 穿透下的触发机制即可完成销号。

---

## 四、 进一步的对比文件检索策略

为了在专利无效宣告请求中达到“击穿”权利要求1乃至全部从属权利要求的目的，建议采取以下针对性的检索策略：

### 4.1 核心检索要素（CPC/IPC 分类号与关键词组合）

1. **IPC/CPC 分类号检索**：

* `H04L65/1016`（IP 多媒体子系统 IMS 中的呼叫/会话建立）

* `H04L65/1069`（会话发起，例如 SIP 触发）

* `H04L67/54`（基于存在或状态信息的服务提供，如 Push 触发）

* `H04W88/16`（移动通信网关）

* `H04L65/65`（流媒体传输控制协议，如 RTSP/RTP）

2. **关键词逻辑块组合（布尔逻辑）**：

* **块 1（终端与网关）**：`(Terminal OR Client OR "移动终端" OR "用户设备") AND (Gateway OR Proxy OR Server OR "网关" OR "代理")`

* **块 2（协议触发/异构协议）**：`("Trigger" OR "WAP Push" OR "SMS" OR "Out-of-band" OR "别名触发" OR "异质协议" OR "不同协议" OR "第二协议")`

* **块 3（会话启动与流媒体）**：`("Session Initiation" OR "SIP" OR "RTSP" OR "Streaming" OR "多媒体流" OR "媒体协商")`

### 4.2 针对性检索方向与补充文献库建议

1. **针对“异构协议触发（Out-of-band Trigger / Wake-up Protocol）”的标准规范检索**：

* 重点检索 **3GPP / OMA（Open Mobile Alliance）** 的早期标准规范。例如：

* **OMA Push Architecture** / **OMA Push OTA Protocol**（OMA 规范中大量记载了使用 SMS/UDP 作为第二协议发送 Push Message 触发终端启动 HTTP/SIP/RTSP 作为第三协议建立媒体连接的过程）。

* **3GPP TS 23.228**（IMS 架构）及 **3GPP TS 23.140**（MMS 架构）。

* *理由*：标准文献的公开日往往早于专利申请日，且对协议细节（协议 A/B/C 的区分）的描述极其严密，能强力抵消专利权人对“协议不同”的争辩。

2. **针对“NAT 穿透与被动唤醒”专利库深度挖掘**：

* 重点检索 **Qualcomm（高通）、Nokia（诺基亚）、Ericsson（爱立信）、Huawei（华为）** 在 2002–2008 年间申请的关于“SIP Out-of-band Notification”、“NAT Keep-alive Alternative via SMS/Push”相关专利。

3. **从属权利要求的预备检索**：

* 密切关注说明书实施例中是否包含“网关的具体 SDP 参数协商”、“特定媒体编码格式（H.264/AAC）的协商”、“网关作为 B2BUA（背靠背代理）”等技术特征。若专利权人在无效过程中将说明书特征补入权利要求1，需提前准备好涵盖上述特定网关架构的对比文件。

作为一名经验丰富的专利代理师，我将严格紧密结合目标专利的权利要求与说明书，对比分析对比文件（D1: US7231658B2、D2: US20070177616A1、D3: US20070201484A1）的原文内容，为您提供系统、严谨的专利无效分析与检索策略。

---

### 一、 权利要求特征分解与技术特征对比表格

根据目标专利权利要求1，将其技术特征分解为特征A~H。下表梳理了各对比文件对权利要求1技术特征的公开情况及详细出处：

#### 权利要求1特征比对表格

---

### 二、 对比文件详细公开情况分析（结合原文）

#### 1. D1: US7231658B2

* **公开的技术特征**：

* **特征A、B、D、F、H**：D1公开了一种在发送端与接收端之间通过网关/中继/缓存进行多媒体数据传输的系统。具体地，段落[0098]与[0104]公开了第一终端（terminal A）使用第一协议（SIP协议中的INVITE消息）启动在第一终端和网关（POB server/transmitting-end cache）之间的第一多媒体会话信息交换（**特征A、B**）；段落[0166]和[0228]公开了第一终端发送多媒体流，接收端缓存（receiving-end cache）接收并在第二终端（terminal B）播放（**特征H**）；段落[0227]、[0265]公开了第二终端使用协议（如RTSP/HTTP或SIP）启动与网关/接收端缓存之间的第二多媒体会话信息交换（**特征D、F**）。

* **未公开/未完全公开的特征**：

* **特征C、E、G**：D1中接收端缓存接收到数据后，通过电子邮件通知第二终端（段落[0225]）。虽然存在“通知”，但D1未明确限定使用专用的“第二协议”来发送“触发”，且没有明确形成“第三协议不同于第二协议”（**特征G**）的架构组合。

#### 2. D2: US20070177616A1

* **公开的技术特征**：

* **特征A、B、D、H**：D2公开了一种交互式多媒体交换架构。段落[0071]-[0072]及图1公开了终端通过Video Gateway 132及Media Server 134传输和接收多媒体流（**特征A、H**）；段落[0109]公开了3G终端使用3G-324M或SIP协议向多媒体交换服务器发起呼叫/会话请求（**特征B**）；段落[0085]公开了服务器通过SMS/Email通知第二终端，或者直接向第二终端呼出以提供媒体内容（**特征D**）。

* **未公开/未完全公开的特征**：

* **特征C、E、F、G**：D2虽然提到了通过SMS/Email通知（Push）第二终端，但其核心机制是服务器主动向第二终端拨号（Call out）或者第二终端通过普通Web/FTP下载，未能明确揭示第二终端响应于特定的“第二协议触发”后，主动使用“不同于第二协议的第三协议”来启动与网关的会话信息交换。

#### 3. D3: US20070201484A1

* **公开的技术特征**：

* **特征A、B、D、F、H**：D3主要针对通道型协议（如3G-324M、SIP、H.323）中的个性化媒体/视频彩铃传输。图3A及段落[0100]公开了第一终端（TOC 110）与第二终端（TTC 190）通过中间代理/网关（B2BUA 360）进行连接（**特征A**）；段落[0107]公开了TOC使用Q.931/H.245发送SETUP消息建立会话（**特征B**）；段落[0115]公开了网关向TTC发送SETUP消息，TTC响应CONNECT建立会话（**特征D、F、H**）。

* **未公开/未完全公开的特征**：

* **特征C、E、G**：D3中的网关到第二终端的呼叫建立属于标准的双向/单向呼叫信令过程（网关向TTC发SETUP），并不属于使用“第二协议”提供“触发”以诱导第二终端主动用“第三协议”启动会话的机制。

---

### 三、 最接近对比文件的选择与创造性分析

#### 1. 总体解决的技术问题与技术效果分析

* **目标专利解决的技术问题**：在异构网络或不同终端环境下，如何高效、灵活地在第一终端与第二终端之间建立多媒体流会话，特别是如何通过网关解耦两端的会话建立过程，利用轻量级/特定的“触发协议”通知第二终端，再由第二终端使用适合的“会话协议”主动与网关建立媒体会话。

* **各对比文件的侧重点**：

* **D1 (US7231658B2)**：侧重于通过中继/缓存（Cache）和PBOX服务器解耦大容量多媒体数据传输，解决直接传输对网络和终端造成的负载过大及安全验证问题。其技术架构与目标专利**最为接近**（即：终端1 -> 网关/缓存 -> 触发/通知 -> 终端2主动连接网关/缓存获取流）。

* **D2 (US20070177616A1)**：侧重于多媒体交换服务器（MEA）对媒体流的转码、存储与跨网络（如3G与IP网）共享。

* **D3 (US20070201484A1)**：侧重于在呼叫建立阶段（彩铃阶段）由B2BUA网关向主叫方插入个性化视频流。

#### 2. 最接近对比文件的确定

* **最接近的对比文件**：**D1 (US7231658B2)**。

* **理由**：D1不仅公开了网关/缓存架构，更重要的是公开了“第一终端将媒体上传至网关缓存 -> 网关/服务器通知第二终端 -> 第二终端主动向网关/缓存发起会话连接以接收多媒体流”的整体业务工作流。这与本专利的架构和技术路线高度吻合。

#### 3. 区别技术特征及其他对比文件的组合分析

* **区别技术特征**：

* 特征C、E、G的组合，即：**使用“第二协议”提供“触发”给第二终端，第二终端“响应于该触发”，使用与第二协议不同的“第三协议”启动与网关的会话信息交换**。

* **其他对比文件是否公开**：

* **D2/D3** 均未明确公开“使用第二协议发送触发，第二终端据此改用不同于第二协议的第三协议启动会话”这一明确的技术特征组合。D2仅提到了SMS/Email通知，但未将其作为协议层面的触发机制与后续会话协议（如RTSP/SIP）形成异构协议协同架构。

---

### 四、 无效请求中最薄弱的技术特征与法律风险评估

在针对本专利提起无效宣告请求时，**最薄弱（即专利权人最容易用来防御、最难被单篇对比文件直接击中）的技术特征**是：

> **“使用第二协议提供触发到第二终端……响应于提供所述触发；第二终端使用第三协议启动在第二终端和网关之间的第二多媒体会话信息的交换；第三协议不同于第二协议”（特征C + 特征E + 特征F + 特征G 的结合）**

#### 为什么该特征最薄弱（对无效发起方而言的难点）：

1. **显式的协议异构触发架构**：权利要求1明确限定了“第二协议”（用于触发）与“第三协议”（用于会话信息交换）必须**不同**（特征G）。

2. **现有技术的习惯教导**：

* 在传统通信协议（如D3）中，网关与第二终端之间通常使用同一种信令协议（如SIP或H.324）贯穿呼叫建立和会话协商过程。

* 在存储转发/异步通知模式（如D1、D2）中，虽然提到了Email或SMS通知，但通常将其视为应用层消息或业务层通知，而非在协议栈层面明确定义的“第二协议触发 -> 响应后启动第三协议会话”的协议协同机制。

---

### 五、 进一步的对比文件检索策略

为了攻克上述“最薄弱的技术特征”（第二协议触发 + 第三协议异构会话），建议采取以下补充检索策略：

#### 1. 扩展检索主题与技术领域

* **Push Notification与SIP/RTSP结合机制**：重点检索在Push Notification（推送通知协议，如WAP Push、SIP NOTIFY、OMA Push、Apple APNs/Google C2DM早期草案）发展初期的专利文献。

* **IMS/SIP 早期规范与3GPP标准草案**：检索3GPP关于“Out-of-band signaling”、“Session Triggering”、“SIP NOTIFY / REFER for Session Initiation”的相关标准提案（TDoc）。

#### 2. 核心检索要素（Keywords & Classifications）

* **关键词组合**：

* `(trigger* OR push OR notification OR "WAP push" OR "SIP NOTIFY")`

* `AND (gateway OR proxy OR "B2BUA" OR server)`

* `AND ("different protocol" OR "second protocol" OR heterogen*)`

* `AND (session OR "media stream" OR RTSP OR SIP OR SDP)`

* **IPC/CPC 分类号**：

* `H04L65/1016`（IP多媒体子系统IMS会话建立）

* `H04L65/1069`（会话协商与会话触发）

* `H04L67/55`（推送技术Push-based services）

* `H04W4/12`（移动消息/通知服务）

#### 3. 推荐的组合无效逻辑架构

* **主对比文件**：**D1 (US7231658B2)**（提供网关/缓存解耦传输多媒体的基本架构及通知流程）。

* **辅对比文件（待检索目标）**：找一篇明确公开“使用第一协议/消息（如WAP Push或SIP NOTIFY）作为轻量级Trigger，终端接收到Trigger后触发本地客户端使用第二协议（如RTSP/HTTP/SIP）向服务器建立多媒体会话”的技术文献。

* **结合逻辑**：本领域技术人员在D1的基础上，为了提高通知的实时性与终端响应效率，结合辅对比文件教导的“Push Trigger - Session Setup”异构协议触发机制，显而易见地将其应用到D1的网关与第二终端之间，从而得出权利要求1的技术方案，不具备创造性（符合《专利审查指南》第四部分第六章关于显而易见性的评述）。

作为一名经验丰富的专利代理师，我紧密结合目标专利（即权利要求1所对应的发明构思）与说明书上下文，对权利要求1进行法律与技术层面的深度剖析，并结合两篇对比文件（D1与D2）进行特征对比、最接近对比文件分析、薄弱特征定位及后续检索策略制定。

---

### 一、 权利要求1的技术特征拆解与目标专利说明书解释

根据本领域的通常理解及目标专利（发明构思）的上下文，权利要求1旨在解决**“不同协议域/客户端类型之间（如SIP与RTSP，或Peer-to-Peer与Client-Server协议）多媒体会话建立与流传输”**的技术问题。

* **技术特征A**：`其中第一和第二终端被连接到至少一个网关以使能第一多媒体流的发送和第二多媒体流的接收`

* **说明书解释**：网关（Gateway）作为中间桥梁/代理，用于连接采用不同协议域的第一终端（发送端，如SIP客户端）与第二终端（接收端，如RTSP客户端），使得第一终端发送的流能被第二终端关联接收。

* **技术特征B**：`所述第一终端使用第一协议启动在第一终端和网关之间的第一多媒体会话信息的交换`

* **说明书解释**：第一终端主动（例如使用SIP协议的SIP INVITE）向网关发起会话协商，提交第一多媒体会话信息（如SDP描述、媒体格式、端口等）。

* **技术特征C**：`使用第二协议提供触发到第二终端`

* **说明书解释**：由于第二终端使用的接收协议（如RTSP）通常只能由客户端主动发起，无法直接响应第一终端的邀请，因此需要使用第二协议（如SIP Content Indirection、SMS、Push消息或内部通知/API）向第二终端发送一个“触发（Trigger）”或通知，告知其有可用的媒体流。

* **技术特征D**：`以启动在第二终端和网关之间的第二多媒体会话信息的交换`

* **说明书解释**：触发的目的在于激活第二终端，促使其主动向网关发起第二多媒体会话的建立与参数协商。

* **技术特征E**：`响应于提供所述触发`

* **说明书解释**：第二终端在接收到上述触发信号后，以此为因果条件做出响应动作。

* **技术特征F**：`第二终端使用第三协议启动在第二终端和网关之间的第二多媒体会话信息的交换`

* **说明书解释**：第二终端作为客户端，使用第三协议（如RTSP协议的DESCRIBE/SETUP/PLAY）向作为服务端的网关发起会话信息交换。

* **技术特征G**：`第三协议不同于第二协议`

* **说明书解释**：用于“触发”第二终端的协议（第二协议）与第二终端实际用于与网关建立/控制媒体会话的协议（第三协议）是不同的协议（例如第二协议为SIP/SMS/Internal Msg，第三协议为RTSP）。

* **技术特征H**：`从第一终端发送第一多媒体流并且在第二终端接收第二多媒体流`

* **说明书解释**：在两端会话信息均协商完毕后，第一终端发出第一媒体流（如RTP流），通过网关/网络路由，第二终端接收对应的第二媒体流（关联流或同一流）。

---

### 二、 对比文件公开情况分析及特征比对表

#### 1. 对比文件指代与公开号对应

* **对比文件1（D1）**：`USRE50541E1` （Title: Method and system for transmitting a multimedia stream）

* **对比文件2（D2）**：`WO2007071461A1` （Title: METHOD FOR ESTABLISHING A UNICAST MEDIA SESSION）

---

#### 2. D1（USRE50541E1）公开情况分析

* **技术特征A**：**公开**。D1段落`[0012]`、`[0017]`、`[0036]`明确记载第一终端（SIP Client）、第二终端（RTSP Client）连接到至少一个网关（SIP-RTSP Gateway），以使能媒体流的发送与接收。

* **技术特征B**：**公开**。D1段落`[0012]`、`[0101]`明确记载第一终端使用第一协议（SIP协议，发送SIP INVITE）启动在第一终端与网关之间第一多媒体会话信息（SDP）的交换。

* **技术特征C**：**公开**。D1段落`[0012]`、`[0018]`、`[0019]`、`[0103]`、`[0104]`明确记载网关使用第二协议（如SIP Content Indirection、SMS、USSD或API等）向第二终端提供Trigger（触发）。

* **技术特征D与E**：**公开**。D1段落`[0012]`、`[0018]`、`[0103]`明确记载触发的目的与因果关系：响应于所述Trigger，促使第二终端启动与网关之间的第二多媒体会话信息交换。

* **技术特征F**：**公开**。D1段落`[0012]`、`[0017]`、`[0106]`明确记载第二终端使用第三协议（RTSP）启动与网关（作RTSP Server）之间的第二多媒体会话信息的交换。

* **技术特征G**：**公开**。D1段落`[0012]`、`[0018]`明确指出第二协议（用于Trigger的协议，如SIP/SMS/API）不同于第三协议（RTSP）。

* **技术特征H**：**公开**。D1段落`[0012]`、`[0107]`记载从第一终端发送RTP多媒体流并在第二终端接收关联的第二多媒体流。

> **结论**：**D1（USRE50541E1）已全面、毫无异议地（或实质上）完全公开了权利要求1的所有技术特征（A~H）。**

---

#### 3. D2（WO2007071461A1）公开情况分析

* **技术特征A**：**公开**。D2在“RTSP session setup”实施例（说明书第11-13页及图3）中记载了用户设备UE 109、机顶盒STB 108、IPTV应用服务器IPTV AS以及流媒体服务器SS。其中STB 108和SS通过网关（RGW/HIGA/IPTV AS等）连接进行流媒体传输。

* **技术特征B**：**公开/实质公开**。D2图3步骤4记载IPTV AS（或UE 109通过AS）使用第一协议（SIP，发送SIP INVITE）向STB 108启动会话信息交换（包含RTSP URL及媒体描述）。

* **技术特征C**：**实质公开/差异点**。在D2图3中，IPTV AS向STB 108发送SIP INVITE（步骤4），STB内部控制逻辑（Control Logic）收到后，通过内部消息/协议（步骤6、12）触发STB内部的RTSP Stack。如果将“IPTV AS发送的SIP INVITE”或“STB内部消息”理解为触发，则公开了使用协议提供Trigger。

* **技术特征D、E、F**：**公开**。D2图3步骤13记载，响应于该触发，STB 108的RTSP Stack使用第三协议（RTSP，发送RTSP SETUP）向服务器/网关启动第二多媒体会话信息的交换。

* **技术特征G**：**公开**。用于触发/邀请的协议（SIP或内部消息协议）与用于会话控制的协议（RTSP）不同。

* **技术特征H**：**公开**。D2图3步骤21记载RTP流从媒体源发送并在STB 108接收。

> **结论**：D2公开了使用SIP与RTSP混合建立多媒体会话的技术方案，但在**“第一终端主动发送流并通过网关触发第二终端”**的逻辑结构上与权利要求1略有偏离（D2侧重于NAT穿透与由用户点播触发IPTV AS向STB下发SIP INVITE）。

---

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

---

### 三、 最接近对比文件的选择与创造性/新颖性分析

#### 1. 整体解决的技术问题与技术效果对比

* **本专利（权利要求1）**：解决在异构网络/不同协议域下，由客户端发起的主动媒体流（如SIP用户生成的直播内容）如何传输给仅具备Client-Server接收能力（如RTSP客户端）的第二终端的问题。技术效果是实现了跨协议域（如SIP到RTSP）的会话自动触发与媒体流接通。

* **D1（USRE50541E1）**：

* *技术问题*：解决用户生成内容（User-Generated Content）从使用对等协议（如SIP）的第一终端传输到仅具有客户端功能（如RTSP Client）的第二终端时，第二终端无法直接响应邀请的问题（参见D1段落`[0008]`-`[0009]`）。

* *技术效果*：通过网关进行协议转换与Trigger触发，使RTSP Client能够被动获知新流并主动建立RTSP会话接收流（参见D1段落`[0012]`、`[0019]`）。

* *匹配度*：**与本专利解决的技术问题、技术方案及技术效果完全一致。**

* **D2（WO2007071461A1）**：

* *技术问题*：主要解决在家庭网络中非IMS/IMS机顶盒在NAT（网络地址转换）穿透环境下的IPTV单播会话建立问题（参见D2摘要及Summary）。

* *技术效果*：实现了NAT Binding的建立与SIP/RTSP协同控制。

#### 2. 最接近对比文件的确定

**D1（USRE50541E1）是首选且绝对最接近的对比文件。**

理由：D1与权利要求1的技术领域完全相同，面对的技术难题完全相同，且**D1公开了权利要求1的所有技术特征（A~H）**。

*注：如果仅考虑新颖性破坏（专利法第22条第2款），直接使用**D1单独破坏权利要求1的新颖性**即可；若进行创造性评估（专利法第22条第3款），D1亦可作为最接近的对比文件结合本领域公知常识直接破坏其创造性。*

---

### 四、 无效请求中最薄弱的技术特征及攻击策略

#### 1. 权利要求1最薄弱的技术特征

若要对本专利发起无效宣告请求，权利要求1中**相对最容易被专利权人用于据理力争或做限缩解释的“薄弱特征”**为：

* **特征C/G（“使用第二协议提供触发到第二终端，且第三协议不同于第二协议”）**

*原因分析*：

在一般的通信流程中，如果直接使用RTSP协议，RTSP协议本身是不具备由Server向Client发起“Unsolicited Trigger/Push”功能的。专利权人通常会主张：“第二协议提供触发”是一个特殊的跨域唤醒机制。

然而，在**D1**中：

1. D1段落`[0018]`、`[0103]`-`[0104]`极其详尽地举例说明了“Trigger”的实现方式（包括SIP Content Indirection RFC 4483、SMS、USSD、SOAP/RPC API等）。

2. D1明确指出第二协议（如SIP/SMS/API）不同于第三协议（RTSP）。

因此，即使专利权人试图将“触发”解释为某种特定的带外信号或特定报文，D1原文的宽泛且精确的记载也已经完全覆盖了该特征。

#### 2. 权利要求1的新颖性/创造性无效结论

* **针对权利要求1**：根据D1（USRE50541E1）段落`[0012]`、`[0017]`-`[0019]`、`[0101]`-`[0107]`，权利要求1的技术特征A~H已全部被D1毫无异议地公开，**权利要求1不具备新颖性（或不具备创造性）**。

---

### 五、 进一步的对比文件检索策略（针对从属权利要求防守与补充）

为防止专利权人在无效宣告过程中通过合并从属权利要求（例如限定“触发”的具体形式为SMS、SIP Content Indirection、或网关具体包含SCF/MF分布架构等）来对抗D1，建议采取以下进一步检索策略：

#### 1. 检索要素提取与表达（Keywords & Classification）

* **核心概念1：异构协议转换/网关（SIP与RTSP网关）**

* *关键词*：`SIP-RTSP gateway`, `SIP to RTSP`, `interworking`, `protocol conversion`

* *IPC/CPC分类号*：`H04L65/1069`（Gateway functions for session handling/protocol conversion）、`H04L65/1016`（SIP interworking）、`H04L65/65`（Media streaming control protocols）

* **核心概念2：带外触发/唤醒机制（Triggering / Push Notification）**

* *关键词*：`trigger`, `content indirection`, `RFC 4483`, `out-of-band notification`, `wake-up`, `push message`

* *IPC/CPC分类号*：`H04L67/55`（Push services）

#### 2. 组合检索策略矩阵

1. **从属特征攻击策略（针对网关架构，如IMS SCF/MF组件）**：

* *检索式*：`(SIP NEAR/3 RTSP) AND (IMS OR "Service Control Function" OR SCF) AND (trigger* OR "content indirection")`

* *目的*：如果专利权人将从属权利要求修改为限制网关分布在IMS网络中的SCF和MF，此检索式可补充ETSI TISPAN或3GPP标准规范类对比文件（如TS 182 027）。

2. **追溯同族与引证/被引（Forward/Backward Citation Search）**：

* 针对 **D1（USRE50541E1）** 及原始专利 **US8825883B2 / EP2073489A1** 进行审查历史（File Wrapper）及引证/被引文献追踪，寻找欧洲专利局（EPO）或美国专利商标局（USPTO）在审查过程中引用的X/Y类对比文件。

3. **标准必要专利/标准草案检索（Standard Documents）**：

* 重点检索 **3GPP** 和 **ETSI TISPAN** 关于 *“IPTV architecture; Support of User Generated Content (UGC)”* 或 *“IMS based IPTV stage 2/3”* 的标准草案（2006-2008年期间），此类标准通常对SIP触发RTSP会话有标准化定义。

作为一名经验丰富的专利代理师，我将紧密结合目标专利说明书的逻辑架构，对权利要求1的技术特征进行剖析，并结合三份对比文件的原文（包括文字段落与公开号）展开严谨的比对、创造性（接近度）分析，以及检索策略研讨。

---

### 一、 目标专利权利要求1的技术特征拆解与说明书逻辑解释

根据多媒体会话建立与控制的架构逻辑，**权利要求1**的技术特征拆解如下：

* **技术特征A**：其中第一和第二终端被连接到至少一个网关以使能第一多媒体流的发送和第二多媒体流的接收；

* **技术特征B**：所述第一终端使用第一协议启动在第一终端和网关之间的第一多媒体会话信息的交换；

* **技术特征C**：使用第二协议提供触发到第二终端；

* **技术特征D**：以启动在第二终端和网关之间的第二多媒体会话信息的交换；

* **技术特征E**：响应于提供所述触发；

* **技术特征F**：第二终端使用第三协议启动在第二终端和网关之间的第二多媒体会话信息的交换；

* **技术特征G**：第三协议不同于第二协议；

* **技术特征H**：从第一终端发送第一多媒体流并且在第二终端接收第二多媒体流。

#### 结合说明书的逻辑解释：

权利要求1的核心在于**跨异构协议/异构网络的多媒体流传输控制与触发机制**。第一终端与第二终端并不直接通过同一种协议完成端到端的协商，而是借助网关（Gateway）作为中间转换或代理节点。

1. **触发与协议分离（特征C、G）**：系统通过“第二协议”向第二终端发送一个通知/触发信号（Trigger）；而第二终端在收到触发后，采用**与第二协议不同的“第三协议”**主动向网关发起会话信息交换（特征F）。这种“触发协议”与“会话建立/媒体传输协议”分离的设计，允许终端在带外（Out-of-band）或特定信令通道被唤醒/触发后，采用专用的多媒体协议与网关建立媒体流会话。

2. **多会话协调（特征B、D、F、H）**：第一终端与网关建立第一会话（第一协议），第二终端与网关建立第二会话（第三协议），网关在中间起到桥接/转换作用，最终实现多媒体流从第一终端通过网关发送并由第二终端接收。

---

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

以下分析中，对比文件分别简称为 **D1**（US6523696B1）、**D2**（US6661785B1）和 **D3**（US20040125757A1）。

#### 1. D1 (US6523696B1) 比对分析

* **公开号**：US6523696B1

* **公开特征分析**：

* **特征A**：公开了第一终端（如发送端1）、第二终端（如接收端6）通过网关（half gateway 3, 4）连接，以传输多媒体流（video data）。*出处：SUMMARY OF THE INVENTION, FIG. 1, FIG. 3 (Step S15-S16)*.

* **特征B**：第一终端使用第一协议（如IEEE 1394/AV/C协议）与网关建立/启动多媒体会话信息交换。*出处：FIG. 3 (Step S8, Step S9: "first AV control terminal 2... reserves the isochronous channel... transmits the FANP message such as the offer message toward the first half gateway 3")*.

* **特征C/D/E/F/G**：D1中第二AV控制终端（5）接收到指示后，通知/命令接收终端（6）通过1394协议接收数据（FIG. 3 Step S12）。然而，D1中**不存在“使用第二协议提供触发，而第二终端响应于触发使用与第二协议不同的第三协议去启动与网关之间的会话”**这一具体逻辑。D1主要是在网关与终端之间进行1394协议与IP/FANP协议的转换，未明确揭示特征C、D、E、F、G的组合结构。

* **特征H**：公开了第一终端发送多媒体流并由第二终端接收。*出处：FIG. 3 (Step S16)*.

#### 2. D2 (US6661785B1) 比对分析

* **公开号**：US6661785B1

* **公开特征分析**：

* **特征A**：公开了PSTN Caller（第一终端）、Subscriber PC（第二终端）通过SSP/H.323 Gateway/SN（网关系统）连接传输语音/多媒体流。*出处：FIG. 1a, SUMMARY OF THE INVENTION*.

* **特征B**：第一终端（PSTN Caller）发起呼叫（PSTN/SS7协议，第一协议），与SSP/SCP网关系统交换会话信息。*出处：SUMMARY OF THE INVENTION ("When the subscriber's line receives a call, the subscriber's SSP sends a termination attempt trigger notification query to the SCP")*.

* **特征C**：SCP响应于PSTN呼叫，使用**第二协议（IP网络上的弹窗通知/Call Notification Message，如TCP/IP）**向Subscriber PC（第二终端）发送呼叫通知/触发（Pop-up window）。*出处：SUMMARY OF THE INVENTION ("In response to the notification query, the SCP sends a call notification message through the internet to the subscriber's PC... displays the call notification message as a 'pop-up' window")*.

* **特征D、E、F、G**：当用户选择“Answer with VoIP”时，Subscriber PC**响应于该触发（特征E）**，使用**第三协议（H.323协议，不同于TCP/IP弹窗通知的第二协议，特征G）**主动发起向H.323 Gateway（网关）的H.323呼叫（特征F），以启动第二多媒体会话信息的交换（特征D）。*出处：SUMMARY OF THE INVENTION ("After sending the 'answer with VOIP' message to the SCP, the subscriber's PC immediately initiates a H.323 call to the H.323 gateway using the H.323 gateway internet address...")*.

* **特征H**：网关桥接后，PSTN Caller（第一终端）发送多媒体流（语音），Subscriber PC（第二终端）接收。*出处：SUMMARY OF THE INVENTION, FIG. 2d (Step 220)*.

#### 3. D3 (US20040125757A1) 比对分析

* **公开号**：US20040125757A1

* **公开特征分析**：

* D3主要涉及在同一/异构网关下使用SIP/SIP-MEX协议或RTSP协议进行流媒体传输与控制。

* **特征A**：公开了客户端（第一/第二实体）通过Gateway（网关）连接传输流媒体。*出处：[0016], [0017], FIG. 2, FIG. 8*.

* **特征B/F/G**：D3揭示了Gateway在RTSP协议与SIP协议之间进行消息映射（Mapping between SIP and RTSP information，[0012]）。例如，RTSP客户端发送DESCRIBE/SETUP（RTSP协议），Gateway映射为SUBSCRIBE/INVITE（SIP协议）发给媒体服务器。

* **缺陷**：D3侧重于网关两侧协议的协议转换与映射，**未揭示通过“第二协议发送触发”，进而促使第二终端“响应触发并使用不同的第三协议主动向网关建立会话”**（特征C、D、E、F、G构成的特定触发交互链路）。

---

### 特征比对表格（Technical Feature Mapping Table）

---

### 三、 最接近对比文件的选择与创造性分析

#### 1. 最接近对比文件的确定

在创造性分析中，**D2 (US6661785B1)** 最适合作为最接近的对比文件。

* **技术领域与整体解决的技术问题匹配度**：

* **目标专利**旨在解决在异构网络/网关环境下，如何通过触发机制协调两个终端与网关建立多媒体会话并传输多媒体流的问题。

* **D2 (US6661785B1)** 正是解决在互联网会话/单电话线环境下，主叫方（PSTN）发起呼叫后，系统如何通过“带外/IP网络”向被叫PC发送触发通知（Pop-up），并由被叫PC响应触发使用VoIP协议（H.323）主动向网关发起呼叫建立媒体会话的问题。技术领域、问题及架构高度重合。

* **技术特征覆盖度**：

* 从特征比对表可以看出，**D2 几乎毫无异议地公开了权利要求1的全部技术特征（A、B、C、D、E、F、G、H）**。

*(注：D1虽然也涉及网关及1394/IP转换，但其核心是集中式/代理控制，缺少“第二协议触发 -> 响应后用不同于第二协议的第三协议主动启动会话”这一核心交互动作；D3侧重于RTSP与SIP的网关转换，同样缺少该触发机制。因此D1和D3均不如D2接近。)*

#### 2. 最接近对比文件（D2）公开情况与未公开特征分析

* 根据上述详细比对，**D2 (US6661785B1) 已经实质公开了权利要求1的全部技术特征**。

* 若将 D2 的网关架构（SSP + SCP + H.323 Gateway + SN 的组合）等同于权利要求1中的“至少一个网关”，则权利要求1**相对于 D2 甚至缺乏新颖性（或创造性极低）**。

---

### 四、 无效宣告请求中最薄弱的技术特征与突破口分析

若针对本目标专利发起无效宣告请求，权利要求1中**最薄弱的技术特征**是：

**“使用第二协议提供触发到第二终端……响应于提供所述触发，第二终端使用第三协议启动在第二终端和网关之间的第二多媒体会话信息的交换；第三协议不同于第二协议”（特征C、D、E、F、G的组合）**。

#### 薄弱原因分析：

1. **概念宽泛**：权利要求1中的“触发”、“第二协议”、“第三协议”写得非常上位和抽象。

2. **已经被现有技术（D2）完全精准击中**：D2中的“IP Pop-up Notification Message”（第二协议）就是“触发”，PC收到弹窗后点击接听（响应触发），使用“H.323协议”（第三协议，且H.323明显不同于TCP/IP弹窗通知协议）向H.323 Gateway发起呼叫（启动会话信息交换）。这与特征C-G的逻辑完全吻合。

---

### 五、 进一步的对比文件检索策略

为了确保无效请求能够一击即中（无论是直接破坏新颖性还是结合破坏创造性），建议采取以下进一步检索策略：

1. **针对“网关/代理触发+异构协议响应”拓展IPC/CPC分类号检索**：

* `H04L65/10`（会话架构与信令）

* `H04L65/1069`（网关或控制节点间交互）

* `H04M3/42`（补充业务，如呼叫等待/通知）

* `H04L67/54`（基于触发/推送的服务）

2. **关键词组合组合策略**：

* `(Gateway OR Proxy OR "Session Border Controller")`

* AND `(Trigger OR Push OR Notification OR Wake-up OR "Pop-up")`

* AND `("First protocol" OR "Second protocol" OR "Out-of-band" OR SIP OR H.323 OR RTSP OR WebRTC)`

* AND `(Initiate OR Establish OR Start OR Launch) NEAR/5 (Session OR Stream OR Media)`

3. **追溯重点技术演进路线（重点检索优先级）**：

* **软交换与IMS架构标准**：检索3GPP / IETF 中关于 Push Notification Service (PNS)、SIP Push-to-Talk (PTT) 或 WebRTC 呼叫推送的早期 RFC/草案（例如利用 Push Notification 唤醒终端，终端再用 SIP/RTSP 连网关）。

* **VoIP Call Waiting (ICW) 专利族延伸**：重点追踪 Lucent, Cisco, Avaya, Microsoft, Nortel 在 1998–2005 年间关于“IP Call Waiting”、“Out-of-band Trigger for VoIP”的专利族，此类文献极易包含完全覆盖特征C-G的方案。

作为一名经验丰富的专利代理师，我针对目标专利《权利要求1》以及提供的三份对比文件（D1: US20040184432A1、D2: US06895439B2、D3: CN1630368A）进行深度法律与技术比对分析。

---

## 一、 权利要求技术特征拆解与说明书解构

结合目标专利（及同类多媒体会话控制与触发架构）的技术背景，权利要求1的核心逻辑在于**“第三方触发/异构协议会话建立”**：通过第一终端使用“第一协议”与网关建立会话，向第二终端发出包含“第二协议”的触发，从而驱动第二终端使用与第二协议不同的“第三协议”与网关建立多媒体会话，最终实现跨终端的多媒体流传输。

* **技术特征 A**：`其中第一和第二终端被连接到至少一个网关以使能第一多媒体流的发送和第二多媒体流的接收`

* *说明书解释*：第一终端（UE1）与第二终端（UE2）通过网络架构中的网关节点（如GGSN/SGSN或媒体网关）进行连接，确保控制信令与媒体流的通路传输。

* **技术特征 B**：`所述第一终端使用第一协议启动在第一终端和网关之间的第一多媒体会话信息的交换`

* *说明书解释*：第一终端采用控制/会话协议（如SIP协议）与网关/服务器进行会话协商与描述信息交换。

* **技术特征 C**：`使用第二协议提供触发到第二终端`

* *说明书解释*：通过特定协议（例如WAP Push、SMS或应用层通知协议等“第二协议”）向第二终端推送触发指令。

* **技术特征 D**：`以启动在第二终端和网关之间的第二多媒体会话信息的交换`

* *说明书解释*：触发的目的在于指示第二终端主动与网关建立其自身的会话信息交互。

* **技术特征 E**：`响应于提供所述触发`

* *说明书解释*：第二终端接收到触发信号后，被动或自动激活后续的会话建立流程。

* **技术特征 F**：`第二终端使用第三协议启动在第二终端和网关之间的第二多媒体会话信息的交换`

* *说明书解释*：第二终端利用具体的多媒体传输/控制协议（如RTSP协议或HTTP协议等“第三协议”）与网关或服务器进行媒体会话参数建立。

* **技术特征 G**：`第三协议不同于第二协议`

* *说明书解释*：第二终端接收触发的协议（第二协议）与后续建立媒体会话的协议（第三协议）在协议栈或功能上属于不同协议（如采用SMS/WAP Push触发，而采用RTSP/RTP传输流）。

* **技术特征 H**：`从第一终端发送第一多媒体流并且在第二终端接收第二多媒体流`

* *说明书解释*：第一终端作为源端/控制端发流，第二终端作为接收端收流（或通过网络业务平台实现端到端流媒体推拉）。

---

## 二、 对比文件技术特征比对表格

以下为各对比文件针对权利要求1各技术特征的公开情况比对表（含对比文件公开号及原文出处）：

---

## 三、 最接近对比文件选择与整体技术问题/效果分析

### 1. 最接近对比文件的筛选分析

* **D1 (US20040184432A1)**：

* **技术领域**：基于通信网络（IMS/GPRS）的流媒体服务控制。

* **整体解决的技术问题**：解决透明流媒体业务（如RTSP）无法被网络运营商（IMS）有效控制、授权与计费的问题。

* **核心方案**：UE利用SIP（第一协议）发送INVITE，应用服务器（AS）代表UE与流服务器（SS）使用RTSP/HTTP进行协商，生成授权Token给GGSN网关，之后UE直接用RTSP PLAY获取媒体流。

* **缺点**：仅针对**单一终端**（UE）申请流媒体的场景，完全缺乏“第一终端触发第二终端”以及“第二终端利用不同协议（第三协议）重新建立会话”的双终端协作逻辑。

* **D2 (US06895439B2)**：

* **技术领域**：基于3GPP IMS的多协议应用鉴权。

* **整体解决的技术问题**：解决多协议（SIP、HTTP、RTSP）业务下各代理重复鉴权的问题。

* **缺点**：同样基于单终端架构，未涉及双终端间跨协议触发与会话建立。

* **D3 (CN1630368A)**：

* **技术领域**：交互式数字电视广播系统及终端间内容共享。

* **整体解决的技术问题**：解决传统iDTV系统中，用户无法跨终端主动选择和共享其他用户（多终端环境）提供的个人多媒体内容（电影、视频流、图片）的技术问题。

* **核心方案**：架构明确涵盖多用户单元（SU1为第二终端，SU2为第一终端）。SU2将多媒体内容/流共享至网络；系统通过带外交互通道（第二协议）向SU1推送/建议触发；SU1响应触发后，使用交互/流传输协议（第三协议）从网络/网关拉取并接收来自SU2的多媒体流。

### 2. 结论：最接近对比文件的确定

**D3 (CN1630368A) 最适合作为最接近的对比文件。**

* **原因**：D3在**整体技术架构**（多终端业务、第一终端提供/发送流、第二终端接收流）、**应用场景**（交互式多媒体共享）以及**核心触发动作**（带外推送触发与响应拉取）上与本专利最为贴近。本专利要解决的整体技术问题是“如何在多终端架构下实现跨终端的异构协议触发与多媒体会话建立”，这与D3的“多终端交互式广播与个人内容共享”高度重合。

*(注：若审查员/发起方侧重于IMS网络下基于SIP/RTSP的具体网关信令控制，**D1**也可被作为备选的“最接近对比文件”，用于组合D3。因此，本案具备**D3为主**或**D1为主**的双重组合路径。)*

---

## 四、 未被最接近对比文件公开特征的显而易见性与最薄弱特征分析

假设以 **D3** 作为最接近对比文件：

### 1. 未被D3完全公开（或存在争议）的技术特征

* **特征 B、G 的部分协议细节**：D3虽然公开了“通过带外通道进行推送（触发）”以及“机顶盒拉取内容”，但对“第一协议、第二协议、第三协议”三者在网络协议栈上的明确区分（例如：明确规定第一协议为SIP，第二协议为WAP Push/SMS，第三协议为RTSP/HTTP）未做极度详尽的文字定义。

### 2. 结合 D1/D2 的结合性分析

* **特征 B、F、G 的结合**：D1 (US20040184432A1) 在 `[0047]-[0064]` 中极其详尽地公开了在网关架构下，使用 **SIP（第一协议）** 进行会话建立，并使用与触发协议不同的 **RTSP/HTTP（第三协议）** 进行媒体流会话控制。

* 将 D1 的 IMS/SIP/RTSP 协议组合手段应用到 D3 的多终端共享系统中，对于本领域技术人员（POSITA）而言是**显而易见的**。

### 3. 本专利“最薄弱的技术特征”

本权利要求1在无效宣告程序中最薄弱的技术特征是：

> **特征 G：`第三协议不同于第二协议` 结合 特征 C、E、F 的“触发-响应”机制**

* **薄弱原因**：

1. 在通信和网络领域，**“带外触发（Out-of-band Trigger）”** 属于公知常识（如使用短消息SMS/WAP Push作为第二协议进行通知，终端收到后再以HTTP/RTSP作为第三协议建立大带宽连接）。

2. D3已公开了“推送（Push）触发 + 拉取（Pull）接收”的双通道异构模式；D1/D2又彻底公开了在多媒体网关中结合SIP与RTSP/HTTP（即不同协议结合）的架构。

3. 权利要求1对于“第二协议”与“第三协议”的具体作用仅作了极其宽泛的功能性限定（Functional Claiming），未限定任何具体的协议交互细节、字段映射或特定的时序耦合关系，极其容易被现有技术的公知常识及D3+D1的组合击穿。

---

## 五、 进一步的对比文件检索策略（无效检索建议）

为了彻底击退本专利（或巩固无效请求的证据链），建议采取以下进一步检索策略：

### 1. 检索要素表达（Search Elements）

* **主题 A（第一/第二终端与网关/服务器）**：`Terminal`, `User Equipment`, `UE`, `Gateway`, `GGSN`, `IMS`, `Server`

* **主题 B（第三方/跨终端触发）**：`Third-party call control`, `3PCC`, `Trigger`, `Push Notification`, `WAP Push`, `SMS trigger`, `Remote initiation`

* **主题 C（异构/不同协议会话）**：`Different protocol`, `SIP`, `RTSP`, `HTTP`, `Session Description Protocol`, `SDP`

### 2. 结合检索式（CPC/IPC 分类号 + 关键词）

* **重点分类号**：

* `H04L65/1016`（IP多媒体子系统 IMS 中的呼叫/会话控制）

* `H04L65/1069`（会话协商或会话建立协议）

* `H04L65/1089`（第三方呼叫控制 3PCC）

* `H04L67/55`（推送业务 Push Services）

* **推荐布尔检索逻辑**：

* `(3PCC OR "third party call control" OR "third-party call") AND (trigger* OR push*) AND (SIP OR RTSP OR HTTP) AND (gateway OR GGSN)`

* `("WAP push" OR "SMS trigger") AND ("session initiation" OR "streaming session") AND (different protocol)`

### 3. 重点标准文献（3GPP/IETF RFC）检索

本专利的技术特征高度符合 **3GPP IMS 规范中的 3PCC（Third Party Call Control，第三方呼叫控制）** 以及 **IETF RFC 3725**（Best Current Practices for Third Party Call Control in SIP）。

* **检索方向**：建议深入检索 **3GPP TS 23.228**、**3GPP TS 24.229** 以及 **IETF RFC 3725** 及其早期草案（Drafts）。RFC 3725 详细规范了由 Controller（第一终端）发起，通过 Server 触发 Response（第二终端），并使用不同媒体协议（SIP/SDP/RTSP）建立媒体流的过程，该标准文件的公开日若早于本专利优先权日，将是毁灭性的现性技术证据（A类/X类对比文件）。

作为一名资深专利代理师，基于本领域的技术认知以及目标专利（权利要求1）、三份对比文件（D1: US20060039367A1、D2: US07043528B2、D3: US20060128376A1）的说明书原文，为您提供以下严谨的专利法律与技术比对分析及无效检索策略。

---

## 一、 目标专利权利要求1的释义（结合说明书上下文）

权利要求1的核心在于一种**跨不同协议/通信域的多媒体会话建立与流传输方法**。

* **第一终端、第二终端与网关（特征A）：** 构建了典型的“终端-网关-终端”通信拓扑，网关作为中间节点，负责会话控制和媒体流的转发/中继。

* **第一/第二/第三协议的相互关系与作用（特征B~G）：**

* 第一终端通过“第一协议”与网关建立会话；

* 网关/系统采用“第二协议”向第二终端发送“触发（Trigger）”；

* 第二终端响应于该触发，采用与第二协议不同的“第三协议”启动与网关的会话。

* **释义重点：** “触发”扮演了跨协议/跨域激活第二终端的角色。第二协议通常为信令/控制触发协议，而第三协议为具体的会话控制或媒体协商协议（例如，第二协议为短消息/蜂窝信令，第三协议为SIP/IGMP/RTSP等）。

* **多媒体流传输（特征H）：** 第一终端发送第一流，第二终端接收第二流（支持单向流或双向流交互）。

---

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

下面对三份对比文件分别进行技术特征的映射与深度比对，指出其**毫无异议公开（完全公开）**或**实质公开（显而易见/等同替换）**的具体特征及详细出处。

### 1. D1：US20060039367A1 (SIP-based session control)

* **技术方案摘要：** 揭示了一种基于SIP协议和住宅网关（RG）/DSLAM进行准入控制（Admission Control）及多媒体流（如IPTV、点播、组播/单播）传输的方法。

* **特征揭示分析：**

* **特征A：** 公开了多媒体终端（100）经由住宅网关RG（520）/DSLAM（530）连接到内容源/其他终端（[0035]、[0036]、图5-6）。**完全公开。**

* **特征B：** 第一终端使用SIP协议（第一协议）向网关发起会话信息交换（[0038] "communications device 100 communicates an SIP invite... RG receives..."）。**完全公开。**

* **特征C/D/E/F/G（触发及双协议交换）：** D1中RG/网关将SIP Invite转换为IGMP Join（图10、[0047]~[0050]），即在网关侧将SIP协议转换为IGMP协议向网络侧发起组播加入。然而，D1是在**网关与网络侧/内容源**之间进行协议转换，**并非网关向“第二终端”使用第二协议提供触发，进而引发第二终端使用不同的第三协议与网关交换会话信息**。因此，特征C、D、E、F、G在D1中未被公开。

* **特征H：** 发送和接收多媒体流（[0038] Step 620 Media Delivery）。**完全公开。**

### 2. D2：US07043528B2 (Connecting video conferencing to a distributed network)

* **技术方案摘要：** 揭示了将视频会议系统（采用H.323/SIP/H.320标准）连接到分布式网络（采用MMS/RTSP流媒体协议）的技术，通过伪终端（Data Capture Module 190）捕获流并分发给客户端。

* **特征揭示分析：**

* **特征A：** 视频会议终端（190/60）与客户端（210/220）通过流媒体模块/网关（110）连接（[0042]、[0045]、图2）。**完全公开。**

* **特征B：** 会话发起端（例如视频会议终端）采用第一协议（H.323或SIP）与网关/MCU交换会话信息（[0006]、[0042]）。**完全公开。**

* **特征C/D/E/F/G：** 客户端（210/220）通过超链接/URL或MMS/RTSP信令请求媒体流（[0048]~[0049]），网关据此输出流。但这属于标准的客户端主动请求，不包含“网关使用第二协议触发第二终端，第二终端响应触发再用第三协议与网关建立会话”的跨协议触发机制。未公开特征C~G。

* **特征H：** 视频/音频流从发送端传输至接收端客户端（[0042]、[0064]）。**完全公开。**

### 3. D3：US20060128376A1 (Communication systems and methods)

* **技术方案摘要：** 揭示了结合移动通信网络（蜂窝）、短距离无线网络（Bluetooth/Wi-Fi）、固网（PSTN/VoIP）的异构网络互联系统。包含通过网关/基站跨网络触发终端建立会话的机制（例如图13A/13B、图17、即时通讯/语音触发[0140]-[0141]）。

* **特征揭示分析：**

* **特征A：** 远程移动终端RMT（1302/第一终端）与第二终端经由接口电路/网关（1306）连接（[0204]~[0208]、图13A）。**完全公开。**

* **特征B：** RMT使用蜂窝协议/SIP（第一协议）启动与网关/LMT的会话（[0209]）。**完全公开。**

* **特征C：** 网关/接入点使用第二协议（如Bluetooth信令、推送通知或短消息/专有触发信令）向第二终端（如蓝牙手机或局域网终端）发送**触发/通知**（[0140] "plug-in... sends a message to interface circuitry to ring home telephone", [0284] "access point sends an encrypted authentication message/trigger to mobile device"）。**实质公开。**

* **特征D/E/F/G：** 第二终端响应于接收到的触发（特征E），使用与第二协议不同的“第三协议”（例如在蓝牙信令触发后，启动PCM/RTP语音会话协议或VoIP/SIP协议，[0260]-[0265]、[0141]）与网关启动第二多媒体会话信息的交换（特征D、F、G）。**实质公开。**

* **特征H：** 跨网关完成多媒体流（语音/视频）的发送与接收（[0212]、[0225]）。**完全公开。**

---

## 三、 特征比对表格（对照表）

下表详细说明了各对比文件对权利要求1技术特征的公开情况及原文出处：

---

## 四、 创造性分析：最接近的对比文件选择与结合路线

### 1. 最接近对比文件的选择

在评估本专利权利要求1的创造性时，**D3 (US20060128376A1)** 是**最接近的对比文件**。

* **理由分析：**

* **技术领域与解决的问题：** 本专利旨在解决“如何在异构网络/不同终端间通过网关高效建立多媒体会话及流传输”的技术问题。D3同样立足于异构网络（蜂窝网、局域网/蓝牙、PSTN/VoIP），旨在解决移动终端通过网关/基站进行跨网多媒体/语音会话建立和流转发的问题，技术领域和整体解决的技术问题高度一致。

* **技术特征覆盖度：** 如比对表所示，D1和D2仅公开了传统的“终端-网关”单侧SIP/H.323会话建立与流分发，完全缺失了**“使用第二协议提供触发 $\rightarrow$ 第二终端响应触发 $\rightarrow$ 使用不同的第三协议建立会话”**（特征C~G）这一核心逻辑链条。而D3完整覆盖了异构拓扑，并实质公开了跨协议触发和会话建立全过程。

*(注：D1也可作为次要的备选最接近对比文件，用于构建以IPTV/网关准入控制为背景的结合路线，但其技术距离较D3更远)*。

### 2. 创造性攻击路线设计（以 D3 为主对比文件）

* **路线一：基于 D3 独立证明破坏创造性（或 D3 + 本领域普通技术知识）**

* **起步：** D3公开了特征A、B、C、D、E、F、G、H的大部分或全部要素。

* **区别特征（若审查员/专利权人主张狭义理解）：** 专利权人可能会争辩D3中的“触发”是否严格对应于第二协议，以及第二终端建立会话的协议是否严格区别于触发协议。

* **显而易见性论述：** 在D3揭示的网络拓扑中（例如蓝牙/Wi-Fi接入点与移动终端），利用带外信令/控制协议（第二协议，如控制PDU或寻呼信令）先行唤醒/触发终端，终端接收后再调用带内媒体会话协议（第三协议，如RTP/SIP/PCM流协议）与网关建立媒体会话，属于本领域技术人员为了解决“降低终端待机功耗、优化信令开销”而采取的**公知常识和常规技术手段**。

* **路线二：D3 与 D1 / D2 的结合**

* 如果将D1或D2作为主对比文件（提供了典型的“网关-SIP多媒体会话”架构，公开了特征A、B、H），其与目标专利的区别特征在于特征C~G（跨协议触发建立会话）。

* **结合动力：** D3明确给出了“在网关与终端之间采用第二协议发送触发通知，从而引导终端采用第三协议发起多媒体会话”的技术教导。本领域技术人员在面对D1/D2如何实现对异构/移动终端的动态唤醒与会话建立这一技术问题时，有明确的动力引入D3的技术方案，将D3的触发机制组合到D1/D2的系统架构中，从而得到权利要求1的全部技术特征。

---

## 五、 无效请求中最薄弱的技术特征分析

在提出无效宣告请求时，本专利权利要求1中**最薄弱（即专利权人最容易用来防守、但也最容易被攻击）的技术特征**是：

> **“使用第二协议提供触发到第二终端... 第二终端使用第三协议启动... 第三协议不同于第二协议”（特征C、F、G的组合）**

### 薄弱性解析与防守/攻击要点：

1. **防守点（专利权人可能的争辩）：**

专利权人极易抓住“第二协议与第三协议不同”这一点，强调其技术效果在于“解耦了唤醒/触发信令与实际的会话建立信令，从而节省网络资源并兼容不同终端”。

2. **攻击点（无效请求人的突破口）：**

* **概念外延过宽（未作进一步限定）：** 权利要求1中仅泛泛限定了“第二协议”和“第三协议不同”，未对协议类型进行任何实质性限定。在通信领域，控制信令（如呼叫指示、Push通知）与媒体传输协议（如RTP、SIP SDP）本身就是天然分层的不同协议。

* **容易被现有技术“等同”或“覆盖”：** 在D3以及广义的移动通信/VoIP技术中，通过控制通道（协议二）发送Ring/Push指示，终端响应后再建立数据通道（协议三），是极为普遍的通信规程。

---

## 六、 进一步的对比文件检索策略建议

为了在后续无效程序中形成**100% 绝对毁灭性（直接公开特征C~G具体协议细节）**的证据链，建议采取以下精准检索策略：

### 1. 检索要素表达（Search Elements）

* **核心要素1（网关/中继）：** Gateway, Residential Gateway, Media Gateway, Router, Access Point.

* **核心要素2（触发/唤醒）：** Trigger, Wake-up, Page, Notification, Alert, PUSH mechanism.

* **核心要素3（双协议/跨协议）：** First Protocol, Second Protocol, Dual protocol, Protocol conversion, Out-of-band signaling.

* **核心要素4（会话建立）：** Session Initiation, SIP, IGMP, RTSP, H.323, Call setup.

### 2. 推荐数据库与分类号（IPC/CPC）

* **IPC/CPC 分类号组合：**

* `H04L 65/1013`、`H04L 65/1069`（基于SIP/异构网络的会话管理与协议转换）

* `H04L 67/54`（网络协议触发与通知机制）

* `H04W 88/16`（移动通信网关/协议转换）

* `H04L 65/80`、`H04M 7/00`（IP语音/多媒体跨网传输）

### 3. 逻辑表达公式（以 European Patent Register / Google Patents 为例）

```text

(IPC=H04L65/10 OR IPC=H04W88/16) AND (gateway OR "access point") AND (trigger* OR wake* OR push*) AND ("session initiation" OR SIP) AND ("different protocol" OR "second protocol")

```

### 4. 重点追溯的方向与目标技术（Prior Art Target）

* **3GPP / IMS 规范文档：** 重点检索2005年之前的 3GPP TS 23.228 (IMS)、TS 23.140 (MM1/MM7协议触发机制) 等标准草案。IMS架构中“CS (电路切) 唤醒 + PS (包交换) 建立SIP会话”或“SMS/USSD 触发 + SIP 会话建立”完全对应特征C~G。

* **Early VoWiFi / CTP 标准：** 重点检索2003–2005年间关于“蜂窝/Wi-Fi双模手机”在进入AP覆盖区时，AP通过低功耗蓝牙/专有信令（协议二）触发手机，手机再通过Wi-Fi发起SIP/VoIP注册（协议三）的专利申请（如 Nokia, Ericsson, Qualcomm, Thomson 的早期专利）。

作为一名经验丰富的专利代理师，我针对目标专利权利要求1，结合目标专利的技术构思（假设目标专利围绕多媒体流传输控制、跨网关/代理的会话触发与协议转换展开）及三份对比文件（D1、D2、D3）的原文内容，为您提供深入的技术分析、特征比对、接近性评估及无效策略建议。

---

### 一、 对比文件公开号及指代说明

1. **D1**：`US20060271687A1`（Methods, systems, and products for sharing content）

2. **D2**：`US20060291472A1`（Method and apparatus for utilizing network services in a manner substantially transparent to service endpoints）

3. **D3**：`US20070025301A1`（Method and system for rate control service in a network）

---

### 二、 各对比文件技术特征公开性比对分析

#### 1. 对比文件 D1（US20060271687A1）分析

* **整体技术方案与效果**：D1 解决移动终端（如摄像手机）屏幕小限制内容共享的问题。通过移动终端使用消息协议（如 SIP/H.323）经由网关（如住宅宽带网关 RBGW 30）向媒体播放设备（如电视 16）发送会话邀请，使媒体设备呈现在手机端生成的多媒体数据流（如 RTP/RTCP 视频流）。

* **技术特征比对与公开认定**：

* **特征 A**：公开。第一终端（手机 12）、第二终端（电视 16）均连接到网关（RBGW 30），使能视频流 18 的发送与接收（[0005], [0025], [0026], FIG. 2）。

* **特征 B**：公开。手机 12 使用第一协议（SIP Invite 42）启动与网关 30 之间的第一多媒体会话信息的交换（[0032], [0033], FIG. 3）。

* **特征 C**：实质公开/显而易见。网关 30 在收到 SIP Invite 42 后，向电视 16 发送第二 SIP Invite 54 作为触发（[0032], [0033], FIG. 3）。但在 D1 中，该触发协议仍为 SIP 协议。

* **特征 D、E**：公开。响应于收到 Invite 54 触发，电视 16 启动与网关 30 之间的会话信息交换（发送 Alerting 56, Acceptance 66）（[0033], [0034], FIG. 4）。

* **特征 F、G**：**未公开**。D1 中电视 16 响应触发时使用的协议（第三协议）与网关发出的触发协议（第二协议）均为 SIP 协议，**未体现“第三协议不同于第二协议”**。

* **特征 H**：公开。手机 12 发送多媒体流（RTP/RTCP 18），电视 16 接收并播放（[0034], [0035], FIG. 5）。

---

#### 2. 对比文件 D2（US20060291472A1）分析

* **整体技术方案与效果**：D2 解决无线终端（如仅支持 RTSP 的终端）无法透明使用基于 SIP 的 IMS 网络服务（如 QoS 保障）的问题。通过在网络中引入代理节点（CSP 140、SSP 150），拦截终端的 RTSP 消息，并在网络侧再生（Regenerative Signaling）出 SIP 协议消息来控制网络 QoS 服务，随后触发/释放 RTP 媒体流。

* **技术特征比对与公开认定**：

* **特征 A**：公开。第一终端（WT 102）和第二终端（VS 130）通过网关/代理节点（CSP 140、SSP 150，广义的网关结构）连接，发送并接收 RTP 媒体流（[0019], [0043], FIG. 1）。

* **特征 B**：公开。WT 102 使用 RTSP 协议（第一协议，如 RTSP DESCRIBE/SETUP/PLAY）启动与 CSP 140 之间的多媒体会话信息交换（[0046], [0052]-[0056], FIG. 2 Steps 202, 214, 226）。

* **特征 C**：公开。CSP 140 在暂存（Hold）RTSP PLAY 消息后，使用 SIP 协议（第二协议，SIP INVITE）向网络/服务端（SSP 150）发送触发消息（[0057]-[0060], FIG. 2 Step 228-232）。

* **特征 D、E、F、G**：公开。SSP 150 响应于收到 SIP INVITE（触发），使用 RTSP 协议（第三协议，RTSP PLAY 242）与视频服务器 VS 130 启动会话信息交换。由于触发使用的是 SIP 协议（第二协议），而 SSP 与 VS 交互使用的是 RTSP 协议（第三协议），**明确公开了“第三协议不同于第二协议”**（[0061]-[0063], FIG. 2 Steps 232, 240-242）。

* **特征 H**：公开。从 WT 102 发送/请求多媒体流，并在 VS 130 与 WT 102 之间建立 RTP 传输流（[0043], [0063], FIG. 2 Step 250）。

---

#### 3. 对比文件 D3（US20070025301A1）分析

* **整体技术方案与效果**：D3 解决无线网络中由于信道质量快速波动导致 TCP/UDP 流控响应滞后的问题。通过在无线网络控制器（RNC）与代理/服务器/对端之间建立速率控制（Rate Control）机制，使用网络反馈（Network Feedback）直接动态调整传输层/应用层速率。

* **技术特征比对与公开认定**：

* **特征 A、B**：公开。终端（UE 358A）连接到 RNC/GGSN 网关，使用 SIP 协议或 RTSP 协议启动多媒体会话建立（[0214]-[0216], [0249], FIG. 13/15）。

* **特征 C、D、E、F、G**：部分公开/不完全对应。D3 侧重于在会话建立过程中，通过 SIP/SDP 带外或扩展字段（RC ID、RC IP、RC Port）通知网络节点（RNC/Proxy），随后使用特定的速率控制协议（GTP-U/Iu UP 上的 RC 消息）在 RNC 与 Proxy/MGW 之间传递速率参数。D3 的重点在于**速率控制参数的传递与协商**，其会话启动的主要控制逻辑并未强调“网关使用第二协议触发第二终端，第二终端再用不同于第二协议的第三协议与网关启动会话”的跨协议控制链条。

* **特征 H**：公开。终端之间或终端与服务器之间发送与接收多媒体流（[0230]-[0232], FIG. 13）。

---

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

---

### 四、 最接近的对比文件分析（最接近先开）

在创造性无效分析中，**D2（US20060291472A1）** 最适合作为最接近的对比文件（第一最接近对比文件），其次 **D1（US20060271687A1）** 可作为备选的最接近对比文件。

#### 1. 首选最接近对比文件：D2（US20060291472A1）

* **整体技术问题与效果比较**：

* **目标专利**解决的核心问题是：在涉及异构网络或不同协议终端/服务端的场景下，如何通过中间网关代理，利用协议间的转换与触发机制，建立端到端的多媒体会话并传输媒体流。

* **D2** 的技术领域、技术问题和解决方案与目标专利极为高度贴合。D2 旨在解决“终端（RTSP）与网络服务/服务端（SIP/IMS）协议不一致时，如何透明地利用 companion protocol（Companion Protocol，如 SIP）完成网络服务控制并触发 base protocol（Base Protocol，如 RTSP）会话建立”。

* **特征覆盖度**：D2 **完全公开**了权利要求1的所有技术特征（A、B、C、D、E、F、G、H）。在 D2 的图2流程中：

* 第一终端（WT 102）使用 RTSP（第一协议）与网关（CSP 140）交换会话信息；

* 网关（CSP）通过 SIP（第二协议）向对端网关（SSP 150）发送触发；

* 响应于该触发，对端网关/第二终端（VS 130）使用 RTSP（第三协议，且 RTSP 明显不同于 SIP）启动会话信息交换并传输多媒体流。

* **结论**：若以 D2 作为单篇对比文件，可直接评述权利要求1**不具备新颖性（A22.2）**；即便对某些概念的解释存在争议，以 D2 为基础结合本领域常识，权利要求1也**极易被认定为不具备创造性（A22.3）**。

#### 2. 备选最接近对比文件：D1（US20060271687A1）

* **整体技术问题与效果比较**：

* D1 解决“移动设备向大屏媒体设备共享多媒体内容”的业务场景问题，其架构同样依赖于住宅网关（RBGW）在主被叫之间传递 SIP 触发和建立流媒体传输。

* **特征覆盖度与区别特征**：

* D1 公开了特征 A、B、C、D、E、H，但**未公开特征 G（第三协议不同于第二协议）**。在 D1 中，网关与第二终端（电视）之间的触发与响应均基于同一 SIP 协议。

* **结合结合性**：若以 D1 为最接近对比文件，区别特征为“第二终端使用与触发协议（第二协议）不同的第三协议启动会话”。本领域技术人员为了使仅支持传统流媒体协议（如 RTSP/HTTP）的设备能够接入 SIPIMS 系统，引入 D2 中公开的“SIP 到 RTSP 协议转换/再生触发机制”是极其显而易见的。

---

### 五、 最薄弱的技术特征与无效攻击切入点

结合对比文件与专利审查实践，本权利要求1中**最薄弱的技术特征**为：

> **特征 G：第三协议不同于第二协议** （以及与其相勾连的“使用第二协议提供触发……第二终端使用第三协议启动……信息交换”）

#### 薄弱性分析：

1. **语义范围宽泛且易被涵盖**：该特征仅限定了“协议类型不同”（例如第二协议为 SIP，第三协议为 RTSP/H.323/HTTP 等），而未限制协议转换的具体数据结构或映射逻辑。

2. **已经被 D2 完全击中**：D2 的核心发明点即为“Regenerative Signaling（再生信令）”，其明确披露了在网关/代理处将第一/第三协议（Base Protocol，如 RTSP）与第二协议（Companion Protocol，如 SIP）进行相互转换与触发。D2 的图2完全覆盖了“用 SIP 协议触发，对端响应时使用 RTSP 协议”的全过程。

3. **技术效果属于本领域惯用手段**：在多媒体通信领域，网关（Gateway/SGW/AGW）的核心定义和本职功能就是“异构网络间的协议转换与会话映射”。在存在不同信令协议的终端或服务端之间，网关一侧使用 SIP 进行网络路由/触发，另一侧使用 RTSP/H.323 进行终端控制，是本领域的公知常识。

---

### 六、 进一步的对比文件检索策略

为了确保在后续的专利无效宣告程序中构建“双保险”的证据链（既有完美的单篇新颖性对比文件，又有充分的公知常识/组合创造件对比文件），建议采取以下检索策略：

#### 1. 核心特征分类号（IPC/CPC）拓展检索

重点针对“异构协议转换”、“SIP 与 RTSP/H.323 网关映射”、“IMS 网络中的协议代理”进行精准分类号限定：

* `H04L 65/102`（IMS/SIP 与其他协议的互通网关与协议转换）

* `H04L 65/1043`（会话控制协议的转换或代理，如 SIP to RTSP/H.323）

* `H04L 65/1069`（会话建立过程中的触发与协商）

* `H04L 67/56`（中间节点/代理/网关的服务代理）

#### 2. 关键词精准组合表达

建议采用以下逻辑组进行逻辑布尔检索：

* **网关/代理组**：`(Gateway OR Proxy OR "B2BUA" OR "Signaling Gateway" OR "Back-to-Back User Agent")`

* **协议转换/再生组**：`("protocol conversion" OR "protocol mapping" OR "regenerative signaling" OR "companion protocol" OR "base protocol" OR "interworking")`

* **协议名称组**：`(SIP NEAR/5 RTSP) OR (SIP NEAR/5 H.323) OR (SIP NEAR/5 HTTP)`

* **触发与会话建立组**：`(trigger OR invite OR initiate) AND ("session description" OR SDP OR "session exchange")`

#### 3. 重点追溯标准文献（3GPP / IETF RFC）

由于该专利涉及多媒体会话控制与网关协议互通，大量架构在 3GPP 和 IETF 标准中早有明确定义：

* **IETF RFC 3372 / RFC 3261**（SIP 协议及网关互通架构）

* **3GPP TS 29.162 / TS 29.228**（IMS 与外部 IP 网络的互通、CS/PS 域协议转换）

* **3GPP TS 26.234**（Transparent end-to-end Packet-switched Streaming Service (PSS)，详细定义了 RTSP 与 SIP/IMS 的结合使用）

#### 4. 检索方向总结

目前的 **D2 (US20060291472A1)** 已经形成了非常强有力的新颖性/创造性破坏力。下一步检索应侧重于寻找**公开日早于目标专利申请日**的 **3GPP 规范文档** 或 **IETF RFC 草案**，此类标准文献在无效宣告中具有极高的证据效力，能彻底封堵专利权人对“网关定义”或“协议转换”的技术解释争辩空间。

这份专利无效分析报告以资深专利代理师的专业视角，紧密结合目标专利权利要求、对比文件原文及专利法创造性审查标准（“三步法”）进行深度比对与严谨研判。

---

### 一、 权利要求拆解与技术特征标识

目标专利权利要求1包含以下8个技术特征（按字母序列编号）：

* **特征A**：其中第一和第二终端被连接到至少一个网关以使能第一多媒体流的发送和第二多媒体流的接收

* **特征B**：所述第一终端使用第一协议启动在第一终端和网关之间的第一多媒体会话信息的交换

* **特征C**：使用第二协议提供触发到第二终端

* **特征D**：以启动在第二终端和网关之间的第二多媒体会话信息的交换

* **特征E**：响应于提供所述触发

* **特征F**：第二终端使用第三协议启动在第二终端和网关之间的第二多媒体会话信息的交换

* **特征G**：第三协议不同于第二协议

* **特征H**：从第一终端发送第一多媒体流并且在第二终端接收第二多媒体流

---

### 二、 对比文件特征比对与公开性分析

下表对各对比文件是否公开权利要求1的技术特征进行了逐项比对，并标注了详细的原文出处：

#### 权利要求1与对比文件特征比对表

---

### 三、 逐一对比文件的深入分析

#### 1. 对比文件1：CN101013997A（D1）

* **技术领域与解决的技术问题**：D1涉及多媒体通信中H.323/SIP多媒体网关转发信令与媒体流的方法，主要解决**私网终端穿越NAT/防火墙设备**的技术问题。

* **公开的技术特征（A, B, H）**：

* **特征A/B/H**：D1公开了主叫终端（第一终端）和被叫终端（第二终端）均连接到位于公网的多媒体网关【具体实施方式第11-13段】；主叫终端通过TCP/SIP/H.323协议（第一协议）向网关发送控制信令（第一多媒体会话信息）【具体实施方式第13段】；网关将来自主叫的媒体流转发给被叫【具体实施方式第13段】。

* **未公开的技术特征（C, D, E, F, G）**：

* D1中的网关仅作为信令与媒体流的透明中继转发设备（TRI标识，【具体实施方式第12-13段】）。网关向被叫终端发送信令时，使用的是与主叫相同的协议（SIP/H.323）。D1**未公开**使用“第二协议向第二终端提供触发”，也**未公开**“第二终端响应触发使用不同于第二协议的第三协议启动会话”。

#### 2. 对比文件2：WO2007101473A1（D2）

* **技术领域与解决的技术问题**：D2涉及IPTV系统与IMS（IP多媒体子系统）融合的技术，主要解决**如何在IPTV/多媒体会话中集成组合业务（如来电通知、事件触发时差播放/追赶播放），以及在有限带宽下灵活控制会话与媒体流**的技术问题【p0006-p0014, p0108】。

* **公开的技术特征（A, B, C, D, E, F, G, H）**：

* **特征A/B/H**：D2公开了主叫/第一终端通过SIP协议（第一协议）向IPTV-AS（网关）建立控制通道与会话信息交换【p0046-p0058；Figure 1】。

* **特征C/D**：在“Incoming Call Notification”或“Extended Incoming Call Scenario”等实施例中，IPTV-AS（网关）通过Parlay-X Web Service/专用控制通道协议（第二协议）向STB/第二终端发送“Incoming Call Notification”触发消息【p0082, p0114；Figure 3/5 Step 7】，以提示并启动第二终端与网关之间的第二多媒体会话【p0082, p0118】。

* **特征E/F/G**：第二终端（STB/用户）响应于该触发【p0086, p0118】，使用SIP协议（第三协议）发送200 OK或SIP INVITE响应来启动第二多媒体会话【p0089-p0090, p0121-p0125】。由于触发使用的是Parlay-X/Web Service或专用控制协议（第二协议），而会话启动使用的是SIP协议（第三协议），**明确公开了第三协议不同于第二协议（特征G）**。

* **特征H**：最终在第一终端和第二终端之间传输并接收多媒体流【p0074, p0125】。

* **结论**：D2**实质公开（或全要件公开）**了权利要求1的所有技术特征A~H。

#### 3. 对比文件3：US7286521B1（D3）

* **技术领域与解决的技术问题**：D3涉及局域化VoIP通信系统，主要解决**在语音激活服务中解耦电路交换网（PSTN）与IP网络，提高服务器负载均衡与呼叫处理灵活性**的技术问题【摘要；[0010]-[0012]】。

* **公开的技术特征（A, B, H）**：

* D3公开了终端通过Media Gateway（网关）和SIP Proxy连接，使用SIP协议启动呼叫会话并收发语音/多媒体流【[0032]-[0045]；FIG. 3】。

* **未公开的技术特征（C, D, E, F, G）**：

* D3重点在于SIP Proxy如何将Incoming Call分发给后端Server以及Tromboning处理，**未公开**通过“第二协议向第二终端发送触发”，以及“第二终端响应触发使用第三协议（异于第二协议）启动会话”的异构协议触发机制。

---

### 四、 最接近对比文件的选择与创造性分析

#### 1. 最接近对比文件的确定

* **首选最接近对比文件：D2 (WO2007101473A1)**

* **理由**：

1. **技术领域高度一致**：D2与目标专利均属于多媒体通信会话控制及网关交互领域。

2. **解决的技术问题相同**：均致力于解决如何在多媒体网关/服务器架构下，通过带外/异构协议触发终端建立多媒体会话。

3. **技术特征覆盖度最高**：D2公开了权利要求1的**全部技术特征（A~H）**。

* **备选最接近对比文件：D1 (CN101013997A)**

* **理由**：若从传统的“网关转发多媒体会话”基础架构出发，D1公开了最经典的主被叫通过网关收发流架构（特征A, B, H）。

#### 2. 创造性与新颖性判定逻辑

##### 路径一：基于D2（WO2007101473A1）发起新颖性/创造性攻击（最佳策略）

* **新颖性攻击（专利法第22条第2款）**：

* 由于D2已经完整公开了特征A、B、C、D、E、F、G、H，且D2的公开日（2007年9月13日）早于目标专利申请日，权利要求1相对于D2**不具备新颖性**。

* **创造性攻击（专利法第22条第3款）**：

* 即使专利权人辩称特征G中“协议具体类型”有细微差异，该领域技术人员在D2公开的“Parlay-X触发 + SIP会话建立”架构下，显而易见能够根据实际网络环境选择不同的控制协议与呼叫协议进行组合，不具备突出的实质性特点和显著的进步。

##### 路径二：基于D1（CN101013997A）结合D2/公知常识发起创造性攻击

* **区别技术特征**：区别在于特征C、D、E、F、G（即通过第二协议向第二终端提供触发，第二终端响应触发使用异于第二协议的第三协议启动与网关的会话）。

* **实际解决的技术问题**：如何在网关与终端之间实现带外异步触发以启动多媒体会话。

* **结合动因**：D2明确教导了在多媒体网关（IPTV-AS）架构中，使用Parlay-X/控制协议向终端发送触发通知，终端再通过SIP协议发起会话连接的技术方案。本领域技术人员在D1的基础上，为了实现灵活的呼叫/事件通知，有明确的动因结合D2的教导，从而得到权利要求1的方案。

---

### 五、 无效请求中最薄弱的技术特征与防守漏洞分析

在权利要求1中，**最薄弱的技术特征是：特征G（“第三协议不同于第二协议”）**。

* **薄弱原因**：

1. **高度抽象与上位化**：权利要求1仅泛泛地限定了“第三协议不同于第二协议”，未对这两个协议的具体名称、消息结构或传输层依赖做任何限定。

2. **极易被对比文件击穿**：在IMS/IPTV或复杂通信网关中，控制面/通知面（如HTTP/Parlay-X/Push Notification）与媒体协商面（如SIP/SDP）天然采用不同协议。D2中采用Parlay-X（第二协议）推送通知、SIP（第三协议）建立会话的模式，直接落入了特征G的字面范围。

3. **缺少协同功效限定**：说明书中若未对两种协议“如何协同解决特定技术难题”进行明确的界定，该特征极易被认定为本领域的常规协议选择或公知常识。

---

### 六、 进一步对比文件检索策略建议

为了确保无效宣告请求的稳妥性（防止专利权人通过修改权利要求、将说明书中的具体协议细节补入权利要求1中进行抗辩），建议采取以下补充检索策略：

1. **检索主题扩展与关键词组合**：

* **关键词**：`(网关 OR 服务端 OR 网关设备) AND (触发 OR 推送 OR 通知 OR Trigger OR Push OR Notification) AND (异构协议 OR 不同协议 OR 双协议 OR Parlay OR SIP OR HTTP OR RTSP)`

* **IPC/CPC分类号**：

* `H04L65/10`（会话初始或会话建立协议）

* `H04L65/1089`（使用不同协议的网关/代理）

* `H04L67/55`（推送消息服务）

2. **重点追踪与补充检索方向**：

* **IMS (IP Multimedia Subsystem) 3GPP标准规范**：重点检索2005–2007年间的3GPP TS 23.228、TS 24.229关于P-CSCF/AS使用Push/Parlay-X触发UE（用户设备）通过SIP建立Session的标准文件。标准文件具有极高的权威性和公开性。

* **Push-to-Talk (PoC) 与 WebRTC 早期草案**：此类系统广泛存在“带外TCP/HTTP/SMS触发 + 带内SIP/RTP媒体建链”的双协议架构。

3. **应对防守修改的预备检索**：

* 仔细核查目标专利说明书中关于“第一协议、第二协议、第三协议”的具体实施例（例如第一协议是否为SIP，第二协议是否为HTTP/Push，第三协议是否为SIP/RTSP）。针对这些具体协议组合提前储备补充对比文件（如D4、D5），以便在专利权人缩小保护范围时发起二次组合攻击。

根据权利要求1的方法，其中第一多媒体会话信息的交换包括向第一终端提供至少部分第二多媒体会话信息；并且由此响应所述提供开始从第一终端发送第一多媒体流。

根据权利要求1或2的方法，其中第二多媒体会话信息的交换包括向第二终端提供至少部分第一多媒体会话信息；并且由此响应于所述提供开始由第二终端接收第二多媒体流。

根据权利要求1或2的方法，其中第一协议是对等型协议。

根据权利要求4的方法，其中所述对等型协议是会话启动协议(SIP)。

根据权利要求1或2的方法，其中第三协议是客户端-服务器型协议。

根据权利要求6的方法，其中所述客户端-服务器型协议是实时流协议(RTSP)。

根据权利要求1或2的方法，其中提供触发到第二终端的步骤是由网关启动的。

根据权利要求1或2的方法，其中第一多媒体会话信息的交换包括提供第二终端的标识符给网关。

根据权利要求9的方法，其中该方法包括在提供触发给第二终端之前；将第二终端的标识符解析成网络地址的附加步骤。

根据权利要求1或2的方法，其中第一和第二协议相同。

根据权利要求1或2的方法，其中第一多媒体流是与第二多媒体流相同的多媒体流。