JP2022154916A - データ処理装置およびデータ処理方法 - Google Patents

Abstract

【課題】保有している本人確認処理結果を接続先システムに連携することによって、口座やアカウントの情報を一元的に管理するデータ処理装置およびデータ処理方法を提供する。【解決手段】銀行システムおよび決済サービス事業者システムと通信するデータ処理装置において、ユーザは、決済サービス事業者システムにアカウント登録申込を送信するＳ１００１。決済サービス事業者システムは、汎用ＩＤを含む認証要求をデータ処理装置に送信しＳ１００２、認証ステータスなどの情報をデータ処理装置から受信したことに応答して、ユーザに対する本人確認処理が完了したことを決定するＳ１００３。また、ユーザのために決済サービス用の利用者ＩＤを生成しＳ１００４、利用者情報、サービス名称、決済事業者コード、利用者ＩＤ、ＰＷをデータ処理装置に送信するＳ１００５。【選択図】図１０

Description

本発明は、銀行や決済サービスのシステムと接続され、保有している本人確認処理を行った結果を接続先システムに連携することによって接続先システムでの本人確認処理を簡易かつ安全に完了させ、接続先システムの口座やアカウントの情報を一元的に管理し、およびシステム相互の価値交換を実現するデータ処理装置およびデータ処理方法に関する。

近年、キャッシュレス化が進んでおり、現金の代替支払い手段として多くの決済サービスが利用されている。このような決済サービスとしては、電子マネー、コード決済（バーコード決済、二次元コード決済、及び類似のものを含む）が広く知られている。

２０１８年１２月、政府の国家戦略特区諮問会議が、現行法で認められていない電子マネーによる給与支払いを解禁する方針を打ち出した。従来、電子マネーによる給与支払いの構想（特許文献１、２）はあったものの実現できていなかった。この方針を受けて、給与支払元企業が個人の電子マネーアカウントを指定して給与支払いを行うことにより、給与受取人は、直接的に給与を電子マネーとして受け取ることが可能となるスキームの検討がなされつつある。

特開２００３－１５７３４４号公報 特許第５１４１１５８号公報 特開２００３－１８７０７５号公報

ユーザが銀行や決済サービスに新規利用申込を行う際、銀行や決済サービスごとに本人確認手続きを行う必要がある。本人確認手続きの結果は、１口座、１アカウント単位に留まるため、ユーザが他の銀行や決済サービスにおいて本人確認手続きを既に行っていたとしても、新規に銀行口座開設の申込、決済サービス利用の申込をする際には改めて本人確認手続きを行う必要がある。本人確認手続きのための情報は、どの銀行や決済サービスでも同じであり、ユーザは、同じような手続きを何度も行わなければならず、そのような煩雑な手続きは負担であった。しかしながら、本人確認処理が不十分であると犯罪リスクが高くなってしまう。

本人確認手続きに関しては、ユーザが信頼できる機関に本人確認情報を提供しておき、その機関を介した簡易的かつセキュアな認証により口座開設やアカウント登録を行えるスキームに対するニーズが存在する。

銀行口座や決済サービスの世界では、各ユーザが開設した口座やアカウント単位で残高管理や明細管理が行われており、資金移動の際は、第１の口座やアカウントから第２の口座やアカウントに送金が行われていた。ユーザが様々な銀行口座や決済サービスのアカウントを有している場合、ユーザにとって重要なことは、それらの情報を一元的に管理し、他のユーザに対する資金移動をより効率的に行うことである。

特許文献３は、複数の口座情報を集約して表示する機能を開示しているものの、それは現在のような多様化した決済サービスに対処できる仕組みではなく、また、他のユーザに対する資金移動を効率的に行えるものではなかった。

個人間で資金移動を行う場合、送金先の口座番号やアカウント情報を聞き出し、その情報に基づいて資金移動を行うことになるが、口座番号やアカウント情報が誤っていると資金移動ができず、余計な手間や手数料がかかり、また、個々人では、送金に伴う手数料の知識が不足し、相手方がどのような決済サービスを利用しているのか分からないこともあり、選択した資金移動経路が最適なものであるかどうか分からなかった。

本発明は、このような課題を解決するためになされたものであり、銀行や決済サービスのシステムと接続され、保有している本人確認処理を行った結果を接続先システムに連携することによって接続先システムでの本人確認処理を簡易かつ安全に完了させ、接続先システムの口座やアカウントの情報を一元的に管理し、およびシステム相互の価値交換を実現するデータ処理装置およびデータ処理方法を提供することを目的とする。

本発明の一態様であるデータ処理装置は、第１のシステムと相互に情報を通信するデータ処理装置であって、前記第１のシステムから、認証要求を受信する手段であって、前記認証要求は、前記データ処理装置および前記第１のシステムにおいて同一のユーザを識別する第１のユーザ識別子と、前記第１のユーザ識別子に関連付けられる第１の認証情報とを含む、手段と、前記第１のユーザ識別子および前記第１の認証情報に基づいて、本人確認済情報を取得し、前記第１のシステムに前記本人確認済情報を送信する手段であって、前記本人確認済情報は、前記データ処理装置によって本人確認処理が成功裏に完了済であることを示す情報である、手段と、前記本人確認済情報に対する応答としての登録情報取得要求を前記第１のシステムから受信し、前記第１のユーザ識別子に関連付けられるユーザ情報を前記第１のシステムに送信する手段と、前記ユーザ情報に対する応答として、前記第１のユーザ識別子に関連付けられる利用者情報を前記第１のシステムから受信する手段を備えたことを特徴とする。

本発明によれば、本人確認、公的個人認証を行った結果をデータ処理装置が保有し、その本人確認、公的個人認証の結果を接続先システムに連携できるため、ユーザが所望の銀行口座開設や決済サービス利用の申込を行う場合、改めて本人確認書類を提出することなく、以前に行った本人確認手続きの結果を利用した簡易、かつ安全な方法で接続先システムに本人確認処理を行わせることができるようになり、ユーザの利便性が向上する。

本発明によれば、データ処理装置と連携する様々な銀行や決済サービスの認証情報および口座やアカウントに関する情報をデータ処理装置側で保持することで、ユーザに関連付けられた、接続先システムの口座やアカウントの残高を一元的に管理できるようになる。本発明に係るデータ処理装置は、複数の銀行システム、決済サービス事業者システムとの間でハブ的な役割を担うことから、それらシステム相互の価値交換（資金移動）を、ユーザに資金移動経路の選択を意識させずに、実現できるようになる。

本明細書において開示される実施形態の詳細な理解は、添付図面に関連して例示される以下の説明から得ることができる。
本発明の実施形態に係るシステム全体の構成図である。 本発明の実施形態に係るデータ処理装置１０のシステム構成図である。 本発明の実施形態に係るアカウント管理ＤＢ１０６のデータ構造の一例を示す図である。 本発明の実施形態に係る入出金管理ＤＢ１０７のデータ構造の一例を示す図である。 本発明に係るアカウント管理に関する処理を説明するフロー図である。 アカウント１０６－１および仮想口座番号１０６－２のデータの一例を示す。 本発明に係る振込受取処理を説明するフロー図である。 入出金管理ＤＢ１０７のデータ内容の一例を示す。 決済サービスのチャージ処理を説明するフロー図である。 データ処理装置１０と決済サービス事業者システム１４が連携して行う処理の一例を説明するフロー図である。 口座、アカウントの利用状況情報取得処理を説明するフロー図である。 本発明に係るデータ処理装置１０によって実行される資金移動処理を説明するフロー図である。 本発明に係る表示画面１３００の一例を示す図である。

本明細書では、「銀行」とは、一般社団法人全国銀行協会（本明細書では「全銀協」と呼ぶことにする）によって付与された４桁の金融機関コードを有する金融機関（例えば、銀行、信用金庫、信用組合、労働金庫、農協系、ゆうちょ銀行、など）を意味するものとして使用する。

本明細書では、「電子マネー」とは、貨幣価値をデジタル・データとしてＩＣカードやインターネットに接続されたサーバに記録し、貨幣価値の授受を電子的に行う仕組み（広辞苑第七版）を意味し、電子マネーの概念には、チャージ可能な電子的支払手段が含まれるが、特定のサービスに限定されることはない。

本明細書では、「決済サービス」とは、電子マネー、コード決済（バーコード決済、二次元コード決済、及び類似のものを含む）のサービスを含むものとして説明する。本発明に係るデータ処理装置１０および決済サービス事業者システム１４が扱う電子的価値情報（金銭的な価値に相当する情報）は、デジタルマネー、バリューなどとも呼ばれる。

本明細書では、以下のスキームについて説明する。
・給与支払元企業が従前の給与支払い手続きおよび給与支払いシステムを変更することなく、給与受取人が電子マネーで給与を受け取ることを実現するデータ処理装置のスキーム
・給与受取人が受け取った給与などの入金データを利用して所望の銀行口座に振込を行い、決済サービスにチャージすることができるデータ処理装置のスキーム
・ユーザが所望の銀行口座開設や決済サービス利用の申込を行う場合、改めて本人確認書類を提出することなく、以前に行った本人確認手続きの結果を利用した簡易、かつ安全な方法で接続先システムに本人確認処理を行わせるデータ処理装置のスキーム
・ユーザに関連付けられた、接続先システムの口座やアカウントの残高を一元的に管理するデータ処理装置のスキーム
・複数の銀行システム、および決済サービス事業者システムとの間でハブ的な役割を担い、それらシステム相互の価値交換（資金移動）を、ユーザに資金移動経路の選択を意識させずに、実現できるデータ処理装置のスキーム

（全体構成）
図１は、本発明の実施形態に係るデータ処理装置１０、銀行システム１１、企業システム１２、ユーザ端末１３、および決済サービス事業者システム１４を含むシステム全体の構成図である。図１では、各要素は１つずつしか示されていないが、これらは複数存在し得る。

図１に示されるように、データ処理装置１０は、銀行システム１１、ユーザ端末１３、および決済サービス事業者システム１４と相互に通信可能に接続される。銀行システム１１は、データ処理装置１０、企業システム１２、および決済サービス事業者システム１４と相互に通信可能に接続される。企業システム１２は、銀行システム１１およびユーザ端末１３と相互に通信可能に接続され得る。決済サービス事業者システム１４は、データ処理装置１０、銀行システム１１、およびユーザ端末１３と相互に通信可能に接続される。

データ処理装置１０は、新規のユーザがデータ処理装置１０に利用開始申込を行った場合、マイナンバーカードや住基カード、運転免許証等を利用した公的個人認証機構を介して当該ユーザの本人確認／認証処理を行い、本人確認／認証結果をアカウント管理ＤＢ１０６に格納し、汎用ＩＤをユーザに割り当てる。汎用ＩＤは、データ処理装置１０、銀行システム１１、および決済サービス事業者システム１４にログインするためのユーザＩＤとして利用され得る。この利用開始申込は、後述する仮想口座番号生成要求とともに行われてもよい。

データ処理装置１０は、ユーザ端末１３からの仮想口座番号生成要求に応答して、銀行システム１１に関連付けられる仮想口座番号をユーザに割り当て、ユーザ端末１３に送信する。本明細書で、「仮想口座番号」は、金融機関の口座識別子（すなわち、金融機関コード、店番号、預金種目、および口座番号）に相当する。仮想口座番号に含まれる店番号は、金融機関における仮想店舗の店番号を示す。

データ処理装置１０は、ユーザ端末１３から、各種依頼や指示を受信し、当該依頼や指示に関連する処理を実行し、関連する依頼や指示を対応するシステムに送信する。

データ処理装置１０は、銀行システム１１に関連付けられる仮想口座番号に対する振込データ（本明細書で「第１の振込データ」と呼ぶこととする）を銀行システム１１から受信し、第１の振込データに基づいてアカウント管理ＤＢ１０６および入出金管理ＤＢ１０７を更新する。第１の振込データは、ユーザの預金口座（金融機関に開設した実在口座）に振り込まれない振込情報の内容を示す。

データ処理装置１０は、ユーザに関連付けられる銀行口座を有する銀行システム１１およびユーザに関連付けられるアカウントを有する決済サービス事業者システム１４と通信を行い、ユーザの残高情報および明細情報を取得する。データ処理装置１０は、取得した残高情報および明細情報を一括して管理することができ、例えば、それらの情報をユーザ端末１３に表示し、それらの情報を利用して資金移動経路を決定することができる。

データ処理装置１０は、ユーザが銀行システム１１に新規口座を開設する際および決済サービス事業者システム１４に新規アカウントを開設する際、ユーザの本人確認／認証処理の結果やユーザに関する情報を銀行システム１１および決済サービス事業者システム１４に連携することができる。

銀行システム１１は、勘定系システムを有する。勘定系システムは、企業や個人の口座、決済サービス事業者自身の管理口座、および本明細書で説明するプール口座を有する。プール口座は、仮想店舗宛ての振込金額を一括して格納しておく（プールする）口座である。銀行システム１１は、受信した振込データに基づいて対応する口座への振込およびプール口座への入金処理を制御する。銀行システム１１は、プール口座に入金された振込の振込データを第１の振込データとしてデータ処理装置１０に送信する。銀行システム１１は、決済サービス事業者システム１４からのリアルタイム口振指示に応答して、プール口座の金額を更新することによって決済サービス事業者自身の管理口座に振替を行い、処理結果を決済サービス事業者システム１４に送信する。

企業システム１２は、従業員の勤怠管理を行って給与計算を行い、従業員に対する振込データを生成して銀行システム１１に送信する。企業システム１２は、ユーザの振込先情報（仮想口座番号）をユーザ端末１３から受信するように構成されていてもよい。

ユーザ端末１３は、有線または無線環境において動作可能な任意のタイプのデバイスである。ユーザ端末１３は、汎用ＩＤや仮想口座番号の払出要求をデータ処理装置１０に送信して、汎用ＩＤや銀行システム１１に関連付けられる仮想口座番号をデータ処理装置１０から受信する。ユーザ端末１３は、データ処理装置１０にログインして、チャージ依頼や送金依頼などの、各種依頼や指示をデータ処理装置１０に送信する。

ユーザ端末１３は、アカウント登録要求を決済サービス事業者システム１４に送信し、決済サービス事業者システム１４とデータ処理装置１０による所定の処理が完了後、生成されたアカウントを受信する。

決済サービス事業者システム１４は、ユーザに関連付けられる個人アカウントおよび銀行システム１１に関連付けられる銀行アカウントを有する。決済サービス事業者システム１４は、銀行アカウントに対するデジタルマネーのチャージ要求および銀行アカウントからユーザの個人アカウントに対するデジタルマネーのチャージ要求をデータ処理装置１０から受信し、当該要求に応答して銀行システム１１にリアルタイム口振指示を送信し、その結果に応じて銀行アカウントに対するチャージ、および銀行アカウントからユーザの個人アカウントに対する送金を行って、処理結果をデータ処理装置１０に送信する。

（システム構成）
図２は、本発明の実施形態に係るデータ処理装置１０のシステム構成図である。図２に示すように、データ処理装置１０は、一般的なコンピュータと同様に、バス１２０などによって相互に接続された制御部１０１、主記憶部１０２、補助記憶部１０３、インターフェース（ＩＦ）部１０４、および出力部１０５を備える。データ処理装置１０は、ファイル／データベースなどの形式で、アカウント管理ＤＢ１０６および入出金管理ＤＢ１０７を備える。

制御部１０１は、中央処理装置（ＣＰＵ）とも呼ばれ、データ処理装置１０の各構成要素の制御やデータの演算を行い、また、補助記憶部１０３に格納されている各種プログラムを主記憶部１０２に読み出して実行する。主記憶部１０２は、メインメモリとも呼ばれ、受信した各種データ、コンピュータ実行可能な命令および当該命令による演算処理後のデータなどを記憶する。補助記憶部１０３は、ハードディスク（ＨＤＤ）などに代表される記憶装置であり、データやプログラムを長期的に保存する。

図２の実施形態は、制御部１０１、主記憶部１０２および補助記憶部１０３を同一のコンピュータの内部に設ける実施形態について説明するが、他の実施形態として、データ処理装置１０は、制御部１０１、主記憶部１０２および補助記憶部１０３を複数個使用することにより、複数のコンピュータによる並列分散処理を実現するように構成することもできる。また、他の実施形態として、データ処理装置１０のための複数のサーバを設置し、複数サーバが一つの補助記憶部１０３を共有する実施形態にすることも可能である。

ＩＦ部１０４は、他のシステムや装置との間でデータを送受信する際のインターフェースの役割を果たし、また、システムオペレータから各種コマンドや入力データ（各種マスタ、テーブルなど）を受け付けるインターフェースを提供する。出力部１０５は、処理されたデータを表示する表示画面や当該データを印刷するための印刷手段などを提供する。

アカウント管理ＤＢ１０６は、ユーザの口座およびアカウントに関連する情報を格納するための、アカウント１０６－１、仮想口座番号１０６－２、銀行口座１０６－３、および決済サービスアカウント１０６－４を含む。図３は、本発明の実施形態に係るアカウント管理ＤＢ１０６のデータ構造の一例を示す図である。

アカウント１０６－１は、本人確認情報を含むユーザ情報、並びにユーザに関連付けられる口座およびアカウントの残高情報を格納する。アカウント１０６－１は、汎用ＩＤ３０１、ＰＷ３０２、認証ステータス３０３、認証媒体３０４、認証日時３０５、ユーザ情報３０６、表面残高３０７、取得日時３０８、およびシステム内残高３０９を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことができる。

汎用ＩＤ３０１は、データ処理装置１０によってユーザに割り当てられたユーザ識別子である。ＰＷ３０２は、当該ユーザのパスワードを示す。汎用ＩＤ３０１およびＰＷ３０２は、データ処理装置１０、銀行システム１１および決済サービス事業者システム１４において、同一ユーザとして識別されるためのユーザＩＤおよびパスワードとして利用され得る。

認証ステータス３０３、認証媒体３０４および認証日時３０５は、公的個人認証の実施状況に関するデータ項目である。認証ステータス３０３は、マイナンバーカード、住民基本台帳カード、運転免許証などを利用した公的個人認証が完了しているか否かのステータスを示す。認証媒体３０４は、公的個人認証に利用した媒体（例えば、マイナンバーカード）を示す。認証日時３０５は、公的個人認証が行われた日時（ＹＹＹＹ／ＭＭ／ＤＤ ＨＨ：ＭＭ：ＳＳ）を示す。ユーザ情報３０６は、ユーザの氏名、カナ氏名、性別、生年月日、住所、連絡先（例えば、電子メールアドレス）などのユーザ関連の情報を示す。

表面残高３０７は、ユーザに関連付けられるシステム内残高３０９、銀行口座、決済サービス事業者アカウントのそれぞれの残高を合算した金額を示す。取得日時３０８は、銀行口座の残高情報、決済サービスアカウントの残高情報を銀行システム１１および決済サービス事業者システム１４から取得した日時のうち最も古い情報を示す。システム内残高３０９は、データ処理装置１０においてユーザ単位に管理される残高を示す。システム内残高３０９の残高は、本明細書において「バリュー」と呼ばれてよい。

仮想口座番号１０６－２は、銀行システム１１に関連付けられる仮想口座番号の情報を格納する。仮想口座番号１０６－２は、汎用ＩＤ３０１、金融機関コード３１１、店番号３１２、預金種目３１３、および口座番号３１４を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことができる。

金融機関コード３１１は、金融機関の識別子であり、全銀協によって各金融機関に割り振られた統一金融機関コードに相当する。店番号３１２は、当該金融機関ごとに予め定められた仮想店舗を示す識別子である。すなわち、店番号３１２は、当該金融機関の実際の店舗に付与された番号以外の番号、すなわち、仮想店舗に付与された番号を示す。預金種目３１３は、口座の預金種目（例えば、「普通」「当座」など）を示す。口座番号３１４は、ユーザに割り振られた仮想店舗の口座番号である。

銀行口座１０６－３は、ユーザに関連付けられる銀行口座の情報を格納する。銀行口座１０６－３は、汎用ＩＤ３０１、金融機関コード３２１、店番号３２２、預金種目３２３、口座番号３２４、ＣＤ暗証３２５、残高３２６および残高更新日時３２７を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことができる。

金融機関コード３２１は、金融機関の識別子であり、全銀協によって各金融機関に割り振られた統一金融機関コードに相当する。店番号３２２は、当該金融機関の実際の店舗を示す識別子である。預金種目３２３は、口座の預金種目（例えば、「普通」「当座」など）を示す。口座番号３２４は、ユーザに割り振られた口座番号である。ＣＤ暗証３２５は、ＡＴＭやＣＤ（キャッシュディスペンサー）を利用する際の暗証番号である。残高３２６は、口座残高を示す。残高更新日時３２７は、口座残高が更新された日時を示す。

決済サービスアカウント１０６－４は、ユーザがアカウント登録している決済サービスの情報を格納する。決済サービスアカウント１０６－４は、汎用ＩＤ３０１、サービス名称３３１、決済事業者コード３３２、利用者ＩＤ３３３、ＰＷ３３４、残高３３５、および残高更新日時３３６を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことができる。

サービス名称３３１は、決済サービスの名称（例えば、〇〇Ｐａｙ、など）を示す。決済事業者コード３３２は、決済サービスを提供する事業者の識別子であり、決済サービス事業者システム１４に関連付けられる。利用者ＩＤ３３３は、決済サービス事業者システム１４によって割り当てられたユーザの識別子である。ＰＷ３３４は、決済サービス事業者システム１４によって割り当てられたユーザのパスワードである。残高３３５は、決済サービスにおけるユーザの残高情報を示す。残高更新日時３３６は、決済サービスにおけるユーザの残高情報が更新された日時情報を示す。

図２に戻って説明すると、入出金管理ＤＢ１０７は、ユーザのシステムアカウント（汎用ＩＤ）に関連付けられるバリュー（金銭的な価値に相当する情報）の入出金明細情報を格納する。

図４は、本発明の実施形態に係る入出金管理ＤＢ１０７のデータ構造の一例を示す図である。入出金管理ＤＢ１０７は、汎用ＩＤ３０１、取扱日４０１、入金額４０２、出金額４０３、差引残高４０４および摘要４０５を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことができる。

取扱日４０１は、バリューに関する入出金データが発生した日時情報を示す。入金額４０２は、入金データが発生した場合の入金額を示す。出金額４０３は、出金データが発生した場合の出金額を示す。差引残高４０４は、入出金データが発生した後の差引残高情報を示す。最新の差引残高４０４の値は、システム内残高３０９の値と等しくなる。摘要４０５は、入出金データの摘要情報を示す。摘要情報は、入金の種類（例えば、「給与」など）、入金処理に関連付けられる銀行の金融機関コード３１１、および資金移動先の銀行の金融機関コードや決済事業者コード、などを示してもよい。

（処理フロー：アカウント管理）
図５は、本発明に係るアカウント管理に関する処理を説明するフロー図である。図５の処理フローでは、新規ユーザに汎用ＩＤを発行する処理、および振込を振込依頼人が指定する金融機関を経由して受け取ることを希望するユーザに対して仮想口座番号を発行する処理を説明する。既に汎用ＩＤを付与されているユーザが新たに仮想口座番号の発行を希望する場合は、汎用ＩＤを発行する処理は省略される。

Ｓ５０１にて、データ処理装置１０は、新規利用申込をユーザ端末１３から受信する。新規利用申込は、ユーザ情報（例えば、氏名、カナ氏名、性別、生年月日、住所、連絡先（例えば、電子メールアドレス）、など）、ログインパスワード（ＰＷ）、公的個人認証のための情報を含む。

Ｓ５０２にて、データ処理装置１０は、新規利用申込を受信したことに応答して、総務省によって提供されている公的個人認証サービスなどとの連携により、公的個人認証情報（例えば、マイナンバーカード、運転免許証など）を利用した電子本人確認処理を行う。

Ｓ５０３にて、データ処理装置１０は、電子本人確認処理が成功裏に完了した後、汎用ＩＤを発行してユーザ端末１３に送信し、汎用ＩＤ、ＰＷ、公的個人認証に関するデータ、およびユーザ情報をアカウント１０６－１に格納する。図６（ａ）は、本人確認処理が成功裏に完了済の新規ユーザの情報を格納したアカウント１０６－１のデータの一例を示す。

Ｓ５０４にて、データ処理装置１０は、仮想口座番号生成要求をユーザ端末１３から受信する。仮想口座番号生成要求は、汎用ＩＤ、ＰＷおよび金融機関コードを含む。

Ｓ５０５にて、データ処理装置１０は、ユーザの仮想口座番号生成要求に応答して、金融機関コードに関連付けられる仮想口座番号を生成し、ユーザ端末１３に送信する。仮想口座番号は、金融機関コード、店番号、預金種目、および口座番号を含む。図６（ｂ）は、仮想口座番号１０６－２のデータの一例である。図６（ｂ）の例のユーザ（汎用ＩＤ）は、仮想口座番号を６つ有している。店番号３１２は、金融機関における仮想店舗の店番号である。口座番号３１４は、ユーザに割り振られた当該金融機関の仮想店舗の口座番号であり、データ処理装置１０は、重複しないように口座番号３１４をユーザに割り振る。データ処理装置１０は、金融機関の仮想店舗ごとに、口座番号３１４の情報を管理するテーブルを備えるように構成されてよい。本発明の一実施形態では、データ処理装置１０は、銀行システム１１に要求して仮想口座番号を生成するように構成されてもよい。

汎用ＩＤおよび仮想口座番号の発行が完了すると、ユーザは、汎用ＩＤをユーザＩＤとして利用することによって、データ処理装置１０によって提供される各種機能を利用することができ、銀行における口座開設および決済サービスにおけるアカウント登録を行うことができる。データ処理装置１０は、ユーザ端末１３からの要求に応答して、アカウント１０６－１および仮想口座番号１０６－２の更新および削除処理を行える。

ユーザは、仮想口座番号を給与支払元企業に給与受取用口座の情報として提供できる。仮想口座番号は、全銀協によって定められている口座体系に一致するため、企業システム１２が仮想口座番号を給与振込用口座番号として登録しても問題なく利用でき、給与支払元企業は、企業システム１２を改修する必要はない。仮想口座番号を給与振込用口座番号として登録することは、企業システム１２のオペレータによって行われてもよく、または、企業システム１２に接続したユーザ端末１３から行われてもよい。

（処理フロー：振込受取処理）
図７は、本発明に係る振込受取処理を説明するフロー図である。図７の処理フローでは、自行内での給与振込を一例として説明するが、本発明の技術思想は、ユーザに対する、給与振込以外の振込、および他行からの振込に対しても適用可能である。すなわち、ユーザは、入金口座番号を仮想口座番号に指定するだけで、本明細書で説明するスキームを利用できる。本処理フローの前提として、ユーザの仮想口座番号が給与振込用口座番号として企業システム１２に登録されているものとして説明する。

Ｓ７０１にて、企業システム１２は、ユーザを含む従業員の給与計算を行い、振込先口座の金融機関コードに基づいて、振込データを対応する銀行システム１１に送信する。銀行システム１１は、振込データを受信する。振込データは、全銀協のフォーマットに従った、従来と同じフォーマットのデータである。任意の決済サービスで給与を最終的に受け取ることを望んでいるユーザの振込データについては、上述した仮想口座番号が被振込口座情報として使用されている。

Ｓ７０２にて、銀行システム１１は、受信した振込データに含まれる店番号が仮想店舗を示すかどうかを判定する。銀行システム１１は、仮想店舗の店番号を格納するテーブルを有していてよい。読み出した店番号が仮想店舗を示す場合、Ｓ７０３に処理が進み、示さない場合、Ｓ７０４に処理が進む。

Ｓ７０３にて、銀行システム１１は、振込データに基づいて、振込元企業口座からプール口座に入金処理を行う。プール口座は、仮想店舗宛ての振込金額を一括して格納しておく（プールする）口座である。本発明の他の実施形態では、プール口座を口座番号ごと、すなわち、仮想口座番号ごとに分けて管理するように構成することも可能である。

Ｓ７０４にて、銀行システム１１は、振込データに基づいて、振込元企業口座からユーザの実口座に対する入金処理を行い、振込処理結果を企業システム１２に送信する。所定の理由により振込不可となった場合には、通常の手続に従い、組戻し処理や付替による振替入金などの事後処理が行われる。

Ｓ７０５にて、銀行システム１１は、プール口座に入金処理が行われた振込データ（すなわち、プール口座に対する入金明細データ）に基づいて、第１の振込データを生成し、データ処理装置１０に送信する。データ処理装置１０は、銀行システム１１から第１の振込データを受信する。

Ｓ７０６にて、データ処理装置１０は、受信した第１の振込データに含まれる金融機関コード、店番号、預金種目および口座番号（すなわち、仮想口座番号）を検索キーとして仮想口座番号１０６－２の対応する仮想口座番号のデータを特定し、仮想口座番号に関連付けられる汎用ＩＤ３０１を取得する。データ処理装置１０は、第１の振込データに基づいて入金データを生成し、入出金管理ＤＢ１０７に追加する。図８は、入出金管理ＤＢ１０７のデータの一例を示す。この例では、従前の残高が０だった汎用ＩＤに対して３０万円の給与が入金されたことを示しており、摘要４０５には、入金を受け取ったプール口座を有する銀行の金融機関コードと入金が給与振込であったこととが示されている（「０１３８ キユウヨ」）。なお、仮想口座番号のデータが特定できない場合、データ処理装置１０は、銀行システム１１に通知し、組戻し処理や付替による振替入金などの事後処理を行うよう依頼する。

図８に示した最新の差引残高４０４の値は、システム内残高３０９の値と等しくなる。システム内残高３０９は、電子マネーに類似するが、決済手段としてよりは、ユーザ個人が持つ価値をあらゆるデジタルマネーに変換するための価値尺度として機能し得る。デジタルマネーは銀行システム１１によるプール口座での資金保全を前提としており、データ処理装置１０で管理されるシステム内残高３０９と同じ額が、接続先の１または複数の銀行システム１１の銀行口座に資金移動され得、および決済サービス事業者の個人アカウントに価値移転され得る。

本発明の一実施形態では、データ処理装置１０は、ユーザ端末１３からの要求に応答して、ユーザのシステムアカウント（すなわち、汎用ＩＤ）に関連付けられる入出金管理ＤＢ１０７のデータをユーザ端末１３に送信でき、これにより、ユーザは、自身に振り込まれた金額の明細および残高を照会できるようになる。

本発明の一実施形態では、給与などの振込額の一部をシステム内残高３０９に加算し、残りをユーザの預金口座などに入金できる。かかる場合、データ処理装置１０は、ユーザ端末１３から、バリューへの入金額を指定する命令を受け取り、銀行システム１１に当該入金額を送信する。銀行システム１１は、ユーザの仮想口座番号宛ての振込額のうち入金額に相当する金額を、プール口座に入金し、残りの金額をユーザの実口座に入金する処理を行うことができる。プール口座に入金された金額は、図７を参照して説明したように、第１の振込データとしてデータ処理装置１０に送信され、システム内残高３０９に加算される。ユーザの実口座の情報は、ユーザ端末１３からデータ処理装置１０に送信され、データ処理装置１０から銀行システム１１に送信される。

（処理フロー：決済サービスのチャージ処理）
図９は、決済サービスのチャージ処理を説明するフロー図である。なお、「チャージ」と「送金」という用語は、交換可能に使用され得る。

Ｓ９０１にて、データ処理装置１０は、ユーザ端末１３からのアクセスに応答して、チャージ先の候補となる、ユーザに関連付けられる１または複数の決済サービス事業者をユーザ端末１３に送信する。ユーザは、ユーザ端末１３の画面上にて自らのシステムアカウント（汎用ＩＤ）の残高情報を参照しながら、チャージ先の決済サービス事業者、チャージ先の個人アカウント（決済サービス事業者の個人アカウント）およびチャージ金額を入力する。ユーザ端末１３は、チャージ先の決済サービス事業者、チャージ先の個人アカウントおよびチャージ金額を含むチャージ依頼をデータ処理装置１０に送信する。データ処理装置１０は、チャージ依頼をユーザ端末１３から受信する。チャージ金額に指定可能な金額は、送金元のシステムアカウント（汎用ＩＤ）に関連付けられているシステム内残高３０９の金額以下である。

Ｓ９０２にて、データ処理装置１０は、受信したチャージ依頼に含まれているチャージ先の決済サービス事業者の銀行アカウントを識別し、識別した銀行アカウントのＩＤおよびＰＷを利用して対応する決済サービス事業者システム１４にログインする。チャージ先の決済サービス事業者の銀行アカウントは、摘要４０５の内容（例えば、入金がどの銀行からなされたのか等の情報）に基づいて決定されてもよい。データ処理装置１０は、チャージ依頼に含まれるチャージ金額を銀行アカウントに対してチャージする第１のチャージ指示、および、チャージ金額を銀行アカウントからユーザの個人アカウントに対して送金する第２のチャージ指示を決済サービス事業者システム１４に送信する。第１のチャージ指示および第２のチャージ指示は、一括して送信されてよく、両者をまとめて「チャージ指示」と呼んでもよい。データ処理装置１０は、チャージ先の決済サービス事業者の銀行アカウントおよびＰＷの情報を有するように構成されていてよい。

Ｓ９０３にて、決済サービス事業者システム１４は、チャージ指示に応答して、銀行アカウントに関連付けられる銀行システム１１に対して、チャージ指示に含まれる金額のリアルタイム口振依頼を送信する。銀行アカウントは、決済サービス事業者における各銀行のアカウントであり、ログインした銀行アカウントによってリアルタイム口振依頼の送信先である銀行システム１１が特定される。

銀行システム１１は、リアルタイム口振依頼に応答して、プール口座から該当金額を減額する処理を行い、決済サービス事業者が銀行システム１１に有する口座に振替を行い、その処理結果（正常または異常）を決済サービス事業者システム１４に送信する。

Ｓ９０４にて、決済サービス事業者システム１４は、銀行システム１１から受信した処理結果が正常を示す場合、該当金額を銀行アカウントの残高に加算する。この処理により、銀行システム１１のプール口座から決済サービス事業者システム１４の銀行アカウントへの送金が行われたことになる。次に、決済サービス事業者システム１４は、チャージ指示にしたがって、ユーザの個人アカウントに対して該当金額を加算するとともに、銀行アカウントの残高から該当金額を減算する。この処理により、決済サービス事業者システム１４内の銀行アカウントからユーザの個人アカウントに送金が行われたことになる。

Ｓ９０５にて、決済サービス事業者システム１４は、チャージ指示の処理結果をデータ処理装置１０に送信し、データ処理装置１０は、チャージ指示の処理結果を受信する。データ処理装置１０は、チャージ指示の処理結果が成功裏に処理が完了したことを示すものである場合、ユーザの送金元のシステムアカウント（汎用ＩＤ）のシステム内残高３０９を減額するとともに、出金データを入出金管理ＤＢ１０７に追加する。

Ｓ９０６にて、データ処理装置１０は、チャージ依頼に対する処理結果をユーザ端末１３に送信する。

上記では、データ処理装置１０は、ユーザ端末１３からの依頼に応答して、指定された決済サービスへのチャージを行うように構成されていたが、本発明の他の実施形態では、所定の設定条件に基づいて、自動でチャージ処理を行うように構成されてもよい。

一実施形態では、データ処理装置１０は、ユーザ端末１３からチャージ指定日時の情報を受け取ることにより、上記のチャージ処理を指定日時に実行するように構成され得る。また、他の実施形態では、データ処理装置１０は、給与などの振込があったことをトリガーとして、チャージ処理を実行するように構成され得る。いずれの場合であっても、ユーザ端末１３が、上述したチャージ依頼のデータとともに、指定日時あるいはトリガーを事前に指定することにより、データ処理装置１０は、ユーザからの都度のチャージ依頼を受け取ることなく、自動でチャージ処理を実行できるようになる。

本発明の他の実施形態では、ユーザが他人の個人アカウントに対して送金を行うこともできる。かかる場合、Ｓ９０１にて説明したチャージ依頼に、他人が使用している決済サービス事業者およびチャージ先の他人の個人アカウントを含めるように変更すればよい。すなわち、個人アカウントをユーザ自身のものとするか、他人の個人アカウントとするかに応じて、自身の決済サービスへのチャージを行うか、他人の決済サービスへの送金を行うかを制御することができる。

本発明の他の実施形態では、チャージ先の決済サービス事業者は、地域通貨であってもよく、あるいは任意のポイントサービスであってもよい。かかる場合、システムアカウントの残高と地域通貨やポイントとの間の交換比率は、自治体や金融機関などによって任意に決定され得る。

（処理フロー：決済サービス事業者への新規登録、情報連携）
ユーザが銀行に口座開設する際、および決済サービスにアカウント登録する際、本人確認が必要である。図１０は、ユーザが任意の決済サービスにアカウント登録申込を行ったことに応答して、データ処理装置１０と決済サービス事業者システム１４が連携して行う処理の一例を説明するフロー図である。本発明の他の実施形態では、図１０に示す処理をデータ処理装置１０と銀行システム１１が連携して行ってもよい。本処理フローにより、データ処理装置１０において本人確認処理が完了しているユーザは、改めて本人確認書類を提出することなく、銀行口座を開設することや決済サービスにアカウント登録することができるようになる。

Ｓ１００１にて、ユーザ端末１３は、任意の決済サービスの決済サービス事業者システム１４にアカウント登録申込を送信する。アカウント登録申込は、ユーザに関連付けられる汎用ＩＤ３０１、ＰＷ３０２を少なくとも含む。データ処理装置１０は、ユーザ端末１３からアカウント登録申込を受信する。

Ｓ１００２にて、決済サービス事業者システム１４は、汎用ＩＤ３０１およびＰＷ３０２を含む認証要求をデータ処理装置１０に送信する。データ処理装置１０は、受信した汎用ＩＤ３０１およびＰＷ３０２に基づいてアカウント１０６－１に問い合わせを行い、汎用ＩＤ３０１に関連付けられる認証ステータス３０３、認証媒体３０４、および認証日時３０５の情報を取得する。認証日時３０５の情報が所定の期限内（例えば、〇年以内）であれば、データ処理装置１０は、認証ステータス３０３、認証媒体３０４、および認証日時３０５の情報を決済サービス事業者システム１４に送信する。

一方、認証日時３０５の情報が所定の期限内でなければ、データ処理装置１０は、改めて本人確認が必要である旨のメッセージを決済サービス事業者システム１４に送信し、決済サービス事業者システム１４は、そのメッセージを、Ｓ１００１にてアカウント登録申込を行ったユーザ端末１３に送信し、本処理フローを終了する。

Ｓ１００３にて、決済サービス事業者システム１４は、認証ステータス３０３、認証媒体３０４、および認証日時３０５の情報をデータ処理装置１０から受信したことに応答して、Ｓ１００１にてアカウント登録申込をしたユーザに対する本人確認処理が完了したことを決定する。決定後、決済サービス事業者システム１４は、登録情報取得要求をデータ処理装置１０に送信する。登録情報取得要求は、汎用ＩＤ３０１を含む。データ処理装置１０は、受信した汎用ＩＤ３０１に関連付けられるユーザ情報３０６の情報をアカウント１０６－１から取得し、決済サービス事業者システム１４に送信する。

Ｓ１００４にて、決済サービス事業者システム１４は、ユーザ情報を受信したことに応答して、ユーザのために決済サービス用の利用者ＩＤ３３３およびＰＷ３３４を生成し、汎用ＩＤ３０１、生成した利用者ＩＤ３３３、ＰＷ３３４、および受信したユーザ情報を決済サービス事業者システム１４のストレージに格納する。決済サービス事業者システム１４は、利用者ＩＤ３３３およびＰＷ３３４をＳ１００１にてアカウント登録申込を行ったユーザ端末１３に送信する。

Ｓ１００５にて、決済サービス事業者システム１４は、利用者情報（例えば、汎用ＩＤ３０１、サービス名称３３１（例えば、〇〇Ｐａｙ）、決済事業者コード３３２、利用者ＩＤ３３３、ＰＷ３３４）をデータ処理装置１０に送信する。データ処理装置１０は、利用者情報を決済サービスアカウント１０６－４に格納する。この処理により、データ処理装置１０および決済サービス事業者システム１４の間で、ユーザ情報および本人確認情報の連携が図られる。なお、本発明の他の実施形態において、データ処理装置１０と銀行システム１１が情報連携を行う場合、銀行口座１０６－３に格納される情報が利用者情報としてやり取りされる。

このように、データ処理装置１０の接続先の銀行システム１１における口座開設や決済サービス事業者システム１４におけるアカウント登録の際に、本人確認が必要となった場合、銀行システム１１および決済サービス事業者システム１４は、汎用ＩＤ３０１およびＰＷ３０２を利用してデータ処理装置１０から認証済情報を取得し、本人確認の代替とすることができる。

汎用ＩＤ３０１は、データ処理装置１０、銀行システム１１および決済サービス事業者システム１４で同一ユーザを識別するために利用可能なため、これらの装置・システムに対するシングルサインオン機能が利用可能となる。例えば、ユーザが、汎用ＩＤ３０１およびＰＷ３０２で決済サービス事業者システム１４にログインした場合、決済サービス事業者システム１４は、汎用ＩＤ３０１およびＰＷ３０２をデータ処理装置１０に送信し、データ処理装置１０において認証処理を行ってもらい、データ処理装置１０から決済サービス事業者システム１４における利用者ＩＤ３３３、ＰＷ３３４を受信するように構成されてもよい。これにより、決済サービス事業者システム１４は、汎用ＩＤ３０１およびＰＷ３０２で認証したことになる。

（処理フロー：口座、アカウントの利用状況情報取得処理）
図１１は、口座、アカウントの利用状況情報取得処理を説明するフロー図である。

Ｓ１１０１にて、データ処理装置１０は、ユーザ端末１３から情報取得要求を受信し、または予め定められた周期で生成された情報取得要求を受信する。情報取得要求は、汎用ＩＤ３０１を少なくとも含む。

Ｓ１１０２にて、データ処理装置１０は、情報取得要求に含まれる汎用ＩＤ３０１に基づいて、銀行口座１０６－３、および決済サービスアカウント１０６－４に問い合わせを行って、汎用ＩＤ３０１に関連付けられる銀行口座および決済サービスアカウントの、銀行システム１１および決済サービス事業者システム１４における認証情報を取得する。

Ｓ１１０３にて、データ処理装置１０は、銀行口座１０６－３から読み出した金融機関コード３２１に基づいて接続先の銀行システム１１を特定し、読み出した金融機関コード３２１、店番号３２２、預金種目３２３、口座番号３２４、およびＣＤ暗証３２５の情報を銀行システム１１に送信し、利用状況照会を行う。銀行システム１１は、該当する口座の残高および入出金明細を読み出し、データ処理装置１０に送信する。

データ処理装置１０は、決済サービスアカウント１０６－４から読み出した決済事業者コード３３２に基づいて接続先の決済サービス事業者システム１４を特定し、利用者ＩＤ３３３およびＰＷ３３４の情報を決済サービス事業者システム１４に送信し、利用状況照会を行う。決済サービス事業者システム１４は、利用者ＩＤ３３３およびＰＷ３３４に関連付けられるアカウントの残高および入出金明細を読み出し、データ処理装置１０に送信する。

Ｓ１１０４にて、データ処理装置１０は、銀行システム１１から受信した残高、および決済サービス事業者システム１４から受信した残高を合算する。合算された残高は、銀行システム１１および決済サービス事業者システム１４に格納されているユーザ（汎用ＩＤ）に関連付けられる金額の合計額を示す。データ処理装置１０は、合算された残高と、システム内残高３０９の値をさらに合算し、アカウント１０６－１の表面残高３０７に格納する。

図１１の処理により、データ処理装置１０は、ユーザに関連付けられるバリュー、銀行口座、および決済サービスアカウントの残高および利用状況を把握できるようになる。

本発明の他の実施形態では、情報取得要求は、汎用ＩＤ３０１、ＰＷ３０２を含む。データ処理装置１０は、接続先の銀行システム１１および決済サービス事業者システム１４に汎用ＩＤ３０１およびＰＷ３０２を送信することによって、ユーザに関連付けられる残高および入出金明細を取得するように構成されてもよい。

（処理フロー：ユーザ間の資金移動処理）
図１２は、本発明に係るデータ処理装置１０によって実行される資金移動処理を説明するフロー図である。本発明では、送金先の汎用ＩＤが既知であるユーザに対して資金移動処理を行う例を説明する。

Ｓ１２０１にて、データ処理装置１０は、ユーザ端末１３から資金移動指示を受信する。資金移動指示は、送金元ユーザの汎用ＩＤ、送金先ユーザの汎用ＩＤ、および送金額の情報を少なくとも含む。

Ｓ１２０２にて、データ処理装置１０は、資金移動指示に含まれる送金先ユーザの汎用ＩＤに基づいてアカウント１０６－１に問い合わせを行い、送金先ユーザの汎用ＩＤがアカウント１０６－１に存在するか否かを判定する。存在する場合、Ｓ１２０３に処理が進み、存在しない場合、Ｓ１２０７に処理が進む。

Ｓ１２０３にて、データ処理装置１０は、図１１を参照しながら説明した方法で、送金元ユーザの汎用ＩＤに関連付けられるシステム内残高３０９、並びに銀行口座および決済サービスアカウントの残高および利用状況を取得する。取得した情報は、第１の利用状況と呼ばれる。

Ｓ１２０４にて、データ処理装置１０は、図１１を参照しながら説明した方法で、送金先ユーザの汎用ＩＤに関連付けられるシステム内残高３０９、並びに銀行口座および決済サービスアカウントの残高および利用状況を取得する。取得した情報は、第２の利用状況と呼ばれる。

Ｓ１２０５にて、データ処理装置１０は、第１の利用状況と第２の利用状況とを比較して、資金移動経路を所定の基準に従って決定する。資金移動経路を決定するための所定の基準は、以下の基準であってよい。

第１の基準は、手数料最小化である。送金元ユーザと送金先ユーザが同じ銀行を利用している場合、同じ銀行かつ同じ営業店を利用している場合、同じ決済サービスを利用している場合などは、手数料が安くなるので、データ処理装置１０は、送金手数料情報（不図示）に基づいて、手数料が最小になる経路を選択することができる。

第２の基準は、送金先ユーザの利用頻度である。データ処理装置１０は、第２の利用状況に基づいて、最も利用頻度が高い銀行口座または決済サービスアカウントを決定する。これにより、データ処理装置１０は、送金先ユーザの利用頻度が高い銀行口座または決済サービスアカウントを送金先として選択することができる。

第３の基準は、着金までの所要日数である。データ処理装置１０は、資金移動指示を受信した日時に基づいて、送金先ユーザの汎用ＩＤに関連付けられる銀行口座および決済サービスアカウントのそれぞれに送金した場合の所要日数を算出する。例えば、資金移動指示を受信したタイミングが銀行の休日に該当する場合や営業時間外に該当する場合などは、銀行および決済サービスのそれぞれについて着金までの所要日数が異なってくる。これにより、データ処理装置１０は、着金までの所要日数が最小となる銀行口座または決済サービスアカウントを送金先として選択することができる。

本発明は、第１の基準～第３の基準に限定されることなく、他の基準に基づいて送金することが可能である。また、複数の基準を組み合わせて送金することも可能である。

Ｓ１２０６にて、データ処理装置１０は、Ｓ１２０５にて決定された資金移動経路に従って、送金処理を実行する。データ処理装置１０は、送金処理に伴い、送金元ユーザの送金元口座または送金元アカウントの減額処理を行うとともに、送金先ユーザの送金先口座または送金先アカウントの増額処理を行う。本発明の一実施形態では、システム内残高３０９が送金元および／または送金先として利用されてもよい。本発明の他の実施形態では、データ処理装置１０から送金元口座または送金元アカウントに対応する銀行システム１１または決済サービス事業者システム１４に対して送金指図を送信することで、送金処理を接続先システムに依頼することとしてもよい。

Ｓ１２０７にて、データ処理装置１０は、送金先の汎用ＩＤが存在せず、送金不可であることをユーザ端末１３に通知する。

（画面の一例）
図１３は、本発明に係る表示画面１３００の一例を示す図である。表示画面１３００に表示されるユーザの残高は、表面残高３０７の金額である。すなわち、この例では、ユーザ「外為 史郎」に関連付けられるバリュー、銀行口座および決済サービスアカウントの全ての残高が合算されて表示されている。

表示画面１３００は、各種メニューを提供する。「詳細残高」は、ユーザに関連付けられるバリュー、銀行口座および決済サービスアカウントのそれぞれの残高を提供する。「受取専用（仮想）口座情報」は、仮想口座番号の情報を提供する。「銀行／決済サービス口座情報」は、銀行口座および決済サービスアカウントの情報を提供する。「口座追加」は、仮想口座番号を新規取得する機能、銀行口座や決済サービスアカウントの情報を入力する機能を提供する。

（その他の処理）
データ処理装置１０は、銀行システム１１から依頼を受けて、仮想口座番号を銀行口座に付け替える処理を行うことができる。例えば、ユーザが仮想口座番号を２つ、銀行口座を１つ有しているケースを考える。銀行システム１１が仮想口座番号のうちの１つに対して、銀行口座への付け替え要求をデータ処理装置１０に送信する。付替え要求は、汎用ＩＤ３０１、付け替え対象の仮想口座番号の情報、付け替え後の銀行口座の情報（例えば、新たに設定したＣＤ暗証３２５など）を含む。データ処理装置１０は、付替え要求に応答して、銀行口座１０６－３に新規データを追加し、仮想口座番号１０６－２から対応するデータを削除あるいは使用不可にする。同様に、データ処理装置１０は、銀行システム１１から依頼を受けて、銀行口座を仮想口座番号に付け替える処理を行うこともできる。

以上、例示的な実施形態を参照しながら本発明の原理を説明したが、本発明の要旨を逸脱することなく、構成および細部において変更する様々な実施形態を実現可能であることを当業者は理解するだろう。すなわち、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。

１０ データ処理装置
１１ 銀行システム
１２ 企業システム
１３ ユーザ端末
１４ 決済サービス事業者システム
１０１ 制御部
１０２ 主記憶部
１０３ 補助記憶部
１０４ インターフェース（ＩＦ）部
１０５ 出力部
１０６ アカウント管理ＤＢ
１０６－１ アカウント
１０６－２ 仮想口座番号
１０６－３ 銀行口座
１０６―４ 決済サービスアカウント
１０７ 入出金管理ＤＢ

Claims (9)

1. 第１のシステムと相互に情報を通信するデータ処理装置であって、
   前記第１のシステムから、認証要求を受信する手段であって、前記認証要求は、前記データ処理装置および前記第１のシステムにおいて同一のユーザを識別する第１のユーザ識別子と、前記第１のユーザ識別子に関連付けられる第１の認証情報とを含む、手段と、
   前記第１のユーザ識別子および前記第１の認証情報に基づいて、本人確認済情報を取得し、前記第１のシステムに前記本人確認済情報を送信する手段であって、前記本人確認済情報は、前記データ処理装置によって本人確認処理が成功裏に完了済であることを示す情報である、手段と、
   前記本人確認済情報に対する応答としての登録情報取得要求を前記第１のシステムから受信し、前記第１のユーザ識別子に関連付けられるユーザ情報を前記第１のシステムに送信する手段と、
   前記ユーザ情報に対する応答として、前記第１のユーザ識別子に関連付けられる利用者情報を前記第１のシステムから受信する手段と
   を備えたデータ処理装置。
2. 前記登録情報取得要求を受信したことは、前記本人確認済情報を利用した前記第１のシステムによる本人確認処理の完了を示している、請求項１のデータ処理装置。
3. 前記本人確認済情報に含まれる認証日時情報が有効期限内を示さない場合、前記第１のシステムに前記本人確認済情報を送信せず、前記認証要求が認められない旨のメッセージを前記第１のシステムに送信する手段をさらに備えた、請求項１のデータ処理装置。
4. 受信した第２の情報取得要求に含まれる前記第１のユーザ識別子に基づいて、前記第１のシステムに関連付けられる口座残高およびアカウント残高を取得する手段と、
   前記第１のユーザ識別子に基づいて、前記データ処理装置に格納されている前記第１のユーザ識別子に関連付けられるシステム内残高を取得する手段と、
   前記口座残高、前記アカウント残高、および前記システム内残高を合算して前記ユーザの表面残高を算出する手段と
   をさらに備えた、請求項１のデータ処理装置。
5. 送金元ユーザの汎用ＩＤ、送金先ユーザの汎用ＩＤ、および送金額の情報を含む資金移動指示を受信する手段と、
   前記送金元ユーザの汎用ＩＤに基づいて、第１の利用状況を取得する手段であって、前記第１の利用状況は、送金元ユーザの前記第１のシステムにおける利用状況および残高と、前記送金元ユーザに関連付けられるシステム内残高とを含む、手段と、
   前記送金先ユーザの汎用ＩＤに基づいて、第２の利用状況を取得する手段であって、前記第２の利用状況は、送金先ユーザの前記第１のシステムにおける利用状況および残高と、前記送金先ユーザに関連付けられるシステム内残高とを含む、手段と、
   前記第１の利用状況および前記第２の利用状況を比較して、予め定められた基準にしたがって、資金移動経路を決定する手段と
   をさらに備えた、請求項１のデータ処理装置。
6. 前記予め定められた基準は、手数料最小化、前記送金先ユーザの利用頻度、および着金までの所要日数のうちの少なくとも１つである、請求項５のデータ処理装置。
7. 第１のシステムと相互に情報を通信するデータ処理装置によって実行されるデータ処理方法であって、
   前記第１のシステムから、認証要求を受信することであって、前記認証要求は、前記データ処理装置および前記第１のシステムにおいて同一のユーザを識別する第１のユーザ識別子と、前記第１のユーザ識別子に関連付けられる第１の認証情報とを含む、ことと、
   前記第１のユーザ識別子および前記第１の認証情報に基づいて、本人確認済情報を取得し、前記第１のシステムに前記本人確認済情報を送信することであって、前記本人確認済情報は、前記データ処理装置によって本人確認処理が成功裏に完了済であることを示す情報である、ことと、
   前記本人確認済情報に対する応答としての登録情報取得要求を前記第１のシステムから受信し、前記第１のユーザ識別子に関連付けられるユーザ情報を前記第１のシステムに送信することと、
   前記ユーザ情報に対する応答として、前記第１のユーザ識別子に関連付けられる利用者情報を前記第１のシステムから受信することと
   を備えるデータ処理方法。
8. 銀行システムおよび決済サービス事業者システムと通信するデータ処理装置であって、
   ユーザ識別子を含む登録依頼を前記銀行システムおよび前記決済サービス事業者システムから受信したことに応答して、前記ユーザ識別子に関連付けられる本人確認済情報を前記銀行システムおよび前記決済サービス事業者システムに提供することにより、前記銀行システムおよび前記決済サービス事業者システムによるユーザ認証を完了させる手段と、
   前記ユーザ識別子に関連付けられる第１の残高情報を前記データ処理装置から取得して第１の残高を算出する手段と、
   前記ユーザ識別子に関連付けられる第２の残高情報を前記銀行システムおよび前記決済サービス事業者システムから取得して、ユーザに関連付けられる第２の残高を算出する手段と、
   を備えたデータ処理装置。
9. 前記データ処理装置は、ユーザ端末と通信するようにさらに構成されており、
   送金元のユーザ識別子および送金先のユーザ識別子を前記ユーザ端末から受信する手段と、
   前記送金元のユーザ識別子に関連付けられる第１の利用状況を前記データ処理装置、前記銀行システムおよび前記決済サービス事業者システムから取得する手段と、
   前記送金先のユーザ識別子に関連付けられる第２の利用状況を前記データ処理装置、前記銀行システムおよび前記決済サービス事業者システムから取得する手段と、
   前記第１の利用状況および前記第２の利用状況を比較して、予め定められた基準にしたがって、資金移動経路を決定し、送金を実行する手段と
   をさらに備えた、請求項８のデータ処理装置。

Images