JP7101284B2 - 預金口座情報開示システム - Google Patents

Description

この出願の発明は、預金口座の情報をオーナー以外の第三者に開示する預金口座情報開示システムに関するものである。

銀行の預金口座の情報は、秘匿にされるべき情報として広く理解されている。特に、近年の振り込み詐欺のような犯罪の増加に伴い、新たな口座の開設には法律により本人確認が必要となっており、氏名、住所等の個人情報とともに、銀行口座の情報は、厳格に管理されている。

特定の個人や法人の名称を銀行に知らせてその者の口座があるかどうかを銀行に問い合わせても、銀行は口座番号等は決して知らせないし、ましてやその口座の残高等の情報を第三者に開示することはあり得ない。尚、預金口座の残高証明書の発行サービスが知られているが、このサービスも、本人にのみ証明書が交付されるのであり、銀行が第三者に直接開示する発想は、全く存在しない。

特開２０１３－５４４８７号公報 特開２００８－３０４９６２号公報 特開２０１３－５４４８７号公報 米国特許公開第２０１５／０３６３７７０号明細書 特開２００２－３５１８６４号公報

しかしながら、発明者は、預金口座の情報を銀行が第三者に直接開示する状況が非常に有益であると考えている。
かかる考えに基づき、この出願の発明は、預金口座の情報を銀行が第三者に直接開示する技術的手段を提供することを解決課題としている。「直接開示」とは、預金口座の保有者本人にまず開示し、本人が第三者に開示する結果、第三者に開示されるような経路の開示ではないという意味である。

上記課題を解決するため、本願の請求項１記載の発明は、オーナーが保有する預金口座の情報を第三者に開示する預金口座情報開示システムであって、
開示サーバを備えており、
開示サーバは、預金口座のオーナー及び預金口座の開設者以外の第三者が操作する端末である開示先端末からのアクセスをネットワークを介して受け付けるものであり、
開示サーバには、開示プログラムが実装されており、
開示プログラムは、開示先端末から預金口座特定情報とともに開示要求が送信された場合、当該預金口座の名義を取得して預金口座情報として開示先端末に送信して開示先端末において閲覧可能とするプログラムであり、
預金口座特定情報は、仮想通貨アドレスであり、
開示プログラムは、当該仮想通貨アドレスのオーナーが誰であるかの情報を預金口座情報として送信するプログラムであり、
開示サーバは、預金口座情報が真正であることを認証せずに開示先端末に送信して開示先端末において閲覧可能とするものであるという構成を有する。
また、上記課題を解決するため、請求項２記載の発明は、前記請求項１の構成において、前記開示サーバは、前記開示先端末から真正な開示用キーが送信された場合のみ前記預金口座情報を送信するプログラムであるという構成を有する。

以下に説明する通り、本願の請求項１記載の発明によれば、預金口座の名義の情報がリアルタイムに第三者に開示されるので、第三者において預金口座の情報をリアルタイムに知る必要がある場合、好適に利用されるシステムとなる。
そして、仮想通貨アドレスのオーナーが誰であるかの情報を第三者が知ることができるので、仮想通貨が将来的に普及していくのに貢献できる技術構成が提供される。
また、請求項２記載の発明によれば、上記効果に加え、真正な開示用キーが送信された場合にのみ仮想通貨アドレスの情報が開示されるので、匿名性という仮想通貨の長所が大きく損なわれることがない。

実施形態の預金口座情報開示システムの概略図である。 実施形態における口座情報ファイルの一例を示した概略図である。 実施形態における預金口座情報の開示について示した概略図である。 開示用キー入力ページの一例を示した概略図である。 開示ページの一例を示した概略図である。 参考例の預金情報開示システムの概略図である。 参考例における口座情報ファイルの一例を示した概略図である。 許可情報ファイルの構造の一例を示した概略図である。 許可設定ページの一例を示した概略図である。 開示申請ページの一例を示した概略図である。 開示プログラムの概略を示すフローチャートである。 開示プログラムにより提供される口座情報閲覧ページの一例を示した概略図である。

次に、本願発明を実施するための形態（実施形態）について説明する。以下の実施形態は、仮想通貨取引で利用される預金口座の情報の開示システムとなっている。また、参考例として、仮想通貨ではなくリアルな通貨の預金口座、即ち市中銀行における預金口座の情報を開示するシステムについても説明する。
まず、実施形態の預金口座情報開示システムについて説明する。図１は、実施形態の預金口座情報開示システムの概略図である。

実施形態において、開示される預金口座の情報は、仮想通貨に関する情報である。仮想通貨は、周知の通り、技術的にはブロックチェーンを基盤とし、ネットワーク上に流通する情報を通貨として捉える仕組みである。現在、幾つかの異なる仮想通貨が実用化されており、それぞれ多少異なる仕組みとなっている。図１では、一例としてリップル（Ripple）が想定されている。
リップルでは、周知のように、ＸＲＰという独自の仮想通貨（ブリッジ通過）に加え、ＵＳＤやＪＰＹのように各国通貨になぞらえた仮想通貨（以下、個別仮想通貨という。）がネットワーク上で流通する。ＸＲＰと各個別仮想通貨は、その時々の交換レートで交換される。

図１に示すように、リップルでは、リアルな通貨と仮想通貨との間の仲立ちをする機関として、ゲートウェイが存在している。リップルにおいて、ゲートウェイは、リアル通貨と仮想通貨との交換所であるとともに、仮想通貨の送金や受け取りを行う機関となっている。
より具体的に説明すると、ユーザーは、任意のゲートウェイに対して利用申し込みをする。この際、ユーザーのリアル通貨の預金口座３からゲートウェイのリアル通貨の預金口座４にリアル通貨の入金がされる。利用申し込みが受け付けられると、ユーザーに対してウォレット２が提供される。ウォレット２は、ある種のデータの集まりであるが、ネットワーク上の“帳簿”とも呼べるものである。

ユーザーには、仮想通貨アドレス（この例ではリップルアドレス）が発行される。仮想通貨アドレスは、暗号技術における公開鍵に相当するもので、ウォレット２と１対１で紐付けられている。また、仮想通貨アドレスに１対１で対応するものとして、秘密鍵が生成されて発行される。ユーザーは自身の預金口座３からゲートウェイの預金口座４にリアル通貨の入金をすると、その分の個別仮想通貨がウォレット２に記録される。日本のユーザーが日本のゲートウェイに利用申し込みをすると、自分のウォレット２にＪＰＹが記録される。例えば、１万円を自分の銀行口座から送金すると、10000JPYが自分のウォレット２に記録される（入金された形となる）。但し、ゲートウェイがウォレットの開設手数料や交換の手数料を取る場合には、それが差し引かれた上でＪＰＹが入金される。

リップルでは、実際の仮想通貨の送金及び受け取りはゲートウェイ同士で行われるので、図１に示すように仮想通貨の送金はゲートウェイが運営するサーバ（以下、この明細書ではゲートサーバと呼ぶ。）１同士で行う仕組みとなっている。具体的に説明すると、ユーザー（預金口座のオーナー）は、送金を行う場合、自身のＰＣやスマホのような端末（以下、オーナー端末という。）５から、自分のウォレット２を開設したゲートウェイのゲートサーバ１にアクセスする。アクセスの際には、自身の仮想通貨アドレスを入力する。送金指示の際には、送金先の仮想通貨アドレスと、個別仮想通貨の種別（ＸＲＰ、ＪＰＹ、ＵＳＤ等）と、送金額を入力する。そして、自身の秘密鍵を入力して送金を指示すると、ゲートサーバ１は、送金先の仮想通貨アドレスに送金を行う。

より具体的には、リップルでは、仮想通貨アドレスはその仮想通貨アドレスがどのゲートウェイで発行されたか判別する情報を含んでおり、ゲートサーバ１は、送金先の仮想通貨アドレスを発行したゲートウェイのゲートサーバ１にアクセスし、送金先の仮想通貨アドレスのウォレット２において送金額の分だけ仮想通貨を増額させるよう指示する。それとともに、送金元のユーザーのウォレット２から送金額の分だけ仮想通貨を減額させる。
このような仮想通貨の送金は、通常、ゲートウェイがユーザーに提供しているウェブサービス（送金サービス）用のプログラムにより行われる。このプログラム（以下、送金プログラムという。）は、ゲートサーバ１に実装されており、自身のゲートウェイにおける顧客（即ち、自身がウォレット２を発行したユーザー）に対して提供される。

上記仮想通貨の送金は、同一の個別仮想通貨間でも行えるし、異なる個別仮想通貨間でも行える。例えば日本国内にあるゲートウェイ同士で1000JPYの送金を行う場合、送金元のウォレット２から1000JPYを差し引き、送金先のウォレット２において1000JPYを加算する。また、例えば日本国内のユーザーが、自身のＪＰＹの仮想通貨を米国内のユーザーに対して1000USD分送金する場合、その時点で交換レートに従って1000USD分のＪＰＹの仮想通貨が日本国内のユーザーのウォレット２から差し引かれ、1000USDが米国内のユーザーのウォレット２において加算される。

上記異種の個別仮想通貨間における交換レートは、リップル全体を統括、管理しているリップルラボが決定している。個別仮想通貨間の交換レートは、実際には、ブリッジ通過（ＸＲＰ）との交換レートを介して決定される。また、送金に際しては、少額ではあるがゲートウェイが手数料を取るので、送金元のユーザーのウォレット２から手数料分も併せて差し引かれたり、または手数料分を差し引いて送金先のウォレット２に対して送金がされたりする。
尚、リップルも、ビットコインと同様、全ての送金は各ブロックチェーン（分散データベース、ledgerと呼ばれる）に記録されており、公正であると検証された全てのブロックチェーンは全ユーザーに対して公開される。但し、ビットコインでは、各ブロックの検証は「採掘者」が競争して行うが、リップルではValidatorと呼ばれる承認者によって各ledgerの検証が行われる。Validatorは、信頼のおける者として予め選定されている。

このような仮想通貨リップルにおける送金において、上述したように、送金先の情報は仮想通貨アドレスのみである。送金元の情報も、仮想通貨アドレスのみである。その仮想通貨アドレスを発行したゲートウェイの情報は、その仮想通貨アドレスの解析により把握できる場合があるが、その仮想通貨アドレスのオーナーの情報は、知ることができない。
このような送金者、受領者の匿名性は、ビットコインも含め、仮想通貨の共通した特長点であり、匿名性が仮想通貨のメリットとなっている。しかしながら、仮想通貨を将来的に広く普及させようとした場合、このような匿名性がかえって障害となると予想される。例えば、事業者間の取引において仮想通貨を決済の手段として利用する場合を想定してみる。例えば事業者Ａが事業者Ｂに請求書を発行し、仮想通貨での支払いを求めたとする。この場合、請求書には、仮想通貨の種別、当該仮想通貨での支払い額（請求額）、仮想通貨アドレスが記載される。請求書を受領した事業者Ｂは、オーナー端末５を操作し、自身のウォレット２から当該仮想通貨アドレスに請求額の仮想通貨を送金するようゲートサーバ１に指示を送信する（即ち、送金処理を行わせる）。

上記送金処理の際、オーナー端末５に表示されるのは送金先の仮想通貨アドレスのみであり、その仮想通貨アドレスが本当に事業者Ａのものかを確認する手段はない。例えば、事業者Ａの社員Ｘが請求書を偽造し、会社（事業者Ａ）の仮想通貨アドレスではなく自身（Ｘ）が保有する仮想通貨アドレスを記載したとしても、事業者Ｂはそれを把握することはできず、Ｘの仮想通貨アドレスに送金をしてしまうことになる。

実施形態の預金口座情報開示システムは、上記のような仮想通貨取引において将来生じ得る問題を考慮したものとなっている。具体的には、この預金口座情報開示システムは、預金口座情報を開示するサーバ（以下、開示サーバという。）６を備えている。
開示サーバ６は、預金口座を開設した銀行が運営する開設銀行サーバに対してネットワーク９を介して接続されている。この実施形態では、開設銀行はゲートウェイであって開設銀行サーバはゲートサーバ１であり、預金口座はウォレット２である。そして、開示される情報は、特定のウォレット２における仮想通貨アドレスのオーナーの情報である。オーナーは、この実施形態における預金口座オーナーである。また、ネットワーク９は、インターネットである。

この実施形態において、開示サーバ６には、開示プログラムが実装されている。開示プログラムは、預金口座オーナー以外の第三者が操作する端末である開示先端末７からのアクセスがあった際に預金口座情報を当該開示先端末７（この例では送金元のオーナーのオーナー端末５）に送信して閲覧可能とするプログラムとなっている。
この実施形態では、開示サーバ６は、信頼のおける第三者機関が運営するものとなっている。ここでの「第三者」とは、ウォレット２の開設者（ゲートウェイ）やユーザーではなく、開示される相手側でもないという意味の第三者である。以下、この者を開示機関という。

開示サーバ６は、記憶部６０を備えている。記憶部６０は、開示サーバ６が備えるハードディスクのようなストレージの場合もあるし、開示サーバ６に接続された他のサーバ（ストレージサーバ等）が備えるものである場合もある。
記憶部６０には、預金口座情報を記録したデータベースファイルである口座情報ファイル６１が記憶されている。図２は、実施形態における口座情報ファイルの一例を示した概略図である。

図２に示すように、口座情報ファイルは、「仮想通貨アドレス」、「ゲートウェイＩＤ」、「オーナー名」、「オーナー住所」、「開示用キー」等のフィールドから成るレコードを多数記録したものとなっている。「ゲートウェイＩＤ」は、その仮想通貨アドレスを発行したゲートウェイのＩＤを記録するフィールドである。ゲートウェイ自体が仮想通貨アドレスを保有している場合、それがＩＤとして記録される場合もあり得る。
「開示用キー」は、預金口座情報の開示をオーナー（当該預金口座オーナー）が許可していることを確認するためのパスワードが記録されるフィールドである。ここでのパスワードは、いわゆる秘密鍵に相当するものであるが、仮想通貨の送金の際に入力する秘密鍵とは別にオーナーに発行される開示用の秘密鍵である。開示用キーは、ウォレット２の開設の際にゲートウェイから付与される構成の場合もあるし、預金口座オーナー自身によって任意のキーが設定される構成の場合もある。

口座情報ファイル６１に記録される情報は、予めゲートウェイから開示機関に提供される。リップルでは、全てではないものの、多くのゲートウェイにおいて、ウォレット２の発行の際に本人確認をし、個人情報を提供してもらっている。この点は、市中銀行における預金口座の開設と同じである。即ち、新規ウォレット２の開設申し込みがあった場合、ゲートウェイは、免許証のような本人確認書類のコピーを提出してもらい、個人情報をゲートサーバ１上の管理用データベースファイルに記録する。そして、発行した仮想通貨アドレスとともに個人情報を管理用データベースファイルに記録する。尚、ここでの個人情報とは、広い意味であり、法人の場合には登記情報ということになる。即ち、法人の場合には、登記簿謄本を提出してもらい、それによって法人名や本店住所を確認し、それらを個人情報としてファイルに記録する。
ゲートウェイは、管理用データベースファイルに記録した情報を、開示機関に提供する。開示機関の担当者は、提供された情報を、自身の端末６００を操作して開示サーバ６の記憶部６０上の口座情報ファイル６１に記録する。

預金口座情報の開示は、開示プログラムによって行われる。この実施形態では、開示プログラムは開示サーバ６に実装されており、仮想通貨の取引を行う際にゲートサーバ１から呼び出されて実行されるものとなっている。
図３は、実施形態における預金口座情報の開示について示した概略図である。開示プログラムの実行は、ゲートサーバ１で提供される送金プログラムにおいて行われる。図３は、この様子を示した概略図である。
ゲートウェイは、ウォレット２を開設した預金口座オーナーに対して会員ＩＤ及びパスワードを発行する。この会員ＩＤ及びパスワードは、ゲートサーバ１にアクセスするためのものであるが、仮想通貨アドレスとその秘密鍵とが兼用される場合もある。

預金口座オーナーは、オーナー端末５において会員ＩＤ及びパスワードを入力してゲートサーバ１にアクセスする。ゲートサーバ１は、送金用ページのＨＴＭＬをオーナー端末５に送信して表示する。送金用ページでは、図３に示すように、送金先の仮想通貨アドレスを入力する欄（以下、送信先アドレス入力欄）３０１、仮想通貨の種別を入力する欄（以下、種別入力欄）３０２、送金額を入力する欄（以下、送金額入力欄）３０３等が設けられている。

そして、送信先アドレス入力欄３０１の下には、「送信先アドレス情報」と表記されたコマンドボタン（以下、開示要請ボタン）３０４が設けられている。開示要請ボタン３０４は、開示用キー入力ページがリンクしている。
図４は、開示用キー入力ページの一例を示した概略図である。この実施形態では、開示用キー入力ページは、ゲートサーバ１によって提供されるものとなっているが、開示サーバ６によって提供される（開示プログラムの一部である）場合もある。

図４に示すように、開示用キー入力ページには、開示用キー入力欄６０５と、送信ボタン６０６とが設けられている。送信ボタン６０６は、開示サーバ６上の開示プログラムの実行ボタンとなっている。
開示プログラムは、送信先アドレス入力欄３０１で入力された仮想通貨アドレスと、開示用キー入力ページで入力された開示用キーとを引数にして実行される。図示は省略するが、開示プログラムは、渡された仮想通貨アドレスによって口座情報ファイル６１を検索し、該当するレコードの「開示用キー」のフィールドの値と渡された開示用キーとが一致するか判断し、一致する場合、専用のページ（以下、開示ページ）に当該レコードの預金口座情報を組み込んで開示先端末７に返信して表示させるようプログラミングされている。

図５は、開示ページの一例を示した概略図である。図５に示すように、開示ページでは、入力された仮想通貨アドレスが確認のために表示されるとともに、その仮想通貨アドレスのオーナー（預金口座オーナー）の情報が表示される。この例では、オーナー名（個人名又は法人名）、住所又は本店所在地が表示されるようになっている。

このような実施形態の預金口座情報開示システムの利用例について、以下に説明する。同様に例えば事業会社Ａが事業会社Ｂに対して請求書を発行し、仮想通貨での支払いを求めるとする。この場合、Ａ社、Ｂ社とも、ウォレット２を付与されており、仮想通貨アドレスを保有している。Ａ社は、請求に際して開示用キーをＢ社に対して告知する。開示用キーは、請求書に記載しておく場合もあるし、暗号化された状態で電子メールにより知らせる場合もある。
尚、少なくともＡ社は、自身がウォレット２を開設したゲートウェイに対して、開設申し込みの際に個人情報を告知しており、そのゲートウェイは、開示機関に対してその個人情報を提供している。開示機関は、提供された個人情報を口座情報ファイル６１に記録している。

請求書の送付を受けたＢ社の担当者は、開示先端末７を操作してゲートサーバ１にアクセスし、送金用ページで仮想通貨アドレス、仮想通貨種別、送金額を入力して送金を指示する。この際、開示要請ボタン３０４をクリック又はタップ（以下、クリックで総称する）し、開示キー入力ページを表示する。そして、Ａ社から提供されている開示キーをここで入力し、送信ボタンをクリックする。この結果、図５に示すようにＢ社の個人情報が開示先端末７に表示される。Ｂ社の担当者は、この情報を閲覧して間違いがないことを確認し、最終的な送金指示のための送信ボタンをクリックする。

このような実施形態の預金口座情報開示システムによれば、仮想通貨アドレスのオーナーの情報が開示されるので、不正な仮想通貨の送金等を抑止することができる。この際、オーナーが開示用キーを知らせた者、即ちオーナーが許可した者にのみ情報が開示されるので、無制限な開示によって匿名性が著しく低下してしまう問題はない。
但し、本願発明の実施形態としては、オーナーの許可を必要とせずに開示する構成であっても良い。この場合、仮想通貨取引における匿名性は大きく低下してしまうが、マネーロンダリングのような犯罪を防止する点では好適であるし、フェイスブックに見られるように、情報を開示した方がかえって信頼性が増すという面もあるからである。

上記実施形態において、開示機関は、預金口座情報が真正であることを認証しつつ開示するものであることが望ましい。即ち、開示機関は、ゲートウェイに対し、認証のために十分な量及び公正さの情報をゲートウェイに義務づける。例えば、オーナーが個人であれば、免許証のコピーを開示機関に提出する他、免許証のオリジナルで本人確認をした旨のゲートウェイの担当者の署名を提出させる。法人であれば、登記簿謄本に加え、取締役の全員の住民票等を提出させる。このようにして認証に十分な量及び公正さの物件が提供された場合にのみ、認証を付与するようにすると好適である。この場合、認証の有無にかかわらず開示先端末７から要求があったら上記のようにオーナー情報を送信して閲覧させるが、認証されている場合にはオーナー情報に加えて認証されている旨の情報（例えば認証マーク）を送信し、認証されている旨が開示先端末７でわかるようにする。

また、仮想通貨アドレスのオーナー情報を認証する場合、その仮想通貨アドレスを発行したゲートウェイを審査する場合もあり得る。例えば、上記のように十分な量及び公正さの物件の提出をオーナーに対して義務づけており、それらの情報を開示機関に提供しているとともに、ゲートウェイ自体の組織の情報についても、運営会社の登記簿謄本や役員の住民票等を提出する等、十分な量及び公正さで情報や物件が提供されている場合、当該ゲートウェイは信頼性の高い機関であると認証する。この場合、ゲートウェイの個別の取引についても開示機関に提供してさらに信頼性を高める場合もある。取引情報については、仮想通貨アドレス同士の取引は全て公開されているので、ここでの取引情報は、主として、仮想通貨とリアル通貨との間の取引（リアル通貨から仮想通貨に換金した上での預かり、仮想通貨からリアル通貨に換金して上での払い出し）である。

このようなゲートウェイの認証も併せて行う場合、ゲートウェイの格付けが開示機関によって行われる場合がある。オーナーの情報、ゲートウェイ自体の情報、各取引情報等について十分な量及び公正さで情報や物件が提出されている場合、Ａランクに格付けされ、情報や物件は少ないもののある程度の公正さが確保されている場合、Ｂランクに格付けされ、それ以外はＣランクに格付けされるといった具合である。これらゲートウェイの格付けも、ある種の預金口座情報であるので、ゲートウェイの格付けを預金口座情報として開示する態様も本願発明には含まれる。この場合、オーナーの情報は開示せずにゲートウェイの格付け情報を開示する構成であっても、メリットがある。例えば、仮想通貨の送金先として指定された仮想通貨アドレスを入力した際、当該仮想通貨アドレスを発行したゲートウェイの格付けが表示されれば、当該仮想通貨アドレスも信頼性も推測することができるからである。尚、このようなゲートウェイの格付け情報も、預金口座情報ファイル６１に予め記録され、上記と同様に開示され得る。

次に、参考例の預金情報開示システムについて説明する。図６は、参考例の実施形態の預金情報開示システムの概略図である。
参考例では、情報を開示する預金口座は、リアル通貨の預金口座、即ち市中銀行の預金口座となっている。図６に示すように、預金口座を開設した銀行は、預金口座のオーナーのためにネットワーク９を介した取引サービス（いわゆるインターネットバンキング）を提供している。オーナーは、自身の端末（オーナー端末）５を操作して銀行のサーバ（以下、銀行サーバ）８にアクセスし、口座残高の確認や他の預金口座への送金（振り込み）等を行う。

各銀行は、それぞれ銀行サーバ８を運営しており、インターネットバンキングのような取引は銀行サーバ８間で行われている。各銀行において、銀行サーバ８は、預金口座のマスターデータを管理したマスターサーバ８０に接続されている。マスターサーバ８０は、ＢＡＮＣＳのような大規模な銀行オンラインシステム８００に接続されており、各ＡＴＭ等や各銀行の窓口での端末等とともに振り込みや振替等のサービスを提供している。

参考例では、このような各銀行の預金口座オーナーに対するサービスにおいて、預金口座情報を開示するものとなっている。リアル通貨における預金口座については、預金口座のオーナー（即ち名義人）の情報は、預金口座オーナー自ら他人に開示する場合が多いので、この実施形態は、名義人のみをさらに開示するものではない。この実施形態のシステムは、名義人に加えて住所をリアルタイムで開示するか、預金口座の預金残高をリアルタイムで開示するものとなっている。預金残高を開示する構成には、当該預金残高に至るまでの取引の記録を開示する構成も含まれる。

具体的に説明すると、この実施形態のシステムも開示サーバ６を備えており、開示サーバ６は、第三者機関としての開示機関によって運営されている。開示機関は、各銀行から独立した中立的な機関である。
開示サーバ６の記憶部６０には、同様に口座情報ファイル６１が記憶されている。図７は、参考例における口座情報ファイルの一例を示した概略図である。

図７に示すように、口座情報ファイルは、「口座ＩＤ」、「銀行ＩＤ」、「銀行名」、「支店ＩＤ」、「支店名」、「口座種別」、「口座番号」、「オーナーＩＤ」、「オーナー名」、「オーナー住所」、「メールアドレス」、「許可設定用キー」等のフィールドから成るレコードを多数記録したデータベースファイルである。「メールアドレス」は、預金口座オーナーのメールアドレスが記録されるフィールドである。

この参考例においても、開示を受けようとする第三者に開示用キーが発行される。許可設定用キーは、この開示用キーのためのキーである。開示用キーの発行は、オーナーの許可により行われるから、許可設定用キーは、許可の権限があることを確認するためのキーである。この参考例では、許可設定用キーは、オーナーから申し込みがあった後に開示機関が決定し、オーナーに書留郵便等の方法で通知される。そして、同じ情報が、預金口座情報ファイル６１の「許可設定用キー」のフィールドに記録される。

口座情報ファイル６１の各レコードの情報は、オーナー本人からのサービス利用申し込みによって記録される。この際、他人の不正な申し込み等を防ぐ観点から、本人確認を行って申し込みを受け付ける必要がある。また、口座情報の開示のためには、銀行サーバ８のアクセスキー（以下、銀行アクセスキーと呼ぶ。）を提供してもらう必要がある。このため、この参考例では、サービス利用の申し込みは銀行に対して行うものとなっており、銀行の窓口で本人確認をした上で申し込みを受け付けるようになっている。

銀行の窓口の担当者は、本人確認をした上で、口座番号、口座種別、オーナー名等の情報を開示機関に送る。開示サーバ６が銀行サーバ８にアクセスするための銀行アクセスキーも開示機関に提供する。開示機関の担当者は、担当者端末６００を操作し、口座情報ファイル６１に新しくレコード追加して開示された情報を記録する。

一方、開示サーバ６の記憶部６０には、許可情報ファイル６２が記録されている。許可情報ファイル６２は、開示サーバ６に登録されている預金口座、即ち預金口座情報ファイル６１の一つのレコードについて一つのファイルが作成され、記憶部６０に記憶される。例えば口座ＩＤをファイル名にして許可情報ファイル６２が作成される。
図８は、許可情報ファイルの構造の一例を示した概略図である。図８に示すように、許可情報ファイルは、「許可ＩＤ」、「開示用キー」、「開示情報種別」、「開示期間」等のフィールドから成るレコードを記録したデータベースファイルである。許可情報ファイルのレコード数は、一つの預金口座についてオーナーが発行した許可ＩＤの数に一致する。

「開示用キー」は、当該預金口座情報の開示のためにオーナーが開示先に提供する秘密鍵である。この参考例では、開示用キーは、開示サーバ６上の開示プログラムが自動生成し、オーナー端末５に返信するものとなっている。
「開示期間」のフィールドは、預金口座情報の取引記録を開示する場合、過去どの程度の期間まで遡って開示するかの情報である。銀行サーバ８が蓄積している範囲が上限となるが、例えば、過去一週間、二週間、一ヶ月、三ヶ月等の期間から選択して値が記録される。

「開示情報種別」は、どの程度までの情報を開示するかを特定するＩＤが記録されるフィールドである。例えば、
１：名義人＋住所、
２：名義人＋住所＋残高、
３：名義人＋住所＋残高＋取引記録、
の三つのパターンから選んで情報開示を許可するものとされ、１～３のいずれかの値が「情報開示種別」に記録される。

このような許可情報ファイル６２の内容は、オーナーが開示サーバ６にアクセスし、専用のページ（以下、開示許可設定ページという。）で情報を入力して開示サーバ６に送信することで記録される。以下、この点について説明する。図９は、許可設定ページの一例を示した概略図である。

開示サーバ６は、預金情報開示のためのウェブサイト（以下、情報開示サイト）を開設している。このサイトは会員制となっており、上記のように銀行の窓口で開示申し込みを行うと、オーナーとしての会員登録がされ、会員ＩＤ及びパスワードが発行される。会員ＩＤ及びパスワードは、開示申し込みの手続きが完了した旨のメールが開示機関からオーナーにメールで報告される際に併せて通知される。

図示は省略するとが、開示サイトのトップページには、「オーナー様のページ」のような表記がされたボタンがあり、このボタンがクリックされると、オーナーとしての会員ＩＤ及びパスワードの入力ページが表示される。このページで会員ＩＤ及びパスワードが正しく入力されて送信ボタンがクリックされると、ログインが行われ、会員エリアのトップページ（会員トップページ）が表示される。

会員トップページには、「開示許可設定」と表記されたボタンが含まれており、それをクリックすると、当該預金口座オーナーが名義人となっていて開示申し込みがされている（即ち、預金情報ファイルにレコードがある）預金口座の一覧が表示される。そして、一覧の各行には預金口座を選択するためのボタンが設けられており、いずれかが選択されると、当該預金口座の口座ＩＤ及びログインの際の会員ＩＤが引数とされて許可設定ページ表示プログラムが実行され、図９に示す許可設定ページが表示されるようになっている。

図９に示すように、許可設定ページでは、選択された預金口座の銀行名、支店名、口座種別、口座番号、名義人が確認のために表示されるようになっている。許可設定ページ表示プログラムは、口座ＩＤを引数にして預金口座情報ファイル６１を検索し、該当するレコードからこれらの情報を取得して許可設定ページに組み込んで表示するようプログラミングされている。
図９に示すように、許可設定ページでは、開示情報種別選択欄６０７が設けられている。開示情報種別選択欄は、名義人＋住所、名義人＋住所＋残高、名義人＋住所＋残高＋取引記録の三つの種別から任意の一つを選ぶ欄となっており、この例ではラジオボタンとなっている。

また、許可設定ページには、開示期間入力欄６０８が設けられている。開示期間入力欄６０８は、三番目の取引記録を含む種別が選択された場合に入力可能となる欄であり、それ以外の種別が選択された場合には入力不可とされる欄である。この欄は、前述したように、銀行サーバ８において蓄積している情報が上限であり、例えばプルダウンリストとされ、過去一週間、二週間、一ヶ月、三ヶ月等の期間から選択して値が入力される欄とされる。

開示サーバ６には、許可設定プログラムが実装されている。図９に示すように、許可設定ページには確認ボタン６０９が設けられている。確認ボタン６０９には、入力された情報を確認させるページの表示プログラムがリンクしており、このページには送信ボタンが設けられている。送信ボタンは、許可設定プログラムの実行ボタンとなっている。許可設定プログラムは、許可設定ファイルに新しくレコードを追加し、許可設定ページで入力された各情報を記録する。そして、許可設定プログラムは、開示用キーを自動生成し、所定のメール本文（テキスト）に組み込んでメールを作成し、口座情報ファイル６１からメールアドレスを取得して当該メールアドレスに送信するようプログラミングされている。このメールには、開示許可設定がされたので開示用キーを知らせる旨と、開示を許可する相手に開示用キーを提供して欲しい旨のメッセージが併せて記載されるようになっている。

次に、このようにして発行される開示用キーを使用した預金口座情報の開示について説明する。
参考例においても、預金口座情報の開示は、開示サーバ６に実装された開示プログラムによって行われる。参考例では、銀行サーバ８による振込サービス（インターネットバンキング）において呼び出されて開示プログラムが実行される他、開示サーバ６が提供する開示サイトにおいて実行されたり、他の種々のサービスにおいて呼び出されて実行されたりし得る。以下では、開示サーバ６が提供する開示サイトで実行される例について説明する。

開示サーバ６は、預金口座情報の開示用のページ（以下、情報開示ページという。）を用意している。開示サイトのトップページには、「預金口座情報を見る」といような表記がされたボタンが設けられている。このボタンには、預金口座情報の閲覧に必要な情報を入力するページ（以下、開示申請ページ）がリンクしている。

図１０は、開示申請ページの一例を示した概略図である。図１０に示すように、開示申請ページには、銀行名、支店名、口座種別、口座番号、及び開示用キーの各入力欄が設けられている。銀行名や口座種別は、この例ではプルダウンリストである。支店名は、数が多いので、最初の文字の入力によって一部一致で検索して候補を表示し、そこから選んで入力する欄とされる。開示用キーは、オーナーから開示先に提供された開示用キーが入力される欄であり、通常、半角英数のみが入力される欄とされる。
開示申請ページには送信ボタン６１０が含まれており、この送信ボタン６１０は、開示プログラムの実行ボタンとなっている。図１１は、開示プログラムの概略を示すフローチャートである。

図１１に示すように、開示プログラムは、入力された銀行名、支店名、口座種別、口座番号の各情報で口座情報ファイル６１を検索し、該当するレコードがあるかどうか、即ち全ての情報が一致する預金口座があるかどうか判断する。無ければ、エラーメッセージを表示してプログラムを終了する。該当するレコードがあれば、口座ＩＤに従って当該預金口座について作成されている許可情報ファイル６２を開き、送信された開示用キーと「開示用キー」のフィールドの値が一致するレコードがあるかどうか判断する。一致するレコードがなければ、その旨のエラーメッセージを表示して終了する。一致するレコードがあれば、そのレコードから開示情報種別を取得する。この際、開示情報種別が“３”であれば、取引期間も許可情報ファイル６２から取得する。そして、開示プログラムは、口座情報ファイル６１の当該預金ＩＤのレコードから銀行アクセスキーを取得し、それによって銀行サーバ８にアクセスする。

開示サーバ６は、アクセスキーとともに、支店ＩＤや口座番号等の情報を銀行サーバ８に送信し、開示情報種別に従ってその時点での預金口座情報を提供するよう要求する。即ち、種別が“１”であれば、オーナーの氏名と住所を提供するよう要求し、種別が“２”であれば、これに加えてその時点での残高を提供するよう要求し、種別が“３”であれば、さらにこれに加えて取引記録を要求し、この際、取引期間も銀行サーバ８に送信する。

銀行サーバ８は、銀行アクセスキーが正しいことを確認した後、当該預金口座のその時点での上記各情報をマスターサーバ８０から取得し、開示サーバ６に返す。開示プログラムは、例えば銀行サーバ８から預金残高情報の返信があると、口座情報閲覧ページに預金残高情報を組み込んで開示先端末７に返信する。これで、開示プログラムは終了である。

図１２は、このような開示プログラムにより提供される口座情報閲覧ページの一例を示した概略図である。図１１に示すように、口座情報閲覧ページでは、例えば、開示先端末７で入力されて開示が要請された預金口座のその時点での預金残高の情報が表示される。この際、口座情報閲覧ページには、開示機関が当該預金口座情報の真正さを認証する旨の表示がされるようになっている。この例では、真正さを認証するマーク６１１を開示機関が制定しており、このマーク６１１が併せて表示されるようになっている。

開示機関は、全国銀行協会のような公的な団体又はそのように公共性、中立性が確保された団体であることが想定されており、預金口座情報ファイル６１等の情報も厳格なセキュリティ管理が施されている。また、各銀行に対しても、情報の真正さを保証する旨の義務を課している。このような態勢により、開示機関は第三者に対して預金口座情報の真正さを認証している。

上記構成に係る参考例の預金口座情報開示システムによれば、預金口座情報がネットワーク９経由で第三者に開示される。この際、当該情報の真正さが開示機関によって認証された状態で当該情報が提供されるので、第三者は一定の信頼性をもって開示情報を受け取ることができる。

より具体的な利用例について説明すると、例えば請求書を発行して相手方に支払いを求める場合、請求書には支払い先の預金口座の情報が記載される。この場合、名義人や口座番号等は記載されるが、住所までは記載されることはない。振り込みに際しても、支払い先の住所まで入力することが要求されることはない。この場合、悪意のある者が同じ名前の会社を設立して預金口座を開設すると、その者の口座に誤って振り込ませることができてしまう。より具体的には、ある会社の従業員が、その会社への送金を自分の口座に誤って振り込ませるため、同じ名前の会社を設立してその名義で銀行口座を開設してその口座番号を請求書に記載する不正があり得る。この場合も、同一住所で同一名義の会社は設立できないので、住所は異なるものになる。このような場合も、請求書を受領した者が、この参考例における開示サイトで住所を確認すると、本来の住所と異なることが判明し、不正を事前に察知することができる。

また、別の利用例として、参考例の預金口座情報開示システムは、預金口座の残高をリアルタイムで第三者が確認するのに好適に利用される。例えば、何らかの事情である預金口座オーナーの資産状況を第三者が確認する必要がある場合、預金口座オーナーは許可設定ページで許可設定を行い、送られた開示用キーを当該第三者にメール転送などで提供する。第三者は、開示先端末７で開示用キーを入力することで、その場で当該預金口座の残高をその場で確認することができる。この場合、開示用キーを入力して送信ボタンをクリックした時点での預金残高、即ちリアルタイムの預金残高が確認できる。

預金残高を第三者が確認する方法としては、現在、預金残高証明書を銀行に発行してもらい、それを預金口座オーナーが第三者に提供する方法がある。しかしながら、預金残高証明書の発行には一週間から１０日ほどかかり、郵送で交付されるので、二週間ほど前の情報になってしまう。参考例のシステムによれば、開示用キーを入力して送信ボタンをクリックした後は、開示サーバ６と銀行サーバ８との動作時間がかかるのみであり、ほぼ瞬時に預金残高が確認できる。しかも、預金残高は、開示機関によって認証がされているので、銀行の預金残高証明書とほぼ同等の信頼性を持ってその情報を受け取ることができる。例えば、高額契約等のような与信を行う際、相手方の資産状況を迅速に把握する必要がある場合があるが、このような場合、参考例のシステムは好適に利用される。

さらに、参考例のシステムは、ノンバンク系の金融機関から融資を受ける際の審査の用途にも好適に利用される。預金口座を開設した銀行から融資を受ける場合、当該預金口座の取引状況は銀行において把握可能であるが、ノンバンク系の金融機関では難しい。融資を申し込む預金口座オーナーから預金通帳の提示を受けることも考えられるが、融資の申し込みから実際の審査までには時間があくのが通常であるため、融資の審査が行われる際にリアルタイムで取引の状況を確認することはできない。

一方、参考例の預金口座情報開示システムを利用すれば、その時点までの預金口座の取引状況をリアルタイムで確認することができる。このため、ノンバンク系の金融機関における審査がキメ細かくでき、結果的に融資を受け易くなる。
上記参考例の構成において、預金口座の残高情報を開示した際、当該残高をロックする構成を採用しても良い。ロックとは、当該残高未満になるような引き出しや引き落とし、振替等を禁止する制限である。

具体的には、許可設定ページでの許可設定の際、預金口座オーナー自ら取引ロック時間を設定できるようにする。許可設定情報ファイルには、「取引ロック時間」のフィールドが設けられており、許可設定プログラムは取引ロック時間を当該フィールドに記録するようプログラミングされる。そして、開示プログラムは、正しい開示用キーが送信されて預金残高情報を開示した際、銀行サーバ８に取引ロック時間を送信するようプログラミングされる。

この場合、銀行サーバ８は、マスターサーバ８０に取引ロック時間を転送し、当該預金口座の取引をロックするよう指令信号を送信する。マスターサーバ８０における取引ロックは、例えば預金口座の差し押さえの場合と同様の処理である。但し、開示先への振り込みは例外として許可されるよう取引ロックが設定される場合があり得る。このようにすると、預金残高が一定期間保証されるので、開示先と預金口座オーナーとの間で各種契約をする場合に便利となる。

上記参考例において、市中銀行の預金口座情報が開示用キー無しで開示される構成が採用されることがあり得る。預金口座の残高や取引情報が誰でも見られる状態になるので、現在の常識からは考えられないが、預金口座の情報を完全にオープンにすることは、例えば企業の経営情報をガラス張りにすることにつながるし、かえってその企業の社会的信用を高めることにもつながる。したがって、そのような構成が積極的に採用されることがあり得る。

尚、上記参考例において、開示用キーは期限付きのものであることが好ましい。即ち、開示サーバ６が開示用キーを発行してから３時間とか、１２時間とか、２４時間のように時間が制限され、その時間を過ぎた場合には、キーとしては真正であっても預金口座情報を開示しないよう開示プログラムがプログラミングされる。これは、開示用キーが不正に流出した場合を想定したものである。前述した実施形態においても、同様の構成としても良い。

また、上記参考例において、オーナーの住所の情報は、開示サーバ１上の口座情報ファイル６１にも記録されているので、銀行サーバ８にアクセスせずに口座情報ファイル６１から取得しても良い。但し、この場合、その後の住所変更がされており、住所変更が銀行にのみ届けられていると、口座情報ファイル６１から取得する情報は古い住所になってしまうので、銀行サーバ８にアクセスして取得することが好ましい。

１ ゲートサーバ
２ ウォレット
５ オーナー端末
６ 開示サーバ
６１ 口座情報ファイル
７ 開示先端末
８ 銀行サーバ
９ ネットワーク（インターネット）

Claims (2)

1. オーナーが保有する預金口座の情報を第三者に開示する預金口座情報開示システムであって、
   開示サーバを備えており、
   開示サーバは、預金口座のオーナー及び預金口座の開設者以外の第三者が操作する端末である開示先端末からのアクセスをネットワークを介して受け付けるものであり、
   開示サーバには、開示プログラムが実装されており、
   開示プログラムは、開示先端末から預金口座特定情報とともに開示要求が送信された場合、当該預金口座の名義を取得して預金口座情報として開示先端末に送信して開示先端末において閲覧可能とするプログラムであり、
   預金口座特定情報は、仮想通貨アドレスであり、
   開示プログラムは、当該仮想通貨アドレスのオーナーが誰であるかの情報を預金口座情報として送信するプログラムであり、
   開示サーバは、預金口座情報が真正であることを認証せずに開示先端末に送信して開示先端末において閲覧可能とするものであることを特徴とする預金口座情報開示システム。
2. 前記開示サーバは、前記開示先端末から真正な開示用キーが送信された場合のみ前記預金口座情報を送信するプログラムであることを特徴とする請求項１記載の仮想通貨アドレスについての預金口座情報開示システム。
   

Images