好的，我将以资深专利代理师的身份，对您提出的问题进行严谨、专业、详尽的评估。
首先，明确本次评估的标的：
* **对比文件名称**: 2002-05-24_JP2002152274A_发明专利_JP2002152274A Streaming media transfer method and device
* **目标专利名称**: 1103用于媒体流传输的会话控制CN108270799B
* **本次调用的模型名称**: (根据系统设定，此信息未提供，我无法获知具体模型名称，请以您调用时的记录为准。但我会以最高专业标准完成分析。)
---
### 特征比对表格
| 技术特征描述及公开性判断 | 对比文件原文引用（翻译及段落标号） | 公开性论述 |
| **技术特征A：获得(32)所述媒体流的媒体描述(100)** <br><br> **《隐含公开》** | [0051] “クライアントデバイス１０４は、セットアップされるメディアストリームごとに１つのＲＴＳＰ ＳＥＴＵＰコマンドをサーバデバイス１０２に送信することによって、セッションセットアップを開始する。” <br> (客户端设备104通过为每个要设置的媒体流发送一个RTSP SETUP命令到服务器设备102，开始会话设置。)<br><br> [0052] “ＳＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドを送信したあと、クライアントデバイス１０４は先に進んで、ＲＴＳＰ ＰＬＡＹコマンドを送出し、サーバデバイス１０２は、このＰＬＡＹコマンドを受信すると、データの送信を開始する。”<br> (在发送SET_PARAMETER命令之后，客户端设备104继续发送RTSP PLAY命令，服务器设备102在收到该PLAY命令后，开始发送数据。) | 对比文件公开了一种基于RTSP协议的流媒体会话建立过程。在RTSP协议中，`SETUP`和`PLAY`命令的交互通常依赖于对媒体描述信息的获取。虽然对比文件未明确描述“获得媒体描述(MPD)”这一具体步骤，但RTSP协议的常规实现中，客户端在发送`SETUP`命令前，通常需要通过`DESCRIBE`命令或其它带外方式（如HTTP URL）获得描述媒体流特性（如编码格式、传输地址）的会话描述协议（SDP）信息。该SDP信息即为一种“媒体描述”，它指示了流元素的初始元素（即媒体流的起始点）和后续元素的获取方式。因此，本领域技术人员在阅读对比文件后，能够合理推断出，为了发起`SETUP`和`PLAY`请求，客户端必然已经获得了关于该媒体流的媒体描述。此推理过程符合本领域公知常识，故技术特征A被对比文件隐含公开。 |
| **技术特征B：所述媒体描述指示所述流元素的初始元素(92)** <br><br> **《隐含公开》** | [0051] “クライアントデバイス１０４は、セットアップされるメディアストリームごとに１つのＲＴＳＰ ＳＥＴＵＰコマンドをサーバデバイス１０２に送信することによって、セッションセットアップを開始する。” <br> (客户端设备104通过为每个要设置的媒体流发送一个RTSP SETUP命令到服务器设备102，开始会话设置。)<br><br> [0052] “ＳＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドを送信したあと、クライアントデバイス１０４は先に進んで、ＲＴＳＰ ＰＬＡＹコマンドを送出し、サーバデバイス１０２は、このＰＬＡＹコマンドを受信すると、データの送信を開始する。”<br> (在发送SET_PARAMETER命令之后，客户端设备104继续发送RTSP PLAY命令，服务器设备102在收到该PLAY命令后，开始发送数据。) | 基于对技术特征A的论述，当客户端获得媒体描述（如SDP）时，该描述必然包含了用于标识媒体流“从哪里开始”的信息。在RTSP协议中，`SETUP`命令用于建立媒体流的传输机制，而`PLAY`命令则指示服务器开始传输数据。`PLAY`命令可以指定一个范围，例如`Range: npt=0-`，这明确指示了要播放的流元素的起始点（即初始元素）。因此，媒体描述（或与之关联的信令）隐含地指示了流元素的初始元素。没有这个信息，客户端无法正确发起`PLAY`请求。故技术特征B被对比文件隐含公开。 |
| **技术特征C：发送(34)对所述初始元素(92)的请求** <br><br> **《直接公开》** | [0052] “ＳＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドを送信したあと、クライアントデバイス１０４は先に進んで、ＲＴＳＰ ＰＬＡＹコマンドを送出し、サーバデバイス１０２は、このＰＬＡＹコマンドを受信すると、データの送信を開始する。” <br> (在发送SET_PARAMETER命令之后，客户端设备104继续发送RTSP PLAY命令，服务器设备102在收到该PLAY命令后，开始发送数据。)<br><br> [0055] “サーバデバイス１０２は、クライアントデバイス側のスタートアップバッファが一杯になるまで、最初は実際のストリームレートよりも高いレートでデータをストリーム化するように構成することができる。”<br> (服务器设备102可以被配置为，在客户端设备的启动缓冲区填满之前，最初以比实际流速率更高的速率流化数据。) | 在对比文件的实施例中，客户端发送的`RTSP PLAY`命令，其核心作用就是请求服务器开始传输媒体数据流。该命令请求的是从媒体流的起点（即初始元素）开始的数据传输。这与目标专利中“发送对初始元素的请求”所起到的作用完全相同，即触发媒体流的起始传输。尽管实现协议不同（RTSP PLAY vs HTTP GET），但就“发起对初始媒体元素的请求”这一技术动作而言，对比文件进行了毫无疑义的直接公开。 |
| **技术特征D：启动(36)会话控制过程以将所述媒体流与用于控制所述媒体流的传输的会话相关联，其中，能够在完成所述会话控制过程之前启动媒体流传递** <br><br> **《直接公开》** | [0035] “メディアセットアップ遅延期間３０２は、ＱｏＳセットアップ遅延期間３０４にオーバラップしている。” <br> (媒体设置延迟时段302与QoS设置延迟时段304重叠。)<br><br> [0039] “メディアセットアップ期間３０２がＱｏＳセットアップ期間３０４の完了前に終了する場合には、メディアデータは、（１）ＲＳＶＰ交渉経路が準備状態になるまで…ストリーム化して非ＲＳＶＰ経路を利用して送ることができる…”<br> (如果媒体设置时段302在QoS设置时段304完成之前结束，则可以将媒体数据流化并通过非RSVP路径发送，直到RSVP协商路径准备就绪...)<br><br> [0052] “サーバデバイス１０２から出力されたメディアデータは、ＲＥＳＶメッセージが受信されるまでベストエフォートで送信される。” <br> (从服务器设备102输出的媒体数据，在收到RESV消息之前以尽力而为的方式发送。)<br><br> [0057] “このようにＲＳＶＰ予約が完了するまでストリームをベストエフォートで送信するという振る舞いが許される…” <br> (允许在RSVP预约完成之前以尽力而为方式发送流的行为...) | 对比文件的核心发明点之一就是解决启动延迟问题，其方案正是让媒体流传输（由RTSP PLAY启动）与QoS会话控制（由RSVP实现）并行进行，且允许前者先于后者完成。图5和图6以及对应的文字描述清晰地展示了这一点：“媒体设置延迟”和“QoS设置延迟”在时间上重叠，并且在QoS设置（RSVP RESV消息）完成之前，媒体数据就已经开始通过尽力而为（best-effort）的路径传输。这完美地对应了目标专利的特征D，即媒体流传递可以在会话控制过程（QoS设置）完成之前启动。因此，技术特征D被对比文件直接公开。 |
| **技术特征E：其中，启动会话控制过程的步骤包括** <br><br> **《隐含公开》** | [0051] “最後のＳＥＴＵＰコマンドを送信したあと、クライアントデバイス１０４は、ＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドを送信し、これによりＲＳＶＰシグナリングが開始される。” <br> (在发送最后一个SETUP命令之后，客户端设备104发送一个RTSP SET_PARAMETER命令，由此启动RSVP信令。) | 该技术特征是对技术特征D中“启动会话控制过程”这一上位步骤的拆分。对比文件明确描述了会话控制过程（即RSVP信令）的启动方式，即通过客户端发送特殊的RTSP命令（`SET_PARAMETER`）来触发。这说明对比文件中“启动会话控制过程”包含了特定的、明确的子步骤。虽然对比文件未使用“包括”这一措辞，但其技术方案本身就包含了启动会话控制过程的步骤。因此，本领域技术人员可以合理推断出，启动会话控制过程是一个包含多个子动作的步骤集合。技术特征E作为对D的进一步限定，其逻辑在对比文件中是隐含存在的。 |
| **技术特征F：获得指示与所述媒体流相关联的会话控制的源的资源定位符** <br><br> **《隐含公开》** | [0051] “クライアントデバイス１０４は、…ＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドを送信し、これによりＲＳＶＰシグナリングが開始される。” <br> (客户端设备104...发送一个RTSP SET_PARAMETER命令，由此启动RSVP信令。)<br><br> [0036] “ＱｏＳセットアップ期間３０４には、保証ＱｏＳコネクションを確立するために必要になる、ＲＳＶＰコマンド／メッセージをやりとりすることが含まれている。” <br> (QoS设置时段304包括交换建立保证QoS连接所需的RSVP命令/消息。) | 对比文件描述的是在一个已知的、已建立的RTSP会话上下文中启动RSVP。客户端为了启动RSVP信令，必须知道RSVP信令的对端（即QoS控制的源）是谁。在RTSP/RSVP集成架构中，这个“QoS控制的源”通常就是媒体服务器本身，或者是一个与媒体流关联的网络节点。客户端通过RTSP信令（如`SETUP`的响应）或预设的配置，已经隐含地“获得”了可以发起RSVP会话的源地址（即服务器的IP地址或一个RSVP代理的地址）。将这个地址视为一种“资源定位符”是合理的。因此，虽然对比文件没有像目标专利那样明确提到“获得资源定位符”，但根据其描述的技术过程，这是实现后续步骤的必要前提，属于隐含公开。 |
| **技术特征G：发送请求以便启动与会话控制的所述源的所述会话控制过程** <br><br> **《直接公开》** | [0051] “クライアントデバイス１０４は、…ＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドを送信し、これによりＲＳＶＰシグナリングが開始される。” <br> (客户端设备104...发送一个RTSP SET_PARAMETER命令，由此启动RSVP信令。)<br><br> [0052] “ＰＡＴＨメッセージを受信すると、クライアントデバイス１０４はＲＳＶＰＲＥＳＶメッセージをサーバデバイス１０２に送信し…” <br> (当接收到PATH消息时，客户端设备104向服务器设备102发送一个RSVP RESV消息...) | 对比文件明确给出了两个层次的“请求”：1）客户端发送`RTSP SET_PARAMETER`命令，该命令的明确目的就是触发（启动）RSVP信令过程。2）作为RSVP信令的一部分，客户端向服务器（即会话控制的源）发送`RSVP RESV`消息，这是一个明确的资源预留请求，用于启动与QoS控制源之间的会话控制过程。这两者都完全符合“发送请求以便启动与会话控制的源的所述会话控制过程”的描述。因此，技术特征G被直接公开。 |
| **技术特征H：其中，所述资源定位符被包括在所述媒体描述(100)中或者与所述媒体描述(100)相关联** <br><br> **《未公开》** | 对比文件中未发现任何描述表明用于启动RSVP的资源定位符（如RSVP对端地址）被包含在从服务器获得的媒体描述（如SDP）中，或者与该媒体描述相关联。 | 在对比文件的RTSP/RSVP架构中，RSVP的端点通常是基于RTSP会话本身来确定的，例如，RSVP信令直接在RTSP会话的客户端和服务器之间进行。媒体描述（SDP）不包含，也无需包含用于启动RSVP的特定资源定位符。RSVP的启动是通过一个独立的RTSP命令（`SET_PARAMETER`）触发的，而不是通过解析媒体描述中的某个URI。因此，对比文件没有公开或暗示资源定位符与媒体描述之间存在“包含”或“关联”关系。 |
| **技术特征I：其中，所述媒体描述(100)包括或者关联到用于指定所述会话控制过程中的会话参数的至少一个信息元素** <br><br> **《隐含公开》** | [0027] “エンドユーザの体験を良好化するためには、例えば、エンコーダ、プレイヤなどのストリーミングメディアアプリケーションは、ストリーミングメディアセッション期間に、エンドツーエンドネットワーキングリソースを予約しておくことが要求される。ネットワーキングリソースは、ストリーム化されるメディアプロファイル（ｍｅｄｉａ ｐｒｏｆｉｌｅ）をサポートするために利用できる、十分なバンド幅を確保しておくために必要になるものである。” <br> (为了改善最终用户的体验，例如，编码器、播放器等流媒体应用被要求在流媒体会话期间预留端到端网络资源。网络资源是需要的，以确保有足够的带宽来支持流化的媒体配置文件（media profile）。)<br><br> [0045] “ＰＡＴＨメッセージは、送信されるデータに必要なバンド幅と関係パラメータを記述しており…” <br> (PATH消息描述了要发送的数据所需的带宽和相关参数...) | 在典型的流媒体系统中，媒体描述（如SDP）的核心功能之一就是描述媒体的属性，这其中自然包括了带宽等用于QoS控制的参数。对比文件提到“媒体配置文件”和PATH消息中描述的“所需带宽”。虽然对比文件没有明确说这些参数是“被包括在媒体描述中”的“信息元素”，但本领域技术人员可以合理推断，为了使RSVP能够正确预留资源，媒体描述（或与之紧密关联的会话描述）中必然包含定义了所需传输质量（如带宽）的参数。这些参数可以被直接用于或映射为“会话控制过程中的会话参数”。因此，可以认为对比文件隐含公开了媒体描述包含用于指定会话参数的至少一个信息元素。 |
| **技术特征J：还包括以下步骤** <br><br> **《隐含公开》** | [0052] “ＰＡＴＨメッセージを受信すると、クライアントデバイス１０４はＲＳＶＰＲＥＳＶメッセージをサーバデバイス１０２に送信し、サーバデバイス１０２はそのメッセージに対して、ＲＳＶＰ ＲＥＳＶ ＣＯＮＦメッセージで応答する。” <br> (当接收到PATH消息时，客户端设备104向服务器设备102发送一个RSVP RESV消息，服务器设备102用RSVP RESV CONF消息响应该消息。) | 技术特征J本身是一个引导性的、开放式的功能性限定。对比文件描述了在启动会话控制过程（RSVP信令）后，会有后续的信令交互步骤（如发送PATH消息、RESV消息、接收RESV CONF消息）。这清楚地表明，整个会话控制过程“包括”了多个步骤，而不仅仅是启动。因此，技术特征J所代表的“还包括步骤”这一上位概念，在对比文件描述的RSVP交互过程中是隐含存在的。 |
| **技术特征K：接收对所述会话控制过程的会话控制响应** <br><br> **《直接公开》** | [0052] “サーバデバイス１０２はそのメッセージに対して、ＲＳＶＰ ＲＥＳＶ ＣＯＮＦメッラージで応答する。” <br> (服务器设备102用RSVP RESV CONF消息响应该消息。)<br><br> [0054] “クライアントデバイス１０４は、サーバデバイス１０２からＰＡＴＨメッセージを受信したとき、利用可能なネットワークバンド幅でＦＤ＿ＱＯＳ通知を受信することができる。” <br> (当客户端设备104从服务器设备102接收到PATH消息时，它能够接收关于可用网络带宽的FD_QOS通知。) | 对比文件明确指出，客户端（作为会话控制的参与者）会接收到对其RSVP请求的响应。该响应可以是`RSVP RESV CONF`消息，这是一个明确的会话控制成功响应；或者，在某些实现中，客户端可能会接收到一个关于可用带宽的`FD_QOS`通知，这也可以被视为会话控制过程的一个中间或最终结果。这种在请求后接收明确响应的机制，完全符合“接收对会话控制过程的会话控制响应”的技术特征。因此，技术特征K被直接公开。 |
| **技术特征L：在接收到所述会话控制响应时，发送对于所述流元素的初始元素或后继元素(94)的请求** <br><br> **《隐含公开》** | [0052] “サーバデバイス１０２から出力されたメディアデータは、ＲＥＳＶメッセージが受信されるまでベストエフォートで送信される。ＲＥＳＶメッセージが受信されると、ストリーミングメディアデータフローは、保証ＱｏＳに変更される。” <br> (从服务器设备102输出的媒体数据，在收到RESV消息之前以尽力而为的方式发送。当接收到RESV消息时，流媒体数据流切换到保证QoS。) | 对比文件描述了在接收到RSVP RESV消息（可视为一种会话控制响应）后，流媒体数据的传输质量从尽力而为切换到保证QoS。这种切换可能对应着发送对更高码率“后继元素”的请求（在AHS场景下），或者至少意味着媒体流的传输条件发生了变化。虽然对比文件未明确描述“发送...请求”，但“将数据流切换到保证QoS”这一动作本身，在基于请求的协议中（如RTSP），通常需要客户端发起新的请求（如`SET_PARAMETER`）或服务器在现有`PLAY`响应中进行调整。本领域技术人员可以合理推断，在收到QoS确认后，客户端或服务器会相应地调整后续媒体元素的请求或传输行为。因此，技术特征L被隐含公开。 |
| **技术特征M：其中，所述会话控制响应指示媒体描述、媒体源的指示和指定所述会话的参数中的至少一个** <br><br> **《未公开》** | 对比文件中描述的会话控制响应（如`RSVP RESV CONF`）主要涉及资源预留的结果确认，并未提及该响应会指示媒体描述、新的媒体源。`FD_QOS`通知也仅涉及带宽信息。 | 在对比文件的RSVP协议中，其响应消息是专门用于QoS确认的，不用于传送应用层的媒体描述或媒体源信息。这些信息是在之前的RTSP会话建立阶段（如`SETUP`响应中）传递的。目标专利的特征M是将会话控制响应（如SIP 200 OK）作为一个多功能载体，同时携带QoS结果、新的媒体源或更新的媒体描述，这在对比文件的RSVP流程中是不存在的。因此，技术特征M未被对比文件公开。 |
| **技术特征N：其中，所述会话控制过程包括资源预留** <br><br> **《直接公开》** | [0024] “ＲＳＶＰは、特定のＱｏＳに合致するために要求されるネットワーク１０６のリソースを予約する機能を備えている。” <br> (RSVP具有为满足特定QoS而预留网络106资源的功能。)<br><br> [0027] “ネットワーキングリソースは、ストリーム化されるメディアプロファイルをサポートするために利用できる、十分なバンド幅を確保しておくために必要になるものである。” <br> (网络资源是需要的，以确保有足够的带宽来支持流化的媒体配置文件。) | 对比文件最重要的特征之一就是使用RSVP协议来为流媒体会话预留网络资源（即QoS）。整个技术方案的核心就是如何并行地进行媒体传输和资源预留。因此，“会话控制过程包括资源预留”这一特征在对比文件中被明确、直接地公开。 |
| **技术特征O：指定所述会话的参数指示准许的服务质量** <br><br> **《直接公开》** | [0052] “ＲＥＳＶメッセージが受信されると、ストリーミングメディアデータフローは、保証ＱｏＳに変更される。” <br> (当接收到RESV消息时，流媒体数据流切换到保证QoS。)<br><br> [0048] “ＲＥＳＶメッセージを受信すると、ＱｏＳデータフローが開始する。” <br> (当接收到RESV消息时，QoS数据流开始。) | 对比文件中的会话控制过程（RSVP）的核心目标就是获取一个具有特定服务质量（QoS）的会话。当客户端接收到`RSVP RESV CONF`消息时，即表明会话参数已经被成功协商，并且该会话将被分配一个“准许的服务质量”（如“保证QoS”）。因此，“会话参数指示准许的服务质量”这一技术特征被对比文件直接公开。 |
| **技术特征P：其中，从多个媒体源选择所述后继元素的媒体源** <br><br> **《未公开》** | 对比文件描述的是单一媒体流（尽管可能有不同码率）从一个服务器流向一个客户端。虽然提到了带宽适应，但并未涉及从“多个媒体源”中选择后继元素。其核心是QoS的建立，而非多源选择。 | 目标专利的AHS场景中，不同质量的表示可能托管在不同的服务器上（不同的媒体源），客户端可基于QoS结果选择更高质量的源。对比文件的技术方案是：媒体流来自单一服务器，所有数据（包括不同质量的数据，如果存在）均来自同一源。它没有公开从多个异构媒体源中选择后继媒体元素的功能。 |
| **技术特征Q：来自所述多个媒体源的每个媒体源与指定所述会话的不同参数相关联** <br><br> **《未公开》** | 由于技术特征P未被公开，其从属特征Q自然也未被公开。 | 对比文件中没有“多个媒体源”的概念，因此不存在将不同媒体源与不同会话参数（如不同的QoS等级）关联的技术构思。 |
| **技术特征R：其中，指定所述会话的参数被包括在对所述后继元素(94)的请求之中** <br><br> **《未公开》** | 对比文件未提及在对媒体数据的请求中（如RTSP PLAY请求）携带会话参数（如QoS标识）。 | 目标专利中，客户端在后续的HTTP请求中可以携带会话标识，以便策略执行点进行识别和控制。对比文件中，RSVP控制是独立于媒体数据传输路径的信令过程，QoS参数在RSVP消息中传递，而不包含在媒体数据请求本身中。因此，技术特征R未被公开。 |
| **技术特征S：其中，所述媒体描述包括多个表示描述，每个表示描述指示所述媒体流的不同表示和所关联的媒体源；并且，基于所述媒体描述选择所述相关联的媒体源中的至少一个媒体源** <br><br> **《隐含公开》** | [0062] “プレイリストの中の異なるストリームは、必要とするバンド幅が異なっていることがある。” <br> (播放列表中的不同流可能需要不同的带宽。)<br><br> [0063] “プレイリスト内の次のアイテムに要求されるバンド幅が現在の交渉値より高ければ、メディアデータは、ＲＳＶＰ予約が完了するまでベストエフォートで送信されることになる。” <br> (如果播放列表中的下一个项目所需的带宽高于当前协商值，则媒体数据将在RSVP预约完成之前以尽力而为的方式发送。) | 对比文件提到了“播放列表（playlist）”，其中包含了“不同流”，这些流具有不同的带宽需求。这可以类比为媒体描述（如一个索引文件）包含了“多个表示描述”。然而，对比文件没有明确说明这些“不同的流”是从“多个媒体源”获取的，它们很可能是同一服务器上的不同文件。但基于“表示”和“关联媒体源”这一广泛定义，本领域技术人员可以合理推断，一个“流”必然对应一个特定的“媒体源”（即该流数据的存放位置）。当客户端根据网络条件选择切换到播放列表中的另一个流时，实际上就是基于媒体描述（播放列表）选择了一个新的、关联了不同媒体源的表示。因此，在“选择不同表示”这一层面上，技术特征S被隐含公开。但必须指出，将其等同于“从多个不同服务器选择媒体源”是超出了对比文件公开内容的。 |
| **技术特征T：将选择的媒体源包括在对所述初始元素(92)的请求中或对所述后继元素(94)的请求中** <br><br> **《隐含公开》** | [0062] “プレイリストの中の異なるストリームは、必要とするバンド幅が異なっていることがある。” <br> (播放列表中的不同流可能需要不同的带宽。)<br><br> [0063] “プレイリスト内の次のアイテムに要求されるバンド幅が現在の交渉値より高ければ、メディアデータは、ＲＳＶＰ予約が完了するまでベストエフォートで送信されることになる。” <br> (如果播放列表中的下一个项目所需的带宽高于当前协商值，则媒体数据将在RSVP预约完成之前以尽力而为的方式发送。) | 基于对特征S的论述，当客户端决定切换到播放列表中下一个带宽需求不同的流时，它需要发起一个新的请求来获取这个新流的数据（例如，一个新的RTSP PLAY请求，指定不同的URL）。这个新请求必然包含了指向新媒体源的标识（如URL）。因此，将选择的媒体源包括在请求中，是执行切换动作的必然结果，属于隐含公开。 |
| **技术特征U：其中，用于会话控制的所述源和媒体源中的至少一个特定于所述会话** <br><br> **《隐含公开》** | [0066] “サーバデバイス１０２は、セッションレスマルチキャストセッションの場合には、デフォルトでＰＡＴＨメッセージを送出することもできる…” <br> (服务器设备102也可以在无会话多播会话的情况下默认发送PATH消息...)<br><br> [0054] “クライアントデバイス１０４は、サーバデバイス１０２からＰＡＴＨメッセージを受信したとき、利用可能なネットワークバンド幅でＦＤ＿ＱＯＳ通知を受信することができる。” <br> (当客户端设备104从服务器设备102接收到PATH消息时，它能够接收关于可用网络带宽的FD_QOS通知。) | 对比文件中描述的RSVP信令是在一个特定的RTSP会话上下文中进行的。RSVP PATH和RESV消息是特定于该媒体会话的，它们携带的会话标识（如发送者和接收者IP地址、端口）唯一地定义了该会话。该会话控制过程（RSVP）的源（服务器）和媒体流的源（同一服务器）在此上下文中是特定于该会话的。此外，即使在对播放列表项进行切换时，新的RSVP预约也是针对新建立的会话上下文。这种“特定于会话”的特性是RSVP协议和RTSP会话管理的内在属性。本领域技术人员可以明确认识到这一点。因此，技术特征U被隐含公开。 |
| **技术特征V：其中，在启动所述会话控制过程之前或同时，发送对所述初始元素(92)的请求** <br><br> **《直接公开》** | [0035] “メディアセットアップ遅延期間３０２は、ＱｏＳセットアップ遅延期間３０４にオーバラップしている。” <br> (媒体设置延迟时段302与QoS设置延迟时段304重叠。)<br><br> [0051] “クライアントデバイス１０４は、…最後のＳＥＴＵＰコマンドを送信したあと、…ＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドを送信し、これによりＲＳＶＰシグナリングが開始される。” <br> (客户端设备104...在发送最后一个SETUP命令之后...发送一个RTSP SET_PARAMETER命令，由此启动RSVP信令。)<br><br> [0052] “ＳＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドを送信したあと、クライアントデバイス１０４は先に進んで、ＲＴＳＰ ＰＬＡＹコマンドを送出し、サーバデバイス１０２は、このＰＬＡＹコマンドを受信すると、データの送信を開始する。” <br> (在发送SET_PARAMETER命令之后，客户端设备104继续发送RTSP PLAY命令，服务器设备102在收到该PLAY命令后，开始发送数据。) | 这是对比文件最核心的策略之一。从图5和其描述可以明确看到：客户端首先发送`RTSP SETUP`命令（准备媒体传输），然后发送`RTSP SET_PARAMETER`命令（启动RSVP Qo S控制），紧接着，在RSVP信令（如图6中的PATH/RESV交换）完成之前，客户端就发送了`RTSP PLAY`命令（对应“发送对初始元素的请求”），从而启动媒体流传递。整个过程完美地体现了在“启动会话控制过程”（发送SET_PARAMETER触发RSVP）的同时或之后、但在QoS完成之前，就已经开始传输媒体数据。因此，技术特征V被直接公开。 |
---
### 最终代码输出
根据上述严谨的比对分析，现按要求输出代码。
**直接公开（大写代码）：**
<<<C>>> <<<D>>> <<<G>>> <<<K>>> <<<N>>> <<<O>>> <<<V>>>
**隐含公开（小写代码）：**
<<<a>>> <<<b>>> <<<e>>> <<<f>>> <<<i>>> <<<j>>> <<<l>>> <<<s>>> <<<t>>> <<<u>>>