客户端、服务端、方法和身份验证系统与流程

本公开涉及信息安全领域，更具体地，涉及一种用于生成验证码的客户端和方法、用于验证用户身份的服务端和方法以及身份验证系统。

背景技术：

访问控制是所有计算机系统都需要涉及的机制，无论是客户端/服务器系统、客户端/浏览器系统，还是云系统，从最简单的用户名/密码，到广泛使用的认证码/验证码(captcha)，以及现在广泛使用的短信验证码和基于硬件的ukey(usbkey)等，其中，短信验证码和ukey都需要外部设备的支持。

多因素认证(multi-factorauthentication,mfa)是一种简单有效的账号安全最佳实践方法，它能够在用户名和密码之外再增加一层或多层安全保护。从密码学理论上说，用于身份认证主要有三方面要素:一是需要用户记忆的身份认证内容，例如密码或身份证号码等；二是用户拥有认证硬件，例如ukey、智能卡(以下简称ic卡)、磁卡等；三是用户本身拥有的唯一特征，例如指纹、瞳孔、声音等。单独来看，每个要素独立存在时，都有其脆弱性，而把多种要素结合起来，实现多重要素认证，可以有效提高系统访问控制的安全性，就是多因素认证。

验证码是目前广泛应用于多因素认证的一种方式。目前广泛使用的验证方式有两种，一种是服务端和客户端同步生成验证信息；另一种是服务端生成验证码，传递到用户设备。

对于第一种方式，例如，通过ukey产生随机电子令牌(token)，这种方式一般是服务端和ukey拥有同步的随机数发生器，周期性地产生随机变化的电子令牌。然而，这种方式需要为所有用户配发ukey，并且后台也要维护一个针对所有用户的庞大随机数同步系统，因而成本较高。对于第二种方式，例如，手机验证码方式，则是服务端生成验证码，发送给手机用户，用户再按提示输入该验证码。但是，随着智能手机的普及，手机系统的漏洞也在增长，各类木马的存在，导致手机验证码的安全性出现 问题。无论哪种验证方式，要么服务端和客户端同步获得验证码，要么服务端生成验证码后再发送给用户，而用户自身并不是先于服务端主动生成验证码，然后由服务端在特定条件下进行验证，也就是说，用户无法主动掌控验证信息。

技术实现要素：

在下文中给出了关于本公开的简要概述，以便提供关于本公开的某些方面的基本理解。但是，应当理解，这个概述并不是关于本公开的穷举性概述。它并不是意图用来确定本公开的关键性部分或重要部分，也不是意图用来限定本公开的范围。其目的仅仅是以简化的形式给出关于本公开的某些概念，以此作为稍后给出的更详细描述的前序。

鉴于以上问题，本公开的目的是提供一种用于生成验证码的客户端和方法、用于验证用户身份的服务端和方法以及用于身份验证系统，其通过借助于公共数据平台，由用户端主导验证码的生成来提高验证安全性。

根据本公开的一方面，提供了一种用于生成验证码的客户端，该客户端包括：事务发起单元，被配置成响应于关于用户的预定身份验证事件而发起数据平台系统内的第一账户与第二账户之间的随机事务(transaction)，以使得该随机事务记录在数据平台系统内；验证码生成单元，被配置成至少基于关于随机事务的信息，生成用于用户的身份验证的验证码；以及发送单元，被配置成将所生成的验证码发送给服务端，以由服务端根据数据平台系统内的随机事务的记录和验证码对用户的身份进行验证，其中，数据平台系统是去中心化的分布式数据库，并且其中的记录是不可更改和删除的。

根据本公开的优选实施例，数据平台系统是基于区块链(blockchain)的数据平台。

根据本公开的另一优选实施例，随机事务包括以下中的至少一个：转账、合约生成和资产转移。

根据本公开的另一优选实施例，验证码生成单元还基于数据平台系统内的历史事务记录来生成验证码。

根据本公开的另一优选实施例，第一账户和第二账户属于同一所有者或者属于不同所有者。

根据本公开的另一优选实施例，第一账户和第二账户是实时创建的或者是预先设置的。

根据本公开的另一优选实施例，验证码生成单元进一步被配置成利用预定生成算法来生成验证码，预定生成算法包括以下中的至少一个：哈希hash算法、消息认证码mac算法、哈希消息认证码hmac算法、基于分组密码的消息认证码cbc-mac算法、随机数生成算法、公钥加密算法和对称密钥加密算法。

根据本公开的另一优选实施例，该客户端还包括：签名单元，被配置成利用客户端私钥对验证码进行签名，其中，发送单元将签名后的验证码发送给服务端。

根据本公开的另一方面，还提供了一种用于验证用户身份的服务端，该服务端包括：接收单元，被配置成接收客户端生成的用于用户的身份验证的验证码，其中，验证码是客户端至少基于关于数据平台系统内的第一账户与第二账户之间的随机事务的信息而生成的，该随机事务是客户端响应于关于用户的预定身份验证事件而发起的；检索单元，被配置成在数据平台系统内检索随机事务的记录；以及验证单元，被配置成根据随机事务的记录，验证验证码的有效性，以验证用户的身份，其中，数据平台系统是去中心化的分布式数据库，并且其中的记录是不可更改和删除的。

根据本公开的另一方面，还提供了一种身份验证系统，该系统包括：客户端，被配置成：响应于关于用户的预定身份验证事件而发起数据平台系统内的第一账户与第二账户之间的随机事务，以使得该随机事务记录在数据平台系统内，至少基于关于随机事务的信息，生成用于用户的身份验证的验证码，以及将所生成的验证码发送给服务端；数据平台系统，数据平台系统是去中心化的分布式数据库，并且其中的记录是不可更改和删除的；以及服务端，被配置成：接收验证码，在数据平台系统内检索随机事务的记录，以及根据随机事务的记录，验证验证码的有效性，以验证用户的身份。

根据本公开的另一方面，还提供了一种用于生成验证码的方法，该方法包括：响应于关于用户的预定身份验证事件而发起数据平台系统内的第一账户与第二账户之间的随机事务，以使得该随机事务记录在数据平台系统内；至少基于关于随机事务的信息，生成用于用户的身份验证的验证码；以及将所生成的验证码发送给服务端，以由服务端根据数据平台系统内的随机事务的记录和验证码对用户的身份进行验证，其中，数据平台系统是 去中心化的分布式数据库，并且其中的记录是不可更改和删除的。

根据本公开的另一方面，还提供了一种用于验证用户身份的方法，该方法包括：接收客户端生成的用于用户的身份验证的验证码，其中，验证码是客户端至少基于关于数据平台系统内的第一账户与第二账户之间的随机事务的信息而生成的，该随机事务是客户端响应于关于用户的预定身份验证事件而发起的；在数据平台系统内检索随机事务的记录；以及根据随机事务的记录，验证验证码的有效性，以验证用户的身份，其中，数据平台系统是去中心化的分布式数据库，并且其中的记录是不可更改和删除的。

根据本公开的其他方面，还提供了用于实现上述根据本公开的方法的计算机程序代码和计算机程序产品以及其上记录有该用于实现上述根据本公开的方法的计算机程序代码的计算机可读存储介质。

根据本公开的实施例，通过利用例如基于区块链的数据平台系统，由用户端主导验证码的生成，即，由用户端响应于关于用户的身份验证事件(例如，登录特定应用服务、网络支付交易等)发起随机事务并且至少基于该随机事务来生成验证码，并且由服务端根据数据平台系统的事务记录对验证码的有效性和真实性进行验证，可以大大提高信息安全性。

在下面的说明书部分中给出本公开实施例的其他方面，其中，详细说明用于充分地公开本公开实施例的优选实施例，而不对其施加限定。

附图说明

本公开可以通过参考下文中结合附图所给出的详细描述而得到更好的理解，其中在所有附图中使用了相同或相似的附图标记来表示相同或者相似的部件。所述附图连同下面的详细说明一起包含在本说明书中并形成说明书的一部分，用来进一步举例说明本公开的优选实施例和解释本公开的原理和优点。其中：

图1是示出根据本公开的实施例的身份验证系统的模型的示意图；

图2是示出根据本公开的实施例的用于生成验证码的客户端的功能配置示例的框图；

图3是示出根据本公开的实施例的用于验证用户身份的服务端的功能配置示例的框图；

图4是示出根据本公开的实施例的用于验证用户身份的交互过程的流程图；

图5是示出根据本公开的实施例的身份验证系统在现有比特币区块链系统上的应用示意图；

图6是示出根据本公开的实施例的身份验证系统在现有智能合约区块链系统上的应用示意图；

图7示出根据本公开的实施例的用于生成验证码的方法的过程示例的流程图；

图8出根据本公开的实施例的用于验证用户身份的方法的过程示例的流程图；

图9是示出根据本公开的实施例的技术在应用服务环境中的登录身份认证应用的示例的示意图；

图10是示出根据本发明的验证系统的一种可能的应用界面的示意图；

图11是示出根据本公开的实施例的技术在应用服务环境中的登录身份认证应用的另一示例的示意图；以及

图12出作为本公开的实施例中可采用的信息处理设备的个人计算机的示例结构的框图。

具体实施方式

在下文中将结合附图对本公开的示范性实施例进行描述。为了清楚和简明起见，在说明书中并未描述实际实施方式的所有特征。然而，应该了解，在开发任何这种实际实施例的过程中必须做出很多特定于实施方式的决定，以便实现开发人员的具体目标，例如，符合与系统及业务相关的那些限制条件，并且这些限制条件可能会随着实施方式的不同而有所改变。此外，还应该了解，虽然开发工作有可能是非常复杂和费时的，但对得益于本公开内容的本领域技术人员来说，这种开发工作仅仅是例行的任务。

在此，还需要说明的一点是，为了避免因不必要的细节而模糊了本公开，在附图中仅仅示出了与根据本公开的方案密切相关的设备结构和/或处理步骤，而省略了与本公开关系不大的其他细节。

接下来，将参照图1至图12描述本公开的实施例。

首先，将参照图1描述根据本公开的实施例的身份验证系统的模型。图1是示出根据本公开的实施例的身份验证系统的模型的示意图。

如图1所示，根据该实施例的系统10可包括数据平台系统100、客户端200和服务端300。客户端200用于生成验证用户身份所需的验证码，并且服务端300用于验证客户端200所生成的验证码的有效性以验证用户身份。在下文中，将分别参照图2和图3详细描述客户端200和服务端300的具体功能配置示例。

数据平台系统200是去中心化的分布式数据库，并且其中的记录是不可更改和删除的。优选地，该数据平台系统可以是基于区块链(blockchain)的数据平台。

区块链是指通过去中心化和去信任的方式，由参与节点集体维护的一个可靠的分布式数据库系统，它的特点是不可更改，不可伪造。区块链是虚拟货币-比特币(bitcoin)金融系统中的重要概念。然而，随着区块链技术的发展，它也不仅仅只是应用在虚拟货币的支付领域。如果说区块链技术1.0是为虚拟货币而生，则区块链技术2.0的核心特性(即，信用信任)成为目前的重要应用方向，被建议做区块链合约、公证等。而区块链技术3.0则被定位为金融应用以外的应用领域，如政府、健康、科学、文化和艺术等领域。

区块链技术主要让参与系统中的众多节点，通过使用密码学方法产生一串数据区块(block)，每个数据区块中包含了一定时间内的系统全部信息交流数据，并且生成数据指纹用于验证其信息的有效性并链接(chain)下一个数据区块。目前的区块链技术可分为3类应用：公有链(permissionlessblockchain)、私有链(permissionedblockchain)或者两者结合应用。公有链例如为比特币使用的区块链，任何人都可以下载，运行客户端，参与系统的运行和维护，写入新的数据区块(即，挖矿)。私有链是指其写入权限(即挖矿，写入一个新的数据区块)仅限于特定组织的区块链。二者的混合应用是指共识过程受预选节点控制的区块链。本质上讲，无论是公有链还是私有链，其实现技术都是一样的，即：去中心化且寓于分布式结构的数据存储、传输和证明的方法，用数据区块取代了目前互联网对中心服务器的依赖，使得所有数据变更或者交易项目都记录在一个云系统之上，理论上实现了数据传输中对数据的自我证明。

无论私有链还是公有链，首先都是基于区块链去实现一个数据记录系统(数据库)，即靠不断的写入新的数据区块，把数据记录串起来；都需要一个共识机制来让所有的节点信任这个新的数据区块(例如，比特币的共识机制是靠挖矿来实现的)；参与写入新数据区块的节点都可以保留一份完整的记录副本。私有链和公有链的区别应该在于应用层面，即哪些节点可以参与到区块链的运行维护(例如挖矿)，公有链是全民参与，私有链可以指定参与节点或设置门槛。另一个区别在于，公有链是匿名的；而私有链因为对于参与节点有选择性，所以不能是匿名的，例如银行应用，只有银行自己的客户可以参与到某个银行的基于区块链的应用服务中，成为其中的一个节点。

可以理解，本发明的数据平台系统并不限于使用公有链或私有链或者二者的结合，而是可根据具体的应用场景而选择适当的区块链系统。例如，对于银行应用，可以选择私有链(或称之为许可链)，由于私有链与公有链相比，可以引入身份管理，从而避免由完全匿名性所带来的各种隐患以及用户管理上的不方便。而对于其他无特殊要求的应用，也可直接采用现有的公有链(例如，比特币的区块链系统)，从而免去了开发和维护成本，具有较强的适用性；或者对于一些应用场合，也可选择公有链和私有链的组合以获得身份可管理性与开发和维护成本之间的折中。

这里，应指出，虽然私有链(或称之为许可链)受到许可权的限制，但仍然是去中心化的，也没有单一的权威。无论私有链还是公有链，它们都是基于区块链技术的、都是去中心化的、以数据区块(block)为基本数据集的、需要依靠共识机制完成事务记录的数据库系统。

此外，应指出，尽管这里描述了本公开的数据平台系统是基于区块链的数据平台的示例，但是本公开并不限于此，而是可采用任何现有的或未来可能出现的数据平台，只要保证该数据平台是去中心化的分布式数据库并且其中的数据记录是不可更改和删除的即可。

在本公开的以下描述中，将以基于区块链的数据平台为例来具体描述本公开的技术，但是应理解，本公开的技术也可以类似地扩展应用于其他数据平台系统。

接下来，将参照图2描述根据本公开的实施例的用于生成验证码的客户端的功能配置示例。图2是示出根据本公开的实施例的用于生成验证码的客户端的功能配置示例的框图。

如图2所示，根据该实施例的客户端200可包括事务发起单元202、验证码生成单元204和发送单元206。应指出，这里所描述的事务发起单元202、验证码生成单元204和发送单元206可以是分立的物理实体或逻辑实体，或者也可由同一个物理实体(例如，处理器(例如，中央处理单元(cpu)或数字信号处理器(dsp)等)或专用集成电路(asic)等)来实现。下面将分别详细描述各个单元的功能配置示例。

事务发起单元202可被配置成响应于关于用户的预定身份验证事件而发起数据平台系统内的第一账户与第二账户之间的随机事务，以使得该随机事务记录在数据平台系统内。

具体地，例如，当用户需要登录特定应用服务时，除了常用的用户名和密码之外，还需要输入验证码作为一个因素参与到多因素身份认证中，以进一步提高安全性。区别于现有技术中由服务端和客户端同时生成验证码或者由服务端生成验证码并发送给用户，在本公开的技术中，由用户利用客户端200先于服务端而主导验证码的生成。例如，在数据平台系统是基于比特币区块链的数据平台的情况下，当需要验证用户身份时，客户端200的事务发起单元202可发起数据平台系统内的第一比特币账户与第二比特币账户之间的转账交易，由于此次交易是用户发起的并且交易金额也是随机的，也就是说，没有人可以预测此次随机交易的额度和时间，因此也无法利用关于此次交易的信息来伪造验证码。例如，图5示出了根据本公开的技术在现有比特币区块链系统上的应用示意图。替选地，在数据平台系统是基于智能合约区块链的数据平台的情况下，当需要验证用户身份时，客户端200的事务发起单元202可发起数据平台系统内的合约甲方与合约乙方之间的一次随机事务(即，新合约生成)，同样地，由于该新合约的相关信息对于除用户之外的其他方是未知的，因此也无法利用该合约相关信息来伪造验证码。例如，图6示出了根据本公开的技术在现有智能合约区块链系统上的应用示意图。稍后将分别参照图5和图6描述这两种情况下的应用示例。再者，例如，在数据平台系统是基于数字资产管理区块链的数据平台的情况下，此时的随机事务对应于第一账户与第二账户之间的一次资产转移，其原理与前两种情况基本上类似，在此不再赘述。

应理解，尽管这里描述了转账交易、智能合约生成和资产转移作为第一账户与第二账户之间的随机事务的示例，但是本公开并不限于此，而是根据所应用的区块链系统(例如，基于众筹、法律文件验证、货币清算结算等的区块链系统)，随机事务可相应地对应于这些数据平台系统内的相 应事务，本公开对此不作具体限制。

这里的第一账户和第二账户可以是同一所有者所持有的账户，如2个账户均归用户所有，均归应用服务提供商所有，或者均归第三方验证服务提供者所有；或者也可以是不同的所有者持有的账户，例如，第一账户为用户所持有的账户，而第二账户为应用服务提供商指定的账户或者第三方验证服务者提供的账户。本质上而言，只要是客户端200可操作的任意两个账户间的一次事务，该事务的相关数据即可用于生成一个随机验证码，而验证码的生成过程和账户的归属没有必然联系。但是，从现实业务应用的角度以及安全性的角度考虑，一般而言，用户只能操作自己的账户或者服务商指定的预置在客户端200中的账户。

第一账户和第二账户可以是在每次需要生成验证码时实时创建的或者可以是预先设置的。

具体地，对于实时创建账户的情况，在每次需要生成验证码时，可以通过基于区块链的数据平台系统创建2个账户并把账户地址导入客户端200中，或者可以通过客户端200调用基于区块链的数据平台系统创建2个账户。通过这种方式，可以使得验证服务端还可以根据用户设定的参与操作的账户来屏蔽其他恶意伪造身份的操作，有利于进一步提高安全性。

另一方面，对于预先设置账户的情况，可以由应用服务提供商或第三方验证管理服务提供商(这两个服务提供商也可以是同一个)在客户端200中预装导入2个随机的账户。通过这种方式，可以做到用户透明，即，在生成验证码时，用户并不知道在生成验证码的过程中涉及到了后台的两个账户之间的一次事务。

第一账户和第二账户可以分别记作a1和a2，无论是从a1至a2的事务，还是a2至a1的事务均可以用来触发验证码的生成。替选地，还可以由应用服务提供商或者第三方验证服务提供商在客户端200中指定第二账户a2，由用户自由指定一个自己的账户作为第一账户a1，从而每次生成验证码时，可以由从a1至a2的事务来触发验证码的生成。

然后，客户端200可以通过例如广播方式来广播关于此次随机事务的信息，以使得该随机事务记录在数据平台系统中。由于区块链系统的不可抵赖性，该随机事务一旦记录在数据平台系统中，就不可被移除和更改。

验证码生成单元204可被配置成至少基于关于随机事务的信息，生成用于用户的身份验证的验证码。

如上所述，由于由用户所发起的第一账户与第二账户之间的随机事务是最新发生的，其内容信息完全是随机的并且无法预先获知并截取，因此如果利用基于该随机事务的信息来生成验证码，可以避免现有技术中验证码被伪造、截取等风险，进一步提高验证码的安全性。优选地，除了关于该随机事务的信息之外，验证码生成单元204还可基于该数据平台系统内的历史事务记录来生成验证码。可以理解，在基于区块链的数据平台系统中，任何账户的任何事务均会被记录在该数据平台系统内，因而验证码生成单元204可以从该数据平台系统获取已知账户(例如，可以是第一账户或第二账户，或者也可以是除这两个账户之外的其他已知账户)的历史事务信息用于生成验证码。此外，验证码生成单元204还可基于其他辅助信息(诸如时间戳、用户名、密码等)来生成验证码，本公开对此不作限制，只要保证用于生成验证码的“种子”至少包括当前发起的随机事务的相关信息即可。

用于生成验证码的算法可包括以下算法中的至少一个：哈希(hash)算法、消息认证码(mac)算法、哈希消息认证码(hmac)算法、基于分组密码的消息认证码(cbc-mac)算法、随机数生成算法、公钥加密算法和对称密钥加密算法，但是并不限于这些算法，而是可利用本领域公知的任何加密算法。如何利用这些现有算法、根据关于随机事务的信息来生成验证码的具体过程与现有技术中基本上相同，在此不再详细描述。区别仅在于，在现有技术中，通常将所生成的验证码和用于生成验证码的“种子”(至少包括关于随机事务的信息)一起发送给验证方，而在本公开中，仅将所生成的验证码发送给验证方，对于“种子”，则是在数据平台系统确认了用户所发起的随机事务以将其记录在数据平台系统之后，由验证方自己在数据平台系统内检索获得。稍后将在关于服务端的实施例中具体描述该区别。

发送单元206可被配置成将所生成的验证码发送给服务端300，以由服务端300根据数据平台系统内的随机事务的记录和验证码对用户的身份进行验证。

接下来，将参照图3描述根据本公开的实施例的用于验证用户身份的服务端的功能配置示例。

如图3所示，根据该实施例的服务端300可包括接收单元302、检索单元304和验证单元306。应理解，这里所描述的接收单元302、检索单元304和验证单元306可以是分立的物理实体或逻辑实体，或者也可由同 一个物理实体(例如，处理器(例如，中央处理单元(cpu)或数字信号处理器(dsp)等)或专用集成电路(asic)等)来实现。下面将分别详细描述各个单元的功能配置示例。

接收单元302可被配置成接收客户端200生成的用于用户的身份验证的验证码。

检索单元304可被配置成在数据平台系统内检索用户的客户端200所发起的随机事务的记录。即，如上所述，在客户端在数据平台系统内的第一账户与第二账户之间发起了一次随机事务以用于生成验证码时，客户端可以在该数据平台系统内广播此次事务，随后数据平台系统会在确认此次随机事务之后将其记录下来(即，打包成一个数据区块并加入区块链中)，从而服务端300的检索单元304可以根据该次随机事务的标识在数据平台系统内找到此次随机事务的相关信息，以用于验证所接收到的验证码的有效性。应指出，从客户端发起随机事务到服务端可以验证客户端上传的验证码之间可能存在一定的时间差，这个时间差由数据平台系统的数据区块(block)的生成速度决定。因此，如上所述，对于一些对于实时性要求较高的应用，也可以采用基于私有链的数据平台系统，这是由于其数据区块的生成速度相对较快。

此外，应指出，在数据平台系统100记录了此次随机事务之后，服务端300的检索单元304可以以预定时间间隔(例如，该间隔取决于该数据平台系统的数据区块生成速度)进行检索，或者替选地，数据平台系统100也可以通过广播或者专门的通知机制来通知服务端记录已完成，从而检索单元304可以在接收到该通知之后，根据来自客户端200的随机事务标识信息在数据平台系统100内检索随机事务的记录。

验证单元306可被配置成根据所检索到的随机事务的记录，验证所接收到的验证码的有效性，以验证用户的身份。验证单元306所采用的用于验证码的验证算法可以与客户端200的验证码生成单元204用于生成验证码的生成算法相同。即，假设所生成的验证码为vc，验证单元306可以根据所检索到的随机事务的记录，使用同样的验证码生成算法来计算一个验证码vc’，如果vc’＝＝vc，则验证通过。

如上所述，在验证单元306利用上述的现有加密算法来验证所接收到的验证码的有效性时，具体的生成验证码的过程与现有技术中基本上相同，区别仅在于，用于生成验证码的“种子”并不是从客户端接收到的，而是服务端从数据平台系统内检索到的。也就是说，在数据平台系统确认最 新的随机事务并将其记录下来之前，服务端是无法验证验证码的有效性和真实性的。如上所述，由于数据平台系统是一个去中心化的分布式数据库，其中的记录是不可更改和删除的，也就是说，数据平台系统内的记录是不可篡改的和可信赖的随机事务相关的“种子”信息是通过数据平台系统进行生成和记录，避免了从客户端向服务端传送“种子”的风险，从而进一步提高了系统安全性。另外，服务端只对数据平台系统内已记录的“种子”进行验证码的确认，也就是说数据平台系统相当于是服务端前面的一级缓存，如果想对服务端进行针对验证码的拒绝服务攻击(dos)，则攻击者需要让验证码/“种子”的数量远超过服务端的处理能力。所以，基于该数据平台系统，可以进一步提整个应用系统的安全性。

为了便于理解根据本发明的验证系统的工作流程，下面将参照图4所示的流程图来描述根据本发明的验证系统的工作流程。图4是示出根据本公开的实施例的用于验证用户身份的交互过程的流程图。

如图4所示，首先，在步骤s410中，客户端200响应于预定身份验证事件(例如，用户登录某应用服务)而发起数据平台系统100内的两个账户间的随机事务，以使得该随机事务记录在数据平台系统100内。然后，在步骤s420中，客户端200基于关于该随机事务的信息而生成验证码，并且在步骤s430中，客户端200将所生成的验证码和该随机事务的标识信息发送到服务端300。接下来，在步骤s440中，数据平台系统100确认该随机事务并将其作为一个数据区块加入到区块链中。在步骤s450中，服务端300等待数据平台系统100确认该次随机事务，该等待可以是等待预定的时间或者也可以是等待来自数据平台系统100的确认通知。在数据平台系统100确认该次随机事务之后，即，在该次随机事务被记录在数据平台系统100内之后，在步骤s460中，服务端300才可以利用所接收到的标识信息在数据平台系统100内检索该随机事务，以基于随机事务的记录验证所接收的验证码的有效性和真实性，并且在步骤s470中，服务端300将验证结果返回到客户端200，从而验证通过的用户可以成功登录应用服务，否则被拒绝登录。

应理解，参照图4所给出的流程仅是示例而非限制，并且本领域技术人员可以根据本公开的原理对该示例流程进行修改。例如，在客户端200还需要基于历史事务记录生成验证码的情况下，客户端200还需要从数据平台系统100获取相应的历史事务记录信息。此外，图4所示的各个步骤的顺序仅是为了便于描述而给出的，实际的执行过程并不限于该顺序，而 是可以根据实际情况适当地修改。

然而，应指出，因为区块链原则上是透明的，即所有节点都可以访问的，因此，在本发明的执行中，一般地，需要保证先生成验证码发送给服务端，再把对应的随机事务记录到区块链。这样，即使有恶意第三方得到“种子”信息(即，随机事务)用来伪造一个验证码，也要排在待验证的验证码队列的后面，而验证服务端只会优先处理排在队列前面的等待验证的验证码，从而可以降低验证码被伪造的风险，提高系统安全性。当然，从以区块链技术为支撑的数据平台系统的角度，想要伪造一个用于生成验证码的随机事务是非常困难的。每一个被记录在数据平台系统的随机事务都是基于两个账户(地址)之间的活动，而服务端验证时也需要根据账户(地址)信息检索该记录。所以，恶意第三方想要伪造验证码的话，还要伪造对应的两个账户(地址)之间的随机事务活动，这在理论上是不可行的。

此外，还应指出，在通常情况下，本发明之所以强调需要先把生成的验证码发送给服务端再把对应的随机事务记录到数据平台系统，是担心恶意第三方得到用户的验证码，同时在别的服务界面抢先登录，从而可能产生验证冲突。例如，如果恶意第三方窃取了用户的用户名(id)、密码(pwd)等，那么他可以监控等待用户的操作，例如，当发现用户在中国银行登录并生成验证码时，恶意第三方立刻利用所窃取的该用户的id和pwd以及通过得到验证码种子(即，用户发起的随机事务)而获取的验证码在农业银行登录。此时，如果服务端不是优先处理该用户的中国银行登录验证码的话，会出现冲突。当然，实际中，因为区块链数据平台本身具有账户信息，这个信息也可以被利用，例如在生成的交易或者智能合约中，标明了该交易或智能合约用于发起和中国银行有关的业务等等，这些信息本身可用于生成验证码，同时被服务端用来验证服务源，以进一步提高安全性。

然而，在实际应用中，作为替选示例，还可能存在以下情况：如果只是用随机事务的特定信息(例如，交易金额)作为生成验证码的种子，那么与数据平台系统相关的其他信息都不必提前生成，也就是说，可以等验证码生成之后再发起随机事务。换言之，如果种子信息不涉及数据平台信息的话，就可以先完成验证码发送，再发起随机事务。然而，应理解，在该情况下，由于验证码的生成与验证过程与数据平台系统的关联度较弱，从而在一定程度上会降低系统安全性。

接下来，为了更系统地理解本发明的验证系统的工作原理，将参照图5和图6，描述在根据本发明的技术分别应用于比特币区块链系统和智能合约区块链系统的情况下的示例。图5是示出根据本公开的实施例的身份验证系统在现有比特币区块链系统上的应用示意图。

如图5所示，当需要进行用户身份验证时，首先，客户端发起比特币账户a1与比特币账户a2之间的一次随机转账交易，转账金额是随机的，该交易最终将被记录在基于比特币区块链的数据平台系统中。此次交易记作ta。

然后，客户端基于此次交易信息生成一个验证码：vc＝verificationcodegen(ta)，其中，vc表示验证码，verificationcodegen()表示用于生成验证码的函数。优选地，客户端也可以同时基于当前新交易和数据平台系统中已知账户的历史交易记录来生成验证码，例如，使用账户a1的历史记录，记作a1history，为了便于记录，可以从第一条记录起，采用哈希链的方式记录保存最新的历史记录，例如hash(a1history)，其中hash()表示哈希函数，从而验证码可以如下生成：vc＝verificationcodegen(ta||hash(a1history))。应理解，该历史信息当然也不限于从第一条记录开始的信息，而是也可以是指定时间的交易信息。

接下来，客户端可以向服务端返回所生成的验证码vc和ta标识信息，这些信息最终和用户名、密码等身份信息一并提交给服务端以进行用户身份验证，并且客户端还在数据平台系统的服务网络内广播ta，以使其记录在数据平台系统内。

在此次交易ta被记录在数据平台系统之后，服务端可以根据ta标识在数据平台系统内找到交易ta，依据数据平台系统中的记录，验证所接收到的验证码vc的有效性：result＝verify(vc，ta)，其中，result表示验证结果，并且verify()表示验证函数。如上所述，服务端可以使用同样的验证码生成算法来计算一个验证码vc’＝verificationcodegen(ta)，如果vc’＝＝vc，则验证通过，从而通过验证的用户可以成功登陆应用服务。

应指出，在基于比特币区块链的应用中，由于涉及资金的交易，因此在验证服务是无偿的情况下，应保证用户的资金无损失，而在有偿服务的情况下，也应在扣除了相应的服务费用之后将剩余资金返回到用户的账户中。具体地，如果参与验证码生成的两个账户均是用户自己的账户，则由于是属于同一用户的账户间交易，因此用户无财务损失；相反，如果参与 验证码生成的一个账户是用户的账户，而另一账户是应用服务提供商或第三方验证服务提供商的账户，则在无偿服务的情况下，在验证通过后，应该发起这笔随机转账交易的逆向转账交易以将资金还原到初识状态，也就是说，可以让用户不察觉账户内容变化的情况下完成一次验证码的生成；而在有偿服务的情况下，验证服务提供商也可以在扣除服务费后把剩余金额转回原始账户。

即，优选地，服务端300还可包括逆向事务发起单元，用于在验证单元306完成了验证码的验证之后，发起关于客户端发起的随机事务的逆向事务。

图6是示出根据本公开的实施例的身份验证系统在现有智能合约区块链系统上的应用示意图。

在具体描述本发明的应用之前，将简要介绍智能合约的相关背景。智能合约被认为是区块链2.0的代表性应用，其是由事件驱动的、具有状态的、运行在一个复制的分享的账本之上的、且能够保管账本上资产的程序，其又不仅仅只是一个计算机程序而是同时也是参与者。它对接收到的信息进行回应，它可以接收和储存价值，也可以向外发送信息和价值。这个程序就像一个可以被信任的人，可以临时保管资产，总是按照事先的规则执行操作。

目前业内有2家与智能合约平台有关的创业公司：ethereum(以太坊)和rootstock。rootstock是一个开源的点对点智能合约平台，利用现有的区块链技术(比特币平台)而没有开发属于自己的区块链，而以太坊(ethereum)是独立的开源数字货币和区块链平台，它为开发者提供在区块链上搭建和发布应用的平台。

简单来说，从密码学和金融科技(fintech)来讲，目前业界提到的智能合约就是在区块链基础上的延伸，从简单转账到资产转移以及其他事务。这些资产归属、资产状态的变化被区块链上的智能合约协议(软件)相约束。也可以简单地认为，这些区块链上发生的事务会被网络赋予合约，即被系统认可和生效，而不需要第三方裁决机构，毕竟区块链就是为了实现去中心化，就像基于区块链的比特币不需要银行就能完成货币发行和交易一样。fintech领域的智能合约则是对于合约双方透明并严格按照合约约定执行的计算机程序。所以，创建一个新的智能合约就是在区块链上生成一段程序，这个程序用于执行双方的约定。

当然，应理解，尽管以上从fintech领域描述了智能合约，但是智能合约并不限于应用于金融领域，而是同样可适用于任何需要限定合约双方按照合约内容执行操作的领域。

在智能合约应用中，区块链会依据区块链网络上的信息对合约进行验证，因为区块链的信息不可逆，同时会自动记录时间，所以合约的安全性、可信赖性得到保证。

图6所示的应用示例与图5所示的应用示例基本上相同，区别仅在于，在基于智能合约区块链的数据平台系统的情况下，账户间的事务并非是转账而是新合约生成。

具体地，如图6所示，首先，客户端发起一次随机事务，即，新生成一个智能合约，然后基于该智能合约而生成验证码(vc)，并发送给服务端。

然后，客户端在数据平台系统中广播新智能合约相关信息，数据平台系统在下一个数据区块中记录该信息并附加时间戳。该记录是不能修改和抵赖的。

接下来，服务端从已记录的数据区块中检索与接收到的vc相对应的智能合约的记录信息，依据该记录验证vc的真实性。

同样地，如上所述，在验证完成之后，根据实际需要，服务端也可以发起一次逆向事务以执行逆向合约生成，此时的逆向事务也是生成一段智能合约程序，只不过执行的内容可以是与之前的随机事务的合约内容反向的操作。其余未描述的细节与图5所示的示例相同，在此不再重复。

应指出，尽管在图6所示的示例中，合约甲方和合约乙方均在客户端内，但这仅表示由客户端发起双方之间的一次事务而并不代表甲方和乙方的归属，也就是说，与上述第一账户和第二账户相同，甲方和乙方可以归属同一用户或不同用户。

除了参照图5和图6描述的示例之外，根据本公开的技术还可以应用于诸如基于数字资产管理区块链、法律文件认证区块链等的数据平台系统，其具体实施方式与以上参照图5和图6描述的示例类似，在此不再一一详细描述。

这里，应指出，在本公开的基于区块链的验证码系统中，前提是基于区块链的数据平台系统的每个数据区块的验证服务的速度(或称之为新区块的生成速度)不会影响应用服务对于验证码的需求和验证速度，这是由 于只有被数据平台系统记录的事务信息才可以用来验证客户端生成的验证码，而区块链的数据区块是定期更新的，也就是说，服务端只需要在一个数据区块更新周期内处理与之前的数据区块中的事务记录相关的验证码检验即可，没有记入数据区块的事务涉及的验证码将暂不被处理。换言之，只要服务端的业务流量处理速度比数据平台系统的数据块的更新速度快，就不会出现拒绝服务，从这个角度来看，本发明的基于区块链的验证码系统可以在一定程度上抵抗拒绝服务(dos)/分布式拒绝服务(ddos)攻击。

此外，还可以理解，基于一次事务而生成的验证码可以作为登录时的多因素身份认证的一个因素来使用，因此在每次登录时都需要一个新的验证码以保证身份验证系统的安全性。这样，对于这种一次性使用的验证码，客户端和服务端在完成验证流程后均不需要保存该验证码，除非该验证码需要作为一个输入参数用于生成后续的新的验证码，这时可以临时保存该验证码，直至新的验证码生成后，就可以清除之前的验证码。因此，可以看出，与现有的验证码机制相比，不需要大型的后台数据维护系统，从而可以大大降低系统成本。

另一方面，基于一次事务生成的验证码也可以作为周期性的动态验证码使用，例如，每天生成一次，或者每小时生成一次等。在有效期内，在应用层服务中，多次使用同一个验证码，例如，动态的信用卡验证码(cvv)，稍后将详细描述该应用示例。在该情况下，可以通过根据事务记录并附加其他信息，生成在指定期限内有效的动态验证码。如果下次使用时提示该验证码已过期，则客户端可以随时再生成一个新的动态验证码。

应指出，以上描述的客户端和服务端的功能配置仅为示例而非限制，并且本领域技术人员还可以根据本公开的原理而对上述功能配置进行修改，例如，对上述各个功能单元进行组合、子组合、变更等，或者添加另外的功能单元(例如，显示单元、存储单元等)。

具体地，作为示例，在验证码如果是利用mac、cbc-mac、hmac或者公钥密码算法生成的情况下，生成的验证码本身就具有认证/鉴别(authentication)特性，即，只有客户端和服务端拥有对应的密钥来生成或验证验证码。而如果是用哈希算法或者随机数生成算法等不具有认证/鉴别特性的简单方法生成的验证码，为了抵抗中间人伪造攻击，还可以基于公钥或身份密钥的签名来提升系统的安全性。具体地，例如，可以为每 个客户端分配一对公钥(pk)和私钥(sk)，从而客户端200可以包括另外的签名单元，用于利用客户端私钥对所生成的验证码进行签名，然后发送单元可以将验证码和签名一起发送给服务端，从而服务端可以利用数据平台系统内的事务记录来验证验证码，并且利用客户端公钥对签名进行验证以证实该验证码确实来自客户端200而不是伪造的。也就是说，对于安全性要求较高的应用环境，还可以附加签名机制来验证验证码发送方的身份，以提升系统安全性。

与上述装置实施例相对应的，本发明还提供了以下方法实施例。

图7是示出根据本公开的实施例的用于生成验证码的方法的过程示例的流程图。该方法例如可以通过在诸如智能手机、平板电脑、个人数字助理(pda)等的客户端上执行相应的验证码生成程序来执行。

如图7所示，首先，在步骤s701中，响应于关于用户的预定身份验证事件而发起数据平台系统内的第一账户与第二账户之间的随机事务，以使得该随机事务记录在数据平台系统内。该数据平台系统是去中心化的分布式数据库，并且其中的记录是不可更改和删除的，例如，优选地，可以是基于区块链的数据平台。优选地，随机事务包括以下中的至少一个：转账、合约生成和资产转移。第一账户和第二账户可以属于同一所有者或不同所有者，并且可以是实时创建的或预先设置的。

接下来，在步骤s702中，至少基于关于随机事务的信息，生成用于用户的身份验证的验证码。优选地，还可基于数据平台系统内的历史事务记录来生成验证码。

然后，在步骤s703中，将所生成的验证码发送给服务端，以由服务端根据数据平台系统内的随机事务的记录和验证码对用户的身份进行验证。

优选地，在图7所示的方法中，还可包括用于利用客户端私钥对所生成的验证码进行签名的步骤，并且在步骤s703中将签名后的验证码发送给服务端。

应理解，这里描述的方法实施例是与以上参照图2描述的客户端的实施例相对应的，因此，在此未详细描述的内容可参见以上相应位置的描述，在此不再重复。

图8是示出根据本公开的实施例的用于验证用户身份的方法的过程示例的流程图。该方法例如可通过在服务器上执行用于验证用户身份的程 序来执行。

如图8所示，首先，在步骤s801中，接收客户端生成的用于用户的身份验证的验证码，该验证码是客户端至少基于关于数据平台系统内的第一账户与第二账户之间的随机事务的信息而生成的，该随机事务是客户端响应于关于用户的预定身份验证事件而发起的。

接下来，在步骤s802中，在数据平台系统内检索随机事务的记录。

然后，在步骤s803中，根据随机事务的记录，验证验证码的有效性，以验证用户的身份。

优选地，该方法还可包括用于在验证之后发起与随机事务对应的逆向事务的步骤。

此外，优选地，该方法还可包括用于利用客户端公钥对来自客户端的签名后的验证码进行验证的步骤。

应理解，这里描述的方法实施例是与以上参照图3描述的服务端的实施例相对应的，因此，在此未详细描述的内容可参见以上相应位置的描述，在此不再重复。

此外，应理解，根据本公开的实施例的存储介质和程序产品中的机器可执行的指令还可以被执行以上描述的用于生成验证码和验证用户身份的方法，因此在此未详细描述的部分可参考先前相应位置的描述，在此不再重复进行描述。

相应地，用于承载上述存储有机器可执行的指令代码的程序产品的存储介质也包括在本发明的公开中。所述存储介质包括但不限于软盘、光盘、磁光盘、存储卡、存储棒等等。

根据上述本公开的实施例，本发明至少可以实现以下技术效果之一：

1、有效的身份验证方式：通过基于区块链的验证码来验证用户身份，因为参与生成验证码的区块链账户要么是属于用户的，要么是专属于用户的客户端的，就像用户的手机sim卡一样，在通常情况下，不考虑恶意攻击的时候，我们可以认为所生成的验证码可以作为用户的身份信息参与到多因素认证应用中。

2、验证码由客户启动生成，具有随机性，因为没有人可以预测某次随机事务的具体内容和时间，因此，可以有效地抵抗验证码被伪造、截取等风险。

3、验证码的验证要依据区块链中的数据，区块链是在持续延长，而且新区块一旦加入到区块链中，就不会再被移走，数据一旦被写入就不能修改或删除。也就是说，数据平台系统内的记录是高度安全和可信赖的，从而也避免了现有技术中用于验证验证码的数据被恶意第三方获取来伪造验证码的风险，进一步提高了安全性。

4、验证码的产生与新的事务有关，而事务的过程安全则可依靠基于区块链的数据平台本身的技术来保障。基于区块链的数据平台使用密码学的设计来确保事务的各个环节安全性，即，除非用户的账户信息已经泄露，否则没有人可以伪造该用户的事务。

5、抵抗dos/ddos攻击：只有被基于区块链的数据平台记录的事务信息可以被用来检验客户端生成的验证码，而区块链的数据区块是定期更新的，也就是说，只要验证服务端的业务流量处理速度比基于区块链的数据平台的数据区块的更新速度快，就不会出现拒绝服务。进一步地，如果生成验证码用的2个账户是归属用户的，那么也可以把系统设计成需要用户触发验证码生成，例如用户完成某项计算或选项操作，然后启动验证码生成。通过多种手段结合，尽量避免dos/ddos攻击。

可以看出，由于根据公开的验证系统(包括验证码的生成和验证)大大提高了数据安全性，因此其可以广泛应用于各种领域中，包括但不限于金融、医疗、文化、政府、工业控制等领域，也就是说，只要涉及需要访问控制的任何领域均可应用本发明的技术。

应指出，在本公开的以下描述中，“客户端”可以被实现为物理实体装置或者也可以被实现为在实际的客户端装置(例如，个人计算机、智能手机、平板电脑、pda等智能终端)上运行的程序，同样地，“服务端”可以被实现为物理实体装置或者也可以被实现为在实际的服务器装置上运行的程序。具体地，当“客户端”被实现为程序时，其可以是在电脑或其他智能终端上的独立软件工具或服务，例如exe、jar、dex、apk等，也可以是软件开发工具包，例如sdk(softwaredevelopmentkit)、jdk(javadevelopmentkit)等，或者也可以是函数库，例如dll、lib等，通过提供应用程序接口让第三方软件进行集成和二次开发。同样，当“服务端”被实现为程序时，其可以是独立的软件工具或服务，或者是开发工具包用以集成到应用服务系统中。这样，在用户登录特定应用服务需要进行身份验证时，可以调用相应的客户端程序来生成验证码，将所生成的验证码提交给服务端程序以进行验证。

接下来，将参照图9至图11描述根据本公开的实施例的技术在应用服务环境中的登录身份认证应用的示例。图9是示出根据本公开的实施例的技术在应用服务环境中的登录身份认证应用的示例的示意图。

如图9所示，应用服务appui是用户在使用应用服务时的用户登录界面，一种可能的应用界面实现如图10所示。在图9所示的示例中，提供应用服务的服务器和提供验证服务的服务器是独立的实体。具体地，在用户登录应用服务时，可调用客户端200来生成验证码。然后，客户端200发起一次随机事务，生成验证码，广播该事务以使其记录在数据平台系统100内，并且将所生成的验证码和事务标识信息发送给服务端300。在数据平台系统100确认了该次随机事务之后，服务端300验证所接收的验证码的有效性，并且将验证结果发送给应用服务器。应用服务器对其他用户登录信息(诸如用户名和密码)进行验证，并且将验证码的验证结果和其他用户登录信息的验证结果返回给应用服务appui，如果所有验证结果均表示验证通过，则用户可以成功登录应用服务，反之，如果任一验证结果表示验证失败，则用户无法登录应用服务。

应理解，上述由客户端200生成验证码并且由服务端300验证验证码的过程可以是在后台执行的，对于用户完全透明的。例如，如图10所示，当需要生成验证码时，用户可点击界面中的按钮“点击获取验证码”，从而通过在后台执行本发明的验证码生成过程，所生成的验证码显示在“区块链验证码”后的输入框内。然后，用户点击按钮“登录”，则通过在后台执行本发明的验证码验证过程来验证所生成的验证码的真实性，验证通过，则用户可登录应用服务，否则可弹出警告消息例如“验证码错误”而拒绝用户登录服务。可以看出，具体的验证码生成和验证过程对于用户来说是完全透明的，不需要用户的参与，从而不会增加操作复杂性。

图11是示出根据本公开的实施例的技术在网络应用服务环境中的登录身份认证应用的另一示例的示意图。

如图11所示，图11所示的应用示例与图9所示的示例基本上相同，区别仅在于，应用服务器和验证服务端是同一实体，从而可以由应用服务器完成验证码和其他登录信息的验证。其他具体过程可参见图9的示例的描述，在此不再赘述。

下面，将作为示例具体描述根据本公开的技术在信用卡验证码服务中的应用。

随着网络支付交易量的日益增大，信用卡验证码(cardverificationcode(cvc)或cardverificationvalue(cvv))的安全也日益受到银行和客户的重视。因为该验证码是印在信用卡背面的附加码，一般是3位数字，所以只要是卡被除用户以外的人看到，均可能被记住。为了解决cvv的安全问题，提出了动态cvv技术。例如，dynamicsinc公司为mastercard的客户提拱的动态验证码的解决方案，该动态验证码基于卡上的led或显示器来显示，每次交易时会有一个随机的验证码供用户使用，当然这个解决方案是基于可显示的卡设计的，而目前的带显示的银行卡一般使用3位的电子纸(e-paper)或lcd；gemalto公司推出的动态cvv方案，其使用每20分钟变化一次的动态验证码取代之前使用的静态3位信用卡验证码，该动态cvv码可以在用户的手机实现也可以在有显示模块的卡上使用；以及tenderarmor公司推出的cvvplus产品，该动态cvv由服务商生成，每天更新并通过手机或电子邮件推送给持卡者，或者持卡者也可以随时申请新的cvvplus码等。可以看出，现有的动态cvv解决方案要么是基于服务端生成，定时或不定时下传给用户端，要么是基于客户端和服务器同步产生随机数的模式而实现的，即客户端(手机或卡)和服务端(银行或第三方)各有一个同步的随机数发生器，保障双方在同一时段获得同样的验证码。无论前者还是后者，服务器都要维护一个庞大的、针对所有用户的cvv生成系统。

相比之下，如上所述，在基于本发明实现的动态cvv的应用中，既不需要提供带显示的银行卡，也不需要在后台维护庞大的cvv生成系统，而是可以根据用户的需要而由用户主动发起动态cvv的生成，从而可以随时为用户提供动态cvv或者提供在一定时间内有效的动态cvv，这样，在提高安全性的同时还大大降低了系统成本。下面将结合本发明的技术，简要描述基于本发明的动态cvv实现方案。

在基于本发明中实现的动态的信用卡验证码应用中，客户端可以是基于手机的应用程序、电脑平台的应用服务程序或者其他形式的智能终端上的应用服务程序，而服务端则包括在银行服务系统中。此外，应指出，在本应用示例中，数据平台系统所基于的区块链可以是公有链，或者也可以是银行的私有链，或者也可以是二者的结合。

假设用户在网银交易中被要求输入动态cvv，此时用户可以启动客户端程序，完成2个设定账户间的随机事务，该随机事务最终将被记录在数据平台系统中。

然后，客户端基于此次事务相关的信息生成一个3位的验证码，该验证码作为此次网银支付的动态cvv由用户通过网银系统提交给银行系统。在生成cvv时，除了此次事务相关信息之外，其他用户相关信息也可参与到cvv的生成，例如：历史事务记录、用户账户地址(例如，区块链系统的walletaddress)、用户信用卡相关的信息等等。

接下来，客户端程序在数据平台系统中广播该次事务，该事务在下一个周期中被记录在数据平台系统中。在该事务被记录在数据平台系统中之后，银行系统可通过查询数据平台系统中的相关记录，验证该cvv的有效性，若验证通过，则可认为商家已取得用户授权，从而完成此次支付交易。

应理解，尽管这里以动态cvv为例描述了本发明的应用示例，但是本公开并不限于此，而是可类似地应用于任何需要安全身份认证的领域。

另外，还应该指出的是，上述系列处理和装置也可以通过软件和/或固件实现。在通过软件和/或固件实现的情况下，从存储介质或网络向具有专用硬件结构的计算机，例如图12所示的通用个人计算机1200安装构成该软件的程序，该计算机在安装有各种程序时，能够执行各种功能等等。

在图12中，中央处理单元(cpu)1201根据只读存储器(rom)1202中存储的程序或从存储部分1208加载到随机存取存储器(ram)1203的程序执行各种处理。在ram1203中，也根据需要存储当cpu1201执行各种处理等等时所需的数据。

cpu1201、rom1202和ram1203经由总线1204彼此连接。输入/输出接口1205也连接到总线1204。

下述部件连接到输入/输出接口1205：输入部分1206，包括键盘、鼠标等等；输出部分1207，包括显示器，比如阴极射线管(crt)、液晶显示器(lcd)等等，和扬声器等等；存储部分1208，包括硬盘等等；和通信部分1209，包括网络接口卡比如lan卡、调制解调器等等。通信部分1209经由网络比如因特网执行通信处理。

根据需要，驱动器1210也连接到输入/输出接口1205。可拆卸介质1211比如磁盘、光盘、磁光盘、半导体存储器等等根据需要被安装在驱动器1210上，使得从中读出的计算机程序根据需要被安装到存储部分1208中。

在通过软件实现上述系列处理的情况下，从网络比如因特网或存储介 质比如可拆卸介质1211安装构成软件的程序。

本领域的技术人员应当理解，这种存储介质不局限于图12所示的其中存储有程序、与设备相分离地分发以向用户提供程序的可拆卸介质1211。可拆卸介质1211的例子包含磁盘(包含软盘(注册商标))、光盘(包含光盘只读存储器(cd-rom)和数字通用盘(dvd))、磁光盘(包含迷你盘(md)(注册商标))和半导体存储器。或者，存储介质可以是rom1202、存储部分1208中包含的硬盘等等，其中存有程序，并且与包含它们的设备一起被分发给用户。

还需要指出的是，执行上述系列处理的步骤可以自然地根据说明的顺序按时间顺序执行，但是并不需要一定根据时间顺序执行。某些步骤可以并行或彼此独立地执行。

例如，在以上实施例中包括在一个单元中的多个功能可以由分开的装置来实现。替选地，在以上实施例中由多个单元实现的多个功能可分别由分开的装置来实现。另外，以上功能之一可由多个单元来实现。无需说，这样的配置包括在本公开的技术范围内。

在该说明书中，流程图中所描述的步骤不仅包括以所述顺序按时间序列执行的处理，而且包括并行地或单独地而不是必须按时间序列执行的处理。此外，甚至在按时间序列处理的步骤中，无需说，也可以适当地改变该顺序。

虽然已经详细说明了本公开及其优点，但是应当理解在不脱离由所附的权利要求所限定的本公开的精神和范围的情况下可以进行各种改变、替代和变换。而且，本公开实施例的术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。