用于至少第一流和至少第二流的目的地间同步的方法，所述第二流与使用所述第一流作为输入流的媒体流修改单元的输出流相关联；该方法包括以下步骤；提供第一流中的分组到达第一同步点的第一到达时间信息；和第二流中的分组到达第二同步点的第二到达时间信息；提供关于所述输入流与所述输出流之间的同步关系的同步相关信息；基于第一和第二到达时间信息和同步相关信息来计算延迟信息。

作为一名经验丰富的专利代理师，我将为您对上述目标权利要求（权利要求1）与两份对比文件（D1、D2）进行深度的技术特征比对、最接近对比文件（原型）选择分析、无效宣告中最薄弱特征剖析以及下一步的检索策略规划。

为了表述清晰，首先明确对比文件的指代及公开号：

* **D1**：`US6724825B1` (Regeneration of program clock reference data for MPEG transport streams)

* **D2**：`US7084898B1` (System and method for providing video conferencing synchronization)

---

### 一、 权利要求1的技术特征拆解与对比文件比对

以下是针对权利要求1各技术特征（A至F）在对比文件D1和D2中的公开情况分析及详细出处。

#### 1. 各对比文件原文详细出处及公开事实分析

* **技术特征A**：`所述第二流与使用所述第一流作为输入流的媒体流修改单元的输出流相关联`

* **D1（实质公开）**：公开了转码器（transcoder）处理输入视频流（第一流）并重新编码输出低码率视频流（第二流）。转码器即为“媒体流修改单元”。原文出处：“The statistical remultiplexer (stat remux), or transcoder, which handles pre-compressed video bit streams by re-compressing them at a specified bit rate...”（BACKGROUND OF THE INVENTION 第3段）以及“The transcoder 100 receives one or more transport stream(s) ... The data from the services is transcoded at respective transcode functions 122, ..., 132.”（DETAILED DESCRIPTION 第2、4段）。

* **D2（毫无异议公开）**：公开了混音单元/混视频单元处理输入流生成混合流。原文出处：“The audio mixer generates a mixed audio stream from the one or more incoming audio streams... transform timestamps for one or more incoming video streams to output timestamps of a mixed video stream”（SUMMARY OF THE INVENTION [0005]）。输入流通过混音/混视频等修改单元后与输出的混合流相关联。

* **技术特征B**：`该方法包括以下步骤`

* **D1 & D2（毫无异议公开）**：均公开了一种包含多个步骤的同步方法。

* **技术特征C**：`提供第一流中的分组到达第一同步点的第一到达时间信息`

* **D1（毫无异议公开）**：公开了当输入分组到达时，附加代表主时钟数据的硬件标签 `PcrInHwTag`。原文出处：“When an input packet 104 arrives, the function 105 appends a transport time stamp, PcrInHwTag, to the packet. The PcrInHwTag is latched from the Master System Time Clock...”（DETAILED DESCRIPTION 第6段）以及“PcrInHwTag is the PCR hardware tag; this is the count of the free running MasterSTC 155 at the time the packet 104 with the PcrIn arrived.”（Section 1.1 第3段）。此处输入单元即第一同步点，`PcrInHwTag` 即第一到达时间信息。

* **D2（实质公开）**：公开了通过观察视频/音频分组到达混音器/混频器的时间来确定到达时间戳。原文出处：“Video mixer determines the necessary buffer delay for each input video stream by observing the timestamps of video packets as they arrive at the mixer.”（DETAILED DESCRIPTION [0029]）。

* **技术特征D**：`和第二流中的分组到达第二同步点的第二到达时间信息`

* **D1（毫无异议公开）**：公开了输出分组在离开转码器（第二同步点）时的硬件标签 `PcrOutHwTag`。原文出处：“This tag represents the clock data of the master STC 155 at the time a packet is output from the transcoder.”（DETAILED DESCRIPTION 第5段）以及“Where PcrOutHwTag is the MasterSTC at the output transport tick time.”（Section 1.1 第5段）。

* **D2（实质公开）**：公开了输出混合流的分组时间戳映射。原文出处：“By observing the timestamp of the input packet and the timestamp of the assigned output mixed packet, audio mixer 104 establishes an input/output timestamp pair.”（DETAILED DESCRIPTION [0024]）。

* **技术特征E**：`提供关于所述输入流与所述输出流之间的同步关系的同步相关信息`

* **D1（毫无异议公开）**：公开了计算输入PCR与主时钟的偏移量 `PcrOffset`，以及引入硬件误差 `PcrHwErr` 和系统延迟 `PcrSysDly`。原文出处：“...the difference, PcrOffset, is computed as: PcrOffset = PcrIn - PcrInHwTag”（Section 1.1 第2段）以及“...less a delay (PcrSysDly) associated with the transcoder... includes a lookahead delay (lookahead_dly) and a buffer delay (buffer_dly).”（SUMMARY OF THE INVENTION 倒数第2段）。这些共同构成了输入与输出流之间的同步相关信息。

* **D2（毫无异议公开）**：明确公开了计算并提供输入与输出流之间的时钟映射参数（缩放因子 M 和偏移量 B）。原文出处：“The audio mixer determines differences in time bases between the one or more incoming audio streams and the mixed audio stream. The audio mixer generates mapping parameters associated with the determined differences... mix_TS = M * input_TS + B”（SUMMARY [0005] 及 DETAILED DESCRIPTION [0020]）。

* **技术特征F**：`基于第一和第二到达时间信息和同步相关信息来计算延迟信息`

* **D1（毫无异议公开）**：公开了基于主时钟的输入/输出标签（第一/第二到达时间）、硬件误差、以及转码器固有延迟来计算输出PCR（对应延迟调整后的时间信息）。原文出处：“PcrOut = PcrOutHwTag + PcrOffset + PcrHwErr - PcrSysDly”（Section 1.2 倒数第2段）。其本质是通过这些信息计算出由于系统延迟（`PcrSysDly`）和硬件时钟漂移（`PcrHwErr`）导致的总体延迟并对时间戳进行校正。

* **D2（毫无异议公开）**：公开了利用映射参数（M、B）以及输入/输出时间戳来计算各个流为了达到同步所需的额外缓冲区延迟信息。原文出处：“Video mixer determines the necessary buffer delay for each input video stream... For each remaining input video stream, the amount of additional buffer time... is equal to the amount of time that input video stream arrives earlier than the most delayed input video stream.”（DETAILED DESCRIPTION [0029]）。

---

#### 2. 特征比对表格

---

### 二、 最接近对比文件（主审对比文件）的选择分析

在创造性分析中，选择“最接近的对比文件”通常从**技术领域相同或相近**、**解决的技术问题最类似**以及**公开权利要求的技术特征最多**三个维度进行考量。本案中，**D1和D2均具备作为最接近对比文件的资格，但针对不同的创造性评述逻辑，二者各有侧重（即存在多个最接近对比文件）**：

#### 优先选择1：D1 (`US6724825B1`) —— 最适合作为第一最接近对比文件

* **技术领域与场景极其契合**：D1 明确针对于**“媒体流修改单元”这一特定架构（即转码器 Transcoder）**。目标专利权利要求1的核心前提是“第二流与使用第一流作为输入流的媒体流修改单元的输出流相关联”。D1正是一个典型的单输入、单输出（或多路独立单输入输出）转码场景。

* **解决的技术问题最类似**：目标专利旨在解决输入流经过媒体修改单元处理后，如何利用到达时间及同步相关信息计算延迟以实现目的地间同步（Inter-destination synchronization）。而D1解决的正是输入流在经过转码器处理后会产生“固定转码延迟（看头延迟+缓冲延迟）”以及“硬件时钟漂移误差”，如何通过主时钟的时间戳标签（`PcrInHwTag`/`PcrOutHwTag`）和偏移量来精确还原和调整输出PCR，从而消除延迟和抖动对终端解码同步的影响。

* **特征覆盖度**：如比对表所示，D1近乎全盘公开了权利要求1的所有架构特征（A-F），且完全是在“输入流 $\rightarrow$ 处理单元 $\rightarrow$ 输出流”的线性延迟链条中进行计算。

#### 优先选择2：D2 (`US7084898B1`) —— 同样可作为独立的第二最接近对比文件

* **技术问题高度一致（聚焦于“目的地间同步/多流同步”）**：D2 的核心是解决视频会议中的“唇同步（Lip Synchronization）”或多路流同步。这与目标专利的“目的地间同步”在广义的多媒体流同步领域属于同一诉求。

* **数学实质高度一致**：D2通过计算输入与输出混合流之间的映射参数 M 和 B，并在接收端或混频端利用该同步关系计算出各流的“额外缓冲延迟（`buffer delay`）”，这在算法实质上完全对应了权利要求1的特征E和F。

* **技术架构略有拓宽**：D2的“媒体流修改单元”是多路输入融合为一路混合输出的混音器/混视频器，虽然也是修改单元，但相比D1的纯转码器，D2引入了多客户端异步时钟的映射。

**总结**：在撰写无效宣告请求书时，**建议以D1为主评述创造性的第一条主线（D1 + 标检索文件），以D2作为独立的第二条主线（D2 + 标检索文件）**，形成双保险。

---

### 三、 无效请求中最薄弱的技术特征剖析

经过上述严格的比对可以发现，权利要求1的技术特征覆盖面较广，且偏向于高层级的“架构与流程描述”（即概念性地要求“提供时间信息”、“提供同步信息”、“计算延迟”）。

如果要提出无效宣告，本权利要求**最薄弱的技术特征（即专利权人最难据此抗辩、最容易被评价为不具备创造性的特征）**是：

> **技术特征E（提供同步关系信息）与特征F（基于时间信息和同步信息计算延迟）的上位概念表述。**

* **原因分析**：权利要求1在撰写时为了获得最大的保护范围，将所有具体的算法和参数进行了高度的**上位化（Generality）**。它仅宣称“基于第一和第二到达时间信息和同步相关信息来计算延迟信息”，却没有限定**怎么算**（例如：是通过线性回归计算斜率和截距，还是通过特定的减法公式扣除固定系统延迟）。

* **法律后果**：这种高度上位的表述，直接导致其技术方案的落入范围过宽。D1中“利用 `PcrOffset`、`PcrHwErr` 和 `PcrSysDly` 修正 `PcrOut`”，以及D2中“利用参数 M、B 计算 `input_TS` 进而对比得出 `additional buffer time`”，在法律实质上**均属于“基于到达时间信息和同步相关信息计算延迟信息”的范畴**。权利要求1由于缺乏具体算法的下位特征限制，其特征E和F被D1或D2实质公开的确定性极高，因此在创造性或新颖性判定中最为薄弱、最容易被攻破。

---

### 四、 进一步的对比文件检索策略

虽然D1和D2对权利要求1已经形成了非常精准的实质性公开，但为了彻底封堵专利权人后续通过**将说明书中的下位具体实施例（例如具体的时钟同步协议、特定的多播/组播目的地间同步架构）改写进权利要求**来尝试规避无效的可能，建议开展以下有针对性的进一步检索：

#### 1. 细化检索领域与关键词拓展

* **核心领域分类号（IPC/CPC）**：聚焦于 `H04N21/4305`（利用时间戳实现视音频同步）、`H04N21/4307`（目的地间或网络节点间同步）、`H04L65/66`（多媒体流传输网络协议）。

* **扩展关键词**：

* 目的间同步：`Inter-destination synchronization` (IDMS), `Group synchronization`, `Multi-client synchronization`.

* 媒体修改与延迟：`Transcoding delay`, `Processing latency`, `Timestamp mapping`, `Reference clock transformation`.

* 流媒体协议：`RTP/RTCP`, `NTP`, `MPEG-TS`, `PCR jitter adjustment`.

#### 2. 针对说明书可能下位特征的防守性检索

* **针对“目的地间同步（IDMS）”的标准演进检索**：

* 在流媒体领域，IDMS 曾在 **3PP / MPEG-DASH** 或者是 **IETF RFC**（如针对 RTP/RTCP 扩展的 IDMS 草案）中有过深度讨论。建议重点检索 2004 年至 2012 年期间（结合该目标专利的优先权日之前）关于 **RTCP IDMS packet** 的标准化提案。

* **针对特定修改单元（如分布式转码或云端混流）的检索**：

* 检索在分布式架构下，当第一流和第二流处于不同网络节点（例如云端修改，边缘端解码）时的时间戳对齐方案。寻找公开了“在中间网络节点记录入节点时间戳、出节点时间戳，并将节点内处理延迟作为同步补偿量发送给接收端”的在先专利或文献。这样即使专利权人将“网络节点/拓扑结构”限缩进权利要求，也能直接使用备用对比文件进行秒杀。

作为一名经验丰富的专利代理师，我将为您针对上述权利要求1以及三份美国对比文件（D1、D2、D3）进行深入的法理与技术特征比对分析。

---

## 权利要求1的技术解构与特征拆解

为了进行精确的对比分析，首先基于目标专利说明书的整体构思，将权利要求1拆解为以下6个独立的技术特征：

* **特征A**：所述第二流与使用所述第一流作为输入流的媒体流修改单元的输出流相关联（属于前序部分限定的架构特征）。

* **特征B**：该方法包括以下步骤（步骤指引）。

* **特征C**：提供第一流中的分组到达第一同步点的第一到达时间信息。

* **特征D**：和第二流中的分组到达第二同步点的第二到达时间信息。

* **特征E**：提供关于所述输入流与所述输出流之间的同步关系的同步相关信息。

* **特征F**：基于第一和第二到达时间信息和同步相关信息来计算延迟信息。

**说明书内涵释明**：本专利旨在解决多路媒体流在经过中间的“媒体流修改单元”（例如转码器、录制缓冲器、流处理单元等）加工后，导致输出的“第二流”相比于输入的“第一流”产生了不可预测的处理延迟，进而影响了目的地之间同步（Inter-Destination Synchronization）的技术问题。其核心在于引入了“同步相关信息”（即修改单元内部的输入与输出的固有联动关系），结合两路流各自到达同步点的绝对/相对时间，精准计算出流与流之间的动态延迟信息。

---

## 对比文件特征比对表格

以下为各对比文件对权利要求1技术特征的比对映射表，分析过程严密结合对比文件原文及详细出处：

---

## 最接近的对比文件（最接近现有技术）分析

在创造性分析过程中，**对比文件2（D2, `US20070089147A1`）最适合作为本申请的最接近对比文件（第一死穴）**。原因如下：

1. **从整体解决的技术问题来看**：本申请旨在解决第一流与经过修改的第二流之间的目的地间同步问题（消除由于流修改、传输、请求带来的动态延迟）。而D2（见段落`[0004]-[0006]`及`[0020]`）明确指出，其解决的技术问题是：由于 headend 录制并访问录制程序流（NPVR 功能），导致录制流（第二流）滞后于广播流（第一流），为了解决这种不妥协的非同步（unsynchronization）状态，需要精准获取两者的时延量 $D$，并在广播流中引入延迟 $d_t$ 从而实现两流完全同步。两者解决的技术问题高度契合。

2. **从技术效果及方案构思来看**：D2 构思了通过计算流加工记录阶段的固有延迟（$D_1$，对应特征E的同步相关信息），结合用户请求的发送与交互时间（$D_2$，对应特征C、D的到达时间信息），最终叠加计算出总延迟 $d_t$（对应特征F）的技术路径。其方案拓扑结构和参数依赖关系与目标权利要求1完全一致。

相比之下，**D1** 仅属于单路流的 QoE（体验质量）指标测量及单流事件的时间戳语义规范，根本未涉及多流同步或流修改单元，技术领域偏离较远；**D3** 虽涉及多媒体同步呈现，但属于静态的“视频 + 补充文本/图形数据”的渲染对齐，不包含“媒体流修改单元”这一核心架构，亦无法计算出由修改单元引起的动态延迟信息。

---

## 创造性评价与最薄弱技术特征指出

通过上述分析可见，**权利要求1的全部技术特征实际上已经被D2（`US20070089147A1`）实质性公开**：

* D2中的“广播程序流”对应第一流，“经过A/S处理器重编码并由录制缓冲管理器存储的NPVR录制流”对应第二流。

* D2中的“A/S处理器 + 缓存管理器”构成了“媒体流修改单元”（特征A）。

* D2计算 $d_t = D_1 + D_2$ 的整个业务流（图10）完美覆盖了特征C、D、E、F的输入要素与输出结果。

> 结论：**如果直接面对D2，权利要求1极有可能被认定为不具备新颖性（A22）或明显不具备创造性（A26.3）。**

### 若提出无效请求，最薄弱的技术特征（即本专利最难被推翻/对无效请求人最有利的突破口）：

由于本权利要求整体已被D2单篇全面覆盖，从权利人（防御方）的角度来看，**没有任何一个特征是足够强壮的**。但如果要吹毛求疵寻找文字或微观架构上的抗辩空间，**特征E（同步相关信息）** 和 **特征A（媒体流修改单元的联动）** 是唯一可以做狭义合理解释的微弱隔离带。

* *防御性抗辩点*：本专利的“同步相关信息”可以被申辩为是一种“实时随流传输的控制元数据或带内信令”；而D2中的 $D_1$ 是由服务器端的 cache manager 直接读取本地系统钟表（clock 110）并计算出来的内部静态/周期性统计差值。

* *无效方化解策略*：由于权利要求1采用了非常上位的“提供关于...同步相关信息”表述，并未限定该信息必须是带内信令还是随流分组。D2中 buffer manager 计算出 $D_1$ 并将其“传输（transmitted）至媒体处理器119”的行为（段落`[0070]`），在法理上已经完全等同于“提供了输入与输出流之间的同步相关信息”。

---

## 进一步的对比文件检索策略

鉴于目前的独立权利要求已被D2精准拦截，为了彻底无效掉该专利可能存在的隐藏从属权利要求（例如对“同步点”的定义、“同步相关信息”的具体数据结构、“延迟信息”的应用方式等），建议采取以下递进式检索策略：

1. **关键词扩展与标准文献检索（针对3GPP/广播多播标准领域）**：

* 目标专利提及了“目的地间同步（Inter-Destination Synchronization, IDMS）”，这是标准化组织（如 IETF, 3GPP, MPEG）非常经典的课题。

* **检索方向**：重点转向 **IETF RFC 7272**（Inter-Destination Media Synchronization protocols）及相关的草案（Drafts）；同时检索 **3GPP TS 26.234**（PSS服务）中关于多播/组播流同步、以及串联网元（比如媒体网关 MGW、转码器 Transcoder）引入时延补偿的条款。

* **控制核心词**：`IDMS`, `Inter-destination synchronization`, `media modification`, `transcoding delay`, `timestamp mapping`, `relative playback time`, `NPT to RTP alignment`.

2. **聚焦“流媒体加工网元（中间件）时延补偿”专门分类号**：

* 精准锁定 IPC/CPC 分类号：**`H04N21/242`**（服务器端同步识别）、**`H04N21/43`**（客户端同步或对齐）、**`H04L65/80`**（流媒体传输服务质量与同步）。

* **检索策略**：检索在流媒体服务器层面对输入流（如原始大码率流）进行切片、转码、流平滑（Smoothing）后，在生成的输出流（如小码率流或分发流）中注入“时间偏移量（Time Offset）”或“历史时间戳映射表”的专利。此类专利能更直接地压制可能被引申出的“带内信令/映射表”等从属特征。

3. **多篇对比文件组合（作为后备B计划）**：

* 利用 **D2** 作为最接近的现有技术（公开了修改流带来的处理延迟、请求延迟和整体相加算法）。

* 结合 **D1 (`US20050204052A1`)** 中关于“基于相对媒体播放时间（NPT/RTP时间戳）作为解耦绝对时钟的统一基准”这一教导。如果本专利抗辩其计算基于特定的相对时间轴，则通过 **D2 + D1** 的结合，以“在该技术领域引入统一相对时间戳来消除处理负荷导致的变动属于公知常识/显而易见”为由，彻底封堵其创造性空间。

作为一名经验丰富的专利代理师，我将为您对目标权利要求1进行深入的法律与技术解析。

在进行特征比对前，我们需要紧密结合目标专利说明书的逻辑来**解释权利要求1**：

目标权利要求1保护的是一种“目的地间同步（Inter-Destination Media Synchronization, IDMS）”或“不同媒体流间同步”的方法。其核心应用场景通常是：第一流（如广播TS流）和第二流（如宽带RTP流）在不同的网络或通道传输，但它们在源头上具有关联性——**技术特征A**指出了这种关联，即第二流是由媒体流修改单元（如转码器、流服务器）将第一流作为输入流进行修改/处理后输出的流。该方法通过在两个流的同步点分别采集分组的到达时间信息（特征C、D），并获取输入与输出流之间的某种同步映射关系（特征E），从而最终计算出协调两流同步所需的延迟信息（特征F）。

以下是针对两份对比文件（D1和D2）的详细无效宣告与创造性分析。

---

## 一、 对比文件公开号及基本信息指代说明

为了行文简洁且符合专利无效宣告审查标准，本报告使用以下简称指代各对比文件：

* **D1**：CN101179484A，《一种不同媒体流间的同步方法及系统》，公开日：2008年5月14日。

* **D2**：US20080317439A1，《SOCIAL NETWORK BASED RECORDING》（基于社交网络的录制），公开日：2008年12月25日。

---

## 二、 技术特征比对表

依据专利审查指南，以下将权利要求1拆解为技术特征A~F，并与对比文件D1、D2的原文进行严谨的逐字/实质比对：

---

## 三、 最接近对比文件（最接近现有技术）分析

在创造性分析中，选择**最接近现有技术**通常从技术领域、解决的技术问题以及核心技术架构的贴合度三个维度考量。本案中，**D1更适合作为最接近的对比文件**（即第一选择），同时**D2可作为主要辅证或共同最接近对比文件**。

### 1. 为什么 D1 最适合作为最接近的对比文件？

* **技术领域与解决的问题高度一致**：D1（【0002】、【0047】）聚焦于“流媒体间数据流的同步技术”，解决如何让相互独立的流媒体数据包（如TS流和RTP流）在终端建立共同时间坐标、实现高精度同步播放的技术问题。这与目标权利要求1的“目的地间同步方法”在算法架构、时钟恢复和数据包时间戳处理的底层逻辑上完全相符。

* **技术手段最为接近**：D1详细展开了如何利用数学公式将第一流的时间戳（PTS）和第二流的时间戳（RTP Timestamp）转化为统一时间基准（NPT），并进行计算比对的步骤，这与特征C、D、E、F的底层计算逻辑高度契合。

### 2. D2 的角色与定位

* D2解决的整体技术问题是“在社交网络中分享媒体观看体验（【0001】）”，具体是通过DVR同步机制让不同地点的用户看到相同的画面，或将用户生成的评论、音频轨与原视频同步（【0008】）。

* D2的优势在于其**完美公开了特征A中“第二流作为第一流输入修改后的输出流”这一流间关系**（即原视频流与重新 remixed 或叠加的评论流之间的关系）。因此，当以D1为最接近现有技术时，D2是用来组合无效掉特征A的最佳武器。

---

## 四、 无效请求中最薄弱的技术特征

若要向国家知识产权局提起无效宣告请求，本权利要求中**最薄弱（即最容易被攻破）的技术特征是：特征E和特征F**。

> **原因分析：**

> “提供同步相关信息”并“计算延迟信息”在流媒体同步领域属于非常通用的上位概念。

> D1中公开的“计算转换后的NPT时间差并判断是否在设定的区间内进行控制（【0139】）”，以及D2中公开的“利用哈希值或相对于屏幕事件的时间差（Time differential）来调整展现时间（【0043】）”，在实质上均已经完全覆盖了“提供同步关系信息并计算延迟”的构思。这几个特征在结合了D1和D2的教导后，完全属于本领域技术人员为了实现流同步而采取的常规技术手段，不具备突出的实质性特点。

相反，**最稳固（抗无效能力较强）的特征**反而是**特征A中关于流的特定上下游关联关系**（媒体流修改单元的输入输出流关联）。因为D1是完全并行的两路独立网络流，必须要引入D2（音视频 remixed/叠加评论）进行结合才能对抗特征A。

---

## 五、 进一步的对比文件检索策略

鉴于目前的D1在特征A（输入/输出修改流关系）上存在微弱的区别漏洞，而D2属于社交网络DVR系统、技术领域偏向高层应用，为了确保100%成功无效权利要求1，建议采取以下进阶检索策略：

1. **细化检索关键词（锁定修改单元+同步）：**

* 应将检索重点放在**“媒体网关（Media Gateway）”、“转码器（Transcoder）”、“流媒体服务器（Streaming Server）”**等具体媒体修改单元的底层同步上。

* **构建专业检索式**：`(目的地间同步 OR 流同步 OR 媒体同步 OR IDMS) AND (转码 OR 修改 OR 编码转换 OR 级联 OR 输入输出) AND (时间戳 OR 延迟计算 OR arrival time OR delay)`。

2. **重点追踪 3GPP 国际标准提案（SA4工作组）：**

* 目标专利的术语“目的地间同步（IDMS）”和“输入流/输出流相关联的媒体流修改单元”具有非常浓厚的**3GPP PSS（分组流服务）或MBMS（多媒体广播组播服务）**标准色彩。

* 强烈建议检索 **3GPP TS 26.234**（PSS协议）或 **TS 26.346**（MBMS协议）在2008年之前的版本及相关的**TR（技术报告）和Tdoc（会议提案）**。在3GPP SA4（编解码与多媒体）标准中，流媒体代理/转码节点（即修改单元）在分发流时如何根据RTP/RTCP计算与原流的延迟以实现同步，属于被标准完全规范的常规技术。

3. **专利分类号（IPC）交叉检索：**

* 聚焦锁定 **H04N 21/43**（用于同步的专门设备，如音视频同步）和 **H04L 65/60**（流媒体传输协议）。在这些分类号下，检索由爱立信、诺基亚、汤姆逊（Thomson）或华为等早期流媒体巨头申请的转码同步专利，极易找出将主码流与转码子码流进行延迟对齐的精确“降维打击”证据。

作为一名经验丰富的专利代理师，我将为您对目标专利的权利要求1进行深度解析，并结合两份对比文件进行详细的特征比对、最接近对比文件分析、无效请求最薄弱特征识别以及后续的检索策略制定。

以下是具体的分析报告：

---

## 一、 权利要求特征解析与指代说明

为了确保分析的严谨性，本报告将使用以下公开号指代各对比文件：

* **D1**：`US20080320545A1` (System and method for providing audio-visual programming with alternative content)

* **D2**：`US20090059962A1` (SYNCHRONIZING RELATED DATA STREAMS IN INTERCONNECTION NETWORKS)

---

## 二、 权利要求1的技术特征比对分析

通过将权利要求1拆解为技术特征A至F，与D1和D2的原文进行细致对照，客观评估其公开情况。

### 1. D1 (US20080320545A1) 特征比对分析

* **技术特征A**：**实质公开**。D1公开了接收第一信号（含默认音视频）和第二流（可选的替代内容流），并由控制器同步组合成修改后的节目。这实质上对应了修改单元对输入流进行处理并输出关联流的过程（参见D1的摘要、[0025]）。

* **技术特征B、C、D**：**未公开**。D1仅提到了使用时间标记、标签或时间戳进行同步（参见[0029]），但完全没有提及“提供第一流/第二流分组到达第一/第二同步点的第一/第二到达时间信息”这一具体机制。

* **技术特征E**：**实质公开**。D1提及输入流与替代流之间存在时间标记或标签的对应关系，并在说明书[0056]中提及“软件标签用于关联替代流与原始节目”，这属于一种同步相关信息。

* **技术特征F**：**未公开**。D1没有公开“基于第一和第二到达时间信息和同步相关信息来计算延迟信息”的计算步骤。

### 2. D2 (US20090059962A1) 特征比对分析

* **技术特征A**：**毫无疑问公开**。D2在摘要、[0003]、[0020]中明确指出， delivery of multiple media streams from a single source to multiple destinations（从单一源向多个目的地传输多个媒体流），例如视频流和音频流，它们彼此关联且属于输入/输出流的修改单元相关联的流。

* **技术特征B、C、D**：**毫无疑问公开**。D2的[0032]详细记录了四次时间戳的获取过程：

* 发送端发送分组时插入时间戳 $Ts_0$。

* **分组到达接收端（同步点）时，接收端根据其本地时钟插入新的时间戳 $Tr_1$（对应特征C：第一到达时间信息）**。

* **返回分组离开接收端（同步点）时，插入时间戳 $Tr_2$（对应特征D：第二到达时间信息）**。

* **技术特征E**：**毫无疑问公开**。D2公开了利用网络往返时间、时钟之间的相位差来进行流同步。公式[1]、[2]、[3]以及[0037]中提及的“解码器延迟（decoder latency）”和[0040]中的“缓冲区信息”，均属于输入流与输出流之间的同步相关信息。

* **技术特征F**：**毫无疑问公开**。D2在[0034]中给出了明确的计算公式：公式[1]计算往返延迟 $\delta = (Ts_3 - Ts_0) - (Tr_2 - Tr_1)$，公式[2]计算时钟相位偏移 $\phi = [(Tr_1 - Ts_0) + (Tr_2 - Ts_3)] / 2$，公式[4]计算最终的解码时间 $T_{DECODE}$。这完全对应了“基于第一和第二到达时间信息和同步相关信息来计算延迟信息”。

---

### 3. 技术特征比对表

---

## 三、 最接近的对比文件（Closest Prior Art）分析

在创造性分析中，**D2 (`US20090059962A1`) 明显更适合作为最接近的对比文件**。原因如下：

1. **技术领域与解决的技术问题高度一致**：

* 目标专利旨在解决**至少两个流在目的地之间的同步问题**（特别是存在媒体流修改或多目的地传输时）。

* **D2** 明确聚焦于互连网络中相关联数据流（如多目的地媒体流、独立音频与视频流）的**目的地间同步（Stream Synchronization）**，解决的是由于各设备时钟相位不同、网络抖动导致的显示不同步问题（参见D2 [0003]、[0005]）。

* 相比之下，**D1** 主要侧重于**内容定制化**，即如何将替代的音频或广告无缝嵌入或替换现有节目的业务逻辑，其对底层网络时钟同步的技术方案描述非常泛泛。

2. **技术特征覆盖率最高（几乎全覆盖）**：

* 如比对表所示，D2 毫无疑问地公开了权利要求1中除形式文字外的高壁垒核心技术特征（特征C、D、E、F），包括引入双向时间戳机制（$Tr_1, Tr_2$）以及融合解码器内部延迟信息来精确计算目标延迟量。

**结论**：选择 D2 作为主要方案（最接近的对比文件），本领域技术人员几乎不需要付出创造性劳动，即可完整覆盖权利要求1的全部特征。

---

## 四、 无效请求中最薄弱的技术特征

基于上述分析，如果向专利局提出该权利要求1的无效宣告请求，**几乎不存在真正意义上的“薄弱技术特征”（即专利权人的护城河极低）**。

若硬要挑出抗辩空间，**技术特征A中关于“媒体流修改单元的输出流相关联”这一特定架构的限定**是相对最容易被专利权人拿来做限缩性解释的争辩点。

* **薄弱点/争辩点**：专利权人可能会辩称，D2公开的只是普通的“多路相关流传输”（如独立的音视频流），而本申请特意限定了“使用第一流作为输入流的**媒体流修改单元的输出流**”（即存在一个明确的加工修改动作）。

* **破局点**：这一架构特征早已被 **D1** 实质公开（D1的控制器接收第一流，通过加入选定替代流，修改并输出新流，参见[0006]、[0025]）。因此，即便认为D2在“修改单元”这一字面表述上存在微弱创新，结合D1也是极其显而易见的。

---

## 五、 进一步的对比文件检索策略

为了使该权利要求1的无效证据链达到天衣无缝的“双保险”效果，建议启动补充检索，重点补充**针对特征A（流修改场景下的时间戳同步）**的直接公开证据。

1. **检索方向调整**：

* 聚焦在“**转码同步（Transcoding Synchronization）**”、“**流媒体中间件/网关延迟补偿**”领域。

* 寻找在网络中间节点对视频流进行修改（如加水印、动态插入广告、拼接），同时为了保证该修改流与原始参考流在终端设备（目的地）严格同步，而采用双向时钟应答（NTP/PTP变体）的现有技术。

2. **关键词组合建议**：

* `("inter-destination synchronization" OR "IDMS" OR "destination synchronization")` （目的地间同步）

* `AND ("time stamp" OR "arrival time" OR "round-trip delay" OR "restitution" OR "NTP" OR "PTP")` （时间戳/到达时间/往返延迟）

* `AND ("media modification" OR "transcoding" OR "ad insertion" OR "alternative content" OR "stream processor")` （媒体修改/广告插入/替代内容）

3. **分类号锁定**：

* **H04N 21/43**：专门针对用在客户端的电视信号或关联数据流之间的同步（Spatial or temporal synchronization of data streams）。

* **H04N 21/242**：服务器端的同步机制（Synchronization processes, e.g. processing of timestamps）。

根据权利要求1，所述方法还包括以下步骤；为至少所述第一或第二同步点提供所述延迟信息；使得至少所述第一或第二同步点能够延迟流的输出；以使得分别由第一和第二同步点输出的第一和第二流基本上是同步的。

根据权利要求1或2所述的方法，其中由至少所述第一和第二同步点来输出所述第一和第二流；并且其中所述同步点被连接到用于使所述同步点同步的至少一个同步单元。

根据权利要求1至2中的任一项所述的方法，其中计算延迟信息的步骤还包括调整步骤；其用于调整第一和/或第二到达时间信息；以实现第一到达时间信息与第二到达时间信息之间的共同时间线；所述调整步骤基于同步相关信息的至少一部分。

根据权利要求4所述的方法，其中由到达时间信息调整模块来执行所述调整步骤；所述模块是同步单元的一部分；所述同步单元被提供有同步相关信息的至少一部分。

根据权利要求4所述的方法，其中在同步点处执行所述调整步骤；所述同步点包括到达时间信息调整模块；所述到达时间信息调整模块被提供有同步相关信息的至少一部分；并且同步单元被提供有已调整第二到达时间信息。

根据权利要求4所述的方法，其中在网络元件中执行所述调整步骤；该网络元件被配置为接收到达时间信息；该网络元件还包括到达时间信息调整模块；所述到达时间信息调整模块被提供有同步相关信息的至少一部分；并且同步单元被提供有已调整第二到达时间信息。

根据权利要求1－2中的任一项所述的方法，其中所述同步点是终端、网络节点或接入节点。

根据权利要求1－2中的任一项所述的方法，其中所述媒体流修改单元是用于接收并处理至少第一媒体流的媒体流处理设备；其中所述处理修改所述第一媒体流中的定时信息。

根据权利要求9所述的方法，其中所述媒体流处理设备是转换器或混合器。

根据权利要求1－2中的任一项所述的方法，其中同步单元被包括在同步点或网络节点中。

根据权利要求1－2中的任一项所述的方法，其中同步单元被包括在同步服务器中。

根据权利要求1－2中的任一项所述的方法，其中在一个或多个RTCP消息中用信号发送所述到达时间信息、所述同步相关信息和/或所述延迟信息。

根据权利要求13所述的方法，其中一个或多个RTCP消息是一个或多个RTCP扩展报告。

根据权利要求13所述的方法，其中所述RTCP消息中的至少一个至少包括标识分组的发送器的标识符、RTP时间戳、NTP时间戳、时钟速率值和/或媒体流相关标识符。