## 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| 技术特征A：所述方法包括:确定所述多媒体内容的第一表示的切换点之间的第一间隔和所述多媒体内容的第二表示的切换点之间的第二间隔，<br>《直接公开》 | [0063] “The encoder 110 generates trick play data by encoding input media content into frames at a predetermined bit rate. When the trick play data is generated, the encoder 110 may encode the media content by using only intra-frames, or intra- and inter-frames. The intra (I)-frames are frames encoded by using information of only corresponding frames.”<br> [0065] “For example, in a method of providing a trick play service by using multiple streams according to an exemplary embodiment, the number of pieces of the trick play data may be determined based on a maximum trick play speed. In this case, if the maximum trick play speed is 16× and the trick play service is provided in units of multiples of two, the number of pieces of the trick play data is 4 and the trick play data includes a piece of trick play data corresponding to a 2× trick play speed, a piece of trick play data corresponding to a 4× trick play speed, a piece of trick play data corresponding to a 8× trick play speed, and a piece of trick play data corresponding to a 16×trick play speed.” <br> [0112] “For example, first trick play data 510 corresponding to a 2× trick play speed is formed by extracting a frame as an I-frame every 2 seconds, and a decoder trick-plays a frame corresponding to a 2× trick play speed every 2 seconds. Second trick play data 520 corresponding to a 4× trick play speed may be formed by reducing a frame rate of the trick play data 510 corresponding to a 2× trick play speed by half.” | 根据目标专利说明书（例如[0080]段），切换点（SP）是关键帧，例如帧内译码（I）帧。对比文件明确公开了生成用于特技播放（如快进）的多个“trick play data”（可视为“表示”），这些数据由I帧组成（[0063]段）。并且，对比文件具体描述了不同速度的“trick play data”中I帧的提取频率：例如，2倍速数据每2秒提取一个I帧，4倍速数据每4秒提取一个I帧（[0112]段）。本领域技术人员能够从这些描述中，确定不同表示（如2倍速表示和4倍速表示）中切换点（I帧）之间的间隔（2秒和4秒）。因此，技术特征A被对比文件直接公开。 |
| 技术特征B：其中所述第一间隔小于所述第二间隔<br>《直接公开》 | [0112] “For example, first trick play data 510 corresponding to a 2× trick play speed is formed by extracting a frame as an I-frame every 2 seconds... Second trick play data 520 corresponding to a 4× trick play speed may be formed by reducing a frame rate of the trick play data 510 corresponding to a 2× trick play speed by half.” | 对比文件直接公开了2倍速表示的I帧间隔（每2秒一个）小于4倍速表示的I帧间隔（每4秒一个）。因此，技术特征B被对比文件直接公开。 |
| 技术特征C：基于所述确定，提交对来自所述第一表示的相当数量的视频数据的一个或多个网络请求，来自所述第一表示的相当数量的视频数据具有至少等于所述第二表示中的切换点之间的重放时间的重放时间<br>《未公开》 | 无相关描述。 | 对比文件虽然公开了不同速度的“trick play data”及其I帧间隔，但未提及客户端基于对不同表示切换点间隔的比较，来提交对来自第一表示（如高频I帧表示）的特定数量视频数据的请求。对比文件描述的是客户端基于用户选择的播放速度，请求对应的整个特技播放数据流或片段（例如[0092]段），而非基于间隔比较来请求“至少等于第二表示切换点间重放时间”的特定数据量。该技术特征涉及目标专利中实现无缝切换的特定缓冲策略，对比文件未公开。 |
| 技术特征D：在提交对来自所述第一表示的相当数量的视频数据的所述请求之后，检索来自所述第二表示的视频数据。<br>《未公开》 | 无相关描述。 | 对比文件描述了客户端可以请求不同速度的特技播放数据（[0092]段），但未描述在提交对第一表示（如高频I帧表示）的特定数量数据请求后，转而检索来自第二表示（如低频I帧表示）的视频数据。对比文件的上下文是用户选择特定播放速度后，客户端请求该速度对应的数据流，并未教导为了实现带宽适应或质量提升，先请求并缓冲一种表示的数据，再切换到另一种表示的机制。 |
| 技术特征E：其进一步包括缓冲来自所述第一表示的视频数据，以及 基于所述经缓冲的视频数据的持续时间确定何时检索来自所述第二表示的视频数据。<br>《未公开》 | 无相关描述。 | 对比文件未提及对接收到的特技播放数据进行缓冲，更未提及基于已缓冲视频数据的持续时间来决定何时开始检索来自另一表示的视频数据。其特技播放服务流程侧重于按用户选择的速度请求和播放数据，不涉及为优化体验而进行的动态缓冲管理和切换决策。 |
| 技术特征F：其中基于所述经缓冲的视频数据的所述持续时间检索 来自所述第二表示的视频数据包括在缓冲来自所述第一表示的视频数据的持续时间之后 检索来自所述第二表示的数据，来自所述第一表示的视频数据的所述持续时间等于所述第二表示中的切换点之间的所述重放时间。<br>《未公开》 | 无相关描述。 | 该特征是技术特征E的具体实施方式。对比文件完全没有公开任何关于缓冲数据持续时间与第二表示切换点间隔之间关系的内容。 |
| 技术特征G：其进一步包括:确定当前可用网络带宽量<br>《隐含公开》 | [0003] “Apparatuses and methods consistent with exemplary embodiments relate to a method and apparatus for providing a trick play service, and more particularly, to a method and apparatus for providing a trick play service in a hypertext transfer protocol (HTTP) adaptive streaming (HAS) architecture for adaptively streaming media data according to fluctuation of a streaming environment.” | 对比文件明确指出其特技播放服务应用于HTTP自适应流媒体（HAS）架构，该架构需要根据流媒体环境的波动（包括网络带宽波动）进行自适应（[0003]段）。本领域技术人员公知，在自适应流媒体中，客户端确定当前可用网络带宽量是执行自适应逻辑（如选择合适比特率的表示）的基础和必要前置步骤。因此，可以合理推断对比文件所描述的系统和方法必然包含“确定当前可用网络带宽量”这一步骤。技术特征G被对比文件隐含公开。 |
| 技术特征H：接收指示所述第一表示和所述第二表示具有共同位速率的所述多媒体内容的清单<br>《未公开》 | [0105] “The “Bitrate” attribute defines a bit rate of the trick play data...” | 对比文件的MPD（清单文件）包含表示比特率的属性（[0105]段），但并未明确描述或指示两个不同的“trick play data”（表示）具有共同的比特率。其特技播放数据通常以“低比特率”编码（[0065]段），但不同速度的表示是否具有相同比特率并未说明，且并非其关注重点。目标专利强调“共同位速率”是为了在同一比特率下比较切换点频率，而对比文件未公开此限定。 |
| 技术特征I：以 及在确定所述共同位速率可由所述当前可用网络带宽量满足之后选择所述第一表示和 所述第二表示。<br>《未公开》 | 无相关描述。 | 该特征依赖于技术特征H（共同位速率）和技术特征G（确定带宽）。即便认可隐含公开了确定带宽，对比文件也未公开客户端基于“共同位速率”是否满足带宽条件来选择两个特定表示的逻辑。客户端在对比文件中选择表示（特技播放数据）的依据是用户所需的播放速度（如2x, 4x），而非基于带宽适应性对具有共同比特率的表示对进行选择。 |
| 技术特征J：其进一步包括:确定当前可用网络带宽量<br>《隐含公开》 | 同技术特征G的引用和论述。 | 与技术特征G为同一技术特征，被对比文件隐含公开。 |
| 技术特征K：接收指示所述第一表示具有第一位速率且所述第二表示具有高于所述第一位速率的 第二位速率的所述多媒体内容的清单<br>《未公开》 | [0105] “The “Bitrate” attribute defines a bit rate of the trick play data...” | 对比文件的MPD可以指示每个表示的比特率，但并未明确教导或描述存在第一表示具有较低比特率、第二表示具有较高比特率这样的组合关系，更未强调这种比特率的高低关系是用于实现从低质量到高质量切换的策略。其特技播放数据的比特率信息是独立描述的，不构成用于切换决策的对比关系。 |
| 技术特征L：确定所述第二位速率是否可由所述当前可用网络带宽量满足，其中请求来自所述第一表示的所述视频数据包括在确定所述第二位速率可由所述当前可用网络带宽量满足之后请求来自所述第一表示的所述视频数据，且其中在请求来自所述第一表示的所述视频数据之后检索来自所述第二表示的所述视频数据包括在确定所述第二位速率可由所述当前可用网络带宽量满足之后检索来自所述第二表示的所述视频数据。<br>《未公开》 | 无相关描述。 | 该特征涉及基于带宽条件判断高比特率表示是否可用，并以此作为先请求低比特率表示、后检索高比特率表示的决策逻辑。对比文件完全没有公开如此复杂的、基于带宽条件对请求和检索顺序进行控制的流程。其特技播放服务的选择是基于用户指令，而非基于带宽的自动适应和切换策略。 |
| 技术特征M：其中请求来自所述第一表示的所述视频数据包括:将对于来自所述第一表示的所述视频数据的一个或多个请求发送到服务器装置<br>《直接公开》 | [0093] “The client 130 requests the server 120 to transmit at least one piece of the trick play data.” <br> [0094] “The MPD file and the trick play data may be requested and transmitted by using an HTTP...” | 对比文件明确公开了客户端向服务器发送请求以获取特技播放数据（[0093]段），并且通常使用HTTP协议（[0094]段）。这直接公开了“将对于来自第一表示的视频数据的一个或多个请求发送到服务器装置”这一特征。 |
| 技术特征N：经由单播接收来自所述第一表示的所述视频数据，且其中检索来自所述第二表示的所述视频数据包括经由多播或广播的至少一者从所述 服务器装置检索所述视频数据。<br>《未公开》 | [0094] “The MPD file and the trick play data may be requested and transmitted by using an HTTP...” | 对比文件提及使用HTTP进行请求和传输，HTTP通常基于单播。但对比文件完全没有提及在检索第二表示数据时会使用多播或广播方式。其整个数据传输上下文都是基于客户端-服务器的请求/响应模型（单播），未涉及多播或广播。 |
| 技术特征O：其进一步包括接收所述多媒体内容的清单文件，其中确 定所述第一间隔包括从所述清单文件中的信息确定所述第一间隔，且其中确定所述第二间 隔包括从所述清单文件中的信息确定所述第二间隔。<br>《隐含公开》 | [0100]-[0107] 描述了MPD文件的结构和内容，包括`Track`标签、`Type`属性（可标识特技播放数据）、`AlternatePlayoutRate`属性（指示播放速度，如2x, 4x）（参见图7、8）。 <br> [0112] “first trick play data 510 corresponding to a 2× trick play speed is formed by extracting a frame as an I-frame every 2 seconds” | 对比文件公开了客户端接收MPD（清单文件），其中包含表示的类型和播放速度信息（如`AlternatePlayoutRate=2`）。同时，对比文件说明书部分揭示了特定播放速度与I帧间隔的对应关系（例如，2倍速对应每2秒一个I帧）。本领域技术人员在阅读对比文件后，能够理解客户端可以从MPD中获取表示的播放速度信息，并结合特技播放数据的编码常识（为支持特定速度的快进，需要以相应频率放置I帧），推断出该表示中切换点（I帧）的大致间隔。因此，可以合理推断“从清单文件中的信息确定间隔”这一技术手段。技术特征O被对比文件隐含公开。 |
| 技术特征P：其中所述第一表示和所述第二表示具有共同位速率，所述方法进一步包括:在确定所述第一间隔和所述第二间隔之前，检索来自具有不同于所述共同位速率的位 速率的第三不同表示的视频数据<br>《未公开》 | 无相关描述。 | 对比文件未描述在确定两个具有共同比特率的表示的切换点间隔之前，先检索一个具有不同比特率的第三表示的视频数据。其流程不涉及这种多步骤的、基于比特率分组的表示选择与切换策略。 |
| 技术特征Q：确定当前可用网络带宽量<br>《隐含公开》 | 同技术特征G、J的引用和论述。 | 与技术特征G、J为同一技术特征，被对比文件隐含公开。 |
| 技术特征R：基于所述第一表示和所述第二表示的所述共同位速率更适于所述当前可用网络带宽 量的确定，确定所述第一间隔和所述第二间隔，提交对于来自所述第一表示的所述视频数 据的所述一个或多个网络请求，以及检索来自所述第二表示的所述视频数据。<br>《未公开》 | 无相关描述。 | 该特征是一个综合性的方法步骤，其前提（共同位速率）和核心逻辑（基于共同位速率更适合带宽的条件来触发后续所有操作）均未在对比文件中公开。对比文件未将比特率适合性与切换点间隔的确定、以及特定顺序的请求和检索操作关联起来。 |
| 技术特征S：其中检索来自所述第二表示的视频数据包括从所述第 二表示的切换点开始检索来自所述第二表示的视频数据。<br>《直接公开》 | [0064] “The encoder 110 encodes the trick play data at a play start point by using the I-frames.” <br> [0092] “Since the trick play data is divided into a plurality of segments based on time, even while trick play streaming is performed, segments of different trick play data may be transmitted upon a request of the client 130.” | 对比文件公开了特技播放数据在播放起始点使用I帧编码（[0064]段），且数据被分成基于时间的段（[0092]段）。当客户端请求特定速度的特技播放数据时，服务器会发送相应的段。由于每个段的起始点（或段内特定位置，根据索引）对应一个I帧（切换点），因此客户端检索来自第二表示的数据时，本质上是从该表示的切换点（I帧）开始检索数据段。这直接公开了技术特征S。 |
<<<A>>><<<B>>><<<M>>><<<S>>><<<g>>><<<j>>><<<o>>>