特許法によるソフトウェア保護の実効性（1991年９月「パテント」誌掲載）
目 次
１．はじめに
２．ソフトウェア保護における著作権法、トレードシークレット法、特許法の関係
３．プログラムを格納したＦＤ等の「イ号能力」
４．通信手段を介して販売・リースされるプログラムの「イ号能力」（「イ号能力」の水平方向の限界）
５．ソースプログラム、詳細フローチャート、設計仕様書を格納したＦＤ等の「イ号能力」（「イ号能力」の垂直方向の限界）
６．終わりに
１．はじめに
近年コンピュータ・ソフトウェアの特許、およびその特許出願が急増している。特許庁での平成４年からのソフトウェア発明の審査基準の緩和などを受けて、ソフトウェア特許出願で先行した大手企業に続き独立系ソフトハウスなど中小グループでも、ソフトウェアの特許による権利化を図る動きが急増している（関連記事、平成３年５月２７日付日経産業新聞「ビジネスＴＯＤＡＹ」）。
一方、平成３年３月に岡山市の特許管理会社が自社所有のパソコンソフトの特許権（「財務・在庫等の管理のための装置」）の侵害を理由に富士通や１１社のソフトハウスを東京地裁に訴えた（「イエス事件」）が、今後はソフトウェア特許権の侵害係争が急増することが予想される。このような侵害係争では、ソフトウェア特許の実際上の有効性が裁判等で正面から問われることになる。
しかし、このソフトウェア特許が現在のおよび将来の実際の侵害係争の中で、実際の侵害行為形態に対して有効に機能するかどうかについては、以下のような多くの問題がある。
２．ソフトウェア保護における著作権法、トレードシークレット法、特許法の関係
本論に入る前に、まずソフトウェア保護における著作権法やトレードシークレット法（不正競争防止法第２条第１項４～９号）と特許法との関係を、図１を参照してざっと概観しておこう。
（１）著作権法によるソフトウェア保護の範囲
図１の実線Ａで示す部分は、システム開発過程で得られる主な成果物を開発過程のレベルに沿って示したものである（この図では、知的財産権の観点から重要と思われる成果物のみを抽出しており、デバッグやテストなどの工程は捨象している）。
この実線Ａで示す部分のうち、実際にＦＤ等に格納されてシステム製品の一部として流通するのは、最下位レベルのオブジェクトプログラム（符号１で示す）である。
ところで、このオブジェクトプログラム１は「プログラムの著作物」（著作権法１０条１項９号）であるソースプログラムａの複製物である（東京地裁昭和６２年１月３０日判決）。
したがって、無権原の第三者が、この実際に流通するオブジェクトプログラム１を類似のオブジェクトプログラム２に改変する行為（図１の符号αで示す行為）は、ソースプログラムａの「複製」または「翻案」として、著作権侵害となる。なお「複製」か「翻案」かは、その改変により創作性が付加されたかどうかによるが、いずれにしても著作権侵害となることに変わりはない（ただ翻案とされると、侵害者である翻案者自身に二次的著作物の権利が発生する）。
また、このオブジェクトプログラム１をソースプログラムａに変換することも「複製」となる。したがって、無権原の第三者が、前記オブジェクトプログラム１を逆コンパイル・逆アセンブルして（図１の①の行為）このソースプログラムａを得、このソースプログラムａからこれに類似する他のソースプログラムｂを得（図１の②の行為）、さらにこのソースプログラムｂからコンパイル・アセンブルして（図１の③の行為）オブジェクトプログラム３を得た場合は、これらの①～③の行為は、いずれもオブジェクトプログラム１の「複製」または「翻案」行為に当たり、②および③の行為は著作権侵害となる。なお①の行為については、リバースエンジニアリングの一部と言えるため「法的に許された複製」となるかどうかは争いがある（まだ明確な判例はない）。
次に、無権原の第三者が、オブジェクトプログラム１を解析してソースプログラムａを得（図１の①の行為）、これから詳細フローチャートｃを得（図１の④の行為）、さらにこの詳細フローチャートｃからソースプログラムｂを作成する（図１の⑤の行為）場合、あるいは、詳細フローチャートｃからこれと類似する他の詳細フローチャートｄを得（図１の⑤’の行為）、この詳細フローチャートｄからソースプログラムｅ、さらにオブジェクトプログラム４を得た場合、はどうか。
一般に、詳細フローチャートがソースプログラムとほとんど機械的に対応している場合であれば、両者はいずれか一方の複製とみることができる（中山信弘著「ソフトウェアの法的保護」１１３頁もほぼ同旨）。したがって、このような場合は、ソースプログラムａから詳細フローチャートｃを得ること（④の行為）はソースプログラムａの複製となるし、逆に詳細フローチャートｃからソースプログラムｂを得ること（⑤の行為）も詳細フローチャートｃの複製となると見てよい。よって④の行為（リバースエンジニアリング）はともかく、 ⑤の行為はソースプログラムａまたはオブジェクトプログラム１に関する著作権の侵害となる。
また、詳細フローチャートｃから類似の詳細フローチャートｄを作成する行為（⑤’の行為）は、詳細フローチャートｃの複製となる。したがって、この複製により得た詳細フローチャートｄからソースプログラムｅを経てオブジェクトプログラム４を得ることは、結局、ソースプログラムａ（あるいはオブジェクトプログラム１）の著作権侵害となると考えられる。（米国の有名なウェラン対ジャスロー判決はこれと似た事案について著作権侵害とした）。
（２）著作権法の「プログラムの著作物の著作権」による保護の限界（「表現」と「アイデア」）
これに対し、第三者が、オブジェクトプログラム１からリバースエンジニアリング（図１の①、④、⑥の行為）によりシステムのアイデア（プログラム仕様書、要求仕様書等に記載されたものに相当する）を得、あるいはシステムのアイデアを記載した書類（特許明細書等）が公開されることによりこのアイデアを知り、このアイデアに基づいて、詳細フローチャートｆ、ソースプログラムｇさらにオブジェクトプログラム５を得た（図１の⑦、⑧、⑨の行為）場合はどうか。
この場合、まず前記の図１の①、④、⑥の行為は、リバースエンジニアリングに伴う行為として適法とされる可能性が高い。またこの点を別としても、プログラム仕様書（プログラム構造・モジュール内設計書）や要求仕様書に記載されているアイデアから詳細フローチャートを作ること（前記の図１の⑦の行為）は、前記仕様書の「表現」の複製とは言えない。よって前記の図１の⑦、⑧、⑨の行為は、結局アイデア部分にまで遡ぼってそこからプログラムの開発をしているのだから、オブジェクトプログラム１の著作物の著作権を侵害したとは言えない。
以上の議論から言えることは、結局、システム開発者が著作権により保護される範囲は、下図１の破線Ｂで示した部分（いわゆる「表現」部分）に限られ、「アイデア」部分は含まれない、ということである。したがって、オブジェクトプログラム１の製作の基になったアイデア部分（これは第三者にとっては、リバースエンジニアリングにより得る場合と、特許出願公開公報などから知る場合と、が有り得る）から詳細フローチャート、ソースプログラムさらにオブジェクトプログラム５を作成することは、著作権によっては阻止できない。
（３）「プログラムの著作物の著作権」による保護と特許権による保護との比較
これに対し、システム発明について特許権（ソフトウェア特許）が成立しているときは、この特許権の対象はシステムのアイデア部分である。したがって、無権原の第三者がこのアイデアを実施すること、具体的にはハードとソフトを含むシステムを一体として製造・販売・リースすることは、特許権を侵害することになる（ハードと切り離してソフトのみを製作・販売・リースすることが特許権侵害となるかどうかは、次の３で後述する）。つまり、図１の実線で囲んだＣの部分がソフトウェア特許の保護範囲と言うことになる。このことから、システム発明におけるプログラムの保護範囲は、「プログラムの著作物の著作権」によるよりもソフトウェア特許による方がかなり広いといえる。
（４）システムの「編集著作物の著作権」による保護と特許権による保護との比較
また新たに創作した各モジュール、ルーチンおよび／または既存の各モジュール、ルーチンを組み合わせてシステムを開発した場合、その各モジュール、ルーチンが独立のプログラムといえるときはそのそれぞれについての「プログラムの著作物の著作権」が新たに成立するかまたは既に成立しているが、これらだけでなく、それらの各モジュール、ルーチンの「選択または配列」に創作性があるときは、そのシステム全体が「編集著作物」（著作権法１２条１項）となり「編集著作物の著作権」も成立する。
しかし、この編集著作物の著作権が成立している場合でも、第三者がそのシステムのアイデアを盗用して独自に各モジュール、ルーチンを組み合わせてシステムを開発した場合は、編集著作権の侵害とすることはできない。これに対し、このようなシステムのアイデアに特許が成立していれば、第三者がそのアイデアに基づいて各モジュール、ルーチンを組み合わせてシステムを製作・販売・リースすることは、特許権侵害となる。よってシステムの発明（アイデア）の保護については、編集著作物の著作権によるよりも、ソフトウェア特許による方が保護範囲は広い、といえる。
（５）トレードシークレット法による保護の可能性
次にトレードシークレット法との関係についても検討しておこう。トレードシークレットの保護範囲はアイデアを含む。しかし、市販され，流通に置かれた図１のオブジェクトプログラム１を格納したＦＤ等は、流通により各エンドユーザーの所有管理下に置かれて原則として（秘密保持契約付きの販売などを除き）第三者のリバースエンジニアリングが可能となる。そのため、このＦＤ等に格納されたオブジェクトプログラム１とこれからリバースエンジリアリング（逆コンパイラ、逆アセンブラ）により直ちに生成されるソースプログラムａの内容は、「秘密として管理されていること」（不正競争防止法第１条第３項）という要件を失うこになり、トレードシークレットとしての保護を受けられない。（リバースエンジニアリングが極めて困難な場合は秘密管理性を失わない可能性もあるが、逆アセンブラなどは極めて容易なので、秘密管理性を失うと解してよいであろう。）
次にプログラム仕様書・システム要求仕様書等のアイデアを記載した書類（および詳細フローチャート）は、流通に置かれるものではない。しかし、これらの書類に記載されたアイデアが既に特許出願されている場合は、それが出願公開される（プログラム構造・モジュール内設計書そのものが出願図面に入れられることもありうる）ことにより、その内容のほとんどが「公然と知られていないこと」（不正競争防止法第１条第３項）という要件を失うことになるので、やはりトレードシークレットとしての保護を受けることはできない。
よってシステムの発明（アイデア）が特許出願され公開されたときは、トレードシークレットによる保護はほとんど期待できない、ということになる。
（６）まとめ
以上の通り、特にシステム発明（ソフトウェア発明）が特許出願され公開されているときは、トレードシークレット法はほとんど役に立たないし、著作権法による保護は狭く十分ではない。すなわち、システム発明（ソフトウェア発明）が特許出願され公開されているときは、第三者は、リバースエンジニアリングによらずとも、特許出願公開公報から容易にそのソフトウェア発明のアイデアを知ることができる。そしてこの公開公報から知ったアイデアに基づいてプログラムを作成し販売・リースすることは、著作権法やトレードシークレット法によっては阻止することができない。
よって、システム発明（ソフトウェア発明）が特許出願されてそれが公開されたときは特に、ソフトウェア特許による保護を有効に機能させることが必要である。
３．プログラムを格納したＦＤ等の「イ号能力」
－ソフトウェア特許がハードウェアとソフトウェアを含むシステムの発明（装置発明）としてクレームされている場合、無権原の第３者（ソフトハウス等）がソフトウェアを格納したＦＤ等のみを製作し、またはソフトウェアを格納したＦＤ等のみをパッケージソフトとして販売・リースすることは、特許侵害となるか？－
（１）問題の所在
先の「イエス事件」のソフトウェア特許を始め、実際にソフトウェア特許出願されている発明のほとんどは、ハードウェアとソフトウェアを含むシステム（装置）として、クレームされている。これは、現在の特許庁の実務が「…のプログラム」や「…のプログラムを格納した記録媒体」というクレームの記載形式を認めていないことや、そもそもプログラムそのものは命令および固定データの集まりであり、これ自体またはこれを格納した記録媒体自体だけでは何らの作用効果も生じさせられないので「発明」と言えないことによるものと考えられる。
ところで、このような特許または特許出願されたシステムの製作・流通形態としては、以下の２つがある。すなわち、
（ａ）大手コンピュータメーカーのように、ハードとソフトを一緒に製作・販売・リースする場合と、
（ｂ）中小ソフトハウスのように、大手コンピュータメーカーのハードおよびそのＯＳ（オペレーティング・システム）を前提にして、ソフト（アプリケーションソフト）のみを製作し、ハードと一緒に販売・リース、またはソフトを格納したＦＤ等（以下、フロッピーディスク、ＩＣカード、磁気テープ、ＣＤ－ＲＯＭ、光磁気ディスク等の記録媒体をまとめて「ＦＤ等」と略す）のみをマニュアルと共にパッケージソフトとして単体で販売・リースする場合とがある。
このうち（ｂ）のソフトのみを製作する行為、およびソフトを格納したＦＤ等のみを単体で販売・リースする行為は、クレームされたシステム全体実施ではないから、それだけでは特許権の直接侵害とはなり得ない。そこで、これら行為が特許法１０１条１号（間接侵害）に該当するか、すなわち、ＦＤ等は特許法１０１条１号の「その物の生産に（のみ）使用する物」に該当するか、が問題となる。
なおここで、特許法１０１条１号の「その物の生産にのみ使用する物」のうち、「のみ」の要件を満たすかどうかについては個々の事例ごとの具体的事情（特許製品との関係）で判断が異なり得る（もっとも、「ソフトウェア特許」はプログラム部分に特徴があるのだから、ソフトウェア特許侵害事件においては、「のみ」の要件を満たすことは多いであろう）。これに対し、この「のみ」の要件を捨象した「その物の生産に使用する物」に該当するかどうかは、個々の具体的事例（特許製品との関係）から離れて一般的に論じることが可能である。
したがって、以下では、プログラムを格納したＦＤ等が特許法１０１条１号の「その物の生産にのみ使用する物」に該当するかの問題のうち、個々の具体的事例により異なる「のみ」の該当性の問題（これはＦＤ等の「イ号適格」の問題と呼んでもよい）を捨象した、「その物の生産に使用する物」に該当するかどうかの問題を、ＦＤ等の「イ号能力」の問題と呼ぶことにする。
（２）プログラムを格納したＦＤ等の「イ号能力」
特許法１０１条１号の「その物の生産に（のみ）使用する物」の意義については、一般に、特許製品（のみ）に使用する「部品」となるものを意味するされている（有斐閣発行・吉藤幸朔著「特許法概説第８版」３５６頁参照）。
プログラムが格納されたＦＤ等は、それ自体が有体物である（著作権法でいう「複製物」に当たる）から、特許法１０１条１号の「物」であることは明らかである。またこのＦＤ等は、ソフトウェアを提供するため、すなわちハードおよびソフトから成るシステム特許製品を完成させるために不可欠のものであるから、システム特許製品の「部品」であり「その物の生産に使用する」といえる。
よって、ＦＤ等は特許法１０１条１号の「その物の生産に使用する物」であり、「イ号能力」を有すると考えられる。
以上のように、ソフトウェア特許関係の事件においては、プログラムを格納したＦＤ等がパッケージソフトとして単独で製作または販売・リリースされているときは、そのＦＤ等の「イ号能力」を肯定できるので、個々の事件の具体的事情から「のみ」の要件を満たす限り、プログラムの製作・または販売・リース行為のいずれかまたは両者を捕らえて間接侵害を主張することができる、と考えられる。
特に、前述の項目２．の（６）まとめで述べたように、システム発明（ソフトウェア発明）が特許出願されてそれが公開されたときは、トレードシークレット法や著作権法による保護は十分ではないので、ソフトウェア特許による保護を有効に機能させることが必要であるが、そのためにも、前述のようにプログラムを格納したＦＤ等の「イ号能力」を肯定し、プログラムを格納したＦＤ等の単独販売・リースの差し止めを認める立場に立つ必要があると考える。
なお、ソフトウェア特許が装置クレームでなく方法クレームで記載されている場合でも、上記の装置クレームの場合と同様に、プログラムを格納したＦＤ等は「その発明の実施にのみ使用する物」（特許法１０１条２号）に当たると考えてよい。
４．通信手段を介して販売・リースされるプログラムの「イ号能力」（「イ号能力」の水平方向の限界）
－ソフトウェアを通信手段（有線・無線）を介して販売・リースする行為を間接侵害として差し止め請求できるか？－
（１）問題の所在
近年の通信手段の発達により、従来のようにプログラムをＦＤ等に格納してマニュアルとともにパッケージソフトとして販売する形態でなく、プログラム自体をパソコン通信ネット等を介して、無償提供（フリーウェア）、あるいは販売（シェアウェア）する形態が登場している。このような近年の通信手段の発達と最近の所有よりも利用を重視する傾向とが相俟って、今後は、プログラム等ソフトウェアの通信回線等を介しての販売、リース、レンタルが急増していくことが予想される（下図２参照、なおこの場合短時間のレンタルは、例えば数時間後にソフトウェアを使用できなくなるようにするプログラムを内蔵させておく等の方法で可能である）。
そこで、ソフトウェア特許が存在している場合に、無権原のソフトハウス等がそのソフトウェア特許されたシステムの「部品」となるプログラムのみを通信による提供のために製作し、さらにそのプログラムを通信回線等の通信手段により販売・リースする場合、その行為をソフトウェア特許の侵害として阻止できるか、を考えてみたい。
（２）通信手段による販売・リースのためのプログラムの「製作」の間接侵害性
まず、ソフトウェア特許が存在している場合に、無権原のソフトハウス等がそのソフトウェア特許されたシステムの「部品」となるプログラムのみを「製作」する行為は、間接侵害行為に該当すると考える。なぜなら、プログラムの製作の途中または完成した段階では、（たとえそのプログラムの完成後はそれを通信手段によりユーザーに提供することを予定していても）必ずそのプログラムをＦＤ等（ハードディスクなどを含む）に格納しなければならないが、この場合のＦＤ等は、前述のように特許法１０１条１号の「その物の生産にのみ使用する物」に当たるからである。
しかし、この場合のプログラムの製作は、外部の人間には分かりにくい会社内で行われるので、この行為をとらえて間接侵害を主張立証するのは、実際には必ずしも容易ではない。よって、次の段階であるプログラムの通信手段を介した販売・リースという流通段階での間接侵害性を検討する必要がある。
（３）ソフトウェア特許されたプログラムを「通信手段を介して販売・リース」する行為の間接侵害性
この問題は、プログラム自体が特許法１０１条１号の「その物の生産に（のみ）使用する物」に当たるか、というプログラム自体の「イ号能力」の有無の問題といってよい。
この場合、プログラム自体が「その物の生産に使用する」ものに当たることは、前述したプログラムを格納したＦＤ等について述べたのと同様に、肯定してよい。
よって、ここでのプログラム自体の「イ号能力」の問題（「その物の生産にのみ使用する物」に当たるかどうか）の決め手は、プログラム自体がその物の生産にのみ使用する「物」に含まれるかどうか、の一点にあるといってよい。
（４）プログラム自体は、「イ号能力」を有するか、すなわち特許法１０１条１号の「物」に含まれるか。
まず、特許法１０１条１号は、民法の特別法としての性格をもっており、民法の規定が参考になる。民法８５条では、「物トハ有体物ヲ謂ウ」と定めており、これからすると、無対物であるプログラム自体は、特許法１０１条１号の「物」に当たらない、となりそうである。しかし、いわゆる法解釈における概念の相対性からは、この民法の規定から直ちに結論を導くことはできない。
次に、間接侵害行為も特許法１９６条（侵害罪）の「侵害」行為となる（「注解特許法」１５７９頁、但し反対説もある。）から、特許法特許法１０１条１号は刑法の特別法としての性格をも有しており、刑法における議論も参考になる。
刑法では、他人の電気引込線に無断で導線を接続して電力を窃取した事例（「電気窃盗」）について議論されている。すなわち、刑法２３５条では、「他人ノ財物ヲ窃取シタル者ハ…」と規定されており、電力がこの「財物」に当たるか（特に財「物」と言えるか）が議論されている。
これにつき、判例（大審院明治３６年５月２１日判決）は、「電流は有体物にあらざるも…可動性と管理可能性とを併有する…」から「財物」にあたり窃盗罪が成立するとした（その後刑法が改正され、「…電気ハ之ヲ財物ト」みなす、とする２４５条が付
加された）。この判例を中心に、電気・熱・圧力等のエネルギ、人間の役務、債権、電波、情報等が財「物」といえると考えるかどうかにつき、学説で議論されている。個の問題についての学説は多岐にわたるが、大ざっぱに整理すると下表１のようになる（参考文献、ジュリスト増刊「刑法の争点」２４３頁、石堂功卓「財物の概念」）。
この表１の中で、前記判例の見解は、「財物」は物理的に管理可能なものに限られ事務的に管理可能な債権や情報は含まれない、とする通説と同じ立場だと一般に解されている（よって、判例によれば、秘密の情報が表示された紙などの媒体をコピーのために社外に持ち出せば、その媒体という「財物」の窃盗になるが、その媒体を持ち出すことなく、目視による記憶やカメラの撮影によりその情報自体を盗んでも窃盗罪とならない（参考文献、ジュリスト1986.1.1-15、第46項、山口厚「企業秘密の保護」）。
以上のように、民法８５条に従えば「物」は有体物に限られるし、刑法２３５条の「財物」についての判例通説に従っても情報であるプログラム自体は「物」とは言えないことになる。特に、特許法１０１条１号に該当することがそのまま特許法１９６条（侵害罪）に該当してしまうことを考えると、罪刑法定主義の要請からも、特許法１０１条１号の解釈を、明文もないのに刑法における判例の解釈から大きく離れて拡大させてしまうことは好ましいこととは思われない。したがって、特許法１０１条１号の「物」にはプログラム自体は含まれない、すなわちプログラム自体は「イ号能力」を有しない、と考えるのが妥当であろう。
（４）まとめ
したがって、特許法１０１条１号の「物」にはプログラム自体は含まれず、プログラム自体は「イ号能力」を有しない、よってプログラム自体を通信手段を介して販売・リースする行為は間接侵害を構成しない、と結論するしかない。
なお、もしこのような通信手段を介してのプログラムの販売・リース（今後急増することが予想される）をソフトウェア特許侵害として差止め可能にするには、特許法を改正する等の立法によるのが最も適切な方法のように思われる。
またこの立法による方法以外に、通信手段を介してのプログラムの販売・リースをソフトウェア特許侵害として差止め可能にする方法としては、例えば民事訴訟法で議論されている表見証明（一応の推定）の理論を応用することも考えられる。すなわち、プログラムを通信手段で提供するためには必ずそのプログラムを格納したＦＤ等を所持している必要があることから、「プログラムの通信手段を介しての販売・リース」行為（すなわちＦＤ等の「所持」行為）があれば、特別の事情（間接反証）がない限り、そのプログラムを格納したＦＤ等は、その「販売・リース」を行っている者（すなわち「所持」している者）が「製作」したものだと推定し、この「ＦＤ等の製作」を侵害行為として追及することが考えられる。
なお、前述のようにプログラム自体を通信手段を介して販売・リースするためには、必ずプログラムを格納したＦＤ等を所持しなければならないが、この「所持」行為自体は、「間接侵害とならない通信手段によるプログラムの販売・リースのため」の所持なので、「侵害するおそれ」（特許法１００条）ある行為とはならない。この点で、プログラムを格納したＦＤ等の販売・リースのためのＦＤ等の「所持」が、「間接侵害となるＦＤ等の販売・リースのため」の所持として「侵害するおそれ」ある行為として差止めの対象となり得るのとは異なっている。
５．ソースプログラム、詳細フローチャート、プログラム仕様書等を格納したＦＤ等の「イ号能力」（「イ号能力」の垂直方向の限界）
次に、ソフトウェア特許が存在している場合に、無権原の第三者が、特許出願公開公報などから知ったアイデアを基に、（オブジェクトプログラム以外の）ソースプログラム、詳細フローチャート、プログラム仕様書等を格納したＦＤ等を製作・販売・リースする行為が間接侵害（特許法１０１条１号）となるかどうかを検討してみよう。このようなソースプログラム、詳細フローチャート、プログラム仕様書を格納したＦＤ等については、その製作はともかく、その販売・リースは通常では考えられないが、間接侵害を潜脱するために敢えて、その販売・リースをコンパイラやアセンブラを有するエンドユーザー向けに行うことも考えられる。
なおこの問題は、図１のプログラム開発工程で得られる成果物のうち、最下位レベルのオブジェクトプログラムを格納したＦＤ等について「イ号能力」がみとめられるとして、そこから出発して上位レベルの成果物のどこまでに「イ号能力」を認めることができるか、という問題である。言わば、前述した「ＦＤ等、さらに通信手段を介して提供するプログラム自体の「イ号能力」」の問題が「イ号能力」の水平方向の限界の問題とするなら、こちらは、「オブジェクトプログラム、ソースプログラム…というようにソフトウェアの開発工程における成果物のレベルを上位の方へ遡ぼっていくとき、どこまでを間接侵害として捕らえることができるか」という「イ号能力」の垂直方向の限界の問題であるといえる。
（１）ソースプログラムを格納したＦＤ等の「イ号能力」
まずソースプログラムを格納したＦＤ等については、特許法１０１条１号の「その物の生産に使用する物」（「のみ」を捨象している）のうちの「生産に使用する」といえるかが問題である。
この点については、まずソースプログラムがその物の「部品」と言えるかが問題である。この点については、そのソースプログラムをコンパイルまたはアセンブルできるコンパイラまたはアセンブラを有するエンドユーザーにとっては、ソースプログラムを格納したＦＤ等があれば直ちにシステムを完成して稼働させることが可能であり、ＦＤ等の中身がオブジェクトプログラムであるかソースプログラムであるかは大した問題ではないといえる。よってソースプログラムはオブジェクトプログラムと同一視できる「システム製品の一部品」といってよく、「イ号能力」を肯定してよいと考える。
（２）詳細フローチャートを格納したＦＤ等の「イ号能力」
まず、詳細フローチャートは、「部品」であるオブジェクトプログラムと同一視できるといってよいか、が問題である。この詳細フローチャートがオブジェクトプログラムと「同一視できるかどうか」という点は、詳細フローチャートからソースプログラムを「自動生成する技術が確立し一般化しているかどうか」によって決めるのが妥当であろう。なぜなら、エンドユーザーがこの詳細フローチャートから機械語プログラムを直ちに自動作成してシステムを完成できるなら、この詳細フローチャートもオブジェクトプログラムと同一視してよいからである。もちろん技術の推移は日進月歩であるから、判断基準時（侵害行為時点）によりこの問題の結論は異なり得るし、時代の推移とともにこの「同一視」できる範囲は広がって行くだろう。しかし、現在の段階では、この詳細フローチャートについては、おそらく、まだ前記のような自動生成技術は一般化していないとして「オブジェクトプログラムと同一視できる」とはいえないとするのが妥当のように思われる。
次に、詳細フローチャートがオブジェクトプログラムと同一視できないとしても、最終生産物であるオブジェクトプログラムを生産するための（唯一の）中間生産物であるとすれば、「その物の生産に（のみ）使用する物」といってよいであろう。そして、ソースプログラムとほぽ機械的に対応するような詳細フローチャートはこのような中間生産物といえるので、「イ号能力」を認めてよいと考える。
なお、特許法１０１条１号の「その物の生産に使用する物」は、「部品」に限らず「加工機械」をも含むとする意見もある。例えば吉藤「特許法概説（第６版）」３１３頁などである（もっとも、同書の第７版および第８版では、この記載は削除されていることからみると、吉藤氏は現在はこの考えをとっておられないのかも知れない）。
仮にこの特許法１０１条１号の「…物」に「加工機械」も含まれるとする意見をとるならば、さらに一歩進めて、「製造装置」もこれに含まれるとしてもよいのではないかと思われる。なぜなら、「加工機械」でもよいとする以上、例えばＮＣ工作機械というハードウェアだけでなく、このＮＣ工作機械を動かすためのＮＣデータ（ＮＣプログラム）やこのＮＣデータの基となるＣＡＤによる形状データなどのソフトウェアを格納したＦＤ等をも含む「製造装置」としてもよいのではないか、と思われるからである（実際にも、特許法１０１条１号の「のみ」の要件を満たす可能性があるのは、汎用のＮＣ工作機械というハードではなく、ＮＣデータ等のソフトの方である）。
そこで、仮に特許法１０１条１号の「…物」には「製造装置」も含まれるとするなら、詳細フローチャート（を格納したＦＤ等）は、パソコン等のハードウェアツールとアセンブラやコンパイラ等のソフトウェアツールとともに「オブジェクトプログラム、ひいてはシステム製品を生産するための製造装置」の一部だといえるので、前記「…物」に含まれることになる。
しかしまた、この考えに立って論理を推し進めると、ソフトウェアの発明に対する「概略フローチャート」や「プログラム仕様書」を格納したＦＤ等（紙でもよい。光学式文字読取装置を使えば紙でもＦＤと同様に入力できる）や、さらには電気回路の発明に対する「回路図」や機械部品の発明に対する「機械図面」までもが「イ号能力」を認められることになる、という結論になりそうである。
まず前記の「回路図」や「機械図面」等も「その物の生産に使用する物」だとする結論が妥当かどうかを考えてみると、これは極めて難しい問題である。直接侵害を予防するために直接侵害に結び付く「回路図」や「機械図面」の生産や販売（実際にはあまり考えられないが）を差し止めることは必ずしも不当なこととはいえない。またこの立場に立っても、研究や情報提供のために「回路図」や「機械図面」を雑誌等に掲載することは、特許法６９条（特許権の効力の制限）により侵害とならないので、実際の不都合もあまり考えられない。
しかし他方、特許法１０１条１号の文理を見ると、間接侵害行為として「生産」や「譲渡」等の行為を問題にしており、これから見ると、「その生産に使用する物」とは、本来これらの行為の対象となるものが予定されていると見ることができる。ところで、前記の「回路図」等は一般に「生産」するものとは日常用語では言わないし、「譲渡」することも通常予定されていない。よって、特許法１０１条１号の「…物」にはこれらの「回路図」等は予定されていない、という考えも成り立つ。つまり、仮に特許法１０１条１号の「生産に使用する物」が「部品」に限らず「加工機械」や「製造装置」をも含むとしても、その場合の「加工機械」や「製造装置」は、「生産」するといえるものや「譲渡」等の対象となるものに限るべきで、少なくとも、「フローチャート」や「回路図」や「機械図面」などは特許法１０１条１号の「生産に使用する物」に含まれない、とという考えも成り立つ。
いずれにせよ、これはまだほとんど議論されていない問題であり、ここでは問題提起に止めておきたい
。
（３）「プログラム仕様書」を格納したＦＤ等（紙を含む）の「イ号能力」
このプログラム仕様書についても、詳細フローチャートについて前述したのと同様の議論が成り立ち得る。
すなわち、このプログラム仕様書については、オブジェクトプログラムという最終製品を生成するための中間生産物としての性格、したがって「イ号能力」を認めてよいかもしれない。しかし、プログラム仕様書からは複数の詳細フローチャート、従って複数のオブジェクトプログラムが生成可能なので、「のみ」の要件を満たすことは仕様書が特許発明を明確に定義している場合などに限られるだろう。
なお、現在、ビジネス分野の「定型的処理分野の機械的作業部分」に限れば、要求仕様からプログラムを自動生成するシステムも実用化されているが、このような「定型的作業部分」のプログラムのアイデアは、新規なものではなくソフトウェア発明の特徴部分とはなり得ないものである。ただ近い将来、「仕様書レベル」で記述されたものから「機械語プログラム」を生成する超高級言語や、「プログラム設計図」から「機械語プログラム」を自動生成するソフトウェアＣＡＤなどの技術が確立し一般に普及することが予想される（馬場勇「ソフトウェア開発の実践技法」技術評論社第１８２ページ参照）が、そのときは、この「仕様書」を格納したＦＤ等（紙でもよい。光学式文字読取装置を使えば紙でもＦＤでも同じである）もオブジェクトプログラムと「同一視できる」ような「システム製品の一部品」として、「イ号能力」を肯定できるようになるであろう（またこの場合は、仕様書から自動生成されたプログラムは仕様書の「複製物」または「二次的著作物」となるだろうから、例えば第三者がリバースエンジニアリング（機械語プログラムから仕様記述への逆変換）によりまたは特許出願公開公報を見ることにより「プログラム仕様書」の「表現」を知り、この「表現」から機械語プログラムを自動作成する行為（図１の⑦、⑧、⑨の行為に相当する行為）は、人の創作活動が加わらない機械的変換過程にすぎず「複製」に当たるとして、仕様書の「表現」について成立している著作権を侵害する行為となる可能性がある。もっとも、これは、コンピュータによる作曲・翻訳等と同じコンピュータ・アウトプットの法的扱いの問題でもあり、今後の検討課題である。
以上、プログラムを格納したＦＤ等、さらに通信手段を介して提供されるプログラム自体が「イ号能力」を認められるか、という「イ号能力」の水平方向の限界の問題
と、オブジェクトプログラム、ソースプログラム…というようにソフトウェア開発工程で得られる成果物を上位レベルの方に遡ぼるときそれらのうちどこまでが「イ号能力」を認められるか、という「イ号能力」の垂直方向の限界の問題と、について議論してきたが、この２つの問題についての以上の議論の一応の結論を下表２に整理しておく。
６．終わりに
以上のように、ソフトウェア特許が実際の侵害係争の中で有効に機能するかどうかについては、多くの問題がある。従来、我々弁理士の世界では、発明の出願を受任しそれを特許成立までもって行けばそれでよしとして特許後の実際の保護の態様については余り関心を払わないというような風潮が一部にあったのは事実である。しかし、本来、受任した発明について将来特許が成立した場合にそれが実際の係争の中でどのように争われどのような保護範囲を有するのかを出願時に明確にイメージすることができなければ、そもそも適正なクレームや明細書を書くことなどできないのではないだろうか。
特に、少なくとも現行特許法では差止めが困難と思われる、通信手段を介してのプログラムの販売・リースをどう扱うか、等の問題については、今から、多くの実務家、学者、官庁等を含めて、特許法の改正等をも含めた広範な議論と対策を講じていく必要があると、私は思う。そうでないと、今後続々成立してくるであろう多数のソフトウェア特許も、「ソフトウェアのみの販売・リース」（将来は販売・リースのほとんどが通信手段を介して行われるようになると予想される）の行為形態によるアイデア盗用についてはほとんど実効性をもたない「絵に書いた餅」に帰してしまうであろう。