发明创造名称：网络进程管理方法及装置
外观设计名称：
决定号：41711
决定日：2019-09-05
委内编号：4W108722
优先权日：
申请（专利）号：200610168028.1
申请日：2006-12-15
复审请求人：
无效请求人：极进网络技术（北京）有限公司
授权公告日：2011-08-10
审定公告日：
专利权人：全球创新聚合有限责任公司
主审员：吴卫民
合议组组长：张巍
参审员：郭琼
国际分类号：H04Q3/00，H04M3/24
外观设计分类号：
法律依据：专利法第26条第3款，专利法第26条第4款，专利法实施细则第20条第1款，专利法实施细则第21条第2款，专利法第22条第3款
决定要点：对专利说明书和权利要求书中的技术方案的理解应当基于本领域技术人员的技术水平和认知能力，并将专利文件作为一个整体来看待。
全文：
本无效宣告请求审查决定涉及专利号为200610168028.1、名称为“网络进程管理方法及装置”的发明专利（下称本专利），本专利的申请日为2006年12月15日，授权公告日为2011年08月10日，专利权人原为“华为技术有限公司”，后变更为“全球创新聚合有限责任公司”。本专利授权公告时的权利要求书如下：
“1. 一种网络进程管理方法，其特征在于，包括以下步骤：
获取网络实体当前物理资源的利用率及需要的业务负荷；
比较所述业务负荷与所述网络实体中当前运行的全部或部分子进程的总负荷大小；
根据比较结果及所述当前物理资源的利用率调整所述网络实体中子进程的数量。
2. 根据权利要求1所述的方法，其特征在于，所述获取网络实体当前物理资源的利用率的步骤包括：
获取网络实体的物理资源；
计算所述物理资源的平均负荷及可用的物理内存总量；
根据所述物理资源的平均负荷及可用的物理内存总量确定所述当前物理资源的利用率。
3. 根据权利要求1所述的方法，其特征在于，所述获取网络实体的业务负荷的具体为：
根据业务控制点的试呼次数确定所述业务负荷。
4. 根据权利要求1所述的方法，其特征在于，所述根据比较结果及所述当前物理资源的利用率调整所述网络实体中子进程的数量的步骤包括：
在所述物理资源的利用率小于预定的最佳利用率的情况下，如果所述业务负荷大于所述网络实体中所有子进程的负荷，则创建一个或多个新的子进程分担所述业务负荷；
在所述物理资源的利用率大于预定的最佳利用率的情况下，如果所述业务负荷小于所述网络实体中所有子进程的负荷，则终止一个或多个子进程。
5. 根据权利要求4所述的方法，其特征在于，所述方法进一步包括：
为所述网络实体中的所有可用子进程设置加载优先级；
在创建一个或多个新的子进程时，优先创建优先级高的子进程；
在终止一个或多个子进程时，优先终止优先级低的子进程。
6. 根据权利要求4所述的方法，其特征在于，所述终止一个或多个子进程的步骤包括：
选择需要终止的子进程；
在执行完该子进程的所有任务后终止该子进程。
7. 一种网络进程管理装置，其特征在于，包括：
物理资源利用率计算单元，用于计算网络实体当前物理资源的利用率，所述物理资源的利用率包括物理资源的平均负荷及可用的物理内存总量；
子进程负荷统计单元，用于统计所述网络实体中当前运行的所有子进程负荷；
业务负荷估计单元，用于估计所述网络实体当前的业务负荷；
比较单元，用于对所述业务负荷与所述网络实体中所有子进程负荷进行比较，获得比较结果；
子进程调整单元，用于根据所述比较结果及所述当前物理资源的利用率调整所述网络实体中子进程的数量。
8. 根据权利要求7所述的装置，其特征在于，所述子进程调整单元包括：
子进程创建子单元，用于创建新的子进程；
子进程终止子单元，用于终止当前子进程；
调整控制子单元，根据所述物理资源的利用率小于预定的最佳利用率，并且所述业务负荷大于所述网络实体中所有子进程的负荷时，通知所述子进程创建子单元创建一个或多个新的子进程；在所述物理资源的利用率大于预定的最佳利用率，并且所述业务负荷小于所述网络实体中所有子进程的负荷时，通知所述子进程终止子单元终止一个或多个子进程。
9. 根据权利要求7所述的装置，其特征在于，所述装置还包括：
优先级设定单元，为所述网络实体中的所有可用子进程设置加载优先级，以使所述子进程创建子单元和所述子进程终止子单元根据该加载优先级创建或终止需要的子进程。”
针对上述专利权，极进网络技术（北京）有限公司（下称请求人）于2019年04月08日向国家知识产权局提出了无效宣告请求，请求宣告本专利权利要求1-9全部无效，请求人提出的具体无效理由是：权利要求1-9没有以说明书为依据，不符合专利法第26条第4款的规定；权利要求1-9的保护范围不清楚，不符合专利法实施细则第20条第1款的规定；本专利的说明书公开不充分，不符合专利法第26条第3款的规定。
经形式审查合格，国家知识产权局于2019年04月15日受理了上述无效宣告请求并将无效宣告请求书转给专利权人，同时成立合议组对本案进行审查。
请求人于2019年05月08日补充提交了意见陈述书和证据，提交的证据如下：
证据1：中国专利申请公开文本CN1430376A，共12页，公开日为2003年07月16日；
证据2：中国专利申请公开文本CN1567834A，共16页，公开日为2005年01月19日；
证据3：题目为“GSM移动智能网SCP业务触发新机制的设计与实现”的论文打印件，刘国辉，CNKI《中国优秀硕士学位论文全文数据库＿信息科技辑》，2006年第11期，共65页，请求人主张其公开日为2006年11月15日；
证据4：中国专利申请公开文本CN1670706A，共13页，公开日为2005年09月21日；
证据5：美国专利申请公开文本US5574770A以及中文译文，共41页，公开日为1996年11月12日；
证据6：美国专利申请公开文本US2006/0136761A1以及相关段落的中文译文，共26页，公开日为2006年06月22日；
证据7：国家图书馆科技查新中心出具的编号为2019-NLC-GCZM-0395的检索报告复印件，其中附有文献复制证明复印件、以及《Apache服务器配置与管理》封面、首页、版权页、序言、目录、第32-51、94-99页、封底复印件，黄栋，清华大学出版社，2002年9月出版，共40页；
证据8：《Unix入门经典》封面、首页、版权页、前言、目录、第148-165页复印件，张楚雄、许文昭译，清华大学出版社，2006年4月出版，共32页；
证据9：《网络管理员教程》封面、首页、版权页、目录部分第1-2页、第264和272-274页复印件，张国鸣、严体华主编，清华大学出版社，2006年6月第2版，共8页；
证据10：本专利的实质审查过程中的相关审查意见通知书以及申请人提交的意见陈述书，共13页。
请求人在意见陈述书中认为：
（1）权利要求1-9保护范围不清楚，不符合专利法实施细则第20条第1款的规定；（2）权利要求1-9缺少必要技术特征，不符合专利法实施细则第21条第2款的规定；（3）在证据1的基础上结合其他证据和/或公知常识，权利要求1-9不具备专利法第22条第3款规定的创造性。
本案合议组于2019年05月17日向专利权人发出转送文件通知书，将请求人于2019年05月08日提交的意见陈述书及证据副本转给专利权人。
针对请求人提交的无效宣告请求书和意见陈述书，专利权人于2019年06月21日提交了意见陈述书。专利权人在意见陈述书中陈述了本专利符合专利法和专利法实施细则相关规定的理由，请求维持专利权有效。
合议组于2019年06月27日向请求人发出转送文件通知书，将专利权人2019年06月21日提交的意见陈述书转送给请求人，并于同日向双方当事人发出了口头审理通知书，定于2019年07月31日举行口头审理。
口头审理如期举行，双方当事人均出席了口头审理。口头审理中，主要确认了如下事项：
1、双方当事人对对方出庭人员身份无异议，对合议组成员变更无异议，对合议组成员无回避请求。
2、针对专利权人2019年06月21日提交的意见陈述书，请求人当庭提交了意见陈述书，合议组当庭将请求人提交的上述意见陈述书及附件转交给专利权人，专利权人表示当庭陈述意见，庭后不再提交书面意见。
3、请求人明确表示：关于权利要求1-9保护范围不清楚，不符合专利法实施细则第20条第1款的规定的无效理由以2019年05月08日提交的意见陈述书中的记载为准；本专利的说明书公开不充分，不符合专利法第26条第3款的规定的无效理由涉及到权利要求1-9的技术方案。
4、请求人当庭提出在创造性评述中，将证据2作为最接近的对比文件。合议组当庭告知双方当事人，在请求人提交的无效宣告请求书以及意见陈述书中并未记载以证据2作为最接近的对比文件并进一步结合其他对比文件的评述方式，请求人的该主张不符合《专利审查指南》中补充无效宣告理由的期限的规定，合议组对此不予接受。请求人进一步明确关于权利要求1、7的创造性评述中，当采用证据1结合证据2的评述方式时，证据7和证据9作为公知常识性证据使用，当采用证据1结合证据7或证据9的评述方式时，证据7和证据9作为对比文件使用；在评述权利要求2、9时，证据8也作为公知常识性证据使用。此外，请求人明确证据10作为参考使用。
5、专利权人明确表示对请求人提交的证据1至证据9的真实性和公开时间无异议，对证据5和证据6的中文译文的准确性无异议，对证据7至证据9作为公知常识性证据无异议。
6、双方当事人在坚持书面意见的基础上针对本专利权利要求是否符合专利法及实施细则的相关规定充分发表了意见。
至此，合议组认为本案事实已经清楚，可以作出审查决定。
二、决定的理由
（一）审查基础及法律适用
本无效宣告请求审查决定所针对的文本为本专利的授权公告文本。
本专利的申请日为2006年12月15日，根据实施修改后的专利法和专利法实施细则的过渡办法的相关规定，本案的审理适用2000年08月25日第二次修正的专利法及2002年12月28日第一次修订的专利法实施细则。
（二）证据认定
专利权人明确表示对请求人提交的证据1至证据9的真实性和公开时间无异议，对证据5和证据6的中文译文的准确性无异议。证据1至证据9的公开日期均早于本专利的申请日，可以作为现有技术评价本专利的新颖性和创造性。证据5和证据6的公开内容以请求人提交的中文译文为准。
（三）专利法第26条第3款
专利法第26条第3款规定：说明书应当对发明或者实用新型作出清楚、完整的说明，以所属技术领域的技术人员能够实现为准；必要的时候，应当有附图。
请求人认为：本专利说明书第[0009]段记载了“比较所述业务负荷与所述网络实体中当前运行的全部或部分子进程的总负荷大小”，说明书第[0028]段记载了“当前的业务负荷可以通过业务的试呼次数来估计”，说明书第[0029]-[0030]段及图1记载了“步骤102：计算网络实体中当前所有子进程的总负荷。可以通过操作系统提供的工具进行统计，不同的系统可能有不同的工具，如Window操作系统、unix操作系统都提供有相应的工具。由于系统内子进程有很多，因此，也可以只关注与业务处理相关的重要子进程，即占用CPU最多的一个或多个子进程”。但是，说明书中没有公开如何计算“业务负荷”和“子进程的总负荷大小”，也未公开“业务负荷”和“网络实体中当前所有子进程的总负荷”的度量标准，以及如何将上述两个因素统一到一个度量标准来进行比较，导致本领域技术人员无法得到上述关键步骤的实现方式，从而无法实现本发明。因此，本专利的说明书公开不充分，不符合专利法第26条第3款的规定，涉及到权利要求1-9的技术方案。
合议组认为：首先，对于当前的业务负荷，本专利说明书第[0028]段记载了“当前的业务负荷可以通过业务的试呼次数来估计”；对于当前所有子进程的总负荷，说明书第[0030]段记载了“可以通过操作系统提供的工具进行统计，不同的系统可能有不同的工具，如Windows操作系统、unix操作系统都提供有相应的工具”；对于部分子进程的总负荷，说明书第[0030]段记载了“由于系统内子进程有很多，因此，也可以只关注与业务处理相关的重要子进程，即占用CPU最多个一个或多个子进程”。基于说明书的上述记载，本领域技术人员结合其所掌握的本领域的技术常识，如通信领域的相关规范和标准，其能够使用本领域的公知技术实现负荷的量度方式、两个负荷的比较方式。因此，本领域技术人员根据说明书的记载，为实现本发明目的，可以采用现有技术中的技术手段计算和比较负荷，本专利说明书公开充分，符合专利法第26条第3款的规定。
综上所述，请求人提出的上述说明书公开不充分，不符合专利法第26条第3款的规定的无效理由不成立。
（四）专利法第26条第4款
专利法第26条第4款规定：权利要求书应当以说明书为依据，说明要求专利保护的范围。
请求人认为：权利要求1包括如下特征：“比较所述业务负荷与所述网络实体中当前运行的全部或部分子进程的总负荷大小”。而说明书第[0017]及[0021]段记载了“根据该业务负荷与实体中当前运行的所有子进程负荷能力的大小”以及“比较该业务负荷与实体中当前运行的全部或部分子进程的总负荷能力的大小”。可见，权利要求1中的特征与说明书中记载的技术特征不一致，得不到说明书的支持，不符合专利法第26条第4款的规定。基于类似的理由，权利要求2-9也得不到说明书的支持，不符合专利法第26条第4款的规定。
合议组认为：首先，本专利说明书第[0009]段记载了与权利要求1相同的内容“比较所述业务负荷与所述网络实体中当前运行的全部或部分子进程的总负荷大小”。其次，说明书第[0017]、[0021]、[0029]、[0037]段记载了“根据该业务负荷与实体中当前运行的所有子进程负荷能力的大小”，“然后比较该业务负荷与实体中当前运行的全部或部分子进程的总负荷能力的大小”，“步骤102：计算网络实体中当前所有子进程的总负荷”，“步骤107：判断网络实体的当前业务负荷是否小于其当前所有子进程的总负荷”，根据上述记载可知，总负荷大小、负荷能力的大小、总负荷均有占用资源的意思，说明书作为一个整体能够支持权利要求1。本领域技术人员根据本专利说明书的记载可以得到或概括得出权利要求1的“比较所述业务负荷与所述网络实体中当前运行的全部或部分子进程的总负荷大小”，因此权利要求1能够得到说明书支持，符合专利法第26条第4款的规定，基于类似的理由，权利要求2-9也能够得到说明书的支持，符合专利法第26条第4款的规定。
因此，请求人提出权利要求1-9得不到说明书的支持，不符合专利法第26条第4款的规定的无效理由不能成立。
（五）专利法实施细则第20条第1款
专利法实施细则第20条第1款规定：权利要求书应当说明发明或者实用新型的技术特征，清楚、简要地表述请求保护的范围。
请求人认为：权利要求1中的特征“比较所述业务负荷与所述网络实体中当前运行的全部或部分子进程的总负荷大小”含义不清楚。本专利说明书第[0017]及[0021]段记载了“根据该业务负荷与实体中当前运行的所有子进程负荷能力的大小”以及“比较该业务负荷与实体中当前运行的全部或部分子进程的总负荷能力的大小”，以及根据说明书第[0029]-[0030]段及图1中步骤的记载和说明书第[0054]-[0060]段的记载，不清楚权利要求1中与“业务负荷”比较的对象是“实体中当前运行的全部或部分子进程的总负荷能力的大小”、“当前所有子进程的总负荷”、还是“上限”和“一定门限”。导致权利要求1的保护范围不清楚，不符合专利法实施细则第20条第1款的规定。基于类似的理由，权利要求2-9也得不到说明书的支持，不符合专利法实施细则第20条第1款的规定。
合议组认为：本专利说明书[0009]段记载了与权利要求1相同的内容“比较所述业务负荷与所述网络实体中当前运行的全部或部分子进程的总负荷大小”。其次，说明书第[0017]、[0021]、[0029]、[0037]段记载了“根据该业务负荷与实体中当前运行的所有子进程负荷能力的大小”，“然后比较该业务负荷与实体中当前运行的全部或部分子进程的总负荷能力的大小”，“步骤102：计算网络实体中当前所有子进程的总负荷”，“步骤104：判断网络实体的当前业务负荷是否大于其当前所有子进程的总负荷”，“步骤107：判断网络实体的当前业务负荷是否小于其当前所有子进程的总负荷”，根据权利要求1记载的内容结合说明书的记载，与“业务负荷”进行比较的对象就是当前负荷的大小，即“实体中当前运行的全部或部分子进程的总负荷能力的大小”，本领域技术人员能够理解权利要求1的“比较所述业务负荷与所述网络实体中当前运行的全部或部分子进程的总负荷大小”的含义，因此权利要求1的保护范围对本领域技术人员而言是清楚的，符合专利法实施细则第20条第1款的规定。基于类似的理由，权利要求2-9的保护范围也是清楚的，符合专利法实施细则第20条第1款的规定。
综上所述，请求人提出的权利要求1-9保护范围不清楚，不符合专利法实施细则第20条第1款规定的无效理由不成立。
（六）专利法实施细则第21条第2款
专利法实施细则第21条第2款规定：独立权利要求应当从整体上反映发明或者实用新型的技术方案，记载解决技术问题的必要技术特征。
请求人认为：根据本专利说明书的记载，要解决技术问题是使子进程的负荷与业务负荷需求相适应，并确保系统资源利用率达到最佳水平。并且，根据说明书第[0022]、[0049]段以及图1步骤104和107的记载，“根据各网络实体的物理硬件资源和操作系统的限制，通信进程的数量可以有不同的上下限”、“根据网络负荷增、减子进程数量时，使其保持在该上下限范围内”。可见，在本专利的说明书中对于子进程数量的调整必须限定在上下限范围之内，并且本专利的各个实施例始终将上述特征作为必要技术特征记载。然而，在权利要求1未对子进程调整的范围进行限定，而当超出“上下限范围”调整子进程的数量，例如超出“最大子进程数”或低于“最小子进程数”，显然是无法实现“子进程的负荷与业务负荷需求相适应”，不能解决上述技术问题，因此，权利要求1缺少解决其技术问题的必要技术特征，不符合专利法实施细则第21条第2款的规定。基于与权利要求1相同的理由，权利要求7也缺少解决技术问题的必要技术特征，权利要求1的从属权利要求2-6和权利要求7的从属权利要求8-9也缺少解决技术问题的必要技术特征，不符合专利法实施细则第21条第2款的规定。
合议组认为：根据本专利说明书[0005]段记载，本专利解决的技术问题为“提供一种网络进程管理方法及装置，以实现优化通信系统，充分利用系统资源，提高系统的业务处理能力”。权利要求1的技术方案为，“获取网络实体当前物理资源的利用率及需要的业务负荷；比较所述业务负荷与所述网络实体中当前运行的全部或部分子进程的总负荷大小；根据比较结果及所述当前物理资源的利用率调整所述网络实体中子进程的数量”。根据权利要求1的技术方案，其中记载了要获取网络实体当前物理资源的利用率，并根据该当前物理资源的利用率对子进程数量进行调整，从而动态创建或终止实体中运行的子进程，从而使子进程的负荷与业务负荷需求相适应，并确保系统资源利用率达到最佳水平，解决了优化通信系统，充分利用系统资源，提高系统业务处理能力的技术问题。因此，本专利权利要求1已经记载了为解决其所提出的技术问题所不可缺少的技术特征，符合专利法实施细则第21条第2款的规定。基于类似的理由，权利要求2-9也不缺少必要技术特征，符合专利法实施细则第21条第2款的规定。
因此，请求人提出权利要求1-9缺少必要技术特征，不符合专利法实施细则第21条第2款的规定的无效理由不能成立。
（七）针对请求人的意见评述
针对上述无效理由，请求人当庭发表了以下观点：专利权人在实质审查阶段答复第一次审查意见通知书的第1页最后两行到第2页第2行认为“对网络进程的管理所依据的参数是：当前物理资源的利用率和业务负荷的比率来决定是否需要对实体中子进程进行调整。由于所基于的参数不同，其算法实现必然不同”，但专利权人在针对关于专利法第26条第3款、专利法第26条第4款、专利法实施细则第20条第1款、专利法实施细则第21条第2款的无效请求理由的意见陈述中，认为获取负荷以及负荷比较的具体算法是公知常识，本专利的核心是在于如何调整。可见，专利权人对于本专利涉及不同法条的无效请求理由的答复意见与其在实质审查阶段的答复不一致，合议组应当不予接受。
对此，合议组认为：专利权人在实质审查阶段答复第一次审查意见通知书的第1页最后两行到第2页第2行的意见指出了本专利与实质审查阶段审查员所使用的对比文件的区别，实质上是相对于该对比文件而言强调了本专利进行比较时涉及的具体参数。本领域技术人员均知晓表示系统性能的参数有很多，其中包括负荷和物理资源利用率等，获取这些参数以及参数比较的具体算法都是本领域技术人员已知的，但是从众多的系统性能参数中选择哪几个参数来使用，以及如何使用来用于后续的调整以改进系统性能是本专利的核心。故合议组对请求人陈述的上述意见不予支持。
（八）关于专利法第22条第3款
专利法第22条第3款规定：创造性，是指同申请日以前的已有技术相比，该发明有突出的实质性特点和显著的进步，该实用新型有实质性特点和进步。
1、权利要求1保护一种网络进程管理方法，证据1公开了一种自动过负荷控制系统（参见证据1说明书第3-7页，图1、2和4）：在智能网（IN）系统中对SCP（业务控制点）（相当于权利要求1中的网络实体）的自动过负荷控制方法和系统。自动过负荷控制系统包括接入实体、中央处理实体、漏桶模块、参数检测模块、参数估计模块和模糊控制模块。接入实体主要负责呼叫的接入，中央处理实体是呼叫核心处理模块。控制系统工作时，接入实体将呼叫/数据送入漏桶模块，漏桶模块相当于呼叫/数据的过滤器，将过滤后的呼叫/数据接入中央处理实体中进行实时处理。参数检测模块持续不断检测中央处理实体当前的复合参数，包括负荷量值和负荷量变化率。所获取的负荷参数一方面直接送入模糊控制器中直接进行负反馈控制，另一方面送入参数估计模块用于计算负荷参数估计误差。负荷参数估计误差也送入模糊控制器，模糊控制器根据模糊规则进行模糊决策，根据当前负荷确定最佳漏桶速率参数，该参数决定了对呼叫/数量的过滤数量。
参数检测模块采用CPU占用率、消息积压数、BHCA性能指标和接入呼叫数变化率作为基本衡量参数。其中，系统的处理能力直接反映就是“CPU占有率”，该指标能够较好的反应出当前系统对负荷的承受能力（相当于网络实体当前物理资源利用率）。参数检测模块输出元素为中央处理实体的基本负荷指标（如CPU占用率、消息积压数、BH以性能指标等）和重要指标的变化率（如CPU占有率变化率，接入呼叫／数据变化率），这些参数被送到模糊控制器端，另外，将CPU占有率送入参数估计模块进行参数估计。参数估计模块，其中在系统实际运行过程中，如果能够依据当前的呼叫量对负荷进行估计预测，就可以和实际系统检测到的负荷参数如CPU占有率，进行比较，如果实际系统负荷远高于估计预测值，说明系统现在存在一些额外系统负荷，很可能系统正在处理一些额外任务，此时就可以适当调低漏桶速率参数，使得系统能够控制接入的呼叫数。这样就可以较好的控制突发性的额外任务对系统的冲击。
以智能网的过负荷控制为例，假如某时刻检测到的CPU负荷值为Ot（相当于网络实体中当前负荷大小），并推出CPU负荷最优估计值Ot＊和估计误差△Ot＝Ot＊ - Ot。参数估计模块的输入元素包括：参数检测模块检测到的原始负荷参数（CPU负荷值），漏桶端当前时刻实际接入的呼叫/数据量（相当于需要的业务负荷）。输出元素包括：CPU负荷参数的估计误差值。另外，在进行参数估计的时候，还需要存储在参数估计模块中的前若干时刻的原始负荷数据。
模糊逻辑控制器中的模糊规则库的规则例如“IF CPU占有率为65％（相当于网络实体当前物理资源利用率）AND消息积压数小于15 AND 参数估计误差小于1 THEN负荷级别零级，漏桶速率为R0 *（CPU＊）／（CPU）”。模糊推理机使用模糊规则库中的规则进行推理，产生适当的决策，最后反馈到SSP进行呼叫限制。
可见，证据1中的技术方案是通过调整漏桶参数控制智能网的接入呼叫数，从而有效控制中央处理实体负荷，其中漏桶参数基于参数估计模块的输出元素进行调整，参数估计模块通过对参数检测模块检测到的CPU负荷值和漏桶端当前时刻实际接入的呼叫/数据量进行估计运算来输出CPU负荷参数的估计误差值，即证据1的技术方案是根据中央处理实体的实际处理能力以牺牲一部分业务为代价保证系统的运行，最大化地利用了系统处理能力，其关注重点是系统当前能够处理的业务负荷，其调整依据是CPU占有率、CPU负荷和CPU负荷最优估计值，调整的对象是接入呼叫的数量，并不涉及网络实体中的子进程。
因此，权利要求1保护的技术方案与证据1相比，二者的区别特征是：权利要求1中比较所述业务负荷与所述网络实体中当前运行的全部或部分子进程的总负荷大小，根据比较结果及所述物理资源的利用率调整所述网络实体中子进程的数量。基于上述区别特征，可以确定权利要求1相对于证据1实际解决的技术问题是：如何满足业务负荷需求的同时提高系统资源利用率。
证据2公开了一种动态调整业务管理点系统服务性能的方法（参见证据2全文，尤其是权利要求1-12，说明书第7-9页，图5）：包括启动或删除业务服务的服务进程（相当于网络进程）。其中，步骤503、监控模块根据该业务服务的用户数量信息（相当于需要的业务负荷）及服务所在设备的负荷量判断服务是否能够满足用户的需求，如果能满足，则返回步骤503，如果不能满足，则进入下一步。需要设置用户数量信息值及服务所在设备的负荷量值，作为判断服务是否满足用户需求以及是否需要在SMP中增加业务服务的依据，该值可以根据不同需要进行设置。本实施例是通过业务服务所在设备中CPU的占用情况来判断该业务服务的负荷情况，因此可以把CPU的占用率作为业务服务的负荷量（相当于网络实体当前物理资源利用率）。步骤504、监控模块启动该业务服务的服务进程（相当于增加网络进程）。动态降低业务服务性能的具体流程与动态提高业务服务性能的具体流程类似，所不同的是，降低业务服务性能是服务中心将业务服务的用户数量信息发送到配置中心，配置中心根据该业务服务的用户数量信息及服务所在设备的负荷量判断是否需要删除业务服务的服务进程或业务服务，如果需要删除业务服务的服务进程，则配置中心选择一个服务进程，并向该服务进程发送删除该服务进程的删除消息（相当于减少网络进程），同时向监控模块发送删除该服务进程的通知消息。
可见，证据2公开的是将当前用户数量（相当于需要的业务负荷）与设备CPU占有率（相当于网络实体当前物理资源利用率）进行比较，根据比较结果调整网络进程的数量，但证据2并没有公开比较所述业务负荷与所述网络实体中当前运行的全部或部分子进程的总负荷大小，根据比较结果及所述物理资源的利用率调整所述网络实体中子进程的数量。因此，证据2没有公开上述区别特征。
证据7公开一种服务器（相当于网络实体）的配置和管理的方法（参见证据7全文，特别是第39-42页，图3-1）：Standalone参数表示Web服务进程由一个单一的服务器进程启动，以一个单独的守候进程的方式驻留在主机后台，监听是否有客户端的请求。如果有，就生成一个子进程来为其服务。Apache服务器在运行中，随着客户请求的增多，启动的子进程会随之增多，但这些服务器进程副本在处理完一次HTTP请求之后并不立即退出，而是停留在计算机中等待下次请求。但是空余的子进程副本不能光增加不减少，如果太多的空余子进程没有处理任务，将影响服务器的处理能力，因此要限制空余副本的数量，使其保持一个合适的数量，使得既能及时响应客户请求，又能减少不必要的进程数量以使用参数MinSpareServers来设置最少的空余子进程数量，使用参数MaxSpareServers来限制最多的空闲子进程数量，多余的服务器进程副本就会退出。
可见，证据7公开的是在服务器中设置了空闲子进程的上限和下限以确保有能力处理客户请求，当空闲子进程的数量超过上限或者低于下限时相应的减少子进程或增加子进程，但证据7中并没有公开比较所述业务负荷与所述网络实体中当前运行的全部或部分子进程的总负荷大小，根据比较结果及所述物理资源的利用率调整所述网络实体中子进程的数量。因此，证据7没有公开上述区别特征。
证据9同样公开了一种服务器（相当于网络实体）的配置和管理的方法（参见证据9全文，特别是第272-273页）：最小空闲进程数（MinSpareServers）用来指定进程池中最低空闲服务器数量（空闲服务器等待输入连接），Apache的主进程总是保证至少有这么多的空闲服务器进程在等待处理客户请求。最大空闲进程数（MaxSpareServers）用来指定进程池中最大空闲进程数。如果空闲的进程数超过这个值，Apache主进程就会结束过多的服务器进程，直到空闲进程数少于此数目。
可见，证据9公开的是在服务器中设置了空闲子进程的上限和下限以确保有能力处理客户请求，当空闲子进程的数量超过上限或者低于下限时相应的减少子进程或增加子进程，但证据9中并没有公开比较所述业务负荷与所述网络实体中当前运行的全部或部分子进程的总负荷大小，根据比较结果及所述物理资源的利用率调整所述网络实体中子进程的数量。因此，证据9没有公开上述区别特征。
针对权利要求1中“比较所述业务负荷与所述网络实体中当前运行的部分子进程的总负荷大小”的方案，请求人进一步引用了证据3，证据3公开了（参见证据3全文，特别是正文第24-28页以及第49-51页）获取SCP系统性能的方法，具体公开了ininit进程会创建manager等进程，并由manager进程创建多个SCF进程，以用于处理呼叫。还公开了inmon进程，用于查看当前scf进程的状态及当前每个scf进程处理的呼叫数和负荷（相当于网络实体中当前运行的部分子进程的负荷大小）。
可见，证据3公开的是获取网络实体中当前运行的部分子进程的负荷大小，但证据3中并没有公开比较所述业务负荷与所述网络实体中当前运行的全部或部分子进程的总负荷大小，根据比较结果及所述物理资源的利用率调整所述网络实体中子进程的数量。因此，证据3没有公开上述区别特征。
同时，目前也没有证据表明上述区别特征属于本领域公知常识。权利要求1的技术方案中，根据网络实体当前物理资源的利用率、需要的业务负荷以及所述网络实体中当前运行的全部或部分子进程的总负荷大小三个系统参数，动态创建或终止实体中运行的子进程，从而使子进程的负荷与业务负荷需求相适应，解决了优化通信系统，充分利用系统资源，提高系统业务处理能力的技术问题，能够获得最大限度满足业务负荷需求同时确保系统资源利用率达到最佳水平的有益技术效果。因此，权利要求1相对于证据1与证据2的结合、或者证据1与证据7的结合、或者证据1与证据9的结合、或者证据1与证据3、以及证据2、证据7或证据9的结合或者上述证据结合的基础上进一步与公知常识的结合具有突出的实质性特点和显著的进步，具备专利法第22条第3款规定的创造性。
另外，请求人在评述从属权利要求2时还进一步引用了证据4或证据8，评述从属权利要求4时进一步引用了证据5或证据6，评述从属权利要求5和6时进一步引用了证据8。
证据4公开了（参见证据4全文，特别是其说明书第4-5页）获取机群系统过去预定时间内的平均进程数、CPU利用率、内存使用率等作为负载平衡指标，以评价机群系统的负载情况。
可见，证据4没有公开获取需要的业务负荷，比较所述业务负荷与所述网络实体中当前运行的全部或部分子进程的总负荷大小，根据比较结果及所述物理资源的利用率调整所述网络实体中子进程的数量，即没有公开上述区别特征。
证据5（参见证据5中文译文说明书全文，特别是第4-5栏，图5）公开了：当CPU占用率小于CPU参考值（相当于物理资源的利用率小于预定的最佳利用率），对抑制的呼叫进行处理，而当CPU占用率大于CPU参考值（相当于物理资源的利用率大于预定的最佳利用率），将负载释放计数设置为0，不对呼叫进行处理。
可见，证据5没有公开获取需要的业务负荷，比较所述业务负荷与所述网络实体中当前运行的全部或部分子进程的总负荷大小，根据比较结果及所述物理资源的利用率调整所述网络实体中子进程的数量，即没有公开上述区别特征。
证据6（参见证据6中文译文说明书全文，特别是图2及说明书第0038段）：将60份80％的范围作为最优利用范围，并将其作为判断条件分别处理（图2中的100）。
可见，证据6没有公开获取需要的业务负荷，比较所述业务负荷与所述网络实体中当前运行的全部或部分子进程的总负荷大小，根据比较结果及所述物理资源的利用率调整所述网络实体中子进程的数量，即没有公开上述区别特征。
证据8（参见证据8全文，特别是第10.6和10.7节）：在停止进程之前执行相应的清理工作，以保证文件或任务的一致性。通过TOP命令获取系统的CPU状况及剩余的内存等物理资源利用情况。通过TOP命令获取各个进程的状态包括，PRI（priority优先级）和NI（NIZE值）。
可见，证据8没有公开获取需要的业务负荷，比较所述业务负荷与所述网络实体中当前运行的全部或部分子进程的总负荷大小，根据比较结果及所述物理资源的利用率调整所述网络实体中子进程的数量，即没有公开上述区别特征。
因此，即使在请求人提出的权利要求1不具备创造性的证据组合方式的基础上再结合证据4或证据5或证据6或证据8，也不能显而易见地得到权利要求1保护的方案。在权利要求1相对于上述证据组合方式具备创造性的基础上，从属权利要求2-6也具备专利法第22条第3款规定的创造性。
2、权利要求7保护一种网络进程管理装置，参见上述关于权利要求1的评述，权利要求7保护的技术方案与证据1相比，二者的区别特征是：（1）权利要求7中物理资源的利用率包括物理资源的平均负荷及可用的物理内存总量；（2）权利要求7中还包括子进程负荷统计单元，用于统计所述网络实体中当前运行的所有子进程负荷，比较单元，用于对所述业务负荷与所述网络实体中所有子进程负荷进行比较，得到比较结果，子进程调整单元，用于根据所述比较结果及所述当前物理资源的利用率调整所述网络实体中子进程的数量。基于上述区别特征，可以确定权利要求7相对于证据1实际解决的技术问题是：以何种系统参数表示物理资源的利用率以及如何满足业务负荷需求的同时提高系统资源利用率。
对于区别特征（1），参见上述评述，证据4（参见证据4全文，特别是说明书第4-5页）公开了可以将物理资源的平均负荷和可用物理内存作为物理资源利用率的参数，上述特征在证据4中所起的作用与其在本专利中所起的作用相同，都是为了确定以何种系统参数表示物理资源的利用率，证据4给出了将其技术手段应用于证据1的技术启示。
对于区别特征（2），参见上述评述，证据2、证据7、证据9均未公开上述区别特征，同时，目前也没有证据表明上述区别特征属于本领域公知常识。权利要求7的技术方案中，根据网络实体当前物理资源的利用率、需要的业务负荷以及所述网络实体中当前运行的全部或部分子进程的总负荷大小三个系统参数，动态创建或终止实体中运行的子进程，从而使子进程的负荷与业务负荷需求相适应，解决了优化通信系统，充分利用系统资源，提高系统业务处理能力的技术问题，能够获得最大限度满足业务负荷需求同时确保系统资源利用率达到最佳水平的有益技术效果。因此，权利要求7相对于上述证据组合方式具有突出的实质性特点和显著的进步，具备专利法第22条第3款规定的创造性。
另外，请求人在评述从属权利要求8时还进一步引用了证据5或证据6，评述从属权利要求9时进一步引用了证据8，参见上述评述，证据5、证据6、证据8均未公开上述区别特征。因此，即使在请求人提出的权利要求7不具备创造性的证据组合方式的基础上再结合证据5或证据6或证据8，也不能显而易见地得到权利要求7保护的方案。
在权利要求7相对于上述证据组合方式具备创造性的基础上，从属权利要求8和9相对于上述证据组合方式也具备专利法第22条第3款规定的创造性。
因此，请求人提出的本专利权利要求1-9不具备创造性，不符合专利法第22条第3款的规定的无效理由不能成立。
综上所述，请求人提出的全部无效理由均不成立，合议组作出如下决定。
三、决定
维持200610168028.1号发明专利权有效。
当事人对本决定不服的，可以根据专利法第46条第2款的规定，自收到本决定之日起三个月内向北京知识产权法院起诉。根据该款的规定，一方当事人起诉后，另一方当事人作为第三人参加诉讼。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
