# 专利创造性评估分析
## 对比文件名称
2009-07-30_JP2009170985A_发明专利_JP2009170985A On-demand data distribution system
## 目标专利名称
经译码多媒体数据的网络串流期间的表示之间的切换 CN103843301B
## 模型名称
DeepSeek
## 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用（翻译为中文） | 公开性论述 |
| **技术特征A**：所述方法包括:确定所述多媒体内容的第一表示的切换点之间的第一间隔和所述多媒体内容的第二表示的切换点之间的第二间隔。 | 对比文件说明书第[2]段：“マルチキャスト配信サーバは、ある一定の間隔でマルチキャストでのコンテンツ配信を行う。”（组播分发服务器以一定的间隔进行组播内容分发。）<br>第[2]段：“例えば、１２０分のコンテンツＡをマルチキャスト配信サーバ１００が３０分毎に配信を開始しているものとする。”（例如，假设组播分发服务器100每隔30分钟开始分发一个120分钟的内容A。） | **《隐含公开》** 对比文件公开了服务器以固定间隔（如30分钟）开始组播分发会话。本领域技术人员可以理解，每次组播分发开始的时间点，对于客户端而言，可以视为一个可以开始接收数据的“接入点”或“切换点”。虽然对比文件未明确使用“切换点”和“表示”的术语，也未描述“切换点之间的间隔”是同一内容不同编码“表示”的属性，但其核心技术方案（单播+组播）隐含了“组播会话开始点”之间存在固定的时间间隔（即组播周期）。客户端需要确定这个间隔，以计算缺失的单播数据量（参见特征C相关描述）。因此，本领域技术人员可以从对比文件公开的周期性组播分发中，合理推断出确定“分发开始点”（可对应于切换点）之间的间隔这一技术特征。 |
| **技术特征B**：其中所述第一间隔小于所述第二间隔。 | 对比文件未明确描述存在两个不同的“表示”，以及它们具有不同的切换点间隔。 | **未公开** 对比文件仅描述了一种内容分发机制：单播补足起始部分，组播提供后续部分。组播以固定周期（如30分钟）开始。其中并未描述存在同一多媒体内容的两个不同“表示”（如不同编码质量、位速率的版本），更未比较这两个“表示”的切换点（或关键帧）间隔的大小关系（第一间隔小于第二间隔）。目标专利中“间隔”是同一内容不同编码“表示”的内在属性，用于优化初始缓冲和切换策略，而对比文件中的“间隔”是服务器发起组播会话的外部调度周期，两者技术构思和作用不同。 |
| **技术特征C**：基于所述确定，提交对来自所述第一表示的相当数量的视频数据的一个或多个网络请求，来自所述第一表示的相当数量的视频数据具有至少等于所述第二表示中的切换点之间的重放时间的重放时间。 | 对比文件说明书第[2]段：“端末１０３は...マルチキャスト配信データで欠落している先頭から受信開始時点までのデータを個別にユニキャストで受信する。”（终端103...通过单播个别地接收在组播分发数据中缺失的从开头到接收开始时刻的数据。）<br>第[2]段：“受信制御部２０３では、...受信したコンテンツデータが先頭から何分間欠落しているかを確認する（３０６）。...受信制御部２０３からユニキャスト配信サーバ１０１へ先頭から１０分間のコンテンツデータの配信要求を行う（３０７）。”（在接收控制部203中，...确认接收到的内容数据从开头起缺失了多少分钟（306）。...从接收控制部203向单播分发服务器101提出从开头起10分钟的内容数据的分发请求（307）。） | **《隐含公开》** 对比文件公开了：客户端在加入一个已开始的组播会话后，会确定从内容开头到加入点之间缺失的数据量（例如10分钟），然后基于这个确定，向单播服务器提交请求以获取该缺失量的数据。这里的“缺失数据量”恰好等于“从组播会话开始点（可视为一个接入/切换点）到客户端加入点的时间”。虽然对比文件未将其描述为“第一表示”和“第二表示中切换点之间的重放时间”，但其技术动作的本质是：**基于对“组播开始点”之间完整间隔（周期）内已错过部分时长的确定，请求足以覆盖该完整间隔（从开始点到下一个开始点）的缺失数据**。本领域技术人员可以合理推断，请求的单播数据量（如10分钟）至少等于一个组播周期（如30分钟）内客户端尚未接收的部分，其目的是为了在播放完单播数据后能无缝切换到组播流。这与特征C“基于确定，请求重放时间至少等于第二表示切换点间隔的第一表示数据”在逻辑上具有相似性。 |
| **技术特征D**：在提交对来自所述第一表示的相当数量的视频数据的所述请求之后，检索来自所述第二表示的视频数据。 | 对比文件说明书第[2]段：“まずはユニキャストデータで閲覧を開始し、途中から蓄積しているマルチキャストデータに切替えて閲覧する。”（首先开始浏览单播数据，然后切换到已积累的组播数据进行浏览。）<br>第[2]段：“ユニキャストデータを再生終了するという手順（３１０）と同時に、データ再生部２０４はメモリ２０２から開始１０分後からのコンテンツデータを取り出して再生を行う（３１２、３１３）。”（在单播数据再生结束的步骤（310）的同时，数据再生部204从存储器202取出从开始10分钟后的内容数据进行再生（312、313）。） | **《隐含公开》** 对比文件清晰地公开了在请求并接收单播数据（对应于目标专利中来自“第一表示”的数据）之后，客户端会检索（从内存中取出）并播放组播数据（对应于目标专利中来自“第二表示”的数据）。这是一个明确的“先A后B”的检索和播放顺序。尽管对比文件中的“单播数据”和“组播数据”是相同内容的相同编码，而非目标专利中不同编码质量的“表示”，但“在请求第一种数据源的数据之后，检索第二种数据源的数据”这一核心步骤已被公开。本领域技术人员可以理解，这是实现从一种数据源切换到另一种数据源的必然过程。 |
| **技术特征E**：其进一步包括缓冲来自所述第一表示的视频数据，以及基于所述经缓冲的视频数据的持续时间确定何时检索来自所述第二表示的视频数据。 | 对比文件说明书第[2]段：“端末１０３では、マルチキャスト配信サーバから配信されたコンテンツデータをマルチキャスト受信部２００で受信し、メモリ２０２に保存する（３０４）。”（在终端103中，通过组播接收部200接收从组播分发服务器分发的内容数据，并保存到存储器202中（304）。）<br>第[2]段：“まずはユニキャストデータで閲覧を開始し、途中から...マルチキャストデータに切替えて閲覧する。” | **《隐含公开》** 对比文件公开了客户端会接收并缓冲（保存到存储器）组播数据。同时，公开了切换发生在单播数据播放完成之时（“ユニキャストデータを再生終了するという手順（３１０）と同時に”）。虽然对比文件没有明确描述“基于经缓冲的视频数据的持续时间”这一决策逻辑，但本领域技术人员可以合理推断：客户端在播放单播数据时，后台持续缓冲组播数据。决定何时切换到组播数据的关键时刻是单播数据播放完毕的时刻。这个时刻间接地与“经缓冲的组播数据已经覆盖了未来播放需求”有关，即确保在切换时有足够的数据可播放。因此，可以认为对比文件隐含了“基于播放进度（与缓冲数据持续时间相关）来确定切换时机”的技术思想。 |
| **技术特征F**：其中基于所述经缓冲的视频数据的所述持续时间检索来自所述第二表示的视频数据包括在缓冲来自所述第一表示的视频数据的持续时间之后检索来自所述第二表示的数据，来自所述第一表示的视频数据的所述持续时间等于所述第二表示中的切换点之间的所述重放时间。 | 对比文件未描述根据“第一表示”的缓冲持续时间等于“第二表示”中特定间隔（如切换点间隔）来决策切换。切换是基于单播播放完毕。 | **未公开** 对比文件中，客户端切换的触发点是单播数据播放完毕（步骤310）。单播数据的量取决于客户端加入组播会话的时间点（例如，错过了开头10分钟），这个时间量是随机的，并非一个预先定义的、与组播会话周期（或任何“第二表示中的切换点之间的重放时间”）相等的固定值。目标专利特征F要求一个精确的、基于两个表示内在属性（切换点间隔）的数学关系来决定缓冲量，这在对比文件中完全没有体现。 |
| **技术特征G**：其进一步包括:确定当前可用网络带宽量。 | 对比文件说明书第[2]段：“配信管理サーバ１１０は、マルチキャスト配信サーバ１００やユニキャスト配信サーバ１０１の配信負荷発生率や、それらサーバが全ての端末１０３〜１０５に向かって配信している回線の使用率などの情報をリアルタイムに監視している。”（分发管理服务器110实时监视组播分发服务器100和单播分发服务器101的分发负载发生率、以及这些服务器面向所有终端103~105进行分发的线路使用率等信息。） | **《隐含公开》** 对比文件明确公开了分发管理服务器会实时监控服务器负载和线路使用率。线路使用率直接反映了网络带宽的占用情况，监控线路使用率是为了评估系统整体负载和带宽压力，并据此决定是否立即处理请求或让用户等待（参见后续描述）。这属于对网络带宽可用性（从服务器/系统侧）的确定。本领域技术人员可以理解，在流媒体系统中，确定网络带宽可用性是进行资源调度和适配的常见基础步骤。 |
| **技术特征H**：接收指示所述第一表示和所述第二表示具有共同位速率的所述多媒体内容的清单。 | 对比文件未提及任何形式的“清单”（如MPD），也未描述内容存在具有不同属性（如位速率）的多个“表示”。 | **未公开** 对比文件描述的系统是单一内容源通过单播和组播两种方式分发，不涉及同一内容的不同编码“表示”，更没有描述包含表示位速率等属性的“清单”文件。该特征属于目标专利基于DASH等自适应流媒体协议的特定技术背景，对比文件未公开。 |
| **技术特征I**：以及在确定所述共同位速率可由所述当前可用网络带宽量满足之后选择所述第一表示和所述第二表示。 | 对比文件未涉及根据位速率选择不同表示。其“选择”是在单播立即补足和等待下次组播之间（由服务器根据负载决定），而非客户端基于带宽选择不同编码的表示。 | **未公开** 该特征与特征H紧密相关。由于对比文件未公开接收包含位速率信息的清单，也未公开存在具有共同位速率的不同表示，因此也就不存在基于带宽选择这些表示的步骤。对比文件中服务器根据负载决定是否立即提供服务，其决策标准是系统负载，而非客户端评估的可用带宽与特定表示位速率的匹配关系。 |
| **技术特征J**：其进一步包括:确定当前可用网络带宽量。 | 同特征G。 | **《隐含公开》** 同特征G的论述。对比文件公开了服务器侧监控线路使用率以确定带宽负荷情况。 |
| **技术特征K**：接收指示所述第一表示具有第一位速率且所述第二表示具有高于所述第一位速率的第二位速率的所述多媒体内容的清单。 | 同特征H。对比文件未提及清单及不同位速率的表示。 | **未公开** 对比文件未公开任何关于内容具有不同位速率“表示”的清单信息。 |
| **技术特征L**：确定所述第二位速率是否可由所述当前可用网络带宽量满足，其中请求来自所述第一表示的所述视频数据包括在确定所述第二位速率可由所述当前可用网络带宽量满足之后请求来自所述第一表示的所述视频数据，且其中在请求来自所述第一表示的所述视频数据之后检索来自所述第二表示的所述视频数据包括在确定所述第二位速率可由所述当前可用网络带宽量满足之后检索来自所述第二表示的所述视频数据。 | 对比文件未涉及基于带宽评估选择不同位速率表示的逻辑。 | **未公开** 该特征依赖于特征K（不同位速率表示）和特征J（确定带宽）。对比文件均未公开这些前提。其技术方案的核心是单播/组播混合传输以降低服务器负载，而非基于客户端带宽在多个不同质量表示间进行自适应切换。 |
| **技术特征M**：其中请求来自所述第一表示的所述视频数据包括:将对于来自所述第一表示的所述视频数据的一个或多个请求发送到服务器装置。 | 对比文件说明书第[2]段：“受信制御部２０３からユニキャスト配信サーバ１０１へ先頭から１０分間のコンテンツデータの配信要求を行う（３０７）。”（从接收控制部203向单播分发服务器101提出从开头起10分钟的内容数据的分发请求（307）。） | **《隐含公开》** 对比文件明确公开了客户端向服务器（单播分发服务器101）发送对特定量内容数据的请求。这对应于将对于视频数据的请求发送到服务器装置。虽然对比文件中的“第一表示”不是目标专利中具有特定切换点间隔的编码版本，而是指“缺失的单播数据部分”，但“发送请求到服务器”这一动作本身已被公开。 |
| **技术特征N**：经由单播接收来自所述第一表示的所述视频数据，且其中检索来自所述第二表示的所述视频数据包括经由多播或广播的至少一者从所述服务器装置检索所述视频数据。 | 对比文件说明书第[2]段：“ユニキャスト配信サーバ１０１から配信されたコンテンツデータはユニキャスト受信部２０１で受信し（３０８）...。”（从单播分发服务器101分发的内容数据由单播接收部201接收（308）...）<br>第[2]段：“マルチキャスト配信サーバ１００から端末１０３に、送信先アドレスをアドレスＡに指定したコンテンツをマルチキャストにて配信する（３０３）。端末１０３では、マルチキャスト配信サーバから配信されたコンテンツデータをマルチキャスト受信部２００で受信し...（３０４）。”（从组播分发服务器100向终端103，以组播方式分发指定了目的地地址为地址A的内容（303）。在终端103中，接收从组播分发服务器分发的内容数据...（304）。） | **《直接公开》** 对比文件直接、明确地公开了客户端通过单播（ユニキャスト）接收第一部分数据（对应于“第一表示”的数据），并通过组播（マルチキャスト，是多播的一种）接收第二部分数据（对应于“第二表示”的数据）。技术特征描述的数据接收方式（单播和多播/广播）与对比文件公开的内容完全一致，且其在对比文件中所起的作用也是实现数据的接收和后续的切换播放，与目标专利中相应特征的作用相同。 |
| **技术特征O**：其进一步包括接收所述多媒体内容的清单文件，其中确定所述第一间隔包括从所述清单文件中的信息确定所述第一间隔，且其中确定所述第二间隔包括从所述清单文件中的信息确定所述第二间隔。 | 对比文件未提及任何清单文件（如MPD），也未描述从清单文件中获取间隔信息。间隔（组播周期）可能是服务器公开的参数或客户端已知的配置。 | **未公开** 目标专利中利用清单文件（MPD）承载表示的特性（包括切换点间隔信息）是DASH等现代自适应流媒体协议的核心特征。对比文件未公开此类清单文件，也未公开从清单文件中解析切换点间隔信息。 |
| **技术特征P**：其中所述第一表示和所述第二表示具有共同位速率，所述方法进一步包括:在确定所述第一间隔和所述第二间隔之前，检索来自具有不同于所述共同位速率的位速率的第三不同表示的视频数据。 | 对比文件未涉及不同位速率的多个表示。 | **未公开** 该特征描述了在多表示自适应流媒体场景下，从一种位速率的表示切换到另一种位速率（但具有不同切换点间隔）的表示的策略。对比文件的方案是单一内容源的传输方式切换（单播->组播），不涉及不同编码质量（位速率）的表示。 |
| **技术特征Q**：确定当前可用网络带宽量。 | 同特征G、J。 | **《隐含公开》** 同特征G、J的论述。对比文件公开了服务器侧监控线路使用率以确定带宽负荷情况。 |
| **技术特征R**：基于所述第一表示和所述第二表示的所述共同位速率更适于所述当前可用网络带宽量的确定，确定所述第一间隔和所述第二间隔，提交对于来自所述第一表示的所述视频数据的所述一个或多个网络请求，以及检索来自所述第二表示的所述视频数据。 | 对比文件未涉及基于带宽适应性选择具有不同切换点间隔的表示。 | **未公开** 该特征综合了基于带宽选择表示和基于切换点间隔策略进行缓冲和切换的完整逻辑。对比文件的技术方案决策点在于服务器负载，而非客户端带宽与表示位速率的匹配，且其“间隔”是固定的组播周期，并非可选择的、与表示质量相关的属性。因此，该特征未被公开。 |
| **技术特征S**：其中检索来自所述第二表示的视频数据包括从所述第二表示的切换点开始检索来自所述第二表示的视频数据。 | 对比文件中，客户端加入组播时，是从加入的那个时刻开始接收数据流，这个点不一定是内容的“切换点”（如关键帧）。虽然组播会话的开始点可以视为一个接入点，但对比文件未明确客户端是从一个特定的、允许解码无缝开始的帧（如关键帧）开始检索组播数据。 | **未公开** 目标专利中“从切换点开始检索”是为了实现无缝切换和解码，特指从关键帧（I帧）这样的随机访问点开始。对比文件描述的是加入一个正在进行的组播流，接收的是实时传输的数据包，并未强调或要求必须从某个特定的帧边界（如关键帧）开始接收。这是实现细节上的重要区别。 |
## 结论与代码输出
根据上述分析，对比文件JP2009170985A直接公开了技术特征N，隐含公开了技术特征A、C、D、E、G、J、M、Q。
<<<N>>>
<<<a>>><<<c>>><<<d>>><<<e>>><<<g>>><<<j>>><<<m>>><<<q>>>