運営：アスタミューゼ株式会社
パナソニックで一緒に知財の仕事しませんか？
  • ポートフォリオ機能


追加

関連ワード 著作物性 /  創作性 /  独自性 /  著作者 /  翻案 /  同一性 /  データベース /  レコード /  公衆送信 /  複製権 /  登録 /  著作権侵害 /  差止 /  損害賠償 / 
元本PDF 裁判所収録の全文PDFを見る pdf
元本PDF 裁判所収録の別紙1PDFを見る pdf
事件 平成 12年 (ワ) 9426号 データベース使用差止等請求事件
原告 株式会社オフィス・キャスター
訴訟代理人弁護士 中島敬行
同 椙山敬士
同 堀井敬一
同 石新智規
被告 株式会社デジタル・ピクチャーズ・エンターテイメント
被告Ａ
被告Ｂ
被告 株式会社エクス
被告ら訴訟代理人弁護士 吉増泰實
同 山口暁
裁判所 東京地方裁判所
判決言渡日 2002/02/21
権利種別 著作権
訴訟類型 民事訴訟
主文 別紙被告物件目録記載のデータベースは，別紙原告物件目録記載のデータベースを複製したものであり，原告の有する同データベースの著作権を侵害する。
事実及び理由
原告の請求
1 被告らは,別紙被告物件目録記載のデータベース(以下「被告データベース」という。)を複製,翻案,頒布及び公衆送信してはならない。
2 被告らは,被告データベースを記録した磁気媒体を廃棄せよ。
3 被告株式会社デジタル・ピクチャーズ・エンターテイメント(以下「被告デジタル・ピクチャーズ」という。),同A及び同Bは,各自原告に対し,3000万円及びこれに対する被告デジタル・ピクチャーズに対しては平成12年5月19日から,被告A及び同Bに対しては平成12年5月24日から各支払済みまで年5分の割合による金員を支払え。
4 被告株式会社エクス(以下「被告エクス」という。)は,原告に対し,2700万円及びこれに対する平成13年1月20日から支払済みまで年5分の割合による金員を支払え。
事案の概要
本件は,原告が,被告デジタル・ピクチャーズ,同エクスが被告データベースを使用,頒布した行為が,原告の有する別紙原告物件目録記載のデータベース(以下「原告データベース」という。)について原告の有する著作権(データベースの著作権)を侵害すると主張して,被告らに対し,被告データベースの複製,翻案,頒布及び公衆送信の差止め及びこれを記録した磁気媒体の廃棄並びに損害賠償を求めている事案である。
1 前提となる事実(証拠により認定した事実については,末尾に証拠を掲げた。)(1)当事者 ア 原告は,情報処理サービス業及び情報提供サービス,コンピュータソフトウェアの企画,開発,販売業務並びに受託開発業務等を営む会社である。
イ 被告デジタル・ピクチャーズは,コンピュータシステムの開発,販売,運営及び保守並びにニューメディアに関するシステム開発及び販売等を目的とする会社である。
ウ 被告Aは,被告デジタル・ピクチャーズの代表取締役であり,被告Bは,被告デジタル・ピクチャーズの取締役である。
エ 被告エクスは,インターネット及びその他の通信システムを利用した情報通信サービス等を目的とする会社である。
(2)原告への権利の帰属 ア 原告データベースを含むコアネットは,新築分譲マンション開発業者等に対する販売を目的とするものである。
新築分譲マンション開発業者は,土地を仕入れ,建築企画を行い,建築販売するまでに,過去の建築販売事例,類似の建築販売事例を参考に建築販売計画を立案する。その際に,業者は,様々な視点からの分析を行う必要があり,各種情報を分析する必要がある。原告データベースは,これらの業者の必要に対して,日々各種の情報を提供するデータベースサービス事業に資するものである。
原告データベースによって,新築分譲マンションの平均坪単価,平均専有面積,価格別販売状況等を集計することができる。そして,原告データベースの検索画面(甲7の1〜3)に一定の検索条件を入力すると,価格帯別需給情報等の情報が,表やグラフのような帳票形式(甲8)で出力される。
イ 原告データベースを含むシステムは,株式会社デジタルウェアが昭和62年に開発したコアネットシステム「調査マン」が起源となっている。その後,分譲マンションの開発着手から販売終了までを時系列的に追った情報を集積した「広告マン」「企画マン」「DIGI-PACK」という名称のデータベースが,同会社により次々と制作,販売され,平成9年に,ウィンドウズとインターネットの普及を背景に,同データベースの統合版である「コアネットforWindows」が,同会社により制作,販売された。原告データベースは,同統合版の中に含まれている。
ウ 株式会社デジタルウェアは,平成10年12月16日,破産宣告を受けた。
原告は,平成11年5月21日,同破産会社破産管財人Cから原告データベースに関する一切の権利を譲り受けた。
(3)被告らの行為 被告デジタル・ピクチャーズは,平成11年6月ころから,新築分譲マンション開発業者に対し,被告データベースを使用して不動産の情報を提供していた。
被告エクスは,平成12年4月,被告デジタル・ピクチャーズから同データベースに関する一切の権利を譲り受け,以後,新築分譲マンション開発業者に対し,同データベースを使用して,同様に,不動産の情報を提供している。
(4)データベースについて ア 原告データベースは,マイクロソフト社制作に係る「アクセス(Access)」を用いて作成されている。「アクセス」は,いわゆるリレーショナル・データベースを開発,維持するために用いられるデータベースソフトである。リレーショナル・データベースは,データベースの情報の単位であるレコードを別のレコードと関連付ける処理機能を持つデータベースである。
イ アクセスで作成されるデータベースにおいて,入力される情報はテーブルと呼ばれる表に格納されていく。テーブルのうち,入力された情報が格納されるテーブルをエントリーテーブルといい,頻繁に使用される情報(例えば地名や駅名等)や検索に用いられる情報が格納されるテーブルをマスターテーブルという。テーブルは,さらに各フィールド項目に細分される。各フィールド項目においては,格納されるデータの種類及び型(テキスト,数値,通貨,Yes/Noなど)が決められている(甲5)。
ウ テーブルの各フィールド項目に入れられるデータをレコードという。各テーブルはフィールド項目が決定された後,具体的なレコードが入力されていく。
エ リレーショナル・データベースでは,テーブルを多数作成するが,テーブル間の関連付けのためには,あるテーブルのあるフィールド項目を他のテーブルのあるフィールド項目と一致させる必要がある。これにより,新たなテーブルを作らないで,既存の複数のテーブルから抽出したいフィールド項目だけを効率的に選択することができる(弁論の全趣旨)。
オ データベースでは,テーブルに格納されているデータをより速く検索,抽出することが重要であり,そのため,フィールド項目の中から,テーブルに格納されている各情報を識別できるようにするためのフィールド項目を選択することが必要になる。この選択されたフィールド項目のことを主キーという。主キーを設定したフィールド項目には,重複するデータを入力することはできない。しかし,1つのフィールド項目だけでは情報を特定できない場合,複数のフィールド項目を組み合わせて主キーにすることができる(甲22)。
(5)原告・被告各データベースについて(検甲1,甲5,6,16,22,乙4,5,35及び弁論の全趣旨) ア(ア) 原告データベースにおいては,別紙図1の構造が含まれていることが認められ,被告データベースにおいては,別紙図2の構造が含まれていることが認められる。また,同業他社(MRC社)のデータベースでは,別紙図3の構造が含まれていることが認められる(図1〜3においては,エントリーテーブルが直方体で,マスターテーブルが円柱で示され,テーブルを示す直方体,円柱の上面に,テーブルの名称が記され,また,フィールド項目がそれぞれ存在するテーブルの手前側側面に黒文字で記入され,さらに,テーブル間の関連付けが,テーブルとテーブルとの間をつなぐ渡り廊下のようなもの(横長の棒状の直方体)で示されている。なお,図2においては,フィールド項目は黒文字及び白文字で記入されているが,黒文字で記入されている項目が存在するフィールド項目であり,また,関連付けは実線及び点線で記入されているが,実線で記入されている項目が存在する関連付けである。)。
(イ) 原告・被告各データベースには,エントリーテーブルとして,PROJECTテーブル,詳細テーブル,住戸一般テーブル,広告テーブル,申込テーブル,月報タイプテーブル,月報価格テーブルが共通して存在するところ,同各テーブルに格納される情報内容は,以下のとおりである。
@ PROJECTテーブルには,マンションの建物・敷地・地域の属性等が格納される。
A 詳細テーブルには,マンションの販売の期分けごとの概略等が格納される。
B 住戸一般テーブルには,各部屋ごとの詳細が格納される。
C 広告テーブルには,各マンション販売の広告出稿の内容が格納される。
D 申込テーブルには,初月の販売から各月の売れ行きが,百分率表示の推移等の形で格納される。
E 月報タイプテーブルには,各マンションの販売結果が,間取りタイプ別に集計されて格納される。
F 月報価格テーブルには,各マンションの販売結果が,価格帯別に集計されて格納される。
(ウ) 原告・被告各データベースには,マスターテーブルとして,all LINEテーブル,all TRAFテーブル,PREFテーブル,TOWNテーブル,ANMテーブル,PAPERテーブル,TYPEテーブル,KAKAKUテーブル,構造reportテーブル,法規制コード1テーブル,法規制コード2テーブル,LAW3テーブルが共通して存在するところ,同各テーブルに格納される情報内容は以下のとおりである。
@ all LINEテーブルには,首都圏の鉄道各社の各路線がコード付けられて格納される。
A all TRAFテーブルには,首都圏鉄道の各駅名がコード付けられて格納される。
B PREFテーブルには,全国の都道府県の名称がコード付けられて格納される。
C TOWNテーブルには,全国の市町村の名称がコード付けられて格納される。
D ANMテーブルには,首都圏及び札幌の一部の町丁名がコード付けられて格納される。
E PAPERテーブルには,広告媒体の名称がコード付けられて格納される。
F TYPEテーブルには,間取り区分がコード付けられて格納される。
G KAKAKUテーブルには,価格帯区分がコード付けられて格納される。
H 構造reportテーブルには,建築構造部分がコード付けられて格納される。
I 法規制コード1テーブル,法規制コード2テーブルには,法規制区分がコード付けられて格納される。また,LAW3テーブルは,法規制コード1テーブルと法規制コード2テーブルを合体させたものである。
イ なお,上記のとおり原告・被告各データベースの構造を認定した理由は,次のとおりである。
(ア)被告らは,検甲1のCD-ROM中「原告側DB」フォルダー「YUKIKO.mdb」ファイル中には,この他28以上のテーブルが存在し,PROJECTテーブルのPROJECT IDフィールドは,少なくとも他に21以上のテーブルとも関連付けられていると主張するが,同主張も,原告データベースにおいて,図1の構造が含まれていることを否定するものではない。
(イ)被告らは,原告・被告データベースとも,PROJECTテーブル「法規制1-1」「法規制1-2」「法規制1-3」各フィールドと,LAW3テーブルのLAW1フィールドとが関連付けられていることを否定し,n:nの関係にあるものは関連付けられているとはいえないと主張し,乙29の1,2を提出する。しかし,甲22によれば,1つのフィールド項目だけではレコードを特定できない場合,複数のフィールド項目を組み合わせて主キーにすることができると認められるところ,甲23によれば,LAW3テーブルにおいては,LAW1フィールドとCHKフィールドの双方に主キーが付されていることが認められ,この双方を組み合わせれば,LAW1フィールドのレコードと,LAW2フィールドのレコードが区別されることになるから,LAW3テーブルの中にあるレコードを一意に特定することができるといえる。したがって,n:nの関係ではなく,n:1の関係になるから,被告らの論理によっても,被告らの同主張は採用できない。また,被告らは,PROJECTテーブル「法規制2-1」「法規制2-2」「法規制2-3」各フィールドと,LAW3テーブルのLAW1フィールドとが関連付けられているといえないと主張するが,同様の理由により採用できない。
(ウ)被告らは,原告・被告各データベースのPROJECTテーブル「路線1」「路線2」「路線3」各フィールドとall LINEテーブルのLINE1フィールドとの関連付けを否定し,n:nの関係にあるものは関連付けられているとはいえないと主張し,乙29の4を提出する。また,同様にall TRAFテーブルのTRAF1フィールドとall LINEテーブルのLINE1フィールドとの関連付けを否定し,n:nの関係にあるものは関連付けられているとはいえないと主張して,乙29の5及び6を提出する。しかしながら,PROJECTテーブルの「路線1」「路線2」「路線3」各フィールドとall TRAFテーブルのTRAF1フィールドとは,主キーと外部キーの関係で関連付けられている。さらに,all LINEテーブルのLINE1フィールドについては,乙29の5によれば3桁の数字が格納されているから,7桁の数字が格納されているall TRAFテーブルのTRAF1フィールドと1:1の対応関係にないようにみえる。しかし,all LINEテーブルのLINE1フィールドに格納されている数字は,all TRAFテーブルのTRAF1フィールドの上3桁と一致するように構成されていることが認められ(例えば,LINE1フィールドの001はいずみ鉄道を意味し,all TRAFフィールド0010010は,いずみ鉄道の大原駅を意味する),LINE1フィールドの3桁の数字によって路線名称をコード化し,TRAF1フィールドの下4桁の数字によって駅名称をコード化し,上記3桁の数字コードを介した相互の関連付けを行い,路線別物件検索機能を可能なものとしているということができる。したがって,このような意味において各テーブル間は関連付けられているということができるから,被告らの主張は採用できない。
(エ)被告らは,原告・被告各データベースのPROJECTテーブルの行政区分コードフィールドとPREFテーブルのJCODEフィールドとの関連付けを否定し,乙29の7及び8を提出する。また被告らは,PROJECTテーブルの行政区分コードフィールドとANMテーブルのM99フィールドとが関連付けを否定し,乙29の9及び10を提出し,さらに,PREFテーブルのJCODEフィールドとTOWNテーブルのJCODEフィールドとの関連付けを否定し,乙29の11を提出する。しかし,PROJECTテーブルの行政区分コードフィールドとTOWNテーブルJCODEフィールドとは,主キーと外部キーが設定されていると認められるから関連付けがされている。また,上記(ウ)と同様に,TOWNテーブルのJCODEフィールドに格納された5桁の数字の上2桁が,PREFテーブルのJCODEフィールドに格納された2桁の数字と一致するように構成されている。
そして,TOWNテーブルのJCODEフィールドに格納された5桁の数字のうち上2桁が都道府県名称を,下3桁が市区町村名称をコード化したもので,このようなコード化をすることによって,都道府県・市区町村別物件検索を可能にしている(例えば,PREFテーブルのJCODE「13」は東京を意味し,TOWNテーブルのJCODE「13101」は東京都千代田区を,「13102」は東京都中央区をそれぞれ意味する。)。また,ANMテーブルのM99フィールドとTOWNテーブルのJCODEフィールドは,そもそもn対1の関係が成立している。したがって,被告らの主張は採用できない。
2 争点(1)原告データベースが著作権法にいうデータベースの著作物に該当するか(争点1)(2)被告データベースが原告データベースの複製であり,その著作権を侵害しているか(争点2) ア 被告データベースが原告データベースに依拠して作成されたものか(争点2(1)) イ 原告データベースのうち被告データベースと共通する情報及び構成が,著作物性を認めるに足りる創作性を有するか(争点2(2)) 3 争点に関する当事者の主張(1)争点1(原告データベースが著作権法にいうデータベースの著作物に該当するか)【原告の主張】 原告データベースにおける情報分類項目等の選択及び体系的構成は,同業他社のデータベースのそれとは大きく異なっており,そのいずれにも創作性が認められるから,原告データベースは著作権法12条の2にいうデータベースの著作物に該当する。
データベースの創作性とは,ユーザーにどのような使い勝手のデータベースを提供するかを構想した上,(@)どういうテーブルをいくつ作るか,(A)各テーブルにどのようなフィールド項目を振り分けるか,(B)それらのテーブル間にどのような関連付けを行うか,を総合考慮して判断されるべきである。そして,生の情報として,新聞・パンフレットなどから何を採り上げ,相互にどのように関連付けるかによって,千差万別のデータベースが作成される。
ア 情報項目等の選択の創作性 原告データベースには,情報の選択,情報項目の設定,テーブル構成,リレーションの張り方,テーブル間の関連付けのいずれの段階にも,制作者の独自性が認められる。このことは,不動産経済調査月報(乙1;以下「不動産月報」という。)や同業他社のデータベースの情報項目と比較しても明らかである。
例えば,同業他社であるMRC社のデータベースのタイプテーブルと比較すると,MRC社のデータベースのテーブルは「M_部屋タイプ」であり,その「タイプ名」は「1R・1K・1DK・1LDK・2K・2DK・2LDK・3K・3DK・3LDK・4DK・4LDK・5DK」のように,一般的な部屋タイプが入力されている(甲28)。これに対し,原告データベースのタイプテーブルの「タイプネーム」には,「フリーDIO・1LLDK・1SK・1SLDK・1SSK・1SSLDK(以下略すが,合計92もの部屋タイプを有している。)」のように,通常使われることのない用語による分類がされている(甲14)。
被告らは,原告データベースのフィールド項目のうち,集計項目を除く項目のほとんどは,不動産月報等の他の媒体に記載されているから,同項目の設定については何らの創作性も認められないと主張し,その証拠として乙2を提出する。
しかしながら,以下に述べるとおり,被告らの主張は,原告データベースのフィールド項目と不動産月報等の他の媒体の記載との比較を正確に行っているとはいえないものである。
(ア)広告・パンフレットとの比較対照について データベースの構築に際し,一定の情報媒体から情報を獲得することは不可避である。原告データベースにおいても,ヒアリング以外では広告・パンフレットを素材にしており,原告データベースにその情報が記載されていることは当然である。
甲9〜12の3をみると,原告データベースの構築に際しすべてのデータが取り込まれているのではなく,データベースに取り込むべき情報が選択されていることが分かる。そもそも,広告・パンフレットとして使用することを目的として選択されたデータと,データベース構築のために使用することを目的として選択されるデータとは,情報の位相を異にするものである。しかるに,被告らが行っているような原告データベースのフィールド項目と広告・パンフレットとの比較は,このような点に考慮することなく,単純な項目の有無を比較しているにすぎないから,無意味である。
(イ)「不動産の表示に関する公正競争規約」(12.7.7公正取引委員会告示第14号;乙33)との比較対照について 被告らは,乙2において,原告のフィールド項目と「不動産の表示に関する公正競争規約」(以下,「公正競争規約」という。)に記載されている項目とを比較し,原告データベースのフィールド項目が公正競争規約から導き出されていると主張するが,公正競争規約のどこから,本件データベースの情報項目のどの項目が導かれるのか,具体的なところが明らかでない。
(ウ)不動産月報の情報項目との比較について 被告らは,乙2において,本件データベースの情報項目と同様の情報項目が不動産月報等の他の媒体にも存在すると指摘するが,以下のとおり誤りである。
(a)「物件名MAIN」 被告らは,乙2において,原告データベースのフィールド項目「物件名MAIN」に関し,不動産月報の項目に○を付し,同じ項目が不動産月報にも存在すると主張する。
この点,原告データベースでは,PROJECTテーブルに「物件名MAIN」,詳細テーブルに「物件名SUB」というフィールド項目が設定されており,両者はその機能が明確に区別されている。すなわち,「物件名MAIN」フィールドには,マンション全体の情報を集計した通期のデータが納められているのに対し,「物件名SUB」フィールドには,販売期分けごとのデータが納められており,物件名に何期という情報が付け加わっている。
このように,通期と期分けごとのデータとで情報項目を異ならせることにより,原告データベースは,販売状況を多角的に提供できるものとなっている。
これに対し,不動産月報の物件名は,「コスモ浦和グレイスアベニュー1期」のように,期分けのデータが記載されている。
つまり,不動産月報には,期分けごとのデータ項目(「物件名SUB」のデータ)は存在するものの,本件データベースにあるような通期のデータ項目(「物件名MAIN」のデータ)は存在しない。
したがって,被告らの主張のように,不動産月報に「物件名MAIN」と「物件名SUB」の双方に該当する項目があるとするのは誤りである。 (b)「種別コード」 被告らは,乙2において,原告データベースのフィールド項目である「種別コード」が不動産月報にも存在すると指摘する。
しかるに,原告データベースにおいて種別コードを設けている理由は,1「一般分譲」,7「シルバー用途マンション」,8「定期借地権付マンション」というように物件の使用用途を明らかにするところにある。
これに対し,不動産月報記載の「土地権利」との記載は,分譲・所有権分譲・借地権分譲など土地(敷地)に対する権利形態を示すものであって,原告データベースのフィールド項目である「種別コード」とはその趣旨が全く異なっている。
(c)「物件所在地」 被告らは,乙2において,原告データベースのフィールド項目「国内分類コード,行政区分コード,町丁名手入力,地番,住居表示」と同一の項目が不動産月報にも存在すると指摘する。
しかし,原告データベースのフィールド項目は以下のような趣旨で設けられている。すなわち,「行政区分コード」フィールドは,正数値で与えられており,これが,大量のデータをより早く処理することを可能にする。また,「町丁名入力」フィールドは,町丁名検索を行うことを可能にするために作成され,町丁名の記入ミスを防ぐことができる。さらに,「国内分類コード」フィールドは,全国を9のエリアに分けた分類項目であり,原告データベースの関東版・中部版を作成する時に,データの切り出しを行うことができる。
このように,それぞれ独自の機能を持ったフィールド項目は,不動産月報には見られない。特に,「国内分類コード」は,前記のように,全国的な規模で情報提供をするための機能であり,関東地域限定でまとめられている不動産月報にはその記載がないはずのものである。
(d)「交通」 被告らは,乙2において,本件データベースのPROJECTテーブルの情報項目のうち,「路線1,路線手入力1,徒歩1,バス1,車1,路線2,路線手入力2,徒歩2,バス2,車2,路線3,路線手入力3,徒歩3,車3」の各項目に該当するものが,不動産月報にも存在すると指摘している。
しかし,不動産月報(乙1)の記載事項を見れば分かるとおり,調査月報にあるのは,「交通」という項目のみであって,本件データベースの項目のように,「路線,徒歩,バス,車」といった交通手段による情報の区分けはされておらず,任意の一つの交通手段を記載できるのみである。
それに対し,原告データベースでは,利用可能な交通手段を可能な限り捕捉するべく,各交通手段別に,また,さらに同じ交通手段についても1から3と分類して情報分類項目を設定しているのである。
原告データベースが,このように多数の情報分類を行っているのは,不動産月報が目的とした最寄り駅までの交通状況を示すことにとどまらず,駅別集計や路線検索,最寄り駅以外にアクセス可能な駅検索等を可能にすることをも目的としたからである。
このように,原告データベースの情報項目の設定と不動産月報の情報項目の設定は,その目的・機能の点で大いに異なっており,両者は決して同一ではない。
これを一緒にしてしまう比較は誤りである。
(e)「法規制コード」 被告らは,乙2において,本件データベースの情報分類項目「法規制1-1,法規制1-2,法規制1-3,法規制2-1,法規制2-2,法規制2-3」と同一の項目が不動産月報にも存在すると指摘する。
しかし,不動産月報(乙1)の「法規制」の項目に「準工業」とあるように,調査月報に記載される情報が都市計画法上の用途地域区分のみであるのに対し,原告データベースの「法規制1-1,法規制1-2,法規制1-3」は都市計画法上の用途地域区分,「法規制2-1,法規制2-2,法規制2-3」は,「その他の法令による地域区分」,例えば,都市計画法上の防火区域や高度地区,自然公園法上の規制区域に関する情報項目であり,不動産月報に比較してより多くの情報項目の設定をしていることは明らかであり,共通する部分があるからといって,同一の項目があると評価することはできない。
(f)「駐車場」 被告らは,乙2において,本件データベースの「駐車場合計台数,賃貸駐車場(敷地内),賃貸駐車場(敷地外),分譲駐車場台数,賃貸駐車場金額MIN(敷地内),賃貸駐車場金額MAX(敷地内),賃貸駐車場金額MIN(敷地外),賃貸駐車場金額MAX(敷地外),分譲駐車場金額MIN,分譲駐車場金額MAX」と同一の項目が不動産月報に存在するとしている。
しかし,不動産月報(乙1)の「駐車場」という項目に記載されている事実は,台数,最低賃貸額,最高賃貸額にすぎず,そこには,原告データベースの情報分類項目にある「賃貸か分譲か」,「敷地内か敷地外か」といった情報は盛り込まれていない。原告データベースは,情報の細分化をはかることで,賃貸駐車場に関する多角的な情報を獲得できるようにすることを目的としていたためにこのような情報分類項目を設けたのある。
このように,駐車場に関する原告データベースの情報分類項目と不動産月報のそれは,到底同一のものとは評価できない。
(g)「事業主名・販売提携・設計・施工」 被告らは,乙2において,本件データベースの「事業主1ないし事業主5,販売会社1ないし3,設計1及び2,施工1及び2」に該当する項目が調査月報に存在すると指摘する。
たしかに,不動産月報(乙1)には,事業主名・販売会社・設計・施工の各項目は存在している。しかし,本件データベースの情報分類項目は,「事業主,販売会社,設計,施工」の情報をさらに細分化して,1ないし5若しくは1ないし3又は1及び2の番号を付している。 これは,大規模な分譲マンション等の開発の際に,複数の事業者が共同事業を行うことが一般的であり,その場合に1社のみ採り上げたのでは事業の実態を正確に把握できないことから,原告データベースでは,正確に把握できるよう事業者・販売者・設計・施工の情報を細分化して情報項目を設定したものである。したがって,原告データベースの情報項目と不動産月報のそれとは,上記のように内実は大きく異なる。
(h)「即日完売」・「即完最高倍率」・「即完平均倍率」 被告らは,詳細テーブルの「即日完売」・「即完最高倍率」・「即完平均倍率」と同様の項目が,不動産月報にも存在すると指摘する。
ここで,「即日完売」とは,予告販売時期に見込み客などの集客を行い,一週間ほどの登録期間を設けた後の登録期間満了日を正式な販売開始日とした場合に,その開始日においてすべての住戸に申込みが入っていることをいう。そして,「即完最高倍率」とは,一つの住戸に対する申込みのうち,即日完売時における最高倍率のことを,「即完平均倍率」とは,各住戸の倍率の平均値をいう。
他方,不動産月報(乙1)においては,即日完売という欄があるのみであり,同月報において,「即完最高倍率」,「即完平均倍率」なる欄は全く見当たらない。せいぜい,即日完売の欄に記載することができるという意味しかなく,両者を同一のものとして扱うのは不当な比較というほかない。
(エ)MRC社のデータベースの情報項目との比較 原告データベースの情報分類項目の創作性は,以下のように,同業他社(MRC社)のデータベースの情報項目と比較しても明らかである(甲18)。
(a)「物件名MAIN」 物件名に関しては,MRC社のデータベースの情報分類項目は不動産月報のそれと類似している。すなわち,甲17に「パークハウス馬込台第1期」とあるとおり期分けごとの情報のみである。
(b)「物件所在地」 この点も,不動産月報と同様,所在地なるフィールド項目1つがあるのみで,原告データベースのように情報分類が細分化されていない。
(c)「交通」 MRC社のデータベースは,「交通」・「最寄り駅」・「徒歩」・「バス」の4つの情報分類項目を持っているが,最寄り駅までの交通状況を明らかにするにとどまるところが原告データベースとは大きく異なる。
(d)「法規制コード」 MRC社のデータベースは,都市計画法上の用途地域についての情報分類は行っているが,原告データベースのようにそれ以外の法令上の規制については何ら項目が設けられていない。
(e)「駐車場」 MRC社のデータベースは,賃貸と分譲の駐車場の数を示すのみであり,原告データベースように多角的な情報分類はされていない。
(f)「事業者・販売提携・設計・施工」 MRC社のデータベースは,事業者のフィールド項目は1つしか存在していない。このため,共同事業者がある場合に,正確な共同事業の実態を捕捉できない点で,原告データベースと大きく異なる。
(g)「即日完売」・「即完最高倍率」・「即完平均倍率」 MRC社のデータベースは,「状態」というフィールド項目に「完売か売り出し中か」が記載されるのみであり,原告データベースのように倍率に関する情報分類項目は設けられていない。
(オ)以上とは逆に,不動産月報又はMRC社のデータベースには存在するが,原告データベースには存在しない情報項目がある。例えば,不動産月報には,「エレベーター,土地権利証,確認番号,距離,冷暖房,給湯,商品企画」などの項目があるが,それに対応する情報項目は,原告データベースには存在しない。
また,MRC社のデータベースの項目には,「エレベーター,主開口方位,借地料」及び「初月売,当月売,累計売」の各項目があるが,それに対応する情報項目は,原告データベースには存在しない。
(カ)集計フィールド項目について 集計フィールド項目とは,リレーションの働きにより,他のコンテンツフィールド項目に何らかの計算値を与えて指標値などに加工した情報を格納しておくフィールド項目であるところ,集計フィールド項目がこのようなプロセスを経たものである以上,本来人が別途計算したうえで記載するというプロセスを経る不動産月報の項目と単純に比較すべきものではない。
被告らは,乙3において,集計フィールド項目について,原告データベースとMRC社のデータベース等とを比較することで,原告データベースの集計項目について,集計項目のうちの多くが同業他社の間で広く用いられているものであり,集計項目の設定自体も原告独自の工夫といえる程のものではなく,業界一般の常識もしくは極めて単純な作業によるものにすぎないと主張する。
しかし,MRC社のデータベースの集計項目と原告データベースのそれとが一致するのは,6項目(「分譲総金額」・「分譲総面積」・「平均価格」・「返金面積」・「初月売戸数」・「初月売率」)のみで,原告データベースは,その他77の集計フィールド項目を有している。
このように,原告データベースにおける集計フィールド項目の情報項目設定数は他のデータベースのそれをはるかにしのぐもので,情報項目の設定に原告独自の個性が表出されていることは明白である。
イ 体系的構成の創作性 原告データベースの体系的構成は,PROJECTテーブル,詳細テーブルを初めとする各テーブルのフィールド項目として数百の項目を設定(つまり,情報収集の方針を決定)した上,多数のエントリーテーブル及びマスターテーブルの作成・データ形式の決定・多数のテーブルの関連付けをしているものであって,この点に,原告データベースの体系的構成の創作性が認められる。このことは,同業他社のMRC社のデータベースが原告データベースに比べて明らかに単純な構成しかとっていないことからしても,明らかである。
被告らは,原告データベースの体系的構成は,「アクセス」を用いたデータベース構築の手順に従えばだれでもできるものであるから,創作性がないと主張する。しかし,「アクセス」を用いた作成手順に従えば当然に原告データベースの体系的構成になるものではなく,情報集積や情報検索の便を考慮した作成者の独自のコンセプトがあって初めて,個別的なデータベースが実現する。被告らの主張を前提とすれば,「アクセス」を用いて作成される同一目的のデータベースはすべて体系的構成において同じものになるはずであるが,失当である。
ウ 上記のとおり,原告データベースには高度の創作性が認められるが,本件のようなデッドコピーの事案では,仮に創作性が低いとしても著作権侵害が認められる。このことは,平成10年(ネ)第3676号同12年11月30日東京高裁判決及びデータベースの著作物に関する昭和61年の著作権法改正のための文化庁著作権審議会第7委員会報告書(昭和60年9月),斎藤博「著作権法」101ページの記述等からも裏付けられる。
エ 被告らは,原告データベースは,マンション開発業者の業界において当然関心の対象になる事柄について,「アクセス」を用いてリレーショナルデータベースを構築したにすぎないから,創作性がないと主張するが,失当である。また被告らは,原告データベースにリレーション(関連付け)が張られていることを否定するが,被告らの主張は,以下の点から,失当であることが明らかである。
(ア)法規制テーブルについて 元来,原告データベースでは,法規制テーブルのうち,用途地域に関するものを法規制1テーブルとし,それ以外の法規制を法規制2テーブルとしていた(甲17の6頁2.1.5)。しかるところ,株式会社デジタルウェアは,法規制1テーブルと法規制2テーブルを合体させたLAW3テーブルを作った(甲14の「LAW3テーブル」を参照)。
この場合,LAW3テーブルのLAW1フィールドは,ID(00とか01とか)が重複して法規制1テーブルのIDと法規制2テーブルのIDが判別できなくなる。被告らが,LAW3テーブルのLAW1フィールドをみると,LAW1フィールドには,同一のデータが2個ずつ入力されている部分があると主張するのは,この状態を指している。
しかしながら,1つのフィールドだけではレコードを特定できない場合,複数のフィールド項目を組み合わせて主キーにすることができる(甲22)。
そこで,まず前記LAW3テーブルに3つ目のフィールド項目CHKを設け,法規制1には1という数字を,法規制2には2という数字を付した。その上で,LAW1フィールドとCHKフィールドの双方に主キーを設定した。
原告データベースのLAW3テーブルのデザインビューを画面キャプチャーした図(甲23の左の図)をみると,その最も左の欄の1行目(LAW11フィールド)と3行目(CHKフィールド)の両方に主キーのマークが付されている。検甲1に格納した被告データベースの対応画面も全く同様の処理が維持されている(甲23の右の図)。このように,LAW1フィールドとCHKフィールドを組み合わせれば,法規制1および2の各レコードが区別されることになる。したがって,LAW3テーブルの中にあるレコードを一意に特定することができるから,「n:n」となるわけではなく,「n:1」の関係となるのであり,関連付けが存在する。法規制2テーブルについても,同様の理由で,関連付けが存在する。
(イ)PROJECTテーブル・all LINEテーブル・all TRAFテーブルの関連について 被告らは,原告データベースに存在する上記各テーブル間のリレーションを否定するが,以下述べるとおり「関連付け」が存在する。
まず,PROJECTテーブルとall TRAFテーブルは,PROJECTテーブルの「路線1」フィールドとall TRAFテーブルの「TRAF1」フィールドが主キーと外部キーの関係で関連付けられている。他方,all LINEテーブルの「LINE1」フィールドは,被告らが指摘するように,3桁の数字が格納されており(乙第29号証の5),一見すると,7桁の数字が格納されているall TRAFテーブルの「TRAF1」フィールドとは1:1の対応関係にないが,「LINE1」フィールドに格納されている数字は,all TRAFテーブルの「TRAF1」フィールドの上3桁と一致するように構成されている。例えば,LINE1フィールドの001はいずみ鉄道を意味し,all TRAFフィールド0010010は,いずみ鉄道の大原駅を意味する。
このように,LINE1フィールドに格納されている3桁の数字は,路線名称をコード化したものであり,TRAF1フィールドの下4桁は駅名称をコード化したものである。路線名称と駅名称に各々このようなコードを与えたうえ,上記3桁の数字コードを介した相互の関連付けを行い,路線別物件検索機能を可能なものとしているのである。 この関連付けにより,本件データベースのユーザーが路線別物件検索機能を操作する際,all LINEテーブルのLINE1フィールドに格納されている路線名称がダイアログボックス内に表示されることになる。 以上のとおり,all LINEテーブルと,all TRAFテーブルとは上記のような関連付けがされており,本件データベースの構造上,他のテーブルと関連付けられている。
(ウ)PROJECTテーブル・PREFテーブル・ANMテーブル・TOWNテーブルの関連について (a)被告らは,上記各テーブルの関連についても,主キーと外部キーに基づく関連付けができないことを根拠として関連付けを否認するが,この点も前記のall LINEテーブル,all TRAFテーブルについて述べたのと同様に,被告らの主張は失当である。
主キーと外部キーに基づく関連付けがされているのは,PROJECTテーブルの「行政区分コード」フィールドとTOWNテーブルの「JCODE」フィールドである。
他方,PREFテーブルとANMテーブルが無関係という訳ではない。PREFテーブルは第1において述べたall LINEテーブルと同じように,TOWNテーブルの「JCODE」フィールドに格納された5桁の数字の上2桁は,PREFテーブルの「JCODE」フィールドに格納された2桁の数字と一致するように構成されている。そして,TOWNテーブルの「JCODE」フィールドに格納された5桁の数字のうち上2桁が都道府県の名称を,下3桁が市区町村の名称をコード化したものであり,このようなコード化をすることによって,都道府県・市区町村別物件検索を可能にしている。例えば,PREFテーブルのJCODE「13」は東京を意味し,TOWNテーブルのJCODE「13101」は東京都千代田区を,「13102」は東京都中央区をそれぞれ意味する。
このような関連付けにより,原告データベースのユーザーが本件都道府県・市区町村別物件検索機能を操作する際,都道府県のダイアログボックスである都道府県を選択すると,市区町村ダイアログボックスにTOWNテーブル内に格納されている市区町村名が表示されるようになっているのである。
以上のとおり,PREFテーブルは,TOWNテーブルと関連付けがされており,原告データベースの構造上,他のテーブルと関連付けられている。
(b)ANMテーブルのM99フィールドとTOWNテーブルのJCODEフィールドも,n対1の関係が成立しており,関連付けがされている。 【被告らの主張】 原告データベースは,情報項目の選択,体系の設定のいずれの点からしても,著作物性を認めるに足りる創作性を有しないから,著作権法にいうデータベースの著作物に該当しない。
ア 情報項目の選択の創作性について 情報の選択に関する創作性とは,情報を選択する基準,すなわちフィールドとしていかなる情報分類項目を設定したのかという点から判断すべきであるが,この点,原告データベースの情報の選択には創作性はない。すなわち,データベースの作成においては,データベースの使用目的に照らして実世界の情報源から必要な情報を選択し,情報項目として設定する。したがって,データベースの使用目的が同一であれば,情報項目はほとんど一致するのであるから,単純に情報源から必要な情報を選択してそれを情報項目として設定したからといって,それだけで直ちに情報項目の設定に創作性が付与されるものではない。そもそも原告・被告各データベースの情報源は,新聞,雑誌広告,パンフレットなどであるが,これらの情報源に記載される事項は,不動産の表示に関する公正競争規約(乙33)によりその大枠が規定されているため,その内容はほとんど変わらないから,これら情報源から収集される情報は,開発するデータベースの使用目的が同一であれば,量的に多い少ないの違いはあっても,ほとんど同一になる。また,原告データベースの情報分類項目のうち,集計項目を除く部分のほとんどは,不動産経済調査月報(乙1),東京カンテイのデータベースの帳票見本(乙34)等の媒体に記載されている情報分類項目をそのまま設定しているにすぎない。原告データベースを同業他社であるMRC社のデータベースと比較してみても,原告データベースに存在しないD_MENテーブルとMRC社のデータベースに存在しない広告テーブルを除けば,MRC社のデータベースの情報項目のほとんどは,原告データベースの情報項目に含まれている。
イ 原告は,原告データベースの情報項目の選択について創作性があると主張するが,以下のとおり失当である。
(a)「物件名MAIN」 原告は,期別販売の物件名について,例えば「ライオンズガーデン横濱寺尾オークステージ 1期」を,純粋な物件名である「ライオンズガーデン横濱寺尾オークステージ」と販売期である「1期」とを別個の情報項目として設定したことをもって,情報項目選定に創作性があると主張するが,性質の異なる2つの情報を2つの情報項目に設定することは,データベース作成の基本的な考え方であり,著作物性を認めるに足りるほどの創作性を有するものではない。
(b)「種別コード」 原告は,「種別コード」に関し,シルバー用途マンションという使用用途の情報と,一般所有権分譲,定期借地権という敷地に対する権利形態の情報とを,同じ「種別コード」として情報項目の設定をしていることに,原告データベースの独自性があり,創作性が認められると主張するが,マンションの使用用途と敷地に対する権利形態という視点の異なる情報を,同一の「種別コード」という情報項目に格納するということは,単に便宜的な分類に過ぎず,言い換えれば分類をしていないのと同じであるから,このようなものに著作物性を認めることはできない(また,そもそも被告データベースでは,この分類は使用されていない。)。
(c)「物件所在地」 同業他社である株式会社東京カンテイのデータベースの帳票見本(乙34)をみると,地番という情報項目と,住居表示を表す所在地という情報項目とがすでに存在するから,分類分けに創作性はない。
(d)「交通」 原告は,原告データベースでは交通に関し複数の項目が設定されているし,3つもの情報項目を設定しているところに創作性があると主張するが,不動産公正競争規約(乙33)によれば,広告,パンフレット等における「交通」の記載方法は,同規約に既に定められているのであって,それらの「交通」の記載から,3つの情報項目を設定することに,著作物性を認めるに足りるほどの創作性があるとは考えられない。同業他社である東京カンテイのデータベースの帳票見本(乙34)をみても,「最寄駅1」「最寄駅2」として2つの項目が記載されている。
(e)「法規制コード」 原告は,不動産月報は,用途地域以外の法規制を採り上げていないと主張するが,誤りである。不動産月報には,用途地域以外の法規制も記載されている(乙10)。
また,原告は,MRC社のデータベースでは用途地域以外の法規制は採り上げられていないと主張し,「法規制1」「法規制2」「法規制3」のフィールドの設定に原告の独自性が認められると主張し,また,MRC社のデータベースでは用途地域として1フィールドしか入れられないのに対し,原告データベースでは3フィールドまで入れられると主張して,原告データベースの法規制フィールドには創作性が認められると主張する。しかし,マンション建設において,複数の用途地域及び複数の法令上の制限地域にわたって建設されることは多々あり,情報源である広告,パンフレットには,これら複数の法規制が記載されている。これらの有限である組み合わせについて,用途地域と用途地域以外の法令上の制限に分け,各項目につき3つのフィールドを設定しただけで,著作物性を肯定するに足りるほどの創作性が認められるとは考えられない。
(f)「駐車場」 同業他社である株式会社東京カンテイのデータベースの帳票見本(乙34)をみると,「駐車場」として,(敷地内),(敷地外)合計,「駐車料金」「分譲駐車場」との項目ないし記載がすでに存在するから,原告データベースの分類分けに創作性はない。
(g)「事業主名・販売提携・設計・施工」 原告は,5つの「事業主」,3つの「販売会社」,2つの「設計者・施工者」と情報項目を定めたことに創作性が認められると主張するが,新築分譲マンションの事業主(売主)等の数は,多くて8社くらいであり,この中から5つ,3つ,2つを選んだからといって大きな意味はない。加えて,同業他社である株式会社東京カンテイのデータベースの帳票見本(乙34)をみると,3つの売主(事業主)「売主1〜3」,1つの「販売代理」,2つの施工「施工1,2」の項目がすでに存在する。
(h)「即日完売」・「即完最高倍率」・「即完平均倍率」 原告は,「即日完売」・「即完最高倍率」・「即完平均倍率」の項目のうち,不動産月報には「即日完売」の項目しか存在しないと主張するが,誤りである。不動産月報にも,「即完最高倍率」「即完平均倍率」の記載がある。これらの項目は,ヒヤリング情報に基づく集計値であり,「即完最高倍率」などの集計に当たって簡単に割り出せるものであるから,原告が主張する「即完最低倍率」の情報項目を加えて設定したからといって,その項目設定に著作物性を有するほどの創作性は認められない。
(i)集計フィールド項目について 集計項目フィールド項目については,パンフレット,新聞広告,雑誌広告,お知らせ看板等から入手した数値に計算を施して得られた結果を1つの項目として設定するものであるが,原告データベースで用いられている集計項目のうち多くは同業他社の間で広く用いられているし(乙3),原告データベースのみで用いられている集計項目についても,単純な合計値,平均値,最大値,最小値を1つの項目にしたものにすぎない。したがって,同集計項目の設定自体も原告独自の工夫といえるほどのものではなく,業界一般の常識又は極めて単純な作業によるものであって,原告のフィールド項目の設定に創作性は認められない。
ウ 体系の設定に関する創作性について (ア)原告は,原告データベースの作成過程において,多数のフィールド項目,テーブルを設定し,データ形式も決定した上でテーブル間のリレーション付けを行い,エントリーなどのためにクエリーを作成していることをもって,体系の設定に創作性があると主張するが,原告の同主張は,単に「アクセス」を用いてリレーショナルデータベースを構築したことを述べるにすぎない。
(イ)被告データベースの設計について 被告データベースの設計をみても,被告データベースのテーブル構成及び関連付けは,データベースの基本的な考え方に基づいて作成されたものにすぎないから,これに対応する原告データベースの部分に創作性があるということはできない。
(a)データベースを設計する場合,次の手順に従って設計するのが通常である。すなわち,まず@データベースの利用目的を決定し,Aテーブルを決定し,Bフィールド項目を決定し,Cテーブル間のリレーションを決定する。被告データベースは,以上の手順に従って設計されている。そして,被告データベースの利用目的は,主として,マンション建築販売業者による新築マンション建築予定地周辺の建築販売情報の収集にある。そして,被告データベースの場合,情報を収集する情報源は,主に@お知らせ看板,A不動産広告(週刊住宅情報を含む),B購入者向けパンフレット,Cヒヤリング情報等であり,このような情報源から,新築マンションのエリアマーケティングに必要な最低限の情報を収集したのが,被告データベースである。
(b)テーブルの決定 テーブルの決定は,収集した情報をその性質に合わせて分類し,その分類に基づいて決定する。被告データベースの収集した情報をその性質に基づき分類すると,次の7つに分類される。それは,建物立地,販売,部屋,広告履歴,申込履歴,タイプ別集計値,価格帯別集計値の7つであり,それぞれの分類ごとに複数の情報項目が含まれてくる。そして,被告データベースは,このように分類された情報分類をそのまま,「PROJECT」「詳細」「住戸一般」「広告」「申込」「月報タイプ」「月報価格」としてテーブル化したものにすぎない。
(c)テーブル間の関連 このようにして設定されたテーブル間の関係は,各テーブルに格納されるデータの性質により,おのずから決定される。被告データベースのテーブル構成及び関連付けは,以下のとおり,データベース構築の基本的な考え方に基づいて作成されたものにすぎず,この部分に対応する原告データベースについて,原告が主張するような著作物性を認めるに足りるほどの創作性はない。
@ PROJECTテーブルと詳細テーブルとの関係 PROJECTテーブルには,新築マンションの建物全体のデータが格納され,詳細テーブルには,販売に関するデータが格納される。例えば,「ライオンズガーデン横濱寺尾オークステージ 1期」という物件名のうち,物件名である「ライオンズガーデン横濱寺尾オークステージ」の部分,すなわち,販売期によって変動することのない建物全体の名称のデータは,PROCECTテーブルに格納される。これに対して,「1期」という販売期のデータ部分は,販売に関する情報であるとともに,将来的に「2期」「3期」と変動する要素をもったデータであるので,詳細テーブルに格納される。このように,性質の異なるデータ及び変動要素を持つデータと変動要素を持たないデータとを分離し,別個のテーブルに帰属させるという考え方は,データベース構築の基本的な考え方である。
原告は,原告データベースがPROJECTテーブルと詳細テーブルに分けてデータを格納することにつき創作性があると主張するが,上述したとおり,被告データベースにおいてPROJECTテーブルと詳細テーブルに分けた理由は,格納するデータの性質及び変動要素を基準としているのであって,このようなテーブル設定に,著作物性を認めるに足りるほどの創作性は存在しない。
また,上述したとおり,PROJECTテーブルには,建物全体に関するデータが格納され,詳細テーブルには,販売に関するデータが格納されるところ,販売は,ある建物の販売であるから,詳細テーブルはPROJECTテーブルに従属した関係に立つ。
したがって,両テーブル間の関連付けは,PROJECTテーブルに主キーを設定し,詳細テーブルに外部キーを設定する関連付け以外にない。
A 詳細テーブルと住戸一般テーブルとの関係 詳細テーブルには,販売に関するデータが格納され,住戸一般テーブルには,個々の部屋に関するデータが格納される。1つの販売に対して複数の部屋が販売されるから,販売される部屋データは変動要素を有している。したがって,これらのデータは,別個のテーブルに格納するのがデータベース構築の基本的な考え方に合致する。
そして,両テーブルの関係は,1つの販売に対して複数の部屋が販売されるのであるから,住戸一般テーブルは,詳細テーブルに従属する関係に立つ。したがって,両テーブルの関連付けは,詳細テーブルに主キーを設定し,住戸一般テーブルに外部キーを設定するしかない。
B 詳細テーブルと広告テーブルの関係 詳細テーブルには,販売に関するデータが格納され,広告テーブルには,個々の販売に対する広告履歴データが格納される。1つの販売に対して複数の広告が出稿されるので,出稿される広告履歴データは変動要素を有している。したがって,これらのデータは別個のテーブルに格納するのがデータベース構築の基本的な考え方に合致する。
そして,両テーブルの関係は,1つの販売に対して複数の広告が出稿されるのであるから,広告テーブルは詳細テーブルに従属する関係に立つ。したがって,両テーブルの関連付けは,詳細テーブルに主キーを設定し,広告テーブルに外部キーを設定するしかない。
C 詳細テーブルと申込テーブルの関係 詳細テーブルには,販売に関するデータが格納され,申込テーブルには,個々の販売に対する申込履歴データが格納される。1つの販売に対して複数の申込がされるので,なされた申込履歴データは変動要素を有している。したがって,これらのデータは別個のテーブルに格納するのが,データベース構築の基本的な考え方に合致する。
そして,両テーブルの関係は,1つの販売に対して複数の申込がされるのであるから,申込テーブルは詳細テーブルに従属する関係に立つ。したがって,両テーブルの関連付けは,詳細テーブルに主キーを設定し,申込テーブルに外部キーを設定するしかない。
D 詳細テーブルと月報タイプテーブルの関係 詳細テーブルには,販売に関するデータが格納され,月報タイプテーブルには,個々の販売に対する間取りごとの集計値データが格納される。1つの販売に対して販売される部屋の間取りは複数存在するから,間取りごとの集計値データは変動要素を有している。したがって,これらのデータは別個のテーブルに格納するのが,データベース構築の基本的な考え方に合致する。
そして,両テーブルの関係は,1つの販売に対して,販売される間取りが複数存在し,間取りごとの集計値も複数存在するから,月報タイプテーブルは詳細テーブルに従属する関係に立つ。したがって,両テーブルの関連付けは,詳細テーブルに主キーを設定し,月報タイプテーブルに外部キーを設定するしかない。
E 詳細テーブルと月報価格テーブルの関係 詳細テーブルには,販売に関するデータが格納され,月報価格テーブルには,個々の販売に対する価格帯ごとの集計値データが格納される。1つの販売に対して販売される部屋の価格は複数存在するから,価格帯ごとの集計値データは変動要素を有している。したがって,これらのデータは別個のテーブルに格納するのが,データベース構築の基本的な考え方に合致する。
そして,両テーブルの関係は,1つの販売に対して,販売される部屋の価格が複数存在し,価格帯ごとの集計値も複数存在するから,月報価格テーブルは詳細テーブルに従属する関係に立つ。したがって,両テーブルの関連付けは,詳細テーブルに主キーを設定し,月報タイプテーブルに外部キーを設定するしかない。
F なお,原告データベースのPROJECTテーブル「法規制1-1」・「法規制1-2」・「法規制1-3」フィールドは,法規制コード1テーブルの「法規制コード」フィールドとは関連付けられているものの,LAW3テーブルの「LAW1」フィールドとは関連付けられていない。原告データベースのPROJECTテーブル「法規制2-1」・「法規制2-2」・「法規制2-3」とLAW3テーブルの「LAW1」フィールドとの間も,同様に関連付けられていない。
(d)マスターテーブルについて 原告は,原告データベースにマスターテーブルが作成されていることをもって,原告データベースに創作性があると主張する。しかし,マスターテーブルとは,情報項目として繰り返し使用される項目を独立したテーブルに格納するものであって,データベース構築の基本的な考え方である。したがって,原告が主張するような,著作物性を認めるに足りるほどの創作性は存在しない。
(2)争点2(被告データベースが原告データベースの複製であり,その著作権を侵害しているか)〔争点2(1)(被告データベースが原告データベースに依拠して作成されたものか〕【原告の主張】 被告データベースは,原告データベースのデッドコピーである。すなわち,被告データベースは,破産会社デジタルウェアの元従業員が,破産管財人の補助者であった期間のデータも含め,原告データベースをデッドコピーして持ち出したものである。被告データベースは,コピー隠しのため多少の変更はされているが,基本的には,原告データベースの具体的データを始め,データ項目,テーブル構成,関連付けなどその体系的構成のほとんど全部をコピーしたものである。したがって,被告データベースは,原告データベースに依拠し,これを複製したものといえる。
この結論は,以下の各事情,すなわち具体的データのコピーの事実,フィールド項目のコピーの事実,体系的構成のコピーの事実,被告らの改ざん行為の事実から裏付けられる。
ア 具体的データのコピーの事実 (ア)物件IDと期分けIDの一致(甲2) 甲2は,各物件に付されたIDを原告・被告各データベースについて比較した表である。なお,同表のデータは,被告デジタル・ピクチャーズが平成11年10月ころに同社ホームページで「パンフレット保有情報」として掲載していた情報である。同表をみると,同一物件に関する被告データベースの物件IDと原告データベースの期分けIDが完全に一致することが分かる。
例えば,被告データベースの物件ID97122103Aと同一の期分けIDが原告データベースに存在し,その両者が示す物件名は,ともに「エステスクエアふじみ野ウエストウイング第5次」である。同様に,被告データベースの物件ID98012021と同一の期分けIDが原告データベースに存在し,その両者が示す物件名は,ともに「ベルパーク湘南茅ヶ崎第3期8次アザレア館・ベゴニア館」である。
このように,被告デジタル・ピクチャーズのホームページにおける「パンフレット保有情報」の物件ID132件のすべてが,原告データベースの期分けIDと一致する。このことは,被告らが原告データベースをデッドコピーしたのでなければあり得ない。
(イ)PROJECT IDの対応(甲26) 甲26の12頁は原告データベースのPROJECTテーブルを表示した画面であり,甲26の13頁は被告データベースのPROJECTテーブルを表示した画面である。
一見すると,原告データベースと被告データベースのPROJECT IDは全く異なっているが,実際は,被告データベースのPROJECT IDは,原告データベースのPROJECT IDを機械的に改ざんしたものであるから,両者は実質的に同一である。
例えば,原告データベースの物件「ルネ大宮宮原」のPROJECT IDは,19980003である。これに対し,被告データベースの物件「ルネ大宮宮原」のPROJECT IDは38000300である。また,「NICE URBAN馬込」の原告データベースのPROJECT IDは19980004,同物件の被告データベースのPROJECT IDは38000400である。原告データベースのPROJECT IDの西暦部分(上4桁)から1960を引いた数値を上2桁にし,原告データベースのIDの下4桁をそれに続けて,その後に00を付けるという操作を施すと,被告データベースのPROJECT IDと一致する。 このように,被告データベースの物件を昇順に並べ替えると,PROJECT IDと物件の並び方が原告データベースの物件と完全に一致する。このことは,被告データベースが原告データベースを機械的にコピーした事実を示している。
(ウ)登録日の一致(甲26の16頁以下) 甲26の16頁は,原告データベースと被告データベースの法規制コード1テーブルを並べて表示した画面である。これをみると,原告データベースの法規制コード1テーブルの各法規制コードと,被告データベースの同名テーブルの各法規制コードとの間において,同名のデータの登録日が秒単位に至るまで完全に一致している。
例えば,原告データベースの法規制コード1テーブルにおける法規制コードA0「1種低層住専」の登録日は,97/02/28 9:30:43であるが,被告データベースの同名のテーブルの法規制コードA0「1種低層住専」の登録日は,これと秒単位まで完全に一致している。このことは,被告データベースが原告データベースをデッドコピーしたものであることを示す。
また,被告らは,平成11年(1999年)3月20日以降に被告データベースの構築を開始したと主張するが,これは,被告データベースの中に97/02/28というそれ以前に入力したデータが存在する事実と矛盾する。
(エ)申込率のデータの一致(甲1の1〜3及び甲27) 申込率に記載されるデータは,独自に訪問及び電話調査によって得られたマンションの売れ行き状況を把握するための数値であり,訪問先,訪問数,電話調査の方法や,これらの調査の時期などでその結果は大きく異なる変動性の強いデータである。それにもかかわらず,原告データベースと被告データベースとでその数値の多くが完全に一致する。原告データベース作成者と被告データベース作成者とが,同じ方法で同じ時期に調査を行ったということはあり得ないから,このような一致は,被告データベースが原告データベースをデッドコピーしたものであることを示すものである。
(オ)その他のデータの一致(甲14,15) 原告データベースのマスターテーブルに格納されたデータのほとんどが,被告データベースのそれと一致する。
例えば,all LINEテーブルにおいては,原・被告両データベースとも,001いずみ鉄道,002シーサイドライン,003ニューシャトルのように,全く同じ名称の交通機関が同じ順番に並んでいる。この順番には,誰もが思い付くような定型的な規則性はなく,その完全な符合は,被告らが原告データベースをデッドコピーしたことを示している。
このように,甲14(原告データベースのマスターテーブル)と甲15(被告データベースのマスターテーブル)とを対比すると,すべてのマスターテーブルにおける個別の各データが完全に一致する。マスターテーブル内の個別のデータの完全な一致は,被告データベースが原告データベースをデッドコピーしたものであることを示す。
イ フィールド項目のコピーの事実(甲4〜6,17,26) 原告データベースと被告データベースは,フィールド項目についてもほぼ一致する。特に,被告データベースの項目の中に被告データベースの性質上全く不要な「sybase更新日,sybase登録日」が存在している(甲24の16頁)のは,被告らが原告データベースをコピーしたという以外に説明できない。なお,「sybase更新日,sybase登録日」は被告データベースの平成12年8月版からは削除されている(検甲1,同17頁)。
また,甲17添付の競合会社項目比較表をみると,原告データベースと被告データベースは,その他のフィールド項目についてもほぼ完全に一致する。すなわち,原告データベースにおける各テーブルのフィールド項目のうち,被告データベースにおける各テーブルのフィールド項目として存在しているものは,PROJECTテーブル110フィールドのうち 66フィールド,詳細テーブル92フィールドのうち79フィールド,住戸一般テーブル36フィールドのうち29フィールド,広告テーブル33フィールドのうち30フィールド,月報タイプテーブル17フィールドのうち13フィールド,申込テーブル13フィールドのうち7フィールド,月報価格テーブル10フィールドのうち6フィールド,all LINEテーブル・TOWNテーブル・ANMテーブル8フィールドのうち6フィールド,all TRAFテーブル6フィールドのうち4フィールド,PREFテーブル9フィールドのうち7フィールド,その他のテーブル内のすべてのフィールドである(別紙図2参照)。被告データベースのフィールド項目数が少ないのは,被告らが削除したからであるが,仮に被告らがコピーしなかった部分があるとしても,他の大多数の部分をコピーしたという事実に影響はない。
ウ 体系的構成のコピーの事実(別紙図1,2参照) 別紙図1及び同2を比較すれば,原告・被告の各データベースの間で体系的構成がほぼ一致することが明らかである。すなわち,原告データベースの7個のエントリーテーブル(PROJECTテーブル・詳細テーブル・広告テーブル・住戸一般テーブル・申込テーブル・月報タイプテーブル・月報価格テーブル)及び12個のマスターテーブル(構造reportテーブル・PAPERテーブル・TYPEテーブル・法規制コード1テーブル・法規制コード2テーブル・LAW3テーブル・KAKAKUテーブル・all LINEテーブル・all TRAFテーブル・PREFテーブル・TOWNテーブル・ANMテーブル)すべてが被告データベースに存在しており,被告データベースに存在しないため関連付けられない箇所を除くと,テーブル間の関連付けは,ほぼ完全に一致する。
エ 被告らによる改ざん行為の事実(ア)IDの改ざん 前記のとおり,被告らは,原告の付したIDに機械的操作を加えて,デッドコピーの事実の隠蔽を図った。
(イ)登録日の変更 前記のとおり,法規制コードについて,原告データベースと被告データベースとでは登録日が完全に一致するところ,被告らは,平成12年の8月に,上記登録日の変更を一斉に行った。そのため,すべてのデータ登録日が,99/05/20 16:34:54になっている(甲26の17頁)。このようなことは機械的変更でなければありえないことであり,デッドコピーを示す登録日の一致という事実を隠蔽するためにされたことは,明らかである。
(ウ)サイベース登録日の削除 被告らによるデッドコピーを裏付けるこの項目は,被告データベースの平成12年8月版において削除されており,被告らによる隠蔽工作の跡である(甲26の17頁)。
【被告らの主張】 原告は,被告らが原告データベースをデッドコピーして被告データベースを作成したと主張するが,事実に反する。原告データベースと被告データベースとは,その相違点からみて,別個の著作物である。つまり,被告データベースは,原告データベースに依拠しておらず,原告データベースを複製したものではない。このことは,データベース作成日時の違い,テーブルの数や種類の違い,関連付けの違い,データ量の違いからそれぞれ裏付けられる。
ア データベース作成日時の違い (ア)乙36添付の画面1によれば,原告データベースのプロパティ詳細情報の画面の作成日時は,1998年2月13日13:54:18と記載されている。これに対して,乙36添付の画面2によれば,被告データベースのプロパティ詳細情報の画面の作成日時は,1999年4月15日16:41:00と記載されている。
(イ)乙36添付の画面3によれば,原告データベースのテーブルの詳細表示の画面に記載されている各テーブルの作成日時は,1998年2月13日13時55分18秒から始まっている。これに対して,乙36添付の画面6によれば,被告データベース各テーブルの作成日時は,1999年4月15日17時1分17秒から始まっている。
イ テーブル数や種類の違い (ア)原告データベースである検甲1中のテーブル表示の画面(乙7)によると,原告データベースには62のテーブルが存在する。これに対して,被告データベースのテーブル表示画面(乙8)によると,被告データベースには28のテーブルしか存在しない。
(イ)乙35添付の図2は,原告データベースの主要なテーブルと各テーブル間の関連付けを図表化したものであり,乙35添付の図3は,被告データベースのテーブルと各テーブル間の関連付けを図表化したものである。
この両者を比較すると,原告データベースには,詳細テーブルのほかに,物件情報がその種別ごとに格納されるシルバーテーブル,一棟テーブル,定借テーブルが存在し,また,定借テーブルに対応して住戸定借テーブルが存在するが,被告データベースにはこれらのテーブルは存在しない。なぜなら,被告データベースは,一般の新築分譲マンションと定期借地権付マンション情報しか扱っておらず,また,定期借地権付マンション固有の情報項目は扱っていないからである。また,原告データベースには,このほかに設備関係の情報を格納する設備テーブルが存在するが,被告データベースには,設備テーブルは存在しない。
ウ 関連付けの違い (ア)原告データベースは,ほとんどのテーブルがPROJECTテーブルとPROJECT IDにより関連づけられているが,被告データベースにおいて,PROJECT IDによってPROJECTテーブルと関連付けられているのは,詳細テーブルだけである。
(イ)原告データベースにおいては,PROJECT IDによる関連付けのほかに,詳細テーブルを中心とする期分けIDによる関連付け,月報IDによる関連付けが存在する。これに対して,被告データベースには,詳細テーブルを中心とする期分けIDによる関連付けしか存在しない。
エ データ量の違い (ア)原告データベースのPROJECTテーブルに格納されている物件数は1万5773件であるが,被告データベースのPROJECTテーブルに格納されている物件数は5536件にすぎない。
(イ)乙36添付の画面11によれば,原告データベースと被告データベースのPROJECTテーブルに存在する物件のうち同一物件を扱っている件数は,2431件にすぎない。さらにこの中から同一情報を抽出すると,その数は170件にすぎない。たしかに,原告データベースと被告データベースとの間には重複情報が存在するが,存在する重複情報はごくわずかであるし,データ自体が著作物性を持つものでない以上,このデータの重複が著作権侵害と結び付くものとはいえない。
〔争点2(2)原告データベースのうち被告データベースと共通する情報及び構成が,著作物性を認めるに足りる創作性を有するか〕【原告の主張】 原告データベースは著作権法にいうデータベースの著作物に該当し,原告データベースの被告データベースと共通する情報及び構成も,著作物性を認めるに足りる創作性を有している。
【被告らの主張】 原告データベースのうち被告データベースと共通する情報及び構成は,著作物性を認めるに足りる創作性を有しない。すなわち,仮に原告データベース全体の情報の選択に創作性の認められる部分が存在するとしても,被告データベースが設定している情報分類項目は,不動産情報の開示としては必要最低限の項目にすぎない。
つまり,被告らは原告データベースの情報分類項目のうち,創作性のない部分を重複して情報分類項目として設定しているにすぎない。また,体系の設定の点についても創作性はない。
当裁判所の判断
1 争点1(原告データベースが著作権法にいうデータベースの著作物に該当するか)(1)著作権法2条1項10号の3は,データベースとは「論文,数値,図形その他の情報の集合物であつて,それらの情報を電子計算機を用いて検索することができるように体系的に構成したものをいう。」と規定し,同法12条の2第1項は「データベースでその情報の選択又は体系的な構成によつて創作性を有するものは,著作物として保護する。」と規定する。このように,データベースとは,情報の集合物を電子計算機を用いて検索することができるように体系的に構成したものをいうのであるところ,前記前提となる事実によれば,原告データベースは,データベースの情報の単位であるレコードを別のレコードと関連付ける処理機能を持つ「リレーショナル・データベース」と呼ばれるものである。リレーショナル・データベースにおいては,入力される情報はテーブルと呼ばれる表に格納され,各テーブルはフィールド項目に細分され,あるテーブルのあるフィールド項目を他のテーブルのあるフィールド項目と一致させてテーブル間を関連付けることにより,既存の複数のテーブルから抽出したいフィールド項目だけを効率的に選択することができるのであるから,情報の選択又は体系的な構成によってデータベースの著作物と評価することができるための重要な要素は,情報が格納される表であるテーブルの内容(種類及び数),各テーブルに存在するフィールド項目の内容(種類及び数),各テーブル間の関連付けのあり方の点にあるものと解される。
(2)そこで,原告データベースの創作性について検討するに,前記前提となる事実によれば,原告データベースは,新築分譲マンション開発業者等に対する販売を目的とするものであり,同データベースを用いて,新築分譲マンションの平均坪単価,平均専有面積,価格別販売状況等を集計したり,検索画面(甲7の1〜3)に一定の検索条件を入力して,価格帯別需給情報等の情報を,表やグラフのような帳票形式(甲8)で出力したりすることができるものである。そして,原告データベースは,別紙図1のとおりの構造を含むと認められるところ,そのテーブルの項目の内容(種類及び数),各テーブル間の関連付けのあり方について敷衍して述べると,PROJECTテーブル,詳細テーブル等の7個のエントリーテーブルと法規制コードテーブル等の12個のマスターテーブルを有し,エントリーテーブル内には合計311のフィールド項目を,マスターテーブル内には78のフィールド項目を配し,各フィールド項目は,新築分譲マンションに関して業者が必要とすると思われる情報を多項目にわたって詳細に採り上げ,期分けID等によって各テーブルを有機的に関連付けて,効率的に必要とする情報を検索することができるようにしているものということができる。すなわち,客観的にみて,原告データベースは,新築分譲マンション開発業者等が必要とする情報をコンピュータによって効率的に検索できるようにするために作成された,上記認定のとおりの膨大な規模の情報分類体系というべきであって,このような規模の情報分類体系を,情報の選択及び体系的構成としてありふれているということは到底できない。加えて,他に原告データベースと同様の情報項目,体系的構成を有するものが存在するとも認められないことは,原告データベースを含む構造(別紙図1)をMRC社のデータベースが含む構造(別紙図3),不動産月報(乙1),不動産の表示規約(乙33),株式会社東京カンテイの新築マンション詳細情報(1)(乙34)等と比較精査しても明らかである。
したがって,原告データベースが含む構造(別紙図1)は,その情報の選択及び体系的構成の点において,著作権法12条の2にいうデータベースの著作物としての著作物性を認めるに足りる創作性を有するものと,認めることができる。
(3)被告らは,原告データベースの情報項目等の選択はありふれていると主張するが,原告データベースが含まれる構造をみても,7個のエントリーテーブル内には合計311のフィールド項目を,12個のマスターテーブル内には78のフィールド項目を配し,各フィールド項目は,新築分譲マンションに関して業者が必要とすると思われる情報を多項目にわたって詳細に採り上げたものと認められるのであって,これをセットとしてみたとき,創作性がないとはいえない。また被告らは,原告データベースが含まれる構造とMRC社のデータベースが含まれる構造との同一性を指摘し,乙35を提出するが,原告データベースがMRC社のデータベースと共通する構造を含むとしても,原告データベースが含まれる構造の全体とMRC社のデータベースが含まれる構造とを比較すると,原告データベースが含まれる構造に比べてMRC社のデータベースが含まれる構造は単純なものといわざるを得ない。すなわち,原告データベースが含まれる構造は,上記のとおり,種々のテーブルを持ち,400に迫る多数のフィールド項目や多種多様な関連付けを持つ情報分類体系となっているから,その全体をみれば,情報項目等の選択の点に関するほか,体系的構成の点における創作性も優に認められるというべきである。つまり,個々のテーブル,フィールド項目や関連付けに着目するのではなく,テーブル間の多種多様な関連付けなどの全体を総体としてみれば,そこに創作性を認めることが可能である。被告らの主張は採用できない。
また被告らは,原告は単に「アクセス」を使ってリレーショナルデータベースを構築したことを述べるにすぎず,体系的構成の点に創作性はないと主張する。
たしかに,当該データベースが取引されると考えられる業界の状況や先行データベースとの関係等の制約から,当該業界で情報として必須とされる項目は限られてくると考えられるから,業界で通常必須とされる情報項目を設定したにすぎないような,多くの項目を含まないデータベースであれば,単に「アクセス」というコンピュータソフトを使用してその業界一般の情報項目を設定して情報を分類する体系を作成したにすぎないとして,著作物性を否定される場合もあり得よう。しかしながら,原告データベースが含まれる構造は,上記認定のとおり,7個のエントリーテーブル内には合計311のフィールド項目を,12個のマスターテーブル内には78のフィールド項目を配し,各フィールド項目は,新築分譲マンションに関して業者が必要とすると思われる情報を多項目にわたって詳細に採り上げ,期分けID等によって各テーブルを有機的に関連付けて,効率的に必要とする情報を検索することができるようにしているものであるから,かような規模の情報分類体系について,マンション業界のだれであっても「アクセス」を使用すれば同じように作成することができるとは到底いえない。したがって,原告データベースは,著作物性を認めるに足りる創作性を十分肯認することができるというべきである。つまり,これだけ多数のテーブル,フィールド項目,関連付けを,素材となるデータも含めて全体としてみると,著作物性を認めるに足りる創作性を否定することはできないというほかはない。被告らの主張は採用することができない。なお,具体的には,以下のとおりである。
ア テーブル間の関連 被告らは,テーブル間の関係は,各テーブルに格納されるデータの性質によりおのずから決定されるのであり,被告データベースのテーブル構成及び関連付けは,変動要素のある情報とそうでない情報を分けるというデータベース構築の基本的な考え方に基づいて作成されたものにすぎず,この部分に対応する原告データベースについて,原告が主張するような著作物性を肯定するに足りるほどの創作性はないと主張する。そして例えば,PROJECTテーブルと詳細テーブルとの関係について,被告データベースにおいてPROJECTテーブルと詳細テーブルに物件名を分けて格納するようにした理由は,格納するデータの性質及び変動要素を基準としているのであって,このようなテーブル設定に,著作物性を認めるに足りるほどの創作性はないと主張する。
しかしながら,この点は,証拠(甲25,乙35)及び弁論の全趣旨によれば,同業他社のMRC社のデータベースにおいてもこのような構成はとられておらず,他に同様の構成をとっている同業他社のデータベースが存在することも認められないし,総合的体系の一部をなす一つ一つの要素を別個に取り出してきて創作性の有無を論じるのはそもそも相当でない。したがって,たとえ変動要素とそうでない要素とを分けるという発想がデータベース構築の基本にあり,原告データベースが同発想に基づいて構築されていたとしても,これをもってただちに原告データベースの創作性を否定することはできないというべきである。被告らの主張を採用することはできない。PROJECTテーブルと詳細テーブルとの関係,詳細テーブルと住戸一般テーブルとの関係,詳細テーブルと広告テーブルの関係,詳細テーブルと申込テーブルの関係,詳細テーブルと月報タイプテーブルの関係,詳細テーブルと月報価格テーブルの関係についていう被告らの主張も,これと同様の理由により,採用することができない。
イ マスターテーブルについて また被告らは,マスターテーブルとは,情報項目として繰り返し使用される項目を独立したテーブルに格納するものであって,データベース構築の基本的な考え方であるから,著作物性を認めるに足りるほどの創作性はないと主張する。たしかに,単にマスターテーブルを設定すること自体については,そのようにいうことができる。しかし,本件における12個のマスターテーブルは,上記認定のとおりの規模をもつ原告データベースの総合的体系の中の一部に位置づけられて機能するものであるから,マスターテーブルの種類及び数,各マスターテーブルのフィールド項目,その関連付け等によって果たす機能を,全体の情報分類体系中における位置付けから評価して創作性を考えるべきなのであって,個々のマスターテーブルのみを取り出して創作性を論じるのは相当でないというべきである。したがって,被告らの主張を採用することはできない。
(5)以上のとおりであるから,原告データベースについては,全体としてみれば,情報項目の選択及び体系的構成のいずれの点においても,著作権法にいうデータベースの著作物に該当すると判断するに足りる,創作性を肯定することができる。
2 争点2(被告データベースが原告データベースの複製であり,その著作権を侵害しているか)〔争点2(1)被告データベースが原告データベースに依拠して作成されたものか〕(1)前記前提となる事実に証拠(甲13及び弁論の全趣旨)を総合すれば,本件の事実経過として,以下の事実を認めることができる。
ア 株式会社デジタルウェアは,原告データベースの著作者として著作権を有していたが,平成10年12月16日,破産宣告を受けた。
イ 被告Bを始めとする株式会社デジタルウェアの従業員10名は,破産管財人の補助者として,平成11年1月28日ころから同年3月11日ころまで原告データベースの更新作業に従事しており,原告データベースにアクセスする機会があった。
ウ 被告デジタル・ピクチャーズは,平成11年3月,株式会社デジタルウェアの従業員であった被告Bを取締役の一人とし,株式会社デジタルウェアの従業員11名中10名を雇用した。
エ 原告は,平成11年5月21日,破産会社デジタルウェア破産管財人から入札により原告データベースに関する一切の権利を取得した。この入札の際,被告デジタル・ピクチャーズの代表者である被告Aが代表者を務める株式会社エグゼも参加していた。
オ 被告デジタル・ピクチャーズは,平成11年6月ころから,被告データベースを使用し,頒布した。
(2)被告データベースの内容は,上記のとおり,別紙図2のとおりの構造を含むと認められるところ,前記前提となる事実に証拠(検甲1,甲4〜6,15〜17,22〜24,乙2〜5,35)及び弁論の全趣旨を総合して,このような被告データベースを含む構造と原告データベースを含む構造とを,テーブルの内容(種類及び数),各テーブルに設定されたフィールド項目の内容,各テーブルの関連付けのあり方について対比すると,その結果は,以下のとおりであると認められる。
ア テーブルの数及び種類については,被告データベースには7個のエントリーテーブル(PROJECTテーブル・詳細テーブル・広告テーブル・住戸一般テーブル・申込テーブル・月報タイプテーブル・月報価格テーブル)と18個のマスターテーブル(構造reportテーブル・PAPERテーブル・TYPEテーブル・法規制コード1テーブル・法規制コード2テーブル・LAW3ないしLAW8テーブル・KAKAKUテーブル・状況マスターテーブル・all LINEテーブル・all TRAFテーブル・PREFテーブル・TOWNテーブル・ANMテーブル)が存在するが,原告データベースにも,同名称の7個のエントリーテーブル及び同名称の12個のマスターテーブル(構造reportテーブル・PAPERテーブル・TYPEテーブル・法規制コード1テーブル・法規制コード2テーブル・LAW3テーブル・KAKAKUテーブル・all LINEテーブル・all TRAFテーブル・PREFテーブル・TOWNテーブル・ANMテーブル)が存在する(なお,被告データベースにあって原告データベースにないテーブルは,6個のマスターテーブル〔LAW4ないしLAW8テーブル,状況マスターテーブル〕である。)。
イ 各テーブルに存在するフィールド項目については,被告データベースのフィールド項目は,状況マスターテーブルに存在する「ID」フィールド,「状況」フィールドの2フィールド項目を除き,すべて原告データベースにおいて対応するフィールド項目が存在し,しかも,対応するフィールド項目の名称はほぼすべて一致する。
ウ テーブル相互間の関連付けについては,以下のとおりであり,これらによれば,被告データベースに存在する関連付けのほぼすべてと同じ関連付けが,原告データベースに存在することが認められる。
(ア)被告データベースでは,PROJECTテーブルの「PROJECT-ID」フィールドと,詳細テーブルの「P_PROJECTID」フィールドが関連付けられている。これは,原告データベースにおいて,PROJECTテーブルの「PROJECT-ID」フィールドが,詳細テーブルの「PROJECT-ID」フィールドと関連付けられていることと一致する。
(イ)被告データベースでは,PROJECTテーブルの「構造」フィールドと構造reportテーブルの「CODE」フィールドが関連付けられている。これは,原告データベースの関連付けと一致する。
(ウ)被告データベースでは,PROJECTテーブル「法規制1-1」「法規制1-2」「法規制1-3」と,法規制コード1テーブルの法規制コードフィールド及びLAW3〜LAW5テーブルの各「LAW1」フィールドとが関連付けられている。これに対し,原告データベースのPROJECTテーブル「法規制1-1」・「法規制1-2」・「法規制1-3」は,原告データベースにないLAW4,LAW5各テーブルとの関連付けはないが,法規制コード1テーブルの法規制コードフィールド及びLAW3テーブルのLAW1フィールドと関連付けられている。
(エ)被告データベースでは,PROJECTテーブル「法規制2-1」「法規制2-2」「法規制2-3」と,法規制コード2テーブルの法規制コードフィールド及びLAW6〜LAW8各テーブルの各「LAW1」フィールドとが関連付けられている。これに対し,原告データベースのPROJECTテーブル「法規制2-1」・「法規制2-2」・「法規制2-3」は,原告データベースにないLAW6〜LAW8各テーブルとの関連付けはないが,法規制コード2テーブルの法規制コードフィールド及びLAW3テーブルのLAW1フィールドと関連付けられているから,関連付けとしてはほぼ一致する。
(オ)被告データベースでは,PROJECTテーブル「路線1」「路線2」「路線3」の各フィールドとall TRAFテーブルTRAF1フィールドとの間に関連付けがされているが,これは,原告データベースの関連付けと一致する。
(カ)被告データベースでは,PROJECTテーブル行政区分コードフィールドとTOWNテーブルのJCODEフィールドとの間に関連付けがされているが,これは,原告データベースの関連付けと一致する。
(キ)被告データベースでは,詳細テーブル期分けIDフィールドと,広告テーブル「期分けID」,住戸一般テーブル「期分けID」,申込テーブル「期分けID」,月報タイプテーブル「期分けID」,月報価格テーブル「期分けID」の各フィールド間とが関連付けられている。これは,原告データベースの関連付けと一致する。
(ク)被告データベースでは,詳細テーブル状況コードフィールドと状況マスターテーブル「ID」との間に関連付けがされているが,原告データベースには,状況マスターテーブルが存在しないため,同関連付けはない。
(ケ)被告データベースでは,住戸一般テーブル間取りフィールドとTYPEテーブルTypeCodeフィールド間に関連付けがされている。これは,原告データベースの関連付けと一致する。
(コ)被告データベースでは,広告テーブル媒体名フィールドとPAPERテーブルBCODEフィールド間に関連付けがされている。これは,原告データベースの関連付けと一致する。
(サ)被告データベースでは,月報タイプテーブル間取りコードフィールドとTYPEテーブルTypeCodeフィールド間に関連付けがされている。これは,原告データベースの関連付けと一致する。
(シ)被告データベースでは,月報価格テーブルの価格帯コードフィールドとKAKAKUテーブルKakakuCodeフィールド間に関連付けがされている。これは,原告データベースの関連付けと一致する。
エ 以上ア〜ウによれば,被告データベースは,テーブルの内容(種類及び数),各テーブルに存在するフィールド項目の名称,テーブル間の関連付けのすべての点からして,原告データベースの構造の一部分とほぼ完全に一致すると認められる。なお,被告らは,被告データベースにあって原告データベースにないものとして,6個のマスターテーブル(LAW4〜LAW8テーブル,状況マスターテーブル)や,その他いくつかのフィールド項目がある旨主張するが,これをア〜ウで認定した一致部分の規模と比較するならば,ごく僅かの相違にすぎないと評価すべきであるから,上記のように,被告データベースが原告データベースの構造の一部分とほぼ完全に一致するといって妨げないというべきである。
(3)また,両データベース間で素材とする情報が重なっているかどうかをみるに,証拠(検甲1,甲1の1〜3,甲2〜4,14,15,24〜26,乙4,5)及び弁論の全趣旨によれば,被告データベースに格納されている具体的なデータについて,以下の事実が認められる。
ア 被告データベースの物件購入申込率に関して,平成10年1月1日から同年2月28日までの間に分譲のあった分のデータにつき,対応する物件についての原告データベースの申込率の数値を比較すると,その約9割の数値が一致する(甲1の1〜3,27)。乙37の記載をもってしても,同認定を左右するに足りない(仮に,乙37の記載を前提にして平成10年1月1日から同年12月31日までの間の申込率の数値についてみても,申込率がそもそも入力されていない物件も含んだ全物件2769件中,1823件もの物件に関する申込率の数値が被告データベースと原告データベースとで一致している。)。
イ 被告データベースにおいて,登録日が平成10年1月5日から平成11年3月11日までの間となっている物件に付されている物件IDに関して,その9桁中の上6桁が,原告データベースに付されている期分けIDの9桁中の下6桁とすべて一致する。
ウ 被告データベースにおいて使用する編集分類である帳票の項目及び検索項目が,原告データベースとほぼ一致する。
エ 被告データベースのPROJECT IDは,原告データベースにおける同一物件に付されているのPROJECT IDと規則性をもって対応する。すなわち,原告データベースのPROJECT IDから1960を差し引いた数値を上2桁にし,原告データベースのPROJECT IDの下4桁をそれに続けて,その後に00をつければ,被告データベースのPROJECT IDと一致する。
オ 被告データベースと原告データベースの各法規制コード1テーブル及び各TYPEテーブルにおいては,それぞれの対応するデータの登録日が,日時のみならず時間,分,秒の単位に至るまで一致する。また,同各テーブルにおけるデータには,被告らが被告データベースの構築を開始したと主張する平成11年3月20日より前の登録日が記載されたデータが存在する。
カ 被告データベースの平成12年8月版では,被告データベースの平成12年7月版と異なり,法規制コード,TypeCodeのすべてのデータ登録日が,99/05/20 16:34:54となっている。つまり,被告らが,本訴提起後である平成12年8月ころ,法規制コードの登録日の変更を一斉に行ったと認められる。
(4)上記の(1)〜(3)によれば,被告データベースが素材とする情報が原告データベースと重なっており,制作されたテーブルの内容(種類及び数),各テーブルに設定されたフィールド項目の内容,各テーブル間の関連付けのあり方のすべての点において共通しているということができる。
(5)以上を総合すれば,被告データベースは,原告データベースに依拠して作成されたというべきであって,原告データベースを含む構造は,被告データベースを含む構造とその内容の点で同一であるといわなければならない。
(6)被告らは,データベース作成日時の違い,テーブルの数や種類の違い,関連付けの違い,データ量の違いの各点を指摘し,原告データベースと被告データベースとは,その相違点からみて,別個の著作物であると主張するが,以下に述べるとおり,採用することができない。
ア データベース作成日時の違い たしかに,乙36添付の画面1によれば,原告データベースのプロパティ詳細情報の画面の作成日時は,1998年2月13日13:54:18と記載され,これに対して,乙36添付の画面2によれば,被告データベースのプロパティ詳細情報の画面の作成日時は,1999年4月15日16:41:00と記載されていること,乙36添付の画面3によれば,原告データベースのテーブルの詳細表示の画面に記載されている各テーブルの作成日時は,1998年2月13日13時55分18秒から始まっているのに対して,乙36添付の画面6によれば,被告データベースのテーブルの詳細表示の画面に記載されている各テーブルの作成日時は,1999年4月15日17時1分17秒から始まっていることがそれぞれ認められる。しかし,この事実は,上記に認定した原告データベースと被告データベースとの間の一致点の量と質に照らせば,単に複製後に被告らにおいて別ファイルで登録した可能性を示唆するものであっても,被告データベースが原告データベースに含まれる構造を複製したものとの上記認定を左右するとはいえない。
イ テーブルの数や種類の違い 被告らは,乙7によれば,原告データベースには62のテーブルが存在するところ,乙8によれば,被告データベースには28のテーブルしか存在しないと主張し,また,乙35添付の図2(原告データベースの主要なテーブルと関連付けを図表化したもの)と乙35添付の図3(被告データベースのテーブルと関連付けを図表化したもの)を比較すると,原告データベースには,詳細テーブルのほかに,物件情報がその種別ごとに格納されるシルバーテーブル,一棟テーブル,定借テーブルが存在し,定借テーブルに対応して住戸定借テーブルが存在するところ,被告データベースにはこれらのテーブルは存在しない,原告データベースには,このほかに設備関係の情報を格納する設備テーブルが存在するが,被告データベースには,設備テーブルは存在しないと主張する。 しかし,上記(2)に認定したところによれば,被告データベースは,テーブルの内容(種類及び数),各テーブルに存在するフィールド項目の名称,テーブル間の関連付けのすべての点からして,原告データベースの構造の一部分とほぼ完全に一致していると認められるのであるから,被告らの主張の事実は,単に被告らにおいて原告データベースに存在するテーブルのうちのいくつかを除いて複製を行ったか,あるいは複製後に被告らにおいて原告データベースのテーブルのうちのいくつかを削除した可能性を示唆するものであっても,そのことをもって,被告データベースが原告データベースの一部を複製したものであるという上記認定を左右するものではない。しかも,被告データベースとほぼ完全に一致する原告データベース部分は,上記(2)に認定したとおりの相当程度の規模であるから,原告データベースの同被複製部分のみにおいても十分に有機的なまとまりを有するというべきである(このことは,原告データベースよりもテーブル数,フィールド項目数が少ない被告データベースを,被告デジタル・ピクチャーズ,同エクスが実際に商用に使用,頒布していることに照らしても明らかというべきである。)。被告らの主張を採用することはできない。
ウ 関連付けの違い 被告らは,原告データベースは,ほとんどのテーブルがPROJECTテーブルとPROJECT IDにより関連づけられているが,被告データベースでは,PROJECT IDによってPROJECTテーブルと関連付けられているのは詳細テーブルだけである,原告データベースは,PROJECT IDによる関連付けのほかに,詳細テーブルを中心とする期分けIDによる関連付け,月報IDによる関連付けが存在するが,被告データベースでは,詳細テーブルを中心とした期分けIDによる関連付けしか存在しない,と主張する。
しかし,上記(2)に認定したところによれば,被告データベースは,テーブルの内容(種類及び数),各テーブルに存在するフィールド項目の名称,テーブル間の関連付けのすべての点からして,原告データベースの構造の一部分とほぼ完全に一致しているのであるから,被告らの主張の事実は,単に被告らにおいて原告データベースに存在するテーブルのうちのいくつかを除いて複製を行ったか,あるいは複製後に被告らにおいて原告データベースのテーブルのうちのいくつかを削除した可能性を示唆するものであっても,そのことをもって,被告データベースが原告データベースの一部を複製したものであるという上記認定を左右するものではない。被告データベースとほぼ完全に一致する原告データベース部分は,上記(2)に認定したとおりの相当程度の規模であるから,原告データベースの同被複製部分のみにおいても十分に有機的なまとまりを有するというべきである。被告らの主張を採用することはできない。
エ データ量の違い 被告らは,原告データベースのPROJECTテーブルにおいて格納されている物件数は1万5773件であるが,被告データベースのPROJECTテーブルに格納されている物件数は5536件にすぎない,乙36添付の画面11によれば,原告データベースと被告データベースのPROJECTテーブルに存在する物件のうち同一物件を扱っている件数は2431件であるにすぎず,さらにこの中から同一情報を抽出するとその数は170件であるにすぎないと主張する。
しかしながら,上記(3)に認定したところによれば,被告データベースと原告データベースとの間においては,個別の具体的なデータについても,物件購入申込率,物件ID,帳票の項目及び検索項目,PROJECT ID,法規制コード1テーブルの各データの登録日がすでに一致ないしほぼ一致するものであることが認められるのであって,この他,被告データベースが,その性質上,日々これに含まれる情報を更新していくものであること(弁論の全趣旨により認められる。)や,上記(4)に認定した事実を加味して考えれば,被告らの主張を前提としても,被告データベースが原告データベースに含まれる構造を複製したものであるとの上記認定を左右するに足りないというべきである。
〔争点2(2)原告データベースのうち被告データベースと共通する情報及び構成が,著作物性を認めるに足りる創作性を有するか〕(1)原告データベースにおいて,被告データベースの構造と共通し,被告らが原告データベースの当該部分を複製したと認められる部分(以下「原告データベース被複製部分」という。)は,争点2(1)についての判断において認定した事実を整理すれば,以下のとおりである。
ア テーブルは,7個のエントリーテーブル(PROJECTテーブル・詳細テーブル・広告テーブル・住戸一般テーブル・申込テーブル・月報タイプテーブル・月報価格テーブル)と12個のマスターテーブル(構造reportテーブル・PAPERテーブル・TYPEテーブル・法規制コード1テーブル・法規制コード2テーブル・LAW3テーブル・KAKAKUテーブル・all LINEテーブル・all TRAFテーブル・PREFテーブル・TOWNテーブル・ANMテーブル)である。
イ フィールド項目は,PROJECTテーブル110フィールドのうち65フィールド,詳細テーブル92フィールドのうち79フィールド,住戸一般テーブル36フィールドのうち29フィールド,広告テーブル33フィールドのうち30フィールド,月報タイプテーブル17フィールドのうち13フィールド,申込テーブル13フィールドのうち7フィールド,月報価格テーブル10フィールドのうち6フィールド,all LINEテーブル・TOWNテーブル・ANMテーブル8フィールドのうち6フィールド,all TRAFテーブル6フィールドのうち4フィールド,PREFテーブル9フィールドのうち7フィールド及びその他のテーブル内の全フィールドである。
ウ テーブル相互間の関連付けについては,以下のとおりである。
(ア)PROJECTテーブルの「PROJECT ID」フィールドの,詳細テーブルの「PROJECT ID」フィールドとの関連付け(イ)PROJECTテーブル「構造」フィールドの,構造reportテーブル「CODE」フィールドとの関連付け(ウ)PROJECTテーブル「法規制1-1」・「法規制1-2」・「法規制1-3」フィールドの,法規制コード1テーブル「法規制コード」フィールド及びLAW3テーブルの「LAW1」フィールドとの関連付け(エ)PROJECTテーブル「法規制2-1」・「法規制2-2」・「法規制2-3」フィールドの,法規制コード2テーブル「法規制コード」フィールド及びLAW3テーブルの「LAW1」フィールドとの関連付け(オ)PROJECTテーブル「路線1」「路線2」「路線3」フィールドの,all TRAFテーブル「TRAF1」フィールドとの関連付け(カ)PROJECTテーブル「行政区分コード」フィールドの,TOWNテーブル「JCODE」フィールドとの関連付け(キ)詳細テーブル「期分けID」フィールドの,広告テーブル「期分けID」,住戸一般テーブル「期分けID」,申込テーブル「期分けID」,月報タイプテーブル「期分けID」,月報価格テーブル「期分けID」の各フィールドとの関連付け(ク)住戸一般テーブル「間取り」フィールドの,TYPEテーブル「TypeCode」フィールドとの関連付け(ケ)広告テーブル「媒体名」フィールドの,PAPERテーブル「BCODE」フィールドとの関連付け(コ)月報タイプテーブル「間取りコード」フィールドの,TYPEテーブル「TypeCode」フィールドとの関連付け(サ)月報価格テーブル「価格帯コード」フィールドの,KAKAKUテーブル「KakakuCode」フィールドとの関連付け(2)そこで,原告データベース被複製部分の創作性について検討するに,被複製部分のテーブルの項目の内容(種類及び数),各テーブル間の関連付けのあり方についてみると,この部分だけでも,PROJECTテーブル,詳細テーブル等の7個のエントリーテーブルと法規制コードテーブル等の12個のマスターテーブルを有し,エントリーテーブル内には合計229のフィールド項目を,マスターテーブル内には68のフィールド項目を有しており,期分けID等によって有機的に関連付けられていて,十分効率的に必要とする情報を検索することができるといえる。すなわち,客観的にみて,原告データベース被複製部分のみをとっても,新築分譲マンション開発業者等が必要とする情報をコンピュータによって効率的に検索できるようにするために作成された,膨大な規模の情報分類体系といわなければならず,このような規模の情報分類体系を,情報の選択及び体系的構成としてありふれているということは,到底できない。MRC社のデータベースが含む構造(別紙図3),不動産月報(乙1),不動産の表示規約(乙33),株式会社東京カンテイの新築マンション詳細情報(1)(乙34)等と比較精査しても,原告データベース被複製部分に類する情報分類体系が存在するとは認められない。
したがって,原告データベースのうち被告データベースと共通する情報及び構成が著作物性を認めるに足りる創作性を有するといって妨げない。
4 結論 以上によれば,被告データベースは原告データベースを複製したものであり,原告の有する同データベースの著作権(複製権)を侵害するものと認めるのが相当である。
よって,中間判決として主文のとおり判決する。
裁判長裁判官 三村量一
裁判官 和久田道雄
裁判官 田中孝一
すごい知財EXPO'22