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

根据权利要求1与目标专利及对比文件的技术特征，以下为详细的侵权/对比分析、最接近对比文件评估、特征比对表格及无效宣告检索策略：

---

## 1. 权利要求1的技术特征拆解与技术内涵解释

结合目标专利说明书及相关标准架构，权利要求1定义了一种**跨终端、多协议协同建立多媒体会话及传输流**的方法：

* **特征A（网络架构与实体）**：第一终端和第二终端均连接至至少一个网关（Gateway），用于第一多媒体流的发送和第二相关多媒体流的接收。

* **特征B（会话启动阶段1）**：第一终端使用**第一协议**向网关启动/交换第一多媒体会话信息（如媒体协商、描述信息上传）。

* **特征C/D（通知/触发阶段）**：使用**第二协议**向第二终端发送触发（Trigger），用于启动第二终端与网关之间的第二多媒体会话信息交换。

* **特征E（协议区别1）**：第二协议不同于第一协议。

* **特征F/G（会话启动阶段2）**：第二终端响应于所述触发，使用**第三协议**启动其与网关之间的第二多媒体会话信息交换。

* **特征H（协议区别2）**：第三协议不同于第二协议，且不同于第一协议（即协议一、二、三三者互不相同）。

* **特征I（媒体流传输）**：第一终端发送第一多媒体流，第二终端接收第二相关多媒体流。

---

## 2. 对比文件技术特征比对表格

以下为权利要求1与两篇对比文件原文（含具体段落/出处）的详细对比分析：

---

## 3. 最接近的对比文件（D1）及创造性分析

### 3.1 最佳对比文件选定：US20020073205A1 (D1)

* **整体解决的技术问题**：D1旨在解决传统移动网络（如MMS）由于终端内存有限、无法在完整下载前实时播放大容量多媒体（视频/音频）流的问题，提供一种将控制层与流传输层解耦、通过通信服务器/网关实现多媒体流推拉（Store-and-Forward Streaming）的方法。这与目标专利解决“异构网络/终端间异构协议控制多媒体流会话建立”的技术问题高度一致。

* **技术效果**：D1通过通知机制触发接收端，利用流媒体控制协议实现低延迟播放，大幅降低了终端存储要求。

* **选定结论**：**US20020073205A1 (D1)** 在技术领域、解决的技术问题、整体系统架构（两终端+网关+三阶段会话控制）上与权利要求1最为接近，适合作为首选的**最接近对比文件**。

### 3.2 区别特征与无效请求中最薄弱的技术特征分析

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

权利要求1明确要求 **“第三协议不同于第二协议和第一协议”**（即：$Protocol_1 \neq Protocol_2$、$Protocol_2 \neq Protocol_3$、且 $Protocol_1 \neq Protocol_3$）。

而在D1中：

* 第一协议（Phase 1，发送端到网关）：**RTSP**（或HTTP）

* 第二协议（Phase 2，网关到接收端触发）：**MMS Notification**

* 第三协议（Phase 3，接收端到网关）：**RTSP**（或HTTP）

* 即D1的 $Protocol_1 = Protocol_3$（均使用RTSP），未公开三者互不相同。

* **无效请求中最薄弱的技术特征（专利权的防守壁垒）**：

**特征H（第三协议与第一协议、第二协议均不相同）** 是本权利要求**最薄弱、最易被攻破（或防守关键）的特征**：

1. **公知常识/协议选择习惯**：在实际多媒体通信架构中（如3GPP、IMS或SIP/RTSP架构），发送端与网关（如上行/推流）所采用的协议（例如：SIP/SDP或WebRTC/RTMP），与接收端与网关（下行/拉流）所采用的协议（例如：RTSP、HLS或HTTP-FLV）在技术实现上经常因终端能力不同而天然不同（例如：发送端为移动台使用SIP，接收端为传统Web终端使用RTSP/HTTP-FLV）。

2. 技术人员在D1的基础上，结合不同终端（如移动终端与PC终端）能力差异，引入不同的上行/下行流控协议属于本领域的惯用技术手段。

---

## 4. 进一步对比文件检索策略（无效宣告检索指引）

为了彻底无效权利要求1，需针对“**第一协议与第三协议不同（且均与第二协议不同）的会话触发机制**”补充对比文件（D3），具体检索策略如下：

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

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

* `H04L65/1016`（SIP/会话控制协议）

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

* `H04L65/65`（流媒体传输协议转换/异构协议）

* `H04L67/562`（网关协议转换/Proxy）

* `H04W4/12`（移动多媒体消息/MMS）

* **关键词组（中英文逻辑表达式）**：

* `((Session or Signaling or Protocol) NEAR3 (Convert* or Differ* or Heterogeneous or Transcod*))`

* `((Push or Trigger or Notification) AND ("SIP" or "RTSP" or "HTTP") AND ("SDP" or "MMS"))`

* `("First protocol" AND "Second protocol" AND "Third protocol")` / `(Upstream NEAR2 Protocol) AND (Downstream NEAR2 Protocol) AND NOT Equal`

### 4.2 结合D1组合结合的技术突破点

1. **寻找D3（异构协议流会话触发）**：检索公开在目标专利申请日前的专利/标准文档，寻找“发送端采用协议A（如SIP/WSP）向网关建立会话，网关通过协议B（如SMS/Push/MMS）触发接收端，接收端采用不同于A的协议C（如RTSP/HTTP/RSVP）向网关拉取流”的技术方案。

2. **标准文献检索（3GPP/IETF）**：

* 重点检索 3GPP TS 23.140 (MMS Stage 2) 与 3GPP TS 26.234 (PSS - Packet-switched Streaming Service) 的结合演进文档。

* 检索 IETF RFC 2326 (RTSP) 与 SIP (RFC 3261) 在多媒体网关（Media Gateway/B2BUA）中的互通标准（如SIP-to-RTSP Interworking）。这类标准明确记载了发送端用SIP，网关带外SMS/Push触发，接收端用RTSP拉流的三协议异构架构，可作为完美的公知常识/D3证据，与D1结合彻底无效权利要求1。

作为一名经验丰富的专利代理师，我针对目标专利权利要求1，紧密结合目标专利说明书以及两份对比文件（D1：US7231658B2，D2：US20070177616A1）的原文进行深度技术特征拆解、对比分析与无效检索策略制定。

---

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

根据目标专利（以下简称“本专利”）的技术方案，权利要求1包含以下9个技术特征（A~I）。结合专利背景与说明书上下文，各特征的技术涵义解释如下：

* **技术特征A**：`用于从第一终端发送多媒体流并且在第二终端接收相关的第二多媒体流的方法，其中，第一和第二终端被连接到至少一个网关以使能第一多媒体流的发送和第二相关流的接收，该方法包括步骤`

* *说明书解释*：该特征限定了系统拓扑形态。第一终端（如发送端）和第二终端（如接收端）通过网关/中继/代理设备连接，用于多媒体流（如音视频流）的跨终端传输与接收。

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

* *说明书解释*：第一终端与网关之间采用第一协议进行控制/信令会话交互（例如启动、建立会话协商等）。

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

* *说明书解释*：向第二终端发送一个“触发”信号/消息，使用的协议为第二协议（例如通知或呼叫触发）。

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

* *说明书解释*：上述触发的作用在于，促使/诱导第二终端主动发起或参与其与网关之间的第二多媒体会话信息交换。

* **技术特征E**：`第二协议不同于第一协议`

* *说明书解释*：第一终端与网关交互的协议（第一协议）与向第二终端发送触发的协议（第二协议）为两种不同的通信协议。

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

* *说明书解释*：存在因果时序关系，即第二终端在收到/响应于第二协议给出的触发之后，才采取下一步的协议交互行动。

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

* *说明书解释*：第二终端被触发后，使用“第三协议”主动或响应式地启动其与网关之间的多媒体会话信息交换。

* **技术特征H**：`第三协议不同于第二协议和第一协议`

* *说明书解释*：**核心协议异构限制**。本专利明确要求第一协议（第一终端-网关）、第二协议（触发协议）、第三协议（第二终端-网关）**三者互不相同**（三协议异构体系）。

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

* *说明书解释*：在会话信息交换/协商完成后，实现多媒体流从第一终端到第二终端的传输与接收。

---

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

#### 1. 对比文件基本信息

* **D1**：US7231658B2 (`Data transmission system, apparatus and method for processing information...`)

* **D2**：US20070177616A1 (`INTERACTIVE MULTIMEDIA EXCHANGE ARCHITECTURE AND SERVICES`)

#### 2. 特征比对表格 (Claim vs D1 & D2)

---

### 三、 接近对比文件分析（结合技术问题与技术效果）

#### 1. D1 (US7231658B2) 分析

* **整体解决的技术问题**：解决在网络中跨终端传输大容量多媒体数据（如视频邮件）时，因发送端不了解接收端能力/状态而导致的传输失败、网络开销过大或中继服务器负载过重的问题。

* **技术效果**：通过引入中继/缓存机制与POB服务器控制，在异构协议和分布式节点间安全、高效地完成大容量多媒体流的缓存与异步/同步转发。

* **与本专利的匹配度**：D1的拓扑结构（发送端终端、发送端缓存、POB服务器、接收端缓存、接收端终端）与本专利的“终端-网关-终端”高度吻合。在D1的HTTP/RTSP下载实施例中（段落[0230]等），已经展现了第一协议（SIP）、第二协议（SMTP/Email通知）、第三协议（HTTP/RTSP）三种不同协议协同工作的技术架构。

#### 2. D2 (US20070177616A1) 分析

* **整体解决的技术问题**：解决不同网络类型（电路域3G与分组域IP网络）及不同终端能力之间多媒体信息无缝共享与交互困难的问题。

* **技术效果**：通过多媒体交换架构（MEA）和网关实现协议转换（如3G-324M到SIP/RTSP/HTTP）、媒体转码与灵活的通知/推送，提升用户体验。

* **与本专利的匹配度**：D2侧重于网关的媒体转码与异构网络互通（如3G与IP网），虽然也提出了采用SMS/Email作为通知触发第二终端使用HTTP/FTP/RTSP拉取媒体，但其核心在于媒体交换架构，对“会话信息交换的严格三协议异构”未作专门的限定。

#### 3. 结论：最接近的对比文件选择

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

* *理由*：D1在整体架构、消息时序（触发机制、响应触发启动会话）以及协议架构上与本专利最为接近。D1不仅公开了完整的终端-网关/缓存-终端交互时序，而且在其特定的实施例中已经完全涵盖了使用第一协议（SIP）建连、第二协议（Email/通知）触发、第三协议（HTTP/RTSP）拉取媒体的全过程。

---

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

通过对比可知，权利要求1的核心发明点（也是防线所在）在于：**三协议的差异性限定（技术特征E与技术特征H的组合，特别是特征H：第三协议不同于第二协议和第一协议）**。

在专利无效审查中，**最薄弱的技术特征为：技术特征H（及特征E/H组合的“三协议异构”）**。

* **薄弱原因分析**：

1. **公知常识/显而易见性高**：在基于网关/中继的异构网络通信（如IMS/SIP架构、网关与Web应用结合）中，由于终端能力与网络接口的不同，发送端与网关采用信令协议（如SIP，第一协议）、网关向接收端发送带链接的推送/通知（如SMS/Push/Email，第二协议）、接收端使用Web/媒体传输协议（如HTTP/RTSP，第三协议）建立媒体会话，是本领域技术人员为了解决“异步/带外通知与媒体拉取”而**非常容易想到的常规技术手段（组装公知协议）**。

2. **D1/D2中已存在教导**：D1段落[0230]明确指出了HTTP/RTSP拉取，同时前文指出SIP/Email的使用；D2段落[0091]也明确教导了SMS/Email通知与HTTP/RTSP/FTP拉取的组合。本领域技术人员在D1/D2的教导下，为了实现跨平台通知与多媒体播放，将这三种不同协议结合使用不具备突出的实质性特点和显著的技术进步。

---

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

为了在无效宣告程序中彻底击毁权利要求1及后续从属权利要求，建议采取以下进一步检索策略：

1. **聚焦“Web-RTC / SIP / RTSP / Push Notification”跨协议会话建立的技术领域**：

* **检索方向**：重点查找在2006-2007年之前（或目标专利优先权日之前）关于“应用网关（Application Gateway）/多媒体消息服务器（MMSC）通过带外通知（Out-of-band Notification，如SMS/Push）触发终端使用HTTP/RTSP/SIP建立会话”的标准文件或专利。

2. **3GPP及ITU-T标准规范检索**：

* **具体标准**：3GPP TS 23.140 (MMS Stage 2)、3GPP TS 24.229 (IMS Call Control)、ITU-T H.324 Annex C / H.323。

* *检索逻辑*：MMS（彩信）与IMS架构天然具备“发送端通过MM1/SIP上传多媒体 -> 接收端收到Push-Notification(SMS/WAP Push) -> 接收端通过HTTP/WSP/RTSP从网关拉取多媒体”的过程。这构成了非常直接的“三协议异构”现有技术证据。

3. **关键词与分类号（IPC/CPC）组合检索策略**：

* **IPC/CPC分类号**：`H04L65/10` (会话建立/网关), `H04L67/55` (推送技术), `H04L65/1101` (协议转换/异构协议), `H04W4/12` (消息服务).

* **逻辑检索式**：

* `(Gateway OR Proxy OR Relay) AND (Session OR SIP OR H.323) AND (Trigger OR Notification OR Push OR SMS OR Email) AND (RTSP OR HTTP OR FTP) AND (Video OR Multimedia OR Stream)`

<FollowUp label="是否需要我针对从属权利要求进一步补充检索策略或编写无效宣告请求书中的创造性论述逻辑？" query="请针对目标专利的从属权利要求进一步补充检索策略，并编写针对权利要求1的专利无效宣告请求书中的创造性论述逻辑草稿。"/>

作为一名经验丰富的专利代理师，我将紧密结合目标专利的说明书解释权利要求1，并对照三份对比文件（公开号分别为 **CN1393090A**、**US6661785B1**、**US20040125757A1**）进行详细的技术特征比对、创造性/最接近对比文件分析以及无效策略评估。

---

## 一、 目标专利权利要求1的说明书解释

根据目标专利的申请意图与技术方案，权利要求1各技术特征的本意及上下文关系解释如下：

* **技术特征A（系统拓扑与预备环境）**：第一终端与第二终端均连接至“至少一个网关”（Gateway），网关在两端之间起到会话协同或协议中转/桥接的作用，使能第一流的发送与第二流的接收。

* **技术特征B（第一阶段会话建立/上传）**：第一终端使用“第一协议”与网关启动第一多媒体会话信息的交换（例如基于第一协议上传多媒体内容或初始化媒体通道）。

* **技术特征C、D、E（第二阶段跨终端触发）**：使用与第一协议不同的“第二协议”，向第二终端发送一个“触发（Trigger）”，目的是触发第二终端去启动与网关之间的第二会话。这里明确限定了**协议异质性（第二协议不同于第一协议）**，第二协议通常为带外（Out-of-band）控制/通知协议（如MMS通知、SIP SUBSCRIBE/NOTIFY、PSTN/AIN触发信号等）。

* **技术特征F、G、H（第三阶段响应触发建立下载会话）**：第二终端接收到触发后，响应于该触发，使用“第三协议”启动与网关之间的第二多媒体会话信息交换。这里进一步限定了**三协议互不相同（第三协议既不同于第二协议，也不同于第一协议）**。第三协议通常为专用的媒体下载或流控协议（如RTSP、HTTP、PSTN等）。

* **技术特征I（媒体流传输）**：第一终端发送第一多媒体流，第二终端接收相关的第二多媒体流（完成端到端或经网关转发的媒体流传输）。

---

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

为了清晰直观地展现各对比文件的公开情况，现整理特征比对表格如下（**中文翻译/对照均紧密结合各对比文件原文及出处**）：

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

---

## 三、 对比文件原文详细出处与公开性深度分析

### 1. CN1393090A (D1) 深度分析

* **公开号**：CN1393090A

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

* **特征A**：图2及说明书第7页第1-12行公开了发送器21、接收器24以及包含媒体服务器22和MMS服务器23的通信服务器（网关结构）。

* **特征B**：说明书第7页第17-21行（阶段1）：“*发送器21与媒体（流式传输）服务器22之间建立流式传输对话...*”，使用的是第一协议（如RTSP/HTTP）。

* **特征C、D、E、F**：说明书第7页第22-31行（阶段2及阶段3）：“*在阶段2中，发送器21通过MMS服务器23发送通知给接收器24...通知包括在接收器24和媒体服务器22之间建立另一流式传输对话所需的显示描述信息...在阶段3中，接收器24基于所接收的通知消息中的信息而建立与媒体服务器22的流式传输对话*”。其中，阶段2采用MMS通知协议（第二协议），与阶段1的第一协议不同（满足特征E）。

* **特征I**：说明书第8页第5-9行：“*发送器21继续将媒体内容发送给媒体服务器22，而媒体服务器22同时将媒体内容中早先收到的部分发送给接收器24*”。

* **未公开/区别特征（致命薄弱点）**：

* **特征H（三协议互不相同）**：D1在说明书第8页第25-28行明确指出：“*RTSP被认为是在阶段1和3中实现和控制流式传输的最佳模式*”。这表明在D1中，**第一协议（阶段1上传）和第三协议（阶段3下载）均为RTSP协议**。因此，D1并未公开“第三协议不同于第一协议”这一限定（即未公开三协议两两不同的特征H）。

### 2. US6661785B1 (D2) 深度分析

* **公开号**：US6661785B1

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

* **特征A**：FIG. 1a及Col. 4, lines 45-65公开了由SSP 110、Gateway 128、SN 116、SCP 120构成的融合网关系统，连接Subscriber 112与PSTN Caller 114。

* **特征B**：Col. 7, lines 16-20（step 212）：“*Subscriber 112 immediately initiates an H.323 call to the H.323 gateway 128...*”（使用第一协议H.323）。

* **特征C、D**：Col. 6, lines 52-60（step 209）：“*SCP 120 forwards to the internet address of subscriber 112 a notification message... presents subscriber 112 with call disposition options.*”（使用第二协议IP通知/Pop-up消息提供触发）。

* **特征E**：第一协议为H.323/IP媒体会话协议，第二协议为TCP/IP通知协议，二者协议不同。

* **特征F、G**：Col. 7, lines 20-30（step 213-216）：“*Upon receiving the H.323 call... gateway 128 converts the H.323 call into a PSTN call and routes the PSTN call to the SN...*”（响应于触发，使用第三协议——PSTN/PRI/Q.931信令协议建立会话信息交换）。

* **特征H（完全公开）**：第一协议为H.323 (IP)，第二协议为IP通知/Pop-up协议，第三协议为PSTN/Q.931电路切分信令协议，**三者相互不同**，完全公开了特征H。

* **特征I**：Col. 8, lines 20-35（step 220）：“*SN 116 bridges the two ports... subscriber 112 and PSTN caller 114 exchange voice communication...*”。

### 3. US20040125757A1 (D3) 深度分析

* **公开号**：US20040125757A1

* **分析**：D3主要关注RTSP与SIP协议之间的映射转换（例如段落[0190]-[0205]），其流程是由客户端主动发起DESCRIBE或SETUP请求，网关被动进行协议转换。D3缺乏“由第一终端经网关使用第二协议主动向第二终端提供触发，以诱导第二终端响应触发去建立第三协议会话”的整体架构（即缺乏特征C、D、E、F、G）。

---

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

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

本专利（权利要求1）解决的核心技术问题是：**在异构网络环境或多终端协作场景下，如何克服单一协议在会话发起、跨网触发和媒体流传输上的局限性，实现跨终端多媒体流的高效协同传输。**

其达到的技术效果在于：通过区分“第一协议（会话上传/建立）”、“第二协议（跨网/跨终端带外触发通知）”以及“第三协议（响应触发后的媒体下载/接收）”，且明确限定三协议互不相同，实现了**控制信令与媒体传输的分离**以及**异构网络协议的最佳匹配**。

### 2. 最接近对比文件的选择（最接近对比文件：D2 或 D1）

在专利无效或创造性评估中，**D2（US6661785B1）和 D1（CN1393090A）均适合作为最接近的对比文件**：

#### 方案一：以 D2（US6661785B1）作为最接近对比文件（首选，突破性最强）

* **理由**：D2属于融合通信领域，其技术拓扑（IP网络与PSTN网络通过网关桥接）、控制流程（Pop-up触发 -> 响应触发 -> 异构协议建立会话）与目标专利最为贴近。

* **特征覆盖**：D2**毫无异议地公开了特征A、B、C、D、E、F、G、H、I的全套技术架构**，特别是彻底公开了目标专利中最具技术屏障的“**三协议互不相同（特征H）**”（即第一协议H.323、第二协议IP通知、第三协议PSTN/Q.931）。

* **创造性摧毁力**：若以D2为单篇对比文件（结合本领域公知常识），或以D2为第一对比文件，本专利权利要求1的创造性将极其危险。

#### 方案二：以 D1（CN1393090A）作为最接近对比文件

* **理由**：D1同属于多媒体流式传输领域（MMS流化），公开了三阶段法（上传、MMS通知触发、流式下载）。

* **未公开特征**：D1未明确公开“**第三协议不同于第一协议（特征H）**”（因为D1的上传和下载阶段均推荐使用RTSP）。

* **结合方案**：若以D1为最接近对比文件，未被D1公开的“第三协议不同于第一协议（特征H）”已被 **D2** 明确公开。本领域技术人员在D1的基础上，结合D2关于“针对不同传输方向及网络接口选用不同专用协议（如H.323与PSTN/Q.931）”的技术教导，无需付出创造性劳动即可得出权利要求1的技术方案。

---

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

若对目标专利提出无效宣告请求，**最薄弱的技术特征（即专利权人最难维持有效性的特征）是：特征H（第三协议不同于第二协议和第一协议）。**

### 原因分析：

1. **概念形式化而非本质创新**：将通信过程中的上传协议、通知协议和下载协议分别采用不同的现有标准协议（如SIP、MMS/SMS/WAP Push、RTSP/HTTP），属于本领域技术人员为了适应不同网络接口（如带外控制通道与带内媒体通道）而进行的常规协议选择和组合。

2. **已被D2完全公开**：D2在VOIP与PSTN融合呼叫等待体系中，为了兼顾IP端（H.323/Pop-up）与传统电话端（PSTN/Q.931），必然采用了三种完全不同的协议进行交互。因此，特征H在D2中已经存在现成的技术教导，专利权人无法以此特征作为划分创造性的“安全避风港”。

---

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

为了在后续的无效程序中形成“双保险”或进一步巩固对从属权利要求的打击，建议采取以下进一步检索策略：

### 1. 扩充检索要素与分类号（IPC/CPC）

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

* `H04L65/10`（会话架构与协议）

* `H04L65/60`（流媒体传输）

* `H04L67/55`（推送技术/Push Technology / Triggering）

* `H04M3/42`（电信补充业务/呼叫等待/跨网触发）

* **核心关键词组合**：

* `("multi-protocol" OR "protocol conversion" OR "heterogeneous protocol" OR "different protocol")`

* `("trigger" OR "notification" OR "push" OR "pop-up")`

* `("session" OR "streaming") AND ("gateway" OR "MMSC")`

### 2. 追踪 3GPP 标准规范文献（强烈推荐）

由于目标专利涉及 MMS（多媒体消息服务）与 RTSP/SIP 结合的流媒体触发机制，该技术在 **3GPP TS 23.140**（MMS功能描述）及 **3GPP TS 26.234**（PSS流式传输业务）规范演进过程中有大量的概念讨论与CR（Change Request）文档：

* **检索方向**：重点检索 2000 年至 2003 年期间 3GPP SA2 / SA4 工作组关于“*MMS Streaming Triggering via OMA/WAP Push to initiate RTSP/SIP Session*”的技术提案（T-Docs）。这类标准提案通常对“通过MMS Notice（第二协议）触发终端启动RTSP（第三协议）流媒体”有极详尽的协议分层图解，是击穿此类专利创造性的绝佳对比文件。

这份针对权利要求1的专利无效宣告可行性与对比文件检索分析报告，紧密结合权利要求书的方案逻辑以及三份对比文件（D1、D2、D3）的原文文本，进行逐特征的比对和深度法律/技术评估。

---

### 一、 权利要求1的技术方案理解与特征分解

#### 1. 权利要求1的核心技术方案解析

本专利权利要求1涉及一种多媒体流的传输与控制方法。其核心构思在于通过**三种互不相同的协议（Protocol 1, Protocol 2, Protocol 3）**在终端（第一终端、第二终端）与网关之间实现协同会话启动及相关多媒体流的发送/接收：

1. **终端与网关架构**：第一终端和第二终端均连接至至少一个网关。

2. **三协议协同触发机制**：

- **第一协议（Protocol 1）**：用于第一终端与网关之间启动第一多媒体会话信息的交换；

- **第二协议（Protocol 2）**：用于向第二终端发送触发（Trigger），且 Protocol 2 ≠ Protocol 1；

- **第三协议（Protocol 3）**：第二终端响应于该触发，使用 Protocol 3 启动其与网关之间的第二多媒体会话信息交换，且 Protocol 3 ≠ Protocol 2 且 Protocol 3 ≠ Protocol 1。

3. **流传输**：第一终端发送第一多媒体流，第二终端接收相关的第二多媒体流。

#### 2. 技术特征拆解（特征A~I）

- **特征A**：用于从第一终端发送多媒体流并且在第二终端接收相关的第二多媒体流的方法，其中，第一和第二终端被连接到至少一个网关以使能第一多媒体流的发送和第二相关流的接收；

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

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

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

- **特征E**：第二协议不同于第一协议；

- **特征F**：响应于提供所述触发；

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

- **特征H**：第三协议不同于第二协议和第一协议；

- **特征I**：从第一终端发送第一多媒体流并且在第二终端接收第二相关多媒体流。

---

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

#### 1. 对比文件1：US7043528B2（简称 D1）

* **公开号**：US7043528B2

* **方案概要**：公开了一种用于将视频会议连接到分布式网络（如Internet）的系统和方法。通过伪终端/数据捕获模块（Data Capture Module 190）与流模块（Streaming Module 110/Gateway）配合，捕获视频会议流并在分布式网络上进行单播/多播分发。

##### 原文比对分析：

- **特征A**：公开了终端（Video Conference End Point / Client）与流模块/网关（Streaming Module 110）连接，实现多媒体流传输。`[段落 [0021], [0040], [0042], 图2]`

- **特征B**：第一终端（例如视频会议终端 60/190）使用视频会议标准协议（如 H.323 / SIP / H.320，即第一协议）与网关/MCU/流模块进行会话控制与信息交换。`[段落 [0006], [0034], [0035]]`

- **特征C、D、E、F、G、H**：**未公开**。D1 中的客户端 210/220（如 RTSP 客户端或 MMS 客户端）主要通过 URL/超链接主动发起拉流请求`[段落 [0049]]`，并没有公开“使用与第一协议不同的第二协议向第二终端发送触发，第二终端再响应触发并使用与第一、第二协议均不同的第三协议来启动会话交换”的三协议协同触发逻辑。

- **特征I**：公开了第一终端发送视频会议流，客户端（第二终端）接收该多媒体流（或转码后的流）。`[段落 [0022], [0035]]`

---

#### 2. 对比文件2：US20060291472A1（简称 D2）

* **公开号**：US20060291472A1

* **方案概要**：公开了一种在通信网络（如 IMS）中通过“再生信令（Regenerative Signaling）”使服务终端能够透明使用网络服务的方法与架构。在 RTSP 客户端（终端 WT 102）、代理（CSP 140 / SSP 150，相当于网关）和视频服务器（VS 130）之间，利用 RTSP（Base Protocol）与 SIP（Companion Protocol）进行交互与 QoS 协商。

##### 原文比对分析：

- **特征A**：公开了无线终端（WT 102，第二终端）与视频服务器（VS 130，第一终端）连接至代理网关（CSP 140/SSP 150），使能视频流的发送与接收。`[段落 [0019]-[0021], 图1]`

- **特征B**：视频服务器（VS 130/第一终端）或客户端（WT 102）使用 RTSP 协议（Base Protocol，第一协议）与代理/网关（CSP/SSP）交换媒体会话信息（如 RTSP DESCRIBE / SETUP）。`[段落 [0018], [0046], [0052]-[0055]]`

- **特征C、D、E**：在图 4（段落 [0075]）中公开了：网关/代理（CSP 140）为了触发终端（WT 102）启动 RAN QoS 设置，向终端 WT 102 的 SIP-UA 模块发送一个 **SIP INVITE 消息**（使用 SIP 协议，即第二协议）。此处，SIP（第二协议）不同于 RTSP（第一协议）。`[段落 [0018], [0075]]`

- **特征F、G、H**：响应于该 SIP INVITE 触发，终端 WT 102 与服务节点（SN 106/网关）之间通过无线接入网信令协议/RAN QoS 协商信令（即第三协议，如 RAN 信令或特定 QoS 预留协议）进行 QoS 资源预留与会话建立。该第三协议不同于 RTSP（第一协议）和 SIP（第二协议）。`[段落 [0066], [0075]-[0077], 图4]`

- **特征I**：公开了视频服务器（VS 130）通过 RTP 发送视频流，终端（WT 102）接收该视频流。`[段落 [0018], [0043], [0063]]`

---

#### 3. 对比文件3：US20070025301A1（简称 D3）

* **公开号**：US20070025301A1

* **方案概要**：公开了移动网络中用于速率控制服务（Rate Control Service）的方法和系统。涉及终端（UE 358A/358B）、无线网络控制器（RNC 356A/356B）、代理（Proxy 360/GW）之间，通过 RTSP、SIP、RANAP、GTP-U、RRC 等多种协议配合建立会话并动态调整传输速率。

##### 原文比对分析：

- **特征A**：公开了第一终端（UE 358A）和第二终端（UE 358B）通过无线网络/网关（RNC/GGSN/Proxy）连接，进行多媒体/数据流传输。`[段落 [0207]-[0210], 图12]`

- **特征B**：终端通过应用层协议（如 SIP 或 RTSP，第一协议）启动会话信息交换（例如，UE 358A 发送 SIP INVITE 或 RTSP DESCRIBE）。`[段落 [0144], [0214], [0219]]`

- **特征C、D、E**：在图 13/图 15/图 16 中，公开了通过 SIP 协议（第二协议）将触发或控制参数传递至终端或对端网络节点（RNC/UE），且 SIP 不同于数据传输控制协议。`[段落 [0214], [0249]-[0251]]`

- **特征F、G、H**：响应于前述触发或设置，第二终端（UE 358B）通过 SM（Session Management，激活二次 PDP 上下文）/ RANAP / RRC 协议（第三协议）与网络/网关启动二次 PDP 上下文激活及会话资源协商。`[段落 [0215]-[0220], [0229]]`

- **特征I**：公开了在两终端间以协商好的速率进行多媒体/数据流的发送与接收。`[段落 [0230], [0247]]`

---

### 三、 权利要求1特征比对表格（Feature Comparison Table）

---

### 四、 最接近对比文件确定与创造性分析

#### 1. 整体技术问题与技术效果评估

目标专利要解决的核心技术问题在于：**在涉及不同终端和网关的多媒体传输场景中，如何跨越不同的网络/业务环境，实现高效、可靠的跨协议协同会话建立与流传输。**

- **D1 (US7043528B2)**：侧重于视频会议伪终端与分布式网络流媒体服务器之间的协议转换与单播/多播分发。其缺少“第二协议触发”以及“三协议协同”机制。

- **D2 (US20060291472A1)**：侧重于在 IMS 网络中，当终端/服务器不具备特定协议能力（如非 SIP 终端使用 RTSP）时，通过代理网关进行“信令再生（Regenerative Signaling）”，利用第一协议（RTSP）与第二协议（SIP）及第三协议（无线接入/QoS信令）完成端到端的服务协商与流建立。**其技术领域、网络拓扑架构以及解决“跨协议协同启动多媒体会话”的技术问题与目标专利最为接近。**

- **D3 (US20070025301A1)**：侧重于移动网络中的速率控制与资源协商（P2P / P2C 场景），同样揭示了通过应用层协议（SIP/RTSP）触发底层网络/终端管理协议（SM/RANAP/GTP）建立媒体会话与 QoS 调整的过程。

#### 2. 最接近对比文件的选择结论

**最接近对比文件推荐：D2（US20060291472A1）**（亦可以 **D3** 作为另一备选最接近对比文件）。

##### 创造性组合评估（D2 为主对比文件）：

1. **D2 已公开的技术特征**：D2 显式或实质公开了特征 A、B、C、D、E、F、G、H、I 的绝大部分技术内容。

- 在 D2 中，第一协议为 **RTSP**，第二协议为 **SIP**（代理 CSP 140 向 WT 102 发送 SIP INVITE 作为触发），第三协议为 **RAN QoS 预留协议/三层信令**（WT 102 响应触发后与网关 SN 106 启动 QoS 设置与会话交换）。

2. **区别特征与技术实质**：若本专利专利权人主张 D2 中“触发”的含义与本专利“第二终端启动多媒体会话”存在微小差异（例如 D2 的 SIP INVITE 主要是为了触发终端进行 RAN QoS 预留），则该区别特征已被 **D3 (US20070025301A1)** 明确公开。

- D3 在段落 [0214]-[0220] 及图 13 中明确揭示了：使用 SIP 协议（第二协议）向终端发送配置/触发信息后，终端响应于该触发，使用 SM（Session Management，第三协议）发起 Activate Secondary PDP Context Request，从而启动与网关（SGSN/RNC）之间的多媒体会话信息交换。

3. **结合启示**：D2 与 D3 均属于 3GPP/IMS 移动多媒体通信技术领域，面对的都是“如何在网关/网络节点控制下，通过多层协议协同建立多媒体 bearer/session”的技术问题。本领域技术人员在 D2 的基础上结合 D3 的教导是显而易见的，无需付出创造性劳动。因此，**权利要求1相对于 D2 与 D3 的结合不具备创造性（《专利法》第22条第3款）**。

---

### 五、 无效请求中最薄弱的技术特征与突破点

若提起无效宣告请求，本专利**最薄弱（最容易被攻破）的技术特征**为：

> **特征 C、F、G、H 的组合**：“使用第二协议提供触发到第二终端……响应于所述触发，第二终端使用不同于第一、第二协议的第三协议启动与网关的会话交换”

#### 理由分析：

1. **概念抽象与外延宽泛**：本专利权利要求1对“第一协议”、“第二协议”、“第三协议”及“触发”的限定非常上位和抽象，未限定具体的协议名称（如 RTSP、SIP、HTTP、GTP 等）。

2. **现有技术的全面覆盖**：在 3GPP IMS 架构（如 D2、D3 所揭示）中，**“应用层控制信令（如 RTSP/SIP） + 核心网/接入网会话建立信令（如 PDP Context / RANAP / RRC）”** 的多协议协同机制属于标准技术。代理或网关发送包含控制参数的消息（相当于“触发”），终端接收后使用底层网络协议发起 bearer/session 建立，完全落入了该权利要求的保护范围。

---

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

为了确保无效宣告请求的胜率达到最高（甚至实现单篇对比文件破坏新颖性/创造性 A 类文献击靶），建议采取以下进一步检索策略：

1. **扩展 3GPP 标准规范检索（最强杀伤力）**：

- **重点规范**：检索 3GPP TS 23.228（IP Multimedia Subsystem; Stage 2）、TS 23.207（End-to-end Quality of Service (QoS) concept and architecture）、TS 24.229 等标准文档。

- **检索逻辑**：3GPP 标准中关于“IMS 签名/SIP 信令触发终端发起二次 PDP 上下文（Secondary PDP Context Activation via SM/GTP protocol）以建立媒体流”的流程描述极其详尽，文本匹配度极高。

2. **分类号与关键词组合策略**：

- **IPC/CPC 分类号**：`H04L65/1016` (Session initiation), `H04L65/1069` (Session management), `H04L65/80` (QoS for media streaming), `H04L67/14` (Session management).

- **逻辑检索式构筑**：

`((gateway OR proxy OR controller) NEAR3 (trigger* OR prompt* OR invit*)) AND ((protocol OR signaling) NEAR5 (first OR second OR third OR different OR multiple))`

结合关键词：`RTSP`, `SIP`, `PDP context`, `session initiation`, `media stream`.

3. **专利族与优先权日追溯**：

- 重点关注爱立信（Ericsson）、诺基亚（Nokia）、华为（Huawei）、高通（Qualcomm）在 2004–2006 年间申请的 IMS 媒体会话建立与 QoS 触发相关专利，极易找到完全覆盖“三协议触发”架构的 102/A 类对质对比文件。

<FollowUp label="是否需要我针对 D2 与 D3 进一步撰写正式的《专利无效宣告请求书》意见陈述书草案？" query="请基于上述对比文件 D2 (US20060291472A1) 和 D3 (US20070025301A1) 的分析，为权利要求1撰写一份规范的无效宣告请求书意见陈述书草案（包含创造性不具备的详细对比论证）。"/>

您好！作为一名经验丰富的专利代理师，我针对您提供的权利要求文件（权利要求1.docx）以及三份对比文件（D1: US20070201484A1、D2: WO2007101473A1、D3: US07286521B1）进行了深入的法律与技术分析。

---

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

在目标专利的体系中，本发明旨在解决**跨不同协议架构下，如何在第一终端与网关建立多媒体会话期间，由网关/服务器灵活触发第二终端建立第二多媒体会话**的问题。

我们将权利要求1拆解为以下9个关键技术特征：

* **特征 A**：用于从第一终端发送多媒体流并且在第二终端接收相关的第二多媒体流的方法，其中，第一和第二终端被连接到至少一个网关以使能第一多媒体流的发送和第二相关流的接收。

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

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

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

* **特征 E**：第二协议不同于第一协议；

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

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

* **特征 H**：第三协议不同于第二协议和第一协议；

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

---

### 二、 对比文件技术特征比对表及分析（包含原文出处及公开性认定）

为了清晰明确，以下表述指代说明：

* **D1**：US20070201484A1（公开日：2007-08-30）

* **D2**：WO2007101473A1（公开日：2007-09-13）

* **D3**：US07286521B1（授权日：2007-10-23）

#### 1. 特征比对表格

---

### 三、 整体解决的技术问题、技术效果及最接近对比文件（最接近先验技术）分析

#### 1. 各对比文件的技术背景与解决问题分析

* **D1 (US20070201484A1)**：

* *技术问题*：解决在基于通道的通信协议（如3G-324M、SIP）呼叫建立及振铃等待阶段，如何向主叫终端提供定制化/交互式多媒体（如视频彩铃PVRB），并在被叫接通后实现会话平滑切换（Cutover）。

* *技术效果*：避免了传统音视频呼叫在等待接通时仅能播放单调回铃音的问题，实现了媒体流的灵活插播与多方跨接。

* **D2 (WO2007101473A1)**：

* *技术问题*：解决在IPTV系统与IMS融合架构下，如何高效进行时移/追看（Time-Shifting/Chase-Play）以及跨异构协议（如控制通道协议、SIP信令协议、Parlay-X Web服务及媒体流协议）进行呼叫通知与媒体流切换。

* *技术效果*：利用IMS架构和网络PVR限制“第一公里”的带宽占用，同时实现了控制信令、触发信令与媒体建立信令的三层分离（不同协议），极大提升了异构网络融合的灵活性。

* **D3 (US07286521B1)**：

* *技术问题*：解决如何在机房内部通过VoIP抽象电路交换网络（PSTN），利用SIP Proxy实现语音门户/电话应用平台的负载均衡与媒体流路由。

* *技术效果*：解耦了电路接口与处理服务器，提高了呼叫处理的扩展性。

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

**结论：对比文件 D2 (WO2007101473A1) 最适合作为最接近的对比文件（第一最接近对比文件）；D1 (US20070201484A1) 也可作为备选的第二最接近对比文件。**

* **选择 D2 的理由**：

1. **架构与问题最为契合**：D2完美对应了权利要求1中**“三协议分离”**（协议一、协议二、协议三互不相同）的架构设计。

2. **特征覆盖度最高**：D2在图1及图3（及其对应段落[p0046]-[p0090]）中，公开了：

* 第一终端与网关建立基于第一协议（如TCP/TLS/MSRP控制通道协议）的会话（特征B）；

* 使用第二协议（如Parlay-X Web Service / 应用层通知协议）向第二终端（STB）发送呼叫触发（特征C）；

* 第二终端响应触发后，使用第三协议（SIP协议）启动第二多媒体会话信息的交换（特征G/H）；

* 从而使能第一与第二终端间多媒体流的建立与接收（特征A、D、F、I）。

3. D2已经完全公开了权利要求1的所有技术特征。

* **备选 D1 的理由**：

* 如果目标专利侧重于“网关/B2BUA中继及媒体流切换/彩铃插播”这一业务场景，D1在网络拓扑（第一终端-B2BUA/网关-第二终端）上极其吻合，但D1在“三协议完全异构（协议1≠协议2≠协议3）”的交底上不如D2清晰。

---

### 四、 未被最接近对比文件公开的技术特征分析与最薄弱环节认定

#### 1. 特征被公开性结论

若以 **D2 (WO2007101473A1)** 作为最接近对比文件：

* **权利要求1的所有技术特征（A~I）均已被D2实质或毫无异议地公开。**

* 具体地：特征E（协议二≠协议一）与特征H（协议三≠协议二且协议三≠协议一）在D2的段落 [p0048]、[p0081]-[p0089] 以及图3中得到了完整显现（第一协议为TLS/TCP控制通道，第二协议为Parlay-X呼叫控制/Notification，第三协议为SIP信令协议）。

#### 2. 无效请求中最薄弱的技术特征（专利权人最可能进行抗辩的特征）

如果在专利无效宣告程序中发起攻击，专利权人最有可能争取并进行狭义解释的**“最薄弱特征”**（即我方攻击难度相对较高或需要严密论证的特征）为：

* **特征 H：第三协议不同于第二协议和第一协议**（以及结合特征E的“三协议完全异构”认定）。

* **薄弱原因/争点分析**：

1. 专利权人可能会将“第一协议”、“第二协议”、“第三协议”限定为**同一种网络层级上的信令**（例如全都是会话控制协议，如SIP、H.323、H.245）。

2. 在D1中，虽然存在多种协议（Q.931、ISUP、H.245），但第一终端和第二终端在终端侧使用的往往是同一种终端协议（如均使用H.324M或均使用SIP），容易被专利权人抗辩为“第一协议与第三协议相同”。

3. 在D2中，第一协议是TCP/TLS长连接控制通道，第二协议是Parlay-X/通知，第三协议是SIP。专利权人可能会抗辩D2的“第二协议（通知）”只是应用层消息，不属于严格意义上的“会话信息交换协议”。

* **代理师应对策略**：在无效申请书中，必须紧扣目标专利说明书对“协议”的宽泛定义，强调只要在语法、语义及通信规程上存在差异（如传输层/应用层控制信令 vs SIP会话信令），即构成“不同协议”，从而锁定D2对特征H的完全公开；同时利用D1作为公知常识/结合对比文件，证明在异构网络网关中采用不同协议进行触发和会话建立属于本领域的惯用技术手段。

---

### 五、 进一步的对比文件检索策略（针对无效请求的巩固）

为了确保在专利无效宣告程序中“一击必杀”，防止专利权人通过修改权利要求（例如将说明书中的具体协议名称、网关架构或媒体流切换细节补入权利要求1）来构建防线，建议采取以下进一步检索策略：

1. **聚焦 3GPP/ITU-T 标准规范检索（针对3G-324M / IMS / ICS 架构）**：

* **检索方向**：重点检索 3GPP TS 23.228（IMS概念）、TS 24.229、TS 23.218 以及 3G-324M（ITU-T H.324 Annex C）关于“IMS Centralized Services (ICS)”或“Service Control Signalling Path Decoupling”的早期标准提案（CR/Tdoc）。

* **关键词组合**：`(Gateway OR B2BUA) AND ("first protocol" OR "second protocol") AND (trigger OR notification) AND (SIP OR H.324M OR H.245)`。

2. **针对“三协议映射/网关触发”进行专利族与分类号精确检索**：

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

* `H04L 65/1069`（会话建立/协商中的协议转换或网关）

* `H04L 65/1016`（SIP与非SIP协议互通）

* `H04M 7/12`（不同通信系统之间的网关/协议映射）

* **追踪核心专利权人（同领域早期布局者）**：

* 重点检索 Dilithium Networks（D1的申请人）、Ericsson（D2的申请人）、Huawei、ZTE、Nokia 在 2005-2007 年间申请的网关协议转换与彩铃/交互媒体触发专利。

3. **防守型补充检索（针对从属权利要求的预演）**：

* 针对说明书中可能出现的“媒体流编解码协同（Transcoding）”、“I帧/关键帧延迟切换（Video Fast Update / Cutover Delay）”等技术点，提前准备好包含类似D1中[0131]-[0136]段（关于I-frame检测与Cutover）的防守对比文件，确保在专利权人缩小权利要求范围时依然能够予以无效。

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

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

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

根据权利要求4的方法，其中第一协议是会话启动协议（SIP）。

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

根据权利要求6的方法，其中第三协议是实时流协议（RTSP）。

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

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

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

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