一种多副本数据完整性验证方法及装置

技术领域

本申请属于云审计技术领域，具体地讲，涉及一种多副本数据完整性验证方法及装置。

背景技术

云存储能够满足用户从云存储共享中心按需分配存储资源，从而免去了用户在本地存储和维护数据的成本。但是，将数据存储到云服务器中，用户失去了对数据的物理控制，从而使用传统的方法无法验证数据的完整性。在现有的多副本数据审计方案中用户端须要上传多份不同的副本文件到云服务器中，防止云服务端声明存储了指定数目的副本文件，而实际只存储一份或者少于协定数目的副本文件。这增加了用户端和云服务器端数倍的通信开销，严重降低了多副本数据审计方案的性能。现有的云存储审计方案也需要为每个文件生成相应的数据块标签集合和其他的一些辅助验证的元数据，这不仅增加了用户端的计算开销，同时也增加了用户端和云服务器端的通信开销。不仅如此，现有的多副本数据审计系统中不仅包含用户端和云服务端，还包含一第三方审计端用于对多副本数据的完整性进行审计，第三方审计端的存在也增加了系统的负担。

发明内容

本申请提供了一种无第三方的多副本数据完整性验证方法及装置，以至少解决当前云审计中需要引入第三方审计端或者需要为每个文件生成相应的数据块标签机和和其他一些辅助验证数据从而增加了用户端的开销问题。

根据本申请的一个方面，提供了一种无第三方的多副本数据完整性验证方法，包括：

经由可信通道接收用户端上传的文件和文件对应的元数据；

根据文件及文件对应的元数据生成N个副本文件，N>1；其中，可信通道建立在用户端与可信容器之间，可信容器为根据用户端发起的认证请求创建的；元数据包括：文件标识符及根据预设的副本文件数量生成的随机时间戳集合；

根据副本文件生成对应的第一哈希值；

将第一哈希值经由可信通道传送至用户端以使用户端生成挑战信息；

接收用户端的挑战信息并根据挑战信息验证N个副本文件的数据完整性。

在一实施例中，可信通道通过如下方式建立：

根据认证请求在本地创建可信容器；

将可信容器的内容的哈希值发送至用户端以使用户端对该哈希值进行验证；

验证通过后在可信容器与用户端之间建立可信通道。

在一实施例中，多副本数据完整性验证方法还包括：

将副本文件和第一哈希值存储到可信容器外部。

在一实施例中，根据文件及文件对应的元数据生成N个副本文件包括：

将用户端上传的文件分割为若干数据块；

根据随机时间戳集合生成N个数据块掩码；

对每个数据块匹配不同的数据块掩码获得N个副本文件。

在一实施例中，根据挑战信息验证N个副本文件的数据完整性包括：

计算挑战信息中N个副本文件的第二哈希值；

将第二哈希值与第一哈希值进行对比，如果相等则验证通过。

根据本申请的另一方面，以用户端为执行主体，还提供了一种无第三方的多副本数据完整性验证方法，包括：

经由可信通道将文件和文件元数据发送至云服务端以供云服务端生成N个副本文件，文件元数据包括：文件标识符及根据预设的副本文件数量生成的随机时间戳集合；

通过可信通道接收云服务器发送的副本文件和副本文件的第一哈希值；

根据第一哈希值、副本文件及文件生成挑战信息并返回云服务器以供云服务器根据挑战信息验证副本文件的数据完整性。

在一实施例中，多副本数据完整性验证方法还包括：

向云服务器发送认证请求；

接收云服务器返回的可信容器的哈希值；

验证哈希值是否正确；

当验证通过后建立与云服务器之间的可信通道。

在一实施例中，多副本数据完整性验证方法还包括：

对文件生成文件标识符；

根据预设的副本文件数量N生成随机时间戳集合，并将文件、文件标识符和时间戳集合通过可信通道发送至云服务器以供云服务器生成N个副本文件。

根据本申请的另一方面，以云服务器端为执行主体，提供了一种无第三方的多副本数据完整性验证装置，包括：

备份单元，用于经由可信通道接收用户端上传的文件和文件对应的元数据并根据文件及文件对应的元数据生成N个副本文件；其中，可信通道建立在用户端与可信容器之间，可信容器为根据用户端发起的认证请求创建的；元数据包括：文件标识符及根据预设的副本文件数量生成的随机时间戳集合；

第一哈希值生成单元，用于根据副本文件生成对应的第一哈希值；

传输单元，用于将第一哈希值经由可信通道传送至用户端以使用户端生成挑战信息；

完整性验证单元，用于接收用户端的挑战信息并根据挑战信息验证多个副本数据的完整性。

在一实施例中，备份单元包括：

副本文件生成模块，用于针对上传的文件和元数据生成N个副本文件；

第一哈希值生成模块，用于为每个副本文件生成第一哈希值并将副本文件和第一哈希值存储到可信容器外部。

在一实施例中，副本文件生成模块包括：

分割模块，用于将用户端上传的文件分割为若干数据块；

掩码生成模块，用于根据随机时间戳集合生成N个数据块掩码；

掩码匹配模块，用于对每个数据块匹配不同的数据块掩码获得N个副本文件。

在一实施例中，完整性验证单元包括：

第二哈希值计算模块，用于计算用户端发送的挑战信息中所有副本文件计算第二哈希值；

对比验证模块，用于将第二哈希值与第一哈希值进行对比，如果相等则验证通过。

以用户端为执行主体，还提供了一种无第三方的多副本数据完整性验证装置，包括：

发送单元，用于经由可信通道将文件和文件元数据发送至云服务端以供云服务端生成N个副本文件，文件元数据包括：文件标识符及根据预设的副本文件数量生成的随机时间戳集合；

挑战信息生成单元，用于通过可信通道接收云服务器发送的副本文件的第一哈希值并根据副本文件的第一哈希值、副本文件及文件生成挑战信息返回云服务器以供云服务器进行完整性验证。

在一实施例中，多副本数据完整性验证装置还包括：

环境验证单元，用于向云服务器发送认证请求后验证云服务器返回的可信容器的哈希值；

可信通道建立单元，用于验证通过后建立与云服务器之间的可信通道。

本申请利用SGX技术确保支持多副本数据完整性验证的同时，通过在可信容器中扩展指定副本数目保存到云服务器中，实现了用户端只需要上传一份文件到云服务器就可以确保云服务器真实地存储了指定数目的副本文件，防止云服务端只存储一份或者少于协定数目的副本文件，避免了用户端和云服务器端之间严重的通信开销。此外，该方法不需要为文件生成相应的数据块标签集合，从而避免了用户端产生严重的计算开销。相比于现有技术，本申请无需引入第三方审计端，并且不需要在用户端进行大量的运算开销，节省了计算资源。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请提供的以云端为执行主体的多副本数据完整性验证方法流程图。

图2为本申请实施例中建立与用户端之间的可信通道的方法流程图。

图3为本申请实施例中生成若干副本文件和对应的第一哈希值的方法流程图。

图4为本申请实施例中针对上传的文件和元数据生成若干个副本文件的流程图。

图5为本申请实施例中将副本文件和第一哈希值存储到可信容器外部的流程图。

图6为本申请实施例中验证多副本数据的完整性的流程图。

图7为本申请提供的以用户端为执行主体的多副本数据完整性验证方法流程图。

图8为本申请实施例中挑战信息生成步骤流程图。

图9为本申请提供的以云端为执行主体的多副本数据完整性验证装置框图。

图10为本申请实施例中可信度建立单元的结构框图。

图11为本申请实施例中备份单元的结构框图。

图12为本申请实施例中副本文件生成模块的结构框图。

图13为本申请实施例中第一哈希值生成模块的结构框图。

图14为本申请实施例中完整性验证单元的结构框图。

图15为本申请实施例中提供的以用户端为执行主体的多副本数据完整性验证装置框图。

图16为本申请实施例中挑战信息生成单元的结构框图。

图17为本申请实施例中一种电子设备的具体实施方式。

图18为本申请的一种模块化示意图。

图19为本申请用户端和云服务器端的通信交互示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。本申请提供的实施例可应用于金融领域，也可以应用于其他领域，本申请不以此为限。

基于背景技术中的问题，本申请提供了一种无第三方的多副本数据完整性验证方法，该方法以云服务器为执行主体，如图1所示，包括：

S101：经由可信通道接收用户端上传的文件和文件对应的元数据。

用户端向云服务器发起运行环境认证请求，云服务器根据该认证请求创建可信容器，然后该可信容器将其内容的哈希值发送给用户端以供用户端进行验证，如果验证通过则建立用户端与云服务器之间的可信通道，此举的目的在于，在云审计开始前创建一个绝对安全公正的审计环境，避免系统遭受外部攻击而影响审计结果的公平性。

S102：根据所述文件及文件对应的元数据生成N个副本文件，根据副本文件生成对应的第一哈希值。元数据包括：文件标识符及针对预设的副本文件生成的随机时间戳集合。

用户端将文件和元数据通过可信通道传输到云服务器的可信容器中，云服务器对这些数据进行预处理然后发送给用户端。

S103：将第一哈希值经由可信通道传送至用户端以使用户端生成挑战信息。

经过云服务器预处理后的数据被送达用户端后，用户端利用这些数据生成挑战信息返回给云服务器以供云审计使用。

S104：接收用户端的挑战信息并根据挑战信息验证N个副本文件的数据完整性。

云服务器接收到用户端发送的挑战信息后利用该挑战信息验证多副本文件的完整性。

在一实施例中，根据用户端发起的认证请求创建本地可信容器并建立与用户端之间的可信通道，如图2所示，包括：

S201：根据认证请求在本地创建可信容器。

S202：将可信容器的内容的哈希值发送至用户端以使用户端对该哈希值进行验证。

S203：验证通过后在可信容器与用户端之间建立可信通道。

在一具体实施例中，在云审计开始前，先对系统进行预设置，基于该系统设定密码学参数和变量。设系统安全参数为l，且大素数p满足|p|＝l；h(·)是加密哈希函数；H(·)为安全哈希函数，分别定义为H

如图19所示，云服务端的服务器部署SGX(软件防护扩展)的环境。用户端向云服务器发起运行环境认证。云服务器根据认证请求创建可信容器(enclave)。可信容器创建完成后，该容器将发送它的内容的哈希值给用户端。若该哈希值与期望的值不一致，则用户端将拒绝与该容器建立通信；否则云服务器将与用户端建立可信通道。

在一实施例中，经由可信通道和可信容器接受用户端上传的文件和元数据并根据用户端上传的文件和元数据生成若干副本文件和对应的第一哈希值，如图3所示，包括：

S301：针对上传的文件和元数据生成若干个副本文件。

S302：为每个副本文件生成第一哈希值并将副本文件和第一哈希值存储到可信容器外部。

在一具体实施例中，用户端将文件和元数据通过可信通道传输到可信容器中，云服务器接收用户端上传的文件和相关的元数据。在云服务器接收到用户端数据后，将文件数据和相关的元数据生成多个副本文件，并且为每个副本文件生成哈希值。然后从将所有的副本文件和对应的哈希值存储到可信容器之外。同时也将所有副本文件的哈希值通过可信通道传输给用户端。

在一实施例中，针对上传的文件和元数据生成若干个副本文件，如图4所示，包括：

S401：将用户端上传的文件分割为若干数据块。

S402：根据所述随机时间戳集合生成N个数据块掩码。

S403：对每个数据块匹配不同的数据块掩码获得若干个副本文件。

在一具体实施例中，用户端对文件F生成文件标识符Fid和针对预设的λ个副本文件生成随机时间戳集合T＝{t

b

其中H(j||i||t

在一实施例中，为每个副本文件生成第一哈希值并将副本文件和第一哈希值存储到可信容器外部，如图5所示，包括：

S501：对所有的副本文件计算哈希值生成第一哈希值集合。

S502：将副本文件的集合和第一哈希值集合存储到可信容器外部。

在一具体实施例中，为所有的副本文件计算哈希值集合Θ＝{h(F

在一实施例中，接收用户端的挑战信息并验证多副本数据的完整性，如图6所示，包括：

S601：计算所述挑战信息中N个副本文件的第二哈希值。

S602：将第二哈希值与第一哈希值进行对比，如果相等则验证通过。

在一具体实施例中，用户端对云服务器发起挑战，并通过前面建立的安全信道发送文件标识符Fid和哈希值集合Θ到云服务器的可信容器中。根据文件标识符Fid从可信容器外加载副本文件集合Γ＝{F

根据本申请的另一方面，以用户端为执行主体，还提供了一种无第三方的多副本数据完整性验证方法，如图7所示，包括：

S701：经由可信通道将文件和文件元数据发送至云服务端以供云服务端生成N个副本文件。

S702：通过所述可信通道接收云服务器发送的副本文件和副本文件的第一哈希值。

S703：根据所述第一哈希值、副本文件及文件生成挑战信息并返回云服务器以供云服务器根据所述挑战信息验证副本文件的数据完整性。

其中，建立用户端与云服务器之间的可信通道的步骤包括：

S1：向云服务器发送认证请求。

S2：接收云服务器返回的可信容器的哈希值。

S3：验证所述哈希值是否正确。

S4：当验证通过后建立与云服务器之间的可信通道。

在一实施例中，根据副本文件的哈希值、副本文件及文件生成挑战信息返回云服务器以供云服务器进行完整性验证，如图8所示，包括：

S801：对文件生成文件标识符。

S802：根据预设的副本文件数量N生成随机时间戳集合，并将文件、文件标识符和时间戳集合通过可信通道发送至云服务器以供云服务器生成N个副本文件。

图18为本申请所提供的方法对应的系统的模块化示意图。

基于同一发明构思，本申请实施例还提供了一种无第三方的多副本数据完整性验证装置，可以用于实现上述实施例中所描述的方法，如下面实施例所述。由于无第三方的多副本数据完整性验证装置解决问题的原理与无第三方的多副本数据完整性验证方法相似，因此无第三方的多副本数据完整性验证装置的实施可以参见无第三方的多副本数据完整性验证方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的系统较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

如图9所示，以云服务器为执行主体，本申请提供了一种无第三方的多副本数据完整性验证装置，包括：

可信度建立单元901，用于根据用户端发起的认证请求创建本地可信容器并建立与用户端之间的可信通道；

备份单元902，用于经由可信通道和可信容器接受用户端上传的文件和元数据并根据用户端上传的文件和元数据生成若干副本文件和对应的第一哈希值；元数据包括：文件标识符及针对预设的副本文件生成的随机时间戳集合；

传输单元903，用于将第一哈希值经由可信通道传送至用户端以使用户端生成挑战信息；

完整性验证单元904，用于接收用户端的挑战信息并验证多副本数据的完整性。

在一实施例中，如图10所示，可信度建立单元901包括：

可信容器创建模块1001，用于根据认证请求在本地创建可信容器；

可信容器验证模块1002，用于将可信容器的内容的哈希值发送至用户端以使用户端对该哈希值进行验证；

可信通道建立模块1003，用于验证通过后在可信容器与用户端之间建立可信通道。

在一实施例中，如图11所示，备份单元902包括：

副本文件生成模块1101，用于针对上传的文件和元数据生成若干个副本文件；

第一哈希值生成模块1102，用于为每个副本文件生成第一哈希值并将副本文件和第一哈希值存储到可信容器外部。

在一实施例中，如图12所示，副本文件生成模块1101包括：

分割模块1201，用于将用户端上传的文件分割为若干数据块；

掩码匹配模块1202，用于对每个数据块匹配不同的数据块掩码获得若干个副本文件。

在一实施例中，如图13所示，第一哈希值生成模块1102包括：

第一哈希值计算模块1301，用于对所有的副本文件计算哈希值生成第一哈希值集合；

存储模块1302，用于将副本文件的集合和第一哈希值集合存储到可信容器外部。

在一实施例中，如图14所示，完整性验证单元904包括：

第二哈希值计算模块1401，用于对用户端发送的所有副本文件计算第二哈希值；

对比验证模块1402，用于将第二哈希值与第一哈希值进行对比，如果相等则验证通过。

以用户端为执行主体，还提供了一种无第三方的多副本数据完整性验证装置，如图15所示，包括：

环境验证单元1501，用于向云服务器发送运行环境认证后验证云服务器返回的可信容器的哈希值；

可信通道建立单元1502，用于验证通过后建立与云服务器之间的可信通道；

挑战信息生成单元1503，用于通过可信通道接收云服务器发送的副本文件的哈希值并根据副本文件的哈希值、副本文件及文件生成挑战信息返回云服务器以供云服务器进行完整性验证。

在一实施例中，如图16所示，挑战信息生成单元1503包括：

文件标识符生成模块1601，用于对文件生成文件标识符；

随机时间戳生成模块1602，用于对预设的若干个副本文件生成随机时间戳集合，并将文件、文件标识符和时间戳集合通过可信通道发送至云服务器以供云服务器进行完整性验证。

本申请提供的一种多副本数据完整性验证方法及装置，在确保支持多副本数据完整性验证的同时，也实现了用户端只需要上传一份文件到云服务器，就可以确保云服务器真实地存储了指定数目的副本文件，防止云服务端只存储一份或者少于协定数目的副本文件。这避免了用户端和云服务器端严重的通信开销。此外，该方法不需要为文件生成相应的数据块标签集合，从而避免了用户端产生严重的计算开销。

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

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

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

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

本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

本申请的实施例还提供能够实现上述实施例中的方法中全部步骤的一种电子设备的具体实施方式，参见图17，所述电子设备具体包括如下内容：

处理器(processor)1701、内存1702、通信接口(Communications Interface)1703、总线1704和非易失性存储器1705；

其中，所述处理器1701、内存1702、通信接口1703通过所述总线1704完成相互间的通信；

所述处理器1701用于调用所述内存1702和非易失性存储器1705中的计算机程序，所述处理器执行所述计算机程序时实现上述实施例中的方法中的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：

S101：根据用户端发起的认证请求创建本地可信容器并建立与用户端之间的可信通道。

S102：经由可信通道和可信容器接受用户端上传的文件和元数据并根据用户端上传的文件和元数据生成若干副本文件和对应的第一哈希值。

S103：将第一哈希值经由可信通道传送至用户端以使用户端生成挑战信息。

S104：接收用户端的挑战信息并验证多副本数据的完整性。

本申请的实施例还提供能够实现上述实施例中的方法中全部步骤的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：

S101：根据用户端发起的认证请求创建本地可信容器并建立与用户端之间的可信通道。

S102：经由可信通道和可信容器接受用户端上传的文件和元数据并根据用户端上传的文件和元数据生成若干副本文件和对应的第一哈希值。

S103：将第一哈希值经由可信通道传送至用户端以使用户端生成挑战信息。

S104：接收用户端的挑战信息并验证多副本数据的完整性。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于硬件+程序类实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。虽然本说明书实施例提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

本领域技术人员应明白，本说明书的实施例可提供为方法、系统或计算机程序产品。因此，本说明书实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书实施例的至少一个实施例或示例中。

在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。以上所述仅为本说明书实施例的实施例而已，并不用于限制本说明书实施例。对于本领域技术人员来说，本说明书实施例可以有各种更改和变化。凡在本说明书实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书实施例的权利要求范围之内。