好的，请看我作为资深专利代理师的分析和评估。
**对比文件名称：** 2006-07-13_US2006155912A_发明申请_US20060155912A1 Server cluster having a virtual server
**目标专利名称：** 969服务器集群CN102934412B
**本次调用的模型名称：** 深度思考 (Deep Think)
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A：包括：接收请求** <br> **《直接公开》** | [0037] “As the demand on the software application of the primary node increases, one or more virtual versions 21 of the primary node can be initiated on standby node 18. Once these virtual versions of the standby node are initiated, the workload of the primary node can be distributed among the primary node and the instantiated virtual versions of the primary node in the standby node, thereby increasing the bandwidth or capacity of the application.” <br> 译文：[0037] “随着对主节点的软件应用的需求的增加，可以在备用节点18上启动一个或多个主节点的虚拟版本21。一旦这些备用节点的虚拟版本被启动，主节点的工作负载就可以在主节点和备用节点中实例化的主节点虚拟版本之间分配，从而增加应用的带宽或容量。” | 对比文件明确描述了在服务器集群环境中处理请求的工作负载。当客户端对主节点上的应用（例如Web服务器）的请求增加时，系统接收这些请求，并启动虚拟版本来分担负载。这种“接收请求”以进行处理和分配是服务器集群负载平衡的基本功能，对比文件公开了其存在。该特征在对比文件中的作用是触发负载分配和扩容操作，这与目标专利中接收请求以进行路由和负载平衡的作用本质相同，均是为后续处理提供基础。 |
| **技术特征B：选择要将所述请求转发至的第一虚拟服务器** <br> **《隐含公开》** | [0023] “In the event of a failure of a primary node, the operating system and applications of the failed primary node can be restarted on the virtual node.” <br> 译文：[0023] “在主节点发生故障的情况下，故障主节点的操作系统和应用可以在虚拟节点上重新启动。” <br> [0037] “As the demand on the software application of the primary node increases, one or more virtual versions 21 of the primary node can be initiated on standby node 18. Once these virtual versions of the standby node are initiated, the workload of the primary node can be distributed among the primary node and the instantiated virtual versions of the primary node in the standby node...” <br> 译文：[0037] “随着对主节点的软件应用的需求的增加，可以在备用节点18上启动一个或多个主节点的虚拟版本21。一旦这些备用节点的虚拟版本被启动，主节点的工作负载就可以在主节点和备用节点中实例化的主节点虚拟版本之间分配...” | 尽管对比文件没有明确使用“选择”一词，但其公开的技术方案隐含了选择逻辑。在故障转移场景中，系统需要识别出与故障主节点对应的虚拟节点（VS A对应VN A），这本质上就是一次选择。在负载分担场景中，系统需要决定将部分请求转发给哪个新启动的虚拟版本，这也是一种选择。本领域技术人员可以合理推断，要实现这些功能，系统必然包含一个选择机制（例如基于标识符的映射），以确定将请求转发至哪个特定的虚拟服务器。该隐含的选择逻辑在对比文件中是实现故障转移和负载分配的关键步骤，与目标专利中为请求选择目标虚拟服务器的目的和功能一致。 |
| **技术特征C：其中，所述第一虚拟服务器由多个服务器之一提供** <br> **《直接公开》** | [0023] “Each primary node 12 is associated with a virtual node 20. Primary Node A is associated with Virtual Node A (20A); Primary Node B is associated with Virtual Node B (20B); and Primary Node C is associated with Virtual Node C (20C). The virtual nodes each run within standby node 18.” <br> 译文：[0023] “每个主节点12与一个虚拟节点20相关联。主节点A与虚拟节点A(20A)相关联；主节点B与虚拟节点B(20B)相关联；主节点C与虚拟节点C(20C)相关联。每个虚拟节点都在备用节点18内运行。” <br> [0024] “As indicated in FIG. 1, each standby node will include multiple virtual servers. ... In the architecture of FIG. 1, a single physical standby node supports three physical primary nodes...” <br> 译文：[0024] “如图1所示，每个备用节点将包括多个虚拟服务器。...在图1的架构中，单个物理备用节点支持三个物理主节点...” | 对比文件明确公开了每个虚拟节点（相当于目标专利的虚拟服务器）是由一个物理节点（即服务器）提供的。具体地，虚拟节点20A、20B、20C都在物理的备用节点18上运行。因此，任何一个虚拟服务器（例如，虚拟节点A）都是由一个物理服务器（备用节点18）提供的。这完全符合技术特征C的描述。该特征在对比文件中定义了虚拟节点与物理节点之间的归属关系，这与目标专利中虚拟服务器由物理服务器提供的定义完全一致。 |
| **技术特征D：其中，所述服务器中的至少一些提供多个虚拟服务器** <br> **《直接公开》** | [0024] “As indicated in FIG. 1, each standby node will include multiple virtual servers. ... In the architecture of FIG. 1, a single physical standby node supports three physical primary nodes...” <br> 译文：[0024] “如图1所示，每个备用节点将包括多个虚拟服务器。...在图1的架构中，单个物理备用节点支持三个物理主节点...” <br> [0025] “Shown in FIG. 2 is a detailed diagram of standby node 18. In the example of FIG. 2, standby node 18 includes three virtual nodes 20.” <br> 译文：[0025] “图2示出了备用节点18的详细示意图。在图2的示例中，备用节点18包括三个虚拟节点20。” | 对比文件明确公开了一个物理服务器（备用节点18）提供多个虚拟服务器（虚拟节点20A、20B、20C）。这直接揭示了“服务器中的至少一些提供多个虚拟服务器”这一技术特征。该特征在对比文件中是实现资源整合和高效利用的关键，使得单个备用节点可以为多个主节点提供备份服务，这与目标专利中通过物理服务器提供多个虚拟服务器以提高资源利用率的目的完全相同。 |
| **技术特征E：在所述第一虚拟服务器不能够接收到所述请求的情况下，将所述请求转发至所述第一虚拟服务器的相邻虚拟服务器** <br> **《隐含公开》** | [0023] “In the event of a failure of a primary node, the operating system and applications of the failed primary node can be restarted on the virtual node.” <br> 译文：[0023] “在主节点发生故障的情况下，故障主节点的操作系统和应用可以在虚拟节点上重新启动。” <br> [0037] “As the demand on the software application of the primary node increases, one or more virtual versions 21 of the primary node can be initiated on standby node 18. Once these virtual versions of the standby node are initiated, the workload of the primary node can be distributed among the primary node and the instantiated virtual versions of the primary node in the standby node...” <br> 译文：[0037] “随着对主节点的软件应用的需求的增加，可以在备用节点18上启动一个或多个主节点的虚拟版本21。一旦这些备用节点的虚拟版本被启动，主节点的工作负载就可以在主节点和备用节点中实例化的主节点虚拟版本之间分配...” | 对比文件公开了两种“第一虚拟服务器不能够接收到所述请求”的场景：1) 主节点故障；2) 主节点负载过重。在这两种情况下，请求被转发到备用节点上的一个虚拟服务器（虚拟节点）。尽管对比文件未使用“相邻”一词，但其描述的“虚拟版本”是为主节点专门创建的备用/扩容实例。本领域技术人员结合对比文件的上下文可以合理推断，这些虚拟服务器在逻辑上紧邻其对应的主节点，构成了一种功能上的“相邻”关系。当主节点（可视为一种特殊的“第一虚拟服务器”）不可用时，请求被转发到其对应的虚拟服务器，这隐含了“转发至相邻虚拟服务器”的技术方案，其目的是为了实现高可用性和负载均衡，与目标专利一致。 |
| **技术特征F：其中，所述第一虚拟服务器的相邻虚拟服务器是与所述第一虚拟服务器不同的服务器的一部分** <br> **《直接公开》** | [0023] “Each primary node 12 is associated with a virtual node 20. ... The virtual nodes each run within standby node 18.” <br> 译文：[0023] “每个主节点12与一个虚拟节点20相关联。...每个虚拟节点都在备用节点18内运行。” <br> [0037] “As the demand on the software application of the primary node increases, one or more virtual versions 21 of the primary node can be initiated on standby node 18.” <br> 译文：[0037] “随着对主节点的软件应用的需求的增加，可以在备用节点18上启动一个或多个主节点的虚拟版本21。” | 对比文件明确公开了主节点（Primary Node A, B, C）与为其提供故障转移或负载分担的虚拟节点（Virtual Node A, B, C）位于不同的物理服务器上。主节点位于Primary Node A，而其对应的虚拟节点Virtual Node A位于Standby Node 18，这是两个不同的物理服务器。因此，当将Primary Node A视为“第一虚拟服务器”（或其载体）时，其“相邻虚拟服务器”（Virtual Node A）确实是“与第一虚拟服务器不同的服务器”的一部分。该特征在对比文件中是实现主节点故障隔离和资源高效利用的核心，与目标专利通过将备份放在不同物理服务器上来避免单点过载的设计思想一致。 |
| **技术特征G：其中，服务器的每个虚拟服务器具有由不同其他服务器提供的相邻服务器。** <br> **《未公开》** | [0024] “As indicated in FIG. 1, each standby node will include multiple virtual servers. ... In the architecture of FIG. 1, a single physical standby node supports three physical primary nodes...” <br> 译文：[0024] “如图1所示，每个备用节点将包括多个虚拟服务器。...在图1的架构中，单个物理备用节点支持三个物理主节点...” | 对比文件公开的架构与目标专利的技术特征G存在本质区别。在对比文件中，所有虚拟节点（Virtual Node A、B、C）的“相邻”（即其对应的故障转移目标）都是同一个物理备用节点（Standby Node 18）。这意味着，对于物理备用节点18来说，它自身上的多个虚拟服务器的“相邻服务器”是相同的（即它们各自对应的主节点，但这些主节点是不同的物理服务器，所以这一点不直接冲突）。更关键的是，目标专利技术特征G强调的是，对于任意一个物理服务器上的所有虚拟服务器，它们的备份服务器都必须是不同的其他物理服务器。对比文件中的主节点A、B、C各自只有一个虚拟备份，且这些备份集中在同一个物理节点上，这完全不符合“每个虚拟服务器具有由不同其他服务器提供的相邻服务器”的分散式备份要求。该特征在对比文件中是缺失的。 |
| **技术特征H：其中，在服务器不可操作的情况下，其余服务器的每个虚拟服务器具有由不同其他服务器提供的相邻服务器。** <br> **《未公开》** | [0023] “In the event of a failure of a primary node, the operating system and applications of the failed primary node can be restarted on the virtual node.” <br> 译文：[0023] “在主节点发生故障的情况下，故障主节点的操作系统和应用可以在虚拟节点上重新启动。” | 技术特征H描述了一种在单个服务器故障后，剩余服务器上的备份关系仍然保持分散和均衡的状态。对比文件仅描述了故障发生时，工作负载被转移到对应的虚拟节点。它没有进一步讨论在某个主节点发生故障后，备用节点18上剩余的虚拟节点的备份关系是否会发生变化，或者是否仍满足“具有由不同其他服务器提供的相邻服务器”的条件。事实上，由于对比文件中的备份关系是静态的一对一映射（主节点→虚拟节点），一旦一个主节点故障，其对应的虚拟节点可能接管工作，但其他虚拟节点的备份关系并未改变，它们仍然只指向自己唯一的主节点，这并非目标专利所描述的动态均衡的备份关系。该特征在对比文件中完全没有被公开或暗示。 |
| **技术特征I：其中，在服务器不可操作的情况下，其余服务器的两个虚拟服务器具有由相同其他服务器提供的相邻服务器，并且，任何其余虚拟服务器中的每一个具有由不同其他服务器提供的相邻服务。** <br> **《未公开》** | 全文未发现相关描述。 | 技术特征I是技术特征H的一个更宽松的变体，但仍然是关于在服务器故障后，其余虚拟服务器的备份关系分布。对比文件没有公开任何关于在故障发生后，如何去调整或保证剩余虚拟服务器的备份服务器属于不同物理服务器的内容。对比文件的架构是每个主节点对应一个唯一的虚拟节点，这种一对一的静态关系决定了其无法满足这种复杂的、动态的负载分担要求。因此，该技术特征未被对比文件公开。 |
| **技术特征J：其中，将与请求相关联的会话信息发送至所述第一虚拟服务器和所述第一虚拟服务器的相邻虚拟服务器。** <br> **《未公开》** | [0031] “At steps 50, the application of the primary node is copied to a warm spare virtual machine in a virtual node of the standby node.” <br> 译文：[0031] “在步骤50，将主节点的应用复制到备用节点的虚拟节点中的温备虚拟机。” <br> [0035] “...the warm spare virtual machine is elevated to a hot spare virtual machine, thereby providing another licensed virtual machine to handle a portion of the workload of the existing hot spare virtual machine.” <br> 译文：[0035] “...温备虚拟机被提升为热备虚拟机，从而提供另一个已许可的虚拟机来处理现有热备虚拟机的一部分工作负载。” | 目标专利的技术特征J要求将“与请求相关联的会话信息”同时发送给主虚拟服务器和其备份服务器，这是一种主动、实时的会话同步机制，以确保无缝的故障转移。对比文件公开了复制应用的副本（将应用复制到温备虚拟机），以及在需要时提升温备虚拟机为热备虚拟机。但这种复制和提升是基于状态或阈值的操作，并非在处理每个请求时，都将该请求的会话信息同时发送给主虚拟机和备份虚拟机。对比文件中的“复制”是创建应用的静态副本，而“会话信息同步”是处理动态请求时的实时数据流。因此，对比文件公开的机制和目标专利的实时会话信息同步在目的、时机和实现方式上均不同。该特征未被对比文件公开。 |
---
**结论代码**
<<<C>>><<<D>>>