对比文件名称：2009-03-04_KR1020090023120A_发明公开_KR1020090023120A 서버 장치, 네트워크 시스템, 콘텐츠 발견 통지 방법 및 컴퓨터·프로그램
目标专利名称：1117用于内容下载和内容上载的策略CN102652421B
本次调用的模型名称：无（根据系统设置，不返回模型名称）
以下是根据您的要求，对对比文件是否公开目标专利权利要求各技术特征的深度分析及特征比对表格。
### 特征比对表格
| 技术特征描述及公开性判断 | 对比文件原文引用 | 公开性论述 |
| **技术特征A：所述方法包括：-生成包括内容下载或内容上载的类型的指示的请求** <br><br> **《隐含公开》** | **对比文件段落【0099】-【0100】** <br> 【0099】首先，IPTV客户端终端10的EPG应用程序14内的用户交互处理部16，通过用户接口11接受来自用户1的内容搜索通知的开始请求。……用户交互处理部16生成SIP SUBSCRIBE请求的body部分中存储的XQuery查询。……之后，用户交互处理部16向事件包处理部17请求事件通知预约。事件包处理部17通过网络接口12，将用于事件通知预约的SIP SUBSCRIBE请求发送给元数据服务器30。<br><br> **对比文件段落【0133】** <br> 图14是SIP NOTIFY消息的body部分中存储的元数据文档的例子。……为了获取ProgramInformation元素中描述的内容，……获取描述了内容地址URL的OnDemandProgram元素。 | 目标专利的技术特征A旨在“生成包括内容下载或内容上载的类型的指示的请求”。对比文件主要描述了使用SIP SUBSCRIBE请求来预约内容发现通知，该请求的核心是包含一个用于搜索元数据的查询条件，以发现用户感兴趣的内容。虽然对比文件没有明确使用“下载类型”或“上载类型”的属性，但该请求的生成是为了发现并随后获取或消费内容。从逻辑上推理，用户发出搜索请求的根本目的是为了找到并下载或观看内容。对比文件中，当发现匹配内容后，客户端会进行“内容的获取·再生”（段落【0071】），这隐含了内容下载或接收的行为。因此，生成一个用于发现并获取内容的请求，实质上隐含了生成一个与内容获取（下载或上载）相关的请求。该请求的核心目的与目标专利中为设置下载/上载策略而生成请求的目的在逻辑上具有高度关联性，本领域技术人员可以合理推断，该对比文件中的请求生成步骤是内容下载/上载流程的初始环节，因此隐含公开了技术特征A。 |
| **技术特征B：其中由传递类型属性来指示内容下载或内容上载的所述类型；并且其中所述传递类型属性具有值渐进式、流传送或自适应之一** <br><br> **未公开** | **对比文件全文** <br> 对比文件全文未提及“传递类型属性”（transfer-type attribute），也未提及“渐进式”（progressive）、“流传送”（streaming）或“自适应”（adaptive）这些具体的传递类型值。 | 目标专利的技术特征B明确限定了指示内容下载/上载类型的具体方式，即通过一个具有特定枚举值（渐进式、流传送、自适应）的“传递类型属性”来实现。该特征定义了请求中包含的具体参数和参数值，是实现带宽差异化预留的核心。对比文件中的SIP SUBSCRIBE请求包含的是元数据搜索条件（XQuery查询），用于描述用户感兴趣的内容特征（如标题、演员）。这完全不同于目标专利中用于指示传输方式（如何下载/上载）的传递类型属性。对比文件没有公开任何与“传递类型”、“渐进式”、“流传送”或“自适应”相关的概念、属性或值，也没有公开任何用于区分不同传输方式（如流传送 vs. 渐进式下载）的指示机制。因此，该技术特征未被对比文件直接或隐含公开。 |
| **技术特征C：-将所述请求传送到IPTV控制节点（4）。** <br><br> **《隐含公开》** | **对比文件段落【0099】-【0100】** <br> 【0099】……事件包处理部17通过网络接口12，将用于事件通知预约的SIP SUBSCRIBE请求发送给元数据服务器30。<br><br> **对比文件段落【0084】** <br> 元数据服务器30具备网络接口31、事件包处理部32、元数据查询处理部33及元数据数据库34。<br><br> **对比文件段落【0002】** <br> IPTV的会话控制的标准化候选是IMS。 | 目标专利的技术特征C是将请求传送到“IPTV控制节点”。对比文件中，请求被明确传送到“元数据服务器30”。虽然名称不同，但对比文件中的元数据服务器在功能上扮演了IPTV系统中的关键控制角色。它负责接收用户请求（SUBSCRIBE），处理请求，管理内容元数据，并触发后续的内容获取流程。在对比文件段落【0071】中，客户端根据元数据服务器的通知与“IPTV服务器20”建立会话以获取内容。因此，元数据服务器30作为内容发现和后续会话建立的触发点，实质上承担了部分IPTV控制节点的功能，即协调内容发现与获取。本领域技术人员可以合理推理，该元数据服务器是IPTV控制架构中的一个节点，负责处理与内容下载/上载相关的控制信令。因此，将请求传送到该节点隐含公开了传送到IPTV控制节点的技术特征。 |
| **技术特征D：其中所述策略是带宽预留。** <br><br> **未公开** | **对比文件全文** <br> 对比文件全文未提及“带宽预留”（bandwidth reservation）、“策略设置”（policy setting）或任何与网络资源分配相关的概念。其核心在于通过SIP NOTIFY进行内容元数据的发现和通知。 | 目标专利的技术特征D明确了所设置策略的具体内容是“带宽预留”。这是实现下载/上载服务质量（QoS）保障的关键。对比文件的整个技术方案围绕“内容发现通知”展开，旨在减少客户端获取元数据的成本，让服务器在发现匹配用户偏好的新内容时主动通知客户端。对比文件完全没有涉及如何为内容下载或上载预留网络带宽，没有提及QoS保障，也没有任何与资源预留相关的信令（如RACS交互）。其解决的问题和实现的效果与带宽预留完全无关。因此，该技术特征未被对比文件直接或隐含公开。 |
| **技术特征E：其中所述IPTV是基于IMS的** <br><br> **《直接公开》** | **对比文件段落【0002】** <br> IPTV（Internet Protocol Television）是利用IP分发数字TV广播的服务或该广播技术的总称。IPTV的会话控制的标准化候选是IMS（IP Multimedia Sub-system）。ETSI和ITU-T中NGN（Next Generation Network）的标准化以IMS为前提。<br><br> **对比文件段落【0003】** <br> IMS是利用分组通信的移动电话的多媒体服务或实现该服务的标准。IMS中，利用称为SIP（Session Initiation Protocol）的IP电话方式，可安全且保证QoS地控制多媒体会话。 | 目标专利的技术特征E限定了IPTV所基于的网络架构是IMS。对比文件的说明书开篇即明确指出“IPTV的会话控制的标准化候选是IMS”，并且详细描述了IMS是基于SIP协议、能提供QoS保障的架构。虽然对比文件的主要创新点在于使用SIP SUBSCRIBE/NOTIFY进行内容发现，但其整个信令交互是建立在IMS架构的认识基础上的，并且其具体实现（如SIP消息的使用）完全符合IMS的框架。本领域技术人员能够毫无疑义地确定，该对比文件所描述的IPTV系统及其方法是在IMS的背景下实现的。因此，该技术特征被对比文件直接公开。 |
| **技术特征F：其中所述传递类型属性被包含在所述请求中包括的SDP提议中。** <br><br> **未公开** | **对比文件全文** <br> 对比文件全文未提及“SDP提议”（SDP Offer）或会话描述协议（SDP）。其信令消息是SIP SUBSCRIBE和NOTIFY，消息体（body part）用于携带元数据查询或元数据本身，而非SDP。 | 目标专利的技术特征F限定了传递类型属性的具体承载方式，即包含在请求中的SDP提议里。SDP是用于描述多媒体会话的参数。对比文件中，客户端发送的请求是SIP SUBSCRIBE，其消息体包含的是XML格式的查询条件（XQuery），用于描述元数据搜索条件。这与SDP提议用于描述媒体流参数（如编码格式、端口、传输协议）的功能完全不同。对比文件没有任何关于SDP提议或使用SDP来指示传输类型的内容。因此，该技术特征未被对比文件直接或隐含公开。 |
| **技术特征G：其中所述SDP提议还包括建议的带宽。** <br><br> **未公开** | **对比文件全文** <br> 对比文件全文未提及“SDP提议”以及其中的“建议的带宽”（suggested bandwidth）属性。 | 目标专利的技术特征G是对技术特征F的进一步限定，即SDP提议中除了传递类型，还包含建议的带宽。由于对比文件完全没有公开技术特征F（使用SDP提议承载传递类型），自然也完全没有公开在SDP提议中包含建议的带宽。对比文件中虽然可能涉及内容的分发，但没有任何关于在会话建立信令中建议带宽的概念。因此，该技术特征未被对比文件直接或隐含公开。 |
| **技术特征H：还包括如果传输类型属性要求的带宽不可用，则所述用户设备接收对所述请求的拒绝。** <br><br> **未公开** | **对比文件全文** <br> 对比文件全文未提及“带宽不可用”、“请求拒绝”以及带宽相关的策略执行。其信令流程中，服务器对SUBSCRIBE请求的响应是200 OK（接受预约），或者可能因鉴权等原因拒绝，但并非基于带宽检查。 | 目标专利的技术特征H描述了在特定失败场景下的处理：当要求的带宽不可用时，请求被拒绝。这依赖于网络具备带宽检查和准入控制机制（如RACS）。对比文件的核心是内容发现，不涉及带宽预留或准入控制。其流程中，服务器接受SUBSCRIBE请求并建立对话，没有基于网络资源可用性的拒绝机制。因此，该技术特征未被对比文件直接或隐含公开。 |
| **技术特征I：包括如果接收到拒绝，则生成包含不同传输类型属性的请求。** <br><br> **未公开** | **对比文件全文** <br> 对比文件全文未提及“接收拒绝”以及“生成包含不同传输类型属性的请求”这一重试机制。 | 目标专利的技术特征I是对技术特征H的后续处理，即在请求被拒绝后，用户设备通过改变传输类型属性进行重试。由于对比文件没有公开技术特征H（基于带宽的拒绝），自然也完全没有公开在此基础上的重试机制。对比文件中，如果SUBSCRIBE请求被拒绝（例如订阅到期），通常会结束对话，而非通过修改查询条件重试。因此，该技术特征未被对比文件直接或隐含公开。 |
<<<E>>>
<<<a>>>
<<<c>>>