通信网络节点、方法和移动终端

技术领域

本公开总体上涉及一种通信网络节点、用于操作智能合约的方法、用于控制通信网络的方法以及移动终端。

背景技术

通常，已知在多个节点上分布分类账，该多个节点为诸如记录数字交易的实体，例如电子设备、服务器等。分布式分类账可以基于已知的区块链技术，例如，已知的加密货币比特币所基于的技术，还有众所周知的以太坊项目(Ethereum project)等。通常，分布式分类账也可以在除区块链之外的其他技术上实现，并且不基于区块链的分布式分类账项目的示例是BigchainDB和IOTA等。例如，IOTA是使用链表的加密货币。

此外，已知移动即服务(MaaS)，其中用户或旅客使用移动即服务而不拥有例如汽车等。移动即服务可以将来自关联运营商或提供商的公共(例如火车、公共汽车等)和私人(例如汽车共享、自行车共享等)运输服务结合起来。

已知的MaaS解决方案通常涉及中央和统一的网关，通过该网关可以规划和预订行程或旅程，用户可以在其中使用单个账户付款。

尽管存在用于提供分布式分类账和移动即服务以及相关联的通信的技术，但是通常期望提供通信网络节点、用于操作智能合约的方法以及用于控制通信网络以提供分布式分类账的方法。

发明内容

根据第一方面，本公开提供一种用于向分布式分类账提供数据的通信网络节点，其中，该节点包括被配置为执行以下至少一项的电路：提供用作智能合约的输入的输入数据的验证，提供在预定设备上是否正确接收了基于从智能合约输出的输出数据的验证。

根据第二方面，本公开提供一种用于操作智能合约的方法，其中，智能合约具有至少两个不同的状态，该方法包括响应于接收到触发来改变智能合约的状态。

根据第三方面，本公开提供一种用于控制包括用于提供分布式分类账的多个节点的通信网络的方法，该方法包括以下步骤中的至少一项：提供用作智能合约的输入的输入数据的验证；提供在预定设备上是否正确接收到基于从智能合约的输出的输出数据的验证。

根据第四方面，本公开提供一种用于与网络节点进行通信以向分布式分类账提供数据的移动终端，其中，该移动终端包括被配置为提供用作智能合约的输入的输入数据的电路。

在从属权利要求、以下描述和附图中阐述了其他方面。

附图说明

参照附图通过示例的方式说明实施例，其中：

图1示意性地示出了区块链。

图2示意性地示出了区块链中的哈希(hashing)。

图3是示出共识协议的实施例的流程图。

图4示出了MaaS系统中的数据流。

图5示出了包括旅程日志数据的区块链的实施例；

图6示出了用于提供区块链的通信网络的实施例；

图7示出了实现区块链oracle的MaaS系统的实施例的数据流；

图8是表示智能合约的状态的转移的转移图。

图9示出了利用区块链oracle来实现智能合约触发的方法的实施例的流程图；

图10示出了基于位置的登记方法的实施例的流程图；

图11示出了基于生物特征的登记方法的实施例的流程图；

图12示出了绑定过程的方法的实施例的流程图；

图13示出了验证过程的方法的流程图；

图14示出了在一些实施例中基于其实现网络设备或通信设备的通用计算机的实施例；以及

图15示出了eNodeB和用户设备彼此通信的实施例。

具体实施方式

在给出参考图1的实施例的详细描述之前，进行一般的解释。

如开头所述，通常已知分布式分类账和移动即服务(MaaS)。

在一些实施例或方面中，本公开总体上涉及用于移动即服务(MaaS)应用的区块链/分布式分类账的应用，特别是不止一个服务提供商之间的MaaS(多模式传输)。

在一些实施例或方面中，本公开总体上还涉及分布式分类账或区块链的应用，作为分布式分类账的一个示例，而不将本公开内容限于区块链。根据本公开的一些方面，分布式分类账或区块链被认为适合于移动即服务(MaaS)应用，因为分布式分类账需要用于多个玩家之间的旅程历史(或旅程数据)的分布式数据库，即多个移动即服务提供商。

分布式分类账的技术及其特殊示例(即区块链)的技术也将在下面进一步讨论。更一般地，术语分布式分类账被用作与网络的多个节点共享数字记录的数据的一种数据库。它可能包含对等网络。数字记录的数据可以包括一种根据先前在同一数据库中记录的数据证明其一致性的信息。

分布式分类账可以是公共的，且任何人都可以访问，但是，原则上，它们也可以是非公共的，且只有获得许可的用户才可以访问它们，其中具有许可的一组实体，节点，人员，操作员，提供者等也可以称为“联盟”，这也将在下面进一步解释。也可以区分每个分层用户对分类账上数据的访问权限。

分布式分类账可以使用例如从用于比特币的区块链技术中已知的机制。这些机制包括发现方法，共识机制，保持数据一致性的机制等等。共识机制可确保具有分布式分类账副本的所有节点或多于一定数量的节点(通常是电子设备)具有分布式分类账的副本，可以就分布式分类账的内容达成共识。有许多共识机制，包括所谓的工作量证明机制(proof-of-work mechanism)，这是一种加密难题(crypto-puzzle，加密魔方)，且其可确保例如不能(不容易)更改区块链的旧区块。例如，工作量证明用于比特币区块链的挖掘过程。

在分布式分类账或区块链中，对参与节点上的区块链上的数据更新达成共识的确认过程(称为挖掘过程)可以通过将先前记录的数据包括在确认数据中来实现记录在区块链上的交易序列的不可逆性。这种挖掘过程为新的交易区块实现了分布式时间戳服务器。在比特币中(因此，在某些实施例中)，挖掘过程基于SHA-256哈希函数。参与挖掘过程的区块链节点搜索具有预定义属性的哈希输出，而哈希函数的输入取决于区块链的当前区块和要添加到区块链的新的交易区块。

基于哈希函数的工作量证明计算本身可能没有用，只是需要它们来实现分布式分类账的不可逆性。

而且，通常，已知使用区块链来存储各种数据。例如，图像、视频、测量和文本文件可以交易形式记录在区块链上。

在一些实施例中，MaaS区块链可能需要处理大量旅客，存储各种旅程记录，大尺寸的区块，高峰时段的处理高峰等。

在一些实施例中，通常分布式分类账或区块链适合于MaaS应用，因为它为多个玩家之间的旅程历史提供了分布式数据库，而在这方面不限制本公开。

此外，在一些实施例中，例如针对MaaS使用智能合约。例如，基于旅客与服务提供商/运营商之间的协议提供票务或MaaS服务。因此，在一些实施例中，可以用智能合约来解决正常情况(例如，买票)或正常情况以外的例外情况/程序(例如，仅买票)。除了正常程序外，智能合约还可以处理这些特殊程序。

在一些实施例中，智能合约是区块链中基于计算机语言的合约。如果满足预定义的条件，例如来自一个或多个传感器的预定义输入，来自人的用户界面输入，来自其他服务器的应用程序接口(API)调用等，则可以自动执行智能合约，这也将在下面更详细地讨论。

在一些实施例中，智能合约的关键成功因素可以是保证从/向真实世界的真实投入(并也输出)，在一些实施例中，在外部输入(例如传感器)和智能合约之间提供了区块链oracle(例如服务器)，并且它对此负责。

已经认识到如何在MaaS应用程序(或其他应用程序)中使用智能合约的问题可能是一个问题，并且在某些情况下，对于智能合约而言，获取可靠的执行输入可能很重要。

作为第一示例，在一些实施例中，智能合约不仅仅与区块链一起运行，而是可能需要与特定应用相关的系统，例如输入和输出系统。例如，在一些实施例中，MaaS应用程序需要检测旅客的登记手续，并因此，一些实施例解决了这个问题并寻址了系统架构，节点/服务器等。

作为第二个示例，智能合约可能依赖于来自传感器的真实输入/输出或任何输入和输出。在加密货币的情况下，只能传输一个数字，而例如，MaaS应用程序需要与实际的物理世界进行交互，例如乘火车，解锁自行车，在正确的位置呼叫共享乘车并骑车等等。在一些实施例中，在下文中可以提供称为“区块链oracle”的节点，以确保对智能合约的正确输入/输出。

另外，一些实施例涉及用于MaaS应用程序的具体过程。

在下文中，给出了本公开中讨论的实施例的简要概述：

系统架构

MaaS系统的数据流(先前发明的回顾)

智能合约的其他功能/节点

智能合约的示例

伪代码示例

智能合约执行的触发

常规ID解决方案

基于位置的(地理围栏)解决方案

基于生物识别的解决方案

其他区块链oracle功能

数据完整性检查

传感器/终端的认证/凭证检查

在硬件/智能手机/可穿戴设备中使用唯一ID

绑定程序

验证程序

在下文中，将参考图1来说明区块链及其一般数据结构。在区块链的该实施例中，特征是网络/拓扑，共识算法，哈希函数，参与者认证，可伸缩性/区块结构和性能。

图1示出了区块链1的一般结构。区块链1包括由多个数据区块2a，2b和2c组成的链，其中，区块2b是当前区块(区块N)，区块2a是先前的区块(区块N1)，区块2c是未来的区块或后继区块(区块N+1)。每个区块包括前一个区块的哈希函数结果，主数据结构，哈希函数的输入值和当前区块的哈希函数结果，其中，当前区块(2b)的哈希函数结果始终用作对下一区块(2c)的输入。

此外，每个区块都包含一个“使用一次的号码”，这是用于安全区块链处理的一次性随机数，可以防止重放攻击。例如，如果攻击者复制了先前发送的数据并再次将复制的数据重新用于欺骗，则接收器能够检测到欺骗通信，因为下一个数据必须使用不同的“一次使用的编号”。该随机数有时在加密货币中称为“随机数(nonce)”。

另外，可以将时间戳插入每个区块2a，2b和2c中。区块链1是分布式分类账的示例，在某些实施例中，其可用于例如提供MaaS。

图2举例说明了哈希函数的输入和输出，其例如用于图1的区块链1。

通常，哈希函数是可以用于使用特定算法将输入数据映射到输出数据的任何函数。输入数据的大小可能很大且各不相同，相反，数据的输出可能会很紧凑并且具有固定的大小。在某些区块链实施例中，用于哈希的已知(和著名的)算法是由美国国家安全局(例如SHA-2，SHA-256)设计的安全哈希算法(SHA)。

哈希函数的输入是先前的哈希输出，一次使用的数字以及当前区块(例如，图1中的区块2b)中的数据主体。哈希函数的输出是对输入值的唯一值响应。如果有人试图篡改数据主体，则哈希函数的输出将不一致。

本公开中的分布式分类账(区块链)的实施例可以实现共识协议或算法。例如，在一些实施例中，拜占庭式容错(Byzantine Fault Tolerance，BFT)用于共识协议，该协议对于数据库的欺骗和硬件的故障具有弹性。

在一些实施例中实现的众所周知的共识算法是所谓的实用拜占庭式容错(Practical Byzantine Fault Tolerance，PBFT)。

在一些实施例中，使用许可区块链，并且相对较少数量的许可区块链节点负责共识(区块验证)。

图3示例性地示出了PBFT的过程10。

在11，领导者节点(也称为非验证对等方)请求其他节点上验证区块链。在12，每个被请求的节点(验证对等方)使用哈希函数检查区块链的有效性，并在13向其他节点指示其结果。在14，节点从其他多个对等节点接收有效性结果，并检查其区块链的共识性(如果节点收到的有效性结果比预定义标准还多)。如果达成共识，则在15点，节点写入/完成区块链。领导者对等方检查其他节点中有效性检查的总体进度，并在16处完成区块链过程。

对于弹性，在一些实施例中，节点的总数大于3f+1，其中f是允许的故障节点的数量。例如，f＝1，总共有4个节点；如果f＝3，则总共有10个节点，依此类推。

在一些实施例中，如本文所讨论的，PBFT具有用于移动服务区块链的许可区块链，至少部分地提供以下特征：

关于安全性，在某些实施例中，PBFT提供了51％攻击的少许风险，这对于加密货币是很常见的，因为负责共识的同级必须获得允许的信任。关于隐私，终端用户无法访问整个区块链，因为仅移动服务提供商在(对等)节点上处理它(由于基于权限的区块链，终端用户可能没有访问区块链的许可)。关于性能，在一些实施例中，由于少数具有高性能的对等体，用于共识的处理时间非常短。关于灵活性，在一些实施例中，与公共区块链相比，区块链的区块大小和格式可以是灵活的。

在下文中，参考图4说明MaaS系统20的数据流，其示出了整个数据流。在MaaS系统20中，示例性地假设终端用户具有自己的终端21，例如智能电话(或任何其他类型的电子(移动)设备)。一些用户(例如来自国外的访客)可能没有智能手机等，并且在这种情况下，例如，可以提供一种替代解决方案，该解决方案基于图4中的代理功能(代理22)，该代理功能向用户提供门。

图4示出了MaaS系统20的数据流程图，其中提供了三个主要部分，在左侧提供了终端用户部分，在中间提供了移动服务运营商/提供商部分，并且在右侧提供了其他实体部分，其中，终端用户部分和其他实体部分与中间的移动服务提供部分通信。

对于MaaS系统20的该实施例，假设移动服务提供商具有用户管理功能23(利用用于客户服务的网络服务器或云和用户简档管理功能23a以及旅客旅程管理功能23b)。它还具有区块链管理功能24。具有区块链管理功能24a的区块链功能24与其他实体部分的区块链管理功能25通信。如果预订中心26提供座位预订/共享乘车预订，则设置中央预订服务器/云。

终端用户与其自己的终端(即，在该实施例中为智能电话21)进行通信，该终端具有示例性的用户界面和传感器，例如GNSS，NFC等。

从图4也可以看出，终端用户可以例如通过终端或通过代理22执行以下动作：服务订购/购买一日/一周票证；预订火车，预订汽车/乘车份额；运输上船/下车许可/记录；下车后进行后处理(例如客户调查，退款或延误赔偿)等。

用户简档管理功能23a被配置为存储静态数据，例如姓名，年龄，联系地址，付款方式(例如信用卡)，服务订购状态，运输偏好，任何其他唯一ID(如IMEI(国际移动站设备标识))等，并与终端21通信。

旅客旅程管理功能23b被配置为执行若干动作并与终端21通信。例如，对于多模式联运通行证，例如，它管理MaaS每月服务的订购以及一日票证，一周票证等的购买。关于旅程计划(或旅程计划者)，它提供目的地输入，路线选择/运输选项，预订/旅行安排并发行票证和发行票证ID，为旅客生成行程并发行行程ID等。在旅客/用户的旅途中，旅客旅程管理功能配置为开始旅程，并针对旅程的每个部分(迭代)检查通行证/票证持有量并记录路堤(embankment)，记录下车并将旅程日志添加到区块链，并在旅程结束时终止旅程并结束行程。

区块链管理功能24a与旅客旅程管理功能23b和其他区块管理25通信。它被配置为添加，验证/执行共识协议并读取区块链。此外，从图4也可以看出，至少在旅客旅程管理功能23b和区块链管理功能24a之间以及在区块链管理功能24a与另一个区块链管理25之间传递通行证，票证和旅程日志信息。

在下文中，参考图5来说明包括旅客旅程历史的区块链30的实施例。

如同参考图1通常说明的那样，区块链30具有几个区块30a，30b，30c，其中，在图5中，示例性地示出过去的区块30a(区块#N-1)，当前区块30b(区块#N)和后续或下一/将来区块30c(区块#N+1)。

区块30a，30b和30c中的每一个可在最大给定区块大小内和相关数据结构内包括交易中的一个或多个旅客日志。在图5中，左侧的区块30a(区块#N-1)处理两个旅客日志31a和31b。从N-1区块30a输出的哈希被提供给下一个N区块30b(当前区块)。区块30b(区块N)处理旅客A和B的下一个旅程日志32a和32b，以及旅客C旅程的旅程日志32c。例如，如果旅客D发布了新的旅程日志，但是如果同时超过了区块大小限制，则将在下一个区区块(即，在本示例中的方框30c)中处理进一步的旅程日志，其中包括旅客B的进一步的旅程日志33a条目，旅客C的进一步的旅程日志条目33b和旅客D的进一步的旅程日志33c条目，这样，区块30c(区块N+1)处理旅客C和D的下一次旅程以及旅客D的剩余日志。然后，将哈希输出(N+1)提供给下一个区块(N+2)(图5中未示出)。

通常，区块链30中的旅程日志可以包括以下信息中的至少一个：

-发行者：多模式联运通行证发行者，移动服务提供商/运输运营商，旅客ID(匿名数据)。

-票证信息：票证类型，运输类型(铁路，乘车共享等)，座位预订(火车/座位号)，价格或票证，条款和条件。

-登船记录：登船位置，时间/日期，下车的位置，时间/日期，未使用/已使用。

-备注：特别说明(例如，取消，延迟)。

在一些实施例中，假定用于MaaS的区块链使用许可的区块链。在许可的区块链中，只有获得许可的运营商(组成一个联盟)才能添加/读取区块，并且允许有限的参与者加入交易验证(即与受信任的参与者达成共识)。因此，在某些实施例中，例如，将移动服务提供商组织为联盟，并且仅允许具有相应权限的运营商访问按权限分配的分布式分类账或区块链，而恶意参与者或不诚实参与者不能加入区块链联盟。

在下文中，参考图6说明用于为MaaS提供(许可的)区块链的通信网络40的实施例。

在弹性方面，通信网络40减轻了单点故障(SPOF)的风险，例如，对于严重依赖可能是系统中的SPOF的中央服务器的传统系统，单点故障通常是系统的薄弱点。

从图6可以看出，通信网络40具有多个节点(或实体)41(大圆圈)，它们与不同的运营商或移动服务提供商相关联(例如MaaS服务提供商、铁路运营商、汽车共享/乘车共享运营商、自行车共享运营商和公共汽车运营商)。

此外，有多个旅客42(小圆圈)，它们可以与移动服务提供商的节点41通信。移动服务提供商节点41可以一起形成通信网络40，这为MaaS提供许可的区块链(例如，图5的区块链30)。

旅客42通过利用其终端(如图4的终端21)和相关的移动服务提供商进行通信来例如订购由移动服务提供商提供的每月MaaS服务，或者购买多模式联运服务的一天/一周通行证。

如上所述，移动服务提供商41可以是新的服务提供商，例如MaaS运营商(例如，共享乘车)，自行车共享服务提供商，旅行社，以及诸如运输铁路公司，电车运营商等常规运输运营商。

移动服务提供商41通过通信网络彼此连接，这是一种逻辑连接，其中，运营商或移动服务提供商之间的直接连接不是必需的，但是可能需要低等待时间和高吞吐量。

移动服务提供商的实体或节点41可以具有各种功能，但是有两个主要功能，如上面针对图4所讨论的，即旅客管理功能和区块链管理功能。旅客管理功能支持座位预订，共享乘车/出租车/汽车租赁/火车座位预订，每月订购或购买一日票证等。像普通的电子商务网站一样，它提供网站或智能手机后端处理的用户界面。

另一方面，在本实施例中，对于终端用户而言，区块链是隐藏的，但是可以由多个移动服务提供商来访问。另外，在本实施例中，在节点41之间实施联盟(许可)区块链，其验证作为联盟成员的移动服务提供商之间的区块链分类账。

在一些实施例中，以上示例被扩展到不同区域中的国际MaaS运营或MaaS运营。然后将区块链定义为多层结构。第一层区块链配置在国家之间或区域之间，且第二层区块链配置在区域的联盟中。例如，区域联盟中的代表性提供商可以加入第一层区块链并处理国际服务。

在下文中，参考示出了MaaS系统50的框图的图7来说明图4的MaaS系统20的替代实施例。

与图4的实施例相反，在MaaS系统50的本实施例中，提供了区块链oracle 51，其包括验证区块/功能51a，完整性区块/功能51b和证书区块/功能51c。

此外，在区块链管理52中，除了与其他区块链管理53进行通信的区块链管理区块/功能52a之外，还提供了智能合约和虚拟机区块/功能52b。

此外，提供了可以与区块链oracle 51(例如，证书功能51c)通信的外部传感器54，例如照相机(用于面部识别)或其他传感器(例如用于指纹检测)。

拥有具有传感器(例如，NFC，GNSS；或其他传感器)的智能手机55的终端用户也可以与区块链oracle 51(例如，与验证功能51a)通信。

区块链管理功能52可以处理智能合约，而新功能“区块链oracle”51可以处理智能合约的输入数据(例如，来自传感器54和/或来自智能手机55的传感器的输入)。

智能合约是一种软件代码，且除数据外(例如，除了行程数据外)，它还可部署在区块链中。但是，由于智能合约是一种软件，因此它们通常需要中央处理器(CPU)才能执行。因此，提供了虚拟机，该虚拟机可以被配置为智能合约的平台并且可以提供相应的计算资源。

在该实施例中，区块链oracle 51负责对智能合约的正确输入，并且是传感器54与智能合约之间的一种代理服务器。当智能合约从传感器54访问数据时，目标传感器可以基于Restful API使用统一资源标识符(URI)或统一资源位置(URL)进行指示：例如：“https：//proxy.blockchainoracle.com/inputdevices/sensorl”。

在此示例中，URL“ptoxy.blockchainoracle.com/”是区块链oracle服务器名称，而“inputdevices/sensorl”部分是在区块链oracle 51下的目标传感器的标识符。

可以使用可扩展标记语言(XML)或Javascript对象符号(JSON)格式等返回这些值。

但是，区块链oracle 51不仅是传感器54与该智能合约之间的代理服务器，而且还负责智能合约的输入和输出的验证。

例如，区块链oracle可以验证来自传感器54的位置/时间戳。此外，它可以检查数据完整性(未更改)，并且可以证明所连接的传感器是否正确。

如前所述，智能合约是一种软件代码，并因此物理部署是灵活的。例如，虚拟机还可以在不同(或任何)位置的受信任云计算机中单独运行。

通常，存在以各种方式部署各种传感器的许多可能性/组合，并且本公开在这方面不限于特定示例。

在一些实施例中，验证的类型或是否执行了任何验证和/或验证过程中是否涉及区块链oracle，取决于输入到智能合约和/或从智能合约接收的数据可能被篡改的风险。例如，如果MaaS操作员拥有传感器的安装状态/部署环境的数据库或对其具有(专有)控制权，并且几乎不可能对其进行修改/篡改(例如，安全摄像机安装在人们无法到达的高塔上)，可以应用简化的(验证)过程。例如，可以跳过验证过程的一部分(例如，代替执行单项检查而不是重复检查)，或者跳过由区块链oracle执行的验证(以便在某些情况下不涉及/不需要区块链oracle)。换句话说，取决于传感器的信任程度，在一些实施例中可以应用合理的验证水平。

在一些实施例中，一种简单的方法/通用方法是在旅客的智能电话/可穿戴设备中使用传感器。替代地(或附加地)，例如在火车站，机场，公共汽车站，自行车共享站，街道等中部署运输设施中的一个或多个外部传感器(例如摄像机)。例如，机场或火车站可以具有多个安全摄像机，在某些实施例中，其被用于或用作MaaS传感器。

在该实施例中，MaaS运营商/运输运营商部署区块链oracle 51。然而，在其他实施例中，第三方可以代替地提供区块链oracle 51的服务。

例如，在一些实施例中，具有物联网(IoT)功能、位置服务器、安全功能、应用程序和服务的电信运营商/移动网络运营商也可以提供区块链oracle功能。

在下文中，讨论智能合约的实施例：

除了区块中的数据外，智能合约还作为代码存储在区块链中。

智能合约的描述或内容是一种软件代码(例如JavaScript，Solidity)，而不是人类描述的自然语言合同。因此，在一些实施例中，存在IF-THEN-ELSE结构和条件。

通常，在一些实施例中，智能合约(计算机语言)可以支持以下至少一项：

·循环结构(if图灵全语言)

·复杂的条件，例如多个变量，三元运算符

·保留内部变量的值(if状态的智能合约)

·读取/写入/更新区块链中的区块

·外部机器/计算机/网络的输入/输出

·机器之间的直接协商，无需人工干预

下面示出了智能合约的示例。但是，存在许多用于智能合约的计算机语言，并且以下智能合约示例以简化的伪代码而非实际的计算机语言提供：

Begin

Variable：TicketState(打开，使用中，关闭)

If票已发行且未使用，Then

将TicketState变为打开

End(if)

Repeat(main loop)

接收来自外部的触发

If然后登记触发，Then

将TicketState变为使用中

End(if)

If签出触发，Then

将TicketState变为关闭

签出循环

End(if)

End(repeat)

将TicketState传输到外部

End(begin)

该伪代码检查是否已使用票证，如果尚未使用票证，则其状态将设置为“打开”。此外，检查是否接收到触发，其中该触发例如是“登记”事件或“签出”事件。如果检测到“登记”事件作为触发，则票证的状态设置为“使用中”，如果检测到“签出”事件作为触发，则票证的状态设置为“关闭”。最后，票证状态被传输到例如区块链oracle 51或另一个实例。

通常，如果支持智能合约的计算机语言，则可以在任何计算机系统中实施。在一些实施例中，重要的是确保智能合约是真实的，并且不可能对其进行修改或改变。如所讨论的，在区块链中，由于哈希函数输出(在这种情况下会发生变化)，可以检测到变化/修改。

在下文中，参考图8讨论与有状态智能合约中的状态转换有关的实施例。

如果智能合约是有状态的，则取决于当前状态，它可能具有不同的行为。在一些实施例中，这是有用的，以便涵盖(复杂的)旅行政策/运输费用。

例如，票在使用前可以退票，但另一方面，票在使用后不允许退票。

图8示出了相关联的智能合约的三种不同内部状态。

最初，当发行票证时，状态为“打开”，即该票证有效，但尚未使用。

当旅客满足“登记”触发条件时，状态转换为“使用中”，且然后票证不再退还。

当旅客满足“签出”的触发条件(例如到达目的地)时，状态为“关闭”。智能合约可以检查适当关闭的条件。例如，如果火车延迟了三个小时并且为了满足火车延迟补偿条件，则智能合约可以自动执行补偿过程。

状态/转换条件的数量可以根据实际的MaaS用例增加/减少，并因此可以相应地进行调整。例如，在航空旅行的一些实施例中，可以单独处理值机(柜台)和登机(登机门)的状态。

在一些实施例中，由区块链oracle执行的验证包括验证在预定设备上是否正确接收了基于来自智能合约的输出的输出数据。例如，如所讨论的，在图8中，智能合约生成有关票证状态的输出，该输出可以传输到区块链oracle，然后核实该票证状态是否正确，并与正确的票证和用户相关联。例如，假设在要支付补偿的情况下，区块链oracle可以验证该补偿是合理的，并且该信息已发送到正确的预定设备。同样，例如，如果票证状态为打开，则此信息应传输到例如正确的登记设备(或MaaS运营商的数据库)以及正确的用户/旅客的正确的移动终端。此外，区块链oracle可以验证输出数据是基于正确的智能合约，以避免例如被篡改的智能合约输出数据用于改变票证状态，获得补偿等。

在下文中，讨论与智能合约执行的触发有关的实施例：

智能合约成功的一个因素在一些实施例中是如何在获得智能合约的准确条件之外获得可靠的触发。

如上所述，智能合约的执行依赖于受信任/准确的输入，称为“(区块链)Oracle”。

图9示出了利用区块链oracle 61实现智能合约触发的方法60的实施例的流程图。假设旅客62利用MaaS服务旅行。旅客62将要办理登记手续。在该实施例中，他或她拥有火车的未使用票证。

在登记手续区域中，设置有能够检测旅客的传感器63(例如，照相机、用于扫描票等的扫描仪、近场通信、用于面部识别的传感器、传感器指纹识别等)。此外，提供了区块链管理，其管理区块链64，如上所述，包括例如旅程数据等。用于智能合约的虚拟机65托管并执行智能合约。

登记的方法或过程如下：

在66处，传感器63(或传感器组63的一个或多个传感器)识别旅客到达特定区域/地点(例如，车站入口，门口，站台等)，并向区块链oracle61通知旅客到达。可选地，在67处，旅客的智能手机，可穿戴设备等中的传感器中的一个或多个传感器检测特定区域，并将指示旅客62的登记或当前位置的触发发送至区块链oracle 61或直接发送到区块链管理服务器64。

区块链oracle服务器61从传感器接收输入(参见66和/或67)，并检查它们的有效性，例如位置，提供发送到区块链oracle服务器61的传感器数据的传感器数据完整性，所连接传感器的认证等。

在68处，区块链管理功能64接收指示登记的触发，该触发启动智能合约的相关过程的执行。

如在图8的参考中已经讨论的，在69处，区块链管理将触发发送到虚拟机65，虚拟机65根据触发/输入/条件的改变执行关联的智能合约的相关代码，然后在70处改变内部状态(例如，票证打开->登记完成)，并且在71处将相应的消息发送到区块链管理服务器。

在72处，区块链管理功能根据智能合约执行的结果将状态改变写入区块中(如果需要的话)。例如，如果多运营商票证无效，则应将其记录在区块链中。

在73处，区块链管理功能将票证状态告知旅客(可选地)。

例如，旅客可以从智能手机屏幕或可穿戴设备获取票证状态更改，在该屏幕上显示相应的消息(或显示指示票证状态更改的任何其他标记)。

在一些实施例中，区块链oracle 61的一项重要职责是保证对智能合约的正确输入，因为如果输入信息错误/不正确，即使正确描述了智能合约，也会执行错误的程序。不管人为错误，机器故障/错误，恶意攻击(例如欺骗)等如何，目标是区块链oracle 61必须防止由于错误的输入/条件而导致智能合约的错误执行。

在一些实施例中，例如，如果传感器和/或服务器由受信任成员部署并且不可能更改或由其他人修改数据，则可以省略oracle 61。

在下文中，讨论检测旅客到达的实施例(位置/区域检测)：

对于登记检测，存在相应方法的实施例。

例如，在一些实施例中，使用QR码/NFC等来检测旅客的到达(例如，通过扫描票证上的QR码，使用旅客的智能手机的NFC等)。

尽管这样的技术本身是已知的，但是在一些实施例中，需要验证智能合约。

在一些实施例中，提供了一种基于位置的解决方案，其可能涉及精确的定位技术，这对于MaaS服务是有用的，因为由此可以准确地确定旅客的位置。在其他实施例中，实现了基于生物特征的解决方案，这对于MaaS应用程序也是有用的(在某些实施例中，基于位置和生物特征的解决方案也被组合在一起)。

在下文中，讨论一种基于常规ID(标识)的实施例，用于检测旅客的到达(或登记)。

常规ID/旅客到达检测的示例如下：

1.在值机机器处检测旅客姓名及其密码

2.在值机机器上显示护照(例如，用于扫描旅客的个人数据)

3.在登记口或登记门处检测NFC传感器(例如智能手机)的接触

4.在门口或阅读器上显示带有条形码/QR码的电子客票

5.在登记地点通过智能手机/PC的用户界面输入。

在一些实施例中，通过使用该方法，在登记过程中涉及许多基于手动/人工的检查。如果有人在智能手机屏幕上制作并使用了伪造的票证，并在门口示出，那么人将无法轻松地对其进行验证并无法识别出该票证是伪造的票证。

在下文中，讨论了实施例，其中实施了基于位置的(地理围栏)解决方案。

例如，在旅客拥有(高端)智能手机或高级可穿戴设备的情况下，其中提供了各种传感器。在这种情况下，基于位置的检测适用于一个传感器(例如GPS传感器)或两个或多个传感器的组合。

例如，上一代GNSS(全球导航卫星系统，例如GPS卫星)的精度可以为30m-50m。当前的卫星系统(例如伽利略加密，QZSS，准真力卫星系统)或多颗卫星的组合可以达到分米级(例如50厘米)的精度，甚至达到厘米级的精度，其中该精度级别为在一些实施例中对MaaS有用。另外，在一些实施例中，实现了室内定位方法的组合，这对于MaaS是有用的，其中，定位系统可以具有非常准确的时钟/时间戳，这对于MaaS也是有用的。

在实施例中，实现以下用于基于位置的解决方案的传感器/定位方法中的至少一种，其中每个都可以以任何方式相互组合：GNSS定位(例如GPS)；高精度卫星定位系统(基于伽利略加密，QZSS，RTK(实时运动)的定位等)；基于Wifi(无线网络)的定位；基于蜂窝的定位(例如，OTDOA(到达的观测时间差)，UTDOA(到达的上行链路时间差)，基站波束成形等；基于惯性测量单元(IMU)的定位(例如，陀螺仪传感器，加速度传感器，电子罗盘等)；信标信号(例如低功耗蓝牙(BLE))；借助智能手机摄像头/图像处理和/或基于NFC的位置检测来识别定位器(例如，在特定位置打印的QR码)。

旅客(即旅客的智能手机/可穿戴设备等)检测到特定区域(用于登记)，并将位置或触发发送到区块链oracle或直接发送到区块链管理服务器。在某些实施例中，该方法的挑战在于如何防止GNSS欺骗或定位不正确。因此，在一些实施例中，区块链oracle可以用不同的方法仔细检查旅客的位置，这将在下面进行讨论。

在下文中，讨论实现位置/方位/时间戳验证的实施例。

区块链oracle可以双重检查传感器位置/方位的有效性。除了位置之外，还可以验证时间戳/时钟，因为位置服务通常使用准确的时钟源。结果，通过考虑一个以上传感器的其他位置信号，区块链oracle可以提高位置的准确性。

例如，可以将两种类型的定位系统进行组合(或者甚至两种以上)。例如，使用GPS(美国)，GLONASS(俄罗斯)，BeiDou(中国)，Galileo(欧洲)和QZSS(日本)等多个卫星进行双重检查，例如GNSS。室内定位的一个示例是，区块链oracle可以使用蓝牙信标，WiFi信号定位，蜂窝信号等。通常，篡改一个系统可能很容易，但是认为很难同时篡改多个系统时间。而且，如果在两个以上的系统中随机选择使用中的系统，则更难于篡改(在某些实施例中就是这种情况)。

此外，在一些实施例中，提供了利用用户终端定位和基于网络的定位的双重检查。例如，智能手机将自己的当前位置发送到网络位置服务器，并且网络位置服务器可以使用基于网络的位置(UTDOA)双重检查该位置是否正确。

此外，在一些实施例中，也可以检查时间戳。例如，UE内部时钟和网络时钟(例如，网络时间协议，NTP)或卫星时钟(GNSS时钟)可以用于比较相关的时间戳。

在一些实施例中，实现基于视觉的位置识别，如下文所述。

如果终端用户或任何车辆具有摄像头/视频，图像/视频处理/计算机视觉功能等，则可用于识别终端用户的当前位置/方位。自动驾驶汽车/高级安全车可以具有摄像头，并且具有用于识别位置/状况的同时定位和地图绘制(SLAM)的功能。例如，摄像头/视频处理识别公路/高速公路的入口，然后可以将当前位置或状态更改(在高速公路上)发送到区块链oracle。

图10是基于位置的登记的过程或方法75的实施例的流程图，其中在图10中，从区块链oracle接收到登记的触发之后的过程被省略，因为它与图9的实施例中的相同。

旅客的票证76存储在区块链77或MaaS服务器中。在79处，区块链管理77的功能将登记位置或任何其他登记条件的信息发送到区块链oracle78。区块链oracle 78检查旅客76是否具有智能电话/可穿戴设备，并因此检查其是否具有合适的定位能力。然后，区块链oracle 78选择基于位置的登记，然后在80处，区块链oracle 78将地理围栏(geo-fencing)条件的详细信息(例如经度，纬度，区域半径或信标信号信息)发送给旅客的智能手机76。智能手机监视器，其中在81处输入定义的地理围栏触发的区域。当智能电话检测到接近该区域时，它在82处通过蜂窝网络或无线网络向区块链oracle发送触发消息。可选地，如上所述，区块链oracle78可以双重检查(double check)用户的位置。例如，区块链oracle 78在83处向位置服务器84、(例如，电信运营商或服务提供商可以具有SUPL(安全用户平面位置)服务器或E-SMLC(服务移动位置中心))发送询问。位置服务器84启动上面讨论的基于网络的定位，以在85处双重检查位置，并且在86处将结果反馈到区块链oracle 78(例如，在位置被确认的情况下)。如果位置被确认，则区块链oracle 78在87处向区块链管理77发送登记触发以执行智能合约。

在下文中，讨论用于确认登记的基于生物特征学的解决方案的实施例。

如果旅客具有生物特征ID(例如IC芯片护照)或可能没有任何物理ID，但是生物特征数据已预先在服务器中注册，则在某些实施例中可以使用基于生物特征的登记手续。

在一些实施例中，该方法的挑战可能是旅客可能不想与MaaS运营商共享生物特征数据，因为生物特征数据是非常敏感的个人信息。

因此，在一些实施例中，区块链oracle不具有生物特征数据，而是提供了受信任的生物特征服务器来识别该人。

在一些实施例中，以下传感器/装置中的至少一个用于实现基于生物特征的解决方案的传感器/输入：来自安全摄像机的视频/图像(面部识别)，指纹传感器，虹膜识别和/或生物特征ID(例如电子护照)。

图11示出了基于生物特征的登记的方法90的实施例的流程图，其中省略了从区块链oracle接收到登记的触发之后的过程，因为它与图9中的相同。

在图11中，传感器63，旅客62，区块链oracle 61和区块链管理64对应于图9的对应实体，并且在这方面参考图9的描述。此外，提供了生物特征数据库91，其存储了旅客62的生物特征数据。

在92处，传感器63执行例如脸部识别或其他生物特征数据获取，并在93处将旅客62到达的检测结果发送到区块链oracle 61。

例如，来自安全摄像机的视频/图像，无人值守的值机柜台上的指纹/护照数据等都可以发送该数据。如果传感器本身可以识别人员/旅客(例如，它具有面部识别功能)，则将关联的ID发送给区块链oracle 61和/或将原始数据或压缩数据发送至区块链oracle61，且区块链oracle 61识别出旅客62的脸。即使传输原始数据，也可以为数据传输提供加密。

可替代地，如果旅客62具有例如具有面部识别功能或指纹读取器的(高端)智能电话，则智能电话在94处将识别结果发送到区块链oracle 61。例如，可以实现双相机，3D深度相机(例如，基于飞行时间的图像感测)等，以用于更准确的面部识别。在一些实施例中，当前，此类功能通常在高端智能手机中实现，但预计不久的将来，此类功能将在许多智能手机中广泛使用，智能电话还可以具有用于计算机视觉的更高能力的处理器(例如，GPU)等，然后将其用于诸如面部识别的MaaS应用程序。

如果区块链oracle 61未存储生物特征数据或未存储足够的细节以识别旅客，则其在95处向外部生物特征服务器91发送请求以对其进行确认。例如，政府/运输当局可以具有用于生物特征护照的生物特征数据的数据库91。然后，区块链oracle 61将具有加密的传感器数据发送到生物特征数据库91，然后生物特征数据库服务器91可以在96处利用其自己的生物特征数据库91从输入数据中识别该人。如果在96处成功识别了旅客62，则生物特征数据库(服务器)91在97处将确认发送到区块链oracle 61。当区块链oracle 61已经确认了旅客ID时，其在98处将登记触发发送到区块链管理64以执行智能合约。

在一些实施例中，区块链oracle本身不存储来自传感器的原始数据，并且它不必访问生物特征数据服务器上的注册生物特征数据。但是，区块链oracle确认数据源(即传感器)，其是否真实(例如，传感器是否真实)以及生物识别服务器是否真实。从传感器到生物识别服务器的数据不会被修改或更改。区块链oracle无法读取数据，因为它已加密，但是由于可以提供完整性功能，因此区块链oracle可以检测到数据的修改，如下所述。oracle只知道旅客已被生物特征服务器识别。这是一种零知识协议，其在一些实施例中实现。

在下文中，讨论与利用区块链oracle进行数据完整性检查有关的实施例。

区块链oracle从传感器接收数据，并需要检查其完整性。

存在与数据完整性检查有关的各种实施例。一个典型的实施例使用哈希函数，而其他典型的实施例使用完整性数据流。

使用哈希函数的实施例：哈希函数和区块链适用于完整性数据，因为例如，传感器组和区块链oracle处理器连接区块链中的联盟成员，并且传感器数据的哈希函数记录在区块链的关联区块中。如果有人修改了区块中的传感器数据，则将与其他成员(例如，联盟)的区块链中的哈希值不一致。哈希函数有各种建议和实现，例如SHA-2，SHA-3和任何其他海绵函数(sponge function)。根据需求/使用情况，可以静态或半静态(即可更改)选择哈希函数和相关参数(例如，nonce)。

关于完整性算法(流)的实施例：与加密流类似，传感器数据序列在发送者侧用密钥乘以完整性序列(例如Ex-OR计算)。完全相同的序列用相同的密钥应用于接收方，从而，在接收方，受保护的数据将成为原始数据。如果有人在中间修改数据，则接收器的输出结果将是不同的(例如，使用CRC进行错误检测，循环冗余校验)。如果算法的密钥定期或不定期更改，或者使用时间戳/时间计数器/数据包序列号等的组合，则保护将变得更强大，因为(更)难以对复制的数据执行重放攻击。

在下文中，讨论了与利用区块链oracle的传感器/终端的认证/认证检查有关的实施例。

在该实施例中，重要的是检查输入数据是否来自真实的传感器/终端，因为如果使用伪造的传感器或篡改的终端，则可能滥用智能合约，这在该实施例中将被避免。

存在输入传感器/设备的认证的各种实施例，其中，该机制也可以用于输出设备(例如致动器，显示器等)的验证。

一些实施例实现哈希函数/X.509证书，其中，哈希函数可以是发送者的签名。这个想法已被公钥基础结构(PKI)和公钥广泛使用并为人所熟知。在某些实施例中，MaaS运营商(或其他人)提供证书颁发机构(CA)，并将认证颁发给正确安装的传感器/设备。

当传感器/设备物理安装在特定位置时，证书也被配置在传感器/设备中。该方法对于由专业人员安装和配置的固定传感器是有用的(至少在一些实施例中)。

在某些实施例中，硬件制造商的ID/序列号被重复使用。在这种情况下，证书的配置需要工作量，并且在安装后可能需要进行一些管理。在一些实施例中实现的一种简单的方法是重复使用制造商的ID，例如序列号，型号，制造商/工厂的位置等。但是，安全级别/唯一性可能较低，因此，目前该方法可能对非专业人士或终端用户设置的传感器有用，因为它可以避免安装或设置认证或证书。

可选地，制造商在工厂的传感器/设备中安装X.509证书(请参阅上面讨论的解决方案)，或者更可靠的，重复使用其他ID，这也将在下面进一步讨论。

制造商的ID存储在安全的内存/存储器中，以防止出现侧通道攻击，否则可能会有人重写或篡改该ID。

在一些实施例中，蜂窝网络/移动电话ID被重用。与制造商的ID相比，基于标准的ID是可靠且唯一的。

3GPP唯一ID的示例是：国际移动设备身份(IMSI)，国际移动用户身份(IMSI)，C-RNTI(小区无线网络传输标识符)(来自网络)，P-TMSI(分组临时移动订户身份)(来自网络)，GUTI(全球唯一临时标识符)(来自网络)等。

然而，由于在整体情况下唯一的ID，在一些实施例中，ID的长度可能太长。该ID由MaaS运营商外部管理。

此外，例如，旅客拥有具有两个SIM卡插槽和两个插入的SIM卡的智能电话，这样，用于通信的IMSI可以根据所连接的电信运营商而改变，并且/或者旅客可以用新型号替换旧终端，从而可以突然改变IMEI。

因此，为了解决这个问题，在一些实施例中，提供了蜂窝ID(相关的移动电话信息/唯一号码)和Maas用户ID之间的绑定过程，如下文进一步讨论的。

在一些实施例中，使用另一个唯一ID。因此，尽管所讨论的实施例是基于蜂窝ID的，但是它可以是另一个唯一的ID。例如，以太网中的MAC地址，在网卡/接口中是唯一的。可以使用通用唯一标识符(UUID)，可以将全球唯一标识符(GUID)唯一地分配给计算机，蓝牙设备地址，iPhone的唯一标识符(UDID)，ANDROID_ID等，对于具有已安装的操作系统/平台的计算机而言，这是唯一的。

IPv6(IP地址版本6)不是全局唯一的，但与IPv4相比，在受限网络内部冲突的可能性较小，而IPv4由于地址短缺而很可能被重新分配。如果IPv6已分配给受信任的组织且未重复，则可以将其用作唯一ID。

在一些实施例中，将短ID用作唯一ID。

如果该ID太短而不能用作全局ID(例如，C-RNTI为16位，并且可能与其他小区中的相同ID冲突)，则可以分配其他前缀或后缀(例如，MaaS ID等)。

在一些实施例中，随机值被用作唯一ID。

如果生成的号码具有良好的唯一性，并且在特定区域中发生冲突的可能性较小，则在某些实施例中，可以将随机号码用作唯一的ID。

就随机值范围而言，需要随机性的分布。例如，利用伪随机生成器生成值，并且另外基于时间戳/计数器/位置信息等，该值足够唯一。

在那种情况下，区块链的oracle(或终端)将其生成为唯一的ID，并将其存储在安全的存储器/存储中，以防止受到侧信道的攻击。

在下文中，讨论了与用户账户和蜂窝唯一ID的绑定/验证过程/方法有关的实施例。

图12示出了用户帐户和蜂窝唯一ID的绑定过程的方法100的实施例的流程图。提供了区块链oracle服务器101，用于旅客102和区块链管理103与用户简档服务器104之间的通信。

在该实施例中，绑定是指唯一ID和用户帐户之间的映射，该映射存储在用户简档服务器104的数据库中。

当旅客102在MaaS运营商处注册其用户简档时，服务器会在105请求绑定(例如，使用旅客的智能手机上运行的MaaS应用程序)。如果旅客102接受使用移动电话ID，则MaaS应用程序读取唯一ID，然后在106将其发送到用户简档服务器104。该ID应该被加密以进行传输。

然后，用户简档服务器104在107绑定用户帐户和唯一ID(移动电话ID)。

旅客102可以选择一个以上的ID。例如，某些智能手机具有不止一个SIM卡，即不止一个IMSI，因此可以选择两个或多个IMSI。

用户简档服务器104存储用户帐户与其唯一ID之间的关系。用户简档服务器104可以将用户账户和唯一ID之间的映射信息发送给区块链oracle 101。

可选地，可以在终端处处理绑定(例如，通过MaaS应用程序)。然后，用户简档服务器104在108’处发送针对特定用户向区块链oracle 101颁发认证的请求，该请求可以包括基于唯一ID的加密信息。然后，区块链oracle 101在109处将认证发送到终端(例如，在终端上运行的MaaS应用程序)。然后，MaaS应用程序在107'处进行唯一ID与终端内部接收的认证之间的绑定。

除移动电话(终端)外，绑定还可以与常规凭据结合使用，从而可以提供更强的安全性。例如，用户终端可以从IC芯片中扫描或读取数据，例如旅客的护照，驾驶执照等。如果这样的类似文件是由受信任的私人组织发行的，则在某些实施例中也可以使用诸如合作ID卡或信用卡的私人ID。如果凭据与用户简档不匹配，则不接受绑定。

然而，使用手机或其他终端可能会带来容易丢失或被盗的风险。使用他人的电话作为运输票证不仅会给旅客造成经济损失，还会对运输公司或社会造成严重的安全隐患。在乘坐火车/飞机时防止使用丢失/被盗的电话是很重要的。

一些实施例涉及这样的风险，并因此，例如，提供了IMEI(国际移动设备身份)数据库，该数据库存储用于跟踪正确的电话或丢失/被盗的电话的信息(所谓的IMEI黑名单)。电信运营商拥有合约SIM卡和IMSI的用户数据库。在这样的实施例中，区块链oracle可以与这些受信任数据库进行通信，并定期检查该过程中所涉及的移动电话(或其他终端)的状态。

在一些实施例中，即使在绑定之后，如果必要，区块链oracle也可以请求重新确认绑定。例如，终端在原旅客不太可能旅行的意外位置/国家/地区使用，然后区块链oracle可能会要求对绑定进行双重检查/重新确认。

图13示出了用户数据源的验证过程的方法110的实施例的流程图。提供区块链oracle服务器111以用于旅客112与区块链管理113和用户简档服务器114之间的通信。

旅客112拥有具有传感器等的智能电话/可穿戴设备，并且因此在115将传感器数据或触发发送到区块链oracle 111。

如果区块链oracle 111具有绑定信息，则区块链oracle 111在116处验证传感器数据/触发的来源以及用户账户与注册的移动信息之间的绑定。

如果区块链oracle 111未存储绑定数据(作为替代解决方案)，则区块链oracle111在117处向MaaS运营商站点处的用户简档服务器114发送验证唯一ID的请求，其中，用户简档服务器114在118处执行验证，并且如果验证成功，则其在119处向区块链oracle 111发送确认。

区块链oracle 111从用户简档服务器114接收确认，然后区块链oracle111在120处向区块链管理113发送触发以执行智能合约。

可选地，如果绑定在终端(应用程序)处执行，则验证可以在终端侧在121处执行，然后在122处将触发发送到区块链管理113。

在这种情况下，如上所述，智能电话/可穿戴设备通过其自己的传感器来启动触发。应用程序在终端处读取绑定的唯一ID(例如IMSI)，并验证正确的(自己的唯一)ID。终端将具有存储的认证的数据/触发发送到区块链oracle 111。

如上所述，区块链oracle可以在不知道唯一ID的情况下通过认证来验证真实数据源。

尽管此处的实施例集中于MaaS作为使用例，但本公开的总体思想也可以应用于其他应用，例如物联网(IoT)智能合约，金融交易(Fintech)，电信/互联网服务等。

在下文中，参考图14描述通用计算机130的实施例。可以实现计算机130，使得其可以基本上用作任何类型的网络设备，例如基站或新的无线电基站，发送和接收点或通信设备，例如用户设备，(终端)(移动)终端设备或如本文所述。计算机具有组件131至141，其可以形成电路，诸如本文所描述的网络设备和通信设备的电路中的任何一个。

可以将使用软件，固件，程序等来执行本文所述方法的实施例安装在计算机130上，然后将其配置为适合于具体实施例。

计算机130具有CPU 131(中央处理单元)，其可以例如根据存储在只读存储器(ROM)132中、存储在存储器137中并加载到随机存取存储器(RAM)133中、存储在可插入到相应驱动器139中的介质140上的程序等，执行如本文所述的各种类型的过程和方法。

CPU 131，ROM 132和RAM 133与总线141连接，该总线又连接到输入/输出接口134。CPU、存储器和存储装置的数量仅是示例性的，并且技术人员将理解，当计算机130用作基站或用户设备(终端)时，计算机130可以进行相应地修改和配置，以满足出现的特定要求。

在输入/输出接口134处，连接了多个组件：输入135、输出136、存储器137、通信接口138和驱动器139，介质140(压缩光盘，数字视频光盘，紧凑型闪存等)可以插入驱动器139中。

输入135可以是指示器设备(鼠标，图形表等)、键盘、麦克风、照相机、触摸屏等。

输出136可以具有显示器(液晶显示器、阴极射线管显示器、发光二极管显示器等)、扬声器等。

存储器137可以具有硬盘、固态驱动器等。

通信接口138可以适于例如经由局域网(LAN)、无线局域网(WLAN)、移动电信系统(GSM，UMTS，LTE，NR等)、蓝牙，红外等进行通信。

应当注意，以上描述仅涉及计算机130的示例配置。可以使用附加或其他传感器、存储设备、接口等来实现替代配置。例如，通信接口138可以支持除了提到的UMTS、LTE和NR之外的其他无线电接入技术。

当计算机130用作基站时，通信接口138可以进一步具有相应的空中接口(例如提供E-UTRA协议OFDMA(下行链路)和SC-FDMA(上行链路))和网络接口(实现例如S1-AP，GTP-U，S1-MME，X2-AP等协议)。此外，计算机130可以具有一个或多个天线和/或天线阵列。本公开不限于这种协议的任何特征。

参考图15，讨论了移动终端的实施例，该移动终端被配置为用于实现本公开的实施例的用户设备UE 150和eNB 155以及UE 150和eNB 155(或NR eNB/gNB)之间的通信路径154。UE 150是通信设备的示例，而eNB是基站(即，网络设备)的示例，而在这方面不限制本公开。

UE 150具有发射器151、接收器152和控制器153，其中，通常，发射器151、接收器152和控制器153的技术功能是技术人员已知的，因此，省略它们的更加详细描述。

eNB 155具有发射器156、接收器157和控制器158，其中，一般来说，发射器156、接收器157和控制器158的功能在此也是技术人员已知的，因此省略它们的更详细描述。

通信路径154具有从UE 150到eNB 155的上行链路路径154a和从eNB 155到UE 150的下行链路路径154b。

在操作期间，UE 150的控制器153控制在接收器152处在下行链路路径154b上的下行链路信号的接收，并且控制器153控制经由发射器151在上行链路路径154a上的上行链路信号的传输。

类似地，在操作期间，eNB 155的控制器158控制在发射器156上的下行链路路径154b上的下行链路信号的传输，并且控制器158控制在接收器157处的上行链路路径154a上的上行链路信号的接收。

如从描述中显而易见的，进一步总结，一些实施例涉及用于向分布式分类账提供数据的通信网络节点，其中，该节点具有配置为执行以下至少一项的电路：提供对用作智能合约的输入的输入数据的验证，提供对基于智能合约的输出的输出数据是否在预定设备上正确接收的验证。

通信网络节点可以是诸如基站，eNodeB等的网络设备，但是该节点也可以被配置为诸如用户设备，(终端)终端设备等的通信设备(例如手机，智能手机、计算机、笔记本电脑、笔记本电脑等)，其具有相应配置的电路。具体地，通信网络节点可以是如本文所讨论的区块链oracle。

在一些实施例中，分布式分类账包括(或者是)区块链，其中，区块链可以包括多个块。

在一些实施例中，分布式分类账包括用于移动即服务的数据。

在一些实施例中，基于许可权来授权对分布式分类账的访问，其中该节点可以是联盟的一部分。联盟可以由移动服务提供商提供，其中，例如，每个节点可以对应于一个移动服务提供商或可以与一个移动服务提供商相关联。

如所讨论的，分布式分类账可以包括区块链，其中，区块链可以包括含有非敏感用户数据的多个区块，并且其中，分布式分类账可以包括用于移动即服务的数据。因此，在一些实施例中，通信网络及其节点被配置为提供MaaS。

可以基于传感器数据来验证输入数据，该传感器数据标识用户。可以由用户的移动终端中包括的至少一个传感器(例如，定位传感器、成像传感器、指纹传感器等)提供传感器数据。

可以由检测用户的至少一个传感器(例如，位于用户进入并被检测的到达地点或登记，登记等处的传感器)提供传感器数据。

该电路可以进一步被配置为提供传感器的认证，传感器提供传感器数据，可以确保传感器是受到信任的。

传感器数据可以包括位置数据或生物特征数据。

位置数据可以被发送到位置服务器以进行验证。

生物特征数据可以被发送到生物特征数据服务器以进行验证。

电路可以进一步被配置为基于数据完整性功能来接收或发送数据，其中数据完整性功能可以基于以下各项中的至少一项：哈希函数、数字签名、块流算法。

该电路可以进一步被配置为发送用于引起智能合约的执行的触发。

在成功验证输入数据的情况下，可以发送触发。

该电路可以进一步被配置为执行基于用户的标识和基于移动终端的标识之间的绑定。

验证可以涉及绑定的验证。

基于移动终端的标识可以包括蜂窝国际移动用户身份、蜂窝IMEI中的至少一项。

该电路可以进一步被配置为验证所连接的设备的认证。

可以基于以下各项中的至少一项来验证所连接设备的认证：基于哈希函数的认证、标准基础认证、所连接设备的制造商标识、设备的预配置，与所连接设备关联的唯一网络或蜂窝标识。

一些实施例涉及一种用于操作智能合约的方法，其中，智能合约具有至少两个不同的状态，该方法包括响应于接收触发而改变智能合约的状态。

至少两个不同状态可以包括以下至少之一：登记状态、签出状态、使用中状态、未使用状态、取消状态。

如本文所讨论的，可以从受信任网络通信节点(例如，区块链oracle)接收触发。

可以从受信任的传感器接收触发(例如，基于认证进行验证)。

可以响应于接收到触发来执行智能合约。

智能合约的执行结果可能取决于智能合约的状态。

一些实施例涉及一种用于控制通信网络的方法，该通信网络包括用于提供分布式分类账的多个节点，该方法包括以下至少一项：提供对用作智能合约的输入的输入数据的验证；提供在预定设备上是否正确接收了基于来自智能合约的输出的输出数据的验证。该方法可以由本文所讨论的通信网络的一个或多个节点执行，和/或由移动终端或任何其他处理设备或电路执行。

可以基于传感器数据来验证输入数据，该传感器数据标识用户。

传感器数据可以由用户的移动终端中包括的至少一个传感器提供。

传感器数据可以由至少一个检测用户的传感器来提供。

该方法可以进一步包括提供传感器的认证，所述传感器提供传感器数据。

传感器数据可以包括位置数据或生物特征数据。

该方法可以进一步包括将位置数据发送到位置服务器以进行验证。

该方法可以包括将生物特征数据发送到生物特征数据服务器以进行验证。

该方法可以进一步包括基于数据完整性功能性来接收或发送数据。

数据完整性功能可以基于以下至少一项：哈希函数、数字签名、区块流算法。

该方法可以进一步包括发送用于引起智能合约的执行的触发。

在成功验证输入数据的情况下，可以发送触发。

可以基于以下各项中的至少一项来发送触发：用户标识、用户的基于位置的检测，用户的基于生物特征的检测。

基于位置的检测可以涉及基于由用户的设备提供的位置数据和用户的基于网络的位置来检查用户的位置。

基于位置的检测可以涉及用于识别用户的视觉处理。

该方法还包括在基于用户的标识和基于移动终端的标识之间执行绑定。

验证可以涉及绑定的验证。

基于移动终端的标识可以包括蜂窝国际移动用户身份、蜂窝IMEI中的至少一项。

该方法可以进一步包括验证所连接的设备的认证。

可以基于以下各项中的至少一项来验证所连接设备的认证：基于哈希函数的认证、标准基础认证、所连接设备的制造商标识、设备的预配置、与所连接设备关联的唯一网络或蜂窝标识。

分布式分类账可以包括区块链。

分布式分类账可以包括用于移动即服务的数据。

可以基于许可权来授权对分布式分类账的访问。

节点可以是联盟的一部分。

验证的提供可以基于智能合约可能被篡改的风险，其中，可以基于该风险而省略或限制验证(例如，一次检查而不是再次检查等)。

一些实施例涉及如本文所讨论的用于与网络节点(如本文所讨论的)通信以向分布式分类账提供数据的移动终端，其中，移动终端具有被配置为提供用作智能合约的输入的输入数据的电路。

该移动终端可以具有至少一个传感器，其中基于至少一个传感器(例如，成像传感器、指纹传感器、生物特征传感器、位置/导航传感器等)的传感器数据来提供输入数据。至少一个传感器可以提供位置数据或生物特征数据。

该电路可以进一步被配置为执行应用，该应用被配置为向网络节点提供输入数据，其中该应用可以是移动即服务应用。

移动终端可以是智能电话(或任何其他智能设备，可穿戴设备等)。

该应用可以被配置为执行用户的认证(例如，通过面部识别、指纹识别或其他生物特征数据验证)。

该应用可以被配置为基于由移动终端的传感器提供的传感器数据(例如，基于位置的登记和/或基于生物特征的登记)来确定用户的登记。

该电路可以进一步被配置为在移动终端和应用之间执行绑定，其中，可以基于可以从网络节点接收到的认证来执行绑定。

在下文中，给出了一些术语定义，其可以在一些实施例中应用(不将本公开限制于以下给出的定义。由于MaaS和分布式分类账的技术领域是高度动态的，并且定义在将来可能改变，因此定义仅是被提供用于增强对本公开的理解的示例并且仅被给出。)

术语“分布式分类账”可从Wikipedia中得知，该术语定义：“分布式分类账(也称为共享分类账，或分布式分类账技术，DLT)是复制，共享和同步的数字数据在地理上分布在多个站点、国家或机构的共识。没有中央管理员或集中式数据存储。”

术语“移动即服务(MaaS)”也可从Wikipedia中得知，定义为：“移动即服务(MaaS)描述了从个人拥有的运输方式向服务即消费的移动解决方案的转变。通过创建和管理行程的统一网关，将公共和私人交通提供商的交通服务结合起来，即可实现此目的，用户可以使用一个帐户付费。用户可以为有限距离的每次旅行或按月付费。MaaS背后的关键概念是根据旅行者的旅行需求提供旅行者出行解决方案。”

在一些实施例中，“公共区块链/分布式分类账”意味着任何人都可以共享分布式数据库(分类账)并加入以执行共识协议，如上所述。

与此相反，“许可的区块链/分布式分类账”意味着只有允许的成员才能共享分布式数据库(分类账)并加入共识协议。如上所述，允许访问区块链的许可成员称为“联盟”。在一些实施例中，许可/联盟类型的区块链适合于MaaSap应用，因为它们不是公共的，因此没有人可以访问它。

术语“实例”被理解为在云上运行的软件过程。它可能会移动到分布式云中的某些位置。

“公共云”可以定义为(https://azure.microsoft.com/en-gb/overview/what-are-pri-vate-public-hybrid-clouds/)：“公共云是部署云计算的最常见方法。云资源(如服务器和存储)由第三方云服务提供商拥有和运营，并通过Internet交付。”

在某些实施例中，在给定的理解中将使用以下术语：

术语“多模式联运通行证”可以是对具有特定条件(例如有效期或可用的运输、不可接受的服务等)的多移动性服务有效的通行证。例如，一日票，一周票，每月MaaS服务订阅，季节性机票等

术语“移动服务提供商”可以是任何类型的服务提供商MaaS的统称。在一些实施例中，它通常是运输组织，例如铁路公司、公共汽车/长途汽车，电车和出租车、汽车共享、乘车共享、自行车共享等。一些移动服务提供商可能未提供实际的运输方式，但可能只提供预订/安排、与旅行社或在线预订网站的比较等。

术语“通行证”可以是公交通行证或旅行卡(英国)(另请参见https://en.wikipe-dia.org/wiki/Transit_pass)。在本公开中，多模式联运通票也应属于术语“通行证”，这意味着该通行证可能在不止一个运输运营商(或提供的出行服务)中有效，因此，它不仅可以覆盖公共交通，还可以覆盖其他类型的出行，例如乘车、骑自行车等。通行证可能包括可接受的交通，有效期以及任何其他发行/运输车票条件的信息。在一些实施例中，MaaS可以提供具有服务水平的某些选项的每月服务订阅。旅客或用户可以向通行证发行人(通常可以是发行通行证的移动服务提供商)支付服务订购费或购买特定时期的通行证。该通行证可以由运输运营商或旅行社，MaaS服务提供商等(如上所述，可能都属于术语“移动服务提供商”)发行。因此，如上所述，一些通行证发行者可以出售通行证，但可能不提供实际的运输服务或运输手段。

术语“票证”可以是特定部分的单程车票，例如带(或不带)座位的单程火车票。在某些实施例中，票可以在多模式联运通票及其条款和条件下发行，并且可以包括选定的运输、座位号、价格等信息。在某些实施例中，即使不需要预订座位或允许无限制旅行，则可以发行票证以在多个移动服务提供商之间共享收益。此外，旅客(用户)可能不会直接为票务发行者付款，而通行证发行人可能会代替旅客为票务发行者付款，并且票证可能由运输运营商或服务提供商(即移动服务提供商)发行。

术语“旅程日志”可以涵盖为基于票证的单程旅程记录的旅程日志。它可能包括有关登船位置、时间/日期、下车的位置、时间/日期、车票是已使用还是未使用等信息，这也将进一步讨论。

术语“智能合约”是众所周知的，并且例如，Wikipedia对此进行了说明(https://en.wikipedia.org/wiki/Smart_contract)：“智能合约是一种旨在以数字方式促进、验证或强制执行合约的谈判或履行的计算机协议。智能合约允许在没有第三方的情况下进行可靠的交易。这些交易是可追踪且不可逆的。智能合约最早是由尼克·萨博(Nick Szabo)于1994年提出的。智能合约的支持者声称，许多类型的合同条款可以部分或完全自动执行、自动执行或两者兼而有之。智能合约的目的是提供优于传统合约法的安全性，并减少与合约相关的其他交易成本。各种加密货币已经实现了智能合约的类型。”

在某些方面可以在不限制本公开的情况下使用的智能合约语言是用于描述区块链中的智能合约的计算机语言，并且可以在用于区块链的虚拟机上运行/执行。另外，可以使用多种语言。例如，以太坊项目的Solidity团队开发了智能合约语言“Solidity”。

在一些实施例中，术语“区块链Oracles”在某种意义上也被理解为在https://blog.apla.io/what-is-a-blockchain-oracle-2ccca433c026之下公开的含义：“oracle是什么？

根据各种在线词典，oracle可以定义为“权威或明智的表达或答案”或“被认为对某事具有绝对权威的人或事”。实际上，字典本身可以看作是oracle，但这与区块链有什么关系？什么是区块链oracle？

要了解区块链oracle，读者应该首先熟悉区块链和智能合约。智能合约是一种在以太坊(Ethereum)或Apla等区块链网络上运行并根据某些事件执行操作或任务的软件代码。最明显的示例是在以太坊网络上发送交易，其中，我向网络提供接收方的地址以及我具有并拥有资金的证明。如果一切顺利，网络将把资金“转移”到接收方。”进一步说明，对于需要外部数据(例如当前天气温度、股票价格甚至FIFA世界杯决赛结果)的分散应用程序，问题在于智能合约(换句话说，就是区块链上的一段代码)如何获取信息，并且在这种情况下，可以使用针对区块链应用程序的oracle。

而且，“Oracle是受信任的数据源或实体，可为智能合约提供有关世界状况的信息或签署声明。它们是现实世界事件与区块链平台数字世界之间的联系。它们不会对未来做出预测，而是报告过去的事件。”

在一些实施例中，术语“有状态/无状态智能合约”被理解如下：有状态意味着将内部状态保持在区块链中。这类似于包括循环过程的计算机程序，并且可能适合于描述复杂的条件。无状态意味着不将内部状态保留在区块链中。这个过程很简单。描述简单条件是合适的。

术语“数据完整性”可以理解为由Wikipedia(https://en.wikipe-dia.org/wiki/Data_integrity)定义：“数据完整性是数据在其整个生命周期中的维护以及准确性和一致性的保证，并且是设计、实施和使用存储、处理或检索数据的任何系统的关键方面。”

术语“证书颁发机构(CA)”可以理解为由Wikipedia(https://en.wik-ipedia.org/wiki/Certificate_authority)定义：“在密码学中，证书颁发机构或认证颁发机构(CA)是颁发数字证书的实体。数字证书通过证书的指定主题来证明公钥的所有权。这允许其他人(依赖方)依赖于对与经指定的公钥相对应的私钥所做的签名或声明。

CA充当受信任的第三方，受证书的主体(所有者)和依赖证书的当事方信任。这些证书的格式由X.509标准指定。”

术语“欺骗”可以理解为由Wikipedia(https://en.wikipe-dia.org/wiki/Spoofing_attack#GPS_spoofing)定义：“欺骗-在信息安全(尤其是网络安全)的背景下，欺骗攻击是指某个人或程序通过伪造数据成功伪装成另一个人或程序，从而获得非法利益的情况。

GPS/GNSS欺骗

GPS欺骗攻击试图通过广播不正确的GPS信号(结构类似于一组正常的GPS信号)或通过重新广播在其他地方或在不同时间捕获的真实信号来欺骗GPS接收器。可以修改这些欺骗信号，以使接收器估计其位置，而不是其实际位置，或者将其位置估计为攻击者确定的时间，但位于不同的时间。GPS欺骗攻击的一种常见形式，通常称为带走攻击，始于广播与目标接收器观测到的真实信号同步的信号。然后，伪造信号的力量会逐渐增加，并从真正的信号中消失。”

术语“侧信道攻击”可以理解为由Wikipedia(https://en.wikipe-dia.org/wiki/Side-channel_attack)定义：“在计算机安全中，侧信道攻击是指基于从计算机系统的实施中获得的信息的任何攻击，而不是基于实施的算法本身的弱点(例如，密码分析和软件错误)。定时信息、功耗、电磁泄漏甚至声音可以提供额外的信息来源，可以加以利用。”

术语“零知识证明/协议”可以理解为Wikipedia(https://en.wikipedia.org/wiki/Zero-knowledge_prooQ)的定义：“在密码学中，零知识证明或零知识协议是一种方法，通过该方法一方(证明方)可以通过该方向另一方(验证方)证明他们知道值x，而无需传达任何信息(除了他们知道值x的事实)。零知识证明的本质是，通过简单地揭示信息来证明某人拥有某些信息的知识是微不足道的；面临的挑战是在不透露信息本身或任何其他信息的情况下证明拥有这种财产。”

在一些实施例中，涉及与蜂窝定位有关的以下术语：

基于UE的定位：观测到的到达时差(OTDOA)，基于小区ID

基于网络的定位：上行链路到达时间差(UTDOA)

电信网络中的位置服务器：安全用户平面位置(SUPL)服务器、增强型服务移动位置中心(E-SMLC)

如本文所述的方法在一些实施例中还被实现为计算机程序，当在计算机和/或处理器和/或电路上执行时，该计算机程序使计算机和/或处理器和/或电路执行该方法。在一些实施例中，还提供了一种非暂时性计算机可读记录介质，该介质在其中存储了计算机程序产品，当该计算机程序产品由诸如上述处理器的处理器执行时，使得本文所述的方法得以执行。

应该认识到，实施例以方法步骤的示例性顺序描述了方法。但是，方法步骤的特定顺序仅出于说明目的而给出，不应解释为具有约束力。

如果没有另外说明，可以将本说明书中描述的以及所附权利要求书中要求保护的所有单元和实体实现为集成电路逻辑，例如在芯片上，并且如果没有另外说明，则可以通过软件来实现由这些单元和实体提供的功能。

就上述本公开的实施例而言，至少部分地使用软件控制的数据处理设备来实现，应当理解，将提供这样的软件控制的计算机程序以及通过其提供这样的计算机程序的传输，存储或其他介质设想为本公开的方面。

注意，本技术还可以如下配置。

(1)一种用于向分布式分类账提供数据的通信网络节点，其中，该节点包括配置为执行以下至少一项的电路：

提供用作智能合约输入的输入数据的验证，

提供在预定设备上是否正确接收了基于从智能合约输出的输出数据的验证。

(2)根据(1)的通信网络节点，其中，基于传感器数据来验证输入数据，传感器数据标识用户。

(3)根据(2)的通信网络节点，其中，传感器数据由包括在用户的移动终端中的至少一个传感器提供。

(4)根据(2)或(3)的通信网络节点，其中，传感器数据由检测用户的至少一个传感器提供。

(5)根据(2)至(4)中任一项的通信网络节点，其中，电路还被配置为提供传感器的认证，传感器提供传感器数据。

(6)根据(2)至(5)中的任何一个的通信网络节点，其中，传感器数据包括位置数据或生物特征数据。

(7)根据(6)的通信网络节点，其中，位置数据被发送到位置服务器以进行验证。

(8)根据(6)或(7)的通信网络节点，其中，生物特征数据被发送到生物特征数据服务器以进行验证。

(9)根据(1)至(8)中任一项的通信网络节点，其中，电路还被配置为基于数据完整性功能来接收或发送数据。

(10)根据(9)的通信网络节点，其中，数据完整性功能基于以下各项中的至少一项：哈希函数、数字签名、区块流算法。

(11)根据(1)至(10)中任一项的通信网络节点，其中，电路还被配置为发送用于引起智能合约的执行的触发。

(12)根据(11)的通信网络节点，其中，在成功验证输入数据的情况下，发送触发。

(13)根据(1)至(12)中任一项的通信网络节点，其中，电路还被配置为在基于用户的标识与基于移动终端的标识之间执行绑定。

(14)根据(13)的通信网络节点，其中，验证包括对绑定的验证。

(15)根据(13)或(14)的通信网络节点，其中，基于移动终端的标识包括蜂窝国际移动用户标识、蜂窝国际移动台设备标识中的至少一项。

(16)根据(1)至(15)中任一项的通信网络节点，其中，电路还被配置为验证所连接的设备的认证。

(17)根据(16)的通信网络节点，其中，基于以下项中的至少一项来验证连接的设备的认证：基于哈希函数的认证、标准基础认证、连接的设备的制造商标识、设备的预配置、与连接的设备关联的唯一网络或蜂窝标识。

(18)根据(1)至(17)中任一项的通信网络节点，其中，分布式分类账包括区块链。

(19)根据(1)至(18)中任一项的通信网络节点，其中，分布式分类账包括用于移动即服务的数据。

(20)根据(1)至(19)中任一项的通信网络节点，其中，基于许可权来授权对分布式分类账的访问。

(21)根据(20)的通信网络节点，其中，节点是联盟的一部分。

(22)一种用于操作智能合约的方法，其中，智能合约具有至少两个不同状态，方法包括：

响应于接收到触发而改变智能合约的状态。

(23)根据(22)的方法，其中，至少两个不同状态包括以下至少一项：登记状态、签出状态、使用中状态、未使用状态、取消状态。

(24)根据(22)或(23)的方法，其中，触发是从受信任网络通信节点接收的。

(25)根据(22)至(24)中的任一项的方法，其中，触发是从受信任传感器接收的。

(26)根据(22)至(25)中任一项的方法，其中，响应于接收到触发而执行智能合约。

(27)根据(26)的方法，其中，智能合约的执行结果取决于智能合约的状态。

(28)一种用于控制通信网络的方法，该通信网络包括多个节点以提供分布式分类账，方法包括以下至少一项：

提供用作智能合约输入的输入数据的验证，

提供在预定设备上是否正确接收了基于从智能合约输出的输出数据的验证。

(29)根据(28)的方法，其中，基于传感器数据来验证输入数据，传感器数据标识用户。

(30)根据(29)的方法，其中，传感器数据由包括在用户的移动终端中的至少一个传感器提供。

(31)根据(29)或(30)的方法，其中，传感器数据由至少一个检测用户的传感器提供。

(32)根据(29)至(31)中任一项的方法，还包括提供传感器的认证，传感器提供传感器数据。

(33)根据(29)至(32)中的任一项的方法，其中，传感器数据包括位置数据或生物特征数据。

(34)根据(33)的方法，还包括：将位置数据发送到位置服务器以进行验证。

(35)根据(33)或(34)的方法，还包括将生物特征数据发送到生物特征数据服务器以进行验证。

(36)根据(28)至(35)中任一项的方法，还包括基于数据完整性功能来接收或发送数据。

(37)根据(36)的方法，其中，数据完整性功能基于以下各项中的至少一项：哈希函数、数字签名、区块流算法。

(38)根据(28)至(37)中任一项的方法，还包括发送用于引起智能合约的执行的触发。

(39)根据(38)的方法，其中，在成功验证输入数据的情况下，发送触发。

(40)根据(38)或(39)的方法，其中，触发是基于以下中的至少一项来发送的：用户标识、用户的基于位置的检测、用户的基于生物特征的检测。

(41)根据(40)的方法，其中，基于位置的检测包括基于由用户的设备提供的位置数据和用户的基于网络的位置来检查用户的位置。

(42)根据(40)或(41)的方法，其中，基于位置的检测包括用于识别用户的视觉处理。

(43)根据(28)至(42)中任一项的方法，还包括在基于用户的标识与基于移动终端的标识之间执行绑定。

(44)根据(43)的方法，其中，验证包括对绑定的验证。

(45)根据(43)或(44)的方法，其中，基于移动终端的标识包括蜂窝国际移动用户标识、蜂窝国际移动台设备标识中的至少一项。

(46)根据(28)至(45)中任一项的方法，还包括验证所连接的设备的认证。

(47)根据(46)的方法，其中，基于以下项中的至少一项来验证连接的设备的认证：基于哈希函数的认证、标准基础认证、连接的设备的制造商标识、设备的预配置、与连接的设备关联的唯一网络或蜂窝标识。

(48)根据(28)至(47)中任一项的方法，其中，分布式分类账包括区块链。

(49)根据(28)至(48)中任一项的方法，其中，分布式分类账包括用于移动即服务的数据。

(50)根据(28)至(49)中任一项的方法，其中，基于许可权来授权对分布式分类账的访问。

(51)根据(50)的方法，其中，节点是联盟的一部分。

(52)根据(28)至(51)中任一项的方法，其中，提供验证是基于智能合约可能被篡改的风险。

(53)根据(52)的方法，其中，基于风险，可以省略或限制验证。

(54)一种用于与网络节点进行通信以向分布式分类账提供数据的移动终端，其中，移动终端包括被配置为执行以下操作的电路：

提供用作智能合约输入的输入数据。

(55)根据(54)的移动终端，还包括至少一个传感器，其中，基于至少一个传感器的传感器数据来提供输入数据。

(56)根据(55)的移动终端，其中，至少一个传感器提供位置数据或生物特征数据。

(57)根据(54)至(56)中任一项的移动终端，其中，电路还被配置为执行应用，应用被配置为将输入数据提供给网络节点。

(58)根据(57)的移动终端，其中，应用是移动即服务应用。

(59)根据(54)至(58)中任一项的移动终端，其中，移动终端是智能电话。

(60)根据(57)的移动终端，其中，应用被配置为执行用户的认证。

(61)根据(58)至(60)中任一项的移动终端，其中，应用被配置为基于由移动终端的传感器提供的传感器数据来确定用户的登记。

(62)根据(57)至(61)中任一项的移动终端，其中，电路还被配置为执行移动终端与应用之间的绑定。

(63)根据(62)的移动终端，其中，绑定是基于认证来执行的。

(64)根据(62)或(63)的移动终端，其中，从网络节点接收认证。