基于区块链的状态机维护方法及装置、电子设备、存储介质与流程

本说明书一个或多个实施例涉及区块链技术领域，尤其涉及一种基于区块链的状态机维护方法及装置、电子设备、存储介质。

背景技术：

区块链技术，也被称之为分布式账本技术，是一种由若干台计算设备共同参与“记账”，共同维护一份完整的分布式数据库的新兴技术。由于区块链技术具有去中心化、公开透明、每台计算设备可以参与数据库记录、并且各计算设备之间可以快速的进行数据同步的特性，使得区块链技术已在众多的领域中广泛的进行应用。

技术实现要素：

有鉴于此，本说明书一个或多个实施例提供一种基于区块链的状态机维护方法及装置、电子设备、存储介质。

为实现上述目的，本说明书一个或多个实施例提供技术方案如下：

根据本说明书一个或多个实施例的第一方面，提出了一种基于区块链的状态机维护方法，应用于区块链节点，所述区块链节点维护了与所述区块链上存证的电子票据对应的状态机；所述状态机包括所述电子票据的生命周期中的若干种票据状态；以及，触发将所述电子票据切换至所述若干种票据状态的操作数据；所述方法包括：

接收针对目标电子票据的操作交易；

响应于所述操作交易，将经过共识的与所述操作交易相关的针对所述目标电子票据的操作数据发布至所述区块链进行存证；

当监听到所述区块链上存证了针对所述目标电子票据的操作数据时，确定监听到的操作数据是否与所述状态机中的操作数据相匹配；

如果是，根据监听到的操作数据对所述状态机的票据状态进行切换。

可选的，所述操作交易为包含针对所述目标电子票据执行操作处理的操作数据的存证交易；与所述操作交易相关的针对所述目标电子票据的操作数据，为所述操作交易中包含的所述操作数据；

所述响应于所述操作交易，将经过共识的与所述操作交易相关的针对所述目标电子票据的操作数据发布至所述区块链进行存证，包括：

响应于所述操作交易，将经过共识的所述操作交易发布至所述区块链进行存证。

可选的，所述操作交易为调用智能合约的交易；与所述操作交易相关的针对所述目标电子票据的操作数据，为调用所述智能合约针对所述目标电子票据执行操作处理生成的操作数据；

所述响应于所述操作交易，将经过共识的与所述操作交易相关的针对所述目标电子票据的操作数据发布至所述区块链进行存证，包括：

调用发布在所述区块链上的智能合约中声明的票据处理逻辑，对所述目标电子票据执行操作处理；

将对所述目标电子票据执行操作处理而生成的操作数据发布至所述区块链上进行存证。

可选的，还包括：

接收票据状态查询方发送的针对所述目标电子票据的票据状态的查询请求；

获取所述状态机当前所处的票据状态，并将获取到的票据状态返回给所述据状态查询方。

可选的，还包括：

如果所述状态机的票据状态发生切换，将切换后的所述电子票据的票据状态，推送至与所述状态机对应的票据状态订阅方。

可选的，所述状态机包括电子票据的生命周期中的未报销状态、报销锁定状态、已报销状态、已入账状态、已开红票状态、已打印状态、已作废状态；

触发将所述状态机的票据状态由未报销状态切换至报销锁定状态的操作数据为，针对目标电子票据的报销交易中携带的所述目标电子票据的标识信息；

触发将所述状态机的票据状态由报销锁定状态切换至已报销状态的操作数据为，针对目标电子票据的报销结果；

触发将所述状态机的票据状态由已报销状态切换至已入账状态的操作数据为，针对目标电子票据的入账结果；

触发将所述状态机的票据状态由未报销状态切换至已开红票状态的操作数据为，针对目标电子票据的冲红结果；

触发将所述状态机的票据状态由未报销状态切换至已打印状态的操作数据为，针对目标电子票据的打印结果；

触发将所述状态机的票据状态由未报销状态切换至已作废状态的操作数据为，针对目标电子票据的作废结果。

根据本说明书一个或多个实施例的第二方面，提出了一种基于区块链的状态机维护装置，应用于区块链节点，所述区块链节点维护了与所述区块链上存证的电子票据对应的状态机；所述状态机包括所述电子票据的生命周期中的若干种票据状态；以及，触发将所述电子票据切换至所述若干种票据状态的操作数据；所述装置包括：

第一接收单元，接收针对目标电子票据的操作交易；

存证单元，响应于所述操作交易，将经过共识的与所述操作交易相关的针对所述目标电子票据的操作数据发布至所述区块链进行存证；

切换单元，当监听到所述区块链上存证了针对所述目标电子票据的操作数据时，确定监听到的操作数据是否与所述状态机中的操作数据相匹配；

如果是，根据监听到的操作数据对所述状态机的票据状态进行切换。

可选的，所述操作交易为包含针对所述目标电子票据执行操作处理的操作数据的存证交易；与所述操作交易相关的针对所述目标电子票据的操作数据，为所述操作交易中包含的所述操作数据；

所述存证单元具体用于：

响应于所述操作交易，将经过共识的所述操作交易发布至所述区块链进行存证。

可选的，所述操作交易为调用智能合约的交易；与所述操作交易相关的针对所述目标电子票据的操作数据，为调用所述智能合约针对所述目标电子票据执行操作处理生成的操作数据；

所述存证单元具体用于：

调用发布在所述区块链上的智能合约中声明的票据处理逻辑，对所述目标电子票据执行操作处理；

将对所述目标电子票据执行操作处理而生成的操作数据发布至所述区块链上进行存证。

可选的，还包括：

第二接收单元，接收票据状态查询方发送的针对所述目标电子票据的票据状态的查询请求；

返回单元，获取所述状态机当前所处的票据状态，并将获取到的票据状态返回给所述据状态查询方。

可选的，还包括：

推送单元，如果所述状态机的票据状态发生切换，将切换后的所述电子票据的票据状态，推送至与所述状态机对应的票据状态订阅方。

可选的，所述状态机包括电子票据的生命周期中的未报销状态、报销锁定状态、已报销状态、已入账状态、已开红票状态、已打印状态、已作废状态；

触发将所述状态机的票据状态由未报销状态切换至报销锁定状态的操作数据为，针对目标电子票据的报销交易中携带的所述目标电子票据的标识信息；

触发将所述状态机的票据状态由报销锁定状态切换至已报销状态的操作数据为，针对目标电子票据的报销结果；

触发将所述状态机的票据状态由已报销状态切换至已入账状态的操作数据为，针对目标电子票据的入账结果；

触发将所述状态机的票据状态由未报销状态切换至已开红票状态的操作数据为，针对目标电子票据的冲红结果；

触发将所述状态机的票据状态由未报销状态切换至已打印状态的操作数据为，针对目标电子票据的打印结果；

触发将所述状态机的票据状态由未报销状态切换至已作废状态的操作数据为，针对目标电子票据的作废结果。

根据本说明书一个或多个实施例的第三方面，提出了一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器通过运行所述可执行指令以实现如上述任一实施例中所述的基于区块链的状态机维护方法。

根据本公开实施例的第四方面，提供一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如上述实施例中任一基于区块链的状态机维护方法的步骤。

由以上技术方案可见，由区块链节点来维护电子票据在整个生命周期中所处的各个票据状态，那么搭建区块链的各个参与方可通过共识在区块链上共同维护电子票据的票据状态，以及通过区块链来了解电子票据当前所处的状态，从而判断是否可对电子票据执行特定的操作。例如，报销单位在对电子票据进行报销之前，可通过区块链维护的状态机来查询该电子票据是否已被报销、作废、冲红等，从而提高报销电子票据的效率，避免出现重复报销、报销出错等问题。

附图说明

图1是一示例性实施例提供的一种创建智能合约的示意图；

图2是一示例性实施例提供的调用智能合约的示意图；

图3是一示例性实施例提供的创建智能合约和调用智能合约的示意图；

图4是本申请一示例性实施例提供的切换电子票据的票据状态的示意图；

图5是一示例性实施例提供的一种基于区块链的状态机维护方法的流程图；

图6是一示例性实施例提供的一种基于区块链的票据状态推送方法的流程图；

图7是一示例性实施例提供的一种基于区块链的状态机维护方案的整体架构示意图；

图8是一示例性实施例提供的另一种基于区块链的状态机维护方案的整体架构示意图；

图9是一示例性实施例提供的一种订阅票据状态的交互图；

图10是一示例性实施例提供的一种票据状态推送方法的交互图；

图11是一示例性实施例提供的另一种票据状态推送方法的交互图；

图12是一示例性实施例提供的一种获取票据状态的交互图；

图13是一示例性实施例提供的一种报销校验的交互图；

图14是一示例性实施例提供的一种设备的结构示意图；

图15是一示例性实施例提供的一种基于区块链的票据状态推送装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。

需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。

区块链一般被划分为三种类型：公有链(publicblockchain)，私有链(privateblockchain)和联盟链(consortiumblockchain)。此外，还有多种类型的结合，比如私有链+联盟链、联盟链+公有链等不同组合形式。其中去中心化程度最高的是公有链。公有链以比特币、以太坊为代表，加入公有链的参与者可以读取链上的数据记录、参与交易以及竞争新区块的记账权等。

而且，各参与者(即节点)可自由加入以及退出网络，并进行相关操作。私有链则相反，该网络的写入权限由某个组织或者机构控制，数据读取权限受组织规定。简单来说，私有链可以为一个弱中心化系统，参与节点具有严格限制且少。这种类型的区块链更适合于特定机构内部使用。

联盟链则是介于公有链以及私有链之间的区块链，可实现“部分去中心化”。联盟链中各个节点通常有与之相对应的实体机构或者组织；参与者通过授权加入网络并组成利益相关联盟，共同维护区块链运行。

不论是公有链、私有链还是联盟链，都可能提供智能合约(smartcontract)的功能。区块链上的智能合约是在区块链系统上可以被交易触发执行的合约。智能合约可以通过代码的形式定义。

以以太坊为例，支持用户在以太坊网络中创建并调用一些复杂的逻辑，这是以太坊区别于比特币区块链技术的最大挑战。以太坊作为一个可编程区块链的核心是以太坊虚拟机(evm)，每个以太坊节点都可以运行evm。evm是一个图灵完备的虚拟机，这意味着可以通过它实现各种复杂的逻辑。用户在以太坊中发布和调用智能合约就是在evm上运行的。实际上，虚拟机直接运行的是虚拟机代码(虚拟机字节码，下简称“字节码”)。部署在区块链上的智能合约可以是字节码的形式。

如图1所示，bob将一个包含创建智能合约信息的交易(transaction)发送到以太坊网络后，节点1的evm可以执行这个交易并生成对应的合约实例。图中1中的“0x68e12cf284…”代表了这个合约的地址，交易的data字段保存的可以是字节码，交易的to字段为一个空的账户。节点间通过共识机制达成一致后，这个合约成功创建，后续用户可以调用这个合约。

合约创建后，区块链上出现一个与该智能合约对应的合约账户，并拥有一个特定的地址，合约代码和账户存储将保存在该合约账户中。智能合约的行为由合约代码控制，而智能合约的账户存储(storage)则保存了合约的状态。换句话说，智能合约使得区块链上产生包含合约代码和账户存储的虚拟账户。

前述提到，包含创建智能合约的交易的data字段保存的可以是该智能合约的字节码。字节码由一连串的字节组成，每一字节可以标识一个操作。基于开发效率、可读性等多方面考虑，开发者可以不直接书写字节码，而是选择一门高级语言编写智能合约代码。例如，采用诸如solidity、serpent、lll语言等高级语言。对于采用高级语言编写的智能合约代码，可以经过编译器编译，生成可以部署到区块链上的字节码。

以solidity语言为例，用其编写的合约与面向对象编程语言中的类(class)很相似，在一个合约中可以声明多种成员，包括状态变量、函数、函数修改器、事件等。状态变量是永久存储在智能合约的账户存储中的值，用于保存合约的状态。

一般的，当一个智能合约部署在区块链后，智能合约的合约代码中的状态变量对应的存储状态是明文，任何人都可以看到其状态，无隐私保护的设置和能力。

如图2所示，仍以以太坊为例，bob将一个包含调用智能合约信息的交易发送到以太坊网络后，节点1的evm可以执行这个交易并生成对应的合约实例。图中2中交易的from字段是发起调用智能合约的账户的地址，to字段中的“0x692a70d2…”代表了被调用的智能合约的地址，value字段在以太坊中是以太币的值，交易的data字段保存的调用智能合约的方法和参数。调用智能合约后，balance的值可能改变。后续，某个客户端可以通过某一区块链节点(例如图2中的节点6)查看balance的当前值。

智能合约可以以规定的方式在区块链网络中每个节点独立的执行，所有执行记录和数据都保存在区块链上，所以当这样的交易完成后，区块链上就保存了无法篡改、不会丢失的交易凭证。

创建智能合约和调用智能合约的示意图如图3所示。以太坊中要创建一个智能合约，需要经过编写智能合约、变成字节码、部署到区块链等过程。以太坊中调用智能合约，是发起一笔指向智能合约地址的交易，智能合约代码分布式的运行在以太坊网络中每个节点的虚拟机中。

请参见图4，图4是本申请一示例性实施例提供的切换电子票据的票据状态的示意图。如图4所示，在开票方开具电子票据后，将电子票据发布至区块链上进行存证，此时电子票据处于未报销状态。当票据相关方(比如用票单位)发起对该电子票据进行报销时，该电子票据处于报销锁定状态，以防止其他用票单位对该电子票据进行报销，从而避免出现重复报销的问题。进一步的，当完成付款(将对应于电子票据的金额转账至用票单位的指定账户)时，电子票据处于已报销状态，而当完成入账时，电子票据处于已入账状态。

其中，电子票据还可无需通过报销的流程，进行直接入账处理，进而从未报销状态切换至已入账状态。在电子票据由未报销状态切换至报销锁定状态后，若在预设时长内未监听到报销结果，则区块链节点将电子票据由报销锁定状态更新为未报销状态(即图中的“过期”过程)。类似的，在电子票据由未报销状态切换至报销锁定状态后，若校验得到电子票据不符合票据报销条件，则区块链节点将电子票据由报销锁定状态更新为未报销状态(即图中的“解除报销”过程)。

而除了对处于未报销状态的电子票据进行报销处理之外，还可进行冲红、打印(使用财政空白票打印)、作废等处理，进而电子票据分别切换为已开红票状态、已打印状态、已作废状态。其中，未报销状态、报销锁定状态、已报销状态、已入账状态为电子票据的有效状态；已开红票状态、已打印状态、已作废状态为电子票据的失效状态，对于处于失效状态的电子票据，无法对其执行操作。

基于上述电子票据切换票据状态的机制，本说明书提供一种基于区块链的状态机维护方法。请参见图5，图5是一示例性实施例提供的一种基于区块链的状态机维护方法的流程图。如图5所示，该维护方法应用于区块链节点，该区块链节点维护了与区块链上存证的电子票据对应的状态机，该状态机包括电子票据的生命周期中的若干种票据状态，以及，触发将电子票据切换至该若干种票据状态的操作数据；其中，该维护方法可以包括以下步骤：

步骤502，接收针对目标电子票据的操作交易。

在本实施例中，票据相关方可对在区块链上存证的电子票据执行操作处理。其中，操作处理包括报销、作废、冲红、打印等。例如，电子票据的交款方可对该电子票据进行报销处理，开票方可对该电子票据进行冲红、作废、打印等。

在一种情况下，可由票据相关方在线下对电子票据执行操作处理，再将处理生成的操作数据(可理解为操作结果)发布至区块链进行存证。在该情况下，操作交易为包含针对目标电子票据执行操作处理的操作数据的存证交易，与操作交易相关的针对目标电子票据的操作数据，为操作交易中包含的操作数据；那么区块链节点在接收到针对目标电子票据的操作交易后，可响应于该操作交易，将经过共识的操作交易发布至区块链进行存证。

在另一种情况下，可通过在区块链上部署智能合约来对电子票据执行操作处理，以区块链为联盟链为例进行说明。联盟链的成员可在联盟链上部署用于对电子票据执行操作处理的智能合约，以及在智能合约中声明票据处理逻辑。在完成对智能合约的开发后，联盟链的成员可以通过联盟链中的任一节点设备将该智能合约发布至联盟链，并在该智能合约由该联盟链中的部分指定的成员节点设备(比如，联盟链中指定的若干个具有记账权限的权威节点设备)完成共识后，收录至该联盟链的分布式数据库(即分布式账本)。后续，用户可以通过接入任一节点设备的客户端，向联盟链中收录的该智能合约提交交易(transaction)，来发起对该智能合约的合约调用，触发在联盟链上来触发执行相关的业务逻辑。

基于上述对智能合约的部署，操作交易为调用智能合约的交易(包含所调用智能合约的地址)，与操作交易相关的针对目标电子票据的操作数据，为调用智能合约针对目标电子票据执行操作处理生成的操作数据(可理解为操作结果)；那么区块链节点在接收到针对目标电子票据的操作交易后，调用发布在区块链上的智能合约中声明的票据处理逻辑，对目标电子票据执行操作处理，并将对目标电子票据执行操作处理而生成的操作数据发布至区块链上进行存证。

需要说明的是，接入区块链的用户在区块链上发起的请求的类型，具体可以是指传统的区块链中所采用的交易(transaction)。当然，接入区块链的用户在区块链上发起的请求的类型，具体也可以是交易以外的，其它形式的具有标准的数据结构的指令、消息等，本说明书一个或多个实施例并不进行特别限定。在以下的各实施例中，将以接入区块链的用户在区块链上发起的请求为交易为例进行说明。

步骤504，响应于所述操作交易，将经过共识的与所述操作交易相关的针对所述目标电子票据的操作数据发布至所述区块链进行存证。

在本实施例中，接入区块链的用户客户端，可以将数据打包成区块链所支持的标准的交易格式，然后发布至区块链；而区块链中的节点设备(即区块链节点)，可以基于搭载的共识算法与其它节点设备一起，对用户客户端发布至区块链的这些交易进行共识，以此来为区块链产生最新区块。

步骤506，当监听到所述区块链上存证了针对所述目标电子票据的操作数据时，确定监听到的操作数据是否与所述状态机中的操作数据相匹配。

步骤508，如果是，根据监听到的操作数据对所述状态机的票据状态进行切换。

在本实施例中，如果状态机的票据状态发生切换，将切换后的电子票据的票据状态，推送至与该状态机对应的票据状态订阅方。

在本实施例中，基于上述过程中对状态机的维护过程，票据状态查询方可通过客户端向区块链节点发送针对目标电子票据的票据状态的查询请求，以获取目标电子票据当前所处的状态。那么区块链节点可获取所维护的状态机当前所处的票据状态，并将获取到的票据状态返回给票据状态查询方。其中，区块链节点在接收到该查询请求后，可先校验票据状态查询方是否具备获取目标电子票据的票据状态的权限。例如，可先校验票据状态查询方是否属于目标电子票据的票据相关方(开票方、监管方、用票方等)；如果是，再获取并返回票据状态。当然，校验的具体方式可根据实际情况灵活设定，本说明书一个或多个实施例并不对此进行限制。

在本实施例中，基于上述步骤中对状态机的维护过程，当操作处理为报销操作时，还可进一步结合状态机记录的电子票据当前所处的票据状态，设定报销锁定机制以防止多个报销发起方对目标电子票据进行重复报销。

报销发起方在对目标电子票据进行报销之前，可向区块链节点发送针对目标电子票据的报销确认请求，以确认目标电子票据是否允许被报销。那么，区块链在接收到该报销确认请求后，根据上述维护的状态机确定目标电子票据当前所处的票据状态。当确定出的票据状态为未报销状态时(说明在此之前不存在其他票据相关方发起对目标电子票据进行报销)，将状态机的票据状态切换为报销锁定状态，并指示该票据相关方对目标电子票据执行报销操作。当确定出的票据状态为报销锁定状态时(说明在此之前已经存在其他票据相关方发起对目标电子票据进行报销)，指示该票据相关方目标电子票据处于报销锁定状态，即禁止对目标电子票据进行报销(若该票据相关方对目标电子票据执行报销操作，则将导致重复报销的问题)。

在本实施例中，状态机可以包括电子票据的生命周期中的未报销状态、报销锁定状态、已报销状态、已入账状态、已开红票状态、已打印状态、已作废状态等票据状态。

其中，触发将状态机的票据状态由未报销状态切换至报销锁定状态的操作数据为，针对目标电子票据的报销交易中携带的目标电子票据的标识信息；触发将状态机的票据状态由报销锁定状态切换至已报销状态的操作数据为，针对目标电子票据的报销结果；触发将状态机的票据状态由已报销状态切换至已入账状态的操作数据为，针对目标电子票据的入账结果；触发将状态机的票据状态由未报销状态切换至已开红票状态的操作数据为，针对目标电子票据的冲红结果；触发将状态机的票据状态由未报销状态切换至已打印状态的操作数据为，针对目标电子票据的打印结果；触发将状态机的票据状态由未报销状态切换至已作废状态的操作数据为，针对目标电子票据的作废结果。

举例而言，报销发起方在对目标电子票据进行报销之前，可向区块链节点发送针对目标电子票据的报销确认请求(包含目标电子票据的标识信息)，以使得区块链节点通过状态机的票据状态确认目标电子票据是否允许被报销(处于未报销状态时允许进行报销处理)。那么，在该情况下，操作数据为报销确认请求中包含的标识信息，当区块链节点接收到针对目标电子票据的报销确认请求时，若对应于目标电子票据的状态机当前处于未报销状态，则将该状态机切换至报销锁定状态。类似的，当在区块链上发布智能合约用于对目标电子票据进行报销时，报销发起方可通过向区块链节点发送报销交易(携带目标电子票据的标识信息)来调用智能合约对目标电子票据进行报销处理。在该情况下，操作数据为目标电子票据的报销交易中携带的目标电子票据的标识信息，当区块链节点接收到针对目标电子票据的报销交易时，若对应于目标电子票据的状态机当前处于未报销状态，则将该状态机切换至报销锁定状态。

操作数据还可以是对目标电子票据执行操作处理后生成的执行结果凭证。例如，当操作处理为报销时，根据对电子票据进行报销处理后得到的报销单据(被发布至区块链上进行存证)，可确定出该电子票据已被报销，若对应于该电子票据的状态机当前处于报销锁定状态，则将该状态机切换至已报销状态。当操作处理为冲红时，根据对电子票据进行冲红处理后得到的冲红票据(被发布至区块链上进行存证)，可确定出该电子票据已被冲红，若对应于该电子票据的状态机当前处于未报销状态，则将该进而将对应于该电子票据的状态机切换至已冲红状态。其中，操作处理为其他操作类型的情况与上述举例类似，在此不再赘述。

在本说明书的技术方案中，基于上述实施例中对状态机的维护，可进一步提供一种基于区块链的票据状态推送方案，请参见图6，图6是一示例性实施例提供的一种基于区块链的票据状态推送方法的流程图。如图6所示，该推送方法应用于区块链节点，该区块链节点维护了与区块链上存证的电子票据对应的状态机；该状态机包括电子票据的生命周期中的若干种票据状态；以及，触发将电子票据切换至若干种票据状态的操作数据；其中，该推送方法可以包括以下步骤：

步骤602，接收针对目标电子票据的操作交易。

步骤604，响应于所述操作交易，将经过共识的与所述操作交易相关的针对所述目标电子票据的操作数据发布至所述区块链进行存证。

步骤606，当监听到所述区块链上存证了针对所述目标电子票据的操作数据时，确定监听到的操作数据是否与所述状态机中的操作数据相匹配；如果是，根据监听到的操作数据对所述状态机的票据状态进行切换。

需要说明的是，上述步骤602-606的具体过程可参考上述图5所示实施例中的步骤502-506，在此不再赘述。

步骤608，根据所述状态机向对应于所述目标电子票据的票据状态订阅方推送包含所述目标电子票据当前所处票据状态的通知消息。

在本实施例中，当票据相关方订阅了电子票据的状态更新情况时，若对应于该电子票据的状态机发生切换，则主动向票据相关方推送相应的通知消息，以告知票据相关方所订阅票据的最新状态。

票据相关方可通过与区块链节点对接的客户端向区块链节点发送状态订阅请求，以实现对电子票据的状态订阅。以上述目标电子票据为例，区块链节点在接收到针对目标电子票据的状态订阅请求后，可确定该状态订阅请求的发送方是否属于目标电子票据的票据相关方；如果是，将该发送方作为目标电子票据的票据状态订阅方。当然，校验是否可订阅目标电子票据的具体方式可根据实际情况灵活设定，例如，还可限定为仅允许目标电子票据的交款方订阅，本说明书一个或多个实施例并不对此进行限制。

由以上技术方案可见，由区块链节点来维护电子票据在整个生命周期中所处的各个票据状态，那么搭建区块链的各个参与方可通过共识在区块链上共同维系电子票据的票据状态，以及通过区块链来了解电子票据当前所处的状态，从而判断是否可对电子票据执行特定的操作。例如，报销单位在对电子票据进行报销之前，可通过区块链维护的状态机来查询该电子票据是否已被报销、作废、冲红等，从而提高报销电子票据的效率，避免出现重复报销、报销出错等问题。

进一步的，基于票据相关方针对电子票据的订阅机制，当状态机的票据状态发生切换时，主动向票据状态订阅方推送通知消息，以告知票据状态订阅方所订阅票据的最新状态变化情况。例如，电子票据的开票、用票、交款人均可通过区块链订阅该电子票据的票据状态；当其中某一方对电子票据执行特定的操作时，订阅方可以通过区块链及时获得状态变化信息。比如，交款人的电子票据被同名人窃取报销，那么交款人可通过上述订阅机制及时获得票据已被报销的通知消息，从而及时挽回损失。

图7是一示例性实施例提供的一种基于区块链的状态机维护方案的整体架构示意图。如图7所示，服务器72上运行有区块链的客户端，使得该服务器72被配置为一区块链节点。票据相关方70可以预先通过客户端71在服务器72处进行账号注册，得到与自身唯一对应的已注册账号。然后，票据相关方70可以通过在客户端71上登录该已注册账号，而服务器72基于该已注册账号在客户端71上的登录信息，确定该已注册账号(对应于该用户)与客户端71之间建立了绑定关系，所需建立的绑定关系为票据相关方70的用户信息与客户端,71的设备信息之间的绑定关系。基于该绑定关系，服务器72在接收到客户端71后续发送的交易时，可确认该交易对应于票据相关方70。

票据相关方70可通过客户端71输入在线下对目标电子票据执行操作处理后得到的操作结果，以由客户端71打包一笔用于存证该操作结果的交易，并将打包好的交易发送至服务器72。服务器72(作为区块链节点)在接收到该交易后，将操作结果发布至区块链上进行存证，并根据操作结果切换状态机的票据状态。

当存在针对目标电子票据的状态订阅方时，服务器72在切换状态机的票据状态后，可主动向状态订阅方推送包含目标电子票据当前所处票据状态的通知消息。例如，假定状态订阅方为目标电子票据的开票方、用票方和交款方，则服务器72主动分别向开票方、用票方和交款方推送包含目标电子票据当前所处票据状态的通知消息。

图8是一示例性实施例提供的另一种基于区块链的状态机维护方案的整体架构示意图。如图8所示，服务器82上运行有区块链的客户端，使得服务器82被配置为一区块链节点，且服务器82上部署有用于对目标电子票据执行操作处理的智能合约。票据相关方80可以预先通过客户端81在服务器82处进行账号注册，得到与自身唯一对应的已注册账号。然后，票据相关方80可以通过在客户端81上登录该已注册账号，而服务器82基于该已注册账号在客户端81上的登录信息，确定该已注册账号(对应于该用户)与客户端81之间建立了绑定关系，所需建立的绑定关系为票据相关方80的用户信息与客户端81的设备信息之间的绑定关系。基于该绑定关系，服务器82在接收到客户端81后续发送的交易时，可确认该交易对应于票据相关方80。

票据相关方80可通过客户端81输入目标电子票据的信息(例如，目标电子票据的id)，以由客户端81打包一笔用于调用智能合约对目标电子票据执行操作处理的交易，并将打包好的交易发送至服务器82。服务器82(作为区块链节点)在接收到该交易后，调用智能合约对目标电子票据执行操作处理，并将操作结果发布至区块链上进行存证。

服务器82监听区块链上存证的操作结果，当监听到对应于目标电子票据的操作结果时，根据监听到的操作结果切换状态机的票据状态。类似的，当存在针对目标电子票据的状态订阅方时，服务器82在切换状态机的票据状态后，可主动向状态订阅方推送包含目标电子票据当前所处票据状态的通知消息。

为了便于理解，下面针对客户端和服务器(作为区块链节点)分别在票据状态推送过程中实现的操作和功能，结合图9-13对本说明书的技术方案进行详细说明。

请参见图9，图9是一示例性实施例提供的一种订阅票据状态的交互图。如图9所示，该交互过程可以包括以下步骤：

步骤902，订阅方客户端构建针对目标电子票据的状态订阅请求。

在本实施例中，用户可通过客户端(与区块链节点对接)向区块链节点发送状态订阅请求(包含目标电子票据的id)，来实现对目标电子票据票据状态的更新通知订阅，从而可了解目标电子票据在整个生命周期中票据状态的变化过程。

电子票据的开票方、用票方、交款方均可通过区块链来订阅票据状态。当其中某一方对电子票据执行特定的操作时，订阅方可以通过区块链及时获得状态变化信息。比如，交款方的电子票据被同名人窃取报销，那么交款方可通过上述订阅机制及时获得票据已被报销的通知消息，从而及时挽回损失。比如，属于医疗方面的电子票据，涉及异地报销、多级报销等因素，容易出现冒名顶替报销、重复报销等问题。例如，张三的电子票据被同名人窃取报销，那么张三可以通过本说明书的订阅方案及时获得票据已被报销的通知消息，进而及时挽回损失。

步骤904，订阅方客户端向区块链节点发送状态订阅请求。

步骤906，区块链节点确定发送方是否属于目标电子票据的票据相关方。

在本实施例中，以是否为票据相关方(开票方、用票方、监管方、交款方等等)来校验是否具备订阅票据状态通知的权限。当票据相关方订阅了电子票据的状态更新情况时，若对应于该电子票据的状态机发生切换，则主动向票据相关方推送相应的通知消息，以告知票据相关方所订阅票据的最新状态。

当然，校验是否可订阅目标电子票据的具体方式可根据实际情况灵活设定，例如，还可限定为仅允许目标电子票据的交款方订阅，本说明书一个或多个实施例并不对此进行限制。

步骤908，区块链节点将状态订阅请求的发送方作为票据状态订阅方。

步骤910，区块链节点向订阅方客户端返回订阅成功的通知消息。

请参见图10，图10是一示例性实施例提供的一种票据状态推送方法的交互图。如图10所示，该交互过程可以包括以下步骤：

步骤1002，票据相关方对目标电子票据执行操作处理。

在本实施例中，由票据相关方在线下对电子票据执行操作处理；比如，报销、冲红、作废、打印等。

步骤1004，票据相关方打包一笔用于存证对目标电子票据执行操作处理后得到的操作结果的交易。

步骤1006，票据相关方向区块链节点发送打包得到的交易。

步骤1008，区块链节点对接收到的交易进行共识处理。

在本实施例中，票据相关方使用的接入区块链的用户客户端，可以将操作结果打包成区块链所支持的标准的交易格式，然后发布至区块链；而区块链中的节点设备，可以基于搭载的共识算法与其它节点设备一起，对用户客户端发布至区块链的这些交易进行共识，以此来为区块链产生最新区块；

其中，区块链中支持的共识算法，通常分为节点设备需要争夺每一轮的记账周期的记账权的共识算法，和预先为每一轮记账周期选举记账节点(不需要争夺记账权)的共识算法。

例如，前者以工作量证明(proofofwork,pow)、股权证明(proofofstake，pos)、委任权益证明(delegatedproofofstake，dpos)等共识算法为代表；后者以实用拜占庭容错(practicalbyzantinefaulttolerance，pbft)等共识算法为代表。

对于采用工作量证明(proofofwork,pow)以及股权证明(proofofstake，pos)、委任权益证明(delegatedproofofstake，dpos)等共识算法的区块链网络中，争夺记账权的节点设备，都可以在接收到交易后执行该笔交易。争夺记账权的节点设备中可能其中一个在本轮争夺记账权的过程中胜出，成为记账节点。记账节点可以收到的交易与其它交易一起打包并生成最新区块，并将生成的最新区块发送至其它节点设备进行共识。

对于采用实用拜占庭容错(practicalbyzantinefaulttolerance，pbft)等共识算法的区块链网络中，具有记账权的节点设备在本轮记账前已经商定好。因此，节点设备在接收到交易后，如果自身不是本轮的记账节点，则可以将该交易发送至记账节点。

对于本轮的记账节点，在将该交易与其它交易一起打包并生成最新区块的过程中或者之前，可以执行该交易。记账节点在将该交易与其它交易一起打包生成新区块后，可以将生成的最新区块或者该最新区块的区块头发送至其它节点设备进行共识。

如上所述，无论区块链采用以上示出的哪种共识算法，本轮的记账节点都可以将接收到的交易打包并生成最新区块，并将生成的最新区块或者该最新区块的区块头发送至其它节点设备进行共识验证。如果其它节点设备接收到最新区块或者该最新区块的区块头后，经验证没有问题，可以将该最新区块追加到原有的区块链末尾，从而完成区块链的记账过程。

步骤1010，区块链节点将操作结果发布至区块链上进行存证。

步骤1012，当区块链节点(比如服务器72)监听到该操作结果时，对状态机的票据状态进行切换。

举例而言，当票据相关方对目标电子票据进行报销处理时，根据对电子票据进行报销处理后得到的报销单据(被发布至区块链上进行存证)，可确定出该电子票据已被报销，进而将对应于该电子票据的状态机切换至已报销状态。当操作处理为冲红时，根据对电子票据进行冲红处理后得到的冲红票据(被发布至区块链上进行存证)，可确定出该电子票据已被冲红，进而将对应于该电子票据的状态机切换至已冲红状态。其中，操作处理为其他操作类型的情况与上述举例类似，在此不再赘述。

步骤1014，区块链节点向订阅方客户端推送最新的票据状态。

步骤1016，订阅方客户端展示接收到的票据状态。

请参见图11，图11是一示例性实施例提供的另一种票据状态推送方法的交互图。如图11所示，该交互过程可以包括以下步骤：

步骤1102，票据相关方打包一笔用于调用智能合约对目标电子票据执行操作处理的交易。

在本实施例中，由在区块链上部署的智能合约来对电子票据执行报销、冲红、作废、打印等操作处理。

步骤1104，票据相关方向区块链节点发送打包得到的交易。

步骤1106，区块链节点对接收到的交易进行共识处理。

步骤1108，在共识通过后，区块链节点调用发布在区块链上的智能合约中声明的票据处理逻辑，对目标电子票据执行操作处理。

以联盟链为例，联盟链的成员可在联盟链上部署用于对电子票据执行操作处理的智能合约，以及在智能合约中声明票据处理逻辑。在完成对智能合约的开发后，联盟链的成员可以通过联盟链中的任一节点设备将该智能合约发布至联盟链，并在该智能合约由该联盟链中的部分指定的成员节点设备(比如，联盟链中指定的若干个具有记账权限的权威节点设备)完成共识后，收录至该联盟链的分布式数据库(即分布式账本)。后续，用户可以通过接入任一节点设备的客户端，向联盟链中收录的该智能合约提交交易(transaction)，来发起对该智能合约的合约调用，触发在联盟链上来触发执行相关的业务逻辑。

举例而言，上述联盟链具体可以是一个联盟成员包括开票单位、财政监管单位和用票单位的联盟链。在该情况下，开票单位可在联盟链上部署声明有用于对电子票据进行作废、冲红、打印等业务逻辑的智能合约；用票单位可在联盟链上部署声明有用于对电子票据进行报销的业务逻辑的智能合约。其中，可在同一智能合约中声明多个业务逻辑(即智能合约与业务逻辑为“一对多”的关系)，也可在每个智能合约中声明不同的业务逻辑(即智能合约与业务逻辑为“一一对应”的关系)，本说明书一个或多个实施例并不对此进行限制。

步骤1110，区块链节点对操作结果进行共识处理。

本实施例中的共识过程可参考上述图10所示实施例中的共识过程，在此不再赘述。

步骤1112，在共识通过后，区块链节点将操作结果发布至区块链上进行存证。

步骤1114，当区块链节点(比如服务器82)监听到该操作结果时，对状态机的票据状态进行切换。

步骤1116，区块链节点向订阅方客户端推送最新的票据状态。

步骤1118，订阅方客户端展示接收到的票据状态。

基于对状态机的维护，除了订阅票据状态之外，票据相关方还可通过客户端主动向区块链节点发送针对目标电子票据的票据状态的查询请求，以获取目标电子票据当前所处的状态。

请参见图12，图12是一示例性实施例提供的一种获取票据状态的交互图。如图12所示，该交互过程可以包括以下步骤：

步骤1202，票据状态查询方构建针对目标电子票据的票据状态的查询请求。

例如，查询请求中可包含目标电子票据的id。

步骤1204，票据状态查询方向区块链节点发送查询请求。

步骤1206，区块链节点确定发送方是否属于目标电子票据的票据相关方。

在本实施例中，可设定为只有票据相关方才具备获取票据状态的权限。当然，权限的设定方式可根据实际情况灵活设定，本说明书一个或多个实施例并不对此进行限制。例如，还可设定为只有票据相关方中的监管方(比如，财政监管单位)才具备获取票据状态的权限。其中，确定是否具备获取票据状态的权限的操作，可由智能合约来执行。例如，在区块链上部署智能合约，该智能合约中声明了校验发送方是否在预设权限列表(该列表中用于记录具备获取票据状态的权限的成员)中的业务逻辑。

步骤1208，若票据状态查询方属于目标电子票据的票据相关方，则获取状态机的票据状态。

步骤1210，区块链节点向票据状态查询方返回获取到的票据状态。

在本说明书的技术方案中，基于上述对状态机的维护过程，当操作处理为报销操作时，还可进一步结合状态机记录的电子票据当前所处的票据状态，设定报销锁定机制以防止多个票据相关方对目标电子票据进行重复报销。

请参见图13，图13是一示例性实施例提供的一种报销校验的交互图。如图13所示，该交互过程可以包括以下步骤：

步骤1302，票据报销方打包一笔针对目标电子票据的报销确认交易。

在本实施例中，票据报销方在对目标电子票据进行报销之前，可向区块链节点发送针对目标电子票据的报销确认交易，以确认目标电子票据是否允许被报销(也即确认目标电子票据是否被锁定)。

步骤1304，票据报销方向区块链节点发送报销确认交易。

步骤1306，区块链节点调用智能合约确定目标电子票据是否符合票据报销条件。

在本实施例中，可预先定义票据报销条件用于校验电子票据是否符合报销的规定。例如，票据报销条件可按照报销权限、报销额度、报销期限等维度来定义。比如，可设定为只有电子票据的交款方才具备报销权限，报销额度为10万元以下，报销期限设定为距离对应于电子票据的交易发生时刻的时长在180天以内。

那么，可在区块链上部署智能合约，该智能合约中声明有用于校验电子票据是否符合票据报销条件的报销校验逻辑。其中，该部署过程与上述智能合约的部署过程类似，在此不再赘述。

步骤1308，区块链节点在确定目标电子票据符合票据报销条件后，根据状态机确定目标电子票据当前所处的票据状态。

步骤1310，当确定出的票据状态为未报销状态时，区块链节点将状态机的票据状态切换为报销锁定状态。

步骤1312，区块链节点生成针对目标电子票据的允许报销事件。

步骤1314，票据报销方监听到该允许报销事件。

在本实施例中，当票据报销方监听到该允许报销事件时，可确认目标电子票据允许被报销，进而实施后续报销的操作。其中，可通过上述图10或图11中示出的方法对目标电子票据进行报销处理。

当确定出的票据状态为报销锁定状态时(说明在此之前已经存在其他票据报销方发起对目标电子票据进行报销)，可生成针对目标电子票据的禁止报销事件，以指示该票据报销方目标电子票据处于报销锁定状态，即禁止对目标电子票据进行报销(若该票据报销方对目标电子票据执行报销操作，则将导致重复报销的问题)。那么，当票据报销方监听到该禁止报销事件时，可确认目标电子票据禁止被报销。

在本实施例中，还可在确认出目标电子票据允许被报销之后，再执行上述校验目标电子票据是否符合票据报销条件的步骤；也即，步骤1308-1310与步骤1306的顺序互换。在该情况下，当校验得出目标电子票据不符合票据报销条件时，进一步将状态机的票据状态从报销锁定状态切换为未报销状态。

传统的电子票据的开具、作废、打印(使用财政空白票打印)和报销入账等各环节是割裂的。比如，患者在保险公司进行报销时，保险公司无法确认该电子票据是否已被作废或者冲红；类似的，当患者在医院进行退付时，医院也无法确认患者是否在医保或者保险公司等用票单位进行了报销。而本说明书中的实施例基于区块链分布式记账的特点，由各个票据相关方来共同维系电子票据的票据状态，通过维护状态机来使得票据相关方获取目标电子票据的最新状态，以及通过上述报销锁定机制和报销校验过程来杜绝重复报销、作废报销、报销作废等套取资金的行为。

由以上技术方案可见，由区块链节点来维护电子票据在整个生命周期中所处的各个票据状态，那么搭建区块链的各个参与方可通过共识在区块链上共同维系电子票据的票据状态，以及通过区块链来了解电子票据当前所处的状态，从而判断是否可对电子票据执行特定的操作。例如，报销单位在对电子票据进行报销之前，可通过区块链维护的状态机来查询该电子票据是否已被报销、作废、冲红等，从而提高报销电子票据的效率，避免出现重复报销、报销出错等问题。

进一步的，基于票据相关方针对电子票据的订阅机制，当状态机的票据状态发生切换时，主动向票据状态订阅方推送通知消息，以告知票据状态订阅方所订阅票据的最新状态变化情况。例如，电子票据的开票方、用票方、交款方均可通过区块链订阅该电子票据的票据状态；当其中某一方对电子票据执行特定的操作时，订阅方可以通过区块链及时获得状态变化信息。比如，交款方的电子票据被同名人窃取报销，那么交款方可通过上述订阅机制及时获得票据已被报销的通知消息，从而及时挽回损失。

图14是一示例性实施例提供的一种设备的示意结构图。请参考图14，在硬件层面，该设备包括处理器1402、内部总线1404、网络接口1406、内存1408以及非易失性存储器1410，当然还可能包括其他业务所需要的硬件。处理器1402从非易失性存储器1410中读取对应的计算机程序到内存1408中然后运行，在逻辑层面上形成基于区块链的状态机维护装置。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图15，在软件实施方式中，该基于区块链的状态机维护装置应用于区块链节点，所述区块链节点维护了与所述区块链上存证的电子票据对应的状态机；所述状态机包括所述电子票据的生命周期中的若干种票据状态；以及，触发将所述电子票据切换至所述若干种票据状态的操作数据；所述装置可以包括：

第一接收单元1501，接收针对目标电子票据的操作交易；

存证单元1502，响应于所述操作交易，将经过共识的与所述操作交易相关的针对所述目标电子票据的操作数据发布至所述区块链进行存证；

切换单元1503，当监听到所述区块链上存证了针对所述目标电子票据的操作数据时，确定监听到的操作数据是否与所述状态机中的操作数据相匹配；

如果是，根据监听到的操作数据对所述状态机的票据状态进行切换。

可选的，所述操作交易为包含针对所述目标电子票据执行操作处理的操作数据的存证交易；与所述操作交易相关的针对所述目标电子票据的操作数据，为所述操作交易中包含的所述操作数据；

所述存证单元1502具体用于：

响应于所述操作交易，将经过共识的所述操作交易发布至所述区块链进行存证。

可选的，所述操作交易为调用智能合约的交易；与所述操作交易相关的针对所述目标电子票据的操作数据，为调用所述智能合约针对所述目标电子票据执行操作处理生成的操作数据；

所述存证单元1502具体用于：

调用发布在所述区块链上的智能合约中声明的票据处理逻辑，对所述目标电子票据执行操作处理；

将对所述目标电子票据执行操作处理而生成的操作数据发布至所述区块链上进行存证。

可选的，还包括：

第二接收单元1504，接收票据状态查询方发送的针对所述目标电子票据的票据状态的查询请求；

返回单元1505，获取所述状态机当前所处的票据状态，并将获取到的票据状态返回给所述据状态查询方。

可选的，还包括：

推送单元1506，如果所述状态机的票据状态发生切换，将切换后的所述电子票据的票据状态，推送至与所述状态机对应的票据状态订阅方。

可选的，所述状态机包括电子票据的生命周期中的未报销状态、报销锁定状态、已报销状态、已入账状态、已开红票状态、已打印状态、已作废状态；

触发将所述状态机的票据状态由未报销状态切换至报销锁定状态的操作数据为，针对目标电子票据的报销交易中携带的所述目标电子票据的标识信息；

触发将所述状态机的票据状态由报销锁定状态切换至已报销状态的操作数据为，针对目标电子票据的报销结果；

触发将所述状态机的票据状态由已报销状态切换至已入账状态的操作数据为，针对目标电子票据的入账结果；

触发将所述状态机的票据状态由未报销状态切换至已开红票状态的操作数据为，针对目标电子票据的冲红结果；

触发将所述状态机的票据状态由未报销状态切换至已打印状态的操作数据为，针对目标电子票据的打印结果；

触发将所述状态机的票据状态由未报销状态切换至已作废状态的操作数据为，针对目标电子票据的作废结果。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

在一个典型的配置中，计算机包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。