离线验证系统、扫码设备和服务器的制作方法

本申请涉及加密解密技术领域，尤其涉及离线验证系统、扫码设备和服务器。

背景技术

本部分旨在为权利要求书中陈述的本申请的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

得益于互联网技术，人们信息交流的方式、支付方式得到了翻天覆地的变化。网络传输的信息中包含了例如支付二维码、乘车码等敏感信息。敏感信息涉及用户自身的利益，所以需要对敏感信息进行加密来保证用户信息安全。

现有技术中，主要是通过验证加密信息来确定信息的可靠性。具体实现时，往往需要将待验证信息发送给网络侧的服务器来进行验证。这就要求服务器存储一个正确版本的待验证信息，而且，以二维码为例，需要扫码二维码的验证设备在线将待验证信息发送给服务器才能实现验证。但当网络中断之后，验证设备便无法将待验证信息发送给服务器，则会导致验证失败。

故此，需要一种新的技术方案来解决离线时无法完成验证的问题。

技术实现要素：

本申请实施例提供一种离线验证系统、扫码设备和服务器，用于解决验证设备离线时无法完成验证的问题。

第一方面，本申请实施例提供一种离线验证系统，包括第一服务器、终端设备和验证设备，其中：

所述第一服务器，用于生成用户组的私钥和公钥，并确定该私钥和公钥中的加密密钥和解密密钥；并在接收到该用户组中的用户发送的二维码获取请求后，对该用户的待验证信息和当前时间采用基于时间的一次性密码算法进行加密生成校验数据，并对校验数据和所述待验证信息采用所述加密密钥进行加密后得到密文，将所述密文转换为二维码后发送给所述用户的终端设备显示；以及，将所述解密密钥和所述一次性密码算法发送给所述用户组的验证设备；

所述验证设备，用于接收所述用户组的解密密钥和所述一次性密码算法并存储；并在扫描所述终端设备显示的所述二维码后，提取所述二维码中的密文，并采用所述解密密钥获得所述密文中的校验数据和所述待验证信息；采用所述一次性密码算法对所述待验证信息和当前时间进行加密得到验证数据；比对所述校验数据和所述验证数据是否一致；若一致则验证通过，若不一致则验证失败。

进一步的，所述验证设备包括第二服务器和扫码设备，所述第二服务器与所述第一服务器通信，所述扫码设备和所述第二服务器通信，其中：

所述第二服务器，用于接收所述第一服务器发送的所述用户组的解密密钥和所述一次性密码算法并存储；

所述扫码设备，用于扫描所述终端设备显示的所述二维码后，将所述二维码发送给所述第二服务器进行验证。

进一步的，所述验证设备包括第二服务器和扫码设备，所述第二服务器与所述第一服务器通信，所述扫码设备和所述第二服务器通信，其中：

所述第二服务器，用于接收所述第一服务器发送的所述用户组的解密密钥和所述一次性密码算法并存储后，发送给所述扫码设备；

所述扫码设备，用于扫描所述终端设备显示的所述二维码后，根据自身存储的解密密钥和所述一次性密码算法对所述二维码进行验证。

进一步的，所述第一服务器还用于：

对所述用户组的一对公钥和私钥进行计时；

当计时到预设的生命周期或接收到密钥更新指令时，重新生成一对新的公钥和私钥；

根据新的公钥和私钥，更新该分组对应的加密密钥和所述验证设备中的解密密钥。

进一步的，所述第一服务器还用于，生成所述用户组的下一生命周期的公钥和私钥，并将下一生命周期的解密密钥发送给所述验证设备；

所述验证设备还用于，更新解密密钥得到当前生命周期的解密密钥后存储，并存储所述用户组的上一生命周期和下一生命周期的解密密钥；在对所述二维码进行认证时，采用当前生命周期的解密密钥解密所述密文中的校验数据和所述待验证信息；若解密失败，则采用上一生命周期的解密密钥和/或下一生命周期的解密密钥解密所述密文中的校验数据和所述待验证信息。

进一步的，所述第一服务器具体用于：

在接收到用户发送的二维码请求后，生成随机数，并对该用户的待验证信息和当前时间采用基于时间的一次性密码算法进行加密生成校验数据，并对校验数据、所述待验证信息和所述随机数采用加密密钥进行加密后得到密文，将所述密文转换为二维码后发送给所述用户的终端设备显示；

所述验证设备具体用于，采用所述解密密钥获得所述密文中的校验数据、所述待验证信息和所述随机数；在预存的随机数中查找所述密文中的随机数；若未查找到，且所述校验数据和所述验证数据一致时，所述二维码验证通过；若查找到，则所述二维码验证失败。

进一步的，所述第一服务器，还用于：

提取指定时间段内的第一预设数量的时间点；

针对每个时间点执行：对该用户的待验证信息和该时间点采用基于时间的一次性密码算法进行加密生成校验数据，并对校验数据和所述待验证信息采用加密密钥进行加密后得到密文，将所述密文转换为二维码后与所述用户对应存储。

进一步的，所述第一服务器还用于，在接收到用户发送的获取多个二维码的请求后，获取存储的该用户的当前时间之后的第二预设数量的所述用户的二维码，并发送给所述用户的终端设备；

所述终端设备，还用于存储所述第二预设数量的时间点各自对应的二维码；在接收到显示存储的二维码的显示请求时，从存储的二维码中选择一个进行显示。

进一步的，所述终端设备还用于，在有效期内接收到第一数量的刷新当前显示的二维码的刷新请求时，从存储的二维码中获取距离当前显示的二维码的时间点最近的、且时间点在当前显示的二维码之后的二维码显示。

进一步的，所述终端设备还用于，在有效期内接收到第二数量的刷新当前显示的二维码的刷新请求时，发送的二维码刷新请求给所述第一服务器，所述第一数量小于所述第二数量。

进一步的，所述解密密钥为公钥、所述加密密钥为私钥。

第二方面，本申请实施例还提供一种扫码设备，包括处理器、存储器、二维码扫描装置和接口，其中：

所述接口用于接收第二服务器下发的解密密钥和一次性密码算法，其中，所解密密钥为公钥和私钥中用于解密的密钥；所述一次性密码算法为基于时间的一次性密码算法；

所述存储器用于存储所述解密密钥和所述一次性密码算法；

所述二维码扫描装置用于扫描终端设备显示的二维码；

所述处理器用于，提取所述二维码扫描装置扫描到的二维码中的密文，并采用所述解密密钥获得所述密文中的校验数据和所述待验证信息；采用所述一次性密码算法对所述待验证信息和当前时间进行加密得到验证数据；比对所述校验数据和所述验证数据是否一致；若一致则确定所述二维码验证通过，若不一致则确定所述二维码验证失败。

本申请实施例还提供一种服务器，包括：

处理器；以及

存储器，所述存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行以用于：

生成用户组的私钥和公钥，并确定该私钥和公钥中的加密密钥和解密密钥；

在接收到所述用户组的用户发送的二维码获取请求后，对该用户的待验证信息和当前时间采用基于时间的一次性密码算法进行加密生成校验数据；

对校验数据和所述待验证信息采用所述加密密钥进行加密后得到密文，将所述密文转换为二维码后发送给所述用户的终端设备显示；以及，

将所述解密密钥和所述一次性密码算法发送给所述用户组的验证设备。

本申请实施例提供的离线验证系统、扫码设备和服务器，通过对用户的待验证信息和当前时间基于一次性加密算法进行加密得到校验数据，该校验数据包含在发送给用户的二维码中，使得该二维码中携带了能够对自身进行验证的数据。这样，扫码设备一侧，可以通过扫描的二维码对其进行验证，而无需将扫描的二维码在线发送给验证服务器进行验证。故此，本申请实施例提供的扫码设备的离线验证。此外，一次性加密算法结合公私钥对加密密钥对校验数据和用户的信息进一步加密，从而保证了二维码的信息安全。故此，本申请实施例实现了既能够保证二维码信息安全，又能使扫码设备对二维码进行离线验证的技术方案。

本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例中的应用场景的示意图；

图2为本申请实施例提供的离线验证系统的结构示意图；

图3为本申请实施例提供的局域网设备和验证设备获取解密密钥以及加密算法的流程示意图；

图4为本申请实施例提供的扫码设备获得解密密钥和一次性加密算法的流程示意图；

图5为本申请实施例提供的扫码设备进行验证的流程示意图；

图6为本申请实施例提供的以内网服务器作为第二服务器进行验证的流程示意图；

图7为本申请实施例提供的用户根据自己需求请求指定时间段内的二维码的界面示意图；

图8为本申请实施例提供的待验证信息的加密方法的流程示意图；

图9为本申请实施例提供的待验证信息的验证方法的流程示意图；

图10为本申请实施例提供的以学生的身份数据为例进行加密的流程示意图；

图11为本申请实施例提供的以学生的身份数据为例进行解密验证的流程示意图；

图12a为本申请实施例提供的扫码设备的结构示意图；

图12b为本申请实施例提供的一种扫码设备的一个界面示意图；

图13为本申请实施例提供的待验证信息的加密装置的结构示意图；

图14为本申请实施例提供的待验证信息的验证装置的结构示意图；

图15为根据本申请实施方式的计算装置的结构示意图。

具体实施方式

为了提供一种验证设备侧离线也能完成信息验证的方案，本申请实施例提供了离线验证系统、扫码设备和服务器。

为便于理解本申请实施例提供的技术方案，这里先对本申请实施例使用的一些关键名词进行解释：

基于时间的一次性密码算法：该算法对于同一时间步长内的任一时间点，进行加密运算后的结果是相同的。例如，时间步长为5分钟，则使用该加密算法对于2018年1月2日上午9:01的计算结果和对2018年1月2日上午9:02分的计算结果是一样的。

公钥(publickey)与私钥(privatekey)：公钥和私钥是通过一种算法得到的一个密钥对(即一个公钥和一个私钥)。通常，公钥是密钥对外公开的部分，私钥则是非公开的部分。通过这种算法得到的密钥对能保证在世界范围内是唯一的。使用这个密钥对的时候，如果用其中一个密钥加密一段数据，必须用对应的另一个密钥解密。比如用公钥加密数据就必须用私钥解密，如果用私钥加密也必须用公钥解密，否则解密将不会成功。

pkcs#1：pcks(thepublic-keycryptographystandards)是由美国rsa数据安全公司及其合作伙伴制定的一组公钥密码学标准，其中包括证书申请、证书更新、证书作废表发布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议。其中，pkcs#1：定义rsa公开密钥算法加密和签名机制，主要用于组织pkcs#7中所描述的数字签名和数字信封。

以下结合说明书附图对本申请的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本申请，并不用于限定本申请，并且在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

如图1所示，其为通过本申请实施例提供的方案来完成二维码校验的场景示意图。需要说明的是，在该场景中扫码设备可以实现离线认证。具体的，如图1所示，该场景中包括用户10的终端设备11、服务器12和扫码设备13。服务器12和扫码设备13存储相同的基于时间的一次性密码算法，并可以拥有一对公私钥。其中，服务器存储该对公私钥对中的加密密钥，扫码设备存储相应的解密密钥。加密时，服务器首先利用一次性密码算法对用户10的信息和当前时间进行加密得到校验数据，再通过加密密钥对校验数据和用户10的信息加密后得到加密后的二维码。其中，需要注意的是，通过该方法使得二维码中携带能够对自身进行验证的校验数据。

用户10通过终端设备11访问服务器12，以此来获取经过加密的二维码后进行显示。扫码设备扫码二维码后根据存储的解密密钥、校验数据和用户10的信息，之后再采用一次性密码算法对当前时间和得到的用户10的信息采用相同的一次性密码算法加密后得到验证数据。根据前述一次性密码算法的特点，其对同一时间步长内的相同信息的加密结果是一样的。所以，原则上若该二维码是准确有效的，那么验证数据和校验数据将一致，否则二者不一致。由此可推知，对于扫码设备而言，若验证数据和校验数据一致则二维码验证通过，否则验证失败。

由此，扫码设备仅根据存储的解密密钥和一次性密码算法便能够对二维码进行验证，而无需通过在线的方式，将二维码发送给服务器12进行验证。这样，便实现了扫码设备13的离线验证。

具体实施时，为实现图1示例的离线验证，如何进行网络架构的系统布局，下面将结合图2对此进行详细说明。而在此之前，需要说明的是，图1中的终端设备11，可以为手机，平板电脑等能够显示二维码的设备。终端设备11可以通过自身安装客户端访问服务器12获取二维码、也可以通过客户端中的小程序甚至短消息来获取二维码，任何能够获取二维码的方式均适用图1所示的应用场景，本申请对此不作限定。

此外，终端设备11与服务器12之间通过网络进行通信连接，该网络可以为局域网、蜂窝网和广域网等。

当然，需要验证的不仅限于图1举例的二维码，还可以是其他需要验证的信息，例如指纹认证、公司签到所用的需要进行验证的信息等，均适用本申请实施例。

接下来，参考图2，对本申请实施例提供的离线验证系统进行详细说明。

如图2所示，其为本申请实施例提供的离线验证系统的结构示意图，该系统可以包括第一服务器21、终端设备22、验证设备23，其中：

所述第一服务器21，用于生成用户组的私钥和公钥，并确定该私钥和公钥中的加密密钥和解密密钥；并在接收到该用户组中的用户发送的二维码获取请求后，对该用户的待验证信息和当前时间采用基于时间的一次性密码算法进行加密生成校验数据，并对校验数据和所述待验证信息采用加密密钥进行加密后得到密文，将所述密文转换为二维码后发送给所述用户的终端设备22显示；以及，将所述解密密钥和所述一次性密码算法发送给所述用户组的验证设备23；

这里，需要说明的是，用户组为由多个用户构成的集合。这样，一组用户可以共享一对公私钥对，具体的将在后文中进行详述，这里暂不赘述。

所述验证设备23，用于接收所述用户组的解密密钥和所述一次性密码算法并存储；并在扫描所述终端设备显示的所述二维码后，提取所述二维码中的密文，并采用所述解密密钥获得所述密文中的校验数据和所述待验证信息；采用所述一次性密码算法对所述待验证信息和当前时间进行加密得到验证数据；比对所述校验数据和所述验证数据是否一致；若一致则验证通过，若不一致则验证失败。

这样，该系统可以基于公私钥对实现对二维码的离线验证。需要验证的二维码的相关业务将不再受在线的限制。

其中，在一个实施例中，所述验证设备包括第二服务器和扫码设备，所述第二服务器与所述第一服务器通信，所述扫码设备和所述第二服务器通信。此外，第一服务器发送的解密密钥和一次性密码算法可以存储在第二服务器和/或扫码设备中。具体的，参见图3，以外网服务器作为第一服务器、内网服务器作为第二服务器为例，对本申请实施例中局域网设备和验证设备获取解密密钥以及加密算法的过程进行说明，在图3中：

第一服务器，可以是外网服务器，为互联网或者其他能够支持大范围网络设备且需要在线通信的服务器。其在接收到用户组发送的密钥对生成请求后，生成该用户组的公钥和私钥，并确定其中的加密密钥和解密密钥，第一服务器自身存储加密密钥存储，并发送解密密钥和一次性密码算法给该用户组的第二服务器。

其中，可以采用rsa(ronrivest，adishamir,leonardadieman)算法生成密钥对。为了保证信息安全，可以将公钥设为加密密钥、私钥设为解密密钥，当然也可以将私钥设为机密没有、公钥设为解密密钥。对于一次性密码算法，具体实施时，其可以为以下算法中的任一种：

hotp(hmac-basedone-timepassword，基于hmac的一次性口令)。

totp(time-basedone-timepassword，基于时间的一次性口令)。

hmac(hash-basedmessageauthenticationcode，基于散列函数的消息认证码算法)。

第二服务器，接收并保存解密密钥和加密算法。

其中，第二服务器可以为局域网(localareanetwork，lan)服务器。局域网是在一个局部的地理范围内(如一个学校、工厂和机关内)，一般是方圆几千米以内，将各种计算机，外部设备和数据库等互相联接起来组成的计算机通信网。它可以通过数据通信网或专用数据电路，与远方的第一服务器连接，构成一个较大范围的信息处理系统。局域网可以实现文件管理、应用软件共享、打印机共享、扫描仪共享、工作组内的日程安排、电子邮件和传真通信服务等功能。即使局域网服务器不能与第一服务器通信，局域网内部的设备也能进行数据传输和访问。

如果需要扫码设备自行对二维码进行验证，则可以由内网服务器将加密密钥和加密算法下发给扫码设备(如图3中虚线所示)。

在验证二维码时，可以根据解密密钥和一次性密码算法的存储位置采用如下相应的方案进行验证：

方案一、解密密钥和一次性密码算法仅存储在内网服务器中时，如图4所示：

终端设备向外网服务器请求获取二维码并显示；且内网服务器可以接收所述外网服务器发送的所述用户组的解密密钥和所述一次性密码算法并存储。

扫码设备，可扫描所述终端设备显示的所述二维码后，将二维码的扫描信息发送给所述内网服务器进行验证。

方式二、解密密钥和一次性密码算法存储在扫码设备中时，如图5所示(前面获取二维码和存储加密密钥及加密算法的操作可参见图5，这里不再赘述)。这里仅说明第二服务器接收所述第一服务器发送的所述用户组的解密密钥和所述一次性密码算法并存储后，发送给所述扫码设备；由扫码设备扫描所述终端设备显示的所述二维码后，根据自身存储的解密密钥和所述一次性密码算法对所述二维码进行验证。

此外，在此进一步说明用户组。用户组是一种和第一服务器交互时的身份。具体实施时，可以通过客户端或者小程序以用户组的身份和第一服务器进行通信。该身份可以在第一服务器中预先注册。例如a学校或b企业以各自的企业的身份在第一服务器中注册自己的分组、甚至某一区域内的用户可以联盟申请一个用户组身份。以a学校为例，可以通过终端设备11以a学校的身份向第一服务器申请a学校的密钥对。这样，a学校的学生则成为a学校这一用户组下的用户，且a学校的学生将共用a学校的密钥对对自身的信息进行加密。

为了保证解密密钥的安全性，解码密钥和一次性密码算法应采用https(hypertexttransferprotocoloversecuresocketlayer，网络协议)等安全方式进行传输，来规避传输途径中被窃听的风险。

进一步的，为了提高信息安全性，避免因为密钥泄露带来的信息安全隐患，本申请实施例中，用户组的密钥对可以具有生命周期。恶意破解密钥是需要时间的，在周期性刷新用户组的密钥对的情况下，即使密钥泄露，泄露的密钥也会因为生命周期的到来而失效。失效的密钥将失去其作用，所以用户信息还是安全的。为周期性更新密钥对，所述第一服务器还用于，对所述用户组的一对公钥和私钥进行计时；当计时到预设的生命周期或接收到密钥更新指令时，重新生成一对新的公钥和私钥；根据新的公钥和私钥，更新该分组对应的加密密钥和所述验证设备中的解密密钥。

具体实施时，为了更新密钥，可以在第一服务器中部署用于更新密钥的接口，第二服务器和/或扫码设备都可以访问该接口。此外，下一生命周期的解密密钥可以记录在该接口中，便于第二服务器和/或扫码设备获取。

为了能够保证验证业务的正常进行，应该避免频繁刷新密钥。例如，刷新密钥的周期为24小时时，第二服务器和扫码设备能够离线时长24小时。具体刷新频率，可以根据实际需求设定，例如不同用户组的密钥对可以有不同的生命周期，以此来满足不同用户组的需求。

其中，为了应对密钥对刷新可能导致第二服务器和/扫码设备中的解密密钥没能及时更新，导致加密的二维码无法解密的情况，可采用以下方案进行解决，具体的：

所述第一服务器还用于，生成所述用户组的下一生命周期的公钥和私钥，并将下一生命周期的解密密钥发送给所述第二服务器；

所述第二服务器还用于，更新解密密钥得到当前生命周期的解密密钥后存储，并存储所述用户组的上一生命周期和下一生命周期的解密密钥。

这样，第二服务器和/或扫码设备上相当于能够存储当前生命周期、上一生命周期和下一生命周期这三个周期的解密密钥。第二服务器或所述扫码设备，在对所述二维码进行认证时则可以采用当前生命周期的解密密钥解密所述密文中的校验数据和所述待验证信息；若解密失败，则采用上一生命周期的解密密钥和/或下一生命周期的解密密钥解密所述密文中的校验数据和所述待验证信息。这样，认证二维码的设备(如第二服务器或扫码设备)即使和第一服务器密钥不同步，也可以实现验证。

如果存储多个生命周期的解密密钥时，解密密钥有效期为24小时，则验证设备可以离线24～48小时(视断线时间)。这样，验证设备不仅仅可以实现离线验证，在非计划断网的情况下，也为网络修复提供了充足时间，而不影响验证业务的进行。

此外，由于二维码采用当前时间进行加密，为了应对第一服务器和验证设备时间不同步带来的验证误差或者密钥无法更新的问题，本申请实施例中可以设置二维码的有效期来克服这一问题。例如该有效期可以为2分钟，能够充分容纳双方时间不同步的误差。

进一步的，当验证设备一侧的用户发现验证设备被盗、解密密钥泄露等问题时，可以紧急通知第一服务器的管理员。这样，管理员可以及时发送更新指令，快速更新密钥对，来尽可能的减少信息泄露造成的损失。

具体实施时，如果一个二维码允许多次校验，则容易导致用户信息泄露或者使用户遭受损失。例如，其他用户可以用盗取的二维码完成支付，使被盗取二维码的用户蒙受损失。所以，本申请实施例中，为了保护用户的信息和用户的利益，一个二维码仅允许验证一次。为此，所述第一服务器可在接收到用户发送的二维码请求后，生成随机数，并对该用户的待验证信息和当前时间采用基于时间的一次性密码算法进行加密生成校验数据，并对校验数据、所述待验证信息和所述随机数采用加密密钥进行加密后得到密文，将所述密文转换为二维码后发送给所述用户的终端设备显示。当所述验证设备进行验证时，采用所述解密密钥获得所述密文中的校验数据、所述待验证信息和所述随机数；在预存的随机数中查找所述密文中的随机数；若未查找到，且所述校验数据和所述验证数据一致时，所述二维码验证通过；若查找到，则所述二维码验证失败。

这样，即使同一用户，其多次请求二维码时，由于针对不同请求获取的二维码中的随机数和加密时的当前时间是不同的，所以不同请求对应不同的二维码。对于验证设备而言，每个验证过的二维码的随机数都可以存储，当验证时，只要待验证的二维码的随机数包含在存储的随机数中，则表示该二维码被验证过，则可以确定已被使用过，进而直接确定二维码验证失败。

当然，具体实施时，可以存储一定时长内的随机数。例如存储最近两天或最近24小时的二维码的随机数。这样，可以将过期的随机数删除来释放存储资源。此外，存储的随机数的多少也一定程度上决定了查找待验证的二维码中的随机数的效率，所以，存储一定时长内的随机数也可以提高二维码的验证效率。

其中，在一个实施例中，所述第一服务器，还可用于提取指定时间段内的第一预设数量的时间点；可以在每个时间步长内提取设定数量的时间点。例如，时间步长为5分钟，则从当前时间9:00开始每5分钟提取一个时间点。

基于提取的时间点，针对每个时间点：对该用户的待验证信息和该时间点采用基于时间的一次性密码算法进行加密生成校验数据，并对校验数据和所述待验证信息采用加密密钥进行加密后得到密文，将所述密文转换为二维码后与所述用户对应存储。

这样，在接收到用户的二维码获取请求时，可以从存储的二维码中获取相应时段的二维码发送给用户。例如，相应时段可以为与获取请求的发送时间在同一时间步长内的时段。

此外，基于存储了不同时间点的二维码，在验证设备离线的情况下，终端设备也可以离线。具体的，所述第一服务器还用于，在接收到用户发送的获取多个二维码的请求后，获取存储的该用户的当前时间之后的第二预设数量的所述用户的二维码，并发送给所述用户的终端设备；

所述终端设备，则可以存储所述第二预设数量的时间点各自对应的二维码；并在接收到显示存储的二维码的显示请求时，从存储的二维码中选择一个进行显示。

具体实施时，优先选择未曾显示的且时间点最早的二维码进行显示。例如，存储了5个二维码，按时间先后，分别为s1、s2、s3、s4、s5。第一次支付时，可以显示s1、第二次支付则显示s2，以此类推。

如图6所示，为客户端(安装在终端设备中)离线时二维码验证过程的示意图，其中：

客户端，通过终端设备从第一服务器获取多个二维码进行缓存。

第二服务器从第一服务器获取到解密密钥和一次性密码算法进行存储。

扫码设备扫描客户端显示的二维码后，发送给第二服务器进行验证。

第二服务器在验证后将验证结果发送给扫码设备。

当然，具体实施时，二维码可以按照时间先后排序，各二维码一经显示后，可以从存储空间中删除。继续上面的例子，s1显示后则删除，第二次支付时则可以直接获取排序第一的s2进行显示。具体实施时，可以在确定显示的二维码完成验证后删除，也可以在二维码显示预设显示时长后删除。该预设显示时长可以根据经验值确定。预设显示时长用于表示二维码经被验证设备验证过所需的时长。

进一步的，有可能当前显示的二维码可能无法完成验证，则用户可以刷新显示的二维码。具体的，所述终端设备还用于，在有效期内接收到第一数量的刷新当前显示的二维码的刷新请求时，从存储的二维码中获取距离当前显示的二维码的时间点最近的、且时间点在当前显示的二维码之后的二维码显示。例如，继续上面的例子，当前显示的为s2，则刷新后获取s3进行显示。

具体实施时，二维码中的使用一次性密码算法加密的时间点无法直接获取，所以第一服务器发送多个时间点的二维码时可以对发送的二维码按照时间点的先后顺序打上标记。这样，终端设备可以根据该标记确定二维码的获取顺序。具体打标记和识别标记的方法，可以由第一服务器和终端设备协商确定，本申请实施例对此不做赘述。

此外，需要说明的是，前述的有效期为设定的一段时长。一个有效期过后，重新计算有效期。具体实施时，有效期可以根据经验值确定，例如可以设置为2秒。若2秒内，用户请求刷新二维码，则获取新的二维码显示。

此外，在一个实施例中，由于一次性密码算法需要同一时间步长内的二维码才能通过验证，为避免生成和验证二维码不在同一时间步长内导致验证失败，还可以优先使用在线获取的二维码进行验证。这样，终端设备还用于在有效期内接收到第二数量的刷新当前显示的二维码的刷新请求时，发送二维码刷新请求给所述第一服务器，所述第一数量小于所述第二数量。由于第一数量小于第二数量，说明在接收到第二数量的刷新请求时，有可能用户存储的二维码都已验证失败或失效。所以从第一服务器获取二维码。这样，对于用户来说，二维码的获取途径不仅可以多样化，来方便用户使用二维码，还能更好的保证用户能够顺利使用二维码进行相关的业务。

此外，因为在线获取二维码需要第一服务器进行加密运算，为了合理的利用第一服务器的处理资源，同一用户的刷新频率不应过高。所以，为了节约第一服务器的处理资源，本申请实施例提供以下两种方案：

方案一、第一服务器接收到用户的二维码的刷新请求后，开始计时，在指定的刷新时长内再次接收到所述用户的二维码刷新请求后，将该刷新请求丢弃。也即第一服务器不会处理再次接收到的二维码刷新请求。例如，第一服务器接收到用户a的二维码刷新请求，在之后的2秒内(即指定的刷新时长)，则生成新的二维码返回给用户，若在这2秒内再接收到该用户a的刷新请求将不予处理。

方案二、终端设备第一次检测到刷新二维码的刷新操作后，开始计时并生成二维码的刷新请求给第一服务器，在计时的指定的刷新时长内，若再次检测到刷新二维码的刷新操作，则丢弃检测到的该信息，也即不会生成二维码刷新请求。

此外，若发送刷新请求给第一服务器，在指定的反馈时长内(如4秒)没有收到第一服务器的响应，则可以继续从存储的二维码中获取未显示的二维码进行显示验证。若发送刷新请求给第一服务器，且得到第一服务器反馈的新的二维码，则用新的二维码替换存储的所有二维码，以此实现优先使用在线获取的二维码。

当然，为便于用户使用离线的二维码，用户还可以按照自己的需求向第一服务器请求指定时间段的二维码。例如，如果用户的二维码使用情况比较有规律。例如上班族，午饭时间段内用二维码消费，上下班乘车时间都是比较有规律的。为了节约用户的网络流量，或避免用户在离线或网络状态差的情况下无法及时获取到二维码。则用户可以参照如图7所示的界面，提前向第一服务器获取二维码。在图7中，用户可以根据自己的计划和实际需要向第一服务器提前申请二维码并下载下来。第一服务器接收到用户发送的获取请求时间段内的二维码请求后，从请求的时间段提取多个时间点，并针对每个时间点根据一次性密码算法和加密密钥生成二维码并返回给用户，其中，针对每个二维码，返回给用户时标注该二维码对应的时间段，以便于用户了解该二维码能在何时使用。相应的，为了便于用户能够在请求的时间段使用二维码进行验证时，第一服务器还要确认用户请求的时间段内的密钥对是否更新，如果需要更新，则预先将密钥对更新后并将更新后的解密密钥提前发送给验证设备存储，并告知验证设备该解密密钥的生效时间，这样验证设备可以根据解密密钥的生效时间确定使用哪个解密密钥进行验证。

此外，本申请实施例中，为了应对特殊情况，第一服务器也可以配置有全网通用的解密验证接口，用于实现在线验证。

基于相同的发明构思，本申请实施例还提供一种待验证信息的加密方法，以上系统仅对二维码进行举例说明，该方法对使用的信息进行扩展，也即该方法是适用于任何需要验证的信息的。如图8所示，为该方法的流程图，包括以下步骤：

步骤801：对待验证信息和当前时间采用基于时间的一次性密码算法进行加密，得到校验数据。

步骤802：对校验数据和所述待验证信息采用加密密钥进行加密并得到密文，其中，所述加密密钥为一对公钥和私钥中的用于加密的密钥。

这样，通过加密密钥和一次性密码算法结合，使得待验证信息的密文中包括了能够验证自身身份的校验数据。这样，对于校验该待验证信息的设备而言，无需在线将待验证信息发送给验证服务器进行验证，仅根据校验数据既可以实现离线验证。

其中，在一个实施例中，对于同一待验证信息而言，加密时的时间不同，得到的校验数据可能会有差别。所以，同一待验证信息，会根据加密的时间产生出不同的密文。为了使得同一个密文只允许校验一次，本申请实施例中，在对校验数据和所述待验证信息采用加密密钥进行加密并得到密文之前，还可以生成随机数；然后，加密时对校验数据、所述待验证信息和所述随机数采用加密密钥进行加密，得到密文。如前所述，该随机数能够用于在对待验证信息进行验证时，来判断该待验证信息的该次密文是否已经被校验过。

对于普通用户而言，一个用户对应一套密钥对。但是随着用户数量的增多，密钥对的数量会增多，会对生成和管理密钥对带来负担。故此，具体实施时，为了简化对密钥对的管理，本申请实施例中，可以预先对作为待验证信息的信息进行分组；并，针对每个分组，根据非对称加密算法生成该分组对应的一对公钥和私钥；将该对公钥和私钥中的一个确定为加密密钥，另一个确定为解密密钥；然后将加密密钥和该分组对应存储。

这样，一个用户组才对应一套密钥对，密钥对的数量会大大减少，便于管理。以学校为例，如果校内每个学生的信息对应一套密钥对，那么一个学校有成千上万的学生，对于该学校要管理成千上万的密钥对。但是如果该学校作为一个分组，仅为该学校分配一个密钥对，那么密钥对的数量将大大降低。这样，述对校验数据和所述待验证信息采用加密密钥进行加密时，则实施为对校验数据和所述待验证信息采用所述待验证信息所在分组对应的加密密钥进行加密，得到密文。

为了便于验证设备能够离线验证，针对每个分组，在根据非对称加密算法生成该分组对应的一对公钥和私钥之后，则将解密密钥发送给该分组预设的验证设备。此外，为了能够防止密钥泄露、窃取导致的信息不安全，本申请实施例中，针对每个分组，对该分组对应的一对公钥和私钥进行计时；当计时到预设的生命周期或接收到密钥更新指令时，重新生成一对新的公钥和私钥；根据新的公钥和私钥，更新该分组对应的加密密钥和所述验证设备中的解密密钥。

这样，如前所述，由于定期更新密钥对，即使密钥泄露或被窃取了，当密钥对更新后，用户的待验证信息依然能够得到保护。

其中，在一个实施例中，固定的密钥能够加密的字节数是有限的，所以具体实施时，可以根据具体的应用场景选取适合长度的密钥。通常针对校园二维码、乘车用的二维码、企业员工签到的二维码等等场景，以rsa算法生成密钥对时，可以主要选取512位、768位或1024位长度的公私钥对。根据rsa的实现原理，由于pkcs#1默认填充字节为11个字节，768位秘钥最多能加密768/8-11＝85个字节，1024位长度的秘钥可以加密1024/8-11＝117个字节。超出固定长度就需要增加秘钥长度或者对原文进行分片循环加密。具体的，分片循环加密可以根据以下方法实现：

在对待验证信息和当前时间采用基于时间的一次性密码算法进行加密，并且在得到校验数据之前，确定待验证信息的字节数是否超过单次加密的最长字节数。若没有，则对待验证信息和当前时间采用基于时间的一次性密码算法进行加密。若超过单次机密的最长字节数，则对所述待验证信息进行分片，按照各分片的在待验证信息中的顺序确定各分片的标记；对每个分片和当前时间采用基于时间的一次性密码算法进行加密，得到各分片的校验数据；对各分片的校验数据采用加密密钥进行加密，得到各分片的密文；根据各分片的标记，确定各分片的密文的顺序，按照确定的顺序组合各分片的密文得到所述待验证信息的密文。

这样，待验证信息字节数过多时，通过分片加密也能够实现验证设备的离线验证。

基于相同的发明构思，与前述加密方法相应，本申请实施例还提供一种加密信息的验证方法，如图9所示，该方法包括以下步骤：

步骤901：获取待验证信息的密文。

步骤902：根据解密密钥对所述密文进行解密，得到所述密文中的校验数据和待验证信息；所述解密密钥与加密所述待验证信息所用的加密密钥组合为一对公钥和私钥。

步骤903：对当前时间和所述密文中的待验证信息采用密码算法进行加密，得到验证数据；所述密码算法与用于加密所述待验证信息所用的基于时间的一次性密码算法相同。

步骤904：比对所述验证数据和所述密文中的校验数据。

步骤905：若所述验证数据和解密获得的校验数据相同，确定所述待验证信息验证通过。

当然，具体实施时，若所述验证数据和解密获得的校验数据不相同，确定所述待验证信息验证失败。

其中，在一个实施例中，所述解密密钥为按照以下流程获取的：

接收加密设备下发的解密密钥，或者，接收验证设备下发的解密密钥更新请求，并根据所述更新请求中的解密密钥更新存储的解密密钥。

其中，加密设备例如是前述的第一服务器。

进一步的，如前所述，利用随机数来实现加密后的待验证信息仅能使用一次，本申请实施例中解密后的所述密文中还包括随机数。故此，在确定所述待验证信息验证通过之前，需要确定在预存的随机数中未查找到所述密文中的随机数，其中预存的随机数为在指定时长内解密其它密文获得的随机数；当所述验证数据和解密获得的校验数据不相同，和/或，在预存的随机数中查找到所述密文中的随机数，则验证失败。也就是说，在比对验证数据和校验数据之前，若在预存的随机数中查找到所述密文中的随机数时，无论比对结果如何都认为验证失败。只有在在预存的随机数中未查找到所述密文中的随机数，且验证数据和校验数据比对结果一致时才认为验证通过。

进一步的，当存在前述的分片加密时，在根据预存的解密密钥对所述密文进行解密之前，应该首先确定所述待验证信息的密文中是否含有分片标记。若不含有分片标记，则直接根据预存的解密密钥对所述密文进行解密。若含有分片标记，则可以获取其中一个分片的密文来验证，具体的：

根据所述解密密钥对该分片的密文进行解密，得到该分片的校验数据和分片数据；采用预采用基于时间的一次性密码算法对当前时间和所述分片数据进行加密，得到分片的验证数据；比对该分片的验证数据和该分片的密文中的校验数据；若该分片的验证数据和该分片的密文中的校验数据相同，确定所述待验证信息验证通过；否则，确定所述待验证信息验证失败。

综上所述，本申请实施例中，采用解密密钥和基于时间的一次性密码算法即可实现验证设备端对待验证信息的离线验证。保证了验证设备业务的正常进行。

以校园码为例，对本申请实施例中离线验证的方案做进一步说明。

如图10所示，待验证信息为学生的身份数据例如学号，基于时间的一次性密码算法为totp算法。杂项数据可以为前述的随机数，或者具体实施时也可以包含其他数据，只要能够验证待验证信息被验证过即可。在加密时，对学生的身份数据和当前时间采用totp算法进行加密生成totp校验数据，然后将学生的身份数据、totp校验数据以及杂项数据作为原始数据，并采用非对称加密的私钥进行加密，得到密文。为了便于传输，再进行base64的转换后得到密文base64。

如图11所示，为解密的过程，对密文base64先进行base64转换后得到密文原文。然后采用非对称加密的公钥进行解密得到原始数据。该原始数据中包括身份数据、totp校验数据1和杂项数据。然后解密段根据totp算法对当前时间和身份数据进行加密，得到totp校验数据2(即验证数据)。将totp校验数据2和totp校验数据1进行比对，若二者一致，则验证通过。

此外，基于相同的发明构思，本申请实施例还提供一种离线扫码设备，如图12a所示，为扫描设备的结构示意图，包括处理器1201、存储器1202、二维码扫描装置1203和接口1204，其中：

所述接口1204用于接收第二服务器下发的解密密钥和一次性密码算法，其中，所解密密钥为公钥和私钥中用于解密的密钥；所述一次性密码算法为基于时间的一次性密码算法；

所述存储器1202用于存储所述解密密钥和所述一次性密码算法；

所述二维码扫描装置1203用于扫描终端设备显示的二维码；

所述处理器1201用于提取所述二维码扫描装置扫描到的二维码中的密文，并采用所述解密密钥获得所述密文中的校验数据和所述待验证信息；采用所述一次性密码算法对所述待验证信息和当前时间进行加密得到验证数据；比对所述校验数据和所述验证数据是否一致；若一致则确定所述二维码验证通过，若不一致则确定所述二维码验证失败。

如图12b所示，为一种扫码设备的界面示意图。在该扫码界面中可以通过扫一扫功能扫码二维码。当然，具体实施时，该扫码设备可以没有显示界面，而是普通的扫码器，例如可以利用图像采集设备和光学成像设备对二维码进行采集的扫码器。

与本申请实施例提供的待验证信息的加密方法对应的，本申请实施例还提供一种待验证信息的加密装置，如图13所示，该装置包括：

校验数据确定模块1301，用于对待验证信息和当前时间采用基于时间的一次性密码算法进行加密，得到校验数据；

密文确定模块1302，用于对校验数据和所述待验证信息采用加密密钥进行加密并得到密文，其中，所述加密密钥为一对公钥和私钥中的用于加密的密钥。

其中在一个实施例中，，所述装置还包括：

随机数生成模块，用于在校验数据确定模块1301，对校验数据和所述待验证信息采用加密密钥进行加密并得到密文之前，生成随机数；

所述密文确定模块，具体用于对校验数据、所述待验证信息和所述随机数采用所述加密密钥进行加密。

其中，在一个实施例中，所述装置还包括：

分组模块，用于在校验数据确定模块对待验证信息和当前时间采用基于时间的一次性密码算法进行加密，得到校验数据之前，对作为待验证信息的信息进行分组；

密钥对生成模块，用于针对每个分组，根据非对称加密算法生成该分组对应的一对公钥和私钥；

加解密钥确定模块，用于将该对公钥和私钥中的一个确定为加密密钥，另一个确定为解密密钥；

加密密钥存储模块，用于将加密密钥和该分组对应存储；

所述密文确定模块，具体用于对校验数据和所述待验证信息采用所述待验证信息所在分组对应的加密密钥进行加密，得到所述密文。

其中，在一个实施例中，所述装置还包括：

解密密钥分发模块，用于在密钥对生成模块根据非对称加密算法生成该分组对应的一对公钥和私钥之后，将解密密钥发送给该分组预设的验证设备；

计时模块，用于针对每个分组，对该分组对应的一对公钥和私钥进行计时；

密钥更新模块，用于当计时到预设的生命周期或接收到密钥更新指令时，重新生成一对新的公钥和私钥；

验证设备密钥更新模块，用于根据新的公钥和私钥，更新该分组对应的加密密钥和所述验证设备中的解密密钥。

其中，在一个实施例中，所述装置还包括：

字节数确定模块，用于在校验数据确定模块对待验证信息和当前时间采用基于时间的一次性密码算法进行加密，并且在得到校验数据之前，确定待验证信息的字节数未超过单次加密的最长字节数。

其中，在一个实施例中，所述装置还包括：

分片模块，用于若字节数确定模块确定所述待验证数据的字节数超过单次加密的最长字节数，对所述待验证信息进行分片，按照各分片的在待验证信息中的顺序确定各分片的标记；

分片加密模块，用于对每个分片和当前时间采用基于时间的一次性密码算法进行加密，得到各分片的校验数据；对各分片的校验数据采用加密密钥进行加密，得到各分片的密文；根据各分片的标记，确定各分片的密文的顺序，按照确定的顺序组合各分片的密文得到所述待验证信息的密文。

与本申请实施例提供的待验证信息的验证方法对应的，本申请实施例还提供一种待验证信息的验证装置，如图14所示，该装置包括：

密文获取模块1401，用于获取待验证信息的密文；

解密模块1402，用于根据解密密钥对所述密文进行解密，得到所述密文中的校验数据和待验证信息；所述解密密钥与加密所述待验证信息所用的加密密钥组合为一对公钥和私钥；

加密模块1403，用于对当前时间和所述密文中的待验证信息采用密码算法进行加密，得到验证数据；所述密码算法与用于加密所述待验证信息所用的基于时间的一次性密码算法相同；

比对模块1404，用于比对所述验证数据和所述密文中的校验数据；

验证模块1405，用于若所述验证数据和解密获得的校验数据相同，确定所述待验证信息验证通过。

否则，若所述验证数据和解密获得的校验数据不相同，确定所述待验证信息验证失败。

其中，在一个实施例中，所述装置还包括：

密钥获取模块，用于接收加密设备下发的解密密钥，或者，接收加密设备下发的解密密钥更新请求，并根据所述更新请求中的解密密钥更新存储的解密密钥。

其中，在一个实施例中，解密后的所述密文中还包括随机数；所述装置还包括：

随机数处理模块，用于在验证模块确定所述待验证信息验证通过之前，确定在预存的随机数中未查找到所述密文中的随机数，其中预存的随机数为在指定时长内解密其它密文获得的随机数；

验证模块，具体用于若所述验证数据和解密获得的校验数据不相同，和/或，在预存的随机数中查找到所述密文中的随机数，则验证失败。

其中，在一个实施例中，所述装置还包括：

分片密文获取模块，用于若确定所述待验证信息的密文中包含分片标记，则获取其中一个分片的密文；

分片解密模块，用于根据预存的所述解密密钥对该分片的密文进行解密，得到该分片的校验数据和分片数据；

分片加密模块，用于采用基于时间的一次性密码算法对当前时间和所述分片数据进行加密，得到分片的验证数据；

分片比对模块，用于比对该分片的验证数据和该分片的密文中的校验数据；

分片验证模块，用于若该分片的验证数据和该分片的密文中的校验数据相同，确定所述待验证信息验证通过；否则，确定所述待验证信息验证失败。

为了描述的方便，以上各部分按照功能划分为各模块(或单元)分别描述。当然，在实施本申请时可以把各模块(或单元)的功能在同一个或多个软件或硬件中实现。

在介绍了本申请示例性实施方式的待验证信息的加密和验证方法和装置之后，接下来，介绍根据本申请的另一示例性实施方式的计算装置。

所属技术领域的技术人员能够理解，本申请的各个方面可以实现为系统、方法或程序产品。因此，本申请的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

在一些可能的实施方式中，根据本申请的计算装置可以至少包括至少一个处理器、以及至少一个存储器(如前述的第一服务器)。其中，所述存储器存储有程序代码，当所述程序代码被所述处理器执行时，使得所述处理器执行本说明书上述描述的根据本申请各种示例性实施方式的系统权限开启方法中的步骤。例如，所述处理器可以执行如图8中所示的步骤801-802、或者图9所示的步骤901-905。

下面参照图15来描述根据本申请的这种实施方式的计算装置150。图15显示的计算装置150仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图15所示，计算装置150以通用计算设备的形式表现。计算装置150的组件可以包括但不限于：上述至少一个处理器151、上述至少一个存储器152、连接不同系统组件(包括存储器152和处理器151)的总线153。

总线153表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器、外围总线、处理器或者使用多种总线结构中的任意总线结构的局域总线。

存储器152可以包括易失性存储器形式的可读介质，例如随机存取存储器(ram)1521和/或高速缓存存储器1522，还可以进一步包括只读存储器(rom)1523。

存储器152还可以包括具有一组(至少一个)程序模块1524的程序/实用工具1525，这样的程序模块1524包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

计算装置150也可以与一个或多个外部设备154(例如键盘、指向设备等)通信，还可与一个或者多个使得用户能与计算装置150交互的设备通信，和/或与使得该计算装置150能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口155进行。并且，计算装置150还可以通过网络适配器156与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器156通过总线153与用于计算装置150的其它模块通信。应当理解，尽管图中未示出，可以结合计算装置150使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。

在一些可能的实施方式中，本申请提供的待验证信息的加密和/或验证方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在计算机设备上运行时，所述程序代码用于使所述计算机设备执行本说明书上述描述的根据本申请各种示例性实施方式的待验证信息的加密方法和/或待验证信息的验证方法中的步骤，例如，所述计算机设备可以执行如图8中所示的步骤801-802，和/或，图9中所示的步骤901-905。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。

本申请的实施方式的用于系统权限开启的程序产品可以采用便携式紧凑盘只读存储器(cd-rom)并包括程序代码，并可以在计算设备上运行。然而，本申请的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于——无线、有线、光缆、rf等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、c++等，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络——包括局域网(lan)或广域网(wan)—连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。