对比文件名称：2009-08-06_WO2009097230A_发明申请_WO2009097230A1 METHOD AND APPARATUS FOR EXPEDITING DELIVERY OF PROGRAMMING CONTENT OVER A BROADBAND NETWORK
目标专利名称：317倒回实时通信会话CN105103520B
本次调用模型名称：DeepSeek
### 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：所述接收方设备在实时通信会话期间从传送方设备接收数据，《直接公开》 | 对比文件说明书[0012]段：“...subscribers associated with client devices 230 (e.g., PCs, PDAs, portable computers, media centers, portable media players, mobile telephones and set-top boxes) are in communication with...headend 220...The headend 220 is in communication with the client devices 230 over the broadband access network 210.” <br> 图5流程描述步骤515：“the client device receives the catch up stream...” | 对比文件明确描述了客户端设备（client device，相当于目标专利的接收方设备）在接收节目内容（相当于参与通信会话）期间，从位于前端的流服务器（streaming server 208，相当于传送方设备）接收数据（如追赶流）。这直接公开了接收方设备从传送方设备接收数据的基本特征。 |
| **技术特征B**：所述方法包括：在所述接收方设备尝试接收来自所述传送方设备的实时媒体流的同时检测媒体接收间隙《隐含公开》 | 对比文件说明书[0003]段：“However, this simple manner of operation does not apply to the delivery of IPTV. In this environment, the client module typically must store a prescribed amount of media information in a buffer before it begins to play the media information to the user. It requires a certain amount of time to fill up this buffer when the user first connects to a stream of media information. Further, digital media information is commonly expressed as a series of key frames (e.g., I frames) and difference frames (e.g., B and P frames). A client module must wait for a key frame before it begins to present the media information. As a result of these factors, there will be a noticeable lag prior to the presentation of programs as the user switches from one channel to the next.” <br> [0017]段：“When changing channels in an IPTV environment using a multicast join request, there is generally a perceptible delay of up to several seconds between the time at which the channel is changed and the time when the content can be decoded and displayed by the client device. This delay arises from the time required to join the appropriate multicast stream and the time required to receive a key frame such as an I frame.” | 目标专利中的“媒体接收间隙”指接收方未能成功接收或播放实时媒体流的时间段。对比文件详细描述了在IPTV环境中用户切换频道时，由于需要加入多播流和等待关键帧（I帧），客户端设备在能够解码和显示内容之前会经历一个可感知的延迟（“noticeable lag”或“perceptible delay of up to several seconds”）。这个延迟发生在客户端尝试接收（加入）新的媒体流（相当于目标专利的实时媒体流）的同时，并且导致内容无法被即时呈现。因此，本领域技术人员可以毫无疑义地理解，对比文件公开了在尝试接收实时媒体流时存在一个媒体无法被播放的“间隙”或延迟，该延迟是由网络和编码特性导致的，相当于隐含公开了“检测媒体接收间隙”这一技术特征。 |
| **技术特征C**：响应于所述检测而向所述传送方设备传送倒回请求，所述倒回请求被配置成触发所述传送方设备生成和提供所述实时媒体流的包括在所述媒体接收间隙期间丢失的媒体的时间延迟版本《直接公开》 | 对比文件说明书[0004]段：“...the client device receives the user request and, in response, the client device transmits the request to the streaming server in the headend, which causes the streaming server to create a unicast catch up stream...” <br> 图5流程步骤505、510：“In step 505 the client device receives the user request. In step 510 the client device transmits the request to the streaming server in the headend, which causes the streaming server to create a unicast catch up stream that commences with a key frame.” <br> [0017]段：“This problem can be overcome by first creating a short-lived transport stream that uses a reduced bit rate representation of the content sent at an accelerated pace that allows the client device to immediately begin decoding and displaying the content. The short-lived transport stream, also referred to herein as a catch up stream, is unicast to the client device.” | 目标专利的“倒回请求”用于触发传送方生成并提供实时媒体流的时间延迟版本（倒回流）。在对比文件中，当用户切换频道（这隐含着客户端检测到无法立即播放新频道内容，即存在媒体接收间隙）时，客户端设备会向流服务器（传送方）发送一个请求（用户请求或频道改变请求）。该请求直接导致（“causes”）流服务器创建一个单播的“追赶流”（catch up stream）。这个追赶流正是从关键帧开始的、实时多播流的一个时间延迟版本（因为它始于过去的某个关键帧，并以加速速率发送，以追上实时流）。因此，对比文件直接公开了响应于（隐含的）间隙检测而发送请求，以触发生成和提供实时流的时间延迟版本。 |
| **技术特征D**：响应于所述倒回请求而接收倒回流，其中所述倒回流被配置成由所述接收方设备独立于所述实时媒体流来播放。《直接公开》 | 对比文件说明书[0004]段：“...the streaming server to create a unicast catch up stream...The client device receives the catch up stream and begins buffering it.” <br> 图5流程步骤515：“The client device receives the catch up stream in step 515...” <br> [0017]段：“The client device uses the unicast catch up stream until it catches up with the multicast stream...” | 对比文件明确记载，客户端设备响应于其发送的请求（相当于倒回请求），会从流服务器接收一个“追赶流”（catch up stream）。该追赶流是一个独立的单播流，客户端设备可以对其进行缓冲、解码和呈现（播放），如说明书[0004]段和图5步骤525所述。追赶流的作用是让客户端在追上实时多播流之前独立播放内容，这完全对应于目标专利中“倒回流被配置成由接收方设备独立于实时媒体流来播放”的特征。因此，该特征被直接公开。 |
| **技术特征E**：其特征在于，进一步包括：在所述倒回流被接收的同时继续接收所述实时媒体流。《隐含公开》 | 对比文件说明书[0004]段：“...sends a request to join the multicast stream. Once the client device starts receiving the multicast stream, the client device discards any remaining images or pictures in the catch up stream that precede the synchronization time. The client device also begins to buffer the multicast stream as it continues to play the buffered catch up stream. When it reaches the end of the catch up stream, the client device begins to play out the buffered multicast stream.” <br> 图5流程步骤535、545：“...sends a request to join the multicast stream in step 535...the client device also begins to buffer the multicast stream as it continues to play the buffered catch up stream in step 545.” | 目标专利的特征E描述了在接收倒回流的同时继续接收实时媒体流。对比文件图5流程和相应描述表明，客户端设备在接收和播放追赶流（倒回流）的过程中，会发送加入多播流的请求（步骤535），并随后开始接收（缓冲）多播流（实时媒体流）（步骤545）。这意味着在追赶流播放的后期阶段，客户端同时接收着追赶流和实时多播流。虽然对比文件没有明确说明从何时开始“同时接收”，但根据流程逻辑，在发送加入请求后，一旦多播流可用，客户端即可开始接收它，而此时追赶流可能仍在播放。因此，本领域技术人员可以合理推断出存在一个时间段，客户端同时接收着追赶流和实时多播流，即该特征被隐含公开。 |
| **技术特征F**：其特征在于，在响应于所述倒回请求而接收所述倒回流的同时所述实时媒体流的接收停止。《未公开》 | 对比文件未描述在接收追赶流（倒回流）期间停止接收实时（多播）流。相反，如特征E论述，客户端在播放追赶流期间会尝试加入并开始接收多播流。 | 对比文件没有公开在接收追赶流（倒回流）的同时停止接收实时媒体流（多播流）。其工作流程是：先通过单播追赶流让客户端快速开始播放，然后客户端加入多播流并开始接收，最终从追赶流无缝切换到多播流。在整个过程中，没有提及在接收追赶流期间“停止”接收多播流。因此，该特征未被对比文件公开。 |
| **技术特征G**：其特征在于，所述倒回请求对应于隐式倒回请求，所述隐式倒回请求传达被配置用于由所述传送方设备评估的信息以准许所述传送方设备独立地触发所述倒回流的生成和递送。《隐含公开》 | 对比文件说明书[0004]、[0005]段及图5步骤505、510描述了客户端设备发送用户请求（如频道改变请求）给流服务器，该请求触发了追赶流的生成。该请求本身传达了用户想要观看特定节目内容的信息。流服务器评估此请求（识别请求的节目），并独立地决定创建和发送追赶流。 | 目标专利的“隐式倒回请求”指传达某些信息（如与媒体接收间隙相关的信息），由传送方设备评估后独立决定触发倒回流。在对比文件中，客户端发送的“用户请求”（如频道号）虽然主要表达观看意图，但该请求被服务器接收后，服务器基于对网络延迟（加入多播流和关键帧等待）的认知，独立决定生成并发送一个追赶流来加速内容呈现。客户端请求中“隐含”了需要快速启动的需求（因为切换频道必然有延迟），服务器评估后触发追赶流。因此，该特征可以被认为被隐含公开。 |
| **技术特征H**：其特征在于，所传达的信息与所述媒体接收间隙相关。《隐含公开》 | 如特征B和G的论述，对比文件中的用户请求（如频道切换）本身，在IPTV的上下文中，就间接传达了“将存在一个媒体播放间隙（延迟）”这一信息。因为服务器知道，对于任何频道切换请求，在客户端能播放多播流之前都会有一个由加入时间和关键帧等待时间构成的固有延迟间隙。 | 对比文件虽然没有明说请求中包含了“间隙时长”等具体信息，但本领域技术人员知晓，在IPTV系统中，频道切换请求这一动作本身，对于知晓系统特性的服务器（传送方）而言，就等同于传达了“客户端即将面临一个媒体接收/播放间隙”的信息。服务器正是基于这一认知来触发追赶流生成。因此，所传达的信息（频道切换请求）与媒体接收间隙是相关的，该特征被隐含公开。 |
| **技术特征I**：其特征在于，所述倒回请求对应于显式倒回请求，所述显式倒回请求显式地请求所述传送方设备提供所述实时媒体流的所述时间延迟版本。《直接公开》 | 对比文件说明书[0004]段及图5步骤510：“the client device transmits the request to the streaming server in the headend, which causes the streaming server to create a unicast catch up stream”。客户端设备发送的“请求”直接导致服务器创建追赶流。 | 目标专利的“显式倒回请求”指明确请求时间延迟版本。对比文件中，客户端设备发送的用户请求（频道改变请求）虽然字面上是请求某个频道（节目），但在该系统实现的上下文中，该请求被服务器解释并执行为：创建并发送一个始于关键帧的追赶流（即实时流的时间延迟版本）。从服务器端动作（创建追赶流）反推，客户端请求实质上就是显式请求了能够快速启动的内容流，而这个流正是时间延迟版本。因此，该特征可以被认为被直接公开。 |
| **技术特征J**：其特征在于，所述显式倒回请求请求所述传送方设备以相对于所述实时媒体流的第一延迟量提供所述实时媒体流的所述时间延迟版本，所述倒回流包括相对于所述实时媒体流的第二延迟量，所述第二延迟量不同于所述第一延迟量。《隐含公开》 | 对比文件说明书[0022]-[0024]段描述了“追赶比率”(Catch Up Ratio, CR)和追赶流持续时间(T_catchup)的计算，由服务器根据关键帧间隔(I_k)和目标比特率(R_t)等决定。例如，T_catchup = CR * I_k。客户端在请求时（如切换频道）并未指定延迟量。 | 目标专利的特征J描述了请求的延迟量与实际提供的延迟量可能不同。在对比文件中，客户端发送请求（如切换频道）时，并未指定一个具体的“延迟量”。服务器在收到请求后，独立地根据预设的追赶比率（CR）和当前流的关键帧间隔（I_k）来计算并生成具有特定延迟量（持续时间T_catchup）的追赶流。因此，客户端“请求的延迟量”（未指定或可视为期望立即播放）与服务器“实际提供的延迟量”（根据CR和I_k计算）是不同的。这符合特征J的界定，该特征被隐含公开。 |
| **技术特征K**：其特征在于，所述接收方设备对应于正参与所述实时通信会话的目标用户装备(UE)，并且所述目标UE播放所述倒回流，或者所述接收方设备对应于正仲裁和/或裁夺所述实时通信会话的服务器，并且所述服务器向参与所述实时通信会话的至少一个目标UE传送所述倒回流。《直接公开》 | 对比文件说明书[0012]段将client devices 230例举为机顶盒、移动电话等，即用户装备(UE)。[0004]段和图5描述了client device接收并播放追赶流。同时，说明书[0012]段指出headend 220（包含流服务器208）通过宽带网络与客户端设备通信，流服务器208负责生成并传输追赶流和多播流，仲裁内容传输。 | 对比文件明确公开了两种角色：1) 作为接收方/目标设备的客户端设备（client device，如机顶盒、移动电话，相当于UE），其接收并播放追赶流（倒回流）。2) 作为发送方/仲裁者的前端（headend）及其中的流服务器（streaming server），它接收请求，生成追赶流，并将其传送给请求的客户端设备（目标UE）。这直接对应于目标专利特征K描述的两种情况。因此，该特征被直接公开。 |
| **技术特征L**：其特征在于，所述媒体接收间隙对应于(i)其中少于阈值数目的用于所述实时媒体流的可用媒体分组成功抵达所述接收方设备的第一时间间隙，或者(ii)其中所述阈值数目的用于所述实时媒体流的可用媒体分组可用、但所述接收方设备处的条件抑制由所述接收方设备进行的回放的第二时间间隙。《隐含公开》 | 对比文件说明书[0003]、[0017]段描述的延迟间隙是由于需要加入多播流和等待关键帧（I帧）造成的。在此期间，客户端设备无法解码和显示内容。这可以理解为：在延迟间隙期间，能够被成功解码并呈现的“可用媒体分组”（即一个可播放的帧，特别是关键帧）少于播放所需的阈值（至少1个关键帧），因此属于目标专利中第(i)种情况。 | 目标专利定义了两种媒体接收间隙。对比文件描述的频道切换延迟，其本质是客户端在成功加入多播流并收到第一个关键帧之前，没有可用的、完整的媒体帧（分组）用于播放。这符合“少于阈值数目的可用媒体分组成功抵达”的情形（阈值至少为1）。因此，对比文件公开的延迟间隙对应于特征L的第(i)种情况，该特征被隐含公开。 |
| **技术特征M**：其特征在于，所述媒体接收间隙基于网络连接降级而发生。《隐含公开》 | 对比文件说明书[0003]、[0017]段将延迟归因于“加入多播流所需的时间”和“等待关键帧”。在基于IP的网络（如IPTV）中，“加入多播流”是一个网络协议过程（如IGMP加入），其速度受网络路由、响应时间等因素影响，可被视为一种网络连接层面的状态或性能体现，并非物理损坏，但可理解为广义的“连接降级”或“连接未就绪”导致的性能下降。 | 目标专利的“网络连接降级”是导致媒体接收间隙的原因之一。对比文件中间隙的主要原因是“加入多播流的时间”，这本质上是网络连接建立或切换过程中的延迟，属于网络连接性能未达到即时传输要求的状态。本领域技术人员可以理解，这种由网络协议交互、路由等引起的延迟属于网络连接层面的问题，可宽泛地归类为“连接降级”的一种表现形式。因此，该特征被隐含公开。 |
| **技术特征N**：其特征在于，所述网络连接降级发生在服务网络与接收方设备之间的连接上和/或回程连接上。《未公开》 | 对比文件未具体区分导致加入延迟的网络问题究竟是发生在服务网络与客户端设备之间的“最后一公里”连接上，还是在核心网络的“回程连接”上。其描述更侧重于加入多播流这一协议过程本身固有的延迟。 | 对比文件虽然提到延迟源于“加入多播流所需的时间”，但并未进一步阐明此延迟具体发生在网络拓扑的哪个部分（如接入网或回程网）。目标专利特征N对网络连接降级发生的位置进行了限定，而对比文件没有公开这一具体限定。因此，该特征未被对比文件公开。 |
| **技术特征O**：其特征在于，进一步包括：执行关于所述倒回流的追赶协议，以使得所述倒回流将追赶上所述实时媒体流。《直接公开》 | 对比文件说明书[0004]段：“The streaming server calculates the end point of the catch up stream and continues to send the catch up stream at a rate faster than real time.” <br> [0017]段：“The client device uses the unicast catch up stream until it catches up with the multicast stream...” <br> “catch up stream”的名称和“faster than real time”的发送速率都明确体现了“追赶”协议。 | 目标专利的“追赶协议”指使倒回流追上实时媒体流的机制。对比文件的核心发明点就是通过发送速率快于实时（“at a rate faster than real time”）的“追赶流”（catch up stream），使客户端设备能够快速追上实时多播流。这直接且明确地公开了执行追赶协议以使时间延迟版本追上实时流的技术特征。 |
| **技术特征P**：其特征在于，所述实时通信会话是半双工会话并且所述接收方设备是在所述倒回流被接收的同时作为非发言权持有者参与所述实时通信会话的目标用户装备(UE)，所述方法进一步包括：在所述接收方设备正接收所述倒回流的同时请求所述实时通信会话的发言权《未公开》 | 对比文件涉及的是电视节目内容的分发，是单向的广播/多播场景，不存在“半双工会话”、“发言权持有者”等概念。客户端设备是被动接收内容的观看者，不具备在会话中请求“发言权”（即发送媒体）的功能或场景。 | 目标专利特征P、Q、R、S涉及的是半双工通信（如对讲）场景下，处于倒回模式的用户如何请求并获得发言权的特定流程。对比文件完全针对单向媒体流分发（如IPTV），没有描述任何双向通信、发言权控制或发言权请求机制。因此，这些特征（P, Q, R, S）未被对比文件公开。 |
| **技术特征Q**：响应于所述发言权请求而接收发言权被准予给所述接收方设备的指示《未公开》 | 同上。对比文件不存在发言权请求与准予的机制。 | 同上。该特征未被对比文件公开。 |
| **技术特征R**：在所述指示被接收到之后继续接收和播放所述倒回流直至(i)所述倒回流追赶上所述发言权被准予给所述接收方设备的时间，和/或(ii)所述接收方设备确定要退出倒回模式《未公开》 | 同上。对比文件不存在发言权准予指示，其追赶流播放直至追上实时流为止，决策逻辑不同。 | 同上。该特征未被对比文件公开。 |
| **技术特征S**：在(i)或(ii)之后作为发言权持有者开始传送用于所述实时通信会话的媒体。《未公开》 | 同上。对比文件中的客户端设备不向服务器发送媒体流。 | 同上。该特征未被对比文件公开。 |
| **技术特征T**：其特征在于，进一步包括：监视与所述实时媒体流和/或所述倒回流相关联的一个或多个性能度量《未公开》 | 对比文件未描述客户端设备或服务器监视媒体流性能度量（如分组差错率、延迟抖动等）的过程。 | 目标专利特征T、U、V涉及对媒体流性能度量的监视和报告。对比文件全文聚焦于通过追赶流机制减少频道切换延迟，并未提及任何对流性能进行主动监视、评估或报告的技术手段。因此，这些特征未被对比文件公开。 |
| **技术特征U**：向所述实时媒体流和/或所述倒回流的始发者报告所述一个或多个性能度量。《未公开》 | 同上。对比文件未描述向流服务器报告性能度量的过程。 | 同上。该特征未被对比文件公开。 |
| **技术特征V**：其特征在于，所述一个或多个性能度量包括所述实时媒体流和/或所述倒回流的分组差错率(PER)。《未公开》 | 同上。对比文件未提及分组差错率(PER)或类似性能度量。 | 同上。该特征未被对比文件公开。 |
<<<A>>><<<C>>><<<D>>><<<I>>><<<K>>><<<O>>>
<<<b>>><<<e>>><<<g>>><<<h>>><<<j>>><<<l>>><<<m>>>