令和８年５月２７日判決言渡同日原本領収裁判所書記官
令和２年（ワ）第３２９８９号不正競争行為差止等請求事件
口頭弁論終結日令和８年１月２７日
判決
原
告株式会社シンクパワー
同訴訟代理人弁護士田中豊
北村亮典
鎌形尚
被
告株式会社ソケッツ
同訴訟代理人弁護士早稲田祐美子
木下駿
主文
１ 本件訴えのうち、別紙１同期歌詞データ目録記載の同期歌詞データを第三者に開示し又は自ら使用することの差止めを求める部分及び同データの消去を求める部分をいずれも却下する。
２ 原告のその余の請求をいずれも棄却する。
３ 訴訟費用は原告の負担とする。
事実及び理由
第１ 請求
１ 被告は、別紙１同期歌詞データ目録記載の同期歌詞データを第三者に開示し又は自ら使用してはならない。
２ 被告は、前項の同期歌詞データを消去せよ。
３ 被告は、別紙２プログラム目録１記載のプログラムを第三者に開示し又は自ら使用してはならない。
４ 被告は、別紙３プログラム目録２記載のプログラムを消去せよ。
５ 被告は、第３項のプログラムを複製、翻案してはならない。
６ 被告は、第４項のプログラムを消去せよ。
７ 被告は、原告に対し、３億６０００万円及びうち１億円に対する令和２年１２月１日から支払済みまで、うち２億６０００万円に対する令和７年４月１日から支払済みまで年３パーセントの割合による金員を支払え。
８ 被告は、原告に対し、３億６０００万円及びうち１億円に対する令和２年１２月１日から支払済みまで、うち２億６０００万円に対する令和７年４月１日から支払済みまで年３パーセントの割合による金員を支払え。
第２ 事案の概要
本件は、原告が被告に対し、⑴被告が、限定提供データである原告の同期歌詞データを不正に取得、使用及び開示したとして、これが不正競争防止法（以下「不競法」という。）２条１項１１号所定の不正競争に当たると主張して、①不競法３条１項及び２項に基づく別紙１同期歌詞データ目録記載の楽曲の同期歌詞データ（以下「本件差止対象データ」という。）の使用及び開示の差止め並びに消去（請求の趣旨１項、２項）、②不競法４条に基づく損害賠償金３億６０００万円（侵害期間は平成３０年４月１日から令和７年３月３１日まで）及び遅延損害金の支払（請求の趣旨７項）を、⑵被告が、原告の営業秘密であり、著作物である別紙２プログラム目録１記載のプログラム（以下、併せて「本件ＳＤＫ」という。）について、①使用及び開示したとして、これが不競法２条１項７号所定の不正競争に当たると主張して、不競法３条１項及び２項に基づく本件ＳＤＫの使用及び開示の差止め並びに別紙３プログラム目録２記載のプログラム（以下「ソケッツＳＤＫ」という。）の消去（請求の趣旨３項、４項）、②複製又は翻案したとして、著作権法１１２条１項及び２項に基づく本件ＳＤＫの複製、翻案の差止め及びソケッツＳＤＫの消去（請求の趣旨５項、６項）、③不競法４条又は著作権侵害の不法行為に基づく損害賠償金３億６０００万円（侵害期間は上記⑴と同じ）及び遅延損害金の支払（請求の趣旨８項）を求める事案である。
１ 前提事実（当事者間に争いがないか、後掲各証拠及び弁論の全趣旨により容易に認められる事実。以下、枝番号のある証拠について枝番号を記載しない場合は、全ての枝番号を含む。）
⑴当事者等
ア 原告は、ソフトウェアの企画、設計、開発、保守及び販売並びに請負、インターネットなどの通信回線を利用した各種情報の収集、処理、分析、サービス提供及び販売等を目的とする株式会社であって、同期歌詞データ（スマートフォン等で楽曲を再生するときに、画面上で当該楽曲の歌詞を当該楽曲の進行に併せて色を変えながら表示する機能（以下「同期歌詞表示機能」という。）を実現するためのデータ）を作成し、音楽配信事業者に対して同期歌詞データを提供する事業を行っている。（甲２）
イ 被告は、音楽、映像のデータの配信等を業とする株式会社であって、同期歌詞データを作成し、音楽配信事業者に対して同期歌詞データを提供する事業を行っている。（甲２、３）
ウ 株式会社レコチョク（以下「レコチョク」という。）は、音楽配信サービスの企画及び運営等を業とする株式会社であって、音楽配信サービスに関する事業を行っている。
⑵レコチョクの音楽配信サービスと同期歌詞表示機能
レコチョクとの間で音楽配信契約を締結したユーザーは、レコチョクの提供する音楽再生アプリケーション（以下「本件アプリ」という。）をスマートフォン等にインストールし（以下、本件アプリをインストールしたユーザーのスマートフォン等を「ユーザー端末」という。）、本件アプリで楽曲を再生すると、ユーザー端末が当該楽曲に対応する同期歌詞データをサーバーから受信し、同期歌詞表示機能を使用することができる。（甲２）⑶原告によるレコチョクに対する本件ＳＤＫ及び同期歌詞データの提供
ア 原告の従業員は、原告の発意に基づいて、本件ＳＤＫを職務上作成したものであり、その作成時における原告の就業規則等には、その著作者について別段の定めはなかった。原告は、平成２５年３月から平成２７年１２月にかけて、レコチョクに対し、本件ＳＤＫを順次納品した。（甲１２ないし１６、４８、７３）
イ レコチョクは、被告にレコチョクの基幹システムの開発を委託し、同システムに連携した形で原告から同期歌詞データの提供を受けることを検討していたことから、原告は、平成２５年７月１３日、被告に対し、本件ＳＤＫ（別紙２プログラム目録記載２のもの）に係る仕様書を交付した。（甲１８）
ウ レコチョクは、平成２５年１２月１８日頃、原告との間で、データ提供契約を締結し（以下「本件データ提供契約」という。）、本件ＳＤＫを組み込んだ本件アプリ及び原告が作成した同期歌詞データを利用した音楽配信サービスの提供を開始した。（甲４ないし１０）
エ 本件データ提供契約は、レコチョクが、平成２９年３月、原告から同期歌詞データの提供を受ける必要はなくなったとの理由で本件データ提供契約の終了を申し出たことから、平成３０年３月３１日をもって終了した。⑷被告によるレコチョクに対するソケッツＳＤＫ及び同期歌詞データの提供
ア 被告は、ソケッツＳＤＫを作成し、平成２９年１２月頃、レコチョクに対してソケッツＳＤＫを納品した。
イ レコチョクは、遅くとも平成２９年１２月頃から令和７年３月３１日まで、ソケッツＳＤＫを組み込んだ本件アプリ及びソケッツから提供された同期歌詞データ（以下「ソケッツ同期歌詞データ」という。）を利用して音楽配信サービスを提供した。
ウ 被告は、ソケッツ同期歌詞データを、「ｈｔｔｐｓ：／／以下省略」の参照先として指定されているデータベース（以下「本件データベース」という。）に格納してレコチョクに提供した。
⑸本件訴訟の経過
原告は、令和２年１２月２５日、被告及びレコチョクに対し、同期歌詞データの使用の差止め、ソケッツＳＤＫの使用の差止め及び損害賠償等を求めて本件訴訟を提起した。
その後、原告とレコチョクの間では、本件弁論準備手続期日において、訴訟上の和解が成立した。（甲７２）
２ 争点
⑴本案前の争点
本件差止対象データに係る差止め等の訴えの特定の有無（争点１）⑵本案の争点
（限定提供データに係る不正競争）
ア 被告が同期歌詞データを不正の手段により取得し、使用又は開示したか（争点２）
イ 同期歌詞データが限定提供データに該当するか（争点３）
（本件ＳＤＫに係る著作権侵害）
ウ ソケッツＳＤＫが本件ＳＤＫを複製又は翻案したものであるか（争点４）（本件ＳＤＫに係る不正競争）
エ 本件ＳＤＫが営業秘密に該当するか（争点５）
オ 被告が営業上の利益を図り又は原告に損害を加える目的で本件ＳＤＫを使用又は開示したか（争点６）
（共通）
カ 差止めの必要性（争点７）
キ 損害の発生及びその額（争点８）
３ 争点に関する当事者の主張
⑴争点１（本件差止対象データに係る差止め等の訴えの特定の有無）について
（原告の主張）
別紙１同期歌詞データ目録のとおり、本件差止対象データは、曲名、アーティスト名及びアルバム名により特定される楽曲演奏に係る同期歌詞データと特定されており、一つの楽曲演奏について複数の同期歌詞データを保有することはないから、本件差止対象データに係る差止め等の訴えの特定に欠けるところはない。
（被告の主張）
本件差止対象データは、曲名、アーティスト名及びアルバム名により楽曲を特定するものであるが、同じ楽曲に係る同期歌詞データであっても、異なる同期パターンのもの等複数存在し、どの同期歌詞データか明らかでないから、差止め等の対象の特定を欠く。
⑵争点２（被告が同期歌詞データを不正の手段により取得し、使用又は開示したか）について
（原告の主張）
ア 被告は、原告が保有していた同期歌詞データを不正の手段により取得した。被告が取得した同期歌詞データは、平成３０年１月９日時点で原告が保有していた別紙１同期歌詞データ目録記載の楽曲演奏に係る同期歌詞データと特定する（以下「本件同期歌詞データ」という。）。すなわち、原告が、同日、レコチョクの役員に対し、原告の同期歌詞データをレコチョクが流用している旨の警告をしたことからすれば、被告は、それまでの間、原告の同期歌詞データを不正の手段により取得していたことが推認され、被告が不正の手段により取得した原告の同期歌詞データは、同日時点で原告が保有していた同期歌詞データ（本件同期歌詞データ）である。その後、被告は、平成２９年１２月頃から令和７年３月まで、不正取得行為により取得した本件同期歌詞データを、ソケッツ同期歌詞データとして、①レコチョクに提供し、又は②レコチョクと音楽配信契約を締結したユーザーの求めに応じて配信して、使用又は開示した。
イ このことは、被告が不正取得の痕跡を残さずに本件同期歌詞データを取得することは技術的に可能であること（プロキシによるライセンスコードの取得）、本件同期歌詞データに基づく歌詞の表示と被告がレコチョクに提供していたソケッツ同期歌詞データに基づく歌詞の表示に不自然な一致（誤記の一致、正規の歌詞カードと異なる原告独自のルールに基づく表記及び改行箇所の一致、原告がレコード会社から独自に提供を受けたアーティストメッセージの一致、間奏等を示す表記の一致等）があることによって裏付けられている。
ソケッツ同期歌詞データが「ソケッツ同期歌詞自動生成システム」によって生成されたことは否認する。また、不一致部分は被告が故意に作り出したものであり、被告が本件同期歌詞データを不正取得したことと矛盾しない。
ウ 後記⑶（原告の主張）のとおり、本件同期歌詞データは限定提供データ（不競法２条７項）に該当するから、前記ア、イの被告の行為は不競法２条１項１１号所定の不正競争に該当する。
（被告の主張）
ア 被告が本件同期歌詞データを取得したことは否認する。ソケッツ同期歌詞データは、被告が「ソケッツ同期歌詞自動生成システム」によって生成したものである。原告が主張する誤記等の一致は、上記システムのクローニング等により混入したものと説明することができる。かえって、本件同期歌詞データとソケッツ同期歌詞データは、時間指定データが完全には一致しておらず、歌詞テキストにも不一致部分が存在するほか、全部が行同期であるか文字同期部分が含まれるかの点等でも異なっている。
イ 被告が本件同期歌詞データをレコチョクに提供したことは否認する。被告は、自ら生成したソケッツ同期歌詞データをレコチョクに提供していた。また、被告は、レコチョクと音楽配信契約を締結したユーザーに同期歌詞データを配信していない。
ウ したがって、被告の行為は不競法２条１項１１号所定の不正競争に該当しない。もとより、同号は平成３０年５月３０日法律３３号の施行日である令和元年７月１日より前に行われた不正競争に適用はなく、被告が同日以後に不正競争を行ったことも立証されていない。
⑶争点３（原告の同期歌詞データが限定提供データに該当するか）について（原告の主張）
原告は、利用許諾契約を締結した音楽配信事業者に対してＩＤ及びパスワードの機能を有するライセンスコードを発行し、当該音楽配信事業者と音楽配信契約を締結したユーザーからの指示に従って、原告のサーバーから当該ユーザーに対して本件同期歌詞データを配信していた。また、平成３０年時点で原告がサーバーに保有していた同期歌詞データは６１万３４７２曲分である。
したがって、本件同期歌詞データは、業として特定の者に提供する情報として電磁的方法により相当量蓄積され、管理されている技術上の情報であり、営業秘密に該当するものではないから、限定提供データ（不競法２条７項）に該当する。
（被告の主張）
不知。限定提供データに該当することは争う。
⑷争点４（ソケッツＳＤＫが本件ＳＤＫを複製又は翻案したものであるか）について
（原告の主張）
ア 被告は、平成２９年７月２５日から令和４年６月３日までの間に本件ＳＤＫに依拠してソケッツＳＤＫを制作した。このことは、後記イのほか、ソケッツＳＤＫと本件ＳＤＫとで、特徴的なクラス名が酷似していることからもいえる。
イ ソケッツＳＤＫは、別紙４－２ソケッツＳＤＫクラス一覧表（以下、別紙４以下については、別紙の番号のみで特定する。）記載のクラスＮｏ４のＡｐｐＩｎｆｏ（以下「ＡｐｐＩｎｆｏ」という。）及びクラスＮｏ３のＡｂｓｔｒａｃｔＸｍｌＰａｒｓｅｒ（以下「ＸｍｌＰａｒｓｅｒ」という。）と本件ＳＤＫの別紙４－１記載のクラスＮｏ１のＳｐＡｐｐＩｎｆｏ（以下「ＳｐＡｐｐＩｎｆｏ」という。）及び同クラスＮｏ５６のＳｐＸｍｌＰａｒｓｅｒ（以下「ＳｐＸｍｌＰａｒｓｅｒ」という。）を対比すると、以下のとおり、基本的な仕組みや処理手順、ソースコードの表現について同一性を有しており、ソケッツＳＤＫが本件ＳＤＫの表現上の本質的な特徴の同一性を維持し、その結果、ソケッツＳＤＫに接する者がプログラムの著作物（著作権法１０条１項９号）である本件ＳＤＫの表現上の本質的特徴を直接感得することができるから、ソケッツＳＤＫは、本件ＳＤＫを複製又は翻案したものということができる。
(ｱ) ＡｐｐＩｎｆｏとＳｐＡｐｐＩｎｆｏの対比
ａ ＡｐｐＩｎｆｏとＳｐＡｐｐＩｎｆｏは、いずれもＷｅｂＡＰＩとの通信に必要な情報を提供するクラスであり、８個の情報にそれぞれ別個のインスタンス変数を用意し、インスタンス変数に対応するｇｅｔメソッドを介して情報提供するというプログラムの基本的な仕組みや各インスタンス変数を初期化する手順が同一である。
ｂ 別紙５－１のとおり、ＡｐｐＩｎｆｏとＳｐＡｐｐＩｎｆｏは、ソースコードの表現に同一性を有する部分が極めて多い（以下、同別紙で着色している行を「本件対象部分１」という。なお、着色していない行はプログラムの表現ではないか、創作性がないことが明らかな部分等である。）。同別紙のＡｐｐＩｎｆｏのソースコードは、被告がレコチョクに納品した平成２９年８月９日以前のものを復元したものであり、同別紙のＳｐＡｐｐＩｎｆｏのソースコードは、対比のために行を並べ替えたものである。被告は、本件訴訟提起時のＡｐｐＩｎｆｏのソースコードは乙Ｂ４１の３であると主張するが、これは被告がレコチョクに納品したものではない。また、プログラミング言語Ｊａｖａ（以下「Ｊａｖａ言語」という。）によって記述されたソースコードにおけるインスタンス変数が宣言される順番やメソッドが定義される順番はコンピューターへの指令ではない。
ｃ そして、別紙５－３の「原告の主張」欄のとおり、Ｎｏ１ないし６の同一性を有する部分（以下、同表のＮｏに応じて「ポイント１」などという。）に創作性が認められるから、ＡｐｐＩｎｆｏからＳｐＡｐｐＩｎｆｏの表現上の本質的特徴を直接感得することができる。ポイント７ないし１２はＳｐＡｐｐＩｎｆｏの表現上の本質的特徴を直接感得することを妨げるものではない。
(ｲ) ＸｍｌＰａｒｓｅｒとＳｐＸｍｌＰａｒｓｅｒの対比
ａ ＸｍｌＰａｒｓｅｒとＳｐＸｍｌＰａｒｓｅｒは、いずれも簡易なタグ構造で記述されたＸＭＬデータの解析に共通する処理を定めたクラスであり、４個の異なるインスタンスメソッドが連携してＸＭＬデータの解析を行う構成を有し、ＸＭＬデータを解析中にエラーが発生した場合、固有の例外クラスに変換して通知（スロー）するというプログラムの基本的な仕組みや処理手順が同一である。
ｂ 別紙６－１のとおり、ＸｍｌＰａｒｓｅｒとＳｐＸｍｌＰａｒｓｅｒは、ソースコードの表現に同一性を有する部分が極めて多い（以下、同別紙で着色している行を「本件対象部分２」という。なお、着色していない行はプログラムの表現ではないか、創作性がないことが明らかな部分である。）。同別紙のＸｍｌＰａｒｓｅｒのソースコードは、被告がレコチョクに納品した平成２９年８月９日以前のものを復元したものであり、同別紙のＳｐＸｍｌＰａｒｓｅｒのソースコードは、対比のために行を並べ替えたものである。被告が本件訴訟提起時のＸｍｌＰａｒｓｅｒのソースコードであるとする乙Ｂ４１の２がレコチョクに納品されたものでないこと、インスタンス変数やメソッドが定義される順番に関する情報がコンピューターへの指令でないことは前記ア(ｲ)と同様である。
ｃ そして、別紙６－３の「原告の主張」欄のとおり、Ｎｏ１ないし７の同一性を有する部分（以下、同表のＮｏに応じて「ポイント⑴」などという。）に創作性が認められるから、ＸｍｌＰａｒｓｅｒからＳｐＸｍｌＰａｒｓｅｒの表現上の本質的特徴を直接感得することができる。ポイント⑻ないし⑽はＳｐＸｍｌＰａｒｓｅｒの表現上の本質的特徴を直接感得することを妨げるものではない。
（被告の主張）
ア 被告が、本件ＳＤＫに依拠してソケッツＳＤＫを制作したことは否認し、本件ＳＤＫがプログラム著作物に当たることは争う。
イ ソケッツＳＤＫについては、以下のとおり、本件ＳＤＫの表現上の本質的な特徴の同一性を維持し、ソケッツＳＤＫに接する者が本件ＳＤＫの表現上の本質的特徴を直接感得することができるということはできない。(ｱ) ＡｐｐＩｎｆｏとＳｐＡｐｐＩｎｆｏの対比
ａ プログラムの基本的な仕組みや処理手順はアイデアにすぎず、表現として保護されるものではない。そもそも、原告が主張するｇｅｔメソッドによる情報提供はありふれた手法である上、ＡｐｐＩｎｆｏとＳｐＡｐｐＩｎｆｏは取り扱う情報が異なっているなど、有意な差がある。
ｂ 原告は、ＡｐｐＩｎｆｏのソースコードを復元し、独自に行を並び替えてＳｐＡｐｐＩｎｆｏと対比しているが、本訴訟提起時のＡｐｐＩｎｆｏのソースコードは乙Ｂ４１の３であり、また、インスタンス変数が宣言される順番やメソッドが定義される順番もプログラムの表現に含まれるから、原告の対比は不適当である。ＡｐｐＩｎｆｏ（復元）とＳｐＡｐｐＩｎｆｏを対比しても、別紙５－２のとおり、対比の必要がある１５９行のうち、ありふれた表現である行が７０行、表現が同一でない行が８３行であり、また、ほとんどが創作的な表現といえない。
ｃ そして、別紙５－３の「被告の主張」欄のとおり、ポイント１ないし６はいずれもありふれた表現であり、ポイント７ないし１２のように表現が大きく異なる部分も存在する。
(ｲ) ＸｍｌＰａｒｓｅｒとＳｐＸｍｌＰａｒｓｅｒの対比
ａ 前記ア(ｱ)のとおり、プログラムの基本的な仕組みや処理手順は表現として保護されるものではない。また、原告が主張する処理手順はいずれもありふれた手法である。
ｂ 原告は、ＸｍｌＰａｒｓｅｒのソースコードを復元し、独自に行を並び替えてＳｐＸｍｌＰａｒｓｅｒと対比しているが、本訴訟提起時のＸｍｌＰａｒｓｅｒのソースコードが乙Ｂ４１の２であること等から原告の対比が不適法であることは前記ア(ｲ)と同様である。ＸｍｌＰａｒｓｅｒ（復元）とＳｐＸｍｌＰａｒｓｅｒを対比しても、別紙６－２のとおり、対比の必要がある８５行のうち、ありふれた表現である行が５１行、表現が同一でない行が３２行であり、また、ほとんどが創作的な表現といえない。
ｃ そして、別紙６－３の「被告の主張」欄のとおり、ポイント⑴ないし⑺はいずれもありふれた表現であり、ポイント⑻ないし⑽のように表現が大きく異なる部分も存在する。
⑸争点５（本件ＳＤＫが営業秘密に該当するか）について
（原告の主張）
本件ＳＤＫは、音楽配信事業者が効率的に同期歌詞データを配信することを目的として原告が開発したプログラムであり、原告の取締役以上の役職者及び秘密保持契約を締結した従業員しかアクセスできない社内ＮＡＳ内で管理されている。また、原告は、同期歌詞データの利用許諾契約又は秘密保持契約を締結した音楽配信事業者にしか本件ＳＤＫを開示しておらず、仕様書等に「Ｃｏｎｆｉｄｅｎｔｉａｌ」と表示している。
したがって、本件ＳＤＫは、秘密として管理されている事業活動に有用な技術上の情報であって、公然と知られていないものであるから、営業秘密（不競法２条６項）に該当する。
（被告の主張）
不知又は争う。
⑹争点６（被告が営業上の利益を図り又は原告に損害を加える目的で本件ＳＤＫを使用又は開示したか）について
（原告の主張）
原告から本件ＳＤＫの開示を受けた被告は、平成２９年７月２５日から令和４年６月３日までの間に、本件ＳＤＫを参照してソケッツＳＤＫを制作し、平成２９年１２月１２日以降、レコチョクに対してソケッツＳＤＫを納品したのであるから、営業上の利益を図り又は原告に損害を加える目的で、営業秘密である本件ＳＤＫを使用し、開示したものといえる。
したがって、被告の上記各行為は不競法２条１項７号所定の不正競争に該当する。
（被告の主張）
被告がソケッツＳＤＫを制作してレコチョクに納品したことは認め、その余は不知又は否認ないし争う。
⑺争点７（差止めの必要性）について
（原告の主張）
ア 本件差止対象データについて
被告は、レコチョクへの本件同期歌詞データの提供終了後も、他社に本件同期歌詞データを提供している。被告が新しい同期歌詞自動生成システムによって生成した同期歌詞データを提供しているとする証拠もない。したがって、被告は本件差止対象データを開示又は使用するおそれがあり、差止めの必要がある。
イ 本件ＳＤＫの開示又は使用について
被告は、ソケッツＳＤＫの提供を終了したものの、本件ＳＤＫを使用して一部を変更したソケッツＳＤＫを他社に提供することは技術的に可能であるから、本件ＳＤＫを開示又は使用するおそれがあり、差止めの必要性がある。
（被告の主張）
ア 本件差止対象データについて
被告は、令和７年３月３１日にレコチョクとの契約を解消してソケッツ同期歌詞データの提供を終了し、従前のソケッツ同期歌詞データは全て廃棄した。したがって、仮に差止めの対象が特定されていたとして、被告が、今後、不正に取得して開示又は使用した限定提供データとされるソケッツ同期歌詞データを開示又は使用するおそれはない。
イ 本件ＳＤＫの開示又は使用について
ソケッツＳＤＫは、レコチョクの音楽配信アプリ専用に作成したものであり、被告は、令和７年３月３１日にレコチョクとの契約を解消してソケッツＳＤＫの提供を終了した。したがって、被告が、今後、本件ＳＤＫを使用して一部を変更したとされるソケッツＳＤＫを開示又は使用するおそれはない。
⑻争点８（損害の発生及びその額）について
（原告の主張）
被告が、平成３０年４月１日から令和７年３月３１日までの間に、本件同期歌詞データに係る不正競争、本件ＳＤＫに係る不正競争及び著作権侵害によって受けた営業上の利益は、合計７億２０００万円を下らない。そして、本件同期歌詞データに係る不正競争によって原告に生じた不競法５条２項所定の損害額、本件ＳＤＫに係る不正競争又は本件ＳＤＫの複製若しくは翻案によって原告に生じた同項又は著作権法１１４条２項所定の損害額は各３億６０００万円を下らない。また、このうち、令和２年１２月１日までに生じた損害は各１億円を下らない。
（被告の主張）
争う。
第３ 当裁判所の判断
１ 争点１（本件差止対象データに係る差止め等の訴えの特定の有無）について⑴原告は、令和２年１２月２５日付け訴状において、差止め等の対象を「本件データベースに格納されている同期歌詞データ」としていたところ、被告から、データの特定を欠き、訴えを却下すべきであるという指摘、レコチョクから、本件データベースには本件データ提供契約終了後も日々新たに制作される楽曲に関するデータが膨大に格納されており、上記同期歌詞データの全ての差止め等を求める法的根拠は明らかでないという指摘を受け、令和４年９月１３日付け訴え変更申立書において、差止め等の対象を、本件データベースに格納されている同期歌詞データのうち、平成３０年１月９日時点で原告が保有していた同期歌詞データと同じ楽曲演奏に係る同期歌詞データに限定するとして、「本件データベースに格納されている別紙１同期歌詞データ目録記載の同期歌詞データ」に変更した（以下「特定後同期歌詞データ」という。）。その後、これを前提として請求原因の主張をし、これに基づいて審理が進められ、令和４年１２月１５日には、裁判所及び当事者との間で、不正競争を理由とする請求について、最終的に主張を整理した書面を提出することはあり得るが、今後、新しい主張立証をすることはない旨の確認がされた。原告は、令和７年８月５日付け訴えの変更申立書において、差止等の対象から、「本件データベースに格納されている」との限定を除く変更をし、被告から、本件差止対象データに係る同期歌詞データは異なる同期パターンのもの等が複数存在し、どの同期歌詞データか明らかでないから、特定を欠き、訴えを却下すべきであるという指摘を受けても、同請求を維持している。⑵原告は、請求原因として、被告が、原告の保有する本件同期歌詞データを不正に取得したこと、レコチョク又はレコチョクと音楽配信契約を締結したユーザーにソケッツ同期歌詞データを提供又は配信したこと、ソケッツ同期歌詞データは本件同期歌詞データであることを主張するところ、本件差止対象データは、ソケッツ同期歌詞データの格納先により特定された特定後同期歌詞データと異なり、データの所在（格納先）による限定がなく、楽曲演奏のみによって特定されている。そして、被告は、第三者に対して同期歌詞データを提供する事業を行っているのであるから（前提事実⑴イ）、本件差止対象データに、口頭弁論終結日までに被告が作成、保有するに至った原告が保有していたという本件同期歌詞データともソケッツ同期歌詞データとも無関係の同期歌詞データが含まれる可能性を払拭することはできない。この点について、原告は、本件差止対象データは、曲名、アーティスト名及びアルバム名により特定される楽曲演奏に係る同期歌詞データと特定されており、一つの楽曲演奏について複数の同期歌詞データを保有することはないから、本件差止対象データに係る差止め等の訴えの特定に欠けるところはないと主張するのみであり、前記⑴のとおりの審理経過や上記請求原因の主張等に照らして、本件における審判対象を的確に特定していないものといわざるを得ない。
⑶したがって、本件差止対象データの特定は不十分というべきであるから、本件訴えのうち、本件差止対象データを第三者に開示し又は自ら使用することの差止めを求める部分及び本件差止対象データの消去を求める部分は、いずれも訴えの特定を欠き、不適法である。
なお、仮に、本件差止対象データが、曲名、アーティスト名及びアルバム名により特定される楽曲演奏に係る同期歌詞データとして特定されるすべての同期歌詞データを含むものとして訴えの特定を欠くとまではいえないとしても、後記２のとおり、同期歌詞データに係る不正競争について不競法４条の適用が認められないのと同様に、同法３条の適用は認められないから、本件訴えのうちの上記部分に係る請求、すなわち、同期歌詞データに係る不正競争を理由とする同法３条に基づく損害賠償請求は理由がない。
２ 争点２（被告が同期歌詞データを不正の手段により取得し、使用又は開示したか）について
本件差止対象データに係る差止め等の訴えが特定を欠き不適法であることは前記１で説示したとおりであるが、不競法４条に基づく損害賠償請求との関係で、争点２について検討する。
⑴原告は、被告が、限定提供データを不正に取得し、使用又は開示したと主張する。
平成３０年５月３０日法律３３号による改正後の同法３条及び４条の規定は、同法律の施行日である令和元年７月１日より前に行われた同法２条１項１１号所定の不正取得行為に係る同号所定の不正競争については、施行日以後に行われる開示行為を除いて適用されない（平成３０年５月３０日法律３３号附則２条１項本文及び同項１号）。したがって、被告の行為について同法４条を適用するためには、時的要素として、①被告が令和元年７月１日以後に限定提供データの不正取得行為をしたか、②被告による不正取得行為が同日より前である場合には、同日以後に限定提供データの開示行為をしたことを要する。そこで、まず、上記時的要素の点について検討する。⑵本件同期歌詞データの取得について
原告は、被告が、レコチョクに対して同期歌詞データを提供するのに先立って、本件同期歌詞データを不正の手段により取得したことを主張するものの、その時期については具体的な特定をしていない。もっとも、原告は、不正取得行為の対象となった同期歌詞データの範囲を原告が平成３０年１月９日に保有していた楽曲として特定し、その根拠として、被告は、原告がレコチョクの役員に対し同期歌詞データに係る侵害警告をした同日までの間、原告の同期歌詞データを不正の手段により取得していたことが推認されることを挙げる。このような原告の主張を前提とすると、被告が不正の手段により本件同期歌詞データを取得したのは同日までというのであるから、被告による取得行為は、令和元年６月３０日以前であることになる。
また、被告が、令和元年７月１日以後に本件同期歌詞データを取得したことを認めるに足りる証拠はない。
このように、被告が、令和元年７月１日以後に本件同期歌詞データを取得したことの主張立証はないから、前記⑴の①の構成による不競法４条の適用は認められない。
⑶本件同期歌詞データの開示について
ア 原告は、被告が、平成２９年１２月頃から令和７年３月まで、本件同期歌詞データをソケッツ同期歌詞データとして、レコチョクに提供し、又はレコチョクと音楽配信契約を締結したユーザーの求めに応じて配信したと主張する。
イ このうち、被告が本件同期歌詞データをレコチョクに提供したとの主張について、被告は、被告がソケッツ同期歌詞データをレコチョクに提供したという限度で認めている。前記⑵のとおり、原告の主張は、被告が、本件同期歌詞データを平成３０年１月９日までに取得したことを前提に、これをソケッツ同期歌詞データとして、レコチョクに提供したとするものであると解されるところ、被告が、本件同期歌詞データを取得したとされる同日から約１年半が経過した令和元年７月１日まで、ソケッツ同期歌詞データをレコチョクに提供していなかったとは考え難い。加えて、レコチョクは、平成２９年１２月頃に同期歌詞データの提供元を原告から被告に切り替え、その前後を通じてユーザーに音楽配信サービスを提供していたのであるから（前記前提事実⑶及び⑷）、この意味からも、被告が、令和元年７月１日まで別紙１同期歌詞データ目録記載の膨大な数の楽曲に係る同期歌詞データをレコチョクに提供していなかったとは考え難い。また、被告が、ソケッツ同期歌詞データを同日以後にレコチョクに提供したことを認めるに足りる証拠もない。
ウ 次に、被告がレコチョクと音楽配信契約を締結したユーザーの求めに応じて、ソケッツ同期歌詞データとして本件同期歌詞データの配信を行ったとの主張について、被告は事実を否認している。楽曲を再生するユーザーに対して、当該楽曲に係る同期歌詞データを配信する行為は限定提供データの「使用」には当たり得ても、「開示」には当たらないと考えられるが、この点を措くとしても、レコチョクではなく被告がレコチョクのユーザーに対する配信を行ったことを認めるに足りる的確な証拠はないから、原告の主張する事実を認めることはできない。
エ このように、被告が、令和元年７月１日以後にソケッツ同期歌詞データを開示したことの立証はないから、ソケッツ同期歌詞データが本件同期歌詞データであるかに関わらず、前記⑴の②の構成による不競法４条の適用は認められない。
⑷したがって、その余の点を判断するまでもなく、同期歌詞データに係る不正競争を理由とする不競法４条に基づく損害賠償請求は理由がない。
３ 争点４（ソケッツＳＤＫが本件ＳＤＫを複製又は翻案したものであるか）について
⑴認定事実
前記前提事実、証拠（後掲各証拠のほか、甲４１ないし４７、５５、５６、５８ないし６０、６８、７０、７１、７４、乙Ｂ３４、３５、３９ないし４３（ただし、いずれも後記認定に反する部分を除く。））及び弁論の全趣旨によれば、以下の事実が認められる。
ア 本件ＳＤＫ及びソケッツＳＤＫの目的及び機能
本件ＳＤＫ及びソケッツＳＤＫは、いずれもＡｎｄｒｏｉｄ端末向けの本件アプリに組み込まれ、本件アプリに、同期歌詞表示機能を付加するためのプログラムであり、ＷｅｂＡＰＩ（データベースの中から必要な同期歌詞データを取得する機能を有するサーバー上のプログラム）を介して必要な同期歌詞データに係る情報をサーバーにリクエストし、サーバーからのレスポンスであるＸＭＬデータを解析し、解析結果をユーザー端末の画面に表示する機能を有する。ソースコードはいずれもＪａｖａ言語で記述されている。
イ 本件ＳＤＫの構造等
(ｱ) クラス構成
本件ＳＤＫは、別紙４－１記載のとおり、５６個のクラス（特定の対象や役割を持つ、データやそれに関連する処理をまとめたソースコードの集合）によって構成されており、これらが連携して前記アの機能を実現する。
(ｲ) ＳｐＡｐｐＩｎｆｏの構造等
ＳｐＡｐｐＩｎｆｏは、サーバーのＷｅｂＡＰＩとの通信に必要な情報を提供するクラスであり、本件ＳＤＫに対して、①ＷｅｂＡＰＩのライセンスコード、②ＷｅｂＡＰＩのテスト利用、③ユーザーのＩＤ、④ユーザーの通信キャリア、⑤アプリのパッケージ名、⑥アプリの名前、⑦アプリのバージョン名及び⑧アプリのバージョン番号の情報（以下「情報①」などという。）を提供する機能を有する。
本件対象部分１におけるソースコードの内容は、概要、(ⅰ)情報①ないし⑧に対応するインスタンス変数（クラスの中で定義され、クラスのどこでも使用することができ、クラスのオブジェクトが作成されるときに初期化される変数）として、別紙５－３「Ｎｏ１」「内容」欄のとおりのインスタンス変数①ないし⑧を設定し、(ⅱ)コンストラクタ（クラスからオブジェクトを生成する際に使用され、オブジェクトが利用される前に必要な準備を行うメソッド）を使用して初期化メソッドを呼び出し、(ⅲ)初期化メソッド①ないし③を使用してインスタンス変数①ないし⑧を初期化（値を代入）し、(ⅳ)対応するｇｅｔメソッド（インスタンス変数の値を返すメソッド）を使用して情報を取得し、情報①ないし⑧を本件ＳＤＫに提供するというものである。
ＳｐＡｐｐＩｎｆｏのソースコードは、別紙５－１の該当欄のとおりであり（別紙５－２もソースコードの記載は同じ。）、ｐａｃｋａｇｅ文、ｉｍｐｏｒｔ文、空白行及びコメント行（以下「空白行等」と総称する。）を含めて合計２３５行で記載されている。このうち、本件対象部分１のソースコードは合計８９行である（ただし、原告が比較のために並べ替える前の行数は各対比表の「ＳｐＡｐｐＩｎｆｏソースコード」の「行」欄のとおりである。）。
(ｳ) ＳｐＸｍｌＰａｒｓｅｒの構造等
ＳｐＸｍｌＰａｒｓｅｒは、簡易なＸＭＬ形式で記述されたＸＭＬデータの解析に共通する処理を定めたクラスである。それぞれ①Ｓｔｒｉｎｇ型、②Ｒｅａｄｅｒ型及び③ＩｎｐｕｔＳｔｒｅａｍ型の引数をとるインスタンスメソッド（プログラムの実行時にオブジェクトの一部として機能する処理に係るメソッド）、④ＸｍｌＰｕｌｌＰａｒｓｅｒ（オープンソースであるＡｎｄｒｏｉｄＳＤＫに付属するＸＭＬパーサー）のインスタンスを引数として実際にＸＭＬデータを解析するインスタンスメソッド（以下、これらのインスタンスメソッドを、それぞれ「ｐａｒｓｅメソッド①」などという。）並びにコールバックメソッド（特定のイベント発生時にのみ処理を行うことができるメソッド）として機能する３個の抽象メソッド（クラスにシグネチャのみ宣言され、実行できる指令を持たないインスタンスメソッド）によって構成されている。
本件対象部分２におけるソースコードには、上記のようなｐａｒｓｅメソッド①ないし④の処理や３個の抽象メソッドについて記載されているほか、(ⅰ)繰り返しの処理の中で読み込んだＸＭＬの要素（開始タグ、テキスト及び終了タグ等）に応じて処理を分岐し、分岐した処理の中でＸＭＬデータの要素に応じたコールバックメソッドを呼び出し、イベントとして通知（スロー）するという処理（以下「解析通知処理」という。）や、（ⅱ）ＸＭＬデータの解析中にエラーが発生した場合にエラーの内容を表す例外オブジェクト①又は②（いずれもＡｎｄｒｏｉｄＳＤＫに付属するもの）を本件ＳＤＫに固有の例外クラスに変換して通知するという処理（以下「例外処理」という。）についても記載されている。ＳｐＸｍｌＰａｒｓｅｒのソースコードは、別紙６－１の該当欄のとおりであり（別紙６－２もソースコードの記載は同じ。）、空白行等を含めて合計１４５行で記載されている。このうち、本件対象部分２のソースコードは合計５６行である（ただし、原告が比較のために並べ替える前の行数は各対比表の「ＳｐＸｍｌＰａｒｓｅｒのソースコード」の「行」欄のとおりである。）。
ウ ソケッツＳＤＫの構造等
(ｱ) クラス構成
ソケッツＳＤＫは、別紙４－２記載のとおり、３９個のクラスによって構成されており、これらが連携して前記アの機能を実現する。(ｲ) ＡｐｐＩｎｆｏの構造等
ＡｐｐＩｎｆｏは、サーバーのＷｅｂＡＰＩとの通信に必要な情報を提供するクラスであり、ソケッツＳＤＫに対して、情報①ないし⑧に加えて、⑨ＷｅｂＡＰＩのＵＲＬの種別（接続環境）、⑩ＷｅｂＡＰＩのＵＲＬのホスト名、⑪ＷｅｂＡＰＩのＵＲＬのパス名、⑫ＷｅｂＡＰＩのアクセストークンの情報（以下「情報⑨」などという。）を提供する機能を有する。さらに、情報⑩及び⑪についてはＭａｐ（キーと値をセットにして扱いたいときに使うデータ構造）を利用して情報提供を行い、サーバーを切り替えるというＳｐＡｐｐＩｎｆｏにない機能を有している。
本件対象部分１におけるソースコードの内容は、概要、(ⅰ)情報①ないし⑧に対応する別紙５－３「Ｎｏ１」「内容」欄のとおりのインスタンス変数①ないし⑧（情報①及び④に関連するインスタンス変数として、ＳｐＡｐｐＩｎｆｏにはないａｐｐｌｉｃａｔｉｏｎＩＤ及びｃａｒｒｉｅｒＣｏｄｅも設定されているものの、これらはｇｅｔメソッドが設定されていない。）に加えて、情報⑨ないし⑫に対応するインスタンス変数⑨ないし⑫を設定し、(ⅱ)コンストラクタを使用して初期化メソッドを呼び出し、(ⅲ)初期化メソッド①②及びｌｏａｄＲｅｓｏｕｒｃｅｓを使用してインスタンス変数①ないし⑪を初期化し、(ⅳ)対応するｇｅｔメソッドを使用して情報を取得し、情報①③④⑨ないし⑫をソケッツＳＤＫに提供するというものである。
ＡｐｐＩｎｆｏについて、原告が被告から本件訴訟提起時点のものとして開示されたソースコード（乙Ｂ４１の３）及びその変更履歴に係るＧｉｔレポジトリ（乙Ｂ４２の３）に基づき平成２９年７月２５日時点のものとして復元したソースコードは、別紙５－１の該当欄のとおりであり（別紙５－２もソースコードの記載は同じ）、空白行等を含めて合計２４０行で記載されている。このうち、本件対象部分２のソースコードは合計１４１行である。
(ｳ) ＸｍｌＰａｒｓｅｒの構造等
ＸｍｌＰａｒｓｅｒは、簡易なＸＭＬ形式で記述されたＸＭＬデータを解析するために共通する処理方法を定めたクラスである。ｐａｒｓｅメソッド①ないし④及びコールバックメソッドとして機能する３個の抽象メソッドに加えて、ＸＭＬの要素とオブジェクトのプロパティの自動マッピングというＳｐＸｍｌＰａｒｓｅｒにない機能を有するインスタンスメソッドｃｏｐｙＰｒｏｐｅｒｔｙ（以下「ｃｏｐｙＰｒｏｐｅｒｔｙメソッド」という。）によって構成されている。
本件対象部分２におけるソースコードの内容は、概ねＳｐＸｍｌＰａｒｓｅｒと同様のものであるが、ｃｏｐｙＰｒｏｐｅｒｔｙメソッドにおいて、オブジェクトが指定の文字列と一致する名前の変数を持つ場合に指定の値をその変数に設定することも記載されている。
ＸｍｌＰａｒｓｅｒについて、原告が被告から本件訴訟提起時点のものとして開示されたソースコード（乙Ｂ４１の２）及びその変更履歴に係るＧｉｔレポジトリ（乙Ｂ４２の２）に基づき平成２９年７月２５日時点のものとして復元したソースコードは、別紙６－１の該当欄のとおりであり（別紙６－２もソースコードの記載は同じ。）、空白行等を含めて合計９５行で記載されている。このうち、本件対象部分２のソースコードは合計６５行である。
エ 本件対象部分１及び２における対比
(ｱ) 本件対象部分１
ａ プログラム構造
前記イ(ｲ)及びウ(ｲ)のとおり、本件対象部分１におけるＡｐｐＩｎｆｏとＳｐＡｐｐＩｎｆｏのソースコードは、(ⅰ)インスタンス変数①ないし⑧を設定し（ただし、別紙５－３「Ｎｏ１」「内容」欄のとおりインスタンス変数の記述は異なる。）、(ⅱ)コンストラクタを使用して初期化メソッドを呼び出し、(ⅲ)初期化メソッドを使用してインスタンス変数①ないし⑧を初期化し、(ⅳ)対応するｇｅｔメソッドを使用して情報を取得するものとして記載されており、これらの点等において両者のプログラム構造は共通である。
他方、両者は、(ⅴ)ＡｐｐＩｎｆｏがインスタンス変数⑨ないし⑫を設定し、これらについても基本的には同様の手順で情報を取得するなどするものとして記載されている点においてプログラム構造が相違しており、インスタンス変数①ないし⑧に係る処理内容に限っても、(ⅵ)ＡｐｐＩｎｆｏはインスタンス変数④の初期化を初期化メソッド①で行っているのに対し、ＳｐＡｐｐＩｎｆｏは初期化メソッド③で行い、インスタンス変数①ないし⑧の初期化の順序も完全には一致しない点、(ⅶ)ＡｐｐＩｎｆｏは情報①ないし⑧のうち情報①③④だけをソケッツＳＤＫに提供している点等において、相違する。
ｂ ソースコード
本件対象部分１におけるＡｐｐＩｎｆｏ（合計１４１行）とＳｐＡｐｐＩｎｆｏ（合計８９行）のソースコードを対比すると、別紙５－３「内容」欄記載のとおり、(Ⅰ)対応する８個のインスタンス変数（インスタンス変数①ないし⑧）を使用し（ポイント１）、(Ⅱ)初期化メソッド①でインスタンス変数⑤、⑧、⑦、⑥、①、②の順に初期化した上で、初期化メソッド②でインスタンス変数③を初期化する記載（ポイント２ないし４）、(Ⅲ)インスタンス変数①②のログを初期化メソッド①内でまとめて出力する記載及びインスタンス変数③のログを初期化メソッド②内で個別の値を読み込む都度出力する記載（ポイント５及び６）において、共通する。
他方、両者は、同別紙「内容」欄記載のとおり、少なくともポイント７ないし１２において記載が相違している。すなわち、(Ⅳ)ＡｐｐＩｎｆｏはインスタンス変数⑨ないし⑫を設定し、情報⑨ないし⑫を取得するなどの処理（前記ａ(ⅴ)）を記載している点（ポイント７）、(Ⅴ)ＡｐｐＩｎｆｏはインスタンス変数④の初期化を初期化メソッド①で行う処理（前記ａ(ⅵ)）を記載しているのに対し、ＳｐＡｐｐＩｎｆｏは初期化メソッド③で行う処理を記載している点（ポイント８）、(Ⅵ)ＡｐｐＩｎｆｏは取得した値をインスタンス変数⑤に代入しているのに対し、ＳｐＡｐｐＩｎｆｏはこれをローカル変数（インスタンス変数と異なり、そのブロック内でしか使用することができない変数）に代入している点（ポイント９）、(Ⅶ)ＡｐｐＩｎｆｏはインスタンス変数③の初期化等の処理を初期化メソッド②から切り出して記載しているのに対し、ＳｐＡｐｐＩｎｆｏはその処理を初期化メソッド②内に記載している点（ポイント１０）、(Ⅷ)ＡｐｐＩｎｆｏはＭａｐ型変数を用いたインスタンス変数⑩⑪の処理を記載している点（ポイント１１）、(Ⅸ)ＳｐＡｐｐＩｎｆｏはデコードした値をインスタンス変数①に代入する処理を記載している点（ポイント１２）等において、相違する。
以上によれば、本件対象部分１のソースコードについて、ＡｐｐＩｎｆｏのうち少なくとも約４４％の行は明らかに記載が相違し、また、別紙５－１「行」欄のとおり、ソースコードの記載の具体的順序は大きく異なる上、上記記載が共通する部分についてもソースコードの具体的記述は一致していない。
(ｲ) 本件対象部分２
ａ プログラム構造
前記イ(ｳ)及びウ(ｳ)のとおり、ＸｍｌＰａｒｓｅｒとＳｐＸｍｌＰａｒｓｅｒのソースコードは、ｐａｒｓｅメソッド①ないし④におけるＸＭＬデータの解析、解析通知処理及び例外処理等が記載されており、これらの点等において両者のプログラム構造は共通である。他方、両者は、ＸｍｌＰａｒｓｅｒに、ＳｐＸｍｌＰａｒｓｅｒには記載のないｃｏｐｙＰｒｏｐｅｒｔｙメソッドの処理（前記ウ(ｳ)）が記載されている点等において相違する。
ｂ ソースコード
本件対象部分２におけるＸｍｌＰａｒｓｅｒ（合計６５行）とＳｐＸｍｌＰａｒｓｅｒ（合計５６行）のソースコードを対比すると、別紙６－３「内容」欄のとおり、(Ⅰ)ａｎｄｒｏｉｄ．ｕｔｉｌパッケージ（オープンソース）パッケージ内のＸｍｌ．ｎｅｗＰｕｌｌＰａｒｓｅｒを利用してＸｍｌＰｕｌｌＰａｒｓｅｒのインスタンスを取得する記載（ポイント⑴）、(Ⅱ)ｐａｒｓｅメソッド②③④にｔｒｙ／ｃａｔｃｈブロックを記載し、ｐａｒｓｅメソッド④にｔｒｙ／ｃａｔｃｈ文、ｆｏｒ文及びｓｗｉｔｃｈ文の３個の入れ子構造とする記載（ポイント⑵）、(Ⅲ)コールバックメソッドに引数となる値を直接渡す記載（ポイント⑶）、(Ⅳ)繰り返し処理にｆｏｒ文を用いる記載（ポイント⑷）、(Ⅴ)条件分岐処理にｓｗｉｔｃｈ文を用いる記載（ポイント⑸）、(Ⅵ)コールバック呼び出し時の引数にスタック型のローカル変数を使用する記載（ポイント⑹）、(Ⅶ)抽象メソッドを介してイベントを通知（コールバック）する記載（ポイント⑺）において、共通する。
他方、両者は、同別紙「内容」欄記載のとおり、少なくともポイント⑻ないし⑽において記載が相違している。すなわち、(Ⅷ)ＸｍｌＰａｒｓｅｒはＸＭＬデータをログ出力する処理を記載している点（ポイント⑻）、(Ⅸ)ＸｍｌＰａｒｓｅｒはｃｏｐｙＰｒｏｐｅｒｔｙメソッドの処理（前記ウ(ｳ)）を記載している点（ポイント⑼）、(Ⅹ)ＸｍｌＰａｒｓｅｒはｐａｒｓｅメソッド②ないし④においてキャッチした例外オブジェクト①を固有の例外クラスに変換してから再スローする処理をコンストラクタに直接値を渡す方法で記載しているのに対し、ＳｐＸｍｌＰａｒｓｅｒはローカル変数に値を格納する方法で記載している点（ポイント⑽）等において、相違する。
以上によれば、本件対象部分２のソースコードについて、ＸｍｌＰａｒｓｅｒのうち少なくとも約３０％の行は明らかに記載が相違し、また、別紙６－１のとおり、上記記載が共通する部分についてもソースコードの具体的記述は一致していない。
オ 記載が共通する部分について
(ｱ) 本件対象部分１
ａ プログラム構造
インスタンス変数を設定しｇｅｔメソッドを介して所定の情報を取得するという手法はＪａｖａ言語では一般的に使用されており、ウェブサイト（乙Ｂ３８の２ないし５、乙Ｂ４３の３等）にも、そのような手法を用いたソースコードの記載例が掲載されている。
また、ｇｅｔメソッドを介して情報を取得するためにはインスタンス変数を初期化する必要があるところ、コンストラクタを使用して初期化メソッドを呼び出してインスタンス変数を初期化するという手法はＪａｖａ言語で一般的に使用されており、ウェブサイト（乙Ｂ３４の１０・１２・１９ないし３１・３７ないし３９、乙Ｂ４３の２・６）にも、そのような手法を用いたソースコードの記載例が掲載されている。
ｂ ポイント１（インスタンス変数の使用）
インスタンス変数を使用せずに所定の情報を取得するソースコードを記載することもできるが、情報取得時に毎回同じ処理を実行する記載が必要になるため、情報取得を繰り返し実行する場合にはインスタンス変数を使用したときと比べてソースコードが長文化する。
ｃ ポイント２ないし４（初期化メソッドを用いたインスタンス変数の初期化）
初期化メソッドを使用せずにインスタンス変数を初期化することもできるが、インスタンス変数を初期化する際に毎回処理を実行する記載が必要になるため、複数のインスタンス変数を初期化する場合には初期化メソッドを使用したときと比べてソースコードが長文化する。ポイント２ないし４における７個のインスタンス変数の初期化の順番や各インスタンス変数をどの初期化メソッドで初期化を行うかによって処理内容に違いは生じない。
ｄ ポイント５及び６（ログを出力する方法）
変数の値のログを出力する目的は主にデバッグ（プログラムのバグを見つけ出し、その原因を特定して修正するプロセス）であり、値を取得した直後に出力する方法やメソッドの処理の結果として後でまとめて出力する方法は一般的な手法である。ウェブサイト（乙Ｂ３４の３２ないし３６）にも、ソースコードの記載例が掲載されている。(ｲ) 本件対象部分２
ａ プログラム構造
任意の形式のＸＭＬデータの解析に共通する処理を定めたクラスを設け、Ｓｔｒｉｎｇ型、Ｒｅａｄｅｒ型及びＩｎｐｕｔＳｔｒｅａｍ型の引数をとるインスタンスメソッドを用意し、ＸｍｌＰｕｌｌＰａｒｓｅｒを使用してＸＭＬデータを解析する手法は一般的に使用されており、書籍（横山隆司「ＧｏｏｇｌｅＡｎｄｒｏｉｄＷｅｂＡＰＩプログラミング入門」（乙Ｂ３４の４１、乙Ｂ４３の４）。以下「本件書籍」という。）及びウェブサイト（乙Ｂ３４の４０・４７・４８）にも、ＸｍｌＰｕｌｌＰａｒｓｅｒを用いた解析通知処理や、ＸＭＬデータ解析中にエラーが発生した場合の処理に係るソースコードの記載例が掲載されている。
ｂ ポイント⑴（ＸｍｌＰｕｌｌＰａｒｓｅｒのインスタンスを取得する方法‐Ｘｍｌ．ｎｅｗＰｕｌｌＰａｒｓｅｒの利用）
ＸｍｌＰｕｌｌＰａｒｓｅｒのインスタンスを取得する際にＸｍｌ．ｎｅｗＰｕｌｌＰａｒｓｅｒを利用する方法とＸｍｌＰｕｌｌＰａｒｓｅｒＦａｃｔｏｒｙ．ｎｅｗＰｕｌｌＰａｒｓｅｒを利用する方法が一般的に使用されており、ウェブサイト（乙Ｂ３５の５、乙Ｂ３８の８・１５、乙Ｂ４３の２４）でも、これらを利用してＸｍｌＰｕｌｌＰａｒｓｅｒのインスタンスを取得することが推奨されているほか、Ｘｍｌ．ｎｅｗＰｕｌｌＰａｒｓｅｒを利用したソースコードの記載例等も掲載されている。
ｃ ポイント⑵（例外処理‐入れ子構造）
ＸＭＬデータの解析処理では、ｆｏｒ文又はｗｈｉｌｅ文によってＸＭＬデータを読み込む処理を繰り返し、ｓｗｉｔｃｈ文又はｉｆ文によって読み込んだＸＭＬの要素に応じた分岐処理を行うのが一般的である。
また、ｔｒｙ／ｃａｔｃｈ文は例外処理に用いられる一般的な構文であり、ウェブサイト（乙Ｂ３５の６、乙Ｂ４３の５）にも、ＸＭＬデータ解析中にエラーが発生した場合に例外オブジェクト①②を固有の例外クラスに変換して通知（スロー）する処理にｔｒｙ／ｃａｔｃｈ文を用いるソースコードの記載例が掲載されている。
さらに、本件書籍には、ｐａｒｓｅメソッド内でｔｒｙ／ｃａｔｃｈ文、ｗｈｉｌｅ文及びｓｗｉｔｃｈ文が入れ子構造になったソースコードの記載例が掲載されている。
ｄ ポイント⑶（引数を直接渡す処理）
コールバックメソッドに戻り値を引数として渡す際に戻り値を直接渡す方法と戻り値をローカル変数に代入して渡す方法が一般的に使用されており、ウェブサイト（乙Ｂ３５の９・１０）にも、これらの方法を用いたソースコードの記載例が掲載されている。
ｅ ポイント⑷（繰り返し処理‐ｆｏｒ文）
繰り返し処理の構文として、ｆｏｒ文、ｗｈｉｌｅ文及びｄｏｗｈｉｌｅ文等を使用することができるが、ｆｏｒ文は決められた回数だけ処理を繰り返す、ｗｈｉｌｅ文は条件を満たす場合には回数を決めずに処理を繰り返す、ｄｏｗｈｉｌｅ文は少なくとも１回は処理を繰り返すといった処理内容の違いがある。
ｆ ポイント⑸（条件分岐処理‐ｓｗｉｔｃｈ文）
条件分岐処理の構文として、ｓｗｉｔｃｈ文及びｉｆ／ｅｌｓｅ文を使用することができるが、変数が３個以上の値をとり、値によって処理を振り分けるときはｓｗｉｔｃｈ文が一般的に使用されており、ウェブサイト（乙Ｂ３５の１５・１６）等にも、ｓｗｉｔｃｈ文を使用したソースコードの記載例が掲載されている。
ｇ ポイント⑹（スタック型ローカル変数の使用）
イベントに対するコールバック呼び出し時の引数として、文字列型の変数を使用することも可能であるが、スタック型のローカル変数を使用する方法は一般的に使用されており、ウェブサイト（乙Ｂ３４の５０、乙Ｂ３５の１７、１８）にも、スタック型のローカル変数にタグ名を保持するソースコードの記載例が掲載されている。
ｈ ポイント⑺（コールバックの方法）
イベントの通知（コールバック）にインターフェースを使用することも可能であるが、抽象メソッドを使用する方法は一般的に使用されている。
⑵検討
ア 複製又は翻案の成否
著作物の翻案とは、既存の著作物に依拠し、かつ、その表現上の本質的な特徴の同一性を維持しつつ、具体的表現に修正、増減、変更等を加えて、新たに思想又は感情を創作的に表現することにより、これに接する者が既存の著作物の表現上の本質的な特徴を直接感得することのできる別の著作物を創作する行為をいい（最高裁平成１１年（受）第９２２号同１３年６月２８日第一小法廷判決・民集５５巻４号８３７頁）、複製とは、既存の著作物に依拠し、これと同一のものを作成し、又は、具体的表現に修正、増減、変更等を加えても、新たに思想又は感情を創作的に表現することなく、その表現上の本質的な特徴を維持し、これに接する者が既存の著作物の表現上の本質的特徴を直接感得することのできるものを作成する行為をいうものと解される。
そして、プログラムは、その性質上、表現する記号が制約され、言語体系が厳格であり、また、電子計算機を少しでも経済的、効率的に機能させようとすると、指令の組合せの選択が限定されるため、プログラムにおける具体的記述が相互に類似することが少なくない。著作権法は、プログラムの具体的表現を保護するものであって、機能やアイデアを保護するものではないところ、プログラムの具体的記述に選択の余地がないか、あるいは、選択の幅が十分でない場合又はありふれた表現である場合は、作成者の個性が発揮されていないものとして、創作性がないというべきである。他方、指令の表現、指令の組合せ、指令の順序からなるプログラム全体に選択の幅が十分にあり、かつ、それがありふれた表現ではなく、作成者の個性が表れている場合は、創作性が認められるべきである。
以下、原告においてプログラムの具体的記述を対比している本件対象部分１及び２に基づき検討する。
イ 本件対象部分１
(ｱ) 本件対象部分１における両ソースコードは、前記⑴エ(ｱ)ａの(ⅰ)ないし(ⅳ)のとおりのプログラム構造の下、同ｂの(Ⅰ)ないし(Ⅲ)のとおり、ポイント１ないし６について、ソースコードの記載が共通する。(ｲ) もっとも、両ソースコードは、ＡｐｐＩｎｆｏが情報⑨ないし⑫を処理するためインスタンス変数⑨ないし⑫が設定されている点においてプログラム構造が相違し（前記⑴エ(ｱ)ａ）、インスタンス変数①ないし⑧に係る処理内容に限っても、ＡｐｐＩｎｆｏはインスタンス変数④の初期化を初期化メソッド①で行っているのに対し、ＳｐＡｐｐＩｎｆｏは初期化メソッド③で行い、インスタンス変数①ないし⑧の初期化の順序も完全には一致しない点、ＡｐｐＩｎｆｏは情報①③④だけをソケッツＳＤＫに提供している点等においてプログラム構造が相違し、これらに対応するソースコードの記載（ポイント７、８等）も相違するほか、インスタンス変数⑤の初期化の方法（取得した値の代入先（ポイント９）。）等に係るソースコードの記載も相違する（同ｂ）。また、ソースコードの記述の具体的順序は大きく異なる（同ｂ）。
(ｳ) そして、ＷｅｂＡＰＩとの通信に必要な情報を提供するための指令の組合せは、ＷｅｂＡＰＩの仕様によって規制されるため本来的に同様の組合せになりやすく、また、意味のある複数の情報や繰り返し実行する処理を変数やメソッドを用いることはプログラムの可読性を高める自然な記載であるというべきであり1、ＷｅｂＡＰＩとの通信に必要な情報①ないし⑧を取得するための指令を、Ｊａｖａ言語で一般的に使用されるインスタンス変数やｇｅｔメソッドを使用する手法（前記⑴オ(ｱ)ａ）によって記載（ポイント１）するのは自然なことであって、インスタンス変数を使用せずに所定の情報を取得するソースコードを記載することができる（同ｂ）としても、それ自体はありふれた表現である。また、同様に、ｇｅｔメソッドを介して情報を取得するためには対応するインスタンス変数を初期化する必要があり、そのための指令を、Ｊａｖａ言語で一般的に使用されるコンストラクタによって初期化メソッドを呼び出す手法（前記⑴オ(ｱ)ａ）によって記載（ポイント２及び３）するのも自然なことであって、初期化メソッドを使用せずにインスタンス変数を初期化することができる（同ｃ）としても、それ自体はありふれた表現である。加えて、複数のインスタンス変数を設定した場合にいずれかの初期化メソッドを使用して適宜の順に初期化する必要があることは当然であるから、各インスタンス変数を所定の初期化メソッドを使用して適宜の順で初期化する記載（ポイント４）もありふれた表現であるといわざるを得ない。
さらに、値を取得した直後にログを出力する方法やメソッドの処理の結果として後でまとめてログを出力する方法はいずれも一般的なものであり、定型的な表現であると認められる（前記⑴オ(ｱ)ｄ）から、これらを用いた記載（ポイント５及び６）も、それ自体はありふれた表現である。
(ｴ) このように、本件対象部分１における両ソースコードの記載に共通する部分があるとしても（前記(ｱ)）、当該部分について表現上の創作性を認めることができないから（前記(ｳ)）、ＡｐｐＩｎｆｏが、ＳｐＡｐｐＩｎｆｏの本件対象部分１の表現上の本質的な特徴の同一性を維持しているということはできない。
また、仮に、上記ポイント１ないし８のありふれた表現を組み合わせることにより、本件対象部分１につき、全体として表現上の創作性を認める余地があるとしても、本件対象部分１におけるＳｐＡｐｐＩｎｆｏの行数はわずか８９行であり、ありふれた表現を組み合わせることによる創作性の程度は自ずと低いものといわざるを得ない。そして、前記(ｲ)のとおり、本件対象部分１における両ソースコードの記載順序は大きく異なり、各行の記載を見ても、本件対象部分１に係るＡｐｐＩｎｆｏのソースコード（１４１行）のうち、少なくとも約４４％の行については明らかに相違し、その余の部分もソースコードの具体的な記述が一致しているわけではない。このように、両ソースコードを全体として見たときの、記載内容、記載順序及び組合せの相違の程度に照らせば、ＡｐｐＩｎｆｏが、ＳｐＡｐｐＩｎｆｏの本件対象部分１の表現上の本質的な特徴の同一性を維持し、ＡｐｐＩｎｆｏに接する者がＳｐＡｐｐＩｎｆｏの表現上の本質的な特徴を直接感得することができるということもできない。
ウ 本件対象部分２
(ｱ) 本件対象部分２における両ソースコードは、前記⑴エ(ｲ)ａのとおりのプログラム構造の下、同ｂの(Ⅰ)ないし(Ⅶ)のとおり、ポイント⑴ないし⑺について、ソースコードの記載が共通する。
(ｲ) もっとも、両ソースコードは、ＸｍｌＰａｒｓｅｒはｃｏｐｙＰｒｏｐｅｒｔｙメソッドの処理も記載されている点等においてプログラム構造が相違し（前記⑴エ(ｲ)ａ）、これに対応するソースコードの記載（ポイント⑼）が相違しているほか、例外オブジェクト①の例外処理の方法（ポイント⑽）等に係るソースコードの記載も相違している（同ｂ）。
(ｳ) そして、任意の形式のＸＭＬデータの解析に共通する処理を定めたクラスにおいて、Ｓｔｒｉｎｇ型、Ｒｅａｄｅｒ型及びＩｎｐｕｔＳｔｒｅａｍ型の引数をとるインスタンスメソッドを用意し、ＸｍｌＰｕｌｌＰａｒｓｅｒを使用してＸＭＬデータを解析する場合、ＸＭＬデータの要素を読み込む処理を繰り返し、読み込んだＸＭＬの要素に応じて処理を分岐し、分岐した処理の中でＸＭＬデータの要素に応じたコールバックメソッドを呼び出してイベントを通知（コールバック）するという解析通知処理や、ＸＭＬデータ解析中にエラーが発生した場合に例外オブジェクト①②を固有の例外クラスに変換して通知（スロー）するという例外処理は一般的に行われているところ（前記⑴オ(ｲ)ａｃ）、繰り返し処理にｆｏｒ文やｗｈｉｌｅ文、条件分岐処理にｓｗｉｔｃｈ文やｉｆ／ｅｌｓｅ文が用いられ、例外処理にｔｒｙ／ｃａｔｃｈ文が用いられるのが一般的であり、これらの構文を入れ子構造として組み合わせる記載例もあること（同ｃｅｆ）からすれば、各構文の特徴を踏まえ、これらを組み合わせて上記各処理に係る指令を記載すること（ポイント⑵⑷⑸）は、ありふれた表現である。そして、上記各処理に係る指令に対し、ＸｍｌＰｕｌｌＰａｒｓｅｒのインスタンスを取得する方法（ポイント⑴）、コールバックメソッドに引数となる値を渡す方法（ポイント⑶）、コールバック呼び出し時の引数の設定（ポイント⑹）及びイベントを通知（コールバック）する方法（ポイント⑺）として、いずれも限られたありふれた選択肢（前記⑴オ(ｲ)ｂｄｇｈ）の中から、一般的に使用される指令の一つを組み合わせたというだけでは、ありふれた表現であることに変わりはないというべきである。
(ｴ) このように、本件対象部分２における両ソースコードの記載に共通する部分があるとしても（前記(ｱ)）、当該部分について表現上の創作性を認めることができないから（前記(ｳ)）、ＸｍｌＰａｒｓｅｒが、ＳｐＸｍｌＰａｒｓｅｒの表現上の本質的な特徴の同一性を維持しているとはいえない。
また、仮に、上記ポイント⑴ないし⑺のありふれた表現を組み合わせることにより、本件対象部分２につき、全体として表現上の創作性を認める余地があるとしても、本件対象部分２におけるＳｐＸｍｌＰａｒｓｅｒの行数はわずか５６行であり、ありふれた表現を組み合わせることによる創作性の程度は自ずと低いものといわざるを得ない。そして、前記(ｲ)のとおり、本件対象部分２における両ソースコードの各行の記載を見ても、本件対象部分２に係るＸｍｌＰａｒｓｅｒのソースコード（６５行）のうち、少なくとも約３０％の行については明らかに相違し、その余の部分もソースコードの具体的な記述が一致しているわけではない。このように、両ソースコードを全体として見たときの、記載内容、記載順序及び組合せの相違の程度に照らせば、ＸｍｌＰａｒｓｅｒが、ＳｐＸｍｌＰａｒｓｅｒの表現上の本質的な特徴の同一性を維持し、ＸｍｌＰａｒｓｅｒに接する者がＳｐＸｍｌＰａｒｓｅｒの表現上の本質的な特徴を直接感得することができるということもできない。
エ 小括
以上のとおり、本件対象部分１及び２の対比によっても、ソケッツＳＤＫが本件ＳＤＫを複製又は翻案したものであるということはできない。加えて、本件ＳＤＫのクラス数は５６個であるのに対し、ソケッツＳＤＫのクラス数は３９個であって、クラス構成も異なり（前記⑴イ(ｱ)及びウ(ｱ)）、本件対象部分１及び２はこれらのうち２個のクラスにすぎないから、この意味からも、ソケッツＳＤＫが、本件ＳＤＫの表現上の本質的な特徴の同一性を維持しているということはできないし、ソケッツＳＤＫに接する者が本件ＳＤＫの表現上の本質的な特徴を直接感得することができるということもできない。
⑶原告の主張について
ア 本件対象部分１
原告は、①ＡｐｐＩｎｆｏとＳｐＡｐｐＩｎｆｏは、いずれも８個の情報にそれぞれ別個のインスタンス変数を用意し、インスタンス変数に対応するｇｅｔメソッドを介して情報提供するというプログラムの基本的な仕組みや各インスタンス変数を初期化する手順が同一である、②別紙５－１のとおり、ＡｐｐＩｎｆｏとＳｐＡｐｐＩｎｆｏは、ソースコードの表現に同一性を有する部分が極めて多い、③別紙５－３の「原告の主張」欄のとおり、ポイント１ないし６に創作性が認められるから、ＡｐｐＩｎｆｏからＳｐＡｐｐＩｎｆｏの表現上の本質的特徴を直接感得することができ、ポイント７ないし１２はＳｐＡｐｐＩｎｆｏの表現上の本質的特徴を直接感得することを妨げるものではないなどと主張しており、原告作成の報告書等（甲４３、４６、５５、５９、６０、６８、７０、７４）にはこれに沿う記載がある。
しかしながら、上記①について、原告においてプログラムの具体的記述を対比している本件対象部分１において、８個の情報にそれぞれ別個のインスタンス変数を設定し、初期化メソッドを使用してこれらを初期化し、所定の情報を取得するという処理の記載に創作性が認められないことは前記⑵イで説示したとおりであるところ、プログラムの基本的な仕組みや処理の流れ自体は、著作権法１０条３項３号所定の「解法」であって、著作物としての保護を受けない部分であるから、プログラムの表現上の創作性とは無関係である。
また、上記②について、本件対象部分１におけるＳｐＡｐｐＩｎｆｏのソースコードは８９行にとどまり、ＡｐｐＩｎｆｏのソースコードのうち約４４％について記載が相違していること（前記⑴エ(ｱ)ｂ）からすれば、ソースコードの表現に同一性を有する部分が極めて多いとはいえない。
さらに、上記③について、ポイント１ないし６に係る記載がいずれも一般的なものであり、それ自体がありふれた表現であることは前記⑵イで説示したとおりであって、両ソースコードを全体として見ると、記載内容、記載順序及び組合せが異なることからすれば、ＡｐｐＩｎｆｏが、ＳｐＡｐｐＩｎｆｏの本件対象部分１の表現上の本質的な特徴の同一性を維持し、ＡｐｐＩｎｆｏに接する者がＳｐＡｐｐＩｎｆｏの表現上の本質的な特徴を直接感得することができるということもできないことも、前記⑵イに説示したとおりである。
イ 本件対象部分２
原告は、①ＸｍｌＰａｒｓｅｒとＳｐＸｍｌＰａｒｓｅｒは、いずれも４個の異なるインスタンスメソッドが連携してＸＭＬデータの解析を行う構成を有し、ＸＭＬデータを解析中にエラーが発生した場合、固有の例外クラスに変換して通知（スロー）するというプログラムの基本的な仕組みや処理手順が同一である、②別紙６－１のとおり、ＸｍｌＰａｒｓｅｒとＳｐＸｍｌＰａｒｓｅｒは、ソースコードの表現に同一性を有する部分が極めて多い、③別紙６－３の「原告の主張」欄のとおり、ポイント⑴ないし⑺に創作性が認められるから、ＸｍｌＰａｒｓｅｒからＳｐＸｍｌＰａｒｓｅｒの表現上の本質的特徴を直接感得することができる、ポイント⑻ないし⑽はＳｐＸｍｌＰａｒｓｅｒの表現上の本質的特徴を直接感得することを妨げるものではないなどと主張しており、原告作成の報告書等（甲４４、４７、５５、５９、６０、６８、７０）にはこれに沿う記載がある。しかしながら、上記①について、原告においてプログラムの具体的記述を対比している本件対象部分２において、４個の異なるインスタンスメソッドを設けてＸＭＬデータを解析し、例外処理を行う指令の組合せに創作性が認められないことは前記⑵ウで説示したとおりであるところ、プログラムの基本的な仕組みや処理の流れ自体は、著作権法１０条３項３号所定の「解法」であり著作物としての保護を受けないことは前記アと同様である。
また、上記②について、本件対象部分２におけるＳｐＸｍｌＰａｒｓｅｒのソースコードは５６行にとどまり、ＸｍｌＰａｒｓｅｒのソースコードのうち約３０％は記載が相違していること（前記⑴エ(ｲ)ｂ）からすれば、ソースコードの記載に同一性を有する部分が極めて多いとはいえない。
さらに、上記③について、ポイント⑴ないし⑺に係る記載がいずれも一般的なものであり、それ自体がありふれた表現であることは前記⑵ウで説示したとおりであって、両ソースコードを全体として見ると、記載内容、記載順序及び組合せが異なることからすれば、ＸｍｌＰａｒｓｅｒが、ＳｐＸｍｌＰａｒｓｅｒの本件対象部分２の表現上の本質的な特徴の同一性を維持し、ＸｍｌＰａｒｓｅｒに接する者がＳｐＸｍｌＰａｒｓｅｒの表現上の本質的な特徴を直接感得することができるということもできないことも、前記⑵ウに説示したとおりである。
⑷まとめ（争点４）
以上によれば、ソケッツＳＤＫは、本件ＳＤＫの複製物又は翻案物に当たるといえないから、被告の行為によって、本件ＳＤＫに係る原告の著作権（複製権又は翻案権）が侵害されたとはいえない。
したがって、その余の点を判断するまでもなく、原告の著作権に基づく差止め等請求及び損害賠償請求は理由がない。
４ 争点５（本件ＳＤＫが営業秘密に該当するか）及び争点６（被告が営業上の利益を図り又は原告に損害を加える目的で本件ＳＤＫを使用又は開示したか）について
⑴原告は、被告が、原告から示された営業秘密である本件ＳＤＫを参照してソケッツＳＤＫを制作し、平成２９年１２月１２日以降、レコチョクに対してソケッツＳＤＫを納品した行為が、営業秘密である本件ＳＤＫの使用又は開示に当たり、不競法２条１項７号所定の不正競争に該当すると主張する。⑵本件ＳＤＫ及びソケッツＳＤＫは、いずれもＡｎｄｒｏｉｄ端末向けの本件アプリに組み込まれ、本件アプリに同期歌詞表示機能を付加するためのプログラムであり、ＷｅｂＡＰＩを介して必要な同期歌詞データに係る情報をサーバーにリクエストし、サーバーからのレスポンスであるＸＭＬデータを解析し、解析結果をユーザー端末の画面に表示するという共通の機能を有するプログラムであり（前記３⑴ア）、ＷｅｂＡＰＩの仕様によって処理内容や指令の選択が制約されるものである。
前記３⑷のとおり、ソケッツＳＤＫは、本件ＳＤＫのソースコードを複製又は翻案したものであるとはいえないところ、前記３⑵で説示したとおり、本件対象部分１及び２における両ソースコードのプログラム構造や記載が共通する部分（ポイント１ないし６及びポイント⑴ないし⑺）は、いずれも書籍やウェブサイトに多数の記載例が掲載されているような一般的な手法を組み合わせたありふれた記載であって、本件ＳＤＫを参照しなければ作成できないようなものではないから、ソケッツＳＤＫと本件ＳＤＫにおいて共通するプログラム構造や記載に係る情報が有用であるということはできない。そして、本件ＳＤＫのクラス数は５６個であるのに対し、ソケッツＳＤＫのクラス数は３９個であり（同イ(ｱ)及びウ(ｱ)）、原告が対比しているのはそれらのうち各２個のクラスにとどまり、本件対象部分１におけるＳｐＡｐｐＩｎｆｏのソースコードは８９行であって、ＡｐｐＩｎｆｏのソースコードのうち約４４％は記載が相違し（同エ(ｱ)ｂ）、本件対象部分２におけるＳｐＸｍｌＰａｒｓｅｒのソースコードは５６行であって、ＸｍｌＰａｒｓｅｒのソースコードのうち約３０％は記載が相違している（同エ(ｲ)ｂ）。そうすると、本件ＳＤＫ及びソケッツＳＤＫの全体の行数は不明であるものの、本件ＳＤＫとソケッツＳＤＫのソースコード全体に対して、ソースコードの記載が共通する部分の分量は、極めて限定的である。
以上のとおり、ソケッツＳＤＫと本件ＳＤＫにおいて共通するプログラム構造や記載に係る情報が有用であるとはいえず、共通するプログラムの記載部分も極めて限定的であることからすれば、仮にソケッツＳＤＫが営業秘密であり、被告がソケッツＳＤＫを制作した際に本件ＳＤＫを参照した可能性を否定できないとしても、被告の行為が営業秘密の使用又は開示（不競法２条１項７号）に当たると評価することはできない。
⑶以上によれば、被告がソケッツＳＤＫを制作してレコチョクに納品した行為につき不競法２条１項７号所定の不正競争は成立しない。
したがって、その余の点を判断するまでもなく、本件ＳＤＫに係る不正競争を理由とする同法３条に基づく差止及び廃棄請求並びに同法４条に基づく損害賠償請求は理由がない。
第４ 結論
よって、本件訴えのうち、本件差止対象データを第三者に開示し又は自ら使用することの差止めを求める部分及び本件差止対象データの消去を求める部分は不適法であるからいずれも却下することとし、原告のその余の請求はいずれも理由がないから棄却することとして、主文のとおり判決する。東京地方裁判所民事第４６部
裁判長裁判官髙
橋彩
裁判官西
山芳樹
裁判官瀧
澤惟子
別紙１
省略
（別紙２）
プログラム目録１
１ プチリリＳＤＫ（ＰｅｔｉｔｌｙｒｉｃｓＳＤＫ１．３(Ａｎｄｒｏｉｄ版)）
２ プチリリＳＤＫ（ｐｅｔｉｔｌｙｒｉｃｓ－ｓｄｋ－１．３．１(Ａｎｄｒｏｉｄ版)）
３ プチリリＳＤＫ（ｐｅｔｉｔｌｙｒｉｃｓ－ＳＤＫ－１．３．４(Ａｎｄｒｏｉｄ版)）
４ プチリリＳＤＫ（ｐｅｔｉｔｌｙｒｉｃｓ－ｓｄｋ－１．３．４ｂ (Ａｎｄｒｏｉｄ版)）
以上
（別紙３）
プログラム目録２
パッケージ名「ｊｐ．ｃｏ．ｓｏｃｋｅｔｓ．ｌｙｒｉｍｏｋｉｔ」（製品名「ＬｙｒｉｍｏＫｉｔ１．０．０」）として製造、使用されているプログラム以上
別紙４－１、別紙４－２、別紙４－３、別紙５－１、別紙５－２、別紙５－３、別紙６－１、別紙６－２、別紙６－３
省略
出典：裁判所ウェブサイト「裁判例検索」（https://www.courts.go.jp/hanrei/97005/detail7/index.html）。本文は同サイト掲載の判決書PDFからTaiLexi AIがテキスト化・整形したもの（正確な文言は原本PDFを参照）。判示事項・裁判要旨・参照法条は裁判所の公表どおり。