【営業代行から学ぶ判例】crps 裁判例 lgbt 裁判例 nda 裁判例 nhk 裁判例 nhk 受信料 裁判例 pl法 裁判例 pta 裁判例 ptsd 裁判例 アメリカ 裁判例 検索 オーバーローン 財産分与 裁判例 クレーマー 裁判例 クレプトマニア 裁判例 サブリース 裁判例 ストーカー 裁判例 セクシャルハラスメント 裁判例 せクハラ 裁判例 タイムカード 裁判例 タイムスタンプ 裁判例 ドライブレコーダー 裁判例 ノンオペレーションチャージ 裁判例 ハーグ条約 裁判例 バイトテロ 裁判例 パタハラ 裁判例 パブリシティ権 裁判例 ハラスメント 裁判例 パワーハラスメント 裁判例 パワハラ 裁判例 ファクタリング 裁判例 プライバシー 裁判例 プライバシーの侵害 裁判例 プライバシー権 裁判例 ブラックバイト 裁判例 ベネッセ 裁判例 ベルシステム24 裁判例 マタニティハラスメント 裁判例 マタハラ 裁判例 マンション 騒音 裁判例 メンタルヘルス 裁判例 モラハラ 裁判例 モラルハラスメント 裁判例 リストラ 裁判例 リツイート 名誉毀損 裁判例 リフォーム 裁判例 遺言 解釈 裁判例 遺言 裁判例 遺言書 裁判例 遺言能力 裁判例 引き抜き 裁判例 営業秘密 裁判例 応召義務 裁判例 応用美術 裁判例 横浜地裁 裁判例 過失割合 裁判例 過労死 裁判例 介護事故 裁判例 会社法 裁判例 解雇 裁判例 外国人労働者 裁判例 学校 裁判例 学校教育法施行規則第48条 裁判例 学校事故 裁判例 環境権 裁判例 管理監督者 裁判例 器物損壊 裁判例 基本的人権 裁判例 寄与分 裁判例 偽装請負 裁判例 逆パワハラ 裁判例 休業損害 裁判例 休憩時間 裁判例 競業避止義務 裁判例 教育を受ける権利 裁判例 脅迫 裁判例 業務上横領 裁判例 近隣トラブル 裁判例 契約締結上の過失 裁判例 原状回復 裁判例 固定残業代 裁判例 雇い止め 裁判例 雇止め 裁判例 交通事故 過失割合 裁判例 交通事故 裁判例 交通事故 裁判例 検索 公共の福祉 裁判例 公序良俗違反 裁判例 公図 裁判例 厚生労働省 パワハラ 裁判例 行政訴訟 裁判例 行政法 裁判例 降格 裁判例 合併 裁判例 婚約破棄 裁判例 裁判員制度 裁判例 裁判所 知的財産 裁判例 裁判例 データ 裁判例 データベース 裁判例 データベース 無料 裁判例 とは 裁判例 とは 判例 裁判例 ニュース 裁判例 レポート 裁判例 安全配慮義務 裁判例 意味 裁判例 引用 裁判例 引用の仕方 裁判例 引用方法 裁判例 英語 裁判例 英語で 裁判例 英訳 裁判例 閲覧 裁判例 学説にみる交通事故物的損害 2-1 全損編 裁判例 共有物分割 裁判例 刑事事件 裁判例 刑法 裁判例 憲法 裁判例 検査 裁判例 検索 裁判例 検索方法 裁判例 公開 裁判例 公知の事実 裁判例 広島 裁判例 国際私法 裁判例 最高裁 裁判例 最高裁判所 裁判例 最新 裁判例 裁判所 裁判例 雑誌 裁判例 事件番号 裁判例 射程 裁判例 書き方 裁判例 書籍 裁判例 商標 裁判例 消費税 裁判例 証拠説明書 裁判例 証拠提出 裁判例 情報 裁判例 全文 裁判例 速報 裁判例 探し方 裁判例 知財 裁判例 調べ方 裁判例 調査 裁判例 定義 裁判例 東京地裁 裁判例 同一労働同一賃金 裁判例 特許 裁判例 読み方 裁判例 入手方法 裁判例 判決 違い 裁判例 判決文 裁判例 判例 裁判例 判例 違い 裁判例 百選 裁判例 表記 裁判例 別紙 裁判例 本 裁判例 面白い 裁判例 労働 裁判例・学説にみる交通事故物的損害 2-1 全損編 裁判例・審判例からみた 特別受益・寄与分 裁判例からみる消費税法 裁判例とは 裁量労働制 裁判例 財産分与 裁判例 産業医 裁判例 残業代未払い 裁判例 試用期間 解雇 裁判例 持ち帰り残業 裁判例 自己決定権 裁判例 自転車事故 裁判例 自由権 裁判例 手待ち時間 裁判例 受動喫煙 裁判例 重過失 裁判例 商法512条 裁判例 証拠説明書 記載例 裁判例 証拠説明書 裁判例 引用 情報公開 裁判例 職員会議 裁判例 振り込め詐欺 裁判例 身元保証 裁判例 人権侵害 裁判例 人種差別撤廃条約 裁判例 整理解雇 裁判例 生活保護 裁判例 生存権 裁判例 生命保険 裁判例 盛岡地裁 裁判例 製造物責任 裁判例 製造物責任法 裁判例 請負 裁判例 税務大学校 裁判例 接見交通権 裁判例 先使用権 裁判例 租税 裁判例 租税法 裁判例 相続 裁判例 相続税 裁判例 相続放棄 裁判例 騒音 裁判例 尊厳死 裁判例 損害賠償請求 裁判例 体罰 裁判例 退職勧奨 違法 裁判例 退職勧奨 裁判例 退職強要 裁判例 退職金 裁判例 大阪高裁 裁判例 大阪地裁 裁判例 大阪地方裁判所 裁判例 大麻 裁判例 第一法規 裁判例 男女差別 裁判例 男女差别 裁判例 知財高裁 裁判例 知的財産 裁判例 知的財産権 裁判例 中絶 慰謝料 裁判例 著作権 裁判例 長時間労働 裁判例 追突 裁判例 通勤災害 裁判例 通信の秘密 裁判例 貞操権 慰謝料 裁判例 転勤 裁判例 転籍 裁判例 電子契約 裁判例 電子署名 裁判例 同性婚 裁判例 独占禁止法 裁判例 内縁 裁判例 内定取り消し 裁判例 内定取消 裁判例 内部統制システム 裁判例 二次創作 裁判例 日本郵便 裁判例 熱中症 裁判例 能力不足 解雇 裁判例 脳死 裁判例 脳脊髄液減少症 裁判例 派遣 裁判例 判決 裁判例 違い 判決 判例 裁判例 判例 と 裁判例 判例 裁判例 とは 判例 裁判例 違い 秘密保持契約 裁判例 秘密録音 裁判例 非接触事故 裁判例 美容整形 裁判例 表現の自由 裁判例 表明保証 裁判例 評価損 裁判例 不正競争防止法 営業秘密 裁判例 不正競争防止法 裁判例 不貞 慰謝料 裁判例 不貞行為 慰謝料 裁判例 不貞行為 裁判例 不当解雇 裁判例 不動産 裁判例 浮気 慰謝料 裁判例 副業 裁判例 副業禁止 裁判例 分掌変更 裁判例 文書提出命令 裁判例 平和的生存権 裁判例 別居期間 裁判例 変形労働時間制 裁判例 弁護士会照会 裁判例 法の下の平等 裁判例 法人格否認の法理 裁判例 法務省 裁判例 忘れられる権利 裁判例 枕営業 裁判例 未払い残業代 裁判例 民事事件 裁判例 民事信託 裁判例 民事訴訟 裁判例 民泊 裁判例 民法 裁判例 無期転換 裁判例 無断欠勤 解雇 裁判例 名ばかり管理職 裁判例 名義株 裁判例 名古屋高裁 裁判例 名誉棄損 裁判例 名誉毀損 裁判例 免責不許可 裁判例 面会交流 裁判例 約款 裁判例 有給休暇 裁判例 有責配偶者 裁判例 予防接種 裁判例 離婚 裁判例 立ち退き料 裁判例 立退料 裁判例 類推解釈 裁判例 類推解釈の禁止 裁判例 礼金 裁判例 労災 裁判例 労災事故 裁判例 労働基準法 裁判例 労働基準法違反 裁判例 労働契約法20条 裁判例 労働裁判 裁判例 労働時間 裁判例 労働者性 裁判例 労働法 裁判例 和解 裁判例

「営業支援」に関する裁判例(59)平成26年 3月14日 東京地裁 平21(ワ)16019号 著作権侵害差止等請求事件

「営業支援」に関する裁判例(59)平成26年 3月14日 東京地裁 平21(ワ)16019号 著作権侵害差止等請求事件

裁判年月日  平成26年 3月14日  裁判所名  東京地裁  裁判区分  判決
事件番号  平21(ワ)16019号
事件名  著作権侵害差止等請求事件
裁判結果  一部認容、一部棄却  文献番号  2014WLJPCA03149002

要旨
◆原告に吸収合併される前の訴外A社(旧原告会社)が、訴外B社から営業譲渡に伴い著作権等の譲渡を受けた、別紙原告物件目録記載のデータベース部分(原告CDDB)を含む旅行業者向けシステムにつき、その開発、営業等を担当していた旧原告会社の社員であった被告Y2、被告Y3、被告Y4、被告Y5、被告Y6らが、旧原告会社を退職した後、被告Y1らと共に被告Y社を設立し、あるいは同社に入社して、被告CDDBを含む旅行業者向けシステムを制作し、顧客らに販売するに当たり、被告システムに含まれる被告CDDBを複製・頒布等する行為について、原告CDDBについて原告が有する著作権(複製権、翻案権、譲渡権、貸与権、公衆送信権)を侵害するものであるなどとして、被告らに対し、被告CDDBの複製、翻案、頒布、公衆送信(送信可能化を含む。)の差止め、損害賠償等を求めた事案において、被告CDDB(当初版・2006年版)及び被告CDDB(現行版)は、原告CDDBに依拠して制作された複製物に当たると認めるのが相当であるが、他方、被告CDDB(新版)については、原告CDDBの複製物ないし翻案物に該当しないというべきであるなどとして、請求の一部を認容した事例

裁判経過
控訴審 平成28年 1月19日 知財高裁 判決 平26(ネ)10038号 著作権侵害差止請求控訴事件

評釈
IP研究会・特許ニュース 13912号1頁
生田哲郎=森本晋・発明 111巻6号45頁
三井大有・コピライト 647号2頁(講演)
石神恒太郞・パテント 68巻10号23頁

参照条文
著作権法2条1項1号
著作権法2条1項10号の3
著作権法2条1項15号
著作権法12条の2第1項
著作権法10条3項
著作権法21条
著作権法23条1項
著作権法26条の2第1項
著作権法26条の3
著作権法27条
著作権法112条1項
著作権法112条2項
著作権法114条1項
民法709条
私的独占の禁止及び公正取引の確保に関する法律2条5項
私的独占の禁止及び公正取引の確保に関する法律3条
私的独占の禁止及び公正取引の確保に関する法律第十条第二項に規定する保険業を営む会社から除くものとして公正取引委員会規則で定める会社を定める規則21条

裁判年月日  平成26年 3月14日  裁判所名  東京地裁  裁判区分  判決
事件番号  平21(ワ)16019号
事件名  著作権侵害差止等請求事件
裁判結果  一部認容、一部棄却  文献番号  2014WLJPCA03149002

当事者 別紙当事者目録記載のとおり

 

主   文

1  被告アゼスタは,別紙被告物件目録記載1ないし21の各データベースを複製し,頒布し又は公衆送信(送信可能化を含む。)してはならない。
2  被告アゼスタは,別紙被告物件目録記載1ないし21の各データベースを格納したCD-ROM等の記録媒体を廃棄し,同各データベースの記録内容を消去せよ。
3  被告アゼスタ,被告Y1,被告Y2,被告Y3及び被告Y4は,原告に対し,連帯して,1億1215万1000円及びうち7680万8000円に対する平成21年5月28日から,うち3534万3000円に対する平成23年11月2日から,各支払済みまで年5分の割合による金員(ただし,1億0548万円及びうち7013万7000円に対する平成21年5月28日から,うち3534万3000円に対する平成23年11月2日から,各支払済みまで同割合による金員の限度で被告Y6と,5561万2000円及びこれに対する平成21年5月28日から支払済みまで同割合による金員の限度で被告Y5と,それぞれ連帯して)を支払え。
4  被告Y6は,原告に対し,被告アゼスタ,被告Y1,被告Y2,被告Y3及び被告Y4と連帯して,1億0548万円及びうち7013万7000円に対する平成21年5月28日から,うち3534万3000円に対する平成23年11月2日から,各支払済みまで年5分の割合による金員(ただし,4944万1000円及びこれに対する平成21年5月28日から支払済みまで同割合による金員の限度で被告Y5と連帯して)を支払え。
5  被告Y5は,原告に対し,被告アゼスタ,被告Y1,被告Y2,被告Y3及び被告Y4と連帯して,5561万2000円及びこれに対する平成21年5月28日から支払済みまで年5分の割合による金員(ただし,4944万1000円及びこれに対する平成21年5月28日から支払済みまで同割合による金員の限度で被告Y6と連帯して)を支払え。
6  原告のその余の請求をいずれも棄却する。
7  訴訟費用は,これを8分し,その7を原告の,その余を被告らの負担とする。
8  この判決は,第1項,第3項ないし第5項に限り仮に執行することができる。

事実及び理由

第1  請求の趣旨
1  被告らは,別紙被告物件目録記載の各データベースを複製,翻案,頒布及び公衆送信(送信可能化を含む。)してはならない。
2  被告らは,別紙被告物件目録記載の各データベースを格納したCD-ROM等の記録媒体を廃棄し,同各データベースの記録内容を消去せよ。
3  被告らは,原告に対し,連帯して,9億1037万0978円及びうち5億5349万6000円につき平成21年5月28日(被告Y6に対する訴状送達の日の翌日であり被告Y6以外の被告らに対する訴状送達日の翌日以降の日)から,うち1億1859万3600円につき平成23年11月2日(平成23年10月7日付け訴えの変更の申立書送達の日の翌日)から,うち2億3828万1378円につき平成25年1月31日(平成25年1月28日付け訴えの変更申立書送達の日の翌日)から,各支払済みまで年5分の割合による金員を支払え。
4  訴訟費用は被告らの負担とする。
5  仮執行宣言
第2  事案の概要
本件は,原告に吸収合併される前の訴外株式会社ブロードリーフ(以下「旧原告会社」という。なお,原告は,旧原告会社を平成22年1月1日に吸収合併するとともに商号を旧原告会社と同名に変更したものである。)が,訴外翼システム株式会社(以下「翼システム」という。)から営業譲渡に伴い著作権等の譲渡を受けた,別紙原告物件目録記載のデータベース部分(以下「原告CDDB」という。なお,「CDDB」はCDで提供されるマスターテーブルによるデータベースの趣旨である。)を含む旅行業者向けシステム「旅行業システムSP」(旧製品名「スーパーフロントマン 旅行業システム」。以下,この旧製品名のものも併せて「原告システム」という。)につき,その開発,営業等を担当していた旧原告会社の社員であった被告Y2,被告Y3,被告Y4,被告Y5,被告Y6らが,旧原告会社を退職した後,被告Y1らと共に被告アゼスタを設立し,あるいは同社に入社して,別紙被告物件目録記載1ないし22の各検索及び行程作成業務用データベース(以下,これらデータベースを総称して「被告CDDB」という。)を含む旅行業者向けシステム「旅 nesPro」(以下「被告システム」という。)を制作し,顧客らに販売するに当たり,被告システムに含まれる被告CDDBを複製・頒布等する行為について,(1)原告CDDBについて原告が有する著作権(複製権,翻案権,譲渡権,貸与権,公衆送信権)を侵害するものであるとして,著作権法112条1項に基づき,被告らに対し,被告CDDBの複製,翻案,頒布,公衆送信(送信可能化を含む。)の差止め(請求の趣旨1項),(2)著作権法112条2項に基づき,被告らに対し,被告CDDBを格納したCD-ROM等の記録媒体の廃棄とその記録内容の消去(請求の趣旨2項),(3)損害賠償として,被告らに対し,連帯して,主位的に,著作権法114条1項,民法709条に基づき,予備的に一般不法行為として民法709条に基づき,9億1037万0978円及びうち5億5349万6000円につき訴状送達の日の翌日以降の日である平成21年5月28日から,うち1億1859万3600円につき平成23年10月7日付け訴えの変更の申立書送達の日の翌日である平成23年11月2日から,うち2億3828万1378円につき平成25年1月28日付け訴えの変更の申立書送達の日の翌日である平成25年1月31日から,各支払済みまで民法所定の年5分の割合による遅延損害金の支払(請求の趣旨3項),をそれぞれ求めたものである。
1  前提事実(証拠等の摘示のない事実は当事者間に争いがない。なお,書証の枝番号は,特に記載しない限り省略する。以下,同様である。)
(1)  当事者
ア 原告(旧原告会社を含む)
旧原告会社は,翼システムの関連会社として,旧商号をアイ・ティー・エックス翼ネット株式会社とし,平成17年12月16日に設立された,コンピュータソフトウェアの開発,販売,情報提供サービス,情報処理サービス等を業とする会社である。旧原告会社は,平成18年8月1日,商号を株式会社ブロードリーフと変更した。〔甲81〕原告は,平成21年9月16日に設立されたところ(現在の商号への変更前の商号は「シー・ビー・ホールディングス株式会社」),本件訴え提起後の平成22年1月1日に,旧原告会社を吸収合併し,訴訟を承継した。
イ 被告ら
(ア) 被告アゼスタは,平成17年10月18日に設立されたコンピュータシステムの開発,各種情報提供サービス,各種情報処理サービス等を業とする株式会社である。被告アゼスタの従業員は平成22年9月時点で10名であり,その取扱商品は,被告システムのほかは,本件訴え提起(平成21年5月15日)の後である平成21年10月に販売を開始した貸切バスの予約,配車,運行管理システムである「バス快道」のみである。〔甲11(別紙2),25の2〕被告アゼスタは,東京都中央区に本社を置くほか,大阪市西区に大阪支店を,福岡市博多区に福岡支社を置いている。〔甲80〕
(イ) 被告Y1は,被告アゼスタの設立当初からの代表取締役である。同被告は,旧原告会社に在籍していたことはない。
(ウ) 被告Y2は,翼システム及び旧原告会社において原告システムの営業等を担当していた者であるところ,平成18年2月15日に旧原告会社を退職して被告アゼスタに転職し,営業を担当している。同被告は,平成19年12月以来,被告アゼスタの取締役である。〔甲62,乙40〕
(エ) 被告Y3は,翼システム及び旧原告会社において原告システムの営業等を担当していた者であるところ,平成18年2月28日に旧原告会社を退職して被告アゼスタに転職し,営業を担当している。同被告は,平成19年12月以来,被告アゼスタの取締役であり,営業グループのマネージャーである。〔甲62,乙41〕
(オ) 被告Y4は,翼システム及び旧原告会社において原告システムの営業を担当していた者であるところ,平成18年3月15日に旧原告会社を退職して被告アゼスタに転職し,営業を担当している。同被告は,現在被告アゼスタの従業員である。
(カ) 被告Y5は,翼システム及び旧原告会社において原告システムの開発を担当していた者であるところ,平成18年6月15日に旧原告会社を退職し,被告アゼスタに転職して開発を担当していたが,平成20年6月に被告アゼスタを退職した。同被告は,現在は,コンピュータソフトウェアの開発業務を行っている。〔乙39〕
(キ) 被告Y6(以下,被告アゼスタを除く,被告Y1,被告Y2,被告Y3,被告Y4,被告Y5及び被告Y6を,併せて「個人被告ら」という。)は,翼システム及び旧原告会社において原告システムの営業を担当していた者であるところ,平成18年11月30日に旧原告会社を退職して被告アゼスタに転職し,営業を担当している。同被告は,現在被告アゼスタの従業員であり,被告アゼスタの福岡営業所(福岡支社)の所長である。〔乙42〕
(ク) 被告アゼスタの代表取締役は被告Y1 1人であり,取締役は被告Y1,被告Y2,被告Y3の3名のみである。
(2)  原告システムの大要
ア 原告システムは,旧原告会社が設立される以前の平成8年1月に,翼システムが制作して販売を開始した「スーパーフロントマン 旅行業システム」を基本として,その後,翼システムにおいて改良されてきたものである。原告システムについては,平成17年12月30日に,同月16日に設立された旧原告会社が翼システムから原告システムを含むパッケージソフトウェアに関する営業の譲渡を受けるとともに,その著作権等の譲渡を受けた(なお,翼システム時代と,旧原告会社に譲渡された後を通じ,特に区別せず「原告システム」という。)。また,上記営業譲渡に伴い,原告システムの開発,営業等に携わってきた翼システムの従業員である,被告Y2,被告Y3,被告Y4,被告Y5,被告Y6らは,翼システムから旧原告会社に移籍した。
イ 原告システムは,国内旅行の旅行行程表,見積書作成のために必要な観光施設,宿泊施設,道路,時刻表などの各種データをデータベース化し,パソコンを用いて効率よく行程表,見積書等を作成することを可能とする旅行業者用システムである。旅行業者は,顧客の要望に合わせ,原告システムを用い,パソコンの画面表示に従って,出発地,帰着地,観光・宿泊施設,交通手段等を検索して選択すると,経路や所要時間等を原告システムにおいて自動的に検索して計算した上で,行程表や見積書も自動的に作成することができる。
ウ 原告CDDBは,地図ソフト(株式会社クレオ〔旧商号・株式会社アルプス社〕のプロアトラス)との連動により,観光・宿泊施設の所在地情報や旅行行程の経路を地図上へ表示する機能を実現するための設計や,インターネットとの連動により観光・宿泊施設のホームページへのアクセスを容易にする設計など,旅行業者の業務用データベースとして,機能性やユーザーの利便性の拡充を図るための工夫がされたデータベースである。
エ 商品としての原告システムの種類としては,検索業務,行程表・見積書作成,インターネット連動,地図連動機能を含むTR-P1のほか,これに加え,さらに売上集計管理,顧客管理機能をも含むTR-P4がある。〔甲1の1〕
オ 原告システムのカタログ(2009年〔平成21年〕版)によれば,検索業務,行程・見積作成の各機能の内容には,以下のものが含まれている。〔甲1の1〕
(検索業務)
時刻表検索,観光施設検索,宿泊施設検索,道路料金経路検索,インターネット検索,画像保存,地図検索。
(行程・見積作成)
行程表作成,見積書作成,損益検討書作成,受注型企画旅行見積書,包括見積書作成,修学旅行見積書,利用施設一覧印刷,観光施設案内書印刷,宿泊施設案内書印刷,添乗指示書作成,現地払い見積書,契約書(受注型・手配型),Mail送信(PDF),画像付き行程表出力。
カ 原告CDDBを含む原告システムで利用するデータベースは,米国のパベイシブ・ソフトウェア・インク(Pervasive Software Inc.なお,旧称 Btrieve Technologies Inc.)が販売するデータベースソフト「Btrieve(ビートリーブ)」(以下「ビートリーブ」という。)を用いて作成されている。ビートリーブにおいては,固有のデータアクセス言語であるAPIが使用されている。〔甲2,15頁〕
ビートリーブで構築,維持されるデータベースは,データベースの情報の単位であるレコードを,別のレコードと関連付ける処理機能を持つものである。
(3)  データベースについての一般的な説明及び正規化について
ア データベースにおいては,入力される情報は行と列から構成されるテーブルと呼ばれる表に格納される。テーブルは,二次元の表を使って表現されるが,この二次元のテーブル内を構成する縦の列と横の行のうち,縦の列は,これ以上細分化できない情報の集合であり,個々のデータの属性を表すものとして,「フィールド(アトリビュート,カラム)」と呼ばれている。各フィールド項目(列)においては,格納されるデータの種類及び型(テキスト,数値,通貨,Yes/Noなど)が決められている。
一つのテーブルの中には複数のフィールドが存在しているのが通常であるが,一つのテーブル内に重複して同じフィールド名を付けることはできず,一つのフィールド内にデータを格納するに当たって,異なる属性のデータを複数混在させて格納することもできないから,必ず同一の属性を持ったデータのみを格納しなければならないという制約がある。
テーブルの,上記二次元の表としてそのテーブル内を構成する縦の列と横の行のうち,横の行は,データベースを利用するユーザーが,最小単位の格納データとして検索等の操作をすることができる1件分のデータを意味し,これは「レコード」と呼ばれる。
そして,複数のテーブル同士を関連付けてデータの検索を行うタイプのデータモデルにおいては,データ検索時にテーブル内の検索したいレコードを他のレコードから識別するための情報を,「キー」として設定する必要がある。そして,テーブル内のレコードを一意的に識別できるフィールドを「候補キー」といい,この候補キーの中から任意に選んだフィールドを,一つのテーブル内に一つだけ,「プライマリー・キー(主キー)」として設定する必要がある。
具体的にどの候補キーをプライマリー・キーとするかについては,どの情報を管理したいのかというテーブル設計の目的によって,プライマリー・キーとして適当とされる候補キーは限定されることとなる。
そして,複数のテーブルがそれぞれ関係づけられることなく個々に存在しているのであれば,紙媒体の資料と異ならないこととなり,重複した内容があちこちに記載されている個々のテーブル内のデータをコンピュータ上の画面に複数立ち上げて,データの照合と統合作業を地道に行っていくこととなってしまい,データベースとしての価値がないことになる。そこで,複数のテーブル内に分散して格納されている個々のデータを,必要な時に必要な分だけ効率的に読み出し,これらのデータを統合・集計して,ユーザーが最終的に必要とする結果としてのデータのみを,コンピュータ上の画面に表示させるような仕組みが必要となる。この一連の作業を実行させるため,複数存在しているテーブル間を何らかの法則を使って関連付けしておくことが必要となり,この各テーブル間の関連付けのことを「リレーション」という。
具体的には,データベース開発者が,データベースの設計を行う際に,ユーザーが最終的に必要とする多数の検索結果を想定し,そのような検索結果を導き出すために相互に関連付けておきたいと考える各テーブルの内部に,同じ属性を持つデータが格納される共通のフィールドを事前に設定しておき,これらのテーブル間にリレーションを持たせることになる。これにより,相互のテーブル内の他のフィールド内に格納されている異なる性質のデータを自由に呼び出し,あたかも一つのテーブル内の情報を取り扱うのと同様にこれらのデータを統合・集計して,ユーザーが最終的に必要とする結果を,コンピュータ上の画面に一括して表示することができる。なお,これらのリレーション関係を持たせるフィールド同士は,必ずしも同一のフィールド名である必要はなく,フィールド内に格納されている実際のデータの属性が同一であれば,リレーションを持たせることができる。〔甲2〕
イ 原告CDDBに限らず,データベースにおいては,一般に,バージョンアップ等,見直しが行われる際に,「正規化」が検討されるのが通常である。「正規化」とは,主に,複数のテーブル同士を関連付けてデータの検索を行うタイプのデータモデルにおいて,各テーブル内に格納されている重複した無駄なデータを排除することで冗長度を減らし,効率的なデータアクセスを可能とする冗長性の排除を目的とする作業,及び,関連性の高いデータ群だけを別のテーブルに分離させることで当該データ群の独立性を高め,各テーブル内に格納されているデータの更新を行う際にデータ間で不整合が起こらないようにする不整合性の回避を目的とする作業のことをいう。〔甲2〕
(4)  翼システム,旧原告会社における被告Y1を除く個人被告らの行為等
被告Y1を除く個人被告らは,いずれも翼システムの社員であったところ,平成17年12月30日における翼システムから旧原告会社への原告システムを含む営業譲渡とともに,旧原告会社に移籍した者であるが,翼システム当時の原告システムへの関与の大要は,以下のとおりである。
ア 被告Y5は,平成2年4月22日,翼システムに入社し,それまでにプログラミングの知識・経験を有していたことから,電装システムの設計,検収等の業務を行ってきたが,平成6年4月ころに,翼システムにおいて,原告システムの開発が決まると,そのプロジェクトのリーダーとなり,旅行代理店へのヒアリング,要件定義,システム設計,データベースの設計・開発,スケジュール管理,営業・サポートへの指導・支援など,旧原告会社の退社に至るまで多岐にわたる業務をこなし,当初から原告システムの制作に携わった者として,原告システムの内容を熟知していた。〔乙39,1頁〕
イ 訴外A(以下「A」という。)は,平成7年7月1日に翼システムに入社し,被告Y5の下でサブリーダーとなるとともに,原告システムについてのプログラマーとして参加し,データ加工等を行った。その後,原告システムの開発リーダーとなり,原告システムの開発・改良の責任者として,旅行代理店へのヒアリング,要件定義,システム設計,データベースの設計・開発,スケジュール管理,営業・サポートへの指導・支援など多岐にわたる業務をこなし,翼システム内部においても,被告Y5とともに,原告システムの内容を最も熟知していた。〔乙38,2頁〕
ウ 被告Y2は,平成8年2月16日に翼システムに入社し,原告システムの販売やサポートに当たり,その主任を務めていた。
エ 被告Y3は,平成8年12月16日に翼システムに入社し,原告システムのシステムサポートを行うとともに,その営業を担当していた。
オ 被告Y6は,平成9年1月6日に,被告Y4は,平成9年12月24日に,それぞれ翼システムに入社し,原告システムの営業を担当していた。〔甲78〕
(5)  被告Y1を除く個人被告らの旧原告会社の退社と,被告Y1らによる被告アゼスタの設立
ア 被告アゼスタは,平成17年10月18日に設立され,出資金の過半を拠出した被告Y1がその代表取締役に就任した。
イ Aは,平成16年7月末,翼システムを退社し,その後,別会社に勤務した後,平成17年11月に被告アゼスタに入社し,平成19年12月25日から被告アゼスタの監査役に就任した。〔甲62〕
ウ 被告Y2は,平成18年2月15日に,被告Y3は,同月28日に,それぞれ旧原告会社を退社した。
エ 被告Y4は,平成18年3月15日に,被告Y5は,平成18年6月15日に,それぞれ旧原告会社を退社した。
オ 被告Y6は,平成18年10月末まで旧原告会社において原告システムの営業に関与した後に退社し,被告アゼスタに入社した。
(6)  被告システムの大要
ア 被告システムは,平成18年(2006年)6月に販売を開始したところ,観光・宿泊施設検索,行程表作成,見積書作成,原価計算等を行う営業ツールシステム,請求書作成,入金未収金管理,支払管理,各種集計表,顧客管理からなる管理業務システム等からなる。〔甲25の2〕
イ 被告CDDBには,被告システムのVer1.0向けのもの(被告物件目録記載1。以下「当初版」という。),被告システムVer1.5向けのもの(被告物件目録記載2。以下「2006年版」という。),被告システムVer2.0からVer3.1向けのもの(被告物件目録記載3~21。以下,これらを併せて「現行版」といい,そのうちのバージョンを特定する必要のあるもののみ,被告システムないし被告CDDBのバージョンとして記載する。),被告システムVer3.2向けのもの(被告物件目録記載22。以下「新版」という。)がある。なお,検索及び行程作成業務用データベースである被告CDDBとしては,当初版及び2006年版は同じものとなっている(以下,併せて「当初版・2006年版」ということがある。その意味では,別紙被告物件目録記載1と同2の被告CDDBは,内容としては同一である。)。
ウ 被告CDDBを含む被告システムで利用されるデータベースは,Microsoft社のSQL Server(以下「SQLサーバー」という。)を用いて作成されている。SQLサーバーはリレーショナル・データベースを開発,維持するために用いられるデータベースソフトであり,テーブル,フィールドを設定し,テーブル間をプライマリー・キーや候補キー等によって関係づけてデータベースを構築・維持するものである。
エ 原告CDDBに用いられているビートリーブと被告CDDBに用いられているSQLサーバーを比較すると,ビートリーブはナビゲーショナル型データベースに,SQLサーバーはリレーショナル型データベースに属するとされるところ,多数のデータが含まれている集合図をエクセルシートのような行と列からなる二次元の表で表現し,特定の表と表とを共通の項目であるキーを使って数学的・論理的に繋げることを意味する「リレーション」を構築することにより,表と表との相関関係を簡単に表現するという点で,同様のデータベースソフトである。ただし,両者では,テーブル内に格納されている個々のデータの読取り手順が異なる。すなわち,ナビゲーショナル型データベースでは,レコード指向アクセス方式が採用されており,テーブル内にある特定のレコードに格納されているデータを検索する際,レコードが存在するテーブルにアクセスし,そのレコードの位置を確認して,1レコードずつデータを取り出すというアクセス方式を採用しており,そのため,レコード指向アクセス方式において複数テーブル内の複数レコードに格納されている複数のデータを検索して取り出したい場合には,上記のような読取り手順を,1レコードごとに何度も繰り返すことで,1レコードずつ取り出してくる必要がある。これに対し,リレーショナル型データベースで採用されているセット指向アクセス方式では,複数テーブル内の複数レコードに格納されている複数のデータを取り出したい場合であっても,読出し条件さえ事前に設定しておけば,検索目的となっている複数データを,同時に一括して取り出してくることができるものとなっている。アクセス方法が異なれば,検索を実行するためのアプリケーションのロジックの組み立て方も異なることになるが,既に完成しているデータベースの全体構造の中に格納されている個々のデータを,どのような手順でどのように読み取っていくかという方法が異なるのみであり,アクセス方式の違い自体が,データベースの全体的構造に影響を与えるものではない。〔甲2〕
オ 被告システムでは,地図ソフトは株式会社クレオのプロアトラスSVと連動していた。また,被告CDDBでは,被告システムの平成18年6月の販売当初から,経路探索ソフトである「駅すぱあと(株式会社ヴァル研究所)」と連動させていたため,基本的に列車等の情報に関するデータについては,フェリーの情報などを除き不要となるものであった。そのため,列車等の情報をデータベース内に格納していない時期がある。具体的には,被告CDDB(当初版・2006年版)にはなかった「43路線マスタ」,「44便マスタ」,「45時刻マスタ」,「46路線構成マスタ」の各テーブルを,被告CDDB(現行版)で設けるに至った。〔甲23〕
(7)  原告システム及び原告CDDBの概要
ア 原告システムのテーブルは,マスターテーブルとエントリーテーブルからなる。マスターテーブルとは,最終的にユーザーが必要とする検索結果を作成するための基礎となるデータを格納しておくテーブルのことであり,データベースの提供時点で,基礎情報が予め格納されている提供マスターテーブルと,付加価値情報をユーザーが任意に後から格納していくことができるユーザーマスターテーブルとを含む。一方,エントリーテーブルとは,データベースの提供時点においてはいまだデータが格納されていない空のテーブルと,フィールドのみを枠組みとして用意しておき,システムを利用する過程において,ユーザー自身の行為を通じてテーブル内にユーザーのオリジナルデータが徐々に蓄積されていく形式をとるテーブルである。〔甲2,2~3頁〕
イ 原告システムを使用するユーザーである旅行業者は,マスターテーブル内に格納されたデータを使って検索した結果を利用して顧客向けの行程表を作成し,作成した行程表データは,ユーザー用のエントリーテーブル内に蓄積されることになる。
ウ 原告CDDBの内容としては,原告システムのうち,顧客情報関連のテーブル,部課・担当者関連のテーブル,仕入先関連のテーブル,システム内部で使用するにすぎないテーブル(科目テーブル,旅行種別テーブルなど),クーポン関連のテーブルなど,原告が提供するマスターテーブルと直接リレーションのないエントリーテーブルが除かれるほか,原告システムのマスターテーブルには存在するが原告CDDBには含まれないものとして,以下のテーブルがある。
(ア) 原告システムが原告CDDBを介さずに直接参照するテーブルであり,原告CDDBとリレーションをもってデータベースを構成しているものではないもの
・郵便番号テーブル(テーブルID;TRVZIP)
・ロード用地点テーブル(テーブルID;TRVROADK)
・メッセージテーブル(テーブルID;TRVMSG)
・メッセージボックス管理テーブル(テーブルID;TRVMSGBX)
・ファイル名が「TRVDMM」であるテーブル(乙23別紙3で行No.61,テーブルID不明とされているテーブル)
(イ) 原告システムの開発途上で作成されていたが,結局利用の予定がないことから,未完成のまま残っていたことを理由として,原告システムにおいて参照されることがないもの
・ランドマークテーブル(テーブルID;TRVRDMK)
・ランドマーク種別テーブル(テーブルID;TRVRDMKC)
・接続索引1テーブル(テーブルID;TRVROADH)
・接続索引2テーブル(テーブルID;TRVROADJ)・接続索引3テーブル(テーブルID;TRVROADN)
・接続索引4テーブル(テーブルID;TRVROADO)
・JR繁忙閑散期定義テーブル(テーブルID;TRVJRA)
・JR普通運賃表テーブル(テーブルID;TRVJRB)
・JR新幹線特急料金表テーブル(テーブルID;TRVJRC)
・JR特急グリーン等料金表テーブル(テーブルID;TRVJRD)
・JR特急区分定義テーブル(テーブルID;TRVJRE)
・JR特急都区市内駅定義テーブル(テーブルID;TRVJRF)
・観光施設IDテーブル(テーブルID;TRVSTID)
・海外地区・方面テーブル(テーブルID;TRVFRGPT)
エ 原告CDDBのマスターテーブルのテーブルIDと各テーブルの概要は,別紙1記載のとおりである(以下,単に「テーブル」という場合には,原告CDDB,被告CDDBを問わず,「マスターテーブル」をいうものとする。なお,別紙1原告CDDBのテーブルについて,緑塗りの表記がされているテーブルは,被告CDDBに一致するテーブルの存在が認められるものである。)。テーブル名は,各テーブルIDで識別されるテーブルの概要に基づき,整理の便宜のために付したものであり,テーブル番号も同様である(なお,別紙1では,テーブル番号は,被告CDDBとの対応関係の便宜等のため,23~27番を欠番としている。以下,各テーブルについては,特にテーブルIDを記載しない限り,別紙1記載のテーブル番号とテーブル名で表記する。ただし,後記のとおり,テーブルIDをTRVSTKMKとするものをテーブル番号及びテーブル名「23観光施設種別テーブル」と,テーブルIDをTRVSTSMとするものをテーブル番号及びテーブル名「24観光施設検索タイトルテーブル」として言及する場合がある。これらは,原告が,原告システムのインストール時にCD以外で提供しているテーブルであり,CDで提供されるマスターテーブルを構成するものではないことから,原告CDDBには含まれていない。)。
オ また,原告CDDBにおける各テーブルに存在するフィールドは,別紙3記載のとおりであり,上記テーブルの場合と同じく,各フィールド自体は各フィールドIDで識別されるところ,整理の便宜のためにフィールド名を付したものである。以下,各フィールドについても,特にフィールドIDを記載しない限り,別紙3記載のフィールド名のみで表記するか,これと併せてテーブル番号ないしフィールドIDで表記する。
カ 原告CDDBにおけるレコード数については別紙4記載の,原告CDDBにおけるフィールド間のリレーションのとり方は別紙5記載(原告CDDBにおけるリレーションについては別紙6,7も同内容)のとおりである(なお,被告CDDBと一致することに争いのある原告システムにおけるテーブル,フィールドの存在についての判断は後記のとおりである。)。
(8)  被告システム及び被告CDDBの概要
ア 被告システムのテーブルも,マスターテーブルとエントリーテーブルからなるところ,被告CDDBのマスターテーブルのIDは,別紙2の該当欄記載のとおりである(被告CDDBについても,テーブル番号及びテーブル名は,各テーブルIDで識別されるテーブルに含まれるフィールド等の概要に基づき,整理の便宜のために番号と名を付したものであり,各テーブルについて,特にテーブルIDを表記しない限り,別紙2記載のテーブル番号とテーブル名で表記する。なお,別紙2記載のテーブル名の括弧内の記載は省略する場合がある。)。
イ 被告CDDBにおける各テーブルのフィールドは,別紙3記載のとおりであり,各フィールド自体は各フィールドIDで識別されるところ,整理の便宜のためにフィールド名を付したものである。以下,各フィールドについても,特にフィールドIDを記載しない限り,別紙3記載のフィールド名のみで表記するか,これと併せてテーブル番号ないしフィールドIDで表記する(フィールド名の括弧内の記載は省略する場合がある。)。
ウ 被告CDDBにおけるレコード数については別紙4記載の,被告CDDBにおけるフィールド間のリレーションのとり方は,当初版・2006年版,現行版,新版につき,それぞれ別紙8,9,10各記載のとおりである(なお,原告CDDBと一致することに争いのある被告CDDBにおけるテーブル,フィールドの存在,及び存在に争いのあるフィールド間のリレーションのとり方についての判断は後記のとおりである。)。
2  争点
(1)  原告CDDBの著作物性及び被告CDDBが原告CDDBに依拠して作成された複製物ないし翻案物といえるか
(2)  被告らによる著作権(複製権,翻案権,譲渡権,貸与権,公衆送信権,送信可能化権)侵害についての共同不法行為の成否
(3)  一般不法行為の成否(予備的主張)
(4)  原告の行為の私的独占の禁止及び公正取引の確保に関する法律(以下「独占禁止法」という。)違反の可能性の有無
(5)  被告らの損害賠償義務の有無及び原告の損害額
第3  争点に関する当事者の主張
1  争点(1)(原告CDDBの著作物性及び被告CDDBが原告CDDBに依拠して作成された複製物ないし翻案物といえるか)について
〔原告の主張〕
(1) 原告CDDBの著作物性について
ア 原告CDDBは,旅行業者が原告システムを使って行程表作成の業務を行うに当たって必要となる情報を選択して,観光施設データ,宿泊施設データ,全国各地の主要道路の道路地点,隣接する道路地点間の大型観光バスの移動時間・距離,有料道路・高速道路の料金データ,鉄道・飛行機・フェリーに関する路線,駅,時刻表等の様々な情報を多項目にわたって収集・蓄積した情報の集合物であり,かつこれらの情報を格納する42個のマスターテーブル内に合計405個のフィールド項目を配し,各テーブル間をプライマリー・キーや候補キー等によって有機的に関連付けることで,旅行業者が顧客のニーズに合わせた行程表を作成する際,観光施設,宿泊施設,交通手段,経路,スケジュール(出発時間,到着時間,滞在時間など)をどのようにすべきかといった事項を,検索結果の情報を適宜選択することによって決定していくことができるような体系的構成を持つ,情報の膨大な分類体系である(甲1の1,甲29,30,54,55)。
イ 原告CDDBの体系的構成は他に依拠することなく構築されたものであり,かつ,原告CDDBの各テーブルに格納される情報は網羅的なものではないし,機械的に選択されたものでもなく,修学旅行,慰安旅行など主として団体旅行における顧客のニーズという観点から行程表作成に必要となる情報が選択されて各テーブルに格納されているものであるから,原告CDDBは著作者の個性が表れているものであり,著作物として保護されるべき創作性を有している。
ウ 原告CDDBは,旅行業者が検索及び行程表作成業務で必要となる情報を42個のマスターテーブルに分類して格納し,各マスターテーブル内には合計405個のフィールド項目を配し,各マスターテーブルごとに各フィールド項目として旅行業者が必要とすると思われる情報を多項目にわたって詳細に採り上げ,プライマリー・キーや候補キーなどによって各テーブルを有機的に関連付けて,効率的に必要とする情報を検索することができるような体系的構成を持つ膨大な規模の情報分類体系であり,かかる体系的構成を持つ原告CDDBを使用することにより,旅行業者が行程表作成業務で必要となる情報を効率的に検索できる。
エ 原告CDDBの体系的構成は,旅行業に関わる様々な情報について,行程表作成に必要な情報が備わり行程表作成のための情報検索が可能となるように,種類別・関連別にカテゴリー分けを行い,テーブル及び情報項目(フィールド)を設定し,各テーブル間にリレーションを取っているものであり,知的活動を経て作成されたものである(甲2の15頁以下)。
原告CDDBにおけるこのような体系的構成を持つ膨大な規模の情報分類体系は,他に依拠して構築されたものではなく,オリジナルに構築されたものである(甲63,乙38,39)。
したがって,原告CDDBには著作物の保護要件を充足する創作性がある。
オ 原告CDDBは42個のマスターテーブル内に合計405個のフィールド項目を配しているところ,これらも情報の集合物であり,行程表作成に関する多数の情報項目の中から旅行業システムにおけるデータベースのフィールド項目として何を取り上げるべきかという知的活動を経て,405個のフィールド項目を選択しているものである。かかるフィールド項目の選択もデータベースにおける情報の選択に該当し,どのフィールド項目を選択するかについては選択の幅があり著作者の個性が表れるものであるから,原告CDDBは,情報の選択について著作物の保護要件を充足する創作性があるといえる。
また,原告CDDBの各テーブルには,旅行業者が修学旅行,慰安旅行など主として団体旅行における顧客のニーズに合わせて原告システムを使って行程表作成の業務を行うに当たって必要となる情報が選択されて格納されている。かかる情報の選択は,基本的に網羅的であるわけでもなく,機械的であるわけでもないので,原告CDDBの42個のテーブルに格納されている各情報の集合物には,情報の選択に創作性があるといえる。
すなわち,原告CDDBでは,市販の一般情報誌,旅行業者向けの専門誌,インターネット,ユーザーからの情報提供等から得られる膨大な情報のうち,旅行業者の利用目的を考慮した上で必要となる情報を選別し,そこで選別されたデータを独自の基準によって作成された各テーブル内の各フィールド内に格納することにより,データベースが体系的構成及び情報の集合物として構築されているものである。原告CDDBにおける情報の集合物は,例えば宿泊施設であれば全部機械的に格納するというような,形式的な条件を満たす情報を機械的に全て格納するというものではなく,情報の母集団(ここでは宿泊施設)から必要性(例えば団体旅行に利用可能な宿泊施設)の観点から選択して格納しているのであるから,どの情報を格納するかについては選択の幅があり,原告CDDBの各テーブルにおける情報の選択に著作物の保護要件を充足する創作性がある。
各テーブルの情報の集合物については,いずれにも情報の選択に創作性があるが,以下道路地点と道路の情報の選択について創作性のあることを例として詳述する。
カ 道路地点に関する情報の創作性について
データ自体のソースが原告CDDBにしかない情報として道路地点情報がある。したがって,もし原告CDDBの道路地点情報が他のデータベースに存在する場合,原告CDDBに依拠したことは否定できないこととなる。
後記のとおり,被告CDDBには原告CDDBの道路地点情報のほぼ全てが存在している。この道路地点に関する情報の選択について創作性があることについては,以下のとおり明らかである。
(ア) 「09地点名テーブル」の地点名称(道路地点名称)及び地点緯度・地点経度のデータ(以下「地点データ」という場合がある。)は,原告CDDBを使って経路検索をする場合の基本となる位置情報である。「20ホテル・旅館テーブル」や「21観光施設テーブル」などの施設データの「代表道路地点」などと結び付いたり,他のテーブル内に格納されている交通関係のデータなどと連動したりすることで,ユーザーが設定した旅行行程における具体的な所要時間,距離,有料道路通行時の料金情報等の算出をするための基礎情報となるデータであり,旅行行程の作成において重大な役割を果たしている(甲30の3頁以下)。
道路地点データは,例えば自動車のナビゲーションシステムにも格納されているが,旅行の行程を作成するのが目的である原告CDDBにおいては,運転者に対して道路案内を行うナビゲーションシステムほど数多くの道路地点データを選択する必要がないため,原告が道路地点データを選択するに当っては,必要に応じた道路地点データに絞って選択をしている。
具体的には,観光バスが通過するのに適切と考えられる道路上の地点,インターチェンジや観光施設等から最も近い交差点,ユーザーの要望を満たすのに適切な地点などを中心に,実際に選択作業を行うデータベース開発者自身が各々適切と考える任意の地点を地図上から選び出し,パソコンのマウスで地図上をクリックするという方法で,当該道路地点データを手作業で選択している。
(イ) 上記考慮に基づいて道路地点を決定した上,上記の方法により詳細な緯度経度情報を「09地点名テーブル」に格納していくことになるので,道路地点データは以下の①,②の二つの観点から選択の幅があり,著作者の個性が表れる原告らのオリジナルデータである。
① 「10道路テーブル」に格納されている道路上の,どの場所を選ぶか
② その場所のスペースから緯度・経度として具体的に詳細な地点としてどこ(原告CDDBでは,緯度・経度を0.1秒単位でデータとして格納している。)を選ぶか
原告CDDBにおいて選択された「09地点名テーブル」のデータは,上記①,②の過程を経て選択されたものであり著作者の個性が表れるものであるので,情報の選択に著作物の保護要件を充足する創作性があるといえる。
(ウ) このように地点データは,原告CDDBの各開発者自身の価値判断で独自に決定し選択した場所及び緯度・経度の情報であるので,この情報は原告CDDBにしか存在し得ない原告固有の情報である。したがって,原告CDDBのデータをデッドコピーしない限り,被告CDDBも含め,他のデータベースにおける道路地点データが原告CDDBと一致することはあり得ない(甲30,32,34,39,47~49)。
キ 道路データの選択の創作性
原告CDDBでは基本的に大型観光バスによる移動を前提とする行程表作成のためのデータを提供することを目的にしていることから,道路テーブルに格納すべき道路については,その観点から選択がされている。原告CDDBの「10道路テーブル」では,国道,高速道路,有料道路,都市高速道路(首都高速など)を基本的に全て格納しているが,都道府県道,一般道路については,原告CDDBで選択された「20ホテル・旅館テーブル」のホテル・旅館の所在地情報,「21観光施設テーブル」の観光施設所在地情報なども踏まえ,大型観光バスによる移動に適切な道路を選択して格納している(甲30,31の1~3,甲33,47~49)。原告CDDBの道路テーブルのデータは,このような過程を経て選択されたものであり著作者の個性が表れるものであるので,情報の選択に著作物の保護要件を充足する創作性がある。
ク 以上のとおり,原告CDDBには,体系的構成及び情報の選択のいずれにおいてもデータベースの著作物として保護されるべき創作性がある。
(2) 被告CDDBが原告CDDBの複製ないし翻案であることについて
ア 具体的対比
(ア) 被告CDDBも,原告CDDBと同じく,旅行業者が旅行行程表を作成するに当たって必要となる,観光施設データ,宿泊施設データ,全国各地の主要道路に関する時間・距離・料金データ等の情報が収集・蓄積されたものであり,これらを蓄積するテーブルやフィールド項目を有し,各テーブル間をプライマリー・キーや候補キー等によって有機的に関連付けることで,旅行業者が必要とする情報を効率的に検索できるようにした機能と構造を持つ情報の分類体系である(甲54,55)。
なお,被告システムに含まれるデータベースには,CD-ROM及びインターネットを通じて提供される被告CDDBの他にユーザーが使用するハードウェアに被告システムをインストールする際に作成されるエントリーテーブルがあるが,エントリーテーブルにはユーザーが自ら作成する見積関係,売上関係,顧客関係などのデータが格納される。
(イ) 体系的構成の類似性
a テーブルの種類及び数
(a) 被告CDDB(当初版・2006年版)
被告CDDB(当初版・2006年版)に含まれる31個のマスターテーブルのうち29個のマスターテーブルは,原告CDDBに含まれる27個のマスターテーブル(別紙1の原告CDDBのテーブル番号01,02,05~22,28~32,42,44の各テーブル)と一致する。なお,原告CDDBのテーブル番号20,21,22に対応する被告CDDBのテーブルについては,正規化などによる変動があるが実質的に対応関係のあるテーブルとなっている。「29個」と「27個」と一致数が異なるのは,この正規化を行っているためで,被告CDDB(当初版・2006年版)では2個テーブルが増えている。すなわち,原告CDDBの「20ホテル・旅館テーブル」,「21観光施設テーブル」,「22観光施設備考テーブル」の3テーブルに対応するのが被告CDDB(当初版・2006年版)の「21施設マスタ」,「29旅館マスタ基本」,「23観光マスタ基本」,「26観光料金マスタ」,「25観光料金種別マスタ」の5テーブル(2テーブル増加)であり,原告CDDB側でカウントするとテーブル数は27個になり,被告CDDB側でカウントすると29個になる。
なお,原告CDDBと一致していない被告CDDB(当初版・2006年版)の2個のテーブル「27観光種別マスタ」と「28観光詳細種別マスタ」についても,CDで提供されるのではなく,原告システムをユーザーのハードウェア内にインストールした際に作成される原告マスターテーブルの中に,これら二つのテーブルと完全に一致するマスターテーブル(テーブル番号23,24)が存在している(甲3の別紙2のNo.23,24,甲23の3頁(2)②)ので,実質的には,被告CDDB(当初版・2006年版)に存在する31個のマスターテーブルの全てが,原告のマスターテーブルと一致しているといえる。
しかも,被告CDDB(当初版・2006年版)に存在する原告CDDBのテーブル,フィールドに対応するテーブル,フィールドには,原告CDDBのテーブルIDとフィールドIDがデッドコピーされてそのまま使われている(甲9,23,54,55)ことからも,原告CDDBと被告CDDB(当初版・2006年版)のテーブル,フィールドが一致していることは明らかである。
(b) 被告CDDB(現行版)
被告CDDB(現行版)に含まれる26個のマスターテーブルのうち24個のマスターテーブルは,原告CDDBに含まれる23個のマスターテーブル(別紙1の原告CDDBのテーブル番号01,02,05ないし12,14,15,20~22,32~34,36,39,40,42,43)と一致する。正規化を行っているため,一致するテーブルを被告CDDB(現行版)でカウントすると1個テーブルが増えている。すなわち,原告CDDBの「20ホテル・旅館テーブル」,「21観光施設テーブル」,「22観光施設備考テーブル」の3テーブルに対応するのが被告CDDB(現行版)の「21施設マスタ」,「29宿泊施設マスタ」,「23観光施設マスタ」,「26観光料金マスタ」,「25観光料金種別マスタ」の5テーブル(2テーブル増加)であり,原告CDDB「39便テーブル」,「40運行日定義テーブル」の2テーブルに対応するのが現行版の「44便マスタ」の1テーブル(1テーブル減少)であるため,一致する数を原告CDDB側でカウントするとテーブル数は23個になり,被告CDDB(現行版)側でカウントすると24個になる。
上記のとおり原告CDDBと一致していない被告CDDB(現行版)の2個のテーブル「27観光種別マスタ」(テーブルID;M_KANKO_SBT)と「28観光詳細種別マスタ」(テーブルID;M_KANKO_SYOSAI_SBT)についても,CDで提供されるのではなく,ユーザーのハードウェア内に原告システムをインストールした際に作成される原告マスターテーブルの中に,これら二つのテーブル(テーブル番号23,24)と完全に一致するマスターテーブルが存在しているため(甲3の別紙2の?23,24,甲23の3頁(2)②),実質的には被告CDDB(現行版)に存在する26個のマスターテーブルの全てが,原告のマスターテーブルと一致しているといえる。
また,被告CDDB(現行版)では,原告CDDBのテーブル,フィールドに対応するテーブル,フィールドのIDは,被告CDDB(当初版・2006年版)で使っていた原告CDDBのID(甲9,23,54,55)から変更してはいるが,デッドコピーしたIDのみを変えただけであり,原告CDDBに対応するテーブル,フィールドが被告CDDB(現行版)に存在することは,被告CDDB(現行版)も被告CDDB(当初版・2006年版)の場合と何ら変わっていない。
(c) 被告CDDB(新版)
被告CDDB(新版)に含まれる29個のマスターテーブルのうち25個のマスターテーブルは,原告CDDBに含まれる20個のマスターテーブル(別紙1の原告CDDBのテーブル番号01,02,06,09~12,14,15,20~22,32~34,36,39,40,42,43)と一致する。
正規化を行っているため,一致するテーブルを被告CDDB(新版)でカウントすると5個テーブルが増えている。すなわち,原告CDDBの「20ホテル・旅館テーブル」,「21観光施設テーブル」,「22観光施設備考テーブル」の3テーブルに対応するのが新版の「21施設マスタ」,「29宿泊施設マスタ」,「23観光施設マスタ」,「130食事土産マスタ」,「26観光料金マスタ」,「25観光料金種別マスタ」,「131施設別詳細種別マスタ」,「132施設種別マスタ」,「133施設詳細種別マスタ」の9テーブル(6テーブル増加)であり,原告CDDBの「39便テーブル」,「40運行日定義テーブル」の2テーブルに対応するのが被告CDDB(新版)の「44便マスタ」の1テーブル(1テーブル減少)であるため,一致する数を原告CDDB側でカウントするとテーブル数は20個になり,被告CDDB(新版)側でカウントすると25個になる。
以上のとおり,一部正規化による変動はあるものの,被告CDDB(新版)に含まれる29個のマスターテーブルのうち,25個のマスターテーブルは,原告CDDBに含まれる20個のマスターテーブルに対応し,一致しているものといえる。
また,被告CDDB(新版)でも,被告CDDB(現行版)と同様に,原告CDDBのテーブル,フィールドに対応するテーブル,フィールドのIDは,被告CDDB(当初版・2006年版)で使っていた原告CDDBのID(甲9,23,54,55)から変更してはいるものの,デッドコピーしたIDのみを変えただけであり,原告CDDBに対応するテーブル,フィールドが被告CDDB(新版)に存在することは,被告CDDB(新版)においても被告CDDB(当初版・2006年版)の場合と何ら変わっていない。
b 被告CDDBの各テーブルに存在するフィールドの種類及び数
(a) 被告CDDB(当初版・2006年版)
原告CDDBのマスターテーブルと一致するテーブルにおけるフィールド項目を見ると,原告CDDBに存在するフィールド項目のほぼ全てが被告CDDB(当初版・2006年版)に存在する(甲9,54,55)。テーブル管理のためのフィールドである被告CDDB(当初版・2006年版)における「登録日時」,「更新日時」,「削除区分」のフィールド13個を除いた場合の被告CDDBのフィールド数286個のうち252個が原告CDDBと一致している(甲55)。
しかも,被告CDDB(当初版・2006年版)に存在する原告CDDBのテーブル,フィールドに対応するテーブル,フィールドには,原告CDDBのテーブルIDとフィールドIDがデッドコピーされてそのまま使われていることからも,原告CDDBと被告CDDB(当初版・2006年版)のテーブル,フィールドが一致していることは明らかである。
(b) 被告CDDB(現行版)
原告CDDBのマスターテーブルと一致するテーブルにおけるフィールド項目を見ると,原告CDDBに存在するフィールド項目の大多数が被告CDDB(現行版)に存在する(甲54,55)。詳細は甲55のとおりであり,テーブル管理のためのフィールドである各テーブルの「作成日時」,「更新日時」,「削除区分」のフィールド合計72個を除いた場合の被告CDDB(現行版)のフィールド数173個のうち143個が原告CDDBと一致している(甲55の別紙2の12頁)。ちなみに,被告CDDBの現行版においてフィールドが増えたといっても,行程表作成のために検索対象となるデータではなく「作成日時」,「更新日時」,「削除区分」などテーブル管理のためのフィールドがその大部分である。
また,被告CDDB(現行版)では,原告CDDBのテーブル,フィールドに対応するテーブル,フィールドのIDは,被告CDDB(当初版・2006年版)で使っていた原告CDDBのID(甲9,23,54,55)から変更されてはいるが,デッドコピーしたIDを変えただけであり,原告CDDBに対応するテーブル,フィールドが被告CDDB(現行版)に存在することは,被告CDDB(当初版・2006年版)の場合と何ら変わっていない。
(c) 被告CDDB(新版)
原告CDDBのマスターテーブルと一致するテーブルにおけるフィールド項目は,原告CDDBに存在するフィールド項目の大多数が被告CDDB(新版)に存在する(甲54,55)。詳細は甲55のとおりであり,テーブル管理のためのフィールドである「作成日時」,「更新日時」,「削除区分」のフィールド75個を除いた場合の被告CDDB(新版)のフィールド数219個のうち146個が原告CDDBと一致している(甲55の別紙2の12頁)。
また,被告CDDB(新版)でも,被告CDDB(現行版)と同様に原告CDDBのテーブル,フィールドに対応するテーブル,フィールドのIDは,被告CDDB(当初版・2006年版)で使っていた原告CDDBのID(甲9,23,54,55)から変更されてはいるが,デッドコピーしたIDを変えただけであり,原告CDDBに対応するテーブル,フィールドが被告CDDB(新版)に存在することは,被告CDDB(当初版・2006年版)の場合と何ら変わっていない。
c テーブル間の関連付け
(a) 被告CDDB(当初版・2006年版)
原告CDDBのマスターテーブルと一致する29個のテーブルに関して,プライマリー・キーの設定も含め,原告CDDBに存在する関連付けのほぼ全てについて,同様の関連付け(リレーション)が被告CDDB(当初版・2006年版)に存在する(甲54の別紙1,甲55)。
なお,被告CDDB(当初版・2006年版)では,原告CDDBについて正規化がなされ,原告CDDBの「20ホテル・旅館テーブル」,「21観光施設テーブル」及び「22観光施設備考テーブル」の3テーブルに対応するテーブルとして,「21施設マスタ」,「29旅館マスタ基本」,「23観光マスタ基本」,「26観光料金マスタ」及び「25観光料金種別マスタ」の5テーブルを設けた。原告CDDBにおける「01市区町村テーブル」が「20ホテル・旅館テーブル」,「21観光施設テーブル」の二つのテーブルとリレーションを取っていることに対して,被告CDDBでは「4市区町村マスタ」は,原告CDDBの「20ホテル・旅館テーブル」,「21観光施設テーブル」の共通項目を括りだした上位のテーブルとなる「21施設マスタ」の一つのテーブルとのみリレーションを取っている。このことによりリレーションの線が半減しているが,これにより原告CDDBの全体としての体系的構成に実質的な変更が加えられているとはいえず,被告CDDB(当初版・2006年版)において原告CDDBの体系的構成は維持されている。
(b) 被告CDDB(現行版)
原告CDDBのマスターテーブルと一致する24個のテーブルに関して,プライマリー・キーの設定も含め,原告CDDBに存在する関連付けのほぼ全てについて,同じ関連付け(リレーション)が,被告CDDB(現行版)に存在する(甲54の別紙2,甲55)。
なお,被告CDDB(現行版)では,原告CDDBについてさらに正規化がなされ,原告CDDBの「39便テーブル」及び「40運行日定義テーブル」の2テーブルに対応するテーブルとして,「44便マスタ」の1テーブルが設けられた。この正規化の関係で,被告CDDBではこの2テーブルが1テーブルになっているため,原告CDDBでは「39便テーブル」と「40運行日定義テーブル」間にあるリレーションが被告CDDBにはない結果となっている。しかし,これにより原告CDDBの全体としての体系的構成に実質的な変更が加えられているとはいえず,被告CDDBにおいて原告CDDBの体系的構成は維持されている。
(c) 被告CDDB(新版)
原告CDDBのマスターテーブルと一致する25個のテーブルに関して,プライマリー・キーの設定も含め,原告CDDBに存在する関連付けのほぼ全てについて,同じ関連付け(リレーション)が,被告CDDB(新版)に存在する(甲54の別紙3)。
なお,被告CDDB(新版)では,従前の施設関係のテーブルについてさらに正規化がなされ,原告CDDBの「20ホテル・旅館テーブル」,「21観光施設テーブル」及び「22観光施設備考テーブル」の3テーブルに対応するテーブルとして,「21施設マスタ」,「29宿泊施設マスタ」,「23観光施設マスタ」,「130食事土産マスタ」,「26観光料金マスタ」,「25観光料金種別マスタ」,「132施設種別マスタ」,「133施設詳細種別マスタ」及び「131施設別詳細種別マスタ」の9テーブルを設けた。宿泊施設マスタや観光施設マスタ同様に施設マスタの下位のテーブルとして「130食事土産マスタ」を,施設の種別に関して大分類,中分類,小分類のテーブルとして「132施設種別マスタ」,「133施設詳細種別マスタ」,「131施設別詳細種別マスタ」をそれぞれ追加したものである。
また,被告CDDB(当初版・2006年版)及び被告CDDB(現行版)では,緯度経度情報を「34緯度経度マスタ」とその他のテーブル(「4市区町村マスタ」,「21施設マスタ」,「35地点マスタ」,「47駅マスタ」)で重複して保有しており,原告CDDBの体系的構成の特徴的部分をそのまま流用していたが,被告らは,原告の指摘により,原告CDDBに依拠しないでデータベースを作成する場合における緯度経度情報の重複保有の不合理さに気づき,被告CDDB(新版)では「34緯度経度マスタ」のテーブルを削除した。また,被告らは,同時に「34緯度経度マスタ」とリレーションが取られていたが実質的に利用されていなかった「32URL種別マスタ」,「33URL分類マスタ」も削除した。
かかるテーブルの追加や削除によって被告CDDBのテーブル間のリレーションに変更が生じてはいるが,これにより原告CDDBと一致するテーブル間における被告CDDBの全体としての体系的構成に実質的な変更が加えられているとはいえず,原告CDDBの体系的構成の大部分は維持されている。
d 小括
以上によれば,被告CDDBの当初版・2006年版,現行版,新版の各体系的構成は,それぞれの各テーブルのうち原告CDDBと一致するテーブル(当初版・2006年版は29個,現行版は24個,新版は20個)に関して,各テーブルの種類,各テーブルに存在するフィールドの種類,各テーブル間の関連付け(リレーション)の全ての点において,原告CDDBの体系的構成と実質的に類似していると認められる。
また,原告CDDBの体系的構成は上記のとおり創作性があるものであるところ,被告CDDBは,当初版・2006年版,現行版,新版のいずれにおいても,その大部分の体系的構成(テーブル,フィールド,リレーション)は原告CDDBと共通であるので,原告CDDBの創作性ある部分と類似しているといえる。
(ウ) 情報の選択の類似性
a フィールド項目の選択の類似性
(a) 被告CDDB(当初版・2006年版)
テーブル管理のためのフィールドである「登録日時」,「更新日時」,「削除区分」のフィールド13個を除いた場合の被告CDDBのフィールド数286個のうち252個が原告CDDBのフィールドと一致しており(甲55の別紙2の12頁),252個のフィールドに関しては原告CDDBのフィールド項目の選択を流用しているといえるので,この点に関して原被告CDDBは同一あるいは少なくとも類似しているといえる。
また,被告CDDB(当初版・2006年版)では,原告CDDBと対応するテーブル,フィールドのテーブルID,フィールドIDには原告CDDBのIDがデッドコピーされてそのまま使われていることからもフィールド項目の選択の同一性ないし類似性は裏付けられる。
(b) 被告CDDB(現行版)
テーブル管理のためのフィールドである「作成日時」,「更新日時」,「削除区分」のフィールド72個を除いた場合の被告CDDBのフィールド数173個のうち143個が原告CDDBと一致しており(甲55の別紙2の12頁),143個のフィールドに関しては原告CDDBのフィールド項目の選択を流用しているといえるので,この点に関して同一あるいは少なくとも類似しているといえる。
また,被告CDDB(現行版)では,原告CDDBのテーブル,フィールドに対応するテーブル,フィールドのIDは,被告CDDB(当初版・2006年版)で使っていた原告CDDBのIDから変更してはいるが,デッドコピーしたIDを変えただけであり,原告CDDBに対応するテーブル,フィールドが被告CDDB(現行版)に存在することは,被告CDDB(当初版・2006年版)の場合と何ら変わっていないので,このことからもフィールド項目の選択の同一性ないし類似性は裏付けられる。
(c) 被告CDDB(新版)
テーブル管理のためのフィールドである「作成日時」,「更新日時」,「削除区分」のフィールド75個を除いた場合の被告CDDBのフィールド数219個のうち146個が原告CDDBと一致しており(甲55の別紙2の12頁),146個のフィールドに関しては原告CDDBのフィールド項目の選択を流用しているといえるので,この点に関して原告CDDBと被告CDDBは,同一あるいは少なくとも類似しているといえる。
また,被告CDDB(新版)でも,原告CDDBのテーブル,フィールドに対応するテーブル,フィールドのIDは,当初版・2006年版で使っていた原告CDDBのIDから変更してはいるが,デッドコピーしたIDを変えただけであり,原告CDDBに対応するテーブル,フィールドが被告CDDB(新版)に存在することは,当初版・2006年版の場合と何ら変わっていないので,このことからもフィールド項目の選択の同一性ないし類似性は裏付けられる。
b 各テーブルに格納されたデータ(レコード)の選択の類似性
上記のとおり,原告CDDBの各テーブルにどのようなデータ(レコード)を登録するかについては基本的に選択の余地があるので,原告CDDBの各テーブルのレコードの集合物には情報の選択の創作性がある。
被告らは,別紙4被告らの主張欄記載のとおり,原告CDDBの各テーブルに格納されたレコード集合物の全部あるいはその一部となるレコードを集合物として,被告CDDBの対応するテーブルに直接コピーして入力し,内容を確認して修正等を行った上で入力してきたことを認めている。
また,被告CDDBには,当初版・2006年版,現行版,新版のいずれにも,原告CDDBのレコードをコピーして入力した痕跡が多数残されている。
このように被告CDDBの各テーブルのレコードは原告CDDBの各レコードの全部あるいはその一部となるレコードを集合物として,被告CDDBの対応するテーブルに直接コピーして入力したり,内容を確認して修正等を行った上で入力したものであるので,被告CDDBの各テーブルにおける情報の選択は原告CDDBと同一あるいは少なくとも類似しているといえる。
c 被告らの主張及びレコードの追加の点について
(a) 被告らは,現行版,新版に関して原告CDDBの各レコードについて確認し必要な修正を行ったから,当初版の被告CDDBのデータとはいえないし,ましてや原告CDDBのデータと同視されるべきものではないと主張するが,失当である。
例えば,被告らが流用を自認する原告CDDBの観光施設のレコード約1万4000件について電話番号が正しいかを確認し,誤りのあった電話番号を修正したとしても,観光施設としてどの施設を選択するかという原告が行った情報の選択に関して1万4000件の選択はそのまま維持されているので,被告CDDBには情報の選択の類似性があることは明らかである。
(b) 被告CDDBでは各テーブルにおいてレコードが追加されている場合があるが,原告CDDBのレコードの集合物に対してレコードが追加されたとしても,原告CDDBの集合物は維持されて存続しているので,追加されたレコードが膨大なものか否かにかかわらず,原告CDDBのレコードの集合物に関して,その部分は情報の選択について原告CDDBと類似していることは明らかである。
例えば,あるホテルが廃業になったためそのホテルに関するレコードが削除された場合でも,被告が流用を自認する原告CDDBのレコード9400件の大部分が削除されずに存続しているのであるから,被告らが流用した原告CDDBのレコードの集合物にする情報の選択について原告CDDBと類似していることは明らかである。
また,フィールドの追加,変更,削除に伴い原告CDDBのレコードのデータの変更がされる場合があるが,被告らが利用した原告CDDBのレコード,例えば,被告らが流用を自認する宿泊施設のレコード9400件についてのフィールド項目に追加,変更,削除があるだけであり,宿泊施設としてどの施設を選択するかという原告が行った情報の選択に関して9400件の選択はそのまま維持されているので,被告CDDBにおいてフィールド項目の追加,変更,削除があったとしても,情報の選択について原告CDDBとの類似性が維持されていることは明らかである。
(c) 被告らは,原告CDDBのデータを直接コピーするなどして被告CDDBへ格納した後にレコードを追加してレコード件数を増加させたので,データベース全体のレコード件数総数から見れば原告CDDBから直接コピーなどしたレコード件数の割合は低いと主張するが,意味のない主張である。
なぜならば,原告は被告らがその後追加したレコードについて責任を追及しているわけではないからである。仮に追加されたレコードが存在するとしても,被告らが直接コピーするなどした原告CDDBのテーブル,フィールドなどの体系的構成及びレコードの集合物自体は被告CDDBに維持・存続しているのであるから,著作権侵害及び一般不法行為の成立が妨げられることはないというべきである。
(d) 被告らは,原告CDDBに格納させるデータについて,創作性が認められない単なる客観的なデータであることを理由に,データベースの著作権による保護がないと主張するが,失当である。
原告CDDBにおいて選択された一つ一つのデータが道路地点の緯度経度情報や道路情報(道路名,道路名読み)など客観的データであったとしても,そのデータの選択には創作性があるので,データの集合物の無断流用は著作権侵害を構成する。情報の選択対象が客観的データであったとしてもデータベースの著作物になり得ることは当然のことであり,その創作性のある部分(情報の選択や体系的構成)を流用すれば,以下のとおり,著作権侵害が成立することは明らかである。
まず,被告CDDB(当初版・2006年版)は,別紙4の被告らの主張のとおり,被告が自認するだけでも,原告CDDBの以下の20個のテーブルのレコードの集合物を直接コピーするなどして利用しており,原告CDDBの情報の選択と同一あるいは少なくとも類似しているといえる。
・「01市区町村テーブル」
・「02地区・県名テーブル」
・「05緯度経度テーブル」
・「06URLアドレステーブル」
・「07URL種別テーブル」
・「08URL分類テーブル」
・「09地点名テーブル」
・「10道路テーブル」
・「11接続テーブル」
・「12禁止乗換テーブル」
・「13有料道路番号テーブル」
・「14区間料金テーブル」
・「15首都高速料金テーブル」
・「16道路構成地点テーブル」
・「17道路構成地点索引テーブル」
・「18市区町村通過道路索引テーブル」
・「19県範囲定義テーブル」
・「20ホテル・旅館テーブル」
・「21観光施設テーブル」
・「32駅テーブル」
被告らはレコードの集合物に対して一部追加,修正,削除を行ったと主張しているが,仮にそのような事実があったとしても,被告CDDBには原告CDDBのレコードの集合物の大部分が残っているので,原告CDDBにおける情報の選択との同一性あるいは少なくとも類似性は維持されている。
次に,被告CDDB(現行版)については,別紙4の被告らの主張のとおり,被告らが自認するだけでも,原告CDDBの以下の11個のテーブルのレコードの集合物を被告CDDB(当初版・2006年版)から引き継いで利用しており,原告CDDBの情報の選択と類似している。
・「05緯度経度テーブル」
・「06URLアドレステーブル」
・「09地点名テーブル」
・「10道路テーブル」
・「11接続テーブル」
・「12禁止乗換テーブル」
・「14区間料金テーブル」
・「15首都高速料金テーブル」
・「20ホテル・旅館テーブル」
・「21観光施設テーブル」
・「32駅テーブル」
被告らはレコードの集合物に一部追加,修正,削除を行ったと主張しているが,仮にそのような事実があったとしても,被告CDDBには原告CDDBのレコードの集合物の大部分が残っているので,原告CDDBにおける情報の選択との同一性あるいは少なくとも類似性は維持されている。
最後に,被告CDDB(新版)については,別紙4の被告らの主張のとおり,被告らが自認するだけでも,原告CDDBの以下の11個のテーブルのレコードの集合物を当初版・2006年版及び現行版から引き継いで利用しており,原告CDDBの情報の選択と類似している。
・「05緯度経度テーブル」
・「06URLアドレステーブル」
・「09地点名テーブル」
・「10道路テーブル」
・「11接続テーブル」
・「12禁止乗換テーブル」
・「14区間料金テーブル」
・「15首都高速料金テーブル」
・「20ホテル・旅館テーブル」
・「21観光施設テーブル」
・「32駅テーブル」
被告らはレコードの集合物に対して一部追加,修正,削除を行ったと主張しているが,仮にそのような事実があったとしても,被告CDDBには原告CDDBのレコードの集合物の大部分が残っているので,前記のとおり情報の選択の類似性は維持されている。
d 道路地点情報の選択の類似性
上記のとおり,被告CDDBにおいて,原告CDDBの各情報の選択の創作性のある部分が類似しているが,道路地点の情報の選択に関しては,以下のとおりである。
原告CDDBの道路地点情報はソースが原告CDDBにしかない原告固有の情報であり,もし原告CDDBの道路地点情報が他のデータベースに存在する場合,原告CDDBに依拠したことは否定できない。
また,原告CDDBでは,「10道路テーブル」に格納された道路に関して,行程表を作成する上で必要と考えられる適切な地点はどこかという考慮に基づいて道路地点を決定した上,詳細な緯度経度情報が「09地点名テーブル」に格納されていくことになるが,道路地点データには,①道路上のどの場所を選ぶか,②その場所の緯度経度として具体的にどこを選ぶかの二つの局面で情報の選択の幅があることは上記のとおりであり,著作者の個性が表れる原告らのオリジナルデータである。
被告らは別紙4のとおり,原告CDDBの「09地点名テーブル」に格納されている道路地点を,被告CDDB(当初版・2006年版)にコピーして入力した上で,追加・修正・削除し,現行版,新版では追加・更新したことを自認する。
被告CDDBでは,原告CDDBの「09地点名テーブル」に格納されている道路地点(道路上のどの場所か,具体的な緯度経度)の情報を「35地点マスタ」に流用し複製しているので,原告CDDBと同一であるか,あるいは少なくとも類似しているものといえる。また,原告CDDBの道路地点の選択(情報の選択)は上記のとおり創作性があるものであるところ,被告CDDBは原告CDDBの創作性ある部分と同一であるか,あるいは少なくとも類似しているものといえる。
類似状況の詳細は,以下のとおりである。
(a) 道路上のどの場所かについて
原告CDDB2005年9月版との比較(甲34)から明らかなように,被告CDDB(当初版・2006年版)では,99.98%,被告CDDB(現行版。2007年9月版,Ver2.53)では99.89%,被告CDDB(現行版。2009年4月版,Ver2.92)では98.38%,被告CDDB(現行版。2009年6月版,Ver2.94)では94.60%,被告CDDB(新版)では92.93%もの原告CDDBの地点に関する「道路上のどの場所か」というデータを流用している(甲34)。なお,データベースにおいては修正などの例外を除き,基本的に従前のデータが承継されることになるので,上記バージョン以外のバージョンの被告CDDBの地点データについても,原告CDDBからのデータの流用がされているものと推認することができる。
(b) その場所の緯度経度として具体的にどこを選ぶかについて
原告CDDBにおける「09地点名テーブル」における緯度経度データの作成は,独自の方法に基づいて全て手作業で行われているため,たとえ同様の方法を用いたとしても,人間がパソコンのマウスで地図上をクリックするという方法で行うものである以上,度分秒(しかも0.1秒単位)で表現された緯度経度の0.1秒単位まで緯度経度データが一件であっても一致することなどあり得ないことである。
それにもかかわらず,被告CDDBの「地点マスタ」の緯度経度データの完全一致率(緯度及び経度が0.1秒単位まで一致している率)は,平成21年(2009年)5月に被告らが原告から著作権侵害の訴えを提起されるときまで,実に92%以上にも達する極めて異常な状態にある(甲5,22,31の1~3,甲32,33,34,39)。
ちなみに,本件訴えが提起される直前の被告CDDB(現行版。2009年4月版,Ver2.92)の緯度経度データの完全一致率は,92.9%であったが,訴え提起直後の被告CDDB(現行版。2009年6月版,Ver2.94)では,8.1%に激減している。
原告CDDBの2005年9月版との比較で見ると,被告CDDB(現行版。2009年6月版,Ver2.94以降)や被告CDDB(新版)では,原告CDDBの緯度経度情報とは微妙に差を設けているが,被告CDDB(現行版)のVer2.94では-10秒から10秒の間に約92%,被告CDDB(新版)では,-10秒から10秒の間に約90%含まれている(甲34の別紙4の1,別紙5の1)ことから,平成21年(2009年)5月,被告らは,原告から著作権侵害の訴えを提起された後に,一定範囲内で数値が異なるような自動処理(例えば乱数発生機能を利用する変換プログラムを作成して,元の緯度経度データの数値に対して一斉に変換をかける等)や個別の改変等の工作を行っているものと推認される。しかし,このような工作を行ったとしても,原告CDDBの緯度経度情報をデッドコピーした後,隠蔽目的でデッドコピーした緯度経度に依拠して自動変換等の改変がされたすぎない(甲75の2の162頁以下)ものであるので,被告CDDBは,結局新版に至るまで,原告CDDBの道路地点情報の緯度経度情報を流用しているといえる。
このように,原告CDDBにおける道路地点情報の選択には創作性があるところ,被告CDDBは原告CDDBの創作性ある部分と同一であるか,あるいは少なくとも類似しているものといえる。
e 道路情報の選択の類似性
上記のとおり,被告CDDBにおいて,原告CDDBの情報の選択の創作性のある部分が類似しているが,都道府県道,一般道路に関する情報の選択に関しては,以下のとおりである。
原告CDDBでは都道府県道,一般道路については,原告CDDBで選択された「20ホテル・旅館テーブル」のホテル・旅館の所在地情報,「21観光施設テーブル」の観光施設所在地情報なども踏まえ,大型観光バスによる移動に適切な道路を選択して「10道路テーブル」に格納しているので,その情報の選択には創作性がある。
被告らは別紙4の被告らの主張のとおり,原告CDDBの「10道路テーブル」に格納されている道路情報を,被告CDDB(当初版・2006年版)にコピーして入力した上で,追加・修正・削除し,現行版,新版では追加・更新したことを自認する。
このように被告CDDBは,原告CDDBの「10道路テーブル」に格納されている道路のデータを「36道路マスタ」に流用し複製している(甲33,別表2,別表3の痕跡番号26ないし31)ので,道路データ(情報)の選択が原告CDDBと同一であるか,あるいは少なくとも類似しているものといえる。また,原告CDDBの道路(情報)の選択は上記のとおり創作性があるので,被告CDDBは原告CDDBの創作性ある部分と同一であるか,あるいは少なくとも類似しているものといえる。
f ダミーデータの選択の同一性
被告CDDBの当初版・2006年版と現行版には,原告CDDBにおけるダミーデータ『ダミーデータ「***」(道路名),「ン?ダミー」(道路名の読み)』が格納されている(甲21)。かかるダミーデータを格納するかどうかは原告CDDBにおける個性が表れているという意味で創作性ある情報の選択の一つであるところ,被告CDDBではこれと同一の情報の選択を行っている。
(エ) 小括
上記のとおり,被告CDDBは当初版・2006年版,現行版,新版のいずれにおいても,原告CDDBの体系的構成及び情報の選択において創作性ある部分と同一であるか少なくとも類似している。
なお,著作物の全部でなくとも著作物の創作性ある部分を複製すれば,著作権侵害は成立する。データベースの著作物でもこの理は同じである。
昭和60年9月の著作権審議会第七小委員会(データベース及びニューメディア関係)報告書でも,複製に関して「従来から複製権は著作物の全体的な複製だけでなく,その一部分であっても,著作物としての価値を持ち得る部分である限り,その部分にも及ぶと解釈されてきたところである。データベースにこの解釈を適用すると,著作物としての価値を持ち得るような形で,情報をある程度のまとまりで複製することについては複製権が及ぶと考えられる。」としており,データベースの一部複製等についても,データベースの著作者の複製権等が及ぶことは明らかである。
なお,被告らは著作権侵害及び一般不法行為が成立しないことの事情として被告システムの優位性を主張する。
しかし,著作権侵害及び一般不法行為の成立とシステムの優位性は関係がない。仮に被告システムに優位性があったとしても,被告CDDBが原告CDDBに依拠し類似性があるものであれば著作権侵害が成立するし,多大な労力費用をかけて開発された原告CDDBを流用した被告CDDBを含む被告システムを,原告CDDBを含む原告システムの販売地域と競合する地域に販売する行為は一般不法行為に該当するというべきである。このことは被告システムに優位性があろうとなかろうと変わりがない。
したがって,被告らの優位性に関する主張は失当である。
イ 依拠性
原告CDDBと被告CDDBとは,データベースとしての表現において,実質的な同一性ないし類似性が認められ,アクセス可能性やデッドコピーされた具体的痕跡からして依拠性があることは明らかである。被告CDDBの開発者であるA及び被告Y5が,翼システムあるいは翼システムから営業譲渡を受けた後は旧原告会社等において原告CDDBの開発に従事していたこと,被告Y3,被告Y2,被告Y4,被告Y6が,原告等において営業担当者として原告システム用の提供データベースである原告CDDB等を常に持ち歩き,顧客に対する原告CDDB等のインストール作業に従事していたこと,A,被告Y5,被告Y3,被告Y2,被告Y4,被告Y6が,原告等を退職した後,ごく短期間で膨大なデータベースの体系的構成及びデータよりなる被告CDDBを開発して販売を行っていること,並びに,被告CDDBには原告CDDBをデッドコピーした痕跡が新版に至るまで多数残されていることなどに鑑みると,A及び被告Y5は,原告CDDBの内容を設計レベルのコアとなる情報まで正確に認識した上で,これに依拠して被告CDDBを作成したものであると認められる。
この点に関して被告らは,一旦CSV(Character-Separated Values)ファイルに抽出した上で,被告CDDBに入力したと主張するが,CSVファイルに一旦出力した後に被告CDDBに入力したのであれば本来不都合が生じる「,(カンマ)」,「”(ダブルクォート)」等が含まれているデータのデッドコピーについても,何ら不都合を生じさせることなくデータ移行を行っていることに鑑みて,被告らの主張は明らかに不合理なもので到底信用することはできない。被告らは当初版・2006年版において,原告CDDBのデータを原告CDDBのテーブルID,フィールドIDと同一あるいは酷似したテーブルID,フィールドIDとする被告CDDBの各テーブル,フィールドにデッドコピーして移行させ,その後現行版,新版において改変等を行ったものである。
また,被告らは,CSVファイルに抽出した後に,一般のホームページや市販のDVDソフト等に掲載されている情報を閲覧,参照等しながら手作業による追加・修正・削除を行い,そのような作業を行った後に被告CDDBに入力したと主張するが,一般のホームページや市販のDVDソフト等に掲載されている情報を閲覧,参照等しながら手作業による追加・修正・削除を行うことはできないし,そもそも対比すべき正しいデータは存在しない。
むしろ,各施設の緯度経度情報やコード体系などをデッドコピーしていること,原告CDDBの道路テーブルにおける道路名フィールドで「***」,道路名カナフィールドで「ン ダミー」として登録されているデータがそのまま被告CDDBにも登録されていたことを含めデッドコピーの痕跡が存在する理由を被告らが何ら説明できない項目があることなどに鑑みて,被告らの主張は明らかに不合理なもので到底信用することはできない。被告らは当初版・2006年版において,原告CDDBのデータを原告CDDBのテーブルID,フィールドIDと同一あるいは酷似したテーブルID,フィールドIDとする被告CDDBの各テーブル,フィールドにデッドコピーして移行させ,その後現行版,新版において改変等を行ったものである。
このように,被告CDDBへのデータの収録過程について,CSVファイルを経由して,エクセル上で一般情報をもとに目視,手作業で追加・修正・削除を行ったとする被告らの主張は,極めて不合理である。
被告らは,原告の指摘のうちのタブ区切りの点のみ反論するが,その余は認否も反論もない。タブ区切りの点についても,データ移行に際して対象テーブルの全データを打ち出して,カンマやダブルクォートが含まれているかを確認し,含まれていない場合はカンマ区切りのCSVで,含まれている場合はタブ区切りのTSVで抽出するという被告ら主張の方法は,かなり手間暇のかかる作業であり,現実的でなく,信用できない。
〔被告らの主張〕
(1) 原告CDDBの著作物性について
そもそも,データベースにおいてはその作成目的や利用対象が同一である限り,その信頼性を維持するため,選択される情報は客観的基準に従ってある程度機械的に収集・選択されることになり,情報の選択について,データベース創作者の創作性が反映する可能性は制限される(乙28)。つまり,収集方針,選定基準というのは,一般的にはシステムの記憶容量が小さい時や,規模に制約のあるデータベースには重要であるが,規模が大きく真に利用価値のあるデータベースほどその重要性がなくなり,場合によっては不必要となるものである。
一方,体系的な構成についても,データベースが最大限活用されるためには,フォーマットの作成や体系設定は「没個性」的でかつ標準的な「汎用性」のあるものが望ましく,ユーザーの習慣性や効率性等を追及すれば一つの標準的な技術に収斂していく傾向があり,情報を網羅した完璧なデータベースであるほど創作性を認める余地は少なくなってしまうのであり,逆に,フォーマットや体系設定が個性的ということになれば,その分データベースの利用を狭めることになってしまうのである。原告の指摘する昭和60年9月の著作権審議会第七小委員会報告書においても,「没個性」,「汎用性」を指向するデータベースの特質などから,データベースについて創作的行為とすることのできない場合がかなりあるとの指摘がされている。
また,下級審裁判例(東京地裁平成12年3月17日判決・判例時報1714号128頁。いわゆるNTTタウンページ事件)においても,データベースにおける情報の選択,体系的な構成の基準となる創作性に関しては,当該データベースの目的・性格が考慮され,データベースの利便性向上のため,作成者として当然行うべき情報の選択はデータベース著作物の創作性については考慮されないことを明確にしたと解されている(乙28)。
実質的にも,データベースについて創作性の程度を低く設定すると,先行データベースの創作者が情報の体系的構成に創作者なりの何らかの構成を反映してデータベースを作成すると,後発者は同一の体系的構成からなるデータベースを制作できないだけでなく,当該データベースの一部を構成する情報の集合体を利用する場合にも当該部分で先行者の体系的構成における創作性が反映されていれば,先行データベースの一部複製とされるおそれがあり,データベースの自由な開発や情報の自由な利用が阻害されるから,この意味でも,データベースの創作性の程度を低く解すべきではない。
以上を踏まえると,原告が原告CDDBの特徴的部分,すなわち創作性のある部分であると主張する,観光施設テーブルの格納情報,ホテル・旅館テーブルの格納情報,行程表作成のために必要なテーブル,フィールド及びリレーションの設計などは,いずれも,旅行業者向けの行程表作成を目的としたデータベースという性質上,作成者として当然考慮すべきものであり,その情報の選択や体系設定はいずれも客観的・標準的な基準に従った没個性的・汎用的なものにすぎないから,仮にこれらの作業が相当程度の資本・労力の投下を要するものであったとしても,創作性は認められない。このようなものに安易に著作物性が認められれば,旅行業者向けのデータベースは,原告以外におよそ制作できないことになり,競争原理が全く機能せず,一社に市場を独占させる結果となり,利用者にとっての利便性向上を著しく阻害する。
したがって,原告CDDBは著作物として保護されるべき創作性を有しておらず,原告CDDBには著作物性がない。
(2) 被告CDDBが原告CDDBの複製ないし翻案に当たらないことについて
ア 被告アゼスタが,原告CDDBのデータの一部を被告CDDBに利用したことは認めるが,以下個別に詳述するとおり,それは,被告CDDBの作成過程において,原告CDDBのデータの一部について,一旦エクセルで読み込めるファイル形式であるCSVファイルで抽出するなどした上で,これらのデータに適宜追加・修正・削除を加えて,それを被告CDDBに収録,利用したり,一旦CSVファイルに抽出した上で,一般のホームページや市販のDVDソフト等に掲載されている情報を閲覧,参照等しながら手作業による追加・修正・削除を行い,そのような作業を行った後に被告CDDBに入力したものである。そのため,特段修正・削除を要しなかった箇所や修正漏れがあった箇所などについて,結果的に原告CDDBのデータと同一のものが被告CDDBに収録されている場合もあるが,これらのデータには,被告アゼスタにおいてホームページ等により情報の正確性等を確認したものも含まれている以上,原告CDDBのデータと同視されるべきものとはいえないのであって,被告アゼスタは,原告CDDBのデッドコピーなどしていない。
また,被告Y3,被告Y2及び被告Y4などの営業担当者は,原告システムのインストール用CDを所持し取り扱うことは会社から一切許されておらず,管理も厳重であったため所在すらもわからなかった。納品などのインストール作業はサポート部門に依頼するという厳格な社内ルールがあったため,上記の者らが手にしたことなど一度もなかった。
(ア) 当初版の被告CDDBのデータについて
被告アゼスタは,当初版の被告CDDBを開発するにあたり,独自に収集したデータに加えて,原告CDDBのデータの一部を,以下のように修正等の加工を施した上で利用した。
a 施設関係データ
(a) 観光施設データ
原告CDDB(2005年11月版)の観光施設データのうち,市販の料金ガイドに掲載されている観光施設(約1万4000件)について,一旦エクセルで読み込めるファイル形式(CSVファイル)で抽出した上で,公式ホームページや一般ホームページ(「ヤフー電話帳」等),料金ガイド等により,最新の情報(名称,名称カナ,郵便番号,電話・ファックス番号,住所)を確認し,適宜追加・修正・削除を加えた。また,原告CDDBでは,テーブル,フィールド等の変更なく,観光施設テーブル及び観光施設備考テーブルに登録できる観光料金の種類が非常に限られた種類の固定的な設定となってしまっており,複雑な料金体系を採用している観光施設に柔軟に対応できていなかった。すなわち,原告CDDBでは,1施設レコードについて,個人・団体ごとに,小学生/中学生/高校生/大人の4項目について,それぞれ4種類の料金しか登録できなかった。しかし,実際には,東京ディズニーランドのように,個人であっても,1デーパスポートからスターライトパスポートまで6種類の料金設定がされていたり,また小学生/中学生/高校生/大人の区別だけではなく,さらに大学生/シニア/障害者等の各属性に応じて細かく料金が異なっている施設や,通常の団体料金とは別に修学旅行等の場合に適用される特別な団体料金(学校団体料金)が設定されている施設も存在しており,原告CDDBはこのような施設の料金情報を十分反映できておらず,顧客のニーズに合致していなかった。
そこで,被告CDDBは,テーブル,フィールド等の変更なく,このような施設の複雑な料金体系をも正確に反映できるように適宜データを加工・修正した上で被告CDDB(「施設マスタ」,「観光マスタ基本」,「観光料金マスタ」)に機械的に移行入力したが,このような詳細な料金情報は料金ガイドにも掲載されておらず,各施設の公式ホームページ等により料金体系の種類・内容の詳細を1件ずつ確認して加工・修正作業を行わなければならないため,多大な労力を必要とした。
また,自然・神社等(山,川,湖沼,渚,城,神社,滝,温泉,海岸,寺,スキー場,公園)のデータ(約4500件)については,一般ホームページや市販のDVDソフト「プロアトラス2002 日本の風景1000」より最新の情報(名称,名称カナ,郵便番号,電話・ファックス番号,住所)を確認して,データを手入力し,さらに,原告CDDB(2005年11月版)のデータの一部についても,CSVファイルで抽出し,一般ホームページより最新の情報(名称,名称カナ,郵便番号,電話・ファックス番号,住所)を確認し,適宜データに追加・修正・削除を加えた上で,被告CDDB(「施設マスタ」,「観光マスタ基本」,「観光料金マスタ」)に機械的に移行入力した。
もっとも,顧客への被告システムの出荷(平成18年6月末ころ販売開始)にあたり,平成17年11月以降急ピッチで進められていた被告CDDBの開発作業が間に合わなかったこともあり,原告CDDBの観光施設データのうち,神社仏閣,ゴルフ場,食事処,ドライブイン,温泉地等に関するデータを中心に,被告CDDB(「施設マスタ」,「観光マスタ基本」,「観光料金マスタ」)にコピーした上で,誤記等の修正を加えた。
(b) 宿泊施設データ
原告CDDB(2005年11月版)の宿泊施設データのうち,「ホテル」区分,「旅館」区分,「その他」区分の「公共の宿」(国民宿舎等)のデータ(約9400件)についても,CSVファイルで抽出した上で,公式ホームページや一般に公開されているホームページ(「ヤフー電話帳」等)等により,最新の情報(名称,名称カナ,郵便番号,電話・ファックス番号,住所)を確認し,適宜追加・修正・削除を加えた上で,被告CDDB(「施設マスタ」,「旅館マスタ基本」)に機械的に移行入力した。
また,観光施設データと同様に,顧客への被告システムの出荷にあたり,被告CDDBの開発作業が間に合わなかったこともあり,原告CDDBの宿泊施設データのうち,ビジネスホテルに関するデータを中心に,コピーして被告CDDB(「施設マスタ」,「旅館マスタ基本」)に入力した上で,誤記等の修正を加えた。
b 交通関係データ
被告CDDBは,鉄道・路線バス・飛行機等の路線・運賃探索ソフトである「駅すぱあと」と連携させているため,原告CDDBと異なり鉄道や飛行機の路線探索,時刻表・料金に関するテーブルを備えておらず,これらのデータは入力していない。
ただし,原告CDDBの駅テーブルのデータ(約9200件)については,CSVファイルで抽出した上で,「駅すぱあと」と連携させるために,駅コード及び駅名のデータに修正を加えた上で,被告CDDB(「駅マスタ」)に機械的に移行入力した。
c 道路関係データ
原告CDDBの道路データ,地点データ等の道路関係データについて,コピーして被告CDDB(「道路名マスタ」,「地点マスタ」,「接続マスタ」等)に入力した上で,不要なデータの削除,誤記等の修正,追加を加えた。ただし,高速道路・有力道路の料金データは,原告CDDBと同様に,一般に公開されているホームページより入力したものである。
これらのデータは,情報の選択に独自の視点や発想が加わる余地がほとんどなく創作性を有しない。
d エリア関係データ
原告CDDBの都道府県データをコピーして被告CDDB(地区・都道府県マスタ)に入力し,原告CDDBの市区町村データについても,コピーして被告CDDB(市区町村マスタ)に入力した上で市区町村の合併等を確認して追加・削除を行ったが,これらのデータは公知の情報であり,選択の幅は皆無であり創作性はない。
(イ)現行版及び新版の被告CDDBのデータについて
被告アゼスタは,平成18年6月末ころの被告システム(当初版)の販売開始以降,現在まで6年以上もの長期間にわたり,膨大な手間・時間をかけて,顧客のニーズに対応してデータ内容を充実させており,継続して被告CDDBのデータを追加・修正・削除している(乙34)。
これにより,現行版及び新版の被告CDDBのデータは,最初に開発した当初版の被告CDDBのデータから一新され,データの件数・内容ともに大幅に変更している。レコード数だけをとっても,新版のレコード数(213万3846件)は当初版・2006年版(58万9592件)の3.6倍を超えるほどに至っている。また,当初版の被告CDDB開発の際に原告CDDBから利用したデータに関して,仮に新版の被告CDDBに同内容のデータが存在していたとしても,当該データは,当初版開発時から現在までの6年数か月の期間を通して,被告アゼスタがホームページや書籍等により情報の正確性等を幾度となく確認した上で被告CDDBに格納しているものであり,被告アゼスタの継続的な企業努力により,現在の情報を正しく反映しているデータとしての価値が新しく備わったものであるから,もはや6年以上も昔の当初版の被告CDDBのデータとはいえないし,ましてや原告CDDBのデータと同視されるべきものではない。
現行版及び新版の被告CDDBの当初版からの主なデータ変更部分は以下のとおりである。
a 施設関係データ
現行版の被告CDDBにおいて,顧客のニーズに対応するため,観光施設,宿泊施設,公共施設等のデータの大幅な拡充を行った結果,現行版(Ver2.99)では,施設マスタのレコード件数が約15万件になり,当初版のレコード件数(約5万7000件)の約2.6倍にまで増加し,さらに各種施設の新設・閉館や住所・料金等の内容変更などに伴い,2万7000件以上のデータを修正した。
また,現行版(Ver2.96)の被告CDDBにおいては,施設に関する緯度経度データが全て更新しており,新版の被告CDDBにおいて,緯度経度マスタのテーブルを削除している。
さらに,新版の被告CDDBにおいては,食事土産マスタ等のテーブルを新設し,全国「観光・運輸」総合カタログ2011年に掲載されたドライブイン等の食事施設や土産店について,公式ホームページや一般ホームページ等により最新の情報(名称,住所,電話・ファックス番号等)を確認し,データを追加・更新した。
b 交通関係データ
現行版の被告CDDBにおいては,「駅すぱあと」に収録されていないフェリー,ケーブルカー,ロープウェイ等の交通機関に対応するため,便マスタ,時刻マスタ等のテーブルを新設し,フェリーガイドやホームページ等を確認した上で,交通会社,時刻表,便名等のデータを新たに追加した。
c 道路関係データ
現行版の被告CDDBにおいて,顧客のニーズに対応するため,地点・道路,高速道路料金等のデータの大幅な拡充を行った結果,現行版(Ver2.99)では,レコード件数が,地点マスタ約2万2300件,道路マスタ約4800件,単経路マスタ約6万6000件,区間料金マスタ約176万8000件となり,当初版のレコード件数(地点マスタ約1万2800件,道路マスタ約2700件,接続マスタ約3万7000件,料金マスタ約36万3300件)からそれぞれ大幅に増加され,既存のデータについても,最新の情報に合わせて多数のデータが更新されている。同様に,新版の被告CDDBにおいても継続的にデータの追加・更新が行われている。
また,現行版(Ver2.94)の被告CDDBにおいては,地点に関する緯度経度データはすべて更新されている。
d エリア関係データ
現行版の被告CDDBにおいては,都道府県マスタ及び市区町村マスタのデータをすべて入力し直した。
また,現行版(Ver2.96)の被告CDDBにおいて,エリアに関する緯度経度データはすべて更新しており,新版の被告CDDBにおいては,緯度経度マスタのテーブルを削除している。
さらに,新版の被告CDDBにおいて,市区町村マスタに政令指定都市のデータを追加し,市区町村だけでなく政令市の検索まで可能となるようにした。新版の都道府県マスタについても,「緯度経路カラム」フィールドを追加して,都道府県庁位置を新規に登録した。
なお,原告は,CSVファイルに一旦出力した後に被告CDDBに入力したのであれば不都合が生じる「,(カンマ)」,「”(ダブルクォート)」等が含まれているデータのデッドコピーについても,不都合を生じさせることなくデータ移行を行っていることに鑑みて,被告らの主張は明らかに不合理なものであると主張するが,CSVファイルには,カンマ区切り(CSV:データをカンマで区切って並べたファイル形式)のみならずタブ区切り(TSV:データをタブ文字で区切って並べたファイル形式)も含まれ,カンマ区切り(CSV)では,カンマ,ダブルクォート等は文字化けや項目ずれを起こすため,被告アゼスタでも,カンマ,ダブルクォート等が含まれているデータについてはタブ区切り(TSV)を使って上記支障が生じないように対処しており,このことは,エクセルを使ってデータ入力・加工等を行う開発者であれば誰でも知っている常識的な知識である。
したがって,原告の上記主張は失当である。
イ 被告CDDBは原告CDDBに依拠したものではなく,原告が主張するような原告CDDBの複製物ないし翻案物ではない。
(ア) 被告らは,独自の設計思想に基づき被告CDDBを開発したものであり,体系的構成が異なる。
被告アゼスタが独自の設計思想に基づき開発した被告CDDB(当初版・2006年版,現行版,新版)では,原告CDDBとのテーブルの一致率(当初版・2006年版は49.0%,現行版は18.2%,新版は11.5%)及びフィールドの一致率(当初版・2006年版は44.1%,現行版は21.1%,新版は13.4%)からも明らかな通り,被告CDDBは,テーブルの内容(種類及び数),各テーブルに設定されたフィールド項目の内容,各テーブルの関連付けのあり方のいずれの点についても,原告CDDBの構造と大きく異なっている。
具体的には,まず,被告CDDBは,格納されている情報について,データベース上,相互に結合・連動する必要のある関連性の強いまとまりごとに類型化していくと,大きく分けて,中核となる施設情報とその他の三つの情報(道路情報,交通情報,エリア情報)に分類することができる。
このうち,施設情報は旅行の目的地や出発地に関する情報であるところ,そもそも,旅行業者向けシステムにおいては,旅行の目的地をどこにするかという点が最も肝要であり,その他の交通情報,道路情報及びエリア情報は,目的地に到達するためのいわば手段となる情報にすぎないから,目的地となる施設情報に関する体系的な構成をどのような内容とするかが,旅行業者向けシステムのデータベースの創作性を判断する上で決定的な要素となる。
実際に,本件のような旅行業者向けシステムと一般に普及しているルート・路線検索システム(カーナビゲーションシステムや「NAVITIME」(株式会社ナビタイムジャパン提供),「駅すぱあと」など)との間で,格納している情報に違いが現れる最たるものが施設情報である。すなわち,ルート・路線検索システムを利用しても出発地や目的地の基本情報(名称や電話番号)は検索することができる上,その間の距離や時間,料金も全て検索することができるところ,本件のような旅行業者向けシステムは,CDデータベース(CD-ROM)に格納する情報との関係では,旅行で訪れる観光施設や宿泊施設に関する詳細情報(営業時間,入館料,客室数,大浴場の有無等)を追加した点に特徴がある。
したがって,施設情報は,旅行業者向けシステムにおいて最も特徴的な情報であり,これがあることではじめて,当該システムがルート・路線検索システムとは異なる独自の検索機能を有しているものといえる。
よって,旅行業者向けシステムのデータベースにおいては,施設情報に関する体系的な構成をどのようにするかが,データベースの体系的な構成における創作性を最も大きく左右するものといえる。
以上を踏まえ,当初版・2006年版,現行版及び新版の被告CDDBの開発における被告アゼスタの独自の設計思想,原告CDDBとの差異等について詳論する。
a 当初版・2006年版
(a) 施設情報について
当初版の被告CDDBの開発当時(2006年ころ),日本人の旅行形態の主流は,旅先に行くこと自体(例えば京都に行く,ニューヨークに行くなど)やその旅先の有名な観光名所を巡る(例えば清水寺を巡る,自由の女神を巡るなど)ことを目的とするものから,体験する,味わう,参拝する,世界遺産を巡る,癒しの時間を過ごすなどといった個々人の興味に沿ったテーマを満足することを目的とする傾向に変わりつつあった。また,当該テーマ自体についても,時代の進展に応じてその多様化が進む傾向にあった。
そのため,被告アゼスタは,ゆくゆくは,そのようなテーマに沿った柔軟な検索や旅行計画の作成を利用者(旅行業者)が行うようになることを想定し,将来におけるデータベースとしての拡張性や格納効率,保守性を最大限に高めるという視点から,施設情報に関するデータベースを設計することとした。
このような意図のもと,被告アゼスタは,当初版・2006年版の被告CDDBにおいて,施設マスタという独立したマスターテーブルを上位テーブルとして用意し,宿泊施設マスタや観光施設マスタといった施設の類型別のマスターテーブルを,施設マスタの下位テーブルとして位置付ける格納方法をとることとし,最大2階層でデータを保持するテーブル構成を採用した。
これにより,当初版・2006年版の被告CDDBでは,電話番号や住所などの施設の基本情報は,「宿泊施設」や「観光施設」といった施設類型の区別なく,いったん全て施設マスタに格納する設計としたことから,上記のようなテーマに沿って施設を検索する場合に,データベースの構造上は,施設マスタのみを検索することで,テーマに沿った施設を検索することが可能な設計構造となったものである。さらに,現行版では,上記設計思想をもとに,下位テーブルではなく上位テーブルである施設マスタに「キーワード」のフィールドを設け,施設マスタを「世界遺産」,「祭り」,「花火」,「桜」,「紅葉」,「観光・食事100選」,「土産物100選」などのキーワードで検索できるようにしている。したがって,被告CDDBでは,いつでも施設類型別のマスターテーブル(例えば,食事施設,公共施設等)を増やすことができ,かつ,これらを上位テーブルの施設マスタで検索できる設計構造となっており,施設類型が多様化してもそれに対応できるような柔軟な設計となっている。現に,新版では,施設類型別のマスターテーブルとして食事・土産マスタを追加し,食事処及び土産施設の情報充実を図っている。
また,宿泊施設自体が観光施設を兼ねている複合施設など(例えば,善光寺宿坊常智院,鴨川ホテル三日月スパ三日月),必ずしも一つの目的地が,「宿泊施設」や「観光施設」といった単独の施設類型に当てはまらないものがあるところ,今後,格納する施設類型が多様化した場合,当該施設がどの施設類型に格納されているか直ちには判然としないケースが増えてくることが予想される。その場合,個々の施設類型から目的の施設を検索しようにも,格納箇所が判然とせず,検索できない可能性があるところ,被告CDDBの設計構造であれば,施設類型が判然としなくとも,上位テーブルである施設マスタを検索すれば目的地を検索することができる仕組みになっていることから,上記多様化にも柔軟に対応することができる。
このように被告CDDBにおいては,旅行業界の動向を見据え,顧客のニーズに応えることができるように,情報の体系付けやキーワードの付与に独自の創意工夫を凝らしている。
一方,原告CDDBにおける施設情報の格納方法は,テーマ別検索を意図していないため,ホテル・旅館テーブルと観光施設テーブルの二つの施設類型別のマスターテーブルでのみ,施設に関する情報を格納している。
そのため,データベースの構造上,目的の施設を検索する場合も,「ホテル・旅館」又は「観光」のいずれか一つのテーブルに絞って検索するか,両方のテーブルを別々に検索せざるを得ず,格納している施設に関する情報をまとめて1テーブルの中で検索できる設計構造になっていない。また,キーワード検索機能を持たない原告CDDBの場合,被告CDDBのようにテーマ別検索を可能とするためには,ホテル・旅館テーブルと観光施設テーブルの両方に「キーワード」のフィールドを追加し,両方のマスターテーブルを個別にすべて検索する必要があることから,被告CDDBと比べて,データベースとしての検索効率及び格納効率が悪いものとなっている。
さらには,原告CDDBの設計構造では,被告CDDBと異なり,施設類型のテーブルを「ホテル・旅館」と「観光」の二つ以外に追加するのがそもそも難しく,仮に追加して施設類型が多様化した場合も,格納した情報の施設類型が判然としない場合に個々の施設類型からの検索が困難なケースが出てくることになり,データベースとして柔軟な設計構造になっていない。
このように旅行業者向けシステムにとって最も重要かつ本質的な特徴といえる施設情報において,被告CDDBは,原告CDDBとは全く異なる独自の設計思想に基づいて情報の格納を行っている(乙19)。
(b) 施設情報以外について
道路情報の格納方法としては,ある地点までの最短経路を検索抽出するというダイクストラ法(乙21。最短距離だけに限らず,時間や費用等の要素も組み合わせ,目的に応じた最適な経路を検索抽出することを含む。)の考え方に従い格納するのが一般的であり,実際の利用者のニーズにも合致している。
そのため,ダイクストラ法は,上記「NAVITIME」やカーナビゲーションシステムなどルート・路線検索を行うシステムではほぼ必ず採用されている方法であり,当然,被告CDDBも原告CDDBもこれを採用している。
したがって,被告CDDBも原告CDDBも,ダイクストラ法という一般的でありふれた最短経路検索方法を採用する以上,これを実現するために,地点(始点)と地点(終点)並びにその間の距離及び所要時間等を格納していくという具体的な情報の格納方法それ自体において特段顕著な差異が生じ得るものではなく,このような格納方法自体には何ら創作性(著作物性)が認められない。
また,交通情報(路線情報,交通会社,便情報,時刻情報,運賃情報,距離情報など)は,情報の内容からして本来,格納する情報に取捨選択の余地があるものではなく,基本的には全ての情報を登録する必要があるものであるから,情報の取捨選択について特段顕著な差異が生じるものではない。
実際に,上記「NAVITIME」,「Yahoo!路線情報」,「駅すぱあと」といった他の多くのルート・路線検索システムにおいても,これらの情報は格納されている。
したがって,そもそも交通情報をどのように格納しようと,格納方法に創作性(著作物性)があるということはできず,著作権侵害の問題が生じるものではない。
そして,被告CDDBでは,頻繁に変更が行われる交通情報のデータメンテナンス作業の軽減の観点から,鉄道・路線バス・飛行機等の路線・運賃探索ソフトである「駅すぱあと」と連動させることとしたため,原告CDDBと異なり,鉄道や飛行機の路線探索,時刻表・料金に関する情報を一切格納しておらず,その分,テーブル及びフィールド構成も簡素なものとなっている。
したがって,交通情報の格納方法について,交通情報のデータメンテナンス(外部ソフトウェアを利用するか否か)に関する考え方の違いから,原告CDDBと被告CDDBとで全く異なる格納方法となっている。
さらに,エリア情報は,そもそも格納する情報が,地区(北海道,東北,関東,中部,関西等)と47都道府県しかないため,格納方法においても,特段顕著な差異が生じるものではなく,格納方法に創作性(著作物性)が認められるものではない。
したがって,そもそもエリア情報をどのように格納しようと,著作権侵害の問題が生じるものではない。
最後に,被告CDDBは,レコード修正を容易にするため,地区情報と都道府県情報を,原告CDDBと異なり,三つのマスターテーブルで保持することとしている上,原告CDDBには,被告CDDBと異なり,地区と都道府県情報に加え,「方面」情報が格納されている。
以上のとおり,エリア情報の格納方法についても,原告CDDBと被告CDDBとでは,一部異なる情報を格納している上,格納方法も異なっている。
b 現行版
(a) 行程・見積機能の当初版からの見直し
2006年版の被告システムから追加搭載した売上・顧客管理機能は,顧客からの評判もよく,システム安定性にも優れていた。そのため,被告アゼスタは,当初版で構築した行程・見積機能についても,この際,新たな外注先に全て見直してもらい,再構築してもらうこととした。
そして,被告アゼスタは,2007年4月,行程・見積機能を当初版から大きく変更した現行版を構築した。
これに伴い,被告CDDBに格納する各情報の格納方法についても次のとおり見直しが行われた。
(b) 施設情報の格納方法
施設情報の格納は,将来におけるテーマ別検索を可能とすることを目的として構築されていたことから,現行版においては,かかる設計思想を受け継ぐこととし,これを具体的に実現すべく,2008年10・11月版(Ver2.82)以降,施設マスタに「キーワード」のフィールドを設け,施設マスタの中から「世界遺産」,「祭り」,「花火」,「桜」,「紅葉」,「観光・食事100選」,「土産物100選」などのテーマに沿って検索できるようにした。
(c) 道路情報の格納方法
前記のとおり,被告CDDBも原告CDDBも,ダイクストラ法という一般的でありふれた最短経路検索方法を採用する以上,これを実現するために,地点(始点)と地点(終点)並びにその間の距離及び所要時間等を格納していくという具体的な情報の格納方法それ自体において特段顕著な差異が生じ得るものではなく,このような格納方法自体には何ら創作性(著作物性)が認められない。
もっとも,ダイクストラ法の特徴は,最短となる経路の探索をひたすら繰り返すことにあるところ,被告アゼスタは,翼システムには在籍していなかった開発担当者も交えて根本から設計思想を見直し,被告CDDBの現行版においては,経路の方向を上下区分で表現した「接続」の組み合わせにより禁止経路を構成する原告CDDBとは全く異なり,禁止経路を定義するための作業量を軽減して格納効率を向上させるべく,上下区分による「接続」概念を一新し,始点→中間点→終点の3地点の組み合わせで禁止経路情報を禁止経路マスタとして1テーブルに格納する方法で格納することとした。
この結果,被告CDDBでは,原告CDDBよりデータの読み込み回数を少なくすませて経路探索を高速で処理することが可能となり,以下の(i)ないし(v)のとおり,現行版の被告CDDBでは,道路情報の格納方法についても,原告CDDBとの間に大きな違いが生じることとなった。
(i) 原告CDDBの接続テーブルでは,接続番号というフィールド項目がプライマリー・キーとなっているのに対し,被告CDDBの単経路マスタでは,地点コード(始点),地点コード(終点),道路コードの三つのフィールド項目がプライマリー・キーとされている(乙9別紙5)。
これにより,例えば,地点Aから地点Bに道路1を介して接続される経路を登録する場合,被告CDDBでは,それぞれのフィールド項目がプライマリー・キーとなっているため重複して登録されることはないが,原告CDDBでは,接続番号というフィールド項目のみがプライマリー・キーとなっているため同一の経路が重複して登録され無駄なデータが作られる可能性がある。もしデータが重複登録されると,同じ地点間でも異なる所要時間や距離が誤って登録される可能性があり,不都合が生じる。その上,原告CDDBでは,地点(始点)がプライマリー・キーとなっていないため,経路検索において,効率の良いデータの読み込みができない設計となっている。
(ii) 被告CDDBの禁止経路マスタは,始点→中間点→終点の3地点の組み合わせで禁止経路情報を1テーブルに格納しているが,原告CDDBでは,経路と経路の組み合わせを接続テーブル及び禁止乗換テーブルの2テーブルに分けて格納しており,被告CDDBの禁止経路マスタと原告CDDBの禁止乗換テーブルは,その構造が異なっている(乙9別紙5)。
これは禁止経路の設定の仕方について原告CDDBと被告CDDBとで異なる考え方(原告CDDBは2地点と2地点の組み合わせで禁止経路を設定する考え方であるのに対し,被告CDDBは3地点の組み合わせで禁止経路を設定する考え方)を採用していることによる。
その結果,禁止経路に関し,原告CDDBでは,被告CDDBに比べて複雑な禁止経路定義設計となっているため,禁止経路を定義するための作業量が増えることから,被告CDDBより誤りが生じやすい構造になっている(乙9別紙5)。
(iii) 被告CDDBの区間料金マスタ及び通行料金マスタと,原告CDDBの区間料金テーブル及び首都高速料金テーブルを比較すると,被告CDDBの方が道路料金区分を備えている分,柔軟な設計となっている(乙9別紙5)。
例えば,新たに深夜早朝,通勤割引などのETC割引料金を追加する場合,被告CDDBでは,区間料金マスタのレコードを追加するだけで,フィールド追加などのテーブルの設計変更は不要である。
これに対し,原告CDDBの区間料金テーブルの構造では,必要な料金種類分のフィールドの追加が必須となる。なお,原告も認めるとおり,フィールドの追加はシステムへの影響が大きく容易でないが,レコードの追加は容易にできる(甲3,4頁)。
(iv) 原告CDDBの首都高速料金テーブルは,その名のとおり首都高速料金の情報だけを格納しているが,被告CDDBの通行料金マスタは,首都高速だけでなく,有料道路などの定額の通行料金の情報全てを格納する設計となっている(乙9別紙5)。
(v) 被告CDDBでは,原告CDDBの市区町村通過道路索引テーブル,道路構成地点索引テーブル,県範囲定義テーブル,道路構成地点テーブル,有料道路番号テーブルに対応するテーブルは存在しない。
(d) 交通情報の格納
交通情報については,そもそも格納方法に創作性(著作物性)があるものではない。もっとも,被告アゼスタでは,前記のとおり,当初版の被告CDDBにおいて,「駅すぱあと」と連動させることとしたため,原告CDDBと異なり,鉄道や飛行機の路線探索,時刻表・料金に関する情報を一切格納していなかったところ,利用者より,鉄道や飛行機以外のフェリーなどの路線やその時刻表等の情報も追加して欲しいといった要望があった。これを受けて,被告アゼスタでは,これらのフェリーなどの路線情報を格納するため,現行版において路線構成マスタ,路線マスタ,時刻マスタ,便マスタの各テーブルを新たに設計したものである。その結果,便情報や運行日の格納に関するテーブル構成にも違いが生じることとなった(乙9別紙6)。
したがって,交通情報の格納については,被告CDDBと原告CDDBとは,当初版からして「駅すぱあと」と連動させるか否かの点で基本的な設計思想が大きく異なっていたが,現行版ではさらにその違いが大きくなっている。
(e) 2006年版の売上・顧客管理機能との設計方針の統一
現行版では,被告データベースの行程・見積機能の部分について,上記の見直しの他に,2006年版の売上・顧客管理機能と設計方針を統一させるため,システムの機能向上,設計工程及び製造工程における品質確保や効率の追求という観点から,被告CDDBのフィールド構成等を再構築した。
具体的には,被告CDDBのフィールドの並び順を変更し,また,全テーブルにおいて作成日時,更新日時及び削除区分のフィールドを追加した。さらに,予備フィールド(別紙3の括弧内に「予備」と記載された,フラグ,区分,日付,数値等のフィールド)は全て削除し,施設情報のURLマスタに表示順フィールドを追加した。
c 新版
被告システムの新版は,平成23年4月4日,それまでの被告システムの現行版(Ver2.99)を再構築して発売した。これに伴い,被告CDDB部分についても内容が大きく変更した。
新版における設計思想は以下のとおりである。
(a) 施設情報の格納方法の変更
新版の被告CDDBでは,主に施設情報の格納につき,利用者のニーズと意識やライフスタイルの変化に対応し,さらにデータベースの拡張性,格納効率及び検索効率等の向上の観点から再構築がされた。
当初版においては,前記のとおり,施設情報の格納に関して,個々人の旅のテーマに沿った柔軟な検索や旅行計画の作成を利用者(旅行業者)が行えるようにするため,将来におけるデータベースとしての拡張性や安定性,検索効率等を考慮して,被告CDDBにおいて,施設マスタを上位テーブルとして用意して,ここに基本的な情報を集約し,いかなる検索テーマを設定しようと施設マスタという一つのマスターテーブルから全て検索できるようにし,宿泊施設マスタや観光施設マスタといった施設の類型別の詳細情報を収録したマスターテーブルを,施設マスタの下位テーブルとして位置付けるテーブル構成をとることとしていた。
新版の被告CDDBでも,上記設計思想をそのまま受け継ぎ,下位テーブルである類型別のマスターテーブルとして新たに食事・土産マスタを追加し,食事処及び土産施設の情報充実を図った。これは観光施設か宿泊施設かにかかわらず,ドライブインや名産品の土産店などのように食事のためや土産物を購入するためにだけ立ち寄ることができる施設について,これらに特化した情報である,開館・閉館時間や食事内容,土産内容等を充実してもらいたいとの利用者からのリクエストがあり,重要性が増したことから,観光施設や宿泊施設から独立させて追加したものである。
また,新版の被告CDDBでは,施設の種別及び詳細種別の格納を統合的に格納するため,施設種別マスタ,施設詳細種別マスタ及び施設別詳細種別マスタを追加した。
具体的には,現行版の被告CDDBまでは,観光施設の種別については施設マスタの中の「観光種別」のフィールド及び観光種別マスタと観光詳細種別マスタで格納していたのに対し,宿泊施設と公共施設の種別については施設マスタの中の「宿泊種別」,「公共施設種別」のフィールドのみで格納しており,施設によって施設の種別の格納の仕方が異なっていた。そこで,新版の被告CDDBでは,これらを一元的に整理し格納するため,施設の種別については,観光施設,宿泊施設,公共施設さらには新版で追加された食事処及び土産施設のいずれも,施設種別マスタ,施設詳細種別マスタ及び施設別詳細種別マスタの三つのテーブルで格納することとしたものである。これに伴い観光種別マスタ及び観光詳細種別マスタは削除した。それぞれのテーブル(マスタ)の格納情報の詳細は,施設を「宿泊」,「観光」,「公共」,「食事・土産」の四つに大分類し,そこから施設種別の中分類として施設種別マスタを用意し,小分類として施設詳細種別マスタを用意したものである。
これにより,例えば,ある一つの施設が神社・仏閣としても博物館としても分類されるような複合的な施設種別を持つ場合において,当該施設に割り当てられた一つの施設コードを使って,神社・仏閣としても博物館としても検索できるような構造になった。すなわち,神社・仏閣としても博物館としても検索されるようなキーワードを関連する格納情報の中に全て直接書き込んでおき文字列で検索できるようにする方法もあるが,データベースとしては施設コードで検索できるようにしておいた方が効率的であるし,データベースの開発時及び更新時における人為的ミスを低減することができる。また,施設の種別を増やしたい場合,食事・土産マスタのようなマスターテーブルとして追加するという方法もあるが,そこまで施設の詳細情報を入力する必要が現時点ではない場合に,施設種別マスタの「施設大種別」の中で追加レコードとして増やすことで対応することも可能となった。これにより検索テーマの種別を増やすことも容易となり,このことは被告のデータベース開発の設計思想にあるテーマ別検索を充実させることにもつながる。なお,現行版の被告CDDBで施設の種別を増やしたい場合,施設マスタの中のフィールドとして新たに追加する必要があり,単なるレコードの追加の場合に比べて,データベースを動作させるプログラムの開発及びその動作検証等に時間を要するなど,データベースの追加拡張が容易ではなかった。
このように,新版の被告CDDBでは,施設の種別につき,一元的に整理,格納することが可能となり,種別の追加が容易になった。
なお,原告CDDBには上記のようなテーブルはない上,施設の種別を増やそうにも,ホテル・旅館テーブル又は観光施設テーブルの中でのフィールドの追加という形でしか対応できない構造になっており,データベースとしての拡張性に乏しい構造となっており,その違いはより一層顕著なものとなっている。
その他にも,新版の被告CDDBでは,提携施設マスタ,提携種別マスタ及び提携会社マスタを追加した。これは,宿泊施設や観光施設等が,大手旅行会社や全国旅行業協会,旅行案内所などと提携している施設か否か,また,宿泊クーポンや食事クーポン等のクーポンを利用できる施設か否か,各会社のクーポンを発券できる施設か否かといった情報を新たに格納したものであり,これらも利用者からの要望に応えるために追加したものである。
また,新版の被告CDDBでは,既存の施設マスタ,観光施設マスタ,宿泊施設マスタにおいても,利用者からの要望をふまえ,「Eメール」(施設への連絡先),「団体受入区分」(団体客の受入れが可能か否か)及び「風呂,温泉効能」(施設内の風呂,温泉の効能)などのフィールドをそれぞれ追加,変更した。
以上のとおり,新版の被告CDDBでは,施設情報の格納方法が大きく変更されており,原告CDDBとは似ている点がないほど体系的な構成を大きく異にしている。
(b) その他の情報
その他の情報については,交通情報に関しては,システム画面上で表示した出発駅と到着駅の駅名で「駅すぱあと」の駅名と連動させるようにして,「駅すぱあと」による検索を可能にしているが,利用者の利便性を考えると駅名によってはシステム画面上で表示する駅名と「駅すぱあと」に登録されている駅名とを別名にしたい場合がある。
例えば,新千歳空港ではなく札幌空港(新千歳空港)と表示する,東京国際空港(羽田)ではなく羽田空港(東京国際空港)と表示する等のように,「駅すぱあと」の駅名ではなく通称で表示した方が利便性が高い,と考えられることによるものである。これらの別名を収録した「駅名(駅すぱあと)」のフィールドを,駅マスタに追加したりもした。
また,道路情報に関しては,地図上に表示するルート検索結果の経路表示をより一層地図上の道路に沿った曲線のように画面上表示するための座標データの情報を格納した「単経路補間マスタ」を追加したり,利用者の要望により道路名の略称でも検索できるように,例えば「中央自動車道」ではなく「中央道」で検索できるよう,「道路名略称」のフィールドを道路マスタに追加したりした。
また,エリア情報に関しては,利用者の要望により,政令指定都市でも検索できるように,「政令市区分」,「政令市コード」をフィールドとして市区町村マスタに追加したりした。
このように利用者からの要望やシステム操作上の利便性等をふまえ,施設情報以外の情報についてもテーブルやフィールドの変更等を行った。なお,これらの新規テーブルや新規フィールドは,原告CDDBには存在しない。
(イ) 原告CDDBと被告CDDBとは,実際のテーブル・フィールドの構造及びリレーションが異なる。
テーブル構造及びフィールド構造の違いに基づく原告CDDBと被告CDDB(新版)の機能等の差異の詳細には大きな違いがあり,被告CDDBが原告CDDBに依拠して作成されたものではないことは明らかである。とりわけ,前記のとおり,旅行業者向けシステムのデータベースにおいては,施設情報に関する体系的な構成をどのようにするかが,データベースの体系的な構成における創作性を最も大きく左右する。
そして,施設情報に関しては,当初版よりすでに,原告CDDBと被告CDDBとで設計思想が大きく異なっており,被告CDDBでは,施設マスタの下位テーブルとして観光施設マスタと宿泊施設マスタが位置付けられ,全ての施設が施設コードで体系立てられており,原告CDDBと体系的な構成を大きく異にしていた。その上さらに,新版の被告CDDBでは,観光施設種別だけではなく,宿泊施設や食事・土産施設,公共施設の施設種別も一元的に管理可能なテーブル構造に変更したことにより,今後どのような種別の施設を追加しても,施設種別の追加に伴うテーブル変更やフィールドの追加を生じさせないですむようになった。これに対し,原告CDDBでは,上位の施設テーブルが存在しないため,異なる種別の施設データを追加する場合には必ず種別ごとのテーブルを追加しなければならず,両CDDBの体系的な構成の違いに基づく機能の優劣も顕著となっている。
以上のように,異なる設計思想で開発された新版の被告CDDBと原告CDDBとは,旅行業者向けシステムのデータベースにおいて最も創作性を左右する施設情報において,もはや似ている点がないほど体系的な構成が異なっており,全く別物のデータベース構造となっている。
(ウ) 原告CDDBとは情報の選択も異なる。
被告アゼスタは,当初版の被告CDDBを開発するにあたり,独自に収集したデータに加えて,原告CDDBのデータの一部を,修正等の加工を施した上で利用した。しかし,これらのデータは,いずれも,行程表・見積書等の作成業務等の機能を有する旅行業者向けのデータベースに格納する情報としては当然かつありふれたものであり,かつその情報の選択において創作性が認められない単なる客観的なデータであるところ,このようなデータに修正等の加工を加えて利用する行為が著作権侵害となることはあり得ない。
また,被告アゼスタは,平成18年6月末ころの被告システム(当初版)の販売開始以降,現在まで6年以上もの長期間にわたり,膨大な手間・時間をかけて,顧客のニーズに対応してデータ内容を充実させており,継続して被告CDDBのデータを追加・修正・削除してきた結果,現行版及び新版の被告CDDBのデータは,当初版の被告CDDBのデータから一新されている。
これら具体的なデータの入力等については,前記(ア)で詳述したとおりである。
(エ) まとめ
以上のとおり,被告アゼスタが独自の設計思想に基づき開発した被告CDDBと原告CDDBとは,体系的な構成及び情報の選択のいずれの点においても大きく異なっており,さらに,被告アゼスタは,当初版・2006年版,現行版,新版と,絶え間なく被告システムに大幅な改良・変更を加えており,被告CDDBと原告CDDBにおける体系的な構成及び情報の選択の点での乖離はますます甚だしいものとなっている。
したがって,被告CDDBは原告CDDBに依拠したものではなく,原告の著作権(複製権)を侵害するものではない。
また,著作物の翻案とは,既存の著作物に依拠し,かつその表現上の本質的な特徴の同一性を維持しつつ,具体的表現に修正,増減,変更等を加えて,新たに思想又は感情を創作的に表現することにより,これに接する者が既存の著作物の表現上の本質的な特徴を直接感得することのできる別の著作物を創作する行為をいうとされ,思想,感情若しくはアイデア,事実若しくは事件など表現それ自体ではない部分又は表現上の創作性がない部分において既存の著作物と同一性を有するにすぎない著作物を創作する行為は,既存の著作物の翻案に当たらないとされるところ,データベースの著作物においても,体系的な構成及び情報の選択に関して,創作性がない部分において既存の著作物と同一性を有するにすぎない著作物を創作する行為は,既存の著作物の翻案に当たらないというべきである。
本件において,原告は,原告CDDBの創作性について,旅行業者が行程表作成の業務を行うにあたって必要となる観光施設データ,宿泊施設データ,全国各地の主要道路の道路地点,大型観光バスの移動時間・距離,有料道路・高速道路の料金データ,鉄道・飛行機・フェリーに関する路線,駅,時刻表等の情報を収集・蓄積し,各テーブル間をプライマリー・キー等によって有機的に関連付けることで,顧客のニーズに合わせた行程表を作成できるようにした情報の分類体系であることを強調する。
しかし,旅行業者向けのデータベースの開発に当たり,上記の情報を収集・蓄積し,各テーブル間をプライマリー・キー等によって有機的に関連付けることで,顧客のニーズに合わせた行程表を作成できるようにすること自体は,アイデアの範疇に属するものにすぎず,それ自体が創作性を基礎付けるわけではない。
データベースの創作性においては,あくまでも体系的な構成及び情報の選択における創作性が問題となるところ,上記のとおり,被告CDDB(とりわけ新版の被告CDDB)は,データの内容についても,情報の選択において創作性を有する部分について原告CDDBと大きく異なっているし,何より,テーブル・フィールドの構造及びリレーションについても,旅行業者向けシステムのデータベースにおいて最も創作性を大きく左右する施設情報を中心に,もはや似ている点がないほど異なっており全くの別物となっている。
したがって,被告CDDB(とりわけ新版の被告CDDB)は,原告CDDBとは,データベースの著作物の創作性を基礎付ける本質的な特徴が大きく異なっており,原告の翻案権を侵害するものともなり得ない。
2  争点(2)(被告らによる著作権侵害についての共同不法行為の成否)について
〔原告の主張〕
被告CDDBは原告CDDBに依拠して作成されたものであるが,依拠して作成され共通の内容となっている部分は,情報の選択及び体系的構成について創作性を有する部分であるので,被告CDDBを製造し販売しインターネットを通じて顧客に提供する被告らの行為は,原告CDDBについて原告が保有する著作権(複製権,翻案権,譲渡権,貸与権,公衆送信権)を侵害するものである。
そして,被告アゼスタの代表取締役である被告Y1をはじめ,被告Y3,被告Y2,被告Y4は,A及び被告Y5に対し,原告CDDBに依拠して,これと同一ないし実質的に同一である被告CDDBを作成することを依頼ないし黙認し,A及び被告Y5の2名は,被告Y1らの右依頼を受け,自らの意思と判断により,被告CDDBを設計ないし作成し,被告Y1,被告Y3,被告Y2,被告Y4,被告Y6の5名は,被告CDDBを含む被告システムを販売しており,被告Y1,被告Y3,被告Y2,被告Y4,被告Y6,被告Y5及びAは,これらの一連の行為により,原告CDDBに係る原告の著作権(複製権,翻案権,譲渡権,貸与権,公衆送信権)を侵害したものと認められる。
これらの著作権侵害行為は,被告アゼスタの代表者,取締役,監査役や従業員としての行為であるとともに,個人被告らについて,個人としての行為でもあると評価することができる。
そして,A及び被告Y5は被告CDDBの開発者として,上記のとおり原告CDDBに依拠して,これと類似する被告CDDBを作成しており,著作権侵害について故意があるというべきである。被告アゼスタの代表者である被告Y1は,A,被告Y5のかかる行為を行うことを依頼し自らもその作業に加わったものであり,著作権侵害について故意があるというべきである。
また,被告Y1,被告Y3,被告Y2,被告Y4,被告Y6らは,被告アゼスタの営業担当者として,被告CDDBが原告CDDBに依拠して作成されたものであることを知りながら,被告CDDBを含む被告システムをユーザーに対して提供し続けているので,著作権侵害について故意があるというべきである。
仮に,個人被告ら及びAに著作権侵害についての故意が認められないとしても,少なくとも過失が認められる。すなわち,個人被告ら及びAは,原告システムの開発に中心的に携わった開発者であるA,被告Y5が,原告システムと競合する被告システムを原告システムの開発に関するノウハウを利用して開発し,原告システムの販売に中心的に携わっていた営業担当者である被告Y3,被告Y2,被告Y4,被告Y6が,被告システムを原告システムの既存ユーザーに対して販売するという事業計画の下で新会社である被告アゼスタを設立し,被告システムを開発し販売しようとしたものであり,原告システムに関する著作権侵害を行う可能性のある行為をあえて行おうとしていたことになる。個人被告ら及びAには,被告CDDBを含む被告システムが,原告CDDBを含む原告システムに関する著作権を侵害しない製品となるように,開発を実施させ,著作権侵害品をユーザーに提供しないという注意義務があったというべきであるが,個人被告ら及びAはかかる注意義務に違反しているので,少なくとも著作権侵害に関して過失があるというべきである。
以上のとおり,本件著作権侵害は個人被告らの故意ないし少なくとも過失により行われたものである。
〔被告らの主張〕
否認し,争う。
被告CDDBは,情報の選択という点のみならず,そもそも体系的な構成からして原告CDDBと大きく異なっており,被告らは原告の著作権を何ら侵害しておらず,また被告アゼスタが原告CDDBのデータの一部を利用した行為について不法行為とはなり得ない。
したがって,被告らの行為が原告に対する不法行為を構成することはない。
3  争点(3)(一般不法行為の成否〔予備的主張〕)について
〔原告の主張〕
(1) 民法709条にいう一般不法行為の成立要件としての権利侵害は,必ずしも厳密な法律上の具体的権利の侵害であることを要せず,法的保護に値する利益の侵害をもって足りる。そして,対象となる作品や製品が著作物に該当しない場合でも,第三者によるそれらの複製,頒布,販売,公衆送信等の利用行為が自由競争の範囲を逸脱し,社会的な許容限度を超える場合には,一般不法行為として権利侵害となる。
データベースに関しても,人が費用や労力をかけて体系的構成を構築し,情報を収集,整理することで,データベースを作成し,そのデータベースを製造販売することで営業活動を行っている場合において,第三者が無断で,そのデータベースの体系的構成,選択収集されたデータを複製して作成したデータベースを,その者の販売地域と競合する地域において販売する行為は,公正かつ自由な競争原理によって成り立つ取引社会において,著しく不公正な手段を用いて他人の法的保護に値する営業活動上の利益を妨害するもので,自由競争の範囲を逸脱し,社会的な許容限度を超えるものであるので,不法行為を構成するというべきである。
(2) 被告らによる自由競争の範囲を逸脱する行為
ア 原告CDDBの作成経緯
原告CDDBは,体系的構成の構築,情報の取得及び入力されたデータの適否のチェックに多大な費用及び労力を費やして作成されたものである。
原告CDDBを含む原告システムは,翼システムが平成6年(1994年)7月から開発を開始し,平成8年(1996年)1月に完成して販売を開始した「スーパーフロントマン 旅行業システム」が元となっており,その後改良が加えられてきたものである。翼システム時代も含め,原告は,日本全国に原告CDDBを含む原告システムを販売し現在に至っている。
被告CDDBの2006年版にデッドコピーされたテーブルIDやフィールドIDから見ると,被告らは,平成18年(2006年)頃までに原告CDDBをデッドコピーした上,当初版,2006年版,現行版及び新版を作成しているものと推認されるが,翼システムないし旧原告会社は,平成6年(1994年)7月の開発開始時から平成18年(2006年)頃までの間,原告CDDBの開発及び維持には,開発要員として少なくとも常時10人以上従事させ,その間,開発費用として少なくとも7億円以上を費やしてきた。
イ 被告らによる原告CDDBの体系的構成及び選択収集した情報の流用
被告Y2,被告Y3,被告Y4,被告Y5,被告Y6は翼システムの従業員であったところ,営業譲渡に伴い,原告に移籍してきたものである。上記被告らは翼システムないし旧原告会社在職中に原告CDDBを備える原告システムの開発,販売に従事していたものであり,原告CDDBにアクセスしていたものである。
体系的構成の流用状況,収集した情報の流用状況については前記2争点(2)〔原告の主張〕のとおりである。すなわち,被告らは,道路情報,道路地点情報についてコピーしたことを認めているところ,その他の情報についてもデッドコピーしている痕跡が多々存在する(甲9,21,23,28,37)。被告CDDBはまず原告CDDBをデッドコピーし,それを元に当初版,2006年版,現行版,新版と作成してきたものであり,各版作成の都度流用を隠蔽するために一部改変を加えたものである。その結果,被告CDDBには原告CDDBから改変されている部分(甲23,35,36,37)も一部あるが,総じてデッドコピーの状況といえる。
ほぼデッドコピーそのものである当初版・2006年版の作成から始まり,その後少しずつ改変を加えて,現行版,新版が作成されたという経過に鑑みると,被告CDDBにおける改変部分の多くは,テーブルID,フィールドID,道路地点の緯度経度情報の改変が典型例であるが,それらは流用の事実を隠蔽しようとしてされているのであって,かかる改変によりデッドコピーでない部分が生じるとしても,そのことは,むしろ被告らの行為の悪質性を顕著に示すものであって,社会的に許容限度内の行為であることを基礎づける事実には到底ならない。
ウ 被告らによる原告の顧客の不当な奪取行為
原告CDDBのような観光施設,宿泊施設,道路,各種交通機関の時刻表等の様々な情報をデータベースとして備え,旅行業者向けの行程表が作成できるパッケージソフトウェアは,被告らが被告CDDBを備える被告システムを平成18年6月から販売するまで,日本国内市場に原告システム以外に存在しなかった。それまでは,原告は日本全国に原告CDDBを含む原告システムを販売してきたものである。
しかるに,原告システムの開発・営業に携わった個人被告ら(被告Y1を除く。)は,原告を退職した上,被告アゼスタを設立し,原告CDDBをデッドコピーあるいは一部改変した被告CDDBを備える被告システムを作成し,主に原告システムのユーザーに対して大幅な値引きを行って売り込みをかけ,原告の顧客を奪ったものである。被告らは原告CDDBを流用することによって開発費をかけずに被告CDDBを作成し,安価な製品の提供を行って原告の顧客をターゲットにして顧客を奪ってきている。被告らが奪った顧客数は,被告ら自身が明確に認めるものだけでも平成20年(2008年)7月時点で182社(甲52),平成22年(2010年)11月時点で300社(甲53)に及び,現時点ではその数は優に360社を超えている。なお,被告らは平成22年(2010年)11月時点で被告CDDBを含む被告システムのユーザーが約500社であることも認めている。
原告の元従業員である被告らが原告を退職後被告アゼスタを設立し,原告CDDBを含む原告システムの顧客に対して,原告が長年多大な費用や労力をかけて作成したデータベースである原告CDDBをそのまま複製等して,作成した被告CDDBを含む被告システムを大きな値引きを行って販売し,原告システムを被告システムに乗り換えさせて原告の顧客を奪うという行為は,故意,あるいは少なくとも過失により,取引における公正かつ自由な競争として許される範囲を甚だしく逸脱し,法的保護に値する原告の営業活動を妨害しその営業上の利益を侵害するものとして不法行為を構成するというべきである。
なお,原告CDDBの開発及び維持管理は,平成17年12月30日までは翼システムが行ったものであるが,原告は,平成17年12月30日に翼システムから営業譲渡を受けて,原告CDDBを含む原告システムについて,著作権のほか一般不法行為上の権利も原告に譲渡されたものであり,原告CDDBについて,原告が一般不法行為上の権利を保有する。
(3) 個人被告らの責任被告Y1,被告Y3,被告Y2,被告Y4,被告Y5は,互いに相談の上,原告CDDBを含む原告システムと競合する旅行業システムを開発販売する被告アゼスタを設立し,A及び被告Y5は,原告CDDBを含む原告システムに依拠して,これと実質的に同一ないし類似する被告CDDBを含む被告システムを開発し,被告Y1,被告Y3,被告Y2,被告Y4,被告Y6は,被告CDDBを含む被告システムを原告システムの販売地域と競合する地域にて販売し,原告の営業上の利益を侵害しているのであるから,個人被告ら及びAは,これらの一連の行為により一般不法行為を行っているものである。
そして,これらの行為は,被告アゼスタの代表者(被告Y1),取締役(被告Y2,被告Y3),監査役(A)や従業員(被告Y4,被告Y6)としての行為であるとともに,個人被告らの個人の行為でもあると評価することができ,被告アゼスタ,個人被告ら及びAによる共同不法行為であるといえる。
したがって,原告に対する一般不法行為について,被告らは,共同不法行為責任を負うというべきである。
A及び被告Y5は,被告CDDBを含む被告システムが原告システムと競合する地域にて販売されることを認識しながら,原告CDDBの体系的構成やデータを流用した被告CDDBを作成しているので,原告の利益を侵害することについて故意があるというべきである。
また,被告Y1,被告Y3,被告Y2,被告Y4,被告Y6らは,被告アゼスタの営業を通じて,被告CDDBが原告CDDBの体系的構成やデータを流用して作成されたものであることを知りながら,被告CDDBを含む被告システムを原告システムの販売地域と競合する地域のユーザーに対して提供し続けているので,原告の利益を侵害することについて故意があるというべきである。
仮に,個人被告ら及びAに故意がなかったとしても,個人被告ら及びAには,少なくとも過失が認められる。すなわち,原告システムの開発に中心的に携わった者であるA,被告Y5が,原告システムと競合する被告システムを開発し,原告システムの販売に中心的に携わっていた者が被告システムを販売するという事業計画の被告アゼスタを設立したのであるから,被告CDDBも含め被告システムの開発販売が不公正な手段を用いて原告の法的保護に値する営業活動上の利益を侵害することにならないように,開発販売を行うべき注意義務があったというべきであるが,個人被告ら及びAはかかる注意義務に違反しているので,少なくとも過失があるというべきである。
以上のとおり,本件共同不法行為は被告らの故意により,仮に故意が認められないとしても少なくとも過失により行われたものである。
したがって,被告らは,原告に対し,上記不法行為により原告が被った損害を賠償する責任を免れない。
〔被告らの主張〕
(1) データの違法な流用及び顧客奪取行為は存しないこと
ア 被告アゼスタが当初版の被告CDDBの開発にあたり利用した原告CDDBのデータは,いずれも行程表・見積書等の作成業務等の機能を有する旅行業者向けのデータベースに不可欠であり,かつその情報の選択において創作性が認められない単なる客観的なデータである。著作権侵害に至らない行為を不法行為と捉えることは,著作権法の趣旨を潜脱するものであり許されるべきではないし,職業選択の自由(憲法22条1項)の重要性に鑑み,在職中に業務を通して取得した知識・技能に基づいて行う行為は原則として自由競争の範囲内のものとして許容されるべきである。したがって,本件で被告アゼスタが原告CDDBのデータの一部を利用した行為については,不法行為とはなり得ない。
また,原告は,原告CDDBが多大な費用や労力をかけて開発されたと主張するが,これも実態とは大きく異なる。平成8年1月に販売開始された原告CDDBは,日本観光協会の観光施設データと,旧国際観光旅館連盟・旧日本観光旅館連盟の加盟施設,政府登録国際観光旅館の宿泊施設が登録されているのみで,旅行業者にとっては全く不十分なものであり,とても顧客を満足させるようなものではなかった。特に,原告CDDBの観光施設データについては,旅行業者が送客手数料を受領できる施設の登録に不備があり,これが販売面での致命傷となっていたため,無断転記を禁じられている料金ガイドから全てのデータを転用して観光データを入力した。実際,被告Y2がヘッドハンティングを受けて翼システムに入社した平成8年2月当時,翼システムでは,情報企画事業部で旅行営業課が設立されたばかりで,原告CDDBも上記のとおり試作品レベルのものであった。しかし,前職で旅行業者向けのトータル業務システム販売業務に従事して旅行業務システム構築のノウハウを熟知していた被告Y2や被告Y5,主たる開発者であったAらが中心になって,原告CDDBの観光施設・宿泊施設データの増加や改良がなされ,わずか3か月後の平成8年5月には販売してもクレームにならない程度まで原告CDDBの品質が改善され,現在の原告CDDBと同等のレベルの性能を備えるに至ったものであり,多大な費用や労力をかけて原告CDDBが開発されたとはいえない。
イ 原告は,被告システム販売開始後,被告らが原告の顧客をターゲットとし残リース期間の短いところから順次「狙い撃ち」して営業を行っていたと主張する。
しかし,被告らは,原告の顧客のみをターゲットにしていたものではなく,当然,その他の旅行会社にも営業を行っていた。また,被告Y3,被告Y2,被告Y4及び被告Y6は残リース期間の長短に関係なく営業を行っていたし,残リース料を負担とするというのはごく普通のことであり,実際被告アゼスタに限らず同業他社も同じ営業方法をとっている。前記のとおり,そもそも原告の顧客が被告システムに変更したのは,単に原告システムの不具合やメンテナンス不足に対する不満と被告システムの優位性が理由であるから,被告らの営業は完全に自由競争の範囲内のものである。
(2) 被告ら各人に不法行為は成立しないこと
ア 被告Y1の責任につき
被告Y1は,そもそも翼システムに在職してもおらず,株式会社グッドウィルの取締役,株式会社エス・エス・アイ・トリスター及び株式会社トリスターの代表取締役を務めた経験を買われ,被告Y3及び被告Y2と友人関係にあったこと等から,被告アゼスタの代表取締役に就任したにすぎない。被告Y1には,被告アゼスタの代表取締役就任以前にデータベースやプログラムの開発に関与した経験は全くなく,その専門的知識も何ら持ち合わせていなかった。実際に,被告Y1は,被告CDDBの早期販売のためにやむを得ず,独自に収集したデータに加えて,被告アゼスタ社内にあった原告CDDBのメンテナンスCDのデータの一部を利用することとした際にも,当該データをそのまま被告CDDBで利用するのではなく,そのまま利用しても顧客からクレームの対象になるだけであるから,旅行業者向けのデータベースに格納する情報としては当然かつありふれた客観的なデータの正誤を確認し必要な修正等を加えた上で利用するように指示していたにすぎない。そして,被告Y1としては,被告CDDBが被告アゼスタの独自の設計思想に基づき開発され,その体系的構成は原告CDDBと大きく異なっている以上,客観的データの一部を修正して利用する行為は,自由競争の範囲内の行為として当然許容されると認識していたものである。
以上からすれば,被告Y1には,原告の企業秘密に接する機会がなかったことに加えて,そもそも原告の営業活動を違法・不当に侵害する故意などなく,被告CDDBの開発・販売に際して,原告の著作権侵害とならないように慎重な配慮も尽くしているから,過失もない。
したがって,被告Y1に不法行為は成立しない。
イ 被告Y5の責任につき
被告Y5は,被告システムのデータベース開発を担当していたところ,被告Y1の指示を受けて,被告アゼスタが独自に収集したデータに加えて,原告CDDBのデータのうち,旅行業者向けのデータベースに格納する情報としては当然かつありふれた客観的なデータについて,必要な修正等を加えた上で利用することにした。確かに,被告Y5としては,長年翼システムにおいて原告CDDBの開発に携わっており,原告CDDBの内容を熟知してはいたが,翼システムから原告CDDBのメンテナンスCDを含めデータベース設計資料等の機密情報を持ち出しすようなことは一切していなかったし,被告CDDBが被告アゼスタの独自の設計思想に基づき開発され,その体系的構成が原告CDDBと大きく異なっている以上,旅行業者向けのデータベースに格納する情報としては当然かつありふれた原告CDDBの客観的データの一部を修正して利用する行為は,自由競争の範囲内の行為として当然許容されると認識していた。
以上からすれば,被告Y5は,そもそも原告の営業活動を違法・不当に侵害する故意などなく,被告CDDBの開発・販売に際して,原告の著作権侵害とならないように慎重な配慮も尽くしているから,過失もない。
したがって,被告Y5に不法行為は成立しない。
なお,原告は,被告アゼスタの行為は,被告ら個人としての行為でもあると評価することができ,被告らに不法行為ないし共同不法行為が成立するとも主張しているが,被告アゼスタの役員でもなく被告Y1の指示に従って被告CDDBの開発に関与していた被告Y5に,被告アゼスタの会社としての行為の責任を帰責させるべきではなく,この意味でも不法行為ないし共同不法行為は成立し得ない。
ウ 被告Y3,被告Y2,被告Y4及び被告Y6の責任につき
被告Y3,被告Y2,被告Y4及び被告Y6は,被告システムの営業担当であり,そもそもデータベースの設計や構造を含む開発に関する知識を持ち合わせていない。被告Y3は,翼システム時代に開発に関する会議に参加していたことはあるが,それも顧客目線でどのような画面であれば見易いか等の営業の立場からのアドバイスをしていただけで,それによってデータベース開発の知識を習得していたものではない。被告システムの開発においても,被告Y3,被告Y2,被告Y4については,単純なデータ入力作業の一部を手伝うことはあったが,それ以上に被告システムの開発には特に関与しておらず,その開発経過については知らないし,原告システムのデータが一部利用されていることも特に認識していなかった。
また,被告Y3,被告Y2,被告Y4及び被告Y6は,原告の顧客リストの持ち出しなどもしていない。被告Y3,被告Y2,被告Y4及び被告Y6は皆,自分が探索した顧客名やその担当者については,何度も通っており当然頭の中で覚えていたし,一般に流通している旅行業者名簿を見れば簡単に連絡先も探すことができたことから,顧客リストなど不要であり,わざわざ持ち出す必要もなかった。
さらに,被告Y3,被告Y2,被告Y4及び被告Y6は,原告システムのインストール用CDを所持し取扱うことは会社から一切許されておらず,納品などのインストール作業はサポート部門に依頼するという社内ルールがあったため,被告Y3,被告Y2,被告Y4及び被告Y6がこれを手にしたことなど一度もなく,管理も厳重であったため所在すら知らなかったし,顧客へのデモンストレーション用に使っていたPCについても,原告退職時に返却又は退職後は特に使用していない上,インストールされているデータをコピーして持ち出すこともしていないしその方法すら知らなかった。
何よりも,被告Y3,被告Y2,被告Y4及び被告Y6は,顧客からの度重なるクレームにも対応しない原告システムの内容に強い不満を持ち,顧客のためよりよい製品を提供したいという思いから,原告を退職し,各々に集まり被告アゼスタの設立に尽力した者たちであるから,原告システムを単にコピーした商品を販売する意思など毛頭なかったし,そのようなことを行えば再びクレームに晒されるだけということも十分に自覚していた。
特に,被告Y6については,被告システムの当初版の販売開始(平成18年6月)及び2006年版の販売開始(平成18年11月)後の同年12月に入社したものである。このように,入社時期から考えて被告システムの開発には全く関与していないことは明らかであるし,最新の顧客リストやインストール用CDの最新版等を持ち出したこともなく,被告CDDBのデータ入力作業には一切関与していないのである。なお,被告Y6は,被告Y2ら他の営業担当者から積極的な引き抜きの勧誘を受けたものではなく,原告の顧客不在の営業方針に失望して自らの意思で退社し被告アゼスタに入社したものである。
したがって,被告Y3,被告Y2,被告Y4及び被告Y6に不法行為が成立する余地はない。
エ 被告アゼスタの責任につき
被告アゼスタについては,上記のとおり,被告Y1,被告Y5,被告Y3,被告Y2,被告Y4及び被告Y6のいずれにも故意・過失はなく,その使用者たる被告アゼスタにも不法行為は成立しない。
4  争点(4)(原告の行為の独占禁止法違反の可能性の有無)について
〔被告らの主張〕
仮に,原告システム及び被告システムのような,行程表・見積書の作成及び出力,売上・集計・顧客管理のトータルサポートを可能とする旅行業向けシステムを開発・販売している業者が原告と被告アゼスタの二社のみで,寡占状況となっているとすれば,原告の本件訴えの提起による被告CDDBの差止請求及び損害賠償請求は,原告一社による市場独占を企図するものと考えられ,競争原理を機能させずに利用者にとっての利便性向上を著しく阻害する結果をもたらすものであるから,まさに,同業者である被告アゼスタの事業活動を排除することにより,公共の利益に反して,一定の取引分野における競争を実質的に制限するものに他ならず,独占禁止法2条5項,3条に違反している可能性すらある。この意味でも,原告の請求は速やかに棄却されるべきである。
〔原告の主張〕
被告らは,独占禁止法違反の可能性を指摘し,原告の請求は速やかに棄却されるべきであると主張するが,訴えの提起が私的独占となる理由は全くない。訴えの提起によって旅行業システムに関する市場への参入を制限しているわけではないし,被告アゼスタの事業活動を支配しているわけでもない。
また,原告による訴えは著作権の権利行使であり,そもそも独占禁止法の適用は除外される(独占禁止法第21条)。
5  争点(5)(被告らの損害賠償義務の有無及び原告の損害額)について
〔原告の主張〕
(1) 被告らの損害賠償義務
前記のとおり,被告らは,原告CDDBをデッドコピーした上,若干の変更を加えて被告CDDBを作成し販売してきているものであり,原告CDDBの著作権侵害ないし原告の法的に保護された利益を侵害する一般不法行為について,故意ないし過失がある。
そして,原告は,被告らが被告CDDBを含む被告システムを販売したことにより,以下の損害を被ったものであるから,被告らは,著作権法114条1項ないし民法709条により,以下のとおり,原告に生じた損害を賠償する義務を負う。
(2) 原告の逸失利益
ア 原告システムと被告システムとの関係
被告らは,被告システムを平成18年6月頃から平成22年11月頃に至るまで,ユーザーに対して,少なくとも500本(少なくとも当初版22本,2006年版78本,現行版400本)販売し(甲53),各販売先のユーザーと更新データを提供するデータメンテナンス契約を締結している。
被告システムにおいて被告CDDBは必須なものであり,被告CDDBがなければ,ユーザーが被告システムを購入することはない。また,原告CDDBや被告CDDBのような観光施設,宿泊施設,道路,各種交通機関の時刻表等の様々な情報をデータベースとして備え,旅行業者向け行程表が作成できるシステムは,パッケージソフトウェアとしては原告システムと被告システム以外には市場に存在せず,原告システムと被告システムには,あるユーザーに対して被告システムが販売されなければ,当該ユーザーに原告システムが販売され,原告と当該ユーザー間に更新データを提供するデータメンテナンス契約が締結される,という関係がある。
したがって,被告CDDBを含む被告システム500本の販売により,原告は原告システム500本の販売にかかる利益及びデータメンテナンス契約にかかる利益を失ったものであり,かかる逸失利益は原告が被った損害となる。
原告の逸失利益は,原告システム1本分及び原告のデータメンテナンス1件分につき失われた売上額から,それぞれ原告システムの製造・販売のための変動経費又はデータメンテナンスのための変動経費を控除した限界利益につき,500本分を計算すべきことになる。
イ 被告システムの販売にかかる原告の逸失利益(原告システム販売に関する損害額)
被告システムの販売にかかる原告の逸失利益は,原告システム「旅行業システムSP」のTR-P4(甲68)に基づいて計算すべきところ,詳細は以下のとおりである。
被告システムである「旅nesPro」は,検索業務,行程・見積業務,売上・集計業務が全て含まれるシステムであるところ(甲1の2),これに対応する原告システムである「旅行業システムSP」の基本システムのタイプはTR-P4である(甲59,68。なお,平成19年9月以降,「TR-SP4」にバージョンアップされ,その標準価格はいずれも220万円である。以下,「TR-P4」と「TR-SP4」を併せて「TR-P4等」という。)。上記のとおり,被告システムの販売により,原告システムである「旅行業システムSP」の基本システムであるTR-P4等の販売にかかる利益が失われる関係にあるので,原告の逸失利益はTR-P4等に基づいて,計算すべきである。
ただし,被告システムの販売が開始された平成18年6月以降は,原告も被告システムの販売価格に対抗するため原告システムの値下げを余儀なくされたことを考慮すると,平成18年当時の原告システムTR-P4の販売価格及び限界利益を前提に原告の逸失利益(損害)を算定すべきである。
平成18年1月から12月までの原告システムTR-P4は37台販売され,その売上総額は7127万8074円であるので,平均実売価格は1台あたり192万6434円となる(甲69)。
平成18年度(1月から12月まで)における原告システム販売の限界利益率は以下のとおり少なくとも83.4%であるので,原告システム1台を販売することによる限界利益は少なくとも160万6646円となる(甲69)。
原告の平成18年度(1月から12月まで)の原告システム関連の売上高は2億2166万7154円であり,原告システムの製造販売にかかる,変動経費は,仕入高,残債,販売手数料,販促費・リース料S,販促費・その他,インセンティブ,外注費,物流費であり,その合計は3683万2045円となる。
平成18年度の原告システムの売上高2億2166万7154円に対する上記変動経費合計3683万2045円の比率は,16.6%となる。
したがって,原告システムの限界利益率は,83.4%となる。
被告システム販売にかかる原告の逸失利益(損害)は以下のとおりとなる。
192万6434円(原告システムの平均実売価格)×500(本)×0.834(限界利益率)=8億0332万2978円
ウ 被告システム販売にかかる原告の逸失利益(原告システムのデータメンテナンス契約についての損害額)
データメンテナンスは,原告システムを導入するユーザーとの間で毎月ユーザーに更新データを提供するためのもので,1本あたり月額6000円で提供される。この月額料金は平成18年1月時点から現在に至るまで変わっていない。
平成18年度(1月から12月まで)における原告における全システムに関するデータメンテナンスの限界利益率は,以下のとおり少なくとも80.6%であり,原告システムのデータメンテナンスの限界利益率も少なくとも80.6%と考えられる(甲69)。
原告の平成18年度(1月から12月まで)のデータメンテナンスの売上は10億4742万9088円であり,データメンテナンスにかかる変動経費は,仕入高,残債,販売手数料,販促費・リース料S,販促費・その他,インセンティブ,外注費,物流費であり,その合計は2億0309万8451円となる。
平成18年度の原告におけるデータメンテナンスの売上高10億4742万9088円に対する上記変動経費合計2億0309万8451円の比率は,19.4%となる。
したがって,原告におけるデータメンテナンス契約の限界利益率は,80.6%となる。
原告システムのデータメンテナンスに関する逸失利益(損害)は以下のとおりとなる。
被告らは,被告システムを少なくとも以下のとおり500本(平成18年度に少なくとも当初版22本,2006年版78本合計100本,平成19年度から22年度までに現行版を各年度少なくとも100本合計400本)販売し,各販売先とデータメンテナンス契約を締結していることから,データメンテナンス契約についての逸失利益にかかる原告の損害は以下の計算により少なくとも8704万8000円となる。
(ア) 平成18年度  580万3200円
平成18年度における被告の販売本数は,当初版が22本,2006年版が78本の合計100本である。したがって,原告の損害額は,次のとおり,580万3200円となる。
6000円×12(か月)×100(本)×0.806=580万3200円
(イ) 平成19年度  1160万6400円
平成19年度における被告の販売本数は,当初版が22本,2006年版が78本,現行版が100本の合計200本である。したがって,原告の損害額は,次のとおり,1160万6400円となる。
6000円×12(月)×200(本)×0.806=1160万6400円
(ウ) 平成20年度  1740万9600円
平成20年度における被告の販売本数は当初版22本,2006年版78本,現行版200本の合計300本である。したがって,原告の損害は,次のとおり,1740万9600円となる。
6000円×12(月)×300(本)×0.806=1740万9600円
(エ) 平成21年度  2321万2800円
平成21年度における被告の販売本数は,当初版22本,2006年版78本,現行版300本の合計400本である。したがって,原告の損害は,次のとおり,2321万2800円となる。
6000円×12(月)×400(本)×0.806=2321万2800円
(オ) 平成22年度  2901万6000円
平成22年度における被告の販売本数は当初版22本,2006年版78本,現行版400本の合計500本である。したがって,原告の損害は,次のとおり,2901万6000円である。
6000円×12(月)×500(本)×0.806=2901万6000円
エ 小括
以上から,原告の逸失利益にかかる損害額合計は,以下のとおり8億9037万0978円となる。
8億0332万2978円+8704万8000円=8億9037万0978円
(3) 弁護士費用
相当な弁護士費用は2000万円を下らない。
(4) 損害額の合計
上記(2)及び(3)の合計額は9億1037万0978円となる。
(5) 予備的主張に係る損害額
予備的主張(一般不法行為)に係る損害額も,上記著作権侵害に基づく損害額と同額である。
〔被告らの主張〕
(1) 原告の主張(1)は否認する。被告らに著作権侵害ないし一般不法行為についての故意ないし過失がないことについては,前記4争点(4)〔被告らの主張〕のとおりである。
(2) 原告の主張(2)ないし(5)は,否認ないし争う。
ア 被告システムは,平成18年6月から平成24年12月までの6年6か月もの期間をかけて,当初版・2006年版,現行版,新版と順次改良され,被告CDDB部分はもちろんのこと,その他のデータベースについても,データベースの構造はもちろんデータの数・内容も大幅に変更しており,さらにはプログラムにも改良が加えられている。しかるに,原告は,これらの違いを全く考慮せずに,当初版,2006年版,現行版の全ての販売数について損害賠償を求めているが,およそ因果関係は認められない。
また,原告は,その著作権が侵害されたと主張する対象について,当初原告システム全体としていたものを,訴えの変更により原告CDDBへと大幅に縮小したにもかかわらず,当該著作権侵害による損害額については,原告システム全体を前提とした金額から一切減額しておらず,整合性がない。
原告が問題とする原告CDDBは,行程・見積機能が参照する一部のデータしか有しておらず,当該部分は,原告システムの旅行業者向けシステムとしての本質的機能が「旅行業者がその業務を遂行する上で必要不可欠な行程表・見積書の作成及び出力,売上・集計・顧客管理のトータルサポート」というところにあることからすれば,わずか一部分にすぎない。テーブル数及びフィールド数についても,原告システムに係るデータベースが合計60個のテーブル(46個のマスターテーブル及び14個のエントリーテーブル)を有し,合計938個のフィールドを含んでいたのに対し,原告CDDBは原告の主張によっても42個のマスターテーブルと405個のフィールドを有するに留まっている。
しかも当然ながら,実際のデータベースは,デジタルデータの集合体とこれを管理・処理するコンピュータ・プログラムとが不可分一体となって稼働するものであり,本件の旅行業者向けシステムもデータベースとプログラムとが不可分一体となって機能するところ,原告システムと被告システムとはそのデータベースのみならずプログラムについても全く異なっており,かかるプログラム上の差異から生じる機能の違いも極めて大きい。
以上の点を考慮すると,仮に万一著作権侵害又は不法行為の事実が認められるような場合であっても,原告が主張する損害はそのほとんど全てが減殺されるべきである。
イ 原告は,原告システムの基本システムのタイプはTR-P4(標準価格は220万円)であると主張して,これを前提に限界利益率を算定している。しかし,原告システムは,行程表・見積書作成機能のみのTR-P1(標準価格は170万円)と,TR-P1の機能に加えて売上・顧客管理機能(同機能には原告CDDBは含まれていない)が追加されたTR-P4とがあり,原告CDDBは,行程表・見積書作成機能部分のみにしか含まれていないから,標準価格でTR-P1を50万円も上回るTR-P4の販売価格を基準として損害額を算定するのは明らかに過大であって,不当である。
さらに,原告は,標準価格を大幅に下回る値引きを行っており,自ら標準価格「1本220万円」と主張する原告システムを70万円にも満たない金額(標準価格の30%以下)で顧客に販売している(乙32)。この点に関して原告は,被告システムの販売が開始された平成18年6月以降は,被告システムの販売価格に対抗するため原告システムの値下げを余儀なくされたなどと主張するが,全く事実に反する。被告システムが販売される平成18年6月以前も,原告システムは,標準価格を大幅に下回る金額で販売されており(乙36の1~26),TR-P1のみならずTR-P4をも含めた合計30本の販売数の平均販売価格は約106万円にすぎない。原告は,何ら客観的資料も示さずに報告書(甲69)のみを根拠として,平成18年1月から12月までの原告システムTR-P4は37台販売されその売上総額は7127万8074円であり,平均実売価格は1台当たり192万6434円となる,などと主張するが,翼システムが標準価格の半額近くまで大幅に値引きして原告システムを販売してきた実績(TR-P1及びTR-P4が標準価格で販売されたことは一度もない。)からすれば,到底信用できない。
また,旅行業者向け行程表作成システムを販売する業者は被告アゼスタ以外にも存在するし,旅行業者全体の傾向として団体旅行の激減,インターネット等の普及により,旅行業者を通さない個人での予約の増加に伴い,売上減少,経費削減を強いられている中,データメンテナンスも十分に行われないパッケージソフトウェアが,平成18年当時の価格を維持できるはずがない。
したがって,そもそも原告システムのTR-P4ではなくTR-P1の販売価格によらなければ不合理であるし,TR-P1の販売価格についても,標準価格(1本170万円)ではなく,大幅に値引きされて販売されている事実に即した実売見込価格によるべきであるから,原告の主張は失当である。
ウ 原告は,平成18年1月から現在に至るまでデータメンテナンスの月額料金は1本6000円であると主張するが,事実に反する。実際は月額2000円で顧客とデータメンテナンス契約を締結している(乙33)。
さらに,被告システムが販売される平成18年6月以前も,原告システムのデータメンテナンス料金は,大きな値引きがされており,合計29本のデータメンテナンス契約の平均料金は約1810円にすぎない(乙36の1~26)。
したがって,月額6000円のデータメンテナンス料金を前提として逸失利益を算出する原告の主張も失当である。
(3) 被告らの主張
原告は,観光施設,宿泊施設,道路,各種交通機関の時刻表等の様々な情報をデータベースとして備え,旅行業者向け行程表が作成できるシステムは,パッケージソフトウェアとしては原告システムと被告システム以外には市場に存在せず,原告システムと被告システムには,被告システムが販売されなければ,当該ユーザーに原告システムが販売され,さらに原告と当該ユーザー間にデータメンテナンス契約が締結されるという関係があると主張するが,以下のとおり,そのような事実は全くない。
まず,旅行業者向け行程表作成システムは,原告システム及び被告システム以外にも,株式会社エヌシステムのJA旅行センター向け旅行業営業支援システム「応援団くん」, 株式会社JMCの国内行程表管理システム「ezROUTE」,株式会社全旅の観光商品流通システム「ANTA-NET」,株式会社ワールドエキスプレスの国内/海外旅程表作成・見積集計の旅行業支援システム「World TAC」などがあり(乙35の1~4),現に上記各社は,被告アゼスタとも原告とも競合している。さらに,その他にも行程表・見積書作成業務支援システム「旅の助」を展開する株式会社エイブルシステムズや「シンフォニーアトゥー」を展開する株式会社ウィ・キャンなど(乙35の5~6),シンプルな行程表作成機能ではあるが団体旅行が激減した昨今ではかえって業者ニーズに即しており,競合することも多くなっている。
被告システムは,原告システムと同額以上で販売しているところ,仮に単に原告システムのデータベースをコピーしただけの模倣品レベルのものであれば,原告システムの既存ユーザーからすれば,会社規模も資本規模も被告アゼスタとは比較にならないほど大きい原告が販売するシステムから新興の企業で資本規模も原告の約560分の1,従業員数もパートを含め12名にすぎない被告アゼスタが販売するシステムにあえて乗り換える必要がない。データベースシステムについては,格納されているデータがいかに正確で,きちんとメンテナンスが施されているかが顧客にとって最重要であるところ,会社規模・資本規模の小さな会社のシステムを導入することは将来のメンテナンスに不安を覚えるのが通常であるからである。被告システムに変更した原告ユーザーからは,変更の理由として,商品開発力の不足(バージョンアップがほとんどなく導入時から全く仕様が変わっていない等),データメンテナンス更新ペースの遅さ(新東名高速等料金情報が遅い,観光・宿泊施設における追加,修正,削除要望には全く応えられない等),データが不正確(道路料金・施設入場料金データの誤りが多い,倒産・廃業した観光・宿泊施設データが何年も放置されている等),サポート体制の不十分さ(急な障害対応や操作説明を受けたくてサポートセンターに連絡しても,旅行業システムは即対応不可なので後で担当者から連絡させると回答され業務が止まってしまう等)などが挙げられており,原告システムの顧客が離反するのは,被告システムの存在が原因なのではなく,専ら原告システムの顧客満足度の低さに起因しているのである。
一方で,被告アゼスタは,その営業担当者は全員旅行業界出身で旅行業システム販売にも10年ないし15年のキャリアを持っており,熱意もあって,業界の動向や顧客の要望に対する理解力に優れており,これらのフィードバックを受けてシステム開発を行うことから,正確かつ迅速なメンテナンスが施され,継続的にデータの量・質ともに向上していることに加え,被告システムは原告システムに比して機能面やサポート体制が充実しており優位性が極めて高く,先進性・利便性・サポート面等のトータルで優れたシステムとして高い支持を受けている。したがって,被告システムには,データベースの内容だけに限定されない商品価値があり,被告アゼスタの弛まぬ開発努力やサポートを含めた営業努力が販売に大きく貢献しているのである。他方で,旧原告会社では,主力の営業担当者が多数退職したため,入社間もない新人や他部署から配属された,旅行業務や旅行業務システム販売の経験の少ない従業員が営業担当とならざるを得ず,これが販売数低下を招く大きな原因の一つになったと考えられる。
以上のとおり,被告システムが販売されなければ,原告システムが必然的に購入され,データメンテナンス契約も締結されるという因果関係は存在しない。
第4  当裁判所の判断
1  前記第2,1の前提事実並びに証拠(甲1~81,乙1~43,証人B,証人A〔下記措信しない部分を除く〕,被告Y5本人,被告Y2本人,被告Y3本人)及び弁論の全趣旨によれば,以下の事実が認められ,同認定を覆すに足りる的確な証拠はない(なお,各段落の末尾に主要な証拠を掲記した。)。
(1)  原告CDDBを含む原告システムの開発の経緯及びその開発,営業活動等についての被告Y5,A,被告Y2,被告Y3,被告Y6,被告Y4の関与の状況について
ア 原告システムは,現在も原告において旅行営業課の課長代理として原告システムの販売を担当するB(以下「B」という。)が翼システムに入社して間もない平成6年4月頃に,当時の同社代表者に対して旅行業システムの制作販売の提案をし,これを代表者が了承したことから,その開発に着手されることとなったシステムである。
被告Y5は,それに先立つ平成2年4月22日に翼システムに入社した。被告Y5は,翼システムに入社する以前,昭和61年から他社で設計書を基にプログラムを行うプログラマーとして稼働し,翼システムにおいても電装システムの設計,検収等の業務を行ってきたことから,翼システムにおいて原告システムの制作が決まり,社員を集めて原告システムの開発プロジェクトが組織されたことを契機にそのリーダーとなった。
Bが原告システムの開発の提案をするに当たって,そのきっかけとなったのは,株式会社小田急トラベル(以下「小田急トラベル」という。)からの要望にあった。同社においては,それまで,団体旅行の行程表の作成のほとんどを,従業員の手作業で行っていたところ,大型バスの使用の際の通行道路の所要時間計算や,途中のドライブインの検索等に時間を要し,手作業でこれらを行うため,一件の行程表作成に20時間ほども要しているという実情にあった。そこで,同社では,パソコンを用いてこれらの業務を効率化したいとの要望が強かったものの,これに適するソフトウェアが当時存しなかったことから,それを可能とする団体旅行の行程表作成用のソフトウェアが作成されたならば,使用したいとの要望が示されていた。
そこで,被告Y5及びBは,小田急トラベルに対し,原告システムの開発のため,状況調査のヒアリングを行い,さらに,平成7年(1995年)1月10日に小田急トラベル社内で行われた原告システム開発プロジェクトの打合せに参加したところ,同打合せにおいて,小田急トラベルの状況調査の結果が報告された。そこでは,同社における行程表作成には上記の問題点があることのほか,同社においては,顧客と打ち合わせた結果作成された行程表の最終原稿のみを,ワープロや表計算ソフトを使用して浄書して保管し,その後に要望が似通う旅行行程表作成の必要があったとき,その要望と類似する上記最終原稿を探し出し,これを変更して使用しているが,その検索にも手間がかかる上に,旅行目的(例えば「女性のグルメ旅行」等)に応じた必要な情報の検索もできない状況にあること等が問題であることが報告された。そして,同社において,行程表作成の際に使用している資料及びその使用方法は,まず「全国道路地図」を用いて旅行行程についての大まかなコース作りをし,次に観光バスキロ程図のある「Road Map」(以下「ロードマップ」という。甲47)を用い,行程に沿って時間を加算して所要時間を算出し,更に料金ガイド,JTB宿泊情報等を用いて,必要な料金等を算出していた。同社によれば,団体旅行に使用される交通機関は,貸切バスの使用が6割,鉄道利用が2ないし3割,航空機使用が1ないし2割で,旅行人数は30名程度での利用が最も多く,多くは10ないし40名程度であること,旅行行程の作成の相談に当たっては,出発地,到着地及びその時間をまず確定して,それから観光地や昼食地を選ぶことが多く,交通機関として貸切バスを使用するのであれば,90ないし120分走行したところで休憩ないし昼食地を探す必要があること,一般的な出発時刻,到着時刻は,それぞれ9時頃,16時頃であること,使用するホテル等の宿泊施設には,ホテル・旅館・民宿・ペンションの種類区分とエコノミー等の料金カテゴリーが必要であり,部屋や食事の内容,風呂の内容や大きさ,料金,宴会場の空きがあるか等が選択項目選定の際のポイントであり重要な情報となること,検索は5ないし6程度の項目とすること等が,原告システムの制作に当たって有益な情報として打合せにおいて紹介され,今後,その要望に沿ったデータベースである原告CDDBを含む原告システム(以下,原告システムの開発という場合には,必要なデータベースである原告CDDBの開発も含む。)の開発スケジュールが組み立てられることとなった。〔被告Y5尋問調書1頁,甲63の別紙1〕
イ 平成7年7月には,Aが翼システムに入社し,原告システムの開発にプログラマーとして参加し,データ加工を担当することとなった。そして,原告システムのホテル・旅館のデータについては,社団法人日本観光協会,実業之日本社からデータの提供を,観光施設については社団法人日本観光協会からデータの提供を,それぞれ受けることとなった。〔乙38,2頁,甲63の別紙1,2〕同年11月9日の時点における,当時進行中の原告システムの開発状況は,行程表のプログラムについては,道路検索について作り直しの途中であり,同月末には終了予定とされ,道路データに関して,国道のデータ入力は終了したが,有料道路は東京,神奈川,千葉,埼玉,静岡は全て終了したものの,それ以外の地域は道路名称のみの入力が終了した段階で,市町村道については未だ700件以上の代表地点のデータが入力されていない状況であった。ホテル・旅館のデータについては,観光施設について社団法人日本観光協会から提供を受けたデータの間違いについて折衝を続けること,収容人数に関するデータも追加することなどが決められた。〔甲63の別紙3〕
そして,同年12月ないし平成8年1月に,原告システム(当時の名称は「スーパーフロントマン 旅行業システム」)の販売が開始された後も,翼システムにおいては,原告システムの充実改良が引き続き行われた。そこにおいて,Aは,原告システムの新機能の追加や改良等を担当した。その後,Aは,翼システムにおいて,システムエンジニアとして認められて主任となり,平成9年ころからは,原告システムのシステム設計やプログラム開発を手がけ,原告システムに関するリーダーであった被告Y5のもとで,サブリーダーとなった。〔乙38,2頁〕
ウ 被告Y2は,昭和62年から旅行業者や旅行業者に業務システムを販売する会社等に勤務して,その間,旅行業者向けトータル業務のシステム販売業務に従事し,旅行業務システム仕様と構築ノウハウを修得していたが,平成8年2月に翼システムからヘッドハンティングを受けて同社に転職した。被告Y2は,翼システムに入社後,原告システムの販売・サポート体制の構築に従事することとなり,平成9年10月ころまでには主任となり,営業成績優秀者表彰を7度受けた。〔甲63の別紙8,甲78,6頁,乙40,12頁〕
エ 被告Y3は,昭和61年からは旅行業者に勤務して旅行業務の営業等を行った後,平成8年12月に翼システムに入社し,入社後,原告システムについてシステムサポートを担当することとなり,平成10年1月ころからは同社営業課でシステム営業を担当することとなった。〔甲78,6頁,乙41,5頁〕
オ 平成9年1月6日に被告Y6が,平成9年12月24日に被告Y4が,翼システムに入社した。〔甲78,6頁〕
カ 被告Y5らが参加した平成9年2月15日の原告システムの開発に関する打合せにおいて,原告システムの改良について話し合われ,例えば,道路データは詳細地点を増やすなど,今後も地道に精度を上げていく努力をする旨が決定され,データ管理のコントロールについて,サポート担当の被告Y6が当たることとなった。
同年3月19日時点での原告システムに関する人的体制として,データコンテンツの作成について,派遣の者6名が当たっていたが,同年4月以降,これを道路データに3人,時刻表メンテナンスに2人,観光施設データに6人,ホテルデータに1人の合計12人に増員することとされた。また,データ開発システムに関しても,同年4月以降,設計にシステムエンジニア1人,プログラムに関しプログラマー1人を当てることとされた。その他,同年3月時点で,原告システムの基本パッケージに関する業務に当てられるシステムエンジニアとして,被告Y5,Aのほかに翼システムの社員1名,外注の者1名,プログラマーとして翼システムの社員2名,外注の者1名が当てられている状況であったが,これを引き続き維持することとされた。また,物的設備については,データ開発用,プログラム開発用兼テスト機,サーバー機として各1台の合計300万円,クライアント機として,各8台の合計640万円の設備投資(ソフトウェアを含む)を行うことが決定された。〔甲63の別紙5,甲78〕
被告Y6は,平成9年5月13日にAらとの間で行われた原告システムの開発業務に関するインタビューにおいて,入金一覧表の帳票イメージについての回答をするなどした。〔甲63の別紙4,6〕
また,被告Y3は,平成10年1月14日に,原告システムについての包括料金特約についての提案をするなどした。〔甲63の別紙11〕
キ 平成10年8月29日,Bのほか,被告Y5,A,被告Y2,被告Y6が参加して原告システムについての営業会議が行われ,原告システムについての不具合点やこれについての改善案の提案がされた。同会議において,原告システムの顧客管理機能の充実を図る必要があるとされ,例として,「法人客の場合は,創立記念旅行に行くことが多いので『創立記念日』での検索等を出来るように検討する」ことなどが今後の検討項目とされた。また,鉄道や航空料金に関しても,乗継ぎ料金の計算,普通運賃の計算が正確にできるように運行キロ数で計算処理すること,ローカル線の駅データも入力していくこととされた。〔甲63の別紙14〕
さらに,今後の検討事項の一つとして,作成した行程表を地図と連動させることで,地図上に行程の経路の表示を可能とすること,祭りやさくらんぼ狩り,カニ食べ放題など,観光施設の検索条件が設定できるよう検討していくこと,宿泊施設の検索には,露天風呂やサウナが重要なキーであり,これらがある旅館を検索することができるようにすることなど,今後も宿泊施設のデータベースの改善を検討していくこととされた。また,旅行代理店は,兼業でバス会社等を営業していることも多く,バス運行管理システムについての要望があった旨も紹介された。〔甲63の別紙14〕
ク 平成11年10月16日,被告Y5,A,被告Y2,被告Y6らが参加して原告システムの商品会議が行われ,今後のバージョンアップに向けてユーザーアンケートを行うこと,観光,ホテルの検索結果からURLに移行できるようにインターネット機能を強化すること,検索パレットは「駅・空港・フェリー」・「市区町村」・「道路地点」のみとすること,利用施設一覧表に休館日を表示した休館日チェックリストを追加すること等の機能強化の方針が打ち出された。〔甲63の別紙19,20〕
ケ 平成12年2月12日,被告Y5,A,被告Y2,被告Y3,被告Y6らが参加して原告システムの商品会議が行われ,原告システムの当時の次期商品として Ver5 の提案がされ,そこでは,原告システムをプロアトラスの地図を利用した旅行業システムとする方針で開発することとし,行程表の検索結果のルートを地図で表示し,地図から温泉地・施設が検索できるようにするため,その技術サンプルを被告Y5が作成することとされた。〔甲63の別紙22〕
コ 平成12年6月,被告Y5が文具・事務機システムのリーダーに転出すると,Aが原告システムの開発,改良に関する責任者となり,旅行代理店のヒアリング,要件定義,システム設計,データベース設計,開発等を行った。〔乙38,2頁〕
被告Y3は,同年8月7日付けで,原告システムの地図機能について,検索フローチャート,表示画面の遷移や地図表示画面との対応関係等についての提案を行い,同月21日付けでも,原告システムの地図機能について,検索フローチャート,表示画面の遷移や地図表示画面との対応関係等について,より詳細な提案を行っている。〔甲75の別紙3~5〕
サ 平成12年10月28日,Bのほか,被告Y2,被告Y3,被告Y4,Aが参加して原告システムについての営業会議が行われ,原告システムのVer5 の全機能についての仕様が決定されて紹介され,販売方法についても協議された。同会議における Ver5 についての紹介では,例えば,検索業務においては,サブメニューが「道路検索」,「時刻表検索」,「ホテル・旅館検索」,「観光施設検索」から,「道路」については「時間・経路・料金」,「時刻表」については「JR・AIR・フェリー」,「施設」については「宿泊」,「観光」,「地図」等のサブメニューが設けられることなどの,Ver4 からの改善点が全て紹介されている。加えて,同会議では,当時のユーザーに対する Ver5 の販売方法について,増設・バージョンアップ時は,リプレースを考慮して販売することとされ,①リース残1ないし2年のユーザーについてはリプレース商談を,②契約後1年未満のユーザーは,営業時の内容によりバージョンアップなどの商談を,③契約1年以上経過のユーザーは,契約時のバージョンで商談をすることとされ,各営業担当者は,担当する顧客のリース終了年月,売買契約書の使用権終了年月を調査し,Bに報告することとされた。〔甲71の別紙6〕
シ 平成12年11月ころから,地図検索機能,インターネット接続機能が追加された「スーパーフロントマン 旅行業システム Ver5」が販売された。〔甲63,3頁〕
ス 平成12年11月20日,Bのほか,被告Y3,被告Y6,被告Y5,Aが参加して原告システムについての商品会議が行われ,原告システムの今後のバージョンアップに向けて,当時の原告システムのユーザーに対し,ユーザーアンケートを実施し,その結果を反映させることとして,被告Y6がそのアンケートを作成することとされた。〔甲71の別紙26〕
セ 平成13年6月18日,Bのほか,被告Y6,被告Y5,Aが参加して原告システムについての商品会議が行われ(なお,被告Y3は参加していなかったが資料が配付された。),原告システムにおいては,観光施設データについて,1施設に4個までの料金しか保存できず,そのうち一番上に登録した料金しか連動できないこと,無料なのか料金設定がないのかが判断できないことが問題とされ,今後の課題とされるとともに,同一施設で複数のレコードが登録されている場合があることも報告された。そして,同一施設は一つのレコードにまとめ,料金を無制限に登録できるようにすること,連動できる料金を選択できるようにすること,無料の場合は「無料」,料金設定なしは「-」を表示するよう,原告システムを改良することとされた。〔甲63の別紙34〕
(2)  構築された原告CDDBの内容
以上のとおりの原告システムの開発当時における聞き取り調査や,販売開始後のユーザーの意見聴取の結果等も踏まえて,旧原告会社は,原告システムに用いられる原告CDDBを,平成17年(2005年)9月までに,以下のとおり構築した。なお,原告CDDBは,2005年9月版以降,2006年11月版までは,テーブル,フィールド及びリレーションに変更はないが,レコード数に若干の違いがある。〔甲35,1頁〕
ア 道路情報の選択について
前記(1)のとおり,原告システムを構築するに当たって実情調査を行った旅行会社である小田急トラベルにおいては,行程の所要時間算出のためロードマップを参照していることが判明していたところ,このロードマップは,貸切観光バスが通行するのに適した道路を選択して道路地点を設定し,隣接道路地点間のキロ数と時間を示した資料である。ロードマップにおいては,有料道路及び国道については名称ないし番号が示されるとともに,主な交差点ないし地名については,その地名とともに黒丸で示され,その黒丸と黒丸との間に,交差点ないし地名間の距離(キロ数)及び所要時間(分)が示されている。〔甲47〕
しかし,原告CDDBの作成に当たっては,まず貸切バスとして通常使用される大型観光バスによる移動に適切な道路の選択を行うこととした。この観点から,国道,高速道路,有料道路,首都高速などの都市高速道路については全ての道路を選択しているものの,都道府県道については約10%,市区町村道だけでも約306万以上に上る一般道路については,そのうちの約0.004%程度に相当する143の一般道路を大型観光バスによる移動に適切な道路として選択し,これを「10道路テーブル」に格納した。その際,道路番号を付すこととして「道路番号」のフィールドを設けるほか,「道路名」,「道路名読み」,「区分」の各フィールドを設けた。〔甲3,甲30,12~13頁〕
これを具体的にみると,例えば,県道及び道道の選択において,ロードマップにおいては,福島県については全県道516件のうちから12県道,北海道については全道道1128件(なお,平成18年(2006年)11月当時は913道路。甲31の1,2頁)のうちから64道道を選択しているところ,原告CDDBにおいては,これよりも多い,福島県において47県道,北海道においては80道道を選択しており,ロードマップと原告CDDBとで共通する県道,道道も,福島県について9道路,北海道についても33道路にすぎない。
次に,これら道路上にとる道路地点の情報についてみると,例えば,北海道の国道230号線における例をとると,ロードマップにおいては,選択している道路地点は14地点であるところ,原告CDDBはこれよりも多い25地点を選択し,このうち共通する道路地点は,5道路地点である。また,九州の国道3号線における福岡県内の道路地点をみると,ロードマップにおいては27地点であるところ,原告CDDBにおいては,これよりも多い48地点であり,共通する道路地点は3地点にすぎない。〔甲47,48〕
さらに,原告CDDBでは,大型観光バスが移動する経路,経由地,目的地と一応の所要時間,到着時間が示せればよいとの考え方をとり,そのため必要な道路地点情報に絞って選択して格納することとした。これは,実際の自動車の走行を前提として全ての交差点や目的地の道路地点の情報を必要とするカーナビゲーションシステムに比して情報量を少なく済ませることができるものであり,格納すべき情報量は格段に少なくなる。〔甲43,2頁〕
イ 道路地点情報の選択(緯度経度情報)について
(ア) 次に,原告CDDBにおいては,上記道路地点として選択した地点における情報を緯度及び経度のデータとして格納することとしたが,実際の作成については,まず,上記のとおりの大型観光バスが通過するのに適切と考えられる道路のうちの,行程表を作成する上で必要と考えられる適切な地点である,交差点,インターチェンジ,サービスエリア,パーキングエリア,観光施設,宿泊施設,駅,役所等の代表道路地点とするのに適切な地点につき,インターチェンジや観光施設等から最も近い交差点や,ユーザーの要望を充たすのに最も適切な地点を中心に,上記選択された道路上から選び出す作業を行った。
そして,道路上でどの場所を選ぶかが決まると,その具体的な地点についての緯度経度は,実際にその選択作業を行うこととなる原告CDDBの作成者自身において,具体的な地点をパソコンのマウスを地図上でクリックする方法で選択し,そこに示される緯度及び経度を,実際に入力する方法をとった。その情報は,「09地点名テーブル」に格納されている。「09地点名テーブル」には,「地点番号」,「地点名称」,「地点名称カナ」,「地点区分」,「都道府県コード」,「市区町村番号」,「地点経度」,「地点緯度」の各フィールドが設けられている。〔甲3,甲28,4~6頁,甲30,14頁〕
上記道路地点の選択は,平成18年(2006年)2月版の時点で1万2781件,同年11月版の原告CDDBにおいて,1万2822件である。〔甲32,1頁〕
(イ) そして,施設と関係する代表道路地点の選択においては,施設が接する道路地点ではなく,当該施設の近辺の道路地点を当該施設の代表道路地点として適宜設定し,その代表道路地点への経路検索をもって,当該施設への経路検索としている。その例として,横浜市中区のホテルニューグランドには,当該ホテルが接する道路ではなく,横浜市中区山下橋が設定され,これとは異なる施設のマリンタワーについても,同じ道路地点が設定され,横浜市中区内では,8か所の代表道路地点を設定しているにすぎない。また,地方では,施設が10キロメートル以上離れているものについて同一の代表道路地点を,70以上の施設について,一つの代表道路地点を設定している例もある。このように,施設が道路に接しているところをもって目的地とせず,当該施設の近辺の道路地点を当該施設の代表道路地点として適宜設定して経路検索を行うこととしたのは,施設の数だけ道路地点の情報を持つことは,道路地点の数を膨大にし,経路検索の効率も悪くなるため,あえてこのような構成をとったものである。〔甲43〕
(ウ) なお,翼システムは,平成8年1月ころに原告システムの販売を開始したが,当初の原告システムには,地図検索機能がなかったため,これら緯度経度情報は,一つのテーブルで保有するのではなく,「01市区町村テーブル」,「09地点名テーブル」,「20ホテル・旅館テーブル」,「21観光施設テーブル」,「32駅テーブル」のそれぞれのテーブルで重複して保有していた。
その後,前記(1)で認定したとおり,被告Y2,被告Y3,被告Y4,被告Y5,被告Y6及びAがその開発ないし営業に関与して,開発・販売された原告システムの Ver5 において,地図検索が効率的に行えるよう,「05緯度経度テーブル」を設けることとし,さらにインターネット接続のため「06URLアドレステーブル」,「07URL種別テーブル」,「08URL分類テーブル」を設けることとした。しかし,その際,既に原告システムを導入しているが,地図検索機能を必要とせず,新たな原告システムへの移行をしない顧客においても,問題なく使用し続けることができるよう,「01市区町村テーブル」,「09地点名テーブル」,「20ホテル・旅館テーブル」,「21観光施設テーブル」,「32駅テーブル」で重複し保有している緯度経度情報を,上記「05緯度経度テーブル」でも重複保有することとした。地図検索機能を使用すると,地図上で一定の範囲を指定し,「05緯度経度テーブル」により,その範囲内にある緯度経度の観光施設,宿泊施設,駅,市区町村等を検索して地図上に表示することができる。
「05緯度経度テーブル」には,緯度経度情報毎に,市区町村,ホテル・旅館,観光施設,地点,駅の各テーブルについての「種別番号」と各テーブルのプライマリー・キーとなる「種別毎番号」の情報を収録するとともに,関連する「01市区町村テーブル」,「09地点名テーブル」,「21観光施設テーブル」,「20ホテル・旅館テーブル」,「32駅テーブル」とリレーションを取っている。
ウ 道路の接続情報の選択について
(ア) 原告CDDBでは,選択された道路と道路との接続地点には,隣接する道路地点間の各道路について,「11接続テーブル」において,各接続番号で特定される細切れの道路を接続していくことで,出来るだけ所要時間の短い経路を検索することとした。「11接続テーブル」には,道路地点間の接続情報として,各細切れの道路の「始点番号」,「終点番号」,通行する道路の「道路番号」,移動に要する「所要時間」,2地点間の「距離」,上り下りの車線情報である「上下区分」,「禁止フラグ」,「接続番号」などの情報を,九つのフィールドに格納した。具体的な距離と時間の算定は,別紙1の「11接続テーブル」の「原告CDDBの各テーブルの概要」欄記載の例のとおりである。〔甲3,甲23,11頁〕
このうち,上記「接続番号」とは,一つの道路を細分化し,その道路の1単位毎に付与される番号であり,2地点間の情報を識別するものである。この接続番号は,原告システムの作成時に,ある道路の1単位を登録するたびにその都度原告が付与したものである。例えば,伊勢自動車道のうち,関JCTから芸濃ICまでの区間を接続番号1と,その逆を接続番号2として上下区分により区別し,同じく伊勢自動車道のうち芸濃ICから安濃SAまでの区間を接続番号3とする,等のものである。〔甲28の7頁及び別紙8〕
(イ) そして,その経路中には,道路条件により,進入禁止,右折禁止,左折禁止などの規制のある場合がある。そこで,原告CDDBにおいては,そのような経路が選択されないようにしておくため,「12禁止乗換テーブル」を設け,そこに選択不可とすべき道路の接続経路,すなわち,ある接続番号からある接続番号への乗換について,禁止されるパターンの情報を格納して,これを経路検索の場合に除外するようにした。「12禁止乗換テーブル」には,「乗換元接続番号」,「乗換先接続番号」のそれぞれの情報項目を設けて,各フィールドとした。〔甲3,甲30,11頁〕
原告CDDBの「12禁止乗換テーブル」には,上記のとおり,一方通行などの理由により,経路として接続できない道路の情報を格納しているところ,具体的には,上記「11接続テーブル」で持つ「接続番号」について,ある接続番号(始点番号,終点番号,道路番号などの情報)の経路から,ある接続番号の経路に乗り換えようとした場合に禁止される接続番号の組み合わせを,この「12禁止乗換テーブル」に情報として格納するものである。「12禁止乗換テーブル」の上記「乗換元接続番号」と「乗換先接続番号」のフィールドには,乗換元と乗換先の接続番号で禁止される乗換のパターンを特定して格納している。
これによると,「11接続テーブル」から各接続番号の始点,終点,道路番号がわかり,乗換を行う場合,乗換元の終点は乗換先の始点となる関係にあるので,接続された場合のルートは
乗換元の始点→(乗換元の終点=乗換先の始点)→乗換先の終点という関係になる。〔甲23,11~12頁〕この「12禁止乗換テーブル」には,「乗換元接続番号」を「16」,「乗換先接続番号」を「16606」などとして,数値がそれぞれ格納されている。〔甲28の別紙9〕
エ 移動手段に関する情報の選択について
また,移動手段の種別については,それまでの一般的な分類に従えば,鉄道,バスを含む自動車,飛行機,船等となるところ,原告CDDBにおいては,これを「JR」,「私鉄」,「空路」,「徒歩」とするほか,船については,想定する旅行会社が扱う旅行で利用頻度の高い「フェリー」として,必要な情報を「43交通機関種別テーブル」に格納した。その際,移動手段を提供する会社についての情報を「42会社テーブル」として格納することとし,交通会社を検索条件として,路線検索を行うことを可能とした。
この点につき,インターネット上での経路検索を可能とするウェブサイトにおいて交通会社を経路検索に用いるものは存せず,他の路線検索システムには見られない原告CDDBの特徴となっている。〔甲30,6,18頁,甲50〕
オ 観光施設情報の選択について
観光施設については,まず観光施設に関する様々な情報項目の中から,施設の名称,住所,緯度経度による位置情報,営業日や時間・駐車場の有無等の施設概要,利用料金等の43項目に分類することとし,フィールドとすることとした。また,これらの情報を格納する「21観光施設テーブル」とは別に,これを補う目的で,料金種別の増加に対応した施設利用料に関する情報項目や施設に関するコメントなどの情報項目を44に分類してフィールドとし,これを「22観光施設備考テーブル」に格納した。
また,観光施設の中から,旅行業者が取り扱うと考えられた観光施設を選択し,これを「21観光施設テーブル」,「22観光施設備考テーブル」に格納した。〔甲30,8頁〕
原告CDDBの「21観光施設テーブル」に収録されたレコード数は,別紙4のとおり,7万2093件である。
カ 宿泊施設情報の選択について
宿泊施設に関しては,宿泊施設に関する情報の中から,宿泊施設の名称,住所,緯度経度の位置情報,室数や収容人数・宴会場の有無・プールの有無等の施設情報などの43項目を選択して,これをフィールドとし,「20ホテル・旅館テーブル」に格納した。
また,宿泊施設の中から,旅行業者が取り扱うと考えられた宿泊施設を選択し,これを「20ホテル・旅館テーブル」に格納した。〔甲30,8~9頁〕
原告CDDBの「20ホテル・旅館テーブル」に収録されたレコード数は,別紙4のとおり,1万6229件である。
キ 小括(原告CDDBの概要の整理)
上記のとおり,分類して収集すべき情報項目の選択,及び情報自体の選択・収集を踏まえて,翼システムにおいて構築された原告CDDBの内容を整理すると,概ね,以下のとおりとなる。
(ア) 原告CDDBの概要としては,旅行業者がパソコンにインストールされた原告システムを使って行程表作成の業務を行うにあたって必要となる,観光施設データ,宿泊施設データ,全国各地の主要道路の道路地点や,隣接する道路地点間の大型観光バスの移動時間・距離,有料道路・高速道路の料金データ,鉄道・飛行機・フェリーに関する路線,駅,時刻表等の情報を収集し,蓄積したものである。原告CDDBでは,別紙2のとおり合計42個のマスターテーブル内に,別紙2,3のとおり合計405個のフィールド項目を配し,各テーブル間を別紙3のとおり設定されたプライマリー・キーにより,別紙5(別紙6,7も同じ)のとおりのリレーションをとって関連付けることで,修学旅行や会社の慰安旅行などの旅行目的や,所要時間,立寄り施設等の要望に合わせた行程表を作成するため,観光施設,宿泊施設,交通手段,経路,出発時間や到着時間,施設等への滞在時間などの具体的なスケジュールをどうすべきかといった事項を,各情報を検索した結果を選択することにより決定し,行程表を作成していくことを可能とした情報の分類体系ということができる。
そして,このような情報の分類を有機的に繋げ合わせて,具体的な行程表を作成するためには,顧客の出発地,帰着地,観光施設などの途中の立寄り地,宿泊施設,交通手段,経路を選択するとともに,出発時刻,到着時刻,滞在時間なども確定する必要があるところ,行程表作成及び検索システムのデータベースでは,これらの情報が,顧客等の具体的要求に基づき,求められたときに対応できるように,テーブル,フィールド及びリレーションを設計した上で,予め情報を選択して格納しておくことが必要となる。
このように,原告CDDBは,上記アないしカの方針で実際に集められた膨大な数のレコードを(各テーブルのレコード数については,別紙4のとおり),別紙2,3のとおりのテーブル,フィールドに格納し,別紙5(同6,7も同様)のとおりのリレーションをとることにより,効率的に検索・行程表作成業務を行えるようにデータベースとして設計したものである。
(イ) そこで,原告CDDBにおける具体的な検索過程と,テーブル,フィールド等の関係等について検討する。
まず,経路検索に関するテーブル及びフィールドの設定,体系的構成,リレーションの設定について,出発地,帰着地,観光施設などの途中立寄り地,宿泊施設,駅,空港,フェリー発着所などに関し,これと関連するテーブルである「01市区町村テーブル」,「20ホテル・旅館テーブル」,「21観光施設テーブル」,「32駅テーブル」に「代表道路地区コード」や「代表道路地点番号」のフィールドを持つこととしている。そして,道路利用の経路検索の対象として市区町村,観光施設,宿泊施設,駅がある場合には,それぞれの施設自体の緯度経度ではなく,これと関連した道路地点の緯度経度情報のデータを使って,その道路地点までの経路を検索することとなる。各施設等にかかるテーブルの「代表道路地区コード」や「代表道路地点番号」は,「09地点名テーブル」の「地点番号」とリレーションがとられていることにより,各施設までの経路を検索するときには,この「代表道路地区コード」や「代表道路地点番号」所定の道路地点までの経路を検索することになる。
また,施設を含めた経路検索を行う場合,施設関連の各テーブルに,「代表道路地区コード」や「代表道路地点番号」という道路地点のフィールドを持たせ,これと「09地点名テーブル」の「地点番号」との間でリレーションを取り,道路地点としての検索を行うという構成を採用している。
具体的には,別紙3記載のとおり,原告CDDBでは,「09地点名テーブル」の「地点番号」フィールドをプライマリー・キーに設定し,これと,別紙5で,青丸と青丸を結ぶ太線のうち黒太線で記載されたリレーションのとおり,「01市区町村テーブル」の「代表道路地区コード」フィールド,「20ホテル・旅館テーブル」の「代表道路地区コード」フィールド,「21観光施設テーブル」の「代表道路地点番号」フィールド,「32駅テーブル」の「代表道路地点番号」フィールドとにリレーションを持たせている。
また,禁止乗換に関するテーブル及びフィールドの設定,体系的構成,リレーションについては,道路利用の経路検索では「09地点名テーブル」及び「11接続テーブル」のデータを使って,所要時間の短い経路を検索して提示するものの,「12禁止乗換テーブル」を設けて,一定の接続経路を除外するように構成している。
上記の「09地点名テーブル」には,別紙3記載の各フィールドに,道路地点の情報(地点番号,地点名称,都道府県コード,市区町村番号,地点区分,緯度,経度など)を格納している。道路地点の情報は,経路検索をする場合の基本となる位置情報となる。「09地点名テーブル」の「地点番号」フィールドについては,上記のとおり「01市区町村テーブル」,「21観光施設テーブル」,「20ホテル・旅館テーブル」,「32駅テーブル」の「代表道路地区コード」や「代表道路地点番号」とリレーションを取り,また「11接続テーブル」,「12禁止乗換テーブル」ともリレーションを取って,旅行行程における具体的な経路検索,所要時間,距離,有料道路通行時の料金情報等の検索をするための基本的な情報となっている。
(ウ) 原告CDDBでは,鉄道,飛行機,フェリー等の経路検索を行う場合には,まず,ある地区や都道府県において交通機関を運営している会社等を特定し,そののちに路線等を特定する方法をとっている。
具体的には,まず交通機関を運営している会社等を特定するために乗車する地区,都道府県を絞り込み(「02地区・県名テーブル」による),次に当該区域の交通機関の会社を選択する(「42会社テーブル」,「44地方別会社索引テーブル」,「45検索地方範囲定義テーブル」,「46地方別路線索引テーブル」による)。すると,当該交通会社が運行している路線一覧が表示され,利用する路線を選択すると路線の駅等が一覧表で示される(「34路線テーブル」,「42会社テーブル」,「46地方別路線索引テーブル」による。)。そこで,出発時刻,乗車駅と降車駅等を選択して検索すると,利用可能な便(「32駅テーブル」,「34路線テーブル」,「36路線検索テーブル」,「39便テーブル」,「40運行日定義テーブル」,「47駅通過路線索引テーブル」による。)が表示されるので,利用する便を確定することになる。
ク 原告CDDBの各テーブルの相互関係
原告CDDBは,上記のとおり,42個のマスターテーブル,405個のフィールド項目からなり,原告CDDBの各テーブルの意義については,別紙1記載のとおりであるところ,原告CDDBの各テーブル相互の関係については,以下のとおり分類される。
「01市区町村テーブル」,「32駅テーブル」,「20ホテル・旅館テーブル」,「21観光施設テーブル」,「09地点名テーブル」,「11接続テーブル」,「10道路テーブル」により,出発地点,経由地,目的地に面した道路に関するデータの検索が可能になる。
次に「09地点名テーブル」,「10道路テーブル」,「11接続テーブル」,「12禁止乗換テーブル」,「14区間料金テーブル」,「15首都高速料金テーブル」により,道路を利用した移動に関する経路探索・料金の算出に必要なデータの検索を可能にしている。
そして,「20ホテル・旅館テーブル」,「21観光施設テーブル」,「22観光施設備考テーブル」,「05緯度経度テーブル」,「06URLアドレステーブル」,「07URL種別テーブル」,「08URL分類テーブル」により,ホテル・旅館,観光施設に関する情報を検索することを可能にしている。
「01市区町村テーブル」,「02地区・県名テーブル」は,道路と地図を関連付ける情報であって,地図から検索をするときに用いられている。
「32駅テーブル」,「33路線構成テーブル」,「34路線テーブル」,「36路線検索テーブル」,「39便テーブル」,「40運行日定義テーブル「42会社テーブル」,「43交通機関種別テーブル」により,公共交通機関を利用した経路探索に必要なデータの検索を可能にしている。
ケ 原告CDDBにおける検索,行程作成の実際
以上を踏まえて,具体的な検索,行程作成の実際について検討する。
まず,出発地を「01市区町村テーブル」を使って市区町村内の道路地点から選択する。その際,選択された市区町村内の道路地点として,「09地点名テーブル」の道路地点のうち,当該市区町村内にある道路地点を見ることができる。そして,市区町村の絞り込みは「02地区・県名テーブル」,方面については「03方面テーブル」,「04方面設定テーブル」,都道府県については,「02地区・県名テーブル」から絞りこむことができる。
また,「01市区町村テーブル」,「20ホテル・旅館テーブル」,「21観光施設テーブル」,「32駅テーブル」には施設等の近辺の道路地点の情報が代表道路地区コードや代表道路地点番号として格納されており,当該市区町村内にあるこれらの施設や駅などを選ぶことを通じて,出発点としての「09地点名テーブル」の道路地点を選ぶことができる。
次に,観光施設を「21観光施設テーブル」から選択する。観光施設の絞り込みは,上記と同じく,「02地区・県名テーブル」,「03方面テーブル」,「04方面設定テーブル」,「01市区町村テーブル」から行うことができる。観光種別は「23観光施設種別テーブル」(ただし,前記のとおり,CDで提供されるものではないことから,原告CDDB自体には含まれていない。)に,名称は「21観光施設テーブル」に,検索結果の観光施設について,当該観光施設に関する様々な情報は,「22観光施設備考テーブル」に格納されており,観光施設に関するホームページの情報も「06URLアドレステーブル」,「07URL種別テーブル」から参照可能であり,最終的に行程に入れるかどうかを判断することができる。
宿泊施設については,「20ホテル・旅館テーブル」から選択し,地区は「02地区・県名テーブル」,方面は「03方面テーブル」,「04方面設定テーブル」,都道府県は「02地区・県名テーブル」,市区町村は「01市区町村テーブル」,地図上の範囲設定は別途の地図ソフトであるプロアトラスと「05緯度経度テーブル」,「20ホテル・旅館テーブル」,宿泊種別は「20ホテル・旅館テーブル」,名称は「20ホテル・旅館テーブル」,検索結果の宿泊施設については当該宿泊施設に関する様々な情報,すなわち和室,洋室の客室数,収容人員,料金,付帯施設,駐車場などが「20ホテル・旅館テーブル」に格納されていて,当該宿泊施設に関するホームページの情報も「06URLアドレステーブル」,「07URL種別テーブル」が対応し,これらを参照してシステムのユーザーである旅行会社ないしその顧客の判断で決定することができる。
コ 原告CDDBのルート検索における交通機関別での必要なテーブル
原告CDDBにおいては,複数の道路地点を用いてルートを検索するところ,このときの利用交通機関別の必要なテーブルについては,以下のとおり整理することができる。
(ア) 道路利用(大型バス)
「09地点名テーブル」,「11接続テーブル」,「12禁止乗換テーブル」
原告CDDBでは,各市区町村,各観光施設,各宿泊施設,各駅の近辺にある道路地点の地点番号を「代表道路地区コード」や「代表道路地点番号」として,各テーブルのフィールドとして持たせ,道路利用の経路検索の対象として市区町村,観光施設,宿泊施設,駅がある場合には,各テーブルの「代表道路地区コード」や「代表道路地点番号」のフィールドに格納されている道路地点までの経路を検索するようにしている。
(イ) 鉄道利用
「02地区・県名テーブル」,「32駅テーブル」,「33路線構成テーブル」,「34路線テーブル」,「36路線検索テーブル」,「39便テーブル」,「40運行日定義テーブル」,「42会社テーブル」,「44地方別会社索引テーブル」,「46地方別路線索引テーブル」,「47駅通過路線索引テーブル」
(ウ) 飛行機利用
「02地区・県名テーブル」,「32駅テーブル」,「33路線構成テーブル」,「34路線テーブル」,「36路線検索テーブル」,「39便テーブル」,「40運行日定義テーブル」,「42会社テーブル」,「44地方別会社索引テーブル」,「46地方別路線索引テーブル」,「47駅通過路線索引テーブル」
(エ) フェリー利用
「02地区・県名テーブル」,「32駅テーブル」,「33路線構成テーブル」,「34路線テーブル」,「36路線検索テーブル」,「39便テーブル」,「40運行日定義テーブル」,「42会社テーブル」,「44地方別会社索引テーブル」,「46地方別路線索引テーブル」,「47駅通過路線索引テーブル」
(3)  翼システムないし旧原告会社の状況及びそこにおける被告Y1を除く個人被告らの活動等
ア 翼システムにおいては,平成11年1月に,当時の翼システム会長が脱税容疑で逮捕され,平成13年3月に実刑判決を受けるに至った。〔甲79〕
これらを受け,平成15年10月ころからは,翼システムにおいても人員削減等の話が出て,経営の存続が危ぶまれる声も聞かれるようになった。
イ 平成17年当時の翼システムにおける,被告Y2,被告Y3,被告Y4,被告Y6の担当営業地域は以下のとおりである。
被告Y2の担当は,概ね,北海道,青森,岩手,宮城,秋田,山形,福島,茨城,栃木,富山,石川の11道県である。
同じく被告Y3の担当は,概ね,千葉,三重,東京の3都県である。
同じく被告Y4の担当は,概ね,群馬,埼玉,神奈川,新潟,山梨,長野,静岡の7県である。
同じく被告Y6の担当は,広島,山口,徳島,香川,愛媛,高知,福岡,佐賀,長崎,熊本,大分,宮崎,鹿児島,沖縄の14県である。
これら被告Y2,被告Y3,被告Y4,被告Y6の4名の担当都県等は,合計で35都道県となり,被告Y2,被告Y3,被告Y4及び被告Y6の4名で,翼システムの顧客の8割以上を担当していた。〔被告Y2尋問調書2頁〕  その他の翼システムにおける営業の担当は,Bが岐阜,三重,福井,滋賀,京都の5府県及び大手ユーザー,訴外Cが大阪,兵庫,奈良,和歌山,鳥取,島根,岡山の7府県であった。〔甲78〕
ウ 被告Y6は,原告システムのサポート担当者として,原告CDDBを含むデータベースCDと,ユーザーのPCなどに原告システムのプログラムをインストールするため,プログラム部分やエントリーテーブル部分から成り,システム導入時にユーザー側に設置されるPC内に必要なプログラムやエントリーテーブル等をインストールすることを可能とするインストールCD,及び,これらがインストールされたノートパソコンを常に持ち歩いており,これらにはコピープロテクションがかかっておらず,そこに格納されているプログラム,データベース,データその他の情報にアクセスすることができた。〔甲63,71〕
エ また,被告Y3,被告Y2,被告Y4の3名,及び,営業も担当することとなった後の被告Y6は,翼システムの営業担当者として,営業活動中,原告CDDBを含むデータベースCDと,原告システムをインストールするためのインストールCD,及び,原告システムのデモ環境がインストールされている,営業担当者が,システム導入の見込み客に対し,原告システムのデモンストレーションをする際に使用するノートパソコンを常に持ち歩いており,これらにはコピープロテクションがかかっておらず,そこに格納されているプログラム,データベース,データその他の情報にアクセスすることができた。また,被告Y5は,被告Y3,被告Y2,被告Y4らの営業担当者は原告等の管理区域内に設置されており本来はアクセスできない開発系サーバー内に格納されている,プログラムやデータベース,これらに関する設計資料等を,それぞれ電子媒体,紙媒体その他の媒体等に複製し得る環境にあった。〔甲63,71〕
オ 上記デモンストレーション用の原告システムのプログラム及びデータベースは,最新の販売用の製品を顧客ないし導入見込み客にデモンストレーションを行うため,常に最新のものとされており,データベースのCDも,最新版が発行されるたびに,営業担当者全員に配布され,データの定期的な更新をすることが可能とされていた。〔甲71〕
(4)  個人被告らによる被告アゼスタの設立等
ア 被告Y3,被告Y2,被告Y4,被告Y5らは,平成17年6月ころまでには,旧原告会社を退社して旅行業システムを営む新会社を設立することの相談を始めた。〔被告Y2尋問調書21頁〕
イ 一方,被告Y1は,翼システム及び旧原告会社に在籍したことはなく,株式会社グッドウィルの取締役,株式会社エス・エス・アイ・トリスター,株式会社トリスターの代表取締役等,IT・ソフトウェア関係の事業の経営に携わってきた経験があり,被告Y3,被告Y2の高校の同級生で,知人でもあったことなどから,平成17年10月18日の被告アゼスタの設立に当たり過半を出資して,設立と同時に被告アゼスタの代表者に就任した。〔証人A尋問調書8頁〕
ウ Aは,被告アゼスタ設立に先立つ平成16年7月に,既に翼システムを退社し,訴外株式会社ストラテジィに入社していたが,平成17年7月頃,被告Y3及び被告Y5から,旅行業システムの販売をする設立準備中の被告アゼスタに加入することの勧誘を受け,同年11月に,被告アゼスタに入社した。Aが入社した当時の被告アゼスタには,常勤の役員,社員は,被告Y1のほかは,Aしかいなかった。〔証人A尋問調書3,9頁,乙38,1頁〕
エ 被告Y3は,平成17年9月ないし10月ころ,翼システムの社員であり,原告システムの営業及びサポート業務に携わっていた訴外Dに対し,翼システムを退社して被告Y3らと事業を行うことを勧誘したが,断られた。〔甲71〕
オ 被告Y5は,前記のとおり,平成17年7月ころには,既に翼システムを退職していたAを被告アゼスタの設立に向けて勧誘をしていたが,被告Y5自身はそのまま旧原告会社に在籍を続けた。被告Y5は,旧原告会社において,原告システムのプログラム,データベース,開発資料,メンテナンス資料等について自由にアクセスできる立場にいた。被告Y5は,遅くとも平成18年1月ころまでには,旧原告会社の社員でありながら,被告システムの当初版の開発にも携わり,入力の指示等を行っており,平成18年6月に旧原告会社を退社し,被告アゼスタに入社した。〔証人A尋問調書11頁,被告Y5尋問調書14,15,24~25頁〕
ただし,A及び被告Y5は,被告CDDBの当初版の開発当時,被告システムに用いられているSQLサーバーに関し,それほどのキャリアを積んではいない状態にあった。〔証人A尋問調書16頁〕
カ 被告アゼスタは,平成18年6月,当初版の被告システムの販売を開始した。被告Y2らは,旧原告会社の顧客に対し,被告アゼスタ設立の挨拶とシステム資料を一斉送付し,営業を行った。〔被告Y2尋問調書8頁〕
しかし,被告システムに関し,同月末に納入したアルピコ観光サービス株式会社から,被告システムの性能に関し,重大なクレームが寄せられるということがあった。〔証人A尋問調書19,20頁〕
キ 被告Y6は,平成18年10月まで旧原告会社において,原告システムの営業を担当していたが,同月,旧原告会社を退社した。〔乙42〕また,被告Y5は,平成20年6月,被告アゼスタを退社した。
ク 被告Y1は,平成20年7月に,「株式会社アゼスタ 営業部 Y1」の名義で,翼システムの顧客である旅行会社に向け,下記の内容の文書を送付した。なお,上記のとおり,被告Y1は翼システムに在籍したことはない。〔甲52〕

「翼システム株式会社在籍中はひとかたならぬ御愛顧を賜り,厚く御礼申し上げます。さて,昨年7月に弊社旅行業務システム『旅 nes Pro』を初めてご紹介させて頂き丁度一年が経過致しましたが,この間も順調に全国の旅行会社様に弊社システムをご導入頂きまして,6月末現在のユーザー数は222社,その内旧翼システム『スーパーフロントマン旅行業システム』から弊社システムへのお切り替えユーザー様が182社となっております。・・・現行システムリース満了に伴う契約更新やシステム増設をご検討の際には,何卒,比較検討頂けます様お願い申し上げます。尚,弊社システムにお切り換え頂く場合には,現行システムからのデータ移行,現行システムのリース残債下取り(社内規定の範囲内)等のご要望もお受け賜り致しますので,ご商談の際に遠慮なくお申し付け下さい。」
ケ 被告アゼスタは,平成20年8月18日,別紙被告物件目録記載11の被告CDDB(現行版)を含む被告システムの Ver2.80 を発売した。また,被告アゼスタは,同年11月発売の別紙被告物件目録記載12の被告CDDB(現行版)を含む被告システム Ver2.82 からは,施設マスタに「キーワード」のフィールドを設け,「世界遺産」,「祭り」,「観光・食事100選」などのテーマに沿って検索することを可能にした。
コ 被告Y6は,平成20年12月1日付け書類送付状を原告の顧客に送付したが,そこには,下記の記載がある。〔甲25の1。アンダーライン・太字は原文どおり。なお,「※」以下は,手書き記載。〕

「突然の資料送付にて大変失礼いたします。翼システム(株)営業として数回ご訪問させていただきましたY6と申します。その節は,長い間皆様にいろいろとお世話になり,誠にありがとうございました。新たに他社にて旅行業システム専門の会社を立ち上げさせていただきました。・・・全国にて300店舗以上の旅行社様が当社へ切り替えをしていただきました。※現在ご利用の翼システムも残リースが1年くらいだと思います。一度ご提案させていただけたらと思います。」
サ 原告は,平成21年5月15日付けで本件訴訟を提起し,その訴状は,同月27日までに被告らに対し送達された。
被告らは,同年6月,原告に対し,ロイヤルティの支払や原告事業の買取り等を条件とする和解の申入れを行ったが,原告に拒絶された。〔当事者間に争いがない〕
シ 被告らは,平成21年6月,別紙被告物件目録記載16の被告CDDB(現行版)を含む被告システム(Ver2.94)を販売した。同システムの被告CDDB(現行版,Ver2.94)においては,同年4月に発売された別紙被告物件目録記載15の被告システム(Ver2.92)の被告CDDBに比べ,原告CDDBにおける緯度経度情報の完全一致率(緯度及び経度を0.1秒単位で表すために原告が設定した6桁ないし7桁の数字で表される緯度経度の数値がすべて一致する率)が,約92%から8.1%に激減した。〔甲32,34,39〕
この点につき,Aは,原告から本件訴訟の提起を受けて,原告から指摘を受けるまで,これらが同じであることを知らなかったが,原告の指摘を受けたことから,交差点が中心になるようにマウスでクリックをして位置決めをして,数値の入れ直しをした結果であるとする。〔証人A尋問調書20頁〕
ス 平成21年10月,被告アゼスタは,新たに,バス運行管理システムの「バス快道」を開発し,その販売を開始し,同年12月には,「バス快道」をバージョンアップした。〔甲25の2〕
セ 被告Y1は,平成22年(2010年)11月29日付けで,被告アゼスタ「営業グループ Y1」の名義で手書きの新製品案内状を送付したが,そこには,下記の記載がある。〔甲53〕

「拝啓 貴社益々ご清栄のこととお慶び申し上げます。私どもアゼスタは旧翼システムにて旅行業システムの開発・営業に携わっていたメンバーで2005年10月に独立した会社です。弊社の旅行業システム『旅ネスプロ』は販売開始から4年間で約500社様,その内旧翼システム時代のお客様約300社様が『旅ネスプロ』へ切換導入して頂いております。・・・尚,弊社システムへお切換え頂くことは,現在システムをご使用している途中でも可能でございます。現行システムのリース残債の下取り現行システムからのデータ移行ができます。」
なお,このころ被告アゼスタから発売された製品は,被告CDDB(現行版)であり,平成22年8月3日に Ver2.99の2010年8・9月版が,同年10月4日に Ver2.99の2010年10・11月版が,同年12月6日にVer2.99の2010年12月・2011年1月版が,それぞれ発売されている。〔甲38〕
なお,このころ,後記のとおり,被告CDDBに存する原告CDDBと共通する誤りがある情報について,その誤りを訂正する変更がされているものがある。
ソ 被告らは,平成23年2月にも,原告に対し,再度の和解の申入れ及び個人被告らに対する訴えの取下げを求めたが,原告に拒絶された。〔当事者間に争いがない〕
タ 被告アゼスタは,平成23年2月7日発行で,被告CDDB(現行版)のVer3.1 を発売した。〔甲38〕
そして,被告アゼスタは,同年4月4日に,被告CDDB(新版)を含む被告システム(別紙被告物件目録記載22)の販売を開始した。
(5)  一般的なデータコピーのプロセスについて
データベース間でデータのコピーを行うには,CSV(Comma SeparatedValues)ファイルを使う方法と直接コピーする方法がある。〔甲67,70〕このうち,データベースのデータをCSVファイルに出力する場合には,1個のテーブルにつき一つのCSVファイルが作成され,テーブル内の1個のレコードが通常1行のデータとして出力される。その際,改行があると,次のレコードとして認識される。1レコード内のフィールドの区切りには「,(カンマ)」を挿入して出力するので,フィールド間は「,(カンマ)」で区切られ,「,(カンマ)」があると,次のデータとなる。
そこで,CSVファイルを使用する場合は,フィールド内のデータに改行や,「,(カンマ)」等が含まれ,かつこれらがフィールドやレコードの区切りを示すものでない場合は,データの前後を「”(ダブルクォート)」で囲う処理などを行い,フィールドやレコードの区切りとして扱われないようにする処理が必要となり,単純にコピーした場合には,CSVファイルへの抽出では,「,(カンマ)」,「”(ダブルクォート)」等が含まれているデータでは不都合が生じることがある。〔甲70,6~8頁〕
なお,タブ区切り(TSV:データをタブ文字で区切って並べたファイル形式)にすれば不都合が生じない場合があり,カンマ区切り(CSV)では,カンマ,ダブルクォート等は文字化けや項目ずれを起こすため,被告アゼスタでも,カンマ,ダブルクォート等が含まれているデータについてはタブ区切り(TSV)を使って上記支障が生じないように対処することは可能である。
(6)  顧客(システムのユーザー)が蓄積したデータの移行について
また,顧客(システムのユーザー)が使用しているシステムについて,別のシステムに移行する際には,顧客の元で作成・保存された既存のデータを,新システムでも使用できるようにするために,データを移行(コンバート)する必要がある。データ移行のためには,移行元のテーブルレイアウトが必要であるところ,原告システムで作成されたエントリーテーブルに保存されるユーザーデータは,原告CDDBの各マスターテーブルの情報と紐付けられており,原告CDDBのテーブル,フィールド,リレーション,フィールドにおける種別の設定,コードの割振りなどの内容や,テーブルレイアウトを知らないと,原告システムのユーザーデータを被告システムに移行することはできない。〔甲61〕
原告が顧客に提供した原告CDDBには,テーブル名,フィールド名,コードの意味,リレーション,予備の項目(別紙3の括弧内に「予備」と記載された,フラグ,区分,日付,数値等のフィールド)に格納されているデータの内容などの情報は格納されておらず,原告CDDBを解析しても,原告CDDBから被告CDDBへとユーザーデータの移行を行うために必要な,原告CDDBについてのテーブル名,フィールド名,コードの意味,リレーションなどの情報を取得することはできない。〔甲67〕
なお,移行元のテーブルID,フィールドIDと,移行先のテーブルID,フィールドIDとを対応させることができれば,両者の間でのデータ移行は容易に行うことができる。〔甲70〕
(7)  被告CDDBに格納されたデータ等について
被告CDDBに格納されたデータには,上記「,(カンマ)」や「”(ダブルクォート)」が含まれていることにより,データ移行がされた場合に不都合が生じたものと認められるものはない。
なお,被告らは,原告CDDBをコピーし流用したことは認めるが客観的なデータに誤記修正をした上であり,しかもカンマ区切り(CSV)ではカンマやダブルクォートが含まれていると文字化けや項目ずれを起こすため,これらが含まれている場合にはタブ区切り(TSV)を使ってデータ入力・加工を行っているものであると主張するところ,確かに,原告CDDBの「09地点名テーブル」の地点番号「12414」には,地点名称「北九州市(R3,県道270号)小倉北区上到津2」との地点が登録されており,この地点名称カナフィールドには,「キタキュウシュウシオク”ラキタクミヤコカミトウツ2」と,「オク”ラ」には,濁点ではなく「”(ダブルクォート)」が含まれており,被告CDDB(当初版・2006年版)には,「キタキュウシュウシオク”ラキタクミヤコカミトウツ2」と原告CDDBと同じデータがそのまま格納されている。しかし,上記「北九州市小倉北区上到津2」の正しい読み仮名は,「キタキュウシュウシコクラキタクカミイトウヅ2」であり,原告CDDBの表記は正しい読み方とも大きく異なるが,被告CDDB(当初版・2006年版)には,全く同じ表記でデータが格納されていることが認められる。〔甲70〕
(8)  原告における原告システム以外の製品の販売について
原告は,原告システムのほか,平成21年ころからは,多拠点向けの旅行業システムとして,「トラベルート・エヌエス」(以下「TR-NS」という。)を販売している。近年における原告システムとTR-NSの販売割合は,ほぼ同等である。〔証人B,12頁,弁論の全趣旨〕
2  争点(1)(原告CDDBの著作物性及び被告CDDBが原告CDDBに依拠して作成された複製物ないし翻案物といえるか)について
(1)  著作権法2条1項10号の3は,データベースにつき,「論文,数値,図形その他の情報の集合物であって,それらの情報を電子計算機を用いて検索することができるように体系的に構成したものをいう」とし,同法12条の2第1項は,「データベースでその情報の選択又は体系的な構成によって創作性を有するものは,著作物として保護する」と規定している。
このように,データベースとは,情報の集合物を電子計算機を用いて検索することができるように体系的に構成したものをいうところ,前記第2,1の前提事実及び前記1で認定した事実によれば,原告CDDBは,データベースの情報の単位であるレコードを別のレコードと関連付ける処理機能を持ついわゆるリレーショナル・データベースである。リレーショナル・データベースにおいては,入力される情報はテーブルと呼ばれる表に格納され,各テーブルはフィールド項目に細分され,あるテーブルのあるフィールド項目を他のテーブルのあるフィールド項目と一致させてテーブル間を関連付けることにより,既存の複数のテーブルから抽出したいフィールド項目だけを効率的に選択することができるデータベースであるから,情報の選択又は体系的な構成によってデータベースの著作物と評価することができるための重要な要素は,情報が格納される表であるテーブルの内容(種類及び数),各テーブルに存在するフィールド項目の内容(種類及び数),各テーブル間の関連付けのあり方の点にあるものと解される。
上記のような観点も踏まえ,原告CDDBのようなリレーショナル・データベースについて情報の選択に創作性があるというためには,データベースの主題,用途やデータベースの提供対象等を考慮して決定された一定の収集方針に基づき収集された情報の中から,更に一定の選定基準に基づき情報を選定することが必要であり,また体系的構成に創作性があるというためには,収集,選定した情報を整理統合するために,情報の項目,構造,形式等を決定して様式を作成し,分類の体系を決定するなどのデータベースの体系の設定が行われることが必要であると解される。
ただし,データベースにおける創作性は,情報の選択又は体系的構成に,何らかの形で人間の創作活動の成果が表れ,制作者の個性が表れていることをもって足りるものと解される。
(2)  次に,著作物の複製ないし翻案については,複製とは,印刷,写真,複写,録音,録画その他の方法により有形的に再製することをいうとされているところ(著作権法2条1項15号),著作物の複製は,既存の著作物に依拠し,これと同一のものを作成し,又は,具体的な表現に修正,増減,変更等を加えても,新たに思想又は感情を創作的に表現することなく,その表現上の本質的な特徴の同一性を維持し,これに接する者が既存の著作物の表現上の本質的な特徴を直接感得することのできるものを作成する行為をいうと解される。
また,著作物の翻案(著作権法27条)とは,既存の著作物に依拠し,かつ,その表現上の本質的な特徴の同一性を維持しつつ,具体的表現に修正,増減,変更等を加えて,新たに思想又は感情を創作的に表現することにより,これに接する者が既存の著作物の表現上の本質的な特徴を直接感得することのできる別の著作物を創作する行為をいう(最高裁平成13年6月28日第一小法廷判決・民集55巻4号837頁参照)。
そして,著作権法は,思想又は感情の創作的な表現を保護するものであるから(著作権法2条1項1号),既存の著作物に依拠して作成又は創作された著作物が,思想,感情若しくはアイデア,事実若しくは事件など表現それ自体でない部分又は表現上の創作性がない部分において,既存の著作物と同一性を有するにすぎない場合には,複製にも翻案にも当たらないというべきである。
データベースについては,情報の選択又は体系的な構成によって創作性を有するものは,著作物として保護されるものであるところ(著作権法12条の2),上記のとおり,データベースにおける創作性は,情報の選択又は体系的構成に,何らかの形で人間の創作活動の成果が表れ,制作者の個性が表れていることをもって足りるものあるが,データベースの著作物として保護されるのはあくまでも,具体的なデータベースに表現として表れた情報の選択や体系的構成であって,具体的な表現としての情報の選択や体系的構成と離れた情報の選択の方針や体系的構成の方針それ自体は保護の対象とはならないというべきである。
(3)  以上を前提に,まず被告CDDB(当初版・2006年版)につき検討する。
ア 被告CDDB(当初版・2006年版)と原告CDDBとの体系的構成の共通性
(ア) テーブルの種類及び数
a 一致するマスターテーブル
原告CDDBには42個の,被告CDDB(当初版・2006年版)には31個のマスターテーブルがそれぞれ含まれるところ,このうち,以下の24個のマスターテーブルについては,原告CDDBに含まれるマスターテーブルと一致することにつき争いがない。
一致することに争いのない24個のマスターテーブルは,以下のとおりである(原告CDDBのマスターテーブル。これと対応する被告CDDB(当初版・2006年版)の表記は別紙2該当欄各記載のとおり)。
・「01市区町村テーブル」
・「02地区・県名テーブル」
・「05緯度経度テーブル」
・「06URLアドレステーブル」
・「07URL種別テーブル」
・「08URL分類テーブル」
・「09地点名テーブル」
・「10道路テーブル」
・「11接続テーブル」
・「12禁止乗換テーブル」
・「13有料道路番号テーブル」
・「14区間料金テーブル」
・「15首都高速料金テーブル」
・「16道路構成地点テーブル」
・「17道路構成地点索引テーブル」
・「18市区町村通過道路索引テーブル」
・「19県範囲定義テーブル」
・「28協定施設テーブル」
・「29券種テーブル」
・「30協定旅館テーブル」
・「31連結協定テーブル」
・「32駅テーブル」
・「42会社テーブル」
・「44地方別会社索引テーブル」
そして,原告は,「20ホテル・旅館テーブル」,「21観光施設テーブル」及び「22観光施設備考テーブル」についても,これら三つのテーブルに対応する,被告CDDB(当初版・2006年版)の「21施設マスタ」,「29旅館マスタ基本」,「23観光マスタ基本」,「26観光料金マスタ」及び「25観光料金種別マスタ」は,一致するマスターテーブルである旨主張する。
このうち,被告CDDB(当初版・2006年版)の「21施設マスタ」,「29旅館マスタ基本」,「23観光マスタ基本」と原告CDDBの「20ホテル・旅館テーブル」,「21観光施設テーブル」とは,別紙3記載のとおり,フィールドのテーブルへのまとめ方は異なるものの,被告CDDB(当初版・2006年版)の下記テーブルについての合計19個のフィールドを除いては,いずれも原告CDDBのフィールドと共通し,被告CDDB(当初版・2006年版)に固有のフィールドといえるものは存在しない。
・「29旅館マスタ基本」テーブルにつき,以下のフィールド(フィールド名の右の記載はフィールドID)
シングル数(客室数_シングル),HLRMSGL
ツイン数(客室数_ツイン),HLRMTWN
その他数(客室数_その他),HLRMETC
TEL2(TEL2),HLTEL2
TEL2コメント(TEL2備考),HLTEL2CMNT
数値1(予備),HLNFILLER5
数値2(予備),HLNFILLER6
登録日時(作成日時),HLTOROKUYMD
更新日時(更新日時),HLKOSHINYMD
・「21施設マスタ」テーブルにつき,以下のフィールド(フィールド名の右の記載はフィールドID)
温泉地コード(温泉地番号),STSPACD
登録日時(作成日時),STOROKUYMD
更新日時(更新日時),STKOSHINYMD
削除フラグ,STDELETECLS
数値1(予備),STFILLER5
数値2(予備),STFILLER6
観光フラグ,STSTFLG
宿泊フラグ,STHLFLG
・「23観光施設マスタ」テーブルにつき,以下のフィールド(フィールド名の右の記載はフィールドID)
登録日時(作成日時),SGTTOROKUYMD
更新日時(更新日時),SGTKOSHINYMD
そして,上記19個のフィールドは,いずれも,それ以外の,例えばプライマリー・キーの設定された「施設コード」フィールドや,施設名称や種別,室数等,原告CDDBと一致するフィールドと比して,重要なものとはいえない。
また,別紙8記載のとおりと認められる被告CDDB(当初版・2006年版)のフィールド間のリレーションをみると(争いのあるリレーションについての判断は後記する。),施設コード同士,代表道路地点や市区町村コード等の間でリレーションをとるテーブルの参照の仕方もほぼ同じものであり,両者は同じ目的で使用されるものと認められる。
そうすると,これら被告CDDB(当初版・2006年版)の「21施設マスタ」,「29旅館マスタ基本」,「23観光マスタ基本」については,原告CDDBの「20ホテル・旅館テーブル」,「21観光施設テーブル」と実質的に一致するテーブルであると認められる。
また,被告CDDB(当初版・2006年版)の「26観光料金マスタ」と,原告CDDBの「22観光施設備考テーブル」とを比較すると,フィールド内容において,別紙3記載のとおり,原告CDDBの方が若干詳細にフィールド区分がされているものの,テーブルの参照の仕方はほぼ同じものであり,両者は同じ目的で使用されるものと認められる。そうすると,被告CDDB(当初版・2006年版)の「26観光料金マスタ」についても,一致するフィールドであると認められる。
一方,被告CDDB(当初版・2006年版)の「25観光料金種別マスタ」は,原告CDDBの「21観光施設テーブル」,「22観光施設備考テーブル」に,料金区分自体のフィールドは存するものの,被告CDDB(当初版・2006年版)の「25観光料金種別マスタ」の「料金種別コード」や「料金種別名称」自体の区分やフィールドが原告のCDDBには存在せず,そのテーブルが一致するものとは認められない。
以上によれば,原告CDDBと被告CDDB(当初版・2006年版)とで一致するマスターテーブルは,被告CDDB(当初版・2006年版)のテーブルで数えると上記28個,原告CDDBの対応するテーブルで数えると27個であると認められる。
b 一致しないマスターテーブル
上記のとおり,被告CDDB(当初版・2006年版)の「25観光料金種別マスタ」は,原告CDDBに対応するマスターテーブルが存在しない。
その他,原告CDDBのマスターテーブルのうち,「03方面テーブル」,「04方面設定テーブル」については,被告システムでは,方面検索の機能がないため,対応するテーブルが存在しない。
また,原告CDDBのマスターテーブルのうち,「33路線構成テーブル」,「34路線テーブル」,「35時刻表料金テーブル」,「36路線検索テーブル」,「37路線検索索引テーブル」,「38路線タイプテーブル」,「39便テーブル」,「40運行日定義テーブル」,「41時刻テーブル」,「43交通機関種別テーブル」,「45検索地方範囲定義テーブル」,「46地方別路線索引テーブル」,「47駅通過線索引テーブル」についても,被告CDDB(当初版・2006年版)に対応するマスターテーブルが存在しない。
このうち,「45検索地方範囲定義テーブル」については,二地点間の検索範囲を管理するためのテーブルであり,原告システム提供当時から存在するテーブルであるところ,原告システム提供開始当時は,パソコンの性能が低く,検索効率を上げるための工夫として必要とされていたが,その後,パソコンの性能が向上したため,必要性が乏しくなっていたテーブルであることが認められる。〔甲3,別紙2〕
なお,上記のうち,被告CDDB(当初版・2006年版)に存するが,原告CDDBに存しない2個のテーブル(「28観光詳細種別マスタ〔テーブルID;AZMSTKMK〕」と「27観光種別マスタ〔テーブルID;AZMSTSM〕」は,原告CDDBには含まれないものの,原告システムをユーザーのハードウェア内にインストールした際に作成される原告マスターテーブルの中に,これら被告CDDB(当初版・2006年版)の二つのテーブルに対応するマスターテーブル(「23観光施設種別テーブル」及び「24観光施設検索タイトルテーブル」)が存在する。
すなわち,上記原告システムの「23観光施設種別テーブル」に含まれるフィールドは「種別番号〔フィールドID;SKCLSCD〕」フィールド,「種別名称〔フィールドID;SKCLSNM〕」フィールドの二つのフィールドであるところ,被告CDDB(当初版・2006年版)の「28観光詳細種別マスタ」テーブルに含まれるフィールドは「詳細種別コード〔フィールドID;SKCLSCD〕」フィールド,「観光詳細種別名称〔フィールドID;SKCLSNM〕」フィールドのほかは,フラグ,区分,日付,数値,登録日時,更新日時等のフィールドであり,上記フラグ等を除いた重要なフィールドについてはフィールドIDが完全に一致している。また,原告システムの「24観光施設検索タイトルテーブル」に含まれるフィールドは「観光施設検索タイトルコード〔フィールドID;SSSEETLCD〕」フィールド,「表示タイトル名〔フィールドID;SSTTLNM〕」フィールド,「種別数〔フィールドID;SSCLSNUM〕」フィールド,「種別コード1〔フィールドID;SSCLS1〕」フィールド,「種別コード2〔フィールドID;SSCLS2〕」フィールド,「種別コード3〔フィールドID;SSCLS3〕」フィールド,「種別コード4〔フィールドID;SSCLS4〕」フィールド,「種別コード5〔フィールドID;SSCLS5〕」フィールド,「種別コード6〔フィールドID;SSCLS6〕」フィールド,「種別コード7〔フィールドID;SSCLS7〕」フィールド,「種別コード8〔フィールドID;SSCLS8〕」フィールド,「種別コード9〔フィールドID;SSCLS9〕」フィールド,「種別コード10〔フィールドID;SSCLS10〕」フィールドの13個のフィールドであるところ,被告CDDB(当初版・2006年版)の「27観光種別マスタ」テーブルに含まれるフィールドのうち「観光種別コード〔フィールドID;SSSEETLCD〕」フィールド,「種別名称〔フィールドID;SSTTLNM〕」フィールドについては,原告CDDBのフィールドIDと完全に一致しており,「観光種別コード〔フィールドID;SSCLS〕」フィールドについても,原告CDDBのフィールドIDのうち,「種別コード」フィールドのフィールドIDの数字を除く部分(「SSCLS」)と一致しており,その余はフラグ,区分,日付,数値,登録日時,更新日時等のフィールドとなっている。〔別紙3,甲8別紙B-3-1の2頁〕
このように,原告CDDBと一致しない被告CDDB(当初版・2006年版)の「27観光種別マスタ」と「28観光詳細種別マスタ」テーブルは,原告CDDBには含まれないものの,内容的にこれと一致するテーブルが原告システムには存在する。
(イ) 被告CDDB(当初版・2006年版)の各テーブルに存在するフィールドの種類及び数
原告CDDBには42個のテーブルに,405個のフィールドが存するところ,被告CDDB(当初版・2006年版)の各テーブルに存在するフィールドIDは別紙3記載のとおりであり,31個のテーブルに318個のフィールドが存する。
フィールドのうち,「作成日時」,「更新日時」及び「削除区分」のフィールドは,データ更新やテーブル管理を行うための管理項目であり,データベースの検索機能やデータの内容自体に影響を及ぼす性質のものではない。〔甲3,7頁〕
そうすると,被告CDDB(当初版・2006年版)における,「29旅館マスタ基本」,「21施設マスタ」,「23観光マスタ基本」,「26観光料金マスタ」,「25観光料金種別マスタ」,「27観光種別マスタ」,「28観光詳細種別マスタ」(別紙3の記載順)に各1個ずつ存在する「登録日時(作成日時)」及び「更新日時(更新日時)」フィールド(合計14個),「26観光料金マスタ」に1個存在する「料金デフォルトフラグ(削除区分)」の合計15個のフィールドを除くと,被告CDDB(当初版・2006年版)のフィールドのうち,これらを除いたフィールド数は,303個となる。
そして,このうち,別紙3記載のとおり,原告CDDBと被告CDDB(当初版・2006年版)とでは,一致するテーブル28個につき,一致するフィールドは299個である。
上記のとおり原告CDDBのマスターテーブルと一致する被告CDDB(当初版・2006年版)のテーブルにおけるフィールド項目については,別紙3記載のとおり,ここから登録日時,更新日時及び削除区分のフィールドを除くと286個となり,このうち原告CDDBと被告CDDB(当初版・2006年版)とで一致するフィールドは252個である。
(ウ) テーブル間の関連付け
別紙3のとおり,原告CDDBと被告CDDB(当初版・2006年版)とでは,原告CDDBのマスターテーブルと一致する28個のテーブルに関して,プライマリー・キーの設定につき,原告CDDBの「02地区・県名テーブル」の「地区コード」フィールドを除き,一致したフィールドないし同一のテーブルの同種フィールドにプライマリー・キーが設定されている。
また,別紙5,別紙8(青丸と青丸を結ぶ黒線〔黒太線を含む〕,及び,下記のとおり,青丸と青丸を結ぶ黒点線が,当裁判所の認めるリレーションである。)のとおり,原告CDDBのマスターテーブルと一致する28個のテーブルに関して,原告CDDBに存在する関連付けのほぼ全てについて,同様のリレーションが被告CDDB(当初版・2006年版)に存在するものといえる(なお,原告CDDBの「01市区町村テーブル」と「20ホテル・旅館テーブル」,「21観光施設テーブル」とのリレーション,被告CDDB(当初版・2006年版)の「4市区町村マスタ」と「21施設マスタ」,「29旅館マスタ基本」,「23観光施設マスタ」,「26観光料金マスタ」のテーブルとのそれぞれのリレーションの関係の評価については,後記のとおり)。
なお,この点に関して被告らは,被告CDDB(当初版・2006年版)の「道路構成地点マスタ〔テーブルID;AZMROADP〕」の「道路構成地点番号」フィールドと「道路構成地点索引マスタ〔テーブルID;AZMROADQ〕」の「道路構成地点インデックス」フィールド及び「構成地点数」フィールドとの各リレーション,「36道路名マスタ〔テーブルID;AZMROADA〕」の「道路コード」フィールドと「道路構成地点索引マスタ」の「道路構成地点インデックス」フィールドとのリレーションをいずれも否認し(別紙8で青丸と青丸を結ぶ黒点線で示されたリレーション),「道路構成地点マスタ」の「レコード番号」フィールドと「道路構成地点索引マスタ」の「道路構成地点インデックス」フィールドとのリレーション,「36道路名マスタ」の「道路コード」フィールドと「道路構成地点索引マスタ」の「レコード番号」フィールドとのリレーションの存在を主張するが(別紙8で赤丸と赤丸を結ぶ赤点線で示されたリレーション),別紙3記載のとおりの被告CDDB(当初版・2006年版)の「道路構成地点マスタ」,「道路構成地点索引マスタ」,「36道路名マスタ」の各テーブルに含まれるフィールドの数やプライマリー・キーの設定状況を含めたフィールドの内容,「4市区町村マスタ」及び「21施設マスタ」のテーブル等に存するそれぞれの「代表道路地点コード」フィールド等と「道路構成地点マスタ」の「道路構成地点番号」フィールドとの間にリレーションがとられていることについて争いがないこと,被告らが,別紙4記載のとおり,「36道路名マスタ」,「道路構成地点マスタ」,「道路構成地点索引マスタ」について,いずれも原告CDDBの対応するフィールド等からデータをコピーしたとしているところ,そのデータの内容などからすると,別紙8記載のとおり,「道路構成地点マスタ」テーブルの「道路構成地点番号」フィールドと「道路構成地点索引マスタ」テーブルの「道路構成地点インデックス」フィールド及び「構成地点数」フィールドとの各リレーション,「36道路名マスタ」テーブルの「道路コード」フィールドと「道路構成地点索引マスタ」テーブルの「道路構成地点インデックス」フィールドとのリレーション(別紙8で青丸と青丸を結ぶ黒点線で示されたリレーション)の存在がいずれも認められる。これに対し,被告CDDB(当初版・2006年版)の「36道路名マスタ」の「道路コード」フィールドと「道路構成地点索引マスタ」の「レコード番号」フィールドと「道路構成地点マスタ」の「レコード番号」フィールドと「道路構成地点索引マスタ」の「道路構成地点インデックス」フィールドとのリレーションの存在について,「道路構成地点索引マスタ」の「レコード番号」フィールドと「道路構成地点マスタ」の「レコード番号」フィールドには,それぞれプライマリー・キーが設定されているものの,上記のとおり争いのない「道路構成地点マスタ」の「道路構成地点番号」フィールドと他のテーブルの各地点コードフィールドとのリレーション,「36道路名マスタ」の「道路コード」フィールドと他のテーブルの各道路コードないし道路番号フィールドとのリレーションの関係や,上記のとおりの原告主張のリレーション(別紙8で青丸と青丸を結ぶ黒点線で示されたリレーション)の存在が認められること等からして,被告ら主張のリレーション(別紙8で赤丸と赤丸を結ぶ赤点線で示されたリレーション)の存在は認められないというべきである。
また,上記のとおり,被告CDDB(当初版・2006年版)では,原告CDDBの「20ホテル・旅館テーブル」,「21観光施設テーブル」,「22観光施設備考テーブル」の3テーブルに対応するテーブルとして,被告CDDB(当初版・2006年版)では「21施設マスタ」,「29旅館マスタ基本」,「23観光マスタ基本」,「26観光料金マスタ」の4テーブルを設けており,このうち「21施設マスタ」テーブルについては,別紙3,5,8記載の原告CDDBの「20ホテル・旅館テーブル」,「21観光施設テーブル」,被告CDDB(当初版・2006年版)の「21施設マスタ」,「29旅館マスタ基本」,「23観光マスタ基本」,「26観光料金マスタ」の各テーブルのそれぞれのフィールド,テーブル間のリレーションの内容を比較すると,被告CDDB(当初版・2006年版)の「21施設マスタ」テーブルは,原告CDDBの「20ホテル・旅館テーブル」及び「21観光施設テーブル」の共通項目を括りだしたものと認められ,上位のテーブルとして設けられているものと認められる。そして,原告CDDBにおける「01市区町村テーブル」が「20ホテル・旅館テーブル」及び「21観光施設テーブル」の二つのテーブルとリレーションを取っているのに対して,被告CDDB(当初版・2006年版)では「4市区町村マスタ」は,原告CDDBの「20ホテル・旅館テーブル」及び「21観光施設テーブル」の共通項目を括りだした上位のテーブルとなっている「21施設マスタ」の一つのテーブルとのみリレーションを取っていることから,これと関連するリレーションの線の分が,別紙5と別紙8を対比すると,少なくなっている。
イ 被告CDDB(当初版・2006年版)の体系的構成が,原告CDDBの複製又は翻案に当たるか
(ア) 上記のとおり,原告CDDBと被告CDDB(当初版・2006年版)とでは,原告CDDBにおける,「01市区町村テーブル」,「02地区・県名テーブル」,「05緯度経度テーブル」,「06URLアドレステーブル」,「07URL種別テーブル」,「08URL分類テーブル」,「09地点名テーブル」,「10道路テーブル」,「11接続テーブル」,「12禁止乗換テーブル」,「13有料道路番号テーブル」,「14区間料金テーブル」,「15首都高速料金テーブル」,「16道路構成地点テーブル」,「17道路構成地点索引テーブル」,「18市区町村通過道路索引テーブル」,「19県範囲定義テーブル」,「20ホテル・旅館テーブル」,「21観光施設テーブル」,「22観光施設備考テーブル」,「28協定施設テーブル」,「29券種テーブル」,「30協定旅館テーブル」,「31連結協定テーブル」,「32駅テーブル」,「42会社テーブル」及び「44地方別会社索引テーブル」の27個のテーブルにつき,これと一致する28個のテーブルが被告CDDB(当初版・2006年版)にも存する。
そして,別紙3のとおり,原告CDDBと被告CDDB(当初版・2006年版)とで一致するテーブルに存する総フィールドも288個にのぼり,このうち,原告CDDBと一致するフィールド数は,252個である。
さらに,テーブル間の関連付けについてみると,原告CDDBと被告CDDB(当初版・2006年版)とでは,別紙5,8のとおり,原告CDDBと被告CDDB(当初版・2006年版)とで一致するフィールドについて,同様のリレーションが存するものと認められる。上記のとおり,被告CDDB(当初版・2006年版)では,「21施設マスタ」を原告CDDBの「20ホテル・旅館テーブル」及び「21観光施設テーブル」の上位のテーブルとして設けているところから,原告CDDBにおける「01市区町村テーブル」と「20ホテル・旅館テーブル」,「21観光施設テーブル」とのリレーションに比して,被告CDDB(当初版・2006年版)の「4市区町村マスタ」は上位テーブルの「21観光施設マスタ」とのみリレーションをとっており,これと関連するリレーションの線が,原告CDDBと比して,その分少なくなっている。しかし,上記のとおり,原告CDDBの「20ホテル・旅館テーブル」,「21観光施設テーブル」,「22観光施設備考テーブル」についても,これら三つのテーブルに対応する,被告CDDB(当初版・2006年版)の「21施設マスタ」,「29旅館マスタ基本」,「23観光マスタ基本」,「26観光料金マスタ」と実質的に一致するテーブルであると認められること,そして,これらテーブルに含まれるフィールドの内容等からして,原告CDDBと被告CDDB(当初版・2006年版)における「01市区町村テーブル」ないし「4市区町村マスタ」と,宿泊施設及び観光施設等のテーブルとのそれぞれのリレーションのとり方は,実質的には同一であるものと認められる。
(イ) 前記認定のとおり,原告CDDBは,それまで存しなかった団体旅行の行程検索・行程表作成のため,顧客である旅行業者等からのヒアリングや寄せられた要望等に基づき,出発地,到着地,交通手段,経由地である観光施設,宿泊施設をデータベース化してこれをコンピュータで効率よく検索できるようにするためのデータベースであるところ,上記被告CDDB(当初版・2006年版)と共通するテーブルに関してみると,原告CDDBの「01市区町村テーブル」,「32駅テーブル」,「20ホテル・施設テーブル」,「21観光施設テーブル」,「09地点名テーブル」,「11接続テーブル」及び「10道路テーブル」により,出発地,経由地,目的地に面した道路に関するデータの検索を可能にし,次に「09地点名テーブル」,「10道路テーブル」,「11接続テーブル」,「12禁止乗換テーブル」,「14区間料金テーブル」及び「15首都高速料金テーブル」により,道路を利用した移動に関する経路探索・料金の算出に必要なデータの検索を可能にしていること,また,「20ホテル・旅館テーブル」,「21観光施設テーブル」,「22観光設備備考テーブル」,「05緯度経度テーブル」,「06URLアドレステーブル」,「07URL種別テーブル」及び「08URL分類テーブル」により,ホテル・旅館,観光施設に関する情報を検索することを可能にしていること,そして,「01市区町村テーブル」及び「02地区・県名テーブル」は,道路と地図を関連付ける情報として,地図から検索をするときに用いられていること,「01市区町村テーブル」,「20ホテル・旅館テーブル」,「21観光施設テーブル」及び「32駅テーブル」には施設等の近辺の道路地点の情報が代表道路地区コードや代表道路地点番号として格納されており,当該市区町村内にあるこれらの施設や駅などを選ぶことを通じて,「09地点名テーブル」の必要な道路地点を選ぶことができること,観光施設も「21観光施設テーブル」から選択し,絞り込みは,「02地区・県名テーブル」,「01市区町村テーブル」から行うことができること,観光施設の名称は「21観光施設テーブル」に,検索結果の観光施設について,当該観光施設に関する様々の情報は,「22観光施設備考テーブル」に格納されており,観光施設に関するホームページの情報も「06URLアドレステーブル」,「07URL種別テーブル」から参照可能であり,最終的に行程に入れるかどうかを判断することができること,が認められる。
また,宿泊施設については,「20ホテル・旅館テーブル」から選択し,地区は「02地区・県名テーブル」,都道府県も同じく「02地区・県名テーブル」,市区町村は「01市区町村テーブル」,地図上の範囲設定は,地図ソフトと「05緯度経度テーブル」,「20ホテル・旅館テーブル」により,宿泊種別は「20ホテル・旅館テーブル」,名称は「20ホテル・旅館テーブル」,検索結果の宿泊施設については当該宿泊施設に関する様々な情報,すなわち,和室,洋室の客室数,収容人員,料金,付帯施設,駐車場などが「20ホテル・旅館テーブル」に格納されていて,当該宿泊施設に関するホームページの情報も「06URLアドレステーブル」,「07URL種別テーブル」が対応し,これらを参照して,ユーザーである旅行会社ないしその顧客の判断で行程等を決めることができることが認められる。
以上のとおり,これら共通するテーブルについては,いずれも各テーブルを構成するフィールドにつき,原告CDDBと,被告CDDB(当初版・2006年版)とでほとんどが共通し,リレーションのとり方もほぼ共通するものである。
そして,両者で共通するこれらの体系的構成は,原告CDDBの制作者において,それまでのデータベースにはなかった設計思想に基づき構成した原告CDDBの創作活動の成果であり,その共通する部分のみでデータベースとして機能し得る膨大な規模の情報分類体系であると認められ,データベースとして制作者の個性が表現されているものということができる。
したがって,被告CDDB(当初版・2006年版)と共通する上記原告CDDBの部分については,データベースの体系的構成としての創作性を有するものと認めるのが相当である。
(ウ) 一方,原告CDDBと被告CDDB(当初版・2006年版)とを比較すると,両者で一致しないマスターテーブルとして,被告CDDB(当初版・2006年版)の「25観光料金種別マスタ」,「27観光種別マスタ」と「28観光詳細種別マスタ」があり,これらは,原告CDDBには含まれないものである。
このうち「25観光料金種別マスタ」については,そこに含まれるフィールドをみると,プライマリー・キーの設定された「料金種別コード」フィールド,「料金種別名称」,「料金メモ(管理用)」の各フィールドのほかは,フラグや日付,区分等のフィールドであり,このうち料金種別にかかるものは,原告CDDBの「21観光施設テーブル」,「22観光施設備考テーブル」では4種類までの料金しか登録することができないところ,被告CDDB(当初版・2006年版)の「25観光料金種別マスタ」を設けることにより5種類以上の料金設定についても登録できるようにテーブルを設けることとしたものである。〔乙20〕
しかし,上記のとおり原告CDDBでも料金種別により分類可能であったところ,これについて,料金種別を増やすためにテーブルを設けること自体は,原告CDDBに新たに創作的表現を加えたものとはいい難い。
また,「27観光種別マスタ」と「28観光詳細種別マスタ」については,上記のとおり,原告システムをユーザーのハードウェア内にインストールした際に作成される原告マスターテーブルの中に,これら二つのテーブルに対応するマスターテーブルである「23観光施設種別テーブル」及び「24観光施設検索タイトルテーブル」が存在し,しかも,これらテーブルについてのテーブルの種類やIDのほとんどが原告CDDBと被告CDDB(当初版・2006年版)とで一致することなどからすれば,これらは被告CDDB(当初版・2006年版)において新たに加わった創作的表現の成果ということはできず,実質的に原告システム中に存する原告CDDBと関連する部分を,CDで提供されるデータベース中に移した関係にすぎないものと認められる。
そして,フィールドについてみても,被告CDDB(当初版・2006年版)の「道路構成地点マスタ」,「道路構成地点索引マスタ」の各「レコード番号」フィールドについては,それぞれ「道路構成地点索引マスタ」テーブルの「道路構成地点インデックス」フィールド,「36道路名マスタ」テーブルの「道路コード」フィールドとのリレーションがとられていること等からすると,原告CDDBの「16道路構成地点テーブル」,「17道路構成地点索引テーブル」の各テーブルを構成するフィールドと実質的な相違はないものと認められる。
さらに,リレーションのとり方についてみても,原告CDDBと被告CDDB(当初版・2006年版)とで異なるリレーションとなっている,被告CDDB(当初版・2006年版)で「4市区町村マスタ」は,施設に関しては「21施設マスタ」とのみリレーションをとっていることから,原告CDDBにおける「01市区町村テーブル」が「20ホテル・旅館テーブル」,「21観光施設テーブル」の二つのテーブルとリレーションをとっていることに対して,リレーションが少なくなっているところ,既に検討したとおり,被告CDDB(当初版・2006年版)の「21施設マスタ」及びこれと関連する,「29旅館マスタ基本」,「23観光マスタ基本」テーブルについては,原告CDDBの「20ホテル・旅館テーブル」,「21観光施設テーブル」とは実質的に一致するテーブルであると認められることや,別紙8のとおり認められる被告CDDB(当初版・2006年版)の「4市区町村マスタ」,「31URLアドレスマスタ」,「34緯度経度マスタ」テーブル等と,「21施設マスタ」,「29旅館マスタ基本」,「23観光マスタ基本」テーブル等,及び,「21施設マスタ」テーブルと,「29旅館マスタ基本」,「23観光マスタ基本」テーブルとのリレーションのとり方からすると,リレーションのとり方において,被告CDDB(当初版・2006年版)のリレーションのとり方には,原告CDDBのリレーションのとり方に,新たな創作性を加えたものとはいえない。
(エ) そうすると,これら被告CDDB(当初版・2006年版)が原告CDDBと共通性を有する部分は,原告CDDBの創作的表現の本質的特徴の同一性が維持されており,これを直接感得することができるものというべきであり,被告CDDB(当初版・2006年版)において変更が加えられた部分については,創作性を有しない部分であるということができる。
ウ 被告CDDB(当初版・2006年版)と原告CDDBとの情報の選択の共通性
(ア) フィールド項目の選択の類似性
前記のとおり,テーブル管理のためのフィールドである「登録日時」,「更新日時」及び「削除区分」のフィールドを除いた被告CDDB(当初版・2006年版)のフィールド数のうち,252個が原告CDDBのフィールドと一致している。
このうち,被告CDDB(当初版・2006年版)の「4市区町村マスタ」の7個のフィールド,「03都道府県マスタ」の4個のフィールド,「緯度経度マスタ」の4個のフィールド,「31URLアドレスマスタ」の5個のフィールド,「35地点マスタ」の8個のフィールド,「36道路名マスタ」の4個のフィールド,「38禁止乗換マスタ」の2個のフィールド,「有料道路番号マスタ」のうちの「道路番号」フィールド,「39料金マスタ」の5個のフィールド,「40高速料金マスタ」の5個のフィールド,「道路構成地点マスタ」の「道路構成地点番号」フィールド,「道路構成地点索引マスタ」の2個のフィールド,「市区町村通過道路索引マスタ」の3個のフィールド,「県範囲定義マスタ」の4個のフィールド,「協定施設マスタ」の31個のフィールド,「券種マスタ」の19個のフィールド,「協定旅館マスタ」の21個のフィールド,「連結協定マスタ」の32個のフィールド,「47駅マスタ」の10個のフィールド,「42会社マスタ」の4個のフィールド,「地方別会社索引マスタ」の2個のフィールドでは,フィールドIDが原告CDDBの対応するフィールドと完全に一致している。詳細は別紙3記載のとおりである。
また,原告CDDBの「20ホテル・旅館テーブル」の「加盟団体種別」フィールドと被告CDDB(当初版・2006年版)の「29旅館マスタ基本」の「加盟団体種別」フィールド,原告CDDBの「20ホテル・旅館テーブル」の「和室客室数」・「洋室客室数」・「和洋室客室数」・「収容人員」・「付帯施設」フィールドと被告CDDB(当初版・2006年版)の「29旅館マスタ基本」の「和室数」・「洋室数」・「和洋室数」・「総収容人員」・「設備」フィールド,さらにはいずれもプライマリー・キーが設定されている,原告CDDBの「20ホテル・旅館テーブル」の「ホテル旅館コード」フィールドと被告CDDB(当初版・2006年版)の「29旅館マスタ基本」の「施設コード(施設番号)」フィールド,原告CDDBの「21観光施設テーブル」の「地区コード」・「都道府県コード」・「市区町村番号」・「観光施設名(カナ)」フィールドと被告CDDB(当初版・2006年版)の「21施設マスタ」の「地区コード」・「都道府県コード」・「市区町村コード」・「名称かな」フィールド,いずれもプライマリー・キーが設定された原告CDDBの「21観光施設テーブル」の「観光施設番号」フィールドと被告CDDB(当初版・2006年版)の「21施設マスタ」の「施設コード」フィールド,原告CDDBの「21観光施設テーブル」の「施設経度」・「施設緯度」・「代表道路地点番号」フィールドと被告CDDB(当初版・2006年版)の「21施設マスタ」の「施設経度」・「施設緯度」・「代表道路地点コード」フィールド等においても,フィールドIDが完全に一致している。
そうすると,フィールド項目の選択について,これらは一致しているものと認められる。
(イ) レコードの選択の類似性
さらに,被告らは,被告CDDB(当初版・2006年版)において,原告CDDBのテーブルのうち,以下の20個のテーブルに含まれるレコードをコピーして用いたことを認めている。
そのテーブルとは,「20ホテル・旅館テーブル」,「21観光施設テーブル」,「05緯度経度テーブル」,「06URLアドレステーブル」,「07URL種別テーブル」,「08URL分類テーブル」,「01市区町村テーブル」,「02地区・県名テーブル」,「09地点名テーブル」,「10道路テーブル」,「11接続テーブル」,「12禁止乗換テーブル」,「13有料道路番号テーブル」,「14区間料金テーブル」,「15首都高速料金テーブル」,「16道路構成地点テーブル」,「17道路構成地点索引テーブル」,「18市区町村通過道路索引テーブル」,「19県範囲定義テーブル」及び「32駅テーブル」である。
そして,別紙4の各テーブルのレコード数記載のとおり,このうち,レコード数が47で同一であり,一般的な内容のとおりであることが推認される「02地区・県名テーブル」を除き,原告CDDBの「09地点名テーブル」,「10道路テーブル」,「11接続テーブル」,「12禁止乗換テーブル」,「14区間料金テーブル」,「15首都高速料金テーブル」,「16道路構成地点テーブル」,「17道路構成地点索引テーブル」,「18市区町村通過道路索引テーブル」,「19県範囲定義テーブル」及び「32駅テーブル」においては,それらテーブルのそれぞれの数百ないし数十万のレコード数につき,各近似するレコード数が被告CDDB(当初版・2006年版)の対応するテーブルには収録されている。
(ウ) 具体的な情報の同一ないし類似性
a 地点名テーブルの道路情報
原告CDDB(2006年11月版)の「09地点名テーブル」には,1万2822件のレコードが収録され,被告CDDB(当初版・2006年版)の「35地点マスタ」には,そのうちの99.6%である1万2774件につき,一致する道路地点(例えば,「関JCT(伊勢自動車道・名阪国道)」,「芸濃IC(伊勢自動車道,県道10号)」等)のレコードが収録されている。〔甲32〕
b 緯度経度情報の一致
そして,原告CDDBの「09地点名テーブル」の上記道路地点の緯度経度情報は,前記のとおり,原告CDDB作成時に,作成者自身がパソコンのマウスを地図上でクリックする方法で選択した場所について,これを0.1秒単位で緯度経度を測定して数値化したものである。
その際,原告CDDBにおいては,一般的な度・分・秒の表記ではなく,度・分・秒につき,0.1秒単位で,A度B分C.D秒を以下の計算式で算出された数値で収録しており,6ないし7桁の数値となって算出される。なお,この0.1秒は,実際には約3メートルである。
(計算式)  A×36000+B×600+C×10+D
例えば,上記「関JCT(伊勢自動車道・名阪国道)」については,一般的な度・分・秒表記であれば,経度136度24分48.2秒,緯度34度50分33.1秒であるところ,これを上記表記で表すと,経度「4910882」,緯度「1254331」となる。
被告CDDB(当初版・2006年版)も,6ないし7桁の数値で緯度経度情報を収録しているところ,被告CDDB(当初版・2006年版)の「関JCT(伊勢自動車道・名阪国道)」の緯度経度表記も,全く同じ経度「4910882」,緯度「1254331」であり,上記道路地点のうち,この6ないし7桁で表される緯度及び経度情報につき,これが原告CDDB(2006年11月版)と完全に数値が一致する率(完全一致率)は98.7%であり,1万2652件の一致するレコードが収録されている。〔甲22,28,32,39,70〕
c 選択道路の一致
原告CDDBは,上記のとおり,大型観光バスでの移動に適した道路の選択を行っており,多くの府県道,道道等の中から,北海道では80道道,福岡県では47県道を選択しているところ,被告CDDB(当初版・2006年版)では,北海道では全く同じ80道道を,福岡県でもこれと一致する県道のうち41県道を選択している。〔甲48〕
d その他の情報の一致
(a) 原告CDDBの「06URLアドレステーブル」と被告CDDB(当初版・2006年版)の「31URLアドレスマスタ」における情報の一致
ⅰ 被告CDDB(当初版・2006年版)では,同一の宿泊施設のURLデータを,「マスタ種別(URL種別)」フィールド(フィールドID;RL1KIND)の「5」(以下,「URL種別5」という。)に,原告CDDBの「テーブル種別」フィールド(フィールドID;RL1KIND)と同じ施設番号で登録するとともに,これを再び「マスタ種別(URL種別)」フィールド(フィールドID;RL1KIND)の「8」(以下,「URL種別8」という。)に,原告CDDBと異なる施設番号で,重複登録している。
すなわち,原告CDDBでは,「テーブル種別」フィールド(フィールドID;RL1KIND)のURL種別の「5」として宿泊施設のURLデータを登録している。他方,被告CDDB(当初版・2006年版)は宿泊施設と観光施設のURLデータを,URL種別8として統合して登録していることに加え,URL種別5としても,宿泊施設の同じURLデータを重複登録していることになる。
その例として,原告CDDB「テーブル種別」フィールド(フィールドID;RL1KIND)のURL種別5の施設番号1番である「アイスバーグホテル」は,被告CDDB(当初版・2006年版)のURL種別5に原告CDDBと同じ施設番号1番で格納されているところ,被告CDDB(当初版・2006年版)のURL種別8では,同じ「アイスバーグホテル」が,施設番号9440番として重複登録されている。すなわち,被告CDDB(当初版・2006年版)は,同一の施設について,URL種別5とURL種別8とで異なる施設番号を付与してそれぞれ登録している。原告CDDB「テーブル種別」フィールド(フィールドID;RL1KIND)のURL種別5の施設番号2番である「札幌第一ホテル 本館」等についても,同様である。〔甲65の別紙1〕
これらは,原告CDDBのURL種別5のデータを一旦コピーし,その後これをURL種別8に番号を変えて登録したが,URL種別5のデータもそのまま残存してしまったことによるものと認められる。
そして,この原告CDDBの「テーブル種別」フィールド(フィールドID;RL1KIND)に登録されている上記URLデータにつき,被告CDDB(当初版・2006年版)において,1万5000件以上のデータが一致している。〔甲65〕
ⅱ 上記宿泊施設の重複登録と同様のことが,観光施設についてのURLデータについても認められる。
被告CDDB(当初版・2006年版)は同一の観光施設のURLデータを,「マスタ種別(URL種別)」フィールド(フィールドID;RL1KIND)の「6」(以下,「URL種別6」という。)に,原告CDDBの「テーブル種別」フィールド(フィールドID;RL1KIND)と同じ施設番号で登録するとともに,URL種別8に原告CDDBと異なる施設番号で重複登録している。すなわち,原告CDDBは,「テーブル種別」フィールドに,URL種別6として観光施設のURLデータを登録しているところ,被告CDDB(当初版・2006年版)は宿泊施設と観光施設のURLデータをURL種別8として統合して登録していることに加え,URL種別6として観光施設につき,同じURLデータを重複登録している。例えば,原告CDDBのURL種別6の施設番号1番の「朝里岳」が,被告CDDB(当初版・2006年版)のURL種別6に原告CDDBと同じ施設番号1番で格納されているところ,被告CDDB(当初版・2006年版)の種別8でも,同じ「朝里岳」が施設番号117174番として重複登録されている。登録番号2の「無意根山」等でも同様である。〔甲65の別紙2〕
すなわち,被告CDDB(当初版・2006年版)は,同一の観光施設について,上記宿泊施設と同様に,URL種別6とURL種別8とで,異なる施設番号を付与して重複登録している。
これも,上記同様,被告CDDB(当初版・2006年版)が原告CDDBのURL種別6のデータを一旦コピーし,その後種別番号8に番号を変えて登録したが,URL種別6のデータもそのまま残存してしまったことによるものと認められる。
これについても,原告CDDBにおいて登録されている4万件以上のURLデータが,被告CDDB(当初版・2006年版)と一致している。〔甲65〕
ⅲ URLに関し,原告CDDBは,開発者の便宜のためとして,URL種別番号の10000以降には,リンク集として,各種URLデータを選択して登録している。このURLデータの登録は,原告CDDBの制作者において,任意に選択して行ったものであることは,URLデータの内容からも明らかである。その例としては,後記のほか,種別キー1番の優先順位2ないし4は,順番に,「全国鉄道会社OFFICIAL 系サイト総合リンク」,「国道901号」,「秩父札所めぐり[西武鉄道HP]」となっていること等からも明らかである。〔甲65の別紙3〕被告CDDB(当初版・2006年版)におけるこのURLデータは,原告CDDBと完全に一致している。この中には,被告CDDB(当初版・2006年版)の用途等に鑑みると,意味があるものとは考えにくい翼システムのURLが,3箇所(タイトルが「注意書き」の2箇所,「翼システム株式会社」の1箇所,合計3箇所)も重複登録されている点についても,完全に一致している。〔甲65の別紙3〕
(b) 原告CDDBの「11接続テーブル」と被告CDDB(当初版・2006年版)の「37接続マスタ」における情報の一致
原告CDDBの「11接続テーブル」と被告CDDB(当初版・2006年版)の「37接続マスタ」において,各接続番号が一致している。この接続番号の付与は,前記のとおり,隣接する道路地点間を一単位として,その一単位ごとに,原告CDDBの制作者において付与した番号であり,機能としては,二地点間の情報を識別するものである。この接続番号は,原告CDDBにおいて定められた,ある道路の一単位を登録する都度,上記のとおり原告システムの制作者において,任意に付与したものである。
これについて,被告CDDB(当初版・2006年版)の「37接続マスタ」において,各道路の一単位に対して,原告CDDBと同じ接続番号が付与されている。〔甲28の別紙8。なお,別紙8の1/2の始点番号,終点番号につき,実際の地点名称を表示したものが2/2であり,格納されているデータが実質的に同じであることが認められる。〕
(c) 原告CDDBの「12禁止乗換テーブル」と被告CDDB(当初版・2006年版)の「38禁止乗換マスタ」における情報の一致
原告CDDBの「12禁止乗換テーブル」の「乗換元接続番号」,「乗換先接続番号」の各フィールドには,接続テーブルのデータが格納されている。これらのデータが原告CDDBと被告CDDB(当初版・2006年版)とで一致している。〔甲28の別紙9〕
被告らは,原告CDDBからコピーして入力し,追加,修正,削除した旨主張するが,原告CDDBの「12禁止乗換テーブル」のフィールドは,「乗換元接続番号」,「乗換先接続番号」の二つの数値フィールドのみで構成されており,しかもその内容は,数値を羅列した表にすぎないから,一般的な資料等と比較することで,その正誤判定や修正等を行うことができない性質のものということができる。加えて,原告CDDBの「12禁止乗換テーブル」は,「09地点名テーブル」のデータを3レコード分使用した上で,「10道路テーブル」の2レコード分,「11接続テーブル」の2レコード分のデータを使用し,これらテーブルとリレーションを取ることによって,はじめて意味のあるテーブルとなるものである。これらは,上記の原告CDDBの設計ないし情報の選択の方針に基づいてデータを組み合わせてできたものであり,一般的な資料と比較して正誤判定等を行う性質のものでもなく,またその正誤判定等が可能なものとも認められない。〔甲70,10頁〕
(d) 原告CDDBの「19県範囲定義テーブル」と被告CDDB(当初版・2006年版)の「県範囲定義マスタ」における情報の一致
ⅰ 原告CDDBが「19県範囲定義テーブル」において,原告が独自に設定した登録データについて,被告CDDB(当初版・2006年版)の「県範囲定義マスタ」に,同一のものが存在する。
原告CDDBの「19県範囲定義テーブル」のテーブルは,出発都道府県から到着都道府県までの経由可能性のある都道府県を管理しているテーブルであり,原告CDDBは,例えば,北海道から青森県までの経由可能性のある都道府県に関しては,「北海道,青森県,岩手県,秋田県」(通常想定される経路に比して原告が独自に設定した点は,岩手県,秋田県が入っていることである。),北海道から岩手県では,「北海道,青森県,岩手県,宮城県,秋田県,山形県」(原告が独自に設定した点は,宮城県,秋田県,山形県が入っていることである。)となっている。同様に他の例でも経由都道府県が,原告が独自に設定した組合せで選択格納されている。この47都道府県における出発と到着のパターンは2209(47×47)パターンあることになるが,被告CDDB(当初版・2006年版)では,原告CDDBの経由都道府県の組合せデータを完全に一致する形で格納している。〔甲65の別紙8〕
ⅱ 原告CDDBの「19県範囲定義テーブル」の,行程を開始する都道府県のコードである「始点県番号」,行程を終了する都道府県のコードである「終点県番号」,47都道府県の内32都道府県を通過するかどうかのデータである「県範囲定義ビット1」,47都道府県の内15都道府県を通過するかどうかのデータである「県範囲定義ビット2」の各フィールドに格納されているデータが,被告CDDB(当初版・2006年版)の「県範囲定義マスタ」で一致している(フィールドID等も全て一致することについては,別紙3のとおりである。)。ある都道府県からある都道府県に向かう場合,通過する都道府県にどの県を組み入れるかには選択の幅があると認められるところ,これを表した原告CDDBの県範囲定義ビット1,県範囲定義ビット2についても,このような選択範囲をとること自体については,選択の幅があるものと認められる。〔甲28の別紙10,甲65の別紙8〕
エ 被告CDDB(当初版・2006年版)の情報の選択が,原告CDDBの複製又は翻案に当たるか
(ア) 前記のとおり,原告CDDBと被告CDDB(当初版・2006年版)とでは,情報項目としてのテーブル,フィールドの設定について,被告CDDB(当初版・2006年版)のテーブル数31個のうちの,28個においてテーブルが一致している。そして,フィールド項目についても,318個のフィールドのうち,252個のフィールドが一致している。
(イ) そして,前記のとおり,原告CDDBと被告CDDB(当初版・2006年版)とで一致する,地点名テーブルの道路情報,緯度経度情報,接続テーブル及び禁止乗換テーブルの情報,県範囲定義テーブルの各情報は,いずれも原告CDDBの制作者において,前記認定のとおり,それぞれ選択の幅のある中から一定の選択方針に基づき選定し,あるいは全く任意に番号等設定したものであり,それぞれ創作性を有するものと認められる。
(ウ) さらに,原告CDDBにおいては,前記のとおり,旅行会社に対する実情調査等の結果を踏まえ,主たる目的として,大型観光バスによる団体旅行を主眼とした行程表作成のための便宜から,通常使用されるロードマップとは異なる観点である,貸切観光バスが通行するのに適した道路として,都道府県道については約10%,市区町村道では約0.004%程度を選択して「10道路テーブル」に格納し,道路地点として選択した地点における情報も緯度及び経度のデータとして格納することとし,これを大型観光バスが通過するのに適切と考えられる道路のうちの,行程表を作成する上で必要と考えられる適切な地点である,交差点,インターチェンジ,サービスエリア,パーキングエリア,観光施設,宿泊施設,駅,役所等の代表道路地点とするのに適切な地点を選別し,パソコンのマウスを地図上でクリックする方法で選択して,実際に入力したものである。また,施設と関係する代表道路地点の選択においても,施設が存する場所の緯度経度による地点ではなく,大型観光バスでの出入りの観点から,当該施設の近辺の道路地点を選び,当該施設の代表道路地点として適宜設定している。
このように,原告CDDBと被告CDDB(当初版・2006年版)との共通部分である,道路,道路位置,代表道路地点等の選別・選択についても,原告CDDBの制作者による創作活動の成果が表れており,創作者の個性が表現されているものといえる。
したがって,被告CDDB(当初版・2006年版)と共通する上記原告CDDBの部分については,データベースの情報の選択としての創作性を有するものと認めるのが相当である。
(エ) そして,これら被告CDDB(当初版・2006年版)が原告CDDBと同一性を有する情報の選択に関する部分も,原告CDDBの創作的表現の本質的特徴を直接感得することのできる同一性が維持されているものというべきである。
オ 被告らの主張に対する判断
(ア) 被告らは,原告CDDBにおける情報の選択は,客観的,標準的な基準に従った没個性的・汎用的なものにすぎず,創作性がないと主張する。
しかし,前記のとおり,原告CDDBにおいて,道路や道路位置,代表道路地点,緯度経度情報,接続・禁止乗換,県範囲定義等を選択,選定するに当たっては,極めて多数にのぼる選択対象として幅のある中から,専ら大型観光バスでの移動を前提とした効率的な経路検索,行程表作成を可能とするという観点からの情報の選別等がされており,その情報の選択には制作者の個性が表れており,創作性があるものということができる。
したがって,被告らの上記主張は採用することができない。
(イ) 被告らは,被告CDDB(当初版・2006年版)の施設情報に関する設計思想は,柔軟な検索や旅行計画の作成を利用者(旅行業者)が行うようになることを想定し,将来におけるデータベースとしての拡張性や格納効率,保守性を最大限に高めるという視点から,施設情報に関するデータベースを設計することとしており,具体的には,施設マスタという独立したマスターテーブルを上位テーブルとして用意し,宿泊施設マスタや観光施設マスタといった施設の類型別のマスターテーブルを,施設マスタの下位テーブルとして位置付ける格納方法をとることとし,最大2階層でデータを保持するテーブル構成を採用し,これにより,被告CDDB(当初版・2006年版)では,電話番号や住所などの施設の基本情報は,「宿泊施設」や「観光施設」といった施設類型の区別なく,一旦全て施設マスタに格納する設計としたことから,テーマに沿って施設を検索する場合に,データベースの構造上は,施設マスタのみを検索することで,テーマに沿った施設を検索することが可能な設計構造となったものである一方,原告CDDBにおける施設情報の格納方法は,テーマ別検索を意図していないため,ホテル・旅館テーブルと観光施設テーブルの二つの施設類型別のマスターテーブルでのみ,施設に関する情報を格納しており,この点で体系的構成が異なる旨主張し,それに沿う証拠として,乙19,27を提出する。
しかし,乙19,27は,いずれも被告Y1の作成した報告書であるところ,これらはいずれも被告らが用いる「格納方法」の語の意味について,被告CDDB(当初版・2006年版)におけるテーブルやフィールド,リレーションとの関係でいかなる意味を持つかについては何ら具体的に明らかにするものではなく,被告CDDB(当初版・2006年版)の「21施設マスタ」,「29旅館マスタ基本」及び「23観光マスタ基本」については,原告CDDBの「20ホテル・旅館テーブル」及び「21観光施設テーブル」と実質的に一致するテーブルであると認められることについては,既に検討したとおりである。
したがって,被告らの上記主張は採用することができない。
(ウ) 被告らは,被告CDDBも原告CDDBも,「NAVITIME」やカーナビゲーションシステムなどルート・路線検索を行うシステムではほぼ必ず採用されている方法であるダイクストラ法という一般的でありふれた最短経路検索方法を採用しており,これを実現するために,地点(始点)と地点(終点)並びにその間の距離及び所要時間等を格納していくという具体的な情報の格納方法それ自体において特段顕著な差異が生じ得るものではなく,このような格納方法自体には創作性が認められない旨主張する。
a そこで,まず,ダイクストラ法について検討する。
ダイクストラ法について,公開特許公報(特開平5-113340号,発明の名称「車載ナビゲータ」,出願日 平成3年10月22日,出願人アルパイン株式会社,甲45)には,以下の記載がある。
・「出発地点から目的地点までの最適経路を求める方法として,ダイクストラ法と称せられる方法が提案されている。このダイクストラ法は出発地点と目的地点を結ぶ直線を半径とする領域,あるいは該領域より大きめの領域内に存在する全交差点を考慮して出発地から目的地迄の最短経路を交差点ネットリストCRNLを参照して探索するものである。図10はダイクストラ法の概略説明図であり,道路を直線,交差点を直線の交点としてグラフ化したものであり,各交差点間の距離は既知で,STPは出発地(交差点),DSPは目的地(交差点)である。」(段落【0007】)
・「ダイクストラ法においては,交差点ネットリストCRNLを参照しながら,出発地を0次交差点として,該0次交差点に隣接する1次交差点1 ~A4 を探し,各1次交差点A1 ~A4 に対応させて1つ前の次数の交差点(出発地交差点)及び出発地からの距離を求める。次いで,各1次交差点A1 ~A4 について2次交差点Bij を探し,各2次交差点に対応させて1次交差点及び出発地からの距離を求める。」(段落【0008】)
・「【発明が解決しようとする課題】このようにダイクストラ法によれば,グラフ理論的に最短経路が求まる。」(段落【0011】)
b 上記記載によれば,ダイクストラ法自体は,地点間の最短経路を求める方法として公知のものであると認められるが,原告CDDBは選択された出発地や観光施設,宿泊施設,到着地等の間での最短経路を探索することを行っているものとしても,前記認定のとおり,原告CDDBの創作性については,原告CDDBがダイクストラ法を実現するためのシステムとして創作性を有するとするものではなく,テーブルやフィールド,これらのリレーションの体系的構成について創作性を認めるものであるから,その創作性の有無は,ダイクストラ法を実現するものとしてありふれているか否かと直接関係するものではないというべきである。
したがって,被告らの上記主張は採用することができない。
(エ) 被告らは,他に同種のデータベースが存在することを前提として,原告CDDBはありふれたものであって,著作物とはいえない旨主張し,それに沿う証拠として,乙35の1ないし6を提出する。
しかし,株式会社エヌシステムのホームページには,平成8年(1996年)4月に,JA旅行センター向け旅行業営業支援システムである「応援団くん」の展開を開始した旨の記載があるが,そのシステムの内容については何ら記載がなく,その詳細は明らかではない。〔乙35の1〕
また,株式会社JMC(ジェーエムシー)のホームページには,「国内行程表管理システム『eZROUTE(イージールート)』」に関する記載があるが,「カーナビで用いられている機能や詳細な電子地図を活用し,パソコン上でかんたん(=イージー)に行程表を作成することが出来るツールです。作成した行程表はモデルコースとして登録し,社内で共有することができます。画像をクリックするとデモ画像が流れます。」と記載されているにすぎず,「eZROUTE」は,株式会社JTB情報システムの国内行程表作成システムとして採用されているが,これについてもそのシステムの詳細は明らかではない。〔乙35の2,乙39,3頁〕
企業間取引サイトであるANTA-NETのホームページには,「社団法人全国旅行業協会(ANTA)が運営する観光商品流通システムで,インターネットを通じて観光関連事業者(旅行業者,宿泊・観光・運輸施設等)の業務拡大を支援するBtoB(企業間取引)サイトです。」との記載があるが,その詳細は何ら明らかではない。〔乙35の3〕
株式会社ワールドエキスプレスによる「国内/海外旅程表作成&見積集計旅行業支援システム World TAC」のホームページには,「国内・海外旅程表作成から見積書・請求書・実績集計まで 一連の手配業務を徹底的に合理化!」として,同システムには国内旅程表作成機能がある旨の記載があるが,同システムの具体的な内容については何ら記載されておらず,その詳細は明らかではない。〔乙35の4〕
株式会社エイブルズシステムの「Mr.トラベルくんシリーズ 旅の助」についてのホームページには,「旅行業,観光バス業,観光関連事業者向けの旅行行程表,見積書作成,顧客管理,営業管理が出来る旅行業務支援システムです。」との記載があるが,それ以上のシステムの詳細については何ら明らかではない。〔乙35の5〕
株式会社ウィ・キャンの旅行業基幹業務システムとして「シンフォニーアトゥー」を紹介するホームページには,「それぞれの部署の方,またそれぞれの機能が同時進行し,壮大な交響曲・・・を奏でるように旅行業が遂行されるシステムであるという願いを込めています。」等の記載はあるが,具体的なシステムの詳細については不明である。〔乙35の6〕
また,被告Y5も,JTBのシステムである「eZROUTE」,農協観光のシステム等を使ったことはないとし,これらシステムの具体的な構成や規模等の詳細については明らかにすることができない。〔被告Y5尋問調書21~22頁〕
以上によれば,原告CDDBが同種データベースの存在によりありふれたものであると認めるべき証拠はない。
したがって,被告らの上記主張は採用することができない。
(オ) 被告らは,自動車道路の経路探索上,当該施設の自動車出入口から最も近い道路地点(代表道路地点)を定めておくことは必要不可欠であり,これは自動車ルートの検索システムである「NAVITIME」や,一般的なカーナビゲーションシステム等でも同様であるから,原告CDDBに特徴的な部分とはいえないとして創作性がない旨主張し,それに沿う証拠として,乙29を提出する。
そこで,乙29について検討すると,まず,乙29の別紙1は「NAVITIME」の自動車ルート検索,同別紙2は「Map Fan Web」のルート検索,同別紙3は「カーナビゲーション(パナソニック ストラーダCN-DV250D)」のルート検索画面である。乙29別紙1の各地図上に示された目的地点である「G」は,いずれも施設(東京ディズニーランド)内の目的地点であって,道路上の道路地点ではないし,代表道路地点でもない。すなわち,乙29別紙1の2枚目(上の地図),3枚目(上下の各地図)及び4枚目(上下の各地図)の各地図の「G」は,いずれも目的地内の地点であり,道路上の地点とはいえない。これによれば,同システムでは,目的地となる施設内の地点(上記では,東京ディズニーランドの駐車場内に入り込んだ地点「G」)に直近となる道路地点を求め,その道路地点を前提に経路検索を行っているものと認められるから,目的地となる施設自体の緯度経度情報に基づき直近の道路地点を求めているものといえる。
また,乙29別紙2の「Map Fan Web」の事例についても,3枚目の上の地図の「5」近くのルート到着地点は東京ディズニーランドの駐車場内の地点,同5枚目の地図の「G」は遊園地内の地点で,いずれも施設内の地点であって,道路上の地点ではない。これら施設内に設定された目的地点に対して,道路について経路検索を行う場合は,これらの地点(施設内の位置情報)に直近の道路地点を前提に経路検索が行われているものといえる。同システムにおいても,上記「NAVITIME」のシステムの場合と同様に,施設情報のテーブルに代表道路地点を固定的に保有しているものではないということができる。
さらに,乙29別紙3の「カーナビゲーションシステム(パナソニックストラーダ)」についても,上記「NAVITIME」や「Map FanWeb」の各システムの場合と同様に,地図上に施設自体の位置を示すときの緯度経度情報と,経路検索時の目的地点の緯度経度情報が複数存在することを示すものであり,これらはいずれも道路上の緯度経度情報ではないから,施設情報として代表道路地点の情報を持つものを示しているとはいえない。
そうすると,これらはいずれも,原告CDDBのように,施設関係のテーブルに,予め代表道路地点を設けておくことを示すものではなく,施設情報として検索方法に応じて施設内に目的地点を複数持つものにすぎないというほかない。
したがって,被告らの上記主張は採用することができない。
(カ) 被告らは,ダイクストラ法を前提として,選択不可とすべき接続経路情報の設定を行うことは,旅行業者向けデータベースとしてありふれたものであると主張し,それに沿う証拠として乙30を提出する。
しかし,乙30の別紙1の1枚目には「◆リンクの使用可否情報を考慮可能-動的考慮」として「『・・・工事中により一時的に通行止めにしたい』などがあります。・・・動的にリンクの使用不可を設定することで実現可能です。」と記載されており,事前に選択不可のリンク(経路)をテーブルとして保有するものでないことは明らかである。
また,乙30の別紙1の2枚目では「◆道路の一方通行などの進行方向制約を考慮可能」として,「一方通行でない道路」については双方向のリンク(経路)を作成し,「一方通行の道路」については走行可能な方向のリンク(経路)のみを作成すると記載されており,選択可能なリンク(経路)のみを作成している例であることが明らかで,選択不可の接続道路情報テーブルを設けることを示しているものとはいえない。
さらに,乙30の別紙2の特許公報(特許第2641470号,発明の名称「ナビゲーション装置」,特許権者 アイシン・エィ・ダブリュ株式会社外1名)には,以下の記載がある。
・「そのために本発明は,出発地から目的地までの経路を探索して探索されたコースに基づき案内を行うナビゲーション装置において,始点から終点で表される道路単位で経路探索を行うための道路に関する情報からなる道路データを格納した記憶手段と,前記記憶手段に格納された道路データを用いて最適経路を探索する経路探索手段とを備え,前記道路データは,該道路データに接続する道路の進入禁止情報を有し,前記経路探索手段は,前記進入禁止情報により進入禁止である道路を除外して経路探索を行うことを特徴とするものである。
〔作用及び発明の効果〕
本発明のナビゲーション装置では,道路データに右左折禁止情報を設定するので,右左折禁止情報の記憶領域は少なくてよい。また,経路探索手段が経路を探索する際には右左折禁止情報の設定された道路を探索コースから除外するので,無駄な探索処理がなくなり,処理の高速化を図ることができる。
〔実施例〕
以下,図面を参照しつつ実施例を説明する。
・・・道路のネットワークデータは,道路のネットワークが例えば第2図(a)に示すような交差点番号・・・,道路番号・・・からなるものとした場合,交差点データについては同図(b),道路データについては同図(c),ノードデータについては同図(d)に示すようなデータ構成となっている。
すなわち,交差点データは,同図(b)に示すように交差点番号・・・に対応して交差点名,当該交差点が始点となっている道路のうち一番番号の小さい道路番号,当該交差点が始点となっている道路のうち一番番号の小さい道路番号,信号の有無からなる。
また,道路データは,同図(c)に示すように道路番号・・・に対応して交差点番号による始点,終点,同じ始点を持つ道路のうち番号が次のもの,同じ終点を持つ道路のうち番号が次のもの,道路の太さ,禁止情報,案内不要情報,写真番号,ノード数,ノード列データの先頭アドレス,長さ等からなる。
そして,ノードデータは,同図(d)に示すように東経,北緯,属性等からなり,道路データから明らかなように道路番号の単位は複数個のノードからなる。すなわち,ノードデータは道路上の1地点に関するデータであり,ノード間を接続するものをアークと呼ぶと,複数のノード列のそれぞれの間をアークで接続することによって道路が表現される。例えば道路番号に関して見ると,道路データよりノード数 15 からなりノードデータの先頭アドレスが100であることから,道路番号は,100から114までのアドレスのノードデータで構成されることになる。
これらのネットワークデータによると,・・・このように特に道路データでは,右左折禁止等の進入禁止の道路番号と案内不要の道路番号をもっていることにより,情報記憶の容量を少なくし,また経路探索を容易に行えるようにしている。」(2頁3欄31行~3頁5欄19行)
上記記載は,隣接する道路地点間の道路間の道路を一単位とした道路に関するデータである道路データを格納するテーブルである,原告CDDBであれば「11接続テーブル」,被告CDDB(当初版・2006年版)であれば「37接続マスタ」(なお,被告CDDB(現行版),被告CDDB(新版)の「37単経路マスタ」についても同様である。)のテーブル自体に右左折禁止の情報を格納する例を示すものであり,禁止されている道路間の接続情報のテーブルを別途設けるものが示されているわけではない。
したがって,被告らの上記主張は採用することができない。
(キ) 被告らは,路線の特定に交通会社の特定も重要であるから交通会社の情報を格納するのは当然のことであると主張する。
しかし,交通会社を条件設定して検索する例については,証拠上見当たらず(甲50),経路検索において必要となる情報につき交通会社テーブルを設けることが当然のことであるということはできない。
したがって,被告らの上記主張は採用することができない。
カ 依拠性について
次に,被告CDDB(当初版・2006年版)が原告CDDBに依拠して制作されたものであるかにつき判断する。
(ア) 依拠性に関連する事実
被告らは,被告CDDB(当初版・2006年版)につき,前記記載の複数のテーブルについて,データを原告CDDBからコピーして利用した事実を認めているところ,その他にも,以下の事実が存する。
a テーブル,フィールドの各IDについて
原告CDDBと,被告CDDB(当初版・2006年版)との対応するテーブルとフィールドについて,テーブルID,フィールドIDの一致する例については既に検討したとおりであるが,完全に一致するものでなくても,被告CDDB(当初版・2006年版)では,テーブルIDの頭3文字を「AZM」にするなどし,それら以外はテーブルID,フィールドIDが完全に一致している例が多数みられる。その詳細は,別紙3のとおりであり,これらのうち,原告CDDBと一致するテーブルID,フィールドIDについては,原告CDDBのデータをコピーしたことによるものと認められる。〔甲9,23,55〕
この点に関してAは,その証言において,原告CDDBと被告CDDBとのフィールドID,テーブルIDの一致につき,フィールドIDの一致については認めるものの,テーブルIDについては「TRV」と「AZM」の部分のみが異なるものがあるが,その余はすべて一致する理由について,10年近くプログラム作業に従事していたことから,全て頭の中に入っており,開発効率を上げるために命名したとし(証人A13頁),その一方で,Aは,原告システムのプログラムの入力には一切関与しておらず,全て旧原告会社(翼システム)の方針に従って入力を指示しただけであるとも証言するが(証人A6頁),これらの証言部分は,Aが原告システムの開発経過において,プログラマーとして参加して被告Y5の下でサブリーダーとなり,その後被告Y5の転出後に原告システムの開発,改良における責任者となったとの事実経過に反する上に,内容的にも不合理であり,信用することができない。
b 緯度経度情報について
原告CDDBでは,バージョンアップ時に,新バージョンである Ver5に移行しない顧客のために,「01市区町村テーブル」,「09地点名テーブル」,「20ホテル・旅館テーブル」,「21観光施設テーブル」,「32駅テーブル」と,緯度経度テーブルとで緯度経度情報を重複保有していることについては既に検討したとおりであるところ,被告CDDB(当初版・2006年版)は,本来必要のない緯度経度情報を複数テーブルで重複保有している。
なお,被告らは,これにつき,被告CDDB(新版)から緯度経度マスタ自体を削除している。
c URLアドレステーブルについて
原告CDDBではタイトルに用いるカタカナについて全角(例として,「青森県[観光コンベンション協会HP]」と半角(例として,その次の優先順位となっている,「青森県[観光情報ネットワークHP]」)が不規則に混用されている例が見られるところ,被告CDDB(当初版・2006年版)の全角半角の混用使用箇所が,原告CDDBと完全に一致する例がある。〔甲28の別紙4〕
d 地点名テーブルについて
(a) 原告CDDBの誤りである地点名の表記「阿武隅PA」(正しくは「阿武隈」)と同じ誤りが,被告CDDB(当初版・2006年版)に存在する。ちなみに,別紙4の被告CDDB(当初版・2006年版)の「35地点マスタ」の被告らの主張欄記載のとおり,被告らは,原告CDDBをコピーして入力した上で追加・修正・削除した旨主張するところであるが,NEXCO東日本のホームページには正しい表記がされている。〔甲21〕
原告は,平成19年8月にその誤りに気付き,その時点で修正をしているが,被告CDDBでは,現行版の Ver2.6(2007年12月5日01版)においても,この誤りがそのまま引き継がれており,その後に,被告らは修正している。
(b) 原告CDDBと同じ誤りが被告CDDB(当初版・2006年版)に存在する。例えば,京都市右京区渡月橋の読みについて「キョウトシウキョウクトゲツバシ」となっているところ,正しくは「キョウトシウキョウクトゲツキョウ」である。
被告らは,原告からの指摘を受け,その後修正した。〔甲65〕
(c) 原告CDDBと同じ誤りが被告CDDB(当初版・2006年版)に存在する。例えば,北九州市小倉北区清水の読みが「キタキュウシュウシコクラキタクシミズ」となっているところ,正しくは「キタキュウシュウシコクラキタクキヨミズ」である。
被告らは,原告からの指摘を受けて,その後修正した。
(d) 原告CDDBと同じ誤りが被告CDDB(当初版・2006年版)に存在する。福岡市中央区警固の読みが「フクオカシチュウオウクケイコ」となっているところ,正しくは「フクオカシチュウオウクケゴ」である。
被告らは,原告からの指摘を受け,その後修正した。
e 道路テーブルについて
(a) 原告CDDBと同じ誤りが,被告CDDB(当初版・2006年版)に多数存在する。例えば,道路番号原告CDDB462(AZ634)道路名「金精道路」の読みの誤りの一致の例がある。これについて,「キンセイドウロ」は誤りであり,正しくは「コンセイドウロ」であるが,この誤りが一致している。
なお,この誤りは,被告CDDB(現行版)にも引き継がれている。
その後,被告らは,被告CDDB(新版)において,道路名の読み仮名である「道路カナ」のフィールド自体を削除している。〔甲65の別紙4〕また,原告CDDBでは,茨城県の読み仮名を,「イバラキケン」(正)と「イバラギケン」(誤)を混在して登録している。
この正誤の混在状況が,被告CDDB(当初版・2006年版)においても,一致して存在している。〔甲65の別紙5〕
(b) 原告CDDBに格納されたダミーデータ「***」(道路名),「ンダミー」(道路名の読み)が被告CDDB(当初版・2006年版)においても一致している。
被告らは,原告からの指摘を受け,被告CDDB(新版)においてはこれらを削除している。〔甲21〕
f 首都高速料金テーブルについて
以下の例のとおり,原告CDDBと同じ誤りが被告CDDB(当初版・2006年版)に存在する。
芦ノ湖スカイラインの大型車の通行料金が「2,200円」のところを,中型車の「1,400円」という誤ったデータを登録している。
阿蘇町営有料道路の中型車の通行料金が「1,580円」のところを,普通車の「560円」という誤ったデータを登録している。
久住高原ロードパークの大型車の通行料金が「2,000円」のところを,中型車の「1,250円」という誤ったデータを登録している。
なみはや大橋(尻無川新橋有料道)の中型車の通行料金が「100円」のところを,大型車の「150円」という誤ったデータを登録している。
また,原告CDDBでは,蔵王ハイラインの大型車の通行料金が「2,100円」のところを,「1,300円」という誤った料金データで格納していたところ,これと同じ誤りが被告CDDB(当初版・2006年版)に存在した。〔甲65の別紙7〕
g ホテル・旅館テーブルについて
(a) 宿泊施設の読み仮名に関して,原告CDDBと同じ誤りが被告CDDB(当初版・2006年版)に存在する。原告CDDBでは宿泊施設名の読み仮名について長音符「ー」とすべきを誤って数字記号マイナス「-」で登録した場合があるところ,これらと同じ誤りが被告CDDB(当初版・2006年版)に存在する。
以下は,読み仮名に長音符「ー」とマイナス記号「-」が混用されている一例であるところ,同様の事例が多数存在する。〔甲65〕
原告CDDB
施設名:リゾートホテルローゼンハイム白馬
施設カナ:リゾートホテルロ-ゼンハイムハクバ
被告CDDB(当初版・2006年版)
施設名:リゾートホテルローゼンハイム白馬
施設カナ:リゾートホテルロ-ゼンハイムハクバ
(b) 宿泊施設名の読み仮名に関する原告CDDBと同じ誤り(施設カナ)が被告CDDB(当初版・2006年版)に存在する。以下のとおりであり,「カナざワ」となっているほか,「新潟」,「大垣」がそのまま漢字で表記されている誤りがある。
・施設名:金沢みなとホテル
施設カナ:カナざワミナトホテル
・施設名:スターホテル新潟
施設カナ:スターホテル新潟
・施設名:チサングランド大垣
施設カナ:チサングランド大垣
h 観光施設テーブルについて
(a) 観光施設名の読み仮名に関して,原告CDDBと同じ誤りが被告CDDB(当初版・2006年版)に存在する。
原告CDDBは宿泊施設名称の読み仮名を表記するフィールドを有しており,宿泊施設名に「英字」「数字」を含む場合,「英字」「数字」について,きちんとした読み仮名である,例えば1をワンないしイチとするなどの方法で表記されているものと,読み仮名に英字や数字がそのまま残っているものとが混用されている。この原告CDDBの混用状態は,理由はともかくとしても,原告独自のデータの登録状態であるということができる。
これにつき,被告CDDB(当初版・2006年版)にも,原告CDDBと同一の混用状態のものが相当数存在する。例えば,原告CDDBの施設名称「美利河I遺跡」(「I」は英字のアイ)は誤りであり,「美利河Ⅰ遺跡」(「Ⅰ」はギリシャ数字の1)とするのが正しいところ,被告CDDB(当初版・2006年版)では,被告CDDB(現行版)に至るまで,原告CDDBと一致する誤り(英字の「I」)の登録をしている。〔甲65〕
(b) 観光施設の読み仮名に関して,原告CDDBと同じ誤りが,被告CDDB(当初版・2006年版)に存在する。すなわち,原告CDDBでは観光施設名の読み仮名について長音符「ー」とすべきところを,誤って数字記号マイナス「-」で登録した場合が相当に存するところ,これと同じ誤りが被告CDDB(当初版・2006年版)に存在する。下記は読み仮名に長音符「ー」とマイナス記号「-」が混用されている一例であるが,同様の事例が相当数存在する。〔甲65〕
・原告CDDB
施設カナ:アカンネイチャーセンタ-
・被告CDDB(当初版・2006年版)
施設カナ:アカンネイチャーセンタ-
(c) 株式会社,有限会社の施設名やその読み仮名に関する原告CDDBの不統一の表記や誤りと,同じ不統一の表記や誤りが,被告CDDB(当初版・2006年版)にも存在する。
原告CDDBは,株式会社や有限会社といった法人の種別について,施設名とそのカナについて,不統一な表記を行っている。
原告CDDBの以下の八つのパターンのデータと同じデータが,被告CDDB(当初版・2006年版)に多数存在する。〔甲65の別紙18〕
・施設名を株式会社とし,カナをサブシキカイシャと誤って表記する
・施設名を(株)とし,カナをカブと表記する
・施設名を(株)や(有)とし,カナを(カブ),(ユウ)と表記する
・施設名を(株)や(有)とし,カナを(カ),(ユ)と表記する
・施設名を(株)とし,カナをカブシキガイシャと表記する
・施設名を株式会社とし,カナをカブシキガイシャやカブシキカイシャと表記する
・施設名を(株)や株式会社とし,カナではそれらを表記しない
・例外的にカナを「カブシキカイシャ」(通常は「カブシキガイシャ」)と表記する
(d) 観光施設名の読み仮名表記に原告CDDBと同じ誤り(「ひらがなが混じる」,「漢字が混じる」,「英字が混じり読みも誤る」,「記号「^」が混じり読みも誤る」など)が被告CDDB(当初版・2006年版)に多数存在する。
以下はその例であるが,その他にも事例がある。〔甲65の別紙19〕
・施設名:光大寺の湯
施設カナ:コウダイジのユ
・施設名:霞間ヶ渓スポーツ公園
施設カナ:カマガタニスポ-ツ公園
・施設名:航空博物館
施設カナ:コウクウガクブツアkン
・施設名:スパガーデンコートピア
施設カナ:スパガ-デンコ^-トピア
(e) 原告CDDBでは,施設について旧名称と現行名称と重複して登録する例があるが,被告CDDB(当初版・2006年版)でも同一の重複登録がある。
以下の例は,被告CDDB(当初版・2006年版)のデータベース開発時期(2005(平成17)年10月以降)からすると格納されるはずのない古い施設名称が重複して登録されている。
下記の「大分阿蘇レーシングパーク」は,1993年から1995年のみ使用され,その後,名称を「オートポリス」に変更した。
このような例につき,原告CDDBと同じ重複登録があり,被告CDDB(当初版・2006年版)の開発時より10年前の旧施設名称が登録されている。
原告CDDB
ⅰ 施設No.50447,施設名:大分阿蘇レーシングパーク
ⅱ 施設No.75327,施設名:オートポリス
被告CDDB(当初版・2006年版)
ⅰ 施設No.142041,施設名:大分阿蘇レーシングパーク
ⅱ 施設No.142055,施設名:オートポリス
ⅰは,被告CDDB(新版)では「オートポリス」に改変されている。また,ⅱは,被告CDDB(新版)では削除されている。
(f) 原告CDDBにおいて,2005年当時登録されていた下記平成17年(2005年)のイベントのデータが,被告CDDB(当初版・2006年版),被告CDDB(現行版)においても,一致して存在している。
被告CDDB(当初版・2006年版)のデータベース開発時期(平成17年(2005年)10月以降)及び販売時期(平成18年(2006年)6月)からすると,これらデータは格納されるはずのないものである。
イベント:アイランド花どんたく[★開催期間:2005年9月9日~11月20日]
i 協定施設テーブル,券種テーブル,協定旅館テーブル,連結協定テーブルについて
原告CDDBにおいては,別紙1の前記各テーブルについての原告CDDBの各テーブルの概要欄記載のとおり,主に大手旅行会社など個別の顧客向けに用意していたテーブルである,協定施設テーブル,券種テーブル,協定旅館テーブル,連結協定テーブルについて,同じテーブルID(ただし,頭文字3文字を除く)で被告CDDB(当初版・2006年版)に存在する。しかも,この被告CDDBのテーブルには,別紙4のとおり,データは全く格納されておらず,不要なテーブルであるということができる。被告CDDB(現行版)以降は,それらのテーブル自体が削除されている。
j 駅テーブルについて
駅名の読み仮名に関して,原告CDDBと同じ誤りが被告CDDB(当初版・2006年版)に存在する。なお,被告らは,駅番号を被告CDDB(現行版)より再度振り直した。
・施設名:別府[◆市営地下鉄]
施設カナ:ベップ(正しくは「ベフ」)
被告CDDB(現行版)の一部(2011年2・3月版 Ver3.1 まで),被告CDDB(新版)からは,上記につき,「ベフ」に改変した。〔甲65の別紙25〕
K 会社テーブルについて
被告CDDB(当初版・2006年版)では,交通機関の会社を検索条件としておらず,その存在の必要性が認められないところ,被告CDDB(当初版・2006年版)には「42会社マスタ」を設けており,しかも別紙4のとおり,そのテーブル(AZMJKF)にはデータが全く入っておらず,不要なテーブルであるにもかかわらず,原告CDDBと同じテーブルが設けられている。
l 地方別会社索引テーブルについて
同テーブルは,被告CDDB(当初版・2006年版)においては「駅すぱあと」との連動により必要ないテーブルであるところ,原告CDDBと同じテーブルが存在する。そのテーブル(AZMJKJ)には,別紙4のとおり,データが全く入っておらず,不要なテーブルである。
m メッセージテーブルについて
被告CDDB(当初版・2006年版)の「メッセージマスタ」テーブル(テーブルID;AZMMSG)は,マスターテーブルであるが,他のテーブルとリレーションを持たず,原告システムが原告CDDBを介さず直接参照するテーブルであり,原告CDDBを構成していないとして,別紙1ないし3のマスターテーブルとしては記載がされていないものである。〔甲6別紙A-13-2,甲13,27〕
被告CDDB(当初版・2006年版)のテーブルには,原告CDDBのメッセージデータと全く同一の内容のデータが格納されており,MSGコード,MSG内容の各フィールドに格納されているデータは一致している。
メッセージ内容を具体的にどのような文章にするのか,また各メッセージに何番のコードを付与するかについては,選択の幅があるということができるところ,被告CDDB(当初版・2006年版)はこれと同じ文章を格納し,同じコード(番号)を付与している。被告CDDB(当初版・2006年版)のAZMMSGテーブルに格納されているメッセージについては,原告CDDBのTRVMSGテーブルのメッセージと完全に同一のものが97.5%の割合となっている。〔甲28の別紙12〕
n メッセージボックステーブルについて
(a) 被告CDDB(当初版・2006年版)の「メッセージボックスマスタ」テーブル(テーブルID;AZMMSGBX)もマスターテーブルであるが,他のテーブルとリレーションを持たず,原告システムが原告CDDBを介さず直接参照するテーブルであり,原告CDDBを構成していないとして,別紙1ないし3のマスターテーブルとしては記載がされていないものである。〔甲13,27〕
被告CDDB(当初版・2006年版)の上記テーブルには,原告CDDBと同一のデータが格納されている。すなわち,被告CDDB(当初版・2006年版)の「メッセージボックスマスタ」テーブルに格納されているメッセージは,原告CDDBの「メッセージボックス(テーブルID;TRVMSGBX)」テーブルのメッセージと完全に同一のものが51.9%,一部一致のものを含めると82.8%の割合で存在している。〔甲28の別紙13〕
(b) 被告CDDB(当初版・2006年版)について,被告らは,被告CDDBの2006年版では「方面」という概念を前提にしないで独自に開発したと主張し,実際,被告CDDBでは方面検索機能は存しないところ,被告CDDBの2006年版の「メッセージボックスマスタ(テーブルID;AZMMSG)」テーブルには「方面を入力して下さい。」とのメッセージが,また,同じく被告CDDBの2006年版の「メッセージボックスマスタ(テーブルID;AZMMSGBX」テーブルには,「入力エラー:方面」,「入力エラー:方面名」とのエラーメッセージが格納されている。
これらは,被告CDDBを独自に開発したとの被告らの主張を前提とすれば,不要なメッセージということができる。
o ランドマークテーブル,ランドマーク種別テーブルについて
ランドマークテーブル,ランドマーク種別テーブルも,マスターテーブルであり,原告システムの開発途上で作成されていたが,結局利用の予定がないことから未完成のまま残っており,原告システムにおいて参照されることがなく,原告CDDBを構成していないとして,別紙1ないし3のマスターテーブルとしては記載がされていないものである。被告CDDB(当初版・2006年版)においても別紙4のとおりデータは全く格納されておらず,不要であるにもかかわらず,これらのテーブルが存在する。
その後,被告CDDB(現行版),被告CDDB(新版)ではこれらのテーブル自体が削除されている。
(イ) 上記(ア)の事実によれば,被告CDDB(当初版・2006年版)が,原告CDDBに依拠して作成されたことは明らかであるということができる。
なお,この点に関して被告らは,被告CDDB(当初版・2006年版)のフィールドIDと,原告CDDBのフィールドIDとの間に一致している部分があることは認めるが,例えば,被告CDDB(当初版・2006年版)の市区町村マスタにおける都道府県コードのフィールドID「CIPRCD」は,
・「CITY」を省略した「CI」を先頭2文字(全フィールド同様)
・「PR」は,県を意味する(Prefecture)を省略したもの
・「CD」は,コード(Code)を省略したもの
との命名ルールに則って付けられており,このようなフィールドIDは,様々なシステムで用いられている一般的な命名規則であり,原告CDDBだけに使用される特殊な命名ルールではなく,被告アゼスタは,被告CDDBについても同様の命名ルールでフィールドIDを定義したにすぎない旨主張する。
しかし,上記が一般的な命名規則であることについて,これを裏付ける的確な証拠はなく,被告らは,上記以外のフィールドIDが一致するものについて何ら説明をしていないばかりか,その余の多数の一致するフィールドについても,一般的な命名規則から説明が付くものがほとんどであると認めるに足りない。
したがって,被告らの上記主張は採用することができない。
キ 被告CDDB(当初版・2006年版)についての結論
以上の検討によれば,被告CDDB(当初版・2006年版)は,原告CDDBに依拠して制作された複製物であると認めるのが相当である。
(4)  次に,被告CDDB(現行版)につき検討する。
ア 被告CDDB(現行版)と原告CDDBとの体系的構成の共通性
(ア) テーブルの種類及び数
a 一致するマスターテーブル
(a) 原告CDDBには42個の,被告CDDB(現行版)には26個のマスターテーブルがそれぞれ含まれるところ,このうち,以下の10個のマスターテーブルについては,原告CDDBに含まれるマスターテーブルと一致することにつき争いがない。
一致することに争いのない10個のマスターテーブルは,以下のとおりである(原告CDDBのマスターテーブルによる表記。対応する被告CDDB(現行版)の表記は別紙2該当欄記載のとおり)。
・「01市区町村テーブル」
・「05緯度経度テーブル」
・「06URLアドレステーブル」
・「07URL種別テーブル」
・「08URL分類テーブル」
・「09地点名テーブル」
・「10道路テーブル」
・「32駅テーブル」
・「42会社テーブル」
・「43交通機関種別テーブル」
(b) そして,原告は,「20ホテル・旅館テーブル」,「21観光施設テーブル」及び「22観光施設備考テーブル」についても,これら三つのテーブルに対応する,被告CDDB(現行版)の「21施設マスタ」,「29宿泊施設マスタ」,「23観光施設マスタ」,「26観光料金マスタ」及び「25観光料金種別マスタ」は,一致するマスターテーブルである旨主張し,さらに,「02地区・県名テーブル」は「3都道府県マスタ」と,「11接続テーブル」は「37単経路マスタ」と,「12禁止乗換テーブル」は「37禁止経路マスタ」と,「14区間料金テーブル」は「39区間料金マスタ」と,「15首都高速料金テーブル」は「40通行料金マスタ」と,「33路線構成テーブル」は「46路線構成マスタ」と,「34路線テーブル」は「43路線マスタ」と,「36路線検索テーブル」は「45時刻マスタ」と,「39便テーブル」及び「40運行日定義テーブル」は「44便マスタ」と,それぞれ対応して被告CDDB(現行版)に存在する旨主張する。
まず,被告CDDB(現行版)の「3都道府県マスタ」と原告CDDB「02地区・県名テーブル」とは,いずれもプライマリー・キーが設定された「都道府県コード」,及び「都道府県名」フィールドから構成されていること,被告CDDB(現行版)のフィールドには「表示順」のフィールドが存するものの,これは検索結果における表示順を定めるものであるところ,これは,都道府県コードに基づき表示順を決定するにすぎないものと認められ,その余の被告CDDB(現行版)のフィールドも,「作成日時」,「更新日時」,「削除区分」,「都道府県名英字」等のフィールドであることから,被告CDDB(現行版)の「3都道府県マスタ」と原告CDDB「02地区・県名テーブル」とは同じ目的で使用されるものであり,実質的に一致するものと認められる。
次に,被告CDDB(現行版)の「37単経路マスタ」,「38禁止経路マスタ」,「39区間料金マスタ」及び「40通行料金マスタ」と原告CDDBの「11接続テーブル」,「12禁止乗換テーブル」,「14区間料金テーブル」及び「15首都高速料金テーブル」とは,別紙3のとおりの各テーブルにおけるフィールドの存在,別紙6のとおりの原告CDDBのリレーション,別紙9のとおり認められる(争いがあるリレーションについての判断は後記のとおりである。)被告CDDB(現行版)のリレーションのとり方を参照すると,どちらも地点コード(地点番号)により特定される道路の始点・終点と禁止ルートを特定し,有料道路の場合に料金を検索するためのものと認められる。フィールドの内容を詳細にみると若干相違する点はあるものの,検索の目的の観点からすると,それらのリレーションに特徴があるものとは認められず,両者は同じ目的で使用されるものであり,実質的に一致するものと認められる。なお,この点についての判断の詳細は,下記オ(被告らの主張に対する判断)のとおりである。
被告CDDB(現行版)の「21施設マスタ」,「29宿泊施設マスタ」,「23観光施設マスタ」,「26観光料金マスタ」については,被告CDDB(当初版・2006年版)と比較して,別紙3のとおり,フラグフィールド等の削除や,「21施設マスタ」に「キーワード」,「公共施設種別」等のフィールドを加えるなど,フィールドに若干の変更はあるものの,被告CDDB(当初版・2006年版)の主要なフィールドには変更がなく,全体的に重要な変更がされているものとはいえないから,被告CDDB(当初版・2006年版)と同様,被告CDDB(現行版)の「21施設マスタ」,「29宿泊施設マスタ」,「23観光施設マスタ」,「26観光料金マスタ」についても,原告CDDBの対応するテーブルと実質一致するものと認められる。なお,被告CDDB(現行版)の「25観光料金種別マスタ」は原告CDDBに対応するテーブルがないことは前記と同様である。
被告CDDB(現行版)の「46路線構成マスタ」,「43路線マスタ」,「45時刻マスタ」及び「44便マスタ」と原告CDDBの「33路線構成テーブル」,「34路線テーブル」,「36路線検索テーブル」,「39便テーブル」及び「40運行日定義テーブル」とは,別紙3のとおりの各テーブルにおけるフィールドの存在,別紙6のとおりの原告CDDBのリレーション,別紙9のとおり認められる被告CDDB(現行版)のリレーションのとり方を参照すると,これらは,道路を移動するものを除く鉄道等の公共輸送サービスを利用した場合の経路探索及び料金の検索をするためのものであるところ,原告CDDBの「33路線構成テーブル」,「34路線テーブル」,「39便テーブル」及び「40運行日定義テーブル」に存在する「路線番号」フィールドにいずれもプライマリー・キーが設定されているところ,被告CDDB(現行版)の「46路線構成マスタ」,「43路線マスタ」及び「44便マスタ」の「路線コード」フィールドにも,いずれもプライマリー・キーが設定されており,その他各テーブルに存するフィールドについても,「備考」や「作成日時」等のフィールドを除くとほとんど共通するものであること,検索の目的の観点でみると,リレーションに特徴があるものともみられないことから,被告CDDB(現行版)の「46路線構成マスタ」,「43路線マスタ」,「45時刻マスタ」及び「44便マスタ」と,原告CDDBの「33路線構成テーブル」,「34路線テーブル」,「36路線検索テーブル」,「39便テーブル」及び「40運行日定義テーブル」とは,同じ目的で使用されるものと認められ,一致するものと認められる。なお,被告CDDB「44便マスタ」は,別紙3のとおりの各フィールドの内容の共通性からみて,原告CDDBの「39便テーブル」,「40運行日定義テーブル」及び「41時刻テーブル」を実質的には正規化した関係にすぎないものであるから,これも一致するものと認められる。
(c) 上記によれば,原告CDDBと被告CDDB(現行版)とで一致するマスターテーブルは,上記23個であると認められる。
b 一致しないマスターテーブル
前記のとおり,被告CDDB(現行版)の「25観光料金種別マスタ」は,原告CDDBに対応するマスターテーブルが存在しない。
その他,原告CDDBのマスターテーブルのうち,「03方面テーブル」及び「04方面設定テーブル」については,被告システムでは,方面検索の機能がないため,対応するテーブルが存在しない。
また,原告CDDBのマスターテーブルのうち,「16道路構成地点テーブル」,「17道路構成地点索引テーブル」,「18市区町村通過道路索引テーブル」,「19県範囲定義テーブル」,「28協定施設テーブル」,「29券種テーブル」,「30協定旅館テーブル」,「31連結協定テーブル」,「35時刻表料金テーブル」,「37路線検索索引テーブル」,「38路線タイプテーブル」,「41時刻テーブル」,「44地方別会社索引テーブル」,「45検索地方範囲定義テーブル」,「46地方別路線索引テーブル」及び「47駅通過線索引テーブル」についても,被告CDDB(現行版)に対応するマスターテーブルが存在しない。
「45検索地方範囲定義テーブル」については,上記被告CDDB(当初版・2006年版)記載のとおりである。
(イ) 被告CDDB(現行版)の各テーブルに存在するフィールドの種類及び数原告CDDBには42個のテーブルに,405個のフィールドが存するところ,被告CDDB(現行版)の26個のテーブルには別紙3記載のとおり,総数256個のフィールドが存する。
前記のとおり原告CDDBのマスターテーブルと一致する被告CDDB(現行版)のテーブルにおけるフィールド項目については,別紙3記載のとおり,一致するテーブルに存するフィールドは245個である(なお,被告CDDB(現行版)のフィールドのうち,「21施設マスタ」テーブルの「キーワード」フィールド,「公共種別」フィールドは,いずれも被告CDDB(現行版)の Ver2.84 以降のものに加えられたフィールドであるところ,別紙3のフィールド数の計算(カウント)にはこれも含めている。また,被告CDDB(現行版)のうち,「3都道府県マスタ」の「都道府県名英字」フィールドは,被告CDDB(現行版)の Ver2.90 以降のものに加えられたフィールドであるところ,別紙3のフィールド数の計算(カウント)にはこれも含めている。)。
フィールドのうち,「作成日時」,「更新日時」及び「削除区分」のフィールドは,データ更新やテーブル管理を行うための管理項目であり,データベースの検索機能や提供データの内容自体に影響を及ぼす性質のものではない。〔甲3,7頁〕このうち,被告CDDB(現行版)における,ほぼ各テーブル(マスタ)に存在する「登録日時(作成日時)」,「更新日時(更新日時)」及び「削除区分(削除区分)」のフィールドを除くと,原告CDDBと被告CDDB(現行版)とで一致するフィールド数は173個となるところ,別紙3のとおり,このうちの143個が,原告CDDBと一致している。
(ウ) テーブル間の関連付け
原告CDDBのマスターテーブルと一致する23個のテーブルに関しては,プライマリー・キーの設定も含め,原告CDDBに存在する関連付けのほぼ全てについて,同様の関連付け(リレーション)が被告CDDBに存在する。その内容は,別紙6,9のとおりである(別紙9で青丸と青丸とを結ぶ黒線〔黒太線を含む〕及び黒点線で記載されたリレーションが,当裁判所がその存在を認めるリレーションである。)。
別紙3のとおり,原告CDDBと被告CDDB(現行版)とでは,原告CDDBのマスターテーブルと一致する23個のテーブルに関して,プライマリー・キーの設定につき,原告CDDBの「02地区・県名テーブル」の「地区コード」フィールド,原告CDDBの「11接続テーブル」の「接続番号」フィールド(被告CDDB(現行版)では,「37単経路マスタ」の「地点コード(始点)(地点番号_始点)」,「地点コード(終点)(地点番号終点)」及び「道路コード(道路番号)」の三つのフィールドにプライマリー・キーが設定されている。),原告CDDBの「12禁止乗換テーブル」の「乗換元接続番号」フィールド(被告CDDB(現行版)では,「38禁止経路マスタ」の「地点コード(始点)(地点番号_始点)」,「道路コード(道路番号)」,「地点コード(中間点)(地点番号_中間)」,「地点コード(終点)(地点番号_終点)」及び「通行禁止道路コード(道路番号禁止)」の五つのフィールドにプライマリー・キーが設定されている。),被告CDDB(現行版)の「39区間料金マスタ」及び「40通行料金マスタ」の各「道路料金区分(道路料金区分)」フィールドを除き,一致したフィールドないし同一のテーブルの同種フィールドにプライマリー・キーが設定され,これらに基づき,上記のとおりのリレーションがとられている。
なお,この点につき,被告らは,被告CDDB(現行版)の「36道路マスタ〔テーブルID;M_DORO〕」の「道路コード」フィールドと「38禁止経路マスタ〔テーブルID;M_KINSIKEIRO〕」の「道路コード」フィールドとの間,「36道路マスタ」の「道路コード」フィールドと「38禁止経路マスタ」の「通行禁止道路コード」フィールドとの間,及び「38禁止経路マスタ」の「地点コード(始点)」,「地点コード(中間点)」,「地点コード(終点)」のそれぞれの地点コードと「35地点マスタ〔テーブルID;M_CHITEN〕」の「地点コード(始点)」,「地点コード(中間点)」,「地点コード(終点)」のそれぞれの地点コードとの間には,いずれもリレーションがあるとする一方(別紙9に赤丸と赤丸を結ぶ赤点線で記載されたリレーション),「37単経路マスタ〔テーブルID;M_TANKEIRO〕」の「地点コード(始点)」,「地点コード(終点)」,「道路コード」のそれぞれのフィールドと「38禁止経路マスタ」の「地点コード(始点)」,「地点コード(中間点)」,「地点コード(終点)」,「道路コード」,「通行禁止道路コード」との間のリレーションを否認する(別紙9に青丸と青丸を結ぶ黒点線で記載されたリレーション)ので,以下,検討する。
まず,「38禁止経路マスタ」と「37単経路マスタ」との間にリレーションが存在しないとする被告の主張については,被告システムに用いられているSQLサーバーを管理するツールであるSQL Server Profiterを用いた解析結果によれば,被告CDDB(現行版)において,「38禁止経路マスタ」と「37単経路マスタ」とにリレーションがあることが認められるから,これと各テーブルのフィールドの内容からすれば,上記「37単経路マスタ」の「地点コード(始点)」,「地点コード(終点)」,「道路コード」のそれぞれのフィールドと「38禁止経路マスタ」の「地点コード(始点)」,「地点コード(中間点)」,「地点コード(終点)」,「道路コード」,「通行禁止道路コード」との間にリレーションがあることが認められる。詳細は後記オのとおりである。〔甲58〕
次に,「36道路マスタ」の「道路コード」フィールドと「38禁止経路マスタ」の「道路コード」フィールドとの間,「36道路マスタ」の「道路コード」フィールドと「38禁止経路マスタ」の「通行禁止道路コード」フィールドとの間,及び「38禁止経路マスタ」の「地点コード(始点)」,「地点コード(中間点)」,「地点コード(終点)」のそれぞれの地点コードのフィールドと「35地点マスタ」の「地点コード」フィールドとの間には,いずれもリレーションがあるとする点につき,被告らは,禁止経路は,あくまでも地点の組み合わせによりデータを取得していて単経路の組み合わせとはなっていないために,禁止経路マスタと単経路マスタは,一方が他方を包含する関係にあるから,リレーションがある旨を主張するが,包含関係があるか否かによりリレーションの有無が判断されるものとは認められない。なお,この点についての詳細は後記オのとおりである。
また,前記のとおり,被告CDDB(現行版)では,原告CDDBの「20ホテル・旅館テーブル」,「21観光施設テーブル」及び「22観光施設備考テーブル」の3テーブルに対応するテーブルとして,「21施設マスタ」,「29宿泊施設マスタ」,「23観光施設マスタ」及び「26観光料金マスタ」の4テーブルを設けているところ,原告CDDBにおける「01市区町村テーブル」が「20ホテル・旅館テーブル」,「21観光施設テーブル」の二つのテーブルとリレーションをとっていることに対して,被告CDDB(現行版)の「4市区町村マスタ」は,原告CDDBの「20ホテル・旅館テーブル」及び「21観光施設テーブル」の共通項目を括りだした上位のテーブルとなっている被告CDDB(現行版)の「21施設マスタ」の一つのテーブルとのみリレーションをとっており,これにより,これと関連するリレーションの線がその分少なくなっているが,この点については,被告CDDB(当初版・2006年版)についてと同様である。
イ 被告CDDB(現行版)の体系的構成が,原告CDDBの複製又は翻案に当たるか
(ア) 前記のとおり,原告CDDBと被告CDDB(現行版)とでは,原告CDDBにおける,「01市区町村テーブル」,「02地区・県名テーブル」,「05緯度経度テーブル」,「06URLアドレステーブル」,「07URL種別テーブル」,「08URL分類テーブル」,「09地点名テーブル」,「10道路テーブル」,「11接続テーブル」,「12禁止乗換テーブル」,「14区間料金テーブル」,「15首都高速料金テーブル」,「20ホテル・旅館テーブル」,「21観光施設テーブル」,「22観光施設備考テーブル」,「32駅テーブル」,「33路線構成テーブル」,「34路線テーブル」,「36路線検索テーブル」,「39便テーブル」,「40運行日定義テーブル」,「42会社テーブル」,「43交通機関種別テーブル」の23個のテーブルにつき,これと一致するテーブルが被告CDDB(現行版)には存する。
原告CDDBと被告CDDB(現行版)とで一致するテーブルに存するフィールドも,143個にのぼる。
さらに,テーブル間の関連付けについてみると,原告CDDBと被告CDDB(現行版)とでは,別紙6,9のとおり,同様のリレーションが存する。
(イ) そして,原告CDDBは,それまで存しなかった団体旅行の行程表作成のため,顧客である旅行業者等からのヒアリングに基づき,出発地,到着地,交通手段,経由地である観光施設,宿泊施設をデータベース化してこれをコンピュータで効率よく検索できるようにするためのデータベースであり,この点につき,上記被告CDDB(現行版)と共通するフィールドに関してみると,原告CDDBの「01市区町村テーブル」,「32駅テーブル」,「20ホテル・施設テーブル」,「21観光施設テーブル」,「09地点名テーブル」,「11接続テーブル」及び「10道路テーブル」により,出発地,経由地,目的地に面した道路に関するデータの検索を可能にし,次に「09地点名テーブル」,「10道路テーブル」,「11接続テーブル」,「12禁止乗換テーブル」,「14区間料金テーブル」及び「15首都高速料金テーブル」により,道路を利用した移動に関する経路探索・料金の算出に必要なデータの検索を可能にしている。また,「20ホテル・旅館テーブル」,「21観光施設テーブル」,「22観光設備備考テーブル」,「05緯度経度テーブル」,「06URLアドレステーブル」,「07URL種別テーブル」及び「08URL分類テーブル」により,ホテル・旅館,観光施設に関する情報を検索することを可能にしている。そして,「01市区町村テーブル」,「02地区・県名テーブル」は,道路と地図を関連付ける情報として,地図から検索をするときに用いられている。また,「01市区町村テーブル」,「20ホテル・旅館テーブル」,「21観光施設テーブル」及び「32駅テーブル」には施設等の近辺の道路地点の情報が代表道路地区コードや代表道路地点番号として格納されており,当該市区町村内にあるこれらの施設や駅などを選ぶことを通じて出発点としての「09地点名テーブル」の道路地点を選ぶことができる。また,観光施設も「21観光施設テーブル」から選択し,絞り込みは,「02地区・県名テーブル」,「01市区町村テーブル」から行うことができる。観光名称は「21観光施設テーブル」に,検索結果の観光施設について,当該観光施設に関する様々の情報は,「22観光施設備考テーブル」に格納されており,観光施設に関するホームページの情報も「06URLアドレステーブル」,「07URL種別テーブル」から参照可能であり,最終的に行程に入れるかどうかを判断することができる。
宿泊施設については,「20ホテル・旅館テーブル」から選択し,地区は「02地区・県名テーブル」,都道府県も「02地区・県名テーブル」,市区町村は「01市区町村テーブル」,地図上の範囲設定はプロアトラスと「05緯度経度テーブル」,「20ホテル・旅館テーブル」,宿泊種別は「20ホテル・旅館テーブル」,名称は「20ホテル・旅館テーブル」,検索結果の宿泊施設については当該宿泊施設に関する様々な情報,すなわち和室,洋室の客室数,収容人員,料金,付帯施設,駐車場などが「20ホテル・旅館テーブル」に格納されていて,当該宿泊施設に関するホームページの情報も「06URLアドレステーブル」,「07URL種別テーブル」が対応し,これらを参照して顧客の判断で決定することができる。
また,「32駅テーブル」,「33路線構成テーブル」,「34路線テーブル」,「36路線検索テーブル」,「39便テーブル」,「40運行日定義テーブル」,「42会社テーブル」及び「43交通機関種別テーブル」により,公共交通機関を利用した経路探索に必要なデータの検索を可能にしている。
これら共通するテーブルについては,いずれも各テーブルを構成するフィールドにつき,原告CDDBと,被告CDDB(現行版)とでほとんどが共通し,リレーションのとり方もほぼ共通するものである。
そして,両者で共通するこれらの体系的構成は,原告CDDBの制作者において,それまでのデータベースにはなかった設計思想に基づき構成した原告CDDBの創作活動の成果であり,その共通する部分のみでデータベースとして機能し得る膨大な規模の情報分類体系であると認められ,データベースとして制作者の個性が表現されているものということができる。
したがって,被告CDDB(現行版)と共通する上記原告CDDBの部分については,データベースの体系的構成としての創作性を有するものと認めるのが相当である。
(ウ) 一方,原告CDDBと被告CDDB(現行版)とを比較すると,両者で一致しないマスターテーブルとして,被告CDDB(現行版)の「25観光料金種別マスタ」,「27観光種別マスタ」と「28観光詳細種別マスタ」があり,これらは,原告CDDBには含まれないものである。
このうち「25観光料金種別マスタ」については,そこに含まれるフィールドをみると,プライマリー・キーの設定された「観光料金種別」フィールド,「料金種別名」,「管理備考」の各フィールド(被告CDDB(当初版・2006年版)とは若干異なる。)のほかは,作成日時,区分等のフィールドであり,このうち料金種別にかかるものは,原告CDDBの「21観光施設テーブル」,「22観光施設備考テーブル」では4種類までの料金しか登録することができないところ,被告CDDB(現行版)においても,「25観光料金種別マスタ」を設けることによりそれ以上の種類の料金設定についても登録できるようにテーブルを設けることとしたことに変わりないものと認められる。〔乙20〕
しかし,前記のとおり原告CDDBでも料金種別により分類可能であったところ,これについて,料金種別を増やすためにテーブルを設けること自体は,原告CDDBに新たに創作的表現を加えたものとはいい難い。
また,「27観光種別マスタ」と「28観光詳細種別マスタ」については,前記のとおり,原告システムをユーザーのハードウェア内にインストールした際に作成される原告マスターテーブルの中に,これら二つのテーブルに対応するマスターテーブルである「23観光施設種別テーブル」及び「24観光施設検索タイトルテーブル」が存在し,被告CDDB(現行版)においては,被告CDDB(当初版・2006年版)と比べて,フィールドIDのうち原告CDDBと一致するものについて変更されているものの,フィールドの区分等についてはほとんど変更がなく,被告CDDB(現行版)において新たに加わった創作の成果ということはできないから,実質的に原告システム中に存する原告CDDBと関連する部分を,CDで提供されるデータベース中に移した関係にすぎないものと認められる。
しかも,テーブルについては,被告CDDB(当初版・2006年版)においては一致するテーブルとしては存しなかった「43路線マスタ」,「44便マスタ」,「45時刻マスタ」及び「46路線構成マスタ」も,被告CDDB(現行版)には設けられ,これら各テーブルのフィールドも,「備考」,「作成日時」等のフィールドを除き,原告CDDBのフィールドとすべて一致している。
そして,フィールドの詳細についてみても,被告CDDB(現行版)の「35地点マスタ」,「36道路マスタ」,「37単経路マスタ」及び「38禁止乗換マスタ」の各テーブルのフィールドは,上記リレーションの存在等からして,いずれも「作成日時」,「更新日時」及び「削除区分」フィールドを除き,原告CDDBの「09地点名テーブル」,「10道路テーブル」,「11接続テーブル」及び「12禁止乗換テーブル」の各テーブルのフィールドと一致するものと認められる。
また,原告CDDBと一致するテーブルである,「39区間料金マスタ」,「40通行料金マスタ」テーブルには,いずれも「道路料金区分」のフィールドが設けられているが,「39区間料金マスタ」,「40首都高速料金マスタ」テーブルには,いずれも原告CDDBと一致するフィールドであった被告CDDB(当初版・2006年版)の「39料金マスタ」,「40通行料金マスタ」テーブルの「普通車料金」,「中型車料金」,「大型車料金」,「特大車料金」の各フィールドにつき,原告CDDBにおいて,もともと区分されていた料金につき,その区分のフィールドを独立して設けたものにすぎない。また,「21施設マスタ」テーブルの「温泉地コード」フィールド,「26観光料金マスタ」の「料金種別コード」フィールド,「29旅館マスタ基本」テーブルの「シングル数」フィールド等についても,もともと種別自体は設けられていたものを細分化したにすぎないものであって,これらについては,いずれも体系的構成として独自の創作性は認められないものである。
さらに,リレーションの取り方についてみても,原告CDDBと被告CDDB(現行版)とで異なるリレーションとなっている,被告CDDB(現行版)においても,「4市区町村マスタ」は,施設に関し「21施設マスタ」とのみリレーションを取っていることから,原告CDDBにおける「01市区町村テーブル」が「20ホテル・旅館テーブル」,「21観光施設テーブル」の二つのテーブルとリレーションを取っていることに対して,リレーションが少なくなっているところ,既に検討したとおり,被告CDDB(現行版)の「21施設マスタ」及びこれと関連する,「29宿泊施設マスタ」,「23観光施設マスタ」テーブルについては,原告CDDBの「20ホテル・旅館テーブル」,「21観光施設テーブル」とは実質的に一致するテーブルであると認められることや,別紙9のとおり認められる被告CDDB(現行版)の「4市区町村マスタ」,「31URLマスタ」,「34緯度経度マスタ」テーブル等と,「21施設マスタ」,「29宿泊施設マスタ」,「23観光施設マスタ」テーブル等,及び「21施設マスタ」テーブルと,「29宿泊施設マスタ」,「23観光施設マスタ」テーブルとのリレーションのとり方等からすると,被告CDDB(現行版)とのリレーションのとり方は,原告CDDBのリレーションのとり方に新たな創作性を加えるものは認められない。
(エ) そうすると,これら被告CDDB(現行版)が原告CDDBと共通性を有する部分は,原告CDDBの創作的表現の本質的特徴の同一性が維持されており,これを直接感得することができるものというべきであり,一方,被告CDDB(現行版)において変更が加えられた部分は,いずれも創作性を有しない部分であるということができる。
ウ 被告CDDB(現行版)と原告CDDBとの情報の選択の共通性
(ア) フィールド項目の選択の類似性
前記のとおり,テーブル管理のためのフィールドである「登録日時」,「更新日時」及び「削除区分」等のフィールドを除いた被告CDDB(現行版)のフィールド数173個のうち143個が原告CDDBのフィールドと一致している。
(イ) レコードの選択の類似性
被告らは,被告CDDB(当初版・2006年版)において,原告CDDBのテーブルのうち,以下の20個のテーブルに含まれるレコードをコピーして用いたことを認めていた。
そのテーブルとは,「20ホテル・旅館テーブル」,「21観光施設テーブル」,「05緯度経度テーブル」,「06URLアドレステーブル」,「07URL種別テーブル」,「08URL分類テーブル」,「01市区町村テーブル」,「02地区・県名テーブル」,「09地点名テーブル」,「10道路テーブル」,「11接続テーブル」,「12禁止乗換テーブル」,「13有料道路番号テーブル」,「14区間料金テーブル」,「15首都高速料金テーブル」,「16道路構成地点テーブル」,「17道路構成地点索引テーブル」,「18市区町村通過道路索引テーブル」,「19県範囲定義テーブル」及び「32駅テーブル」である。
このうち,被告らは,被告CDDB(当初版・2006年版)において存在した,原告CDDBの「13有料道路番号テーブル」,「16道路構成地点テーブル」,「17道路構成地点索引テーブル」,「18市区町村通過道路索引テーブル」及び「19県範囲定義テーブル」の五つのテーブルと対応するテーブルについては,被告CDDB(現行版)においては削除したとしている。
また,被告らは,被告CDDB(現行版)において,原告CDDBの「07URL種別テーブル」,「08URL分類テーブル」に対応する「32URL種別マスタ」,「33URL見出しマスタ(被告CDDB(現行版)ではURL分類マスタ)」の二つのテーブルについては,テーブル及びそれらに存する合計11個のフィールドはいずれも維持するものの,レコード数はいずれもゼロであるとする。
原告CDDBの「05緯度経度テーブル」に対応する「34緯度経度マスタ」については,別紙3のとおり,被告CDDB(当初版・2006年版)の四つのフィールドにおいては,いずれも原告CDDBの対応するフィールドとフィールドIDが完全に一致していたところ,被告CDDB(現行版)においては,フィールドIDを改め,新たに「作成日時」,「更新日時」及び「削除区分」の三つのフィールドを設けるほか,別紙4のとおり,公共施設につき7万件余りのレコードを追加し,総レコード数を18万余とした。対応する原告CDDBのレコード数は11万余件である。
原告CDDBの「20ホテル・旅館テーブル」,「21観光施設テーブル」についても,被告CDDB(当初版・2006年版)と原告CDDBの対応するフィールドとフィールドIDが完全に一致していたものについては,被告CDDB(現行版)においては,フィールドIDを改め,フラグ,日付等に関するフィールドについて,一部削除を行うなどしたほかは,基本的に被告CDDB(当初版・2006年版)のフィールドを維持し,レコードに関し,新設ホテル,施設等の追加や削除等を行った。
原告CDDBの「09地点名テーブル」と対応する「35地点マスタ」については,被告CDDB(当初版・2006年版)においては,フィールド数,フィールドIDが原告CDDBと完全に一致していたところ,被告CDDB(現行版)においては,フィールドIDを改めるとともに,「作成日時」,「更新日時」及び「削除区分」の三つのフィールドを新設するほか,道路データの追加等に伴い,レコードを追加・更新した。
原告CDDBの「10道路テーブル」と対応する被告CDDB(現行版)の「36道路マスタ」については,被告CDDB(当初版・2006年版)の「36道路名マスタ」においては,フィールド数,フィールドIDが原告CDDBと完全に一致していたところ,被告CDDB(現行版)においては,フィールドIDを改めるとともに,「作成日時」,「更新日時」及び「削除区分」の三つのフィールドを新設するほか,道路データを追加・更新した。
被告CDDB(当初版・2006年版)の「37接続マスタ」については,原告CDDBの「11接続テーブル」のデータをコピーして利用したことを被告らは認めており,被告CDDB(当初版・2006年版)の同テーブルの各フィールドIDは,被告CDDB(当初版・2006年版)で付加された「連番」フィールドを除き,その余の9個のフィールドにつき,いずれも原告CDDBのフィールドIDに「RDC」を頭に付加した以外は同一であるところ,被告CDDB(現行版)ではこれらIDを改めるとともに,フィールドを五つとして被告CDDB(当初版・2006年版)からの正規化を行うとともに,「作成日時」,「更新日時」及び「削除区分」の三つのフィールドを新設するほか,「地点コード(始点)」,「地点コード(終点)」,「道路コード」の三つにプライマリー・キーを設定した。また,道路データを充実させたことに伴う追加,更新等をレコードに関して行った。
被告CDDB(当初版・2006年版)の「38禁止乗換マスタ」については,原告CDDBの「12禁止乗換テーブル」のデータをコピーして利用したことを被告らは認めており,被告CDDB(当初版・2006年版)の同テーブルの各フィールドIDは,いずれも原告CDDBのフィールドIDと同一であるところ,被告CDDB(現行版)ではこれらIDを改めるとともに,「作成日時」,「更新日時」及び「削除区分」の三つのフィールドを新設するほか,「地点コード(始点)」,「地点コード(終点)」,「道路コード」の三つにプライマリー・キーを設定した。また,道路データを充実させたことに伴う追加,更新等をレコードに関して行った。
原告CDDBの「14区間料金テーブル」に対応する被告CDDB(当初版・2006年版)の「39料金マスタ」については,原告CDDBのデータをコピーして利用したことを被告らは認めており,被告CDDB(当初版・2006年版)の同テーブルの各フィールドIDは,いずれも原告CDDBのフィールドIDと同一であるところ,被告CDDB(現行版)ではこれらIDを改めるとともに,「作成日時」,「更新日時」及び「削除区分」の三つのフィールドを新設するほか,「地点コード(始点)」,「地点コード(終点)」,「道路料金区分」の三つにプライマリー・キーを設定した。また,高速道路の料金改定,区間延長等に対応してレコードを追加し,このテーブルのレコードだけで170万件余りとなり,全レコードの66%以上を占めている。
原告CDDBの「15首都高速料金テーブル」に対応する被告CDDB(当初版・2006年版)の「40首都高速料金マスタ」については,原告CDDBのデータをコピーして利用したことを被告らは認めており,被告CDDB(当初版・2006年版)の同テーブルの各フィールドIDは,いずれも原告CDDBのフィールドIDと同一であるところ,被告CDDB(現行版)ではこれらIDを改めるとともに,「作成日時」,「更新日時」,「削除区分」の三つのフィールドを新設するほか,「道路コード」,「道路料金区分」の二つにプライマリー・キーを設定した。また,有料道路料金の無料化,料金改定等に対応してレコードの追加,更新等を行った。
原告CDDBの「32駅テーブル」に対応する「47駅マスタ」では,被告CDDB(当初版・2006年版)に存した「駅番号(ヴァル研)〔フィールドID;JKBVALND〕」,「JR駅名コード〔フィールドID;JKBJRNO〕」の二つのフィールドを削除した。なお,これらフィールドIDは,いずれも原告CDDBの対応するフィールドのIDと同一である。
(ウ) 具体的な情報の同一ないし類似性
a 地点名テーブルの道路情報
原告CDDB(2006年11月版)の「09地点名テーブル」には,1万2822件のレコードが収録され,被告CDDB(現行版)では,バージョンにより異なるものの,2007年9月版の Ver2.53の「35地点マスタ」には,そのうちの99.5%である1万2762件につき,一致する道路地点(前記同様,「関JCT(伊勢自動車道・名阪国道)」,「芸濃IC(伊勢自動車道,県道10号)」等)のレコードが収録されている。〔甲32〕
b 緯度経度情報の一致
そして,原告CDDBの「09地点名テーブル」の道路地点の緯度経度情報は,前記のとおり,原告CDDB作成時に,作成者自身がパソコンのマウスを地図上でクリックする方法で選択した場所について,これを0.1秒単位で緯度経度を測定して数値化したものであり,被告CDDB(現行版のうち,2007年9月版の Ver2.53)においても,6ないし7桁の数値で緯度経度情報を収録しているところ,上記道路地点のうち,この6ないし7桁で表される緯度及び経度情報につき,原告CDDB(2006年11月版)との完全一致率は96.6%であり,1万2392件の一致するレコードが収録されている。〔甲22,28,32,39,70〕
c 選択道路の一致
原告CDDBは,前記のとおり,大型観光バスでの移動に適した道路の選択を行っており,多くの道道,県道等の中から北海道では80道道,福岡県では47県道を選択しているところ,被告CDDB(現行版のうち,2007年5月版の Ver2.0)では,北海道では,全データ83件のうち,全く同じ80道道を,福岡県ではこれと一致する県道のうち41県道を選択して格納している。〔甲48〕
d その他の情報の一致
(a) 緯度経度情報について
原告CDDBでは,新バージョンに移行しない顧客のために「01市区町村テーブル」,「09地点名テーブル」,「20ホテル・旅館テーブル」,「21観光施設テーブル」,「32駅テーブル」と緯度経度テーブルとで緯度経度情報を重複保有している。被告CDDB(現行版)でも同様に重複保有している。
(b) 地点名テーブルについて
原告CDDBと同じ誤りが被告CDDB(現行版)にも存在する(被告CDDB(当初版・2006年版)の該当箇所で記載した「阿武隅」。正しくは「阿武隈」。)。
(c) 道路テーブルについて
ⅰ 原告CDDBと同じ誤りが被告CDDB(現行版)にも存在する。
すなわち,被告CDDB(当初版・2006年版)の例で挙げた,道路番号原告CDDB462(AZ634)の道路名「金精道路」の読みの誤り(誤りは「キンセイドウロ」,正しくは「コンセイドウロ」)が,被告CDDB(現行版)にも存する。
ⅱ 原告CDDBと同じ誤りが被告CDDB(現行版)にも存在する。
被告CDDB(当初版・2006年版)の該当箇所でも記載したとおり,原告CDDBは茨城県の読み仮名を,「イバラキケン」(正)と「イバラギケン」(誤)を混在して登録している。〔甲65の別紙5〕
ⅲ 被告CDDB(当初版・2006年版)の該当箇所でも記載したとおり,ダミーデータ「***」(道路名),「ン ダミー」(道路名の読み)の一致が,被告CDDB(現行版)においても認められる。〔甲21〕
(d) 首都高速料金テーブルについて
原告CDDBと同じ誤りが被告CDDB(現行版)にも存在する。具体的には,前記(3)カ(ア)f記載のとおりである。
被告らは,原告から,2010年9月22日付け第6準備書面で,「蔵王ハイライン」の誤った料金データ一致がデッドコピーであるとの指摘を受け,その後の2010年12月・2011年1月版のVer2.99からはこれを修正した。〔甲65の別紙7〕
(e) ホテル・旅館テーブルについて
ⅰ 宿泊施設の読み仮名に関して,原告CDDBと同じ誤りが被告CDDB(現行版)にも存在する。被告CDDB(当初版・2006年版)の該当箇所でも記載したとおり,原告CDDBでは宿泊施設名の読み仮名について長音符「ー」とすべきを誤って数字記号マイナス「-」で登録した場合が相当あるが,これらと同じ誤りが被告CDDB(現行版)にも存在する。具体的には,前記(3)カ(ア)g(a)記載のとおりである。
ⅱ 宿泊施設名の読み仮名に関して,原告CDDBと同じ誤り(施設カナ)が被告CDDB(現行版)に存在する。これらについては,被告CDDB(当初版・2006年版)と同じ誤りが,全て被告CDDB(現行版)にも存する。具体的には,前記(3)カ(ア)g(b)記載のとおりである。
(f) 観光施設テーブルについて
ⅰ 観光施設名の読み仮名に関して,原告CDDBと同じ誤りが被告CDDB(現行版)にも存在する。
被告CDDB(当初版・2006年版)の該当箇所でも記載したとおり,原告CDDBは宿泊施設名称の読み仮名を表記するフィールドを有しており,宿泊施設名に「英字」「数字」を含む場合に「英字」「数字」についてもきちんと読み仮名で表記されているものと,読み仮名に「英字」「数字」がそのまま残っているものが混用されているところ,被告CDDB(現行版)にも原告CDDBと同じ混用状態が存在する。
被告CDDB(当初版・2006年版)と同じく,原告CDDBの施設名称「美利河I遺跡」(「I」は英字のアイ)の誤りにつき,被告CDDB(現行版)は原告CDDBと一致する誤り(英字の「I」)の登録をしている。〔甲65の別紙14〕
ⅱ 観光施設の読み仮名に関して,原告CDDBと同じ誤りが被告CDDB(現行版)に存在する。原告CDDBでは観光施設名の読み仮名について,長音符「ー」とすべきを誤って数字記号マイナス「-」で登録した場合が相当数あるところ,これらと同じ誤りが被告CDDB(現行版)に存在する。読み仮名に長音符「ー」とマイナス記号「-」が混用されている前記(3)カ(ア)h(b)記載の例のほか,被告CDDB(当初版・2006年版)と同様,そうした事例が存在する。〔甲65の別紙15〕
ⅲ 株式会社,有限会社の施設名やその読み仮名に関する原告CDDBの不統一表記や誤りと同じ不統一の表記や誤りが被告CDDB(現行版)にも存在する。
被告CDDB(当初版・2006年版)の該当箇所でも記載したとおり,原告CDDBは,株式会社や有限会社といった法人の種別について,施設名とそのカナについて不統一な表記を行っている。
原告CDDBの以下の二つのパターン(被告CDDB(当初版・2006年版)では八つ)のデータと同じデータが被告CDDB(現行版)に存する。〔甲65の別紙18〕
・施設名を株式会社とし,カナをサブシキカイシャと誤って表記する
・施設名を(株)とし,カナをカブと表記する
ⅳ 観光施設名の読み仮名表記に原告CDDBと同じ誤り(「ひらがなが混じる」,「漢字が混じる」,「英字が混じり読みも誤る」,「記号「^」が混じり読みも誤る」など)が被告CDDB(現行版)にも存在する。具体的には前記(3)カ(ア)h(d)記載の被告CDDB(当初版・2006年版)の例のほか,その他にも事例がある。〔甲65の別紙19〕
ⅴ 原告CDDBでは施設について旧名称と現行名称と重複して登録する例があるが,被告CDDB(現行版)でも同一の重複登録があり,この点については,前記(3)カ(ア)h(e)記載と同様である。
ⅵ 原告CDDBに平成17年(2005年)当時登録されていた下記の平成17年(2005年)のイベントのデータが,被告CDDB(現行版)にも引き続き存在しており,この点については,前記(3)カ(ア)h(f)記載と同様である。
(g) 駅テーブルについて
駅名の読み仮名に関して,原告CDDBと同じ誤りが被告CDDB(現行版)にも存在する(なお,2011年2・3月版 Ver3.1 以降と,被告CDDB(新版)では「ベフ」に改変されている)。〔甲65の別紙25〕
この点については,前記(3)カ(ア)j記載と同様である。
エ 被告CDDB(現行版)の情報の選択が,原告CDDBの複製又は翻案に当たるか
(ア) 前記のとおり,原告CDDBと被告CDDB(現行版)とでは,情報の選択について,地点名テーブルの道路情報,緯度経度情報の情報が,それぞれ完全に一致するか,大部分において一致している。
(イ) そして,原告CDDBにおいては,前記のとおり,旅行会社に対する実情調査等の結果を踏まえ,主たる目的として,大型観光バスによる団体旅行を主眼とした行程表作成のための便宜から,通常使用されるロードマップとは異なる観点である,貸切観光バスが通行するのに適した道路として,都道府県道については約10%,市区町村道では約0.004%程度を選択して「10道路テーブル」に格納し,道路地点として選択した地点における情報も緯度及び経度のデータとして格納することとし,これを大型観光バスが通過するのに適切と考えられる道路のうちの,行程表を作成する上で必要と考えられ適切な地点でもある,交差点,インターチェンジ,サービスエリア,パーキングエリア,観光施設,宿泊施設,駅,役所等の代表道路地点とするのに適切な地点を選別し,パソコンのマウスを地図上でクリックする方法で選択して,実際に入力したものである。
そして,施設と関係する代表道路地点の選択においては,施設が接する道路地点ではなく,当該施設の近辺の道路地点を当該施設の代表道路地点として適宜設定している。
このように,原告CDDBと被告CDDB(現行版)との共通部分である,道路,道路位置,代表道路地点等の選別・選択について,原告CDDBの制作者の創作活動の成果が表れており,その個性が表現されている。
したがって,被告CDDB(現行版)と共通する上記原告CDDBの部分については,データベースの情報の選択としての創作性を有するものと認めるのが相当である。
そして,これら被告CDDB(現行版)が原告CDDBと共通性を有する部分は,原告CDDBの創作的表現の本質的特徴を直接感得することができるものというべきである。
オ 被告らの主張に対する判断
(ア) 被告らは,被告CDDB(現行版)の「37単経路マスタ」では,接続番号のフィールドを削除して接続概念を一新しており,原告CDDBの「11接続テーブル」とは異なる旨主張する。
原告CDDBの「11接続テーブル」においては,道路地点間の接続情報である始点,終点,通行する道路の道路番号,移動に要する時間,2地点間の距離,上り下り車線の情報,接続番号などの情報等を各フィールドごとに格納しているところ,前記認定のとおり,被告CDDB(当初版・2006年版)の「37接続マスタ」では,これら原告CDDBと比較すると,「連番」のフィールドを除き,同一のフィールドが存在していた。そして,被告CDDB(現行版)の「37単経路マスタ」では,これら接続情報のうち,始点,終点,通行する道路の道路番号,移動に要する時間,2地点間の距離に関連するフィールドのみを残して,「接続番号」,「乗換禁止情報索引」,「上下区分」等,その余のフィールドを削除したものと認められる。これについては,後記のとおり,乗換禁止の情報に関して,接続番号のフィールドを使わず,これを「始点」,「中間点」,「終点」というフィールドで持つようにしたためであると認められる。
しかし,これら被告CDDB(現行版)の「37単経路マスタ」における接続番号等のフィールドの削除自体は,その体系的構成や既に選択されている情報自体に影響を及ぼすものとは認められない。
したがって,被告らの上記主張は採用することができない。
(イ) また,被告らは,被告CDDB(現行版)の「38禁止経路マスタ」は,と原告CDDBの「12禁止乗換テーブル」とは異なるものである旨主張する。
既に検討したとおり,原告CDDBの「12禁止乗換テーブル」には,一方通行などの理由により,経路として接続できない道路の情報を格納しているところ,具体的には,「11接続テーブル」で持つ「接続番号」について,ある接続番号(始点番号,終点番号,道路番号などの情報)の経路から,ある接続番号の経路に乗り換えようとした場合に禁止される接続番号の組み合わせを「12禁止乗換テーブル」に情報として格納している。
この「12禁止乗換テーブル」の「乗換元接続番号」と「乗換先接続番号」のフィールドには,乗換元と乗換先の接続番号で禁止される乗換のパターンを特定して格納しているものである。
これによると,「11接続テーブル」から各接続番号の始点,終点,道路番号がわかり,乗換を行う場合,乗換元の終点は乗換先の始点となる関係にあるので,接続された場合のルートは
乗換元の始点→(乗換元の終点=乗換先の始点)→乗換先の終点
との関係になる。〔甲23,11,12頁〕
そして,上記(乗換元の終点=乗換先の始点)は,希望するルートである,乗換元の始点から乗換先の終点から見れば,これはすなわち中間点であるということができる。別紙1の「11接続テーブル」についての「原告CDDBの各テーブルの概要」欄記載の例であれば,地点Bはまさにこの中間点である。
一方,被告CDDB(現行版)の「38禁止経路マスタ」においては,経路として接続できない,例えば一方通行であるなど,その道路の情報を「地点コード(始点)」,「地点コード(中間点)」,「道路コード」,「地点コード(終点)」,「通行禁止道路コード」の各フィールドにおいて格納している(別紙3のとおり,その余のフィールドは,作成日時等のフィールドである。)。
そうすると,被告CDDB(現行版)においては,原告CDDBの乗換元の始点が被告CDDB(現行版)の地点コード(始点)に,乗換元の終点=乗換先の始点が地点コード(中間)に,乗換先の終点が地点コード(終点)に,道路コードが通行禁止道路コードにそれぞれ対応するものであって,その違いは,乗換地点が一つ(乗換元の終点=乗換先の始点)あるのにつき,原告CDDBでは乗換元の終点,乗換先の始点と二つのフィールドとして捉えているのに対して,被告CDDB(現行版)では,中間点という一つのフィールドで捉えたところにある。
しかし,これは実質的内容には変化がなく,合理化を図る一種の正規化として行われたものにすぎず,被告CDDB(当初版・2006年版)から被告CDDB(現行版)とで体系的構成に実質的な変化をもたらすものとは認められない。
したがって,被告らの上記主張は採用することができない。
(ウ) 被告らは,被告CDDB(現行版)の「39区間料金マスタ」は,原告CDDBの「14区間料金テーブル」における料金区分の増加に対する対応において柔軟性があり,異なるものである旨主張する。
なるほど,原告CDDBの「14区間料金テーブル」には有料道路(距離制料金)における区間,車種による料金情報が格納されており,原告CDDBではそれぞれの具体的な車種料金(大型車料金,中型車料金,普通車料金など)を,それぞれフィールドとして保有していることから,新たな車種料金(例えば超小型車)が生じた場合には,フィールドを増やす必要が生じるので,車種料金のフィールドではなく,車種のフィールドを設け具体的な車種についてはデータとして管理した方が合理的といえるところ,被告CDDB(現行版)の「39区間料金マスタ」では,道路料金区分として車種を格納するフィールドを設け,具体的な車種(大型車,中型車料金,普通車料金など)を具体的なデータとすることにより,新たな車種料金が生じても,フィールドを増やさないで対応できることになる。 このように,原告CDDBの「14区間料金テーブル」と,被告CDDB(現行版)の「39区間料金マスタ」とでは,道路料金区分として車種を格納するフィールドを設けるか否かには違いがあるが,結局のところこれは,被告CDDB(当初版・2006年版)と同じ機能について正規化によるフィールドの整理を行ったにすぎないものというべきであり,被告CDDB(当初版・2006年版)と被告CDDB(現行版)とを比較してその体系的構成自体に変化があるものとはいえない。
したがって,被告らの上記主張は採用することができない。
(エ) また,被告らは,被告CDDB(現行版)において,「38禁止経路マスタ」は,「35地点マスタ」及び「36道路マスタ」とはリレーションがあるものの「37単経路マスタ」とはリレーションがない旨主張する。
被告らは,被告CDDB(現行版)の「36道路マスタ〔テーブルID;M_DORO〕」の「道路コード」フィールドと「38禁止経路マスタ〔テーブルID;M_KINSIKEIRO〕」の「道路コード」フィールドとの間,「36道路マスタ」の「道路コード」フィールドと「38禁止経路マスタ」の「通行禁止道路コード」フィールドとの間,及び「38禁止経路マスタ」の「地点コード(始点)」,「地点コード(中間点)」,「地点コード(終点)」のそれぞれの地点コードと「35地点マスタ〔テーブルID;M_CHITEN〕」の「地点コード」との間には,いずれもリレーションがあるとする一方,「37単経路マスタ〔テーブルID;M_TANKEIRO〕の「地点コード(始点)」,「地点コード(終点)」,「道路コード」のそれぞれのコードと「38禁止経路マスタ」の「地点コード(始点)」,「地点コード(中間点)」,「地点コード(終点)」,「道路コード」,「通行禁止道路コード」との間にはリレーションを否認するので,以下検討する。
まず,「38禁止経路マスタ」と「37単経路マスタ」との間にリレーションが存在しないとする被告の主張については,リレーショナル・データベースでは,各テーブルに共通するフィールドを用いて検索することになるところ,プログラムが禁止経路マスタと単経路マスタのそれぞれの「地点コード」と「道路コード」という双方のテーブルに共通するフィールドのデータを元に検索を行っていることから,体系的構成としてもテーブル間に共通のフィールドを設けるリレーションがとられていること,被告システムに用いられているSQLサーバーを管理するツールであるSQL Server Profiterを用いた解析結果によれば,現実の電子計算機による検索でも,被告システムにおいては,禁止経路マスタの地点コード(始点)と単経路マスタの地点コード(始点),禁止経路マスタの地点コード(中間点)と単経路マスタの地点コード(終点),禁止経路マスタの道路コードと単経路マスタの道路コードが全て同じとなる単経路に「1」,そうでない単経路には「0」というフラグ(指標)を付けて,単経路マスタの全ての単経路について,「地点コード始点」,「地点コード終点」,「所要時間」,「距離」の各フィールドの情報及び道路マスタの「道路区分」の各フィールドの情報を取得する命令をしており,被告CDDB(現行版)において,「38禁止経路マスタ」と「37単経路マスタ」とにリレーションがあることが認められるから,「37単経路マスタ」の「地点コード(始点)」,「地点コード(終点)」,「道路コード」のそれぞれのコードと「38禁止経路マスタ」の「地点コード(始点)」,「地点コード(中間点)」,「地点コード(終点)」,「道路コード」,「通行禁止道路コード」との間にリレーションがあることが認められる。〔甲58〕
したがって,被告らの上記主張は採用することができない。
(オ) 被告らは,「36道路マスタ」の「道路コード」フィールドと「38禁止経路マスタ」の「道路コード」フィールドとの間,「36道路マスタ」の「道路コード」フィールドと「38禁止経路マスタ」の「通行禁止道路コード」フィールドとの間,及び「38禁止経路マスタ」の「地点コード(始点)」,「地点コード(中間点)」,「地点コード(終点)」のそれぞれの地点コードと「35地点マスタ」の「地点コード」との間には,いずれもリレーションがあるとする点につき,被告らは,禁止経路は,あくまでも地点の組み合わせによりデータを取得していて単経路の組み合わせとはなっていないために,禁止経路マスタと単経路マスタは,一方が他方を包含する関係にありリレーションがある旨主張し,それに沿う証拠として,乙31の1,2を提出する。
乙31の1(木暮仁著「利用部門のための情報システム設計論」1997年3月2日第1刷発行・株式会社日科技連出版社)には,「リレーションシップとは,たとえば『社員』と『部門』の間での,『所属する』『部員である』というような結びつきをいう.一般的には動詞である.」と,また,乙31の2(株式会社システム・テクノロジー・アイ 林優子「プロとしてのデータモデリング入門」2006年11月29日初版第1刷発行・ソフトバンク クリエイティブ株式会社)には,「リレーションシップとは,『2つのエンティティの間の意味ある関連を表現するもの』です。たとえば,部門エンティティとは社員エンティティの間には,『社員は部門に所属する』という関係が成り立ちますが。この『所属する』というのがリレーションシップです。」との記載がある。
このうち,データモデルにおけるエンティティについては,データベースにおけるテーブルに対応するものとは認められるところ(甲64の4),上記乙31の1,2に,被告らが主張する,一方が他方を包含する関係にある場合にリレーションがあるとする内容についての記載はない。
また,リレーションシップとは,「データベースで,共通するフィールドを通じて複数のテーブルが関連付けられること。関連付けることで,複数のテーブルのレコードをひとつのテーブルのレコードのように扱える。」ことを意味するものと認められるところ(甲64の1),リレーションには,1対1,1対多,多対多の関係があるものと認められるから(甲64の3,4),包含関係があるか否かによりリレーションシップの有無を判断すべきものとは認められない。
そして,このように,データベースにおけるリレーションシップは,テーブル間の関連付けで,具体的にリレーションシップを実現するために,各テーブルに共通するフィールドを通じて,複数のテーブルが関連付けられることをいうものであるから,テーブル間に共通するフィールドがあれば両テーブル間にはリレーションがあるものと考えられるところ,その場合,フィールドIDないしフィールド名が同じになることが多いものと解されるが,それらが異なっていても,同じ属性のフィールドであれば共通のフィールドとなるものと解される。
加えて,被告CDDB(現行版)の「単経路マスタ」には「地点コード(始点)」,「地点コード(終点)」,「道路コード」のフィールドがあり,「禁止経路マスタ」には「地点コード(始点)」,「地点コード(中間点)」,「地点コード(終点)」,「道路コード」のフィールドがあり,単経路も禁止経路も道路コードと地点の組み合せで特定している。「単経路マスタ」でも「禁止経路マスタ」でも,道路コードのフィールドが共通であることに加え,始点,中間点,終点のいずれであれ地点コードが格納されているフィールドは地点コードという属性のデータが格納されている点で共通であるので,テーブル間にはその共通の属性のフィールドを介してリレーションがあるといえる。加えて,前記のとおり,被告CDDB(現行版)では,SQLサーバーの命令により,単経路マスタ,禁止経路マスタ間の共通のフィールドを使って実際の検索もされていることが認められる。
したがって,被告らの上記主張は採用することができない。
カ 依拠性について
被告CDDB(現行版)が,被告CDDB(当初版・2006年版)に改変等を加える形で制作されたと認められること,上記誤記等を含む具体的な情報の同一性等に照らし,被告CDDB(現行版)が,原告CDDBに依拠して作成されたことは明らかである。
被告らは,原告CDDBに依拠することなく,平成18年8月に被告CDDBを含む被告システムの制作を委託した外注先を変更し,独自に被告CDDB(現行版,Ver2.99)を作成したと主張し,それに沿う証拠として,外注先が作成したとするテーブル定義書(乙22)を提出する。
しかし,上記テーブル定義書(乙22)には,作成者,承認者の押印欄等があり,作成日を記入する欄も設けられているにもかかわらず,100枚以上提出されたその定義書には1枚も作成者,承認者の押印も作成日の記入もない上,平成23年2月21日に行われた第8回弁論準備手続期日においても,被告らにおいて,乙22の作成者については外注先の強い希望により具体的に特定することは差し控えるなどとして乙22の作成の経緯については何ら明らかにしないことを考慮すると,乙22及びそれが被告CDDB(現行版,Ver2.99)のテーブル定義書であるとする平成23年2月9日付け被告Y1作成の報告書(乙24)は,いずれも信用するに足りない。
したがって,被告らの主張は上記採用することができない。
キ 被告CDDB(現行版)についての結論
以上の検討によれば,被告CDDB(現行版)は,原告CDDBに依拠して制作された複製物に当たると認めるのが相当である。
(5)  最後に,被告CDDB(新版)につき検討する。
ア 被告CDDB(新版)と原告CDDBとの体系的構成の共通性
(ア) テーブルの種類及び数
a 一致するマスターテーブル
(a) 原告CDDBには42個の,被告CDDB(新版)には29個のマスターテーブルがそれぞれ含まれるところ,このうち,以下の7個のマスターテーブルについては,原告CDDBに含まれるマスターテーブルと一致することにつき争いがない。
一致することに争いのない7個のマスターテーブルは,以下のとおりである(原告CDDBのマスターテーブルによる表記。対応する被告CDDB(新版)の表記は別紙2該当欄記載のとおり)。
・「01市区町村テーブル」
・「06URLアドレステーブル」
・「09地点名テーブル」
・「10道路テーブル」
・「32駅テーブル」
・「42会社テーブル」
・「43交通機関種別テーブル」
(b) そして,原告は,「20ホテル・旅館テーブル」,「21観光施設テーブル」及び「22観光施設備考テーブル」についても,これら三つのテーブルに対応する,被告CDDB(新版)の「21施設マスタ」,「29宿泊施設マスタ」,「23観光施設マスタ」,「26観光料金マスタ」,「25観光料金種別マスタ」,さらには被告CDDB(新版)で加わった「130食事土産マスタ」,「131施設別詳細種別マスタ」,「132施設種別マスタ」,「133施設詳細種別マスタ」は,一致するマスターテーブルである旨主張し,さらに,「02地区・県名テーブル」は「3都道府県マスタ」と,「11接続テーブル」は「37単経路マスタ」と,「12禁止乗換テーブル」は「38禁止経路マスタ」と,「14区間料金テーブル」は「39区間料金マスタ」と,「15首都高速料金テーブル」は「40通行料金マスタ」と,「33路線構成テーブル」は「46路線構成マスタ」と,「34路線テーブル」は「43路線マスタ」と,「36路線検索テーブル」は「45時刻マスタ」と,「39便テーブル」及び「40運行日定義テーブル」は「44便マスタ」と,それぞれ対応して被告CDDB(新版)に存在する旨主張する。
まず,被告CDDB(新版)の「3都道府県マスタ」は,被告CDDB(現行版)と比較すると,被告CDDB(現行版)から被告CDDB(新版)へのバージョンアップに当たり,「34緯度経度マスタ」を削除したことに伴い,被告CDDB(新版)の「3都道府県マスタ」では,「代表道路地点コード」,「緯度」,「経度」,「都道府県カナ」の各フィールドが追加されたものの,これは上記削除に伴うものであって,内容的に重要な変更はされていないものと認められることから,被告CDDB(現行版)と同様,「3都道府県マスタ」は原告CDDBの対応するテーブルと実質一致するものと認められる。
また,被告CDDB(新版)の「37単経路マスタ」,「38禁止経路マスタ」,「39区間料金マスタ」及び「40通行料金マスタ」それら自体は,別紙3のとおり,各フィールドを含め,被告CDDB(現行版)と比較して変更はないと認められるから,被告CDDB(現行版)と同様,「37単経路マスタ」,「38禁止経路マスタ」,「39区間料金マスタ」及び「40通行料金マスタ」は,原告CDDBの対応するテーブルと実質的に一致するものと認められる。
次に,被告CDDB(新版)の「21施設マスタ」,「29宿泊施設マスタ」及び「23観光施設マスタ」は,被告CDDB(現行版)等と比較して詳細な情報を登録するためのフィールド(「風呂」,「バリアフリー」等)が追加されているものの,テーブル全体としては重要な変更がされていないから,被告CDDB(新版)の「26観光料金マスタ」及び「25観光料金種別マスタ」は,被告CDDB(現行版)と比較して変更はなく,被告CDDB(新版)の「21施設マスタ」,「29宿泊施設マスタ」,「23観光施設マスタ」及び「26観光料金マスタ」も,原告CDDBの対応するテーブルと実質的に一致するものと認められる。なお,被告CDDB(新版)の「25観光料金種別マスタ」は原告CDDBに対応するテーブルが存しないことは被告CDDB(当初版・2006年版),被告CDDB(現行版)のときと同様である。
そして,被告CDDB(新版)では,「宿泊施設マスタ」や「観光施設マスタ」と同様に,「施設マスタ」の下位のテーブルとして「130食事土産マスタ」が,施設の種別に関して大分類,中分類,小分類のテーブルとして,「132施設種別マスタ」,「133施設詳細種別マスタ」,「131施設別詳細種別マスタ」が,それぞれ追加されている。被告CDDB(新版)の「130食事土産マスタ」,「131施設別詳細種別マスタ」,「132施設種別マスタ」,「133施設詳細種別マスタ」と原告CDDBの「20ホテル・旅館テーブル」,「21観光施設テーブル」とは,別紙3,別紙7,別紙10(争いのあるリレーションについての判断は後記する。)のとおりの各フィールドやリレーションの内容等をみると,一部に共通するフィールドは存在しているものの,共通していない部分は,施設に関する情報を被告CDDB(現行版)からさらに追加可能にするものであって,施設を選択するための情報として参照可能なものであることが推認される。そうすると,これらは,原告CDDBとは,対応しないものと認められる。
さらに,被告CDDB(新版)の「46路線構成マスタ」,「43路線マスタ」は被告CDDB(現行版)と比較してフィールド内容に一部変更がされているが,被告CDDB(新版)では被告CDDB(現行版)に持たせていた料金計算のための情報を「駅すぱあと」に行わせるように設計を変更し,そのためのフィールドを設けたものであり,被告CDDB(新版)の「45時刻マスタ」,「44便マスタ」は被告CDDB(現行版)と比較して変更はないと思われることから,被告CDDB(現行版)と同様,被告CDDB(新版)の「46路線構成マスタ」,「43路線マスタ」,「45時刻マスタ」及び「44便マスタ」は原告CDDBの対応するテーブルと実質的には一致するものと認められる。ただし,後記するとおり,別紙10において,(※※)の付けられたフィールドが被告CDDB(新版)には新設されており,また,それに伴いリレーションの取り方も異なるものとなっている。
(c) 上記によれば,原告CDDBと被告CDDB(新版)とで一致するマスターテーブルは,上記20個であると認められる。
なお,被告CDDB(当初版・2006年版)及び被告CDDB(現行版)では,緯度経度情報を,「34緯度経度マスタ」とその他のテーブルの「4市区町村マスタ」,「21施設マスタ」,「35地点マスタ」,「47駅マスタ」で重複して保有しており,原告CDDBと同様となっていたところ,被告CDDB(新版)では「34緯度経度マスタ」のテーブルが削除されている。また,被告らは,それまで,「34緯度経度マスタ」とリレーションを取っていたが,実質的に利用していなかった「32URL種別マスタ」,「33URL分類マスタ」も削除した。
b 一致しないマスターテーブル
前記のとおり,被告CDDB(新版)の「25観光料金種別マスタ」は,原告CDDBに対応するマスターテーブルが存在せず,「130食事土産マスタ」,「131施設別詳細種別マスタ」,「132施設種別マスタ」及び「133施設詳細種別マスタ」についても,被告CDDB(新版)において新たに設けられたマスターテーブルであって,一致するものは原告CDDBには存しない。
また,被告CDDB(新版)の「134提携施設マスタ」,「135提携種別マスタ」,「136提携会社マスタ」及び「137単経路補間マスタ」についても,原告CDDBに対応するマスターテーブルが存在しない。
そして,原告CDDBのマスターテーブルのうち,「03方面テーブル」,「04方面設定テーブル」については,被告システムでは,方面検索の機能がないため,対応するテーブルが存在しない。
さらに,原告CDDBのマスターテーブルのうち,被告CDDB(新版)においては,原告CDDBの「05緯度経度テーブル」について,対応するテーブルが存在しない。
その他,被告CDDB(新版)では,原告CDDBの,「07URL種別テーブル」,「08URL分類テーブル」,「13有料道路番号テーブル」,「16道路構成地点テーブル」,「17道路構成地点索引テーブル」,「18市区町村通過道路索引テーブル」,「19県範囲定義テーブル」,「28協定施設テーブル」,「29券種テーブル」,「30協定旅館テーブル」,「31連結協定テーブル」,「35時刻表料金テーブル」,「37路線検索索引テーブル」,「38路線タイプテーブル」,「41時刻テーブル」,「44地方別会社索引テーブル」,「45検索地方範囲定義テーブル」,「46地方別路線索引テーブル」及び「47駅通過線索引テーブル」についても,被告CDDB(新版)に対応するマスターテーブルが存在しない。
(イ) 被告CDDB(新版)の各テーブルに存在するフィールドの種類及び数原告CDDBには42個のテーブルに,405個のフィールドが存するところ,被告CDDB(新版)の各テーブルに存在するフィールドは別紙3記載のとおりであり,29個のテーブルに326個のフィールドが存する。
前記のとおり原告CDDBのマスターテーブルと一致する被告CDDB(新版)の20個のテーブルにおけるフィールド項目については,別紙3記載のとおり,一致するテーブルに存するフィールドは294個である。
フィールドのうち,「作成日時」,「更新日時」及び「削除区分」のフィールドは,データ更新やテーブル管理を行うための管理項目であり,データベースの検索機能や提供データの内容自体に影響を及ぼす性質のものではない。〔甲3,7頁〕
このうち,被告CDDB(新版)における,ほぼ各テーブル(マスタ)に存在する「登録日時(作成日時)」,「更新日時(更新日時)」及び「削除区分(削除区分)」のフィールドを除くと,原告CDDBと被告CDDB(新版)とで一致するフィールド数のうち,別紙3のとおり,133個が,原告CDDBと一致している。
(ウ) テーブル間の関連付け
別紙3のとおり,原告CDDBと被告CDDB(新版)とでは,原告CDDBのマスターテーブルと一致する20個のテーブルに関して,プライマリー・キーの設定につき,原告CDDBの「02地区・県名テーブル」の「地区コード」フィールド,原告CDDBの「06URLアドレステーブル」の「テーブル種別」・「種別毎キー」フィールド,原告CDDBの「11接続テーブル」の「接続番号」フィールド(被告CDDB(新版)では,「37単経路マスタ」の「地点コード(始点)(地点番号_始点)」,「地点コード(終点)(地点番号_終点)」及び「道路コード(道路番号)」の三つのフィールドにプライマリー・キーが設定されている。),原告CDDBの「12禁止乗換テーブル」の「乗換元接続番号」フィールド(被告CDDB(新版)では,「38禁止経路マスタ」の「地点コード(始点)(地点番号_始点)」,「道路コード(道路番号)」,「地点コード(中間点)(地点番号中間)」「地点コード(終点)(地点番号_終点)」及び「通行禁止道路コード(道路番号_禁止)」の五つのフィールドにプライマリー・キーが設定されている。),被告CDDB(新版)の「39区間料金マスタ」及び「40通行料金マスタ」の各「道路料金区分(道路料金区分)」フィールドを除き,一致したフィールドないし同一のテーブルの同種フィールドにプライマリー・キーが設定されている。
これらによれば,被告CDDB(新版)におけるテーブル間のリレーションに関しては,別紙10の青丸と青丸を結ぶ黒線(黒太線を含む)及び黒点線のとおりと認められる。
なお,この点につき,被告らは,被告CDDB(新版)の「36道路マスタ〔テーブルID;M_DORO〕」の「道路コード」フィールドと「38禁止経路マスタ〔テーブルID;M_KINSIKEIRO〕」の「道路コード」フィールドとの間,「36道路マスタ」の「道路コード」フィールドと「38禁止経路マスタ」の「通行禁止道路コード」フィールドとの間,及び,「38禁止経路マスタ」の「地点コード(始点)」,「地点コード(中間点)」,「地点コード(終点)」のそれぞれの地点コードと「35地点マスタ〔テーブルID;M_CHITEN〕」の「地点コード」との間には,いずれもリレーションがあるとする一方(別紙10に赤丸と赤丸を結ぶ赤点線で記載されたリレーション),「37単経路マスタ〔テーブルID;M_TANKEIRO〕」の「地点コード(始点)」,「地点コード(終点)」,「道路コード」のそれぞれのフィールドと「38禁止経路マスタ」の「地点コード(始点)」,「地点コード(中間点)」,「地点コード(終点)」,「道路コード」,「通行禁止道路コード」との間のリレーションを否認する(別紙10に青丸と青丸を結ぶ黒点線で記載されたリレーション)ので,以下,検討する。
まず,「38禁止経路マスタ」と「37単経路マスタ」との間にリレーションが存在しないとする被告の主張については,被告システムに用いられているSQLサーバーを管理するツールであるSQL Server Profiterを用いた解析結果によれば,被告CDDB(新版)においても,「38禁止経路マスタ」と「37単経路マスタ」とにリレーションがあることが認められるから,これと各テーブルのフィールドの内容からすれば,上記「37単経路マスタ」の「地点コード(始点)」,「地点コード(終点)」,「道路コード」のそれぞれのフィールドと「38禁止経路マスタ」の「地点コード(始点)」,「地点コード(中間点)」,「地点コード(終点)」,「道路コード」,「通行禁止道路コード」との間にリレーションがあることが認められる。これらの詳細は前記被告CDDB(現行版)における判断と同様である。〔甲58〕次に,「36道路マスタ」の「道路コード」フィールドと「38禁止経路マスタ」の「道路コード」フィールドとの間,「36道路マスタ」の「道路コード」フィールドと「38禁止経路マスタ」の「通行禁止道路コード」フィールドとの間,及び「38禁止経路マスタ」の「地点コード(始点)」,「地点コード(中間点)」,「地点コード(終点)」のそれぞれの地点コードのフィールドと「35地点マスタ」の「地点コード」フィールドとの間には,いずれもリレーションがあるとする点につき,被告らは,禁止経路は,あくまでも地点の組み合わせによりデータを取得していて単経路の組み合わせとはなっていないために,禁止経路マスタと単経路マスタは,一方が他方を包含する関係にあるから,リレーションがある旨主張する。
しかし,包含関係があるか否かによりリレーションの有無が判断されるものとは認められないことは前記被告CDDB(現行版)についての判断と同様である。
また,被告CDDB(新版)では,被告CDDB(現行版)と同様,原告CDDBの「20ホテル・旅館テーブル」,「21観光施設テーブル」及び「22観光施設備考テーブル」の3テーブルに対応するテーブルとして,被告CDDB(新版)では「21施設マスタ」,「29宿泊施設マスタ」,「23観光施設マスタ」及び「26観光料金マスタ」の4テーブルを設けているところ,原告CDDBにおける「01市区町村テーブル」が「20ホテル・旅館テーブル」,「21観光施設テーブル」の二つのテーブルとリレーションを取っていることに対して,被告CDDB(新版)では「4市区町村マスタ」は,原告CDDBの「20ホテル・旅館テーブル」,「21観光施設テーブル」の共通項目を括りだした上位のテーブルとなっている被告CDDB(新版)の「21施設マスタ」の一つのテーブルとのみリレーションを取っている。これにより,これと関連するリレーションの線がその分少なくなっている。
(エ) 一方で,被告CDDB(新版)では,前記のとおり,被告CDDB(現行版)に比して,原告CDDBと一致しないテーブルである,「130食事土産マスタ」,「131施設別詳細種別マスタ」,「132施設種別マスタ」,「133施設詳細種別マスタ」,「134提携施設マスタ」,「135提携種別マスタ」,「136提携会社マスタ」及び「137単経路補間マスタ」が追加されている。
まず,「130食事土産マスタ」は,下位テーブルである類型別のマスターテーブルとして新たに追加するものであり,具体的には,食事処及び土産施設の情報充実を図るものである。これは観光施設,宿泊施設にかかわらず,ドライブインや名産品の土産店などのように,食事のためや土産物を購入するためにだけ立ち寄ることができる施設があり,観光施設や宿泊施設から独立させて,これらに特化した情報である開館・閉館時間や,食事内容,土産内容等に関する検索機能を充実させることへの利用者(顧客)からの要望に応えるために設置されたものである。
また,「131施設別詳細種別マスタ」,「132施設種別マスタ」及び「133施設詳細種別マスタ」は,被告CDDB(現行版)においては,観光施設の種別につき,「施設マスタ」中の「観光種別」のフィールド,「観光種別マスタ」と「観光詳細種別マスタ」で格納していたのに対し,宿泊施設と公共施設の種別については,施設マスタの中の「宿泊種別」「公共施設種別」のフィールドのみで格納しており,これら施設によって施設の種別の格納の仕方が異なっていたが,被告CDDB(新版)では,これを一元的に整理し格納するため,施設の種別については,観光施設,宿泊施設,公共施設,被告CDDB(新版)で追加された食事処及び土産施設のいずれも,「132施設種別マスタ」,「133施設詳細種別マスタ」及び「131施設別詳細種別マスタ」の三つのテーブルで格納することとした。これに伴って,被告CDDB(現行版)の「観光種別マスタ」及び「観光詳細種別マスタ」は削除された。
これら情報の格納の詳細については,まず,施設を「宿泊」,「観光」,「公共」及び「食事・土産」の四つに大分類し,次に,そこから施設種別の中分類として施設種別マスタを用意し,さらに,小分類として施設詳細種別マスタを用意している。〔乙26〕
これにより,例えば,ある一つの施設が神社・仏閣としても博物館としても分類されるような複合的な施設種別を持つ場合において,当該施設に割り当てられた一つの施設コードを使って,神社・仏閣としても博物館としても検索できるような構造とした。
また,「134提携施設マスタ」,「135提携種別マスタ」及び「136提携会社マスタ」は,宿泊施設や観光施設等が,大手旅行会社や全国旅行業協会,旅行案内所などと提携している施設か否か,宿泊クーポンや食事クーポン等のクーポンを利用できる施設か否か,各会社のクーポンを発券できる施設か否かといった情報を新たに格納したものであり,これらも利用者からの要望に応えるものである。
イ 被告CDDB(新版)の体系的構成が,原告CDDBの複製又は翻案に当たるか
(ア) 上記のとおり,原告CDDBと被告CDDB(新版)とでは,原告CDDBにおける,「01市区町村テーブル」,「02地区・県名テーブル」,「06URLアドレステーブル」,「09地点名テーブル」,「10道路テーブル」,「11接続テーブル」,「12禁止乗換テーブル」,「14区間料金テーブル」,「15首都高速料金テーブル」,「20ホテル・旅館テーブル」,「21観光施設テーブル」,「22観光施設備考テーブル」,「32駅テーブル」,「33路線構成テーブル」,「34路線テーブル」,「36路線検索テーブル」,「39便テーブル」,「40運行日定義テーブル」,「42会社テーブル」及び「43交通機関種別テーブル」の20個のテーブルにつき,これと一致するテーブルが被告CDDB(新版)にも存する。
しかし,これら一致するテーブルについても,フィールドの構成やリレーションのとり方には,被告CDDB(現行版)と異なる点があることは後記のとおりである。
また,被告CDDB(新版)の全フィールド数は,326個であるところ,原告CDDBと被告CDDB(新版)とで一致するフィールドは133個である。
さらに,テーブル間の関連付けについては,原告CDDBと被告CDDB(新版)とのリレーションの関係を対比すると,別紙7,10のとおりであり,被告CDDB(新版)では,別紙10の青丸と青丸を結ぶ黒太線で示されている,「4市区町村マスタ」の「代表道路地点コード」フィールドと,「21施設マスタ」の「代表道路地点コード」フィールド,「35地点マスタ」の「地点コード」フィールド,「47駅マスタ」の「代表道路地点コード」フィールドとのリレーションについては被告CDDB(現行版)から引き続いて存在するものの,「34緯度経度マスタ」,「32URLアドレスマスタ種別マスタ」,「33URL分類マスタ」を削除したことに伴い,これらとのリレーションが消滅している。
そして,被告CDDB(新版)において,「130食事土産マスタ」,「131施設別詳細種別マスタ」,「132施設種別マスタ」,「133施設詳細種別マスタ」,「134提携施設マスタ」,「135提携種別マスタ」,「136提携会社マスタ」及び「137単経路補間マスタ」が新設されたことに伴い,これら相互のリレーションのほか,被告CDDB(現行版)にも存した,「37単経路マスタ」,「21施設マスタ」,「29宿泊施設マスタ」との間で,新たなリレーションも多数発生している。
(イ) 前記認定のとおりの,原告CDDBと被告CDDB(新版)との間で一致するテーブルについて詳しくみると,原告CDDBでは,「01市区町村テーブル」,「32駅テーブル」,「20ホテル・施設テーブル」,「21観光施設テーブル」,「09地点名テーブル」,「11接続テーブル」及び「10道路テーブル」により,出発地,経由地,目的地に面した道路に関するデータの検索を可能にし,また,「09地点名テーブル」,「10道路テーブル」,「11接続テーブル」,「12禁止乗換テーブル」,「14区間料金テーブル」及び「15首都高速料金テーブル」により,道路を利用した移動に関する経路探索・料金の算出に必要なデータの検索を可能にしている。
しかし,これらと対応する被告CDDB(新版)のテーブルをみると,新たなテーブルとして,「137単経路補完マスタ」が「37単経路マスタ」とリレーションをとる形で設けられ,従来設けられていた「34緯度経度マスタ」とのリレーションも消滅している。
また,原告CDDBでは,「20ホテル・旅館テーブル」,「21観光施設テーブル」,「22観光設備備考テーブル」及び「06URLアドレステーブル」により,ホテル・旅館,観光施設に関する情報を検索することを可能にしているものであるが,被告CDDB(新版)では,新たに「130食事土産マスタ」が設けられているほか,「29宿泊施設マスタ」,「23観光施設マスタ」においても,別紙10の各テーブル内に(※※)が記載されたフィールドに示されているとおり,相当の数の新設フィールドが設置されているし,「21施設マスタ」,「29宿泊施設マスタ」は,いずれも新設テーブルである「131施設別詳細種別マスタ」,「132施設種別マスタ」,「133施設詳細種別マスタ」,「134提携施設マスタ」,「135提携種別マスタ」,「136提携会社マスタ」との新たなリレーションがとられている。
さらに,原告CDDBでは,「32駅テーブル」,「33路線構成テーブル」,「34路線テーブル」,「36路線検索テーブル」,「39便テーブル」,「40運行日定義テーブル」,「42会社テーブル」及び「43交通機関種別テーブル」により,公共交通機関を利用した経路探索に必要なデータの検索を可能にしているが,それらに対応する被告CDDB(新版)の「43路線マスタ」,「47駅マスタ」には「駅すぱあと」との連動のためのフィールドが設けられ,また「46路線構成マスタ」に「出発駅コード」,「到着駅コード」の各フィールドが設けられたことに伴い,「47駅マスタ」とのリレーションにも変化がある。
そして,原告CDDBの「01市区町村テーブル」,「02地区・県名テーブル」は,道路と地図を関連付ける情報として,地図から検索をするときに用いられるものであるが,検索対象となる宿泊・観光施設や経路等との結びつきが重要であるとみられるところ,前記のとおり,これらの施設や経路等についてのテーブル,フィールド及びそれらについてのリレーションに関し,相当な変更が被告CDDB(新版)ではされているものといえる。
(ウ) 以上によれば,被告CDDB(新版)においては,被告CDDB(新版)が原告CDDBと共通性を有する部分のうち,「01市区町村テーブル」,「32駅テーブル」,「20ホテル・施設テーブル」,「21観光施設テーブル」,「09地点名テーブル」,「11接続テーブル」及び「10道路テーブル」により,出発地点,経由地,目的地に面した道路に関するデータの検索を可能にし,「09地点名テーブル」,「10道路テーブル」,「11接続テーブル」,「12禁止乗換テーブル」,「14区間料金テーブル」及び「15首都高速料金テーブル」により,道路を利用した移動に関する経路探索を行うことを可能にしている点では,なお原告CDDBの創作的表現の本質的な特徴を直接感得することができる部分があるということができそうにも思われる。
(エ) しかし,出発地,経由地,目的地に面した代表道路地点に関連して,その緯度経度情報による経路探索を行うことを可能とする被告CDDB(新版)の「4市区町村マスタ」(原告CDDBの「01市区町村テーブル」),「47駅マスタ」(原告CDDBの「32駅テーブル」),「21施設マスタ」(原告CDDBの「20ホテル・施設テーブル」,「21観光施設テーブル」),「35地点マスタ」(原告CDDBの「09地点名テーブル」)の各テーブル及びこれらを結ぶリレーション(別紙10の青丸と青丸を結ぶ黒太線),これと関連する,「37単経路マスタ」(原告CDDBの「11接続テーブル」),「36道路マスタ」(原告CDDBの「10道路テーブル」),「38禁止経路マスタ」(原告CDDBの「12禁止乗換テーブル」)との別紙10記載のリレーションについては,それらを構成するテーブル,リレーションは,被告CDDB(新版)の全体のフィールド数,リレーションのとり方からみると,ごく一部となってしまっている上に,新たに設けられたテーブルである,「137単経路補完マスタ」,「130食事土産マスタ」,「131施設別詳細種別マスタ」,「132施設種別マスタ」,「133施設詳細種別マスタ」,「134提携施設マスタ」,「135提携種別マスタ」,「136提携会社マスタ」等との間に新たなリレーションがとられている。そして,これら新設テーブルについては,上記各テーブルに含まれるフィールドの内容や機能等からすれば,これら被告CDDB(新版)において,新たな創作的表現として加えられたことを肯定できる。
そうすると,従前の一致部分が削除されたり,新たな創作的表現が付け加えられたりしている被告CDDB(新版)全体からみた場合には,原告CDDBと共通性を有する部分は,被告CDDB(新版)の全体の中からみれば,もはや原告CDDBの表現の本質的な特徴を直接感得することができなくなっていると認めるのが相当である。
そうすると,被告CDDB(新版)は,もはやその体系的構成において,原告CDDBの複製ないし翻案には該当しないというべきである。
ウ 被告CDDB(新版)と原告CDDBとの情報の選択の共通性
(ア) フィールド項目の選択の類似性
前記のとおり,テーブル管理のためのフィールドである「登録日時」,「更新日時」及び「削除区分」等のフィールドを除いた被告CDDB(新版)のフィールド数219個のうち146個が原告CDDBのフィールドと一致している。
一方,被告CDDB(新版)では,「3都道府県マスタ」テーブルに「代表道路地点コード」,「緯度」,「経度」等のフィールドを新設した。
また,被告CDDB(新版)では,「47駅マスタ」テーブルに「駅名(駅すぱあと)」フィールドを,「46路線構成マスタ」テーブルに「出発駅コード」及び「到着駅コード」フィールドを,「43路線マスタ」テーブルに「駅すぱあと収録区分」及び「集約路線コード」フィールドをそれぞれ新設した。
これらの新設フィールドについては,原告CDDBに対応するフィールドが存しない。
さらに,被告CDDB(新版)において新設したテーブルについては,原告CDDBに対応するテーブルが存しないところ,その詳細は以下のとおりである。
被告CDDB(新版)における新設テーブルである,「132施設種別マスタ」には,ホテル,旅館,ビジネス,名所旧跡・公園景観等,18の施設種別名の情報が格納されており,別紙3のとおり,フィールドは「施設種別名」,「表示順」,「施設大種別」,「施設種別」,「更新日時」,「作成日時」及び「削除区分」の7個である。〔乙26〕同じく新設テーブルである「133施設詳細種別マスタ」には,ホテル,旅館,ビジネス,史跡,庭園,歴史的建造物等,60の施設詳細種別名の情報が格納されており,別紙3のとおり,フィールドは,「施設種別」,「施設詳細種別名」,「施設大種別」,「表示順」,「作成日時」,「更新日時」及び「削除区分」の7個である。〔乙26〕
新設テーブルである「131施設別詳細種別マスタ」には,「かんぽの宿小樽」以下,15万件余りの旅館,施設等の施設名の情報が格納されており,フィールドは,「施設種別」,「施設大種別」,「更新日時」,「作成日時」及び「削除区分」の5個である。
同じく新設テーブルである「134提携施設マスタ」には観光施設,食事施設等5000件余りの施設の情報が格納されており,別紙3のとおり,フィールドは,「施設コード」,「提携会社コード」,「提携種別」,「提携施設コード」,「更新日時」,「削除日時」及び「作成日時」の7個である。〔乙26〕
新設テーブルである「135提携種別マスタ」には6件の情報が格納されており,別紙3のとおり,フィールドは,「表示順」,「提携会社コード」,「提携種別」,「提携種別名」,「更新日時」,「削除区分」及び「作成日時」の7個である。〔乙26〕新設テーブルである「136提携会社マスタ」には1件の情報しか格納されていないが,別紙3のとおり,フィールドは,「表示順」,「提携会社コード」,「提携会社名」,「更新日時」,「削除区分」及び「作成日時」の6個である。〔乙26〕
新設テーブルである「137単経路補間マスタ」は,道路に関し,地図上に表示するルート検索結果の経路表示を地図上の道路に沿った曲線のように画面上に表示するための座標データとして,1万7000件余りの情報が格納され,別紙3のとおり,フィールドは,「地点コード(始点)」,「地点コード(終点)」,「道路コード」,「緯度」,「経度」,「更新日時」,「連番」,「削除区分」及び「作成日時」の9個であり,このうち,「地点コード(始点)」,「地点コード(終点)」,「道路コード」及び「連番」のフィールドにプライマリー・キーが設定されている。〔乙26〕
「137単経路補間マスタ」は,「37単経路マスタ」に格納された地点間を結ぶ情報につき,行程表において単経路マスタの情報を使用して地図上の移動経路を印刷するところ,地点間の距離が離れるほど,地図上の移動経路の印刷が直線的になるので,「単経路マスタ」の経路情報をさらに詳細なものとして,「137単経路補間マスタ」に収録することとしたものである。これにより,上記のとおり,行程表の移動経路の印刷を,実際の道路に近い,きめ細かなものとするためのテーブルである。
(イ) レコードの選択の類似性
被告らは,被告CDDB(当初版・2006年版)において,原告CDDBのテーブルのうち,以下の20個のテーブルに含まれるレコードをコピーして用いたことを認めていた。
そのテーブルとは,「20ホテル・旅館テーブル」,「21観光施設テーブル」,「05緯度経度テーブル」,「06URLアドレステーブル」,「07URL種別テーブル」,「08URL分類テーブル」,「01市区町村テーブル」,「02地区・県名テーブル」,「09地点名テーブル」,「10道路テーブル」,「11接続テーブル」,「12禁止乗換テーブル」,「13有料道路番号テーブル」,「14区間料金テーブル」,「15首都高速料金テーブル」,「16道路構成地点テーブル」,「17道路構成地点索引テーブル」,「18市区町村通過道路索引テーブル」,「19県範囲定義テーブル」及び「32駅テーブル」である。
このうち,被告らは,被告CDDB(現行版)までに,被告CDDB(当初版・2006年版)において存在した,原告CDDBの「13有料道路番号テーブル」,「16道路構成地点テーブル」,「17道路構成地点索引テーブル」,「18市区町村通過道路索引テーブル」及び「19県範囲定義テーブル」の5個のテーブルと対応するテーブルは削除したとしている。
また,被告らは,被告CDDB(現行版)においてはレコード数がゼロであったにもかかわらず維持されていた,原告CDDBの「07URL種別テーブル」,「08URL分類テーブル」に対応する「32URL種別マスタ」,「33URL見出しマスタ(被告CDDB(現行版)ではURL分類マスタ)」の2個のテーブルについて,被告CDDB(新版)では削除した。
さらに,重複保有となっていた「34緯度経度マスタ」について,被告CDDB(現行版)において公共施設7万件余りを追加し,総レコード数を18万件余りとしていたところ,このテーブルについても削除した。
原告CDDBの「20ホテル・旅館テーブル」及び「21観光施設テーブル」と対応する被告CDDB(新版)の「29宿泊施設マスタ」,「21施設マスタ」,「23観光施設マスタ」についても,被告CDDB(現行版)と比して,レコードの追加削除等を行っている。
その他,「35地点マスタ」,「36道路マスタ」,「37単経路マスタ」,「38禁止経路マスタ」,「39区間料金マスタ」,「40通行料金マスタ」及び「47駅マスタ」については,被告CDDB(現行版)から,それぞれレコードの追加削除等を行った。
(ウ) 具体的な情報の同一ないし類似性
a 地点名テーブルの道路情報
原告CDDB(2006年11月版)の「09地点名テーブル」には,1万2822件のレコードが収録され,被告CDDB(新版)では,「35地点マスタ」には,そのうちの92.6%である1万1872件につき,一致する道路地点(前記同様,「関JCT(伊勢自動車道・名阪国道)」,「芸濃IC(伊勢自動車道,県道10号)」等)のレコードが収録されている。〔甲32〕
b 緯度経度情報の一致
そして,原告CDDBの「09地点名テーブル」の上記道路地点の緯度経度情報は,前記のとおり,原告CDDB作成時に,作成者自身がパソコンのマウスを地図上でクリックする方法で選択した場所について,これを0.1秒単位で緯度経度を測定して数値化したものであるところ,被告CDDB(新版)も,6ないし7桁の数値で緯度経度情報を収録しているところ,上記道路地点のうち,この6桁ないし7桁で表される緯度及び経度情報につき,これと原告CDDB(2006年11月版)との完全一致率は8.1%であり,1033件の一致するレコードが収録されている。〔甲22,28,32,39,70〕
これについては,被告システム(現行版)Ver2.94 までは,緯度経度情報は,原告CDDBのものを全て流用していたものであるが,その後,原告からの訴訟提起を受けて,見直した結果であるとする。〔証人A尋問調書20頁〕
c 選択道路の一致
原告CDDBは,前記のとおり,大型観光バスでの移動に適した道路の選択を行っており,多くの道道,県道等の中から北海道では80道道,福岡県では47県道を選択しているところ,被告CDDB(新版)では,北海道については全データが171件となり,原告CDDBと同じ道道は79個を,福岡県では全データが123件となり,これと一致する県道のうち42県道を,それぞれ選択している。〔甲48〕
d その他の情報の一致
(a) 地点名テーブルについて
被告CDDB(現行版)に存在した原告CDDBと同じ誤りについては,被告らは,被告CDDB(新版)で修正した。〔甲21〕
(b) 道路テーブルについて
被告CDDB(現行版)には原告CDDBと同じ誤りが存したが,被告らは,被告CDDB(新版)から道路名の読み仮名である「道路カナ」のフィールド自体を削除した。
また,原告CDDBと一致するダミーデータ「***」(道路名),「ン ダミー」(道路名の読み)についても,被告らは,被告CDDB(新版)において削除している。〔甲21〕
(c) ホテル・旅館テーブルについて
ⅰ 宿泊施設の読み仮名に関しては,原告CDDBと同じ誤りが被告CDDB(新版)にも存在する。原告CDDBでは宿泊施設名の読み仮名について長音符「ー」とすべきを誤って数字記号マイナス「-」で登録した場合が相当数あるが,これらと同じ誤りが被告CDDB(新版)にも存在する。具体的には,前記(3)カ(ア)g(a)記載のとおりである。
ⅱ 宿泊施設名の読み仮名に関して,原告CDDBと同じ誤り(施設カナ)が被告CDDB(新版)にも存在する。具体的には,前記(3)カ(ア)g(b)記載のとおりである。〔甲65の別紙13〕
(d) 観光施設テーブルについて
ⅰ 観光施設の読み仮名に関して原告CDDBと同じ誤りが被告CDDB(新版)にも存在する。原告CDDBでは観光施設名の読み仮名について長音符「ー」とすべきを誤って数字記号マイナス「-」で登録した場合が相当あるが,これと同じ誤りが被告CDDB(新版)にも存在する。以下は読み仮名に長音符「ー」とマイナス記号「-」が混用されている前記(3)カ(ア)h(b)記載の例のほか,同様の事例が存在を示すものである。
なお,宿泊施設名称の読み仮名に関し,原告CDDBでは,宿泊施設名に「英字」「数字」を含む場合,「英字」「数字」についてもきちんと読み仮名で表記されているものと,読み仮名に「英字」「数字」がそのまま残っているものが混用されており,被告CDDB(現行版)にも同じ混用状態が存在していた。この点につき,被告CDDB(新版)では,原告CDDBの施設名称「美利河I遺跡」(「I」は英字のアイ)の誤りにつき,被告CDDB(新版)は,被告CDDB(現行版)において原告CDDBと一致する誤り(英字の「I」)の登録を訂正した。〔甲65の別紙14〕
ⅱ 株式会社,有限会社の施設名やその読み仮名に関する原告CDDBの不統一の表記や誤りと同じ不統一の表記や誤りが被告CDDB(新版)に存在する。
原告CDDBは,株式会社や有限会社といった法人の種別について,施設名とそのカナについて不統一な表記を行っている。
原告CDDBの以下の二つのパターンと同様のデータの事例が被告CDDB(新版)にも存在する。〔甲65の別紙18〕
・ 施設名を株式会社とし,カナをサブシキカイシャと誤って表記する
・ 施設名を(株)とし,カナをカブと表記する
ⅲ 観光施設名の読み仮名表記に原告CDDBと同じ誤り(「ひらがなが混じる」,「漢字が混じる」など)が被告CDDB(新版)にも存在する。被告CDDB(現行版)と同じ以下の例のほか,他にも事例がある。〔甲65の別紙19〕
・施設名:光大寺の湯
施設カナ:コウダイジのユ
・施設名:霞間ヶ渓スポーツ公園
施設カナ:カマガタニスポ-ツ公園
なお,以下の例については,被告CDDB(新版)においては訂正されている。
・施設名:航空博物館(誤記である施設カナ:コウクウガクブツアkン)
・施設名:スパガーデンコートピア(誤記である施設カナ:スパガ-デンコ^-トピア)
(エ) 新たなテーブルへの情報の格納
前記のとおり,被告CDDB(新版)においては,新設テーブルとして,「131施設別詳細種別マスタ」,「132施設種別マスタ」,「133施設詳細種別マスタ」,「134提携施設マスタ」,「135提携種別マスタ」,「136提携会社マスタ」及び「137単経路補間マスタ」が設けられており,「131施設別詳細種別マスタ」には,15万件余りの旅館,施設等の施設名の情報が,「134提携施設マスタ」には観光施設,食事施設等5000件余りの施設の情報が格納されている。
また,被告CDDB(新版)における新設テーブルである「130食事土産マスタ」には,別紙4のとおり,株式会社全旅クーポン事業部発行の「全国『観光・運輸』総合カタログ2011年」に掲載されたドライブインなどの食事施設,土産物店などの情報1万0695件が,新たに格納されている。
エ 被告CDDB(新版)の情報の選択が,原告CDDBの複製又は翻案に当たるか
(ア) 原告CDDBと被告CDDB(新版)との情報の選択の類似性に関し,情報の選択項目であるテーブル,フィールドについて,原告CDDBと被告CDDB(新版)とを比較すると,前記のとおり,被告CDDB(新版)の全テーブル数が29個であるところ,一致するテーブルはそのうちの20個であり,フィールド数に関しては,全フィールド数が326個であるところ,一致するフィールドは133個である。
そして,被告CDDB(新版)においては,前記のとおり,相当の数の新たなテーブルが設置され,既存のテーブルについても,詳細化するフィールドの追加が相当数されている。
例えば,地点名テーブルの道路情報については,相当数の地点が一致しているが,これは前記のように,「関JCT」や「芸濃IC」等,インターチェンジ自体を選ぶというものであるから,それら重要地点を選ぶ必然性が高く,また,これら一致する道路地点の選択が,相当に幅のある中から1万件余りの情報を選択したことについての証拠はない。
具体的な道路地点についての緯度経度情報の完全一致率についても,被告CDDB(現行版)と比して大幅に低下し,一致率は10%に満たない。
また,選択道路についても,被告CDDB(新版)の全データに比較して,原告CDDBと一致する選択道路の割合でみた場合には半分以下となっている。
さらに,被告CDDB(新版)の全レコード数は,別紙4のとおり約270万件にも及び,原告CDDBとは,その情報量に相当の隔たりがある。
(イ) 他方,原告CDDBと被告CDDB(新版)では,依然として,前記記載のとおり,原告CDDBと同じ誤りないし不自然な表現方法の同一性もみられる。
しかし,これらについても,上記認定した原告CDDBと被告CDDB(新版)とで共通性を有する部分の表現方法ないし誤り自体には,原告CDDBの創作性があるものと認めるべき内容はみられないというべきである。
(ウ) これらを総合勘案すると,被告CDDB(新版)においては,もはや,情報の選択においても,原告CDDBと共通性を有する部分は少なく,共通性を有する部分については創作性を有するものとは認め難いか,あるいは原告CDDBの創作的表現上の特徴を直接感得することができないものであると認めるのが相当である。
そうすると,被告CDDB(新版)は,もはやその情報の選択において,原告CDDBの複製ないし翻案には該当しないというべきである。
オ 原告の主張に対する判断
(ア) 原告は,被告CDDB(新版)においても,体系的構成において,テーブル間の関連付けが,原告CDDBのマスターテーブルと一致するテーブルに関して,プライマリー・キーの設定も含め,原告CDDBに存在する関連付けのほぼ全てについて同じリレーションが,被告CDDB(新版)にも存在する旨主張する。
しかし,被告CDDB(新版)におけるテーブル間のリレーションについては,原告CDDBと相当程度の相違があることは前記のとおりである。
したがって,原告の上記主張は採用することができない。
(イ) 原告は,フィールド項目の選択の類似性として,テーブル管理のためのフィールドである「作成日時」,「更新日時」及び「削除区分」のフィールドを除いた場合の被告CDDBのフィールド数のうち,146個が原告CDDBと一致しており,したがって,原告CDDBのフィールド項目の選択を流用しているといえるから,この点に関して原告CDDBと被告CDDB(新版)は同一あるいは少なくとも類似している旨主張する。
しかし,原告CDDBと被告CDDB(新版)のフィールドの一致数については,前記認定のとおり133個であると認められるところ,その余の200個弱のフィールドについては,もはや原告CDDBと一致するものではなく,被告CDDB(新版)を全体としてみた場合に,原告CDDBと被告CDDB(新版)とのフィールドには同一性ないし類似性は認められないというべきである。
したがって,原告の上記主張は採用することができない。
(ウ) 原告は,被告CDDB(新版)では,各テーブルにおいてレコードが追加されている場合があるものの,原告CDDBのレコードの集合物に対してレコードが追加されたとしても,原告CDDBの集合物は維持されて存続しているので,追加されたレコードが膨大なものか否かにかかわらず,原告CDDBのレコードの集合物のその部分に関しては,情報の選択について原告CDDBと類似しているから,被告らが流用した原告CDDBのレコードの集合物の情報の選択について,原告CDDBと類似することとなる旨主張する。
なるほど,被告CDDB(新版)のレコード数が270万件余りにのぼるとしても,これらは原告CDDBからコピーしたデータが相当数存する被告CDDB(当初版・2006年版)に,レコードが追加・改変されてきたものにほかならず,いまだ原告CDDBからコピーされたままのレコードも相当数に上ると推認されるところである。
しかし,データベースの著作物として保護されるのは情報の選択ないし体系的構成において創作性を有するものであり,データないしレコード等それ自体を保護するものではない。そして,前記のデータベースが著作物として保護される理由,その著作物性の有無や複製及び翻案の判断基準に照らせば,例え,原告のデータベースと被告のデータベースとの間に情報の選択において共通点があり,その共通点において,原告データベースの表現としての創作性のある部分が一部含まれているとしても,両データベース全体を比較した場合に,その保有する情報量に大きな差があるため,情報の選択として創作性を有する共通部分がその一部にすぎず,相当部分が異なる場合には,もはや情報の選択においてその表現の本質的特徴を直接感得できると評価することはできず,また,原告のデータベースと被告のデータベースとの間に体系的構成において共通点があり,その共通点において,原告データベースの表現としての創作性のある部分が一部含まれているとしても,両データベース全体を比較した場合に,共通しないテーブル,フィールド項目が相当数を占め,また,それら相互間のリレーションの仕方にも大きな相違がみられるため,体系的な構成として創作性を有する共通部分がその一部にすぎず,相当部分が異なる場合には,体系的構成においてもその表現の本質的特徴を直接感得できるということはできないというべきであって,そのような場合,被告データベースはもはや,共通部分を有する原告データベースとは別個のデータベースであると認めるのが相当である。
そうすると,本件においては,前記のとおり,被告CDDB(新版)は,原告CDDBと比較して,情報の選択及び体系的構成において相当な相違が存在し,共通する部分を有する原告データベースとは別個のデータベースとなったものというべきであるから,原告CDDBからコピーしたレコード自体が残存しているとしても,もはや,両者が情報の選択及び体系的構成において類似していると評価することは相当でないというべきである。
したがって,原告の上記主張は採用することができない。
(エ) 原告CDDBの道路地点の情報の選択に関して,被告CDDB(新版)の道路地点の緯度経度情報については,-10秒から10秒の間でみれば,被告CDDB(新版)には原告CDDBの緯度経度情報が約90%が含まれているところ(甲34の別紙4の1,別紙5の1),被告らは,原告から平成21年5月に著作権侵害の訴えを提起された後に,一定範囲内で数値が異なるような乱数発生機能を利用する変換プログラムを作成して,元の緯度経度データの数値に対して一斉に変換をかける等の自動処理や個別の改変等の工作を行っているものであり,このような工作を行ったとしても,原告CDDBの緯度経度情報をデッドコピーした後に,隠蔽目的でデッドコピーした緯度経度情報に依拠して自動変換等の改変がされたすぎないから,被告CDDB(新版)は,原告CDDBの道路地点情報の緯度経度情報を流用していると主張する。
確かに,Aは,その証言において,原告CDDBと被告CDDBとの緯度経度情報につき,原告から本件訴訟の提起を受けて指摘を受けるまで,これらが同じであることを知らなかったが,原告の指摘を受けたことから,交差点が中心になるようにマウスでクリックをして位置決めをして,数値の入れ直しをした結果,緯度経度情報が異なるに至ったとするところ(証人A尋問調書20頁),新たに位置決めをして数値を入れ直したとする証言の信用性については,前記のとおりAの証言自体の信用性からして疑問は残るものの,結果としては10%を切る一致率となっていること,被告CDDB(新版)の地点マスタのレコード数は別紙4のとおり2万3000件余りであり,原告主張のレコードの一致率も,原告CDDBが保有する1万2000件余りの地点に関する緯度経度情報に関し,同一の地点がこのうちいくつ被告CDDB(新版)にあるかを探し,それについて,緯度経度情報が一致する率を調べた結果が10%を切る,としているものであるから,その一致する地点の範囲で緯度経度情報の数値が例えプラスマイナス10秒の間に90%が入るものとしても,地点に関する緯度経度情報の全体からみた場合には,緯度経度情報が重複している割合が多いとは認められないというべきである。
したがって,原告の上記主張は採用することができない。
カ 被告CDDB(新版)についての結論
以上によれば,被告CDDB(新版)については,原告CDDBの複製物ないし翻案物に該当しないというべきである。
3  争点(2)(被告らによる著作権〔複製権,翻案権,譲渡権,貸与権,公衆送信権,送信可能化権〕侵害についての共同不法行為の成否)について
(1)  前記のとおり,被告CDDB(当初版・2006年版),被告CDDB(現行版)は原告CDDBの複製物であり,原告CDDBについて原告が有する複製権を侵害するものと認められる。
証拠(甲51)によれば,被告アゼスタは,原告CDDBの複製物である被告CDDB(当初版・2006年版),被告CDDB(現行版)を顧客に対してCD等を用いて販売するほか,被告CDDBを含む被告システムにつき,インターネットを通じてオンラインアップデート等の行為を行っており,また,被告CDDBを含む被告システムについて,リース等も行っていると認められるから,被告アゼスタは,原告CDDBについての譲渡権,貸与権,公衆送信権,送信可能化権を侵害している。
そうすると,請求の趣旨第1項のうち,原告が,被告アゼスタに対し,著作権法112条1項に基づき,被告CDDB(当初版・2006年版),被告CDDB(現行版)に関する,別紙被告物件目録1ないし21記載の物件について,複製,頒布,公衆送信(送信可能化を含む)の差止めを求める部分については理由がある(主文第1項)。
これに対し,請求の趣旨第1項のうち,原告が,被告らに対し,被告CDDBの翻案の差止めを求める部分については,データベースである被告CDDBを翻案する行為には広範かつ多様な態様があり得るところであるから,原告の請求は差止めの対象となる具体的な行為を特定することなく,多様な態様を含みうる翻案行為の全てを差止めることを求めるものであり,内容の限定されない態様を含むものとして,本件において,その差止めの必要性を認めることはできない。
そうすると,請求の趣旨第1項のうち,被告らに対し,被告CDDBの翻案の差止めを求める部分については理由がないというべきである。
(2)  請求の趣旨第1項のうち,被告アゼスタ以外の個人被告らに対しても,被告CDDB(別紙被告物件目録1ないし21について)の複製等の差止めを求める部分については,まず,被告Y5については,平成20年6月に被告アゼスタを退社し,その後の職業については不明であるものの,被告システムの複製や販売等に関与している旨の証拠もないから,被告Y5に係る差止請求については理由がないというべきである。
また,その余の個人被告らに対する差止請求についても,それら被告が個人として,原告CDDBを複製し,頒布し,公衆送信(送信可能化を含む)をしたものと認めるべき証拠はないから,請求の趣旨第1項のうち,個人被告らに対し,被告CDDB(別紙被告物件目録1ないし21について)の複製等の差止めを求める部分についても理由がないというべきである。
(3)  そして,前記によれば,原告の請求の趣旨第2項にかかる著作権法112条2項に基づく廃棄等請求のうち,被告アゼスタに対し,被告CDDB(当初版・2006年版),被告CDDB(現行版)に関する,別紙被告物件目録1ないし21記載の物件についての各データベースを格納したCD-ROM等の記録媒体を廃棄し,同各データベースの記録内容の消去を命ずる部分については理由があり(主文第2項),その余については理由がないというべきである。
(4)  なお,著作権侵害の共同不法行為に基づく損害賠償の主張については,後記4のとおり,著作権侵害の予備的主張として一般不法行為の主張がされていることに鑑み,争点(3)(一般不法行為の成否〔著作権侵害についての予備的主張〕),争点(4)(原告の行為の独占禁止法違反の可能性の有無)についての判断の後,争点(5)(被告らの損害賠償義務の有無及び原告の損害額)の冒頭において,被告らの故意ないし過失の有無についての判断を行うこととする。
4  争点(3)(一般不法行為の成否〔著作権侵害についての予備的主張〕)について
(1)  原告は,著作権侵害についての予備的主張として,一般不法行為に基づく主張をしているところ,原告の主張する損害の算定時期は,平成18年6月から平成22年11月までで,その対象も,被告CDDB(当初版・2006年版),被告CDDB(現行版)を組み込んだ被告システムの販売に基づく損害を主張しており,被告CDDB(新版)の発売時期は平成23年4月以降であり,損害算定のための販売数に,被告CDDB(新版)を対象とはしていない。したがって,被告CDDB(新版)は,一般不法行為に基づく損害賠償請求の対象になっていないことは明らかであるが,なお,事案に鑑み,著作権侵害を認めない被告CDDB(新版)について,一般不法行為の成否についても検討し,判断を示すこととする。
原告は,原告が費用や労力をかけて開発し,制作した原告CDDBにつき,その多数の部分を流用して被告CDDBを販売する行為は,先行者の築いた開発成果にいわばただ乗りする行為であって,取引における公正かつ自由な競争として許される範囲を逸脱するものとして不法行為を構成するというべきであると主張する。
しかし,著作権法は,著作物の利用について,一定の範囲の者に対し,一定の要件の下に独占的な利益を認めるとともに,その独占的な利益と国民の文化的生活の自由との調和を図る趣旨で,著作権の発生原因,内容,範囲,消滅原因等を定め,独占的な利益の及ぶ範囲,限界を明らかにしていることからすれば,ある著作物が同法による保護を受ける著作物に該当しないものである場合,当該著作物を独占的に利用する権利は法的保護の対象とはならないものと解すべきであるから,著作権法による保護を受けない著作物の利用行為は,同法の規律の対象とする著作物の利用による利益とは異なる法的に保護された利益を侵害するなどの特段の事情がない限り,不法行為を構成するものではないと解するのが相当である(最高裁平成21(受)第602号・同第603号,同23年12月8日第一小法廷判決・民集65巻9号3275頁参照)。
この観点から本件を検討すると,前記認定事実によれば,原告CDDBについての著作権侵害が認め難い被告CDDB(新版)については,体系的構成及び情報の選択のいずれについても原告CDDBとの同一性ないし類似性が認められないところであり,その情報の選択における判断において示したように,被告CDDB(新版)においては,原告CDDBから流用した情報の割合は,相当程度に低下している。
確かに,原告の主張するとおり,被告CDDB(新版)においては,前記2記載のとおり,原告CDDBから流用したものと推認されるレコードが存するものの,被告CDDB(新版)において,総レコード数からみた場合のこれら流用レコードの割合も相当に低いものとなっている。
そうすると,原告が費用や労力をかけて作り上げた原告CDDBに関して主張する保護されるべき利益とは,結局,原告が著作権法によって保護されるべきと主張する法的利益,すなわち,原告CDDBの情報の選択方針や,情報内容それ自体といったアイデアや抽象的な特徴,ないし表現それ自体でないものに基づく利益と異なるものではないことになり,それらの点が著作権法によっては保護されないものであることは前記判示のとおりである。
また,本件全証拠を精査し,原告システムからのリプレースをも目的とした営業活動がされていることを勘案しても,被告らが被告CDDBを含む被告システムを販売し,収益を得る行為が殊更原告に損害を与えることを目的として行われたなどの自由競争の範囲を逸脱する行為であると認めるに足りる事実も窺われない。
そうすると,被告らが被告CDDBを販売等する行為には,著作権法の規律の対象とする著作物の利用とは異なる法的に保護された利益を侵害するなどの特段の事情は認められないというべきである。
したがって,被告らの上記行為については民法上の不法行為を構成するものではないと認めるのが相当であるから,著作権法上の請求が認められない被告CDDB(新版)に関して,一般不法行為の成立を理由に著作権侵害に係る損害と同額の損害の賠償を求める原告の予備的請求には理由がないというべきである。
(2)  また,原告は,被告らが原告CDDBをデッドコピーし,これに改変を加えて被告CDDB(新版)を制作したものであり,改変によってデッドコピーとは異なるものとなったとしても,それは社会的に許容される限度を超える行為であり,不法行為を構成するものであるとも主張する。
確かに,被告CDDB(新版)にも,いまだ原告CDDBからのコピーであると推認されるレコードも一部に存する上,被告らは,度重なる求釈明がされた後であり,本件訴え提起から3年以上が経過した後の,平成25年1月29日付け被告第22準備書面においても,原告CDDBのデータの一部を被告CDDBに利用する際のデータの入手経路を含む具体的態様については,認否を差し控える,などとしており,個人被告らの各陳述書ないし報告書(乙39ないし42)においても,何らこれらデータの入手経路について触れるところがなく,かえって,被告Y1は,平成21年9月18日付け陳述書において,「私どもは,被告データベースの設計・構築にあたって,自らの経験,ノウハウ等をもとに,実際に現場でデータベースを利用することになる取引先(利用者)からヒアリングを行い,現在使用中の出力帳票(…)のサンプルの提供を受け,書籍やウェブサイト等の様々な旅行関連資料とも照らし合わせながら,議論を重ねた上でデータ項目の洗い出し及びデータ収集を行って,独自に被告データベースを設計・構築しました。」,「私どもは,上記…のとおり,膨大な時間をかけて議論を重ね,独自の設計思想を確定して,文字どおりゼロから独自に被告データベースを設計・構築したのであり,原告から被告データベースの販売等の差止めを求められるような理由は全くありません。」などとしていた(乙2の1)にもかかわらず,被告Y5は,当法廷において,被告CDDBの開発当初は,ゼロから作成していたが,間に合わないことが分かったことから,原告CDDBのメンテナンスCDからデータをコピーすることとしたと供述し(被告Y5尋問調書16頁),上記被告Y1の陳述内容とは全く相反する供述をするなど,原告CDDBに依拠して制作された被告CDDBの制作過程は何ら明らかになっておらず,原告CDDBについて,そこから被告CDDBに流用したレコードの全貌も不明である。そして,被告システムは,原告システムからのデータ移行が可能なことをうたったリプレース販売の手法を主にとっていることから,被告らが,被告システムを,原告システムからのデータ移行が可能なシステムとしていかに構築したかについても,何ら被告らは明らかにせず,また,被告らの上記リプレースを主体とした営業方法について,上記被告システムの制作過程からすれば,明らかな自由競争の範囲内のものであるとまではいい難い面がないとはいえない。
しかし,前記(1)のとおり,被告らが被告CDDB(新版)を販売等する行為には,著作権法の規律の対象とする著作物の利用とは異なる法的に保護された利益を侵害するなどの特段の事情は認められないから,原告の不法行為に基づく予備的請求についても理由がないというべきである。
5  争点(4)(原告の行為の独占禁止法違反の可能性の有無)について
被告らは,原告システム及び被告システムのような,行程表・見積書の作成及び出力,売上・集計・顧客管理のトータルサポートを可能とする旅行業向けシステムを開発・販売している業者が原告と被告アゼスタの2社のみであり,寡占状況となっているとすれば,原告の本訴提起による被告CDDBの差止請求及び損害賠償請求は,原告1社による市場独占を企図するものと考えられ,公共の利益に反し一定の取引分野における競争を実質的に制限するものであるから,独占禁止法2条5項,3条に違反している可能性があり,原告の請求はこの点から速やかに棄却されるべきものである旨主張する。
独占禁止法2条5項は,「この法律において『私的独占』とは,事業者が,単独に,又は他の事業者と結合し,若しくは通謀し,その他いかなる方法をもってするかを問わず,他の事業者の事業活動を排除し,又は支配することにより,公共の利益に反して,一定の取引分野における競争を実質的に制限することをいう。」とし,同法3条は,事業者が私的独占等をしてはならないことを定めるものであるところ,そもそも,それらの規定に違反しているというのであればともかく,その可能性があるというのみで,原告の請求を棄却しなければならない法的根拠は不明といわざるを得ないばかりか,原告による本件訴えの提起は著作権法等に基づくものであるところ,独占禁止法21条は,同法の適用関係について,著作権法による権利行使には適用しないと規定しているのであって,本件全証拠を精査しても,原告による訴えの提起につき,同条の規定を排除すべき事情を認めるに足りる証拠はなく,その他原告による被告らに対する差止め及び損害賠償等の請求につき,その権利行使が許されないとする事情は何ら認められない。
したがって,被告らの上記主張は採用することができない。
6  争点(5)(被告らの損害賠償義務の有無及び原告の損害額)について
(1)  被告らの損害賠償義務の有無
前記のとおり,被告アゼスタは著作権侵害の不法行為責任を負うところ,以下,各個人被告らの損害賠償義務の有無について,検討する。
ア 被告Y1につき
被告Y1は,旧原告会社に在籍した経験はなく,データベースやシステムに関する専門知識はない。〔被告Y5尋問調書18,19頁〕
しかし,平成17年10月18日の被告アゼスタの設立に際しては出資金の過半を拠出してその代表者となり,Aが同年11月に被告アゼスタに入社した際には,常勤の役員,社員は被告Y1しかいない状態であったところ,その状況で,被告Y1は,Aとともに被告システムの制作に当初から携わってきている。被告Y5も,原告CDDBのデータをコピーするため,CDを利用するに当たっては,被告Y1と相談して決めたとしている。〔被告Y5尋問調書26,27頁〕
被告Y1は,被告システム販売開始当初から,旧原告会社の顧客に向けて,被告システムへのリプレースを勧める文書を送付していること(上記認定の乙52の記載内容)などからすると,被告Y1は,被告アゼスタの著作権侵害について共同不法行為を行ったものと認めることができ,上記認定事実によれば,被告Y1には,著作権侵害について少なくとも過失を認めることができる。
イ 被告Y2につき
被告Y2は,翼システムにおいて,主任として原告システムの会議にも参加し,その販売に関与しており,しかも,被告Y2は,翼システムへの転職前においても,旅行業者向けのトータル業務システムの販売業務に従事していて,旅行業務システム構築のノウハウを熟知していた者である。被告Y2は,被告アゼスタにおいても,営業を担当して営業グループのマネージャーであるほか,取締役にも就任しており,被告アゼスタの著作権侵害の共同不法行為を行ったものと認めることができる。上記認定事実によれば,被告Y2につき,著作権侵害について少なくとも過失を認めることができる。
ウ 被告Y3につき
被告Y3は,翼システムにおいて,営業担当として積極的に原告システムの会議にも参加して提言をし,その販売にも関与しており,被告アゼスタにおいても,著作権侵害の共同不法行為を行ったものと認めることができる。
上記認定事実によれば,被告Y3につき,著作権侵害について少なくとも過失を認めることができる。
エ 被告Y4につき
被告Y4は,翼システムにおいて,営業担当として原告システムの会議にも参加して,その販売にも関与しており,被告アゼスタにおいても,著作権侵害の共同不法行為を行ったものと認めることができる。上記認定事実によれば,被告Y4につき,著作権侵害について少なくとも過失を認めることができる。
オ 被告Y5につき
被告Y5は,被告アゼスタを平成20年6月に退社しているが,それまでは,被告CDDB(現行版)の開発に関与している。〔被告Y5尋問調書18頁〕
被告Y5は原告システム開発のリーダーであり,被告アゼスタ入社時期は遅いものの,被告システムの開発当初から積極的に関与しており,被告CDDBの販売開始から,被告Y5の被告アゼスタ退社の平成20年6月までの損害に関する著作権侵害の共同不法行為については責任を負うものと認められ,上記認定事実によれば,被告Y5には少なくとも過失が認められる。
カ 被告Y6につき
被告Y6は,翼システムにおいて,営業担当として原告システムの会議にも参加して,販売にも関与しており,被告アゼスタにおいても,著作権侵害の共同不法行為を行ったものと認めることができる。上記認定事実によれば,被告Y6につき,著作権侵害について少なくとも過失を認めることができる。ただし,被告Y6は,原告も,平成18年10月末までは原告システムの販売に関与してきたと主張しているところであるので,その時期以降の損害について,その余の被告らとの共同不法行為責任を認めるべきである。
キ 小括
以上によれば,個人被告らは,被告アゼスタの著作権侵害の不法行為について,共同不法行為を行ったものと認められるから,それぞれ損害賠償義務を負うこととなり,被告らは,原告が被告らの著作権侵害行為により被った損害を賠償すべき責任を負う。
(2)  著作権法114条1項に基づく損害額
ア 被告CDDBを含む被告システムの販売本数
(ア) 被告システム(旅 nesPro)には,Pro-1と Pro-2の二つのタイプがあると認められるところ,このうち Pro-1は,行程表・見積書作成機能のみのシステムであり,Pro-2は,Pro-1の機能に加えて売上・顧客管理機能が追加されたシステムである(甲25の2)。なお,売上・顧客管理機能は原告CDDBには含まれていない。
被告システムのバージョン毎の販売本数は,以下のとおりであると認められる。

そうすると,原告が,損害賠償として請求する期間は,平成18年6月から平成22年11月末までであるから,上記のうち,現行版については月数の割合を乗じることとして計算することにより,被告アゼスタの被告システムの販売本数を算定するのが相当である。その内容は,当初版・2006年版については上記販売本数の合計欄記載の以下の本数,現行版については,月数に応じた以下の計算による。
・22本(当初版)
・61本(2006年版)
・333÷49×44(現行版)≒299本
・合計 22+61+299=382本
以上のとおり,被告らは,上記合計382本の被告システムを販売したものとすべきである。
(イ) この点に関して原告は,被告らは,被告システムを平成18年6月から平成22年11月ころまでの間に少なくとも500本を販売したと主張し,それに沿う証拠として,甲53を提出する。
確かに,甲53には,被告代表者である被告Y1において,被告システムを平成22年11月29日までに,約500社に納入したかに読める記載がある。しかし,この文書は,新製品の案内として原告顧客に送付した文書であり,必ずしも正確な納入本数を反映した文書であるとは認め難く,また被告アゼスタの紹介の文書には,平成22年1月の時点において,被告システムの導入350社を達成した旨の記載があり(甲25の2),これは上記販売本数の認定と概ね相違しないことが認められる。
したがって,原告の上記主張は採用することができない。
イ 原告CDDBにつき,著作権法114条1項本文の「著作権者等がその侵害の行為がなければ販売することができた」といえるかについて
原告CDDBと被告CDDBとの代替関係(相互補完性)については,前記認定のとおり,顧客である旅行会社のニーズを分析した上で制作された原告CDDBと,被告CDDB自体の類似性に加え,被告らは,原告システムを使用する顧客の手持ちデータの移行が可能であることを宣伝して原告システムとのリプレース販売を仕掛け,原告顧客に対しても,被告アゼスタの設立当初から販売をしているものであるから,原告CDDBと被告CDDBとの間には代替関係を肯定することができる。
また,原告の供給能力についても,後記ウのとおり,原告は平成18年1月ないし同年12月までの1年間に,原告システムを132本販売していること,原告は,被告アゼスタよりも相当に事業規模が大きいことに照らせば,原告の供給能力には特段の問題は認められない。
ウ 原告の利益率について
(ア) 原告が,被告アゼスタの販売した被告CDDBを含む被告システムを追加的に販売したとした場合に,必要な経費を考慮した原告の利益率については,平成18年1月から同年12月の実績を基に,以下のとおり算定される。
原告の費目毎の経費は以下のとおりと認められ,これらについては経費として算入すべきである。
・ 仕入高:781万4000円
仕入高は,原告システムと関連するパソコン,プリンター等のハードウェアなどと一緒に販売する場合の仕入費用である。
・ 残債:108万5000円
残債は,原告システム販売時に,顧客の旧リース料を原告が負担する場合の費用である。
・ 販売手数料:250万4000円
販売手数料は,原告システム販売時に販売代理店に対し支払われる手数料である。
・ 販促費/リース料S:43万9000円
販促費/リース料Sは,原告システム販売時に,顧客の新たなリース料の一部を原告が負担する場合の費用である。
・ 販促費/その他:39万6000円
販促費/その他は,原告システムの販売促進活動にかかる成約記念品等の費用である。
・ 外注費:678万2000円
外注費は,原告システムの開発及びメンテナンスなどについての外部委託費用である。
・ 物流費:188万3000円
物流費は,原告システム等の出荷に伴い発生する運送費用である。
・ インセンティブ:1592万9000円
インセンティブとは,原告システム販売担当営業員に販売額に応じて支払われるインセンティブ費用である。〔以上,甲77〕
以上の合計額は,3683万2000円となる。
(イ) 以下の経費については控除すべきものとは認められない。
・ 広告宣伝費:112万5000円・ その他管理費:5332万9000円
(ウ) 次に,仮に被告が販売した量の原告システムを原告が追加的販売に要した場合の人件費については,以下のとおりである。
原告システムの売上高は,甲69の売上高欄のうち,「内ソフト」の欄の記載金額によるべきと認められるから,2億1257万8000円となり(甲69),同じく甲69によれば,原告システムの単価は167万9000円,平成18年1月ないし12月の原告システムの販売本数は132本(ただし,基本タイプ〔TR-P1,TR-P3,TR-P4〕のほか,モバイルタイプTR-P1M,子機セットTR-P1L,TR-P4Lの販売台数を含むとし,これらの販売台数の内訳は明らかではないが,これらを合算した上記販売本数によるのを相当と認める。)となる。
原告において,旅行部門に携わる人員は,営業部門につき営業4人,アフター3人,スタッフ1人,開発部門に1人,本社スタッフ1人の合計10人である。〔甲69〕
そうすると,原告の人件費は,甲69によれば6561万9000円と認められるところ,被告アゼスタの販売本数が平成18年6月から平成22年11月末までの4年6か月で382本であると認められるから,
382÷54×12=84(本,年平均)となる。
原告の販売本数について,その内訳は明らかでないものの,上記のとおり売上本数は132本とするものとし,上記84本を販売するのに必要な追加的人件費は,以下のとおりの式で計算される。
6561万9000円×営業部門人数8人÷全体10人×84÷132≒3340万6000円
そうすると,必要な追加的人件費は,3340万6000円となる。
(エ) 上記追加的人件費を,経費に加え,原告の限界利益を算出する。
上記を前提とした原告の限界利益率は以下のとおりとなる。
2億1257万8000円÷132本=161万0439円
〔2億1257万8000円-(3683万2000円+3340万6000円)〕÷132本=1億4234万円÷132本=107万8333円
161万0439円-107万8333円=53万2106円
53万2106円÷161万0439円=0.3304
以上によれば,原告の限界利益率は33%であると認められる。
エ 著作権法114条1項ただし書の事情の有無
被告らは,原告システムは,長年にわたり十分なバージョンアップないしバックアップもされていないのに対し,被告システムにおいては,頻繁なバージョンアップや,旅行業に熟練した社員らによるバックアップ等が充実していたことにより,販売の実績をあげてきたものであり,それに相当する相応量の販売数量は,原告が販売することができないとする事情に該当する旨主張する。
確かに被告らは,頻繁なバージョンアップを行っており,被告Y2,被告Y3,被告Y6らは,旅行業システムに長年携わり,多くの知識を有するものと認められるが,原告側において,被告らに比べ,十分なシステムサポート体制等がとられていないことを認めるに足る的確な証拠はないし,また被告主張の事情により,被告システムの販売が特段に伸びたものと認めるべき証拠もない。
したがって,被告らの上記主張は採用することができない。
オ 寄与率
原告CDDBは,別紙原告物件目録記載のとおり,原告システムの一部であるところ,原告は,損害額算定に当たって,原告システム全体の販売価格を基準としているから,原告システムにおける原告CDDBの寄与率を考慮すべきこととなる。
原告CDDBは原告システムのうちの検索及び行程作成業務用のデータベース部分であり,原告システムのうちの,基本システムであるTR-P1は,検索業務,行程表・見積書作成,インターネット連動,地図連動機能を含むものであるから,TR-P1の販売価格(システム価格170万円)を基準とすれば十分であり,TR-P1に売上集計管理,顧客管理機能を加えたTR-P4を基準とすべき理由はない。
そして,前記第2,1(2)のとおり,原告システムのカタログ(2009年〔平成21年〕版)によれば,検索業務,行程・見積作成の各機能の内容としては,検索業務は時刻表検索,観光施設検索,宿泊施設検索,道路料金経路検索,インターネット検索,画像保存,地図検索を含むもの,行程・見積作成は行程表作成,見積書作成,損益検討書作成,受注型企画旅行見積書,包括見積書作成,修学旅行見積書,利用施設一覧印刷,観光施設案内書印刷,宿泊施設案内書印刷,添乗指示書作成,現地払い見積書,契約書(受注型・手配型),Mail送信(PDF),画像付き行程表出力を含むものであるから,このうち時刻表検索,インターネット検索,画像保存,地図検索,見積書作成,損益検討書作成,受注型企画旅行見積書,包括見積書作成,修学旅行見積書,利用施設一覧印刷,観光施設案内書印刷,宿泊施設案内書印刷,添乗指示書作成,現地払い見積書,契約書(受注型・手配型),Mail送信(PDF),画像付き行程表出力等の機能については,原告CDDBとは無関係の機能である。
これらを総合考慮すると,原告CDDBの原告システム(TR-P1)における寄与率は50%と認めるのが相当である。
そうすると,原告CDDBに係る損害は1本当たりの販売価格に寄与率,利益率を乗じて,これに販売本数を乗じることにより,以下のとおり計算される。
170万円×0.5×0.33=28万0500円
28万0500円×382本=1億0715万1000円
カ 原告の主張に対する判断
原告は,原告システムについてのデータメンテナンス契約についての損害の賠償を請求するので,以下,この点につき判断する。
データメンテナンス契約は,原告システムを導入するユーザーとの間で,毎月ユーザーに更新データを提供するための契約であり,月額6000円で提供されているとするものである。〔甲77,5頁〕
しかし,データメンテナンス契約自体は,原告CDDBにかかる著作権侵害と相当因果関係を欠き,著作権侵害に基づく損害賠償請求の範囲に入るものとは認められない。
したがって,原告の上記主張は採用することができない。
キ 被告らの主張に対する判断
(ア) 被告らは,旅行業者向けシステムには,「応援団くん」等同種のものが複数あり,被告システムの販売と原告の損害との因果関係が存しないと主張するが,既に検討したとおり,それらは,原告CDDBとは内容的に異なるものであり,むしろ,原告システムと被告システムとは相互補完関係にあると認められることは前記のとおりである。
したがって,被告らの上記主張については採用することができない。
(イ) 被告らは,被告システムの方が,レコード数が豊富であること,データメンテナンス及びサポート体制が充実していること,担当個人被告らの経歴・ノウハウの存在等により,これら体制が優れていること,原告CDDBとの不一致部分が被告システムの販売に寄与していること,データベース以外の部分が被告システムの販売に寄与していること等を理由として,著作権法114条1項ただし書の事情が認められると主張する。
確かに,レコード数については別紙4のとおり,被告CDDB(現行版)においては,原告CDDBと比して多くのレコードを格納しているといえるものの,被告CDDB(当初版・2006年版)においては,原告CDDBと大差はない。また,被告CDDB(現行版)において増加したレコードも,その多くが「39区間料金マスタ」テーブルにかかるものであるところ,これらにはインターネットから入手可能な高速道路情報等もあること,被告らの主張によっても,もともと被告らは原告CDDBから多くのデータをコピーするなどし,しかも前記認定のとおり,被告CDDBには原告CDDBからコピーしたままのデータが多数存在し,原告CDDBからコピーしたデータを安易にそのまま利用したものを基に,これを充実させてきたものともいえること,そもそも原告の顧客におけるニーズやその契約期間を被告らにおいて把握した上で,そのリプレースを前提として原告CDDBのデータを利用して短期間に開発したことによる廉価販売が被告アゼスタの売上げに貢献しているともいえること等を総合考慮すると,本件において,著作権法114条1項ただし書の事情があると認めることはできないというべきである。
したがって,被告らの上記主張はいずれも採用することができない。
(ウ) 被告らは,被告システムの販売において,被告らが提供するバス運行管理システムとのセット販売の分については,原告の損害との相当因果関係を欠くものと主張する。
しかし,前記1で認定したとおり,被告アゼスタがバス運行管理システムである「バス快道」を発売したのは,本件訴え提起後の平成21年10月のことであるから,被告が乙43において,2006年版についての販売本数を計上していることについてはそもそも疑問があるほか,バス運行管理システムの導入が増えたのは平成24年のゴールデンウイークに発生した事故が契機となっているとする(乙40,9頁)ところからすると,原告の求める損害賠償期間(平成18年~22年)とも重ならないから,そもそも主張の前提を欠くものである。
したがって,被告らの上記主張は採用することができない。
(エ) 被告らは,原告システムは値引き販売を行うことが常態となっているから,損害の計算もそれを基礎として算定すべきであると主張し,それに沿う証拠として,乙36の1ないし26を提出する。
しかし,乙36の1ないし26は見積書のうちのごく一部であって,これを保存していたパソコンも現存しない(被告Y2尋問調書27頁)というのであるから,上記証拠は不十分であって,他に翼システムないし旧原告会社において値引き販売が常態化していたものと認めるべき的確な証拠はないし,原告CDDBについての著作権侵害に基づく損害については,TR-P1の販売価格である170万円を基準としてそこに寄与率等を乗じることにより適正に評価されていると認められるから,原告の損害を上記算定方法により行うことに特段の問題は認められない。
したがって,被告らの上記主張は採用することができない。
(3)  弁護士費用
被告らのうち,平成18年6月から平成22年11月までの著作権侵害の不法行為と相当因果関係のある原告の弁護士費用相当額の損害は,事案の性質,認容額,主張立証の難易度等の事情に鑑み,500万円を下らない。
(4)  個人被告ら各人毎の損害賠償責任を負う範囲についての判断
ア 被告Y1,被告Y2,被告Y3及び被告Y4について
被告Y1,被告Y2,被告Y3及び被告Y4の損害賠償責任については,原告の主張する損害期間の全範囲にわたるから,弁護士費用を加算して,以下の式の通りとなる。
1億0715万1000円+500万円=1億1215万1000円
イ 被告Y5について
(ア) 被告Y5は,平成20年6月に被告アゼスタを退社しているから,被告CDDB(現行版)については月数に応じ,それまでの間の原告の損害を計算すべきである。
・22本(当初版)
・61本(2006年版)
・333÷49×15(現行版)≒101本
以上の合計184本の被告システムの売上げに関する損害について,賠償責任を負うとすべきである。
28万0500円×184本=5161万2000円
(イ) そうすると,被告Y5が責任を負う弁護士費用の範囲は400万円とするのが相当である。
(ウ) 以上の合計は5561万2000円となる。
ウ 被告Y6について
(ア) 被告Y6は,平成18年10月まで旧原告会社で営業を担当したが同月退職したとし(乙42),その後被告アゼスタに入社しているところ,旧原告会社の退社の日が平成18年11月30日となっていることからして,被告CDDBの2006年版以降の販売に係る分については責任を負うものとして損害を計算すべきである。
・61本(2006年版)
・333÷49×44(現行版)≒299本
以上の合計360本の被告システムの売上げに関する損害について,賠償責任を負うとすべきである。
28万0500円×360本=1億0098万円
(イ) そうすると,被告Y6が責任を負う弁護士費用の範囲は450万円とするのが相当である。
(ウ) 以上の合計は1億0548万円となる。
エ 被告Y5と被告Y6との損害賠償債務の連帯の範囲について
被告Y5と被告Y6との損害賠償債務についての連帯の範囲は,両者の責任が併存する期間に応じることとなり,被告CDDB(現行版)の販売数についての重なり合う期間は15か月分となることから,以下のとおり計算される。
・61本(2006年版)
・333÷49×15(現行版)≒101本の合計162本分
28万0500円×162本=4544万1000円
これと重なり合う弁護士費用400万円の合計4944万1000円の範囲で連帯責任を認めるべきである。
オ 遅延損害金の起算点について
遅延損害金の起算点については,原告は,当初,平成18年6月から訴え提起時である平成21年5月15日までの損害賠償金として5億5349万6000円(うち弁護士費用相当額2000万円)及びこれに対する訴状送達の日の翌日以降の日である平成21年5月28日から支払済みまで年5分の割合による遅延損害金の支払を求めていたところ,平成23年10月7日付け訴えの変更の申立書により,損害算定の期間を,現状の平成22年11月分までを含むものとして請求額も6億7208万9600円に拡張し,遅延損害金については,うち5億5349万6000円に対する平成21年5月28日から,うち1億1859万3600円につき上記平成23年10月7日付け訴えの変更の申立書送達の日の翌日である平成23年11月2日から各支払済みまで民法所定の年5分の割合による遅延損害金の支払を求める内容に変更した。
したがって,被告CDDBを含む被告システムの販売に係る遅延損害金の起算点については,平成21年5月15日までの販売に係る分については平成21年5月28日から,平成21年5月16日以降平成22年11月までの販売に係る分については平成23年11月2日からとすべきである。
そして,前記認定のとおり,被告システム(現行版)の販売本数は平成19年4月から平成22年11月末までの44か月分として299本とすべきところ,これを平成19年4月から平成21年5月15日までの25.5か月分と平成21年5月16日から平成22年11月末までの18.5か月分とに割り振ることになる。
そうすると,平成19年4月から平成21年5月15日までの分は,
299本×25.5÷44≒173本
平成21年5月16日から平成22年11月末までの分は
299本×18.5÷44≒126本
となる。
平成19年4月から平成21年5月15日までの損害分の計算は,当初版(22本),2006年版(61本)の本数と合算して,
28万0500円×(22+61+173)=7180万8000円となる(このうち,被告Y6が責任を負うべき分は,28万0500円×(61+173)=6563万7000円である。)。
これと弁護士費用相当額500万円を合算すべきこととなり(弁護士費用については一括して算入するのを相当とする。以下同じ。),その合計は,7680万8000円となる。
また,平成21年5月16日から平成22年11月末まで損害分の計算は,
28万0500円×126=3534万3000円となる。
個人被告らのうち,被告Y6,被告Y5については関与の時期に対応して,被告Y6については,認容額のうち7013万7000円(上記7180万8000円のうち,被告Y6が責任を負うべき損害に相当する6563万7000円と,被告Y6について相当な弁護士費用450万円の合算額)については平成21年5月28日から,うち3534万3000円については平成23年11月2日から起算すべきこととなり,被告Y5については,認容額全額につき,平成21年5月28日から起算すべきこととなる。
7  結論
以上のとおりであり,原告の請求は,主文掲記の限度で理由があるから,その限度で認容し,その余の請求は理由がないから棄却することとし,仮執行宣言については主文第1項,第3項ないし第5項については相当であるので付することとし,別紙被告物件目録1ないし21記載のデータベースを格納したCD-ROM等の記録媒体の廃棄,データベースの記録内容の消去を命ずる主文第2項について仮執行宣言は相当でないので付さないこととして,主文のとおり判決する。
(裁判長裁判官 東海林保 裁判官 今井弘晃 裁判官 足立拓人)

別紙

*******

関連記事一覧

  • コメント ( 0 )

  • トラックバックは利用できません。

  1. この記事へのコメントはありません。


Notice: Undefined index: show_google_top in /home/users/1/lolipop.jp-2394bc826a12fc5a/web/www.bokuore.com/wp-content/themes/rumble_tcd058/footer.php on line 296

Notice: Undefined index: show_google_btm in /home/users/1/lolipop.jp-2394bc826a12fc5a/web/www.bokuore.com/wp-content/themes/rumble_tcd058/footer.php on line 296