插件升级的方法、系统及装置与流程

本发明涉及金融设备技术领域，特别是涉及插件升级的方法、系统及装置。

背景技术：

在软件设计中，为了方便对软件进行功能扩展，通常采用插件方式进行开发，将软件所要实现的一个一个功能封装在插件中。通过插件式的软件架构，不需要修改应用程序，就可以增减应用程序的功能，提高了软件的可扩展性。对软件插件升级通常的做法是：通过服务器对用户端软件的所有插件统一进行升级，以及统一的软件版本管理。

然而这种插件升级方式的灵活度受限，特别是在应用软件和硬件相关的场合，例如现金处理设备(ATM(Automatic Teller Machine，自动取款机)、VTM(Virtual Teller Machine，虚拟柜员机)、清分机、售票机等)，由于用户端的应用软件及其功能插件与设备硬件特性紧密相关，同一功能的用户端存在着不同厂商提供的硬件设备，没法做到软件版本统一管理以及插件统一升级，因此容易导致因插件版本与设备硬件不兼容引起的设备故障、账务长短款等问题，为避免此类问题，需要人工一对一的对用户端的软件插件进行升级维护，维护效率低，维护成本高。

技术实现要素：

基于此，本发明实施例提供一种插件升级的方法、系统及装置，能够提高对用户端软件插件升级维护的效率。

本发明一方面提供一种插件升级的方法，包括：

服务器确定待升级的用户端；根据待升级的用户端、各用户端待升级的插件创建与用户端的设备属性对应的升级任务列表；

用户端向服务器发送升级任务的查询请求；

服务器获取所述用户端对应的设备属性，查询已创建的升级任务列表中有所述用户端对应的升级任务，向所述用户端返回所述升级任务的清单；所述升级任务的清单中至少包括需升级的插件、插件版本以及下载地址；

所述用户端根据所述升级任务的清单下载相应的插件，将本地的控制软件的相应插件升级到对应版本。

本发明又一方面提供一种插件升级的方法，包括：

向服务器发送升级任务的查询请求；

接收服务器返回的与本端的设备属性对应的升级任务的清单；所述升级任务的清单中至少包括需升级的插件、插件版本以及下载地址；

根据所述升级任务的清单下载相应的插件，将本地的控制软件的相应插件升级到对应版本。

本发明又一方面提供一种插件升级的方法，包括：

确定待升级的用户端；根据待升级的用户端、各用户端待升级的插件创建与用户端的设备属性对应的升级任务列表；

接收用户端发送的升级任务的查询请求，获取所述用户端对应的设备属性，查询已创建的升级任务列表中有所述用户端对应的升级任务；

向所述用户端返回所述升级任务的清单，所述升级任务的清单中至少包括需升级的插件、插件版本以及下载地址。

本发明又一方面提供一种插件升级的系统，包括服务器和用户端，所述服务器和用户端通信连接，所述服务器包括：

任务创建模块，用于确定待升级的用户端；根据待升级的用户端、各用户端待升级的插件创建与用户端的设备属性对应的升级任务列表；

所述用户端包括：

任务查询模块，用于向服务器发送升级任务的查询请求；

所述服务器还包括：

任务下发模块，用于获取所述用户端对应的设备属性，查询已创建的升级任务列表中有所述用户端对应的升级任务，向所述用户端返回所述升级任务的清单；所述升级任务的清单中至少包括需升级的插件、插件版本以及下载地址；

所述用户端还包括：

升级执行模块，用于根据所述升级任务的清单下载相应的插件，将本地的控制软件的相应插件升级到对应版本。

本发明又一方面提供一种插件升级的装置，包括：

任务查询模块，用于向服务器发送升级任务的查询请求；以及用于接收服务器返回的与本端的设备属性对应的升级任务的清单；所述升级任务的清单中至少包括需升级的插件、插件版本以及下载地址；

升级执行模块，用于根据所述升级任务的清单下载相应的插件，将本地的控制软件的相应插件升级到对应版本。

本发明又一方面提供一种插件升级的装置，包括：

任务创建模块，用于确定待升级的用户端；根据待升级的用户端、各用户端待升级的插件创建与用户端的设备属性对应的升级任务列表；

任务下发模块，用于接收用户端发送的升级任务的查询请求，获取所述用户端对应的设备属性，查询已创建的升级任务列表中有所述用户端对应的升级任务；以及用于向所述用户端返回所述升级任务的清单；所述升级任务的清单中至少包括需升级的插件、插件版本以及下载地址。

上述技术方案，服务器可从全部通信连接的用户端中灵活确定出待升级的用户端以及待升级的插件，并创建相应的与用户端的设备属性对应的升级任务列表；各个用户端通过向服务器发送升级任务的查询请求，服务器根据所述用户端的设备属性查询已创建的升级任务列表中是否有该用户端对应的升级任务，若有则向对应用户端返回相应的升级任务的清单，包括需升级的插件、插件版本以及下载地址；从而各个用户端可分别根据服务器返回的升级任务的清单下载相应的插件，将本地的控制软件的相应插件升级到对应版本。由此可灵活确定需要升级的用户端以及用户端软件插件，并且可以同时对多个用户端进行差异化的插件升级，无需人工一对一的进行升级维护，提高了升级维护效率。

附图说明

图1为一实施例的插件升级的方法的示意性流程图；

图2为一实施例中服务器端创建的升级任务列表的ER图；

图3为与图2中升级任务列表关联的各升级任务的清单的ER图；

图4为一实施例中服务器端基于区域属性得到的用户端属性树结构的示意图；

图5为一实施例中服务器端基于设备类型得到的用户端属性树结构的示意图；

图6为基于图4的用户端属性树结构得到的用户端数据表的ER图；

图7为基于图5的用户端属性树结构得到的用户端数据表的ER图；

图8为一实施例中服务器端保存的版本档案中数据结构的逻辑示意图；

图9为一实施例中服务器端保存的版本档案中升级档案数据表的ER图；

图10为与图9中升级档案数据表关联的版本信息数据表的ER图；

图11为一实施例的服务器端主动型的插件升级的方法的应用场景的示意图；

图12为一实施例的用户端主动型的插件升级的方法的应用场景的示意图；

图13为另一实施例的插件升级的方法的示意性流程图；

图14为另一实施例的插件升级的方法的示意性流程图；

图15为一实施例的插件升级的系统的示意性结构图；

图16为一实施例的插件升级的装置的示意性结构图；

图17为一实施例的插件升级的装置的示意性结构图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

图1为一实施例的插件升级的方法的示意性流程图；在该实施例中，所述用户端为ATM、VTM、清分机、售票机等现金设备，这类用户端的控制软件均包含若干插件；并且这类用户端还与远程的服务器通信连接。参考图1所示，本实施例插件升级的方法包括步骤：

S11，服务器确定待升级的用户端；根据待升级的用户端、各用户端待升级的插件创建与用户端的设备属性对应的升级任务列表；

本实施例中，所述设备属性信息包括用户端对应的区域属性或者设备类型属性。服务器可根据选定的设备属性确定待升级的用户端，例如：预先根据设备属性信息建立用户端属性树结构，从预先建立的用户端属性树结构中确定出归属于所述选定的设备属性的用户端，作为待升级的用户端。由此可提供确定待升级的用户端的效率。

本实施例中，服务器端创建的升级任务列表可包括两类关联的数据表，一类为记录升级任务列表概况的数据表，其对应的ER图参考图2所示，至少包括升级任务ID以及对应的设备属性。另一类为反应各升级任务清单的数据表，对应的ER图参考图3所示，至少包括升级任务ID、插件名、插件版本以及下载地址等信息，升级任务概况的数据表与各升级任务清单的数据表通过升级任务ID为外键进行关联。

S12，用户端向服务器发送升级任务的查询请求；

本实施例中，用户端在启动时，检查服务器端是否有属于自己的升级任务，具体做法为向服务器发送升级任务的查询请求。可以理解的是，所述升级任务的查询请求中至少包含所述用户端的设备ID以及其所属的设备属性。

S13，服务器获取所述用户端对应的设备属性，查询已创建的升级任务列表中有所述用户端对应的升级任务，向所述用户端返回所述升级任务的清单；所述升级任务的清单中至少包括需升级的插件、插件版本以及下载地址；

本实施例中，服务器可根据预先建立用户端属性树结构获取请求用户端的设备属性，服务器端创建的升级任务列表以用户端的设备属性作为索引，因此服务器可根据用户端对应的设备属性查询已创建的升级任务列表，检测其中是否有该设备属性相关的升级任务。若有，进一步的，以升级任务ID作为外键关联到对应的任务清单数据表，得到对应的任务详情(清单)，例如：升级任务ID、需升级的插件、插件版本以及下载地址。由此可得到用户端对应的插件升级信息，然后将插件升级的详情下发给对应的用户端。

S14，所述用户端根据所述升级任务的清单下载相应的插件，将本地的控制软件的相应插件升级到对应版本。

用户端根据服务器下发的升级任务的清单，得到本次需要升级的插件、插件目标版本，并自动链接到相应的下载地址下载相应的插件，进而将本地的控制软件的相应插件升级到对应版本。

作为一优选实施方式，所述设备属性信息包括区域属性或者设备类型属性。本实施例的插件升级的方法还包括步骤：在服务器端预先根据区域属性创建第一用户端属性树结构，以及根据设备类型属性创建第二用户端属性树结构。下面结合图4～图7对在服务器端创建的用户端属性树结构及相关的用户端数据表进行举例说明。其中用户端的区域属性可根据用户端所属单位的组织结构进行划分，参考图4所示，可根据银行的结构划分现金设备的区域属性，将银行管辖区域按树形划分为若干一级区域属性，如分行域1～n，每个一级区域属性下又可划分为若干二级区域属性，如支行域1～n；如此类推叶子节点是具体的现金设备。在该树形结构中，最小的区域属性便是特定的某个设备(可用设备ID进行标识)。根据该树形结构可建立第一用户数据表，其ER图如图6所示，第一用户数据表可以叶子节点之外的区域属性(例如区域ID)作为外键。设备ID、区域ID均可根据实际情况设定，属于同一级的区域属性的区域ID各不相同，属于同一级的区域属性的设备ID各不相同。

此外，也可根据设备类型将若干用户端组织为树形结构。参考图5所示，例如按照功能进行组织，包含若干一级类型属性，如功能类型1～n(例如ATM为类型1，VTM为类型2等)，每个一级类型属性下又包含若干个二级类型属性，如厂商1～n,二级类型属性下又可包含若干三级类型属性，如型号1～n；如此类推叶子节点是某台具体的现金设备。该树形结构中，最小的类型属性便是特定的某个设备。如图7所示，根据该树形结构可建立第二用户数据表，其ER图如图7所示，其中叶子节点便是设备ID，第二用户数据表可以叶子节点之外的各级类型属性作为外键。设备ID、各级类型属性的ID可根据实际情况设定，属于同一级类型属性的各类型属性ID各不相同。

基于上述的服务器端创建的用户端属性树结构以及对应的用户端数据表，对应的，在步骤S12中服务器获取所述用户端对应的设备属性的过程可包括：查询所述第一用户端数据表或第二用户端数据表，得到所述用户端对应的设备属性。基于上述用户端数据表，其逻辑清晰，索引效率高。

本实施例中，在服务器端还预先建立有各用户端的控制软件的版本档案，该版本档案中记录的数据内容包括控制软件的历史版本信息，参考图8所示，可包括版本号、版本升级时间、对应的升级任务ID等信息；进一步的，每个历史版本下又进一步关联有插件的控制软件版本信息。参考图9所示，基于上述版本档案的数据结构，在服务器端的数据库中还预先创建了有用于保存用户端对应的控制软件的版本档案的数据表，包括一级数据表和与之关联的二级数据表，分别参考图9、图10，其中一级数据表用于保存用户端ID(即设备ID)、用户端控制软件的版本号、版本升级时间、对应的升级任务ID等，二级数据表记录了升级任务ID、插件名、插件版本以及下载地址等信息。并且，一级数据表与二级数据表以升级任务ID为外键进行关联。

本实施例中，在用户端记录其控制软件的当前控制软件版本信息，包括控制软件当前版本号、包含的插件名以及插件控制软件版本信息；也可以像服务器端一样，对历史版本信息均记录下来，形成一版本档案。优选的，本实施例中用户端以覆盖的方式仅记录控制软件的当前版本信息，以节省用户端的存储空间。

基于服务器端的版本档案和用户端本地记录的控制软件版本信息，作为一优选实施方式，用户端将本地的控制软件的相应插件升级到对应版本之后，还会更新本地记录的控制软件版本信息，并将更新后的控制软件版本信息上报给服务器；对应的，服务器在收到用户端上报的控制软件版本信息后，更新服务器端存储的该用户端的控制软件的版本档案。由此服务器端可统一管理各用户端的控制软件的控制软件版本信息，方便管理人员管理，即管理员可通过查看各用户端在服务器中的版本档案信息，确定出哪些用户端的控制软件需要升级，或者用户端控制软件的哪些插件需要升级，便于对分散在各地的用户端进行统一且差异化的升级管理；另一方面，在用户端和服务器两处均存储了控制软件版本信息，也有利于增强系统数据的可靠性，例如：当某用户端出现故障时，可根据服务器端保存的对应版本档案信息对该用户端进行恢复。

图11为本发明一实施例的服务器端主动型的插件升级的方法的应用场景的示意图，如图11所示，本应用场景下，由服务器主动管理用户端插件升级，用户端插件升级的过程如下：

S111，管理人员基于服务器端保存的各用户端的控制软件的版本档案，对服务器端进行升级设置；

本实施例中，可设置待升级的设备属性，例如设置某分行下的设备属性，或者设置某厂商的设备属性。对应的，只需输入或者选择某分行的设备属性，或者某厂商的设备属性，由此可从全部用户端中确定若干个待升级的用户端。既方便对用户端进行灵活的管理，又可保证维护效率。

S112，服务器端接收升级设置，根据设置的设备属性确定待升级的用户端以及待升级的插件，创建升级任务列表；

服务器端可同时创建多个用户端对应的升级任务，构成升级任务列表。

S113，用户端启动时，向服务器发送升级任务的查询请求；

所述升级任务的查询请求中至少包含用于确定所述用户端对应的设备属性的信息；

S114，服务器获取所述用户端对应的设备属性，查询已创建的升级任务列表中有所述用户端对应的升级任务，向用户端发送所述升级任务的清单；

本实施例中，可根据该用户端在用户端属性树结构中的中位置，确定出所述用户端对应的设备属性，进而检测升级任务列表中是否存在有该用户端相关的升级任务。

若确定出升级任务列表中没有该用户端相关的升级任务，可返回空的响应，或者不做回应。

S115，用户端在收到服务器端发送的升级任务的清单后，便可根据所述升级任务的清单下载相应的插件，将本地的控制软件的相应插件升级到对应版本。

若用户端在收到服务器端返回的空响应，或者，在发出升级任务的查询请求后设定时间内未收到服务器端的响应，则确定为当前没有升级任务，不进行控制软件的升级。

S116，用户端将本地的控制软件的相应插件升级到对应版本之后，更新本地记录的控制软件版本信息；

S117，用户端将更新后的控制软件版本信息上报给服务器。

客户端直接将更新后的控制软件版本信息发送给服务器。

S118，服务器在收到用户端上报的控制软件版本信息后，更新服务器端存储的所述用户端的控制软件的版本档案。该方案可以降低服务器的运算量。

在另一优选实施方式中，在客户端将本地的控制软件的相应插件升级到对应版本之后，步骤S117还可替换为：用户端向服务器端发送升级完成的消息，所述消息的内容包括升级任务ID和升级完成状态，但不包括具体的软件版本信息。对应的，步骤S118可替换为，服务器在收到上述消息之后，可根据升级完成状态和所述升级任务ID检索获得对应的控制软件版本信息，进而根据所述控制软件版本信息更新服务器端存储的所述用户端的控制软件的版本档案。即服务器在收到上述消息之后，若检测到为升级成功的升级完成状态，则根据所述升级任务ID检索获得对应的控制软件版本信息，进而更新服务器端存储的所述用户端的控制软件的版本档案。该方案有利于进一步减少用户端与服务器之间的数据传输量。

在实际使用中，某区域属性的全部用户端或者某区域属性的某些用户端，因硬件环境的变更或者需求功能变更，其控制软件的插件需回退到某个历史版本。针对该情况，作为另一优选实施方式，本实施例的用户端还可主动请求版本回退，实现过程包括：若用户端检测到回退指令，向服务器发送版本档案的查询请求，所述版本档案的查询请求中至少包括用于确定所述用户端对应的设备属性的信息；服务器获取与所述用户端对应的控制软件的版本档案，向所述用户端返回所述版本档案；用户端向所述服务器发送回退更新请求，所述回退更新请求中至少包括从所述版本档案中确定出的目标版本/升级时间点；服务器根据所述目标版本/升级时间点确定出对应的历史升级任务，向所述用户端返回所述历史升级任务的清单；所述历史升级任务的清单中至少包括需回退的插件、插件版本以及下载地址；用户端根据所述历史升级任务的清单下载相应的插件，将本地的控制软件的相应插件回退更新到对应的版本，完成用户端控制软件的版本回退。

图12为本发明一实施例的用户端主动型的插件升级的方法的应用场景的示意图，本应用场景下，由用户端主动发起升级请求(这里指的是回退版本的请求)，实现用户端插件升级的过程如下：

S121，管理人员对用户端进行设置，向用户端发出控制软件的回退指令。

S122，用户端检测到回退指令，向服务器发送版本档案的查询请求；

S123，服务器获取所述用户端对应的控制软件的版本档案；向所述用户端返回所述版本档案；

S124，管理人员可在用户端根据服务器返回的版本档案，确定当前需回退的控制软版本，或者历史上的升级时间点，对用户端进行回退设置；

S125，用户端接收所述回退设置，向所述服务器发送回退更新请求，所述回退更新请求中至少包括从所述版本档案中确定出的目标版本/升级时间点；

S126，服务器根据所述目标版本/升级时间点确定出对应的历史升级任务，并获得该历史升级任务对应的清单；

S127，向所述用户端返回该条历史升级任务的清单；该条俩是升级任务的清单中至少包括需回退的插件、插件版本以及下载地址；

S128，用户端根据该条历史升级任务的清单下载相应的插件，将本地的控制软件的相应插件回退更新到对应的版本；并更新本地记录的控制软件版本信息；

S129，将更新后的控制软件版本信息上报给服务器；

S130，服务器在收到用户端上报的控制软件版本信息后，更新服务器端存储的所述用户端的控制软件的版本档案。该方案可以降低服务器的运算量。

同理，在另一优选实施方式中，在客户端将本地的控制软件的相应插件回退更新到对应的版本之后，步骤S129还可替换为：用户端向服务器端发送回退更新完成的消息，所述消息的内容包括升级任务ID和升级完成状态，但不包括具体的软件版本信息。对应的，步骤S130可替换为，服务器在收到上述回退更新完成的消息之后，可根据所述升级任务ID和升级完成状态检索获得对应的控制软件版本信息，进而根据所述控制软件版本信息更新服务器端存储的所述用户端的控制软件的版本档案。该方案有利于进一步减少用户端与服务器之间的数据传输量。

基于上述实施例的插件升级的方法，可基于服务器主动对选定的用户端进行升级维护，创建相应的升级任务列表；使得各个用户端可分别根据服务器返回的升级任务的清单下载相应的插件，将本地的控制软件的相应插件升级到对应版本；由此可灵活确定需要升级的用户端以及用户端的软件插件，并且可以同时对多个用户端进行差异化的插件升级，无需人工一对一的进行升级维护；同时，还可基于用户端主动发起升级请求，以此对有回退需要的用户端控制软件实现快速回退，进一步提高了升级维护效率。

图13为另一实施例的插件升级的方法的示意性流程图；在该实施例中，以应用于用户端为例，对完成插件升级的方式进行说明。所述用户端为ATM、VTM、清分机、售票机等现金设备，这类用户端的控制软件均包含若干插件；并且这类用户端还与远程的服务器通信连接。参考图13所示，本实施例中的插件升级的方法包括步骤：

S21，向服务器发送升级任务的查询请求；

本实施例中，本端在启动时，向服务器发送升级任务的查询请求，所述升级任务的查询请求包含有用于确定本端对应的设备属性的信息。

S22，接收服务器返回的与本端的设备属性对应的升级任务的清单；所述升级任务的清单中至少包括需升级的插件、插件版本以及下载地址；

服务器返回的升级任务，即可以是仅针对本端的升级任务，也可以是针对包含本端在内的、归属于相同设备属性的多个用户端的的升级任务，具体可基于服务器端预先建立的用户端属性树结构实现。

S23，根据所述升级任务的清单下载相应的插件，将本地的控制软件的相应插件升级到对应版本。

作为一优选实施方式，将本地的控制软件的相应插件升级到对应版本之后，还需更新本地记录的控制软件版本信息，并将更新后的控制软件版本信息上报给服务器，指示服务器更新服务器端存储的所述用户端的控制软件的版本档案。

作为一优选实施方式，所述的插件升级的方法还可包括步骤：

S24，若检测到回退指令，向所述服务器发送版本档案的查询请求；

S25，接收所述服务器返回的与本端对应的控制软件的版本档案；

S26，向所述服务器发送回退更新请求，所述回退更新请求中至少包括从所述版本档案中确定出的目标版本/升级时间点；

S27，接收所述服务器返回的与所述目标版本/升级时间点对应的历史升级任务的清单，所述历史升级任务的清单中至少包括需回退更新的插件、插件版本以及下载地址；

S28，根据所述历史升级任务的清单下载相应的插件，将本地的控制软件的相应插件回退更新到对应版本。

需要说明的是，对于某一用户端来说，上述步骤S21～S23、步骤S24～S28两部分的执行先后顺序可互换，即先执行步骤S24～S28，再步骤S21～S23。

图14为另一实施例的插件升级的方法的示意性流程图；在该实施例中，以应用于服务器为例，对完成插件升级的方式进行说明。所述服务器与若干用户端通信连接，所述用户端为ATM、VTM、清分机、售票机等现金设备，这类用户端的控制软件均包含若干插件。参考图14所示，本实施例中的插件升级的方法包括步骤：

S31，确定待升级的用户端；根据待升级的用户端、各用户端待升级的插件创建与用户端的设备属性对应的升级任务列表；

S32，接收用户端发送的升级任务的查询请求，获取所述用户端对应的设备属性，查询已创建的升级任务列表中有所述用户端对应的升级任务；

上述升级任务列表中的升级任务，即可以是仅针对某一个用户端的升级任务，也可以是针对归属于某一设备属性的多个用户端的升级任务，若为后者，则在接收到归属于该设备属性的任意用户端的查询请求时，则均能查询已创建的升级任务列表中的同一升级任务。

S33，向所述用户端返回所述升级任务的清单，所述升级任务的清单中至少包括需升级的插件、插件版本以及下载地址。

作为一优选实施方式，上述插件升级的方法还包括：服务器预先根据设备属性信息建立用户端属性树结构，参考图4、图5所示，所述设备属性信息包括用户端对应的区域属性或者设备类型属性；所述服务器确定待升级的用户端的过程包括：服务器根据选定的设备属性，从所述用户端属性树结构中确定出归属于所述选定的设备属性的用户端，作为待升级的用户端。

作为一优选实施方式，上述插件升级的方法还包括：若收到用户端上报的控制软件版本信息，则对本地存储的所述用户端的控制软件的版本档案进行相应的更新。

作为一优选实施方式，上述插件升级的方法还包括：

S34，若检测到用户端发送的版本档案的查询请求，则获取与所述用户端对应的控制软件的版本档案，并向所述用户端返回所述版本档案；

S35，若接收到用户端发送的回退更新请求，所述回退更新请求中至少包括从所述版本档案中确定出的目标版本/升级时间点；则根据所述目标版本/升级时间点确定出对应的历史升级任务，向所述用户端返回所述历史升级任务的清单；所述历史升级任务的清单中至少包括需回退的插件、插件版本以及下载地址。

需要说明的是，对于某一用户端来说，上述步骤S31～S33、步骤S34～S35两部分的执行先后顺序可互换，即先执行步骤S34～S35，再步骤S31～S33，或者两部分并发执行。

需要说明的是，对于前述的各方法实施例，为了简便描述，将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其它顺序或者同时进行。

基于与上述实施例中的插件升级的方法相同的思想，本发明还提供插件升级的系统及装置，系统及装置可用于执行上述对应的插件升级的方法。为了便于说明，插件升级的系统/装置实施例的结构示意图中，仅仅示出了与本发明实施例相关的部分，本领域技术人员可以理解，图示结构并不构成对系统/装置的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

图15为本发明一实施例的插件升级的系统的示意性结构图，包括服务器100和用户端200，所述服务器100和若干用户端200通信连接。

其中，所述服务器100包括：任务创建模块101，用于确定待升级的用户端；根据待升级的用户端、各用户端待升级的插件创建与用户端的设备属性对应的升级任务列表；

所述用户端200包括：任务查询模块201，用于向服务器发送升级任务的查询请求；

所述服务器100还包括：任务下发模块102，用于获取所述用户端对应的设备属性，查询已创建的升级任务列表中有所述用户端对应的升级任务，向所述用户端返回所述升级任务的清单；所述升级任务的清单中至少包括需升级的插件、插件版本以及下载地址；

所述用户端200还包括：升级执行模块202，用于根据所述升级任务的清单下载相应的插件，将本地的控制软件的相应插件升级到对应版本。

作为一优选实施方式，所述用户端200还包括：版本上报模块(图中未示出)，用于在将本地的控制软件的相应插件升级到对应版本之后，更新本地记录的控制软件版本信息，将更新后的控制软件版本信息上报给服务器；所述服务器100还包括：档案更新模块(图中未示出)，用于在收到用户端上报的控制软件版本信息后，更新服务器端存储的所述用户端的控制软件的版本档案。

作为一优选实施方式，所述服务器100还包括：用户树创建模块(图中未示出)，用于预先根据设备属性信息建立用户端属性树结构，参考图4、图5所示。以便根据用户端属性树结构确定待升级的用户端。

作为一优选实施方式，参考图16、图17所示，所述用户端200还包括：回退请求模块203，用于若检测到回退指令，向所述服务器发送版本档案的查询请求；所述服务器100还包括：档案管理模块103，用于获取与所述用户端对应的控制软件的版本档案，向所述用户端返回所述版本档案；所述回退请求模块203还用于向所述服务器发送回退更新请求，所述回退更新请求中至少包括从所述版本档案中确定出的目标版本/升级时间点；所述服务器100还包括：回退确认模块104，用于根据所述目标版本/升级时间点确定出对应的历史升级任务，向所述用户端返回所述历史升级任务的清单；所述历史升级任务的清单中至少包括需回退的插件、插件版本以及下载地址；所述用户端200还包括：回退执行模块204，用于根据服务器发送的历史升级任务的清单下载相应的插件，将本地的控制软件的相应插件回退更新到对应版本。

上述实施例的插件升级的系统，服务器可从全部通信连接的用户端中灵活确定出待升级的用户端以及待升级的插件，并创建相应的与用户端的设备属性对应的升级任务列表；用户端通过向服务器发送升级任务的查询请求，服务器根据所述用户端的设备属性查询已创建的升级任务列表中是否有该用户端对应的升级任务，若有则向对应用户端返回相应的升级任务的清单，包括需升级的插件、插件版本以及下载地址；从而用户端可分别根据服务器返回的升级任务的清单下载相应的插件，将本地的控制软件的相应插件升级到对应版本。由此可在服务器端灵活确定需要升级的用户端以及用户端软件插件，并且可以同时对多个用户端进行差异化的插件升级，无需人工一对一的进行升级维护，提高了升级维护效率。

参考图16，本发明一实施例的插件升级的装置的示意性结构图，该装置可以应用于与服务器连接的用户端，例如任一联网的ATM机。本实施例的插件升级的装置包括：任务查询模块201、以及升级执行模块202，各模块详述如下：

所述任务查询模块201，用于向服务器发送升级任务的查询请求；以及用于接收服务器返回的与本端的设备属性对应的升级任务的清单；所述升级任务的清单中至少包括需升级的插件、插件版本以及下载地址；

所述升级执行模块202，用于根据所述升级任务的清单下载相应的插件，将本地的控制软件的相应插件升级到对应版本。

作为一优选实施方式，还可包括回退请求模块203，用于若检测到回退指令，向所述服务器发送版本档案的查询请求；还用于向所述服务器发送回退更新请求，所述回退更新请求中至少包括从所述版本档案中确定出的目标版本/升级时间点；以及回退执行模块204，用于接收所述服务器返回的与所述目标版本/升级时间点对应的历史升级任务的清单，并根据服务器发送的历史升级任务的清单下载相应的插件，将本地的控制软件的相应插件回退更新到对应版本。

本实施例的装置在启动时，检查服务器端是否有属于自己的升级任务，如有就按照对应的升级任务的信息下载需要更新的插件；还可进行本端控制软件的回退更新，并在完成更新后，还可通知服务器端更新本端的版本档案记录。服务器端登记有包括本次升级在内的、本端所有的历史版本信息。

图17为本发明一实施例的插件升级的装置的示意性结构图，该装置可以应用于与若干用户端通信连接的服务器。如图17所示，本实施例的插件升级的装置包括：任务创建模块101、以及任务下发模块102，各模块详述如下：

所述任务创建模块101，用于确定待升级的用户端；根据待升级的用户端、各用户端待升级的插件创建与用户端的设备属性对应的升级任务列表；

所述任务下发模块102，用于接收用户端发送的升级任务的查询请求，获取所述用户端对应的设备属性，查询已创建的升级任务列表中有所述用户端对应的升级任务；以及用于向所述用户端返回所述升级任务的清单；所述升级任务的清单中至少包括需升级的插件、插件版本以及下载地址。

作为一优选实施方式，还可包括档案管理模块103，用于若接收到用户端发送的版本档案的查询请求，则获取与所述用户端对应的控制软件的版本档案，向所述用户端返回所述版本档案；以及，回退确认模块104，用于若接收到用户端发送的回退更新请求，根据回退更新请求中的目标版本/升级时间点确定出对应的历史升级任务，向所述用户端返回所述历史升级任务的清单；所述历史升级任务的清单中至少包括需回退的插件、插件版本以及下载地址。

通过本实施例的装置，可为选定设备属性的若干用户端创建升级任务信息，以对用户端进行灵活的、差异化的管理，有利于提高用户端升级维护的效率，降低维护成本；另一方面，还可管理用户端控制软件的回退更新，将用户端控制软件的插件快速回退到对应的历史版本。

需要说明的是，上述示例的插件升级的系统/装置的实施方式中，各模块之间的信息交互、执行过程等内容，由于与本发明前述方法实施例基于同一构思，其带来的技术效果与本发明前述方法实施例相同，具体内容可参见本发明方法实施例中的叙述，此处不再赘述。

此外，上述示例的插件升级的系统/装置的实施方式中，各功能模块的逻辑划分仅是举例说明，实际应用中可以根据需要，例如出于相应硬件的配置要求或者软件的实现的便利考虑，将上述功能分配由不同的功能模块完成，即将所述插件升级的装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。其中各功能模既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

本领域普通技术人员可以理解，实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，作为独立的产品销售或使用。所述程序在执行时，可执行如上述各方法的实施例的全部或部分步骤。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。可以理解，其中所使用的术语“第一”、“第二”等在本文中用于区分对象，但这些对象不受这些术语限制。

以上所述实施例仅表达了本发明的几种实施方式，不能理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。