判例全文

【事件名】トラベル管理ソフト「旅行業システムＳＰ」事件 【年月日】平成２６年３月１４日 　東京地裁　平成２１年（ワ）第１６０１９号　著作権侵害差止等請求事件 　（口頭弁論終結日　平成２５年１１月２９日） 判決 　当事者　別紙当事者目録記載のとおり 主文 １　被告アゼスタは、別紙被告物件目録記載１ないし２１の各データベースを複製し、頒布し又は公衆送信（送信可能化を含む。）してはならない。 ２　被告アゼスタは、別紙被告物件目録記載１ないし２１の各データベースを格納したＣＤ−ＲＯＭ等の記録媒体を廃棄し、同各データベースの記録内容を消去せよ。 ３　被告アゼスタ、被告Ｙ１、被告Ｙ２、被告Ｙ３及び被告Ｙ４は、原告に対し、連帯して、１億１２１５万１０００円及びうち７６８０万８０００円に対する平成２１年５月２８日から、うち３５３４万３０００円に対する平成２３年１１月２日から、各支払済みまで年５分の割合による金員（ただし、１億０５４８万円及びうち７０１３万７０００円に対する平成２１年５月２８日から、うち３５３４万３０００円に対する平成２３年１１月２日から、各支払済みまで同割合による金員の限度で被告Ｙ６と、５５６１万２０００円及びこれに対する平成２１年５月２８日から支払済みまで同割合による金員の限度で被告Ｙ５と、それぞれ連帯して）を支払え。 ４　被告Ｙ６は、原告に対し、被告アゼスタ、被告Ｙ１、被告Ｙ２、被告Ｙ３及び被告Ｙ４と連帯して、１億０５４８万円及びうち７０１３万７０００円に対する平成２１年５月２８日から、うち３５３４万３０００円に対する平成２３年１１月２日から、各支払済みまで年５分の割合による金員（ただし、４９４４万１０００円及びこれに対する平成２１年５月２８日から支払済みまで同割合による金員の限度で被告Ｙ５と連帯して）を支払え。 ５　被告Ｙ５は、原告に対し、被告アゼスタ、被告Ｙ１、被告Ｙ２、被告Ｙ３及び被告Ｙ４と連帯して、５５６１万２０００円及びこれに対する平成２１年５月２８日から支払済みまで年５分の割合による金員（ただし、４９４４万１０００円及びこれに対する平成２１年５月２８日から支払済みまで同割合による金員の限度で被告Ｙ６と連帯して）を支払え。 ６　原告のその余の請求をいずれも棄却する。 ７　訴訟費用は、これを８分し、その７を原告の、その余を被告らの負担とする。 ８　この判決は、第１項、第３項ないし第５項に限り仮に執行することができる。 事実及び理由 第１　請求の趣旨 １　被告らは、別紙被告物件目録記載の各データベースを複製、翻案、頒布及び公衆送信（送信可能化を含む。）してはならない。 ２　被告らは、別紙被告物件目録記載の各データベースを格納したＣＤ−ＲＯＭ等の記録媒体を廃棄し、同各データベースの記録内容を消去せよ。 ３　被告らは、原告に対し、連帯して、９億１０３７万０９７８円及びうち５億５３４９万６０００円につき平成２１年５月２８日（被告Ｙ６に対する訴状送達の日の翌日であり被告Ｙ６以外の被告らに対する訴状送達日の翌日以降の日）から、うち１億１８５９万３６００円につき平成２３年１１月２日（平成２３年１０月７日付け訴えの変更の申立書送達の日の翌日）から、うち２億３８２８万１３７８円につき平成２５年１月３１日（平成２５年１月２８日付け訴えの変更申立書送達の日の翌日）から、各支払済みまで年５分の割合による金員を支払え。 ４　訴訟費用は被告らの負担とする。 ５　仮執行宣言 第２　事案の概要 　本件は、原告に吸収合併される前の訴外株式会社ブロードリーフ（以下「旧原告会社」という。なお、原告は、旧原告会社を平成２２年１月１日に吸収合併するとともに商号を旧原告会社と同名に変更したものである。）が、訴外翼システム株式会社（以下「翼システム」という。）から営業譲渡に伴い著作権等の譲渡を受けた、別紙原告物件目録記載のデータベース部分（以下「原告ＣＤＤＢ」という。なお、「ＣＤＤＢ」はＣＤで提供されるマスターテーブルによるデータベースの趣旨である。）を含む旅行業者向けシステム「旅行業システムＳＰ」（旧製品名「スーパーフロントマン 旅行業システム」。以下、この旧製品名のものも併せて「原告システム」という。）につき、その開発、営業等を担当していた旧原告会社の社員であった被告Ｙ２、被告Ｙ３、被告Ｙ４、被告Ｙ５、被告Ｙ６らが、旧原告会社を退職した後、被告Ｙ１らと共に被告アゼスタを設立し、あるいは同社に入社して、別紙被告物件目録記載１ないし２２の各検索及び行程作成業務用データベース（以下、これらデータベースを総称して「被告ＣＤＤＢ」という。）を含む旅行業者向けシステム「旅nesPro」（以下「被告システム」という。）を制作し、顧客らに販売するに当たり、被告システムに含まれる被告ＣＤＤＢを複製・頒布等する行為について、(1)原告ＣＤＤＢについて原告が有する著作権（複製権、翻案権、譲渡権、貸与権、公衆送信権）を侵害するものであるとして、著作権法１１２条１項に基づき、被告らに対し、被告ＣＤＤＢの複製、翻案、頒布、公衆送信（送信可能化を含む。）の差止め（請求の趣旨１項）、(2)著作権法１１２条２項に基づき、被告らに対し、被告ＣＤＤＢを格納したＣＤ−ＲＯＭ等の記録媒体の廃棄とその記録内容の消去（請求の趣旨２項）、(3)損害賠償として、被告らに対し、連帯して、主位的に、著作権法１１４条１項、民法７０９条に基づき、予備的に一般不法行為として民法７０９条に基づき、９億１０３７万０９７８円及びうち５億５３４９万６０００円につき訴状送達の日の翌日以降の日である平成２１年５月２８日から、うち１億１８５９万３６００円につき平成２３年１０月７日付け訴えの変更の申立書送達の日の翌日である平成２３年１１月２日から、うち２億３８２８万１３７８円につき平成２５年１月２８日付け訴えの変更の申立書送達の日の翌日である平成２５年１月３１日から、各支払済みまで民法所定の年５分の割合による遅延損害金の支払（請求の趣旨３項）、をそれぞれ求めたものである。 １　前提事実（証拠等の摘示のない事実は当事者間に争いがない。なお、書証の枝番号は、特に記載しない限り省略する。以下、同様である。） (1)　当事者 ア　原告（旧原告会社を含む） 　旧原告会社は、翼システムの関連会社として、旧商号をアイ・ティー・エックス翼ネット株式会社とし、平成１７年１２月１６日に設立された、コンピュータソフトウェアの開発、販売、情報提供サービス、情報処理サービス等を業とする会社である。旧原告会社は、平成１８年８月１日、商号を株式会社ブロードリーフと変更した。〔甲８１〕 　原告は、平成２１年９月１６日に設立されたところ（現在の商号への変更前の商号は「シー・ビー・ホールディングス株式会社」）、本件訴え提起後の平成２２年１月１日に、旧原告会社を吸収合併し、訴訟を承継した。 イ　被告ら (ア)　被告アゼスタは、平成１７年１０月１８日に設立されたコンピュータシステムの開発、各種情報提供サービス、各種情報処理サービス等を業とする株式会社である。被告アゼスタの従業員は平成２２年９月時点で１０名であり、その取扱商品は、被告システムのほかは、本件訴え提起（平成２１年５月１５日）の後である平成２１年１０月に販売を開始した貸切バスの予約、配車、運行管理システムである「バス快道」のみである。〔甲１１（別紙２）、２５の２〕 　被告アゼスタは、東京都中央区に本社を置くほか、大阪市西区に大阪支店を、福岡市博多区に福岡支社を置いている。〔甲８０〕 (イ)　被告Ｙ１は、被告アゼスタの設立当初からの代表取締役である。同被告は、旧原告会社に在籍していたことはない。 (ウ)　被告Ｙ２は、翼システム及び旧原告会社において原告システムの営業等を担当していた者であるところ、平成１８年２月１５日に旧原告会社を退職して被告アゼスタに転職し、営業を担当している。同被告は、平成１９年１２月以来、被告アゼスタの取締役である。〔甲６２、乙４０〕 (エ)　被告Ｙ３は、翼システム及び旧原告会社において原告システムの営業等を担当していた者であるところ、平成１８年２月２８日に旧原告会社を退職して被告アゼスタに転職し、営業を担当している。同被告は、平成１９年１２月以来、被告アゼスタの取締役であり、営業グループのマネージャーである。〔甲６２、乙４１〕 (オ)　被告Ｙ４は、翼システム及び旧原告会社において原告システムの営業を担当していた者であるところ、平成１８年３月１５日に旧原告会社を退職して被告アゼスタに転職し、営業を担当している。同被告は、現在被告アゼスタの従業員である。 (カ)　被告Ｙ５は、翼システム及び旧原告会社において原告システムの開発を担当していた者であるところ、平成１８年６月１５日に旧原告会社を退職し、被告アゼスタに転職して開発を担当していたが、平成２０年６月に被告アゼスタを退職した。同被告は、現在は、コンピュータソフトウェアの開発業務を行っている。〔乙３９〕 (キ)　被告Ｙ６（以下、被告アゼスタを除く、被告Ｙ１、被告Ｙ２、被告Ｙ３、被告Ｙ４、被告Ｙ５及び被告Ｙ６を、併せて「個人被告ら」という。）は、翼システム及び旧原告会社において原告システムの営業を担当していた者であるところ、平成１８年１１月３０日に旧原告会社を退職して被告アゼスタに転職し、営業を担当している。同被告は、現在被告アゼスタの従業員であり、被告アゼスタの福岡営業所（福岡支社）の所長である。〔乙４２〕 (ク)　被告アゼスタの代表取締役は被告Ｙ１ １人であり、取締役は被告Ｙ１、被告Ｙ２、被告Ｙ３の３名のみである。 (2)　原告システムの大要 ア　原告システムは、旧原告会社が設立される以前の平成８年１月に、翼システムが制作して販売を開始した「スーパーフロントマン　旅行業システム」を基本として、その後、翼システムにおいて改良されてきたものである。原告システムについては、平成１７年１２月３０日に、同月１６日に設立された旧原告会社が翼システムから原告システムを含むパッケージソフトウェアに関する営業の譲渡を受けるとともに、その著作権等の譲渡を受けた（なお、翼システム時代と、旧原告会社に譲渡された後を通じ、特に区別せず「原告システム」という。）。また、上記営業譲渡に伴い、原告システムの開発、営業等に携わってきた翼システムの従業員である、被告Ｙ２、被告Ｙ３、被告Ｙ４、被告Ｙ５、被告Ｙ６らは、翼システムから旧原告会社に移籍した。 イ　原告システムは、国内旅行の旅行行程表、見積書作成のために必要な観光施設、宿泊施設、道路、時刻表などの各種データをデータベース化し、パソコンを用いて効率よく行程表、見積書等を作成することを可能とする旅行業者用システムである。旅行業者は、顧客の要望に合わせ、原告システムを用い、パソコンの画面表示に従って、出発地、帰着地、観光・宿泊施設、交通手段等を検索して選択すると、経路や所要時間等を原告システムにおいて自動的に検索して計算した上で、行程表や見積書も自動的に作成することができる。 ウ　原告ＣＤＤＢは、地図ソフト（株式会社クレオ〔旧商号・株式会社アルプス社〕のプロアトラス）との連動により、観光・宿泊施設の所在地情報や旅行行程の経路を地図上へ表示する機能を実現するための設計や、インターネットとの連動により観光・宿泊施設のホームページへのアクセスを容易にする設計など、旅行業者の業務用データベースとして、機能性やユーザーの利便性の拡充を図るための工夫がされたデータベースである。 エ　商品としての原告システムの種類としては、検索業務、行程表・見積書作成、インターネット連動、地図連動機能を含むＴＲ−Ｐ１のほか、これに加え、さらに売上集計管理、顧客管理機能をも含むＴＲ−Ｐ４がある。〔甲１の１〕 オ　原告システムのカタログ（２００９年〔平成２１年〕版）によれば、検索業務、行程・見積作成の各機能の内容には、以下のものが含まれている。〔甲１の１〕 　（検索業務） 　時刻表検索、観光施設検索、宿泊施設検索、道路料金経路検索、インターネット検索、画像保存、地図検索。 　（行程・見積作成） 　行程表作成、見積書作成、損益検討書作成、受注型企画旅行見積書、包括見積書作成、修学旅行見積書、利用施設一覧印刷、観光施設案内書印刷、宿泊施設案内書印刷、添乗指示書作成、現地払い見積書、契約書（受注型・手配型）、Ｍａｉｌ送信（ＰＤＦ）、画像付き行程表出力。 カ　原告ＣＤＤＢを含む原告システムで利用するデータベースは、米国のパベイシブ・ソフトウェア・インク（Pervasive Software Inc.なお、旧称Btrieve Technologies Inc.）が販売するデータベースソフト「Btrieve（ビートリーブ）」（以下「ビートリーブ」という。）を用いて作成されている。ビートリーブにおいては、固有のデータアクセス言語であるＡＰＩが使用されている。〔甲２、１５頁〕 ビートリーブで構築、維持されるデータベースは、データベースの情報の単位であるレコードを、別のレコードと関連付ける処理機能を持つものである。 (3)　データベースについての一般的な説明及び正規化について ア　データベースにおいては、入力される情報は行と列から構成されるテーブルと呼ばれる表に格納される。テーブルは、二次元の表を使って表現されるが、この二次元のテーブル内を構成する縦の列と横の行のうち、縦の列は、これ以上細分化できない情報の集合であり、個々のデータの属性を表すものとして、「フィールド（アトリビュート、カラム）」と呼ばれている。各フィールド項目（列）においては、格納されるデータの種類及び型（テキスト、数値、通貨、Yes/No など）が決められている。 　一つのテーブルの中には複数のフィールドが存在しているのが通常であるが、一つのテーブル内に重複して同じフィールド名を付けることはできず、一つのフィールド内にデータを格納するに当たって、異なる属性のデータを複数混在させて格納することもできないから、必ず同一の属性を持ったデータのみを格納しなければならないという制約がある。 　テーブルの、上記二次元の表としてそのテーブル内を構成する縦の列と横の行のうち、横の行は、データベースを利用するユーザーが、最小単位の格納データとして検索等の操作をすることができる１件分のデータを意味し、これは「レコード」と呼ばれる。 　そして、複数のテーブル同士を関連付けてデータの検索を行うタイプのデータモデルにおいては、データ検索時にテーブル内の検索したいレコードを他のレコードから識別するための情報を、「キー」として設定する必要がある。そして、テーブル内のレコードを一意的に識別できるフィールドを「候補キー」といい、この候補キーの中から任意に選んだフィールドを、一つのテーブル内に一つだけ、「プライマリー・キー（主キー）」として設定する必要がある。 　具体的にどの候補キーをプライマリー・キーとするかについては、どの情報を管理したいのかというテーブル設計の目的によって、プライマリー・キーとして適当とされる候補キーは限定されることとなる。 　そして、複数のテーブルがそれぞれ関係づけられることなく個々に存在しているのであれば、紙媒体の資料と異ならないこととなり、重複した内容があちこちに記載されている個々のテーブル内のデータをコンピュータ上の画面に複数立ち上げて、データの照合と統合作業を地道に行っていくこととなってしまい、データベースとしての価値がないことになる。そこで、複数のテーブル内に分散して格納されている個々のデータを、必要な時に必要な分だけ効率的に読み出し、これらのデータを統合・集計して、ユーザーが最終的に必要とする結果としてのデータのみを、コンピュータ上の画面に表示させるような仕組みが必要となる。この一連の作業を実行させるため、複数存在しているテーブル間を何らかの法則を使って関連付けしておくことが必要となり、この各テーブル間の関連付けのことを「リレーション」という。 　具体的には、データベース開発者が、データベースの設計を行う際に、ユーザーが最終的に必要とする多数の検索結果を想定し、そのような検索結果を導き出すために相互に関連付けておきたいと考える各テーブルの内部に、同じ属性を持つデータが格納される共通のフィールドを事前に設定しておき、これらのテーブル間にリレーションを持たせることになる。これにより、相互のテーブル内の他のフィールド内に格納されている異なる性質のデータを自由に呼び出し、あたかも一つのテーブル内の情報を取り扱うのと同様にこれらのデータを統合・集計して、ユーザーが最終的に必要とする結果を、コンピュータ上の画面に一括して表示することができる。なお、これらのリレーション関係を持たせるフィールド同士は、必ずしも同一のフィールド名である必要はなく、フィールド内に格納されている実際のデータの属性が同一であれば、リレーションを持たせることができる。〔甲２〕 イ　原告ＣＤＤＢに限らず、データベースにおいては、一般に、バージョンアップ等、見直しが行われる際に、「正規化」が検討されるのが通常である。「正規化」とは、主に、複数のテーブル同士を関連付けてデータの検索を行うタイプのデータモデルにおいて、各テーブル内に格納されている重複した無駄なデータを排除することで冗長度を減らし、効率的なデータアクセスを可能とする冗長性の排除を目的とする作業、及び、関連性の高いデータ群だけを別のテーブルに分離させることで当該データ群の独立性を高め、各テーブル内に格納されているデータの更新を行う際にデータ間で不整合が起こらないようにする不整合性の回避を目的とする作業のことをいう。〔甲２〕 (4)　翼システム、旧原告会社における被告Ｙ１を除く個人被告らの行為等 　被告Ｙ１を除く個人被告らは、いずれも翼システムの社員であったところ、平成１７年１２月３０日における翼システムから旧原告会社への原告システムを含む営業譲渡とともに、旧原告会社に移籍した者であるが、翼システム当時の原告システムへの関与の大要は、以下のとおりである。 ア　被告Ｙ５は、平成２年４月２２日、翼システムに入社し、それまでにプログラミングの知識・経験を有していたことから、電装システムの設計、検収等の業務を行ってきたが、平成６年４月ころに、翼システムにおいて、原告システムの開発が決まると、そのプロジェクトのリーダーとなり、旅行代理店へのヒアリング、要件定義、システム設計、データベースの設計・開発、スケジュール管理、営業・サポートへの指導・支援など、旧原告会社の退社に至るまで多岐にわたる業務をこなし、当初から原告システムの制作に携わった者として、原告システムの内容を熟知していた。〔乙３９、１頁〕 イ　訴外Ａ（以下「Ａ」という。）は、平成７年７月１日に翼システムに入社し、被告Ｙ５の下でサブリーダーとなるとともに、原告システムについてのプログラマーとして参加し、データ加工等を行った。その後、原告システムの開発リーダーとなり、原告システムの開発・改良の責任者として、旅行代理店へのヒアリング、要件定義、システム設計、データベースの設計・開発、スケジュール管理、営業・サポートへの指導・支援など多岐にわたる業務をこなし、翼システム内部においても、被告Ｙ５とともに、原告システムの内容を最も熟知していた。〔乙３８、２頁〕 ウ　被告Ｙ２は、平成８年２月１６日に翼システムに入社し、原告システムの販売やサポートに当たり、その主任を務めていた。 エ　被告Ｙ３は、平成８年１２月１６日に翼システムに入社し、原告システムのシステムサポートを行うとともに、その営業を担当していた。 オ　被告Ｙ６は、平成９年１月６日に、被告Ｙ４は、平成９年１２月２４日に、それぞれ翼システムに入社し、原告システムの営業を担当していた。〔甲７８〕 (5)　被告Ｙ１を除く個人被告らの旧原告会社の退社と、被告Ｙ１らによる被告アゼスタの設立 ア　被告アゼスタは、平成１７年１０月１８日に設立され、出資金の過半を拠出した被告Ｙ１がその代表取締役に就任した。 イ　Ａは、平成１６年７月末、翼システムを退社し、その後、別会社に勤務した後、平成１７年１１月に被告アゼスタに入社し、平成１９年１２月２５日から被告アゼスタの監査役に就任した。〔甲６２〕 ウ　被告Ｙ２は、平成１８年２月１５日に、被告Ｙ３は、同月２８日に、それぞれ旧原告会社を退社した。 エ　被告Ｙ４は、平成１８年３月１５日に、被告Ｙ５は、平成１８年６月１５日に、それぞれ旧原告会社を退社した。 オ　被告Ｙ６は、平成１８年１０月末まで旧原告会社において原告システムの営業に関与した後に退社し、被告アゼスタに入社した。 (6)　被告システムの大要 ア　被告システムは、平成１８年（２００６年）６月に販売を開始したところ、観光・宿泊施設検索、行程表作成、見積書作成、原価計算等を行う営業ツールシステム、請求書作成、入金未収金管理、支払管理、各種集計表、顧客管理からなる管理業務システム等からなる。〔甲２５の２〕 イ　被告ＣＤＤＢには、被告システムのVer1.0向けのもの（被告物件目録記載１。以下「当初版」という。）、被告システムVer1.5向けのもの（被告物件目録記載２。以下「２００６年版」という。）、被告システムVer2.0からVer3.1向けのもの（被告物件目録記載３〜２１。以下、これらを併せて「現行版」といい、そのうちのバージョンを特定する必要のあるもののみ、被告システムないし被告ＣＤＤＢのバージョンとして記載する。）、被告システムVer3.2向けのもの（被告物件目録記載２２。以下「新版」という。）がある。なお、検索及び行程作成業務用データベースである被告ＣＤＤＢとしては、当初版及び２００６年版は同じものとなっている（以下、併せて「当初版・２００６年版」ということがある。その意味では、別紙被告物件目録記載１と同２の被告ＣＤＤＢは、内容としては同一である。）。 ウ　被告ＣＤＤＢを含む被告システムで利用されるデータベースは、Microsoft社のSQL Server（以下「SQLサーバー」という。）を用いて作成されている。SQLサーバーはリレーショナル・データベースを開発、維持するために用いられるデータベースソフトであり、テーブル、フィールドを設定し、テーブル間をプライマリー・キーや候補キー等によって関係づけてデータベースを構築・維持するものである。 エ　原告ＣＤＤＢに用いられているビートリーブと被告ＣＤＤＢに用いられているSQLサーバーを比較すると、ビートリーブはナビゲーショナル型データベースに、SQLサーバーはリレーショナル型データベースに属するとされるところ、多数のデータが含まれている集合図をエクセルシートのような行と列からなる二次元の表で表現し、特定の表と表とを共通の項目であるキーを使って数学的・論理的に繋げることを意味する「リレーション」を構築することにより、表と表との相関関係を簡単に表現するという点で、同様のデータベースソフトである。ただし、両者では、テーブル内に格納されている個々のデータの読取り手順が異なる。すなわち、ナビゲーショナル型データベースでは、レコード指向アクセス方式が採用されており、テーブル内にある特定のレコードに格納されているデータを検索する際、レコードが存在するテーブルにアクセスし、そのレコードの位置を確認して、１レコードずつデータを取り出すというアクセス方式を採用しており、そのため、レコード指向アクセス方式において複数テーブル内の複数レコードに格納されている複数のデータを検索して取り出したい場合には、上記のような読取り手順を、１レコードごとに何度も繰り返すことで、１レコードずつ取り出してくる必要がある。これに対し、リレーショナル型データベースで採用されているセット指向アクセス方式では、複数テーブル内の複数レコードに格納されている複数のデータを取り出したい場合であっても、読出し条件さえ事前に設定しておけば、検索目的となっている複数データを、同時に一括して取り出してくることができるものとなっている。アクセス方法が異なれば、検索を実行するためのアプリケーションのロジックの組み立て方も異なることになるが、既に完成しているデータベースの全体構造の中に格納されている個々のデータを、どのような手順でどのように読み取っていくかという方法が異なるのみであり、アクセス方式の違い自体が、データベースの全体的構造に影響を与えるものではない。〔甲２〕 オ　被告システムでは、地図ソフトは株式会社クレオのプロアトラスＳＶと連動していた。また、被告ＣＤＤＢでは、被告システムの平成１８年６月の販売当初から、経路探索ソフトである「駅すぱあと（株式会社ヴァル研究所）」と連動させていたため、基本的に列車等の情報に関するデータについては、フェリーの情報などを除き不要となるものであった。そのため、列車等の情報をデータベース内に格納していない時期がある。具体的には、被告ＣＤＤＢ（当初版・２００６年版）にはなかった「４３路線マスタ」、「４４便マスタ」、「４５時刻マスタ」、「４６路線構成マスタ」の各テーブルを、被告ＣＤＤＢ（現行版）で設けるに至った。〔甲２３〕 (7)　原告システム及び原告ＣＤＤＢの概要 ア　原告システムのテーブルは、マスターテーブルとエントリーテーブルからなる。マスターテーブルとは、最終的にユーザーが必要とする検索結果を作成するための基礎となるデータを格納しておくテーブルのことであり、データベースの提供時点で、基礎情報が予め格納されている提供マスターテーブルと、付加価値情報をユーザーが任意に後から格納していくことができるユーザーマスターテーブルとを含む。一方、エントリーテーブルとは、データベースの提供時点においてはいまだデータが格納されていない空のテーブルと、フィールドのみを枠組みとして用意しておき、システムを利用する過程において、ユーザー自身の行為を通じてテーブル内にユーザーのオリジナルデータが徐々に蓄積されていく形式をとるテーブルである。〔甲２、２〜３頁〕 イ　原告システムを使用するユーザーである旅行業者は、マスターテーブル内に格納されたデータを使って検索した結果を利用して顧客向けの行程表を作成し、作成した行程表データは、ユーザー用のエントリーテーブル内に蓄積されることになる。 ウ　原告ＣＤＤＢの内容としては、原告システムのうち、顧客情報関連のテーブル、部課・担当者関連のテーブル、仕入先関連のテーブル、システム内部で使用するにすぎないテーブル（科目テーブル、旅行種別テーブルなど）、クーポン関連のテーブルなど、原告が提供するマスターテーブルと直接リレーションのないエントリーテーブルが除かれるほか、原告システムのマスターテーブルには存在するが原告ＣＤＤＢには含まれないものとして、以下のテーブルがある。 (ア)　原告システムが原告ＣＤＤＢを介さずに直接参照するテーブルであり、原告ＣＤＤＢとリレーションをもってデータベースを構成しているものではないもの ・郵便番号テーブル（テーブルＩＤ；ＴＲＶＺＩＰ） ・ロード用地点テーブル（テーブルＩＤ；ＴＲＶＲＯＡＤＫ） ・メッセージテーブル（テーブルＩＤ；ＴＲＶＭＳＧ） ・メッセージボックス管理テーブル（テーブルＩＤ；ＴＲＶＭＳＧＢＸ） ・ファイル名が「ＴＲＶＤＭＭ」であるテーブル（乙２３別紙３で行Ｎｏ．６１、テーブルＩＤ不明とされているテーブル） (イ)　原告システムの開発途上で作成されていたが、結局利用の予定がないことから、未完成のまま残っていたことを理由として、原告システムにおいて参照されることがないもの ・ランドマークテーブル（テーブルＩＤ；ＴＲＶＲＤＭＫ） ・ランドマーク種別テーブル（テーブルＩＤ；ＴＲＶＲＤＭＫＣ） ・接続索引１テーブル（テーブルＩＤ；ＴＲＶＲＯＡＤＨ） ・接続索引２テーブル（テーブルＩＤ；ＴＲＶＲＯＡＤＪ） ・接続索引３テーブル（テーブルＩＤ；ＴＲＶＲＯＡＤＮ） ・接続索引４テーブル（テーブルＩＤ；ＴＲＶＲＯＡＤＯ） ・ＪＲ繁忙閑散期定義テーブル（テーブルＩＤ；ＴＲＶＪＲＡ） ・ＪＲ普通運賃表テーブル（テーブルＩＤ；ＴＲＶＪＲＢ） ・ＪＲ新幹線特急料金表テーブル（テーブルＩＤ；ＴＲＶＪＲＣ） ・ＪＲ特急グリーン等料金表テーブル（テーブルＩＤ；ＴＲＶＪＲＤ） ・ＪＲ特急区分定義テーブル（テーブルＩＤ；ＴＲＶＪＲＥ） ・ＪＲ特急都区市内駅定義テーブル（テーブルＩＤ；ＴＲＶＪＲＦ） ・観光施設ＩＤテーブル（テーブルＩＤ；ＴＲＶＳＴＩＤ） ・海外地区・方面テーブル（テーブルＩＤ；ＴＲＶＦＲＧＰＴ） エ　原告ＣＤＤＢのマスターテーブルのテーブルＩＤと各テーブルの概要は、別紙１記載のとおりである（以下、単に「テーブル」という場合には、原告ＣＤＤＢ、被告ＣＤＤＢを問わず、「マスターテーブル」をいうものとする。なお、別紙１原告ＣＤＤＢのテーブルについて、緑塗りの表記がされているテーブルは、被告ＣＤＤＢに一致するテーブルの存在が認められるものである。）。テーブル名は、各テーブルＩＤで識別されるテーブルの概要に基づき、整理の便宜のために付したものであり、テーブル番号も同様である（なお、別紙１では、テーブル番号は、被告ＣＤＤＢとの対応関係の便宜等のため、２３〜２７番を欠番としている。以下、各テーブルについては、特にテーブルＩＤを記載しない限り、別紙１記載のテーブル番号とテーブル名で表記する。ただし、後記のとおり、テーブルＩＤをＴＲＶＳＴＫＭＫとするものをテーブル番号及びテーブル名「２３観光施設種別テーブル」と、テーブルＩＤをＴＲＶＳＴＳＭとするものをテーブル番号及びテーブル名「２４観光施設検索タイトルテーブル」として言及する場合がある。これらは、原告が、原告システムのインストール時にＣＤ以外で提供しているテーブルであり、ＣＤで提供されるマスターテーブルを構成するものではないことから、原告ＣＤＤＢには含まれていない。）。 オ　また、原告ＣＤＤＢにおける各テーブルに存在するフィールドは、別紙３記載のとおりであり、上記テーブルの場合と同じく、各フィールド自体は各フィールドＩＤで識別されるところ、整理の便宜のためにフィールド名を付したものである。以下、各フィールドについても、特にフィールドＩＤを記載しない限り、別紙３記載のフィールド名のみで表記するか、これと併せてテーブル番号ないしフィールドＩＤで表記する。 カ　原告ＣＤＤＢにおけるレコード数については別紙４記載の、原告ＣＤＤＢにおけるフィールド間のリレーションのとり方は別紙５記載（原告ＣＤＤＢにおけるリレーションについては別紙６、７も同内容）のとおりである（なお、被告ＣＤＤＢと一致することに争いのある原告システムにおけるテーブル、フィールドの存在についての判断は後記のとおりである。）。 (8)　被告システム及び被告ＣＤＤＢの概要 ア　被告システムのテーブルも、マスターテーブルとエントリーテーブルからなるところ、被告ＣＤＤＢのマスターテーブルのＩＤは、別紙２の該当欄記載のとおりである（被告ＣＤＤＢについても、テーブル番号及びテーブル名は、各テーブルＩＤで識別されるテーブルに含まれるフィールド等の概要に基づき、整理の便宜のために番号と名を付したものであり、各テーブルについて、特にテーブルＩＤを表記しない限り、別紙２記載のテーブル番号とテーブル名で表記する。なお、別紙２記載のテーブル名の括弧内の記載は省略する場合がある。）。 イ　被告ＣＤＤＢにおける各テーブルのフィールドは、別紙３記載のとおりであり、各フィールド自体は各フィールドＩＤで識別されるところ、整理の便宜のためにフィールド名を付したものである。以下、各フィールドについても、特にフィールドＩＤを記載しない限り、別紙３記載のフィールド名のみで表記するか、これと併せてテーブル番号ないしフィールドＩＤで表記する（フィールド名の括弧内の記載は省略する場合がある。）。 ウ　被告ＣＤＤＢにおけるレコード数については別紙４記載の、被告ＣＤＤＢにおけるフィールド間のリレーションのとり方は、当初版・２００６年版、現行版、新版につき、それぞれ別紙８、９、１０各記載のとおりである（なお、原告ＣＤＤＢと一致することに争いのある被告ＣＤＤＢにおけるテーブル、フィールドの存在、及び存在に争いのあるフィールド間のリレーションのとり方についての判断は後記のとおりである。）。 ２　争点 (1)　原告ＣＤＤＢの著作物性及び被告ＣＤＤＢが原告ＣＤＤＢに依拠して作成された複製物ないし翻案物といえるか (2)　被告らによる著作権（複製権、翻案権、譲渡権、貸与権、公衆送信権、送信可能化権）侵害についての共同不法行為の成否 (3)　一般不法行為の成否（予備的主張） (4)　原告の行為の私的独占の禁止及び公正取引の確保に関する法律（以下「独占禁止法」という。）違反の可能性の有無 (5)　被告らの損害賠償義務の有無及び原告の損害額 第３　争点に関する当事者の主張 １　争点(1)（原告ＣＤＤＢの著作物性及び被告ＣＤＤＢが原告ＣＤＤＢに依拠して作成された複製物ないし翻案物といえるか）について 〔原告の主張〕 (1)　原告ＣＤＤＢの著作物性について ア　原告ＣＤＤＢは、旅行業者が原告システムを使って行程表作成の業務を行うに当たって必要となる情報を選択して、観光施設データ、宿泊施設データ、全国各地の主要道路の道路地点、隣接する道路地点間の大型観光バスの移動時間・距離、有料道路・高速道路の料金データ、鉄道・飛行機・フェリーに関する路線、駅、時刻表等の様々な情報を多項目にわたって収集・蓄積した情報の集合物であり、かつこれらの情報を格納する４２個のマスターテーブル内に合計４０５個のフィールド項目を配し、各テーブル間をプライマリー・キーや候補キー等によって有機的に関連付けることで、旅行業者が顧客のニーズに合わせた行程表を作成する際、観光施設、宿泊施設、交通手段、経路、スケジュール（出発時間、到着時間、滞在時間など）をどのようにすべきかといった事項を、検索結果の情報を適宜選択することによって決定していくことができるような体系的構成を持つ、情報の膨大な分類体系である（甲１の１、甲２９、３０、５４、５５）。 イ　原告ＣＤＤＢの体系的構成は他に依拠することなく構築されたものであり、かつ、原告ＣＤＤＢの各テーブルに格納される情報は網羅的なものではないし、機械的に選択されたものでもなく、修学旅行、慰安旅行など主として団体旅行における顧客のニーズという観点から行程表作成に必要となる情報が選択されて各テーブルに格納されているものであるから、原告ＣＤＤＢは著作者の個性が表れているものであり、著作物として保護されるべき創作性を有している。 ウ　原告ＣＤＤＢは、旅行業者が検索及び行程表作成業務で必要となる情報を４２個のマスターテーブルに分類して格納し、各マスターテーブル内には合計４０５個のフィールド項目を配し、各マスターテーブルごとに各フィールド項目として旅行業者が必要とすると思われる情報を多項目にわたって詳細に採り上げ、プライマリー・キーや候補キーなどによって各テーブルを有機的に関連付けて、効率的に必要とする情報を検索することができるような体系的構成を持つ膨大な規模の情報分類体系であり、かかる体系的構成を持つ原告ＣＤＤＢを使用することにより、旅行業者が行程表作成業務で必要となる情報を効率的に検索できる。 エ　原告ＣＤＤＢの体系的構成は、旅行業に関わる様々な情報について、行程表作成に必要な情報が備わり行程表作成のための情報検索が可能となるように、種類別・関連別にカテゴリー分けを行い、テーブル及び情報項目（フィールド）を設定し、各テーブル間にリレーションを取っているものであり、知的活動を経て作成されたものである（甲２の１５頁以下）。 　原告ＣＤＤＢにおけるこのような体系的構成を持つ膨大な規模の情報分類体系は、他に依拠して構築されたものではなく、オリジナルに構築されたものである（甲６３、乙３８、３９）。 　したがって、原告ＣＤＤＢには著作物の保護要件を充足する創作性がある。 オ　原告ＣＤＤＢは４２個のマスターテーブル内に合計４０５個のフィールド項目を配しているところ、これらも情報の集合物であり、行程表作成に関する多数の情報項目の中から旅行業システムにおけるデータベースのフィールド項目として何を取り上げるべきかという知的活動を経て、４０５個のフィールド項目を選択しているものである。かかるフィールド項目の選択もデータベースにおける情報の選択に該当し、どのフィールド項目を選択するかについては選択の幅があり著作者の個性が表れるものであるから、原告ＣＤＤＢは、情報の選択について著作物の保護要件を充足する創作性があるといえる。 　また、原告ＣＤＤＢの各テーブルには、旅行業者が修学旅行、慰安旅行など主として団体旅行における顧客のニーズに合わせて原告システムを使って行程表作成の業務を行うに当たって必要となる情報が選択されて格納されている。かかる情報の選択は、基本的に網羅的であるわけでもなく、機械的であるわけでもないので、原告ＣＤＤＢの４２個のテーブルに格納されている各情報の集合物には、情報の選択に創作性があるといえる。 　すなわち、原告ＣＤＤＢでは、市販の一般情報誌、旅行業者向けの専門誌、インターネット、ユーザーからの情報提供等から得られる膨大な情報のうち、旅行業者の利用目的を考慮した上で必要となる情報を選別し、そこで選別されたデータを独自の基準によって作成された各テーブル内の各フィールド内に格納することにより、データベースが体系的構成及び情報の集合物として構築されているものである。原告ＣＤＤＢにおける情報の集合物は、例えば宿泊施設であれば全部機械的に格納するというような、形式的な条件を満たす情報を機械的に全て格納するというものではなく、情報の母集団（ここでは宿泊施設）から必要性（例えば団体旅行に利用可能な宿泊施設）の観点から選択して格納しているのであるから、どの情報を格納するかについては選択の幅があり、原告ＣＤＤＢの各テーブルにおける情報の選択に著作物の保護要件を充足する創作性がある。 　各テーブルの情報の集合物については、いずれにも情報の選択に創作性があるが、以下道路地点と道路の情報の選択について創作性のあることを例として詳述する。 カ　道路地点に関する情報の創作性について 　データ自体のソースが原告ＣＤＤＢにしかない情報として道路地点情報がある。したがって、もし原告ＣＤＤＢの道路地点情報が他のデータベースに存在する場合、原告ＣＤＤＢに依拠したことは否定できないこととなる。後記のとおり、被告ＣＤＤＢには原告ＣＤＤＢの道路地点情報のほぼ全てが存在している。この道路地点に関する情報の選択について創作性があることについては、以下のとおり明らかである。 (ア)　「０９地点名テーブル」の地点名称（道路地点名称）及び地点緯度・地点経度のデータ（以下「地点データ」という場合がある。）は、原告ＣＤＤＢを使って経路検索をする場合の基本となる位置情報である。「２０ホテル・旅館テーブル」や「２１観光施設テーブル」などの施設データの「代表道路地点」などと結び付いたり、他のテーブル内に格納されている交通関係のデータなどと連動したりすることで、ユーザーが設定した旅行行程における具体的な所要時間、距離、有料道路通行時の料金情報等の算出をするための基礎情報となるデータであり、旅行行程の作成において重大な役割を果たしている（甲３０の３頁以下）。 　道路地点データは、例えば自動車のナビゲーションシステムにも格納されているが、旅行の行程を作成するのが目的である原告ＣＤＤＢにおいては、運転者に対して道路案内を行うナビゲーションシステムほど数多くの道路地点データを選択する必要がないため、原告が道路地点データを選択するに当っては、必要に応じた道路地点データに絞って選択をしている。 　具体的には、観光バスが通過するのに適切と考えられる道路上の地点、インターチェンジや観光施設等から最も近い交差点、ユーザーの要望を満たすのに適切な地点などを中心に、実際に選択作業を行うデータベース開発者自身が各々適切と考える任意の地点を地図上から選び出し、パソコンのマウスで地図上をクリックするという方法で、当該道路地点データを手作業で選択している。 (イ)　上記考慮に基づいて道路地点を決定した上、上記の方法により詳細な緯度経度情報を「０９地点名テーブル」に格納していくことになるので、道路地点データは以下の�@、�Aの二つの観点から選択の幅があり、著作者の個性が表れる原告らのオリジナルデータである。 �@　「１０道路テーブル」に格納されている道路上の、どの場所を選ぶか�A　その場所のスペースから緯度・経度として具体的に詳細な地点としてどこ（原告ＣＤＤＢでは、緯度・経度を０．１秒単位でデータとして格納している。）を選ぶか 　原告ＣＤＤＢにおいて選択された「０９地点名テーブル」のデータは、上記�@、�Aの過程を経て選択されたものであり著作者の個性が表れるものであるので、情報の選択に著作物の保護要件を充足する創作性があるといえる。 (ウ)　このように地点データは、原告ＣＤＤＢの各開発者自身の価値判断で独自に決定し選択した場所及び緯度・経度の情報であるので、この情報は原告ＣＤＤＢにしか存在し得ない原告固有の情報である。したがって、原告ＣＤＤＢのデータをデッドコピーしない限り、被告ＣＤＤＢも含め、他のデータベースにおける道路地点データが原告ＣＤＤＢと一致することはあり得ない（甲３０、３２、３４、３９、４７〜４９）。 キ　道路データの選択の創作性 　原告ＣＤＤＢでは基本的に大型観光バスによる移動を前提とする行程表作成のためのデータを提供することを目的にしていることから、道路テーブルに格納すべき道路については、その観点から選択がされている。原告ＣＤＤＢの「１０道路テーブル」では、国道、高速道路、有料道路、都市高速道路（首都高速など）を基本的に全て格納しているが、都道府県道、一般道路については、原告ＣＤＤＢで選択された「２０ホテル・旅館テーブル」のホテル・旅館の所在地情報、「２１観光施設テーブル」の観光施設所在地情報なども踏まえ、大型観光バスによる移動に適切な道路を選択して格納している（甲３０、３１の１〜３、甲３３、４７〜４９）。原告ＣＤＤＢの道路テーブルのデータは、このような過程を経て選択されたものであり著作者の個性が表れるものであるので、情報の選択に著作物の保護要件を充足する創作性がある。 ク　以上のとおり、原告ＣＤＤＢには、体系的構成及び情報の選択のいずれにおいてもデータベースの著作物として保護されるべき創作性がある。 (2)　被告ＣＤＤＢが原告ＣＤＤＢの複製ないし翻案であることについて ア　具体的対比 (ア)　被告ＣＤＤＢも、原告ＣＤＤＢと同じく、旅行業者が旅行行程表を作成するに当たって必要となる、観光施設データ、宿泊施設データ、全国各地の主要道路に関する時間・距離・料金データ等の情報が収集・蓄積されたものであり、これらを蓄積するテーブルやフィールド項目を有し、各テーブル間をプライマリー・キーや候補キー等によって有機的に関連付けることで、旅行業者が必要とする情報を効率的に検索できるようにした機能と構造を持つ情報の分類体系である（甲５４、５５）。 　なお、被告システムに含まれるデータベースには、ＣＤ−ＲＯＭ及びインターネットを通じて提供される被告ＣＤＤＢの他にユーザーが使用するハードウェアに被告システムをインストールする際に作成されるエントリーテーブルがあるが、エントリーテーブルにはユーザーが自ら作成する見積関係、売上関係、顧客関係などのデータが格納される。 (イ)　体系的構成の類似性 ａ　テーブルの種類及び数 (a)　被告ＣＤＤＢ（当初版・２００６年版） 　被告ＣＤＤＢ（当初版・２００６年版）に含まれる３１個のマスターテーブルのうち２９個のマスターテーブルは、原告ＣＤＤＢに含まれる２７個のマスターテーブル（別紙１の原告ＣＤＤＢのテーブル番号０１、０２、０５〜２２、２８〜３２、４２、４４の各テーブル）と一致する。なお、原告ＣＤＤＢのテーブル番号２０、２１、２２に対応する被告ＣＤＤＢのテーブルについては、正規化などによる変動があるが実質的に対応関係のあるテーブルとなっている。「２９個」と「２７個」と一致数が異なるのは、この正規化を行っているためで、被告ＣＤＤＢ（当初版・２００６年版）では２個テーブルが増えている。すなわち、原告ＣＤＤＢの「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「２２観光施設備考テーブル」の３テーブルに対応するのが被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」、「２９旅館マスタ基本」、「２３観光マスタ基本」、「２６観光料金マスタ」、「２５観光料金種別マスタ」の５テーブル（２テーブル増加）であり、原告ＣＤＤＢ側でカウントするとテーブル数は２７個になり、被告ＣＤＤＢ側でカウントすると２９個になる。 　なお、原告ＣＤＤＢと一致していない被告ＣＤＤＢ（当初版・２００６年版）の２個のテーブル「２７観光種別マスタ」と「２８観光詳細種別マスタ」についても、ＣＤで提供されるのではなく、原告システムをユーザーのハードウェア内にインストールした際に作成される原告マスターテーブルの中に、これら二つのテーブルと完全に一致するマスターテーブル（テーブル番号２３、２４）が存在している（甲３の別紙２のＮｏ．２３、２４、甲２３の３頁（２）�A）ので、実質的には、被告ＣＤＤＢ（当初版・２００６年版）に存在する３１個のマスターテーブルの全てが、原告のマスターテーブルと一致しているといえる。 　しかも、被告ＣＤＤＢ（当初版・２００６年版）に存在する原告ＣＤＤＢのテーブル、フィールドに対応するテーブル、フィールドには、原告ＣＤＤＢのテーブルＩＤとフィールドＩＤがデッドコピーされてそのまま使われている（甲９、２３、５４、５５）ことからも、原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）のテーブル、フィールドが一致していることは明らかである。 (b)　被告ＣＤＤＢ（現行版） 　被告ＣＤＤＢ（現行版）に含まれる２６個のマスターテーブルのうち２４個のマスターテーブルは、原告ＣＤＤＢに含まれる２３個のマスターテーブル（別紙１の原告ＣＤＤＢのテーブル番号０１、０２、０５ないし１２、１４、１５、２０〜２２、３２〜３４、３６、３９、４０、４２、４３）と一致する。正規化を行っているため、一致するテーブルを被告ＣＤＤＢ（現行版）でカウントすると１個テーブルが増えている。すなわち、原告ＣＤＤＢの「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「２２観光施設備考テーブル」の３テーブルに対応するのが被告ＣＤＤＢ（現行版）の「２１施設マスタ」、「２９宿泊施設マスタ」、「２３観光施設マスタ」、「２６観光料金マスタ」、「２５観光料金種別マスタ」の５テーブル（２テーブル増加）であり、原告ＣＤＤＢ「３９便テーブル」、「４０運行日定義テーブル」の２テーブルに対応するのが現行版の「４４便マスタ」の１テーブル（１テーブル減少）であるため、一致する数を原告ＣＤＤＢ側でカウントするとテーブル数は２３個になり、被告ＣＤＤＢ（現行版）側でカウントすると２４個になる。 　上記のとおり原告ＣＤＤＢと一致していない被告ＣＤＤＢ（現行版）の２個のテーブル「２７観光種別マスタ」（テーブルＩＤ；Ｍ＿ＫＡＮＫＯ＿ＳＢＴ）と「２８観光詳細種別マスタ」（テーブルＩＤ；Ｍ＿ＫＡＮＫＯ＿ＳＹＯＳＡＩ＿ＳＢＴ）についても、ＣＤで提供されるのではなく、ユーザーのハードウェア内に原告システムをインストールした際に作成される原告マスターテーブルの中に、これら二つのテーブル（テーブル番号２３、２４）と完全に一致するマスターテーブルが存在しているため（甲３の別紙２のNo. ２３、２４、甲２３の３頁（２）�A）、実質的には被告ＣＤＤＢ（現行版）に存在する２６個のマスターテーブルの全てが、原告のマスターテーブルと一致しているといえる。 　また、被告ＣＤＤＢ（現行版）では、原告ＣＤＤＢのテーブル、フィールドに対応するテーブル、フィールドのＩＤは、被告ＣＤＤＢ（当初版・２００６年版）で使っていた原告ＣＤＤＢのＩＤ（甲９、２３、５４、５５）から変更してはいるが、デッドコピーしたＩＤのみを変えただけであり、原告ＣＤＤＢに対応するテーブル、フィールドが被告ＣＤＤＢ（現行版）に存在することは、被告ＣＤＤＢ（現行版）も被告ＣＤＤＢ（当初版・２００６年版）の場合と何ら変わっていない。 (c) 被告ＣＤＤＢ（新版） 　被告ＣＤＤＢ（新版）に含まれる２９個のマスターテーブルのうち２５個のマスターテーブルは、原告ＣＤＤＢに含まれる２０個のマスターテーブル（別紙１の原告ＣＤＤＢのテーブル番号０１、０２、０６、０９〜１２、１４、１５、２０〜２２、３２〜３４、３６、３９、４０、４２、４３）と一致する。 　正規化を行っているため、一致するテーブルを被告ＣＤＤＢ（新版）でカウントすると５個テーブルが増えている。すなわち、原告ＣＤＤＢの「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「２２観光施設備考テーブル」の３テーブルに対応するのが新版の「２１施設マスタ」、「２９宿泊施設マスタ」、「２３観光施設マスタ」、「１３０食事土産マスタ」、「２６観光料金マスタ」、「２５観光料金種別マスタ」、「１３１施設別詳細種別マスタ」、「１３２施設種別マスタ」、「１３３施設詳細種別マスタ」の９テーブル（６テーブル増加）であり、原告ＣＤＤＢの「３９便テーブル」、「４０運行日定義テーブル」の２テーブルに対応するのが被告ＣＤＤＢ（新版）の「４４便マスタ」の１テーブル（１テーブル減少）であるため、一致する数を原告ＣＤＤＢ側でカウントするとテーブル数は２０個になり、被告ＣＤＤＢ（新版）側でカウントすると２５個になる。 　以上のとおり、一部正規化による変動はあるものの、被告ＣＤＤＢ（新版）に含まれる２９個のマスターテーブルのうち、２５個のマスターテーブルは、原告ＣＤＤＢに含まれる２０個のマスターテーブルに対応し、一致しているものといえる。 　また、被告ＣＤＤＢ（新版）でも、被告ＣＤＤＢ（現行版）と同様に、原告ＣＤＤＢのテーブル、フィールドに対応するテーブル、フィールドのＩＤは、被告ＣＤＤＢ（当初版・２００６年版）で使っていた原告ＣＤＤＢのＩＤ（甲９、２３、５４、５５）から変更してはいるものの、デッドコピーしたＩＤのみを変えただけであり、原告ＣＤＤＢに対応するテーブル、フィールドが被告ＣＤＤＢ（新版）に存在することは、被告ＣＤＤＢ（新版）においても被告ＣＤＤＢ（当初版・２００６年版）の場合と何ら変わっていない。 ｂ　被告ＣＤＤＢの各テーブルに存在するフィールドの種類及び数 (a) 被告ＣＤＤＢ（当初版・２００６年版） 　原告ＣＤＤＢのマスターテーブルと一致するテーブルにおけるフィールド項目を見ると、原告ＣＤＤＢに存在するフィールド項目のほぼ全てが被告ＣＤＤＢ（当初版・２００６年版）に存在する（甲９、５４、５５）。テーブル管理のためのフィールドである被告ＣＤＤＢ（当初版・２００６年版）における「登録日時」、「更新日時」、「削除区分」のフィールド１３個を除いた場合の被告ＣＤＤＢのフィールド数２８６個のうち２５２個が原告ＣＤＤＢと一致している（甲５５）。 　しかも、被告ＣＤＤＢ（当初版・２００６年版）に存在する原告ＣＤＤＢのテーブル、フィールドに対応するテーブル、フィールドには、原告ＣＤＤＢのテーブルＩＤとフィールドＩＤがデッドコピーされてそのまま使われていることからも、原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）のテーブル、フィールドが一致していることは明らかである。 (b)　被告ＣＤＤＢ（現行版） 　原告ＣＤＤＢのマスターテーブルと一致するテーブルにおけるフィールド項目を見ると、原告ＣＤＤＢに存在するフィールド項目の大多数が被告ＣＤＤＢ（現行版）に存在する（甲５４、５５）。詳細は甲５５のとおりであり、テーブル管理のためのフィールドである各テーブルの「作成日時」、「更新日時」、「削除区分」のフィールド合計７２個を除いた場合の被告ＣＤＤＢ（現行版）のフィールド数１７３個のうち１４３個が原告ＣＤＤＢと一致している（甲５５の別紙２の１２頁）。ちなみに、被告ＣＤＤＢの現行版においてフィールドが増えたといっても、行程表作成のために検索対象となるデータではなく「作成日時」、「更新日時」、「削除区分」などテーブル管理のためのフィールドがその大部分である。 　また、被告ＣＤＤＢ（現行版）では、原告ＣＤＤＢのテーブル、フィールドに対応するテーブル、フィールドのＩＤは、被告ＣＤＤＢ（当初版・２００６年版）で使っていた原告ＣＤＤＢのＩＤ（甲９、２３、５４、５５）から変更されてはいるが、デッドコピーしたＩＤを変えただけであり、原告ＣＤＤＢに対応するテーブル、フィールドが被告ＣＤＤＢ（現行版）に存在することは、被告ＣＤＤＢ（当初版・２００６年版）の場合と何ら変わっていない。 (c)　被告ＣＤＤＢ（新版） 　原告ＣＤＤＢのマスターテーブルと一致するテーブルにおけるフィールド項目は、原告ＣＤＤＢに存在するフィールド項目の大多数が被告ＣＤＤＢ（新版）に存在する（甲５４、５５）。詳細は甲５５のとおりであり、テーブル管理のためのフィールドである「作成日時」、「更新日時」、「削除区分」のフィールド７５個を除いた場合の被告ＣＤＤＢ（新版）のフィールド数２１９個のうち１４６個が原告ＣＤＤＢと一致している（甲５５の別紙２の１２頁）。 　また、被告ＣＤＤＢ（新版）でも、被告ＣＤＤＢ（現行版）と同様に原告ＣＤＤＢのテーブル、フィールドに対応するテーブル、フィールドのＩＤは、被告ＣＤＤＢ（当初版・２００６年版）で使っていた原告ＣＤＤＢのＩＤ（甲９、２３、５４、５５）から変更されてはいるが、デッドコピーしたＩＤを変えただけであり、原告ＣＤＤＢに対応するテーブル、フィールドが被告ＣＤＤＢ（新版）に存在することは、被告ＣＤＤＢ（当初版・２００６年版）の場合と何ら変わっていない。 ｃ　テーブル間の関連付け (a)　被告ＣＤＤＢ（当初版・２００６年版） 　原告ＣＤＤＢのマスターテーブルと一致する２９個のテーブルに関して、プライマリー・キーの設定も含め、原告ＣＤＤＢに存在する関連付けのほぼ全てについて、同様の関連付け（リレーション）が被告ＣＤＤＢ（当初版・２００６年版）に存在する（甲５４の別紙１、甲５５）。 　なお、被告ＣＤＤＢ（当初版・２００６年版）では、原告ＣＤＤＢについて正規化がなされ、原告ＣＤＤＢの「２０ホテル・旅館テーブル」、「２１観光施設テーブル」及び「２２観光施設備考テーブル」の３テーブルに対応するテーブルとして、「２１施設マスタ」、「２９旅館マスタ基本」、「２３観光マスタ基本」、「２６観光料金マスタ」及び「２５観光料金種別マスタ」の５テーブルを設けた。原告ＣＤＤＢにおける「０１市区町村テーブル」が「２０ホテル・旅館テーブル」、「２１観光施設テーブル」の二つのテーブルとリレーションを取っていることに対して、被告ＣＤＤＢでは「４市区町村マスタ」は、原告ＣＤＤＢの「２０ホテル・旅館テーブル」、「２１観光施設テーブル」の共通項目を括りだした上位のテーブルとなる「２１施設マスタ」の一つのテーブルとのみリレーションを取っている。このことによりリレーションの線が半減しているが、これにより原告ＣＤＤＢの全体としての体系的構成に実質的な変更が加えられているとはいえず、被告ＣＤＤＢ（当初版・２００６年版）において原告ＣＤＤＢの体系的構成は維持されている。 (b)　被告ＣＤＤＢ（現行版） 　原告ＣＤＤＢのマスターテーブルと一致する２４個のテーブルに関して、プライマリー・キーの設定も含め、原告ＣＤＤＢに存在する関連付けのほぼ全てについて、同じ関連付け（リレーション）が、被告ＣＤＤＢ（現行版）に存在する（甲５４の別紙２、甲５５）。 　なお、被告ＣＤＤＢ（現行版）では、原告ＣＤＤＢについてさらに正規化がなされ、原告ＣＤＤＢの「３９便テーブル」及び「４０運行日定義テーブル」の２テーブルに対応するテーブルとして、「４４便マスタ」の１テーブルが設けられた。この正規化の関係で、被告ＣＤＤＢではこの２テーブルが１テーブルになっているため、原告ＣＤＤＢでは「３９便テーブル」と「４０運行日定義テーブル」間にあるリレーションが被告ＣＤＤＢにはない結果となっている。しかし、これにより原告ＣＤＤＢの全体としての体系的構成に実質的な変更が加えられているとはいえず、被告ＣＤＤＢにおいて原告ＣＤＤＢの体系的構成は維持されている。 (c)　被告ＣＤＤＢ（新版） 　原告ＣＤＤＢのマスターテーブルと一致する２５個のテーブルに関して、プライマリー・キーの設定も含め、原告ＣＤＤＢに存在する関連付けのほぼ全てについて、同じ関連付け（リレーション）が、被告ＣＤＤＢ（新版）に存在する（甲５４の別紙３）。 　なお、被告ＣＤＤＢ（新版）では、従前の施設関係のテーブルについてさらに正規化がなされ、原告ＣＤＤＢの「２０ホテル・旅館テーブル」、「２１観光施設テーブル」及び「２２観光施設備考テーブル」の３テーブルに対応するテーブルとして、「２１施設マスタ」、「２９宿泊施設マスタ」、「２３観光施設マスタ」、「１３０食事土産マスタ」、「２６観光料金マスタ」、「２５観光料金種別マスタ」、「１３２施設種別マスタ」、「１３３施設詳細種別マスタ」及び「１３１施設別詳細種別マスタ」の９テーブルを設けた。宿泊施設マスタや観光施設マスタ同様に施設マスタの下位のテーブルとして「１３０食事土産マスタ」を、施設の種別に関して大分類、中分類、小分類のテーブルとして「１３２施設種別マスタ」、「１３３施設詳細種別マスタ」、「１３１施設別詳細種別マスタ」をそれぞれ追加したものである。 　また、被告ＣＤＤＢ（当初版・２００６年版）及び被告ＣＤＤＢ（現行版）では、緯度経度情報を「３４緯度経度マスタ」とその他のテーブル（「４市区町村マスタ」、「２１施設マスタ」、「３５地点マスタ」、「４７駅マスタ」）で重複して保有しており、原告ＣＤＤＢの体系的構成の特徴的部分をそのまま流用していたが、被告らは、原告の指摘により、原告ＣＤＤＢに依拠しないでデータベースを作成する場合における緯度経度情報の重複保有の不合理さに気づき、被告ＣＤＤＢ（新版）では「３４緯度経度マスタ」のテーブルを削除した。また、被告らは、同時に「３４緯度経度マスタ」とリレーションが取られていたが実質的に利用されていなかった「３２ＵＲＬ種別マスタ」、「３３ＵＲＬ分類マスタ」も削除した。 　かかるテーブルの追加や削除によって被告ＣＤＤＢのテーブル間のリレーションに変更が生じてはいるが、これにより原告ＣＤＤＢと一致するテーブル間における被告ＣＤＤＢの全体としての体系的構成に実質的な変更が加えられているとはいえず、原告ＣＤＤＢの体系的構成の大部分は維持されている。 ｄ　小括 　以上によれば、被告ＣＤＤＢの当初版・２００６年版、現行版、新版の各体系的構成は、それぞれの各テーブルのうち原告ＣＤＤＢと一致するテーブル（当初版・２００６年版は２９個、現行版は２４個、新版は２０個）に関して、各テーブルの種類、各テーブルに存在するフィールドの種類、各テーブル間の関連付け（リレーション）の全ての点において、原告ＣＤＤＢの体系的構成と実質的に類似していると認められる。また、原告ＣＤＤＢの体系的構成は上記のとおり創作性があるものであるところ、被告ＣＤＤＢは、当初版・２００６年版、現行版、新版のいずれにおいても、その大部分の体系的構成（テーブル、フィールド、リレーション）は原告ＣＤＤＢと共通であるので、原告ＣＤＤＢの創作性ある部分と類似しているといえる。 (ウ)　情報の選択の類似性 ａ　フィールド項目の選択の類似性 (a)　被告ＣＤＤＢ（当初版・２００６年版） 　テーブル管理のためのフィールドである「登録日時」、「更新日時」、「削除区分」のフィールド１３個を除いた場合の被告ＣＤＤＢのフィールド数２８６個のうち２５２個が原告ＣＤＤＢのフィールドと一致しており（甲５５の別紙２の１２頁）、２５２個のフィールドに関しては原告ＣＤＤＢのフィールド項目の選択を流用しているといえるので、この点に関して原被告ＣＤＤＢは同一あるいは少なくとも類似しているといえる。 　また、被告ＣＤＤＢ（当初版・２００６年版）では、原告ＣＤＤＢと対応するテーブル、フィールドのテーブルＩＤ、フィールドＩＤには原告ＣＤＤＢのＩＤがデッドコピーされてそのまま使われていることからもフィールド項目の選択の同一性ないし類似性は裏付けられる。 (b)　被告ＣＤＤＢ（現行版） 　テーブル管理のためのフィールドである「作成日時」、「更新日時」、「削除区分」のフィールド７２個を除いた場合の被告ＣＤＤＢのフィールド数１７３個のうち１４３個が原告ＣＤＤＢと一致しており（甲５５の別紙２の１２頁）、１４３個のフィールドに関しては原告ＣＤＤＢのフィールド項目の選択を流用しているといえるので、この点に関して同一あるいは少なくとも類似しているといえる。 　また、被告ＣＤＤＢ（現行版）では、原告ＣＤＤＢのテーブル、フィールドに対応するテーブル、フィールドのＩＤは、被告ＣＤＤＢ（当初版・２００６年版）で使っていた原告ＣＤＤＢのＩＤから変更してはいるが、デッドコピーしたＩＤを変えただけであり、原告ＣＤＤＢに対応するテーブル、フィールドが被告ＣＤＤＢ（現行版）に存在することは、被告ＣＤＤＢ（当初版・２００６年版）の場合と何ら変わっていないので、このことからもフィールド項目の選択の同一性ないし類似性は裏付けられる。 (c)　被告ＣＤＤＢ（新版） 　テーブル管理のためのフィールドである「作成日時」、「更新日時」、「削除区分」のフィールド７５個を除いた場合の被告ＣＤＤＢのフィールド数２１９個のうち１４６個が原告ＣＤＤＢと一致しており（甲５５の別紙２の１２頁）、１４６個のフィールドに関しては原告ＣＤＤＢのフィールド項目の選択を流用しているといえるので、この点に関して原告ＣＤＤＢと被告ＣＤＤＢは、同一あるいは少なくとも類似しているといえる。 　また、被告ＣＤＤＢ（新版）でも、原告ＣＤＤＢのテーブル、フィールドに対応するテーブル、フィールドのＩＤは、当初版・２００６年版で使っていた原告ＣＤＤＢのＩＤから変更してはいるが、デッドコピーしたＩＤを変えただけであり、原告ＣＤＤＢに対応するテーブル、フィールドが被告ＣＤＤＢ（新版）に存在することは、当初版・２００６年版の場合と何ら変わっていないので、このことからもフィールド項目の選択の同一性ないし類似性は裏付けられる。 ｂ　各テーブルに格納されたデータ（レコード）の選択の類似性 　上記のとおり、原告ＣＤＤＢの各テーブルにどのようなデータ（レコード）を登録するかについては基本的に選択の余地があるので、原告ＣＤＤＢの各テーブルのレコードの集合物には情報の選択の創作性がある。 　被告らは、別紙４被告らの主張欄記載のとおり、原告ＣＤＤＢの各テーブルに格納されたレコード集合物の全部あるいはその一部となるレコードを集合物として、被告ＣＤＤＢの対応するテーブルに直接コピーして入力し、内容を確認して修正等を行った上で入力してきたことを認めている。 　また、被告ＣＤＤＢには、当初版・２００６年版、現行版、新版のいずれにも、原告ＣＤＤＢのレコードをコピーして入力した痕跡が多数残されている。 　このように被告ＣＤＤＢの各テーブルのレコードは原告ＣＤＤＢの各レコードの全部あるいはその一部となるレコードを集合物として、被告ＣＤＤＢの対応するテーブルに直接コピーして入力したり、内容を確認して修正等を行った上で入力したものであるので、被告ＣＤＤＢの各テーブルにおける情報の選択は原告ＣＤＤＢと同一あるいは少なくとも類似しているといえる。 ｃ　被告らの主張及びレコードの追加の点について (a)　被告らは、現行版、新版に関して原告ＣＤＤＢの各レコードについて確認し必要な修正を行ったから、当初版の被告ＣＤＤＢのデータとはいえないし、ましてや原告ＣＤＤＢのデータと同視されるべきものではないと主張するが、失当である。 　例えば、被告らが流用を自認する原告ＣＤＤＢの観光施設のレコード約１万４０００件について電話番号が正しいかを確認し、誤りのあった電話番号を修正したとしても、観光施設としてどの施設を選択するかという原告が行った情報の選択に関して１万４０００件の選択はそのまま維持されているので、被告ＣＤＤＢには情報の選択の類似性があることは明らかである。 (b)　被告ＣＤＤＢでは各テーブルにおいてレコードが追加されている場合があるが、原告ＣＤＤＢのレコードの集合物に対してレコードが追加されたとしても、原告ＣＤＤＢの集合物は維持されて存続しているので、追加されたレコードが膨大なものか否かにかかわらず、原告ＣＤＤＢのレコードの集合物に関して、その部分は情報の選択について原告ＣＤＤＢと類似していることは明らかである。 　例えば、あるホテルが廃業になったためそのホテルに関するレコードが削除された場合でも、被告が流用を自認する原告ＣＤＤＢのレコード９４００件の大部分が削除されずに存続しているのであるから、被告らが流用した原告ＣＤＤＢのレコードの集合物にする情報の選択について原告ＣＤＤＢと類似していることは明らかである。 　また、フィールドの追加、変更、削除に伴い原告ＣＤＤＢのレコードのデータの変更がされる場合があるが、被告らが利用した原告ＣＤＤＢのレコード、例えば、被告らが流用を自認する宿泊施設のレコード９４００件についてのフィールド項目に追加、変更、削除があるだけであり、宿泊施設としてどの施設を選択するかという原告が行った情報の選択に関して９４００件の選択はそのまま維持されているので、被告ＣＤＤＢにおいてフィールド項目の追加、変更、削除があったとしても、情報の選択について原告ＣＤＤＢとの類似性が維持されていることは明らかである。 (c)　被告らは、原告ＣＤＤＢのデータを直接コピーするなどして被告ＣＤＤＢへ格納した後にレコードを追加してレコード件数を増加させたので、データベース全体のレコード件数総数から見れば原告ＣＤＤＢから直接コピーなどしたレコード件数の割合は低いと主張するが、意味のない主張である。 　なぜならば、原告は被告らがその後追加したレコードについて責任を追及しているわけではないからである。仮に追加されたレコードが存在するとしても、被告らが直接コピーするなどした原告ＣＤＤＢのテーブル、フィールドなどの体系的構成及びレコードの集合物自体は被告ＣＤＤＢに維持・存続しているのであるから、著作権侵害及び一般不法行為の成立が妨げられることはないというべきである。 (d)　被告らは、原告ＣＤＤＢに格納させるデータについて、創作性が認められない単なる客観的なデータであることを理由に、データベースの著作権による保護がないと主張するが、失当である。 　原告ＣＤＤＢにおいて選択された一つ一つのデータが道路地点の緯度経度情報や道路情報（道路名、道路名読み）など客観的データであったとしても、そのデータの選択には創作性があるので、データの集合物の無断流用は著作権侵害を構成する。情報の選択対象が客観的データであったとしてもデータベースの著作物になり得ることは当然のことであり、その創作性のある部分（情報の選択や体系的構成）を流用すれば、以下のとおり、著作権侵害が成立することは明らかである。 　まず、被告ＣＤＤＢ（当初版・２００６年版）は、別紙４の被告らの主張のとおり、被告が自認するだけでも、原告ＣＤＤＢの以下の２０個のテーブルのレコードの集合物を直接コピーするなどして利用しており、原告ＣＤＤＢの情報の選択と同一あるいは少なくとも類似しているといえる。 ・「０１市区町村テーブル」 ・「０２地区・県名テーブル」 ・「０５緯度経度テーブル」 ・「０６ＵＲＬアドレステーブル」 ・「０７ＵＲＬ種別テーブル」 ・「０８ＵＲＬ分類テーブル」 ・「０９地点名テーブル」 ・「１０道路テーブル」 ・「１１接続テーブル」 ・「１２禁止乗換テーブル」 ・「１３有料道路番号テーブル」 ・「１４区間料金テーブル」 ・「１５首都高速料金テーブル」 ・「１６道路構成地点テーブル」 ・「１７道路構成地点索引テーブル」 ・「１８市区町村通過道路索引テーブル」 ・「１９県範囲定義テーブル」 ・「２０ホテル・旅館テーブル」 ・「２１観光施設テーブル」 ・「３２駅テーブル」 　被告らはレコードの集合物に対して一部追加、修正、削除を行ったと主張しているが、仮にそのような事実があったとしても、被告ＣＤＤＢには原告ＣＤＤＢのレコードの集合物の大部分が残っているので、原告ＣＤＤＢにおける情報の選択との同一性あるいは少なくとも類似性は維持されている。 　次に、被告ＣＤＤＢ（現行版）については、別紙４の被告らの主張のとおり、被告らが自認するだけでも、原告ＣＤＤＢの以下の１１個のテーブルのレコードの集合物を被告ＣＤＤＢ（当初版・２００６年版）から引き継いで利用しており、原告ＣＤＤＢの情報の選択と類似している。 ・「０５緯度経度テーブル」 ・「０６ＵＲＬアドレステーブル」 ・「０９地点名テーブル」 ・「１０道路テーブル」 ・「１１接続テーブル」 ・「１２禁止乗換テーブル」 ・「１４区間料金テーブル」 ・「１５首都高速料金テーブル」 ・「２０ホテル・旅館テーブル」 ・「２１観光施設テーブル」 ・「３２駅テーブル」 　被告らはレコードの集合物に一部追加、修正、削除を行ったと主張しているが、仮にそのような事実があったとしても、被告ＣＤＤＢには原告ＣＤＤＢのレコードの集合物の大部分が残っているので、原告ＣＤＤＢにおける情報の選択との同一性あるいは少なくとも類似性は維持されている。 　最後に、被告ＣＤＤＢ（新版）については、別紙４の被告らの主張のとおり、被告らが自認するだけでも、原告ＣＤＤＢの以下の１１個のテーブルのレコードの集合物を当初版・２００６年版及び現行版から引き継いで利用しており、原告ＣＤＤＢの情報の選択と類似している。 ・「０５緯度経度テーブル」 ・「０６ＵＲＬアドレステーブル」 ・「０９地点名テーブル」 ・「１０道路テーブル」 ・「１１接続テーブル」 ・「１２禁止乗換テーブル」 ・「１４区間料金テーブル」 ・「１５首都高速料金テーブル」 ・「２０ホテル・旅館テーブル」 ・「２１観光施設テーブル」 ・「３２駅テーブル」 　被告らはレコードの集合物に対して一部追加、修正、削除を行ったと主張しているが、仮にそのような事実があったとしても、被告ＣＤＤＢには原告ＣＤＤＢのレコードの集合物の大部分が残っているので、前記のとおり情報の選択の類似性は維持されている。 ｄ　道路地点情報の選択の類似性 　上記のとおり、被告ＣＤＤＢにおいて、原告ＣＤＤＢの各情報の選択の創作性のある部分が類似しているが、道路地点の情報の選択に関しては、以下のとおりである。 　原告ＣＤＤＢの道路地点情報はソースが原告ＣＤＤＢにしかない原告固有の情報であり、もし原告ＣＤＤＢの道路地点情報が他のデータベースに存在する場合、原告ＣＤＤＢに依拠したことは否定できない。 　また、原告ＣＤＤＢでは、「１０道路テーブル」に格納された道路に関して、行程表を作成する上で必要と考えられる適切な地点はどこかという考慮に基づいて道路地点を決定した上、詳細な緯度経度情報が「０９地点名テーブル」に格納されていくことになるが、道路地点データには、�@道路上のどの場所を選ぶか、�Aその場所の緯度経度として具体的にどこを選ぶかの二つの局面で情報の選択の幅があることは上記のとおりであり、著作者の個性が表れる原告らのオリジナルデータである。 　被告らは別紙４のとおり、原告ＣＤＤＢの「０９地点名テーブル」に格納されている道路地点を、被告ＣＤＤＢ（当初版・２００６年版）にコピーして入力した上で、追加・修正・削除し、現行版、新版では追加・更新したことを自認する。 　被告ＣＤＤＢでは、原告ＣＤＤＢの「０９地点名テーブル」に格納されている道路地点（道路上のどの場所か、具体的な緯度経度）の情報を「３５地点マスタ」に流用し複製しているので、原告ＣＤＤＢと同一であるか、あるいは少なくとも類似しているものといえる。また、原告ＣＤＤＢの道路地点の選択（情報の選択）は上記のとおり創作性があるものであるところ、被告ＣＤＤＢは原告ＣＤＤＢの創作性ある部分と同一であるか、あるいは少なくとも類似しているものといえる。 　類似状況の詳細は、以下のとおりである。 (a)　道路上のどの場所かについて 　原告ＣＤＤＢ２００５年９月版との比較（甲３４）から明らかなように、被告ＣＤＤＢ（当初版・２００６年版）では、９９．９８％、被告ＣＤＤＢ（現行版。２００７年９月版、Ver2.53）では９９．８９％、被告ＣＤＤＢ（現行版。２００９年４月版、Ver2.92）では９８．３８％、被告ＣＤＤＢ（現行版。２００９年６月版、Ver2.94）では９４．６０％、被告ＣＤＤＢ（新版）では９２．９３％もの原告ＣＤＤＢの地点に関する「道路上のどの場所か」というデータを流用している（甲３４）。なお、データベースにおいては修正などの例外を除き、基本的に従前のデータが承継されることになるので、上記バージョン以外のバージョンの被告ＣＤＤＢの地点データについても、原告ＣＤＤＢからのデータの流用がされているものと推認することができる。 (b) その場所の緯度経度として具体的にどこを選ぶかについて 原告ＣＤＤＢにおける「０９地点名テーブル」における緯度経度データの作成は、独自の方法に基づいて全て手作業で行われているため、たとえ同様の方法を用いたとしても、人間がパソコンのマウスで地図上をクリックするという方法で行うものである以上、度分秒（しかも０．１秒単位）で表現された緯度経度の０．１秒単位まで緯度経度データが一件であっても一致することなどあり得ないことである。 　それにもかかわらず、被告ＣＤＤＢの「地点マスタ」の緯度経度データの完全一致率（緯度及び経度が０．１秒単位まで一致している率）は、平成２１年（２００９年）５月に被告らが原告から著作権侵害の訴えを提起されるときまで、実に９２％以上にも達する極めて異常な状態にある（甲５、２２、３１の１〜３、甲３２、３３、３４、３９）。 　ちなみに、本件訴えが提起される直前の被告ＣＤＤＢ（現行版。２００９年４月版、Ver2.92）の緯度経度データの完全一致率は、９２．９％であったが、訴え提起直後の被告ＣＤＤＢ（現行版。２００９年６月版、Ver2.94）では、８．１％に激減している。 　原告ＣＤＤＢの２００５年９月版との比較で見ると、被告ＣＤＤＢ（現行版。２００９年６月版、Ver2.94以降）や被告ＣＤＤＢ（新版）では、原告ＣＤＤＢの緯度経度情報とは微妙に差を設けているが、被告ＣＤＤＢ（現行版）のVer2.94では−１０秒から１０秒の間に約９２％、被告ＣＤＤＢ（新版）では、−１０秒から１０秒の間に約９０％含まれている（甲３４の別紙４の１、別紙５の１）ことから、平成２１年（２００９年）５月、被告らは、原告から著作権侵害の訴えを提起された後に、一定範囲内で数値が異なるような自動処理（例えば乱数発生機能を利用する変換プログラムを作成して、元の緯度経度データの数値に対して一斉に変換をかける等）や個別の改変等の工作を行っているものと推認される。しかし、このような工作を行ったとしても、原告ＣＤＤＢの緯度経度情報をデッドコピーした後、隠蔽目的でデッドコピーした緯度経度に依拠して自動変換等の改変がされたすぎない（甲７５の２の１６２頁以下）ものであるので、被告ＣＤＤＢは、結局新版に至るまで、原告ＣＤＤＢの道路地点情報の緯度経度情報を流用しているといえる。 このように、原告ＣＤＤＢにおける道路地点情報の選択には創作性があるところ、被告ＣＤＤＢは原告ＣＤＤＢの創作性ある部分と同一であるか、あるいは少なくとも類似しているものといえる。 ｅ　道路情報の選択の類似性 　上記のとおり、被告ＣＤＤＢにおいて、原告ＣＤＤＢの情報の選択の創作性のある部分が類似しているが、都道府県道、一般道路に関する情報の選択に関しては、以下のとおりである。 　原告ＣＤＤＢでは都道府県道、一般道路については、原告ＣＤＤＢで選択された「２０ホテル・旅館テーブル」のホテル・旅館の所在地情報、「２１観光施設テーブル」の観光施設所在地情報なども踏まえ、大型観光バスによる移動に適切な道路を選択して「１０道路テーブル」に格納しているので、その情報の選択には創作性がある。 　被告らは別紙４の被告らの主張のとおり、原告ＣＤＤＢの「１０道路テーブル」に格納されている道路情報を、被告ＣＤＤＢ（当初版・２００６年版）にコピーして入力した上で、追加・修正・削除し、現行版、新版では追加・更新したことを自認する。 　このように被告ＣＤＤＢは、原告ＣＤＤＢの「１０道路テーブル」に格納されている道路のデータを「３６道路マスタ」に流用し複製している（甲３３、別表２、別表３の痕跡番号２６ないし３１）ので、道路データ（情報）の選択が原告ＣＤＤＢと同一であるか、あるいは少なくとも類似しているものといえる。また、原告ＣＤＤＢの道路（情報）の選択は上記のとおり創作性があるので、被告ＣＤＤＢは原告ＣＤＤＢの創作性ある部分と同一であるか、あるいは少なくとも類似しているものといえる。 ｆ　ダミーデータの選択の同一性 　被告ＣＤＤＢの当初版・２００６年版と現行版には、原告ＣＤＤＢにおけるダミーデータ『ダミーデータ「＊＊＊」（道路名）、「ﾝ ﾀﾞﾐｰ」（道路名の読み）』が格納されている（甲２１）。かかるダミーデータを格納するかどうかは原告ＣＤＤＢにおける個性が表れているという意味で創作性ある情報の選択の一つであるところ、被告ＣＤＤＢではこれと同一の情報の選択を行っている。 (エ)　小括 　上記のとおり、被告ＣＤＤＢは当初版・２００６年版、現行版、新版のいずれにおいても、原告ＣＤＤＢの体系的構成及び情報の選択において創作性ある部分と同一であるか少なくとも類似している。 　なお、著作物の全部でなくとも著作物の創作性ある部分を複製すれば、著作権侵害は成立する。データベースの著作物でもこの理は同じである。 　昭和６０年９月の著作権審議会第七小委員会（データベース及びニューメディア関係）報告書でも、複製に関して「従来から複製権は著作物の全体的な複製だけでなく、その一部分であっても、著作物としての価値を持ち得る部分である限り、その部分にも及ぶと解釈されてきたところである。データベースにこの解釈を適用すると、著作物としての価値を持ち得るような形で、情報をある程度のまとまりで複製することについては複製権が及ぶと考えられる。」としており、データベースの一部複製等についても、データベースの著作者の複製権等が及ぶことは明らかである。 　なお、被告らは著作権侵害及び一般不法行為が成立しないことの事情として被告システムの優位性を主張する。 　しかし、著作権侵害及び一般不法行為の成立とシステムの優位性は関係がない。仮に被告システムに優位性があったとしても、被告ＣＤＤＢが原告ＣＤＤＢに依拠し類似性があるものであれば著作権侵害が成立するし、多大な労力費用をかけて開発された原告ＣＤＤＢを流用した被告ＣＤＤＢを含む被告システムを、原告ＣＤＤＢを含む原告システムの販売地域と競合する地域に販売する行為は一般不法行為に該当するというべきである。このことは被告システムに優位性があろうとなかろうと変わりがない。 　したがって、被告らの優位性に関する主張は失当である。 イ　依拠性 　原告ＣＤＤＢと被告ＣＤＤＢとは、データベースとしての表現において、実質的な同一性ないし類似性が認められ、アクセス可能性やデッドコピーされた具体的痕跡からして依拠性があることは明らかである。被告ＣＤＤＢの開発者であるＡ及び被告Ｙ５が、翼システムあるいは翼システムから営業譲渡を受けた後は旧原告会社等において原告ＣＤＤＢの開発に従事していたこと、被告Ｙ３、被告Ｙ２、被告Ｙ４、被告Ｙ６が、原告等において営業担当者として原告システム用の提供データベースである原告ＣＤＤＢ等を常に持ち歩き、顧客に対する原告ＣＤＤＢ等のインストール作業に従事していたこと、Ａ、被告Ｙ５、被告Ｙ３、被告Ｙ２、被告Ｙ４、被告Ｙ６が、原告等を退職した後、ごく短期間で膨大なデータベースの体系的構成及びデータよりなる被告ＣＤＤＢを開発して販売を行っていること、並びに、被告ＣＤＤＢには原告ＣＤＤＢをデッドコピーした痕跡が新版に至るまで多数残されていることなどに鑑みると、Ａ及び被告Ｙ５は、原告ＣＤＤＢの内容を設計レベルのコアとなる情報まで正確に認識した上で、これに依拠して被告ＣＤＤＢを作成したものであると認められる。 　この点に関して被告らは、一旦ＣＳＶ（Character-Separated Values）ファイルに抽出した上で、被告ＣＤＤＢに入力したと主張するが、ＣＳＶファイルに一旦出力した後に被告ＣＤＤＢに入力したのであれば本来不都合が生じる「、(カンマ)」、「"(ダブルクォート）」等が含まれているデータのデッドコピーについても、何ら不都合を生じさせることなくデータ移行を行っていることに鑑みて、被告らの主張は明らかに不合理なもので到底信用することはできない。被告らは当初版・２００６年版において、原告ＣＤＤＢのデータを原告ＣＤＤＢのテーブルＩＤ、フィールドＩＤと同一あるいは酷似したテーブルＩＤ、フィールドＩＤとする被告ＣＤＤＢの各テーブル、フィールドにデッドコピーして移行させ、その後現行版、新版において改変等を行ったものである。 　また、被告らは、ＣＳＶファイルに抽出した後に、一般のホームページや市販のＤＶＤソフト等に掲載されている情報を閲覧、参照等しながら手作業による追加・修正・削除を行い、そのような作業を行った後に被告ＣＤＤＢに入力したと主張するが、一般のホームページや市販のＤＶＤソフト等に掲載されている情報を閲覧、参照等しながら手作業による追加・修正・削除を行うことはできないし、そもそも対比すべき正しいデータは存在しない。 　むしろ、各施設の緯度経度情報やコード体系などをデッドコピーしていること、原告ＣＤＤＢの道路テーブルにおける道路名フィールドで「＊＊＊」、道路名カナフィールドで「ﾝ ﾀﾞﾐｰ」として登録されているデータがそのまま被告ＣＤＤＢにも登録されていたことを含めデッドコピーの痕跡が存在する理由を被告らが何ら説明できない項目があることなどに鑑みて、被告らの主張は明らかに不合理なもので到底信用することはできない。被告らは当初版・２００６年版において、原告ＣＤＤＢのデータを原告ＣＤＤＢのテーブルＩＤ、フィールドＩＤと同一あるいは酷似したテーブルＩＤ、フィールドＩＤとする被告ＣＤＤＢの各テーブル、フィールドにデッドコピーして移行させ、その後現行版、新版において改変等を行ったものである。 　このように、被告ＣＤＤＢへのデータの収録過程について、ＣＳＶファイルを経由して、エクセル上で一般情報をもとに目視、手作業で追加・修正・削除を行ったとする被告らの主張は、極めて不合理である。 　被告らは、原告の指摘のうちのタブ区切りの点のみ反論するが、その余は認否も反論もない。タブ区切りの点についても、データ移行に際して対象テーブルの全データを打ち出して、カンマやダブルクォートが含まれているかを確認し、含まれていない場合はカンマ区切りのＣＳＶで、含まれている場合はタブ区切りのＴＳＶで抽出するという被告ら主張の方法は、かなり手間暇のかかる作業であり、現実的でなく、信用できない。 〔被告らの主張〕 (1)　原告ＣＤＤＢの著作物性について 　そもそも、データベースにおいてはその作成目的や利用対象が同一である限り、その信頼性を維持するため、選択される情報は客観的基準に従ってある程度機械的に収集・選択されることになり、情報の選択について、データベース創作者の創作性が反映する可能性は制限される（乙２８）。つまり、収集方針、選定基準というのは、一般的にはシステムの記憶容量が小さい時や、規模に制約のあるデータベースには重要であるが、規模が大きく真に利用価値のあるデータベースほどその重要性がなくなり、場合によっては不必要となるものである。 　一方、体系的な構成についても、データベースが最大限活用されるためには、フォーマットの作成や体系設定は「没個性」的でかつ標準的な「汎用性」のあるものが望ましく、ユーザーの習慣性や効率性等を追及すれば一つの標準的な技術に収斂していく傾向があり、情報を網羅した完璧なデータベースであるほど創作性を認める余地は少なくなってしまうのであり、逆に、フォーマットや体系設定が個性的ということになれば、その分データベースの利用を狭めることになってしまうのである。原告の指摘する昭和６０年９月の著作権審議会第七小委員会報告書においても、「没個性」、「汎用性」を指向するデータベースの特質などから、データベースについて創作的行為とすることのできない場合がかなりあるとの指摘がされている。 　また、下級審裁判例（東京地裁平成１２年３月１７日判決・判例時報１７１４号１２８頁。いわゆるＮＴＴタウンページ事件）においても、データベースにおける情報の選択、体系的な構成の基準となる創作性に関しては、当該データベースの目的・性格が考慮され、データベースの利便性向上のため、作成者として当然行うべき情報の選択はデータベース著作物の創作性については考慮されないことを明確にしたと解されている（乙２８）。 　実質的にも、データベースについて創作性の程度を低く設定すると、先行データベースの創作者が情報の体系的構成に創作者なりの何らかの構成を反映してデータベースを作成すると、後発者は同一の体系的構成からなるデータベースを制作できないだけでなく、当該データベースの一部を構成する情報の集合体を利用する場合にも当該部分で先行者の体系的構成における創作性が反映されていれば、先行データベースの一部複製とされるおそれがあり、データベースの自由な開発や情報の自由な利用が阻害されるから、この意味でも、データベースの創作性の程度を低く解すべきではない。 　以上を踏まえると、原告が原告ＣＤＤＢの特徴的部分、すなわち創作性のある部分であると主張する、観光施設テーブルの格納情報、ホテル・旅館テーブルの格納情報、行程表作成のために必要なテーブル、フィールド及びリレーションの設計などは、いずれも、旅行業者向けの行程表作成を目的としたデータベースという性質上、作成者として当然考慮すべきものであり、その情報の選択や体系設定はいずれも客観的・標準的な基準に従った没個性的・汎用的なものにすぎないから、仮にこれらの作業が相当程度の資本・労力の投下を要するものであったとしても、創作性は認められない。このようなものに安易に著作物性が認められれば、旅行業者向けのデータベースは、原告以外におよそ制作できないことになり、競争原理が全く機能せず、一社に市場を独占させる結果となり、利用者にとっての利便性向上を著しく阻害する。 　したがって、原告ＣＤＤＢは著作物として保護されるべき創作性を有しておらず、原告ＣＤＤＢには著作物性がない。 (2)　被告ＣＤＤＢが原告ＣＤＤＢの複製ないし翻案に当たらないことについてア　被告アゼスタが、原告ＣＤＤＢのデータの一部を被告ＣＤＤＢに利用したことは認めるが、以下個別に詳述するとおり、それは、被告ＣＤＤＢの作成過程において、原告ＣＤＤＢのデータの一部について、一旦エクセルで読み込めるファイル形式であるＣＳＶファイルで抽出するなどした上で、これらのデータに適宜追加・修正・削除を加えて、それを被告ＣＤＤＢに収録、利用したり、一旦ＣＳＶファイルに抽出した上で、一般のホームページや市販のＤＶＤソフト等に掲載されている情報を閲覧、参照等しながら手作業による追加・修正・削除を行い、そのような作業を行った後に被告ＣＤＤＢに入力したものである。そのため、特段修正・削除を要しなかった箇所や修正漏れがあった箇所などについて、結果的に原告ＣＤＤＢのデータと同一のものが被告ＣＤＤＢに収録されている場合もあるが、これらのデータには、被告アゼスタにおいてホームページ等により情報の正確性等を確認したものも含まれている以上、原告ＣＤＤＢのデータと同視されるべきものとはいえないのであって、被告アゼスタは、原告ＣＤＤＢのデッドコピーなどしていない。 　また、被告Ｙ３、被告Ｙ２及び被告Ｙ４などの営業担当者は、原告システムのインストール用ＣＤを所持し取り扱うことは会社から一切許されておらず、管理も厳重であったため所在すらもわからなかった。納品などのインストール作業はサポート部門に依頼するという厳格な社内ルールがあったため、上記の者らが手にしたことなど一度もなかった。 (ア)　当初版の被告ＣＤＤＢのデータについて 　被告アゼスタは、当初版の被告ＣＤＤＢを開発するにあたり、独自に収集したデータに加えて、原告ＣＤＤＢのデータの一部を、以下のように修正等の加工を施した上で利用した。 a　施設関係データ (a)　観光施設データ 　原告ＣＤＤＢ（２００５年１１月版）の観光施設データのうち、市販の料金ガイドに掲載されている観光施設（約１万４０００件）について、一旦エクセルで読み込めるファイル形式（ＣＳＶファイル）で抽出した上で、公式ホームページや一般ホームページ（「ヤフー電話帳」等）、料金ガイド等により、最新の情報（名称、名称カナ、郵便番号、電話・ファックス番号、住所）を確認し、適宜追加・修正・削除を加えた。また、原告ＣＤＤＢでは、テーブル、フィールド等の変更なく、観光施設テーブル及び観光施設備考テーブルに登録できる観光料金の種類が非常に限られた種類の固定的な設定となってしまっており、複雑な料金体系を採用している観光施設に柔軟に対応できていなかった。すなわち、原告ＣＤＤＢでは、１施設レコードについて、個人・団体ごとに、小学生／中学生／高校生／大人の４項目について、それぞれ４種類の料金しか登録できなかった。しかし、実際には、東京ディズニーランドのように、個人であっても、１デーパスポートからスターライトパスポートまで６種類の料金設定がされていたり、また小学生／中学生／高校生／大人の区別だけではなく、さらに大学生／シニア／障害者等の各属性に応じて細かく料金が異なっている施設や、通常の団体料金とは別に修学旅行等の場合に適用される特別な団体料金（学校団体料金）が設定されている施設も存在しており、原告ＣＤＤＢはこのような施設の料金情報を十分反映できておらず、顧客のニーズに合致していなかった。 　そこで、被告ＣＤＤＢは、テーブル、フィールド等の変更なく、このような施設の複雑な料金体系をも正確に反映できるように適宜データを加工・修正した上で被告ＣＤＤＢ（「施設マスタ」、「観光マスタ基本」、「観光料金マスタ」）に機械的に移行入力したが、このような詳細な料金情報は料金ガイドにも掲載されておらず、各施設の公式ホームページ等により料金体系の種類・内容の詳細を１件ずつ確認して加工・修正作業を行わなければならないため、多大な労力を必要とした。 　また、自然・神社等（山、川、湖沼、渚、城、神社、滝、温泉、海岸、寺、スキー場、公園）のデータ（約４５００件）については、一般ホームページや市販のＤＶＤソフト「プロアトラス２００２ 日本の風景１０００」より最新の情報（名称、名称カナ、郵便番号、電話・ファックス番号、住所）を確認して、データを手入力し、さらに、原告ＣＤＤＢ（２００５年１１月版）のデータの一部についても、ＣＳＶファイルで抽出し、一般ホームページより最新の情報（名称、名称カナ、郵便番号、電話・ファックス番号、住所）を確認し、適宜データに追加・修正・削除を加えた上で、被告ＣＤＤＢ（「施設マスタ」、「観光マスタ基本」、「観光料金マスタ」）に機械的に移行入力した。 　もっとも、顧客への被告システムの出荷（平成１８年６月末ころ販売開始）にあたり、平成１７年１１月以降急ピッチで進められていた被告ＣＤＤＢの開発作業が間に合わなかったこともあり、原告ＣＤＤＢの観光施設データのうち、神社仏閣、ゴルフ場、食事処、ドライブイン、温泉地等に関するデータを中心に、被告ＣＤＤＢ（「施設マスタ」、「観光マスタ基本」、「観光料金マスタ」）にコピーした上で、誤記等の修正を加えた。 (b)　宿泊施設データ 　原告ＣＤＤＢ（２００５年１１月版）の宿泊施設データのうち、「ホテル」区分、「旅館」区分、「その他」区分の「公共の宿」（国民宿舎等）のデータ（約９４００件）についても、ＣＳＶファイルで抽出した上で、公式ホームページや一般に公開されているホームページ（「ヤフー電話帳」等）等により、最新の情報（名称、名称カナ、郵便番号、電話・ファックス番号、住所）を確認し、適宜追加・修正・削除を加えた上で、被告ＣＤＤＢ（「施設マスタ」、「旅館マスタ基本」）に機械的に移行入力した。 　また、観光施設データと同様に、顧客への被告システムの出荷にあたり、被告ＣＤＤＢの開発作業が間に合わなかったこともあり、原告ＣＤＤＢの宿泊施設データのうち、ビジネスホテルに関するデータを中心に、コピーして被告ＣＤＤＢ（「施設マスタ」、「旅館マスタ基本」）に入力した上で、誤記等の修正を加えた。 b　交通関係データ 　被告ＣＤＤＢは、鉄道・路線バス・飛行機等の路線・運賃探索ソフトである「駅すぱあと」と連携させているため、原告ＣＤＤＢと異なり鉄道や飛行機の路線探索、時刻表・料金に関するテーブルを備えておらず、これらのデータは入力していない。 　ただし、原告ＣＤＤＢの駅テーブルのデータ（約９２００件）については、ＣＳＶファイルで抽出した上で、「駅すぱあと」と連携させるために、駅コード及び駅名のデータに修正を加えた上で、被告ＣＤＤＢ（「駅マスタ」）に機械的に移行入力した。 c　道路関係データ 　原告ＣＤＤＢの道路データ、地点データ等の道路関係データについて、コピーして被告ＣＤＤＢ（「道路名マスタ」、「地点マスタ」、「接続マスタ」等）に入力した上で、不要なデータの削除、誤記等の修正、追加を加えた。ただし、高速道路・有力道路の料金データは、原告ＣＤＤＢと同様に、一般に公開されているホームページより入力したものである。 　これらのデータは、情報の選択に独自の視点や発想が加わる余地がほとんどなく創作性を有しない。 d　エリア関係データ 　原告ＣＤＤＢの都道府県データをコピーして被告ＣＤＤＢ（地区・都道府県マスタ）に入力し、原告ＣＤＤＢの市区町村データについても、コピーして被告ＣＤＤＢ（市区町村マスタ）に入力した上で市区町村の合併等を確認して追加・削除を行ったが、これらのデータは公知の情報であり、選択の幅は皆無であり創作性はない。 (イ)　現行版及び新版の被告ＣＤＤＢのデータについて 　被告アゼスタは、平成１８年６月末ころの被告システム（当初版）の販売開始以降、現在まで６年以上もの長期間にわたり、膨大な手間・時間をかけて、顧客のニーズに対応してデータ内容を充実させており、継続して被告ＣＤＤＢのデータを追加・修正・削除している（乙３４）。 　これにより、現行版及び新版の被告ＣＤＤＢのデータは、最初に開発した当初版の被告ＣＤＤＢのデータから一新され、データの件数・内容ともに大幅に変更している。レコード数だけをとっても、新版のレコード数（２１３万３８４６件）は当初版・２００６年版（５８万９５９２件）の３．６倍を超えるほどに至っている。また、当初版の被告ＣＤＤＢ開発の際に原告ＣＤＤＢから利用したデータに関して、仮に新版の被告ＣＤＤＢに同内容のデータが存在していたとしても、当該データは、当初版開発時から現在までの６年数か月の期間を通して、被告アゼスタがホームページや書籍等により情報の正確性等を幾度となく確認した上で被告ＣＤＤＢに格納しているものであり、被告アゼスタの継続的な企業努力により、現在の情報を正しく反映しているデータとしての価値が新しく備わったものであるから、もはや６年以上も昔の当初版の被告ＣＤＤＢのデータとはいえないし、ましてや原告ＣＤＤＢのデータと同視されるべきものではない。 　現行版及び新版の被告ＣＤＤＢの当初版からの主なデータ変更部分は以下のとおりである。 a　施設関係データ 　現行版の被告ＣＤＤＢにおいて、顧客のニーズに対応するため、観光施設、宿泊施設、公共施設等のデータの大幅な拡充を行った結果、現行版（Ver2.99）では、施設マスタのレコード件数が約１５万件になり、当初版のレコード件数（約５万７０００件）の約２．６倍にまで増加し、さらに各種施設の新設・閉館や住所・料金等の内容変更などに伴い、２万７０００件以上のデータを修正した。 　また、現行版（Ver2.96）の被告ＣＤＤＢにおいては、施設に関する緯度経度データが全て更新しており、新版の被告ＣＤＤＢにおいて、緯度経度マスタのテーブルを削除している。 　さらに、新版の被告ＣＤＤＢにおいては、食事土産マスタ等のテーブルを新設し、全国「観光・運輸」総合カタログ２０１１年に掲載されたドライブイン等の食事施設や土産店について、公式ホームページや一般ホームページ等により最新の情報（名称、住所、電話・ファックス番号等）を確認し、データを追加・更新した。 b　交通関係データ 　現行版の被告ＣＤＤＢにおいては、「駅すぱあと」に収録されていないフェリー、ケーブルカー、ロープウェイ等の交通機関に対応するため、便マスタ、時刻マスタ等のテーブルを新設し、フェリーガイドやホームページ等を確認した上で、交通会社、時刻表、便名等のデータを新たに追加した。 c　道路関係データ 　現行版の被告ＣＤＤＢにおいて、顧客のニーズに対応するため、地点・道路、高速道路料金等のデータの大幅な拡充を行った結果、現行版（Ver2.99）では、レコード件数が、地点マスタ約２万２３００件、道路マスタ約４８００件、単経路マスタ約６万６０００件、区間料金マスタ約１７６万８０００件となり、当初版のレコード件数（地点マスタ約１万２８００件、道路マスタ約２７００件、接続マスタ約３万７０００件、料金マスタ約３６万３３００件）からそれぞれ大幅に増加され、既存のデータについても、最新の情報に合わせて多数のデータが更新されている。同様に、新版の被告ＣＤＤＢにおいても継続的にデータの追加・更新が行われている。 　また、現行版（Ver2.94）の被告ＣＤＤＢにおいては、地点に関する緯度経度データはすべて更新されている。 d　エリア関係データ 　現行版の被告ＣＤＤＢにおいては、都道府県マスタ及び市区町村マスタのデータをすべて入力し直した。 　また、現行版（Ver2.96）の被告ＣＤＤＢにおいて、エリアに関する緯度経度データはすべて更新しており、新版の被告ＣＤＤＢにおいては、緯度経度マスタのテーブルを削除している。 　さらに、新版の被告ＣＤＤＢにおいて、市区町村マスタに政令指定都市のデータを追加し、市区町村だけでなく政令市の検索まで可能となるようにした。新版の都道府県マスタについても、「緯度経路カラム」フィールドを追加して、都道府県庁位置を新規に登録した。 　なお、原告は、ＣＳＶファイルに一旦出力した後に被告ＣＤＤＢに入力したのであれば不都合が生じる「、(カンマ)」、「"(ダブルクォート）」等が含まれているデータのデッドコピーについても、不都合を生じさせることなくデータ移行を行っていることに鑑みて、被告らの主張は明らかに不合理なものであると主張するが、ＣＳＶファイルには、カンマ区切り（ＣＳＶ：データをカンマで区切って並べたファイル形式）のみならずタブ区切り（ＴＳＶ：データをタブ文字で区切って並べたファイル形式）も含まれ、カンマ区切り（ＣＳＶ）では、カンマ、ダブルクォート等は文字化けや項目ずれを起こすため、被告アゼスタでも、カンマ、ダブルクォート等が含まれているデータについてはタブ区切り（ＴＳＶ）を使って上記支障が生じないように対処しており、このことは、エクセルを使ってデータ入力・加工等を行う開発者であれば誰でも知っている常識的な知識である。 　したがって、原告の上記主張は失当である。 イ　被告ＣＤＤＢは原告ＣＤＤＢに依拠したものではなく、原告が主張するような原告ＣＤＤＢの複製物ないし翻案物ではない。 (ア)　被告らは、独自の設計思想に基づき被告ＣＤＤＢを開発したものであり、体系的構成が異なる。 　被告アゼスタが独自の設計思想に基づき開発した被告ＣＤＤＢ（当初版・ ２００６年版、現行版、新版）では、原告ＣＤＤＢとのテーブルの一致率（当初版・２００６年版は４９．０％、現行版は１８．２％、新版は１１．５％）及びフィールドの一致率（当初版・２００６年版は４４．１％、現行版は２１．１％、新版は１３．４％）からも明らかな通り、被告ＣＤＤＢは、テーブルの内容（種類及び数）、各テーブルに設定されたフィールド項目の内容、各テーブルの関連付けのあり方のいずれの点についても、原告ＣＤＤＢの構造と大きく異なっている。 　具体的には、まず、被告ＣＤＤＢは、格納されている情報について、データベース上、相互に結合・連動する必要のある関連性の強いまとまりごとに類型化していくと、大きく分けて、中核となる施設情報とその他の三つの情報（道路情報、交通情報、エリア情報）に分類することができる。 　このうち、施設情報は旅行の目的地や出発地に関する情報であるところ、そもそも、旅行業者向けシステムにおいては、旅行の目的地をどこにするかという点が最も肝要であり、その他の交通情報、道路情報及びエリア情報は、目的地に到達するためのいわば手段となる情報にすぎないから、目的地となる施設情報に関する体系的な構成をどのような内容とするかが、旅行業者向けシステムのデータベースの創作性を判断する上で決定的な要素となる。 　実際に、本件のような旅行業者向けシステムと一般に普及しているルート・路線検索システム（カーナビゲーションシステムや「ＮＡＶＩＴＩＭＥ」（株式会社ナビタイムジャパン提供）、「駅すぱあと」など）との間で、格納している情報に違いが現れる最たるものが施設情報である。すなわち、ルート・路線検索システムを利用しても出発地や目的地の基本情報（名称や電話番号）は検索することができる上、その間の距離や時間、料金も全て検索することができるところ、本件のような旅行業者向けシステムは、ＣＤデータベース（ＣＤ−ＲＯＭ）に格納する情報との関係では、旅行で訪れる観光施設や宿泊施設に関する詳細情報（営業時間、入館料、客室数、大浴場の有無等）を追加した点に特徴がある。 　したがって、施設情報は、旅行業者向けシステムにおいて最も特徴的な情報であり、これがあることではじめて、当該システムがルート・路線検索システムとは異なる独自の検索機能を有しているものといえる。 　よって、旅行業者向けシステムのデータベースにおいては、施設情報に関する体系的な構成をどのようにするかが、データベースの体系的な構成における創作性を最も大きく左右するものといえる。 　以上を踏まえ、当初版・２００６年版、現行版及び新版の被告ＣＤＤＢの開発における被告アゼスタの独自の設計思想、原告ＣＤＤＢとの差異等について詳論する。 ａ　当初版・２００６年版 (a)　施設情報について 　当初版の被告ＣＤＤＢの開発当時（２００６年ころ）、日本人の旅行形態の主流は、旅先に行くこと自体（例えば京都に行く、ニューヨークに行くなど）やその旅先の有名な観光名所を巡る（例えば清水寺を巡る、自由の女神を巡るなど）ことを目的とするものから、体験する、味わう、参拝する、世界遺産を巡る、癒しの時間を過ごすなどといった個々人の興味に沿ったテーマを満足することを目的とする傾向に変わりつつあった。また、当該テーマ自体についても、時代の進展に応じてその多様化が進む傾向にあった。 　そのため、被告アゼスタは、ゆくゆくは、そのようなテーマに沿った柔軟な検索や旅行計画の作成を利用者（旅行業者）が行うようになることを想定し、将来におけるデータベースとしての拡張性や格納効率、保守性を最大限に高めるという視点から、施設情報に関するデータベースを設計することとした。 　このような意図のもと、被告アゼスタは、当初版・２００６年版の被告ＣＤＤＢにおいて、施設マスタという独立したマスターテーブルを上位テーブルとして用意し、宿泊施設マスタや観光施設マスタといった施設の類型別のマスターテーブルを、施設マスタの下位テーブルとして位置付ける格納方法をとることとし、最大２階層でデータを保持するテーブル構成を採用した。 　これにより、当初版・２００６年版の被告ＣＤＤＢでは、電話番号や住所などの施設の基本情報は、「宿泊施設」や「観光施設」といった施設類型の区別なく、いったん全て施設マスタに格納する設計としたことから、上記のようなテーマに沿って施設を検索する場合に、データベースの構造上は、施設マスタのみを検索することで、テーマに沿った施設を検索することが可能な設計構造となったものである。さらに、現行版では、上記設計思想をもとに、下位テーブルではなく上位テーブルである施設マスタに「キーワード」のフィールドを設け、施設マスタを「世界遺産」、「祭り」、「花火」、「桜」、「紅葉」、「観光・食事１００選」、「土産物１００選」などのキーワードで検索できるようにしている。したがって、被告ＣＤＤＢでは、いつでも施設類型別のマスターテーブル（例えば、食事施設、公共施設等）を増やすことができ、かつ、これらを上位テーブルの施設マスタで検索できる設計構造となっており、施設類型が多様化してもそれに対応できるような柔軟な設計となっている。現に、新版では、施設類型別のマスターテーブルとして食事・土産マスタを追加し、食事処及び土産施設の情報充実を図っている。 　また、宿泊施設自体が観光施設を兼ねている複合施設など（例えば、善光寺宿坊常智院、鴨川ホテル三日月スパ三日月）、必ずしも一つの目的地が、「宿泊施設」や「観光施設」といった単独の施設類型に当てはまらないものがあるところ、今後、格納する施設類型が多様化した場合、当該施設がどの施設類型に格納されているか直ちには判然としないケースが増えてくることが予想される。その場合、個々の施設類型から目的の施設を検索しようにも、格納箇所が判然とせず、検索できない可能性があるところ、被告ＣＤＤＢの設計構造であれば、施設類型が判然としなくとも、上位テーブルである施設マスタを検索すれば目的地を検索することができる仕組みになっていることから、上記多様化にも柔軟に対応することができる。 　このように被告ＣＤＤＢにおいては、旅行業界の動向を見据え、顧客のニーズに応えることができるように、情報の体系付けやキーワードの付与に独自の創意工夫を凝らしている。 　一方、原告ＣＤＤＢにおける施設情報の格納方法は、テーマ別検索を意図していないため、ホテル・旅館テーブルと観光施設テーブルの二つの施設類型別のマスターテーブルでのみ、施設に関する情報を格納している。 　そのため、データベースの構造上、目的の施設を検索する場合も、「ホテル・旅館」又は「観光」のいずれか一つのテーブルに絞って検索するか、両方のテーブルを別々に検索せざるを得ず、格納している施設に関する情報をまとめて１テーブルの中で検索できる設計構造になっていない。また、キーワード検索機能を持たない原告ＣＤＤＢの場合、被告ＣＤＤＢのようにテーマ別検索を可能とするためには、ホテル・旅館テーブルと観光施設テーブルの両方に「キーワード」のフィールドを追加し、両方のマスターテーブルを個別にすべて検索する必要があることから、被告ＣＤＤＢと比べて、データベースとしての検索効率及び格納効率が悪いものとなっている。 　さらには、原告ＣＤＤＢの設計構造では、被告ＣＤＤＢと異なり、施設類型のテーブルを「ホテル・旅館」と「観光」の二つ以外に追加するのがそもそも難しく、仮に追加して施設類型が多様化した場合も、格納した情報の施設類型が判然としない場合に個々の施設類型からの検索が困難なケースが出てくることになり、データベースとして柔軟な設計構造になっていない。 　このように旅行業者向けシステムにとって最も重要かつ本質的な特徴といえる施設情報において、被告ＣＤＤＢは、原告ＣＤＤＢとは全く異なる独自の設計思想に基づいて情報の格納を行っている（乙１９）。 (b)　施設情報以外について 　道路情報の格納方法としては、ある地点までの最短経路を検索抽出するというダイクストラ法（乙２１。最短距離だけに限らず、時間や費用等の要素も組み合わせ、目的に応じた最適な経路を検索抽出することを含む。）の考え方に従い格納するのが一般的であり、実際の利用者のニーズにも合致している。 　そのため、ダイクストラ法は、上記「ＮＡＶＩＴＩＭＥ」やカーナビゲーションシステムなどルート・路線検索を行うシステムではほぼ必ず採用されている方法であり、当然、被告ＣＤＤＢも原告ＣＤＤＢもこれを採用している。 　したがって、被告ＣＤＤＢも原告ＣＤＤＢも、ダイクストラ法という一般的でありふれた最短経路検索方法を採用する以上、これを実現するために、地点（始点）と地点（終点）並びにその間の距離及び所要時間等を格納していくという具体的な情報の格納方法それ自体において特段顕著な差異が生じ得るものではなく、このような格納方法自体には何ら創作性（著作物性）が認められない。 　また、交通情報（路線情報、交通会社、便情報、時刻情報、運賃情報、距離情報など）は、情報の内容からして本来、格納する情報に取捨選択の余地があるものではなく、基本的には全ての情報を登録する必要があるものであるから、情報の取捨選択について特段顕著な差異が生じるものではない。 　実際に、上記「ＮＡＶＩＴＩＭＥ」、「Ｙａｈｏｏ！路線情報」、「駅すぱあと」といった他の多くのルート・路線検索システムにおいても、これらの情報は格納されている。 　したがって、そもそも交通情報をどのように格納しようと、格納方法に創作性（著作物性）があるということはできず、著作権侵害の問題が生じるものではない。 　そして、被告ＣＤＤＢでは、頻繁に変更が行われる交通情報のデータメンテナンス作業の軽減の観点から、鉄道・路線バス・飛行機等の路線・運賃探索ソフトである「駅すぱあと」と連動させることとしたため、原告ＣＤＤＢと異なり、鉄道や飛行機の路線探索、時刻表・料金に関する情報を一切格納しておらず、その分、テーブル及びフィールド構成も簡素なものとなっている。 　したがって、交通情報の格納方法について、交通情報のデータメンテナンス（外部ソフトウェアを利用するか否か）に関する考え方の違いから、原告ＣＤＤＢと被告ＣＤＤＢとで全く異なる格納方法となっている。 　さらに、エリア情報は、そもそも格納する情報が、地区（北海道、東北、関東、中部、関西等）と４７都道府県しかないため、格納方法においても、特段顕著な差異が生じるものではなく、格納方法に創作性（著作物性）が認められるものではない。 　したがって、そもそもエリア情報をどのように格納しようと、著作権侵害の問題が生じるものではない。 　最後に、被告ＣＤＤＢは、レコード修正を容易にするため、地区情報と都道府県情報を、原告ＣＤＤＢと異なり、三つのマスターテーブルで保持することとしている上、原告ＣＤＤＢには、被告ＣＤＤＢと異なり、地区と都道府県情報に加え、「方面」情報が格納されている。 　以上のとおり、エリア情報の格納方法についても、原告ＣＤＤＢと被告ＣＤＤＢとでは、一部異なる情報を格納している上、格納方法も異なっている。 ｂ　現行版 (a)　行程・見積機能の当初版からの見直し 　２００６年版の被告システムから追加搭載した売上・顧客管理機能は、顧客からの評判もよく、システム安定性にも優れていた。そのため、被告アゼスタは、当初版で構築した行程・見積機能についても、この際、新たな外注先に全て見直してもらい、再構築してもらうこととした。 　そして、被告アゼスタは、２００７年４月、行程・見積機能を当初版から大きく変更した現行版を構築した。 　これに伴い、被告ＣＤＤＢに格納する各情報の格納方法についても次のとおり見直しが行われた。 (b)　施設情報の格納方法 　施設情報の格納は、将来におけるテーマ別検索を可能とすることを目的として構築されていたことから、現行版においては、かかる設計思想を受け継ぐこととし、これを具体的に実現すべく、２００８年１０・１１月版（Ver2.82）以降、施設マスタに「キーワード」のフィールドを設け、施設マスタの中から「世界遺産」、「祭り」、「花火」、「桜」、「紅葉」、「観光・食事１００選」、「土産物１００選」などのテーマに沿って検索できるようにした。 (c)　道路情報の格納方法 　前記のとおり、被告ＣＤＤＢも原告ＣＤＤＢも、ダイクストラ法という一般的でありふれた最短経路検索方法を採用する以上、これを実現するために、地点（始点）と地点（終点）並びにその間の距離及び所要時間等を格納していくという具体的な情報の格納方法それ自体において特段顕著な差異が生じ得るものではなく、このような格納方法自体には何ら創作性（著作物性）が認められない。 　もっとも、ダイクストラ法の特徴は、最短となる経路の探索をひたすら繰り返すことにあるところ、被告アゼスタは、翼システムには在籍していなかった開発担当者も交えて根本から設計思想を見直し、被告ＣＤＤＢの現行版においては、経路の方向を上下区分で表現した「接続」の組み合わせにより禁止経路を構成する原告ＣＤＤＢとは全く異なり、禁止経路を定義するための作業量を軽減して格納効率を向上させるべく、上下区分による「接続」概念を一新し、始点→中間点→終点の３地点の組み合わせで禁止経路情報を禁止経路マスタとして１テーブルに格納する方法で格納することとした。 　この結果、被告ＣＤＤＢでは、原告ＣＤＤＢよりデータの読み込み回数を少なくすませて経路探索を高速で処理することが可能となり、以下の(i)ないし(v)のとおり、現行版の被告ＣＤＤＢでは、道路情報の格納方法についても、原告ＣＤＤＢとの間に大きな違いが生じることとなった。 (i)　原告ＣＤＤＢの接続テーブルでは、接続番号というフィールド項目がプライマリー・キーとなっているのに対し、被告ＣＤＤＢの単経路マスタでは、地点コード（始点）、地点コード（終点）、道路コードの三つのフィールド項目がプライマリー・キーとされている（乙９別紙５）。 　これにより、例えば、地点Ａから地点Ｂに道路１を介して接続される経路を登録する場合、被告ＣＤＤＢでは、それぞれのフィールド項目がプライマリー・キーとなっているため重複して登録されることはないが、原告ＣＤＤＢでは、接続番号というフィールド項目のみがプライマリー・キーとなっているため同一の経路が重複して登録され無駄なデータが作られる可能性がある。もしデータが重複登録されると、同じ地点間でも異なる所要時間や距離が誤って登録される可能性があり、不都合が生じる。その上、原告ＣＤＤＢでは、地点（始点）がプライマリー・キーとなっていないため、経路検索において、効率の良いデータの読み込みができない設計となっている。 (ii)　被告ＣＤＤＢの禁止経路マスタは、始点→中間点→終点の３地点の組み合わせで禁止経路情報を１テーブルに格納しているが、原告ＣＤＤＢでは、経路と経路の組み合わせを接続テーブル及び禁止乗換テーブルの２テーブルに分けて格納しており、被告ＣＤＤＢの禁止経路マスタと原告ＣＤＤＢの禁止乗換テーブルは、その構造が異なっている（乙９別紙５）。 　これは禁止経路の設定の仕方について原告ＣＤＤＢと被告ＣＤＤＢとで異なる考え方（原告ＣＤＤＢは２地点と２地点の組み合わせで禁止経路を設定する考え方であるのに対し、被告ＣＤＤＢは３地点の組み合わせで禁止経路を設定する考え方）を採用していることによる。 　その結果、禁止経路に関し、原告ＣＤＤＢでは、被告ＣＤＤＢに比べて複雑な禁止経路定義設計となっているため、禁止経路を定義するための作業量が増えることから、被告ＣＤＤＢより誤りが生じやすい構造になっている（乙９別紙５）。 (iii)　被告ＣＤＤＢの区間料金マスタ及び通行料金マスタと、原告ＣＤＤＢの区間料金テーブル及び首都高速料金テーブルを比較すると、被告ＣＤＤＢの方が道路料金区分を備えている分、柔軟な設計となっている（乙９別紙５）。 　例えば、新たに深夜早朝、通勤割引などのＥＴＣ割引料金を追加する場合、被告ＣＤＤＢでは、区間料金マスタのレコードを追加するだけで、フィールド追加などのテーブルの設計変更は不要である。これに対し、原告ＣＤＤＢの区間料金テーブルの構造では、必要な料金種類分のフィールドの追加が必須となる。なお、原告も認めるとおり、フィールドの追加はシステムへの影響が大きく容易でないが、レコードの追加は容易にできる（甲３、４頁）。 (iv)　原告ＣＤＤＢの首都高速料金テーブルは、その名のとおり首都高速料金の情報だけを格納しているが、被告ＣＤＤＢの通行料金マスタは、首都高速だけでなく、有料道路などの定額の通行料金の情報全てを格納する設計となっている（乙９別紙５）。 (v)　被告ＣＤＤＢでは、原告ＣＤＤＢの市区町村通過道路索引テーブル、道路構成地点索引テーブル、県範囲定義テーブル、道路構成地点テーブル、有料道路番号テーブルに対応するテーブルは存在しない。 (d)　交通情報の格納 　交通情報については、そもそも格納方法に創作性（著作物性）があるものではない。もっとも、被告アゼスタでは、前記のとおり、当初版の被告ＣＤＤＢにおいて、「駅すぱあと」と連動させることとしたため、原告ＣＤＤＢと異なり、鉄道や飛行機の路線探索、時刻表・料金に関する情報を一切格納していなかったところ、利用者より、鉄道や飛行機以外のフェリーなどの路線やその時刻表等の情報も追加して欲しいといった要望があった。これを受けて、被告アゼスタでは、これらのフェリーなどの路線情報を格納するため、現行版において路線構成マスタ、路線マスタ、時刻マスタ、便マスタの各テーブルを新たに設計したものである。その結果、便情報や運行日の格納に関するテーブル構成にも違いが生じることとなった（乙９別紙６）。 　したがって、交通情報の格納については、被告ＣＤＤＢと原告ＣＤＤＢとは、当初版からして「駅すぱあと」と連動させるか否かの点で基本的な設計思想が大きく異なっていたが、現行版ではさらにその違いが大きくなっている。 (e)　２００６年版の売上・顧客管理機能との設計方針の統一 　現行版では、被告データベースの行程・見積機能の部分について、上記の見直しの他に、２００６年版の売上・顧客管理機能と設計方針を統一させるため、システムの機能向上、設計工程及び製造工程における品質確保や効率の追求という観点から、被告ＣＤＤＢのフィールド構成等を再構築した。 　具体的には、被告ＣＤＤＢのフィールドの並び順を変更し、また、全テーブルにおいて作成日時、更新日時及び削除区分のフィールドを追加した。さらに、予備フィールド（別紙３の括弧内に「予備」と記載された、フラグ、区分、日付、数値等のフィールド）は全て削除し、施設情報のＵＲＬマスタに表示順フィールドを追加した。 ｃ　新版 　被告システムの新版は、平成２３年４月４日、それまでの被告システムの現行版（Ver2.99）を再構築して発売した。これに伴い、被告ＣＤＤＢ部分についても内容が大きく変更した。 　新版における設計思想は以下のとおりである。 (a)　施設情報の格納方法の変更 　新版の被告ＣＤＤＢでは、主に施設情報の格納につき、利用者のニーズと意識やライフスタイルの変化に対応し、さらにデータベースの拡張性、格納効率及び検索効率等の向上の観点から再構築がされた。 　当初版においては、前記のとおり、施設情報の格納に関して、個々人の旅のテーマに沿った柔軟な検索や旅行計画の作成を利用者（旅行業者）が行えるようにするため、将来におけるデータベースとしての拡張性や安定性、検索効率等を考慮して、被告ＣＤＤＢにおいて、施設マスタを上位テーブルとして用意して、ここに基本的な情報を集約し、いかなる検索テーマを設定しようと施設マスタという一つのマスターテーブルから全て検索できるようにし、宿泊施設マスタや観光施設マスタといった施設の類型別の詳細情報を収録したマスターテーブルを、施設マスタの下位テーブルとして位置付けるテーブル構成をとることとしていた。 　新版の被告ＣＤＤＢでも、上記設計思想をそのまま受け継ぎ、下位テーブルである類型別のマスターテーブルとして新たに食事・土産マスタを追加し、食事処及び土産施設の情報充実を図った。これは観光施設か宿泊施設かにかかわらず、ドライブインや名産品の土産店などのように食事のためや土産物を購入するためにだけ立ち寄ることができる施設について、これらに特化した情報である、開館・閉館時間や食事内容、土産内容等を充実してもらいたいとの利用者からのリクエストがあり、重要性が増したことから、観光施設や宿泊施設から独立させて追加したものである。 　また、新版の被告ＣＤＤＢでは、施設の種別及び詳細種別の格納を統合的に格納するため、施設種別マスタ、施設詳細種別マスタ及び施設別詳細種別マスタを追加した。 　具体的には、現行版の被告ＣＤＤＢまでは、観光施設の種別については施設マスタの中の「観光種別」のフィールド及び観光種別マスタと観光詳細種別マスタで格納していたのに対し、宿泊施設と公共施設の種別については施設マスタの中の「宿泊種別」、「公共施設種別」のフィールドのみで格納しており、施設によって施設の種別の格納の仕方が異なっていた。そこで、新版の被告ＣＤＤＢでは、これらを一元的に整理し格納するため、施設の種別については、観光施設、宿泊施設、公共施設さらには新版で追加された食事処及び土産施設のいずれも、施設種別マスタ、施設詳細種別マスタ及び施設別詳細種別マスタの三つのテーブルで格納することとしたものである。これに伴い観光種別マスタ及び観光詳細種別マスタは削除した。それぞれのテーブル（マスタ）の格納情報の詳細は、施設を「宿泊」、「観光」、「公共」、「食事・土産」の四つに大分類し、そこから施設種別の中分類として施設種別マスタを用意し、小分類として施設詳細種別マスタを用意したものである。 　これにより、例えば、ある一つの施設が神社・仏閣としても博物館としても分類されるような複合的な施設種別を持つ場合において、当該施設に割り当てられた一つの施設コードを使って、神社・仏閣としても博物館としても検索できるような構造になった。すなわち、神社・仏閣としても博物館としても検索されるようなキーワードを関連する格納情報の中に全て直接書き込んでおき文字列で検索できるようにする方法もあるが、データベースとしては施設コードで検索できるようにしておいた方が効率的であるし、データベースの開発時及び更新時における人為的ミスを低減することができる。また、施設の種別を増やしたい場合、食事・土産マスタのようなマスターテーブルとして追加するという方法もあるが、そこまで施設の詳細情報を入力する必要が現時点ではない場合に、施設種別マスタの「施設大種別」の中で追加レコードとして増やすことで対応することも可能となった。これにより検索テーマの種別を増やすことも容易となり、このことは被告のデータベース開発の設計思想にあるテーマ別検索を充実させることにもつながる。なお、現行版の被告ＣＤＤＢで施設の種別を増やしたい場合、施設マスタの中のフィールドとして新たに追加する必要があり、単なるレコードの追加の場合に比べて、データベースを動作させるプログラムの開発及びその動作検証等に時間を要するなど、データベースの追加拡張が容易ではなかった。 　このように、新版の被告ＣＤＤＢでは、施設の種別につき、一元的に整理、格納することが可能となり、種別の追加が容易になった。 　なお、原告ＣＤＤＢには上記のようなテーブルはない上、施設の種別を増やそうにも、ホテル・旅館テーブル又は観光施設テーブルの中でのフィールドの追加という形でしか対応できない構造になっており、データベースとしての拡張性に乏しい構造となっており、その違いはより一層顕著なものとなっている。 　その他にも、新版の被告ＣＤＤＢでは、提携施設マスタ、提携種別マスタ及び提携会社マスタを追加した。これは、宿泊施設や観光施設等が、大手旅行会社や全国旅行業協会、旅行案内所などと提携している施設か否か、また、宿泊クーポンや食事クーポン等のクーポンを利用できる施設か否か、各会社のクーポンを発券できる施設か否かといった情報を新たに格納したものであり、これらも利用者からの要望に応えるために追加したものである。 　また、新版の被告ＣＤＤＢでは、既存の施設マスタ、観光施設マスタ、宿泊施設マスタにおいても、利用者からの要望をふまえ、「Ｅメール」（施設への連絡先）、「団体受入区分」（団体客の受入れが可能か否か）及び「風呂、温泉効能」（施設内の風呂、温泉の効能）などのフィールドをそれぞれ追加、変更した。 　以上のとおり、新版の被告ＣＤＤＢでは、施設情報の格納方法が大きく変更されており、原告ＣＤＤＢとは似ている点がないほど体系的な構成を大きく異にしている。 (b)　その他の情報 　その他の情報については、交通情報に関しては、システム画面上で表示した出発駅と到着駅の駅名で「駅すぱあと」の駅名と連動させるようにして、「駅すぱあと」による検索を可能にしているが、利用者の利便性を考えると駅名によってはシステム画面上で表示する駅名と「駅すぱあと」に登録されている駅名とを別名にしたい場合がある。例えば、新千歳空港ではなく札幌空港（新千歳空港）と表示する、東京国際空港（羽田）ではなく羽田空港（東京国際空港）と表示する等のように、「駅すぱあと」の駅名ではなく通称で表示した方が利便性が高い、と考えられることによるものである。これらの別名を収録した「駅名（駅すぱあと）」のフィールドを、駅マスタに追加したりもした。 　また、道路情報に関しては、地図上に表示するルート検索結果の経路表示をより一層地図上の道路に沿った曲線のように画面上表示するための座標データの情報を格納した「単経路補間マスタ」を追加したり、利用者の要望により道路名の略称でも検索できるように、例えば「中央自動車道」ではなく「中央道」で検索できるよう、「道路名略称」のフィールドを道路マスタに追加したりした。 　また、エリア情報に関しては、利用者の要望により、政令指定都市でも検索できるように、「政令市区分」、「政令市コード」をフィールドとして市区町村マスタに追加したりした。 　このように利用者からの要望やシステム操作上の利便性等をふまえ、施設情報以外の情報についてもテーブルやフィールドの変更等を行った。なお、これらの新規テーブルや新規フィールドは、原告ＣＤＤＢには存在しない。 (イ)　原告ＣＤＤＢと被告ＣＤＤＢとは、実際のテーブル・フィールドの構造及びリレーションが異なる。 　テーブル構造及びフィールド構造の違いに基づく原告ＣＤＤＢと被告ＣＤＤＢ（新版）の機能等の差異の詳細には大きな違いがあり、被告ＣＤＤＢが原告ＣＤＤＢに依拠して作成されたものではないことは明らかである。とりわけ、前記のとおり、旅行業者向けシステムのデータベースにおいては、施設情報に関する体系的な構成をどのようにするかが、データベースの体系的な構成における創作性を最も大きく左右する。 　そして、施設情報に関しては、当初版よりすでに、原告ＣＤＤＢと被告ＣＤＤＢとで設計思想が大きく異なっており、被告ＣＤＤＢでは、施設マスタの下位テーブルとして観光施設マスタと宿泊施設マスタが位置付けられ、全ての施設が施設コードで体系立てられており、原告ＣＤＤＢと体系的な構成を大きく異にしていた。その上さらに、新版の被告ＣＤＤＢでは、観光施設種別だけではなく、宿泊施設や食事・土産施設、公共施設の施設種別も一元的に管理可能なテーブル構造に変更したことにより、今後どのような種別の施設を追加しても、施設種別の追加に伴うテーブル変更やフィールドの追加を生じさせないですむようになった。これに対し、原告ＣＤＤＢでは、上位の施設テーブルが存在しないため、異なる種別の施設データを追加する場合には必ず種別ごとのテーブルを追加しなければならず、両ＣＤＤＢの体系的な構成の違いに基づく機能の優劣も顕著となっている。 　以上のように、異なる設計思想で開発された新版の被告ＣＤＤＢと原告ＣＤＤＢとは、旅行業者向けシステムのデータベースにおいて最も創作性を左右する施設情報において、もはや似ている点がないほど体系的な構成が異なっており、全く別物のデータベース構造となっている。 (ウ)　原告ＣＤＤＢとは情報の選択も異なる。 　被告アゼスタは、当初版の被告ＣＤＤＢを開発するにあたり、独自に収集したデータに加えて、原告ＣＤＤＢのデータの一部を、修正等の加工を施した上で利用した。しかし、これらのデータは、いずれも、行程表・見積書等の作成業務等の機能を有する旅行業者向けのデータベースに格納する情報としては当然かつありふれたものであり、かつその情報の選択において創作性が認められない単なる客観的なデータであるところ、このようなデータに修正等の加工を加えて利用する行為が著作権侵害となることはあり得ない。 　また、被告アゼスタは、平成１８年６月末ころの被告システム（当初版）の販売開始以降、現在まで６年以上もの長期間にわたり、膨大な手間・時間をかけて、顧客のニーズに対応してデータ内容を充実させており、継続して被告ＣＤＤＢのデータを追加・修正・削除してきた結果、現行版及び新版の被告ＣＤＤＢのデータは、当初版の被告ＣＤＤＢのデータから一新されている。 　これら具体的なデータの入力等については、前記(ｱで詳述したとおりである。 (エ)　まとめ 　以上のとおり、被告アゼスタが独自の設計思想に基づき開発した被告ＣＤＤＢと原告ＣＤＤＢとは、体系的な構成及び情報の選択のいずれの点においても大きく異なっており、さらに、被告アゼスタは、当初版・２００６年版、現行版、新版と、絶え間なく被告システムに大幅な改良・変更を加えており、被告ＣＤＤＢと原告ＣＤＤＢにおける体系的な構成及び情報の選択の点での乖離はますます甚だしいものとなっている。 　したがって、被告ＣＤＤＢは原告ＣＤＤＢに依拠したものではなく、原告の著作権（複製権）を侵害するものではない。 　また、著作物の翻案とは、既存の著作物に依拠し、かつその表現上の本質的な特徴の同一性を維持しつつ、具体的表現に修正、増減、変更等を加えて、新たに思想又は感情を創作的に表現することにより、これに接する者が既存の著作物の表現上の本質的な特徴を直接感得することのできる別の著作物を創作する行為をいうとされ、思想、感情若しくはアイデア、事実若しくは事件など表現それ自体ではない部分又は表現上の創作性がない部分において既存の著作物と同一性を有するにすぎない著作物を創作する行為は、既存の著作物の翻案に当たらないとされるところ、データベースの著作物においても、体系的な構成及び情報の選択に関して、創作性がない部分において既存の著作物と同一性を有するにすぎない著作物を創作する行為は、既存の著作物の翻案に当たらないというべきである。 　本件において、原告は、原告ＣＤＤＢの創作性について、旅行業者が行程表作成の業務を行うにあたって必要となる観光施設データ、宿泊施設データ、全国各地の主要道路の道路地点、大型観光バスの移動時間・距離、有料道路・高速道路の料金データ、鉄道・飛行機・フェリーに関する路線、駅、時刻表等の情報を収集・蓄積し、各テーブル間をプライマリー・キー等によって有機的に関連付けることで、顧客のニーズに合わせた行程表を作成できるようにした情報の分類体系であることを強調する。 　しかし、旅行業者向けのデータベースの開発に当たり、上記の情報を収集・蓄積し、各テーブル間をプライマリー・キー等によって有機的に関連付けることで、顧客のニーズに合わせた行程表を作成できるようにすること自体は、アイデアの範疇に属するものにすぎず、それ自体が創作性を基礎付けるわけではない。 　データベースの創作性においては、あくまでも体系的な構成及び情報の選択における創作性が問題となるところ、上記のとおり、被告ＣＤＤＢ（とりわけ新版の被告ＣＤＤＢ）は、データの内容についても、情報の選択において創作性を有する部分について原告ＣＤＤＢと大きく異なっているし、何より、テーブル・フィールドの構造及びリレーションについても、旅行業者向けシステムのデータベースにおいて最も創作性を大きく左右する施設情報を中心に、もはや似ている点がないほど異なっており全くの別物となっている。 　したがって、被告ＣＤＤＢ（とりわけ新版の被告ＣＤＤＢ）は、原告ＣＤＤＢとは、データベースの著作物の創作性を基礎付ける本質的な特徴が大きく異なっており、原告の翻案権を侵害するものともなり得ない。 ２　争点(2)(被告らによる著作権侵害についての共同不法行為の成否)について 〔原告の主張〕 　被告ＣＤＤＢは原告ＣＤＤＢに依拠して作成されたものであるが、依拠して作成され共通の内容となっている部分は、情報の選択及び体系的構成について創作性を有する部分であるので、被告ＣＤＤＢを製造し販売しインターネットを通じて顧客に提供する被告らの行為は、原告ＣＤＤＢについて原告が保有する著作権（複製権、翻案権、譲渡権、貸与権、公衆送信権）を侵害するものである。 　そして、被告アゼスタの代表取締役である被告Ｙ１をはじめ、被告Ｙ３、被告Ｙ２、被告Ｙ４は、Ａ及び被告Ｙ５に対し、原告ＣＤＤＢに依拠して、これと同一ないし実質的に同一である被告ＣＤＤＢを作成することを依頼ないし黙認し、Ａ及び被告Ｙ５の２名は、被告Ｙ１らの右依頼を受け、自らの意思と判断により、被告ＣＤＤＢを設計ないし作成し、被告Ｙ１、被告Ｙ３、被告Ｙ２、被告Ｙ４、被告Ｙ６の５名は、被告ＣＤＤＢを含む被告システムを販売しており、被告Ｙ１、被告Ｙ３、被告Ｙ２、被告Ｙ４、被告Ｙ６、被告Ｙ５及びＡは、これらの一連の行為により、原告ＣＤＤＢに係る原告の著作権（複製権、翻案権、譲渡権、貸与権、公衆送信権）を侵害したものと認められる。 　これらの著作権侵害行為は、被告アゼスタの代表者、取締役、監査役や従業員としての行為であるとともに、個人被告らについて、個人としての行為でもあると評価することができる。 　そして、Ａ及び被告Ｙ５は被告ＣＤＤＢの開発者として、上記のとおり原告ＣＤＤＢに依拠して、これと類似する被告ＣＤＤＢを作成しており、著作権侵害について故意があるというべきである。被告アゼスタの代表者である被告Ｙ１は、Ａ、被告Ｙ５のかかる行為を行うことを依頼し自らもその作業に加わったものであり、著作権侵害について故意があるというべきである。 　また、被告Ｙ１、被告Ｙ３、被告Ｙ２、被告Ｙ４、被告Ｙ６らは、被告アゼスタの営業担当者として、被告ＣＤＤＢが原告ＣＤＤＢに依拠して作成されたものであることを知りながら、被告ＣＤＤＢを含む被告システムをユーザーに対して提供し続けているので、著作権侵害について故意があるというべきである。 　仮に、個人被告ら及びＡに著作権侵害についての故意が認められないとしても、少なくとも過失が認められる。すなわち、個人被告ら及びＡは、原告システムの開発に中心的に携わった開発者であるＡ、被告Ｙ５が、原告システムと競合する被告システムを原告システムの開発に関するノウハウを利用して開発し、原告システムの販売に中心的に携わっていた営業担当者である被告Ｙ３、被告Ｙ２、被告Ｙ４、被告Ｙ６が、被告システムを原告システムの既存ユーザーに対して販売するという事業計画の下で新会社である被告アゼスタを設立し、被告システムを開発し販売しようとしたものであり、原告システムに関する著作権侵害を行う可能性のある行為をあえて行おうとしていたことになる。個人被告ら及びＡには、被告ＣＤＤＢを含む被告システムが、原告ＣＤＤＢを含む原告システムに関する著作権を侵害しない製品となるように、開発を実施させ、著作権侵害品をユーザーに提供しないという注意義務があったというべきであるが、個人被告ら及びＡはかかる注意義務に違反しているので、少なくとも著作権侵害に関して過失があるというべきである。 　以上のとおり、本件著作権侵害は個人被告らの故意ないし少なくとも過失により行われたものである。 〔被告らの主張〕 　否認し、争う。 　被告ＣＤＤＢは、情報の選択という点のみならず、そもそも体系的な構成からして原告ＣＤＤＢと大きく異なっており、被告らは原告の著作権を何ら侵害しておらず、また被告アゼスタが原告ＣＤＤＢのデータの一部を利用した行為について不法行為とはなり得ない。 　したがって、被告らの行為が原告に対する不法行為を構成することはない。 ３　争点(3)（一般不法行為の成否〔予備的主張〕）について 〔原告の主張〕 (1)　民法７０９条にいう一般不法行為の成立要件としての権利侵害は、必ずしも厳密な法律上の具体的権利の侵害であることを要せず、法的保護に値する利益の侵害をもって足りる。そして、対象となる作品や製品が著作物に該当しない場合でも、第三者によるそれらの複製、頒布、販売、公衆送信等の利用行為が自由競争の範囲を逸脱し、社会的な許容限度を超える場合には、一般不法行為として権利侵害となる。 　データベースに関しても、人が費用や労力をかけて体系的構成を構築し、情報を収集、整理することで、データベースを作成し、そのデータベースを製造販売することで営業活動を行っている場合において、第三者が無断で、そのデータベースの体系的構成、選択収集されたデータを複製して作成したデータベースを、その者の販売地域と競合する地域において販売する行為は、公正かつ自由な競争原理によって成り立つ取引社会において、著しく不公正な手段を用いて他人の法的保護に値する営業活動上の利益を妨害するもので、自由競争の範囲を逸脱し、社会的な許容限度を超えるものであるので、不法行為を構成するというべきである。 (2)　被告らによる自由競争の範囲を逸脱する行為 ア　原告ＣＤＤＢの作成経緯 　原告ＣＤＤＢは、体系的構成の構築、情報の取得及び入力されたデータの適否のチェックに多大な費用及び労力を費やして作成されたものである。 　原告ＣＤＤＢを含む原告システムは、翼システムが平成６年（１９９４年）７月から開発を開始し、平成８年（１９９６年）１月に完成して販売を開始した「スーパーフロントマン 旅行業システム」が元となっており、その後改良が加えられてきたものである。翼システム時代も含め、原告は、日本全国に原告ＣＤＤＢを含む原告システムを販売し現在に至っている。 　被告ＣＤＤＢの２００６年版にデッドコピーされたテーブルＩＤやフィールドＩＤから見ると、被告らは、平成１８年（２００６年）頃までに原告ＣＤＤＢをデッドコピーした上、当初版、２００６年版、現行版及び新版を作成しているものと推認されるが、翼システムないし旧原告会社は、平成６年（１９９４年）７月の開発開始時から平成１８年（２００６年）頃までの間、原告ＣＤＤＢの開発及び維持には、開発要員として少なくとも常時１０人以上従事させ、その間、開発費用として少なくとも７億円以上を費やしてきた。 イ　被告らによる原告ＣＤＤＢの体系的構成及び選択収集した情報の流用 　被告Ｙ２、被告Ｙ３、被告Ｙ４、被告Ｙ５、被告Ｙ６は翼システムの従業員であったところ、営業譲渡に伴い、原告に移籍してきたものである。上記被告らは翼システムないし旧原告会社在職中に原告ＣＤＤＢを備える原告システムの開発、販売に従事していたものであり、原告ＣＤＤＢにアクセスしていたものである。 　体系的構成の流用状況、収集した情報の流用状況については前記２争点(2)〔原告の主張〕のとおりである。すなわち、被告らは、道路情報、道路地点情報についてコピーしたことを認めているところ、その他の情報についてもデッドコピーしている痕跡が多々存在する（甲９、２１、２３、２８、３７）。被告ＣＤＤＢはまず原告ＣＤＤＢをデッドコピーし、それを元に当初版、２００６年版、現行版、新版と作成してきたものであり、各版作成の都度流用を隠蔽するために一部改変を加えたものである。その結果、被告ＣＤＤＢには原告ＣＤＤＢから改変されている部分（甲２３、３５、３６、３７）も一部あるが、総じてデッドコピーの状況といえる。 　ほぼデッドコピーそのものである当初版・２００６年版の作成から始まり、その後少しずつ改変を加えて、現行版、新版が作成されたという経過に鑑みると、被告ＣＤＤＢにおける改変部分の多くは、テーブルＩＤ、フィールドＩＤ、道路地点の緯度経度情報の改変が典型例であるが、それらは流用の事実を隠蔽しようとしてされているのであって、かかる改変によりデッドコピーでない部分が生じるとしても、そのことは、むしろ被告らの行為の悪質性を顕著に示すものであって、社会的に許容限度内の行為であることを基礎づける事実には到底ならない。 ウ　被告らによる原告の顧客の不当な奪取行為 　原告ＣＤＤＢのような観光施設、宿泊施設、道路、各種交通機関の時刻表等の様々な情報をデータベースとして備え、旅行業者向けの行程表が作成できるパッケージソフトウェアは、被告らが被告ＣＤＤＢを備える被告システムを平成１８年６月から販売するまで、日本国内市場に原告システム以外に存在しなかった。それまでは、原告は日本全国に原告ＣＤＤＢを含む原告システムを販売してきたものである。 　しかるに、原告システムの開発・営業に携わった個人被告ら（被告Ｙ１を除く。）は、原告を退職した上、被告アゼスタを設立し、原告ＣＤＤＢをデッドコピーあるいは一部改変した被告ＣＤＤＢを備える被告システムを作成し、主に原告システムのユーザーに対して大幅な値引きを行って売り込みをかけ、原告の顧客を奪ったものである。被告らは原告ＣＤＤＢを流用することによって開発費をかけずに被告ＣＤＤＢを作成し、安価な製品の提供を行って原告の顧客をターゲットにして顧客を奪ってきている。被告らが奪った顧客数は、被告ら自身が明確に認めるものだけでも平成２０年（２００８年）７月時点で１８２社（甲５２）、平成２２年（２０１０年）１１月時点で３００社（甲５３）に及び、現時点ではその数は優に３６０社を超えている。なお、被告らは平成２２年（２０１０年）１１月時点で被告ＣＤＤＢを含む被告システムのユーザーが約５００社であることも認めている。 　原告の元従業員である被告らが原告を退職後被告アゼスタを設立し、原告ＣＤＤＢを含む原告システムの顧客に対して、原告が長年多大な費用や労力をかけて作成したデータベースである原告ＣＤＤＢをそのまま複製等して、作成した被告ＣＤＤＢを含む被告システムを大きな値引きを行って販売し、原告システムを被告システムに乗り換えさせて原告の顧客を奪うという行為は、故意、あるいは少なくとも過失により、取引における公正かつ自由な競争として許される範囲を甚だしく逸脱し、法的保護に値する原告の営業活動を妨害しその営業上の利益を侵害するものとして不法行為を構成するというべきである。 　なお、原告ＣＤＤＢの開発及び維持管理は、平成１７年１２月３０日までは翼システムが行ったものであるが、原告は、平成１７年１２月３０日に翼システムから営業譲渡を受けて、原告ＣＤＤＢを含む原告システムについて、著作権のほか一般不法行為上の権利も原告に譲渡されたものであり、原告ＣＤＤＢについて、原告が一般不法行為上の権利を保有する。 (3)　個人被告らの責任 　被告Ｙ１、被告Ｙ３、被告Ｙ２、被告Ｙ４、被告Ｙ５は、互いに相談の上、原告ＣＤＤＢを含む原告システムと競合する旅行業システムを開発販売する被告アゼスタを設立し、Ａ及び被告Ｙ５は、原告ＣＤＤＢを含む原告システムに依拠して、これと実質的に同一ないし類似する被告ＣＤＤＢを含む被告システムを開発し、被告Ｙ１、被告Ｙ３、被告Ｙ２、被告Ｙ４、被告Ｙ６は、被告ＣＤＤＢを含む被告システムを原告システムの販売地域と競合する地域にて販売し、原告の営業上の利益を侵害しているのであるから、個人被告ら及びＡは、これらの一連の行為により一般不法行為を行っているものである。 　そして、これらの行為は、被告アゼスタの代表者（被告Ｙ１）、取締役（被告Ｙ２、被告Ｙ３）、監査役（Ａ）や従業員（被告Ｙ４、被告Ｙ６）としての行為であるとともに、個人被告らの個人の行為でもあると評価することができ、被告アゼスタ、個人被告ら及びＡによる共同不法行為であるといえる。 　したがって、原告に対する一般不法行為について、被告らは、共同不法行為責任を負うというべきである。 　Ａ及び被告Ｙ５は、被告ＣＤＤＢを含む被告システムが原告システムと競合する地域にて販売されることを認識しながら、原告ＣＤＤＢの体系的構成やデータを流用した被告ＣＤＤＢを作成しているので、原告の利益を侵害することについて故意があるというべきである。 　また、被告Ｙ１、被告Ｙ３、被告Ｙ２、被告Ｙ４、被告Ｙ６らは、被告アゼスタの営業を通じて、被告ＣＤＤＢが原告ＣＤＤＢの体系的構成やデータを流用して作成されたものであることを知りながら、被告ＣＤＤＢを含む被告システムを原告システムの販売地域と競合する地域のユーザーに対して提供し続けているので、原告の利益を侵害することについて故意があるというべきである。 　仮に、個人被告ら及びＡに故意がなかったとしても、個人被告ら及びＡには、少なくとも過失が認められる。すなわち、原告システムの開発に中心的に携わった者であるＡ、被告Ｙ５が、原告システムと競合する被告システムを開発し、原告システムの販売に中心的に携わっていた者が被告システムを販売するという事業計画の被告アゼスタを設立したのであるから、被告ＣＤＤＢも含め被告システムの開発販売が不公正な手段を用いて原告の法的保護に値する営業活動上の利益を侵害することにならないように、開発販売を行うべき注意義務があったというべきであるが、個人被告ら及びＡはかかる注意義務に違反しているので、少なくとも過失があるというべきである。 　以上のとおり、本件共同不法行為は被告らの故意により、仮に故意が認められないとしても少なくとも過失により行われたものである。 　したがって、被告らは、原告に対し、上記不法行為により原告が被った損害を賠償する責任を免れない。 〔被告らの主張〕 (1)　データの違法な流用及び顧客奪取行為は存しないこと ア　被告アゼスタが当初版の被告ＣＤＤＢの開発にあたり利用した原告ＣＤＤＢのデータは、いずれも行程表・見積書等の作成業務等の機能を有する旅行業者向けのデータベースに不可欠であり、かつその情報の選択において創作性が認められない単なる客観的なデータである。著作権侵害に至らない行為を不法行為と捉えることは、著作権法の趣旨を潜脱するものであり許されるべきではないし、職業選択の自由（憲法２２条１項）の重要性に鑑み、在職中に業務を通して取得した知識・技能に基づいて行う行為は原則として自由競争の範囲内のものとして許容されるべきである。したがって、本件で被告アゼスタが原告ＣＤＤＢのデータの一部を利用した行為については、不法行為とはなり得ない。 　また、原告は、原告ＣＤＤＢが多大な費用や労力をかけて開発されたと主張するが、これも実態とは大きく異なる。平成８年１月に販売開始された原告ＣＤＤＢは、日本観光協会の観光施設データと、旧国際観光旅館連盟・旧日本観光旅館連盟の加盟施設、政府登録国際観光旅館の宿泊施設が登録されているのみで、旅行業者にとっては全く不十分なものであり、とても顧客を満足させるようなものではなかった。特に、原告ＣＤＤＢの観光施設データについては、旅行業者が送客手数料を受領できる施設の登録に不備があり、これが販売面での致命傷となっていたため、無断転記を禁じられている料金ガイドから全てのデータを転用して観光データを入力した。実際、被告Ｙ２がヘッドハンティングを受けて翼システムに入社した平成８年２月当時、翼システムでは、情報企画事業部で旅行営業課が設立されたばかりで、原告ＣＤＤＢも上記のとおり試作品レベルのものであった。しかし、前職で旅行業者向けのトータル業務システム販売業務に従事して旅行業務システム構築のノウハウを熟知していた被告Ｙ２や被告Ｙ５、主たる開発者であったＡらが中心になって、原告ＣＤＤＢの観光施設・宿泊施設データの増加や改良がなされ、わずか３か月後の平成８年５月には販売してもクレームにならない程度まで原告ＣＤＤＢの品質が改善され、現在の原告ＣＤＤＢと同等のレベルの性能を備えるに至ったものであり、多大な費用や労力をかけて原告ＣＤＤＢが開発されたとはいえない。 イ　原告は、被告システム販売開始後、被告らが原告の顧客をターゲットとし残リース期間の短いところから順次「狙い撃ち」して営業を行っていたと主張する。 　しかし、被告らは、原告の顧客のみをターゲットにしていたものではなく、当然、その他の旅行会社にも営業を行っていた。また、被告Ｙ３、被告Ｙ２、被告Ｙ４及び被告Ｙ６は残リース期間の長短に関係なく営業を行っていたし、残リース料を負担とするというのはごく普通のことであり、実際被告アゼスタに限らず同業他社も同じ営業方法をとっている。前記のとおり、そもそも原告の顧客が被告システムに変更したのは、単に原告システムの不具合やメンテナンス不足に対する不満と被告システムの優位性が理由であるから、被告らの営業は完全に自由競争の範囲内のものである。 (2)　被告ら各人に不法行為は成立しないこと ア　被告Ｙ１の責任につき 　被告Ｙ１は、そもそも翼システムに在職してもおらず、株式会社グッドウィルの取締役、株式会社エス・エス・アイ・トリスター及び株式会社トリスターの代表取締役を務めた経験を買われ、被告Ｙ３及び被告Ｙ２と友人関係にあったこと等から、被告アゼスタの代表取締役に就任したにすぎない。被告Ｙ１には、被告アゼスタの代表取締役就任以前にデータベースやプログラムの開発に関与した経験は全くなく、その専門的知識も何ら持ち合わせていなかった。実際に、被告Ｙ１は、被告ＣＤＤＢの早期販売のためにやむを得ず、独自に収集したデータに加えて、被告アゼスタ社内にあった原告ＣＤＤＢのメンテナンスＣＤのデータの一部を利用することとした際にも、当該データをそのまま被告ＣＤＤＢで利用するのではなく、そのまま利用しても顧客からクレームの対象になるだけであるから、旅行業者向けのデータベースに格納する情報としては当然かつありふれた客観的なデータの正誤を確認し必要な修正等を加えた上で利用するように指示していたにすぎない。そして、被告Ｙ１としては、被告ＣＤＤＢが被告アゼスタの独自の設計思想に基づき開発され、その体系的構成は原告ＣＤＤＢと大きく異なっている以上、客観的データの一部を修正して利用する行為は、自由競争の範囲内の行為として当然許容されると認識していたものである。 　以上からすれば、被告Ｙ１には、原告の企業秘密に接する機会がなかったことに加えて、そもそも原告の営業活動を違法・不当に侵害する故意などなく、被告ＣＤＤＢの開発・販売に際して、原告の著作権侵害とならないように慎重な配慮も尽くしているから、過失もない。 　したがって、被告Ｙ１に不法行為は成立しない。 イ　被告Ｙ５の責任につき 　被告Ｙ５は、被告システムのデータベース開発を担当していたところ、被告Ｙ１の指示を受けて、被告アゼスタが独自に収集したデータに加えて、原告ＣＤＤＢのデータのうち、旅行業者向けのデータベースに格納する情報としては当然かつありふれた客観的なデータについて、必要な修正等を加えた上で利用することにした。確かに、被告Ｙ５としては、長年翼システムにおいて原告ＣＤＤＢの開発に携わっており、原告ＣＤＤＢの内容を熟知してはいたが、翼システムから原告ＣＤＤＢのメンテナンスＣＤを含めデータベース設計資料等の機密情報を持ち出しすようなことは一切していなかったし、被告ＣＤＤＢが被告アゼスタの独自の設計思想に基づき開発され、その体系的構成が原告ＣＤＤＢと大きく異なっている以上、旅行業者向けのデータベースに格納する情報としては当然かつありふれた原告ＣＤＤＢの客観的データの一部を修正して利用する行為は、自由競争の範囲内の行為として当然許容されると認識していた。 　以上からすれば、被告Ｙ５は、そもそも原告の営業活動を違法・不当に侵害する故意などなく、被告ＣＤＤＢの開発・販売に際して、原告の著作権侵害とならないように慎重な配慮も尽くしているから、過失もない。 　したがって、被告Ｙ５に不法行為は成立しない。 　なお、原告は、被告アゼスタの行為は、被告ら個人としての行為でもあると評価することができ、被告らに不法行為ないし共同不法行為が成立するとも主張しているが、被告アゼスタの役員でもなく被告Ｙ１の指示に従って被告ＣＤＤＢの開発に関与していた被告Ｙ５に、被告アゼスタの会社としての行為の責任を帰責させるべきではなく、この意味でも不法行為ないし共同不法行為は成立し得ない。 ウ　被告Ｙ３、被告Ｙ２、被告Ｙ４及び被告Ｙ６の責任につき 　被告Ｙ３、被告Ｙ２、被告Ｙ４及び被告Ｙ６は、被告システムの営業担当であり、そもそもデータベースの設計や構造を含む開発に関する知識を持ち合わせていない。被告Ｙ３は、翼システム時代に開発に関する会議に参加していたことはあるが、それも顧客目線でどのような画面であれば見易いか等の営業の立場からのアドバイスをしていただけで、それによってデータベース開発の知識を習得していたものではない。被告システムの開発においても、被告Ｙ３、被告Ｙ２、被告Ｙ４については、単純なデータ入力作業の一部を手伝うことはあったが、それ以上に被告システムの開発には特に関与しておらず、その開発経過については知らないし、原告システムのデータが一部利用されていることも特に認識していなかった。 　また、被告Ｙ３、被告Ｙ２、被告Ｙ４及び被告Ｙ６は、原告の顧客リストの持ち出しなどもしていない。被告Ｙ３、被告Ｙ２、被告Ｙ４及び被告Ｙ６は皆、自分が探索した顧客名やその担当者については、何度も通っており当然頭の中で覚えていたし、一般に流通している旅行業者名簿を見れば簡単に連絡先も探すことができたことから、顧客リストなど不要であり、わざわざ持ち出す必要もなかった。 　さらに、被告Ｙ３、被告Ｙ２、被告Ｙ４及び被告Ｙ６は、原告システムのインストール用ＣＤを所持し取扱うことは会社から一切許されておらず、納品などのインストール作業はサポート部門に依頼するという社内ルールがあったため、被告Ｙ３、被告Ｙ２、被告Ｙ４及び被告Ｙ６がこれを手にしたことなど一度もなく、管理も厳重であったため所在すら知らなかったし、顧客へのデモンストレーション用に使っていたＰＣについても、原告退職時に返却又は退職後は特に使用していない上、インストールされているデータをコピーして持ち出すこともしていないしその方法すら知らなかった。 　何よりも、被告Ｙ３、被告Ｙ２、被告Ｙ４及び被告Ｙ６は、顧客からの度重なるクレームにも対応しない原告システムの内容に強い不満を持ち、顧客のためよりよい製品を提供したいという思いから、原告を退職し、各々に集まり被告アゼスタの設立に尽力した者たちであるから、原告システムを単にコピーした商品を販売する意思など毛頭なかったし、そのようなことを行えば再びクレームに晒されるだけということも十分に自覚していた。 　特に、被告Ｙ６については、被告システムの当初版の販売開始（平成１８年６月）及び２００６年版の販売開始（平成１８年１１月）後の同年１２月に入社したものである。このように、入社時期から考えて被告システムの開発には全く関与していないことは明らかであるし、最新の顧客リストやインストール用ＣＤの最新版等を持ち出したこともなく、被告ＣＤＤＢのデータ入力作業には一切関与していないのである。なお、被告Ｙ６は、被告Ｙ２ら他の営業担当者から積極的な引き抜きの勧誘を受けたものではなく、原告の顧客不在の営業方針に失望して自らの意思で退社し被告アゼスタに入社したものである。 　したがって、被告Ｙ３、被告Ｙ２、被告Ｙ４及び被告Ｙ６に不法行為が成立する余地はない。 エ　被告アゼスタの責任につき 　被告アゼスタについては、上記のとおり、被告Ｙ１、被告Ｙ５、被告Ｙ３、被告Ｙ２、被告Ｙ４及び被告Ｙ６のいずれにも故意・過失はなく、その使用者たる被告アゼスタにも不法行為は成立しない。 ４　争点(4)(原告の行為の独占禁止法違反の可能性の有無）について 〔被告らの主張〕 　仮に、原告システム及び被告システムのような、行程表・見積書の作成及び出力、売上・集計・顧客管理のトータルサポートを可能とする旅行業向けシステムを開発・販売している業者が原告と被告アゼスタの二社のみで、寡占状況となっているとすれば、原告の本件訴えの提起による被告ＣＤＤＢの差止請求及び損害賠償請求は、原告一社による市場独占を企図するものと考えられ、競争原理を機能させずに利用者にとっての利便性向上を著しく阻害する結果をもたらすものであるから、まさに、同業者である被告アゼスタの事業活動を排除することにより、公共の利益に反して、一定の取引分野における競争を実質的に制限するものに他ならず、独占禁止法２条５項、３条に違反している可能性すらある。この意味でも、原告の請求は速やかに棄却されるべきである。 〔原告の主張〕 　被告らは、独占禁止法違反の可能性を指摘し、原告の請求は速やかに棄却されるべきであると主張するが、訴えの提起が私的独占となる理由は全くない。訴えの提起によって旅行業システムに関する市場への参入を制限しているわけではないし、被告アゼスタの事業活動を支配しているわけでもない。また、原告による訴えは著作権の権利行使であり、そもそも独占禁止法の適用は除外される（独占禁止法第２１条）。 ５　争点(5）（被告らの損害賠償義務の有無及び原告の損害額）について 〔原告の主張〕 (1)　被告らの損害賠償義務 　前記のとおり、被告らは、原告ＣＤＤＢをデッドコピーした上、若干の変更を加えて被告ＣＤＤＢを作成し販売してきているものであり、原告ＣＤＤＢの著作権侵害ないし原告の法的に保護された利益を侵害する一般不法行為について、故意ないし過失がある。 　そして、原告は、被告らが被告ＣＤＤＢを含む被告システムを販売したことにより、以下の損害を被ったものであるから、被告らは、著作権法１１４条１項ないし民法７０９条により、以下のとおり、原告に生じた損害を賠償する義務を負う。 (2)　原告の逸失利益 ア　原告システムと被告システムとの関係 　被告らは、被告システムを平成１８年６月頃から平成２２年１１月頃に至るまで、ユーザーに対して、少なくとも５００本（少なくとも当初版２２本、２００６年版７８本、現行版４００本）販売し（甲５３）、各販売先のユーザーと更新データを提供するデータメンテナンス契約を締結している。 　被告システムにおいて被告ＣＤＤＢは必須なものであり、被告ＣＤＤＢがなければ、ユーザーが被告システムを購入することはない。また、原告ＣＤＤＢや被告ＣＤＤＢのような観光施設、宿泊施設、道路、各種交通機関の時刻表等の様々な情報をデータベースとして備え、旅行業者向け行程表が作成できるシステムは、パッケージソフトウェアとしては原告システムと被告システム以外には市場に存在せず、原告システムと被告システムには、あるユーザーに対して被告システムが販売されなければ、当該ユーザーに原告システムが販売され、原告と当該ユーザー間に更新データを提供するデータメンテナンス契約が締結される、という関係がある。 　したがって、被告ＣＤＤＢを含む被告システム５００本の販売により、原告は原告システム５００本の販売にかかる利益及びデータメンテナンス契約にかかる利益を失ったものであり、かかる逸失利益は原告が被った損害となる。 　原告の逸失利益は、原告システム１本分及び原告のデータメンテナンス１件分につき失われた売上額から、それぞれ原告システムの製造・販売のための変動経費又はデータメンテナンスのための変動経費を控除した限界利益につき、５００本分を計算すべきことになる。 イ　被告システムの販売にかかる原告の逸失利益（原告システム販売に関する損害額） 　被告システムの販売にかかる原告の逸失利益は、原告システム「旅行業システムＳＰ」のＴＲ−Ｐ４（甲６８）に基づいて計算すべきところ、詳細は以下のとおりである。 　被告システムである「旅ｎｅｓＰｒｏ」は、検索業務、行程・見積業務、売上・集計業務が全て含まれるシステムであるところ（甲１の２）、これに対応する原告システムである「旅行業システムＳＰ」の基本システムのタイプはＴＲ−Ｐ４である（甲５９、６８。なお、平成１９年９月以降、「ＴＲ−ＳＰ４」にバージョンアップされ、その標準価格はいずれも２２０万円である。以下、「ＴＲ−Ｐ４」と「ＴＲ−ＳＰ４」を併せて「ＴＲ−Ｐ４等」という。）。上記のとおり、被告システムの販売により、原告システムである「旅行業システムＳＰ」の基本システムであるＴＲ−Ｐ４等の販売にかかる利益が失われる関係にあるので、原告の逸失利益はＴＲ−Ｐ４等に基づいて、計算すべきである。 　ただし、被告システムの販売が開始された平成１８年６月以降は、原告も被告システムの販売価格に対抗するため原告システムの値下げを余儀なくされたことを考慮すると、平成１８年当時の原告システムＴＲ−Ｐ４の販売価格及び限界利益を前提に原告の逸失利益（損害）を算定すべきである。 　平成１８年１月から１２月までの原告システムＴＲ−Ｐ４は３７台販売され、その売上総額は７１２７万８０７４円であるので、平均実売価格は１台あたり１９２万６４３４円となる（甲６９）。 　平成１８年度（１月から１２月まで）における原告システム販売の限界利益率は以下のとおり少なくとも８３．４％であるので、原告システム１台を販売することによる限界利益は少なくとも１６０万６６４６円となる（甲６９）。 　原告の平成１８年度（１月から１２月まで）の原告システム関連の売上高は２億２１６６万７１５４円であり、原告システムの製造販売にかかる、変動経費は、仕入高、残債、販売手数料、販促費・リース料Ｓ、販促費・その他、インセンティブ、外注費、物流費であり、その合計は３６８３万２０４５円となる。 　平成１８年度の原告システムの売上高２億２１６６万７１５４円に対する上記変動経費合計３６８３万２０４５円の比率は、１６．６％となる。 　したがって、原告システムの限界利益率は、８３．４％となる。 　被告システム販売にかかる原告の逸失利益（損害）は以下のとおりとなる。 　１９２万６４３４円（原告システムの平均実売価格）×５００（本）×０．８３４（限界利益率）＝８億０３３２万２９７８円 ウ　被告システム販売にかかる原告の逸失利益（原告システムのデータメンテナンス契約についての損害額） 　データメンテナンスは、原告システムを導入するユーザーとの間で毎月ユーザーに更新データを提供するためのもので、１本あたり月額６０００円で提供される。この月額料金は平成１８年１月時点から現在に至るまで変わっていない。 　平成１８年度（１月から１２月まで）における原告における全システムに関するデータメンテナンスの限界利益率は、以下のとおり少なくとも８０．６％であり、原告システムのデータメンテナンスの限界利益率も少なくとも８０．６％と考えられる（甲６９）。 　原告の平成１８年度（１月から１２月まで）のデータメンテナンスの売上は１０億４７４２万９０８８円であり、データメンテナンスにかかる変動経費は、仕入高、残債、販売手数料、販促費・リース料Ｓ、販促費・その他、インセンティブ、外注費、物流費であり、その合計は２億０３０９万８４５１円となる。 　平成１８年度の原告におけるデータメンテナンスの売上高１０億４７４２万９０８８円に対する上記変動経費合計２億０３０９万８４５１円の比率は、１９．４％となる。 　したがって、原告におけるデータメンテナンス契約の限界利益率は、８０．６％となる。 　原告システムのデータメンテナンスに関する逸失利益（損害）は以下のとおりとなる。 　被告らは、被告システムを少なくとも以下のとおり５００本（平成１８年度に少なくとも当初版２２本、２００６年版７８本合計１００本、平成１９年度から２２年度までに現行版を各年度少なくとも１００本合計４００本）販売し、各販売先とデータメンテナンス契約を締結していることから、データメンテナンス契約についての逸失利益にかかる原告の損害は以下の計算により少なくとも８７０４万８０００円となる。 (ア)　平成１８年度 ５８０万３２００円 　平成１８年度における被告の販売本数は、当初版が２２本、２００６年版が７８本の合計１００本である。したがって、原告の損害額は、次のとおり、５８０万３２００円となる。 　６０００円×１２（か月）×１００（本）×０．８０６＝５８０万３２００円 (イ)　平成１９年度 １１６０万６４００円 　平成１９年度における被告の販売本数は、当初版が２２本、２００６年版が７８本、現行版が１００本の合計２００本である。したがって、原告の損害額は、次のとおり、１１６０万６４００円となる。 　６０００円×１２（月）×２００（本）×０．８０６＝１１６０万６４００円 (ウ)　平成２０年度 １７４０万９６００円 　平成２０年度における被告の販売本数は当初版２２本、２００６年版７８本、現行版２００本の合計３００本である。したがって、原告の損害は、次のとおり、１７４０万９６００円となる。 　６０００円×１２（月）×３００（本）×０．８０６＝１７４０万９６００円 (エ)　平成２１年度 ２３２１万２８００円 　平成２１年度における被告の販売本数は、当初版２２本、２００６年版７８本、現行版３００本の合計４００本である。したがって、原告の損害は、次のとおり、２３２１万２８００円となる。 　６０００円×１２（月）×４００（本）×０．８０６＝２３２１万２８００円 (オ)　平成２２年度 ２９０１万６０００円 　平成２２年度における被告の販売本数は当初版２２本、２００６年版７８本、現行版４００本の合計５００本である。したがって、原告の損害は、次のとおり、２９０１万６０００円である。 　６０００円×１２（月）×５００（本）×０．８０６＝２９０１万６０００円 エ　小括 　以上から、原告の逸失利益にかかる損害額合計は、以下のとおり８億９０３７万０９７８円となる。 　８億０３３２万２９７８円＋８７０４万８０００円＝８億９０３７万０９７８円 (3)　弁護士費用 　相当な弁護士費用は２０００万円を下らない。 (4)　損害額の合計 　上記(2)及び(3)の合計額は９億１０３７万０９７８円となる。 (5)　予備的主張に係る損害額 　予備的主張（一般不法行為）に係る損害額も、上記著作権侵害に基づく損害額と同額である。 〔被告らの主張〕 (1)　原告の主張(1)は否認する。被告らに著作権侵害ないし一般不法行為についての故意ないし過失がないことについては、前記４争点(4)〔被告らの主張〕のとおりである。 (2)　原告の主張(2)ないし(5)は、否認ないし争う。 ア 被告システムは、平成１８年６月から平成２４年１２月までの６年６か月もの期間をかけて、当初版・２００６年版、現行版、新版と順次改良され、被告ＣＤＤＢ部分はもちろんのこと、その他のデータベースについても、データベースの構造はもちろんデータの数・内容も大幅に変更しており、さらにはプログラムにも改良が加えられている。しかるに、原告は、これらの違いを全く考慮せずに、当初版、２００６年版、現行版の全ての販売数について損害賠償を求めているが、およそ因果関係は認められない。 　また、原告は、その著作権が侵害されたと主張する対象について、当初原告システム全体としていたものを、訴えの変更により原告ＣＤＤＢへと大幅に縮小したにもかかわらず、当該著作権侵害による損害額については、原告システム全体を前提とした金額から一切減額しておらず、整合性がない。 　原告が問題とする原告ＣＤＤＢは、行程・見積機能が参照する一部のデータしか有しておらず、当該部分は、原告システムの旅行業者向けシステムとしての本質的機能が「旅行業者がその業務を遂行する上で必要不可欠な行程表・見積書の作成及び出力、売上・集計・顧客管理のトータルサポート」というところにあることからすれば、わずか一部分にすぎない。テーブル数及びフィールド数についても、原告システムに係るデータベースが合計６０個のテーブル（４６個のマスターテーブル及び１４個のエントリーテーブル）を有し、合計９３８個のフィールドを含んでいたのに対し、原告ＣＤＤＢは原告の主張によっても４２個のマスターテーブルと４０５個のフィールドを有するに留まっている。 　しかも当然ながら、実際のデータベースは、デジタルデータの集合体とこれを管理・処理するコンピュータ・プログラムとが不可分一体となって稼働するものであり、本件の旅行業者向けシステムもデータベースとプログラムとが不可分一体となって機能するところ、原告システムと被告システムとはそのデータベースのみならずプログラムについても全く異なっており、かかるプログラム上の差異から生じる機能の違いも極めて大きい。 　以上の点を考慮すると、仮に万一著作権侵害又は不法行為の事実が認められるような場合であっても、原告が主張する損害はそのほとんど全てが減殺されるべきである。 イ　原告は、原告システムの基本システムのタイプはＴＲ−Ｐ４（標準価格は２２０万円）であると主張して、これを前提に限界利益率を算定している。しかし、原告システムは、行程表・見積書作成機能のみのＴＲ−Ｐ１（標準価格は１７０万円）と、ＴＲ−Ｐ１の機能に加えて売上・顧客管理機能（同機能には原告ＣＤＤＢは含まれていない）が追加されたＴＲ−Ｐ４とがあり、原告ＣＤＤＢは、行程表・見積書作成機能部分のみにしか含まれていないから、標準価格でＴＲ−Ｐ１を５０万円も上回るＴＲ−Ｐ４の販売価格を基準として損害額を算定するのは明らかに過大であって、不当である。 　さらに、原告は、標準価格を大幅に下回る値引きを行っており、自ら標準価格「１本２２０万円」と主張する原告システムを７０万円にも満たない金額（標準価格の３０％以下）で顧客に販売している（乙３２）。この点に関して原告は、被告システムの販売が開始された平成１８年６月以降は、被告システムの販売価格に対抗するため原告システムの値下げを余儀なくされたなどと主張するが、全く事実に反する。被告システムが販売される平成１８年６月以前も、原告システムは、標準価格を大幅に下回る金額で販売されており（乙３６の１〜２６）、ＴＲ−Ｐ１のみならずＴＲＰ４をも含めた合計３０本の販売数の平均販売価格は約１０６万円にすぎない。原告は、何ら客観的資料も示さずに報告書（甲６９）のみを根拠として、平成１８年１月から１２月までの原告システムＴＲ−Ｐ４は３７台販売されその売上総額は７１２７万８０７４円であり、平均実売価格は１台当たり１９２万６４３４円となる、などと主張するが、翼システムが標準価格の半額近くまで大幅に値引きして原告システムを販売してきた実績（ＴＲ−Ｐ１及びＴＲ−Ｐ４が標準価格で販売されたことは一度もない。）からすれば、到底信用できない。 　また、旅行業者向け行程表作成システムを販売する業者は被告アゼスタ以外にも存在するし、旅行業者全体の傾向として団体旅行の激減、インターネット等の普及により、旅行業者を通さない個人での予約の増加に伴い、売上減少、経費削減を強いられている中、データメンテナンスも十分に行われないパッケージソフトウェアが、平成１８年当時の価格を維持できるはずがない。 　したがって、そもそも原告システムのＴＲ−Ｐ４ではなくＴＲ−Ｐ１の販売価格によらなければ不合理であるし、ＴＲ−Ｐ１の販売価格についても、標準価格（１本１７０万円）ではなく、大幅に値引きされて販売されている事実に即した実売見込価格によるべきであるから、原告の主張は失当である。 ウ　原告は、平成１８年１月から現在に至るまでデータメンテナンスの月額料金は１本６０００円であると主張するが、事実に反する。実際は月額２０００円で顧客とデータメンテナンス契約を締結している（乙３３）。 　さらに、被告システムが販売される平成１８年６月以前も、原告システムのデータメンテナンス料金は、大きな値引きがされており、合計２９本のデータメンテナンス契約の平均料金は約１８１０円にすぎない（乙３６の１〜２６）。 　したがって、月額６０００円のデータメンテナンス料金を前提として逸失利益を算出する原告の主張も失当である。 (3)　被告らの主張 　原告は、観光施設、宿泊施設、道路、各種交通機関の時刻表等の様々な情報をデータベースとして備え、旅行業者向け行程表が作成できるシステムは、パッケージソフトウェアとしては原告システムと被告システム以外には市場に存在せず、原告システムと被告システムには、被告システムが販売されなければ、当該ユーザーに原告システムが販売され、さらに原告と当該ユーザー間にデータメンテナンス契約が締結されるという関係があると主張するが、以下のとおり、そのような事実は全くない。 　まず、旅行業者向け行程表作成システムは、原告システム及び被告システム以外にも、株式会社エヌシステムのＪＡ旅行センター向け旅行業営業支援システム「応援団くん」、 株式会社ＪＭＣの国内行程表管理システム「ezROUTE」、株式会社全旅の観光商品流通システム「ＡＮＴＡ−ＮＥＴ」、株式会社ワールドエキスプレスの国内／海外旅程表作成・見積集計の旅行業支援システム「World TAC」などがあり（乙３５の１〜４）、現に上記各社は、被告アゼスタとも原告とも競合している。さらに、その他にも行程表・見積書作成業務支援システム「旅の助」を展開する株式会社エイブルシステムズや「シンフォニーアトゥー」を展開する株式会社ウィ・キャンなど（乙３５の５〜６）、シンプルな行程表作成機能ではあるが団体旅行が激減した昨今ではかえって業者ニーズに即しており、競合することも多くなっている。 被告システムは、原告システムと同額以上で販売しているところ、仮に単に原告システムのデータベースをコピーしただけの模倣品レベルのものであれば、原告システムの既存ユーザーからすれば、会社規模も資本規模も被告アゼスタとは比較にならないほど大きい原告が販売するシステムから新興の企業で資本規模も原告の約５６０分の１、従業員数もパートを含め１２名にすぎない被告アゼスタが販売するシステムにあえて乗り換える必要がない。データベースシステムについては、格納されているデータがいかに正確で、きちんとメンテナンスが施されているかが顧客にとって最重要であるところ、会社規模・資本規模の小さな会社のシステムを導入することは将来のメンテナンスに不安を覚えるのが通常であるからである。被告システムに変更した原告ユーザーからは、変更の理由として、商品開発力の不足（バージョンアップがほとんどなく導入時から全く仕様が変わっていない等）、データメンテナンス更新ペースの遅さ（新東名高速等料金情報が遅い、観光・宿泊施設における追加、修正、削除要望には全く応えられない等）、データが不正確（道路料金・施設入場料金データの誤りが多い、倒産・廃業した観光・宿泊施設データが何年も放置されている等）、サポート体制の不十分さ（急な障害対応や操作説明を受けたくてサポートセンターに連絡しても、旅行業システムは即対応不可なので後で担当者から連絡させると回答され業務が止まってしまう等）などが挙げられており、原告システムの顧客が離反するのは、被告システムの存在が原因なのではなく、専ら原告システムの顧客満足度の低さに起因しているのである。 　一方で、被告アゼスタは、その営業担当者は全員旅行業界出身で旅行業システム販売にも１０年ないし１５年のキャリアを持っており、熱意もあって、業界の動向や顧客の要望に対する理解力に優れており、これらのフィードバックを受けてシステム開発を行うことから、正確かつ迅速なメンテナンスが施され、継続的にデータの量・質ともに向上していることに加え、被告システムは原告システムに比して機能面やサポート体制が充実しており優位性が極めて高く、先進性・利便性・サポート面等のトータルで優れたシステムとして高い支持を受けている。したがって、被告システムには、データベースの内容だけに限定されない商品価値があり、被告アゼスタの弛まぬ開発努力やサポートを含めた営業努力が販売に大きく貢献しているのである。他方で、旧原告会社では、主力の営業担当者が多数退職したため、入社間もない新人や他部署から配属された、旅行業務や旅行業務システム販売の経験の少ない従業員が営業担当とならざるを得ず、これが販売数低下を招く大きな原因の一つになったと考えられる。 　以上のとおり、被告システムが販売されなければ、原告システムが必然的に購入され、データメンテナンス契約も締結されるという因果関係は存在しない。 第４　当裁判所の判断 １　前記第２、１の前提事実並びに証拠（甲１〜８１、乙１〜４３、証人Ｂ、証人Ａ〔下記措信しない部分を除く〕、被告Ｙ５本人、被告Ｙ２本人、被告Ｙ３本人）及び弁論の全趣旨によれば、以下の事実が認められ、同認定を覆すに足りる的確な証拠はない（なお、各段落の末尾に主要な証拠を掲記した。）。 (1)　原告ＣＤＤＢを含む原告システムの開発の経緯及びその開発、営業活動等についての被告Ｙ５、Ａ、被告Ｙ２、被告Ｙ３、被告Ｙ６、被告Ｙ４の関与の状況について ア　原告システムは、現在も原告において旅行営業課の課長代理として原告システムの販売を担当するＢ（以下「Ｂ」という。）が翼システムに入社して間もない平成６年４月頃に、当時の同社代表者に対して旅行業システムの制作販売の提案をし、これを代表者が了承したことから、その開発に着手されることとなったシステムである。 　被告Ｙ５は、それに先立つ平成２年４月２２日に翼システムに入社した。被告Ｙ５は、翼システムに入社する以前、昭和６１年から他社で設計書を基にプログラムを行うプログラマーとして稼働し、翼システムにおいても電装システムの設計、検収等の業務を行ってきたことから、翼システムにおいて原告システムの制作が決まり、社員を集めて原告システムの開発プロジェクトが組織されたことを契機にそのリーダーとなった。 　Ｂが原告システムの開発の提案をするに当たって、そのきっかけとなったのは、株式会社小田急トラベル（以下「小田急トラベル」という。）からの要望にあった。同社においては、それまで、団体旅行の行程表の作成のほとんどを、従業員の手作業で行っていたところ、大型バスの使用の際の通行道路の所要時間計算や、途中のドライブインの検索等に時間を要し、手作業でこれらを行うため、一件の行程表作成に２０時間ほども要しているという実情にあった。そこで、同社では、パソコンを用いてこれらの業務を効率化したいとの要望が強かったものの、これに適するソフトウェアが当時存しなかったことから、それを可能とする団体旅行の行程表作成用のソフトウェアが作成されたならば、使用したいとの要望が示されていた。 　そこで、被告Ｙ５及びＢは、小田急トラベルに対し、原告システムの開発のため、状況調査のヒアリングを行い、さらに、平成７年（１９９５年）１月１０日に小田急トラベル社内で行われた原告システム開発プロジェクトの打合せに参加したところ、同打合せにおいて、小田急トラベルの状況調査の結果が報告された。そこでは、同社における行程表作成には上記の問題点があることのほか、同社においては、顧客と打ち合わせた結果作成された行程表の最終原稿のみを、ワープロや表計算ソフトを使用して浄書して保管し、その後に要望が似通う旅行行程表作成の必要があったとき、その要望と類似する上記最終原稿を探し出し、これを変更して使用しているが、その検索にも手間がかかる上に、旅行目的（例えば「女性のグルメ旅行」等）に応じた必要な情報の検索もできない状況にあること等が問題であることが報告された。そして、同社において、行程表作成の際に使用している資料及びその使用方法は、まず「全国道路地図」を用いて旅行行程についての大まかなコース作りをし、次に観光バスキロ程図のある「Ｒｏａｄ Ｍａｐ」（以下「ロードマップ」という。甲４７）を用い、行程に沿って時間を加算して所要時間を算出し、更に料金ガイド、ＪＴＢ宿泊情報等を用いて、必要な料金等を算出していた。同社によれば、団体旅行に使用される交通機関は、貸切バスの使用が６割、鉄道利用が２ないし３割、航空機使用が１ないし２割で、旅行人数は３０名程度での利用が最も多く、多くは１０ないし４０名程度であること、旅行行程の作成の相談に当たっては、出発地、到着地及びその時間をまず確定して、それから観光地や昼食地を選ぶことが多く、交通機関として貸切バスを使用するのであれば、９０ないし１２０分走行したところで休憩ないし昼食地を探す必要があること、一般的な出発時刻、到着時刻は、それぞれ９時頃、１６時頃であること、使用するホテル等の宿泊施設には、ホテル・旅館・民宿・ペンションの種類区分とエコノミー等の料金カテゴリーが必要であり、部屋や食事の内容、風呂の内容や大きさ、料金、宴会場の空きがあるか等が選択項目選定の際のポイントであり重要な情報となること、検索は５ないし６程度の項目とすること等が、原告システムの制作に当たって有益な情報として打合せにおいて紹介され、今後、その要望に沿ったデータベースである原告ＣＤＤＢを含む原告システム（以下、原告システムの開発という場合には、必要なデータベースである原告ＣＤＤＢの開発も含む。）の開発スケジュールが組み立てられることとなった。〔被告Ｙ５尋問調書１頁、甲６３の別紙１〕 イ　平成７年７月には、Ａが翼システムに入社し、原告システムの開発にプログラマーとして参加し、データ加工を担当することとなった。そして、原告システムのホテル・旅館のデータについては、社団法人日本観光協会、実業之日本社からデータの提供を、観光施設については社団法人日本観光協会からデータの提供を、それぞれ受けることとなった。〔乙３８、２頁、甲６３の別紙１、２〕 　同年１１月９日の時点における、当時進行中の原告システムの開発状況は、行程表のプログラムについては、道路検索について作り直しの途中であり、同月末には終了予定とされ、道路データに関して、国道のデータ入力は終了したが、有料道路は東京、神奈川、千葉、埼玉、静岡は全て終了したものの、それ以外の地域は道路名称のみの入力が終了した段階で、市町村道については未だ７００件以上の代表地点のデータが入力されていない状況であった。ホテル・旅館のデータについては、観光施設について社団法人日本観光協会から提供を受けたデータの間違いについて折衝を続けること、収容人数に関するデータも追加することなどが決められた。〔甲６３の別紙３〕 　そして、同年１２月ないし平成８年１月に、原告システム（当時の名称は「スーパーフロントマン 旅行業システム」）の販売が開始された後も、翼システムにおいては、原告システムの充実改良が引き続き行われた。そこにおいて、Ａは、原告システムの新機能の追加や改良等を担当した。その後、Ａは、翼システムにおいて、システムエンジニアとして認められて主任となり、平成９年ころからは、原告システムのシステム設計やプログラム開発を手がけ、原告システムに関するリーダーであった被告Ｙ５のもとで、サブリーダーとなった。〔乙３８、２頁〕 ウ　被告Ｙ２は、昭和６２年から旅行業者や旅行業者に業務システムを販売する会社等に勤務して、その間、旅行業者向けトータル業務のシステム販売業務に従事し、旅行業務システム仕様と構築ノウハウを修得していたが、平成８年２月に翼システムからヘッドハンティングを受けて同社に転職した。被告Ｙ２は、翼システムに入社後、原告システムの販売・サポート体制の構築に従事することとなり、平成９年１０月ころまでには主任となり、営業成績優秀者表彰を７度受けた。〔甲６３の別紙８、甲７８、６頁、乙４０、１２頁〕 エ　被告Ｙ３は、昭和６１年からは旅行業者に勤務して旅行業務の営業等を行った後、平成８年１２月に翼システムに入社し、入社後、原告システムについてシステムサポートを担当することとなり、平成１０年１月ころからは同社営業課でシステム営業を担当することとなった。〔甲７８、６頁、乙４１、５頁〕 オ　平成９年１月６日に被告Ｙ６が、平成９年１２月２４日に被告Ｙ４が、翼システムに入社した。〔甲７８、６頁〕 カ　被告Ｙ５らが参加した平成９年２月１５日の原告システムの開発に関する打合せにおいて、原告システムの改良について話し合われ、例えば、道路データは詳細地点を増やすなど、今後も地道に精度を上げていく努力をする旨が決定され、データ管理のコントロールについて、サポート担当の被告Ｙ６が当たることとなった。 　同年３月１９日時点での原告システムに関する人的体制として、データコンテンツの作成について、派遣の者６名が当たっていたが、同年４月以降、これを道路データに３人、時刻表メンテナンスに２人、観光施設データに６人、ホテルデータに１人の合計１２人に増員することとされた。また、データ開発システムに関しても、同年４月以降、設計にシステムエンジニア１人、プログラムに関しプログラマー１人を当てることとされた。その他、同年３月時点で、原告システムの基本パッケージに関する業務に当てられるシステムエンジニアとして、被告Ｙ５、Ａのほかに翼システムの社員１名、外注の者１名、プログラマーとして翼システムの社員２名、外注の者１名が当てられている状況であったが、これを引き続き維持することとされた。また、物的設備については、データ開発用、プログラム開発用兼テスト機、サーバー機として各１台の合計３００万円、クライアント機として、各８台の合計６４０万円の設備投資（ソフトウェアを含む）を行うことが決定された。〔甲６３の別紙５、甲７８〕 　被告Ｙ６は、平成９年５月１３日にＡらとの間で行われた原告システムの開発業務に関するインタビューにおいて、入金一覧表の帳票イメージについての回答をするなどした。〔甲６３の別紙４、６〕 　また、被告Ｙ３は、平成１０年１月１４日に、原告システムについての包括料金特約についての提案をするなどした。〔甲６３の別紙１１〕 キ　平成１０年８月２９日、Ｂのほか、被告Ｙ５、Ａ、被告Ｙ２、被告Ｙ６が参加して原告システムについての営業会議が行われ、原告システムについての不具合点やこれについての改善案の提案がされた。同会議において、原告システムの顧客管理機能の充実を図る必要があるとされ、例として、「法人客の場合は、創立記念旅行に行くことが多いので『創立記念日』での検索等を出来るように検討する」ことなどが今後の検討項目とされた。また、鉄道や航空料金に関しても、乗継ぎ料金の計算、普通運賃の計算が正確にできるように運行キロ数で計算処理すること、ローカル線の駅データも入力していくこととされた。〔甲６３の別紙１４〕 　さらに、今後の検討事項の一つとして、作成した行程表を地図と連動させることで、地図上に行程の経路の表示を可能とすること、祭りやさくらんぼ狩り、カニ食べ放題など、観光施設の検索条件が設定できるよう検討していくこと、宿泊施設の検索には、露天風呂やサウナが重要なキーであり、これらがある旅館を検索することができるようにすることなど、今後も宿泊施設のデータベースの改善を検討していくこととされた。また、旅行代理店は、兼業でバス会社等を営業していることも多く、バス運行管理システムについての要望があった旨も紹介された。〔甲６３の別紙１４〕 ク　平成１１年１０月１６日、被告Ｙ５、Ａ、被告Ｙ２、被告Ｙ６らが参加して原告システムの商品会議が行われ、今後のバージョンアップに向けてユーザーアンケートを行うこと、観光、ホテルの検索結果からＵＲＬに移行できるようにインターネット機能を強化すること、検索パレットは「駅・空港・フェリー」・「市区町村」・「道路地点」のみとすること、利用施設一覧表に休館日を表示した休館日チェックリストを追加すること等の機能強化の方針が打ち出された。〔甲６３の別紙１９、２０〕 ケ　平成１２年２月１２日、被告Ｙ５、Ａ、被告Ｙ２、被告Ｙ３、被告Ｙ６らが参加して原告システムの商品会議が行われ、原告システムの当時の次期商品としてVer5 の提案がされ、そこでは、原告システムをプロアトラスの地図を利用した旅行業システムとする方針で開発することとし、行程表の検索結果のルートを地図で表示し、地図から温泉地・施設が検索できるようにするため、その技術サンプルを被告Ｙ５が作成することとされた。〔甲６３の別紙２２〕 コ　平成１２年６月、被告Ｙ５が文具・事務機システムのリーダーに転出すると、Ａが原告システムの開発、改良に関する責任者となり、旅行代理店のヒアリング、要件定義、システム設計、データベース設計、開発等を行った。〔乙３８、２頁〕 　被告Ｙ３は、同年８月７日付けで、原告システムの地図機能について、検索フローチャート、表示画面の遷移や地図表示画面との対応関係等についての提案を行い、同月２１日付けでも、原告システムの地図機能について、検索フローチャート、表示画面の遷移や地図表示画面との対応関係等について、より詳細な提案を行っている。〔甲７５の別紙３〜５〕 サ　平成１２年１０月２８日、Ｂのほか、被告Ｙ２、被告Ｙ３、被告Ｙ４、Ａが参加して原告システムについての営業会議が行われ、原告システムのVer5の全機能についての仕様が決定されて紹介され、販売方法についても協議された。同会議におけるVer5についての紹介では、例えば、検索業務においては、サブメニューが「道路検索」、「時刻表検索」、「ホテル・旅館検索」、「観光施設検索」から、「道路」については「時間・経路・料金」、「時刻表」については「ＪＲ・ＡＩＲ・フェリー」、「施設」については「宿泊」、「観光」、「地図」等のサブメニューが設けられることなどの、Ver4からの改善点が全て紹介されている。加えて、同会議では、当時のユーザーに対するVer5の販売方法について、増設・バージョンアップ時は、リプレースを考慮して販売することとされ、�@リース残１ないし２年のユーザーについてはリプレース商談を、�A契約後１年未満のユーザーは、営業時の内容によりバージョンアップなどの商談を、�B契約１年以上経過のユーザーは、契約時のバージョンで商談をすることとされ、各営業担当者は、担当する顧客のリース終了年月、売買契約書の使用権終了年月を調査し、Ｂに報告することとされた。〔甲７１の別紙６〕 シ　平成１２年１１月ころから、地図検索機能、インターネット接続機能が追加された「スーパーフロントマン 旅行業システムVer5」が販売された。〔甲６３、３頁〕 ス　平成１２年１１月２０日、Ｂのほか、被告Ｙ３、被告Ｙ６、被告Ｙ５、Ａが参加して原告システムについての商品会議が行われ、原告システムの今後のバージョンアップに向けて、当時の原告システムのユーザーに対し、ユーザーアンケートを実施し、その結果を反映させることとして、被告Ｙ６がそのアンケートを作成することとされた。〔甲７１の別紙２６〕 セ　平成１３年６月１８日、Ｂのほか、被告Ｙ６、被告Ｙ５、Ａが参加して原告システムについての商品会議が行われ（なお、被告Ｙ３は参加していなかったが資料が配付された。）、原告システムにおいては、観光施設データについて、１施設に４個までの料金しか保存できず、そのうち一番上に登録した料金しか連動できないこと、無料なのか料金設定がないのかが判断できないことが問題とされ、今後の課題とされるとともに、同一施設で複数のレコードが登録されている場合があることも報告された。そして、同一施設は一つのレコードにまとめ、料金を無制限に登録できるようにすること、連動できる料金を選択できるようにすること、無料の場合は「無料」、料金設定なしは「−」を表示するよう、原告システムを改良することとされた。〔甲６３の別紙３４〕 (2)　構築された原告ＣＤＤＢの内容 　以上のとおりの原告システムの開発当時における聞き取り調査や、販売開始後のユーザーの意見聴取の結果等も踏まえて、旧原告会社は、原告システムに用いられる原告ＣＤＤＢを、平成１７年（２００５年）９月までに、以下のとおり構築した。なお、原告ＣＤＤＢは、２００５年９月版以降、２００６年１１月版までは、テーブル、フィールド及びリレーションに変更はないが、レコード数に若干の違いがある。〔甲３５、１頁〕 ア　道路情報の選択について 　前記(1)のとおり、原告システムを構築するに当たって実情調査を行った旅行会社である小田急トラベルにおいては、行程の所要時間算出のためロードマップを参照していることが判明していたところ、このロードマップは、貸切観光バスが通行するのに適した道路を選択して道路地点を設定し、隣接道路地点間のキロ数と時間を示した資料である。ロードマップにおいては、有料道路及び国道については名称ないし番号が示されるとともに、主な交差点ないし地名については、その地名とともに黒丸で示され、その黒丸と黒丸との間に、交差点ないし地名間の距離（キロ数）及び所要時間（分）が示されている。〔甲４７〕 　しかし、原告ＣＤＤＢの作成に当たっては、まず貸切バスとして通常使用される大型観光バスによる移動に適切な道路の選択を行うこととした。この観点から、国道、高速道路、有料道路、首都高速などの都市高速道路については全ての道路を選択しているものの、都道府県道については約１０％、市区町村道だけでも約３０６万以上に上る一般道路については、そのうちの約０．００４％程度に相当する１４３の一般道路を大型観光バスによる移動に適切な道路として選択し、これを「１０道路テーブル」に格納した。その際、道路番号を付すこととして「道路番号」のフィールドを設けるほか、「道路名」、「道路名読み」、「区分」の各フィールドを設けた。〔甲３、甲３０、１２〜１３頁〕 　これを具体的にみると、例えば、県道及び道道の選択において、ロードマップにおいては、福島県については全県道５１６件のうちから１２県道、北海道については全道道１１２８件（なお、平成１８年（２００６年）１１月当時は９１３道路。甲３１の１、２頁）のうちから６４道道を選択しているところ、原告ＣＤＤＢにおいては、これよりも多い、福島県において４７県道、北海道においては８０道道を選択しており、ロードマップと原告ＣＤＤＢとで共通する県道、道道も、福島県について９道路、北海道についても３３道路にすぎない。 　次に、これら道路上にとる道路地点の情報についてみると、例えば、北海道の国道２３０号線における例をとると、ロードマップにおいては、選択している道路地点は１４地点であるところ、原告ＣＤＤＢはこれよりも多い２５地点を選択し、このうち共通する道路地点は、５道路地点である。また、九州の国道３号線における福岡県内の道路地点をみると、ロードマップにおいては２７地点であるところ、原告ＣＤＤＢにおいては、これよりも多い４８地点であり、共通する道路地点は３地点にすぎない。〔甲４７、４８〕 　さらに、原告ＣＤＤＢでは、大型観光バスが移動する経路、経由地、目的地と一応の所要時間、到着時間が示せればよいとの考え方をとり、そのため必要な道路地点情報に絞って選択して格納することとした。これは、実際の自動車の走行を前提として全ての交差点や目的地の道路地点の情報を必要とするカーナビゲーションシステムに比して情報量を少なく済ませることができるものであり、格納すべき情報量は格段に少なくなる。〔甲４３、２頁〕 イ　道路地点情報の選択（緯度経度情報）について (ア)　次に、原告ＣＤＤＢにおいては、上記道路地点として選択した地点における情報を緯度及び経度のデータとして格納することとしたが、実際の作成については、まず、上記のとおりの大型観光バスが通過するのに適切と考えられる道路のうちの、行程表を作成する上で必要と考えられる適切な地点である、交差点、インターチェンジ、サービスエリア、パーキングエリア、観光施設、宿泊施設、駅、役所等の代表道路地点とするのに適切な地点につき、インターチェンジや観光施設等から最も近い交差点や、ユーザーの要望を充たすのに最も適切な地点を中心に、上記選択された道路上から選び出す作業を行った。 　そして、道路上でどの場所を選ぶかが決まると、その具体的な地点についての緯度経度は、実際にその選択作業を行うこととなる原告ＣＤＤＢの作成者自身において、具体的な地点をパソコンのマウスを地図上でクリックする方法で選択し、そこに示される緯度及び経度を、実際に入力する方法をとった。その情報は、「０９地点名テーブル」に格納されている。「０９地点名テーブル」には、「地点番号」、「地点名称」、「地点名称カナ」、「地点区分」、「都道府県コード」、「市区町村番号」、「地点経度」、「地点緯度」の各フィールドが設けられている。〔甲３、甲２８、４〜６頁、甲３０、１４頁〕 　上記道路地点の選択は、平成１８年（２００６年）２月版の時点で１万２７８１件、同年１１月版の原告ＣＤＤＢにおいて、１万２８２２件である。〔甲３２、１頁〕 (イ)　そして、施設と関係する代表道路地点の選択においては、施設が接する道路地点ではなく、当該施設の近辺の道路地点を当該施設の代表道路地点として適宜設定し、その代表道路地点への経路検索をもって、当該施設への経路検索としている。その例として、横浜市中区のホテルニューグランドには、当該ホテルが接する道路ではなく、横浜市中区山下橋が設定され、これとは異なる施設のマリンタワーについても、同じ道路地点が設定され、横浜市中区内では、８か所の代表道路地点を設定しているにすぎない。また、地方では、施設が１０キロメートル以上離れているものについて同一の代表道路地点を、７０以上の施設について、一つの代表道路地点を設定している例もある。このように、施設が道路に接しているところをもって目的地とせず、当該施設の近辺の道路地点を当該施設の代表道路地点として適宜設定して経路検索を行うこととしたのは、施設の数だけ道路地点の情報を持つことは、道路地点の数を膨大にし、経路検索の効率も悪くなるため、あえてこのような構成をとったものである。〔甲４３〕 (ウ)　なお、翼システムは、平成８年１月ころに原告システムの販売を開始したが、当初の原告システムには、地図検索機能がなかったため、これら緯度経度情報は、一つのテーブルで保有するのではなく、「０１市区町村テーブル」、「０９地点名テーブル」、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「３２駅テーブル」のそれぞれのテーブルで重複して保有していた。 　その後、前記(1)で認定したとおり、被告Ｙ２、被告Ｙ３、被告Ｙ４、被告Ｙ５、被告Ｙ６及びＡがその開発ないし営業に関与して、開発・販売された原告システムのVer5 において、地図検索が効率的に行えるよう、「０５緯度経度テーブル」を設けることとし、さらにインターネット接続のため「０６ＵＲＬアドレステーブル」、「０７ＵＲＬ種別テーブル」、「０８ＵＲＬ分類テーブル」を設けることとした。しかし、その際、既に原告システムを導入しているが、地図検索機能を必要とせず、新たな原告システムへの移行をしない顧客においても、問題なく使用し続けることができるよう、「０１市区町村テーブル」、「０９地点名テーブル」、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「３２駅テーブル」で重複し保有している緯度経度情報を、上記「０５緯度経度テーブル」でも重複保有することとした。地図検索機能を使用すると、地図上で一定の範囲を指定し、「０５緯度経度テーブル」により、その範囲内にある緯度経度の観光施設、宿泊施設、駅、市区町村等を検索して地図上に表示することができる。 　「０５緯度経度テーブル」には、緯度経度情報毎に、市区町村、ホテル・旅館、観光施設、地点、駅の各テーブルについての「種別番号」と各テーブルのプライマリー・キーとなる「種別毎番号」の情報を収録するとともに、関連する「０１市区町村テーブル」、「０９地点名テーブル」、「２１観光施設テーブル」、「２０ホテル・旅館テーブル」、「３２駅テーブル」とリレーションを取っている。 ウ　道路の接続情報の選択について (ア)　原告ＣＤＤＢでは、選択された道路と道路との接続地点には、隣接する道路地点間の各道路について、「１１接続テーブル」において、各接続番号で特定される細切れの道路を接続していくことで、出来るだけ所要時間の短い経路を検索することとした。「１１接続テーブル」には、道路地点間の接続情報として、各細切れの道路の「始点番号」、「終点番号」、通行する道路の「道路番号」、移動に要する「所要時間」、２地点間の「距離」、上り下りの車線情報である「上下区分」、「禁止フラグ」、「接続番号」などの情報を、九つのフィールドに格納した。具体的な距離と時間の算定は、別紙１の「１１接続テーブル」の「原告ＣＤＤＢの各テーブルの概要」欄記載の例のとおりである。〔甲３、甲２３、１１頁〕 　このうち、上記「接続番号」とは、一つの道路を細分化し、その道路の１単位毎に付与される番号であり、２地点間の情報を識別するものである。この接続番号は、原告システムの作成時に、ある道路の１単位を登録するたびにその都度原告が付与したものである。例えば、伊勢自動車道のうち、関ＪＣＴから芸濃ＩＣまでの区間を接続番号１と、その逆を接続番号２として上下区分により区別し、同じく伊勢自動車道のうち芸濃ＩＣから安濃ＳＡまでの区間を接続番号３とする、等のものである。〔甲２８の７頁及び別紙８〕 (イ)　そして、その経路中には、道路条件により、進入禁止、右折禁止、左折禁止などの規制のある場合がある。そこで、原告ＣＤＤＢにおいては、そのような経路が選択されないようにしておくため、「１２禁止乗換テーブル」を設け、そこに選択不可とすべき道路の接続経路、すなわち、ある接続番号からある接続番号への乗換について、禁止されるパターンの情報を格納して、これを経路検索の場合に除外するようにした。「１２禁止乗換テーブル」には、「乗換元接続番号」、「乗換先接続番号」のそれぞれの情報項目を設けて、各フィールドとした。〔甲３、甲３０、１１頁〕 　原告ＣＤＤＢの「１２禁止乗換テーブル」には、上記のとおり、一方通行などの理由により、経路として接続できない道路の情報を格納しているところ、具体的には、上記「１１接続テーブル」で持つ「接続番号」について、ある接続番号（始点番号、終点番号、道路番号などの情報）の経路から、ある接続番号の経路に乗り換えようとした場合に禁止される接続番号の組み合わせを、この「１２禁止乗換テーブル」に情報として格納するものである。「１２禁止乗換テーブル」の上記「乗換元接続番号」と「乗換先接続番号」のフィールドには、乗換元と乗換先の接続番号で禁止される乗換のパターンを特定して格納している。 　これによると、「１１接続テーブル」から各接続番号の始点、終点、道路番号がわかり、乗換を行う場合、乗換元の終点は乗換先の始点となる関係にあるので、接続された場合のルートは 　乗換元の始点→（乗換元の終点＝乗換先の始点）→乗換先の終点という関係になる。〔甲２３、１１〜１２頁〕 　この「１２禁止乗換テーブル」には、「乗換元接続番号」を「１６」、「乗換先接続番号」を「１６６０６」などとして、数値がそれぞれ格納されている。〔甲２８の別紙９〕 エ　移動手段に関する情報の選択について 　また、移動手段の種別については、それまでの一般的な分類に従えば、鉄道、バスを含む自動車、飛行機、船等となるところ、原告ＣＤＤＢにおいては、これを「ＪＲ」、「私鉄」、「空路」、「徒歩」とするほか、船については、想定する旅行会社が扱う旅行で利用頻度の高い「フェリー」として、必要な情報を「４３交通機関種別テーブル」に格納した。その際、移動手段を提供する会社についての情報を「４２会社テーブル」として格納することとし、交通会社を検索条件として、路線検索を行うことを可能とした。 　この点につき、インターネット上での経路検索を可能とするウェブサイトにおいて交通会社を経路検索に用いるものは存せず、他の路線検索システムには見られない原告ＣＤＤＢの特徴となっている。〔甲３０、６、１８頁、甲５０〕 オ　観光施設情報の選択について 　観光施設については、まず観光施設に関する様々な情報項目の中から、施設の名称、住所、緯度経度による位置情報、営業日や時間・駐車場の有無等の施設概要、利用料金等の４３項目に分類することとし、フィールドとすることとした。また、これらの情報を格納する「２１観光施設テーブル」とは別に、これを補う目的で、料金種別の増加に対応した施設利用料に関する情報項目や施設に関するコメントなどの情報項目を４４に分類してフィールドとし、これを「２２観光施設備考テーブル」に格納した。 　また、観光施設の中から、旅行業者が取り扱うと考えられた観光施設を選択し、これを「２１観光施設テーブル」、「２２観光施設備考テーブル」に格納した。〔甲３０、８頁〕 　原告ＣＤＤＢの「２１観光施設テーブル」に収録されたレコード数は、別紙４のとおり、７万２０９３件である。 カ　宿泊施設情報の選択について 　宿泊施設に関しては、宿泊施設に関する情報の中から、宿泊施設の名称、住所、緯度経度の位置情報、室数や収容人数・宴会場の有無・プールの有無等の施設情報などの４３項目を選択して、これをフィールドとし、「２０ホテル・旅館テーブル」に格納した。 　また、宿泊施設の中から、旅行業者が取り扱うと考えられた宿泊施設を選択し、これを「２０ホテル・旅館テーブル」に格納した。〔甲３０、８〜９頁〕 　原告ＣＤＤＢの「２０ホテル・旅館テーブル」に収録されたレコード数は、別紙４のとおり、１万６２２９件である。 キ　小括（原告ＣＤＤＢの概要の整理） 　上記のとおり、分類して収集すべき情報項目の選択、及び情報自体の選択・収集を踏まえて、翼システムにおいて構築された原告ＣＤＤＢの内容を整理すると、概ね、以下のとおりとなる。 (ア)　原告ＣＤＤＢの概要としては、旅行業者がパソコンにインストールされた原告システムを使って行程表作成の業務を行うにあたって必要となる、観光施設データ、宿泊施設データ、全国各地の主要道路の道路地点や、隣接する道路地点間の大型観光バスの移動時間・距離、有料道路・高速道路の料金データ、鉄道・飛行機・フェリーに関する路線、駅、時刻表等の情報を収集し、蓄積したものである。原告ＣＤＤＢでは、別紙２のとおり合計４２個のマスターテーブル内に、別紙２、３のとおり合計４０５個のフィールド項目を配し、各テーブル間を別紙３のとおり設定されたプライマリー・キーにより、別紙５（別紙６、７も同じ）のとおりのリレーションをとって関連付けることで、修学旅行や会社の慰安旅行などの旅行目的や、所要時間、立寄り施設等の要望に合わせた行程表を作成するため、観光施設、宿泊施設、交通手段、経路、出発時間や到着時間、施設等への滞在時間などの具体的なスケジュールをどうすべきかといった事項を、各情報を検索した結果を選択することにより決定し、行程表を作成していくことを可能とした情報の分類体系ということができる。 　そして、このような情報の分類を有機的に繋げ合わせて、具体的な行程表を作成するためには、顧客の出発地、帰着地、観光施設などの途中の立寄り地、宿泊施設、交通手段、経路を選択するとともに、出発時刻、到着時刻、滞在時間なども確定する必要があるところ、行程表作成及び検索システムのデータベースでは、これらの情報が、顧客等の具体的要求に基づき、求められたときに対応できるように、テーブル、フィールド及びリレーションを設計した上で、予め情報を選択して格納しておくことが必要となる。 　このように、原告ＣＤＤＢは、上記アないしカの方針で実際に集められた膨大な数のレコードを（各テーブルのレコード数については、別紙４のとおり）、別紙２、３のとおりのテーブル、フィールドに格納し、別紙５（同６、７も同様）のとおりのリレーションをとることにより、効率的に検索・行程表作成業務を行えるようにデータベースとして設計したものである。 (イ)　そこで、原告ＣＤＤＢにおける具体的な検索過程と、テーブル、フィールド等の関係等について検討する。 　まず、経路検索に関するテーブル及びフィールドの設定、体系的構成、リレーションの設定について、出発地、帰着地、観光施設などの途中立寄り地、宿泊施設、駅、空港、フェリー発着所などに関し、これと関連するテーブルである「０１市区町村テーブル」、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「３２駅テーブル」に「代表道路地区コード」や「代表道路地点番号」のフィールドを持つこととしている。そして、道路利用の経路検索の対象として市区町村、観光施設、宿泊施設、駅がある場合には、それぞれの施設自体の緯度経度ではなく、これと関連した道路地点の緯度経度情報のデータを使って、その道路地点までの経路を検索することとなる。各施設等にかかるテーブルの「代表道路地区コード」や「代表道路地点番号」は、「０９地点名テーブル」の「地点番号」とリレーションがとられていることにより、各施設までの経路を検索するときには、この「代表道路地区コード」や「代表道路地点番号」所定の道路地点までの経路を検索することになる。 　また、施設を含めた経路検索を行う場合、施設関連の各テーブルに、「代表道路地区コード」や「代表道路地点番号」という道路地点のフィールドを持たせ、これと「０９地点名テーブル」の「地点番号」との間でリレーションを取り、道路地点としての検索を行うという構成を採用している。 　具体的には、別紙３記載のとおり、原告ＣＤＤＢでは、「０９地点名テーブル」の「地点番号」フィールドをプライマリー・キーに設定し、これと、別紙５で、青丸と青丸を結ぶ太線のうち黒太線で記載されたリレーションのとおり、「０１市区町村テーブル」の「代表道路地区コード」フィールド、「２０ホテル・旅館テーブル」の「代表道路地区コード」フィールド、「２１観光施設テーブル」の「代表道路地点番号」フィールド、「３２駅テーブル」の「代表道路地点番号」フィールドとにリレーションを持たせている。 　また、禁止乗換に関するテーブル及びフィールドの設定、体系的構成、リレーションについては、道路利用の経路検索では「０９地点名テーブル」及び「１１接続テーブル」のデータを使って、所要時間の短い経路を検索して提示するものの、「１２禁止乗換テーブル」を設けて、一定の接続経路を除外するように構成している。 　上記の「０９地点名テーブル」には、別紙３記載の各フィールドに、道路地点の情報（地点番号、地点名称、都道府県コード、市区町村番号、地点区分、緯度、経度など）を格納している。道路地点の情報は、経路検索をする場合の基本となる位置情報となる。「０９地点名テーブル」の「地点番号」フィールドについては、上記のとおり「０１市区町村テーブル」、「２１観光施設テーブル」、「２０ホテル・旅館テーブル」、「３２駅テーブル」の「代表道路地区コード」や「代表道路地点番号」とリレーションを取り、また「１１接続テーブル」、「１２禁止乗換テーブル」ともリレーションを取って、旅行行程における具体的な経路検索、所要時間、距離、有料道路通行時の料金情報等の検索をするための基本的な情報となっている。 (ウ)　原告ＣＤＤＢでは、鉄道、飛行機、フェリー等の経路検索を行う場合には、まず、ある地区や都道府県において交通機関を運営している会社等を特定し、そののちに路線等を特定する方法をとっている。 　具体的には、まず交通機関を運営している会社等を特定するために乗車する地区、都道府県を絞り込み（「０２地区・県名テーブル」による）、次に当該区域の交通機関の会社を選択する（「４２会社テーブル」、「４４地方別会社索引テーブル」、「４５検索地方範囲定義テーブル」、「４６地方別路線索引テーブル」による）。すると、当該交通会社が運行している路線一覧が表示され、利用する路線を選択すると路線の駅等が一覧表で示される（「３４路線テーブル」、「４２会社テーブル」、「４６地方別路線索引テーブル」による。）。そこで、出発時刻、乗車駅と降車駅等を選択して検索すると、利用可能な便（「３２駅テーブル」、「３４路線テーブル」、「３６路線検索テーブル」、「３９便テーブル」、「４０運行日定義テーブル」、「４７駅通過路線索引テーブル」による。）が表示されるので、利用する便を確定することになる。 ク　原告ＣＤＤＢの各テーブルの相互関係 　原告ＣＤＤＢは、上記のとおり、４２個のマスターテーブル、４０５個のフィールド項目からなり、原告ＣＤＤＢの各テーブルの意義については、別紙１記載のとおりであるところ、原告ＣＤＤＢの各テーブル相互の関係については、以下のとおり分類される。 　「０１市区町村テーブル」、「３２駅テーブル」、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「０９地点名テーブル」、「１１接続テーブル」、「１０道路テーブル」により、出発地点、経由地、目的地に面した道路に関するデータの検索が可能になる。 　次に「０９地点名テーブル」、「１０道路テーブル」、「１１接続テーブル」、「１２禁止乗換テーブル」、「１４区間料金テーブル」、「１５首都高速料金テーブル」により、道路を利用した移動に関する経路探索・料金の算出に必要なデータの検索を可能にしている。 　そして、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「２２観光施設備考テーブル」、「０５緯度経度テーブル」、「０６ＵＲＬアドレステーブル」、「０７ＵＲＬ種別テーブル」、「０８ＵＲＬ分類テーブル」により、ホテル・旅館、観光施設に関する情報を検索することを可能にしている。 　「０１市区町村テーブル」、「０２地区・県名テーブル」は、道路と地図を関連付ける情報であって、地図から検索をするときに用いられている。 　「３２駅テーブル」、「３３路線構成テーブル」、「３４路線テーブル」、「３６路線検索テーブル」、「３９便テーブル」、「４０運行日定義テーブル「４２会社テーブル」、「４３交通機関種別テーブル」により、公共交通機関を利用した経路探索に必要なデータの検索を可能にしている。 ケ　原告ＣＤＤＢにおける検索、行程作成の実際 　以上を踏まえて、具体的な検索、行程作成の実際について検討する。 　まず、出発地を「０１市区町村テーブル」を使って市区町村内の道路地点から選択する。その際、選択された市区町村内の道路地点として、「０９地点名テーブル」の道路地点のうち、当該市区町村内にある道路地点を見ることができる。そして、市区町村の絞り込みは「０２地区・県名テーブル」、方面については「０３方面テーブル」、「０４方面設定テーブル」、都道府県については、「０２地区・県名テーブル」から絞りこむことができる。 　また、「０１市区町村テーブル」、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「３２駅テーブル」には施設等の近辺の道路地点の情報が代表道路地区コードや代表道路地点番号として格納されており、当該市区町村内にあるこれらの施設や駅などを選ぶことを通じて、出発点としての「０９地点名テーブル」の道路地点を選ぶことができる。 　次に、観光施設を「２１観光施設テーブル」から選択する。観光施設の絞り込みは、上記と同じく、「０２地区・県名テーブル」、「０３方面テーブル」、「０４方面設定テーブル」、「０１市区町村テーブル」から行うことができる。観光種別は「２３観光施設種別テーブル」（ただし、前記のとおり、ＣＤで提供されるものではないことから、原告ＣＤＤＢ自体には含まれていない。）に、名称は「２１観光施設テーブル」に、検索結果の観光施設について、当該観光施設に関する様々な情報は、「２２観光施設備考テーブル」に格納されており、観光施設に関するホームページの情報も「０６ＵＲＬアドレステーブル」、「０７ＵＲＬ種別テーブル」から参照可能であり、最終的に行程に入れるかどうかを判断することができる。 　宿泊施設については、「２０ホテル・旅館テーブル」から選択し、地区は「０２地区・県名テーブル」、方面は「０３方面テーブル」、「０４方面設定テーブル」、都道府県は「０２地区・県名テーブル」、市区町村は「０１市区町村テーブル」、地図上の範囲設定は別途の地図ソフトであるプロアトラスと「０５緯度経度テーブル」、「２０ホテル・旅館テーブル」、宿泊種別は「２０ホテル・旅館テーブル」、名称は「２０ホテル・旅館テーブル」、検索結果の宿泊施設については当該宿泊施設に関する様々な情報、すなわち和室、洋室の客室数、収容人員、料金、付帯施設、駐車場などが「２０ホテル・旅館テーブル」に格納されていて、当該宿泊施設に関するホームページの情報も「０６ＵＲＬアドレステーブル」、「０７ＵＲＬ種別テーブル」が対応し、これらを参照してシステムのユーザーである旅行会社ないしその顧客の判断で決定することができる。 コ　原告ＣＤＤＢのルート検索における交通機関別での必要なテーブル 　原告ＣＤＤＢにおいては、複数の道路地点を用いてルートを検索するところ、このときの利用交通機関別の必要なテーブルについては、以下のとおり整理することができる。 (ア)　道路利用（大型バス） 　「０９地点名テーブル」、「１１接続テーブル」、「１２禁止乗換テーブル」 　原告ＣＤＤＢでは、各市区町村、各観光施設、各宿泊施設、各駅の近辺にある道路地点の地点番号を「代表道路地区コード」や「代表道路地点番号」として、各テーブルのフィールドとして持たせ、道路利用の経路検索の対象として市区町村、観光施設、宿泊施設、駅がある場合には、各テーブルの「代表道路地区コード」や「代表道路地点番号」のフィールドに格納されている道路地点までの経路を検索するようにしている。 (イ)　鉄道利用 　「０２地区・県名テーブル」、「３２駅テーブル」、「３３路線構成テーブル」、「３４路線テーブル」、「３６路線検索テーブル」、「３９便テーブル」、「４０運行日定義テーブル」、「４２会社テーブル」、「４４地方別会社索引テーブル」、「４６地方別路線索引テーブル」、「４７駅通過路線索引テーブル」 (ウ)　飛行機利用 　「０２地区・県名テーブル」、「３２駅テーブル」、「３３路線構成テーブル」、「３４路線テーブル」、「３６路線検索テーブル」、「３９便テーブル」、「４０運行日定義テーブル」、「４２会社テーブル」、「４４地方別会社索引テーブル」、「４６地方別路線索引テーブル」、「４７駅通過路線索引テーブル」 (エ)　フェリー利用 　「０２地区・県名テーブル」、「３２駅テーブル」、「３３路線構成テーブル」、「３４路線テーブル」、「３６路線検索テーブル」、「３９便テーブル」、「４０運行日定義テーブル」、「４２会社テーブル」、「４４地方別会社索引テーブル」、「４６地方別路線索引テーブル」、「４７駅通過路線索引テーブル」 (3)　翼システムないし旧原告会社の状況及びそこにおける被告Ｙ１を除く個人被告らの活動等 ア　翼システムにおいては、平成１１年１月に、当時の翼システム会長が脱税容疑で逮捕され、平成１３年３月に実刑判決を受けるに至った。〔甲７９〕これらを受け、平成１５年１０月ころからは、翼システムにおいても人員削減等の話が出て、経営の存続が危ぶまれる声も聞かれるようになった。 イ　平成１７年当時の翼システムにおける、被告Ｙ２、被告Ｙ３、被告Ｙ４、被告Ｙ６の担当営業地域は以下のとおりである。 　被告Ｙ２の担当は、概ね、北海道、青森、岩手、宮城、秋田、山形、福島、茨城、栃木、富山、石川の１１道県である。 　同じく被告Ｙ３の担当は、概ね、千葉、三重、東京の３都県である。 　同じく被告Ｙ４の担当は、概ね、群馬、埼玉、神奈川、新潟、山梨、長野、静岡の７県である。 　同じく被告Ｙ６の担当は、広島、山口、徳島、香川、愛媛、高知、福岡、佐賀、長崎、熊本、大分、宮崎、鹿児島、沖縄の１４県である。 　これら被告Ｙ２、被告Ｙ３、被告Ｙ４、被告Ｙ６の４名の担当都県等は、合計で３５都道県となり、被告Ｙ２、被告Ｙ３、被告Ｙ４及び被告Ｙ６の４名で、翼システムの顧客の８割以上を担当していた。〔被告Ｙ２尋問調書２頁〕その他の翼システムにおける営業の担当は、Ｂが岐阜、三重、福井、滋賀、京都の５府県及び大手ユーザー、訴外Ｃが大阪、兵庫、奈良、和歌山、鳥取、島根、岡山の７府県であった。〔甲７８〕 ウ　被告Ｙ６は、原告システムのサポート担当者として、原告ＣＤＤＢを含むデータベースＣＤと、ユーザーのＰＣなどに原告システムのプログラムをインストールするため、プログラム部分やエントリーテーブル部分から成り、システム導入時にユーザー側に設置されるＰＣ内に必要なプログラムやエントリーテーブル等をインストールすることを可能とするインストールＣＤ、及び、これらがインストールされたノートパソコンを常に持ち歩いており、これらにはコピープロテクションがかかっておらず、そこに格納されているプログラム、データベース、データその他の情報にアクセスすることができた。〔甲６３、７１〕 エ　また、被告Ｙ３、被告Ｙ２、被告Ｙ４の３名、及び、営業も担当することとなった後の被告Ｙ６は、翼システムの営業担当者として、営業活動中、原告ＣＤＤＢを含むデータベースＣＤと、原告システムをインストールするためのインストールＣＤ、及び、原告システムのデモ環境がインストールされている、営業担当者が、システム導入の見込み客に対し、原告システムのデモンストレーションをする際に使用するノートパソコンを常に持ち歩いており、これらにはコピープロテクションがかかっておらず、そこに格納されているプログラム、データベース、データその他の情報にアクセスすることができた。また、被告Ｙ５は、被告Ｙ３、被告Ｙ２、被告Ｙ４らの営業担当者は原告等の管理区域内に設置されており本来はアクセスできない開発系サーバー内に格納されている、プログラムやデータベース、これらに関する設計資料等を、それぞれ電子媒体、紙媒体その他の媒体等に複製し得る環境にあった。〔甲６３、７１〕 オ　上記デモンストレーション用の原告システムのプログラム及びデータベースは、最新の販売用の製品を顧客ないし導入見込み客にデモンストレーションを行うため、常に最新のものとされており、データベースのＣＤも、最新版が発行されるたびに、営業担当者全員に配布され、データの定期的な更新をすることが可能とされていた。〔甲７１〕 (4)　個人被告らによる被告アゼスタの設立等 ア　被告Ｙ３、被告Ｙ２、被告Ｙ４、被告Ｙ５らは、平成１７年６月ころまでには、旧原告会社を退社して旅行業システムを営む新会社を設立することの相談を始めた。〔被告Ｙ２尋問調書２１頁〕 イ　一方、被告Ｙ１は、翼システム及び旧原告会社に在籍したことはなく、株式会社グッドウィルの取締役、株式会社エス・エス・アイ・トリスター、株式会社トリスターの代表取締役等、ＩＴ・ソフトウェア関係の事業の経営に携わってきた経験があり、被告Ｙ３、被告Ｙ２の高校の同級生で、知人でもあったことなどから、平成１７年１０月１８日の被告アゼスタの設立に当たり過半を出資して、設立と同時に被告アゼスタの代表者に就任した。〔証人Ａ尋問調書８頁〕 ウ　Ａは、被告アゼスタ設立に先立つ平成１６年７月に、既に翼システムを退社し、訴外株式会社ストラテジィに入社していたが、平成１７年７月頃、被告Ｙ３及び被告Ｙ５から、旅行業システムの販売をする設立準備中の被告アゼスタに加入することの勧誘を受け、同年１１月に、被告アゼスタに入社した。Ａが入社した当時の被告アゼスタには、常勤の役員、社員は、被告Ｙ１のほかは、Ａしかいなかった。〔証人Ａ尋問調書３、９頁、乙３８、１頁〕 エ　被告Ｙ３は、平成１７年９月ないし１０月ころ、翼システムの社員であり、原告システムの営業及びサポート業務に携わっていた訴外Ｄに対し、翼システムを退社して被告Ｙ３らと事業を行うことを勧誘したが、断られた。〔甲７１〕 オ　被告Ｙ５は、前記のとおり、平成１７年７月ころには、既に翼システムを退職していたＡを被告アゼスタの設立に向けて勧誘をしていたが、被告Ｙ５自身はそのまま旧原告会社に在籍を続けた。被告Ｙ５は、旧原告会社において、原告システムのプログラム、データベース、開発資料、メンテナンス資料等について自由にアクセスできる立場にいた。被告Ｙ５は、遅くとも平成１８年１月ころまでには、旧原告会社の社員でありながら、被告システムの当初版の開発にも携わり、入力の指示等を行っており、平成１８年６月に旧原告会社を退社し、被告アゼスタに入社した。〔証人Ａ尋問調書１１頁、被告Ｙ５尋問調書１４、１５、２４〜２５頁〕 　ただし、Ａ及び被告Ｙ５は、被告ＣＤＤＢの当初版の開発当時、被告システムに用いられているＳＱＬサーバーに関し、それほどのキャリアを積んではいない状態にあった。〔証人Ａ尋問調書１６頁〕 カ　被告アゼスタは、平成１８年６月、当初版の被告システムの販売を開始した。被告Ｙ２らは、旧原告会社の顧客に対し、被告アゼスタ設立の挨拶とシステム資料を一斉送付し、営業を行った。〔被告Ｙ２尋問調書８頁〕 　しかし、被告システムに関し、同月末に納入したアルピコ観光サービス株式会社から、被告システムの性能に関し、重大なクレームが寄せられるということがあった。〔証人Ａ尋問調書１９、２０頁〕 キ　被告Ｙ６は、平成１８年１０月まで旧原告会社において、原告システムの営業を担当していたが、同月、旧原告会社を退社した。〔乙４２〕 　また、被告Ｙ５は、平成２０年６月、被告アゼスタを退社した。 ク　被告Ｙ１は、平成２０年７月に、「株式会社アゼスタ 営業部 Ｙ１」の名義で、翼システムの顧客である旅行会社に向け、下記の内容の文書を送付した。なお、上記のとおり、被告Ｙ１は翼システムに在籍したことはない。〔甲５２〕 記 　「翼システム株式会社在籍中はひとかたならぬ御愛顧を賜り、厚く御礼申し上げます。さて、昨年７月に弊社旅行業務システム『旅 nes Pro』を初めてご紹介させて頂き丁度一年が経過致しましたが、この間も順調に全国の旅行会社様に弊社システムをご導入頂きまして、６月末現在のユーザー数は２２２社、その内旧翼システム『スーパーフロントマン旅行業システム』から弊社システムへのお切り替えユーザー様が１８２社となっております。・・・現行システムリース満了に伴う契約更新やシステム増設をご検討の際には、何卒、比較検討頂けます様お願い申し上げます。尚、弊社システムにお切り換え頂く場合には、現行システムからのデータ移行、現行システムのリース残債下取り（社内規定の範囲内）等のご要望もお受け賜り致しますので、ご商談の際に遠慮なくお申し付け下さい。」 ケ　被告アゼスタは、平成２０年８月１８日、別紙被告物件目録記載１１の被告ＣＤＤＢ（現行版）を含む被告システムのVer2.80 を発売した。また、被告アゼスタは、同年１１月発売の別紙被告物件目録記載１２の被告ＣＤＤＢ（現行版）を含む被告システムVer2.82 からは、施設マスタに「キーワード」のフィールドを設け、「世界遺産」、「祭り」、「観光・食事１００選」などのテーマに沿って検索することを可能にした。 コ　被告Ｙ６は、平成２０年１２月１日付け書類送付状を原告の顧客に送付したが、そこには、下記の記載がある。〔甲２５の１。アンダーライン・太字は原文どおり。なお、「※」以下は、手書き記載。〕 記 　「突然の資料送付にて大変失礼いたします。翼システム(株)営業として数回ご訪問させていただきましたＹ６と申します。その節は、長い間皆様にいろいろとお世話になり、誠にありがとうございました。新たに他社にて旅行業システム専門の会社を立ち上げさせていただきました。・・・全国にて３００店舗以上の旅行社様が当社へ切り替えをしていただきました。※現在ご利用の翼システムも残リースが１年くらいだと思います。一度ご提案させていただけたらと思います。」 サ　原告は、平成２１年５月１５日付けで本件訴訟を提起し、その訴状は、同月２７日までに被告らに対し送達された。 　被告らは、同年６月、原告に対し、ロイヤルティの支払や原告事業の買取り等を条件とする和解の申入れを行ったが、原告に拒絶された。〔当事者間に争いがない〕 シ　被告らは、平成２１年６月、別紙被告物件目録記載１６の被告ＣＤＤＢ（現行版）を含む被告システム（Ver2.94）を販売した。同システムの被告ＣＤＤＢ（現行版、Ver2.94）においては、同年４月に発売された別紙被告物件目録記載１５の被告システム（Ver2.92）の被告ＣＤＤＢに比べ、原告ＣＤＤＢにおける緯度経度情報の完全一致率（緯度及び経度を０．１秒単位で表すために原告が設定した６桁ないし７桁の数字で表される緯度経度の数値がすべて一致する率）が、約９２％から８．１％に激減した。〔甲３２、３４、３９〕 　この点につき、Ａは、原告から本件訴訟の提起を受けて、原告から指摘を受けるまで、これらが同じであることを知らなかったが、原告の指摘を受けたことから、交差点が中心になるようにマウスでクリックをして位置決めをして、数値の入れ直しをした結果であるとする。〔証人Ａ尋問調書２０頁〕 ス　平成２１年１０月、被告アゼスタは、新たに、バス運行管理システムの「バス快道」を開発し、その販売を開始し、同年１２月には、「バス快道」をバージョンアップした。〔甲２５の２〕 セ　被告Ｙ１は、平成２２年（２０１０年）１１月２９日付けで、被告アゼスタ「営業グループ Ｙ１」の名義で手書きの新製品案内状を送付したが、そこには、下記の記載がある。〔甲５３〕 記 　「拝啓 貴社益々ご清栄のこととお慶び申し上げます。私どもアゼスタは旧翼システムにて旅行業システムの開発・営業に携わっていたメンバーで２００５年１０月に独立した会社です。弊社の旅行業システム『旅ネスプロ』は販売開始から４年間で約５００社様、その内旧翼システム時代のお客様約３００社様が『旅ネスプロ』へ切換導入して頂いております。・・・尚、弊社システムへお切換え頂くことは、現在システムをご使用している途中でも可能でございます。現行システムのリース残債の下取り現行システムからのデータ移行ができます。」 　なお、このころ被告アゼスタから発売された製品は、被告ＣＤＤＢ（現行版）であり、平成２２年８月３日にVer2.99 の２０１０年８・９月版が、同年１０月４日にVer2.99 の２０１０年１０・１１月版が、同年１２月６日にVer2.99 の２０１０年１２月・２０１１年１月版が、それぞれ発売されている。〔甲３８〕 　なお、このころ、後記のとおり、被告ＣＤＤＢに存する原告ＣＤＤＢと共通する誤りがある情報について、その誤りを訂正する変更がされているものがある。 ソ　被告らは、平成２３年２月にも、原告に対し、再度の和解の申入れ及び個人被告らに対する訴えの取下げを求めたが、原告に拒絶された。〔当事者間に争いがない〕 タ　被告アゼスタは、平成２３年２月７日発行で、被告ＣＤＤＢ（現行版）のVer3.1 を発売した。〔甲３８〕 　そして、被告アゼスタは、同年４月４日に、被告ＣＤＤＢ（新版）を含む被告システム（別紙被告物件目録記載２２）の販売を開始した。 (5)　一般的なデータコピーのプロセスについて 　データベース間でデータのコピーを行うには、ＣＳＶ（Comma Separated Values）ファイルを使う方法と直接コピーする方法がある。〔甲６７、７０〕 　このうち、データベースのデータをＣＳＶファイルに出力する場合には、１個のテーブルにつき一つのＣＳＶファイルが作成され、テーブル内の１個のレコードが通常１行のデータとして出力される。その際、改行があると、次のレコードとして認識される。１レコード内のフィールドの区切りには「、（カンマ）」を挿入して出力するので、フィールド間は「、（カンマ）」で区切られ、「、（カンマ）」があると、次のデータとなる。 　そこで、ＣＳＶファイルを使用する場合は、フィールド内のデータに改行や、「、（カンマ）」等が含まれ、かつこれらがフィールドやレコードの区切りを示すものでない場合は、データの前後を「"(ダブルクォート）」で囲う処理などを行い、フィールドやレコードの区切りとして扱われないようにする処理が必要となり、単純にコピーした場合には、ＣＳＶファイルへの抽出では、「、(カンマ)」、「"(ダブルクォート）」等が含まれているデータでは不都合が生じることがある。〔甲７０、６〜８頁〕 　なお、タブ区切り（ＴＳＶ：データをタブ文字で区切って並べたファイル形式）にすれば不都合が生じない場合があり、カンマ区切り（ＣＳＶ）では、カンマ、ダブルクォート等は文字化けや項目ずれを起こすため、被告アゼスタでも、カンマ、ダブルクォート等が含まれているデータについてはタブ区切り（ＴＳＶ）を使って上記支障が生じないように対処することは可能である。 (6)　顧客（システムのユーザー）が蓄積したデータの移行について 　また、顧客（システムのユーザー）が使用しているシステムについて、別のシステムに移行する際には、顧客の元で作成・保存された既存のデータを、新システムでも使用できるようにするために、データを移行（コンバート）する必要がある。データ移行のためには、移行元のテーブルレイアウトが必要であるところ、原告システムで作成されたエントリーテーブルに保存されるユーザーデータは、原告ＣＤＤＢの各マスターテーブルの情報と紐付けられており、原告ＣＤＤＢのテーブル、フィールド、リレーション、フィールドにおける種別の設定、コードの割振りなどの内容や、テーブルレイアウトを知らないと、原告システムのユーザーデータを被告システムに移行することはできない。〔甲６１〕 　原告が顧客に提供した原告ＣＤＤＢには、テーブル名、フィールド名、コードの意味、リレーション、予備の項目（別紙３の括弧内に「予備」と記載された、フラグ、区分、日付、数値等のフィールド）に格納されているデータの内容などの情報は格納されておらず、原告ＣＤＤＢを解析しても、原告ＣＤＤＢから被告ＣＤＤＢへとユーザーデータの移行を行うために必要な、原告ＣＤＤＢについてのテーブル名、フィールド名、コードの意味、リレーションなどの情報を取得することはできない。〔甲６７〕 　なお、移行元のテーブルＩＤ、フィールドＩＤと、移行先のテーブルＩＤ、フィールドＩＤとを対応させることができれば、両者の間でのデータ移行は容易に行うことができる。〔甲７０〕 (7)　被告ＣＤＤＢに格納されたデータ等について 　被告ＣＤＤＢに格納されたデータには、上記「、(カンマ)」や「"(ダブルクォート）」が含まれていることにより、データ移行がされた場合に不都合が生じたものと認められるものはない。 　なお、被告らは、原告ＣＤＤＢをコピーし流用したことは認めるが客観的なデータに誤記修正をした上であり、しかもカンマ区切り（ＣＳＶ）ではカンマやダブルクォートが含まれていると文字化けや項目ずれを起こすため、これらが含まれている場合にはタブ区切り（ＴＳＶ）を使ってデータ入力・加工を行っているものであると主張するところ、確かに、原告ＣＤＤＢの「０９地点名テーブル」の地点番号「１２４１４」には、地点名称「北九州市（Ｒ３、県道２７０号）小倉北区上到津２」との地点が登録されており、この地点名称カナフィールドには、「ｷﾀｷｭｳｼｭｳｼｵｸ"ﾗｷﾀｸﾐﾔｺｶﾐﾄｳﾂ２」と、「ｵｸ"ﾗ」には、濁点ではなく「"(ダブルクォート）」が含まれており、被告ＣＤＤＢ（当初版・２００６年版）には、「ｷﾀｷｭｳｼｭｳｼｵｸﾗ"ｷﾀｸﾐﾔｺｶﾐﾄｳﾂ２」と原告ＣＤＤＢと同じデータがそのまま格納されている。しかし、上記「北九州市小倉北区上到津２」の正しい読み仮名は、「ｷﾀｷｭｳｼｭｳｼｺｸﾗｷﾀｸｶﾐｲﾄｳﾂﾞ２」であり、原告ＣＤＤＢの表記は正しい読み方とも大きく異なるが、被告ＣＤＤＢ（当初版・２００６年版）には、全く同じ表記でデータが格納されていることが認められる。〔甲７０〕 (8)　原告における原告システム以外の製品の販売について 　原告は、原告システムのほか、平成２１年ころからは、多拠点向けの旅行業システムとして、「トラベルート・エヌエス」（以下「ＴＲ−ＮＳ」という。）を販売している。近年における原告システムとＴＲ−ＮＳの販売割合は、ほぼ同等である。〔証人Ｂ、１２頁、弁論の全趣旨〕 ２　争点(1)（原告ＣＤＤＢの著作物性及び被告ＣＤＤＢが原告ＣＤＤＢに依拠して作成された複製物ないし翻案物といえるか）について (1)　著作権法２条１項１０号の３は、データベースにつき、「論文、数値、図形その他の情報の集合物であって、それらの情報を電子計算機を用いて検索することができるように体系的に構成したものをいう」とし、同法１２条の２第１項は、「データベースでその情報の選択又は体系的な構成によって創作性を有するものは、著作物として保護する」と規定している。 　このように、データベースとは、情報の集合物を電子計算機を用いて検索することができるように体系的に構成したものをいうところ、前記第２、１の前提事実及び前記１で認定した事実によれば、原告ＣＤＤＢは、データベースの情報の単位であるレコードを別のレコードと関連付ける処理機能を持ついわゆるリレーショナル・データベースである。リレーショナル・データベースにおいては、入力される情報はテーブルと呼ばれる表に格納され、各テーブルはフィールド項目に細分され、あるテーブルのあるフィールド項目を他のテーブルのあるフィールド項目と一致させてテーブル間を関連付けることにより、既存の複数のテーブルから抽出したいフィールド項目だけを効率的に選択することができるデータベースであるから、情報の選択又は体系的な構成によってデータベースの著作物と評価することができるための重要な要素は、情報が格納される表であるテーブルの内容（種類及び数）、各テーブルに存在するフィールド項目の内容（種類及び数）、各テーブル間の関連付けのあり方の点にあるものと解される。 　上記のような観点も踏まえ、原告ＣＤＤＢのようなリレーショナル・データベースについて情報の選択に創作性があるというためには、データベースの主題、用途やデータベースの提供対象等を考慮して決定された一定の収集方針に基づき収集された情報の中から、更に一定の選定基準に基づき情報を選定することが必要であり、また体系的構成に創作性があるというためには、収集、選定した情報を整理統合するために、情報の項目、構造、形式等を決定して様式を作成し、分類の体系を決定するなどのデータベースの体系の設定が行われることが必要であると解される。 　ただし、データベースにおける創作性は、情報の選択又は体系的構成に、何らかの形で人間の創作活動の成果が表れ、制作者の個性が表れていることをもって足りるものと解される。 (2)　次に、著作物の複製ないし翻案については、複製とは、印刷、写真、複写、録音、録画その他の方法により有形的に再製することをいうとされているところ（著作権法２条１項１５号）、著作物の複製は、既存の著作物に依拠し、これと同一のものを作成し、又は、具体的な表現に修正、増減、変更等を加えても、新たに思想又は感情を創作的に表現することなく、その表現上の本質的な特徴の同一性を維持し、これに接する者が既存の著作物の表現上の本質的な特徴を直接感得することのできるものを作成する行為をいうと解される。 　また、著作物の翻案（著作権法２７条）とは、既存の著作物に依拠し、かつ、その表現上の本質的な特徴の同一性を維持しつつ、具体的表現に修正、増減、変更等を加えて、新たに思想又は感情を創作的に表現することにより、これに接する者が既存の著作物の表現上の本質的な特徴を直接感得することのできる別の著作物を創作する行為をいう（最高裁平成１３年６月２８日第一小法廷判決・民集５５巻４号８３７頁参照）。 　そして、著作権法は、思想又は感情の創作的な表現を保護するものであるから（著作権法２条１項１号）、既存の著作物に依拠して作成又は創作された著作物が、思想、感情若しくはアイデア、事実若しくは事件など表現それ自体でない部分又は表現上の創作性がない部分において、既存の著作物と同一性を有するにすぎない場合には、複製にも翻案にも当たらないというべきである。 　データベースについては、情報の選択又は体系的な構成によって創作性を有するものは、著作物として保護されるものであるところ（著作権法１２条の２）、上記のとおり、データベースにおける創作性は、情報の選択又は体系的構成に、何らかの形で人間の創作活動の成果が表れ、制作者の個性が表れていることをもって足りるものあるが、データベースの著作物として保護されるのはあくまでも、具体的なデータベースに表現として表れた情報の選択や体系的構成であって、具体的な表現としての情報の選択や体系的構成と離れた情報の選択の方針や体系的構成の方針それ自体は保護の対象とはならないというべきである。 (3)　以上を前提に、まず被告ＣＤＤＢ（当初版・２００６年版）につき検討する。 ア　被告ＣＤＤＢ（当初版・２００６年版）と原告ＣＤＤＢとの体系的構成の共通性 (ア)　テーブルの種類及び数 ａ　一致するマスターテーブル 　原告ＣＤＤＢには４２個の、被告ＣＤＤＢ（当初版・２００６年版）には３１個のマスターテーブルがそれぞれ含まれるところ、このうち、以下の２４個のマスターテーブルについては、原告ＣＤＤＢに含まれるマスターテーブルと一致することにつき争いがない。 　一致することに争いのない２４個のマスターテーブルは、以下のとおりである（原告ＣＤＤＢのマスターテーブル。これと対応する被告ＣＤＤＢ（当初版・２００６年版）の表記は別紙２該当欄各記載のとおり）。 ・「０１市区町村テーブル」 ・「０２地区・県名テーブル」 ・「０５緯度経度テーブル」 ・「０６ＵＲＬアドレステーブル」 ・「０７ＵＲＬ種別テーブル」 ・「０８ＵＲＬ分類テーブル」 ・「０９地点名テーブル」 ・「１０道路テーブル」 ・「１１接続テーブル」 ・「１２禁止乗換テーブル」 ・「１３有料道路番号テーブル」 ・「１４区間料金テーブル」 ・「１５首都高速料金テーブル」 ・「１６道路構成地点テーブル」 ・「１７道路構成地点索引テーブル」 ・「１８市区町村通過道路索引テーブル」 ・「１９県範囲定義テーブル」 ・「２８協定施設テーブル」 ・「２９券種テーブル」 ・「３０協定旅館テーブル」 ・「３１連結協定テーブル」 ・「３２駅テーブル」 ・「４２会社テーブル」 ・「４４地方別会社索引テーブル」 　そして、原告は、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」及び「２２観光施設備考テーブル」についても、これら三つのテーブルに対応する、被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」、「２９旅館マスタ基本」、「２３観光マスタ基本」、「２６観光料金マスタ」及び「２５観光料金種別マスタ」は、一致するマスターテーブルである旨主張する。 　このうち、被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」、「２９旅館マスタ基本」、「２３観光マスタ基本」と原告ＣＤＤＢの「２０ホテル・旅館テーブル」、「２１観光施設テーブル」とは、別紙３記載のとおり、フィールドのテーブルへのまとめ方は異なるものの、被告ＣＤＤＢ（当初版・２００６年版）の下記テーブルについての合計１９個のフィールドを除いては、いずれも原告ＣＤＤＢのフィールドと共通し、被告ＣＤＤＢ（当初版・２００６年版）に固有のフィールドといえるものは存在しない。 ・「２９旅館マスタ基本」テーブルにつき、以下のフィールド（フィールド名の右の記載はフィールドＩＤ） 　シングル数（客室数＿シングル）、ＨＬＲＭＳＧＬ 　ツイン数（客室数＿ツイン）、ＨＬＲＭＴＷＮ 　その他数（客室数＿その他）、ＨＬＲＭＥＴＣ 　ＴＥＬ２（ＴＥＬ２）、ＨＬＴＥＬ２ 　ＴＥＬ２コメント（ＴＥＬ２備考）、ＨＬＴＥＬ２ＣＭＮＴ 　数値１（予備）、ＨＬＮＦＩＬＬＥＲ５ 　数値２（予備）、ＨＬＮＦＩＬＬＥＲ６ 　登録日時（作成日時）、ＨＬＴＯＲＯＫＵＹＭＤ 　更新日時（更新日時）、ＨＬＫＯＳＨＩＮＹＭＤ ・「２１施設マスタ」テーブルにつき、以下のフィールド（フィールド名の右の記載はフィールドＩＤ） 　温泉地コード（温泉地番号）、ＳＴＳＰＡＣＤ 　登録日時（作成日時）、ＳＴＯＲＯＫＵＹＭＤ 　更新日時（更新日時）、ＳＴＫＯＳＨＩＮＹＭＤ 　削除フラグ、ＳＴＤＥＬＥＴＥＣＬＳ 　数値１（予備）、ＳＴＦＩＬＬＥＲ５ 　数値２（予備）、ＳＴＦＩＬＬＥＲ６ 　観光フラグ、ＳＴＳＴＦＬＧ 　宿泊フラグ、ＳＴＨＬＦＬＧ ・「２３観光施設マスタ」テーブルにつき、以下のフィールド（フィールド名の右の記載はフィールドＩＤ） 　登録日時（作成日時）、ＳＧＴＴＯＲＯＫＵＹＭＤ 　更新日時（更新日時）、ＳＧＴＫＯＳＨＩＮＹＭＤ 　そして、上記１９個のフィールドは、いずれも、それ以外の、例えばプライマリー・キーの設定された「施設コード」フィールドや、施設名称や種別、室数等、原告ＣＤＤＢと一致するフィールドと比して、重要なものとはいえない。 　また、別紙８記載のとおりと認められる被告ＣＤＤＢ（当初版・２００６年版）のフィールド間のリレーションをみると（争いのあるリレーションについての判断は後記する。）、施設コード同士、代表道路地点や市区町村コード等の間でリレーションをとるテーブルの参照の仕方もほぼ同じものであり、両者は同じ目的で使用されるものと認められる。 　そうすると、これら被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」、「２９旅館マスタ基本」、「２３観光マスタ基本」については、原告ＣＤＤＢの「２０ホテル・旅館テーブル」、「２１観光施設テーブル」と実質的に一致するテーブルであると認められる。 　また、被告ＣＤＤＢ（当初版・２００６年版）の「２６観光料金マスタ」と、原告ＣＤＤＢの「２２観光施設備考テーブル」とを比較すると、フィールド内容において、別紙３記載のとおり、原告ＣＤＤＢの方が若干詳細にフィールド区分がされているものの、テーブルの参照の仕方はほぼ同じものであり、両者は同じ目的で使用されるものと認められる。そうすると、被告ＣＤＤＢ（当初版・２００６年版）の「２６観光料金マスタ」についても、一致するフィールドであると認められる。 　一方、被告ＣＤＤＢ（当初版・２００６年版）の「２５観光料金種別マスタ」は、原告ＣＤＤＢの「２１観光施設テーブル」、「２２観光施設備考テーブル」に、料金区分自体のフィールドは存するものの、被告ＣＤＤＢ（当初版・２００６年版）の「２５観光料金種別マスタ」の「料金種別コード」や「料金種別名称」自体の区分やフィールドが原告のＣＤＤＢには存在せず、そのテーブルが一致するものとは認められない。 　以上によれば、原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とで一致するマスターテーブルは、被告ＣＤＤＢ（当初版・２００６年版）のテーブルで数えると上記２８個、原告ＣＤＤＢの対応するテーブルで数えると２７個であると認められる。 ｂ　一致しないマスターテーブル 　上記のとおり、被告ＣＤＤＢ（当初版・２００６年版）の「２５観光料金種別マスタ」は、原告ＣＤＤＢに対応するマスターテーブルが存在しない。 　その他、原告ＣＤＤＢのマスターテーブルのうち、「０３方面テーブル」、「０４方面設定テーブル」については、被告システムでは、方面検索の機能がないため、対応するテーブルが存在しない。 　また、原告ＣＤＤＢのマスターテーブルのうち、「３３路線構成テーブル」、「３４路線テーブル」、「３５時刻表料金テーブル」、「３６路線検索テーブル」、「３７路線検索索引テーブル」、「３８路線タイプテーブル」、「３９便テーブル」、「４０運行日定義テーブル」、「４１時刻テーブル」、「４３交通機関種別テーブル」、「４５検索地方範囲定義テーブル」、「４６地方別路線索引テーブル」、「４７駅通過線索引テーブル」についても、被告ＣＤＤＢ（当初版・２００６年版）に対応するマスターテーブルが存在しない。 　このうち、「４５検索地方範囲定義テーブル」については、二地点間の検索範囲を管理するためのテーブルであり、原告システム提供当時から存在するテーブルであるところ、原告システム提供開始当時は、パソコンの性能が低く、検索効率を上げるための工夫として必要とされていたが、その後、パソコンの性能が向上したため、必要性が乏しくなっていたテーブルであることが認められる。〔甲３、別紙２〕 　なお、上記のうち、被告ＣＤＤＢ（当初版・２００６年版）に存するが、原告ＣＤＤＢに存しない２個のテーブル（「２８観光詳細種別マスタ〔テーブルＩＤ；ＡＺＭＳＴＫＭＫ〕」と「２７観光種別マスタ〔テーブルＩＤ；ＡＺＭＳＴＳＭ〕」は、原告ＣＤＤＢには含まれないものの、原告システムをユーザーのハードウェア内にインストールした際に作成される原告マスターテーブルの中に、これら被告ＣＤＤＢ（当初版・２００６年版）の二つのテーブルに対応するマスターテーブル（「２３観光施設種別テーブル」及び「２４観光施設検索タイトルテーブル」）が存在する。 　すなわち、上記原告システムの「２３観光施設種別テーブル」に含まれるフィールドは「種別番号〔フィールドＩＤ；ＳＫＣＬＳＣＤ〕」フィールド、「種別名称〔フィールドＩＤ；ＳＫＣＬＳＮＭ〕」フィールドの二つのフィールドであるところ、被告ＣＤＤＢ（当初版・２００６年版）の「２８観光詳細種別マスタ」テーブルに含まれるフィールドは「詳細種別コード〔フィールドＩＤ；ＳＫＣＬＳＣＤ〕」フィールド、「観光詳細種別名称〔フィールドＩＤ；ＳＫＣＬＳＮＭ〕」フィールドのほかは、フラグ、区分、日付、数値、登録日時、更新日時等のフィールドであり、上記フラグ等を除いた重要なフィールドについてはフィールドＩＤが完全に一致している。また、原告システムの「２４観光施設検索タイトルテーブル」に含まれるフィールドは「観光施設検索タイトルコード〔フィールドＩＤ；ＳＳＳＥＥＴＬＣＤ〕」フィールド、「表示タイトル名〔フィールドＩＤ；ＳＳＴＴＬＮＭ〕」フィールド、「種別数〔フィールドＩＤ；ＳＳＣＬＳＮＵＭ〕」フィールド、「種別コード１〔フィールドＩＤ；ＳＳＣＬＳ１〕」フィールド、「種別コード２〔フィールドＩＤ；ＳＳＣＬＳ２〕」フィールド、「種別コード３〔フィールドＩＤ；ＳＳＣＬＳ３〕」フィールド、「種別コード４〔フィールドＩＤ；ＳＳＣＬＳ４〕」フィールド、「種別コード５〔フィールドＩＤ；ＳＳＣＬＳ５〕」フィールド、「種別コード６〔フィールドＩＤ；ＳＳＣＬＳ６〕」フィールド、「種別コード７〔フィールドＩＤ；ＳＳＣＬＳ７〕」フィールド、「種別コード８〔フィールドＩＤ；ＳＳＣＬＳ８〕」フィールド、「種別コード９〔フィールドＩＤ；ＳＳＣＬＳ９〕」フィールド、「種別コード１０〔フィールドＩＤ；ＳＳＣＬＳ１０〕」フィールドの１３個のフィールドであるところ、被告ＣＤＤＢ（当初版・２００６年版）の「２７観光種別マスタ」テーブルに含まれるフィールドのうち「観光種別コード〔フィールドＩＤ；ＳＳＳＥＥＴＬＣＤ〕」フィールド、「種別名称〔フィールドＩＤ；ＳＳＴＴＬＮＭ〕」フィールドについては、原告ＣＤＤＢのフィールドＩＤと完全に一致しており、「観光種別コード〔フィールドＩＤ；ＳＳＣＬＳ〕」フィールドについても、原告ＣＤＤＢのフィールドＩＤのうち、「種別コード」フィールドのフィールドＩＤの数字を除く部分（「ＳＳＣＬＳ」）と一致しており、その余はフラグ、区分、日付、数値、登録日時、更新日時等のフィールドとなっている。〔別紙３、甲８別紙Ｂ−３−１の２頁〕 　このように、原告ＣＤＤＢと一致しない被告ＣＤＤＢ（当初版・２００６年版）の「２７観光種別マスタ」と「２８観光詳細種別マスタ」テーブルは、原告ＣＤＤＢには含まれないものの、内容的にこれと一致するテーブルが原告システムには存在する。 (イ)　被告ＣＤＤＢ（当初版・２００６年版）の各テーブルに存在するフィールドの種類及び数 　原告ＣＤＤＢには４２個のテーブルに、４０５個のフィールドが存するところ、被告ＣＤＤＢ（当初版・２００６年版）の各テーブルに存在するフィールドＩＤは別紙３記載のとおりであり、３１個のテーブルに３１８個のフィールドが存する。 　フィールドのうち、「作成日時」、「更新日時」及び「削除区分」のフィールドは、データ更新やテーブル管理を行うための管理項目であり、データベースの検索機能やデータの内容自体に影響を及ぼす性質のものではない。〔甲３、７頁〕 　そうすると、被告ＣＤＤＢ（当初版・２００６年版）における、「２９旅館マスタ基本」、「２１施設マスタ」、「２３観光マスタ基本」、「２６観光料金マスタ」、「２５観光料金種別マスタ」、「２７観光種別マスタ」、「２８観光詳細種別マスタ」（別紙３の記載順）に各１個ずつ存在する「登録日時（作成日時）」及び「更新日時（更新日時）」フィールド（合計１４個）、「２６観光料金マスタ」に１個存在する「料金デフォルトフラグ（削除区分）」の合計１５個のフィールドを除くと、被告ＣＤＤＢ（当初版・２００６年版）のフィールドのうち、これらを除いたフィールド数は、３０３個となる。 　そして、このうち、別紙３記載のとおり、原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とでは、一致するテーブル２８個につき、一致するフィールドは２９９個である。 　上記のとおり原告ＣＤＤＢのマスターテーブルと一致する被告ＣＤＤＢ（当初版・２００６年版）のテーブルにおけるフィールド項目については、別紙３記載のとおり、ここから登録日時、更新日時及び削除区分のフィールドを除くと２８６個となり、このうち原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とで一致するフィールドは２５２個である。 (ウ)　テーブル間の関連付け 　別紙３のとおり、原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とでは、原告ＣＤＤＢのマスターテーブルと一致する２８個のテーブルに関して、プライマリー・キーの設定につき、原告ＣＤＤＢの「０２地区・県名テーブル」の「地区コード」フィールドを除き、一致したフィールドないし同一のテーブルの同種フィールドにプライマリー・キーが設定されている。 　また、別紙５、別紙８（青丸と青丸を結ぶ黒線〔黒太線を含む〕、及び、下記のとおり、青丸と青丸を結ぶ黒点線が、当裁判所の認めるリレーションである。）のとおり、原告ＣＤＤＢのマスターテーブルと一致する２８個のテーブルに関して、原告ＣＤＤＢに存在する関連付けのほぼ全てについて、同様のリレーションが被告ＣＤＤＢ（当初版・２００６年版）に存在するものといえる（なお、原告ＣＤＤＢの「０１市区町村テーブル」と「２０ホテル・旅館テーブル」、「２１観光施設テーブル」とのリレーション、被告ＣＤＤＢ（当初版・２００６年版）の「４市区町村マスタ」と「２１施設マスタ」、「２９旅館マスタ基本」、「２３観光施設マスタ」、「２６観光料金マスタ」のテーブルとのそれぞれのリレーションの関係の評価については、後記のとおり）。 　なお、この点に関して被告らは、被告ＣＤＤＢ（当初版・２００６年版）の「道路構成地点マスタ〔テーブルＩＤ；ＡＺＭＲＯＡＤＰ〕」の「道路構成地点番号」フィールドと「道路構成地点索引マスタ〔テーブルＩＤ；ＡＺＭＲＯＡＤＱ〕」の「道路構成地点インデックス」フィールド及び「構成地点数」フィールドとの各リレーション、「３６道路名マスタ〔テーブルＩＤ；ＡＺＭＲＯＡＤＡ〕」の「道路コード」フィールドと「道路構成地点索引マスタ」の「道路構成地点インデックス」フィールドとのリレーションをいずれも否認し（別紙８で青丸と青丸を結ぶ黒点線で示されたリレーション）、「道路構成地点マスタ」の「レコード番号」フィールドと「道路構成地点索引マスタ」の「道路構成地点インデックス」フィールドとのリレーション、「３６道路名マスタ」の「道路コード」フィールドと「道路構成地点索引マスタ」の「レコード番号」フィールドとのリレーションの存在を主張するが（別紙８で赤丸と赤丸を結ぶ赤点線で示されたリレーション）、別紙３記載のとおりの被告ＣＤＤＢ（当初版・２００６年版）の「道路構成地点マスタ」、「道路構成地点索引マスタ」、「３６道路名マスタ」の各テーブルに含まれるフィールドの数やプライマリー・キーの設定状況を含めたフィールドの内容、「４市区町村マスタ」及び「２１施設マスタ」のテーブル等に存するそれぞれの「代表道路地点コード」フィールド等と「道路構成地点マスタ」の「道路構成地点番号」フィールドとの間にリレーションがとられていることについて争いがないこと、被告らが、別紙４記載のとおり、「３６道路名マスタ」、「道路構成地点マスタ」、「道路構成地点索引マスタ」について、いずれも原告ＣＤＤＢの対応するフィールド等からデータをコピーしたとしているところ、そのデータの内容などからすると、別紙８記載のとおり、「道路構成地点マスタ」テーブルの「道路構成地点番号」フィールドと「道路構成地点索引マスタ」テーブルの「道路構成地点インデックス」フィールド及び「構成地点数」フィールドとの各リレーション、「３６道路名マスタ」テーブルの「道路コード」フィールドと「道路構成地点索引マスタ」テーブルの「道路構成地点インデックス」フィールドとのリレーション（別紙８で青丸と青丸を結ぶ黒点線で示されたリレーション）の存在がいずれも認められる。これに対し、被告ＣＤＤＢ（当初版・２００６年版）の「３６道路名マスタ」の「道路コード」フィールドと「道路構成地点索引マスタ」の「レコード番号」フィールドと「道路構成地点マスタ」の「レコード番号」フィールドと「道路構成地点索引マスタ」の「道路構成地点インデックス」フィールドとのリレーションの存在について、「道路構成地点索引マスタ」の「レコード番号」フィールドと「道路構成地点マスタ」の「レコード番号」フィールドには、それぞれプライマリー・キーが設定されているものの、上記のとおり争いのない「道路構成地点マスタ」の「道路構成地点番号」フィールドと他のテーブルの各地点コードフィールドとのリレーション、「３６道路名マスタ」の「道路コード」フィールドと他のテーブルの各道路コードないし道路番号フィールドとのリレーションの関係や、上記のとおりの原告主張のリレーション（別紙８で青丸と青丸を結ぶ黒点線で示されたリレーション）の存在が認められること等からして、被告ら主張のリレーション（別紙８で赤丸と赤丸を結ぶ赤点線で示されたリレーション）の存在は認められないというべきである。 　また、上記のとおり、被告ＣＤＤＢ（当初版・２００６年版）では、原告ＣＤＤＢの「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「２２観光施設備考テーブル」の３テーブルに対応するテーブルとして、被告ＣＤＤＢ（当初版・２００６年版）では「２１施設マスタ」、「２９旅館マスタ基本」、「２３観光マスタ基本」、「２６観光料金マスタ」の４テーブルを設けており、このうち「２１施設マスタ」テーブルについては、別紙３、５、８記載の原告ＣＤＤＢの「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」、「２９旅館マスタ基本」、「２３観光マスタ基本」、「２６観光料金マスタ」の各テーブルのそれぞれのフィールド、テーブル間のリレーションの内容を比較すると、被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」テーブルは、原告ＣＤＤＢの「２０ホテル・旅館テーブル」及び「２１観光施設テーブル」の共通項目を括りだしたものと認められ、上位のテーブルとして設けられているものと認められる。そして、原告ＣＤＤＢにおける「０１市区町村テーブル」が「２０ホテル・旅館テーブル」及び「２１観光施設テーブル」の二つのテーブルとリレーションを取っているのに対して、被告ＣＤＤＢ（当初版・２００６年版）では「４市区町村マスタ」は、原告ＣＤＤＢの「２０ホテル・旅館テーブル」及び「２１観光施設テーブル」の共通項目を括りだした上位のテーブルとなっている「２１施設マスタ」の一つのテーブルとのみリレーションを取っていることから、これと関連するリレーションの線の分が、別紙５と別紙８を対比すると、少なくなっている。 イ　被告ＣＤＤＢ（当初版・２００６年版）の体系的構成が、原告ＣＤＤＢの複製又は翻案に当たるか (ア)　上記のとおり、原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とでは、原告ＣＤＤＢにおける、「０１市区町村テーブル」、「０２地区・県名テーブル」、「０５緯度経度テーブル」、「０６ＵＲＬアドレステーブル」、「０７ＵＲＬ種別テーブル」、「０８ＵＲＬ分類テーブル」、「０９地点名テーブル」、「１０道路テーブル」、「１１接続テーブル」、「１２禁止乗換テーブル」、「１３有料道路番号テーブル」、「１４区間料金テーブル」、「１５首都高速料金テーブル」、「１６道路構成地点テーブル」、「１７道路構成地点索引テーブル」、「１８市区町村通過道路索引テーブル」、「１９県範囲定義テーブル」、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「２２観光施設備考テーブル」、「２８協定施設テーブル」、「２９券種テーブル」、「３０協定旅館テーブル」、「３１連結協定テーブル」、「３２駅テーブル」、「４２会社テーブル」及び「４４地方別会社索引テーブル」の２７個のテーブルにつき、これと一致する２８個のテーブルが被告ＣＤＤＢ（当初版・２００６年版）にも存する。 　そして、別紙３のとおり、原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とで一致するテーブルに存する総フィールドも２８８個にのぼり、このうち、原告ＣＤＤＢと一致するフィールド数は、２５２個である。 　さらに、テーブル間の関連付けについてみると、原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とでは、別紙５、８のとおり、原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とで一致するフィールドについて、同様のリレーションが存するものと認められる。上記のとおり、被告ＣＤＤＢ（当初版・２００６年版）では、「２１施設マスタ」を原告ＣＤＤＢの「２０ホテル・旅館テーブル」及び「２１観光施設テーブル」の上位のテーブルとして設けているところから、原告ＣＤＤＢにおける「０１市区町村テーブル」と「２０ホテル・旅館テーブル」、「２１観光施設テーブル」とのリレーションに比して、被告ＣＤＤＢ（当初版・２００６年版）の「４市区町村マスタ」は上位テーブルの「２１観光施設マスタ」とのみリレーションをとっており、これと関連するリレーションの線が、原告ＣＤＤＢと比して、その分少なくなっている。しかし、上記のとおり、原告ＣＤＤＢの「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「２２観光施設備考テーブル」についても、これら三つのテーブルに対応する、被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」、「２９旅館マスタ基本」、「２３観光マスタ基本」、「２６観光料金マスタ」と実質的に一致するテーブルであると認められること、そして、これらテーブルに含まれるフィールドの内容等からして、原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）における「０１市区町村テーブル」ないし「４市区町村マスタ」と、宿泊施設及び観光施設等のテーブルとのそれぞれのリレーションのとり方は、実質的には同一であるものと認められる。 (イ)　前記認定のとおり、原告ＣＤＤＢは、それまで存しなかった団体旅行の行程検索・行程表作成のため、顧客である旅行業者等からのヒアリングや寄せられた要望等に基づき、出発地、到着地、交通手段、経由地である観光施設、宿泊施設をデータベース化してこれをコンピュータで効率よく検索できるようにするためのデータベースであるところ、上記被告ＣＤＤＢ（当初版・２００６年版）と共通するテーブルに関してみると、原告ＣＤＤＢの「０１市区町村テーブル」、「３２駅テーブル」、「２０ホテル・施設テーブル」、「２１観光施設テーブル」、「０９地点名テーブル」、「１１接続テーブル」及び「１０道路テーブル」により、出発地、経由地、目的地に面した道路に関するデータの検索を可能にし、次に「０９地点名テーブル」、「１０道路テーブル」、「１１接続テーブル」、「１２禁止乗換テーブル」、「１４区間料金テーブル」及び「１５首都高速料金テーブル」により、道路を利用した移動に関する経路探索・料金の算出に必要なデータの検索を可能にしていること、また、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「２２観光設備備考テーブル」、「０５緯度経度テーブル」、「０６ＵＲＬアドレステーブル」、「０７ＵＲＬ種別テーブル」及び「０８ＵＲＬ分類テーブル」により、ホテル・旅館、観光施設に関する情報を検索することを可能にしていること、そして、「０１市区町村テーブル」及び「０２地区・県名テーブル」は、道路と地図を関連付ける情報として、地図から検索をするときに用いられていること、「０１市区町村テーブル」、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」及び「３２駅テーブル」には施設等の近辺の道路地点の情報が代表道路地区コードや代表道路地点番号として格納されており、当該市区町村内にあるこれらの施設や駅などを選ぶことを通じて、「０９地点名テーブル」の必要な道路地点を選ぶことができること、観光施設も「２１観光施設テーブル」から選択し、絞り込みは、「０２地区・県名テーブル」、「０１市区町村テーブル」から行うことができること、観光施設の名称は「２１観光施設テーブル」に、検索結果の観光施設について、当該観光施設に関する様々の情報は、「２２観光施設備考テーブル」に格納されており、観光施設に関するホームページの情報も「０６ＵＲＬアドレステーブル」、「０７ＵＲＬ種別テーブル」から参照可能であり、最終的に行程に入れるかどうかを判断することができること、が認められる。 　また、宿泊施設については、「２０ホテル・旅館テーブル」から選択し、地区は「０２地区・県名テーブル」、都道府県も同じく「０２地区・県名テーブル」、市区町村は「０１市区町村テーブル」、地図上の範囲設定は、地図ソフトと「０５緯度経度テーブル」、「２０ホテル・旅館テーブル」により、宿泊種別は「２０ホテル・旅館テーブル」、名称は「２０ホテル・旅館テーブル」、検索結果の宿泊施設については当該宿泊施設に関する様々な情報、すなわち、和室、洋室の客室数、収容人員、料金、付帯施設、駐車場などが「２０ホテル・旅館テーブル」に格納されていて、当該宿泊施設に関するホームページの情報も「０６ＵＲＬアドレステーブル」、「０７ＵＲＬ種別テーブル」が対応し、これらを参照して、ユーザーである旅行会社ないしその顧客の判断で行程等を決めることができることが認められる。 　以上のとおり、これら共通するテーブルについては、いずれも各テーブルを構成するフィールドにつき、原告ＣＤＤＢと、被告ＣＤＤＢ（当初版・２００６年版）とでほとんどが共通し、リレーションのとり方もほぼ共通するものである。 　そして、両者で共通するこれらの体系的構成は、原告ＣＤＤＢの制作者において、それまでのデータベースにはなかった設計思想に基づき構成した原告ＣＤＤＢの創作活動の成果であり、その共通する部分のみでデータベースとして機能し得る膨大な規模の情報分類体系であると認められ、データベースとして制作者の個性が表現されているものということができる。 　したがって、被告ＣＤＤＢ（当初版・２００６年版）と共通する上記原告ＣＤＤＢの部分については、データベースの体系的構成としての創作性を有するものと認めるのが相当である。 (ウ)　一方、原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とを比較すると、両者で一致しないマスターテーブルとして、被告ＣＤＤＢ（当初版・２００６年版）の「２５観光料金種別マスタ」、「２７観光種別マスタ」と「２８観光詳細種別マスタ」があり、これらは、原告ＣＤＤＢには含まれないものである。 　このうち「２５観光料金種別マスタ」については、そこに含まれるフィールドをみると、プライマリー・キーの設定された「料金種別コード」フィールド、「料金種別名称」、「料金メモ（管理用）」の各フィールドのほかは、フラグや日付、区分等のフィールドであり、このうち料金種別にかかるものは、原告ＣＤＤＢの「２１観光施設テーブル」、「２２観光施設備考テーブル」では４種類までの料金しか登録することができないところ、被告ＣＤＤＢ（当初版・２００６年版）の「２５観光料金種別マスタ」を設けることにより５種類以上の料金設定についても登録できるようにテーブルを設けることとしたものである。〔乙２０〕 　しかし、上記のとおり原告ＣＤＤＢでも料金種別により分類可能であったところ、これについて、料金種別を増やすためにテーブルを設けること自体は、原告ＣＤＤＢに新たに創作的表現を加えたものとはいい難い。 　また、「２７観光種別マスタ」と「２８観光詳細種別マスタ」については、上記のとおり、原告システムをユーザーのハードウェア内にインストールした際に作成される原告マスターテーブルの中に、これら二つのテーブルに対応するマスターテーブルである「２３観光施設種別テーブル」及び「２４観光施設検索タイトルテーブル」が存在し、しかも、これらテーブルについてのテーブルの種類やＩＤのほとんどが原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とで一致することなどからすれば、これらは被告ＣＤＤＢ（当初版・２００６年版）において新たに加わった創作的表現の成果ということはできず、実質的に原告システム中に存する原告ＣＤＤＢと関連する部分を、ＣＤで提供されるデータベース中に移した関係にすぎないものと認められる。 　そして、フィールドについてみても、被告ＣＤＤＢ（当初版・２００６年版）の「道路構成地点マスタ」、「道路構成地点索引マスタ」の各「レコード番号」フィールドについては、それぞれ「道路構成地点索引マスタ」テーブルの「道路構成地点インデックス」フィールド、「３６道路名マスタ」テーブルの「道路コード」フィールドとのリレーションがとられていること等からすると、原告ＣＤＤＢの「１６道路構成地点テーブル」、「１７道路構成地点索引テーブル」の各テーブルを構成するフィールドと実質的な相違はないものと認められる。 　さらに、リレーションのとり方についてみても、原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とで異なるリレーションとなっている、被告ＣＤＤＢ（当初版・２００６年版）で「４市区町村マスタ」は、施設に関しては「２１施設マスタ」とのみリレーションをとっていることから、原告ＣＤＤＢにおける「０１市区町村テーブル」が「２０ホテル・旅館テーブル」、「２１観光施設テーブル」の二つのテーブルとリレーションをとっていることに対して、リレーションが少なくなっているところ、既に検討したとおり、被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」及びこれと関連する、「２９旅館マスタ基本」、「２３観光マスタ基本」テーブルについては、原告ＣＤＤＢの「２０ホテル・旅館テーブル」、「２１観光施設テーブル」とは実質的に一致するテーブルであると認められることや、別紙８のとおり認められる被告ＣＤＤＢ（当初版・２００６年版）の「４市区町村マスタ」、「３１ＵＲＬアドレスマスタ」、「３４緯度経度マスタ」テーブル等と、「２１施設マスタ」、「２９旅館マスタ基本」、「２３観光マスタ基本」テーブル等、及び、「２１施設マスタ」テーブルと、「２９旅館マスタ基本」、「２３観光マスタ基本」テーブルとのリレーションのとり方からすると、リレーションのとり方において、被告ＣＤＤＢ（当初版・２００６年版）のリレーションのとり方には、原告ＣＤＤＢのリレーションのとり方に、新たな創作性を加えたものとはいえない。 (エ)　そうすると、これら被告ＣＤＤＢ（当初版・２００６年版）が原告ＣＤＤＢと共通性を有する部分は、原告ＣＤＤＢの創作的表現の本質的特徴の同一性が維持されており、これを直接感得することができるものというべきであり、被告ＣＤＤＢ（当初版・２００６年版）において変更が加えられた部分については、創作性を有しない部分であるということができる。 ウ　被告ＣＤＤＢ（当初版・２００６年版）と原告ＣＤＤＢとの情報の選択の共通性 (ア)　フィールド項目の選択の類似性 　前記のとおり、テーブル管理のためのフィールドである「登録日時」、「更新日時」及び「削除区分」のフィールドを除いた被告ＣＤＤＢ（当初版・２００６年版）のフィールド数のうち、２５２個が原告ＣＤＤＢのフィールドと一致している。 　このうち、被告ＣＤＤＢ（当初版・２００６年版）の「４市区町村マスタ」の７個のフィールド、「０３都道府県マスタ」の４個のフィールド、「緯度経度マスタ」の４個のフィールド、「３１ＵＲＬアドレスマスタ」の５個のフィールド、「３５地点マスタ」の８個のフィールド、「３６道路名マスタ」の４個のフィールド、「３８禁止乗換マスタ」の２個のフィールド、「有料道路番号マスタ」のうちの「道路番号」フィールド、「３９料金マスタ」の５個のフィールド、「４０高速料金マスタ」の５個のフィールド、「道路構成地点マスタ」の「道路構成地点番号」フィールド、「道路構成地点索引マスタ」の２個のフィールド、「市区町村通過道路索引マスタ」の３個のフィールド、「県範囲定義マスタ」の４個のフィールド、「協定施設マスタ」の３１個のフィールド、「券種マスタ」の１９個のフィールド、「協定旅館マスタ」の２１個のフィールド、「連結協定マスタ」の３２個のフィールド、「４７駅マスタ」の１０個のフィールド、「４２会社マスタ」の４個のフィールド、「地方別会社索引マスタ」の２個のフィールドでは、フィールドＩＤが原告ＣＤＤＢの対応するフィールドと完全に一致している。詳細は別紙３記載のとおりである。 　また、原告ＣＤＤＢの「２０ホテル・旅館テーブル」の「加盟団体種別」フィールドと被告ＣＤＤＢ（当初版・２００６年版）の「２９旅館マスタ基本」の「加盟団体種別」フィールド、原告ＣＤＤＢの「２０ホテル・旅館テーブル」の「和室客室数」・「洋室客室数」・「和洋室客室数」・「収容人員」・「付帯施設」フィールドと被告ＣＤＤＢ（当初版・２００６年版）の「２９旅館マスタ基本」の「和室数」・「洋室数」・「和洋室数」・「総収容人員」・「設備」フィールド、さらにはいずれもプライマリー・キーが設定されている、原告ＣＤＤＢの「２０ホテル・旅館テーブル」の「ホテル旅館コード」フィールドと被告ＣＤＤＢ（当初版・２００６年版）の「２９旅館マスタ基本」の「施設コード（施設番号）」フィールド、原告ＣＤＤＢの「２１観光施設テーブル」の「地区コード」・「都道府県コード」・「市区町村番号」・「観光施設名（カナ）」フィールドと被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」の「地区コード」・「都道府県コード」・「市区町村コード」・「名称かな」フィールド、いずれもプライマリー・キーが設定された原告ＣＤＤＢの「２１観光施設テーブル」の「観光施設番号」フィールドと被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」の「施設コード」フィールド、原告ＣＤＤＢの「２１観光施設テーブル」の「施設経度」・「施設緯度」・「代表道路地点番号」フィールドと被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」の「施設経度」・「施設緯度」・「代表道路地点コード」フィールド等においても、フィールドＩＤが完全に一致している。 　そうすると、フィールド項目の選択について、これらは一致しているものと認められる。 （イ）レコードの選択の類似性 　さらに、被告らは、被告ＣＤＤＢ（当初版・２００６年版）において、原告ＣＤＤＢのテーブルのうち、以下の２０個のテーブルに含まれるレコードをコピーして用いたことを認めている。 　そのテーブルとは、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「０５緯度経度テーブル」、「０６ＵＲＬアドレステーブル」、「０７ＵＲＬ種別テーブル」、「０８ＵＲＬ分類テーブル」、「０１市区町村テーブル」、「０２地区・県名テーブル」、「０９地点名テーブル」、「１０道路テーブル」、「１１接続テーブル」、「１２禁止乗換テーブル」、「１３有料道路番号テーブル」、「１４区間料金テーブル」、「１５首都高速料金テーブル」、「１６道路構成地点テーブル」、「１７道路構成地点索引テーブル」、「１８市区町村通過道路索引テーブル」、「１９県範囲定義テーブル」及び「３２駅テーブル」である。 　そして、別紙４の各テーブルのレコード数記載のとおり、このうち、レコード数が４７で同一であり、一般的な内容のとおりであることが推認される「０２地区・県名テーブル」を除き、原告ＣＤＤＢの「０９地点名テーブル」、「１０道路テーブル」、「１１接続テーブル」、「１２禁止乗換テーブル」、「１４区間料金テーブル」、「１５首都高速料金テーブル」、「１６道路構成地点テーブル」、「１７道路構成地点索引テーブル」、「１８市区町村通過道路索引テーブル」、「１９県範囲定義テーブル」及び「３２駅テーブル」においては、それらテーブルのそれぞれの数百ないし数十万のレコード数につき、各近似するレコード数が被告ＣＤＤＢ（当初版・２００６年版）の対応するテーブルには収録されている。 (ウ)　具体的な情報の同一ないし類似性 a　地点名テーブルの道路情報 　原告ＣＤＤＢ（２００６年１１月版）の「０９地点名テーブル」には、１万２８２２件のレコードが収録され、被告ＣＤＤＢ（当初版・２００６年版）の「３５地点マスタ」には、そのうちの９９．６％である１万２７７４件につき、一致する道路地点（例えば、「関ＪＣＴ（伊勢自動車道・名阪国道）」、「芸濃ＩＣ（伊勢自動車道、県道１０号）」等）のレコードが収録されている。〔甲３２〕 b　緯度経度情報の一致 　そして、原告ＣＤＤＢの「０９地点名テーブル」の上記道路地点の緯度経度情報は、前記のとおり、原告ＣＤＤＢ作成時に、作成者自身がパソコンのマウスを地図上でクリックする方法で選択した場所について、これを０．１秒単位で緯度経度を測定して数値化したものである。 　その際、原告ＣＤＤＢにおいては、一般的な度・分・秒の表記ではなく、度・分・秒につき、０．１秒単位で、Ａ度Ｂ分Ｃ．Ｄ秒を以下の計算式で算出された数値で収録しており、６ないし７桁の数値となって算出される。なお、この０．１秒は、実際には約３メートルである。 　（計算式） Ａ×３６０００＋Ｂ×６００＋Ｃ×１０＋Ｄ 　例えば、上記「関ＪＣＴ（伊勢自動車道・名阪国道）」については、一般的な度・分・秒表記であれば、経度１３６度２４分４８．２秒、緯度３４度５０分３３．１秒であるところ、これを上記表記で表すと、経度「４９１０８８２」、緯度「１２５４３３１」となる。 　被告ＣＤＤＢ（当初版・２００６年版）も、６ないし７桁の数値で緯度経度情報を収録しているところ、被告ＣＤＤＢ（当初版・２００６年版）の「関ＪＣＴ（伊勢自動車道・名阪国道）」の緯度経度表記も、全く同じ経度「４９１０８８２」、緯度「１２５４３３１」であり、上記道路地点のうち、この６ないし７桁で表される緯度及び経度情報につき、これが原告ＣＤＤＢ（２００６年１１月版）と完全に数値が一致する率（完全一致率）は９８．７％であり、１万２６５２件の一致するレコードが収録されている。〔甲２２、２８、３２、３９、７０〕 ｃ　選択道路の一致 　原告ＣＤＤＢは、上記のとおり、大型観光バスでの移動に適した道路の選択を行っており、多くの府県道、道道等の中から、北海道では８０道道、福岡県では４７県道を選択しているところ、被告ＣＤＤＢ（当初版・２００６年版）では、北海道では全く同じ８０道道を、福岡県でもこれと一致する県道のうち４１県道を選択している。〔甲４８〕 ｄ　その他の情報の一致 (a)　原告ＣＤＤＢの「０６ＵＲＬアドレステーブル」と被告ＣＤＤＢ（当初版・２００６年版）の「３１ＵＲＬアドレスマスタ」における情報の一致 �@　被告ＣＤＤＢ（当初版・２００６年版）では、同一の宿泊施設のＵＲＬデータを、「マスタ種別（ＵＲＬ種別）」フィールド（フィールドＩＤ；ＲＬ１ＫＩＮＤ）の「５」（以下、「ＵＲＬ種別５」という。）に、原告ＣＤＤＢの「テーブル種別」フィールド（フィールドＩＤ；ＲＬ１ＫＩＮＤ）と同じ施設番号で登録するとともに、これを再び「マスタ種別（ＵＲＬ種別）」フィールド（フィールドＩＤ；ＲＬ１ＫＩＮＤ）の「８」（以下、「ＵＲＬ種別８」という。）に、原告ＣＤＤＢと異なる施設番号で、重複登録している。 　すなわち、原告ＣＤＤＢでは、「テーブル種別」フィールド（フィールドＩＤ；ＲＬ１ＫＩＮＤ）のＵＲＬ種別の「５」として宿泊施設のＵＲＬデータを登録している。他方、被告ＣＤＤＢ（当初版・２００６年版）は宿泊施設と観光施設のＵＲＬデータを、ＵＲＬ種別８として統合して登録していることに加え、ＵＲＬ種別５としても、宿泊施設の同じＵＲＬデータを重複登録していることになる。 　その例として、原告ＣＤＤＢ「テーブル種別」フィールド（フィールドＩＤ；ＲＬ１ＫＩＮＤ）のＵＲＬ種別５の施設番号１番である「アイスバーグホテル」は、被告ＣＤＤＢ（当初版・２００６年版）のＵＲＬ種別５に原告ＣＤＤＢと同じ施設番号１番で格納されているところ、被告ＣＤＤＢ（当初版・２００６年版）のＵＲＬ種別８では、同じ「アイスバーグホテル」が、施設番号９４４０番として重複登録されている。すなわち、被告ＣＤＤＢ（当初版・２００６年版）は、同一の施設について、ＵＲＬ種別５とＵＲＬ種別８とで異なる施設番号を付与してそれぞれ登録している。原告ＣＤＤＢ「テーブル種別」フィールド（フィールドＩＤ；ＲＬ１ＫＩＮＤ）のＵＲＬ種別５の施設番号２番である「札幌第一ホテル 本館」等についても、同様である。〔甲６５の別紙１〕 　これらは、原告ＣＤＤＢのＵＲＬ種別５のデータを一旦コピーし、その後これをＵＲＬ種別８に番号を変えて登録したが、ＵＲＬ種別５のデータもそのまま残存してしまったことによるものと認められる。 　そして、この原告ＣＤＤＢの「テーブル種別」フィールド（フィールドＩＤ；ＲＬ１ＫＩＮＤ）に登録されている上記ＵＲＬデータにつき、被告ＣＤＤＢ（当初版・２００６年版）において、１万５０００件以上のデータが一致している。〔甲６５〕 �A　上記宿泊施設の重複登録と同様のことが、観光施設についてのＵＲＬデータについても認められる。 　被告ＣＤＤＢ（当初版・２００６年版）は同一の観光施設のＵＲＬデータを、「マスタ種別（ＵＲＬ種別）」フィールド（フィールドＩＤ；ＲＬ１ＫＩＮＤ）の「６」（以下、「ＵＲＬ種別６」という。）に、原告ＣＤＤＢの「テーブル種別」フィールド（フィールドＩＤ；ＲＬ１ＫＩＮＤ）と同じ施設番号で登録するとともに、ＵＲＬ種別８に原告ＣＤＤＢと異なる施設番号で重複登録している。すなわち、原告ＣＤＤＢは、「テーブル種別」フィールドに、ＵＲＬ種別６として観光施設のＵＲＬデータを登録しているところ、被告ＣＤＤＢ（当初版・２００６年版）は宿泊施設と観光施設のＵＲＬデータをＵＲＬ種別８として統合して登録していることに加え、ＵＲＬ種別６として観光施設につき、同じＵＲＬデータを重複登録している。例えば、原告ＣＤＤＢのＵＲＬ種別６の施設番号１番の「朝里岳」が、被告ＣＤＤＢ（当初版・２００６年版）のＵＲＬ種別６に原告ＣＤＤＢと同じ施設番号１番で格納されているところ、被告ＣＤＤＢ（当初版・２００６年版）の種別８でも、同じ「朝里岳」が施設番号１１７１７４番として重複登録されている。登録番号２の「無意根山」等でも同様である。〔甲６５の別紙２〕 　すなわち、被告ＣＤＤＢ（当初版・２００６年版）は、同一の観光施設について、上記宿泊施設と同様に、ＵＲＬ種別６とＵＲＬ種別８とで、異なる施設番号を付与して重複登録している。 　これも、上記同様、被告ＣＤＤＢ（当初版・２００６年版）が原告ＣＤＤＢのＵＲＬ種別６のデータを一旦コピーし、その後種別番号８に番号を変えて登録したが、ＵＲＬ種別６のデータもそのまま残存してしまったことによるものと認められる。 　これについても、原告ＣＤＤＢにおいて登録されている４万件以上のＵＲＬデータが、被告ＣＤＤＢ（当初版・２００６年版）と一致している。〔甲６５〕 �B　ＵＲＬに関し、原告ＣＤＤＢは、開発者の便宜のためとして、ＵＲＬ種別番号の１００００以降には、リンク集として、各種ＵＲＬデータを選択して登録している。このＵＲＬデータの登録は、原告ＣＤＤＢの制作者において、任意に選択して行ったものであることは、ＵＲＬデータの内容からも明らかである。その例としては、後記のほか、種別キー１番の優先順位２ないし４は、順番に、「全国鉄道会社OFFICIAL 系サイト総合リンク」、「国道９０１号」、「秩父札所めぐり［西武鉄道ＨＰ］」となっていること等からも明らかである。〔甲６５の別紙３〕 　被告ＣＤＤＢ（当初版・２００６年版）におけるこのＵＲＬデータは、原告ＣＤＤＢと完全に一致している。この中には、被告ＣＤＤＢ（当初版・２００６年版）の用途等に鑑みると、意味があるものとは考えにくい翼システムのＵＲＬが、３箇所（タイトルが「注意書き」の２箇所、「翼システム株式会社」の１箇所、合計３箇所）も重複登録されている点についても、完全に一致している。〔甲６５の別紙３〕 (b)　原告ＣＤＤＢの「１１接続テーブル」と被告ＣＤＤＢ（当初版・２００６年版）の「３７接続マスタ」における情報の一致 　原告ＣＤＤＢの「１１接続テーブル」と被告ＣＤＤＢ（当初版・２００６年版）の「３７接続マスタ」において、各接続番号が一致している。この接続番号の付与は、前記のとおり、隣接する道路地点間を一単位として、その一単位ごとに、原告ＣＤＤＢの制作者において付与した番号であり、機能としては、二地点間の情報を識別するものである。この接続番号は、原告ＣＤＤＢにおいて定められた、ある道路の一単位を登録する都度、上記のとおり原告システムの制作者において、任意に付与したものである。 　これについて、被告ＣＤＤＢ（当初版・２００６年版）の「３７接続マスタ」において、各道路の一単位に対して、原告ＣＤＤＢと同じ接続番号が付与されている。〔甲２８の別紙８。なお、別紙８の１／２の始点番号、終点番号につき、実際の地点名称を表示したものが２／２であり、格納されているデータが実質的に同じであることが認められる。〕 (c)　原告ＣＤＤＢの「１２禁止乗換テーブル」と被告ＣＤＤＢ（当初版・２００６年版）の「３８禁止乗換マスタ」における情報の一致 　原告ＣＤＤＢの「１２禁止乗換テーブル」の「乗換元接続番号」、「乗換先接続番号」の各フィールドには、接続テーブルのデータが格納されている。これらのデータが原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とで一致している。〔甲２８の別紙９〕 　被告らは、原告ＣＤＤＢからコピーして入力し、追加、修正、削除した旨主張するが、原告ＣＤＤＢの「１２禁止乗換テーブル」のフィールドは、「乗換元接続番号」、「乗換先接続番号」の二つの数値フィールドのみで構成されており、しかもその内容は、数値を羅列した表にすぎないから、一般的な資料等と比較することで、その正誤判定や修正等を行うことができない性質のものということができる。加えて、原告ＣＤＤＢの「１２禁止乗換テーブル」は、「０９地点名テーブル」のデータを３レコード分使用した上で、「１０道路テーブル」の２レコード分、「１１接続テーブル」の２レコード分のデータを使用し、これらテーブルとリレーションを取ることによって、はじめて意味のあるテーブルとなるものである。これらは、上記の原告ＣＤＤＢの設計ないし情報の選択の方針に基づいてデータを組み合わせてできたものであり、一般的な資料と比較して正誤判定等を行う性質のものでもなく、またその正誤判定等が可能なものとも認められない。〔甲７０、１０頁〕 (d)　原告ＣＤＤＢの「１９県範囲定義テーブル」と被告ＣＤＤＢ（当初版・２００６年版）の「県範囲定義マスタ」における情報の一致 �@　原告ＣＤＤＢが「１９県範囲定義テーブル」において、原告が独自に設定した登録データについて、被告ＣＤＤＢ（当初版・２００６年版）の「県範囲定義マスタ」に、同一のものが存在する。 　原告ＣＤＤＢの「１９県範囲定義テーブル」のテーブルは、出発都道府県から到着都道府県までの経由可能性のある都道府県を管理しているテーブルであり、原告ＣＤＤＢは、例えば、北海道から青森県までの経由可能性のある都道府県に関しては、「北海道、青森県、岩手県、秋田県」（通常想定される経路に比して原告が独自に設定した点は、岩手県、秋田県が入っていることである。）、北海道から岩手県では、「北海道、青森県、岩手県、宮城県、秋田県、山形県」（原告が独自に設定した点は、宮城県、秋田県、山形県が入っていることである。）となっている。同様に他の例でも経由都道府県が、原告が独自に設定した組合せで選択格納されている。この４７都道府県における出発と到着のパターンは２２０９（４７×４７）パターンあることになるが、被告ＣＤＤＢ（当初版・２００６年版）では、原告ＣＤＤＢの経由都道府県の組合せデータを完全に一致する形で格納している。〔甲６５の別紙８〕 �A　原告ＣＤＤＢの「１９県範囲定義テーブル」の、行程を開始する都道府県のコードである「始点県番号」、行程を終了する都道府県のコードである「終点県番号」、４７都道府県の内３２都道府県を通過するかどうかのデータである「県範囲定義ビット１」、４７都道府県の内１５都道府県を通過するかどうかのデータである「県範囲定義ビット２」の各フィールドに格納されているデータが、被告ＣＤＤＢ（当初版・２００６年版）の「県範囲定義マスタ」で一致している（フィールドＩＤ等も全て一致することについては、別紙３のとおりである。）。ある都道府県からある都道府県に向かう場合、通過する都道府県にどの県を組み入れるかには選択の幅があると認められるところ、これを表した原告ＣＤＤＢの県範囲定義ビット１、県範囲定義ビット２についても、このような選択範囲をとること自体については、選択の幅があるものと認められる。〔甲２８の別紙１０、甲６５の別紙８〕 エ　被告ＣＤＤＢ（当初版・２００６年版）の情報の選択が、原告ＣＤＤＢの複製又は翻案に当たるか (ア)　前記のとおり、原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とでは、情報項目としてのテーブル、フィールドの設定について、被告ＣＤＤＢ（当初版・２００６年版）のテーブル数３１個のうちの、２８個においてテーブルが一致している。そして、フィールド項目についても、３１８個のフィールドのうち、２５２個のフィールドが一致している。 (イ)　そして、前記のとおり、原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とで一致する、地点名テーブルの道路情報、緯度経度情報、接続テーブル及び禁止乗換テーブルの情報、県範囲定義テーブルの各情報は、いずれも原告ＣＤＤＢの制作者において、前記認定のとおり、それぞれ選択の幅のある中から一定の選択方針に基づき選定し、あるいは全く任意に番号等設定したものであり、それぞれ創作性を有するものと認められる。 (ウ)　さらに、原告ＣＤＤＢにおいては、前記のとおり、旅行会社に対する実情調査等の結果を踏まえ、主たる目的として、大型観光バスによる団体旅行を主眼とした行程表作成のための便宜から、通常使用されるロードマップとは異なる観点である、貸切観光バスが通行するのに適した道路として、都道府県道については約１０％、市区町村道では約０．００４％程度を選択して「１０道路テーブル」に格納し、道路地点として選択した地点における情報も緯度及び経度のデータとして格納することとし、これを大型観光バスが通過するのに適切と考えられる道路のうちの、行程表を作成する上で必要と考えられる適切な地点である、交差点、インターチェンジ、サービスエリア、パーキングエリア、観光施設、宿泊施設、駅、役所等の代表道路地点とするのに適切な地点を選別し、パソコンのマウスを地図上でクリックする方法で選択して、実際に入力したものである。また、施設と関係する代表道路地点の選択においても、施設が存する場所の緯度経度による地点ではなく、大型観光バスでの出入りの観点から、当該施設の近辺の道路地点を選び、当該施設の代表道路地点として適宜設定している。 　このように、原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）との共通部分である、道路、道路位置、代表道路地点等の選別・選択についても、原告ＣＤＤＢの制作者による創作活動の成果が表れており、創作者の個性が表現されているものといえる。 　したがって、被告ＣＤＤＢ（当初版・２００６年版）と共通する上記原告ＣＤＤＢの部分については、データベースの情報の選択としての創作性を有するものと認めるのが相当である。 (エ)　そして、これら被告ＣＤＤＢ（当初版・２００６年版）が原告ＣＤＤＢと同一性を有する情報の選択に関する部分も、原告ＣＤＤＢの創作的表現の本質的特徴を直接感得することのできる同一性が維持されているものというべきである。 オ　被告らの主張に対する判断 (ア)　被告らは、原告ＣＤＤＢにおける情報の選択は、客観的、標準的な基準に従った没個性的・汎用的なものにすぎず、創作性がないと主張する。 　しかし、前記のとおり、原告ＣＤＤＢにおいて、道路や道路位置、代表道路地点、緯度経度情報、接続・禁止乗換、県範囲定義等を選択、選定するに当たっては、極めて多数にのぼる選択対象として幅のある中から、専ら大型観光バスでの移動を前提とした効率的な経路検索、行程表作成を可能とするという観点からの情報の選別等がされており、その情報の選択には制作者の個性が表れており、創作性があるものということができる。 　したがって、被告らの上記主張は採用することができない。 (イ)　被告らは、被告ＣＤＤＢ（当初版・２００６年版）の施設情報に関する設計思想は、柔軟な検索や旅行計画の作成を利用者（旅行業者）が行うようになることを想定し、将来におけるデータベースとしての拡張性や格納効率、保守性を最大限に高めるという視点から、施設情報に関するデータベースを設計することとしており、具体的には、施設マスタという独立したマスターテーブルを上位テーブルとして用意し、宿泊施設マスタや観光施設マスタといった施設の類型別のマスターテーブルを、施設マスタの下位テーブルとして位置付ける格納方法をとることとし、最大２階層でデータを保持するテーブル構成を採用し、これにより、被告ＣＤＤＢ（当初版・２００６年版）では、電話番号や住所などの施設の基本情報は、「宿泊施設」や「観光施設」といった施設類型の区別なく、一旦全て施設マスタに格納する設計としたことから、テーマに沿って施設を検索する場合に、データベースの構造上は、施設マスタのみを検索することで、テーマに沿った施設を検索することが可能な設計構造となったものである一方、原告ＣＤＤＢにおける施設情報の格納方法は、テーマ別検索を意図していないため、ホテル・旅館テーブルと観光施設テーブルの二つの施設類型別のマスターテーブルでのみ、施設に関する情報を格納しており、この点で体系的構成が異なる旨主張し、それに沿う証拠として、乙１９、２７を提出する。 　しかし、乙１９、２７は、いずれも被告Ｙ１の作成した報告書であるところ、これらはいずれも被告らが用いる「格納方法」の語の意味について、被告ＣＤＤＢ（当初版・２００６年版）におけるテーブルやフィールド、リレーションとの関係でいかなる意味を持つかについては何ら具体的に明らかにするものではなく、被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」、「２９旅館マスタ基本」及び「２３観光マスタ基本」については、原告ＣＤＤＢの「２０ホテル・旅館テーブル」及び「２１観光施設テーブル」と実質的に一致するテーブルであると認められることについては、既に検討したとおりである。 　したがって、被告らの上記主張は採用することができない。 (ウ)　被告らは、被告ＣＤＤＢも原告ＣＤＤＢも、「ＮＡＶＩＴＩＭＥ」やカーナビゲーションシステムなどルート・路線検索を行うシステムではほぼ必ず採用されている方法であるダイクストラ法という一般的でありふれた最短経路検索方法を採用しており、これを実現するために、地点（始点）と地点（終点）並びにその間の距離及び所要時間等を格納していくという具体的な情報の格納方法それ自体において特段顕著な差異が生じ得るものではなく、このような格納方法自体には創作性が認められない旨主張する。 ａ　そこで、まず、ダイクストラ法について検討する。 　ダイクストラ法について、公開特許公報（特開平５−１１３３４０号、発明の名称「車載ナビゲータ」、出願日 平成３年１０月２２日、出願人アルパイン株式会社、甲４５）には、以下の記載がある。 ・「出発地点から目的地点までの最適経路を求める方法として、ダイクストラ法と称せられる方法が提案されている。このダイクストラ法は出発地点と目的地点を結ぶ直線を半径とする領域、あるいは該領域より大きめの領域内に存在する全交差点を考慮して出発地から目的地迄の最短経路を交差点ネットリストＣＲＮＬを参照して探索するものである。図１０はダイクストラ法の概略説明図であり、道路を直線、交差点を直線の交点としてグラフ化したものであり、各交差点間の距離は既知で、ＳＴＰは出発地（交差点）、ＤＳＰは目的地（交差点）である。」（段落【０００７】） ・「ダイクストラ法においては、交差点ネットリストＣＲＮＬを参照しながら、出発地を０次交差点として、該０次交差点に隣接する１次交差点Ａ1 〜Ａ4 を探し、各１次交差点Ａ1 〜Ａ4 に対応させて１つ前の次数の交差点（出発地交差点）及び出発地からの距離を求める。次いで、各１次交差点Ａ1 〜Ａ4 について２次交差点Ｂij を探し、各２次交差点に対応させて１次交差点及び出発地からの距離を求める。」（段落【０００８】） ・「【発明が解決しようとする課題】このようにダイクストラ法によれば、グラフ理論的に最短経路が求まる。」（段落【００１１】） ｂ　上記記載によれば、ダイクストラ法自体は、地点間の最短経路を求める方法として公知のものであると認められるが、原告ＣＤＤＢは選択された出発地や観光施設、宿泊施設、到着地等の間での最短経路を探索することを行っているものとしても、前記認定のとおり、原告ＣＤＤＢの創作性については、原告ＣＤＤＢがダイクストラ法を実現するためのシステムとして創作性を有するとするものではなく、テーブルやフィールド、これらのリレーションの体系的構成について創作性を認めるものであるから、その創作性の有無は、ダイクストラ法を実現するものとしてありふれているか否かと直接関係するものではないというべきである。 　したがって、被告らの上記主張は採用することができない。 (エ)　被告らは、他に同種のデータベースが存在することを前提として、原告ＣＤＤＢはありふれたものであって、著作物とはいえない旨主張し、それに沿う証拠として、乙３５の１ないし６を提出する。 　しかし、株式会社エヌシステムのホームページには、平成８年（１９９６年）４月に、ＪＡ旅行センター向け旅行業営業支援システムである「応援団くん」の展開を開始した旨の記載があるが、そのシステムの内容については何ら記載がなく、その詳細は明らかではない。〔乙３５の１〕 　また、株式会社ＪＭＣ（ジェーエムシー）のホームページには、「国内行程表管理システム『ｅＺＲＯＵＴＥ（イージールート）』」に関する記載があるが、「カーナビで用いられている機能や詳細な電子地図を活用し、パソコン上でかんたん（＝イージー）に行程表を作成することが出来るツールです。作成した行程表はモデルコースとして登録し、社内で共有することができます。画像をクリックするとデモ画像が流れます。」と記載されているにすぎず、「ｅＺＲＯＵＴＥ」は、株式会社ＪＴＢ情報システムの国内行程表作成システムとして採用されているが、これについてもそのシステムの詳細は明らかではない。〔乙３５の２、乙３９、３頁〕 　企業間取引サイトであるＡＮＴＡ−ＮＥＴのホームページには、「社団法人全国旅行業協会（ＡＮＴＡ）が運営する観光商品流通システムで、インターネットを通じて観光関連事業者（旅行業者、宿泊・観光・運輸施設等）の業務拡大を支援するＢｔｏＢ（企業間取引）サイトです。」との記載があるが、その詳細は何ら明らかではない。〔乙３５の３〕 　株式会社ワールドエキスプレスによる「国内／海外旅程表作成＆見積集計旅行業支援システム Ｗｏｒｌｄ　ＴＡＣ」のホームページには、「国内・海外旅程表作成から見積書・請求書・実績集計まで 一連の手配業務を徹底的に合理化！」として、同システムには国内旅程表作成機能がある旨の記載があるが、同システムの具体的な内容については何ら記載されておらず、その詳細は明らかではない。〔乙３５の４〕 　株式会社エイブルズシステムの「Ｍｒ．トラベルくんシリーズ 旅の助」についてのホームページには、「旅行業、観光バス業、観光関連事業者向けの旅行行程表、見積書作成、顧客管理、営業管理が出来る旅行業務支援システムです。」との記載があるが、それ以上のシステムの詳細については何ら明らかではない。〔乙３５の５〕 　株式会社ウィ・キャンの旅行業基幹業務システムとして「シンフォニーアトゥー」を紹介するホームページには、「それぞれの部署の方、またそれぞれの機能が同時進行し、壮大な交響曲・・・を奏でるように旅行業が遂行されるシステムであるという願いを込めています。」等の記載はあるが、具体的なシステムの詳細については不明である。〔乙３５の６〕 　また、被告Ｙ５も、ＪＴＢのシステムである「ｅＺＲＯＵＴＥ」、農協観光のシステム等を使ったことはないとし、これらシステムの具体的な構成や規模等の詳細については明らかにすることができない。〔被告Ｙ５尋問調書２１〜２２頁〕 　以上によれば、原告ＣＤＤＢが同種データベースの存在によりありふれたものであると認めるべき証拠はない。 　したがって、被告らの上記主張は採用することができない。 (オ)　被告らは、自動車道路の経路探索上、当該施設の自動車出入口から最も近い道路地点（代表道路地点）を定めておくことは必要不可欠であり、これは自動車ルートの検索システムである「ＮＡＶＩＴＩＭＥ」や、一般的なカーナビゲーションシステム等でも同様であるから、原告ＣＤＤＢに特徴的な部分とはいえないとして創作性がない旨主張し、それに沿う証拠として、乙２９を提出する。 　そこで、乙２９について検討すると、まず、乙２９の別紙１は「ＮＡＶＩＴＩＭＥ」の自動車ルート検索、同別紙２は「Ｍａｐ　Ｆａｎ　Ｗｅｂ」のルート検索、同別紙３は「カーナビゲーション（パナソニック ストラーダＣＮ−ＤＶ２５０Ｄ）」のルート検索画面である。乙２９別紙１の各地図上に示された目的地点である「Ｇ」は、いずれも施設（東京ディズニーランド）内の目的地点であって、道路上の道路地点ではないし、代表道路地点でもない。すなわち、乙２９別紙１の２枚目（上の地図）、３枚目（上下の各地図）及び４枚目（上下の各地図）の各地図の「Ｇ」は、いずれも目的地内の地点であり、道路上の地点とはいえない。これによれば、同システムでは、目的地となる施設内の地点（上記では、東京ディズニーランドの駐車場内に入り込んだ地点「Ｇ」）に直近となる道路地点を求め、その道路地点を前提に経路検索を行っているものと認められるから、目的地となる施設自体の緯度経度情報に基づき直近の道路地点を求めているものといえる。 　また、乙２９別紙２の「Ｍａｐ　Ｆａｎ　Ｗｅｂ」の事例についても、３枚目の上の地図の「５」近くのルート到着地点は東京ディズニーランドの駐車場内の地点、同５枚目の地図の「Ｇ」は遊園地内の地点で、いずれも施設内の地点であって、道路上の地点ではない。これら施設内に設定された目的地点に対して、道路について経路検索を行う場合は、これらの地点（施設内の位置情報）に直近の道路地点を前提に経路検索が行われているものといえる。同システムにおいても、上記「ＮＡＶＩＴＩＭＥ」のシステムの場合と同様に、施設情報のテーブルに代表道路地点を固定的に保有しているものではないということができる。 　さらに、乙２９別紙３の「カーナビゲーションシステム（パナソニックストラーダ）」についても、上記「ＮＡＶＩＴＩＭＥ」や「Ｍａｐ　Ｆａｎ　Ｗｅｂ」の各システムの場合と同様に、地図上に施設自体の位置を示すときの緯度経度情報と、経路検索時の目的地点の緯度経度情報が複数存在することを示すものであり、これらはいずれも道路上の緯度経度情報ではないから、施設情報として代表道路地点の情報を持つものを示しているとはいえない。 　そうすると、これらはいずれも、原告ＣＤＤＢのように、施設関係のテーブルに、予め代表道路地点を設けておくことを示すものではなく、施設情報として検索方法に応じて施設内に目的地点を複数持つものにすぎないというほかない。 　したがって、被告らの上記主張は採用することができない。 (カ)　被告らは、ダイクストラ法を前提として、選択不可とすべき接続経路情報の設定を行うことは、旅行業者向けデータベースとしてありふれたものであると主張し、それに沿う証拠として乙３０を提出する。 　しかし、乙３０の別紙１の１枚目には「◆リンクの使用可否情報を考慮可能−動的考慮」として「『・・・工事中により一時的に通行止めにしたい』などがあります。・・・動的にリンクの使用不可を設定することで実現可能です。」と記載されており、事前に選択不可のリンク（経路）をテーブルとして保有するものでないことは明らかである。 　また、乙３０の別紙１の２枚目では「◆道路の一方通行などの進行方向制約を考慮可能」として、「一方通行でない道路」については双方向のリンク（経路）を作成し、「一方通行の道路」については走行可能な方向のリンク（経路）のみを作成すると記載されており、選択可能なリンク（経路）のみを作成している例であることが明らかで、選択不可の接続道路情報テーブルを設けることを示しているものとはいえない。 　さらに、乙３０の別紙２の特許公報（特許第２６４１４７０号、発明の名称「ナビゲーション装置」、特許権者 アイシン・エィ・ダブリュ株式会社外１名）には、以下の記載がある。 ・「そのために本発明は、出発地から目的地までの経路を探索して探索されたコースに基づき案内を行うナビゲーション装置において、始点から終点で表される道路単位で経路探索を行うための道路に関する情報からなる道路データを格納した記憶手段と、前記記憶手段に格納された道路データを用いて最適経路を探索する経路探索手段とを備え、前記道路データは、該道路データに接続する道路の進入禁止情報を有し、前記経路探索手段は、前記進入禁止情報により進入禁止である道路を除外して経路探索を行うことを特徴とするものである。 〔作用及び発明の効果〕 　本発明のナビゲーション装置では、道路データに右左折禁止情報を設定するので、右左折禁止情報の記憶領域は少なくてよい。また、経路探索手段が経路を探索する際には右左折禁止情報の設定された道路を探索コースから除外するので、無駄な探索処理がなくなり、処理の高速化を図ることができる。 〔実施例〕 　以下、図面を参照しつつ実施例を説明する。 　・・・道路のネットワークデータは、道路のネットワークが例えば第２図（ａ）に示すような交差点番号・・・、道路番号・・・からなるものとした場合、交差点データについては同図（ｂ）、道路データについては同図（ｃ）、ノードデータについては同図（ｄ）に示すようなデータ構成となっている。 　すなわち、交差点データは、同図（ｂ）に示すように交差点番号・・・に対応して交差点名、当該交差点が始点となっている道路のうち一番番号の小さい道路番号、当該交差点が始点となっている道路のうち一番番号の小さい道路番号、信号の有無からなる。 　また、道路データは、同図（ｃ）に示すように道路番号・・・に対応して交差点番号による始点、終点、同じ始点を持つ道路のうち番号が次のもの、同じ終点を持つ道路のうち番号が次のもの、道路の太さ、禁止情報、案内不要情報、写真番号、ノード数、ノード列データの先頭アドレス、長さ等からなる。 　そして、ノードデータは、同図（ｄ）に示すように東経、北緯、属性等からなり、道路データから明らかなように道路番号の単位は複数個のノードからなる。すなわち、ノードデータは道路上の１地点に関するデータであり、ノード間を接続するものをアークと呼ぶと、複数のノード列のそれぞれの間をアークで接続することによって道路が表現される。例えば道路番号に関して見ると、道路データよりノード数15 からなりノードデータの先頭アドレスが100 であることから、道路番号は、100 から114 までのアドレスのノードデータで構成されることになる。 　これらのネットワークデータによると、・・・このように特に道路データでは、右左折禁止等の進入禁止の道路番号と案内不要の道路番号をもっていることにより、情報記憶の容量を少なくし、また経路探索を容易に行えるようにしている。」（２頁３欄３１行〜３頁５欄１９行） 　上記記載は、隣接する道路地点間の道路間の道路を一単位とした道路に関するデータである道路データを格納するテーブルである、原告ＣＤＤＢであれば「１１接続テーブル」、被告ＣＤＤＢ（当初版・２００６年版）であれば「３７接続マスタ」（なお、被告ＣＤＤＢ（現行版）、被告ＣＤＤＢ（新版）の「３７単経路マスタ」についても同様である。）のテーブル自体に右左折禁止の情報を格納する例を示すものであり、禁止されている道路間の接続情報のテーブルを別途設けるものが示されているわけではない。 　したがって、被告らの上記主張は採用することができない。 (キ)　被告らは、路線の特定に交通会社の特定も重要であるから交通会社の情報を格納するのは当然のことであると主張する。 　しかし、交通会社を条件設定して検索する例については、証拠上見当たらず（甲５０）、経路検索において必要となる情報につき交通会社テーブルを設けることが当然のことであるということはできない。 　したがって、被告らの上記主張は採用することができない。 カ　依拠性について 　次に、被告ＣＤＤＢ（当初版・２００６年版）が原告ＣＤＤＢに依拠して制作されたものであるかにつき判断する。 (ア)　依拠性に関連する事実 　被告らは、被告ＣＤＤＢ（当初版・２００６年版）につき、前記記載の複数のテーブルについて、データを原告ＣＤＤＢからコピーして利用した事実を認めているところ、その他にも、以下の事実が存する。 a　テーブル、フィールドの各ＩＤについて 　原告ＣＤＤＢと、被告ＣＤＤＢ（当初版・２００６年版）との対応するテーブルとフィールドについて、テーブルＩＤ、フィールドＩＤの一致する例については既に検討したとおりであるが、完全に一致するものでなくても、被告ＣＤＤＢ（当初版・２００６年版）では、テーブルＩＤの頭３文字を「ＡＺＭ」にするなどし、それら以外はテーブルＩＤ、フィールドＩＤが完全に一致している例が多数みられる。その詳細は、別紙３のとおりであり、これらのうち、原告ＣＤＤＢと一致するテーブルＩＤ、フィールドＩＤについては、原告ＣＤＤＢのデータをコピーしたことによるものと認められる。〔甲９、２３、５５〕 　この点に関してＡは、その証言において、原告ＣＤＤＢと被告ＣＤＤＢとのフィールドＩＤ、テーブルＩＤの一致につき、フィールドＩＤの一致については認めるものの、テーブルＩＤについては「ＴＲＶ」と「ＡＺＭ」の部分のみが異なるものがあるが、その余はすべて一致する理由について、１０年近くプログラム作業に従事していたことから、全て頭の中に入っており、開発効率を上げるために命名したとし（証人Ａ１３頁）、その一方で、Ａは、原告システムのプログラムの入力には一切関与しておらず、全て旧原告会社（翼システム）の方針に従って入力を指示しただけであるとも証言するが（証人Ａ６頁）、これらの証言部分は、Ａが原告システムの開発経過において、プログラマーとして参加して被告Ｙ５の下でサブリーダーとなり、その後被告Ｙ５の転出後に原告システムの開発、改良における責任者となったとの事実経過に反する上に、内容的にも不合理であり、信用することができない。 b　緯度経度情報について 　原告ＣＤＤＢでは、バージョンアップ時に、新バージョンであるVer5に移行しない顧客のために、「０１市区町村テーブル」、「０９地点名テーブル」、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「３２駅テーブル」と、緯度経度テーブルとで緯度経度情報を重複保有していることについては既に検討したとおりであるところ、被告ＣＤＤＢ（当初版・２００６年版）は、本来必要のない緯度経度情報を複数テーブルで重複保有している。 　なお、被告らは、これにつき、被告ＣＤＤＢ（新版）から緯度経度マスタ自体を削除している。 c　ＵＲＬアドレステーブルについて 　原告ＣＤＤＢではタイトルに用いるカタカナについて全角（例として、「青森県［観光コンベンション協会ＨＰ］」と半角（例として、その次の優先順位となっている、「青森県［観光情報ﾈｯﾄﾜｰｸＨＰ］」）が不規則に混用されている例が見られるところ、被告ＣＤＤＢ（当初版・２００６年版）の全角半角の混用使用箇所が、原告ＣＤＤＢと完全に一致する例がある。〔甲２８の別紙４〕 d　地点名テーブルについて (a)　原告ＣＤＤＢの誤りである地点名の表記「阿武隅ＰＡ」（正しくは「阿武隈」）と同じ誤りが、被告ＣＤＤＢ（当初版・２００６年版）に存在する。ちなみに、別紙４の被告ＣＤＤＢ（当初版・２００６年版）の「３５地点マスタ」の被告らの主張欄記載のとおり、被告らは、原告ＣＤＤＢをコピーして入力した上で追加・修正・削除した旨主張するところであるが、ＮＥＸＣＯ東日本のホームページには正しい表記がされている。〔甲２１〕 　原告は、平成１９年８月にその誤りに気付き、その時点で修正をしているが、被告ＣＤＤＢでは、現行版のVer2.6（２００７年１２月５日０１版）においても、この誤りがそのまま引き継がれており、その後に、被告らは修正している。 (b)　原告ＣＤＤＢと同じ誤りが被告ＣＤＤＢ（当初版・２００６年版）に存在する。例えば、京都市右京区渡月橋の読みについて「キョウトシウキョウクトゲツバシ」となっているところ、正しくは「キョウトシウキョウクトゲツキョウ」である。 　被告らは、原告からの指摘を受け、その後修正した。〔甲６５〕 (c)　原告ＣＤＤＢと同じ誤りが被告ＣＤＤＢ（当初版・２００６年版）に存在する。例えば、北九州市小倉北区清水の読みが「キタキュウシュウシコクラキタクシミズ」となっているところ、正しくは「キタキュウシュウシコクラキタクキヨミズ」である。 　被告らは、原告からの指摘を受けて、その後修正した。 (d)　原告ＣＤＤＢと同じ誤りが被告ＣＤＤＢ（当初版・２００６年版）に存在する。福岡市中央区警固の読みが「フクオカシチュウオウクケイコ」となっているところ、正しくは「フクオカシチュウオウクケゴ」である。 　被告らは、原告からの指摘を受け、その後修正した。 e　道路テーブルについて (a)　原告ＣＤＤＢと同じ誤りが、被告ＣＤＤＢ（当初版・２００６年版）に多数存在する。例えば、道路番号原告ＣＤＤＢ４６２（ＡＺ６３４）道路名「金精道路」の読みの誤りの一致の例がある。これについて、「キンセイドウロ」は誤りであり、正しくは「コンセイドウロ」であるが、この誤りが一致している。 　なお、この誤りは、被告ＣＤＤＢ（現行版）にも引き継がれている。 　その後、被告らは、被告ＣＤＤＢ（新版）において、道路名の読み仮名である「道路カナ」のフィールド自体を削除している。〔甲６５の別紙４〕 　また、原告ＣＤＤＢでは、茨城県の読み仮名を、「イバラキケン」（正）と「イバラギケン」（誤）を混在して登録している。 　この正誤の混在状況が、被告ＣＤＤＢ（当初版・２００６年版）においても、一致して存在している。〔甲６５の別紙５〕 (b)　原告ＣＤＤＢに格納されたダミーデータ「＊＊＊」（道路名）、「ンダミー」（道路名の読み）が被告ＣＤＤＢ（当初版・２００６年版）においても一致している。 　被告らは、原告からの指摘を受け、被告ＣＤＤＢ（新版）においてはこれらを削除している。〔甲２１〕 f　首都高速料金テーブルについて 　以下の例のとおり、原告ＣＤＤＢと同じ誤りが被告ＣＤＤＢ（当初版・２００６年版）に存在する。 　芦ノ湖スカイラインの大型車の通行料金が「２、２００円」のところを、中型車の「１、４００円」という誤ったデータを登録している。 　阿蘇町営有料道路の中型車の通行料金が「１、５８０円」のところを、普通車の「５６０円」という誤ったデータを登録している。 　久住高原ロードパークの大型車の通行料金が「２、０００円」のところを、中型車の「１、２５０円」という誤ったデータを登録している。 　なみはや大橋（尻無川新橋有料道）の中型車の通行料金が「１００円」のところを、大型車の「１５０円」という誤ったデータを登録している。 　また、原告ＣＤＤＢでは、蔵王ハイラインの大型車の通行料金が「２、１００円」のところを、「１、３００円」という誤った料金データで格納していたところ、これと同じ誤りが被告ＣＤＤＢ（当初版・２００６年版）に存在した。〔甲６５の別紙７〕 g　ホテル・旅館テーブルについて (a)　宿泊施設の読み仮名に関して、原告ＣＤＤＢと同じ誤りが被告ＣＤＤＢ（当初版・２００６年版）に存在する。原告ＣＤＤＢでは宿泊施設名の読み仮名について長音符「ー」とすべきを誤って数字記号マイナス「−」で登録した場合があるところ、これらと同じ誤りが被告ＣＤＤＢ（当初版・２００６年版）に存在する。 　以下は、読み仮名に長音符「ー」とマイナス記号「−」が混用されている一例であるところ、同様の事例が多数存在する。〔甲６５〕 　原告ＣＤＤＢ 　施設名：リゾートホテルローゼンハイム白馬 　施設カナ：リゾートホテルロ−ゼンハイムハクバ 　被告ＣＤＤＢ（当初版・２００６年版） 　施設名：リゾートホテルローゼンハイム白馬 　施設カナ：リゾートホテルロ−ゼンハイムハクバ (b)　宿泊施設名の読み仮名に関する原告ＣＤＤＢと同じ誤り（施設カナ）が被告ＣＤＤＢ（当初版・２００６年版）に存在する。以下のとおりであり、「カナざワ」となっているほか、「新潟」、「大垣」がそのまま漢字で表記されている誤りがある。 ・施設名：金沢みなとホテル 　施設カナ：カナざワミナトホテル ・施設名：スターホテル新潟 　施設カナ：スターホテル新潟 ・施設名：チサングランド大垣 　施設カナ：チサングランド大垣 h　観光施設テーブルについて (a)　観光施設名の読み仮名に関して、原告ＣＤＤＢと同じ誤りが被告ＣＤＤＢ（当初版・２００６年版）に存在する。 　原告ＣＤＤＢは宿泊施設名称の読み仮名を表記するフィールドを有しており、宿泊施設名に「英字」「数字」を含む場合、「英字」「数字」について、きちんとした読み仮名である、例えば１をワンないしイチとするなどの方法で表記されているものと、読み仮名に英字や数字がそのまま残っているものとが混用されている。この原告ＣＤＤＢの混用状態は、理由はともかくとしても、原告独自のデータの登録状態であるということができる。 　これにつき、被告ＣＤＤＢ（当初版・２００６年版）にも、原告ＣＤＤＢと同一の混用状態のものが相当数存在する。例えば、原告ＣＤＤＢの施設名称「美利河Ｉ遺跡」（「Ｉ」は英字のアイ）は誤りであり、「美利河�T遺跡」（「�T」はギリシャ数字の１）とするのが正しいところ、被告ＣＤＤＢ（当初版・２００６年版）では、被告ＣＤＤＢ（現行版）に至るまで、原告ＣＤＤＢと一致する誤り（英字の「Ｉ」）の登録をしている。〔甲６５〕 (b)　観光施設の読み仮名に関して、原告ＣＤＤＢと同じ誤りが、被告ＣＤＤＢ（当初版・２００６年版）に存在する。すなわち、原告ＣＤＤＢでは観光施設名の読み仮名について長音符「ー」とすべきところを、誤って数字記号マイナス「−」で登録した場合が相当に存するところ、これと同じ誤りが被告ＣＤＤＢ（当初版・２００６年版）に存在する。下記は読み仮名に長音符「ー」とマイナス記号「−」が混用されている一例であるが、同様の事例が相当数存在する。〔甲６５〕 ・原告ＣＤＤＢ 　施設カナ：アカンネイチャーセンタ− ・被告ＣＤＤＢ（当初版・２００６年版） 　施設カナ：アカンネイチャーセンタ− (c)　株式会社、有限会社の施設名やその読み仮名に関する原告ＣＤＤＢの不統一の表記や誤りと、同じ不統一の表記や誤りが、被告ＣＤＤＢ（当初版・２００６年版）にも存在する。 　原告ＣＤＤＢは、株式会社や有限会社といった法人の種別について、施設名とそのカナについて、不統一な表記を行っている。 　原告ＣＤＤＢの以下の八つのパターンのデータと同じデータが、被告ＣＤＤＢ（当初版・２００６年版）に多数存在する。〔甲６５の別紙１８〕 ・施設名を株式会社とし、カナをサブシキカイシャと誤って表記する ・施設名を（株）とし、カナをカブと表記する ・施設名を（株）や（有）とし、カナを（カブ）、（ユウ）と表記する ・施設名を（株）や（有）とし、カナを（カ）、（ユ）と表記する ・施設名を（株）とし、カナをカブシキガイシャと表記する ・施設名を株式会社とし、カナをカブシキガイシャやカブシキカイシャと表記する ・施設名を（株）や株式会社とし、カナではそれらを表記しない ・例外的にカナを「カブシキカイシャ」（通常は「カブシキガイシャ」）と表記する (d)　観光施設名の読み仮名表記に原告ＣＤＤＢと同じ誤り（「ひらがなが混じる」、「漢字が混じる」、「英字が混じり読みも誤る」、「記号「＾」が混じり読みも誤る」など）が被告ＣＤＤＢ（当初版・２００６年版）に多数存在する。 　以下はその例であるが、その他にも事例がある。〔甲６５の別紙１９〕 ・施設名：光大寺の湯 　施設カナ：コウダイジのユ ・施設名：霞間ヶ渓スポーツ公園 　施設カナ：カマガタニスポ−ツ公園 ・施設名：航空博物館 　施設カナ：コウクウガクブツアｋン ・施設名：スパガーデンコートピア 　施設カナ：スパガ−デンコ＾−トピア (e)　原告ＣＤＤＢでは、施設について旧名称と現行名称と重複して登録する例があるが、被告ＣＤＤＢ（当初版・２００６年版）でも同一の重複登録がある。 　以下の例は、被告ＣＤＤＢ（当初版・２００６年版）のデータベース開発時期（２００５（平成１７）年１０月以降）からすると格納されるはずのない古い施設名称が重複して登録されている。 　下記の「大分阿蘇レーシングパーク」は、１９９３年から１９９５年のみ使用され、その後、名称を「オートポリス」に変更した。 　このような例につき、原告ＣＤＤＢと同じ重複登録があり、被告ＣＤＤＢ（当初版・２００６年版）の開発時より１０年前の旧施設名称が登録されている。 　原告ＣＤＤＢ 　�@施設Ｎｏ．５０４４７、施設名：大分阿蘇レーシングパーク 　�A施設Ｎｏ．７５３２７、施設名：オートポリス 　被告ＣＤＤＢ（当初版・２００６年版） 　�@施設Ｎｏ．１４２０４１、施設名：大分阿蘇レーシングパーク 　�A施設Ｎｏ．１４２０５５、施設名：オートポリス 　�@は、被告ＣＤＤＢ（新版）では「オートポリス」に改変されている。また、�Aは、被告ＣＤＤＢ（新版）では削除されている。 (f)　原告ＣＤＤＢにおいて、２００５年当時登録されていた下記平成１７年（２００５年）のイベントのデータが、被告ＣＤＤＢ（当初版・２００６年版）、被告ＣＤＤＢ（現行版）においても、一致して存在している。 　被告ＣＤＤＢ（当初版・２００６年版）のデータベース開発時期（平成１７年（２００５年）１０月以降）及び販売時期（平成１８年（２００６年）６月）からすると、これらデータは格納されるはずのないものである。 　イベント：アイランド花どんたく［★開催期間：２００５年９月９日〜１１月２０日］ i　協定施設テーブル、券種テーブル、協定旅館テーブル、連結協定テーブルについて 　原告ＣＤＤＢにおいては、別紙１の前記各テーブルについての原告ＣＤＤＢの各テーブルの概要欄記載のとおり、主に大手旅行会社など個別の顧客向けに用意していたテーブルである、協定施設テーブル、券種テーブル、協定旅館テーブル、連結協定テーブルについて、同じテーブルＩＤ（ただし、頭文字３文字を除く）で被告ＣＤＤＢ（当初版・２００６年版）に存在する。しかも、この被告ＣＤＤＢのテーブルには、別紙４のとおり、データは全く格納されておらず、不要なテーブルであるということができる。被告ＣＤＤＢ（現行版）以降は、それらのテーブル自体が削除されている。 j　駅テーブルについて 　駅名の読み仮名に関して、原告ＣＤＤＢと同じ誤りが被告ＣＤＤＢ（当初版・２００６年版）に存在する。なお、被告らは、駅番号を被告ＣＤＤＢ（現行版）より再度振り直した。 ・施設名：別府［◆市営地下鉄］ 　施設カナ：ベップ（正しくは「ベフ」） 　被告ＣＤＤＢ（現行版）の一部（２０１１年２・３月版Ver3.1 まで）、被告ＣＤＤＢ（新版）からは、上記につき、「ベフ」に改変した。〔甲６５の別紙２５〕 K　会社テーブルについて 　被告ＣＤＤＢ（当初版・２００６年版）では、交通機関の会社を検索条件としておらず、その存在の必要性が認められないところ、被告ＣＤＤＢ（当初版・２００６年版）には「４２会社マスタ」を設けており、しかも別紙４のとおり、そのテーブル（ＡＺＭＪＫＦ）にはデータが全く入っておらず、不要なテーブルであるにもかかわらず、原告ＣＤＤＢと同じテーブルが設けられている。 l　地方別会社索引テーブルについて 　同テーブルは、被告ＣＤＤＢ（当初版・２００６年版）においては「駅すぱあと」との連動により必要ないテーブルであるところ、原告ＣＤＤＢと同じテーブルが存在する。そのテーブル（ＡＺＭＪＫＪ）には、別紙４のとおり、データが全く入っておらず、不要なテーブルである。 m　メッセージテーブルについて 　被告ＣＤＤＢ（当初版・２００６年版）の「メッセージマスタ」テーブル（テーブルＩＤ；ＡＺＭＭＳＧ）は、マスターテーブルであるが、他のテーブルとリレーションを持たず、原告システムが原告ＣＤＤＢを介さず直接参照するテーブルであり、原告ＣＤＤＢを構成していないとして、別紙１ないし３のマスターテーブルとしては記載がされていないものである。〔甲６別紙Ａ−１３−２、甲１３、２７〕 　被告ＣＤＤＢ（当初版・２００６年版）のテーブルには、原告ＣＤＤＢのメッセージデータと全く同一の内容のデータが格納されており、ＭＳＧコード、ＭＳＧ内容の各フィールドに格納されているデータは一致している。 　メッセージ内容を具体的にどのような文章にするのか、また各メッセージに何番のコードを付与するかについては、選択の幅があるということができるところ、被告ＣＤＤＢ（当初版・２００６年版）はこれと同じ文章を格納し、同じコード（番号）を付与している。被告ＣＤＤＢ（当初版・２００６年版）のＡＺＭＭＳＧテーブルに格納されているメッセージについては、原告ＣＤＤＢのＴＲＶＭＳＧテーブルのメッセージと完全に同一のものが９７．５％の割合となっている。〔甲２８の別紙１２〕 n　メッセージボックステーブルについて (a)　被告ＣＤＤＢ（当初版・２００６年版）の「メッセージボックスマスタ」テーブル（テーブルＩＤ；ＡＺＭＭＳＧＢＸ）もマスターテーブルであるが、他のテーブルとリレーションを持たず、原告システムが原告ＣＤＤＢを介さず直接参照するテーブルであり、原告ＣＤＤＢを構成していないとして、別紙１ないし３のマスターテーブルとしては記載がされていないものである。〔甲１３、２７〕 　被告ＣＤＤＢ（当初版・２００６年版）の上記テーブルには、原告ＣＤＤＢと同一のデータが格納されている。すなわち、被告ＣＤＤＢ（当初版・２００６年版）の「メッセージボックスマスタ」テーブルに格納されているメッセージは、原告ＣＤＤＢの「メッセージボックス（テーブルＩＤ；ＴＲＶＭＳＧＢＸ）」テーブルのメッセージと完全に同一のものが５１．９％、一部一致のものを含めると８２．８％の割合で存在している。〔甲２８の別紙１３〕 (b)　被告ＣＤＤＢ（当初版・２００６年版）について、被告らは、被告ＣＤＤＢの２００６年版では「方面」という概念を前提にしないで独自に開発したと主張し、実際、被告ＣＤＤＢでは方面検索機能は存しないところ、被告ＣＤＤＢの２００６年版の「メッセージボックスマスタ（テーブルＩＤ；ＡＺＭＭＳＧ）」テーブルには「方面を入力して下さい。」とのメッセージが、また、同じく被告ＣＤＤＢの２００６年版の「メッセージボックスマスタ（テーブルＩＤ；ＡＺＭＭＳＧＢＸ」テーブルには、「入力エラー：方面」、「入力エラー：方面名」とのエラーメッセージが格納されている。 　これらは、被告ＣＤＤＢを独自に開発したとの被告らの主張を前提とすれば、不要なメッセージということができる。 o　ランドマークテーブル、ランドマーク種別テーブルについて 　ランドマークテーブル、ランドマーク種別テーブルも、マスターテーブルであり、原告システムの開発途上で作成されていたが、結局利用の予定がないことから未完成のまま残っており、原告システムにおいて参照されることがなく、原告ＣＤＤＢを構成していないとして、別紙１ないし３のマスターテーブルとしては記載がされていないものである。被告ＣＤＤＢ（当初版・２００６年版）においても別紙４のとおりデータは全く格納されておらず、不要であるにもかかわらず、これらのテーブルが存在する。 　その後、被告ＣＤＤＢ（現行版）、被告ＣＤＤＢ（新版）ではこれらのテーブル自体が削除されている。 (イ)　上記(ア)の事実によれば、被告ＣＤＤＢ（当初版・２００６年版）が、原告ＣＤＤＢに依拠して作成されたことは明らかであるということができる。 　なお、この点に関して被告らは、被告ＣＤＤＢ（当初版・２００６年版）のフィールドＩＤと、原告ＣＤＤＢのフィールドＩＤとの間に一致している部分があることは認めるが、例えば、被告ＣＤＤＢ（当初版・２００６年版）の市区町村マスタにおける都道府県コードのフィールドＩＤ「ＣＩＰＲＣＤ」は、 ・「ＣＩＴＹ」を省略した「ＣＩ」を先頭２文字（全フィールド同様） ・「ＰＲ」は、県を意味する（Ｐｒｅｆｅｃｔｕｒｅ）を省略したもの ・「ＣＤ」は、コード（Ｃｏｄｅ）を省略したもの との命名ルールに則って付けられており、このようなフィールドＩＤは、様々なシステムで用いられている一般的な命名規則であり、原告ＣＤＤＢだけに使用される特殊な命名ルールではなく、被告アゼスタは、被告ＣＤＤＢについても同様の命名ルールでフィールドＩＤを定義したにすぎない旨主張する。 　しかし、上記が一般的な命名規則であることについて、これを裏付ける的確な証拠はなく、被告らは、上記以外のフィールドＩＤが一致するものについて何ら説明をしていないばかりか、その余の多数の一致するフィールドについても、一般的な命名規則から説明が付くものがほとんどであると認めるに足りない。 　したがって、被告らの上記主張は採用することができない。 キ　被告ＣＤＤＢ（当初版・２００６年版）についての結論 　以上の検討によれば、被告ＣＤＤＢ（当初版・２００６年版）は、原告ＣＤＤＢに依拠して制作された複製物であると認めるのが相当である。 (4)　次に、被告ＣＤＤＢ（現行版）につき検討する。 ア　被告ＣＤＤＢ（現行版）と原告ＣＤＤＢとの体系的構成の共通性 (ア)　テーブルの種類及び数 ａ　一致するマスターテーブル (a)　原告ＣＤＤＢには４２個の、被告ＣＤＤＢ（現行版）には２６個のマスターテーブルがそれぞれ含まれるところ、このうち、以下の１０個のマスターテーブルについては、原告ＣＤＤＢに含まれるマスターテーブルと一致することにつき争いがない。 　一致することに争いのない１０個のマスターテーブルは、以下のとおりである（原告ＣＤＤＢのマスターテーブルによる表記。対応する被告ＣＤＤＢ（現行版）の表記は別紙２該当欄記載のとおり）。 ・「０１市区町村テーブル」 ・「０５緯度経度テーブル」 ・「０６ＵＲＬアドレステーブル」 ・「０７ＵＲＬ種別テーブル」 ・「０８ＵＲＬ分類テーブル」 ・「０９地点名テーブル」 ・「１０道路テーブル」 ・「３２駅テーブル」 ・「４２会社テーブル」 ・「４３交通機関種別テーブル」 (b)　そして、原告は、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」及び「２２観光施設備考テーブル」についても、これら三つのテーブルに対応する、被告ＣＤＤＢ（現行版）の「２１施設マスタ」、「２９宿泊施設マスタ」、「２３観光施設マスタ」、「２６観光料金マスタ」及び「２５観光料金種別マスタ」は、一致するマスターテーブルである旨主張し、さらに、「０２地区・県名テーブル」は「３都道府県マスタ」と、「１１接続テーブル」は「３７単経路マスタ」と、「１２禁止乗換テーブル」は「３７禁止経路マスタ」と、「１４区間料金テーブル」は「３９区間料金マスタ」と、「１５首都高速料金テーブル」は「４０通行料金マスタ」と、「３３路線構成テーブル」は「４６路線構成マスタ」と、「３４路線テーブル」は「４３路線マスタ」と、「３６路線検索テーブル」は「４５時刻マスタ」と、「３９便テーブル」及び「４０運行日定義テーブル」は「４４便マスタ」と、それぞれ対応して被告ＣＤＤＢ（現行版）に存在する旨主張する。 　まず、被告ＣＤＤＢ（現行版）の「３都道府県マスタ」と原告ＣＤＤＢ「０２地区・県名テーブル」とは、いずれもプライマリー・キーが設定された「都道府県コード」、及び「都道府県名」フィールドから構成されていること、被告ＣＤＤＢ（現行版）のフィールドには「表示順」のフィールドが存するものの、これは検索結果における表示順を定めるものであるところ、これは、都道府県コードに基づき表示順を決定するにすぎないものと認められ、その余の被告ＣＤＤＢ（現行版）のフィールドも、「作成日時」、「更新日時」、「削除区分」、「都道府県名英字」等のフィールドであることから、被告ＣＤＤＢ（現行版）の「３都道府県マスタ」と原告ＣＤＤＢ「０２地区・県名テーブル」とは同じ目的で使用されるものであり、実質的に一致するものと認められる。 　次に、被告ＣＤＤＢ（現行版）の「３７単経路マスタ」、「３８禁止経路マスタ」、「３９区間料金マスタ」及び「４０通行料金マスタ」と原告ＣＤＤＢの「１１接続テーブル」、「１２禁止乗換テーブル」、「１４区間料金テーブル」及び「１５首都高速料金テーブル」とは、別紙３のとおりの各テーブルにおけるフィールドの存在、別紙６のとおりの原告ＣＤＤＢのリレーション、別紙９のとおり認められる（争いがあるリレーションについての判断は後記のとおりである。）被告ＣＤＤＢ（現行版）のリレーションのとり方を参照すると、どちらも地点コード（地点番号）により特定される道路の始点・終点と禁止ルートを特定し、有料道路の場合に料金を検索するためのものと認められる。フィールドの内容を詳細にみると若干相違する点はあるものの、検索の目的の観点からすると、それらのリレーションに特徴があるものとは認められず、両者は同じ目的で使用されるものであり、実質的に一致するものと認められる。なお、この点についての判断の詳細は、下記オ（被告らの主張に対する判断）のとおりである。 　被告ＣＤＤＢ（現行版）の「２１施設マスタ」、「２９宿泊施設マスタ」、「２３観光施設マスタ」、「２６観光料金マスタ」については、被告ＣＤＤＢ（当初版・２００６年版）と比較して、別紙３のとおり、フラグフィールド等の削除や、「２１施設マスタ」に「キーワード」、「公共施設種別」等のフィールドを加えるなど、フィールドに若干の変更はあるものの、被告ＣＤＤＢ（当初版・２００６年版）の主要なフィールドには変更がなく、全体的に重要な変更がされているものとはいえないから、被告ＣＤＤＢ（当初版・２００６年版）と同様、被告ＣＤＤＢ（現行版）の「２１施設マスタ」、「２９宿泊施設マスタ」、「２３観光施設マスタ」、「２６観光料金マスタ」についても、原告ＣＤＤＢの対応するテーブルと実質一致するものと認められる。なお、被告ＣＤＤＢ（現行版）の「２５観光料金種別マスタ」は原告ＣＤＤＢに対応するテーブルがないことは前記と同様である。 　被告ＣＤＤＢ（現行版）の「４６路線構成マスタ」、「４３路線マスタ」、「４５時刻マスタ」及び「４４便マスタ」と原告ＣＤＤＢの「３３路線構成テーブル」、「３４路線テーブル」、「３６路線検索テーブル」、「３９便テーブル」及び「４０運行日定義テーブル」とは、別紙３のとおりの各テーブルにおけるフィールドの存在、別紙６のとおりの原告ＣＤＤＢのリレーション、別紙９のとおり認められる被告ＣＤＤＢ（現行版）のリレーションのとり方を参照すると、これらは、道路を移動するものを除く鉄道等の公共輸送サービスを利用した場合の経路探索及び料金の検索をするためのものであるところ、原告ＣＤＤＢの「３３路線構成テーブル」、「３４路線テーブル」、「３９便テーブル」及び「４０運行日定義テーブル」に存在する「路線番号」フィールドにいずれもプライマリー・キーが設定されているところ、被告ＣＤＤＢ（現行版）の「４６路線構成マスタ」、「４３路線マスタ」及び「４４便マスタ」の「路線コード」フィールドにも、いずれもプライマリー・キーが設定されており、その他各テーブルに存するフィールドについても、「備考」や「作成日時」等のフィールドを除くとほとんど共通するものであること、検索の目的の観点でみると、リレーションに特徴があるものともみられないことから、被告ＣＤＤＢ（現行版）の「４６路線構成マスタ」、「４３路線マスタ」、「４５時刻マスタ」及び「４４便マスタ」と、原告ＣＤＤＢの「３３路線構成テーブル」、「３４路線テーブル」、「３６路線検索テーブル」、「３９便テーブル」及び「４０運行日定義テーブル」とは、同じ目的で使用されるものと認められ、一致するものと認められる。なお、被告ＣＤＤＢ「４４便マスタ」は、別紙３のとおりの各フィールドの内容の共通性からみて、原告ＣＤＤＢの「３９便テーブル」、「４０運行日定義テーブル」及び「４１時刻テーブル」を実質的には正規化した関係にすぎないものであるから、これも一致するものと認められる。 (c)　上記によれば、原告ＣＤＤＢと被告ＣＤＤＢ（現行版）とで一致するマスターテーブルは、上記２３個であると認められる。 ｂ　一致しないマスターテーブル 　前記のとおり、被告ＣＤＤＢ（現行版）の「２５観光料金種別マスタ」は、原告ＣＤＤＢに対応するマスターテーブルが存在しない。 　その他、原告ＣＤＤＢのマスターテーブルのうち、「０３方面テーブル」及び「０４方面設定テーブル」については、被告システムでは、方面検索の機能がないため、対応するテーブルが存在しない。 　また、原告ＣＤＤＢのマスターテーブルのうち、「１６道路構成地点テーブル」、「１７道路構成地点索引テーブル」、「１８市区町村通過道路索引テーブル」、「１９県範囲定義テーブル」、「２８協定施設テーブル」、「２９券種テーブル」、「３０協定旅館テーブル」、「３１連結協定テーブル」、「３５時刻表料金テーブル」、「３７路線検索索引テーブル」、「３８路線タイプテーブル」、「４１時刻テーブル」、「４４地方別会社索引テーブル」、「４５検索地方範囲定義テーブル」、「４６地方別路線索引テーブル」及び「４７駅通過線索引テーブル」についても、被告ＣＤＤＢ（現行版）に対応するマスターテーブルが存在しない。 　「４５検索地方範囲定義テーブル」については、上記被告ＣＤＤＢ（当初版・２００６年版）記載のとおりである。 (イ)　被告ＣＤＤＢ（現行版）の各テーブルに存在するフィールドの種類及び数　原告ＣＤＤＢには４２個のテーブルに、４０５個のフィールドが存するところ、被告ＣＤＤＢ（現行版）の２６個のテーブルには別紙３記載のとおり、総数２５６個のフィールドが存する。 　前記のとおり原告ＣＤＤＢのマスターテーブルと一致する被告ＣＤＤＢ（現行版）のテーブルにおけるフィールド項目については、別紙３記載のとおり、一致するテーブルに存するフィールドは２４５個である（なお、被告ＣＤＤＢ（現行版）のフィールドのうち、「２１施設マスタ」テーブルの「キーワード」フィールド、「公共種別」フィールドは、いずれも被告ＣＤＤＢ（現行版）のVer2.84 以降のものに加えられたフィールドであるところ、別紙３のフィールド数の計算（カウント）にはこれも含めている。また、被告ＣＤＤＢ（現行版）のうち、「３都道府県マスタ」の「都道府県名英字」フィールドは、被告ＣＤＤＢ（現行版）のVer2.90 以降のものに加えられたフィールドであるところ、別紙３のフィールド数の計算（カウント）にはこれも含めている。）。 　フィールドのうち、「作成日時」、「更新日時」及び「削除区分」のフィールドは、データ更新やテーブル管理を行うための管理項目であり、データベースの検索機能や提供データの内容自体に影響を及ぼす性質のものではない。〔甲３、７頁〕 　このうち、被告ＣＤＤＢ（現行版）における、ほぼ各テーブル（マスタ）に存在する「登録日時（作成日時）」、「更新日時（更新日時）」及び「削除区分（削除区分）」のフィールドを除くと、原告ＣＤＤＢと被告ＣＤＤＢ（現行版）とで一致するフィールド数は１７３個となるところ、別紙３のとおり、このうちの１４３個が、原告ＣＤＤＢと一致している。 (ウ)　テーブル間の関連付け 　原告ＣＤＤＢのマスターテーブルと一致する２３個のテーブルに関しては、プライマリー・キーの設定も含め、原告ＣＤＤＢに存在する関連付けのほぼ全てについて、同様の関連付け（リレーション）が被告ＣＤＤＢに存在する。その内容は、別紙６、９のとおりである（別紙９で青丸と青丸とを結ぶ黒線〔黒太線を含む〕及び黒点線で記載されたリレーションが、当裁判所がその存在を認めるリレーションである。）。 　別紙３のとおり、原告ＣＤＤＢと被告ＣＤＤＢ（現行版）とでは、原告ＣＤＤＢのマスターテーブルと一致する２３個のテーブルに関して、プライマリー・キーの設定につき、原告ＣＤＤＢの「０２地区・県名テーブル」の「地区コード」フィールド、原告ＣＤＤＢの「１１接続テーブル」の「接続番号」フィールド（被告ＣＤＤＢ（現行版）では、「３７単経路マスタ」の「地点コード（始点）（地点番号 始点）」、「地点コード（終点）（地点番号終点）」及び「道路コード（道路番号）」の三つのフィールドにプライマリー・キーが設定されている。）、原告ＣＤＤＢの「１２禁止乗換テーブル」の「乗換元接続番号」フィールド（被告ＣＤＤＢ（現行版）では、「３８禁止経路マスタ」の「地点コード（始点）（地点番号 始点）」、「道路コード（道路番号）」、「地点コード（中間点）（地点番号 中間）」、「地点コード（終点）（地点番号 終点）」及び「通行禁止道路コード（道路番号禁止）」の五つのフィールドにプライマリー・キーが設定されている。）、被告ＣＤＤＢ（現行版）の「３９区間料金マスタ」及び「４０通行料金マスタ」の各「道路料金区分（道路料金区分）」フィールドを除き、一致したフィールドないし同一のテーブルの同種フィールドにプライマリー・キーが設定され、これらに基づき、上記のとおりのリレーションがとられている。 　なお、この点につき、被告らは、被告ＣＤＤＢ（現行版）の「３６道路マスタ〔テーブルＩＤ；Ｍ＿ＤＯＲＯ〕」の「道路コード」フィールドと「３８禁止経路マスタ〔テーブルＩＤ；Ｍ＿ＫＩＮＳＩＫＥＩＲＯ〕」の「道路コード」フィールドとの間、「３６道路マスタ」の「道路コード」フィールドと「３８禁止経路マスタ」の「通行禁止道路コード」フィールドとの間、及び「３８禁止経路マスタ」の「地点コード（始点）」、「地点コード（中間点）」、「地点コード（終点）」のそれぞれの地点コードと「３５地点マスタ〔テーブルＩＤ；Ｍ＿ＣＨＩＴＥＮ〕」の「地点コード（始点）」、「地点コード（中間点）」、「地点コード（終点）」のそれぞれの地点コードとの間には、いずれもリレーションがあるとする一方（別紙９に赤丸と赤丸を結ぶ赤点線で記載されたリレーション）、「３７単経路マスタ〔テーブルＩＤ；Ｍ＿ＴＡＮＫＥＩＲＯ〕」の「地点コード（始点）」、「地点コード（終点）」、「道路コード」のそれぞれのフィールドと「３８禁止経路マスタ」の「地点コード（始点）」、「地点コード（中間点）」、「地点コード（終点）」、「道路コード」、「通行禁止道路コード」との間のリレーションを否認する（別紙９に青丸と青丸を結ぶ黒点線で記載されたリレーション）ので、以下、検討する。 　まず、「３８禁止経路マスタ」と「３７単経路マスタ」との間にリレーションが存在しないとする被告の主張については、被告システムに用いられているSQLサーバーを管理するツールであるSQL Server Profiterを用いた解析結果によれば、被告ＣＤＤＢ（現行版）において、「３８禁止経路マスタ」と「３７単経路マスタ」とにリレーションがあることが認められるから、これと各テーブルのフィールドの内容からすれば、上記「３７単経路マスタ」の「地点コード（始点）」、「地点コード（終点）」、「道路コード」のそれぞれのフィールドと「３８禁止経路マスタ」の「地点コード（始点）」、「地点コード（中間点）」、「地点コード（終点）」、「道路コード」、「通行禁止道路コード」との間にリレーションがあることが認められる。詳細は後記オのとおりである。〔甲５８〕 　次に、「３６道路マスタ」の「道路コード」フィールドと「３８禁止経路マスタ」の「道路コード」フィールドとの間、「３６道路マスタ」の「道路コード」フィールドと「３８禁止経路マスタ」の「通行禁止道路コード」フィールドとの間、及び「３８禁止経路マスタ」の「地点コード（始点）」、「地点コード（中間点）」、「地点コード（終点）」のそれぞれの地点コードのフィールドと「３５地点マスタ」の「地点コード」フィールドとの間には、いずれもリレーションがあるとする点につき、被告らは、禁止経路は、あくまでも地点の組み合わせによりデータを取得していて単経路の組み合わせとはなっていないために、禁止経路マスタと単経路マスタは、一方が他方を包含する関係にあるから、リレーションがある旨を主張するが、包含関係があるか否かによりリレーションの有無が判断されるものとは認められない。なお、この点についての詳細は後記オのとおりである。 また、前記のとおり、被告ＣＤＤＢ（現行版）では、原告ＣＤＤＢの「２０ホテル・旅館テーブル」、「２１観光施設テーブル」及び「２２観光施設備考テーブル」の３テーブルに対応するテーブルとして、「２１施設マスタ」、「２９宿泊施設マスタ」、「２３観光施設マスタ」及び「２６観光料金マスタ」の４テーブルを設けているところ、原告ＣＤＤＢにおける「０１市区町村テーブル」が「２０ホテル・旅館テーブル」、「２１観光施設テーブル」の二つのテーブルとリレーションをとっていることに対して、被告ＣＤＤＢ（現行版）の「４市区町村マスタ」は、原告ＣＤＤＢの「２０ホテル・旅館テーブル」及び「２１観光施設テーブル」の共通項目を括りだした上位のテーブルとなっている被告ＣＤＤＢ（現行版）の「２１施設マスタ」の一つのテーブルとのみリレーションをとっており、これにより、これと関連するリレーションの線がその分少なくなっているが、この点については、被告ＣＤＤＢ（当初版・２００６年版）についてと同様である。 イ　被告ＣＤＤＢ（現行版）の体系的構成が、原告ＣＤＤＢの複製又は翻案に当たるか (ア)　前記のとおり、原告ＣＤＤＢと被告ＣＤＤＢ（現行版）とでは、原告ＣＤＤＢにおける、「０１市区町村テーブル」、「０２地区・県名テーブル」、「０５緯度経度テーブル」、「０６ＵＲＬアドレステーブル」、「０７ＵＲＬ種別テーブル」、「０８ＵＲＬ分類テーブル」、「０９地点名テーブル」、「１０道路テーブル」、「１１接続テーブル」、「１２禁止乗換テーブル」、「１４区間料金テーブル」、「１５首都高速料金テーブル」、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「２２観光施設備考テーブル」、「３２駅テーブル」、「３３路線構成テーブル」、「３４路線テーブル」、「３６路線検索テーブル」、「３９便テーブル」、「４０運行日定義テーブル」、「４２会社テーブル」、「４３交通機関種別テーブル」の２３個のテーブルにつき、これと一致するテーブルが被告ＣＤＤＢ（現行版）には存する。 　原告ＣＤＤＢと被告ＣＤＤＢ（現行版）とで一致するテーブルに存するフィールドも、１４３個にのぼる。 　さらに、テーブル間の関連付けについてみると、原告ＣＤＤＢと被告ＣＤＤＢ（現行版）とでは、別紙６、９のとおり、同様のリレーションが存する。 (イ)　そして、原告ＣＤＤＢは、それまで存しなかった団体旅行の行程表作成のため、顧客である旅行業者等からのヒアリングに基づき、出発地、到着地、交通手段、経由地である観光施設、宿泊施設をデータベース化してこれをコンピュータで効率よく検索できるようにするためのデータベースであり、この点につき、上記被告ＣＤＤＢ（現行版）と共通するフィールドに関してみると、原告ＣＤＤＢの「０１市区町村テーブル」、「３２駅テーブル」、「２０ホテル・施設テーブル」、「２１観光施設テーブル」、「０９地点名テーブル」、「１１接続テーブル」及び「１０道路テーブル」により、出発地、経由地、目的地に面した道路に関するデータの検索を可能にし、次に「０９地点名テーブル」、「１０道路テーブル」、「１１接続テーブル」、「１２禁止乗換テーブル」、「１４区間料金テーブル」及び「１５首都高速料金テーブル」により、道路を利用した移動に関する経路探索・料金の算出に必要なデータの検索を可能にしている。また、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「２２観光設備備考テーブル」、「０５緯度経度テーブル」、「０６ＵＲＬアドレステーブル」、「０７ＵＲＬ種別テーブル」及び「０８ＵＲＬ分類テーブル」により、ホテル・旅館、観光施設に関する情報を検索することを可能にしている。そして、「０１市区町村テーブル」、「０２地区・県名テーブル」は、道路と地図を関連付ける情報として、地図から検索をするときに用いられている。また、「０１市区町村テーブル」、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」及び「３２駅テーブル」には施設等の近辺の道路地点の情報が代表道路地区コードや代表道路地点番号として格納されており、当該市区町村内にあるこれらの施設や駅などを選ぶことを通じて出発点としての「０９地点名テーブル」の道路地点を選ぶことができる。また、観光施設も「２１観光施設テーブル」から選択し、絞り込みは、「０２地区・県名テーブル」、「０１市区町村テーブル」から行うことができる。観光名称は「２１観光施設テーブル」に、検索結果の観光施設について、当該観光施設に関する様々の情報は、「２２観光施設備考テーブル」に格納されており、観光施設に関するホームページの情報も「０６ＵＲＬアドレステーブル」、「０７ＵＲＬ種別テーブル」から参照可能であり、最終的に行程に入れるかどうかを判断することができる。 　宿泊施設については、「２０ホテル・旅館テーブル」から選択し、地区は「０２地区・県名テーブル」、都道府県も「０２地区・県名テーブル」、市区町村は「０１市区町村テーブル」、地図上の範囲設定はプロアトラスと「０５緯度経度テーブル」、「２０ホテル・旅館テーブル」、宿泊種別は「２０ホテル・旅館テーブル」、名称は「２０ホテル・旅館テーブル」、検索結果の宿泊施設については当該宿泊施設に関する様々な情報、すなわち和室、洋室の客室数、収容人員、料金、付帯施設、駐車場などが「２０ホテル・旅館テーブル」に格納されていて、当該宿泊施設に関するホームページの情報も「０６ＵＲＬアドレステーブル」、「０７ＵＲＬ種別テーブル」が対応し、これらを参照して顧客の判断で決定することができる。 　また、「３２駅テーブル」、「３３路線構成テーブル」、「３４路線テーブル」、「３６路線検索テーブル」、「３９便テーブル」、「４０運行日定義テーブル」、「４２会社テーブル」及び「４３交通機関種別テーブル」により、公共交通機関を利用した経路探索に必要なデータの検索を可能にしている。 　これら共通するテーブルについては、いずれも各テーブルを構成するフィールドにつき、原告ＣＤＤＢと、被告ＣＤＤＢ（現行版）とでほとんどが共通し、リレーションのとり方もほぼ共通するものである。 　そして、両者で共通するこれらの体系的構成は、原告ＣＤＤＢの制作者において、それまでのデータベースにはなかった設計思想に基づき構成した原告ＣＤＤＢの創作活動の成果であり、その共通する部分のみでデータベースとして機能し得る膨大な規模の情報分類体系であると認められ、データベースとして制作者の個性が表現されているものということができる。 　したがって、被告ＣＤＤＢ（現行版）と共通する上記原告ＣＤＤＢの部分については、データベースの体系的構成としての創作性を有するものと認めるのが相当である。 (ウ)　一方、原告ＣＤＤＢと被告ＣＤＤＢ（現行版）とを比較すると、両者で一致しないマスターテーブルとして、被告ＣＤＤＢ（現行版）の「２５観光料金種別マスタ」、「２７観光種別マスタ」と「２８観光詳細種別マスタ」があり、これらは、原告ＣＤＤＢには含まれないものである。 　このうち「２５観光料金種別マスタ」については、そこに含まれるフィールドをみると、プライマリー・キーの設定された「観光料金種別」フィールド、「料金種別名」、「管理備考」の各フィールド（被告ＣＤＤＢ（当初版・２００６年版）とは若干異なる。）のほかは、作成日時、区分等のフィールドであり、このうち料金種別にかかるものは、原告ＣＤＤＢの「２１観光施設テーブル」、「２２観光施設備考テーブル」では４種類までの料金しか登録することができないところ、被告ＣＤＤＢ（現行版）においても、「２５観光料金種別マスタ」を設けることによりそれ以上の種類の料金設定についても登録できるようにテーブルを設けることとしたことに変わりないものと認められる。〔乙２０〕 　しかし、前記のとおり原告ＣＤＤＢでも料金種別により分類可能であったところ、これについて、料金種別を増やすためにテーブルを設けること自体は、原告ＣＤＤＢに新たに創作的表現を加えたものとはいい難い。 　また、「２７観光種別マスタ」と「２８観光詳細種別マスタ」については、前記のとおり、原告システムをユーザーのハードウェア内にインストールした際に作成される原告マスターテーブルの中に、これら二つのテーブルに対応するマスターテーブルである「２３観光施設種別テーブル」及び「２４観光施設検索タイトルテーブル」が存在し、被告ＣＤＤＢ（現行版）においては、被告ＣＤＤＢ（当初版・２００６年版）と比べて、フィールドＩＤのうち原告ＣＤＤＢと一致するものについて変更されているものの、フィールドの区分等についてはほとんど変更がなく、被告ＣＤＤＢ（現行版）において新たに加わった創作の成果ということはできないから、実質的に原告システム中に存する原告ＣＤＤＢと関連する部分を、ＣＤで提供されるデータベース中に移した関係にすぎないものと認められる。 　しかも、テーブルについては、被告ＣＤＤＢ（当初版・２００６年版）においては一致するテーブルとしては存しなかった「４３路線マスタ」、「４４便マスタ」、「４５時刻マスタ」及び「４６路線構成マスタ」も、被告ＣＤＤＢ（現行版）には設けられ、これら各テーブルのフィールドも、「備考」、「作成日時」等のフィールドを除き、原告ＣＤＤＢのフィールドとすべて一致している。 　そして、フィールドの詳細についてみても、被告ＣＤＤＢ（現行版）の「３５地点マスタ」、「３６道路マスタ」、「３７単経路マスタ」及び「３８禁止乗換マスタ」の各テーブルのフィールドは、上記リレーションの存在等からして、いずれも「作成日時」、「更新日時」及び「削除区分」フィールドを除き、原告ＣＤＤＢの「０９地点名テーブル」、「１０道路テーブル」、「１１接続テーブル」及び「１２禁止乗換テーブル」の各テーブルのフィールドと一致するものと認められる。 　また、原告ＣＤＤＢと一致するテーブルである、「３９区間料金マスタ」、「４０通行料金マスタ」テーブルには、いずれも「道路料金区分」のフィールドが設けられているが、「３９区間料金マスタ」、「４０首都高速料金マスタ」テーブルには、いずれも原告ＣＤＤＢと一致するフィールドであった被告ＣＤＤＢ（当初版・２００６年版）の「３９料金マスタ」、「４０通行料金マスタ」テーブルの「普通車料金」、「中型車料金」、「大型車料金」、「特大車料金」の各フィールドにつき、原告ＣＤＤＢにおいて、もともと区分されていた料金につき、その区分のフィールドを独立して設けたものにすぎない。また、「２１施設マスタ」テーブルの「温泉地コード」フィールド、「２６観光料金マスタ」の「料金種別コード」フィールド、「２９旅館マスタ基本」テーブルの「シングル数」フィールド等についても、もともと種別自体は設けられていたものを細分化したにすぎないものであって、これらについては、いずれも体系的構成として独自の創作性は認められないものである。 　さらに、リレーションの取り方についてみても、原告ＣＤＤＢと被告ＣＤＤＢ（現行版）とで異なるリレーションとなっている、被告ＣＤＤＢ（現行版）においても、「４市区町村マスタ」は、施設に関し「２１施設マスタ」とのみリレーションを取っていることから、原告ＣＤＤＢにおける「０１市区町村テーブル」が「２０ホテル・旅館テーブル」、「２１観光施設テーブル」の二つのテーブルとリレーションを取っていることに対して、リレーションが少なくなっているところ、既に検討したとおり、被告ＣＤＤＢ（現行版）の「２１施設マスタ」及びこれと関連する、「２９宿泊施設マスタ」、「２３観光施設マスタ」テーブルについては、原告ＣＤＤＢの「２０ホテル・旅館テーブル」、「２１観光施設テーブル」とは実質的に一致するテーブルであると認められることや、別紙９のとおり認められる被告ＣＤＤＢ（現行版）の「４市区町村マスタ」、「３１ＵＲＬマスタ」、「３４緯度経度マスタ」テーブル等と、「２１施設マスタ」、「２９宿泊施設マスタ」、「２３観光施設マスタ」テーブル等、及び「２１施設マスタ」テーブルと、「２９宿泊施設マスタ」、「２３観光施設マスタ」テーブルとのリレーションのとり方等からすると、被告ＣＤＤＢ（現行版）とのリレーションのとり方は、原告ＣＤＤＢのリレーションのとり方に新たな創作性を加えるものは認められない。 (エ)　そうすると、これら被告ＣＤＤＢ（現行版）が原告ＣＤＤＢと共通性を有する部分は、原告ＣＤＤＢの創作的表現の本質的特徴の同一性が維持されており、これを直接感得することができるものというべきであり、一方、被告ＣＤＤＢ（現行版）において変更が加えられた部分は、いずれも創作性を有しない部分であるということができる。 ウ　被告ＣＤＤＢ（現行版）と原告ＣＤＤＢとの情報の選択の共通性 (ア)　フィールド項目の選択の類似性 　前記のとおり、テーブル管理のためのフィールドである「登録日時」、「更新日時」及び「削除区分」等のフィールドを除いた被告ＣＤＤＢ（現行版）のフィールド数１７３個のうち１４３個が原告ＣＤＤＢのフィールドと一致している。 (イ)　レコードの選択の類似性 　被告らは、被告ＣＤＤＢ（当初版・２００６年版）において、原告ＣＤＤＢのテーブルのうち、以下の２０個のテーブルに含まれるレコードをコピーして用いたことを認めていた。 　そのテーブルとは、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「０５緯度経度テーブル」、「０６ＵＲＬアドレステーブル」、「０７ＵＲＬ種別テーブル」、「０８ＵＲＬ分類テーブル」、「０１市区町村テーブル」、「０２地区・県名テーブル」、「０９地点名テーブル」、「１０道路テーブル」、「１１接続テーブル」、「１２禁止乗換テーブル」、「１３有料道路番号テーブル」、「１４区間料金テーブル」、「１５首都高速料金テーブル」、「１６道路構成地点テーブル」、「１７道路構成地点索引テーブル」、「１８市区町村通過道路索引テーブル」、「１９県範囲定義テーブル」及び「３２駅テーブル」である。 　このうち、被告らは、被告ＣＤＤＢ（当初版・２００６年版）において存在した、原告ＣＤＤＢの「１３有料道路番号テーブル」、「１６道路構成地点テーブル」、「１７道路構成地点索引テーブル」、「１８市区町村通過道路索引テーブル」及び「１９県範囲定義テーブル」の五つのテーブルと対応するテーブルについては、被告ＣＤＤＢ（現行版）においては削除したとしている。 　また、被告らは、被告ＣＤＤＢ（現行版）において、原告ＣＤＤＢの「０７ＵＲＬ種別テーブル」、「０８ＵＲＬ分類テーブル」に対応する「３２ＵＲＬ種別マスタ」、「３３ＵＲＬ見出しマスタ（被告ＣＤＤＢ（現行版）ではＵＲＬ分類マスタ）」の二つのテーブルについては、テーブル及びそれらに存する合計１１個のフィールドはいずれも維持するものの、レコード数はいずれもゼロであるとする。 　原告ＣＤＤＢの「０５緯度経度テーブル」に対応する「３４緯度経度マスタ」については、別紙３のとおり、被告ＣＤＤＢ（当初版・２００６年版）の四つのフィールドにおいては、いずれも原告ＣＤＤＢの対応するフィールドとフィールドＩＤが完全に一致していたところ、被告ＣＤＤＢ（現行版）においては、フィールドＩＤを改め、新たに「作成日時」、「更新日時」及び「削除区分」の三つのフィールドを設けるほか、別紙４のとおり、公共施設につき７万件余りのレコードを追加し、総レコード数を１８万余とした。対応する原告ＣＤＤＢのレコード数は１１万余件である。 　原告ＣＤＤＢの「２０ホテル・旅館テーブル」、「２１観光施設テーブル」についても、被告ＣＤＤＢ（当初版・２００６年版）と原告ＣＤＤＢの対応するフィールドとフィールドＩＤが完全に一致していたものについては、被告ＣＤＤＢ（現行版）においては、フィールドＩＤを改め、フラグ、日付等に関するフィールドについて、一部削除を行うなどしたほかは、基本的に被告ＣＤＤＢ（当初版・２００６年版）のフィールドを維持し、レコードに関し、新設ホテル、施設等の追加や削除等を行った。 　原告ＣＤＤＢの「０９地点名テーブル」と対応する「３５地点マスタ」については、被告ＣＤＤＢ（当初版・２００６年版）においては、フィールド数、フィールドＩＤが原告ＣＤＤＢと完全に一致していたところ、被告ＣＤＤＢ（現行版）においては、フィールドＩＤを改めるとともに、「作成日時」、「更新日時」及び「削除区分」の三つのフィールドを新設するほか、道路データの追加等に伴い、レコードを追加・更新した。 　原告ＣＤＤＢの「１０道路テーブル」と対応する被告ＣＤＤＢ（現行版）の「３６道路マスタ」については、被告ＣＤＤＢ（当初版・２００６年版）の「３６道路名マスタ」においては、フィールド数、フィールドＩＤが原告ＣＤＤＢと完全に一致していたところ、被告ＣＤＤＢ（現行版）においては、フィールドＩＤを改めるとともに、「作成日時」、「更新日時」及び「削除区分」の三つのフィールドを新設するほか、道路データを追加・更新した。 　被告ＣＤＤＢ（当初版・２００６年版）の「３７接続マスタ」については、原告ＣＤＤＢの「１１接続テーブル」のデータをコピーして利用したことを被告らは認めており、被告ＣＤＤＢ（当初版・２００６年版）の同テーブルの各フィールドＩＤは、被告ＣＤＤＢ（当初版・２００６年版）で付加された「連番」フィールドを除き、その余の９個のフィールドにつき、いずれも原告ＣＤＤＢのフィールドＩＤに「ＲＤＣ」を頭に付加した以外は同一であるところ、被告ＣＤＤＢ（現行版）ではこれらＩＤを改めるとともに、フィールドを五つとして被告ＣＤＤＢ（当初版・２００６年版）からの正規化を行うとともに、「作成日時」、「更新日時」及び「削除区分」の三つのフィールドを新設するほか、「地点コード（始点）」、「地点コード（終点）」、「道路コード」の三つにプライマリー・キーを設定した。また、道路データを充実させたことに伴う追加、更新等をレコードに関して行った。 　被告ＣＤＤＢ（当初版・２００６年版）の「３８禁止乗換マスタ」については、原告ＣＤＤＢの「１２禁止乗換テーブル」のデータをコピーして利用したことを被告らは認めており、被告ＣＤＤＢ（当初版・２００６年版）の同テーブルの各フィールドＩＤは、いずれも原告ＣＤＤＢのフィールドＩＤと同一であるところ、被告ＣＤＤＢ（現行版）ではこれらＩＤを改めるとともに、「作成日時」、「更新日時」及び「削除区分」の三つのフィールドを新設するほか、「地点コード（始点）」、「地点コード（終点）」、「道路コード」の三つにプライマリー・キーを設定した。また、道路データを充実させたことに伴う追加、更新等をレコードに関して行った。 　原告ＣＤＤＢの「１４区間料金テーブル」に対応する被告ＣＤＤＢ（当初版・２００６年版）の「３９料金マスタ」については、原告ＣＤＤＢのデータをコピーして利用したことを被告らは認めており、被告ＣＤＤＢ（当初版・２００６年版）の同テーブルの各フィールドＩＤは、いずれも原告ＣＤＤＢのフィールドＩＤと同一であるところ、被告ＣＤＤＢ（現行版）ではこれらＩＤを改めるとともに、「作成日時」、「更新日時」及び「削除区分」の三つのフィールドを新設するほか、「地点コード（始点）」、「地点コード（終点）」、「道路料金区分」の三つにプライマリー・キーを設定した。また、高速道路の料金改定、区間延長等に対応してレコードを追加し、このテーブルのレコードだけで１７０万件余りとなり、全レコードの６６％以上を占めている。 　原告ＣＤＤＢの「１５首都高速料金テーブル」に対応する被告ＣＤＤＢ（当初版・２００６年版）の「４０首都高速料金マスタ」については、原告ＣＤＤＢのデータをコピーして利用したことを被告らは認めており、被告ＣＤＤＢ（当初版・２００６年版）の同テーブルの各フィールドＩＤは、いずれも原告ＣＤＤＢのフィールドＩＤと同一であるところ、被告ＣＤＤＢ（現行版）ではこれらＩＤを改めるとともに、「作成日時」、「更新日時」、「削除区分」の三つのフィールドを新設するほか、「道路コード」、「道路料金区分」の二つにプライマリー・キーを設定した。また、有料道路料金の無料化、料金改定等に対応してレコードの追加、更新等を行った。 　原告ＣＤＤＢの「３２駅テーブル」に対応する「４７駅マスタ」では、被告ＣＤＤＢ（当初版・２００６年版）に存した「駅番号（ヴァル研）〔フィールドＩＤ；ＪＫＢＶＡＬＮＤ〕」、「ＪＲ駅名コード〔フィールドＩＤ；ＪＫＢＪＲＮＯ〕」の二つのフィールドを削除した。なお、これらフィールドＩＤは、いずれも原告ＣＤＤＢの対応するフィールドのＩＤと同一である。 (ウ)　具体的な情報の同一ないし類似性 a　地点名テーブルの道路情報 　原告ＣＤＤＢ（２００６年１１月版）の「０９地点名テーブル」には、１万２８２２件のレコードが収録され、被告ＣＤＤＢ（現行版）では、バージョンにより異なるものの、２００７年９月版のVer2.53 の「３５地点マスタ」には、そのうちの９９．５％である１万２７６２件につき、一致する道路地点（前記同様、「関ＪＣＴ（伊勢自動車道・名阪国道）」、「芸濃ＩＣ（伊勢自動車道、県道１０号）」等）のレコードが収録されている。〔甲３２〕 b　緯度経度情報の一致 　そして、原告ＣＤＤＢの「０９地点名テーブル」の道路地点の緯度経度情報は、前記のとおり、原告ＣＤＤＢ作成時に、作成者自身がパソコンのマウスを地図上でクリックする方法で選択した場所について、これを０．１秒単位で緯度経度を測定して数値化したものであり、被告ＣＤＤＢ（現行版のうち、２００７年９月版のVer2.53）においても、６ないし７桁の数値で緯度経度情報を収録しているところ、上記道路地点のうち、この６ないし７桁で表される緯度及び経度情報につき、原告ＣＤＤＢ（２００６年１１月版）との完全一致率は９６．６％であり、１万２３９２件の一致するレコードが収録されている。〔甲２２、２８、３２、３９、７０〕 ｃ　選択道路の一致 　原告ＣＤＤＢは、前記のとおり、大型観光バスでの移動に適した道路の選択を行っており、多くの道道、県道等の中から北海道では８０道道、福岡県では４７県道を選択しているところ、被告ＣＤＤＢ（現行版のうち、２００７年５月版のVer2.0）では、北海道では、全データ８３件のうち、全く同じ８０道道を、福岡県ではこれと一致する県道のうち４１県道を選択して格納している。〔甲４８〕 ｄ　その他の情報の一致 (a)　緯度経度情報について 　原告ＣＤＤＢでは、新バージョンに移行しない顧客のために「０１市区町村テーブル」、「０９地点名テーブル」、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「３２駅テーブル」と緯度経度テーブルとで緯度経度情報を重複保有している。被告ＣＤＤＢ（現行版）でも同様に重複保有している。 (b)　地点名テーブルについて 　原告ＣＤＤＢと同じ誤りが被告ＣＤＤＢ（現行版）にも存在する（被告ＣＤＤＢ（当初版・２００６年版）の該当箇所で記載した「阿武隅」。正しくは「阿武隈」。）。 (c)　道路テーブルについて �@　原告ＣＤＤＢと同じ誤りが被告ＣＤＤＢ（現行版）にも存在する。すなわち、被告ＣＤＤＢ（当初版・２００６年版）の例で挙げた、道路番号原告ＣＤＤＢ４６２（ＡＺ６３４）の道路名「金精道路」の読みの誤り（誤りは「キンセイドウロ」、正しくは「コンセイドウロ」）が、被告ＣＤＤＢ（現行版）にも存する。 �A　原告ＣＤＤＢと同じ誤りが被告ＣＤＤＢ（現行版）にも存在する。被告ＣＤＤＢ（当初版・２００６年版）の該当箇所でも記載したとおり、原告ＣＤＤＢは茨城県の読み仮名を、「イバラキケン」（正）と「イバラギケン」（誤）を混在して登録している。〔甲６５の別紙５〕 �B　被告ＣＤＤＢ（当初版・２００６年版）の該当箇所でも記載したとおり、ダミーデータ「＊＊＊」（道路名）、「ン ダミー」（道路名の読み）の一致が、被告ＣＤＤＢ（現行版）においても認められる。〔甲２１〕 (d)　首都高速料金テーブルについて 　原告ＣＤＤＢと同じ誤りが被告ＣＤＤＢ（現行版）にも存在する。具体的には、前記(3)カ(ｱf 記載のとおりである。 　被告らは、原告から、２０１０年９月２２日付け第６準備書面で、「蔵王ハイライン」の誤った料金データ一致がデッドコピーであるとの指摘を受け、その後の２０１０年１２月・２０１１年１月版のVer2.99 からはこれを修正した。〔甲６５の別紙７〕 (e)　ホテル・旅館テーブルについて �@　宿泊施設の読み仮名に関して、原告ＣＤＤＢと同じ誤りが被告ＣＤＤＢ（現行版）にも存在する。被告ＣＤＤＢ（当初版・２００６年版）の該当箇所でも記載したとおり、原告ＣＤＤＢでは宿泊施設名の読み仮名について長音符「ー」とすべきを誤って数字記号マイナス「−」で登録した場合が相当あるが、これらと同じ誤りが被告ＣＤＤＢ（現行版）にも存在する。具体的には、前記(3)カ(ア)g(a)記載のとおりである。 �A　宿泊施設名の読み仮名に関して、原告ＣＤＤＢと同じ誤り（施設カナ）が被告ＣＤＤＢ（現行版）に存在する。これらについては、被告ＣＤＤＢ（当初版・２００６年版）と同じ誤りが、全て被告ＣＤＤＢ（現行版）にも存する。具体的には、前記(3)カ(ア)g(b)記載のとおりである。 (f)　観光施設テーブルについて �@　観光施設名の読み仮名に関して、原告ＣＤＤＢと同じ誤りが被告ＣＤＤＢ（現行版）にも存在する。 　被告ＣＤＤＢ（当初版・２００６年版）の該当箇所でも記載したとおり、原告ＣＤＤＢは宿泊施設名称の読み仮名を表記するフィールドを有しており、宿泊施設名に「英字」「数字」を含む場合に「英字」「数字」についてもきちんと読み仮名で表記されているものと、読み仮名に「英字」「数字」がそのまま残っているものが混用されているところ、被告ＣＤＤＢ（現行版）にも原告ＣＤＤＢと同じ混用状態が存在する。 　被告ＣＤＤＢ（当初版・２００６年版）と同じく、原告ＣＤＤＢの施設名称「美利河Ｉ遺跡」（「Ｉ」は英字のアイ）の誤りにつき、被告ＣＤＤＢ（現行版）は原告ＣＤＤＢと一致する誤り（英字の「Ｉ」）の登録をしている。〔甲６５の別紙１４〕 �A　観光施設の読み仮名に関して、原告ＣＤＤＢと同じ誤りが被告ＣＤＤＢ（現行版）に存在する。原告ＣＤＤＢでは観光施設名の読み仮名について、長音符「ー」とすべきを誤って数字記号マイナス「−」で登録した場合が相当数あるところ、これらと同じ誤りが被告ＣＤＤＢ（現行版）に存在する。読み仮名に長音符「ー」とマイナス記号「−」が混用されている前記(3)カ(ア)h(b)記載の例のほか、被告ＣＤＤＢ（当初版・２００６年版）と同様、そうした事例が存在する。〔甲６５の別紙１５〕 �B　株式会社、有限会社の施設名やその読み仮名に関する原告ＣＤＤＢの不統一表記や誤りと同じ不統一の表記や誤りが被告ＣＤＤＢ（現行版）にも存在する。 　被告ＣＤＤＢ（当初版・２００６年版）の該当箇所でも記載したとおり、原告ＣＤＤＢは、株式会社や有限会社といった法人の種別について、施設名とそのカナについて不統一な表記を行っている。 　原告ＣＤＤＢの以下の二つのパターン（被告ＣＤＤＢ（当初版・２００６年版）では八つ）のデータと同じデータが被告ＣＤＤＢ（現行版）に存する。〔甲６５の別紙１８〕 ・施設名を株式会社とし、カナをサブシキカイシャと誤って表記する ・施設名を（株）とし、カナをカブと表記する �C　観光施設名の読み仮名表記に原告ＣＤＤＢと同じ誤り（「ひらがなが混じる」、「漢字が混じる」、「英字が混じり読みも誤る」、「記号「＾」が混じり読みも誤る」など）が被告ＣＤＤＢ（現行版）にも存在する。具体的には前記(3)カ(ア)h(d)記載の被告ＣＤＤＢ（当初版・２００６年版）の例のほか、その他にも事例がある。〔甲６５の別紙１９〕 �D　原告ＣＤＤＢでは施設について旧名称と現行名称と重複して登録する例があるが、被告ＣＤＤＢ（現行版）でも同一の重複登録があり、この点については、前記(3)カ(ア)h(e)記載と同様である。 �E　原告ＣＤＤＢに平成１７年（２００５年）当時登録されていた下記の平成１７年（２００５年）のイベントのデータが、被告ＣＤＤＢ（現行版）にも引き続き存在しており、この点については、前記(3)カ(ア)h(f)記載と同様である。 (g)　駅テーブルについて 　駅名の読み仮名に関して、原告ＣＤＤＢと同じ誤りが被告ＣＤＤＢ（現行版）にも存在する（なお、２０１１年２・３月版Ver3.1 以降と、被告ＣＤＤＢ（新版）では「ベフ」に改変されている）。〔甲６５の別紙２５〕 　この点については、前記(3)カ(ｱ)j記載と同様である。 エ　被告ＣＤＤＢ（現行版）の情報の選択が、原告ＣＤＤＢの複製又は翻案に当たるか (ア)　前記のとおり、原告ＣＤＤＢと被告ＣＤＤＢ（現行版）とでは、情報の選択について、地点名テーブルの道路情報、緯度経度情報の情報が、それぞれ完全に一致するか、大部分において一致している。 (イ)　そして、原告ＣＤＤＢにおいては、前記のとおり、旅行会社に対する実情調査等の結果を踏まえ、主たる目的として、大型観光バスによる団体旅行を主眼とした行程表作成のための便宜から、通常使用されるロードマップとは異なる観点である、貸切観光バスが通行するのに適した道路として、都道府県道については約１０％、市区町村道では約０．００４％程度を選択して「１０道路テーブル」に格納し、道路地点として選択した地点における情報も緯度及び経度のデータとして格納することとし、これを大型観光バスが通過するのに適切と考えられる道路のうちの、行程表を作成する上で必要と考えられ適切な地点でもある、交差点、インターチェンジ、サービスエリア、パーキングエリア、観光施設、宿泊施設、駅、役所等の代表道路地点とするのに適切な地点を選別し、パソコンのマウスを地図上でクリックする方法で選択して、実際に入力したものである。 　そして、施設と関係する代表道路地点の選択においては、施設が接する道路地点ではなく、当該施設の近辺の道路地点を当該施設の代表道路地点として適宜設定している。 　このように、原告ＣＤＤＢと被告ＣＤＤＢ（現行版）との共通部分である、道路、道路位置、代表道路地点等の選別・選択について、原告ＣＤＤＢの制作者の創作活動の成果が表れており、その個性が表現されている。 　したがって、被告ＣＤＤＢ（現行版）と共通する上記原告ＣＤＤＢの部分については、データベースの情報の選択としての創作性を有するものと認めるのが相当である。 　そして、これら被告ＣＤＤＢ（現行版）が原告ＣＤＤＢと共通性を有する部分は、原告ＣＤＤＢの創作的表現の本質的特徴を直接感得することができるものというべきである。 オ　被告らの主張に対する判断 (ア)　被告らは、被告ＣＤＤＢ（現行版）の「３７単経路マスタ」では、接続番号のフィールドを削除して接続概念を一新しており、原告ＣＤＤＢの「１１接続テーブル」とは異なる旨主張する。 　原告ＣＤＤＢの「１１接続テーブル」においては、道路地点間の接続情報である始点、終点、通行する道路の道路番号、移動に要する時間、２地点間の距離、上り下り車線の情報、接続番号などの情報等を各フィールドごとに格納しているところ、前記認定のとおり、被告ＣＤＤＢ（当初版・２００６年版）の「３７接続マスタ」では、これら原告ＣＤＤＢと比較すると、「連番」のフィールドを除き、同一のフィールドが存在していた。そして、被告ＣＤＤＢ（現行版）の「３７単経路マスタ」では、これら接続情報のうち、始点、終点、通行する道路の道路番号、移動に要する時間、２地点間の距離に関連するフィールドのみを残して、「接続番号」、「乗換禁止情報索引」、「上下区分」等、その余のフィールドを削除したものと認められる。これについては、後記のとおり、乗換禁止の情報に関して、接続番号のフィールドを使わず、これを「始点」、「中間点」、「終点」というフィールドで持つようにしたためであると認められる。 　しかし、これら被告ＣＤＤＢ（現行版）の「３７単経路マスタ」における接続番号等のフィールドの削除自体は、その体系的構成や既に選択されている情報自体に影響を及ぼすものとは認められない。 　したがって、被告らの上記主張は採用することができない。 (イ)　また、被告らは、被告ＣＤＤＢ（現行版）の「３８禁止経路マスタ」は、と原告ＣＤＤＢの「１２禁止乗換テーブル」とは異なるものである旨主張する。 　既に検討したとおり、原告ＣＤＤＢの「１２禁止乗換テーブル」には、一方通行などの理由により、経路として接続できない道路の情報を格納しているところ、具体的には、「１１接続テーブル」で持つ「接続番号」について、ある接続番号（始点番号、終点番号、道路番号などの情報）の経路から、ある接続番号の経路に乗り換えようとした場合に禁止される接続番号の組み合わせを「１２禁止乗換テーブル」に情報として格納している。 　この「１２禁止乗換テーブル」の「乗換元接続番号」と「乗換先接続番号」のフィールドには、乗換元と乗換先の接続番号で禁止される乗換のパターンを特定して格納しているものである。 　これによると、「１１接続テーブル」から各接続番号の始点、終点、道路番号がわかり、乗換を行う場合、乗換元の終点は乗換先の始点となる関係にあるので、接続された場合のルートは 　乗換元の始点→（乗換元の終点＝乗換先の始点）→乗換先の終点 との関係になる。〔甲２３、１１、１２頁〕 　そして、上記（乗換元の終点＝乗換先の始点）は、希望するルートである、乗換元の始点から乗換先の終点から見れば、これはすなわち中間点であるということができる。別紙１の「１１接続テーブル」についての「原告ＣＤＤＢの各テーブルの概要」欄記載の例であれば、地点Ｂはまさにこの中間点である。 　一方、被告ＣＤＤＢ（現行版）の「３８禁止経路マスタ」においては、経路として接続できない、例えば一方通行であるなど、その道路の情報を「地点コード（始点）」、「地点コード（中間点）」、「道路コード」、「地点コード（終点）」、「通行禁止道路コード」の各フィールドにおいて格納している（別紙３のとおり、その余のフィールドは、作成日時等のフィールドである。）。 　そうすると、被告ＣＤＤＢ（現行版）においては、原告ＣＤＤＢの乗換元の始点が被告ＣＤＤＢ（現行版）の地点コード（始点）に、乗換元の終点＝乗換先の始点が地点コード（中間）に、乗換先の終点が地点コード（終点）に、道路コードが通行禁止道路コードにそれぞれ対応するものであって、その違いは、乗換地点が一つ（乗換元の終点＝乗換先の始点）あるのにつき、原告ＣＤＤＢでは乗換元の終点、乗換先の始点と二つのフィールドとして捉えているのに対して、被告ＣＤＤＢ（現行版）では、中間点という一つのフィールドで捉えたところにある。 　しかし、これは実質的内容には変化がなく、合理化を図る一種の正規化として行われたものにすぎず、被告ＣＤＤＢ（当初版・２００６年版）から被告ＣＤＤＢ（現行版）とで体系的構成に実質的な変化をもたらすものとは認められない。 　したがって、被告らの上記主張は採用することができない。 (ウ)　被告らは、被告ＣＤＤＢ（現行版）の「３９区間料金マスタ」は、原告ＣＤＤＢの「１４区間料金テーブル」における料金区分の増加に対する対応において柔軟性があり、異なるものである旨主張する。 　なるほど、原告ＣＤＤＢの「１４区間料金テーブル」には有料道路（距離制料金）における区間、車種による料金情報が格納されており、原告ＣＤＤＢではそれぞれの具体的な車種料金（大型車料金、中型車料金、普通車料金など）を、それぞれフィールドとして保有していることから、新たな車種料金（例えば超小型車）が生じた場合には、フィールドを増やす必要が生じるので、車種料金のフィールドではなく、車種のフィールドを設け具体的な車種についてはデータとして管理した方が合理的といえるところ、被告ＣＤＤＢ（現行版）の「３９区間料金マスタ」では、道路料金区分として車種を格納するフィールドを設け、具体的な車種（大型車、中型車料金、普通車料金など）を具体的なデータとすることにより、新たな車種料金が生じても、フィールドを増やさないで対応できることになる。 このように、原告ＣＤＤＢの「１４区間料金テーブル」と、被告ＣＤＤＢ（現行版）の「３９区間料金マスタ」とでは、道路料金区分として車種を格納するフィールドを設けるか否かには違いがあるが、結局のところこれは、被告ＣＤＤＢ（当初版・２００６年版）と同じ機能について正規化によるフィールドの整理を行ったにすぎないものというべきであり、被告ＣＤＤＢ（当初版・２００６年版）と被告ＣＤＤＢ（現行版）とを比較してその体系的構成自体に変化があるものとはいえない。 　したがって、被告らの上記主張は採用することができない。 (エ)　また、被告らは、被告ＣＤＤＢ（現行版）において、「３８禁止経路マスタ」は、「３５地点マスタ」及び「３６道路マスタ」とはリレーションがあるものの「３７単経路マスタ」とはリレーションがない旨主張する。 　被告らは、被告ＣＤＤＢ（現行版）の「３６道路マスタ〔テーブルＩＤ；Ｍ＿ＤＯＲＯ〕」の「道路コード」フィールドと「３８禁止経路マスタ〔テーブルＩＤ；Ｍ＿ＫＩＮＳＩＫＥＩＲＯ〕」の「道路コード」フィールドとの間、「３６道路マスタ」の「道路コード」フィールドと「３８禁止経路マスタ」の「通行禁止道路コード」フィールドとの間、及び「３８禁止経路マスタ」の「地点コード（始点）」、「地点コード（中間点）」、「地点コード（終点）」のそれぞれの地点コードと「３５地点マスタ〔テーブルＩＤ；Ｍ＿ＣＨＩＴＥＮ〕」の「地点コード」との間には、いずれもリレーションがあるとする一方、「３７単経路マスタ〔テーブルＩＤ；Ｍ＿ＴＡＮＫＥＩＲＯ〕の「地点コード（始点）」、「地点コード（終点）」、「道路コード」のそれぞれのコードと「３８禁止経路マスタ」の「地点コード（始点）」、「地点コード（中間点）」、「地点コード（終点）」、「道路コード」、「通行禁止道路コード」との間にはリレーションを否認するので、以下検討する。 　まず、「３８禁止経路マスタ」と「３７単経路マスタ」との間にリレーションが存在しないとする被告の主張については、リレーショナル・データベースでは、各テーブルに共通するフィールドを用いて検索することになるところ、プログラムが禁止経路マスタと単経路マスタのそれぞれの「地点コード」と「道路コード」という双方のテーブルに共通するフィールドのデータを元に検索を行っていることから、体系的構成としてもテーブル間に共通のフィールドを設けるリレーションがとられていること、被告システムに用いられているSQLサーバーを管理するツールであるSQL ServerProfiterを用いた解析結果によれば、現実の電子計算機による検索でも、被告システムにおいては、禁止経路マスタの地点コード（始点）と単経路マスタの地点コード（始点）、禁止経路マスタの地点コード（中間点）と単経路マスタの地点コード（終点）、禁止経路マスタの道路コードと単経路マスタの道路コードが全て同じとなる単経路に「１」、そうでない単経路には「０」というフラグ（指標）を付けて、単経路マスタの全ての単経路について、「地点コード始点」、「地点コード終点」、「所要時間」、「距離」の各フィールドの情報及び道路マスタの「道路区分」の各フィールドの情報を取得する命令をしており、被告ＣＤＤＢ（現行版）において、「３８禁止経路マスタ」と「３７単経路マスタ」とにリレーションがあることが認められるから、「３７単経路マスタ」の「地点コード（始点）」、「地点コード（終点）」、「道路コード」のそれぞれのコードと「３８禁止経路マスタ」の「地点コード（始点）」、「地点コード（中間点）」、「地点コード（終点）」、「道路コード」、「通行禁止道路コード」との間にリレーションがあることが認められる。〔甲５８〕 したがって、被告らの上記主張は採用することができない。 (オ)　被告らは、「３６道路マスタ」の「道路コード」フィールドと「３８禁止経路マスタ」の「道路コード」フィールドとの間、「３６道路マスタ」の「道路コード」フィールドと「３８禁止経路マスタ」の「通行禁止道路コード」フィールドとの間、及び「３８禁止経路マスタ」の「地点コード（始点）」、「地点コード（中間点）」、「地点コード（終点）」のそれぞれの地点コードと「３５地点マスタ」の「地点コード」との間には、いずれもリレーションがあるとする点につき、被告らは、禁止経路は、あくまでも地点の組み合わせによりデータを取得していて単経路の組み合わせとはなっていないために、禁止経路マスタと単経路マスタは、一方が他方を包含する関係にありリレーションがある旨主張し、それに沿う証拠として、乙３１の１、２を提出する。 　乙３１の１（木暮仁著「利用部門のための情報システム設計論」１９９７年３月２日第１刷発行・株式会社日科技連出版社）には、「リレーションシップとは、たとえば『社員』と『部門』の間での、『所属する』『部員である』というような結びつきをいう．一般的には動詞である．」と、また、乙３１の２（株式会社システム・テクノロジー・アイ 林優子「プロとしてのデータモデリング入門」２００６年１１月２９日初版第１刷発行・ソフトバンク クリエイティブ株式会社）には、「リレーションシップとは、『２つのエンティティの間の意味ある関連を表現するもの』です。たとえば、部門エンティティとは社員エンティティの間には、『社員は部門に所属する』という関係が成り立ちますが。この『所属する』というのがリレーションシップです。」との記載がある。 　このうち、データモデルにおけるエンティティについては、データベースにおけるテーブルに対応するものとは認められるところ（甲６４の４）、上記乙３１の１、２に、被告らが主張する、一方が他方を包含する関係にある場合にリレーションがあるとする内容についての記載はない。 　また、リレーションシップとは、「データベースで、共通するフィールドを通じて複数のテーブルが関連付けられること。関連付けることで、複数のテーブルのレコードをひとつのテーブルのレコードのように扱える。」ことを意味するものと認められるところ（甲６４の１）、リレーションには、１対１、１対多、多対多の関係があるものと認められるから（甲６４の３、４）、包含関係があるか否かによりリレーションシップの有無を判断すべきものとは認められない。 　そして、このように、データベースにおけるリレーションシップは、テーブル間の関連付けで、具体的にリレーションシップを実現するために、各テーブルに共通するフィールドを通じて、複数のテーブルが関連付けられることをいうものであるから、テーブル間に共通するフィールドがあれば両テーブル間にはリレーションがあるものと考えられるところ、その場合、フィールドＩＤないしフィールド名が同じになることが多いものと解されるが、それらが異なっていても、同じ属性のフィールドであれば共通のフィールドとなるものと解される。 　加えて、被告ＣＤＤＢ（現行版）の「単経路マスタ」には「地点コード（始点）」、「地点コード（終点）」、「道路コード」のフィールドがあり、「禁止経路マスタ」には「地点コード（始点）」、「地点コード（中間点）」、「地点コード（終点）」、「道路コード」のフィールドがあり、単経路も禁止経路も道路コードと地点の組み合せで特定している。「単経路マスタ」でも「禁止経路マスタ」でも、道路コードのフィールドが共通であることに加え、始点、中間点、終点のいずれであれ地点コードが格納されているフィールドは地点コードという属性のデータが格納されている点で共通であるので、テーブル間にはその共通の属性のフィールドを介してリレーションがあるといえる。加えて、前記のとおり、被告ＣＤＤＢ（現行版）では、SQLサーバーの命令により、単経路マスタ、禁止経路マスタ間の共通のフィールドを使って実際の検索もされていることが認められる。 　したがって、被告らの上記主張は採用することができない。 カ　依拠性について 　被告ＣＤＤＢ（現行版）が、被告ＣＤＤＢ（当初版・２００６年版）に改変等を加える形で制作されたと認められること、上記誤記等を含む具体的な情報の同一性等に照らし、被告ＣＤＤＢ（現行版）が、原告ＣＤＤＢに依拠して作成されたことは明らかである。 　被告らは、原告ＣＤＤＢに依拠することなく、平成１８年８月に被告ＣＤＤＢを含む被告システムの制作を委託した外注先を変更し、独自に被告ＣＤＤＢ（現行版、Ver2.99）を作成したと主張し、それに沿う証拠として、外注先が作成したとするテーブル定義書（乙２２）を提出する。 　しかし、上記テーブル定義書（乙２２）には、作成者、承認者の押印欄等があり、作成日を記入する欄も設けられているにもかかわらず、１００枚以上提出されたその定義書には１枚も作成者、承認者の押印も作成日の記入もない上、平成２３年２月２１日に行われた第８回弁論準備手続期日においても、被告らにおいて、乙２２の作成者については外注先の強い希望により具体的に特定することは差し控えるなどとして乙２２の作成の経緯については何ら明らかにしないことを考慮すると、乙２２及びそれが被告ＣＤＤＢ（現行版、Ver2.99）のテーブル定義書であるとする平成２３年２月９日付け被告Ｙ１作成の報告書（乙２４）は、いずれも信用するに足りない。 　したがって、被告らの主張は上記採用することができない。 キ　被告ＣＤＤＢ（現行版）についての結論 　以上の検討によれば、被告ＣＤＤＢ（現行版）は、原告ＣＤＤＢに依拠して制作された複製物に当たると認めるのが相当である。 (5)　最後に、被告ＣＤＤＢ（新版）につき検討する。 ア　被告ＣＤＤＢ（新版）と原告ＣＤＤＢとの体系的構成の共通性 (ア)　テーブルの種類及び数 ａ　一致するマスターテーブル (a)　原告ＣＤＤＢには４２個の、被告ＣＤＤＢ（新版）には２９個のマスターテーブルがそれぞれ含まれるところ、このうち、以下の７個のマスターテーブルについては、原告ＣＤＤＢに含まれるマスターテーブルと一致することにつき争いがない。 　一致することに争いのない７個のマスターテーブルは、以下のとおりである（原告ＣＤＤＢのマスターテーブルによる表記。対応する被告ＣＤＤＢ（新版）の表記は別紙２該当欄記載のとおり）。 ・「０１市区町村テーブル」 ・「０６ＵＲＬアドレステーブル」 ・「０９地点名テーブル」 ・「１０道路テーブル」 ・「３２駅テーブル」 ・「４２会社テーブル」 ・「４３交通機関種別テーブル」 (b)　そして、原告は、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」及び「２２観光施設備考テーブル」についても、これら三つのテーブルに対応する、被告ＣＤＤＢ（新版）の「２１施設マスタ」、「２９宿泊施設マスタ」、「２３観光施設マスタ」、「２６観光料金マスタ」、「２５観光料金種別マスタ」、さらには被告ＣＤＤＢ（新版）で加わった「１３０食事土産マスタ」、「１３１施設別詳細種別マスタ」、「１３２施設種別マスタ」、「１３３施設詳細種別マスタ」は、一致するマスターテーブルである旨主張し、さらに、「０２地区・県名テーブル」は「３都道府県マスタ」と、「１１接続テーブル」は「３７単経路マスタ」と、「１２禁止乗換テーブル」は「３８禁止経路マスタ」と、「１４区間料金テーブル」は「３９区間料金マスタ」と、「１５首都高速料金テーブル」は「４０通行料金マスタ」と、「３３路線構成テーブル」は「４６路線構成マスタ」と、「３４路線テーブル」は「４３路線マスタ」と、「３６路線検索テーブル」は「４５時刻マスタ」と、「３９便テーブル」及び「４０運行日定義テーブル」は「４４便マスタ」と、それぞれ対応して被告ＣＤＤＢ（新版）に存在する旨主張する。 　まず、被告ＣＤＤＢ（新版）の「３都道府県マスタ」は、被告ＣＤＤＢ（現行版）と比較すると、被告ＣＤＤＢ（現行版）から被告ＣＤＤＢ（新版）へのバージョンアップに当たり、「３４緯度経度マスタ」を削除したことに伴い、被告ＣＤＤＢ（新版）の「３都道府県マスタ」では、「代表道路地点コード」、「緯度」、「経度」、「都道府県カナ」の各フィールドが追加されたものの、これは上記削除に伴うものであって、内容的に重要な変更はされていないものと認められることから、被告ＣＤＤＢ（現行版）と同様、「３都道府県マスタ」は原告ＣＤＤＢの対応するテーブルと実質一致するものと認められる。 　また、被告ＣＤＤＢ（新版）の「３７単経路マスタ」、「３８禁止経路マスタ」、「３９区間料金マスタ」及び「４０通行料金マスタ」それら自体は、別紙３のとおり、各フィールドを含め、被告ＣＤＤＢ（現行版）と比較して変更はないと認められるから、被告ＣＤＤＢ（現行版）と同様、「３７単経路マスタ」、「３８禁止経路マスタ」、「３９区間料金マスタ」及び「４０通行料金マスタ」は、原告ＣＤＤＢの対応するテーブルと実質的に一致するものと認められる。 　次に、被告ＣＤＤＢ（新版）の「２１施設マスタ」、「２９宿泊施設マスタ」及び「２３観光施設マスタ」は、被告ＣＤＤＢ（現行版）等と比較して詳細な情報を登録するためのフィールド（「風呂」、「バリアフリー」等）が追加されているものの、テーブル全体としては重要な変更がされていないから、被告ＣＤＤＢ（新版）の「２６観光料金マスタ」及び「２５観光料金種別マスタ」は、被告ＣＤＤＢ（現行版）と比較して変更はなく、被告ＣＤＤＢ（新版）の「２１施設マスタ」、「２９宿泊施設マスタ」、「２３観光施設マスタ」及び「２６観光料金マスタ」も、原告ＣＤＤＢの対応するテーブルと実質的に一致するものと認められる。なお、被告ＣＤＤＢ（新版）の「２５観光料金種別マスタ」は原告ＣＤＤＢに対応するテーブルが存しないことは被告ＣＤＤＢ（当初版・２００６年版）、被告ＣＤＤＢ（現行版）のときと同様である。 　そして、被告ＣＤＤＢ（新版）では、「宿泊施設マスタ」や「観光施設マスタ」と同様に、「施設マスタ」の下位のテーブルとして「１３０食事土産マスタ」が、施設の種別に関して大分類、中分類、小分類のテーブルとして、「１３２施設種別マスタ」、「１３３施設詳細種別マスタ」、「１３１施設別詳細種別マスタ」が、それぞれ追加されている。被告ＣＤＤＢ（新版）の「１３０食事土産マスタ」、「１３１施設別詳細種別マスタ」、「１３２施設種別マスタ」、「１３３施設詳細種別マスタ」と原告ＣＤＤＢの「２０ホテル・旅館テーブル」、「２１観光施設テーブル」とは、別紙３、別紙７、別紙１０（争いのあるリレーションについての判断は後記する。）のとおりの各フィールドやリレーションの内容等をみると、一部に共通するフィールドは存在しているものの、共通していない部分は、施設に関する情報を被告ＣＤＤＢ（現行版）からさらに追加可能にするものであって、施設を選択するための情報として参照可能なものであることが推認される。そうすると、これらは、原告ＣＤＤＢとは、対応しないものと認められる。 　さらに、被告ＣＤＤＢ（新版）の「４６路線構成マスタ」、「４３路線マスタ」は被告ＣＤＤＢ（現行版）と比較してフィールド内容に一部変更がされているが、被告ＣＤＤＢ（新版）では被告ＣＤＤＢ（現行版）に持たせていた料金計算のための情報を「駅すぱあと」に行わせるように設計を変更し、そのためのフィールドを設けたものであり、被告ＣＤＤＢ（新版）の「４５時刻マスタ」、「４４便マスタ」は被告ＣＤＤＢ（現行版）と比較して変更はないと思われることから、被告ＣＤＤＢ（現行版）と同様、被告ＣＤＤＢ（新版）の「４６路線構成マスタ」、「４３路線マスタ」、「４５時刻マスタ」及び「４４便マスタ」は原告ＣＤＤＢの対応するテーブルと実質的には一致するものと認められる。ただし、後記するとおり、別紙１０において、（※※）の付けられたフィールドが被告ＣＤＤＢ（新版）には新設されており、また、それに伴いリレーションの取り方も異なるものとなっている。 (c)　上記によれば、原告ＣＤＤＢと被告ＣＤＤＢ（新版）とで一致するマスターテーブルは、上記２０個であると認められる。 　なお、被告ＣＤＤＢ（当初版・２００６年版）及び被告ＣＤＤＢ（現行版）では、緯度経度情報を、「３４緯度経度マスタ」とその他のテーブルの「４市区町村マスタ」、「２１施設マスタ」、「３５地点マスタ」、「４７駅マスタ」で重複して保有しており、原告ＣＤＤＢと同様となっていたところ、被告ＣＤＤＢ（新版）では「３４緯度経度マスタ」のテーブルが削除されている。また、被告らは、それまで、「３４緯度経度マスタ」とリレーションを取っていたが、実質的に利用していなかった「３２ＵＲＬ種別マスタ」、「３３ＵＲＬ分類マスタ」も削除した。 ｂ　一致しないマスターテーブル 　前記のとおり、被告ＣＤＤＢ（新版）の「２５観光料金種別マスタ」は、原告ＣＤＤＢに対応するマスターテーブルが存在せず、「１３０食事土産マスタ」、「１３１施設別詳細種別マスタ」、「１３２施設種別マスタ」及び「１３３施設詳細種別マスタ」についても、被告ＣＤＤＢ（新版）において新たに設けられたマスターテーブルであって、一致するものは原告ＣＤＤＢには存しない。 　また、被告ＣＤＤＢ（新版）の「１３４提携施設マスタ」、「１３５提携種別マスタ」、「１３６提携会社マスタ」及び「１３７単経路補間マスタ」についても、原告ＣＤＤＢに対応するマスターテーブルが存在しない。 　そして、原告ＣＤＤＢのマスターテーブルのうち、「０３方面テーブル」、「０４方面設定テーブル」については、被告システムでは、方面検索の機能がないため、対応するテーブルが存在しない。 　さらに、原告ＣＤＤＢのマスターテーブルのうち、被告ＣＤＤＢ（新版）においては、原告ＣＤＤＢの「０５緯度経度テーブル」について、対応するテーブルが存在しない。 　その他、被告ＣＤＤＢ（新版）では、原告ＣＤＤＢの、「０７ＵＲＬ種別テーブル」、「０８ＵＲＬ分類テーブル」、「１３有料道路番号テーブル」、「１６道路構成地点テーブル」、「１７道路構成地点索引テーブル」、「１８市区町村通過道路索引テーブル」、「１９県範囲定義テーブル」、「２８協定施設テーブル」、「２９券種テーブル」、「３０協定旅館テーブル」、「３１連結協定テーブル」、「３５時刻表料金テーブル」、「３７路線検索索引テーブル」、「３８路線タイプテーブル」、「４１時刻テーブル」、「４４地方別会社索引テーブル」、「４５検索地方範囲定義テーブル」、「４６地方別路線索引テーブル」及び「４７駅通過線索引テーブル」についても、被告ＣＤＤＢ（新版）に対応するマスターテーブルが存在しない。 (イ)　被告ＣＤＤＢ（新版）の各テーブルに存在するフィールドの種類及び数原告ＣＤＤＢには４２個のテーブルに、４０５個のフィールドが存するところ、被告ＣＤＤＢ（新版）の各テーブルに存在するフィールドは別紙３記載のとおりであり、２９個のテーブルに３２６個のフィールドが存する。 　前記のとおり原告ＣＤＤＢのマスターテーブルと一致する被告ＣＤＤＢ（新版）の２０個のテーブルにおけるフィールド項目については、別紙３記載のとおり、一致するテーブルに存するフィールドは２９４個である。 　フィールドのうち、「作成日時」、「更新日時」及び「削除区分」のフィールドは、データ更新やテーブル管理を行うための管理項目であり、データベースの検索機能や提供データの内容自体に影響を及ぼす性質のものではない。〔甲３、７頁〕 　このうち、被告ＣＤＤＢ（新版）における、ほぼ各テーブル（マスタ）に存在する「登録日時（作成日時）」、「更新日時（更新日時）」及び「削除区分（削除区分）」のフィールドを除くと、原告ＣＤＤＢと被告ＣＤＤＢ（新版）とで一致するフィールド数のうち、別紙３のとおり、１３３個が、原告ＣＤＤＢと一致している。 (ウ)　テーブル間の関連付け 　別紙３のとおり、原告ＣＤＤＢと被告ＣＤＤＢ（新版）とでは、原告ＣＤＤＢのマスターテーブルと一致する２０個のテーブルに関して、プライマリー・キーの設定につき、原告ＣＤＤＢの「０２地区・県名テーブル」の「地区コード」フィールド、原告ＣＤＤＢの「０６ＵＲＬアドレステーブル」の「テーブル種別」・「種別毎キー」フィールド、原告ＣＤＤＢの「１１接続テーブル」の「接続番号」フィールド（被告ＣＤＤＢ（新版）では、「３７単経路マスタ」の「地点コード（始点）（地点番号＿始点）」、「地点コード（終点）（地点番号＿終点）」及び「道路コード（道路番号）」の三つのフィールドにプライマリー・キーが設定されている。）、原告ＣＤＤＢの「１２禁止乗換テーブル」の「乗換元接続番号」フィールド（被告ＣＤＤＢ（新版）では、「３８禁止経路マスタ」の「地点コード（始点）（地点番号＿始点）」、「道路コード（道路番号）」、「地点コード（中間点）（地点番号中間）」「地点コード（終点）（地点番号＿終点）」及び「通行禁止道路コード（道路番号＿禁止）」の五つのフィールドにプライマリー・キーが設定されている。）、被告ＣＤＤＢ（新版）の「３９区間料金マスタ」及び「４０通行料金マスタ」の各「道路料金区分（道路料金区分）」フィールドを除き、一致したフィールドないし同一のテーブルの同種フィールドにプライマリー・キーが設定されている。 　これらによれば、被告ＣＤＤＢ（新版）におけるテーブル間のリレーションに関しては、別紙１０の青丸と青丸を結ぶ黒線（黒太線を含む）及び黒点線のとおりと認められる。 　なお、この点につき、被告らは、被告ＣＤＤＢ（新版）の「３６道路マスタ〔テーブルＩＤ；Ｍ＿ＤＯＲＯ〕」の「道路コード」フィールドと「３８禁止経路マスタ〔テーブルＩＤ；Ｍ＿ＫＩＮＳＩＫＥＩＲＯ〕」の「道路コード」フィールドとの間、「３６道路マスタ」の「道路コード」フィールドと「３８禁止経路マスタ」の「通行禁止道路コード」フィールドとの間、及び、「３８禁止経路マスタ」の「地点コード（始点）」、「地点コード（中間点）」、「地点コード（終点）」のそれぞれの地点コードと「３５地点マスタ〔テーブルＩＤ；Ｍ＿ＣＨＩＴＥＮ〕」の「地点コード」との間には、いずれもリレーションがあるとする一方（別紙１０に赤丸と赤丸を結ぶ赤点線で記載されたリレーション）、「３７単経路マスタ〔テーブルＩＤ；Ｍ＿ＴＡＮＫＥＩＲＯ〕」の「地点コード（始点）」、「地点コード（終点）」、「道路コード」のそれぞれのフィールドと「３８禁止経路マスタ」の「地点コード（始点）」、「地点コード（中間点）」、「地点コード（終点）」、「道路コード」、「通行禁止道路コード」との間のリレーションを否認する（別紙１０に青丸と青丸を結ぶ黒点線で記載されたリレーション）ので、以下、検討する。 　まず、「３８禁止経路マスタ」と「３７単経路マスタ」との間にリレーションが存在しないとする被告の主張については、被告システムに用いられているSQLサーバーを管理するツールであるSQL Server Profiterを用いた解析結果によれば、被告ＣＤＤＢ（新版）においても、「３８禁止経路マスタ」と「３７単経路マスタ」とにリレーションがあることが認められるから、これと各テーブルのフィールドの内容からすれば、上記「３７単経路マスタ」の「地点コード（始点）」、「地点コード（終点）」、「道路コード」のそれぞれのフィールドと「３８禁止経路マスタ」の「地点コード（始点）」、「地点コード（中間点）」、「地点コード（終点）」、「道路コード」、「通行禁止道路コード」との間にリレーションがあることが認められる。これらの詳細は前記被告ＣＤＤＢ（現行版）における判断と同様である。〔甲５８〕 次に、「３６道路マスタ」の「道路コード」フィールドと「３８禁止経路マスタ」の「道路コード」フィールドとの間、「３６道路マスタ」の「道路コード」フィールドと「３８禁止経路マスタ」の「通行禁止道路コード」フィールドとの間、及び「３８禁止経路マスタ」の「地点コード（始点）」、「地点コード（中間点）」、「地点コード（終点）」のそれぞれの地点コードのフィールドと「３５地点マスタ」の「地点コード」フィールドとの間には、いずれもリレーションがあるとする点につき、被告らは、禁止経路は、あくまでも地点の組み合わせによりデータを取得していて単経路の組み合わせとはなっていないために、禁止経路マスタと単経路マスタは、一方が他方を包含する関係にあるから、リレーションがある旨主張する。 しかし、包含関係があるか否かによりリレーションの有無が判断されるものとは認められないことは前記被告ＣＤＤＢ（現行版）についての判断と同様である。 また、被告ＣＤＤＢ（新版）では、被告ＣＤＤＢ（現行版）と同様、原告ＣＤＤＢの「２０ホテル・旅館テーブル」、「２１観光施設テーブル」及び「２２観光施設備考テーブル」の３テーブルに対応するテーブルとして、被告ＣＤＤＢ（新版）では「２１施設マスタ」、「２９宿泊施設マスタ」、「２３観光施設マスタ」及び「２６観光料金マスタ」の４テーブルを設けているところ、原告ＣＤＤＢにおける「０１市区町村テーブル」が「２０ホテル・旅館テーブル」、「２１観光施設テーブル」の二つのテーブルとリレーションを取っていることに対して、被告ＣＤＤＢ（新版）では「４市区町村マスタ」は、原告ＣＤＤＢの「２０ホテル・旅館テーブル」、「２１観光施設テーブル」の共通項目を括りだした上位のテーブルとなっている被告ＣＤＤＢ（新版）の「２１施設マスタ」の一つのテーブルとのみリレーションを取っている。これにより、これと関連するリレーションの線がその分少なくなっている。 (エ) 一方で、被告ＣＤＤＢ（新版）では、前記のとおり、被告ＣＤＤＢ（現行版）に比して、原告ＣＤＤＢと一致しないテーブルである、「１３０食事土産マスタ」、「１３１施設別詳細種別マスタ」、「１３２施設種別マスタ」、「１３３施設詳細種別マスタ」、「１３４提携施設マスタ」、「１３５提携種別マスタ」、「１３６提携会社マスタ」及び「１３７単経路補間マスタ」が追加されている。 　まず、「１３０食事土産マスタ」は、下位テーブルである類型別のマスターテーブルとして新たに追加するものであり、具体的には、食事処及び土産施設の情報充実を図るものである。これは観光施設、宿泊施設にかかわらず、ドライブインや名産品の土産店などのように、食事のためや土産物を購入するためにだけ立ち寄ることができる施設があり、観光施設や宿泊施設から独立させて、これらに特化した情報である開館・閉館時間や、食事内容、土産内容等に関する検索機能を充実させることへの利用者（顧客）からの要望に応えるために設置されたものである。 　また、「１３１施設別詳細種別マスタ」、「１３２施設種別マスタ」及び「１３３施設詳細種別マスタ」は、被告ＣＤＤＢ（現行版）においては、観光施設の種別につき、「施設マスタ」中の「観光種別」のフィールド、「観光種別マスタ」と「観光詳細種別マスタ」で格納していたのに対し、宿泊施設と公共施設の種別については、施設マスタの中の「宿泊種別」「公共施設種別」のフィールドのみで格納しており、これら施設によって施設の種別の格納の仕方が異なっていたが、被告ＣＤＤＢ（新版）では、これを一元的に整理し格納するため、施設の種別については、観光施設、宿泊施設、公共施設、被告ＣＤＤＢ（新版）で追加された食事処及び土産施設のいずれも、「１３２施設種別マスタ」、「１３３施設詳細種別マスタ」及び「１３１施設別詳細種別マスタ」の三つのテーブルで格納することとした。これに伴って、被告ＣＤＤＢ（現行版）の「観光種別マスタ」及び「観光詳細種別マスタ」は削除された。 　これら情報の格納の詳細については、まず、施設を「宿泊」、「観光」、「公共」及び「食事・土産」の四つに大分類し、次に、そこから施設種別の中分類として施設種別マスタを用意し、さらに、小分類として施設詳細種別マスタを用意している。〔乙２６〕 　これにより、例えば、ある一つの施設が神社・仏閣としても博物館としても分類されるような複合的な施設種別を持つ場合において、当該施設に割り当てられた一つの施設コードを使って、神社・仏閣としても博物館としても検索できるような構造とした。 　また、「１３４提携施設マスタ」、「１３５提携種別マスタ」及び「１３６提携会社マスタ」は、宿泊施設や観光施設等が、大手旅行会社や全国旅行業協会、旅行案内所などと提携している施設か否か、宿泊クーポンや食事クーポン等のクーポンを利用できる施設か否か、各会社のクーポンを発券できる施設か否かといった情報を新たに格納したものであり、これらも利用者からの要望に応えるものである。 イ　被告ＣＤＤＢ（新版）の体系的構成が、原告ＣＤＤＢの複製又は翻案に当たるか (ア)　上記のとおり、原告ＣＤＤＢと被告ＣＤＤＢ（新版）とでは、原告ＣＤＤＢにおける、「０１市区町村テーブル」、「０２地区・県名テーブル」、「０６ＵＲＬアドレステーブル」、「０９地点名テーブル」、「１０道路テーブル」、「１１接続テーブル」、「１２禁止乗換テーブル」、「１４区間料金テーブル」、「１５首都高速料金テーブル」、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「２２観光施設備考テーブル」、「３２駅テーブル」、「３３路線構成テーブル」、「３４路線テーブル」、「３６路線検索テーブル」、「３９便テーブル」、「４０運行日定義テーブル」、「４２会社テーブル」及び「４３交通機関種別テーブル」の２０個のテーブルにつき、これと一致するテーブルが被告ＣＤＤＢ（新版）にも存する。 　しかし、これら一致するテーブルについても、フィールドの構成やリレーションのとり方には、被告ＣＤＤＢ（現行版）と異なる点があることは後記のとおりである。 　また、被告ＣＤＤＢ（新版）の全フィールド数は、３２６個であるところ、原告ＣＤＤＢと被告ＣＤＤＢ（新版）とで一致するフィールドは１３３個である。 　さらに、テーブル間の関連付けについては、原告ＣＤＤＢと被告ＣＤＤＢ（新版）とのリレーションの関係を対比すると、別紙７、１０のとおりであり、被告ＣＤＤＢ（新版）では、別紙１０の青丸と青丸を結ぶ黒太線で示されている、「４市区町村マスタ」の「代表道路地点コード」フィールドと、「２１施設マスタ」の「代表道路地点コード」フィールド、「３５地点マスタ」の「地点コード」フィールド、「４７駅マスタ」の「代表道路地点コード」フィールドとのリレーションについては被告ＣＤＤＢ（現行版）から引き続いて存在するものの、「３４緯度経度マスタ」、「３２ＵＲＬアドレスマスタ種別マスタ」、「３３ＵＲＬ分類マスタ」を削除したことに伴い、これらとのリレーションが消滅している。 　そして、被告ＣＤＤＢ（新版）において、「１３０食事土産マスタ」、「１３１施設別詳細種別マスタ」、「１３２施設種別マスタ」、「１３３施設詳細種別マスタ」、「１３４提携施設マスタ」、「１３５提携種別マスタ」、「１３６提携会社マスタ」及び「１３７単経路補間マスタ」が新設されたことに伴い、これら相互のリレーションのほか、被告ＣＤＤＢ（現行版）にも存した、「３７単経路マスタ」、「２１施設マスタ」、「２９宿泊施設マスタ」との間で、新たなリレーションも多数発生している。 (イ)　前記認定のとおりの、原告ＣＤＤＢと被告ＣＤＤＢ（新版）との間で一致するテーブルについて詳しくみると、原告ＣＤＤＢでは、「０１市区町村テーブル」、「３２駅テーブル」、「２０ホテル・施設テーブル」、「２１観光施設テーブル」、「０９地点名テーブル」、「１１接続テーブル」及び「１０道路テーブル」により、出発地、経由地、目的地に面した道路に関するデータの検索を可能にし、また、「０９地点名テーブル」、「１０道路テーブル」、「１１接続テーブル」、「１２禁止乗換テーブル」、「１４区間料金テーブル」及び「１５首都高速料金テーブル」により、道路を利用した移動に関する経路探索・料金の算出に必要なデータの検索を可能にしている。 　しかし、これらと対応する被告ＣＤＤＢ（新版）のテーブルをみると、新たなテーブルとして、「１３７単経路補完マスタ」が「３７単経路マスタ」とリレーションをとる形で設けられ、従来設けられていた「３４緯度経度マスタ」とのリレーションも消滅している。 　また、原告ＣＤＤＢでは、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「２２観光設備備考テーブル」及び「０６ＵＲＬアドレステーブル」により、ホテル・旅館、観光施設に関する情報を検索することを可能にしているものであるが、被告ＣＤＤＢ（新版）では、新たに「１３０食事土産マスタ」が設けられているほか、「２９宿泊施設マスタ」、「２３観光施設マスタ」においても、別紙１０の各テーブル内に（※※）が記載されたフィールドに示されているとおり、相当の数の新設フィールドが設置されているし、「２１施設マスタ」、「２９宿泊施設マスタ」は、いずれも新設テーブルである「１３１施設別詳細種別マスタ」、「１３２施設種別マスタ」、「１３３施設詳細種別マスタ」、「１３４提携施設マスタ」、「１３５提携種別マスタ」、「１３６提携会社マスタ」との新たなリレーションがとられている。 　さらに、原告ＣＤＤＢでは、「３２駅テーブル」、「３３路線構成テーブル」、「３４路線テーブル」、「３６路線検索テーブル」、「３９便テーブル」、「４０運行日定義テーブル」、「４２会社テーブル」及び「４３交通機関種別テーブル」により、公共交通機関を利用した経路探索に必要なデータの検索を可能にしているが、それらに対応する被告ＣＤＤＢ（新版）の「４３路線マスタ」、「４７駅マスタ」には「駅すぱあと」との連動のためのフィールドが設けられ、また「４６路線構成マスタ」に「出発駅コード」、「到着駅コード」の各フィールドが設けられたことに伴い、「４７駅マスタ」とのリレーションにも変化がある。 　そして、原告ＣＤＤＢの「０１市区町村テーブル」、「０２地区・県名テーブル」は、道路と地図を関連付ける情報として、地図から検索をするときに用いられるものであるが、検索対象となる宿泊・観光施設や経路等との結びつきが重要であるとみられるところ、前記のとおり、これらの施設や経路等についてのテーブル、フィールド及びそれらについてのリレーションに関し、相当な変更が被告ＣＤＤＢ（新版）ではされているものといえる。 (ウ)　以上によれば、被告ＣＤＤＢ（新版）においては、被告ＣＤＤＢ（新版）が原告ＣＤＤＢと共通性を有する部分のうち、「０１市区町村テーブル」、「３２駅テーブル」、「２０ホテル・施設テーブル」、「２１観光施設テーブル」、「０９地点名テーブル」、「１１接続テーブル」及び「１０道路テーブル」により、出発地点、経由地、目的地に面した道路に関するデータの検索を可能にし、「０９地点名テーブル」、「１０道路テーブル」、「１１接続テーブル」、「１２禁止乗換テーブル」、「１４区間料金テーブル」及び「１５首都高速料金テーブル」により、道路を利用した移動に関する経路探索を行うことを可能にしている点では、なお原告ＣＤＤＢの創作的表現の本質的な特徴を直接感得することができる部分があるということができそうにも思われる。 (エ)　しかし、出発地、経由地、目的地に面した代表道路地点に関連して、その緯度経度情報による経路探索を行うことを可能とする被告ＣＤＤＢ（新版）の「４市区町村マスタ」（原告ＣＤＤＢの「０１市区町村テーブル」）、「４７駅マスタ」（原告ＣＤＤＢの「３２駅テーブル」）、「２１施設マスタ」（原告ＣＤＤＢの「２０ホテル・施設テーブル」、「２１観光施設テーブル」）、「３５地点マスタ」（原告ＣＤＤＢの「０９地点名テーブル」）の各テーブル及びこれらを結ぶリレーション(別紙１０の青丸と青丸を結ぶ黒太線)、これと関連する、「３７単経路マスタ」（原告ＣＤＤＢの「１１接続テーブル」）、「３６道路マスタ」（原告ＣＤＤＢの「１０道路テーブル」）、「３８禁止経路マスタ」（原告ＣＤＤＢの「１２禁止乗換テーブル」）との別紙１０記載のリレーションについては、それらを構成するテーブル、リレーションは、被告ＣＤＤＢ（新版）の全体のフィールド数、リレーションのとり方からみると、ごく一部となってしまっている上に、新たに設けられたテーブルである、「１３７単経路補完マスタ」、「１３０食事土産マスタ」、「１３１施設別詳細種別マスタ」、「１３２施設種別マスタ」、「１３３施設詳細種別マスタ」、「１３４提携施設マスタ」、「１３５提携種別マスタ」、「１３６提携会社マスタ」等との間に新たなリレーションがとられている。そして、これら新設テーブルについては、上記各テーブルに含まれるフィールドの内容や機能等からすれば、これら被告ＣＤＤＢ（新版）において、新たな創作的表現として加えられたことを肯定できる。 　そうすると、従前の一致部分が削除されたり、新たな創作的表現が付け加えられたりしている被告ＣＤＤＢ（新版）全体からみた場合には、原告ＣＤＤＢと共通性を有する部分は、被告ＣＤＤＢ（新版）の全体の中からみれば、もはや原告ＣＤＤＢの表現の本質的な特徴を直接感得することができなくなっていると認めるのが相当である。 　そうすると、被告ＣＤＤＢ（新版）は、もはやその体系的構成において、原告ＣＤＤＢの複製ないし翻案には該当しないというべきである。 ウ　被告ＣＤＤＢ（新版）と原告ＣＤＤＢとの情報の選択の共通性 (ア)　フィールド項目の選択の類似性 　前記のとおり、テーブル管理のためのフィールドである「登録日時」、「更新日時」及び「削除区分」等のフィールドを除いた被告ＣＤＤＢ（新版）のフィールド数２１９個のうち１４６個が原告ＣＤＤＢのフィールドと一致している。 　一方、被告ＣＤＤＢ（新版）では、「３都道府県マスタ」テーブルに「代表道路地点コード」、「緯度」、「経度」等のフィールドを新設した。 　また、被告ＣＤＤＢ（新版）では、「４７駅マスタ」テーブルに「駅名（駅すぱあと）」フィールドを、「４６路線構成マスタ」テーブルに「出発駅コード」及び「到着駅コード」フィールドを、「４３路線マスタ」テーブルに「駅すぱあと収録区分」及び「集約路線コード」フィールドをそれぞれ新設した。 　これらの新設フィールドについては、原告ＣＤＤＢに対応するフィールドが存しない。 　さらに、被告ＣＤＤＢ（新版）において新設したテーブルについては、原告ＣＤＤＢに対応するテーブルが存しないところ、その詳細は以下のとおりである。 　被告ＣＤＤＢ（新版）における新設テーブルである、「１３２施設種別マスタ」には、ホテル、旅館、ビジネス、名所旧跡・公園景観等、１８の施設種別名の情報が格納されており、別紙３のとおり、フィールドは「施設種別名」、「表示順」、「施設大種別」、「施設種別」、「更新日時」、「作成日時」及び「削除区分」の７個である。〔乙２６〕 　同じく新設テーブルである「１３３施設詳細種別マスタ」には、ホテル、旅館、ビジネス、史跡、庭園、歴史的建造物等、６０の施設詳細種別名の情報が格納されており、別紙３のとおり、フィールドは、「施設種別」、「施設詳細種別名」、「施設大種別」、「表示順」、「作成日時」、「更新日時」及び「削除区分」の７個である。〔乙２６〕 　新設テーブルである「１３１施設別詳細種別マスタ」には、「かんぽの宿小樽」以下、１５万件余りの旅館、施設等の施設名の情報が格納されており、フィールドは、「施設種別」、「施設大種別」、「更新日時」、「作成日時」及び「削除区分」の５個である。 　同じく新設テーブルである「１３４提携施設マスタ」には観光施設、食事施設等５０００件余りの施設の情報が格納されており、別紙３のとおり、フィールドは、「施設コード」、「提携会社コード」、「提携種別」、「提携施設コード」、「更新日時」、「削除日時」及び「作成日時」の７個である。〔乙２６〕 　新設テーブルである「１３５提携種別マスタ」には６件の情報が格納されており、別紙３のとおり、フィールドは、「表示順」、「提携会社コード」、「提携種別」、「提携種別名」、「更新日時」、「削除区分」及び「作成日時」の７個である。〔乙２６〕 　新設テーブルである「１３６提携会社マスタ」には１件の情報しか格納されていないが、別紙３のとおり、フィールドは、「表示順」、「提携会社コード」、「提携会社名」、「更新日時」、「削除区分」及び「作成日時」の６個である。〔乙２６〕 　新設テーブルである「１３７単経路補間マスタ」は、道路に関し、地図上に表示するルート検索結果の経路表示を地図上の道路に沿った曲線のように画面上に表示するための座標データとして、１万７０００件余りの情報が格納され、別紙３のとおり、フィールドは、「地点コード（始点）」、「地点コード（終点）」、「道路コード」、「緯度」、「経度」、「更新日時」、「連番」、「削除区分」及び「作成日時」の９個であり、このうち、「地点コード（始点）」、「地点コード（終点）」、「道路コード」及び「連番」のフィールドにプライマリー・キーが設定されている。〔乙２６〕 　「１３７単経路補間マスタ」は、「３７単経路マスタ」に格納された地点間を結ぶ情報につき、行程表において単経路マスタの情報を使用して地図上の移動経路を印刷するところ、地点間の距離が離れるほど、地図上の移動経路の印刷が直線的になるので、「単経路マスタ」の経路情報をさらに詳細なものとして、「１３７単経路補間マスタ」に収録することとしたものである。これにより、上記のとおり、行程表の移動経路の印刷を、実際の道路に近い、きめ細かなものとするためのテーブルである。 (イ)　レコードの選択の類似性 　被告らは、被告ＣＤＤＢ（当初版・２００６年版）において、原告ＣＤＤＢのテーブルのうち、以下の２０個のテーブルに含まれるレコードをコピーして用いたことを認めていた。 　そのテーブルとは、「２０ホテル・旅館テーブル」、「２１観光施設テーブル」、「０５緯度経度テーブル」、「０６ＵＲＬアドレステーブル」、「０７ＵＲＬ種別テーブル」、「０８ＵＲＬ分類テーブル」、「０１市区町村テーブル」、「０２地区・県名テーブル」、「０９地点名テーブル」、「１０道路テーブル」、「１１接続テーブル」、「１２禁止乗換テーブル」、「１３有料道路番号テーブル」、「１４区間料金テーブル」、「１５首都高速料金テーブル」、「１６道路構成地点テーブル」、「１７道路構成地点索引テーブル」、「１８市区町村通過道路索引テーブル」、「１９県範囲定義テーブル」及び「３２駅テーブル」である。 　このうち、被告らは、被告ＣＤＤＢ（現行版）までに、被告ＣＤＤＢ（当初版・２００６年版）において存在した、原告ＣＤＤＢの「１３有料道路番号テーブル」、「１６道路構成地点テーブル」、「１７道路構成地点索引テーブル」、「１８市区町村通過道路索引テーブル」及び「１９県範囲定義テーブル」の５個のテーブルと対応するテーブルは削除したとしている。 　また、被告らは、被告ＣＤＤＢ（現行版）においてはレコード数がゼロであったにもかかわらず維持されていた、原告ＣＤＤＢの「０７ＵＲＬ種別テーブル」、「０８ＵＲＬ分類テーブル」に対応する「３２ＵＲＬ種別マスタ」、「３３ＵＲＬ見出しマスタ（被告ＣＤＤＢ（現行版）ではＵＲＬ分類マスタ）」の２個のテーブルについて、被告ＣＤＤＢ（新版）では削除した。 　さらに、重複保有となっていた「３４緯度経度マスタ」について、被告ＣＤＤＢ（現行版）において公共施設７万件余りを追加し、総レコード数を１８万件余りとしていたところ、このテーブルについても削除した。 　原告ＣＤＤＢの「２０ホテル・旅館テーブル」及び「２１観光施設テーブル」と対応する被告ＣＤＤＢ（新版）の「２９宿泊施設マスタ」、「２１施設マスタ」、「２３観光施設マスタ」についても、被告ＣＤＤＢ（現行版）と比して、レコードの追加削除等を行っている。 　その他、「３５地点マスタ」、「３６道路マスタ」、「３７単経路マスタ」、「３８禁止経路マスタ」、「３９区間料金マスタ」、「４０通行料金マスタ」及び「４７駅マスタ」については、被告ＣＤＤＢ（現行版）から、それぞれレコードの追加削除等を行った。 (ウ)　具体的な情報の同一ないし類似性 a　地点名テーブルの道路情報 　原告ＣＤＤＢ（２００６年１１月版）の「０９地点名テーブル」には、１万２８２２件のレコードが収録され、被告ＣＤＤＢ（新版）では、「３５地点マスタ」には、そのうちの９２．６％である１万１８７２件につき、一致する道路地点（前記同様、「関ＪＣＴ（伊勢自動車道・名阪国道）」、「芸濃ＩＣ（伊勢自動車道、県道１０号）」等）のレコードが収録されている。〔甲３２〕 b　緯度経度情報の一致 　そして、原告ＣＤＤＢの「０９地点名テーブル」の上記道路地点の緯度経度情報は、前記のとおり、原告ＣＤＤＢ作成時に、作成者自身がパソコンのマウスを地図上でクリックする方法で選択した場所について、これを０．１秒単位で緯度経度を測定して数値化したものであるところ、被告ＣＤＤＢ（新版）も、６ないし７桁の数値で緯度経度情報を収録しているところ、上記道路地点のうち、この６桁ないし７桁で表される緯度及び経度情報につき、これと原告ＣＤＤＢ（２００６年１１月版）との完全一致率は８．１％であり、１０３３件の一致するレコードが収録されている。〔甲２２、２８、３２、３９、７０〕 　これについては、被告システム（現行版）Ver2.94 までは、緯度経度情報は、原告ＣＤＤＢのものを全て流用していたものであるが、その後、原告からの訴訟提起を受けて、見直した結果であるとする。〔証人Ａ尋問調書２０頁〕 ｃ　選択道路の一致 　原告ＣＤＤＢは、前記のとおり、大型観光バスでの移動に適した道路の選択を行っており、多くの道道、県道等の中から北海道では８０道道、福岡県では４７県道を選択しているところ、被告ＣＤＤＢ（新版）では、北海道については全データが１７１件となり、原告ＣＤＤＢと同じ道道は７９個を、福岡県では全データが１２３件となり、これと一致する県道のうち４２県道を、それぞれ選択している。〔甲４８〕 ｄ　その他の情報の一致 (a)　地点名テーブルについて 　被告ＣＤＤＢ（現行版）に存在した原告ＣＤＤＢと同じ誤りについては、被告らは、被告ＣＤＤＢ（新版）で修正した。〔甲２１〕 (b)　道路テーブルについて 　被告ＣＤＤＢ（現行版）には原告ＣＤＤＢと同じ誤りが存したが、被告らは、被告ＣＤＤＢ（新版）から道路名の読み仮名である「道路カナ」のフィールド自体を削除した。 　また、原告ＣＤＤＢと一致するダミーデータ「＊＊＊」（道路名）、「ン ダミー」（道路名の読み）についても、被告らは、被告ＣＤＤＢ（新版）において削除している。〔甲２１〕 (c)　ホテル・旅館テーブルについて �@　宿泊施設の読み仮名に関しては、原告ＣＤＤＢと同じ誤りが被告ＣＤＤＢ（新版）にも存在する。原告ＣＤＤＢでは宿泊施設名の読み仮名について長音符「ー」とすべきを誤って数字記号マイナス「−」で登録した場合が相当数あるが、これらと同じ誤りが被告ＣＤＤＢ（新版）にも存在する。具体的には、前記(3)カ(ア)g(a)記載のとおりである。 �A　宿泊施設名の読み仮名に関して、原告ＣＤＤＢと同じ誤り（施設カナ）が被告ＣＤＤＢ（新版）にも存在する。具体的には、前記(3)カ(ア)g(b)記載のとおりである。〔甲６５の別紙１３〕 (d)　観光施設テーブルについて �@　観光施設の読み仮名に関して原告ＣＤＤＢと同じ誤りが被告ＣＤＤＢ（新版）にも存在する。原告ＣＤＤＢでは観光施設名の読み仮名について長音符「ー」とすべきを誤って数字記号マイナス「−」で登録した場合が相当あるが、これと同じ誤りが被告ＣＤＤＢ（新版）にも存在する。以下は読み仮名に長音符「ー」とマイナス記号「−」が混用されている前記(3)カ(アh(b)記載の例のほか、同様の事例が存在を示すものである。 　なお、宿泊施設名称の読み仮名に関し、原告ＣＤＤＢでは、宿泊施設名に「英字」「数字」を含む場合、「英字」「数字」についてもきちんと読み仮名で表記されているものと、読み仮名に「英字」「数字」がそのまま残っているものが混用されており、被告ＣＤＤＢ（現行版）にも同じ混用状態が存在していた。この点につき、被告ＣＤＤＢ（新版）では、原告ＣＤＤＢの施設名称「美利河Ｉ遺跡」（「Ｉ」は英字のアイ）の誤りにつき、被告ＣＤＤＢ（新版）は、被告ＣＤＤＢ（現行版）において原告ＣＤＤＢと一致する誤り（英字の「Ｉ」）の登録を訂正した。〔甲６５の別紙１４〕 �A　株式会社、有限会社の施設名やその読み仮名に関する原告ＣＤＤＢの不統一の表記や誤りと同じ不統一の表記や誤りが被告ＣＤＤＢ（新版）に存在する。 　原告ＣＤＤＢは、株式会社や有限会社といった法人の種別について、施設名とそのカナについて不統一な表記を行っている。 　原告ＣＤＤＢの以下の二つのパターンと同様のデータの事例が被告ＣＤＤＢ（新版）にも存在する。〔甲６５の別紙１８〕 ・ 施設名を株式会社とし、カナをサブシキカイシャと誤って表記する ・ 施設名を（株）とし、カナをカブと表記する �B　観光施設名の読み仮名表記に原告ＣＤＤＢと同じ誤り（「ひらがなが混じる」、「漢字が混じる」など）が被告ＣＤＤＢ（新版）にも存在する。被告ＣＤＤＢ（現行版）と同じ以下の例のほか、他にも事例がある。〔甲６５の別紙１９〕 ・施設名：光大寺の湯 　施設カナ：コウダイジのユ ・施設名：霞間ヶ渓スポーツ公園 　施設カナ：カマガタニスポ−ツ公園 　なお、以下の例については、被告ＣＤＤＢ（新版）においては訂正されている。 ・施設名：航空博物館（誤記である施設カナ：コウクウガクブツアｋン） ・施設名：スパガーデンコートピア（誤記である施設カナ：スパガ−デンコ＾−トピア） (エ)　新たなテーブルへの情報の格納 　前記のとおり、被告ＣＤＤＢ（新版）においては、新設テーブルとして、「１３１施設別詳細種別マスタ」、「１３２施設種別マスタ」、「１３３施設詳細種別マスタ」、「１３４提携施設マスタ」、「１３５提携種別マスタ」、「１３６提携会社マスタ」及び「１３７単経路補間マスタ」が設けられており、「１３１施設別詳細種別マスタ」には、１５万件余りの旅館、施設等の施設名の情報が、「１３４提携施設マスタ」には観光施設、食事施設等５０００件余りの施設の情報が格納されている。 　また、被告ＣＤＤＢ（新版）における新設テーブルである「１３０食事土産マスタ」には、別紙４のとおり、株式会社全旅クーポン事業部発行の「全国『観光・運輸』総合カタログ２０１１年」に掲載されたドライブインなどの食事施設、土産物店などの情報１万０６９５件が、新たに格納されている。エ　被告ＣＤＤＢ（新版）の情報の選択が、原告ＣＤＤＢの複製又は翻案に当たるか (ア)　原告ＣＤＤＢと被告ＣＤＤＢ（新版）との情報の選択の類似性に関し、情報の選択項目であるテーブル、フィールドについて、原告ＣＤＤＢと被告ＣＤＤＢ（新版）とを比較すると、前記のとおり、被告ＣＤＤＢ（新版）の全テーブル数が２９個であるところ、一致するテーブルはそのうちの２０個であり、フィールド数に関しては、全フィールド数が３２６個であるところ、一致するフィールドは１３３個である。 　そして、被告ＣＤＤＢ（新版）においては、前記のとおり、相当の数の新たなテーブルが設置され、既存のテーブルについても、詳細化するフィールドの追加が相当数されている。 　例えば、地点名テーブルの道路情報については、相当数の地点が一致しているが、これは前記のように、「関ＪＣＴ」や「芸濃ＩＣ」等、インターチェンジ自体を選ぶというものであるから、それら重要地点を選ぶ必然性が高く、また、これら一致する道路地点の選択が、相当に幅のある中から１万件余りの情報を選択したことについての証拠はない。 　具体的な道路地点についての緯度経度情報の完全一致率についても、被告ＣＤＤＢ（現行版）と比して大幅に低下し、一致率は１０％に満たない。 　また、選択道路についても、被告ＣＤＤＢ（新版）の全データに比較して、原告ＣＤＤＢと一致する選択道路の割合でみた場合には半分以下となっている。 　さらに、被告ＣＤＤＢ（新版）の全レコード数は、別紙４のとおり約２７０万件にも及び、原告ＣＤＤＢとは、その情報量に相当の隔たりがある。 (イ)　他方、原告ＣＤＤＢと被告ＣＤＤＢ（新版）では、依然として、前記記載のとおり、原告ＣＤＤＢと同じ誤りないし不自然な表現方法の同一性もみられる。 　しかし、これらについても、上記認定した原告ＣＤＤＢと被告ＣＤＤＢ（新版）とで共通性を有する部分の表現方法ないし誤り自体には、原告ＣＤＤＢの創作性があるものと認めるべき内容はみられないというべきである。 (ウ)　これらを総合勘案すると、被告ＣＤＤＢ（新版）においては、もはや、情報の選択においても、原告ＣＤＤＢと共通性を有する部分は少なく、共通性を有する部分については創作性を有するものとは認め難いか、あるいは原告ＣＤＤＢの創作的表現上の特徴を直接感得することができないものであると認めるのが相当である。 　そうすると、被告ＣＤＤＢ（新版）は、もはやその情報の選択において、原告ＣＤＤＢの複製ないし翻案には該当しないというべきである。 オ　原告の主張に対する判断 (ア)　原告は、被告ＣＤＤＢ（新版）においても、体系的構成において、テーブル間の関連付けが、原告ＣＤＤＢのマスターテーブルと一致するテーブルに関して、プライマリー・キーの設定も含め、原告ＣＤＤＢに存在する関連付けのほぼ全てについて同じリレーションが、被告ＣＤＤＢ（新版）にも存在する旨主張する。 　しかし、被告ＣＤＤＢ（新版）におけるテーブル間のリレーションについては、原告ＣＤＤＢと相当程度の相違があることは前記のとおりである。 　したがって、原告の上記主張は採用することができない。 (イ)　原告は、フィールド項目の選択の類似性として、テーブル管理のためのフィールドである「作成日時」、「更新日時」及び「削除区分」のフィールドを除いた場合の被告ＣＤＤＢのフィールド数のうち、１４６個が原告ＣＤＤＢと一致しており、したがって、原告ＣＤＤＢのフィールド項目の選択を流用しているといえるから、この点に関して原告ＣＤＤＢと被告ＣＤＤＢ（新版）は同一あるいは少なくとも類似している旨主張する。 　しかし、原告ＣＤＤＢと被告ＣＤＤＢ（新版）のフィールドの一致数については、前記認定のとおり１３３個であると認められるところ、その余の２００個弱のフィールドについては、もはや原告ＣＤＤＢと一致するものではなく、被告ＣＤＤＢ（新版）を全体としてみた場合に、原告ＣＤＤＢと被告ＣＤＤＢ（新版）とのフィールドには同一性ないし類似性は認められないというべきである。 　したがって、原告の上記主張は採用することができない。 (ウ)　原告は、被告ＣＤＤＢ（新版）では、各テーブルにおいてレコードが追加されている場合があるものの、原告ＣＤＤＢのレコードの集合物に対してレコードが追加されたとしても、原告ＣＤＤＢの集合物は維持されて存続しているので、追加されたレコードが膨大なものか否かにかかわらず、原告ＣＤＤＢのレコードの集合物のその部分に関しては、情報の選択について原告ＣＤＤＢと類似しているから、被告らが流用した原告ＣＤＤＢのレコードの集合物の情報の選択について、原告ＣＤＤＢと類似することとなる旨主張する。 　なるほど、被告ＣＤＤＢ（新版）のレコード数が２７０万件余りにのぼるとしても、これらは原告ＣＤＤＢからコピーしたデータが相当数存する被告ＣＤＤＢ（当初版・２００６年版）に、レコードが追加・改変されてきたものにほかならず、いまだ原告ＣＤＤＢからコピーされたままのレコードも相当数に上ると推認されるところである。 　しかし、データベースの著作物として保護されるのは情報の選択ないし体系的構成において創作性を有するものであり、データないしレコード等それ自体を保護するものではない。そして、前記のデータベースが著作物として保護される理由、その著作物性の有無や複製及び翻案の判断基準に照らせば、例え、原告のデータベースと被告のデータベースとの間に情報の選択において共通点があり、その共通点において、原告データベースの表現としての創作性のある部分が一部含まれているとしても、両データベース全体を比較した場合に、その保有する情報量に大きな差があるため、情報の選択として創作性を有する共通部分がその一部にすぎず、相当部分が異なる場合には、もはや情報の選択においてその表現の本質的特徴を直接感得できると評価することはできず、また、原告のデータベースと被告のデータベースとの間に体系的構成において共通点があり、その共通点において、原告データベースの表現としての創作性のある部分が一部含まれているとしても、両データベース全体を比較した場合に、共通しないテーブル、フィールド項目が相当数を占め、また、それら相互間のリレーションの仕方にも大きな相違がみられるため、体系的な構成として創作性を有する共通部分がその一部にすぎず、相当部分が異なる場合には、体系的構成においてもその表現の本質的特徴を直接感得できるということはできないというべきであって、そのような場合、被告データベースはもはや、共通部分を有する原告データベースとは別個のデータベースであると認めるのが相当である。 　そうすると、本件においては、前記のとおり、被告ＣＤＤＢ（新版）は、原告ＣＤＤＢと比較して、情報の選択及び体系的構成において相当な相違が存在し、共通する部分を有する原告データベースとは別個のデータベースとなったものというべきであるから、原告ＣＤＤＢからコピーしたレコード自体が残存しているとしても、もはや、両者が情報の選択及び体系的構成において類似していると評価することは相当でないというべきである。 　したがって、原告の上記主張は採用することができない。 (エ)　原告ＣＤＤＢの道路地点の情報の選択に関して、被告ＣＤＤＢ（新版）の道路地点の緯度経度情報については、−１０秒から１０秒の間でみれば、被告ＣＤＤＢ（新版）には原告ＣＤＤＢの緯度経度情報が約９０％が含まれているところ（甲３４の別紙４の１、別紙５の１）、被告らは、原告から平成２１年５月に著作権侵害の訴えを提起された後に、一定範囲内で数値が異なるような乱数発生機能を利用する変換プログラムを作成して、元の緯度経度データの数値に対して一斉に変換をかける等の自動処理や個別の改変等の工作を行っているものであり、このような工作を行ったとしても、原告ＣＤＤＢの緯度経度情報をデッドコピーした後に、隠蔽目的でデッドコピーした緯度経度情報に依拠して自動変換等の改変がされたすぎないから、被告ＣＤＤＢ（新版）は、原告ＣＤＤＢの道路地点情報の緯度経度情報を流用していると主張する。 　確かに、Ａは、その証言において、原告ＣＤＤＢと被告ＣＤＤＢとの緯度経度情報につき、原告から本件訴訟の提起を受けて指摘を受けるまで、これらが同じであることを知らなかったが、原告の指摘を受けたことから、交差点が中心になるようにマウスでクリックをして位置決めをして、数値の入れ直しをした結果、緯度経度情報が異なるに至ったとするところ（証人Ａ尋問調書２０頁）、新たに位置決めをして数値を入れ直したとする証言の信用性については、前記のとおりＡの証言自体の信用性からして疑問は残るものの、結果としては１０％を切る一致率となっていること、被告ＣＤＤＢ（新版）の地点マスタのレコード数は別紙４のとおり２万３０００件余りであり、原告主張のレコードの一致率も、原告ＣＤＤＢが保有する１万２０００件余りの地点に関する緯度経度情報に関し、同一の地点がこのうちいくつ被告ＣＤＤＢ（新版）にあるかを探し、それについて、緯度経度情報が一致する率を調べた結果が１０％を切る、としているものであるから、その一致する地点の範囲で緯度経度情報の数値が例えプラスマイナス１０秒の間に９０％が入るものとしても、地点に関する緯度経度情報の全体からみた場合には、緯度経度情報が重複している割合が多いとは認められないというべきである。 　したがって、原告の上記主張は採用することができない。 カ　被告ＣＤＤＢ（新版）についての結論 　以上によれば、被告ＣＤＤＢ（新版）については、原告ＣＤＤＢの複製物ないし翻案物に該当しないというべきである。 ３　争点(2)(被告らによる著作権〔複製権、翻案権、譲渡権、貸与権、公衆送信権、送信可能化権〕侵害についての共同不法行為の成否)について (1)　前記のとおり、被告ＣＤＤＢ（当初版・２００６年版）、被告ＣＤＤＢ（現行版）は原告ＣＤＤＢの複製物であり、原告ＣＤＤＢについて原告が有する複製権を侵害するものと認められる。 　証拠（甲５１）によれば、被告アゼスタは、原告ＣＤＤＢの複製物である被告ＣＤＤＢ（当初版・２００６年版）、被告ＣＤＤＢ（現行版）を顧客に対してＣＤ等を用いて販売するほか、被告ＣＤＤＢを含む被告システムにつき、インターネットを通じてオンラインアップデート等の行為を行っており、また、被告ＣＤＤＢを含む被告システムについて、リース等も行っていると認められるから、被告アゼスタは、原告ＣＤＤＢについての譲渡権、貸与権、公衆送信権、送信可能化権を侵害している。 　そうすると、請求の趣旨第１項のうち、原告が、被告アゼスタに対し、著作権法１１２条１項に基づき、被告ＣＤＤＢ（当初版・２００６年版）、被告ＣＤＤＢ（現行版）に関する、別紙被告物件目録１ないし２１記載の物件について、複製、頒布、公衆送信（送信可能化を含む）の差止めを求める部分については理由がある（主文第１項）。 　これに対し、請求の趣旨第１項のうち、原告が、被告らに対し、被告ＣＤＤＢの翻案の差止めを求める部分については、データベースである被告ＣＤＤＢを翻案する行為には広範かつ多様な態様があり得るところであるから、原告の請求は差止めの対象となる具体的な行為を特定することなく、多様な態様を含みうる翻案行為の全てを差止めることを求めるものであり、内容の限定されない態様を含むものとして、本件において、その差止めの必要性を認めることはできない。 　そうすると、請求の趣旨第１項のうち、被告らに対し、被告ＣＤＤＢの翻案の差止めを求める部分については理由がないというべきである。 (2)　請求の趣旨第１項のうち、被告アゼスタ以外の個人被告らに対しても、被告ＣＤＤＢ（別紙被告物件目録１ないし２１について）の複製等の差止めを求める部分については、まず、被告Ｙ５については、平成２０年６月に被告アゼスタを退社し、その後の職業については不明であるものの、被告システムの複製や販売等に関与している旨の証拠もないから、被告Ｙ５に係る差止請求については理由がないというべきである。 　また、その余の個人被告らに対する差止請求についても、それら被告が個人として、原告ＣＤＤＢを複製し、頒布し、公衆送信（送信可能化を含む）をしたものと認めるべき証拠はないから、請求の趣旨第１項のうち、個人被告らに対し、被告ＣＤＤＢ（別紙被告物件目録１ないし２１について）の複製等の差止めを求める部分についても理由がないというべきである。 (3)　そして、前記によれば、原告の請求の趣旨第２項にかかる著作権法１１２条２項に基づく廃棄等請求のうち、被告アゼスタに対し、被告ＣＤＤＢ（当初版・２００６年版）、被告ＣＤＤＢ（現行版）に関する、別紙被告物件目録１ないし２１記載の物件についての各データベースを格納したＣＤ−ＲＯＭ等の記録媒体を廃棄し、同各データベースの記録内容の消去を命ずる部分については理由があり（主文第２項）、その余については理由がないというべきである。 (4)　なお、著作権侵害の共同不法行為に基づく損害賠償の主張については、後記４のとおり、著作権侵害の予備的主張として一般不法行為の主張がされていることに鑑み、争点(3)（一般不法行為の成否〔著作権侵害についての予備的主張〕)、争点(4)（原告の行為の独占禁止法違反の可能性の有無）についての判断の後、争点(5)（被告らの損害賠償義務の有無及び原告の損害額）の冒頭において、被告らの故意ないし過失の有無についての判断を行うこととする。 ４　争点(3)（一般不法行為の成否〔著作権侵害についての予備的主張〕）について (1)　原告は、著作権侵害についての予備的主張として、一般不法行為に基づく主張をしているところ、原告の主張する損害の算定時期は、平成１８年６月から平成２２年１１月までで、その対象も、被告ＣＤＤＢ（当初版・２００６年版）、被告ＣＤＤＢ（現行版）を組み込んだ被告システムの販売に基づく損害を主張しており、被告ＣＤＤＢ（新版）の発売時期は平成２３年４月以降であり、損害算定のための販売数に、被告ＣＤＤＢ（新版）を対象とはしていない。したがって、被告ＣＤＤＢ（新版）は、一般不法行為に基づく損害賠償請求の対象になっていないことは明らかであるが、なお、事案に鑑み、著作権侵害を認めない被告ＣＤＤＢ（新版）について、一般不法行為の成否についても検討し、判断を示すこととする。 　原告は、原告が費用や労力をかけて開発し、制作した原告ＣＤＤＢにつき、その多数の部分を流用して被告ＣＤＤＢを販売する行為は、先行者の築いた開発成果にいわばただ乗りする行為であって、取引における公正かつ自由な競争として許される範囲を逸脱するものとして不法行為を構成するというべきであると主張する。 　しかし、著作権法は、著作物の利用について、一定の範囲の者に対し、一定の要件の下に独占的な利益を認めるとともに、その独占的な利益と国民の文化的生活の自由との調和を図る趣旨で、著作権の発生原因、内容、範囲、消滅原因等を定め、独占的な利益の及ぶ範囲、限界を明らかにしていることからすれば、ある著作物が同法による保護を受ける著作物に該当しないものである場合、当該著作物を独占的に利用する権利は法的保護の対象とはならないものと解すべきであるから、著作権法による保護を受けない著作物の利用行為は、同法の規律の対象とする著作物の利用による利益とは異なる法的に保護された利益を侵害するなどの特段の事情がない限り、不法行為を構成するものではないと解するのが相当である（最高裁平成２１(受)第６０２号・同第６０３号、同２３年１２月８日第一小法廷判決・民集６５巻９号３２７５頁参照）。 　この観点から本件を検討すると、前記認定事実によれば、原告ＣＤＤＢについての著作権侵害が認め難い被告ＣＤＤＢ（新版）については、体系的構成及び情報の選択のいずれについても原告ＣＤＤＢとの同一性ないし類似性が認められないところであり、その情報の選択における判断において示したように、被告ＣＤＤＢ（新版）においては、原告ＣＤＤＢから流用した情報の割合は、相当程度に低下している。 　確かに、原告の主張するとおり、被告ＣＤＤＢ（新版）においては、前記２記載のとおり、原告ＣＤＤＢから流用したものと推認されるレコードが存するものの、被告ＣＤＤＢ（新版）において、総レコード数からみた場合のこれら流用レコードの割合も相当に低いものとなっている。 　そうすると、原告が費用や労力をかけて作り上げた原告ＣＤＤＢに関して主張する保護されるべき利益とは、結局、原告が著作権法によって保護されるべきと主張する法的利益、すなわち、原告ＣＤＤＢの情報の選択方針や、情報内容それ自体といったアイデアや抽象的な特徴、ないし表現それ自体でないものに基づく利益と異なるものではないことになり、それらの点が著作権法によっては保護されないものであることは前記判示のとおりである。 　また、本件全証拠を精査し、原告システムからのリプレースをも目的とした営業活動がされていることを勘案しても、被告らが被告ＣＤＤＢを含む被告システムを販売し、収益を得る行為が殊更原告に損害を与えることを目的として行われたなどの自由競争の範囲を逸脱する行為であると認めるに足りる事実も窺われない。 　そうすると、被告らが被告ＣＤＤＢを販売等する行為には、著作権法の規律の対象とする著作物の利用とは異なる法的に保護された利益を侵害するなどの特段の事情は認められないというべきである。 　したがって、被告らの上記行為については民法上の不法行為を構成するものではないと認めるのが相当であるから、著作権法上の請求が認められない被告ＣＤＤＢ（新版）に関して、一般不法行為の成立を理由に著作権侵害に係る損害と同額の損害の賠償を求める原告の予備的請求には理由がないというべきである。 (2)　また、原告は、被告らが原告ＣＤＤＢをデッドコピーし、これに改変を加えて被告ＣＤＤＢ（新版）を制作したものであり、改変によってデッドコピーとは異なるものとなったとしても、それは社会的に許容される限度を超える行為であり、不法行為を構成するものであるとも主張する。 　確かに、被告ＣＤＤＢ（新版）にも、いまだ原告ＣＤＤＢからのコピーであると推認されるレコードも一部に存する上、被告らは、度重なる求釈明がされた後であり、本件訴え提起から３年以上が経過した後の、平成２５年１月２９日付け被告第２２準備書面においても、原告ＣＤＤＢのデータの一部を被告ＣＤＤＢに利用する際のデータの入手経路を含む具体的態様については、認否を差し控える、などとしており、個人被告らの各陳述書ないし報告書（乙３９ないし４２）においても、何らこれらデータの入手経路について触れるところがなく、かえって、被告Ｙ１は、平成２１年９月１８日付け陳述書において、「私どもは、被告データベースの設計・構築にあたって、自らの経験、ノウハウ等をもとに、実際に現場でデータベースを利用することになる取引先（利用者）からヒアリングを行い、現在使用中の出力帳票（…）のサンプルの提供を受け、書籍やウェブサイト等の様々な旅行関連資料とも照らし合わせながら、議論を重ねた上でデータ項目の洗い出し及びデータ収集を行って、独自に被告データベースを設計・構築しました。」、「私どもは、上記…のとおり、膨大な時間をかけて議論を重ね、独自の設計思想を確定して、文字どおりゼロから独自に被告データベースを設計・構築したのであり、原告から被告データベースの販売等の差止めを求められるような理由は全くありません。」などとしていた（乙２の１）にもかかわらず、被告Ｙ５は、当法廷において、被告ＣＤＤＢの開発当初は、ゼロから作成していたが、間に合わないことが分かったことから、原告ＣＤＤＢのメンテナンスＣＤからデータをコピーすることとしたと供述し（被告Ｙ５尋問調書１６頁）、上記被告Ｙ１の陳述内容とは全く相反する供述をするなど、原告ＣＤＤＢに依拠して制作された被告ＣＤＤＢの制作過程は何ら明らかになっておらず、原告ＣＤＤＢについて、そこから被告ＣＤＤＢに流用したレコードの全貌も不明である。そして、被告システムは、原告システムからのデータ移行が可能なことをうたったリプレース販売の手法を主にとっていることから、被告らが、被告システムを、原告システムからのデータ移行が可能なシステムとしていかに構築したかについても、何ら被告らは明らかにせず、また、被告らの上記リプレースを主体とした営業方法について、上記被告システムの制作過程からすれば、明らかな自由競争の範囲内のものであるとまではいい難い面がないとはいえない。 　しかし、前記(1)のとおり、被告らが被告ＣＤＤＢ（新版）を販売等する行為には、著作権法の規律の対象とする著作物の利用とは異なる法的に保護された利益を侵害するなどの特段の事情は認められないから、原告の不法行為に基づく予備的請求についても理由がないというべきである。 ５　争点(4)（原告の行為の独占禁止法違反の可能性の有無）について 　被告らは、原告システム及び被告システムのような、行程表・見積書の作成及び出力、売上・集計・顧客管理のトータルサポートを可能とする旅行業向けシステムを開発・販売している業者が原告と被告アゼスタの２社のみであり、寡占状況となっているとすれば、原告の本訴提起による被告ＣＤＤＢの差止請求及び損害賠償請求は、原告１社による市場独占を企図するものと考えられ、公共の利益に反し一定の取引分野における競争を実質的に制限するものであるから、独占禁止法２条５項、３条に違反している可能性があり、原告の請求はこの点から速やかに棄却されるべきものである旨主張する。 　独占禁止法２条５項は、「この法律において『私的独占』とは、事業者が、単独に、又は他の事業者と結合し、若しくは通謀し、その他いかなる方法をもってするかを問わず、他の事業者の事業活動を排除し、又は支配することにより、公共の利益に反して、一定の取引分野における競争を実質的に制限することをいう。」とし、同法３条は、事業者が私的独占等をしてはならないことを定めるものであるところ、そもそも、それらの規定に違反しているというのであればともかく、その可能性があるというのみで、原告の請求を棄却しなければならない法的根拠は不明といわざるを得ないばかりか、原告による本件訴えの提起は著作権法等に基づくものであるところ、独占禁止法２１条は、同法の適用関係について、著作権法による権利行使には適用しないと規定しているのであって、本件全証拠を精査しても、原告による訴えの提起につき、同条の規定を排除すべき事情を認めるに足りる証拠はなく、その他原告による被告らに対する差止め及び損害賠償等の請求につき、その権利行使が許されないとする事情は何ら認められない。 　したがって、被告らの上記主張は採用することができない。 ６　争点(5)（被告らの損害賠償義務の有無及び原告の損害額）について (1)　被告らの損害賠償義務の有無 　前記のとおり、被告アゼスタは著作権侵害の不法行為責任を負うところ、以下、各個人被告らの損害賠償義務の有無について、検討する。 ア　被告Ｙ１につき 　被告Ｙ１は、旧原告会社に在籍した経験はなく、データベースやシステムに関する専門知識はない。〔被告Ｙ５尋問調書１８、１９頁〕 　しかし、平成１７年１０月１８日の被告アゼスタの設立に際しては出資金の過半を拠出してその代表者となり、Ａが同年１１月に被告アゼスタに入社した際には、常勤の役員、社員は被告Ｙ１しかいない状態であったところ、その状況で、被告Ｙ１は、Ａとともに被告システムの制作に当初から携わってきている。被告Ｙ５も、原告ＣＤＤＢのデータをコピーするため、ＣＤを利用するに当たっては、被告Ｙ１と相談して決めたとしている。〔被告Ｙ５尋問調書２６、２７頁〕 　被告Ｙ１は、被告システム販売開始当初から、旧原告会社の顧客に向けて、被告システムへのリプレースを勧める文書を送付していること（上記認定の乙５２の記載内容）などからすると、被告Ｙ１は、被告アゼスタの著作権侵害について共同不法行為を行ったものと認めることができ、上記認定事実によれば、被告Ｙ１には、著作権侵害について少なくとも過失を認めることができる。 イ　被告Ｙ２につき 　被告Ｙ２は、翼システムにおいて、主任として原告システムの会議にも参加し、その販売に関与しており、しかも、被告Ｙ２は、翼システムへの転職前においても、旅行業者向けのトータル業務システムの販売業務に従事していて、旅行業務システム構築のノウハウを熟知していた者である。被告Ｙ２は、被告アゼスタにおいても、営業を担当して営業グループのマネージャーであるほか、取締役にも就任しており、被告アゼスタの著作権侵害の共同不法行為を行ったものと認めることができる。上記認定事実によれば、被告Ｙ２につき、著作権侵害について少なくとも過失を認めることができる。 ウ　被告Ｙ３につき 　被告Ｙ３は、翼システムにおいて、営業担当として積極的に原告システムの会議にも参加して提言をし、その販売にも関与しており、被告アゼスタにおいても、著作権侵害の共同不法行為を行ったものと認めることができる。上記認定事実によれば、被告Ｙ３につき、著作権侵害について少なくとも過失を認めることができる。 エ　被告Ｙ４につき 　被告Ｙ４は、翼システムにおいて、営業担当として原告システムの会議にも参加して、その販売にも関与しており、被告アゼスタにおいても、著作権侵害の共同不法行為を行ったものと認めることができる。上記認定事実によれば、被告Ｙ４につき、著作権侵害について少なくとも過失を認めることができる。 オ　被告Ｙ５につき 　被告Ｙ５は、被告アゼスタを平成２０年６月に退社しているが、それまでは、被告ＣＤＤＢ（現行版）の開発に関与している。〔被告Ｙ５尋問調書１８頁〕 　被告Ｙ５は原告システム開発のリーダーであり、被告アゼスタ入社時期は遅いものの、被告システムの開発当初から積極的に関与しており、被告ＣＤＤＢの販売開始から、被告Ｙ５の被告アゼスタ退社の平成２０年６月までの損害に関する著作権侵害の共同不法行為については責任を負うものと認められ、上記認定事実によれば、被告Ｙ５には少なくとも過失が認められる。 カ　被告Ｙ６につき 　被告Ｙ６は、翼システムにおいて、営業担当として原告システムの会議にも参加して、販売にも関与しており、被告アゼスタにおいても、著作権侵害の共同不法行為を行ったものと認めることができる。上記認定事実によれば、被告Ｙ６につき、著作権侵害について少なくとも過失を認めることができる。ただし、被告Ｙ６は、原告も、平成１８年１０月末までは原告システムの販売に関与してきたと主張しているところであるので、その時期以降の損害について、その余の被告らとの共同不法行為責任を認めるべきである。 キ　小括 　以上によれば、個人被告らは、被告アゼスタの著作権侵害の不法行為について、共同不法行為を行ったものと認められるから、それぞれ損害賠償義務を負うこととなり、被告らは、原告が被告らの著作権侵害行為により被った損害を賠償すべき責任を負う。 (2)　著作権法１１４条１項に基づく損害額 ア　被告ＣＤＤＢを含む被告システムの販売本数 (ア)　被告システム（旅nesPro）には、Pro-1とPro-2の二つのタイプがあると認められるところ、このうちPro-1は、行程表・見積書作成機能のみのシステムであり、Pro-2は、Pro-1の機能に加えて売上・顧客管理機能が追加されたシステムである（甲２５の２）。なお、売上・顧客管理機能は原告ＣＤＤＢには含まれていない。 　被告システムのバージョン毎の販売本数は、以下のとおりであると認められる。 被告システムのバージョン（納品時期） 販売本数 Pro-1 Pro-2 合計 当初版[ver1.0] 　(平成18年6月〜同年11月) 22本 O本 22本 ２００６年版[ver1.5] 　(平成18年11月〜平成19年4月) 14本 47本 61本 現行版[ver2.0〜ver3.1] 　(平成19年4月〜平成23年4月) 126本 207本 333本 新版[ver3.2] 　(平成23年4月〜平成23年6月) 10本 26本 36本 合計 172本 280本 452本 　そうすると、原告が、損害賠償として請求する期間は、平成１８年６月から平成２２年１１月末までであるから、上記のうち、現行版については月数の割合を乗じることとして計算することにより、被告アゼスタの被告システムの販売本数を算定するのが相当である。その内容は、当初版・２００６年版については上記販売本数の合計欄記載の以下の本数、現行版については、月数に応じた以下の計算による。 　・２２本（当初版） 　・６１本（２００６年版） 　・３３３÷４９×４４（現行版）≒２９９本 　・合計 ２２＋６１＋２９９＝３８２本 　以上のとおり、被告らは、上記合計３８２本の被告システムを販売したものとすべきである。 (イ)　この点に関して原告は、被告らは、被告システムを平成１８年６月から平成２２年１１月ころまでの間に少なくとも５００本を販売したと主張し、それに沿う証拠として、甲５３を提出する。 　確かに、甲５３には、被告代表者である被告Ｙ１において、被告システムを平成２２年１１月２９日までに、約５００社に納入したかに読める記載がある。しかし、この文書は、新製品の案内として原告顧客に送付した文書であり、必ずしも正確な納入本数を反映した文書であるとは認め難く、また被告アゼスタの紹介の文書には、平成２２年１月の時点において、被告システムの導入３５０社を達成した旨の記載があり（甲２５の２）、これは上記販売本数の認定と概ね相違しないことが認められる。 　したがって、原告の上記主張は採用することができない。 イ　原告ＣＤＤＢにつき、著作権法１１４条１項本文の「著作権者等がその侵害の行為がなければ販売することができた」といえるかについて 　原告ＣＤＤＢと被告ＣＤＤＢとの代替関係（相互補完性）については、前記認定のとおり、顧客である旅行会社のニーズを分析した上で制作された原告ＣＤＤＢと、被告ＣＤＤＢ自体の類似性に加え、被告らは、原告システムを使用する顧客の手持ちデータの移行が可能であることを宣伝して原告システムとのリプレース販売を仕掛け、原告顧客に対しても、被告アゼスタの設立当初から販売をしているものであるから、原告ＣＤＤＢと被告ＣＤＤＢとの間には代替関係を肯定することができる。 　また、原告の供給能力についても、後記ウのとおり、原告は平成１８年１月ないし同年１２月までの１年間に、原告システムを１３２本販売していること、原告は、被告アゼスタよりも相当に事業規模が大きいことに照らせば、原告の供給能力には特段の問題は認められない。 ウ　原告の利益率について (ア)　原告が、被告アゼスタの販売した被告ＣＤＤＢを含む被告システムを追加的に販売したとした場合に、必要な経費を考慮した原告の利益率については、平成１８年１月から同年１２月の実績を基に、以下のとおり算定される。 　原告の費目毎の経費は以下のとおりと認められ、これらについては経費として算入すべきである。 ・ 仕入高：７８１万４０００円 　仕入高は、原告システムと関連するパソコン、プリンター等のハードウェアなどと一緒に販売する場合の仕入費用である。 ・ 残債：１０８万５０００円 　残債は、原告システム販売時に、顧客の旧リース料を原告が負担する場合の費用である。 ・ 販売手数料：２５０万４０００円 　販売手数料は、原告システム販売時に販売代理店に対し支払われる手数料である。 ・ 販促費／リース料Ｓ：４３万９０００円 　販促費／リース料Ｓは、原告システム販売時に、顧客の新たなリース料の一部を原告が負担する場合の費用である。 ・ 販促費／その他：３９万６０００円 販促費／その他は、原告システムの販売促進活動にかかる成約記念品等の費用である。 ・ 外注費：６７８万２０００円 　外注費は、原告システムの開発及びメンテナンスなどについての外部委託費用である。 ・ 物流費：１８８万３０００円 　物流費は、原告システム等の出荷に伴い発生する運送費用である。 ・ インセンティブ：１５９２万９０００円 　インセンティブとは、原告システム販売担当営業員に販売額に応じて支払われるインセンティブ費用である。〔以上、甲７７〕 　以上の合計額は、３６８３万２０００円となる。 (イ)　以下の経費については控除すべきものとは認められない。 ・ 広告宣伝費：１１２万５０００円 ・ その他管理費：５３３２万９０００円 (ウ)　次に、仮に被告が販売した量の原告システムを原告が追加的販売に要した場合の人件費については、以下のとおりである。 　原告システムの売上高は、甲６９の売上高欄のうち、「内ソフト」の欄の記載金額によるべきと認められるから、２億１２５７万８０００円となり（甲６９）、同じく甲６９によれば、原告システムの単価は１６７万９０００円、平成１８年１月ないし１２月の原告システムの販売本数は１３２本（ただし、基本タイプ〔ＴＲ−Ｐ１、ＴＲ−Ｐ３、ＴＲ−Ｐ４〕のほか、モバイルタイプＴＲ−Ｐ１Ｍ、子機セットＴＲ−Ｐ１Ｌ、ＴＲ−Ｐ４Ｌの販売台数を含むとし、これらの販売台数の内訳は明らかではないが、これらを合算した上記販売本数によるのを相当と認める。）となる。 　原告において、旅行部門に携わる人員は、営業部門につき営業４人、アフター３人、スタッフ１人、開発部門に１人、本社スタッフ１人の合計１０人である。〔甲６９〕 　そうすると、原告の人件費は、甲６９によれば６５６１万９０００円と認められるところ、被告アゼスタの販売本数が平成１８年６月から平成２２年１１月末までの４年６か月で３８２本であると認められるから、 ３８２÷５４×１２＝８４（本、年平均）となる。 　原告の販売本数について、その内訳は明らかでないものの、上記のとおり売上本数は１３２本とするものとし、上記８４本を販売するのに必要な追加的人件費は、以下のとおりの式で計算される。 ６５６１万９０００円×営業部門人数８人÷全体１０人×８４÷１３２≒３３４０万６０００円 　そうすると、必要な追加的人件費は、３３４０万６０００円となる。 (エ)　上記追加的人件費を、経費に加え、原告の限界利益を算出する。 　上記を前提とした原告の限界利益率は以下のとおりとなる。 　２億１２５７万８０００円÷１３２本＝１６１万０４３９円 　〔２億１２５７万８０００円−（３６８３万２０００円＋３３４０万６０００円）〕÷１３２本＝１億４２３４万円÷１３２本＝１０７万８３３３円 　１６１万０４３９円−１０７万８３３３円＝５３万２１０６円 　５３万２１０６円÷１６１万０４３９円＝０．３３０４ 　以上によれば、原告の限界利益率は３３％であると認められる。 エ　著作権法１１４条１項ただし書の事情の有無 　被告らは、原告システムは、長年にわたり十分なバージョンアップないしバックアップもされていないのに対し、被告システムにおいては、頻繁なバージョンアップや、旅行業に熟練した社員らによるバックアップ等が充実していたことにより、販売の実績をあげてきたものであり、それに相当する相応量の販売数量は、原告が販売することができないとする事情に該当する旨主張する。 　確かに被告らは、頻繁なバージョンアップを行っており、被告Ｙ２、被告Ｙ３、被告Ｙ６らは、旅行業システムに長年携わり、多くの知識を有するものと認められるが、原告側において、被告らに比べ、十分なシステムサポート体制等がとられていないことを認めるに足る的確な証拠はないし、また被告主張の事情により、被告システムの販売が特段に伸びたものと認めるべき証拠もない。 　したがって、被告らの上記主張は採用することができない。 オ　寄与率 　原告ＣＤＤＢは、別紙原告物件目録記載のとおり、原告システムの一部であるところ、原告は、損害額算定に当たって、原告システム全体の販売価格を基準としているから、原告システムにおける原告ＣＤＤＢの寄与率を考慮すべきこととなる。 　原告ＣＤＤＢは原告システムのうちの検索及び行程作成業務用のデータベース部分であり、原告システムのうちの、基本システムであるＴＲ−Ｐ１は、検索業務、行程表・見積書作成、インターネット連動、地図連動機能を含むものであるから、ＴＲ−Ｐ１の販売価格（システム価格１７０万円）を基準とすれば十分であり、ＴＲ−Ｐ１に売上集計管理、顧客管理機能を加えたＴＲ−Ｐ４を基準とすべき理由はない。 　そして、前記第２、１(2)のとおり、原告システムのカタログ（２００９年〔平成２１年〕版）によれば、検索業務、行程・見積作成の各機能の内容としては、検索業務は時刻表検索、観光施設検索、宿泊施設検索、道路料金経路検索、インターネット検索、画像保存、地図検索を含むもの、行程・見積作成は行程表作成、見積書作成、損益検討書作成、受注型企画旅行見積書、包括見積書作成、修学旅行見積書、利用施設一覧印刷、観光施設案内書印刷、宿泊施設案内書印刷、添乗指示書作成、現地払い見積書、契約書（受注型・手配型）、Ｍａｉｌ送信（ＰＤＦ）、画像付き行程表出力を含むものであるから、このうち時刻表検索、インターネット検索、画像保存、地図検索、見積書作成、損益検討書作成、受注型企画旅行見積書、包括見積書作成、修学旅行見積書、利用施設一覧印刷、観光施設案内書印刷、宿泊施設案内書印刷、添乗指示書作成、現地払い見積書、契約書（受注型・手配型）、Ｍａｉｌ送信（ＰＤＦ）、画像付き行程表出力等の機能については、原告ＣＤＤＢとは無関係の機能である。 　これらを総合考慮すると、原告ＣＤＤＢの原告システム（ＴＲ−Ｐ１）における寄与率は５０％と認めるのが相当である。 　そうすると、原告ＣＤＤＢに係る損害は１本当たりの販売価格に寄与率、利益率を乗じて、これに販売本数を乗じることにより、以下のとおり計算される。 　１７０万円×０．５×０．３３＝２８万０５００円 　２８万０５００円×３８２本＝１億０７１５万１０００円 カ　原告の主張に対する判断 　原告は、原告システムについてのデータメンテナンス契約についての損害の賠償を請求するので、以下、この点につき判断する。 　データメンテナンス契約は、原告システムを導入するユーザーとの間で、毎月ユーザーに更新データを提供するための契約であり、月額６０００円で提供されているとするものである。〔甲７７、５頁〕 　しかし、データメンテナンス契約自体は、原告ＣＤＤＢにかかる著作権侵害と相当因果関係を欠き、著作権侵害に基づく損害賠償請求の範囲に入るものとは認められない。 　したがって、原告の上記主張は採用することができない。 キ　被告らの主張に対する判断 (ア)　被告らは、旅行業者向けシステムには、「応援団くん」等同種のものが複数あり、被告システムの販売と原告の損害との因果関係が存しないと主張するが、既に検討したとおり、それらは、原告ＣＤＤＢとは内容的に異なるものであり、むしろ、原告システムと被告システムとは相互補完関係にあると認められることは前記のとおりである。 　したがって、被告らの上記主張については採用することができない。 (イ)　被告らは、被告システムの方が、レコード数が豊富であること、データメンテナンス及びサポート体制が充実していること、担当個人被告らの経歴・ノウハウの存在等により、これら体制が優れていること、原告ＣＤＤＢとの不一致部分が被告システムの販売に寄与していること、データベース以外の部分が被告システムの販売に寄与していること等を理由として、著作権法１１４条１項ただし書の事情が認められると主張する。 　確かに、レコード数については別紙４のとおり、被告ＣＤＤＢ（現行版）においては、原告ＣＤＤＢと比して多くのレコードを格納しているといえるものの、被告ＣＤＤＢ（当初版・２００６年版）においては、原告ＣＤＤＢと大差はない。また、被告ＣＤＤＢ（現行版）において増加したレコードも、その多くが「３９区間料金マスタ」テーブルにかかるものであるところ、これらにはインターネットから入手可能な高速道路情報等もあること、被告らの主張によっても、もともと被告らは原告ＣＤＤＢから多くのデータをコピーするなどし、しかも前記認定のとおり、被告ＣＤＤＢには原告ＣＤＤＢからコピーしたままのデータが多数存在し、原告ＣＤＤＢからコピーしたデータを安易にそのまま利用したものを基に、これを充実させてきたものともいえること、そもそも原告の顧客におけるニーズやその契約期間を被告らにおいて把握した上で、そのリプレースを前提として原告ＣＤＤＢのデータを利用して短期間に開発したことによる廉価販売が被告アゼスタの売上げに貢献しているともいえること等を総合考慮すると、本件において、著作権法１１４条１項ただし書の事情があると認めることはできないというべきである。 　したがって、被告らの上記主張はいずれも採用することができない。 (ウ)　被告らは、被告システムの販売において、被告らが提供するバス運行管理システムとのセット販売の分については、原告の損害との相当因果関係を欠くものと主張する。 　しかし、前記１で認定したとおり、被告アゼスタがバス運行管理システムである「バス快道」を発売したのは、本件訴え提起後の平成２１年１０月のことであるから、被告が乙４３において、２００６年版についての販売本数を計上していることについてはそもそも疑問があるほか、バス運行管理システムの導入が増えたのは平成２４年のゴールデンウイークに発生した事故が契機となっているとする（乙４０、９頁）ところからすると、原告の求める損害賠償期間（平成１８年〜２２年）とも重ならないから、そもそも主張の前提を欠くものである。 　したがって、被告らの上記主張は採用することができない。 (エ)　被告らは、原告システムは値引き販売を行うことが常態となっているから、損害の計算もそれを基礎として算定すべきであると主張し、それに沿う証拠として、乙３６の１ないし２６を提出する。 　しかし、乙３６の１ないし２６は見積書のうちのごく一部であって、これを保存していたパソコンも現存しない（被告Ｙ２尋問調書２７頁）というのであるから、上記証拠は不十分であって、他に翼システムないし旧原告会社において値引き販売が常態化していたものと認めるべき的確な証拠はないし、原告ＣＤＤＢについての著作権侵害に基づく損害については、ＴＲ−Ｐ１の販売価格である１７０万円を基準としてそこに寄与率等を乗じることにより適正に評価されていると認められるから、原告の損害を上記算定方法により行うことに特段の問題は認められない。 　したがって、被告らの上記主張は採用することができない。 (3)　弁護士費用 　被告らのうち、平成１８年６月から平成２２年１１月までの著作権侵害の不法行為と相当因果関係のある原告の弁護士費用相当額の損害は、事案の性質、認容額、主張立証の難易度等の事情に鑑み、５００万円を下らない。 (4)　個人被告ら各人毎の損害賠償責任を負う範囲についての判断 ア　被告Ｙ１、被告Ｙ２、被告Ｙ３及び被告Ｙ４について 　被告Ｙ１、被告Ｙ２、被告Ｙ３及び被告Ｙ４の損害賠償責任については、原告の主張する損害期間の全範囲にわたるから、弁護士費用を加算して、以下の式の通りとなる。 １億０７１５万１０００円＋５００万円＝１億１２１５万１０００円 イ　被告Ｙ５について (ア)　被告Ｙ５は、平成２０年６月に被告アゼスタを退社しているから、被告ＣＤＤＢ（現行版）については月数に応じ、それまでの間の原告の損害を計算すべきである。 ・２２本（当初版） ・６１本（２００６年版） ・３３３÷４９×１５（現行版）≒１０１本 　以上の合計１８４本の被告システムの売上げに関する損害について、賠償責任を負うとすべきである。 ２８万０５００円×１８４本＝５１６１万２０００円 (イ)　そうすると、被告Ｙ５が責任を負う弁護士費用の範囲は４００万円とするのが相当である。 (ウ)　以上の合計は５５６１万２０００円となる。 ウ　被告Ｙ６について (ア)　被告Ｙ６は、平成１８年１０月まで旧原告会社で営業を担当したが同月退職したとし（乙４２）、その後被告アゼスタに入社しているところ、旧原告会社の退社の日が平成１８年１１月３０日となっていることからして、被告ＣＤＤＢの２００６年版以降の販売に係る分については責任を負うものとして損害を計算すべきである。 ・６１本（２００６年版） ・３３３÷４９×４４（現行版）≒２９９本 　以上の合計３６０本の被告システムの売上げに関する損害について、賠償責任を負うとすべきである。 ２８万０５００円×３６０本＝１億００９８万円 (イ)　そうすると、被告Ｙ６が責任を負う弁護士費用の範囲は４５０万円とするのが相当である。 (ウ)　以上の合計は１億０５４８万円となる。 エ　被告Ｙ５と被告Ｙ６との損害賠償債務の連帯の範囲について 　被告Ｙ５と被告Ｙ６との損害賠償債務についての連帯の範囲は、両者の責任が併存する期間に応じることとなり、被告ＣＤＤＢ（現行版）の販売数についての重なり合う期間は１５か月分となることから、以下のとおり計算される。 ・６１本（２００６年版） ・３３３÷４９×１５（現行版）≒１０１本 　の合計１６２本分 　２８万０５００円×１６２本＝４５４４万１０００円 　これと重なり合う弁護士費用４００万円の合計４９４４万１０００円の範囲で連帯責任を認めるべきである。 オ　遅延損害金の起算点について 　遅延損害金の起算点については、原告は、当初、平成１８年６月から訴え提起時である平成２１年５月１５日までの損害賠償金として５億５３４９万６０００円（うち弁護士費用相当額２０００万円）及びこれに対する訴状送達の日の翌日以降の日である平成２１年５月２８日から支払済みまで年５分の割合による遅延損害金の支払を求めていたところ、平成２３年１０月７日付け訴えの変更の申立書により、損害算定の期間を、現状の平成２２年１１月分までを含むものとして請求額も６億７２０８万９６００円に拡張し、遅延損害金については、うち５億５３４９万６０００円に対する平成２１年５月２８日から、うち１億１８５９万３６００円につき上記平成２３年１０月７日付け訴えの変更の申立書送達の日の翌日である平成２３年１１月２日から各支払済みまで民法所定の年５分の割合による遅延損害金の支払を求める内容に変更した。 　したがって、被告ＣＤＤＢを含む被告システムの販売に係る遅延損害金の起算点については、平成２１年５月１５日までの販売に係る分については平成２１年５月２８日から、平成２１年５月１６日以降平成２２年１１月までの販売に係る分については平成２３年１１月２日からとすべきである。 　そして、前記認定のとおり、被告システム（現行版）の販売本数は平成１９年４月から平成２２年１１月末までの４４か月分として２９９本とすべきところ、これを平成１９年４月から平成２１年５月１５日までの２５．５か月分と平成２１年５月１６日から平成２２年１１月末までの１８．５か月分とに割り振ることになる。 　そうすると、平成１９年４月から平成２１年５月１５日までの分は、 ２９９本×２５．５÷４４≒１７３本 平成２１年５月１６日から平成２２年１１月末までの分は ２９９本×１８．５÷４４≒１２６本 となる。 　平成１９年４月から平成２１年５月１５日までの損害分の計算は、当初版（２２本）、２００６年版（６１本）の本数と合算して、 ２８万０５００円×（２２＋６１＋１７３）＝７１８０万８０００円 となる（このうち、被告Ｙ６が責任を負うべき分は、２８万０５００円×（６１＋１７３）＝６５６３万７０００円である。）。 　これと弁護士費用相当額５００万円を合算すべきこととなり（弁護士費用については一括して算入するのを相当とする。以下同じ。）、その合計は、７６８０万８０００円となる。 　また、平成２１年５月１６日から平成２２年１１月末まで損害分の計算は、 ２８万０５００円×１２６＝３５３４万３０００円 となる。 　個人被告らのうち、被告Ｙ６、被告Ｙ５については関与の時期に対応して、被告Ｙ６については、認容額のうち７０１３万７０００円（上記７１８０万８０００円のうち、被告Ｙ６が責任を負うべき損害に相当する６５６３万７０００円と、被告Ｙ６について相当な弁護士費用４５０万円の合算額）については平成２１年５月２８日から、うち３５３４万３０００円については平成２３年１１月２日から起算すべきこととなり、被告Ｙ５については、認容額全額につき、平成２１年５月２８日から起算すべきこととなる。 ７　結論 　以上のとおりであり、原告の請求は、主文掲記の限度で理由があるから、その限度で認容し、その余の請求は理由がないから棄却することとし、仮執行宣言については主文第１項、第３項ないし第５項については相当であるので付することとし、別紙被告物件目録１ないし２１記載のデータベースを格納したＣＤ−ＲＯＭ等の記録媒体の廃棄、データベースの記録内容の消去を命ずる主文第２項について仮執行宣言は相当でないので付さないこととして、主文のとおり判決する。 東京地方裁判所民事第４０部 　裁判長裁判官　東海林保 　裁判官　今井弘晃 　裁判官　足立拓人 （別紙） 当事者目録 原告　株式会社ブロードリーフ訴訟承継人株式会社ブロードリーフ 原告　訴訟代理人弁護士　吉田正夫 同　井口加奈子 被告　株式会社アゼスタ（以下「被告アゼスタ」という。） 被告　Ｙ１（以下「被告Ｙ１」という。） 被告　Ｙ２（以下「被告Ｙ２」という。） 被告　Ｙ３（以下「被告Ｙ３」という。） 被告　Ｙ４（以下「被告Ｙ４」という。） 被告　Ｙ５（以下「被告Ｙ５」という。） 被告　Ｙ６（以下「被告Ｙ６」という。） 被告ら訴訟代理人弁護士　野間自子 同　中島健太郎 同　浅田登志雄 （被告物件目録） １　旅nesPro Ver1.0 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース ２　旅nesPro Ver1.5 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース ３　旅nesPro Ver2.0 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース ４　旅nesPro Ver2.51 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース ５　旅nesPro Ver2.53 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース ６　旅nesPro Ver2.6 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース ７　旅nesPro Ver2.70 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース ８　旅nesPro Ver2.72 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース ９　旅nesPro Ver2.76 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース １０　旅nesPro Ver2.78 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース １１　旅nesPro Ver2.80 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース １２　旅nesPro Ver2.82 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース １３　旅nesPro Ver2.84 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース １４　旅nesPro Ver2.90 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース １５　旅nesPro Ver2.92 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース １６　旅nesPro Ver2.94 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース １７　旅nesPro Ver2.96 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース １８　旅nesPro Ver2.97 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース １９　旅nesPro Ver2.98 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース ２０　旅nesPro Ver2.99 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース ２１　旅nesPro Ver3.1 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース ２２　旅nesPro Ver3.2 メンテナンスＣＤに格納されている検索及び行程作成業務用データベース （原告物件目録） 「旅行業システムＳＰ」に含まれる検索及び行程作成業務用データベース部分 ＜以下別紙省略略＞

日本ユニ著作権センター http://jucc.sakura.ne.jp/