過払い金｜不動産情報DBの不正使用

主文

別紙被告物件目録記載のデータベースは，別紙原告物件目録記載のデータベースを複製したものであり，原告の有する同データベースの著作権を侵害する。

事実及び理由

第１原告の請求

１被告らは，別紙被告物件目録記載のデータベース（以下「被告データベース」という。）を複製，翻案，頒布及び公衆送信してはならない。
２被告らは，被告データベースを記録した磁気媒体を廃棄せよ。
３被告株式会社デジタル・ピクチャーズ・エンターテイメント（以下「被告デジタル・ピクチャーズ」という。），同Ａ及び同Ｂは，各自原告に対し，３０００万円及びこれに対する被告デジタル・ピクチャーズに対しては平成１２年５月１９日から，被告Ａ及び同Ｂに対しては平成１２年５月２４日から各支払済みまで年５分の割合による金員を支払え。
４被告株式会社エクス（以下「被告エクス」という。）は，原告に対し，２７００万円及びこれに対する平成１３年１月２０日から支払済みまで年５分の割合による金員を支払え。

第２事案の概要

本件は，原告が，被告デジタル・ピクチャーズ，同エクスが被告データベースを使用，頒布した行為が，原告の有する別紙原告物件目録記載のデータベース（以下「原告データベース」という。）について原告の有する著作権（データベースの著作権）を侵害すると主張して，被告らに対し，被告データベースの複製，翻案，頒布及び公衆送信の差止め及びこれを記録した磁気媒体の廃棄並びに損害賠償を求めている事案である。
１前提となる事実（証拠により認定した事実については，末尾に証拠を掲げた。）
（１）当事者
ア原告は，情報処理サービス業及び情報提供サービス，コンピュータソフトウェアの企画，開発，販売業務並びに受託開発業務等を営む会社である。
イ被告デジタル・ピクチャーズは，コンピュータシステムの開発，販売，運営及び保守並びにニューメディアに関するシステム開発及び販売等を目的とする会社である。
ウ被告Ａは，被告デジタル・ピクチャーズの代表取締役であり，被告Ｂは，被告デジタル・ピクチャーズの取締役である。
エ被告エクスは，インターネット及びその他の通信システムを利用した情報通信サービス等を目的とする会社である。
（２）原告への権利の帰属
ア原告データベースを含むコアネットは，新築分譲マンション開発業者等に対する販売を目的とするものである。
新築分譲マンション開発業者は，土地を仕入れ，建築企画を行い，建築販売するまでに，過去の建築販売事例，類似の建築販売事例を参考に建築販売計画を立案する。
その際に，業者は，様々な視点からの分析を行う必要があり，各種情報を分析する必要がある。
原告データベースは，これらの業者の必要に対して，日々各種の情報を提供するデータベースサービス事業に資するものである。
原告データベースによって，新築分譲マンションの平均坪単価，平均専有面積，価格別販売状況等を集計することができる。
そして，原告データベースの検索画面（甲７の１３）に一定の検索条件を入力すると，価格帯別需給情報等の情報が，表やグラフのような帳票形式（甲８）で出力される。
イ原告データベースを含むシステムは，株式会社デジタルウェアが昭和６２年に開発したコアネットシステム「調査マン」が起源となっている。
その後，分譲マンションの開発着手から販売終了までを時系列的に追った情報を集積した「広告マン」「企画マン」「ＤＩＧＩ‐ＰＡＣＫ」という名称のデータベースが，同会社により次々と制作，販売され，平成９年に，ウィンドウズとインターネットの普及を背景に，同データベースの統合版である「コアネットｆｏｒＷｉｎｄｏｗｓ」が，同会社により制作，販売された。原告データベースは，同統合版の中に含まれている。
ウ株式会社デジタルウェアは，平成１０年１２月１６日，破産宣告を受けた。
原告は，平成１１年５月２１日，同破産会社破産管財人Ｃから原告データベースに関する一切の権利を譲り受けた。
（３）被告らの行為
被告デジタル・ピクチャーズは，平成１１年６月ころから，新築分譲マンション開発業者に対し，被告データベースを使用して不動産の情報を提供していた。
被告エクスは，平成１２年４月，被告デジタル・ピクチャーズから同データベースに関する一切の権利を譲り受け，以後，新築分譲マンション開発業者に対し，同データベースを使用して，同様に，不動産の情報を提供している。
（４）データベースについて
ア原告データベースは，マイクロソフト社制作に係る「アクセス（Ａｃｃｅｓｓ）」を用いて作成されている。
「アクセス」は，いわゆるリレーショナル・データベースを開発，維持するために用いられるデータベースソフトである。
リレーショナル・データベースは，データベースの情報の単位であるレコードを別のレコードと関連付ける処理機能を持つデータベースである。
イアクセスで作成されるデータベースにおいて，入力される情報はテーブルと呼ばれる表に格納されていく。
テーブルのうち，入力された情報が格納されるテーブルをエントリーテーブルといい，頻繁に使用される情報（例えば地名や駅名等）や検索に用いられる情報が格納されるテーブルをマスターテーブルという。
テーブルは，さらに各フィールド項目に細分される。
各フィールド項目においては，格納されるデータの種類及び型（テキスト，数値，通貨，Ｙｅｓ／Ｎｏなど）が決められている（甲５）。
ウテーブルの各フィールド項目に入れられるデータをレコードという。
各テーブルはフィールド項目が決定された後，具体的なレコードが入力されていく。
エリレーショナル・データベースでは，テーブルを多数作成するが，テーブル間の関連付けのためには，あるテーブルのあるフィールド項目を他のテーブルのあるフィールド項目と一致させる必要がある。
これにより，新たなテーブルを作らないで，既存の複数のテーブルから抽出したいフィールド項目だけを効率的に選択することができる（弁論の全趣旨）。
オデータベースでは，テーブルに格納されているデータをより速く検索，抽出することが重要であり，そのため，フィールド項目の中から，テーブルに格納されている各情報を識別できるようにするためのフィールド項目を選択することが必要になる。
この選択されたフィールド項目のことを主キーという。
主キーを設定したフィールド項目には，重複するデータを入力することはできない。
しかし，１つのフィールド項目だけでは情報を特定できない場合，複数のフィールド項目を組み合わせて主キーにすることができる（甲２２）。
（５）原告・被告各データベースについて（検甲１，甲５，６，１６，２２，乙４，５，３５及び弁論の全趣旨）
ア（ア）原告データベースにおいては，別紙図１の構造が含まれていることが認められ，被告データベースにおいては，別紙図２の構造が含まれていることが認められる。
また，同業他社（ＭＲＣ社）のデータベースでは，別紙図３の構造が含まれていることが認められる（図１３においては，エントリーテーブルが直方体で，マスターテーブルが円柱で示され，テーブルを示す直方体，円柱の上面に，テーブルの名称が記され，また，フィールド項目がそれぞれ存在するテーブルの手前側側面に黒文字で記入され，さらに，テーブル間の関連付けが，テーブルとテーブルとの間をつなぐ渡り廊下のようなもの（横長の棒状の直方体）で示されている。
なお，図２においては，フィールド項目は黒文字及び白文字で記入されているが，黒文字で記入されている項目が存在するフィールド項目であり，また，関連付けは実線及び点線で記入されているが，実線で記入されている項目が存在する関連付けである。）。
（イ）原告・被告各データベースには，エントリーテーブルとして，ＰＲＯＪＥＣＴテーブル，詳細テーブル，住戸一般テーブル，広告テーブル，申込テーブル，月報タイプテーブル，月報価格テーブルが共通して存在するところ，同各テーブルに格納される情報内容は，以下のとおりである。
１ＰＲＯＪＥＣＴテーブルには，マンションの建物・敷地・地域の属性等が格納される。
２詳細テーブルには，マンションの販売の期分けごとの概略等が格納される。
３住戸一般テーブルには，各部屋ごとの詳細が格納される。
４広告テーブルには，各マンション販売の広告出稿の内容が格納される。
５申込テーブルには，初月の販売から各月の売れ行きが，百分率表示の推移等の形で格納される。
６月報タイプテーブルには，各マンションの販売結果が，間取りタイプ別に集計されて格納される。
７月報価格テーブルには，各マンションの販売結果が，価格帯別に集計されて格納される。
（ウ）原告・被告各データベースには，マスターテーブルとして，ａｌｌ　ＬＩＮＥテーブル，ａｌｌ　ＴＲＡＦテーブル，ＰＲＥＦテーブル，ＴＯＷＮテーブル，ＡＮＭテーブル，ＰＡＰＥＲテーブル，ＴＹＰＥテーブル，ＫＡＫＡＫＵテーブル，構造ｒｅｐｏｒｔテーブル，法規制コード１テーブル，法規制コード２テーブル，ＬＡＷ３テーブルが共通して存在するところ，同各テーブルに格納される情報内容は以下のとおりである。
１ａｌｌ　ＬＩＮＥテーブルには，首都圏の鉄道各社の各路線がコード付けられて格納される。
２ａｌｌ　ＴＲＡＦテーブルには，首都圏鉄道の各駅名がコード付けられて格納される。
３ＰＲＥＦテーブルには，全国の都道府県の名称がコード付けられて格納される。
４ＴＯＷＮテーブルには，全国の市町村の名称がコード付けられて格納される。
５ＡＮＭテーブルには，首都圏及び札幌の一部の町丁名がコード付けられて格納される。
６ＰＡＰＥＲテーブルには，広告媒体の名称がコード付けられて格納される。
７ＴＹＰＥテーブルには，間取り区分がコード付けられて格納される。
８ＫＡＫＡＫＵテーブルには，価格帯区分がコード付けられて格納される。
９構造ｒｅｐｏｒｔテーブルには，建築構造部分がコード付けられて格納される。
１０法規制コード１テーブル，法規制コード２テーブルには，法規制区分がコード付けられて格納される。
また，ＬＡＷ３テーブルは，法規制コード１テーブルと法規制コード２テーブルを合体させたものである。
イなお，上記のとおり原告・被告各データベースの構造を認定した理由は，次のとおりである。
（ア）被告らは，検甲１のＣＤ‐ＲＯＭ中「原告側ＤＢ」フォルダー「ＹＵＫＩＫＯ．ｍｄｂ」ファイル中には，この他２８以上のテーブルが存在し，ＰＲＯＪＥＣＴテーブルのＰＲＯＪＥＣＴ　ＩＤフィールドは，少なくとも他に２１以上のテーブルとも関連付けられていると主張するが，同主張も，原告データベースにおいて，図１の構造が含まれていることを否定するものではない。
（イ）被告らは，原告・被告データベースとも，ＰＲＯＪＥＣＴテーブル「法規制１‐１」「法規制１‐２」「法規制１‐３」各フィールドと，ＬＡＷ３テーブルのＬＡＷ１フィールドとが関連付けられていることを否定し，ｎ：ｎの関係にあるものは関連付けられているとはいえないと主張し，乙２９の１，２を提出する。
しかし，甲２２によれば，１つのフィールド項目だけではレコードを特定できない場合，複数のフィールド項目を組み合わせて主キーにすることができると認められるところ，甲２３によれば，ＬＡＷ３テーブルにおいては，ＬＡＷ１フィールドとＣＨＫフィールドの双方に主キーが付されていることが認められ，この双方を組み合わせれば，ＬＡＷ１フィールドのレコードと，ＬＡＷ２フィールドのレコードが区別されることになるから，ＬＡＷ３テーブルの中にあるレコードを一意に特定することができるといえる。
したがって，ｎ：ｎの関係ではなく，ｎ：１の関係になるから，被告らの論理によっても，被告らの同主張は採用できない。
また，被告らは，ＰＲＯＪＥＣＴテーブル「法規制２‐１」「法規制２‐２」「法規制２‐３」各フィールドと，ＬＡＷ３テーブルのＬＡＷ１フィールドとが関連付けられているといえないと主張するが，同様の理由により採用できない。
（ウ）被告らは，原告・被告各データベースのＰＲＯＪＥＣＴテーブル「路線１」「路線２」「路線３」各フィールドとａｌｌ　ＬＩＮＥテーブルのＬＩＮＥ１フィールドとの関連付けを否定し，ｎ：ｎの関係にあるものは関連付けられているとはいえないと主張し，乙２９の４を提出する。
また，同様にａｌｌ　ＴＲＡＦテーブルのＴＲＡＦ１フィールドとａｌｌＬＩＮＥテーブルのＬＩＮＥ１フィールドとの関連付けを否定し，ｎ：ｎの関係にあるものは関連付けられているとはいえないと主張して，乙２９の５及び６を提出する。
しかしながら，ＰＲＯＪＥＣＴテーブルの「路線１」「路線２」「路線３」各フィールドとａｌｌ　ＴＲＡＦテーブルのＴＲＡＦ１フィールドとは，主キーと外部キーの関係で関連付けられている。
さらに，ａｌｌ　ＬＩＮＥテーブルのＬＩＮＥ１フィールドについては，乙２９の５によれば３桁の数字が格納されているから，７桁の数字が格納されているａｌｌ　ＴＲＡＦテーブルのＴＲＡＦ１フィールドと１：１の対応関係にないようにみえる。
しかし，ａｌｌＬＩＮＥテーブルのＬＩＮＥ１フィールドに格納されている数字は，ａｌｌ　ＴＲＡＦテーブルのＴＲＡＦ１フィールドの上３桁と一致するように構成されていることが認められ（例えば，ＬＩＮＥ１フィールドの００１はいずみ鉄道を意味し，ａｌｌ　ＴＲＡＦフィールド００１００１０は，いずみ鉄道の大原駅を意味する），ＬＩＮＥ１フィールドの３桁の数字によって路線名称をコード化し，ＴＲＡＦ１フィールドの下４桁の数字によって駅名称をコード化し，上記３桁の数字コードを介した相互の関連付けを行い，路線別物件検索機能を可能なものとしているということができる。
したがって，このような意味において各テーブル間は関連付けられているということができるから，被告らの主張は採用できない。
（エ）被告らは，原告・被告各データベースのＰＲＯＪＥＣＴテーブルの行政区分コードフィールドとＰＲＥＦテーブルのＪＣＯＤＥフィールドとの関連付けを否定し，乙２９の７及び８を提出する。
また被告らは，ＰＲＯＪＥＣＴテーブルの行政区分コードフィールドとＡＮＭテーブルのＭ９９フィールドとが関連付けを否定し，乙２９の９及び１０を提出し，さらに，ＰＲＥＦテーブルのＪＣＯＤＥフィールドとＴＯＷＮテーブルのＪＣＯＤＥフィールドとの関連付けを否定し，乙２９の１１を提出する。
しかし，ＰＲＯＪＥＣＴテーブルの行政区分コードフィールドとＴＯＷＮテーブルＪＣＯＤＥフィールドとは，主キーと外部キーが設定されていると認められるから関連付けがされている。
また，上記（ウ）と同様に，ＴＯＷＮテーブルのＪＣＯＤＥフィールドに格納された５桁の数字の上２桁が，ＰＲＥＦテーブルのＪＣＯＤＥフィールドに格納された２桁の数字と一致するように構成されている。
そして，ＴＯＷＮテーブルのＪＣＯＤＥフィールドに格納された５桁の数字のうち上２桁が都道府県名称を，下３桁が市区町村名称をコード化したもので，このようなコード化をすることによって，都道府県・市区町村別物件検索を可能にしている（例えば，ＰＲＥＦテーブルのＪＣＯＤＥ「１３」は東京を意味し，ＴＯＷＮテーブルのＪＣＯＤＥ「１３１０１」は東京都千代田区を，「１３１０２」は東京都中央区をそれぞれ意味する。）。
また，ＡＮＭテーブルのＭ９９フィールドとＴＯＷＮテーブルのＪＣＯＤＥフィールドは，そもそもｎ対１の関係が成立している。したがって，被告らの主張は採用できない。
２争点
（１）原告データベースが著作権法にいうデータベースの著作物に該当するか（争点１）
（２）被告データベースが原告データベースの複製であり，その著作権を侵害しているか（争点２）
ア被告データベースが原告データベースに依拠して作成されたものか（争点２（１））
イ原告データベースのうち被告データベースと共通する情報及び構成が，著作物性を認めるに足りる創作性を有するか（争点２（２））
３争点に関する当事者の主張
（１）争点１（原告データベースが著作権法にいうデータベースの著作物に該当するか）
【原告の主張】
原告データベースにおける情報分類項目等の選択及び体系的構成は，同業他社のデータベースのそれとは大きく異なっており，そのいずれにも創作性が認められるから，原告データベースは著作権法１２条の２にいうデータベースの著作物に該当する。
データベースの創作性とは，ユーザーにどのような使い勝手のデータベースを提供するかを構想した上，（）どういうテーブルをいくつ作るか，（）各テーブルにどのようなフィールド項目を振り分けるか，（）それらのテーブル間にどのような関連付けを行うか，を総合考慮して判断されるべきである。
そして，生の情報として，新聞・パンフレットなどから何を採り上げ，相互にどのように関連付けるかによって，千差万別のデータベースが作成される。
ア情報項目等の選択の創作性
原告データベースには，情報の選択，情報項目の設定，テーブル構成，リレーションの張り方，テーブル間の関連付けのいずれの段階にも，制作者の独自性が認められる。
このことは，不動産経済調査月報（乙１；以下「不動産月報」という。）や同業他社のデータベースの情報項目と比較しても明らかである。
例えば，同業他社であるＭＲＣ社のデータベースのタイプテーブルと比較すると，ＭＲＣ社のデータベースのテーブルは「Ｍ＿部屋タイプ」であり，その「タイプ名」は「１Ｒ・１Ｋ・１ＤＫ・１ＬＤＫ・２Ｋ・２ＤＫ・２ＬＤＫ・３Ｋ・３ＤＫ・３ＬＤＫ・４ＤＫ・４ＬＤＫ・５ＤＫ」のように，一般的な部屋タイプが入力されている（甲２８）。
これに対し，原告データベースのタイプテーブルの「タイプネーム」には，「フリー
ＤＩＯ・１ＬＬＤＫ・１ＳＫ・１ＳＬＤＫ・１ＳＳＫ・１ＳＳＬＤＫ（以下略すが，合計９２もの部屋タイプを有している。）」のように，通常使われることのない用語による分類がされている（甲１４）。
被告らは，原告データベースのフィールド項目のうち，集計項目を除く項目のほとんどは，不動産月報等の他の媒体に記載されているから，同項目の設定については何らの創作性も認められないと主張し，その証拠として乙２を提出する。
しかしながら，以下に述べるとおり，被告らの主張は，原告データベースのフィールド項目と不動産月報等の他の媒体の記載との比較を正確に行っているとはいえないものである。
（ア）広告・パンフレットとの比較対照について
データベースの構築に際し，一定の情報媒体から情報を獲得することは不可避である。
原告データベースにおいても，ヒアリング以外では広告・パンフレットを素材にしており，原告データベースにその情報が記載されていることは当然である。
甲９１２の３をみると，原告データベースの構築に際しすべてのデータが取り込まれているのではなく，データベースに取り込むべき情報が選択されていることが分かる。
そもそも，広告・パンフレットとして使用することを目的として選択されたデータと，データベース構築のために使用することを目的として選択されるデータとは，情報の位相を異にするものである。
しかるに，被告らが行っているような原告データベースのフィールド項目と広告・パンフレットとの比較は，このような点に考慮することなく，単純な項目の有無を比較しているにすぎないから，無意味である。
（イ）「不動産の表示に関する公正競争規約」（１２．７．７公正取引委員会告示第１４号；乙３３）との比較対照について
被告らは，乙２において，原告のフィールド項目と「不動産の表示に関する公正競争規約」（以下，「公正競争規約」という。）に記載されている項目とを比較し，原告データベースのフィールド項目が公正競争規約から導き出されていると主張するが，公正競争規約のどこから，本件データベースの情報項目のどの項目が導かれるのか，具体的なところが明らかでない。
（ウ）不動産月報の情報項目との比較について
被告らは，乙２において，本件データベースの情報項目と同様の情報項目が不動産月報等の他の媒体にも存在すると指摘するが，以下のとおり誤りである。
（ａ）「物件名ＭＡＩＮ」
被告らは，乙２において，原告データベースのフィールド項目「物件名ＭＡＩＮ」に関し，不動産月報の項目に○を付し，同じ項目が不動産月報にも存在すると主張する。
この点，原告データベースでは，ＰＲＯＪＥＣＴテーブルに「物件名ＭＡＩＮ」，詳細テーブルに「物件名ＳＵＢ」というフィールド項目が設定されており，両者はその機能が明確に区別されている。
すなわち，「物件名ＭＡＩＮ」フィールドには，マンション全体の情報を集計した通期のデータが納められているのに対し，「物件名ＳＵＢ」フィールドには，販売期分けごとのデータが納められており，物件名に何期という情報が付け加わっている。
このように，通期と期分けごとのデータとで情報項目を異ならせることにより，原告データベースは，販売状況を多角的に提供できるものとなっている。
これに対し，不動産月報の物件名は，「コスモ浦和グレイスアベニュー１期」のように，期分けのデータが記載されている。
つまり，不動産月報には，期分けごとのデータ項目（「物件名ＳＵＢ」のデータ）は存在するものの，本件データベースにあるような通期のデータ項目（「物件名ＭＡＩＮ」のデータ）は存在しない。
したがって，被告らの主張のように，不動産月報に「物件名ＭＡＩＮ」と「物件名ＳＵＢ」の双方に該当する項目があるとするのは誤りである。
（ｂ）「種別コード」
被告らは，乙２において，原告データベースのフィールド項目である「種別コード」が不動産月報にも存在すると指摘する。
しかるに，原告データベースにおいて種別コードを設けている理由は，１「一般分譲」，７「シルバー用途マンション」，８「定期借地権付マンション」というように物件の使用用途を明らかにするところにある。
これに対し，不動産月報記載の「土地権利」との記載は，分譲・所有権分譲・借地権分譲など土地（敷地）に対する権利形態を示すものであって，原告データベースのフィールド項目である「種別コード」とはその趣旨が全く異なっている。
（ｃ）「物件所在地」
被告らは，乙２において，原告データベースのフィールド項目「国内分類コード，行政区分コード，町丁名手入力，地番，住居表示」と同一の項目が不動産月報にも存在すると指摘する。
しかし，原告データベースのフィールド項目は以下のような趣旨で設けられている。
すなわち，「行政区分コード」フィールドは，正数値で与えられており，これが，大量のデータをより早く処理することを可能にする。
また，「町丁名入力」フィールドは，町丁名検索を行うことを可能にするために作成され，町丁名の記入ミスを防ぐことができる。
さらに，「国内分類コード」フィールドは，全国を９のエリアに分けた分類項目であり，原告データベースの関東版・中部版を作成する時に，データの切り出しを行うことができる。
このように，それぞれ独自の機能を持ったフィールド項目は，不動産月報には見られない。
特に，「国内分類コード」は，前記のように，全国的な規模で情報提供をするための機能であり，関東地域限定でまとめられている不動産月報にはその記載がないはずのものである。
（ｄ）「交通」
被告らは，乙２において，本件データベースのＰＲＯＪＥＣＴテーブルの情報項目のうち，「路線１，路線手入力１，徒歩１，バス１，車１，路線２，路線手入力２，徒歩２，バス２，車２，路線３，路線手入力３，徒歩３，車３」の各項目に該当するものが，不動産月報にも存在すると指摘している。
しかし，不動産月報（乙１）の記載事項を見れば分かるとおり，調査月報にあるのは，「交通」という項目のみであって，本件データベースの項目のように，「路線，徒歩，バス，車」といった交通手段による情報の区分けはされておらず，任意の一つの交通手段を記載できるのみである。
それに対し，原告データベースでは，利用可能な交通手段を可能な限り捕捉するべく，各交通手段別に，また，さらに同じ交通手段についても１から３と分類して情報分類項目を設定しているのである。
原告データベースが，このように多数の情報分類を行っているのは，不動産月報が目的とした最寄り駅までの交通状況を示すことにとどまらず，駅別集計や路線検索，最寄り駅以外にアクセス可能な駅検索等を可能にすることをも目的としたからである。
このように，原告データベースの情報項目の設定と不動産月報の情報項目の設定は，その目的・機能の点で大いに異なっており，両者は決して同一ではない。
これを一緒にしてしまう比較は誤りである。
（ｅ）「法規制コード」
被告らは，乙２において，本件データベースの情報分類項目「法規制１‐１，法規制１‐２，法規制１‐３，法規制２‐１，法規制２‐２，法規制２‐３」と同一の項目が不動産月報にも存在すると指摘する。
しかし，不動産月報（乙１）の「法規制」の項目に「準工業」とあるように，調査月報に記載される情報が都市計画法上の用途地域区分のみであるのに対し，原告データベースの「法規制１‐１，法規制１‐２，法規制１‐３」は都市計画法上の用途地域区分，「法規制２‐１，法規制２‐２，法規制２‐３」は，「その他の法令による地域区分」，例えば，都市計画法上の防火区域や高度地区，自然公園法上の規制区域に関する情報項目であり，不動産月報に比較してより多くの情報項目の設定をしていることは明らかであり，共通する部分があるからといって，同一の項目があると評価することはできない。
（ｆ）「駐車場」
被告らは，乙２において，本件データベースの「駐車場合計台数，賃貸駐車場（敷地内），賃貸駐車場（敷地外），分譲駐車場台数，賃貸駐車場金額ＭＩＮ（敷地内），賃貸駐車場金額ＭＡＸ（敷地内），賃貸駐車場金額ＭＩＮ（敷地外），賃貸駐車場金額ＭＡＸ（敷地外），分譲駐車場金額ＭＩＮ，分譲駐車場金額ＭＡＸ」と同一の項目が不動産月報に存在するとしている。
しかし，不動産月報（乙１）の「駐車場」という項目に記載されている事実は，台数，最低賃貸額，最高賃貸額にすぎず，そこには，原告データベースの情報分類項目にある「賃貸か分譲か」，「敷地内か敷地外か」といった情報は盛り込まれていない。
原告データベースは，情報の細分化をはかることで，賃貸駐車場に関する多角的な情報を獲得できるようにすることを目的としていたためにこのような情報分類項目を設けたのある。
このように，駐車場に関する原告データベースの情報分類項目と不動産月報のそれは，到底同一のものとは評価できない。
（ｇ）「事業主名・販売提携・設計・施工」
被告らは，乙２において，本件データベースの「事業主１ないし事業主５，販売会社１ないし３，設計１及び２，施工１及び２」に該当する項目が調査月報に存在すると指摘する。
たしかに，不動産月報（乙１）には，事業主名・販売会社・設計・施工の各項目は存在している。
しかし，本件データベースの情報分類項目は，「事業主，販売会社，設計，施工」の情報をさらに細分化して，１ないし５若しくは１ないし３又は１及び２の番号を付している。
これは，大規模な分譲マンション等の開発の際に，複数の事業者が共同事業を行うことが一般的であり，その場合に１社のみ採り上げたのでは事業の実態を正確に把握できないことから，原告データベースでは，正確に把握できるよう事業者・販売者・設計・施工の情報を細分化して情報項目を設定したものである。
したがって，原告データベースの情報項目と不動産月報のそれとは，上記のように内実は大きく異なる。
（ｈ）「即日完売」・「即完最高倍率」・「即完平均倍率」
被告らは，詳細テーブルの「即日完売」・「即完最高倍率」・「即完平均倍率」と同様の項目が，不動産月報にも存在すると指摘する。
ここで，「即日完売」とは，予告販売時期に見込み客などの集客を行い，一週間ほどの登録期間を設けた後の登録期間満了日を正式な販売開始日とした場合に，その開始日においてすべての住戸に申込みが入っていることをいう。
そして，「即完最高倍率」とは，一つの住戸に対する申込みのうち，即日完売時における最高倍率のことを，「即完平均倍率」とは，各住戸の倍率の平均値をいう。
他方，不動産月報（乙１）においては，即日完売という欄があるのみであり，同月報において，「即完最高倍率」，「即完平均倍率」なる欄は全く見当たらない。
せいぜい，即日完売の欄に記載することができるという意味しかなく，両者を同一のものとして扱うのは不当な比較というほかない。
（エ）ＭＲＣ社のデータベースの情報項目との比較
原告データベースの情報分類項目の創作性は，以下のように，同業他社（ＭＲＣ社）のデータベースの情報項目と比較しても明らかである（甲１８）。
（ａ）「物件名ＭＡＩＮ」
物件名に関しては，ＭＲＣ社のデータベースの情報分類項目は不動産月報のそれと類似している。
すなわち，甲１７に「パークハウス馬込台第１期」とあるとおり期分けごとの情報のみである。
（ｂ）「物件所在地」
この点も，不動産月報と同様，所在地なるフィールド項目１つがあるのみで，原告データベースのように情報分類が細分化されていない。
（ｃ）「交通」
ＭＲＣ社のデータベースは，「交通」・「最寄り駅」・「徒歩」・「バス」の４つの情報分類項目を持っているが，最寄り駅までの交通状況を明らかにするにとどまるところが原告データベースとは大きく異なる。
（ｄ）「法規制コード」
ＭＲＣ社のデータベースは，都市計画法上の用途地域についての情報分類は行っているが，原告データベースのようにそれ以外の法令上の規制については何ら項目が設けられていない。
（ｅ）「駐車場」
ＭＲＣ社のデータベースは，賃貸と分譲の駐車場の数を示すのみであり，原告データベースように多角的な情報分類はされていない。
（ｆ）「事業者・販売提携・設計・施工」
ＭＲＣ社のデータベースは，事業者のフィールド項目は１つしか存在していない。
このため，共同事業者がある場合に，正確な共同事業の実態を捕捉できない点で，原告データベースと大きく異なる。
（ｇ）「即日完売」・「即完最高倍率」・「即完平均倍率」
ＭＲＣ社のデータベースは，「状態」というフィールド項目に「完売か売り出し中か」が記載されるのみであり，原告データベースのように倍率に関する情報分類項目は設けられていない。
（オ）以上とは逆に，不動産月報又はＭＲＣ社のデータベースには存在するが，原告データベースには存在しない情報項目がある。
例えば，不動産月報には，「エレベーター，土地権利証，確認番号，距離，冷暖房，給湯，商品企画」などの項目があるが，それに対応する情報項目は，原告データベースには存在しない。
また，ＭＲＣ社のデータベースの項目には，「エレベーター，主開口方位，借地料」及び「初月売，当月売，累計売」の各項目があるが，それに対応する情報項目は，原告データベースには存在しない。
（カ）集計フィールド項目について
集計フィールド項目とは，リレーションの働きにより，他のコンテンツフィールド項目に何らかの計算値を与えて指標値などに加工した情報を格納しておくフィールド項目であるところ，集計フィールド項目がこのようなプロセスを経たものである以上，本来人が別途計算したうえで記載するというプロセスを経る不動産月報の項目と単純に比較すべきものではない。
被告らは，乙３において，集計フィールド項目について，原告データベースとＭＲＣ社のデータベース等とを比較することで，原告データベースの集計項目について，集計項目のうちの多くが同業他社の間で広く用いられているものであり，集計項目の設定自体も原告独自の工夫といえる程のものではなく，業界一般の常識もしくは極めて単純な作業によるものにすぎないと主張する。
しかし，ＭＲＣ社のデータベースの集計項目と原告データベースのそれとが一致するのは，６項目（「分譲総金額」・「分譲総面積」・「平均価格」・「返金面積」・「初月売戸数」・「初月売率」）のみで，原告データベースは，その他７７の集計フィールド項目を有している。
このように，原告データベースにおける集計フィールド項目の情報項目設定数は他のデータベースのそれをはるかにしのぐもので，情報項目の設定に原告独自の個性が表出されていることは明白である。
イ体系的構成の創作性
原告データベースの体系的構成は，ＰＲＯＪＥＣＴテーブル，詳細テーブルを初めとする各テーブルのフィールド項目として数百の項目を設定（つまり，情報収集の方針を決定）した上，多数のエントリーテーブル及びマスターテーブルの作成・データ形式の決定・多数のテーブルの関連付けをしているものであって，この点に，原告データベースの体系的構成の創作性が認められる。
このことは，同業他社のＭＲＣ社のデータベースが原告データベースに比べて明らかに単純な構成しかとっていないことからしても，明らかである。
被告らは，原告データベースの体系的構成は，「アクセス」を用いたデータベース構築の手順に従えばだれでもできるものであるから，創作性がないと主張する。
しかし，「アクセス」を用いた作成手順に従えば当然に原告データベースの体系的構成になるものではなく，情報集積や情報検索の便を考慮した作成者の独自のコンセプトがあって初めて，個別的なデータベースが実現する。
被告らの主張を前提とすれば，「アクセス」を用いて作成される同一目的のデータベースはすべて体系的構成において同じものになるはずであるが，失当である。
ウ上記のとおり，原告データベースには高度の創作性が認められるが，本件のようなデッドコピーの事案では，仮に創作性が低いとしても著作権侵害が認められる。
このことは，平成１０年（ネ）第３６７６号同１２年１１月３０日東京高裁判決及びデータベースの著作物に関する昭和６１年の著作権法改正のための文化庁著作権審議会第７委員会報告書（昭和６０年９月），斎藤博「著作権法」１０１ページの記述等からも裏付けられる。
エ被告らは，原告データベースは，マンション開発業者の業界において当然関心の対象になる事柄について，「アクセス」を用いてリレーショナルデータベースを構築したにすぎないから，創作性がないと主張するが，失当である。
また被告らは，原告データベースにリレーション（関連付け）が張られていることを否定するが，被告らの主張は，以下の点から，失当であることが明らかである。
（ア）法規制テーブルについて
元来，原告データベースでは，法規制テーブルのうち，用途地域に関するものを法規制１テーブルとし，それ以外の法規制を法規制２テーブルとしていた（甲１７の６頁２．１．５）。
しかるところ，株式会社デジタルウェアは，法規制１テーブルと法規制２テーブルを合体させたＬＡＷ３テーブルを作った（甲１４の「ＬＡＷ３テーブル」を参照）。
この場合，ＬＡＷ３テーブルのＬＡＷ１フィールドは，ＩＤ（００とか０１とか）が重複して法規制１テーブルのＩＤと法規制２テーブルのＩＤが判別できなくなる。
被告らが，ＬＡＷ３テーブルのＬＡＷ１フィールドをみると，ＬＡＷ１フィールドには，同一のデータが２個ずつ入力されている部分があると主張するのは，この状態を指している。
しかしながら，１つのフィールドだけではレコードを特定できない場合，複数のフィールド項目を組み合わせて主キーにすることができる（甲２２）。
そこで，まず前記ＬＡＷ３テーブルに３つ目のフィールド項目ＣＨＫを設け，法規制１には１という数字を，法規制２には２という数字を付した。
その上で，ＬＡＷ１フィールドとＣＨＫフィールドの双方に主キーを設定した。
原告データベースのＬＡＷ３テーブルのデザインビューを画面キャプチャーした図（甲２３の左の図）をみると，その最も左の欄の１行目（ＬＡＷ１１フィールド）と３行目（ＣＨＫフィールド）の両方に主キーのマークが付されている。
検甲１に格納した被告データベースの対応画面も全く同様の処理が維持されている（甲２３の右の図）。
このように，ＬＡＷ１フィールドとＣＨＫフィールドを組み合わせれば，法規制１および２の各レコードが区別されることになる。
したがって，ＬＡＷ３テーブルの中にあるレコードを一意に特定することができるから，「ｎ：ｎ」となるわけではなく，「ｎ：１」の関係となるのであり，関連付けが存在する。
法規制２テーブルについても，同様の理由で，関連付けが存在する。
（イ）ＰＲＯＪＥＣＴテーブル・ａｌｌ　ＬＩＮＥテーブル・ａｌｌ　ＴＲＡＦテーブルの関連について被告らは，原告データベースに存在する上記各テーブル間のリレーションを否定するが，以下述べるとおり「関連付け」が存在する。
まず，ＰＲＯＪＥＣＴテーブルとａｌｌ　ＴＲＡＦテーブルは，ＰＲＯＪＥＣＴテーブルの「路線１」フィールドとａｌｌ　ＴＲＡＦテーブルの「ＴＲＡＦ１」フィールドが主キーと外部キーの関係で関連付けられている。
他方，ａｌｌ　ＬＩＮＥテーブルの「ＬＩＮＥ１」フィールドは，被告らが指摘するように，３桁の数字が格納されており（乙第２９号証の５），一見すると，７桁の数字が格納されているａｌｌ　ＴＲＡＦテーブルの「ＴＲＡＦ１」フィールドとは１：１の対応関係にないが，「ＬＩＮＥ１」フィールドに格納されている数字は，ａｌｌＴＲＡＦテーブルの「ＴＲＡＦ１」フィールドの上３桁と一致するように構成されている。
例えば，ＬＩＮＥ１フィールドの００１はいずみ鉄道を意味し，ａｌｌ　ＴＲＡＦフィールド００１００１０は，いずみ鉄道の大原駅を意味する。
このように，ＬＩＮＥ１フィールドに格納されている３桁の数字は，路線名称をコード化したものであり，ＴＲＡＦ１フィールドの下４桁は駅名称をコード化したものである。
路線名称と駅名称に各々このようなコードを与えたうえ，上記３桁の数字コードを介した相互の関連付けを行い，路線別物件検索機能を可能なものとしているのである。
この関連付けにより，本件データベースのユーザーが路線別物件検索機能を操作する際，ａｌｌ　ＬＩＮＥテーブルのＬＩＮＥ１フィールドに格納されている路線名称がダイアログボックス内に表示されることになる。
以上のとおり，ａｌｌ　ＬＩＮＥテーブルと，ａｌｌ　ＴＲＡＦテーブルとは上記のような関連付けがされており，本件データベースの構造上，他のテーブルと関連付けられている。
（ウ）ＰＲＯＪＥＣＴテーブル・ＰＲＥＦテーブル・ＡＮＭテーブル・ＴＯＷＮテーブルの関連について
（ａ）被告らは，上記各テーブルの関連についても，主キーと外部キーに基づく関連付けができないことを根拠として関連付けを否認するが，この点も前記のａｌｌＬＩＮＥテーブル，ａｌｌ　ＴＲＡＦテーブルについて述べたのと同様に，被告らの主張は失当である。
主キーと外部キーに基づく関連付けがされているのは，ＰＲＯＪＥＣＴテーブルの「行政区分コード」フィールドとＴＯＷＮテーブルの「ＪＣＯＤＥ」フィールドである。
他方，ＰＲＥＦテーブルとＡＮＭテーブルが無関係という訳ではない。
ＰＲＥＦテーブルは第１において述べたａｌｌ　ＬＩＮＥテーブルと同じように，ＴＯＷＮテーブルの「ＪＣＯＤＥ」フィールドに格納された５桁の数字の上２桁は，ＰＲＥＦテーブルの「ＪＣＯＤＥ」フィールドに格納された２桁の数字と一致するように構成されている。
そして，ＴＯＷＮテーブルの「ＪＣＯＤＥ」フィールドに格納された５桁の数字のうち上２桁が都道府県の名称を，下３桁が市区町村の名称をコード化したものであり，このようなコード化をすることによって，都道府県・市区町村別物件検索を可能にしている。
例えば，ＰＲＥＦテーブルのＪＣＯＤＥ「１３」は東京を意味し，ＴＯＷＮテーブルのＪＣＯＤＥ「１３１０１」は東京都千代田区を，「１３１０２」は東京都中央区をそれぞれ意味する。
このような関連付けにより，原告データベースのユーザーが本件都道府県・市区町村別物件検索機能を操作する際，都道府県のダイアログボックスである都道府県を選択すると，市区町村ダイアログボックスにＴＯＷＮテーブル内に格納されている市区町村名が表示されるようになっているのである。
以上のとおり，ＰＲＥＦテーブルは，ＴＯＷＮテーブルと関連付けがされており，原告データベースの構造上，他のテーブルと関連付けられている。
（ｂ）ＡＮＭテーブルのＭ９９フィールドとＴＯＷＮテーブルのＪＣＯＤＥフィールドも，ｎ対１の関係が成立しており，関連付けがされている。
【被告らの主張】
原告データベースは，情報項目の選択，体系の設定のいずれの点からしても，著作物性を認めるに足りる創作性を有しないから，著作権法にいうデータベースの著作物に該当しない。
ア情報項目の選択の創作性について
情報の選択に関する創作性とは，情報を選択する基準，すなわちフィールドとしていかなる情報分類項目を設定したのかという点から判断すべきであるが，この点，原告データベースの情報の選択には創作性はない。
すなわち，データベースの作成においては，データベースの使用目的に照らして実世界の情報源から必要な情報を選択し，情報項目として設定する。
したがって，データベースの使用目的が同一であれば，情報項目はほとんど一致するのであるから，単純に情報源から必要な情報を選択してそれを情報項目として設定したからといって，それだけで直ちに情報項目の設定に創作性が付与されるものではない。
そもそも原告・被告各データベースの情報源は，新聞，雑誌広告，パンフレットなどであるが，これらの情報源に記載される事項は，不動産の表示に関する公正競争規約（乙３３）によりその大枠が規定されているため，その内容はほとんど変わらないから，これら情報源から収集される情報は，開発するデータベースの使用目的が同一であれば，量的に多い少ないの違いはあっても，ほとんど同一になる。
また，原告データベースの情報分類項目のうち，集計項目を除く部分のほとんどは，不動産経済調査月報（乙１），東京カンテイのデータベースの帳票見本（乙３４）等の媒体に記載されている情報分類項目をそのまま設定しているにすぎない。
原告データベースを同業他社であるＭＲＣ社のデータベースと比較してみても，原告データベースに存在しないＤ＿ＭＥＮテーブルとＭＲＣ社のデータベースに存在しない広告テーブルを除けば，ＭＲＣ社のデータベースの情報項目のほとんどは，原告データベースの情報項目に含まれている。
イ原告は，原告データベースの情報項目の選択について創作性があると主張するが，以下のとおり失当である。
（ａ）「物件名ＭＡＩＮ」
原告は，期別販売の物件名について，例えば「ライオンズガーデン横濱寺尾オークステージ１期」を，純粋な物件名である「ライオンズガーデン横濱寺尾オークステージ」と販売期である「１期」とを別個の情報項目として設定したことをもって，情報項目選定に創作性があると主張するが，性質の異なる２つの情報を２つの情報項目に設定することは，データベース作成の基本的な考え方であり，著作物性を認めるに足りるほどの創作性を有するものではない。
（ｂ）「種別コード」
原告は，「種別コード」に関し，シルバー用途マンションという使用用途の情報と，一般所有権分譲，定期借地権という敷地に対する権利形態の情報とを，同じ「種別コード」として情報項目の設定をしていることに，原告データベースの独自性があり，創作性が認められると主張するが，マンションの使用用途と敷地に対する権利形態という視点の異なる情報を，同一の「種別コード」という情報項目に格納するということは，単に便宜的な分類に過ぎず，言い換えれば分類をしていないのと同じであるから，このようなものに著作物性を認めることはできない（また，そもそも被告データベースでは，この分類は使用されていない。）。
（ｃ）「物件所在地」
同業他社である株式会社東京カンテイのデータベースの帳票見本（乙３４）をみると，地番という情報項目と，住居表示を表す所在地という情報項目とがすでに存在するから，分類分けに創作性はない。
（ｄ）「交通」
原告は，原告データベースでは交通に関し複数の項目が設定されているし，３つもの情報項目を設定しているところに創作性があると主張するが，不動産公正競争規約（乙３３）によれば，広告，パンフレット等における「交通」の記載方法は，同規約に既に定められているのであって，それらの「交通」の記載から，３つの情報項目を設定することに，著作物性を認めるに足りるほどの創作性があるとは考えられない。
同業他社である東京カンテイのデータベースの帳票見本（乙３４）をみても，「最寄駅１」「最寄駅２」として２つの項目が記載されている。
（ｅ）「法規制コード」
原告は，不動産月報は，用途地域以外の法規制を採り上げていないと主張するが，誤りである。
不動産月報には，用途地域以外の法規制も記載されている（乙１０）。
また，原告は，ＭＲＣ社のデータベースでは用途地域以外の法規制は採り上げられていないと主張し，「法規制１」「法規制２」「法規制３」のフィールドの設定に原告の独自性が認められると主張し，また，ＭＲＣ社のデータベースでは用途地域として１フィールドしか入れられないのに対し，原告データベースでは３フィールドまで入れられると主張して，原告データベースの法規制フィールドには創作性が認められると主張する。
しかし，マンション建設において，複数の用途地域及び複数の法令上の制限地域にわたって建設されることは多々あり，情報源である広告，パンフレットには，これら複数の法規制が記載されている。
これらの有限である組み合わせについて，用途地域と用途地域以外の法令上の制限に分け，各項目につき３つのフィールドを設定しただけで，著作物性を肯定するに足りるほどの創作性が認められるとは考えられない。
（ｆ）「駐車場」
同業他社である株式会社東京カンテイのデータベースの帳票見本（乙３４）をみると，「駐車場」として，（敷地内），（敷地外）合計，「駐車料金」「分譲駐車場」との項目ないし記載がすでに存在するから，原告データベースの分類分けに創作性はない。
（ｇ）「事業主名・販売提携・設計・施工」
原告は，５つの「事業主」，３つの「販売会社」，２つの「設計者・施工者」と情報項目を定めたことに創作性が認められると主張するが，新築分譲マンションの事業主（売主）等の数は，多くて８社くらいであり，この中から５つ，３つ，２つを選んだからといって大きな意味はない。
加えて，同業他社である株式会社東京カンテイのデータベースの帳票見本（乙３４）をみると，３つの売主（事業主）「売主１３」，１つの「販売代理」，２つの施工「施工１，２」の項目がすでに存在する。
（ｈ）「即日完売」・「即完最高倍率」・「即完平均倍率」
原告は，「即日完売」・「即完最高倍率」・「即完平均倍率」の項目のうち，不動産月報には「即日完売」の項目しか存在しないと主張するが，誤りである。
不動産月報にも，「即完最高倍率」「即完平均倍率」の記載がある。
これらの項目は，ヒヤリング情報に基づく集計値であり，「即完最高倍率」などの集計に当たって簡単に割り出せるものであるから，原告が主張する「即完最低倍率」の情報項目を加えて設定したからといって，その項目設定に著作物性を有するほどの創作性は認められない。
（ｉ）集計フィールド項目について
集計項目フィールド項目については，パンフレット，新聞広告，雑誌広告，お知らせ看板等から入手した数値に計算を施して得られた結果を１つの項目として設定するものであるが，原告データベースで用いられている集計項目のうち多くは同業他社の間で広く用いられているし（乙３），原告データベースのみで用いられている集計項目についても，単純な合計値，平均値，最大値，最小値を１つの項目にしたものにすぎない。
したがって，同集計項目の設定自体も原告独自の工夫といえるほどのものではなく，業界一般の常識又は極めて単純な作業によるものであって，原告のフィールド項目の設定に創作性は認められない。
ウ体系の設定に関する創作性について
（ア）原告は，原告データベースの作成過程において，多数のフィールド項目，テーブルを設定し，データ形式も決定した上でテーブル間のリレーション付けを行い，エントリーなどのためにクエリーを作成していることをもって，体系の設定に創作性があると主張するが，原告の同主張は，単に「アクセス」を用いてリレーショナルデータベースを構築したことを述べるにすぎない。
（イ）被告データベースの設計について
被告データベースの設計をみても，被告データベースのテーブル構成及び関連付けは，データベースの基本的な考え方に基づいて作成されたものにすぎないから，これに対応する原告データベースの部分に創作性があるということはできない。
（ａ）データベースを設計する場合，次の手順に従って設計するのが通常である。
すなわち，まず１データベースの利用目的を決定し，２テーブルを決定し，３フィールド項目を決定し，４テーブル間のリレーションを決定する。
被告データベースは，以上の手順に従って設計されている。
そして，被告データベースの利用目的は，主として，マンション建築販売業者による新築マンション建築予定地周辺の建築販売情報の収集にある。
そして，被告データベースの場合，情報を収集する情報源は，主に１お知らせ看板，２不動産広告（週刊住宅情報を含む），３購入者向けパンフレット，４ヒヤリング情報等であり，このような情報源から，新築マンションのエリアマーケティングに必要な最低限の情報を収集したのが，被告データベースである。
（ｂ）テーブルの決定
テーブルの決定は，収集した情報をその性質に合わせて分類し，その分類に基づいて決定する。
被告データベースの収集した情報をその性質に基づき分類すると，次の７つに分類される。
それは，建物立地，販売，部屋，広告履歴，申込履歴，タイプ別集計値，価格帯別集計値の７つであり，それぞれの分類ごとに複数の情報項目が含まれてくる。
そして，被告データベースは，このように分類された情報分類をそのまま，「ＰＲＯＪＥＣＴ」「詳細」「住戸一般」「広告」「申込」「月報タイプ」「月報価格」としてテーブル化したものにすぎない。
（ｃ）テーブル間の関連
このようにして設定されたテーブル間の関係は，各テーブルに格納されるデータの性質により，おのずから決定される。
被告データベースのテーブル構成及び関連付けは，以下のとおり，データベース構築の基本的な考え方に基づいて作成されたものにすぎず，この部分に対応する原告データベースについて，原告が主張するような著作物性を認めるに足りるほどの創作性はない。
１ＰＲＯＪＥＣＴテーブルと詳細テーブルとの関係
ＰＲＯＪＥＣＴテーブルには，新築マンションの建物全体のデータが格納され，詳細テーブルには，販売に関するデータが格納される。
例えば，「ライオンズガーデン横濱寺尾オークステージ１期」という物件名のうち，物件名である「ライオンズガーデン横濱寺尾オークステージ」の部分，すなわち，販売期によって変動することのない建物全体の名称のデータは，ＰＲＯＣＥＣＴテーブルに格納される。
これに対して，「１期」という販売期のデータ部分は，販売に関する情報であるとともに，将来的に「２期」「３期」と変動する要素をもったデータであるので，詳細テーブルに格納される。
このように，性質の異なるデータ及び変動要素を持つデータと変動要素を持たないデータとを分離し，別個のテーブルに帰属させるという考え方は，データベース構築の基本的な考え方である。
原告は，原告データベースがＰＲＯＪＥＣＴテーブルと詳細テーブルに分けてデータを格納することにつき創作性があると主張するが，上述したとおり，被告データベースにおいてＰＲＯＪＥＣＴテーブルと詳細テーブルに分けた理由は，格納するデータの性質及び変動要素を基準としているのであって，このようなテーブル設定に，著作物性を認めるに足りるほどの創作性は存在しない。
また，上述したとおり，ＰＲＯＪＥＣＴテーブルには，建物全体に関するデータが格納され，詳細テーブルには，販売に関するデータが格納されるところ，販売は，ある建物の販売であるから，詳細テーブルはＰＲＯＪＥＣＴテーブルに従属した関係に立つ。
したがって，両テーブル間の関連付けは，ＰＲＯＪＥＣＴテーブルに主キーを設定し，詳細テーブルに外部キーを設定する関連付け以外にない。
２詳細テーブルと住戸一般テーブルとの関係
詳細テーブルには，販売に関するデータが格納され，住戸一般テーブルには，個々の部屋に関するデータが格納される。
１つの販売に対して複数の部屋が販売されるから，販売される部屋データは変動要素を有している。
したがって，これらのデータは，別個のテーブルに格納するのがデータベース構築の基本的な考え方に合致する。
そして，両テーブルの関係は，１つの販売に対して複数の部屋が販売されるのであるから，住戸一般テーブルは，詳細テーブルに従属する関係に立つ。
したがって，両テーブルの関連付けは，詳細テーブルに主キーを設定し，住戸一般テーブルに外部キーを設定するしかない。
３詳細テーブルと広告テーブルの関係
詳細テーブルには，販売に関するデータが格納され，広告テーブルには，個々の販売に対する広告履歴データが格納される。
１つの販売に対して複数の広告が出稿されるので，出稿される広告履歴データは変動要素を有している。
したがって，これらのデータは別個のテーブルに格納するのがデータベース構築の基本的な考え方に合致する。
そして，両テーブルの関係は，１つの販売に対して複数の広告が出稿されるのであるから，広告テーブルは詳細テーブルに従属する関係に立つ。
したがって，両テーブルの関連付けは，詳細テーブルに主キーを設定し，広告テーブルに外部キーを設定するしかない。
４詳細テーブルと申込テーブルの関係
詳細テーブルには，販売に関するデータが格納され，申込テーブルには，個々の販売に対する申込履歴データが格納される。
１つの販売に対して複数の申込がされるので，なされた申込履歴データは変動要素を有している。
したがって，これらのデータは別個のテーブルに格納するのが，データベース構築の基本的な考え方に合致する。
そして，両テーブルの関係は，１つの販売に対して複数の申込がされるのであるから，申込テーブルは詳細テーブルに従属する関係に立つ。
したがって，両テーブルの関連付けは，詳細テーブルに主キーを設定し，申込テーブルに外部キーを設定するしかない。
５詳細テーブルと月報タイプテーブルの関係
詳細テーブルには，販売に関するデータが格納され，月報タイプテーブルには，個々の販売に対する間取りごとの集計値データが格納される。
１つの販売に対して販売される部屋の間取りは複数存在するから，間取りごとの集計値データは変動要素を有している。
したがって，これらのデータは別個のテーブルに格納するのが，データベース構築の基本的な考え方に合致する。
そして，両テーブルの関係は，１つの販売に対して，販売される間取りが複数存在し，間取りごとの集計値も複数存在するから，月報タイプテーブルは詳細テーブルに従属する関係に立つ。
したがって，両テーブルの関連付けは，詳細テーブルに主キーを設定し，月報タイプテーブルに外部キーを設定するしかない。
６詳細テーブルと月報価格テーブルの関係
詳細テーブルには，販売に関するデータが格納され，月報価格テーブルには，個々の販売に対する価格帯ごとの集計値データが格納される。
１つの販売に対して販売される部屋の価格は複数存在するから，価格帯ごとの集計値データは変動要素を有している。
したがって，これらのデータは別個のテーブルに格納するのが，データベース構築の基本的な考え方に合致する。
そして，両テーブルの関係は，１つの販売に対して，販売される部屋の価格が複数存在し，価格帯ごとの集計値も複数存在するから，月報価格テーブルは詳細テーブルに従属する関係に立つ。
したがって，両テーブルの関連付けは，詳細テーブルに主キーを設定し，月報タイプテーブルに外部キーを設定するしかない。
７なお，原告データベースのＰＲＯＪＥＣＴテーブル「法規制１‐１」・「法規制１‐２」・「法規制１‐３」フィールドは，法規制コード１テーブルの「法規制コード」フィールドとは関連付けられているものの，ＬＡＷ３テーブルの「ＬＡＷ１」フィールドとは関連付けられていない。
原告データベースのＰＲＯＪＥＣＴテーブル「法規制２‐１」・「法規制２‐２」・「法規制２‐３」とＬＡＷ３テーブルの「ＬＡＷ１」フィールドとの間も，同様に関連付けられていない。
（ｄ）マスターテーブルについて
原告は，原告データベースにマスターテーブルが作成されていることをもって，原告データベースに創作性があると主張する。
しかし，マスターテーブルとは，情報項目として繰り返し使用される項目を独立したテーブルに格納するものであって，データベース構築の基本的な考え方である。
したがって，原告が主張するような，著作物性を認めるに足りるほどの創作性は存在しない。
（２）争点２（被告データベースが原告データベースの複製であり，その著作権を侵害しているか）
〔争点２（１）（被告データベースが原告データベースに依拠して作成されたものか〕【原告の主張】
被告データベースは，原告データベースのデッドコピーである。
すなわち，被告データベースは，破産会社デジタルウェアの元従業員が，破産管財人の補助者であった期間のデータも含め，原告データベースをデッドコピーして持ち出したものである。
被告データベースは，コピー隠しのため多少の変更はされているが，基本的には，原告データベースの具体的データを始め，データ項目，テーブル構成，関連付けなどその体系的構成のほとんど全部をコピーしたものである。
したがって，被告データベースは，原告データベースに依拠し，これを複製したものといえる。
この結論は，以下の各事情，すなわち具体的データのコピーの事実，フィールド項目のコピーの事実，体系的構成のコピーの事実，被告らの改ざん行為の事実から裏付けられる。
ア具体的データのコピーの事実
（ア）物件ＩＤと期分けＩＤの一致（甲２）
甲２は，各物件に付されたＩＤを原告・被告各データベースについて比較した表である。
なお，同表のデータは，被告デジタル・ピクチャーズが平成１１年１０月ころに同社ホームページで「パンフレット保有情報」として掲載していた情報である。
同表をみると，同一物件に関する被告データベースの物件ＩＤと原告データベースの期分けＩＤが完全に一致することが分かる。
例えば，被告データベースの物件ＩＤ９７１２２１０３Ａと同一の期分けＩＤが原告データベースに存在し，その両者が示す物件名は，ともに「エステスクエアふじみ野ウエストウイング第５次」である。
同様に，被告データベースの物件ＩＤ９８０１２０２１と同一の期分けＩＤが原告データベースに存在し，その両者が示す物件名は，ともに「ベルパーク湘南茅ヶ崎第３期８次アザレア館・ベゴニア館」である。
このように，被告デジタル・ピクチャーズのホームページにおける「パンフレット保有情報」の物件ＩＤ１３２件のすべてが，原告データベースの期分けＩＤと一致する。
このことは，被告らが原告データベースをデッドコピーしたのでなければあり得ない。
（イ）ＰＲＯＪＥＣＴ　ＩＤの対応（甲２６）
甲２６の１２頁は原告データベースのＰＲＯＪＥＣＴテーブルを表示した画面であり，甲２６の１３頁は被告データベースのＰＲＯＪＥＣＴテーブルを表示した画面である。
一見すると，原告データベースと被告データベースのＰＲＯＪＥＣＴ　ＩＤは全く異なっているが，実際は，被告データベースのＰＲＯＪＥＣＴ　ＩＤは，原告データベースのＰＲＯＪＥＣＴＩＤを機械的に改ざんしたものであるから，両者は実質的に同一である。
例えば，原告データベースの物件「ルネ大宮宮原」のＰＲＯＪＥＣＴＩＤは，１９９８０００３である。
これに対し，被告データベースの物件「ルネ大宮宮原」のＰＲＯＪＥＣＴ　ＩＤは３８０００３００である。
また，「ＮＩＣＥ　ＵＲＢＡＮ馬込」の原告データベースのＰＲＯＪＥＣＴ　ＩＤは１９９８０００４，同物件の被告データベースのＰＲＯＪＥＣＴ　ＩＤは３８０００４００である。
原告データベースのＰＲＯＪＥＣＴ　ＩＤの西暦部分（上４桁）から１９６０を引いた数値を上２桁にし，原告データベースのＩＤの下４桁をそれに続けて，その後に００を付けるという操作を施すと，被告データベースのＰＲＯＪＥＣＴ　ＩＤと一致する。
このように，被告データベースの物件を昇順に並べ替えると，ＰＲＯＪＥＣＴ　ＩＤと物件の並び方が原告データベースの物件と完全に一致する。
このことは，被告データベースが原告データベースを機械的にコピーした事実を示している。
（ウ）登録日の一致（甲２６の１６頁以下）
甲２６の１６頁は，原告データベースと被告データベースの法規制コード１テーブルを並べて表示した画面である。
これをみると，原告データベースの法規制コード１テーブルの各法規制コードと，被告データベースの同名テーブルの各法規制コードとの間において，同名のデータの登録日が秒単位に至るまで完全に一致している。
例えば，原告データベースの法規制コード１テーブルにおける法規制コードＡ０「１種低層住専」の登録日は，９７／０２／２８９：３０：４３であるが，被告データベースの同名のテーブルの法規制コードＡ０「１種低層住専」の登録日は，これと秒単位まで完全に一致している。
このことは，被告データベースが原告データベースをデッドコピーしたものであることを示す。
また，被告らは，平成１１年（１９９９年）３月２０日以降に被告データベースの構築を開始したと主張するが，これは，被告データベースの中に９７／０２／２８というそれ以前に入力したデータが存在する事実と矛盾する。
（エ）申込率のデータの一致（甲１の１３及び甲２７）
申込率に記載されるデータは，独自に訪問及び電話調査によって得られたマンションの売れ行き状況を把握するための数値であり，訪問先，訪問数，電話調査の方法や，これらの調査の時期などでその結果は大きく異なる変動性の強いデータである。
それにもかかわらず，原告データベースと被告データベースとでその数値の多くが完全に一致する。
原告データベース作成者と被告データベース作成者とが，同じ方法で同じ時期に調査を行ったということはあり得ないから，このような一致は，被告データベースが原告データベースをデッドコピーしたものであることを示すものである。
（オ）その他のデータの一致（甲１４，１５）
原告データベースのマスターテーブルに格納されたデータのほとんどが，被告データベースのそれと一致する。
例えば，ａｌｌ　ＬＩＮＥテーブルにおいては，原・被告両データベースとも，００１いずみ鉄道，００２シーサイドライン，００３ニューシャトルのように，全く同じ名称の交通機関が同じ順番に並んでいる。
この順番には，誰もが思い付くような定型的な規則性はなく，その完全な符合は，被告らが原告データベースをデッドコピーしたことを示している。
このように，甲１４（原告データベースのマスターテーブル）と甲１５（被告データベースのマスターテーブル）とを対比すると，すべてのマスターテーブルにおける個別の各データが完全に一致する。
マスターテーブル内の個別のデータの完全な一致は，被告データベースが原告データベースをデッドコピーしたものであることを示す。
イフィールド項目のコピーの事実（甲４６，１７，２６）
原告データベースと被告データベースは，フィールド項目についてもほぼ一致する。
特に，被告データベースの項目の中に被告データベースの性質上全く不要な「ｓｙｂａｓｅ更新日，ｓｙｂａｓｅ登録日」が存在している（甲２４の１６頁）のは，被告らが原告データベースをコピーしたという以外に説明できない。
なお，「ｓｙｂａｓｅ更新日，ｓｙｂａｓｅ登録日」は被告データベースの平成１２年８月版からは削除されている（検甲１，同１７頁）。
また，甲１７添付の競合会社項目比較表をみると，原告データベースと被告データベースは，その他のフィールド項目についてもほぼ完全に一致する。
すなわち，原告データベースにおける各テーブルのフィールド項目のうち，被告データベースにおける各テーブルのフィールド項目として存在しているものは，ＰＲＯＪＥＣＴテーブル１１０フィールドのうち　６６フィールド，詳細テーブル９２フィールドのうち７９フィールド，住戸一般テーブル３６フィールドのうち２９フィールド，広告テーブル３３フィールドのうち３０フィールド，月報タイプテーブル１７フィールドのうち１３フィールド，申込テーブル１３フィールドのうち７フィールド，月報価格テーブル１０フィールドのうち６フィールド，ａｌｌ　ＬＩＮＥテーブル・ＴＯＷＮテーブル・ＡＮＭテーブル８フィールドのうち６フィールド，ａｌｌ　ＴＲＡＦテーブル６フィールドのうち４フィールド，ＰＲＥＦテーブル９フィールドのうち７フィールド，その他のテーブル内のすべてのフィールドである（別紙図２参照）。
被告データベースのフィールド項目数が少ないのは，被告らが削除したからであるが，仮に被告らがコピーしなかった部分があるとしても，他の大多数の部分をコピーしたという事実に影響はない。
ウ体系的構成のコピーの事実（別紙図１，２参照）
別紙図１及び同２を比較すれば，原告・被告の各データベースの間で体系的構成がほぼ一致することが明らかである。
すなわち，原告データベースの７個のエントリーテーブル（ＰＲＯＪＥＣＴテーブル・詳細テーブル・広告テーブル・住戸一般テーブル・申込テーブル・月報タイプテーブル・月報価格テーブル）及び１２個のマスターテーブル（構造ｒｅｐｏｒｔテーブル・ＰＡＰＥＲテーブル・ＴＹＰＥテーブル・法規制コード１テーブル・法規制コード２テーブル・ＬＡＷ３テーブル・ＫＡＫＡＫＵテーブル・ａｌｌＬＩＮＥテーブル・ａｌｌ　ＴＲＡＦテーブル・ＰＲＥＦテーブル・ＴＯＷＮテーブル・ＡＮＭテーブル）すべてが被告データベースに存在しており，被告データベースに存在しないため関連付けられない箇所を除くと，テーブル間の関連付けは，ほぼ完全に一致する。
エ被告らによる改ざん行為の事実
（ア）ＩＤの改ざん
前記のとおり，被告らは，原告の付したＩＤに機械的操作を加えて，デッドコピーの事実の隠蔽を図った。
（イ）登録日の変更
前記のとおり，法規制コードについて，原告データベースと被告データベースとでは登録日が完全に一致するところ，被告らは，平成１２年の８月に，上記登録日の変更を一斉に行った。
そのため，すべてのデータ登録日が，９９／０５／２０１６：３４：５４になっている（甲２６の１７頁）。
このようなことは機械的変更でなければありえないことであり，デッドコピーを示す登録日の一致という事実を隠蔽するためにされたことは，明らかである。
（ウ）サイベース登録日の削除
被告らによるデッドコピーを裏付けるこの項目は，被告データベースの平成１２年８月版において削除されており，被告らによる隠蔽工作の跡である（甲２６の１７頁）。
【被告らの主張】
原告は，被告らが原告データベースをデッドコピーして被告データベースを作成したと主張するが，事実に反する。
原告データベースと被告データベースとは，その相違点からみて，別個の著作物である。
つまり，被告データベースは，原告データベースに依拠しておらず，原告データベースを複製したものではない。
このことは，データベース作成日時の違い，テーブルの数や種類の違い，関連付けの違い，データ量の違いからそれぞれ裏付けられる。
アデータベース作成日時の違い
（ア）乙３６添付の画面１によれば，原告データベースのプロパティ詳細情報の画面の作成日時は，１９９８年２月１３日１３：５４：１８と記載されている。
これに対して，乙３６添付の画面２によれば，被告データベースのプロパティ詳細情報の画面の作成日時は，１９９９年４月１５日１６：４１：００と記載されている。
（イ）乙３６添付の画面３によれば，原告データベースのテーブルの詳細表示の画面に記載されている各テーブルの作成日時は，１９９８年２月１３日１３時５５分１８秒から始まっている。
これに対して，乙３６添付の画面６によれば，被告データベース各テーブルの作成日時は，１９９９年４月１５日１７時１分１７秒から始まっている。
イテーブル数や種類の違い
（ア）原告データベースである検甲１中のテーブル表示の画面（乙７）によると，原告データベースには６２のテーブルが存在する。
これに対して，被告データベースのテーブル表示画面（乙８）によると，被告データベースには２８のテーブルしか存在しない。
（イ）乙３５添付の図２は，原告データベースの主要なテーブルと各テーブル間の関連付けを図表化したものであり，乙３５添付の図３は，被告データベースのテーブルと各テーブル間の関連付けを図表化したものである。
この両者を比較すると，原告データベースには，詳細テーブルのほかに，物件情報がその種別ごとに格納されるシルバーテーブル，一棟テーブル，定借テーブルが存在し，また，定借テーブルに対応して住戸定借テーブルが存在するが，被告データベースにはこれらのテーブルは存在しない。
なぜなら，被告データベースは，一般の新築分譲マンションと定期借地権付マンション情報しか扱っておらず，また，定期借地権付マンション固有の情報項目は扱っていないからである。
また，原告データベースには，このほかに設備関係の情報を格納する設備テーブルが存在するが，被告データベースには，設備テーブルは存在しない。
ウ関連付けの違い
（ア）原告データベースは，ほとんどのテーブルがＰＲＯＪＥＣＴテーブルとＰＲＯＪＥＣＴＩＤにより関連づけられているが，被告データベースにおいて，ＰＲＯＪＥＣＴ　ＩＤによってＰＲＯＪＥＣＴテーブルと関連付けられているのは，詳細テーブルだけである。
（イ）原告データベースにおいては，ＰＲＯＪＥＣＴ　ＩＤによる関連付けのほかに，詳細テーブルを中心とする期分けＩＤによる関連付け，月報ＩＤによる関連付けが存在する。
これに対して，被告データベースには，詳細テーブルを中心とする期分けＩＤによる関連付けしか存在しない。
エデータ量の違い
（ア）原告データベースのＰＲＯＪＥＣＴテーブルに格納されている物件数は１万５７７３件であるが，被告データベースのＰＲＯＪＥＣＴテーブルに格納されている物件数は５５３６件にすぎない。
（イ）乙３６添付の画面１１によれば，原告データベースと被告データベースのＰＲＯＪＥＣＴテーブルに存在する物件のうち同一物件を扱っている件数は，２４３１件にすぎない。
さらにこの中から同一情報を抽出すると，その数は１７０件にすぎない。
たしかに，原告データベースと被告データベースとの間には重複情報が存在するが，存在する重複情報はごくわずかであるし，データ自体が著作物性を持つものでない以上，このデータの重複が著作権侵害と結び付くものとはいえない。
〔争点２（２）原告データベースのうち被告データベースと共通する情報及び構成が，著作物性を認めるに足りる創作性を有するか〕
【原告の主張】
原告データベースは著作権法にいうデータベースの著作物に該当し，原告データベースの被告データベースと共通する情報及び構成も，著作物性を認めるに足りる創作性を有している。
【被告らの主張】
原告データベースのうち被告データベースと共通する情報及び構成は，著作物性を認めるに足りる創作性を有しない。
すなわち，仮に原告データベース全体の情報の選択に創作性の認められる部分が存在するとしても，被告データベースが設定している情報分類項目は，不動産情報の開示としては必要最低限の項目にすぎない。
つまり，被告らは原告データベースの情報分類項目のうち，創作性のない部分を重複して情報分類項目として設定しているにすぎない。
また，体系の設定の点についても創作性はない。

第３当裁判所の判断

１争点１（原告データベースが著作権法にいうデータベースの著作物に該当するか）
（１）著作権法２条１項１０号の３は，データベースとは「論文，数値，図形その他の情報の集合物であつて，それらの情報を電子計算機を用いて検索することができるように体系的に構成したものをいう。」と規定し，同法１２条の２第１項は「データベースでその情報の選択又は体系的な構成によつて創作性を有するものは，著作物として保護する。」と規定する。
このように，データベースとは，情報の集合物を電子計算機を用いて検索することができるように体系的に構成したものをいうのであるところ，前記前提となる事実によれば，原告データベースは，データベースの情報の単位であるレコードを別のレコードと関連付ける処理機能を持つ「リレーショナル・データベース」と呼ばれるものである。
リレーショナル・データベースにおいては，入力される情報はテーブルと呼ばれる表に格納され，各テーブルはフィールド項目に細分され，あるテーブルのあるフィールド項目を他のテーブルのあるフィールド項目と一致させてテーブル間を関連付けることにより，既存の複数のテーブルから抽出したいフィールド項目だけを効率的に選択することができるのであるから，情報の選択又は体系的な構成によってデータベースの著作物と評価することができるための重要な要素は，情報が格納される表であるテーブルの内容（種類及び数），各テーブルに存在するフィールド項目の内容（種類及び数），各テーブル間の関連付けのあり方の点にあるものと解される。
（２）そこで，原告データベースの創作性について検討するに，前記前提となる事実によれば，原告データベースは，新築分譲マンション開発業者等に対する販売を目的とするものであり，同データベースを用いて，新築分譲マンションの平均坪単価，平均専有面積，価格別販売状況等を集計したり，検索画面（甲７の１３）に一定の検索条件を入力して，価格帯別需給情報等の情報を，表やグラフのような帳票形式（甲８）で出力したりすることができるものである。
そして，原告データベースは，別紙図１のとおりの構造を含むと認められるところ，そのテーブルの項目の内容（種類及び数），各テーブル間の関連付けのあり方について敷衍して述べると，ＰＲＯＪＥＣＴテーブル，詳細テーブル等の７個のエントリーテーブルと法規制コードテーブル等の１２個のマスターテーブルを有し，エントリーテーブル内には合計３１１のフィールド項目を，マスターテーブル内には７８のフィールド項目を配し，各フィールド項目は，新築分譲マンションに関して業者が必要とすると思われる情報を多項目にわたって詳細に採り上げ，期分けＩＤ等によって各テーブルを有機的に関連付けて，効率的に必要とする情報を検索することができるようにしているものということができる。
すなわち，客観的にみて，原告データベースは，新築分譲マンション開発業者等が必要とする情報をコンピュータによって効率的に検索できるようにするために作成された，上記認定のとおりの膨大な規模の情報分類体系というべきであって，このような規模の情報分類体系を，情報の選択及び体系的構成としてありふれているということは到底できない。
加えて，他に原告データベースと同様の情報項目，体系的構成を有するものが存在するとも認められないことは，原告データベースを含む構造（別紙図１）をＭＲＣ社のデータベースが含む構造（別紙図３），不動産月報（乙１），不動産の表示規約（乙３３），株式会社東京カンテイの新築マンション詳細情報（１）（乙３４）等と比較精査しても明らかである。
したがって，原告データベースが含む構造（別紙図１）は，その情報の選択及び体系的構成の点において，著作権法１２条の２にいうデータベースの著作物としての著作物性を認めるに足りる創作性を有するものと，認めることができる。
（３）被告らは，原告データベースの情報項目等の選択はありふれていると主張するが，原告データベースが含まれる構造をみても，７個のエントリーテーブル内には合計３１１のフィールド項目を，１２個のマスターテーブル内には７８のフィールド項目を配し，各フィールド項目は，新築分譲マンションに関して業者が必要とすると思われる情報を多項目にわたって詳細に採り上げたものと認められるのであって，これをセットとしてみたとき，創作性がないとはいえない。
また被告らは，原告データベースが含まれる構造とＭＲＣ社のデータベースが含まれる構造との同一性を指摘し，乙３５を提出するが，原告データベースがＭＲＣ社のデータベースと共通する構造を含むとしても，原告データベースが含まれる構造の全体とＭＲＣ社のデータベースが含まれる構造とを比較すると，原告データベースが含まれる構造に比べてＭＲＣ社のデータベースが含まれる構造は単純なものといわざるを得ない。
すなわち，原告データベースが含まれる構造は，上記のとおり，種々のテーブルを持ち，４００に迫る多数のフィールド項目や多種多様な関連付けを持つ情報分類体系となっているから，その全体をみれば，情報項目等の選択の点に関するほか，体系的構成の点における創作性も優に認められるというべきである。
つまり，個々のテーブル，フィールド項目や関連付けに着目するのではなく，テーブル間の多種多様な関連付けなどの全体を総体としてみれば，そこに創作性を認めることが可能である。
被告らの主張は採用できない。
また被告らは，原告は単に「アクセス」を使ってリレーショナルデータベースを構築したことを述べるにすぎず，体系的構成の点に創作性はないと主張する。
たしかに，当該データベースが取引されると考えられる業界の状況や先行データベースとの関係等の制約から，当該業界で情報として必須とされる項目は限られてくると考えられるから，業界で通常必須とされる情報項目を設定したにすぎないような，多くの項目を含まないデータベースであれば，単に「アクセス」というコンピュータソフトを使用してその業界一般の情報項目を設定して情報を分類する体系を作成したにすぎないとして，著作物性を否定される場合もあり得よう。
しかしながら，原告データベースが含まれる構造は，上記認定のとおり，７個のエントリーテーブル内には合計３１１のフィールド項目を，１２個のマスターテーブル内には７８のフィールド項目を配し，各フィールド項目は，新築分譲マンションに関して業者が必要とすると思われる情報を多項目にわたって詳細に採り上げ，期分けＩＤ等によって各テーブルを有機的に関連付けて，効率的に必要とする情報を検索することができるようにしているものであるから，かような規模の情報分類体系について，マンション業界のだれであっても「アクセス」を使用すれば同じように作成することができるとは到底いえない。
したがって，原告データベースは，著作物性を認めるに足りる創作性を十分肯認することができるというべきである。
つまり，これだけ多数のテーブル，フィールド項目，関連付けを，素材となるデータも含めて全体としてみると，著作物性を認めるに足りる創作性を否定することはできないというほかはない。
被告らの主張は採用することができない。
なお，具体的には，以下のとおりである。
アテーブル間の関連
被告らは，テーブル間の関係は，各テーブルに格納されるデータの性質によりおのずから決定されるのであり，被告データベースのテーブル構成及び関連付けは，変動要素のある情報とそうでない情報を分けるというデータベース構築の基本的な考え方に基づいて作成されたものにすぎず，この部分に対応する原告データベースについて，原告が主張するような著作物性を肯定するに足りるほどの創作性はないと主張する。
そして例えば，ＰＲＯＪＥＣＴテーブルと詳細テーブルとの関係について，被告データベースにおいてＰＲＯＪＥＣＴテーブルと詳細テーブルに物件名を分けて格納するようにした理由は，格納するデータの性質及び変動要素を基準としているのであって，このようなテーブル設定に，著作物性を認めるに足りるほどの創作性はないと主張する。
しかしながら，この点は，証拠（甲２５，乙３５）及び弁論の全趣旨によれば，同業他社のＭＲＣ社のデータベースにおいてもこのような構成はとられておらず，他に同様の構成をとっている同業他社のデータベースが存在することも認められないし，総合的体系の一部をなす一つ一つの要素を別個に取り出してきて創作性の有無を論じるのはそもそも相当でない。
したがって，たとえ変動要素とそうでない要素とを分けるという発想がデータベース構築の基本にあり，原告データベースが同発想に基づいて構築されていたとしても，これをもってただちに原告データベースの創作性を否定することはできないというべきである。
被告らの主張を採用することはできない。
ＰＲＯＪＥＣＴテーブルと詳細テーブルとの関係，詳細テーブルと住戸一般テーブルとの関係，詳細テーブルと広告テーブルの関係，詳細テーブルと申込テーブルの関係，詳細テーブルと月報タイプテーブルの関係，詳細テーブルと月報価格テーブルの関係についていう被告らの主張も，これと同様の理由により，採用することができない。
イマスターテーブルについて
また被告らは，マスターテーブルとは，情報項目として繰り返し使用される項目を独立したテーブルに格納するものであって，データベース構築の基本的な考え方であるから，著作物性を認めるに足りるほどの創作性はないと主張する。
たしかに，単にマスターテーブルを設定すること自体については，そのようにいうことができる。
しかし，本件における１２個のマスターテーブルは，上記認定のとおりの規模をもつ原告データベースの総合的体系の中の一部に位置づけられて機能するものであるから，マスターテーブルの種類及び数，各マスターテーブルのフィールド項目，その関連付け等によって果たす機能を，全体の情報分類体系中における位置付けから評価して創作性を考えるべきなのであって，個々のマスターテーブルのみを取り出して創作性を論じるのは相当でないというべきである。
したがって，被告らの主張を採用することはできない。
（５）以上のとおりであるから，原告データベースについては，全体としてみれば，情報項目の選択及び体系的構成のいずれの点においても，著作権法にいうデータベースの著作物に該当すると判断するに足りる，創作性を肯定することができる。
２争点２（被告データベースが原告データベースの複製であり，その著作権を侵害しているか）
〔争点２（１）被告データベースが原告データベースに依拠して作成されたものか〕（１）前記前提となる事実に証拠（甲１３及び弁論の全趣旨）を総合すれば，本件の事実経過として，以下の事実を認めることができる。
ア株式会社デジタルウェアは，原告データベースの著作者として著作権を有していたが，平成１０年１２月１６日，破産宣告を受けた。
イ被告Ｂを始めとする株式会社デジタルウェアの従業員１０名は，破産管財人の補助者として，平成１１年１月２８日ころから同年３月１１日ころまで原告データベースの更新作業に従事しており，原告データベースにアクセスする機会があった。
ウ被告デジタル・ピクチャーズは，平成１１年３月，株式会社デジタルウェアの従業員であった被告Ｂを取締役の一人とし，株式会社デジタルウェアの従業員１１名中１０名を雇用した。
エ原告は，平成１１年５月２１日，破産会社デジタルウェア破産管財人から入札により原告データベースに関する一切の権利を取得した。
この入札の際，被告デジタル・ピクチャーズの代表者である被告Ａが代表者を務める株式会社エグゼも参加していた。
オ被告デジタル・ピクチャーズは，平成１１年６月ころから，被告データベースを使用し，頒布した。
（２）被告データベースの内容は，上記のとおり，別紙図２のとおりの構造を含むと認められるところ，前記前提となる事実に証拠（検甲１，甲４６，１５１７，２２２４，乙２５，３５）及び弁論の全趣旨を総合して，このような被告データベースを含む構造と原告データベースを含む構造とを，テーブルの内容（種類及び数），各テーブルに設定されたフィールド項目の内容，各テーブルの関連付けのあり方について対比すると，その結果は，以下のとおりであると認められる。
アテーブルの数及び種類については，被告データベースには７個のエントリーテーブル（ＰＲＯＪＥＣＴテーブル・詳細テーブル・広告テーブル・住戸一般テーブル・申込テーブル・月報タイプテーブル・月報価格テーブル）と１８個のマスターテーブル（構造ｒｅｐｏｒｔテーブル・ＰＡＰＥＲテーブル・ＴＹＰＥテーブル・法規制コード１テーブル・法規制コード２テーブル・ＬＡＷ３ないしＬＡＷ８テーブル・ＫＡＫＡＫＵテーブル・状況マスターテーブル・ａｌｌ　ＬＩＮＥテーブル・ａｌｌ　ＴＲＡＦテーブル・ＰＲＥＦテーブル・ＴＯＷＮテーブル・ＡＮＭテーブル）が存在するが，原告データベースにも，同名称の７個のエントリーテーブル及び同名称の１２個のマスターテーブル（構造ｒｅｐｏｒｔテーブル・ＰＡＰＥＲテーブル・ＴＹＰＥテーブル・法規制コード１テーブル・法規制コード２テーブル・ＬＡＷ３テーブル・ＫＡＫＡＫＵテーブル・ａｌｌ　ＬＩＮＥテーブル・ａｌｌ　ＴＲＡＦテーブル・ＰＲＥＦテーブル・ＴＯＷＮテーブル・ＡＮＭテーブル）が存在する（なお，被告データベースにあって原告データベースにないテーブルは，６個のマスターテーブル〔ＬＡＷ４ないしＬＡＷ８テーブル，状況マスターテーブル〕である。）。
イ各テーブルに存在するフィールド項目については，被告データベースのフィールド項目は，状況マスターテーブルに存在する「ＩＤ」フィールド，「状況」フィールドの２フィールド項目を除き，すべて原告データベースにおいて対応するフィールド項目が存在し，しかも，対応するフィールド項目の名称はほぼすべて一致する。
ウテーブル相互間の関連付けについては，以下のとおりであり，これらによれば，被告データベースに存在する関連付けのほぼすべてと同じ関連付けが，原告データベースに存在することが認められる。
（ア）被告データベースでは，ＰＲＯＪＥＣＴテーブルの「ＰＲＯＪＥＣＴ‐ＩＤ」フィールドと，詳細テーブルの「Ｐ＿ＰＲＯＪＥＣＴＩＤ」フィールドが関連付けられている。
これは，原告データベースにおいて，ＰＲＯＪＥＣＴテーブルの「ＰＲＯＪＥＣＴ‐ＩＤ」フィールドが，詳細テーブルの「ＰＲＯＪＥＣＴ‐ＩＤ」フィールドと関連付けられていることと一致する。
（イ）被告データベースでは，ＰＲＯＪＥＣＴテーブルの「構造」フィールドと構造ｒｅｐｏｒｔテーブルの「ＣＯＤＥ」フィールドが関連付けられている。
これは，原告データベースの関連付けと一致する。
（ウ）被告データベースでは，ＰＲＯＪＥＣＴテーブル「法規制１‐１」「法規制１‐２」「法規制１‐３」と，法規制コード１テーブルの法規制コードフィールド及びＬＡＷ３ＬＡＷ５テーブルの各「ＬＡＷ１」フィールドとが関連付けられている。
これに対し，原告データベースのＰＲＯＪＥＣＴテーブル「法規制１‐１」・「法規制１‐２」・「法規制１‐３」は，原告データベースにないＬＡＷ４，ＬＡＷ５各テーブルとの関連付けはないが，法規制コード１テーブルの法規制コードフィールド及びＬＡＷ３テーブルのＬＡＷ１フィールドと関連付けられている。
（エ）被告データベースでは，ＰＲＯＪＥＣＴテーブル「法規制２‐１」「法規制２‐２」「法規制２‐３」と，法規制コード２テーブルの法規制コードフィールド及びＬＡＷ６ＬＡＷ８各テーブルの各「ＬＡＷ１」フィールドとが関連付けられている。
これに対し，原告データベースのＰＲＯＪＥＣＴテーブル「法規制２‐１」・「法規制２‐２」・「法規制２‐３」は，原告データベースにないＬＡＷ６ＬＡＷ８各テーブルとの関連付けはないが，法規制コード２テーブルの法規制コードフィールド及びＬＡＷ３テーブルのＬＡＷ１フィールドと関連付けられているから，関連付けとしてはほぼ一致する。
（オ）被告データベースでは，ＰＲＯＪＥＣＴテーブル「路線１」「路線２」「路線３」の各フィールドとａｌｌ　ＴＲＡＦテーブルＴＲＡＦ１フィールドとの間に関連付けがされているが，これは，原告データベースの関連付けと一致する。
（カ）被告データベースでは，ＰＲＯＪＥＣＴテーブル行政区分コードフィールドとＴＯＷＮテーブルのＪＣＯＤＥフィールドとの間に関連付けがされているが，これは，原告データベースの関連付けと一致する。
（キ）被告データベースでは，詳細テーブル期分けＩＤフィールドと，広告テーブル「期分けＩＤ」，住戸一般テーブル「期分けＩＤ」，申込テーブル「期分けＩＤ」，月報タイプテーブル「期分けＩＤ」，月報価格テーブル「期分けＩＤ」の各フィールド間とが関連付けられている。
これは，原告データベースの関連付けと一致する。
（ク）被告データベースでは，詳細テーブル状況コードフィールドと状況マスターテーブル「ＩＤ」との間に関連付けがされているが，原告データベースには，状況マスターテーブルが存在しないため，同関連付けはない。
（ケ）被告データベースでは，住戸一般テーブル間取りフィールドとＴＹＰＥテーブルＴｙｐｅＣｏｄｅフィールド間に関連付けがされている。
これは，原告データベースの関連付けと一致する。
（コ）被告データベースでは，広告テーブル媒体名フィールドとＰＡＰＥＲテーブルＢＣＯＤＥフィールド間に関連付けがされている。
これは，原告データベースの関連付けと一致する。
（サ）被告データベースでは，月報タイプテーブル間取りコードフィールドとＴＹＰＥテーブルＴｙｐｅＣｏｄｅフィールド間に関連付けがされている。
これは，原告データベースの関連付けと一致する。
（シ）被告データベースでは，月報価格テーブルの価格帯コードフィールドとＫＡＫＡＫＵテーブルＫａｋａｋｕＣｏｄｅフィールド間に関連付けがされている。
これは，原告データベースの関連付けと一致する。
エ以上アウによれば，被告データベースは，テーブルの内容（種類及び数），各テーブルに存在するフィールド項目の名称，テーブル間の関連付けのすべての点からして，原告データベースの構造の一部分とほぼ完全に一致すると認められる。
なお，被告らは，被告データベースにあって原告データベースにないものとして，６個のマスターテーブル（ＬＡＷ４ＬＡＷ８テーブル，状況マスターテーブル）や，その他いくつかのフィールド項目がある旨主張するが，これをアウで認定した一致部分の規模と比較するならば，ごく僅かの相違にすぎないと評価すべきであるから，上記のように，被告データベースが原告データベースの構造の一部分とほぼ完全に一致するといって妨げないというべきである。
（３）また，両データベース間で素材とする情報が重なっているかどうかをみるに，証拠（検甲１，甲１の１３，甲２４，１４，１５，２４２６，乙４，５）及び弁論の全趣旨によれば，被告データベースに格納されている具体的なデータについて，以下の事実が認められる。
ア被告データベースの物件購入申込率に関して，平成１０年１月１日から同年２月２８日までの間に分譲のあった分のデータにつき，対応する物件についての原告データベースの申込率の数値を比較すると，その約９割の数値が一致する（甲１の１３，２７）。
乙３７の記載をもってしても，同認定を左右するに足りない（仮に，乙３７の記載を前提にして平成１０年１月１日から同年１２月３１日までの間の申込率の数値についてみても，申込率がそもそも入力されていない物件も含んだ全物件２７６９件中，１８２３件もの物件に関する申込率の数値が被告データベースと原告データベースとで一致している。）。
イ被告データベースにおいて，登録日が平成１０年１月５日から平成１１年３月１１日までの間となっている物件に付されている物件ＩＤに関して，その９桁中の上６桁が，原告データベースに付されている期分けＩＤの９桁中の下６桁とすべて一致する。
ウ被告データベースにおいて使用する編集分類である帳票の項目及び検索項目が，原告データベースとほぼ一致する。
エ被告データベースのＰＲＯＪＥＣＴ　ＩＤは，原告データベースにおける同一物件に付されているのＰＲＯＪＥＣＴ　ＩＤと規則性をもって対応する。
すなわち，原告データベースのＰＲＯＪＥＣＴ　ＩＤから１９６０を差し引いた数値を上２桁にし，原告データベースのＰＲＯＪＥＣＴＩＤの下４桁をそれに続けて，その後に００をつければ，被告データベースのＰＲＯＪＥＣＴＩＤと一致する。
オ被告データベースと原告データベースの各法規制コード１テーブル及び各ＴＹＰＥテーブルにおいては，それぞれの対応するデータの登録日が，日時のみならず時間，分，秒の単位に至るまで一致する。
また，同各テーブルにおけるデータには，被告らが被告データベースの構築を開始したと主張する平成１１年３月２０日より前の登録日が記載されたデータが存在する。
カ被告データベースの平成１２年８月版では，被告データベースの平成１２年７月版と異なり，法規制コード，ＴｙｐｅＣｏｄｅのすべてのデータ登録日が，９９／０５／２０１６：３４：５４となっている。
つまり，被告らが，本訴提起後である平成１２年８月ころ，法規制コードの登録日の変更を一斉に行ったと認められる。
（４）上記の（１）（３）によれば，被告データベースが素材とする情報が原告データベースと重なっており，制作されたテーブルの内容（種類及び数），各テーブルに設定されたフィールド項目の内容，各テーブル間の関連付けのあり方のすべての点において共通しているということができる。
（５）以上を総合すれば，被告データベースは，原告データベースに依拠して作成されたというべきであって，原告データベースを含む構造は，被告データベースを含む構造とその内容の点で同一であるといわなければならない。
（６）被告らは，データベース作成日時の違い，テーブルの数や種類の違い，関連付けの違い，データ量の違いの各点を指摘し，原告データベースと被告データベースとは，その相違点からみて，別個の著作物であると主張するが，以下に述べるとおり，採用することができない。
アデータベース作成日時の違い
たしかに，乙３６添付の画面１によれば，原告データベースのプロパティ詳細情報の画面の作成日時は，１９９８年２月１３日１３：５４：１８と記載され，これに対して，乙３６添付の画面２によれば，被告データベースのプロパティ詳細情報の画面の作成日時は，１９９９年４月１５日１６：４１：００と記載されていること，乙３６添付の画面３によれば，原告データベースのテーブルの詳細表示の画面に記載されている各テーブルの作成日時は，１９９８年２月１３日１３時５５分１８秒から始まっているのに対して，乙３６添付の画面６によれば，被告データベースのテーブルの詳細表示の画面に記載されている各テーブルの作成日時は，１９９９年４月１５日１７時１分１７秒から始まっていることがそれぞれ認められる。
しかし，この事実は，上記に認定した原告データベースと被告データベースとの間の一致点の量と質に照らせば，単に複製後に被告らにおいて別ファイルで登録した可能性を示唆するものであっても，被告データベースが原告データベースに含まれる構造を複製したものとの上記認定を左右するとはいえない。
イテーブルの数や種類の違い
被告らは，乙７によれば，原告データベースには６２のテーブルが存在するところ，乙８によれば，被告データベースには２８のテーブルしか存在しないと主張し，また，乙３５添付の図２（原告データベースの主要なテーブルと関連付けを図表化したもの）と乙３５添付の図３（被告データベースのテーブルと関連付けを図表化したもの）を比較すると，原告データベースには，詳細テーブルのほかに，物件情報がその種別ごとに格納されるシルバーテーブル，一棟テーブル，定借テーブルが存在し，定借テーブルに対応して住戸定借テーブルが存在するところ，被告データベースにはこれらのテーブルは存在しない，原告データベースには，このほかに設備関係の情報を格納する設備テーブルが存在するが，被告データベースには，設備テーブルは存在しないと主張する。
しかし，上記（２）に認定したところによれば，被告データベースは，テーブルの内容（種類及び数），各テーブルに存在するフィールド項目の名称，テーブル間の関連付けのすべての点からして，原告データベースの構造の一部分とほぼ完全に一致していると認められるのであるから，被告らの主張の事実は，単に被告らにおいて原告データベースに存在するテーブルのうちのいくつかを除いて複製を行ったか，あるいは複製後に被告らにおいて原告データベースのテーブルのうちのいくつかを削除した可能性を示唆するものであっても，そのことをもって，被告データベースが原告データベースの一部を複製したものであるという上記認定を左右するものではない。
しかも，被告データベースとほぼ完全に一致する原告データベース部分は，上記（２）に認定したとおりの相当程度の規模であるから，原告データベースの同被複製部分のみにおいても十分に有機的なまとまりを有するというべきである（このことは，原告データベースよりもテーブル数，フィールド項目数が少ない被告データベースを，被告デジタル・ピクチャーズ，同エクスが実際に商用に使用，頒布していることに照らしても明らかというべきである。）。
被告らの主張を採用することはできない。
ウ関連付けの違い
被告らは，原告データベースは，ほとんどのテーブルがＰＲＯＪＥＣＴテーブルとＰＲＯＪＥＣＴ　ＩＤにより関連づけられているが，被告データベースでは，ＰＲＯＪＥＣＴ　ＩＤによってＰＲＯＪＥＣＴテーブルと関連付けられているのは詳細テーブルだけである，原告データベースは，ＰＲＯＪＥＣＴ　ＩＤによる関連付けのほかに，詳細テーブルを中心とする期分けＩＤによる関連付け，月報ＩＤによる関連付けが存在するが，被告データベースでは，詳細テーブルを中心とした期分けＩＤによる関連付けしか存在しない，と主張する。
しかし，上記（２）に認定したところによれば，被告データベースは，テーブルの内容（種類及び数），各テーブルに存在するフィールド項目の名称，テーブル間の関連付けのすべての点からして，原告データベースの構造の一部分とほぼ完全に一致しているのであるから，被告らの主張の事実は，単に被告らにおいて原告データベースに存在するテーブルのうちのいくつかを除いて複製を行ったか，あるいは複製後に被告らにおいて原告データベースのテーブルのうちのいくつかを削除した可能性を示唆するものであっても，そのことをもって，被告データベースが原告データベースの一部を複製したものであるという上記認定を左右するものではない。
被告データベースとほぼ完全に一致する原告データベース部分は，上記（２）に認定したとおりの相当程度の規模であるから，原告データベースの同被複製部分のみにおいても十分に有機的なまとまりを有するというべきである。
被告らの主張を採用することはできない。
エデータ量の違い
被告らは，原告データベースのＰＲＯＪＥＣＴテーブルにおいて格納されている物件数は１万５７７３件であるが，被告データベースのＰＲＯＪＥＣＴテーブルに格納されている物件数は５５３６件にすぎない，乙３６添付の画面１１によれば，原告データベースと被告データベースのＰＲＯＪＥＣＴテーブルに存在する物件のうち同一物件を扱っている件数は２４３１件であるにすぎず，さらにこの中から同一情報を抽出するとその数は１７０件であるにすぎないと主張する。
しかしながら，上記（３）に認定したところによれば，被告データベースと原告データベースとの間においては，個別の具体的なデータについても，物件購入申込率，物件ＩＤ，帳票の項目及び検索項目，ＰＲＯＪＥＣＴ　ＩＤ，法規制コード１テーブルの各データの登録日がすでに一致ないしほぼ一致するものであることが認められるのであって，この他，被告データベースが，その性質上，日々これに含まれる情報を更新していくものであること（弁論の全趣旨により認められる。）や，上記（４）に認定した事実を加味して考えれば，被告らの主張を前提としても，被告データベースが原告データベースに含まれる構造を複製したものであるとの上記認定を左右するに足りないというべきである。
〔争点２（２）原告データベースのうち被告データベースと共通する情報及び構成が，著作物性を認めるに足りる創作性を有するか〕
（１）原告データベースにおいて，被告データベースの構造と共通し，被告らが原告データベースの当該部分を複製したと認められる部分（以下「原告データベース被複製部分」という。）は，争点２（１）についての判断において認定した事実を整理すれば，以下のとおりである。
アテーブルは，７個のエントリーテーブル（ＰＲＯＪＥＣＴテーブル・詳細テーブル・広告テーブル・住戸一般テーブル・申込テーブル・月報タイプテーブル・月報価格テーブル）と１２個のマスターテーブル（構造ｒｅｐｏｒｔテーブル・ＰＡＰＥＲテーブル・ＴＹＰＥテーブル・法規制コード１テーブル・法規制コード２テーブル・ＬＡＷ３テーブル・ＫＡＫＡＫＵテーブル・ａｌｌ　ＬＩＮＥテーブル・ａｌｌ　ＴＲＡＦテーブル・ＰＲＥＦテーブル・ＴＯＷＮテーブル・ＡＮＭテーブル）である。
イフィールド項目は，ＰＲＯＪＥＣＴテーブル１１０フィールドのうち６５フィールド，詳細テーブル９２フィールドのうち７９フィールド，住戸一般テーブル３６フィールドのうち２９フィールド，広告テーブル３３フィールドのうち３０フィールド，月報タイプテーブル１７フィールドのうち１３フィールド，申込テーブル１３フィールドのうち７フィールド，月報価格テーブル１０フィールドのうち６フィールド，ａｌｌ　ＬＩＮＥテーブル・ＴＯＷＮテーブル・ＡＮＭテーブル８フィールドのうち６フィールド，ａｌｌ　ＴＲＡＦテーブル６フィールドのうち４フィールド，ＰＲＥＦテーブル９フィールドのうち７フィールド及びその他のテーブル内の全フィールドである。
ウテーブル相互間の関連付けについては，以下のとおりである。
（ア）ＰＲＯＪＥＣＴテーブルの「ＰＲＯＪＥＣＴ　ＩＤ」フィールドの，詳細テーブルの「ＰＲＯＪＥＣＴＩＤ」フィールドとの関連付け
（イ）ＰＲＯＪＥＣＴテーブル「構造」フィールドの，構造ｒｅｐｏｒｔテーブル「ＣＯＤＥ」フィールドとの関連付け
（ウ）ＰＲＯＪＥＣＴテーブル「法規制１‐１」・「法規制１‐２」・「法規制１‐３」フィールドの，法規制コード１テーブル「法規制コード」フィールド及びＬＡＷ３テーブルの「ＬＡＷ１」フィールドとの関連付け
（エ）ＰＲＯＪＥＣＴテーブル「法規制２‐１」・「法規制２‐２」・「法規制２‐３」フィールドの，法規制コード２テーブル「法規制コード」フィールド及びＬＡＷ３テーブルの「ＬＡＷ１」フィールドとの関連付け
（オ）ＰＲＯＪＥＣＴテーブル「路線１」「路線２」「路線３」フィールドの，ａｌｌ　ＴＲＡＦテーブル「ＴＲＡＦ１」フィールドとの関連付け
（カ）ＰＲＯＪＥＣＴテーブル「行政区分コード」フィールドの，ＴＯＷＮテーブル「ＪＣＯＤＥ」フィールドとの関連付け
（キ）詳細テーブル「期分けＩＤ」フィールドの，広告テーブル「期分けＩＤ」，住戸一般テーブル「期分けＩＤ」，申込テーブル「期分けＩＤ」，月報タイプテーブル「期分けＩＤ」，月報価格テーブル「期分けＩＤ」の各フィールドとの関連付け（ク）住戸一般テーブル「間取り」フィールドの，ＴＹＰＥテーブル「ＴｙｐｅＣｏｄｅ」フィールドとの関連付け
（ケ）広告テーブル「媒体名」フィールドの，ＰＡＰＥＲテーブル「ＢＣＯＤＥ」フィールドとの関連付け
（コ）月報タイプテーブル「間取りコード」フィールドの，ＴＹＰＥテーブル「ＴｙｐｅＣｏｄｅ」フィールドとの関連付け
（サ）月報価格テーブル「価格帯コード」フィールドの，ＫＡＫＡＫＵテーブル「ＫａｋａｋｕＣｏｄｅ」フィールドとの関連付け
（２）そこで，原告データベース被複製部分の創作性について検討するに，被複製部分のテーブルの項目の内容（種類及び数），各テーブル間の関連付けのあり方についてみると，この部分だけでも，ＰＲＯＪＥＣＴテーブル，詳細テーブル等の７個のエントリーテーブルと法規制コードテーブル等の１２個のマスターテーブルを有し，エントリーテーブル内には合計２２９のフィールド項目を，マスターテーブル内には６８のフィールド項目を有しており，期分けＩＤ等によって有機的に関連付けられていて，十分効率的に必要とする情報を検索することができるといえる。
すなわち，客観的にみて，原告データベース被複製部分のみをとっても，新築分譲マンション開発業者等が必要とする情報をコンピュータによって効率的に検索できるようにするために作成された，膨大な規模の情報分類体系といわなければならず，このような規模の情報分類体系を，情報の選択及び体系的構成としてありふれているということは，到底できない。
ＭＲＣ社のデータベースが含む構造（別紙図３），不動産月報（乙１），不動産の表示規約（乙３３），株式会社東京カンテイの新築マンション詳細情報（１）（乙３４）等と比較精査しても，原告データベース被複製部分に類する情報分類体系が存在するとは認められない。
したがって，原告データベースのうち被告データベースと共通する情報及び構成が著作物性を認めるに足りる創作性を有するといって妨げない。
４結論
以上によれば，被告データベースは原告データベースを複製したものであり，原告の有する同データベースの著作権（複製権）を侵害するものと認めるのが相当である。
よって，中間判決として主文のとおり判決する。

自己破産の豆知識なら「自己破産ドットコム」

自己破産は、借金超過で苦しんでいる人を救済し、再び立ち直るチャンスを与えるために国が作った制度です。
そのため、一般の方が考えているほどの不利益があるわけではなく、当然財産は没収されますが、免責さえ受けてしまえば7年程度の間はローンやクレジットの利用ができなくなるということ以外のデメリットはありません。
自己破産の同時破産廃止とは、認定を受けた司法書士等の法律専門家が債務者（借主）本人の現住所地を管轄する地方裁判所に申し立てをおこない、多重債務に陥り支払い不能な状態や極めて返済が困難な状況にあり、換価分配（換金して債権者に配当）する財産が無いことが明らかで破産管財人費用等の予納金も捻出できず、重大な免責不許可事由にも該当しない債務者に対し、破産手続開始決定（破産宣告）と同時に破産手続きを廃止し免責を受け全ての借金を清算して生活再建の機会を与える債務整理を指します。
自己破産をする時には弁護士に依頼をするのがベストです。
自己破産の豆知識なら「自己破産ドットコム」(http://hasan-soudan.jp/)。
きっとあなたの明日を明るいものへしてくれるはずです。

過払い金で相談をしたい人、必見！

消費者金融との付き合いも長いから自分にも過払い金が発生しているのでは？と思っている方や、過払い金の請求はどうしたらいいのかなぁ、なんて悩んでいる方、必見！
過払い金ドットコム→(http://kabarai-soudan.jp/)は、そんな過払い金に関する基礎知識から、過払いの問題に強い法律事務所の検索サイト。
どの先生も過払い請求に豊富な実績があるので、安心です。
取引履歴を取り寄せて引き直し計算をして・・・とかしている暇があるなら、さっさと弁護士に依頼をしましょうね★

借金問題や借金返済で弁護士に相談をするなら

「借金返済・債務整理ドットコム→(http://hensai-soudan.jp/)」をご存じですか。
任意整理・個人再生・自己破産など、債務整理の実績豊富な弁護士や司法書士の事務所情報が盛りだくさんのサイトなんです。
借金返済や借金問題の解決にすごくお役に立てるサイトです。
他にも債務整理の基礎知識も掲載しているので、相談をする前に自分で勉強をしたい人にもお勧めです。
勇気を出して専門家に相談して、借金を整理して、借金のない人生をもう一度歩み出して下さい。

相続　法律相談なら

相続とは、人間の死後に、その人が有した遺産を、特定の人に承継させることを指す。
一般的には、自然人の死亡を原因とするものを相続と称することが多いが、死亡を原因としない生前相続の制度（日本国憲法が施行される前の日本における家督相続は、死亡を原因とする場合もしない場合も含む）も存在する。
亡くなった人を「被相続人」、権利義務を承継する人を「相続人」といい、人の死亡によって相続が発生することを「相続の開始」という。
相続に関する規定には遺言により民法の規定と異なる定めをすることができる任意規定が多く含まれる一方、遺留分規定のように遺言での排除を許さない強行規定も存在する。
相続　法律相談なら「相続相談ドットコム→(http://sozoku-soudan.jp/)」

価値あるサイト売買｜プレミアM＆A

不要なサイトの処分に困ったらプレミアM&A。
そのサイトの価値を最大限に評価して高値で買い取ってくれる業者を探してくれます。
今は特にECサイトが高値で売れる傾向が。
決算対策として売上が付きやすいためでしょうか。
「プレミア M＆A」で価値あるサイト売買。(http://premierma.co.jp/)
不要なドメインの処分に是非！

質問を検索