发明创造名称：一种灰度发布方法及系统
外观设计名称：
决定号：201108
决定日：2020-01-16
委内编号：1F283530
优先权日：
申请（专利）号：201810263812.3
申请日：2018-03-27
复审请求人：无锡华云数据技术服务有限公司
无效请求人：
授权公告日：
审定公告日：
专利权人：
主审员：吕淼
合议组组长：冉建国
参审员：安晓兰
国际分类号：H04L12/24(2006.01),H04L29/08(2006.01),H04L29/06(2006.01),G06F8/60(2018.01),G06F8/65(2018.01)
外观设计分类号：
法律依据：专利法第22条第3款
决定要点
：如果权利要求的技术方案与作为最接近现有技术的对比文件相比存在区别特征，而该区别特征是本领域的公知常识，则该权利要求的技术方案相对于所述对比文件以及本领域的公知常识的结合是显而易见的，该权利要求的技术方案不具备创造性。
全文：
本复审请求涉及申请号为201810263812.3，名称为“一种灰度发布方法及系统”的发明专利申请（下称本申请）。申请人为无锡华云数据技术服务有限公司。本申请的申请日为2018年03月27日，公开日为2018年09月25日。
经实质审查，国家知识产权局实质审查部门于2019年02月12日发出驳回决定，驳回了本申请，其理由是权利要求1-10不具备专利法第22条第3款规定的创造性。驳回决定中引用了对比文件1：CN107248986A，公开日：2017年10月13日。驳回决定的具体理由是：权利要求1-10相对于对比文件1和本领域惯用手段的结合不具备专利法第22条第3款规定的创造性。驳回决定所依据的文本为：2018年03月27日提交的原始申请文件。驳回决定所针对的权利要求书的内容如下：
“1. 一种灰度发布方法，其特征在于，所述方法包括：
注册中心接收用户控制台发送的服务请求，所述服务请求包括用户的用户标识以及所述用户所请求的微服务的标识；
所述注册中心根据所述微服务的标识判断所述微服务是否以灰度方式发布；
若是，则所述注册中心根据所述用户标识判断所述用户是否为测试用户；
若是，则所述注册中心将所述微服务的Beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述Beta版本。
2. 根据权利要求1所述的方法，其特征在于，在所述注册中心根据所述用户标识判断所述用户是否为测试用户之后，还包括：
若所述用户不是测试用户，则所述注册中心向所述用户控制台返回所述微服务的正式在线版本的服务地址。
3. 根据权利要求1所述的方法，其特征在于，在所述注册中心将所述微服务的Beta版本的服务地址返回给所述用户控制台之后，还包括：
若所述Beta版本通过测试，则所述注册中心下线原正式在线版本，并将所述Beta版本升级为新的正式在线版本。
4. 根据权利要求1所述的方法，其特征在于，在所述注册中心将所述微服务的Beta版本的服务地址返回给所述用户控制台之后，还包括：
若所述Beta版本没有通过测试，则所述注册中心下线所述Beta版本。
5. 根据权利要求2至3任一项所述的方法，其特征在于，在所述注册中心确定所述用户为测试用户之后，以及，在所述注册中心将所述Beta版本的服务地址返回给所述用户控制台之前，还包括：
所述注册中心确定所述Beta版本的版本号高于所述正式在线版本的版本号。
6. 根据权利要求1至4任一项所述的方法，其特征在于，所述注册中心根据所述用户标识判断所述用户是否为测试用户，包括：
所述注册中心判断所述用户标识是否添加表示所述用户为测试用户的标签，所述标签由所述用户控制台在确定所述用户为测试用户后添加；
若所述用户标识添加有所述标签，则所述注册中心确定所述用户为测试用户。
7. 一种灰度发布系统，其特征在于，包括：注册中心和用户控制台，其中，
所述用户控制台用于：向所述注册中心发送服务请求，所述服务请求包括用户的用户标识以及所述用户所请求的微服务的标识；
所述注册中心，用于：接收所述服务请求；根据所述微服务的标识判断所述微服务是否以灰度方式发布；在所述微服务以灰度方式发布时，则根据所述用户标识判断所述用户是否为测试用户；以及在所述用户为测试用户时，将所述微服务的Beta版本的服务地址返回给所述用户控制台；
所述用户控制台还用于：根据所述服务地址调用所述Beta版本。
8. 根据权利要求7所述的系统，其特征在于，所述注册中心还用于：在根据所述用户标识判断所述用户是否为测试用户之后，若判断出所述用户不是测试用户，则向所述用户控制台返回所述微服务的正式在线版本的服务地址。
9. 根据权利要求7所述的系统，其特征在于，在所述注册中心还用于：将所述微服务的Beta版本的服务地址返回给所述用户控制台之后，若所述Beta版本通过测试，则下线原正式在线版本，并将所述Beta版本升级为新的正式在线版本；以及，若所述Beta版本没有通过测试，则下线所述Beta 版本。
10. 根据权利要求7至9任一项所述的系统，其特征在于，所述用户控制台还用于为测试用户的用户标识添加表示所述用户为测试用户的标签；
所述注册中心用于：根据所述用户标识判断所述用户是否为测试用户，包括：
判断所述用户标识是否添加所述标签；若所述用户标识添加有所述标签，则所述注册中心确定所述用户为测试用户。”
申请人（下称复审请求人）对上述驳回决定不服，于2019年05月21日向国家知识产权局提出了复审请求，同时提交了权利要求书的全文修改替换页，具体修改为：将从属权利要求6的附加特征和说明书中的部分内容加入到独立权利要求1中，将从属权利要求10的附加特征和说明书中的部分内容加入到独立权利要求7中，删除了从属权利要求6和10，并对权利要求的编号和引用关系进行了适应性修改。
复审请求人认为：1）对比文件1中托管服务器既要接收用户的登录请求，根据用户密码对用户账号进行认证，还要确定是否设置用户为灰度用户，对灰度用户的用户信息中添加灰度标识，这样必然导致托管服务器的资源开销较高，而本申请由用户控制台在确定用户为测试用户后添加标签，由注册中心根据用户标识是否添加了标签来判断用户是否为测试用户，提高了识别用户类型的效率，无需额外耗费注册中心的处理资源去执行添加灰度标识的繁琐操作，降低了注册中心的资源开销；2）对比文件1是基于灰度发布规则来选取部分用户使用不同的版本，而本申请是固定的让普通用户使用旧版本，让非普通用户使用Beta版本，因此，对比文件1未公开本申请权利要求1的技术特征“所述注册中心根据所述用户标识判断所述用户是否为测试用户，包括：所述注册中心判断所述用户标识是否添加表示所述用户为测试用户的标签，所述标签由所述用户控制台在确定所述用户为测试用户后添加，若所述用户标识添加有所述标签，则所述注册中心确定所述用户为测试用户，所述测试用户包括开发人员、测试人员或管理员”；3）对比文件1未公开本申请权利要求1中的技术特征“所述注册中心根据所述微服务的标识判断所述微服务是否以灰度方式发布”以及“所述注册中心将所述微服务的Beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述Beta版本”。
复审请求人在提出复审请求时提交的权利要求书的内容如下：
“1. 一种灰度发布方法，其特征在于，所述方法包括：
注册中心接收用户控制台发送的服务请求，所述服务请求包括用户的用户标识以及所述用户所请求的微服务的标识；
所述注册中心根据所述微服务的标识判断所述微服务是否以灰度方式发布；
若是，则所述注册中心根据所述用户标识判断所述用户是否为测试用户，其中，所述注册中心根据所述用户标识判断所述用户是否为测试用户，包括：
所述注册中心判断所述用户标识是否添加表示所述用户为测试用户的标签，所述标签由所述用户控制台在确定所述用户为测试用户后添加；
若所述用户标识添加有所述标签，则所述注册中心确定所述用户为测试用户，所述测试用户包括开发人员、测试人员或管理员；
若是，则所述注册中心将所述微服务的Beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述Beta版本。
2. 根据权利要求1所述的方法，其特征在于，在所述注册中心根据所述用户标识判断所述用户是否为测试用户之后，还包括：
若所述用户不是测试用户，则所述注册中心向所述用户控制台返回所述微服务的正式在线版本的服务地址。
3. 根据权利要求1所述的方法，其特征在于，在所述注册中心将所述微服务的Beta版本的服务地址返回给所述用户控制台之后，还包括：
若所述Beta版本通过测试，则所述注册中心下线原正式在线版本，并将所述Beta版本升级为新的正式在线版本。
4. 根据权利要求1所述的方法，其特征在于，在所述注册中心将所述微服务的Beta版本的服务地址返回给所述用户控制台之后，还包括：
若所述Beta版本没有通过测试，则所述注册中心下线所述Beta版本。
5. 根据权利要求2至3任一项所述的方法，其特征在于，在所述注册中心确定所述用户为测试用户之后，以及，在所述注册中心将所述Beta版本的服务地址返回给所述用户控制台之前，还包括：
所述注册中心确定所述Beta版本的版本号高于所述正式在线版本的版本号。
6. 一种灰度发布系统，其特征在于，包括：注册中心和用户控制台，其中，
所述用户控制台用于：向所述注册中心发送服务请求，所述服务请求包括用户的用户标识以及所述用户所请求的微服务的标识；
所述注册中心，用于：接收所述服务请求；根据所述微服务的标识判断所述微服务是否以灰度方式发布；在所述微服务以灰度方式发布时，则根据所述用户标识判断所述用户是否为测试用户；以及在所述用户为测试用户时，将所述微服务的Beta版本的服务地址返回给所述用户控制台，其中，所述注册中心还用于判断所述用户标识是否添加表示所述用户为测试用户的标签，所述标签由所述用户控制台在确定所述用户为测试用户后添加；若所述用户标识添加有所述标签，则所述注册中心确定所述用户为测试用户，所述测试用户包括开发人员、测试人员或管理员；
所述用户控制台还用于：根据所述服务地址调用所述Beta版本。
7. 根据权利要求6所述的系统，其特征在于，所述注册中心还用于：在根据所述用户标识判断所述用户是否为测试用户之后，若判断出所述用户不是测试用户，则向所述用户控制台返回所述微服务的正式在线版本的服务地址。
8. 根据权利要求6所述的系统，其特征在于，在所述注册中心还用于：将所述微服务的Beta版本的服务地址返回给所述用户控制台之后，若所述 Beta版本通过测试，则下线原正式在线版本，并将所述Beta版本升级为新的正式在线版本；以及，若所述Beta版本没有通过测试，则下线所述Beta版本。”
经形式审查合格，国家知识产权局于2019年05月27日依法受理了该复审请求，并将其转送至实质审查部门进行前置审查。
实质审查部门在前置审查意见书中认为：1）对比文件1中的正式用户使用新版本服务实质上就是本申请中测试用户使用Beta版本服务，虽然对比文件1中的正式用户是按照灰度发布规则确定的，但是，将正式用户设定为开发人员、测试人员或管理员属于本领域技术人员根据实际需要的常规设定，是不需要付出创造性劳动的；2）在正式用户的用户信息中添加标识符，在灰度用户的用户信息中不添加标识符，从而区别正式用户和灰度用户，这是不需要付出创造性劳动的，另外，在本领域中，将一个装置的实现的功能拆分成两个装置来实现是不需要付出创造性劳动的，因此，由用户控制台在确定用户为测试用户后添加标签，由注册中心根据用户标识是否添加了标签来判断用户是否为测试用户是不需要付出创造性劳动的；3）在执行服务调用前，首先根据服务标识判断该服务是否以灰度方式发布，若是，则根据所述用户标识判断所述用户是否为测试用户，若是，则调用所述服务的Beta版本是不需要付出创造性劳动的；将所述微服务的Beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述Beta版本是本领域技术人员根据实际需要的常规选择，在此基础上，结合对比文件1公开的内容，所述注册中心将所述微服务的Beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述Beta版本是不需要付出创造性劳动的。因而坚持驳回决定。
随后，国家知识产权局成立合议组对本案进行审理。
合议组于2019年09月04日向复审请求人发出复审通知书，复审通知书依据的审查文本为：2019年05月21日提交的权利要求第1-8项， 2018年03月27日提交的说明书第1-92段、说明书附图图1-6、说明书摘要及摘要附图，引用的对比文件与驳回决定依据的对比文件相同。复审通知书中指出：权利要求1-8相对于对比文件1和本领域惯用手段的结合不具备专利法第22条第3款规定的创造性。对于复审请求人的意见，合议组认为：1）本申请权利要求1中，将添加标签和识别标签的功能分到用户控制台和注册中心两个装置来实现，降低了注册中心的资源耗费，增加了用户控制台的资源耗费，然而将一个装置的两个功能分到两个装置上来实现，从而降低装置的资源耗费属于本领域的惯用手段，因此，本申请由用户控制台在确定用户为测试用户后添加标签，由注册中心根据用户标识是否添加了标签来判断用户是否为测试用户对于本领域技术人员是容易想到的；2）首先，本申请权利要求中并未限定测试用户是固定不能改变的，实际上，本申请用户控制台也是可以根据需要设定用户是否为测试用户，即根据需要选取部分用户使用不同的版本，这与对比文件1并不矛盾；其次，对比文件1公开了托管服务器根据服务对应的灰度发布规则，确定是否设置该用户为灰度用户，若根据服务对应的灰度发布规则确定设置该用户为灰度用户，则在该用户的用户信息中添加灰度标识，该灰度标识可以为0或1等标识符，托管服务器接收用户的终端发送的服务访问请求，确定该服务访问请求携带的用户信息中是否包含灰度标识，如果是，则确定该用户为灰度用户，即对比文件1公开了注册中心判断所述用户标识是否添加表示所述用户为灰度用户的标签，所述标签在确定用户为灰度用户后添加，若所述用户标识添加有所述标签，则所述注册中心确定所述用户为灰度用户；对比文件1中的灰度用户为使用旧版本的用户，非灰度用户为使用新版本的用户，灰度用户通过灰度标识符来识别，那么不具有灰度标识符的用户即可识别为使用新版本的用户，在本领域中，包括开发人员、测试人员或管理员的测试用户使用新版本属于本领域的惯用手段，因此，通过添加的标签来识别测试用户对于本领域技术人员是容易想到的；用户标签由用户控制台或注册中心来添加可以根据需要进行选择，这属于本领域的惯用手段；3）对比文件1已经公开了当用户访问该服务时，用户通过终端发送服务访问请求给托管服务器，该服务访问请求携带用户的用户信息及服务的服务标识，服务以灰度方式发布，而微服务中，由于服务的多样，有些服务已经是新的正式在线版本了，因此，在执行服务调用前，首先根据服务标识判断该服务是否以灰度方式发布，若是，则根据所述用户标识判断所述用户是否为测试用户，若是，则调用所述服务的Beta版本是不需要付出创造性劳动的；对比文件1还公开了托管服务器将服务访问请求转发给版本升级后的docker容器集群，从而调用升级后的版本，而如何调用升级后的版本，比如，将所述微服务的Beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述Beta版本是本领域技术人员根据实际需要的常规选择，在此基础上，结合对比文件1公开的内容，所述注册中心将所述微服务的Beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述Beta版本是不需要付出创造性劳动的。
复审请求人于2019年09月29日提交了意见陈述书，未对申请文件进行修改。复审请求人认为：1）本申请中设置“所述注册中心根据所述微服务的标识判断所述微服务是否以灰度方式发布；若是，则所述注册中心根据所述用户标识判断所述用户是否为测试用户；若是，则所述注册中心将所述微服务的Beta版本的服务地址返回给所述用户控制台”这一技术特征并不是因为微服务的多样性，而是为了根据请求服务的用户类别来判断该服务是否需要以灰度方式发布，对于本领域技术人员来说，在不付出创造性劳动的情况下，只能想到在微服务存在多样性的前提下，才会在执行服务调用前，想到根据服务标识判断该服务是否以灰度方式发布的方案；2）在本领域中，特别是在docker容器集群应用环境，为了调用升级后的版本，都是通过向docker容器集群发送指令，因此，对于本领域技术人员来说，“将所述微服务的Beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述Beta版本”不属于本领域的惯用手段；3）对比文件1中，灰度用户是一个随机的，并不限于任何类型的用户，目的是为了让所有类型的用户来体验新版本，完成新旧版本的过渡，本申请目的是为了提供更新微服务的时候，让普通用户可以正常使用微服务的同时，开发人员、测试人员或管理员可以对Beta版本的微服务进行测试，因此，使开发人员、测试人员或管理员的测试用户使用新版本不属于本领域的惯用手段；4）本申请由用户控制台在确定用户为测试用户后添加标签，由注册中心根据用户标识是否添加了标签来判断用户是否为测试用户，这一特征不属于本领域的惯用手段，且其提高了识别用户类型的效率，无需额外耗费注册中心的处理资源去执行添加灰度标识的繁琐操作，降低了注册中心的资源开销。
在上述程序的基础上，合议组认为本案事实已经清楚，可以作出复审请求审查决定。
二、决定的理由
1、审查文本的认定
复审程序中，复审请求人于2019年05月21日提交了权利要求书全文修改替换页, 经审查，其对权利要求书的修改符合专利法第33条的规定。本复审请求审查决定针对的文本为：2019年05月21日提交的权利要求第1-8项， 2018年03月27日提交的说明书第1-92段、说明书附图图1-6、说明书摘要及摘要附图。
2、关于专利法第22条第3款
专利法第22条第3款规定：创造性，是指与现有技术相比，该发明具有突出的实质性特点和显著的进步，该实用新型具有实质性特点和进步。
本复审请求审查决定所引用的对比文件与驳回决定及复审通知书中引用的对比文件相同，即：
对比文件1：CN107248986A，公开日：2017年10月13日。
1）权利要求1请求保护一种灰度发布方法，对比文件1公开了一种服务托管方法，并具体公开了如下技术特征（参见说明书第[0001]段至第[0104]段）：本发明实施例通过托管服务器提供一套分布式系统组件开发工具，通过将微服务架构、集成环境和Docker集群的深度开发进行结合，组成了一套分布式系统组件开发工具，该开发工具用于满足用户快速开发、快速部署及服务管理的需求；为了实现服务的平滑升级，减少服务用户流失，本发明实施例提供灰度发布的升级方式，即让一部分用户继续用旧版本的服务，一部分用户开始用新版本的服务，如果使用新版本的服务的部分用户对新版本的服务没有什么反对意见，则逐步扩大用新版本的服务的用户数量，直至把所有用户都迁移到新版本的服务上面来；基于上述灰度发布的升级方式，在本发明实施例中启动服务的新版本后，托管服务器将新版本的服务确定为正式服务，将旧版本的该服务确定为灰度服务，将使用旧版本的用户确定为灰度用户，及将访问旧版本的请求确定为灰度请求；当用户登录托管服务器时，托管服务器接收用户的终端发送的登录请求，该登录请求携带用户账号及用户密码，当根据用户密码对用户账号认证通过后，根据服务对应的灰度发布规则，确定是否设置该用户为灰度用户；若根据服务对应的灰度发布规则确定设置该用户为灰度用户，则在该用户的用户信息中添加灰度标识；该灰度标识可以为0或1等标识符；该用户被设置为灰度用户后，该用户的终端发送的访问该服务的请求即为灰度请求，该用户后续访问该服务时均访问该服务的旧版本；若根据服务对应的灰度发布规则确定不设置该用户为灰度用户，则不在该用户的用户信息中添加灰度标识，该用户后续访问该服务时均访问该服务的新版本；当用户访问该服务时，用户通过终端发送服务访问请求给托管服务器，该服务访问请求携带用户的用户信息及服务的服务标识（相当于注册中心接收用户控制台发送的服务请求，所述服务请求包括用户的用户标识以及所述用户所请求的微服务的标识）；托管服务器接收用户的终端发送的服务访问请求，确定该服务访问请求携带的用户信息中是否包含灰度标识；如果是，则确定该用户为灰度用户（相当于所述注册中心根据所述用户标识判断所述用户类型），及确定该服务访问请求为灰度请求，根据服务标识，将该服务访问请求转发给版本升级前的服务对应的docker容器集群；如果否，则确定该用户为正式用户，根据服务标识将服务访问请求转发给版本升级后的服务的docker容器集群；通过深度优化的微服务架构，使服务各自独立，并隔离出灰度环境，用户的终端发送的服务访问请求，依据服务访问请求携带的用户信息中是否包含灰度标识，通过路由转发到不同后台，通过账号的分流，让不同用户进入不同环境，并且实现灰度环境和正式环境并存，数据互通，让用户无感知使用，实现灰度服务平滑升级成正式服务（相当于一种灰度发布方法）。
可见，权利要求1所要保护的技术方案与对比文件1公开的内容相比，其区别是：（1）所述注册中心根据所述微服务的标识判断所述微服务是否以灰度方式发布，若以灰度方式发布，执行之后的步骤；（2）权利要求1中是所述注册中心将所述微服务的Beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述Beta版本，而对比文件1中是托管服务器将服务访问请求转发给版本升级后的docker容器集群，从而调用升级后的版本；（3）所述注册中心根据所述用户标识判断所述用户是否为测试用户，包括：所述注册中心判断所述用户标识是否添加表示所述用户为测试用户的标签，所述标签由所述用户控制台在确定所述用户为测试用户后添加，若所述用户标识添加有所述标签，则所述注册中心确定所述用户为测试用户，所述测试用户包括开发人员、测试人员或管理员。
基于上述区别，权利要求1的技术方案相对于对比文件1的技术方案实际解决的技术问题是：如何调用Beta版本以及如何确定测试用户。
对于区别（1），对比文件1已经公开了当用户访问微服务时，用户通过终端发送服务访问请求给托管服务器，该服务访问请求携带用户的用户信息及服务的服务标识，服务以灰度方式发布，而微服务中，由于服务的多样，有些服务已经是新的正式在线版本了，因此，在执行服务调用前，首先根据服务标识判断该服务是否以灰度方式发布，若是，则根据所述用户标识判断所述用户是否为测试用户，若是，则调用所述服务的Beta版本是不需要付出创造性劳动的。
对于区别（2），对比文件1已经公开了托管服务器将服务访问请求转发给版本升级后的docker容器集群，而将服务对应的服务地址发给用户，使得用户根据该服务地址调用服务属于本领域的惯用手段，因此，注册中心将所述微服务的Beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述Beta版本对于本领域技术人员是容易想到的。
对于区别（3），对比文件1公开了托管服务器根据服务对应的灰度发布规则，确定是否设置该用户为灰度用户，若根据服务对应的灰度发布规则确定设置该用户为灰度用户，则在该用户的用户信息中添加灰度标识，该灰度标识可以为0或1等标识符，托管服务器接收用户的终端发送的服务访问请求，确定该服务访问请求携带的用户信息中是否包含灰度标识；如果是，则确定该用户为灰度用户，即对比文件1公开了注册中心判断所述用户标识是否添加表示所述用户为灰度用户的标签，所述标签在确定用户为灰度用户后添加，若所述用户标识添加有所述标签，则所述注册中心确定所述用户为灰度用户。对比文件1中的灰度用户为使用旧版本的用户，非灰度用户为使用新版本的用户，灰度用户通过灰度标识符来识别，那么不具有灰度标识符的用户即可识别为使用新版本的用户，在本领域中，包括开发人员、测试人员或管理员的测试用户使用新版本属于本领域的惯用手段，因此，通过添加的标签来识别测试用户对于本领域技术人员是容易想到的。用户标签由用户控制台或注册中心来添加可以根据需要进行选择，这属于本领域的惯用手段，因此，上述区别（3）对于本领域技术人员是容易想到的。
因此，在对比文件1的基础上结合上述惯用手段得到该权利要求的技术方案是显而易见的，该权利要求不具有突出的实质性特点和显著的进步，不具备专利法第22条第3款规定的创造性。
2） 权利要求2引用了权利要求1，对比文件1公开了以下技术特征（参见说明书第[0001]段至第[0104]段）：托管服务器接收用户的终端发送的服务访问请求，确定该服务访问请求携带的用户信息中是否包含灰度标识；如果是，则确定该用户为灰度用户，及确定该服务访问请求为灰度请求，根据服务标识，将该服务访问请求转发给版本升级前的服务对应的docker容器集群；如果否，则确定该用户为正式用户，根据服务标识将服务访问请求转发给版本升级后的服务的docker容器集群。对比文件1已经公开了调用升级前的版本，而如何调用升级前的版本，比如，所述注册中心向所述用户控制台返回所述微服务的正式在线版本的服务地址是不需要付出创造性劳动的。因此，在其引用的权利要求不具备创造性时，该从属权利要求同样不具备专利法第22条第3款规定的创造性。
3） 权利要求3引用了权利要求1，对比文件1公开了以下技术特征（参见说明书第[0001]段至第[0104]段）：为了实现服务的平滑升级，减少服务用户流失，本发明实施例提供灰度发布的升级方式，即让一部分用户继续用旧版本的服务，一部分用户开始用新版本的服务，如果使用新版本的服务的部分用户对新版本的服务没有什么反对意见，则逐步扩大用新版本的服务的用户数量，直至把所有用户都迁移到新版本的服务上面来。在对比文件1公开的上述内容的基础上，若所述Beta版本通过测试，则所述注册中心下线原正式在线版本，并将所述Beta版本升级为新的正式在线版本是不需要付出创造性劳动的。因此，在其引用的权利要求不具备创造性时，该从属权利要求同样不具备专利法第22条第3款规定的创造性。
4） 权利要求4引用了权利要求1，对比文件1公开了以下技术特征（参见说明书第[0001]段至第[0104]段）：为了实现服务的平滑升级，减少服务用户流失，本发明实施例提供灰度发布的升级方式，即让一部分用户继续用旧版本的服务，一部分用户开始用新版本的服务，如果使用新版本的服务的部分用户对新版本的服务没有什么反对意见，则逐步扩大用新版本的服务的用户数量，直至把所有用户都迁移到新版本的服务上面来。在对比文件1公开的上述内容的基础上，若所述Beta版本没有通过测试，则所述注册中心下线所述Beta版本是不需要付出创造性劳动的。因此，在其引用的权利要求不具备创造性时，该从属权利要求同样不具备专利法第22条第3款规定的创造性。
5）权利要求5引用了权利要求2至3任一项，对比文件1公开了以下技术特征（参见说明书第[0001]段至第[0104]段）：为了实现服务的平滑升级，减少服务用户流失，本发明实施例提供灰度发布的升级方式，即让一部分用户继续用旧版本的服务，一部分用户开始用新版本的服务，如果使用新版本的服务的部分用户对新版本的服务没有什么反对意见，则逐步扩大用新版本的服务的用户数量，直至把所有用户都迁移到新版本的服务上面来；托管服务器接收用户的终端发送的服务访问请求，确定该服务访问请求携带的用户信息中是否包含灰度标识；如果是，则确定该用户为灰度用户，及确定该服务访问请求为灰度请求，根据服务标识，将该服务访问请求转发给版本升级前的服务对应的docker容器集群；如果否，则确定该用户为正式用户，根据服务标识将服务访问请求转发给版本升级后的服务的docker容器集群（相当于所述注册中心确定所述Beta版本的版本号高于所述正式在线版本的版本号）。因此，在其引用的权利要求不具备创造性时，该从属权利要求同样不具备专利法第22条第3款规定的创造性。
6）权利要求6-8是与权利要求1、2、权利要求3和权利要求4的组合相对应的系统权利要求，且在本领域中，采用具体的系统、设备来实现指定的方法步骤以及系统中包含实现具体功能的设备属于本领域的惯用手段，因此，在权利要求1-4不具备创造性的基础上，权利要求6-8所要求的保护的技术方案，对于本领域技术人员来说是显而易见的，因此，权利要求6-8所要求保护的技术方案不具备突出的实质性特点和显著的进步，因此，不具备专利法第22条第2款规定的创造性。
3、对复审请求人相关意见的评述
对于复审请求人的意见，合议组认为：
1）复审通知书中已经指出“微服务中，由于服务的多样，有些服务已经是新的正式在线版本了”，可见，此处服务的多样性指的是微服务有些以新的正式在线版本发布，有些以非正式在线版本发布，即部分为灰度发布，部分为非灰度发布，而本申请中根据存储的微服务的类型信息或微服务对应的用户的类型信息来判断微服务是否以灰度方式发布，也是因为微服务的多样性，来判断服务是否以灰度方式发布，因此，在执行服务调用前，首先根据服务标识判断该服务是否以灰度方式发布，若是，则根据所述用户标识判断所述用户是否为测试用户，若是，则调用所述服务的Beta版本是不需要付出创造性劳动的。
2）将服务对应的服务地址发给用户，使得用户根据该服务地址调用服务属于本领域的惯用手段，因此，注册中心将所述微服务的Beta版本的服务地址返回给所述用户控制台，以使所述用户控制台根据所述服务地址调用所述Beta版本对于本领域技术人员是容易想到的。
3）对比文件1随机选取部分用户使用不同的版本，使用新版本的用户实际上就是一种测试用户，因此，对比文件实现了在提供更新微服务的时候，让非测试用户的普通用户正常使用微服务的同时，测试用户可以对新版本的微服务进行测试，这与本申请是一致的。另外，在本领域中，使用新版本的测试用户包括开发人员、测试人员或管理员属于本领域的惯用手段。
4）本申请权利要求1将对比文件1中添加标签和识别标签的功能分到用户控制台和注册中心两个装置来实现，降低了注册中心的资源耗费，增加了用户控制台的资源耗费，然而将一个装置的两个功能分到两个装置上来实现，从而降低装置的资源耗费属于本领域的惯用手段，因此，本申请由用户控制台在确定用户为测试用户后添加标签，由注册中心根据用户标识是否添加了标签来判断用户是否为测试用户对于本领域技术人员是容易想到的。
因此，复审请求人的意见不具备说服力，合议组不予支持。
三、决定
维持国家知识产权局于2019年02月12日对本申请作出的驳回决定。
如对本复审请求审查决定不服，根据专利法第41条第2款的规定，复审请求人可以自收到本决定之日起三个月内向北京知识产权法院起诉。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
