戻る

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

戻る