发明内容
鉴于此,本发明提供了一种新的二维码登录方案,以力图解决或至少缓解上面存在的问题。
根据本发明的一个方面,提供了一种二维码登陆方法,适于在第二服务器中执行,该方法包括:接收来自第一服务器的第一请求,第一请求包括应用标识,由第三方应用生成,请求获取二维码;根据应用标识生成第一信息,将第一信息发送至第一服务器,以便第一服务器将该第一信息发送至第三服务器,由第三服务器生成包含第一信息的二维码后,返回二维码地址给第一服务器,并由第一服务器将二维码地址以及与第一请求关联的事件标识发送给第三方应用;接收来自第一服务器的第二信息,该第二信息由客户端扫描在第三方应用上显示的二维码后生成,包括第一信息;根据第二信息生成用户标识,将用户标识发送至第一服务器,以便第一服务器关联事件标识和用户标识,并响应于第三方应用发送的携带事件标识的第二请求,发送用户标识至第三方应用,供第三方应用登录该用户标识对应的第三方账户。
可选地,在根据本发明的二维码登陆方法中,根据应用标识生成第一信息的步骤之前包括:验证第一请求,验证通过则根据应用标识生成第一信息。
可选地,在根据本发明的二维码登陆方法中,第一请求还包括第一签名,验证第一请求的步骤包括:根据应用标识获取该应用标识关联的应用密钥,根据应用密钥和应用标识生成第一验证签名;将该第一验证签名与第一签名比对,若一致则验证通过,否则验证失败;将验证消息返回至第一服务器。
可选地,在根据本发明的二维码登陆方法中,第一信息包括应用标识、指定域名、时间戳以及随机数。
可选地,在根据本发明的二维码登陆方法中,根据第二信息生成用户标识的步骤之前包括:验证第二信息,验证通过则根据第二信息生成用户标识。
可选地,在根据本发明的二维码登陆方法中,第二信息还包括用户信息,验证第二信息的步骤包括:验证第二信息中用户信息是否存在;验证第二信息中第一信息是否包括指定域名;若用户信息存在、第一信息包括指定域名,则验证通过,否则验证失败;将验证消息返回至第一服务器。
可选地,在根据本发明的二维码登陆方法中,第二信息还包括客户端信息,接收第二信息的步骤包括:接收客户端信息,将客户端信息与用户信息关联后存储。
可选地,在根据本发明的二维码登陆方法中,根据第二信息生成用户标识的步骤包括:根据应用标识和用户信息生成用户标识。
可选地,在根据本发明的二维码登陆方法中,根据应用标识和用户信息生成用户标识的步骤包括:将应用标识和用户信息经过笛卡尔积运算变换成用户标识。
可选地,在根据本发明的二维码登陆方法中,该方法还包括:接收来自第一服务器的第二请求,第二请求包括应用标识和第二签名;根据第二签名验证第二请求,将验证消息发送至第一服务器。
可选地,在根据本发明的二维码登陆方法中,第二请求还包括事件标识,验证第二请求的步骤包括:根据应用标识获取该应用标识关联的应用密钥,根据应用密钥、应用标识和事件标识生成第二验证签名;将该第二验证签名与第二签名比对,若一致则验证通过,否则验证失败。
根据本发明的另一个方面,提供了一种第二服务器,适于与第一服务器交互,该第二服务器包括:接收单元,适于接收来自第一服务器的第一请求,所述第一请求包括应用标识,由第三方应用生成,请求获取二维码;还适于接收来自第一服务器的第二信息,所述第二信息由客户端扫描在第三方应用上显示的二维码后生成,包括第一信息;控制单元,适于根据应用标识生成第一信息,将第一信息发送至第一服务器,以便第一服务器将第一信息发送至第三服务器,由第三服务器生成包含第一信息的二维码后返回二维码地址给第一服务器,并由第一服务器将二维码地址以及与第一请求关联的事件标识发送给第三方应用;还适于根据第二信息生成用户标识;以及反馈单元,适于将第一信息发送至第一服务器,以便第一服务器将第一信息发送至第三服务器,由第三服务器生成包含第一信息的二维码后,返回二维码地址给第一服务器,并由第一服务器将二维码地址以及与第一请求关联的事件标识发送给第三方应用;还适于将用户标识发送至第一服务器,以便第一服务器关联事件标识和用户标识,并响应于第三方应用发送的携带事件标识的第二请求,发送用户标识至第三方应用,供第三方应用登录该用户标识对应的第三方账户。
可选地,在根据本发明的第二服务器中,还包括验证单元,适于验证第一请求,验证通过则控制单元根据应用标识生成第一信息。
可选地,在根据本发明的第二服务器中,第一请求包括第一签名,验证单元还适于根据应用标识获取该应用标识关联的应用密钥,根据应用密钥和应用标识生成第一验证签名;还适于将该第一验证签名与第一签名比对,若一致则验证通过,否则验证失败,反馈单元将验证消息返回至第一服务器。
可选地,在根据本发明的第二服务器中,第一信息包括应用标识、指定域名、时间戳以及随机数。
可选地,在根据本发明的第二服务器中,验证单元还适于验证第二信息,验证通过则控制单元根据第二信息生成用户标识。
可选地,在根据本发明的第二服务器中,第二信息还包括用户信息,验证单元还适于验证第二信息中用户信息是否存在,还适于验证第二信息中第一信息是否包括指定域名,若用户信息存在、第一信息包括指定域名,则验证通过,否则验证失败;反馈单元将验证消息返回至第一服务器。
可选地,在根据本发明的第二服务器中,第二信息还包括客户端信息,接收单元还适于接收客户端信息,控制单元将该客户端信息与用户信息关联后存储。
可选地,在根据本发明的第二服务器中,控制单元适于根据应用标识和所述用户信息生成用户标识。
可选地,在根据本发明的第二服务器中,控制单元适于将应用标识和用户信息经过笛卡尔积运算变换成用户标识。
可选地,在根据本发明的第二服务器中,接收单元还适于接收来自第一服务器的第二请求,第二请求包括应用标识和第二签名;验证单元还适于根据第二签名验证第二请求,反馈单元还适于将验证消息发送至第一服务器。
可选地,在根据本发明的第二服务器中,第二请求还包括事件标识,验证单元还适于根据应用标识获取该应用标识关联的应用密钥,根据应用密钥、应用标识和事件标识生成第二验证签名;还适于将该第二验证签名与第二签名比对,若一致则验证通过,否则验证失败。
根据本发明的还有一个方面,提供了一种二维码登录系统,适于登录第三方应用,包括:客户端、第一服务器、根据本发明的第二服务器、以及第三服务器,其中:第一服务器适于与客户端、第二服务器、第三服务器交互,响应第三方应用的第一请求、第二请求;第三服务器适于与第一服务器交互,生成二维码后返回二维码地址;客户端驻留在移动终端中,适于扫描第三方应用显示的所述二维码,还适于与第一服务器交互。
根据本发明的二维码登陆方案,通过扫描二维码可直接登录用户在第三方应用的账户,实现快速、安全的账号认证登陆,解决了过去的繁琐登录问题。并且本发明通过生成唯一固定的标识将用户在客户端的账户与用户在第三方应用的账户建立联系,因此整个登录过程不会收集用户在第三方应用的任何信息,解决了帐号安全、撞库风险等问题。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。
图1示出了根据本发明一个示例性实施例的二维码登录系统100的结构框图。二维码登录系统100通过网络与第三方应用相连,用户可通过二维码登录系统100扫描二维码直接登录第三方应用,无需输入其在第三方应用上的第三方账户和密码。这里,第三方应用可以是需要账户登录的、安装在移动终端里的各种应用,也可以是第三方网站,本发明对此不做限制。如图1所示,二维码登录系统100可以包括第一服务器110、第二服务器120、第三服务器130以及客户端140,第一服务器110通过网络分别与第二服务器120、第三服务器130以及客户端140连接。
图2示出了根据本发明一个示例性实施例的第一服务器110的结构框图,第一服务器110可以包括接收单元111、控制单元112以及响应单元113,还可以包括转发单元114、验证单元115。
图3示出了根据本发明一个示例性实施例的第二服务器120的结构框图,第二服务器120可以包括接收单元121、控制单元122以及反馈单元123,还可以包括验证单元124、存储单元125。
第三方应用向第一服务器110发送第一请求,请求获取二维码。第一服务器110中接收单元111适于接收来自第三方应用的第一请求,第一请求通常为http请求,可由第三方应用调用其预先嵌入的API接口生成,API由二维码登录系统100厂商提供维护。可选地,第一请求包括应用标识,该应用标识可唯一地标识第三方应用身份,一个合法的应用标识例如:“Fqlw4Z2KCqHzvw8YN0eUpM9KgTQ47iWf”。而应用标识由第二服务器120预先创建。具体地,在第三方应用生成第一请求之前,第三方应用向第二服务器120发出创建请求,请求创建应用。第二服务器120中接收单元121响应该请求,与接收单元121相连的控制单元122创建与该第三方应用唯一关联的应用标识(app_id)并存储至存储单元125,而后反馈单元123将应用标识返回至第三方应用。
第一请求还可以包括第一签名,通常可通过验证第一签名来确保数据交互的安全性,防止数据被篡改。该第一签名可根据第三方应用的应用密钥生成,一个合法的应用密钥例如:“qms7LwYXgw5FbnVdwYyA”。应用密钥与应用标识相同地,在第二服务器120响应来自第三方应用的创建请求时创建,第二服务器120中控制单元122创建与该第三方应用唯一关联的应用密钥(app_key)并存储至存储单元125,而后反馈单元123将应用密钥返回至第三方应用。
每一次第三方应用向第一服务器110发送请求,均需要向第一服务器110传递一个签名(signature),第一服务器110将请求转发至第二服务器120验证,第二服务器120中验证单元124会根据该请求中的参数值计算签名,而后将其与请求中的签名比对,比对一致则数据安全,验证通过。其中请求传递的签名与第二服务器120生成的签名计算原理相同,具体如下:
将请求中除签名之外的其他参数按参数名字典排序后,按以下格式拼接成字符串:$参数名1=$参数值1$参数名2=$参数值2...$参数名n=$参数值n$app_key,并将拼好的字符串使用MD5加密,最后得到的字符串即为该请求的签名。
转发单元114与接收单元111相连,适于将接收单元111接收的第一请求转发至第二服务器120。第二服务器120中接收单元121适于接收来自第一服务器110的第一请求,验证单元124验证第一请求。根据本发明的一个实施方式,验证单元124通过验证第一签名来验证第一请求,确保第一请求数据没有被篡改。具体地,第二服务器120中存储单元125存储有第三方应用的应用标识和应用密钥,验证单元124可根据第一请求中携带的应用标识获取该应用标识对应的应用密钥,根据该应用密钥和应用标识生成第一验证签名。这里假定第三方应用获取的应用标识和应用密钥如下:
$app_id='Fqlw4Z2KCqHzvw3YN0eUpM9KgTQ47iWf';
$app_key='qms7LwYXgw3FbnVdwYyA';
除第一签名外,该第一请求共一个参数app_id,则按照上述签名生成原理,可根据app_id拼接字符串:'app_id='.$app_id.$app_key,之后,把拼接的字符串,使用MD5加密:md5('app_id='.$app_id.$app_key),即得到第一验证签名。验证单元124将该第一验证签名与第一签名比对,若一致则验证通过,否则验证失败,而后反馈单元123将该验证消息(验证通过或者验证失败)返回至第一服务器110。
若验证通过,第二服务器120中控制单元122则根据应用标识生成第一信息,第一信息包括该应用标识,通常为字符串,此外,内容还可以包括指定域名、时间戳以及随机数。具体地,控制单元122将应用标识、时间戳和随机数拼接并加密,其中加密方式可以是Base64编码,本发明对此不做限制。加密后在首端加上指定域名,即得到类似于以下的第一信息:“http://yc.im/bjGArUqO91RnS5sSeF2X9yaILOHB/RbrEb3KTIfdi0GAWbho70DwXyA4Xhfs/VCqFywQszmjzwMHG6TSRaBcKGg==”。
反馈单元123将上述第一信息同验证消息返回至第一服务器110,接收单元111接收来自第二服务器120的验证消息和第一信息,若验证消息为验证通过,与接收单元111相连的控制单元112则创建与第一请求关联的事件标识,并存储,其中事件标识可唯一地标识第一请求。
同时,转发单元114可以将第一信息转发至第三服务器130,第三服务器130接收第一信息后根据该第一信息生成二维码,该二维码包含第一信息,并将该二维码的地址返回至第一服务器110。例如,二维码地址可以如下:
https://qrcode.yangcong.com/qrcode/1432774598.27qoUQy3.png。
接收单元111接收来自第三服务器130的二维码地址,控制单元112将第一请求的事件标识与生成该二维码的第一信息进行关联,例如,以事件标识为key,第一信息为value,建立二者一一对应的映射表。
而后与控制单元112相连的响应单元113响应第一请求,将事件标识与二维码地址返回至第三方应用。可选地,还可以返回状态码(status)和相应的状态码描述(description),其中状态码为一个表示请求结果的数字,状态码描述为对应状态码含义的文字描述,表1列出了响应第一请求返回的几种状态码与相应的状态码描述:
表1
响应单元113的返回示例如下:
返回的数据通常为json格式。
而后,第三方应用接收二维码地址和事件标识,在其界面上显示该地址对应的二维码,生成包括该事件标识的第二请求发送至第一服务器110,第二请求请求获取该事件标识所对应的事件响应结果,例如获取等待用户扫描二维码产生响应或直至返回超过事件标识有效时间不可重试。该事件标识有效时间可以为300s。
第一服务器110中接收单元111接收来自第三方应用的第二请求。可选地,第二请求除事件标识外还可以包括应用标识、第二签名。转发单元114将第二请求发送至第二服务器120。
第二服务器120中接收单元121接收来自第一服务器110的第二请求,验证单元124验证第二请求。根据本发明的一个实施方式,验证单元124通过验证第二签名来验证第二请求,确保第二请求数据没有被篡改。具体地,存储单元125存储有第三方应用的应用标识和应用密钥,验证单元124可根据第二请求中携带的应用标识查询获取该应用标识对应的应用密钥,根据该应用标识、事件标识和应用密钥生成第二验证签名,即md5('app_id='.$app_id.'event_id='.$event_id.$app_key),具体签名生成原理已在关于第一请求的描述中详细说明,此处不再赘述。
验证单元124将该第二验证签名与第二签名比对,若一致则验证通过,否则验证失败,而后反馈单元123将该验证消息(验证通过或者验证失败)返回至第一服务器110。
第一服务器110中接收单元111接收来自第二服务器120的该验证消息,若验证通过,控制单元112根据第二请求中事件标识查询该事件响应结果,响应单元113可以响应第二请求,返回状态码和相应的状态码描述,表2列出了响应第二请求返回的几种状态码与相应的状态码描述:
表2
若返回状态码为602“等待用户响应,可重试”,第三方应用可以在事件标识有效时间内重试发送第二请求至第一服务器110,直至返回状态码200“请求成功”或者603“用户响应超时,不可重试”为止。
在上述事件标识有效时间内,用户通过客户端140扫描第三方应用显示的二维码,图4示出了根据本发明一个实施例的客户端140的结构框图。
客户端140驻留在移动终端中,可以包括扫描单元141、交互单元142以及显示单元143,还可以包括验证单元144。扫描单元141适于扫描第三方应用显示的二维码,获取该二维码包含的内容,即第一信息。与扫描单元141相连的验证单元144验证该第一信息,确保二维码来源安全。具体地,验证单元144可验证第一信息是否包括指定域名,例如,是否包含http://yc.im/,若包括,则二维码来源安全,验证通过。
而后交互单元142将包括第一信息的第二信息发送至第一服务器110,以便第一服务器110对第二信息进行处理后,返回处理消息至客户端140。其中第二信息还可以包括用户信息(即客户端当前登录的用户账户,用户账户可以是用户手机号等)和客户端信息,客户端信息可以包括客户端标识(可唯一地标识客户端140)、wifi信息、经纬度信息以及设备信息。
第一服务器110中接收单元111接收来自客户端140扫描二维码后生成的第二信息,与接收单元111相连的验证单元115验证第二信息中客户端信息,确保该信息来自客户端140。可选地,客户端信息包括随机密钥(secret),随机密钥通常在客户端140利用用户信息登录第一服务器110后由控制单元112分配。接收单元140接收来自客户端140的随机密钥后,验证单元115验证该随机密钥是否与第一服务器110为该客户端140分配的值一致,若一致,则验证通过,否则,验证失败。
验证通过后,转发单元114将第二信息转发至第二服务器120,第二服务器120中接收单元121接收来自第一服务器110的第二信息,验证单元124验证第二信息后反馈单元123将验证消息返回至第一服务器110。可选地,验证单元124可以验证第二信息中用户信息是否存在、以及验证第二信息中第一信息是否包括指定域名,若用户信息存在且第一信息包括指定域名,则验证通过,否则验证失败。根据本发明的另一个实施方式,第二服务器120中接收单元121还适于接收客户端信息,控制单元122还适于将该客户端信息与用户信息关联后存储至存储单元125。
验证通过后,第二服务器120中控制单元122根据第二信息生成用户标识,根据本发明的一个实施方式,控制单元122可以根据第二信息中应用标识和用户信息生成用户标识,例如对用户信息和应用标识进行笛卡尔积运算后得到用户标识。这里,用户标识为用户在客户端140对应第三方应用生成的唯一且固定的ID账号,用户标识与用户信息、应用标识的笛卡尔积唯一对应,从用户标识中无法获知用户信息、应用标识,保证了用户账户安全。而后,第二服务器120中反馈单元123将用户标识发送至第一服务器110。
第一服务器110中接收单元111接收来自第二服务器120的验证消息和用户标识,若验证通过,则控制单元112查询获取第二信息中第一信息关联的事件标识,将该事件标识与用户标识进行关联,例如,以事件标识为key,用户标识为value,建立二者一一对应的映射表。同时控制单元112还可以删除该事件标识与第一信息的关联关系,以节省存储空间。
控制单元112与响应单元113相连,此时响应单元113响应上述来自第三方应用的第二请求,根据第二请求中事件标识查询该事件响应结果,即获取第二请求中事件标识关联的用户标识,将该用户标识发送至第三方应用。而后控制单元112可以删除事件标识、用户标识及其关联关系。
根据本发明的另一个实施方式,控制单元112还适于根据用户标识、事件标识生成第三签名,第三签名生成原理同第一签名、第二签名,即md5('uid='.$uid.$eventid),其中uid为用户标识,eventid为事件标识,而后响应单元113将用户标识和第三签名一齐返回至第三方应用。
第三方应用接收来自第一服务器110的用户标识和第三签名,验证第三签名,避免传输过程被恶意修改。具体地,第三方应用根据用户标识和事件标识生成第三验证签名,将该第三验证签名与第三签名比对,若一致则验证通过,否则验证失败。
验证通过后,第三方应用登录该用户标识对应的第三方账户。例如,第三方应用查询该用户标识预先绑定的第三方账户名和密码,自动登入该账户,若该用户标识绑定了多个第三方账户名和密码,可由用户选择自动登入的账户,无需用户输入第三方账户名和密码,极大地提高了用户体验和登录效率从而实现快速、安全的账号认证登陆,解决了过去的繁琐登录问题,并且整个登录过程不会收集用户在第三方应用的任何信息,解决了帐号安全、撞库风险等问题。
若第三方应用查询不到该用户标识绑定的第三方账户,则可提示用户输入账户进行绑定。
根据本发明的还有一个实施方式,第一服务器110的响应单元113在响应第二请求后,还可以返回对第二信息的处理消息至客户端140,客户端140中交互单元142接收来自第一服务器110的处理消息后,显示单元143显示该处理消息相应的内容,例如绑定成功或登录成功。
以上数据传输过程中,二维码作为用户信息的载体,并不参与验证过程,验证过程由客户端140的加密数据进行,操作简便的同时保证了安全性。其中,客户端140与第一服务器110之间的传输采用RSA加密,而第一服务器110与第二服务器120、第一服务器110与第三方应用之间的传输可以不加密,本发明对是否加密或加密方式不做限制。
图5示出了根据本发明一个实施例的二维码登录方法500的流程图。
如图5所示,二维码登录方法500适于步骤S510,在步骤S510中,接收在来自第一服务器的第一请求,该第一请求包括应用标识,由第三方应用生成,请求获取二维码。第一请求通常为http请求,应用标识可唯一地标识第三方应用身份,由第二服务器120为第三方应用生成。
接下来在步骤S520中,根据应用标识生成第一信息,将第一信息发送至第一服务器110,以便第一服务器110将第一信息发送至第三服务器130,由第三服务器130生成包含第一信息的二维码后,返回二维码地址给第一服务器110,并由第一服务器110将二维码地址以及与第一请求关联的事件标识发送给第三方应用。其中第一信息还可以包括应用标识、指定域名、时间戳以及随机数,事件标识可唯一地标识第一请求,由第一服务器110为第一请求生成。
可选地,根据应用标识生成第一信息的步骤之前包括:验证第一请求,验证通过则根据应用标识生成第一信息。具体地,第一请求还包括第一签名,验证第一请求的步骤包括:根据应用标识获取该应用标识关联的应用密钥,根据应用密钥和应用标识生成第一验证签名;将该第一验证签名与第一签名比对,若一致则验证通过,否则验证失败;将验证消息返回至第一服务器110。
第三方应用接收二维码地址并显示,客户端140扫描该二维码后生成第二信息发送至第一服务器110,第一服务器110将第二信息转发至第二服务器120,而后在步骤S530中,接收来自第一服务器110的第二信息,该第二信息由客户端扫描在第三方应用上显示的二维码后生成,包括第一信息。
在步骤S540中,根据第二信息生成用户标识。可选地,根据第二信息生成用户标识的步骤之前包括:验证第二信息,验证通过则根据第二信息生成用户标识。具体地,第二信息还包括用户信息,验证第二信息的步骤包括:验证第二信息中用户信息是否存在;验证第二信息中第一信息是否包括指定域名;若用户信息存在、第一信息包括指定域名,则验证通过,否则验证失败;将验证消息返回至第一服务器110。
可选地,第二信息还包括客户端信息,接收第二信息的步骤还包括:接收客户端信息,将客户端信息与用户信息关联后存储。
可选地,根据第二信息生成用户标识的步骤包括:根据应用标识和所述用户信息生成用户标识。例如将应用标识和所述用户信息经过笛卡尔积运算变换成用户标识。用户标识为用户在客户端140上对应第三方应用的唯一固定账号。
同样地,在步骤S540中,根据第二信息生成用户标识后,将用户标识发送至第一服务器110,以便第一服务器110响应于第三方应用发送的携带事件标识的第二请求,发送用户标识至第三方应用登录该用户标识对应的第三方账户。
根据本发明的还有一个实施方式,二维码登录方法500还可以包括步骤:接收来自第一服务器110的第二请求,该第二请求包括应用标识和第二签名;根据第二签名验证第二请求,将验证消息发送至第一服务器110。可选地,第二请求还可以包括事件标识,验证第二请求的步骤包括:根据应用标识获取该应用标识关联的应用密钥,根据应用密钥、应用标识和事件标识生成第二验证签名;将该第二验证签名与第二签名比对,若一致则验证通过,否则验证失败。
以上在结合图1、图2、图3和图4说明二维码登录系统100的具体描述中已经对各步骤中的相应处理进行了详细解释,这里不再对重复内容进行赘述。
在此处所提供的说明书中,说明了大量具体细节。然而,能够理解,本发明的实施例可以在没有这些具体细节的情况下被实践。在一些实例中,并未详细示出公知的方法、结构和技术,以便不模糊对本说明书的理解。
类似地,应当理解,为了精简本公开并帮助理解各个发明方面中的一个或多个,在上面对本发明的示例性实施例的描述中,本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而,并不应将该公开的方法解释成反映如下意图:即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多特征。更确切地说,如下面的权利要求书所反映的那样,发明方面在于少于前面公开的单个实施例的所有特征。因此,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员应当理解在本文所公开的示例中的设备的模块或单元或组件可以布置在如该实施例中所描述的设备中,或者可替换地可以定位在与该示例中的设备不同的一个或多个设备中。前述示例中的模块可以组合为一个模块或者此外可以分成多个子模块。
本领域那些技术人员可以理解,可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件,以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外,可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述,本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外,本领域的技术人员能够理解,尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征,但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如,在下面的权利要求书中,所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
此外,所述实施例中的一些在此被描述成可以由计算机系统的处理器或者由执行所述功能的其它装置实施的方法或方法元素的组合。因此,具有用于实施所述方法或方法元素的必要指令的处理器形成用于实施该方法或方法元素的装置。此外,装置实施例的在此所述的元素是如下装置的例子:该装置用于实施由为了实施该发明的目的的元素所执行的功能。
如在此所使用的那样,除非另行规定,使用序数词“第一”、“第二”、“第三”等等来描述普通对象仅仅表示涉及类似对象的不同实例,并且并不意图暗示这样被描述的对象必须具有时间上、空间上、排序方面或者以任意其它方式的给定顺序。
尽管根据有限数量的实施例描述了本发明,但是受益于上面的描述,本技术领域内的技术人员明白,在由此描述的本发明的范围内,可以设想其它实施例。此外,应当注意,本说明书中使用的语言主要是为了可读性和教导的目的而选择的,而不是为了解释或者限定本发明的主题而选择的。因此,在不偏离所附权利要求书的范围和精神的情况下,对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。对于本发明的范围,对本发明所做的公开是说明性的,而非限制性的,本发明的范围由所附权利要求书限定。