2016年2月5日金曜日

侵害訴訟 著作権 平成26(ネ)10038 知財高裁 変更(請求一部認容)

事件番号
事件名
 著作権侵害差止請求控訴事件
裁判年月日
 平成28年1月19日
裁判所名
 知的財産高等裁判所第3部 
裁判長裁判官          大      鷹      一      郎 
裁判官          田      中      正      哉 
裁判官          神      谷      厚      毅

「(1)  データベースの複製ないし翻案について
ア  前記第2の2の前提事実及び前記1の認定事実によれば,原告CDDBは,入力される個々の情報(データ)の集合体が,縦の列と横の行から構成される表であるテーブルに格納され,テーブルの縦の列は個々のデータの属性を表す「フィールド」に細分され,テーブルの横の行は,ユーザーが,最小単位の格納データとして検索等の操作をすることができる1件分のデータである「レコード」を構成し,複数のテーブル間に共通のフィールド(プライマリー・キー(主キー)等)を設定し,テーブル間を関連付けることにより,相互のテーブル内の他のフィールドに格納されている属性の異なるデータを抽出し,抽出したデータを統合・集計して検索することができる機能を有するいわゆるリレーショナルデータベースである。
  著作権法12条の2第1項は,データベースで,その情報の選択又は体系的な構成によって創作性を有するものは,著作物として保護する旨規定しているところ,情報の選択又は体系的構成について選択の幅が存在し,特定のデータベースにおける情報の選択又は体系的構成に制作者の何らかの個性が表れていれば,その制作過程において制作者の思想又は感情が移入され,その思想又は感情を創作的に表現したものとして,当該データベースは情報の選択又は体系的構成によって創作性を有するものと認めてよいものと解される。
  そして,リレーショナルデータベースにおける体系的構成の創作性を判断するに当たっては,データベースの体系的構成は,情報の集合物から特定の情報を効率的に検索することができるようにした論理構造であって,リレーショナルデータベースにおいては,テーブルの内容(種類及び数),各テーブルに存在するフィールド項目の内容(種類及び数),どのテーブルとどのテーブルをどのようなフィールド項目を用いてリレーション関係を持たせるかなどの複数のテーブル間の関連付け(リレーション)の態様等によって体系的構成が構築されていることを考慮する必要があるものと解される。また,リレーショナルデータベースにおいては,一般に,各テーブル内に格納されるデータの無駄な重複を減らし,検索効率を高めるために,フィールド項目に従属関係を設定して,新たなテーブルを設けたり,テーブル内に格納されているデータの更新を行う際にデータ間に不整合が起こらないようにするために,関連性の高いデータ群だけを別のテーブルに分離させるなどの正規化が行われており,その正規化の程度にも段階があることから,正規化がもたらす意義や正規化の程度についても考慮する必要があるものと解される。
イ  複製とは,印刷,写真,複写,録音,録画その他の方法により有形的に再製することをいい(著作権法2条1項15号),著作物の複製(同法21条)とは,当該著作物に依拠して,その表現上の本質的な特徴を直接感得することのできるものを有形的に再製する行為をいうものと解される。また,著作物の翻案(著作権法27条)とは,既存の著作物に依拠し,かつ,その表現上の本質的な特徴の同一性を維持しつつ,具体的表現に修正,増減,変更等を加えて,新たに思想又は感情を創作的に表現することにより,これに接する者が既存の著作物の表現上の本質的な特徴を直接感得することのできる別の著作物を創作する行為をいうものと解される(最高裁平成13年6月28日第一小法廷判決・民集55巻4号837頁参照)。
  そして,リレーショナルデータベースにおいては,データベースの一部分を分割して利用することが可能であり,また,テーブル又は各テーブル内のフィールドを追加したり,テーブル又はフィールドを削除した場合で あっても,既存のデータベースの検索機能は当然に失われるものではなく,その検索のための体系的構成の全部又は一部が維持されていると評価できる場合があり得るものと解される。
  以上を前提とすると,被告CDDBが原告CDDBを複製ないし翻案したものといえるかどうかについては,まず,被告CDDBにおいて,原告CDDBのテーブル,各テーブル内のフィールド及び格納されている具体的な情報(データ)と共通する部分があるかどうかを認定し,次に,その共通部分について原告CDDBは情報の選択又は体系的構成によって創作性を有するかどうかを判断し,さらに,創作性を有すると認められる場合には,被告CDDBにおいて原告CDDBの共通部分の情報の選択又は体系的構成の本質的な特徴を認識可能であるかどうかを判断し,認識可能な場合には,その本質的な特徴を直接感得することができるものといえるから,被告CDDBは,原告CDDBの共通部分を複製ないし翻案したものと認めることができるというべきである。」
「ノ  原判決180頁25行目冒頭から26行目末尾までを次のとおり改める。
  「以上の検討によれば,被告CDDB(当初版・2006年版)は,原告CDDBに依拠して制作されたものであって,被告CDDB(当初版・2006年版)において原告CDDBの共通部分の体系的構成及び情報の選択の本質的な特徴を直接感得することができるものといえるから,原告CDDBの共通部分の複製物であると認めるのが相当である。」  」
「 したがって,被告CDDB(新版)に新たに付け加えられたテーブル,フィールド及びリレーションの存在によって生じた体系的構成の部分が創作性を有するとしても,被告CDDB(新版)においては,原告CDDBの体系的構成①ないし③及び⑤の本質的な特徴が認識可能であり,その本質的な特徴を直接感得することができるものというべきである。 」

【コメント】
 報道で少し話題にもなりました,旅行業者向けのソフトの,データベースの著作権侵害訴訟の事件です。
 一審の東京地裁平成21(ワ)16019(平成26年3月14日判決)は,データベースの差止と1億円強の損害賠償を認めました。

 そして,この控訴審では,差止(差止の対象のデータベースが一つ増えております。)に加えて,2億円強の損害賠償まで認めました。ですので,かなりインパクトのある判決ではないでしょうか。

 データベースの著作物性については,著作権法に,
(データベースの著作物)
第十二条の二  データベースでその情報の選択又は体系的な構成によつて創作性を有するものは、著作物として保護する。
とありますので, 一般的には著作物として認められているわけです。

 とは言え,こういう機能的な成果物(プログラムもそう。)は,個別具体的な事例で,著作物性が認められた場合というのは結局少なかったりします。
 さて,本件の事例で,データベースの著作権侵害について,知財高裁は,一定の規範を示しました。
 従前, 著作権侵害の判断については,二段階テストとろ過テストというものが知られておりました。
「①原告作品の著作物性を認定してから,被告作品に原告作品の創作的表現が複製又は本案されているかを順次判断する手法(2段階テスト)と,②原告作品と 被告作品の同一性を有する部分を抽出し,それが思想又は感情の創作的な表現に当たるか否かという判断をする手法(濾過テスト)があった」こういうものです。これは知財高裁4部の高部部長の著作(「実務詳説 著作権訴訟」(きんざい))からの引用です。 

 今回はデータベースという機能的な成果物の話ですが,どうやら②のろ過テストの方を採用したようです。
 判旨によると,
1被告CDDB(新版)と原告CDDBとの体系的構成の共通性があるか?→2共通性があるなら,体系的構成の共通部分についての原告CDDBの創作性があるか?→3創作性があるなら,被告CDDB(新版)において,原告CDDBの体系的構成の本質的な特徴が認識可能か? 
という手順で判断したようです。
 最近は,二段階テストよりも,このろ過テストの方が裁判所には人気のあるようです。共通性のある所の創作性を検討すればよいので,多少手間が省けるからなのでしょう。

 あと,本件では,データベースということで,体系的構成だけでなく,正規化についても創作性判断の一要素と判示されております。
 ですので,本件の判示はなかなか奥深いものがあるなあと言った感じがします。

 ところで,個人的には,上記の法的な話よりも,事実的な話の方に興味があります。つまり,被告のパッケージソフトについて,よく解析ができたなあということです(そうじゃないとテーブルの構成の共通性などわかりませんから。)。

 どういうことかと言いますと,近時のソフトウェアは,リバースエンジニアリングが非常にしにくくなっています。中間言語の難読化等や暗号化を行っていることが多いと思います。ですので,類似品の現物が手に入ったところで,中身のソースコード等が本当に類似しているかどうかがわからないこともあるのです。

 そういう意味では,原告に勤めていた従業員等が原告を退職して作った会社が被告等だとは言え,被告ももう少しリバースエンジニアリング対策をしていれば原告に証拠をとられることは無かったかもしれません。

 ただ,そんなことを言えば,恐らく原告のソフトをリバースエンジニアリングして,テーブル等を抜き取ったのが事の発端だと思いますので,原告がはじめにきちんとリバースエンジニアリング対策をしていれば良かったのかもしれません。