权限转移系统及其控制方法和客户端与流程

本发明涉及验证对web服务的访问权限的权限转移系统及其控制方法和客户端。
背景技术：
：个体web服务器提供用于提供web服务的开放应用程序编程接口(api)，并且web服务可以通过开放api彼此协作。在这种情况下，从安全性的观点来看，可能需要如下措施：在不需要移交由一个web服务管理的用户的认证信息的情况下，授权另一web服务来访问该一个web服务。为了实现这种措施，已采用标准协议(oauth2.0)来实现web服务之间的协作。oauth2.0是用于在用户批准的情况下在web服务之间安全地移交(或转移)用户的认证信息的机制，其细节将在下面描述。根据oauth2.0，当用户进行授权操作时，web服务b接收授权码。授权码是用于证明用户授权对web服务a的访问的代码。通过使用所接收到的授权码和证明web服务b的信息，web服务b向web服务a发送用以发出授权令牌的请求。授权令牌是用于授权web服务b访问web服务a所提供的开放api的令牌。web服务b接收到授权令牌，因此web服务b被授权访问web服务a的api。用于证明web服务b的信息可以是唯一标识web服务b的id、作为机密信息的密钥、或利用数字证书的数字签名。这里，术语“权限转移”是指通过用户进行的授权操作来授权web服务b对web服务a的api的访问。在oauth2.0中，被配置为响应于用户进行的授权操作而发出授权码并根据授权码发出授权令牌的服务器被称为授权服务器。被配置为提供开放api的服务器被称为资源服务器，并且访问开放api的实体被称为客户端。在上面的示例中，提供web服务a的服务器对应于授权服务器和资源服务器，并且提供web服务b的服务器对应于客户端。参考图1，将描述作为根据oauth2.0的处理流程的授权码授予(authorizationcodegrant)。首先，作为用于实现oauth2.0的在先操作，将登记请求发送到授权服务器，以使得将客户端登记为oauth2.0客户端(s0.0)。更具体地，在客户端启动时或者在后述的s1.1的授权流程开始时未登记客户端的情况下，向授权服务器的登记端点(图1中的“ep”)发送客户端登记请求。例如，可以通过客户端主动与授权服务器通信或者通过用户经由web浏览器访问授权服务器并登记客户端来进行登记请求的发送。s0.0中的登记请求包括显示在下面描述的授权确认画面上的客户端名称、描述、图标图像和作为必需参数的重定向统一资源标识符(uri)。重定向uri是用于指定授权服务器将授权码响应发送至的响应目的地的响应目的地信息(地址)，以使得客户端从授权服务器接收到授权码响应。将在下面描述授权码响应。已经接收到客户端登记请求的授权服务器发出用于标识客户端的客户端id和作为用于认证客户端的机密信息的客户端密钥，并将客户端id和客户端密钥作为客户端登记响应返回给客户端(s0.1)。授权服务器将在s0.1中接收到的客户端id和客户端密钥以及在s0.0中接收到的信息和重定向uri彼此相关联地保持。客户端保持在s0.1中接收到的客户端id和客户端密钥。至此为止，已经描述了作为用于实现oauth2.0的在先操作的客户端登记流程。接着，将参考图1来描述用于在授权服务器中认证用户的流程。用户可以登录客户端(s1.0)。客户端生成并保持作为用于标识登录用户的信息的登录上下文。用于标识登录用户的信息(例如本地用户id等)可以从生成的登录上下文中获得。用户可以经由web浏览器来访问用于开始授权的uri(以下称为授权开始uri)，并且可以开始根据oauth2.0的授权流程(s1.1)。响应于访问用于开始授权流程的授权开始uri，客户端将授权码请求发送到授权服务器的授权端点(s1.2)。授权码请求包括客户端id、重定向uri和状态参数。状态参数是用于唯一地将授权码请求与授权码响应相关联的信息，并且可用于防止csrf(跨站请求伪造)攻击和令牌替换(以下称为“授权码替换”)攻击。为此，状态参数是不可预测且不重叠的值。对客户端在后述的授权码响应中接收到的状态参数与客户端在s1.2中的授权码请求中发送的状态参数之间的一致性进行验证。此外，为了标识已经执行了授权码请求的用户，通过客户端将客户端发出的状态参数与重定向uri和登录上下文相关联地进行管理。如果用户尚未登录授权服务器，则在s1.2中接收到授权码请求的授权服务器以用于在web浏览器上认证用户的登录画面进行响应(s1.3)。用户可以通过web浏览器输入用户id和密码，并向授权服务器执行认证请求(s1.4)。已经接收到认证请求的授权服务器验证在s1.4中接收到的用户id和密码的组合与预先登记的组合之间的一致性。如果在s1.4中接收到的用户id和密码的组合与预先登记的组合一致，则授权服务器发出授权令牌。发出的授权令牌响应于web浏览器的cookie。授权服务器以用户在web浏览器上批准客户端的授权的授权确认画面进行响应(s1.5)。如果在s1.2中接收到的客户端id和重定向uri的组合与在授权服务器中预先登记的客户端id和重定向uri的组合不一致，则授权服务器在web浏览器上以错误画面进行响应。这可以防止重定向(传送)到无效的uri。在登录用户已经通过使用相同的客户端id执行了授权操作的情况下，可以省略s1.5中的处理。在下文中，授权用户id和客户端id的组合将被称为批准信息。在s1.6中用户进行授权操作之后，授权服务器发出授权码并且将授权码和状态参数作为授权码响应发送给客户端(s1.7)。更具体地，授权码和状态参数作为查询参数被添加到重定向uri，然后将其发送到web浏览器，使得授权码和状态参数被重定向到通过重定向uri所指定的响应目的地。s1.7中发出的授权码与客户端id、用户id和重定向uri相关联地保存在授权服务器中。授权服务器还保存批准信息。已经接收到针对重定向uri的授权码响应的客户端验证授权码响应中包括的状态参数是否与客户端管理的状态参数一致。如果作为验证的结果、状态参数一致，则客户端将令牌请求发送到授权服务器的令牌端点(s2.0)。令牌请求包括客户端id、客户端密钥、在s1.7中获得的授权码以及在s1.2中接收到的重定向uri。已经在s2.0中接收到令牌请求的授权服务器验证客户端id和客户端密钥的组合是否与预先登记的组合一致。如果作为验证结果判断为它们一致，则客户端被授权。授权服务器验证其是否保持了在s2.0中接收到的授权码，并且如果是，则验证授权码是否未到期以及与授权令牌相关联的客户端id和重定向uri是否与在s2.0中的令牌请求中接收到的客户端id和重定向uri一致。通过该验证，授权服务器可以验证在s1.2中发送了授权码请求的客户端是否与在s2.0中发送了令牌请求的客户端一致。如果验证成功，则授权服务器向客户端发出授权令牌，并将其作为对客户端的令牌响应进行响应(s2.1)。这里，授权服务器可以向客户端发出用于再次获得授权令牌的刷新令牌，并以其作为令牌响应进行响应。客户端可以使用s2.1中接收到的授权令牌来访问资源服务器提供的开放api。在发出授权令牌之后，可以丢弃由授权服务器管理的授权码以防止重放攻击。如果刷新令牌包括在s2.1中的令牌响应中，则将登录上下文和刷新令牌在客户端中彼此相关联地进行管理。因此，可以在无需进行授权操作(s1.2至s1.7)的情况下再次获得授权令牌，以在下一次和随后的场合访问该api。更具体地，响应于s1.1中的授权的开始，客户端确认用户的登录上下文和刷新令牌是否彼此相关联。如果不是，则进行根据oauth2.0的流程(s1.2和后续步骤中的处理)。如果用户的登录上下文和刷新令牌彼此相关联，则向授权服务器的令牌端点发送刷新请求(s2.2)。刷新请求包括客户端id、客户端密钥和刷新令牌。已经接收到刷新请求的授权服务器验证客户端id和客户端密钥的组合是否与在s0.1中预先登记的组合一致。如果确认为一致并且客户端已授权，则授权服务器验证所接收到的刷新令牌是否保持在授权服务器中，并且如果是，则验证刷新令牌是否未过期以及与刷新令牌相关联的客户端id是否与刷新请求中的客户端id一致。如果这些验证全部都成功，则授权服务器发出授权令牌并将授权令牌作为令牌响应发送给客户端。这里，可以重新发出新的刷新令牌以再次获得授权令牌，并且新的刷新令牌可以与令牌响应同时发送到客户端。在授权服务器中发出新的刷新令牌之后，授权服务器丢弃已经管理的刷新令牌，以防止重放攻击。已经描述了根据oauth2.0的授权码授予的处理流程。根据oauth2.0的处理流程使得授权服务器能够发出授权令牌，并且客户端通过使用发出的授权令牌来访问资源服务器提供的开放api，而不是将授权服务器所管理的用户认证信息发送到客户端。日本特开2016-6624公开了一种通过使用根据oauth2.0的处理流程来与多个外部服务系统协作的信息处理系统。存在降低用于在权限转移系统中管理参数的成本的需求。例如，在基于图1所示的oauth2.0的处理流程中，设置用于在s1.2中将授权码请求发送到授权服务器的授权端点的状态参数。针对状态参数要设置的值应该是不可预测且不重叠的，并且可用于在客户端中将从客户端向授权服务器发送的授权码请求与客户端所接收到的授权码响应相关联。然而，每次执行授权码请求时都要发出状态参数的值，此外，在客户端中保持状态参数的值直到其被删除为止，这可能会对客户端上的管理成本产生负担。技术实现要素：本发明公开了以下结构。一种权限转移系统，包括：至少处理器和至少存储器，至少所述存储器与至少所述处理器连接并且存储有指令，在至少所述处理器执行所述指令时，至少所述存储器和至少所述处理器进行协作以用作：发送部件，用于在用户许可客户端对资源服务器进行访问的情况下，从所述客户端向授权服务器发送用于利用所述授权服务器发出授权码的授权码请求；接收部件，用于从所述授权服务器向所述客户端接收作为对所述授权码请求的响应的授权码响应；以及生成部件，用于在用户登录所述客户端的情况下生成登录上下文，其中，所述发送部件所发送的所述授权码请求包括签名信息和用于将所述授权码请求与所述授权码响应相关联的参数，所述参数具有被设置为所述参数的值的所述登录上下文，其中，在所述授权服务器中验证所述签名信息之后，向所述客户端发送与所述授权码请求相对应的所述授权码响应，以及其中，所述客户端使用所述接收部件所接收到的所述授权码响应中所包括的参数和所述发送部件所发送的所述授权码请求中所包括的参数，来验证所述授权码响应是否与所述授权码请求相对应。一种权限转移系统的控制方法，所述控制方法包括：发送步骤，用于在用户许可客户端对资源服务器进行访问的情况下，从所述客户端向授权服务器发送用于利用所述授权服务器发出授权码的授权码请求；接收步骤，用于从所述授权服务器向所述客户端接收作为对所述授权码请求的响应的授权码响应；以及生成步骤，用于在用户登录所述客户端的情况下生成登录上下文，其中，所述发送步骤所发送的所述授权码请求包括签名信息和用于将所述授权码请求与所述授权码响应相关联的参数，所述参数具有被设置为所述参数的值的所述登录上下文，其中，在所述授权服务器中验证所述签名信息之后，向所述客户端发送与所述授权码请求相对应的所述授权码响应，以及其中，所述客户端使用所述接收步骤所接收到的所述授权码响应中所包括的参数和所述发送步骤所发送的所述授权码请求中所包括的参数，来验证所述授权码响应是否与所述授权码请求相对应。一种客户端，包括：发送部件，用于在用户许可所述客户端对资源服务器进行访问的情况下，从所述客户端向授权服务器发送用于利用所述授权服务器发出授权码的授权码请求；以及接收部件，用于接收作为对所述授权码请求的响应的授权码响应，其中，所述发送部件所发送的所述授权码请求包括签名信息和用于将所述授权码请求与所述授权码响应相关联的参数，所述参数具有被设置为所述参数的值的登录上下文，其中，在所述授权服务器中验证所述签名信息之后，所述客户端从所述授权服务器接收与所述授权码请求相对应的所述授权码响应，以及其中，所述客户端使用所述接收部件所接收到的所述授权码响应中所包括的参数和所述发送部件所发送的授权码请求中所包括的参数，来验证所述授权码响应是否与所述授权码请求相对应。通过以下参考附图对典型实施例的说明，本发明的其它特征将变得明显。附图说明图1是基于oauth2.0的授权码授予的处理流程。图2是示出根据实施例1的权限转移系统的结构图。图3示出权限转移系统中包括的装置的硬件结构。图4a至4d示出权限转移系统中包括的装置的软件模块结构。图5a和5b示出用于要由web浏览器显示的客户端的用户认证画面和授权确认画面的示例。图6示出根据实施例1的基于oauth2.0的授权码授予的处理流程。图7示出根据实施例1的包括授权码请求的jwt的示例。图8示出根据实施例1的包括授权令牌的jwt的示例。图9示出根据实施例1的用于在客户端中确定重定向uri的处理流程。图10示出根据实施例2的基于oauth2.0的授权码授予的处理流程。图11示出根据实施例2的包括授权码请求的jwt的示例。图12示出用于判断授权服务器中的批准信息的流程。图13示出根据实施例4的基于oauth2.0的授权码授予的处理流程。具体实施方式本发明可以维持诸如用于将授权码请求与授权码响应相关联的状态参数等的参数的角色，并且同时可以降低在客户端中发出和管理参数的成本。参考附图，下面将描述用于实施本发明的最佳模式。首先，将参考图2来描述根据本发明的实施例的权限转移系统。广域网(wan)100由万维网(www)系统构成。wan100和装置200至500通过局域网(lan)101连接。授权服务器200是用于实现oauth2.0的服务器，并且被配置为进行诸如接收认证请求并发出和管理授权码等的处理。资源服务器300具有用于提供web服务的开放api。尽管授权服务器200和资源服务器300通过图2中的lan101连接，但是它们可以通过wan100连接。授权服务器200还可以通过lan101连接到未示出的数据库服务器，使得被授权服务器200用来实现其功能的数据可以存储在数据库服务器中。尽管授权服务器200和资源服务器300在图2中作为单独的服务器提供，但是服务器的功能可以在一个服务器中实现。客户端400对应于基于oauth2.0的客户端，并且例如可以是打印机、多功能打印机/外围设备(mfp)、个人计算机(pc)或智能电话。终端500对应于基于oauth2.0的用户代理。用户可以经由终端500使用装置的功能，诸如对授权服务器200的用户认证请求以及要在客户端400上进行的登录操作等。例如，终端500具体可以是pc或智能电话。客户端400和终端500分别包括web浏览器410和web浏览器510。用户可以运行web浏览器410或web浏览器510来执行后述的授权操作。客户端400和终端500通过lan101连接。在下文中，如果可以由web浏览器410和web浏览器510中的任何一个进行操作，则web浏览器410和web浏览器510将简称为“web浏览器”而无需附图标记。接着，参考图3，将描述授权服务器200、资源服务器300、客户端400和终端500的硬件结构。图3是示出一般信息处理设备的框图，根据本实施例的装置可以应用一般信息处理设备的硬件结构或作为基础结构即服务(iaas)提供的信息处理设备的虚拟硬件结构。将参考图3来描述客户端400作为示例，但是资源服务器300、授权服务器200和终端500具有相同的硬件结构。中央处理单元(cpu)2001被配置为从随机存取存储器(ram)2002、只读存储器(rom)2003或外部存储器2011等中读出程序并在客户端400上执行用于控制的程序的指令。下面将描述的序列可以通过这种程序的执行指令来实现。cpu2001还被配置为控制连接到系统总线2004的块。ram2002是cpu2001可用于执行指令的工作存储器。可以将诸如操作系统(os)或保存在rom2003或外部存储器2011中的应用程序等的程序加载到ram2002，并且cpu2001可以顺次读出并执行程序的指令。rom2003是被配置为存储嵌入程序以及包括应用程序和os的数据的存储装置。rom2003可以是闪速存储器或可擦除rom。ram2002或rom2003可以是连接到cpu2001并且在其上存储指令的存储器，其中当该指令由cpu2001执行时，协作以用作各种单元或者进行后述的操作。键盘控制器(kbc)2005被配置为控制来自键盘(kb)2009和未示出的指点装置的输入。阴极射线管控制器(crtc)2006被配置为控制由crt显示器2010呈现的显示。盘控制器(dkc)2007被配置为控制对外部存储器2011的数据访问。网络控制器(nc)2008被配置为执行用于控制与通过wan100或lan101连接到装置的其它装置的通信的处理。如果装置是作为iaas提供的虚拟信息处理设备，则该装置可以不具有kbc2005和crtc2006，但是可以通过在经由nc2008连接到装置的终端中包括的键盘或crt显示器来操作。在以下描述中，除非另有说明，否则装置的功能可主要由cpu2001以硬件或主要由安装在ram2002、rom2003或外部存储器2011等中的程序以软件来执行。接着，参考图4a至4d，将描述授权服务器200、资源服务器300、客户端400和终端500的功能。授权服务器200具有授权服务器单元210和http服务器单元220。http服务器单元220通过wan100连接到客户端400和终端500，并且是被配置为与将在下面描述的web浏览器或客户端应用程序420进行http通信的功能。http服务器单元220可以基于ssl/tls来进行通信，并且具有未示出的证书存储器。授权服务器单元210是被配置为经由http服务器单元220从web浏览器510接收请求并且以对所接收的请求的结果进行响应的功能。更具体地，http服务器单元220被配置为从web浏览器510接收用户认证请求，生成与关于已经成功认证的用户的用户信息相关联的授权令牌，并且将授权令牌通知给web浏览器510。这里的授权令牌可以是表示用户正在登录授权服务器200的令牌或用于验证用户是否已经由授权服务器200认证的令牌。使用授权令牌使得授权服务器200能够识别用户。另一方面，授权码是表示许可客户端400代表用户来访问资源服务器300的api的令牌，其中通过由认证用户进行的授权操作将权限转移至该客户端400。授权服务器单元210还可以被配置为保持用于对授权令牌添加签名信息的私钥。在这种情况下，私钥可以用于对授权令牌添加签名信息，并且可以向客户端400发出具有签名信息的授权令牌。资源服务器300具有资源服务器单元310。资源服务器单元310是被配置为提供用于提供web服务的开放api的功能。资源服务器单元310可以具有http服务器单元，并且可以被配置为经由http服务器单元(如授权服务器200)进行相对于外部装置的发送和接收。客户端400具有web浏览器410、客户端应用程序420和认证单元430。web浏览器410是通过用户代理实现的用于使用www的功能，其中web浏览器410与包括在终端500中的web浏览器510的功能相同。web浏览器410被配置为响应于用户操作与授权服务器200和客户端应用程序420通信。客户端应用程序420被配置为执行由资源服务器300提供的开放api，以向用户提供与客户端应用程序420提供的功能相结合的web服务。根据本实施例，客户端应用程序420对应于基于oauth2.0的客户端。认证单元430是用于认证用户的功能。用户可以通过客户端400呈现的输入画面(未示出)输入本地用户id和本地用户密码，以使用客户端400的功能。响应于输入的客户端400通过在认证单元430中预先登记的信息(本地用户id和本地用户密码)与输入信息之间进行比较来对用户进行认证处理，并生成登录上下文。可以以诸如利用ic卡的认证或基于指纹的生物认证等的任何其它形式来进行认证处理。登录上下文是用于标识客户端400中的本地用户的信息，并且例如可以包括本地用户id。登录上下文由客户端应用程序420和认证单元430共享。根据本实施例，已经描述了用户通过直接操作客户端400来执行用于登录客户端400的处理，然而用户可以经由web浏览器510来远程登录客户端400。在这种情况下，认证单元430以未示出的登录画面对web浏览器510进行响应。基于用户通过登录画面输入的本地用户id和本地用户密码来对用户进行认证。在这种情况下，在认证单元430中生成登录上下文，并且由客户端应用程序420和认证单元430共享登录该上下文。实施例1根据实施例1，可以在不损害执行处理的安全性的情况下解决由于客户端的uri的改变而导致的基于oauth2.0的处理的复杂性。相同的标号指代与图1和本实施例中描述的处理流程相同的处理流程，并且将省略其重复的细节描述。首先，参考图5a和5b，描述用于由授权服务器200认证用户的登录画面和用于向用户询问关于客户端400的授权的批准的授权确认画面。图5a示出在web浏览器上显示并且可以被用户用来登录授权服务器200的登录画面的示例。在用户经由web浏览器向授权服务器200的授权端点发送授权码请求并且用户尚未登录授权服务器200的情况下，登录画面将显示在web浏览器上。登录画面5000包括用户id输入栏5001、密码输入栏5002和可用于执行登录操作的登录按钮5003。下面将描述在按下登录按钮5003之后要执行的处理。图5b示出授权服务器200向web浏览器响应作为用户认证的结果的授权确认画面的示例。授权确认画面5100具有用于向用户询问批准的内容，包括要授权的客户端400的客户端名称5101、与客户端400有关的描述5102以及图标图像5103。授权确认画面5100还包括分别可以被用户用来许可和拒绝客户端400的授权的许可按钮5104和拒绝按钮5105。下面将描述当按下许可按钮5104时以及当按下拒绝按钮5105时要执行的处理。接着，将参考图6来描述具有本发明的特征的基于oauth2.0的授权码授予的处理流程。相同的标号指代图1和图6中的相同部分，并且将省略任何重复的细节描述。图1中的s0.0、s0.1、s1.2、s2.0和s2.2中的处理可以由后述的s3.0、s3.1、s4.0、s5.0和s5.1中的处理替换，以执行根据本实施例的基于oauth2.0的处理流程。首先，将参考图6来描述作为用于执行oauth2.0的在先操作而要进行的用于登记客户端400的流程。根据本实施例，例如，客户端400主动与授权服务器200通信以执行对客户端400的登记请求。然而，用户可以经由web浏览器访问授权服务器200以执行客户端400的登记请求。用于登记客户端400的流程在客户端400启动时开始，或者在s1.1中的授权流程开始时尚未登记客户端400的情况下开始。客户端400将客户端400的登记请求发送到授权服务器200(s3.0)。已经接收到登记请求的授权服务器200生成用于标识客户端400的客户端id以及用于认证客户端400的加密密钥和解密密钥(或公钥和私钥)的密钥对。根据本实施例，下面将示例性地描述私钥和加密密钥。授权服务器200将生成的客户端id和私钥作为登记响应返回给客户端400(s3.1)。客户端id和私钥彼此相关联地保存在客户端400中，同时客户端id和公钥彼此关联地保存在授权服务器200中。将通过假设客户端id为“client_01”来描述本实施例。表1中示出客户端400中保持的关联信息的示例，以及表2中示出授权服务器200中保持的关联信息的示例。表1客户端id私钥client_01私钥a表2客户端id公钥client_01公钥a要作为登记响应发送到客户端400的信息不限于如上所述的形式。例如，可以嵌入客户端id作为私钥的主体信息，并且可以仅将私钥作为登记响应发送到客户端400。可选地，授权服务器200可以预先生成私钥，并且私钥可以在客户端400制造时预先安装在客户端400中，而无需针对客户端400执行登记流程(s3.0至s3.1)。至此为止，已经描述了客户端400的登记流程。在现有技术中，在客户端400的在先登记期间将重定向uri和与客户端400有关的信息发送到授权服务器200(s0.0)，并且在授权服务器200中管理所发送的信息。相反，根据本发明的在先登记(s3.0)不发送该信息，并且不对授权服务器200中所发送的信息进行管理。接着，参考图6，将描述从用户登录客户端400的步骤起、直到客户端400向授权服务器200发送授权码请求的步骤为止的处理流程。用户登录客户端400(s1.0)。假设这里的本地用户id是“local_user_01”。客户端400生成并保持可以标识本地用户id的登录上下文。可以被配置为使得登录上下文可以响应于用户进行的登出操作或者在针对上下文预设的到期日期之后变为无效。接着，用户经由web浏览器访问用于开始客户端400的授权的uri(s1.1)。在这里的用户代理是web浏览器410的情况下，用户可以启动web浏览器410或者可以使用用于web浏览器410的书签来访问uri。可选地，可以运行客户端应用程序420的用户界面(未示出)以启动web浏览器410，从而开始授权处理。在用户代理是web浏览器510的情况下，web浏览器410可以接收由web浏览器510进行的远程访问，并且可以输入用于在web浏览器510中进行访问的授权开始的uri，或者与其相对应的书签可用于进行访问。可选地，客户端应用程序420针对通过web浏览器510的远程访问利用画面(未示出)来进行响应，并且用户可以按下针对画面中嵌入的授权开始的uri的链接来进行访问。如果客户端400在s1.1中接收到对授权开始uri的访问，则客户端400将授权码请求发送到授权服务器200的授权端点(s4.0)。更具体地，将对授权服务器200的授权端点的重定向指示发送到web浏览器。在s4.0中发送的授权码请求包括用于指定授权码作为授权码响应的响应类型的信息以及用于唯一地将授权码请求与授权码响应相关联的状态参数。在s4.0中发送的授权码请求还包括jsonweb令牌(jwt)。更具体地，在oauth2.0jwt配置文件中声明client_assertion_type：jwt-bearer，并且jwt被设置为client_assertion的参数。图7示出当jwt被设置为参数时授权码请求的示例。jwt包括头部分(从“header”开始)、有效载荷部分(从“payload”开始)和数字签名部分(从“encoded”开始)，所有这些都根据由base64表示的编码方法来进行编码。在有效载荷部分中，在“iss”(表示发出者)和“sub”(表示主体)下，设置客户端id“client_01”。在“aud”(表示用户)下，设置授权服务器200的授权端点的uri，并且在“exp”(表示到期日期)和“iat”(表示发出日期和时间)下，设置信息。在“client_name”下设置客户端名称，并且在“description”下设置客户端400的描述。参考图7，“装置xx”被设置为客户端400的客户端名称，并且“位于yy中的\r\n装置xx”被设置为客户端400的描述。在“redirect_uri”下设置重定向uri，并且例如这里设置“https://192.168.1.1/redirect”。根据需要，在“icon_image”下设置与图标图像有关的信息以及图标图像的图像格式。如果图标图像存在，则与图标图像有关的信息可以被设置为uri，或者如果图像保持在授权服务器200中，则与图标图像有关的信息可以是用于标识图像的信息。在设置这些信息之后，根据base64对头部分和有效载荷部分中的字符串进行编码，并且通过使用保持在客户端400中的私钥针对字符串提供数字签名。已经在s4.0中获得jwt的授权服务器200基于客户端id来识别公钥，并且通过使用公钥来验证包括在jwt中的数字签名以认证客户端400并验证jwt中的字符串没有被更改。结果，验证了在s4.0中授权码请求的jwt中包括的重定向uri由客户端400设置并且没有被更改。至此为止，已经描述了从用户登录客户端400的步骤起、直到客户端400将授权码请求发送到授权服务器200的步骤为止的流程。基于jwt，可以信任授权码请求中包括的重定向uri。因此，授权服务器200可以不将其与重定向uri进行比较，并且可以不预先向授权服务器200登记重定向uri。结果，即使在客户端400的uri被改变并且因此改变了重定向uri的情况下，也可以使用客户端400的改变后的uri来将授权码请求发送到授权服务器200。可以基于存储在客户端400中的与本地用户使用的语言有关的语言信息、或者在web浏览器上的accept-language头中设置的语言信息(包括在来自web浏览器的请求中的语言信息)，来确定用于编写要在授权确认画面上显示的与客户端400有关的信息(诸如客户端名称、描述和图标图像等)的语言。这意味着可以基于语言信息来编写s4.0中的授权码请求中包括的与客户端400有关的信息。因此，授权服务器200可以接收与客户端400有关的信息，以将适用于登录客户端400的本地用户的授权确认画面呈现给用户。接着，参考图6，将描述从经由web浏览器向用户呈现登录画面起、直到向客户端400发出授权码为止的处理。如果用户尚未登录授权服务器200，则已经接收到授权码请求的授权服务器200向授权端点呈现登录画面(s1.3)。图5a示出登录画面的示例。用户可以在登录画面5000上输入用户id和密码，并按下登录按钮5003以向授权服务器200发送认证请求(s1.4)。已经接收到认证请求的授权服务器200将用户id和密码的组合与预先在授权服务器200中登记的信息进行比较，并且如果它们一致，则发出授权令牌。将发出的授权令牌作为响应返回到web浏览器的cookie。这里，授权令牌可以是随机且不可预测的字符串，或者可以是包括登录用户的标识信息以及登录日期和时间的加密字符串。在前一种情况下，授权令牌与登录用户的标识信息(或本实施例中的用户id)相组合地保持在授权服务器200中。这里将本实施例中的用户id假定为“user_01”。授权服务器200利用授权确认画面来响应于web浏览器(s1.5)。图5b示出授权确认画面的示例。然而，在利用公钥来验证在s4.0中的授权码请求中接收到的jwt中的数字签名并且判断为无效的情况下，返回错误画面(未示出)，并且处理结束。数字签名验证的处理可以防止重定向到无效的uri。下面将描述jwt中的数字签名有效的情况。基于在s4.0中的授权码请求中接收到的jwt中包括的值(客户端名称5101、描述5102和图标图像5103)，在web浏览器上显示授权确认画面5100。这里，如果用户按下拒绝按钮5105并且如果客户端id和重定向uri的组合与预先登记的对应组合一致，则授权服务器200将表示用户拒绝客户端400的授权的信息添加到重定向uri中的查询参数。然后，授权服务器200利用用以将信息重定向到在重定向uri中指定的响应目的地的指示来向web浏览器进行响应。如上所述，使用这样的jwt使得能够拒绝无效的授权码请求，并且可以向web浏览器提供表示授权码请求已被拒绝的显示画面。即使s4.0中的请求未被拒绝，用户也可以通过授权确认画面来拒绝授权，并将表示授权已被拒绝的信息发送到web浏览器。另一方面，如果用户按下许可按钮5104，则执行授权操作(s1.6)，并且授权服务器200发出授权码。将在s1.6中发出的授权码和在s4.0中的授权码请求中接收到的状态参数作为查询参数添加到重定向uri，并且将用以将授权码和状态参数重定向到在重定向uri中所指定的响应目的地的指示返回到web浏览器(s1.7)。将所发出的授权码与客户端id、用户id和重定向uri相关联地保存在授权服务器200中。保存在授权服务器200中的授权码可以用于响应于后述的令牌请求而进行的对客户端400的验证。这里，例如，将授权码与客户端id“client_01”、用户id“user_01”和重定向uri“https://192.168.1.1/redirect”相关联地保存。授权码是不可预测的随机字符串，并且可以具有到期日期。授权服务器200确定为授权被用户批准，并将批准信息(用户id和客户端id)登记为与登录用户有关的信息。已经在s1.7中接收到授权码响应的客户端400将令牌请求发送到授权服务器200的令牌端点(s5.0)。令牌请求包括jwt(jsonweb令牌)，jwt包括表示授权流程基于授权码授予的定义“grant_type＝authorization_code”以及获得的授权码和客户端认证信息。更具体地，jwt在这里被设置为在oauth2.0jwt配置文件中声明的client_assertion_type：jwt-bearer中的client_assert中的参数。图8示出由jwt表示的令牌请求的示例。将省略与图7中的授权码请求重叠的部分的任何重复细节描述。已经在s5.0中接收到令牌请求的授权服务器200通过使用从客户端id识别的公钥来验证jwt中的签名。如果验证成功并且客户端400被认证，则授权服务器200发出授权令牌并将令牌响应发送到客户端400(s2.1)。客户端400将刷新请求发送到授权服务器200的令牌端点(s5.1)。在s2.2中，刷新请求中的客户端400的认证方法基于客户端id和密钥的组合来进行比较以认证客户端400。另一方面，在s5.1中，通过使用私钥来验证添加到客户端id的数字签名以验证客户端400。该处理在web浏览器上呈现登录画面，然后向客户端400发出授权码。接着，将参考图9来描述用于确定要在授权码请求中设置的重定向uri的处理。图9中的处理是用于确定客户端400中的重定向uri的处理流程。当客户端400接收到授权流程的开始请求时(s1.1)，开始该处理(s9.1)。客户端400在授权流程的发起请求中获得主机头(hostheader)(s9.2)。客户端400判断所获得的主机头的域部分是否是“localhost”(s9.3)。域部分“localhost”与表示要执行程序的装置的主机名相对应，并且在这种情况下，域部分“localhost”表示授权流程的发起请求被发送至的web浏览器。根据s9.3中的判断结果，可以识别出授权流程的发起请求被发送至的web浏览器。这里假设web浏览器410将授权流程的发起请求发送到客户端400。如果主机头是“localhost”，则确定为重定向uri的域部分是“localhost”(s9.8)。例如，重定向uri可以是“https：//localhost/redirect”。如果在s9.3中主机头的域部分不是“localhost”，则客户端400判断主机头的域部分是否是ip地址(s9.4)。如果不是，则使用在s9.2中获得的主机头来向未示出的dns服务器进行查询，以获得ip地址(s9.5)。例如，在主机头是“www.canon.jp:443”的情况下，端口号“443”被添加到作为域的“www.canon.jp”(全限定域名：fqdn)。在这种情况下，提取作为主机头的一部分的域部分，并且对具有域部分的dns服务器进行查询。在获得ip地址之后，执行后述的s9.6中的处理。如果在s9.4中主机头的域部分是ip地址，则在客户端400中将客户端400中预设的ip地址和获得的ip地址进行比较(s9.6)。在客户端400中判断ip地址是否一致(s9.7)。如果ip地址不一致，则判断为在s9.1中接收到的访问无效，并且处理以错误终止(s9.9)。如果ip地址一致，则判断为在s9.1中接收到的访问有效，并且生成具有在s9.2中获得的主机头的域部分的uri。生成的uri被确定为重定向uri(s9.8)。至此为止，已经描述了用于确定客户端400中的重定向uri的方法。根据该方法，即使当ip地址或主机名改变时，也可以响应于基于oauth2.0的处理流程中的授权流程的发起请求来确定重定向uri。本实施例可以在基于oauth2.0的授权码授予的处理流程中不会损害安全性的情况下，消除重定向uri和与在授权确认画面上要呈现的客户端有关的信息的在先登记和管理的必要性，并且可以容易地解决动态变化。实施例2在参考图1和6描述的基于oauth2.0的处理流程中，设置状态参数，以在s1.2(或图6中的s4.0)中将授权码请求发送到授权服务器的授权端点。状态参数具有用于唯一地将授权码请求与授权码响应相关联的不可预测且不重叠的值。然而，每当执行授权码请求时都要发出状态参数的值，并且状态参数的值要保持在客户端400中，直到状态参数的值被删除为止，从而会对客户端400的管理成本产生负担。将描述根据实施例2的用于降低在客户端400中发出和管理状态参数的值的成本的处理。尽管将参考与传统技术(图1)的组合来描述实施例2，但是实施例2可以与实施例1(图6)组合。参考图10，将描述根据实施例2的基于oauth2.0的授权码授予的处理流程。相同的标号指代图1和图10中的相同部分，并且将省略任何重复的细节描述。根据实施例2的客户端400的在先登记以基于传统技术的模式(s0.0至s0.1)进行，但是可以以根据实施例1的模式(s3.0至s3.1)进行，因此将省略对其的任何重复描述。由于从用户登录客户端400的时间(s1.0)起、直到授权发起请求被发送到客户端400的时间(s1.1)为止的处理以与传统技术或者实施例1相同的方式进行，因此将省略任何重复的描述。当在s1.1中客户端400接收到对用于授权开始的uri的访问时，客户端400将授权码请求发送到授权服务器200的授权端点(s7.0)。更具体地，经由web浏览器进行到授权端点的重定向。s7.0中的授权码请求包括用于指定授权码作为响应类型的信息、用于唯一标识客户端400的客户端id、作为用于唯一地将授权码请求与授权码响应相关联的信息的状态参数、以及重定向uri。然而，登录上下文被设置为状态参数的值。登录上下文是保持与登录客户端400的用户有关的信息的数据对象，并且包括用于标识本地用户的本地用户信息，诸如本地用户id或本地用户的电子邮件地址等。jwt包括要在授权码请求中发送的客户端id以及被设置为状态参数的登录上下文。下面将参考图11来描述jwt中的参数设置。已经在s7.0中接收到授权码请求的授权服务器200通过进行s1.3至s1.6中的处理，来针对登录授权服务器200的用户请求客户端400的授权。用户可以授权客户端400执行授权操作。如果在s1.6中执行了授权操作，则授权服务器200发出授权码。将发出的授权码与客户端id、用户id和重定向uri相关联地保存。在这种情况下，将授权码与客户端id“client_01”、用户id“user_01”和重定向uri“https://192.168.1.1/redirect”相关联地保存。将用以将授权码和s7.0中被设置为状态参数的值的登录上下文重定向到重定向uri的指示作为响应发送到web浏览器(s7.1)。这里，授权服务器200通过使用公钥来对授权码和状态参数添加数字签名。已经在重定向uri处接收到授权码响应的客户端400通过使用保持在客户端400中的私钥来验证数字签名值，并验证在s7.1中接收到的授权码响应的内容是否未被更改。更具体地，客户端400可以验证在客户端400中保存的登录上下文和在s7.1中接收到的登录上下文一致并确定为授权码请求和授权码响应彼此相关联。由于在验证了s7.1中接收到的授权码响应的内容未被更改之后用于从授权服务器200向客户端400发出授权令牌的处理(s2.0至s2.2)可以以根据实施例1的模式(s5.0至s5.1、s2.1)进行，因此将省略任何重复描述。到此为止，已经描述了根据实施例2的基于oauth2.0的授权码授予的处理流程。接着，参考图11，将描述在s7.0中在从客户端400向授权服务器200的授权码请求中发送的jwt的示例。将省略jwt中包括的与图8中相同的字符串的任何重复细节描述。在有效载荷部分中，设置状态以及iss(发出者)和sub(主体)。在这种情况下，在aud(用户)下设置授权服务器200的授权端点的“https://xxx.com/authrization”。此外，在state下，设置“user：//local_user_01，mail：local_user_01@abc.com”作为登录上下文。根据base64来对头部分和有效载荷部分中的字符串进行编码，并且针对这些字符串，通过使用保持在客户端400中的私钥来提供数字签名。至此为止，已经描述了要在s7.0中的授权码请求中从客户端400向授权服务器200发送的jwt的示例。尽管图11示出以json(javascript(注册商标)对象表示法)格式的文本数据编写的登录上下文，但是登录上下文不限于具有该格式。当客户端400在s7.1中接收到授权码响应时，客户端400使用登录上下文来标识本地用户，并且登录上下文可以例如是通过对登录上下文执行可逆或不可逆加密而获得的任何值。根据实施例2，由客户端400保持的现有登录上下文被设置为状态参数的值，使得可以在客户端400中消除针对状态参数设置新值的必要性，从而可以降低客户端400中的生成和管理的成本。登录上下文是可以唯一标识本地用户而不与其它用户重叠的信息。当本地用户登录客户端400时，登录上下文可以由客户端400中的os(未示出)生成，并且在本地用户登出时变为无效。响应于由本地用户进行的登录操作而生成登录上下文使得网页在web浏览器上开放，其中登录本地用户具有对该网页的访问权限。登录上下文响应于本地用户进行的登出操作而变为无效，使得可以防止本地用户具有访问权限的网页向其它用户开放，并且可以确保安全性。另一方面，状态参数具有用于唯一地将授权码请求与授权码响应相关联的不可预测且不重叠的值。换句话说，根据本实施例，状态参数的值被登录上下文替换，使得可以维持状态参数的特性(不与其它信息重叠的信息)，并且可以降低用于在客户端400中生成和管理状态参数的值的成本。在授权码请求和授权码响应中使用jwt使得能够在不会损害基于oauth2.0的处理的执行中的安全性的情况下，在授权服务器200和客户端400之间安全地交换包括用户信息的状态参数。实施例3在一些情况下，一个用户id可以与多个本地用户id相关联，而不是将唯一地与客户端400的本地用户id相关联的用户id保存在授权服务器200中。更具体地，在一些情况下，在客户端400中，可以针对各个用户登记本地用户id，而在授权服务器200中，可以针对多个本地用户id使用共同用户id，而不是针对各个用户发出用户id。例如，由于生成多个账户(用户id)的复杂性，因此可以针对一个部门内的业务生成共同账户，并且该共同账户可以由该部门的多个成员共享。结果，批准信息(包括客户端id和用户id)由客户端400的多个用户共享。然后，出现如下问题：尽管一个用户正在执行授权操作，但是共享批准信息中包括的用户id的另一用户执行了授权操作。为了防止用户id被共享，可以将用户id单独存储在授权服务器200中，然而这需要针对各个用户发出用户id并且需要用于生成和管理用户id的成本。根据实施例3，在授权服务器200中不生成和管理新用户id的情况下，用户id没有被多个用户共享。首先，将描述要在授权服务器200中管理的批准信息。表3是存储在授权服务器200中的批准信息的示例。表3在表3中，“client_id”表示客户端id，“user_id”表示向授权服务器200登记的用户的用户id，“login_context”表示由授权服务器200响应于s7.0中的授权码请求而发送的登录上下文。登录上下文包括与登录客户端400的本地用户有关的本地用户信息。在“login_context”下不存在设置值意味着没有登录上下文被视为批准信息，并且在“login_context”下存在设置值意味着登录上下文被视为批准信息。标志“consent”(同意)表示用户在s1.5中的授权确认画面上是否批准授权。具有“1”的标志“consent”表示客户端400的授权被批准，而具有“0”的标志“consent”表示授权被拒绝。表3中的批准信息表中没有记录表示用户尚未授权。作为批准信息表的替代形式，可以不设置“consent”。根据该形式，如果用户拒绝客户端400的授权，则从批准信息表中删除记录。当授权服务器200接收到用户进行的授权操作时，生成表3中的批准信息(s1.6)。在s1.6中，在授权服务器200中管理包括客户端id和用户id的批准信息。根据本实施例，除了客户端id和用户id之外，还管理在s7.0(图10)中接收到的登录上下文作为如表3中的批准信息。用于判断登录上下文是否包括在批准信息中的标准取决于在客户端400中是否预设了该登录上下文。授权服务器200可以主要基于以下两种形式来判断登录上下文是否存在于客户端400中。一种形式向授权服务器200通知当在s0.0中登记了与客户端400有关的信息时，客户端400是具有登录上下文的多用户装置。根据第二种形式，当web浏览器向授权服务器200发送授权请求时，另外发送状态参数和用于通知状态参数的值是登录上下文的另一参数。这里假设，根据本实施例，授权服务器200基于这两种形式之一判断为登录上下文存在于客户端400中，并且登录上下文包括在与用户有关的批准信息中。参考图12，将描述用于判断是否要在web浏览器上显示授权确认画面的流程。图12中的流程在授权服务器200在s12.1中接收到授权码请求之后、在s12.2中判断是否要显示登录画面时执行。图5a示出登录画面的示例。当通过web浏览器上的登录画面输入用户id和密码时，授权服务器200从web浏览器接收认证请求(s12.3)。由于s12.1、s12.2和s12.3中的处理与图10中的s7.0、s1.3和s1.4中的处理相同，因此将省略任何重复的细节描述。授权服务器200判断在s12.3中接收到的用户id以及在s7.0中接收到的登录上下文和客户端id与作为批准信息而预先保存在授权服务器200中的用户id、客户端id和登录上下文是否一致(s12.4)。如果在s12.4中判断为预先登记的批准信息与s12.3中的用户id以及s7.0中的登录上下文和客户端id一致，则处理移至s12.5。这里，与向授权服务器200登记为批准信息的用户id、客户端id和登录上下文一致的用户id、客户端id和登录上下文表示由用户id和登录上下文识别出的用户已经通过使用由客户端id识别出的客户端400执行了授权操作。。另一方面，如果在s12.4中未判断为预先登记的批准信息与s12.3中的用户id以及s7.0中的登录上下文和客户端id一致，则判断为用户尚未执行授权操作。然后，基于s12.3中的用户id以及s7.0中的登录上下文和客户端id来生成新的批准信息(s12.9)。新生成的批准信息作为记录添加到表3所示的示例的批准信息中。在s12.4中判断为一致的批准信息之后，判断预先登记的批准信息是否是用户批准授权的信息(s12.5)。更具体地，确认表3中的consent的值。如果consent具有“1”，则执行对客户端400的授权码响应，而不执行授权确认画面(s1.5)和授权操作(s1.6)。然后处理流程结束。另一方面，如果consent具有“0”或者如果在s12.9中生成新的批准信息，则将作为用于查询授权批准的画面的授权确认画面返回到web浏览器(s12.6)。基于用户的操作来接收批准结果(s12.7)，并且将批准结果保存在授权服务器200中(s12.8)。表3示出要保存的批准信息的示例。由于s12.6和s12.7中的处理与图10中的s1.5和s1.6中的处理相同，因此将省略任何重复的细节描述。已经描述了用于判断是否要在web浏览器上显示授权确认画面的流程。根据实施例3，将登录上下文添加到此时的批准信息(包括用户id和客户端id)。每当与用户id和登录上下文不一致时，都可以显示授权批准画面，并且可以防止批准信息被多个用户共享，而无需新生成和管理用户信息。实施例4根据实施例4，授权码不用于发出用于降低授权服务器200中的授权码的生成和管理的负荷的授权令牌。参考图13，将描述根据实施例4的基于oauth2.0的授权码授予的处理。相同的标号指代前述实施例和本实施例中的相同部分，并且将省略任何重复的细节描述。尽管将参考与传统技术(图1)的组合来描述实施例4，但是实施例4不限于此，可以与实施例1(图6)、实施例2(图10)或实施例3组合。首先，在s1.1中向客户端400发送授权流程的发起请求之后，客户端400向授权服务器200发送授权码请求(s7.2)。尽管要在s7.2中发送的信息与s1.2中的相同，但是“id_token”而不是“code”被指定为授权码请求的响应类型。将“id_token”指定为授权码请求的响应类型使得授权服务器200能够在对客户端400的授权码响应中发送用户id而不是授权码。在用户在s1.3至s1.6中批准客户端400的授权之后，授权服务器200向客户端400发送授权码响应(s7.3)。在这种情况下，授权服务器200利用用于将用户id(user_id)和状态参数重定向到重定向uri的指示来响应于web浏览器。更具体地，授权服务器200通过使用客户端400的公钥来对用户id和状态参数添加数字签名。已经在s7.3中接收到授权码响应的客户端400通过使用客户端400保持的私钥来验证数字签名，并验证了授权码响应的内容未被更改。客户端400还验证了在授权码请求中发送的状态参数与在授权码响应中接收到的状态参数一致，以确定授权码请求和授权码响应彼此相关联。在确定为授权码请求和授权码响应彼此相关联之后，客户端400将令牌请求发送到授权服务器200的令牌端点(s7.4)。令牌请求包括“grant_type＝authorization_code”，这表示授权流程是授权码授予。尽管在“oauth2.0”的规则下“grant_type”的值是“authorization_code”，但是根据本实施例，将使用用户id而不是授权码来发出授权令牌。令牌请求还包括客户端密钥、客户端id和作为在s7.3中获得的用户id的jwt(jsonweb令牌)。更具体地，jwt在这里被设置为在oauth2.0jwt配置文件中声明的client_assertion_type：jwt-bearer的client_assertion中的参数。这里假设客户端id是“client_01”并且用户id是“user_01”。客户端400通过使用客户端400所保持的私钥将数字签名添加到客户端id和用户id。已经在s7.4中接收到令牌请求的授权服务器200通过使用从客户端id识别的公钥来验证添加到令牌请求的数字签名，以认证客户端400。所接收的客户端id和用户id用于获得批准信息以判断用户是否批准客户端400的授权。如果判断为用户批准授权，则授权服务器200发出授权令牌并将所发出的授权令牌作为令牌响应发送到客户端400(s7.5)。这里，不发出用于再次获得授权令牌的刷新令牌。这是因为，参考图1描述的授权码授予流程通过使用授权码发出授权令牌，并且当授权令牌被发出时使授权码无效。因此，发出刷新令牌以省略用于再次执行授权码授予的处理流程的处理，并且授权服务器200和客户端400存储刷新令牌。然而，根据本实施例，基于批准信息(包括客户端id和用户id)发出授权令牌。因此，为了再次获得授权令牌，可以通过使用在授权服务器200中管理的批准信息来执行令牌请求。到此为止，已经描述了不使用授权码来发出授权令牌的处理。根据实施例4，授权服务器200可以省略用于发出和存储授权码和刷新令牌的处理，这可以降低用于管理授权服务器200中的授权码和刷新令牌的成本。省略客户端400中的刷新令牌存储处理可以进一步降低客户端400中的管理成本。实施例4和实施例3的组合(其包括批准信息中的登录上下文)在s7.4中在令牌请求中发送客户端id、用户id和登录上下文。其它实施例在包括在jwt中包括重定向uri和与客户端400有关的信息的实施例(实施例1)、登录上下文被设置为状态参数的实施例(实施例2))、以及在不发出授权码的情况下发出授权令牌的实施例(实施例4)的上述实施例之间，可以进行任何组合。可以在授权码请求中指定表示授权范围的范围参数。例如，可以与授权码、授权令牌和刷新令牌相关联地管理在授权码请求中指定的范围参数。该范围参数表示的授权范围可以显示在所显示的授权确认画面5100中。本发明的实施例还可以通过如下的方法来实现，即，通过网络或者各种存储介质将执行上述实施例的功能的软件(程序)提供给系统或装置，该系统或装置的计算机或是中央处理单元(cpu)、微处理单元(mpu)读出并执行程序的方法。尽管已经参考典型实施例说明了本发明，但是应该理解，本发明不局限于所公开的典型实施例。所附权利要求书的范围符合最宽的解释，以包含所有这类修改、等同结构和功能。当前第1页12