• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 全部申し立て 特36条6項1、2号及び3号 請求の範囲の記載不備  G06Q
審判 全部申し立て 特174条1項  G06Q
審判 全部申し立て 1項3号刊行物記載  G06Q
審判 全部申し立て 特36条4項詳細な説明の記載不備  G06Q
審判 全部申し立て 2項進歩性  G06Q
管理番号 1369018
異議申立番号 異議2020-700786  
総通号数 253 
発行国 日本国特許庁(JP) 
公報種別 特許決定公報 
発行日 2021-01-29 
種別 異議の決定 
異議申立日 2020-10-13 
確定日 2020-12-11 
異議申立件数
事件の表示 特許第6680943号発明「金融取引処理装置及びプログラム」の特許異議申立事件について、次のとおり決定する。 
結論 特許第6680943号の請求項1ないし4に係る特許を維持する。 
理由 第1 手続の経緯
特許第6680943号の請求項1?4に係る特許についての出願は、令和元年11月26日に特許出願され、令和2年3月24日にその特許権の設定登録がされ、令和2年4月15日に特許掲載公報が発行された。その後、その特許に対し、特許異議申立人 栗暢行(以下、申立人という。)により特許異議の申立てがされたものである。

第2 本件発明
特許第6680943号の請求項1?4の特許に係る発明は、それぞれ、その特許請求の範囲の請求項1?4に記載された事項により特定される以下のとおりのものである。(以下、それぞれ、本件発明1などという。A?Jなどの符号は申立人が付与した符号を援用した。)

【請求項1】
A.ネットワークを介し顧客から金融取引のための取引口座の口座開設要求を受け付ける受付部と、
B.前記取引口座を開設するための本人確認資料の提出方法を前記顧客に選択させ、前記選択された提出方法に対応する画面を前記顧客に表示する画面制御部と、
を有し、
C.前記画面制御部は、前記顧客について保持されている前記本人確認資料の有効性を前記本人確認資料の記載事項に基づき確認し、前記本人確認資料が有効でない場合、有効な本人確認資料を提出させる画面を表示する
D.金融取引処理装置。
【請求項2】
E.前記画面制御部は、前記本人確認資料をアップロードにより提出する第1の提出方法と、前記本人確認資料を郵送により提出する第2の提出方法との何れか一方を前記顧客に選択させる、請求項1記載の金融取引処理装置。
【請求項3】
F.前記画面制御部は、前記顧客について登録済みの顧客情報に基づき、前記取引口座を開設するために必要な前記本人確認資料の種別を特定し、前記特定した種別の本人確認資料を提出させる画面を前記顧客に表示する、請求項1又は2記載の金融取引処理装置。
【請求項4】
G.ネットワークを介し顧客から金融取引のための取引口座の口座開設要求を受け付ける処理と、
H.前記取引口座を開設するための本人確認資料の提出方法を前記顧客に選択させ、前記選択された提出方法に対応する画面を前記顧客に表示する処理と、
をコンピュータに実行させ、
I.前記表示する処理は、前記顧客について保持されている前記本人確認資料の有効性を前記本人確認資料の記載事項に基づき確認し、前記本人確認資料が有効でない場合、有効な本人確認資料を提出させる画面を表示する
J.プログラム。

第3 申立理由の概要
申立人は、概略以下のとおり主張している。
(ア)特許法第29条第1項第3号の規定に違反している旨の主張について
(ア-1)証拠として
1)特開2014-21765号公報(以下「甲1」という。)
を提出し、請求項1?4に係る特許は、甲1に記載された発明であるから、特許法第29条第1項第3号の規定に違反してされたものであり、請求項1?4に係る特許を取り消すべきものである旨の主張。
(ア-2)証拠として
5)国際公開第2007/018233号の再公表特許(以下「甲5」という。)
を提出し、請求項1?4に係る特許は、甲5に記載された発明であるから、特許法第29条第1項第3号の規定に違反してされたものであり、請求項1?4に係る特許を取り消すべきものである旨の主張。

(イ)特許法第29条第2項の規定に違反している旨の主張について
証拠として、甲1、甲5に加えて
2)特開2012-33003号公報(以下「甲2」という。)
3)国際公開第2018/088475号(以下「甲3」という。)
4)特開2007-293598号公報(以下「甲4」という。)
を提出し、
(イ-1)請求項2に係る特許は、甲5を主たる引例として、甲5に記載された発明に周知の技術(甲1、甲3、甲5の記載参照)を適用することにより、当業者が容易に発明をすることができたものである、
(イ-2)請求項3に係る特許は、甲1を主たる引例として、甲1に記載された発明に周知の技術(甲3、甲4の記載参照)を適用することにより、当業者が容易に発明をすることができたものである、
から特許法第29条第2項の規定に違反してされたものであり、請求項2、3に係る特許を取り消すべきものである旨の主張。

(ウ)特許法第17条の2第3項に規定する要件を満たしていない旨の主張について
本件特許についての出願は、令和元年11月26日に特許出願され、令和2年1月16日、及び、令和2年2月17日付の手続補正を経た後登録されたが、本件特許の特許請求の範囲にて特定される事項は、願書に最初に添付した明細書、特許請求の範囲又は図面(以下当初明細書等という。)に記載された事項と比較して、上記当初明細書等に記載されていない事項を含んでいるから、上記手続補正は、特許法第17条の2第3項の規定する要件を満たしていない旨の主張。

(エ)特許法第36条第6項第1号、同第2号に規定する要件を満たしていない旨の主張について
請求項1?4に係る特許は、その記載に、発明の詳細な説明に記載された範囲を超え、また、明確でない記載を含んでいるから、特許法第36条第6項第1号および同第2号の規定する要件を満たしていない旨の主張。

(オ)特許法第36条第4項第1号に規定する要件を満たしていない旨の主張について
請求項1?4に係る特許は、その記載に、発明の詳細な説明に当業者が実施できる程度に開示されていない事項を含んでいるから、特許法第36条第4項第1号の規定する要件を満たしていない旨の主張。

第4 各甲号証の記載
(1)甲1(特開2014-21765号公報)には、以下のとおりの記載がある。
【0001】
本発明は、口座申込システム、制御プログラム及び携帯情報端末に関する。

【0005】
そこで、本発明は、申込者に申込を断念させずに、金融機関の顧客獲得に結びつけるための口座申込システム、制御プログラム及び携帯情報端末を提供することを目的とする。

【0012】
(第1実施形態)
図1は、第1実施形態に係る口座開設システム100の全体構成を示す図である。
口座開設システム100は、銀行の口座開設の申込と、携帯情報端末1を用いたキャッシュカード機能の使用とを、携帯情報端末1の操作で行えるシステムである。ここで、キャッシュカード機能とは、口座開設済の預金口座への入金や預金口座からの払出、振込等の取引を、キャッシュカードと同様に携帯情報端末1を用いてATM(Automatic Teller Machine:現金自動預け払い機)で行えるものをいう。
口座開設システム100は、携帯情報端末1と、IC(Integrated Circuit)免許証3(情報記憶媒体)と、本人確認サーバ4と、発行サーバ5と、口座開設サーバ7(取引サーバ)と、Webサーバ8と、アプリ配信サーバ9-1と、アプリ管理サーバ9-2とを備えている。携帯情報端末1と、本人確認サーバ4と、発行サーバ5と、口座開設サーバ7と、Webサーバ8と、アプリ配信サーバ9-1と、アプリ管理サーバ9-2とは、通信ネットワークNを介して通信可能に接続されている。

【0014】
IC免許証3は、ICチップ3aを有するカード型の運転免許証である。ICチップ3aは、属性情報として免許証に記載の申込者の住所と、氏名と、生年月日とを記憶している。また、ICチップ3aは、IC免許証3を所有する申込者本人が定めた2種類のPIN(Personal Identification Number)(暗証情報)を記憶している。さらに、ICチップ3aは、証明情報として証明書と、発行者番号とを記憶している。
【0015】
本人確認サーバ4は、鍵情報を記憶する鍵情報記憶部4aを有する。本人確認サーバ4は、鍵情報記憶部4aを参照して、携帯情報端末1から受信した証明書が正当なものであるか否かを判定し、判定結果を携帯情報端末1に送信する。
発行サーバ5は、キャッシュカード機能を、携帯情報端末1に設定するための発行処理を行う。
口座開設サーバ7は、口座開設の処理を行う。口座開設サーバ7は、取引データとして、口座開設をした口座番号を有する。
Webサーバ8は、口座申込用のWebページを記憶する。
口座開設サーバ7と、Webサーバ8とは、銀行ごとに用意され、銀行システム内に設けられている。

【0017】
次に、口座開設システム100の主な装置の機能構成について説明する。図2は、第1実施形態に係る携帯情報端末1、本人確認サーバ4及び発行サーバ5の機能構成を示す図である。
携帯情報端末1は、上述したICチップ1aと、UIM1bとの他に、制御部10と、記憶部20と、タッチパネル26と、通信I/F(インタフェース)部28とを備える。
UIM1bが記憶する発行用アプリ22は、制御プログラム21の実行によってアプリ管理サーバ9-2からダウンロードされるキャッシュカード機能の発行に必要なソフトウェアである。発行用アプリ22は、発行処理部17の機能を実現する。
制御部10は、携帯情報端末1の全体を制御するCPU(中央処理装置)である。制御部10は、記憶部20に記憶されているオペレーティングシステム(OS)や各種アプリケーションプログラムを適宜読み出して実行することにより、上述したハードウェアと協働し、本発明に係る各種機能を実現している。
制御部10は、受付部11と、プログラム起動部12と、案内実行部13と、操作判断部14と、発行要求送信部15aと、アプリ起動部16と、発行処理部17と、完了報告送信部18とを備える。
【0018】
受付部11は、申込者によるタッチパネル26への操作を受け付ける。
プログラム起動部12は、受付部11が受け付けた操作に応じて、制御プログラム21を起動する。
案内実行部13は、口座申込のための案内を実行する。
操作判断部14は、受付部11が受け付けた操作が、案内実行部13により実行された案内に対応したものであるか否かを判断する。
発行要求送信部15aは、キャッシュカード機能の発行要求を、発行サーバ5に対して送信する。
アプリ起動部16は、アプリ管理サーバ9-2からダウンロードした発行用アプリ22を起動して実行する。
発行処理部17は、発行サーバ5との間で発行処理を行う。そして、発行処理部17は、キャッシュカード機能を携帯情報端末1で使用させるためのデータである取引用発行データを受信して、UIM1bに記憶する。発行処理部17の処理によって、携帯情報端末1には、キャッシュカード機能が備わる。
完了報告送信部18は、UIM1bに記憶されたことに応じて、完了報告として発行完了通知を発行サーバ5に対して送信する。

【0021】
本人確認サーバ4は、携帯情報端末1から受信した証明情報に基づき本人確認を行い、その結果を携帯情報端末1に送信するサーバである。
本人確認サーバ4は、制御部40と、記憶部45とを備える。
制御部40は、本人確認サーバ4の全体を制御するCPUである。制御部40は、記憶部45に記憶されているOSやアプリケーションプログラムを適宜読み出して実行することにより、上述したハードウェアと協働し、本発明に係る各種機能を実現している。
制御部40は、判定部41と、送信部42とを有する。
判定部41は、携帯情報端末1から受信した証明情報が正当であるか否か(証明情報の真贋)を、鍵情報記憶部4aに記憶された鍵情報を用いて判定する。ここで、携帯情報端末1は、証明情報として、証明書と発行者番号とをIC免許証3から取得して記憶している。そして、鍵情報は、IC免許証3に記憶された証明書の復号鍵であり、各都道府県の公安委員会が発行したものである。また、発行者番号は、都道府県ごとに有する鍵情報から該当する鍵情報を特定するのに用いられる。判定部41は、発行者番号をもとに鍵情報を特定し、特定した鍵情報により証明書を復号する。そして、証明書が復号できれば、証明書は、正当であると判断できる。
送信部42は、判定部41による判定結果を携帯情報端末1に対して送信する。

【0026】
次に、口座開設システム100の処理について説明する。初めに、口座申込からキャッシュカード機能の発行処理の流れについて説明する。図3は、第1実施形態に係る口座開設システム100での一連の処理を説明するための図である。図4は、第1実施形態に係る制御プログラム21に設定された複数の案内方法の例を示す図である。
図3の(#1)から(#7)までは、口座申込による口座開設のための処理である。
図3において、携帯情報端末1は、アプリ配信サーバ9-1から制御プログラム21をダウンロードして、記憶部20に記憶する(#1)。ダウンロードの方法は、例えば、インターネットのショッピングサイトのページから制御プログラム21をダウンロードしたり、Webサーバ8にアクセスしてそこからアプリ配信サーバ9-1を経由してダウンロードしたりするものである。なお、携帯情報端末1に予め制御プログラム21がインストールされている場合(プレインストール時)には、このダウンロードの処理は不要である。
次に、携帯情報端末1の受付部11は、申込者からの操作を受け付ける。携帯情報端末1のプログラム起動部12は、受け付けた操作がプログラム起動の操作であることに応じて、制御プログラム21を起動する。そして、携帯情報端末1の案内実行部13は、制御プログラム21に設定された複数の案内方法から優先順位の最も高い案内方法を選択して出力する。そうすることで、口座開設システム100は、口座申込処理を開始する(#2)。
【0027】
図4(a)は、制御プログラム21に設定されている複数の案内方法と、優先順位とを示す。優先順位は、予め利便性が高かったり、携帯情報端末1の操作が容易であったりするものを上位に設定してある。この図4(a)の例では、優先順位の最上位の「1」のものは、申込者が携帯情報端末1を操作するだけで口座開設が行え、かつ、口座開設までにかかる期間が短い方法である。優先順位の「2」のものは、申込者が携帯情報端末1を操作するだけで口座開設が行えるものであるが、本人確認作業を銀行から委託された第三者等が行うものであるので、口座開設までにかかる期間が先の方法に比べてやや長いものである。優先順位の「3」と「4」のものは、申込者が携帯情報端末1を操作し、かつ、郵送により口座開設を行う方法である。優先順位の「3」のものは、申込者が携帯情報端末1を操作して必要項目を入力するものである。他方、優先順位の「4」のものは、最寄りの店舗を探して申込書を取りにいくものである。よって、優先順位の「3」のものの方が、「4」のものよりも利便性が高い。
【0028】
図3に戻り、携帯情報端末1の案内実行部13は、制御プログラム21にしたがって順番に各案内項目を出力させる。
ここで、案内項目の一例を図4(b)に示す。まず、「1.」に示す説明によって、IC免許証3を申込者の手元に準備させる。その後、案内実行部13は、各案内項目を順番に出力させる。
そして、図3に示すように、申込者は、案内にしたがって準備したIC免許証3の情報を、携帯情報端末1に読み取らせる(#3)。
携帯情報端末1がIC免許証3を読み取れた場合には、携帯情報端末1は、本人確認サーバ4に対して通信する(#4)。
本人確認サーバ4の判定部41は、本人確認処理として判定処理を行い、本人確認サーバ4の送信部42は、判定結果情報を携帯情報端末1に送信する(#5)。また、判定結果情報が正当である場合に、本人確認サーバ4は、口座開設サーバ7に対して判定結果情報を送信し、口座開設処理を依頼する(#6)。
そして、携帯情報端末1は、判定結果情報を受信し(#5)、判定結果情報が正当である場合には、キャッシュカード機能の発行処理まで待機する。
口座開設サーバ7は、口座番号付与処理を行い(#7)、口座番号を付与する。口座番号付与処理は、口座番号を付与する前提として、申込者が口座開設をするのに適する者であるか否かの審査等の各種チェックを行う。
以上の処理により、口座開設システム100は、口座申込による口座開設を行うことができる。

【0031】
次に、上述で説明した口座申込の案内の処理の詳細について説明する。図5は、第1実施形態に係る携帯情報端末1の口座申込の案内に関するフローチャートである。図6及び図7は、第1実施形態に係る携帯情報端末1のタッチパネル26での表示例を示す図である。
ここで説明する処理は、図3の(#2)から(#5)までに対応する携帯情報端末1の処理である。
図5において、携帯情報端末1の受付部11が申込者の申込に関する操作を受け付けたことに応じて、携帯情報端末1のプログラム起動部12は、記憶部20に記憶された制御プログラム21を起動させる。そして、ステップS11において、携帯情報端末1の案内実行部13は、最も優先順位の高い案内を実行して、その案内の最初の案内項目を出力させる。
【0032】
ここで、最も優先順位の高い案内とは、図4(a)に示した例では、優先順位が「1」のものであり、最初の項目とは、図4(b)に示した例では、「1.」をいう。
ステップS12において、携帯情報端末1の受付部11は、申込者からの操作を受け付けたか否かを判断する。申込者からの操作を受け付けた場合(ステップS12:YES)には、制御部10は、処理をステップS13に移す。他方、申込者からの操作を受け付けていない場合(ステップS12:NO)には、制御部10は、引続きステップS12の処理を行い、申込者からの操作を待つ。
【0033】
ステップS13において、携帯情報端末1の操作判断部14は、受け付けた操作が案内に適切なものであるか否かを判断する。例えば、「IC免許証3を準備してください。準備できたら「OK」を選択してください。IC免許証3がない場合には「キャンセル」を選択してください。」という案内がされた場合について説明する。受け付けた操作が案内に適切なものであるとは、申込者によって「OK」が選択された場合をいう。申込者によって「キャンセル」が選択された場合には、操作判断部14は、受け付けた操作が案内に適切なものではないと判断する。受け付けた操作が案内に適切なものである場合(ステップS13:YES)には、操作判断部14は、処理をステップS15に移す。他方、受け付けた操作が案内に適切なものではない場合(ステップS13:NO)には、操作判断部14は、処理をステップS14に移す。
ステップS14において、携帯情報端末1の案内実行部13は、次に優先順位の高い案内を実行して、その案内の最初の案内項目を出力させる。案内実行部13は、例えば、優先順位が「1」のものを実行していた場合には、優先順位が「2」のものを実行する。そして、制御部10は、処理をステップS12に移す。
【0034】
ステップS15において、携帯情報端末1の制御部10は、口座申込処理を行う。口座申込処理とは、申込みに必要な情報を受け付けた場合に、口座申込みに必要な処理を行うことをいう。
ステップS16において、携帯情報端末1の制御部10は、実行していた口座申込処理が正常に終了したか否かを判断する。口座申込処理が正常に終了したとは、例えば、実行していた案内の最後の案内項目まで出力し、口座申込が完了した場合をいう。口座申込処理が正常に終了した場合(ステップS16:YES)には、制御部10は、本処理を終了し、キャッシュカード機能の発行処理に必要なIDを取得するまで待機する。他方、口座申込処理が正常に終了していない場合(ステップS16:NO)には、制御部10は、処理をステップS17に移す。
ステップS17において、携帯情報端末1の案内実行部13は、次に優先順位の高い案内を実行して、その案内の最初の案内項目を出力させる。その後、制御部10は、処理をステップS12に移す。
【0035】
図6を参照して、図5で説明したステップS12からステップS17までの処理の一例を説明する。図6は、例えば、優先順位が「1」の案内であって、IC免許証3が手元に用意された状態で、案内実行部13がタッチパネル26に出力させる案内の例である。
まず、(a)において、携帯情報端末1は、PINの入力画面を出力する(ステップS15)。申込者によって2種類のPINの入力がされて「次へ」が選択された場合に、携帯情報端末1は、タッチパネル26に(b)に示す指示画面を出力する(ステップS15)。
【0036】
申込者が携帯情報端末1をIC免許証3にかざすことで、携帯情報端末1は、ICチップ1aがIC免許証3のICチップ3aと通信し、入力されたPINと、ICチップ3aに記憶されているPINとが一致するか否かを照合する。そして、携帯情報端末1は、照合の結果、一致した場合には、ICチップ3aに記憶されている氏名、住所等の属性情報と、証明情報とを受信する。受信できたら、携帯情報端末1は、タッチパネル26に(c)に示す画面を出力(ステップS15)し、証明情報を本人確認サーバ4に送信する。他方、受信できなかったら、携帯情報端末1は、(d)に示すエラー画面を出力した上で、(f)に示す画面を出力する(ステップS16でNOが選択されたステップS17へ進む)。
【0037】
IC免許証3から情報が受信できた場合には、携帯情報端末1は、本人確認サーバ4に証明情報を送信することで、本人確認サーバ4での判定結果を受信する。携帯情報端末1は、本人確認ができなかった場合には、(e)に示すエラー画面を出力した上で、(f)に示す画面を出力する(ステップS16でNOが選択されたステップS17へ進む)。
(f)は、口座申込用のWebページにおけるURLの画面である。これは、申込者に他の案内にて引続き口座申込を行わせるためのものである。ここで、申込者がそのURLを選択することで、携帯情報端末1は、口座申込用のWebページへ遷移する。
【0038】
図6の例は、受け付けた操作が案内に対応していない場合に、携帯情報端末1が即時に他の案内を実行するものであった。しかし、図7の例のように、受け付けた操作が案内に対応していない場合であっても、携帯情報端末1は、少なくとも1回は申込者による操作のやり直しができるようにしてもよい。携帯情報端末1は、やり直してもなお操作が案内に対応していない場合に、他の案内を実行してもよい。

【0045】
このように、第1実施形態によれば、口座申込による口座開設に関して以下のような効果がある。
(1)口座開設システム100は、携帯情報端末1を用いて口座開設のための口座申込ができる。
申込者は、携帯情報端末1を用いて出力される案内にしたがって口座開設の申込ができる。
また、口座開設システム100は、複数の申込の案内を有することで、申込者の操作が案内に対応したものではない場合であっても、すぐに他の案内に誘導できる。よって、申込者が申込途中で断念することを防止でき、申込者の口座申込のモチベーションの高い状態を維持したままで、口座申込を行うことができる。銀行にとっては、顧客獲得に結びつけることができる。
【0046】
(2)口座開設システム100は、複数の案内の優先順位が予め決まっており、優先順位の高い案内から順に実行するので、例えば、口座開設までの期間が短い案内を最優先に実行することで、銀行と申込者との双方にとって利便性が高いものから順番に案内できる。
(3)口座開設システム100は、操作が案内に対応したものではない場合に、他の案内として口座申込用のWebページに誘導できる。よって、Webページに記載の内容に沿って申込者が口座申込を行うことができる。
【0047】
(4)口座開設システム100は、IC免許証3を用いて証明情報を受け付け、本人確認サーバ4で証明情報の正当性を判断することで、本人確認を行って、口座申込ができる。よって、本人確認作業を携帯情報端末1と、本人確認サーバ4と、IC免許証3とを用いて行うことができる。
(5)口座開設システム100は、入力された暗証情報が、IC免許証3に記憶された暗証情報に一致している場合に、IC免許証3に記憶されている証明情報と属性情報とを読み出すので、IC免許証3の読み出しを、申込者に限定できる。よって、口座開設システム100全体としてセキュリティ性が向上する。

以上の甲1の記載によれば、甲1には以下のとおりの発明が開示されている。(以下、甲1発明という。)

口座開設システム100は、携帯情報端末1と、IC(Integrated Circuit)免許証3(情報記憶媒体)と、本人確認サーバ4と、発行サーバ5と、口座開設サーバ7(取引サーバ)と、Webサーバ8と、アプリ配信サーバ9-1と、アプリ管理サーバ9-2とを備え、(【0012】)
携帯情報端末1と、本人確認サーバ4と、発行サーバ5と、口座開設サーバ7と、Webサーバ8と、アプリ配信サーバ9-1と、アプリ管理サーバ9-2とは、通信ネットワークNを介して通信可能に接続され、(【0012】)
IC免許証3は、ICチップ3aを有するカード型の運転免許証であって、ICチップ3aは、属性情報として免許証に記載の申込者の住所と、氏名と、生年月日とを記憶し、また、ICチップ3aは、IC免許証3を所有する申込者本人が定めた2種類のPIN(Personal Identification Number)(暗証情報)を記憶し、さらに、ICチップ3aは、証明情報として証明書と、発行者番号とを記憶し、(【0014】)
本人確認サーバ4は、鍵情報を記憶する鍵情報記憶部4aを有し、本人確認サーバ4は、鍵情報記憶部4aを参照して、携帯情報端末1から受信した証明書が正当なものであるか否かを判定し、判定結果を携帯情報端末1に送信し、(【0015】)
口座開設サーバ7は、口座開設の処理を行い、取引データとして、口座開設をした口座番号を有し、(【0015】)
Webサーバ8は、口座申込用のWebページを記憶し、(【0015】)
口座開設サーバ7と、Webサーバ8とは、銀行ごとに用意され、銀行システム内に設けられ、(【0015】)
携帯情報端末1は、制御部10と、記憶部20と、タッチパネル26と、通信I/F(インタフェース)部28とを備え、(【0017】)
制御部10は、受付部11と、プログラム起動部12と、案内実行部13と、操作判断部14と、発行要求送信部15aと、アプリ起動部16と、発行処理部17と、完了報告送信部18とを備え、(【0017】)
受付部11は、申込者によるタッチパネル26への操作を受け付け、(【0018】)
プログラム起動部12は、受付部11が受け付けた操作に応じて、制御プログラム21を起動し、(【0018】)
案内実行部13は、口座申込のための案内を実行し、(【0018】)
操作判断部14は、受付部11が受け付けた操作が、案内実行部13により実行された案内に対応したものであるか否かを判断し、(【0018】)
アプリ起動部16は、アプリ管理サーバ9-2からダウンロードした発行用アプリ22を起動して実行し、(【0018】)
発行処理部17は、発行サーバ5との間で発行処理を行い、(【0018】)
制御プログラム21に設定されている複数の案内方法と、優先順位は、予め利便性が高かったり、携帯情報端末1の操作が容易であったりするものを上位に設定してあり、この例では、優先順位の最上位の「1」のものは、申込者が携帯情報端末1を操作するだけで口座開設が行え、かつ、口座開設までにかかる期間が短い方法であり、優先順位の「2」のものは、申込者が携帯情報端末1を操作するだけで口座開設が行えるものであるが、本人確認作業を銀行から委託された第三者等が行うものであるので、口座開設までにかかる期間が先の方法に比べてやや長いものであり、優先順位の「3」と「4」のものは、申込者が携帯情報端末1を操作し、かつ、郵送により口座開設を行う方法であり、(【0027】)
口座申込の案内の処理の詳細は、携帯情報端末1の処理であって、(【0031】)
携帯情報端末1の受付部11が申込者の申込に関する操作を受け付けたことに応じて、携帯情報端末1のプログラム起動部12は、記憶部20に記憶された制御プログラム21を起動させ、(【0031】)
携帯情報端末1の案内実行部13は、最も優先順位の高い案内を実行して、その案内の最初の案内項目を出力させ、(【0031】)
携帯情報端末1の受付部11は、申込者からの操作を受け付けた場合(ステップS12:YES)には、制御部10は、処理をステップS13に移し、(【0032】)
携帯情報端末1の操作判断部14は、受け付けた操作が案内に適切なものであるか否かを判断し、申込者によって「OK」が選択された場合、操作判断部14は、処理をステップS15に移し、ステップS15において、携帯情報端末1の制御部10は、口座申込処理を行い、実行していた口座申込処理が正常に終了した場合、本処理を終了し、操作判断部14で、受け付けた操作が案内に適切なものではない場合(ステップS13:NO)には、案内実行部13は、次に優先順位の高い案内を実行して、その案内の最初の案内項目を出力させ、(【0033】、【0034】)
口座申込処理は、携帯情報端末1の案内実行部13が、制御プログラム21に設定された複数の案内方法から優先順位の最も高い案内方法を選択して出力することにより開始され、(【0026】)
申込者は、案内にしたがって準備したIC免許証3の情報を、携帯情報端末1に読み取らせ、(【0028】)
携帯情報端末1がIC免許証3を読み取れた場合には、携帯情報端末1は、本人確認サーバ4に対して通信し、(【0028】)
本人確認サーバ4の判定部41は、本人確認処理として判定処理を行い、本人確認サーバ4の送信部42は、判定結果情報を携帯情報端末1に送信し、(【0028】)
判定結果情報が正当である場合に、本人確認サーバ4は、口座開設サーバ7に対して判定結果情報を送信し、口座開設処理を依頼し、(【0028】)
口座開設サーバ7は、口座番号付与処理し、(【0028】)
口座開設システム100は、口座申込による口座開設を行う、(【0028】)
口座開設システム。

(2)甲2(特開2012-33003号公報)には、以下のとおりの記載がある。
【請求項1】
顧客の本人確認証を読取る読取部と
前記読取部により読取られた前記本人確認証の内容と、前記顧客の登録済み本人確認証の内容とを比較する本人確認部と
を備え、
前記本人確認部が行う比較は、前記本人確認証の有効期限と、前記登録済み本人確認証の有効期限との比較を含む、窓口端末。
【請求項2】
前記本人確認部により前記本人確認証が有効であると判断された場合に取引を実行する取引処理部をさらに備え、
前記本人確認部は、前記本人確認証の有効期限と、前記登録済み本人確認証の有効期限が一致しない場合、双方の有効期限の関係に基づいて前記本人確認証の有効性を判断する、請求項1に記載の窓口端末。
【請求項3】
前記本人確認部は、前記登録済み本人確認証の有効期限が切れており、かつ、前記本人確認証の有効期限が切れていない場合、前記本人確認証と前記登録済み本人確認証とで前記有効期限以外の内容が一致するか否かに応じて前記本人確認証の有効性を判断する、請求項2に記載の窓口端末。
【請求項4】
前記登録済み本人確認証は、前記窓口端末とネットワークを介して配置された本人確認証記憶部に登録されており、
前記窓口端末は、
前記本人確認証記憶部から前記登録済み本人確認証を取得するための通信部を備える、請求項3に記載の窓口端末。
【請求項5】
前記通信部は、前記本人確認証の有効期限と前記登録済み本人確認証の有効期限が一致しないが、前記本人確認部により前記本人確認証は有効であると判断された場合、前記本人確認証の内容をサーバ装置に送信し、
前記本人確認証記憶部に記憶されている前記登録済み本人確認証の内容は、前記サーバ装置により、前記通信部から前記サーバ装置が受信した前記本人確認証の内容に更新される、請求項4に記載の窓口端末。

【0001】
本発明は、窓口端末、本人確認方法、および本人確認システムに関する。

【0007】
そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、現本人確認証と登録済み本人確認証の有効期限の関係を考慮して本人確認を行うことが可能な、新規かつ改良された窓口端末、本人確認方法、および本人確認システムを提供することにある。

【0025】
また、口座開設や所定金額を超える振込などの所定の取引を行う場合、顧客の本人確認を行う必要がある。したがって、オンライン窓口端末20は、顧客の本人確認が必要な取引に際しては、顧客から提示される本人確認証、および本人確認用サーバ12から得られる登録済み本人確認証の内容に基づき、顧客の本人確認を行う。

【0033】
(本発明の実施形態に至る経緯)
ここで、本発明と異なるオンライン窓口端末による本人確認について説明する。このオンライン窓口端末は、顧客の本人確認証を読取り、読み取った本人確認証の内容(写真、住所、氏名など)と、本人確認証DB14に登録済みの本人確認証の内容を比較し、顧客の本人確認を行う。

【0045】
この更新確認画面80において実行ボタン82がオペレータにより選択されると、登録済み本人確認証の内容を今回の本人確認証の内容で更新するための処理が実行される。一方、更新確認画面80においてキャンセルボタン84がオペレータにより選択された場合には、登録済み本人確認証の内容を更新するための処理は行われない。

【0053】
(関係A)
登録済み本人確認証の有効期限が切れていて、かつ、今回の本人確認証の有効期限は切れていない。
(関係B)
登録済み本人確認証の有効期限の方が今回の本人確認証の有効期限よりも未来の日付である。
【0054】
上記を補足すると、今回の本人確認証の有効期限と登録済み本人確認証の有効期限の関係が関係Aに該当する場合、今回の本人確認証の方が後に発行されたものであるので、今回の本人確認証は有効であると判断することが妥当である。したがって、本人確認部254は、今回の本人確認証の有効期限と登録済み本人確認証の有効期限の関係が関係Aに該当する場合、他の項目の一致不一致を再度確認し、他の項目が一致する場合、今回の本人確認証は有効であると判断する。

【0063】
そして、本人確認部254は、今回の本人確認証の有効期限と登録済み本人確認証の有効期限の関係が上述の関係Aに該当する場合、他の項目の一致不一致を再度確認する(S332)。そして、本人確認部254により他の項目が一致すると判断された場合、取引処理部256が取引を継続し、取引を成立させる(S336)。

以上の記載からみて、甲2には、「オンライン窓口端末による本人確認について、このオンライン窓口端末は、顧客の本人確認証を読取り、読み取った本人確認証の内容(写真、住所、氏名など)と、本人確認証DB14に登録済みの本人確認証の内容を比較し、顧客の本人確認を行う」ことが記載されている。

(3)甲3(国際公開第2018/088475号)には、以下のとおりの記載がある。
[0001]
本発明は、電子認証に係り、特に、一の事業者との関係で本人確認済みがされている個人又は組織体が、他の事業者との関係でも本人確認の認証が必要な場合に、一の事業者との関係で記憶されている本人確認済みの事実を用いて他の事業者のための本人確認の認証に利用する技術に関する。

[0026]
口座開設のためには、基本4情報の真偽を証明する本人確認書類を送付することが必要である。本人確認書類のコピー書面を郵送してもよいが、郵送の代わりに本人確認書類の電子データの送信も従来から行われている。ここでは、本人確認書類を電子データにしてA銀行に送信するものとする。もっとも、口座を開設するためには、インターネット経由だけではなく、対面での申込も存在する。

[0028]
ここまでの処理は、従来から既に行われてきたものであるが、本発明は、A銀行がユーザXの本人確認を行った事実を認証システム100に登録することで、A銀行以外の銀行等での口座開設時には本人確認済みの事実を利用できるという点に特徴がある。認証システム100に登録するか否かはユーザXからの申込みを前提とし、口座開設後、任意の時にユーザ登録アプリケーションを実行することによって認証システム100に登録することができる。

[0041]
<認証システム100の利用>
次に、ユーザXがA銀行以外の別の金融機関(例えば、B銀行とする。)に口座開設をする場合を想定する。ユーザXはB銀行の口座開設の申し込みをする際、従来であれば、B銀行もユーザXに対して本人確認書類の送信を要求し、A銀行と同じようにユーザXの本人確認作業を行うものであるが、本実施形態の場合、この本人確認作業を認証システム100に依頼する。

[0045]
上述したように、ユーザXは既にユーザ登録しているので、B銀行の端末である検証端末(V1)は、ユーザXにノンス(nonce)と呼ばれる使い捨てのランダムな値を発行すると、これに検証端末(V1)の電子署名を付与して、ユーザXの端末であるユーザPC(C1)に送信する(図2(A)の「2. nonce送信」参照)。
[0046]
A銀行の口座開設時と同様、検証端末(V1)の電子署名付きのノンスをユーザPC(C1)で受信したユーザXは、ユーザPC(C1)の画面上に表示されるQRコードを携
帯端末(C2)を用いて読み込む。QRコードにはB銀行に関する銀行情報が含まれており、例えば、携帯端末(C2)からB銀行に接続する接続先アドレスを含んでいる。携帯端末(C2)は、読み込んだQRコードから銀行情報及びユーザPC(C1)で受信されたノンスを受信する(図2(A)の「3. QRコード読取」参照)。
[0047]
図1(A)の「4. キーペア作成」で説明したとおり、携帯端末(C2)はC2用のキーペア(秘密鍵、公開鍵)を保管している。そこで、次に携帯端末(C2)は、受信したノンス及びC2公開鍵に対してC2秘密鍵を用いて電子署名を付与する。携帯端末(C2)の電子書署名付きのノンス及びC2公開鍵が検証端末(V1)に送信される(図2(A)の「4. ユーザ公開鍵送信」参照)。
[0048]
検証端末(V1)は、受信したC2公開鍵を用いて携帯端末(C2)の電子署名を検証し、携帯端末(C2)から送信されたデータの正当性を確認する。さらに、「2. nonce送信」の際に自身が発行したノンスと同一であるか否かを確認することで、ユーザXがB銀行の口座開設を望む真のユーザであることを確認する。ノンスの同一性を確認できなければ、ユーザX以外の者による登録手続として拒絶する。

以上の記載からみて、甲3には、「電子認証に係り、特に、一の事業者との関係で本人確認済みがされている個人又は組織体が、他の事業者との関係でも本人確認の認証が必要な場合に、一の事業者との関係で記憶されている本人確認済みの事実を用いて他の事業者のための本人確認の認証に利用する技術」が記載されている。

(4)甲4(特開2007-293598号公報)には、以下のとおりの記載がある。
【請求項1】
携帯端末を利用することによって、口座開設を含む金融取引サービスを受けることが可能な金融取引サービス方法であって、
銀行と携帯電話会社が端末固有番号を用いて情報を管理しつつ連携し、携帯電話会社の保有情報を活用した本人確認によって、銀行側の確認手続きを補完することを特徴とする、携帯端末を利用した金融取引サービス方法。

【請求項4】
請求項1記載の携帯端末を利用した金融取引サービス方法であって、
携帯電話会社が、携帯端末の契約時において、携帯契約者本人についての携帯電話会社用パスワード、および、前記携帯契約者本人の氏名と住所の情報を含む携帯契約者情報を取得しておき、また、前記契約者本人が前記携帯端末の利用を開始した後においては、携帯端末の利用料金の支払い状況を示す携帯料金支払い情報を前記携帯電話会社が管理しており、このような状況下において、前記携帯端末のユーザが、その携帯端末を利用して前記銀行に新規口座を開設する場合の手順は、
前記携帯端末から、前記端末固有番号と共に前記携帯電話会社用パスワードを、銀行サーバを経由して携帯電話会社サーバに、あるいは、直接、携帯電話会社サーバに送信する第1のステップと、
前記携帯電話会社サーバが、受信した前記パスワードと、前記端末固有番号に紐付けられて管理されているパスワードとの一致/不一致を判定して本人確認を行う第2のステップと、
この第2のステップにおいて前記パスワードの一致が確認された後、前記携帯電話会社サーバが、前記銀行サーバに向けて、前記携帯契約者情報および前記携帯料金支払い情報を送信する第3のステップと、
銀行サーバにて、前記携帯料金支払い情報を調査することによって、前記携帯端末の契約時に取得された前記契約者の住所における契約者本人の存在を確認する第4のステップと、
この第4のステップにて、前記住所における前記契約者本人の存在が確認できた場合に、銀行サーバは前記携帯契約者情報を参照して預金者ファイルを作成し、そして、正規の口座に比べて利用態様が制限された仮口座を開設する第5のステップと、
を、含むことを特徴とする、携帯端末を利用した金融取引サービス方法。
【請求項5】
請求項3または請求項4記載の携帯端末を利用した金融取引サービス方法であって、
前記仮口座の開設後に、銀行が、本人限定受取郵便にて、銀行用パスワードおよび口座利用開始登録に必要なアクセス情報を含む口座利用開始情報を、前記携帯契約者の住所に送付する第6のステップと、
前記携帯端末のユーザが、前記本人限定郵便を受け取り、前記アクセス情報が示す銀行サイトにアクセスして、前記端末固有番号および前記銀行用パスワードを含む前記口座利用開始情報を、前記銀行サーバに送信する第7のステップと、
前記銀行サーバが、受信した前記利用開始情報に含まれる前記銀行用パスワードおよびその他の情報の少なくとも一つと、携帯端末固有番号に紐付けられて管理されている銀行用パスワードおよびその他の情報の少なくとも一つ、との一致/不一致を判定し、一致を確認できた場合に、前記仮口座を、正規の口座に移行させる第8のステップと、
を、さらに含むことを特徴とする、携帯端末を利用した金融取引サービス方法。

【0001】
本発明は、携帯端末を利用した金融取引サービス方法および金融取引サービスシステムに関し、特に、携帯端末から銀行システムにアクセスして新規に銀行口座を開設することを可能とする携帯ダイレクトバンキング技術に関する。

【0012】
本発明は、このような考察に基づいてなされたものであり、携帯端末を利用したダイレクトバンキングによって銀行口座の開設を可能とすること、ならびに、その際の手続きを簡素化してユーザの負担を軽減すること、を目的とする。
【課題を解決するための手段】
【0013】
本発明の携帯端末を利用した金融取引サービス方法では、携帯端末を利用することによって、口座開設を含む金融取引サービスを受けることが可能な金融取引サービス方法であって、銀行と携帯電話会社が端末固有番号を用いて情報を管理しつつ連携し、携帯電話会社の保有情報を活用した本人確認によって、銀行側の確認手続きを補完する。

【0054】
銀行3は携帯電話会社1と通信回線を介してリンクしており、携帯契約者100から、端末固有番号と共に携帯電話会社用パスワードが送られてくると、ゲートウェイ装置(不図示)の接続先を、リンクしている携帯電話会社に切り替えて(手順Q2)、送られてきた情報をそのまま、携帯電話会社1に送信する(手順Q3)。この点、見かけ上は銀行3を経由しているものの、携帯電話会社用パスワードは、実質的には、直接に携帯電話会社1に送られているのに等しい。これは、情報セキュリティ上、携帯電話会社用パスワードの内容を銀行が知るのは好ましくないと考えられるからであり、ゆえに、銀行は、携帯電話会社用パスワードを、そのまま携帯電話会社1に転送するようにしたものである。なお、携帯電話会社用パスワードについては、上記のとおり、銀行が関与しないのが原則であるため、携帯契約者100が、端末固有番号と共に携帯電話会社用パスワードを、直接、銀行代理店としての携帯電話会社1に送信するようにしても特に、問題はない。

【0059】
料金支払いの確認がとれたときは、手順Q8に移行し、仮口座(正規の口座に比べて、利用態様が制限されている口座)を開設する。このとき、銀行3は、預金契約者番号、口座種類、口座番号の情報を預金者の仮口座に付与する。また、仮口座の開設には、預金者の氏名、住所、生年月日、携帯電話番号、メールアドレス等が必要であるが(通常は、口座開設の申請書に記載される事項である)、ここでは、手順Q5において、携帯電話会社1から送信されてくる携帯契約者情報2(氏名、住所、生年月日、携帯電話番号、メールアドレス等)を、そのまま援用して仮口座を開設する。

【0062】
次に、銀行3は、仮口座開設後に、本人限定受取郵便にて、銀行用のパスワード(B)(携帯契約時のパスワード(A)とは異なるもの)、口座利用開始登録に必要なアクセス情報(専用URL)を含む口座利用開始情報、その他、例えばキャッシュカード等を、携帯端末200の契約者100の住所90に送付する(手順Q9)。

【0064】
銀行3からの本人限定受取郵便を受領した本人100は、その後に、自己名義にお携帯端末200から、銀行の口座利用開始登録サイトにアクセスし、端末固有番号と共に、本人限定郵便で送付された銀行用パスワード(パスワード(B))等を送信する(手順Q10)。
【0065】
次に、銀行3は、パスワード(B)の照合確認を行い(手順Q11)、適正なパスワード(B)であることが確認できた時点で、本人確認法による手続きが完結したことになり、この時点で、正式の(通常の)口座を開設する(手順Q12)。これによって、その端末固有番号をもつ携帯端末について、すべての金融取引が許可されることになる。

以上の記載からみて、甲4には、「携帯電話会社が、携帯端末の契約時において、携帯契約者本人についての携帯電話会社用パスワード、および、前記携帯契約者本人の氏名と住所の情報を含む携帯契約者情報を取得しておき、また、前記契約者本人が前記携帯端末の利用を開始した後においては、携帯端末の利用料金の支払い状況を示す携帯料金支払い情報を前記携帯電話会社が管理しており、このような状況下において、前記携帯端末のユーザが、その携帯端末を利用して前記銀行に新規口座を開設する場合、銀行3は携帯電話会社1と通信回線を介してリンクしており、携帯契約者100から、端末固有番号と共に携帯電話会社用パスワードが送られてくると、ゲートウェイ装置(不図示)の接続先を、リンクしている携帯電話会社に切り替えて(手順Q2)、送られてきた情報をそのまま、携帯電話会社1に送信し、前記携帯電話会社サーバが、受信した前記パスワードと、前記端末固有番号に紐付けられて管理されているパスワードとの一致/不一致を判定して本人確認を行い、前記住所における前記契約者本人の存在が確認できた場合に、銀行サーバは前記携帯契約者情報を参照して預金者ファイルを作成し、そして、正規の口座に比べて利用態様が制限された仮口座を開設する金融取引サービス方法」が開示されている。

(5)甲5(国際公開第2007/018233号の再公表特許)には、以下のとおりの記載がある。
【請求項1】
金融機関に口座を開設する口座開設方法であって、
携帯端末において、口座開設用のWebコンテンツの提供する口座開設専用の携帯電話用アプリケーションソフトウェアをダウンロードするステップと、
当該携帯端末において、ダウンロードされた前記携帯電話用アプリケーションソフトウェアによって、申込者により入力された、少なくとも氏名、住所および生年月日を含む本人確認情報を、ネットワークを介して接続された金融機関のサーバに送信するステップと、
前記金融機関のサーバにおいて、前記本人確認情報を、当該本人確認情報を特定するための登録番号と関連付けて、申込情報データベースに記憶するステップと、
前記携帯端末において、前記登録番号を獲得するステップと、
前記携帯端末において、前記携帯電話用アプリケーションソフトウェアによって、当該携帯端末に搭載されたカメラにて撮影された本人確認書類のデジタルデータを、前記登録番号とともに前記金融機関のサーバに送信するステップと、
前記金融機関のサーバにおいて、前記本人確認書類のデジタルデータに基づくテキストデータを、前記登録番号と関連付けて、前記申込情報データベースに記憶するステップと、
前記金融機関のサーバにおいて、前記登録番号と関連付けられた前記本人確認書類のデジタルデータに基づくテキストデータと、当該登録番号と関連付けられた前記本人確認情報との確認の後に、前記本人確認情報を、新規の口座情報として、口座データベースに記憶するステップと、を備えたことを特徴とする口座開設方法。

【0001】
本発明は、インターネットなどのコンピュータネットワーク上で決済処理を行う電子決済システム、電子決済方法及びプログラムに関する。特には、電子決済システムにおいて手間やコストを掛けずに、安全且つ確実に新規口座を開設することができる口座開設方法に関する。

【発明が解決しようとする課題】
【0010】
しかしながら、上述したような口座開設方法によれば、一般的な方法では、本人確認書類の提出は、一般的には、紙に印刷された運転免許証の写し、住民票、健康保険証の写し、パスポートの写し等を直接金融機関に送付又は持参して行なわなければならず、手間や時間がかかるという問題があった。また、本人確認書類は、運転免許証等の原本をコピーして用いられるため、記載文字や本人の顔写真等が不鮮明になる場合があった。更に、本人確認書類は紙でのみ保存されるため、その保存や管理に手間がかかり、本人確認書類の劣化が生じるという問題があった。

【0031】
以下、図面を参照して本発明の口座開設方法の実施の形態を説明する。
図1は、本発明の口座開設方法を実行するシステムの一形態を示す図である。このシステムは、ユーザの口座情報などを有する金融機関の電子銀行サーバ10と、電子銀行サーバ10に口座を開設するための本人確認情報及び本人確認書類画像データを送信する通信機器であるカメラ付携帯電話20及びPC(Personal Computer)30などの端末(以下、単に「端末20,30」ともいう)と、PC30に接続され本人確認書類をデジタルデータに加工するデジタルカメラ30A及びスキャナ30Bと、カメラ付携帯電話20の通信キャリア40と、PC30のプロバイダ50と、電子銀行サーバ10、カメラ付携帯電話20、PC30、通信キャリア40及びプロバイダ50を通信可能に接続するネットワーク60と、を備えている。
【0032】
ここで、ネットワーク60は、インターネットやイントラネットを利用して構築することができる。
【0033】
また、運転免許証、各種健康保険証、パスポート、住民票の写し、印鑑証明書、外国人登録原票記載事項証明書などのいわゆる本人確認法施行規則定める書類の原本または写し(コピー)(以下、単に「本人確認書類」ともいう)70は、カメラ付携帯電話20に搭載されたカメラで撮影され、または、デジタルカメラ30Aで撮影されたりスキャナ30Bで読み取られたりして作成されたデジタルデータとして、カメラ付携帯電話20又はPC30より口座開設用のWebコンテンツ(又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理の場合(後述する)は単にネットワーク60)を介して、又は電子メールなどによって電子銀行サーバ10に送信される。

【0036】
電子銀行サーバ10は、ネットワーク60と通信可能に接続する通信制御部11と、口座情報を記憶する口座DB(Data Base)15と、口座DB15の口座情報に基づいて決済処理を行う決済処理部16と、ネットワーク60を介して、又は電子メールなどによって、端末20,30から受信したデジタルデータ(画像情報)をテキストデータに自動的に変換するデータ変換処理部13と、口座開設用のWebコンテンツ(口座開設専用の携帯電話用アプリケーションソフトウェアを含む)を記憶するWebDB17と、ネットワーク60を介して端末20,30にWebDB17に記憶されている本人確認情報を入力させて受信し、本人確認書類のデジタルデータ(画像情報)を作成させ、デジタルデータ(画像情報)を送信させて受信するためのWebコンテンツ(又は口座開設専用の携帯電話用アプリケーションソフトウェア)を提供し、端末20,30からWebコンテンツ(又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理)を介して入力された本人確認情報を受信し、データ変換処理部13で変換されたテキストデータと、受信した本人確認情報を比較し、該データと該情報が一致した場合に、新規の口座情報を記憶することによって新規の口座を口座DB15に開設する口座開設処理部12と、口座開設処理部12で受信した本人確認情報と、データ変換処理部13で変換されたテキストデータを記憶する申込情報DB14と、を備えている。

【0040】
また、口座開設処理部12は、データ変換処理部13において、デジタルデータ(画像情報)からテキストデータへの変換結果により判読不能とされた場合、再度本人確認書類のデジタルデータ(画像情報)の作成、送信を促すエラー通知を、ネットワークを介して、又は電子メールで本人確認書類のデジタルデータの送信元に自動的に送信し、口座開設用のWebコンテンツ又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理を介して、又は電子メールを通してユーザに対し通知する。

【0042】
図3及び図4は、本発明の口座開設方法のフローチャートである。図1?図4において、ユーザは、新規口座の開設申込を行うため、カメラ付携帯電話20又はPC30から口座開設用のWebコンテンツを提供する電子銀行サーバ10へアクセスする。(ステップ301)。

【0046】
この場合、カメラ付携帯電話20において、口座開設用のWebサイトへアクセスしたメインメニュー画面(Webページ)上の、(又は、メインメニュー画面(Webページ)での選択によりリンクされた口座開設専用の携帯電話用アプリケーションソフトウェアのダウンロード用画面(Webページ)上でもよい)ダウンロード用釦を選択することにより、電子銀行サーバ10より口座開設用のWebコンテンツ(当該Webページ)を介して、口座開設専用の携帯電話用アプリケーションソフトウェアをカメラ付携帯電話20へダウンロードする。(ステップ302)。
【0047】
アプリケーションソフトウェアが自動的に起動される。(ステップ303)。

【0051】
次に、カメラ付携帯電話20又はPC30から電子銀行サーバ10に本人確認情報(氏名、住所、生年月日など)を口座開設用のWebコンテンツ又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理を介して入力し、新規口座の開設申込を行う(ステップ304)。この入力が完了すると、電子銀行サーバ10の口座開設処理部12から登録番号が付与される。口座開設処理部12は、受け取った本人確認情報(氏名、住所、生年月日など)と登録番号を関連付けて申込情報DB14に記憶する。
【0052】
そして、電子銀行サーバ10は、ユーザの確認のため、本人確認書類の提出を要求する。ユーザは、この要求に応じて、運転免許証、各種健康保険証、パスポート、住民票の写し、印鑑証明書、外国人登録原票記載事項証明書などの本人確認書類70を準備し、本人確認書類70のデジタルデータ(画像情報)を作成する(ステップ305)。
【0053】
ここで、カメラ付携帯電話20に搭載されたカメラで運転免許証、住民票、健康保険証、パスポート等を撮影し本人確認書類70のデジタルデータ(画像情報)を作成ことができる。または、運転免許証、住民票、健康保険証、パスポート等をデジタルカメラ30Aで撮影したりスキャナ30Bで読み取ったりして作成することもできる。
【0054】
カメラ付携帯電話20で作成された本人確認書類70のデジタルデータ(画像情報)は、当該カメラ付携帯電話20から口座開設用のWebコンテンツ(又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理の場合は単にネットワーク60)を介して、又は電子メールで電子銀行サーバ10に送信され、また、デジタルカメラ30Aやスキャナ30Bで作成された本人確認書類70のデジタルデータ(画像情報)は、PC30に取り込まれ、PC30から口座開設用のWebコンテンツを介して、又は電子メールで金融機関の電子銀行サーバ10に送信される(ステップ306)。

【0056】
電子銀行サーバ10は、本人確認情報(氏名、住所、生年月日、当該書類の有効期限、登録番号等を含む)が記載された本人確認書類70のデジタルデータ(画像情報)を受信し(ステップ307)、データ変換処理部13は、受信した本人確認書類70のデジタルデータ(画像情報)を受け取り、氏名、住所、生年月日、当該書類の有効期限、登録番等を判読し(ステップ308)、判読可能であれば、テキストデータに変換し、申込情報DB14に記憶する(ステップ311)。
【0057】
ここで、本人確認書類70のデジタルデータ(画像情報)やテキストデータは、登録番号を付して登録管理される。また、本人確認書類70のデジタルデータ(画像情報)やテキストデータは、金融機関側で画面や紙に出力して確認することができる。なお、データ変換処理部13は、OCRソフトウェアの実行によって自動的にデジタルデータ(画像情報)を判読し、テキストデータに変換する。

【0059】
次に、口座開設処理部12は、登録番号に基づいて、本人確認情報と、テキストデータとを比較する確認チェックを行い(ステップ312)、該データと該情報が一致し、当該書類の有効期限が承認された場合に、口座DB16に新規の口座情報を記憶することによって新規の口座を開設する(ステップ315)。

【0061】
ステップ312で、本人確認ができなかった場合には、エラー通知をネットワーク60を介して、又は電子メールでカメラ付携帯電話20又はPC30に自動的に送信し、受信したカメラ付携帯電話20又はPC30において、口座開設用のWebコンテンツ又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理を介して、又は電子メールを通してユーザに対し通知し、(ステップ313)、ユーザが本人確認情報の修正などをする場合には(ステップ314)、ステップ304からの処理を行なう。

【0063】
図5は、本発明の口座開設方法の他の一例を示すフローチャートである。
本フローチャートは、PC30において新規口座の開設申込を行い、当該口座開設の申込完了後、携帯電話にてその後の口座開設に必要なステップを引き続き実行可能とする口座開設方法を示すものである。
【0064】
図1?図5において、ユーザは、新規口座の開設申込を行うため、PC30から口座開設用のWebコンテンツを提供する電子銀行サーバ10へアクセスする。(ステップ501(ステップ301に同じ))。
【0065】
次に、PC30から電子銀行サーバ10に本人確認情報(氏名、住所、生年月日など)を口座開設用のWebコンテンツを介して入力し、新規口座の開設申込を行う(ステップ502(ステップ304に同じ))。この入力が完了すると、電子銀行サーバ10の口座開設処理部12から登録番号が付与される。口座開設処理部12は、受け取った本人確認情報(氏名、住所、生年月日など)と登録番号を関連付けて申込情報DB14に記憶する。
【0066】
この時点をもって、PC30の口座開設申込み完了とし(ステップ503)、電子銀行サーバ10により本人確認情報などの申込者特定情報及び口座開設専用の携帯電話用アプリケーションソフトウェアのダウンロード用画面(Webページ)のURL(Uniform resource locator)情報を含む情報コードである2次元コード(QRコード(登録商標))80が生成され、口座開設用のWebコンテンツを介してPC30に表示する。(ステップ504)

【0069】
図6は、本発明の口座開設方法の他の一例を示すフローチャートである。
本フローチャートは、カメラ付携帯電話20において、PC30と同様に通常の口座開設フローである、口座開設用のWebサイト(電子銀行サーバ10)が提供するWebページの口座開設用のWebコンテンツを介して新規口座の開設申込を行い、当該口座開設の申込完了後、口座開設専用の携帯電話用アプリケーションソフトウェアの利用により、その後の口座開設に必要なステップを引き続き実行可能とする口座開設方法を示すものである。
【0070】
ここで、図6において、新規口座の開設申込から口座開設申込み完了までの、ステップ601からステップ603までは、図5のPC30によるステップ501からステップ503の場合と同様にて説明は省略する。
【0071】
口座開設申込み完了(ステップ603)後、カメラ付携帯電話20において、次に表示される本人確認書類送付方法を選択できる選択釦を含む画面(Webページ)上で「デジタルデータ送付」釦を選択し(ステップ604)、当該釦のハイパーリンク情報に含まれる、本人確認情報などの申込者特定情報及び口座開設専用の携帯電話用アプリケーションソフトウェアのダウンロード用画面(Webページ)のURL(Uniform resource locator)情報により、申込者特定情報などのユーザ情報を引き継いで当該ダウンロード用画面(Webページ)へリンクされ(ステップ605)、当該ダウンロード用画面(Webページ)上のダウンロード用釦を選択することにより、口座開設用のWebコンテンツ(当該ダウンロード用Webページ)を介して、ユーザ情報を引き継いで前記アプリケーションソフトウェアを前記携帯電話へダウンロードし(ステップ606)、口座開設専用の携帯電話用アプリケーションソフトウェアが自動的に起動される。(ステップ607)。
【0072】
カメラ付携帯電話20において、図5の場合と同様に、口座開設専用の携帯電話用アプリケーションソフトウェアは、引き継がれたユーザ情報である口座開設申込みでの本人確認情報などの申込者特定情報に基づき、金融機関への口座開設の申込に続く、ステップ305以降の、本人確認書類70のデジタルデータ(画像情報)の作成、デジタルデータ(画像情報)の電子銀行サーバ10への送信等の一連のステップを継続して行うことができる。
【0073】
これにより、カメラ付携帯電話20などのモバイルによる口座開設申込みにおいても、口座開設専用の携帯電話用アプリケーションソフトウェアの活用上、最も効果の高いと思われる本人確認書類70のデジタルデータ(画像情報)の作成、送付だけはアプリケーションソフトウェアの利用とすることもできる。

以上の甲5の記載によれば、甲5には以下のとおりの発明が開示されている。(以下、甲5発明という。)

ユーザの口座情報などを有する金融機関の電子銀行サーバ10と、電子銀行サーバ10に口座を開設するための本人確認情報及び本人確認書類画像データを送信する通信機器である端末と、電子銀行サーバ10と通信機器であるカメラ付携帯電話20とを通信可能に接続するネットワーク60と、を備え、(【0031】)
電子銀行サーバ10は、ネットワーク60と通信可能に接続する通信制御部11と、ネットワーク60を介して、端末20から受信したデジタルデータ(画像情報)をテキストデータに自動的に変換するデータ変換処理部13と、口座開設用のWebコンテンツ(口座開設専用の携帯電話用アプリケーションソフトウェアを含む)を記憶するWebDB17と、ネットワーク60を介して端末20にWebDB17に記憶されている本人確認情報を入力させて受信し、本人確認書類のデジタルデータ(画像情報)を作成させ、デジタルデータ(画像情報)を送信させて受信するためのWebコンテンツ(又は口座開設専用の携帯電話用アプリケーションソフトウェア)を提供し、端末20からWebコンテンツ(又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理)を介して入力された本人確認情報を受信し、データ変換処理部13で変換されたテキストデータと、受信した本人確認情報を比較し、該データと該情報が一致した場合に、新規の口座情報を記憶することによって新規の口座を口座DB15に開設する口座開設処理部12と、口座開設処理部12で受信した本人確認情報と、データ変換処理部13で変換されたテキストデータを記憶する申込情報DB14と、を備え、(【0036】)
カメラ付携帯電話20から口座開設用のWebコンテンツを提供する電子銀行サーバ10へアクセスし(ステップ301)、(【0042】)
カメラ付携帯電話20において、口座開設用のWebサイトへアクセスしたメインメニュー画面(Webページ)上の、(又は、メインメニュー画面(Webページ)での選択によりリンクされた口座開設専用の携帯電話用アプリケーションソフトウェアのダウンロード用画面(Webページ)上でもよい)ダウンロード用釦を選択することにより、電子銀行サーバ10より口座開設用のWebコンテンツ(当該Webページ)を介して、口座開設専用の携帯電話用アプリケーションソフトウェアをカメラ付携帯電話20へダウンロードし(ステップ302)、(【0046】)
カメラ付携帯電話20において、アプリケーションソフトウェアが自動的に起動され(ステップ303)、(【0047】)
カメラ付携帯電話20から電子銀行サーバ10に本人確認情報(氏名、住所、生年月日など)を入力し、新規口座の開設申込を行い(ステップ304)、この入力が完了すると、電子銀行サーバ10の口座開設処理部12から登録番号が付与され、口座開設処理部12は、受け取った本人確認情報(氏名、住所、生年月日など)と登録番号を関連付けて申込情報DB14に記憶し、(【0051】)
電子銀行サーバ10は、ユーザの確認のため、本人確認書類の提出を要求し、ユーザは、この要求に応じて、運転免許証、各種健康保険証、パスポート、住民票の写し、印鑑証明書、外国人登録原票記載事項証明書などの本人確認書類70を準備し、本人確認書類70のデジタルデータ(画像情報)を作成し(ステップ305)、(【0052】)
カメラ付携帯電話20で作成された本人確認書類70のデジタルデータ(画像情報)は、当該カメラ付携帯電話20から口座開設用のWebコンテンツ(又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理の場合は単にネットワーク60)を介して電子銀行サーバ10に送信され(ステップ306)、(【0054】)
電子銀行サーバ10は、本人確認情報(氏名、住所、生年月日、当該書類の有効期限、登録番号等を含む)が記載された本人確認書類70のデジタルデータ(画像情報)を受信し(ステップ307)、データ変換処理部13は、受信した本人確認書類70のデジタルデータ(画像情報)を受け取り、氏名、住所、生年月日、当該書類の有効期限、登録番等を判読し(ステップ308)、判読可能であれば、テキストデータに変換し、申込情報DB14に記憶し(ステップ311)、(【0056】)
口座開設処理部12は、登録番号に基づいて、本人確認情報と、テキストデータとを比較する確認チェックを行い(ステップ312)、該データと該情報が一致し、当該書類の有効期限が承認された場合に、口座DB16に新規の口座情報を記憶することによって新規の口座を開設し(ステップ315)、(【0059】)
ステップ312で、本人確認ができなかった場合には、エラー通知をネットワーク60を介してカメラ付携帯電話20に自動的に送信し、受信したカメラ付携帯電話20において、ステップ304からの処理を行なうものであって、(【0061】)
カメラ付携帯電話20における、通常の口座開設フローである、口座開設用のWebサイト(電子銀行サーバ10)が提供するWebページの口座開設用のWebコンテンツを介して新規口座の開設申込を行い、当該口座開設の申込完了後、口座開設専用の携帯電話用アプリケーションソフトウェアの利用により、その後の口座開設に必要なステップを引き続き実行可能とするフローでは、(【0069】)
カメラ付携帯電話20において、次に表示される本人確認書類送付方法を選択できる選択釦を含む画面(Webページ)上で「デジタルデータ送付」釦を選択し(ステップ604)、当該釦のハイパーリンク情報に含まれる、本人確認情報などの申込者特定情報及び口座開設専用の端末用アプリケーションソフトウェアのダウンロード用画面(Webページ)のURL(Uniform resource locator)情報により、申込者特定情報などのユーザ情報を引き継いで当該ダウンロード用画面(Webページ)へリンクされ(ステップ605)、当該ダウンロード用画面(Webページ)上のダウンロード用釦を選択することにより、口座開設用のWebコンテンツ(当該ダウンロード用Webページ)を介して、ユーザ情報を引き継いで前記アプリケーションソフトウェアを前記端末へダウンロードし(ステップ606)、口座開設専用の携帯電話用アプリケーションソフトウェアが自動的に起動され(ステップ607)、(【0071】)
口座開設専用の携帯電話用アプリケーションソフトウェアは、引き継がれたユーザ情報である口座開設申込みでの本人確認情報などの申込者特定情報に基づき、金融機関への口座開設の申込に続く、ステップ305以降の、本人確認書類70のデジタルデータ(画像情報)の作成、デジタルデータ(画像情報)の電子銀行サーバ10への送信等の一連のステップを継続して行うことができる、(【0072】)
口座開設方法を実行するシステム。

第5 判断
事案に鑑み、第3(ウ)、(エ)、(オ)についてまず検討する。
(5-1)特許法第17条の2第3項に規定する要件を満たしていない旨の主張(上記(ウ))について
当初明細書には以下のとおりの記載がある。

【0019】
受付部110は、ネットワークを介し顧客から金融取引のための取引口座の口座開設要求を受け付ける。例えば、インターネットバンキングにログインしている顧客が、銀行取引に加えて、新たに投資信託を購入するために投信口座の開設をインターネットバンキングのウェブページ上で申し込むと、受付部110は、口座開設要求の受付を画面制御部120に通知する。
【0020】
画面制御部120は、取引口座を開設するための本人確認資料の提出方法を顧客に選択させ、選択された提出方法に対応する画面を顧客に表示する。具体的には、顧客から口座開設要求があった旨を受付部110から通知されると、画面制御部120は、口座開設に必要とされる口座開設申込書と本人確認資料とを取得するための口座開設申込画面を顧客端末50に表示する。口座開設申込画面は、例えば、図4に示されるようなレイアウトを有してもよい。
【0021】
図4に示される口座開設申込画面では、画面制御部120は、口座開設申込書への入力が必要とされる氏名、住所等の個人情報を顧客に入力するよう求める。ここで、当該顧客はインターネットバンキングに登録しているため、氏名、住所等の個人情報は顧客情報として取得済みであり、顧客の入力負担を軽減するため、取得済みの顧客情報を利用して、口座開設申込に必要とされる個人情報は予め入力済みとして口座開設申込画面上で表示し、顧客に内容の確認のみ求めてもよい。確認の結果、内容に問題なければ、顧客は"OK"ボタンを押下し、変更がある場合、"変更"ボタンを押下する。
【0022】
さらに、画面制御部120は、本人確認資料の提出方法を顧客に選択させる。図示された口座開設申込画面では、画面制御部120は、ネットワークを介し本人確認資料の画像データなどを送信させる"WEBでアップロード"ボタンと、郵送により本人確認資料のコピーを提出する"郵送"ボタンとの2つの提出方法の選択肢を提示している。
【0023】
顧客が"WEBでアップロード"ボタンを押下した場合、画面制御部120は、図5に示されるような口座開設申込画面を顧客端末50上に表示する。図示された口座開設申込画面では、本人確認資料として、個人番号カード、又は、運転免許証と通知カードとをアップロードするよう顧客に要求している。顧客は、個人番号カード、又は、運転免許証と通知カードとを撮像し、"アップロード"ボタンを押下することによって当該画像データをアップロードする。その後、顧客は"口座開設"ボタンを押下し、口座開設申込手続を終了する。
【0024】
他方、顧客が"郵送"ボタンを押下した場合、画面制御部120は、図6に示されるような口座開設申込画面を顧客端末50上に表示する。図示された口座開設申込画面では、本人確認資料を郵送するための返送用キットを顧客の住所宛に送付することが通知される。その後、顧客は"口座開設"ボタンを押下し、口座開設申込手続を終了する。
【0025】
一実施例では、画面制御部120は、顧客について登録済みの顧客情報に基づき、取引口座を開設するために必要な本人確認資料の種別を特定し、特定した種別の本人確認資料を提出させる画面を顧客に表示してもよい。例えば、顧客が投資信託(投信)を取引するための投信口座の口座開設をインターネットバンキングを介し申し込む場合、当該銀行は基本的に顧客の顧客情報を既に取得している。このため、投信口座の口座開設に必要な本人確認資料のみを顧客に提出してもらえばよい。具体的には、当該銀行が顧客の運転免許証のコピーを既に取得済みである場合、画面制御部120は、運転免許証以外の本人確認資料を顧客に求める口座開設申込画面を顧客端末50上に表示してもよい。
【0026】
なお、顧客情報に保持されている運転免許証などの本人確認資料が有効期限切れ、住所変更、氏名改称などのために申込時点で有効なものでない場合、画面制御部120は、有効な本人確認資料を提出するよう顧客に求めてもよい。例えば、画面制御部120は、顧客情報に保持されている本人確認資料を有効性を確認し、保持されている本人確認資料が有効でない場合、有効な本人確認資料を再提出させるための画面を顧客端末50に表示してもよい。当該有効性の判断は、例えば、RPA(Robotic Process Automation)を利用して、顧客情報として保存されている本人確認資料のコピーを画像認識し、有効期限が切れているかなどを確認することによって行われてもよい。また、有効な本人確認資料が再提出された場合、あるいは、マイナンバーなどの以前は口座開設に必要とされていなかった個人情報が提出された場合、取得した情報は顧客情報に格納され、投信口座の開設のためだけでなく、銀行口座の顧客情報の更新にも利用されてもよい。

以上の記載によれば、
(a)受付部110は、ネットワークを介し顧客から金融取引のための取引口座の口座開設要求を受け付け、(【0019】)
(b)画面制御部120は、取引口座を開設するための本人確認資料の提出方法を顧客に選択させ、選択された提出方法に対応する画面を顧客に表示し、(【0020】)
(c)(選択された提出方法に対応する画面として)顧客が"WEBでアップロード"ボタンを押下した場合、画面制御部120は、図5に示されるような口座開設申込画面を顧客端末50上に表示すること、(【0023】)
(d)本人確認資料の例として、個人番号カード、又は、運転免許証と通知カードがあること、(【0023】)
(e)既に取得済みの本人確認資料の例として、運転免許証のコピーがあり、当該銀行が顧客の運転免許証のコピーを既に取得済みである場合、画面制御部120は、運転免許証以外の本人確認資料を顧客に求めること、(【0025】)
(f)顧客情報に保持されている運転免許証などの本人確認資料が有効期限切れ、住所変更、氏名改称などのために申込時点で有効なものでない場合、画面制御部120は、有効な本人確認資料を提出するよう顧客に求めること、(【0026】)
(g)顧客情報に保持されている本人確認資料を有効性を確認し、保持されている本人確認資料が有効でないと判断すること、(【0026】)
(h)当該有効性の判断は、顧客情報として保存されている本人確認資料のコピーを画像認識し、有効期限が切れているかなどを確認することによって行われてもよいこと、(【0026】)
が記載されており、上記(b)?(h)の制御は「画面制御部120」にて行うことも記載されている。
申立人の主張によれば、「口座開設のために提出された本人確認資料の有効性を当該本人確認資料の記載事項に基づいて確認すること、及び記載事項に基づいて確認することは記載されていない」とのことであるが、顧客が"WEBでアップロード"を選択し、運転免許証と通知カードにて本人確認を行おうとしたときには、上記実施例の「運転免許証」は、口座確認のために提出させる本人確認資料であって、かつ顧客情報に保持されている本人確認資料である。
そして、上記免許証の有効性の確認について、本人確認資料のコピーを画像認識し、有効期限が切れているかなどを確認することによって行うこと、本人確認資料が有効で無い場合、本人確認資料の提出を求めることも記載されているから、「前記顧客について保持されている前記本人確認資料の有効性を前記本人確認資料の記載事項に基づき確認し、前記本人確認資料が有効でない場合、有効な本人確認資料を提出させる」ことも記載されている。
したがって、請求項1の構成A?Cは当初明細書に記載されている。
なお、上記申立人の主張のうち、「口座開設のために提出された本人確認資料の有効性を当該本人確認資料の記載事項に基づいて確認すること、及び記載事項に基づいて確認することは記載されていない」の下線部は、特許請求の範囲の記載に基づいていない主張である。
また、請求項3の記載との関係において、構成Cと構成Fの構成をともに採用することは当初明細書に記載されていないとのことであるが、上記で検討したとおり、画面制御部が、構成C、構成Fの表示のための処理を行っていることは記載されており、これらの処理をともに行うことも、例えば、本人確認資料を実施例の「運転免許証」と置き換えれば、構成Fにて運転免許証が登録されている場合、これ以外の本人確認資料の提出を求めるが、構成Cにて運転免許証が有効で無い場合、運転免許証の提出も求める構成とすることは上記当初明細書の記載から読み取ることはできるから、当初明細書に記載されていないということはできない。
したがって、本件発明1、本件発明3についての申立人の主張は採用することができず、本件発明1とその記載を引用する本件発明2,本件発明3、及び本件発明1の「金融取引処理装置」の構成を「(画面を表示する)プログラム」とした発明である本件発明4は、当初明細書に記載された発明である。
よって、令和2年1月16日、及び、令和2年2月17日の手続補正は、特許法第17条の2第3項に規定する要件を満たすものである。

(5-2)特許法第36条第6項第1号、同第2号に規定する要件を満たしていない旨の主張(上記(エ))について
上記主張は
(i)「保持されている前記本人確認資料」はどのような資料であるか
(ii)「保持されている前記本人確認資料」と「前記取引口座を開設するための本人確認資料」との関係が不明確である
(iii)「本人確認資料が有効でない場合」とはどのような場合であるか
が不明確であり、また、発明の詳細な説明に記載された事項を超えた事項を含むという主張である。
まず、「保持されている前記本人確認資料」は、発明の詳細な説明の記載に「例えば、顧客が投資信託(投信)を取引するための投信口座の口座開設をインターネットバンキングを介し申し込む場合、当該銀行は基本的に顧客の顧客情報を既に取得している。このため、投信口座の口座開設に必要な本人確認資料のみを顧客に提出してもらえばよい。具体的には、当該銀行が顧客の運転免許証のコピーを既に取得済みである場合、画面制御部120は、運転免許証以外の本人確認資料を顧客に求める口座開設申込画面を顧客端末50上に表示してもよい。」とあるとおり、当該記載の「運転免許証」のことを指すから明確である。
次に、「前記取引口座を開設するための本人確認資料」とは、発明の詳細な説明に「画面制御部120は、図5に示されるような口座開設申込画面を顧客端末50上に表示する。本人確認資料として、個人番号カード、又は、運転免許証と通知カードとをアップロードするよう顧客に要求している。」と記載されているように、「個人番号カード」、「運転免許証と通知カード」などのことであるから明確である。
そして、これらの記載から、口座開設のために必要な本人確認資料として、「運転免許証と通知カード」を選択した場合、「運転免許証と通知カード」が「前記取引口座を開設するための本人確認資料」であり、当該銀行が顧客の運転免許証のコピーを既に取得済みである場合、「運転免許証」が「保持されている前記本人確認資料」に対応することも明白である。
ただし、このような本人確認資料は、システム構築時に当業者が適宜決定可能な事項であることは普通のことであり、「運転免許証と通知カード」、「運転免許証」を、「前記取引口座を開設するための本人確認資料」、「保持されている前記本人確認資料」と、それぞれ、上位概念化することは不自然ではない。
「本人確認資料が有効でない場合」とは、発明の詳細な説明に「顧客情報に保持されている運転免許証などの本人確認資料が有効期限切れ、住所変更、氏名改称などのために申込時点で有効なものでない場合」と記載があるから、このような場合を指すことは明確である。
ただし、先記したとおり、本人確認資料は、システム構築時に当業者が適宜決定可能な事項であって、また、有効性の確認も本人確認資料に記載された範囲においてどのようなものを利用するか適宜決定可能であるから、これらを、実施例の記載に限定する必要は無いことは技術常識である。
したがって、申立人の上記主張はいずれも採用することができない。
以上のことから、本件発明1と本件発明1の記載を引用する本件発明2、本件発明3、及び、本件発明1の「金融取引処理装置」の構成を「(画面を表示する)プログラム」とした発明である本件発明4は、いずれも特許法第36条第6項第1号、同第2号に規定する要件を満たすものである。

(5-3)特許法第36条第4項第1号に規定する要件を満たしていない旨の主張(上記(オ))について
上記主張は、「有効な本人確認資料を提出させる」の「有効な本人確認資料」とはどのような資料か、当業者が実施できる程度に、発明の詳細な説明が記載されていないというものである。
発明の詳細な説明には「なお、顧客情報に保持されている運転免許証などの本人確認資料が有効期限切れ、住所変更、氏名改称などのために申込時点で有効なものでない場合、画面制御部120は、有効な本人確認資料を提出するよう顧客に求めてもよい。例えば、画面制御部120は、顧客情報に保持されている本人確認資料を有効性を確認し、保持されている本人確認資料が有効でない場合、有効な本人確認資料を再提出させるための画面を顧客端末50に表示してもよい。」との記載があるから、本人確認資料が「運転免許証」である場合、本人確認資料としての運転免許証について、「有効期限切れ、住所変更、氏名改称などのために申込時点で有効なものでない」という事象が生じたら、「有効期限切れ、住所変更、氏名改称などのために申込時点で有効なものでない」という問題を解消した(すなわち有効な)運転免許証を提出させることを意味することは、上記記載から読み取ることができるから、申立人の上記主張は採用することはできない。
申立人は「すなわち、口座開設のために本人確認資料(例えば、新しい有効期限の資料)がすでに提出されているが、・・・」と主張しているが、「すでに提出されている」と述べるのみで、その主張の根拠が述べられていないから、申立人の上記主張は採用することはできない。
以上のことから、本件発明1と本件発明1の記載を引用する本件発明2、本件発明3、及び、本件発明1の「金融取引処理装置」の構成を「(画面を表示する)プログラム」とした発明である本件発明4は、いずれも特許法第36条第4項第1号に規定する要件を満たすものである。

(5-4)特許法第29条第1項第3号の規定に違反している旨の主張(上記(ア))について
(5-4-1)本件発明1と甲1発明との対比及び判断
甲1発明の「本人確認サーバ4」は、通信ネットワークNを介して通信可能に接続され、携帯情報端末1から受信した証明書が正当なものであるか否かを判定し、判定結果情報が正当である場合に、本人確認サーバ4は、口座開設サーバ7に対して判定結果情報を送信し、口座開設処理を依頼し、口座開設サーバ7は、口座番号付与処理を行い口座開設を行っている。
したがって、間接的にではあるが、本人確認サーバ4は、金融取引処理装置であって、「ネットワークを介し顧客から金融取引のための取引口座の口座開設要求を受け付ける受付部」を有しているといえる。
甲1発明では、複数の案内方法と、優先順位が設定され、申込者の操作により、優先順位が高い案内方法から低い案内方法に申し込み手順が変更され、上記申し込み手順の変更に伴い、申込者が携帯情報端末1を操作するだけで口座開設が行える案内方法から郵送により口座開設を行う方法まで案内方法が変更され、これに伴い、本人確認資料の提出方法も、携帯情報端末1の操作により提出する方法から、郵送により提出方法に変化するから、前記取引口座を開設するための本人確認資料の提出方法を前記顧客に選択させ、前記選択された提出方法に対応する画面を前記顧客に表示させているといえる。
もっとも、本件発明1では、上記表示のための処理を金融取引処理装置の画面制御部が、「前記取引口座を開設するための本人確認資料の提出方法を前記顧客に選択させ、前記選択された提出方法に対応する画面を前記顧客に表示する画面制御部」であるのに対し、甲1発明では、携帯情報端末にて、上記案内方法の変更のための処理が行われているからこの点で相違する。
甲1発明の本人確認サーバ4は、鍵情報記憶部4aを参照して、携帯情報端末1から受信した証明書が正当なものであるか否かを判定し、判定結果を携帯情報端末1に送信しているから、前記顧客について保持されている前記本人確認資料と、受信した本人確認資料との判定を行ってはいるが、「前記顧客について保持されている前記本人確認資料の有効性を前記本人確認資料の記載事項に基づき確認し」てはおらず、また、「前記本人確認資料が有効でない場合、有効な本人確認資料を提出させる画面を表示する」ことも行っていない。

以上のことからみて、甲1発明と本件発明1とは、以下の一致点で一致し相違点で相違する。

(一致点)
ネットワークを介し顧客から金融取引のための取引口座の口座開設要求を受け付ける受付部を有し、
前記取引口座を開設するための本人確認資料の提出方法を前記顧客に選択させ、前記選択された提出方法に対応する画面を前記顧客に表示することが可能な、
金融取引処理装置。

相違点1
「前記取引口座を開設するための本人確認資料の提出方法を前記顧客に選択させ、前記選択された提出方法に対応する画面を前記顧客に表示することが可能」とするための構成が、本件発明1では、金融取引処理装置が有する画面制御部であるのに対し、甲1発明では、携帯情報端末である点。

相違点2
本件発明1は、「前記画面制御部は、前記顧客について保持されている前記本人確認資料の有効性を前記本人確認資料の記載事項に基づき確認し、前記本人確認資料が有効でない場合、有効な本人確認資料を提出させる画面を表示する」という特定事項を有しているのに対し、甲1発明では当該特定事項を有していない点。

特に相違点2について、申立人は、甲1の【0028】、【0037】、【0038】に記載されていると主張しているが、【0028】には、本人確認サーバの確認結果が正当である場合の処理しか記載がなく、【0037】には、本人確認ができなかった場合として「本人確認ができなかった場合には、(e)に示すエラー画面を出力した上で、(f)に示す画面を出力する(ステップS16でNOが選択されたステップS17へ進む)。
(f)は、口座申込用のWebページにおけるURLの画面である。これは、申込者に他の案内にて引続き口座申込を行わせるためのものである。ここで、申込者がそのURLを選択することで、携帯情報端末1は、口座申込用のWebページへ遷移する。」との記載はあるが、これは案内方法の変更を行うことであって、「前記画面制御部は、前記顧客について保持されている前記本人確認資料の有効性を前記本人確認資料の記載事項に基づき確認し、前記本人確認資料が有効でない場合、有効な本人確認資料を提出させる画面を表示する」ことを開示しておらず、【0038】には「受け付けた操作が案内に対応していない場合に、携帯情報端末1が即時に他の案内を実行するものであった。しかし、図7の例のように、受け付けた操作が案内に対応していない場合であっても、携帯情報端末1は、少なくとも1回は申込者による操作のやり直しができるようにしてもよい。」との記載があるのみで、「受け付けた操作が案内に対応していない場合」の処理であるから、「前記画面制御部は、前記顧客について保持されている前記本人確認資料の有効性を前記本人確認資料の記載事項に基づき確認し、前記本人確認資料が有効でない場合、有効な本人確認資料を提出させる画面を表示する」ことについて、記載も示唆もされていない。
したがって、当該主張は採用することができず、上記相違点が存在するのであるから、本件発明1は甲1に記載された発明ではない。

本件発明2、本件発明3は本件発明1の記載を引用しさらに限定した構成を付加したものであり、本件発明4は、本件発明1の「金融取引処理装置」の構成を「(画面を表示する)プログラム」とした発明であって、上記相違点と同様の構成を有しているから、本件発明1と同様、甲1に記載された発明ではない。

(5-4-2)本件発明1と甲5発明との対比及び判断
甲5発明の電子銀行サーバは、端末からのアクセスを受けて、電子銀行サーバに、上記端末のユーザが口座を開設するための各種処理を行っているから、「ネットワークを介し顧客から金融取引のための取引口座の口座開設要求を受け付ける受付部」を有している。
甲5発明では、「端末において、次に表示される本人確認書類送付方法を選択できる選択釦を含む画面(Webページ)上で「デジタルデータ送付」釦を選択」することで、本人確認書類送付方法を選択しているから、「前記取引口座を開設するための本人確認資料の提出方法を前記顧客に選択させ、前記選択された提出方法に対応する画面を前記顧客に表示する画面制御部」を有している。
甲5発明では、電子銀行サーバ10は、本人確認情報(氏名、住所、生年月日、当該書類の有効期限、登録番号等を含む)が記載された本人確認書類70のデジタルデータ(画像情報)を受信しテキストデータに変換した情報と、(端末から電子銀行サーバ10に本人確認情報(氏名、住所、生年月日など)を口座開設用のWebコンテンツ又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理を介して入力した)本人確認情報とを比較して本人確認を行っているから、「前記顧客について保持されている前記本人確認資料の有効性を前記本人確認資料の記載事項に基づき確認し」ていない。
したがって、「前記本人確認資料が有効でない場合、有効な本人確認資料を提出させる画面を表示する」ことも行っていない。

以上のことからみて、甲5発明と本件発明1とは、以下の一致点で一致し相違点で相違する。

(一致点)
ネットワークを介し顧客から金融取引のための取引口座の口座開設要求を受け付ける受付部と、
前記取引口座を開設するための本人確認資料の提出方法を前記顧客に選択させ、前記選択された提出方法に対応する画面を前記顧客に表示する画面制御部と、
を有する、
金融取引処理装置。

(相違点)
本件発明1は、「前記画面制御部は、前記顧客について保持されている前記本人確認資料の有効性を前記本人確認資料の記載事項に基づき確認し、前記本人確認資料が有効でない場合、有効な本人確認資料を提出させる画面を表示する」という特定事項を有しているのに対し、甲5発明は、当該特定事項を有していない点。

上記相違点について、申立人は、『甲5には口座開設処理部12は、入力され保持されている本人確認書類(構成要件Cにおける「保持されている前記本人確認資料」に相当)の有効性を当該本人確認書類の記載事項に基づいて確認し(段落36)、本人確認書類が判別不能とされた場合、再度本人確認書類のデジタルデータ(画像情報)の作成、送信を促すエラー通知を、ネットワークを介して、又は電子メールで本人確認書類のデジタルデータの送信元に自動的に送信し、口座開設用のWebコンテンツ又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理を介して、又は電子メールを通してユーザに対し通知することが記載されている(段落40)』と主張している。
しかし、段落36の「端末20,30からWebコンテンツ(又は口座開設専用の携帯電話用アプリケーションソフトウェアの実行による処理)を介して入力された本人確認情報を受信し、データ変換処理部13で変換されたテキストデータと、受信した本人確認情報を比較し、該データと該情報が一致した場合に、新規の口座情報を記憶する」の処理は、端末からWebコンテンツを介して入力された本人確認情報とデータ変換処理部13で変換されたテキストデータ(本人確認書類の画像データをテキスト変換したデータ)とを比較する構成であるから、段落0059のステップ312の処理であり、段落40の「本人確認書類が判別不能とされた場合」とは、「データ変換処理部13において、デジタルデータ(画像情報)からテキストデータへの変換結果により判読不能とされた場合」のことであるから、段落0058の「ステップ308で、判読不能とされた場合」のことである。
すなわち、本人確認書類が判別不能であることと、本人確認書類が有効でないこととは異なっているのであるから、申立人の上記主張は採用することができない。
したがって、当該主張は採用することができず、上記相違点が存在するのであるから、本件発明1は甲5に記載された発明ではない。

本件発明2、本件発明3は本件発明1の記載を引用しさらに限定した構成を付加したものであり、本件発明4は、本件発明1の「金融取引処理装置」の構成を「(画面を表示する)プログラム」とした発明であって、上記相違点と同様の構成を有しているから、本件発明1と同様、甲5に記載された発明ではない。

(5-5)特許法第29条第2項の規定に違反している旨の主張(上記(イ))について
(5-5-1)甲1を主たる引例とした主張について
(a)本件発明1と甲1発明との対比
一致点、相違点は、上記(5-4-1)のとおりである。
(b)相違点についての判断
相違点2について検討する。
申立人は、上記相違点について、甲1に記載されていると述べるのみで、他の甲号証に記載された事項との検討を行っていない。
そして、甲2ないし甲5の記載を見ても、上記相違点2に相当する事項について開示が無いことは明らかである。
したがって、本件発明1及び本件発明1の記載を引用する本件発明2、本件発明3、並びに本件発明1の「金融取引処理装置」の構成を「(画面を表示する)プログラム」とした本件発明4は、甲1発明及び甲2ないし甲5記載の事項に基づいて当業者が容易に発明をすることができたものであるということはできない。

(5-5-2)甲5を主たる引例とした主張について
(a)本件発明1と甲5発明との対比
一致点、相違点は、上記(5-4-2)のとおりである。
(b)相違点についての判断
申立人は、上記相違点について、甲5に記載されていると述べるのみで、他の甲号証に記載された事項との検討を行っていない。
そして、甲1ないし甲4の記載を見ても、上記相違点に相当する事項について開示が無いことは明らかである。
したがって、本件発明1及び本件発明1の記載を引用する本件発明2、本件発明3、並びに本件発明1の「金融取引処理装置」の構成を「(画面を表示する)プログラム」とした本件発明4は、甲5発明及び甲1ないし甲4記載の事項に基づいて当業者が容易に発明をすることができたものであるということはできない。

第6 むすび
したがって、特許異議の申立ての理由及び証拠によっては、請求項1?4に係る特許を取り消すことはできない。
また、他に請求項1?4に係る特許を取り消すべき理由を発見しない。
よって、結論のとおり決定する。

 
異議決定日 2020-12-03 
出願番号 特願2019-213661(P2019-213661)
審決分類 P 1 651・ 536- Y (G06Q)
P 1 651・ 55- Y (G06Q)
P 1 651・ 113- Y (G06Q)
P 1 651・ 121- Y (G06Q)
P 1 651・ 537- Y (G06Q)
最終処分 維持  
前審関与審査官 久慈 渉  
特許庁審判長 高瀬 勤
特許庁審判官 上田 智志
渡邊 聡
登録日 2020-03-24 
登録番号 特許第6680943号(P6680943)
権利者 株式会社三菱UFJ銀行
発明の名称 金融取引処理装置及びプログラム  
代理人 伊東 忠重  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ