禁止软件专利的不可行性
作者:叶琏刚    本站发布时间:2003-5-18 10:21:03

是否允许计算机软件获取专利是近几年来世界专利界,IT界讨论很多的话题。在美国,软件“是否”可以获取美国专利几乎没有什么争论过。只要符合专利的三性,就可以获取专利权。软件专利只是方法专利中的一种。(98年STATE STREET一案并不是说从98年开始充许商业方法授予专利了,而是说美国专利法从来没有禁止过商业方法专利授权。)专利申请审查中,是否是软件不是审查的一个项目。一项专利申请与计算机软件相关与否,与其专利性没有关系。在美国专利界,现在讨论多的话题是如何改善授权软件专利的质量,使不符合专利三性的软件专利申请得不到授权,已授权的如何取销。

计算机软件的可专利性在中国还处于讨论阶段。下文要说的是:从目前的IT技术的发展情况看,尤其是集成电路的发展,软件硬件的差别已越来越小,现在已经几乎为零。如果硬件的可以授予专利,那么计算机软件专利不仅是可行的,而是必须的。因为硬件与软件是同样的东西。在允许计算机硬件获取专利的同时禁止计算机软件获取专利反而是不可行的。

下面的英文原文是一个与专利有关的BBS网上一篇文章的节选。文章从一项美国专利申请公告的分析开始,结合目前集成电路设计、制造的现状,提出计算机软件与硬件是等同的结论。

对计算机硬件的可专利性几乎没有人有异议。硬件是一些实实在在的电路板,实实在在的封装在塑料里的硅片。一小块硅片中可以有几百万个不同的电子元件,每一个元件,都是实实在在的工业零部件。独特的硬件,独特的集成电路可以受专利保护,几乎没有人会不同意。在美国是这样,在中国也是这样。(这个专利申请的公告号是:20020178285,可以用这个号到美国专利与商标局网站,www.uspto.gov查找申请书的全文,包括附图和权利要求。)

集成电路的专利性主要在于其电路的新式组合。电路中的所有部件,比如晶体管、电阻、电容、电感、接线等等都是众所周知的,没有什么特别。但是把这些普通的部件按一定的规则组合起来,就可以实现不一般的功能,可以实现以前人们想不到,做不到的事情。所以,集成电路可以有新颖性,创造性和实用性,可以授予专利。这种专利自从有集成电路、印刷电路板之后就有,没有什么稀奇,没有人会不同意授予它们专利。

集成电路的制造,很大程度是机械化,自动化大生产。集成电路生产设备在计算机程序的控制下,对标准的硅片进行标准的物理、化学处理,使其表面或机体中产生物理化学反应,按设计要求生成各种电子元部件,并按设计要求连接在一起。集成电路的生产过程中,几乎不需要人的介入。整个生产过程虽然很复杂,生产工厂及设略非常昂贵,但是整个过程是标准化的,没有任何特别。在世界集成电路市场上,有不少“皮包公司”,只管电路设计,不管集成电路的制造,也没有自己的集成电路制造工厂。集成电路制工厂往往需求巨额投资,风险很大,如果工厂开工不足,就很可能有巨额损失。

硅片上的各种元部件的产生都有标准的生产程序,按一个按钮,集成电路生产机器就在硅片上生成一个相应的元件。集成电路设计公司实际上就是一个编程序的公司,就是将设计的电路转换成控制生产机器用的程序,然后将这个程序交给集成电路制造工厂,就可以得到实实在在的集成电路。这个电路图可以是传统的线路图,也可以是“描述”这个线路图的“描述”程序。这个“描述”程序,可以用专用的描述语言写,也可用通用的语言写,比如用自然人用语言如英语,也可用计算机语言如C语言写等等。

集成电路芯片是地道的硬件,用C语言写的描述程序则是地道的软件,但两者所代表的东西却几乎是同一个东西。在现实生活中,两者的价值也几乎一样。芯片虽然有了一个实实在在的实体,其价值并不比空空的C语言程序多。芯片物理实体(载体)的价值与非实体的价值(程序)相比几乎为零。

专利法保护的是一种发明创造,是保护一种有价值的东西,这个东西可能可以用不同的语言来描述,比如可以是中文,也可以是英文,但不应该因为描述的方式不同而给予不同的保护,不能只保护中文写的权利要求而不保护英文写权利要求的。硬件专利权利要求与软件专利权利要求只是权利要求书写形式的不同,其要求保护的发明是同一件东西。下文中举的例子很好的展示了对同一发明,不同形式的权利要求。

从典型的软件专利权利要求过渡到典型的硬件专利权利要求,中间的权利要求介于两者这间:3,1,2,9,  7,8,6,10。

这些权利要求,相互之间没有专利上的差别,所以一个可以授权,另一个也应该可以授权。所以如果硬件专利权利要求是充许的,那么相应的软件专利权利要求就没有理由不充许。

所以在一个专利制度中,允许硬件专利授权而不允许软件专利授权是不可行的。

-----Original Message-----

From: clients@bustpatents.com [mailto:clients@bustpatents.com]

Sent: Tuesday, January 28, 2003 7:35 PM

To: srctran@bustpatents.com

Subject: PATNEWS: Good example of hardware/software (patenting) equivalences

!20030129  A good example of hardware/software (patenting) equivalences

(NOTE: This is the last week I will be sending out PATNEWS from the bustpatents.com domain.  Starting next week, I will be sending out PATNEWS from a new domain, patenting-art.com.  Most likely the address will be:  patnews@ns1.patenting-art.com.  Those of you with email filters, please keep this in mind.)

A patent application was recently published that is a good example of the equivalences and blurry boundaries of patenting hardware and software. The patent application in general is claiming methods for designing communication dataflow systems.  Let's look at the claims, with a few extra claims I have written:

   United States Patent Application       20020178285

   1.  A  method of modeling a dataflow architecture comprising the steps

   of:   storing  in  a  memory  indicia  representative  of  a  dataflow

   architecture   having   components  responsive  to  intercommunication

   protocols;  and  processing  conversions  among the intercommunication

   protocols  to  determine control structures required to implement said

   dataflow architecture.

   2.  A  method  as  recited  in  claim 1, wherein the indicia stored in

   memory and the control structures are translated into a description of

   an implementation of said dataflow architecture.

At this point, we just have a claim for some software to design a system. Now some might object to software patent claims such as these, preferring instead something physical to be patented, which indeed is what some of the next claims are claiming.

   6.  A  method  as  recited  in  claim  2,  where the description of an

   implementation is further translated into a physical implementation of

   the dataflow architecture.

Here is the "hardware" claim, since protecting the translation of something into a physical implementation is little different from protecting the physical implementation (though broader since there can be multiple translations from one description - this type of claim just avoids having to explicitly claim every such translation).  Given the long history of patenting hardware, i.e., something "physical", I don't think anyone will object to claim 6.

   7. A method as recited in claim 6, wherein the physical implementation

   is configuration data for a FPGA.

   8. A method as recited in claim 6, wherein the physical implementation

   is a layout for an Application Specific Integrated Circuit (ASIC).

Certainly FPGAs and ASICs are as physical an object as you can get and therefore patentable as devices.  Again, protecting the configuration data of a physical implementation is little different from protecting the physical implementation itself.  Now there are multiple "FPGAs" and "ASICs" from companies such as Xilink and Altera, so do we want to waste time and money having inventors claim every specific form of physical implementation?  I think not. Thus these general claims.  That we are concerned about physical devices is seen in claim 10:

   10. An apparatus resulting from the method recited in claim 2.

Claims 6, 7, 8 and 10, then, are claims for groups of hardware, with claim 10 being the smallest group, and claim 6 being the broadest group with subsets claims 7 and claim 8.  Hard to see why any one of these claims shouldn't be allowed if any of the others are allowed.  Patentability shouldn't rise or fall on how many boring variations of claims an inventor is willing to pay for.

Now, in the circuit design world, much money is made selling and licensing hardware descriptions in EDIF/VHDL/Verilog, often as much profit as selling the physical implementation.  Seems foolish to protect one form and not the other, if they are equally economically valuable and require the same amount of design and manufacturing effort to produce (that is, given the EDIF/VHDL/Verilog, you push a button to get the hardware). Which leads to claims 3, 4 and 5:

   3.  A  method  as  recited  in  claim  2,  where the description of an

   implementation is the EDIF netlisting language.

   4.  A  method  as  recited  in  claim  2,  where the description of an

   implementation is structural VHDL.

   5.  A  method  as  recited  in  claim  2,  where the description of an

   implementation is structural Verilog.

EDIF/VHDL/Verilog are hardware description languages, which some might not think of as programming languages for which such descriptions would be software.  But SystemC is an up-and-coming hardware description language very similar to the programming language C, and Ada is a programming language very similar to VHDL, while C can be used as a hardware description language in that there are tools for converting C directly into digital circuit specifications.  Assuming so, one more claim can be automatically derived:

   5.' A method  as  recited  in  claim  2, where the description of an

   implementation is System C, C or ADA.

To allow the patenting of any of these is to have to allow the patenting of all of them.

However, claims 3, 4, 5 and 6 form an equivalence class, the members being the phrases that start after the phrase "... where the description of an implementation ...", an equivalence class of things that have equal economic value, have equal production requirements, etc.  Not surprising that the inventors choose to claim them equally.  Now claim 6 is mostly "hardware-ish", claims 3, 4, and 5 are mostly "software-ish". Yet the inventors are putting them together in an equivalence class, a combination that seems quite reasonable.

The next claim to consider is where all of the boundaries get blurred:

   9. A method as recited in claim 6, wherein the physical implementation

   is object code for a general-purpose processor.

The inventors are creating another equivalence class here, comprising the a) physical implementation of an FPGA, b) the physical implementation of an ASIC, and c) the object code for a general-purpose processor. But this equivalence class has both hardware-hardware (FPGAs and ASICs) and some sort of software - the object code.

However "object code" in this context pretty much implies the existence of a processor, and ignoring (as we can in most implementations) the specific structure of the processor (its speed, word widths in bits, cache memory, etc.), we simplify claim 9 to:

   9'. A method as recited in claim 6, wherein the physical implementation

   is object code.

This might appear objectionable language, "Greg - object code isn't physical", but not to modern Landauer-ish physicists, to whom information is physical (an upcoming very long PATNEWS), and certainly object code is information.

Now object code is compiled source code, and given that "source code" implies something to be compiled, and not wanting to see a long and boring list of source code compilers (".. object code derived from a C compiler running on a Pentium .. object code derived from a Fortran compiler running on a Forth chip, etc.), we can simplify claim 9' to:

   9'. A method as recited in claim 6, wherein the physical implementation

   is source code.

I.e., software.  Software/source code - both information - both physical, making the transition to claim 9' quite reasonable in the chain of all of these transformations.

Software descriptions that are not novel, obvious to a toadstool, and/or not enabled?  Fine, deny the patent - I will be the first to support not granting patents for such specifications (and I wish it was done a lot more often).  But don't deny the patent on a software description by pretending you can draw the line in the above claims (at least while sober).

Greg Aharonian

Internet Patent News Service

( 说明:文中的观点或信息与本网站主办单位无关)