# 专利创造性评估报告
## 一、基本信息
- **目标专利名称**：379 经译码多媒体数据的网络串流期间的表示之间的切换 (CN103843301B)
- **对比文件名称**：2011-09-08_US2011219063A_发明申请_US20110219063A1 APPARATUS AND METHOD FOR PLAYING MEDIA CONTENT DATA
- **模型名称**：GPT-4
## 二、特征比对表格
| 技术特征描述及公开性判断 | 对比文件原文引用 | 公开性论述 |
| **特征A**：所述方法包括:确定所述多媒体内容的第一表示的切换点之间的第一间隔和所述多媒体内容的第二表示的切换点之间的第二间隔。<br>**隐含公开** | 说明书第[0038]段：“In every coding scheme, generally, the first screen is coded with an I frame, while the succeeding screens undergo coding with P frames or B frames, in order to reduce a bit rate. However, in the case where only P frames and B frames continuously exist, once an error occurs while the P or B frames are being decoded in a reception side, successive errors may occur. In this case, if a user requests a random access to a specific frame, decoding for a precise random access to the frame may be difficult to perform. Therefore, an I frame is periodically inserted between the consecutive P and B frames, which is called ‘intra-refresh’. The number of frames between an arbitrary I frame and its next I frame is called a Group of Picture (GOP).” | 对比文件公开了在编码方案中，为了随机访问，会周期性地插入I帧，并将两个I帧之间的帧数定义为GOP。I帧即为目标专利中的“切换点”（关键帧）。因此，GOP值实质上定义了切换点之间的间隔（以帧数计，可转换为时间间隔）。对比文件描述了存在两种数据：normal-mode data（正常模式数据）和trick-mode data（特技模式数据），并且它们的GOP值不同（例如，图5A的GOP=9，图5B的GOP=3）。确定这两种数据（对应于两种“表示”）的GOP值，即隐含公开了确定两个表示的切换点（I帧）之间的间隔。虽然对比文件未明确使用“确定间隔”的表述，但本领域技术人员可以毫无疑义地从其描述的GOP概念和两种不同GOP值的数据中，推理出确定不同表示（数据模式）的切换点间隔这一技术特征。 |
| **特征B**：其中所述第一间隔小于所述第二间隔。<br>**直接公开** | 说明书第[0072]段：“According to embodiments of the present invention, the trick-mode data is generally configured to be 1/4 times or 1/N (where N is several tens, i.e., 10, 20, 30, etc.) times the normal-mode data in size, and the GOP value of the trick-mode data is also set smaller than that the GOP value of the normal-mode data, increasing the frequency of I frames (or the number of occurrences of I frames).” | 对比文件明确教导了trick-mode data（特技模式数据）的GOP值被设置为小于normal-mode data（正常模式数据）的GOP值。GOP值越小，意味着I帧（切换点）之间的间隔（以帧数或时间为单位）越小。因此，“第一间隔小于第二间隔”这一特征被对比文件直接且明确地公开，其中trick-mode data的切换点间隔（第一间隔）小于normal-mode data的切换点间隔（第二间隔）。 |
| **特征C**：基于所述确定，提交对来自所述第一表示的相当数量的视频数据的一个或多个网络请求，来自所述第一表示的相当数量的视频数据具有至少等于所述第二表示中的切换点之间的重放时间的重放时间。<br>**未公开** | 说明书第[0070]段：“In step 405, the client 350 analyzes a MainContentsDescription.xml file with ContentURL included in the received manifest information, and sends a request for the X-speed play function to the address (e.g., a URL) of the server 300, included in the ContentURL...” | 对比文件公开了客户端可以向服务器发送请求以获取特定功能（如X-speed play）的数据（trick-mode data）。然而，对比文件完全没有公开或暗示：1）请求的数据量是基于对两个表示切换点间隔的“确定”；2）请求的数据量具有“至少等于所述第二表示中的切换点之间的重放时间”这一特定条件。对比文件中的请求是基于用户的功能请求（如快进），而非基于计算出的间隔来请求特定时长的数据。因此，该技术特征未被对比文件公开。 |
| **特征D**：在提交对来自所述第一表示的相当数量的视频数据的所述请求之后，检索来自所述第二表示的视频数据。<br>**未公开** | 说明书第[0093]段：“Upon receiving the switching request to the normal mode, the controller 353 informs the analyzer 355 of the switching request. The analyzer 355 analyzes ContentURL of the server 300, included in manifest information of a received media content descriptor, and provides a URL of the server 300 to the controller 353 according to the analysis results. The controller 353 sends a request for normal-mode data to the URL on a GOP basis beginning from a new I frame.” | 对比文件公开了客户端可以在不同模式间切换，例如从trick-mode切换回normal-mode时，会请求normal-mode data（第二表示）。但是，这种切换是响应用户的模式切换请求（例如从快进切回正常播放），而不是在“提交对来自第一表示的相当数量的视频数据的请求之后”自动进行的。目标专利的切换是基于缓冲策略的自动行为，而对比文件的切换是基于用户指令的响应行为，两者的触发条件和目的不同。因此，该技术特征未被对比文件公开。 |
| **特征E**：其进一步包括缓冲来自所述第一表示的视频数据，以及基于所述经缓冲的视频数据的持续时间确定何时检索来自所述第二表示的视频数据。<br>**未公开** | 无相关内容。 | 对比文件完全没有提及“缓冲”来自第一表示（如trick-mode data）的视频数据，更没有提及基于缓冲数据的“持续时间”来决定何时检索第二表示（如normal-mode data）的数据。对比文件的模式切换决策是基于用户指令（见图10步骤705），而非基于内部缓冲状态的计算。因此，该技术特征未被对比文件公开。 |
| **特征F**：其中基于所述经缓冲的视频数据的所述持续时间检索来自所述第二表示的视频数据包括在缓冲来自所述第一表示的视频数据的持续时间之后检索来自所述第二表示的数据，来自所述第一表示的视频数据的所述持续时间等于所述第二表示中的切换点之间的所述重放时间。<br>**未公开** | 无相关内容。 | 对比文件完全没有公开任何关于比较第一表示缓冲数据的持续时间与第二表示切换点之间重放时间，并以此作为切换条件的技术内容。这是目标专利核心的缓冲和切换策略，在对比文件中没有记载或暗示。因此，该技术特征未被对比文件公开。 |
| **特征G**：其进一步包括:确定当前可用网络带宽量。<br>**未公开** | 无相关内容。 | 对比文件的技术方案聚焦于通过提供GOP更小的trick-mode data来减少快进和随机访问的延迟，完全没有涉及根据“当前可用网络带宽量”进行自适应决策的任何内容。网络带宽的确定和适应是目标专利（涉及DASH流媒体）的核心背景，但并非对比文件（关注本地或流媒体播放中的特技模式）所解决的问题。因此，该技术特征未被对比文件公开。 |
| **特征H**：接收指示所述第一表示和所述第二表示具有共同位速率的所述多媒体内容的清单。<br>**未公开** | 说明书表1及[0065]段描述了媒体内容描述符（manifest），其中包含`Track`信息，`Track`具有`Bitrate`属性。例如：“`<Track ID=1 GOP=″9″ StartTime=0.00 mode=normal Bitrate=40000 ...>`”和“`<Track ID=2 GOP=″3″ StartTime=0.00 mode=TrickPlay Bitrate=10000 ...>`”。 | 对比文件公开了清单（媒体内容描述符）中包含不同轨道（Track）的信息，并且每个轨道有独立的`Bitrate`属性。在表1的示例中，正常模式轨道（ID=1）的比特率为40000，而特技模式轨道（ID=2）的比特率为10000，两者不同。对比文件并未公开或暗示两个表示具有“共同位速率”。相反，它明确显示了它们具有不同的比特率。因此，该技术特征未被对比文件公开。 |
| **特征I**：以及在确定所述共同位速率可由所述当前可用网络带宽量满足之后选择所述第一表示和所述第二表示。<br>**未公开** | 无相关内容。 | 如上所述，对比文件既未公开“共同位速率”（特征H），也未公开“确定当前可用网络带宽量”（特征G），更未将两者结合以选择表示。因此，该技术特征未被对比文件公开。 |
| **特征J**：其进一步包括:确定当前可用网络带宽量。<br>**未公开** | 同特征G。 | 同特征G，该技术特征未被对比文件公开。 |
| **特征K**：接收指示所述第一表示具有第一位速率且所述第二表示具有高于所述第一位速率的第二位速率的所述多媒体内容的清单。<br>**未公开** | 同特征H的引用。在表1中，`mode=normal`的`Bitrate=40000`，`mode=TrickPlay`的`Bitrate=10000`。 | 对比文件公开的清单指示了不同表示具有不同的位速率。然而，在其实例中，特技模式数据（第一表示，用于快进/随机访问）的比特率（10000）**低于**正常模式数据（第二表示，用于正常播放）的比特率（40000）。这与特征K描述的“第二表示具有高于第一位速率的第二位速率”相反。因此，该技术特征未被对比文件公开（至少未公开所述的大小关系）。 |
| **特征L**：确定所述第二位速率是否可由所述当前可用网络带宽量满足，其中请求来自所述第一表示的所述视频数据包括在确定所述第二位速率可由所述当前可用网络带宽量满足之后请求来自所述第一表示的所述视频数据，且其中在请求来自所述第一表示的所述视频数据之后检索来自所述第二表示的所述视频数据包括在确定所述第二位速率可由所述当前可用网络带宽量满足之后检索来自所述第二表示的所述视频数据。<br>**未公开** | 无相关内容。 | 对比文件完全没有涉及根据网络带宽判断位速率是否可满足，并以此作为请求或切换条件的技术内容。该特征融合了网络带宽适应性和特定切换逻辑，在对比文件中无任何基础。因此，该技术特征未被对比文件公开。 |
| **特征M**：其中请求来自所述第一表示的所述视频数据包括:将对于来自所述第一表示的所述视频数据的一个或多个请求发送到服务器装置。<br>**隐含公开** | 说明书第[0070]段：“...and sends a request for the X-speed play function to the address (e.g., a URL) of the server 300...”。图4步骤405也示出了客户端向服务器发送请求。 | 对比文件公开了客户端向服务器发送请求以获取特技模式数据（第一表示）。这隐含了“将对于来自所述第一表示的所述视频数据的一个或多个请求发送到服务器装置”这一动作。虽然对比文件的请求可能是针对一个功能（如X-speed play），而目标专利可能是针对具体数据段，但向服务器发送请求以获取特定表示的数据这一基本技术手段是相同的。因此，本领域技术人员可以从对比文件公开的内容中合理推断出该技术特征。 |
| **特征N**：经由单播接收来自所述第一表示的所述视频数据，且其中检索来自所述第二表示的所述视频数据包括经由多播或广播的至少一者从所述服务器装置检索所述视频数据。<br>**未公开** | 无相关内容。 | 对比文件虽然涉及客户端从服务器接收数据，但完全没有区分或提及数据传输是采用“单播”、“多播”还是“广播”方式。这些是网络传输的具体协议和方式，对比文件未涉及此层面的技术细节。因此，该技术特征未被对比文件公开。 |
| **特征O**：其进一步包括接收所述多媒体内容的清单文件，其中确定所述第一间隔包括从所述清单文件中的信息确定所述第一间隔，且其中确定所述第二间隔包括从所述清单文件中的信息确定所述第二间隔。<br>**隐含公开** | 说明书表1及[0065]-[0066]段。表1的媒体内容描述符中，`Track`元素包含`GOP`属性（例如`GOP=″9″`, `GOP=″3″`）。[0065]段说明该描述符包含文件结构信息，如`TrackID`用以识别normal-mode和trick-mode数据。 | 对比文件明确公开了客户端接收包含媒体内容描述符（即清单文件）的信息，并且该描述符中的`Track`元素明确包含了`GOP`属性。`GOP`属性直接定义了I帧（切换点）之间的间隔（以帧数表示）。因此，本领域技术人员可以毫无疑义地认识到，通过接收并解析该清单文件，可以确定不同表示（对应不同`Track`或`mode`）的切换点间隔（GOP值）。虽然对比文件未明确写出“从清单文件中的信息确定间隔”这一步骤，但该步骤是获取并使用清单文件中已明确记载的GOP信息的必然结果和直接推论。因此，该技术特征被对比文件隐含公开。 |
| **特征P**：其中所述第一表示和所述第二表示具有共同位速率，所述方法进一步包括:在确定所述第一间隔和所述第二间隔之前，检索来自具有不同于所述共同位速率的位速率的第三不同表示的视频数据。<br>**未公开** | 无相关内容。 | 对比文件未公开任何关于存在具有“共同位速率”的第一和第二表示。此外，也未公开在确定间隔“之前”，先检索一个位速率不同的“第三表示”的视频数据。该特征描述了一个特定的、多步骤的自适应流媒体切换流程，在对比文件中无任何对应记载。因此，该技术特征未被对比文件公开。 |
| **特征Q**：确定当前可用网络带宽量。<br>**未公开** | 同特征G、J。 | 同特征G、J，该技术特征未被对比文件公开。 |
| **特征R**：基于所述第一表示和所述第二表示的所述共同位速率更适于所述当前可用网络带宽量的确定，确定所述第一间隔和所述第二间隔，提交对于来自所述第一表示的所述视频数据的所述一个或多个网络请求，以及检索来自所述第二表示的所述视频数据。<br>**未公开** | 无相关内容。 | 该特征是一个复杂的、基于网络带宽和位速率适配的决策与执行流程。对比文件既未公开“共同位速率”，也未公开“确定当前可用网络带宽量”，更未将这两者结合作为决策基础以触发后续的间隔确定和数据请求/检索动作。因此，该技术特征未被对比文件公开。 |
| **特征S**：其中检索来自所述第二表示的视频数据包括从所述第二表示的切换点开始检索来自所述第二表示的视频数据。<br>**直接公开** | 说明书第[0093]段：“The controller 353 sends a request for normal-mode data to the URL on a GOP basis beginning from a new I frame.” 以及第[0082]段：“However, when random access is made on the trick-mode data (as shown in ), decoding may start beginning from the I frame 905 just next to the time 901...” | 对比文件明确教导了在请求正常模式数据（第二表示）时，是基于GOP并从新的I帧开始（“beginning from a new I frame”）。同时，在描述随机访问操作时，也明确指出解码从I帧开始。I帧即切换点。因此，“从第二表示的切换点开始检索”这一技术特征被对比文件直接公开。 |
## 三、总结与代码输出
根据上述比对分析：
- **直接公开**的技术特征有：**B**, **S**。
- **隐含公开**的技术特征有：**A**, **O**。
- 其余技术特征（C, D, E, F, G, H, I, J, K, L, M, N, P, Q, R）均未被对比文件直接公开或隐含公开。
<<<B>>><<<S>>><<<a>>><<<o>>>