管理从至少一个终端发送至网络的至少一个服务请求的方法，所述网络包括用于存储可信服务信息的网络节点；所述方法包括以下步骤；所述网络从终端接收服务请求；所述请求包括服务请求信息；以及如果所述服务请求信息的至少一部分未被列入所述可信服务信息中；则发送用户验证请求以便请求用户验证由所述终端请求的服务；接收用户验证响应；所述响应包括由所述用户提供的验证信息；所述验证信息指示所述用户是接受还是拒绝所述服务请求；以及如果所述验证信息提供了允许所请求的服务的指示；则向所述可信服务信息添加所述服务请求信息的至少一部分；其中所述可信服务信息包含所请求的服务的服务类型和目的地中的至少一个。

资深专利代理师意见如下：

针对目标专利《管理从至少一个终端发送至网络的至少一个服务请求的方法》（权利要求1）与三份对比文件（D1: JP2006106928A、D2: US20070245422A1、D3: JP2007310781A）的对比分析、创造性评估及检索策略制定如下：

---

## 一、 权利要求1技术特征拆解

目标专利权利要求1涉及一种在网络节点管理终端服务请求的方法，核心在于通过**白名单/可信服务信息（包含服务类型或目的地）**校验请求，未命中时触发**用户交互式验证（确认是否允许该服务）**，并在用户允许后将该请求动态**更新添加到可信服务信息**中。

技术特征拆解如下：

* **特征A**：所述网络包括用于存储可信服务信息的网络节点；

* **特征B**：所述网络从终端接收服务请求；

* **特征C**：所述请求包括服务请求信息；

* **特征D**：如果所述服务请求信息的至少一部分未被列入所述可信服务信息中；

* **特征E**：则发送用户验证请求以便请求用户验证由所述终端请求的服务；

* **特征F**：接收用户验证响应；

* **特征G**：所述响应包括由所述用户提供的验证信息；

* **特征H**：所述验证信息指示所述用户是接受还是拒绝所述服务请求；

* **特征I**：如果所述验证信息提供了允许所请求的服务的指示；

* **特征J**：则向所述可信服务信息添加所述服务请求信息的至少一部分；

* **特征K**：其中所述可信服务信息包含所请求的服务的服务类型和目的地中的至少一个。

---

## 二、 各对比文件对比分析与出处

各对比文件对目标专利权利要求1的公开情况如下：

### 1. D1: JP2006106928A (Access prevention apparatus, method, and program of preventing access)

* **公开情况**：

* **实质公开（终端侧/代理侧实施例）**：公开了**黑/白名单机制**（[0002]段）、**请求接收与判定**（[0002]段、[0002]段中说明的`ステップS201`、`S202`）、**警告弹窗及用户确认交互（接受/拒绝）**（`ステップS204`-`S205`，图3）。

* **实质公开（动态添加/记忆）**：公开了对于用户忽略警告并确认允许访问的站点，将其**存储记忆**，再次访问时不发出警告（[0002]段：“ブラウザ102は、警告を出力したにもかかわらずそれを無視し、ユーザがアクセスすることを承認したサイトについては、そのサイトを記憶しておくことにより、再度、そのサイトへアクセスする場合には、ユーザに警告を出力しないようにすることも可能である”）。

* **实质公开（网络节点部署）**：在实施例3中，上述逻辑被部署在连接终端与网络之间的**代理服务器（Proxy Server，即网络节点）**中（[0002]段：“プロキシサーバ1104に偽装判定部と有名サイト情報記憶部を配置し...”，图10）。

* **未公开/区别特征**：D1中的白名单主要基于域名/URL（目的地），未明确提及可信服务信息中包含**“服务类型”**。

### 2. D2: US20070245422A1 (Phishing-Prevention Method Through Analysis of Internet Website to be Accessed...)

* **公开情况**：

* **实质公开（白名单与校验）**：公开了存储稳定网站信息（Stable website information / Reliable website information）（[0040]段、[0046]段），比较输入的访问地址是否在白名单中（[0046]段 S80/S90）。

* **实质公开（用户验证交互）**：未在白名单中时弹窗警告，由用户选择是否继续访问（[0047]段 S100-S140，图4）。

* **实质公开（动态添加至白名单）**：公开了如果用户确定不是钓鱼网站，可以**将该输入的网站地址注册添加到可靠/可信网站列表中**（[0049]段：“the Internet user may register the inputted website address in the reliable website information when he/she convinces it of a website that is not a phishing website...”；[0027]段：“...an item for selecting whether to add a website address that made an access attempt to a reliable website list...”）。

* **未公开/区别特征**：D2主要是在**用户客户端PC（终端自身）**上安装防钓鱼程序（[0039]段），未明确公开由**网络中的网络节点**执行存储和控制逻辑；且白名单主要存储网站地址（目的地），未提及“服务类型”。

### 3. D3: JP2007310781A (Fake website prevention method and intermediate node)

* **公开情况**：

* **实质公开（网络节点部署）**：公开了在**网络中间节点（Intermediate Node 20）**拦截并处理HTTP请求（[0002]段、[0002]段，图1、图4）。

* **实质公开（验证与响应交互）**：公开了获取站点信息后向用户返送验证画面，由用户输入“承认”或“拒绝”（[0002]段、[0002]段 `ステップS13-S15`）。

* **实质公开（动态更新地址列表）**：如果用户选择“承认（Pass）”，中间节点将该目的地IP地址添加到`宛先アドレスリスト207`中（[0002]段 `ステップS14`：“登録ユーザが利用者端末30から接続先の承認を返送した場合、接続確認部205は、その宛先ＩＰアドレスと「pass」とを関連付けて宛先アドレスリストへ追加・格納する”）。

* **未公开/区别特征**：D3的校验逻辑倾向于对不在预存列表中的网站通过Whois查询进行域名/IP一致性分析后触发预览与用户验证，且`宛先アドレスリスト`主要记录目的地IP地址，未明确体现包含“服务类型”的结构化可信服务信息。

---

## 三、 特征比对表格

---

## 四、 最接近对比文件分析与创造性评估

### 1. 最接近对比文件的选择及理由

在专利无效或创造性分析中，**D1 (JP2006106928A)** 和 **D3 (JP2007310781A)** 均非常适合作为**最接近的对比文件（Primary Prior Art）**：

* **选择D1作为最接近对比文件**：

* **技术领域与问题相同**：D1旨在解决网络诈骗/钓鱼访问拦截问题，其实施例3明确构筑于网络中间节点（代理服务器 Proxy Server）上。

* **架构高度吻合**：D1公开了从代理服务器接收终端请求、判定白名单/可信库、向终端返回HTML确认/验证弹窗、接收用户带参验证响应，并在用户允许后将该站点进行记忆/添加（后续免警告）的完整闭环流程。

* **选择D3作为最接近对比文件**：

* **网络架构完全对齐**：D3直接定义了网络中间节点（Intermediate Node 20），明确提出了在网络节点维护一个白名单（`宛先アドレスリスト207`）。当收到未知请求时向用户请求“承认/拒否”，一旦“承认”则直接动态将该IP/地址追加（添加）到网络节点的白名单数据库中（`ステップS14`）。

### 2. 区别特征与最薄弱技术特征分析

**（1） 区别特征**

将目标专利权利要求1与D1或D3对比，主要区别特征在于：

* 权利要求1限定了“可信服务信息包含所请求的**服务类型**和目的地中的**至少一个**”。

* 虽然D1、D2、D3均明确公开了存储“目的地”（如URL、域名、IP地址），但均未显式提出在白名单中记录**“服务类型”（Service Type，如HTTP、FTP、特定端口服务、协议类型等）**。

**（2） 最薄弱的技术特征（目标专利的防线）**

目标专利最薄弱的技术特征是**特征K中关于“服务类型（Service Type）”的限定**以及**特征J（动态添加至网络节点的白名单中）**：

* **特征J（动态添加）**：D1（[0002]段）、D2（[0049]段）、D3（[0002]段 S14）均已非常完整地公开了“用户确认信任后，将信息添加至白名单/记忆库”的逻辑。特征J已被现有技术全面涵盖，**不具备创造性贡献**。

* **特征K（服务类型 vs 目的地）**：由于特征K使用了“……中的**至少一个**”这一选择性表述，在法律解释上，**只要对比文件公开了“目的地”或“服务类型”中的任意一个，即满足该特征的字面侵权/公开**。既然D1、D2、D3均公开了存储“目的地（URL/IP/域名）”，则特征K在字面意义上**已被D1/D2/D3完全公开**！

> **致命法律缺陷（无效突破口）**：

> 权利要求1的特征K采用了择一表达（“服务类型和目的地中的至少一个”）。由于D1/D3均公开了白名单中包含“目的地（URL/IP）”，在法律判定上，**D1/D3已经完全公开了特征K**。

> 这导致权利要求1的所有技术特征（A~K）已被D1（或结合D3）完全覆盖，权利要求1**极易因缺乏新颖性（A22.2）或创造性（A22.3）而被宣告无效**。

---

## 五、 进一步对比文件检索策略（深度无效策略）

为了确保彻底攻破目标专利（尤其是防止专利权人在无效阶段通过修改权利要求，将“服务类型”作为必要技术特征补入主权中），建议采取以下补充检索策略：

### 1. 核心关键词与分类号（IPC/CPC）组合

* **关键词（中文/英文/日文）**：

* 可信/白名单：`白名单` / `可信列表` / `Allowlist` / `Whitelist` / `Trusted service` / `ホワイトリスト` / `許可リスト`

* 服务类型/协议：`服务类型` / `协议类型` / `端口` / `Service type` / `Protocol type` / `Port number` / `服务标识`

* 动态添加/学习：`动态添加` / `自动更新` / `用户确认后添加` / `Dynamic update` / `Add to trust` / `User confirmed`

* 网络节点：`代理服务器` / `网关` / `防火墙` / `中间节点` / `Proxy` / `Gateway` / `Firewall` / `Intermediate node`

* **国际专利分类号（IPC/CPC）**：

* `H04L 63/02` (网络防火墙/安全过滤节点)

* `H04L 63/10` (网络访问控制/白名单/黑名单机制)

* `H04L 67/02` (Web服务/HTTP请求处理)

* `G06F 21/55` (恶意软件/网络攻击/钓鱼防范)

### 2. 检索逻辑式构建

* **逻辑组1（针对网络节点+白名单动态更新）**：

`((Proxy OR Gateway OR Firewall OR "Intermediate Node") AND ("White list" OR Allowlist OR "Trusted List") AND (Prompt OR Warn OR Confirm OR Verification) AND (Update OR Add OR Register))`

* **逻辑组2（针对“服务类型”白名单过滤）**：

`((Firewall OR Gateway OR "Access Control") AND ("Service Type" OR "Protocol Type" OR "Port") AND ("Allow List" OR "Trust List" OR Whitelist))`

### 3. 追溯方向建议

1. **防守性修改防范（重点检索“服务类型”+“网络节点白名单”）**：

重点检索早期（2000年—2008年间）的**企业级防火墙（Enterprise Firewall）**或**应用层网关（ALG / UTM）**专利。这类设备普遍具备“基于服务类型（如TCP/UDP端口、HTTP/FTP/SMTP协议）及目的地址联合控制，并在提示管理员/用户后动态放行并加入信任规则”的技术方案。

2. **同族专利与引证文献追踪**：

* 深入追踪D1 (JP2006106928A) 及D3 (JP2007310781A) 的**同族专利（如US/EP同族）**及**后续引证文献（Forward Citations）**。

* 检索Check Point、Cisco、Fortinet、Juniper等网络安全巨头在2005年前后申请的动态防火墙规则更新（Dynamic Rule Creation）相关专利。

### 一、 基于目标专利说明书的权利要求解释

为了准确判定权利要求1的技术特征范围与保护边界，结合专利说明书对核心术语及技术特征解释如下：

1. **“网络节点”与“可信服务信息” (特征A、K)**：

* **解释**：网络节点是网络架构中具备数据存储与处理能力的实体。可信服务信息（Trusted Service Information）是指经安全验证或白名单机制认可的服务配置/策略列表，其中**必须至少包含**“服务类型”（如电子邮件、Web、即时通讯、视频等）与“目的地”（如目标IP地址、域名、端口号、接收方端点）中的至少一种。

2. **“服务请求”与“服务请求信息” (特征B、C)**：

* **解释**：终端发起的向网络请求执行特定服务或数据传输的呼叫/数据包。服务请求信息包含该请求的具体属性（如请求的协议类型、目标地址/目的地、服务类别等）。

3. **未列入时的“用户验证请求/响应/验证信息” (特征D、E、F、G、H、I)**：

* **解释**：当网络节点检测到某请求的属性未在“可信服务信息”白名单中时，触发交互式验证机制。网络向用户端发送验证请求（Challenge/Prompt），要求用户明确做出“接受”或“拒绝”的交互指示（如通过输入密码、点击确认、回答问题等形式提供验证信息）。

4. **动态添加至可信服务信息 (特征J)**：

* **解释**：如果用户验证响应指示“允许/接受”该服务，网络节点会将该服务请求信息的至少一部分（如该新目的地或新服务类型）**自动更新/添加**至可信服务信息数据库中，以便后续对相同/同类请求直接放行而无需再次验证。

---

### 二、 对比文件特征比对分析与比对表格

以下分析严格基于各对比文件原文（对比文件公开号及出处段落）。

#### 1. D1：US5872847A

* **基本概念**：基于可信关联（Trusted Associations）在计算机网络中建立信任的系统（SNIU架构）。

* **特征比对**：

* **特征A (公开)**：公开了网络中包含SNIU（安全网络接口单元）及关联表（Association Table），SNIU作为存储可信关联参数的网络节点（[SUMMARY OF THE INVENTION] Paragraph [2]）。

* **特征B、C (公开)**：公开了SNIU接收来自主机（终端）的数据包/服务请求，请求中包含目的IP地址等信息（[DETAILED DESCRIPTION OF THE INVENTION] Paragraph [2]）。

* **特征D (公开)**：公开了Message Parser检查关联表，判断是否存在发送至该目的地的关联（若不存在则触发建立关联）（[DETAILED DESCRIPTION OF THE INVENTION] Paragraph [2]）。

* **特征E、F、G、H (未公开/差异特征)**：D1在未找到关联时，是由SNIU节点之间自动发送`Association Request`及`ICMP Echo Request`进行机器间的密匙与证书协商（[SUMMARY OF THE INVENTION] Paragraph [2]; [DETAILED DESCRIPTION OF THE INVENTION] Paragraph [2]），**并非发送给“用户”请求“用户”做出接受/拒绝的验证指示**。

* **特征I、J (实质公开/等同)**：当收到对端SNIU同意建立关联的响应（Association Grant）后，更新关联表（Association Table）（[DETAILED DESCRIPTION OF THE INVENTION] Paragraph [2]）。

* **特征K (公开)**：关联表中存储了目的地IP地址（PEER SNIU IP / IP ADDRESS）（FIG. 5; [DETAILED DESCRIPTION OF THE INVENTION] Paragraph [2]）。

#### 2. D2：US20030204569A1

* **基本概念**：利用“反向图灵测试”（Human Interactive Proof / Challenge）对可能感染未知病毒或垃圾邮件的电子邮件进行过滤。

* **特征比对**：

* **特征A (公开)**：公开了邮件过滤系统/服务器（网络节点），存储有Known Sender/Spammer等控制信息（[0031], FIG. 3, FIG. 4）。

* **特征B、C (公开)**：接收来自发送者的原始电子邮件（服务请求），包含发件人、收件人、邮件内容等信息（[0009], [0036]-[0040]）。

* **特征D (公开)**：判断邮件是否可疑（例如发件人不在已知安全列表中、或含有可疑代码/垃圾内容）（[0009], [0036], [0053]-[0055]）。

* **特征E、F、G、H (公开)**：当邮件被识别为可疑/未信任时，自动向发件人（用户）发送挑战（Challenge/Reverse Turing Test），要求发件人（人类用户）回答问题/执行任务以验证其身份（接受或拒绝放行邮件）（[0007], [0009], [0020], [0075]-[0081]）。

* **特征I、J (公开)**：当发件人正确回答挑战（指示允许该邮件/服务）后，系统将邮件放入收件箱，并将该发件人/历史验证结果**更新/添加**至历史数据库/分类器中（[0056], [0075], [0088]）。

* **特征K (公开)**：数据库中更新添加的可信/历史信息包含发件人身份/地址（即目的地/来源端点服务信息）（[0036], [0056]）。

#### 3. D3：US20040168055A1

* **基本概念**：安全即时通讯（Secure Instant Messaging）系统及证书发布机制。

* **特征比对**：

* **特征A (公开)**：即时通讯服务器（IM Server）及订阅数据库（S/AIM Subscriber Database）（[0077]-[0082]）。

* **特征B、C (公开)**：服务器接收IM消息或文件传输请求，请求包含接收方Screen Name（目的地）（[0016], [0026], [0148]-[0161]）。

* **特征D、E、F、G、H (未公开/差异特征)**：D3主要通过数字证书、密匙协商及SSL/S/MIME进行身份认证与加密（[0115]-[0133], [0184]-[0206]），不涉及未列入时向用户发送反向交互挑战（Challenge）要求用户明确指示接受/拒绝的技术特征。

* **特征I、J、K (部分公开)**：客户端通过验证证书或哈希值更新本地/服务器证书缓存（包含Screen Name等目的地信息）（[0183]-[0216]）。

---

#### 权利要求1特征比对表格（Feature Comparison Table）

---

### 三、 最接近对比文件分析与创造性（无效）评估

#### 1. 最接近对比文件的选择

在创造性分析中，**对比文件2 (D2: US20030204569A1)** 适合作为**最接近的对比文件**（Primary Prior Art）。

* **原因与技术效果分析**：

* **整体解决的技术问题**：本专利与D2均旨在解决“如何在网络节点接收到未明确信任的服务/通信请求时，安全、动态地甄别请求合法性并更新信任列表”的技术问题。

* **技术效果**：D2公开了通过网络节点接收服务请求，在未信任时触发针对用户的交互验证（Challenge/Response），并在验证允许后将该请求对应的实体信息更新添加至信任/历史数据库中。D2几乎**全面覆盖了权利要求1的所有技术特征（A-K）**。

*(注：D1主要解决网络会话层自动建立安全关联的问题，缺乏“用户交互验证”逻辑；D3主要解决IM消息及文件传输的证书分布与PKI加密问题，同样缺乏“未列入白名单时触发用户验证及动态添加入白名单”的全套闭环机制。因此D1和D3不适合作为第一最接近对比文件，但可作为辅助对比文件)*。

#### 2. 最接近对比文件未公开的特征及其他对比文件的补充

若将 **D2 (US20030204569A1)** 作为最接近对比文件：

* **公开情况**：D2实际上已经**实质公开了权利要求1的全部技术特征（A~K）**。

* **潜在争议点/最薄弱的技术特征**：

专利权人可能会辩称：*D2中的“反向图灵测试”是发送给“服务请求的发起方/发送方（Sender）”，而权利要求1中的“发送用户验证请求以便请求用户验证由终端请求的服务”涵盖了发送给“接收方用户/本地用户”进行确认的情形；此外，D2添加的是发件人信任信息，而权利要求1明确限定“可信服务信息包含服务类型和目的地中的至少一个”*。

#### 3. 无效攻击路径与最薄弱特征分析

* **最薄弱的技术特征**：**特征D+E+J+K的组合**（即：基于服务请求中的“服务类型/目的地”未在白名单中，触发向用户发送验证，并在允许后将“服务类型/目的地”更新加入可信白名单）。

* **无效策略**：

1. **方案一（单独基于D2破坏新颖性/创造性 - 35 U.S.C. 102/103 或 中国专利法第22条）**：

* 论证D2中电子邮件传输本质上是一种服务请求，邮件的收件人地址/Domain即为“目的地”，邮件类型/附件格式即为“服务类型”。D2在检测到未知发件人/可疑附件时，向用户发送Challenge，验证通过后更新历史白名单数据库（包含地址与服务属性）。因此权利要求1相对于D2不具备新颖性或创造性。

2. **方案二（D2与D1/D3组合破坏创造性）**：

* 若专利局/法院对D2中“目的地/服务类型”的理解有狭义解释，可结合 **D1 (US5872847A)** 或 **D3 (US20040168055A1)**：D1明确公开了在网络节点中基于“目的地IP地址/服务数据类型”建立及更新关联表（Association Table）（特征A, D, J, K）；结合D2公开的“未信任时通过用户验证请求（Challenge）获取许可并更新信任库”（特征E, F, G, H, I），本领域技术人员将D1的基于目的地的信任判定与D2的交互式用户验证机制结合是显而易见的。

---

### 四、 进一步对比文件检索策略（Retrieval Strategy）

为了确保无效请求的成功率，针对上述“最薄弱特征”（基于“服务类型/目的地”的白名单动态拦截与用户交互确认），建议采用以下进一步检索策略：

1. **分类号（IPC / CPC）扩展检索**：

* `H04L 63/10` (网络安全中的访问控制/策略)

* `H04L 63/0227` (基于白名单/黑名单的防火墙及过滤)

* `H04L 67/75` (网络服务请求与交互验证)

* `G06F 21/62` (保护计算机软件或数据的访问控制)

2. **关键词组合（Boolean Query Statement）**：

* **逻辑组1（网络节点与白名单）**：`(network node OR gateway OR firewall OR proxy) AND (trusted list OR whitelist OR trusted service)`

* **逻辑组2（未匹配与验证触发）**：`(not listed OR unknown OR unverified OR miss) AND (user verification OR prompt OR challenge OR authentication request)`

* **逻辑组3（动态更新）**：`(add OR update OR insert) NEAR/5 (destination OR service type OR IP OR port OR whitelist)`

3. **优先权日与专利族追溯策略**：

* 重点检索在目标专利**申请日/优先权日之前**（重点关注 2000 年~2005 年期间）网络防火墙（Firewall）、个人安全代理（Personal Firewall/Outbound Filtering，如 ZoneAlarm 动态提示弹窗技术）相关的专利文献及 RFC 标准。

* **关键技术场景切入**：检索“应用层防火墙在拦截到未知出站目的地（Destination IP/Port）或未知服务类型时，向终端用户弹窗询问‘允许/拒绝’，并在用户点击‘总是允许’后自动将该目的地/服务类型加入信任白名单”的对比文件，此类技术在 2000-2004 年的个人防火墙软件（如 ZoneAlarm, Norton Internet Security）专利中有大量公开。

作为一名经验丰富的专利代理师，我针对目标专利【权利要求1.docx】（以下简称权利要求1）与三篇对比文件（D1: US20040210772A1、D2: CN1588879A、D3: JP2005062942A）进行深度的专利法律与技术比对分析。

---

### 一、 目标专利权利要求1的技术特征分解与解释

**【权利要求1】**

管理从至少一个终端发送至网络的至少一个服务请求的方法，所述网络包括用于存储可信服务信息的网络节点；所述方法包括以下步骤：

- **特征A**：所述网络包括用于存储可信服务信息的网络节点；

- **特征B**：所述网络从终端接收服务请求；

- **特征C**：所述请求包括服务请求信息；

- **特征D**：如果所述服务请求信息的至少一部分未被列入所述可信服务信息中；

- **特征E**：则发送用户验证请求以便请求用户验证由所述终端请求的服务；

- **特征F**：接收用户验证响应；

- **特征G**：所述响应包括由所述用户提供的验证信息；

- **特征H**：所述验证信息指示所述用户是接受还是拒绝所述服务请求；

- **特征I**：如果所述验证信息提供了允许所请求的服务的指示；

- **特征J**：则向所述可信服务信息添加所述服务请求信息的至少一部分；

- **特征K**：其中所述可信服务信息包含所请求的服务的服务类型和目的地中的至少一个。

**【说明书结合解释】**

本发明的核心控制机制在于：在网络侧节点维护一份“可信服务信息”（白名单/允许列表概念）。当终端发起服务请求（包含类型/目的地）时，网络节点先检索该列表。若未命中（未知/不可信服务），网络并不直接拦截或自动放行，而是触发一个**交互式“用户验证请求”**向用户确认；一旦用户回复**允许/接受**，网络不仅放行该服务，还会**动态学习（更新）**，将该服务请求信息（类型/目的地）**添加保存到可信服务信息列表中**，从而实现可信服务列表的动态扩充与自动化管理。

---

### 二、 对比文件技术特征比对表及原文出处分析

#### 附：对比文件指代代号与公开号对照表

- **D1**：US20040210772A1 （Method and apparatus for secure instant messaging utilizing server-supervised publication）

- **D2**：CN1588879A （一种互联网内容过滤系统及过滤方法）

- **D3**：JP2005062942A （Service processing method, system, and its processing program）

---

#### 【特征比对表格】

---

### 三、 各对比文件公开性与技术方案深度分析

#### 1. 对比文件 D1 (US20040210772A1)

- **原理与内容**：D1公开了一种基于服务器监督出版的即时通讯（IM）安全方法。重点在于数字安全证书（Certificate）的发布、验证、撤销列表（CRL）查询以及加密IM消息传输。

- **特征比对**：

- D1公开了终端与网络服务器之间发送服务请求/会话请求（特征B、C）。

- 但D1的安全控制是基于**身份证书的合法性/撤销状态**，而非基于“可信服务信息（服务类型/目的地）”的匹配。D1完全**缺失**“未命中时提示用户验证 -> 接收用户选择 -> 将允许的服务动态追加写入可信服务列表”这套逻辑（特征D、E、F、G、H、I、J、K全部缺失）。

#### 2. 对比文件 D2 (CN1588879A)

- **原理与内容**：D2公开了一种互联网内容过滤系统。系统包含CFA（过滤代理，存黑白名单）、QS（查询服务器，存海量分级URL）和CAMS（内容分析与管理服务器）。

- **特征比对**：

- **公开了特征A、B、C、D、K**：当终端UT发送URL（包含服务类型与目的地）时，CFA拦截并匹配黑白名单；若不在黑白名单中，向QS查询；若QS中也没有（NAN不可判定），则判定未命中。

- **关键区别（缺失特征E-J）**：D2在遇到未知/未命中的URL（NAN）时，其处理方式是**“根据事先用户预设的固定策略自动判为允许或禁止”**，或者交由后端的CAMS服务器进行机器学习与人工抽查分析。D2**明确记载**：“在此情形下（即NAN不可判定），CFA不再更新其黑名单或白名单”。D2没有发送用户验证请求、无实时用户提示与交互响应，更无“用户同意后将该服务加入可信服务列表”的自学习机制。

#### 3. 对比文件 D3 (JP2005062942A)

- **原理与内容**：D3公开了一套Web服务处理方法，主要解决服务利用侧如何避免使用到自己黑名单（BlackList）中企业服务的问题。

- **特征比对**：

- **公开了特征A、B、C、D、K**：管理节点维护服务信息列表；服务节点接收服务请求并查询管理节点。

- **关键区别（缺失特征E-J）**：D3使用的是**静态/预先注册的黑名单**。当查询发现某个服务节点在黑名单中时，系统会自动重新发起UDDI检索去寻找替代的服务节点；若不在黑名单中直接调用。整个过程完全在后台自动化进行，不涉及“向终端发送用户验证请求，由用户实时确认是否放行，并将其动态写入可信服务信息”的过程。

---

### 四、 最接近的对比文件分析（最接近对比文件的选择）

#### 1. 整体解决的技术问题与技术效果对比

- **目标专利解决的问题与效果**：

- *技术问题*：如何更加灵活、智能化地管理网络可信服务列表，避免静态列表无法覆盖新服务、以及频繁手动配置的繁琐。

- *技术效果*：通过“未命中即触发用户实时验证”并结合“验证通过后自动学习/添加至可信列表”的机制，实现了可信服务信息的动态扩充，既保证了安全防护，又提升了系统自适应管理能力与用户体验。

- **D2解决的问题与效果**：

- *技术问题*：如何解决终端（CFA）资源受限无法存储海量黑白名单，以及网络内容海量时变的问题。

- *技术效果*：通过“CFA本地缓存 + QS分级查询 + CAMS后台分析”三层架构，提高过滤效率。

- **D3解决的问题与效果**：

- *技术问题*：解决分布式Web服务多级调用中，服务利用侧无法主动规避不信任/黑名单企业的问题。

- *技术效果*：通过在多级调用链中实时向BlackList管理节点查询，自动规避黑名单节点并重新路由。

#### 2. 最接近对比文件确定：**D2（CN1588879A）**

- **结论**：**D2 适合作为最接近的对比文件（主要最接近对比文件）**。

- **理由**：

1. **技术领域高度重合**：D2与目标专利均属于网络通信中的服务请求控制与网络安全/过滤领域（拦截终端服务请求，基于网络节点的列表信息进行放行/阻止）。

2. **技术特征覆盖度最高**：D2已经公开了“网络节点存储黑白名单（可信服务信息）”、“截获终端服务请求（包含服务类型与目的地URL）”、“判断请求信息是否在列表中（未命中处理）”等框架性特征（特征A、B、C、D、K）。

3. **架构最为契合**：相比于D1（基于密钥证书管理）和D3（基于多级Web服务调用的后台路由规避），D2的网络过滤代理（CFA）/查询服务器（QS）与目标专利中网络节点处理终端服务请求的模式最为接近。

*(注：D3亦可作为备选的第二最接近对比文件，用于组合对比，但其主要侧重于企业黑名单的后台避让，在服务请求过滤和动态学习的场景上略逊于D2。)*

---

### 五、 创造性与无效宣告攻击策略分析

#### 1. 未被最接近对比文件（D2）公开的技术特征

目标专利权利要求1相对于D2的**区别技术特征**为：

> **区别特征组（特征E、F、G、H、I、J）**：

> 当服务请求信息未被列入可信服务信息时，**向终端/用户发送验证请求** -> **接收包含用户许可/拒绝的验证响应** -> **若用户许可，则将该服务请求信息（至少一部分）添加保存到可信服务信息中**。

#### 2. 区别特征的技术效果与实际解决的技术问题

- **实际解决的技术问题**：如何在遇到未已知/未列入名单的服务请求时，提供一种实时交互式的安全确认机制，并实现可信服务信息的动态自动更新（自学习）。

#### 3. 无效请求中最薄弱的技术特征（攻击难点/专利权人的防线）

- **最薄弱的技术特征（即目标专利的核心发明点）**：

**特征J（根据用户允许指示，将服务请求信息动态追加/添加到可信服务信息中）** 与 **特征E/H/I（实时用户提示与交互授权）的有机结合**。

- **分析原因**：

- 在现有技术中（如D2），面对未知/不可信请求，通常的做法要么是“根据预设策略直接拦截/放行”，要么是“交由后台管理员/服务器爬虫（如CAMS）后续异步分析处理”。D2甚至明确排除在未命中时更新本地列表。

- D3则是完全依靠预先设定的黑名单进行自动避让。

- 这种“**交互式确认 + 动态放行 + 实时反馈追加至可信白名单**”的安全闭环逻辑（类似于防火墙/杀毒软件中的“学习模式/提示用户选择并记住规则”），是权利要求1中最不易被单篇对比文件直接公开、且不容易被公知常识简单等同替代的部分。

---

### 六、 进一步的对比文件检索策略建议

为了彻底突破权利要求1的区别特征（特征E~J），在后续提出专利无效宣告请求时，建议采取以下针对性的检索策略：

#### 1. 检索方向与技术领域扩展

不要将检索局限于“Web服务过滤（D2/D3）”或“IM即时通讯（D1）”，应当将技术领域扩展至：

- **个人防火墙/应用防火墙（Personal/Application Firewall）**：如 Early 2000s 的 ZoneAlarm、Norton Internet Security、Outpost Firewall 等软件技术。此类软件的核心逻辑即为：当检测到未知程序发起的网络出站请求（目的地/端口/协议未在规则列表中时），弹窗询问用户“允许/拒绝”，若用户勾选“记住此操作/总是允许”，则将该规则自动写入可信规则库。

- **入侵检测与预防系统（IDS/IPS）及防病毒软件（Anti-Virus）**：未知行为的实时拦截与用户授权规则学习机制。

- **移动终端/智能手机权限管理（Permission & Access Control）**：应用首次申请网络服务访问时，系统弹出权限申请提示，用户同意后写入系统的可信授权列表。

#### 2. 关键词与IPC分类号组合策略

- **关键词（中英文/日文）**：

- `(未知服务 OR 未列入 OR 未命中 OR unknown service OR not in list OR unlisted OR 未登録)`

- `AND`

- `(用户验证 OR 提示用户 OR 弹窗确认 OR 授权 OR user confirmation OR prompt user OR user authorization OR ユーザー確認 OR 許可)`

- `AND`

- `(动态添加 OR 更新白名单 OR 追加规则 OR 记住选择 OR add to trusted list OR update whitelist OR save rule OR dynamic rule addition OR 信頼リスト追加 OR 学習)`

- **专利分类号（IPC / CPC）**：

- `H04L 63/02`（网络安全；防火墙）

- `H04L 63/10`（安全访问控制；授权/访问列表）

- `H04L 63/20`（安全策略的配置与管理）

- `G06F 21/55 / G06F 21/56`（恶意行为监测与用户交互）

#### 3. 组合无效方案构想（三步法组合策略）

- **主对比文件（D2/CN1588879A）**：提供整体架构（网络节点、终端服务请求、黑白名单匹配、服务类型与目的地URL）。

- **辅助对比文件（D4 - 待检索出的防火墙/安全策略学习专利）**：提供“当请求不在可信列表中时，向用户发送提示请求，根据用户许可响应，将该请求特征追加至可信规则库”的技术启示。

- **无效理由**：本领域技术人员在D2的基础上，面对“如何提高未知服务处理灵活性和免去管理员手动维护白名单”的技术问题，引入D4（或防火墙/安全交互领域）公知的“用户确认并动态学习追加规则”的技术手段是显而易见的，从而不具备创造性（专利法第22条第3款）。

一份针对权利要求1的专利无效与创造性分析对比报告如下：

---

### 一、 权利要求特征分解与说明书解释

根据目标专利的说明书及权利要求上下文，权利要求1的技术方案解释如下：

* **技术特征A（网络节点存储可信服务信息）：** 网络中包含用于存储可信服务（Trusted Service）信息的节点。在说明书中，该可信服务信息作为白名单或已知可信服务列表存放在网络节点上。

* **技术特征B（网络接收服务请求）：** 网络节点从终端（Client/Terminal）接收发起的服务请求。

* **技术特征C（请求包含服务请求信息）：** 接收到的服务请求中携带有与服务相关的服务请求信息（如服务标识、目的地或服务类型）。

* **技术特征D（比对判断非可信）：** 网络节点将服务请求信息的至少一部分与可信服务信息比对，若未被列入可信服务信息（即非已知/未预先信任的服务），触发后续验证逻辑。

* **技术特征E（发送用户验证请求）：** 节点向终端/用户发送验证请求，请求用户对该未列入可信信息的服务进行人工/主动验证确认。

* **技术特征F（接收用户验证响应）：** 节点接收来自用户/终端的验证响应。

* **技术特征G与H（响应包含验证信息及决策）：** 响应中包含由用户提供的验证信息，该信息明确指示用户是“接受”还是“拒绝”该服务请求。

* **技术特征I与J（动态更新可信服务信息）：** 若用户的验证信息指示“允许/接受”该服务请求，网络节点将该服务请求信息的至少一部分（如服务类型或目的地）**动态添加并更新**到所述可信服务信息中，使得后续相同的服务请求无需再触发人工验证。

* **技术特征K（可信服务信息的具体内容）：** 可信服务信息包含所请求服务的“服务类型”和“目的地”中的至少一个。

---

### 二、 各对比文件与权利要求特征比对分析（公开程度与详细出处）

#### 1. D1：US20050060399A1

* **技术方案概述：** 涉及Web服务系统中的黑名单/服务管理。服务使用者（101）向黑名单管理服务节点（103）注册黑名单（如不想使用的服务公司/节点）。各中间服务提供者在调用下一个服务前，向103查询是否属于黑名单。若属于黑名单，则换用其他未列入黑名单的服务节点。

* **特征公开情况分析：**

* **实质公开/公开部分：**

* **特征A、B、C：** 公开了网络节点（管理节点103或服务提供节点106）存储管理服务信息，接收服务请求并包含服务请求信息（[0006]、[0052]-[0056]）。

* **特征D：** 公开了对比服务节点信息是否在名单中（[0006]、[0017]、[0055]）。

* **未公开/未实质公开部分：**

* **特征E、F、G、H：** D1中黑名单的处理是**系统自动绕过/拒绝**，并不存在“向用户发送验证请求以便请求用户验证，并接收用户指示接受或拒绝的响应”的**实时交互验证过程**。

* **特征I、J：** D1中黑名单/白名单的注册是**预先一次性注册**（[0006]“previously transmits... to a management node”），在服务运行判断过程中，不存在“用户允许后，将服务请求信息动态添加到可信服务信息中”的**动态学习/添加机制**。

* **特征K：** D1存储的是黑名单/节点标识，而非“包含服务类型和目的地中的至少一个的可信服务信息”。

#### 2. D2：US20050138351A1

* **技术方案概述：** 涉及无线局域网EAP认证过程中，终端通过认证服务器和OCSP服务器验证服务器证书（Server Certificate Verification）的方法。

* **特征公开情况分析：**

* **实质公开/公开部分：**

* **特征A、B、C：** 公开了局域网认证服务器（300）及OCSP服务器（400）存储/验证证书（可信信息），接收终端的认证/验证请求（[0010]、[0018]-[0021]）。

* **特征D、E、F、G、H：** 在证书无效或验证过程中，涉及服务器与终端之间的验证消息交互（[0010]、[0033]-[0037]）。

* **未公开/未实质公开部分：**

* **特征I、J：** D2涉及的是PKI体系下的证书状态查询（OCSP/CRL），验证过程是对既有CA/OCSP撤销列表的查询，**完全不包含**“如果用户指示允许，则向可信服务信息添加服务请求信息”的动态更新存储机制。

* **特征K：** D2验证的是证书合法性（Certificate Validity），而非服务的“服务类型和目的地”。

#### 3. D3：US07131003B2

* **技术方案概述：** 涉及即时通讯（IM）系统中的安全消息与文件传输。当用户A向用户B发送消息/文件时，需要获取并验证对方的安全证书。用户可以将其证书发布至IM服务器，IM服务器将证书Hash指纹分发给好友列表（Buddy List）。当好友本地缓存的Hash与服务器发来的Hash不匹配时，好友终端向IM服务器请求更新证书并存入缓存。

* **特征公开情况分析：**

* **特征A（实质公开）：** IM服务器（307）存储并发布用户的安全证书（可信服务/身份信息），且客户端本地维护证书缓存（[0082]、[0124]、[0167]）。

* **特征B、C（实质公开）：** IM服务器从终端接收服务请求（如发送即时消息/请求证书/文件传输），请求包含服务请求信息（[0166]、[0168]）。

* **特征D（实质公开）：** 当接收端/发送端比较接收到的证书Hash值与本地缓存不一致（即未列入/不匹配既有可信缓存）时（[0014]、[0167]“If the hash values do not match or the cache hash value does not exist”）。

* **特征E、F、G、H（隐含/部分公开）：** 终端在证书改变或收到未验证服务时，提示用户或请求用户确认是否接收/更新（[0167]、[0259]-[0263] UI提示 security status）。

* **特征I、J（实质公开）：** 如果确认/获取到新的有效证书后，将新证书/Hash（服务请求信息的一部分）**添加/更新到本地/系统的可信证书缓存（可信服务信息）中**（[0124]、[0167]“recipient requests the user's certificate... and update their caches with a new copy”）。

* **特征K（部分/实质公开）：** 证书中包含用户屏幕名（Screen Name，即IM通讯的目的地标识）以及服务类型（如S/MIME安全IM服务/文件传输服务，[0209]-[0221]）。

---

### 三、 特征比对表格

---

### 四、 最接近的对比文件分析（整体解决的技术问题与效果）

#### 1. 目标专利整体解决的技术问题及技术效果

目标专利旨在解决**网络服务访问过程中的安全性与动态信任扩展问题**。其技术效果在于：当终端发起未知的/未被预先信任的网络服务时，通过向用户触发弹窗/验证，由用户自主决定是否信任；一旦用户确认允许，系统能够**动态将该服务信息（类型/目的地）学习并添加到可信服务信息中**，从而在保证网络安全的前提下，提升后续服务访问的顺畅度与系统智能化程度。

#### 2. 最接近的对比文件选择：**D3 (US07131003B2)**

* **理由：**

1. **架构与机制最契合：** D3构筑了“客户端-IM网络服务器”架构，且明确引入了“可信信息（证书/Hash）缓存-比对未命中（未列入）-向服务器请求/用户确认-动态更新添加至缓存库”的完整闭环逻辑。

2. **特征覆盖度最高：** D3不仅公开了基本的网络请求和比对（特征A-D），更明确公开了动态添加更新可信服务信息（特征I、J）以及包含目的地（Screen Name/接收方标识）和服务类型（特征K）。

3. **技术问题一致：** D3同样旨在解决“在不可信/未知网络环境中，如何动态验证并建立对新服务/新联系人的信任，并减少重复验证开销”的问题。

*(注：D1虽然涉及服务选择，但其属于静态黑名单过滤/系统自动路由绕过，缺乏“用户验证响应”和“动态允许后添加到可信库”的关键机制，不适合作为第一最接近对比文件；D2属于纯粹的网络接入层证书校验，不涉及服务信息的动态添加，相关性最弱。)*

---

### 五、 无效请求中最薄弱的技术特征与防守点

若对本专利发起无效宣告请求，本权利要求**最薄弱（即最难被对比文件组合完全攻破）的技术特征**是：

> **特征E-H 与 特征J 的有机组合：** “在服务未被列入可信信息时，**主动向用户发送验证请求**以获得用户‘接受或拒绝’的指示，并**基于用户明确的‘允许’指示**，将该服务请求信息的至少一部分**动态添加**到所述可信服务信息中。”

* **薄弱点/防守原因：**

1. **D1** 采用的是系统后台自动比对黑名单，若命中黑名单直接系统重定向或拒绝，**完全没有“向用户提示并由用户决策”**的步骤，也没有“允许后加入可信库”的逻辑。

2. **D2** 属于后台协议（EAP/OCSP）自动校验，属于机对机的认证，**完全不干预用户层面的人工确认与信任库学习**。

3. **D3** 虽然有缓存更新（J）和UI显示（E-H），但其更新触发更多是基于PKI证书链和Hash对比的“系统自动拉取更新”，**“将用户显式的接受/拒绝决策作为触发可信库添加（学习）的直接条件”**在D3中属于弱公开或隐性公开。

---

### 六、 进一步的对比文件检索策略建议

为了彻底攻克“**未知服务 -> 弹窗提示用户确认/授权 -> 用户允许后 -> 动态将该服务/地址/类型写入可信白名单**”这一核心创新点，建议采取以下补充检索策略：

1. **领域拓展（从IM/Web服务拓展至防火墙/杀毒软件/网络安全访问控制）：**

* *检索逻辑：* 目标专利的特征本质上是**“个人防火墙/主动防御（HIPS）/网络访问控制”**的经典逻辑（例如：某未知程序/网址试图联网，防火墙弹窗询问“是否允许？”，用户点击“允许并记住选择”，防火墙将该IP/域名/端口添加到“可信服务规则库/白名单”中）。

* *建议IPC分类号：* `H04L63/02`（防火墙；网络访问控制）、`H04L63/10`（安全策略）、`G06F21/55` / `G06F21/56`（程序行为监控与恶意软件防御）。

2. **关键词组合调整：**

* **核心逻辑词对：**

* `(untrusted OR unknown OR "not in list" OR "not match")` （未列入/不可信）

* `(prompt OR ask OR request) NEAR/3 (user OR human)` （请求用户验证）

* `(allow OR accept OR trust)` （允许/接受）

* `(add OR update OR append OR store) NEAR/5 (trusted OR whitelist OR "allow list")` （添加至可信库/白名单）

* **服务特征词对：**

* `("service type" OR destination OR URL OR IP OR port)` （服务类型或目的地）

3. **重点追溯专利权人与早期经典文献（预判2004-2010年左右的防火墙专利）：**

* 重点检索 Symantec, McAfee, ZoneAlarm, Trend Micro, Kaspersky 等网络安全公司在 2000-2010 年间申请的“动态白名单/交互式防火墙规则学习”相关专利。这类文献极有可能会彻底完全公开“用户确认后将未知名服务/目的地动态写入可信列表”的全套技术特征。

作为一名经验丰富的专利代理师，我将严格按照专利审查指南及创造性/无效分析的标准流程，紧密结合目标权利要求与各对比文件（D1、D2、D3）的原文及具体段落，为您进行全面、严密的对比分析。

---

### 一、 权利要求特征分解与技术解释

目标权利要求1保护一种**管理从至少一个终端发送至网络的至少一个服务请求的方法**，其核心逻辑在于：网络节点存储“可信服务信息”，在收到终端服务请求后，若发现请求信息未列入该可信信息中，则向用户发起验证；收到允许指示后，**动态地将该服务请求信息（服务类型/目的地）补充添加至可信服务信息中**，从而完成规则的动态学习与更新。

* **技术特征A**：所述网络包括用于存储可信服务信息的网络节点

* *说明书解释*：网络侧具有存储节点（如数据库/防火墙/服务器），用于维护一份包含“可信任/被允许”的服务准入信息列表。

* **技术特征B**：所述网络从终端接收服务请求

* *说明书解释*：终端发起的连接请求、消息发送或服务调用被网络节点接收。

* **技术特征C**：所述请求包括服务请求信息

* *说明书解释*：请求体或请求头中携带识别该服务特征的信息（如目的地地址、服务类型等）。

* **技术特征D**：如果所述服务请求信息的至少一部分未被列入所述可信服务信息中

* *说明书解释*：网络节点将接收到的请求信息与已有的“可信服务信息”进行匹配检查，触发未命中（Miss/未列入）判定。

* **技术特征E**：则发送用户验证请求以便请求用户验证由所述终端请求的服务

* *说明书解释*：因未列入可信列表，网络节点主动向用户/终端推送验证提示，要求用户确认是否授权。

* **技术特征F**：接收用户验证响应

* *说明书解释*：网络节点接收终端/用户对上述验证请求的反馈。

* **技术特征G**：所述响应包括由所述用户提供的验证信息

* *说明书解释*：响应报文中包含用户的操作决策数据。

* **技术特征H**：所述验证信息指示所述用户是接受还是拒绝所述服务请求

* *说明书解释*：验证信息明确反映了用户的授权意志（允许或拒绝）。

* **技术特征I**：如果所述验证信息提供了允许所请求的服务的指示

* *说明书解释*：判定逻辑：当验证信息表明用户选择了“接受/允许”。

* **技术特征J**：则向所述可信服务信息添加所述服务请求信息的至少一部分

* *说明书解释*：**核心创新点/动态更新机制**。网络节点将本次通过验证的服务请求信息（或其特征部分）追加写入网络节点存储的“可信服务信息”中，实现白名单/可信库的动态学习与自动扩充。

* **技术特征K**：其中所述可信服务信息包含所请求的服务的服务类型和目的地中的至少一个。

* *说明书解释*：限制了可信服务信息的具体属性内容（如服务类型或目的地址/号码/URL等）。

---

### 二、 对比文件原文技术特征比对表格

以下为各对比文件针对权利要求1各项技术特征的比对分析。

*注：对比文件指代代号与公开号对应如下：*

* **D1**：`US20070050624A1` (SECURE INSTANT MESSAGING SYSTEM)

* **D2**：`WO2007041157A1` (WIRELESS NETWORK PROTECTION AGAINST MALICIOUS TRANSMISSIONS)

* **D3**：`WO2008001061A1` (A METHOD OF OPERATING A DUAL SIM WIRELESS COMMUNICATIONS DEVICE)

---

### 三、 整体技术问题、技术效果与最接近对比文件分析

#### 1. 各对比文件的技术领域、问题与效果分析

* **D1 (`US20070050624A1`)**：

* *技术问题*：解决了即时通讯（IM）网络中，如何在现有架构下实现安全的端到端消息/文件传输及证书分发问题。

* *技术效果*：通过在服务器分发证书Hash值，避免频繁下载大容量证书，提高通信效率和安全性。

* **D2 (`WO2007041157A1`)**：

* *技术问题*：解决了无线通信网络中，移动终端（如智能手机）因恶意代码/病毒自动发起异常或高昂服务连接而对网络及用户造成破坏和经济损失的问题。

* *技术效果*：在网络侧（基站/防火墙）建立过滤机制，基于安全策略/白名单/黑名单拦截恶意流量，并在超限或异常时通知用户，由用户决定是否解除拦截。

* **D3 (`WO2008001061A1`)**：

* *技术问题*：解决了单射频前端的无线终端如何同时运行和注册多个SIM卡的问题。

* *技术效果*：在同一基站下共享物理信道实现双卡同时待机。

#### 2. 最接近对比文件的选择

**最接近对比文件为：D2 (`WO2007041157A1`)**。

**选择理由**：

1. **技术领域与问题高度契合**：本专利权利要求1解决的是“网络节点如何管理终端发送的服务请求，通过用户验证来区分合法请求与非法请求，并对可信服务信息进行动态管理”的问题。D2同样处于无线网络服务请求防护和流量管控领域，旨在解决网络节点如何基于规则拦截未授权/恶意服务请求，并引入用户交互验证的问题。

2. **技术特征覆盖度最高**：D2公开了权利要求1的大部分核心特征（特征A、B、C、D、E、F、G、H、I、K）。D2在基站（网络节点）设置白名单/策略（可信服务信息），拦截未在策略内的服务（如未允许的eBay访问或高昂服务），并向用户发送通知，接收用户的解封/验证指令（clearance message）。

3. **对比D1和D3**：D1侧重于PKI密钥与证书Hash的PKI同步管理，缺乏“用户提示与授权验证”这一核心逻辑；D3属于底层通信协议及硬件多卡待机技术，技术领域和问题均不相关。因此D2是唯一的最佳最接近对比文件。

---

### 四、 未被最接近对比文件公开的特征及“最薄弱技术特征”分析

#### 1. 未被D2公开的技术特征

通过对D2原文的精细比对，**特征J**（“则向所述可信服务信息添加所述服务请求信息的至少一部分”）未被D2完全/实质公开。

* **D2原文情况分析**：

* D2段落`[0017]`提到：“moles that have already been identified as virulent... remain in 'blocked' status until, e.g., the user sends a clearance message, or switches off his personal firewall.”（被拦截的终端保持阻塞，直到用户发送clearance消息或关闭防火墙）。

* D2段落`[0018]`提到：“To permit such traffic to pass... the user could send a notice to the firewall announcing that he will send a mass SMS...”（用户可以向防火墙发送通知宣布将发送群发消息，以允许通过）。

* **差异点**：D2仅公开了“**临时放行/解除当前阻塞（clearance）**”或“**一次性声明允许**”，**并未公开“将该被允许的服务请求信息（如目的地/服务类型）动态添加到网络节点的白名单/可信服务信息存储中，以备后续再次请求时直接放行”**这一学习/动态更新机制（特征J）。

#### 2. 判定无效请求中最薄弱的技术特征

在针对本专利权利要求1发起无效宣告请求时，**最薄弱的技术特征为：特征J**（即“**如果验证信息提供了允许所请求的服务的指示，则向所述可信服务信息添加所述服务请求信息的至少一部分**”）。

* **薄弱性原因**：

1. 现有对比文件（D1、D2、D3）中，**没有任何一篇直接公开了“网络节点在收到用户许可后，将该服务请求信息反向追加/写入到可信服务信息库（动态白名单更新）”这一动作**。

2. 专利权人在无效答辩中极易将“特征J”主张为**显性贡献**（即实现了“动态学习与白名单自动维护，避免用户对同一服务反复收到验证打扰”的技术效果）。

3. 若仅依赖现有D1~D3的组合，审查员/审理组很可能认定“在拦截放行后将新服务自动加入可信白名单”属于非公知常识的特有技术手段，从而维持权利要求1有效。

---

### 五、 进一步的对比文件检索策略

针对上述最薄弱特征（特征J：动态学习/将用户通过的拦截项添加到网络侧白名单），建议采取以下补强检索策略：

#### 1. 检索主题词与表达扩展（Keywords & Concepts）

* **网络节点/防火墙/白名单**：White List, Allowed List, Trust List, Dynamic White List, Firewall Rule Base, Rule Update, Database Modification.

* **动态学习/自动添加/更新**：Dynamic Add, Auto-learning, Self-learning, Automatically append, Update rule, Add entry, Learn-mode.

* **用户授权/验证拦截**：User authorization, User consent, Prompt user, Access Control, Interactive Firewall.

#### 2. 逻辑组配与检索式设计（以IPC分类号与关键词结合）

* **IPC/CPC分类号精准锁定**：

* `H04L63/02`（网络防火墙/数据包过滤）

* `H04L63/10`（网络访问控制/基于策略的安全）

* `H04W12/08`（无线网络安全/访问控制）

* `G06F21/55` / `G06F21/56`（恶意程序检测与拦截）

* **组合检索逻辑**：

1. `（(Firewall OR "Network Node" OR "Base Station") AND ("White List" OR "Trusted List" OR "Security Policy")）`

2. `AND （(Prompt OR Query OR Challenge OR Request) NEAR3 (User OR Consumer)）` （匹配网络提示用户确认）

3. `AND （(Add OR Append OR Update OR Learn OR Insert) NEAR5 ("White list" OR "Trusted List" OR Rule OR Database)）` （匹配特征J：验证通过后自动添加至白名单）

#### 3. 重点检索领域与专利族/非专利文献源

* **重点专利权人/技术巨头**：关注网络安全与电信网元设备厂商在2006年~2007年（目标专利优先权日前）的专利布局，如：

* 网络安全厂商：Check Point, Juniper Networks, Palo Alto Networks, Symantec, McAfee.

* 电信设备商：Huawei, ZTE, Ericsson, Nokia, Qualcomm.

* **非专利文献（NPL）**：

* 早期交互式防火墙（如 ZoneAlarm, Kerio Personal Firewall, Iptables 扩展模块）的技术手册与白皮书。此类防火墙极具“当程序/服务首次联网触发拦截，询问用户 Allow/Deny，若用户选择 Remember this answer/Always allow，则将该规则自动写入允许列表”的技术特征（需重点寻找将该逻辑部署在网络节点/网关处的文献）。

针对目标专利《权利要求1》与三篇对比文件的技术比对、最接近对比文件分析、最薄弱特征认定及检索策略，分析如下：

---

## 一、 对比文件特征比对分析与出处对照

为确保分析严谨，以下将对比文件代号及其官方公开号进行明确对应：

* **D1**：JP2008011148A

* **D2**：US7321969B2

* **D3**：JP2008048055A

### 1. 技术特征比对表

---

### 2. 对比文件原文详细出处对照

#### **D1 (JP2008011148A)**

* **特征A**：段落`[2]`说明“电话帐端末40は、発呼番号及びそれに伴う発呼先関連情報が格納された電話帳ＤＢ41を備える...優良電話番号テーブル41a...”。

* **特征B、C**：段落`[2]`说明“発呼番号受信部14は、ユーザ端末20が発呼したときの発呼番号を受信する...ＩＮＶＩＴＥメッセージ...発呼番号が含まれる”。

* **特征D**：段落`[2]`说明“優良及び要注意電話番号テーブル41ａ，41ｂに格納されていない発呼番号である場合...”。

* **特征E**：段落`[2]`说明“発呼先関連情報送信部16は...Ｔｒｙｉｎｇメッセージ...ユーザ端末20に送信する...画面に「...お間違いありませんか？」と表示される”。

* **特征F、G、H、I**：段落`[2]`说明“当該ユーザ端末からの発呼許可通知を受けたことに応じて着呼要求情報を送信する...通話を続けるか否かを判断することができる”。

* **特征K**：段落`[2]`图2及说明“電話番号41aa...電話番号先のＩＤ41ab...”。

#### **D2 (US7321969B2)**

* **特征A、K**：栏`[0026]`、图5说明“secure buddy list 320 that includes data representing: mandatory secure buddies 500, mandatory unsecure buddies 502...”。

* **特征B、C**：栏`[0044]`说明“proxy 22a intercepts instant messages... clear text packets 34...”。

* **特征D**：栏`[0054]`、`[0055]`说明“comparing the buddy ID from the instant message from the buddy IDs listed in the secure buddy list...”。

#### **D3 (JP2008048055A)**

* **特征A**：段落`[2]`说明“許可発信元情報記憶手段（ホワイトリスト記憶部210）...”。

* **特征B、C**：段落`[2]`说明“接続要求（ＩＮＶＩＴＥ）...発信元通信アドレスおよび着信先通信アドレス...”。

* **特征D**：段落`[2]`说明“接続許可手段により接続が許可されなかった場合に（不在白名单中）...”。

* **特征E**：段落`[2]`说明“同意確認送信手段...同意確認メッセージを着信先に送信する...”。

* **特征F、G、H**：段落`[2]`说明“返信受信手段...同意確認メッセージに応答して着信先から...追加同意通知（或拒绝通知）を受信する...”。

* **特征I、J**：段落`[2]`说明“許可発信元情報追加手段...返信受信手段が追加同意通知とともに受信した発信元情報を許可発信元情報記憶手段に追加する...”。

* **特征K**：段落`[2]`说明“通信アドレス（0503345002等）およびSIP/邮件/电话等通信手段类型”。

---

## 二、 最接近对比文件分析

在创造性评估中，**D3 (JP2008048055A)** 与 **D1 (JP2008011148A)** 均具备作为“最接近的对比文件”的资格，其中 **D3 为首选最接近对比文件**。

### 1. D3 (JP2008048055A) —— 首选最接近对比文件

* **技术领域与问题**：同样属于网络通信连接控制与防垃圾/防钓鱼攻击领域，旨在解决当请求服务/连接不在既定信任名单中时的动态安全验证与信任库更新问题。

* **特征覆盖度**：D3 **全面公开了权利要求1中的技术特征A、B、C、D、E、F、G、H、I、J、K**。D3明确揭示了网络节点在收到未列入白名单（可信服务信息）的请求时，向用户发送同意确认请求（验证请求），在收到许可指示后，将该发信元信息（服务请求信息）追加添加至白名单（可信服务信息）中。

### 2. D1 (JP2008011148A) —— 备选最接近对比文件

* **技术领域与问题**：属于VoIP/网络呼叫安全防钓鱼领域，解决用户向未知网络节点发起呼叫时的身份确认问题。

* **特征覆盖度**：公开了特征A、B、C、D、E、F、G、H、I、K。

* **与权利要求1的差异**：D1未公开**特征J**（向可信服务信息中**添加**服务请求信息）。D1在用户确认呼叫后仅完成当次呼叫的建立，并未将该号码自动学习并更新写入数据库41中。

---

## 三、 无效请求中最薄弱的技术特征分析

针对权利要求1，若要发起无效宣告请求，**最薄弱的技术特征为：技术特征J（向可信服务信息添加所述服务请求信息的至少一部分）**。

### 薄弱性逻辑分析：

1. **对比文件D3已实质公开特征J**：D3中“许可发信元情报追加手段”在收到追加同意通知后，明确将发信元通信地址写入许可发信元情报记忆手段（白名单）中。这意味着权利要求1的所有技术特征已被单篇对比文件D3完全覆盖。

2. **新颖性缺陷（A22条）**：基于D3的完全公开，权利要求1直接面临**不具备新颖性**的巨大风险。

3. **显而易见性（A23条）**：即使退一步以D1作为最接近对比文件（D1缺少特征J），将D3中“将验证通过的未知请求源动态添加至信任名单”的常规技术手段结合到D1中，以解决“避免重复对已知安全服务进行人工二次验证”的技术问题，对本领域技术人员而言是完全显而易见的。

---

## 四、 进一步对比文件检索策略建议

为了深化无效案卷的证据链（尤其是针对从属权利要求及应对专利权人的修改策略），建议采用以下检索策略：

### 1. 扩充技术关键词与分类号 (IPC/CPC) 组合

* **关键词组**：

* **可信库/白名单**：`White list` / `Trust list` / `Allowed list` / `Trusted service` / `ホワイトリスト` / `许可表`

* **未命中判断**：`Not in list` / `Miss` / `Unknown` / `未登録` / `不在表中`

* **动态验证/许可**：`Consent` / `Approval` / `Validation request` / `Prompt` / `同意確認` / `授权提示`

* **动态更新/添加**：`Dynamic add` / `Auto update` / `Append` / `追加` / `写入`

* **专利分类号**：

* `H04L 63/10` (网络安全访问控制)

* `H04L 67/52` / `H04L 67/14` (基于会话和服务的连接控制)

* `H04M 3/436` (呼叫过滤与阻断体系)

### 2. 重点检索方向

1. **反垃圾邮件/反SPAM与SIP安全规范**：重点检索RFC标准草案（如针对RFC 3261扩展的Consent-based communications框架文档，即D3中引用的Internet-Drafts）。

2. **动态防火墙/智能网关日志学习**：检索基于行为分析的动态安全网关专利，重点关注“拦截未知服务请求 -> 发起二次Challenge/验证 -> 验证通过后自动加入允许规则库 (Access Control List)”这一机制。

3. **同族专利与引证文献追踪**：深度挖掘对比文件 **D3 (JP2008048055A)** 的同族文献以及审查历史中的引证/被引证对比文件（Forward/Backward Citation Search），通常能获取同等攻防强度的同类美专利或欧洲专利。

尊敬的客户/案件主管：

作为一名经验丰富的专利代理师，我已对目标专利权利要求1及三份对比文件（D1: CA2619397A1, D2: US20080098225A1, D3: WO2008051933A2）进行了全面的技术特征比对与法律逻辑梳理。以下是详细的无效宣告检索与创造性分析报告：

---

## 一、 权利要求1的技术本质与解释

本权利要求1的核心技术方案在于一种**动态信任列表更新与服务请求授权控制方法**。

* **实质流程**：网络节点在收到终端的服务请求后，先查询“可信服务信息”（黑/白名单或可信库）。若该服务请求信息（如服务类型或目的地）**未在**可信服务信息中，网络不直接拒绝或放行，而是触发**用户二次验证交互**（向终端/用户发送验证请求并接收包含允许/拒绝指示的响应）。若用户明确授权“允许”，网络不仅放行服务，还会**将该服务请求信息的至少一部分（类型/目的地）动态添加到“可信服务信息”中**，以便后续直接匹配。

* **技术效果**：兼顾网络访问安全性与用户使用便捷性，减少重复验证，实现可信服务列表的动态学习与自动扩充。

---

## 二、 特征比对与对比文件公开情况分析

以下为权利要求1各个技术特征（A~K）在三份对比文件中的原文对照与公开性判断。

### 1. 技术特征比对表

---

## 三、 最接近对比文件分析与创造性评价

在审查及无效宣告程序中，最接近对比文件的选择应基于**技术领域、解决的技术问题及技术特征重合度**：

### 1. 文本族系说明

* **D1（CA2619397A1）与 D3（WO2008051933A2）** 属于同一专利族（同源于 US Provisional 60/853,150），其说明书文本内容与附图高度重合，技术方案均聚焦于“基于接入点（AP）的IP/MAC地址黑白名单控制GAN/UMA网络接入”。

### 2. 最接近对比文件的选择

* **备选1：D2 (US20080098225A1)** —— **强烈推荐作为第一最接近对比文件**

* **理由**：D2解决的技术问题是“在网络/网站访问过程中如何安全地对用户进行双因素/二次身份认证”。D2完整公开了**特征A、B、C、E、F、G、H、I、K**。其逻辑（网站访问请求 -> 服务器向无线设备发SMS验证码 -> 用户输入PIN/验证码响应 -> 验证通过则允许访问）与权利要求1的“交互式验证”架构几乎完全吻合。

* **区别特征**：D2未公开**特征D**（基于可信列表匹配失败作为触发条件）和**特征J**（用户授权后**动态将服务信息添加/更新至可信服务信息**中）。

* **备选2：D1 (CA2619397A1) / D3 (WO2008051933A2)** —— **可作为第二最接近对比文件**

* **理由**：D1/D3解决的是网络节点基于存储的网络接入点（IP/MAC）白名单/黑名单实施访问控制的问题（公开了特征A、B、C、D）。

* **区别特征**：D1/D3缺乏“触发用户验证并根据用户允许动作**动态学习并添加**可信服务信息”的闭环机制（缺少特征E、F、G、H、I、J、K）。

---

## 四、 无效请求中最薄弱的技术特征与突破口

若基于目前给出的D1、D2、D3提出无效宣告请求，**最薄弱（即最难被现有对比文件攻破）的技术特征**是：

> **特征J：如果所述验证信息提供了允许所请求的服务的指示，则向所述可信服务信息添加所述服务请求信息的至少一部分。**（以及特征D与J构成的“匹配失败->用户授权->自动学习添加”的动态更新闭环）

### 析因分析：

1. **D2的局限**：D2是一个典型的二次认证（2FA/OTP）系统，用户每次访问或验证成功，仅赋予**本次会话（Session）**的访问权限（[0021] Session ID），**并没有**将该被访问的网站/服务“记录并添加”到常态化的“可信服务白名单”中以备下次免验或信任匹配。

2. **D1/D3的局限**：D1/D3中的黑白名单是静态配置或由网络管理节点根据QoS质量指标在后台更新（[0031]），**完全没有**“通过终端/用户实时交互授权来反馈更新白名单”的机制。

---

## 五、 进一步对比文件检索策略（无效方案补充）

为了彻底无效权利要求1，必须补充检索能够公开“**安全防护/防火墙/访问控制中，针对未知/不在信任列表中的服务，通过提示用户确认，并在用户确认信任后自动将该服务/地址加入信任列表（白名单）**”的技术特征。

建议采用以下检索策略：

### 1. 扩展技术领域（防范防火墙/安全软件/网络接入控制领域）

权利要求1的实质是“**未知服务的提示与动态白名单学习（Trust-on-First-Use / Auto-whitelisting）**”。该技术在 PC 端防火墙（如 ZoneAlarm、360安全卫士）、移动端应用权限/网络访问控制（Android/iOS 防火墙）领域极为常见。

### 2. 关键词与逻辑检索式构建（以英文/中文专利库为例）

* **核心概念组合 1（动态白名单/学习机制）**：

`("trust list" OR "white list" OR "trusted service" OR "trusted database")`

`AND ("add" OR "update" OR "append" OR "learn")`

`AND ("user prompt" OR "user verification" OR "user permission" OR "user allow")`

* **核心概念组合 2（防火墙/拦截与提示）**：

`("service request" OR "access request")`

`AND ("not in" OR "unknown" OR "untrusted")`

`AND ("prompt user" OR "request authorization")`

`AND ("add to trusted" OR "remember decision")`

### 3. 组合无效路线预演（公知常识/结合证明）

* **主引证（D2） + 辅引证（新检索到的防火墙/动态白名单专利 D4）**：

* 用 D2 提供“服务请求 - 二次发送验证 - 用户确认授权”的基础架构；

* 用 D4（或安全软件领域的公知常识）提供“当请求的服务未在信任列表中时，提示用户授权，并在授权后**将该服务添加至信任列表**以简化后续访问”的技术教导。

* **结合理由**：为了提高安全系统的智能化水平并减少频繁打扰用户的验证弹窗，本领域技术人员有动机将 D4 中的“用户确认后自动记入白名单”机制引入 D2 的认证流程中，从而得到权利要求1的方案。

---

*如需针对特定检索库生成具体的 检索表达式（如 Table search / IPC分类号如 H04L63/10, H04W12/08），可进一步为您定制。*

这是一份针对目标专利权利要求1（下称“本案权利要求1”）的详细专利无效可行性深度分析报告。

---

## 一、 权利要求1的技术特征分解与本案技术方案解读

本案权利要求1涉及一种“管理从至少一个终端发送至网络的至少一个服务请求的方法”。在解释权利要求时，需紧密结合专利说明书的一般理解：

* **网络与网络节点（特征A）**：网络节点是网络中具有存储与逻辑判断能力的实体（如服务器、网关等）。

* **服务请求与服务请求信息（特征B、C、K）**：终端向网络发起的通信/连接/服务请求，请求信息包含**服务类型**（如HTTP、SMTP、IMAP等协议类型或具体业务）和**目的地**（如目标IP地址、URL、域名、接收方地址等）中的至少一个。

* **可信服务信息与白名单机制（特征A、D、J、K）**：网络节点中存储有预先认可的“可信服务信息”（即白名单，包含可信的服务类型或目的地）。如果发起的请求信息未在该列表中，则触发验证。

* **用户验证交互（特征E、F、G、H、I）**：网络向用户/终端发送验证请求；用户提供指示“接受”或“拒绝”的验证信息；若用户选择“允许/接受”，则放行该服务。

* **动态白名单更新（特征J）**：在用户确认允许该服务后，网络节点将该**服务请求信息的至少一部分**自动添加至可信服务信息中，从而实现白名单的动态学习与扩充。

---

## 二、 对比文件原文技术特征比对与公开性分析

下表将权利要求1分解为技术特征A~K，并详细比对各对比文件原文（附公开号及精确段落编号）。

### 1. 详细特征比对表

---

## 三、 对比文件详细公开性与最接近对比文件分析

### 1. 各对比文件的技术方案与对比分析

#### **对比文件1 (US20080289037A1，简称D1)**

* **解决的技术问题**：解决企业电子邮件通信中敏感/受限信息泄漏的问题，特别是防止用户因疏忽将邮件发送给未经授权的外界接收者。

* **技术方案**：在客户端或服务器端维护白名单（White List）。当用户发送邮件时，系统将邮件的接收者（目的地）与白名单进行比对。如果接收者不在白名单上，系统会提示/询问用户（Prompt/Confirm）是否确定发送。若用户确认，则允许发送。

* **技术效果**：有效防止信息误发泄漏，同时保证合法通信的灵活性。

* **特征公开情况**：D1**完整公开了特征A、B、C、D、E、F、G、H、I、K**。

* **关键区别（差异特征）**：对于**特征J**（将用户允许的服务请求信息添加至可信服务信息/白名单中），D1段落[0056]仅提到了白名单可以通过夜间批处理（nightly batch job）更新，但没有显式揭示“在用户单次验证允许后，系统自动将该服务请求信息（或其一部分）动态添加至白名单/可信服务信息中”。

#### **对比文件2 (WO2009041804A2，简称D2)**

* **解决的技术问题**：解决即时通讯（IM）过程中的安全防护及用户身份认证繁琐的问题。

* **技术方案**：采用智能卡（Smart Card）及数字证书（PKI架构）对客户端与服务器进行双向身份认证，并在认证通过后记录IP地址以建立加密通信通道。

* **技术效果**：实现安全的即时消息传输。

* **特征公开情况**：仅公开了基本的网络架构与请求接收（特征A、B、C的一部分），属于非常常规的网络认证技术。**完全未公开白名单比对（D）、用户二次验证交互（E-I）以及动态添加白名单（J）等核心逻辑**。

#### **对比文件3 (JP2009077031A，简称D3)**

* **解决的技术问题**：解决移动办公计算机在外网连接时容易导致企业内部机密信息泄漏（如通过P2P软件）的问题。

* **技术方案**：由手机（便携通信装置）作为控制中枢，内部存储许可数据（URL白名单）。当移动计算机发起外部连接请求时，手机向网关服务器校验终端合法性，随后比对请求的URL是否在许可数据存储部中。若不在，直接拒绝连接；若在，则放行。

* **技术效果**：严格限制移动终端访问未授权的外部网站，防止信息泄漏。

* **特征公开情况**：公开了特征A、B、C、D、K。

* **关键区别**：D3是一种**静态/严格防范机制**。当URL未列入许可库时，D3的做法是直接拒绝（段落B30：“接続が許可されていないURLの場合...接続拒否応答を返し”），**没有向用户发送验证请求（缺少特征E-I）**，更**没有后续的动态添加白名单机制（缺少特征J）**。

---

### 2. 最接近对比文件的选择

**最接近对比文件：D1 (US20080289037A1)**

* **选择理由**：

1. **技术领域与架构高度重合**：D1与本案均属于网络通信安全控制领域，均采用“白名单比对 + 超出白名单时触发用户确认”的机制。

2. **覆盖特征最多**：D1公开了本案权利要求1中**A、B、C、D、E、F、G、H、I、K共10个技术特征**（占比超90%）。

3. **技术问题与效果契合**：两者均致力于解决“受限通信请求的安全管控与用户灵活授权”这一技术问题。

---

## 四、 无效攻防焦点与最薄弱技术特征分析

基于D1作为最接近对比文件，本案权利要求1的**主要防线与最薄弱技术特征**分析如下：

### 1. 区别技术特征

本案权利要求1相对于D1的区别特征为**特征J**：

> **“如果所述验证信息提供了允许所请求的服务的指示，则向所述可信服务信息添加所述服务请求信息的至少一部分”**（即：用户确认放行后，系统自动/动态将该服务/目的地“学习”并加入白名单）。

### 2. 专利权人可能采取的抗辩路线

专利权人会主张：D1的白名单是静态的或由管理员通过后台批处理（nightly batch job）统一维护的。D1中即使用户点击确认强行发送了邮件，系统也只是“一次性放行”，下次发送给同一非白名单地址时依然会弹窗提示。而本案通过特征J实现了**“基于用户授权的动态白名单自学习功能”**，简化了后续同类请求的审批流程，提高了网络管理效率。

### 3. 无效请求人的突破口与最薄弱特征（特征J）

**特征J是本案权利要求1中最薄弱的技术特征**，其显而易见性（审查指南第22条第3款）极强，理由如下：

1. **公知常识/惯用技术手段叠加**：

在网络安全和防火墙/杀毒软件（如Windows防火墙、360安全卫士、各类邮件网关）领域，“**当未已知程序/地址发起连接时提示用户 -> 用户选择‘允许’ -> 勾选/默认‘记住此操作’并自动加入白名单**”是极其常规、熟知的技术手段。

2. **D1的暗示与教导**：

D1段落[0028]已经提到系统会记录（log）用户的调整行为，以便后续对系统默认设置或白名单进行修改。将“用户确认允许”直接作为触发条件来更新本地/远程白名单数据库，属于本领域技术人员基于提高自动化程度、避免重复弹窗打扰用户这一显而易见的动机，无需付出创造性劳动就能联想到的技术改进。

---

## 五、 进一步对比文件检索策略建议

为了彻底击退特征J（动态添加白名单），形成强有力的结合对比文件（D1 + D4 / 惯用技术手段公知常识证据），建议采取以下补充检索策略：

### 1. 检索要素组合（IPC分类号 + 关键词）

* **IPC / CPC 分类号**：

* `H04L 63/0227` （基于规则或白名单/黑名单的过滤）

* `H04L 63/0263` （动态更新防火墙/安全规则）

* `H04L 63/101` （基于属性/白名单的访问控制）

* `G06F 21/55` / `G06F 21/56` （恶意软件/未授权访问防范与用户交互提示）

* **关键词逻辑表达式**：

* **逻辑组1（白名单/规则）**：`(White list OR Whitelist OR Trust* OR Allowed List OR 信任列表 OR 白名单)`

* **逻辑组2（请求/非白名单触发）**：`(Request OR Access OR Destination OR 未包含 OR 不在列表中 OR Unknown)`

* **逻辑组3（用户确认/提示）**：`(Prompt OR Confirm OR User Interaction OR Verification OR 提示用户 OR 用户确认)`

* **逻辑组4（动态添加/自动更新，即特征J）**：`(Auto* add OR Dynamic update OR Append OR Learning OR Remember OR 自动添加 OR 动态更新 OR 记住选择)`

### 2. 重点检索方向建议

1. **防火墙与网络入侵防御系统（IPS/IDS）专利文献**：

检索2008年以前的个人防火墙专利（如Symantec、McAfee、Kaspersky、ZoneAlarm或趋势科技的专利）。这类产品在遇到未知网络连接请求时，标准的交互就是“允许并记住（Add to trusted zone / whitelist）”。

2. **应用软件权限管理与弹出拦截文献**：

检索移动终端/PC端应用软件在访问受控资源（如网络、通讯录）时的动态授权与权限白名单更新专利。

---

## 六、 总结结论

1. **对比文件公开性**：D1 (US20080289037A1) 已经揭示了本案权利要求1绝大部分核心架构（特征A-I, K）。D2与D3公开程度较低，不适合作为主对比文件。

2. **最接近对比文件**：**D1** 为最接近对比文件。

3. **无效突破口**：权利要求1的**特征J（根据用户允许指示动态添加至白名单）**是唯一的差异特征，也是最薄弱环。

4. **下一步行动**：以 **D1** 为第一对比文件，补充检索一篇揭示“根据用户‘允许’反馈自动将新目标/服务补充入白名单”的防火墙/安全网关类专利（D4），或直接补充教科书/公知常识举证，即可对权利要求1形成极具杀伤力的创造性（或新颖性）无效组合方案。

根据权利要求1所述的方法，其中，所述方法还包括以下步骤；如果所述验证信息提供不允许所请求的服务的指示；则向所述可信服务信息添加所述服务请求信息的至少一部分。

根据权利要求1所述的方法，其中，所述用户验证请求是经由安全通信信道被发送的；以及/或者所述用户验证响应是经由安全通信信道被接收的。

根据权利要求1所述的方法，其中，所述用户验证请求是经由安全通信信道被发送的；并且所述用户验证响应是经由相同的所述安全通信信道被接收的。

根据权利要求1所述的方法，所述方法还包括以下步骤；在所述终端与所述网络之间建立加密的通信信道；经由所述加密的通信信道向所述终端发送用户验证请求；经由所述加密的通信信道来接收用户验证响应；所述响应包括由所述用户提供的、所述用户是接受还是拒绝所述服务请求的验证信息。

根据权利要求5所述的方法，其中所述加密的通信信道是使用所述终端的标识模块中存储的私有密钥被建立的。

根据权利要求5所述的方法，其中，所述终端包括标识模块；一个或多个输入/输出接口；以及一个或多个可信硬件组件；所述可信硬件组件被配置为在所述可信硬件组件与所述标识模块和/或所述一个或多个输入/输出接口之间建立一个或多个可信通信路径。

根据权利要求1至5中任一项所述的方法，其中，所述方法还包括以下步骤；建立与所述网络接收所述服务请求所通过的通信信道不同的另一通信信道；经由安全信道向所述终端发送用户验证请求；以及经由所述另一通信信道来接收用户验证响应；所述响应包括用户是允许还是拒绝所述服务请求的验证信息。

根据权利要求3或4所述的方法，其中，所述安全通信信道由消息发送服务提供。

根据权利要求9所述的方法，其中，所述安全通信信道由短消息服务或USSD服务提供。

根据权利要求1至7中任一项所述的方法，其中，验证请求包括被配置为确定所述用户是否是人的测试；并且其中验证响应包括所述测试是否成功的信息。

根据权利要求11所述的方法，其中，所述测试为反向图灵测试或验证字。

根据权利要求1至7中任一项所述的方法，其中，所述网络包括服务供应网络节点；所述服务供应网络节点包括访问位置寄存器（VLR）；所述访问位置寄存器（VLR）包括可信服务信息；所述网络节点还包括用户验证功能设备；其用于响应于来自终端的服务请求；向所述终端发送不将所述服务请求信息的至少一部分列入所述可信服务信息中的用户验证请求。

根据权利要求13所述的方法，其中，所述网络还包括归属位置寄存器（HLR）；所述归属位置寄存器包括所述终端的可信服务信息；所述方法还包括以下步骤；将可信服务信息从所述归属位置寄存器传送至所述访问位置寄存器。