一种管理连接到至少一个网络(1380)的多个资源节点(1330)的资源管理节点(1300)，包括：系统实体数据库(1304)，包含对所述至少一个网络(1380)上的所述资源节点(1330)的通信地址和相关联元数据进行标识的信息，所述相关联元数据标识所述资源节点(1330)的能力；交互流数据库(1308)，包含对经由所述至少一个网络(1380)在所述资源节点(1330)中所标识的资源节点之间通信允许的数据流以及相关联触发准则进行定义的信息，所述相关联触发准则定义何时要执行所述数据流中所标识的数据流；交互执行引擎(1312)，被配置为确定满足所述交互流数据库(1308)所定义的所述相关联触发准则之一，并通过经由所述至少一个网络(1380)在所述资源节点(1330)中所标识的资源节点之间建立相关联的数据流来进行响应；以及推荐引擎(1310)，所述推荐引擎(1310)被配置为：从所述系统实体数据库(1304)中的元数据生成所述资源节点(1330)中的至少两个资源节点之间的推荐数据流；向用户设备节点(1320)传递标识所述推荐数据流的消息，以由所述用户设备节点(1320)的用户接受；以及通过向所述交互流数据库(1308)添加信息，对接收到指示接受所述推荐数据流的用户设备节点(1320)响应进行响应，所述信息对至少两个资源节点(1330)之间的所述推荐数据流以及被所述交互执行引擎(1312)用来建立所述推荐数据流的相关联触发准则进行标识。

作为一名经验丰富的专利代理师，我将为您对目标专利（CN103975345B）的权利要求1进行深度解析，并结合两份对比文件（D1: JP2005346190A，D2: JP2002092194A）的原文进行严谨的特征比对、创造性评判及无效请求薄弱点分析。

---

## 一、 目标专利权利要求1的合理解释与技术架构

目标专利的核心在于利用**社交网络中的社交映射原则（如好友、所有权等信任关系）**来直观地管理联网资源节点之间的数据流。

### 权利要求1的系统架构逻辑

1. **系统实体数据库(1304)**：负责解决“网络里有什么、它们能干什么（能力元数据）”的基础认知问题。

2. **交互流数据库(1308)**：负责解决“谁和谁被允许通电/通信、在什么条件下（触发准则）发起”的规则定义问题。

3. **交互执行引擎(1312)**：负责解决“自动监测并执行”的动态控制问题。

4. **推荐引擎(1310)**：负责解决“基于现有能力主动生成新交互流、推给用户确认、确认后反向丰富规则库”的智能化闭环问题。

---

## 二、 特征比对分析与详尽出处

以下基于两份对比文件的原文（包含日文原件及对应的中文释义内涵），对权利要求1的各个技术特征（A至F）进行无异议公开或实质公开的逐项比对。

### 1. 特征比对总表

---

## 三、 最接近对比文件（D1 vs D2）的定性分析

在创造性分析（三步法）中，选择最接近的对比文件通常从**技术领域是否相同、解决的技术问题是否最接近、以及公开权利要求特征的数量**三个维度考量。

### D1 (JP2005346190A) 分析

* **技术领域**：家用电器信息通信及远程控制系统。

* **解决的技术问题**：解决新家电接入家庭网络时，如何避免频繁重构或手动更新Home Server应用的问题（通过ASP服务器提供差分更新及校验）。

* **评述**：D1侧重于**软件架构的升级与维护（Patch/差分下载）**，其本质是个软件版本控制和设备发现系统。它对于目标专利中“根据用户习惯/节点能力进行跨设备数据流的动态规则建立”这一核心技术问题，契合度较低。

### D2 (JP2002092194A) 分析

* **技术领域**：控制信息管理系统、控制对象远程预约及网络联动控制。

* **解决的技术问题**：解决传统的远程操作因外界因素变化（如电视节目延时、天气变化）导致预设的控制条件失效、用户无法得到满意控制效果的问题。

* **评述**：D2构建了一个完善的**“数据/规则中心——集中条件判定——下发执行机制”**。它不仅公开了“条件（触发准则）”与“控制内容（数据流）”的解耦，还明确提出了**“根据用户的嗜好或历史信息，向用户提供控制内容的提案（推荐），并在用户确认后将其写入数据库中作为新的控制规则”**（第[0059]段）。

### 结论：谁适合做最接近的对比文件？

> **D2 (JP2002092194A) 明显更适合作为最接近的对比文件。**

>

> * **理由**：目标专利整体解决的技术问题是“如何在复杂的联网设备中，直观、动态地生成和管理交叉响应的数据流规则”。D2同样立足于“如何通过收集判定信息/变更信息，动态、智能化地修改和建立控制设备之控制规则”的问题。

> * **特征覆盖度**：D2几乎完全公开了特征A、B、C，并实质公开了特征D、E、F的交互逻辑。

---

## 四、 创造性评述与未公开特征的组合

若以 **D2 为最接近的对比文件**，其没有完全毫无异议公开、需要进行组合和抗辩的微弱差异特征在于：

1. **特征A中的“社交网络/元数据标识能力”**：D2公开了根据IP/设备地址管理空调、录画机，但没有明确提出利用“社交映射原则（如好友、所有权）”来对资源节点的能力进行管理。

2. **特征D、F中推荐引擎的具体上下游闭环**：目标专利限定从“系统实体数据库的元数据”生成推荐数据流。而D2在第[0059]段中提出的是“根据过去的历史预约信息分析用户嗜好从而推荐”。

### 那么，这些特征是否被D1或其他公知常识公开？

* **D1的贡献**：D1公开了设备接入时自动上传“制造公司名、产品名、型式、ID”（特征A中的能力元数据），并由ASP服务器根据这一元数据从“模块管理信息列表（图7）”中匹配对应的监视控制应用（特征D的雏形：根据设备能力元数据匹配允许的交互流）。

* **社交网络常识**：在2013-2018年间（目标专利申请日前），将社交网络（Social Web / 好友请求关系）引入到物联网（IoT）中，即构建“社交物联网（Social Web of Things, SWoT）”，已经是本领域的公知常识或常用技术手段。

因此，审查员极易使用 **D2 + D1 + 本领域公知常识** 构筑创造性组合：

* 由D2提供整体推荐、用户接受后写入规则库、由引擎动态执行的核心架构（特征B、C、E、F）；

* 由D1提供根据设备能力元数据进行交互模块匹配的手段（特征A、D）；

* 将传统控制设备之间的“主从/绑定”关系转化为“好友/信任”关系属于典型的社交网络概念向物联网的常规移植。

---

## 五、 无效请求方最薄弱的技术特征（即专利权人的护城河）

如果您代表**无效请求方**（试图无效掉该专利），以下特征是您整个证据链条中**最薄弱、也是最难攻克**的防线：

### 特征D与特征F的特定动态闭环：

> “推荐引擎被配置为：**从所述系统实体数据库中的元数据生成**所述资源节点中的至少两个资源节点之间的推荐数据流……通过向所述交互流数据库**添加信息**，对接收到指示接受……响应进行响应，所述信息对……**推荐数据流以及相关联触发准则进行标识**。”

#### 为什么此特征最薄弱（对请求方而言最难攻克）？

1. **D2的局限性**：D2虽然在第[0059]段提到了“推荐（提案）”，但其推荐的依据是**“过去的预约信息（历史行为数据）”**。而本专利的权利要求1严格限定了推荐的源头是**“系统实体数据库中的元数据（即设备本身固有的能力）”**。

2. **技术效果的差异（专利权人的反驳点）**：

* **D2的模式**：用户以前用过A和B联动，系统以后继续推荐A和B联动。如果用户从未联动过C和D，系统便无法基于历史行为推荐。

* **本专利的模式**：即使新接入的C设备和D设备从未有过交互历史，只要“推荐引擎”发现C的元数据标识其具有“输出实时电价能力”，D的元数据标识其具有“延迟洗衣能力”，推荐引擎就能**凭空（仅基于能力元数据）创造出一个全新的联动推荐流**（如说明书洗衣机与电力公司的联动示例）。

3. **对请求方的警示**：在无效宣告程序中，专利权人极有可能会紧紧抓住**“基于静态能力元数据动态生成全新触发规则流”**这一智能联动闭环，抗辩D2的“历史嗜好推荐”属于完全不同的技术构思，且未产生“克服不兼容设备盲区、直观生成未知规则流”的技术效果。

### 无效策略建议

请求方必须在后续的补证或口审辩论中，极力将特征D中的“从元数据生成”解释为“从设备型号、设备类型列表中读取既有预设流”（利用D1图7的Module管理列表进行贴靠），将“生成”解释为“匹配选取”，淡化其“AI/引擎自主创造规则”的色彩，方可削弱这一特征的创造性高度。

作为一名经验丰富的专利代理师，我将为您对权利要求1进行深度的法律与技术解析，紧密结合目标专利说明书（CN103975345B）的立法本意与技术构思，并逐一比对四份对比文件（D1: US2011161478A / D2: WO2011080549A，以及D3: JP2002335586A，D4: JP2005109746A），进行无异议公开与实质公开特征的精准法律定性，最终为您指出无效宣告请求方最薄弱的技术特征及应对策略。

---

## 一、 目标专利说明书对权利要求的原意解释

权利要求1的核心在于构建了一个**基于社交物联网（Social Web of Things）架构的资源管理节点（1300）**。其本质是通过“社交映射原则”（如好友关系、信任机制）来管理物理网络中的硬设备、传感器或虚拟服务。

根据目标说明书第 `[0007]`-`[0009]`、`[0037]`-`[0046]`、`[0110]`-`[0124]` 段的记载，各技术特征的架构本意解释如下：

* **技术特征A（系统实体数据库 1304）：**

* **本意解释：** 它不仅仅是传统的网络拓扑结构数据库。说明书指出，该数据库为每个物理对象或用户创建“系统实体简档（20）”。其关键在于不仅标识“通信地址”，还必须包含**“标识资源节点能力的相关联元数据”**（如设备的技术规范、功能能力、数据输入/输出格式等）。

* **技术特征B（交互流数据库 1308）与特征C（交互执行引擎 1312）：**

* **本意解释：** 这两者构成了本专利的**执行层**。交互流数据库定义了“允许的数据流”和“相关联触发准则”。引擎在触发准则满足时（如电价降到阈值、开启时间过长等），在节点间建立**相关联的数据流（如串行菊花链架构）**。

* **技术特征D、E、F（推荐引擎 1310 的动态循环闭环）：**

* **本意解释：** 这是本专利区别于传统静态配置网络最核心的**智能控制闭环**。

* 推荐引擎不是由用户手动编排，而是**“从系统实体数据库中的元数据”动态生成**推荐数据流（特征D）；

* 通过消息（例如友好关系请求）传递给用户接受（特征E）；

* **最核心的动态反哺：** 一旦用户接受，推荐引擎做出响应，**“通过向交互流数据库添加信息”**（特征F）来更新网络允许的通信边界，使被用来建立推荐流的“触发准则”沉淀到执行层。说明书图17-18以“电力公司接口、闹钟与洗衣机”的联动进行了极具针对性的体系化说明。

---

## 二、 对比文件特征比对表

根据权利要求1的分拆，我们将四份对比文件与之进行全案特征比对：

---

## 三、 对比文件原文详细出处及公开性分析

### 1. 对比文件D1（公开号：US20110161478A1）

* **同族说明：** **D1与D2为高度关联的同族专利。** D1是美国发明申请，D2是世界知识产权组织国际申请（WO2011080549A1）。二者的技术实质完全一致，附图、图号及逻辑架构相同。以下一并给出D1/D2的详细出处分析。

* **毫无异议公开的特征：**

* **主题名称及特征A：** D1在 `[0036]`-`[0038]` 段公开了：*“A plurality of networked objects 10 is connected to the system 12... Both the profiles that represent users 16 and network objects 10 in the system 12 are jointly referred to herein as system entity profiles 20.”*；在 `[0060]`-`[0061]` 段明确公开了 *“1. A device capability database... 3. A database or list indicating which devices and user-provided services are available...”*。这与特征A中的系统实体数据库、通信地址、能力元数据完全对应，属于**毫无异议地公开**。

* **实质公开的特征：**

* **特征E：** D1在 `[0070]` 段公开了社交物联网的交互：*“Alice is guided to the notification tab under the home page, and sees that she receives a notification 212 saying 'Do you want to send a friend request to Bob's NAS?'”*。其将设备之间请求建立关系作为消息传递给用户接受，在法律实质上，其社交关系请求对应并**实质公开**了特征E中“向用户设备节点传递消息以由用户接受”的手段。

* **未公开的特征（技术断层）：**

* D1的整体逻辑是“任务中继/转包”。如 `[0042]`-`[0043]` 段所述，TV自己不能录像，它将任务“转包（subcontracted）”给具有录像能力的视频记录器。这属于**应用层任务分配**，D1**完全没有公开**特征B和C中所述的“定义允许的数据流和触发准则的交互流数据库”，更没有公开推荐引擎通过“从元数据生成数据流”（特征D）并“向交互流数据库动态添加信息”（特征F）的底层数据重构闭合回路。

### 2. 对比文件D3（公开号：JP2002335586A）

* **实质公开的特征：**

* **特征A：** D3在说明书 `[0026]`、`[0032]`-`[0034]` 段公开了“主处理部14”、“ユーザテーブル18（用户表18）”及“コマンド変換テーブル20（命令转换表20）”。用户表18记录了用户ID、厂家名、通信手段、家用服务器地址；命令转换表20则存储了各种厂家的控制信号格式（F1-F4）。这通过静态映射实现了对不同厂家设备能力的管理，**实质公开**了特征A。

* **特征B及特征C：** D3在 `[0058]`-`[0060]` 段公开了其第1和第2变型例：*“家電製品32又は環境の状態を示す値が、その設定値となった場合に携帯電話機24へその状態情報信号を送信する（例如设定室温0℃以下为条件进行通知）...自動的に家電制御システム10からホームサーバ34へ遠隔制御信号が送信される（条件满足时自动发控制信号）”*。预设的条件（如0℃）和对应的控制转换输出，**实质公开**了特征B的“触发准则”以及特征C“执行引擎确定满足触发准则并建立控制响应”的逻辑。

* **未公开的特征：**

* D3完全是**基于用户静态预设条件或既定代码**进行的条件触发控制，**完全不具备“推荐引擎”**。它无法做到“从元数据自动生成推荐流（特征D）”，也没有“向用户发送推荐流由其接受（特征E）”，更没有“将接受后的新规则动态添加回交互流数据库（特征F）”的智能推荐反哺机制。

### 3. 对比文件D4（公开号：JP2005109746A）

* **实质公开的特征：**

* **特征A：** D4在 `[0033]` 段公开了“家電データベース208（家电数据库）”，记录了各厂家家电的机型、品种、功能信息。

* **特征E：** D4在 `[0067]`-`[0070]` 段以及图22-23公开了服务提供逻辑：*“機器サービス情報データベース（ＤＢ）から家電機器Ａについてのサービス...を表示するＧＵＩサービス選択画面を送信する”*。ASP服务器向操作端末发送包含可选服务（如菜谱、洗衣模式）的GUI画面供用户选择，这与向用户设备发送消息以供接受的特征E在技术手段上等同，属于**实质公开**。

* **未公开的特征：**

* D4的GUI生成机制是静态的“部件拼接”。如 `[0013]` 段所述，它是根据家电机器的识别子（ID），从数据库中抽出对应的“部品群（部件群）”来合成GUI画面。这仅仅是**用户交互界面的动态拼接，根本不是“生成至少两个资源节点之间的推荐数据流（特征D）”**。用户选择后，D4仅仅是把服务数据写入家电控制器（见 `[0068]` 段），**完全没有公开**特征B、C的交互流及执行引擎，也无法反哺并“向交互流数据库添加信息（特征F）”。

---

## 四、 最接近对比文件（D1/D2）的选定与创造性分析

在创造性宣告无效的分析中，**对比文件D1（公开号：US20110161478A1）或D2（公开号：WO2011080549A1）最适合作为最接近的对比文件。**

### 1. 技术问题与技术效果的同质性分析

* **整体解决的技术问题：** 本目标专利旨在解决传统物联网配置 ad-hoc、用户无法直观理解大量联网对象之间复杂关系和交互模型的思维鸿沟（见目标说明书 `[0003]`-`[0005]` 段）。而**D1/D2开篇在【BACKGROUND】第 `[0005]`-`[0006]` 段，以完全相同的文字表述**指出：*“现今的产品是支持特定有限功能的ad-hoc解决方案...没有提供整体而统一的交互...无法直观理解对象的上下文和关系”*。两者面临的原始技术痛点完全一致。

* **技术效果的同质性：** 两者都是通过引入“社交映射原则（如好友关系、信任机制）”，将冷冰冰的机器物理连接转化为用户易于直观思维模型化（Mental Model）的“社交物联网（Social Web of Things）”（见目标说明书 `[0009]` 与 D1第 `[0035]` 段）。

因此，从技术领域、发明目的、基础架构（AS服务器 + 网关 + 社交实体简谱）以及所达到的技术效果来看，D1/D2构成了最天然的、最接近的现有技术。

### 2. 特征结合与创造性评述逻辑

* **最接近现有技术（D1）未公开的特征：** 特征B（交互流数据库）、特征C（交互执行引擎）、特征D（根据元数据自主生成推荐流）、特征F（将推荐流和触发准则反哺写入交互流数据库）。

* **其他对比文件的公开性结合评述：**

* 无效请求方会尝试将 **D1/D2 与 D3（JP2002335586A）进行结合**。

* **理由：** D3在变型1和变型2中，公开了“当环境状态/家电状态满足一定条件（触发准则）时，自动转换并向家庭服务器/节点间发送控制信号和允许的数据流”。

* **请求方的无效逻辑：** 在D1/D2所构建的社交物联网框架下，为了实现设备之间更自动化的协同，本领域技术人员有动机引入D3所公开的“根据环境或设备状态设定触发准则并执行相应控制数据流”的技术手段（特征B、C）。

---

## 五、 请求方最薄弱的技术特征及无效应对策略

如果我们要站在无效请求方的角度，或者作为专利权人进行防御评述，整个无效案件中**请求方最薄弱、最难以攻破的技术特征是：特征D与特征F的有机结合（即推荐引擎的动态自组织闭环）。**

$$\text{特征A + 特征B + 特征C} \xrightarrow{\text{传统静态/条件触发控制}} \text{特征D + 特征F (动态自组织重构闭环)}$$

### 1. 为什么这是最薄弱点？（为什么其他对比文件没有公开？）

* **D3/D4的致命缺陷：** 请求方即使结合了D1和D3，也只能拼凑出：“在社交物联网中，设备间可以根据静态预设的条件（如温度、能耗阈值）触发既定的控制”。

* **特征D+F的创造性高度：** 目标专利的“推荐引擎”具有本质的动态进化特征。它是**从系统实体数据库中的元数据（设备能力变化、新发现设备）中自主计算并派生出**至少两个节点之间的“新数据流”（特征D）。最关键的是特征F，一旦用户点击接受，这个系统会将这个推荐数据流及其触发准则**“动态添加”**到交互流数据库中。

* **法律定性：** 这种“动态改写执行层数据库、重构系统未来通信边界”的**反哺机制**，在D1/D2中仅仅是静态的建立“好友关系”；在D3中只是静态地“执行既定代码”；在D4中只是静态地“将功能参数写入设备控制器”。没有任何一份对比文件公开或暗示了“推荐引擎通过修改交互流数据库来实现网络规则自我进化”的技术构思。

### 2. 针对请求方的实务建议（最薄弱点的无效突破口）

如果您作为无效请求方，直接通过对比文件常规的“特征拼凑”来否定特征D+F的创造性是注定要失败的。要在该最薄弱特征上取得突破，必须采取以下迂回攻坚策略：

* **策略一：利用公知常识/通用AI推荐算法进行“技术下沉”评述**

* 不要把“推荐数据流”和“添加信息”死扣在物联网设备上。请求方应提交多篇2011年之前的**通用推荐系统（Recommendation Systems）**或**网络策略动态编排（Policy Orchestration）**的背景技术作为公知常识证据。

* 论证：在线性社交网络或电商系统中，“根据用户/商品属性元数据（特征D），动态推荐好友/商品，并在用户接受后，将该新型关系/权重数据动态添加、改写底层行为关联数据库（特征F）”，属于推荐算法领域的常规操作。本领域技术人员将其移植到物联网的对象管理中，属于“技术领域的正常转用”，不具备突出的实质性特点。

* **策略二：发动说明书“充分公开（专法26条3款）”或“权利要求得不到支持（专法26条4款）”的条款夹击**

* **攻击点：** 细读目标专利说明书会发现，其对于“推荐引擎如何**具体通过元数据计算、自动生成**推荐流”的算法描写极其笼统（仅图17-18做了业务层面的举例）。

* **无效策略：** 请求方在口审中应采取双刃剑策略——如果专利权人主张特征D和F具有极高的、有别于传统拼接的“智能化自组织计算创造性”，则请求方立刻反击其**说明书属于“盲人摸象式”的未充分公开**，普通技术人员根据说明书含糊的记载根本无法实现这种“自动生成并改写底层数据库”的元数据推荐引擎。从而通过26条3款迫使专利权人限缩解释或直接无效。

作为一名经验丰富的专利代理师，我针对目标专利《管理社交网络中的联网资源节点之间的数据流》（授权公告号：CN103975345B）的权利要求1，结合说明书原文以及提交的四份对比文件（D1~D4）进行深入的无效可行性与创造性分析。报告如下：

---

## 一、 目标专利权利要求释明与技术架构

本专利的核心思想是将“社交网络（如好友关系、推荐机制）”的概念引入物联网（IoT）或联网资源节点的数据流管理中。为了清晰比对，首先结合说明书对权利要求1的六个技术特征进行专利法意义上的释明：

* **技术特征A（系统实体数据库）：** 对应说明书图13中的`1304`。它不仅存储IP/MAC等通信地址，关键是存储了**能力元数据**（如设备是电视、空调还是传感器，支持什么格式）。

* **技术特征B（交互流数据库）：** 对应`1308`。其核心是**“允许的数据流”+“触发准则”**。即预先定义好“如果A发生，允许数据从节点X流向节点Y”。

* **技术特征C（交互执行引擎）：** 对应`1312`。属于控制执行层，负责监听触发准则，并在条件满足时自动建立资源节点间的数据连接（菊花链或串行通信）。

* **技术特征D、E、F（推荐引擎及其闭环机制）：** 对应`1310`。这是本专利区别于传统自律控制系统的关键。系统不是直接替用户做主，而是**自发学习/挖掘**（基于元数据）生成一个新的“推荐数据流” $\rightarrow$ 发送给用户设备（`1320`）求许可 $\rightarrow$ 用户点“接受”后，再把这个新规则反向写回交互流数据库（`1308`）中供执行引擎使用。

---

## 二、 对比文件（D1~D4）技术方案概述

在进行特征比对前，先界定各对比文件整体解决的技术问题和技术效果：

* **D1 (JP2002095072A)：** 解决多设备家庭自动化中用户无法自律控制以及配置困难的问题。采用“控制装置+属性表（静的/动的情報）”架构。通过读取静的情報（设备种别、环境）识别能力，结合外部信息（天气、电价）自动更新动的情報（动作条件）实施联动控制。

* **D2 (JP2002354183A) / D3 (JP3507477B2)：** 解决图像通信装置（传真机/PC）在强制代行接收与普通代行接收时，操作员无法区分内存中图像种类的技术问题。属于极其局限的办公外设切换控制，不涉及社交物联网架构。

* **D4 (JP2011114355A)：** 解决家庭网络内多用户对智能家电控电需求不一致、产生冲突的问题。采用“阈值列表+设备设定列表+用户优先度”来实现网络内总能耗上限的动态分配和控制权转移。

---

## 三、 技术特征比对表

根据上述分析，将权利要求1拆解的特征与对比文件原文进行逐项比对：

---

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

根据专利审查指南的“三步法”，选择最接近的对比文件应当优先考虑**技术领域相同或相近、解决的技术问题最类似、公开的技术特征最多**的文献。

### 最接近对比文件：D1 (JP2002095072A)

* **理由分析：**

* **技术领域及解决问题完全一致：** D1和目标专利均属于“家庭网络/物联网内的多设备自动化智能集中控制管理”领域。两者皆旨在解决“如何让网络中大量不同能力、不同空间分布的异构设备，根据外部环境变化（如天气、时间、控制目的）进行自律性联动，以降低用户频繁手动设置的复杂度”这一技术问题。

* **技术效果高度重合：** 两者最终达到的效果都是通过中央控制节点（目标专利的资源管理节点 `1300` / D1的控制装置 `2`）调配网络资源，实现了环境自适应（省电、省钱联动）。

* **特征公开最多：** D1公开了目标专利权利要求1的核心物理架构，即特征A、B、C。D1中的“静的情報”完美对应系统实体数据库中的“通信地址和相关联元数据”；D1中基于外部信息（天气/电价）和联动策略控制协同设备，完美对应了特征B和C的触发与交互数据流执行。

> **结论：** D1在创造性分析中**最适合单独作为“最接近的对比文件”**。D4虽涉及能耗管理，但其本质是多用户优先级在总额度限制下的信号竞合分配，其网络架构和解决的“冲突解决问题”与本申请相距较远，不适合作为第一主体文件，可作为特征C的辅助结合证据。D2/D3为不相干的传真机代行接收技术，在创造性分析中应予以排除。

---

## 五、 无效请求方最薄弱的技术特征分析（最具创造性防线）

如果我是无效请求方（要求推翻该专利的一方），在此案中**最薄弱的突破口、也就是最难打掉的技术特征是：技术特征D、E、F的联结组合（即“推荐引擎的闭环确认机制”）**。

### 原因深度剖析：

1. **现有技术存在明显的“技术盲区”：**

不管是D1还是D4，传统物联网控制的思维模型都是**“自律/被动控制”**——要么是用户预先设定好死规则（如D4），要么是系统后台根据天气默默地去改设备参数（如D1）。没有任何一篇对比文件启示了**“系统通过挖掘元数据自动生成本不存在的异构设备间的新数据流（特征D） $\rightarrow$ 弹出消息以社交网络‘好友申请’类似的机制请求用户确认（特征E） $\rightarrow$ 经用户确认后动态修改数据库规则库（特征F）”**这一技术闭环。

2. **该特征带来了预料不到的技术效果：**

说明书【0004】及【0115】明确指出，由于物联网设备过多，用户根本无法建立庞大的“思维模型”去手动配置复杂的跨设备触发规则。特征D、E、F的组合让系统具备了智能孵化新规则的能力，同时通过“用户设备确认”这一道关卡，既保证了规则的安全可控，又避免了传统完全自律系统在后台频繁误操作导致的用户困扰。这种“社交映射原则（类似于好友申请和接受）”应用在物联网规则生成上，在申请日（2018年）前具有极强的非显而易见性。

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

由于在D1~D4中特征D、E、F完全断档，单纯依靠现有这几份文件以“D1+公知常识”或“D1+D4”组合极难动摇权利要求1的创造性。请求方若想成功无效该特征，**必须在答辩前启动补充检索**：

* **检索方向：** 重点寻找智能家居/智慧物联领域中，涉及“场景自动化推荐”、“基于IFTTT规则的用户交互式确认与规则写入”的早期专利或文献。

* **结合逻辑：** 只有找到一份公开了“系统根据设备能力自动推荐场景，用户点击接受后生效并写入自动化数据库”的证据D5，通过“D1（主方案架构）+ D5（推荐闭环机制）”进行结合，才有可能攻破目标专利这道最坚固的防线。

根据权利要求1所述的资源管理节点(1300)，其中：所述推荐引擎(1310)还被配置为确定哪些资源节点(1330)具有兼容数据格式，并从任何推荐数据流中排除将通信连接但具有不兼容数据格式的两个或更多个资源节点(1330)。

根据权利要求1所述的资源管理节点(1300)，其中，所述推荐引擎(1310)还被配置为：与交互流设计商(1324)通信，以接收在所述资源节点(1330)中的至少两个资源节点之间定义的一个或更多个推荐数据流；向所述用户设备节点(1320)传递接收到的一个或更多个推荐数据流，以用于接受；以及通过向所述交互流数据库(1308)添加信息和相关联触发准则，对指示所述用户设备节点(1320)的用户接受所述推荐数据流中所选择的一个或更多个推荐数据流的一个或更多个消息进行响应，所述信息标识所述推荐数据流中所选择的一个或更多个推荐数据流并建立相关联的数据流，所述相关联触发准则被所述交互执行引擎(1312)用来建立所述推荐数据流中的所述一个或更多个推荐数据流。

根据权利要求1所述的资源管理节点(1300)，其中，所述推荐引擎(1310)还被配置为：向所述用户设备节点(1320)传递所述推荐数据流，作为友好关系请求；以及通过向所述交互流数据库(1308)添加信息，对指示所述用户设备节点(1320)的用户接受所述友好关系请求的消息进行响应，所述信息对所述至少两个资源节点(1330)之间的好友关系以及被所述交互执行引擎(1312)用来建立所述推荐数据流的相关联触发准则进行标识。

根据权利要求4所述的资源管理节点(1300)，其中，所述推荐引擎(1310)还被配置为：通过标识当前能够在资源节点(1330)中新接受的好友关系的至少一个资源节点与至少一个其他资源节点之间建立的一个或更多个其他推荐数据流，对接收到所述用户设备节点(1320)的用户对所述友好关系请求的接受进行响应；向所述用户设备节点(1320)传递一个或更多个其他友好关系请求，以及对将由所述一个或更多个其他推荐数据流针对所述用户设备节点(1320)创建的功能进行标识的信息；通过向所述交互流数据库(1308)添加信息，对指示所述用户设备节点(1320)的用户接受所述一个或更多个其他友好关系请求中所选的一个或更多个友好关系请求的一个或更多个消息进行响应，所述信息对所述一个或更多个其他推荐数据流中对应的推荐数据流之间的所选其他好友关系以及所述交互执行引擎(1312)用来建立所述一个或更多个其他推荐数据流中对应的推荐数据流的相关联触发准则进行标识。

根据权利要求4所述的资源管理节点(1300)，还包括：系统实体语义描述数据库(1306)，包含转码信息，所述转码信息被用于将来自一个或更多个数据流的数据转码为用于向所述用户设备节点(1320)传递的自然语言描述，其中，所述交互执行引擎(1312)使用来自所述系统实体语义描述数据库(1306)的所述转码信息将所建立的推荐数据流中的数据转码为向所述用户设备节点(1320)传递的自然语言描述。

根据权利要求1所述的资源管理节点(1300)，其中，所述推荐引擎(1310)还被配置为：跟踪其他用户设备节点的用户喜欢什么数据流；确定所述推荐数据流对应于所跟踪的所述其他用户设备节点的用户喜欢使用的数据流之一；以及传递指示所确定的所述推荐数据流的受欢迎情况的信息，作为到所述用户设备节点(1320)的消息的一部分。

根据权利要求1所述的资源管理节点(1300)，还包括：用户简档数据库(1302)，包含对所述交互流数据库(1308)所标识的哪些数据流已被所述用户设备节点(1320)的用户接受进行标识的信息，其中，所述推荐引擎(1310)还被配置为：使用所述用户简档数据库(1302)、所述系统实体数据库(1304)和所述交互流数据库(1308)生成所述推荐数据流，以标识所述用户设备节点(1320)的用户能够访问哪些资源节点(1330)并标识所述资源节点(1330)中的用户可访问资源节点之间的至少一个新数据流，所述至少一个新数据流不同于针对所述用户设备节点(1320)的用户激活的其他数据流；以及将所述至少一个新数据流作为所述推荐数据流传递给所述用户设备节点(1320)，以由所述用户设备节点(1320)的用户来接受。

根据权利要求1所述的资源管理节点(1300)，还包括：用户简档数据库(1302)，包含对用来访问所述资源节点(1330)中的对应资源节点的用户访问凭证进行标识的信息，其中，所述推荐引擎(1310)还被配置为：将所述推荐数据流限制为与具有所述用户简档数据库(1302)所标识的对应用户访问凭证的资源节点(1330)在一起。

根据权利要求9所述的资源管理节点(1300)，其中：所述推荐引擎(1310)还被配置为测试所述用户访问凭证，以确认所述交互执行引擎(1312)能够在向所述交互流数据库(1308)添加所述推荐数据流之前在对应资源节点(1330)之间建立数据流。

根据权利要求9所述的资源管理节点(1300)，其中：所述交互执行引擎(1312)还被配置为：当在对应资源节点(1330)之间建立数据流时，使用所述用户简档数据库(1302)所标识的所述用户访问凭证。

根据权利要求1所述的资源管理节点(1300)，还包括推荐引擎(1310)，所述推荐引擎(1310)被配置为：发现已变为新连接到所述至少一个网络(1380)且尚未和与所述交互流数据库(1308)中定义的数据流相关联的任何资源节点(1330)连接的资源节点；确定所发现的资源节点利用与所述资源节点(1330)中的一个或更多个资源节点兼容的数据格式来进行通信；以及在所述所发现的资源节点与兼容的一个或更多个资源节点(1330)之间发起一个或更多个数据流的建立。

根据权利要求1所述的资源管理节点(1300)，还包括：系统实体语义描述数据库(1306)，包含用于将所述资源节点(1330)之一输出的数据格式转码为另一数据格式的信息，所述另一数据格式对于到所述资源节点(1330)中的另一资源节点的输入是兼容的，其中，所述交互执行引擎(1312)被配置为：从所述系统实体数据库(1304)确定用于在所述资源节点(1330)中的数据流的两个或更多个资源节点之间通信的数据格式不兼容；以及通过使用来自所述系统实体语义描述数据库(1306)的所述转码信息将所述数据流的所述两个或更多个资源节点(1330)之间的数据进行转码以提供兼容通信，对所述确定进行响应。