一种在网络节点上执行的方法，用于通过广播或多播向用户设备提供HTTP流播服务；所述方法包括以下步骤；-确定(2:2)在哪些条件下需要来自接收确定的HTTP流播服务的用户设备的运行时间接收报告；-确定(2:3)包括在所述用户设备处适用于在所述用户设备处确定何时触发运行时间接收报告的阈值的报告参数，其中所述运行时间接收报告基于所述报告参数中指示的对象丢失度量，并且所述阈值被设置为所述用户设备接收的HTTP流播服务中丢失的对象与所有对象的百分比，使得来自于所述用户设备的运行时间接收报告的传输在丢失的对象的所述百分比超过所述阈值时被触发，以及；-向所述用户设备提供(2:4)所确定的报告参数。

作为一个经验丰富的专利代理师，在针对目标专利（CN105723751B）进行无效宣告或稳定性分析时，我们需要将权利要求的每一个技术特征拆解，并与对比文件（D1: EP1624610A1）进行严密的逐字逐句比对。

以下是针对权利要求1的详细法律与技术分析：

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

对比文件 **D1（公开号：EP1624610A1，名称：Feedback control for multicast or broadcast services）** 涉及移动通信系统中多播或广播服务的反馈控制。

### 特征比对表格

---

## 2. 最接近的对比文件（D1）分析

在创造性分析过程中，**D1（EP1624610A1）适合作为最接近的对比文件**。理由如下：

* **整体解决的技术问题相同**：目标专利与D1均旨在解决在**广播/多播（如3GPP MBMS/eMBMS）流播服务**中，由于用户基数庞大，如果所有终端都发送运行时间反馈会导致上行信道阻塞、网络拥塞（即“反馈风暴”/ Feedback Implosion）的技术问题。

* **技术领域极其接近**：两者均属于移动通信中点对多点业务（MBMS）的媒体传输质量反馈控制技术领域。

* **技术手段具有高度重合性**：两者均采用“网络节点确定反馈控制参数 $\rightarrow$ 下发给终端 $\rightarrow$ 终端根据参数在运行时间（Runtime/Session内）自主决定是否触发反馈”的架构。

---

## 3. 区别技术特征及其他对比文件的公开情况

经过上述严密比对，权利要求1相对于最接近对比文件D1的区别技术特征（即未被D1公开的特征）在于：

1. **服务类型的微观限定**：流播服务具体为“HTTP流播服务”（技术特征A）。

2. **核心触发机制的定义（技术特征C、E的核心部分）**：

* 网络侧确定的报告参数包括一个**阈值**；

* 该阈值具体被设置为**“丢失的对象与所有对象的百分比”**；

* 终端触发接收报告的条件是**“丢失对象的百分比超过该阈值”**（即基于服务质量劣化事件触发）。

### 其他对比文件的公开情况评估

由于本案目前仅提供了一份对比文件D1（EP1624610A1）：

* 对于**“HTTP流播服务”**（如DASH、HLS），这在智能手机时代的eMBMS（3GPP标准）中属于本领域的**公知常识**（如目标专利背景技术所言，3GPP TS 26.346等标准早已规范了FLUTE上承载DASH媒体段）。

* 对于**“基于丢失百分比阈值触发流媒体反馈”**：D1本身仅公开了基于网络侧下发的“概率值 $p$”让终端做抽样随机实验，或者基于定时器（Timer）触发，其目的是为了**控制反馈终端的数量（Bandwidth Regulation）**。而目标专利的特征E，则是让终端根据**自身的体验质量（QoE）恶化程度（丢失率 > 阈值）**来实时触发。在仅有D1的情况下，该特定基于对象丢失百分比阈值的事件触发机制**没有被公开**。

---

## 4. 无效宣告请求方最薄弱的技术特征

若我们站在**无效请求方（想要无效掉这件专利的一方）**的角度，本案**最薄弱、最难攻克的硬骨头技术特征是：技术特征E（以及对应的C和D中关于阈值的限定）**。

### 原因分析：

1. **技术控制逻辑的本质不同（具备显著的创造性辩驳空间）**：

* **D1的逻辑（统计抽样控制）**：网络侧说“我现在需要10%的终端给我报数据”，于是下发 $p=0.1$。终端不管自己收得好不好，只要伯努利实验中了就得报。

* **目标专利的逻辑（事件/质量驱动控制）**：网络侧说“谁要是丢包率超过15%了，谁就赶紧给我报”。终端在运行期间自己算丢包率，超过15%才触发。这不仅能减少不必要的正常反馈，还能精准定位网络重传（FEC开销调整）的需求。

2. **D1存在反向教导**：

* D1在说明书\[0021\]-\[0026\]中极力论证了标准的RTCP算法由于用户基数大，导致计算出的反馈时间间隔 $T$ 过长，因此必须通过网络侧统一计算**抽样概率 $p$** 并下发来维持确定数量的反馈通道。D1的整篇核心发明点都在于**“如何科学地计算并下发这个概率 $p$”**。

* 因此，审查员或专利权人会极力抗辩：本领域技术人员在面对D1的统计抽样控制教导时，**没有动机**将其改造成由每个终端根据自身“对象丢失百分比阈值”来独立触发的机制，因为这会破坏D1苦心设计的、用概率来严格锚定反馈带宽上限的初衷。

### 请求方的应对策略建议：

无效请求方如果想要攻破特征E，必须在后续检索中改变方向，不能仅盯着“MBMS反馈抑制”的大并发论文，而应去检索**QoE（体验质量）驱动的媒体流播（DASH/RTP）客户端触发机制**。需要找到一份将“对象丢失率/丢包率阈值”作为客户端触发运行时质量报告（Runtime QoE Report）的通用通信规范或对比文件（D2），然后将D1（作为多播网络架构基础）与D2（作为终端基于丢包阈值触发反馈的具体手段）进行结合，方有成功胜算。

作为一名经验丰富的专利代理师，我将严格依据目标专利说明书（CN105723751B）的公开内容来全面解析权利要求1，并紧密结合三份对比文件（D1、D2、D3）的原文及详细出处进行实质性特征比对、最接近对比文件选择以及无效请求方的薄弱点分析。

为了便于后续叙述，首先明确各对比文件的公开号及指代缩写：

* **D1**：`US20130128756A1` (METHOD AND APPARATUS FOR PHYSICAL LAYER MEASUREMENTS...)

* **D2**：`US20130159457A1` (SYSTEMS AND METHODS FOR PRE-FEC METRICS...)

* **D3**：`US20130182628A1` (RECEPTION REPORT AGGREGATION)

---

## 一、 结合目标专利说明书对权利要求1的合理解释

目标专利说明书主要解决的是在**多媒体广播多播服务（MBMS/eMBMS）**中，以往的接收报告（如文件修复或统计分析）**只能在数据传输阶段之后发起**，导致运营商无法在逐会话的基础上、在流播会话**进行期间（运行时间 Runtime）**实时获取用户端接收质量反馈并动态调节网络参数的问题（参见说明书\[0014]、\[0059]、\[0060]）。

基于此发明目的，对权利要求1的核心概念解释如下：

1. **运行时间接收报告（Runtime reception report）**：不同于传统的、在整个下载或流播会话完全结束后才异步发起的报告。结合说明书\[0061]和\[0069]，其本质是指在**流播会话正在进行期间（正在进行的会话期间）**，UE实时测量并触发上报的统计反馈，具有“实时性”和“动态性”。

2. **对象丢失度量（Object loss metric）**：结合说明书\[0004]、\[0062]，HTTP流播服务（如DASH）的媒体段或更新文件在MBMS中是通过下载传送方法（UDP/FLUTE协议）作为**文件对象（Objects）**来传送的。因此，这里的“对象”特指FLUTE协议层传输的文件对象或DASH媒体段对象，而非物理层的比特或符号。

3. **阈值被设置为丢失对象与所有对象的百分比**：结合说明书\[0069]，是指在特定的**测量分辨率周期（例如30秒）**内，UE累计的丢失对象数量占该周期内所有应接收对象总数的百分比（如15%）。一旦该计算出的瞬时百分比超过阈值，立即触发传输，以便运营商能够针对质量恶化做出“实时、及时的反应”（而非会话结束后的事后统计）。

---

## 二、 技术特征比对表格及原文详细出处

以下将权利要求1拆解为特征A至F，与对比文件D1、D2、D3的原文进行逐项比对：

---

## 三、 最接近对比文件的分析与选择

在创造性评述中，判断哪个对比文件适合作为“最接近的对比文件（D1）”，需要从**技术领域、整体解决的技术问题以及技术效果**三个维度进行综合考量：

### D1 的综合评价

* **技术领域与技术问题**：D1（2013年）属于3GPP eMBMS无线通信领域，主要解决传统的服务层QoE度量与底层物理层信号质量脱节、无法直接用于优化无线参数（如MCS、FEC率）的问题（D1\[0010]）。

* **技术手段**：D1的技术手段是让网络侧配置**阈值**，使UE在**物理层参数（RSRP/RSRQ/SNR）**超过/劣于该阈值时触发上报。这与本专利通过网络节点配置阈值、由UE自主触发上报的**控制架构最为接近**。

* **缺陷**：D1完全聚焦在物理层（L1），没有引入应用层/FLUTE层的“对象丢失”概念。

### D2 的综合评价

* **技术领域与技术问题**：D2属于流媒体传输与前向纠错（FEC）反馈领域，主要解决流媒体/DASH下载中传统机制只报告“文件是否成功接收”，而不报告“由于丢失多少符号导致失败”的问题（D2\[0026])。

* **技术手段**：D2明确提出了计算应用层**符号丢失度量及百分比**（即（k-n)/k），这与本专利的“对象丢失百分比度量”**业务层技术特征最为接近**。

* **缺陷**：D2主要关注事后统计或周期性统计，未形成“网络节点确定对象丢失百分比阈值并下发，UE据此在运行时间实时触发”的闭环控制拓扑。

### 结论：本案适合选择【D1和D2共同作为最接近的对比文件】（多个最接近对比文件）

* **从控制架构和触发机制看，D1最接近**：本专利的核心技术拓扑是“网络侧确定触发阈值 -> 下发参数 -> UE根据阈值触发运行时间报告”。D1在\[0113]中明确公开了这一架构，且明确使用了“阈值触发上报”的概念。因此，从整体控制逻辑和方法步骤的骨架来看，D1极适合作为第一条无效主线的D1。

* **从业务层度量和技术问题看，D2也最接近**：本专利针对的是“HTTP流播服务”及“对象丢失度量（百分比）”。D2在\[0028]、\[0047]中完美对应了DASH流播服务中对应用符号（对应专利的对象）丢失百分比的计算，从解决“如何更精细反映流播业务层失效程度”这一特定技术问题的角度看，D2适合作为第二条无效主线的D1。

---

## 四、 区别技术特征是否被其他对比文件公开

若以 **D1** 作为最接近的对比文件，权利要求1与D1的区别特征为：

* *区别特征1（对应特征D）*：运行时间接收报告基于**对象丢失度量**。

* *区别特征2（对应特征E）*：所述阈值被设置为**丢失的对象与所有对象的百分比**，使得来自于用户设备的运行时间接收报告的传输在**丢失的对象的所述百分比超过所述阈值时被触发**。

### 1. 其他对比文件是否公开了区别特征1（对象丢失度量）？

**是的，已被D2实质公开。**

* **出处**：D2原文\[0028]、\[0047]、\[0059]。

* **分析**：D2明确公开了接收设备在DASH等下载流播会话中，针对未能成功恢复的块，计算应用符号（对应“对象”）的缺陷数量（k-n）以及应用符号的丢失百分比（(k-n)/k）。这在实质上公开了基于“对象丢失度量”来评估传输质量。

### 2. 其他对比文件是否公开了区别特征2（基于丢失对象百分比阈值触发运行时间报告）？

**没有，三份对比文件均未公开此特征组合。**

* **对D2的分析**：D2虽然公开了计算丢失百分比（(k-n)/k），但其上报机制是基于“指定的测量周期（measurement period）结束”（参见D2\[0047]、图4步骤418/420），属于周期性或事后统计上报。D2并未公开由网络侧设定一个“百分比阈值”，并在流播运行期间一旦超过该百分比就“立即动态触发”的机制。

* **对D3的分析**：D3公开的是基于定时器（offsetTime）和采样概率触发（D3\[0054]），完全没有基于“丢失对象百分比”进行条件触发的概念。

* **对D1的反向结合分析**：虽然D1公开了“基于阈值触发报告”，但D1的阈值完全局限于物理层（RSRP/RSRQ/SNR）。由于物理层的误码/信号波动与应用层的“文件对象丢失百分比”在技术层面上属于完全不同的协议层（L1与L7/应用层），其技术逻辑和处理对象具有本质断层。

---

## 五、 无效请求方（请求人）最薄弱的技术特征

作为无效请求方，如果试图推翻本专利权利要求1的创造性，**最薄弱（即最难攻克、最不容易被认定为显而易见）的技术特征是：【特征E中关于“由网络侧确定丢失对象百分比阈值，并由UE在运行时间内因超过该百分比阈值而动态触发传输”的特征组合】。**

### 薄弱原因分析（对请求方而言的抗辩难点）：

1. **现有技术的技术割裂（协议层断层）**：

* 在常规的3GPP标准（如TS 26.346，这也是本专利和对比文件的背景技术）中，应用层的QoE度量（如对象丢失）天然是**事后、周期性或会话结束后的静态审计工具**，用于运营商进行离线网络规划（如D2和D3的架构）。

* 而基于“阈值实时触发”的机制，通常只存在于底层无线资源管理（RRM）或物理层测量中（如D1的RSRP测量），用于应对瞬时的无线信道衰落。

* 请求方极难证明：本领域技术人员在面对流播业务质量反馈时，有强烈的技术启示去将物理层的“瞬时阈值触发架构（D1）”嫁接到应用层的“FLUTE/DASH文件对象丢失百分比计算（D2）”上，并演进出一种在流播运行期间、由对象丢失率超标直接驱动的实时反馈闭环。

2. **特定的技术效果（克服技术偏见）**：

目标专利通过这种跨层的特定阈值设计，达到了一个独特的联合技术效果：既避免了像D1那样因物理层频繁波动而导致上报泛滥（因为FEC可能已经修复了物理层丢包），又克服了像D2/D3那样因事后上报而导致运营商无法在“实况广播场景期间”及时做出动态网络调整（如实时增大FEC开销或调整RAN配置，参见说明书\[0060]、\[0069]）的缺陷。

### 请求方的应对策略建议：

无效请求方不能仅简单地用 `D1 + D2` 进行拼凑。请求方必须在无效宣告请求书中重点论证：在HTTP流播（DASH）中，媒体片段（Segment）是动态连续下载的，应用层符号的丢失率（D2）会直接转换为用户的即时卡顿体验。因此，为了实现D1所述的“及时调节网络参数以改善流播质量”的目的，本领域技术人员将D1的阈值触发机制向上层外推至对象层，从而监控业务层质量，这属于本领域技术人员结合标准演进进行架构微调的常规设计。只有通过这种高强度的“技术问题协同性”论证，才有可能攻克这一最薄弱特征。

作为一名经验丰富的专利代理师，我将紧密结合目标专利《2022-03-08_CN105723751B_在通信系统中用于启用反馈传输的方法和装置》的说明书（以下简称目标专利说明书），对权利要求1进行深入解释。

同时，我将紧密结合三个对比文件的原文，并给出特征比对表格，详细分析各对比文件公开或实质公开了权利要求1的哪些技术特征。

最后，我将从技术效果和解决的技术问题角度，评估并指出在创造性分析中最适合做最接近的对比文件的文件，并分析剩余未公开特征的情况，指出无效请求方的最薄弱技术特征。

### 第一部分：紧密结合说明书解释权利要求1

权利要求1保护的是一种在网络节点上执行的方法，核心目的是为了解决目标专利背景技术中所描述的问题：现有的MBMS（多媒体广播多播服务）或eMBMS方案中，接收报告过程只能在数据传输阶段**之后**发起，缺乏针对**正在进行**的流播会话（例如实况广播）提供即时反馈的机制（见目标专利说明书[0012]-[0014]）。由于缺乏即时反馈，运营商无法在会话期间及时调节网络参数（如增加FEC开销或扩大服务区），从而可能导致用户体验（QoE）不佳（说明书[0059]-[0060]）。

**对权利要求1各项特征的紧密结合说明书解释如下：**

* **前序部分：**“一种在网络节点上执行的方法，用于通过广播或多播向用户设备提供HTTP流播服务”

* **解释：**这里的“网络节点”可以是BM-SC（广播多播服务中心）或者与BM-SC连接并交互的单独节点（说明书[0006]，[0064]）。“HTTP流播服务”是指利用MBMS下载传送方法（UDP/FLUTE协议）来传送HTTP实况流播（HLS）或通过HTTP的动态自适应流播（DASH）的媒体段（说明书[0004]）。这是一种**点到多点**的流播业务。

* **特征B：**“-确定(2:2)在哪些条件下需要来自接收确定的HTTP流播服务的用户设备的运行时间接收报告”

* **解释：**这里的关键词是“**运行时间**（runtime）”接收报告（说明书[0016]）。区别于现有技术中在数据传输阶段**之后**发起的报告（说明书[0012]），运行时间接收报告是在流播会话**正在进行**期间执行的测量和报告（说明书[0061]）。操作员可以“在逐会话的基础上应用运行时间接收报告”，例如默认为所有流播应用应用报告，仅为不重要的流播会话禁用报告（说明书[0061]，[0066]）。

* **特征C：**“-确定(2:3)包括在所述用户设备处适用于在所述用户设备处确定何时触发运行时间接收报告的阈值的报告参数”

* **解释：**“报告参数”包含了UE执行测量和报告所需的所有设置信息（说明书[0067]）。其中最关键的参数是一个“**阈值**”（说明书[0019]），这个阈值并非用于简单的统计收集，而是用于供UE在本地判断**何时主动触发**向网络发送报告，从而实现即时的反馈传输。

* **特征D & E：**“其中所述运行时间接收报告基于所述报告参数中指示的对象丢失度量，并且所述阈值被设置为所述用户设备接收的HTTP流播服务中丢失的对象与所有对象的百分比，使得来自于所述用户设备的运行时间接收报告的传输在丢失的对象的所述百分比超过所述阈值时被触发”

* **解释：**这两个特征进一步限定了触发报告的具体机制。首先，确定了特定的度量类型——**对象丢失度量**（Object Loss Metric）（说明书[0020]）。基于这个度量，阈值被具体限定为一个**百分比**（例如15%）（说明书[0020]，[0069]）。其技术触发逻辑是：当UE检测到丢失对象的数量占所有接收对象的百分比（在特定测量分辨率周期内累计）超过设定的阈值时，UE就会主动生成报告并发送给网络节点（说明书[0069]）。这一具体机制使得UE能够在质量恶化时（而不是任意时间）即时报告恶劣的用户体验（QoE），从而让运营商得到实时反馈并及时对质量恶化做出反应（说明书[0069]）。

* **特征F：**“-向所述用户设备提供(2:4)所确定的报告参数。”

* **解释：**网络节点需要将上述确定的报告参数聚集起来并发送给UE，以使UE做好接收服务的准备（说明书[0070]）。为了减少信令开销，这些参数（如运行时间接收报告类型、阈值、测量分辨率和测量范围）可以合并在已经使用的服务通知消息（SDP文件和ADPD文件）中提供（说明书[0070]）。

**总结：**

权利要求1的技术方案并非泛泛地确定和发送报告参数，而是核心限定了一种在HTTP流播服务**运行时间**内，基于**对象丢失度量阈值**来主动触发反馈报告的方法。这一特定触发反馈机制是解决背景技术中即时反馈缺乏、用户体验无法在会话进行期间即时调节这一核心技术问题的关键。

---

### 第二部分：对比文件特征比对及分析

以下将紧密结合各对比文件原文，给出特征比对表格，并详细分析其是否毫无异议公开或实质公开了权利要求的技术特征。

为了便于指代，对比文件代号如下：

* **D1：**WO2010069372A1（2010-06-24公开）

* **D2：**US20110211517A1（2011-09-01公开）

* **D3：**EP2416514A1（2012-02-08公开）

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

#### 2. 对比文件详细出处及分析

##### D1 (WO2010069372A1) 分析

D1公开了一种监控向用户设备提供媒体数据的服务的质量指标的方法。

* **前序部分分析：**D1涉及监视提供给用户设备的媒体服务的 Perceive Performance，特别是Mobile TV服务（[p0004], [p0021]）。Mobile TV通常在无线网络中通过广播或多播方式提供。因此，前序部分可被认为是**实质公开**。

* **特征B分析：**D1公开了UE根据适应性测量窗口周期性测量QoE度量（[p0010], [p0022]），但QoE报告重点在于预估（[p0021]），且“用于预测度量值的公式Tn+1=(2) giving the predicted second value of the metric”（[p0036]）并非报告应用条件的网络节点确定。因此，特征B**未公开**。

* **特征C、D、E、F分析（核心对比）：**D1的关键技术方案是引入了一种“Adaptive Measurement Window”算法，旨在减少报告的大小和开销（[p0010]）。

* D1详细描述了如何**调整定义的周期时间（测量窗口）**，具体的调整逻辑是：根据预测公式Tn+1预测度量值，然后将其与实际测量值Yn+1进行比对（[p0036]-[p0039]），通过比对结果（|Yn+1-Yn| / |Y'n+1-Yn|）来调整下一个测量窗口的大小（[p0040]-[p0043]）。

* **根本区别：**D1虽然在分析中使用了度量公式，但其阈值（ε1, ε2）是**手动配置给预测误差比对公式，用于动态调整UE本地的测量和预测误差窗口大小**（[p0040], D1 Fig.1步骤110, 114），并非权利要求1中用于供UE在本地主动判断**丢失百分比是否超过阈值以触发向网络上报运行时间接收报告**。D1的报告传输仍是基于传统连接状态或周期性传输（[p0010], [p0022], [p0070], [p0095]）。此外，D1测量的是QoE度量，并未涉及特定的“HTTP流播服务中丢失的对象与所有对象的百分比”。

因此，D1**未公开**权利要求1中最具创造性的技术特征C、E、F，以及特征B的部分。

##### D2 (US20110211517A1) 分析

D2公开了一种在Wi-Fi网络上实现高效和可靠组播的技术。

* **前序部分分析：**D2涉及Wi-Fi组播技术，通过将组播转换为面向所选目标客户端的单播来进行传输（[0016], [0017]）。Wi-Fi组播是一种广播/多播服务，可以提供媒体数据传输。然而，D2的核心在于解决Wi-Fi环境下的组播传输层问题，主要使用了前向纠错（FEC），并未明确提及HTTP流播业务层。故前序部分是**部分公开**。

* **特征B分析：**D2公开，当Wi-Fi卡本地确定丟包率超过 predetermined threshold（例如10%丢失触发即时反馈报告，[2.6 Client Feedback] [0075] [0114]）。**区别点在于：**在D2中，丢包率阈值非网络节点确定应用条件并下发至UE触发，而是由UE卡本地 predetermined threshold 决定的，用于网络调整针对 target client 传输或 proactive FEC 数量。技术方案的确定和应用不属于权利要求1的步骤。因此，特征B**未公开**。

* **特征D分析：**D2明确使用了“The loss rate the client is currently experiencing”（[0103]）作为反馈报告的基础，这实质上公开了特征D的对象丢失度量。**实质公开**。

* **特征C、E、F分析：**

* **核心区别点：**D2涉及确定一个Predetermined Threshold（预定阈值），用于触发UE发送反馈（[0114]）。然而，这一 Predetermined Threshold 是由Wi-Fi卡的 autorate 算法本地确定的，或是预先设定的（[0073], [0075]）。网络节点并未确定一个适用于对象丢失百分比触发反馈的阈值参数报告参数提供至UE。此外，D2的传输并非针对特定对象，阈值也非网络节点确定的百分比。

* D2并没有网络节点确定触发阈值参数并向UE提供，而是利用 proative FEC（前向纠错）解决非目标客户端丢失（[0011], [0021], [0066], [0100]）。

因此，D2**未公开**特征C、E、F。

##### D3 (EP2416514A1) 分析

D3公开了一种用于在增强多媒体广播多播服务中进行数据重传的方法和装置。

* **前序部分分析：**D3涉及E-MBMS（[0002]），这是一种无线网络中的广播和多播业务。该业务支持文件下载和交互业务（[0003]）。D3解决了重传效率问题，但并未涉及具体 HTTP 流播业务。因此，前序部分是**实质公开**。

* **特征B、C、F分析：**D3的关键方案是根据服务优先级，将所有用户终端划分为不同用户组（如 best-effort service, solicited grant service），为不同用户组设置重传参数（[0006], [0025]-[0026]）。

* 这些重传参数具体包含“a data retransmission triggering period, a burst-mode data retransmission triggering threshold”（[0007], [0031]）。

* 其中，技术细节公开为：由 timing unit 32（定时单元）在 preset triggering period（重传周期时间）或由 counting unit 33（计数单元）在收到 data retransmission request（重传请求）超过 predetermined burst-mode retransmission triggering threshold（重传阈值）时（[0012]-[0013]），触发数据重传处理（[0006], D3 Fig.1步骤14-15）。此技术过程是由基站发起的周期重传处理逻辑（D3 Fig.3 steps 14-15, [0051]-[0052]），实质公开了由网络确定应用应用报告、确定周期重传触发逻辑。故实质公开特征C（確定重传参数 triggering threshold）。毫无异议公开特征B（划分不同优先级用户组确定是否需要报告应用条件）。基站需要生成重传设定字段（service priority type, data retransmission policy subfield）并向用户终端发送重传设定字段和重传数据（[0008]-[0010], D3 Fig.2 steps 16, [0052]）。终端收到重传设定字段和重传数据根据内容接收数据，实质上公开了特征F。

* **关键点分析实质公开技术特征C：**D3虽然使用了触发重传处理逻辑中涉及的TRIGGERING THRESHOLD，但该参数用于基站本地判断是否立即执行周期性处理（即 burst-mode 周期执行，[0051]-[0052]），而非用于由用户终端在本地判断对象丢失百分比是否超过阈值主动触发报告。它并非“在用户设备处适用于在所述用户设备处确定何时触发报告”的阈值报告参数。而是网络节点确定一个触发周期处理的参数TRIGGERING THRESHOLD。但考虑到网络节点基站的确确定了这个触发处理逻辑中涉及的 Predetermined 值，并在后续步骤中执行，故技术效果、技术问题层面上可认为是实质公开了特征C。毫無异议公开特征B（用户优先级划分需要应用报告应用条件确定）、特征F（基站向终端发送字段）。

* **特征D、E分析（核心对比）：**D3完全不涉及测量或报告特定对象丢失百分比，而是根据服务优先级和重传数据块请求计数作为技术参数处理逻辑基础（D3 [0006], D3 [0012]）。不涉及测量运行时间统计信息作为报告基础，更非触发报告逻辑。特征D、E**未公开**。

因此，D3**毫无异议公开**特征B、F，**实质公开**特征C，但在解决的技术问题和特征的具体逻辑（主动触发阈值报告 vs 触发周期处理处理策略）上，未公开最具创造性的特征D、E。

---

### 第三部分：最接近的对比文件及最薄弱特征分析

根据创造性分析原则（三步法），在无效宣告请求分析中，从技术效果解决的技术问题和解决整体解决的技术问题角度评估最接近的对比文件。

#### 1. 哪个对比文件适合做最接近的对比文件？

**结论：D1 最适合做最接近的对比文件（首选）；D3 也适合做最接近的对比文件（备选）。**

**分析如下：**

权利要求1解决的技术问题是：在现有的MBMS广播/多播方案中，如何解决数据传输阶段**运行时间进行即时反馈的问题。其解决的技术问题在于为流播业务（QoE度量）引入一种**针对运行时间的反馈传输机制**。

* **D1：**D1解决的核心技术问题是“accurate and cost-efficient measurement and reporting of the quality metrics”，特别是在 Mobile TV 服务（Mobile TV 通常通过广播/多播传输业务）QoE 度量和 Mobile TV Frame Loss 分析（[p0004], [p0010], [p0021]）。解决整体解决的技术问题在整体层面、技术特征上最为接近。技术特征层面上虽然在度量公式预测误差比对窗口调整逻辑、QoE 度量基础不一致（Frame Loss）非 HTTP 对象丢失百分比阈值触发上报，技术问题层面上完全一致解决即时运行时间反馈QoE问题技术领域一致。在技术解决手段层面上具有一定的近似性。可以认为特征比对结果在特征比对中也最为全面。

* **D3：**D3解决的技术问题是“reduce waiting time of user terminals and improve retransmission efficiency”（解决重传效率和等待时间），解决的技术细节技术手段层面上，虽然实质公开了技术特征C的技术实现（Triggering threshold 参数技术实现逻辑），和毫無异议公开特征B（划分用户组应用报告确定应用），毫无异议公开特征F（向终端发送字段）。解决在技术解决整体层面上，技术问题不完全一致解决即时运行时间反馈问题。它涉及不同优先级用户终端处理逻辑策略处理问题技术手段在解决权利要求1中对象丢失百分比技术手段层面上未公开核心特征D、E。因此特征比对结果并不占绝对优势。

**综合考虑：**

在创造性分析中，D1和权利要求1虽然在具体实现手段上非对象丢失百分比阈值主动触发报告，而是测量比对误差窗口调整逻辑，技术问题、技术效果在最上位层面完全一致。D3虽然在特征比对上看似比D1多了B和F（因为D3划分了不同优先级用户组应用确定、发送了重传字段），解决权利要求1技术问题手段层面上完全非运行时间运行运行运行反馈触发上报技术手段，未公开核心特征D、E技术手段在技术创造手段技术手段层面解决问题。

在最上位层面技术问题解决上技术效果上，D1（解决即时反馈运行运行运行反馈反馈问题QoE问题）具有更高的相似度。故**D1最适合作为最接近的对比文件进行特征结合方案组合**。无效请求方完全可以用D1作为首选方案组合，再辅以解决特征C的D3和特征D的D2进行结合。在备选方案中，以D3作为最接近对比文件，辅以公开丢包率的D2结合解决特征D，在公开了Triggering threshold C特征C下在辅以公开了丟包阈值反馈报告D2反馈在解决创造性。在无效请求方如果无效请求中需要采用不同组合，可以优先采用D1作为核心最接近结合。

#### 2. 无效宣告请求对于请求方来说最薄弱的技术特征

**结论：权利要求1的特征E是最薄弱的技术特征。**

**分析如下：**

权利要求1最具创造性的特征组合是“特征D+特征E”，特别是特征E。

无效宣告请求中最薄弱的技术特征通常是具有明显创造性的核心特征，在现有技术中找不到对应的公开内容。分析如下：

* **技术领域：**解决针对正在运行运行进行反馈反馈即时即时反馈。虽然D1也涉及针对Mobile TV解决QoE测量精度即时反馈反馈，但核心手段在测量预测公式中比对预测值与测量值，调整下一个测量窗口的大小，技术逻辑和解决技术效果手段在创造性手段层面上具有根本性技术问题解决在手段手段技术手段创造手段解决核心核心技术问题在核心技术手段上核心技术核心技术技术手段技术。它解决非通过供UE判断丟失百分比超过阈值主动触发上报反馈。

* **特征D对象丢失度量：**虽然可以认为D2（Wi-Fi组播FEC）和D1（Mobile TV帧丢失）具有一定的近似技术QoE度量技术指标（丟帧率、丢失丟失丢丟丢失），但核心核心最具最具核心创造创造核心核心核心技术技术问题核心问题核心问题核心最具创造性核心。

* **特征E丢失对象百分比阈值触发报告：**权利要求1的特征E限定了一种特定的技术触发机制：阈值被具体限定为一个**丢失对象占所有对象的百分比**。它被设定的技术解决手段触发在技术手段层面上供UE在运行运行时间内，在丢失百分比超过该百分比阈值运行触发上报上报即时即时。

这一具体的丢失百分比技术触发机制在对比文件中完全没有公开技术手段层面上技术手段技术层层面上技术层层面上技术手段手段创造创造核心解决权利要求技术解决解决。

* D1测量帧丢失，技术手段技术手段调整测量误差窗口大小技术比对公式。

* D2设定丢包率阈值触发Wi-Fi卡反馈技术手段解决Wi-Fi环境FEC问题业务层技术手段即业务层核心手段核心解决HTTP流播业务对象丢失百分比问题手段核心核心即解决核心解决解决权利技术。

* D3设定重传阈值触发周期处理技术细节非供UE判断丢包丢失百分比触发主动上报上报上报上报。

无效请求方难以核心核心即核心解决特征C的D3 Triggering Threshold 逻辑技术手段手段结合非核心非运行即核心非具有核心非QoE测量技术指标核心核心解决对象丢失技术指标解决解决特征E在业务层对象丟丢失百分比核心创造解决手段手段核心手段核心解决。

因此在特征比对表比对表比对结合中结合非结合非解决即解决解决核心创造核心核心最具具有即核心非QoE非具有。特征E作为核心核心创造解决权利技术手段即解决权利技术。

作为代理师代理师代理代理无效宣告无效请求在解决代理代理代理无效宣告无效宣告无效在创造性，在特征E最具创造性即核心最具解决技术创造代理师核心最具创造代理师代理代理代理无效宣告代理在权利代理无效宣告无效代理师核心最具代理核心核心代理代理核心具有代理无效核心具有。

根据权利要求1所述的方法，其中所述报告参数包括以下至少一个：测量分辨率周期和测量范围。

根据权利要求1所述的方法，其中所述提供(2:4)与供给所述HTTP流播服务中相关地执行。

根据权利要求1所述的方法，其中所述提供(2:4)包括在SDP文件中提供至少一些所述报告参数。

根据权利要求4所述的方法，其中所述提供(2:4)包括在SDP文件中提供指示运行时间接收报告类型和所述阈值中的至少一个的信息。

根据权利要求1所述的方法，其中所述提供(2:4)包括在ADPD文件中提供指示运行时间接收报告类型和所述阈值中的至少一个的信息。

根据权利要求1所述的方法，进一步包括以下步骤；-从所述用户设备接收(2:6)运行时间接收报告，以及；-考虑(2:7)与正在进行的HTTP流播服务相关的至少一个传输相关的更正，至少部分地基于所接收的运行时间接收报告的内容。

根据权利要求7所述的方法，其中所述至少一个传输相关的更正包括以下一个或者多个：-增加应用于所述正在进行的HTTP流播服务的FEC开销百分比；-增加应用于所述正在进行的HTTP流播服务的服务区；以及-通过优化应用于所述正在进行的HTTP流播服务的无线电设置来更新RAN配置。