计算机软件类专利申请文件的撰写

算法专利本质上是方法专利,采用技术问题——技术方案——有益效果的思路写，即针对现有技术的编码算法存在哪些技术问题（例如解压缩时间长、压缩后的图像分辨率差），本发明提出了一种编码方法，这种编码方法是怎样的（压缩算法的流程），从而能够解决现有技术存在的技术问题，进而带来怎样的有益效果。

算法的专利是指它的实现，未具体实现的理论本身不可能取得专利，任何人都可以随便引用、阐述、公开。

还是采用技术问题——技术方案——有益效果的思路写，即针对现有技术的编码算法存在哪些技术问题（例如解压缩时间长、压缩后的图像分辨率差），本发明提出了一种编码方法，这种编码方法是怎样的（压缩算法的流程），从而能够解决现有技术存在的技术问题，进而带来怎样的有益效果。算法的专利本质上还是方法专利。

浅谈计算机软件类专利申请文件的撰写

文/集佳知识产权代理有限公司周嗣勇

随着计算机软件产业的迅速发展，计算机软件的专利权保护已经受到越来越多国家的重视。美国、欧盟、日本等软件发达国家相继确定了给予计算机软件的专利保护，我国也在专利局颁布的《审查指南》中对计算机软件专利进行了规定。尽管如此，现阶段我国对于软件类专利的申请还是有较大的限制，从主观因素考虑，审查员对于软件类专利申请的审查也相对“严格”。因此，与其他类型的专利申请文件相比，软件类专利申请文件在撰写方法上也有所区别。在本文中，笔者将结合自身的工作经验，对软件类专利申请文件撰写过程中需要特别注意的地方做一些简单介绍。

一、针对专利法第25条：

根据专利法第25条第二款的规定，对智力活动的规则和方法不授予专利权。这里所说的智力活动的规则和方法包括数学方法以及一切属于以人的抽象思维、主观意念或者感觉为特征的非技术方案。

首先应该注意的是主题的命名，应避免“程序”、“补丁”、“指令”、“算法”等形式的命名。尽管专利法第25条规定了一系列不属于专利保护的客体，但是在实际撰写中，该问题还是比较容易避免的。主要方法是在方案中增加技术特征，使方案的内容不仅限于程序或算法本身。

对于计算软件而言，比较常用的一种方法是，首先假设一个执行主体，该主体具有逻辑计算或判断等数据处理功能，然后基于这个执行主体，从“数据处理”的角度进行方法或装置权利要求的撰写。这类权利要求往往具有比较统一的模式，对于方法权项为“输入（接收）源数据—处理数据—输出（发送）结果”，相应对于产品权项为“输入（接收）模块—处理模块—输出（发送）模块”。在实际撰写中，“数据处理”往往是体现发明点的重要部分，需要重点描述，而根据方案的具体情况，在不影响整体方案的前提下，有时可以省略“输入（接收）”或“输出（发送）”方面的特征。有些时候，也有必要说明如何应用数据处理的结果来解决技术问题，例如基于程序或算法的控制方法等等。

一般来说，按照上述模式撰写的权利要求，由于涉及了“数据处理”这样的技术特征，因次就整体而言并不是智力活动规则或方法，这样就基本可以避免依据专利法第25条排除其获得专利权的可能性。

二、针对专利法实施细则第2条第2款：

针对专利法实施细则第2条第2款，在《审查指南》中有如下说明：技术方案是对要解决的技术问题所采取的利用了自然规律的技术手段的集合。未采用技术手段解决技术问题，以获得符合自然规律的技术效果的方案，不属于专利法实施细则第二条第二款规定的客体。

根据审查指南的上述规定，成为一项技术方案的标准是：同时具备技术手段、技术问题和技术效果三要素。可以看出，一个方案即使具备了技术特征，也不一定能够构成技术方案。因此，对于计算机软件而言，即使利用撰写技巧为方案添加了技术特征，该方案依然可能被认定为不属于技术方案。

一般的观点认为，是否构成技术方案，取决于方案本身。而事实上，审查员对于是否构成技术方案这个问题有很大程度上是基于主观的判断，这个判断的依据又很大程度来源于原申请文件的背景技术及有益效果部分，请看下面的一个案例：

一种更新帐户信息的系统，该系统包括分布于各个营业点的终端节点，用于接受客户的帐户信息。一个公共存储器，用于存储各个网点的帐户信息，当其中一个终端节点接受新的或更新的帐户信息时，该终端节点将该信息发送到该公共存储器，该公共存储器将该信息同时发送给整个系统的其他终端节点用于更新，使得其它终端节点的信息也能几乎同步地更新帐户信息。

在原申请文件的背景技术中，首先介绍了银行账户系统的现状，然后提出了现有技术无法存在及时更新账户信息的问题；在有益效果的描述中，也只是在介绍本发明能够实现同步更新账户信息的效果。审查员看过这样的描述之后，很容易在第一印象中就认为该方案属于解决的是商业问题，甚至可能在不仔细阅读具体实施方案的情况下，就直接以细则第2条第2款下发审查意见，导致申请在还没有考虑“新颖性”、“创造性”的问题的情况下，就已经被挡在了授权的大门之外。

实际上，上面的方案应该这样理解：现有技术的状况是每个终端节点的数据被逐个串行更新，因而导致其他节点没有得到及时更新而出错，而上述系统所解决的技术问题是如何快速地以并行方式更新网络系统中各个节点的数据，并且采用了增加公共存储器的技术手段，由此产生了使整个银行系统的运行性能得以改善的技术效果，因此此类系统属于可给予专利保护的客体。

可以肯定的是，如果在撰写的时候，能够将以上分析内容有选择地写入申请文件，那么审查员是不会轻易以细则第2条第2款下发审查意见的。当然，以上内容也可以在答复审查意见的过程中陈述，比较好的结果是审查员接受了意见陈述，并继续对原申请文件进行审查，但是，这样无形中增加了审查的周期，有可能直接影响到申请人的利益。还有一种更坏的结果是，审查员认为原申请文件中并没有记载相关的内容（如果对说明书进行修改又很可能不符合专利法第33条的规定），双方就主观认定的问题长期争执不下，无论申请最终是否能够得到授权，对于申请人以及代理人都会带来多方面的损失。

可见，对于说明书背景技术以及有益效果的描述也应该引起重视，下面做一些简单介绍： 1）背景技术部分：

应该尽量从技术角度方面描述现有技术的问题，很多时候，“商业问题”只是技术问题的一种表现形式，在说明商业问题的时候，完全可以从技术的角度分析其本质。

另一种比较大胆的方法是：在背景技术部分，直接从技术角度描述问题，而对商业问题避而不谈。相应地，在具体实施方式部分，再提到本发明的方案具体可以应用于解决某一实际的商业问题。同时，撰写独立权利要求的时候，也仅针对技术问题说明技术方案，将涉及商业方法的内容放入从权。

从另一个角度考虑，上述做法也可以在原有方案的基础上，争取一个更大的保护范围。当然相对而言，这样做也可能会产生其他的问题，例如，独权得不到说明书支持、独权缺乏新

颖性等等。对于得不到说明书支持的问题，需要注意在说明书中增加相对于独权的描述内容，并且可以考虑多增加一些具体实施方式，最好是能够解决非商业问题的实施方式，即便只是形式上的简单介绍，也可以说明方案的技术性；而对于缺乏新颖性的问题，在撰写过程中确实难以预测，但是，相信无论对于申请人还是代理人，答复新颖性问题要比答复是否技术方案的问题简单得多，更为重要的是：由于审查员在主观上已经认同独权构成技术方案了，那么，即使在答复过程中将涉及商业方法的从权内容补充到独权中，也不会影响独权方案的技术性。

2）有益效果部分：

这部分的描述应该相对于背景技术部分，如果背景技术部分提到了具体的商业问题，那么在说明有益效果的时候，除了说明本方案能够解决该商业问题之外，还要注意从技术的角度进行分析和推导，例如，前面的例子中，应该在有益效果中加入“以并行方式取代串行方式，因而改善了数据处理的性能”这样技术层面的说明；如果在背景技术部分没有提到具体的商业问题，那么同样在有益效果部分也不要提到与商业问题的相关的内容。当然这里说的有益效果特指在“发明内容”部分的有益效果，这部分有益效果是针对方案整体而言的。而解决商业问题的有益效果可以在具体的实施例中进行描述。

三、针对专利法第26条第4款：

相对于方法权利要求而言，产品的权利要求更便于举证，因此，在防止专利侵权方面，产品权利要求比方法权利要求更为有利。对于计算机软件类的专利，不涉及或很少涉及硬件上的变化或改进。尽管在说明书中详细介绍了有关方法的各个步骤，但是由于没有结合相关的硬件对产品权利要求中限定的产品进行说明，因此产品权利要求以说明书不支持为由导致驳回的情况很常见。

根据审查指南的规定，产品权利要求如果全部以计算机程序流程为依据，按照与该计算机程序流程的各步骤完全对应一致的方式，或者按照与反映该计算机程序流程的方法权利要求完全对应一致的方式，撰写装置权利要求，即这种装置权利要求中的各组成部分与该计算机程序流程的各个步骤或者该方法权利要求中的各个步骤完全对应一致，则这种装置权利要求中的各组成部分应当理解为实现该程序流程各步骤或该方法各步骤所必须建立的功能模块，由这样一组功能模块限定的装置权利要求应当理解为主要通过说明书记载的计算机程序实现该解决方案的功能模块构架，而不应当理解为主要通过硬件方式实现该解决方案的实体装置。

可见，只要在撰写申请文件时，注意采用“完全对应一致的方式”撰写产品权利要求，就可以有效避免说明书不支持的问题。如果申请人确实希望对执行程序的实体产品进行保护的时候，应该注意在说明书中从硬件实现的角度对产品进行说明。

以上对计算机软件类专利案可能涉及的几种常见问题进行了说明，建议大家在撰写的时候，能够预先对这些问题予以充分考虑，撰写出更高质量的申请文件，从而起到缩短审查周期或提高授权率的作用。