发明内容
有鉴于此,本申请提供一种消息防伪的实现方法,应用验证服务器上,所述验证服务器可获取到下发消息记录,所述下发消息记录中包括若干条下发消息的接收方用户标识和特征信息,所述方法包括:
接收终端上传的消息验证请求,所述消息验证请求中携带待检验消息的接收方用户标识和验证信息;
当所述下发消息记录中具有与待检验消息相同的接收方用户标识、并且特征信息匹配于所述待检验消息的验证信息的下发消息时,向所述终端回复通过验证的响应。
本申请提供的一种消息防伪的实现方法,应用消息服务器上,包括:
生成下发消息,并根据接收方用户标识发送所述下发消息;
将所述下发消息的接收方用户标识和特征信息写入下发消息记录,用来由验证服务器将下发消息的接收方用户标识和特征信息、与待检验消息的接收方用户标识和验证信息进行匹配,以确定待检验消息是否通过验证。
本申请提供的一种消息防伪的实现方法,应用终端上,包括:
根据用户的操作,向验证服务器上传消息验证请求;所述消息验证请求中携带待检验消息的接收方用户标识和验证信息,供验证服务器将待检验消息的接收方用户标识和验证信息、与下发消息记录中下发消息的接收方用户标识和特征信息进行匹配,以确定待检验消息是否通过验证;
接收验证服务器返回的带有验证结果的消息验证响应,并向用户显示验证结果。
本申请还提供了一种消息防伪的实现装置,应用验证服务器上,所述验证服务器可获取到下发消息记录,所述下发消息记录中包括若干条下发消息的接收方用户标识和特征信息,所述装置包括:
验证请求接收单元,用于接收终端上传的消息验证请求,所述消息验证请求中携带待检验消息的接收方用户标识和验证信息;
验证请求匹配单元,用于当所述下发消息记录中具有与待检验消息相同的接收方用户标识、并且特征信息匹配于所述待检验消息的验证信息的下发消息时,向所述终端回复通过验证的响应。
本申请提供的一种消息防伪的实现装置,应用消息服务器上,包括:
下发消息生成单元,用于生成下发消息,并根据接收方用户标识发送所述下发消息;
特征信息记录单元,用于将所述下发消息的接收方用户标识和特征信息写入下发消息记录,用来由验证服务器将下发消息的接收方用户标识和特征信息、与待检验消息的接收方用户标识和验证信息进行匹配,以确定待检验消息是否通过验证。
本申请提供的一种消息防伪的实现装置,应用终端上,包括:
验证请求上传单元,用于根据用户的操作,向验证服务器上传消息验证请求;所述消息验证请求中携带待检验消息的接收方用户标识和验证信息,供验证服务器将待检验消息的接收方用户标识和验证信息、与下发消息记录中下发消息的接收方用户标识和特征信息进行匹配,以确定待检验消息是否通过验证;
验证响应接收单元,用于接收验证服务器返回的带有验证结果的消息验证响应,并向用户显示验证结果。
由以上技术方案可见,本申请的实施例中,由向用户下发消息的消息服务器记录下发消息的接收方用户标识和特征信息,在终端将待检验消息的接收方用户标识和验证信息上传给验证服务器后,验证服务器查找是否有与待检验消息匹配的下发消息,以决定待检验消息是否通过验证;本申请的实施例为用户提供了对接收消息的真伪进行验证的机制,能够识别出假冒合法主体发送的虚假消息,提高了用户的网络安全。
具体实施方式
本申请的实施例提出一种消息防伪的实现方法,在网络侧记录发送给用户的下发消息的相关信息,用户在对所接收消息的真伪存疑时,可以向验证服务器发送带有待检验消息相关信息的消息验证请求,验证服务器根据所记录的下发消息相关信息,对用户的待检验消息进行核实,以确定待检验消息的真伪,使得用户能够借助验证服务器来识别虚假消息,而不必依赖经验自行判断消息的真伪,在为用户提供更好的安全性的同时减轻了用户的负担,从而解决现有技术中存在的问题。
本申请实施例应用的一种网络环境如图1所示,消息服务器负责向用户下发消息,验证服务器负责响应终端对待检验消息进行验证的请求,当用户的第一终端接收到待检测消息后,用户可以通过第二终端向验证服务器发起对该待检测消息的验证请求。其中,消息服务器与验证服务器可以是同一服务器,第一终端与第二终端也可以是同一终端。
消息服务器、验证服务器、第一终端或第二终端之间通过相互网络可访问,第一终端或第二终端可以是手机、平板电脑、PC(Personal Computer,个人电脑)、笔记本等设备;消息服务器或验证服务器可以是一个物理或逻辑服务器,也可以是由两个或两个以上分担不同职责的物理或逻辑服务器、相互协同来实现本申请实施例中消息服务器或验证服务器的各项功能。本申请实施例对第一终端或第二终端、消息服务器和验证服务器的种类,以及第一终端或第二终端、消息服务器和验证服务器之间通信网络的类型、协议等均不做限定。
本申请实施例中,消息防伪的实现方法应用在验证服务器上的流程如图2所示,应用在消息服务器上的流程如图3所示,应用在终端上的流程如图4所示。
在消息服务器上,步骤310,生成下发消息,并根据接收方用户标识发送生成的下发消息。
本申请实施例中的消息可以是由消息服务器能够发送到终端的任何形式的信息,例如短信、邮件、即时消息、向安装在终端上的客户端应用程序推送的消息等等,消息服务器可以参照现有技术来生成上述形式或其他形式的消息,不再赘述。对应的,下发消息的接收方用户标识可以是用户的移动终端标识(如手机号码、移动用户国际识别码)、邮箱地址、即时消息系统的用户名、用户在应用系统中的登录账号等等。
在生成下发消息时,可以生成用于消息验证的附加信息,并将附加信息添加到下发消息的完整消息体中,发送给用户。例如,消息服务器可以按照一定的算法为每条下发消息生成防伪码,防伪码和接收方用户标识的组合唯一对应于一条下发消息;消息服务器将防伪码封装在对应的下发消息中进行发送。生成防伪码的具体算法可参照现有技术中各种生成不重复随机码的方法实现,不再赘述。
在消息服务器上,步骤320,将下发消息的接收方用户标识和特征信息写入下发消息记录,用来由验证服务器将下发消息的接收方用户标识和特征信息、与待检验消息的接收方用户标识和验证信息进行匹配,以确定待检验消息是否通过验证。
消息服务器在发送下发消息后,将下发消息的接收方用户标识和下发消息的特征信息写入到下发消息记录中。消息服务器可以将下发消息记录保存在本地,也可以保存在网络中可以由消息服务器和验证服务器访问的任意存储位置,还可以将下发消息记录以及对下发消息记录的更新发送给验证服务器,由验证服务器进行保存。
与下发消息关联的各种信息中,任何与用户终端接收消息相关的信息、以及根据这些信息以某种算法生成的映射信息,都可以用来作为下发消息的特征信息。例如,下发消息的发送时间、消息内容、以及发送时间的哈希值、消息内容的哈希值,都可以用作下发消息的特征信息。此外,还可以将用于进行消息验证的附加信息作为下发消息的特征信息,例如为每条下发消息生成的防伪码。
在不同的应用场景中,可以根据该场景的实际需求、下发消息的具体形式等因素来决定下发消息特征信息的组成,本申请的实施例不做限定。在一种实现方式中,可以将根据下发消息的消息内容以预定算法生成的内容特征值作为全部或部分特征信息,内容特征值的计算通常在消息服务器上进行。例如,可以由消息服务器将下发消息的消息内容和接收方用户标识输入到预定摘要算法中,计算出内容摘要并将其作为下发消息的内容特征值。
在终端上,步骤410,根据用户的操作,向验证服务器上传消息验证请求。消息验证请求中携带待检验消息的接收方用户标识和验证信息,供验证服务器将待检验消息的接收方用户标识和验证信息、与下发消息记录中下发消息的接收方用户标识和特征信息进行匹配,以确定待检验消息是否通过验证。
在验证服务器上,步骤210,接收终端上传的消息验证请求,消息验证请求中携带待检验消息的接收方用户标识和验证信息。
当用户收到消息后,如果对消息的真假存在疑问,可以将收到的消息作为待检验消息,通过预定的操作令终端向验证服务器发起消息验证请求。终端从待检验消息消息的相关信息中提取待检验消息的验证信息,将用于接收待检验消息的用户标识和验证信息封装在消息验证请求中发送给验证服务器。
采用待检验消息的哪些相关信息作为验证信息,由于终端提交的验证信息将被验证服务器用于与下发消息的特征信息相匹配,因而通常按照对应于下发消息的特征信息的方式来确定。
需要说明的是,本申请的实施例中,用户可以在接收待检验消息的终端上向验证服务器发起请求,也可以在与接收待检验消息终端的类型相同或不同的其他终端上发起请求。当用户在非接收待检验消息的终端的其他终端上发起请求时,通常发起请求的终端需要在用户的干预下获取待检验消息的接收方用户标识和/或验证信息,具体的获取方式可以根据两个终端的硬件和软件类型、待检验消息的形式等来由用户手动、或参照现有技术实现,不再赘述。
在验证服务器上,步骤220,当下发消息记录中具有与待检验消息相同的接收方用户标识、并且特征信息匹配于待检验消息的验证信息的下发消息时,向终端回复通过验证的响应。
在终端上,步骤420,接收验证服务器返回的带有验证结果的消息验证响应,并向用户显示验证结果。
验证服务器采用对应于消息服务器处理下发消息记录的方式来获取下发消息记录,或将待检验消息与下发消息记录中的记录项(即各条下发消息)进行匹配。例如,验证服务器可以向消息服务器请求下发消息记录,也可以从网络中的预设存储位置读取由消息服务器维护的下发消息记录,还可以由消息服务器将下发消息记录以及对下发消息记录的更新发送给验证服务器,验证服务器读取自己保存的下发消息记录即可。
在收到终端提交的消息验证请求后,验证服务器从中提取待检验消息的接收方用户标识和验证信息,在下发消息记录中查找具有相同接收方用户标识的下发消息,将查找到的下发消息的特征信息与待检验消息的验证信息相匹配,如果有能够匹配与待检验消息的下发消息,则待检验消息是由消息服务器下发的,待检验消息通过验证;验证服务器以通过验证为验证结果,向终端返回消息验证响应。如果下发消息记录中没有具有相同接收方用户标识的下发消息,或具有相同接收方用户标识的下发消息中没有与待检验消息的验证信息相匹配的下发消息,则待检验消息不能通过验证;验证服务器以验证失败为验证结果,向终端返回消息验证响应。
终端在收到验证服务器返回的带有验证结果的消息验证响应后,将通过验证或验证失败的结果显示给用户。
当下发消息的特征信息、对应的待检验消息的验证信息所包含的具体内容不同时,验证服务器的匹配处理、以及对消息的验证程度将有所区别。以下举例说明几种特征信息和验证信息的可能选择方式,以及相应的匹配处理过程。
在第一种方式中,可以将下发消息的消息内容作为特征信息,对应的将待检验消息的消息内容作为验证信息。验证服务器对比具有相同接收方用户标识的下发消息和待检验消息的消息内容,如果有一条下发消息的内容与待检验消息一致,则待检验消息通过验证。这种方式能够非常准确的验证消息的真实性,但是需要保存的下发消息记录往往会过于庞大,造成服务端的存储压力,影响查询和匹配记录的速度。
在第二种方式中,可以将由消息服务器根据下发消息的消息内容以预定算法压缩为下发消息的内容特征值(如哈希值或内容摘要),将内容特征值作为特征信息。对应的,可以由终端根据待检验消息的消息内容,以同样的预定算法生成待检验消息的内容特征值,来作为验证信息上传给验证服务器;也可以由终端将待检验消息的消息内容作为验证信息上传,由验证服务器采用同样的预定算法根据待检验消息的消息内容生成待检验消息的内容特征值,与具有相同接收方用户标识的下发消息的内容特征值进行比对,如果有一条下发消息的内容特征值与待检验消息相同,则通过验证。相对于第一种方式,第二种方式对验证的准确性稍有降低,但能够大大减少下发消息记录的数据量,提高验证服务器的响应速度。
在第三种方式中,可以将消息服务器生成的防伪码作为下发消息的特征信息。消息服务器生成每条下发消息的防伪码,并将防伪码和消息内容分别作为完整消息体的一部分发送给用户,防伪码与接收方用户标识的组合与下发消息一一对应。终端将待检验消息的防伪码作为验证信息上传给验证服务器。验证服务器将具有相同接收方用户标识的下发消息和待检验消息的防伪码进行比对,如果有一条下发消息的防伪码与待检验消息相同,则通过验证。这种方式能够验证消息服务器是否向用户下发了带有该防伪码的消息,但是不能确认消息内容无误。如果消息服务器下发的消息被不法分子截获,修改消息内容但不修改防伪码后再发送给用户,会导致消息验证结果错误。
在第四种方式中,可以将第二种方式中的内容特征值和第三种方式中的防伪码一并作为下发消息的特征信息。对应的,终端将待检验消息的内容特征值或消息内容(由验证服务器据以生成待检验消息的内容特征值)、和待检验消息中携带的防伪码作为验证信息,上传给验证服务器。验证服务器将具有相同接收方用户标识的下发消息和待检验消息的防伪码、内容特征值进行比对,如果有一条下发消息的防伪码及内容特征值都与待检验消息相同,则通过验证。这种方式既可以减小下发消息记录的数据量,提高验证服务器的响应速度,又可以提高验证的准确性。
由于验证信息通常都包含在待检验消息的完整消息体中,为了减少用户或终端对待检验消息的处理,可以由终端将待检验消息的完整消息体封装在消息验证请求中,验证服务器在收到消息验证请求后,从中提取待检验消息的完整消息体,从完整消息体中解析出待检验消息的验证信息。
验证服务器可以按照下发消息的格式来将待检验消息的完整消息体拆解为各个部分,从而得到作为某一部分的验证信息。例如,用户在手机上收到第三方支付平台发送的账单短信,完整消息体为:“你的000****0000账户9月账单100元,10月10日将自动还款或去m.zhifu.com/J/thaUu立即还款。防伪码qaz。【第三方平台名称】”。根据该第三方支付平台下发账单短信的格式,验证服务器可以从该完整消息体中解析出消息内容(“你的000****0000账户9月账单100元,10月10日将自动还款或去m.zhifu.com/J/thaUu立即还款”)、防伪码(“qaz”)、和发送方签名(“第三方平台名称”),其中消息内容和防伪码在上述第四种实现方式中将作为待检验消息的验证信息。
在本申请的实施例中,消息服务器和验证服务器可以是同一个,也可以是由验证服务器来对一个到多个消息服务器的下发消息进行验证,并且这些消息服务器可以是采用同一个渠道,也可以是采用不同的渠道向用户下发消息。换言之,可以由下发消息的服务器来对自己下发的消息和冒用自己身份下发的消息进行验证,可以由验证服务器来对某个渠道的若干个消息服务器下发的消息或冒用这些消息服务器下发的消息进行验证,也可以由验证服务器来对多个渠道的多个消息服务器下发的消息或冒用这些消息服务器下发的消息进行验证。其中,消息服务器采用的渠道对应于某个应用系统的消息形式的组合,例如,某个第三方支付平台的短信对应于一个渠道,该第三方支付平台的即时消息对应于另一个渠道,该第三方支付平台的客户端App(应用程序)推送消息对应于第三个渠道。
当验证服务器针对多个渠道的多个消息服务器提供消息验证服务时,这些渠道中,不同渠道的接收方用户标识有可能相同。为了避免下发消息记录中不同渠道下发给同一个用户的消息之间的混淆,可以由消息服务器将下发消息的下发渠道也写入下发消息记录中;由终端获取待检验消息的接收渠道(可以由用户输入,或由终端通过接收待检验消息的进程自动识别等方式来获取)并加接收渠道封装在消息验证请求中发送给验证服务器;验证服务器将具有相同接收方用户标识、并且下发渠道与接收渠道相同的下发消息的特征信息与待检验消息的验证信息相比对,如果有一条下发消息与待检验消息相匹配,则通过验证。
另外需要说明的是,为了避免不法分子设置虚假的验证服务器,来对其冒用合法主体发送的消息进行验证,本申请的实施例中,在消息服务器下发给用户的各种消息中,不会带有验证服务器的地址链接或其他访问方式。访问验证服务器的方式可以在官网、官微上提供给用户,还可以通过其他宣传途径令用户知晓。
可见,本申请的实施例中,由向消息服务器记录下发消息的接收方用户标识和特征信息,用户在对接收的消息有疑虑时,可以将带有待检验消息的接收方用户标识和验证信息的消息验证请求发送给验证服务器,由验证服务器根据下发消息记录来判定待检验消息是否为真。本申请的技术方案为用户提供了鉴定接收消息是否由合法主体发送的机制,用户不必依赖主观经验进行判断,在提高用户安全性的同时减轻了用户的负担。
在本申请的一个应用示例中,第三方支付平台通过多种渠道来向用户下发消息,这些渠道及其官方服务接口包括:短信的特服号、邮件的官方邮箱、即时消息系统的官方账号、办公服务系统的官方账号;对应的,这些渠道的用户标识分为是:用户的手机号码、用户在该第三方支付平台的注册邮箱、用户在该即时消息系统的用户名、用户在该办公服务系统的用户名。
上述渠道分别有各自的消息服务器。每个消息服务器为要下发的消息分配一个该消息在本服务器上的序号,作为消息ID(编号)。在向用户发送消息前,消息服务器以要下发消息的消息ID和当前时间输入到预定的哈希算法中,以所得哈希值的后四位作为该下发消息的防伪码。消息服务器在下发消息记录表中查找具有该下发消息接收方用户标识的表项(即已经下发给同一用户的其他下发消息)是否有同样的防伪码,如果有则重新生成防伪码,直到与具有相同接收方用户标识的表项没有重复为止。
消息服务器将防伪码添加在消息内容的后面,生成下发消息,按照该渠道的用户标识发送消息。消息服务器以下发消息的消息内容和接收方用户标识为输入,采用预定摘要算法生成内容摘要,以内容摘要和防伪码作为下发消息的特征信息。
消息服务器在下发消息记录表中增加对应于该下发消息的表项,下发消息记录表保存在预定的网络位置。一种下发消息记录表的结构如表1所示:
索引号 |
接收方用户标识 |
防伪码 |
内容摘要 |
发送时间 |
1 |
|
|
|
|
2 |
|
|
|
|
表1
表1中,发送时间为消息服务器发送该下发消息的时间。
上述第三方支付平台的各个官方服务接口也用来作为用户访问验证服务器的入口。用户在收到看似第三方支付平台发送的消息时,可以指令终端将待检验消息的完整消息体、接收待检验消息的渠道和接收方用户标识封装消息验证请求中,发送到任意一个上述官方服务接口。用户不仅可以用接收待检验消息的渠道来验证待检验消息,也可以用其他渠道来进行消息真伪的检验。
对通过各个官方服务接口收到的消息验证请求,验证服务器从中提取出待检验消息的完整消息体、接收渠道和接收方用户标识。验证服务器按照第三方平台的消息服务器下发消息的格式(不同的下发渠道可能对应于相同或不同的消息格式),对待检验消息的完整消息体进行解析,从中得到待检验消息的消息内容和防伪码。验证服务器以待检验消息的消息内容和接收方用户标识作为输入,采用与消息服务器相同的预定摘要算法生成待检验消息的内容摘要,以内容摘要和防伪码作为待检验消息的验证信息。
验证服务器获取对应于待检验消息接收渠道的消息服务器保存在预定网络位置的下发消息记录表,在该下发消息记录表中查找是否有接收方用户标识、防伪码和内容摘要都与待检验消息相同的表项,如果有,待检验消息是由对应于其接收渠道的消息服务器下发的,验证通过;如果没有则该待检验消息验证失败。
验证服务器将待检验消息的验证结果在消息验证响应中发送给发起请求的终端。终端在收到消息验证响应后,将其中的验证结果显示给用户。
与上述流程实现对应,本申请的实施例还提供了一种应用在验证服务器上的消息防伪的实现装置、一种应用在消息服务器上的消息防伪的实现装置,和一种应用在终端上的消息防伪的实现装置。这三种装置均可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为逻辑意义上的装置,是通过终端、验证服务器或消息服务器的CPU(CentralProcess Unit,中央处理器)将对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言,除了图5所示的CPU、内存以及非易失性存储器之外,消息防伪的实现装置所在的终端通常还包括用于进行无线信号收发的芯片等其他硬件,消息防伪的实现装置所在的验证服务器或消息服务器通常还包括用于实现网络通信功能的板卡等其他硬件。
图6所示为本申请实施例提供的一种消息防伪的实现装置,应用验证服务器上,所述验证服务器可获取到下发消息记录,所述下发消息记录中包括若干条下发消息的接收方用户标识和特征信息,所述装置包括验证请求接收单元和验证请求匹配单元,其中:验证请求接收单元用于接收终端上传的消息验证请求,所述消息验证请求中携带待检验消息的接收方用户标识和验证信息;验证请求匹配单元用于当所述下发消息记录中具有与待检验消息相同的接收方用户标识、并且特征信息匹配于所述待检验消息的验证信息的下发消息时,向所述终端回复通过验证的响应。
可选的,所述下发消息的特征信息包括:下发消息的防伪码;所述待检验消息的验证信息包括:待检验消息中携带的防伪码,用来与下发消息的防伪码进行匹配。
可选的,所述下发消息的特征信息包括:根据下发消息的消息内容以预定算法生成的内容特征值;所述待检验消息的验证信息包括:待检验消息的消息内容;
一个例子中,所述装置还包括:待检验内容特征值单元,用于根据待检验消息的消息内容,以预定算法生成待检验消息的内容特征值,用来与下发消息的内容特征值进行匹配。
上述例子中,所述内容特征值可以包括:根据消息内容和接收方用户标识,采用预定摘要算法生成的内容摘要。
可选的,所述消息验证请求中携带有待检验消息的完整消息体;所述装置还包括:消息体解析单元,用于从待检验消息的完整消息体中解析出所述待检验消息的验证信息。
可选的,所述用户标识包括:用户的移动终端标识、邮箱地址、和/或即时消息系统的用户名;所述下发消息记录中还包括:下发消息的下发渠道;所述消息验证请求中还包括:待检验消息的接收渠道,用来与下发消息的下发渠道进行匹配。
图7所示为本申请实施例提供的一种消息防伪的实现装置,应用消息服务器上,包括下发消息生成单元和特征信息记录单元,其中:下发消息生成单元用于生成下发消息,并根据接收方用户标识发送所述下发消息;特征信息记录单元用于将所述下发消息的接收方用户标识和特征信息写入下发消息记录,用来由验证服务器将下发消息的接收方用户标识和特征信息、与待检验消息的接收方用户标识和验证信息进行匹配,以确定待检验消息是否通过验证。
可选的,所述下发消息生成单元具体用于:生成下发消息的防伪码,并将其封装在下发消息中,并根据接收方用户标识发送所述下发消息;所述防伪码和所述接收方用户标识的组合与所述下发消息一一对应;所述下发消息的特征信息包括:下发消息的防伪码。
一个例子中,所述下发消息的特征信息包括:根据下发消息的消息内容以预定算法生成的内容特征值。
上述例子中,所述装置还可以包括:下发内容特征值单元,用于根据下发消息的消息内容和接收方用户标识,采用预定摘要算法生成的内容摘要并将其作为下发消息的内容特征值。
图8所示为本申请实施例提供的一种消息防伪的实现装置,应用终端上,包括验证请求上传单元和验证响应接收单元,其中:验证请求上传单元用于根据用户的操作,向验证服务器上传消息验证请求;所述消息验证请求中携带待检验消息的接收方用户标识和验证信息,供验证服务器将待检验消息的接收方用户标识和验证信息、与下发消息记录中下发消息的接收方用户标识和特征信息进行匹配,以确定待检验消息是否通过验证;验证响应接收单元用于接收验证服务器返回的带有验证结果的消息验证响应,并向用户显示验证结果。
可选的,所述待检验消息的验证信息包括:待检验消息中携带的防伪码。
可选的,所述待检验消息的验证信息包括:待检验消息的消息内容。
可选的,所述装置还可以包括:消息体封装单元,用于将待检验消息的完整消息体封装在消息验证请求中,供验证服务器从所述完整消息体中解析出待检验消息的验证信息。
可选的,所述装置还包括:接收渠道单元,用于获取所述待检验消息的接收渠道,并封装在消息验证请求中。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitorymedia),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。