平成25(ネ)10008著作権侵害差止請求権不存在確認等請求控訴事件

平成２６年３月１２日判決言渡 同日原本領収 裁判所書記官

平成２５年（ネ）第１０００８号 著作権侵害差止請求権不存在確認等請求控訴事

件（原審・東京地方裁判所平成２４年（ワ）第５７７１号）

口頭弁論終結日 平成２６年１月１５日

判 決

控 訴 人 日本テクノ・ラボ株式会社

訴訟代理人弁護士 栄 枝 明 典

同 石 井 尚 子

同 内 山 浩 人

訴訟復代理人弁護士 三 浦 友 裕

被 控 訴 人 新高和ソフトウェア株式会社

訴訟代理人弁護士 松 島 淳 也

同 木 村 貴 司

補 佐 人 弁 理 士 廣 田 恵 梨 奈

主 文

１ 本件控訴を棄却する。

２ 控訴費用は控訴人の負担とする。

事実及び理由

第１ 控訴の趣旨

１ 原判決を取り消す。２ 被控訴人の請求をいずれも棄却する。

第２ 事案の概要

本判決の略称は，「本件ソフトウェアのプログラム」を「本件プログラム」と，「原告ソフトウェアのプログラム」を「被控訴人プログラム」と各改め，以下に掲記するほかは，原判決に従う。１ 本件は，被控訴人プログラムを製造，販売する被控訴人が，被控訴人プログラムは控訴人の著作物である本件プログラムを複製又は翻案したものであり，被控訴人が被控訴人プログラムを製造，販売する行為は，控訴人が有する本件プログラムの著作権（複製権（著作権法２１条）又は翻案権（同法２７条）及び譲渡権（同法２６条の２第１項））侵害に該当するとともに，控訴人の営業秘密である本件プログラム等の不正使用（不正競争防止法２条１項７号）に該当することを理由に，被控訴人に対し，著作権法１１２条１項及び不正競争防止法３条１項に基づく被控訴人プログラムの製造，販売の差止請求権を有するなどと控訴人が主張しているがそのような請求権は存在しないとして，控訴人の上記各差止請求権の不存在の確認を求めた事案である。原判決は，被控訴人プログラムの具体的記述から本件プログラムの表現上の本質的な特徴を直接感得することができないから，被控訴人プログラムが本件プログラムを複製又は翻案したものと認めることはできない，被控訴人が本件プログラムの表現上の創作性を有する部分を使用して被控訴人プログラムを製造し，販売したものとはいえない以上，被控訴人が控訴人の営業秘密である本件プログラムの表現上の創作性を有する部分を使用して被控訴人プログラムを製造し，販売したものとはいえない，エプソンチャイナ社からの本件要望事項それ自体が控訴人において秘密として管理されていたことを認めるに足りる証拠はなく，被控訴人が本件要望事項を利用し，これを搭載した被控訴人プログラムを製造したことについての具体的な主張立証もないとして，被控訴人の請求をいずれも認容したため，控訴人がこれを不服として本件控訴に及んだ。２ 争いのない事実等及び争点は，「争点１（本件ソフトウェアのプログラムの著作権侵害の成否）」を「争点１（被控訴人が被控訴人プログラムを製造，販売する行為についての本件プログラムの著作権（複製権又は翻案権及び譲渡権）侵害の成否）と改めるほかは，原判決「事実及び理由」の第２の１及び２記載のとおりであるから，これを引用する。

第３ 当事者の主張

当事者双方の主張は，原判決１９頁１３行目の「甲１１」を「甲９」と改め，次のとおり当審における当事者双方の補充主張を付加するほかは，原判決「事実及び理由」の第３記載のとおりであるから，これを引用する。

１ 争点１（被控訴人が被控訴人プログラムを製造，販売する行為についての本

件プログラムの著作権（複製権又は翻案権及び譲渡権）侵害の成否）について〔当審における控訴人の補充主張〕 依拠についてア 本件プログラムは，控訴人が製作した「iDupli version１」（以下「旧バージョンプログラム」という。）をバージョンアップした「iDupli version２」である。控訴人は，被控訴人の代表者であるＡから，プログラム開発の仕事の委託を懇願されたことから，被控訴人に対し，旧バージョンプログラムのバージョンアップ作業を委託することとして，開発内容の指示を行った上で，旧バージョンプログラムのソースコードを貸与した。したがって，旧バージョンプログラム及び本件プログラムの大部分は，控訴人により創作されたものである。イ 被控訴人プログラムは，本件プログラムを作成し，内容を熟知した被控訴人が，本件プログラムを複製（デッドコピー）し，一部改変を加えて作成したものであるから，本件プログラムに依拠して作成された複製物又は翻案物であるというべきである。被控訴人プログラムは，本件プログラムのソースコードをデッドコピーして改変したプログラムであるため，創作性を有するもの及び有しないものも含めた本件プログラムにおける全表現が侵害されている。ウ 被控訴人プログラムが本件プログラムのデッドコピーである根拠は，以下のとおりである。 本件プログラム及び被控訴人プログラムは，画面の構成（表現）が酷似している。だからこそ，被控訴人は，平成２３年９月時点において，本件プログラムの画面（創作性のある表現）と同一であった被控訴人プログラムの画面表示の位置を入れ替えた上で，本件プログラムとは異なる表現であるなどと主張しているのである。 後記において具体的に主張するとおり，被控訴人プログラムのソースコードの一部が本件プログラムと同一である。また，各プログラムのソースコードの構成は酷似している。 被控訴人は，本件プログラムの「CsvIDtask.cpp」クラスの全行を改変し，デッドコピーしたが，プログラム名「CsvIDtask.cpp」については，オリジナルのまま残した。被控訴人は，本件プログラムの受託開発作業のために入手したソースコードから，子クラスの名前，親クラスの名前，ソースコード上の単語などを部分的に置き換えて，あたかも違うソースコードのように見せかけようとする悪質な隠蔽工作を施した。 ソースコードに記述されるイベントの登録順序は，開発者が意図して登録し，記述するものであるところ，本件プログラム及び被控訴人プログラムは，イベントの登録順序が完全に酷似している。 被控訴人プログラムにおいては，「System.xml」という XML フォーマット環境設定ファイルを使用せずに「System.ini」を使用しているが，開示されたソースコードでは，「System.xml」を使用したままとなっている。被控訴人プログラムの「 "CSysOption" 」 ク ラ ス が 必 要 と す る フ ァ イ ル は 「 "System.ini" 」 で あ り ，「"System.xml"」ファイルは参照していないから，被控訴人プログラムが本件プログラムをデッドコピーして製作されたことは明らかである。 本件プログラムの創作性についてア プログラムにおける具体的表現や記述は，コンピュータによって理解され，何らかの機能を実現するものであって，表現と機能とは密接不可分であり，独立したものではないから，プログラムの機能について主張したからといって，直ちに創作性がないということはできない。控訴人は，原審において，本件プログラムの表現上の工夫について，実際の具体的記述に沿って詳細に主張したにもかかわらず，原判決は表現が実現する機能面だけを取り上げ，創作性を否定した。イ 原判決は，被控訴人プロ グラムの 一部のソースコードについて，第 三者（Baidu 社）が提供しているオープンソースソフトウェア（以下「本件オープンソースソフトウェア」という。）であると認定したが，被控訴人プログラムのソースコードの一部（原判決別紙５）がオープンソースソフトウェアであるとする証拠（甲１１）は，本件オープンソースソフトウェアとは無関係のウェブ検索結果にすぎず，原判決は，証拠に基づかない認定をした。ウ 原判決は，本件プログラム及び被控訴人プログラムにおいて，自動生成された部分が存在することを，本件プログラムの創作性を否定する根拠の１つとするが，「Visual Studio」におけるソースコードの自動生成とは，単に，プログラマが画面の設計やクラス，構造の設計等を入力する際，その入力データを基に，一部のソースコードについてキーボードを叩く作業を軽減し，作業効率を上げるための機能にすぎず，コーディング作業を一部簡素化する機能は，どのような開発環境であっても多かれ少なかれ有している機能である。仮に，自動生成された部分があったとしても，手打ち入力されたコードと異ならないのであるから，その具体的記述内容の創作性を検討すべきであり，自動生成であることのみを理由に創作性を否定した原判決は誤りである。エ 原判決は，本件プログラム及び被控訴人プログラムにおいて，マイクロソフト社が公開している関数の名称の記述など，ありふれた表現が用いられていることを，本件プログラムの創作性を否定する根拠の１つとするが，著作権法がプログラムの著作物を保護する以上，命令語，関数名等の予約語がありふれたものであるとしても，直ちに作成者の個性が表れていないと解することはできない。 本件プログラムと被控訴人プログラムとの全体的な類似性についてア クラス構造は，プログラムの構成を表すものであり，文学作品でいえば，文章構成・構造に相当する，いわゆる骨組みといえる部分である。したがって，どのような構造，構成を採用するかは，製作者の独創性，創造性が強く発揮される部分である。イ 本件プログラム及び被控訴人プログラムは，クラス構造がほぼ１体１で対応するほど類似しているのみならず，原判決別紙１ないし１２のとおり，ソースコードの具体的記載においても，キーワード変換をしているものの，その構成，内容，機能の組合せにおいて，ほぼ同一か，かなり類似している。例 え ば ， 本 件 プ ロ グ ラ ム の 「 CSplasnWnd 」 ク ラ ス と 被 控 訴 人 プ ロ グ ラ ム の「CSplasnBox」とを比較すると，「CSplashBox」は「CSplashWnd」のソースコードに対してキーワード置換を行った後，コメント部分（機能しない部分）を２行ほど削除したものであって，両者のソースコードは構造及び表現においてほぼ同じである（原判決別紙５参照）。ま た ， 本 件 プ ロ グ ラ ム の 「 CTaskListPanel 」 ク ラ ス と 被 控 訴 人 プ ロ グ ラ ム の「CTaskListBox」においても，双方に１行ずつの増減があるのみで，キーワード置換を除けば，両者のソースコードは構造及び表現においてほぼ同じである（原判決別紙２参照）。このように，本件プログラムと被控訴人プログラムとを比較すると，ほとんどの部分が同一又は類似した表現となっており，相違が認められる部分は些細なものにすぎないから，両者が同一又は類似していることは明らかである。 各クラスにおける同一性又は類似性についてア 原判決別紙１及び２について 被控訴人は，「IMPLEMENT_DYNAMIC」関数はありふれた関数であるとするが，前記のとおり，命令や関数がありふれていることをもって，直ちに著作権侵害が否定されるものではなく，用いられた命令や関数が具体的にどのような引数や組合せで用いられているかが重要である。被控訴人プログラムの具体的記述は，本件プログラムとは一見異なってみえるものの，それは，被控訴人が本件プログラムのソースコードを流用する際，流用の事実を隠匿するために，任意に指定できる関数名を近い意味の英単語に一括変換しているだけで，新たな創作性が発揮されているわけではない。「IMPLEMENT_DYNAMIC」は，いわゆるオブジェクトクラスの承継命令であり，クラス毎にコーディングしていくＣ＋＋言語における構造部分にも当たる重要な箇所であるところ，被控訴人プログラムと本件プログラムのソースコードが，同じ場所で同じように承継命令を記載しているのは，クラス分け（分類と整理）の仕方がほぼ同じであるからにほかならない。 被控訴人は，３か国言語に対応している部分及び次回の起動時に前回の終了時の状態から再開できるようにしている部分についても，具体的記述が異なると主張するが，具体的関数名が一見異なっていても，実質的に見て同じ関数の表記であるということができるし，前記 と同様に，流用の事実を隠匿するために，任意に指定できる関数名を近い意味の英単語に一括変換したにすぎない。イ 原判決別紙３について被控訴人は，「OnSize」メソッドは「Visual Studio」を使って自動生成されるものであり，ありふれた表現であると主張する。しかし，当該記述は１６行に及ぶところ，このうち，「Visual Studio」を使って自動生成されるのは４行にすぎず，残りの１２行についても，本件プログラムと被控訴人プログラムの具体的記述はほとんど同じである。前記のとおり，純粋な自動生成なる機能は存在せず，単にコーディングの手間を省くために，コーディング以外の操作をしているにすぎないから，結果として自動生成されているように見えるコードであっても，単に手入力の手間やミスを省いたにすぎず，プログラマの意思が反映されたソースコードそのものである。実際，「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」の両方が必要となる。 被控訴人は，被控訴人プログラムにふさわしいと考えられる名称をクラス名や変数名にて使用しているにすぎない。控訴人が主張する置換をしただけでは，本件プログラムのクラスが被控訴人プログラムのクラスの名称に置換されるものではない。 本件プログラムの創作性についてア 原判決は，本件プログラムの具体的記述における表現上の創作性を有する部分と被控訴人プログラムの表現上の具体的記述とを対比し，被控訴人プログラムの具体的記述から本件プログラムの表現上の本質的な特徴を直接感得することができるか否かについて検討したものであって，原判決の判断手法及びその結論に誤りはない。イ 控訴人は，原判決は本件オープンソースソフトウェアについて証拠に基づかない認定をしたと主張するが，同ソフトウェアは本件プログラムの納品日前には既に公開されていたものである。ウ 「Visual Studio」におけるソースコードの自動生成を用いた場合，例えば，「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 文／else if 文」の一般的な使用方法について説明しているにすぎない。しかも，本件プログラムは，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」メソッドが生成され，原判決別紙３の「void CChildView::OnSize(UINT

n Type, int cx, int cy)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」は，コンボボックス（combo box）の頭文字からなる文字列であり，

コンボボックスを意味する表現として慣用されるものと認められるところ（甲１

），本件プログラムと被控訴人プログラムとの共通部分である

「m_cbLanguage.AddString」のうち，「m_cbLanguage」は，コンボボックス（combo

box）で「言語」（Language）を選択するための関数であるため，combo box の頭文

字と Language とを結合した表現であることは明らかである。また，証拠（甲１

）によれば，AddString は，マイクロソフトがあらかじめ用意していた関数名で

あると認められるから，「m_cbLanguage.AddString」は，「m_cbLanguage」という

文字列と AddString とを文法に従って結合させたものにすぎず，創作性を認めるこ

とはできない。

控訴人は，「m_cbLanguage」をインターネット検索しても，３件又は２件しか検

索結果として表示されないから，ありふれた関数であるということはできない，被

控訴人プログラムは，①「AddString」命令で文字列を追加している対象がコンボボ

ックスである点，②コンボボックスに付けられた任意の名称が，同じ

「m_cbLanguage」である点，③加えられる文字列が，プログラム実行時に選択でき

る３か国言語である点等において，「AddString」関数の利用表現方法が本件プログ

ラムと酷似していると主張する。

し か し な が ら ， 上 記 の と お り ， 「 m_cbLanguage 」 は ， combo box の 頭 文 字 と

Language とを結合した表現にすぎず，インターネット検索において数件しか検索結

果として表示されないことをもって，創作性を認めることはできない。また，①及

び②の事項は，上記のとおり，使用言語を選択可能とする機能を実現するために採

用されたありふれた記述にすぎず，③の事情は，３か国言語に対応するという機能

を意味するにすぎない。

また，控訴人は，画面上のコンボボックスから３つの利用言語を即時に変更可能

とすることにより，ユーザビリティの向上を図っているとも主張するが，これはプ

ログラムの機能（アイデア）に当たるものであって，プログラムの表現の創作性を

認める根拠となるものではない。

したがって，控訴人の上記主張はいずれも採用することができない。

エ 原判決別紙５について

 証拠（甲９，２３）によれば，原判決別紙５に係る本件プログラムの記述は，

遅くとも平成２２年８月１４日には Baidu 社から公開され，同年１２月２５日の時

点では公知となっていた本件オープンソースソフトウェアを用いたものであると認

められる。

したがって，本件プログラムと被控訴人プログラムとの間において，本件オープ

ンソースソフトウェアを用いた部分が共通するとしても，本件プログラムの著作権

を侵害するものということはできない。

控訴人は，原判決が，同判決第３の１ア ｄの被控訴人の主張を援用して，本

件オープンソースソフトウェアに係る書証として摘示した甲１１が本件オープンソ

ースソフトウェアとは無関係であることを前提に，被控訴人プログラムが本件オー

プンソースソフトウェアにより作成されていることに関する証拠はないと主張する

が，甲１１は甲９の誤記と認められるから，控訴人の上記主張はその前提自体を欠

き理由がない。

 「SetTimer」関数は，指定されたタイムアウト値を持つ１個のタイマを作成

する機能に関し，マイクロソフト社があらかじめ用意している関数であり（甲１

），任意に設定可能であるタイムアウト値として２０００ミリ秒（２秒）を選択

したことをもって，プログラムの表現上の創作性を認めることはできない。

控訴人は，スプラッシュウィンドウをどの程度の時間表示させるかは，本件プロ

グラムの特性や利便性を考えてチューニングした固有の数値であり，仮に，

「SetTimer」関数がありふれた表現であったとしても，「SetTimer(1,2000,NULL)」

という表現全体の創作性を否定することはできないなどと主張するが，これはプロ

グラムの機能（アイデア）に当たるものであって，プログラムの表現の創作性を認

める根拠となるものではない。

したがって，控訴人の上記主張は採用することができない。

オ 原判決別紙６について

本件プログラムの記述は，「CString LoadResString（UINT nID）；」であり，被

控訴人プログラムの記述は，「CString GetString（UINT nID）；」である。

本件プログラムと被控訴人プログラムとの共通部分のうち，「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 文を３回使

用している。）

else if(FOLDER_JOB==m_nJobType)

また，被控訴人プログラムの記述は，以下のとおりである。

if（NORMAL_PROJECT=m_nProjectType）

（被控訴人プログラムは，これに続いて，「GetDlgItem」命令を４７回使用して

いるが，if 文は使用していない。）

else if(FOLDER_PROJECT==m_nProjectType)

 本件プログラムと被控訴人プログラムとの共通部分のうち，if 文/else if 文

は，条件に応じた処理において一般的に用いられるところ，本件プログラムと被控

訴人プログラムとは，具体的な判断条件の表現が異なっている。

また，if 文に続く部分は，「GetDlgItem」命令が記述されていることは共通して

いるものの，if 文の利用の有無が異なっているのみならず，「GetDlgItem」命令の

使用回数が大きく異なっている以上，各命令文の表現が一致しているとはいえない。

そして，「 GetDlgItem」命令は，マイクロソフト社があらかじめ用意している関

数（甲１５）であるから，本件プログラムの上記記述に創作性を認めることはでき

ない。

控訴人は，本件プログラムは，利用者がいちいち本件プログラムを操作しなくて

も書き込みが開始できる仕組みとして，①外部のコンピュータで CSV ファイルを用

意して，そのファイルを特定のフォルダに保存した時点で，CSV ファイルの内容に

従って書き込みを開始する方法（CSV ジョブ）と，②フォルダの容量を監視して一

定容量を超えた際に書き込みを開始する方法（フォルダジョブ）を用意し，遠隔地

からの処理や自動処理に対応する機能を備えているなどと主張するが，これはプロ

グラムの機能（アイデア）に当たるものであって，プログラムの表現の創作性を認

める根拠となるものではない。

控訴人は，被控訴人プログラムと本件プログラムとは，処理を３つの処理ブロッ

クに分け，最初の条件に合うものを処理１で，２つめの条件に合うものを処理２で，

いずれの条件にも合わないものを処理３でそれぞれ処理するという大きな分岐処理

構造をほぼ同じ表現によって実現するものであると主張する。

しかしながら，分岐構造は，アルゴリズム（解法）に属するものであるのみなら

ず，控訴人の主張する上記分岐構造は，プログラムの処理上，一般的に行われてい

るものである（甲２８）。このような分岐構造を if 文/else if 文を用いて実現す

ることは，if 文/else if 文の一般的な使用方法というべきであって，分岐構造が共

通することをもって，著作権侵害を認めることはできない。

したがって，控訴人の上記主張はいずれも採用することができない。

ケ 原判決別紙１１について

「IMPLEMENT_DYNCREATE」関数については，前記アと同様に，当該表現に創作性

を認めることはできない。

コ 原判決別紙１２について

 AddNotifyIcon 等について

本件プログラムの記述は，以下のとおりである。

AddNotifyIcon();

OnSysHFMStart();

OnSysJMStart();

OnSysTMStart();

また，被控訴人プログラムの記述は，以下のとおりである。

AddNotifyIcon();

OnHFLStart();

OnPLStart();

OnTLStart();

本件プログラムと被控訴人プログラムとの共通部分は，関数名として

「AddNotifyIcon()」を使用している部分 であるが，証拠（甲１７）によれば ，

「AddNotifyIcon()」は，関数名として一般的に多数使用されているものと認められ

るから，当該記述に創作性を認めることはできない。

控訴人は，ユーザのメニューアクセス性を向上させるため，Windows のタスクト

レイにアイコンを表示し，それを右クリックするとメニューが選択できるように工

夫しているなどと主張するが，これはプログラムの機能（アイデア）に当たるもの

であって，プログラムの表現の創作性を認める根拠となるものではない。

 アプリケーションの終了処理について

本件プログラムの記述は，以下のとおりである。

if (theApp.m_taskMonitor.IsExistUnFinishedTasks()

&& AfxMessageBox(_T("There are some unfinished task(s).")

_T(" ￥ nThe exact status will lose if you close the application.

￥nAre you sure to close it?"), 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」関数において，遅延させる数値を０．５秒（５００）に設定したことをも

って，プログラムの表現上の創作性を認めることはできない。

したがって，控訴人の上記主張は採用することができない。

サ 小括

以上のとおり，控訴人の指摘する本件プログラムと被控訴人プログラムとの共通

部分において，本件プログラムの表現上の創作性を認めることができない以上，被

控訴人プログラムが本件プログラムを複製又は翻案したものということはできない。

控訴人は，そのほか，被控訴人プログラムは，本件プログラムを複製（デッドコ

ピー）し，一部改変を加えて作成したものであるから，本件プログラムに依拠して

作成された複製物又は翻案物であると主張し，その根拠として，本件プログラム及

び被控訴人プログラムの画面の構成（表現）は酷似していること，クラス構造が類

似していることなどを指摘する。

しかしながら，同一の機能を有するプログラムが複数存在し得る以上，プログラ

ムを実行した際の画面が類似するからといって，直ちにプログラムの著作権の侵害

を根拠付けるものではないことは明らかである。クラス構造も，プログラムに係る

具体的な記述ということはできない。原判決別紙１ないし１２における本件プログ

ラムと被控訴人プログラムとの具体的対比によれば，被控訴人プログラムの記述は，

本件プログラムの記述と相当程度異なっており，被控訴人プログラムが本件プログ

ラムを複製した上で一部改変を加えたものとも認めることはできない。

前記のとおり，控訴人の指摘する本件プログラムと被控訴人プログラムとの共通

部分において，本件プログラムの表現上の創作性を認めることができない以上，仮

に被控訴人プログラムが本件プログラムに依拠して製作されたものであったとして

も，被控訴人プログラムが本件プログラムを複製又は翻案したものということはで

きない。

したがって，控訴人の上記主張はいずれも採用することができない。

争点２（被控訴人が被控訴人プログラムを製造，販売する行為についての不

正競争防止法２条１項７号の不正競争行為の成否）について

 本件プログラムに関するアイデアについて

ア 本件プログラムについて

控訴人は，本件プログラム自体が不正競争防止法２条１項７号により保護される

営業秘密であると主張する。

しかしながら，前記１のとおり，被控訴人プログラムが本件プログラムを複製又

は翻案したものと認めることはできず，被控訴人が本件プログラムの表現上の創作

性を有する部分を使用して被控訴人プログラムを製造，販売したものとはいえない

以上，その余の点について検討するまでもなく，控訴人の上記主張は採用すること

ができない。

イ 本件アイデアについて

控訴人は，控訴人の従業員であるＢが本件プログラムの製作を指示する際に開示

した情報（乙３２添付の表に記載された情報）及び本件プログラム製作の前提とな

るアイデアが営業秘密に該当すると主張する。

しかしながら，上記各情報が被控訴人プログラムにおいて使用されていることを

認めるに足りる的確な証拠はない。

したがって，その余の点について検討するまでもなく，控訴人の上記主張は採用

することができない。

 本件要望事項について

本件要望事項は，エプソンチャイナ社から控訴人に対して指摘された本件プログ

ラムの改善に関する要望事項であるが，控訴人及びエプソンチャイナ社との間で，

本件要望事項が秘密として管理されていたことを認めるに足りる的確な証拠はない。

また，控訴人の従業員Ｃが，平成２３年１月１７日，エプソンチャイナ社のＤに

対して送信した電子メール（乙２５）には，製品向上のために本件要望事項に取り

組む旨が記載されているが，当該メールは被控訴人に対して送信されたものではな

い。被控訴人の代表者であるＡは，平成２２年１２月６日，エプソンチャイナ社と

控訴人との会議に同席しているようであり（乙２４の２），そのような際に本件要

望事項を知り得た可能性は否定できないが，これを控訴人の営業秘密であるとして，

その保有者である控訴人から開示を受けたことを認めるに足りる的確な証拠もない。

したがって，その余の点について検討するまでもなく，控訴人の上記主張は採用

できない。

 小括

以上のとおり，被控訴人が被控訴人プログラムを製作し，販売したことが，控訴

人の営業秘密である本件プログラム，本件アイデア及び本件要望事項に関する不正

競争防止法２条１項７号の不正競争行為に該当するとの控訴人の主張は理由がない

から，控訴人が，被控訴人に対し，同法３条１項に基づいて，被控訴人プログラム

の製造，販売の差止請求権を有するものとは認められない。

結論

以上の次第であるから，被控訴人の本訴請求はいずれも理由があるから，これを

認容した原判決は相当であって，本件控訴は理由がないから，棄却されるべきもの

である。

なお，控訴人の平成２５年２月１４日付け文書提出命令の申立て（平成２５年

（ウ）第１００１３号）については，本訴における控訴人の主張内容等に鑑みれ

ば，既に書証として提出されている被控訴人プログラムのソースコード（甲７）の

ほかに，上記申立てに係る被控訴人プログラムのソースコードの証拠調べの必要性

はないものと認められるから，上記申立てを却下する。

知的財産高等裁判所第４部

裁判長裁判官 富 田 善 範

裁判官 田 中 芳 樹

裁判官 荒 井 章 光