2020年2月20日木曜日

侵害訴訟 特許  平成30(ワ)12609  東京地裁 請求認容

事件名
 特許権侵害差止請求事件
裁判年月日
 令和元年10月9日
裁判所名
 東京地方裁判所民事第29部 
裁判長裁判官  山    田    真    紀 
裁判官   神    谷    厚    毅  
裁判官  西    山    芳    樹

「⑴  争点1-1(本件アプリは構成要件1Bを充足するか)について 
  ア  構成要件1Bに対応する本件アプリの構成に係る事実認定
(ア)  前記第2の2⑸ア(ア)のとおり,本件アプリは,スピーカー等の放音装置から,識別情報であるIDコードを表す音響IDを含む音響が放音されると,これを収音し,当該音響IDからIDコードを検出するものとしてスマートフォンを機能させるものであるところ,前記2⑴のとおり,本件広告には,「映像・音声にのせ て」,「動画・音楽などの音」に埋め込んで,「映像・音声に重畳」させて音響IDを放音することが記載されているほか,使用例の一つとして,バスの車内案内では多言語で停留所情報等を提供することができることが記載されていること,同⑵のとおり,本件ダウンロードサイトには,本件アプリは,空港,駅,電車,バス等に設置された放音装置から送信された音波を,スマートフォンで受信することで, 関連する情報を自動で表示させることのできるサービスを提供するものであることが記載されていることなどからすると,被告から音響IDの提供を受けた顧客において,案内音声を識別するものとしてIDコードを使用し,これを案内音声とともに放音装置から放音することは,本件アプリにつき想定されていた使用形態の一つであるというべきである。そうすると,本件アプリは「案内音声と当該案内音声を識別するIDコードを含む音響IDとを含有する音響を収音し,当該音響からIDコードを抽出する情報抽出手段」(構成1b)を備えていると認めるのが相当である。
(イ) 被告は,本件アプリが構成1bを備えていることを否認し,その理由として,①被告サービスにおいて,被告は,放音される音響やIDコードの識別対象を決定しておらず,これらを選択,決定しているのは顧客であって,いずれも「案内音声」に限られるものではないこと,②本件アプリの利用場面の中で,最も多くの需要が見込まれているのは商品説明の場合であるが,商品説明において,放音装置から音声が発せられることは必須ではなく,かえって,音声が放音されるとスマートフォンに表示される情報を理解する妨げになることを主張する。
  しかしながら,被告の上記①の主張は,構成要件1B所定の音響が放音されない 場合があることを指摘するにとどまるものであり,前記(ア)のとおり,本件広告においても,案内音声を収音する使用形態を回避させるような記述はなく,むしろ,そのような使用形態を想定したものとなっていたというべきであるから,前記認定を覆すに足りないというべきである。
 また,被告の上記②の主張について,本件アプリにつき最も多くの需要が見込ま れていたのが商品説明の場面であったとしても,被告において,そのような使用形態に特化したものとして本件アプリを広告宣伝していたものでもなく,前記認定を覆すに足りない。
  イ  構成要件1Bに係るあてはめ
 以上の認定を踏まえて検討すると,構成1bの「案内音声」は,本件発明1の 「案内音声である再生対象音を表す音響信号」に対応し,構成1bの「案内音声を識別するIDコードを含む音響ID」は,本件発明1の「案内音声である再生対象音の識別情報を含む変調信号とを含有する音響信号」に対応する。
 そして,本件発明1は,コンピュータを所定の手段として機能させるプログラムに係る発明であり,構成要件1Bは,放音された所定の音響を収音した収音信号か ら識別情報を抽出する情報抽出手段を規定するものであるから,構成要件1B所定の音響が放音された場合に,これを収音し,識別信号を抽出する手段としてコンピュータを機能させるプログラムであれば,これと異なる用途でコンピュータを機能させ得るとしても,又は音響が放音されない場面があるとしても,同構成要件を充足すると解すべきところ,本件アプリは,同所定の音響を収音し,当該音響からIDコードを抽出するものとしてスマートフォンを機能させるものであるから,放音される音響やIDコードの識別対象を選択しているのが顧客であり,音響が放音されない使用方法が選択され得るとしても,構成要件1Bを充足する。 

  ⑵  争点1-2(本件アプリは構成要件1Dを充足するか)について
ア  構成要件1Dの「関連情報」の言語の解釈
(ア) 構成要件1Dは,「関連情報」について,「前記案内音声である再生対象音の発音内容を表す関連情報であって,前記情報要求に含まれる識別情報に対応するとともに相異なる言語に対応する複数の関連情報のうち,前記情報要求の言語情報で指定された言語に対応する関連情報」と規定しているから,「関連情報」の言語は,相異なる言語に対応するものの中から情報要求の言語情報で指定された言語に対応するものと解すべきである。 
(イ) 被告は,「関連情報」は,第1言語で発音される案内音声の発音内容を第1言語で表した文字列であると解すべきであるとし,その理由として,原告が本件訂正審判請求1の際に訂正事項が明細書の記載事項の範囲内であることを示す根拠として本件明細書1の【0041】を挙げていたことを指摘するが,構成要件1Dは上記のとおりのものであるから,「関連情報」が案内音声の言語と同一のものであ ると解するのは文言上無理がある。また,同段落には,第2言語に翻訳することなく,第1言語の指定文字列のまま関連情報Qとする実施例が開示されているが,これは第1実施形態の変形例の一つ(態様1)にすぎず,原告が本件訂正審判請求1の際に同段落を指摘したからといって,当該実施例の態様に限定して「関連情報」の言語について解釈するのは相当でない。 
  イ  構成要件1Dに対応する本件アプリの構成に係る事実認定
(ア)  前記第2の2⑸ア(ウ)及び同イのとおり,本件アプリは,管理サーバから,リクエスト情報に含まれるIDコード及びアプリ使用言語の情報に対応する情報の所在を示すものとして送信されるアクセス先URLを受信するものとしてスマートフォンを機能させるものであり,管理サーバには,1個のIDコードに対応させて,6個までのアプリ使用言語に対応するURLを記憶することができるところ,前記2⑴のとおり,本件広告には,日本語のほか,英語,中国語,台湾語,韓国語,ロシア語など多言語で情報配信できることが記載されており,使用例の一つとして,バスの車内案内では多言語で停留所情報等を提供することができることが記載されていること,同⑵のとおり,本件ダウンロードサイトには,外国人観光客に対して,空港・駅等のアナウンスに関連する情報を多言語で情報提供する用途に用いることができることが記載されていることなどからすると,顧客において,リクエスト情報に含まれるIDコードに対応する案内音声の発音内容を表す情報について,当該案内音声とは異なる言語に対応する複数の情報を管理サーバに記憶させ,リクエスト情報に含まれるアプリ使用言語に対応する情報をスマートフォンに送信するようにすることは,本件アプリにつき想定されていた使用態様の一つであるというべき である。そうすると,本件アプリは,「前記案内音声の発音内容を表す関連情報であって,前記リクエスト情報に含まれるIDコードに対応するとともに,6個までのアプリ使用言語に対応する複数の情報のうち,前記リクエスト情報のアプリ使用言語に対応する情報を受信する受信手段」(構成1d)を備えていると認めるのが相当である。 
  (イ) 被告は,本件アプリが構成1dを備えていることを否認し,その理由として,①被告サービスにおいて,被告は,本件スマートフォンが受信する情報を決定しておらず,これを選択,決定しているのは顧客であって,構成要件1D所定のものに限られないこと,②被告は,本件アプリに係る実証実験において,本件アプリを用いて「案内音声である再生対象音の発音内容」を関連情報として出力したことはな く,外国語に翻訳した内容を関連情報として出力したこともないこと,③被告は,今後,顧客に対し,案内音声である再生対象音の発音内容を表す他国語の関連情報を提供することを禁ずる旨の約束をする意思があることを主張する。
  しかしながら,被告の上記①の主張は,本件スマートフォンの受信する情報が構成要件1D所定の情報ではない場合があることを指摘するにとどまるものであり,前記(ア)のとおり,本件広告及び本件ダウンロードサイトにおいても,案内音声の 発音内容を表し,リクエスト情報に含まれるアプリ使用言語に対応する情報を受信する使用形態を回避させるような記述はなく,むしろ,そのような使用形態を想定したものとなっていたというべきであるから,被告の実証実験では同構成要件所定の情報を受信しなかったこと(上記②),被告が今後も同構成要件所定の使用態様で本件アプリを使用しないことを約束する意思を有していること(上記③)を併せ考慮しても,前記認定を覆すに足りないというべきである。
  ウ  構成要件1Dに係るあてはめ
  構成要件1Bにおいて規定するとおりにコンピュータを機能させるものであれば,同構成要件を充足するとの前記⑴イにおける検討と同様に,構成要件1D所定の情報を受信する手段としてコンピュータを機能させるプログラムであれば,受信する情報が同構成要件所定のものではない場面があるとしても,同構成要件を充足すると解すべきところ,本件アプリは,構成1dを備えており,スマートフォンを「前記案内音声の発音内容を表す関連情報であって,前記リクエスト情報に含まれるIDコードに対応するとともに,6個までのアプリ使用言語に対応する複数の情報のうち,前記リクエスト情報のアプリ使用言語に対応する情報を受信する受信手段」として機能させるものであるから,本件スマートフォンが受信する情報を選択しているのが顧客であるとしても,構成要件1Dを充足する。 」
 
【コメント】
 本件は,特許番号第5871088号,発明の名称を「端末装置,情報提供システム,情報提供方法およびプログラム」とする特許権(訴訟ではもう1つ特許がありましたが,そちらは省略)を有する原告(ヤマハ)が, 「Sound Insight」 及び「サウンドインサイト防災」 というアプリ(本件アプリ)の作成やダウンロード配信をしていた被告に対し,特許権侵害を主張し差止を求めた,特許権侵害訴訟の事件です。
 
 これに対して,東京地裁民事29部の山田部長の合議体は,請求のすべてを認容しました(つまりは特許権侵害を認めたわけです。)。

 まずは,クレームからです。
1A  コンピュータを, 
1B  案内音声である再生対象音を表す音響信号と当該案内音声である再生対象音の識別情報を含む変調信号とを含有する音響信号に応じて放音された音響を収音した収音信号から識別情報を抽出する情報抽出手段,
1C  前記情報抽出手段が抽出した識別情報と,当該端末装置にて指定された言語を示す言語情報とを含む情報要求を送信する送信手段,
1D  前記案内音声である再生対象音の発音内容を表す関連情報であって,前記情報要求に含まれる識別情報に対応するとともに相異なる言語に対応する複数の関連情報のうち,前記情報要求の言語情報で指定された言語に対応する関連情報を受信する受信手段,および,
1E  前記受信手段が受信した関連情報を前記案内音声の放音とともに出力する出力手段 
1F  として機能させるプログラム。
 
 明細書の図1はこんな感じです。 
 
 どういうやつかといいますと,従来美術館とかの多言語案内は,電波やら赤外線でやってたのので,専用の受信機等が必要だった,でも今回は音にしたので,そこはクリア,そしてスマホ経由で多言語の案内の表示をそのスマホに送る,というようなやつです。
 
 ヤマハぽいプログラムクレームだと思いますね。
 
 他方,被告アプリですが,こういうようなものでした。
ア  本件アプリは,スマートフォンにインストールされて利用されるアプリケーションであり,被告が提供するサービス(以下「被告サービス」という。)において,本件スマートフォンを次のように機能させるプログラムである。
(ア) スピーカー等の放音装置から,識別情報であるIDコードを表す音響IDを含む音響が放音されると,これを収音し,当該音響IDからIDコードを検出する。 
(イ) 検出されたIDコード及びアプリ使用言語の情報を含むリクエスト情報を作成し,被告が管理するサーバ(以下「管理サーバ」という。)に送信する。
(ウ) 管理サーバから,リクエスト情報に含まれるIDコード及びアプリ使用言語の情報に対応する情報の所在を示すものとして送信されるアクセス先URLを受信する。 
(エ) 上記アクセス先URLに係るサーバにアクセスして情報を取得し,これをブラウザに表示して出力する。
  イ  被告サービスにおいて,被告から音響IDの提供を受け,放音装置から音響IDを含む音響を放音し,IDコード及びアプリ使用言語の情報に対応するURLを決定し,管理サーバにその対応関係を記憶しているのは,被告と契約を締結した 被告の顧客(以下,単に「顧客」という。)であり,顧客は,1個のIDコードに対応させて,6個までのアプリ使用言語に対応する各URLを管理サーバに記憶することができる。

 2015/11/19のニュースリリースの図だと以下のようなものです。
  
  
  うーん,くりそつです。
 しかし,本件の優先日が,2014.10.24なので何か惜しい所です。アイデアレベルでは結構昔からあったのかもしれません。
 
 さて,本件も特筆すべきところがあります。
 プログラムのクレームで侵害を認めており,しかもソースコードの解析をした形跡がありません。 

 これはクレームの作り方がうまかったのではないかと思います。プログラムクレームなのに,・・ステップ等がありません!
 そうではなく,システム(物)のクレームのようになっており,最後に,F「・・・として機能させるプログラム」 と結んでおります。
 実に狡猾であり,大手の企業がソースコード分からなくても何とかなるようにしよう・・・と頭をフル回転したのではないでしょうか。実に見習うべきことだと思えます。