一种在客户端处执行的方法，包括步骤： 由所述客户端请求被第一云存储服务器认证； 从所述客户端向所述第一云存储服务器发送身份联合请求，其中所述身份联合请求寻求将所述客户端的在所述第一云存储服务器上的用户账户与所述客户端的在第二云存储服务器上的用户账户联合； 将所述客户端从所述第一云存储服务器重定向到所述第二云存储服务器； 由所述客户端请求被所述第二云存储服务器认证，以使得所述第二云存储服务器在所述客户端被认证后，将所述第一云存储服务器上的所述用户账户与所述第二云存储服务器上的所述用户账户进行映射并且在它们之间建立身份联合；以及将所述客户端从所述第二云存储服务器重定向到所述第一云存储服务器； 其中所述步骤中的一个或多个步骤是由处理设备执行的。

这份权利要求涉及一种通过客户端重定向机制在两个独立服务器之间建立账户关联的技术。分析其有效性需要严谨拆解其流程节点。

### 权利要求解释与说明书结合分析

权利要求1要求保护一种在客户端执行的方法，其核心在于通过**前端重定向（Front-channel redirection）**机制在两个不同的云存储服务器之间建立身份联合（Identity Federation）。

结合目标专利说明书（特别是[0028]-[0050]段落及图2），该方案的技术脉络非常清晰：

1. **起点**：客户端登录“从UCD服务器”（即权利要求中的第一云存储服务器）。

2. **触发**：客户端明确发出 `IdentityFederationRequest`，该请求携带了需要绑定的从服务器账户和主服务器账户信息（对应技术特征B）。

3. **流转**：从UCD服务器不直接与主UCD服务器进行后台通信，而是通过HTTP 302状态码将客户端**重定向**至主UCD服务器（即权利要求中的第二云存储服务器）（对应技术特征C）。

4. **映射**：主UCD服务器对用户进行认证后，在本地记录两个账户的映射关系，完成联合（对应技术特征D）。

5. **回归**：主UCD服务器再次将客户端重定向回从UCD服务器，完成闭环（对应技术特征E）。

该发明的核心逻辑是**利用客户端作为信息传递和鉴权的桥梁**，避免了沉重的后台协议规范（如Liberty Alliance），实现轻量的身份联合。

---

### 对比文件特征比对与分析

以下是D1（US20130340062A1）和D2（JP2013137588A）对权利要求1各技术特征的公开情况比对表。为了方便对应结构，将D2中的 Service Provider (SP) 视为第一服务器，ID Provider (IDP) 视为第二服务器。

---

### 最接近的对比文件分析

在创造性分析中，**D2 (JP2013137588A) 最适合作为最接近的对比文件**。

* **从解决的技术问题与技术领域来看**：D2与目标专利均致力于解决跨域单点登录（SSO）场景下，如何在没有提前建立账户关联的情况下，动态完成账户身份的联合/绑定机制。

* **从技术效果与整体架构来看**：D2采用了与目标专利高度一致的**前端重定向架构（Front-Channel Architecture）**。D2完整地公开了“客户端 -> 访问服务器1 -> 被重定向至服务器2 -> 服务器2鉴权并执行账户映射 -> 被重定向回服务器1”这一核心流转闭环。

* **排除D1的理由**：尽管D1公开了映射配置（SSO mapping）的核心概念，但D1采用的是**后端服务器间直接通信**（Server-to-Server API）的技术手段（见D1段落[0085]）。若以D1为起点，要求本领域技术人员将其后端通信架构彻底重构为目标专利的前端重定向架构，跨度过大，极易在答辩中被专利权人以“缺乏技术启示”或“事后诸葛亮”成功反驳。

---

### 无效请求中最薄弱的技术特征及攻击策略

若基于上述文件提出无效请求，权利要求1最薄弱的技术特征是 **特征B（客户端主动发送专门的身份联合请求）** 以及 **“云存储服务器”这一应用场景限定**。

针对这两部分未被D2直接公开的特征，可以构建如下严密的组合攻击逻辑：

1. **关于“云存储服务器”的应用场景限定**：

这属于现有技术中极其常见的商业场景替换。D2在段落[0003]和[0023]中明确指出了其应用场景包含 **SaaS (Software as a Service)**。云存储（例如各类企业网盘）本身就是SaaS的一种标准和普遍形态（Storage-as-a-Service）。本领域技术人员将D2的鉴权系统平移应用于云存储场景，无需付出任何创造性劳动。

2. **关于特征B（显式发送身份联合请求）**：

* **区别点**：D2的逻辑是用户仅点击“服务请求”，系统后台自动发现未绑定，从而触发联动和新账户生成；而目标专利是客户端显式地发送一个包含双边账户信息的“身份联合请求”来绑定已有账户。

* **引入D1作为辅助证据**：D1在段落[0081]-[0082]中明确教导了“用户可以主动向系统提供映射关系（例如上传映射文件）”，即主动发出将特定IdP账户与SP账户进行联合的请求。

* **结合启示**：当本领域技术人员在实施D2的架构时，若面临“如何允许用户主动指定想要绑定的两个现有账户，而不是仅由系统单向自动生成新账户”这一常规技术需求时，拥有绝对的动机去借鉴D1的教导。在D2重定向流程的初始阶段，让客户端先发送一个明确的身份联合请求，仅仅是前端UI交互设计与标准身份协议参数的常规功能拼接。

**无效宣告策略总结**：以 **D2为主证 + D1为辅证 + 本领域公知常识（云存储作为SaaS的标准形态）** 的组合，能够形成逻辑闭环，有极高概率成功覆盖并无效掉权利要求1的全部技术特征。

您好，我是您的专利代理师。现紧密结合目标专利**CN106415519B**（以下简称“本专利”或“目标专利”）的说明书，对您提供的权利要求1进行深入解析，并结合四篇对比文件原文进行详细的特征比对、创造性分析（最接近对比文件选择及结合分析），并指出无效请求中最薄弱的技术特征。

---

### 第一部分：目标专利权利要求1的代理师解析

**权利要求1：**

> 一种在客户端处执行的方法，包括步骤：

> * (A) 由所述客户端请求被第一云存储服务器认证；

> * (B) 从所述客户端向所述第一云存储服务器发送身份联合请求，其中所述身份联合请求寻求将所述客户端的在所述第一云存储服务器上的用户账户与所述客户端的在第二云存储服务器上的用户账户联合；

> * (C) 将所述客户端从所述第一云存储服务器重定向到所述第二云存储服务器；

> * (D) 由所述客户端请求被所述第二云存储服务器认证，以使得所述第二云存储服务器在所述客户端被认证后，将所述第一云存储服务器上的所述用户账户与所述第二云存储服务器上的所述用户账户进行映射并且在它们之间建立身份联合；以及

> * (E) 将所述客户端从所述第二云存储服务器重定向到所述第一云存储服务器；

> * (F) 其中所述步骤中的一个或多个步骤是由处理设备执行的。

**代理师对权利要求的解析（结合说明书）：**

1. **技术领域与背景：** 本专利属于云存储安全领域，特别涉及统一云盘（Unified Cloud Disk, UCD）架构下的身份管理。背景技术（说明书[0005]-[0006]）指出，由于不同云存储服务提供商使用不同的应用编程接口(API)，导致移动用户访问困难。OMA提出了UCD方法尝试解决API异质性问题。本专利的说明性实施例（[0007]）尤其适用于UCD架构，旨在提供安全的统一云存储技术。

2. **核心术语解释：**

* **客户端：** 说明书[0021]定义为被编程/配置为终端用户执行功能的软件/硬件。在UCD示例中，指代“UCD客户端”（[0011]）。

* **第一云存储服务器/第二云存储服务器：** 说明书[0021]定义为响应用户请求执行功能的软件/硬件。在UCD示例中（[0011]、[0028]），**第一服务器**对应“从UCD服务器”，**第二服务器**对应“主UCD服务器”（主UCD服务器具有身份提供方IdP功能，负责注册主UCD账户并发布标识信息）。

* **身份联合（Identity Federation）：** 说明书[0025]定义为允许用户将针对每个服务提供方创建的本地“身份”进行联合（链接、连接或结合）。联合的身份允许用户登入一个服务器即可点击关联的服务提供方。本专利寻求在UCD环境下提供改进的（轻量化、减少沉重开销）身份联合管理（[0026]）。

3. **方法流程的说明书对应（如图2所示流程）：**

* **步骤A（由所述客户端请求被第一云存储服务器认证）：** 对应说明书图2步骤1和1.1-1.2（[0032]-[0034]），用户请求登入从UCD服务器（第一服务器），若未认证，则客户端回复用户认证信息。

* **步骤B（从所述客户端向所述第一云存储服务器发送身份联合请求...）：** 对应说明书图2步骤3（[0037]-[0038]），UCD客户端向从UCD服务器（第一服务器）发送IdentityFederationRequest，寻求将从用户账户与主用户账户联合。示例格式包括主、从服务器的用户ID及URI。

* **步骤C（将所述客户端从所述第一云存储服务器重定向到所述第二云存储服务器）：** 对应说明书图2步骤5（[0040]），从UCD服务器（第一服务器）使用RegisterNameIdentifierRequest消息（状态代码**302**的HTTP消息）将UCD客户端**重定向**到主UCD服务器（第二服务器）。

* **步骤D（由所述客户端请求被所述第二云存储服务器认证，以使得...映射并且...建立联合）：** 对应说明书图2步骤5.1-5.3（认证，[0042]-[0045]）和步骤6（记录，[0046]）。客户端对主服务器作出回复（认证信息），主服务器（第二服务器）对用户认证。认证后，主UCD服务器记录联合信息（即映射从用户账户和主用户账户，从而在它们之间建立身份联合）。

* **步骤E（将所述客户端从所述第二云存储服务器重定向到所述第一云存储服务器）：** 对应说明书图2步骤7（[0047]），主UCD服务器（第二服务器）使用RegisterNameIdentifierResponse消息（状态代码**302**的HTTP消息）将UCD客户端**重定向**到从UCD服务器（第一服务器）。消息中包括SSO令牌和服务器身份等，用于确认。

4. **技术效果：** 结合说明书图2和具体实施方式，该权利要求通过由客户端中介的特定的重定向流程（第一 -> 第二（映射） -> 第一），实现在统一云存储环境（如UCD）中，在不具备直接安全协定的服务器之间安全地建立用户账户的身份联合映射，克服了传统规范对UCD架构施加的沉重开销负担（[0026]），提供了轻量化的改进方法。

---

### 第二部分：对比文件技术特征详细特征比对表格

为了清晰展示各对比文件（D1-D4）是否公开权利要求1的技术特征，现给出详细特征比对表格。

**本案使用的对比文件指代：**

* **D1：** 2006-09-28_US2006218628A_Method and system for enhanced federated single logout.docx

* **D2：** 2010-12-23_US2010325199A_CLIENT, BROKERAGE SERVER AND METHOD FOR PROVIDING CLOUD STORAGE.docx

* **D3：** 2011-06-22_EP2336886A_Cloud federation as a service.docx

* **D4：** 2011-06-30_US2011161291A_WAN-OPTIMIZED LOCAL AND CLOUD SPANNING DEDUPLICATED STORAGE SYSTEM.docx

<br>

<br>

---

### 第三部分：创造性分析中的最接近对比文件选择及原因

在进行本专利权利要求1的創造性分析时，我作为代理师认为：**D3（2011-06-22_EP2336886ACloud federation as a service.docx）**适合作为最接近的对比文件。

在对比分析时，**可以有多个最接近对比文件**（本案中，虽然 D1 的重定向机制最契合权利要求，但从整体解决问题的角度，D3 更契合）。从技术领域和解决的技术问题整体来看，理由如下：

1. **整体解决的技术问题契合：**

* **目标专利**寻求在统一云存储架构下（例如异构UCD服务器之间），解决服务器之间缺乏直接协定时，如何安全建立轻量化的账户联合（映射）管理，以克服异质API导致的访问困难，特别是克服自由联合计划（Liberty Alliance Project）规范沉重开销的问题（本专利说明书[0005]、[0025]-[0026]）。

* **D3**也明确公开了旨在解决用户订阅多个不兼容云服务提供商（异构Clouds）带来的账户管理复杂性问题（无"一站式"透明利用多个厂商的产品、Proprietary environment/[0006]）。其解决方案核心是通过**Cloud Federator 106/308/408（实质对应为所述“第一云存储服务器”）**提供**通用身份联合客户配置文件（federated customer profile）**（[0007]、[0009]），跨多个服务和厂商实施 brokerage，使用户能够无缝接入互不兼容的Clouds（实质对应为所述“第二云存储服务器”）。

* **D1**虽然在特征C和E上与本专利公开的HTTP 302重定向机制最吻合（增强单点登出背景下的浏览器中介机制，[0161]-[0163]），但其旨在解决的整体问题是在已经建立联合的情况下，**单点登出（Single Logout）**操作的恢复、确认和用户通知状态反映（[0010]-[0012]、[0154]、增强 SLO，[0158]）。其并不主要旨在在缺乏直接协定的异构 Clouds 服务器账户之间**安全建立（establish）联合映射关系**这一特定阶段。其阶段和所解决之核心联合机制差异较大。

2. **技术效果的一致性：**

* 目标专利实现的技术效果是在不具备直接安全协定的第一服务器（Slave）和具备IdP功能的第二服务器（Master）之间，通过客户端特定的重定向交互，安全且轻量化地完成本地账户到主账户的映射（联合），避免自由联盟计划的沉重开销，提供改进的身份联合管理方案。

* D3实现的技术效果同样是跨域身份信息交换机制（[0009]），使 Client能够不依赖各 CloudsProprietary环境和配置文件即可 seamless 无缝访问不兼容 Clouds（[0012]、图1、图2），实现身份联合配置。二者均旨在提高联合管理之无缝性和开销改进。

3. **技术特征涵盖度：** 从整体比对看，目标专利的核心技术，即基于特定的客户端中介流程，建立异构云服务器（例如异构 UCD 厂商）之间的身份联合映射，这一概念在 D3 中以“universal customer profile federation service implements cross-domain single sign-on”（通用配置文件联合服务执行跨域 SSO）的形式被实质公开（Feature B, D）。D3 是唯一专注于建立这种 Cloud 服务器对服务器之身份联合的引证技术文件。D1 的 SLO 流程属于建立联合**后**的操作，D2 属于接口代理转换中介（中介代理模式非重定向中介模式），D4 属于去重优化，领域差异过大。

综上所述，虽然D1提供了具体的HTTP重定向步骤实现细节之教导（Feature C, E），但从技术背景、核心问题整体解决途径以及技术效果来看，**D3 是最密切相关的文件，适合作为创造性分析的起点（主要最接近对比文件）**。

因此，**主要的创造性结合逻辑**应为：从最接近文件D3出发，其虽然公开了 Cloud Federator（第一服务器）旨在跨多个异构 Clouds 服务实施通用的配置文件联合管理，但未公开特定的客户端重定向交互（第一 -> 第二重定向 -> 认证（映射建立联合） -> 第一重定向）的具体交互流程 Feature B 的请求细节、C（重定向机制）、E（重定向机制），而将重定向机制应用在联合计算环境以进行服务器之间基于浏览器中介通信之教导（特别是 Feature C, E 所需之 302 状态代码和 Location 头机制）在引证文件**D1（Enhanced Federated SLO, [0161]）**中被明确教导。对于本领域技术人员来说，面对D3改进身份联合管理的透明和无缝性问题，由于OASIS SAML规范是跨域SSO（[0009]）的惯用方案且使用重定向模式绑定，因此结合 D1 具体的重定向机制来改进 D3 管理器与 Clouds 服务器之间的账户/配置文件联合映射的具体实施，属于惯用技术手段结合，不具备创造性。

---

### 第四部分：无效请求中最薄弱的技术特征

在如果对本权利要求1发起无效请求，可以预见专利权人会极力主张本权利要求的创造性，主张将多个重定向交互步骤、认证（建立映射联合）特定顺序以及应用于“云存储服务器用户账户”建立联合这一特定环境的结合。

代理师认为，本权利要求1中**最薄弱（最容易被现有技术攻击）**的技术特征（步骤）：

* **隐含的技术特征A（由客户端请求被第一服务器认证）：** 如特征比对表格所述，由客户端访问任何受保护的服务器，都隐含“请求认证”的过程（隐含惯用技术手段）。现有技术D1、D3均实质公开 IdP/Federator 认证云客户端。属于显而易见的。

* **特征F（步骤由处理设备执行）：** 权利要求描述的是一系列由处理设备（处理器/内存）执行的方法步骤（ Feature A-E均依赖处理器和内存系统图6公开，[0022]、[0023]），这属于一般基于网络通讯的方法权利要求的常规撰写形式。特征本身不包含任何技术细节（惯用常规处理器执行惯用常规网络通讯，例如 HTTPS 网络和 TLS 规范，D1[0016]、说明书[0051]、[0097]），对创造性的贡献非常小。属于隐含的常规技术组件。

* **实质的步骤A（如果单独看）：** 由客户端请求认证，在基于浏览器的 SSO 方案中广泛存在。

综上所述，无效请求应主张由客户端访问认证（A）以及特征（F）属于惯用手段。

而对于真正的实质无效结合逻辑（Feature B-E），最薄弱的结合攻击路径在于将 D3 专注于云服务器账户/配置文件联合、跨域身份映射的技术目标与 D1 公开的基于 HTTP 重定向（302机制）在服务器之间进行通讯的具体实施方式（虽用于 SLO 背景下但机制相同、D1 [0161]-[0163]公开由 IdP 重定向到 SP，再由 SP 重定向到 IdP）结合。

最可能被判定为不具备创造性的无效论点结合为：**D3 结合 D1 并隐含公开/惯用。最薄弱部分在于 D3 的跨域身份映射方案隐含需要 D1 公开的浏览器绑定（重定向模式）交互。** Feature F 则是该结合下的常规处理器实现。

您好。我是经验丰富的专利代理师，现结合目标专利说明书（授权公告号：CN106415519B）对权利要求1进行深入解析，并结合您提供的四份对比文件原文进行详细的特征比对、创造性分析，并指出若提出无效请求最薄弱的技术特征。

以下是详细的分析报告。

---

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

紧密结合目标专利说明书CN106415519B的背景技术[0005]-[0006]以及具体实施方式[0021]-[0023]、[0037]-[0050]（对应图2），权利要求1保护的是一种在**客户端（UCD客户端）**处执行的身份联合方法，旨在解决异构云存储服务API不同导致的访问复杂性问题，通过在两个云存储服务器之间建立账户映射，实现统一、安全的云存储访问。

我们将权利要求1分解为以下逻辑独立的技术特征，以便后续比对：

* **特征1-前序：**一种在客户端处执行的方法，其一个或多个步骤是由处理设备执行的。

* **特征1-A（步骤1）：**由所述客户端请求被第一云存储服务器认证。

* **特征1-B（步骤2）：**从所述客户端向所述第一云存储服务器发送身份联合请求，其中所述身份联合请求寻求将所述客户端的在所述第一云存储服务器上的用户账户与所述客户端的在第二云存储服务器上的用户账户联合。

* **特征1-C（步骤3）：**将所述客户端从所述第一云存储服务器重定向到所述第二云存储服务器。

* **特征1-D（步骤4）：**由所述客户端请求被所述第二云存储服务器认证，以使得所述第二云存储服务器在所述客户端被认证后，将所述第一云存储服务器上的所述用户账户与所述第二云存储服务器上的所述用户账户进行映射并且在它们之间建立身份联合。

* **特征1-E（步骤5）：**将所述客户端从所述第二云存储服务器重定向到所述第一云存储服务器。

---

### 第二部分：对比文件特征比对与分析

我们将针对每一份对比文件（D1-D4），分析其是否毫无异议公开或实质公开了上述权利要求1的技术特征，并给出原文详细出处。

#### 1. 对比文件1 (D1): US2011161723A1

**公开号：** US2011/0161723 A1

**主题：** 使用本地和跨云去重存储系统的灾难恢复。

**D1 分析结论：** D1属于完全不同的技术领域（数据去重存储与灾难恢复），未公开权利要求1有关身份联合、重定向及账户映射的核心认证流程特征。

#### 2. 对比文件2 (D2): WO2011080063A1

**公开号：** WO2011/080063 A1

**主题：** 平台间迁移虚拟机镜像。

**D2 分析结论：** D2涉及虚拟机镜像迁移，虽然处理多云环境，但在方法执行主体（非客户端）以及具体技术实现路径（非基于重定向的身份联合流程）上与本专利存在本质区别。

#### 3. 对比文件3 (D3): WO2011082123A1

**公开号：** WO2011/082123 A1

**主题：** WAN优化的本地和跨云去重存储系统。

该文件与D1（US2011161723A1）属于同一族（Claims priority to... 61/315,392... 61/290,334），其摘要、说明书内容（包括图1-7及对应文字描述）与D1高度重合。

**比对分析：**

基于对D1的分析，D3同样公开了处理平台600和计算机系统2000（对应前序特征），但其核心技术仍聚焦于数据的块级去重、WAN优化传输、本地缓存策略以及利用多个云存储进行灾难恢复。

D3**未毫无异议公开也未实质公开**技术特征1-A至1-E，即没有公开基于客户端的、涉及从第一云服务器到第二云服务器的重定向、并在第二云服务器上执行认证后建立两服务器间用户账户映射的身份联合全流程。

#### 4. 对比文件4 (D4): US2011276713A1

**公开号：** US2011/0276713 A1

**主题：** 用于局域网存储设备和云存储系统之间接口的云连接器。

**D4 分析结论：** D4解决的是将本地NAS集成到多云存储中的问题，使用了统一云协议网关（云连接器）的技术路径。虽然其涉及多云提供商，也隐含凭证管理，但并未公开本专利基于客户端重定向和服务器间主动建立账户映射的“身份联合”特定流程。

---

### 第三部分：最接近对比文件的分析与选择

在创造性分析中，选择“最接近的对比文件”应考虑其解决的技术问题、采用的技术方案以及技术效果与目标专利的契合度。

基于上述比对，**没有任何一个对比文件在整体技术方案上接近本专利申请权利要求1。**

1. **D1/D3（灾难恢复/去重）：** 聚焦数据物理存储层面的优化，与身份管理、统一安全访问技术领域相距较远，不适合做最接近对比文件。

2. **D2（VM镜像迁移）：** 聚焦虚拟机镜像在异构云间的兼容性和迁移，执行主体非客户端，技术路径非重定向鉴权。虽然提及多云和凭证，但整体架构差异巨大，不适合做最接近对比文件。

3. **D4（云连接器网关）：** 虽然D4也属于“云存储”领域，且解决的问题包含“从客户端访问多个异构云存储系统”（与本专利背景技术[0005]、[0006]提到的 API异质性导致访问困难的问题有一定相关性），但其采用的技术方案是设置一个**服务器端/网关端的“云连接器310”**来进行协议翻译和路由（[0034]），从而对客户端屏蔽异构性。

* **目标专利的解决技术问题：** 在统一云盘（UCD）架构下，如何**在客户端、主/从服务器之间利用标准且安全的身份联合流程**（针对自由联盟计划开销沉重进行改进，见本专利说明书[0026]），通过账户映射解决API异质性访问问题。

* **目标专利的核心方案：** 客户端参与的、基于重定向（HTTP 302）在异构服务器间建立账户映射的流转过程（图2）。

* **对比：** D4解决API屏蔽的方式与本专利基于认证流转建立映射的方式完全不同。因此，即使D4领域较近，其技术方案和技术效果也相差甚远。

**结论：如果您必须选择一个，D4勉强可以被视为技术领域、技术问题上最接近的文件，但由于技术路径的巨大差异（网关协议翻译 vs 基于重定向的身份映射），其本身并不适合作为创造性分析中的起步文件。本案中，可以认为没有合适的、能够提供本专利技术方案主要特征的“最接近对比文件”。**

### 第四部分：最薄弱的技术特征指出

结合目标专利说明书和权利要求1，如果需要对其提出无效请求，**最薄弱的技术特征**在于：

**特征1-C/1-E 与 1-D 的结合：基于从第一云服务器到第二云服务器的重定向（Redirect）在客户端参与下完成账户映射和身份联合建立。**

**理由如下：**

1. **现有技术基础：** 在身份鉴权领域，**基于Web的单点登录（SSO）和身份联合技术（如SAML, OAuth 2.0, 以及专利提及的 Liberty Alliance Project）早已属于成熟的现有技术（本专利背景技术[0025]已承认）**。这些技术标准的核心机制就是利用浏览器/客户端在Service Provider（SP）和Identity Provider（IdP）之间进行重定向（通常通过 HTTP 302 响应），从而在不直接向SP暴露用户凭证的情况下完成鉴权和会话建立。

2. **本专利的调适：** 本专利说明书[0027]也明确承认，实施例提供了“对自由联合计划（Liberty Alliance）的身份联合消息中的一些**经调适（adapted）**方面加以利用”的方法，并指出可替换实施例可以不需要这种具体的特定消息（[0027]）。

3. **创造性层面的考虑：** 权利要求1将这种通用的、早已在互联网身份验证领域广泛应用的“基于重定向的联合鉴权流转”应用于“统一云存储（UCD）”这一特定的垂直场景，并将流转的**目的（技术效果）**限定为“将第一云存储服务器上的用户账户与第二云存储服务器上的用户账户进行**映射**并且建立身份联合”。

对于本领域技术人员而言，当面临如何利用身份联合技术在两个已存在的异构云存储服务（UCD主/从服务器，说明书[0011]）之间建立安全连接的问题时，**将成熟的、基于重定向的SSO/联合鉴权标准流程引入云存储API认证流程中，以完成账户映射和联合会话建立，其本身是一种常规、显而易见的技术迁移。**

**总结无效策略：**

虽然提供的D1-D4均未具体公开该重定向流程，但无效请求人可以通过寻找身份管理/Web鉴权领域的其他通用现有技术（例如 Liberty Alliance 1.2规范原文，或SAML 1.1/2.0标准，均为2009年前公开），证明该特定鉴权流转流程属于通用惯用手段。然后，结合D4这样公开了多云环境凭证管理的文件，主张将通用重定向鉴权流程应用于多云存储账户映射属于常规选择，不具备创造性。

你好！针对这份目标专利（安全的统一云存储）及提供的四篇对比文件，我为你进行详细的侵权/无效分析。我们直接切入正题，从权利要求解释、最接近现有技术（CPA）的确定、特征比对，到无效策略中的薄弱点进行逐层拆解。

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

在进行新颖性和创造性比对之前，必须紧密结合目标专利说明书（CN106415519B）对权利要求1的保护边界进行明确：

* **技术背景与问题**：该专利旨在解决不同云存储服务提供商之间API异质性的问题，通过“统一云盘 (UCD)”架构实现多云存储的统一访问。

* **身份联合 (Identity Federation)**：结合说明书[0025]段，身份联合是指允许用户将针对不同服务提供方创建的本地“身份”（账户）进行链接。

* **交互逻辑（核心保护点）**：结合说明书[0028]-[0042]段（对应图2的流程），权利要求1限定了一种特定的网络交互时序：客户端登录**第一云存储服务器**（说明书中的“从UCD服务器”），发起联合请求；随后，第一云存储服务器不直接进行后台映射，而是**将客户端重定向 (Redirect)** 到**第二云存储服务器**（说明书中的“主UCD服务器”）；在第二云存储服务器处对用户进行认证，并由**第二云存储服务器**记录联合信息（账户映射）；最后再次**重定向回**第一云存储服务器。

### 二、 最接近的对比文件 (CPA) 确定

在创造性分析中，确定最接近的对比文件（CPA）通常需要寻找与目标专利技术领域相同、解决的技术问题最相近、且公开技术特征最多的文献。

* **D1 (DE112010004160T5) & D2 (CN102725733A)**：这两篇是同族专利，涉及在不同云计算环境之间移植虚拟机映像（VM Porting），解决的是底层虚拟机格式兼容和部署问题，完全未涉及用户账户的身份联合与单点登录认证。

* **D3 (US20120297472A1)**：涉及单点登录 (SSO) 以及跨服务的 SSO 映射设置。其解决的技术问题正是多服务间的认证协作与账户绑定，技术领域和整体解决的技术问题与目标专利高度一致。

* **D4 (US20120303736A1)**：涉及分布式云环境中的数据安全，核心在于云存储代理将数据文件切片并根据规则分散存储到不同服务器，不涉及账户的身份联合机制。

**结论**：从整体解决的技术问题（实现不同系统间的身份认证协作与账户映射）以及技术效果角度来看，**D3 (US20120297472A1) 毫无异议是唯一适合作为最接近的对比文件 (CPA)**。

### 三、 权利要求1与对比文件的特征比对与出处

下面以 D3 (US20120297472A1) 为主，建立权利要求1的技术特征比对表：

### 四、 区别技术特征及其他对比文件分析

通过上述比对，权利要求1相对于 CPA (D3) 的**区别技术特征为：特征C、特征D的部分（由第二服务器建立映射）以及特征E。**

其实质在于**网络拓扑交互逻辑的差异**：

* **D3的逻辑（集中代理模式）**：第一服务器 (Service A) 充当代理，客户端把两边的账号密码都交给第一服务器，由第一服务器在后台走 API 跟第二服务器确认，然后把映射关系记录在第一服务器自己这里。

* **目标专利的逻辑（端到端重定向模式）**：第一服务器不触碰第二服务器的密码，而是利用 HTTP 重定向 (302状态码等) 把客户端踢给第二服务器，在第二服务器的地盘完成认证，并由第二服务器记录映射，再重定向回来。

**其他对比文件是否公开了上述区别技术特征？**

* **D1/D2** 和 **D4** 均属于完全不同的技术分支（VM调度与存储碎片化）。通读全文，没有任何段落提及在身份联合过程中“第一服务器将客户端重定向至第二服务器认证并由第二服务器建立映射”的技术手段。

* 因此，区别技术特征未被提供的其他对比文件公开，也不属于本领域公知常识的简单拼凑。

### 五、 若提出无效请求最薄弱的技术特征

如果你正处于代理该专利的无效宣告请求方（进攻方）的立场，你需要面对一个非常棘手的现实：**特征C、D、E的联动机制是你提无效的最薄弱环节（即专利权人最坚固的护城河）。**

具体分析如下：

1. **无法通过现有证据链结合克服**：D3 虽然解决了相同的问题，但它采用的“代理API”机制与目标专利的“重定向 (Redirect)”机制在计算机网络安全和身份管理领域是两条平行的技术路线。这就像“代客泊车”和“自己开车去别的停车场验证”的区别。

2. **技术效果的差异明显**：目标专利采用重定向由第二服务器主导认证和映射，其技术效果是第一服务器不需要收集和存储用户在第二服务器的敏感凭证（避免了D3中客户端把 Service B 的密码交给 Service A 的安全风险）。这种安全性提升使得该区别特征具有显著的进步。

**实务建议**：若要真正打掉这个专利的权利要求1，仅凭 D1-D4 是远远不够的。你必须跳出这四篇文件，去检索早于 2012 年（由于本专利可能是较早申请的延续或类似技术的改进，需关注优先权日）的 **SAML 2.0、OAuth 1.0/2.0 或 Liberty Alliance Project** 的原始标准文档或相关专利。因为“重定向至 IdP 进行认证再跳回 SP”是典型的 SAML/OAuth 标准流程，找到揭示该标准流程用于“账户联邦 (Account Linking/Federation) 初始化”的对比文件，将其与 D3 结合，才是摧毁该专利权利要求1创造性的唯一出路。

这份分析报告将紧密结合目标专利说明书（CN106415519B）的实施例，对权利要求1进行解构，并使用提供的对比文件（D1-D4）进行详细的新颖性和创造性比对分析，以确定无效宣告请求的突破口。

### 一、 结合说明书对权利要求1的解释

目标专利的核心在于提供一种安全的统一云存储（UCD）架构中的“身份联合（Identity Federation）”机制。根据说明书的具体实施方式（特别是图2及相关描述），权利要求1保护的是一种在客户端执行的身份联合交互流程：

* **第一云存储服务器与第二云存储服务器**：对应说明书中的“从UCD服务器”和“主UCD服务器”。

* **身份联合的目的**：解决跨不同云存储服务提供商时的账号统一问题。将用户在从服务器上的账户与主服务器上的账户进行链接（映射）。

* **重定向机制（Redirection）**：客户端并非直接在后台完成联合，而是通过HTTP重定向技术（如说明书中状态代码302的HTTP消息），在第一服务器和第二服务器之间跳转，携带身份标识符完成认证和联合信息的记录。

### 二、 最接近的对比文件（CPA）的确定

在提供的四份对比文件中：

* **D2 (US20130007867A1)** 与 **D3 (WO2013002886A1)** 为同族专利，内容实质相同，以下分析以D2为代表。

* **D1 (JP2012243027A)** 涉及SSO（单点登录）映射，但其具体发明点在于通过服务器间的API获取ID列表进行比对，以防止跨租户的错误映射（如图7所示的服务器后端交互），并未详细公开权利要求1中通过客户端“重定向”来建立身份联合的具体交互步骤。

* **D4 (CN103023993A)** 涉及一种基于云计算的企业信息系统架构，仅在宏观层面提及了统一认证（如段落[0096]），未公开具体的身份联合和重定向技术细节。

**结论**：**D2 (US20130007867A1)** 最适合作为最接近的对比文件。

* **解决的技术问题**：D2同样致力于解决网络客户端访问SaaS（软件即服务，说明书中明确云存储是一种SaaS）时的跨域身份认证和访问控制问题。

* **技术效果**：D2通过在SaaS服务器（服务提供方）和身份认证服务器（身份提供方）之间通过重定向（HTTP redirect）机制传递SAML断言，实现了安全的单点登录和身份验证，与目标专利利用重定向实现身份联合的技术逻辑和效果高度重合。

### 三、 权利要求1与D2 (US20130007867A1) 的特征比对表格

以下分析将D2中的 SaaS server 110 对应为“第一云存储服务器”，Identity authentication server 120 对应为“第二云存储服务器”。

### 四、 其他对比文件对区别特征的公开情况分析

**权利要求1相对于D2的区别技术特征在于：**

特征B中，客户端向第一云存储服务器发送的明确是**“身份联合请求”**，且目的明确为**“寻求将所述客户端的在所述第一云存储服务器上的用户账户与所述客户端的在第二云存储服务器上的用户账户联合”**。

**其他对比文件是否公开了该区别特征：**

* **D1 (JP2012243027A)**：D1在背景技术[0003]中提到了ID的对应关系被称为“SSO映射（シングルサインオンマッピング）”。虽然D1涉及账户映射（将Service A的ID与Service B的ID关联），但D1的方案（如段落[0026]及图7流程）是用户直接在Service A（第一服务器）输入Service B（第二服务器）的ID和密码，由Service A在后台去拉取ID列表并进行自动比对设定。D1并未公开“由客户端发送身份联合请求，并通过在两个服务器间重定向客户端来完成账户联合”的整体联动过程。

* **D4 (CN103023993A)**：未提供具体的用户账户联合报文或机制，无相关公开。

### 五、 若提出无效请求，最薄弱的技术特征及策略建议

在创造性分析和无效宣告请求中，**权利要求1最薄弱的技术特征是“特征C、D、E所构成的重定向交互逻辑”**。

**无效策略分析：**

1. **重定向逻辑已被D2实质公开**：目标专利极力主张的贡献在于客户端在主从云服务器之间的来回“重定向（Redirect）”过程。然而，正如比对表格所示，D2（段落[0028]-[0030]）已经完整、清晰地公开了SaaS服务器重定向客户端至身份认证服务器，身份认证服务器认证并关联身份后，再将客户端携带断言导回SaaS服务器的完整SAML（Security Assertion Markup Language）重定向交互流。

2. **公知常识的结合**：对于区别特征（特征B：发送寻求账户联合的“身份联合请求”），在联邦身份管理（Federated Identity Management）和SAML 2.0/Liberty Alliance标准中，将不同服务提供商处的独立账户进行绑定（Account Linking / Identity Federation）是本领域技术人员熟知的常规技术手段。D1（[0003]）也印证了在不同服务之间建立ID映射以实现SSO是领域内的已知需求。

3. **论理主线**：D2已经公开了通过客户端重定向进行跨域身份验证的基础架构。为了实现两个具体云存储账户的长期绑定（即D1中提到的SSO映射需求），本领域技术人员有动机在D2的初始访问请求中加入明确的“联合账户”指令（即特征B），这仅仅是本领域常规业务逻辑在SAML/HTTP重定向标准协议上的具体应用，未产生预料不到的技术效果。权利要求1不具备创造性。

这是一份针对目标专利（安全的统一云存储，CN106415519B）权利要求1，结合您提供的四篇对比文件进行的详细侵权/无效比对分析意见。

为了行文简洁与专业，以下将对比文件进行如下编号：

* **D1**: TW201338494A (云端认证系统及方法)

* **D2**: CN103583030A (在分布式云计算环境中实现数据安全性的方法及装置)

* **D3**: EP2716006A1 (D2的同族EP专利，技术内容与D2一致，后续分析将D2/D3合并考虑)

* **D4**: JP2013250875A (SYSTEM, CONTROL METHOD AND PROGRAM / SSOマッピング)

### 一、 紧密结合说明书的权利要求1解释

目标专利的核心在于解决UCD（统一云盘）架构下，跨不同服务提供方的云存储系统时的身份联合（Identity Federation）问题。

根据说明书 `[0008]` 段及 `图2` 的记载，权利要求1所保护的是一种**基于客户端重定向（Client Redirection）的身份联合机制**。其核心逻辑是：客户端不需要把“第二云存储服务器”的账号密码直接交给“第一云存储服务器”来做后台绑定（这存在安全隐患），而是由第一服务器将客户端**重定向（Redirect）**到第二服务器，由客户端直接向第二服务器进行认证。第二服务器认证通过后，在后台建立两个账户的映射（联合），然后再将客户端重定向回第一服务器。这种机制类似于标准的OAuth 2.0或SAML中的重定向授权流，保证了不同云存储服务商之间不直接接触对方的用户敏感凭证。

---

### 二、 对比文件技术特征比对与分析

#### 1. 各对比文件公开情况概述

* **D1 (TW201338494A)**：公开了一种集中式的云端认证系统（通过第三方“认证云3”统一发放Ticket/认证码）。并未公开两个独立的云存储服务器之间直接进行身份联合及客户端重定向的过程。

* **D2/D3 (CN103583030A / EP2716006A1)**：主要探讨分布式云存储中数据的“切片（Shredding）”和分散存储以保证数据安全（即云存储中介将数据拆分存入平台A、B、C）。**完全未涉及**账户身份联合、单点登录或认证重定向的技术领域。

* **D4 (JP2013250875A)**：公开了在IdP（Identity Provider，对应第一云存储服务器）和SP（Service Provider，对应第二云存储服务器）之间建立SSO映射（SSO Mapping）的机制，目的与目标专利完全一致，是本案的**核心对比文件**。

#### 2. 技术特征比对表 (以D4为核心)

---

### 三、 创造性分析：最接近的对比文件 (CPA) 确定

在创造性评价中，**D4 (JP2013250875A) 是唯一适合作为最接近的对比文件 (CPA) 的文献**。

* **从技术领域与解决的技术问题来看**：目标专利解决的是跨云服务的“身份联合”问题，以实现单点登录（SSO）并消除API异质性。D4明确致力于解决“认证协作服务之间的SSO映射设置（シングルサインオンマッピングの設定）”问题，技术领域与目标专利完全重合。

* **从技术效果来看**：D4通过建立AUID映射表，同样实现了用户只需在一端认证即可访问另一端服务的技术效果。

* **淘汰D1、D2、D3的理由**：D2和D3解决的是分布式存储的数据防篡改/防泄露问题（数据切片），与身份联合毫不相干，本领域技术人员不会将其作为起点。D1虽然涉及认证，但属于集中式票据认证（类似Kerberos），未涉及两个对等服务提供商之间的账户映射和身份联合，距离目标专利较远。

### 四、 未被CPA公开的特征及无效请求突破口

#### 1. 区别技术特征及其技术效果

目标专利相对于D4的区别特征在于：**特征C（重定向至第二服务器）、特征D的特定动作（由客户端直接向第二服务器请求认证）以及特征E（重定向回第一服务器）**。

其达到的**技术效果**是：避免了客户端将第二服务器（SP）的账号和密码暴露给第一服务器（IdP）。在D4中（段落 `[0070]`），用户必须将SP的账号密码输入给IdP，由IdP后台代为请求，这要求IdP必须是完全可信的；而目标专利通过**客户端重定向流（Client Redirect Flow）**，实现了零敏感信息传递的联合，提升了系统安全性。

#### 2. 其他对比文件是否公开了该区别特征？

**没有。**

* D1 采用的是通过客户端中转Ticket的方式，不存在第一服务器重定向到第二服务器的机制。

* D2/D3 属于数据切片存储，根本不涉及HTTP 302重定向及身份认证逻辑。

#### 3. 若提出无效请求，最薄弱的技术特征与策略建议

如果我们要针对目标专利提出无效请求：

* **最薄弱的技术特征**是 **特征A、特征B、特征F**。这三个特征在D4中被实质或毫无异议地公开，在无效宣告请求书中可以直接作为已公开的现有技术进行主张，无需耗费过多笔墨。

* **无效突破难点与策略建议**：本案如果仅凭D1-D4，**无法成功宣告无效**，因为没有任何一篇文件公开了“重定向机制”。

* **破局思路**：需要引入新的对比文件（D5）。该D5应当是SAML 2.0、OAuth 2.0 或 OpenID Connect (OIDC) 的标准协议文档或相关专利。

* **结合方式**：以D4为最接近的对比文件，主张D4已经公开了“建立服务器间身份联合映射”的核心思想，而目标专利中的“通过HTTP重定向(302)实现客户端在两端之间的跳转认证”仅仅是本领域技术人员采用标准SAML/OAuth协议替换D4中后台API调用的**惯用技术手段**。因为在2015年（目标专利申请日前），使用重定向来避免密码泄露已经是Web安全认证领域的公知常识。

作为一名经验丰富的专利代理师，我将为您对目标专利进行深度解析，并结合四份对比文件进行全方位的技术特征比对与创造性、无效可行性分析。

---

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

目标专利（CN106415519B）涉及一种**统一云盘（Unified Cloud Disk, UCD）架构下的安全身份联合方法**。

结合目标专利说明书背景技术及具体实施方式，权利要求1各技术特征的架构实质与内涵解释如下：

* **客户端（Client）**：在UCD环境中具体指代**UCD客户端**（如说明书\[0011], \[0021]），是由终端用户（客户）操作的、能够通过标准SaaS API跨多个云存储系统访问数据的计算设备或软件。

* **第一云存储服务器**：在具体实施例中指代**从UCD服务器（Slave UCD Server）**（如说明书\[0011], \[0023]），其可以具有或没有身份提供方（IdP）功能。

* **第二云存储服务器**：在具体实施例中指代具有身份提供方功能、被终端用户选择用来注册主账户的**主UCD服务器（Master UCD Server）**（如说明书\[0011], \[0023]），它作为**身份提供方（Identity Provider, IdP）**负责发布标识信息、建立映射。

* **身份联合（Identity Federation）**：指允许用户将已经在不同服务提供方（不同的云存储系统）处创建的本地身份进行**链接、连接或结合**（如说明书\[0025]），从而形成统一的联合身份，这是实现后续单点登录（SSO）的先决条件。

* **重定向（Redirect）**：利用客户端作为中转桥梁，在第一云存储服务器和第二云存储服务器之间通过HTTP 302重定向消息携带参数进行认证信息互传的过程（如说明书\[0040], \[0047]），**其本质是以客户端为媒介的双向环状重定向认证机制。**

---

## 二、 对比文件技术特征比对与详细出处分析

为了客观评估权利要求1的创新性，引入以下四份对比文件（D1\~D4）进行特征级比对：

* **D1**: US20130110967A1 (公开日: 2013-05-02)

* **D2**: WO2013065084A1 (公开日: 2013-05-10)

* **D3**: JP2013516668A (公开日: 2013-05-13)

* **D4**: US20130198801A1 (公开日: 2013-08-01)

### 1. 对比文件公开特征的详细出处与分析

#### D1 (US20130110967A1) & D2 (WO2013065084A1)

* **实质公开内容**：D1与D2为同族专利，其公开了一种在异构环境下利用**单一存根信息（Stub Information）**管理多个不同云存储（Cloud Storages）中文件迁移、数据搬移、负载均衡的技术方案（参见D1/D2的摘要及\[0010]-\[0013]）。

* **特征比对结论**：D1/D2虽然提到了“客户端（Client）”和“多个云存储服务器”，但其核心在于**后端数据层面的文件映射与迁移**（Data Migration），完全不涉及客户端在两个云服务器之间互联、重定向进行**“身份联合/账户映射（Identity Federation/Account Collaboration）”**的认证管理流程。因此，D1/D2**未公开**特征B、C、D、E。

#### D3 (JP2013516668A)

* **实质公开内容**：D3公开了一种在不同的云平台或虚拟机监视器（Hypervisor）之间进行**虚拟映像/虚拟机（Virtual Images/VM）ポーティング（迁移/移植）**的方法（参见D3的\[0009]-\[0011]）。其利用拓扑模型差异（Topology Difference）和工作流，将ソリューション（解决方案）从源平台移植到目标平台。

* **特征比对结论**：D3属于虚拟化底层部署技术，虽然涉及认证信息（ソース認証情報）作为拓扑单元的一部分，但其核心是**虚机镜像的兼容性移植与展开**。D3**未公开**客户端在两个云存储服务器之间进行动态重定向、认证并建立用户账户映射的身份联合架构（特征B、C、D、E）。

#### D4 (US20130198801A1)

* **实质公开内容**：D4公开了一种**身份认证协作/联合系统（Authentication Collaboration System）**。该系统包括用户终端（User Terminal 100）、ID提供者设备（ID Provider Device 200，即IDP）以及服务提供者设备（Service Provider Device 300，即SP）。

* **出处及特征映射深度分析**：

* **特征A**：D4公开了用户终端向SP（第一服务器）发送服务使用请求，由于未认证，启动认证协作（参见D4的\[0011], \[0016], \[0113]-\[0116]及图13步骤S1-S3）。**毫无疑问公开了特征A。**

* **特征B**：D4公开了SP向用户终端发送认证协作请求，终端将其重定向发送给IDP（第二服务器）（参见D4的\[0011], \[0116]-\[0118]及图13步骤S4-S5）。该请求寻求在SP和IDP之间针对该用户建立**账户协作/账户联合（Account Collaboration/Account Registration）**。**实质公开了特征B。**

* **特征C**：D4中，终端在收到SP的请求后，被**重定向（Redirect）**到IDP设备（参见D4的\[0118]“the user terminal 100 redirects the authentication collaboration request message...”，图13步骤S5）。**毫无疑问公开了特征C。**

* **特征D**：D4公开了用户终端请求被IDP（第二服务器）认证（在非登录状态下输入ID和密码，或在已登录状态下通过Token识别）（参见D4的\[0121], \[0138], \[0168], \[0186]）。在确认或执行认证后，IDP（第二服务器）通过策略评估和账户配置，发布**身份联合ID（Authentication Collaboration ID）**，将IDP侧的用户账户与SP侧的用户账户进行**映射链接并建立账户协作**（参见D4的\[0059], \[0092]“performs account collaboration on both of the IDP user store 250 and the SP user store 310”，\[0132], \[0142]）。**毫无疑问公开了特征D。**

* **特征E**：D4公开了IDP（第二服务器）生成认证断言后，将认证协作响应消息通过用户终端**重定向（Redirect）**回SP（第一服务器）（参见D4的\[0140], \[0141]“the user terminal 100 redirects the received authentication collaboration response message to the SP...”，图15步骤S25-S26）。**毫无疑问公开了特征E。**

* **特征F**：D4的各设备均包含CPU和内存（参见D4的\[0058]），属于处理设备执行。**毫无疑问公开了特征F。**

---

### 2. 权利要求1技术特征比对表格

以下是本案权利要求1与各对比文件的精细化特征比对表：

---

## 三、 最接近对比文件（D1-D4）的甄选与创造性分析

### 1. 谁最适合作为“最接近的对比文件”？

在专利创造性分析（三步法）中，选择最接近对比文件的基本原则是**技术领域相同或相近、解决的技术问题最类似、公开的技术特征最多**。

* **D1、D2、D3 的裁决**：

* **D1/D2** 解决的技术问题是异构云存储之间的“文件迁移和多存根管理”，属于**后端数据存储管理领域**。

* **D3** 解决的技术问题是“虚拟机镜像跨平台移植时的トポロジ（拓扑）差异消除”，属于**系统部署与虚拟化移植领域**。

* 它们与本网权利要求1所要解决的“云存储环境下的**网络安全访问、身份联合认证与多账户链接映射**”这一核心技术问题完全不同。

* **D4 的裁决**：

* **D4** 同样属于**网络安全与身份认证联合领域**。

* D4 明确旨在解决“在单点登录（SSO）过程中，如何在无需人工干预的情况下，自动完成服务提供商（SP）与身份提供商（IDP）之间的**账户注册与联合协作**（Account Collaboration）”，这与目标专利解决“避免自由联合计划施加沉重开销负担，提供改进的身份联合管理（建立服务器之间的用户账户映射）”的**技术问题完全一致，且技术效果高度相同**（均实现了无缝、自动化的多账户联合）。

**结论**：**D4（US20130198801A1）是本案唯一且最适合的“最接近的对比文件”。**

### 2. 创造性评述与未公开特征的挖掘

基于三步法评述：

* **技术领域的重合性**：目标专利权利要求1属于云存储网络安全认证技术。如上表所示，D4已经毫无异议地公开了权利要求1中**绝大部分**的核心架构特征。

* **微弱区别特征分析**：目标专利权利要求1中使用了术语“第一云存储服务器”和“第二云存储服务器”，并限定在“云存储”场景下。而D4使用的是“服务提供者（SP）设备”和“ID提供者（IDP）设备”。

* **该区别特征是否被其他对比文件公开？**

* **是的。** D1和D2在说明书摘要及\[0007]、\[0011]中明确公开了“利用由云提供商提供的存储（云存储，Cloud Storage）”、“第一存储设备（First Storage Device）”及“第二存储设备”。

* **是否具有创造性？**

* 将D4中的网络服务提供者（SP）具体限定为“云存储服务提供者（云存储服务器）”，属于本领域技术人员在云计算普及背景下，将通用的SAML身份联合协议**应用到具体应用场景（云存储访问控制）的常规技术挑选和显而易见的应用迁移**。这种结合没有产生任何预料不到的技术效果。

* 因此，权利要求1相对于 **D4 结合 D1/D2** 或者是 **D4 结合本领域的公知常识**，不具备创造性。

---

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

若您代表请求人对本目标专利提出无效宣告请求，整个权利要求书（特别是权利要求1）**最薄弱、最容易被攻破的技术特征**是：

> **“技术特征C与技术特征E：双向环状重定向特征”** 以及 **“技术特征D：在重定向认证后由服务器建立用户账户映射/身份联合”**。

### 为什么这里最薄弱？

1. **架构完全撞车**：目标专利权利要求1表面上写得非常花哨（客户端在第一云和第二云之间来回重定向），试图以此作为发明点。但这种“Client $\rightarrow$ Server 1 $\rightarrow$ Client $\rightarrow$ Server 2 $\rightarrow$ Client $\rightarrow$ Server 1”的环状重定向，正是**标准SAM 2.0 / Liberty Alliance 协议中Web浏览器单点登录及账户链接的标准标准流程**。

2. **D4的高精准覆盖**：D4图13至图15的交互时序，完美再现了这一标准的重定向轨迹（特征C、E）。且D4明确记载了通过此过程由IDP侧利用“Authentication Collaboration ID”自动建立两端Store的账户映射（特征D）。

3. **缺乏特异性保护意图**：权利要求1在撰写时过于宽泛，仅写了方法流程（A $\rightarrow$ B $\rightarrow$ C $\rightarrow$ D $\rightarrow$ E），未能将说明书具体实施方式中真正可能具有新颖性的细节（例如：具体的消息格式 `IdentityFederationRequest(userIdM, userIdS...)` 或者数字签名确认有效的安全校验步骤）写入权利要求1。

### 总结无效策略建议

在撰写无效宣告请求书时，建议直接将 **D4 作为最接近的现有技术（独立基本点）**：

* 主攻**法条**：专利法第22条第3款（创造性）。

* **组合方式**：以 D4 为主线，结合 D1/D2（用于证明第一/第二服务器属于“云存储服务器”是行业惯用技术手段），足以为权利要求1盖棺定论。由于权利要求1未包含任何实质性的特异性技术特征，其在D4如此高精度的对口拦截下，**极难通过修改或辩驳来维持专利权有效**。

根据权利要求1所述的方法，进一步包括：在所述客户端处从所述第二云存储服务器接收用于所述客户端的登录令牌，以登录所述第一云存储服务器的服务。

根据权利要求2所述的方法，进一步包括：从所述客户端向所述第一云存储服务器发送所述登录令牌。

根据权利要求1所述的方法，进一步包括： 从所述客户端向所述第二云存储服务器发送身份解除联合请求，其中所述身份解除联合请求寻求将所述客户端的在所述第一云存储服务器上的所述用户账户与所述客户端的在所述第二云存储服务器上的所述用户账户解除联合； 将所述客户端从所述第二云存储服务器重定向到所述第一云存储服务器； 由所述客户端请求被所述第一云存储服务器认证，以使得所述第一云存储服务器在所述客户端被认证后使所述第一云存储服务器上的所述用户账户与所述第二云存储服务器上的所述用户账户的所述映射无效或将所述映射删除，由此结束所述第一云存储服务器上的所述用户账户和所述第二云存储服务器上的所述用户账户之间的所述身份联合；以及将所述客户端从所述第一云存储服务器重定向到所述第二云存储服务器。

一种计算机可读存储介质，所述计算机可读存储介质包括存储在其中的可执行程序代码，所述可执行程序代码在被处理设备执行时使得所述处理设备执行根据权利要求1所述的方法的步骤。

一种在客户端处执行的装置，包括存储器和处理器，所述处理器操作地耦合至所述存储器并且被配置为执行根据权利要求1所述的方法的步骤。

一种在第一云存储服务器处执行的方法，包括步骤： 在所述第一云存储服务器处接收来自客户端的用以被认证的请求； 在所述第一云存储服务器处从所述客户端接收身份联合请求，其中所述身份联合请求寻求将所述客户端的在所述第一云存储服务器上的用户账户与所述客户端的在第二云存储服务器上的用户账户联合；以及将所述客户端从所述第一云存储服务器重定向到所述第二云存储服务器，以使得所述客户端请求被所述第二云存储服务器认证，并且使得所述第二云存储服务器在所述客户端被认证后将所述第一云存储服务器上的所述用户账户与所述第二云存储服务器上的所述用户账户进行映射并且在它们之间建立身份联合，并且将所述客户端从所述第二云存储服务器重定向到所述第一云存储服务器； 其中所述步骤中的一个或多个步骤是由处理设备执行的。

一种计算机可读存储介质，所述计算机可读存储介质包括存储在其中的可执行程序代码，所述可执行程序代码在被处理设备执行时使得所述处理设备执行根据权利要求7所述的方法的步骤。

一种在第一云存储服务器处执行的装置，包括存储器和处理器，所述处理器操作地耦合至所述存储器并且被配置为执行根据权利要求7所述的方法的步骤。

一种在第二云存储服务器处执行的方法，包括步骤： 响应于从客户端至第一云存储服务器的身份联合请求，在所述第二云存储服务器处接收来自所述客户端的用以被认证的请求，其中所述身份联合请求寻求将所述客户端的在所述第一云存储服务器上的用户账户与所述客户端的在所述第二云存储服务器上的用户账户联合； 在所述客户端被认证之后，将所述第一云存储服务器上的所述用户账户与所述第二云存储服务器上的所述用户账户进行映射并且在它们之间建立身份联合；以及将所述客户端从所述第二云存储服务器重定向到所述第一云存储服务器； 其中所述步骤中的一个或多个步骤是由处理设备执行的。

一种计算机可读存储介质，所述计算机可读存储介质包括存储在其中的可执行程序代码，所述可执行程序代码在被处理设备执行时使得所述处理设备执行根据权利要求10所述的方法的步骤。

一种在第二云存储服务器处执行的装置，包括存储器和处理器，所述处理器操作地耦合至所述存储器并且被配置为执行根据权利要求10所述的方法的步骤。