好的，我会遵循资深专利代理师的角色，严谨、细致地评估对比文件对于目标专利权利要求的各技术特征的公开情况。
**对比文件名称：** 2008-06-26_US2008152316A_发明申请_US20080152316A1 REMOTE CONTROL OF MEDIA CONTENT DELIVERY TO A DIGITAL MEDIA RECORDER
**目标专利名称：** 1117用于内容下载和内容上载的策略CN102652421B
**本次调用的模型名称：** （根据您的上下文，此处为模型名称，我无法获知具体名称，但已按指令执行分析。）
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A：** 所述方法包括：-生成包括内容下载或内容上载的类型的指示的请求<br><br>**《隐含公开》** | 对比文件说明书第[0027]-[0029]段描述了下载流程：“Initially, the browser application 30 of the computing terminal 28 may logon to the remote download application of the DMR 12... (步骤100)”。在[0029]段：“Once the remote control mode is configured, the browser application 30 may request the video web site home page of the media content server (step 110)”。[0030]段：“Assume that media content was selected, and the selected media content corresponds to VIDEO 1. At this point, the media content server may start transferring or streaming a video file for VIDEO 1 to the DMR 12 over the Internet 20 (step 116)”。 | 对比文件公开了用户通过计算终端（28）上的浏览器应用（30）生成请求，以选择并下载媒体内容（如VIDEO 1）到数字媒体记录器（DMR 12）。该请求隐含地包含了“内容下载”的类型，因为整个过程的目的是将内容从服务器传送并存储到本地设备。然而，对比文件通篇仅涉及媒体内容的**下载**，完全没有提及或暗示任何关于用户设备向服务器**上载**媒体内容的技术内容、场景或需求。因此，对比文件仅部分公开了技术特征A中关于“内容下载”的指示，对于“内容上载”的类型指示则完全未公开。根据隐含公开判断标准的宽松要求，本领域技术人员可以合理推断出存在类似的生成下载请求的步骤，但对于上载部分，对比文件未提供任何技术启示。因此，判断为技术特征A被部分公开，属于隐含公开。 |
| **技术特征B：** 其中由传递类型属性来指示内容下载或内容上载的所述类型；并且中所述传递类型属性具有值渐进式、流传送或自适应之一<br><br>**《未公开》** | 对比文件全文未出现“传递类型属性”(transfer-type attribute)、“渐进式”(progressive)、“流传送”(streaming)或“自适应”(adaptive)等相关术语或概念。 | 对比文件描述了媒体内容的“transferring or streaming”（传输或流传送）（[0030]段），但这描述的是一种普通的传输动作，而非用于在信令中指示内容传送方式的特定“属性”。对比文件完全没有公开任何类似于目标专利中的“传递类型属性”的技术概念，也未公开该属性的具体值（渐进式、流传送或自适应），更未提及利用该属性来区分不同下载或上载类型。因此，对比文件完全未公开技术特征B。 |
| **技术特征C：** -将所述请求传送到IPTV控制节点（4）。<br><br>**《未公开》** | 对比文件说明书第[0024]段描述了通信路径：“...the computing terminal 28 will communicate with the media access server 32 or a media content server 24 through the DMR 12...” 以及[0039]段：“...the media access server 32 is used as a liaison between the computing terminal 28 and the media content servers 24。” 请求被传送至媒体内容服务器（24）或媒体接入服务器（32），或通过DMR（12）传递。 | 对比文件中的请求是发送给**媒体内容服务器（24）** 或**媒体接入服务器（32）**。尽管DMR（12）和媒体接入服务器（32）具备控制功能，但对比文件并未将其定义为 **“IPTV控制节点”** ，也未描述其具备目标专利中IPTV控制节点（4）所执行的策略设置功能（如与RACS交互进行带宽预留）。请求的接收方在功能和定义上均与目标专利的“IPTV控制节点”不同。因此，对比文件未公开技术特征C。 |
| **技术特征D：** 其中所述策略是带宽预留。<br><br>**《未公开》** | 对比文件全文未提及带宽预留、服务质量（QoS）保障或任何形式的资源预留策略。 | 目标专利的核心是通过在请求中指示内容类型来触发策略设置，特别是带宽预留，以确保传送质量。对比文件描述了内容的下载过程，但完全未涉及任何关于网络资源（如带宽）的预留或QoS保证机制。其下载过程是典型的“尽力而为”传送，没有策略设置或资源预留的步骤。因此，对比文件未公开技术特征D。 |
| **技术特征E：** 其中所述IPTV是基于IMS的<br><br>**《未公开》** | 对比文件说明书第[0021]段提及：“...configured to receive television services through an over-the-air, cable, satellite, **IPTV**, or like television network 14。” | 对比文件仅列举“IPTV”作为DMR（12）可以连接的电视网络类型之一，但并未对其体系结构进行任何限定，更没有提到其是基于IMS（IP多媒体子系统）的。整个对比文件描述的内容分发和远程控制方案，均基于标准的互联网协议（HTTP等）和不同的服务器角色，与IMS/RACS等复杂的电信级控制架构无关。因此，对比文件未公开技术特征E。 |
| **技术特征F：** 所述传递类型属性被包含在所述请求中包括的SDP提议中。<br><br>**《未公开》** | 对比文件全文未出现“SDP”（会话描述协议）、“SDP提议”（SDP Offer）等术语。 | 由于对比文件未公开技术特征B（传递类型属性），自然也完全未公开其被包含在SDP提议中的具体方式。对比文件中的请求（如HTTP请求）并未使用SDP协议来携带会话描述或属性。因此，对比文件未公开技术特征F。 |
| **技术特征G：** 其中所述SDP提议还包括建议的带宽。<br><br>**《未公开》** | 对比文件全文未出现“SDP提议”术语，也未描述在请求中包含“建议的带宽”。 | 基于对技术特征D、E、F的论述，对比文件既无带宽预留策略，也无IMS架构，更无SDP协议交互，因此完全不可能公开在SDP提议中包含建议带宽的技术方案。因此，对比文件未公开技术特征G。 |
| **技术特征H：** 还包括如果传输类型属性要求的带宽不可用，则所述用户设备接收对所述请求的拒绝。<br><br>**《未公开》** | 对比文件全文未描述对下载请求的拒绝机制，特别是基于带宽不可用的拒绝。 | 对比文件未公开技术特征D（带宽预留）和技术特征B（传递类型属性），因此缺乏判断带宽是否可用以及请求是否被拒绝的基础。对比文件中的下载过程假设内容可以正常传输，未涉及请求失败或拒绝的场景。因此，对比文件未公开技术特征H。 |
| **技术特征I：** 包括如果接收到拒绝，则生成包含不同传输类型属性的请求。<br><br>**《未公开》** | 对比文件全文未描述请求被拒绝后的重试或调整机制。 | 基于对技术特征H的论述，对比文件未公开请求被拒绝的场景，因此更不可能公开在接收到拒绝后生成包含不同传输类型属性的新请求这一后续步骤。因此，对比文件未公开技术特征I。 |
### 综合结论
经过严谨比对，对比文件 **US20080152316A1** 仅隐含公开了目标专利权利要求中的技术特征A（部分，关于内容下载）。该对比文件未公开技术特征B至I中的任何一个特征，无论是直接公开还是隐含公开。
<<<a>>>