对比文件名称：2006-03-16_WO2005017654A_发明申请_WO2005017654A2 INTEROPERABLE SYSTEMS AND METHODS FOR PEER-TO-PEER SERVICE ORCHESTRATION
目标专利名称：在面向服务架构总线上的互联网协议连接CN104137518B
本次调用的模型名称：专利创造性评估模型
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A：** 所述方法包括：在第一设备处，使用与第一IP服务相关联的第一服务名称，在所述SOA总线上通告所述第一IP服务<br>**《隐含公开》** | 第[0182]段：“...a NEMO Node 1810b (in FIG. 18b) can register its description, including its supported services, with other Nodes...”<br>第[0106]段：“...A service registry is software that responds to service search requests by returning a previously published service description.” | 对比文件公开了在对等网络（P2P）环境中，节点（Node）可以注册（register）其描述，包括其支持的服务（services），这相当于在网络上通告服务。其中，服务的描述（description）可以包含服务名称等信息（参见第[0100]段对WSDL的描述）。虽然对比文件未明确使用“IP服务”和“SOA总线”这两个术语，但其描述的NEMO框架是一个基于Web服务的对等服务编排框架，其核心是在对等节点间通告和发现服务（第[0115]-[0118]段），这与目标专利在SOA总线上通告IP服务的作用（实现服务发现与调用）在本质上相同。本领域技术人员能够从对比文件公开的服务通告机制中，推理出使用服务名称在类似总线的对等网络上通告服务的技术方案。因此，该技术特征被对比文件隐含公开。 |
| **技术特征B：** 在所述SOA总线上发现由第二设备通告的与第二服务名称相关联的第二IP服务，<br>**《直接公开》** | 第[0180]段：“Client Driven - a NEMO Node 1810a (in FIG. 18a) explicitly sends out a request to some set of targeted Nodes (e.g., 1820a) that support a ‘Service Query’ service interface 1815a, the request asking whether the targeted Nodes support a specified set of services.” | 对比文件明确公开了服务发现（Service Discovery）机制。请求节点（第一设备）向目标节点（第二设备）发送服务查询请求，询问目标节点是否支持指定的服务集。目标节点如果支持，则会响应，从而完成服务的发现。这与目标专利中“在SOA总线上发现由第二设备通告的...第二IP服务”的作用完全一致，即寻找并确认可用的服务。因此，本领域技术人员能够毫无疑义地从对比文件得出该技术特征。 |
| **技术特征C：** 其中，所述第一服务名称和所述第二服务名称中的每者包括与所述SOA总线处的IP服务统一地关联的服务描述符<br>**《未直接或隐含公开》** | 第[0106]段：“...A service registry is software that responds to service search requests by returning a previously published service description.”<br>第[0096]段关于WSDL元素（如portType, binding, service）的描述。 | 对比文件公开了服务具有描述（description），并且可以使用WSDL等标准进行描述。WSDL中的服务类型（service_type）、端口类型（portType）等可以起到区分服务类别的作用。然而，目标专利强调的是一种“与SOA总线处的IP服务统一地关联的服务描述符”（例如，“org.alljoyn.ipservice”），其作用是专门、统一地标识IP服务，以便于在总线上快速识别和发现所有IP服务。对比文件并未公开这种专门为IP服务设计、并在整个总线范围内统一使用的特定描述符。其服务描述更为通用，用于描述各种类型的服务，没有强调针对IP服务的统一标识。因此，对比文件既未直接公开也未隐含公开该技术特征。 |
| **技术特征D：** 通过在所述SOA总线上远程地调用所述第二设备的所述第二IP服务，向所述第二设备发送至少第一IP分组<br>**《隐含公开》** | 第[0211]段：“Asynchronous RPC Delivery Style — this model is particularly appropriate... The client submits a request... to any service-providing nodes.”<br>第[0213]段：“Synchronous RPC Delivery Style - the client submits a request and then waits for one or more responses...”<br>第[0162]段：“...The service requesting node makes a service discovery request... Once candidate service providing nodes are found, the requesting node may choose to dispatch a request to one or more of the service providing nodes based on a specific service binding.” | 对比文件详细描述了服务调用（service invocation）的多种模式，包括异步和同步的RPC（远程过程调用）风格。请求节点（客户端）在发现服务提供节点后，会基于特定的服务绑定（service binding）向目标节点分派（dispatch）请求以调用服务。虽然对比文件没有明确将传输的内容称为“IP分组”，但其请求/响应消息中承载的“payload”（有效载荷）可以包含任意数据。本领域技术人员可以合理推断，通过这种远程服务调用机制来向另一个节点发送数据（包括网络层数据如IP分组）是显而易见的应用方式。因此，该技术特征被对比文件隐含公开。 |
| **技术特征E：** 通过第一通告的服务，在所述SOA总线上从所述第二设备接收至少第二IP分组<br>**《隐含公开》** | 第[0211]段：“...the service-providing endpoint may respond indicating that it does not support this model, or, if the service-providing node does support this model, it will return a response...”<br>第[0168]段：“After dispatching a request, the requesting node will typically receive one or more responses.” | 对比文件公开了在服务调用中，服务提供节点会向请求节点返回响应（response）。响应消息同样包含payload。这对应于目标专利中第一设备通过其通告的服务接收来自第二设备的数据（第二IP分组）。虽然对比文件未特指接收的是IP分组，但接收作为服务调用结果的数据是远程服务调用的必然组成部分。因此，该技术特征被对比文件隐含公开。 |
| **技术特征F：** 其中，与所述第一IP服务相关联的所述第一服务名称还包括：被分配给所述第一设备的唯一的IP地址<br>**《未直接或隐含公开》** | 第[0128]段：“Node - a representation of a participant in the system framework... Nodes may be implemented in a variety of forms including consumer electronic devices, software agents...”<br>第[0136]段：“Service Provider - an entity (e.g., a Node or Device) that exposes some set of Services.” | 对比文件描述了节点（Node）代表系统参与者，服务由节点提供。节点的身份信息（identityinfo）可以包含各种凭证（如第[0197]段图5a中的Native Services API）。然而，对比文件完全没有提及将“IP地址”作为服务名称的一部分，也没有提及为设备分配唯一的IP地址用于在服务总线上的通信。目标专利将IP地址嵌入服务名称是为了在SOA总线层面直接实现IP路由和寻址，这是一个特定的技术手段。对比文件的服务发现和调用机制建立在更抽象的节点标识和服务绑定之上，未涉及IP网络层的地址集成。因此，该技术特征未被公开。 |
| **技术特征G：** 并且中，与所述第二IP服务相关联的所述第二服务名称还包括：被分配给所述第二设备的唯一的IP地址。<br>**《未直接或隐含公开》** | 同技术特征F的引用。 | 基于与技术特征F相同的理由，对比文件未公开在服务名称中包含分配给设备的唯一IP地址。因此，该技术特征未被公开。 |
| **技术特征H：** 动态地生成针对所述第一设备的IP地址<br>**《未直接或隐含公开》** | 无相关引用。 | 对比文件通篇未涉及IP地址的生成、分配或管理机制。其关注点在于服务层面的抽象、发现、安全与编排，而非底层网络协议（如IP）的地址配置。因此，该技术特征未被公开。 |
| **技术特征I：** 判断在所述SOA总线上的任何其它设备是否与所述动态地生成的IP地址相关联<br>**《未直接或隐含公开》** | 无相关引用。 | 同上，对比文件未涉及IP地址冲突检测。因此，该技术特征未被公开。 |
| **技术特征J：** 响应于确定在所述SOA总线上没有其它设备与所述动态地生成的IP地址相关联，将所述动态地生成的IP地址作为所述唯一的IP地址分配给所述第一设备。<br>**《未直接或隐含公开》** | 无相关引用。 | 同上，对比文件未涉及IP地址的动态分配逻辑。因此，该技术特征未被公开。 |
| **技术特征K：** 响应于确定在所述SOA总线上的另一个设备与所述动态地生成的IP地址相关联，放弃所述动态地生成的IP地址<br>**《未直接或隐含公开》** | 无相关引用。 | 同上，对比文件未涉及IP地址冲突解决。因此，该技术特征未被公开。 |
| **技术特征L：** 动态地生成针对所述第一设备的新的IP地址。<br>**《未直接或隐含公开》** | 无相关引用。 | 同上，对比文件未涉及IP地址的重新生成。因此，该技术特征未被公开。 |
| **技术特征M：** 其中，判断在所述SOA总线上的任何其它设备是否与所述动态地生成的IP地址相关联包括：确定在所述SOA总线上的不同的服务与所述动态地生成的IP地址相关联<br>**《未直接或隐含公开》** | 无相关引用。 | 对比文件未公开通过检查服务是否与IP地址相关联来判断IP地址冲突的机制。因此，该技术特征未被公开。 |
| **技术特征N：** 确定所述不同的服务包括被分配给所述第一设备的唯一的标识符<br>**《未直接或隐含公开》** | 无相关引用。 | 对比文件未公开利用设备唯一标识符来解析IP地址冲突的机制。因此，该技术特征未被公开。 |
| **技术特征O：** 基于所述唯一的标识符，确定所述不同的服务属于所述第一设备。<br>**《未直接或隐含公开》** | 无相关引用。 | 对比文件未公开上述机制。因此，该技术特征未被公开。 |
| **技术特征P：** 其中，在所述SOA总线上发现由所述第二设备通告的所述第二IP服务包括：在所述SOA总线上发现与所述第二IP服务相关联的所述第二服务名称。<br>**《隐含公开》** | 第[0180]段：“...the request asking whether the targeted Nodes support a specified set of services.”<br>第[0106]段：“...returning a previously published service description.” | 对比文件公开的服务发现过程，其请求和响应中必然涉及对服务的描述或标识，这隐含了服务名称的发现。当请求节点询问目标节点是否支持某项服务时，它需要以某种方式指定该服务，而服务名称是描述服务的最直接方式之一。服务提供节点返回的服务描述中也必然包含用于标识该服务的信息（如名称）。因此，本领域技术人员可以合理推断服务发现过程包括发现服务名称。该技术特征被隐含公开。 |
| **技术特征Q：** 其中，与所述第一IP服务相关联的所述第一服务名称和与所述第二IP服务相关联的所述第二服务名称被通告在由所述SOA总线实现的连续命名空间中。<br>**《未直接或隐含公开》** | 第[0106]段提及“service description”。<br>第[0092]段提及XML命名空间（XML Namespaces）用于解决命名冲突。 | 对比文件提到了使用XML命名空间来解决XML文档中的命名冲突，这是一种通用的数据格式技术。然而，目标专利的“由SOA总线实现的连续命名空间”特指在SOA总线基础设施层面为所有通告的服务提供的一个统一的、连续的命名范围或寻址体系（如AllJoyn总线的命名规则）。对比文件并未描述其服务通告依赖于或使用这样一个由总线本身实现的、特定的连续命名空间。因此，该技术特征未被公开。 |
| **技术特征R：** 其中，所述第一IP分组去往被分配给所述第二设备的唯一的IP地址。<br>**《未直接或隐含公开》** | 第[0211], [0213]段描述请求被发送到“service-providing nodes”。 | 对比文件描述了请求被发送到服务提供节点，但节点是通过服务绑定、地址（如URI）或发现机制来定位的，并未明确提及使用“IP地址”作为目的地址。其通信可能建立在更高层的抽象（如服务端点）或多种传输协议之上。目标专利明确将IP地址作为分组的最终网络层目的地址，并将此地址与服务名称绑定。对比文件没有公开这种基于IP地址的、网络层的数据路由机制。因此，该技术特征未被公开。 |
| **技术特征S：** 其中，所述第二IP分组去往与所述第一设备相关联的唯一的IP地址。<br>**《未直接或隐含公开》** | 同技术特征R。 | 基于与技术特征R相同的理由，对比文件未公开响应或数据去往设备的唯一IP地址。因此，该技术特征未被公开。 |
| **技术特征T：** 其中，与所述第一IP服务相关联的所述第一服务名称还包括：与所述第一设备相关联的主机名。<br>**《未直接或隐含公开》** | 无相关引用。 | 对比文件未提及在服务名称中包含主机名（hostname）或实现DNS功能。目标专利此特征是为了集成DNS解析。因此，该技术特征未被公开。 |
| **技术特征U：** 其中，与所述第一IP服务相关联的所述第一服务名称还包括：与所述主机名相关联的子域。<br>**《未直接或隐含公开》** | 无相关引用。 | 对比文件未提及子域。因此，该技术特征未被公开。 |
| **技术特征V：** 其中，与所述第一IP服务相关联的所述第一服务名称还包括：与所述第一IP服务相关联的子网的指示。<br>**《未直接或隐含公开》** | 无相关引用。 | 对比文件未提及IP子网或在服务名称中指示子网。因此，该技术特征未被公开。 |
| **技术特征W：** 其中，向所述第二设备发送所述第一IP分组还包括：在所述SOA总线上调用所述第二IP服务<br>**《隐含公开》** | 第[0211], [0213]段。 | 如技术特征D所述，对比文件公开了通过调用服务来发送请求（其payload可包含数据）。这直接对应于“在SOA总线上调用所述第二IP服务”。因此，该技术特征被隐含公开。 |
| **技术特征X：** 将所述第一IP分组作为与远程地调用所述第二IP服务相关联的参数，发送给所述第二IP服务。<br>**《隐含公开》** | 第[0211], [0213]段描述客户端提交请求（request），服务提供节点处理请求并返回响应。请求和响应消息包含payload。 | 对比文件中的服务调用涉及请求消息，消息中包含payload（有效载荷）。本领域技术人员可以理解，要传输的数据（如IP分组）可以作为该payload的一部分或作为调用的参数进行传递。虽然对比文件未明确使用“参数”一词，但将数据嵌入服务调用消息中是实现数据传递的常规技术手段。因此，该技术特征被隐含公开。 |
| **技术特征Y：** 其中，在虚拟网络接口处，发生向所述第二设备发送所述第一IP分组。<br>**《未直接或隐含公开》** | 无相关引用。 | 对比文件完全没有提及“虚拟网络接口”（Virtual Network Interface）。这是目标专利中用于桥接传统IP网络栈和SOA总线IP服务的具体实现模块。因此，该技术特征未被公开。 |
| **技术特征Z：** 其中，从所述第二设备接收所述第二IP分组，还包括：确定所述第二设备在所述SOA总线上调用了所述第一IP服务<br>**《隐含公开》** | 第[0171]段：“From the perspective of the service providing node... Determine if the requested service is supported.”<br>第[0211]段描述服务提供节点接收和处理请求。 | 对比文件从服务提供节点的角度描述，当它收到一个请求时，需要确定所请求的服务是否被支持。这对应于目标专利中第一设备（作为服务提供方）确定第二设备调用了它的第一IP服务。这是服务提供方处理传入调用的必然步骤。因此，该技术特征被隐含公开。 |
<<<B>>><<<a>>><<<d>>><<<e>>><<<p>>><<<w>>><<<x>>><<<z>>>