【知財高判平成29年12月21日平29(ネ)10027号[金融商品取引管理装置事件・控訴審]】

【要旨】
 本判決は、ソフトウェア特許の侵害訴訟において、特許権者が勝訴した事例である。

【キーワード】
ソフトウェア特許、充足論、特許発明の技術的範囲、特許請求の範囲基準の原則、明細書参酌の原則、特許法70条

1 事実関係等

原審である東京地判平成29年2月10日平28(ワ)4461号を参照。

2 判旨

⑴ 控訴人の主張

(1) 被告サービス1が本件発明1の技術的範囲に属すること
ア 構成要件1Bについて
(ア) 原判決の誤り
a 原判決は,被告サービス1では,値幅情報及び利幅情報を売買注文申込情報として入力する欄がないから,値幅情報及び利幅情報を売買注文申込情報として受信して受け付けていない,と認定する。
 しかし,本件発明1において「値幅を示す情報」及び「利幅を示す情報」は,「金融商品管理システム」が「受信して受け付ける」と規定されているのであり,顧客が画面上で入力するか否かは問題とされていないのであるから,値幅情報及び利幅情報を売買注文申込情報として入力する欄がないことは,値幅情報及び利幅情報を売買注文申込情報として受信して受け付けていないことの根拠となるものではない。
b 原判決は,被告サービス1について,④「想定変動幅」及び⑥「対象資産(円)」の数値を見ただけで直ちに値幅及び利幅が分かるということにはならないから,④「想定変動幅」及び⑥「対象資産(円)」の数値自体が「値幅を示す情報」及び「利幅を示す情報」に該当するというのは困難である,と認定している。
 しかし,本件発明1は「金融商品取引管理システム」における金融商品取引管理方法に関するものであり,「値幅を示す情報」「利幅を示す情報」を受信して受け付けて,これに基づいて注文情報群を生成するのは「金融商品取引管理システム」である。したがって,本件発明1における「示す」とは,「値幅を示す情報」「利幅を示す情報」を利用する「金融商品取引管理システムに対して」,値幅及び利幅を「わからせる,表示する,意味する」と解釈されるべきことは明らかであって,「人間に対して」値幅及び利幅を分からせても,意味がない。そうすると,本件発明1の「値幅を示す情報」の解釈として,値幅が顧客に対して画面上で表示されているか否か,並びに,顧客が値幅及び利幅を理解することができるか否かを問題とする余地はない。
(イ) 被告サービス1における「値幅を示す情報」及び「利幅を示す情報」
a 被告サービス1においては,「計算」ボタンをクリックすると,④「想定変動幅」と⑥「対象資産(円)」の条件から瞬時に,値幅(甲7では50銭)が算出されており,この算出された値幅に基づいて,新規指定レートや利食いレートが設定されている。したがって,被告サービス1において,被告サーバが「値幅を示す情報」及び「利幅を示す情報」に当たる「50銭」という情報を「受信して受け付け」ている。
b 値幅や利幅を「示す」というのが,「顧客に対して」利幅や値幅を分からせるものであるとしても,「受信して受け付ける」情報は,顧客が画面上で入力した情報に基づいて演算された情報であってもよい。④「想定変動幅」と⑥「対象資産」から演算された値幅や利幅そのものが,甲7の画面02に表示されているから,被告サービス1は,構成要件1Bを充足する。
c 「受信して受け付ける」というのが,顧客が画面上において入力する態様に限定されるとしても,④「想定変動幅」及び⑥「対象資産(円)」が,被告サービスにおける「値幅を示す情報」」「利幅を示す情報」であるといえるから,被告サービス1は,構成要件1Bを充足する。

⑵ 被控訴人の主張

(1) 「被告サービス1が本件発明1の技術的範囲に属すること」について
ア 構成要件1Bについて
(ア) 本件明細書等1においては,顧客が「値幅を示す情報」及び「利幅を示す情報」を含む五個の情報を入力する実施例のみが開示されていることから,これら五個の情報は,顧客が入力するものでなければならない。
 「示す」とは,「物事が見る人・聞く人にある事柄をわからせる。表示する。意味する。」という意味であるから,人間である顧客が「値幅を示す情報」及び「利幅を示す情報」を含む五つの情報を入力したといえるためには,入力した情報が「金融商品取引管理システム」によって,どのような情報として受け付けられるのかを分かる必要がある。被告サービス1における④「想定変動幅」及び⑥「対象資産(円)」は「値幅を示す情報」又は「利幅を示す情報」に当たらない。「想定変動幅」とは「通貨ペア」の為替レートの変動幅の予測値を表示・入力する欄にすぎず,⑥「対象資産(円)」とは取引に使用する資産(日本円)を入力する欄にすぎないから,そのような二つの値から値幅及び利幅を理解することができない。
(イ) 構成要件1Bの「前記金融商品の売買注文を行うための売買注文申込情報として受け付け」られる五個の情報は,「金融商品取引管理システム」に入力されるものであるから,「金融商品取引管理システム」の外部にあるものでなければならない。入力された情報に基づき,何らかの算定式等に基づいて,「金融商品取引管理システム」の内部で生成された情報は,外部からの入力に係る情報ではない。したがって,仮に,被告サービス1において,入力された六個の情報に基づき,入力後に値幅及び利幅に相当する数値が算定可能であるとしても,それは,入力に係る情報を規定する構成要件1Bの「値幅を示す情報」「利幅を示す情報」に当たらない。このことは,構成要件1Cにおいて,「該注文入力受付手順によって受け付けられた前記売買注文申込情報に基づいて,・・・前記金融商品の注文情報を生成する注文情報生成手順と,」と規定されていることからみて,なお一層明らかである。すなわち,「売買注文申込情報」は,「注文情報を生成する」のに先立って存在するので,いったん「注文情報」が生成され,そこから遡って「売買注文申込情報」を導き出し得たとしても,それは,構成要件1Bの「値幅を示す情報」「利幅を示す情報」及び構成要件1Cの充足性を論じる上で,何ら意味をなさない。顧客が画面上で入力した情報に基づいて演算された情報は,本件発明1においては構成要件1Cで演算処理されるのであるから,演算結果である情報をもって構成要件1Bの充足性を問題にすることはできない。
 被告サービス1では,「注文情報群」を算出するに当たり,対象の通貨を所定の価格で買(売)った後,相場が予想に反して変動した場合に,追加で対象の通貨を買う(売る)場合の値幅情報及び利幅情報を売買注文申込情報として入力する欄はないから,値幅情報及び利幅情報を売買注文申込情報として受信して受け付けてはいないというべきである。
(ウ) 本件発明1と被告サービス1は,金融商品の相場変動を正確に予測することができなくてもFX取引による所望の利益を得るという課題を,顧客に利幅及び値幅という専門的な知識が必要である情報を入力させることで解決するか,それともこれらの情報を入力させないまま解決するかという課題解決原理の違いがあり,作用効果が異なる重大な考慮要素である。利幅及び値幅を含む情報を顧客に入力させなくてもよいという解釈は,本件発明1の課題解決原理を無視するものである。
(エ) 被告サービス1は,画面1において,顧客が①~⑥の情報を入力し,「計算」アイコンを押すと,画面2に遷移する。

 画面2において,⑧の情報は,強いていえば,買いの指値価格及び売りの指値注文のペアとなり得る存在として,注文情報群に相当し得る。しかし,画面2の⑧の情報において,顧客が自由に注文情報を変更することができて,しかも,それらの変更は,⑧の情報全体に影響を及ぼすものではない。

 画面2において,顧客が⑧の情報を適宜修正してから「注文」ボタンを押すことによって,取引が開始される。したがって,被告サービス1が提案した⑧の情報に対し,顧客による適宜の修正が加わった後,最終的に注文情報群となるのは,顧客が⑧「注文情報群」欄に入力したものということになる。
 構成要件1Cにおいて,「金融商品取引管理システム」が演算した「注文情報群」をそのまま使用する本件発明1と異なり,被告サービス1は,最終的に,顧客が注文情報群を入力するので,この意味において,被告サービス1は,構成要件1B及び1Cを充足しない。

⑶ 判旨

2  被告サービス1について
(1)  争点(1)ア(構成要件1Bの「値幅を示す情報」の充足性)及び同イ(構成要件1Bの「利幅を示す情報」の充足性)について
ア 被告サービス1の認定
 証拠(甲7,乙4)及び弁論の全趣旨によると,被告サービス1は,以下のとおりのものと認定することができる。
(ア) 被控訴人のウェブサイトで,「サイクル注文」を選択すると,「新規注文入力」と題する画面1が表示される。画面1では,顧客は,①「通貨ペア」,②「注文種類」,③「参考期間」,④「想定変動幅」,⑤「ポジション方向」及び⑥「対象資産(円)」の各情報を入力し,その後に同画面の「計算」ボタンをクリックすると,別の「新規注文入力」と題する画面2に遷移する。
(イ) 画面2においては,画面1で顧客が入力した情報に基づく計算結果が,注文数,値幅,並びに,新規指定レート及び利食いレートを持つ複数の注文情報群として示される。各注文情報群の新規指定レートと利食いレートとの差は等しい。各注文情報群の新規指定レート及び利食いレートは,顧客において変更することができ,新規指定レート又は利食いレートを変更した場合,一の高値側の新規指定レートの値と一つ安値側の利食いレートの値は連動して変化するが,それ以外の新規指定レート及び利食いレートが自動的に変更されることはない。また,顧客は,画面2の「数量」入力欄に,注文希望数を,金額に相当する単位で入力する。顧客が画面2の「注文」ボタンをクリックすると,取引が開始する。顧客は,画面2の「戻る」ボタンをクリックして画面1に戻って前記①~⑥の情報を再入力することや,画面2の「キャンセル」ボタンをクリックして,注文をしないこととすることもできる。
(ウ) 上記の新規指定レート及び利食いレートを持つ複数の注文情報群は,新規指定レートのうち一番先頭の価格を最高価格としてより安値側にした複数の新規指定レートと利食いレートのうち一番先頭の価格を最高価格としてより安値側にした複数の利食いレートから成り,これら複数の新規指定レートと複数の利食いレートとは互いに売りと買いの関係にある。
(エ) 上記の複数の注文情報群は,取引のため金融商品取引管理システムに一旦格納されることとなる。
(オ) 取引が開始した後は,画面2で表示された複数の注文情報群全てにおいて,例えば,第一注文が買い注文で第二注文が売り注文である場合,それぞれの注文情報群の買い注文は注文中,売り注文は待機とされ,ある注文情報群の買い注文が成約すれば,対応する売り注文が注文中とされ,売り注文が成約すれば,同一注文情報群の買い注文が再び注文中とされ,約定と注文が繰り返される構成となっている。
(カ) 以上のとおり,被告サービス1は,あらかじめ指定した変動幅の中で,複数のイフダン注文を一度に同時発注し,決済成立後,あらかじめ指定した変動幅の範囲で成立した決済注文と同条件のイフダン新規注文をシステムが自動的に繰り返し発注する連続注文機能を有するものである。
イ 「値幅を示す情報」及び「利幅を示す情報」の充足性
 上記認定によると,顧客は,画面2において,複数の注文同士の「値幅」を認識し,新規指定レートと利食いレートとの差から「利幅」を認識し,必要に応じて変更を加えた上で,「戻る」ボタンや「キャンセル」ボタンをクリックして注文しないことを選択できるにもかかわらず,「注文」ボタンをクリックして画面2において示された値幅及び利幅による注文情報群の注文をすることができるのであるから,顧客が「値幅を示す情報」及び「利幅を示す情報」を売買注文申込情報として入力し,被告サービス1はこれを受信して受け付けているものと認めるのが相当である。
ウ 構成要件1Bの充足性
 「画面2」において示され「注文」ボタンをクリックすることによって送られる情報のうち,「通貨ペア」,「数量」,及び「新規指定レートのうち一番先頭の価格」が,それぞれ,構成要件1Bにおける,「売買を希望する前記金融商品の種類を選択するための情報」,「前記金融商品の売買注文における,注文価格ごとの注文金額を示す情報」,及び「前記金融商品の販売注文価格又は購入注文価格としての一の注文価格を示す情報」に相当するといえ,これらの情報はいずれも売買注文に用いられるから,「金融商品の売買注文を行うための売買注文申込情報」であるといえる。
 以上より,被告サービス1は,本件発明1の構成要件1Bを充足することになる。
エ 被控訴人の主張について
(ア) 被控訴人は,本件明細書等1においては,顧客が「値幅を示す情報」及び「利幅を示す情報」を含む五個の情報を入力する実施例のみが開示されていることから,これら五個の情報は,顧客が入力するものである,と主張する。
 しかし,構成要件1Bは,顧客が各情報を,プルダウンメニューから選択したり,キーボードで数字を打ち込んだりすることを要件としていないから,これらの操作と,画面上に示された情報を確認して実行することとを区別する理由はない。
(イ) 被控訴人は,人間である顧客が「値幅を示す情報」及び「利幅を示す情報」を含む五つの情報を入力したといえるためには,入力した情報が「金融商品取引管理システム」によって,どのような情報として受け付けられるのかを分かる必要があるところ,被告サービス1ではそのような構成になっていない旨主張する。
 しかし,上記認定のとおり,顧客は,被告サービス1の画面2において,画面2に表示された値幅及び利幅における注文をすることを決定して,「注文」ボタンをクリックするものであるから,被告サービス1において,顧客は,自ら望み具体的に認識した値幅及び利幅が,「値幅を示す情報」及び「利幅を示す情報」として「金融商品取引管理システム」に受け付けられることを認識しているといえる。
(ウ) 被控訴人は,「値幅を示す情報」及び「利幅を示す情報」は,「金融商品取引管理システム」に入力されるものであるから,「金融商品取引管理システム」の外部にあるものでなければならない,と主張する。
 しかし,被告サービス1においては,値幅と利幅が,「金融商品取引管理システム」の内部で何らかの算定式等に基づいて生成された情報であっても,情報が生成されれば直ちに売買注文申込情報となるのではなく,顧客が「注文」ボタンをクリックして初めて,売買注文申込情報として受け付けられるものである。このような値幅及び利幅について,「金融商品取引管理システム」の内部で生成された情報であることを理由に,「値幅を示す情報」「利幅を示す情報」に該当しないということはできない。
(エ) 被控訴人は,本件発明1においては,「売買注文申込情報」は,「注文情報を生成する」に先立って存在するので,いったん「注文情報」が生成され,そこから遡って「売買注文申込情報」を導き出し得たとしても,それは,構成要件1Bの「値幅を示す情報」及び「利幅を示す情報」並びに構成要件1Cの充足性を論じる上で,何ら意味をなさない,と主張する。
 しかし,被告サービス1において,実際に注文される場合の売買注文申込情報は,画面2で顧客が「注文」ボタンをクリックしたときに入力され,受信して受け付けられ,後記(2)のとおり,その後,注文情報が生成される。顧客が①~⑥の情報を入力して画面1で「計算」ボタンをクリックしてから生成される情報は,あくまでも売買注文申込情報を生成するに当たってのいわば参考情報にすぎないものと解される。
(オ) 被控訴人は,被告サービス1では,「注文情報群」を算出するに当たり,対象の通貨を所定の価格で買(売)った後,相場が予想に反して変動した場合に,追加で対象の通貨を買う(売る)場合の値幅情報及び利幅情報を売買注文申込情報として入力する欄はないから,値幅情報及び利幅情報を売買注文申込情報として受信して受け付けてはいないというべきである,と主張する。
 しかし,構成要件1Bには,対象の通貨を所定の価格で買(売)った後,相場が予想に反して変動した場合に,追加で対象の通貨を買う(売る)場合の値幅情報を入力することは規定されていないから,そのような構成を有しないとしても,構成1Bの充足性が左右されることはない。
(カ) 被控訴人は,本件発明1と被告サービス1は,金融商品の相場変動を正確に予測することができなくてもFX取引による所望の利益を得るという課題を,顧客に利幅及び値幅という専門的な知識が必要である情報を入力させることで解決するか,それともこれらの情報を入力させないまま解決するかという課題解決原理の違いがあり,利幅及び値幅を含む情報を顧客に入力させなくてもよいという解釈は,本件発明1の課題解決原理を無視するものである,と主張する。
 しかし,本件発明1は,上記課題を複数の注文情報群を繰り返し実行することによって解決したものであり,被告サービス1もこの構成をとるものである。それに加えて,被告サービス1は利幅及び値幅を含む情報を顧客に入力させなくてもよいという構成をとることにより,より上記課題解決を進めたものということができるとしても,この点をもって,被告サービス1が本件発明1の技術的範囲に属しないということはできない。
(キ) 被控訴人は,構成要件1Cにおいて,「金融商品取引管理システム」が計算した注文情報群をそのまま使用する本件発明1と異なり,被告サービス1は,最終的に,顧客が注文情報群を入力するので,この意味において,被告サービス1は,構成要件1B及び1Cを充足しない,と主張する。
 しかし,上記(エ)のとおり,顧客が①~⑥の情報を入力して画面1で「計算」ボタンをクリックしてから生成される情報は,あくまでも参考情報にすぎず,被告サービス1においては,画面2で顧客が「注文」ボタンをクリックしたときに売買注文申込情報が受信して受け付けられ(構成要件1B),後記(2)アのとおり,その後,注文情報が生成される(構成要件1C)のであるから,構成要件1B及び1Cを充足する。

(2) 争点(1)ウ(構成要件1C,1E,1F,1G及び1Hの充足性)について
ア 構成要件1Cについて
 前記(1)のとおり,被告サービス1における取引は,「画面2」に表示された,新規指定レート及び利食いレートを持つ複数の注文情報群を,顧客が確認した上で,「注文」ボタンをクリックすることで開始されることから,実際の注文に用いられる注文情報は,「画面2」において顧客によって「注文」ボタンをクリックした後,すなわち,構成要件1Bに係る手順の後に,「注文」ボタンのクリックによって受信して受け付けられた売買注文申込情報に基づいて生成されるものと解される。
 以上より,被告サービス1は,本件発明1の構成要件1Cを充足する。

3 検討

⑴ 本控訴審判決は、構成要件1Bの「値幅を示す情報」及び「利幅を示す情報」について、明細書の実施例(値幅入力欄44cや利益金額指定欄44e)よりも広い解釈を示している。しかし、「値幅を示す情報」及び「利幅を示す情報」は抽象的な記載であり、また、明細書には、一の実施例しか記載されておらず、明細書には、実施例の記載を広げるような記載がないことからすると、特許法70条第2項に基づき、特許請求の範囲は、明細書の実施例に対応する事項がクレーミングされていると解釈されるように思える。少なくとも、従前のソフトウェア特許の侵害訴訟におけるクレーム解釈の傾向に沿うか否かという観点では、原審にあたる東京地判平成29年2月10日平28(ワ)4461号の方が、従前の裁判例の傾向に沿うものと考えられる。

⑵ また、構成要件1Cとの関係を踏まえても、控訴審判決の構成要件1Bを充足するとの判断には疑問は残る。すなわち、構成要件1Cの「注文情報」は、図5(b)における「注文情報群45c1,45c2,・・・45ck」の買い注文情報又は売り注文情報に対応することから、図5(b)のように45aの注文ボタンにより注文される際に供される情報が、構成要件1Cの「注文情報」であると考えられる。被告サービス1において、注文ボタンにより注文される際に供される情報は、画面2に表れていることになるところ、画面②の⑧「注文情報群」が構成要件1Cの「注文情報」に対応すると考えられる。そうすると、画面2において、⑧「注文情報群」が生成される前に(つまり画面1において)、売買注文申込情報が受け付けられていないといけないにもかかわらず、控訴審判決は、画面2において「顧客が『値幅を示す情報』及び『利幅を示す情報』を売買注文申込情報として入力」していると認定していることから、構成要件1Bと構成要件1Cとの前後関係を踏まえると、画面2を根拠に構成要件1Bを充足するという認定には無理があるように思える。この点について、控訴審判決は、「被告サービス1において,実際に注文される場合の売買注文申込情報は,画面2で顧客が『注文』ボタンをクリックしたときに入力され,受信して受け付けられ,後記(2)のとおり,その後,注文情報が生成される。顧客が①~⑥の情報を入力して画面1で『計算』ボタンをクリックしてから生成される情報は,あくまでも売買注文申込情報を生成するに当たってのいわば参考情報にすぎないものと解される。」、また、「後記(2)」として、「『画面2』において顧客によって『注文』ボタンをクリックした後,すなわち,構成要件1Bに係る手順の後に,『注文』ボタンのクリックによって受信して受け付けられた売買注文申込情報に基づいて生成される」と認定するが、構成要件1Cの「注文情報」が、画面2の⑧「注文情報群」であるか否かという点は全く考慮しておらず、画面2を根拠に構成要件1Bを充足するという根拠としては不十分であるように思える。

⑶ 本件発明が、トラップリピートイフダン取引を実現するシステム一般を保護する技術的思想であることを前提とする記載が明細書にあるのであれば、実施例の範囲を超えて、権利範囲を認めることも可能であると思われるが、判決では本件発明がかかる技術的思想を保護するものであるとの検討は見られず、実施例を超えた権利範囲とすることの根拠も脆弱であるように思える。

⑷ 以上のように、本控訴審判決は、従前のソフトウェア特許の侵害訴訟の充足性の判断と比べると、異なる傾向にあると考えられるが、特許請求の範囲及び明細書の記載かからすると、本控訴審判決は、特異な判決と思われる。そのため、今後、同じような傾向の裁判例が続くとは考えい難いと考えられる。

以上
(文責)弁護士・弁理士 杉尾雄一