CN111062059A - 用于业务处理的方法和装置 - Google Patents

Abstract

本说明书的实施例提供了用于业务处理的方法、服务器、客户端设备、计算设备和机器可读存储介质。该方法可以包括：接收业务信息和针对业务信息的签名信息，其中，业务信息是由客户端设备生成的，签名信息是客户端设备调用安全元件(Security Element，SE)模块来生成的，SE模块已经被注册到服务器；对签名信息进行验证，以确认客户端设备的可信性；在签名信息验证通过的情况下，基于业务信息进行业务处理。

Description

用于业务处理的方法和装置

技术领域

本说明书的实施例涉及信息技术领域，并且具体地，涉及用于业务处理的方法、服务器、客户端设备、计算设备和机器可读存储介质。

背景技术

在基于互联网的大量业务场景中，一般需要客户端设备和服务器彼此进行通信以便完成业务处理。在这样的场景中，通常需要考虑安全性问题，例如，如何防止服务器篡改数据，或者如何确保客户端设备的数据是可信的等等。

发明内容

考虑到现有技术的上述问题，本说明书的实施例提供了用于业务处理的方法、服务器、客户端设备、计算设备和机器可读存储介质。

一方面，本说明书的实施例提供了一种用于业务处理的方法，其中，所述方法由位于区块链系统中的服务器执行，所述方法包括：接收业务信息和针对所述业务信息的签名信息，其中，所述业务信息是由所述客户端设备生成的，所述签名信息是所述客户端设备调用SE模块来生成的，所述SE模块已经被注册到所述服务器；对所述签名信息进行验证，以确认所述客户端设备的可信性；在对所述签名信息验证通过的情况下，基于所述业务信息进行业务处理。

另一方面，本说明书的实施例提供了一种用于业务处理的方法，包括：生成需要服务器进行处理的业务信息，其中，所述服务器位于区块链系统中；调用SE模块来生成针对所述业务信息的签名信息，其中，所述SE模块已经被注册到所述服务器；发送所述业务信息和所述签名信息，以便所述服务器在对所述签名信息验证通过之后，基于所述业务信息进行业务处理。

另一方面，本说明书的实施例提供了一种用于业务处理的服务器，其中，所述服务器位于区块链系统中，所述服务器包括：接收单元，被配置为接收业务信息和针对所述业务信息的签名信息，其中，所述业务信息是由所述客户端设备生成的，所述签名信息是所述客户端设备调用安全元件SE模块来生成的，所述SE模块已经被注册到所述服务器；验证单元，被配置为对所述签名信息进行验证，以确认所述客户端设备的可信性；处理单元，被配置为在所述验证单元对所述签名信息验证通过的情况下，基于所述业务信息进行业务处理。

另一方面，本说明书的实施例提供了一种用于业务处理的客户端设备，包括：生成单元，被配置为生成需要服务器进行处理的业务信息，其中，所述服务器位于区块链系统中；调用单元，被配置为调用安全元件SE模块来生成针对所述业务信息的签名信息，其中，所述SE模块已经被注册到所述服务器；发送单元，被配置为发送所述业务信息和所述签名信息，以便所述服务器在对所述签名信息验证通过之后，基于所述业务信息进行业务处理。

另一方面，本说明书的实施例提供了一种计算设备，包括：至少一个处理器；与所述至少一个处理器进行通信的存储器，其上存储有可执行指令，所述可执行指令在被所述至少一个处理器执行时使得所述至少一个处理器实现上述由服务器执行的方法。

另一方面，本说明书的实施例提供了一种计算设备，包括：至少一个处理器；与所述至少一个处理器进行通信的存储器，其上存储有可执行指令，所述可执行指令在被所述至少一个处理器执行时使得所述至少一个处理器实现上述由客户端设备执行的方法。

另一方面，本说明书的实施例提供了一种机器可读存储介质，存储有可执行指令，所述可执行指令在被机器执行时使得机器实现上述由服务器执行的方法。

另一方面，本说明书的实施例提供了一种机器可读存储介质，存储有可执行指令，所述可执行指令在被机器执行时使得机器实现上述由客户端设备执行的方法。

可见，在该技术方案中，由于利用区块链系统中的服务器进行业务处理，从而能够有效地确保业务数据的安全性；此外，由于利用注册到服务器的SE模块来生成针对业务信息的签名信息，使得服务器能够确认客户端设备的可信性，从而能够有效地确保客户端设备侧的业务数据的可信性。因此，在该技术方案中，通过区块链技术和SE模块来共同构建业务处理的可信环境，从而能够有效地解决客户端设备和服务器之间的双重信任问题。

附图说明

通过结合附图对本说明书的实施例的更详细的描述，本说明书的实施例的上述以及其它目的、特征和优势将变得更加明显，其中，在本说明书的实施例中，相同的附图标记通常代表相同的元素。

图1是根据一个实施例的用于业务处理的方法的示意性流程图。

图2是根据一个实施例的用于业务处理的方法的示意性流程图。

图3A是根据一个实施例的用于业务处理的过程的示意性流程图。

图3B是根据一个实施例的用于注册SE模块的过程的示意性流程图。

图4是根据一个实施例的用于业务处理的服务器的示意性框图。

图5是根据一个实施例的用于业务处理的客户端设备的示意性框图。

图6是根据一个实施例的用于业务处理的计算设备的硬件结构图。

图7是根据一个实施例的用于业务处理的计算设备的硬件结构图。

具体实施方式

现在将参考各实施例讨论本文描述的主题。应当理解的是，讨论这些实施例仅是为了使得本领域技术人员能够更好地理解并且实现本文描述的主题，并非是对权利要求书中所阐述的保护范围、适用性或者示例的限制。可以在不脱离权利要求书的保护范围的情况下，对所讨论的元素的功能和排列进行改变。各个实施例可以根据需要，省略、替换或者添加各种过程或组件。

在包括客户端设备和服务器的业务场景中，往往需要考虑安全性问题。例如，如何确保服务器不会随意篡改业务数据，如何确保客户端设备提供的业务数据是可信的等等。

如所已知的，区块链技术可以是指借由密码学串接并且保护内容的串联交易记录(也可以被称为区块)。例如，每个区块可以包含前一个区块的加密哈希信息、相应时间戳标记以及交易数据，这样使得区块内容具有难以篡改的特性。

因此，在本说明书的实施例中，可以在服务器侧采用区块链技术，来确保服务器侧的业务数据的安全性。

而对于客户端设备而言，可以采用SE模块来确保业务数据的可信性。SE模块通常可以是以芯片形式来提供的。为了防止外部恶意解析攻击并且保护数据安全，SE模块通常可以具有加密/解密逻辑电路。

在本说明书的技术方案中，客户端设备可以采用多种形式来实现。例如，客户端设备可以被实现为手持设备，其也可以被称为移动设备、移动终端、移动通信终端等等。例如，手持设备可以是具有口袋大小的设备，包括但不限于手机、笔记本电脑、平板电脑、销售点(Point of Sale，POS)机、车载计算机等等。

下面将结合具体实施例来描述本说明书中的技术方案。

图1是根据一个实施例的用于业务处理的方法的示意性流程图。例如，图1的方法可以由位于区块链系统中的服务器来执行。

如图1所示，在步骤102中，可以接收业务信息和针对业务信息的签名信息。

业务信息可以是由客户端设备生成的。签名信息可以是客户端设备调用SE模块来生成的，而SE模块可以已经被注册到服务器。

在步骤104中，可以对签名信息进行验证，以确认客户端设备的可信性。

在步骤106中，在对签名信息验证通过的情况下，可以基于业务信息进行业务处理。

可见，在该技术方案中，由于利用区块链系统中的服务器进行业务处理，从而能够有效地确保业务数据的安全性；此外，由于利用注册到服务器的SE模块来生成针对业务信息的签名信息，使得服务器能够确认客户端设备的可信性，从而能够有效地确保客户端设备侧的业务数据的可信性。因此，在该技术方案中，通过区块链技术和SE模块来共同构建业务处理的可信环境，从而能够有效地解决客户端设备和服务器之间的双重信任问题。

在本说明书中，SE模块可以采用多种形式来实现。例如，SE模块可以是以硬件形式集成在客户端设备中。

再例如，SE模块可以是以可解耦的形式与客户端设备耦合的。在这种情况下，SE模块可以采用硬件来实现。或者，SE模块可以集成在可插拔的用户识别模块(SubscriberIdentification Module，SIM)卡中，从而通过SIM卡与客户端设备相耦合。

例如，SE模块可以集成在限域通信(Range Controlled Communication，RCC)-SIM卡中。在这种情况下，SE模块可以与SIM卡绑定在一起，其中SE模块可以通过RCC或蓝牙低能(Bluetooth Low Energy，BLE)技术来与客户端设备进行通信。

再例如，SE模块可以集成在近场通信(Near Field Communication，NFC)-SIM卡中。在这种情况下，SE模块可以与SIM卡绑定在一起，其中SE模块可以通过NFC的方式与客户端设备进行通信。

如前所述，SE模块可以具有加密/解密逻辑电路，其可以以安全的方式存储用于验证和签名的公私钥对。

在一种情况下，公钥和私钥可以是通过业务管理系统预先配置在SE模块中的。例如，对于发票开具场景来说，业务管理系统可以是税务管理系统等等。此外，业务管理系统可以将公钥和SE模块的标识信息等相关信息通过安全环境发送给处于区块链系统中的服务器，从而将SE模块注册到服务器，也可以理解为将SE模块注册到区块链系统中。

在另一种情况下，可以以更灵活的方式来实现SE模块的注册过程。具体地，SE模块可以生成公钥和私钥。SE模块可以向可信服务管理(Trusted Service Management，TSM)平台发送公钥。SE模块可以与TSM平台之间建立安全通道，而公钥可以是通过该安全通道来传送的。例如，TSM平台可以基于在SE模块中预先配置的密码来与SE模块建立安全通道。该密码可以是在SE模块出厂时配置在SE模块中的。

此外，SE模块还可以通过安全通道向TSM平台发送用于生成数字证书的其它相关信息。TSM平台在接收到公钥之后，可以生成数字证书，然后可以通过安全通道将数字证书发送给SE模块，这样，SE模块可以认为当前的公钥和私钥已经被TSM服务器认证，即处于可用状态。

此外，TSM平台在对公钥认证之后，可以将注册信息(例如，其包括公钥和SE模块的标识信息等)发送给区块链系统中的服务器，从而将SE模块注册到区块链系统中的服务器上。这样，能够保证客户端设备的公钥和私钥绝对安全并且不可伪造，由此可以使得SE模块和服务器安全地进行后续的业务处理。

在一个实施例中，签名信息可以是利用SE模块中存储的私钥来对业务信息进行签名得到的。此处，可以采用现有的任何适用的技术来实现对业务信息的签名。

在步骤104中，可以利用与私钥相对应的公钥来对签名信息进行验证，这样能够有效地确认客户端设备的可信性。

在一个实施例中，在进行业务处理之后，可以生成业务处理结果。然后，可以将业务处理结果发送给相应的设备，比如客户端设备或其它相关设备。例如，在下述的发票开具场景下，还可以将业务处理结果发送给消费者设备。

本说明书的技术方案可以应用于需要客户端设备与服务器之间的双重信任的场景中。例如，本说明书的技术方案可以适用于税务发票开具、数据存证等多种场景。

下面以发票开具场景为例来进行说明。传统的税务发票开具通常是使用税控发票机来实现的。税控发票机在出厂时被税务局进行认证，以保证发票出具的正确性。但是，由于税控发票机的出厂设置，导致更新换代频率较低，使得机器容易落后，从而可能与税务局的服务器的网络连接不够稳定，不仅使用体验较差，而且可能会导致发票开具出现问题。因此，如果能够在普通的客户端设备上实现发票开具过程，将能够极大地提升发票开具的便捷性以及用户使用体验。但是，这种方式需要确保客户端设备和服务器之间的双重可信性。鉴于此，本说明书的技术方案能够在客户端设备和服务器之间安全地实现发票开具过程。

在一个实施例中，上述业务信息可以包括发票开具信息。例如，发票开具信息可以包括发票抬头、金额等信息。而签名信息可以是利用SE模块中的私钥对发票开具信息进行签名来得到的。

在步骤106中，在对签名信息验证通过的情况下，例如在确认客户端设备是可信的情况下，服务器可以基于发票开具信息，执行发票开具过程，从而得到发票开具结果。例如，服务器可以生成并且存储发票记录。而发票开具结果可以包括随机哈希字符串或诸如查询码之类的信息。通过该随机哈希字符串或查询码，可以在服务器上查询并且获取到所存储的发票记录。

可见，由于利用区块链系统中的服务器进行发票开具，从而能够有效地确保发票数据的安全性；此外，由于利用注册到服务器的SE模块来生成针对发票开具信息的签名信息，使得服务器能够确认客户端设备的可信性，从而能够有效地确保客户端设备侧的发票数据的可信性。因此，在该技术方案中，通过区块链技术和SE模块来共同构建发票开具的可信环境，从而能够有效地解决客户端设备和服务器之间的双重信任问题。

在一种情况下，在步骤102中，服务器可以从客户端设备接收发票开具信息和签名信息，从而可以将发票开具结果返回给该客户端设备。

在一种情况下，客户端设备可以将发票开具信息和签名信息发送给消费者设备。在消费者需要进行报销时，可以通过消费者设备向服务器发送发票开具信息和签名信息。这样，在步骤102中，服务器可以从消费者设备接收发票开具信息和签名信息。然后，服务器可以将发票开具结果返回给消费者设备。

在该实施例中，客户端设备可以处于在线或离线状态。例如，在客户端设备处于离线状态时，例如当前无法与服务器直接进行通信，可以采用这种方式来实现发票开具。

图2是根据一个实施例的用于业务处理的方法的示意性流程图。例如，图2的方法可以由客户端设备来执行。

如图2所示，在步骤202中，可以生成需要服务器进行处理的业务信息。服务器可以位于区块链系统中。

在步骤204中，可以调用SE模块来生成针对业务信息的签名信息。SE模块可以已经被注册到服务器。

在步骤206中，可以发送业务信息和签名信息，以便服务器在对签名信息验证通过之后，基于业务信息进行业务处理。

可见，在该技术方案中，由于利用区块链系统中的服务器进行业务处理，从而能够有效地确保业务数据的安全性；此外，由于利用注册到服务器的SE模块来生成针对业务信息的签名信息，使得服务器能够确认客户端设备的可信性，从而能够有效地确保客户端设备侧的业务数据的可信性。因此，在该技术方案中，通过区块链技术和SE模块来共同构建业务处理的可信环境，从而能够有效地解决客户端设备和服务器之间的双重信任问题。

如前所述，可以在进行业务处理之前，将SE模块注册到服务器。

在一个实施例中，如前所述，可以在SE模块中预先配置公钥和私钥，然后通过相应的业务管理系统将SE模块注册到服务器。在这种情况下，SE模块可以是集成在客户端设备中的，也可以是与客户端设备可解耦的。

在另一实施例中，如前所述，可以以更灵活的方式来将SE模块注册到服务器。例如，在步骤202之前，可以调用SE模块来生成公钥和私钥。然后，可以调用SE模块来将公钥发送给TSM平台和SE模块的标识信息。TSM平台可以对公钥进行认证，从而生成数字证书。然后，TSM可以将数字证书发送给SE模块，这样SE模块可以认为公钥和私钥是被认证过的，从而处于可用状态。此外，如前所述，TSM平台和SE模块之间可以建立安全通道，公钥和数字证书等相关信息可以是在该安全通道上传送的。

此外，TSM平台可以将注册信息(例如，其包括公钥和SE模块的标识信息等)发送给服务器，使得服务器对SE模块进行注册。在这种情况下，SE模块可以是以可解耦的方式来耦合到客户端设备的。

这样，能够确保客户端设备的公钥和私钥是绝对安全并且不可伪造的，由此能够安全地进行后续的业务处理。

在一个实施例中，可以由用户发起SE模块的注册过程。而在对SE模块进行注册时，可以首先对用户进行验证，以便确认用户是客户端设备的合法使用者。例如，可以接收用户在客户端设备上的输入，该输入用于指示对SE模块进行注册。比如，可以通过安装在客户端设备上的应用程序来接收用户的输入。

然后，可以基于输入对用户进行验证。比如，可以对用户进行密码验证和/或生物验证。密码验证通常可以指对用户输入的密码进行验证。生物验证通常可以指对用户的生物特征(比如指纹、面部、虹膜等)进行验证。可以理解的是，在对客户端设备的用户没有限制(例如，任何用户可以使用该客户端设备进行业务处理)的情况下，可以不对用户进行生物验证。

之后，在对用户验证通过的情况下，例如确认用户是可信的，可以调用SE模块来生成公钥和私钥。

在一个实施例中，在步骤202中，用户可以通过客户端设备上安装的用于业务处理的应用程序来发起业务处理过程。例如，可以在用户发起业务处理过程时，对用户进行验证以确认该用户是合法使用者，比如对用户进行密码验证和/或生物验证。在对用户验证通过的情况下，还可以通过应用程序来接收用户输入的业务相关信息。可以基于业务相关信息，来生成需要服务器进行处理的业务信息。

在一个实施例中，在步骤204中，可以利用SE模块中存储的私钥来对业务信息进行签名，以得到签名信息。这样，服务器可以对签名信息进行验证，从而确认客户端设备的可信性。

如前所述，本说明书的技术方案可以适用于各种场景，例如发票开具或数据存证场景。

下面以发票开具场景为例进行说明。在一个实施例中，业务信息可以包括发票开具信息。例如，发票开具信息可以包括发票抬头、金额等信息。例如，发票抬头、金额等信息可以是由用户通过客户端设备的应用程序输入的。

在一种情况下，在步骤206中，可以向服务器发送发票开具信息和签名信息。然后，可以从服务器接收发票开具结果。发票开具结果可以是服务器基于发票开具信息来生成的。

例如，在客户端设备当前处于在线状态的情况下，即在客户端设备当前能够与服务器进行通信的情况下，客户端设备可以直接将发票开具信息和签名信息发送给服务器，并且从服务器接收发票开具结果。

在另一种情况中，在步骤206中，客户端设备可以向消费者设备发送发票开具信息和签名信息。这样，在消费者需要进行报销时，可以通过消费者设备向服务器发送发票开具信息和签名信息，并且从服务器接收发票开具结果。

在该实施例中，客户端设备当前可以处于在线或离线状态。尤其是在客户端设备处于离线状态时，该实施例也能够支持开具发票，这也可以称为离线开票。

对于离线开票场景而言，可以在客户端设备中设置离线发票的信用额度。当客户端设备在离线状态下调用SE模块生成签名信息时，SE模块可以首先检查自从客户端设备最后一次与服务器同步到现在为止，已经开具的离线发票金额是否超过所设置的离线发票的信用额度。如果没有超过信用额度，则可以生成签名信息。如果已经超过信用额度，则拒绝生成签名信息。这种方式也能够保证客户端设备不会无限制地进行离线开票。

对于消费者设备而言，如果在从客户端设备接收到发票开具信息和签名信息时处于在线状态，可以通过与服务器进行通信来验证客户端设备的签名信息的可信性。例如，消费者设备可以立即向服务器发送发票开具信息和签名信息，如果接收到发票开具结果，则可以证明客户端设备提供的签名信息是可信的。

当然，如果消费者设备和客户端设备都处于离线状态，可以增加额外的公私钥对来验证客户端设备提供的签名信息是否是可信的。

当然，除了发票开具场景外，本说明书的技术方案也可以支持其它场景下的离线业务处理过程。

下面将结合具体例子描述本说明书的技术方案。应当理解的是，以下例子仅是为了帮助本领域技术人员更好地理解本说明书的技术方案，而非对其进行限制。

图3A是根据一个实施例的用于业务处理的过程的示意性流程图。

如图3A所示，在步骤302A中，客户端设备可以经由TSM平台，将SE模块注册到区块链系统中的服务器上。该过程将在图3B中进一步描述。

在步骤304A中，客户端设备可以在需要请求服务器进行业务处理时，生成业务信息。

例如，客户端设备可以接收用户通过客户端设备上的应用程序输入的业务相关信息，基于该信息来生成业务信息。即，业务处理过程可以由用户通过应用程序来发起。在这种情况下，可以对用户进行验证，例如密码验证和/或生物验证。

在步骤306A中，客户端设备可以调用SE模块中的私钥来对业务信息进行签名，从而得到签名信息。

在步骤308A中，客户端设备可以向服务器发送业务信息和签名信息。

在步骤310A中，服务器可以对签名信息进行验证，以确认客户端设备的可信性。

在步骤312A中，在对签名信息验证通过的情况下，服务器可以基于业务信息进行业务处理，从而生成业务处理结果。

例如，在发票开具场景下，可以基于发票开具信息来生成发票开具结果。

在步骤314A中，服务器可以向客户端设备发送业务处理结果。

可见，在该技术方案中，由于利用区块链系统中的服务器进行业务处理，从而能够有效地确保业务数据的安全性；此外，由于利用注册到服务器的SE模块来生成针对业务信息的签名信息，使得服务器能够确认客户端设备的可信性，从而能够有效地确保客户端设备侧的业务数据的可信性。因此，在该技术方案中，通过区块链技术和SE模块来共同构建业务处理的可信环境，从而能够有效地解决客户端设备和服务器之间的双重信任问题。

下面将详细描述图3A中的302A的具体实现过程。图3B是根据一个实施例的用于注册SE模块的过程的示意性流程图。

如图3B所示，在步骤302B中，客户端设备可以从用户接收输入，该输入用于指示注册SE模块。

例如，用户可以通过安装在客户端设备上的应用程序(其可以用于业务处理)来发起注册SE模块的过程。例如，用户可以点击该应用程序所呈现的按钮，或者输入相应的信息，从而发起注册SE模块的过程。

在步骤304B中，客户端设备可以对用户进行验证。

例如，客户端设备可以对用户进行密码验证和/或生物验证。

在步骤306B中，在对用户验证通过的情况下，客户端设备可以调用SE模块来生成公钥和私钥。

在步骤308B中，客户端设备可以调用SE模块来向TSM平台发送公钥。

例如，SE模块可以与TSM平台建立安全通道，并且可以通过该安全通道来向TSM平台发送公钥。

在步骤310B中，TSM平台可以基于公钥，来生成数字证书。

在步骤312B中，TSM平台可以向客户端设备中的SE模块发送数字证书。这样，SE模块可以认为公钥和私钥已经处于可用状态。

例如，TSM平台可以通过之前与SE模块建立的安全通道，来向SE模块发送数字证书。

在步骤314B中，TSM平台可以向区块链系统中的服务器发送注册信息。例如，注册信息可以包括公钥和SE模块的标识信息。

在步骤316B中，服务器可以基于公钥和SE模块的标识信息，对SE模块进行注册。

可见，在该实施例中，由于将客户端设备的SE模块注册到区块链系统中的服务器，所以可以在服务器和客户端之间构建可信的业务处理环境，从而能够安全地进行后续的业务处理。

图4是根据一个实施例的用于业务处理的服务器的示意性框图。

如图4所示，服务器400可以包括接收单元402、验证单元404和处理单元406。

接收单元402可以接收业务信息和针对业务信息的签名信息，其中，业务信息是由客户端设备生成的，签名信息是客户端设备调用SE模块来生成的，SE模块已经被注册到服务器。

验证单元404可以对签名信息进行验证，以确认客户端设备的可信性。

处理单元406可以在对签名信息验证通过的情况下，基于业务信息进行业务处理。

可见，在该技术方案中，由于利用区块链系统中的服务器进行业务处理，从而能够有效地确保业务数据的安全性；此外，由于利用注册到服务器的SE模块来生成针对业务信息的签名信息，使得服务器能够确认客户端设备的可信性，从而能够有效地确保客户端设备侧的业务数据的可信性。因此，在该技术方案中，通过区块链技术和SE模块来共同构建业务处理的可信环境，从而能够有效地解决客户端设备和服务器之间的双重信任问题。

在一个实施例中，签名信息可以是利用SE模块中存储的私钥对业务信息进行签名得到的。

验证单元404可以利用与私钥相对应的公钥来对签名信息进行验证。

在一个实施例中，服务器400还可以包括注册单元408。

接收单元402可以在接收业务信息和签名信息之前，从TSM平台接收注册信息，其中，注册信息包括公钥和SE模块的标识信息，公钥是TSM平台从SE模块接收的，并且注册信息是在TSM平台对公钥进行认证之后发送的。

注册单元408可以基于注册信息，对SE模块进行注册。

在一个实施例中，业务信息可以包括发票开具信息。处理单元406可以基于发票开具信息，生成发票开具结果。

在一个实施例中，接收单元402可以从客户端设备接收发票开具信息和签名信息，其中，发票开具结果被发送给客户端设备。

在一个实施例中，接收单元402可以从消费者设备接收发票开具信息和签名信息，其中，发票开具信息和签名信息是消费者设备从客户端设备接收的，发票开具结果被发送给消费者设备。

装置400的各个单元可以执行图1和图3A-3B的方法实施例中的相应步骤，因此，为了描述的简洁，装置400的各个单元的具体操作和功能此处不再赘述。

上述装置400可以采用硬件实现，也可以采用软件实现，或者可以通过软硬件的组合来实现。例如，装置400在采用软件实现时，其可以通过其所在设备的处理器将存储器(比如非易失性存储器)中对应的可执行指令读取到内存中运行来形成。

图5是根据一个实施例的用于业务处理的客户端设备的示意性框图。

如图5所示，客户端设备500可以包括生成单元502、调用单元504和发送单元506。

生成单元502可以生成需要服务器进行处理的业务信息，其中，服务器位于区块链系统中。

调用单元504可以调用SE模块来生成针对业务信息的签名信息，其中，SE模块已经被注册到服务器。

发送单元506可以发送业务信息和签名信息，以便服务器在对签名信息验证通过之后，基于业务信息进行业务处理。

可见，在该技术方案中，由于利用区块链系统中的服务器进行业务处理，从而能够有效地确保业务数据的安全性；此外，由于利用注册到服务器的SE模块来生成针对业务信息的签名信息，使得服务器能够确认客户端设备的可信性，从而能够有效地确保客户端设备侧的业务数据的可信性。因此，在该技术方案中，通过区块链技术和SE模块来共同构建业务处理的可信环境，从而能够有效地解决客户端设备和服务器之间的双重信任问题。

在一个实施例中，调用单元504可以利用SE模块中存储的私钥对业务信息进行签名，以得到签名信息。

在一个实施例中，在生成单元502生成业务信息之前，调用单元504可以调用SE模块来生成公钥和私钥，其中，公钥和私钥是相对应的。调用单元504可以调用SE模块来向TSM平台发送公钥和SE模块的标识信息，以便TSM平台在对公钥认证之后将SE模块注册到服务器。

在一个实施例中，客户端设备500还可以包括第一接收单元508和验证单元510。

第一接收单元508可以接收用户在客户端设备上的输入，其中，输入用于指示对SE模块进行注册。

验证单元510可以基于输入对用户进行验证；

在验证单元510对用户验证通过的情况下，调用单元504可以调用SE模块来生成公钥和私钥。

在一个实施例中，客户端设备500还可以包括第二接收单元512。

业务信息可以包括发票开具信息。发送单元506可以为向服务器发送发票开具信息和签名信息。第二接收单元512可以从服务器接收发票开具结果，其中，发票开具结果是服务器基于发票开具信息生成的。

在一个实施例中，发送单元506可以向消费者设备发送发票开具信息和签名信息，以便消费者设备从服务器接收发票开具结果，其中，发票开具结果是服务器基于发票开具信息生成的。

在一个实施例中，SE模块可以是以可解耦的方式与客户端设备耦合的。

装置500的各个单元可以执行图2和图3A-3B的方法实施例中的相应步骤，因此，为了描述的简洁，装置500的各个单元的具体操作和功能此处不再赘述。

上述装置500可以采用硬件实现，也可以采用软件实现，或者可以通过软硬件的组合来实现。例如，装置500在采用软件实现时，其可以通过其所在设备的处理器将存储器(比如非易失性存储器)中对应的可执行指令读取到内存中运行来形成。

图6是根据一个实施例的用于业务处理的计算设备的硬件结构图。如图6所示，计算设备600可以包括至少一个处理器602、存储器604、内存606和通信接口608，并且至少一个处理器602、存储器604、内存606和通信接口608经由总线610连接在一起。至少一个处理器602执行在存储器604中存储或编码的至少一个可执行指令(即，上述以软件形式实现的元素)。

在一个实施例中，在存储器604中存储的可执行指令在被至少一个处理器602执行时，使得计算设备实现以上结合图1-3B描述的由服务器执行的过程。

计算设备600可以采用本领域任何适用的形式来实现，例如，其包括但不限于台式计算机、膝上型计算机、智能电话、平板计算机、消费电子设备、可穿戴智能设备等等。

图7是根据一个实施例的用于业务处理的计算设备的硬件结构图。如图7所示，计算设备700可以包括至少一个处理器702、存储器704、内存706和通信接口708，并且至少一个处理器702、存储器704、内存706和通信接口708经由总线710连接在一起。至少一个处理器702执行在存储器704中存储或编码的至少一个可执行指令(即，上述以软件形式实现的元素)。

在一个实施例中，在存储器704中存储的可执行指令在被至少一个处理器702执行时，使得计算设备实现以上结合图1-3B描述的由客户端设备执行的过程。

本说明书的实施例还提供了一种机器可读存储介质。该机器可读存储介质可以存储有可执行指令，可执行指令在被机器执行时使得机器实现上面参照图1-3B描述的由服务器执行的具体过程。

本说明书的实施例还提供了一种机器可读存储介质。该机器可读存储介质可以存储有可执行指令，可执行指令在被机器执行时使得机器实现上面参照图1-3B描述的由客户端设备执行的具体过程。

例如，机器可读存储介质可以包括但不限于随机存取存储器(Random AccessMemory，RAM)、只读存储器(Read-Only Memory，ROM)、电可擦除可编程只读存储器(Electrically-Erasable Programmable Read-Only Memory，EEPROM)、静态随机存取存储器(Static Random Access Memory，SRAM)、硬盘、闪存等等。

应当理解的是，本说明书中的各个实施例均采用递进的方式来描述，各个实施例之间相同或相似的部分相互参见即可，每个实施例重点说明的都是与其它实施例的不同之处。例如，对于上述关于装置的实施例、关于计算设备的实施例以及关于机器可读存储介质的实施例而言，由于它们基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

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

应当理解的是，对于本领域普通技术人员来说，对本说明书中的实施例进行的各种修改将是显而易见的，并且可以在不脱离权利要求书的保护范围的情况下，将本文所定义的一般性原理应用于其它变型。

Claims (28)

1.一种用于业务处理的方法，其中，所述方法由位于区块链系统中的服务器执行，所述方法包括：

接收业务信息和针对所述业务信息的签名信息，其中，所述业务信息是由所述客户端设备生成的，所述签名信息是所述客户端设备调用安全元件SE模块来生成的，所述SE模块已经被注册到所述服务器；

对所述签名信息进行验证，以确认所述客户端设备的可信性；

在对所述签名信息验证通过的情况下，基于所述业务信息进行业务处理。

2.根据权利要求1所述的方法，其中，所述签名信息是利用所述SE模块中存储的私钥对所述业务信息进行签名得到的；

对所述签名信息进行验证，包括：

利用与所述私钥相对应的公钥来对所述签名信息进行验证。

3.根据权利要求2所述的方法，其中，在接收所述业务信息和所述签名信息之前，所述方法还包括：

从可信服务管理TSM平台接收注册信息，其中，所述注册信息包括所述公钥和所述SE模块的标识信息，所述公钥是所述TSM平台从所述SE模块接收的，并且所述注册信息是在所述TSM平台对所述公钥进行认证之后发送的；

基于所述注册信息，对所述SE模块进行注册。

4.根据权利要求1至3中任一项所述的方法，其中，所述业务信息包括发票开具信息；

基于所述业务信息进行业务处理，包括：

基于所述发票开具信息，生成发票开具结果。

5.根据权利要求4所述的方法，其中，接收所述业务信息和所述签名信息，包括：

从所述客户端设备接收所述发票开具信息和所述签名信息，其中，所述发票开具结果由所述服务器发送给所述客户端设备；或者

从消费者设备接收所述发票开具信息和所述签名信息，其中，所述发票开具信息和所述签名信息是所述消费者设备从所述客户端设备接收的，所述发票开具结果由所述服务器发送给所述消费者设备。

6.一种用于业务处理的方法，包括：

生成需要服务器进行处理的业务信息，其中，所述服务器位于区块链系统中；

调用安全元件SE模块来生成针对所述业务信息的签名信息，其中，所述SE模块已经被注册到所述服务器；

发送所述业务信息和所述签名信息，以便所述服务器在对所述签名信息验证通过之后，基于所述业务信息进行业务处理。

7.根据权利要求6所述的方法，其中，调用SE模块来生成针对所述业务信息的签名信息，包括：

利用所述SE模块中存储的私钥对所述业务信息进行签名，以得到所述签名信息。

8.根据权利要求7所述的方法，其中，在生成所述业务信息之前，所述方法还包括：

调用所述SE模块来生成公钥和所述私钥，其中，所述公钥和所述私钥是相对应的；

调用所述SE模块来向可信服务管理TSM平台发送所述公钥和所述SE模块的标识信息，以便所述TSM平台在对所述公钥认证之后将所述SE模块注册到所述服务器。

9.根据权利要求8所述的方法，其中，调用所述SE模块来生成公钥和所述私钥，包括：

接收用户在所述客户端设备上的输入，其中，所述输入用于指示对所述SE模块进行注册；

基于所述输入对所述用户进行验证；

在对所述用户验证通过的情况下，调用所述SE模块来生成所述公钥和所述私钥。

10.根据权利要求6至9中任一项所述的方法，其中，所述业务信息包括发票开具信息；

发送所述业务信息和所述签名信息，包括：

向所述服务器发送所述发票开具信息和所述签名信息；所述方法还包括：

从所述服务器接收发票开具结果，其中，所述发票开具结果是所述服务器基于所述发票开具信息生成的。

11.根据权利要求6至9中任一项所述的方法，其中，所述业务信息包括发票开具信息；

发送所述业务信息和所述签名信息，包括：

向消费者设备发送所述发票开具信息和所述签名信息，以便所述消费者设备从所述服务器接收发票开具结果，其中，所述发票开具结果是所述服务器基于所述发票开具信息生成的。

12.根据权利要求6至11中任一项所述的方法，其中，所述SE模块是以可解耦的方式与所述客户端设备耦合的。

13.一种用于业务处理的服务器，其中，所述服务器位于区块链系统中，所述服务器包括：

接收单元，被配置为接收业务信息和针对所述业务信息的签名信息，其中，所述业务信息是由所述客户端设备生成的，所述签名信息是所述客户端设备调用安全元件SE模块来生成的，所述SE模块已经被注册到所述服务器；

验证单元，被配置为对所述签名信息进行验证，以确认所述客户端设备的可信性；

处理单元，被配置为在所述验证单元对所述签名信息验证通过的情况下，基于所述业务信息进行业务处理。

14.根据权利要求13所述的服务器，其中，所述签名信息是利用所述SE模块中存储的私钥对所述业务信息进行签名得到的；

所述验证单元被配置为：利用与所述私钥相对应的公钥来对所述签名信息进行验证。

15.根据权利要求14所述的服务器，其中，所述服务器还包括注册单元；

所述接收单元还被配置为：在接收所述业务信息和所述签名信息之前，从可信服务管理TSM平台接收注册信息，其中，所述注册信息包括所述公钥和所述SE模块的标识信息，所述公钥是所述TSM平台从所述SE模块接收的，并且所述注册信息是在所述TSM平台对所述公钥进行认证之后发送的；

所述注册单元，被配置为基于所述注册信息，对所述SE模块进行注册。

16.根据权利要求14至15中任一项所述的服务器，其中，所述业务信息包括发票开具信息；

所述处理单元被配置为：基于所述发票开具信息，生成发票开具结果。

17.根据权利要求16所述的服务器，其中，所述接收单元被配置为：

从所述客户端设备接收所述发票开具信息和所述签名信息，其中，所述发票开具结果被发送给所述客户端设备；或者

从消费者设备接收所述发票开具信息和所述签名信息，其中，所述发票开具信息和所述签名信息是所述消费者设备从所述客户端设备接收的，所述发票开具结果被发送给所述消费者设备。

18.一种用于业务处理的客户端设备，包括：

生成单元，被配置为生成需要服务器进行处理的业务信息，其中，所述服务器位于区块链系统中；

调用单元，被配置为调用安全元件SE模块来生成针对所述业务信息的签名信息，其中，所述SE模块已经被注册到所述服务器；

发送单元，被配置为发送所述业务信息和所述签名信息，以便所述服务器在对所述签名信息验证通过之后，基于所述业务信息进行业务处理。

19.根据权利要求18所述的客户端设备，其中，所述调用单元被配置为：

利用所述SE模块中存储的私钥对所述业务信息进行签名，以得到所述签名信息。

20.根据权利要求19所述的客户端设备，其中，所述调用单元还被配置为：

在所述生成单元生成所述业务信息之前，调用所述SE模块来生成公钥和所述私钥，其中，所述公钥和所述私钥是相对应的；

调用所述SE模块来向可信服务管理TSM平台发送所述公钥和所述SE模块的标识信息，以便所述TSM平台在对所述公钥认证之后将所述SE模块注册到所述服务器。

21.根据权利要求20所述的客户端设备，其中，所述客户端设备还包括第一接收单元和验证单元；

所述第一接收单元，被配置为接收用户在所述客户端设备上的输入，其中，所述输入用于指示对所述SE模块进行注册；

所述验证单元，被配置为基于所述输入对所述用户进行验证；

所述调用单元被配置为：在所述验证单元对所述用户验证通过的情况下，调用所述SE模块来生成所述公钥和所述私钥。

22.根据权利要求18至21中任一项所述的客户端设备，其中，所述客户端设备还包括第二接收单元；所述业务信息包括发票开具信息；

所述发送单元，被配置为向所述服务器发送所述发票开具信息和所述签名信息；

所述第二接收单元，被配置为从所述服务器接收发票开具结果，其中，所述发票开具结果是所述服务器基于所述发票开具信息生成的。

23.根据权利要求18至21中任一项所述的客户端设备，其中，所述业务信息包括发票开具信息；

所述发送单元，被配置为向消费者设备发送所述发票开具信息和所述签名信息，以便所述消费者设备从所述服务器接收发票开具结果，其中，所述发票开具结果是所述服务器基于所述发票开具信息生成的。

24.根据权利要求18至23中任一项所述的客户端设备，其中，所述SE模块是以可解耦的方式与所述客户端设备耦合的。

25.一种计算设备，包括：

至少一个处理器；

与所述至少一个处理器进行通信的存储器，其上存储有可执行指令，所述可执行指令在被所述至少一个处理器执行时使得所述至少一个处理器实现根据权利要求1至5中任一项所述的方法。

26.一种计算设备，包括：

至少一个处理器；

与所述至少一个处理器进行通信的存储器，其上存储有可执行指令，所述可执行指令在被所述至少一个处理器执行时使得所述至少一个处理器实现根据权利要求6至12中任一项所述的方法。

27.一种机器可读存储介质，存储有可执行指令，所述可执行指令在被机器执行时使得机器实现根据权利要求1至5中任一项所述的方法。

28.一种机器可读存储介质，存储有可执行指令，所述可执行指令在被机器执行时使得机器实现根据权利要求6至12中任一项所述的方法。

Images