◆H15. 1.31 東京地裁 平成13(ワ)17306 著作権 民事訴訟事件
平成１３年(ワ)第１７３０６号 著作権侵害差止等請求事件
平成１４年１０月２日口頭弁論終結
判 決
原 告 株式会社ワイビーエム
同訴訟代理人弁護士 伊 関 正 孝
同 高 橋 利 全
被 告 佐鳥電機株式会社
同訴訟代理人弁護士 真 山 泰
同 茶 谷 篤
同 吉 増 泰 實
同 南 雲 隆 之
主 文
１ 原告の請求をいずれも棄却する。
２ 訴訟費用は原告の負担とする。
事 実 及 び 理 由
第１ 請求
１ 被告は，別紙被告製品目録記載の製品を製造，使用，販売，頒布又は輸出してはならない。
２ 被告は，前項記載の製品を廃棄せよ。
３ 被告は，原告に対し，金４０００万円及びこれに対する平成１３年９月４日から支払済みまで年５分の割合による金員を支払え。
第２ 事案の概要
原告は被告に対し，別紙被告プログラム目録記載の各プログラムを（以下，総称して「被告プログラム」という。）搭載した別紙被告製品目録記載の製品（以下「被告製品」という。）を製造，販売するなどの被告の行為が，原告の有する原告プログラム目録記載の各プログラム（以下，総称して「原告プログラム」という。）に係る著作権（複製権，翻案権，譲渡権）を侵害すると主張して，被告の上記各行為の差止及び損害賠償金の支払等を求めた。
１ 前提となる事実（証拠等は文末に付した。）
(1) 原告プログラム
ア 吉沢ビジネス・マシンズ株式会社（以下「吉沢ビジネス・マシンズ」という。）は，平成元年９月ころ，ＭＳ−ＤＯＳ３．１上で作動し，ＡｕｔｏＣＡＤ ＧＸL版に対応する別紙原告プログラム目録の１記載のプログラム（以下「原告プログラム１」という。）を開発し，東日本旅客鉄道株式会社（以下「ＪＲ東日本」という。）千葉支社等に対し，同プログラムを複製，格納した製品の納入を開始した（甲１４，弁論の全趣旨）。
イ 吉沢ビジネス・マシンズは，平成８年１１月ころ，原告プログラム１をバージョンアップし，Ｗｉｎｄｏｗｓ上で作動し，ＡｕｔｏＣＡＤ Ｒ１３Ｊ版に対応する同目録の２記載のプログラム（以下「原告プログラム２」という。）を開発し，ＪＲ東日本秋田支社等に，同プログラムを複製，格納した製品を納入した（弁論の全趣旨）。
ウ 原告は，平成１２年１１月１日，吉沢ビジネス・マシンズから，代金２億円で，原告プログラムに関する開発，販売，保守サービス等一切の事業を譲り受けるとともに，原告プログラムの著作権及び同権利の侵害により同日までに発生した損害賠償請求権を譲り受けた（甲１１，１２）。
(2) 被告プログラム
ア 被告は，平成９年３月ころ，Ｗｉｎｄｏｗｓ上で作動し，ＡｕｔｏＣＡＤ Ｒ１３Ｊ版に対応する被告プログラム目録の１記載のプログラム（以下「被告プログラム１」という。）を開発し，ＪＲ東日本の盛岡支社等に，これを複製，格納した製品を納入した（乙３，弁論の全趣旨）。
イ 被告は，平成１０年１０月ころには，被告プログラム１をバージョンアップし，ＡｕｔｏＣＡＤ Ｒ１４版に対応する同目録の２記載のプログラム（以下「被告プログラム２」という。）を開発し，さらに平成１３年１０月ころには，被告プログラム２をバージョンアップし，ＡｕｔｏＣＡＤ ２０００ｉ版に対応する同目録の３記載のプログラム（以下「被告プログラム３」という。）を開発し，それぞれを複製，格納した製品をＪＲ東日本の盛岡支社等に納入した（乙３，弁論の全趣旨）。
(3) 原告プログラムの内容
ア 原告プログラムは，ＡｕｔｏＣＡＤ上で作動し，鉄道電気設計及び設備管理用の図面を作成するコンピュータ支援設計製図ソフトプログラムである。なお，ＡｕｔｏＣＡＤとは，オペレーティングシステム（ＭＳ−ＤＯＳ又はＷｉｎｄｏｗｓ）上で作動するオートデスク社製の汎用型ＣＡＤシステム（２次元又は３次元の図面の作成，変更，削除，表示，印刷等を行うプラットフォーム）である。
原告が複製権侵害と主張する部分は，原告プログラムの，以下のイ及びウである。
イ 原告「電車線−基準線作成プログラム」
(ア) 原告「電車線−基準線作成プログラム」は，原告プログラムの一部であるが，ユーザーの入力するデータに従って，電車線（電気機関車及び電車に動力用の電気を供給するために使用する接触電線等）の設計図面の作図を補助するため，縦及び上下の基準線を描画するプログラムである。
(イ) 原告「電車線−基準線プログラム」は，各機能ごとに記述され，以下の５つのファイルに分けられている（甲１７，２７）。
ａ メイン部 ＹＢＪーＴＲ６８．ｌｓｐファイル（別紙１）
ｂ 入力部 ＹＢＪ−ＴＱ０２．ｌｓｐファイル（別紙２）
ｃ 修正部 ＹＢＪ−ＴＲ８０．ｌｓｐファイル
ｄ 描画部 ＹＢＪ−ＴＲ７９．ｌｓｐファイル（別紙３）
ｅ 説明部 ＹＢＪ−ＴＲ７８．ｌｓｐファイル
(ウ) 原告「電車線ー基準線プログラム」は，ＡｕｔｏＬＩＳＰ言語（インタープリター方式のプログラム言語。同言語の記述は，コンパイルする必要がない。）で記述されている。なお，原告プログラムは，暗号化されたソースプログラム形式によって，原告製品のハードディスク内に複製，格納され，同プログラムについてのオブジェクトプログラムは存在しない（弁論の全趣旨）。
ウ シェイプ定義に係る記述
原告プログラムを複製，格納した製品のハードディスク内には，多数の特殊文字（フォント）や特殊図形（シェイプ）についてのシェイプファイル（拡張子ｓｈｘのバイナリデータファイル）が格納されている（甲１９，２４）。シェイプファイルは，シェイプ定義ファイル（拡張子がｓｈｐのファイル）をＡｕｔｏＣＡＤのコマンドで機械語に翻訳（コンパイル）することによって生成されるファイルである。シェイプ定義ファイルは，ＡｕｔｏＣＡＤのシェイプ定義文に従って記述されている（乙２）。
(4) 被告プログラムの内容
ア 被告プログラムも，ＡｕｔｏＣＡＤ上で作動し，鉄道電気設計及び設備管理用の図面を作成するコンピュータ支援設計製図ソフトプログラムである。
イ 被告「電車線−基準線作成プログラム」
被告「電車線−基準線作成プログラム」も，被告プログラムの一部を構成し，ユーザーの入力するデータに従って，電車線（電気機関車及び電車に動力用の電気を供給するために使用する接触電線等）の設計図面の作図を補助するため，縦及び上下の基準線を描画するプログラムである。
被告「電車線ー基準線プログラム」は，別紙４のとおり，ＢＡＳＥＬＩＮＥ．ｌｓｐファイル上に，ＡｕｔｏＬＩＳＰ言語で記述されている（甲１８）。
ウ シェイプ定義に係る記述
被告プログラムを複製，格納した製品のハードディスク内には，特殊文字（フォント）や特殊図形（シェイプ）についてのシェイプファイル（拡張子ｓｈｘのバイナリデータファイル）が格納されている（乙１）。シェイプ定義ファイルは，ＡｕｔｏＣＡＤのシェイプ定義文に従って記述されている。
２ 争点
(1) 被告プログラムは，原告プログラムを複製ないし翻案したものに当たるか（被告製品を製造，販売するなどの被告の行為は，原告プログラムに係る複製権，翻案権，譲渡権を侵害するか。）。
(2) 被告は，被告プログラムを作成するに際して，原告プログラム１を，自己のコンピュータ内の記憶媒体等に複製，格納したことがあるか。
(3) 原告の損害額はいくらか。
３ 争点に関する当事者の主張
(1) 被告プログラムは，原告プログラムを複製ないし翻案したものに当たるか。
（原告の主張）
被告は，以下のとおり，原告プログラムに依拠して，原告プログラムと実質的に同一であるか，又は二次的著作物に当たる被告プログラムを作成した。被告プログラムは原告プログラムを複製ないし翻案したものである。
したがって，被告プログラムを搭載した被告製品を製造，販売する被告の行為は，原告プログラムについて原告が有する著作権（複製権，翻案権，譲渡権）を侵害する。
ア 原，被告の「電車線−基準線作成プログラム」の同一性
(ア) メニュー表示部
原，被告のメニュー表示部は，処理手順ないしフローチャート等，その基本的な構造が全く同一である。
(イ) 基準線のデータ入力部
ａ キロ行程最初の値の入力部
「電車線−基準線作成プログラム」のうち，キロ行程の最初の値を入力する部分は，原告プログラムが「（setq V0（getreal"\n●キロ行程の最初の値をｍ単位で入力＜０＞："））」であるのに対して，被告プログラムが「（setq fStartKiro(getreal"\nキロ行程の最初の値をｍ単位で入力＜０＞：")）」であり，ほとんど同一である。また，上記「""」内に記述された日本語部分（画面表示メッセージ）もほとんど同じである。
ｂ キロ行程オフセット値の入力部
「電車線−基準線作成プログラム」のうち，キロ行程のオフセット値（スタート地点から図面を書き出す地点までの距離）を入力する部分は，原告プログラムが「（princ"\n\n\n●キロ行程のオフセット値（スタート値から最"）」「（setqV1(getreal"\n 初のマークまでの距離)をｍ単位で入力＜０＞："））」であるのに対して，被告プログラムが，「（setq fOffsetKiro(getreal"\nキロ行程のオフセット値（スタート値から最初のマークまでの距離）をｍ単位で入力＜０＞：")）」であり，ほとんど同一である。また，画面表示メッセージは完全に一致している。
ｃ 縮尺の入力部
「電車線−基準線作成プログラム」のうち，縮尺を入力する部分は，原告プログラムが「（setq V２（getreal"\n\n\n●縮尺の分母のみ（例：1/500は500）入力＜500＞："））」であるのに対して，被告プログラムが，「（setq fScScaleC(getreal"\n尺度の分母のみ(１/500のときは500)を入力＜500＞：")）」であり，ほとんど同一である。また，画面表示メッセージは，実質的に同一である。
ｄ 用紙サイズの入力部
「電車線−基準線作成プログラム」のうち，用紙サイズを入力する部分は，原告プログラムが「（princ“\n\n\n●キロ用紙サイズＡ４（高さ210ｍｍ）Ａ３（高さ297ｍｍ）"）」「（setqV3(getstring“\nＡ２（高さ420ｍｍ）を入力＜Ａ４＞：")）」であるのに対して，被告プログラムが「（setq sPaSize(getreal“\n用紙サイズ（Ａ４，Ａ３，Ａ２，Ａ１，Ａ０）または高さをｍｍ単位で入力＜Ａ４＞：")）」であり，ほとんど同一である。また，画面表示メッセージは，実質的に同一である。
ｅ スパン距離の入力部
「電車線−基準線作成プログラム」のうち，スパン距離を入力する部分は，原告プログラムが「（setq V0（getstring"\n\nスパンを入力＜50＞"））」であるのに対して，被告プログラムが「（initget 6）（setq fSpan(getreal(strcat"\nスパン距離をｍ単位で入力＜"（DelLastZero fOldSpan）"＞："))）」であり，ほとんど同一である。また，画面表示メッセージは，実質的に同一である。
(ウ) 基準線の描画部
ａ 初期設定部
「電車線−基準線作成プログラム」のうち，基準線描画部の初期設定部（変数に値を設定する部分）の構成は，原，被告プログラムのいずれも，「キロ行程最初の値」，「キロ行程オフセット値」，「縮尺」，「用紙サイズ」の４項目を採用しているという点で，全く同じである。また，原，被告プログラムの処理の流れは，いずれも，上記４項目について入力されたデータを設定ファイルから読み出した後，「キロ行程最初の値」，「キロ行程オフセット値」，「縮尺」，「用紙サイズ」の順序で変数に値を設定する点において，全く同じである。
ｂ スパンの描画部
「電車線−基準線作成プログラム」のうち，スパン（縦基準線間の距離）描画部の処理の流れは，原，被告プログラムのいずれも，「Ｌ（スパン線の左側の補助線の描画）」，「Ｒ（スパン線の右側の補助線の描画）」，「スパン（前回のスパン位置から，指示されたスパン距離分の間隔を空けた縦線の描画）」の順に繰り返し処理を行うという点において，実質的に同一である。
ｃ 図面の上下基準線の描画部
「電車線−基準線作成プログラム」のうち，上下基準線を描画する部分の変数設定の処理の流れは，原告プログラムが，上下基準線を描画するための変数を設定する順序について，最下位の基準線，最上部の基準線，下から２番目の基準線，それ以降は上から２番目の基準線まで昇順としているのに対して，被告プログラムが，最下位の基準線，次いで昇順に一番上の基準線としている点において，ほぼ同一である。
ｄ キロ行程の描画部
「電車線−基準線作成プログラム」のうち，キロ行程（１キロ，０．５キロ及び０．１キロごとに，表示するマーク）の描画部は，原，被告プログラムのいずれも，@キロ行程の算出の方法，Aアルゴリズム，Bキロ行程に配置する図形をシンボル化しているという点において，一致している。
イ シェイプ定義に係る記述の同一性
(ア) 特殊文字データ
被告の特殊文字データのソースプログラム（シェイプ定義）は，原告の特殊文字データのソースプログラムと実質的に同一である。
例えば，文字コード「０Ｆ２７Ｃ」で表示される「 （（（ 」（甲３３の２２２頁）についての原，被告のソースプログラム（シェイプ定義）は，ペンの動き（特殊文字を書き始める起点や，書く順序）こそ異なるものの，相対的な移動を指示する部分（１つ前の地点から移動する数値を，Ｘ座標，Ｙ座標で記述したもの）はほぼ一致しており，その結果，画面上に表示される文字の形状（変化点の座標値）は完全に一致する。このような文字が，実務で使用される文字の９０％を占めている。
(イ) シェイプコードの割当領域
シェイプコードの割当領域については，被告プログラムと原告プログラムとは実質的に同じである。
すなわち，原告プログラムでは，シェイプ定義ファイル先頭の宣言文において，「５Ｆ，６０」「７Ｂ，Ａ０」及び「Ｅ０，ＦＥ」の３つの外字の割当領域を設定している。これは，原告プログラム１を作成した当時は，ＯＳ（ＭＳ−ＤＯＳ）上に外字領域がなかったため，原告が独自にＡＳＣＩＩ（アスキー）文字を転換して「５Ｆから６０」「７Ｂから７Ｆ」を外字領域として採用していたが，その後，原告プログラム２にバージョンアップする際に，Ｗｉｎｄｏｗｓ上に存在する外字領域である「Ｆ２からＦＥ」に外字を割り当てるようになったためである。したがって，原告プログラムでは，「Ｆ２からＦＥ」領域に割り当てられた文字は，「５Ｆから６０」「７Ｂから７Ｆ」の領域に登録されたシェイプ定義と全く同じものである。
これに対し，被告プログラムでも，外字領域として「５Ｆ，６０」「７Ｂ，７Ｆ」「８１，９Ｆ」「Ｅ０，ＥＡ」「Ｆ２，ＦＥ」の５領域を設定している。「７Ｂ，７Ｆ」「８１，９Ｆ」は，「８０」を境にして「７Ｂ，Ａ０」の領域を分割したものであり，同様に，「Ｅ０，ＥＡ」「Ｆ２，ＦＥ」は，「Ｅ０，ＦＦ」の領域を分割したものであるから，原，被告プログラムのシェイプコードの割当領域は実質的に同じである。
ウ 依拠性について
原告プログラムを複製，格納した製品は，ＪＲ東日本に納入されており，被告は，ＪＲ東日本の各支社に出入りする立場にあったから，ＪＲ東日本の従業員らの協力を得て，原告プログラムを解析する機会があった。
また，被告プログラムと原告プログラムの間には，後記のとおり，被告プログラムが独立して開発されたのであれば，あり得ないような一致点が数多く存在する。このことからも，被告は，原告プログラムに依拠して，被告プログラムを作成したことが明らかである。
（被告の反論）
原告プログラムのうち，原告が，被告プログラムとの類似性を指摘する部分は，以下のとおり，すべて創作性を有しない。また，原，被告プログラムは，実質的に同一ではないから，仮に，原告プログラムに創作性のある部分があったとしても，被告プログラムは，原告プログラムを複製ないし翻案したものではない。
ア 電車線−基準線作成プログラムの同一性
(ア) メニュー表示部
原告のメニュー表示部のプログラムは，「princ"\n1.データファイルの作成"」というものにすぎず，何ら創作性を有しない。
また，原告プログラムと被告プログラムとでは，表示されるメニューの文言が異なり，実質的に同一とはいえない。
(イ) 基準線のデータ入力部
ａ キロ行程最初の値の入力部
原告のキロ行程の最初の値を入力するプログラムの記述は，創作性を有しない。すなわち，原告のキロ行程の最初の値を入力するプログラムを簡単に模式化すれば，「setq Ａ (getreal"メッセージ＜実数＞")」となるが，これは，メッセージを画面に表示し，実数の入力を求め，入力された実数をＡという変数に代入するという極めて基本的なプログラムであり，誰が作成しても同一の記述となる。
ｂ キロ行程オフセット値の入力部
原告のキロ行程オフセット値の入力部のプログラムの記述は，単純なものであり，創作性を有しない。
また，原告プログラムでは，princ関数を使用しているのに対し，被告プログラムでは，setq関数及びgetreal関数を使用している点において，両者は異なる。
ｃ 縮尺の入力部
原告の縮尺の入力部のプログラムの記述は，創作性を有しない。すなわち，縮尺の設定において，必要とされる要素は，縮尺の入力を求めるメッセージ表示と実数値の入力であり，そのために必要な最低限のプログラムを模式化すると，「setq Ａ (getreal"メッセージ＜実数＞"）」となる。原告のプログラムは，この最低限必要なプログラムと同じものであって，創作性はない。
ｄ 用紙サイズの入力部
原，被告の用紙サイズの入力部のプログラムは，実質的に同一とはいえない。すなわち，原告プログラムではgetstring関数を使用しているのに対し，被告プログラムではinitget関数及びgetreal関数を使用している点において，両者のプログラムは異なる。また，原告プログラムでは，入力されたデータを逐一ファイルに書き出しているのに対し，被告プログラムでは，リスト処理をしてからファイルに書き出している点において，データの処理方法が異なる。
ｅ スパン距離の入力部
原告のスパン距離の入力部のプログラムと被告の該当部分とのプログラムとは，実質的に同一ではない。
(ウ) 基準線の描画部
ａ 初期設定部
原告プログラムの初期設定部において使用されている「キロ行程最初の値」「キロ行程オフセット値」「縮尺」「用紙サイズ」の各入力項目は，ＣＡＤにおける製図の際の必要性及びユーザーであるＪＲ東日本の要請によって必然的に決まるものであるから，その選択には創作性がなく，また，入力項目の変数の設定の順序にも創作性はない。
被告プログラムと原告プログラムとは，入力されたデータをファイルに書き出す順序及び使用する関数が異なっているから，実質的に同一ではない。
ｂ スパン線の描画部
原告のスパン線の描画部のプログラムの処理の流れには，創作性がない。すなわち，原告プログラムのスパン線描画部は，「Ｌ（左）側 → Ｒ（右）側 → スパン」の順に繰り返し処理を行うものであるが，スパン線の描画部において入力されるデータは，スパン間の距離を表す数値又は左右の補助線を描画することを表す「Ｌ」又は「Ｒ」だけであるから，その処理順序は，自ずから限られている。
被告プログラムと原告プログラムとは，スパン線描画部のプログラムの具体的記述において異なっているから，両者は実質的に同一ではない。
ｃ 図面の上下基準線の描画部
被告プログラムと原告プログラムとは，上下基準線を描画する上下基準線を描画する順序及び使用する関数が異なっているから，両者は同一ではない。
ｄ キロ行程の描画部
被告プログラムと原告プログラムとは，キロ行程の描画部のアルゴリズムが異なっているから，両者は同一ではない。
イ シェイプ定義に係る記述の同一性
(ア) 特殊文字データ
ａ 原告が主張する「特殊文字データのソースプログラム」は，著作権法上の保護の対象となるプログラムではない。
すなわち，著作権法（以下「法」という場合がある。）が保護するプログラム著作物とは，「電子計算機を機能させて一の結果を得ることができるようにこれに対する指令の組み合わせたものとして表現したもの」（法２条１項１０号の２）である。しかし，原告が主張する「特殊文字のソースプログラム」は，単なる座標値データであって指令の組み合わせではない。
ｂ 仮に，特殊文字のシェイプ定義のうち，ペンの動き（文字を書く順序）に関する指令情報が著作権法上のプログラムに該当するとしても，被告の特殊文字のシェイプ定義と原告の特殊文字のシェイプ定義とは，ペンの動き及び変化点の座標値において異なるから，両者は同一とはいえない。
(イ) シェイプコードの割当領域
原告プログラムのシェイプコードの割当領域の選択には，創作性がない。
ウ 依拠性について
被告プログラムは，被告がＪＲ東日本から開発依頼を受けて，平成７年ころから，自ら開発を続けてきたものであり，原告プログラムに依拠したものではない。
(2) 被告は，被告プログラムを作成するに際して，原告プログラム１を，自己のコンピュータ内の記憶媒体等に複製，格納したことがあるか。
（原告の主張）
被告は，過去のいずれかの時点において，ＪＲ東日本の各支社に出入りする立場にあったことを利用するなどして，ＪＲ東日本に設置されているコンピューター内のハードディスクに格納された原告プログラムを，自己のコンピュータ内の記憶媒体等に複製して格納したことがある。被告がこのような行為を行ったことは，以下の事実に照らして明らかである。
被告の上記複製行為は，原告プログラムについて原告が有する著作権（複製権，翻案権）を侵害する。
ア 特殊文字データの変化点の座標値の一致
原告プログラムの特殊文字の形状と，被告プログラムの特殊文字の形状とは，約９０％以上がほぼ完全に一致している。このことは，これらの特殊文字のフォント定義において記述されている変化点の座標値が一致していることを意味するが，変化点の座標値は，ソースプログラムを見なければ分からないものであるから，被告プログラムの特殊文字のソースプログラムは，原告プログラムを複製し，解析して作成したものである。
イ シェイプコードの割当領域の一致
原告プログラムと被告プログラムのシェイプコードの割当領域は，ほぼ完全に一致している。また，原，被告プログラムのいずれにおいても，「Ｆ２からＦＥ」領域に割り当てられた文字は，「５Ｆから６０」「７Ｂから７Ｆ」の領域に登録されたシェイプ定義と全く同じである。原告プログラムでは，特殊文字が二重に定義されているのは，原告プログラム１のＯＳが外字領域を有しないＭＳ−ＤＯＳであったためであるが，Ｗｉｎｄｏｗｓ上で作動する被告プログラムでは，「５Ｆから６０」「７Ｂから７Ｆ」の領域に登録された特殊フォントは不要であるにもかかわらず，これらの文字が原告プログラムと同じく二重に定義されている点で不自然である。
このような一致点が存在することは，被告が，原告プログラムを複製し，これを解析して被告プログラムを作成したことを示している。
ウ 補助線の数の一致
原告の電車線−基準線プログラムと被告の電車線−基準線プログラムとは，描画される横の補助線の数が一致している。補助線の数は，沿革的な理由で残されているにすぎないにもかかわらず，この数が一致するということは，被告が，原告プログラムを複製し，これを解析して被告プログラムを作成したことを示している。
エ エスケープコードの一致
原，被告プログラムは，いずれも「"｝"」をエスケープコードとして使用している。
原告は，信号設備台帳プログラムやキロ行程の描画部において，小さい上付き文字を表記するためのエスケープコードとして，「"｝"」を採用しており，たとえば「"Ｍ｝"」とＡｕｔｏＣＡＤに指令すれば，「Ｍ」の小さい上付き文字がＡｕｔｏＣＡＤ上に描かれる。原告プログラムで，このような方法を採用したのは，ＯＳがＭＳ−ＤＯＳであった時代には，外字領域がなかったため，アスキー文字の「"｝"」を転用して，特殊文字コントロール記号としたためである。
これに対し，被告プログラムでも，原告プログラムと同様に，「"｝"」をエスケープコードとして「小さい上付き文字」を表示している。被告プログラムが開発された当時，ＯＳはＷｉｎｄｏｗｓであり，Ｗｉｎｄｏｗｓには外字領域が定義されているのであるから，アスキー文字を特殊文字コントロール記号として転用する必要性が全くなかったことからすれば，被告プログラムで，このような方法を採用するのは，不自然である。
このような一致点が存在することは，被告が原告プログラムを複製し，これを解析したことを示している。
オ 改行コードの一致
原告の信号ケーブルプログラムでは，改行コード（入力した文字列を図面上に表示する際の改行を制御するためのコード）として，「０８６ＢＡ」を使用しているところ，被告プログラムでも，全く同じ「０８６ＢＡ」を改行コードとして使用している。また，改行量も同じであり，このため，原，被告プログラムで作成した文字列の図面上の配置位置（座標値）は，完全に一致する。
このような改行コードが偶然一致することはあり得ず，これは，被告が，原告プログラムを複製し，解析したことを示している。
カ 変数に値を設定する順序の一致
上記のとおり，電車線−基準線プログラムのうちの初期設定部は，原，被告プログラムのいずれも，入力されたデータを設定ファイルから読み出した後，変数に値を設定する順序が，「キロ行程最初の値」，「キロ行程オフセット値」，「縮尺」，「用紙サイズ」の順であるという点において，全く同じである。
変数に値を設定する順序は，プログラマーが自由に決定できるものであるから，被告プログラムが独立して開発されたものであれば，両者において変数に値を設定する順序が一致する確率は極めて小さい。特に，被告プログラムでは，入力されたデータを設定ファイルに書き出す順序は，「縮尺」，「用紙サイズ」，「キロ行程最初の値」，「キロ行程オフセット値」の順であるにもかかわらず，変数に値を設定する順序がこれと異なるのは，不自然である。
このことは，被告が原告プログラムを複製し，解析したことを示している。
（被告の反論）
被告は，被告プログラムを作成するに際して，原告プログラム１を自己のコンピュータ内の記憶媒体等に複製して格納をしていない。
原告は，原，被告プログラムでは，「特殊文字の形状」，「シェイプコードの割当領域」，「補助線の数」，「エスケープコード」，「改行コード及び改行量」，「変数に値を設定する順序」等が一致することをもって，被告が原告プログラムを複製したと主張する。しかし，以下のとおり，上記各一致点は，原告プログラムを直接複製した上で解析しなくても，他の方法により認識し得る事項であるから，被告が原告プログラムを複製した根拠とはならない。
ア 原告の主張ア及びイについて
特殊文字の形状及びシェイプコードの割当領域は，原告プログラム上でフォント一覧表を作成するＬＩＳＰプログラムを実行し，印刷した文字フォント一覧表から分かるものであり，被告は，被告プログラムと原告プログラムとの互換性を図るために，同一覧表を作成し，これに基づいて，原告プログラムのシェイプコードと同じコードの特殊文字を作成した。
イ 原告の主張ウについて
補助線の数は，原告プログラムが作成した図面上分かるものであり，被告は，ＪＲ東日本から補助線の数について変更要請がなかったため，従前と同じ本数を採用した。
ウ 原告の主張エについて
エスケープコードは，原告プログラムが作成した図面上から分かるものであり，被告は，原告プログラムと操作上の互換性を図るために，同じエスケープコードを採用した。
エ 原告の主張オについて
改行コードは，原告プログラムが作成した図面上から分かるものであり，改行量については，異なる改行量を数回図面上で試行することにより，原告プログラムが定義した改行量を探し当てることができる。
(3) 原告の損害額はいくらか。
（原告の主張）
被告は，平成７年ころから現在まで，被告プログラムを複製，格納した製品を少なくとも合計１００台製造し，販売した。上記製品の１台当たりの利益額は４０万円を下らない。
したがって，原告プログラムに係る著作権を侵害されたことにより生じた原告の損害額は，４０００万円を下らない。
（被告の反論）
否認ないし争う。
第３ 当裁判所の判断
１ 争点１（被告プログラムは，原告プログラムを複製ないし翻案したものに当たるか。）について
(1) プログラムの創作性の有無及び同一性の判断について
ある表現物が，著作権法の保護の対象になる著作物に当たるというためには，思想，感情を創作的に表現したものであることが必要である。そして，創作的に表現したものというためには，当該表現が，厳密な意味で独創性のあることを要しないが，作成者の何らかの個性が発揮されたものであることは必要である。
この点は，プログラム（電子計算機を機能させて一の結果を得ることができるようにこれに対する指令を組み合わせたものとして表現したもの）形式で表現されたものであっても何ら異なることはない。プログラムは，具体的記述において，作成者の個性が表現されていれば，著作物として著作権法上の保護を受ける。
ところで，プログラムは，その性質上，表現する記号が制約され，言語体系が厳格であり，また，電子計算機を少しでも経済的，効率的に機能させようとすると，指令の組合せの選択が限定されるため，プログラムにおける具体的記述が相互に類似することが少なくない。仮に，プログラムの具体的記述が，誰が作成してもほぼ同一になるもの，簡単な内容をごく短い表記法によって記述したもの又は極くありふれたものである場合においても，これを著作権法上の保護の対象になるとすると，電子計算機の広範な利用等を妨げ，社会生活や経済活動に多大の支障を来す結果となる。また，著作権法は，プログラムの具体的表現を保護するものであって，機能やアイデアを保護するものではないところ，特定の機能を果たすプログラムの具体的記述が，極くありふれたものである場合に，これを保護の対象になるとすると，結果的には，機能やアイデアそのものを保護，独占させることになる。したがって，電子計算機に対する指令の組合せであるプログラムの具体的表記が，このような記述からなる場合は，作成者の個性が発揮されていないものとして，創作性がないというべきである。
さらに，プログラム相互の同一性等を検討する際にも，プログラム表現には上記のような特性が存在することを考慮するならば，プログラムの具体的記述の中で，創作性が認められる部分を対比することにより，実質的に同一であるか否か，あるいは，創作的な特徴部分を直接感得することができるか否かの観点から判断すべきであって，単にプログラムの全体の手順や構成が類似しているか否かという観点から判断すべきではない。
以下，上記のような点を総合考慮して，原告プログラムの創作性の有無及び被告プログラムとの対比について検討する。
(2) 電車線−基準線作成プログラムについて
ア メニュー表示部
(ア) 原告プログラムの内容
原告プログラム１の電車線−基準線作成プログラムのメニュー表示部の内容は，以下のとおりである（甲１７，２５）。
原告プログラム１の電車線−基準線作成プログラムのメインプログラムは，画面上に，「１．データファイルの作成」，「２．データファイルの修正」，「３．基本線作成」，「４．データファイルの文法説明」，「０．終了」というメニュー一覧を表示し，ユーザーが入力したメニュー番号に応じて，各機能を実行するファイルを呼び出す（ロードする）機能を有するものである。
そのプログラムの記述は，別紙１のとおりであり，１から２８行目までの合計２８行から構成されている（空行がある。また，１から４行目は，プログラムの内容や作成年月日などのメモである。）。
ａ ６行目は，「(setq B1 0)」であり，変数Ｂ１を初期化することを指示する。setq（セットキュー）関数は，ＡｕｔｏＬＩＳＰ言語における基本的な代入関数である。
ｂ ８から２０行目は，主として，「(princ "\n【メニュー名】"」，「(princ "\n"）」という構文を６回繰り返すものであり，【メニュー名】の部分には，順次，「＜＜ＪＲーＣＡＤ＞＞【電車線キロ行程，基準線作成】」，「１．データファイルの作成」，「２．データファイルの修正」，「３．基本線作成（データファイル作成後）」，「４．データファイルの文法説明」，「０．終了」が表示されている。princ（プリンシー）関数は，「" "」内の記述を，そのまま画面上に表示することを指令する。「￥ｎ」はＭＳ−ＤＯＳ版ＡｕｔｏＣＡＤにおける改行コードである。
ｃ ２１行目は，「（setq B0 (getint "\n目的の番号を入力<0>:"))(if(=B0 nil)(setq B0 0)）」であり，「目的の番号を入力＜０＞：」というメッセージを画面に表示した後，ユーザーが入力した整数値（メニュー番号）を，変数Ｂ０に設定することを指令する。
ｄ ２３から２７行目は，「（if(=B0【メニュー番号】)(load "【ファイル名】"))」という構文を４回繰り返し，最後に「(if（=B0 0)(setq B1 1))」と記述され，【ファイル名】の部分には，順次，データ入力部，修正部，描画部，説明部を実行するファイル名が記述されている。この部分は，ユーザーの入力するメニュー番号に応じてデータ入力部，修正部，描画部，説明部のいずれかのファイルをＡｕｔｏＣＡＤに読み込み，ユーザーがメニュー番号「０」（終了）を選択した場合には，変数Ｂ１に１を設定し，処理を終了することを指令する。
(イ) 創作性の有無
原告プログラムのメニュー表示部のプログラム記述は，全体として短く，その大部分が，ＡｕｔｏＬＩＳＰ言語で定められた一般的な関数を用いて，簡単な指令を組み合わせたものにすぎない。したがって，原告プログラムは，制作者の個性が発揮された表現とはいえず，創作性がない。
また，原告プログラムのメニュー表示部における処理の流れは，@画面上に，データ作成（入力），修正，描画，説明，終了の順に各メニューメッセージを表示し，Aユーザーにいずれかのメニュー番号を選択（入力）させ，Bユーザーが入力したメニュー番号に応じて，各機能を実行するファイルを呼び出すものであるが，これらの流れは，法１０条３項３号所定の「解法」に当たるというべきであって，著作権の保護が及ばない。
以上のとおり，原告プログラムのメニュー表示部は創作性がない。
イ 基準線のデータ入力部
(ア) キロ行程最初の値の入力部
ａ 原告プログラムの内容
原告プログラムのキロ行程最初の値の入力部の主たるプログラム記述（原告が，被告プログラムの該当部分と同一であると主張する記述。後記(イ)ないし(オ)においても同じである。）は，「(setq V0(getreal"\n●キロ行程の最初の値をにｍ単位で入力＜０＞:"))」の１行であり（別紙２の１３行目），これにより，キロ行程の最初の値の入力を指令するメッセージを画面上に表示し，入力された実数を，変数Ｖ０に設定することを指令する（甲１７，２５）。
原告の記述部分を構文にすると「setq V0 (getreal"メッセージ"))」となる。Getreal（ゲットリアル）関数は，ＡｕｔｏＬＩＳＰ言語で実数値を入力させる際に使用される関数であり，関数の後に記述される「" "」で囲まれた文字列を，そのまま画面に表示する。￥ｎは，改行を意味するコードである。
ｂ 創作性の有無
原告プログラムのキロ行程最初の値の入力部の記述は，画面上に「●キロ行程の最初の値をにｍ単位で入力＜０＞：」という文字列を表示した上，ユーザーが入力した実数値を，ＡｕｔｏＬＩＳＰ言語の一般的な関数を用いて，変数に設定するという極めて簡単な内容を，ごく短い構文で表現するものである。
したがって，キロ行程最初の値の入力部の記述は，制作者の個性が発揮された表現とはいえず，創作性はない。
(イ) キロ行程オフセット値の入力部
ａ 原告プログラムの内容
原告プログラムのキロ行程オフセット値の入力部の主たるプログラム記述は，「(princ"\n\n\n●キロ行程のオフセット値（スタート値から最"）」「(setq V1(getreal"￥ｎ初のマークまでの距離)をｍ単位で入力＜０＞："））」の２行であり（別紙２の１７，１８行目），これにより，キロ行程オフセット値の入力を指令するメッセージを画面上に表示し，入力された実数を，変数Ｖ１に設定することを指令する（甲１７，２５）。
原告の記述部分を構文にすると，「setq V0 (getreal"メッセージ"))」となるが，画面表示メッセージがゲットリアル関数に続く「""」内にすべて記載されておらず，メッセージの一部は，前行のプリンシー関数を用いて画面表示する。
ｂ 創作性の有無
原告プログラムのキロ行程オフセット値の入力部の記述は，画面上に「●キロ行程のオフセット値（スタート値から最初のマークまでの距離）をｍ単位で入力＜０＞：」という文字列を表示した上，ユーザーが入力した実数値を，ＡｕｔｏＬＩＳＰ言語の一般的な関数を用いて，変数に設定するという極めて簡単な内容を，ごく短い構文で表現するものである。
したがって，キロ行程オフセット値の入力部の記述は，制作者の個性が発揮された表現とはいえず，創作性はない。
(ウ) 縮尺の入力部
ａ 原告プログラムの内容
原告プログラムの縮尺の入力部の主たるプログラム記述は，「（setq V2(getreal "\n\n\n●縮尺の分母のみ（例：1/500は500）入力＜500＞:"))」の１行であり（別紙２の２２行目），これにより，縮尺の分母の入力を指令する「●縮尺の分母のみ（例：1/500は500）入力＜500＞：」というメッセージを画面上に表示し，入力された実数を，変数Ｖ２に設定することを指令する（甲１７，２５）。
原告の記述部分を構文にすると，上記「キロ行程最初の値の入力部」及び「キロ行程オフセット値の入力部」の記述と同じく，「setq V0 (getreal"メッセージ"))」となる。
ｂ 創作性の有無
原告プログラムの縮尺の入力部の主たるプログラム記述は，キロ行程最初の値の入力部及びキロ行程オフセット値の入力部の記述と同じく，制作者の個性が発揮された表現とはいえず，創作性はない。
(エ) 用紙サイズの入力部
ａ 原告プログラムの内容
原告プログラムの用紙サイズの入力部の主たるプログラム記述は，「(princ"\n\n\n●キロ用紙サイズＡ４（高さ210ｍｍ）Ａ３（高さ297ｍｍ）")」「（setq V3（getstring"\n Ａ２（高さ420ｍｍ）を入力＜Ａ４＞:"))」の２行であり（別紙２の２６，２７行目），用紙サイズの入力を指示するメッセージとして，「●キロ用紙サイズＡ４（高さ210ｍｍ）Ａ３（高さ297ｍｍ）Ａ２（高さ420ｍｍ）を入力＜Ａ４＞：」を画面上に表示し，入力された文字列を，変数Ｖ３に設定することを指令する（甲１７，２５）。
原告の記述部分を構文にすると，「setq V3 (getstring"メッセージ"))」となり，用紙サイズに関しては，入力されるデータは，「Ａ４」「Ａ３」といった文字列であるため，文字列の入力に対応するＡｕｔｏＬＩＳＰ言語の関数であるgetstring（ゲットストリング）関数を使用している。また，メッセージの一部は，前行において，プリンシー関数を用いて画面表示する。
ｂ 創作性の有無
原告プログラムの用紙サイズの入力部の記述は，画面上に「●キロ用紙サイズＡ４（高さ210ｍｍ）Ａ３（高さ297ｍｍ）Ａ２（高さ420ｍｍ）を入力＜Ａ４＞：」という文字列を表示した上，ユーザーが入力した文字列を，ＡｕｔｏＬＩＳＰ言語で文字列の際に通常用いられる関数を用いて，変数に設定するという極めて簡単な内容を，ごく短い構文で表現するものである。
したがって，原告の用紙サイズの入力部の記述は，制作者の個性が発揮された表現とはいえず，創作性はない。
(オ) スパン距離の入力部
ａ 原告プログラムの内容
原告プログラムのスパン（縦の基準線間の距離）の入力部の主たるプログラム記述は，「setq V0（getstring "\n\nスパンを入力＜50＞"))」の１行であり（別紙２の３６行目），これにより，スパンの入力を指示するメッセージとして，「スパンを入力＜50＞」を画面上に表示し，入力された文字列を，変数Ｖ０に設定することを指令する（甲１７，２５）。
原告の記述部分を構文にすると，用紙サイズの入力部の記述と同じく，「setq V0 （getstring"メッセージ"))」である。スパンに関しては，入力されるデータは，スパン（実数値）だけではなく，スパンの左右に補助線を描画することを指示する文字列（「Ｌ」又は「Ｒ」）も含まれるため，文字列の入力に対応するゲットストリング関数を使用している。
ｂ 創作性の有無
原告プログラムのスパンの入力部の記述は，画面上に「スパンを入力＜50＞」という文字列を表示した上，ユーザーが入力した文字列を，ＡｕｔｏＬＩＳＰ言語で文字列の際に通常用いられる関数を用いて，変数に設定するという極めて簡単な内容を，ごく短い構文で表現するものである。
したがって，スパン距離の入力部の記述は，制作者の個性が発揮された表現とはいえず，創作性はない。
ウ 基準線の描画部
(ア) 初期設定部
ａ 原，被告プログラムの内容
(a) 原告プログラムの初期設定部は，ユーザーが入力部で入力したデータに基づいて基準線を描画するため，入力部でデータファイルに書き込んだデータを読み出して，変数に設定する役割を有する。原告プログラムの初期設定部の記述は，描画部ファイル（別紙３）の記述のうち２２から５３行目までの３２行であり，その構成は，以下のとおりである。
まず，「キロ行程の最初の値」について，@「(setq 【変数】(read-line F1))」という構文により，データファイル内に書き込まれているデータを先頭から１行分読み込み，変数に設定し，Artos関数及びatof関数（文字列を実数に変換する関数）などを使用して，上記@の変数を，作図の際に使用できる実数値又は文字列等に変形させ，その結果を，セットキュー関数で新たな変数に設定し直し，B新しい変数の設定結果をプリンシー関数で画面上に表示し，その後，@からBまでの処理を，「キロ行程オフセット値」，「縮尺」，「用紙サイズ」の各入力項目ごとに，繰り返す。
原告プログラムの初期設定部において，変数を設定する順序は，入力部においてデータをファイルに読み込んだ順序と同一で，「キロ行程の最初の値」，「キロ行程オフセット値」，「縮尺」，「用紙サイズ」の順序である。これは，原告プログラムが，入力部において，「（write-line【変数】F0」という構文を使って，入力されたデータを，入力された順に逐次データファイルへ書き込んでいるところ（入力部ファイルの３０から３４行目），初期設定部のデータの読み込みに使われているread-line関数は，データがファイルに書き込まれた順に先頭から読み出すことしかできないためである（甲１７，２５）。
(b) これに対し，被告プログラムの初期設定部に該当する部分は，被告の電車線−基準線作成ファイル（別紙４）の２８４から２９１行目までの８行であり（DrawBaseLine関数というローカル関数の定義内に記述されている。），その構成は，以下のとおりである。
まず，「キロ行程の最初の値」について，@IsBaseLineDataというリスト（複数の値をもった変数）の中から，必要なデータを呼び出し，Aデータをそのままatof関数，fix関数（小数部分を切り捨てて整数変換する関数）などで評価し，B評価した数値をセットキュー関数で変数に設定し，上記@からBの処理を，順次，「キロ行程オフセット値」，「縮尺」，「用紙サイズ」という順序で行う。
被告の上記処理の具体的記述は，「(setq【変数】（【関数（atof関数など）】（nth【リスト内の順序】IsBaseLineData))」という１行の構文を主として，これを各入力項目（変数）ごとに，繰り返す。「（nth【リスト内の順序】IsBaseLineData）」は，リストの中身のデータを読み込む指令であり，Read-line（リードライン）関数のように，データファイルの先頭からだけではなく，データファイル内のうち，【リスト内の順序】で指定された位置にあるデータを読み出すことができる。なお，被告の電車線−基準線プログラムでは，IsBaseLineData内のデータは，縮尺，用紙サイズ，キロ行程の最初の値，キロ行程オフセット値，スパン距離の順序で保持されている（甲１８，２５，２７）。
ｂ 原告プログラムの創作性の有無及び対比
(a) 原告プログラムにおける入力項目として何を用いるかという点は，アイデアであり，著作権法上の保護の対象となるものではない。また，「キロ行程最初の値」，「キロ行程オフセット値」，「縮尺」，「用紙サイズ」の順序で変数に値を設定するという処理の流れも，法１０条３項３号所定の「解法」に当たり，著作物としての保護を受けない。
(b) 仮に，原告プログラムの初期設定部の具体的記述に，創作性が生じると解する余地があるとしても，前記認定の原告プログラムの内容に照らして，創作性の範囲は極めて狭いものというべきである。そして，被告プログラムと原告プログラムとは，初期設定部に用いられている構文上の相違によって具体的記述が大きく相違する。被告プログラムの初期設定部の具体的記述は，原告プログラムの初期設定部の記述と実質的に同一とはいえないし，原告プログラムの創作性を有する本質的な特徴部分を直接感得することもできない。
(c) したがって，原告プログラムの初期設定部について複製権又は翻案権侵害があるとは認められない。
(イ) スパン線の描画部
ａ 原，被告プログラムの内容
(a) スパン線の描画部は，ユーザーから入力され，データファイルに書き出されたスパン（縦基準線間の距離）に関するデータ（スパン間の距離を表す数値又は左右補助線を描画することを表す「Ｌ」又は「Ｒ」）を基に，縦の基準線，左右補助線，スパンの数値，スパン線（中央の横基準線）の描画を行う役割を有する。
原告プログラムのスパン線の描画部の記述は，原告の描画部ファイル（別紙３）の５９から１０５行目までの４７行であり，その構成は，以下のとおりである。
まず，@変数の初期化等の処理の後，画面左端の基準線の作図を指令し，Aデータファイルに入力されているスパン距離に関するデータを，「(setq 【変数】(read-line F1))」という構文で，ファイルの頭から１行分読み込み，B読み込んだデータが空ではない場合に，後続の処理を行うように指令し，C「（if（=(substr S0 1 1)" L "）」という指令で評価して，読み込んだデータが「Ｌ」の場合には，ＡｕｔｏＬＩＳＰ言語のコマンドである「command "line"(list Ｘ座標１，Ｙ座標１)(list Ｘ座標１，Ｙ座標２)"")」という構文を用いて，左補助線を描画するよう指令し（Ｘ座標１は，１つ前の基準線のＸ座標値から−４．０オフセットした値，Ｙ座標値１及び同２は，それぞれ左端基準線の両端の点のＹ座標値である。），D読み込んだデータが「Ｒ」の場合には，同様に右補助線を描画するよう指令し，E読み込んだデータが実数値（スパン距離）の場合には，前回のスパン位置からスパン距離分右側の位置に縦基準線を描画し，かつ，スパン距離を表示するよう指令し，F上記処理が終了した後は，データファイルからさらにデータを読み込んで変数を設定するよう指令し，データがあれば上記Bの処理を繰り返すが，データがなければ（変数が空になれば），処理を終了する（甲１７，２５，２７）。
(b) これに対し，被告プログラムのスパン線描画部の記述は，被告の電車線−基準線作成ファイル（別紙４）の３２９から３６３行目までの３４行であり，その構成は，以下のとおりである。
まず，@画面左端の基準線の作図を指令し，作図した結果の図形情報を，ＡｕｔｏＬＩＳＰ言語の関数であるputlayer関数を用いて，更新し，A初期カウンタ（変数）を「４」に設定し，リスト内のデータの５番目以降（ユーザーが入力し，リスト内に保持したデータのうち，５番目以降がスパンに関連するデータであるため）を処理対象とするよう指定し，Bリストの全体の長さを評価して，カウンタがリストの長さに達しない限り，後続の処理を繰り返すよう指令し，Cカウンタの順序（最初は５番目）に位置するデータをリストから読み出してセットキュー関数で変数（「vItem」）に設定し，D「（＝（strcase vItem）」という構文で評価（変数が大文字に変換される。）した結果，変数がＬである場合は，左補助線を描画するよう指令し，E上記Dと同じ評価の結果，変数がＲである場合には，右補助線を描画するよう指令し，F「（＜0.0(setq fSpan（atof vItem))」という構文で評価（数値であれば，実数に変換が行われる。）した結果，変数が実数である場合は，縦基準線及びスパンの数値を描画するよう指令し，G最後に，処理カウンタに１を足した後，上記Bに戻り，B以降の処理を繰り返す（甲１
８，２５，２７）。
ｂ 原告プログラムの創作性の有無及び対比
(a) 原告プログラムにおいて，読み出したデータを「Ｌ」，「Ｒ」，「スパン」の順序に評価し，描画をするという処理の流れは，法１０条３項３号所定の「解法」に当たり，著作物としての保護を受けないというべきである。
(b) 仮に，原告プログラムのスパン描画部の具体的記述に，創作性が生じると解する余地があるとしても，前記認定のプログラムの内容に照らして，創作性の範囲は極めて狭いものというべきである。そして，被告プログラムと原告プログラムとは，その具体的な変数の評価方法や，全体の処理を繰り返すための方法手順が異なる。被告プログラムのスパン描画部の具体的記述は，原告プログラムのスパン描画部の記述と実質的に同一とはいえないし，原告プログラムの創作性を有する本質的な特徴部分を直接感得することもできない。
(c) したがって，原告プログラムのスパン線描画部の記述について複製権又は翻案権の侵害があるとは認められない。
(ウ) 図面の上下基準線の描画部
ａ 原，被告プログラムの内容
(a) 上下基準線の描画部は，画面上部に３本，画面下部に６本，合計９本の上下基準線の描画を行う機能を有する。
原告プログラムの上下基準線の描画部の記述は，原告の描画部ファイル（別紙３）の１０８から１２３行目までの１６行であり，その構成は，主として，「command "line"（list Ｘ座標１ Ｙ座標１）（list Ｘ座標２ Ｙ座標２)"")」という構文を，最下部の基準線，最上部の基準線，下から２番目の基準線，以降は昇順に上から２番目の基準線まで，順次９回繰り返すというものであり，これにより，各基準線の始点と終点を，ＸとＹの座標値で特定し，２点間に線を描くことを指令している（甲１７，２５）。
(b) これに対し，被告プログラムの上下基準線の描画部の記述は，被告の電車線−基準線作成ファイル（別紙４）の３６５から４０７行目までの４３行であるが，あらかじめそれぞれの基準線のオフセット値（基準線間の間隔。変数の設定の順序は，最下位の基準線から昇順である。）及び縦線の高さの半分の値を変数として設定されており（２９３から３０３行目），上下基準線の描画部においては，「command "Line" 変数１ 変数２ ""」という構文の指令を繰り返し，１つ前に描画した基準線の座標にオフセット値（変数）を加算して，次の基準線の座標（変数１，変数２）を求めるという方法で，上下基準線を，画面中央部上側（上から３番目の基準線）から順に上方向へ３本，次いで中央部下側（下から６番目の基準線）から下部方向へ合計６本の基準線（合計９本）を描画している（甲１８，２５）。
ｂ 原告プログラムの創作性の有無及び対比
(a) 原告プログラムにおいて，上下基準線の座標値を下の基準線から上の基準線へ昇順に設定し，描画するという処理の流れは，そもそも，法１０条３項３号所定の「解法」に当たり，著作物としての保護を受けないというべきである。
(b) 仮に，原告プログラムの上下基準線描画部の具体的記述に，創作性が生じると解する余地があるとしても，前記認定のプログラムの内容に照らして，創作性の範囲は狭いものというべきである。そして，被告プログラムと原告プログラムとは，前記認定のとおり，基準線を描画する順序や，基準線の座標値を計算する方法に関するプログラムの記述において大きく相違する。被告プログラムの上下基準線描画部の記述は，原告プログラムの上下基準線描画部の記述と実質的に同一とはいえないし，原告プログラムの創作性を有する本質的な特徴部分を直接感得することもできない。
(c) したがって，原告プログラムの上下基準線描画部の記述についての複製権又は翻案権が侵害されている認めることはできない。
(エ) キロ行程の描画部
ａ 原，被告プログラムの内容
(a) キロ行程の描画部は，１キロメートル，０．５キロメートル，０．１キロメートルごとに，それぞれ印（マーク）を描画する機能を有する。
原告プログラムのキロ行程の描画部は，描画部ファイル（別紙３）の１２９から１６４行目までの３６行であり，その構成は，以下のとおりである。
まず，マークを一定間隔（１キロメートルごと，５００メートルごと，１００メートルごと）で設定するために，@現在処理中のキロ行程の値を，一定の間隔の数値（たとえば，１キロメートルマークについては１０００）で除し，その結果を切り捨て，さらに同数値（１０００）を乗じ，その計算結果が，もとのキロ行程の値と一致するときには，１キロメートルマークのシンボルを表示し（プログラムとは別に定義してある図形を読み込む），A一致しない場合には，続けて５００メートルマークを表示する場合に当たるかを，同様の方法（ただし，除したり乗じたりする数値は，５００になる）で判定し，B一致しない場合には，続けて１００メートルマークを表示する場合に当たるかを，同様の方法（ただし，除したり乗じたりする数値は，１００になる）で判定し，C上記処理を終了後，現在処理中のキロ行程の値に０．１メートルを加算した後，上記@へ戻って同じ処理を繰り返し，現在処理中のキロ行程が，事前に変数として設定してある「最大のキロ行程」と一致するに至ったとき（キロ行程が画面の右端に達したとき）は，終了する（甲１７，２５）。
(b) これに対し，被告プログラムのキロ行程の描画部の記述は，被告の電車線−基準線作成ファイル（別紙４）の４１０から４４９行の合計４０行であり，その構成は，マークを設置する一定間隔（１キロメートルごと，５００メートルごと，１００メートルごと）の判定をする方法として，rem（レム）関数を用いており，現在処理中のキロ行程を，一定の間隔の数値（例えば，１キロメートルマークについては１０００）で除し，その余りが０のときは，１キロメートルマークのシンボルを表示する（プログラムとは別に定義してある図形を読み込む）という計算方法を採用している（甲１８，２５）。
ｂ 原告プログラムの創作性の有無及び対比
(a) 原告プログラムにおける「アルゴリズム」は，そもそも法１０条３項３号所定の「解法」として，プログラムの著作権で保護されるものではないし，プログラムとは別に定義（シンボル化）された図形を読み込むという方法も，アイデアに当たり，著作権法上保護されるものではない。
(b) 仮に，原告プログラムのキロ行程の描画部の具体的記述に，創作性が生じると解する余地があるとしても，前記認定のプログラムの内容に照らして，創作性の範囲は狭いものというべきである。そして，被告プログラムと原告プログラムとは，キロ行程の値の評価方法が相違することにより，プログラムの記述において大きく相違する。被告プログラムのキロ行程の記述は，原告プログラムのキロ行程の記述と実質的に同一とはいえないし，また，原告プログラムの創作性を有する本質的な特徴部分を直接感得することもできない。
(c) したがって，原告プログラムのキロ行程の記述について複製権又は翻案権が侵害されていると認めることはできない。
エ 以上によれば，被告の「電車線ー基準線プログラム」が，原告の「電車線ー基準線プログラム」の複製又は翻案である旨の原告の主張は，理由がない。
(3) シェイプ定義に係る記述について
ア 特殊文字データ
証拠（甲６ないし８，１９，２４，３３，乙１，２，４，８ないし１２）によれば，以下の事実が認められる。
(ア) ＡｕｔｏＣＡＤ文字フォント等の概要
ａ ＡｕｔｏＣＡＤの文字フォント
(a) ＡｕｔｏＣＡＤの文字フォントには，大きく分けて，半角フォント，ビッグフォント，ＴｒｕｅＴｙｐｅフォントの３種類がある。ビッグフォントは，漢字など非ＡＳＣＩＩ文字を表現するための特殊な形式のシェイプ定義ファイルである。一般的に，コンピューターで扱うすべての文字は，すべて１つ１つ「文字コード」が割り当てられているが，コンピューターの文字コードは基本的には２５６個しかなく，漢字等多数の文字を割り振るには不十分であるため，ビッグフォントでは，２バイトコード（文字コードを２つ連結し，１つの文字を指定する。）によって文字を表現することができる。２バイトコードを用いる際には，コンピューターが，１つ目のコードを独自の文字コードであると誤認識しないよう，滅多に使用しない特定のＡＳＣＩＩコードを「エスケープコード（コンピューターが次の文字とあわせて漢字と判断する文字コード）」として，ユーザーが選択することができる。
ＡｕｔｏＣＡＤには，ビッグフォントファイルとして，あらかじめＢＩＧＦＯＮＴ．ｓｈｘ及びＥＸＴＦＯＮＴ．ｓｈｘが添付されており，同ファイル内の文字の定義は，公開されており，これを改変・参照して，文字を独自の仕様とすることが可能である。
(b) ビッグフォントのシェイプ定義ファイルの最初の行は，「＊ＢＩＧＦＯＮＴ nchars，nranges，b1，e1，b2，e2，・・」という構文に従って記述（領域宣言）される。
「nchras」は，その記述に続いて定義されている文字定義数の近似値である。
「nranges」は，エスケープコードとして使用される連続範囲の数を指定する。
「b1,e1」は，エスケープコードとして使用される連続範囲における先頭及び最終コードを指定する。
ｂ ＡｕｔｏＣＡＤシェイプ定義に係る記述
シェイプ定義ファイルは，ＡｕｔｏＣＡＤの規定する文法に従って記述されており，その規約は，ＡｕｔｏＣＡＤに標準添付されるマニュアルに記載されている。なお，ＡｕｔｏＣＡＤのフォントは，ビットマップのように字形を「点の集まり」で表すのではなく，線で表すベクトルフォントである。
ＡｕｔｏＣＡＤのシェイプ定義ファイルのシェイプ記述の構文は，以下のとおりであり，シェイプ定義ファイルの各行には，最大１２８文字まで記述できる。
「*shapenumber, defbytes, shapename
specbyte 1, specbyte 2, specbyte 3....0」
(a) 「*shapenumber」とは，ファイルに対して与えられる一意な番号（シェイプ番号）で，シェイプファイルを呼び出す場合は，このシェイプ番号を指定する。文字フォントの場合は，ＡＳＣＩＩコードの中の各文字の値に対応する固有の番号が必要である（なお，シェイプ定義ファイルでは，文字以外の図形等のシェイプを記述することも可能であり，その場合には，任意の番号を割り当てることができる。）。
(b) 「defbytes」は，シェイプを記述するのに必要となるデータバイト数で，上限は，各シェイプにつき２０００バイトである。
(c) 「shapename」は，シェイプ名である。
(d) 「specbyte」とは，シェイプ指定バイトであり，各指定バイトは，ベクトルの長さ及び方向又は特別コード番号の１つを定義するコードである。特別コード番号には，０からＥまでの１５種類があり，例えば，「０」又は「０００」は「シェイプ定義終了」，「１」又は「００１」は「描画モードをアクティブにする（ペンダウン）」，「２」又は「００２」は「描画モードを非アクティブにする（ペンアップ）」，「３」又は「００３」はその次に記述されるバイトでベクトルの長さを除し，「４」又は「００４」はその次に記述されるバイトでベクトルの長さを乗じるという意味を有する。
シェイプ指定バイトにおいて，各変位点を記述する方法としては，@ベクトルの長さ及び方向コードを３文字の文字列で表現する方法（最初の文字がゼロで，２番目の文字がベクトルの長さを，３番目の文字がベクトルの方向を指定する）と，A特別指定コード「８」又は「９」に続けて，座標値を「（Ｘ変位，Ｙ変位）」で指定する方法がある。@の記述方法では，ベクトルの長さとして指定できる有効範囲は１（１単位長）からＦ（１５単位長）の１５種類であり，方向を指定できる有効範囲は，０からＦまで（９０度方向から反時計回りに順に１６等分した方向）の１６種類である。Aの記述方法では，ＸＹ変位値として指定できる範囲は，−１２８から＋１２７までである。
(イ) 原，被告シェイプ定義に係る記述の内容
ａ 原，被告のフォント定義に係る記述
(a) 原告のフォント定義に係る記述
原告のＳＵＧ−ＢＩＧ１．ｓｈｐ（シェイプ定義ファイル）冒頭の宣言文は，「＊ＢＩＧＦＯＮＴ １０３６９，３，０５Ｆ，０６０，０７Ｂ，０Ａ０，０Ｅ０，0ＦＦ」であり（甲１９），これは，エスケープコードとして使用される連続範囲として，「５Ｆ，６０」「７Ｂ，Ａ０」「Ｅ０，ＦＦ」の３つの外字領域を設定したことを意味する。
原告は，原告のフォント定義ファイルにおいて，ＡｕｔｏＣＡＤで標準添付されていない漢字，アルファベット，下付き文字，上付き文字，文章中で用いる特殊記号などについて，独自の定義文を作成している。
(b) 被告のフォント定義に係る記述
被告プログラムの特殊文字には，被告が，ＡｕｔｏＣＡＤに添付されているフォントを利用せずに，独自に作成した特殊フォントが１１８文字ある。このうち，「５Ｆ，６０」「７Ｂ，Ａ０」「Ｅ０，ＦＥ」の３つの外字領域内にコードが指定されている文字（原告の特殊文字と共通のシェイプコードを有する文字）で，かつ，原告も，ＡｕｔｏＣＡＤに添付されているフォントを利用せずに，独自に作成した特殊文字は，合計５４文字である。
５４文字のうち，１０文字は，原，被告の文字の形状が異なり，したがって，シェイプ定義の変化点の座標値も異なっている。１文字は，変化点の座標値及び筆順はほぼ同じであるが，文字の起点が異なっている結果，文字の形状は重ならない。３８文字は，形状は同じで，ほぼ重なるが，筆順（原告のシェイプ定義は，反時計回り又は下から上へ，被告のシェイプ定義は時計回り又は上から下へと記述している。）が異なるため，シェイプ定義中の変化点の座標値は異なっている。３８文字のうち１つは，後記文字コード「０Ｆ２７Ｃ」の文字「（（（」である。５文字は，文字の形状も筆順も一致しており，したがってシェイプ定義の変化点の座標値も一致するが，シェイプ定義の冒頭で記述するベクトルの倍率の表示が異なるなど，シェイプ定義全体の具体的記述には異なっている部分がある。上記５文字の形状は，「×」「／」「｜」「?（上付き小文字のエル）」「?（下付き小文字のエル）」である。
ｂ 原，被告の文字コード「０Ｆ２７Ｃ」の記述
(a) 原告のシェイプ記述
文字コード「０Ｆ２７Ｃ」についての原告のシェイプ定義の記述は，以下のとおりである。
「＊ＯＦ２７Ｃ，１０７，［｛Ｂ＝特殊（（（］
２，３，５，４，３，２，（８，７，−３），１，（８，−２，２），（８，−２，３），（８，−２，４），（８，−１，６），（８，１，６），（８，２，４），（８，２，３），（８，２，２），２，（８，０，−３０），（８，５，２），１，（８，−２，２），（８，−２，３），（８，−１，２），（８，−１，６），（８，１，６），（８，１，２），（８，２，３），（８，２，２），２，（８，０，−２８），（８，５，４），１，（８，−２，２），（８，−２，４），（８，−１，４），（８，０，２），（８，１，４），（８，２，４），（８，２，２），２，（８，０，−２６），（８，６，３），３，３，４，５，０」
したがって，原告のシェイプ記述においては，描画モードが作動（アクティブ）になった後は，「（−２，２），（−２，３），（−２，４），（−１，６），（１，６），（２，４），（２，３），（２，２），（０，−３０），（５，２），（−２，２），（−２，３），（−１，２），（−１，６），（１，６），（１，２），（２，３），（２，２），（０，−２８），（５，４），（−２，２），（−２，４），（−１，４），（０，２），（１，４），（２，４），（２，２）」の変化点の順に，線を描画しており，これは，画面上，「（」を下から上方向へ，左側から右方向へと描く動きとなる。
(b) 被告のシェイプ記述
文字コード「０Ｆ２７Ｃ」についての被告のシェイプ定義の記述は，以下のとおりである。
「＊ＯＦ２７Ｃ，９５，（（（
３，１００，４，６０，２，１４，８，（−８，−２５），２，５，８，（７，２７），１，９，（−２，−２），（−２，−３），（−２，−４），（−１，−６），（１，−６），（２，−４），（２，−３），（２，−２），（０，０），２，８，（５，２８），１，９，（−２，−２），（−２，−３），（−１，−２），（−１，−６），（１，−６），（１，−２），（２，−３），（２，−２），（０，０），２，８，（５，２４），１，９，（−２，−２），（−２，−４），（−１，−４），（０，−２），（１，−４），（２，−４），（２，−２），（０，０），２，６，８，（２３，０），２，１４，８，（−１５，−６），４，１００，３，６０，０」
したがって，被告のシェイプ記述においては，描画モードが作動（アクティブ）になった後は，「（−２，−２）（−２，−３），（−２，−４），（−１，−６），（−１，−６）（２，−４），（２，−３），（２，−２），（５，２８），（−２，−２），（−２，−３），（−１，−２），（−１，−６），（１，−６），（１，−２），（２，−３），（２，−２），（５，２４），（−２，−２），（−２，−４），（−１，−４），（０，−２），（１，−４），（２，−４），（２，−２）」の変化点の順に，線を描画しており，これは画面上，「（」を上から下方向へ，左側から右方向へと描く動きとなる。
(c) 文字コード「０Ｆ２７Ｃ」で表示される「 （（（ 」については，原，被告のシェイプ定義いずれで表示された場合でも，画面上の形状は同一であり，両者は重なり合う。
(ウ) 原告シェイプ定義に係る記述の創作性の有無及び対比等
ａ 法２条１項１０号の２所定のプログラム該当性の有無
原告のシェイプ定義の記述が，法２条１項１０号の２所定のプログラムに該当するか否かについて，念のため判断する。
原告のシェイプ定義の記述は，例えば「２」や「０」のような数字から構成され，これにより，「ペンアップ」「シェイプ終了」という動作が電子計算機により行われる。同記述は，ＡｕｔｏＣＡＤ上に存在し，シェイプ記述を定義するプログラム（例えば，「２」は「ペンアップ」を意味することを定義するプログラム）に読み込まれ，協働して機能することによって初めて，電子計算機に対する指令としての意味を持つ。そうすると，シェイプ定義の記述は，ＡｕｔｏＣＡＤによって読み込まれる情報を記載した単なるデータであるから，それ自体独立して，「電子計算機を機能させて一の結果を得ることができるようにこれに対する指令の組み合わせたものとして表現したもの」に当たらないと解する余地もなくはない。しかし，たとえ，当該記述が，独立性がなく，個別的に利用することができないものであったとしても，データ部分を読み込む他のプログラムと協働することによって，電子計算機に対する指令を組み合わせたものとして表現したものとみることができるのであるから，そのような記述も，同号所定のプログラムに当たると解して差し支えない。
そうすると，原告のシェイプ定義の記述は，具体的な記述に創作性がある限りにおいて，著作権法の保護の対象になるというべきである。
ｂ 創作性の有無
原告のシェイプ定義の記述方法は，シェイプ定義ファイルを実行するプログラムであるＡｕｔｏＣＡＤによって規定されており，その記述は，ベクトルの始点と終点を定める変位点の座標値（−１２８から＋１２７まで）又はベクトルの長さ及び方向コードを表現する３文字の文字列と，これらの座標値間の移動を指示する１から１０までの特別指定コードの組合せにより表現されている。そして，シェイプ定義に係る文法によれば，特定の形状のフォント又はシェイプを，通常の筆順で記述しようとすれば，その変位点の座標値の記述方法について，制作者の選択の幅は極めて狭いものであるから，シェイプ記述に創作性が生じるものということはできない。そして，原告の特殊文字のシェイプ定義に係る記述は，当該文字を描く筆順として通常の筆順に従っているから，原告のシェイプ記述の座標値の記述に，創作性があるとはいえない。
ｃ 対比
仮に，原告のシェイプ記述の具体的表現に創作性が認められると解する余地があるとしても，上記のとおり，原，被告が独自に作成した特殊文字合計５４文字のうち，４９文字については，変化点の座標値又は筆順が異なっていることに照らすならば（たとえば，原告が同一であると主張する「（（（」の原，被告のシェイプ記述の筆順は，被告のシェイプ記述が上から下方向へ書いているのに対し，原告のシェイプ記述は，下から上方向へと書いている点において相違があり，シェイプ定義の具体的記述は相違する。），両者の具体的表現方法が実質的に同一とはいえないし，また，原告シェイプ定義記述の創作性を有する本質的な特徴部分を直接感得することもできない。
なお，上記５４文字中，５文字（「×」「／」「｜」「?（上付き小文字のエル）」「?（下付き小文字のエル）」）については，上記シェイプ記述の表現は，ほぼ必然的に決まるというべきであるから，５文字に関するシェイプ定義に創作性が生ずる余地はない。
ｃ したがって，原告の特殊文字コードのシェイプ記述について，複製権又は翻案権侵害があるとは認められない。
イ シェイプコードの割当領域について
原告は，被告プログラムと原告プログラムとは，シェイプコードの割当領域において実質的に同一である旨主張する。しかし，原告プログラムにおけるシェイプコードの割当領域の選択は，アイデアに当たり，その点において，原告プログラムないし原告シェイプ定義記述の創作性を基礎付けることはできない。この点における原告の主張は失当である。
２ 争点２（被告は，被告プログラムを作成するに際して，原告プログラム１を，自己のコンピュータ内の記憶媒体等に複製，格納したことがあるか。）について
原告は，被告プログラムと原告プログラムとの間に，共通点が存在することを根拠として，被告が，原告プログラムを被告のコンピュータ内の記憶媒体等に複製して格納したことがあると主張する。
しかし，以下のとおりの理由から，原告プログラムと被告プログラムとに共通する点があったとしても，被告は，被告のコンピュータ内の記憶媒体等に複製する方法以外の方法によって，原告プログラムの内容を認識することができるから，これらの共通点が存在することをもって，被告が原告プログラムを複製したと認めることはできない。
(1) 特殊文字データの変化点の座標値の一致について
原告は，原告プログラムの特殊文字の形状と，被告プログラムの特殊文字の形状の９０％がほぼ完全に一致していることをもって，被告が原告プログラムを複製したことがある旨主張する。
しかし，原告プログラムの特殊文字の形状は，原告プログラムで使用されている「フォント一覧表」を作成するＬＩＳＰプログラムを，原告プログラム上で実行し，作成した「フォント一覧表」を見ることにより認識できるものであるし（乙４，８，１０），上記認定のとおり，原，被告が独自に作成した５４文字のうち，シェイプ定義（変化点の座標値）が完全に一致するものは５文字しかなく，その５文字は，いずれも座標値が一致しても不自然ではないような簡単な形状のものであるから，原，被告の特殊文字の形状が一致していることをもって，被告が原告プログラムを複製したと認めることはできない。
(2) シェイプコードの割当領域の一致
原告は，原，被告のシェイプコードの割当領域が，ほぼ完全に一致していること及び当該割当領域に割り当てられている特殊外字が，２重定義されている部分も含めて，すべて一致していることをもって，被告が原告プログラムを複製したことがあると主張する。
しかし，証拠（乙４，８，１０）によれば，原告プログラムの特殊文字のシェイプコード及びその割当領域は，原告プログラムにおいて使用されているフォントを表示した「フォント一覧表」を見ることにより認識することができ，被告は，原告プログラムで作成された図面を被告プログラムで開くことができるようにするために，同表に基づき，原告プログラムに存在する特殊文字に対応する特殊文字に，原告プログラムにおいて割り当てられたシェイプコードと同じシェイプコードを割り当てたことが認められるから，原，被告の特殊文字のシェイプコードの割当領域が一致していることをもって，被告が原告プログラムを複製したと認めることはできない。
(3) 補助線の数の一致
原告は，被告の電車線−基準線プログラムで描画される横の補助線（上下基準線）の数が，原告の補助線の数と一致していることをもって，被告が，原告プログラムを複製したことがある旨主張する。
しかし，上下基準線の数は，原告プログラムによって作成された図面を見ることによって容易に分かることであるし（甲３），被告が，ＪＲ東日本の便宜のために，従前の図面と一致する数とすることは，何ら不自然なことではないから，このことをもって，被告が，原告プログラムを複製したと認めることはできない。
(4) エスケープコードの一致
原告は，被告プログラムが使用するエスケープコード（「"｝"」）が，原告プログラムで使用されているコードと同じであることをもって，被告が，原告プログラムを複製したことがある旨主張する。
しかし，原告が使用するエスケープコードは，当該エスケープコードを使用して作成した原告プログラムを，被告プログラム上で開けば，エスケープコードとしての役割を果たさずに，そのまま当該コードの文字として，画面上に表示されるものであるから（乙４），原告プログラムを複製することなく知り得るものであるし，被告が，ユーザーであるＪＲ東日本が操作する上で便利なように，原告プログラムと同じコードをエスケープコードとすることは，何ら不合理なことではないから，エスケープコードが一致していることをもって，被告が原告プログラムを複製したと認めることはできない。
(5) 改行コードの一致
原告は，被告プログラムが使用する改行コード及び改行量が，原告プログラムが使用する改行コード及び改行量と同じであることをもって，被告が，原告プログラムを複製したことがある旨主張する。
しかし，原告が使用する改行コードは，当該改行コードを使用して作成した原告プログラムを，被告プログラム上で開くと，可読不可能な文字（「・」）として画面上に表示されるが，そのコードは，当該文字を他のアプリケーションに貼り付けることによって調べることが可能であり（乙４），その改行量も（原告の改行コードのシェイプ定義では，変位点の座標値が（０，−３０）であり，これは下方向へ３０単位移動することを意味する。），画面上の表示内容から，原告の改行コードを用いた場合の改行量と同じ改行量を探すことは可能であるし，被告が，ＪＲ東日本の操作上の便宜のため，原告プログラムと同じコードをエスケープコードとし，改行量を一致させること自体は，何ら不自然なことではないから，エスケープコードが一致していることをもって，被告が原告プログラムを複製し，解析したと認めることはできない。
(6) 変数に値を設定する順序の一致
原告は，被告の初期設定部のプログラムでは，変数に値を設定する順序（「キロ行程最初の値」「キロ行程オフセット値」「縮尺」「用紙サイズ」の順）が，原告プログラムで変数に値を設定する順序と同じであることをもって，被告が，原告プログラムを複製したことがある旨主張する。
しかし，上記順序は，変数を設定する順序としては，何ら不自然なものではなく，この点が一致していることをもって，被告が原告プログラムを複製したと認めることはできない。
(7) 以上のとおり，原告が主張する各一致点をもって，被告が原告プログラムを複製したことがあると認めることはできず，その他，原告の主張を認めるに足りる証拠はない。
したがって，この点に関する原告の主張は理由がない。
３ 以上によれば，原告の請求は，その余の点を判断するまでもなく，いずれも理由がない。よって，主文のとおり判決する。
東京地方裁判所民事第２９部
裁判長裁判官 飯 村 敏 明
裁判官 今 井 弘 晃
裁判官 大 寄 麻 代
原告プログラム目録
１ ＡｕｔｏＣＡＤ ＧＸL版ＪＲ−ＣＡＤ
「電車線−基準線作成プログラム」のうち，メニュー表示部のプログラム，入力部のプログラム，描画部のプログラムは，それぞれ別紙１ないし３のとおりである。
２ ＡｕｔｏＣＡＤ Ｒ１３Ｊ版ＪＲ−ＣＡＤK
被告プログラム目録
１ ＡｕｔｏＣＡＤ Ｒ１３Ｊ版 Ｑｕｉｔｅ鉄道編
「電車線−基準線作成プログラム」のうち，メニュー表示部のプログラム，入力部のプログラム，描画部のプログラムは，別紙４のとおりである。
２ ＡｕｔｏＣＡＤ Ｒ１４版 Ｑｕｉｔｅ鉄道編Ｖｅｒ１．１
３ ＡｕｔｏＣＡＤ ２０００ｉ版 Ｑｕｉｔｅ２０００鉄道編 Ｖｅｒ１．０