中国科学院计算技术研究所与国家知识产权局专利复审委员会发明专利申请驳回复审行政纠纷上诉案

中国科学院计算技术研究所与国家知识产权局专利复审委员会发明专利申请驳回复审行政纠纷上诉案 北京市高级人民法院 行政判决书 (2015)高行终字第356号 上诉人（原审原告）中国科学院计算技术研究所，住所地北京市海淀区某地。 法定代表人孙某，所长。 委托代理人梁某。 被上诉人（原审被告）国家知识产权局专利复审委员会，住所地北京市海淀区某地银谷大厦10-12层。 法定代表人张某，副主任。 委托代理人黄某。 委托代理人曹某。 上诉人中国科学院计算技术研究所（甲公司）因发明专利申请驳回复审行政纠纷一案，不服北京市第一中级人民法院（2014）一中知行初字第4222号行政判决，向本院提起上诉。本院于2015年1月7日受理后，依法组成合议庭审理了本案。本案现已审理终结。 北京市第一中级人民法院经审理查明：本申请为申请号为200910092802.9，名称为“业务流程间的不匹配交互的发现方法”的发明专利申请。乙公司，申请日为2009年9月8日，公开日为2010年2月17日。 针对本申请，国家知识产权局原审查部门于2011年12月22日作出驳回决定。驳回的理由是：权利要求1、11请求保护的方案不属于技术方案，不符合《专利法》第二条第二款的规定。基于类似的理由，从属权利要求2-10、12-14请求保护的方案同样不属于技术方案，不符合《专利法》第二条第二款的规定。 丙公司不服上述驳回决定，于2012年3月22日向国家知识产权局专利复审委员会（简称专利复审委员会）提出复审请求，并修改了权利要求，修改后的权利要求如下： “1.一种业务流程间的不匹配交互的发现方法，包括： 步骤1）、从多个待处理的业务流程中选取两个业务流程，所选取的业务流程将对不参与业务流程间交互的活动进行约简，得到约简后的业务流程； 步骤2）、根据所选取的任一业务流程内参与交互的两个活动间的关系确定活动所在交互对在该业务流程内的关系，进而得到所选取的两个业务流程所含交互的交互对间关系集合；其中， 所述交互对间关系集合包括所述交互对在所选取的两个业务流程内的关系；所述活动间的关系包括顺序前、顺序后、并行、完全互斥以及部分互斥； 步骤3）、根据所述交互对间关系集合中所包含的存在矛盾的交互对间关系确定所选取的两个业务流程内存在矛盾的交互对，从而生成所选取的两个业务流程的完整矛盾交互集合。 2.根据权利要求1所述的业务流程间的不匹配交互的发现方法，其特征在于，所述的所选取的业务流程中不参与业务流程间交互的活动包括： a、不发送消息或者接受消息的任务类型的活动； b、中间事件类型的活动； c、内容为空的网关对。 3.根据权利要求1所述的业务流程间的不匹配交互的发现方法，其特征在于，还包括： 步骤4）、根据所述的完整矛盾交互集合计算最小消解集合；所述最小消解集合能够推导出所述的完整矛盾交互集合，且所包含的矛盾交互对的个数最小。 4.根据权利要求3所述的业务流程间的不匹配交互的发现方法，其特征在于，所述的步骤4）包括： 步骤4-1）、初始化最小消解集合为空； 步骤4-2）、选择矛盾交互集合中的一个交互对（i1，i2）； 步骤4-3）、若存在交互x，使得i1与x之间的关系同时为顺序前或同时为顺序后或同时为并行，并且交互对（i2，x）已经存在于最小消解集合中，则交互对（i1，i2）不加入所述的最小消解集合，否则加入所述最小消解集合； 步骤4-4）、从步骤4-2）开始重复执行，直至遍历完整矛盾交互集合中的所有交互对。 5.根据权利要求1或3所述的业务流程间的不匹配交互的发现方法，其特征在于，还包括： 步骤5）、合并两个业务流程，然后将合并后的业务流程与其它业务流程作为所选取的两个业务流程，重新执行步骤1）后的操作，直至不再有未经处理的业务流程，从而实现多个业务流程间不匹配交互的发现。 6.根据权利要求5所述的业务流程间的不匹配交互的发现方法，其特征在于，在所述的步骤5）中，所述的合并两个业务流程包括将已经得到完整矛盾交互集合的两个业务流程进行合并。 7.根据权利要求6所述的业务流程间的不匹配交互的发现方法，其特征在于，所述的将已经得到完整矛盾交互集合的两个业务流程进行合并包括： 步骤5-1）、选择其中的一个作为目标流程，另外一个业务流程作为输入流程； 步骤5-2）、将所述输入流程中除了开始活动、结束活动以及交互对方已经存在于所述目标流程中的活动外的每一个活动都被加入所述目标流程中； 步骤5-3）、将所述输入流程中除了连接开始活动和结束活动的迁移以外的每一个迁移添加到所述目标流程中，如果新加入的迁移所连接的活动没有加入到所述目标流程中，则将该迁移连接原活动的交互对方。 8.根据权利要求1或3或5所述的业务流程间的不匹配交互的发现方法，其特征在于，在所述的步骤3）中，所述的存在矛盾的交互对间关系包括：“顺序前”和“完全互斥”、“顺序后”和“完全互斥”、“顺序前”和“部分互斥”、“顺序后”和“部分互斥”、“并行”和“部分互斥”、“顺序前”和“顺序后”、“完全互斥”和“并行”。 9.根据权利要求8所述的业务流程间的不匹配交互的发现方法，其特征在于，当交互对间关系为下列之一时，所述交互对发生“死锁”：“顺序前”和“完全互斥”、“顺序后”和“完全互斥”、“顺序前”和“部分互斥”、“顺序后”和“部分互斥”、“并行”和“部分互斥”、“顺序前”和“顺序后”； 当交互对间关系为“完全互斥”和“并行”时，所述交互对发生“缺乏同步”。 10.一种业务流程间的不匹配交互的发现装置，其特征在于，包括业务流程选择模块、业务流程约简模块、交互对间关系集合生成模块、完整矛盾交互集合生成模块；其中， 所述的业务流程选择模块用于从多个待处理的业务流程中选取两个业务流程； 所述的业务流程约简模块，用于对不参与业务流程间交互的活动进行约简； 所述的交互对间关系集合生成模块用于根据所选取的任一业务流程内参与交互的两个活动间的关系确定活动所在交互对在该业务流程内的关系，进而得到所选取的两个业务流程所含交互的交互对间关系集合；其中， 所述交互对间关系集合包括所述交互对在所选取的两个业务流程内的关系；所述活动间的关系包括顺序前、顺序后、并行、完全互斥以及部分互斥； 所述的完整矛盾交互集合生成模块用于根据所述交互对间关系集合中所包含的存在矛盾的交互对间关系确定所选取的两个业务流程内存在矛盾的交互对，从而生成所选取的两个业务流程的完整矛盾交互集合。。 11.根据权利要求10所述的业务流程间的不匹配交互的发现装置，其特征在于，还包括最小消解集合计算模块；该模块用于根据所述的完整矛盾交互集合计算最小消解集合；所述最小消解集合能够推导出所述的完整矛盾交互集合，且所包含的矛盾交互对的个数最小。 12.根据权利要求10或11所述的业务流程间的不匹配交互的发现装置，其特征在于，还包括业务流程合并模块；该模块用于合并两个业务流程。” 经形式审查合格后，专利复审委员会于2012年5月9日依法受理了该复审请求，并将其转送至实质审查部门进行前置审查。实质审查部门在前置审查意见书中坚持原驳回决定。 专利复审委员会经过审查，于2013年12月20日作出的第61110号复审请求审查决定（简称被诉决定）。该决定中认定： 一、审查文本的认定 被诉决定所依据的审查文本与复审通知书所依据的审查文本相同，即为：申请日2009年9月8日提交的说明书第1-12页、说明书附图第1-4页、说明书摘要、摘要附图；2012年3月22日提交的权利要求第1-12项。 二、关于《中华人民共和国专利法》（简称《专利法》）第二条第二款 1、权利要求1要求保护一种业务流程间的不匹配交互的发现方法。 在本申请的背景部分公开了以下内容（参见说明书第1页第3段至第2页第1段）：业务流程可以采用业务流程建模标记（BusinessProcessModelNotation，BPMN）来建模。BPMN是由OMG组织制定的业务流程建模的标准，它由一系列用来构建业务流程的标准图标组成，且不与任何一种实现技术紧密耦合。BPMN不仅能够实现单个业务流程建模，而且能够实现多流程和它们之间交互的建模。目前已存在很多致力于发现业务流程间交互的不匹配的方法。Petri网和有限状态自动机等形式化方法都可用来验证流程间的匹配性。使用Petri网的方法是将每一个业务流程转换为一个Petri网，然后将流程间的交互转化为库所（place），最后将多流程之间的交互不匹配的发现问题转换为一个多流程合并后的大流程内部的正确性问题。现有的发现业务流程间交互不匹配的方法，存在以下缺点：发现过程繁琐、耗时；没有考虑运行时的特征；不能准确定位具体是哪些交互造成了流程间交互的不匹配。由此可知，权利要求1的方案所实际要解决的问题在于，如何利用建模算法获取业务流程间的交互冲突，并对业务流程进行调整。由于该方法中的业务流程、流程间交互的活动、交互对间的关系集合等仅具有虚拟的、抽象的、非技术性的含义，该方法也未被用于特定的技术领域，因此权利要求1的方案并未解决技术问题。 为了解决上述问题，权利要求1的方案所采用的手段是：基于人为预设的运算准则，对这些虚拟的业务流程中的不同活动之间的关系进行分析、归类和调整，其中对该业务流程模型中各种活动的分析和处理操作仅是基于单纯的抽象的人为规定，并未遵循自然规律，因此权利要求1所采用的手段并不属于技术手段。 实施该方案所能够获得的效果，也仅是能够发现虚拟的业务流程模型中的不匹配并加以调整，由于处理的仅是抽象的模型部件，不是外部技术数据，因此无法获得对外部技术数据进行技术处理的技术效果，即权利要求1的方案无法获得技术效果。可见，权利要求1请求保护的方案不属于技术方案，不符合《专利法》第二条第二款的规定。 2、权利要求2为从属权利要求，其对权利要求1的方案作了进一步限定，其具体限定了该业务流程模型中不参与交互的活动的类型，但是这属于单纯的人为规定。因此，权利要求2的方案也未解决技术问题，未利用技术手段，未获得技术效果。因此权利要求2不属于技术方案，不符合《专利法》第二条第二款的规定。 3、权利要求3为从属权利要求，其对权利要求1的方案作了进一步限定，权利要求4为从属权利要求，其对权利要求3的方案作了进一步限定，其限定内容均涉及对业务流程模型的交互对按照人为预先设定的处理算法执行相关处理。因此，权利要求3、4的方案也未解决技术问题，未利用技术手段，未获得技术效果。因此权利要求3、4不属于技术方案，不符合《专利法》第二条第二款的规定。 4、权利要求5-7为从属权利要求，其限定部分对如何实现两个业务流程的合并操作作了具体限定。但是上述合并操作同样仅是基于人为预先设定的处理算法和步骤执行的。因此，权利要求5-7的方案也未解决技术问题，未利用技术手段，未获得技术效果。因此权利要求5-7不属于技术方案，不符合《专利法》第二条第二款的规定。 5、权利要求8、9为从属权利要求，其限定部分对存在矛盾的交互对间关系进行了具体规定，并基于上述关系设定了发生“死锁”和“缺乏同步”的条件。上述内容均仅仅是人为预先设定的条件和分类规则。因此，权利要求8、9的方案也未解决技术问题，未利用技术手段，未获得技术效果。因此权利要求8、9不属于技术方案，不符合《专利法》第二条第二款的规定。 6、权利要求10要求保护一种业务流程间的不匹配交互的发现装置。 在本申请的背景技术部分公开了以下内容（参见说明书第1页第3段至第2页第1段）：业务流程可以采用业务流程建模标记（BusinessProcessModelNotation，BPMN）来建模。BPMN是由OMG组织制定的业务流程建模的标准，它由一系列用来构建业务流程的标准图标组成，且不与任何一种实现技术紧密耦合。BPMN不仅能够实现单个业务流程建模，而且能够实现多流程和它们之间交互的建模。目前已存在很多致力于发现业务流程间交互的不匹配的方法。Petri网和有限状态自动机等形式化方法都可用来验证流程间的匹配性。使用Petri网的方法是将每一个业务流程转换为一个Petri网，然后将流程间的交互转化为库所（place），最后将多流程之间的交互不匹配的发现问题转换为一个多流程合并后的大流程内部的正确性问题。有限状态自动机的方法将流程间的一次交互当作总是能够正确完成的。现有的发现业务流程间交互不匹配的方法，存在以下缺点：发现过程繁琐、耗时；没有考虑运行时的特征；不能准确定位具体是哪些交互造成了流程间交互的不匹配。由此可知，权利要求10的方案所实际要解决的问题在于，如何利用建模算法获取业务流程间的交互冲突，并对业务流程进行调整。由于该方法中的业务流程、流程间交互的活动、交互对间关系集合等仅具有虚拟的、抽象的、非技术性的含义，该方法也未被用于特定的技术领域，因此权利要求10的方案并未解决技术问题。 该方案所采用的手段是：基于人为预设的运算准则，对这些虚拟的业务流程中的不同活动之间的关系进行分析、归类和调整，其中对该业务流程模型中各种活动的分析和处理操作仅是基于单纯的抽象的人为规定，并未遵循自然规律，因此权利要求10所采用的手段并不属于技术手段。 实施该方案所能够获得的效果，也仅是能够发现虚拟的业务流程模型中的不匹配并加以调整，由于处理的仅是抽象的模型部件，不是外部技术数据，因此无法获得对外部技术数据进行技术处理的技术效果，即权利要求10的方案无法获得技术效果。 可见，权利要求10请求保护的方案不属于技术方案，不符合《专利法》第二条第二款的规定。 7、权利要求11为从属权利要求，其对权利要求10的方案作了进一步限定，权利要求12为从属权利要求，其对权利要求10或11的方案作了进一步限定。上述限定内容具体限定了执行最小消解集合计算操作以及业务流程合并操作的模块的具体功能。但是上述最小消解集合计算操作以及合并操作，同样仅是基于人为预先设定的处理算法和步骤执行的。因此，权利要求11、12的方案也未解决技术问题，未利用技术手段，未获得技术效果。因此权利要求11、12不属于技术方案，不符合《专利法》第二条第二款的规定。 三、丁公司的相关意见陈某 丙公司在答复复审通知书时提出的意见陈某，专利复审委员会认为：（1）说明书关于权利要求1的方案的相关描述，仅仅是关注于业务流程模型内部各个部分之间抽象的相互关系，并基于这些相互关系制定了业务流程模型的内部运行规则，这些规则实质上仅仅属于抽象的数学运算规则，并未应用于具体技术领域。即使如申请人所述，业务流程模型中的活动，都代表着诸如下订单、电子支付、物料、生产、组装、配送环节等具体的企业生产、销售活动及行为，但是这也从另一方面说明，本申请的方案，解决的是涉及企业生产、销售活动等事务流程管理领域的问题，这并非专利法意义上的技术问题。（2）本申请所采用的模型分析的算法，虽然利用了公知的计算机硬件设备来实现，但是这一实现过程仅利用了公知计算机硬件设备的固有的、公知的属性（能够进行运算处理），实质上仅仅是将人为制定的企业事务流程管理规则抽象化、虚拟化为人为预定的数学算法，并利用计算机的运算处理功能实现。上述过程并未给该公知的计算机硬件设备带来任何技术上的改进，也没有给该计算机硬件设备的内部或外部性能带来任何改变。也即，本申请对业务流程中的不同事务活动之间的关系进行分析、归类和调整，将其抽象化为对业务流程模型的各种运算规则，其中对该业务流程模型中各种活动的管理、分析和处理操作仅是基于单纯的人为规定，并利用公知的计算机硬件来实现。上述过程并未遵循自然规律，并不构成技术手段。（3）本申请的方案虽然能够快速发现业务流程之间的冲突，相对于人为的管理流程而言提高了效率，能够使得企业的生产经营活动高效、顺利的执行，但这种效果的产生，首先是基于人为制定的与企业生产经营流程相关的事务流程管理规则的改变，其次还利用了公知的计算机硬件的固有的、公知的计算属性加以实现，因此本申请的方案虽然能够获得提高管理效率的效果，但这样的效果不是通过直接利用自然规律获得的，不属于专利法意义上的技术效果。 综上，专利复审委员会作出被诉决定：维持国家知识产权局于2011年12月22日对本申请作出的驳回决定。 北京市第一中级人民法院认为： 一、关于法律适用 于2008年12月27日修改的《专利法》（简称2009年《专利法》）已于2009年10月1日起施行，因此本案审理涉及2001年《专利法》与2009年《专利法》之间的选择适用问题。依据《中华人民共和国立法法》第八十四条的规定，参照国家知识产权局《施行修改后的专利法的过渡办法》的规定，本申请的申请日在2009年10月1日前，因此应适用2001年《专利法》以及修改前《中华人民共和国专利法实施细则》（简称《专利法实施细则》）进行审理。被诉决定适用2009年《专利法》第二条第二款的内容进行审查有误，予以纠正。但鉴于该款内容与修改前《专利法实施细则》第二条第一款的内容一致，因此该法律法规适用不当对本案结果不产生实质影响，法院适用修改前《专利法实施细则》第二条第一款的规定对本案进行审理。 二、本申请是否符合修改前《专利法实施细则》第二条第一款的规定 本申请权利要求1要求保护业务流程间的不匹配交互的发现方法，该方法首先从多个待处理的业务流程中选取两个业务流程，并对不参与业务流程间交互的活动进行约简，其次确定活动所在交互对在该业务流程内的关系，进而得到所选取的两个业务流程所含交互的交互对间关系集合，最后根据交互对间关系集合中所包含的存在矛盾的交互对间关系确定所选取的两个业务流程内存在矛盾的交互对，生成所选取的两个业务流程的完整矛盾交互集合。该方案中处理对象是业务流程，而业务流程本身并未结合具体的技术领域，是一个抽象概念，不具有技术性含义。对业务流程交互关系所进行的简化、分析、归纳以及调整是在人为设定规则的基础上完成的，属于单纯的人为规定，并未遵循自然规律。只有当抽象的业务流程分析过程与具体技术领域联系起来，应用于实际生产流程当中，上述人为规定才有可能符合自然规律，解决技术问题。然而，本申请权利要求1中业务流程间不匹配交互的发现方法并未反映实际生产流程，仅仅是抽象的人为设定，并不属于技术手段。 根据本申请背景技术部分公开的内容，本申请所要解决的问题在于“克服现有的业务流程间不匹配交互发现方法过程繁琐、耗时，不能发现业务流程在运行时的不匹配交互以及不能准确指出哪些交互造成了流程间交互的不匹配等缺陷”。尽管本申请权利要求1所述方案能够解决上述问题，但由于该方案本身是对抽象思维的概括，抽象思维活动本身并不能解决实际的技术问题。实施该方案所能获得的“简便、高效、功能全面”的效果，不是对具体技术数据进行技术处理的技术效果。因此，本申请权利要求1所采取的方案未采用技术手段解决技术问题并达到技术效果，不满足技术方案的构成条件，被诉决定关于本申请权利要求1的方案不属于修改前《专利法实施细则》第二条第一款规定的技术方案的认定，并无不当，应予支持。 本申请从属权利要求2-9对权利要求1要求保护的系统进行了进一步的限定，权利要求2具体限定业务流程中不参与业务流程间交互的活动，权利要求3、4具体限定如何根据完整矛盾交互集合计算最小消解集合，权利要求5-7具体限定如何实现两个业务流程的合并操作，权利要求8、9具体限定存在矛盾的交互对间关系。上述从属权利要求2-9的限定内容均是对业务流程交互处理算法的人为规定，没有结合具体应用领域，其要求保护的方案的整体仍然是一种抽象的处理方法，因此被诉决定关于从属权利要求2-9所要求保护的方案未采用技术手段、解决技术问题并且达到技术效果，因此也不属于修改前《专利法实施细则》第二条第一款规定的技术方案的认定，并无不当，应予支持。 本申请权利要求10-12要求保护一种业务流程间的不匹配交互的发现装置，其包括业务流程选择模块、业务流程约简模块、交互对间关系集合生成模块、完整矛盾交互集合生成模块、最小消解集合计算模块以及业务流程合并模块。权利要求10-12中的功能模块分别与权利要求1、3、5所述方法步骤一一对应，属于与权利要求1、3、5所述方法对应的装置权利要求。基于与权利要求1、3、5相类似的理由，其所采取的手段、所解决的问题和达到的效果均是非技术性的，被诉决定关于本申请权利要求10-12的方案不属于修改前《专利法实施细则》第二条第一款规定的技术方案的认定并无不当，应予支持。 综上所述，专利复审委员会作出的被诉决定虽然存在瑕疵，但审理程序合法、审查结论正确。丙公司的诉讼请求不能成立，不予支持。依照最高人民法院《关于执行〈中华人民共和国行政诉讼法〉若干问题的解释》第五十六条第（四）项之规定，判决驳回中国科学院计算技术研究所的诉讼请求。 丙公司不服原审判决向本院提出上诉，请求撤销原审判决和专利复审委员会第61110号决定，责令专利复审委员会重新作出复审决定。丙公司主要的上诉理由是：本技术方案中的业务流程具体是指通过业务流程建模工具，基于业务建模语言，建模得到的具体业务流程模型，其中每个具体活动是实际生产流程中具体的活动，能够产生实际的客观效果。本发明属于技术问题：第一，业务流程建模语言是一种客观存在；第二，业务流程建模结果具有客观性；第三，业务流程建模存在着一系列工具的支持。综上，本发明要解决的业务流程问题属于技术问题，所采用的技术手段也是符合自然规律的，不是人为制定的抽象规则，是专利法保护的客体。专利复审委员会服从原审判决。 本院经审理查明，原审判决查明事实清楚，证据采信得当，且有国家知识产权局驳回决定书、专利复审委员会审查本案时所依据的本申请文本、专利复审委员会复审通知书、丙公司在复审阶段提交的意见陈某书、在诉讼程序中提交的补充证据及当事人陈某等证据在案佐证，证据充分，本院对原审法院查明的事实予以确认。 本院认为，本案争议的焦点在于本发明专利申请所要保护的方案是否属于技术方案，能否构成专利法保护的客体。如果一项权利要求要求保护的方案未解决技术问题，未利用技术手段，也未获得技术效果，则该项权利要求所要求保护的方案不属于技术方案，不符合《专利法》的相关规定。一般而言，技术方案应具备技术手段、技术问题和技术效果等要素。技术方案是对要解决的技术问题所采用的利用了自然规律的技术手段的集合，未采用技术手段解决技术问题，以获得符合自然规律的技术效果的方案，不属于《专利法》保护的客体。本发明专利申请权利要求1要求保护业务流程间的不匹配交互的发现方法，该方法首先从多个待处理的业务流程中选取两个业务流程，并对不参与业务流程间交互的活动进行约简，其次确定活动所在交互对在该业务流程内的关系，进而得到所选取的两个业务流程所含交互的交互对间关系集合，最后根据交互对间关系集合中所包含的存在矛盾的交互对间关系确定所选取的两个业务流程内存在矛盾的交互对，生成所选取的两个业务流程的完整矛盾交互集合。说明书关于权利要求1的方案的相关描述，仅仅是关注于业务流程模型内部各个部分之间抽象的相互关系，并基于这些相互关系制定了业务流程模型的内部运行规则，这些规则实质上仅仅属于抽象的数学运算规则，并未应用于具体技术领域。本发明专利申请权利要求1要求保护方案的处理对象是业务流程，而业务流程本身并未结合具体的技术领域，是一个抽象概念，不具有技术性含义。对业务流程交互关系所进行的简化、分析、归纳以及调整是在人为设定规则的基础上完成的，属于单纯的人为规定，并未遵循自然规律。因此，本申请权利要求1所采取的方案未采用技术手段解决技术问题并达到技术效果，不满足技术方案的构成条件。基于同样的理由，本发明专利申请权利要求2-9以及10-12所要求保护的方案，也不属于技术方案，不符合《专利法》的规定。 综上，丙公司的上诉主张缺乏事实及法律依据，其上诉请求本院不予支持。原审判决认定事实清楚，适用法律正确，依法应予维持。依据《中华人民共和国行政诉讼法》第六十一条第（一）项之规定，判决如下： 驳回上诉，维持原判。 一、二审案件受理费各人民币一百元，均由中国科学院计算技术研究所负担（均已交纳）。 本判决为终审判决。 审　判　长　　刘继祥 审　判　员　　刘晓军 代理审判员　　周　波 二〇一五年五月十二日 书　记　员　　张见秋 本案法律依据 中华人民共和国专利法(2008修正) 第2条2款 施行修改后的专利法的过渡办法 中华人民共和国行政诉讼法(2014修正) 第61条 中华人民共和国立法法(2015修正) 第84条 最高人民法院关于执行《中华人民共和国行政诉讼法》若干问题的解释[失效] 第56条1款4项 中华人民共和国专利法实施细则(2002修订) 第2条1款