发明创造名称：一种虚拟资源转移方法、相关设备及系统
外观设计名称：
决定号：202009
决定日：2020-01-21
委内编号：1F255798
优先权日：
申请（专利）号：201510466637.4
申请日：2015-07-31
复审请求人：腾讯科技（深圳）有限公司
无效请求人：
授权公告日：
审定公告日：
专利权人：
主审员：邢鹏
合议组组长：牛晓丽
参审员：董杰
国际分类号：G06Q20/16,G06Q20/40,H04L29/06
外观设计分类号：
法律依据：专利法第22条第3款
决定要点
：如果一项权利要求与作为最接近现有技术的对比文件存在区别特征，但该区别特征属于本领域公知常识，在该对比文件的基础上结合公知常识得到该权利要求的技术方案是显而易见的，则该权利要求不具备创造性。
全文：
本复审请求涉及申请号为201510466637.4，名称为“一种虚拟资源转移方法、相关设备及系统”的发明专利申请（下称本申请）。申请人为腾讯科技（深圳）有限公司。本申请的申请日为2015年07月31日，公开日为2015年12月16日。
经实质审查，国家知识产权局原审查部门于2018年03月27日发出驳回决定，驳回了本申请，其理由是：权利要求1-13相对于对比文件1（CN104732373 A，公开日期为2015年06月24日）结合本领域常用技术手段不具备专利法第22条第3款规定的创造性。驳回决定所依据的文本为申请人于申请日2015年07月31日提交的说明书第0001-0129段、说明书附图、说明书摘要以及摘要附图，于2017年12月08日提交的权利要求第1-13项。驳回决定所针对的权利要求书如下：
“1. 一种虚拟资源转移方法，其特征在于，包括：
第一客户端登陆公众服务账号，并基于所述公众服务账号发起业务请求；
第二客户端通过登录所述公众服务账号获取所述业务请求后，基于所述公众服务账号输入针对所述业务请求的业务订单信息；其中，所述公众服务账号为开发者或服务商在互联网应用中注册的服务帐号，开发者或服务商通过公众服务帐号为互联网应用中的一个或多个用户提供相应的服务；所述互联网应用对应有后台服务器；
与所述公众服务账号关联的应用服务器根据所述业务订单信息进行费用的计算，生成虚拟资源转移请求；或者所述应用服务器接收的所述业务订单信息中携带有上报的费用信息，根据所述费用信息直接生成虚拟资源转移请求，并通过所述公众服务账号向所述第一客户端发送所述虚拟资源转移请求；其中，与所述公众服务账号关联的应用服务器为通过公众服务帐号为互联网应用中的用户提供服务的服务器；所述后台服务器用于处理互联网应用在实现相应功能过程中的各种需求，并用于对互联网应用中的用户的相关信息、公众服务帐号的相关信息及用户之间、用户与公众服务帐号之间的交互消息进行管理；
所述第一客户端接收到所述虚拟资源转移请求后，将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移。
2. 如权利要求1所述的方法，其特征在于，所述第一客户端接收到所述虚拟资源转移请求后，将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移包括：
所述第一客户端通过所述公众服务账号接收所述虚拟资源转移请求；
通过所述公众服务账号触发生成虚拟资源转移界面，以指示与所述第一客户端预设关联的第一虚拟资源账号转移虚拟资源至与所述公众服务账号预设关联的第二虚拟资源账号；
所述第一客户端根据在所述虚拟资源转移界面输入的转移确认信息，将所述第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移。
3. 如权利要求1所述的方法，其特征在于，所述第二客户端通过所述公众服务账号获取所述业务请求后，基于所述公众服务账号输入针对所述业务请求的业务订单信息包括：
当所述业务请求包括多个业务信息时，所述第二客户端基于所述公众服务账号分别针对各个业务信息输入业务订单信息；
通过所述公众服务账号对输入的多个业务订单信息进行汇总，生成汇总后的业务订单信息。
4. 如权利要求1所述的方法，其特征在于，所述将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移之后，还包括：
所述公众服务账号获知所述第一客户端将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移后，向所述第一客户端和/或所述第二客户端发送虚拟资源转移完成信息。
5. 一种客户端设备，其特征在于，包括：
登录发送模块，用于登录公众服务账号，并基于所述公众服务账号发起业务请求；以使第二客户端通过登录所述公众服务账号获取所述业务请求后，基于所述公众服务账号输入针对所述业务请求的业务订单信息；与所述公众服务账号关联的应用服务器根据所述业务订单信息进行费用的计算，生成虚拟资源转移请求；或者所述应用服务器接收的所述业务订单信息中携带有上报的费用信息，根据所述费用信息直接生成虚拟资源转移请求，并通过所述公众服务账号向所述客户端设备发送所述虚拟资源转移请求；其中，所述公众服务账号为开发者或服务商在互联网应用中注册的服务帐号，开发者或服务商通过公众服务帐号为互联网应用中的一个或多个用户提供相应的服务；所述互联网应用对应有后台服务器；与所述公众服务账号关联的应用服务器为通过公众服务帐号为互联网应用中的用户提供服务的服务器；所述后台服务器用于处理互联网应用在实现相应功能过程中的各种需求，并用于对互联网应用中的用户的相关信息、公众服务帐号的相关信息及用户之间、用户与公众服务帐号之间的交互消息进行管理；
虚拟资源转移模块，用于接收到所述虚拟资源转移请求后，将第一虚拟资 源账号中的虚拟资源向第二虚拟资源账号转移。
6. 如权利要求5所述的客户端设备，其特征在于，所述虚拟资源转移模块包括：
转移请求接收单元，用于通过所述公众服务账号接收所述虚拟资源转移请求；
转移界面生成单元，用于通过所述公众服务账号触发生成虚拟资源转移界面，以指示与所述第一客户端预设关联的第一虚拟资源账号转移虚拟资源至与所述公众服务账号预设关联的第二虚拟资源账号；
转移单元，用于根据在所述虚拟资源转移界面输入的转移确认信息，将所述第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移。
7. 如权利要求5所述的客户端设备，其特征在于，还包括：
第一转移完成信息接收模块，用于在所述公众服务账号获知所述第一客户端根据所述虚拟资源转移请求完成了虚拟资源转移后，通过所述公众服务账号接收虚拟资源转移完成信息。
8. 一种客户端设备，其特征在于，包括：
业务请求接收模块，用于通过登录公众服务账号获取业务请求；所述业务请求为第一客户端登陆所述预设的公众服务账号，并基于所述公众服务账号发起的业务请求；其中，所述公众服务账号为开发者或服务商在互联网应用中注册的服务帐号，开发者或服务商通过公众服务帐号为互联网应用中的一个或多个用户提供相应的服务；所述互联网应用对应有后台服务器；
订单信息输入模块，用于基于所述公众服务账号输入针对所述业务请求的业务订单信息；以使与所述公众服务账号关联的应用服务器根据所述业务订单信息进行费用的计算，生成虚拟资源转移请求；或者所述应用服务器接收的所述业务订单信息中携带有上报的费用信息，根据所述费用信息直接生成虚拟资源转移请求，并通过所述公众服务账号向所述第一客户端发送所述虚拟资源转移请求，所述第一客户端接收到所述虚拟资源转移请求后，将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移；其中，与所述公众服务账号关联的 应用服务器为通过公众服务帐号为互联网应用中的用户提供服务的服务器；所述后台服务器用于处理互联网应用在实现相应功能过程中的各种需求，并用于对互联网应用中的用户的相关信息、公众服务帐号的相关信息及用户之间、用户与公众服务帐号之间的交互消息进行管理。
9. 如权利要求8所述的客户端设备，其特征在于，所述订单信息输入模块包括：
输入单元，用于当所述业务请求接收模块接收到的业务请求包括多个业务信息时，基于所述公众服务账号分别针对各个业务信息输入业务订单信息；
汇总单元，用于通过所述公众服务账号对输入的多个业务订单信息进行汇总，生成汇总后的业务订单信息。
10. 如权利要求8所述的客户端设备，其特征在于，还包括：
第二转移完成信息接收模块，用于在所述公众服务账号获知所述第一客户端将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移后，通过所述公众服务账号接收虚拟资源转移完成信息。
11. 一种应用服务器，其特征在于，所述应用服务器为通过公众服务帐号为互联网应用中的用户提供服务的服务器，包括：
转移请求生成模块，用于根据业务订单信息进行费用的计算，生成虚拟资源转移请求；或者所述应用服务器接收的所述业务订单信息中携带有上报的费用信息，根据所述费用信息直接生成虚拟资源转移请求；所述业务订单信息为第一客户端登陆公众服务账号，并基于所述公众服务账号发起业务请求，第二客户端通过登录所述公众服务账号获取所述业务请求后，基于所述公众服务账号输入针对所述业务请求的业务订单信息；其中，所述公众服务账号为开发者或服务商在互联网应用中注册的服务帐号，开发者或服务商通过公众服务帐号为互联网应用中的一个或多个用户提供相应的服务；所述互联网应用对应有后台服务器；所述后台服务器用于处理互联网应用在实现相应功能过程中的各种需求，并用于对互联网应用中的用户的相关信息、公众服务帐号的相关信息及用户之间、用户与公众服务帐号之间的交互消息进行管理；
转移请求发送模块，用于通过所述公众服务账号向所述第一客户端发送所述虚拟资源转移请求；以使所述第一客户端接收到所述虚拟资源转移请求后，将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移。
12. 一种虚拟资源转移系统，其特征在于，包括第一客户端、第二客户端和应用服务器，其中
第一客户端登陆公众服务账号，并基于所述公众服务账号发起业务请求；所述第二客户端通过登录所述公众服务账号获取所述业务请求后，基于所述公众服务账号输入针对所述业务请求的业务订单信息；其中，所述公众服务账号为开发者或服务商在互联网应用中注册的服务帐号，开发者或服务商通过公众服务帐号为互联网应用中的一个或多个用户提供相应的服务；所述互联网应用对应有后台服务器；与所述公众服务账号关联的所述应用服务器根据所述业务订单信息进行费用的计算，生成虚拟资源转移请求；或者所述应用服务器接收的所述业务订单信息中携带有上报的费用信息，根据所述费用信息直接生成虚拟资源转移请求，并通过所述公众服务账号向所述第一客户端发送所述虚拟资源转移请求；其中，与所述公众服务账号关联的应用服务器为通过公众服务帐号为互联网应用中的用户提供服务的服务器；所述后台服务器用于处理互联网应用在实现相应功能过程中的各种需求，并用于对互联网应用中的用户的相关信息、公众服务帐号的相关信息及用户之间、用户与公众服务帐号之间的交互消息进行管理；所述第一客户端接收到所述虚拟资源转移请求后，将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移。
13. 如权利要求12所述的系统，其特征在于，所述第一客户端为所述权利要求5-7任一项所述的客户端设备；所述第二客户端为所述权利要求8-10任一项所述的客户端设备；所述应用服务器为所述权利要求12所述的应用服务器。”
申请人（下称复审请求人）对上述驳回决定不服，于2018年07月11日向国家知识产权局提出了复审请求，同时修改了权利要求书。复审请求人认为：对比文件1的系统架构和本申请的系统架构不同，支付以及订单生成的流程也不相同，因此本申请具备创造性。复审请求人于2018年07月11日提交的修改后的权利要求书如下：
“1. 一种虚拟资源转移方法，其特征在于，包括：
第一客户端登陆公众服务账号，并基于所述公众服务账号发起业务请求；
第二客户端通过登录所述公众服务账号获取所述业务请求后，基于所述公众服务账号输入针对所述业务请求的业务订单信息；其中，所述公众服务账号为开发者或服务商在互联网应用中注册的服务帐号，开发者或服务商通过公众服务帐号为互联网应用中的一个或多个用户提供相应的服务；所述互联网应用对应有后台服务器；
与所述公众服务账号关联的应用服务器根据所述业务订单信息进行费用的计算，生成虚拟资源转移请求；或者所述应用服务器接收的所述业务订单信息中携带有上报的费用信息，根据所述费用信息直接生成虚拟资源转移请求，并通过所述公众服务账号向所述第一客户端发送所述虚拟资源转移请求；其中，与所述公众服务账号关联的应用服务器为通过公众服务帐号为互联网应用中的用户提供服务的服务器；所述后台服务器用于处理互联网应用在实现相应功能过程中的各种需求，并用于对互联网应用中的用户的相关信息、公众服务帐号的相关信息及用户之间、用户与公众服务帐号之间的交互消息进行管理；其中，所述后台服务器与所述应用服务器为独立的两个服务器；
所述第一客户端接收到所述虚拟资源转移请求后，将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移；
所述第一客户端接收到所述虚拟资源转移请求后，将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移包括：
所述第一客户端通过所述公众服务账号接收所述虚拟资源转移请求；以及通过所述公众服务账号触发生成虚拟资源转移界面，以指示与所述第一客户端预设关联的第一虚拟资源账号转移虚拟资源至与所述公众服务账号预设关联的第二虚拟资源账号；
所述第一客户端根据在所述虚拟资源转移界面输入的转移确认信息，将所述第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移。
2. 如权利要求1所述的方法，其特征在于，所述第二客户端通过所述公众 服务账号获取所述业务请求后，基于所述公众服务账号输入针对所述业务请求的业务订单信息包括：
当所述业务请求包括多个业务信息时，所述第二客户端基于所述公众服务账号分别针对各个业务信息输入业务订单信息；
通过所述公众服务账号对输入的多个业务订单信息进行汇总，生成汇总后的业务订单信息。
3. 如权利要求1所述的方法，其特征在于，所述将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移之后，还包括：
所述公众服务账号获知所述第一客户端将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移后，向所述第一客户端和/或所述第二客户端发送虚拟资源转移完成信息。
4. 一种客户端设备，其特征在于，包括：
登录发送模块，用于登录公众服务账号，并基于所述公众服务账号发起业务请求；以使第二客户端通过登录所述公众服务账号获取所述业务请求后，基于所述公众服务账号输入针对所述业务请求的业务订单信息；与所述公众服务账号关联的应用服务器根据所述业务订单信息进行费用的计算，生成虚拟资源转移请求；或者所述应用服务器接收的所述业务订单信息中携带有上报的费用信息，根据所述费用信息直接生成虚拟资源转移请求，并通过所述公众服务账号向所述客户端设备发送所述虚拟资源转移请求；其中，所述公众服务账号为开发者或服务商在互联网应用中注册的服务帐号，开发者或服务商通过公众服务帐号为互联网应用中的一个或多个用户提供相应的服务；所述互联网应用对应有后台服务器；与所述公众服务账号关联的应用服务器为通过公众服务帐号为互联网应用中的用户提供服务的服务器；所述后台服务器用于处理互联网应用在实现相应功能过程中的各种需求，并用于对互联网应用中的用户的相关信息、公众服务帐号的相关信息及用户之间、用户与公众服务帐号之间的交互消息进行管理；其中，所述后台服务器与所述应用服务器为独立的两个服务器；
虚拟资源转移模块，用于接收到所述虚拟资源转移请求后，将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移；
所述虚拟资源转移模块包括：
转移请求接收单元，用于通过所述公众服务账号接收所述虚拟资源转移请求；
转移界面生成单元，用于通过所述公众服务账号触发生成虚拟资源转移界面，以指示与所述第一客户端预设关联的第一虚拟资源账号转移虚拟资源至与所述公众服务账号预设关联的第二虚拟资源账号；
转移单元，用于根据在所述虚拟资源转移界面输入的转移确认信息，将所述第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移。
5. 如权利要求4所述的客户端设备，其特征在于，还包括：
第一转移完成信息接收模块，用于在所述公众服务账号获知所述第一客户端根据所述虚拟资源转移请求完成了虚拟资源转移后，通过所述公众服务账号接收虚拟资源转移完成信息。
6. 一种客户端设备，其特征在于，包括：
业务请求接收模块，用于通过登录公众服务账号获取业务请求；所述业务请求为第一客户端登陆所述预设的公众服务账号，并基于所述公众服务账号发起的业务请求；其中，所述公众服务账号为开发者或服务商在互联网应用中注册的服务帐号，开发者或服务商通过公众服务帐号为互联网应用中的一个或多个用户提供相应的服务；所述互联网应用对应有后台服务器；
订单信息输入模块，用于基于所述公众服务账号输入针对所述业务请求的业务订单信息；以使与所述公众服务账号关联的应用服务器根据所述业务订单信息进行费用的计算，生成虚拟资源转移请求；或者所述应用服务器接收的所述业务订单信息中携带有上报的费用信息，根据所述费用信息直接生成虚拟资源转移请求，并通过所述公众服务账号向所述第一客户端发送所述虚拟资源转移请求，所述第一客户端接收到所述虚拟资源转移请求后，将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移；其中，与所述公众服务账号关联的应用服务器为通过公众服务帐号为互联网应用中的用户提供服务的服务器；所述后台服务器用于处理互联网应用在实现相应功能过程中的各种需求，并用于对互联网应用中的用户的相关信息、公众服务帐号的相关信息及用户之间、用 户与公众服务帐号之间的交互消息进行管理；其中，所述后台服务器与所述应用服务器为独立的两个服务器；
第二转移完成信息接收模块，用于在所述公众服务账号获知所述第一客户端通过所述公众服务账号接收所述虚拟资源转移请求；以及通过所述公众服务账号触发生成虚拟资源转移界面，以指示与所述第一客户端预设关联的第一虚拟资源账号转移虚拟资源至与所述公众服务账号预设关联的第二虚拟资源账号；所述第一客户端根据在所述虚拟资源转移界面输入的转移确认信息，将所述第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移后，通过所述公众服务账号接收虚拟资源转移完成信息。
7. 如权利要求6所述的客户端设备，其特征在于，所述订单信息输入模块包括：
输入单元，用于当所述业务请求接收模块接收到的业务请求包括多个业务信息时，基于所述公众服务账号分别针对各个业务信息输入业务订单信息；
汇总单元，用于通过所述公众服务账号对输入的多个业务订单信息进行汇总，生成汇总后的业务订单信息。
8. 一种应用服务器，其特征在于，所述应用服务器为通过公众服务帐号为互联网应用中的用户提供服务的服务器，包括：
转移请求生成模块，用于根据业务订单信息进行费用的计算，生成虚拟资源转移请求；或者所述应用服务器接收的所述业务订单信息中携带有上报的费用信息，根据所述费用信息直接生成虚拟资源转移请求；所述业务订单信息为第一客户端登陆公众服务账号，并基于所述公众服务账号发起业务请求，第二客户端通过登录所述公众服务账号获取所述业务请求后，基于所述公众服务账号输入针对所述业务请求的业务订单信息；其中，所述公众服务账号为开发者或服务商在互联网应用中注册的服务帐号，开发者或服务商通过公众服务帐号为互联网应用中的一个或多个用户提供相应的服务；所述互联网应用对应有后台服务器；所述后台服务器用于处理互联网应用在实现相应功能过程中的各种需求，并用于对互联网应用中的用户的相关信息、公众服务帐号的相关信息及用户之间、用户与公众服务帐号之间的交互消息进行管理；其中，所述后台服 务器与所述应用服务器为独立的两个服务器；
转移请求发送模块，用于通过所述公众服务账号向所述第一客户端发送所述虚拟资源转移请求；以使所述第一客户端通过所述公众服务账号接收所述虚拟资源转移请求；以及通过所述公众服务账号触发生成虚拟资源转移界面，以指示与所述第一客户端预设关联的第一虚拟资源账号转移虚拟资源至与所述公众服务账号预设关联的第二虚拟资源账号；以及使得所述第一客户端根据在所述虚拟资源转移界面输入的转移确认信息，将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移。
9. 一种虚拟资源转移系统，其特征在于，包括第一客户端、第二客户端和应用服务器，其中
第一客户端用于登陆公众服务账号，并基于所述公众服务账号发起业务请求；所述第二客户端用于通过登录所述公众服务账号获取所述业务请求后，基于所述公众服务账号输入针对所述业务请求的业务订单信息；其中，所述公众服务账号为开发者或服务商在互联网应用中注册的服务帐号，开发者或服务商通过公众服务帐号为互联网应用中的一个或多个用户提供相应的服务；所述互联网应用对应有后台服务器；与所述公众服务账号关联的所述应用服务器根据所述业务订单信息进行费用的计算，生成虚拟资源转移请求；或者所述应用服务器接收的所述业务订单信息中携带有上报的费用信息，根据所述费用信息直接生成虚拟资源转移请求，并通过所述公众服务账号向所述第一客户端发送所述虚拟资源转移请求；其中，与所述公众服务账号关联的应用服务器为通过公众服务帐号为互联网应用中的用户提供服务的服务器；所述后台服务器用于处理互联网应用在实现相应功能过程中的各种需求，并用于对互联网应用中的用户的相关信息、公众服务帐号的相关信息及用户之间、用户与公众服务帐号之间的交互消息进行管理；其中，所述后台服务器与所述应用服务器为独立的两个服务器；所述第一客户端还用于通过所述公众服务账号接收所述虚拟资源转移请求；以及通过所述公众服务账号触发生成虚拟资源转移界面，以指示与所述第一客户端预设关联的第一虚拟资源账号转移虚拟资源至与所述公众服务账号预设关联的第二虚拟资源账号；所述第一客户端根据在所述虚拟资源转移界面输入的转移确认信息，将所述第一虚拟资源账号中的虚拟资源向第二虚拟资 源账号转移。
10. 如权利要求9所述的系统，其特征在于，所述第一客户端为所述权利要求4-5任一项所述的客户端设备；所述第二客户端为所述权利要求6-7任一项所述的客户端设备；所述应用服务器为所述权利要求8所述的应用服务器。”
经形式审查合格，国家知识产权局于2018年07月19日依法受理了该复审请求，并将其转送至原审查部门进行前置审查。
原审查部门在前置审查意见书中认为复审请求人的意见陈述不具备说服力，因而坚持驳回决定。
随后，国家知识产权局成立合议组对本案进行审理。
合议组于2019 年06 月21 日向复审请求人发出复审通知书，指出：权利要求1-10相对于对比文件1结合本领域常用技术手段不具备专利法第22条第3款规定的创造性。
复审请求人于2019 年08 月06 日提交了意见陈述书，同时修改了权利要求书。复审请求人认为：（1）对比文件1是用户必须通过APP填写快递相关信息后进行支付确认，才能生成快递订单，快递员才能根据订单上门取件；而权利要求1公开的技术方案是第一客户端先发起一个业务请求，然后快递员看到该业务请求，并进行上门取件，在上门取件时快递员获知到业务订单的相关信息后，快递员输入生成业务订单信息，然后发送给服务器，服务器再生成虚拟资源转移请求，最后用户再确认支付；对比文件1并没有披露当业务请求包括多个业务信息时，如何处理的技术特征，各个业务订单分配信道资源；汇总后统一发送给应用服务器不但可以更加高效地完成信息的内部处理，并节省了网络资源，该得到的技术效果也是实实在在做出的技术上的贡献。
（2）本申请中处理方式不但可以减少终端、后台服务器、应用服务器相互之间通信时所需的通信资源，节省网络资源，还可以减少终端、后台服务器、应用服务器各自运行的运行资源，提升终端、后台服务器、应用服务器各自的运行效率。在本申请的申请日之前，并没有具体公开有本申请的终端、互联网应用的后台服务器以及公众服务账号的应用服务器组合的系统架构，该后台服务器与该应用服务器为独立的两个服务器。
复审请求人于2019年08月06日提交的新修改的权利要求书如下：
“1. 一种虚拟资源转移方法，其特征在于，包括：
第一客户端登陆公众服务账号，并基于所述公众服务账号发起业务请求；
第二客户端通过登录所述公众服务账号获取所述业务请求后，基于所述公众服务账号输入针对所述业务请求的业务订单信息；当所述业务请求包括多个业务信息时，所述第二客户端基于所述公众服务账号分别针对各个业务信息输入业务订单信息；通过所述公众服务账号对输入的多个业务订单信息进行汇总，生成汇总后的业务订单信息；其中，所述公众服务账号为开发者或服务商在互联网应用中注册的服务帐号，开发者或服务商通过公众服务帐号为互联网应用中的一个或多个用户提供相应的服务；所述互联网应用对应有后台服务器；
与所述公众服务账号关联的应用服务器根据所述业务订单信息进行费用的计算，生成虚拟资源转移请求；或者所述应用服务器接收的所述业务订单信息中携带有上报的费用信息，根据所述费用信息直接生成虚拟资源转移请求，并通过所述公众服务账号向所述第一客户端发送所述虚拟资源转移请求；其中，与所述公众服务账号关联的应用服务器为通过公众服务帐号为互联网应用中的用户提供服务的服务器；所述后台服务器用于处理互联网应用在实现相应功能过程中的各种需求，并用于对互联网应用中的用户的相关信息、公众服务帐号的相关信息及用户之间、用户与公众服务帐号之间的交互消息进行管理；其中，所述后台服务器与所述应用服务器为独立的两个服务器；
所述第一客户端接收到所述虚拟资源转移请求后，将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移；
所述第一客户端接收到所述虚拟资源转移请求后，将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移包括：
所述第一客户端通过所述公众服务账号接收所述虚拟资源转移请求；以及通过所述公众服务账号触发生成虚拟资源转移界面，以指示与所述第一客户端预设关联的第一虚拟资源账号转移虚拟资源至与所述公众服务账号预设关联的第二虚拟资源账号；
所述第一客户端根据在所述虚拟资源转移界面输入的转移确认信息，将所述第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移。
2. 如权利要求1所述的方法，其特征在于，所述将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移之后，还包括：
所述公众服务账号获知所述第一客户端将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移后，向所述第一客户端和/或所述第二客户端发送虚拟资源转移完成信息。
3. 一种客户端设备，其特征在于，包括：
登录发送模块，用于登录公众服务账号，并基于所述公众服务账号发起业务请求；以使第二客户端通过登录所述公众服务账号获取所述业务请求后，基于所述公众服务账号输入针对所述业务请求的业务订单信息；当所述业务请求包括多个业务信息时，所述第二客户端基于所述公众服务账号分别针对各个业务信息输入业务订单信息；通过所述公众服务账号对输入的多个业务订单信息进行汇总，生成汇总后的业务订单信息；与所述公众服务账号关联的应用服务器根据所述业务订单信息进行费用的计算，生成虚拟资源转移请求；或者所述应用服务器接收的所述业务订单信息中携带有上报的费用信息，根据所述费用信息直接生成虚拟资源转移请求，并通过所述公众服务账号向所述客户端设备发送所述虚拟资源转移请求；其中，所述公众服务账号为开发者或服务商在互联网应用中注册的服务帐号，开发者或服务商通过公众服务帐号为互联网应用中的一个或多个用户提供相应的服务；所述互联网应用对应有后台服务器；与所述公众服务账号关联的应用服务器为通过公众服务帐号为互联网应用中的用户提供服务的服务器；所述后台服务器用于处理互联网应用在实现相应功能过程中的各种需求，并用于对互联网应用中的用户的相关信息、公众服务帐号的相关信息及用户之间、用户与公众服务帐号之间的交互消息进行管理；其中，所述后台服务器与所述应用服务器为独立的两个服务器；
虚拟资源转移模块，用于接收到所述虚拟资源转移请求后，将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移；
所述虚拟资源转移模块包括：
转移请求接收单元，用于通过所述公众服务账号接收所述虚拟资源转移请求；
转移界面生成单元，用于通过所述公众服务账号触发生成虚拟资源转移界面，以指示与所述第一客户端预设关联的第一虚拟资源账号转移虚拟资源至与所述公众服务账号预设关联的第二虚拟资源账号；
转移单元，用于根据在所述虚拟资源转移界面输入的转移确认信息，将所述第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移。
4. 如权利要求3所述的客户端设备，其特征在于，还包括：
第一转移完成信息接收模块，用于在所述公众服务账号获知所述第一客户端根据所述虚拟资源转移请求完成了虚拟资源转移后，通过所述公众服务账号接收虚拟资源转移完成信息。
5. 一种客户端设备，其特征在于，包括：
业务请求接收模块，用于通过登录公众服务账号获取业务请求；所述业务请求为第一客户端登陆所述预设的公众服务账号，并基于所述公众服务账号发起的业务请求；其中，所述公众服务账号为开发者或服务商在互联网应用中注册的服务帐号，开发者或服务商通过公众服务帐号为互联网应用中的一个或多个用户提供相应的服务；所述互联网应用对应有后台服务器；
订单信息输入模块，用于基于所述公众服务账号输入针对所述业务请求的业务订单信息；以使与所述公众服务账号关联的应用服务器根据所述业务订单信息进行费用的计算，生成虚拟资源转移请求；或者所述应用服务器接收的所述业务订单信息中携带有上报的费用信息，根据所述费用信息直接生成虚拟资源转移请求，并通过所述公众服务账号向所述第一客户端发送所述虚拟资源转移请求，所述第一客户端接收到所述虚拟资源转移请求后，将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移；其中，与所述公众服务账号关联的应用服务器为通过公众服务帐号为互联网应用中的用户提供服务的服务器；所述后台服务器用于处理互联网应用在实现相应功能过程中的各种需求，并用于对互联网应用中的用户的相关信息、公众服务帐号的相关信息及用户之间、用户与公众服务帐号之间的交互消息进行管理；其中，所述后台服务器与所述应用服务器为独立的两个服务器；
第二转移完成信息接收模块，用于在所述公众服务账号获知所述第一客户 端通过所述公众服务账号接收所述虚拟资源转移请求；以及通过所述公众服务账号触发生成虚拟资源转移界面，以指示与所述第一客户端预设关联的第一虚拟资源账号转移虚拟资源至与所述公众服务账号预设关联的第二虚拟资源账号；所述第一客户端根据在所述虚拟资源转移界面输入的转移确认信息，将所述第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移后，通过所述公众服务账号接收虚拟资源转移完成信息；
所述订单信息输入模块包括：
输入单元，用于当所述业务请求接收模块接收到的业务请求包括多个业务信息时，基于所述公众服务账号分别针对各个业务信息输入业务订单信息；
汇总单元，用于通过所述公众服务账号对输入的多个业务订单信息进行汇总，生成汇总后的业务订单信息。
6. 一种应用服务器，其特征在于，所述应用服务器为通过公众服务帐号为互联网应用中的用户提供服务的服务器，包括：
转移请求生成模块，用于根据业务订单信息进行费用的计算，生成虚拟资源转移请求；或者所述应用服务器接收的所述业务订单信息中携带有上报的费用信息，根据所述费用信息直接生成虚拟资源转移请求；所述业务订单信息为第一客户端登陆公众服务账号，并基于所述公众服务账号发起业务请求，第二客户端通过登录所述公众服务账号获取所述业务请求后，基于所述公众服务账号输入针对所述业务请求的业务订单信息；当所述业务请求接收模块接收到的业务请求包括多个业务信息时，基于所述公众服务账号分别针对各个业务信息输入业务订单信息；通过所述公众服务账号对输入的多个业务订单信息进行汇总，生成汇总后的业务订单信息；其中，所述公众服务账号为开发者或服务商在互联网应用中注册的服务帐号，开发者或服务商通过公众服务帐号为互联网应用中的一个或多个用户提供相应的服务；所述互联网应用对应有后台服务器；所述后台服务器用于处理互联网应用在实现相应功能过程中的各种需求，并用于对互联网应用中的用户的相关信息、公众服务帐号的相关信息及用户之间、用户与公众服务帐号之间的交互消息进行管理；其中，所述后台服务器与所述应用服务器为独立的两个服务器；
转移请求发送模块，用于通过所述公众服务账号向所述第一客户端发送所 述虚拟资源转移请求；以使所述第一客户端接收到所述虚拟资源转移请求后，通过所述公众服务账号接收所述虚拟资源转移请求；以及通过所述公众服务账号触发生成虚拟资源转移界面，以指示与所述第一客户端预设关联的第一虚拟资源账号转移虚拟资源至与所述公众服务账号预设关联的第二虚拟资源账号；所述第一客户端根据在所述虚拟资源转移界面输入的转移确认信息，将第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移。
7. 一种虚拟资源转移系统，其特征在于，包括第一客户端、第二客户端和应用服务器，其中
第一客户端登陆公众服务账号，并基于所述公众服务账号发起业务请求；所述第二客户端通过登录所述公众服务账号获取所述业务请求后，基于所述公众服务账号输入针对所述业务请求的业务订单信息；当所述业务请求接收模块接收到的业务请求包括多个业务信息时，基于所述公众服务账号分别针对各个业务信息输入业务订单信息；通过所述公众服务账号对输入的多个业务订单信息进行汇总，生成汇总后的业务订单信息；其中，所述公众服务账号为开发者或服务商在互联网应用中注册的服务帐号，开发者或服务商通过公众服务帐号为互联网应用中的一个或多个用户提供相应的服务；所述互联网应用对应有后台服务器；与所述公众服务账号关联的所述应用服务器根据所述业务订单信息进行费用的计算，生成虚拟资源转移请求；或者所述应用服务器接收的所述业务订单信息中携带有上报的费用信息，根据所述费用信息直接生成虚拟资源转移请求，并通过所述公众服务账号向所述第一客户端发送所述虚拟资源转移请求；其中，与所述公众服务账号关联的应用服务器为通过公众服务帐号为互联网应用中的用户提供服务的服务器；所述后台服务器用于处理互联网应用在实现相应功能过程中的各种需求，并用于对互联网应用中的用户的相关信息、公众服务帐号的相关信息及用户之间、用户与公众服务帐号之间的交互消息进行管理；其中，所述后台服务器与所述应用服务器为独立的两个服务器；所述第一客户端接收到所述虚拟资源转移请求后，通过所述公众服务账号接收所述虚拟资源转移请求；以及通过所述公众服务账号触发生成虚拟资源转移界面，以指示与所述第一客户端预设关联的第一虚拟资源账号转移虚拟资源至与所述公众服务账号预设关联的第二虚拟资源账号；所述第一客户端根据在所述虚拟资 源转移界面输入的转移确认信息，将所述第一虚拟资源账号中的虚拟资源向第二虚拟资源账号转移。
8. 如权利要求7所述的系统，其特征在于，所述第一客户端为所述权利要求3-4任一项所述的客户端设备；所述第二客户端为所述权利要求5所述的客户端设备；所述应用服务器为所述权利要求6所述的应用服务器。”
在上述程序的基础上，合议组认为本案事实已经清楚，可以作出审查决定。
二、决定的理由
审查文本的认定
复审请求人在复审阶段提交了申请文件的修改文本，因此，本复审决定针对的文本为：复审请求人于申
请日2015年07月31日提交的说明书第0001-0129段、说明书附图、说明书摘要以及摘要附图，于2019年08月06日提交的权利要求第1-8项。
2、专利法第22条第3款
专利法第22条第3款规定：创造性，是指与现有技术相比，该发明具有突出的实质性特点和显著的进步，该实用新型具有实质性特点和进步。
本复审决定使用的对比文件与复审通知书以及驳回决定使用的对比文件相同，即：
对比文件1：CN104732373 A，公开日期为2015年06月24日。
2.1、权利要求1请求保护一种虚拟资源转移方法，对比文件1公开了一种便捷的快递收件服务方法，能够实现费用的支付操作，并具体公开了以下内容（参见说明书第0017-0023段，附图1-3）：步骤S1：用户或快递员通过手机或移动终端（相当于第一客户端和第二客户端）下载安装APP，并通过APP在快递收件服务平台（相当于后台服务器）上注册用户或快递员信息；步骤S2：用户通过手机上的APP填写快递相关信息，手机上的APP根据该快递相关信息计算快递费用，并询问用户是否确认支付，若确认支付，则形成快递订单，并通过APP发送快递订单至快递收件服务平台；否则，不形成快递订单；所述快递相关信息包括快递物件类型、体积及重量的信息；步骤S3：快递收件服务平台定位需快递服务的用户的地理位置，并将快递订单信息发送至该用户附近的各快递员的移动终端上；步骤S4：快递员通过移动终端采用抢单的方式，获取该快递订单，并反馈至快递收件服务平台，同时，通知其他快递员该快递订单已预订；步骤S5：快递收件服务平台根据反馈信息，定位快递员的地理位置，并根据快递员接单情况规划快递员收件路线，同时计算快递员至各用户处的上门收件时间；步骤S6：快递收件服务平台发送快递员相关信息至用户的手机，该快递员相关信息包括快递员姓名、手机号、上门收件时间的信息；步骤S7：用户通过手机上的APP查询快递员当前位置，当快递员距离用户100米时，快递收件服务平台发送信息告知用户，提醒用户即将收件；步骤S8：快递员上门收件，确认快递物件信息，若确认无误，则接收快递物件，并反馈至快递收件服务平台，同时，通过外接打印机打印快递面单；若有误，则通过移动终端发送不接收快递物件原因至快递收件服务平台。
由此可见，权利要求1与对比文件1的区别特征为：（1）对比文件1中是通过APP以及服务平台完成业务，而权利要求1是通过公众服务账号、后台服务器以及应用服务器完成业务；（2）对比文件1是由用户填写快递相关信息，在APP处完成费用计算后进行转账，而权利要求1是由第二客户端输入针对所述业务请求的业务订单信息，由应用服务器发送虚拟资源转移请求给第一客户端并完成虚拟资源转移操作，并且在业务请求包括多个业务信息时公众服务号对多个订单信息进行汇总，生成汇总后的业务订单信息。基于上述区别特征，权利要求1实际解决的问题是：以何种架构来设计虚拟资源转移系统以及虚拟资源转移系统的各个组成部分如何相互配合完成订单的生成以及虚拟资源的转移。
对于区别特征（1），在虚拟资源的转移领域，公众服务账号和APP均属于常见的客户端，采用独立的APP客户端登陆平台为互联网应用的用户提供相应服务，或是通过公众服务帐号为互联网应用的用户提供相应服务，均属于本领域的常用技术手段，是本领域技术人员可以根据具体情况进行选择的；另外，在对比文件1已经公开了app客户端和服务器架构以及相关功能模块的情况下，本领域技术人员也可以按需对整个系统的功能进行合理的划分，合理的将功能模块设置在客户端或者一个服务器以及多个服务器上，这都属于本领域的常用技术手段。
对于区别特征（2），虚拟资源转移系统的各个部件配合完成订单的生成和合并以及在账户之间转移资源的具体过程实质上是通过现有技术中的终端和服务器实现人为设定的订单和资金处理的商业规则，并未对现有技术作出技术上的贡献。
因此，在对比文件1的基础上结合上述本领域常用技术手段以获得权利要求1的技术方案，对本领域技术人员来说是显而易见的，因此，权利要求1所请求保护的技术方案不具备突出的实质性特点和显著的进步，因而不具备专利法第22条第3款规定的创造性。
2.2、权利要求2进一步限定了发送虚拟资源转移完成信息的操作，然而均是通过现有技术中的终端或服务器实现人为设定的商业规则，并未给权利要求带来技术上的贡献，因此在其引用的权利要求不具备创造性的情况下，权利要求2也不具备专利法第22条第3款规定的创造性。
2.3、权利要求3请求保护一种客户端设备，对比文件1公开了一种便捷的快递收件服务方法及系统，并具体公开了以下内容（参见说明书第0017-0023段，附图1-3）：如图1-3所示，用户通过手机下载安装本发明的用户APP（相当于第一客户端），并通过该APP注册用户信息，主要包括用户手机号码、登陆密码等信息，然后，登陆APP系统（相当于登录发送模块）与快递收件服务平台通信，查询周围的快递员的大致位置，通过APP填写快递相关信息(快递物件大小、体积、重量、类型等信息以及具体的发件方、收件方信息)，计算快递费用，待用户支付后（相当于虚拟资源转移模块），APP将快递订单信息发送至快递收件服务平台（相当于后台服务器）的云管理系统；快递员的移动终端(快递员需在移动终端上安装快递员APP，并注册快递员信息)（相当于第二客户端）接收发送来的快递订单信息，进行抢单后，APP将信息反馈至云管理系统，并由云管理系统告知用户已由某某快递员接单。
由此可见，权利要求3与对比文件1的区别特征为：（1）对比文件1中是通过APP以及服务平台完成业务，而权利要求3的客户端设备通过公众服务账号、后台服务器以及应用服务器完成业务；（2）对比文件1是由用户填写快递相关信息，在APP处完成费用计算后进行转账，而权利要求3是由第二客户端输入针对所述业务请求的业务订单信息，由应用服务器发送虚拟资源转移请求给第一客户端并完成虚拟资源转移操作，并且在业务请求包括多个业务信息时公众服务号对多个订单信息进行汇总，生成汇总后的业务订单信息。基于上述区别特征，权利要求3实际解决的问题是：以何种架构来设计虚拟资源转移系统以及虚拟资源转移系统的各个组成部分如何相互配合完成订单的生成以及虚拟资源的转移。
对于区别特征（1），在虚拟资源的转移技术领域，公众服务账号和APP均属于常见的客户端，采用独立的APP客户端登陆平台为互联网应用的用户提供相应服务，或是通过公众服务帐号为互联网应用的用户提供相应服务，均属于本领域的常用技术手段，是本领域技术人员可以根据具体情况进行选择的；另外，在对比文件1已经公开了app客户端和服务器架构以及相关功能模块的情况下，本领域技术人员也可以按需对整个系统的功能进行合理的划分，合理的将功能模块设置在客户端或者一个服务器以及多个服务器上，这都属于本领域的常用技术手段。
对于区别特征（2），虚拟资源转移系统的各个部件配合完成订单的生成和合并以及在账户之间转移资源的具体过程实质上是通过现有技术中的终端和服务器实现人为设定的订单和资金处理的商业规则，并未对现有技术作出技术上的贡献。
因此，在对比文件1的基础上结合上述本领域常用技术手段以获得权利要求3的技术方案，对本领域技术人员来说是显而易见的，因此，权利要求3所请求保护的技术方案不具备突出的实质性特点和显著的进步，因而不具备专利法第22条第3款规定的创造性。
2.4、权利要求4进一步限定了发送虚拟资源转移完成信息的操作，然而均是通过现有技术中的终端和服务器实现人为设定的商业规则，并未给权利要求带来技术上的贡献，因此在其引用的权利要求不具备创造性的情况下，权利要求4也不具备专利法第22条第3款规定的创造性。
2.5、权利要求5请求保护一种客户端设备，对比文件1公开了一种便捷的快递收件服务方法及系统，并具体公开了以下内容（参见说明书第0017-0023段，附图1-3）：如图1-3所示，用户通过手机下载安装本发明的用户APP（相当于第一客户端），并通过该APP注册用户信息，主要包括用户手机号码、登陆密码等信息，然后，登陆APP系统与快递收件服务平台通信，查询周围的快递员的大致位置，通过APP填写快递相关信息(快递物件大小、体积、重量、类型等信息以及具体的发件方、收件方信息)（相当于订单信息输人模块），计算快递费用，待用户支付后，APP将快递订单信息发送至快递收件服务平台（相当于后台服务器）的云管理系统；快递员的移动终端(快递员需在移动终端上安装快递员APP，并注册快递员信息)（相当于第二客户端）接收发送来的快递订单信息（相当于业务请求接收模块），进行抢单后，APP将信息反馈至云管理系统，并由云管理系统告知用户已由某某快递员接单。
由此可见，权利要求5与对比文件1的区别特征为：（1）对比文件1中是通过APP以及服务平台完成业务，而权利要求5的客户端设备通过公众服务账号、后台服务器以及应用服务器完成业务；（2）对比文件1是由用户填写快递相关信息，在APP处完成费用计算后进行转账，而权利要求5是由第二客户端输入针对所述业务请求的业务订单信息，由应用服务器发送虚拟资源转移请求给第一客户端并完成虚拟资源转移操作，并且在业务请求包括多个业务信息时公众服务号对多个订单信息进行汇总，生成汇总后的业务订单信息。基于上述区别特征，权利要求5实际解决的问题是：以何种架构来设计虚拟资源转移系统以及虚拟资源转移系统的各个组成部分如何相互配合完成订单的生成以及虚拟资源的转移。
对于区别特征（1），在虚拟资源的转移技术领域，公众服务账号和APP均属于常见的客户端，采用独立的APP客户端登陆平台为互联网应用的用户提供相应服务，或是通过公众服务帐号为互联网应用的用户提供相应服务，均属于本领域的常用技术手段，是本领域技术人员可以根据具体情况进行选择的；另外，在对比文件1已经公开了app客户端和服务器架构以及相关功能模块的情况下，本领域技术人员也可以按需对整个系统的功能进行合理的划分，合理的将功能模块设置在客户端或者一个服务器以及多个服务器上，这都属于本领域的常用技术手段。
对于区别特征（2），虚拟资源转移系统的各个部件配合完成订单的生成和合并以及在账户之间转移资源的具体过程实质上是通过现有技术中的终端和服务器实现人为设定的订单和资金处理的商业规则，并未对现有技术作出技术上的贡献。
因此，在对比文件1的基础上结合上述本领域常用技术手段以获得权利要求5的技术方案，对本领域技术人员来说是显而易见的，因此，权利要求5所请求保护的技术方案不具备突出的实质性特点和显著的进步，因而不具备专利法第22条第3款规定的创造性。
2.6、权利要求6请求保护一种应用服务器，对比文件1公开了一种便捷的快递收件服务方法及系统，并具体公开了以下内容（参见说明书第0017-0023段，附图1-3）：如图1-3所示，用户通过手机下载安装本发明的用户APP（相当于第一客户端），并通过该APP注册用户信息，主要包括用户手机号码、登陆密码等信息，然后，登陆APP系统与快递收件服务平台通信，查询周围的快递员的大致位置，通过APP填写快递相关信息(快递物件大小、体积、重量、类型等信息以及具体的发件方、收件方信息)，计算快递费用，待用户支付后，APP将快递订单信息发送至快递收件服务平台（相当于后台服务器）的云管理系统；快递员的移动终端(快递员需在移动终端上安装快递员APP，并注册快递员信息)（相当于第二客户端）接收发送来的快递订单信息，进行抢单后，APP将信息反馈至云管理系统，并由云管理系统告知用户已由某某快递员接单。
由此可见，权利要求6与对比文件1的区别特征为：（1）对比文件1中是通过APP以及服务平台完成业务，而权利要求6的应用服务器通过和公众服务账号、后台服务器配合完成业务；（2）对比文件1是由用户填写快递相关信息，在APP处完成费用计算后进行转账，而权利要求6是由第二客户端输入针对所述业务请求的业务订单信息，由应用服务器发送虚拟资源转移请求给第一客户端并完成虚拟资源转移操作，并且在业务请求包括多个业务信息时公众服务号对多个订单信息进行汇总，生成汇总后的业务订单信息。基于上述区别特征，权利要求6实际解决的问题是：以何种架构来设计虚拟资源转移系统以及虚拟资源转移系统的各个组成部分如何相互配合完成订单的生成以及虚拟资源的转移。
对于区别特征（1），在虚拟资源的转移技术领域，公众服务账号和APP均属于常见的客户端，采用独立的APP客户端登陆平台为互联网应用的用户提供相应服务，或是通过公众服务帐号为互联网应用的用户提供相应服务，均属于本领域的常用技术手段，是本领域技术人员可以根据具体情况进行选择的；另外，在对比文件1已经公开了app客户端和服务器架构的情况下，本领域技术人员也可以按需对整个系统的功能进行合理的划分，合理的将功能模块设置在客户端或者一个服务器以及多个服务器上，这都属于本领域的常用技术手段。
对于区别特征（2），虚拟资源转移系统的各个部件配合完成订单的生成和合并以及在账户之间转移资源的具体过程实质上是通过现有技术中的终端和服务器实现人为设定的订单和资金处理的商业规则，并未对现有技术作出技术上的贡献。
因此，在对比文件1的基础上结合上述本领域常用技术手段以获得权利要求6的技术方案，对本领域技术人员来说是显而易见的，因此，权利要求6所请求保护的技术方案不具备突出的实质性特点和显著的进步，因而不具备专利法第22条第3款规定的创造性。
2.7、权利要求7请求保护一种虚拟资源转移系统，其是与权利要求1相应的装置权利要求，因此基于评述权利要求1不具备创造性的理由，权利要求7也不具备专利法第22条第3款规定的创造性。
2.8、权利要求8引用了权利要求7，其附加特征限定第一客户端为权利要求3-4任一项所述的客户端设备，第二客户端为权利要求5所述的客户端设备，应用服务器为权利要求6所述的应用服务器，基于上述对权利要求7、权利要求3-6的审查意见可知，权利要求8也不具备专利法第22条第3款规定的创造性。
3、对复审请求人相关意见的评述
针对上述复审请求人于2019年08月06日提交的意见陈述，合议组认为：
(1)由用户填写订单信息还是由快递员填写订单信息以及对多个订单进行合并处理都是具体商业规则的实施，本申请中只是将这些商业规则运行在通用的计算机之上，并不具有技术贡献。
(2) 在虚拟资源的转移领域，公众服务账号和APP均属于常见的客户端，采用独立的APP客户端登陆平台为互联网应用的用户提供相应服务，或是通过公众服务帐号为互联网应用的用户提供相应服务，均属于本领域的技术人员的常规选择，公众服务账号虽然不是独立的APP但是其处理方式与APP并无本质的区别，可以设置公众服务账号对应的服务器来对相关的数据进行处理，这是本领域技术人员可以根据具体情况进行选择的；另外，在对比文件1已经公开了app客户端和服务器架构的情况下，为了提高数据的处理和交互效率本领域技术人也可以按需对整个系统的功能进行合理的划分，合理的将功能模块设置在客户端端或者一个服务器以及多个服务器上，这都属于本领域的常用技术手段。
综上所述，复审请求人的理由不成立。
三、决定
维持国家知识产权局于2018 年03 月27 日对本申请作出的驳回决定。
如对本复审决定不服，根据专利法第41条第2款的规定，复审请求人可以自收到本复审决定之日起三个月内向北京知识产权法院起诉。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
