CN111869187A - Iot服务层系统与分布式分类账系统之间的互通 - Google Patents

Abstract

本文描述了一种分布式分类账互通架构，其中分布式分类账代理与IoT服务层系统和分布式分类账系统相接口。服务层节点可以与分布式分类账代理交互以利用分布式分类账系统提供的功能，例如，请求分布式分类账代理将一些服务层信息插入分布式分类账。分布式分类帐代理可以支持多个服务层节点，并且可以接口到多个不同的分布式分类帐系统。

Description

IOT服务层系统与分布式分类账系统之间的互通

背景技术

oneM2M标准定义了在一个或多个网络实体(每个网络实体被称为“通用服务实体”(CSE))中实现的服务层。服务层的目的是提供可被不同的“垂直”M2M系统和应用程序利用的“水平”服务。CSE支持四个参考点。Mca参考点与应用程序实体(AE)接口。Mcc参考点与同一服务提供商域内的另一个CSE接口，而Mcc'参考点与不同服务提供商域内的另一个CSE接口。Mcn参考点与基础网络服务实体(NSE)接口。NSE向CSE提供基础网络服务，例如设备管理、位置服务和设备触发。CSE包含多个被称为“公共服务功能”(CSF)的逻辑功能，例如“发现”和“数据管理与存储库”。

发明内容

公开了一种用于IoT服务层系统与分布式分类帐系统之间的互通的方法和系统。描述了一种分布式分类账互通架构，其中分布式分类账代理与IoT服务层系统和分布式分类账系统接口。服务层节点可以与分布式分类账代理交互以利用分布式分类账系统提供的功能，例如请求分布式分类账代理将一些服务层信息插入分布式分类账中。分布式分类帐代理可以支持多个服务层节点，并且可以接口到多个不同的分布式分类帐系统。

提供本发明内容以简化形式介绍选择的概念，这些概念将在下面的具体实施方式中进一步描述。本发明内容既不旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于限制所要求保护的主题的范围。此外，所要求保护的主题不限于解决在本公开的任何部分中指出的任何或所有缺点的限制。

附图说明

为了有助于对本申请的更健全的理解，现在参考附图，在附图中，相同的元件用相同的附图标记表示。这些附图不应被解释为限制本申请，而仅意图是说明性的。

图1示出了oneM2M架构的示例框图；

图2示出了分布式分类帐系统架构的示例框图；

图3示出了在分布式分类帐节点处执行的示例操作的流程图；

图4示出了比特币系统和相关的分布式分类帐系统中的示例分布式分类帐结构的流程图；

图5示出了比特币系统中的示例分布式分类帐结构的框图；

图6示出了比特币系统中的示例交易结构的流程图；

图7示出了分离的IoT服务层系统和分布式层系统的流程图；

图8示出了第一示例分布式分类账互通架构；

图9示出了第二示例分布式分类账互通架构；

图10示出了第三示例分布式分类账互通架构；

图11示出了第四示例分布式分类账互通架构；

图12示出了使用第一和第二互通架构的分布式分类账互通的示例方法的流程图；

图13示出了使用第三互通架构的分布式分类账互通的示例方法的流程图；

图14示出了使用第四互通架构的分布式分类账互通的示例方法的流程图；

图15示出了用于分布式分类账代理和服务层节点关联的示例方法的流程图；

图16示出了用于将服务层信息添加到分布式层的第一示例方法的流程图；

图17示出了分布式层系统交易的示例；

图18示出了用于将服务层信息添加到分布式层的第二示例方法的流程图；

图19A和19B示出了用于将服务层信息添加到分布式层的第三示例方法的流程图；

图20示出了用于在分布式分类账系统中查询交易的示例方法的流程图；

图21示出了用于在分布式分类账系统中验证交易的示例方法的流程图；

图22示出了用于订阅分布式分类账系统中的交易的示例方法的流程图；

图23示出了用于分布式分类账系统中的交易模板格式的<dlsTxTemplate>资源的示例结构；

图24示出了用于操作<dlsTxTemplate>资源的示例方法；

图25示出了与分布式分类账系统有关的交易实例的<dlsTx>资源的示例结构；

图26示出了用于操作<dlsTx>资源的示例方法；

图27示出了用于服务层节点的示例用户界面；

图28示出了用于分布式分类账代理的示例用户界面；

图29A示出了其中可以实施一个或多个所公开的实施例的示例机器到机器(M2M)或物联网(IoT)通信系统的示例系统图；

图29B示出了可以在图29A所示的M2M/IoT通信系统内使用的示例架构的示例系统图；

图29C示出了可以在图29A所示的通信系统内使用的示例M2M/IoT终端或网关设备的示例系统图；以及

图29D示出了其中可以实现图29A的通信系统的各方面的示例计算系统的示例框图。

具体实施方式

oneM2M架构(参见oneM2M-TS-0001oneM2M功能架构-V3.10.0，2018年2月)实现了以下类型的节点，如图1所示：

应用服务节点(ASN)：包含一个CSE并且包含至少一个应用实体(AE)的节点。物理映射示例：ASN可以驻留在M2M设备中；

应用专用节点(ADN)：包含至少一个AE并且不包含CSE的节点。oneM2M系统的场域中可以有零个或多个ADN。物理映射示例：ADN可以驻留在受约束的M2M设备中；

中间节点(MN)：包含一个CSE并且包含零个或多个AE的节点。oneM2M系统的场域中可以有零个或多个MN。物理映射的示例：MN可以驻留在M2M网关中；

基础设施节点(IN)：包含一个CSE并且包含零个或多个AE的节点。每个oneM2M服务提供商的基础设施域中可以恰好有一个IN。IN中的CSE可以包含不适用于其它节点类型的CSE功能。物理映射示例：IN可以驻留在M2M服务基础设施中；以及

非oneM2M节点(NoDN)：不包含oneM2M实体(既不包含AE也不包含CSE)的节点。此类节点表示出于互通目的(例如，管理)而附接到oneM2M系统的设备。

图2示出了分布式分类账(DL)交易的示例实例，其中DLN1将交易发送给对等的分布式分类账节点(DLN)。此图还说明了通用的分布式分类帐系统(DLS)架构，其中DLN可以经由底层点对点(P2P)网络相互连接并参与到该系统中。有一些现有的DLS，例如比特币系统和以太坊系统。取决于底层P2P网络协议，DLN可以具有若干其它DLN作为其对等邻居。DLN可以是完整节点或轻型节点。完整的DLN节点(例如，比特币系统中的矿工)维护完整的分类帐，由于新添加到分类账的交易，分类帐一直在增长。轻型DLN节点(例如，比特币系统中的钱包客户端软件)不维护完整的分类帐，而只能处理来往分类账的交易。通常，以下操作在每个DLN节点处独立执行，使得可以在每个完整的DLN节点处连续形成和维护完整且一致的分类帐。应当理解，这些操作仅是示例性的，并且某些操作对于轻型DLN节点可以是不需要的。

在阶段1，启动后，DLN发现并选择一些现有DLN作为其对等邻居(例如，经由基于域名系统的服务发现(DNS-SD))，并连接到P2P网络。然后，它通过从其邻居DLN下载当前分类帐来与其邻居DLN同步，并且还可以交换公共密钥或其它类似的凭证。

在阶段2，DLN生成新交易，并且可以使用其私有密钥对其进行签名。该DLN可以是此交易的发布者(例如，比特币系统中的付款人)。然后，它将已签名的交易发送给其邻居DLN，其邻居DLN也可以将交易中继到其邻居。最终，新交易可以被系统中的所有DLN接收。

在阶段3，DLN接收新交易，并可以使用发送DLN的公共密钥验证该交易。

在阶段4，每个完整的DLN节点独立执行某个共识协议(例如，比特币系统中的工作量证明(PoW))，并生成包含一组新生成但未确认的交易的交易集(例如，比特币系统中的区块)。第一个生成满足DLS提供的要求的交易集的DLN节点被声明为获胜者。换句话说，只有共识协议之外的获胜者才能生成新的交易集，并将其发送到P2P网络进行验证。请注意，此交易集通常包含对当前分类账的最后一个交易集的先前交易参考；先前交易参考有助于在阶段6将此交易集追加到当前分类帐。

在阶段5中，获胜者(例如，本示例中的DLN6)生成交易集并将其发送到P2P网络。

在阶段6，DLN(例如，在本示例中为DLN3、DLN4和DLN5)接收交易集并根据同一共识协议对其进行验证。在每个DLN处，可以将经过验证的交易集追加到当前分类帐，这意味着现在确认了交易集中包含的所有交易；从而通过将来自已确认交易集中的所有交易的更改进行合并来在每个DLN处独立且自动地更新DLS系统状态(例如，比特币系统中未使用的比特币)。在此步骤之前，整个DLS都将达到新状态，该状态将由未来的交易集更新。

根据图2所示的示例：1)DLN1和DLN2是轻型节点，并且可以仅在阶段1、阶段2和阶段3中涉及；2)DLN1生成新交易，该新交易由所有其它DLN接收；3)DLN3-DLN6是完整节点，并且独立执行共识协议，并且DLN6是获胜者；4)每个完整节点都维护单独的分类帐，但具有同一交易集列表(例如，越来越多的经过验证的交易集)。

许多DLS(例如，比特币系统)被设计具有以下特征和优点：

通过使用发送DLN的私有密钥签署交易来保护每个交易的数据完整性；

发送DLN仅披露其公共密钥或公共密钥的哈希，而不公开其真实身份。因此，从身份的角度来看，隐私得到保护；

由于每个完整的DLN维护单独且完整的分类帐，因此不存在单点故障，并且几乎不可能篡改分类帐；以及

DLN不需要它们之间的预先建立的信任，而是独立地执行共识协议，这在一些DLS(例如，比特币系统中的PoW)中需要密集的计算，并且攻击分类账的成本将非常高。

DLS可以在没有任何预先建立的许可或信任的情况下由公共用户使用，并且被称为公共分类账或无许可分类账(例如，比特币系统)。相反，私有分类帐或许可分类帐(例如，超级分类帐系统)是仅用于某些许可用户(例如，组织内部的用户)的DLS。这两种类型的DLS之间的另一个区别是，私人分类帐可以使用简单的共识协议，因为私人分类帐中的用户已经建立了一定的信任。

基于图2所示的一般架构，图3示出了在DLN处的示例操作细节，其可以包括以下步骤(尽管对于特定的DLS，细节可能有所不同)。应当理解，每个DLN可以独立地执行这些步骤。

在步骤1，DLN启动并发现现有的DLN。

在步骤2，DLN依赖于底层P2P协议连接到一个或多个被发现的DLN，并且可以彼此交换公共密钥或类似凭证。

在步骤3，DLN从一个或多个被发现的DLN中检索当前分类帐。

在步骤4，DLN等待即将发生的事件或触发器(例如，生成新交易、接收新交易集或接收新交易)。

当需要生成新交易时，可以触发步骤5.1和5.2二者。

在步骤5.1，DLN组装新交易。DLN可以使用其私有密钥签署交易。交易结构在不同的DLS中有所不同。例如，图6(下面讨论)示出了比特币系统中的交易结构。

在步骤5.2，DLN将交易发送到其邻居DLN。

当DLN接收到新交易时，可以触发步骤6.1-6.4。

在步骤6.1，DLN从P2P网络接收新交易。

在步骤6.2，DLN验证交易，这可以是检查该交易的发布者在分类账中是否有足够的未使用的比特币来支持比特币系统中的该交易。如果交易有效，则DLN可以将其存储在等待执行共识协议的交易池中，也可以将其转发给邻居DLN。在一些系统(例如，以太坊)中，交易可以被发送到分类账中的合约账户，并且可以导致合约账户中包含的合约代码的执行。请注意，可以直到共识协议完成才能验证交易。

在步骤6.3，DLN执行共识协议并生成新的交易集。以比特币系统为例，DLN将未确认的交易(已缓存在交易池中)组装成一个区块。该区块还可以包含对当前分类账中的最后一个区块(例如，哈希(最后一个区块))的参考以及匹配随机数。可以在大量计算尝试之后找到匹配随机数，以使“该新区块+匹配随机数”的哈希值小于目标值。比特币系统的设计使得此过程(例如，找到匹配随机数)平均需要十分钟。换句话说，在比特币系统中，通过执行PoW协议生成新区块所需的平均时间为十分钟。在图5中示出了在比特币系统中使用的示例区块结构。

在步骤6.4，DLN将新交易集(例如，比特币系统中的新区块)发送到P2P网络。

当DLN从其邻居DLN接收到新交易集时，可以触发步骤7.1-7.4。

在步骤7.1，DLN从P2P网络接收新交易集。如果DLN仍在对包含在接收到的交易集中的交易执行共识协议，并且如果接收到的交易集有效，则DLN可以停止当前的共识协议执行，而可以移动到对交易池中缓冲的其它未确认交易执行共识协议。

在步骤7.2，DLN根据共识协议验证接收到的交易集。请注意，共识协议(例如，比特币系统中的PoW)在生成新交易集(例如，步骤6.3)时可能需要大量计算，但是通常无需花费太多计算即可更快地验证接收到的交易集。

在步骤7.3，一旦交易集是有效交易集，DLN会将交易集追加到分类账。通常，该交易集包含对当前分类账中最后一个交易集的参考(例如，其父交易集)。在一些DLS中，当将经验证的交易集追加到分类账时，可以将其连接到多个先前的交易集。一般的分布式分类帐在图4中示出并在下面讨论。

在步骤7.4，DLN将经验证的交易集转发到其邻居DLN。

图4示出了在比特币系统和使用与比特币系统类似的区块链技术的其它DLS中使用的示例分布式分类帐结构。请注意，分布式分类帐可以由每个完整的DLN节点独立维护，并且可以包含以下三个组件：

区块链：经验证的区块的链。第一个区块是创世块，没有参考任何先前的区块。区块#N是最近生成和验证的最后一个区块；

交易池：DLN处的存储池，用于缓冲所有接收到但未确认的交易。当新区块被接收并验证时，新区块中包含的所有交易都可以从交易池中移除；以及

帐户和虚拟机：比特币系统不具有此项，但以太坊系统使用此项来支持智能合约并在以太坊系统之上开发各种垂直应用程序。以太坊系统中有两种类型的账户：用户拥有的外部账户和包含合约代码的合约账户。外部帐户可以将交易发送到空地址以创建新合约(例如，合约帐户)，并最终将其部署到系统中。每当合约帐户接收到来自外部帐户的交易或来自另一合约帐户的消息时，合约代码就被自动触发并执行。请注意，出于共识目的，以太坊系统使用与比特币系统相同的PoW协议。

图5示出了在比特币系统中使用的示例区块结构。示例区块结构具有以下字段：

区块大小：指示整个区块的大小；

区块标题：包含与版本、先前的区块哈希值、默克尔根、时间戳、难度目标和随机数相关联的信息；

版本：比特币系统的版本；

先前区块哈希值：先前区块(例如，分类账上的最后一个区块)的哈希值；

默克尔根：根据特定树结构的所有包含的交易的哈希结果；

时间戳：该区块的生成时间；

难度目标：用于调整PoW协议的难度，使得平均每十分钟可以生成一个新区块；

随机数：从运行PoW协议获得的整数，以确保哈希(此区块，随机数)将小于目标值；

交易计数器：指示该区块中包含的交易数量；以及

交易：包含一组交易。第一交易是由矿工(例如，生成该区块的DLN)创建的coinbase交易(或生成交易)，以索取包括用于运行PoW协议并生成该区块的努力的所有交易费用的奖励。因此，coinbase交易可能不具有输入部分(参见图6)。

图6示出了比特币系统中的交易结构，其中示出了两个特定的交易实例(例如，TIDx和TIDy)。交易实例TIDx可以在交易实例TIDy之前已经生成。

每个交易可以具有两个主要部分(例如，“输入”和“输出”)以及图中未示出的一些其它字段。“输入”部分包括其它付款人已转移或支付给该交易的发布者的未使用的交易输出(UTXO)的列表。“输出”部分包括该交易的发布者将支付以使用“输入”部分中的所有UTXO的UTXO的列表。“输入”部分中包含的总比特币数量应不少于“输出”部分中包含的总比特币，并且盈余可以被支付作为对运行PoW协议并首先生成新的和有效区块的矿工DLN的激励。

在由用户1发布的TIDx中，用户1向用户2和用户4付款(例如，向用户4支付0.1比特币，向用户2支付0.2比特币)。因此，在TIDx的“输出”部分中有两个UTXO，一个给用户4，另一个给用户2。注意，为了说明的方便，省略了TIDx的“输入”部分。

交易的“输入”部分包含一个或多个UTXO的参考，其已包括在先前的交易中。例如，TIDy的“输入”部分包含一个UTXO，它指向交易TIDx中输出索引＝1的UTXO。

在用户2发布的TIDy中，用户2使用他的比特币(例如，从TIDx中的用户1接收到)向用户3付款(例如，0.15比特币)；0.04的更改将返回给用户2，剩余0.01比特币则作为交易费用。

每个用户可以具有一对唯一密钥(私有密钥，公共密钥)。公共密钥可以基于私有密钥。

公共密钥可以用于生成唯一的比特币地址。比特币地址是公共的，并向其它用户揭露，并且可以用作交易“输出”部分中的接收地址(例如，收款人)。

私有密钥可用于生成签名，付款人可将其与公共密钥一起用作UnlockingScript(US)以基于UTXO的LockingScript(LS)来解锁UTXO，并且还可以由其它DLN用于验证付款人是否是此UTXO的所有者。

如图7所示，现有的物联网(IoT)服务层系统(SLS)可用于维护资源树并将数据存储在不同的SLN中。例如，在oneM2M中，IN-CSE维护注册到IN-CSE的IN-AE、MN-CSE和ASN-CSE的资源树；并且MN-CSE托管用于已注册的MN-AE、ADN-AE和ASN-CSE的资源树。然而，现有的SLS存储数据和管理整个系统的方式继承了以下限制：

SLN通常是用于存储注册到该SLN的所有其它SLN的数据的集中式节点(例如，图7中的情境1)。此集中式节点可能会导致单点故障。另外，集中式节点可能受到拒绝服务、否认访问记录、篡改数据等风险的攻击；

每个SLN可以仅维护用于其它已注册SLN的一部分数据。无法保证将一直维护整个系统中的所有数据访问历史记录和数据本身。

在以ad hoc方式部署SLN的某些情境中，例如，用于公共安全和灾难管理(例如，图7中的情境2)，在这些SLN之间预先建立信任可能是不可行的，并且它们之间的数据交换的安全性可能处于危险之中；以及

现有的SLS，例如oneM2M，需要SLN建立注册关系，然后它们才能相互通信。对于某些情境，这样的SL注册过程可能是负担或难以实现。例如，SLN(例如，移动中的车辆)可能会继续四处移动，因此将重复执行现有的SL注册，这会导致额外的开销。同样，对于以ad hoc模式部署的SLN，可能不容易建立SL注册。DLS可以用于这些情境，而无需SL注册，但同时仍保证SLN的安全性和信任。

DLS带来许多优点，诸如仅追加、不可否认的分布式分类帐，无需预先建立的信任。如上文所讨论的，DLS具有克服SLS局限性的良好潜力。然而，现有的SLS和DLS已开发为两个分离的系统。在SLS可以有效利用DLS的优势之前，可能需要解决几个问题。例如：SLS如何有效地与不同但适当的DLS互通，SLN如何正确指示其支持/使用DLS的能力和要求，SLN如何与DLN进行有效交互以用于分类账相关的操作，以及SLS信息可以如何被有效地添加(例如，数据访问记录)到分布式分类帐。

本文公开了用于IoT服务层系统和分布式分类账系统之间的互通的方法和系统。

描述了分布式分类账互通架构，其中分布式分类账代理与IoT服务层系统和分布式分类账系统接口。服务层节点可以与分布式分类帐代理进行交互以利用分布式分类帐系统提供的功能。例如，服务层节点可以请求分布式分类帐代理将一些服务层信息插入分布式分类帐。分布式分类帐代理可以支持多个服务层节点，并且还可以接口到多个不同的分布式分类帐系统。

本文公开了用于互连IoT服务层系统和分布式分类帐系统的以下示例方法：

一种用于服务层节点选择适当的分布式分类帐代理以与分布式分类帐系统互通的方法；

一种用于分布式分类帐代理为服务层节点选择适当的分布式分类帐系统的方法；

一种用于分布式分类账代理与服务层节点相关联的方法，其中分布式分类账代理可以首先向服务层节点注册，服务层节点可以请求批准分布式分类账代理使用其代理功能，和/或分布式分类帐代理可以将其交易格式或模板发送到服务层节点；

一种用于服务层节点触发将服务层信息添加到分布式分类账的方法；

一种用于一个服务层节点向另一服务层节点指示分布式分类账需求的方法；

一种用于服务层节点基于从分布式分类帐代理接收到的交易格式将服务层信息(例如，服务层请求原语)组装到交易中的方法。服务层节点可以将生成的交易发送到分布式分类账代理，分布式分类账代理可以根据分布式分类账系统规范将它们添加到分布式分类账。

一种用于服务层节点简单地将服务层信息发送到分布式分类帐代理的方法，分布式分类帐代理可以将服务层信息转换成交易并根据分布式分类帐系统规范将交易添加到分布式分类帐；

一种用于服务层节点从分布式分类账代理查询和/或检索交易的方法；

一种用于服务层节点验证来自分布式分类账代理的分布式分类账中的交易状态的方法；以及

一种用于服务层节点订阅来自分布式分类帐代理的分布式分类帐中的交易的方法。

应当理解，本文公开的方法和系统不限于以上提供的示例。

在一个实施例中，用于互通服务层系统和分布式分类账系统的分布式分类账代理可以被配置为从服务层实体(例如，服务层节点)接收消息，该消息包括要存储在分布式分类帐系统中的分布式分类账节点处的数据，基于数据根据分布式分类帐系统的一个或多个规范生成交易，将与交易相关联的信息发送到分布式分类帐节点，从分布式分类帐节点接收交易已被分布式分类账节点确认的指示，并向服务层实体发送交易已被分布式分类账节点确认的指示。分布式分类帐系统可以包括多个分布式分类帐节点。该消息可以包括将数据存储在分布式分类账节点中的特定节点处的指示。

分布式分类账代理还可以被配置为生成从服务层实体(即，服务层节点和/或服务层应用实体)接收的数据与交易之间的映射。交易已被分布式分类账节点确认的指示可以包括以下至少之一：交易的标识符，从服务层实体接收的数据的标识符，以及从服务层实体接收的数据的哈希值。分布式分类帐代理还可以被配置为向服务层实体，并且在接收到交易已被确认的指示之前，发送响应，该响应包括交易正在等待分布式分类帐节点的确认的指示。分布式分类帐代理还可以被配置为从服务层实体接收包括其它数据的另一消息，其中，基于该数据和该其它数据来生成交易。

分布式分类帐代理还可以被配置为从服务层实体(即，服务层节点和/或服务层应用实体)接收请求从分布式分类账节点检索一个或多个交易的请求，从分布式分类账检索与一个或多个交易相关联的信息，并将与一个或多个交易相关联的信息发送到服务层实体。分布式分类账代理还可以被配置为从服务层实体接收请求验证一个或多个交易已被分布式分类账节点确认的请求，向分布式分类账节点发送请求确定该一个或多个交易是否已被分布式分类帐节点确认的请求，从分布式分类帐节点接收指示一个或多个交易已被分布式分类帐节点确认的指示，并向服务层实体发送指示一个或多个交易已被分布式分类帐节点确认的指示。分布式分类帐代理还可以被配置为从服务层实体接收请求在满足特定通知标准的分布式分类帐节点处接收有关交易的自动通知的请求。

在另一实施例中，分布式分类帐代理还可以被配置为从服务层实体(即，服务层节点和/或服务层应用实体)接收请求使用分布式分类账代理用于与分布式分类帐系统的分布式分类帐节点互通的一个或多个功能的请求，生成公共密钥和私有密钥对，至少基于公共密钥创建与服务层实体相关联的帐户，并将指示该帐户已被生成的指示发送到服务层实体。

分布式分类帐代理还可以被配置为向服务层实体(即，服务层节点和/或服务层应用实体)发送请求向服务层实体注册的请求，该请求包括指示分布式分类账代理支持一个或多个分布式分类账节点的指示，并从服务层实体接收包括一个或多个参数的响应，该一个或多个参数包括：从一个或多个分布式分类账节点中选择的分布式分类账节点的标识符，服务层实体所需的分布式分类帐节点的一个或多个属性，以及服务层实体的安全性和隐私要求。请求使用分布式分类帐代理的一个或多个功能的请求可以包括与一个或多个参数相关联的信息。分布式分类账节点的一个或多个属性可以包括以下一项或多项：分布式分类账节点的类型，与分布式分类账节点相关联的共识协议，与分布式分类账节点相关联的交易费用，用于在分布式分类账节点处添加新交易的延时，以及分布式分类帐系统中的完整分布式分类帐节点的数量。服务层实体可以维护注册到服务层实体的分布式分类帐代理的列表。分布式分类账代理还可以被配置为在服务层实体的标识符与公共密钥、私有密钥以及与所生成的账户相关联的标识符中的一个或多个之间生成映射。第一服务层实体可以向第二服务层实体发送与所添加的交易相关的一些信息(例如，如果交易已被成功添加到分布式分类帐，这些信息为交易的标识符、服务层信息和/或已被包括在交易中的其标识符等)。

在另一实施例中，第一服务层实体可以被配置为从第二服务层实体接收消息，该消息包括要存储在分布式分类账系统的分布式分类账节点上的数据，基于该数据确定用于在第一服务层实体和分布式分类帐节点之间进行互通的分布式分类账代理，将要添加到分布式分类帐节点的数据发送到分布式分类帐代理，从分布式分类帐代理接收指示交易已被生成的指示，并将与交易相关联的信息存储在第一服务层实体处。分布式分类帐代理可以被配置为基于该数据根据分布式分类帐系统的一个或多个规范生成交易。

分布式分类账代理可以被配置为生成交易和与第一服务层实体相关联的信息之间的映射。第一服务层实体还可以被配置为存储交易和与第一服务层实体相关联的信息之间的映射。该消息可以包括指示哪个服务层实体将向分布式分类账代理发送信息的指示。该信息可以包括指示何时应该将数据添加到分布式分类帐节点的指示。该交易可以包括第一服务层实体的标识符。

提供以下术语作为描述用于IoT服务层系统和分布式分类账系统之间的互通的方法的上下文。

分布式分类帐：由不同的分布式分类帐节点(DLN)维护并位于不同的分布式分类帐节点(DLN)处的分布式仅追加数据库。每个DLN处维护的分类帐是相同的。分类账基本上包含以各种结构分组在一起的交易(例如，比特币系统中的区块链)。

分布式分类帐系统：由DLN组成的系统，这些DLN一起工作但以分布式方式创建和维护分布式分类帐。通常，这些DLN通过底层对等(P2P)网络连接并相互通信。例如，比特币系统是分布式分类帐系统(DLS)。

分布式分类帐节点：创建和维护分类帐的逻辑节点。DLN具有若干其它DLN作为其对等方。每个DLN可以根据底层P2P网络协议向其对等DLN生成新消息，并且还可以将任何接收到的消息转发到其对等DLN(从其接收该消息的对等DLN除外)。没有假设DLN相互信任。DLN可以是“完整DLN”(例如，维护完整分类帐的DLN)或“轻型DLN”(例如，不维护完整分类帐的DLN)。

交易：在DLS中的DLN之间传输的最小消息单元(也称为DLS交易)。DLN(例如，比特币系统中的付款人)可以向另一个DLN(例如，比特币系统中的收款人)发布交易。每个已发布的交易可以基于底层P2P协议发送到发布者的对等DLN并由发布者的对等DLN转发，最终，DLS中的所有DLN都将接收到该交易。由于DLN以分布式方式工作，因此它们可能需要在交易被验证并存储在分布式分类帐中之前，就通过DLS发送的所有交易达成共识(例如，经由某些共识协议)。交易状态可以由DLN生成，发送到DLS(或由DLN从DLS接收)，和/或被追加到分布式分类帐并由DLS确认(例如，在每个参与DLN处运行共识协议之后)。

交易集：将若干交易分组在一起的结构(例如，比特币系统中的区块)。在某些DLS中，共识协议是在每个交易集上执行的，而不是在单个交易上执行的，以提高效率。

共识协议：DLN用于在通过DLS发送的所有交易被验证并存储在分布式分类帐中之前，对所有交易达成共识的协议。共识协议的示例是在比特币系统和建立在比特币系统之上的其它DLS中使用的工作量证明(PoW)。

分布式分类帐代理：可以与SLS和DLS二者都接口的逻辑节点。分布式分类帐代理(DLP)基本支持服务层功能和分布式分类帐功能二者。它可以是SLN和完整DLN的组合。

本文结合图8、图9、图10和图11描述了四个分布式分类账互通架构选项。基于这些互通架构选项，总体的互通过程在图12、13和14中简要地示出。然后，在分开的图中呈现了详细的过程，例如，图15用于DLP和SLN关联，图16、17和18用于将服务层信息添加到分布式分类账，图20用于从分布式分类帐中查询/检索交易，图21用于验证分布式分类账中的交易状态，以及图22用于订阅分布式分类帐中的交易。

本文描述了四个示例分布式分类帐互通选项。

提出了DLP作为SLS和DLS之间的新逻辑节点，以使它们互通在一起。DLP具有到SLS的接口作为SLN，以及到DLS的另一接口作为DLN。DLP可以支持多个不同的DLS，因此它可以为SLN或SLS选择适当的DLS。DLP可以注册到SLN，并且可以将交易格式发送到SLN。在将SLN用于在DLS中存储交易之前，SLN可能需要从DLP请求批准。作为此请求的一部分，如果DLP批准了该请求，则DLP可以为SLN创建DLS帐户。DLP从SLN接收请求，并进而执行如SLN请求的各种任务。同时，SLN可以连接到多个DLP，并且可以为不同的SL信息选择适当的DLP。SL处的SLN的唯一标识符可以在SLS中重新用作交易的发布者或接收方标识符。

图8示出了用于SLS利用DLS的互通架构选项1。SLS可以利用DLS存储许多类型的服务层信息和/或其摘要(例如，服务层请求/响应历史、服务层订阅通知记录、服务层注册历史、服务层资源历史、服务层数据访问记录等)。服务层(SL)位于分布式分类帐层(DLL)上方。分布式分类帐代理(DLP)被提议为一种互通功能实体，用于将服务层和分布式分类帐层连接在一起。DLP具有两个接口：到服务层节点(SLN)的服务层接口和到DLN的分布式分类帐接口。在此互通选项中，每个SLN连接到不同的DLP，使得可以在基础DLS中直接使用SLN标识符或其变体(例如，哈希(SLN标识符))。DLP可以是维护分类帐的完整DLN节点，也可以是不维护分类帐的轻型DLN节点。

当SLN需要利用DLS时(例如，SLN接收并批准新的SL注册，并且它想将该SL注册存储到DLS和分布式分类帐)，可以在SLN和相应的DLP处执行以下操作：

在阶段1，SLN首先需要找到合适的DLP并连接到它；然后，SLN向DLP发送SL消息(其中包含要存储在分布式分类帐中的服务层信息)或DLS交易。

在阶段2，在DLP处，来自SLN的一个或多个SL消息将根据DLS规范被转译为DLS交易，除非在步骤1中发送给DLP的SLN是DLS交易。一种方法是简单地将那些原始SL消息包含在DLS交易的主体中。可选地，DLP可以首先例如通过去除SL消息中的任何冗余信息或参数来压缩那些原始SL消息。请注意，来自SLN的一条SL消息可能会触发DLP生成新的DLS交易；替代地，DLP可以缓冲若干SL消息并将它们包含在一个DLS交易中。DLP可以保持在DLS交易和原始SL消息之间或者在DLS交易和原始SL消息的哈希值之间的映射。

在阶段3，像普通DLN这样的DLP将生成的DLS交易发送到DLS。此时，DLP可以向SLN发送快速响应，以通知它若干SL消息已被组装到DLS交易中，并且DLS交易已被插入到DLS中，但它正在等待确认。该响应消息可以包含DLS交易的标识符、包含在DLS交易中的SL消息的标识符、以及关于DLS交易的其它元数据。

在阶段4，在DLS交易在DLS内被确认并被追加到分类账之后，DLP可以将另一个SL响应或通知发送回SLN。该SL响应可以包含DLS交易的标识符、已经被转译成DLS交易的原始SL消息的标识符、已经被转译成DLS交易的原始SL消息的哈希值等等。

图9示出了用于SLS利用DLS的替代互通架构选项2。与选项1的区别在于，选项2中的DLP1可以支持多个SLN。在这种情况下，DLP1仍可以使用SLN的唯一标识符(例如，SLN1或SLN2)作为要在DLP1处生成的每个DLS交易的发布者，因此DLP1可能需要管理多个DLS用户或帐户(每个SLN一个)。替代地，DLP1可以使用其自己的标识符作为每个DLS交易的发布者，并且可能仅需要管理一个DLS帐户。然而，DLP1可能需要将每个SLN的标识符添加到生成的交易中，或者维护在每个DLS交易的标识符与已发布如DLS交易中包含的SL消息的相应SLN的标识符之间的单独映射。

图10示出了用于SLS利用DLS的另一替代互通架构选项3。与选项1的区别在于，选项3中的SLN可以连接到多个DLP，但是每个DLP仍可以仅支持一种类型的SLS(例如，oneM2M、开放式互连基金会、万维物联网等)，如同选项1。由于各种DLP可以支持不同类型的DLS(例如，公共分类帐、私有分类帐等)，并且每个DLS可以使用不同的共识协议和交易语义，因此SLN可以基于其需求选择最适合的DLP。例如，一些高度敏感的数据访问记录可以存储在私有分类帐中(例如，图中的DLS A)，而敏感度较低的服务层请求历史可以存储在公共分类帐中(例如，图中的DLS B)。

图11示出了用于SLS利用DLS的互通架构选项4，其中一个单个DLP可以连接到并且支持多种类型的DLS。换句话说，DLP维护多个分类帐，并且每个分类帐对应于不同的DLS。对于这种情境，SLN可以执行与选项1相同的方式，但是DLP可能需要为连接到DLP的SLN选择最适合的DLS。所选择的DLS对SLN可以是透明的。替代地，DLP可以将其支持的DLS类型通知给SLN；然后，SLN本身可以选择适合的DLS(类似于选项3)。

本文公开了用于分布式分类帐互通的过程。

SLS和DLS之间的互通主要集中于SLN可以如何利用由DLS提供的功能(例如，建立仅追加、不可否认和不可篡改的分布式数据库)。这是通过在SLN和DLP之间提议新的交互(例如，DLP和SLN关联)，将SL信息添加到分布式分类帐，查询/检索分布式分类帐中的交易，验证分布式分类帐中的交易状态，以及订阅分布式分类帐中的交易来实现的。

图12示出了在SLN具有SL交互之后将SL信息添加到分布式分类帐的示例总体过程。该图所示的过程适用于互通的选项1和选项2，并且详细情况将在其它图中进行讨论。发起方SLN或接收方SLN任一方均可以与其DLP交互，以将SL信息存储到分布式分类帐。为了便于描述，在以下描述中使用SLN1和DLP1，它们可以直接应用于SLN2和DLP2。

在步骤1，将SLN1和DLP1彼此关联。作为此步骤的一部分，DLP1可以首先向SLN1注册；替代地，DLP1可以将自身注册到第三方存储库(例如，DNS-SD服务器)，而SLN1可以从第三方存储库中发现DLP1。然后，SLN1可以从DLP1请求批准，以利用其功能来与DLS互通。

在步骤2，SLN1和SLN2如常交换现有的SL原语。

在步骤3，在完成步骤2中SLN1和SLN2之间的SL交互之后，可以触发SLN1或SLN2任一方以利用DLS来存储有关步骤2或任何先前SL交互的一些SL信息。

在步骤3.1，SLN1向DLP1发送消息。该消息可以包含要存储在DLS中的SL信息。替代地，SLN1可以直接生成DLS交易并将其发送到DLP1(如果它知道DLS交易的格式)，该格式可以在步骤1中从DLP1发送到SLN1。

在步骤3.2，如果DLP1在步骤3.1接收到DLS交易，则它可以简单地将DLS交易转发到其对等DLN。否则，DLP1缓冲接收到的SL信息，并立即或稍后生成DLS交易。

在步骤3.3，在将DLS交易添加到DLS(并且可选地由对等DLN验证)之后，DLP1将响应发送回SLN1。

在步骤4，SLN1可以查询和检索先前已经由DLP1添加到DLS的任何DLS交易。

在步骤5，SLN1可以验证一条SL信息或DLS交易是否已成功添加到DLS并由DLS验证。

在步骤6，SLN1可以订阅DLP1，以接收有关从DLS接收到并且满足某些通知标准的新的DLS交易的自动通知。

图13示出了用于SLN将SL信息添加到分布式分类账的示例总体过程。此图中示出的过程适用于互通架构选项3，并且详细信息将在其它图中讨论。注意，图13类似于图12，步骤3除外：

在步骤3，互通架构选项3中的情境，SLN1(或SLN2)连接到多个DLP(例如，DLP1和DLP2)或与多个DLP相关联。在SLN1向DLP发送SL信息(或生成DLS交易)之前，它首先需要选择适合的DLP。选择标准可以基于：要添加到DLS的SL信息的类型，要添加到DLS的SL信息所涉及的发起方(或接收方)，安全性和/或隐私要求级别，有关向DLS添加DLS交易的延时要求，当前时间，当前位置，不同DLS所需的交易费用，和/或有关SLN1或DLS的其它上下文信息。

图14示出了用于SLN将SL信息添加到分布式分类帐的示例总体过程。该图所示的过程适用于互通架构选项4，并且详细信息将在其它图中讨论。注意，图14类似于图12，步骤3.2除外：

在步骤3.2，对于互通架构选项4中的情境，DLP1维护多个分布式分类帐，每个分布式分类帐用于不同的DLS。来自SLN1的将SL信息添加到分布式分类帐的请求可能不会指示目标DLS。因此，DLP1可能需要为SLN1选择适合的DLS。选择标准可以基于：可以在步骤3.1中传达的来自SLN1的一些提示(例如，目标DLS的类型)，要添加到DLS的SL信息的类型，来自SLN1的安全性和/或隐私要求级别，用于添加DLS交易的DLS的延时，和/或有关SLN1或DLS的其它上下文信息。注意，在图14中与SLN2进行通信的DLP可以是另一个DLP2。

本文公开了用于DLP和SLN关联的方法和系统。

DLP可以将其自身注册到SLN，并且因此SLN可以维护已注册DLP的列表。其它SLN可以搜索和检索此列表，以查找适合的DLP以其使用。在利用DLP提供的功能(例如，构建仅追加、不可否认和不可篡改的分布式数据库)之前，SLN可能需要从DLP请求批准；在此过程中，SLN可以将任何目标DLS通知DLP，并且DLP可以将指定的交易格式发送到SLN。此外，DLP可以为SLN创建DLS帐户。

图15示出了用于DLP和SLN关联的示例过程，并且在下面详细描述：

在步骤1，DLP注册到SLN1。DLP可以将以下信息通知SLN1：

DLP支持的DLS列表(包括其属性)。DLS的属性可以是，例如：DLS的名称或标识符、其类型(例如，私有、公共)、共识协议(例如，PoW)、交易费用、添加新交易的延迟、DLS中的完整DLN节点数目等等；和/或

每个DLS中作为DLN的DLP的标识符(例如，帐户地址或公共密钥)。

在步骤2，SLN1向DLP发送响应。SLN1可以将以下信息通知DLP：

targetDLS：从步骤1中发送的DLS列表中选择的目标DLS ID；

ExpectedDLSProperty：如果在步骤1中DLP没有发送DLS列表，则为目标DLS的期望属性；以及

spRequirement：来自SLN1的安全性和隐私要求。

在步骤3中，SLN1维护已注册DLP的列表和可能的相应DLS的列表，如果在步骤1中DLP提供了它们。

在步骤4，SLN1请求DLP批准使用其功能来与DLS互通。该消息可以包含以下信息(例如，如果步骤2中未包含)：

targetDLS：从步骤1中发送的DLS列表中选择的目标DLS ID；

ExpectedDLSProperties：如果在步骤1中DLP没有发送DLS列表，则为目标DLS的期望属性；以及

spRequirement：来自SLN1的安全性和隐私要求。

在步骤5，可以为SLN1创建DLS帐户。DLP首先可以为SLN1生成私有密钥和公共密钥对。替代地，可以通过用于分发安全密钥的第三方认证机构来获得公共-私有密钥。然后，DLP可以为SLN1创建DLS帐户。DLS帐户的标识符(例如，dlsAccountID)可以是所生成的公共密钥或其哈希值。DLP可以维护SLN1的SL标识符与所生成的SLN1的私有密钥、公共密钥和dlsAccountID之间的映射表(例如，表1中的第二行)。使用此映射，DLP能够基于SLN的标识符找到任何SLN的dlsAccountID(及其私有密钥/公共密钥)，SLN的标识符可以由任何其它SLN给出。

在步骤6，DLP向SLN1发送响应。该消息可能包含以下信息：

targetDLS：为SLN1选择和/或确认的目标DLS ID；

txFormat：用于目标DLS的交易格式(例如，交易模板)；

maxTxRate：SLN1所允许的最大交易产生速率；

slnPubicKey：在步骤5为SLN1生成的公共密钥；

slnPrivateKey：在步骤5为SLN1生成的私有密钥。如果SLN1和DLP之间没有安全通信，则此参数将不被包括在步骤6中；以及

dlsAccountID：在步骤5为SLN1生成的DLS帐户的标识符。

在步骤7，SLN2从SLN1发现DLP。来自SLN2的发现标准可以包括所支持的DLS的类型、共识协议的类型等。SLN1搜索在步骤3中创建和维护的已注册DLP的列表。

在步骤8，SLN1向SLN2发送响应。该响应可以包含所发现的DLP的列表，包括它们的地址和可选地其它信息(例如，每个所发现的DLP支持的DL S列表)。

步骤9可以类似于步骤4。

步骤10可以类似于步骤5。

步骤11可以类似于步骤6。

表1：用于SLN的DLS账户

本文公开了用于将服务层信息添加到分布式分类账的方法和系统。

作为发起方或接收方的SLN可以将SL信息(例如，服务层请求原语)发送给DLP，DLP可以将SL信息转译为DLS交易，并根据DLS规范将DLS交易添加到分布式分类账中。DLP可以维护SL信息和相应的DLS交易之间的映射，并且可以将该映射发送到SLN。附加地或替代地，SLN可以基于从DLP接收到的交易格式将SL信息组装到DLS交易中。然后，SLN可以将所生成的交易发送到DLP，DLP可以根据DLS规范将其添加到分布式分类帐中。

图16示出了用于SLN将SL信息添加到DLS的示例过程。在这种情境中，SLN1和SLN2交换SL原语。SLN2然后可以决定将一些SL信息发送到DLP。DLP可以将接收到的SL信息转译为DLS交易，并将其添加到DLS。请注意，SLN1和SLN2可以不具有任何已建立的信任或注册，例如，如果两者都以ad hoc模式部署或两者属于不同的服务提供商。通过利用此过程将所交换的SL信息存储到分布式分类帐，既不能否认也不能伪造它们之间的先前交互。

在步骤1，SLN1向SLN2发送SL请求原语。该请求中可以包含“DL指示”，以指示SLN2将请求原语(和/或步骤2中的响应消息)添加到DLS。作为示例，“DL指示”可以包括以下参数：

dlAction：指示SLN1或SLN2是否需要触发将SL信息添加到DLS。例如：

dlAction＝0：SLN1或SLN2都不需要利用DLS。在这种情况下，可能不需要其它参数。

dlAction＝1：SLN1负责利用DLS。在这种情况下，步骤1可能不需要targetDLP和typeOfTargetDLS。

dlAction＝2：SLN2负责利用DLS。

dlScope：指示要将哪个SL信息添加到DLS。例如，

dlScope＝1：将整个请求原语添加到DLS。

dlScope＝2：将整个响应原语添加到DLS。

dlScope＝3：将请求和响应原语均添加到DLS。

dlScope＝4：将请求原语的报头添加到DLS。

dlScope＝5：将响应原语的报头添加到DLS。

dlScope＝6：将请求和响应原语的报头均添加到DLS。

dlScope＝7：如dlScopeNode所指示的，将从SLN2到另一个SLN的下一个请求原语添加到DLS中。

dlScope＝8：如dlScopeNode所指示的，将从另一个SLN到SLN2的下一个请求原语添加到DLS。

dlScopeNode：指示另一个SLN。

dlsAccountID：SLN1的DLS帐户ID。

targetDLP：指示目标DLP的地址。如果包括此参数，则可以不需要typeOfTargetDLS。

typeOfTargetDLS：指示SLN1要求或偏好利用的SLN2的目标DLS的类型。SLN2可以基于此参数来选择适合的DLP。

在步骤2，SLN2接收SL请求原语并处理所包含的“DL指示”。如果dlAction＝2，则SLN2可以确定最终的targetDLP(例如，根据步骤1中包含的typeOfTargetDLS)。SLN2生成SL响应原语，并将其发送给SLN1。响应原语可以包含SLN2选择的最终targetDLP和dlScope，要包含在DLS交易中的SL信息的哈希值以及SLN2的dlsAccountID。替代地，如果dlAction不等于1，则SLN2可以在步骤8之后将此响应原语发送给SLN1。在这种情况下，可以在此响应原语中包含相应DLS交易的标识符(如果通过步骤7发送了一个DLS交易)。

在步骤3，SLN2将特定SL信息发送到DLP。该步骤中包含的SL信息可以基于步骤1中包含的dlScope确定；否则，SLN2可以由应用程序预先配置或以“dlScope”提供。另外地或替代地，当SLN1将自身注册到SLN2时，可以将“dlScope”提供给SLN2。在此步骤中，SLN2可以包含以下参数：

dlStart：指示DLP应该何时启动将SL信息添加到DLS。例如，dlStart＝atOnce：立即启动。

dlStart＝timePeriod：在dlStart中包含的时间段后启动。

dlStart＝numOfSLInfo：在从SLN2接收到numOfSLInfo条SL信息后启动。

slInfoID：此步骤中包含的整个SL信息的唯一标识符。

slInfoHashFlag：指示DLP需要压缩接收到的SL信息(例如，使用哈希函数)，例如，当slInfoHashFlag＝TRUE时。

recipientID：作为在步骤4中生成的DLS交易的接收方的SLN的DLS帐户ID。接收方可以是SLN1或其它SLN。

在步骤4，DLP从SLN2接收SL信息。如果dlStart＝atOnce，则如果DLP支持多个DLS，则DLP可以首先基于其在“DLP和SLN关联”期间与SLN2交换的信息来选择适合的DLS，然后根据所选择的DLS中使用的交易格式生成DLS交易，并使用SLN2的私有密钥对其进行分配(假设SLN2是此DLS交易的发布者)。例如，在步骤3中接收到的整个SL信息可以被包含作为所生成的DLS交易的有效载荷。如果dlStart不是“atOnce”，则DLP可以缓冲接收到的SL信息，并使用设置为dlStart中所包含的值来启动定时器(或计数器)。DLP可以直到定时器到期或计数器(每次DLP从SLN2接收到SL信息时，计数器可以增加1)超过numOfSLInfo才生成DLS交易。可选地，DLP可以将SL信息进行哈希或压缩为具有较短大小的值，并且可以在所生成的DLS交易中仅包含经哈希的值(例如，当步骤3中包含的slInfoHashFlag具有值TRUE时)。交易实例的例子在图17中示出，其中此交易的发布者是SLN2，而接收方是SLN1。所提议的交易格式可以具有以下字段：

issuerID：发布者的dlsAccountID。在此示例中，发布者是SLN2。

recipientID：从步骤3接收到的接收方的DLS帐户ID。在此示例中，接收方为SLN1。

otherFields：特定于DLS或可用于未来扩展的其它字段或参数。

txTransaction：以如下方式包含SL信息的交易有效载荷为例：

txPurpose：指示该交易的目的(例如，“与SLS1互通”)。

slInfoType：指示该交易中包含的SL信息的类型。它可以是“原始(未经哈希)”或“经哈希”。

numOfSLInfo：指示该交易中包含的SL信息的数量。

slInfoSize：指示SL信息的大小。

slInfoContent：指示SL信息的内容，其可以是原始SL信息或原始SL信息的哈希值，取决于slInfoType的值。

Signature：交易报头的哈希值加上针对发布者的私有密钥的交易有效载荷，其由DLP在“DLP和SLN关联”期间创建。

在步骤5，DLP根据DLS规范将所生成的DLS交易发送到其对等DLN。

当对等DLN接收到该交易时，它可以验证该交易是否有效。作为此过程的一部分，它可以等待或联系另一个为SLN1服务的DLP(称为DLP4SLN1)，以进一步验证交易中的SL信息是否真正用于SLN1。这样，DLP4SLN1可以从交易中提取所包含的信息，并将其发送到SLN1以供验证。

在步骤6，DLP创建并维护所生成的DLS交易与SL信息或其经哈希的值之间的映射。请注意，步骤6可以在步骤5之前但在步骤4之后发生，也可以就作为步骤4的一部分。

在步骤7，DLP将响应发送回SLN2。响应消息可以包含例如在步骤4中所生成的DLS交易的标识符(如果有的话)、包含在DLS交易中的每个SL信息的哈希值、和/或包含在DLS交易中的每个SL信息的slInfoID。

在步骤8，SLN2从DLP接收响应，并存储包含在响应中的信息(例如，以维护SL信息和相应DLS交易之间的映射)。

在步骤9，在稍后的某个时间，将在步骤5中发送的DLS交易成功添加到新的交易集(例如，以太坊系统中的区块)，该交易集已经由DLS中的所有DLN进行了验证。

在步骤10，DLP根据DLS中使用的共识协议来验证交易集，并更新在步骤5中发送的DLS交易的状态信息。例如，其状态可以更改为“已确认”，并且交易集的标识符可以被添加到其中。

在图16中，应当理解，从SLN2到DLP的步骤3也可以是从SLN1到DLP(例如，如果步骤1中的dlAction＝1，表示SLN1应该负责将SL信息添加到分布式分类帐中)。然后，步骤7可以从DLP到SLN1。还应当理解，步骤1和步骤2不是强制的。SLN2处的一些本地事件(例如，将新通知发送给订阅者或通知目标，SLN2只是转发从另一个SLN3发送到另一个SLN4的SL消息，等等)，可以触发SLN2启动步骤3以与DLP通信。

图18示出了结合图16描述的方法的示例替代过程。在此替代过程中，SLN2(或SLN1)知道DLS交易的格式，并相应地针对要存储在分布式分类帐中的SL信息生成DLS交易。因此，SLN2(或SLN1)发送给DLP的不是朴素的SL信息，而是DLS交易。

步骤1可以与图16中的步骤1相同。

步骤2可以与图16中的步骤2相同。然而，图18中的步骤2可以在步骤3之后发生；在这种情况下，所生成的DLS交易的标识符可以包含在对SLN1的响应原语中。

在步骤3中，SLN2根据在“DLP和SLN关联”期间从DLP获得的交易格式来生成DLS交易。

步骤4可以与图16中的步骤6相同。

在步骤5，SLN2将DLS交易发送到DLP。

在步骤6，DLP将DLS交易转发到DLS中的其对等DLN。

在步骤7，DLP向SLN2发送响应。

步骤8可以与图16中的步骤9相同。

在步骤9，DLP通知SLN2：DLS交易已成功添加到DLS并已被确认。在该消息中，DLP可以包括步骤8中从对等DLN接收到的交易集信息。

在图18中，应当理解，从SLN2到DLP的步骤3也可以是从SLN1到DLP(例如，如果步骤1中的dlAction＝1，表示SLN1应该负责将SL信息添加到分布式分类帐中)。然后，SLN1可以处理步骤3-步骤9，如图中针对SLN2所示。此外，步骤1和步骤2可以不是强制的。SLN2处的某些本地事件(例如，将新通知发送给订阅者或通知目标)可以触发SLN2启动步骤3以与DLP通信。

图19示出了用于将服务层信息添加到分布式分类帐的另一替代过程。在此示例中，SLN1和SLN2以ad hoc模式部署，但是它们不具有注册关系。SLN1和SLN2利用DLS来存储其SL原语，并且每一个都可以与DLP相关联(例如，DLP1用于SLN1，DLP2用于SLN2)。换句话说，发起方SLN1首先将SL请求原语经由DLP1添加到DLS，然后其再将SL请求原语发送给接收方SLN2。同样，SLN2可能也需要经由DLP2将SL响应原语添加到DLS，然后其再将SL响应原语发送给SLN1。请注意，DLP1和DLP2是两个逻辑实体，并且它们可以是相同的DLP。可以需要以下示例步骤：

在步骤1，SLN1准备SL请求原语。

在步骤2，SLN1将SL请求原语发送到DLP1。替代地，SLN1可以将SL请求原语组装到DLS交易中，并将DLS交易发送到DLP1。

在步骤3，DLP1从步骤2接收消息，并将相应的SL信息添加到DLS。

在步骤4，DLP1将DLS交易ID发送到SLN1。

在步骤5，在从DLP1接收到响应并且知道SL请求原语已成功添加到DLS之后，SLN1基于SL协议将SL请求原语发送到SLN2。在此步骤中，SLN1还附带来自步骤4的DLS交易ID1。

在步骤6，在从SLN1接收到SL请求原语之后，SLN2与DLP2联系以验证具有DLS交易ID1的交易是否先前已被添加到分布式分类帐。

在步骤7，DLP2向SLN2发送响应。

在步骤8，如果如步骤7所指示的，具有DLS交易ID1的交易已被添加到分布式分类帐，则SLN2准备SL响应原语。

在步骤9，SLN2将SL响应原语发送到DLP2。替代地，SLN2可以将SL响应原语组装到DLS交易中，并将DLS交易发送到DLP2。

在步骤10，DLP2从步骤9接收消息，并将相应的SL信息添加到DLS。

在步骤11，DLP2将DLS交易ID发送到SLN2。

在步骤12，在从DLP2接收到响应并且知道SL响应原语已被成功添加到DLS之后，SLN2基于SL协议将SL响应原语发送到SLN1。SLN2还可以在此步骤中附带来自步骤11的DLS交易ID2。

在步骤13，在从SLN2接收到SL响应原语之后，SLN1与DLP1联系以验证具有DLS交易ID2的交易是否先前已被添加到分布式分类帐。

在步骤14，DLP1向SLN1发送响应。

在步骤15，如果如步骤14所指示的，具有DLS交易ID2的交易已被添加到分布式分类帐，则SLN1可以另外向SLN2发送确认消息。

本文公开了用于从分布式分类账查询和/或检索交易的方法和系统。

SLN可以将交易过滤器发送到DLP，以查询和可能地检索分布式分类帐中的交易。作为响应，DLP可以将找到的交易的列表(例如，其标识符、其内容或两者)发送给SLN。例如，在接收方SLN请求DLP将SL信息添加到分布式分类账之后，相应的发起方SLN可以将交易标识符(从发起方SLN的通知中获取)作为过滤器，以从同一DLP检索交易内容，例如，以验证交易是否包含原始SL信息。

图20示出了用于SLN从维护分布式分类帐的DLP查询/检索交易的过程。

在步骤1，SLN向DLP发送查询请求。该请求可以包含交易过滤器(例如，txFilter)。txFilter可以包含一个或多个交易属性(例如，创建时间、交易标识符、DLS交易中已包含的SL信息的哈希值等)

在步骤2，DLP基于步骤1中包含的txFilter来发现匹配的DLS交易。DLP可以将所发现的交易的标识符或每个所发现的交易的内容返回给SLN。

在步骤3，如果步骤2仅包含所发现的交易的标识符，则SLN可以将该标识符发送给DLP，以供检索交易内容。

在步骤4，DLP将交易内容发送到SLN。

本文公开了用于验证分布式分类账中的交易状态的方法和系统。

SLN可以请求DLP检查或验证先前已创建为包含SL信息的DLS交易的当前状态。SLN可以将某些交易属性(例如，交易标识符)提供给DLP，使得DLP可以定位正确的交易。

例如，在接收方SLN请求DLP将SL信息添加到分布式分类账之后，相应的发起方SLN可以将交易标识符发送到DLP以检查当前交易状态。

在另一示例中，如果两个SLN(SLN1和SLN2)都以ad hoc模式部署或属于不同的服务提供商，则它们可以不具有任何服务层注册关系。在这种情况下，在两者都执行SL交互之后，SLN1(或SLN2)可以使用图16中描述的过程，来将其SL交互信息添加到分布式分类帐。然后，SLN2(或SLN1)可以使用图21中描述的过程，来验证其先前与SLN1的交互是否确实已被添加到分布式分类帐。

图21示出了用于SLN验证DLS交易和/或一条SL信息是否已被成功地添加到DLS并被DLS确认的示例过程。

在步骤1，SLN向DLP发送消息，以验证DLS交易或一条SL消息的状态。该状态可以是例如：已缓冲但尚未添加到DLS、已添加但尚未被DLS确认、已被DLS确认等等。此消息可以包含以下参数：

dlsTxID：DLS交易的标识符，它可以由SLN、DLP或其它SLN/DLP在先生成。该参数可以包含DLS交易标识符的列表。

slInfoID：先前已经从SLN(不一定是图21上的相同SLN)发送到DLP(不一定是图21上的相同SLN)的一条SL信息(例如，SL请求消息)的标识符。该参数可以包含SL信息标识符的列表。

slInfoHash：先前已经从SLN(不一定是图21上的相同SLN)发送到DLP(不一定是图21上的相同SLN)的一条SL信息(例如，SL请求消息)的哈希值。此参数可以包含SL信息哈希值的列表。

previousStatus：SLN知道并想要验证的DLS交易或一条SL信息的状态。此参数可以是可选的。

dlsAccountIDForIssuer：发布者的DLS帐户ID。

dlsAccountIDForRecipient：接收方的DLS帐户ID。

在步骤2，DLP根据步骤1中包含的参数搜索本地维护的相应分布式分类帐或搜索所维护的SL信息与相应DLS交易之间的映射。DLP查找相应DLS交易或SL信息的当前状态，如步骤1所指示的。然后，如果在步骤1中已包括previousStatus，则DLP将当前状态发送到SLN或仅将验证结果(例如，TRUE或FALSE)发送到SLN。

本文公开了用于订阅分布式信件交易的方法和系统。

SLN可以向DLP作出订阅，意图从DLP接收针对某些交易相关的事件的未来自动通知(例如，当只是将包含SL信息的新的DLS交易添加到DLS时)。当期望的事件发生时，DLP可以向SLN发送通知。该通知可以包含与该事件有关的DLS交易的标识符或全部内容。

例如，如果两个SLN(SLN1和SLN2)均以ad hoc模式部署或属于不同的服务提供商，则它们可以不具有任何服务层注册关系。在这种情况下，在两者都执行SL交互之后，SLN1(或SLN2)可以使用图16中的过程，以将其SL交互信息添加到分布式分类帐。然后，SLN2(或SLN1)可以使用图22中的过程，以订阅由SLN1(或SLN2)添加的任何DLS交易。然后，当服务于SLN2的DLP接收到由SLN1添加的DLS交易时，DLP可以向SLN2发送自动通知。

图22示出了当新的DLS交易被生成、添加和/或确认到DLS时，用于SLN向DLP作出订阅以接收自动通知的方法。

在步骤1，SLN向DLP发送订阅请求，该请求经由参数txCriteria通知DLP通知条件。txCriteria例如可以基于：DLS交易的状态(例如，被生成、被添加和/或被确认)、DLS交易的发布者(例如，来自特定的SLN或DLP)、DLS交易的生成时间、DLS交易的大小、DLS交易的内容类型(例如，SL请求原语、关于SL响应原语、SL请求/响应原语的特定类型等)、和/或其它DLS交易属性。

在步骤2，DLP处理订阅请求，并将响应发送给SLN。

在步骤3，满足txCriteria的新的交易已由DLP生成(或接收)，已由DLP或其它DLP添加到DLS，和/或已向DLS确认。

在步骤4，DLP将通知发送给SLN。该通知可以包含满足txCriteria的DLS交易的标识符或全部内容。

在步骤5，SLN向DLP发送响应。

本文公开的SLN和DLP之间的交互可以在oneM2M服务层中实现。因此，提议了一些新的oneM2M资源、新的oneM2M属性、新的oneM2M请求参数、新的oneM2M响应参数以及新的oneM2M RESTful操作。另外，与SLN交互所涉及的DLP功能可以实现为oneM2M RESTful操作。例如，oneM2M CSE(甚至是AE)可以使用本文描述的过程，来在DLP处创建DLS交易。在这种情况下，DLP维护<dlsTx>资源，并充当oneM2M托管CSE。

基于所公开的方法和系统，CSE可以将存储在任何oneM2M资源(例如，在<request>资源中、关于AE或CSE注册的事件、与现有<subscription>资源有关的通知事件等)中的SL信息组装到DLS交易，并将其发送到DLP，或者它可以简单地将SL信息发送到DLP，在DLP处将基于SL信息生成DLS交易。然后，DLP帮助将DLS交易添加到分布式分类帐。在这两种情况下，CSE都可能需要将DLS交易信息记录在原始的oneM2M资源中，例如，使用表2中提出的新属性。

例如，oneM2M将<request>指定为资源类型，其仅可以由于来自发起方CSE的请求，该发起方CSE请求在请求消息中包含响应类型参数，并且其中响应类型参数设置为“nonBlockingReqeustSynch”或“nonBlockingRequestAsynch”，而由接收方CSE隐式创建。接收方CSE可以借助DLP将<request>资源存储到分布式分类帐中。

表2：新的共有属性

在一个示例中，发起方CSE可以在oneM2M请求原语中包含“DL指示”，以通知接收方CSE是否以及如何将请求原语中包含的SL信息添加到分布式分类账。相应地，提议了若干新的oneM2M请求参数，如表3所示。这些新的请求参数也可以作为针对oneM2M<request>资源类型的新属性引入。

表3：新的请求原语参数综述

在一个示例中，接收方CSE可以在oneM2M响应原语中包含一些有关“DL指示”的最终决定，以通知发起方CSE是否以及如何将包含在请求和/或响应原语中的SL信息添加到分布式分类帐。相应地，在表4中提议并描述了若干新的oneM2M响应参数，接收方CSE可以将其包含在响应原语中，以发送给发起方CSE。

表4：新的响应原语参数综述

dlsTxTemplate表示在DLS中使用的交易格式。DLP可以在CSE处创建dlsTxTemplate，其可以由其它AE/CSE发现和检索，如果其它AE/CSE需要为特定SL信息创建DLS交易。请注意，DLP可以是CSE或AE。dlsTxTemplate资源的结构在图23中说明。<dlsTxTemplate>资源可以包含表5中指定的子资源。

表5：<dlsTxTemplate>资源的子资源

<dlsTxTemplate>资源可以包含表6中指定的属性。

表6：<dlsTxTemplate>资源的属性

图24示出了操作<dlsTxTemplate>资源(例如，创建/检索/更新/删除<dlsTxTemplate>资源)的示例过程。发起方可以是CSE或AE，而接收方可以是CSE。分别在表7、表8、表9和表10中给出了详细描述。

图24所示的过程可以用于创建<dlsTxTemplate>资源，如表7中所描述的。

表7：<dlsTxTemplate>创建

图24中所示的过程可以用于检索现有<dlsTxTemplate>资源的属性，如表8所描述的。

表8：<dlsTxTemplate>检索

图24中所示的过程可以用于更新现有的<dlsTxTemplate>资源。如表9中所描述的。

表9：<dlsTxTemplate>更新

图24中所示的过程可以用于删除现有的<dlsTxTemplate>资源，如表10中所描述的。

表10：<dlsTxTemplate>删除

dlsTx表示可以在CSE或DLP处生成的DLS交易。dlsTx资源的结构在图25中示出。<dlsTx>资源可以包含表11中指定的子资源。

表11：<dlsTx>资源的子资源

<dlsTx>资源可以包含表12中指定的属性。

表12：<dlsTx>资源的属性

图26示出了操作<dlsTx>资源(例如，创建/检索/更新/删除<dlsTx>资源)的示例过程。发起方可以是CSE或AE，而接收方可以是CSE。分别在表13、表14、表15和表16中给出了详细描述。

图26中所示的过程可以用于创建<dlsTx>资源，如表13所描述的。

表13：<dlsTx>创建

图26中所示的过程可以用于检索现有的<dlsTx>资源的属性，如表14中所描述的。

表14：<dlsTx>检索

图26所示的过程可以用于更新现有的<dlsTx>资源，如表15所描述的。

表15：<dlsTx>更新

图26所示的过程可以用于删除现有的<dlsTx>资源，如表16所描述的。

表16：<dlsTx>删除

图27示出了用于配置DLP并显示所配置的DLP的信息的示例用户界面。例如，用户界面可用于配置包括DLP的端口号在内的地址；配置要存储在DLS中的SL信息的类型；显示包括DLP端口号在内的地址；和/或显示DLP使用的共识协议

图28示出了用于DLP的示例用户界面，其可以显示以下信息：相关联的SLN的地址；SLN上次向DLP发送SL信息或DLS交易的时间；和/或分类帐相关信息(例如，来自SLN或针对SLN生成的DLS交易的数量、自上次交易集起经过的时间等等)。

执行图1-22、24和26所示的步骤的任何实体，诸如服务层、服务层设备、服务层应用程序、应用程序实体等，可以是逻辑实体，其可以以软件(即，计算机可执行指令)的形式实现，软件被存储在以下各项的存储器中并在以下各项的处理器上执行：被配置用于无线和/或网络通信的装置或计算机系统，诸如图29C或图29D所示的那些。也就是说，图1、3、6-18、20和21所示的(一个或多个)方法可以以软件(即，计算机可执行指令)的形式来实现，软件被存储在装置(诸如图29C或图29D所示的装置或计算机系统之类的装置)的存储器中，该计算机可执行指令在由装置的处理器执行时，执行图1、3、6-18、20和21所示的步骤。还应理解，图1、3、6-18、20和21所示的任何发送和接收步骤可以由装置/实体的通信电路在装置的处理器及其执行的计算机可执行指令(例如，软件)的控制下执行。

图29A是其中可以实现一个或多个所公开的实施例的示例机器到机器(M2M)、物联网(IoT)或万维物联网(WoT)通信系统10的图。通常，M2M技术为IoT/WoT提供构建区块，并且任何M2M设备、M2M网关、M2M服务器或M2M服务平台都可以是IoT/WoT的组件或装置以及IoT/WoT服务层等。在图1-22、24和26中任何一个中所示的任何实体均可以包括通信系统的网络装置，例如图29A-29D中所示的那些。

服务层可以是网络服务架构内的功能层。服务层通常位于应用协议层(例如，HTTP、CoAP或MQTT)之上，并为客户端应用程序提供增值服务。服务层还提供到较低资源层(例如，控制层和传输/接入层)的核心网络的接口。服务层支持(服务)能力或功能的多种类别，包括服务定义、服务运行时启用、策略管理、接入控制和服务群集。最近，若干行业标准机构，例如oneM2M，已经在开发M2M服务层，以解决与将M2M类型的设备和应用程序集成到诸如互联网/Web、蜂窝、企业和家庭网络之类的部署中相关联的挑战。M2M服务层可以向应用程序和/或各种设备提供对服务层所支持的上述能力或功能的组合或集合的访问，该服务层可以被称为CSE或SCL。一些示例包括但不限于安全性、收费、数据管理、设备管理、发现、供应和连接管理，这些可以是各种应用程序普遍使用的。这些能力或功能可以经由API而对各种应用程序可用，这些API利用M2M服务层定义的消息格式、资源结构和资源表示。CSE或SCL是可以由硬件和/或软件实现的功能实体，并且提供暴露给各种应用程序和/或设备(即，这些功能实体之间的功能接口)的(服务)能力或功能，以便它们使用此类能力或功能。

如图29A所示，M2M/IoT/WoT通信系统10包括通信网络12。通信网络12可以是固定网络(例如，以太网、光纤、ISDN、PLC等)或无线网络(例如，WLAN、蜂窝等)或异构网络的网络。例如，通信网络12可以包括向多个用户提供诸如语音、数据、视频、消息接发、广播等内容的多个接入网络。例如，通信网络12可以采用一种或多种信道接入方法，例如码分多址(CDMA)、时分多址(TDMA)、频分多址(FDMA)、正交FDMA(OFDMA)、单载波FDMA(SC-FDMA)等。此外，通信网络12可以包括其它网络，诸如核心网络、互联网、传感器网络、工业控制网络、个人局域网、融合个人网络、卫星网络、家庭网络或企业网络。

如图29A所示，M2M/IoT/WoT通信系统10可以包括基础设施域和场域。基础设施域是指端到端M2M部署的网络侧，而场域是指区域网络，通常在M2M网关后面。场域和基础设施域都可以包括网络的各种不同的网络装置(例如，服务器、网关、设备等)。例如，场域可以包括M2M网关14和设备18。将理解，根据需要，任何数量的M2M网关设备14和M2M设备18可以被包括在M2M/IoT/WoT通信系统10中。M2M网关设备14和M2M设备18中的每一个被配置为使用通信电路经由通信网络12或直接无线电链路来发送和接收信号。

M2M网关14允许无线M2M设备(例如，蜂窝和非蜂窝)以及固定网络M2M设备(例如，PLC)通过诸如通信网络12或直接无线电链路之类的运营商网络进行通信。例如，M2M设备18可以收集数据并且经由通信网络12或直接无线电链路将数据发送到M2M应用程序20或其它M2M设备18。M2M设备18还可以从M2M应用程序20或M2M设备18接收数据。此外，数据和信号可以经由M2M服务层22被发送到M2M应用程序20和从M2M应用程序20接收，如下文所描述的。M2M设备18和网关14可以经由各种网络进行通信，该网络包括例如，蜂窝、WLAN、WPAN(例如，Zigbee、6LoWPAN、蓝牙)、直接无线电链路和电话线。示例M2M设备包括但不限于平板电脑、智能电话、医疗设备、温度和天气监测器、联网汽车、智能仪表、游戏机、个人数字助理、健康和健身监测器、灯、恒温器、家电、车库门以及其它基于执行器的设备、安全设备和智能插座。

参考图29B，场域中所示的M2M服务层22为M2M应用程序20、M2M网关14、M2M设备18和通信网络12提供服务。将理解，根据需要,M2M服务层22可以与任何数量的M2M应用程序、M2M网关14、M2M设备18和通信网络12进行通信。M2M服务层22可以由网络的一个或多个网络装置来实现，该网络装置可以包括服务器、计算机、设备等。M2M服务层22提供适用于M2M设备18、M2M网关14和M2M应用程序20的服务能力。M2M服务层22的功能可以以多种方式实现，例如作为网络服务器、在蜂窝核心网络中、在云中等等。

类似于所示的M2M服务层22，在基础设施域中存在M2M服务层22'。M2M服务层22'为基础设施域中的M2M应用程序20'和基础通信网络12提供服务。M2M服务层22'还为场域中的M2M网关14和M2M设备18提供服务。将理解，M2M服务层22'可以与任何数量的M2M应用程序、M2M网关和M2M设备通信。M2M服务层22'可以通过不同的服务提供商与服务层交互。M2M服务层22'可以由网络的一个或多个网络装置实现，该网络装置可以包括服务器、计算机、设备、虚拟机(例如，云计算/存储场等)等等。

还参考图29B，M2M服务层22和22'提供一组核心的服务交付能力，各种各样的应用程序和垂直行业都可以利用这些服务交付能力。这些服务能力使M2M应用程序20和20'能够与设备交互并执行诸如数据收集、数据分析、设备管理、安全性、计费、服务/设备发现等功能。实质上，这些服务能力使应用程序免于实现这些功能的负担，从而简化了应用程序开发并降低了成本和上市时间。服务层22和22'还使M2M应用程序20和20'能够通过诸如网络12之类的与服务层22和22'提供的服务连接的各种网络进行通信。

M2M应用程序20和20'可以包括各种行业中的应用程序，例如但不限于，运输、健康和保健、联网家庭、能源管理、资产跟踪以及安全和监视。如上所述，跨设备、网关、服务器和系统的其它网络装置运行的M2M服务层支持以下功能，例如数据收集、设备管理、安全性、计费、位置跟踪/地理保护、设备/服务发现和旧有系统集成，并将这些功能作为服务提供给M2M应用程序20和20'。

通常，服务层(例如，图29B中所示的服务层22和22')定义软件中间件层，该软件中间件层通过一组应用程序编程接口(API)和底层网络接口来支持增值服务能力。ETSI M2M和oneM2M体系结构都定义了服务层。ETSI M2M的服务层被称为服务能力层(SCL)。可以在ETSI M2M架构的各种不同节点中实现SCL。例如，服务层的实例可以在M2M设备(在此被称为设备SCL(DSCL))、网关(在此被称为网关SCL(GSCL))和/或网络节点(在此被称为网络SCL(NSCL))内实现。oneM2M服务层支持一组通用服务功能(CSF)(即服务能力)。一组一个或多个特定类型的CSF的实例被称为公共服务实体(CSE)，其可以被托管在不同类型的网络节点(例如，基础设施节点、中间节点、专用节点)上。第三代合作伙伴计划(3GPP)还定义了一种用于机器类型通信(MTC)的架构。在该架构中，服务层及其提供的服务能力被实现为服务能力服务器(SCS)的一部分。无论是实现在ETSI M2M架构的DSCL、GSCL或NSCL中，还是实现在3GPP MTC架构的服务能力服务器(SCS)中，还是实现在oneM2M架构的CSF或CSE中，还是实现在网络的某个其它节点中，服务层的实例都可被实现为在网络中的一个或多个独立节点(包括服务器、计算机和其它计算设备或节点)上执行，或者作为一个或多个现有节点的一部分执行的逻辑实体(例如，软件、计算机可执行指令等)。作为示例，服务层或其组件的实例可以以软件的形式来实现，该软件在具有下文描述的图29C或图29D所示的一般架构的网络装置(例如，服务器、计算机、网关、设备等)上运行。

此外，本文描述的方法和功能可以被实现为使用面向服务的架构(SOA)和/或面向资源的架构(ROA)以访问服务的M2M网络的一部分。

从部署的角度来看，服务层可以部署在各种类型的网络节点上，包括本文中各个附图所示的服务器、网关和设备。实现服务层功能或以其它方式并入服务层的实例的通信网络的任何此类节点、服务器、网关、设备、装置或其它逻辑实体在本文中可被称为服务层实体。

图29C是诸如图1-22、24和26所示的实体之一之类的网络的装置的示例硬件/软件架构的框图，它们可以操作为诸如图29A和29B所示的M2M网络中的M2M服务器、网关、设备或其它网络装置。如图29D所示，网络装置30可以包括处理器32、不可移除存储器44、可移除存储器46、扬声器/麦克风38、小键盘40、显示器、触摸板和/或指示器42、电源48、全球定位系统(GPS)芯片组50和其它外围设备52。网络装置30还可以包括通信电路，例如收发器34和发送/接收元件36。将理解，网络装置30可以包括前述元件的任何子组合，同时保持与实施例一致。该网络装置可以是实现用于在服务层系统和分布式分类账系统之间进行互通的方法的装置，诸如关于图1-22、24和26示出和描述的方法操作。

处理器32可以是通用处理器、专用处理器、常规处理器、数字信号处理器(DSP)、多个微处理器、与DSP内核相关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何其它类型的集成电路(IC)、状态机等等。通常，处理器32可以执行存储在网络装置的存储器(例如，存储器44和/或存储器46)中的计算机可执行指令，以便执行网络装置的各种所需功能。例如，处理器32可以执行信号编码、数据处理、功率控制、输入/输出处理和/或使网络装置30能够在无线或有线环境中操作的任何其它功能。处理器32可以运行应用层程序(例如，浏览器)和/或无线电接入层(RAN)程序和/或其它通信程序。处理器32还可以例如在接入层和/或应用层执行诸如认证、安全密钥协议和/或加密操作之类的安全性操作。

如图29C所示，处理器32被耦合到其通信电路(例如，收发器34和发送/接收元件36)。通过执行计算机可执行指令，处理器32可以控制通信电路，以使得网络装置30经由其所连接的网络与其它网络装置进行通信。特别地，处理器32可以控制通信电路，以执行本文(例如，在图1-22、24和26中)和权利要求中描述的发送和接收步骤。尽管图29C将处理器32和收发器34描绘为分离的组件，但是将理解，处理器32和收发器34可以被集成在一起在电子封装或芯片中。

发送/接收元件36可以被配置为向其它网络装置发送信号，或从其它网络装置接收信号，其它网络装置包括M2M服务器、网关、设备。例如，在实施例中，发送/接收元件36可以是被配置为发送和/或接收RF信号的天线。发送/接收元件36可以支持各种网络和空中接口，例如WLAN、WPAN、蜂窝等。在实施例中，发送/接收元件36可以是被配置为发送和/或接收例如IR、UV或可见光信号的发射器/检测器。在又一实施例中，发送/接收元件36可以被配置为发送和接收RF和光信号两者。将理解，发送/接收元件36可以被配置为发送和/或接收无线或有线信号的任何组合。

另外，尽管发送/接收元件36在图29C中被示出为单个元件，但是网络装置30可以包括任意数量的发送/接收元件36。更具体地，网络装置30可以采用MIMO技术。因此，在实施例中，网络装置30可以包括两个或更多个发送/接收元件36(例如，多个天线)用于发送和接收无线信号。

收发器34可以被配置为调制将由发送/接收元件36发送的信号，并且对由发送/接收元件36接收的信号进行解调。如上所述，网络装置30可以具有多模式能力。因此，收发器34可以包括多个收发器，用于使网络装置30能够经由诸如UTRA和IEEE 802.11之类的多个RAT进行通信。

处理器32可以从诸如不可移除存储器44和/或可移除存储器46之类的任何类型的适当存储器访问信息并将数据存储在其中。例如，处理器32可以在其存储器中存储会话上下文，如上所述。不可移除存储器44可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘或任何其它类型的存储器存储设备。可移除存储器46可以包括用户识别模块(SIM)卡、存储棒、安全数字(SD)存储卡等。在其它实施例中，处理器32可以从不在物理上位于网络装置30上(例如，在服务器或家用计算机上)的存储器中访问信息并将数据存储在其中。处理器32可以被配置为控制显示器或指示器42上的照明图案、图像或颜色，以反映装置的状态或配置装置，尤其是与网络装置通信的底层网络、应用程序或其它服务。在一个实施例中，显示器/指示器42可以呈现图27和28之一所示并在此描述的图形用户界面。

处理器32可以从电源48接收电力，并且可以被配置为向网络装置30中的其它组件分配和/或控制电力。电源48可以是用于为网络装置30供电的任何适当的设备。例如，电源48可以包括一个或多个干电池(例如，镍镉(NiCd)、镍锌(NiZn)、镍金属氢化物(NiMH)、锂离子(Li-ion)等)、太阳能电池、燃料电池等等。

处理器32还可以被耦合到GPS芯片组50，该GPS芯片组被配置为提供关于网络装置30的当前位置的位置信息(例如，经度和纬度)。将理解，网络装置30可以在保持与实施例一致的情况下，通过任何适当的位置确定方法来获取位置信息。

处理器32还可以被耦合到其它外围设备52，其可以包括提供附加特征、功能和/或有线或无线连接的一个或多个软件和/或硬件模块。例如，外围设备52可以包括各种传感器，例如加速度计、生物识别(例如，指纹)传感器、电子罗盘、卫星收发器、传感器、数码相机(用于照片或视频)、通用串行总线(USB)端口或其它互连接口、振动设备、电视收发器、免提耳机、

模块、调频(FM)广播单元、数字音乐播放器、媒体播放器、视频游戏播放器模块、互联网浏览器等。

网络装置30可以实现在其它装置或设备中，例如传感器、消费电子产品、可穿戴设备(例如，智能手表或智能服装)、医疗或电子保健设备、机器人、工业设备、无人机、车辆(例如，汽车、卡车、火车或飞机)。网络装置30可以经由一个或多个互连接口(诸如可以包括外围设备52之一的互连接口)连接到此类装置或设备的其它组件、模块或系统。

图29C是示例计算系统90的框图，其还可以用于实现网络的一个或多个网络装置，例如图1-22、24和26所示并在此处描述的实体，其可以操作为M2M服务器、网关、设备或M2M网络中的其它网络装置，例如，图29A和29B所示的那些。

计算系统90可以包括计算机或服务器，并且可以主要由计算机可读指令控制，该指令可以是软件形式，无论在何地，或通过任何方式存储或访问此类软件。这样的计算机可读指令可以在诸如中央处理单元(CPU)91之类的处理器内执行，以使计算系统90进行工作。在许多已知的工作站、服务器和个人计算机中，中央处理单元91由被称为微处理器的单芯片CPU实现。在其它机器中，中央处理单元91可以包括多个处理器。协处理器81是与主CPU91不同的可选处理器，其执行附加功能或辅助CPU 91。CPU 91和/或协处理器81可以接收、生成和处理与所公开的系统和方法有关的数据。

在操作中，CPU 91经由计算机的主数据传输路径，系统总线80，来获取、解码和执行指令，并将信息向和从其它资源进行传输。这样的系统总线连接计算系统90中的组件并定义用于数据交换的介质。系统总线80通常包括用于发送数据的数据线、用于发送地址的地址线以及用于发送中断和用于操作系统总线的控制线。这样的系统总线80的示例是PCI(外围组件互连)总线。

耦合到系统总线80的存储器包括随机存取存储器(RAM)82和只读存储器(ROM)93。此类存储器包括允许信息被存储和检索的电路。ROM 93通常包含不容易修改的存储数据。RAM 82中存储的数据可由CPU 91或其它硬件设备读取或更改。可以由存储器控制器92控制对RAM 82和/或ROM 93的访问。存储器控制器92可以提供地址转换功能，该地址转换功能在执行指令时将虚拟地址转换为物理地址。存储器控制器92还可以提供存储器保护功能，其将系统内的进程隔离并且将系统进程与用户进程隔离。因此，以第一模式运行的程序只可以访问由其自己的进程虚拟地址空间映射的存储器；除非已建立进程之间的存储器共享，否则它无法访问另一个进程的虚拟地址空间内的存储器。

另外，计算系统90可以包含外围设备控制器83，其负责将指令从CPU 91传输到外围设备，例如打印机94、键盘84、鼠标95和磁盘驱动器85。

由显示控制器96控制的显示器86用于显示由计算系统90生成的视觉输出。这种视觉输出可以包括文本、图形、动画图形和视频。显示器86可以用基于CRT的视频显示器、基于LCD的平板显示器、基于气体等离子体的平板显示器或触摸面板来实现。显示控制器96包括生成视频信号所需的电子组件，该视频信号要被发送到显示器86。显示器86与由CPU 91执行的计算机可执行指令结合，可以生成和操作图29D中示出和描述的图形用户界面及其随附描述。

此外，计算系统90可以包含通信电路，例如网络适配器97，其可以用于将计算系统90连接到外部通信网络，例如图29A-29D的网络12，以使计算系统90能够与网络的其它装置通信。单独或与CPU91组合的通信电路可用于执行本文(例如，在图1-22、24和26中)和权利要求中所描述的发送和接收步骤。

应理解，本文描述的任何或所有系统、方法和过程可以以存储在计算机可读存储介质上的计算机可执行指令(即，程序代码)的形式实现，该指令在由诸如M2M网络的装置之类的机器(包括例如，M2M服务器、网关、设备等)执行时，执行和/或实现本文描述的系统、方法和过程。具体地，可以以这样的计算机可执行指令的形式实现上述的任何步骤、操作或功能。计算机可读存储介质包括以用于存储信息的任何非暂时性(即，有形或物理)方法或技术实现的易失性和非易失性、可移除和不可移除介质，但是这种计算机可读存储介质不包括信号。计算机可读存储介质包括但不限于RAM、ROM、EEPROM、闪存或其它存储技术、CD-ROM、数字多功能盘(DVD)或其它光盘存储、磁盒、磁带、磁盘存储或其它磁存储设备，或可用于存储所需信息并可由计算机访问的任何其它有形或物理介质。

以下是可能在以上描述中出现的与服务层技术有关的缩略词的列表。除非另有说明，否则本文中使用的缩写词是指下面列出的相应术语：

AE 应用程序实体

BC 区块链

CSE 公共服务实体

CSF 公共服务功能

DL 分布式分类帐

DLN 分布式分类帐节点

DLP 分布式分类帐代理

DLS 分布式分类帐系统

DNS 域名系统

DNS-SD 基于DNS的服务发现

ID 标识符

IoT 物联网

M2M 机器到机器

P2P 对等

PoW 工作量证明

SL 服务层

SLN 服务层节点

SLS 服务层系统

URI 统一资源标识符

UTXO 未使用的交易输出

以下是可能在以上描述中出现的与服务层技术有关的术语和定义的列表。除非另有说明，否则此处使用的术语和定义是指下面列出的相应术语：

该书面描述使用示例来公开本发明，包括最佳模式，并且还使本领域的任何技术人员能够实践本发明，包括制造和使用任何设备或系统以及执行任何结合的方法。本发明的可专利范围由权利要求限定，并且可以包括本领域技术人员想到的其它示例。如果这样的其它示例具有与权利要求的字面语言并无不同的要素，或者如果它们包括与权利要求的字面语言没有实质性差异的等同要素，则它们意图在权利要求的范围内。

Claims (20)

1.一种由分布式分类帐代理执行的用于使服务层系统和分布式分类帐系统互通的方法，所述方法包括：

从服务层实体接收消息，所述消息包括要存储在所述分布式分类帐系统中的数据；

在所述分布式分类账代理处并且基于所述数据，根据所述分布式分类账系统的一个或多个规范生成交易；

将与所述交易相关联的信息发送到所述分布式分类帐系统；

从所述分布式分类帐系统接收所述交易已被所述分布式分类帐系统确认的指示；以及

向所述服务层实体发送所述交易已被所述分布式分类帐系统确认的指示。

2.根据权利要求1所述的方法，还包括：生成从所述服务层实体接收到的数据与所述交易之间的映射。

3.根据权利要求1所述的方法，其中，所述交易已被所述分布式分类账系统确认的指示包括以下至少之一：所述交易的标识符、从所述服务层实体接收到的数据的标识符、或从所述服务层实体接收到的数据的哈希值。

4.根据权利要求1所述的方法，还包括：向所述服务层实体并且在接收到所述交易已被确认的指示之前发送响应，所述响应包括所述交易正在等待由所述分布式分类账系统确认的指示。

5.根据权利要求1所述的方法，还包括：从所述服务层实体接收包括其它数据的另一消息，其中，所述交易是基于所述数据和所述其它数据生成的。

6.根据权利要求1所述的方法，还包括：

从所述服务层实体接收从所述分布式分类帐系统检索一个或多个交易的请求；

从所述分布式分类帐系统检索与所述一个或多个交易相关联的信息；以及

向所述服务层实体发送与所述一个或多个交易相关联的信息。

7.根据权利要求1所述的方法，

其中，所述分布式分类帐系统包括多个分布式分类帐节点，以及

其中，所述消息包括将所述数据存储在所述分布式分类账节点中的特定节点处的指示。

8.一种装置，包括处理器和存储器，所述存储器存储计算机可执行指令，所述计算机可执行指令在由所述处理器执行时，实现用于使服务层系统和分布式分类帐系统互通的分布式分类帐代理，并使所述分布式分类帐代理执行以下操作：

从服务层实体接收消息，所述消息包括要存储在所述分布式分类帐系统中的数据；

在所述分布式分类账代理处并且基于所述数据，根据所述分布式分类账系统的一个或多个规范生成交易；

将与所述交易相关联的信息发送到所述分布式分类帐系统；

从所述分布式分类帐系统接收所述交易已被所述分布式分类帐系统确认的指示；以及

向所述服务层实体发送所述交易已被所述分布式分类帐系统确认的指示。

9.根据权利要求8所述的装置，其中，所述指令在被执行时还使所述分布式分类账代理执行以下操作：生成从所述服务层实体接收到的数据与所述交易之间的映射。

10.根据权利要求8所述的装置，其中，所述交易已被所述分布式分类账系统确认的指示包括以下至少之一：所述交易的标识符、从所述服务层实体接收到的数据的标识符、或从所述服务层实体接收到的数据的哈希值。

11.根据权利要求8所述的装置，其中，所述指令在被执行时还使所述分布式分类账代理执行以下操作：向所述服务层实体并且在接收到所述交易已被确认的指示之前发送响应，所述响应包括所述交易正在等待由所述分布式分类账系统确认的指示。

12.根据权利要求8所述的装置，其中，所述指令在被执行时还使所述分布式分类账代理执行以下操作：从所述服务层实体接收包括其它数据的另一消息，其中，所述交易是基于所述数据和所述其它数据生成的。

13.根据权利要求8所述的装置，其中，所述指令在被执行时还使所述分布式分类账代理执行以下操作：

从所述服务层实体接收从所述分布式分类帐系统检索一个或多个交易的请求；

从所述分布式分类帐系统检索与所述一个或多个交易相关联的信息；以及

向所述服务层实体发送与所述一个或多个交易相关联的信息。

14.根据权利要求8所述的装置，

其中，所述分布式分类帐系统包括多个分布式分类帐节点，以及

其中，所述消息包括将所述数据存储在所述分布式分类账节点中的特定节点处的指示。

15.一种计算机可读存储介质，存储计算机可执行指令，所述计算机可执行指令在由处理器执行时，实现用于使服务层系统和分布式分类账系统互通的分布式分类账代理，并且使所述分布式分类账代理执行以下操作：

从服务层实体接收消息，所述消息包括要存储在所述分布式分类帐系统中的数据；

在所述分布式分类账代理处并且基于所述数据，根据所述分布式分类账系统的一个或多个规范生成交易；

将与所述交易相关联的信息发送到所述分布式分类帐系统；

从所述分布式分类帐系统接收所述交易已被所述分布式分类帐系统确认的指示；以及

向所述服务层实体发送所述交易已被所述分布式分类帐系统确认的指示。

16.根据权利要求15所述的计算机可读存储介质，其中，所述指令在被执行时还使所述分布式分类账代理执行以下操作：生成从所述服务层实体接收到的数据与所述交易之间的映射。

17.根据权利要求15所述的计算机可读存储介质，其中，所述交易已被所述分布式分类账系统确认的指示包括以下至少之一：所述交易的标识符、从所述服务层实体接收到的数据的标识符、或从所述服务层实体接收到的数据的哈希值。

18.根据权利要求15所述的计算机可读存储介质，其中，所述指令在被执行时还使所述分布式分类账代理执行以下操作：向所述服务层实体并且在接收到所述交易已被确认的指示之前发送响应，所述响应包括所述交易正在等待由所述分布式分类账系统确认的指示。

19.根据权利要求15所述的计算机可读存储介质，其中，所述指令在被执行时还使所述分布式分类账代理执行以下操作：从所述服务层实体接收包括其它数据的另一消息，其中，所述交易是基于所述数据和所述其它数据生成的。

20.根据权利要求15所述的计算机可读存储介质，

其中，所述分布式分类帐系统包括多个分布式分类帐节点，以及

其中，所述消息包括将所述数据存储在所述分布式分类账节点中的特定节点处的指示。

Images