对比文件的名称：2004-09-23_US2004184432A_发明申请_US20040184432A1 Method for controlling streaming services
目标专利的名称：2086用于发送多媒体流的方法和系统CN101953136B
本次调用的模型名称：Claude
### 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用（翻译） | 公开性论述 |
| **技术特征A**：第一和第二终端被连接到至少一个网关以使能第一多媒体流的发送和第二多媒体流的接收（隐含公开） | [0028] “终端通过GGSN接入IMS网络，IMS由CPS实体代表，该实体包含CSCF功能并与SIP应用服务器协作”；[0047]步骤1：“UE发送SIP INVITE到SIP应用服务器”；[0052]步骤6：“SIP应用（运行在应用服务器AS上）利用来自INVITE和流服务器SS的信息建立相应的RTSP SETUP消息”；[0064]步骤18：“媒体开始在UE和流服务器之间流动”。 | 对比文件中UE（接收多媒体流的终端）和SS（发送多媒体流的服务器）均连接到包含AS的IMS网络，AS作为SIP-RTSP信令网关处理UE与SS之间的会话建立与协商，使得SS发送的媒体流能被UE接收。AS承担了目标专利中“网关”的角色（连接不同协议域的中间设备），因此本领域技术人员可以合理推断该配置隐含公开了“终端连接到网关”的方案。 |
| **技术特征B**：第一终端使用第一协议启动在第一终端和网关之间的第一多媒体会话信息的交换（未公开） | [0047]步骤1：“UE发送SIP INVITE到SIP应用服务器”。（UE是接收端，非发送端） | 目标专利中第一终端是发送多媒体流的一方，而对比文件中发起SIP会话的UE是接收流的一方；发送流的一方（SS）没有主动使用任何协议启动与AS的会话，而是由AS代表接收端发起RTSP信令。因此未公开该特征。 |
| **技术特征C**：使用第二协议提供触发到第二终端（未公开） | 全文中无“触发（trigger）”或类似明确用于通知第二终端启动会话的消息；仅存在[0047]步骤9：“AS发送SIP 200 OK给UE”作为对INVITE的响应。 | 对比文件没有独立于请求的触发消息，AS的响应是对终端请求的回复，并非目标专利中由网关主动发出的、用以启动第二终端会话的触发。故未公开。 |
| **技术特征D**：以启动在第二终端和网关之间的第二多媒体会话信息的交换（未公开） | 同C，无触发机制。 | 由于C未公开，D作为其目的也未公开。 |
| **技术特征E**：响应于提供所述触发（未公开） | 无触发，故无响应。 | 未公开。 |
| **技术特征F**：第二终端使用第三协议启动在第二终端和网关之间的第二多媒体会话信息的交换（未公开） | [0062]步骤16：“UE使用RTSP直接向流服务器发起RTSP PLAY”。（RTSP目标为SS，非AS） | 目标专利中第二终端应使用第三协议（如RTSP）与网关建立会话，但对比文件中UE与AS之间无RTSP会话，UE直接与SS进行RTSP通信，AS并未作为RTSP服务器出现。因此未公开。 |
| **技术特征G**：第三协议不同于第二协议（未公开） | 无触发，且第二协议未定义。 | 无法比较。未公开。 |
| **技术特征H**：从第一终端发送第一多媒体流并且在第二终端接收第二多媒体流（直接公开） | [0064]步骤18：“媒体开始在UE和流服务器之间流动”。（流从SS流向UE） | 对比文件中SS作为发送端（第一终端对应角色）发送多媒体流，UE作为接收端（第二终端对应角色）接收多媒体流，媒体流内容相同。该特征被明确公开，本领域技术人员能毫无疑义地确定发送与接收的实现。 |
| **技术特征I**：第一多媒体会话信息的交换包括向第一终端提供至少部分第二多媒体会话信息（隐含公开） | [0052]步骤6：“SIP应用利用来自INVITE的UE传输参数和来自SS的信息，建立相应的RTSP SETUP消息，该消息包含UE的传输参数”。（AS向SS提供UE的参数，即第二终端的信息） | 目标专利中第一多媒体会话信息交换包含网关向第一终端提供第二终端的会话信息。对比文件中AS（网关角色）通过SETUP消息向SS（第一终端角色）提供了UE（第二终端）的传输参数，这些参数属于第二多媒体会话信息。虽然角色映射稍作调整，但实质相同，本领域技术人员能合理推断该技术手段已被公开。 |
| **技术特征J**：由此响应所述提供开始从第一终端发送第一多媒体流（未公开） | [0053]步骤7：“流服务器响应SETUP发送SIP 200 OK”；[0062]步骤16：“UE随后发出RTSP PLAY”；[0064]步骤18：“媒体开始流动”。 | 对比文件中SS收到提供信息（SETUP）后并未立即开始发送流，而是等待UE的PLAY命令。因此“响应提供立即开始发送”未被公开。 |
| **技术特征K**：第二多媒体会话信息的交换包括向第二终端提供至少部分第一多媒体会话信息（隐含公开） | [0054]步骤9：“应用服务器形成SIP 200 OK消息...包含来自流服务器SS和UE两者的共同SDP描述”。（AS向UE提供SS的SDP信息） | 目标专利中第二多媒体会话信息交换包含网关向第二终端提供第一终端的会话信息。对比文件中AS通过200 OK消息向UE（第二终端）提供了SS（第一终端）的会话描述信息，符合该特征，因此隐含公开。 |
| **技术特征L**：由此响应于所述提供开始由第二终端接收第二多媒体流（隐含公开） | [0062]步骤16：“UE收到对INVITE的响应后，直接进行RTSP PLAY”；[0064]步骤18：“媒体开始流动”。 | 对比文件中UE在收到包含第一终端信息的200 OK后，立即启动RTSP PLAY并开始接收流。提供（200 OK）与接收开始具有因果关联，本领域技术人员能合理认定该特征已被公开。 |
| **技术特征M**：第一协议是对等型协议（未公开） | [0047]步骤1：UE使用SIP（对等型）发出INVITE，但UE是接收端，非第一终端；第一终端SS未使用对等型协议与AS通信。 | 目标专利中第一协议为第一终端与网关间的协议且为对等型。对比文件中发送端SS与AS之间使用RTSP（客户端-服务器型），不符合对等型；而使用SIP的UE是接收端，不是第一终端。因此未公开。 |
| **技术特征N**：其中所述对等型协议是会话启动协议(SIP)（未公开） | 同M。 | 基于M未公开，N未公开。 |
| **技术特征O**：第三协议是客户端-服务器型协议（直接公开） | [0004]“实时流协议（RTSP）是流媒体协议之一”；[0062]步骤16：“UE进行RTSP PLAY”。（UE作为RTSP客户端，SS作为RTSP服务器） | 目标专利中第三协议用于第二终端与网关之间，且为客户端-服务器型。对比文件中UE（第二终端）使用RTSP与SS通信，RTSP明确是客户端-服务器型协议（客户端发起请求，服务器响应）。该特征被直接公开。 |
| **技术特征P**：其中所述客户端-服务器型协议是实时流协议(RTSP)（直接公开） | [0004]“One example for these is the RTSP (real time streaming protocol)”；[0047]步骤4：AS使用RTSP DESCRIBE与SS通信。 | 对比文件大量提及RTSP作为流控制协议，并且UE和SS之间直接采用RTSP，因此RTSP作为客户端-服务器型协议被直接公开。 |
| **技术特征Q**：其中提供触发到第二终端的步骤是由网关启动的（未公开） | 无触发机制。 | 无相关描述。未公开。 |
| **技术特征R**：第一多媒体会话信息的交换包括提供第二终端的标识符给网关（隐含公开） | [0047]步骤1：“INVITE消息包含关于媒体内容和流服务器的足够信息”。（UE提供流服务器标识给AS） | 目标专利中第一终端在会话信息交换中向网关提供第二终端的标识符。对比文件中UE（若视为第一终端，尽管其为接收端）在SIP INVITE中向AS（网关）提供了流服务器（第二终端对应角色）的标识（如rtsp URL）。尽管角色不完全一致，但本质相同，本领域技术人员能合理推断该手段已被对比文件公开。 |
| **技术特征S**：其中该方法包括在提供触发给第二终端之前（未公开） | 无触发。 | 未公开。 |
| **技术特征T**：将第二终端的标识符解析成网络地址的附加步骤（未公开） | 无触发及解析步骤的明确记载。 | 对比文件未提及地址解析过程。未公开。 |
| **技术特征U**：其中第一和第二协议相同（未公开） | 第一协议未准确定义，第二协议未定义。 | 无法确定。未公开。 |
| **技术特征V**：其中第一多媒体流是与第二多媒体流相同的多媒体流（直接公开） | [0064]步骤18：“媒体开始在UE和流服务器之间流动”。（同一媒体流从SS流向UE） | 对比文件中SS发送的流和UE接收的流是完全相同的媒体内容，没有转换或替换，因此该特征被直接公开。 |
---
### 公开性代码输出
基于上述分析，对比文件直接或隐含公开了以下技术特征：
<<<H>>><<<O>>><<<P>>><<<V>>><<<a>>><<<i>>><<<k>>><<<l>>><<<r>>>