【事件の表示】
　特許第６６８０９４３号発明「金融取引処理装置及びプログラム」の特許異議申立事件について、次のとおり決定する。
【結　論】
　特許第６６８０９４３号の請求項１ないし４に係る特許を維持する。
【理　由】
第１　手続の経緯 
　特許第６６８０９４３号の請求項１〜４に係る特許についての出願は、令和元年１１月２６日に特許出願され、令和２年３月２４日にその特許権の設定登録がされ、令和２年４月１５日に特許掲載公報が発行された。その後、その特許に対し、特許異議申立人　栗暢行（以下、申立人という。）により特許異議の申立てがされたものである。 
第２　本件発明 
　特許第６６８０９４３号の請求項１〜４の特許に係る発明は、それぞれ、その特許請求の範囲の請求項１〜４に記載された事項により特定される以下のとおりのものである。（以下、それぞれ、本件発明１などという。Ａ〜Ｊなどの符号は申立人が付与した符号を援用した。）
【請求項１】
Ａ．ネットワークを介し顧客から金融取引のための取引口座の口座開設要求を受け付ける受付部と、
Ｂ．前記取引口座を開設するための本人確認資料の提出方法を前記顧客に選択させ、前記選択された提出方法に対応する画面を前記顧客に表示する画面制御部と、
を有し、
Ｃ．前記画面制御部は、前記顧客について保持されている前記本人確認資料の有効性を前記本人確認資料の記載事項に基づき確認し、前記本人確認資料が有効でない場合、有効な本人確認資料を提出させる画面を表示する
Ｄ．金融取引処理装置。
【請求項２】
Ｅ．前記画面制御部は、前記本人確認資料をアップロードにより提出する第１の提出方法と、前記本人確認資料を郵送により提出する第２の提出方法との何れか一方を前記顧客に選択させる、請求項１記載の金融取引処理装置。
【請求項３】
Ｆ．前記画面制御部は、前記顧客について登録済みの顧客情報に基づき、前記取引口座を開設するために必要な前記本人確認資料の種別を特定し、前記特定した種別の本人確認資料を提出させる画面を前記顧客に表示する、請求項１又は２記載の金融取引処理装置。
【請求項４】
Ｇ．ネットワークを介し顧客から金融取引のための取引口座の口座開設要求を受け付ける処理と、
Ｈ．前記取引口座を開設するための本人確認資料の提出方法を前記顧客に選択させ、前記選択された提出方法に対応する画面を前記顧客に表示する処理と、
をコンピュータに実行させ、
Ｉ．前記表示する処理は、前記顧客について保持されている前記本人確認資料の有効性を前記本人確認資料の記載事項に基づき確認し、前記本人確認資料が有効でない場合、有効な本人確認資料を提出させる画面を表示する
Ｊ．プログラム。
第３　申立理由の概要 
　申立人は、概略以下のとおり主張している。
（ア）特許法第２９条第１項第３号の規定に違反している旨の主張について 
（ア−１）証拠として 
１）特開２０１４−２１７６５号公報（以下「甲１」という。） 
を提出し、請求項１〜４に係る特許は、甲１に記載された発明であるから、特許法第２９条第１項第３号の規定に違反してされたものであり、請求項１〜４に係る特許を取り消すべきものである旨の主張。
（ア−２）証拠として 
５）国際公開第２００７／０１８２３３号の再公表特許（以下「甲５」という。） 
を提出し、請求項１〜４に係る特許は、甲５に記載された発明であるから、特許法第２９条第１項第３号の規定に違反してされたものであり、請求項１〜４に係る特許を取り消すべきものである旨の主張。
（イ）特許法第２９条第２項の規定に違反している旨の主張について
　証拠として、甲１、甲５に加えて
２）特開２０１２−３３００３号公報（以下「甲２」という。）
３）国際公開第２０１８／０８８４７５号（以下「甲３」という。） 
４）特開２００７−２９３５９８号公報（以下「甲４」という。）
を提出し、
（イ−１）請求項２に係る特許は、甲５を主たる引例として、甲５に記載された発明に周知の技術（甲１、甲３、甲５の記載参照）を適用することにより、当業者が容易に発明をすることができたものである、
（イ−２）請求項３に係る特許は、甲１を主たる引例として、甲１に記載された発明に周知の技術（甲３、甲４の記載参照）を適用することにより、当業者が容易に発明をすることができたものである、
　から特許法第２９条第２項の規定に違反してされたものであり、請求項２、３に係る特許を取り消すべきものである旨の主張。 
（ウ）特許法第１７条の２第３項に規定する要件を満たしていない旨の主張について
　本件特許についての出願は、令和元年１１月２６日に特許出願され、令和２年１月１６日、及び、令和２年２月１７日付の手続補正を経た後登録されたが、本件特許の特許請求の範囲にて特定される事項は、願書に最初に添付した明細書、特許請求の範囲又は図面（以下当初明細書等という。）に記載された事項と比較して、上記当初明細書等に記載されていない事項を含んでいるから、上記手続補正は、特許法第１７条の２第３項の規定する要件を満たしていない旨の主張。
（エ）特許法第３６条第６項第１号、同第２号に規定する要件を満たしていない旨の主張について 
　請求項１〜４に係る特許は、その記載に、発明の詳細な説明に記載された範囲を超え、また、明確でない記載を含んでいるから、特許法第３６条第６項第１号および同第２号の規定する要件を満たしていない旨の主張。
（オ）特許法第３６条第４項第１号に規定する要件を満たしていない旨の主張について
　請求項１〜４に係る特許は、その記載に、発明の詳細な説明に当業者が実施できる程度に開示されていない事項を含んでいるから、特許法第３６条第４項第１号の規定する要件を満たしていない旨の主張。
第４　各甲号証の記載 
（１）甲１（特開２０１４−２１７６５号公報）には、以下のとおりの記載がある。
【０００１】
　本発明は、口座申込システム、制御プログラム及び携帯情報端末に関する。
【０００５】
　そこで、本発明は、申込者に申込を断念させずに、金融機関の顧客獲得に結びつけるための口座申込システム、制御プログラム及び携帯情報端末を提供することを目的とする。
【００１２】
（第１実施形態）
　図１は、第１実施形態に係る口座開設システム１００の全体構成を示す図である。
　口座開設システム１００は、銀行の口座開設の申込と、携帯情報端末１を用いたキャッシュカード機能の使用とを、携帯情報端末１の操作で行えるシステムである。ここで、キャッシュカード機能とは、口座開設済の預金口座への入金や預金口座からの払出、振込等の取引を、キャッシュカードと同様に携帯情報端末１を用いてＡＴＭ（Ａｕｔｏｍａｔｉｃ　Ｔｅｌｌｅｒ　Ｍａｃｈｉｎｅ：現金自動預け払い機）で行えるものをいう。
　口座開設システム１００は、携帯情報端末１と、ＩＣ（Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）免許証３（情報記憶媒体）と、本人確認サーバ４と、発行サーバ５と、口座開設サーバ７（取引サーバ）と、Ｗｅｂサーバ８と、アプリ配信サーバ９−１と、アプリ管理サーバ９−２とを備えている。携帯情報端末１と、本人確認サーバ４と、発行サーバ５と、口座開設サーバ７と、Ｗｅｂサーバ８と、アプリ配信サーバ９−１と、アプリ管理サーバ９−２とは、通信ネットワークＮを介して通信可能に接続されている。
【００１４】
　ＩＣ免許証３は、ＩＣチップ３ａを有するカード型の運転免許証である。ＩＣチップ３ａは、属性情報として免許証に記載の申込者の住所と、氏名と、生年月日とを記憶している。また、ＩＣチップ３ａは、ＩＣ免許証３を所有する申込者本人が定めた２種類のＰＩＮ（Ｐｅｒｓｏｎａｌ　Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ　Ｎｕｍｂｅｒ）（暗証情報）を記憶している。さらに、ＩＣチップ３ａは、証明情報として証明書と、発行者番号とを記憶している。
【００１５】
　本人確認サーバ４は、鍵情報を記憶する鍵情報記憶部４ａを有する。本人確認サーバ４は、鍵情報記憶部４ａを参照して、携帯情報端末１から受信した証明書が正当なものであるか否かを判定し、判定結果を携帯情報端末１に送信する。
　発行サーバ５は、キャッシュカード機能を、携帯情報端末１に設定するための発行処理を行う。
　口座開設サーバ７は、口座開設の処理を行う。口座開設サーバ７は、取引データとして、口座開設をした口座番号を有する。
　Ｗｅｂサーバ８は、口座申込用のＷｅｂページを記憶する。
　口座開設サーバ７と、Ｗｅｂサーバ８とは、銀行ごとに用意され、銀行システム内に設けられている。
【００１７】
　次に、口座開設システム１００の主な装置の機能構成について説明する。図２は、第１実施形態に係る携帯情報端末１、本人確認サーバ４及び発行サーバ５の機能構成を示す図である。
　携帯情報端末１は、上述したＩＣチップ１ａと、ＵＩＭ１ｂとの他に、制御部１０と、記憶部２０と、タッチパネル２６と、通信Ｉ／Ｆ（インタフェース）部２８とを備える。
　ＵＩＭ１ｂが記憶する発行用アプリ２２は、制御プログラム２１の実行によってアプリ管理サーバ９−２からダウンロードされるキャッシュカード機能の発行に必要なソフトウェアである。発行用アプリ２２は、発行処理部１７の機能を実現する。
　制御部１０は、携帯情報端末１の全体を制御するＣＰＵ（中央処理装置）である。制御部１０は、記憶部２０に記憶されているオペレーティングシステム（ＯＳ）や各種アプリケーションプログラムを適宜読み出して実行することにより、上述したハードウェアと協働し、本発明に係る各種機能を実現している。
　制御部１０は、受付部１１と、プログラム起動部１２と、案内実行部１３と、操作判断部１４と、発行要求送信部１５ａと、アプリ起動部１６と、発行処理部１７と、完了報告送信部１８とを備える。
【００１８】
　受付部１１は、申込者によるタッチパネル２６への操作を受け付ける。
　プログラム起動部１２は、受付部１１が受け付けた操作に応じて、制御プログラム２１を起動する。
　案内実行部１３は、口座申込のための案内を実行する。
　操作判断部１４は、受付部１１が受け付けた操作が、案内実行部１３により実行された案内に対応したものであるか否かを判断する。
　発行要求送信部１５ａは、キャッシュカード機能の発行要求を、発行サーバ５に対して送信する。
　アプリ起動部１６は、アプリ管理サーバ９−２からダウンロードした発行用アプリ２２を起動して実行する。
　発行処理部１７は、発行サーバ５との間で発行処理を行う。そして、発行処理部１７は、キャッシュカード機能を携帯情報端末１で使用させるためのデータである取引用発行データを受信して、ＵＩＭ１ｂに記憶する。発行処理部１７の処理によって、携帯情報端末１には、キャッシュカード機能が備わる。
　完了報告送信部１８は、ＵＩＭ１ｂに記憶されたことに応じて、完了報告として発行完了通知を発行サーバ５に対して送信する。
【００２１】
　本人確認サーバ４は、携帯情報端末１から受信した証明情報に基づき本人確認を行い、その結果を携帯情報端末１に送信するサーバである。
　本人確認サーバ４は、制御部４０と、記憶部４５とを備える。
　制御部４０は、本人確認サーバ４の全体を制御するＣＰＵである。制御部４０は、記憶部４５に記憶されているＯＳやアプリケーションプログラムを適宜読み出して実行することにより、上述したハードウェアと協働し、本発明に係る各種機能を実現している。
　制御部４０は、判定部４１と、送信部４２とを有する。
　判定部４１は、携帯情報端末１から受信した証明情報が正当であるか否か（証明情報の真贋）を、鍵情報記憶部４ａに記憶された鍵情報を用いて判定する。ここで、携帯情報端末１は、証明情報として、証明書と発行者番号とをＩＣ免許証３から取得して記憶している。そして、鍵情報は、ＩＣ免許証３に記憶された証明書の復号鍵であり、各都道府県の公安委員会が発行したものである。また、発行者番号は、都道府県ごとに有する鍵情報から該当する鍵情報を特定するのに用いられる。判定部４１は、発行者番号をもとに鍵情報を特定し、特定した鍵情報により証明書を復号する。そして、証明書が復号できれば、証明書は、正当であると判断できる。
　送信部４２は、判定部４１による判定結果を携帯情報端末１に対して送信する。
【００２６】
　次に、口座開設システム１００の処理について説明する。初めに、口座申込からキャッシュカード機能の発行処理の流れについて説明する。図３は、第１実施形態に係る口座開設システム１００での一連の処理を説明するための図である。図４は、第１実施形態に係る制御プログラム２１に設定された複数の案内方法の例を示す図である。
　図３の（＃１）から（＃７）までは、口座申込による口座開設のための処理である。
　図３において、携帯情報端末１は、アプリ配信サーバ９−１から制御プログラム２１をダウンロードして、記憶部２０に記憶する（＃１）。ダウンロードの方法は、例えば、インターネットのショッピングサイトのページから制御プログラム２１をダウンロードしたり、Ｗｅｂサーバ８にアクセスしてそこからアプリ配信サーバ９−１を経由してダウンロードしたりするものである。なお、携帯情報端末１に予め制御プログラム２１がインストールされている場合（プレインストール時）には、このダウンロードの処理は不要である。
　次に、携帯情報端末１の受付部１１は、申込者からの操作を受け付ける。携帯情報端末１のプログラム起動部１２は、受け付けた操作がプログラム起動の操作であることに応じて、制御プログラム２１を起動する。そして、携帯情報端末１の案内実行部１３は、制御プログラム２１に設定された複数の案内方法から優先順位の最も高い案内方法を選択して出力する。そうすることで、口座開設システム１００は、口座申込処理を開始する（＃２）。
【００２７】
　図４（ａ）は、制御プログラム２１に設定されている複数の案内方法と、優先順位とを示す。優先順位は、予め利便性が高かったり、携帯情報端末１の操作が容易であったりするものを上位に設定してある。この図４（ａ）の例では、優先順位の最上位の「１」のものは、申込者が携帯情報端末１を操作するだけで口座開設が行え、かつ、口座開設までにかかる期間が短い方法である。優先順位の「２」のものは、申込者が携帯情報端末１を操作するだけで口座開設が行えるものであるが、本人確認作業を銀行から委託された第三者等が行うものであるので、口座開設までにかかる期間が先の方法に比べてやや長いものである。優先順位の「３」と「４」のものは、申込者が携帯情報端末１を操作し、かつ、郵送により口座開設を行う方法である。優先順位の「３」のものは、申込者が携帯情報端末１を操作して必要項目を入力するものである。他方、優先順位の「４」のものは、最寄りの店舗を探して申込書を取りにいくものである。よって、優先順位の「３」のものの方が、「４」のものよりも利便性が高い。
【００２８】
　図３に戻り、携帯情報端末１の案内実行部１３は、制御プログラム２１にしたがって順番に各案内項目を出力させる。
　ここで、案内項目の一例を図４（ｂ）に示す。まず、「１．」に示す説明によって、ＩＣ免許証３を申込者の手元に準備させる。その後、案内実行部１３は、各案内項目を順番に出力させる。
　そして、図３に示すように、申込者は、案内にしたがって準備したＩＣ免許証３の情報を、携帯情報端末１に読み取らせる（＃３）。
　携帯情報端末１がＩＣ免許証３を読み取れた場合には、携帯情報端末１は、本人確認サーバ４に対して通信する（＃４）。
　本人確認サーバ４の判定部４１は、本人確認処理として判定処理を行い、本人確認サーバ４の送信部４２は、判定結果情報を携帯情報端末１に送信する（＃５）。また、判定結果情報が正当である場合に、本人確認サーバ４は、口座開設サーバ７に対して判定結果情報を送信し、口座開設処理を依頼する（＃６）。
　そして、携帯情報端末１は、判定結果情報を受信し（＃５）、判定結果情報が正当である場合には、キャッシュカード機能の発行処理まで待機する。
　口座開設サーバ７は、口座番号付与処理を行い（＃７）、口座番号を付与する。口座番号付与処理は、口座番号を付与する前提として、申込者が口座開設をするのに適する者であるか否かの審査等の各種チェックを行う。
　以上の処理により、口座開設システム１００は、口座申込による口座開設を行うことができる。
【００３１】
　次に、上述で説明した口座申込の案内の処理の詳細について説明する。図５は、第１実施形態に係る携帯情報端末１の口座申込の案内に関するフローチャートである。図６及び図７は、第１実施形態に係る携帯情報端末１のタッチパネル２６での表示例を示す図である。
　ここで説明する処理は、図３の（＃２）から（＃５）までに対応する携帯情報端末１の処理である。
　図５において、携帯情報端末１の受付部１１が申込者の申込に関する操作を受け付けたことに応じて、携帯情報端末１のプログラム起動部１２は、記憶部２０に記憶された制御プログラム２１を起動させる。そして、ステップＳ１１において、携帯情報端末１の案内実行部１３は、最も優先順位の高い案内を実行して、その案内の最初の案内項目を出力させる。
【００３２】
　ここで、最も優先順位の高い案内とは、図４（ａ）に示した例では、優先順位が「１」のものであり、最初の項目とは、図４（ｂ）に示した例では、「１．」をいう。
　ステップＳ１２において、携帯情報端末１の受付部１１は、申込者からの操作を受け付けたか否かを判断する。申込者からの操作を受け付けた場合（ステップＳ１２：ＹＥＳ）には、制御部１０は、処理をステップＳ１３に移す。他方、申込者からの操作を受け付けていない場合（ステップＳ１２：ＮＯ）には、制御部１０は、引続きステップＳ１２の処理を行い、申込者からの操作を待つ。
【００３３】
　ステップＳ１３において、携帯情報端末１の操作判断部１４は、受け付けた操作が案内に適切なものであるか否かを判断する。例えば、「ＩＣ免許証３を準備してください。準備できたら「ＯＫ」を選択してください。ＩＣ免許証３がない場合には「キャンセル」を選択してください。」という案内がされた場合について説明する。受け付けた操作が案内に適切なものであるとは、申込者によって「ＯＫ」が選択された場合をいう。申込者によって「キャンセル」が選択された場合には、操作判断部１４は、受け付けた操作が案内に適切なものではないと判断する。受け付けた操作が案内に適切なものである場合（ステップＳ１３：ＹＥＳ）には、操作判断部１４は、処理をステップＳ１５に移す。他方、受け付けた操作が案内に適切なものではない場合（ステップＳ１３：ＮＯ）には、操作判断部１４は、処理をステップＳ１４に移す。
　ステップＳ１４において、携帯情報端末１の案内実行部１３は、次に優先順位の高い案内を実行して、その案内の最初の案内項目を出力させる。案内実行部１３は、例えば、優先順位が「１」のものを実行していた場合には、優先順位が「２」のものを実行する。そして、制御部１０は、処理をステップＳ１２に移す。
【００３４】
　ステップＳ１５において、携帯情報端末１の制御部１０は、口座申込処理を行う。口座申込処理とは、申込みに必要な情報を受け付けた場合に、口座申込みに必要な処理を行うことをいう。
　ステップＳ１６において、携帯情報端末１の制御部１０は、実行していた口座申込処理が正常に終了したか否かを判断する。口座申込処理が正常に終了したとは、例えば、実行していた案内の最後の案内項目まで出力し、口座申込が完了した場合をいう。口座申込処理が正常に終了した場合（ステップＳ１６：ＹＥＳ）には、制御部１０は、本処理を終了し、キャッシュカード機能の発行処理に必要なＩＤを取得するまで待機する。他方、口座申込処理が正常に終了していない場合（ステップＳ１６：ＮＯ）には、制御部１０は、処理をステップＳ１７に移す。
　ステップＳ１７において、携帯情報端末１の案内実行部１３は、次に優先順位の高い案内を実行して、その案内の最初の案内項目を出力させる。その後、制御部１０は、処理をステップＳ１２に移す。
【００３５】
　図６を参照して、図５で説明したステップＳ１２からステップＳ１７までの処理の一例を説明する。図６は、例えば、優先順位が「１」の案内であって、ＩＣ免許証３が手元に用意された状態で、案内実行部１３がタッチパネル２６に出力させる案内の例である。
　まず、（ａ）において、携帯情報端末１は、ＰＩＮの入力画面を出力する（ステップＳ１５）。申込者によって２種類のＰＩＮの入力がされて「次へ」が選択された場合に、携帯情報端末１は、タッチパネル２６に（ｂ）に示す指示画面を出力する（ステップＳ１５）。
【００３６】
　申込者が携帯情報端末１をＩＣ免許証３にかざすことで、携帯情報端末１は、ＩＣチップ１ａがＩＣ免許証３のＩＣチップ３ａと通信し、入力されたＰＩＮと、ＩＣチップ３ａに記憶されているＰＩＮとが一致するか否かを照合する。そして、携帯情報端末１は、照合の結果、一致した場合には、ＩＣチップ３ａに記憶されている氏名、住所等の属性情報と、証明情報とを受信する。受信できたら、携帯情報端末１は、タッチパネル２６に（ｃ）に示す画面を出力（ステップＳ１５）し、証明情報を本人確認サーバ４に送信する。他方、受信できなかったら、携帯情報端末１は、（ｄ）に示すエラー画面を出力した上で、（ｆ）に示す画面を出力する（ステップＳ１６でＮＯが選択されたステップＳ１７へ進む）。
【００３７】
　ＩＣ免許証３から情報が受信できた場合には、携帯情報端末１は、本人確認サーバ４に証明情報を送信することで、本人確認サーバ４での判定結果を受信する。携帯情報端末１は、本人確認ができなかった場合には、（ｅ）に示すエラー画面を出力した上で、（ｆ）に示す画面を出力する（ステップＳ１６でＮＯが選択されたステップＳ１７へ進む）。
　（ｆ）は、口座申込用のＷｅｂページにおけるＵＲＬの画面である。これは、申込者に他の案内にて引続き口座申込を行わせるためのものである。ここで、申込者がそのＵＲＬを選択することで、携帯情報端末１は、口座申込用のＷｅｂページへ遷移する。
【００３８】
　図６の例は、受け付けた操作が案内に対応していない場合に、携帯情報端末１が即時に他の案内を実行するものであった。しかし、図７の例のように、受け付けた操作が案内に対応していない場合であっても、携帯情報端末１は、少なくとも１回は申込者による操作のやり直しができるようにしてもよい。携帯情報端末１は、やり直してもなお操作が案内に対応していない場合に、他の案内を実行してもよい。
【００４５】
　このように、第１実施形態によれば、口座申込による口座開設に関して以下のような効果がある。
　（１）口座開設システム１００は、携帯情報端末１を用いて口座開設のための口座申込ができる。
　申込者は、携帯情報端末１を用いて出力される案内にしたがって口座開設の申込ができる。
　また、口座開設システム１００は、複数の申込の案内を有することで、申込者の操作が案内に対応したものではない場合であっても、すぐに他の案内に誘導できる。よって、申込者が申込途中で断念することを防止でき、申込者の口座申込のモチベーションの高い状態を維持したままで、口座申込を行うことができる。銀行にとっては、顧客獲得に結びつけることができる。
【００４６】
　（２）口座開設システム１００は、複数の案内の優先順位が予め決まっており、優先順位の高い案内から順に実行するので、例えば、口座開設までの期間が短い案内を最優先に実行することで、銀行と申込者との双方にとって利便性が高いものから順番に案内できる。
　（３）口座開設システム１００は、操作が案内に対応したものではない場合に、他の案内として口座申込用のＷｅｂページに誘導できる。よって、Ｗｅｂページに記載の内容に沿って申込者が口座申込を行うことができる。
【００４７】
　（４）口座開設システム１００は、ＩＣ免許証３を用いて証明情報を受け付け、本人確認サーバ４で証明情報の正当性を判断することで、本人確認を行って、口座申込ができる。よって、本人確認作業を携帯情報端末１と、本人確認サーバ４と、ＩＣ免許証３とを用いて行うことができる。
　（５）口座開設システム１００は、入力された暗証情報が、ＩＣ免許証３に記憶された暗証情報に一致している場合に、ＩＣ免許証３に記憶されている証明情報と属性情報とを読み出すので、ＩＣ免許証３の読み出しを、申込者に限定できる。よって、口座開設システム１００全体としてセキュリティ性が向上する。
　以上の甲１の記載によれば、甲１には以下のとおりの発明が開示されている。（以下、甲１発明という。） 
　口座開設システム１００は、携帯情報端末１と、ＩＣ（Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）免許証３（情報記憶媒体）と、本人確認サーバ４と、発行サーバ５と、口座開設サーバ７（取引サーバ）と、Ｗｅｂサーバ８と、アプリ配信サーバ９−１と、アプリ管理サーバ９−２とを備え、（【００１２】）
　携帯情報端末１と、本人確認サーバ４と、発行サーバ５と、口座開設サーバ７と、Ｗｅｂサーバ８と、アプリ配信サーバ９−１と、アプリ管理サーバ９−２とは、通信ネットワークＮを介して通信可能に接続され、（【００１２】）
　ＩＣ免許証３は、ＩＣチップ３ａを有するカード型の運転免許証であって、ＩＣチップ３ａは、属性情報として免許証に記載の申込者の住所と、氏名と、生年月日とを記憶し、また、ＩＣチップ３ａは、ＩＣ免許証３を所有する申込者本人が定めた２種類のＰＩＮ（Ｐｅｒｓｏｎａｌ　Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ　Ｎｕｍｂｅｒ）（暗証情報）を記憶し、さらに、ＩＣチップ３ａは、証明情報として証明書と、発行者番号とを記憶し、（【００１４】）
　本人確認サーバ４は、鍵情報を記憶する鍵情報記憶部４ａを有し、本人確認サーバ４は、鍵情報記憶部４ａを参照して、携帯情報端末１から受信した証明書が正当なものであるか否かを判定し、判定結果を携帯情報端末１に送信し、（【００１５】）
　口座開設サーバ７は、口座開設の処理を行い、取引データとして、口座開設をした口座番号を有し、（【００１５】）
　Ｗｅｂサーバ８は、口座申込用のＷｅｂページを記憶し、（【００１５】）
　口座開設サーバ７と、Ｗｅｂサーバ８とは、銀行ごとに用意され、銀行システム内に設けられ、（【００１５】）
　携帯情報端末１は、制御部１０と、記憶部２０と、タッチパネル２６と、通信Ｉ／Ｆ（インタフェース）部２８とを備え、（【００１７】）
　制御部１０は、受付部１１と、プログラム起動部１２と、案内実行部１３と、操作判断部１４と、発行要求送信部１５ａと、アプリ起動部１６と、発行処理部１７と、完了報告送信部１８とを備え、（【００１７】）
　受付部１１は、申込者によるタッチパネル２６への操作を受け付け、（【００１８】）
　プログラム起動部１２は、受付部１１が受け付けた操作に応じて、制御プログラム２１を起動し、（【００１８】）
　案内実行部１３は、口座申込のための案内を実行し、（【００１８】）
　操作判断部１４は、受付部１１が受け付けた操作が、案内実行部１３により実行された案内に対応したものであるか否かを判断し、（【００１８】）
　アプリ起動部１６は、アプリ管理サーバ９−２からダウンロードした発行用アプリ２２を起動して実行し、（【００１８】）
　発行処理部１７は、発行サーバ５との間で発行処理を行い、（【００１８】）
　制御プログラム２１に設定されている複数の案内方法と、優先順位は、予め利便性が高かったり、携帯情報端末１の操作が容易であったりするものを上位に設定してあり、この例では、優先順位の最上位の「１」のものは、申込者が携帯情報端末１を操作するだけで口座開設が行え、かつ、口座開設までにかかる期間が短い方法であり、優先順位の「２」のものは、申込者が携帯情報端末１を操作するだけで口座開設が行えるものであるが、本人確認作業を銀行から委託された第三者等が行うものであるので、口座開設までにかかる期間が先の方法に比べてやや長いものであり、優先順位の「３」と「４」のものは、申込者が携帯情報端末１を操作し、かつ、郵送により口座開設を行う方法であり、（【００２７】）
　口座申込の案内の処理の詳細は、携帯情報端末１の処理であって、（【００３１】）
　携帯情報端末１の受付部１１が申込者の申込に関する操作を受け付けたことに応じて、携帯情報端末１のプログラム起動部１２は、記憶部２０に記憶された制御プログラム２１を起動させ、（【００３１】）
　携帯情報端末１の案内実行部１３は、最も優先順位の高い案内を実行して、その案内の最初の案内項目を出力させ、（【００３１】）
　携帯情報端末１の受付部１１は、申込者からの操作を受け付けた場合（ステップＳ１２：ＹＥＳ）には、制御部１０は、処理をステップＳ１３に移し、（【００３２】）
　携帯情報端末１の操作判断部１４は、受け付けた操作が案内に適切なものであるか否かを判断し、申込者によって「ＯＫ」が選択された場合、操作判断部１４は、処理をステップＳ１５に移し、ステップＳ１５において、携帯情報端末１の制御部１０は、口座申込処理を行い、実行していた口座申込処理が正常に終了した場合、本処理を終了し、操作判断部１４で、受け付けた操作が案内に適切なものではない場合（ステップＳ１３：ＮＯ）には、案内実行部１３は、次に優先順位の高い案内を実行して、その案内の最初の案内項目を出力させ、（【００３３】、【００３４】）
　口座申込処理は、携帯情報端末１の案内実行部１３が、制御プログラム２１に設定された複数の案内方法から優先順位の最も高い案内方法を選択して出力することにより開始され、（【００２６】）
　申込者は、案内にしたがって準備したＩＣ免許証３の情報を、携帯情報端末１に読み取らせ、（【００２８】）
　携帯情報端末１がＩＣ免許証３を読み取れた場合には、携帯情報端末１は、本人確認サーバ４に対して通信し、（【００２８】）
　本人確認サーバ４の判定部４１は、本人確認処理として判定処理を行い、本人確認サーバ４の送信部４２は、判定結果情報を携帯情報端末１に送信し、（【００２８】）
　判定結果情報が正当である場合に、本人確認サーバ４は、口座開設サーバ７に対して判定結果情報を送信し、口座開設処理を依頼し、（【００２８】）
　口座開設サーバ７は、口座番号付与処理し、（【００２８】）
　口座開設システム１００は、口座申込による口座開設を行う、（【００２８】）
　口座開設システム。
　
（２）甲２（特開２０１２−３３００３号公報）には、以下のとおりの記載がある。
【請求項１】
　顧客の本人確認証を読取る読取部と
　前記読取部により読取られた前記本人確認証の内容と、前記顧客の登録済み本人確認証の内容とを比較する本人確認部と
を備え、
　前記本人確認部が行う比較は、前記本人確認証の有効期限と、前記登録済み本人確認証の有効期限との比較を含む、窓口端末。
【請求項２】
　前記本人確認部により前記本人確認証が有効であると判断された場合に取引を実行する取引処理部をさらに備え、
　前記本人確認部は、前記本人確認証の有効期限と、前記登録済み本人確認証の有効期限が一致しない場合、双方の有効期限の関係に基づいて前記本人確認証の有効性を判断する、請求項１に記載の窓口端末。
【請求項３】
　前記本人確認部は、前記登録済み本人確認証の有効期限が切れており、かつ、前記本人確認証の有効期限が切れていない場合、前記本人確認証と前記登録済み本人確認証とで前記有効期限以外の内容が一致するか否かに応じて前記本人確認証の有効性を判断する、請求項２に記載の窓口端末。
【請求項４】
　前記登録済み本人確認証は、前記窓口端末とネットワークを介して配置された本人確認証記憶部に登録されており、
　前記窓口端末は、
　前記本人確認証記憶部から前記登録済み本人確認証を取得するための通信部を備える、請求項３に記載の窓口端末。
【請求項５】
　前記通信部は、前記本人確認証の有効期限と前記登録済み本人確認証の有効期限が一致しないが、前記本人確認部により前記本人確認証は有効であると判断された場合、前記本人確認証の内容をサーバ装置に送信し、
　前記本人確認証記憶部に記憶されている前記登録済み本人確認証の内容は、前記サーバ装置により、前記通信部から前記サーバ装置が受信した前記本人確認証の内容に更新される、請求項４に記載の窓口端末。
【０００１】
　本発明は、窓口端末、本人確認方法、および本人確認システムに関する。
【０００７】
　そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、現本人確認証と登録済み本人確認証の有効期限の関係を考慮して本人確認を行うことが可能な、新規かつ改良された窓口端末、本人確認方法、および本人確認システムを提供することにある。
【００２５】
　また、口座開設や所定金額を超える振込などの所定の取引を行う場合、顧客の本人確認を行う必要がある。したがって、オンライン窓口端末２０は、顧客の本人確認が必要な取引に際しては、顧客から提示される本人確認証、および本人確認用サーバ１２から得られる登録済み本人確認証の内容に基づき、顧客の本人確認を行う。
【００３３】
　　（本発明の実施形態に至る経緯）
　ここで、本発明と異なるオンライン窓口端末による本人確認について説明する。このオンライン窓口端末は、顧客の本人確認証を読取り、読み取った本人確認証の内容（写真、住所、氏名など）と、本人確認証ＤＢ１４に登録済みの本人確認証の内容を比較し、顧客の本人確認を行う。
【００４５】
　この更新確認画面８０において実行ボタン８２がオペレータにより選択されると、登録済み本人確認証の内容を今回の本人確認証の内容で更新するための処理が実行される。一方、更新確認画面８０においてキャンセルボタン８４がオペレータにより選択された場合には、登録済み本人確認証の内容を更新するための処理は行われない。
【００５３】
　（関係Ａ）
　登録済み本人確認証の有効期限が切れていて、かつ、今回の本人確認証の有効期限は切れていない。
　（関係Ｂ）
　登録済み本人確認証の有効期限の方が今回の本人確認証の有効期限よりも未来の日付である。
【００５４】
　上記を補足すると、今回の本人確認証の有効期限と登録済み本人確認証の有効期限の関係が関係Ａに該当する場合、今回の本人確認証の方が後に発行されたものであるので、今回の本人確認証は有効であると判断することが妥当である。したがって、本人確認部２５４は、今回の本人確認証の有効期限と登録済み本人確認証の有効期限の関係が関係Ａに該当する場合、他の項目の一致不一致を再度確認し、他の項目が一致する場合、今回の本人確認証は有効であると判断する。
【００６３】
　そして、本人確認部２５４は、今回の本人確認証の有効期限と登録済み本人確認証の有効期限の関係が上述の関係Ａに該当する場合、他の項目の一致不一致を再度確認する（Ｓ３３２）。そして、本人確認部２５４により他の項目が一致すると判断された場合、取引処理部２５６が取引を継続し、取引を成立させる（Ｓ３３６）。
　
　以上の記載からみて、甲２には、「オンライン窓口端末による本人確認について、このオンライン窓口端末は、顧客の本人確認証を読取り、読み取った本人確認証の内容（写真、住所、氏名など）と、本人確認証ＤＢ１４に登録済みの本人確認証の内容を比較し、顧客の本人確認を行う」ことが記載されている。
（３）甲３（国際公開第２０１８／０８８４７５号）には、以下のとおりの記載がある。
［０００１］
　本発明は、電子認証に係り、特に、一の事業者との関係で本人確認済みがされている個人又は組織体が、他の事業者との関係でも本人確認の認証が必要な場合に、一の事業者との関係で記憶されている本人確認済みの事実を用いて他の事業者のための本人確認の認証に利用する技術に関する。
［００２６］
　口座開設のためには、基本４情報の真偽を証明する本人確認書類を送付することが必要である。本人確認書類のコピー書面を郵送してもよいが、郵送の代わりに本人確認書類の電子データの送信も従来から行われている。ここでは、本人確認書類を電子データにしてＡ銀行に送信するものとする。もっとも、口座を開設するためには、インターネット経由だけではなく、対面での申込も存在する。
［００２８］
　ここまでの処理は、従来から既に行われてきたものであるが、本発明は、Ａ銀行がユーザＸの本人確認を行った事実を認証システム１００に登録することで、Ａ銀行以外の銀行等での口座開設時には本人確認済みの事実を利用できるという点に特徴がある。認証システム１００に登録するか否かはユーザＸからの申込みを前提とし、口座開設後、任意の時にユーザ登録アプリケーションを実行することによって認証システム１００に登録することができる。
［００４１］
＜認証システム１００の利用＞
　次に、ユーザＸがＡ銀行以外の別の金融機関（例えば、Ｂ銀行とする。）に口座開設をする場合を想定する。ユーザＸはＢ銀行の口座開設の申し込みをする際、従来であれば、Ｂ銀行もユーザＸに対して本人確認書類の送信を要求し、Ａ銀行と同じようにユーザＸの本人確認作業を行うものであるが、本実施形態の場合、この本人確認作業を認証システム１００に依頼する。
［００４５］
　上述したように、ユーザＸは既にユーザ登録しているので、Ｂ銀行の端末である検証端末（Ｖ１）は、ユーザＸにノンス（nonce）と呼ばれる使い捨てのランダムな値を発行すると、これに検証端末（Ｖ１）の電子署名を付与して、ユーザＸの端末であるユーザＰＣ（Ｃ１）に送信する（図２（Ａ）の「2. nonce送信」参照）。
［００４６］
　Ａ銀行の口座開設時と同様、検証端末（Ｖ１）の電子署名付きのノンスをユーザＰＣ（Ｃ１）で受信したユーザＸは、ユーザＰＣ（Ｃ１）の画面上に表示されるＱＲコードを携
帯端末（Ｃ２）を用いて読み込む。ＱＲコードにはＢ銀行に関する銀行情報が含まれており、例えば、携帯端末（Ｃ２）からＢ銀行に接続する接続先アドレスを含んでいる。携帯端末（Ｃ２）は、読み込んだＱＲコードから銀行情報及びユーザＰＣ（Ｃ１）で受信されたノンスを受信する（図２（Ａ）の「3. ＱＲコード読取」参照）。
［００４７］
　図１（Ａ）の「4. キーペア作成」で説明したとおり、携帯端末（Ｃ２）はＣ２用のキーペア（秘密鍵、公開鍵）を保管している。そこで、次に携帯端末（Ｃ２）は、受信したノンス及びＣ２公開鍵に対してＣ２秘密鍵を用いて電子署名を付与する。携帯端末（Ｃ２）の電子書署名付きのノンス及びＣ２公開鍵が検証端末（Ｖ１）に送信される（図２（Ａ）の「4. ユーザ公開鍵送信」参照）。
［００４８］
　検証端末（Ｖ１）は、受信したＣ２公開鍵を用いて携帯端末（Ｃ２）の電子署名を検証し、携帯端末（Ｃ２）から送信されたデータの正当性を確認する。さらに、「2. nonce送信」の際に自身が発行したノンスと同一であるか否かを確認することで、ユーザＸがＢ銀行の口座開設を望む真のユーザであることを確認する。ノンスの同一性を確認できなければ、ユーザＸ以外の者による登録手続として拒絶する。
　以上の記載からみて、甲３には、「電子認証に係り、特に、一の事業者との関係で本人確認済みがされている個人又は組織体が、他の事業者との関係でも本人確認の認証が必要な場合に、一の事業者との関係で記憶されている本人確認済みの事実を用いて他の事業者のための本人確認の認証に利用する技術」が記載されている。
（４）甲４（特開２００７−２９３５９８号公報）には、以下のとおりの記載がある。
【請求項１】
　携帯端末を利用することによって、口座開設を含む金融取引サービスを受けることが可能な金融取引サービス方法であって、
　銀行と携帯電話会社が端末固有番号を用いて情報を管理しつつ連携し、携帯電話会社の保有情報を活用した本人確認によって、銀行側の確認手続きを補完することを特徴とする、携帯端末を利用した金融取引サービス方法。
【請求項４】
　請求項１記載の携帯端末を利用した金融取引サービス方法であって、
　携帯電話会社が、携帯端末の契約時において、携帯契約者本人についての携帯電話会社用パスワード、および、前記携帯契約者本人の氏名と住所の情報を含む携帯契約者情報を取得しておき、また、前記契約者本人が前記携帯端末の利用を開始した後においては、携帯端末の利用料金の支払い状況を示す携帯料金支払い情報を前記携帯電話会社が管理しており、このような状況下において、前記携帯端末のユーザが、その携帯端末を利用して前記銀行に新規口座を開設する場合の手順は、
　前記携帯端末から、前記端末固有番号と共に前記携帯電話会社用パスワードを、銀行サーバを経由して携帯電話会社サーバに、あるいは、直接、携帯電話会社サーバに送信する第１のステップと、
　前記携帯電話会社サーバが、受信した前記パスワードと、前記端末固有番号に紐付けられて管理されているパスワードとの一致／不一致を判定して本人確認を行う第２のステップと、
　この第２のステップにおいて前記パスワードの一致が確認された後、前記携帯電話会社サーバが、前記銀行サーバに向けて、前記携帯契約者情報および前記携帯料金支払い情報を送信する第３のステップと、
　銀行サーバにて、前記携帯料金支払い情報を調査することによって、前記携帯端末の契約時に取得された前記契約者の住所における契約者本人の存在を確認する第４のステップと、
　この第４のステップにて、前記住所における前記契約者本人の存在が確認できた場合に、銀行サーバは前記携帯契約者情報を参照して預金者ファイルを作成し、そして、正規の口座に比べて利用態様が制限された仮口座を開設する第５のステップと、
　を、含むことを特徴とする、携帯端末を利用した金融取引サービス方法。
【請求項５】
　請求項３または請求項４記載の携帯端末を利用した金融取引サービス方法であって、
　前記仮口座の開設後に、銀行が、本人限定受取郵便にて、銀行用パスワードおよび口座利用開始登録に必要なアクセス情報を含む口座利用開始情報を、前記携帯契約者の住所に送付する第６のステップと、
　前記携帯端末のユーザが、前記本人限定郵便を受け取り、前記アクセス情報が示す銀行サイトにアクセスして、前記端末固有番号および前記銀行用パスワードを含む前記口座利用開始情報を、前記銀行サーバに送信する第７のステップと、
　前記銀行サーバが、受信した前記利用開始情報に含まれる前記銀行用パスワードおよびその他の情報の少なくとも一つと、携帯端末固有番号に紐付けられて管理されている銀行用パスワードおよびその他の情報の少なくとも一つ、との一致／不一致を判定し、一致を確認できた場合に、前記仮口座を、正規の口座に移行させる第８のステップと、
　を、さらに含むことを特徴とする、携帯端末を利用した金融取引サービス方法。
【０００１】
　本発明は、携帯端末を利用した金融取引サービス方法および金融取引サービスシステムに関し、特に、携帯端末から銀行システムにアクセスして新規に銀行口座を開設することを可能とする携帯ダイレクトバンキング技術に関する。
【００１２】
　本発明は、このような考察に基づいてなされたものであり、携帯端末を利用したダイレクトバンキングによって銀行口座の開設を可能とすること、ならびに、その際の手続きを簡素化してユーザの負担を軽減すること、を目的とする。
【課題を解決するための手段】
【００１３】
　本発明の携帯端末を利用した金融取引サービス方法では、携帯端末を利用することによって、口座開設を含む金融取引サービスを受けることが可能な金融取引サービス方法であって、銀行と携帯電話会社が端末固有番号を用いて情報を管理しつつ連携し、携帯電話会社の保有情報を活用した本人確認によって、銀行側の確認手続きを補完する。
【００５４】
　銀行３は携帯電話会社１と通信回線を介してリンクしており、携帯契約者１００から、端末固有番号と共に携帯電話会社用パスワードが送られてくると、ゲートウェイ装置（不図示）の接続先を、リンクしている携帯電話会社に切り替えて（手順Ｑ２）、送られてきた情報をそのまま、携帯電話会社１に送信する（手順Ｑ３）。この点、見かけ上は銀行３を経由しているものの、携帯電話会社用パスワードは、実質的には、直接に携帯電話会社１に送られているのに等しい。これは、情報セキュリティ上、携帯電話会社用パスワードの内容を銀行が知るのは好ましくないと考えられるからであり、ゆえに、銀行は、携帯電話会社用パスワードを、そのまま携帯電話会社１に転送するようにしたものである。なお、携帯電話会社用パスワードについては、上記のとおり、銀行が関与しないのが原則であるため、携帯契約者１００が、端末固有番号と共に携帯電話会社用パスワードを、直接、銀行代理店としての携帯電話会社１に送信するようにしても特に、問題はない。
【００５９】
　料金支払いの確認がとれたときは、手順Ｑ８に移行し、仮口座（正規の口座に比べて、利用態様が制限されている口座）を開設する。このとき、銀行３は、預金契約者番号、口座種類、口座番号の情報を預金者の仮口座に付与する。また、仮口座の開設には、預金者の氏名、住所、生年月日、携帯電話番号、メールアドレス等が必要であるが（通常は、口座開設の申請書に記載される事項である）、ここでは、手順Ｑ５において、携帯電話会社１から送信されてくる携帯契約者情報２（氏名、住所、生年月日、携帯電話番号、メールアドレス等）を、そのまま援用して仮口座を開設する。
【００６２】
　次に、銀行３は、仮口座開設後に、本人限定受取郵便にて、銀行用のパスワード（Ｂ）（携帯契約時のパスワード（Ａ）とは異なるもの）、口座利用開始登録に必要なアクセス情報（専用ＵＲＬ）を含む口座利用開始情報、その他、例えばキャッシュカード等を、携帯端末２００の契約者１００の住所９０に送付する（手順Ｑ９）。
【００６４】
　銀行３からの本人限定受取郵便を受領した本人１００は、その後に、自己名義にお携帯端末２００から、銀行の口座利用開始登録サイトにアクセスし、端末固有番号と共に、本人限定郵便で送付された銀行用パスワード（パスワード（Ｂ））等を送信する（手順Ｑ１０）。
【００６５】
　次に、銀行３は、パスワード（Ｂ）の照合確認を行い（手順Ｑ１１）、適正なパスワード（Ｂ）であることが確認できた時点で、本人確認法による手続きが完結したことになり、この時点で、正式の（通常の）口座を開設する（手順Ｑ１２）。これによって、その端末固有番号をもつ携帯端末について、すべての金融取引が許可されることになる。
　以上の記載からみて、甲４には、「携帯電話会社が、携帯端末の契約時において、携帯契約者本人についての携帯電話会社用パスワード、および、前記携帯契約者本人の氏名と住所の情報を含む携帯契約者情報を取得しておき、また、前記契約者本人が前記携帯端末の利用を開始した後においては、携帯端末の利用料金の支払い状況を示す携帯料金支払い情報を前記携帯電話会社が管理しており、このような状況下において、前記携帯端末のユーザが、その携帯端末を利用して前記銀行に新規口座を開設する場合、銀行３は携帯電話会社１と通信回線を介してリンクしており、携帯契約者１００から、端末固有番号と共に携帯電話会社用パスワードが送られてくると、ゲートウェイ装置（不図示）の接続先を、リンクしている携帯電話会社に切り替えて（手順Ｑ２）、送られてきた情報をそのまま、携帯電話会社１に送信し、前記携帯電話会社サーバが、受信した前記パスワードと、前記端末固有番号に紐付けられて管理されているパスワードとの一致／不一致を判定して本人確認を行い、前記住所における前記契約者本人の存在が確認できた場合に、銀行サーバは前記携帯契約者情報を参照して預金者ファイルを作成し、そして、正規の口座に比べて利用態様が制限された仮口座を開設する金融取引サービス方法」が開示されている。
（５）甲５（国際公開第２００７／０１８２３３号の再公表特許）には、以下のとおりの記載がある。
【請求項１】
　金融機関に口座を開設する口座開設方法であって、
　携帯端末において、口座開設用のＷｅｂコンテンツの提供する口座開設専用の携帯電話用アプリケーションソフトウェアをダウンロードするステップと、
　当該携帯端末において、ダウンロードされた前記携帯電話用アプリケーションソフトウェアによって、申込者により入力された、少なくとも氏名、住所および生年月日を含む本人確認情報を、ネットワークを介して接続された金融機関のサーバに送信するステップと、
　前記金融機関のサーバにおいて、前記本人確認情報を、当該本人確認情報を特定するための登録番号と関連付けて、申込情報データベースに記憶するステップと、
　前記携帯端末において、前記登録番号を獲得するステップと、
　前記携帯端末において、前記携帯電話用アプリケーションソフトウェアによって、当該携帯端末に搭載されたカメラにて撮影された本人確認書類のデジタルデータを、前記登録番号とともに前記金融機関のサーバに送信するステップと、
　前記金融機関のサーバにおいて、前記本人確認書類のデジタルデータに基づくテキストデータを、前記登録番号と関連付けて、前記申込情報データベースに記憶するステップと、
　前記金融機関のサーバにおいて、前記登録番号と関連付けられた前記本人確認書類のデジタルデータに基づくテキストデータと、当該登録番号と関連付けられた前記本人確認情報との確認の後に、前記本人確認情報を、新規の口座情報として、口座データベースに記憶するステップと、を備えたことを特徴とする口座開設方法。
【０００１】
　本発明は、インターネットなどのコンピュータネットワーク上で決済処理を行う電子決済システム、電子決済方法及びプログラムに関する。特には、電子決済システムにおいて手間やコストを掛けずに、安全且つ確実に新規口座を開設することができる口座開設方法に関する。
【発明が解決しようとする課題】
【００１０】
　しかしながら、上述したような口座開設方法によれば、一般的な方法では、本人確認書類の提出は、一般的には、紙に印刷された運転免許証の写し、住民票、健康保険証の写し、パスポートの写し等を直接金融機関に送付又は持参して行なわなければならず、手間や時間がかかるという問題があった。また、本人確認書類は、運転免許証等の原本をコピーして用いられるため、記載文字や本人の顔写真等が不鮮明になる場合があった。更に、本人確認書類は紙でのみ保存されるため、その保存や管理に手間がかかり、本人確認書類の劣化が生じるという問題があった。
【００３１】
　以下、図面を参照して本発明の口座開設方法の実施の形態を説明する。
　図１は、本発明の口座開設方法を実行するシステムの一形態を示す図である。このシステムは、ユーザの口座情報などを有する金融機関の電子銀行サーバ１０と、電子銀行サーバ１０に口座を開設するための本人確認情報及び本人確認書類画像データを送信する通信機器であるカメラ付携帯電話２０及びＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）３０などの端末（以下、単に「端末２０，３０」ともいう）と、ＰＣ３０に接続され本人確認書類をデジタルデータに加工するデジタルカメラ３０Ａ及びスキャナ３０Ｂと、カメラ付携帯電話２０の通信キャリア４０と、ＰＣ３０のプロバイダ５０と、電子銀行サーバ１０、カメラ付携帯電話２０、ＰＣ３０、通信キャリア４０及びプロバイダ５０を通信可能に接続するネットワーク６０と、を備えている。
【００３２】
　ここで、ネットワーク６０は、インターネットやイントラネットを利用して構築することができる。
【００３３】
　また、運転免許証、各種健康保険証、パスポート、住民票の写し、印鑑証明書、外国人登録原票記載事項証明書などのいわゆる本人確認法施行規則定める書類の原本または写し（コピー）（以下、単に「本人確認書類」ともいう）７０は、カメラ付携帯電話２０に搭載されたカメラで撮影され、または、デジタルカメラ３０Ａで撮影されたりスキャナ３０Ｂで読み取られたりして作成されたデジタルデータとして、カメラ付携帯電話２０又はＰＣ３０より口座開設用のＷｅｂコンテンツ（又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理の場合（後述する）は単にネットワーク６０）を介して、又は電子メールなどによって電子銀行サーバ１０に送信される。
【００３６】
　電子銀行サーバ１０は、ネットワーク６０と通信可能に接続する通信制御部１１と、口座情報を記憶する口座ＤＢ（Ｄａｔａ  Ｂａｓｅ）１５と、口座ＤＢ１５の口座情報に基づいて決済処理を行う決済処理部１６と、ネットワーク６０を介して、又は電子メールなどによって、端末２０，３０から受信したデジタルデータ（画像情報）をテキストデータに自動的に変換するデータ変換処理部１３と、口座開設用のＷｅｂコンテンツ（口座開設専用の携帯電話用アプリケーションソフトウェアを含む）を記憶するＷｅｂＤＢ１７と、ネットワーク６０を介して端末２０，３０にＷｅｂＤＢ１７に記憶されている本人確認情報を入力させて受信し、本人確認書類のデジタルデータ（画像情報）を作成させ、デジタルデータ（画像情報）を送信させて受信するためのＷｅｂコンテンツ（又は口座開設専用の携帯電話用アプリケーションソフトウェア）を提供し、端末２０，３０からＷｅｂコンテンツ（又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理）を介して入力された本人確認情報を受信し、データ変換処理部１３で変換されたテキストデータと、受信した本人確認情報を比較し、該データと該情報が一致した場合に、新規の口座情報を記憶することによって新規の口座を口座ＤＢ１５に開設する口座開設処理部１２と、口座開設処理部１２で受信した本人確認情報と、データ変換処理部１３で変換されたテキストデータを記憶する申込情報ＤＢ１４と、を備えている。
【００４０】
　また、口座開設処理部１２は、データ変換処理部１３において、デジタルデータ（画像情報）からテキストデータへの変換結果により判読不能とされた場合、再度本人確認書類のデジタルデータ（画像情報）の作成、送信を促すエラー通知を、ネットワークを介して、又は電子メールで本人確認書類のデジタルデータの送信元に自動的に送信し、口座開設用のＷｅｂコンテンツ又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理を介して、又は電子メールを通してユーザに対し通知する。
【００４２】
　図３及び図４は、本発明の口座開設方法のフローチャートである。図１〜図４において、ユーザは、新規口座の開設申込を行うため、カメラ付携帯電話２０又はＰＣ３０から口座開設用のＷｅｂコンテンツを提供する電子銀行サーバ１０へアクセスする。（ステップ３０１）。
【００４６】
　この場合、カメラ付携帯電話２０において、口座開設用のＷｅｂサイトへアクセスしたメインメニュー画面（Ｗｅｂページ）上の、（又は、メインメニュー画面（Ｗｅｂページ）での選択によりリンクされた口座開設専用の携帯電話用アプリケーションソフトウェアのダウンロード用画面（Ｗｅｂページ）上でもよい）ダウンロード用釦を選択することにより、電子銀行サーバ１０より口座開設用のＷｅｂコンテンツ（当該Ｗｅｂページ）を介して、口座開設専用の携帯電話用アプリケーションソフトウェアをカメラ付携帯電話２０へダウンロードする。（ステップ３０２）。
【００４７】
　アプリケーションソフトウェアが自動的に起動される。（ステップ３０３）。
【００５１】
　次に、カメラ付携帯電話２０又はＰＣ３０から電子銀行サーバ１０に本人確認情報（氏名、住所、生年月日など）を口座開設用のＷｅｂコンテンツ又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理を介して入力し、新規口座の開設申込を行う（ステップ３０４）。この入力が完了すると、電子銀行サーバ１０の口座開設処理部１２から登録番号が付与される。口座開設処理部１２は、受け取った本人確認情報（氏名、住所、生年月日など）と登録番号を関連付けて申込情報ＤＢ１４に記憶する。
【００５２】
　そして、電子銀行サーバ１０は、ユーザの確認のため、本人確認書類の提出を要求する。ユーザは、この要求に応じて、運転免許証、各種健康保険証、パスポート、住民票の写し、印鑑証明書、外国人登録原票記載事項証明書などの本人確認書類７０を準備し、本人確認書類７０のデジタルデータ（画像情報）を作成する（ステップ３０５）。
【００５３】
　ここで、カメラ付携帯電話２０に搭載されたカメラで運転免許証、住民票、健康保険証、パスポート等を撮影し本人確認書類７０のデジタルデータ（画像情報）を作成ことができる。または、運転免許証、住民票、健康保険証、パスポート等をデジタルカメラ３０Ａで撮影したりスキャナ３０Ｂで読み取ったりして作成することもできる。
【００５４】
　カメラ付携帯電話２０で作成された本人確認書類７０のデジタルデータ（画像情報）は、当該カメラ付携帯電話２０から口座開設用のＷｅｂコンテンツ（又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理の場合は単にネットワーク６０）を介して、又は電子メールで電子銀行サーバ１０に送信され、また、デジタルカメラ３０Ａやスキャナ３０Ｂで作成された本人確認書類７０のデジタルデータ（画像情報）は、ＰＣ３０に取り込まれ、ＰＣ３０から口座開設用のＷｅｂコンテンツを介して、又は電子メールで金融機関の電子銀行サーバ１０に送信される（ステップ３０６）。
【００５６】
　電子銀行サーバ１０は、本人確認情報（氏名、住所、生年月日、当該書類の有効期限、登録番号等を含む）が記載された本人確認書類７０のデジタルデータ（画像情報）を受信し（ステップ３０７）、データ変換処理部１３は、受信した本人確認書類７０のデジタルデータ（画像情報）を受け取り、氏名、住所、生年月日、当該書類の有効期限、登録番等を判読し（ステップ３０８）、判読可能であれば、テキストデータに変換し、申込情報ＤＢ１４に記憶する（ステップ３１１）。
【００５７】
　ここで、本人確認書類７０のデジタルデータ（画像情報）やテキストデータは、登録番号を付して登録管理される。また、本人確認書類７０のデジタルデータ（画像情報）やテキストデータは、金融機関側で画面や紙に出力して確認することができる。なお、データ変換処理部１３は、ＯＣＲソフトウェアの実行によって自動的にデジタルデータ（画像情報）を判読し、テキストデータに変換する。
【００５９】
　次に、口座開設処理部１２は、登録番号に基づいて、本人確認情報と、テキストデータとを比較する確認チェックを行い（ステップ３１２）、該データと該情報が一致し、当該書類の有効期限が承認された場合に、口座ＤＢ１６に新規の口座情報を記憶することによって新規の口座を開設する（ステップ３１５）。
【００６１】
　ステップ３１２で、本人確認ができなかった場合には、エラー通知をネットワーク６０を介して、又は電子メールでカメラ付携帯電話２０又はＰＣ３０に自動的に送信し、受信したカメラ付携帯電話２０又はＰＣ３０において、口座開設用のＷｅｂコンテンツ又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理を介して、又は電子メールを通してユーザに対し通知し、（ステップ３１３）、ユーザが本人確認情報の修正などをする場合には（ステップ３１４）、ステップ３０４からの処理を行なう。
【００６３】
　図５は、本発明の口座開設方法の他の一例を示すフローチャートである。
　本フローチャートは、ＰＣ３０において新規口座の開設申込を行い、当該口座開設の申込完了後、携帯電話にてその後の口座開設に必要なステップを引き続き実行可能とする口座開設方法を示すものである。
【００６４】
　図１〜図５において、ユーザは、新規口座の開設申込を行うため、ＰＣ３０から口座開設用のＷｅｂコンテンツを提供する電子銀行サーバ１０へアクセスする。（ステップ５０１（ステップ３０１に同じ））。
【００６５】
　次に、ＰＣ３０から電子銀行サーバ１０に本人確認情報（氏名、住所、生年月日など）を口座開設用のＷｅｂコンテンツを介して入力し、新規口座の開設申込を行う（ステップ５０２（ステップ３０４に同じ））。この入力が完了すると、電子銀行サーバ１０の口座開設処理部１２から登録番号が付与される。口座開設処理部１２は、受け取った本人確認情報（氏名、住所、生年月日など）と登録番号を関連付けて申込情報ＤＢ１４に記憶する。
【００６６】
　この時点をもって、ＰＣ３０の口座開設申込み完了とし（ステップ５０３）、電子銀行サーバ１０により本人確認情報などの申込者特定情報及び口座開設専用の携帯電話用アプリケーションソフトウェアのダウンロード用画面（Ｗｅｂページ）のＵＲＬ（Uniform resource locator）情報を含む情報コードである２次元コード（ＱＲコード（登録商標））８０が生成され、口座開設用のＷｅｂコンテンツを介してＰＣ３０に表示する。（ステップ５０４）
【００６９】
　図６は、本発明の口座開設方法の他の一例を示すフローチャートである。
　本フローチャートは、カメラ付携帯電話２０において、ＰＣ３０と同様に通常の口座開設フローである、口座開設用のＷｅｂサイト（電子銀行サーバ１０）が提供するＷｅｂページの口座開設用のＷｅｂコンテンツを介して新規口座の開設申込を行い、当該口座開設の申込完了後、口座開設専用の携帯電話用アプリケーションソフトウェアの利用により、その後の口座開設に必要なステップを引き続き実行可能とする口座開設方法を示すものである。
【００７０】
　ここで、図６において、新規口座の開設申込から口座開設申込み完了までの、ステップ６０１からステップ６０３までは、図５のＰＣ３０によるステップ５０１からステップ５０３の場合と同様にて説明は省略する。
【００７１】
　口座開設申込み完了（ステップ６０３）後、カメラ付携帯電話２０において、次に表示される本人確認書類送付方法を選択できる選択釦を含む画面（Ｗｅｂページ）上で「デジタルデータ送付」釦を選択し（ステップ６０４）、当該釦のハイパーリンク情報に含まれる、本人確認情報などの申込者特定情報及び口座開設専用の携帯電話用アプリケーションソフトウェアのダウンロード用画面（Ｗｅｂページ）のＵＲＬ（Uniform resource locator）情報により、申込者特定情報などのユーザ情報を引き継いで当該ダウンロード用画面（Ｗｅｂページ）へリンクされ（ステップ６０５）、当該ダウンロード用画面（Ｗｅｂページ）上のダウンロード用釦を選択することにより、口座開設用のＷｅｂコンテンツ（当該ダウンロード用Ｗｅｂページ）を介して、ユーザ情報を引き継いで前記アプリケーションソフトウェアを前記携帯電話へダウンロードし（ステップ６０６）、口座開設専用の携帯電話用アプリケーションソフトウェアが自動的に起動される。（ステップ６０７）。
【００７２】
　カメラ付携帯電話２０において、図５の場合と同様に、口座開設専用の携帯電話用アプリケーションソフトウェアは、引き継がれたユーザ情報である口座開設申込みでの本人確認情報などの申込者特定情報に基づき、金融機関への口座開設の申込に続く、ステップ３０５以降の、本人確認書類７０のデジタルデータ（画像情報）の作成、デジタルデータ（画像情報）の電子銀行サーバ１０への送信等の一連のステップを継続して行うことができる。
【００７３】
　これにより、カメラ付携帯電話２０などのモバイルによる口座開設申込みにおいても、口座開設専用の携帯電話用アプリケーションソフトウェアの活用上、最も効果の高いと思われる本人確認書類７０のデジタルデータ（画像情報）の作成、送付だけはアプリケーションソフトウェアの利用とすることもできる。
　以上の甲５の記載によれば、甲５には以下のとおりの発明が開示されている。（以下、甲５発明という。）
　
　ユーザの口座情報などを有する金融機関の電子銀行サーバ１０と、電子銀行サーバ１０に口座を開設するための本人確認情報及び本人確認書類画像データを送信する通信機器である端末と、電子銀行サーバ１０と通信機器であるカメラ付携帯電話２０とを通信可能に接続するネットワーク６０と、を備え、（【００３１】）
　電子銀行サーバ１０は、ネットワーク６０と通信可能に接続する通信制御部１１と、ネットワーク６０を介して、端末２０から受信したデジタルデータ（画像情報）をテキストデータに自動的に変換するデータ変換処理部１３と、口座開設用のＷｅｂコンテンツ（口座開設専用の携帯電話用アプリケーションソフトウェアを含む）を記憶するＷｅｂＤＢ１７と、ネットワーク６０を介して端末２０にＷｅｂＤＢ１７に記憶されている本人確認情報を入力させて受信し、本人確認書類のデジタルデータ（画像情報）を作成させ、デジタルデータ（画像情報）を送信させて受信するためのＷｅｂコンテンツ（又は口座開設専用の携帯電話用アプリケーションソフトウェア）を提供し、端末２０からＷｅｂコンテンツ（又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理）を介して入力された本人確認情報を受信し、データ変換処理部１３で変換されたテキストデータと、受信した本人確認情報を比較し、該データと該情報が一致した場合に、新規の口座情報を記憶することによって新規の口座を口座ＤＢ１５に開設する口座開設処理部１２と、口座開設処理部１２で受信した本人確認情報と、データ変換処理部１３で変換されたテキストデータを記憶する申込情報ＤＢ１４と、を備え、（【００３６】）
　カメラ付携帯電話２０から口座開設用のＷｅｂコンテンツを提供する電子銀行サーバ１０へアクセスし（ステップ３０１）、（【００４２】）
　カメラ付携帯電話２０において、口座開設用のＷｅｂサイトへアクセスしたメインメニュー画面（Ｗｅｂページ）上の、（又は、メインメニュー画面（Ｗｅｂページ）での選択によりリンクされた口座開設専用の携帯電話用アプリケーションソフトウェアのダウンロード用画面（Ｗｅｂページ）上でもよい）ダウンロード用釦を選択することにより、電子銀行サーバ１０より口座開設用のＷｅｂコンテンツ（当該Ｗｅｂページ）を介して、口座開設専用の携帯電話用アプリケーションソフトウェアをカメラ付携帯電話２０へダウンロードし（ステップ３０２）、（【００４６】）
　カメラ付携帯電話２０において、アプリケーションソフトウェアが自動的に起動され（ステップ３０３）、（【００４７】）
　カメラ付携帯電話２０から電子銀行サーバ１０に本人確認情報（氏名、住所、生年月日など）を入力し、新規口座の開設申込を行い（ステップ３０４）、この入力が完了すると、電子銀行サーバ１０の口座開設処理部１２から登録番号が付与され、口座開設処理部１２は、受け取った本人確認情報（氏名、住所、生年月日など）と登録番号を関連付けて申込情報ＤＢ１４に記憶し、（【００５１】）
　電子銀行サーバ１０は、ユーザの確認のため、本人確認書類の提出を要求し、ユーザは、この要求に応じて、運転免許証、各種健康保険証、パスポート、住民票の写し、印鑑証明書、外国人登録原票記載事項証明書などの本人確認書類７０を準備し、本人確認書類７０のデジタルデータ（画像情報）を作成し（ステップ３０５）、（【００５２】）
　カメラ付携帯電話２０で作成された本人確認書類７０のデジタルデータ（画像情報）は、当該カメラ付携帯電話２０から口座開設用のＷｅｂコンテンツ（又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理の場合は単にネットワーク６０）を介して電子銀行サーバ１０に送信され（ステップ３０６）、（【００５４】）
　電子銀行サーバ１０は、本人確認情報（氏名、住所、生年月日、当該書類の有効期限、登録番号等を含む）が記載された本人確認書類７０のデジタルデータ（画像情報）を受信し（ステップ３０７）、データ変換処理部１３は、受信した本人確認書類７０のデジタルデータ（画像情報）を受け取り、氏名、住所、生年月日、当該書類の有効期限、登録番等を判読し（ステップ３０８）、判読可能であれば、テキストデータに変換し、申込情報ＤＢ１４に記憶し（ステップ３１１）、（【００５６】）
　口座開設処理部１２は、登録番号に基づいて、本人確認情報と、テキストデータとを比較する確認チェックを行い（ステップ３１２）、該データと該情報が一致し、当該書類の有効期限が承認された場合に、口座ＤＢ１６に新規の口座情報を記憶することによって新規の口座を開設し（ステップ３１５）、（【００５９】）
　ステップ３１２で、本人確認ができなかった場合には、エラー通知をネットワーク６０を介してカメラ付携帯電話２０に自動的に送信し、受信したカメラ付携帯電話２０において、ステップ３０４からの処理を行なうものであって、（【００６１】）
　カメラ付携帯電話２０における、通常の口座開設フローである、口座開設用のＷｅｂサイト（電子銀行サーバ１０）が提供するＷｅｂページの口座開設用のＷｅｂコンテンツを介して新規口座の開設申込を行い、当該口座開設の申込完了後、口座開設専用の携帯電話用アプリケーションソフトウェアの利用により、その後の口座開設に必要なステップを引き続き実行可能とするフローでは、（【００６９】）
　カメラ付携帯電話２０において、次に表示される本人確認書類送付方法を選択できる選択釦を含む画面（Ｗｅｂページ）上で「デジタルデータ送付」釦を選択し（ステップ６０４）、当該釦のハイパーリンク情報に含まれる、本人確認情報などの申込者特定情報及び口座開設専用の端末用アプリケーションソフトウェアのダウンロード用画面（Ｗｅｂページ）のＵＲＬ（Uniform resource locator）情報により、申込者特定情報などのユーザ情報を引き継いで当該ダウンロード用画面（Ｗｅｂページ）へリンクされ（ステップ６０５）、当該ダウンロード用画面（Ｗｅｂページ）上のダウンロード用釦を選択することにより、口座開設用のＷｅｂコンテンツ（当該ダウンロード用Ｗｅｂページ）を介して、ユーザ情報を引き継いで前記アプリケーションソフトウェアを前記端末へダウンロードし（ステップ６０６）、口座開設専用の携帯電話用アプリケーションソフトウェアが自動的に起動され（ステップ６０７）、（【００７１】）
　口座開設専用の携帯電話用アプリケーションソフトウェアは、引き継がれたユーザ情報である口座開設申込みでの本人確認情報などの申込者特定情報に基づき、金融機関への口座開設の申込に続く、ステップ３０５以降の、本人確認書類７０のデジタルデータ（画像情報）の作成、デジタルデータ（画像情報）の電子銀行サーバ１０への送信等の一連のステップを継続して行うことができる、（【００７２】）
　口座開設方法を実行するシステム。
　
第５　判断
　事案に鑑み、第３（ウ）、（エ）、（オ）についてまず検討する。
（５−１）特許法第１７条の２第３項に規定する要件を満たしていない旨の主張（上記（ウ））について
　当初明細書には以下のとおりの記載がある。
　【００１９】
　
受付部１１０は、ネットワークを介し顧客から金融取引のための取引口座の口座開設要求を受け付ける
　【００２０】
　
画面制御部１２０は、取引口座を開設するための本人確認資料の提出方法を顧客に選択させ、選択された提出方法に対応する画面を顧客に表示する
口座開設申込画面は、例えば、図４に示されるようなレイアウトを有してもよい
　【００２１】
　図４に示される口座開設申込画面では、画面制御部１２０は、口座開設申込書への入力が必要とされる氏名、住所等の個人情報を顧客に入力するよう求める。ここで、当該顧客はインターネットバンキングに登録しているため、氏名、住所等の個人情報は顧客情報として取得済みであり、顧客の入力負担を軽減するため、取得済みの顧客情報を利用して、口座開設申込に必要とされる個人情報は予め入力済みとして口座開設申込画面上で表示し、顧客に内容の確認のみ求めてもよい。確認の結果、内容に問題なければ、顧客はＯＫボタンを押下し、変更がある場合、変更ボタンを押下する。
　【００２２】
　さらに、
画面制御部１２０は、本人確認資料の提出方法を顧客に選択させる。図示された口座開設申込画面では、画面制御部１２０は、ネットワークを介し本人確認資料の画像データなどを送信させるＷＥＢでアップロードボタンと、郵送により本人確認資料のコピーを提出する郵送ボタンとの２つの提出方法の選択肢を提示している
　【００２３】
　
顧客がＷＥＢでアップロードボタンを押下した場合、画面制御部１２０は、図５に示されるような口座開設申込画面を顧客端末５０上に表示する。図示された口座開設申込画面では、本人確認資料として、個人番号カード、又は、運転免許証と通知カードとをアップロードするよう顧客に要求している。顧客は、個人番号カード、又は、運転免許証と通知カードとを撮像し、アップロードボタンを押下することによって当該画像データをアップロードする。その後、顧客は口座開設ボタンを押下し、口座開設申込手続を終了する
　【００２４】
　他方、顧客が郵送ボタンを押下した場合、画面制御部１２０は、図６に示されるような口座開設申込画面を顧客端末５０上に表示する。図示された口座開設申込画面では、本人確認資料を郵送するための返送用キットを顧客の住所宛に送付することが通知される。その後、顧客は口座開設ボタンを押下し、口座開設申込手続を終了する。
　【００２５】
　
一実施例では、画面制御部１２０は、顧客について登録済みの顧客情報に基づき、取引口座を開設するために必要な本人確認資料の種別を特定し、特定した種別の本人確認資料を提出させる画面を顧客に表示してもよい。例えば、顧客が投資信託（投信）を取引するための投信口座の口座開設をインターネットバンキングを介し申し込む場合、当該銀行は基本的に顧客の顧客情報を既に取得している。このため、投信口座の口座開設に必要な本人確認資料のみを顧客に提出してもらえばよい。具体的には、当該銀行が顧客の運転免許証のコピーを既に取得済みである場合、画面制御部１２０は、運転免許証以外の本人確認資料を顧客に求める口座開設申込画面を顧客端末５０上に表示してもよい
　【００２６】
　なお、
顧客情報に保持されている運転免許証などの本人確認資料が有効期限切れ、住所変更、氏名改称などのために申込時点で有効なものでない場合、画面制御部１２０は、有効な本人確認資料を提出するよう顧客に求めてもよい
　
　以上の記載によれば、
（ａ）受付部１１０は、ネットワークを介し顧客から金融取引のための取引口座の口座開設要求を受け付け、（【００１９】）
（ｂ）画面制御部１２０は、取引口座を開設するための本人確認資料の提出方法を顧客に選択させ、選択された提出方法に対応する画面を顧客に表示し、（【００２０】）
（ｃ）（選択された提出方法に対応する画面として）顧客がＷＥＢでアップロードボタンを押下した場合、画面制御部１２０は、図５に示されるような口座開設申込画面を顧客端末５０上に表示すること、（【００２３】）
（ｄ）本人確認資料の例として、個人番号カード、又は、運転免許証と通知カードがあること、（【００２３】）
（ｅ）既に取得済みの本人確認資料の例として、運転免許証のコピーがあり、当該銀行が顧客の運転免許証のコピーを既に取得済みである場合、画面制御部１２０は、運転免許証以外の本人確認資料を顧客に求めること、（【００２５】）
（ｆ）顧客情報に保持されている運転免許証などの本人確認資料が有効期限切れ、住所変更、氏名改称などのために申込時点で有効なものでない場合、画面制御部１２０は、有効な本人確認資料を提出するよう顧客に求めること、（【００２６】）
（ｇ）顧客情報に保持されている本人確認資料を有効性を確認し、保持されている本人確認資料が有効でないと判断すること、（【００２６】）
（ｈ）当該有効性の判断は、顧客情報として保存されている本人確認資料のコピーを画像認識し、有効期限が切れているかなどを確認することによって行われてもよいこと、（【００２６】）
が記載されており、上記（ｂ）〜（ｈ）の制御は「画面制御部１２０」にて行うことも記載されている。
　申立人の主張によれば、「口座開設のために提出された本人確認資料の有効性を当該本人確認資料の記載事項に基づいて確認すること、及び記載事項に基づいて確認することは記載されていない」とのことであるが、顧客がＷＥＢでアップロードを選択し、運転免許証と通知カードにて本人確認を行おうとしたときには、上記実施例の「運転免許証」は、口座確認のために提出させる本人確認資料であって、かつ顧客情報に保持されている本人確認資料である。
　そして、上記免許証の有効性の確認について、本人確認資料のコピーを画像認識し、有効期限が切れているかなどを確認することによって行うこと、本人確認資料が有効で無い場合、本人確認資料の提出を求めることも記載されているから、「前記顧客について保持されている前記本人確認資料の有効性を前記本人確認資料の記載事項に基づき確認し、前記本人確認資料が有効でない場合、有効な本人確認資料を提出させる」ことも記載されている。
　したがって、請求項１の構成Ａ〜Ｃは当初明細書に記載されている。
　なお、上記申立人の主張のうち、「
口座開設のために提出された
　また、請求項３の記載との関係において、構成Ｃと構成Ｆの構成をともに採用することは当初明細書に記載されていないとのことであるが、上記で検討したとおり、画面制御部が、構成Ｃ、構成Ｆの表示のための処理を行っていることは記載されており、これらの処理をともに行うことも、例えば、本人確認資料を実施例の「運転免許証」と置き換えれば、構成Ｆにて運転免許証が登録されている場合、これ以外の本人確認資料の提出を求めるが、構成Ｃにて運転免許証が有効で無い場合、運転免許証の提出も求める構成とすることは上記当初明細書の記載から読み取ることはできるから、当初明細書に記載されていないということはできない。
　したがって、本件発明１、本件発明３についての申立人の主張は採用することができず、本件発明１とその記載を引用する本件発明２，本件発明３、及び本件発明１の「金融取引処理装置」の構成を「（画面を表示する）プログラム」とした発明である本件発明４は、当初明細書に記載された発明である。
　よって、令和２年１月１６日、及び、令和２年２月１７日の手続補正は、特許法第１７条の２第３項に規定する要件を満たすものである。
　
（５−２）特許法第３６条第６項第１号、同第２号に規定する要件を満たしていない旨の主張（上記（エ））について
　上記主張は
（i）「保持されている前記本人確認資料」はどのような資料であるか
（ii）「保持されている前記本人確認資料」と「前記取引口座を開設するための本人確認資料」との関係が不明確である
（iii）「本人確認資料が有効でない場合」とはどのような場合であるか
が不明確であり、また、発明の詳細な説明に記載された事項を超えた事項を含むという主張である。
　まず、「保持されている前記本人確認資料」は、発明の詳細な説明の記載に「例えば、顧客が投資信託（投信）を取引するための投信口座の口座開設をインターネットバンキングを介し申し込む場合、当該銀行は基本的に
顧客の顧客情報を既に取得している
当該銀行が顧客の運転免許証のコピーを既に取得済みである場合
　次に、「前記取引口座を開設するための本人確認資料」とは、発明の詳細な説明に「画面制御部１２０は、図５に示されるような口座開設申込画面を顧客端末５０上に表示する。本人確認資料として、個人番号カード、又は、運転免許証と通知カードとをアップロードするよう顧客に要求している。」と記載されているように、「個人番号カード」、「運転免許証と通知カード」などのことであるから明確である。
　そして、これらの記載から、口座開設のために必要な本人確認資料として、「運転免許証と通知カード」を選択した場合、「運転免許証と通知カード」が「前記取引口座を開設するための本人確認資料」であり、当該銀行が顧客の運転免許証のコピーを既に取得済みである場合、「運転免許証」が「保持されている前記本人確認資料」に対応することも明白である。
　ただし、このような本人確認資料は、システム構築時に当業者が適宜決定可能な事項であることは普通のことであり、「運転免許証と通知カード」、「運転免許証」を、「前記取引口座を開設するための本人確認資料」、「保持されている前記本人確認資料」と、それぞれ、上位概念化することは不自然ではない。
　「本人確認資料が有効でない場合」とは、発明の詳細な説明に「顧客情報に保持されている運転免許証などの本人確認資料が有効期限切れ、住所変更、氏名改称などのために申込時点で有効なものでない場合」と記載があるから、このような場合を指すことは明確である。
　ただし、先記したとおり、本人確認資料は、システム構築時に当業者が適宜決定可能な事項であって、また、有効性の確認も本人確認資料に記載された範囲においてどのようなものを利用するか適宜決定可能であるから、これらを、実施例の記載に限定する必要は無いことは技術常識である。
　したがって、申立人の上記主張はいずれも採用することができない。
　以上のことから、本件発明１と本件発明１の記載を引用する本件発明２、本件発明３、及び、本件発明１の「金融取引処理装置」の構成を「（画面を表示する）プログラム」とした発明である本件発明４は、いずれも特許法第３６条第６項第１号、同第２号に規定する要件を満たすものである。
　
（５−３）特許法第３６条第４項第１号に規定する要件を満たしていない旨の主張（上記（オ））について
　上記主張は、「有効な本人確認資料を提出させる」の「有効な本人確認資料」とはどのような資料か、当業者が実施できる程度に、発明の詳細な説明が記載されていないというものである。
　発明の詳細な説明には「なお、顧客情報に保持されている運転免許証などの本人確認資料が有効期限切れ、住所変更、氏名改称などのために申込時点で有効なものでない場合、画面制御部１２０は、有効な本人確認資料を提出するよう顧客に求めてもよい。例えば、画面制御部１２０は、顧客情報に保持されている本人確認資料を有効性を確認し、保持されている本人確認資料が有効でない場合、有効な本人確認資料を再提出させるための画面を顧客端末５０に表示してもよい。」との記載があるから、本人確認資料が「運転免許証」である場合、本人確認資料としての運転免許証について、「有効期限切れ、住所変更、氏名改称などのために申込時点で有効なものでない」という事象が生じたら、「有効期限切れ、住所変更、氏名改称などのために申込時点で有効なものでない」という問題を解消した（すなわち有効な）運転免許証を提出させることを意味することは、上記記載から読み取ることができるから、申立人の上記主張は採用することはできない。
　申立人は「すなわち、口座開設のために本人確認資料（例えば、新しい有効期限の資料）がすでに提出されているが、・・・」と主張しているが、「すでに提出されている」と述べるのみで、その主張の根拠が述べられていないから、申立人の上記主張は採用することはできない。
　以上のことから、本件発明１と本件発明１の記載を引用する本件発明２、本件発明３、及び、本件発明１の「金融取引処理装置」の構成を「（画面を表示する）プログラム」とした発明である本件発明４は、いずれも特許法第３６条第４項第１号に規定する要件を満たすものである。　
（５−４）特許法第２９条第１項第３号の規定に違反している旨の主張（上記（ア））について
（５−４−１）本件発明１と甲１発明との対比及び判断
　甲１発明の「本人確認サーバ４」は、通信ネットワークＮを介して通信可能に接続され、携帯情報端末１から受信した証明書が正当なものであるか否かを判定し、判定結果情報が正当である場合に、本人確認サーバ４は、口座開設サーバ７に対して判定結果情報を送信し、口座開設処理を依頼し、口座開設サーバ７は、口座番号付与処理を行い口座開設を行っている。
　したがって、間接的にではあるが、本人確認サーバ４は、金融取引処理装置であって、「ネットワークを介し顧客から金融取引のための取引口座の口座開設要求を受け付ける受付部」を有しているといえる。
　甲１発明では、複数の案内方法と、優先順位が設定され、申込者の操作により、優先順位が高い案内方法から低い案内方法に申し込み手順が変更され、上記申し込み手順の変更に伴い、申込者が携帯情報端末１を操作するだけで口座開設が行える案内方法から郵送により口座開設を行う方法まで案内方法が変更され、これに伴い、本人確認資料の提出方法も、携帯情報端末１の操作により提出する方法から、郵送により提出方法に変化するから、前記取引口座を開設するための本人確認資料の提出方法を前記顧客に選択させ、前記選択された提出方法に対応する画面を前記顧客に表示させているといえる。
　もっとも、本件発明１では、上記表示のための処理を金融取引処理装置の画面制御部が、「前記取引口座を開設するための本人確認資料の提出方法を前記顧客に選択させ、前記選択された提出方法に対応する画面を前記顧客に表示する画面制御部」であるのに対し、甲１発明では、携帯情報端末にて、上記案内方法の変更のための処理が行われているからこの点で相違する。
　甲１発明の本人確認サーバ４は、鍵情報記憶部４ａを参照して、携帯情報端末１から受信した証明書が正当なものであるか否かを判定し、判定結果を携帯情報端末１に送信しているから、前記顧客について保持されている前記本人確認資料と、受信した本人確認資料との判定を行ってはいるが、「前記顧客について保持されている前記本人確認資料の有効性を前記本人確認資料の記載事項に基づき確認し」てはおらず、また、「前記本人確認資料が有効でない場合、有効な本人確認資料を提出させる画面を表示する」ことも行っていない。
　以上のことからみて、甲１発明と本件発明１とは、以下の一致点で一致し相違点で相違する。
　　　
（一致点）
　ネットワークを介し顧客から金融取引のための取引口座の口座開設要求を受け付ける受付部を有し、
　前記取引口座を開設するための本人確認資料の提出方法を前記顧客に選択させ、前記選択された提出方法に対応する画面を前記顧客に表示することが可能な、
　金融取引処理装置。
相違点１
「前記取引口座を開設するための本人確認資料の提出方法を前記顧客に選択させ、前記選択された提出方法に対応する画面を前記顧客に表示することが可能」とするための構成が、本件発明１では、金融取引処理装置が有する画面制御部であるのに対し、甲１発明では、携帯情報端末である点。
相違点２
本件発明１は、「前記画面制御部は、前記顧客について保持されている前記本人確認資料の有効性を前記本人確認資料の記載事項に基づき確認し、前記本人確認資料が有効でない場合、有効な本人確認資料を提出させる画面を表示する」という特定事項を有しているのに対し、甲１発明では当該特定事項を有していない点。
　特に相違点２について、申立人は、甲１の【００２８】、【００３７】、【００３８】に記載されていると主張しているが、【００２８】には、本人確認サーバの確認結果が正当である場合の処理しか記載がなく、【００３７】には、本人確認ができなかった場合として「本人確認ができなかった場合には、（ｅ）に示すエラー画面を出力した上で、（ｆ）に示す画面を出力する（ステップＳ１６でＮＯが選択されたステップＳ１７へ進む）。
　（ｆ）は、口座申込用のＷｅｂページにおけるＵＲＬの画面である。これは、申込者に他の案内にて引続き口座申込を行わせるためのものである。ここで、申込者がそのＵＲＬを選択することで、携帯情報端末１は、口座申込用のＷｅｂページへ遷移する。」との記載はあるが、これは案内方法の変更を行うことであって、「前記画面制御部は、前記顧客について保持されている前記本人確認資料の有効性を前記本人確認資料の記載事項に基づき確認し、前記本人確認資料が有効でない場合、有効な本人確認資料を提出させる画面を表示する」ことを開示しておらず、【００３８】には「受け付けた操作が案内に対応していない場合に、携帯情報端末１が即時に他の案内を実行するものであった。しかし、図７の例のように、受け付けた操作が案内に対応していない場合であっても、携帯情報端末１は、少なくとも１回は申込者による操作のやり直しができるようにしてもよい。」との記載があるのみで、「受け付けた操作が案内に対応していない場合」の処理であるから、「前記画面制御部は、前記顧客について保持されている前記本人確認資料の有効性を前記本人確認資料の記載事項に基づき確認し、前記本人確認資料が有効でない場合、有効な本人確認資料を提出させる画面を表示する」ことについて、記載も示唆もされていない。
　したがって、当該主張は採用することができず、上記相違点が存在するのであるから、本件発明１は甲１に記載された発明ではない。
　
　本件発明２、本件発明３は本件発明１の記載を引用しさらに限定した構成を付加したものであり、本件発明４は、本件発明１の「金融取引処理装置」の構成を「（画面を表示する）プログラム」とした発明であって、上記相違点と同様の構成を有しているから、本件発明１と同様、甲１に記載された発明ではない。
　
（５−４−２）本件発明１と甲５発明との対比及び判断
　甲５発明の電子銀行サーバは、端末からのアクセスを受けて、電子銀行サーバに、上記端末のユーザが口座を開設するための各種処理を行っているから、「ネットワークを介し顧客から金融取引のための取引口座の口座開設要求を受け付ける受付部」を有している。
　甲５発明では、「端末において、次に表示される本人確認書類送付方法を選択できる選択釦を含む画面（Ｗｅｂページ）上で「デジタルデータ送付」釦を選択」することで、本人確認書類送付方法を選択しているから、「前記取引口座を開設するための本人確認資料の提出方法を前記顧客に選択させ、前記選択された提出方法に対応する画面を前記顧客に表示する画面制御部」を有している。
　甲５発明では、電子銀行サーバ１０は、本人確認情報（氏名、住所、生年月日、当該書類の有効期限、登録番号等を含む）が記載された本人確認書類７０のデジタルデータ（画像情報）を受信しテキストデータに変換した情報と、（端末から電子銀行サーバ１０に本人確認情報（氏名、住所、生年月日など）を口座開設用のＷｅｂコンテンツ又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理を介して入力した）本人確認情報とを比較して本人確認を行っているから、「前記顧客について保持されている前記本人確認資料の有効性を前記本人確認資料の記載事項に基づき確認し」ていない。
　したがって、「前記本人確認資料が有効でない場合、有効な本人確認資料を提出させる画面を表示する」ことも行っていない。
　
　以上のことからみて、甲５発明と本件発明１とは、以下の一致点で一致し相違点で相違する。
　　　
（一致点）
　ネットワークを介し顧客から金融取引のための取引口座の口座開設要求を受け付ける受付部と、
　前記取引口座を開設するための本人確認資料の提出方法を前記顧客に選択させ、前記選択された提出方法に対応する画面を前記顧客に表示する画面制御部と、
を有する、
　金融取引処理装置。
　
（相違点）
　本件発明１は、「前記画面制御部は、前記顧客について保持されている前記本人確認資料の有効性を前記本人確認資料の記載事項に基づき確認し、前記本人確認資料が有効でない場合、有効な本人確認資料を提出させる画面を表示する」という特定事項を有しているのに対し、甲５発明は、当該特定事項を有していない点。
　
　上記相違点について、申立人は、『甲５には口座開設処理部１２は、入力され保持されている本人確認書類（構成要件Ｃにおける「保持されている前記本人確認資料」に相当）の有効性を当該本人確認書類の記載事項に基づいて確認し（段落３６）、本人確認書類が判別不能とされた場合、再度本人確認書類のデジタルデータ（画像情報）の作成、送信を促すエラー通知を、ネットワークを介して、又は電子メールで本人確認書類のデジタルデータの送信元に自動的に送信し、口座開設用のＷｅｂコンテンツ又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理を介して、又は電子メールを通してユーザに対し通知することが記載されている（段落４０）』と主張している。
　しかし、段落３６の「端末２０，３０からＷｅｂコンテンツ（又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理）を介して入力された本人確認情報を受信し、データ変換処理部１３で変換されたテキストデータと、受信した本人確認情報を比較し、該データと該情報が一致した場合に、新規の口座情報を記憶する」の処理は、端末からＷｅｂコンテンツを介して入力された本人確認情報とデータ変換処理部１３で変換されたテキストデータ（本人確認書類の画像データをテキスト変換したデータ）とを比較する構成であるから、段落００５９のステップ３１２の処理であり、段落４０の「本人確認書類が判別不能とされた場合」とは、「データ変換処理部１３において、デジタルデータ（画像情報）からテキストデータへの変換結果により判読不能とされた場合」のことであるから、段落００５８の「ステップ３０８で、判読不能とされた場合」のことである。
　すなわち、本人確認書類が判別不能であることと、本人確認書類が有効でないこととは異なっているのであるから、申立人の上記主張は採用することができない。
　したがって、当該主張は採用することができず、上記相違点が存在するのであるから、本件発明１は甲５に記載された発明ではない。
　
　本件発明２、本件発明３は本件発明１の記載を引用しさらに限定した構成を付加したものであり、本件発明４は、本件発明１の「金融取引処理装置」の構成を「（画面を表示する）プログラム」とした発明であって、上記相違点と同様の構成を有しているから、本件発明１と同様、甲５に記載された発明ではない。
　
（５−５）特許法第２９条第２項の規定に違反している旨の主張（上記（イ））について
（５−５−１）甲１を主たる引例とした主張について
（ａ）本件発明１と甲１発明との対比
　一致点、相違点は、上記（５−４−１）のとおりである。
（ｂ）相違点についての判断
　相違点２について検討する。
　申立人は、上記相違点について、甲１に記載されていると述べるのみで、他の甲号証に記載された事項との検討を行っていない。
　そして、甲２ないし甲５の記載を見ても、上記相違点２に相当する事項について開示が無いことは明らかである。
　したがって、本件発明１及び本件発明１の記載を引用する本件発明２、本件発明３、並びに本件発明１の「金融取引処理装置」の構成を「（画面を表示する）プログラム」とした本件発明４は、甲１発明及び甲２ないし甲５記載の事項に基づいて当業者が容易に発明をすることができたものであるということはできない。
（５−５−２）甲５を主たる引例とした主張について
（ａ）本件発明１と甲５発明との対比
　一致点、相違点は、上記（５−４−２）のとおりである。
（ｂ）相違点についての判断
　申立人は、上記相違点について、甲５に記載されていると述べるのみで、他の甲号証に記載された事項との検討を行っていない。
　そして、甲１ないし甲４の記載を見ても、上記相違点に相当する事項について開示が無いことは明らかである。
　したがって、本件発明１及び本件発明１の記載を引用する本件発明２、本件発明３、並びに本件発明１の「金融取引処理装置」の構成を「（画面を表示する）プログラム」とした本件発明４は、甲５発明及び甲１ないし甲４記載の事項に基づいて当業者が容易に発明をすることができたものであるということはできない。
　
第６　むすび
　したがって、特許異議の申立ての理由及び証拠によっては、請求項１〜４に係る特許を取り消すことはできない。　
　また、他に請求項１〜４に係る特許を取り消すべき理由を発見しない。
　よって、結論のとおり決定する。
【異議決定日】
令和２年１２月３日（２０２０．１２．３）