戻る

平成２６年３月１２日判決言渡同日原本領収裁判所書記官
平成２５年（ネ）第１０００８号著作権侵害差止請求権不存在確認等請求控訴事
件（原審・東京地方裁判所平成２４年（ワ）第５７７１号）
口頭弁論終結日平成２６年１月１５日
判決
控訴人日本テクノ・ラボ株式会社
訴訟代理人弁護士栄枝明典
同石井尚子
同内山浩人
訴訟復代理人弁護士三浦友裕
被控訴人新高和ソフトウェア株式会社
訴訟代理人弁護士松島淳也
同木村貴司
補佐人弁理士廣田恵梨奈
主文
１本件控訴を棄却する。
２控訴費用は控訴人の負担とする。
事実及び理由
第１控訴の趣旨
１原判決を取り消す。
２被控訴人の請求をいずれも棄却する。
第２事案の概要
本判決の略称は，「本件ソフトウェアのプログラム」を「本件プログラム」と，
「原告ソフトウェアのプログラム」を「被控訴人プログラム」と各改め，以下に掲
記するほかは，原判決に従う。
１本件は，被控訴人プログラムを製造，販売する被控訴人が，被控訴人プログ
ラムは控訴人の著作物である本件プログラムを複製又は翻案したものであり，被控
訴人が被控訴人プログラムを製造，販売する行為は，控訴人が有する本件プログラ
ムの著作権（複製権（著作権法２１条）又は翻案権（同法２７条）及び譲渡権（同
法２６条の２第１項））侵害に該当するとともに，控訴人の営業秘密である本件プ
ログラム等の不正使用（不正競争防止法２条１項７号）に該当することを理由に，
被控訴人に対し，著作権法１１２条１項及び不正競争防止法３条１項に基づく被控
訴人プログラムの製造，販売の差止請求権を有するなどと控訴人が主張しているが
そのような請求権は存在しないとして，控訴人の上記各差止請求権の不存在の確認
を求めた事案である。
原判決は，被控訴人プログラムの具体的記述から本件プログラムの表現上の本質
的な特徴を直接感得することができないから，被控訴人プログラムが本件プログラ
ムを複製又は翻案したものと認めることはできない，被控訴人が本件プログラムの
表現上の創作性を有する部分を使用して被控訴人プログラムを製造し，販売したも
のとはいえない以上，被控訴人が控訴人の営業秘密である本件プログラムの表現上
の創作性を有する部分を使用して被控訴人プログラムを製造し，販売したものとは
いえない，エプソンチャイナ社からの本件要望事項それ自体が控訴人において秘密
として管理されていたことを認めるに足りる証拠はなく，被控訴人が本件要望事項
を利用し，これを搭載した被控訴人プログラムを製造したことについての具体的な
主張立証もないとして，被控訴人の請求をいずれも認容したため，控訴人がこれを
不服として本件控訴に及んだ。
２争いのない事実等及び争点は，「争点１（本件ソフトウェアのプログラムの
著作権侵害の成否）」を「争点１（被控訴人が被控訴人プログラムを製造，販売す
る行為についての本件プログラムの著作権（複製権又は翻案権及び譲渡権）侵害の
成否）と改めるほかは，原判決「事実及び理由」の第２の１及び２記載のとおりで
あるから，これを引用する。
第３当事者の主張
当事者双方の主張は，原判決１９頁１３行目の「甲１１」を「甲９」と改め，次
のとおり当審における当事者双方の補充主張を付加するほかは，原判決「事実及び
理由」の第３記載のとおりであるから，これを引用する。
１争点１（被控訴人が被控訴人プログラムを製造，販売する行為についての本
件プログラムの著作権（複製権又は翻案権及び譲渡権）侵害の成否）について
〔当審における控訴人の補充主張〕
依拠について
ア本件プログラムは，控訴人が製作した「iDupliversion１」（以下「旧バー
ジョンプログラム」という。）をバージョンアップした「iDupliversion２」であ
る。控訴人は，被控訴人の代表者であるＡから，プログラム開発の仕事の委託を懇
願されたことから，被控訴人に対し，旧バージョンプログラムのバージョンアップ
作業を委託することとして，開発内容の指示を行った上で，旧バージョンプログラ
ムのソースコードを貸与した。
したがって，旧バージョンプログラム及び本件プログラムの大部分は，控訴人に
より創作されたものである。
イ被控訴人プログラムは，本件プログラムを作成し，内容を熟知した被控訴人
が，本件プログラムを複製（デッドコピー）し，一部改変を加えて作成したもので
あるから，本件プログラムに依拠して作成された複製物又は翻案物であるというべ
きである。
被控訴人プログラムは，本件プログラムのソースコードをデッドコピーして改変
したプログラムであるため，創作性を有するもの及び有しないものも含めた本件プ
ログラムにおける全表現が侵害されている。
ウ被控訴人プログラムが本件プログラムのデッドコピーである根拠は，以下の
とおりである。
本件プログラム及び被控訴人プログラムは，画面の構成（表現）が酷似して
いる。だからこそ，被控訴人は，平成２３年９月時点において，本件プログラムの
画面（創作性のある表現）と同一であった被控訴人プログラムの画面表示の位置を
入れ替えた上で，本件プログラムとは異なる表現であるなどと主張しているのであ
る。
後記において具体的に主張するとおり，被控訴人プログラムのソースコー
ドの一部が本件プログラムと同一である。また，各プログラムのソースコードの構
成は酷似している。
被控訴人は，本件プログラムの「CsvIDtask.cpp」クラスの全行を改変し，デ
ッドコピーしたが，プログラム名「CsvIDtask.cpp」については，オリジナルのまま
残した。
被控訴人は，本件プログラムの受託開発作業のために入手したソースコードから，
子クラスの名前，親クラスの名前，ソースコード上の単語などを部分的に置き換え
て，あたかも違うソースコードのように見せかけようとする悪質な隠蔽工作を施し
た。
ソースコードに記述されるイベントの登録順序は，開発者が意図して登録し，
記述するものであるところ，本件プログラム及び被控訴人プログラムは，イベント
の登録順序が完全に酷似している。
被控訴人プログラムにおいては，「System.xml」というXMLフォーマット環
境設定ファイルを使用せずに「System.ini」を使用しているが，開示されたソース
コードでは，「System.xml」を使用したままとなっている。被控訴人プログラムの
「"CSysOption"」クラスが必要とするファイルは「"System.ini"」であり，
「"System.xml"」ファイルは参照していないから，被控訴人プログラムが本件プロ
グラムをデッドコピーして製作されたことは明らかである。
本件プログラムの創作性について
アプログラムにおける具体的表現や記述は，コンピュータによって理解され，
何らかの機能を実現するものであって，表現と機能とは密接不可分であり，独立し
たものではないから，プログラムの機能について主張したからといって，直ちに創
作性がないということはできない。控訴人は，原審において，本件プログラムの表
現上の工夫について，実際の具体的記述に沿って詳細に主張したにもかかわらず，
原判決は表現が実現する機能面だけを取り上げ，創作性を否定した。
イ原判決は，被控訴人プログラムの一部のソースコードについて，第三者
（Baidu社）が提供しているオープンソースソフトウェア（以下「本件オープンソ
ースソフトウェア」という。）であると認定したが，被控訴人プログラムのソース
コードの一部（原判決別紙５）がオープンソースソフトウェアであるとする証拠
（甲１１）は，本件オープンソースソフトウェアとは無関係のウェブ検索結果にす
ぎず，原判決は，証拠に基づかない認定をした。
ウ原判決は，本件プログラム及び被控訴人プログラムにおいて，自動生成され
た部分が存在することを，本件プログラムの創作性を否定する根拠の１つとするが，
「VisualStudio」におけるソースコードの自動生成とは，単に，プログラマが画面
の設計やクラス，構造の設計等を入力する際，その入力データを基に，一部のソー
スコードについてキーボードを叩く作業を軽減し，作業効率を上げるための機能に
すぎず，コーディング作業を一部簡素化する機能は，どのような開発環境であって
も多かれ少なかれ有している機能である。仮に，自動生成された部分があったとし
ても，手打ち入力されたコードと異ならないのであるから，その具体的記述内容の
創作性を検討すべきであり，自動生成であることのみを理由に創作性を否定した原
判決は誤りである。
エ原判決は，本件プログラム及び被控訴人プログラムにおいて，マイクロソフ
ト社が公開している関数の名称の記述など，ありふれた表現が用いられていること
を，本件プログラムの創作性を否定する根拠の１つとするが，著作権法がプログラ
ムの著作物を保護する以上，命令語，関数名等の予約語がありふれたものであると
しても，直ちに作成者の個性が表れていないと解することはできない。
本件プログラムと被控訴人プログラムとの全体的な類似性について
アクラス構造は，プログラムの構成を表すものであり，文学作品でいえば，文
章構成・構造に相当する，いわゆる骨組みといえる部分である。
したがって，どのような構造，構成を採用するかは，製作者の独創性，創造性が
強く発揮される部分である。
イ本件プログラム及び被控訴人プログラムは，クラス構造がほぼ１体１で対応
するほど類似しているのみならず，原判決別紙１ないし１２のとおり，ソースコー
ドの具体的記載においても，キーワード変換をしているものの，その構成，内容，
機能の組合せにおいて，ほぼ同一か，かなり類似している。
例えば，本件プログラムの「CSplasnWnd」クラスと被控訴人プログラムの
「CSplasnBox」とを比較すると，「CSplashBox」は「CSplashWnd」のソースコード
に対してキーワード置換を行った後，コメント部分（機能しない部分）を２行ほど
削除したものであって，両者のソースコードは構造及び表現においてほぼ同じであ
る（原判決別紙５参照）。
また，本件プログラムの「CTaskListPanel」クラスと被控訴人プログラムの
「CTaskListBox」においても，双方に１行ずつの増減があるのみで，キーワード置
換を除けば，両者のソースコードは構造及び表現においてほぼ同じである（原判決
別紙２参照）。
このように，本件プログラムと被控訴人プログラムとを比較すると，ほとんどの
部分が同一又は類似した表現となっており，相違が認められる部分は些細なものに
すぎないから，両者が同一又は類似していることは明らかである。
各クラスにおける同一性又は類似性について
ア原判決別紙１及び２について
被控訴人は，「IMPLEMENT_DYNAMIC」関数はありふれた関数であるとするが，
前記のとおり，命令や関数がありふれていることをもって，直ちに著作権侵害が否
定されるものではなく，用いられた命令や関数が具体的にどのような引数や組合せ
で用いられているかが重要である。被控訴人プログラムの具体的記述は，本件プロ
グラムとは一見異なってみえるものの，それは，被控訴人が本件プログラムのソー
スコードを流用する際，流用の事実を隠匿するために，任意に指定できる関数名を
近い意味の英単語に一括変換しているだけで，新たな創作性が発揮されているわけ
ではない。「IMPLEMENT_DYNAMIC」は，いわゆるオブジェクトクラスの承継命令であ
り，クラス毎にコーディングしていくＣ＋＋
言語における構造部分にも当たる重要な
箇所であるところ，被控訴人プログラムと本件プログラムのソースコードが，同じ
場所で同じように承継命令を記載しているのは，クラス分け（分類と整理）の仕方
がほぼ同じであるからにほかならない。
被控訴人は，３か国言語に対応している部分及び次回の起動時に前回の終了
時の状態から再開できるようにしている部分についても，具体的記述が異なると主
張するが，具体的関数名が一見異なっていても，実質的に見て同じ関数の表記であ
るということができるし，前記と同様に，流用の事実を隠匿するために，任意に
指定できる関数名を近い意味の英単語に一括変換したにすぎない。
イ原判決別紙３について
被控訴人は，「OnSize」メソッドは「VisualStudio」を使って自動生成されるも
のであり，ありふれた表現であると主張する。しかし，当該記述は１６行に及ぶと
ころ，このうち，「VisualStudio」を使って自動生成されるのは４行にすぎず，残
りの１２行についても，本件プログラムと被控訴人プログラムの具体的記述はほと
んど同じである。前記のとおり，純粋な自動生成なる機能は存在せず，単にコーデ
ィングの手間を省くために，コーディング以外の操作をしているにすぎないから，
結果として自動生成されているように見えるコードであっても，単に手入力の手間
やミスを省いたにすぎず，プログラマの意思が反映されたソースコードそのもので
ある。実際，「OnSize」メソッドを用いて上記４行を自動生成させるには，７通り
の手順を踏む必要があり，手順が異なれば，当然，発生するソースコードも異なる。
したがって，わずかな部分が自動生成されたからといって，創作性が否定される
わけではない。
また，本件プログラムは，「OnSize」メソッドを利用することで，ウィンドウの
サイズが変更された場合の挙動についてプログラミングしており，ユーザビリティ
を考慮して縦横ともに任意のサイズへの変更を認めた上，中身もリサイズする仕様
としている点において，創作性を認めることができる。
ウ原判決別紙４について
「m_cbLanguage」をインターネット検索しても，３件又は２件しか検索結果とし
て表示されないから，ありふれた関数であるということはできない。
また，被控訴人プログラムは，①「AddString」命令で文字列を追加している対象
がコンボボックスである点，②コンボボックスに付けられた任意の名称が，同じ
「m_cbLanguage」である点，③加えられる文字列が，プログラム実行時に選択でき
る３か国言語である点，④指摘した部分の行数が同じ４行で，並びも一緒である点
等において，「AddString」関数の利用表現方法が本件プログラムと酷似しているも
のであるから，「AddString」があらかじめ用意された関数であることをもって，直
ちに創作性を否定することはできない。
エ原判決別紙５について
スプラッシュウィンドウの表示について，被控訴人プログラムが本件オープ
ンソースソフトウェアにより作成されていることに関する証拠はない。被控訴人が
根拠として指摘する甲１１は，本件オープンソースソフトウェアとは無関係である。
本件オープンソースソフトウェア開発元のウェブサイトには，被控訴人プログラム
の当該部分と酷似するソースコードが掲載されているが，本件プログラムが納品さ
れた平成２２年１２月２５日の後である平成２３年１２月２７日に掲載が開始され
たものである。
スプラッシュウィンドウをどの程度の時間，表示させるかは，本件プログラ
ムの特性やユーザへの利便性を考えてチューニングした固有の数値である。仮に，
「SetTimer」関数がありふれた表現であったとしても，「SetTimer(1,2000,NULL)」
という表現全体の創作性を否定することはできない。
オ原判決別紙７について
被控訴人プログラムは，「AddPage」関数で追加されるタブ数が本件プログラムと
は異なるが，これは，被控訴人プログラムが本件プログラムを流用した上で，機能
を追加しているからにすぎない。被控訴人プログラムに，被控訴人が流用後に追加
した機能やそれに対応するプログラムやソースコードが存在するからといって，本
件プログラムの著作権侵害を否定する理由とはならない。
また，「AddPage」関数があらかじめ用意された命令であるからといって，直ちに
本件プログラムの創作性を否定することはできない。
カ原判決別紙８及び９について
被控訴人プログラムのパブリッシャー装置の状態を表示する部分は，被控訴人が
本件プログラムのソースコードを流用する際，流用の事実を隠匿するために，任意
に指定できる関数名を近い意味の英単語に一括変換しているだけで，新たな創作性
が発揮されているわけではない。
「SetTimer」関数については，前記エのとおりである。
キ原判決別紙１０について
被控訴人が主張する本件プログラムと被控訴人プログラムとの具体的記述の
相違は，被控訴人が本件プログラムのソースコードを流用する際，流用の事実を隠
匿するために，任意に指定できる関数名を近い意味の英単語に一括変換しているだ
けで，新たな創作性が発揮されているわけではない。
被控訴人プログラムと本件プログラムとは，処理を３つの処理ブロックに分
け，最初の条件に合うものを処理１で，２つめの条件に合うものを処理２で，いず
れの条件にも合わないものを処理３でそれぞれ処理するという大きな分岐処理構造
をほぼ同じ表現によって実現するものである。
被控訴人プログラムと本件プログラムとは，指定されたダイアログボックス
内のコントロールのハンドルを取得するための関数である「GetDlgItem」関数が，
同じ条件分岐の中に数多く記載されている点で共通している。また，取得対象とな
っているダイアログは，両プログラムともジョブのスケジューリング関係のダイア
ログである点についても共通している。「GetDlgItem」関数の数が異なるのは，被
控訴人が控訴人からの著作権侵害という指摘を避けるため，本件プログラムが
「WEEKDAY」と１行で処理している部分について，「SUNDAY」から「SATURDAY」まで
別々にし，単純に行数を増やしたり，機能を追加したことに伴う変更にすぎず，被
控訴人の創作性が発揮されているわけではない。
ク原判決別紙１１について
本件プログラムは，「IMPLEMENT_DYNCREATE」関数を利用することで，「重複ソー
スコードを排除してメンテナンス性の向上を図るとともに承継先クラスの違いを意
識することなく，CIDTaskを扱うことができるように工夫して記述されており，被
控訴人プログラムは，この点で共通している。
ケ原判決別紙１２について
ユーザのメニューアクセス性を向上させている部分については，被控訴人が
本件プログラムのソースコードを流用する際，流用の事実を隠匿するために，任意
に指定できる関数名を近い意味の英単語に一括変換しているだけで，新たな創作性
が発揮されているわけではない。
「AddNotifyIcon」の関数名がありふれていることをもって，直ちに創作性を
否定することはできない。
処理作業中に利用者がアプリケーションの終了処理を行った場合の挙動につ
いて，被控訴人は，控訴人からの著作権侵害という指摘を避けるため，被控訴人プ
ログラムについて，本件プログラムでは，２つの条件がand条件で結ばれたif文を
２つのif文に解体し，さらに，後に出現するメッセージを変数に置き換え，先だっ
て変数にメッセージを代入するという変更を加えたが，この程度の変更が加えられ
ていることをもって，具体的記述が異なるということはできない。
「Delay」関数がありふれていることをもって，直ちに創作性を否定すること
はできない。
アプリケーション終了確認に関する部分について，「Delay」関数自体は，特に引
数に制限や推奨値はなく，プログラマが自由な数値を設定できるところ，本件プロ
グラムでは，本件プログラム上で動く２つのプロセスの終了確認の間隔として最適
な数値として，２つの「Delay」関数において各５００ミリ秒が設定されている。当
該数値は，経験則によりあらかじめ判明していたわけではなく，検証やテストにお
いて得られた最適値として，控訴人の努力や工夫が込められた数値であって，これ
を漫然と流用して「Delay(500)」と記述した被控訴人の著作権侵害は明白である。
被控訴人が，ミリ秒単位で本件プログラムと同じ遅延時間を流用できたことは，被
控訴人プログラムの終了待ち対象の２つのプロセスが本件プログラムとほぼ同じで
あること，すなわち，両プログラムがほぼ同じであることを裏付けるものである。
以上によれば，被控訴人プログラムは，本件プログラムの著作権（複製権又
は翻案権）を侵害しているというべきである。
〔当審における被控訴人の補充主張〕
依拠について
ア被控訴人プログラムは，本件プログラムのデッドコピーではなく，被控訴人
が自ら製作したものである。被控訴人プログラムが本件プログラムに依拠して製作
されたものではないことは，原判決別紙１ないし１２の本件プログラムと被控訴人
プログラムとを対比しても，一致する行が１行もない全く異なるプログラムである
ことからも明らかである。
イ被控訴人プログラムが本件プログラムのデッドコピーであるとする控訴人の
主張は，以下のとおり誤りである。
被控訴人プログラムと本件プログラムとは，少なくとも，①タブの数，②デ
ィスク欄はあるがジョブ欄はない，③ジョブ最大容量欄，④ＤＶＤＤＬ最大容量欄
について異なるものである。
被控訴人プログラムが，本件プログラムをデッドコピーした上で改変を加え
て製作されたものであるならば，コメント部分は中国語ではなく，日本語となるは
ずである。被控訴人は，中国語の開発環境で，プログラムを自動生成する等の方法
によって被控訴人プログラムを開発したからこそ，コメント部分が中国語となって
いるのである。
本件プログラムと被控訴人プログラムとは，プログラムの構造が異なるため，
被控訴人プログラムでは，「System.xml」と「System.ini」の両方が必要となる。
被控訴人は，被控訴人プログラムにふさわしいと考えられる名称をクラス名
や変数名にて使用しているにすぎない。控訴人が主張する置換をしただけでは，本
件プログラムのクラスが被控訴人プログラムのクラスの名称に置換されるものでは
ない。
本件プログラムの創作性について
ア原判決は，本件プログラムの具体的記述における表現上の創作性を有する部
分と被控訴人プログラムの表現上の具体的記述とを対比し，被控訴人プログラムの
具体的記述から本件プログラムの表現上の本質的な特徴を直接感得することができ
るか否かについて検討したものであって，原判決の判断手法及びその結論に誤りは
ない。
イ控訴人は，原判決は本件オープンソースソフトウェアについて証拠に基づか
ない認定をしたと主張するが，同ソフトウェアは本件プログラムの納品日前には既
に公開されていたものである。
ウ「VisualStudio」におけるソースコードの自動生成を用いた場合，例えば，
「OnSize」メソッドにおいて「OnSize」を選択すれば，だれが操作しても，必
ず同じプログラムになるから，このようなプログラムは，「思想又は感情を創作的
に表現したもの」（著作権法２条１項１号）には該当しない。
エ本件プログラム及び被控訴人プログラムの共通部分は，いずれも命令語，関
数名等の予約語等のありふれた表現において共通しているにすぎないのであるから，
これらについて著作権法の保護が及ばないのは当然である。
本件プログラムと被控訴人プログラムとの全体的な類似性について
ア原判決別紙１ないし１２は，控訴人が提出した書証（乙４の１～1４）に基づ
いて作成されたものであるところ，当該書証は，被控訴人プログラムの内容を正確
に反映していない。
例えば，「OnSize」メソッドについて，被控訴人プログラムは空白行も入れて４
３行で構成されているが，原判決別紙３には，そのうち２１行分しか記載されてい
ない。
また，原判決別紙３の「CChildview.cpp」に関する記載においては，被控訴人プ
ログラムから，本件プログラムと一致しないソースコードが約８５行削除されてい
る。
このように，控訴人は，被控訴人プログラムの重要なロジックを削除した上で対
比表を作成しており，同対比表をもってしては，本件プログラムと被控訴人プログ
ラムとの正確な対比はできない。
イ被控訴人プログラムと本件プログラムとでは，実現しようとする機能が異な
るし，動作するハードウェアも，被控訴人プログラムはセイコーエプソン株式会社
（以下「エプソン」という。）製又はRimage社製のディスクパブリッシャーであり，
本件プログラムはPrimera社製のディスクパブリッシャーである点についても異な
るため，全体構造及びクラスの対応関係が一致することはなく，クラス数もソース
コードの分量も全く異なり，クラスが１対１で対応しているわけではない。すなわ
ち，被控訴人プログラムと本件プログラムとは，①クラス数及び分量，②実現しよ
うとする機能，③動作するハードウェア，④表示画面のいずれもが異なる。
また，控訴人が主張する一括置換を行っても，本件プログラムのクラス名称が被
控訴人プログラムのクラス名称に置換されるものではないし，そもそも「CIDJob」
のように１対１で対応していないクラスの場合，一括置換をすること自体，不可能
である。
ウ本件訴訟提起前の交渉段階において，控訴人が被控訴人に対して提示した，
控訴人のエンジニアであるＢが平成２３年１０月１８日に控訴人代表者に対して送
信した電子メール（甲３０。以下「本件メール」という。）には，「NTLからは群
刻で実装された各種重要機能について一切要求も資料も渡されていないのでその部
分は，新高和が自前で企画，開発したものである。完全に無関係である。というわ
けでまともに争って勝てる保障はまったくなく，技術の進歩という点でのNTLの停
滞，怠惰のみが目立つ。裁判所も古い既得権を認めなくなってきているのでどうす
るか？」との記載があり，控訴人も，被控訴人プログラムが本件プログラムに依拠
したものではなく，完全に独立して製作されものであることを認識していたもので
ある。
エ控訴人は，原判決別紙１１（乙４の１３）の１行目に「CsvIDTask.cpp」と記
載されていることをもって，被控訴人プログラムが本件プログラムに依拠して作成
されたことの根拠とするようである。
しかし，「CsvIDTask」の記載が残っているのは，訴訟外において被控訴人が控訴
人から求められたソースコードの対比について準備を行った際の痕跡にすぎない。
すなわち，被控訴人は，「CsvTask.cpp」と「CsvIDTask.cpp」とでは，実装されて
いる内容が全く異なるものの，あえて被控訴人プログラムの「CsvTask.cpp」と対比
するとしたら，本件プログラムの「CsvIDTask.cpp」になるであろうと考え，対比用
のコメント（「CsvTask.cpp」が「CsvIDTask.cpp」に対応する旨のコメント）を被
控訴人プログラムに追加した。しかし，訴訟外での対比は行われなかったため，コ
メント欄の記載を元に戻そうとしたところ，「CsvIDTask.cpp」を削除せずに，誤っ
て「CsvTask.cpp」を削除してしまったものである。
各クラスにおける同一性又は類似性について
ア原判決別紙１及び２について
控訴人の主張は，マイクロソフト社が用意し，世界中のエンジニアが利用し
ているありふれた関数である「IMPLEMENT_DYNAMIC」命令の一般的な使用方法（機能
やアイデア）を説明しているにすぎない。
また，わずか１つの親クラスと１つの子クラスとの関係が類似していることをも
って，ソースコードのクラス分けがほぼ同じであるとはいえないし，クラス分けが
ほぼ同じであることをもって，著作権侵害が認められるものでもない。
控訴人の主張は，機能（アイデア）に関する主張であって表現に関する主張
ではない上，機能としてもありふれている。控訴人は，３か国語で使用できる機能
が同じであることから，文字列として各言語を変数に代入し，文字列を代入した変
数を前提としてプログラミングしていると主張しているものであり，同じプログラ
ムで処理できる部分はできるだけ共通化するというオブジェクト指向プログラムの
基本的な発想の１例を紹介しているにすぎない。このような手法は公知である。
また，被控訴人プログラム（GetString（IDS_JOBS_LIST）と本件プログラム
（LoadResString（IDS_JOBS_LIST））の共通部分は「IDS_JOB_LIST」の部分だけで
あるが，「IDS_」という部分は文法上の規約であり，これらに「JOBS_LIST」という
ありふれた表現を結合させたにすぎないから，創作性がないことは明らかである。
さらに，次回の起動時に，前回の終了時の状態から再開できるようにしていると
いう点もアイデアにすぎず，プログラムにおける具体的記述も異なるものである。
本件プログラムの表現を一括置換した事実もない（一括置換しても，「ALL」という
部分は一致しない。）。
イ原判決別紙３について
控訴人は，「OnSize」メソッドについて，被控訴人プログラムの重要なロジック
に関する部分を削除した上で，本件プログラムと一致するから著作権侵害であると
主張するものであり，失当である。
また，控訴人は，両者が一致すると主張する部分について創作性に係る主張をし
ないが，「m_splitter.MoveWindow」内の計算式が異なる等，表現自体が一致してお
らず，共通部分は，自動生成された部分，マイクロソフト社があらかじめ用意して
いる関数等，ありふれた表現が採用されている部分のみである。
ウ原判決別紙４について
控訴人が使用した検索エンジンとは異なる検索エンジンで「m_cbLanguage」をイ
ンターネット検索すると，多数のプログラム使用例が検索結果として表示されるか
ら，当該関数がありふれた関数であることは明らかである。
また，「AddString」命令で文字列を追加している対象がコンボボックスである点
は，同命令の通常の用法であるし，「m_cbLanguage」自体もありふれた表現である。
３か国語（英語，日本語，中国語）を選択できる点は，表現の問題ではないし，
「自動」「英語」「日本語」「中国語」の順番に並んでいることに創作性はない。
エ原判決別紙５について
本件オープンソースソフトウェアは，複数のサイトで公開されているところ，
遅くとも平成２２年８月１４日には公開されていたから，控訴人が納品日であると
主張する平成２３年１２月２７日の時点では，全世界中のエンジニアが利用できる
公知の情報となっていたことは明らかである。
２０００ミリ秒という設定は，本件オープンソースソフトウェアでも使用さ
れている設定であり，被控訴人が本件プログラムを開発した際，当該設定を参考に
したため，同じ数値となったにすぎない。タイムアウト値として設定される数字は，
１秒，２秒，３秒等のきりのよい数値が採用されることが多く，２０００ミリ秒と
いう設定は，ありふれた設定にすぎない。
オ原判決別紙８及び９について
本件プログラムと被控訴人プログラムでは，インクの残量の表示方法自体，異な
るものである。
カ原判決別紙１０について
控訴人は，本件プログラム及び被控訴人プログラムは大きな分岐処理構造が
ほぼ同じ表現によって実現されていると主張するが，これは，単純に，コンピュー
タ言語の「if文／elseif文」の一般的な使用方法について説明しているにすぎな
い。しかも，本件プログラムは，if文の中に，さらにif文が記述される入れ子の
構造が採用されているのに対し，被控訴人プログラムは，入れ子の構造が採用され
ていないという点においても異なる。
控訴人は，「GetDlgItem」関数の数が異なるのは，被控訴人が控訴人からの
著作権侵害という指摘を避けるために，本件プログラムが１行で処理している部分
について別々にし，単純に行数を増やすなどしたにすぎないなどと主張するが，そ
もそも表現自体が一致していないのみならず，控訴人の主張によっても，被控訴人
プログラムでは「GetDlgItem」関数が４９回も用いられているのに対し，本件プロ
グラムでは同関数が１４回しか用いられておらず，両者には３５行分もの差がある
ことについて，合理的な説明がされているわけではない。
キ原判決別紙１１について
控訴人の主張は，マイクロソフト社が用意し，世界中のエンジニアが利用してい
るありふれた関数である「IMPLEMENT_DYNCREATE」命令の一般的な使用方法（機能や
アイデア）を説明しているにすぎない。
ク原判決別紙１２について
ユーザのメニューアクセス性を向上させている部分については，アイデアに
係る主張にすぎない。しかも，被控訴人プログラムにおけるメニューでは，本件プ
ログラムと同様の「メニューアクセス性を向上させる」工夫は採用されていない。
控訴人は，被控訴人が一括置換をしたなどと主張するが，略語の意味を省略
しないで表示した上で一括置換するという迂遠な方法を用いる必要性は乏しい。
しかも，例えば，「OnSysHFMStart」関数について控訴人が主張する一括置換を行
うと，「OnSysHotFolderListenerStart」となるはずであるが，これは，被控訴人プ
ログラムの「OnHFLStart」とは一致しない。
処理作業中に利用者がアプリケーションの終了処理を行った場合の挙動に係
る控訴人の主張は，ソフトウェア開発における常識的な処理を本件プログラム及び
被控訴人プログラムが採用していることを意味するにすぎず，機能（アイデア）と
してありふれたものにすぎない。
また，本件プログラムではメッセージとして表示する内容をあらかじめ定義して
いるため，if文の中の条件式が整理されているのに対し，被控訴人プログラムでは
条件式自体が非常に複雑になっている点において，本件プログラムではif文の中で
さらにif文を使用しているが，被控訴人プログラムではそのようになっていない点
において，表示されるメッセージの具体的な内容も異なる点において，両者は明ら
かに異なる表現となっており，表現の共通性自体が存在しない。
「Delay」関数においては，ミリ秒単位で数値を設定することが可能であると
ころ，通常では０．５秒（５００），１秒（１０００），２秒（２０００）等のき
りのよい数値が使用されているから，５００ミリ秒に設定されたことに創作性を認
める余地はない。
以上によれば，被控訴人プログラムは，本件プログラムの著作権（複製権又
は翻案権）を侵害しているということはできない。
したがって，被控訴人が被控訴人プログラムを製造，販売する行為が，控訴人が
保有する本件プログラムの著作権（複製権又は翻案権及び譲渡権）の侵害行為に該
当するとの控訴人の主張は理由がないから，控訴人が，被控訴人に対し，著作権法
１１２条１項に基づく被控訴人プログラムの製造，販売の差止請求権を有するもの
とは認められない。
２争点２（被控訴人が被控訴人プログラムを製造，販売する行為についての不
正競争防止法２条１項７号の不正競争行為の成否）について
〔当審における控訴人の補充主張〕
本件プログラムに関するアイデアについて
ア営業秘密の内容について
原判決は，被控訴人が本件プログラムの表現上の創作性を有する部分を使用して
被控訴人プログラムを製造し，販売したものとはいえない以上，営業秘密の不正使
用には該当しないとするが，控訴人の主張を誤解するものである。控訴人は，原判
決別紙１ないし１２の対照表の一致又は類似したプログラムの各箇所における本件
プログラムそのものが，表現であると同時に製作のアイデア（以下「本件アイデ
ア」という。）を表すものであり，秘密として管理されている営業秘密であると主
張するものである。
すなわち，控訴人は，本件プログラムのソースコードのみならず，控訴人の従業
員であるＢが本件プログラムの製作を指示する際に開示した情報（乙３２添付の表
に記載された情報）及び本件プログラム製作の前提となるアイデアの営業秘密性を
主張するものである。
被控訴人は，控訴人から本件アイデアに基づく指示を受けて，本件プログラムを
製作して納品しておきながら，秘かに同じアイデアに基づき被控訴人プログラムを
製作して，控訴人と競合して販売しているのである。
イ秘密管理性について
控訴人と被控訴人との間には，本件業務委託基本契約のほか，平成１９年１
０月１日付けシステムエンジニアリング・サービス契約（以下「本件ＳＥサービス
契約」という。）及び同日付け秘密保持契約（以下「本件秘密保持契約」とい
う。）が締結され，被控訴人は，控訴人に対し，上記各契約の守秘義務条項のほか，
開発管理規程（乙３６），誓約書（乙３７），アクセス管理規則（乙３８）に基づ
いて，さらには，いわゆる善管注意義務及び契約当事者間に認められる当然の保護
義務として，守秘義務を負っていたものである。
本件ＳＥサービス契約９条１項ただし書において，被控訴人の従業員が控訴人の
構内若しくは控訴人の指定する作業場所に駐在して知り得た情報については，秘密
情報である旨の特定及び表示の有無にかかわらず，秘密情報と同様に扱うものとさ
れている。控訴人の担当者は，控訴人の構内において，被控訴人の担当者に対し，
本件プログラムの製作について指示を行い，本件アイデアを開示したのであるし，
控訴人が指定した上海の被控訴人の事業所において被控訴人が知り得た情報（控訴
人からの業務受託により生成した情報）も，秘密情報として扱われることになる。
被控訴人は，営業秘密である旨の表示がされていないなどと主張するが，機密で
ある旨の表示とは，機密という文言が明記されていなければならないというもので
はなく，機密である旨の趣旨を読み取ることができれば足りる。アクセス管理規則，
誓約書及び開発管理規程の存在自体が，機密である旨を表示するものであるという
ことができる。
本件プログラムは，製作時においても製作担当者以外はアクセスしてはなら
ない仕組みになっており，完成したソースコードは，控訴人のサーバで厳格に秘密
として管理され，特別なパスワードを用いなければアクセスできなかったから，秘
密管理性が認められる。
本件要望事項について
ア原判決は，本件要望事項それ自体が控訴人において秘密として管理されてい
たことを認めるに足りる証拠はないとするが，本件業務委託基本契約に基づいて控
訴人から受託して営業活動を行った被控訴人が守秘義務を負っていたことは，前記
のとおりである。それにもかかわらず，被控訴人が本件要望事項を秘密として管
理していなかったのであれば，むしろ被控訴人の債務不履行であり，そのことによ
り営業秘密性が否定されるのは背理である。
イ原判決は，被控訴人が本件要望事項を利用し，これを搭載した被控訴人プロ
グラムを製造したことについての具体的な主張立証はないとするが，被控訴人プロ
グラムが本件要望事項に対応した新機能を有していること自体は当事者間に争いが
ない。被控訴人は，本件要望事項を知りながら，本件プログラムと競合する被控訴
人プログラムをエプソンチャイナ社に売り込んだのであるから，本件要望事項を満
たす機能を追加するのは当然である。
〔当審における被控訴人の補充主張〕
本件プログラムに関するアイデアについて
ア営業秘密の内容について
控訴人は，控訴人及び被控訴人間の本件業務委託基本契約の守秘義務条項等に基
づいて，本件アイデア及び本件要望事項が営業秘密であると主張する。
しかしながら，控訴人が主張する各契約は，守秘義務の対象を明確化するために，
営業秘密の定義規定を設け，不正競争防止法における「営業秘密」より狭い範囲の
情報に対してのみ，秘密保持義務を課すものであるところ，上記各事項は，いずれ
も秘密である旨が表示されるなどの要件を充足するものではないから，控訴人の主
張は失当である。
イ本件プログラムについて
本件プログラムと被控訴人プログラムとは，マイクロソフト社が提供している関
数，オープンソースソフトウェア，自動生成されるプログラム等が一致しているに
すぎず，これらのありふれた表現は，非公知性及び秘密管理性の要件を具備しない。
しかも，本件メールに記載されているとおり，控訴人も，被控訴人が控訴人から
営業秘密を開示されておらず，これを使用していないことを認識していたというほ
かない。
本件要望事項について
アエプソンチャイナ社が控訴人に対して本件要望事項を伝えていたのであれば，
これらの機能を開発することは容易なはずであるが，控訴人が本件プログラムをエ
プソンチャイナ社に販売できていないことからすると，そもそも控訴人がこのよう
な要望事項をエプソンチャイナ社から聞いていないものと推測される。
したがって，本件要望事項は，エプソンチャイナ社がディスクパブリッシャー用
ソフトウェアを購入する前提条件であるということはできないから，有用性はない
というべきである。
イ被控訴人は，控訴人から本件要望事項を示されたことはないし，Ａが控訴人
の代理人としてエプソンチャイナ社と交渉した事実もない。控訴人は，エプソンチ
ャイナ社の関連会社であるエプソン社及びエプソン販売社の担当者と知り合いであ
ったのであるから，Ａを代理人とする必要性はない。控訴人は，自ら営業秘密であ
ると主張する本件要望事項の入手経緯自体把握しておらず，秘密管理性を認めるこ
ともできない。
被控訴人は，被控訴人の製品に興味を抱いた方正集団（エプソンチャイナ社の販
売代理店）から要望を受け，エプソン社製のディスクパブリッシャーに対応する被
控訴人プログラムを開発したにすぎない。
第４当裁判所の判断
当裁判所も，被控訴人の本訴請求は，いずれも理由があり，これを認容すべきも
のと判断する。その理由は，次のとおりである。
１争点１（被控訴人が被控訴人プログラムを製造，販売する行為についての本
件プログラムの著作権（複製権又は翻案権及び譲渡権）侵害の成否）について
プログラムの著作物性の判断基準
アある表現物が，著作権法の保護の対象となる著作物に当たるというためには，
思想，感情を創作的に表現したものであることが必要であり，創作的に表現したも
のというためには，作成者の何らかの個性が発揮されたものであることが必要であ
る。この点は，プログラムであっても異なるところはないが，プログラムは，「電
子計算機を機能させて一の結果を得ることができるようにこれに対する指令を組み
合わせたものとして表現したもの」（著作権法２条１項１０号の２）であり，所定
のプログラム言語，規約及び解法に制約されつつ，コンピュータに対する指令をど
のように表現するか，その指令の表現をどのように組み合わせ，どのような表現順
序とするかなどについて，著作権法により保護されるべき作成者の個性が表れるこ
とになる。
したがって，プログラムに著作物性があるというためには，指令の表現自体，そ
の指令の表現の組合せ，その表現順序からなるプログラムの全体に選択の幅があり，
かつ，それがありふれた表現ではなく，作成者の個性，すなわち，表現上の創作性
が表れていることを要する。
イ著作物の複製（著作権法２１条，２条１項１５号）とは，既存の著作物に依
拠し，その内容及び形式を覚知させるに足りるものを再製することをいう（最高裁
昭和５０年（オ）第３２４号同５３年９月７日第一小法廷判決・民集３２巻６号１
１４５頁参照）。ここで，再製とは，既存の著作物と同一性のあるものを作成する
ことをいうと解すべきであるが，同一性の程度については，完全に同一である場合
のみではなく，多少の修正増減があっても著作物の同一性を損なうことのない，す
なわち実質的に同一である場合も含むと解すべきである。
次に，著作物の翻案（同法２７条）とは，既存の著作物に依拠し，かつ，その表
現上の本質的な特徴の同一性を維持しつつ，具体的表現に修正，増減，変更等を加
えて，新たに思想又は感情を創作的に表現することにより，これに接する者が既存
の著作物の表現上の本質的な特徴を直接感得することのできる別の著作物を創作す
る行為をいう。そして，著作権法は，思想又は感情の創作的な表現を保護するもの
であるから（同法２条１項１号），既存の著作物に依拠して創作された著作物が思
想，感情若しくはアイデア，事実若しくは事件など表現それ自体でない部分又は表
現上の創作性がない部分において，既存の著作物と同一性を有するにすぎない場合
には，複製にも翻案にも当たらないものと解するのが相当である（最高裁平成１１
年（受）第９２２号同１３年６月２８日第一小法廷判決・民集５５巻４号８３７頁
参照）。
このように，複製又は翻案に該当するためには，既存の著作物とこれに依拠して
創作された著作物との同一性を有する部分が著作権法による保護の対象となる思想
又は感情を創作的に表現したものであることが必要である。
そして，「創作的」に表現されたというためには，厳密な意味で独創性が発揮さ
れたものであることは必要ではなく，筆者の何らかの個性が表現されたもので足り
るというべきであるが，他方，プログラムの具体的記述自体がごく短く又は表現上
制約があるため他の表現が想定できない場合や，表現が平凡かつありふれたもので
ある場合には，作成者の個性が表現されたものとはいえないから，創作的な表現で
あるということはできない。
本件プログラムの表現上の創作性について
被控訴人は，原判決別紙１ないし１２のとおり，本件プログラムと被控訴人プロ
グラムとを対比した上で，各クラスにおける同一性又は類似性について具体的に主
張する。
そこで，以下，被控訴人の上記主張について検討する。
ア原判決別紙１及び２について
IMPLEMENT_DYNAMIC命令について
本件プログラムの記述は，「IMPLEMENT_DYNAMIC（CjobsListPanel，CPanel）」で
あり，被控訴人プログラムの記述は，「IMPLEMENT_DYNAMIC（CProjectListBox，
CBox）」である。
本件プログラムと被控訴人プログラムとの共通部分は，「IMPLEMENT_DYNAMIC命
令」を使用している部分であるが，証拠（甲２２）によれば，「IMPLEMENT_DYNAMIC
命令」は，マイクロソフト社があらかじめ用意している関数であるから，当該関数
を使用していることをもって，当該表現に創作性を認めることはできない。
控訴人は，“CJobListPanelや”CTaskListPanel”の各クラスの上位クラスとし
て“CPanel”クラスを用意し，共通機能を“CPanel”クラスにまとめ，
“CJobListPanelや”CTaskListPanel”を派生クラスと定義することにより，同じ
機能を実現するに当たり，記述の重複やコーディング量を減らす等の表現の工夫を
しているなどと主張する。
しかしながら，控訴人の上記主張は，「IMPLEMENT_DYNAMIC命令」の一般的な機
能を用いたプログラム作成上の工夫（アイデア）を説明するものにすぎず，上記共
通部分に係る創作性について具体的に主張するものではない。
また，控訴人は，「IMPLEMENT_DYNAMIC」は，いわゆるオブジェクトクラスの承継
命令であり，クラス毎にコーディングしていくＣ＋＋
言語における構造部分にも当た
る重要な箇所であるところ，被控訴人プログラムと本件プログラムのソースコード
が同じ場所で同じように承継命令を記載しているのは，クラス分けの仕方がほぼ同
じであるからにほかならないなどと主張するが，クラス分け（分類と整理）の仕方
は，プログラムのアイデア又は解法に当たるものであって，プログラムの表現上の
創作性を認める根拠となるものではない。
したがって，控訴人の上記主張はいずれも採用することができない。
３か国語対応について
本件プログラムの記述は，「LoadResString（IDS_JOBS_LIST）」であり，被控訴
人プログラムの記述は，「GetString（IDS_JOBS_LIST）」である。
上記各記述のうち，「LoadResString」と「GetString」は，機能が共通するとし
ても，具体的表現が異なることは明らかである。
そして，本件プログラムと被控訴人プログラムとの共通部分は，
「IDS_JOB_LIST」の部分であるが，証拠（甲２９）によれば，このうち，「IDS_」
の部分は文法上の規約に基づいて記載されたものである。また，「JOBS_LIST」の部
分は，ジョブのリストを意味するものであり，ありふれた表現を結合させた記述に
すぎないから，創作性を認めることはできない。
次回起動時の処理について
本件プログラムの記述は，以下のとおりである。
「theApp.m_jobMonitor.LoadJobs（）；」
「theApp.m_jobMonitor.SaveJobs（）；」
また，被控訴人プログラムの記述は，以下のとおりである。
「theApp.m_projectListener.LoadAllProjects（）；」
「theApp.m_projectListener.SaveAllProjects（）；」
このうち，「m_projectListener.SaveAllProjects」「m_jobMonitor.SaveJobs」
と「m_projectListener.LoadAllProjects」「m_jobMonitor.LoadJobs」とは，意味
自体は類似するものの，表現が異なることは明らかである。
そして，本件プログラムと被控訴人プログラムとの共通部分は，「theApp.
….Load…（）；」「theApp.….Save…（）；」の部分であるが，このうち，
「theApp」の部分はアプリケーションのオブジェクトであることを意味するもので
あり，「Load」「Save」の部分は読み出し・書き込みを意味する語として，いずれ
もありふれた表現にすぎず，創作性を認めることはできない。
控訴人は，本件プログラム及び被控訴人プログラムの３か国言語に対応している
部分及び次回の起動時に前回の終了時の状態から再開できるようにしている部分は，
具体的関数名が一見異なっていても，実質的に見て同じ関数の表記であるというこ
とができるし，被控訴人は，控訴人プログラムの流用の事実を隠匿するために，任
意に指定できる関数名を近い意味の英単語に一括変換したなどと主張する。
しかしながら，控訴人の主張は，上記各プログラムがいずれも３か国語に対応し，
次回の起動時に前回の終了時の状態から再開できる機能を有していることを主張す
るものにすぎず，プログラムの表現の創作性を認める根拠となるものではない。
また，控訴人の主張する一括置換をしても，「ALL」という部分は一致しないから，
一括置換をしただけでは，同一の記述となるものでもない。
したがって，控訴人の上記主張は採用することができない。
イ原判決別紙３について
証拠（甲９）によれば，「OnSize」メソッドをAdd（追加）する指示をすれば，
「OnSize」メソッドが生成され，原判決別紙３の「voidCChildView::OnSize(UINT
nType,intcx,intcy)CWnd::OnSize(nType,cx,cy)」までの部分は自動的に生
成されるものと認められるから，当該部分は控訴人が記述したものということはで
きず，創作性を認めることはできない。また，証拠（甲３２～３９）によれば，本
件プログラム及び被控訴人プログラムの上記部分以降において共通して用いられて
いるCRect，rcClient，GetClientRect，IsWindow，m_splitter，GetSafeHwnd，
SetColumnInfo，Recalclayoutは，いずれもマイクロソフト社が用意している関数
名であるか，分割ウィンドウを使用する際にプログラマが一般的に使用するありふ
れた名称であると認められる。
したがって，原判決別紙３において，本件プログラムの創作性を認めることはで
きない。
控訴人は，本件プログラムは「OnSize」メソッドを利用することで，ユーザビリ
ティを考慮して縦横ともに任意のサイズへの変更を認めた上，中身もリサイズする
仕様としている点において，創作性を認めることができるなどと主張するが，これ
らはプログラムの機能（アイデア）に当たるものであって，プログラムの表現の創
作性を認める根拠となるものではない。
したがって，控訴人の上記主張は採用することができない。
ウ原判決別紙４について
本件プログラムの記述は，以下のとおりである。
m_cbLanguage.AddString（_T（”Automatically”））;
m_cbLanguage.AddString（_T（”English”））;
m_cbLanguage.AddString（_T（”日本語”））;
m_cbLanguage.AddString（_T（”筒体中文”））;
また，被控訴人プログラムの記述は，以下のとおりである。
m_cbLanguage.AddString（GetString（IDS_AUTOMATICALLY））；
m_cbLanguage.AddString（GetString（IDS_ENGLISH））；
m_cbLanguage.AddString（GetString（IDS_JAPANESE））；
m_cbLanguage.AddString（GetString（IDS_CHINESE））；
そして，「cb」は，コンボボックス（combobox）の頭文字からなる文字列であり，
コンボボックスを意味する表現として慣用されるものと認められるところ（甲１
０），本件プログラムと被控訴人プログラムとの共通部分である
「m_cbLanguage.AddString」のうち，「m_cbLanguage」は，コンボボックス（combo
box）で「言語」（Language）を選択するための関数であるため，comboboxの頭文
字とLanguageとを結合した表現であることは明らかである。また，証拠（甲１
０）によれば，AddStringは，マイクロソフトがあらかじめ用意していた関数名で
あると認められるから，「m_cbLanguage.AddString」は，「m_cbLanguage」という
文字列とAddStringとを文法に従って結合させたものにすぎず，創作性を認めるこ
とはできない。
控訴人は，「m_cbLanguage」をインターネット検索しても，３件又は２件しか検
索結果として表示されないから，ありふれた関数であるということはできない，被
控訴人プログラムは，①「AddString」命令で文字列を追加している対象がコンボボ
ックスである点，②コンボボックスに付けられた任意の名称が，同じ
「m_cbLanguage」である点，③加えられる文字列が，プログラム実行時に選択でき
る３か国言語である点等において，「AddString」関数の利用表現方法が本件プログ
ラムと酷似していると主張する。
しかしながら，上記のとおり，「m_cbLanguage」は，comboboxの頭文字と
Languageとを結合した表現にすぎず，インターネット検索において数件しか検索結
果として表示されないことをもって，創作性を認めることはできない。また，①及
び②の事項は，上記のとおり，使用言語を選択可能とする機能を実現するために採
用されたありふれた記述にすぎず，③の事情は，３か国言語に対応するという機能
を意味するにすぎない。
また，控訴人は，画面上のコンボボックスから３つの利用言語を即時に変更可能
とすることにより，ユーザビリティの向上を図っているとも主張するが，これはプ
ログラムの機能（アイデア）に当たるものであって，プログラムの表現の創作性を
認める根拠となるものではない。
したがって，控訴人の上記主張はいずれも採用することができない。
エ原判決別紙５について
証拠（甲９，２３）によれば，原判決別紙５に係る本件プログラムの記述は，
遅くとも平成２２年８月１４日にはBaidu社から公開され，同年１２月２５日の時
点では公知となっていた本件オープンソースソフトウェアを用いたものであると認
められる。
したがって，本件プログラムと被控訴人プログラムとの間において，本件オープ
ンソースソフトウェアを用いた部分が共通するとしても，本件プログラムの著作権
を侵害するものということはできない。
控訴人は，原判決が，同判決第３の１アｄの被控訴人の主張を援用して，本
件オープンソースソフトウェアに係る書証として摘示した甲１１が本件オープンソ
ースソフトウェアとは無関係であることを前提に，被控訴人プログラムが本件オー
プンソースソフトウェアにより作成されていることに関する証拠はないと主張する
が，甲１１は甲９の誤記と認められるから，控訴人の上記主張はその前提自体を欠
き理由がない。
「SetTimer」関数は，指定されたタイムアウト値を持つ１個のタイマを作成
する機能に関し，マイクロソフト社があらかじめ用意している関数であり（甲１
３），任意に設定可能であるタイムアウト値として２０００ミリ秒（２秒）を選択
したことをもって，プログラムの表現上の創作性を認めることはできない。
控訴人は，スプラッシュウィンドウをどの程度の時間表示させるかは，本件プロ
グラムの特性や利便性を考えてチューニングした固有の数値であり，仮に，
「SetTimer」関数がありふれた表現であったとしても，「SetTimer(1,2000,NULL)」
という表現全体の創作性を否定することはできないなどと主張するが，これはプロ
グラムの機能（アイデア）に当たるものであって，プログラムの表現の創作性を認
める根拠となるものではない。
したがって，控訴人の上記主張は採用することができない。
オ原判決別紙６について
本件プログラムの記述は，「CStringLoadResString（UINTnID）；」であり，被
控訴人プログラムの記述は，「CStringGetString（UINTnID）；」である。
本件プログラムと被控訴人プログラムとの共通部分のうち，「CString」は，マイ
クロソフト社が用意した文字列に関するクラスの名称であり（甲２５），「UINT」
は，データの型名であり文法で定められた表現にすぎない（甲２６）。また，
「nID」という変数名もありふれた表現である（甲２７）から，創作性を認めること
はできない。
控訴人は，画面に表示する文字について，本件プログラムは「LoadResString」関
数を定義・利用し，その関数中で多言語処理を行わせることによって，呼出元では
使用言語を意識しないように工夫しているところ，被控訴人プログラムは，
「GetString」関数を定義し，本件プログラムと同様に多言語処理を関数内で行わせ
ることにより，呼出元では言語を意識しなくてもよいような作りとなっているなど
と主張する。
しかしながら，多言語処理を関数内で行わせることにより，呼出元では言語を意
識しなくてもよいようにする点は，プログラムの機能（アイデア）に当たるもので
あって，プログラムの表現上の創作性を認める根拠となるものではない。
したがって，控訴人の上記主張は採用することができない。
カ原判決別紙７について
本件プログラムの記述は，以下のとおりである。
AddPage（&m_normalPage）;
AddPage（&m_discFormatPage）;
AddPage（&m_capacityPage）;
AddPage（&m_primeraPage）;
また，被控訴人プログラムの記述は，以下のとおりである。
AddPage（&m_normalPage）;
AddPage（&m_jobPage）;
AddPage（&m_discFormatPage）;
AddPage（&m_mailPage）;
AddPage（&m_encryptPage）;
AddPage（&m_supSavPage）;
AddPage（&m_multiConnectionPage）;
AddPage（&m_hfPage）;
AddPage（&m_rimagePage）;
本件プログラムと被控訴人プログラムとの共通部分は，「AddPage
（&m_normalPage）」，「AddPage（&m_discFormatPage）」の２行であるが，
「AddPage」は，マイクロソフト社があらかじめ用意している命令である（甲１４）。
また，引数の「&m_normalPage」，「&m_discFormatPage」は，「AddPage」の対象が
「normalPage」及び「discFormatPage」であることを意味するものにすぎず，創作
性を認めることはできない。
控訴人は，本件プログラムでは，“AddPage”命令を用いて機能ごとにグルーピン
グしてタブを設け，複数のタブを切り替え表示することにより，１画面に表示され
る情報量を少なくし，利用者の使い勝手をよくするよう工夫されているところ，被
控訴人プログラムは「AddPage」関数で追加されるタブ数が本件プログラムとは異な
るが，これは，被控訴人プログラムが本件プログラムを流用した上で機能を追加し
ているからにすぎず，被控訴人プログラムに，被控訴人が流用後に追加した機能や
それに対応するプログラムやソースコードが存在するからといって，本件プログラ
ムの著作権侵害を否定する理由とはならないなどと主張するが，これはプログラム
の機能（アイデア）に当たるものであって，プログラムの表現上の創作性を認める
根拠となるものではない。
したがって，控訴人の上記主張は採用することができない。
キ原判決別紙８及び９について
本件プログラムの記述は，以下のとおりである。
DrawRobot（&dc）;
DrawInk（&dc）;
DrawDisc(&dc);
DrawDriver（&dc）;
また，被控訴人プログラムの記述は，以下のとおりである。
DrawPublisher（&dc）;
DrawInk（&dc）;
DrawBins（&dc）;
本件プログラムと被控訴人プログラムとの共通部分である「DrawInk
（&dc）」は，表示に関する命令（「Draw」）に対象物（「Ink」）を結合させた記
述にすぎず，パブリシャー装置のインクの残量の状態を表示させる命令として，創
作性を認めることはできない。
控訴人は，〝DrawRobot″，〝DrawInk″，〝DrawDisc″命令でパブリシャー装置
の状態を表示して利用者の便宜を図るように工夫しているなどと主張するが，これ
はプログラムの機能（アイデア）に当たるものであって，プログラムの表現の創作
性を認める根拠となるものではない。
したがって，控訴人の上記主張は採用できない。
「SetTimer」関数については，前記エで述べたとおりであり，創作性を認
めることはできない。
ク原判決別紙１０について
本件プログラムの記述は，以下のとおりである。
if(CSV_JOB==m_nJobType)
（本件プログラムは，これに続いて，「GetDlgItem」命令を１９回，if文を３回使
用している。）
elseif(FOLDER_JOB==m_nJobType)
また，被控訴人プログラムの記述は，以下のとおりである。
if（NORMAL_PROJECT=m_nProjectType）
（被控訴人プログラムは，これに続いて，「GetDlgItem」命令を４７回使用して
いるが，if文は使用していない。）
elseif(FOLDER_PROJECT==m_nProjectType)
本件プログラムと被控訴人プログラムとの共通部分のうち，if文/elseif文
は，条件に応じた処理において一般的に用いられるところ，本件プログラムと被控
訴人プログラムとは，具体的な判断条件の表現が異なっている。
また，if文に続く部分は，「GetDlgItem」命令が記述されていることは共通して
いるものの，if文の利用の有無が異なっているのみならず，「GetDlgItem」命令の
使用回数が大きく異なっている以上，各命令文の表現が一致しているとはいえない。
そして，「GetDlgItem」命令は，マイクロソフト社があらかじめ用意している関
数（甲１５）であるから，本件プログラムの上記記述に創作性を認めることはでき
ない。
控訴人は，本件プログラムは，利用者がいちいち本件プログラムを操作しなくて
も書き込みが開始できる仕組みとして，①外部のコンピュータでCSVファイルを用
意して，そのファイルを特定のフォルダに保存した時点で，CSVファイルの内容に
従って書き込みを開始する方法（CSVジョブ）と，②フォルダの容量を監視して一
定容量を超えた際に書き込みを開始する方法（フォルダジョブ）を用意し，遠隔地
からの処理や自動処理に対応する機能を備えているなどと主張するが，これはプロ
グラムの機能（アイデア）に当たるものであって，プログラムの表現の創作性を認
める根拠となるものではない。
控訴人は，被控訴人プログラムと本件プログラムとは，処理を３つの処理ブロッ
クに分け，最初の条件に合うものを処理１で，２つめの条件に合うものを処理２で，
いずれの条件にも合わないものを処理３でそれぞれ処理するという大きな分岐処理
構造をほぼ同じ表現によって実現するものであると主張する。
しかしながら，分岐構造は，アルゴリズム（解法）に属するものであるのみなら
ず，控訴人の主張する上記分岐構造は，プログラムの処理上，一般的に行われてい
るものである（甲２８）。このような分岐構造をif文/elseif文を用いて実現す
ることは，if文/elseif文の一般的な使用方法というべきであって，分岐構造が共
通することをもって，著作権侵害を認めることはできない。
したがって，控訴人の上記主張はいずれも採用することができない。
ケ原判決別紙１１について
「IMPLEMENT_DYNCREATE」関数については，前記アと同様に，当該表現に創作性
を認めることはできない。
コ原判決別紙１２について
AddNotifyIcon等について
本件プログラムの記述は，以下のとおりである。
AddNotifyIcon();
OnSysHFMStart();
OnSysJMStart();
OnSysTMStart();
また，被控訴人プログラムの記述は，以下のとおりである。
AddNotifyIcon();
OnHFLStart();
OnPLStart();
OnTLStart();
本件プログラムと被控訴人プログラムとの共通部分は，関数名として
「AddNotifyIcon()」を使用している部分であるが，証拠（甲１７）によれば，
「AddNotifyIcon()」は，関数名として一般的に多数使用されているものと認められ
るから，当該記述に創作性を認めることはできない。
控訴人は，ユーザのメニューアクセス性を向上させるため，Windowsのタスクト
レイにアイコンを表示し，それを右クリックするとメニューが選択できるように工
夫しているなどと主張するが，これはプログラムの機能（アイデア）に当たるもの
であって，プログラムの表現の創作性を認める根拠となるものではない。
アプリケーションの終了処理について
本件プログラムの記述は，以下のとおりである。
if(theApp.m_taskMonitor.IsExistUnFinishedTasks()
&&AfxMessageBox(_T("Therearesomeunfinishedtask(s).")
_T("￥nTheexactstatuswillloseifyouclosetheapplication.
￥nAreyousuretocloseit?"),MB_YESNO)!=IDYES)
{
m_bCloseSelected=FALSE;
END_SIGN_LOCK(theApp.m_taskMonitor.m_bListCtrlAccessAble)
return;
}
被控訴人プログラムの記述は，以下のとおりである。
双方の記述を対比すると，まず，本件プログラムと被控訴人プログラムとの共通
部分であるif文において，具体的な判断条件である括弧内の表現が異なっている。
また，被控訴人プログラムにおいては，if文の条件が成立した場合に実行される命
令列中に，さらにif文を使用して条件を判断しているのに対して，本件プログラム
にはそのような記述はない。
しかも，前記のとおり，if文は条件に応じた処理に一般的に用いられるものであ
るのみならず，「AfxMessageBox」関数は，あらかじめマイクロソフト社が用意して
いる関数（甲１８）であるから，いずれもありふれた表現にすぎず，当該記述に創
作性を認めることはできない。
控訴人は，アプリケーションの終了処理に際し，ディスクへの書き込み作業等が
終了する前にアプリケーションが終了し，不具合が生じてしまうことを避けるため，
一定間隔で作業の終了確認を行い，終了が確認できた場合に限り，アプリケーショ
ンが終了するように工夫しているなどと主張するが，これはプログラムの機能（ア
イデア）に当たるものであって，プログラムの表現上の創作性を認める根拠となる
ものではない。
whileループ文の中のDelay命令について
本件プログラムの記述は，以下のとおりである。
while（theApp.m_jobMonitor.IsWorking()）
Delay(500，FALSE);
while（theApp.m_taskMonitor.IsWorking()）
Delay(500，FALSE);
また，被控訴人プログラムの記述は，以下のとおりである。
while（theApp.m_projectListener.IsRunning()）
Delay(500，FALSE);
while（theApp.m_taskListener.IsRunning()）
Delay(500，FALSE);
本件プログラムと被控訴人プログラムとの共通部分は，while文及び「Delay」関
数を使用している点及び「Delay」関数の引数であるが，while文は文法上定められ
た表現であり（甲１９），「Delay」関数は，時間待ちの機能を実現するためにエン
ジニアが一般的に使用するありふれた関数名である（甲２０）から，当該記述に創
作性を認めることはできない。
控訴人は，アプリケーションの終了処理に際し，一定間隔で作業の終了確認を行
い，終了が確認できた場合に限り，アプリケーションが終了するように工夫してい
るが，その間隔が短すぎればその確認自体の処理の重さから終了処理が遅れる本末
転倒の事態が生じかねず，逆に確認処理間隔が長すぎれば，すでに終了処理が終わ
っていても，アプリケーションが終わらないという無駄な時間が生じてしまうため，
両者のバランスを考慮した結果，終了確認の間隔を５００ミリ秒に調整したなどと
主張するが，これはプログラムの機能（アイデア）に当たるものであって，
「Delay」関数において，遅延させる数値を０．５秒（５００）に設定したことをも
って，プログラムの表現上の創作性を認めることはできない。
したがって，控訴人の上記主張は採用することができない。
サ小括
以上のとおり，控訴人の指摘する本件プログラムと被控訴人プログラムとの共通
部分において，本件プログラムの表現上の創作性を認めることができない以上，被
控訴人プログラムが本件プログラムを複製又は翻案したものということはできない。
控訴人は，そのほか，被控訴人プログラムは，本件プログラムを複製（デッドコ
ピー）し，一部改変を加えて作成したものであるから，本件プログラムに依拠して
作成された複製物又は翻案物であると主張し，その根拠として，本件プログラム及
び被控訴人プログラムの画面の構成（表現）は酷似していること，クラス構造が類
似していることなどを指摘する。
しかしながら，同一の機能を有するプログラムが複数存在し得る以上，プログラ
ムを実行した際の画面が類似するからといって，直ちにプログラムの著作権の侵害
を根拠付けるものではないことは明らかである。クラス構造も，プログラムに係る
具体的な記述ということはできない。原判決別紙１ないし１２における本件プログ
ラムと被控訴人プログラムとの具体的対比によれば，被控訴人プログラムの記述は，
本件プログラムの記述と相当程度異なっており，被控訴人プログラムが本件プログ
ラムを複製した上で一部改変を加えたものとも認めることはできない。
前記のとおり，控訴人の指摘する本件プログラムと被控訴人プログラムとの共通
部分において，本件プログラムの表現上の創作性を認めることができない以上，仮
に被控訴人プログラムが本件プログラムに依拠して製作されたものであったとして
も，被控訴人プログラムが本件プログラムを複製又は翻案したものということはで
きない。
したがって，控訴人の上記主張はいずれも採用することができない。
２争点２（被控訴人が被控訴人プログラムを製造，販売する行為についての不
正競争防止法２条１項７号の不正競争行為の成否）について
本件プログラムに関するアイデアについて
ア本件プログラムについて
控訴人は，本件プログラム自体が不正競争防止法２条１項７号により保護される
営業秘密であると主張する。
しかしながら，前記１のとおり，被控訴人プログラムが本件プログラムを複製又
は翻案したものと認めることはできず，被控訴人が本件プログラムの表現上の創作
性を有する部分を使用して被控訴人プログラムを製造，販売したものとはいえない
以上，その余の点について検討するまでもなく，控訴人の上記主張は採用すること
ができない。
イ本件アイデアについて
控訴人は，控訴人の従業員であるＢが本件プログラムの製作を指示する際に開示
した情報（乙３２添付の表に記載された情報）及び本件プログラム製作の前提とな
るアイデアが営業秘密に該当すると主張する。
しかしながら，上記各情報が被控訴人プログラムにおいて使用されていることを
認めるに足りる的確な証拠はない。
したがって，その余の点について検討するまでもなく，控訴人の上記主張は採用
することができない。
本件要望事項について
本件要望事項は，エプソンチャイナ社から控訴人に対して指摘された本件プログ
ラムの改善に関する要望事項であるが，控訴人及びエプソンチャイナ社との間で，
本件要望事項が秘密として管理されていたことを認めるに足りる的確な証拠はない。
また，控訴人の従業員Ｃが，平成２３年１月１７日，エプソンチャイナ社のＤに
対して送信した電子メール（乙２５）には，製品向上のために本件要望事項に取り
組む旨が記載されているが，当該メールは被控訴人に対して送信されたものではな
い。被控訴人の代表者であるＡは，平成２２年１２月６日，エプソンチャイナ社と
控訴人との会議に同席しているようであり（乙２４の２），そのような際に本件要
望事項を知り得た可能性は否定できないが，これを控訴人の営業秘密であるとして，
その保有者である控訴人から開示を受けたことを認めるに足りる的確な証拠もない。
したがって，その余の点について検討するまでもなく，控訴人の上記主張は採用
できない。
小括
以上のとおり，被控訴人が被控訴人プログラムを製作し，販売したことが，控訴
人の営業秘密である本件プログラム，本件アイデア及び本件要望事項に関する不正
競争防止法２条１項７号の不正競争行為に該当するとの控訴人の主張は理由がない
から，控訴人が，被控訴人に対し，同法３条１項に基づいて，被控訴人プログラム
の製造，販売の差止請求権を有するものとは認められない。
３結論
以上の次第であるから，被控訴人の本訴請求はいずれも理由があるから，これを
認容した原判決は相当であって，本件控訴は理由がないから，棄却されるべきもの
である。
なお，控訴人の平成２５年２月１４日付け文書提出命令の申立て（平成２５年
（ウ）第１００１３号）については，本訴における控訴人の主張内容等に鑑みれ
ば，既に書証として提出されている被控訴人プログラムのソースコード（甲７）の
ほかに，上記申立てに係る被控訴人プログラムのソースコードの証拠調べの必要性
はないものと認められるから，上記申立てを却下する。
知的財産高等裁判所第４部
裁判長裁判官富田善範
裁判官田中芳樹
裁判官荒井章光

戻る