**对比文件名称：** 2006-12-28_US2006291472A1 Method and apparatus for utilizing network services in a manner substantially transparent to service endpoints
**目标专利名称：** 用于发送多媒体流的方法和系统 CN105208020B
**调用模型名称：** 深度模型
### 特征比对表格
| 技术特征描述及公开性判断 | 对比文件原文引用（中文翻译） | 公开性论述 |
| **技术特征A**：第一和第二终端被连接到至少一个网关以使能第一多媒体流的发送和第二相关流的接收。 | 【0020】无线终端(WT)102、视频服务器(VS)130、客户端侧代理(CSP)140、服务器侧代理(SSP)150。 <br> 【0039】RSP 160包括服务端点之间的端到端RTSP信令路径。 <br> 【0043】RBP 180在WT 102和VS 130之间建立。 | **《直接公开》**。对比文件明确公开了系统架构：无线终端（WT 102，相当于第一终端）和视频服务器（VS 130，相当于第二终端）通过客户端侧代理（CSP 140）和服务器侧代理（SSP 150）构成的网关进行通信。通过RTSP信令路径(RSP 160)和RTP承载路径(RBP 180)，实现了多媒体流从第一终端（WT 102）发送并在第二终端（VS 130）接收，与目标专利中终端通过网关收发多媒体流的作用完全相同。 |
| **技术特征B**：使用第一协议启动在第一终端和网关之间的第一多媒体会话信息的交换。 | 【0052】在步骤202，由WT 102的RTSP客户端部分发起RTSP DESCRIBE消息。该RTSP DESCRIBE消息被重定向到CSP 140。CSP 140读取该RTSP DESCRIBE消息以获取与至少一个网络服务相关的服务信息。 <br> 【0054】在步骤214，WT 102的RTSP客户端部分发起RTSP SETUP消息。 | **《直接公开》**。对比文件公开了第一终端（WT 102）使用第一协议（RTSP协议）启动与网关（CSP 140）的多媒体会话信息交换的操作。例如，WT 102通过发起RTSP DESCRIBE和RTSP SETUP消息来启动会话信息（如SDP参数、端口信息）的交换，这与目标专利中第一终端使用第一协议启动与网关的会话信息交换的作用相同。 |
| **技术特征C**：使用第二协议提供触发到第二终端。 | 【0057】在步骤228，响应于RTSP PLAY消息，CSP 140向VS 130发起一个SIP INVITE消息。 <br> 【0061】CSP 140和SSP 150之间的SIP伙伴协议消息用于执行IMS QoS授权处理。 | **《隐含公开》**。对比文件公开了使用第二协议（SIP）提供触发，但该触发并非直接发送到第二终端（VS 130）本身，而是发送到与VS 130对应的服务器侧代理（SSP 150），用于为VS 130配置网络服务。虽然触发目标不同，但对比文件部分公开了“使用SIP作为第二协议来产生并发送触发消息”这一概念。本领域技术人员可以合理推断，该触发机制可以扩展为直接发送到第二终端以通知其准备接收。 |
| **技术特征D**：以启动在第二终端和网关之间的第二多媒体会话信息的交换。 | 【0059】在步骤232，S-CSCF 122将SIP INVITE消息发送到SSP 150，在该处SIP INVITE消息由SSP 150终止，以使得SIP消息对VS 130透明。 <br> 【0060】在步骤234，SSP 150响应于SIP INVITE消息发起SIP 200 OK消息。 | **《隐含公开》**。对比文件公开了启动代理间（即CSP和SSP，SSP代表VS 130作为网关一部分）的第二多媒体会话信息交换（SIP会话）。虽然该交换发生在网关内部组件间，而非直接与第二终端进行，但公开了响应于触发（SIP INVITE），启动网络侧（SSP端）多媒体会话信息交换的核心过程。本领域技术人员可以合理推断，该信息交换能够被适配为直接启动第二终端与网关的会话信息交换。 |
| **技术特征E**：第二协议不同于第一协议。 | 【0018】在一个实施例中，基础协议（第一协议）包括实时流协议(RTSP)...伙伴协议（第二协议）包括会话启动协议(SIP)。 | **《直接公开》**。对比文件明确描述第一协议是RTSP，第二协议是SIP，两者是不同的协议。这与目标专利权利要求中第二协议不同于第一协议的技术特征完全一致。 |
| **技术特征F**：响应于提供所述触发。 | 【0061】CSP 140和SSP 150之间的SIP伙伴协议消息用于执行IMS QoS授权处理...如果IMS QoS授权处理成功，CSP 140就会向VS 130转发RTSP PLAY消息。 | **《直接公开》**。对比文件公开了网关（CSP 140）在提供触发（SIP INVITE消息）并接收到响应（SIP 200 OK消息）后，执行后续动作（例如，在QoS授权成功后，释放RTSP PLAY消息）。这直接体现了响应于提供触发所执行的操作。 |
| **技术特征G**：第二终端使用第三协议启动在第二终端和网关之间的第二多媒体会话信息的交换。 | 【0053】在步骤208，VS 130发起一个RTSP 200 OK消息。<br>【0055】在步骤220，VS 130发起一个RTSP 200 OK消息。<br>【0063】在步骤250，RTP承载信令路径在VS 130和WT 102之间建立，VS 130开始向WT 102流式传输视频内容。 | **《直接公开》**。对比文件公开了第二终端（VS 130）使用第三协议（RTSP/RTP协议）与网关（CSP 140/SSP 150）交换会话信息。VS 130通过发起RTSP 200 OK消息和建立RTP路径来完成多媒体会话信息（如端口、流传输地址）的交换和多媒体流的传输，这与目标专利中第二终端使用第三协议与网关交互的作用相同。 |
| **技术特征H**：第三协议不同于第二协议和第一协议。 | 【0018】基础协议（第一协议）包括实时流协议(RTSP)...伙伴协议（第二协议）包括会话启动协议(SIP)。<br>【0043】视频内容使用RTP协议传输。 | **《直接公开》**。对比文件明确第一协议是RTSP，第二协议是SIP，而用于承载媒体数据的第三协议是RTP（虽然RTSP用于会话控制，RTP用于实际数据传输，但正如目标专利所披露的，第三协议是用于交换会话信息的协议，在对比文件中RTSP是基础协议，与RTP相关联，其功能不同）。这里第三协议RTP显著不同于RTSP和SIP。本领域技术人员可以明确区分三种协议。 |
| **技术特征I**：从第一终端发送第一多媒体流并且在第二终端接收第二相关多媒体流。 | 【0063】在步骤250，RTP承载信令路径在VS 130和WT 102之间建立，VS 130开始向WT 102流式传输视频内容。 | **《直接公开》**。对比文件明确公开了多媒体流从第一终端（视频服务器VS 130）发送，并在第二终端（无线终端WT 102）接收，从而实现了多媒体流的单向传输。虽然第一终端和第二终端的角色（服务器/客户端）与目标专利中描述的（用户设备/演播室）按字面略有差异，但实现的“从一端发送到另一端接收”的技术方案和效果完全相同。 |
| **技术特征J**：其中第一多媒体会话信息的交换包括向第一终端提供至少部分第二多媒体会话信息。 | 【0047】CSP 140记录由WT 102和VS 130使用基础协议消息（例如RTSP消息）协商的SDP参数、端口、CODEC等网络服务参数。<br>【0049】SSP 150使用VS 130在RTSP消息交换期间公布的SDP和记录的RTSP协商端口等信息来代表VS 130在CSP 140和SSP 150之间建立SIP会话。 | **《隐含公开》**。对比文件公开了第一多媒体会话信息（RTSP）交换过程中，网关（CSP和SSP）获知了第二终端（VS 130）的会话信息（如SDP参数、端口）。然而，对比文件未明确将这些信息提供给第一终端（WT 102），而是用于建立网络服务会话。本领域技术人员可以合理推断，在RTSP会话建立过程中，这些信息必然通过代理被传递或可用于指导第一终端的发送，但基于严格标准，其公开程度不足以构成直接公开，故认定为隐含公开。 |
| **技术特征K**：由此响应所述提供开始从第一终端发送第一多媒体流。 | 【0062-0063】在SIP伙伴协议消息成功完成后，CSP 140释放RTSP PLAY消息给VS 130，随后在步骤250建立RTP路径，开始流式传输。 | **《隐含公开》**。对比文件公开了在完成第二相关多媒体会话信息（SIP）的交换后（相当于“响应”），开始从第一终端（VS 130）发送第一多媒体流。虽然响应条件和具体机制（QoS验证通过后释放PLAY消息）与目标专利的表述不完全相同，但本领域技术人员可以理解，其“基于提供/完成信息交换动作，触发流开始发送”的逻辑与目标专利一致。 |
| **技术特征L**：其中第二多媒体会话信息的交换包括向第二终端提供至少部分第一多媒体会话信息。 | 【0048】CSP 140使用从基础协议消息中获得的如用户IP地址、SDP等信息，生成SIP INVITE消息。 | **《未公开》**。对比文件公开了网关（CSP）将第一终端（WT 102）的会话信息（如IP、SDP）用于向第二终端侧（SSP 150）发起会话请求（SIP INVITE），但并未明确描述将这些信息直接提供回第二终端（VS 130）。网关是代表第一终端与第二终端侧沟通，而非将信息传递给第二终端本身。本领域技术人员无法毫无疑义地推导出该特征。 |
| **技术特征M**：由此响应于所述提供开始由第二终端接收第二相关多媒体流。 | 【0063】在步骤250，RTP承载信令路径在VS 130和WT 102之间建立，VS 130开始向WT 102流式传输视频内容。 | **《未公开》**。该特征（M）与特征（K）对应，强调接收流的开始。对比文件中，接收流（WT 102接收）的开始是建立在网络服务（SIP）授权和承载建立（RTP）成功的基础上，并非直接响应于网关向第二终端提供第一终端的会话信息。其触发机制与目标专利不同，且未明确公开此类直接因果关系。 |
| **技术特征N**：其中第一协议是对等型协议。 | 【0088】在另一个实施例中，SIP被用作基础协议（第一协议），而RTSP被用作伙伴协议（第二协议）。<br>SIP是一种对等型协议。 | **《隐含公开》**。对比文件的主要实施例中第一协议是RTSP（客户端-服务器型），但其明确公开了在另一实施例中，SIP（一种对等型协议）可以作为第一协议。本领域技术人员能够认识到，当使用SIP作为第一协议时，就构成了与目标专利相同的“第一协议是对等型协议”的技术特征。对比文件的公开具有教导性，使得该特征成为在另一变换下可以合理推得的方案。 |
| **技术特征O**：其中第一协议是会话启动协议（SIP）。 | 【0088】在另一个实施例中，SIP被用作基础协议（第一协议），而RTSP被用作伙伴协议。 | **《隐含公开》**。同特征N，对比文件明确公开了可以使用SIP作为第一协议。本领域技术人员能够认识到，该替换为常规技术手段，当采用该替换时，即公开了技术特征O。 |
| **技术特征P**：其中第三协议是客户端-服务器型协议。 | 【0018】在一个实施例中，基础协议（第一协议）包括实时流协议(RTSP)。<br>RTSP是一种客户端-服务器型协议。 | **《直接公开》**。对比文件中，用于第一终端和第二终端之间多媒体流会话信息交换的核心协议是RTSP。RTSP是业界公认的客户端-服务器型协议，其中服务器（如VS 130）提供服务，客户端（如WT 102）发起请求。该协议类型与目标专利中第三协议的类型完全相同。 |
| **技术特征Q**：其中第三协议是实时流协议（RTSP）。 | 【0018】在一个实施例中，基。础协议（第一协议）包括实时流协议(RTSP)。<br>【0039】RSP 160包括服务端点（WT 102和VS 130）之间的端到端RTSP信令路径。 | **《直接公开》**。对比文件全文大量公开了使用RTSP作为终端间进行多媒体会话信息交换（描述、建立、播放等）的协议。RTSP正是实现流控制的核心协议，与目标专利中第二终端使用的第三协议完全一致。 |
| **技术特征R**：其中提供触发到第二终端的步骤是由网关启动。 | 【0057】在步骤228，响应于RTSP PLAY消息，CSP 140向VS 130发起一个SIP INVITE消息。<br>CSP 140即为网关。 | **《直接公开》**。对比文件明确公开了提供触发（SIP INVITE消息）的步骤是由客户端侧代理（CSP 140）启动的。该代理在整体架构中充当网关的角色（负责协议转换和会话协调），这与目标专利中“由网关启动提供触发”的技术特征完全一致。 |
| **技术特征S**：其中第一多媒体会话信息的交换包括提供第二终端的标识符给网关。 | 【0029】在一个实施例中，L4/7-S 142使用目的TCP端口554将客户端发起的RTSP消息重定向到CSP 140。<br>【0046】从WT 102发出的RTSP消息被重定向到CSP 140。<br>RTSP消息的目标地址/URI隐含了VS 130的标识符。 | **《隐含公开》**。对比文件描述了第一终端（WT 102）发起的RTSP消息通过重定向机制到达网关（CSP 140）。虽然未明确描述为“提供第二终端的标识符”，但第一终端发出的RTSP消息中必然包含了用于路由和识别的信息（如VS 130的URI或IP地址），这些信息构成了第二终端的标识。本领域技术人员可以合理推断，这类标识必然通过会话信息交换的一部分被提供给了网关。 |
| **技术特征T**：其中该方法包括在提供触发给第二终端之前。 | 【0057】在步骤228，响应于RTSP PLAY消息，CSP 140发起SIP INVITE。之前的步骤202-224为RTSP消息交换。 | **《未公开》**。对比文件描述了在提供触发（发起SIP INVITE）之前，进行了RTSP消息交换。但这与目标专利强调的“在提供触发前”进行特定动作（如下文的“将标识符解析成网络地址”）不同。对比文件未明确公开在触发前需要完成的特定预处理步骤。 |
| **技术特征U**：将第二终端的标识符解析成网络地址的附加步骤。 | 全文未明确公开此具有步骤。 | **《未公开》**。对比文件虽提及了标识符（如SIP URI）和网络地址的转换可能性（例如，通过L4/7开关进行重定向），但并未公开在提供触发前执行一个**独立的** “将第二终端标识符解析成网络地址”的步骤。本领域技术人员无法从对比文件的内容中毫无疑义地推导出该特定步骤。 |
| **技术特征V**：其中第一多媒体流是与第二相关多媒体流相同的多媒体流。 | 【0043】RBP 180在WT 102和VS 130之间建立。换句话说，视频内容使用由SSP 170信令建立的保证QoS，通过RBP 180从VS 130流式传输到WT 102。 | **《直接公开》**。对比文件描述了多媒体流（视频内容）从第一终端（VS 130）通过承载路径（RBP 180）直接流式传输到第二终端（WT 102），中间没有缓冲、转码或生成不同的“第二相关多媒体流”的描述。因此，对于第二终端来说，接收到的就是第一终端发送的原始多媒体流，即两者是相同的流。 |
### 结论
<<<A>>><<<B>>><<<E>>><<<F>>><<<G>>><<<H>>><<<I>>><<<P>>><<<Q>>><<<R>>><<<V>>><<<j>>><<<k>>><<<n>>><<<o>>><<<s>>>