JP5484823B2 - カードレス決済のための情報処理装置、カードレス決済システム、カードレス決済方法、キャッシュレス決済方法およびプログラム - Google Patents

Description

本発明は、ネットワークを介した電子決済技術に関し、より詳細には、ユーザビリティが高く、かつセキュリティ性を向上したカードレス決済のための情報処理装置、カードレス決済システム、カードレス決済方法、キャッシュレス決済方法およびプログラムに関する。

近年ネットワーク技術やコンピュータ技術に進歩により、ネットワークを介した商品購入を行うことが容易になっている。ネットワークを介して商品購入やサービス購入を行う電子商取引、いわゆるｅコマースでは、商品・サービスの購入者は、商品・サービスの提供者に対して商品購入要求を送付し、クレジット・カードやデビット・カードなどのカード番号を提供者に送付する。

提供者は、ユーザからの商品購入要求を受領すると、提供者を管理するアクワイアラにユーザおよびカード番号を問合わせ、アクワイアラを経由してユーザに対する認証およびカード番号情報の確認に成功すると、提供者は、ユーザとの間で購入契約を締結し、商品の発送を行い、クレジット・カードやデビット・カードによる対価の支払を、アクワイアラに請求する。アクワイアラは、提供者の代わりにクレジット・カードやデビット・カードの発行元（以下、発行元ノードとして参照する。）などに請求を行う。発行元は、アクワイアラからの支払要求を受領すると、アクワイアラに対して精算を行い、さらにアクワイアラは、加盟店ノードに対して精算を行う。

一方、発行元は、ユーザが銀行口座を開設する銀行に請求を行って、ユーザの銀行口座からの支払を受領し、ネットワークを介したｅ−コマースのスキームが完結する。なお、デビット・サービスの場合、デビット・カードの発行権限は、銀行が保有し、デビット・サービスを要求するユーザが、当該銀行に預金口座を有する場合に、銀行がデビット・カードを当該ユーザに対して発行する。

現在上述したｅコマースにおける代金決済の方法には、クレジット・カードやデビット・カードが利用されている。クレジット・カードは、ユーザの銀行口座からの代金決済が、ｅコマースによる商品・サービスに関する購入契約完了と、銀行口座からの代金引き落としが、購入契約完了後１月から２月後に行われるのが通常である。一方、デビット・カードは、銀行ノードが発行元ノードの機能を有する融合ノードとして機能しており、このため、商品・サービスに関する購入契約完了と、銀行口座からの代金引き落としとがほぼ同期して行われるキャッシュレス・サービスが可能とされる。

クレジット・カードは、銀行口座からの代金引き落としが購入契約完了後の一定期間内に行われるので、ユーザは現在の銀行預金残高を気にすることなく、一定期間後の預金残高を考えて商品・サービスの購入を行うことができる。一方、デビット・カードは、銀行口座からの引落が、購入契約完了とほぼ同時に行われる。このため、デビット・カードは、購買契約と、代金決済完了までの時間的サイクルが短いので、カード番号詐取などに対して迅速に対応できるという利点がある。

従来から、上述したデビット・カードを利用するキャッシュレス決済を行うシステムが種々提案されている。例えば、特開２００８−３０５３９２号公報（特許文献１）では、金融機関に口座を有するユーザの端末装置（ユーザ端末）が通信ネットワークを介して接続され、このユーザに対して決済機能を備えたカードを発行する発行者が管理するサーバ装置によって、このユーザに対して有効期限付きのカード決済サービスを提供する方法が記載されている。

また、特開２００１−３５７２０２号公報（特許文献２）では、インターネット上において、リアルタイムに決済を行うことができると共に、決済コストを低減するために、コンピュータである電子銀行は、利用者毎の金融取引情報を記憶する記憶手段と、利用者からインターネットにより送信されてきた決済情報を受信する決済情報受信手段と、決済情報受信手段で受信した決済情報に基づいて、利用者間の決済を実行する決済実行手段と、決済実行手段で実行した決済内容を反映させるため、記憶手段に記憶されたその利用者の金融取引情報を更新する更新手段とを備えるシステムが記載されている。

さらに、特表２００３−５０７８２４号公報（特許文献３）では、要求者の状態を提供者により電子的に照合して商取引を行うためのシステムにおいて、 メモリに関連付けられたホストマイクロプロセッサと、 ホストコンピュータと通信するための通信装置とを備え、 上記メモリは、使用制限付取引識別番号と、上記使用制限付取引識別番号に対応付けられた個人識別情報とを含んでおり、 上記使用制限付取引識別番号は、ランダムに発生された番号と、時間発生スタンプとを備えていることを特徴とする商取引を行うためのシステムを記載する。特許文献３のシステムは、カード番号をランダムに発生させ、有効期限を与えるタイムスタンプをリアルタイムで発行することを可能とすることで、カード番号の迅速な発行を可能とし、効率的なキャッシュレス・サービスを提供する。

また、特表２００４−５２４６０５号公報（特許文献４）では、リモート認証サービスプロバイダは、消費者名および固有の消費者コードに基づく消費者の高速認証を容易にするために、消費者データを管理し、固有の消費者コードは、消費者により保有されるハードウェアトークンによって生成されるワンタイムパスワード(OTP)である。リモート認証サービスプロバイダは、トークンにより生成されたパスワードが正当であることを確かめるシステムが開示されている。

さらに、特開２００４−２５９１５２号公報（特許文献５）では、複数の決済手段の中から、決済金額に応じていずれか１つの決済手段を自動的に選択して決済を行えるようにするためＰＯＳ装置、携帯端末、クレジット会社コンピュータ、金融機関コンピュータを使用するシステムが記載されている。このシステムでは、携帯端末は、ＰＯＳ装置から決済金額が送られてくると、決済手段決定テーブルを参照して、その決済金額に対応した決済手段を決定し、決定された決済手段で決済するための決済情報および決済金額を含んだ決済要求信号がPOS装置へ送信される。POS装置は、この決済要求信号に基づいて決済手段を判別し、決済手段に対応する決済処理が行われる。

特開２００８−３０５３９２号公報 特開２００１−３５７２０２号公報 特表２００３−５０７８２４号公報 特表２００４−５２４６０５号公報 特開２００４−２５９１５２号公報

上述した先行技術では、消費者や顧客の功利的管理を行う店、カード番号の効率的な発行およびワンタイム・パスワードの利用などによるセキュリティ向上などが可能とされている。しかしながら、上述したシステムおよび方法は、消費者の認証、決済処理の効率化などを目的とするものであり、物理的にデビット・カードを発行することなく、デビット・サービスを提供することを目的とするものではない。

また、物理的にカードを発行することなくキャッシュレス・サービスを提供する際に、カード番号詐取などの個人情報漏洩リスクを最低化させながら、ユーザに対して手軽にキャッシュレス・サービスを提供することを目的とするものではない。さらに、キャッシュレス・サービスの普及に伴ない、キャッシュレス・サービスにおけるカード番号管理および個人情報管理を効率化させることを課題とするものではない。

本発明は、上記従来技術の問題点に鑑みてなされたものであり、物理的なカードの発行を伴うことなく、高い利便性で、セキュリティの高いカードレス決済のための情報処理装置、カードレス決済システム、カードレス決済方法、キャッシュレス決済方法およびプログラムを提供することを目的とする。

本発明は、上記従来技術の問題点に鑑みてなされたものであり、本発明は、クレジット・カードとは異なり、デビット・サービスでは、デビット・サービス利用と、代金振り替えとを実質的に同期化できるので、購入契約完了と同時にデビット・カードを無効化しても、デビット・カードの利用と代金決済とを独立して管理することが可能であることに着目し、デビット・サービスによる決済を承認し、デビット・サービス利用の承認と同時に無効化される決済承認番号を、ワンタイムデビット番号として発行する。

すなわち、本発明によれば、ネットワークを介して電子商取引における代金決済を物理的カードを発行することなく実行する情報処理装置であって、前記情報処理装置は、
前記情報処理装置に対し前記ネットワークを介してアクセスするユーザのログイン認証を行うログイン認証部と、
前記ログイン認証が成功したユーザについてユーザ認証を実行するユーザ認証部と、
前記ユーザ認証に成功したユーザが前記電子商取引での代金決済を前記情報処理装置が行うために利用する決済承認番号を生成するための数字列からなる部分情報を部分情報データベースからランダムに採番する部分情報取得部と、
前記部分情報取得部が取得した前記部分情報と、代金決済のための制御情報を結合して前記ユーザ認証に成功したユーザに固有でありかつ前記代金決済の成功により無効化される前記決済承認番号を生成する決済承認番号生成部と、
前記ネットワークを介して決済の要求を受領して前記決済の要求が含む前記決済承認番号の有効性を判断し、前記決済承認番号が有効の場合に代金決済に指定された金額について、前記ユーザの口座番号から引落しを指令すると共に、決済の成功に応答して前記ユーザの前記決済承認番号を無効化する決済要求処理部と
を含む、情報処理装置が提供できる。

本発明では、前記部分情報取得部は、乱数発生部を含み、前記乱数発生部が生成した乱数列を、前記部分情報データベースから検索して既リースでない部分情報を前記部分情報データベースから取得することができる。本発明では、前記情報処理装置は、さらに前記口座番号を有するユーザを管理するユーザ・データベースを含み、前記ユーザ・データベースは、前記ユーザについて発行された前記決済承認番号を前記ユーザに対応付けて登録することができる。

本発明では、前記情報処理装置は、前記決済の要求に関連する代金決済の履歴を記録する決済ログ・データベースを含み、前記決済の成功に応答して、前記決済承認番号を、前記ユーザ・データベースから前記決済ログ・データベースに移動させることにより無効化することができる。

本発明では、前記情報処理装置は、銀行口座を管理する銀行が設置する銀行サービス・サーバであり、前記決済承認番号は、デビット・サービスについての代金決済の承認を与えることができる。

本発明では、ネットワークを介して電子商取引における代金決済を物理的カードを発行することなく実行するカードレス決済システムであって、情報処理装置であって、前記カードレス決済システムは、
前記ネットワークに接続されたユーザ・ノードと、
前記ネットワークに接続され、前記ユーザ・ノードとの間で相互通信可能な銀行サービス・サーバとを含み、前記銀行サービス・サーバは、
前記情報処理装置に対し前記ネットワークを介してアクセスする前記ユーザ・ノードから送付されるアクセス要求についてログイン認証を行うログイン認証部と、
前記ログイン認証が成功した場合、前記ユーザ・ノードから送付された前記アクセス要求についてユーザ認証を実行するユーザ認証部と、
前記ユーザ認証に成功した場合、前記ユーザ・ノードが前記電子商取引での代金決済を前記情報処理装置により行うために利用する決済承認番号を生成するための数字列からなる部分情報を、部分情報データベースからランダムに採番する部分情報取得部と、
前記部分情報と、代金決済のための制御情報を結合して前記カードレス決済システム上で固有であり、かつ前記代金決済の成功により無効化される前記決済承認番号を生成する決済承認番号を前記ユーザ・ノードについて生成する決済承認番号生成部と、
前記ネットワークを介して決済の要求を受領して前記決済の要求が含む前記決済承認番号の有効性を判断し、前記決済承認番号が有効の場合に代金決済に指定された金額について、前記ユーザ・ノードに対応付けられた口座番号から引落しを指令すると共に、決済の成功に応答して前記ユーザ・ノードの前記決済承認番号を無効化する決済要求処理部と
を含む、カードレス決済システムが提供できる。

本発明では、前記部分情報取得部は、乱数列発生部を含み、前記乱数発生部が生成した乱数列を、前記部分情報データベースから検索して既リースでない部分情報を前記部分情報データベースから取得することができる。

本発明では、前記情報処理装置は、前記決済の要求に関連する代金決済の履歴を記録する決済ログ・データベースを含み、前記決済の成功に応答して、前記決済承認番号を、前記ユーザ・データベースから前記決済ログ・データベースに移動させることにより無効化することができる。本発明では、前記銀行サービス・サーバは、銀行口座を提供する銀行が管理し、前記決済承認番号は、デビット・サービスについての代金決済の承認を与えることができる。

本発明では、ネットワークを介して電子商取引における代金決済を物理的カードを発行することなく実行する情報処理装置が実行するカードレス決済方法であって、前記情報処理装置が、
前記情報処理装置に対し前記ネットワークを介してアクセスするユーザのログイン認証を行うステップと、
前記ログイン認証が成功したユーザについてユーザ認証するステップと、
前記ユーザ認証に成功したユーザが前記電子商取引での代金決済を前記情報処理装置により行うために利用する決済承認番号を生成するための数字列からなる部分情報を部分情報データベースからランダムに採番するステップと、
前記部分情報取得部が取得した前記部分情報と、代金決済のための制御情報を結合して前記ユーザ認証に成功したユーザに固有でありかつ前記代金決済の成功により無効化される前記決済承認番号を生成するステップと、
前記ネットワークを介して決済の要求を受領して前記決済の要求が含む前記決済承認番号の有効性を判断し、前記決済承認番号が有効の場合に代金決済に指定された金額について、前記ユーザの口座番号から引落しを指令すると共に、決済の成功に応答して前記ユーザの前記決済承認番号を無効化するステップと
を実行するカードレス決済方法が提供できる。

本発明では、前記ランダムに採番するステップは、乱数列を生成し、生成した乱数列で前記部分情報データベースを照会して既リースでない部分情報を前記部分情報データベースから取得するステップを含むことができる。本発明では、前記決済承認番号を生成するステップは、前記口座番号を有するユーザを管理するユーザ・データベースに前記ユーザについて発行された前記決済承認番号を前記ユーザに対応付けて登録することができる。

本発明では、前記決済承認番号を無効化するステップは、前記決済の要求に関連する代金決済の履歴を記録する決済ログ・データベースに、前記決済の成功に応答して前記決済承認番号を、前記ユーザ・データベースから前記決済ログ・データベースに移動させるステップを含み、前記情報処理装置は、銀行口座を管理する銀行が設置する銀行サービス・サーバであり、前記決済承認番号は、デビット・サービスについての代金決済の承認を与えることができる。

本発明では、ネットワークを介したキャッシュレス決済方法であって、前記キャッシュレス決済方法は、銀行サービス・サーバが、
ネットワークに接続されたユーザ・ノードから電子商取引での代金決済を銀行サービス・サーバにより銀行口座から即時決済するためのワンタイムデビット番号を発行する要求を受領するステップと、
前記要求の受領に応答して、ログイン認証およびワンタイム・パスワードを利用したユーザ認証を実行するステップと、
前記ユーザ認証の成功後、前記ユーザ認証に成功したユーザが前記ワンタイムデビット番号を生成するための部分情報を部分情報データベースからランダムに採番し、代金決済のための制御情報を結合して前記ユーザに固有でありかつ前記代金決済の成功により無効化される前記ワンタイムデビット番号を生成するステップと、
前記ユーザ・ノードにより加盟店ノードがネットワーク上に開設するインターネット・ショッピングサイトに対して通知された前記ワンタイムデビット番号および決済金額を含む決済の要求を受領するステップと、
前記決済の要求が含む前記ワンタイムデビット番号について前記決済の要求を受領した時刻でのワンタイムデビット番号の利用状況および銀行口座の状況を検査し、当該検査の結果前記利用状況および前記銀行口座の状況が決済可能であると判断した場合、前記ワンタイムデビット番号を現在登録している銀行口座から前記決済金額の引落しを実行することにより代金決済を実行させるステップと、
前記決済の成功に応答してユーザ・データベースに登録された前記ワンタイムデビット番号を削除して無効化するステップと、
当該決済トランザクションを、前記加盟店ノードの識別値、削除した前記ワンタイムデビット番号、決済金額と共に決済情報として決済ログ・データベースに登録するステップと
を実行する、キャッシュレス決済方法が提供できる。

さらに、本発明によれば、情報処理装置を、上述したいずれかに記載の機能手段として機能させるためのコンピュータ実行可能なプログラムが提供される。

本発明では、決済承認番号が購買契約に関連する決済承認番号の利用についての承認がなされた時点で当該決済承認番号を無効化することができ、決済承認番号が不正取得された場合にでも銀行ノード、発行者ノード、アクワイアラ・ノード、加盟店ノードの損失を最小限に止めることができる。

また、本発明では、当該決済承認番号は、代金決済までの短期間、銀行ノードおよび発行者ノードが管理するだけで済むため、債権・債務を伴う情報の漏洩や累積的な不正利用の可能性を最小限に止めることができる。さらに、代金決済の完了後、リボークされた決済承認番号が含んでいた部分情報は、有効期間に関係なく再利用できるので、ユーザ数が増加しても例えばカード番号といった決済承認番号の有効な発行数を最小限化することができるので、物理的なデビット・カードを発行しないことに加え、さらにキャッシュレス・サービスのセキュリティを向上でき、ｅコマースに関連する各ノードにおける個人情報漏洩リスクを最小限とすることができる。

さらに本発明によれば、決済承認番号は、ユーザ間で共有されないようにして部分情報をランダムに採番して生成されるので、クレジットマスターなどによる番号取得を防止でき、よりセキュリティ性を向上させることができる。

本実施形態が適用されるｅコマースのトランザクション・フロー１００の実施形態を示した図。 本実施形態において、カードレス決済システム２００の機能ブロック図を示した図。 本実施形態の銀行サービス・サーバ２１０が実行するワンタイムデビット・サービスの実施形態のフローチャート。 本実施形態の部分情報ＤＢ２５０に対するDBアクセス部２４４の処理を示したフローチャート。 本実施形態で使用する部分情報DB２５０のデータ構造５００を示した図。 本実施形態の銀行サービス・サーバ２１０が実行する決済承認番号生成処理の第１の実施形態のフローチャート。 本実施形態の銀行サービス・サーバ２１０が実行する決済承認番号生成処理の第２の実施形態のフローチャート。 本実施形態の決済承認番号生成部２３４が実行する図６および図７の制御情報と部分情報との結合処理の概略図。 本実施形態のユーザDB２６０が管理するユーザ・データのデータ構造を示した図。 本実施形態の銀行サービス・サーバ２１０が実行する無効化処理の実施形態のフローチャート。 本実施形態の決済処理のフローチャート。 本実施形態で、決済要求処理部２３６が実行する決済承認番号のワンタイム化処理を、ユーザ・テーブル１２２０を使用して説明する図。 本実施形態の銀行サービス・サーバ２１０がユーザ通知部２３８を介してユーザ・ノード２２０のデスクトップ画面上に表示させるウェブ・ページ１２００の実施形態を示した図。 ワンタイムデビット・サービスのユーザ登録ページ１４００の実施形態を示した図。 決済承認番号が割当てられた後の条件設定をカスタマイズするＧＵＩ表示画面の実施形態を示した図。 本実施形態のワンタイムデビット番号を使用する際の実施形態において表示されるＧＵＩ表示１６００を示した図。 本実施形態のワンタイムデビット・サービスにより発行されるワンタイムデビット番号、すなわち、決済承認番号の数を、時系列的にシミュレーションした結果を示した図。

図１は、本実施形態が適用されるｅコマースにおけるキャッシュレス・サービスの各ネットワーク・ノード間のトランザクション・フロー１００の実施形態を示す。図１に示すｅコマースでは、リクエスト（１）で、ユーザ・ノードから銀行ノードにデビット・サービスを受けるための固有の識別値である決済承認番号の発行を要求する。本実施形態で、ユーザ・ノードとは、パーソナル・コンピュータ、ワークステーション、またはサーバ、携帯電話、PDA(Personal Data Assistant)などの情報処理装置として構成される情報処理装置であって、インターネットなどのネットワークに接続されて、ユーザにより操作されてネットワーク上で各種のトランザクションを実行可能な情報処理装置を意味する。

本実施形態で、銀行ノードとは、ｅコマース・トランザクション中で、代金の支払決済を行うため、銀行口座を開設し管理する銀行といったビジネス・エンティティが管理するサーバなどの情報処理装置であって、ネットワークに接続され、他のネットワーク・ノードからアクセスされる情報処理装置を意味する。銀行ノードは、ネットワーク上に所定のＵＲＬ(Uniform Resource Locator)で指定されるウェブ・サイトを開設することにより、ネットワークを介して各種サービスを提供する。銀行ノードは、ユーザ・ノードからのアクセス要求を受領すると、当該ユーザ・ノードからのアクセス要求について、認証処理を実行し、認証処理に成功すると、レスポンスとして決済承認番号を発行する。

決済承認番号は、本実施形態では特に制限はないがキャッシュレス決済処理について従来からクレジットカード・サービスなどに対して利用されている数字列を使用することが、処理基盤の大きな修正を伴うことなく、本実施形態を適用することができるため、好ましい実施形態である。なお、決済承認番号は、本質的には数字列が有意情報として利用されるが、ユーザ識別性を向上させる点で、ハイフン「−」など、ASCIIコードなどを含んで構成されていてもよい。

ユーザ・ノードは、決済承認番号を取得すると、リクエスト（２）で、ネットワークを介してネットワーク上で商品／サービスを提供するためのウェブ・サイトを開設する加盟店ノードに対して、購入リクエストを発行し、購入／利用したいサービスを特定した後、決済承認番号などを送付する。なお、本実施形態において、加盟店ノードとは、商品やサービスをネットワークを介して提供するため、サーバなどを利用してＵＲＬなどで特定されるウェブ・サイトを提供し、ネットワーク上の固有ノードとして機能する情報処理装置を意味する。加盟店ノードは、ユーザ・ノードからの購入リクエストを受領すると、リクエスト（３）およびリクエスト（３−２）でアクワイアラ・ノードおよび発行者ノードに対して決済承認番号の認証を送付する。

なお、本実施形態でアクワイアラは、加盟店と契約締結し、管理するエンティティであり、アクライアラ・ノードとは、アクワイアラが、ネットワークを介して加盟店を管理するため、サーバなどを利用してネットワーク上に特定のURI(Uniform Resource Identifier）などによりネットワーク・ノードとして機能する情報処理装置を意味する。アクワイアラ・ノードは、加盟店ノードや発行者ノードとの間でトランザクションを行い、口座引落代行などの処理を実行する。また、本実施形態で発行者とは、キャッシュレス・サービスを提供するための固有番号など、キャッシュレス取引識別値を発行するビジネス・エンティティを意味し、発行者ノードは、当該発行者がネットワーク上でその機能を実行させる情報処理装置である。発行者ノードは、アクワイアラ・ノードに対する代金支払などを代行し、サーバなどの情報処理装置として実装されている。

アクワイアラ・ノードは、加盟店ノードからのリクエスト（３）を受領すると、リクエスト（３−２）を銀行ノードおよび発行者ノードへと送付する。銀行ノードは、当該リクエスト（３−２）を受領すると、リクエスト（３−２）が含む、決済承認番号、購買内容、およびタイムスタンプを取得し、当該決済承認番号の有効性を検査する。銀行ノードは、決済承認番号が有効であると判断した場合、リクエスト（３−２）のレスポンスとして該当する決済承認番号が有効である通知を、アクワイアラ・ノードに送付する。アクワイアラ・ノードは、リクエスト（３）のレスポンスとして決済承認番号が有効であるとの通知を加盟店ノードに送付する。この段階で、ユーザ・ノードおよび加盟店ノードの間で契約が締結され、商品発送手配やサービス提供開始が行われる。

図１のキャッシュレス・サービスのコンテキストを、デビット・サービスに適用する場合、銀行ノードは、発行者ノートの機能を含むことになり、キャッシュレス・サービスをデビット・サービスとする場合、銀行ノードは、図１中、破線で示すように発行者ノードの機能を有することになる。銀行ノードは、購買契約完了の通知をアクワイアラ・ノードといった適切なネットワーク・ノードから受領すると、当該決済承認番号を保有するユーザ・ノードの口座番号から、リクエスト（３−２）が含む決済承認番号に対応付けて登録された口座番号から購入金額の決済を行い、発行者ノードに対する代金決済を完了する。その後、銀行ノードは、直ちに、行使された決済承認番号を銀行ノードが管理するユーザ・データベース（以下、ユーザDBとして参照する。）から削除し、銀行ノードが管理する決済ログ・データベース（以下、決済ログDBとして参照する。）に移転して決済記録として保存する。

その後、銀行ノードは、代金決済完了のトランザクション（４）で、ユーザ・ノードに代金引き落とし完了を通知する。一方、発行者ノードは、アクワイアラ・ノードに対して決済を行い、トランザクション（５）で、決済完了を通知する。アクワイアラ・ノードは、加盟店に対する代金決済を完了すると、トランザクション（６）で、加盟店ノードに当該契約に関する代金決済が完了したことを通知する。

図２は、本実施形態におけるカードレス決済システム２００の機能ブロック図を示す。なお、図２に示すカードレス決済システム２００は、銀行サービス・サーバ２１０と、ユーザ・ノード２２０とを含んで構成されており、銀行サービス・サーバ２１０と、ユーザ・ノード２２０とは、ネットワーク２９０を介してアクセス要求およびレスポンスを返すことにより相互通信可能とされている。

ユーザ・ノード２２０は、例示する目的から１つのみ示しているが、銀行サービス・サーバ２１０は、パーソナル・コンピュータ、ワークステーション、携帯電話、PDAなどから構成される複数のユーザ・ノードからのリクエストをそれぞれ受領して処理を実行する。ユーザ・ノード２２０が、パーソナル・コンピュータやワークステーションなどから構成される場合、そのマイクロプロセッサ（MPU）は、これまで知られたいかなるシングルコア・プロセッサまたはマルチコア・プロセッサを使用することができる。

また、ユーザ・ノード２２０がパーソナル・コンピュータやワークステーションとして構成される場合、そのオペレーティング・システム（OS）は、WINDOWS（登録商標）、UNIX（登録商標）、LINUX（登録商標）、MAC OSなど、これまで知られたいかなるOSでも利用することができる。さらに、ユーザ・ノード２２０は、携帯電話やPDAとして実装することができ、この場合、CPUとしては、専用のASICとして構成することもできるし、低消費電力型のCPUを使用し、WindowsCE（登録商標）や専用ブラウザを搭載して、銀行サービス・サーバにアクセスする構成として実装することができる。

さらに、ユーザ・ノード２２０は、銀行サービス・サーバ２１０や他のウェブ・サイトにアクセスするため、Internet Explorer（登録商標）、Mozilla（登録商標）、Opera（登録商標）、FireFox（登録商標）などのブラウザ・ソフトウェアを実装することができる。

銀行サービス・サーバ２１０は、サーバなどとして実装でき、そのマイクロプロセッサとしては、PENTIUM（登録商標）、XEON(登録商標）、PENTIUM（登録商標）互換チップなど、CISCアーキテクチャのマイクロプロセッサ、または、POWERPC（登録商標）などのRISCアーキテクチャのマイクロプロセッサを、シングルコアまたはマルチコアの形態で実装することができる。また、銀行サービス・サーバ２１０は、WINDOWS（登録商標）200X、UNIX（登録商標）、LINUX（登録商標）などのオペレーティング・システムにより制御され、C、C++、Java（登録商標）、JavaBEANS（登録商標）、PERL、RUBYなどのプログラミング言語を使用して実装される、CGI、サーブレット、APACHE、IIS(Internet Information Server)などのサーバ・プログラムを実行し、ユーザ・ノード２２０から送付される各種リクエストを処理し、ユーザ・ノード２２０にレスポンスを返す。

ユーザ・ノード２２０と、銀行サービス・サーバ２１０との間を接続するネットワーク２９０は、イーサネット（登録商標）、FDDI、トークンリング、IEEE.802.xなどワイヤレス通信を使用する物理層プロトコルの下で、TCP／IPといったトランザクション・プロトコルを使用するHTTP、HTTPSなどのファイル転送プロトコルでテータ送受信が行われる。なお、ユーザ・ノード２２０と銀行サービス・サーバの間のトランザクションには、SSL(Secure Socket Layer)などのセキュア通信を使用して通信セキュリティを向上させることができる。

以下、本実施形態の銀行サービス・サーバ２１０の機能構成について詳細に説明する。銀行サービス・サーバ２１０は、ゲートウェイ処理部２３０を含んで構成されている。ゲートウェイ処理部２３０は、ユーザ・ノード２２０から送付されたリクエストに応じて適切なサーバ・アプリケーションを呼び出してリクエストを処理させており、銀行サービス・サーバ２１０の内部モジュールとしてではなく、独立したゲートウェイ・サーバとして実装することもできる。なお、図２に示した機能ブロックは、銀行サービス・サーバ２１０が、各機能処理部として情報処理装置を機能させるための実行プログラムをRAMなどの実行空間に展開し、CPUまたはMPUがプログラムを実行することにより情報処理装置上に実現されている。

銀行サービス・サーバ２１０は、ログイン認証部２３２と、ユーザ認証部２４０とを含んで構成される。ログイン認証部２３２は、例えば、銀行サービス・サーバ２１０がユーザを最初に登録する際に発行する、ユーザID、パスワードなどを使用するTelnetプロトコルや公開鍵暗号法などを利用するSSH(Secure Shell)プロトコルなどを使用して実装することができる。銀行サービス・サーバ２１０がユーザ・ノード２２０についてログイン認証に成功すると、ユーザ認証部２４０は、ユーザ・ノード２２０から送付されるユーザID、パスワードとは異なるワンタイム・パスワードを使用するユーザ認証を実行する。ユーザ認証部２４０は、ワンタイム・パスワードを銀行サービス・サーバ２１０から取得し、ワンタイム・パスワードが、ユーザIDに固有のものであるか否かを検査することによってユーザ認証処理を実行する。

この目的のため、銀行側は、正規登録ユーザに対して時系列的にみてユーザに固有のワンタイム・パスワードを生成する認証デバイスをユーザに所持させている。このような認証デバイスは、リニアフィードバック・シフトレジスタ（ＬＦＳＲ）を使用して一定間隔毎に設定された桁数の乱数を発生させ、当該乱数の発生サイクルなどを、認証デバイス／ユーザID毎に固有となるように構成しておくことができる。ユーザ認証部２４０は、ワンタイム・パスワードの検証を行う際には、ユーザDB２６０にユーザIDに対応付けて登録するワンタイム・パスワード情報を使用してソフトウェア的に演算することで、ワンタイム・パスワードの一致不一致を検証することで、電子署名などユーザ・ノード２２０に局在化される認証プロトコル以外の方式で本人認証の精度を向上させている。

さらに、銀行サービス・サーバ２１０は、決済承認番号生成部２３４と、部分情報取得部２４２とを含んで構成されている。決済承認番号生成部２３４は、ユーザ・ノード２２０が、ワンタイムデビット・サービスのために実際に利用でき、発行者ノードによりオーソライズされた決済承認番号を生成する。また、決済承認番号生成部２３４は、決済承認番号を生成するに際して、部分情報取得部２４２を呼び出して、部分情報データベース２５０（以下、部分情報DB２５０として参照する。）に格納された部分情報をランダムに取得し、決済承認番号生成部２３４に渡し、決済承認番号の生成を可能とする。この目的のため、部分情報取得部２４２は、乱数発生部２４６を含んでいて、部分情報DB２５０から決済承認番号を生成する部分情報を取得する。

また、決済承認番号生成部２３４は、決済承認番号を生成する際には、ワンタイムデビット・サービスのオーソライズを証明すると共に、取引種別などを規定する制御情報を取得し、部分情報に結合させて、発行者ノードによってオーソライズされた決済承認番号を生成する。

銀行サービス・サーバ２１０は、決済承認番号の生成が完了すると、ユーザ通知部２３８を介して決済承認番号をユーザ・ノード２２０に通知する。ユーザ通知部２３８は、銀行サービス・サーバ２１０がユーザ・ノード２２０との間でデータ送受信を行うために必要がグラフィカル・ユーザ・インタフェース（ＧＵＩ）を生成する他、メーラなどを含んで構成され、ユーザ・ノード２２０上に表示するウェブ・ページを表示させ、また通知の必要性に応じてメール送信を行う。必要となる通知としては、残高不足、決済承認番号の送付、その他営業通知などを挙げることができ、特定の目的に限定されない。

さらに、銀行サービス・サーバ２１０は、部分情報ＤＢ２５０、ユーザDB２６０、決済ログＤＢ２７０を管理し、データテーブルの作成・更新・同期化および検索処理を実行するDBアクセス部２４４を含んで構成されている。DBアクセス部２４４は、生成された決済承認番号を、決済承認番号の取得を要求したユーザIDに対応付けて登録すると共に、決済承認番号の無効化を管理している。また、DBアクセス部２４４は、銀行サービス・サーバ２１０に対してアクセスするユーザのユーザID、ログイン・パスワード、銀行口座番号などユーザに関連して変更されるユーザ・データを管理するユーザDB２６０に対してアクセスし、認証およびアクセス権限の確認、ユーザアカウントの追加などを実行する。また、DBアクセス部２４４は、本実施形態においては、部分情報DB２５０の管理も担当し、決済承認番号生成部２３４から決済承認番号生成要求が発行されると、部分情報処理部２４２が発行する部分情報取得要求が含む乱数列を使用して部分情報DB２５０に対してSQL文などによる照会を発行し、部分情報の取得を可能とする。

また、DBアクセス部２４４は、部分情報DB２５０に格納する部分情報を登録する部分情報テーブルに対して部分情報を登録し、また部分情報がリースされると、該当する部分情報を部分情報DB２５０から削除する処理を行う。DBアクセス部２４４は、データベース・アプリケーションとして実装することができ、例えば、DB2（登録商標）、Oracle（登録商標）、ACCESS（登録商標）などのリレーショナル・データベースを使用することもできるし、XMLデータベース、オブジェクト指向データベース(OODB)を利用して実装することができる。

銀行サービス・サーバ２１０は、決済要求処理部２３６を含んで構成されている。決済要求処理部２３６は、アクワイアラ・ノードなどの適切なノードから購買契約成立に関連して送付される決済要求を含む権利確認要求、または決済要求と権利確認要求とを別々のパケットとして受領すると、DBアクセス部２４４を呼び出し、ユーザDB２６０に対してSQL(Structured Query Language)文を発行し、決済の要求が含む決済承認番号を検索させ、当該決済承認番号が有効か否か、すなわち、本実施形態でのコンテキストにおいては、機能的に表現すれば、決済承認番号が既に利用されているか否か、データ上での記述では、ユーザDB２６０内に当該決済承認番号が見出されるか否かを判断する。なお、本実施形態では、決済要求や権利確認要求の構成形式およびトランザクション形式に依存することなく、権利確認の検査にパスした決済を指令するためにネットワークを介して受領する要求を、用語「決済の要求」として総合的に参照する。

ユーザDB２６０内に該当する決済承認番号が見出された場合、決済要求処理部２３６は、決済サーバ２８０に対し、決済指令を発行し、対応するユーザIDの銀行口座から、決済の要求に含まれる金額を決済処理をトライするように指令する。決済サーバ２８０は、決済承認番号に関連するｅ−コマースおよびそれに対する代金決済を管理するために決済管理データベース（以下、決済管理DBとして参照する。）２８０ａを管理し、決済承認番号の無効化と代金決済処理の、高いセキュリティレベルで、非同期化させている。なお、決済サーバ２８０が実装する振り替え処理についてはより詳細に後述する。なお、説明の便宜上、銀行サービス・サーバ２１０と、決済サーバ２８０とは別体として説明しているが、機能的に分離されている限り、同一のサーバ内のサーバ・アプリケーションとして実装されることについて問題はない。

そして、決済要求処理部２３６は、決済サーバ２８０から代金引落とし処理、すなわち決済処理が完了した通知を受領すると、ユーザDB２６０の対象となる決済承認番号を削除し、決済ログ・データベース（以下、決済ログDBとして参照する。）２７０の対応するレコードに、決済承認番号を利用する権利の承認要求に対応して発行される承認番号の他、当該権利承認要求が含む、購買内容、決済日時、振り替え金額、差額調整金額などの情報とともに記入する。

ユーザDB２６０は、当該ユーザIDについて割当てられた未行使の決済承認番号を登録しているので、決済要求処理部２３６は、ユーザDB２６０の照会により、決済承認番号にヒットしない場合、不正要求と判断し、決済を実行しない。すなわち、本実施形態では、未利用の決済承認番号のみをユーザDB２６０に登録しておき、決済要求処理部２３６は、ユーザDB２６０のみに照会を発行して決済条件を判定するので、決済承認番号のワンタイム利用が可能とされる。

なお、決済承認番号のワンタイム利用を可能とするためには、DBアクセス部２４４がユーザDB２６０の使用済み決済承認番号にフラグを設定する処理を行うことも可能である。しかしながら、決済承認番号をワンタイム利用させるコンテキストにあっては、既利用の決済承認番号は、以後の管理の目的から、決済DB２７０において管理するべきものであり、クレジット・カード番号などのように、ユーザDB２６０において常時ユーザIDに関連付けておく必要性はない。このため、ユーザDB２６０の記憶容量や検索のスケーラビリティおよび処理オーバーヘッドといった観点から見て、既使用の決済承認番号は、決済ログDB２７０に移動して決済ログと共に管理することが好ましい。また、決済承認番号の有効・無効について、本実施形態のように、ユーザDB２６０において有効な決済承認番号のみを登録させて管理することにより、ユーザDB２６０に対して例えばSQL攻撃などでアタックされた場合に、決済承認番号を無効化させるための無効化フラグの有効化などの悪意ある攻撃ができず、よりセキュリティ性を向上させることができる。

以上のトランザクションにより、ユーザと加盟店との間の商品／サービスの購入／決済サイクルが完結する。上述したキャッシュレスｅコマース・サイクルは、発行者ノードによって代金決済についてオーソライズされた銀行ノードが、銀行ノードの認証により発行され、設定された有効期間生存し、生存期間中において１度商品購入またはサービス利用のために利用された後に効力を失う、決済承認番号を使用するワンタイムデビット・サービスとして提供される。ワンタイムデビット・サービスは、物理的なカードの発行を伴うことなく提供することができ、デビット・サービスの利用性を向上することができる。

図３は、本実施形態の銀行サービス・サーバ２１０が実行するワンタイムデビット・サービスの実施形態のフローチャートである。図３の処理は、ステップＳ３００から開始する。なお、本実施形態の銀行サービス・サーバ２１０は、デーモンまたはサービスとして図３の処理を実行する。ステップＳ３０１では、ユーザ・ノード２２０からのアクセス要求を受領する。この際、Telnetプロトコルなどにしたがって、ユーザ・ノード２２０からは、ログイン・パスワードおよびユーザIDが送付されるので、銀行サービス・サーバ２１０は、ステップＳ３０２で、ログイン認証を実行する。なお、ユーザIDは、当該ユーザが保有する銀行口座番号とすることができる。

ステップＳ３０２でログイン認証に失敗した場合（ｎｏ）処理を再度ステップＳ３０１に戻し、後続するアクセス要求を待機する。一方、ステップＳ３０２でログイン認証に成功した場合、ステップＳ３０３でユーザ・ノードから送付されるワンタイム・パスワードを取得し、ユーザ認証部２４０によるワンタイム・パスワードを使用するユーザ認証を実行する。ステップＳ３０３の認証は、ユーザに予め貸与または譲渡してある認証デバイスが生成するワンタイム・パスワードを、ユーザ認証部２４０が銀行サービス・サーバ２１０が管理するデータを利用してシミュレーションし、各値の一致不一致を用いて行うことができる。なお、ワンタイム・パスワードを使用するユーザ認証は、本実施形態の要旨ではないので、さらなる詳細な説明は行わない。

ステップＳ３０３で、ユーザ認証に失敗した場合（ｎｏ）。処理をステップＳ３０１に戻し、後続するアクセス要求を待機する。また、ステップＳ３０３でユーザ認証に成功した場合（ｙｅｓ）ステップＳ３０４で、アクセス要求が決済承認番号取得要求であるか否かを判断する。ステップＳ３０４で決済承認番号取得要求でない場合には（ｎｏ）処理をステップＳ３１１に分岐させて他サービスを呼び出す。一方、ステップＳ３０４で決済承認番号取得要求であると判断した場合（ｙｅｓ）、ステップＳ３０５で、当該ユーザIDについてユーザDB２６０を検索し、当該ユーザIDについて既に割当てられている決済承認番号が設定した上限値を超えているか否かを判断する。上限値は、決済承認番号の容量やデビット・サービスの利用期待度などに応じて適宜設定することができるが、説明する実施形態では、４つの異なる番号として設定することができる。

ステップＳ３０５で、既に上限値に達して登録されている場合（ｎｏ）、処理をステップＳ３１２に分岐させ、ユーザにその旨を通知し、処理をステップＳ３０１に戻し、後続するアクセス要求を待機する。一方、ステップＳ３０５で、有効な決済承認番号が設定された上限値以下の場合（ｙｅｓ）、ステップＳ３０６で適切な桁数、例えば８桁の乱数列を発生し、部分情報DB２５０から対応する部分情報を採番する。

その後、ステップＳ３０７で、決済承認番号生成部２３４は、適切な記憶領域から取得した、発行者ノードまたは銀行ノード自身がオーソライズした銀行コードおよびサービス種類を示すサービス・コードやチェックディジット・コードなどと、取得した部分情報とを結合して決済承認番号を生成する。本実施形態では、決済承認番号は、数字、アルファベット、キャラクタなどASCIIコードを含んで構成することができるが、既存の決済システムへの適合性の点から、適切な桁数の数字列とすることが好ましい。本実施形態では、制御情報は、銀行コード、サービス・コード、チェックディジット・コードなどを含むことができる。また、セキュリティ性および最大ユーザ数の観点から、数字列の桁数はできるだけ大きい方が好ましく、特定の実施形態では、部分情報として利用する数字列は、８桁とすることができる。

ステップＳ３０８では、決済承認番号を生成した後、ユーザに宛てて決済承認番号を送付し、トランザクションが成功裏に終了した後、ユーザDB２６０の当該ユーザIDのフィールドに生成した決済承認番号を登録し、以後の決済のために利用可能とする。上述した部分情報は、部分情報DB２５０に登録されており、決済承認番号生成部２３４が決済承認番号を生成する際に生成する８桁の乱数列が部分情報として登録された数字列に一致することにより、当該部分情報がリース中であるか否かに応答して乱数列を採番するか否かを制御する。

図４は、本実施形態の銀行サービス・サーバ２１０のDBアクセス部２４４による部分情報DB２５０に対するデータベース処理のフローチャートである。図５の処理は、ステップＳ４００で、銀行サービス・サーバ２１０がサービスを開始した時点で開始する。ステップＳ４０１で、ランダム作成プログラムを起動するか否かを判断し、ランダム作成プログラムを起動するべきと判断した場合（ｙｅｓ）、ランダム作成プログラムを呼び出して、ステップＳ４０２で所定の桁数の数字列、特定の実施形態では、８桁の数字列を発生させ、部分情報DB２５０が管理する部分情報テーブルに登録し、発生した数字列で全部（１憶個）のレコードを埋め尽くすまで継続する。

なお、本実施形態においてランダム発生プログラムとは、決済承認番号を生成するために利用する制御コード以外の部分情報として使用される数字列を生成し、銀行サービス・サーバ２１０が管理する部分情報ＤＢ２５０をリフレッシュするためのプログラムであり、rnd()関数などを使用して実装することができる。また、ステップＳ４０１の判断で、ランダム発生プログラムを起動しないと判断した場合（ｎｏ）、処理をステップＳ４０３に分岐させて、部分情報取得要求の受領を待機する。

なお、ステップＳ４０１の判断は、前回起動時からの時間間隔、前回起動時からの決済承認番号発行数、サーバメンテナンス時などに基づいて定期的または不定期的に行うことができる。ステップＳ４０２で、説明する実施形態では、00000000〜999999999の１憶個の乱数が数字列としてランダムに登録された後、ステップＳ４０３で部分情報取得部２４２から部分情報取得要求が発行されたか否かを判断する。ステップＳ４０３で、部分情報取得要求が発行されたと判断した場合（ｙｅｓ）、ステップＳ４０４で、乱数発生部２４６を呼び出して乱数列（８桁）発生させ、発生した乱数列をSQL文にセットする。

この場合のSQL文は、例えば、”SELECT PARTIAL INFORMATION FROM PARTIAL TABLE WHERE PARTIAL INFORMATION = RANDOM NUMBER”として部分情報DB２５０に照会を発行する。なお、変数「PARTIAL TABLE」は、部分情報テーブルを参照する変数であり、変数「PARTIAL INFORMATION」は、部分情報を参照する変数であり、変数「RANDOM NUMBER」は、乱数発生部２４６が発生した８桁の乱数列を参照する変数である。一方、ステップＳ４０３で部分情報取得要求が発行されない場合（ｎｏ）、処理を再度ステップＳ４０３に戻して、後続する部分情報取得要求の発行を待機する。

一方、ステップＳ４０５では、DBアクセス部２４４は、発行したSQL文の結果を検査し、SQL文の検索結果が有意な数字列を返したか否かを判断する。ステップＳ４０５でSQL文の照会結果が有意な場合（ｙｅｓ）ステップＳ４０６で検索された数字列を部分情報としてセットして部分情報取得部２４２からの部分情報取得要求のレスポンスとして返す。一方、ステップＳ４０５で、SQL文の検索結果が、値NULLを返すなど有意の値ではない場合（ｎｏ）、処理をステップＳ４０４に戻しさらに他の乱数列を発生させ、SQL文に発生させた乱数列をセットして、ステップＳ４０５で有意な数字列が返されるまで照会処理を反復する。

その後、ステップＳ４０７で、例えばSQL文として“DELETE FROM PARTIAL TABLE WHERE PARTIAL INFORMATION = RANDOM NUMBER”を発行し、該当する部分情報を部分情報ＤＢ２５０が管理する部分情報テーブルから削除する。その後、処理をステップＳ４０１に戻し、ランダム作成プログラムを起動するか否かの判断を行い、当該判断に応じて、図４の処理を反復させる。

図５には、本実施形態で使用する部分情報DB２５０のデータ構造５００を示す。部分情報DB２５０は、部分情報を部分情報テーブルとして登録することができる。図５には、第１実施形態の部分情報テーブル５１０および部分情報テーブルの第２実施形態の部分情報テーブル５２０を示す。部分情報テーブル５１０は、本実施形態の最も好ましい実施形態を示し、図２に示すDBアクセス部２４４の処理にしたがって生成され、部分情報テーブル５１０は、部分情報の本体を構成する数字列を登録するフィールドから構成されている。

図６の部分情報テーブル５１０は、部分情報がリースされると、当該リースされた部分情報が既リースとして削除され、リースされた部分情報増加するにしたがって部分情報テーブル５１０のエントリ行が減少するように構成されている。さらに、部分情報テーブル５１０には、発行者ノードから割当てられた銀行コードである数字列＝123456が紐付けされていて、制御情報毎に発行する部分情報の管理を可能としている。本実施形態において、決済承認番号に余裕があり、決済承認番号を再利用しない場合、部分情報テーブル５１０ように、一度リースされた部分情報を部分情報テーブル５１０が再生成されるまで、再利用されないように設定することが、決済承認番号のセキュリティ担保という点では好ましい。

一方、部分情報テーブル５２０は、銀行コードとして数字列＝123487が紐付けられていて、部分情報テーブル５１０とは異なり、特定の部分情報が現在リース中である、すなわち、既リースであることを示すリース中FLGを登録するフィールドと、部分情報を登録するフィールドとを含んで構成されている。さらに、部分情報テーブル５２０は、部分情報を与える数字列が、適切なハッシュ関数、例えば、SHA−1、SHA−3、MD−5などを使用してハッシュ化され、HASH値として登録されている。部分情報を、部分情報テーブル５２０の形式で登録することにより、仮に銀行サービス・サーバ２１０に対し悪意ある攻撃が行われた場合でも、現在リース中の部分情報の漏洩を防止することができ、よりセキュリティ性を向上させることができる。

さらに他の実施形態では、部分情報テーブル５２０において部分情報をHASH化せずに登録しておき、部分情報テーブル５１０のように一旦リースした部分情報が利用できないようにするため、リース中FLGを設定するのではなく、部分情報テーブル５１０の処理と同様に、当該部分情報を登録するレコードを部分情報テーブル５２０から削除する構成とすることができる。

この目的で、銀行サービス・サーバ２１０は、８桁の数字列に対して任意の制御コードを付してHASH値を生成し、乱数列の一致を判断する際に当該制御コードを生成された乱数列に追加してHASH値を計算し、相互比較を行うこともできる。また、部分情報テーブル５２０は、ワンタイムユースを認める本実施形態のコンテキストにおいて、決済承認番号のワンタイムユースが終了した後に部分情報を再リースする場合に好ましい実施形態である。部分情報を再リースして番号リサイクルを行う場合、発番済の部分情報を適切な期間、例えば５年保管しておき、当該期間経過後、これらの発番済の部分情報を再利用するタイミングで一斉に「リサイクル可」にステイタス変更を実行して、ランダム発生プログラムの起動、部分情報テーブル５１０、５２０のリフレッシュ、部分情報のリースの処理を再度新たな部分情報テーブル５１０、５２０を利用して再開させてもよい。

なお、部分情報テーブル５１０、５２０は、銀行サービス・サーバ２１０のサービス開始時にランダム作成プログラムを起動することにより生成され、以後サービスが提供される期間にわたって管理され、部分情報取得部２４２からのランダムなアクセスを受けて、部分情報のリース判断を行うために利用される。部分情報テーブル５１０、５２０の両方について、部分情報を構成する数字列やハッシュ値の配置は、部分情報テーブル５１０、５２０を生成する際に数字列をランダムに発生させ、発生させた数字列やハッシュ値を発生順に部分情報テーブル５１０、５２０に登録することができる。

図６は、本実施形態の銀行サービス・サーバ２１０が実行する決済承認番号生成処理の第１の実施形態のフローチャートである。図６の処理は、ステップＳ６００から開始し、ステップＳ６０１では、部分情報取得部２４２が設定された桁数の乱数を発生させ、ステップＳ６０２では、部分情報取得部２４２は、部分情報DB２５０に対して照会を発行し、発生した乱数が登録されているレコードのリースFLGの値を検査する。なお、部分情報テーブル５１０、５２０が、銀行コードなど制御情報に紐付けされている場合には、ステップＳ６０２の処理に先立って、照会を発行するべき銀行コードの決定を行う。

ステップＳ６０２では、部分情報取得部２４２は、発生した乱数列に対応する部分情報が登録されているか否かを検査し、該当する部分情報を新規にリースして良いか否かを判断する。図６の実施形態では、ステップＳ６０２の判断は、生成した乱数列が部分情報テーブル５１０に登録されていないことに基づいて行われ、リース中の場合（ｙｅｓ）、処理をステップＳ６０１に戻し、ステップＳ６０２の判断でリース中でないとの判断がなされるまで再度別の乱数を生成させる。一方、ステップＳ６０２で、生成した乱数列がリース中ではないと判断した場合（ｎｏ）、ステップＳ６０３で発生した乱数列に相当する値を部分情報として確定し、決済承認番号生成部２３４に送付する。本実施形態では、乱数列をそのまま部分情報として設定することもできるし、該当する部分情報を部分情報テーブル５１０から取得してもよい。ステップＳ６０４では、決済承認番号生成部２３４は、銀行コード、サービス・コードおよびチェックディジット・コードなどの制御情報と、部分情報とを適切な配置として結合し、決済承認番号を生成する。

ステップＳ６０５では、生成した決済承認番号をユーザ通知部２３８からユーザに宛てて送付する。この時の送付は、ウェブ・ページ上の決済承認番号を表示させるフィールドに値を表示させることによっても行うことができるし、登録されたメールアドレスに対してメール送信することによっても行うことができる。

ユーザ通知部２３８からの通知が成功裏に終了すると、処理はステップＳ６０６で処理をDBアクセス部２４４に制御を渡し処理を終了する。なお、この後、DBアクセス部２４４は、部分情報テーブル５１０から、リースした部分情報を削除して、次の部分情報取得要求を処理する。

図７は、本実施形態の銀行サービス・サーバ２１０が実行する決済承認番号生成処理の第２の実施形態のフローチャートである。図７に示した第２の実施形態は、部分情報がハッシュ値として登録されている場合の処理である、図７に示した処理は、ステップＳ７００から開始し、ステップＳ７０１では、部分情報取得部２４２が設定された桁数の乱数を発生させ、生成した乱数列のHASH値を計算した後、HASH値が一致したレコードのリースFLGの値を検査する。なお、部分情報テーブル５２０が、銀行コードなど制御情報に紐付けされている場合には、ステップＳ７０２の処理に先立って、照会を発行するべき銀行コードの決定を行うことが必要である点は、図６と同一である。

ステップＳ７０３では、部分情報取得部２４２は、HASH値が一致したレコードのリースFLGを検査し、該当する部分情報を新規にリースして良いか否かを判断する。ステップＳ７０３の判断の結果、生成した乱数列がリース中の場合（ｙｅｓ）、処理をステップＳ７０１に戻し、ステップＳ７０３の判断でリース中でないとの判断再度別の乱数を生成させる。一方、ステップＳ７０３で、検索の結果生成した乱数列がリース中ではない場合（ｎｏ）、ステップＳ７０４で発生した乱数列を部分情報として確定し、決済承認番号生成部２３４に送付する。その後、ステップＳ７０５、ステップＳ７０６を、図６のステップＳ６０５、Ｓ６０６と同様にして実行した後、処理はステップＳ７０８で処理をDBアクセス部２４４に制御を渡し処理を終了する。

図８は、本実施形態の決済承認番号生成部２３４が実行する図６および図７の制御情報と部分情報との結合処理の概略図である。図８に示すように、結合するべき制御情報８６０は、銀行コード８１０、サービス・コード８３０、およびチェックディジット・コード８４０を含む。一方、部分情報８７０は、部分情報取得部２４２が生成した乱数列８２０として提供される。なお、決済承認番号は、数字列のみで機能するが、ユーザの認識性を向上する目的で、ハイフンなどの非数字コードを組み合わせて表示することもできる。

決済承認番号生成部２３４は、部分情報DB２５０のデータ構成に依存して、制御情報を最初に取得しておく処理と、部分情報を取得した後、制御情報を適切な記憶領域から取得する処理のいずれかを使用して、制御情報８６０および部分情報８７０を取得する。決済承認番号生成部２３４は、取得した制御情報８６０と、部分情報８７０とを設定されたシーケンス順に読み出して行き、順次数字列を延長させて、制御情報８６０および部分情報８７０を結合する。なお、制御情報８６０を構成するサービス・コード８３０およびチェックディジット・コード８４０は、銀行コード８１０とは別々に結合処理において呼び出され、設定された位置に配置される。

決済承認番号生成部２３４が上述した処理を終了した後、決済承認番号８５０が作成され、バッファメモリなどに以後の処理のため格納される。図８に示した実施形態では、決済承認番号８５０は、１６桁の数字列として生成されている。この理由は、既存のクレジットカード・システムの情報処理基盤を有効利用するために互換性のある数字列として構成するためであり、ワンタイムデビット・サービスのための処理ネットワークを含めて構築する場合には、図８に示した数字列、桁数でなくともよい。

図９は、本実施形態のユーザDB２６０が管理するユーザ・データのデータ構造を示す。図９に示すユーザDB２６０は、DBアクセス部２４４からのSQL文などを使用してアクセスされる、リレーショナル・データベース、XMLデータベースとして実装することができる。図９では、例示的にリレーショナル・データベースのフォーマットでテーブル構造としてユーザ・データを登録する実施形態である。ユーザ・データは、各ユーザに固有のユーザＡ〜ユーザＤといったユーザIDを登録するレコード９１０と、ユーザIDに対応付けされる口座番号を登録するレコード９２０と、ログインPWD（パスワード）、ログインID、ワンタイム・パスワードをユーザ認証部２４０がシミュレーションするために利用するワンタイムPWD情報をそれぞれ登録するレコード９３０、９４０、９５０とを含んで構成されている。

なお、ログインPWD、ログインIDおよびワンタイムPWD情報は、ユーザDB２６０とは別にアクセス管理DBなどに分離して登録されていてもよい。

さらにユーザ・データ９００は、ユーザID毎に現在有効な決済承認番号を、その有効期限情報と共に登録するレコード９６０を含んで構成されている。図９に示した実施形態では、銀行サービス・サーバ２１０は、特定のユーザIDに対して独立した４決済承認番号を同時に発行することができ、図９に示した実施形態では、ユーザＡが、４決済承認番号を保有しており、その他のユーザＢおよびユーザＢは、１決済承認番号を保有していることが示されている。なお、ユーザＤは、ワンタイムデビット・サービスのための決済承認番号を未だ取得していない状況にある。

有効期限は、一旦発行されたワンタイムデビット・サービスの決済承認番号が未使用時で有効な期間を示し、例えば、５年など、銀行ノードの状況およびサービスの利用度に応じて適宜設定される期間である。図９に示したユーザ・データは、リレーショナル・データベースのテーブル形式として説明しているが、特定の実装形式に応じて、XMLデータベースとして構成することもできるし、OODB(オブジェクト指向データベース）として構成することもできる。

図１０は、本実施形態の銀行サービス・サーバ２１０が実行する決済承認番号の無効化処理の実施形態のフローチャートである。図１０の処理は、図２の決済要求処理部２３６が実行する処理であり、処理は、ステップＳ１０００からスタートし、図３と同様に、デーモンまたはサービスとして実行され、ステップＳ１００１で、決済要求を発行する適切なノードから決済要求を受領したか否かを判断する。決済要求を受領しない場合（ｎｏ）には、処理をステップＳ１００１に戻し、決済要求の受領を継続して待機する。

ステップＳ１００１で、決済要求を受領した場合（ｙｅｓ）ステップＳ１００２で決済要求が含む決済承認番号、購買内容、タイムスタンプを取得し、ステップＳ１００３で、ユーザDB２６０中の決済承認番号が有効であるかを、ユーザDB２６０中に受領した決済承認番号が登録されているか否かに基づいて判断する。ユーザDB２６０中の該当するユーザIDに関して決済承認番号が登録されていない場合（ｎｏ）、処理をステップＳ１００８に分岐させ、不正請求として決済サーバに通知し、決済サーバ２８０による不正請求処理モジュールを呼び出して、処理をステップＳ１００１に戻し、後続する決済要求を待機する。

一方、ステップＳ１００３で、ユーザDB２６０中に決済承認番号が見出された場合（ｙｅｓ）、ステップＳ１００４で、該当するユーザの口座番号を取得し、決済指令を口座番号情報およびユーザIDの値と共に決済サーバ２８０に発行する。ステップＳ１００５では、決済サーバ２８０からの応答を待機し、決済サーバ２８０から決済成功の通知を受領した場合（ｙｅｓ）、ステップＳ１００６で、DBアクセス部２４４を呼び出してユーザDB２６０から決済処理を指令した決済承認番号を削除することによって無効化し、決済ログDB２７０の該当するユーザID、購買内容などに対応付けて登録する。なお、このときの決済成功の通知は、図４の決済が成功した段階で決済サーバ２８０が発行する。

なお、ステップＳ１００３〜Ｓ１００６の処理の詳細については、後述する図１１で詳細に説明する。ステップＳ１００７では、処理中の決済要求に未処理の決済承認番号が残っているかを判断し、残っていない場合、処理をステップＳ１００１に分岐させ後続する決済要求を待機する。一方、未処理の決済承認番号が残っている場合（ｙｅｓ）処理をステップＳ１００２に分岐させ、ステップＳ１００７の判断で、未処理の決済承認番号がないと判断するまでステップＳ１００２〜Ｓ１００７の処理を反復させる。

一方、ステップＳ１００５で、決済不成功の通知を受領した場合（ｎｏ）、ステップＳ１００９で、ユーザ通知部２３８からユーザに対して決済不能であったことおよびその原因を通知する。同時のステップＳ１００９では、アクワイアラ・ノードなどに対しても決済未了の通知を行い、所定期間内に再度決済要求を送付するように依頼する。そして決済要求処理部２３６は、同一の加盟店ノードなどからの同一の決済承認番号の処理を可能とするため、決済成功または決済不成功にかかわらず、処理対象の決済承認番号について、一定期間、例えば１０日間生存させ、決済不能の原因の解消に備える構成とすることができる。なお、この実施形態でも処理対象としている同一の決済承認番号についての異なる加盟店ノードからの決済要求を受領した場合には、当該決済承認番号の利用承認は行わないことで、ワンタイムデビット・サービスの実効性を担保しながら、加盟店ノード側の利用性も向上させることができる。

以上の決済要求処理部２３６の処理により、ユーザDB２６０から既使用の決済承認番号が削除されるので、決済承認番号は、ユーザDB２６０内での存在・不存在のみに基づいてその有効性が判断でき、ワンタイムデビット・サービスの利用に伴って、ユーザIDなどの銀行ノードがセキュアに管理する情報をネットワークを介して転送することなく、加盟店ノードと、ユーザ・ノードとの間で固有に取り決められたハンドルネームなどをネットワークを通じて送信するだけで決済の承認が可能とされる。

図１１は、本実施形態のワンタイムデビット・サービスにおける決済処理のフローチャートを示す。なお、図１１の処理は、本実施形態では、銀行サービス・サーバ２１０と、決済処理サーバ２８０とが機能的に共同して処理を遂行する。しかしながら、銀行サービス・サーバ２１０と、決済サーバ２８０とを統合して実装する場合、同一のサーバの銀行サービス・モジュールと、決済サービス・モジュールとがプロセス間通信などを利用して実行するプロセスとされる。以下、図２に説明したコンテキストに沿って、銀行サービス・サーバ２１０と、決済サーバ２８０とが図１１の処理を連携して実行するものとして説明する。

図１１の処理は、ステップＳ１１００から開始し、ステップＳ１１０１で、加盟店ノードまたはアクワイアラ・ノードといった適切なノードから権利確認要求を受領する。説明する実施形態では、権利確認要求は、実質的な決済要求として構成することができ、権利確認要求パケット＝AUTHORIZATION_REQUESTは、ワンタイムデビット・サービスを利用しようとするユーザが、加盟店ノードの提供するネットショップにアクセスしてカード情報およびユーザ情報を入力し、商品・サービスの購入を要求した段階で、加盟店ノードから、または加盟店ノードからアクワイアラ・ノードを介して銀行サービス・サーバ２１０に決済要求として送付される、決済要求処理部２３６は、決済要求を決済サーバ２８０に発行する前に、権利確認要求を検査し、権利確認要求の検査にパスすることによって、決済指令を決済サーバ２８０に発行して決済処理を開始させる。銀行サービス・サーバ２１０は、ステップＳ１１０１で権利確認要求を受領すると、権利確認要求パケットからカード情報、口座情報、代金情報を抽出する。この処理は説明する実施形態では、決済要求処理部２３６が実行するものとして説明するが、銀行サービス・サーバ２１０のいかなる機能部が実行してもよい。なお、カード情報には、銀行サービス・サーバ２１０が発行した決済承認番号であるカード番号が含まれている。

ステップＳ１１０２で、銀行サービス・サーバ２１０は、取得したカード情報から、カード種別、利用限度額および有効期限などを検査し、同時にカード情報が紐付けられたユーザの口座状態を検査し、両方の検査にパスした場合（ｙｅｓ）、ステップＳ１１０３で当該権利確認要求に対して承認番号を割り当て、承認番号、承認応答、および口座取引許可を権利確認要求の送付元に返す。この段階で、決済要求処理部２３６は、決済サーバに通知を発行し、決済サーバ２８０は、決済ログDB２７０に承認番号に対応するレコードを割り当てて追加レコードを生成させる。

一方、ステップＳ１１０２の検索をパスした権利確認要求について、決済要求処理部２３６は、決済指令を、プロセス間通信などを利用して権利確認要求に含まれるカード情報、口座情報および承認番号と共に決済サーバ２８０に送付し、決済管理DB２８０ａに登録させる。さらにステップＳ１１０３で、決済管理DB２８０ａは、決済管理DB２８０ａに登録した現在処理中の権利確認要求に関連する口座から、権利確認要求の代金情報に該当する決済金額を引落し、決済管理DB２８０ａの該当するレコードに決済済フラグなどを設定する。その後さらに、決済サーバ２８０は、銀行サービス・サーバ２１０に通知を発行し、ユーザDB２６０から該当する決済承認番号を削除し、当該追加レコードに移動させるように指令する。この処理によって、本実施形態の決済処理では、決済承認番号のワンタイム化を可能とする。

なお、ユーザDB２６０からの決済承認番号の移動は、決済処理が完了する前に、権利確認要求に対する承認を行った時点で決済サーバ２８０が、銀行サービス・サーバ２１０に指令することもでき、適宜アプリケーション・モジュールの実装形式および処理上の目的に応じて設定することができる。

一方、ステップＳ１１０２の検査にパスしない場合（ｎｏ）、ステップＳ１１０９に処理を分岐させ、権利承認拒否通知パケットを権利確認要求の発行元に返し、後続する権利確認要求の処理に対応する。権利確認要求の発行元は、当該権利証人拒否通知を受領して、ウェブ・ページ上に権利確認が拒否されたことを表示し、ユーザとの間でさらなるトランザクションを生成する。

また、ステップＳ１１０３の処理が完了した後、決済サーバ２８０は、権利確認要求に対応した決済確定通知の受領を待機する。決済確定通知は、権利確認要求に関連するｅ−コマースについての契約が終了して、ｅ−コマースの売上げが確定したことを銀行サービス・サーバ２１０に通知するトランザクションである。説明の明確化の観点で、ステップＳ１１０４では、ステップＳ１１０１で受領した権利確認要求に関連する決済確定通知の受領を待機しているものとし、決済確定通知を受領して当該決済確定通知が含む承認番号が、ステップＳ１１０１で受領した権利確認要求に該当しない場合（ｎｏ）処理をステップＳ１１０４に戻す。一方、現在注目している承認番号に該当する決済確定通知が送付された場合（ｙｅｓ）、処理をステップＳ１１０５に進め、決済確定通知から承認番号および売上げ確定金額などの確認情報を抽出し、設定したパラメータ単位で、権利確認要求が含む各種情報と前方一致、後方一致、全部一致などの組合せ判断を行いマッチング検査を実行する。

なお、ステップＳ１１０４の決済確定通知は、システムまたはサービス上の設定に応答して、ｅ−コマースにおける契約完了期間などを考慮して、通常、数日〜２ヶ月程度の期間で設定された期間内に送付される。

なお、マッチング検査のためのパラメータ設定は、セキュリティ保持上詳細な説明を省略するが、決済管理DB２８０ａが管理する特定のレコードに登録された全データについて、パラメータ設定にしたがったプロトコルで多重検査を実行することにより権利確認要求と、決済確定通知との間のコインシデンスを保証している。ステップＳ１１０６では、パラメータ設定に関連した検査プロトコルにしたがってマッチング処理にパスした場合（ｙｅｓ）、ステップＳ１１０７で、さらにカード有効性および口座状態を検査し、両方とも現在時点で良好か否かを判断する。ステップＳ１１０７の検査において良好であると判断された場合（ｙｅｓ）、ステップＳ１１０８で、決済管理DB２８０ａの該当するレコードについて、最終的な売り上げ金額と決済処理の金額との差額を自動決済し、処理をステップＳ１１０１に分岐させ後続する権利確認要求を処理する。最終的な売り上げ金額との調整は、例えば、ユーザが同一の決済承認番号を使用して設定した期間、例えば、１０日内に複数回のｅ−コマースを行った場合や、条件修正、追加などの場合に行うことができる。なお、ステップＳ１１０８の処理が終了した後、決済内容は、決済管理DB２８０ａから決済ログDB２７０に移動される。一方、ステップＳ１１０６で、マッチング処理にパスしない場合（ｎｏ）、処理をステップＳ１１１０に進め、オフラインでのマッチング処理および決済処理を行い、処理をステップＳ１１０１に分岐させ、後続する権利確認要求の処理に対応する。また、ステップ１１０７で、カード有効性および口座状態が不良である場合（ｎｏ）オフラインでの事故処理に処理を渡し、処理をステップＳ１１０１に戻しさらに後続する権利確認要求の処理を継続する。

図１１に示した処理により、ワンタイムデビット・サービスが可能とされる。なお、ステップＳ１１０２の処理を実行した段階で、決済承認番号は、ユーザDB２６０から決済ログDB２７０に移転され、この段階で該当する決済承認番号が無効化されている。この場合でも、決済管理DB２８０ａは、決済承認番号に対応するカード番号を依然として管理しているので、決済承認番号の無効化と、決済確定処理とを非同期かつ高いセキュリティ性で可能としている。

図１２は、本実施形態で、決済要求処理部２３６が実行する決済承認番号のワンタイム化処理を、ユーザ・テーブルＳ１２２０を使用して説明する図である。図１２で説明する実施形態では、ユーザＡが２回、決済承認番号Ｓ１２３０、Ｓ１２４０を利用したワンタイムデビット・サービスを利用するものとして説明する。決済要求処理部２３６は、例えばアクワイアラ・ノードから、｛決済承認番号，購買内容，タイムスタンプ｝などを含む決済要求を受領する。ここで、ユーザＡは、まず、決済承認番号Ｓ１２３０を利用して、加盟店ノードが開設するネットショップＡ店で、電気製品Ｂを購入する契約を行ったものとする。

アクワイアラ・ノードは、契約が締結された後、銀行サービス・サーバ２１０に決済要求を送付すると、決済要求処理部２３６は、当該決済要求から決済承認番号を抽出し、DBアクセス部２４４を呼び出して、抽出した決済承認番号をSQL文にセットさせ、ユーザDB２６０に対して照会を発行させる。DBアクセス部２４４は、SQL文の照会結果を、決済要求処理部２３６に返す。この際、当該検索結果は、当該決済承認番号が登録されている場合、登録しているユーザのユーザIDも含む。

決済承認番号は、ユーザ全体にわたり同時に有効な値が生成されないように部分情報取得部２４２が生成するので、ユーザDB２６０を検索するため、決済承認番号の他に値がなくとも検索が可能である。また、ユーザDB２６０が、XMLデータベースとして実装されている場合、DOMやSAXなどを利用して、木構造中における検索対象とする決済承認番号を検索することもできる。

決済要求処理部２３６は、決済要求から抽出した決済承認番号を見出すと、データ構造Ｓ１２２０の決済承認番号Ｓ１２３０の削除をDBアクセス部２４４に指令して削除させる。これを説明する目的で図１２では、決済承認番号Ｓ１２３０がグレー表示されているが、この段階で、決済承認番号Ｓ１２３０は、ユーザDB２６０から既に削除されていることを示す。その後、決済要求処理部２３６は、決済要求が含む決済承認番号、購買内容、およびユーザDB２６０から当該決済承認番号を削除した日時をDBアクセス部２４４に渡す。DBアクセス部２４４は、決済要求処理部２３６からの指令を受領すると、削除した決済承認番号と、当該決済承認番号が行使された購買内容およびユーザDB２６０から当該決済承認番号を削除した日時を、決済ログDB２７０の決済承認番号を見出したユーザIDのフィールドに記入する。

決済ログテーブルＳ１２１０は、決済ログDB２７０に構成される決済ログテーブルのうち、ユーザＡに対応するカラムを例示的に抽出して示したものである。決済ログテーブルＳ１２１０を説明すると、決済ログテーブルＳ１２１０は、既使用の決済承認番号Ｓ１２３０を登録するフィールドと、当該決済承認番号Ｓ１２３０により購入または利用されたサービスの内容および決済タイムスタンプを記録するフィールドとを含んでいる。

ユーザＡが、以後にさらに決済承認番号Ｓ１２４０を行使すると、決済ログテーブルＳ１２１０のユーザＡのカラムには、使用済みの決済承認番号と、その購買内容とが追加登録され、以後の決済ログの参照に利用される。なお、決済ログDB２７０についても、リレーショナル・データベースとして実装することもできるし、XMLデータベースとして実装することもできるし、またＯＯDBとして実装することができる。

図１３は、本実施形態の銀行サービス・サーバ２１０がユーザ通知部２３８を介してユーザ・ノード２２０のデスクトップ画面上に表示させるウェブ・ページ１３００の実施形態を示す。ウェブ・ページ１３００には、銀行サービス・サーバ２１０が提供することが可能な各種サービスについてのリンクやオンライン広告などが表示されている。ユーザが本実施形態の決済承認番号の取得を希望する際には、ログイン・ボタン１３２０をクリックし、登録ユーザ画面を開くことで、ワンタイムデビット・サービスの登録ページを開く。

図１４は、ワンタイムデビット・サービスのユーザ登録ページ１４００の実施形態を示す。ユーザ登録ページ１４００には、表示ウィンドウ１４１０内に複数の入力フィールドを有するＧＵＩ表示１４２０が表示されており、ユーザに対してワンタイムデビット・サービスのための番号を発行するページであることを認識させている。ユーザは、図１４に示したＧＵＩ表示１４２０から、自己の口座を有する店番−口座番号を入力フィールド１４３０に入力し、その後、ユーザ登録時に取得したログインIDやログイン・パスワードなどを入力フィールド１４４０、１４５０に記入する。その後、入力フィールド１４６０で利用限度額の設定を行う。

そして、ユーザは、認証デバイスがその時点で表示しているワンタイム・パスワードを入力フィールド１４７０に入力する。すべての値の記入が終了した後、ユーザは、「利用開始」ボタン１４８０をクリックすることにより、ワンタイムデビット・サービスのための決済承認番号が数字列として割当てられる。

図１５は、決済承認番号が割当てられた後の条件設定をカスタマイズするワンタイムデビット番号確認画面１５００の実施形態を示す。図１５に示したワンタイムデビット番号確認画面１５００には、ＧＵＩ表示１５１０が表示されている。図１５の実施形態中、「デビット番号をご確認下さい。」の下のフィールド１５３０に表示される数字列は本実施形態の決済承認番号である。そして、フィールド１５４０には、月／年およびセキュリティコードなどが表示されている。なお、セキュリティコードは、加盟店ノードによってはセキュリティコードの入力を要求する場合もあるので、そのようなネットショップにおいて、ユーザインタフェースを別途用意することなく、ワンタイムデビット・サービスの利用を可能とするために、銀行サービス・サーバ２１０が割当てる。

さらにフィールド１５５０には、デフォルト設定された限度金額である１０万円をユーザが変更するための入力フィールド１５５０が表示され、ユーザが利用限度額をシステム上で許容できる限度内で、変更可能とされている。ユーザは、図１５のＧＵＩ表示１５１０を介してワンタイムデビット番号の確認および利用限度額を修正して、本実施形態のワンタイムデビット・サービスを利用する準備が完了する。なお、図１５に示した各種情報は、ユーザが保存することができるように、ユーザ通知部２３８から確認メールなどとしてユーザ・ノードに送付されてもよい。なお、ユーザ通知部２３８からの通知成功に対応して、決済認証番号、利用限度額などのカスタマイズされた情報を、ユーザDB２６０などに登録して以後の処理のために利用する。

図１６は、本実施形態のワンタイムデビット番号を使用する際の実施形態において表示されるＧＵＩ表示１６００を示す。ユーザは、ユーザ・ノード２２０からネットワークにアクセスし、加盟店ノードとして機能する「ネットショップネット」のウェブ・ページにアクセスしている。ユーザが各種商品・サービスの購入や利用を要求した後、決済要求を行うと、ユーザ・ノード２２０の表示ウィンドウ１６１０には、決済情報入力ウィザード１６２０が表示される。

ユーザは、決済種類として、デビット・サービスでの支払を希望する設定を入力しており、決済情報入力ウィザード１６２０では、デビット番号の入力フィールド１６３０が表示される。ユーザは、入力フィールド１６３０にワンタイムデビット番号を入力し、さらに有効期限、CVVの値の入力を行い、「ＯＫ」ボタンをクリックすることにより、決済要求がアクワイアラ・ノードを経由して銀行ノードに送付される。この決済要求は、特定の実施形態では、条件付の決済要求を含む権利確認要求として一体の形式で発行することもできるし、他の実施形態では、権利確認要求と決済要求とを別々のパケットとしてシーケンシャルに送付することもでき、決済要求の構成形式には特に限定されるものではない。銀行ノードに設置された銀行サービス・サーバ２１０は、当該決済要求を受領すると、図３、図４、図５、図７、図８、図１１に示した処理を実行して決済処理を完了する。

以下、銀行サービス・サーバ２１０が実行する決済プロセスを、ユーザによる決済承認番号の利用ステップから説明する。ユーザは、銀行サービス・サーバ２１０にアクセスし、ログイン認証およびワンタイム・パスワードを利用したユーザ認証の後、ワンタイムデビット番号として与えられる決済承認番号を、銀行サービス・サーバ２１０が表示する画面上で事前に確認する。その後、ユーザは、特定のURI(Uniform Resource Identifier)で指定され、加盟店ノードがインターネット上に開設するインターネット・ショッピングサイトにアクセスする。

なお、インターネット・ショッピングサイトへのリダイレクトは、銀行サービス・サーバ２１０がユーザ・ノード２２０の画面上に表示するウェブ・ページのバナー広告やハイパーリンクとすることもできるし、ユーザが別のブラウジング画面を表示させ、当該ブラウジング画面からユーザが所望するインターネット・ショッピングサイトを表示させてアクセスすることもできる。

ユーザは、アクセスしたインターネット・ショッピングサイトの商品購入・決済申込み画面まで処理を進めた後、決済申込み画面でワンタイムデビット番号を、所定の入力フィールドにタイピングまたはコピーアンドペーストにより設定する。その後、決済申込み画面上に表示された「ＯＫボタン」をクリックするなどしてsubmitアクションをインターネット・ショッピングサイトに送付する。加盟店ノードは、ウェブ・サーバとして実装されており、決済申込み画面から入力されたワンタイムデビット番号および決済金額を、決済要求通知に含ませ、例えば、VPN(Virtual
Private Network)などで構成された決済ネットワークを通じて銀行サービス・サーバ２１０に送付する。

銀行サービス・サーバ２１０は、当該ワンタイムデビット番号について決済申込がなされたことを通知する決済要求通知を受領すると、決済要求通知を受領した時刻でのワンタイムデビット番号の利用状況、具体的には、利用限度額超過していないか、カード利用停止になっていないかなど、および普通預金口座が引落し禁止や入金禁止になっていないかなどの状況の確認を行なう。銀行サービス・サーバ２１０は、ワンタイムデビット番号の利用状況や普通預金口座番号の状況に問題がないと判断すると、ワンタイムデビット番号を現在登録している普通預金口座から決済、具体的には、普通預金口座からの決済金額の引落し処理を実行する。引落処理が成功した後、銀行サービス・サーバ２１０は、当該ワンタイムデビット番号を図４および図１１の処理によって無効化し、当該決済トランザクションを、加盟店ノードの識別値、ワンタイムデビット番号、決済金額、決済内容などの決済情報を、決済ログDB２７０に登録して一連のキャッシュレス・サービスを終了する。

上述したように、本実施形態のワンタイムデビット・サービスは、物理的にカードを発行することが不要で、かつほぼリアルタイムでの代金決済が可能となるので、銀行ノード、アクワイアラ・ノード、発行者ノードおよび加盟店ノードにおける個人情報の長期管理を不要とする。また、ユーザにおいても煩雑な物理的カードの取得が不要となり、また使いすぎが防止できるなど、利用性および個人情報漏洩リスクの増大を防止することができる。

図１７は、本実施形態のワンタイムデビット・サービスにより発行されるワンタイムデビット番号、すなわち、決済承認番号の数を、時系列的にシミュレーションした結果を示す。シミュレーションにあたっては、下記の仮定を行った。
（１）ワンタイムデビット・サービスに加入するユーザ数は、１万人／月である。
（２）新規登録ユーザのうち、１月以内にワンタイムデビット・サービスを利用するユーザの期待値は、５０％である。
（３）新規登録ユーザのうち、２月以内にワンタイムデビット・サービスを利用するユーザの期待値は、４０％である。
（４）新規登録ユーザのうち、有効期間（５年）の間に利用しないユーザの期待値は、１０％である。
（５）決済承認番号を複数発行する場合には、全ユーザに対して同一の４番号を発行するものとし対外は、上記（１）〜（４）の条件と同一とした。

上記仮定の下で、発行しなければならない決済承認番号、図１７に示したシミュレーションでは、本実施形態のワンタイムデビット・サービスと、有効期間中生存する従来のサービスとに関し、デビット番号発行数を、サービス提供期間（月数）についてプロットして示す。図１７中、ラインＡが従来の有効期間中生存するサービスのデビット番号割当数の月次増加を示し、ラインＢが、１ユーザあたり１番号を割当てる場合のデビット番号割当数の月次増加を示し、ラインCは、１ユーザあたり４番号を割当てる場合のデビット番号割当数の月次増加を示す。なお、１ユーザあたり４番号を割当てる場合、デビット番号の割当数は、利用期待値に影響を与えないものと仮定した。

図１７に示されるように、従来のサービスでは、ラインＡで示すように、ユーザ登録数が増加すればするだけ、ユーザ登録数に正比例してデビット番号割当数が増加しているのが示されている（１０ヶ月で、１０万デビット番号）。

一方、本実施形態のワンタイムデビット・サービスでは、デビット番号割当数は、総ユーザ数の増加に対してはるかに低く抑制され、サービス開始後６０ヶ月経過した時点では、ユーザ数は、累積で６０万人であるところ、専有されるワンタイムデビット・カード番号は、総登録ユーザ数の約１／６弱という結果が得られている。そして、ラインCに示すように１ユーザに対して４番号を割当てる場合、初期には、従来サービスよりも発行数は増えるものの、サービス期間およびユーザ数の増加に応じて従来のサービスよりもデビット番号割当総数は、低く抑制できることが示される。

すなわち、本発明によれば、同数の総ユーザ数であても管理しなければならないワンタイムデビット・サービスに利用する決済承認番号の総発行数が抑制でき、管理しなければならない決済承認番号の総数が削減できることから、不正使用などの可能性を低減でき、また銀行ノード、アクワイアラ・ノード、発行者ノードにおける既発行の決済承認番号の管理および情報処理装置に対する負荷も軽減できキャッシュレス・サービスの利用性をより効率化できる。

本実施形態の上記機能は、C++、Java（登録商標）、JavaBeans（登録商標）、JavaApplet（登録商標）、JavaScript（登録商標）、Perl、Rubyなどのオブジェクト指向プログラミング言語などで記述された装置実行可能なプログラムにより実現でき、プログラムは、ハードディスク装置、CD-ROM、MO、フレキシブルディスク、EEPROM、EPROMなどの装置可読な記録媒体に格納して頒布することができ、また他装置が可能な形式でネットワークを介して伝送することができる。

これまで本実施形態につき説明してきたが、本発明は、上述した実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

１００…トランザクション・フロー
２００…カードレス決済システム
２１０…銀行サービス・サーバ
２２０…ユーザ・ノード
２３０…ゲートウェイ処理部
２３２…ログイン認証部
２４０…ユーザ認証部
２３４…決済承認番号生成部
２４２…部分情報取得部
２５０…部分情報DB
２３８…ユーザ通知部
２３６…決済要求処理部
２４４…DBアクセス部
２４６…乱数発生部
２６０…ユーザDB
２７０…決済ログDB
２８０…決済サーバ
２８０ａ…決済管理DB
２９０…ネットワーク

Claims (15)

1. ネットワークを介して電子商取引における代金決済を物理的カードを発行することなく実行する情報処理装置であって、前記情報処理装置は、
   前記情報処理装置に対し前記ネットワークを介してアクセスするユーザのログイン認証を行うログイン認証部と、
   前記ログイン認証が成功したユーザについてユーザ認証を実行するユーザ認証部と、
   前記ユーザ認証に成功したユーザが前記電子商取引での代金決済を前記情報処理装置が行うために利用する決済承認番号を生成するための数字列からなる部分情報を部分情報データベースからランダムに採番する部分情報取得部と、
   前記部分情報取得部が取得した前記部分情報と、代金決済のための制御情報を結合して前記ユーザ認証に成功したユーザに固有であり、ユーザの使用によっては無効化されずに一定期間生存し、前記ユーザの口座番号からの引落としの成功により無効化される前記決済承認番号を生成する決済承認番号生成部と、
   前記ネットワークを介して決済の要求を受領して前記決済の要求が含む前記決済承認番号の有効性を判断し、前記決済承認番号が有効の場合に前記決済の要求に指定された金額について、前記ユーザの口座番号から引落しを指令すると共に、引落としの成功に応答して前記ユーザの前記決済承認番号を無効化する決済要求処理部と
   を含む、情報処理装置。
2. 前記部分情報取得部は、乱数発生部を含み、前記乱数発生部が生成した乱数列を、前記部分情報データベースから検索して既リースでない部分情報を前記部分情報データベースから取得する、請求項１に記載の情報処理装置。
3. 前記情報処理装置は、さらに前記口座番号を有するユーザを管理するユーザ・データベースを含み、前記ユーザ・データベースは、前記ユーザについて発行された前記決済承認番号を前記ユーザに対応付けて登録する、請求項１または２に記載の情報処理装置。
4. 前記情報処理装置は、前記決済の要求に関連する代金決済の履歴を記録する決済ログ・データベースを含み、前記決済の成功に応答して、前記決済承認番号を、前記ユーザ・データベースから前記決済ログ・データベースに移動させることにより無効化する、請求項３に記載の情報処理装置。
5. 前記情報処理装置は、銀行口座を管理する銀行が設置する銀行サービス・サーバであり、前記決済承認番号は、デビット・サービスについての代金決済の承認を与える、請求項１〜４のいずれか１項に記載の情報処理装置。
6. ネットワークを介して電子商取引における代金決済を物理的カードを発行することなく実行するカードレス決済システムであって、情報処理装置であって、前記カードレス決済システムは、
   前記ネットワークに接続されたユーザ・ノードと、
   前記ネットワークに接続され、前記ユーザ・ノードとの間で相互通信可能な銀行サービス・サーバとを含み、前記銀行サービス・サーバは、
   前記情報処理装置に対し前記ネットワークを介してアクセスする前記ユーザ・ノードから送付されるアクセス要求についてログイン認証を行うログイン認証部と、
   前記ログイン認証が成功した場合、前記ユーザ・ノードから送付された前記アクセス要求についてユーザ認証を実行するユーザ認証部と、
   前記ユーザ認証に成功した場合、前記ユーザ・ノードが前記電子商取引での代金決済を前記情報処理装置により行うために利用する決済承認番号を生成するための数字列からなる部分情報を、部分情報データベースからランダムに採番する部分情報取得部と、
   前記部分情報取得部が取得した前記部分情報と、代金決済のための制御情報を結合して前記カードレス決済システム上で固有であり、ユーザの使用によっては無効化されずに一定期間生存し、前記ユーザの口座番号からの引落としの成功により無効化される前記決済承認番号を生成する決済承認番号生成部と、
   前記ネットワークを介して決済の要求を受領して前記決済の要求が含む前記決済承認番号の有効性を判断し、前記決済承認番号が有効の場合に前記決済の要求に指定された金額について、前記ユーザの口座番号から引落しを指令すると共に、引落としの成功に応答して前記ユーザ・ノードの前記決済承認番号を無効化する決済要求処理部と
   を含む、カードレス決済システム。
7. 前記部分情報取得部は、乱数発生部を含み、前記乱数発生部が生成した乱数列を、前記部分情報データベースから検索して既リースでない部分情報を前記部分情報データベースから取得する、請求項６に記載のカードレス決済システム。
8. 前記情報処理装置は、
   前記口座番号を有するユーザを管理するユーザ・データベースを含み、前記ユーザ・データベースと、
   前記ユーザについて発行された前記決済承認番号を前記ユーザに対応付けて登録する、前記決済の要求に関連する代金決済の履歴を記録する決済ログ・データベースと
   を含み、前記決済の成功に応答して、前記決済承認番号を、前記ユーザ・データベースから前記決済ログ・データベースに移動させることにより無効化する、請求項６または７に記載のカードレス決済システム。
9. 前記銀行サービス・サーバは、銀行口座を提供する銀行が管理し、前記決済承認番号は、デビット・サービスについての代金決済の承認を与える、請求項６〜８のいずれか１項に記載のカードレス決済システム。
10. ネットワークを介して電子商取引における代金決済を物理的カードを発行することなく実行する情報処理装置が実行するカードレス決済方法であって、前記情報処理装置が、
    前記情報処理装置に対し前記ネットワークを介してアクセスするユーザのログイン認証を行うステップと、
    前記ログイン認証が成功したユーザについてユーザ認証するステップと、
    前記ユーザ認証に成功したユーザが前記電子商取引での代金決済を前記情報処理装置により行うために利用する決済承認番号を生成するための数字列からなる部分情報を部分情報データベースからランダムに採番するステップと、
    前記部分情報と、代金決済のための制御情報を結合して前記ユーザ認証に成功したユーザに固有であり、ユーザの使用によっては無効化されずに一定期間生存し、前記ユーザの口座番号からの引落としの成功により無効化される前記決済承認番号を生成するステップと、
    前記ネットワークを介して決済の要求を受領して前記決済の要求が含む前記決済承認番号の有効性を判断し、前記決済承認番号が有効の場合に前記決済の要求に指定された金額について、前記ユーザの口座番号から引落しを指令すると共に、引落としの成功に応答して前記ユーザの前記決済承認番号を無効化するステップと
    を実行するカードレス決済方法。
11. 前記ランダムに採番するステップは、乱数列を生成し、生成した乱数列で前記部分情報データベースを照会して既リースでない部分情報を前記部分情報データベースから取得するステップを含む、請求項１０に記載のカードレス決済方法。
12. 前記決済承認番号を生成するステップは、前記口座番号を有するユーザを管理するユーザ・データベースに前記ユーザについて発行された前記決済承認番号を前記ユーザに対応付けて登録する、請求項１０または１１に記載のカードレス決済方法。
13. 前記決済承認番号を無効化するステップは、前記決済の要求に関連する代金決済の履歴を記録する決済ログ・データベースに、前記決済の成功に応答して前記決済承認番号を、前記ユーザ・データベースから前記決済ログ・データベースに移動させるステップを含み、前記情報処理装置は、銀行口座を管理する銀行が設置する銀行サービス・サーバであり、前記決済承認番号は、デビット・サービスについての代金決済の承認を与える、請求項１２に記載のカードレス決済方法。
14. ネットワークを介したキャッシュレス決済方法であって、前記キャッシュレス決済方法は、銀行サービス・サーバが、
    ネットワークに接続されたユーザ・ノードから電子商取引での代金決済を銀行サービス・サーバにより銀行口座から即時決済するためのワンタイムデビット番号を発行する要求を受領するステップと、
    前記要求の受領に応答して、ログイン認証およびワンタイム・パスワードを利用したユーザ認証を実行するステップと、
    前記ユーザ認証の成功後、前記ユーザ認証に成功したユーザが前記ワンタイムデビット番号を生成するための部分情報を部分情報データベースからランダムに採番し、代金決済のための制御情報を結合して前記ユーザに固有でありユーザの使用によっては無効化されずに一定期間生存し、前記ユーザの口座番号からの引落としの成功により無効化される前記ワンタイムデビット番号を生成するステップと、
    前記ユーザ・ノードにより加盟店ノードがネットワーク上に開設するインターネット・ショッピングサイトに対して通知された前記ワンタイムデビット番号および決済金額を含む決済の要求を受領するステップと、
    前記決済の要求が含む前記ワンタイムデビット番号について前記決済の要求を受領した時刻でのワンタイムデビット番号の利用状況および銀行口座の状況を検査し、当該検査の結果前記利用状況および前記銀行口座の状況が決済可能であると判断した場合、前記ワンタイムデビット番号を現在登録している銀行口座から前記決済金額の引落しを実行することにより代金決済を実行させるステップと、
    前記決済の成功に応答してユーザ・データベースに登録された前記ワンタイムデビット番号を削除して無効化するステップと、
    当該決済トランザクションを、前記加盟店ノードの識別値、削除した前記ワンタイムデビット番号、決済金額と共に決済情報として決済ログ・データベースに登録するステップと
    を実行する、キャッシュレス決済方法。
15. 情報処理装置を、請求項１〜５のいずれか１項に記載の機能手段として機能させるためのコンピュータ実行可能なプログラム。