ｆダミーデータの選択の同一性
被告ＣＤＤＢの当初版・２００６年版と現行版には，原告ＣＤＤＢにおけるダミーデータ『ダミーデータ「＊＊＊」（道路名），「ﾝﾀﾞﾐｰ」（道路名の読み）』が格納されている（甲２１）。かかるダミーデータを格納するかどうかは原告ＣＤＤＢにおける個性が表れているという意味で創作性ある情報の選択の一つであるところ，被告ＣＤＤＢではこれと同一の情報の選択を行っている。
(ｴ)小括
上記のとおり，被告ＣＤＤＢは当初版・２００６年版，現行版，新版のいずれにおいても，原告ＣＤＤＢの体系的構成及び情報の選択において創作性ある部分と同一であるか少なくとも類似している。
なお，著作物の全部でなくとも著作物の創作性ある部分を複製すれば，著作権侵害は成立する。データベースの著作物でもこの理は同じである。昭和６０年９月の著作権審議会第七小委員会（データベース及びニューメディア関係）報告書でも，複製に関して「従来から複製権は著作物の全体的な複製だけでなく，その一部分であっても，著作物としての価値を持ち得る部分である限り，その部分にも及ぶと解釈されてきたところである。データベースにこの解釈を適用すると，著作物としての価値を持ち得るような形で，情報をある程度のまとまりで複製することについては複製権が及ぶと考えられる。」としており，データベースの一部複製等についても，データベースの著作者の複製権等が及ぶことは明らかである。
なお，被告らは著作権侵害及び一般不法行為が成立しないことの事情として被告システムの優位性を主張する。
しかし，著作権侵害及び一般不法行為の成立とシステムの優位性は関係がない。仮に被告システムに優位性があったとしても，被告ＣＤＤＢが原告ＣＤＤＢに依拠し類似性があるものであれば著作権侵害が成立するし，多大な労力費用をかけて開発された原告ＣＤＤＢを流用した被告ＣＤＤＢを含む被告システムを，原告ＣＤＤＢを含む原告システムの販売地域と競合する地域に販売する行為は一般不法行為に該当するというべきである。このことは被告システムに優位性があろうとなかろうと変わりがない。したがって，被告らの優位性に関する主張は失当である。
イ依拠性
原告ＣＤＤＢと被告ＣＤＤＢとは，データベースとしての表現において，実質的な同一性ないし類似性が認められ，アクセス可能性やデッドコピーされた具体的痕跡からして依拠性があることは明らかである。被告ＣＤＤＢの開発者であるＡ及び被告Ｙ５が，翼システムあるいは翼システムから営業譲渡を受けた後は旧原告会社等において原告ＣＤＤＢの開発に従事していたこと，被告Ｙ３，被告Ｙ２，被告Ｙ４，被告Ｙ６が，原告等において営業担当者として原告システム用の提供データベースである原告ＣＤＤＢ等を常に持ち歩き，顧客に対する原告ＣＤＤＢ等のインストール作業に従事していたこと，Ａ，被告Ｙ５，被告Ｙ３，被告Ｙ２，被告Ｙ４，被告Ｙ６が，原告等を退職した後，ごく短期間で膨大なデータベースの体系的構成及びデータよりなる被告ＣＤＤＢを開発して販売を行っていること，並びに，被告ＣＤＤＢには原告ＣＤＤＢをデッドコピーした痕跡が新版に至るまで多数残されていることなどに鑑みると，Ａ及び被告Ｙ５は，原告ＣＤＤＢの内容を設計レベルのコアとなる情報まで正確に認識した上で，これに依拠して被告ＣＤＤＢを作成したものであると認められる。
この点に関して被告らは，一旦ＣＳＶ（Character-SeparatedValues）ファイルに抽出した上で，被告ＣＤＤＢに入力したと主張するが，ＣＳＶファイルに一旦出力した後に被告ＣＤＤＢに入力したのであれば本来不都合が生じる「,(カンマ)」，「"(ダブルクォート）」等が含まれているデータのデッドコピーについても，何ら不都合を生じさせることなくデータ移行を行っていることに鑑みて，被告らの主張は明らかに不合理なもので到底信用することはできない。被告らは当初版・２００６年版において，原告ＣＤＤＢのデータを原告ＣＤＤＢのテーブルＩＤ，フィールドＩＤと同一あるいは酷似したテーブルＩＤ，フィールドＩＤとする被告ＣＤＤＢの各テーブル，フィールドにデッドコピーして移行させ，その後現行版，新版において改変等を行ったものである。また，被告らは，ＣＳＶファイルに抽出した後に，一般のホームページや市販のＤＶＤソフト等に掲載されている情報を閲覧，参照等しながら手作業による追加・修正・削除を行い，そのような作業を行った後に被告ＣＤＤＢに入力したと主張するが，一般のホームページや市販のＤＶＤソフト等に掲載されている情報を閲覧，参照等しながら手作業による追加・修正・削除を行うことはできないし，そもそも対比すべき正しいデータは存在しない。むしろ，各施設の緯度経度情報やコード体系などをデッドコピーしていること，原告ＣＤＤＢの道路テーブルにおける道路名フィールドで「＊＊＊」，道路名カナフィールドで「ﾝﾀﾞﾐｰ」として登録されているデータがそのまま被告ＣＤＤＢにも登録されていたことを含めデッドコピーの痕跡が存在する理由を被告らが何ら説明できない項目があることなどに鑑みて，被告らの主張は明らかに不合理なもので到底信用することはできない。被告らは当初版・２００６年版において，原告ＣＤＤＢのデータを原告ＣＤＤＢのテーブルＩＤ，フィールドＩＤと同一あるいは酷似したテーブルＩＤ，フィールドＩＤとする被告ＣＤＤＢの各テーブル，フィールドにデッドコピーして移行させ，その後現行版，新版において改変等を行ったものである。


このように，被告ＣＤＤＢへのデータの収録過程について，ＣＳＶファイルを経由して，エクセル上で一般情報をもとに目視，手作業で追加・修正・削除を行ったとする被告らの主張は，極めて不合理である。被告らは，原告の指摘のうちのタブ区切りの点のみ反論するが，その余は認否も反論もない。タブ区切りの点についても，データ移行に際して対象テーブルの全データを打ち出して，カンマやダブルクォートが含まれているかを確認し，含まれていない場合はカンマ区切りのＣＳＶで，含まれている場合はタブ区切りのＴＳＶで抽出するという被告ら主張の方法は，かなり手間暇のかかる作業であり，現実的でなく，信用できない。
〔被告らの主張〕
(1)原告ＣＤＤＢの著作物性について
そもそも，データベースにおいてはその作成目的や利用対象が同一である限り，その信頼性を維持するため，選択される情報は客観的基準に従ってある程度機械的に収集・選択されることになり，情報の選択について，データベース創作者の創作性が反映する可能性は制限される（乙２８）。つまり，収集方針，選定基準というのは，一般的にはシステムの記憶容量が小さい時や，規模に制約のあるデータベースには重要であるが，規模が大きく真に利用価値のあるデータベースほどその重要性がなくなり，場合によっては不必要となるものである。
一方，体系的な構成についても，データベースが最大限活用されるためには，フォーマットの作成や体系設定は「没個性」的でかつ標準的な「汎用性」のあるものが望ましく，ユーザーの習慣性や効率性等を追及すれば一つの標準的な技術に収斂していく傾向があり，情報を網羅した完璧なデータベースであるほど創作性を認める余地は少なくなってしまうのであり，逆に，フォーマットや体系設定が個性的ということになれば，その分データベースの利用を狭めることになってしまうのである。原告の指摘する昭和６０年９月の著作権審議会第七小委員会報告書においても，「没個性」，「汎用性」を指向するデータベースの特質などから，データベースについて創作的行為とすることのできない場合がかなりあるとの指摘がされている。
また，下級審裁判例（東京地裁平成１２年３月１７日判決・判例時報１７１４号１２８頁。いわゆるＮＴＴタウンページ事件）においても，データベースにおける情報の選択，体系的な構成の基準となる創作性に関しては，当該データベースの目的・性格が考慮され，データベースの利便性向上のため，作成者として当然行うべき情報の選択はデータベース著作物の創作性については考慮されないことを明確にしたと解されている（乙２８）。実質的にも，データベースについて創作性の程度を低く設定すると，先行データベースの創作者が情報の体系的構成に創作者なりの何らかの構成を反映してデータベースを作成すると，後発者は同一の体系的構成からなるデータベースを制作できないだけでなく，当該データベースの一部を構成する情報の集合体を利用する場合にも当該部分で先行者の体系的構成における創作性が反映されていれば，先行データベースの一部複製とされるおそれがあり，データベースの自由な開発や情報の自由な利用が阻害されるから，この意味でも，データベースの創作性の程度を低く解すべきではない。
以上を踏まえると，原告が原告ＣＤＤＢの特徴的部分，すなわち創作性のある部分であると主張する，観光施設テーブルの格納情報，ホテル・旅館テーブルの格納情報，行程表作成のために必要なテーブル，フィールド及びリレーションの設計などは，いずれも，旅行業者向けの行程表作成を目的としたデータベースという性質上，作成者として当然考慮すべきものであり，その情報の選択や体系設定はいずれも客観的・標準的な基準に従った没個性的・汎用的なものにすぎないから，仮にこれらの作業が相当程度の資本・労力の投下を要するものであったとしても，創作性は認められない。このようなものに安易に著作物性が認められれば，旅行業者向けのデータベースは，原告以外におよそ制作できないことになり，競争原理が全く機能せず，一社に市場を独占させる結果となり，利用者にとっての利便性向上を著しく阻害する。したがって，原告ＣＤＤＢは著作物として保護されるべき創作性を有しておらず，原告ＣＤＤＢには著作物性がない。
(2)被告ＣＤＤＢが原告ＣＤＤＢの複製ないし翻案に当たらないことについてア被告アゼスタが，原告ＣＤＤＢのデータの一部を被告ＣＤＤＢに利用したことは認めるが，以下個別に詳述するとおり，それは，被告ＣＤＤＢの作成過程において，原告ＣＤＤＢのデータの一部について，一旦エクセルで読み込めるファイル形式であるＣＳＶファイルで抽出するなどした上で，これらのデータに適宜追加・修正・削除を加えて，それを被告ＣＤＤＢに収録，利用したり，一旦ＣＳＶファイルに抽出した上で，一般のホームページや市販のＤＶＤソフト等に掲載されている情報を閲覧，参照等しながら手作業による追加・修正・削除を行い，そのような作業を行った後に被告ＣＤＤＢに入力したものである。そのため，特段修正・削除を要しなかった箇所や修正漏れがあった箇所などについて，結果的に原告ＣＤＤＢのデータと同一のものが被告ＣＤＤＢに収録されている場合もあるが，これらのデータには，被告アゼスタにおいてホームページ等により情報の正確性等を確認したものも含まれている以上，原告ＣＤＤＢのデータと同視されるべきものとはいえないのであって，被告アゼスタは，原告ＣＤＤＢのデッドコピーなどしていない。
また，被告Ｙ３，被告Ｙ２及び被告Ｙ４などの営業担当者は，原告システムのインストール用ＣＤを所持し取り扱うことは会社から一切許されておらず，管理も厳重であったため所在すらもわからなかった。納品などのインストール作業はサポート部門に依頼するという厳格な社内ルールがあったため，上記の者らが手にしたことなど一度もなかった。
(ｱ)当初版の被告ＣＤＤＢのデータについて
被告アゼスタは，当初版の被告ＣＤＤＢを開発するにあたり，独自に収集したデータに加えて，原告ＣＤＤＢのデータの一部を，以下のように修正等の加工を施した上で利用した。
a施設関係データ
(a)観光施設データ


原告ＣＤＤＢ（２００５年１１月版）の観光施設データのうち，市販の料金ガイドに掲載されている観光施設（約１万４０００件）について，一旦エクセルで読み込めるファイル形式（ＣＳＶファイル）で抽出した上で，公式ホームページや一般ホームページ（「ヤフー電話帳」等），料金ガイド等により，最新の情報（名称，名称カナ，郵便番号，電話・ファックス番号，住所）を確認し，適宜追加・修正・削除を加えた。また，原告ＣＤＤＢでは，テーブル，フィールド等の変更なく，観光施設テーブル及び観光施設備考テーブルに登録できる観光料金の種類が非常に限られた種類の固定的な設定となってしまっており，複雑な料金体系を採用している観光施設に柔軟に対応できていなかった。すなわち，原告ＣＤＤＢでは，１施設レコードについて，個人・団体ごとに，小学生／中学生／高校生／大人の４項目について，それぞれ４種類の料金しか登録できなかった。しかし，実際には，東京ディズニーランドのように，個人であっても，１デーパスポートからスターライトパスポートまで６種類の料金設定がされていたり，また小学生／中学生／高校生／大人の区別だけではなく，さらに大学生／シニア／障害者等の各属性に応じて細かく料金が異なっている施設や，通常の団体料金とは別に修学旅行等の場合に適用される特別な団体料金（学校団体料金）が設定されている施設も存在しており，原告ＣＤＤＢはこのような施設の料金情報を十分反映できておらず，顧客のニーズに合致していなかった。
そこで，被告ＣＤＤＢは，テーブル，フィールド等の変更なく，このような施設の複雑な料金体系をも正確に反映できるように適宜データを加工・修正した上で被告ＣＤＤＢ（「施設マスタ」，「観光マスタ基本」，「観光料金マスタ」）に機械的に移行入力したが，このような詳細な料金情報は料金ガイドにも掲載されておらず，各施設の公式ホームページ等により料金体系の種類・内容の詳細を１件ずつ確認して加工・修正作業を行わなければならないため，多大な労力を必要とした。
また，自然・神社等（山，川，湖沼，渚，城，神社，滝，温泉，海岸，寺，スキー場，公園）のデータ（約４５００件）については，一般ホームページや市販のＤＶＤソフト「プロアトラス２００２日本の風景１０００」より最新の情報（名称，名称カナ，郵便番号，電話・ファックス番号，住所）を確認して，データを手入力し，さらに，原告ＣＤＤＢ（２００５年１１月版）のデータの一部についても，ＣＳＶファイルで抽出し，一般ホームページより最新の情報（名称，名称カナ，郵便番号，電話・ファックス番号，住所）を確認し，適宜データに追加・修正・削除を加えた上で，被告ＣＤＤＢ（「施設マスタ」，「観光マスタ基本」，「観光料金マスタ」）に機械的に移行入力した。
もっとも，顧客への被告システムの出荷（平成１８年６月末ころ販売開始）にあたり，平成１７年１１月以降急ピッチで進められていた被告ＣＤＤＢの開発作業が間に合わなかったこともあり，原告ＣＤＤＢの観光施設データのうち，神社仏閣，ゴルフ場，食事処，ドライブイン，温泉地等に関するデータを中心に，被告ＣＤＤＢ（「施設マスタ」，「観光マスタ基本」，「観光料金マスタ」）にコピーした上で，誤記等の修正を加えた。
(b)宿泊施設データ
原告ＣＤＤＢ（２００５年１１月版）の宿泊施設データのうち，「ホテル」区分，「旅館」区分，「その他」区分の「公共の宿」（国民宿舎等）のデータ（約９４００件）についても，ＣＳＶファイルで抽出した上で，公式ホームページや一般に公開されているホームページ（「ヤフー電話帳」等）等により，最新の情報（名称，名称カナ，郵便番号，電話・ファックス番号，住所）を確認し，適宜追加・修正・削除を加えた上で，被告ＣＤＤＢ（「施設マスタ」，「旅館マスタ基本」）に機械的に移行入力した。また，観光施設データと同様に，顧客への被告システムの出荷にあたり，被告ＣＤＤＢの開発作業が間に合わなかったこともあり，原告ＣＤＤＢの宿泊施設データのうち，ビジネスホテルに関するデータを中心に，コピーして被告ＣＤＤＢ（「施設マスタ」，「旅館マスタ基本」）に入力した上で，誤記等の修正を加えた。
b交通関係データ
被告ＣＤＤＢは，鉄道・路線バス・飛行機等の路線・運賃探索ソフトである「駅すぱあと」と連携させているため，原告ＣＤＤＢと異なり鉄道や飛行機の路線探索，時刻表・料金に関するテーブルを備えておらず，これらのデータは入力していない。
ただし，原告ＣＤＤＢの駅テーブルのデータ（約９２００件）については，ＣＳＶファイルで抽出した上で，「駅すぱあと」と連携させるために，駅コード及び駅名のデータに修正を加えた上で，被告ＣＤＤＢ（「駅マスタ」）に機械的に移行入力した。
c道路関係データ
原告ＣＤＤＢの道路データ，地点データ等の道路関係データについて，コピーして被告ＣＤＤＢ（「道路名マスタ」，「地点マスタ」，「接続マスタ」等）に入力した上で，不要なデータの削除，誤記等の修正，追加を加えた。ただし，高速道路・有力道路の料金データは，原告ＣＤＤＢと同様に，一般に公開されているホームページより入力したものである。これらのデータは，情報の選択に独自の視点や発想が加わる余地がほとんどなく創作性を有しない。
dエリア関係データ
原告ＣＤＤＢの都道府県データをコピーして被告ＣＤＤＢ（地区・都道府県マスタ）に入力し，原告ＣＤＤＢの市区町村データについても，コピーして被告ＣＤＤＢ（市区町村マスタ）に入力した上で市区町村の合併等を確認して追加・削除を行ったが，これらのデータは公知の情報であり，選択の幅は皆無であり創作性はない。


（ｲ）現行版及び新版の被告ＣＤＤＢのデータについて被告アゼスタは，平成１８年６月末ころの被告システム（当初版）の販売開始以降，現在まで６年以上もの長期間にわたり，膨大な手間・時間をかけて，顧客のニーズに対応してデータ内容を充実させており，継続して被告ＣＤＤＢのデータを追加・修正・削除している（乙３４）。これにより，現行版及び新版の被告ＣＤＤＢのデータは，最初に開発した当初版の被告ＣＤＤＢのデータから一新され，データの件数・内容ともに大幅に変更している。レコード数だけをとっても，新版のレコード数（２１３万３８４６件）は当初版・２００６年版（５８万９５９２件）の３．６倍を超えるほどに至っている。また，当初版の被告ＣＤＤＢ開発の際に原告ＣＤＤＢから利用したデータに関して，仮に新版の被告ＣＤＤＢに同内容のデータが存在していたとしても，当該データは，当初版開発時から現在までの６年数か月の期間を通して，被告アゼスタがホームページや書籍等により情報の正確性等を幾度となく確認した上で被告ＣＤＤＢに格納しているものであり，被告アゼスタの継続的な企業努力により，現在の情報を正しく反映しているデータとしての価値が新しく備わったものであるから，もはや６年以上も昔の当初版の被告ＣＤＤＢのデータとはいえないし，ましてや原告ＣＤＤＢのデータと同視されるべきものではない。
現行版及び新版の被告ＣＤＤＢの当初版からの主なデータ変更部分は以下のとおりである。
a施設関係データ
現行版の被告ＣＤＤＢにおいて，顧客のニーズに対応するため，観光施設，宿   泊施設   ，公共   施設等   のデー   タの大   幅な拡   充を行   った結   果，現   行版（Ver2.99）では，施設マスタのレコード件数が約１５万件になり，当初版のレコード件数（約５万７０００件）の約２．６倍にまで増加し，さらに各種施設の新設・閉館や住所・料金等の内容変更などに伴い，２万７０００件以上のデータを修正した。
また，現行版（Ver2.96）の被告ＣＤＤＢにおいては，施設に関する緯度経度データが全て更新しており，新版の被告ＣＤＤＢにおいて，緯度経度マスタのテーブルを削除している。
さらに，新版の被告ＣＤＤＢにおいては，食事土産マスタ等のテーブルを新設し，全国「観光・運輸」総合カタログ２０１１年に掲載されたドライブイン等の食事施設や土産店について，公式ホームページや一般ホームページ等により最新の情報（名称，住所，電話・ファックス番号等）を確認し，データを追加・更新した。
b交通関係データ
現行版の被告ＣＤＤＢにおいては，「駅すぱあと」に収録されていないフェリー，ケーブルカー，ロープウェイ等の交通機関に対応するため，便マスタ，時刻マスタ等のテーブルを新設し，フェリーガイドやホームページ等を確認した上で，交通会社，時刻表，便名等のデータを新たに追加した。
c道路関係データ
現行版の被告ＣＤＤＢにおいて，顧客のニーズに対応するため，地点・道路，高速道路料金等のデータの大幅な拡充を行った結果，現行版（Ver2.99）では，レコード件数が，地点マスタ約２万２３００件，道路マスタ約４８００件，単経路マスタ約６万６０００件，区間料金マスタ約１７６万８０００件となり，当初版のレコード件数（地点マスタ約１万２８００件，道路マスタ約２７００件，接続マスタ約３万７０００件，料金マスタ約３６万３３００件）からそれぞれ大幅に増加され，既存のデータについても，最新の情報に合わせて多数のデータが更新されている。同様に，新版の被告ＣＤＤＢにおいても継続的にデータの追加・更新が行われている。また，現行版（Ver2.94）の被告ＣＤＤＢにおいては，地点に関する緯度経度データはすべて更新されている。
dエリア関係データ
現行版の被告ＣＤＤＢにおいては，都道府県マスタ及び市区町村マスタのデータをすべて入力し直した。
また，現行版（Ver2.96）の被告ＣＤＤＢにおいて，エリアに関する緯度経度データはすべて更新しており，新版の被告ＣＤＤＢにおいては，緯度経度マスタのテーブルを削除している。
さらに，新版の被告ＣＤＤＢにおいて，市区町村マスタに政令指定都市のデータを追加し，市区町村だけでなく政令市の検索まで可能となるようにした。新版の都道府県マスタについても，「緯度経路カラム」フィールドを追加して，都道府県庁位置を新規に登録した。
なお，原告は，ＣＳＶファイルに一旦出力した後に被告ＣＤＤＢに入力したのであれば不都合が生じる「,(カンマ)」，「"(ダブルクォート）」等が含まれているデータのデッドコピーについても，不都合を生じさせることなくデータ移行を行っていることに鑑みて，被告らの主張は明らかに不合理なものであると主張するが，ＣＳＶファイルには，カンマ区切り（ＣＳＶ：データをカンマで区切って並べたファイル形式）のみならずタブ区切り（ＴＳＶ：データをタブ文字で区切って並べたファイル形式）も含まれ，カンマ区切り（ＣＳＶ）では，カンマ，ダブルクォート等は文字化けや項目ずれを起こすため，被告アゼスタでも，カンマ，ダブルクォート等が含まれているデータについてはタブ区切り（ＴＳＶ）を使って上記支障が生じないように対処しており，このことは，エクセルを使ってデータ入力・加工等を行う開発者であれば誰でも知っている常識的な知識である。
したがって，原告の上記主張は失当である。
イ被告ＣＤＤＢは原告ＣＤＤＢに依拠したものではなく，原告が主張するような原告ＣＤＤＢの複製物ないし翻案物ではない。
(ｱ)被告らは，独自の設計思想に基づき被告ＣＤＤＢを開発したものであり，体系的構成が異なる。


被告アゼスタが独自の設計思想に基づき開発した被告ＣＤＤＢ（当初版・２００６年版，現行版，新版）では，原告ＣＤＤＢとのテーブルの一致率（当初版・２００６年版は４９．０％，現行版は１８．２％，新版は１１．５％）及びフィールドの一致率（当初版・２００６年版は４４．１％，現行版は２１．１％，新版は１３．４％）からも明らかな通り，被告ＣＤＤＢは，テーブルの内容（種類及び数），各テーブルに設定されたフィールド項目の内容，各テーブルの関連付けのあり方のいずれの点についても，原告ＣＤＤＢの構造と大きく異なっている。
具体的には，まず，被告ＣＤＤＢは，格納されている情報について，データベース上，相互に結合・連動する必要のある関連性の強いまとまりごとに類型化していくと，大きく分けて，中核となる施設情報とその他の三つの情報（道路情報，交通情報，エリア情報）に分類することができる。このうち，施設情報は旅行の目的地や出発地に関する情報であるところ，そもそも，旅行業者向けシステムにおいては，旅行の目的地をどこにするかという点が最も肝要であり，その他の交通情報，道路情報及びエリア情報は，目的地に到達するためのいわば手段となる情報にすぎないから，目的地となる施設情報に関する体系的な構成をどのような内容とするかが，旅行業者向けシステムのデータベースの創作性を判断する上で決定的な要素となる。実際に，本件のような旅行業者向けシステムと一般に普及しているルート・路線検索システム（カーナビゲーションシステムや「ＮＡＶＩＴＩＭＥ」（株式会社ナビタイムジャパン提供），「駅すぱあと」など）との間で，格納している情報に違いが現れる最たるものが施設情報である。すなわち，ルート・路線検索システムを利用しても出発地や目的地の基本情報（名称や電話番号）は検索することができる上，その間の距離や時間，料金も全て検索することができるところ，本件のような旅行業者向けシステムは，ＣＤデータベース（ＣＤ－ＲＯＭ）に格納する情報との関係では，旅行で訪れる観光施設や宿泊施設に関する詳細情報（営業時間，入館料，客室数，大浴場の有無等）を追加した点に特徴がある。
したがって，施設情報は，旅行業者向けシステムにおいて最も特徴的な情報であり，これがあることではじめて，当該システムがルート・路線検索システムとは異なる独自の検索機能を有しているものといえる。よって，旅行業者向けシステムのデータベースにおいては，施設情報に関する体系的な構成をどのようにするかが，データベースの体系的な構成における創作性を最も大きく左右するものといえる。
以上を踏まえ，当初版・２００６年版，現行版及び新版の被告ＣＤＤＢの開発における被告アゼスタの独自の設計思想，原告ＣＤＤＢとの差異等について詳論する。
ａ当初版・２００６年版
(a)施設情報について
当初版の被告ＣＤＤＢの開発当時（２００６年ころ），日本人の旅行形態の主流は，旅先に行くこと自体（例えば京都に行く，ニューヨークに行くなど）やその旅先の有名な観光名所を巡る（例えば清水寺を巡る，自由の女神を巡るなど）ことを目的とするものから，体験する，味わう，参拝する，世界遺産を巡る，癒しの時間を過ごすなどといった個々人の興味に沿ったテーマを満足することを目的とする傾向に変わりつつあった。また，当該テーマ自体についても，時代の進展に応じてその多様化が進む傾向にあった。
そのため，被告アゼスタは，ゆくゆくは，そのようなテーマに沿った柔軟な検索や旅行計画の作成を利用者（旅行業者）が行うようになることを想定し，将来におけるデータベースとしての拡張性や格納効率，保守性を最大限に高めるという視点から，施設情報に関するデータベースを設計することとした。
このような意図のもと，被告アゼスタは，当初版・２００６年版の被告ＣＤＤＢにおいて，施設マスタという独立したマスターテーブルを上位テーブルとして用意し，宿泊施設マスタや観光施設マスタといった施設の類型別のマスターテーブルを，施設マスタの下位テーブルとして位置付ける格納方法をとることとし，最大２階層でデータを保持するテーブル構成を採用した。
これにより，当初版・２００６年版の被告ＣＤＤＢでは，電話番号や住所などの施設の基本情報は，「宿泊施設」や「観光施設」といった施設類型の区別なく，いったん全て施設マスタに格納する設計としたことから，上記のようなテーマに沿って施設を検索する場合に，データベースの構造上は，施設マスタのみを検索することで，テーマに沿った施設を検索することが可能な設計構造となったものである。さらに，現行版では，上記設計思想をもとに，下位テーブルではなく上位テーブルである施設マスタに「キーワード」のフィールドを設け，施設マスタを「世界遺産」，「祭り」，「花火」，「桜」，「紅葉」，「観光・食事１００選」，「土産物１００選」などのキーワードで検索できるようにしている。したがって，被告ＣＤＤＢでは，いつでも施設類型別のマスターテーブル（例えば，食事施設，公共施設等）を増やすことができ，かつ，これらを上位テーブルの施設マスタで検索できる設計構造となっており，施設類型が多様化してもそれに対応できるような柔軟な設計となっている。現に，新版では，施設類型別のマスターテーブルとして食事・土産マスタを追加し，食事処及び土産施設の情報充実を図っている。
また，宿泊施設自体が観光施設を兼ねている複合施設など（例えば，善光寺宿坊常智院，鴨川ホテル三日月スパ三日月），必ずしも一つの目的地が，「宿泊施設」や「観光施設」といった単独の施設類型に当てはまらないものがあるところ，今後，格納する施設類型が多様化した場合，当該施設がどの施設類型に格納されているか直ちには判然としないケースが増えてくることが予想される。その場合，個々の施設類型から目的の施設を検索しようにも，格納箇所が判然とせず，検索できない可能性があるところ，被告ＣＤＤＢの設計構造であれば，施設類型が判然としなくとも，上位テーブルである施設マスタを検索すれば目的地を検索することができる仕組みになっていることから，上記多様化にも柔軟に対応することができる。
このように被告ＣＤＤＢにおいては，旅行業界の動向を見据え，顧客のニーズに応えることができるように，情報の体系付けやキーワードの付与に独自の創意工夫を凝らしている。
一方，原告ＣＤＤＢにおける施設情報の格納方法は，テーマ別検索を意図していないため，ホテル・旅館テーブルと観光施設テーブルの二つの施設類型別のマスターテーブルでのみ，施設に関する情報を格納している。


そのため，データベースの構造上，目的の施設を検索する場合も，「ホテル・旅館」又は「観光」のいずれか一つのテーブルに絞って検索するか，両方のテーブルを別々に検索せざるを得ず，格納している施設に関する情報をまとめて１テーブルの中で検索できる設計構造になっていない。また，キーワード検索機能を持たない原告ＣＤＤＢの場合，被告ＣＤＤＢのようにテーマ別検索を可能とするためには，ホテル・旅館テーブルと観光施設テーブルの両方に「キーワード」のフィールドを追加し，両方のマスターテーブルを個別にすべて検索する必要があることから，被告ＣＤＤＢと比べて，データベースとしての検索効率及び格納効率が悪いものとなっている。
さらには，原告ＣＤＤＢの設計構造では，被告ＣＤＤＢと異なり，施設類型のテーブルを「ホテル・旅館」と「観光」の二つ以外に追加するのがそもそも難しく，仮に追加して施設類型が多様化した場合も，格納した情報の施設類型が判然としない場合に個々の施設類型からの検索が困難なケースが出てくることになり，データベースとして柔軟な設計構造になっていない。
このように旅行業者向けシステムにとって最も重要かつ本質的な特徴といえる施設情報において，被告ＣＤＤＢは，原告ＣＤＤＢとは全く異なる独自の設計思想に基づいて情報の格納を行っている（乙１９）。
(b)施設情報以外について
道路情報の格納方法としては，ある地点までの最短経路を検索抽出するというダイクストラ法（乙２１。最短距離だけに限らず，時間や費用等の要素も組み合わせ，目的に応じた最適な経路を検索抽出することを含む。）の考え方に従い格納するのが一般的であり，実際の利用者のニーズにも合致している。
そのため，ダイクストラ法は，上記「ＮＡＶＩＴＩＭＥ」やカーナビゲーションシステムなどルート・路線検索を行うシステムではほぼ必ず採用されている方法であり，当然，被告ＣＤＤＢも原告ＣＤＤＢもこれを採用している。
したがって，被告ＣＤＤＢも原告ＣＤＤＢも，ダイクストラ法という一般的でありふれた最短経路検索方法を採用する以上，これを実現するために，地点（始点）と地点（終点）並びにその間の距離及び所要時間等を格納していくという具体的な情報の格納方法それ自体において特段顕著な差異が生じ得るものではなく，このような格納方法自体には何ら創作性（著作物性）が認められない。
また，交通情報（路線情報，交通会社，便情報，時刻情報，運賃情報，距離情報など）は，情報の内容からして本来，格納する情報に取捨選択の余地があるものではなく，基本的には全ての情報を登録する必要があるものであるから，情報の取捨選択について特段顕著な差異が生じるものではない。
実際に，上記「ＮＡＶＩＴＩＭＥ」，「Ｙａｈｏｏ！路線情報」，「駅すぱあと」といった他の多くのルート・路線検索システムにおいても，これらの情報は格納されている。
したがって，そもそも交通情報をどのように格納しようと，格納方法に創作性（著作物性）があるということはできず，著作権侵害の問題が生じるものではない。
そして，被告ＣＤＤＢでは，頻繁に変更が行われる交通情報のデータメンテナンス作業の軽減の観点から，鉄道・路線バス・飛行機等の路線・運賃探索ソフトである「駅すぱあと」と連動させることとしたため，原告ＣＤＤＢと異なり，鉄道や飛行機の路線探索，時刻表・料金に関する情報を一切格納しておらず，その分，テーブル及びフィールド構成も簡素なものとなっている。
したがって，交通情報の格納方法について，交通情報のデータメンテナンス（外部ソフトウェアを利用するか否か）に関する考え方の違いから，原告ＣＤＤＢと被告ＣＤＤＢとで全く異なる格納方法となっている。
さらに，エリア情報は，そもそも格納する情報が，地区（北海道，東北，関東，中部，関西等）と４７都道府県しかないため，格納方法においても，特段顕著な差異が生じるものではなく，格納方法に創作性（著作物性）が認められるものではない。
したがって，そもそもエリア情報をどのように格納しようと，著作権侵害の問題が生じるものではない。
最後に，被告ＣＤＤＢは，レコード修正を容易にするため，地区情報と都道府県情報を，原告ＣＤＤＢと異なり，三つのマスターテーブルで保持することとしている上，原告ＣＤＤＢには，被告ＣＤＤＢと異なり，地区と都道府県情報に加え，「方面」情報が格納されている。以上のとおり，エリア情報の格納方法についても，原告ＣＤＤＢと被告ＣＤＤＢとでは，一部異なる情報を格納している上，格納方法も異なっている。
ｂ現行版
(a)行程・見積機能の当初版からの見直し
２００６年版の被告システムから追加搭載した売上・顧客管理機能は，顧客からの評判もよく，システム安定性にも優れていた。そのため，被告アゼスタは，当初版で構築した行程・見積機能についても，この際，新たな外注先に全て見直してもらい，再構築してもらうこととした。
そして，被告アゼスタは，２００７年４月，行程・見積機能を当初版から大きく変更した現行版を構築した。
これに伴い，被告ＣＤＤＢに格納する各情報の格納方法についても次のとおり見直しが行われた。
(b)施設情報の格納方法
施設情報の格納は，将来におけるテーマ別検索を可能とすることを目的として構築されていたことから，現行版においては，かかる設計思想を受け継ぐこととし，これを具体的に実現すべく，２００８年１０・１１月版（Ver2.82）以降，施設マスタに「キーワード」のフィールドを設け，施設マスタの中から「世界遺産」，「祭り」，「花火」，「桜」，「紅葉」，「観光・食事１００選」，「土産物１００選」などのテーマに沿って検索できるようにした。
(c)道路情報の格納方法
前記のとおり，被告ＣＤＤＢも原告ＣＤＤＢも，ダイクストラ法という一般的でありふれた最短経路検索方法を採用する以上，これを実現するために，地点（始点）と地点（終点）並びにその間の距離及び所要時間等を格納していくという具体的な情報の格納方法それ自体において特段顕著な差異が生じ得るものではなく，このような格納方法自体には何ら創作性（著作物性）が認められない。


もっとも，ダイクストラ法の特徴は，最短となる経路の探索をひたすら繰り返すことにあるところ，被告アゼスタは，翼システムには在籍していなかった開発担当者も交えて根本から設計思想を見直し，被告ＣＤＤＢの現行版においては，経路の方向を上下区分で表現した「接続」の組み合わせにより禁止経路を構成する原告ＣＤＤＢとは全く異なり，禁止経路を定義するための作業量を軽減して格納効率を向上させるべく，上下区分による「接続」概念を一新し，始点→中間点→終点の３地点の組み合わせで禁止経路情報を禁止経路マスタとして１テーブルに格納する方法で格納することとした。
この結果，被告ＣＤＤＢでは，原告ＣＤＤＢよりデータの読み込み回数を少なくすませて経路探索を高速で処理することが可能となり，以下の(i)ないし(v)のとおり，現行版の被告ＣＤＤＢでは，道路情報の格納方法についても，原告ＣＤＤＢとの間に大きな違いが生じることとなった。
(i)原告ＣＤＤＢの接続テーブルでは，接続番号というフィールド項目がプライマリー・キーとなっているのに対し，被告ＣＤＤＢの単経路マスタでは，地点コード（始点），地点コード（終点），道路コードの三つのフィールド項目がプライマリー・キーとされている（乙９別紙５）。
これにより，例えば，地点Ａから地点Ｂに道路１を介して接続される経路を登録する場合，被告ＣＤＤＢでは，それぞれのフィールド項目がプライマリー・キーとなっているため重複して登録されることはないが，原告ＣＤＤＢでは，接続番号というフィールド項目のみがプライマリー・キーとなっているため同一の経路が重複して登録され無駄なデータが作られる可能性がある。もしデータが重複登録されると，同じ地点間でも異なる所要時間や距離が誤って登録される可能性があり，不都合が生じる。その上，原告ＣＤＤＢでは，地点（始点）がプライマリー・キーとなっていないため，経路検索において，効率の良いデータの読み込みができない設計となっている。
(ii)被告ＣＤＤＢの禁止経路マスタは，始点→中間点→終点の３地点の組み合わせで禁止経路情報を１テーブルに格納しているが，原告ＣＤＤＢでは，経路と経路の組み合わせを接続テーブル及び禁止乗換テーブルの２テーブルに分けて格納しており，被告ＣＤＤＢの禁止経路マスタと原告ＣＤＤＢの禁止乗換テーブルは，その構造が異なっている（乙９別紙５）。
これは禁止経路の設定の仕方について原告ＣＤＤＢと被告ＣＤＤＢとで異なる考え方（原告ＣＤＤＢは２地点と２地点の組み合わせで禁止経路を設定する考え方であるのに対し，被告ＣＤＤＢは３地点の組み合わせで禁止経路を設定する考え方）を採用していることによる。
その結果，禁止経路に関し，原告ＣＤＤＢでは，被告ＣＤＤＢに比べて複雑な禁止経路定義設計となっているため，禁止経路を定義するための作業量が増えることから，被告ＣＤＤＢより誤りが生じやすい構造になっている（乙９別紙５）。
(iii)被告ＣＤＤＢの区間料金マスタ及び通行料金マスタと，原告ＣＤＤＢの区間料金テーブル及び首都高速料金テーブルを比較すると，被告ＣＤＤＢの方が道路料金区分を備えている分，柔軟な設計となっている（乙９別紙５）。
例えば，新たに深夜早朝，通勤割引などのＥＴＣ割引料金を追加する場合，被告ＣＤＤＢでは，区間料金マスタのレコードを追加するだけで，フィールド追加などのテーブルの設計変更は不要である。これに対し，原告ＣＤＤＢの区間料金テーブルの構造では，必要な料金種類分のフィールドの追加が必須となる。なお，原告も認めるとおり，フィールドの追加はシステムへの影響が大きく容易でないが，レコードの追加は容易にできる（甲３，４頁）。
(iv)原告ＣＤＤＢの首都高速料金テーブルは，その名のとおり首都高速料金の情報だけを格納しているが，被告ＣＤＤＢの通行料金マスタは，首都高速だけでなく，有料道路などの定額の通行料金の情報全てを格納する設計となっている（乙９別紙５）。
(v)被告ＣＤＤＢでは，原告ＣＤＤＢの市区町村通過道路索引テーブル，道路構成地点索引テーブル，県範囲定義テーブル，道路構成地点テーブル，有料道路番号テーブルに対応するテーブルは存在しない。
(d)交通情報の格納
交通情報については，そもそも格納方法に創作性（著作物性）があるものではない。もっとも，被告アゼスタでは，前記のとおり，当初版の被告ＣＤＤＢにおいて，「駅すぱあと」と連動させることとしたため，原告ＣＤＤＢと異なり，鉄道や飛行機の路線探索，時刻表・料金に関する情報を一切格納していなかったところ，利用者より，鉄道や飛行機以外のフェリーなどの路線やその時刻表等の情報も追加して欲しいといった要望があった。これを受けて，被告アゼスタでは，これらのフェリーなどの路線情報を格納するため，現行版において路線構成マスタ，路線マスタ，時刻マスタ，便マスタの各テーブルを新たに設計したものである。その結果，便情報や運行日の格納に関するテーブル構成にも違いが生じることとなった（乙９別紙６）。したがって，交通情報の格納については，被告ＣＤＤＢと原告ＣＤＤＢとは，当初版からして「駅すぱあと」と連動させるか否かの点で基本的な設計思想が大きく異なっていたが，現行版ではさらにその違いが大きくなっている。
(e)２００６年版の売上・顧客管理機能との設計方針の統一現行版では，被告データベースの行程・見積機能の部分について，上記の見直しの他に，２００６年版の売上・顧客管理機能と設計方針を統一させるため，システムの機能向上，設計工程及び製造工程における品質確保や効率の追求という観点から，被告ＣＤＤＢのフィールド構成等を再構築した。
具体的には，被告ＣＤＤＢのフィールドの並び順を変更し，また，全テーブルにおいて作成日時，更新日時及び削除区分のフィールドを追加した。さらに，予備フィールド（別紙３の括弧内に「予備」と記載された，フラグ，区分，日付，数値等のフィールド）は全て削除し，施設情報のＵＲＬマスタに表示順フィールドを追加した。
ｃ新版


被告システムの新版は，平成２３年４月４日，それまでの被告システムの現行版（Ver2.99）を再構築して発売した。これに伴い，被告ＣＤＤＢ部分についても内容が大きく変更した。
新版における設計思想は以下のとおりである。
(a)施設情報の格納方法の変更
新版の被告ＣＤＤＢでは，主に施設情報の格納につき，利用者のニーズと意識やライフスタイルの変化に対応し，さらにデータベースの拡張性，格納効率及び検索効率等の向上の観点から再構築がされた。当初版においては，前記のとおり，施設情報の格納に関して，個々人の旅のテーマに沿った柔軟な検索や旅行計画の作成を利用者（旅行業者）が行えるようにするため，将来におけるデータベースとしての拡張性や安定性，検索効率等を考慮して，被告ＣＤＤＢにおいて，施設マスタを上位テーブルとして用意して，ここに基本的な情報を集約し，いかなる検索テーマを設定しようと施設マスタという一つのマスターテーブルから全て検索できるようにし，宿泊施設マスタや観光施設マスタといった施設の類型別の詳細情報を収録したマスターテーブルを，施設マスタの下位テーブルとして位置付けるテーブル構成をとることとしていた。
新版の被告ＣＤＤＢでも，上記設計思想をそのまま受け継ぎ，下位テーブルである類型別のマスターテーブルとして新たに食事・土産マスタを追加し，食事処及び土産施設の情報充実を図った。これは観光施設か宿泊施設かにかかわらず，ドライブインや名産品の土産店などのように食事のためや土産物を購入するためにだけ立ち寄ることができる施設について，これらに特化した情報である，開館・閉館時間や食事内容，土産内容等を充実してもらいたいとの利用者からのリクエストがあり，重要性が増したことから，観光施設や宿泊施設から独立させて追加したものである。
また，新版の被告ＣＤＤＢでは，施設の種別及び詳細種別の格納を統合的に格納するため，施設種別マスタ，施設詳細種別マスタ及び施設別詳細種別マスタを追加した。
具体的には，現行版の被告ＣＤＤＢまでは，観光施設の種別については施設マスタの中の「観光種別」のフィールド及び観光種別マスタと観光詳細種別マスタで格納していたのに対し，宿泊施設と公共施設の種別については施設マスタの中の「宿泊種別」，「公共施設種別」のフィールドのみで格納しており，施設によって施設の種別の格納の仕方が異なっていた。そこで，新版の被告ＣＤＤＢでは，これらを一元的に整理し格納するため，施設の種別については，観光施設，宿泊施設，公共施設さらには新版で追加された食事処及び土産施設のいずれも，施設種別マスタ，施設詳細種別マスタ及び施設別詳細種別マスタの三つのテーブルで格納することとしたものである。これに伴い観光種別マスタ及び観光詳細種別マスタは削除した。それぞれのテーブル（マスタ）の格納情報の詳細は，施設を「宿泊」，「観光」，「公共」，「食事・土産」の四つに大分類し，そこから施設種別の中分類として施設種別マスタを用意し，小分類として施設詳細種別マスタを用意したものである。
これにより，例えば，ある一つの施設が神社・仏閣としても博物館としても分類されるような複合的な施設種別を持つ場合において，当該施設に割り当てられた一つの施設コードを使って，神社・仏閣としても博物館としても検索できるような構造になった。すなわち，神社・仏閣としても博物館としても検索されるようなキーワードを関連する格納情報の中に全て直接書き込んでおき文字列で検索できるようにする方法もあるが，データベースとしては施設コードで検索できるようにしておいた方が効率的であるし，データベースの開発時及び更新時における人為的ミスを低減することができる。また，施設の種別を増やしたい場合，食事・土産マスタのようなマスターテーブルとして追加するという方法もあるが，そこまで施設の詳細情報を入力する必要が現時点ではない場合に，施設種別マスタの「施設大種別」の中で追加レコードとして増やすことで対応することも可能となった。これにより検索テーマの種別を増やすことも容易となり，このことは被告のデータベース開発の設計思想にあるテーマ別検索を充実させることにもつながる。なお，現行版の被告ＣＤＤＢで施設の種別を増やしたい場合，施設マスタの中のフィールドとして新たに追加する必要があり，単なるレコードの追加の場合に比べて，データベースを動作させるプログラムの開発及びその動作検証等に時間を要するなど，データベースの追加拡張が容易ではなかった。
このように，新版の被告ＣＤＤＢでは，施設の種別につき，一元的に整理，格納することが可能となり，種別の追加が容易になった。なお，原告ＣＤＤＢには上記のようなテーブルはない上，施設の種別を増やそうにも，ホテル・旅館テーブル又は観光施設テーブルの中でのフィールドの追加という形でしか対応できない構造になっており，データベースとしての拡張性に乏しい構造となっており，その違いはより一層顕著なものとなっている。
その他にも，新版の被告ＣＤＤＢでは，提携施設マスタ，提携種別マスタ及び提携会社マスタを追加した。これは，宿泊施設や観光施設等が，大手旅行会社や全国旅行業協会，旅行案内所などと提携している施設か否か，また，宿泊クーポンや食事クーポン等のクーポンを利用できる施設か否か，各会社のクーポンを発券できる施設か否かといった情報を新たに格納したものであり，これらも利用者からの要望に応えるために追加したものである。
また，新版の被告ＣＤＤＢでは，既存の施設マスタ，観光施設マスタ，宿泊施設マスタにおいても，利用者からの要望をふまえ，「Ｅメール」（施設への連絡先），「団体受入区分」（団体客の受入れが可能か否か）及び「風呂，温泉効能」（施設内の風呂，温泉の効能）などのフィールドをそれぞれ追加，変更した。
以上のとおり，新版の被告ＣＤＤＢでは，施設情報の格納方法が大きく変更されており，原告ＣＤＤＢとは似ている点がないほど体系的な構成を大きく異にしている。
(b)その他の情報
その他の情報については，交通情報に関しては，システム画面上で表示した出発駅と到着駅の駅名で「駅すぱあと」の駅名と連動させるようにして，「駅すぱあと」による検索を可能にしているが，利用者の利便性を考えると駅名によってはシステム画面上で表示する駅名と「駅すぱあと」に登録されている駅名とを別名にしたい場合がある。例えば，新千歳空港ではなく札幌空港（新千歳空港）と表示する，東京国際空港（羽田）ではなく羽田空港（東京国際空港）と表示する等のように，「駅すぱあと」の駅名ではなく通称で表示した方が利便性が高い，と考えられることによるものである。これらの別名を収録した「駅名（駅すぱあと）」のフィールドを，駅マスタに追加したりもした。
また，道路情報に関しては，地図上に表示するルート検索結果の経路表示をより一層地図上の道路に沿った曲線のように画面上表示するための座標データの情報を格納した「単経路補間マスタ」を追加したり，利用者の要望により道路名の略称でも検索できるように，例えば「中央自動車道」ではなく「中央道」で検索できるよう，「道路名略称」のフィールドを道路マスタに追加したりした。


また，エリア情報に関しては，利用者の要望により，政令指定都市でも検索できるように，「政令市区分」，「政令市コード」をフィールドとして市区町村マスタに追加したりした。
このように利用者からの要望やシステム操作上の利便性等をふまえ，施設情報以外の情報についてもテーブルやフィールドの変更等を行った。なお，これらの新規テーブルや新規フィールドは，原告ＣＤＤＢには存在しない。
(ｲ)原告ＣＤＤＢと被告ＣＤＤＢとは，実際のテーブル・フィールドの構造及びリレーションが異なる。
テーブル構造及びフィールド構造の違いに基づく原告ＣＤＤＢと被告ＣＤＤＢ（新版）の機能等の差異の詳細には大きな違いがあり，被告ＣＤＤＢが原告ＣＤＤＢに依拠して作成されたものではないことは明らかである。とりわけ，前記のとおり，旅行業者向けシステムのデータベースにおいては，施設情報に関する体系的な構成をどのようにするかが，データベースの体系的な構成における創作性を最も大きく左右する。そして，施設情報に関しては，当初版よりすでに，原告ＣＤＤＢと被告ＣＤＤＢとで設計思想が大きく異なっており，被告ＣＤＤＢでは，施設マスタの下位テーブルとして観光施設マスタと宿泊施設マスタが位置付けられ，全ての施設が施設コードで体系立てられており，原告ＣＤＤＢと体系的な構成を大きく異にしていた。その上さらに，新版の被告ＣＤＤＢでは，観光施設種別だけではなく，宿泊施設や食事・土産施設，公共施設の施設種別も一元的に管理可能なテーブル構造に変更したことにより，今後どのような種別の施設を追加しても，施設種別の追加に伴うテーブル変更やフィールドの追加を生じさせないですむようになった。これに対し，原告ＣＤＤＢでは，上位の施設テーブルが存在しないため，異なる種別の施設データを追加する場合には必ず種別ごとのテーブルを追加しなければならず，両ＣＤＤＢの体系的な構成の違いに基づく機能の優劣も顕著となっている。
以上のように，異なる設計思想で開発された新版の被告ＣＤＤＢと原告ＣＤＤＢとは，旅行業者向けシステムのデータベースにおいて最も創作性を左右する施設情報において，もはや似ている点がないほど体系的な構成が異なっており，全く別物のデータベース構造となっている。(ｳ)原告ＣＤＤＢとは情報の選択も異なる。
被告アゼスタは，当初版の被告ＣＤＤＢを開発するにあたり，独自に収集したデータに加えて，原告ＣＤＤＢのデータの一部を，修正等の加工を施した上で利用した。しかし，これらのデータは，いずれも，行程表・見積書等の作成業務等の機能を有する旅行業者向けのデータベースに格納する情報としては当然かつありふれたものであり，かつその情報の選択において創作性が認められない単なる客観的なデータであるところ，このようなデータに修正等の加工を加えて利用する行為が著作権侵害となることはあり得ない。
また，被告アゼスタは，平成１８年６月末ころの被告システム（当初版）の販売開始以降，現在まで６年以上もの長期間にわたり，膨大な手間・時間をかけて，顧客のニーズに対応してデータ内容を充実させており，継続して被告ＣＤＤＢのデータを追加・修正・削除してきた結果，現行版及び新版の被告ＣＤＤＢのデータは，当初版の被告ＣＤＤＢのデータから一新されている。
これら具体的なデータの入力等については，前記(ｱ)で詳述したとおりである。
(ｴ)まとめ
以上のとおり，被告アゼスタが独自の設計思想に基づき開発した被告ＣＤＤＢと原告ＣＤＤＢとは，体系的な構成及び情報の選択のいずれの点においても大きく異なっており，さらに，被告アゼスタは，当初版・２００６年版，現行版，新版と，絶え間なく被告システムに大幅な改良・変更を加えており，被告ＣＤＤＢと原告ＣＤＤＢにおける体系的な構成及び情報の選択の点での乖離はますます甚だしいものとなっている。したがって，被告ＣＤＤＢは原告ＣＤＤＢに依拠したものではなく，原告の著作権（複製権）を侵害するものではない。
また，著作物の翻案とは，既存の著作物に依拠し，かつその表現上の本質的な特徴の同一性を維持しつつ，具体的表現に修正，増減，変更等を加えて，新たに思想又は感情を創作的に表現することにより，これに接する者が既存の著作物の表現上の本質的な特徴を直接感得することのできる別の著作物を創作する行為をいうとされ，思想，感情若しくはアイデア，事実若しくは事件など表現それ自体ではない部分又は表現上の創作性がない部分において既存の著作物と同一性を有するにすぎない著作物を創作する行為は，既存の著作物の翻案に当たらないとされるところ，データベースの著作物においても，体系的な構成及び情報の選択に関して，創作性がない部分において既存の著作物と同一性を有するにすぎない著作物を創作する行為は，既存の著作物の翻案に当たらないというべきである。本件において，原告は，原告ＣＤＤＢの創作性について，旅行業者が行程表作成の業務を行うにあたって必要となる観光施設データ，宿泊施設データ，全国各地の主要道路の道路地点，大型観光バスの移動時間・距離，有料道路・高速道路の料金データ，鉄道・飛行機・フェリーに関する路線，駅，時刻表等の情報を収集・蓄積し，各テーブル間をプライマリー・キー等によって有機的に関連付けることで，顧客のニーズに合わせた行程表を作成できるようにした情報の分類体系であることを強調する。しかし，旅行業者向けのデータベースの開発に当たり，上記の情報を収集・蓄積し，各テーブル間をプライマリー・キー等によって有機的に関連付けることで，顧客のニーズに合わせた行程表を作成できるようにすること自体は，アイデアの範疇に属するものにすぎず，それ自体が創作性を基礎付けるわけではない。
データベースの創作性においては，あくまでも体系的な構成及び情報の選択における創作性が問題となるところ，上記のとおり，被告ＣＤＤＢ（とりわけ新版の被告ＣＤＤＢ）は，データの内容についても，情報の選択において創作性を有する部分について原告ＣＤＤＢと大きく異なっているし，何より，テーブル・フィールドの構造及びリレーションについても，旅行業者向けシステムのデータベースにおいて最も創作性を大きく左右する施設情報を中心に，もはや似ている点がないほど異なっており全くの別物となっている。


したがって，被告ＣＤＤＢ（とりわけ新版の被告ＣＤＤＢ）は，原告ＣＤＤＢとは，データベースの著作物の創作性を基礎付ける本質的な特徴が大きく異なっており，原告の翻案権を侵害するものともなり得ない。２争点(2)(被告らによる著作権侵害についての共同不法行為の成否)について
〔原告の主張〕
被告ＣＤＤＢは原告ＣＤＤＢに依拠して作成されたものであるが，依拠して作成され共通の内容となっている部分は，情報の選択及び体系的構成について創作性を有する部分であるので，被告ＣＤＤＢを製造し販売しインターネットを通じて顧客に提供する被告らの行為は，原告ＣＤＤＢについて原告が保有する著作権（複製権，翻案権，譲渡権，貸与権，公衆送信権）を侵害するものである。
そして，被告アゼスタの代表取締役である被告Ｙ１をはじめ，被告Ｙ３，被告Ｙ２，被告Ｙ４は，Ａ及び被告Ｙ５に対し，原告ＣＤＤＢに依拠して，これと同一ないし実質的に同一である被告ＣＤＤＢを作成することを依頼ないし黙認し，Ａ及び被告Ｙ５の２名は，被告Ｙ１らの右依頼を受け，自らの意思と判断により，被告ＣＤＤＢを設計ないし作成し，被告Ｙ１，被告Ｙ３，被告Ｙ２，被告Ｙ４，被告Ｙ６の５名は，被告ＣＤＤＢを含む被告システムを販売しており，被告Ｙ１，被告Ｙ３，被告Ｙ２，被告Ｙ４，被告Ｙ６，被告Ｙ５及びＡは，これらの一連の行為により，原告ＣＤＤＢに係る原告の著作権（複製権，翻案権，譲渡権，貸与権，公衆送信権）を侵害したものと認められる。これらの著作権侵害行為は，被告アゼスタの代表者，取締役，監査役や従業員としての行為であるとともに，個人被告らについて，個人としての行為でもあると評価することができる。
そして，Ａ及び被告Ｙ５は被告ＣＤＤＢの開発者として，上記のとおり原告ＣＤＤＢに依拠して，これと類似する被告ＣＤＤＢを作成しており，著作権侵害について故意があるというべきである。被告アゼスタの代表者である被告Ｙ１は，Ａ，被告Ｙ５のかかる行為を行うことを依頼し自らもその作業に加わったものであり，著作権侵害について故意があるというべきである。また，被告Ｙ１，被告Ｙ３，被告Ｙ２，被告Ｙ４，被告Ｙ６らは，被告アゼスタの営業担当者として，被告ＣＤＤＢが原告ＣＤＤＢに依拠して作成されたものであることを知りながら，被告ＣＤＤＢを含む被告システムをユーザーに対して提供し続けているので，著作権侵害について故意があるというべきである。
仮に，個人被告ら及びＡに著作権侵害についての故意が認められないとしても，少なくとも過失が認められる。すなわち，個人被告ら及びＡは，原告システムの開発に中心的に携わった開発者であるＡ，被告Ｙ５が，原告システムと競合する被告システムを原告システムの開発に関するノウハウを利用して開発し，原告システムの販売に中心的に携わっていた営業担当者である被告Ｙ３，被告Ｙ２，被告Ｙ４，被告Ｙ６が，被告システムを原告システムの既存ユーザーに対して販売するという事業計画の下で新会社である被告アゼスタを設立し，被告システムを開発し販売しようとしたものであり，原告システムに関する著作権侵害を行う可能性のある行為をあえて行おうとしていたことになる。個人被告ら及びＡには，被告ＣＤＤＢを含む被告システムが，原告ＣＤＤＢを含む原告システムに関する著作権を侵害しない製品となるように，開発を実施させ，著作権侵害品をユーザーに提供しないという注意義務があったというべきであるが，個人被告ら及びＡはかかる注意義務に違反しているので，少なくとも著作権侵害に関して過失があるというべきである。
以上のとおり，本件著作権侵害は個人被告らの故意ないし少なくとも過失により行われたものである。
〔被告らの主張〕
否認し，争う。
被告ＣＤＤＢは，情報の選択という点のみならず，そもそも体系的な構成からして原告ＣＤＤＢと大きく異なっており，被告らは原告の著作権を何ら侵害しておらず，また被告アゼスタが原告ＣＤＤＢのデータの一部を利用した行為について不法行為とはなり得ない。
したがって，被告らの行為が原告に対する不法行為を構成することはない。３争点(3)（一般不法行為の成否〔予備的主張〕）について
〔原告の主張〕
1)民法７０９条にいう一般不法行為の成立要件としての権利侵害は，必ずしも厳密な法律上の具体的権利の侵害であることを要せず，法的保護に値する利益の侵害をもって足りる。そして，対象となる作品や製品が著作物に該当しない場合でも，第三者によるそれらの複製，頒布，販売，公衆送信等の利用行為が自由競争の範囲を逸脱し，社会的な許容限度を超える場合には，一般不法行為として権利侵害となる。
データベースに関しても，人が費用や労力をかけて体系的構成を構築し，情報を収集，整理することで，データベースを作成し，そのデータベースを製造販売することで営業活動を行っている場合において，第三者が無断で，そのデータベースの体系的構成，選択収集されたデータを複製して作成したデータベースを，その者の販売地域と競合する地域において販売する行為は，公正かつ自由な競争原理によって成り立つ取引社会において，著しく不公正な手段を用いて他人の法的保護に値する営業活動上の利益を妨害するもので，自由競争の範囲を逸脱し，社会的な許容限度を超えるものであるので，不法行為を構成するというべきである。
(2)被告らによる自由競争の範囲を逸脱する行為
ア原告ＣＤＤＢの作成経緯


原告ＣＤＤＢは，体系的構成の構築，情報の取得及び入力されたデータの適否のチェックに多大な費用及び労力を費やして作成されたものである。原告ＣＤＤＢを含む原告システムは，翼システムが平成６年（１９９４年）７月から開発を開始し，平成８年（１９９６年）１月に完成して販売を開始した「スーパーフロントマン旅行業システム」が元となっており，その後改良が加えられてきたものである。翼システム時代も含め，原告は，日本全国に原告ＣＤＤＢを含む原告システムを販売し現在に至っている。被告ＣＤＤＢの２００６年版にデッドコピーされたテーブルＩＤやフィールドＩＤから見ると，被告らは，平成１８年（２００６年）頃までに原告ＣＤＤＢをデッドコピーした上，当初版，２００６年版，現行版及び新版を作成しているものと推認されるが，翼システムないし旧原告会社は，平成６年（１９９４年）７月の開発開始時から平成１８年（２００６年）頃までの間，原告ＣＤＤＢの開発及び維持には，開発要員として少なくとも常時１０人以上従事させ，その間，開発費用として少なくとも７億円以上を費やしてきた。
イ被告らによる原告ＣＤＤＢの体系的構成及び選択収集した情報の流用被告Ｙ２，被告Ｙ３，被告Ｙ４，被告Ｙ５，被告Ｙ６は翼システムの従業員であったところ，営業譲渡に伴い，原告に移籍してきたものである。上記被告らは翼システムないし旧原告会社在職中に原告ＣＤＤＢを備える原告システムの開発，販売に従事していたものであり，原告ＣＤＤＢにアクセスしていたものである。
体系的構成の流用状況，収集した情報の流用状況については前記２争点(2)〔原告の主張〕のとおりである。すなわち，被告らは，道路情報，道路地点情報についてコピーしたことを認めているところ，その他の情報についてもデッドコピーしている痕跡が多々存在する（甲９，２１，２３，２８，３７）。被告ＣＤＤＢはまず原告ＣＤＤＢをデッドコピーし，それを元に当初版，２００６年版，現行版，新版と作成してきたものであり，各版作成の都度流用を隠蔽するために一部改変を加えたものである。その結果，被告ＣＤＤＢには原告ＣＤＤＢから改変されている部分（甲２３，３５，３６，３７）も一部あるが，総じてデッドコピーの状況といえる。ほぼデッドコピーそのものである当初版・２００６年版の作成から始まり，その後少しずつ改変を加えて，現行版，新版が作成されたという経過に鑑みると，被告ＣＤＤＢにおける改変部分の多くは，テーブルＩＤ，フィールドＩＤ，道路地点の緯度経度情報の改変が典型例であるが，それらは流用の事実を隠蔽しようとしてされているのであって，かかる改変によりデッドコピーでない部分が生じるとしても，そのことは，むしろ被告らの行為の悪質性を顕著に示すものであって，社会的に許容限度内の行為であることを基礎づける事実には到底ならない。
ウ被告らによる原告の顧客の不当な奪取行為
原告ＣＤＤＢのような観光施設，宿泊施設，道路，各種交通機関の時刻表等の様々な情報をデータベースとして備え，旅行業者向けの行程表が作成できるパッケージソフトウェアは，被告らが被告ＣＤＤＢを備える被告システムを平成１８年６月から販売するまで，日本国内市場に原告システム以外に存在しなかった。それまでは，原告は日本全国に原告ＣＤＤＢを含む原告システムを販売してきたものである。
しかるに，原告システムの開発・営業に携わった個人被告ら（被告Ｙ１を除く。）は，原告を退職した上，被告アゼスタを設立し，原告ＣＤＤＢをデッドコピーあるいは一部改変した被告ＣＤＤＢを備える被告システムを作成し，主に原告システムのユーザーに対して大幅な値引きを行って売り込みをかけ，原告の顧客を奪ったものである。被告らは原告ＣＤＤＢを流用することによって開発費をかけずに被告ＣＤＤＢを作成し，安価な製品の提供を行って原告の顧客をターゲットにして顧客を奪ってきている。被告らが奪った顧客数は，被告ら自身が明確に認めるものだけでも平成２０年（２００８年）７月時点で１８２社（甲５２），平成２２年（２０１０年）１１月時点で３００社（甲５３）に及び，現時点ではその数は優に３６０社を超えている。なお，被告らは平成２２年（２０１０年）１１月時点で被告ＣＤＤＢを含む被告システムのユーザーが約５００社であることも認めている。原告の元従業員である被告らが原告を退職後被告アゼスタを設立し，原告ＣＤＤＢを含む原告システムの顧客に対して，原告が長年多大な費用や労力をかけて作成したデータベースである原告ＣＤＤＢをそのまま複製等して，作成した被告ＣＤＤＢを含む被告システムを大きな値引きを行って販売し，原告システムを被告システムに乗り換えさせて原告の顧客を奪うという行為は，故意，あるいは少なくとも過失により，取引における公正かつ自由な競争として許される範囲を甚だしく逸脱し，法的保護に値する原告の営業活動を妨害しその営業上の利益を侵害するものとして不法行為を構成するというべきである。
なお，原告ＣＤＤＢの開発及び維持管理は，平成１７年１２月３０日までは翼システムが行ったものであるが，原告は，平成１７年１２月３０日に翼システムから営業譲渡を受けて，原告ＣＤＤＢを含む原告システムについて，著作権のほか一般不法行為上の権利も原告に譲渡されたものであり，原告ＣＤＤＢについて，原告が一般不法行為上の権利を保有する。
(3)個人被告らの責任


被告Ｙ１，被告Ｙ３，被告Ｙ２，被告Ｙ４，被告Ｙ５は，互いに相談の上，原告ＣＤＤＢを含む原告システムと競合する旅行業システムを開発販売する被告アゼスタを設立し，Ａ及び被告Ｙ５は，原告ＣＤＤＢを含む原告システムに依拠して，これと実質的に同一ないし類似する被告ＣＤＤＢを含む被告システムを開発し，被告Ｙ１，被告Ｙ３，被告Ｙ２，被告Ｙ４，被告Ｙ６は，被告ＣＤＤＢを含む被告システムを原告システムの販売地域と競合する地域にて販売し，原告の営業上の利益を侵害しているのであるから，個人被告ら及びＡは，これらの一連の行為により一般不法行為を行っているものである。そして，これらの行為は，被告アゼスタの代表者（被告Ｙ１），取締役（被告Ｙ２，被告Ｙ３），監査役（Ａ）や従業員（被告Ｙ４，被告Ｙ６）としての行為であるとともに，個人被告らの個人の行為でもあると評価することができ，被告アゼスタ，個人被告ら及びＡによる共同不法行為であるといえる。したがって，原告に対する一般不法行為について，被告らは，共同不法行為責任を負うというべきである。
Ａ及び被告Ｙ５は，被告ＣＤＤＢを含む被告システムが原告システムと競合する地域にて販売されることを認識しながら，原告ＣＤＤＢの体系的構成やデータを流用した被告ＣＤＤＢを作成しているので，原告の利益を侵害することについて故意があるというべきである。
また，被告Ｙ１，被告Ｙ３，被告Ｙ２，被告Ｙ４，被告Ｙ６らは，被告アゼスタの営業を通じて，被告ＣＤＤＢが原告ＣＤＤＢの体系的構成やデータを流用して作成されたものであることを知りながら，被告ＣＤＤＢを含む被告システムを原告システムの販売地域と競合する地域のユーザーに対して提供し続けているので，原告の利益を侵害することについて故意があるというべきである。
仮に，個人被告ら及びＡに故意がなかったとしても，個人被告ら及びＡには，少なくとも過失が認められる。すなわち，原告システムの開発に中心的に携わった者であるＡ，被告Ｙ５が，原告システムと競合する被告システムを開発し，原告システムの販売に中心的に携わっていた者が被告システムを販売するという事業計画の被告アゼスタを設立したのであるから，被告ＣＤＤＢも含め被告システムの開発販売が不公正な手段を用いて原告の法的保護に値する営業活動上の利益を侵害することにならないように，開発販売を行うべき注意義務があったというべきであるが，個人被告ら及びＡはかかる注意義務に違反しているので，少なくとも過失があるというべきである。以上のとおり，本件共同不法行為は被告らの故意により，仮に故意が認められないとしても少なくとも過失により行われたものである。したがって，被告らは，原告に対し，上記不法行為により原告が被った損害を賠償する責任を免れない。
〔被告らの主張〕
(1)データの違法な流用及び顧客奪取行為は存しないことア被告アゼスタが当初版の被告ＣＤＤＢの開発にあたり利用した原告ＣＤＤＢのデータは，いずれも行程表・見積書等の作成業務等の機能を有する旅行業者向けのデータベースに不可欠であり，かつその情報の選択において創作性が認められない単なる客観的なデータである。著作権侵害に至らない行為を不法行為と捉えることは，著作権法の趣旨を潜脱するものであり許されるべきではないし，職業選択の自由（憲法２２条１項）の重要性に鑑み，在職中に業務を通して取得した知識・技能に基づいて行う行為は原則として自由競争の範囲内のものとして許容されるべきである。したがって，本件で被告アゼスタが原告ＣＤＤＢのデータの一部を利用した行為については，不法行為とはなり得ない。
また，原告は，原告ＣＤＤＢが多大な費用や労力をかけて開発されたと主張するが，これも実態とは大きく異なる。平成８年１月に販売開始された原告ＣＤＤＢは，日本観光協会の観光施設データと，旧国際観光旅館連盟・旧日本観光旅館連盟の加盟施設，政府登録国際観光旅館の宿泊施設が登録されているのみで，旅行業者にとっては全く不十分なものであり，とても顧客を満足させるようなものではなかった。特に，原告ＣＤＤＢの観光施設データについては，旅行業者が送客手数料を受領できる施設の登録に不備があり，これが販売面での致命傷となっていたため，無断転記を禁じられている料金ガイドから全てのデータを転用して観光データを入力した。実際，被告Ｙ２がヘッドハンティングを受けて翼システムに入社した平成８年２月当時，翼システムでは，情報企画事業部で旅行営業課が設立されたばかりで，原告ＣＤＤＢも上記のとおり試作品レベルのものであった。しかし，前職で旅行業者向けのトータル業務システム販売業務に従事して旅行業務システム構築のノウハウを熟知していた被告Ｙ２や被告Ｙ５，主たる開発者であったＡらが中心になって，原告ＣＤＤＢの観光施設・宿泊施設データの増加や改良がなされ，わずか３か月後の平成８年５月には販売してもクレームにならない程度まで原告ＣＤＤＢの品質が改善され，現在の原告ＣＤＤＢと同等のレベルの性能を備えるに至ったものであり，多大な費用や労力をかけて原告ＣＤＤＢが開発されたとはいえない。イ原告は，被告システム販売開始後，被告らが原告の顧客をターゲットとし残リース期間の短いところから順次「狙い撃ち」して営業を行っていたと主張する。
しかし，被告らは，原告の顧客のみをターゲットにしていたものではなく，当然，その他の旅行会社にも営業を行っていた。また，被告Ｙ３，被告Ｙ２，被告Ｙ４及び被告Ｙ６は残リース期間の長短に関係なく営業を行っていたし，残リース料を負担とするというのはごく普通のことであり，実際被告アゼスタに限らず同業他社も同じ営業方法をとっている。前記のとおり，そもそも原告の顧客が被告システムに変更したのは，単に原告システムの不具合やメンテナンス不足に対する不満と被告システムの優位性が理由であるから，被告らの営業は完全に自由競争の範囲内のものである。
(2)被告ら各人に不法行為は成立しないこと
ア被告Ｙ１の責任につき


被告Ｙ１は，そもそも翼システムに在職してもおらず，株式会社グッドウィルの取締役，株式会社エス・エス・アイ・トリスター及び株式会社トリスターの代表取締役を務めた経験を買われ，被告Ｙ３及び被告Ｙ２と友人関係にあったこと等から，被告アゼスタの代表取締役に就任したにすぎない。被告Ｙ１には，被告アゼスタの代表取締役就任以前にデータベースやプログラムの開発に関与した経験は全くなく，その専門的知識も何ら持ち合わせていなかった。実際に，被告Ｙ１は，被告ＣＤＤＢの早期販売のためにやむを得ず，独自に収集したデータに加えて，被告アゼスタ社内にあった原告ＣＤＤＢのメンテナンスＣＤのデータの一部を利用することとした際にも，当該データをそのまま被告ＣＤＤＢで利用するのではなく，そのまま利用しても顧客からクレームの対象になるだけであるから，旅行業者向けのデータベースに格納する情報としては当然かつありふれた客観的なデータの正誤を確認し必要な修正等を加えた上で利用するように指示していたにすぎない。そして，被告Ｙ１としては，被告ＣＤＤＢが被告アゼスタの独自の設計思想に基づき開発され，その体系的構成は原告ＣＤＤＢと大きく異なっている以上，客観的データの一部を修正して利用する行為は，自由競争の範囲内の行為として当然許容されると認識していたものである。
以上からすれば，被告Ｙ１には，原告の企業秘密に接する機会がなかったことに加えて，そもそも原告の営業活動を違法・不当に侵害する故意などなく，被告ＣＤＤＢの開発・販売に際して，原告の著作権侵害とならないように慎重な配慮も尽くしているから，過失もない。したがって，被告Ｙ１に不法行為は成立しない。
イ被告Ｙ５の責任につき
被告Ｙ５は，被告システムのデータベース開発を担当していたところ，被告Ｙ１の指示を受けて，被告アゼスタが独自に収集したデータに加えて，原告ＣＤＤＢのデータのうち，旅行業者向けのデータベースに格納する情報としては当然かつありふれた客観的なデータについて，必要な修正等を加えた上で利用することにした。確かに，被告Ｙ５としては，長年翼システムにおいて原告ＣＤＤＢの開発に携わっており，原告ＣＤＤＢの内容を熟知してはいたが，翼システムから原告ＣＤＤＢのメンテナンスＣＤを含めデータベース設計資料等の機密情報を持ち出しすようなことは一切していなかったし，被告ＣＤＤＢが被告アゼスタの独自の設計思想に基づき開発され，その体系的構成が原告ＣＤＤＢと大きく異なっている以上，旅行業者向けのデータベースに格納する情報としては当然かつありふれた原告ＣＤＤＢの客観的データの一部を修正して利用する行為は，自由競争の範囲内の行為として当然許容されると認識していた。
以上からすれば，被告Ｙ５は，そもそも原告の営業活動を違法・不当に侵害する故意などなく，被告ＣＤＤＢの開発・販売に際して，原告の著作権侵害とならないように慎重な配慮も尽くしているから，過失もない。したがって，被告Ｙ５に不法行為は成立しない。
なお，原告は，被告アゼスタの行為は，被告ら個人としての行為でもあると評価することができ，被告らに不法行為ないし共同不法行為が成立するとも主張しているが，被告アゼスタの役員でもなく被告Ｙ１の指示に従って被告ＣＤＤＢの開発に関与していた被告Ｙ５に，被告アゼスタの会社としての行為の責任を帰責させるべきではなく，この意味でも不法行為ないし共同不法行為は成立し得ない。
ウ被告Ｙ３，被告Ｙ２，被告Ｙ４及び被告Ｙ６の責任につき被告Ｙ３，被告Ｙ２，被告Ｙ４及び被告Ｙ６は，被告システムの営業担当であり，そもそもデータベースの設計や構造を含む開発に関する知識を持ち合わせていない。被告Ｙ３は，翼システム時代に開発に関する会議に参加していたことはあるが，それも顧客目線でどのような画面であれば見易いか等の営業の立場からのアドバイスをしていただけで，それによってデータベース開発の知識を習得していたものではない。被告システムの開発においても，被告Ｙ３，被告Ｙ２，被告Ｙ４については，単純なデータ入力作業の一部を手伝うことはあったが，それ以上に被告システムの開発には特に関与しておらず，その開発経過については知らないし，原告システムのデータが一部利用されていることも特に認識していなかった。また，被告Ｙ３，被告Ｙ２，被告Ｙ４及び被告Ｙ６は，原告の顧客リストの持ち出しなどもしていない。被告Ｙ３，被告Ｙ２，被告Ｙ４及び被告Ｙ６は皆，自分が探索した顧客名やその担当者については，何度も通っており当然頭の中で覚えていたし，一般に流通している旅行業者名簿を見れば簡単に連絡先も探すことができたことから，顧客リストなど不要であり，わざわざ持ち出す必要もなかった。
さらに，被告Ｙ３，被告Ｙ２，被告Ｙ４及び被告Ｙ６は，原告システムのインストール用ＣＤを所持し取扱うことは会社から一切許されておらず，納品などのインストール作業はサポート部門に依頼するという社内ルールがあったため，被告Ｙ３，被告Ｙ２，被告Ｙ４及び被告Ｙ６がこれを手にしたことなど一度もなく，管理も厳重であったため所在すら知らなかったし，顧客へのデモンストレーション用に使っていたＰＣについても，原告退職時に返却又は退職後は特に使用していない上，インストールされているデータをコピーして持ち出すこともしていないしその方法すら知らなかった。
何よりも，被告Ｙ３，被告Ｙ２，被告Ｙ４及び被告Ｙ６は，顧客からの度重なるクレームにも対応しない原告システムの内容に強い不満を持ち，顧客のためよりよい製品を提供したいという思いから，原告を退職し，各々に集まり被告アゼスタの設立に尽力した者たちであるから，原告システムを単にコピーした商品を販売する意思など毛頭なかったし，そのようなことを行えば再びクレームに晒されるだけということも十分に自覚していた。特に，被告Ｙ６については，被告システムの当初版の販売開始（平成１８年６月）及び２００６年版の販売開始（平成１８年１１月）後の同年１２月に入社したものである。このように，入社時期から考えて被告システムの開発には全く関与していないことは明らかであるし，最新の顧客リストやインストール用ＣＤの最新版等を持ち出したこともなく，被告ＣＤＤＢのデータ入力作業には一切関与していないのである。なお，被告Ｙ６は，被告Ｙ２ら他の営業担当者から積極的な引き抜きの勧誘を受けたものではなく，原告の顧客不在の営業方針に失望して自らの意思で退社し被告アゼスタに入社したものである。
したがって，被告Ｙ３，被告Ｙ２，被告Ｙ４及び被告Ｙ６に不法行為が成立する余地はない。
エ被告アゼスタの責任につき


被告アゼスタについては，上記のとおり，被告Ｙ１，被告Ｙ５，被告Ｙ３，被告Ｙ２，被告Ｙ４及び被告Ｙ６のいずれにも故意・過失はなく，その使用者たる被告アゼスタにも不法行為は成立しない。４争点(4)(原告の行為の独占禁止法違反の可能性の有無）について〔被告らの主張〕
仮に，原告システム及び被告システムのような，行程表・見積書の作成及び出力，売上・集計・顧客管理のトータルサポートを可能とする旅行業向けシステムを開発・販売している業者が原告と被告アゼスタの二社のみで，寡占状況となっているとすれば，原告の本件訴えの提起による被告ＣＤＤＢの差止請求及び損害賠償請求は，原告一社による市場独占を企図するものと考えられ，競争原理を機能させずに利用者にとっての利便性向上を著しく阻害する結果をもたらすものであるから，まさに，同業者である被告アゼスタの事業活動を排除することにより，公共の利益に反して，一定の取引分野における競争を実質的に制限するものに他ならず，独占禁止法２条５項，３条に違反している可能性すらある。この意味でも，原告の請求は速やかに棄却されるべきである。
〔原告の主張〕
被告らは，独占禁止法違反の可能性を指摘し，原告の請求は速やかに棄却されるべきであると主張するが，訴えの提起が私的独占となる理由は全くない。訴えの提起によって旅行業システムに関する市場への参入を制限しているわけではないし，被告アゼスタの事業活動を支配しているわけでもない。また，原告による訴えは著作権の権利行使であり，そもそも独占禁止法の適用は除外される（独占禁止法第２１条）。
５争点(5）（被告らの損害賠償義務の有無及び原告の損害額）について〔原告の主張〕
(1)被告らの損害賠償義務
前記のとおり，被告らは，原告ＣＤＤＢをデッドコピーした上，若干の変更を加えて被告ＣＤＤＢを作成し販売してきているものであり，原告ＣＤＤＢの著作権侵害ないし原告の法的に保護された利益を侵害する一般不   法行為について，故意ないし過失がある。
そして，原告は，被告らが被告ＣＤＤＢを含む被告システムを販売したことにより，以下の損害を被ったものであるから，被告らは，著作権法１１４条１項ないし民法７０９条により，以下のとおり，原告に生じた損害を賠償する義務を負う。
(2)原告の逸失利益
ア原告システムと被告システムとの関係
被告らは，被告システムを平成１８年６月頃から平成２２年１１月頃に至るまで，ユーザーに対して，少なくとも５００本（少なくとも当初版２２本，２００６年版７８本，現行版４００本）販売し（甲５３），各販売先のユーザーと更新データを提供するデータメンテナンス契約を締結している。
被告システムにおいて被告ＣＤＤＢは必須なものであり，被告ＣＤＤＢがなければ，ユーザーが被告システムを購入することはない。また，原告ＣＤＤＢや被告ＣＤＤＢのような観光施設，宿泊施設，道路，各種交通機関の時刻表等の様々な情報をデータベースとして備え，旅行業者向け行程表が作成できるシステムは，パッケージソフトウェアとしては原告システムと被告システム以外には市場に存在せず，原告システムと被告システムには，あるユーザーに対して被告システムが販売されなければ，当該ユーザーに原告システムが販売され，原告と当該ユーザー間に更新データを提供するデータメンテナンス契約が締結される，という関係がある。したがって，被告ＣＤＤＢを含む被告システム５００本の販売により，原告は原告システム５００本の販売にかかる利益及びデータメンテナンス契約にかかる利益を失ったものであり，かかる逸失利益は原告が被った損害となる。
原告の逸失利益は，原告システム１本分及び原告のデータメンテナンス１件分につき失われた売上額から，それぞれ原告システムの製造・販売のための変動経費又はデータメンテナンスのための変動経費を控除した限界利益につき，５００本分を計算すべきことになる。
イ被告システムの販売にかかる原告の逸失利益（原告システム販売に関する損害額）
被告システムの販売にかかる原告の逸失利益は，原告システム「旅行業システムＳＰ」のＴＲ－Ｐ４（甲６８）に基づいて計算すべきところ，詳細は以下のとおりである。
被告システムである「旅ｎｅｓＰｒｏ」は，検索業務，行程・見積業務，売上・集計業務が全て含まれるシステムであるところ（甲１の２），これに対応する原告システムである「旅行業システムＳＰ」の基本システムのタイプはＴＲ－Ｐ４である（甲５９，６８。なお，平成１９年９月以降，「ＴＲ－ＳＰ４」にバージョンアップされ，その標準価格はいずれも２２０万円である。以下，「ＴＲ－Ｐ４」と「ＴＲ－ＳＰ４」を併せて「ＴＲ－Ｐ４等」という。）。上記のとおり，被告システムの販売により，原告システムである「旅行業システムＳＰ」の基本システムであるＴＲ－Ｐ４等の販売にかかる利益が失われる関係にあるので，原告の逸失利益はＴＲ－Ｐ４等に基づいて，計算すべきである。
ただし，被告システムの販売が開始された平成１８年６月以降は，原告も被告システムの販売価格に対抗するため原告システムの値下げを余儀なくされたことを考慮すると，平成１８年当時の原告システムＴＲ－Ｐ４の販売価格及び限界利益を前提に原告の逸失利益（損害）を算定すべきである。
平成１８年１月から１２月までの原告システムＴＲ－Ｐ４は３７台販売され，その売上総額は７１２７万８０７４円であるので，平均実売価格は１台あたり１９２万６４３４円となる（甲６９）。
平成１８年度（１月から１２月まで）における原告システム販売の限界利益率は以下のとおり少なくとも８３．４％であるので，原告システム１台を販売することによる限界利益は少なくとも１６０万６６４６円となる（甲６９）。
原告の平成１８年度（１月から１２月まで）の原告システム関連の売上高は２億２１６６万７１５４円であり，原告システムの製造販売にかかる，変動経費は，仕入高，残債，販売手数料，販促費・リース料Ｓ，販促費・その他，インセンティブ，外注費，物流費であり，その合計は３６８３万２０４５円となる。


平成１８年度の原告システムの売上高２億２１６６万７１５４円に対する上記変動経費合計３６８３万２０４５円の比率は，１６．６％となる。したがって，原告システムの限界利益率は，８３．４％となる。被告システム販売にかかる原告の逸失利益（損害）は以下のとおりとなる。
１９２万６４３４円（原告システムの平均実売価格）×５００（本）×０．８３４（限界利益率）＝８億０３３２万２９７８円ウ被告システム販売にかかる原告の逸失利益（原告システムのデータメンテナンス契約についての損害額）
データメンテナンスは，原告システムを導入するユーザーとの間で毎月ユーザーに更新データを提供するためのもので，１本あたり月額６０００円で提供される。この月額料金は平成１８年１月時点から現在に至るまで変わっていない。
平成１８年度（１月から１２月まで）における原告における全システムに関するデータメンテナンスの限界利益率は，以下のとおり少なくとも８０．６％であり，原告システムのデータメンテナンスの限界利益率も少なくとも８０．６％と考えられる（甲６９）。
原告の平成１８年度（１月から１２月まで）のデータメンテナンスの売上は１０億４７４２万９０８８円であり，データメンテナンスにかかる変動経費は，仕入高，残債，販売手数料，販促費・リース料Ｓ，販促費・その他，インセンティブ，外注費，物流費であり，その合計は２億０３０９万８４５１円となる。
平成１８年度の原告におけるデータメンテナンスの売上高１０億４７４２万９０８８円に対する上記変動経費合計２億０３０９万８４５１円の比率は，１９．４％となる。
したがって，原告におけるデータメンテナンス契約の限界利益率は，８０．６％となる。
原告システムのデータメンテナンスに関する逸失利益（損害）は以下のとおりとなる。
被告らは，被告システムを少なくとも以下のとおり５００本（平成１８年度に少なくとも当初版２２本，２００６年版７８本合計１００本，平成１９年度から２２年度までに現行版を各年度少なくとも１００本合計４００本）販売し，各販売先とデータメンテナンス契約を締結していることから，データメンテナンス契約についての逸失利益にかかる原告の損害は以下の計算により少なくとも８７０４万８０００円となる。
(ｱ)平成１８年度   ５８０万３２００円
平成１８年度における被告の販売本数は，当初版が２２本，２００６年版が７８本の合計１００本である。したがって，原告の損害額は，次のとおり，５８０万３２００円となる。
６０００円×１２（か月）×１００（本）×０．８０６＝５８０万３
２００円
(ｲ)平成１９年度   １１６０万６４００円
平成１９年度における被告の販売本数は，当初版が２２本，２００６年版が７８本，現行版が１００本の合計２００本である。したがって，原告の損害額は，次のとおり，１１６０万６４００円となる。６０００円×１２（月）×２００（本）×０．８０６＝１１６０万６
４００円
(ｳ)平成２０年度   １７４０万９６００円
平成２０年度における被告の販売本数は当初版２２本，２００６年版７８本，現行版２００本の合計３００本である。したがって，原告の損害は，次のとおり，１７４０万９６００円となる。
６０００円×１２（月）×３００（本）×０．８０６＝１７４０万９
６００円
(ｴ)平成２１年度   ２３２１万２８００円
平成２１年度における被告の販売本数は，当初版２２本，２００６年版７８本，現行版３００本の合計４００本である。したがって，原告の損害は，次のとおり，２３２１万２８００円となる。
６０００円×１２（月）×４００（本）×０．８０６＝２３２１万２
８００円
(ｵ)平成２２年度   ２９０１万６０００円
平成２２年度における被告の販売本数は当初版２２本，２００６年版７８本，現行版４００本の合計５００本である。したがって，原告の損害は，次のとおり，２９０１万６０００円である。
６０００円×１２（月）×５００（本）×０．８０６＝２９０１万６
０００円
エ小括
以上から，原告の逸失利益にかかる損害額合計は，以下のとおり８億９０３７万０９７８円となる。
８億０３３２万２９７８円＋８７０４万８０００円＝８億９０３７万０
９７８円
(3)弁護士費用
相当な弁護士費用は２０００万円を下らない。
(4)損害額の合計
上記(2)及び(3)の合計額は９億１０３７万０９７８円となる。
(5)予備的主張に係る損害額
予備的主張（一般不法行為）に係る損害額も，上記著作権侵害に基づく損害額と同額である。
〔被告らの主張〕
(1)原告の主張(1)は否認する。被告らに著作権侵害ないし一般不法行為についての故意ないし過失がないことについては，前記４争点(4)〔被告らの主張〕のとおりである。
(2)原告の主張(2)ないし(5)は，否認ないし争う。ア被告システムは，平成１８年６月から平成２４年１２月までの６年６か月もの期間をかけて，当初版・２００６年版，現行版，新版と順次改良され，被告ＣＤＤＢ部分はもちろんのこと，その他のデータベースについても，データベースの構造はもちろんデータの数・内容も大幅に変更しており，さらにはプログラムにも改良が加えられている。しかるに，原告は，これらの違いを全く考慮せずに，当初版，２００６年版，現行版の全ての販売数について損害賠償を求めているが，およそ因果関係は認められない。また，原告は，その著作権が侵害されたと主張する対象について，当初原告システム全体としていたものを，訴えの変更により原告ＣＤＤＢへと大幅に縮小したにもかかわらず，当該著作権侵害による損害額については，原告システム全体を前提とした金額から一切減額しておらず，整合性がない。


原告が問題とする原告ＣＤＤＢは，行程・見積機能が参照する一部のデータしか有しておらず，当該部分は，原告システムの旅行業者向けシステムとしての本質的機能が「旅行業者がその業務を遂行する上で必要不可欠な行程表・見積書の作成及び出力，売上・集計・顧客管理のトータルサポート」というところにあることからすれば，わずか一部分にすぎない。テーブル数及びフィールド数についても，原告システムに係るデータベースが合計６０個のテーブル（４６個のマスターテーブル及び１４個のエントリーテーブル）を有し，合計９３８個のフィールドを含んでいたのに対し，原告ＣＤＤＢは原告の主張によっても４２個のマスターテーブルと４０５個のフィールドを有するに留まっている。
しかも当然ながら，実際のデータベースは，デジタルデータの集合体とこれを管理・処理するコンピュータ・プログラムとが不可分一体となって稼働するものであり，本件の旅行業者向けシステムもデータベースとプログラムとが不可分一体となって機能するところ，原告システムと被告システムとはそのデータベースのみならずプログラムについても全く異なっており，かかるプログラム上の差異から生じる機能の違いも極めて大きい。以上の点を考慮すると，仮に万一著作権侵害又は不法行為の事実が認められるような場合であっても，原告が主張する損害はそのほとんど全てが減殺されるべきである。
イ原告は，原告システムの基本システムのタイプはＴＲ－Ｐ４（標準価格は２２０万円）であると主張して，これを前提に限界利益率を算定している。しかし，原告システムは，行程表・見積書作成機能のみのＴＲ－Ｐ１（標準価格は１７０万円）と，ＴＲ－Ｐ１の機能に加えて売上・顧客管理機能（同機能には原告ＣＤＤＢは含まれていない）が追加されたＴＲ－Ｐ４とがあり，原告ＣＤＤＢは，行程表・見積書作成機能部分のみにしか含まれていないから，標準価格でＴＲ－Ｐ１を５０万円も上回るＴＲ－Ｐ４の販売価格を基準として損害額を算定するのは明らかに過大であって，不当である。
さらに，原告は，標準価格を大幅に下回る値引きを行っており，自ら標準価格「１本２２０万円」と主張する原告システムを７０万円にも満たない金額（標準価格の３０％以下）で顧客に販売している（乙３２）。この点に関して原告は，被告システムの販売が開始された平成１８年６月以降は，被告システムの販売価格に対抗するため原告システムの値下げを余儀なくされたなどと主張するが，全く事実に反する。被告システムが販売される平成１８年６月以前も，原告システムは，標準価格を大幅に下回る金額で販売されており（乙３６の１～２６），ＴＲ－Ｐ１のみならずＴＲ－Ｐ４をも含めた合計３０本の販売数の平均販売価格は約１０６万円にすぎない。原告は，何ら客観的資料も示さずに報告書（甲６９）のみを根拠として，平成１８年１月から１２月までの原告システムＴＲ－Ｐ４は３７台販売されその売上総額は７１２７万８０７４円であり，平均実売価格は１台当たり１９２万６４３４円となる，などと主張するが，翼システムが標準価格の半額近くまで大幅に値引きして原告システムを販売してきた実績（ＴＲ－Ｐ１及びＴＲ－Ｐ４が標準価格で販売されたことは一度もない。）からすれば，到底信用できない。
また，旅行業者向け行程表作成システムを販売する業者は被告アゼスタ以外にも存在するし，旅行業者全体の傾向として団体旅行の激減，インターネット等の普及により，旅行業者を通さない個人での予約の増加に伴い，売上減少，経費削減を強いられている中，データメンテナンスも十分に行われないパッケージソフトウェアが，平成１８年当時の価格を維持できるはずがない。
したがって，そもそも原告システムのＴＲ－Ｐ４ではなくＴＲ－Ｐ１の販売価格によらなければ不合理であるし，ＴＲ－Ｐ１の販売価格についても，標準価格（１本１７０万円）ではなく，大幅に値引きされて販売されている事実に即した実売見込価格によるべきであるから，原告の主張は失当である。
ウ原告は，平成１８年１月から現在に至るまでデータメンテナンスの月額料金は１本６０００円であると主張するが，事実に反する。実際は月額２０００円で顧客とデータメンテナンス契約を締結している（乙３３）。さらに，被告システムが販売される平成１８年６月以前も，原告システムのデータメンテナンス料金は，大きな値引きがされており，合計２９本のデータメンテナンス契約の平均料金は約１８１０円にすぎない（乙３６の１～２６）。
したがって，月額６０００円のデータメンテナンス料金を前提として逸失利益を算出する原告の主張も失当である。
(3)被告らの主張
原告は，観光施設，宿泊施設，道路，各種交通機関の時刻表等の様々な情報をデータベースとして備え，旅行業者向け行程表が作成できるシステムは，パッケージソフトウェアとしては原告システムと被告システム以外には市場に存在せず，原告システムと被告システムには，被告システムが販売されなければ，当該ユーザーに原告システムが販売され，さらに原告と当該ユーザー間にデータメンテナンス契約が締結されるという関係があると主張するが，以下のとおり，そのような事実は全くない。


まず，旅行業者向け行程表作成システムは，原告システム及び被告システム以外にも，株式会社エヌシステムのＪＡ旅行センター向け旅行業営業支援システ   ム「応   援団く   ん」，   株式会   社ＪＭ   Ｃの国   内行程   表管理   システ   ム#$%&'」，株式会社全旅の観光商品流通システム「ＡＮＴＡ－ＮＥＴ」，株式会社ワールドエキスプレスの国内／海外旅程表作成・見積集計の旅行業支援システム「()*+」などがあり（乙３５の１～４），現に上記各社は，被告アゼスタとも原告とも競合している。さらに，その他にも行程表・見積書作成業務支援システム「旅の助」を展開する株式会社エイブルシステムズや「シンフォニーアトゥー」を展開する株式会社ウィ・キャンなど（乙３５の５～６），シンプルな行程表作成機能ではあるが団体旅行が激減した昨今ではかえって業者ニーズに即しており，競合することも多くなっている。被告システムは，原告システムと同額以上で販売しているところ，仮に単に原告システムのデータベースをコピーしただけの模倣品レベルのものであれば，原告システムの既存ユーザーからすれば，会社規模も資本規模も被告アゼスタとは比較にならないほど大きい原告が販売するシステムから新興の企業で資本規模も原告の約５６０分の１，従業員数もパートを含め１２名にすぎない被告アゼスタが販売するシステムにあえて乗り換える必要がない。データベースシステムについては，格納されているデータがいかに正確で，きちんとメンテナンスが施されているかが顧客にとって最重要であるところ，会社規模・資本規模の小さな会社のシステムを導入することは将来のメンテナンスに不安を覚えるのが通常であるからである。被告システムに変更した原告ユーザーからは，変更の理由として，商品開発力の不足（バージョンアップがほとんどなく導入時から全く仕様が変わっていない等），データメンテナンス更新ペースの遅さ（新東名高速等料金情報が遅い，観光・宿泊施設における追加，修正，削除要望には全く応えられない等），データが不正確（道路料金・施設入場料金データの誤りが多い，倒産・廃業した観光・宿泊施設データが何年も放置されている等），サポート体制の不十分さ（急な障害対応や操作説明を受けたくてサポートセンターに連絡しても，旅行業システムは即対応不可なので後で担当者から連絡させると回答され業務が止まってしまう等）などが挙げられており，原告システムの顧客が離反するのは，被告システムの存在が原因なのではなく，専ら原告システムの顧客満足度の低さに起因しているのである。
一方で，被告アゼスタは，その営業担当者は全員旅行業界出身で旅行業システム販売にも１０年ないし１５年のキャリアを持っており，熱意もあって，業界の動向や顧客の要望に対する理解力に優れており，これらのフィードバックを受けてシステム開発を行うことから，正確かつ迅速なメンテナンスが施され，継続的にデータの量・質ともに向上していることに加え，被告システムは原告システムに比して機能面やサポート体制が充実しており優位性が極めて高く，先進性・利便性・サポート面等のトータルで優れたシステムとして高い支持を受けている。したがって，被告システムには，データベースの内容だけに限定されない商品価値があり，被告アゼスタの弛まぬ開発努力やサポートを含めた営業努力が販売に大きく貢献しているのである。他方で，旧原告会社では，主力の営業担当者が多数退職したため，入社間もない新人や他部署から配属された，旅行業務や旅行業務システム販売の経験の少ない従業員が営業担当とならざるを得ず，これが販売数低下を招く大きな原因の一つになったと考えられる。
以上のとおり，被告システムが販売されなければ，原告システムが必然的に購入され，データメンテナンス契約も締結されるという因果関係は存在しない。
第４当裁判所の判断
１前記第２，１の前提事実並びに証拠（甲１～８１，乙１～４３，証人Ｂ，証人Ａ〔下記措信しない部分を除く〕，被告Ｙ５本人，被告Ｙ２本人，被告Ｙ３本人）及び弁論の全趣旨によれば，以下の事実が認められ，同認定を覆すに足りる的確な証拠はない（なお，各段落の末尾に主要な証拠を掲記した。）。(1)原告ＣＤＤＢを含む原告システムの開発の経緯及びその開発，営業活動等についての被告Ｙ５，Ａ，被告Ｙ２，被告Ｙ３，被告Ｙ６，被告Ｙ４の関与
の状況について
ア原告システムは，現在も原告において旅行営業課の課長代理として原告システムの販売を担当するＢ（以下「Ｂ」という。）が翼システムに入社して間もない平成６年４月頃に，当時の同社代表者に対して旅行業システムの制作販売の提案をし，これを代表者が了承したことから，その開発に着手されることとなったシステムである。


被告Ｙ５は，それに先立つ平成２年４月２２日に翼システムに入社した。被告Ｙ５は，翼システムに入社する以前，昭和６１年から他社で設計書を基にプログラムを行うプログラマーとして稼働し，翼システムにおいても電装システムの設計，検収等の業務を行ってきたことから，翼システムにおいて原告システムの制作が決まり，社員を集めて原告システムの開発プロジェクトが組織されたことを契機にそのリーダーとなった。Ｂが原告システムの開発の提案をするに当たって，そのきっかけとなったのは，株式会社小田急トラベル（以下「小田急トラベル」という。）からの要望にあった。同社においては，それまで，団体旅行の行程表の作成のほとんどを，従業員の手作業で行っていたところ，大型バスの使用の際の通行道路の所要時間計算や，途中のドライブインの検索等に時間を要し，手作業でこれらを行うため，一件の行程表作成に２０時間ほども要しているという実情にあった。そこで，同社では，パソコンを用いてこれらの業務を効率化したいとの要望が強かったものの，これに適するソフトウェアが当時存しなかったことから，それを可能とする団体旅行の行程表作成用のソフトウェアが作成されたならば，使用したいとの要望が示されていた。そこで，被告Ｙ５及びＢは，小田急トラベルに対し，原告システムの開発のため，状況調査のヒアリングを行い，さらに，平成７年（１９９５年）１月１０日に小田急トラベル社内で行われた原告システム開発プロジェクトの打合せに参加したところ，同打合せにおいて，小田急トラベルの状況調査の結果が報告された。そこでは，同社における行程表作成には上記の問題点があることのほか，同社においては，顧客と打ち合わせた結果作成された行程表の最終原稿のみを，ワープロや表計算ソフトを使用して浄書して保管し，その後に要望が似通う旅行行程表作成の必要があったとき，その要望と類似する上記最終原稿を探し出し，これを変更して使用しているが，その検索にも手間がかかる上に，旅行目的（例えば「女性のグルメ旅行」等）に応じた必要な情報の検索もできない状況にあること等が問題であることが報告された。そして，同社において，行程表作成の際に使用している資料及びその使用方法は，まず「全国道路地図」を用いて旅行行程についての大まかなコース作りをし，次に観光バスキロ程図のある「ＲｏａｄＭａｐ」（以下「ロードマップ」という。甲４７）を用い，行程に沿って時間を加算して所要時間を算出し，更に料金ガイド，ＪＴＢ宿泊情報等を用いて，必要な料金等を算出していた。同社によれば，団体旅行に使用される交通機関は，貸切バスの使用が６割，鉄道利用が２ないし３割，航空機使用が１ないし２割で，旅行人数は３０名程度での利用が最も多く，多くは１０ないし４０名程度であること，旅行行程の作成の相談に当たっては，出発地，到着地及びその時間をまず確定して，それから観光地や昼食地を選ぶことが多く，交通機関として貸切バスを使用するのであれば，９０ないし１２０分走行したところで休憩ないし昼食地を探す必要があること，一般的な出発時刻，到着時刻は，それぞれ９時頃，１６時頃であること，使用するホテル等の宿泊施設には，ホテル・旅館・民宿・ペンションの種類区分とエコノミー等の料金カテゴリーが必要であり，部屋や食事の内容，風呂の内容や大きさ，料金，宴会場の空きがあるか等が選択項目選定の際のポイントであり重要な情報となること，検索は５ないし６程度の項目とすること等が，原告システムの制作に当たって有益な情報として打合せにおいて紹介され，今後，その要望に沿ったデータベースである原告ＣＤＤＢを含む原告システム（以下，原告システムの開発という場合には，必要なデータベースである原告ＣＤＤＢの開発も含む。）の開発スケジュールが組み立てられることとなった。〔被告Ｙ５尋問調書１頁，
甲６３の別紙１〕
イ平成７年７月には，Ａが翼システムに入社し，原告システムの開発にプログラマーとして参加し，データ加工を担当することとなった。そして，原告システムのホテル・旅館のデータについては，社団法人日本観光協会，実業之日本社からデータの提供を，観光施設については社団法人日本観光協会からデータの提供を，それぞれ受けることとなった。〔乙３８，２頁，
甲６３の別紙１，２〕
同年１１月９日の時点における，当時進行中の原告システムの開発状況は，行程表のプログラムについては，道路検索について作り直しの途中であり，同月末には終了予定とされ，道路データに関して，国道のデータ入力は終了したが，有料道路は東京，神奈川，千葉，埼玉，静岡は全て終了したものの，それ以外の地域は道路名称のみの入力が終了した段階で，市町村道については未だ７００件以上の代表地点のデータが入力されていない状況であった。ホテル・旅館のデータについては，観光施設について社団法人日本観光協会から提供を受けたデータの間違いについて折衝を続けること，収容人数に関するデータも追加することなどが決められた。〔甲
６３の別紙３〕
そして，同年１２月ないし平成８年１月に，原告システム（当時の名称は「スーパーフロントマン旅行業システム」）の販売が開始された後も，翼システムにおいては，原告システムの充実改良が引き続き行われた。そこにおいて，Ａは，原告システムの新機能の追加や改良等を担当した。その後，Ａは，翼システムにおいて，システムエンジニアとして認められて主任となり，平成９年ころからは，原告システムのシステム設計やプログラム開発を手がけ，原告システムに関するリーダーであった被告Ｙ５のもとで，サブリーダーとなった。〔乙３８，２頁〕
ウ被告Ｙ２は，昭和６２年から旅行業者や旅行業者に業務システムを販売する会社等に勤務して，その間，旅行業者向けトータル業務のシステム販売業務に従事し，旅行業務システム仕様と構築ノウハウを修得していたが，平成８年２月に翼システムからヘッドハンティングを受けて同社に転職した。被告Ｙ２は，翼システムに入社後，原告システムの販売・サポート体制の構築に従事することとなり，平成９年１０月ころまでには主任となり，営業成績優秀者表彰を７度受けた。〔甲６３の別紙８，甲７８，６頁，乙
４０，１２頁〕
エ被告Ｙ３は，昭和６１年からは旅行業者に勤務して旅行業務の営業等を行った後，平成８年１２月に翼システムに入社し，入社後，原告システムについてシステムサポートを担当することとなり，平成１０年１月ころからは同社営業課でシステム営業を担当することとなった。〔甲７８，６頁，
乙４１，５頁〕
オ平成９年１月６日に被告Ｙ６が，平成９年１２月２４日に被告Ｙ４が，翼システムに入社した。〔甲７８，６頁〕
カ被告Ｙ５らが参加した平成９年２月１５日の原告システムの開発に関する打合せにおいて，原告システムの改良について話し合われ，例えば，道路データは詳細地点を増やすなど，今後も地道に精度を上げていく努力をする旨が決定され，データ管理のコントロールについて，サポート担当の被告Ｙ６が当たることとなった。


同年３月１９日時点での原告システムに関する人的体制として，データコンテンツの作成について，派遣の者６名が当たっていたが，同年４月以降，これを道路データに３人，時刻表メンテナンスに２人，観光施設データに６人，ホテルデータに１人の合計１２人に増員することとされた。また，データ開発システムに関しても，同年４月以降，設計にシステムエンジニア１人，プログラムに関しプログラマー１人を当てることとされた。その他，同年３月時点で，原告システムの基本パッケージに関する業務に当てられるシステムエンジニアとして，被告Ｙ５，Ａのほかに翼システムの社員１名，外注の者１名，プログラマーとして翼システムの社員２名，外注の者１名が当てられている状況であったが，これを引き続き維持することとされた。また，物的設備については，データ開発用，プログラム開発用兼テスト機，サーバー機として各１台の合計３００万円，クライアント機として，各８台の合計６４０万円の設備投資（ソフトウェアを含む）を行うことが決定された。〔甲６３の別紙５，甲７８〕被告Ｙ６は，平成９年５月１３日にＡらとの間で行われた原告システムの開発業務に関するインタビューにおいて，入金一覧表の帳票イメージについての回答をするなどした。〔甲６３の別紙４，６〕また，被告Ｙ３は，平成１０年１月１４日に，原告システムについての包括料金特約についての提案をするなどした。〔甲６３の別紙１１〕キ平成１０年８月２９日，Ｂのほか，被告Ｙ５，Ａ，被告Ｙ２，被告Ｙ６が参加して原告システムについての営業会議が行われ，原告システムについての不具合点やこれについての改善案の提案がされた。同会議において，原告システムの顧客管理機能の充実を図る必要があるとされ，例として，「法人客の場合は，創立記念旅行に行くことが多いので『創立記念日』での検索等を出来るように検討する」ことなどが今後の検討項目とされた。また，鉄道や航空料金に関しても，乗継ぎ料金の計算，普通運賃の計算が正確にできるように運行キロ数で計算処理すること，ローカル線の駅データも入力していくこととされた。〔甲６３の別紙１４〕さらに，今後の検討事項の一つとして，作成した行程表を地図と連動させることで，地図上に行程の経路の表示を可能とすること，祭りやさくらんぼ狩り，カニ食べ放題など，観光施設の検索条件が設定できるよう検討していくこと，宿泊施設の検索には，露天風呂やサウナが重要なキーであり，これらがある旅館を検索することができるようにすることなど，今後も宿泊施設のデータベースの改善を検討していくこととされた。また，旅行代理店は，兼業でバス会社等を営業していることも多く，バス運行管理システムについての要望があった旨も紹介された。〔甲６３の別紙１４〕ク平成１１年１０月１６日，被告Ｙ５，Ａ，被告Ｙ２，被告Ｙ６らが参加して原告システムの商品会議が行われ，今後のバージョンアップに向けてユーザーアンケートを行うこと，観光，ホテルの検索結果からＵＲＬに移行できるようにインターネット機能を強化すること，検索パレットは「駅・空港・フェリー」・「市区町村」・「道路地点」のみとすること，利用施設一覧表に休館日を表示した休館日チェックリストを追加すること等の機能強化の方針が打ち出された。〔甲６３の別紙１９，２０〕ケ平成１２年２月１２日，被告Ｙ５，Ａ，被告Ｙ２，被告Ｙ３，被告Ｙ６らが参加して原告システムの商品会議が行われ，原告システムの当時の次期商品としてVer5の提案がされ，そこでは，原告システムをプロアトラスの地図を利用した旅行業システムとする方針で開発することとし，行程表の検索結果のルートを地図で表示し，地図から温泉地・施設が検索できるようにするため，その技術サンプルを被告Ｙ５が作成することとされた。
〔甲６３の別紙２２〕
コ平成１２年６月，被告Ｙ５が文具・事務機システムのリーダーに転出すると，Ａが原告システムの開発，改良に関する責任者となり，旅行代理店のヒアリング，要件定義，システム設計，データベース設計，開発等を行った。〔乙３８，２頁〕
被告Ｙ３は，同年８月７日付けで，原告システムの地図機能について，検索フローチャート，表示画面の遷移や地図表示画面との対応関係等についての提案を行い，同月２１日付けでも，原告システムの地図機能について，検索フローチャート，表示画面の遷移や地図表示画面との対応関係等について，より詳細な提案を行っている。〔甲７５の別紙３～５〕サ平成１２年１０月２８日，Ｂのほか，被告Ｙ２，被告Ｙ３，被告Ｙ４，Ａが参加して原告システムについての営業会議が行われ，原告システムのVer5の全機能についての仕様が決定されて紹介され，販売方法についても協議された。同会議におけるVer5についての紹介では，例えば，検索業務においては，サブメニューが「道路検索」，「時刻表検索」，「ホテル・旅館検索」，「観光施設検索」から，「道路」については「時間・経路・料金」，「時刻表」については「ＪＲ・ＡＩＲ・フェリー」，「施設」については「宿泊」，「観光」，「地図」等のサブメニューが設けられることなどの，Ver4からの改善点が全て紹介されている。加えて，同会議では，当時のユーザーに対するVer5の販売方法について，増設・バージョンアップ時は，リプレースを考慮して販売することとされ，①リース残１ないし２年のユーザーについてはリプレース商談を，②契約後１年未満のユーザーは，営業時の内容によりバージョンアップなどの商談を，③契約１年以上経過のユーザーは，契約時のバージョンで商談をすることとされ，各営業担当者は，担当する顧客のリース終了年月，売買契約書の使用権終了年月を調査し，Ｂに報告することとされた。〔甲７１の別紙６〕シ平成１２年１１月ころから，地図検索機能，インターネット接続機能が追加された「スーパーフロントマン旅行業システム   Ver5」が販売された。
〔甲６３，３頁〕
ス平成１２年１１月２０日，Ｂのほか，被告Ｙ３，被告Ｙ６，被告Ｙ５，Ａが参加して原告システムについての商品会議が行われ，原告システムの今後のバージョンアップに向けて，当時の原告システムのユーザーに対し，ユーザーアンケートを実施し，その結果を反映させることとして，被告Ｙ６がそのアンケートを作成することとされた。〔甲７１の別紙２６〕セ平成１３年６月１８日，Ｂのほか，被告Ｙ６，被告Ｙ５，Ａが参加して原告システムについての商品会議が行われ（なお，被告Ｙ３は参加していなかったが資料が配付された。），原告システムにおいては，観光施設データについて，１施設に４個までの料金しか保存できず，そのうち一番上に登録した料金しか連動できないこと，無料なのか料金設定がないのかが判断できないことが問題とされ，今後の課題とされるとともに，同一施設で複数のレコードが登録されている場合があることも報告された。そして，同一施設は一つのレコードにまとめ，料金を無制限に登録できるようにすること，連動できる料金を選択できるようにすること，無料の場合は「無料」，料金設定なしは「－」を表示するよう，原告システムを改良することとされた。〔甲６３の別紙３４〕


(2)構築された原告ＣＤＤＢの内容
以上のとおりの原告システムの開発当時における聞き取り調査や，販売開始後のユーザーの意見聴取の結果等も踏まえて，旧原告会社は，原告システムに用いられる原告ＣＤＤＢを，平成１７年（２００５年）９月までに，以下のとおり構築した。なお，原告ＣＤＤＢは，２００５年９月版以降，２００６年１１月版までは，テーブル，フィールド及びリレーションに変更はないが，レコード数に若干の違いがある。〔甲３５，１頁〕
ア道路情報の選択について
前記(1)のとおり，原告システムを構築するに当たって実情調査を行った旅行会社である小田急トラベルにおいては，行程の所要時間算出のためロードマップを参照していることが判明していたところ，このロードマップは，貸切観光バスが通行するのに適した道路を選択して道路地点を設定し，隣接道路地点間のキロ数と時間を示した資料である。ロードマップにおいては，有料道路及び国道については名称ないし番号が示されるとともに，主な交差点ないし地名については，その地名とともに黒丸で示され，その黒丸と黒丸との間に，交差点ないし地名間の距離（キロ数）及び所要時間（分）が示されている。〔甲４７〕
しかし，原告ＣＤＤＢの作成に当たっては，まず貸切バスとして通常使用される大型観光バスによる移動に適切な道路の選択を行うこととした。この観点から，国道，高速道路，有料道路，首都高速などの都市高速道路については全ての道路を選択しているものの，都道府県道については約１０％，市区町村道だけでも約３０６万以上に上る一般道路については，そのうちの約０．００４％程度に相当する１４３の一般道路を大型観光バスによる移動に適切な道路として選択し，これを「１０道路テーブル」に格納した。その際，道路番号を付すこととして「道路番号」のフィールドを設けるほか，「道路名」，「道路名読み」，「区分」の各フィールドを設けた。〔甲３，甲３０，
１２～１３頁〕
これを具体的にみると，例えば，県道及び道道の選択において，ロードマップにおいては，福島県については全県道５１６件のうちから１２県道，北海道については全道道１１２８件（なお，平成１８年（２００６年）１１月当時は９１３道路。甲３１の１，２頁）のうちから６４道道を選択しているところ，原告ＣＤＤＢにおいては，これよりも多い，福島県において４７県道，北海道においては８０道道を選択しており，ロードマップと原告ＣＤＤＢとで共通する県道，道道も，福島県について９道路，北海道についても３３道路にすぎない。
次に，これら道路上にとる道路地点の情報についてみると，例えば，北海道の国道２３０号線における例をとると，ロードマップにおいては，選択している道路地点は１４地点であるところ，原告ＣＤＤＢはこれよりも多い２５地点を選択し，このうち共通する道路地点は，５道路地点である。また，九州の国道３号線における福岡県内の道路地点をみると，ロードマップにおいては２７地点であるところ，原告ＣＤＤＢにおいては，これよりも多い４８地点であり，共通する道路地点は３地点にすぎない。〔甲４７，４８〕さらに，原告ＣＤＤＢでは，大型観光バスが移動する経路，経由地，目的地と一応の所要時間，到着時間が示せればよいとの考え方をとり，そのため必要な道路地点情報に絞って選択して格納することとした。これは，実際の自動車の走行を前提として全ての交差点や目的地の道路地点の情報を必要とするカーナビゲーションシステムに比して情報量を少なく済ませることができるものであり，格納すべき情報量は格段に少なくなる。〔甲４３，２頁〕
イ道路地点情報の選択（緯度経度情報）について
(ｱ)次に，原告ＣＤＤＢにおいては，上記道路地点として選択した地点における情報を緯度及び経度のデータとして格納することとしたが，実際の作成については，まず，上記のとおりの大型観光バスが通過するのに適切と考えられる道路のうちの，行程表を作成する上で必要と考えられる適切な地点である，交差点，インターチェンジ，サービスエリア，パーキングエリア，観光施設，宿泊施設，駅，役所等の代表道路地点とするのに適切な地点につき，インターチェンジや観光施設等から最も近い交差点や，ユーザーの要望を充たすのに最も適切な地点を中心に，上記選択された道路上から選び出す作業を行った。
そして，道路上でどの場所を選ぶかが決まると，その具体的な地点についての緯度経度は，実際にその選択作業を行うこととなる原告ＣＤＤＢの作成者自身において，具体的な地点をパソコンのマウスを地図上でクリックする方法で選択し，そこに示される緯度及び経度を，実際に入力する方法をとった。その情報は，「０９地点名テーブル」に格納されている。「０９地点名テーブル」には，「地点番号」，「地点名称」，「地点名称カナ」，「地点区分」，「都道府県コード」，「市区町村番号」，「地点経度」，「地点緯度」の各フィールドが設けられている。〔甲３，甲２８，４～６
頁，甲３０，１４頁〕
上記道路地点の選択は，平成１８年（２００６年）２月版の時点で１万２７８１件，同年１１月版の原告ＣＤＤＢにおいて，１万２８２２件である。〔甲３２，１頁〕
(ｲ)そして，施設と関係する代表道路地点の選択においては，施設が接する道路地点ではなく，当該施設の近辺の道路地点を当該施設の代表道路地点として適宜設定し，その代表道路地点への経路検索をもって，当該施設への経路検索としている。その例として，横浜市中区のホテルニューグランドには，当該ホテルが接する道路ではなく，横浜市中区山下橋が設定され，これとは異なる施設のマリンタワーについても，同じ道路地点が設定され，横浜市中区内では，８か所の代表道路地点を設定しているにすぎない。また，地方では，施設が１０キロメートル以上離れているものについて同一の代表道路地点を，７０以上の施設について，一つの代表道路地点を設定している例もある。このように，施設が道路に接しているところをもって目的地とせず，当該施設の近辺の道路地点を当該施設の代表道路地点として適宜設定して経路検索を行うこととしたのは，施設の数だけ道路地点の情報を持つことは，道路地点の数を膨大にし，経路検索の効率も悪くなるため，あえてこのような構成をとったものである。〔甲４３〕(ｳ)なお，翼システムは，平成８年１月ころに原告システムの販売を開始したが，当初の原告システムには，地図検索機能がなかったため，これら緯度経度情報は，一つのテーブルで保有するのではなく，「０１市区町村テーブル」，「０９地点名テーブル」，「２０ホテル・旅館テーブル」，「２１観光施設テーブル」，「３２駅テーブル」のそれぞれのテーブルで重複して保有していた。


その後，前記(1)で認定したとおり，被告Ｙ２，被告Ｙ３，被告Ｙ４，被告Ｙ５，被告Ｙ６及びＡがその開発ないし営業に関与して，開発・販売された原告システムのVer5において，地図検索が効率的に行えるよう，「０５緯度経度テーブル」を設けることとし，さらにインターネット接続のため「０６ＵＲＬアドレステーブル」，「０７ＵＲＬ種別テーブル」，「０８ＵＲＬ分類テーブル」を設けることとした。しかし，その際，既に原告システムを導入しているが，地図検索機能を必要とせず，新たな原告システムへの移行をしない顧客においても，問題なく使用し続けることができるよう，「０１市区町村テーブル」，「０９地点名テーブル」，「２０ホテル・旅館テーブル」，「２１観光施設テーブル」，「３２駅テーブル」で重複し保有している緯度経度情報を，上記「０５緯度経度テーブル」でも重複保有することとした。地図検索機能を使用すると，地図上で一定の範囲を指定し，「０５緯度経度テーブル」により，その範囲内にある緯度経度の観光施設，宿泊施設，駅，市区町村等を検索して地図上に表示することができる。
「０５緯度経度テーブル」には，緯度経度情報毎に，市区町村，ホテル・旅館，観光施設，地点，駅の各テーブルについての「種別番号」と各テーブルのプライマリー・キーとなる「種別毎番号」の情報を収録するとともに，関連する「０１市区町村テーブル」，「０９地点名テーブル」，「２１観光施設テーブル」，「２０ホテル・旅館テーブル」，「３２駅テーブル」とリレーションを取っている。
ウ道路の接続情報の選択について
(ｱ)原告ＣＤＤＢでは，選択された道路と道路との接続地点には，隣接する道路地点間の各道路について，「１１接続テーブル」において，各接続番号で特定される細切れの道路を接続していくことで，出来るだけ所要時間の短い経路を検索することとした。「１１接続テーブル」には，道路地点間の接続情報として，各細切れの道路の「始点番号」，「終点番号」，通行する道路の「道路番号」，移動に要する「所要時間」，２地点間の「距離」，上り下りの車線情報である「上下区分」，「禁止フラグ」，「接続番号」などの情報を，九つのフィールドに格納した。具体的な距離と時間の算定は，別紙１の「１１接続テーブル」の「原告ＣＤＤＢの各テーブルの概要」欄記載の例のとおりである。〔甲３，甲２３，１１頁〕このうち，上記「接続番号」とは，一つの道路を細分化し，その道路の１単位毎に付与される番号であり，２地点間の情報を識別するものである。この接続番号は，原告システムの作成時に，ある道路の１単位を登録するたびにその都度原告が付与したものである。例えば，伊勢自動車道のうち，関ＪＣＴから芸濃ＩＣまでの区間を接続番号１と，その逆を接続番号２として上下区分により区別し，同じく伊勢自動車道のうち芸濃ＩＣから安濃ＳＡまでの区間を接続番号３とする，等のものである。〔甲２８の７頁及
び別紙８〕
(ｲ)そして，その経路中には，道路条件により，進入禁止，右折禁止，左折禁止などの規制のある場合がある。そこで，原告ＣＤＤＢにおいては，そのような経路が選択されないようにしておくため，「１２禁止乗換テーブル」を設け，そこに選択不可とすべき道路の接続経路，すなわち，ある接続番号からある接続番号への乗換について，禁止されるパターンの情報を格納して，これを経路検索の場合に除外するようにした。「１２禁止乗換テーブル」には，「乗換元接続番号」，「乗換先接続番号」のそれぞれの情報項目を設けて，各フィールドとした。〔甲３，甲３０，１１頁〕原告ＣＤＤＢの「１２禁止乗換テーブル」には，上記のとおり，一方通行などの理由により，経路として接続できない道路の情報を格納しているところ，具体的には，上記「１１接続テーブル」で持つ「接続番号」について，ある接続番号（始点番号，終点番号，道路番号などの情報）の経路から，ある接続番号の経路に乗り換えようとした場合に禁止される接続番号の組み合わせを，この「１２禁止乗換テーブル」に情報として格納するものである。「１２禁止乗換テーブル」の上記「乗換元接続番号」と「乗換先接続番号」のフィールドには，乗換元と乗換先の接続番号で禁止される乗換のパターンを特定して格納している。
これによると，「１１接続テーブル」から各接続番号の始点，終点，道路番号がわかり，乗換を行う場合，乗換元の終点は乗換先の始点となる関
係にあるので，接続された場合のルートは
乗換元の始点→（乗換元の終点＝乗換先の始点）→乗換先の終点という関係になる。〔甲２３，１１～１２頁〕
この「１２禁止乗換テーブル」には，「乗換元接続番号」を「１６」，「乗換先接続番号」を「１６６０６」などとして，数値がそれぞれ格納されている。〔甲２８の別紙９〕
エ移動手段に関する情報の選択について
また，移動手段の種別については，それまでの一般的な分類に従えば，鉄道，バスを含む自動車，飛行機，船等となるところ，原告ＣＤＤＢにおいては，これを「ＪＲ」，「私鉄」，「空路」，「徒歩」とするほか，船については，想定する旅行会社が扱う旅行で利用頻度の高い「フェリー」として，必要な情報を「４３交通機関種別テーブル」に格納した。その際，移動手段を提供する会社についての情報を「４２会社テーブル」として格納することとし，交通会社を検索条件として，路線検索を行うことを可能とした。この点につき，インターネット上での経路検索を可能とするウェブサイトにおいて交通会社を経路検索に用いるものは存せず，他の路線検索システムには見られない原告ＣＤＤＢの特徴となっている。〔甲３０，６，１８頁，
甲５０〕
オ観光施設情報の選択について
観光施設については，まず観光施設に関する様々な情報項目の中から，施設の名称，住所，緯度経度による位置情報，営業日や時間・駐車場の有無等の施設概要，利用料金等の４３項目に分類することとし，フィールドとすることとした。また，これらの情報を格納する「２１観光施設テーブル」とは別に，これを補う目的で，料金種別の増加に対応した施設利用料に関する情報項目や施設に関するコメントなどの情報項目を４４に分類してフィールドとし，これを「２２観光施設備考テーブル」に格納した。また，観光施設の中から，旅行業者が取り扱うと考えられた観光施設を選択し，これを「２１観光施設テーブル」，「２２観光施設備考テーブル」に格納した。〔甲３０，８頁〕
原告ＣＤＤＢの「２１観光施設テーブル」に収録されたレコード数は，別紙４のとおり，７万２０９３件である。
カ宿泊施設情報の選択について


宿泊施設に関しては，宿泊施設に関する情報の中から，宿泊施設の名称，住所，緯度経度の位置情報，室数や収容人数・宴会場の有無・プールの有無等の施設情報などの４３項目を選択して，これをフィールドとし，「２０ホテル・旅館テーブル」に格納した。
また，宿泊施設の中から，旅行業者が取り扱うと考えられた宿泊施設を選択し，これを「２０ホテル・旅館テーブル」に格納した。〔甲３０，８～９
頁〕
原告ＣＤＤＢの「２０ホテル・旅館テーブル」に収録されたレコード数は，別紙４のとおり，１万６２２９件である。
キ小括（原告ＣＤＤＢの概要の整理）
上記のとおり，分類して収集すべき情報項目の選択，及び情報自体の選択・収集を踏まえて，翼システムにおいて構築された原告ＣＤＤＢの内容を整理すると，概ね，以下のとおりとなる。
(ｱ)原告ＣＤＤＢの概要としては，旅行業者がパソコンにインストールされた原告システムを使って行程表作成の業務を行うにあたって必要となる，観光施設データ，宿泊施設データ，全国各地の主要道路の道路地点や，隣接する道路地点間の大型観光バスの移動時間・距離，有料道路・高速道路の料金データ，鉄道・飛行機・フェリーに関する路線，駅，時刻表等の情報を収集し，蓄積したものである。原告ＣＤＤＢでは，別紙２のとおり合計４２個のマスターテーブル内に，別紙２，３のとおり合計４０５個のフィールド項目を配し，各テーブル間を別紙３のとおり設定されたプライマリー・キーにより，別紙５（別紙６，７も同じ）のとおりのリレーションをとって関連付けることで，修学旅行や会社の慰安旅行などの旅行目的や，所要時間，立寄り施設等の要望に合わせた行程表を作成するため，観光施設，宿泊施設，交通手段，経路，出発時間や到着時間，施設等への滞在時間などの具体的なスケジュールをどうすべきかといった事項を，各情報を検索した結果を選択することにより決定し，行程表を作成していくことを可能とした情報の分類体系ということができる。
そして，このような情報の分類を有機的に繋げ合わせて，具体的な行程表を作成するためには，顧客の出発地，帰着地，観光施設などの途中の立寄り地，宿泊施設，交通手段，経路を選択するとともに，出発時刻，到着時刻，滞在時間なども確定する必要があるところ，行程表作成及び検索システムのデータベースでは，これらの情報が，顧客等の具体的要求に基づき，求められたときに対応できるように，テーブル，フィールド及びリレーションを設計した上で，予め情報を選択して格納しておくことが必要となる。
このように，原告ＣＤＤＢは，上記アないしカの方針で実際に集められた膨大な数のレコードを（各テーブルのレコード数については，別紙４のとおり），別紙２，３のとおりのテーブル，フィールドに格納し，別紙５（同６，７も同様）のとおりのリレーションをとることにより，効率的に検索・行程表作成業務を行えるようにデータベースとして設計したものである。
(ｲ)そこで，原告ＣＤＤＢにおける具体的な検索過程と，テーブル，フィールド等の関係等について検討する。
まず，経路検索に関するテーブル及びフィールドの設定，体系的構成，リレーションの設定について，出発地，帰着地，観光施設などの途中立寄り地，宿泊施設，駅，空港，フェリー発着所などに関し，これと関連するテーブルである「０１市区町村テーブル」，「２０ホテル・旅館テーブル」，「２１観光施設テーブル」，「３２駅テーブル」に「代表道路地区コード」や「代表道路地点番号」のフィールドを持つこととしている。そして，道路利用の経路検索の対象として市区町村，観光施設，宿泊施設，駅がある場合には，それぞれの施設自体の緯度経度ではなく，これと関連した道路地点の緯度経度情報のデータを使って，その道路地点までの経路を検索することとなる。各施設等にかかるテーブルの「代表道路地区コード」や「代表道路地点番号」は，「０９地点名テーブル」の「地点番号」とリレーションがとられていることにより，各施設までの経路を検索するときには，この「代表道路地区コード」や「代表道路地点番号」所定の道路地点までの経路を検索することになる。
また，施設を含めた経路検索を行う場合，施設関連の各テーブルに，「代表道路地区コード」や「代表道路地点番号」という道路地点のフィールドを持たせ，これと「０９地点名テーブル」の「地点番号」との間でリレーションを取り，道路地点としての検索を行うという構成を採用している。具体的には，別紙３記載のとおり，原告ＣＤＤＢでは，「０９地点名テーブル」の「地点番号」フィールドをプライマリー・キーに設定し，これと，別紙５で，青丸と青丸を結ぶ太線のうち黒太線で記載されたリレーションのとおり，「０１市区町村テーブル」の「代表道路地区コード」フィールド，「２０ホテル・旅館テーブル」の「代表道路地区コード」フィールド，「２１観光施設テーブル」の「代表道路地点番号」フィールド，「３２駅テーブル」の「代表道路地点番号」フィールドとにリレーションを持たせている。
また，禁止乗換に関するテーブル及びフィールドの設定，体系的構成，リレーションについては，道路利用の経路検索では「０９地点名テーブル」及び「１１接続テーブル」のデータを使って，所要時間の短い経路を検索して提示するものの，「１２禁止乗換テーブル」を設けて，一定の接続経路を除外するように構成している。
上記の「０９地点名テーブル」には，別紙３記載の各フィールドに，道路地点の情報（地点番号，地点名称，都道府県コード，市区町村番号，地点区分，緯度，経度など）を格納している。道路地点の情報は，経路検索をする場合の基本となる位置情報となる。「０９地点名テーブル」の「地点番号」フィールドについては，上記のとおり「０１市区町村テーブル」，「２１観光施設テーブル」，「２０ホテル・旅館テーブル」，「３２駅テーブル」の「代表道路地区コード」や「代表道路地点番号」とリレーションを取り，また「１１接続テーブル」，「１２禁止乗換テーブル」ともリレーションを取って，旅行行程における具体的な経路検索，所要時間，距離，有料道路通行時の料金情報等の検索をするための基本的な情報となっている。


(ｳ)原告ＣＤＤＢでは，鉄道，飛行機，フェリー等の経路検索を行う場合には，まず，ある地区や都道府県において交通機関を運営している会社等を特定し，そののちに路線等を特定する方法をとっている。具体的には，まず交通機関を運営している会社等を特定するために乗車する地区，都道府県を絞り込み（「０２地区・県名テーブル」による），次に当該区域の交通機関の会社を選択する（「４２会社テーブル」，「４４地方別会社索引テーブル」，「４５検索地方範囲定義テーブル」，「４６地方別路線索引テーブル」による）。すると，当該交通会社が運行している路線一覧が表示され，利用する路線を選択すると路線の駅等が一覧表で示される（「３４路線テーブル」，「４２会社テーブル」，「４６地方別路線索引テーブル」による。）。そこで，出発時刻，乗車駅と降車駅等を選択して検索すると，利用可能な便（「３２駅テーブル」，「３４路線テーブル」，「３６路線検索テーブル」，「３９便テーブル」，「４０運行日定義テーブル」，「４７駅通過路線索引テーブル」による。）が表示されるので，利用する便を確定することになる。
ク原告ＣＤＤＢの各テーブルの相互関係
原告ＣＤＤＢは，上記のとおり，４２個のマスターテーブル，４０５個のフィールド項目からなり，原告ＣＤＤＢの各テーブルの意義については，別紙１記載のとおりであるところ，原告ＣＤＤＢの各テーブル相互の関係については，以下のとおり分類される。
「０１市区町村テーブル」，「３２駅テーブル」，「２０ホテル・旅館テーブル」，「２１観光施設テーブル」，「０９地点名テーブル」，「１１接続テーブル」，「１０道路テーブル」により，出発地点，経由地，目的地に面した道路に関するデータの検索が可能になる。
次に「０９地点名テーブル」，「１０道路テーブル」，「１１接続テーブル」，「１２禁止乗換テーブル」，「１４区間料金テーブル」，「１５首都高速料金テーブル」により，道路を利用した移動に関する経路探索・料金の算出に必要なデータの検索を可能にしている。
そして，「２０ホテル・旅館テーブル」，「２１観光施設テーブル」，「２２観光施設備考テーブル」，「０５緯度経度テーブル」，「０６ＵＲＬアドレステーブル」，「０７ＵＲＬ種別テーブル」，「０８ＵＲＬ分類テーブル」により，ホテル・旅館，観光施設に関する情報を検索することを可能にしている。
「０１市区町村テーブル」，「０２地区・県名テーブル」は，道路と地図を関連付ける情報であって，地図から検索をするときに用いられている。「３２駅テーブル」，「３３路線構成テーブル」，「３４路線テーブル」，「３６路線検索テーブル」，「３９便テーブル」，「４０運行日定義テーブル「４２会社テーブル」，「４３交通機関種別テーブル」により，公共交通機関を利用した経路探索に必要なデータの検索を可能にしている。
ケ原告ＣＤＤＢにおける検索，行程作成の実際
以上を踏まえて，具体的な検索，行程作成の実際について検討する。まず，出発地を「０１市区町村テーブル」を使って市区町村内の道路地点から選択する。その際，選択された市区町村内の道路地点として，「０９地点名テーブル」の道路地点のうち，当該市区町村内にある道路地点を見ることができる。そして，市区町村の絞り込みは「０２地区・県名テーブル」，方面については「０３方面テーブル」，「０４方面設定テーブル」，都道府県については，「０２地区・県名テーブル」から絞りこむことができる。また，「０１市区町村テーブル」，「２０ホテル・旅館テーブル」，「２１観光施設テーブル」，「３２駅テーブル」には施設等の近辺の道路地点の情報が代表道路地区コードや代表道路地点番号として格納されており，当該市区町村内にあるこれらの施設や駅などを選ぶことを通じて，出発点としての「０９地点名テーブル」の道路地点を選ぶことができる。次に，観光施設を「２１観光施設テーブル」から選択する。観光施設の絞り込みは，上記と同じく，「０２地区・県名テーブル」，「０３方面テーブル」，「０４方面設定テーブル」，「０１市区町村テーブル」から行うことができる。観光種別は「２３観光施設種別テーブル」（ただし，前記のとおり，ＣＤで提供されるものではないことから，原告ＣＤＤＢ自体には含まれていない。）に，名称は「２１観光施設テーブル」に，検索結果の観光施設について，当該観光施設に関する様々な情報は，「２２観光施設備考テーブル」に格納されており，観光施設に関するホームページの情報も「０６ＵＲＬアドレステーブル」，「０７ＵＲＬ種別テーブル」から参照可能であり，最終的に行程に入れるかどうかを判断することができる。宿泊施設については，「２０ホテル・旅館テーブル」から選択し，地区は「０２地区・県名テーブル」，方面は「０３方面テーブル」，「０４方面設定テーブル」，都道府県は「０２地区・県名テーブル」，市区町村は「０１市区町村テーブル」，地図上の範囲設定は別途の地図ソフトであるプロアトラスと「０５緯度経度テーブル」，「２０ホテル・旅館テーブル」，宿泊種別は「２０ホテル・旅館テーブル」，名称は「２０ホテル・旅館テーブル」，検索結果の宿泊施設については当該宿泊施設に関する様々な情報，すなわち和室，洋室の客室数，収容人員，料金，付帯施設，駐車場などが「２０ホテル・旅館テーブル」に格納されていて，当該宿泊施設に関するホームページの情報も「０６ＵＲＬアドレステーブル」，「０７ＵＲＬ種別テーブル」が対応し，これらを参照してシステムのユーザーである旅行会社ないしその顧客の判断で決定することができる。
コ原告ＣＤＤＢのルート検索における交通機関別での必要なテーブル原告ＣＤＤＢにおいては，複数の道路地点を用いてルートを検索するところ，このときの利用交通機関別の必要なテーブルについては，以下のとおり整理することができる。
(ｱ)道路利用（大型バス）
「０９地点名テーブル」，「１１接続テーブル」，「１２禁止乗換テー
ブル」
原告ＣＤＤＢでは，各市区町村，各観光施設，各宿泊施設，各駅の近辺にある道路地点の地点番号を「代表道路地区コード」や「代表道路地点番号」として，各テーブルのフィールドとして持たせ，道路利用の経路検索の対象として市区町村，観光施設，宿泊施設，駅がある場合には，各テーブルの「代表道路地区コード」や「代表道路地点番号」のフィールドに格納されている道路地点までの経路を検索するようにしている。
(ｲ）鉄道利用
「０２地区・県名テーブル」，「３２駅テーブル」，「３３路線構成テーブル」，「３４路線テーブル」，「３６路線検索テーブル」，「３９便テーブル」，「４０運行日定義テーブル」，「４２会社テーブル」，「４４地方別会社索引テーブル」，「４６地方別路線索引テーブル」，「４７
駅通過路線索引テーブル」
(ｳ)飛行機利用


「０２地区・県名テーブル」，「３２駅テーブル」，「３３路線構成テーブル」，「３４路線テーブル」，「３６路線検索テーブル」，「３９便テーブル」，「４０運行日定義テーブル」，「４２会社テーブル」，「４４地方別会社索引テーブル」，「４６地方別路線索引テーブル」，「４７
駅通過路線索引テーブル」
(ｴ)フェリー利用
「０２地区・県名テーブル」，「３２駅テーブル」，「３３路線構成テーブル」，「３４路線テーブル」，「３６路線検索テーブル」，「３９便テーブル」，「４０運行日定義テーブル」，「４２会社テーブル」，「４４地方別会社索引テーブル」，「４６地方別路線索引テーブル」，「４７
駅通過路線索引テーブル」
(3)翼システムないし旧原告会社の状況及びそこにおける被告Ｙ１を除く個人被
告らの活動等
ア翼システムにおいては，平成１１年１月に，当時の翼システム会長が脱税容疑で逮捕され，平成１３年３月に実刑判決を受けるに至った。〔甲７９〕これらを受け，平成１５年１０月ころからは，翼システムにおいても人員削減等の話が出て，経営の存続が危ぶまれる声も聞かれるようになった。イ平成１７年当時の翼システムにおける，被告Ｙ２，被告Ｙ３，被告Ｙ４，被告Ｙ６の担当営業地域は以下のとおりである。
被告Ｙ２の担当は，概ね，北海道，青森，岩手，宮城，秋田，山形，福島，茨城，栃木，富山，石川の１１道県である。
同じく被告Ｙ３の担当は，概ね，千葉，三重，東京の３都県である。同じく被告Ｙ４の担当は，概ね，群馬，埼玉，神奈川，新潟，山梨，長野，静岡の７県である。
同じく被告Ｙ６の担当は，広島，山口，徳島，香川，愛媛，高知，福岡，佐賀，長崎，熊本，大分，宮崎，鹿児島，沖縄の１４県である。これら被告Ｙ２，被告Ｙ３，被告Ｙ４，被告Ｙ６の４名の担当都県等は，合計で３５都道県となり，被告Ｙ２，被告Ｙ３，被告Ｙ４及び被告Ｙ６の４名で，翼システムの顧客の８割以上を担当していた。〔被告Ｙ２尋問調書２頁〕    その他の翼システムにおける営業の担当は，Ｂが岐阜，三重，福井，滋賀，京都の５府県及び大手ユーザー，訴外Ｃが大阪，兵庫，奈良，和歌山，鳥取，島根，岡山の７府県であった。〔甲７８〕
ウ被告Ｙ６は，原告システムのサポート担当者として，原告ＣＤＤＢを含むデータベースＣＤと，ユーザーのＰＣなどに原告システムのプログラムをインストールするため，プログラム部分やエントリーテーブル部分から成り，システム導入時にユーザー側に設置されるＰＣ内に必要なプログラムやエントリーテーブル等をインストールすることを可能とするインストールＣＤ，及び，これらがインストールされたノートパソコンを常に持ち歩いており，これらにはコピープロテクションがかかっておらず，そこに格納されているプログラム，データベース，データその他の情報にアクセスすることができた。〔甲６３，７１〕
エまた，被告Ｙ３，被告Ｙ２，被告Ｙ４の３名，及び，営業も担当することとなった後の被告Ｙ６は，翼システムの営業担当者として，営業活動中，原告ＣＤＤＢを含むデータベースＣＤと，原告システムをインストールするためのインストールＣＤ，及び，原告システムのデモ環境がインストールされている，営業担当者が，システム導入の見込み客に対し，原告システムのデモンストレーションをする際に使用するノートパソコンを常に持ち歩いており，これらにはコピープロテクションがかかっておらず，そこに格納されているプログラム，データベース，データその他の情報にアクセスすることができた。また，被告Ｙ５は，被告Ｙ３，被告Ｙ２，被告Ｙ４らの営業担当者は原告等の管理区域内に設置されており本来はアクセスできない開発系サーバー内に格納されている，プログラムやデータベース，これらに関する設計資料等を，それぞれ電子媒体，紙媒体その他の媒体等に複製し得る環境にあった。〔甲６３，７１〕
オ上記デモンストレーション用の原告システムのプログラム及びデータベースは，最新の販売用の製品を顧客ないし導入見込み客にデモンストレーションを行うため，常に最新のものとされており，データベースのＣＤも，最新版が発行されるたびに，営業担当者全員に配布され，データの定期的な更新をすることが可能とされていた。〔甲７１〕
(4)個人被告らによる被告アゼスタの設立等
ア被告Ｙ３，被告Ｙ２，被告Ｙ４，被告Ｙ５らは，平成１７年６月ころまでには，旧原告会社を退社して旅行業システムを営む新会社を設立することの相談を始めた。〔被告Ｙ２尋問調書２１頁〕
イ一方，被告Ｙ１は，翼システム及び旧原告会社に在籍したことはなく，株式会社グッドウィルの取締役，株式会社エス・エス・アイ・トリスター，株式会社トリスターの代表取締役等，ＩＴ・ソフトウェア関係の事業の経営に携わってきた経験があり，被告Ｙ３，被告Ｙ２の高校の同級生で，知人でもあったことなどから，平成１７年１０月１８日の被告アゼスタの設立に当たり過半を出資して，設立と同時に被告アゼスタの代表者に就任した。〔証人Ａ尋問調書８
頁〕
ウＡは，被告アゼスタ設立に先立つ平成１６年７月に，既に翼システムを退社し，訴外株式会社ストラテジィに入社していたが，平成１７年７月頃，被告Ｙ３及び被告Ｙ５から，旅行業システムの販売をする設立準備中の被告アゼスタに加入することの勧誘を受け，同年１１月に，被告アゼスタに入社した。Ａが入社した当時の被告アゼスタには，常勤の役員，社員は，被告Ｙ１のほかは，Ａしかいなかった。〔証人Ａ尋問調書３，９頁，乙３８，１頁〕エ被告Ｙ３は，平成１７年９月ないし１０月ころ，翼システムの社員であり，原告システムの営業及びサポート業務に携わっていた訴外Ｄに対し，翼システムを退社して被告Ｙ３らと事業を行うことを勧誘したが，断られた。〔甲７１〕オ被告Ｙ５は，前記のとおり，平成１７年７月ころには，既に翼システムを退職していたＡを被告アゼスタの設立に向けて勧誘をしていたが，被告Ｙ５自身はそのまま旧原告会社に在籍を続けた。被告Ｙ５は，旧原告会社において，原告システムのプログラム，データベース，開発資料，メンテナンス資料等について自由にアクセスできる立場にいた。被告Ｙ５は，遅くとも平成１８年１月ころまでには，旧原告会社の社員でありながら，被告システムの当初版の開発にも携わり，入力の指示等を行っており，平成１８年６月に旧原告会社を退社し，被告アゼスタに入社した。〔証人Ａ尋問調書１１頁，被告Ｙ５尋問調書１
４，１５，２４～２５頁〕


ただし，Ａ及び被告Ｙ５は，被告ＣＤＤＢの当初版の開発当時，被告システムに用いられているＳＱＬサーバーに関し，それほどのキャリアを積んではいない状態にあった。〔証人Ａ尋問調書１６頁〕
カ被告アゼスタは，平成１８年６月，当初版の被告システムの販売を開始した。被告Ｙ２らは，旧原告会社の顧客に対し，被告アゼスタ設立の挨拶とシステム資料を一斉送付し，営業を行った。〔被告Ｙ２尋問調書８頁〕しかし，被告システムに関し，同月末に納入したアルピコ観光サービス株式会社から，被告システムの性能に関し，重大なクレームが寄せられるということがあった。〔証人Ａ尋問調書１９，２０頁〕
キ被告Ｙ６は，平成１８年１０月まで旧原告会社において，原告システムの営業を担当していたが，同月，旧原告会社を退社した。〔乙４２〕また，被告Ｙ５は，平成２０年６月，被告アゼスタを退社した。ク被告Ｙ１は，平成２０年７月に，「株式会社アゼスタ    営業部Ｙ１」の名義で，翼システムの顧客である旅行会社に向け，下記の内容の文書を送付した。なお，上記のとおり，被告Ｙ１は翼システムに在籍したことはない。〔甲
５２〕
記「翼システム株式会社在籍中はひとかたならぬ御愛顧を賜り，厚く御礼申し上げます。さて，昨年７月に弊社旅行業務システム『旅nesPro』を初めてご紹介させて頂き丁度一年が経過致しましたが，この間も順調に全国の旅行会社様に弊社システムをご導入頂きまして，６月末現在のユーザー数は２２２社，その内旧翼システム『スーパーフロントマン旅行業システム』から弊社システムへのお切り替えユーザー様が１８２社となっております。・・・現行システムリース満了に伴う契約更新やシステム増設をご検討の際には，何卒，比較検討頂けます様お願い申し上げます。尚，弊社システムにお切り換え頂く場合には，現行システムからのデータ移行，現行システムのリース残債下取り（社内規定の範囲内）等のご要望もお受け賜り致しますので，ご商談の際に遠慮なくお申し付け下さい。」ケ被告アゼスタは，平成２０年８月１８日，別紙被告物件目録記載１１の被告ＣＤＤＢ（現行版）を含む被告システムのVer2.80を発売した。また，被告アゼスタは，同年１１月発売の別紙被告物件目録記載１２の被告ＣＤＤＢ（現行版）を含む被告システムVer2.82からは，施設マスタに「キーワード」のフィールドを設け，「世界遺産」，「祭り」，「観光・食事１００選」などのテーマに沿って検索することを可能にした。
コ被告Ｙ６は，平成２０年１２月１日付け書類送付状を原告の顧客に送付したが，そこには，下記の記載がある。〔甲２５の１。アンダーライン・太字は原文どおり。なお，「※」以下は，手書き記載。〕
記「突然の資料送付にて大変失礼いたします。翼システム(株)営業として数回ご訪問させていただきましたＹ６と申します。その節は，長い間皆様にいろいろとお世話になり，誠にありがとうございました。新たに他社にて旅行業システム専門の会社を立ち上げさせていただきました。・・・全国にて３００店舗以上の旅行社様が当社へ切り替えをしていただきました。※現在ご利用の翼システムも残リースが１年くらいだと思います。一度ご提案させていただけたらと思います。」サ原告は，平成２１年５月１５日付けで本件訴訟を提起し，その訴状は，同月２７日までに被告らに対し送達された。
被告らは，同年６月，原告に対し，ロイヤルティの支払や原告事業の買取り等を条件とする和解の申入れを行ったが，原告に拒絶された。〔当事者間
に争いがない〕
シ被告らは，平成２１年６月，別紙被告物件目録記載１６の被告ＣＤＤＢ（現行版）を含む被告システム（Ver2.94）を販売した。同システムの被告ＣＤＤＢ（現行版，Ver2.94）においては，同年４月に発売された別紙被告物件目録記載１５の被告システム（Ver2.92）の被告ＣＤＤＢに比べ，原告ＣＤＤＢにおける緯度経度情報の完全一致率（緯度及び経度を０．１秒単位で表すために原告が設定した６桁ないし７桁の数字で表される緯度経度の数値がすべて一致する率）が，約９２％から８．１％に激減した。〔甲３２，
３４，３９〕
この点につき，Ａは，原告から本件訴訟の提起を受けて，原告から指摘を受けるまで，これらが同じであることを知らなかったが，原告の指摘を受けたことから，交差点が中心になるようにマウスでクリックをして位置決めをして，数値の入れ直しをした結果であるとする。〔証人Ａ尋問調書２０頁〕ス平成２１年１０月，被告アゼスタは，新たに，バス運行管理システムの「バス快道」を開発し，その販売を開始し，同年１２月には，「バス快道」をバージョンアップした。〔甲２５の２〕
セ被告Ｙ１は，平成２２年（２０１０年）１１月２９日付けで，被告アゼスタ「営業グループＹ１」の名義で手書きの新製品案内状を送付したが，そこには，下記の記載がある。〔甲５３〕
記「拝啓貴社益々ご清栄のこととお慶び申し上げます。私どもアゼスタは旧翼システムにて旅行業システムの開発・営業に携わっていたメンバーで２００５年１０月に独立した会社です。弊社の旅行業システム『旅ネスプロ』は販売開始から４年間で約５００社様，その内旧翼システム時代のお客様約３００社様が『旅ネスプロ』へ切換導入して頂いております。・・・尚，弊社システムへお切換え頂くことは，現在システムをご使用している途中でも可能でございます。現行システムのリース残債の下取り現行システムからのデータ移行ができます。」
なお，このころ被告アゼスタから発売された製品は，被告ＣＤＤＢ（現行版）であり，平成２２年８月３日にVer2.99の２０１０年８・９月版が，同年１０月４日にVer2.99の２０１０年１０・１１月版が，同年１２月６日にVer2.99の２０１０年１２月・２０１１年１月版が，それぞれ発売されている。〔甲３８〕
なお，このころ，後記のとおり，被告ＣＤＤＢに存する原告ＣＤＤＢと共通する誤りがある情報について，その誤りを訂正する変更がされているものがある。
ソ被告らは，平成２３年２月にも，原告に対し，再度の和解の申入れ及び個人被告らに対する訴えの取下げを求めたが，原告に拒絶された。〔当事者間
に争いがない〕


タ被告アゼスタは，平成２３年２月７日発行で，被告ＣＤＤＢ（現行版）のVer3.1を発売した。〔甲３８〕
そして，被告アゼスタは，同年４月４日に，被告ＣＤＤＢ（新版）を含む被告システム（別紙被告物件目録記載２２）の販売を開始した。
(5)一般的なデータコピーのプロセスについて
データベース間でデータのコピーを行うには，ＣＳＶ（CommaSeparatedValues）ファイルを使う方法と直接コピーする方法がある。〔甲６７，７０〕このうち，データベースのデータをＣＳＶファイルに出力する場合には，１個のテーブルにつき一つのＣＳＶファイルが作成され，テーブル内の１個のレコードが通常１行のデータとして出力される。その際，改行があると，次のレコードとして認識される。１レコード内のフィールドの区切りには「，（カンマ）」を挿入して出力するので，フィールド間は「，（カンマ）」で区切られ，「，（カンマ）」があると，次のデータとなる。
そこで，ＣＳＶファイルを使用する場合は，フィールド内のデータに改行や，「，（カンマ）」等が含まれ，かつこれらがフィールドやレコードの区切りを示すものでない場合は，データの前後を「"(ダブルクォート）」で囲う処理などを行い，フィールドやレコードの区切りとして扱われないようにする処理が必要となり，単純にコピーした場合には，ＣＳＶファイルへの抽出では，「,(カンマ)」，「"(ダブルクォート）」等が含まれているデータでは不都合が生じることがある。〔甲７０，６～８頁〕
なお，タブ区切り（ＴＳＶ：データをタブ文字で区切って並べたファイル形式）にすれば不都合が生じない場合があり，カンマ区切り（ＣＳＶ）では，カンマ，ダブルクォート等は文字化けや項目ずれを起こすため，被告アゼスタでも，カンマ，ダブルクォート等が含まれているデータについてはタブ区切り（ＴＳＶ）を使って上記支障が生じないように対処することは可能である。(6)顧客（システムのユーザー）が蓄積したデータの移行についてまた，顧客（システムのユーザー）が使用しているシステムについて，別のシステムに移行する際には，顧客の元で作成・保存された既存のデータを，新システムでも使用できるようにするために，データを移行（コンバート）する必要がある。データ移行のためには，移行元のテーブルレイアウトが必要であるところ，原告システムで作成されたエントリーテーブルに保存されるユーザーデータは，原告ＣＤＤＢの各マスターテーブルの情報と紐付けられており，原告ＣＤＤＢのテーブル，フィールド，リレーション，フィールドにおける種別の設定，コードの割振りなどの内容や，テーブルレイアウトを知らないと，原告システムのユーザーデータを被告システムに移行することはできない。
〔甲６１〕
原告が顧客に提供した原告ＣＤＤＢには，テーブル名，フィールド名，コードの意味，リレーション，予備の項目（別紙３の括弧内に「予備」と記載された，フラグ，区分，日付，数値等のフィールド）に格納されているデータの内容などの情報は格納されておらず，原告ＣＤＤＢを解析しても，原告ＣＤＤＢから被告ＣＤＤＢへとユーザーデータの移行を行うために必要な，原告ＣＤＤＢについてのテーブル名，フィールド名，コードの意味，リレーションなどの情報を取得することはできない。〔甲６７〕
なお，移行元のテーブルＩＤ，フィールドＩＤと，移行先のテーブルＩＤ，フィールドＩＤとを対応させることができれば，両者の間でのデータ移行は容易に行うことができる。〔甲７０〕
(7)被告ＣＤＤＢに格納されたデータ等について
被告ＣＤＤＢに格納されたデータには，上記「,(カンマ)」や「"(ダブルクォート）」が含まれていることにより，データ移行がされた場合に不都合が生じたものと認められるものはない。
なお，被告らは，原告ＣＤＤＢをコピーし流用したことは認めるが客観的なデータに誤記修正をした上であり，しかもカンマ区切り（ＣＳＶ）ではカンマやダブルクォートが含まれていると文字化けや項目ずれを起こすため，これらが含まれている場合にはタブ区切り（ＴＳＶ）を使ってデータ入力・加工を行っているものであると主張するところ，確かに，原告ＣＤＤＢの「０９地点名テーブル」の地点番号「１２４１４」には，地点名称「北九州市（Ｒ３，県道２７０号）小倉北区上到津２」との地点が登録されており，この地点名称カナフィールドには，「ｷﾀｷｭｳｼｭｳｼｵｸ"ﾗｷﾀｸﾐﾔｺｶﾐﾄｳﾂ２」と，「ｵｸ"ﾗ」には，濁点ではなく「"(ダブルクォート）」が含まれており，被告ＣＤＤＢ（当初版・２００６年版）には，「ｷﾀｷｭｳｼｭｳｼｵｸ"ﾗｷﾀｸﾐﾔｺｶﾐﾄｳﾂ２」と原告ＣＤＤＢと同じデータがそのまま格納されている。しかし，上記「北九州市小倉北区上到津２」の正しい読み仮名は，「ｷﾀｷｭｳｼｭｳｼｺｸﾗｷﾀｸｶﾐｲﾄｳﾂﾞ２」であり，原告ＣＤＤＢの表記は正しい読み方とも大きく異なるが，被告ＣＤＤＢ（当初版・２００６年版）には，全く同じ表記でデータが格納されていることが認められる。〔甲７０〕(8)原告における原告システム以外の製品の販売について原告は，原告システムのほか，平成２１年ころからは，多拠点向けの旅行業システムとして，「トラベルート・エヌエス」（以下「ＴＲ－ＮＳ」という。）を販売している。近年における原告システムとＴＲ－ＮＳの販売割合は，ほぼ同等である。〔証人Ｂ，１２頁，弁論の全趣旨〕


２争点(1)（原告ＣＤＤＢの著作物性及び被告ＣＤＤＢが原告ＣＤＤＢに依拠して作成された複製物ないし翻案物といえるか）について(1)著作権法２条１項１０号の３は，データベースにつき，「論文，数値，図形その他の情報の集合物であって，それらの情報を電子計算機を用いて検索することができるように体系的に構成したものをいう」とし，同法１２条の２第１項は，「データベースでその情報の選択又は体系的な構成によって創作性を有するものは，著作物として保護する」と規定している。このように，データベースとは，情報の集合物を電子計算機を用いて検索することができるように体系的に構成したものをいうところ，前記第２，１の前提事実及び前記１で認定した事実によれば，原告ＣＤＤＢは，データベースの情報の単位であるレコードを別のレコードと関連付ける処理機能を持ついわゆるリレーショナル・データベースである。リレーショナル・データベースにおいては，入力される情報はテーブルと呼ばれる表に格納され，各テーブルはフィールド項目に細分され，あるテーブルのあるフィールド項目を他のテーブルのあるフィールド項目と一致させてテーブル間を関連付けることにより，既存の複数のテーブルから抽出したいフィールド項目だけを効率的に選択することができるデータベースであるから，情報の選択又は体系的な構成によってデータベースの著作物と評価することができるための重要な要素は，情報が格納される表であるテーブルの内容（種類及び数），各テーブルに存在するフィールド項目の内容（種類及び数），各テーブル間の関連付けのあり方の点にあるものと解される。
上記のような観点も踏まえ，原告ＣＤＤＢのようなリレーショナル・データベースについて情報の選択に創作性があるというためには，データベースの主題，用途やデータベースの提供対象等を考慮して決定された一定の収集方針に基づき収集された情報の中から，更に一定の選定基準に基づき情報を選定することが必要であり，また体系的構成に創作性があるというためには，収集，選定した情報を整理統合するために，情報の項目，構造，形式等を決定して様式を作成し，分類の体系を決定するなどのデータベースの体系の設定が行われることが必要であると解される。
ただし，データベースにおける創作性は，情報の選択又は体系的構成に，何らかの形で人間の創作活動の成果が表れ，制作者の個性が表れていることをもって足りるものと解される。
(2)次に，著作物の複製ないし翻案については，複製とは，印刷，写真，複写，録音，録画その他の方法により有形的に再製することをいうとされているところ（著作権法２条１項１５号），著作物の複製は，既存の著作物に依拠し，これと同一のものを作成し，又は，具体的な表現に修正，増減，変更等を加えても，新たに思想又は感情を創作的に表現することなく，その表現上の本質的な特徴の同一性を維持し，これに接する者が既存の著作物の表現上の本質的な特徴を直接感得することのできるものを作成する行為をいうと解される。また，著作物の翻案（著作権法２７条）とは，既存の著作物に依拠し，かつ，その表現上の本質的な特徴の同一性を維持しつつ，具体的表現に修正，増減，変更等を加えて，新たに思想又は感情を創作的に表現することにより，これに接する者が既存の著作物の表現上の本質的な特徴を直接感得することのできる別の著作物を創作する行為をいう（最高裁平成１３年６月２８日第一小法廷判決・民集５５巻４号８３７頁参照）。
そして，著作権法は，思想又は感情の創作的な表現を保護するものであるから（著作権法２条１項１号），既存の著作物に依拠して作成又は創作された著作物が，思想，感情若しくはアイデア，事実若しくは事件など表現それ自体でない部分又は表現上の創作性がない部分において，既存の著作物と同一性を有するにすぎない場合には，複製にも翻案にも当たらないというべきである。データベースについては，情報の選択又は体系的な構成によって創作性を有するものは，著作物として保護されるものであるところ（著作権法１２条の２），上記のとおり，データベースにおける創作性は，情報の選択又は体系的構成に，何らかの形で人間の創作活動の成果が表れ，制作者の個性が表れていることをもって足りるものあるが，データベースの著作物として保護されるのはあくまでも，具体的なデータベースに表現として表れた情報の選択や体系的構成であって，具体的な表現としての情報の選択や体系的構成と離れた情報の選択の方針や体系的構成の方針それ自体は保護の対象とはならないというべきである。(3)以上を前提に，まず被告ＣＤＤＢ（当初版・２００６年版）につき検討する。ア被告ＣＤＤＢ（当初版・２００６年版）と原告ＣＤＤＢとの体系的構成の
共通性
(ｱ)テーブルの種類及び数
ａ一致するマスターテーブル
原告ＣＤＤＢには４２個の，被告ＣＤＤＢ（当初版・２００６年版）には３１個のマスターテーブルがそれぞれ含まれるところ，このうち，以下の２４個のマスターテーブルについては，原告ＣＤＤＢに含まれるマスターテーブルと一致することにつき争いがない。
一致することに争いのない２４個のマスターテーブルは，以下のとおりである（原告ＣＤＤＢのマスターテーブル。これと対応する被告ＣＤＤＢ（当初版・２００６年版）の表記は別紙２該当欄各記載のとおり）。
・「０１市区町村テーブル」
・「０２地区・県名テーブル」
・「０５緯度経度テーブル」
・「０６ＵＲＬアドレステーブル」
・「０７ＵＲＬ種別テーブル」
・「０８ＵＲＬ分類テーブル」
・「０９地点名テーブル」
・「１０道路テーブル」
・「１１接続テーブル」
・「１２禁止乗換テーブル」
・「１３有料道路番号テーブル」
・「１４区間料金テーブル」
・「１５首都高速料金テーブル」
・「１６道路構成地点テーブル」
・「１７道路構成地点索引テーブル」
・「１８市区町村通過道路索引テーブル」
・「１９県範囲定義テーブル」
・「２８協定施設テーブル」
・「２９券種テーブル」
・「３０協定旅館テーブル」
・「３１連結協定テーブル」
・「３２駅テーブル」
・「４２会社テーブル」
・「４４地方別会社索引テーブル」
そして，原告は，「２０ホテル・旅館テーブル」，「２１観光施設テーブル」及び「２２観光施設備考テーブル」についても，これら三つのテーブルに対応する，被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」，「２９旅館マスタ基本」，「２３観光マスタ基本」，「２６観光料金マスタ」及び「２５観光料金種別マスタ」は，一致するマスターテーブルである旨主張する。


このうち，被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」，「２９旅館マスタ基本」，「２３観光マスタ基本」と原告ＣＤＤＢの「２０ホテル・旅館テーブル」，「２１観光施設テーブル」とは，別紙３記載のとおり，フィールドのテーブルへのまとめ方は異なるものの，被告ＣＤＤＢ（当初版・２００６年版）の下記テーブルについての合計１９個のフィールドを除いては，いずれも原告ＣＤＤＢのフィールドと共通し，被告ＣＤＤＢ（当初版・２００６年版）に固有のフィールドといえるものは存在しない。
・「２９旅館マスタ基本」テーブルにつき，以下のフィールド（フィールド名の右の記載はフィールドＩＤ）
シングル数（客室数＿シングル），ＨＬＲＭＳＧＬ
ツイン数（客室数＿ツイン），ＨＬＲＭＴＷＮ
その他数（客室数＿その他），ＨＬＲＭＥＴＣ
ＴＥＬ２（ＴＥＬ２），ＨＬＴＥＬ２
ＴＥＬ２コメント（ＴＥＬ２備考），ＨＬＴＥＬ２ＣＭＮＴ
数値１（予備），ＨＬＮＦＩＬＬＥＲ５
数値２（予備），ＨＬＮＦＩＬＬＥＲ６
登録日時（作成日時），ＨＬＴＯＲＯＫＵＹＭＤ
更新日時（更新日時），ＨＬＫＯＳＨＩＮＹＭＤ
・「２１施設マスタ」テーブルにつき，以下のフィールド（フィールド名の右の記載はフィールドＩＤ）
温泉地コード（温泉地番号），ＳＴＳＰＡＣＤ
登録日時（作成日時），ＳＴＯＲＯＫＵＹＭＤ
更新日時（更新日時），ＳＴＫＯＳＨＩＮＹＭＤ
削除フラグ，ＳＴＤＥＬＥＴＥＣＬＳ
数値１（予備），ＳＴＦＩＬＬＥＲ５
数値２（予備），ＳＴＦＩＬＬＥＲ６
観光フラグ，ＳＴＳＴＦＬＧ
宿泊フラグ，ＳＴＨＬＦＬＧ
・「２３観光施設マスタ」テーブルにつき，以下のフィールド（フィールド名の右の記載はフィールドＩＤ）
登録日時（作成日時），ＳＧＴＴＯＲＯＫＵＹＭＤ
更新日時（更新日時），ＳＧＴＫＯＳＨＩＮＹＭＤ
そして，上記１９個のフィールドは，いずれも，それ以外の，例えばプライマリー・キーの設定された「施設コード」フィールドや，施設名称や種別，室数等，原告ＣＤＤＢと一致するフィールドと比して，重要なものとはいえない。
また，別紙８記載のとおりと認められる被告ＣＤＤＢ（当初版・２００６年版）のフィールド間のリレーションをみると（争いのあるリレーションについての判断は後記する。），施設コード同士，代表道路地点や市区町村コード等の間でリレーションをとるテーブルの参照の仕方もほぼ同じものであり，両者は同じ目的で使用されるものと認められる。そうすると，これら被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」，「２９旅館マスタ基本」，「２３観光マスタ基本」については，原告ＣＤＤＢの「２０ホテル・旅館テーブル」，「２１観光施設テーブル」と実質的に一致するテーブルであると認められる。また，被告ＣＤＤＢ（当初版・２００６年版）の「２６観光料金マスタ」と，原告ＣＤＤＢの「２２観光施設備考テーブル」とを比較すると，フィールド内容において，別紙３記載のとおり，原告ＣＤＤＢの方が若干詳細にフィールド区分がされているものの，テーブルの参照の仕方はほぼ同じものであり，両者は同じ目的で使用されるものと認められる。そうすると，被告ＣＤＤＢ（当初版・２００６年版）の「２６観光料金マスタ」についても，一致するフィールドであると認められる。
一方，被告ＣＤＤＢ（当初版・２００６年版）の「２５観光料金種別マスタ」は，原告ＣＤＤＢの「２１観光施設テーブル」，「２２観光施設備考テーブル」に，料金区分自体のフィールドは存するものの，被告ＣＤＤＢ（当初版・２００６年版）の「２５観光料金種別マスタ」の「料金種別コード」や「料金種別名称」自体の区分やフィールドが原告のＣＤＤＢには存在せず，そのテーブルが一致するものとは認められない。以上によれば，原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とで一致するマスターテーブルは，被告ＣＤＤＢ（当初版・２００６年版）のテーブルで数えると上記２８個，原告ＣＤＤＢの対応するテーブルで数えると２７個であると認められる。
ｂ一致しないマスターテーブル
上記のとおり，被告ＣＤＤＢ（当初版・２００６年版）の「２５観光料金種別マスタ」は，原告ＣＤＤＢに対応するマスターテーブルが存在しない。
その他，原告ＣＤＤＢのマスターテーブルのうち，「０３方面テーブル」，「０４方面設定テーブル」については，被告システムでは，方面検索の機能がないため，対応するテーブルが存在しない。


また，原告ＣＤＤＢのマスターテーブルのうち，「３３路線構成テーブル」，「３４路線テーブル」，「３５時刻表料金テーブル」，「３６路線検索テーブル」，「３７路線検索索引テーブル」，「３８路線タイプテーブル」，「３９便テーブル」，「４０運行日定義テーブル」，「４１時刻テーブル」，「４３交通機関種別テーブル」，「４５検索地方範囲定義テーブル」，「４６地方別路線索引テーブル」，「４７駅通過線索引テーブル」についても，被告ＣＤＤＢ（当初版・２００６年版）に対応するマスターテーブルが存在しない。
このうち，「４５検索地方範囲定義テーブル」については，二地点間の検索範囲を管理するためのテーブルであり，原告システム提供当時から存在するテーブルであるところ，原告システム提供開始当時は，パソコンの性能が低く，検索効率を上げるための工夫として必要とされていたが，その後，パソコンの性能が向上したため，必要性が乏しくなっていたテーブルであることが認められる。〔甲３，別紙２〕
なお，上記のうち，被告ＣＤＤＢ（当初版・２００６年版）に存するが，原告ＣＤＤＢに存しない２個のテーブル（「２８観光詳細種別マスタ〔テーブルＩＤ；ＡＺＭＳＴＫＭＫ〕」と「２７観光種別マスタ〔テーブルＩＤ；ＡＺＭＳＴＳＭ〕」は，原告ＣＤＤＢには含まれないものの，原告システムをユーザーのハードウェア内にインストールした際に作成される原告マスターテーブルの中に，これら被告ＣＤＤＢ（当初版・２００６年版）の二つのテーブルに対応するマスターテーブル（「２３観光施設種別テーブル」及び「２４観光施設検索タイトルテーブル」）が存在する。すなわち，上記原告システムの「２３観光施設種別テーブル」に含まれるフィールドは「種別番号〔フィールドＩＤ；ＳＫＣＬＳＣＤ〕」フィールド，「種別名称〔フィールドＩＤ；ＳＫＣＬＳＮＭ〕」フィールドの二つのフィールドであるところ，被告ＣＤＤＢ（当初版・２００６年版）の「２８観光詳細種別マスタ」テーブルに含まれるフィールドは「詳細種別コード〔フィールドＩＤ；ＳＫＣＬＳＣＤ〕」フィールド，「観光詳細種別名称〔フィールドＩＤ；ＳＫＣＬＳＮＭ〕」フィールドのほかは，フラグ，区分，日付，数値，登録日時，更新日時等のフィールドであり，上記フラグ等を除いた重要なフィールドについてはフィールドＩＤが完全に一致している。また，原告システムの「２４観光施設検索タイトルテーブル」に含まれるフィールドは「観光施設検索タイトルコード〔フィールドＩＤ；ＳＳＳＥＥＴＬＣＤ〕」フィールド，「表示タイトル名〔フィールドＩＤ；ＳＳＴＴＬＮＭ〕」フィールド，「種別数〔フィールドＩＤ；ＳＳＣＬＳＮＵＭ〕」フィールド，「種別コード１〔フィールドＩＤ；ＳＳＣＬＳ１〕」フィールド，「種別コード２〔フィールドＩＤ；ＳＳＣＬＳ２〕」フィールド，「種別コード３〔フィールドＩＤ；ＳＳＣＬＳ３〕」フィールド，「種別コード４〔フィールドＩＤ；ＳＳＣＬＳ４〕」フィールド，「種別コード５〔フィールドＩＤ；ＳＳＣＬＳ５〕」フィールド，「種別コード６〔フィールドＩＤ；ＳＳＣＬＳ６〕」フィールド，「種別コード７〔フィールドＩＤ；ＳＳＣＬＳ７〕」フィールド，「種別コード８〔フィールドＩＤ；ＳＳＣＬＳ８〕」フィールド，「種別コード９〔フィールドＩＤ；ＳＳＣＬＳ９〕」フィールド，「種別コード１０〔フィールドＩＤ；ＳＳＣＬＳ１０〕」フィールドの１３個のフィールドであるところ，被告ＣＤＤＢ（当初版・２００６年版）の「２７観光種別マスタ」テーブルに含まれるフィールドのうち「観光種別コード〔フィールドＩＤ；ＳＳＳＥＥＴＬＣＤ〕」フィールド，「種別名称〔フィールドＩＤ；ＳＳＴＴＬＮＭ〕」フィールドについては，原告ＣＤＤＢのフィールドＩＤと完全に一致しており，「観光種別コード〔フィールドＩＤ；ＳＳＣＬＳ〕」フィールドについても，原告ＣＤＤＢのフィールドＩＤのうち，「種別コード」フィールドのフィールドＩＤの数字を除く部分（「ＳＳＣＬＳ」）と一致しており，その余はフラグ，区分，日付，数値，登録日時，更新日時等のフィールドとなっている。〔別紙３，甲８別紙Ｂ－３－１の２頁〕このように，原告ＣＤＤＢと一致しない被告ＣＤＤＢ（当初版・２００６年版）の「２７観光種別マスタ」と「２８観光詳細種別マスタ」テーブルは，原告ＣＤＤＢには含まれないものの，内容的にこれと一致するテーブルが原告システムには存在する。
(ｲ)被告ＣＤＤＢ（当初版・２００６年版）の各テーブルに存在するフィール
ドの種類及び数
原告ＣＤＤＢには４２個のテーブルに，４０５個のフィールドが存するところ，被告ＣＤＤＢ（当初版・２００６年版）の各テーブルに存在するフィールドＩＤは別紙３記載のとおりであり，３１個のテーブルに３１８個のフィールドが存する。
フィールドのうち，「作成日時」，「更新日時」及び「削除区分」のフィールドは，データ更新やテーブル管理を行うための管理項目であり，データベースの検索機能やデータの内容自体に影響を及ぼす性質のものではない。
〔甲３，７頁〕


そうすると，被告ＣＤＤＢ（当初版・２００６年版）における，「２９旅館マスタ基本」，「２１施設マスタ」，「２３観光マスタ基本」，「２６観光料金マスタ」，「２５観光料金種別マスタ」，「２７観光種別マスタ」，「２８観光詳細種別マスタ」（別紙３の記載順）に各１個ずつ存在する「登録日時（作成日時）」及び「更新日時（更新日時）」フィールド（合計１４個），「２６観光料金マスタ」に１個存在する「料金デフォルトフラグ（削除区分）」の合計１５個のフィールドを除くと，被告ＣＤＤＢ（当初版・２００６年版）のフィールドのうち，これらを除いたフィールド数は，３０３個となる。
そして，このうち，別紙３記載のとおり，原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とでは，一致するテーブル２８個につき，一致するフィールドは２９９個である。
上記のとおり原告ＣＤＤＢのマスターテーブルと一致する被告ＣＤＤＢ（当初版・２００６年版）のテーブルにおけるフィールド項目については，別紙３記載のとおり，ここから登録日時，更新日時及び削除区分のフィールドを除くと２８６個となり，このうち原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とで一致するフィールドは２５２個である。
(ｳ)テーブル間の関連付け
別紙３のとおり，原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とでは，原告ＣＤＤＢのマスターテーブルと一致する２８個のテーブルに関して，プライマリー・キーの設定につき，原告ＣＤＤＢの「０２地区・県名テーブル」の「地区コード」フィールドを除き，一致したフィールドないし同一のテーブルの同種フィールドにプライマリー・キーが設定されている。また，別紙５，別紙８（青丸と青丸を結ぶ黒線〔黒太線を含む〕，及び，下記のとおり，青丸と青丸を結ぶ黒点線が，当裁判所の認めるリレーションである。）のとおり，原告ＣＤＤＢのマスターテーブルと一致する２８個のテーブルに関して，原告ＣＤＤＢに存在する関連付けのほぼ全てについて，同様のリレーションが被告ＣＤＤＢ（当初版・２００６年版）に存在するものといえる（なお，原告ＣＤＤＢの「０１市区町村テーブル」と「２０ホテル・旅館テーブル」，「２１観光施設テーブル」とのリレーション，被告ＣＤＤＢ（当初版・２００６年版）の「４市区町村マスタ」と「２１施設マスタ」，「２９旅館マスタ基本」，「２３観光施設マスタ」，「２６観光料金マスタ」のテーブルとのそれぞれのリレーションの関係の評価については，後記のとおり）。
なお，この点に関して被告らは，被告ＣＤＤＢ（当初版・２００６年版）の「道路構成地点マスタ〔テーブルＩＤ；ＡＺＭＲＯＡＤＰ〕」の「道路構成地点番号」フィールドと「道路構成地点索引マスタ〔テーブルＩＤ；ＡＺＭＲＯＡＤＱ〕」の「道路構成地点インデックス」フィールド及び「構成地点数」フィールドとの各リレーション，「３６道路名マスタ〔テーブルＩＤ；ＡＺＭＲＯＡＤＡ〕」の「道路コード」フィールドと「道路構成地点索引マスタ」の「道路構成地点インデックス」フィールドとのリレーションをいずれも否認し（別紙８で青丸と青丸を結ぶ黒点線で示されたリレーション），「道路構成地点マスタ」の「レコード番号」フィールドと「道路構成地点索引マスタ」の「道路構成地点インデックス」フィールドとのリレーション，「３６道路名マスタ」の「道路コード」フィールドと「道路構成地点索引マスタ」の「レコード番号」フィールドとのリレーションの存在を主張するが（別紙８で赤丸と赤丸を結ぶ赤点線で示されたリレーション），別紙３記載のとおりの被告ＣＤＤＢ（当初版・２００６年版）の「道路構成地点マスタ」，「道路構成地点索引マスタ」，「３６道路名マスタ」の各テーブルに含まれるフィールドの数やプライマリー・キーの設定状況を含めたフィールドの内容，「４市区町村マスタ」及び「２１施設マスタ」のテーブル等に存するそれぞれの「代表道路地点コード」フィールド等と「道路構成地点マスタ」の「道路構成地点番号」フィールドとの間にリレーションがとられていることについて争いがないこと，被告らが，別紙４記載のとおり，「３６道路名マスタ」，「道路構成地点マスタ」，「道路構成地点索引マスタ」について，いずれも原告ＣＤＤＢの対応するフィールド等からデータをコピーしたとしているところ，そのデータの内容などからすると，別紙８記載のとおり，「道路構成地点マスタ」テーブルの「道路構成地点番号」フィールドと「道路構成地点索引マスタ」テーブルの「道路構成地点インデックス」フィールド及び「構成地点数」フィールドとの各リレーション，「３６道路名マスタ」テーブルの「道路コード」フィールドと「道路構成地点索引マスタ」テーブルの「道路構成地点インデックス」フィールドとのリレーション（別紙８で青丸と青丸を結ぶ黒点線で示されたリレーション）の存在がいずれも認められる。これに対し，被告ＣＤＤＢ（当初版・２００６年版）の「３６道路名マスタ」の「道路コード」フィールドと「道路構成地点索引マスタ」の「レコード番号」フィールドと「道路構成地点マスタ」の「レコード番号」フィールドと「道路構成地点索引マスタ」の「道路構成地点インデックス」フィールドとのリレーションの存在について，「道路構成地点索引マスタ」の「レコード番号」フィールドと「道路構成地点マスタ」の「レコード番号」フィールドには，それぞれプライマリー・キーが設定されているものの，上記のとおり争いのない「道路構成地点マスタ」の「道路構成地点番号」フィールドと他のテーブルの各地点コードフィールドとのリレーション，「３６道路名マスタ」の「道路コード」フィールドと他のテーブルの各道路コードないし道路番号フィールドとのリレーションの関係や，上記のとおりの原告主張のリレーション（別紙８で青丸と青丸を結ぶ黒点線で示されたリレーション）の存在が認められること等からして，被告ら主張のリレーション（別紙８で赤丸と赤丸を結ぶ赤点線で示されたリレーション）の存在は認められないというべきである。


また，上記のとおり，被告ＣＤＤＢ（当初版・２００６年版）では，原告ＣＤＤＢの「２０ホテル・旅館テーブル」，「２１観光施設テーブル」，「２２観光施設備考テーブル」の３テーブルに対応するテーブルとして，被告ＣＤＤＢ（当初版・２００６年版）では「２１施設マスタ」，「２９旅館マスタ基本」，「２３観光マスタ基本」，「２６観光料金マスタ」の４テーブルを設けており，このうち「２１施設マスタ」テーブルについては，別紙３，５，８記載の原告ＣＤＤＢの「２０ホテル・旅館テーブル」，「２１観光施設テーブル」，被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」，「２９旅館マスタ基本」，「２３観光マスタ基本」，「２６観光料金マスタ」の各テーブルのそれぞれのフィールド，テーブル間のリレーションの内容を比較すると，被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」テーブルは，原告ＣＤＤＢの「２０ホテル・旅館テーブル」及び「２１観光施設テーブル」の共通項目を括りだしたものと認められ，上位のテーブルとして設けられているものと認められる。そして，原告ＣＤＤＢにおける「０１市区町村テーブル」が「２０ホテル・旅館テーブル」及び「２１観光施設テーブル」の二つのテーブルとリレーションを取っているのに対して，被告ＣＤＤＢ（当初版・２００６年版）では「４市区町村マスタ」は，原告ＣＤＤＢの「２０ホテル・旅館テーブル」及び「２１観光施設テーブル」の共通項目を括りだした上位のテーブルとなっている「２１施設マスタ」の一つのテーブルとのみリレーションを取っていることから，これと関連するリレーションの線の分が，別紙５と別紙８を対比すると，少なくなっている。イ被告ＣＤＤＢ（当初版・２００６年版）の体系的構成が，原告ＣＤＤＢの複
製又は翻案に当たるか
(ｱ)上記のとおり，原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とでは，原告ＣＤＤＢにおける，「０１市区町村テーブル」，「０２地区・県名テーブル」，「０５緯度経度テーブル」，「０６ＵＲＬアドレステーブル」，「０７ＵＲＬ種別テーブル」，「０８ＵＲＬ分類テーブル」，「０９地点名テーブル」，「１０道路テーブル」，「１１接続テーブル」，「１２禁止乗換テーブル」，「１３有料道路番号テーブル」，「１４区間料金テーブル」，「１５首都高速料金テーブル」，「１６道路構成地点テーブル」，「１７道路構成地点索引テーブル」，「１８市区町村通過道路索引テーブル」，「１９県範囲定義テーブル」，「２０ホテル・旅館テーブル」，「２１観光施設テーブル」，「２２観光施設備考テーブル」，「２８協定施設テーブル」，「２９券種テーブル」，「３０協定旅館テーブル」，「３１連結協定テーブル」，「３２駅テーブル」，「４２会社テーブル」及び「４４地方別会社索引テーブル」の２７個のテーブルにつき，これと一致する２８個のテーブルが被告ＣＤＤＢ（当初版・２００６年版）にも存する。そして，別紙３のとおり，原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とで一致するテーブルに存する総フィールドも２８８個にのぼり，このうち，原告ＣＤＤＢと一致するフィールド数は，２５２個である。さらに，テーブル間の関連付けについてみると，原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とでは，別紙５，８のとおり，原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とで一致するフィールドについて，同様のリレーションが存するものと認められる。上記のとおり，被告ＣＤＤＢ（当初版・２００６年版）では，「２１施設マスタ」を原告ＣＤＤＢの「２０ホテル・旅館テーブル」及び「２１観光施設テーブル」の上位のテーブルとして設けているところから，原告ＣＤＤＢにおける「０１市区町村テーブル」と「２０ホテル・旅館テーブル」，「２１観光施設テーブル」とのリレーションに比して，被告ＣＤＤＢ（当初版・２００６年版）の「４市区町村マスタ」は上位テーブルの「２１観光施設マスタ」とのみリレーションをとっており，これと関連するリレーションの線が，原告ＣＤＤＢと比して，その分少なくなっている。しかし，上記のとおり，原告ＣＤＤＢの「２０ホテル・旅館テーブル」，「２１観光施設テーブル」，「２２観光施設備考テーブル」についても，これら三つのテーブルに対応する，被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」，「２９旅館マスタ基本」，「２３観光マスタ基本」，「２６観光料金マスタ」と実質的に一致するテーブルであると認められること，そして，これらテーブルに含まれるフィールドの内容等からして，原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）における「０１市区町村テーブル」ないし「４市区町村マスタ」と，宿泊施設及び観光施設等のテーブルとのそれぞれのリレーションのとり方は，実質的には同一であるものと認められる。


(ｲ)前記認定のとおり，原告ＣＤＤＢは，それまで存しなかった団体旅行の行程検索・行程表作成のため，顧客である旅行業者等からのヒアリングや寄せられた要望等に基づき，出発地，到着地，交通手段，経由地である観光施設，宿泊施設をデータベース化してこれをコンピュータで効率よく検索できるようにするためのデータベースであるところ，上記被告ＣＤＤＢ（当初版・２００６年版）と共通するテーブルに関してみると，原告ＣＤＤＢの「０１市区町村テーブル」，「３２駅テーブル」，「２０ホテル・施設テーブル」，「２１観光施設テーブル」，「０９地点名テーブル」，「１１接続テーブル」及び「１０道路テーブル」により，出発地，経由地，目的地に面した道路に関するデータの検索を可能にし，次に「０９地点名テーブル」，「１０道路テーブル」，「１１接続テーブル」，「１２禁止乗換テーブル」，「１４区間料金テーブル」及び「１５首都高速料金テーブル」により，道路を利用した移動に関する経路探索・料金の算出に必要なデータの検索を可能にしていること，また，「２０ホテル・旅館テーブル」，「２１観光施設テーブル」，「２２観光設備備考テーブル」，「０５緯度経度テーブル」，「０６ＵＲＬアドレステーブル」，「０７ＵＲＬ種別テーブル」及び「０８ＵＲＬ分類テーブル」により，ホテル・旅館，観光施設に関する情報を検索することを可能にしていること，そして，「０１市区町村テーブル」及び「０２地区・県名テーブル」は，道路と地図を関連付ける情報として，地図から検索をするときに用いられていること，「０１市区町村テーブル」，「２０ホテル・旅館テーブル」，「２１観光施設テーブル」及び「３２駅テーブル」には施設等の近辺の道路地点の情報が代表道路地区コードや代表道路地点番号として格納されており，当該市区町村内にあるこれらの施設や駅などを選ぶことを通じて，「０９地点名テーブル」の必要な道路地点を選ぶことができること，観光施設も「２１観光施設テーブル」から選択し，絞り込みは，「０２地区・県名テーブル」，「０１市区町村テーブル」から行うことができること，観光施設の名称は「２１観光施設テーブル」に，検索結果の観光施設について，当該観光施設に関する様々の情報は，「２２観光施設備考テーブル」に格納されており，観光施設に関するホームページの情報も「０６ＵＲＬアドレステーブル」，「０７ＵＲＬ種別テーブル」から参照可能であり，最終的に行程に入れるかどうかを判断することができること，が認められる。また，宿泊施設については，「２０ホテル・旅館テーブル」から選択し，地区は「０２地区・県名テーブル」，都道府県も同じく「０２地区・県名テーブル」，市区町村は「０１市区町村テーブル」，地図上の範囲設定は，地図ソフトと「０５緯度経度テーブル」，「２０ホテル・旅館テーブル」により，宿泊種別は「２０ホテル・旅館テーブル」，名称は「２０ホテル・旅館テーブル」，検索結果の宿泊施設については当該宿泊施設に関する様々な情報，すなわち，和室，洋室の客室数，収容人員，料金，付帯施設，駐車場などが「２０ホテル・旅館テーブル」に格納されていて，当該宿泊施設に関するホームページの情報も「０６ＵＲＬアドレステーブル」，「０７ＵＲＬ種別テーブル」が対応し，これらを参照して，ユーザーである旅行会社ないしその顧客の判断で行程等を決めることができることが認められる。以上のとおり，これら共通するテーブルについては，いずれも各テーブルを構成するフィールドにつき，原告ＣＤＤＢと，被告ＣＤＤＢ（当初版・２００６年版）とでほとんどが共通し，リレーションのとり方もほぼ共通するものである。
そして，両者で共通するこれらの体系的構成は，原告ＣＤＤＢの制作者において，それまでのデータベースにはなかった設計思想に基づき構成した原告ＣＤＤＢの創作活動の成果であり，その共通する部分のみでデータベースとして機能し得る膨大な規模の情報分類体系であると認められ，データベースとして制作者の個性が表現されているものということができる。したがって，被告ＣＤＤＢ（当初版・２００６年版）と共通する上記原告ＣＤＤＢの部分については，データベースの体系的構成としての創作性を有するものと認めるのが相当である。
(ｳ)一方，原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とを比較すると，両者で一致しないマスターテーブルとして，被告ＣＤＤＢ（当初版・２００６年版）の「２５観光料金種別マスタ」，「２７観光種別マスタ」と「２８観光詳細種別マスタ」があり，これらは，原告ＣＤＤＢには含まれないものである。
このうち「２５観光料金種別マスタ」については，そこに含まれるフィールドをみると，プライマリー・キーの設定された「料金種別コード」フィールド，「料金種別名称」，「料金メモ（管理用）」の各フィールドのほかは，フラグや日付，区分等のフィールドであり，このうち料金種別にかかるものは，原告ＣＤＤＢの「２１観光施設テーブル」，「２２観光施設備考テーブル」では４種類までの料金しか登録することができないところ，被告ＣＤＤＢ（当初版・２００６年版）の「２５観光料金種別マスタ」を設けることにより５種類以上の料金設定についても登録できるようにテーブルを設けることとしたものである。〔乙２０〕
しかし，上記のとおり原告ＣＤＤＢでも料金種別により分類可能であったところ，これについて，料金種別を増やすためにテーブルを設けること自体は，原告ＣＤＤＢに新たに創作的表現を加えたものとはいい難い。また，「２７観光種別マスタ」と「２８観光詳細種別マスタ」については，上記のとおり，原告システムをユーザーのハードウェア内にインストールした際に作成される原告マスターテーブルの中に，これら二つのテーブルに対応するマスターテーブルである「２３観光施設種別テーブル」及び「２４観光施設検索タイトルテーブル」が存在し，しかも，これらテーブルについてのテーブルの種類やＩＤのほとんどが原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とで一致することなどからすれば，これらは被告ＣＤＤＢ（当初版・２００６年版）において新たに加わった創作的表現の成果ということはできず，実質的に原告システム中に存する原告ＣＤＤＢと関連する部分を，ＣＤで提供されるデータベース中に移した関係にすぎないものと認められる。


そして，フィールドについてみても，被告ＣＤＤＢ（当初版・２００６年版）の「道路構成地点マスタ」，「道路構成地点索引マスタ」の各「レコード番号」フィールドについては，それぞれ「道路構成地点索引マスタ」テーブルの「道路構成地点インデックス」フィールド，「３６道路名マスタ」テーブルの「道路コード」フィールドとのリレーションがとられていること等からすると，原告ＣＤＤＢの「１６道路構成地点テーブル」，「１７道路構成地点索引テーブル」の各テーブルを構成するフィールドと実質的な相違はないものと認められる。
さらに，リレーションのとり方についてみても，原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とで異なるリレーションとなっている，被告ＣＤＤＢ（当初版・２００６年版）で「４市区町村マスタ」は，施設に関しては「２１施設マスタ」とのみリレーションをとっていることから，原告ＣＤＤＢにおける「０１市区町村テーブル」が「２０ホテル・旅館テーブル」，「２１観光施設テーブル」の二つのテーブルとリレーションをとっていることに対して，リレーションが少なくなっているところ，既に検討したとおり，被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」及びこれと関連する，「２９旅館マスタ基本」，「２３観光マスタ基本」テーブルについては，原告ＣＤＤＢの「２０ホテル・旅館テーブル」，「２１観光施設テーブル」とは実質的に一致するテーブルであると認められることや，別紙８のとおり認められる被告ＣＤＤＢ（当初版・２００６年版）の「４市区町村マスタ」，「３１ＵＲＬアドレスマスタ」，「３４緯度経度マスタ」テーブル等と，「２１施設マスタ」，「２９旅館マスタ基本」，「２３観光マスタ基本」テーブル等，及び，「２１施設マスタ」テーブルと，「２９旅館マスタ基本」，「２３観光マスタ基本」テーブルとのリレーションのとり方からすると，リレーションのとり方において，被告ＣＤＤＢ（当初版・２００６年版）のリレーションのとり方には，原告ＣＤＤＢのリレーションのとり方に，新たな創作性を加えたものとはいえない。
(ｴ)そうすると，これら被告ＣＤＤＢ（当初版・２００６年版）が原告ＣＤＤＢと共通性を有する部分は，原告ＣＤＤＢの創作的表現の本質的特徴の同一性が維持されており，これを直接感得することができるものというべきであり，被告ＣＤＤＢ（当初版・２００６年版）において変更が加えられた部分については，創作性を有しない部分であるということができる。ウ被告ＣＤＤＢ（当初版・２００６年版）と原告ＣＤＤＢとの情報の選択の共
通性
(ｱ)フィールド項目の選択の類似性
前記のとおり，テーブル管理のためのフィールドである「登録日時」，「更新日時」及び「削除区分」のフィールドを除いた被告ＣＤＤＢ（当初版・２００６年版）のフィールド数のうち，２５２個が原告ＣＤＤＢのフィールドと一致している。
このうち，被告ＣＤＤＢ（当初版・２００６年版）の「４市区町村マスタ」の７個のフィールド，「０３都道府県マスタ」の４個のフィールド，「緯度経度マスタ」の４個のフィールド，「３１ＵＲＬアドレスマスタ」の５個のフィールド，「３５地点マスタ」の８個のフィールド，「３６道路名マスタ」の４個のフィールド，「３８禁止乗換マスタ」の２個のフィールド，「有料道路番号マスタ」のうちの「道路番号」フィールド，「３９料金マスタ」の５個のフィールド，「４０高速料金マスタ」の５個のフィールド，「道路構成地点マスタ」の「道路構成地点番号」フィールド，「道路構成地点索引マスタ」の２個のフィールド，「市区町村通過道路索引マスタ」の３個のフィールド，「県範囲定義マスタ」の４個のフィールド，「協定施設マスタ」の３１個のフィールド，「券種マスタ」の１９個のフィールド，「協定旅館マスタ」の２１個のフィールド，「連結協定マスタ」の３２個のフィールド，「４７駅マスタ」の１０個のフィールド，「４２会社マスタ」の４個のフィールド，「地方別会社索引マスタ」の２個のフィールドでは，フィールドＩＤが原告ＣＤＤＢの対応するフィールドと完全に一致している。詳細は別紙３記載のとおりである。
また，原告ＣＤＤＢの「２０ホテル・旅館テーブル」の「加盟団体種別」フィールドと被告ＣＤＤＢ（当初版・２００６年版）の「２９旅館マスタ基本」の「加盟団体種別」フィールド，原告ＣＤＤＢの「２０ホテル・旅館テーブル」の「和室客室数」・「洋室客室数」・「和洋室客室数」・「収容人員」・「付帯施設」フィールドと被告ＣＤＤＢ（当初版・２００６年版）の「２９旅館マスタ基本」の「和室数」・「洋室数」・「和洋室数」・「総収容人員」・「設備」フィールド，さらにはいずれもプライマリー・キーが設定されている，原告ＣＤＤＢの「２０ホテル・旅館テーブル」の「ホテル旅館コード」フィールドと被告ＣＤＤＢ（当初版・２００６年版）の「２９旅館マスタ基本」の「施設コード（施設番号）」フィールド，原告ＣＤＤＢの「２１観光施設テーブル」の「地区コード」・「都道府県コード」・「市区町村番号」・「観光施設名（カナ）」フィールドと被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」の「地区コード」・「都道府県コード」・「市区町村コード」・「名称かな」フィールド，いずれもプライマリー・キーが設定された原告ＣＤＤＢの「２１観光施設テーブル」の「観光施設番号」フィールドと被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」の「施設コード」フィールド，原告ＣＤＤＢの「２１観光施設テーブル」の「施設経度」・「施設緯度」・「代表道路地点番号」フィールドと被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」の「施設経度」・「施設緯度」・「代表道路地点コード」フィールド等においても，フィールドＩＤが完全に一致している。
そうすると，フィールド項目の選択について，これらは一致しているものと認められる。
（ｲ）レコードの選択の類似性


さらに，被告らは，被告ＣＤＤＢ（当初版・２００６年版）において，原告ＣＤＤＢのテーブルのうち，以下の２０個のテーブルに含まれるレコードをコピーして用いたことを認めている。
そのテーブルとは，「２０ホテル・旅館テーブル」，「２１観光施設テーブル」，「０５緯度経度テーブル」，「０６ＵＲＬアドレステーブル」，「０７ＵＲＬ種別テーブル」，「０８ＵＲＬ分類テーブル」，「０１市区町村テーブル」，「０２地区・県名テーブル」，「０９地点名テーブル」，「１０道路テーブル」，「１１接続テーブル」，「１２禁止乗換テーブル」，「１３有料道路番号テーブル」，「１４区間料金テーブル」，「１５首都高速料金テーブル」，「１６道路構成地点テーブル」，「１７道路構成地点索引テーブル」，「１８市区町村通過道路索引テーブル」，「１９県範囲定義テーブル」及び「３２駅テーブル」である。
そして，別紙４の各テーブルのレコード数記載のとおり，このうち，レコード数が４７で同一であり，一般的な内容のとおりであることが推認される「０２地区・県名テーブル」を除き，原告ＣＤＤＢの「０９地点名テーブル」，「１０道路テーブル」，「１１接続テーブル」，「１２禁止乗換テーブル」，「１４区間料金テーブル」，「１５首都高速料金テーブル」，「１６道路構成地点テーブル」，「１７道路構成地点索引テーブル」，「１８市区町村通過道路索引テーブル」，「１９県範囲定義テーブル」及び「３２駅テーブル」においては，それらテーブルのそれぞれの数百ないし数十万のレコード数につき，各近似するレコード数が被告ＣＤＤＢ（当初版・２００６年版）の対応するテーブルには収録されている。
(ｳ)具体的な情報の同一ないし類似性
a地点名テーブルの道路情報
原告ＣＤＤＢ（２００６年１１月版）の「０９地点名テーブル」には，１万２８２２件のレコードが収録され，被告ＣＤＤＢ（当初版・２００６年版）の「３５地点マスタ」には，そのうちの９９．６％である１万２７７４件につき，一致する道路地点（例えば，「関ＪＣＴ（伊勢自動車道・名阪国道）」，「芸濃ＩＣ（伊勢自動車道，県道１０号）」等）のレコードが収録されている。〔甲３２〕
b緯度経度情報の一致
そして，原告ＣＤＤＢの「０９地点名テーブル」の上記道路地点の緯度経度情報は，前記のとおり，原告ＣＤＤＢ作成時に，作成者自身がパソコンのマウスを地図上でクリックする方法で選択した場所について，これを０．１秒単位で緯度経度を測定して数値化したものである。その際，原告ＣＤＤＢにおいては，一般的な度・分・秒の表記ではなく，度・分・秒につき，０．１秒単位で，Ａ度Ｂ分Ｃ．Ｄ秒を以下の計算式で算出された数値で収録しており，６ないし７桁の数値となって算出される。なお，この０．１秒は，実際には約３メートルである。（計算式）Ａ×３６０００＋Ｂ×６００＋Ｃ×１０＋Ｄ例えば，上記「関ＪＣＴ（伊勢自動車道・名阪国道）」については，一般的な度・分・秒表記であれば，経度１３６度２４分４８．２秒，緯度３４度５０分３３．１秒であるところ，これを上記表記で表すと，経度「４９１０８８２」，緯度「１２５４３３１」となる。
被告ＣＤＤＢ（当初版・２００６年版）も，６ないし７桁の数値で緯度経度情報を収録しているところ，被告ＣＤＤＢ（当初版・２００６年版）の「関ＪＣＴ（伊勢自動車道・名阪国道）」の緯度経度表記も，全く同じ経度「４９１０８８２」，緯度「１２５４３３１」であり，上記道路地点のうち，この６ないし７桁で表される緯度及び経度情報につき，これが原告ＣＤＤＢ（２００６年１１月版）と完全に数値が一致する率（完全一致率）は９８．７％であり，１万２６５２件の一致するレコードが収録されている。〔甲２２，２８，３２，３９，７０〕
ｃ選択道路の一致
原告ＣＤＤＢは，上記のとおり，大型観光バスでの移動に適した道路の選択を行っており，多くの府県道，道道等の中から，北海道では８０道道，福岡県では４７県道を選択しているところ，被告ＣＤＤＢ（当初版・２００６年版）では，北海道では全く同じ８０道道を，福岡県でもこれと一致する県道のうち４１県道を選択している。〔甲４８〕
ｄその他の情報の一致
(a)原告ＣＤＤＢの「０６ＵＲＬアドレステーブル」と被告ＣＤＤＢ（当初版・２００６年版）の「３１ＵＲＬアドレスマスタ」における情報の
一致
ⅰ被告ＣＤＤＢ（当初版・２００６年版）では，同一の宿泊施設のＵＲＬデータを，「マスタ種別（ＵＲＬ種別）」フィールド（フィールドＩＤ；ＲＬ１ＫＩＮＤ）の「５」（以下，「ＵＲＬ種別５」という。）に，原告ＣＤＤＢの「テーブル種別」フィールド（フィールドＩＤ；ＲＬ１ＫＩＮＤ）と同じ施設番号で登録するとともに，これを再び「マスタ種別（ＵＲＬ種別）」フィールド（フィールドＩＤ；ＲＬ１ＫＩＮＤ）の「８」（以下，「ＵＲＬ種別８」という。）に，原告ＣＤＤＢと異なる施設番号で，重複登録している。


すなわち，原告ＣＤＤＢでは，「テーブル種別」フィールド（フィールドＩＤ；ＲＬ１ＫＩＮＤ）のＵＲＬ種別の「５」として宿泊施設のＵＲＬデータを登録している。他方，被告ＣＤＤＢ（当初版・２００６年版）は宿泊施設と観光施設のＵＲＬデータを，ＵＲＬ種別８として統合して登録していることに加え，ＵＲＬ種別５としても，宿泊施設の同じＵＲＬデータを重複登録していることになる。その例として，原告ＣＤＤＢ「テーブル種別」フィールド（フィールドＩＤ；ＲＬ１ＫＩＮＤ）のＵＲＬ種別５の施設番号１番である「アイスバーグホテル」は，被告ＣＤＤＢ（当初版・２００６年版）のＵＲＬ種別５に原告ＣＤＤＢと同じ施設番号１番で格納されているところ，被告ＣＤＤＢ（当初版・２００６年版）のＵＲＬ種別８では，同じ「アイスバーグホテル」が，施設番号９４４０番として重複登録されている。すなわち，被告ＣＤＤＢ（当初版・２００６年版）は，同一の施設について，ＵＲＬ種別５とＵＲＬ種別８とで異なる施設番号を付与してそれぞれ登録している。原告ＣＤＤＢ「テーブル種別」フィールド（フィールドＩＤ；ＲＬ１ＫＩＮＤ）のＵＲＬ種別５の施設番号２番である「札幌第一ホテル本館」等についても，同様である。〔甲６５の別紙１〕
これらは，原告ＣＤＤＢのＵＲＬ種別５のデータを一旦コピーし，その後これをＵＲＬ種別８に番号を変えて登録したが，ＵＲＬ種別５のデータもそのまま残存してしまったことによるものと認められる。そして，この原告ＣＤＤＢの「テーブル種別」フィールド（フィールドＩＤ；ＲＬ１ＫＩＮＤ）に登録されている上記ＵＲＬデータにつき，被告ＣＤＤＢ（当初版・２００６年版）において，１万５０００件以上のデータが一致している。〔甲６５〕
ⅱ上記宿泊施設の重複登録と同様のことが，観光施設についてのＵＲＬデータについても認められる。
被告ＣＤＤＢ（当初版・２００６年版）は同一の観光施設のＵＲＬデータを，「マスタ種別（ＵＲＬ種別）」フィールド（フィールドＩＤ；ＲＬ１ＫＩＮＤ）の「６」（以下，「ＵＲＬ種別６」という。）に，原告ＣＤＤＢの「テーブル種別」フィールド（フィールドＩＤ；ＲＬ１ＫＩＮＤ）と同じ施設番号で登録するとともに，ＵＲＬ種別８に原告ＣＤＤＢと異なる施設番号で重複登録している。すなわち，原告ＣＤＤＢは，「テーブル種別」フィールドに，ＵＲＬ種別６として観光施設のＵＲＬデータを登録しているところ，被告ＣＤＤＢ（当初版・２００６年版）は宿泊施設と観光施設のＵＲＬデータをＵＲＬ種別８として統合して登録していることに加え，ＵＲＬ種別６として観光施設につき，同じＵＲＬデータを重複登録している。例えば，原告ＣＤＤＢのＵＲＬ種別６の施設番号１番の「朝里岳」が，被告ＣＤＤＢ（当初版・２００６年版）のＵＲＬ種別６に原告ＣＤＤＢと同じ施設番号１番で格納されているところ，被告ＣＤＤＢ（当初版・２００６年版）の種別８でも，同じ「朝里岳」が施設番号１１７１７４番として重複登録されている。登録番号２の「無意根山」等でも同様である。〔甲６５の別紙２〕
すなわち，被告ＣＤＤＢ（当初版・２００６年版）は，同一の観光施設について，上記宿泊施設と同様に，ＵＲＬ種別６とＵＲＬ種別８とで，異なる施設番号を付与して重複登録している。
これも，上記同様，被告ＣＤＤＢ（当初版・２００６年版）が原告ＣＤＤＢのＵＲＬ種別６のデータを一旦コピーし，その後種別番号８に番号を変えて登録したが，ＵＲＬ種別６のデータもそのまま残存してしまったことによるものと認められる。
これについても，原告ＣＤＤＢにおいて登録されている４万件以上のＵＲＬデータが，被告ＣＤＤＢ（当初版・２００６年版）と一致している。〔甲６５〕
ⅲＵＲＬに関し，原告ＣＤＤＢは，開発者の便宜のためとして，ＵＲＬ種別番号の１００００以降には，リンク集として，各種ＵＲＬデータを選択して登録している。このＵＲＬデータの登録は，原告ＣＤＤＢの制作者において，任意に選択して行ったものであることは，ＵＲＬデータの内容からも明らかである。その例としては，後記のほか，種別キ   ー１番   の優先   順位２   ないし   ４は，   順番に   ，「全   国鉄道   会社OFFICIAL系サイト総合リンク」，「国道９０１号」，「秩父札所めぐり［西武鉄道ＨＰ］」となっていること等からも明らかである。〔甲
６５の別紙３〕


被告ＣＤＤＢ（当初版・２００６年版）におけるこのＵＲＬデータは，原告ＣＤＤＢと完全に一致している。この中には，被告ＣＤＤＢ（当初版・２００６年版）の用途等に鑑みると，意味があるものとは考えにくい翼システムのＵＲＬが，３箇所（タイトルが「注意書き」の２箇所，「翼システム株式会社」の１箇所，合計３箇所）も重複登録されている点についても，完全に一致している。〔甲６５の別紙３〕(b)原告ＣＤＤＢの「１１接続テーブル」と被告ＣＤＤＢ（当初版・２００６年版）の「３７接続マスタ」における情報の一致原告ＣＤＤＢの「１１接続テーブル」と被告ＣＤＤＢ（当初版・２００６年版）の「３７接続マスタ」において，各接続番号が一致している。この接続番号の付与は，前記のとおり，隣接する道路地点間を一単位として，その一単位ごとに，原告ＣＤＤＢの制作者において付与した番号であり，機能としては，二地点間の情報を識別するものである。この接続番号は，原告ＣＤＤＢにおいて定められた，ある道路の一単位を登録する都度，上記のとおり原告システムの制作者において，任意に付与したものである。
これについて，被告ＣＤＤＢ（当初版・２００６年版）の「３７接続マスタ」において，各道路の一単位に対して，原告ＣＤＤＢと同じ接続番号が付与されている。〔甲２８の別紙８。なお，別紙８の１／２の始点番号，終点番号につき，実際の地点名称を表示したものが２／２であり，格納されているデータが実質的に同じであることが認められる。〕
(c)原告ＣＤＤＢの「１２禁止乗換テーブル」と被告ＣＤＤＢ（当初版・２００６年版）の「３８禁止乗換マスタ」における情報の一致原告ＣＤＤＢの「１２禁止乗換テーブル」の「乗換元接続番号」，「乗換先接続番号」の各フィールドには，接続テーブルのデータが格納されている。これらのデータが原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とで一致している。〔甲２８の別紙９〕被告らは，原告ＣＤＤＢからコピーして入力し，追加，修正，削除した旨主張するが，原告ＣＤＤＢの「１２禁止乗換テーブル」のフィールドは，「乗換元接続番号」，「乗換先接続番号」の二つの数値フィールドのみで構成されており，しかもその内容は，数値を羅列した表にすぎないから，一般的な資料等と比較することで，その正誤判定や修正等を行うことができない性質のものということができる。加えて，原告ＣＤＤＢの「１２禁止乗換テーブル」は，「０９地点名テーブル」のデータを３レコード分使用した上で，「１０道路テーブル」の２レコード分，「１１接続テーブル」の２レコード分のデータを使用し，これらテーブルとリレーションを取ることによって，はじめて意味のあるテーブルとなるものである。これらは，上記の原告ＣＤＤＢの設計ないし情報の選択の方針に基づいてデータを組み合わせてできたものであり，一般的な資料と比較して正誤判定等を行う性質のものでもなく，またその正誤判定等が可能なものとも認められない。
〔甲７０，１０頁〕
(d)原告ＣＤＤＢの「１９県範囲定義テーブル」と被告ＣＤＤＢ（当初版・２００６年版）の「県範囲定義マスタ」における情報の一致ⅰ原告ＣＤＤＢが「１９県範囲定義テーブル」において，原告が独自に設定した登録データについて，被告ＣＤＤＢ（当初版・２００６年版）の「県範囲定義マスタ」に，同一のものが存在する。原告ＣＤＤＢの「１９県範囲定義テーブル」のテーブルは，出発都道府県から到着都道府県までの経由可能性のある都道府県を管理しているテーブルであり，原告ＣＤＤＢは，例えば，北海道から青森県までの経由可能性のある都道府県に関しては，「北海道，青森県，岩手県，秋田県」（通常想定される経路に比して原告が独自に設定した点は，岩手県，秋田県が入っていることである。），北海道から岩手県では，「北海道，青森県，岩手県，宮城県，秋田県，山形県」（原告が独自に設定した点は，宮城県，秋田県，山形県が入っていることである。）となっている。同様に他の例でも経由都道府県が，原告が独自に設定した組合せで選択格納されている。この４７都道府県における出発と到着のパターンは２２０９（４７×４７）パターンあることになるが，被告ＣＤＤＢ（当初版・２００６年版）では，原告ＣＤＤＢの経由都道府県の組合せデータを完全に一致する形で格納している。〔甲６５の別紙８〕
ⅱ原告ＣＤＤＢの「１９県範囲定義テーブル」の，行程を開始する都道府県のコードである「始点県番号」，行程を終了する都道府県のコードである「終点県番号」，４７都道府県の内３２都道府県を通過するかどうかのデータである「県範囲定義ビット１」，４７都道府県の内１５都道府県を通過するかどうかのデータである「県範囲定義ビット２」の各フィールドに格納されているデータが，被告ＣＤＤＢ（当初版・２００６年版）の「県範囲定義マスタ」で一致している（フィールドＩＤ等も全て一致することについては，別紙３のとおりである。）。ある都道府県からある都道府県に向かう場合，通過する都道府県にどの県を組み入れるかには選択の幅があると認められるところ，これを表した原告ＣＤＤＢの県範囲定義ビット１，県範囲定義ビット２についても，このような選択範囲をとること自体については，選択の幅があるものと認められる。〔甲２８の別紙１０，甲６５の別
紙８〕
エ被告ＣＤＤＢ（当初版・２００６年版）の情報の選択が，原告ＣＤＤＢの
複製又は翻案に当たるか


(ｱ)前記のとおり，原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とでは，情報項目としてのテーブル，フィールドの設定について，被告ＣＤＤＢ（当初版・２００６年版）のテーブル数３１個のうちの，２８個においてテーブルが一致している。そして，フィールド項目についても，３１８個のフィールドのうち，２５２個のフィールドが一致している。(ｲ)そして，前記のとおり，原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）とで一致する，地点名テーブルの道路情報，緯度経度情報，接続テーブル及び禁止乗換テーブルの情報，県範囲定義テーブルの各情報は，いずれも原告ＣＤＤＢの制作者において，前記認定のとおり，それぞれ選択の幅のある中から一定の選択方針に基づき選定し，あるいは全く任意に番号等設定したものであり，それぞれ創作性を有するものと認められる。(ｳ)さらに，原告ＣＤＤＢにおいては，前記のとおり，旅行会社に対する実情調査等の結果を踏まえ，主たる目的として，大型観光バスによる団体旅行を主眼とした行程表作成のための便宜から，通常使用されるロードマップとは異なる観点である，貸切観光バスが通行するのに適した道路として，都道府県道については約１０％，市区町村道では約０．００４％程度を選択して「１０道路テーブル」に格納し，道路地点として選択した地点における情報も緯度及び経度のデータとして格納することとし，これを大型観光バスが通過するのに適切と考えられる道路のうちの，行程表を作成する上で必要と考えられる適切な地点である，交差点，インターチェンジ，サービスエリア，パーキングエリア，観光施設，宿泊施設，駅，役所等の代表道路地点とするのに適切な地点を選別し，パソコンのマウスを地図上でクリックする方法で選択して，実際に入力したものである。また，施設と関係する代表道路地点の選択においても，施設が存する場所の緯度経度による地点ではなく，大型観光バスでの出入りの観点から，当該施設の近辺の道路地点を選び，当該施設の代表道路地点として適宜設定している。
このように，原告ＣＤＤＢと被告ＣＤＤＢ（当初版・２００６年版）との共通部分である，道路，道路位置，代表道路地点等の選別・選択についても，原告ＣＤＤＢの制作者による創作活動の成果が表れており，創作者の個性が表現されているものといえる。
したがって，被告ＣＤＤＢ（当初版・２００６年版）と共通する上記原告ＣＤＤＢの部分については，データベースの情報の選択としての創作性を有するものと認めるのが相当である。
(ｴ)そして，これら被告ＣＤＤＢ（当初版・２００６年版）が原告ＣＤＤＢと同一性を有する情報の選択に関する部分も，原告ＣＤＤＢの創作的表現の本質的特徴を直接感得することのできる同一性が維持されているものというべきである。
オ被告らの主張に対する判断
(ｱ)被告らは，原告ＣＤＤＢにおける情報の選択は，客観的，標準的な基準に従った没個性的・汎用的なものにすぎず，創作性がないと主張する。しかし，前記のとおり，原告ＣＤＤＢにおいて，道路や道路位置，代表道路地点，緯度経度情報，接続・禁止乗換，県範囲定義等を選択，選定するに当たっては，極めて多数にのぼる選択対象として幅のある中から，専ら大型観光バスでの移動を前提とした効率的な経路検索，行程表作成を可能とするという観点からの情報の選別等がされており，その情報の選択には制作者の個性が表れており，創作性があるものということができる。したがって，被告らの上記主張は採用することができない。(ｲ)被告らは，被告ＣＤＤＢ（当初版・２００６年版）の施設情報に関する設計思想は，柔軟な検索や旅行計画の作成を利用者（旅行業者）が行うようになることを想定し，将来におけるデータベースとしての拡張性や格納効率，保守性を最大限に高めるという視点から，施設情報に関するデータベースを設計することとしており，具体的には，施設マスタという独立したマスターテーブルを上位テーブルとして用意し，宿泊施設マスタや観光施設マスタといった施設の類型別のマスターテーブルを，施設マスタの下位テーブルとして位置付ける格納方法をとることとし，最大２階層でデータを保持するテーブル構成を採用し，これにより，被告ＣＤＤＢ（当初版・２００６年版）では，電話番号や住所などの施設の基本情報は，「宿泊施設」や「観光施設」といった施設類型の区別なく，一旦全て施設マスタに格納する設計としたことから，テーマに沿って施設を検索する場合に，データベースの構造上は，施設マスタのみを検索することで，テーマに沿った施設を検索することが可能な設計構造となったものである一方，原告ＣＤＤＢにおける施設情報の格納方法は，テーマ別検索を意図していないため，ホテル・旅館テーブルと観光施設テーブルの二つの施設類型別のマスターテーブルでのみ，施設に関する情報を格納しており，この点で体系的構成が異なる旨主張し，それに沿う証拠として，乙１９，２７を提出する。
しかし，乙１９，２７は，いずれも被告Ｙ１の作成した報告書であるところ，これらはいずれも被告らが用いる「格納方法」の語の意味について，被告ＣＤＤＢ（当初版・２００６年版）におけるテーブルやフィールド，リレーションとの関係でいかなる意味を持つかについては何ら具体的に明らかにするものではなく，被告ＣＤＤＢ（当初版・２００６年版）の「２１施設マスタ」，「２９旅館マスタ基本」及び「２３観光マスタ基本」については，原告ＣＤＤＢの「２０ホテル・旅館テーブル」及び「２１観光施設テーブル」と実質的に一致するテーブルであると認められることについては，既に検討したとおりである。


したがって，被告らの上記主張は採用することができない。(ｳ)被告らは，被告ＣＤＤＢも原告ＣＤＤＢも，「ＮＡＶＩＴＩＭＥ」やカーナビゲーションシステムなどルート・路線検索を行うシステムではほぼ必ず採用されている方法であるダイクストラ法という一般的でありふれた最短経路検索方法を採用しており，これを実現するために，地点（始点）と地点（終点）並びにその間の距離及び所要時間等を格納していくという具体的な情報の格納方法それ自体において特段顕著な差異が生じ得るものではなく，このような格納方法自体には創作性が認められない旨主張する。ａそこで，まず，ダイクストラ法について検討する。ダイクストラ法について，公開特許公報（特開平５－１１３３４０号，発明の名称「車載ナビゲータ」，出願日平成３年１０月２２日，出願人アルパイン株式会社，甲４５）には，以下の記載がある。・「出発地点から目的地点までの最適経路を求める方法として，ダイクストラ法と称せられる方法が提案されている。このダイクストラ法は出発地点と目的地点を結ぶ直線を半径とする領域，あるいは該領域より大きめの領域内に存在する全交差点を考慮して出発地から目的地迄の最短経路を交差点ネットリストＣＲＮＬを参照して探索するものである。図１０はダイクストラ法の概略説明図であり，道路を直線，交差点を直線の交点としてグラフ化したものであり，各交差点間の距離は既知で，ＳＴＰは出発地（交差点），ＤＳＰは目的地（交差点）である。」（段落【０００７】）
・「ダイクストラ法においては，交差点ネットリストＣＲＮＬを参照しながら，出発地を０次交差点として，該０次交差点に隣接する１次交差点1～Ａ4を探し，各１次交差点Ａ1   ～Ａ4に対応させて１つ前の次数の交差点（出発地交差点）及び出発地からの距離を求める。次いで，各１次交差点Ａ1～Ａ4について２次交差点Ｂij   を探し，各２次交差点に対応させて１次交差点及び出発地からの距離を求める。」（段落【０００８】）
・「【発明が解決しようとする課題】このようにダイクストラ法によれば，グラフ理論的に最短経路が求まる。」（段落【００１１】）ｂ上記記載によれば，ダイクストラ法自体は，地点間の最短経路を求める方法として公知のものであると認められるが，原告ＣＤＤＢは選択された出発地や観光施設，宿泊施設，到着地等の間での最短経路を探索することを行っているものとしても，前記認定のとおり，原告ＣＤＤＢの創作性については，原告ＣＤＤＢがダイクストラ法を実現するためのシステムとして創作性を有するとするものではなく，テーブルやフィールド，これらのリレーションの体系的構成について創作性を認めるものであるから，その創作性の有無は，ダイクストラ法を実現するものとしてありふれているか否かと直接関係するものではないというべきである。
したがって，被告らの上記主張は採用することができない。(ｴ)被告らは，他に同種のデータベースが存在することを前提として，原告ＣＤＤＢはありふれたものであって，著作物とはいえない旨主張し，それに沿う証拠として，乙３５の１ないし６を提出する。
しかし，株式会社エヌシステムのホームページには，平成８年（１９９６年）４月に，ＪＡ旅行センター向け旅行業営業支援システムである「応援団くん」の展開を開始した旨の記載があるが，そのシステムの内容については何ら記載がなく，その詳細は明らかではない。〔乙３５の１〕また，株式会社ＪＭＣ（ジェーエムシー）のホームページには，「国内行程表管理システム『ｅＺＲＯＵＴＥ（イージールート）』」に関する記載があるが，「カーナビで用いられている機能や詳細な電子地図を活用し，パソコン上でかんたん（＝イージー）に行程表を作成することが出来るツールです。作成した行程表はモデルコースとして登録し，社内で共有することができます。画像をクリックするとデモ画像が流れます。」と記載されているにすぎず，「ｅＺＲＯＵＴＥ」は，株式会社ＪＴＢ情報システムの国内行程表作成システムとして採用されているが，これについてもそのシステムの詳細は明らかではない。〔乙３５の２，乙３９，３頁〕
企業間取引サイトであるＡＮＴＡ－ＮＥＴのホームページには，「社団法人全国旅行業協会（ＡＮＴＡ）が運営する観光商品流通システムで，インターネットを通じて観光関連事業者（旅行業者，宿泊・観光・運輸施設等）の業務拡大を支援するＢｔｏＢ（企業間取引）サイトです。」との記載があるが，その詳細は何ら明らかではない。〔乙３５の３〕
株式会社ワールドエキスプレスによる「国内／海外旅程表作成＆見積集計旅行業支援システムＷｏｒｌｄ    ＴＡＣ」のホームページには，「国内・海外旅程表作成から見積書・請求書・実績集計まで一連の手配業務を徹底的に合理化！」として，同システムには国内旅程表作成機能がある旨の記載があるが，同システムの具体的な内容については何ら記載されておらず，その詳細は明らかではない。〔乙３５の４〕
株式会社エイブルズシステムの「Ｍｒ．トラベルくんシリーズ旅の助」についてのホームページには，「旅行業，観光バス業，観光関連事業者向けの旅行行程表，見積書作成，顧客管理，営業管理が出来る旅行業務支援システムです。」との記載があるが，それ以上のシステムの詳細については何ら明らかではない。〔乙３５の５〕
株式会社ウィ・キャンの旅行業基幹業務システムとして「シンフォニーアトゥー」を紹介するホームページには，「それぞれの部署の方，またそれぞれの機能が同時進行し，壮大な交響曲・・・を奏でるように旅行業が遂行されるシステムであるという願いを込めています。」等の記載はあるが，具体的なシステムの詳細については不明である。〔乙３５の６〕また，被告Ｙ５も，ＪＴＢのシステムである「ｅＺＲＯＵＴＥ」，農協観光のシステム等を使ったことはないとし，これらシステムの具体的な構成や規模等の詳細については明らかにすることができない。〔被告Ｙ５尋問調書
２１～２２頁〕
以上によれば，原告ＣＤＤＢが同種データベースの存在によりありふれたものであると認めるべき証拠はない。


したがって，被告らの上記主張は採用することができない。(ｵ)被告らは，自動車道路の経路探索上，当該施設の自動車出入口から最も近い道路地点（代表道路地点）を定めておくことは必要不可欠であり，これは自動車ルートの検索システムである「ＮＡＶＩＴＩＭＥ」や，一般的なカーナビゲーションシステム等でも同様であるから，原告ＣＤＤＢに特徴的な部分とはいえないとして創作性がない旨主張し，それに沿う証拠として，乙２９を提出する。
そこで，乙２９について検討すると，まず，乙２９の別紙１は「ＮＡＶＩＴＩＭＥ」の自動車ルート検索，同別紙２は「ＭａｐＦａｎ    Ｗｅｂ」のルート検索，同別紙３は「カーナビゲーション（パナソニックストラーダＣＮ－ＤＶ２５０Ｄ）」のルート検索画面である。乙２９別紙１の各地図上に示された目的地点である「Ｇ」は，いずれも施設（東京ディズニーランド）内の目的地点であって，道路上の道路地点ではないし，代表道路地点でもない。すなわち，乙２９別紙１の２枚目（上の地図），３枚目（上下の各地図）及び４枚目（上下の各地図）の各地図の「Ｇ」は，いずれも目的地内の地点であり，道路上の地点とはいえない。これによれば，同システムでは，目的地となる施設内の地点（上記では，東京ディズニーランドの駐車場内に入り込んだ地点「Ｇ」）に直近となる道路地点を求め，その道路地点を前提に経路検索を行っているものと認められるから，目的地となる施設自体の緯度経度情報に基づき直近の道路地点を求めているものといえる。また，乙２９別紙２の「ＭａｐＦａｎ    Ｗｅｂ」の事例についても，３枚目の上の地図の「５」近くのルート到着地点は東京ディズニーランドの駐車場内の地点，同５枚目の地図の「Ｇ」は遊園地内の地点で，いずれも施設内の地点であって，道路上の地点ではない。これら施設内に設定された目的地点に対して，道路について経路検索を行う場合は，これらの地点（施設内の位置情報）に直近の道路地点を前提に経路検索が行われているものといえる。同システムにおいても，上記「ＮＡＶＩＴＩＭＥ」のシステムの場合と同様に，施設情報のテーブルに代表道路地点を固定的に保有しているものではないということができる。
さらに，乙２９別紙３の「カーナビゲーションシステム（パナソニックストラーダ）」についても，上記「ＮＡＶＩＴＩＭＥ」や「ＭａｐＦａｎＷｅｂ」の各システムの場合と同様に，地図上に施設自体の位置を示すときの緯度経度情報と，経路検索時の目的地点の緯度経度情報が複数存在することを示すものであり，これらはいずれも道路上の緯度経度情報ではないから，施設情報として代表道路地点の情報を持つものを示しているとはいえない。そうすると，これらはいずれも，原告ＣＤＤＢのように，施設関係のテーブルに，予め代表道路地点を設けておくことを示すものではなく，施設情報として検索方法に応じて施設内に目的地点を複数持つものにすぎないというほかない。
したがって，被告らの上記主張は採用することができない。(ｶ)被告らは，ダイクストラ法を前提として，選択不可とすべき接続経路情報の設定を行うことは，旅行業者向けデータベースとしてありふれたものであると主張し，それに沿う証拠として乙３０を提出する。しかし，乙３０の別紙１の１枚目には「◆リンクの使用可否情報を考慮可能－動的考慮」として「『・・・工事中により一時的に通行止めにしたい』などがあります。・・・動的にリンクの使用不可を設定することで実現可能です。」と記載されており，事前に選択不可のリンク（経路）をテーブルとして保有するものでないことは明らかである。
また，乙３０の別紙１の２枚目では「◆道路の一方通行などの進行方向制約を考慮可能」として，「一方通行でない道路」については双方向のリンク（経路）を作成し，「一方通行の道路」については走行可能な方向のリンク（経路）のみを作成すると記載されており，選択可能なリンク（経路）のみを作成している例であることが明らかで，選択不可の接続道路情報テーブルを設けることを示しているものとはいえない。
さらに，乙３０の別紙２の特許公報（特許第２６４１４７０号，発明の名称「ナビゲーション装置」，特許権者アイシン・エィ・ダブリュ株式会社外１名）には，以下の記載がある。
・「そのために本発明は，出発地から目的地までの経路を探索して探索されたコースに基づき案内を行うナビゲーション装置において，始点から終点で表される道路単位で経路探索を行うための道路に関する情報からなる道路データを格納した記憶手段と，前記記憶手段に格納された道路データを用いて最適経路を探索する経路探索手段とを備え，前記道路データは，該道路データに接続する道路の進入禁止情報を有し，前記経路探索手段は，前記進入禁止情報により進入禁止である道路を除外して経路探索を行うことを特徴とするものである。
〔作用及び発明の効果〕
本発明のナビゲーション装置では，道路データに右左折禁止情報を設定するので，右左折禁止情報の記憶領域は少なくてよい。また，経路探索手段が経路を探索する際には右左折禁止情報の設定された道路を探索コースから除外するので，無駄な探索処理がなくなり，処理の高速化を図ることができる。
〔実施例〕
以下，図面を参照しつつ実施例を説明する。
・・・道路のネットワークデータは，道路のネットワークが例えば第２図（ａ）に示すような交差点番号・・・，道路番号・・・からなるものとした場合，交差点データについては同図（ｂ），道路データについては同図（ｃ），ノードデータについては同図（ｄ）に示すようなデータ構成となっている。
すなわち，交差点データは，同図（ｂ）に示すように交差点番号・・・に対応して交差点名，当該交差点が始点となっている道路のうち一番番号の小さい道路番号，当該交差点が始点となっている道路のうち一番番号の小さい道路番号，信号の有無からなる。
また，道路データは，同図（ｃ）に示すように道路番号・・・に対応して交差点番号による始点，終点，同じ始点を持つ道路のうち番号が次のもの，同じ終点を持つ道路のうち番号が次のもの，道路の太さ，禁止情報，案内不要情報，写真番号，ノード数，ノード列データの先頭アドレス，長さ等からなる。


そして，ノードデータは，同図（ｄ）に示すように東経，北緯，属性等からなり，道路データから明らかなように道路番号の単位は複数個のノードからなる。すなわち，ノードデータは道路上の１地点に関するデータであり，ノード間を接続するものをアークと呼ぶと，複数のノード列のそれぞれの間をアークで接続することによって道路が表現される。例えば道路番号に関して見ると，道路データよりノード数15からなりノードデータの先頭アドレスが100であることから，道路番号は，100   から114までのアドレスのノードデータで構成されることになる。これらのネットワークデータによると，・・・このように特に道路データでは，右左折禁止等の進入禁止の道路番号と案内不要の道路番号をもっていることにより，情報記憶の容量を少なくし，また経路探索を容易に行えるようにしている。」（２頁３欄３１行～３頁５欄１９行）上記記載は，隣接する道路地点間の道路間の道路を一単位とした道路に関するデータである道路データを格納するテーブルである，原告ＣＤＤＢであれば「１１接続テーブル」，被告ＣＤＤＢ（当初版・２００６年版）であれば「３７接続マスタ」（なお，被告ＣＤＤＢ（現行版），被告ＣＤＤＢ（新版）の「３７単経路マスタ」についても同様である。）のテーブル自体に右左折禁止の情報を格納する例を示すものであり，禁止されている道路間の接続情報のテーブルを別途設けるものが示されているわけではない。したがって，被告らの上記主張は採用することができない。(ｷ)被告らは，路線の特定に交通会社の特定も重要であるから交通会社の情報を格納するのは当然のことであると主張する。
しかし，交通会社を条件設定して検索する例については，証拠上見当たらず（甲５０），経路検索において必要となる情報につき交通会社テーブルを設けることが当然のことであるということはできない。したがって，被告らの上記主張は採用することができない。
カ依拠性について
次に，被告ＣＤＤＢ（当初版・２００６年版）が原告ＣＤＤＢに依拠して制作されたものであるかにつき判断する。
(ｱ)依拠性に関連する事実
被告らは，被告ＣＤＤＢ（当初版・２００６年版）につき，前記記載の複数のテーブルについて，データを原告ＣＤＤＢからコピーして利用した事実を認めているところ，その他にも，以下の事実が存する。
aテーブル，フィールドの各ＩＤについて
原告ＣＤＤＢと，被告ＣＤＤＢ（当初版・２００６年版）との対応するテーブルとフィールドについて，テーブルＩＤ，フィールドＩＤの一致する例については既に検討したとおりであるが，完全に一致するものでなくても，被告ＣＤＤＢ（当初版・２００６年版）では，テーブルＩＤの頭３文字を「ＡＺＭ」にするなどし，それら以外はテーブルＩＤ，フィールドＩＤが完全に一致している例が多数みられる。その詳細は，別紙３のとおりであり，これらのうち，原告ＣＤＤＢと一致するテーブルＩＤ，フィールドＩＤについては，原告ＣＤＤＢのデータをコピーしたことによるものと認められる。〔甲９，２３，５５〕
この点に関してＡは，その証言において，原告ＣＤＤＢと被告ＣＤＤＢとのフィールドＩＤ，テーブルＩＤの一致につき，フィールドＩＤの一致については認めるものの，テーブルＩＤについては「ＴＲＶ」と「ＡＺＭ」の部分のみが異なるものがあるが，その余はすべて一致する理由について，１０年近くプログラム作業に従事していたことから，全て頭の中に入っており，開発効率を上げるために命名したとし（証人Ａ１３頁），その一方で，Ａは，原告システムのプログラムの入力には一切関与しておらず，全て旧原告会社（翼システム）の方針に従って入力を指示しただけであるとも証言するが（証人Ａ６頁），これらの証言部分は，Ａが原告システムの開発経過において，プログラマーとして参加して被告Ｙ５の下でサブリーダーとなり，その後被告Ｙ５の転出後に原告システムの開発，改良における責任者となったとの事実経過に反する上に，内容的にも不合理であり，信用することができない。
b緯度経度情報について
原告ＣＤＤＢでは，バージョンアップ時に，新バージョンであるVer5に移行しない顧客のために，「０１市区町村テーブル」，「０９地点名テーブル」，「２０ホテル・旅館テーブル」，「２１観光施設テーブル」，「３２駅テーブル」と，緯度経度テーブルとで緯度経度情報を重複保有していることについては既に検討したとおりであるところ，被告ＣＤＤＢ（当初版・２００６年版）は，本来必要のない緯度経度情報を複数テーブルで重複保有している。
なお，被告らは，これにつき，被告ＣＤＤＢ（新版）から緯度経度マスタ自体を削除している。
cＵＲＬアドレステーブルについて
原告ＣＤＤＢではタイトルに用いるカタカナについて全角（例として，「青森県［観光コンベンション協会ＨＰ］」と半角（例として，その次の優先順位となっている，「青森県［観光情報ﾈｯﾄﾜｰｸＨＰ］」）が不規則に混用されている例が見られるところ，被告ＣＤＤＢ（当初版・２００６年版）の全角半角の混用使用箇所が，原告ＣＤＤＢと完全に一致する例がある。〔甲２８の別紙４〕
d地点名テーブルについて
(a)原告ＣＤＤＢの誤りである地点名の表記「阿武隅ＰＡ」（正しくは「阿武隈」）と同じ誤りが，被告ＣＤＤＢ（当初版・２００６年版）に存在する。ちなみに，別紙４の被告ＣＤＤＢ（当初版・２００６年版）の「３５地点マスタ」の被告らの主張欄記載のとおり，被告らは，原告ＣＤＤＢをコピーして入力した上で追加・修正・削除した旨主張するところであるが，ＮＥＸＣＯ東日本のホームページには正しい表記がされている。〔甲２１〕