JP2017156859A - 情報処理システム、サーバ装置、情報処理方法、及び情報処理プログラム - Google Patents

Abstract

【課題】より実質的なユーザの支払能力に応じた信用承認を行うことが可能な情報処理システム、サーバ装置、情報処理方法、及び情報処理プログラムを提供する。【解決手段】ウォレットサーバは、取引対象に対する決済を求めるユーザが利用可能な複数の決済方法のそれぞれの情報を取得し、当該複数の決済方法のそれぞれの情報に基づいて仮決済で許容する信用承認額を算出し、当該信用承認額と当該取引対象の支払金額とに基づいて当該ユーザに対して仮決済を許可するかを決定する。【選択図】図１１

Description

本発明は、取引対象に対する決済を求めるユーザが利用可能な決済方法の情報に基づいて信用承認を行うシステム等の技術分野に関する。

従来から、取引対象の支払金額（支払代金）を決済するための決済方法として、例えばクレジットカードを用いたクレジット決済（後払い式の決済）、貨幣価値を有する電子バリューを用いた電子マネー決済（前払い式の決済）、所定の換算率で支払いに利用可能なポイントを用いたポイント決済、デビットカードを用いた即時引落決済（銀行口座からの即時引落決済）などが知られている。取引対象に対する決済を求めるユーザが複数の決済方法を利用できる場合、当該ユーザにより任意に指定された決済方法により当該取引対象の支払金額が決済される。これらの決済方法のうち、クレジット決済では、ユーザは予め設定された与信限度額（与信枠）内で取引対象の支払金額を決済を行うことができる。一方、特許文献１には、ユーザが選択した明細データを当該ユーザにより指定された決済方法により即時に決済し、当該決済に係る合計額を利用可能額に追加するように構成することで、与信限度額を増額せずに、一定期間内で定められた与信限度額を超えるクレジットカードの利用を可能にしたシステムが提案されている。

特許５４００２１９号

ところで、例えば店舗と間で取引を行うユーザがクレジット決済を利用する場合、店舗に設置された与信照会端末により、取引対象の支払金額が与信限度額を超えないかどうかなどの与信照会が行われる。このため、例えば、ユーザの与信限度額が１０万円である場合において、当該ユーザが１１万円（支払金額）の取引を行うために与信照会が行われても信用承認されず、ユーザは当該取引を行うことができない。このことは特許文献１の技術でも同様である。

しかしながら、ユーザが上記クレジット決済の他にも、例えば電子マネー決済及び即時引落決済を利用でき、電子マネーの残高が２万円、銀行口座の残高が２０万円である場合、当該ユーザは全体として１１万円の取引についての充分な支払能力を持っていると考えられる。このような場合に取引を認めないのは、ユーザにとっては不便であり、店舗にとっては販売機会の損失となる。

そこで、本発明は、上記点等に鑑みてなされたものであり、より実質的なユーザの支払能力に応じた信用承認を行うことが可能な情報処理システム、サーバ装置、情報処理方法、及び情報処理プログラムを提供することを課題とする。

上記課題を解決するために、請求項１に記載の発明は、取引対象に対する決済を求めるユーザの識別情報を取得する第１取得手段と、前記ユーザが利用可能な複数の決済方法であって前記識別情報に対応付けられている前記複数の決済方法のそれぞれの情報を取得する第２取得手段と、前記複数の決済方法のそれぞれの情報に基づいて、前記複数の決済方法のうち少なくとも１つの決済方法による実決済の前段階で暫定的に行われる仮決済で許容する信用承認額を算出する算出手段と、前記信用承認額と前記取引対象の支払金額とに基づいて、前記ユーザに対して前記仮決済を許可するかを決定する決定手段と、を備えることを特徴とする。

この発明によれば、複数の決済方法のそれぞれの情報に基づいて算出した信用承認額を用いて仮決済を許可するかを決定するので、より実質的なユーザの支払能力に応じた信用承認を行うことができる。

請求項２に記載の発明は、請求項１に記載の情報処理システムにおいて、前記算出手段は、前記決済方法の情報に含まれる前記決済方法の利用履歴及び利用可能額に基づいて前記利用可能額から利用せずに残すべき金額を差し引いた残金額を算出し、当該残金額を用いて前記信用承認額を算出することを特徴とする。

この発明によれば、将来的に利用される可能性のある金額を除外して信用承認額を算出するので、より精度の高い適切な信用承認額を算出することができる。

請求項３に記載の発明は、請求項１に記載の情報処理システムにおいて、前記算出手段は、前記複数の決済方法のそれぞれの情報から、前記決済方法全体の過去所定期間における利用可能額の推移を特定し、当該決済方法全体の利用可能額の推移に基づいて、前記信用承認額を算出することを特徴とする。

この発明によれば、ユーザにより利用可能な決済方法全体の過去所定期間における利用可能額の推移に基づいて信用承認額を算出するので、より精度の高い適切な信用承認額を算出することができる。

請求項４に記載の発明は、請求項１乃至３の何れか一項に記載の情報処理システムにおいて、前記算出手段は、前記複数の決済方法のうちから前記実決済に利用する候補として当該ユーザにより選択された複数の決済方法のそれぞれの情報に基づいて、前記信用承認額を算出することを特徴とする。

この発明によれば、ユーザの意向に沿った信用承認額を算出することができる。

請求項５に記載の発明は、請求項１乃至４の何れか一項に記載の情報処理システムにおいて、前記仮決済される前記支払金額を、前記複数の決済方法のうち少なくとも１つの決済方法に割り振る割振手段を更に備えることを特徴とする。

この発明によれば、ユーザに負担をかけずに割り振りを行うことができる。

請求項６に記載の発明は、請求項５に記載の情報処理システムにおいて、前記割振手段は、前記仮決済される前記支払金額を、前記複数の決済方法のうち前記ユーザにより予め指定された優先順位に応じて割り振ることを特徴とする。

この発明によれば、ユーザに負担をかけずに、ユーザの意向に沿った割り振りを行うことができる。

請求項７に記載の発明は、請求項５または６に記載の情報処理システムにおいて、前記割振手段は、前記仮決済される前記支払金額を分割して前記複数の決済方法に割り振ることを特徴とする。

この発明によれば、ユーザに負担をかけずに、複数の決済方法に分散させて割り振りを行うことができる。

請求項８に記載の発明は、請求項５または６に記載の情報処理システムにおいて、前記割振手段は、前記仮決済される前記支払金額を、前記複数の決済方法のうちから前記実決済に利用する候補として前記ユーザにより選択された複数の決済方法の一部または全部に割り振ることを特徴とする。

この発明によれば、ユーザに負担をかけずに、ユーザの意向に沿った割り振りを行うことができる。

請求項９に記載の発明は、請求項７に記載の情報処理システムにおいて、前記割振手段は、前記分割される前記支払金額が、前記決済方法の情報に含まれる前記決済方法の利用可能額から利用せずに残すべき金額を差し引いた残金額以下になるように割り振ることを特徴とする。

この発明によれば、より精度の高い（信頼性の高い）割り振りを行うことができる。

請求項１０に記載の発明は、請求項１乃至８の何れか一項に記載の情報処理システムにおいて、前記決定手段により前記仮決済を許可することが決定された場合、前記支払金額を仮決済する仮決済手段と、前記仮決済された前記支払金額が割り振られた前記決済方法の利用可能額のうち当該割り振られた分の金額の利用をロックするロック手段と、前記仮決済された前記支払金額を、前記割り振られた前記決済方法により実決済する実決済手段と、前記実決済された前記支払金額の利用のロックを解除するロック解除手段と、を備えることを特徴とする。

この発明によれば、決済方法に割り振られた分の金額が仮決済から実決済までの間に、ユーザにより利用されるのを確実に防止することができる。

請求項１１に記載の発明は、取引対象に対する決済を求めるユーザの識別情報を取得する第１取得手段と、前記ユーザが利用可能な複数の決済方法であって前記識別情報に対応付けられている前記複数の決済方法のそれぞれの情報を取得する第２取得手段と、前記複数の決済方法のそれぞれの情報に基づいて、前記複数の決済方法のうち少なくとも１つの決済方法による実決済の前段階で暫定的に行われる仮決済で許容する信用承認額を算出する算出手段と、前記信用承認額と前記取引対象の支払金額とに基づいて、前記ユーザに対して前記仮決済を許可するかを決定する決定手段と、を含むことを特徴とする。

請求項１２に記載の発明は、１つ以上のコンピュータにより実行される情報処理方法であって、取引対象に対する決済を求めるユーザの識別情報を取得する第１取得ステップと、前記ユーザが利用可能な複数の決済方法であって前記識別情報に対応付けられている前記複数の決済方法のそれぞれの情報を取得する第２取得ステップと、前記複数の決済方法のそれぞれの情報に基づいて、前記複数の決済方法のうち少なくとも１つの決済方法による実決済の前段階で暫定的に行われる仮決済で許容する信用承認額を算出する算出ステップと、前記信用承認額と前記取引対象の支払金額とに基づいて、前記ユーザに対して前記仮決済を許可するかを決定する決定ステップと、を含むことを特徴とする。

請求項１３に記載の発明は、コンピュータを、取引対象に対する決済を求めるユーザの識別情報を取得する第１取得手段と、前記ユーザが利用可能な複数の決済方法であって前記識別情報に対応付けられている前記複数の決済方法のそれぞれの情報を取得する第２取得手段と、前記複数の決済方法のそれぞれの情報に基づいて、前記複数の決済方法のうち少なくとも１つの決済方法による実決済の前段階で暫定的に行われる仮決済で許容する信用承認額を算出する算出手段と、前記信用承認額と前記取引対象の支払金額とに基づいて、前記ユーザに対して前記仮決済を許可するかを決定する決定手段として機能させる。

この発明によれば、複数の決済方法のそれぞれの情報に基づいて算出した信用承認額を用いて仮決済を許可するかを決定するので、より実質的なユーザの支払能力に応じた信用承認を行うことができる。

本実施形態に係る電子決済システムＳの概要構成例を示す図である。 ウォレットサーバ８のハードウェア構成例を示す図である。 （Ａ）は、店舗情報データベース８２ａの内容の一例を示す図であり、（Ｂ）は、ユーザ情報データベース８２ｂの内容の一例を示す図である。 決済方法情報データベース８２ｃの内容の一例を示す図である。 電子決済システムＳの各構成要素の繋がりと、ウォレットサーバ８のシステム制御部８３の機能ブロックとを示す図である。 信用承認額の算出例を示す図である。 ユーザが利用可能な複数の決済方法全体の過去所定期間における利用可能額の推移に基づいて信用承認額を算出する例を示す概念図である。 支払金額の割振例を示す図である。 割振の可否及び優先順位設定時におけるユーザ端末１及びウォレットサーバ８の処理例を示すシーケンス図である。 ユーザ端末１における割振可否設定画面の表示例を示す図である。 仮決済時におけるユーザ端末１、店舗端末２、及びウォレットサーバ８の処理例を示すシーケンス図である。 支払金額割振時におけるウォレットサーバ８、及び管理サーバ４〜７の処理例を示すシーケンス図である。 実決済時におけるウォレットサーバ８、及び管理サーバ４〜７の処理例を示すシーケンス図である。

以下、図面を参照して本発明の実施形態について説明する。なお、以下に説明する実施の形態は、電子決済システムに対して本発明を適用した場合の実施形態である。

［１．電子決済システムの構成及び機能概要］
先ず、図１等を参照して、本実施形態に係る電子決済システムＳの構成及び概要機能について説明する。図１は、本実施形態に係る電子決済システムＳの概要構成例を示す図である。図１に示すように、電子決済システムＳは、ユーザ端末１、店舗端末２、第１電子マネー管理サーバ３、第２電子マネー管理サーバ４、クレジットカード管理サーバ５、ポイント管理サーバ６、口座管理サーバ７、及びウォレットサーバ８等を含んで構成される。第１電子マネー管理サーバ３、第２電子マネー管理サーバ４、クレジットカード管理サーバ５、ポイント管理サーバ６、口座管理サーバ７、及びウォレットサーバ８は、それぞれ、ネットワークＮＷに接続されている。ネットワークＮＷは、例えば、インターネット、移動体通信網（基地局等を含む）、及びゲートウェイ等により構築される。なお、クレジットカード管理サーバ５、口座管理サーバ７、及びウォレットサーバ８は、例えば専用回線を介して、金融機関（例えば銀行、信用金庫、信用組合、労働金庫等）により運営される金融機関システム９に接続可能になっている。金融機関システム９は、多数の口座を有し、クレジットカード管理サーバ５、口座管理サーバ７、またはウォレットサーバ８からの要求によって、口座間の資金移動が行うことが可能なコンピュータシステムである。

ユーザ端末１は、制御部１１、記憶部１２、操作・表示部１３、ＨＴＴＰ（Hypertext Transfer Protocol）等に基づく通信機能を有する通信部１４、及び近距離無線通信（例えばＮＦＣ（Near field radio communication）、ＢＬＥ（Bluetooth Low Energy）、ＩｒＤＡ（Infrared Data Association）などの規格に準拠した通信）機能を有する近距離無線通信部１５等を含んで構成される。なお、ユーザ端末１には、スマートフォン、携帯電話機、タブレット端末、ＰＤＡ（Personal Digital Assistant）、または携帯ゲーム機などの携帯端末が適用されるとよい。制御部１１は、ＣＰＵ（Central Processing Unit），ＲＯＭ（Read Only Memory），及びＲＡＭ（Random Access Memory）等を備える。

記憶部１２は、ＯＳ（Operating System），アプリケーションプログラム，及びＷｅｂブラウザプログラム等を記憶する。ユーザ端末１にインストールされるアプリケーションプログラムには、取引対象（商品またはサービス）に対する決済を求めるユーザが利用可能な複数の決済方法のうち少なくとも１つの決済方法による決済（これを、「実決済」という）の前段階で暫定的（一時的）に行われる仮の決済（これを、「仮決済」という）を要求することが可能なユーザ側仮決済用プログラムが含まれる。このような決済方法の例として、電子マネー決済、クレジット決済、ポイント決済、及び即時引落決済が挙げられる。また、記憶部１２には、ユーザ端末１のユーザのユーザＩＤ（ユーザの識別情報）が記憶されている。このユーザＩＤは、例えばユーザ側仮決済用プログラムがユーザ端末１にインストールされたときに表示される設定画面から入力される。なお、本実施形態では、ユーザ端末１、第１電子マネー管理サーバ３、第２電子マネー管理サーバ４、クレジットカード管理サーバ５、ポイント管理サーバ６、口座管理サーバ７、及びウォレットサーバ８で管理されるユーザＩＤは、同じユーザについて同一であるものとするが、同じユーザについて各サーバ間で異なるユーザＩＤが管理されてもよく、この場合、例えばウォレットサーバ８で同じユーザの複数のユーザＩＤが互いに対応付けられて管理される。操作・表示部１３は、例えば、ユーザの指やペン等による操作を受け付ける入力機能と、情報を表示する表示機能を有するタッチパネルを備える。

制御部１１は、ＯＳ上でユーザ側仮決済用プログラムを実行することにより、後述するように、取引対象に対する仮決済をウォレットサーバ８へ要求するための処理等を実行する。なお、ユーザ側仮決済用プログラムは、所定のサーバからユーザ端末１にダウンロードされてもよいし、ＣＤ、ＤＶＤなどの記録媒体に記録（コンピュータにより読み取り可能に記録）されており、当該記録媒体から読み込まれて記憶部１２に記憶されるようにしてもよい。また、制御部１１は、通信部１４によりネットワークＮＷを介して所定のＷｅｂサーバ（図示せず）、第１電子マネー管理サーバ３、第２電子マネー管理サーバ４、クレジットカード管理サーバ５、ポイント管理サーバ６、口座管理サーバ７、及びウォレットサーバ８等との間で通信を行うことが可能になっている。また、制御部１１は、近距離無線通信部１５により店舗端末２との間で近距離無線通信を行うことが可能になっている。

店舗端末２は、制御部２１、記憶部２２、操作・表示部２３、ＨＴＴＰ等に基づく通信機能を有する通信部２４、近距離無線通信機能（例えばＮＦＣ、ＢＬＥ、ＩｒＤＡなどの規格に準拠した通信）を有する近距離無線通信部２５、及び外部のリーダライタＲＷとのインターフェースを担うＩ／Ｆ２６等を含んで構成される。なお、店舗端末２には、ＣＡＴ（Credit Authorization Terminal）機能を備えるＰＯＳ（Point of sale）端末が適用されるとよい。制御部２１は、ＣＰＵ，ＲＯＭ，及びＲＡＭ等を備える。記憶部２２は、ＯＳ，アプリケーションプログラム，及びＷｅｂブラウザプログラム等を記憶する。店舗端末２にインストールされるアプリケーションプログラムには、上述した仮決済を要求することが可能な店舗側仮決済用プログラムと、通常の決済用プログラムとが含まれる。また、記憶部２２には、店舗端末２が設置される店舗の店舗ＩＤ（店舗の識別情報）が記憶されている。この店舗ＩＤは、例えば店舗側仮決済用プログラムが店舗端末２にインストールされたときに表示される設定画面から入力される。操作・表示部２３は、例えば、店舗の店員の指やペン等による操作を受け付ける入力機能と、情報を表示する表示機能を有するタッチパネルを備える。

制御部２１は、ＯＳ上で店舗側仮決済用プログラムを実行することにより、後述するように、取引対象に対する仮決済をウォレットサーバ８へ要求するための処理等を実行する。なお、店舗側仮決済用プログラムは、所定のサーバから店舗端末２にダウンロードされてもよいし、ＣＤ、ＤＶＤなどの記録媒体に記録（コンピュータにより読み取り可能に記録）されており、当該記録媒体から読み込まれて記憶部２２に記憶されるようにしてもよい。また、制御部２１は、通信部２４によりネットワークＮＷを介して第１電子マネー管理サーバ３、第２電子マネー管理サーバ４、クレジットカード管理サーバ５、ポイント管理サーバ６、口座管理サーバ７、及びウォレットサーバ８等との間で通信を行うことが可能になっている。また、制御部２１は、近距離無線通信部２５によりユーザ端末１との間で近距離無線通信を行うことが可能になっている。また、制御部２１は、Ｉ／Ｆ２６によりリーダライタＲＷと通信を行うことが可能になっており、ＯＳ上で通常の決済用プログラムを実行することにより、ユーザが所有する決済用のカード（例えば国際標準規格等で寸法が定められた平板状のカードである）からリーダライタＲＷにより読み取られた情報を取得し、取得した情報に基づいて、通常の決済（電子マネー決済、クレジット決済、ポイント決済、または即時引落決済）を行うことができる。決済用のカードの例として、電子マネーカード、クレジットカード、ポイントカード、デビットカードなどがある。

ここで、電子マネーカードは、例えば非接触型ＩＣチップ（ＩＣモジュール）を備えており、当該ＩＣチップの不揮発性メモリには、貨幣価値に対応させた電子バリューの残高、電子マネー番号、及びログデータ等の情報が記憶されている。この電子バリューは、ストアドバリュー型前払い式の電子マネー（以下、「ストアド型電子マネー」という）である。電子マネー番号は、電子マネーカード毎に固有の番号であり、これにより、電子マネーカードの発行対象者であるユーザを特定することができる。電子バリューの残高及び電子マネー番号等の情報は、電子マネーカードの非接触型ＩＣチップから店舗端末２のリーダライタＲＷにより読み取られ、電子マネー決済（以下、「ストアド型電子マネー決済」という）に用いられる。ログデータの例として、利用履歴データ、及びチャージ履歴データがある。利用履歴データは、電子バリューが決済（支払い）に利用された履歴を示すデータであり、ストアド型電子マネー決済時に店舗端末２により生成される。利用履歴データには、例えば利用日（ストアド型電子マネー決済による決済日であり、例えば、年月日の他、時刻を含んでもよい、以下同様）、利用店舗名、及び利用額等の情報が含まれる。チャージ履歴データは、電子バリューがチャージ（つまり、電子バリューの残高が増額）された履歴を示すデータであり、電子バリューのチャージ時に店舗端末２により生成される。チャージ履歴データには、例えばチャージ日、及びチャージ額等の情報が含まれる。なお、ストアド型電子マネーを管理するアプリケーションプログラムが、ユーザ端末１にインストールされてもよい。この場合、ユーザ端末１に搭載される非接触型ＩＣチップの不揮発性メモリには、電子バリューの残高等の情報が店舗端末２のリーダライタＲＷにより読み取り可能に記憶される。また、電子マネーカードは、後述するサーバ型前払い式の電子マネー（以下、「サーバ型電子マネー」という）の電子マネー番号等の情報を記憶するものであってもよい。この場合、サーバ型電子マネーの電子バリューの残高は、第２電子マネー管理サーバ４で管理される。

クレジットカードは、例えば非接触型ＩＣチップを備えており、当該ＩＣチップの不揮発性メモリには、クレジットカード番号、クレジットカードの発行対象者であるユーザの氏名、及びクレジットカードの有効期限等の情報が記憶されている。クレジットカード番号は、クレジットカード毎に固有の番号であり、これにより、クレジットカードの発行対象者であるユーザを特定することができる。クレジットカード番号、ユーザの氏名、及びクレジットカードの有効期限等の情報は、クレジットカードの非接触型ＩＣチップから店舗端末２のリーダライタＲＷにより読み取られ、クレジット決済に用いられる。なお、電子マネーカードとクレジットカードとは一体型の共用カードであってもよい。この場合、共用カードの非接触型ＩＣチップの不揮発性メモリには、電子バリューの残高等の情報と、クレジットカード番号等の情報とが店舗端末２のリーダライタＲＷにより読み取り可能に記憶される。なお、クレジットカードは、店舗端末２で通常の決済に利用される他にも、所定のＷｅｂサイト（例えばショッピングモールサイト）でのクレジット決済にも用いられる。或いは、クレジットカードは、定期的な支払いが生じる取引対象の支払金額（例えば、ガス代、水道代、その他の公共料金、家賃、保険料、携帯キャリア利用料金など）のクレジット決済にも用いられる。

ポイントカードには、ポイントカード番号がバーコードまたは２次元コードにより記載されている。ポイントカード番号は、ポイントカード毎に固有の番号であり、これにより、ポイントカードの発行対象者であるユーザを特定することができる。ポイントカード番号は、バーコードまたは２次元コードから店舗端末２のリーダライタＲＷにより読み取られ、ポイント決済に用いられる。なお、電子マネーカード（またはクレジットカード）とポイントカードとは一体型の共用カードであってもよい。この場合、共用カードの非接触型ＩＣチップの不揮発性メモリには、電子バリューの残高等の情報（またはクレジットカード番号等の情報）と、ポイントカード番号とが店舗端末２のリーダライタＲＷにより読み取り可能に記憶される。或いは、ポイントカード番号を管理するアプリケーションプログラムが、ユーザ端末１にインストールされてもよい。この場合、ユーザ端末１に搭載される非接触型ＩＣチップの不揮発性メモリには、ポイントカード番号が店舗端末２のリーダライタＲＷにより読み取り可能に記憶される。或いは、この場合、ユーザの操作に応じて当該ポイントカード番号を有するバーコードまたは２次元コードがユーザ端末１の操作・表示部１３に表示され、当該バーコードまたは２次元コードから当該ポイントカード番号が店舗端末２のリーダライタＲＷにより読み取られてもよい。なお、ポイントカードは、店舗端末２で利用される他にも、所定のＷｅｂサイト（例えばショッピングモールサイト）でのポイント決済にも用いられる。

デビットカードは、例えば非接触型ＩＣチップを備えており、当該ＩＣチップの不揮発性メモリには、デビットカード番号、デビットカードの発行対象者であるユーザの氏名、デビットカードを発行した金融機関を識別する金融機関ＩＤ、及びデビットカードの有効期限等の情報が記憶されている。デビットカード番号は、デビットカード毎に固有の番号であり、これにより、デビットカードの発行対象者であるユーザを特定することができる。デビットカード番号、ユーザの氏名、金融機関コード、及びデビットカードの有効期限等の情報は、デビットカードの非接触型ＩＣチップから店舗端末２のリーダライタＲＷにより読み取られ、即時引落決済（デビット決済）に用いられる。なお、キャッシュカードがデビットカードとして用いられる場合もある。なお、デビットカードは、店舗端末２で利用される他にも、所定のＷｅｂサイト（例えばショッピングモールサイト）においても即時引落決済に用いられる。なお、デビットカードは、店舗端末２で通常の決済に利用される他にも、所定のＷｅｂサイト（例えばショッピングモールサイト）での即時引落決済にも用いられる。或いは、デビットカードは、定期的な支払いが生じる取引対象の支払金額（例えば、ガス代、水道代、家賃、保険料、携帯キャリア利用料金など）の即時引落決済にも用いられる。この場合、例えば月毎に定められた支払金額が毎月の引落日にユーザの口座から自動的に引き落とされる。

第１電子マネー管理サーバ３は、ストアド型電子マネーの情報を管理するサーバである。第１電子マネー管理サーバ３の記憶部には、電子マネー番号、ストアド型電子マネーの電子バリューの残高、ログデータ、及びユーザＩＤ等の情報がユーザ毎に対応付けられて記憶される。上述したように、例えば店舗端末２においてストアド型電子マネー決済が行われた場合、店舗端末２からネットワークＮＷを介して第１電子マネー管理サーバ３へ、上記利用履歴データ、及び電子マネー番号が送信（例えば即時送信、または定期的に送信）され、第１電子マネー管理サーバ３の記憶部に記憶される。このとき、電子バリューの残高が更新される。なお、電子マネーカードの非接触型ＩＣチップに記憶された電子バリューの残高と、この残高と同一の電子マネー番号が対応付けられている残高であって第１電子マネー管理サーバ３の記憶部に記憶されている電子バリューの残高とは、タイムラグにより一致しない場合がある。また、例えば店舗端末２において電子バリューのチャージが行われた場合、店舗端末２からネットワークＮＷを介して第１電子マネー管理サーバ３へ、上記チャージ履歴データ、及び電子マネー番号が送信（例えば即時送信、または定期的に送信）され、第１電子マネー管理サーバ３の記憶部に記憶される。このとき、電子バリューの残高が更新される。

第２電子マネー管理サーバ４は、サーバ型電子マネーの情報を管理するサーバである。サーバ型電子マネーの例として、インターネット上の所定のＷｅｂサイトで利用可能なオンライン電子マネーが挙げられる。第２電子マネー管理サーバ４の記憶部には、サーバ型電子マネーの電子バリューの残高、電子マネー番号、ログデータ、及びユーザＩＤ等の情報がユーザ毎に対応付けられて記憶される。ログデータの例として、上記と同様、利用履歴データ、及びチャージ履歴データがある。さらに、第２電子マネー管理サーバ４の記憶部には、サーバ型電子マネーの電子バリューの残高、及びサーバ型電子マネーの取扱い店舗を識別する店舗ＩＤ等の情報が店舗毎に対応付けられて記憶される。そして、第２電子マネー管理サーバ４は、所定のＷｅｂサイト（例えばショッピングモールサイト）におけるＷｅｂサーバへアクセスしたユーザ端末１からのサーバ型電子マネーによる決済要求（ユーザＩＤ、及び支払金額等を含む）に応じて、当該ユーザＩＤに対応付けられた電子バリューの残高を減らす（つまり、支払金額分だけ減額する）電子マネー決済（以下、「サーバ型電子マネー決済」という）を行う。このとき、第２電子マネー管理サーバ４は、利用履歴データを生成する。

クレジットカード管理サーバ５は、クレジットカードの情報を管理するサーバである。クレジットカード管理サーバ５の記憶部には、クレジットカード番号、クレジットカードの発行対象者であるユーザの氏名、クレジットカードの有効期限、与信限度額（与信枠）、利用可能額、利用履歴データ、ユーザ口座情報、及びユーザＩＤ等の情報がユーザ毎に対応付けられて記憶される。与信限度額は、例えばクレジットカードを利用した買い物やキャッシングの累積に対して許容される上限額である。利用可能額とは、現時点でクレジットカードを利用することができる総額（例えば、与信限度額から当月利用額を減じた額）である。利用履歴データは、クレジットカードが決済に利用された履歴を示すデータであり、クレジット決済による決済日に例えばクレジットカード管理サーバ５により生成される。この利用履歴データには、例えば利用日、利用店舗名、及び利用額等の情報が含まれる。この利用日は、例えば、クレジット決済による決済日である。ユーザ口座情報には、クレジット決済に係る支払金額が引き落とされる引落口座（ユーザの口座）の口座番号、引落日、及び当該口座を管理する金融機関を識別する金融機関ＩＤ等が含まれる。

さらに、クレジットカード管理サーバ５の記憶部には、クレジットカードの取扱い店舗（加盟店）を識別する店舗ＩＤ、及び店舗口座情報等の情報が店舗毎に対応付けられて記憶される。店舗口座情報には、クレジット決済に係る支払金額が振り込まれる口座（店舗の口座）の口座番号、及び当該口座を管理する金融機関を識別する金融機関ＩＤ等が含まれる。そして、クレジットカード管理サーバ５は、例えば店舗端末２或いは所定のＷｅｂサイトからの与信照会（クレジットカード番号、有効期限、及び支払金額等を含む）に応じてクレジットカードを用いたクレジット決済が可能であるか否かの与信照会を行い、例えば有効期限が過ぎておらず、且つ取引対象の支払金額が利用可能額を超えていない場合に、与信承認ＯＫメッセージを店舗端末２へ返信する。なお、クレジットカードによる与信承認は、本発明において信用承認とは同じでなく区別されるものである。そして、与信承認ＯＫメッセージが受信された場合、クレジット決済が行われる。すなわち、店舗端末２により売上が計上され、当該取引対象の支払金額を請求する請求データ（店舗ＩＤ及び支払金額を含む）がクレジットカード管理サーバ５へ送信され、さらに、クレジットカード管理サーバ５から金融機関システム９へ資金移動要求が送信される。これにより、当該取引対象の支払金額が立替払取次業者（例えば、クレジットカード会社）の口座（口座の残高）から引き落とされてユーザと取引を行った店舗の口座に振り込まれる。その後、当該取引対象の支払金額及び手数料が当該ユーザの口座から引き落とされる。

ポイント管理サーバ６は、所定の換算率で支払いに利用可能なポイントの情報を管理するサーバである。ポイント管理サーバ６の記憶部には、ポイントカード番号、残りポイント数（残高）、ログデータ、及びユーザＩＤ等の情報がユーザ毎に対応付けられて記憶される。このログデータの例として、利用履歴データ、及び獲得履歴データがある。利用履歴データは、ポイントが決済に利用された履歴を示すデータであり、例えばポイント決済時にポイント管理サーバ６により生成される。利用履歴データには、例えば利用日、利用店舗名、及び利用ポイント数等の情報が含まれる。獲得履歴データは、ポイントが獲得（例えば、商品購入、アンケート回答、或いはキャンペーン応募により残りポイント数が増加）された履歴を示すデータであり、ポイントの獲得時に例えばポイント管理サーバ６により生成される。獲得履歴データには、例えば獲得日、及び獲得ポイント数等の情報が含まれる。

さらに、ポイント管理サーバ６の記憶部には、残りポイント数、及びポイントの取扱い店舗を識別する店舗ＩＤ等の情報が店舗毎に対応付けられて記憶される。そして、ポイント管理サーバ６は、例えば店舗端末２または所定のＷｅｂサイトからのポイントによる決済要求（ポイントカード番号、及び支払金額等を含む）に応じて、当該ポイントカード番号に対応付けられた残りポイント数を減らす（つまり、支払金額を所定の換算率で換算したポイント分だけ減らす）ポイント決済を行う。このとき、ポイント管理サーバ６は、利用履歴データを生成する。

口座管理サーバ７は、口座の情報を管理するサーバである。口座管理サーバ７の記憶部には、デビットカード番号、デビットカードの発行対象者であるユーザの氏名、デビットカードの有効期限、ログデータ、ユーザ口座情報、及びユーザＩＤ等の情報がユーザ毎に対応付けられて記憶される。ログデータの例として、利用履歴データ、及び振込履歴データがある。利用履歴データは、デビットカードが決済に利用された履歴を示すデータであり、例えば即時引落決済時に口座管理サーバ７により生成される。この利用履歴データには、例えば利用日、利用店舗名、及び利用額等の情報が含まれる。振込履歴データは、デビット決済に利用される口座（ユーザの口座）に振込された履歴を示すデータであり、例えば振込時に口座管理サーバ７により生成される。この振込履歴データには、例えば振込日、及び振込額等の情報が含まれる。なお、ユーザの口座には、例えばユーザの給料など、定期的に振り込まれる場合（自動振込）がある。ユーザ口座情報には、即時引落決済に係る支払金額が引き落とされる口座（ユーザの口座）の口座番号、残高（預金残高）、及び当該口座を管理する金融機関を識別する金融機関ＩＤ等が含まれる。

さらに、口座管理サーバ７の記憶部には、デビットカードの取扱い店舗（加盟店）を識別する店舗ＩＤ、及び店舗口座情報等の情報が店舗毎に対応付けられて記憶される。店舗口座情報には、例えば即時引落決済に係る支払金額が振り込まれる口座（店舗の口座）の口座番号、及び当該口座を管理する金融機関を識別する金融機関ＩＤ等が含まれる。そして、口座管理サーバ７は、例えば店舗端末２または所定のＷｅｂサイトからの即時引落による決済要求（デビットカード番号、及び支払金額等を含む）に応じて、取引対象の支払金額の移動要求（ユーザの口座の口座番号、店舗の口座の口座番号、及び支払金額を含む）を金融機関システム９へ送信する。これにより、当該取引対象の支払金額がユーザの口座（口座の残高）から引き落とされて当該ユーザと取引を行った店舗の口座に振り込まれ、口座管理サーバ７が記憶するユーザ口座情報と店舗口座情報中の残高が更新される。このとき、口座管理サーバ７は、利用履歴データを生成する。なお、口座管理サーバ７は、金融機関システム９の構成要素として組み込まれてもよい。

ウォレットサーバ８は、上述した仮決済及び実決済を行うサーバである。すなわち、ウォレットサーバ８は、取引対象に対する決済を求めるユーザの代わりに当該取引対象の支払金額を一時的に立て替えて店舗へ支払い、その後、仮決済された支払金額を、当該ユーザが利用可能な１または複数の決済方法により実決済する。さらに、ウォレットサーバ８は、各決済方法で利用可能な金額の全部または一部のチャージを受け付け、決済方法毎に区別してチャージ額を管理するウォレット機能を有する。例えば、ウォレットサーバ８は、ユーザの操作により電子マネーカードからユーザ端末１により取得された電子バリューを取得し、当該ユーザ端末１のユーザのユーザＩＤに対応付けて記憶する。なお、サーバ型電子マネー決済、クレジット決済、ポイント決済、及び即時引落決済で利用可能な貨幣価値に対応するチャージ額をウォレット機能により管理することもできる。

図２は、ウォレットサーバ８のハードウェア構成例を示す図である。ウォレットサーバ８は、図２に示すように、通信部８１、記憶部８２、及びシステム制御部８３等を備え、これらの構成要素はシステムバス８４に接続されている。なお、ウォレットサーバ８は、サーバ装置の一例である。通信部８１は、ネットワークＮＷに接続され、通信状態の制御を行う。システム制御部８３は、通信部８１によりネットワークＮＷを介して、ユーザ端末１、店舗端末２、第１電子マネー管理サーバ３、第２電子マネー管理サーバ４、ポイント管理サーバ５、クレジットカード管理サーバ６、及び口座管理サーバ７のそれぞれとの間で通信を行うことが可能になっている。なお、システム制御部８３は、第１電子マネー管理サーバ３、第２電子マネー管理サーバ４、ポイント管理サーバ５、クレジットカード管理サーバ６、及び口座管理サーバ７のそれぞれと専用回線を介して通信してもよい。記憶部８２は、例えば、ハードディスクドライブ等により構成されており、ＯＳ及び決済用プログラム（本発明の情報処理プログラムを含む）等の各種プログラムを記憶する。なお、決済用プログラムは、所定のサーバからウォレットサーバ８にダウンロードされてもよいし、ＣＤ、ＤＶＤなどの記録媒体に記録（コンピュータにより読み取り可能に記録）されており、当該記録媒体から読み込まれて記憶部８２に記憶されるようにしてもよい。

また、記憶部８２には、店舗情報データベース（ＤＢ）８２ａ、ユーザ情報データベース（ＤＢ）８２ｂ、及び決済方法情報データベース（ＤＢ）８２ｃ等が構築される。なお、ウォレットサーバ８以外のサーバに設けられてもよい。図３（Ａ）は、店舗情報データベース８２ａの内容の一例を示す図であり、図３（Ｂ）は、ユーザ情報データベース８２ｂの内容の一例を示す図である。図４は、決済方法情報データベース８２ｃの内容の一例を示す図である。

店舗情報データベース８２ａには、図３（Ａ）に示すように、本電子決済システムＳの利用登録を行った店舗の店舗ＩＤ、パスワード、店舗の名称、店舗の連絡先、及び店舗口座情報等の情報が店舗毎に対応付けられて格納されている。ここで、店舗ＩＤ及びパスワードは、ウォレットサーバ８へのログイン等の認証処理に用いられる。店舗の連絡先には、店舗の住所、電話番号、電子メールアドレス等が含まれる。また、店舗口座情報には、仮決済に係る支払金額が振り込まれる口座（店舗の口座）の口座番号、及び当該口座を管理する金融機関を識別する金融機関ＩＤ等が含まれる。なお、店舗情報データベース８２ａに格納される情報は、例えばそれぞれの店舗の店員の操作に応じてウォレットサーバ８にアクセスした店舗端末２からの設定要求に応じて格納される。

ユーザ情報データベース８２ｂには、図３（Ｂ）に示すように、本電子決済システムＳの利用登録を行ったユーザのユーザＩＤ、パスワード、ユーザの氏名、ユーザの連絡先、ユーザが所有するカードの番号等（クレジットカード番号の場合、ユーザの氏名、及びクレジットカードの有効期限が含まれてもよい）の情報がユーザ毎に対応付けられて格納されている。ここで、ユーザＩＤ及びパスワードは、ウォレットサーバ８へのログイン等の認証処理に用いられる。ユーザの連絡先には、ユーザの住所、電話番号、電子メールアドレス等が含まれる。図３（Ｂ）の例では、ユーザａ（ユーザＩＤ:U0001）は、１つの電子マネーカードと、１つのクレジットカードと、１つのポイントカードと、１つのデビットカードとを所有している。また、ユーザｂ（ユーザＩＤ:U0002）は、２つの電子マネーカードと、１つのクレジットカードと、１つのデビットカードとを所有している。また、ユーザｃ（ユーザＩＤ:U0003）は、１つの電子マネーカードと、１つのデビットカードとを所有している。なお、ユーザ情報データベース８２ｂに格納される情報は、例えばそれぞれのユーザの操作に応じてウォレットサーバ８にアクセスしたユーザ端末１からの設定要求に応じて格納される。

決済方法情報データベース８２ｃには、図４に示すように、本電子決済システムＳの利用登録を行ったユーザのユーザＩＤ、ユーザが利用可能な決済方法（例えば、決済方法を識別する決済種別ＩＤでもよいし、文字列でもよい）、利用可能額、入出金履歴、割振の可否、割振の優先順位、及び利用ロック額等の情報がユーザ毎に対応付けられて格納されている。図４の例では、ユーザＩＤ“U0001”には、ユーザａが利用可能な決済方法として、電子マネー決済、クレジット決済、ポイント決済、及び即時引落決済が対応付けられている。また、ユーザＩＤ“U0002”には、ユーザｂが利用可能な決済方法として、電子マネー決済１（例えば、ストアド型電子マネー決済）、電子マネー決済２（例えば、サーバ型電子マネー決済）、クレジット決済、及び即時引落決済が対応付けられている。また、ユーザＩＤ“U0003”には、ユーザｃが利用可能な決済方法として、電子マネー決済、及び即時引落決済が対応付けられている。

また、図４に示す利用可能額及び入出金履歴は、ユーザが利用可能な決済方法の情報の一例である。電子マネー決済に対応付けられた利用可能額には、電子バリューの残高が該当する。電子マネー決済に対応付けられた入出金履歴中の入出金日には、利用履歴データに含まれる利用日（出金日）と、チャージ履歴データに含まれるチャージ日（入金日）とが該当する。電子マネー決済に対応付けられた入出金履歴中の入出金額には、利用履歴データに含まれる利用額（出金額：図４の例では、−（マイナス）で表す）と、チャージ履歴データに含まれるチャージ額（入金額：図４の例では、＋（プラス）で表す）とが該当する。電子バリューの残高、利用履歴データ、及びチャージ履歴データは、例えばユーザＩＤまたは電子マネーカード番号をキーとして、第１電子マネー管理サーバ３または第２電子マネー管理サーバ４から所定のタイミング（定期的（例えば、１日毎）、或いは後述する信用承認額の算出の際など）で取得され、決済方法情報データベース８２ｃに格納される。

一方、クレジット決済には、利用可能額と共に与信限度額が対応付けられており、利用可能額は、与信限度額から当月利用額を減じた額が該当する。例えばユーザＩＤ“U0001”、且つクレジット決済に対応付けられた入出金日“2016/1/15”の入出金額“\20,000”は当月利用額（2016/1/22時点）である。クレジット決済に対応付けられた利用履歴（図４の例では、便宜上、入出金履歴と記す）中の入出金日には、利用履歴データに含まれる利用日（決済日）が該当する。クレジット決済に対応付けられた利用履歴中の入出金額には、利用履歴データに含まれる利用額（決済額）が該当する。与信限度額、利用履歴データ、及びチャージ履歴データは、例えばユーザＩＤまたはクレジットカード番号をキーとして、クレジットカード管理サーバ５から所定のタイミング（定期的（例えば、１日毎）、或いは後述する信用承認額の算出の際など）で取得され、決済方法情報データベース８２ｃに格納される。

一方、ポイント決済に対応付けられた利用可能額（ポイント決済の利用可能額）には、残りポイント数（残高）が該当する。ポイント決済に対応付けられた入出金履歴中の入出金日には、利用履歴データに含まれる利用日（出金日）と、獲得履歴データに含まれる獲得日（入金日）とが該当する。ポイント決済に対応付けられた入出金履歴中の入出金額には、利用履歴データに含まれる利用ポイント数を所定の換算率で通貨に換算した額（出金額）と、獲得履歴データに含まれる獲得ポイント数を所定の換算率で通貨に換算した額（入金額）とが該当する。残りポイント数、利用履歴データ、及び獲得履歴データは、例えばユーザＩＤまたはポイントカード番号をキーとして、ポイント管理サーバ６から所定のタイミング（定期的（例えば、１日毎）、或いは後述する信用承認額の算出の際など）で取得され、決済方法情報データベース８２ｃに格納される。

一方、即時引落決済に対応付けられた利用可能額（即時引落決済の利用可能額）には、ユーザ口座情報に含まれる残高が該当する。即時引落決済に対応付けられた入出金履歴中の入出金日には、利用履歴データに含まれる利用日（出金日）と、振込履歴データに含まれる振込日（入金日）とが該当する。即時引落決済に対応付けられた入出金履歴中の入出金額には、利用履歴データに含まれる利用（出金額）と、振込履歴データに含まれる振込額（入金額）とが該当する。口座の残高、利用履歴データ、及び振込履歴データは、例えばユーザＩＤまたはデビットカード番号をキーとして、口座管理サーバ７から所定のタイミング（定期的（例えば、１日毎）、或いは後述する信用承認額の算出の際など）で取得され、決済方法情報データベース８２ｃに格納される。

また、図４に示す割振の可否は、ユーザが利用可能な決済方法の情報の一例であり、仮決済された支払金額の割振候補（つまり、仮決済後の実決済に利用する候補）とするか否かを、ユーザが利用可能な決済方法毎に示す。なお、割振の可否は、それぞれのユーザにより任意に選択可能であり、例えばユーザの操作に応じてウォレットサーバ８にアクセスしたユーザ端末１からの設定要求に応じて更新される。また、図４に示す割振の優先順位は、ユーザが利用可能な決済方法の情報の一例であり、仮決済された支払金額の割り振り候補の中で優先して割り振る順番を示す。このような優先順位が高いほど支払金額が優先して割り振られる。なお、割振の優先順位は、それぞれのユーザにより任意に指定可能であり、例えばユーザの操作に応じてウォレットサーバ８にアクセスしたユーザ端末１からの設定要求に応じて更新される。また、図４に示す利用ロック額は、仮決済された支払金額が割り振られた決済方法の利用可能額のうち、割り振られた分の金額を示す。利用ロック額は、支払金額が割り振られた決済方法の利用可能額のうち、仮決済から実決済までの間に利用されること防止する額である。図４の例では、利用ロック額として￥0が格納されているが、支払金額の決済方法への割り振りが行われたときに、その割振額が利用ロック額として格納（更新）されることになる。

システム制御部８３（本発明におけるコンピュータの一例）は、ＣＰＵ（Central Processing Unit）８３ａ（プロセッサ），ＲＯＭ（Read Only Memory）８３ｂ，及びＲＡＭ（Random Access Memory）８３ｃ等を備え、ＯＳ上で決済用プログラム等を実行する。図５は、電子決済システムＳの各構成要素の繋がりと、ウォレットサーバ８のシステム制御部８３の機能ブロックとを示す図である。システム制御部８３（システム制御部８３内のプロセッサ）は、決済用プログラムを実行することにより、図５に示すように、ＩＤ取得部８３１、決済方法情報取得部８３２、信用承認額算出部８３３、仮決済判定部８３４、仮決済部８３５、支払金額割振部８３６、利用ロック部８３７、実決済部８３８、及び利用ロック解除部８３９等として機能する。なお、ＩＤ取得部８３１は、本発明における第１取得手段の一例である。決済方法情報取得部８３２は、本発明における第２取得手段の一例である。信用承認額算出部８３３は、本発明における算出手段の一例である。仮決済判定部８３４は、本発明における決定手段の一例である。仮決済部８３５は、本発明における仮決済手段の一例である。支払金額割振部８３６は、本発明における割振手段の一例である。利用ロック部８３７は、本発明におけるロック手段の一例である。実決済部８３８は、本発明における実決済手段の一例である。利用ロック解除部８３９は、本発明におけるロック解除手段の一例である。

ＩＤ取得部８３１は、取引対象に対する決済を求めるユーザのユーザＩＤを、例えばユーザ端末１から店舗端末２を介して取得する。なお、ＩＤ取得部８３１は、所定のＷｅｂサイト（例えばショッピングモールサイト）において店舗（いわゆる仮想店舗）とユーザとが取引を行う場合、ＩＤ取得部８３１は、当該Ｗｅｂサイトのサーバから、取引対象に対する決済を求めるユーザのユーザＩＤを取得してもよい。

決済方法情報取得部８３２は、ユーザ端末１のユーザが利用可能な複数の決済方法であって、ＩＤ取得部８３１により取得されたユーザＩＤに対応付けられている複数の決済方法のそれぞれの情報（例えば、利用可能額、及び入出金履歴）を決済方法情報データベース８２ｃから取得する。

信用承認額算出部８３３は、決済方法情報取得部８３２により取得された、複数の決済方法のそれぞれの情報に基づいて、当該複数の決済方法のうち少なくとも１つの決済方法による実決済の前段階で暫定的に行われる仮決済で許容する信用承認額を算出する。図６は、信用承認額の算出例を示す図である。図６（Ａ）〜（Ｃ）の例では、各決済方法の利用可能額から信用根拠額が算出され、算出された各信用根拠額を合計した合計値が信用承認額として算出されている。この信用根拠額は、信用承認額の算出根拠となる金額である。例えば、信用承認額の算出時点から実決済の実行予定日までの間に入出金が予測される金額を利用可能額から増減した金額が信用根拠額として算出される。

ここで、信用承認額の算出時点を2016/1/22とし、実決済の実行予定日を2016/1/31 0:00と仮定したときの信用根拠額について図４を参照して具体的に説明する。図４において、ユーザＩＤ“U0001”とクレジット決済に対応付けられた利用履歴から、毎月２９日に\3,000が３０日に\30,000がそれぞれ利用されていることが特定することができるので、2016/1/22から2016/1/31までの間に\33,000の利用が予測される。このため、信用承認額算出部８３３は、2016/1/22から2016/1/31までの間の利用額\33,000を、利用せずに残すべき金額（ユーザにとって残しておかなければならない金額）として特定し、図６（Ａ）に示すように、クレジット決済に対応付けられた利用可能額\80,000から当該利用額\33,000を差し引いた残金額\47,000を信用根拠額として算出する。このように、信用承認額算出部８３３は、決済方法情報取得部８３２により取得された、決済方法の情報に含まれる決済方法の入出金履歴（この場合、利用履歴）及び利用可能額に基づいて、利用可能額から利用せずに残すべき金額を差し引いた残金額を算出し、当該残金額を信用根拠額として用いて信用承認額を算出することになる。これにより、ユーザの利用履歴から将来的に利用される可能性のある金額を除外して信用承認額を算出するので、より精度の高い（信頼性の高い）適切な信用承認額を算出することができる。すなわち、例えば、電子マネーなどは仮決済の後に、他の用途で利用されることが考えられるし、クレジットカードには携帯キャリア利用料金や公共料金などが毎月引き落とされるように設定されていたり、銀行口座からは毎月の家賃が引落があったりすることが考えられる。このような場合、仮決済時点において複数の決済方法にて支払可能な合計額にて信用承認すると、その後に他の用途で使われた決済により、実決済時には合計額が減っており決済できないことがあり得るが、ユーザの利用履歴から将来的に利用される可能性のある金額を除外して信用承認額を算出すれば実決済できないことを防止することができる。

なお、図４において、ユーザＩＤ“U0001”と電子マネー決済に対応付けられた入出金履歴からは、2016/1/22から2016/1/31までの間の出金は予測できない。このため、信用承認額算出部８３３は、利用せずに残すべき金額は\0となり、図６（Ａ）に示すように、電子マネー決済に対応付けられた利用可能額\13,000を信用根拠額として算出することになる。

一方、図４において、ユーザＩＤ“U0001”と即時引落決済に対応付けられた入出金履歴から、毎月２５日に\120,000が入金され、２９日に\100,000が出金されていることが特定することができるので、2016/1/22から2016/1/31までの間に差引\20,000の入金が予測される。このため、信用承認額算出部８３３は、2016/1/22から2016/1/31までの間の入金額\20,000を、利用できると予測される金額として特定し、図６（Ａ）に示すように、即時引落決済に対応付けられた利用可能額\0に当該入金額\20,000を加えた見込金額\20,000を信用根拠額として算出する。なお、図６（Ａ）の例では、電子マネー決済及びポイント決済のそれぞれに対応付けられた利用可能額は、そのまま信用根拠額として算出されている。また、図６（Ｂ），（Ｃ）の例では、各決済方法に対応付けられた利用可能額は、そのまま信用根拠額として算出されている。

ところで、図４において、ユーザＩＤ“U0002”と即時引落決済に対応付けられた割振の可否は「否」であるので、当該即時引落決済に対応付けられた利用可能額は、図６（Ｂ）に示すように除外されて信用承認額が算出される。すなわち、この場合、信用承認額算出部８３３は、ユーザｂが利用可能な複数の決済方法のうちから実決済に利用する候補として当該ユーザｂにより選択された複数の決済方法（つまり、割振の可否が「可」である決済方法）のそれぞれの情報に基づいて、信用承認額を算出することになる。これにより、ユーザの意向に沿った信用承認額を算出することができる。

なお、図６（Ａ）〜（Ｃ）の例では、各決済方法の各信用根拠額を合計した合計値が信用承認額として算出されているが、各決済方法の各信用根拠額の合計値の所定割合（例えば、合計値を１００％としたときの８０％程度）の額が信用承認額として算出されるように構成してもよい。

また、別の例として、信用承認額算出部８３３は、決済方法情報取得部８３２により取得された、複数の決済方法のそれぞれの情報から、決済方法全体の過去所定期間における利用可能額の推移（言い換えれば、時間経過に応じた利用可能額の変化）を特定し、当該決済方法全体の利用可能額の推移に基づいて、信用承認額を算出してもよい。図７は、ユーザが利用可能な複数の決済方法全体の過去所定期間における利用可能額の推移に基づいて信用承認額を算出する例を示す概念図である。図７の例では、電子マネー決済、ポイント決済、クレジット決済、及び即時引落決済のぞれぞれの利用可能額の推移と、これらの決済方法全体の利用可能額の推移とが示されている。なお、クレジット決済の利用可能額は月毎に与信限度額まで回復している。信用承認額算出部８３３は、このような決済方法全体の利用可能額の推移（つまり、当該推移を示すデータ列）から過去所定期間（例えば、３ヶ月〜６ヶ月程度）の推移を特定する。そして、信用承認額算出部８３３は、特定した過去所定期間における利用可能額の平均値（標準偏差値、最大値、或いは最小値でもよい）を算出し、算出した平均値の所定割合（例えば、平均値等を１００％としたときの８０％程度）の額を信用承認額として算出する。これにより、実決済の実行予定日に支払可能であると考えられる、より精度の高い適切な信用承認額を算出することができる。

仮決済判定部８３４は、信用承認額算出部８３３により算出された信用承認額と、取引対象の支払金額（例えば店舗端末２から取得される支払金額）とに基づいて、取引対象に対する決済を求めるユーザに対して仮決済を許可するかを決定する。例えば、仮決済判定部８３４は、信用承認額と支払金額と比較して、当該信用承認額が支払金額以上であると判定した場合、当該ユーザに対して仮決済を許可することを決定する。なお、当該信用承認額が支払金額未満であっても、その差が所定値（例えば、\1,000）以下であれば、仮決済を許可することが決定されてもよい。

仮決済部８３５は、仮決済判定部８３４により仮決済を許可することが決定された場合、支払金額を仮決済する。すなわち、仮決済部８３５は、信用承認ＯＫメッセージを店舗端末２へ送信し、取引対象に対する決済を求めるユーザと取引を行う店舗へ当該取引対象の支払金額を立て替えて支払うための処理を実行する。ここで、仮決済とは、信用承認ＯＫメッセージが店舗端末２へ送信されることをいうものであると解釈してもよいし、または、信用承認ＯＫメッセージが店舗端末２受信されることにより当該支払金額の売上が計上されることをいうものであると解釈してもよい。或いは、仮決済とは、当該店舗へ当該支払金額が支払われる（この支払は、電子マネー決済、即時引落決済、クレジット決済のいずれでもよい）ことをいうものであると解釈してもよいし、信用承認ＯＫメッセージが店舗端末２へ送信され、且つ、当該店舗へ当該支払金額が支払われることをいうものであると解釈してもよい。

支払金額割振部８３６は、仮決済された支払金額を、ユーザにより利用可能な複数の決済方法のうち少なくとも１つの決済方法に割り振る。これにより、仮決済された支払金額をユーザに負担をかけずに割り振りを行うことができる。支払金額は、１つの決済方法に割り振られてもよいし、複数の決済方法に分割されて割り振られてもよい。なお、支払金額の割り振りは、仮決済を許可することが決定された後、仮決済される前に行われてもよい。

図８は、支払金額の割振例を示す図である。図８（Ａ）の例では、各決済方法には割振の優先順位が対応付けられているため、仮決済された支払金額は、ユーザａにより利用可能な複数の決済方法のうち当該ユーザａにより予め指定された優先順位に応じて分割して割り振られている。これにより、仮決済された支払金額をユーザに負担をかけずに、ユーザの意向に沿った割り振りを行うことができる。より具体的には、支払金額\60,000のうち、先ず、割振の優先順位が１位であるクレジット決済に対して割振額\47,000（支払金額\60,000から分割された支払金額）が割り振られている。つまり、支払金額\60,000から分割される金額が、クレジット決済の信用根拠額\47,000以下になるように当該クレジット決済に割り振られている。この信用根拠額\47,000は、クレジット決済の利用可能額から利用せずに残すべき金額を差し引いた残金額に相当する。次に、割振の優先順位が２位であるポイント決済に対して割振額\5,000が割り振られている。つまり、支払金額\60,000から分割される金額が、ポイント決済の信用根拠額\5,000以下になるように当該ポイント決済に割り振られている。最後に、割振の優先順位が３位である電子マネー決済に対して割振額\8,000（残りの支払金額）が割り振られている。つまり、支払金額\60,000から分割される支払金額が、電子マネー決済の信用根拠額\8,000以下になるように当該電子マネー決済に割り振られている。このように、仮決済された支払金額は、ユーザａが利用可能な４つの決済方法のうち３つの決済方法に分割して割り振られる。

一方、図８（Ｂ）の例では、各決済方法には割振の優先順位が無い。この場合、仮決済された支払金額は、ユーザｂにより利用可能な複数の決済方法（電子マネー決済１、電子マネー決済２、クレジット決済、及び即時引落決済）のうちから実決済に利用する候補としてユーザｂにより選択された複数の決済方法（電子マネー決済１、電子マネー決済２、及びクレジット決済）に対して分割して割り振られている。より具体的には、支払金額\40,000が、電子マネー決済１、電子マネー決済２、及びクレジット決済のそれぞれの信用根拠額に応じた割合で\24,000、\8,000、及び\8,000に分割され、分割された割振額\24,000が電子マネー決済１に、分割された割振額\8,000が電子マネー決済２に、分割された割振額\8,000がクレジット決済にそれぞれ割り振られている。このように、仮決済された支払金額が、ユーザｂにより選択された３つの決済方法の全部に割り振られる。なお、仮決済された支払金額が、ユーザｂにより選択された３つの決済方法の一部（例えば、利用可能額が大きい上位２つの決済方法）に割り振られてもよい。一方、図８（Ｃ）の例では、各決済方法には割振の優先順位が対応付けられているが、この場合、支払金額\90,000を割振の優先順位が１位である即時引落決済に対して割り振ると残りの支払金額が\0となる。このため、仮決済された支払金額は、ユーザｃが利用可能な２つの決済方法のうち１つの決済方法に分割して割り振られることになる。これにより、仮決済された支払金額をユーザに負担をかけずに、複数の決済方法に分散させて割り振りを行うことができる。

ところで、仮決済された支払金額がストアド型電子マネー決済に割り振られた場合、電子バリューの残高は電子マネーカードの不揮発性メモリに格納されているので、実決済までの間にユーザにより電子バリューが決済に利用されてしまい、割振額が実決済に利用できない場合がある。このため、支払金額割振部８３６は、上述したウォレット機能により、ストアド型電子マネーの電子バリューのチャージ額が割振額以上管理されている場合に限り、当該ストアド型電子マネー決済に割り振るように構成するとよい。

利用ロック部８３７は、仮決済された支払金額が割り振られた決済方法の利用可能額のうち、割振額（つまり、実決済される予定の金額）の利用をロックする。これにより、決済方法に割り振られた分の金額が仮決済から実決済までの間に、ユーザにより利用されるのを確実に防止することができる。より具体的には、利用ロック部８３７は、決済方法への割振額を利用ロック額として決済方法情報データベース８２ｃに格納（更新）する。これにより、利用ロックが解除されるまでの間、信用承認額算出部８３３は、利用可能額から利用ロック額を差し引いた残金額を信用根拠額として算出することになる。また、利用ロック部８３７は、割振額が割り振られた決済方法に対応する管理サーバ４〜７の何れかへ、取引対象に対する決済を求めるユーザのユーザＩＤ、当該割振額が割り振られた決済方法、及び当該割振額を含む利用ロック要求をネットワークＮＷを介して送信する。なお、ストアド型電子マネー決済に割振額が割り振られた場合、ウォレット機能により当該ユーザのユーザＩＤに対応付けられて管理されているチャージ額のうち当該割振額分が電子マネー決済に利用されることを禁止する設定が行われる。

実決済部８３８は、実決済の実行予定日が到来した場合、仮決済された支払金額（つまり、割振額）を、割り振られた決済方法により実決済する。より具体的には、実決済部８３８は、割振額が割り振られた決済方法に対応する管理サーバ４〜７の何れかへ、割振額の利用がロックされた対象のユーザのユーザＩＤ、当該割振額が割り振られた決済方法、及び当該割振額を含む決済要求をネットワークＮＷを介して送信する。なお、ストアド型電子マネー決済に割振額が割り振られた場合、ウォレット機能により当該ユーザのユーザＩＤに対応付けられて管理されているチャージ額から割振額だけ減らす。

利用ロック解除部８３９は、上記実決済が完了すると、当該実決済された割振額の利用のロックを解除する。より具体的には、利用ロック解除部８３９は、利用ロック額から当該割振額を差し引いた金額を決済方法情報データベース８２ｃに格納（更新）する。そして、利用ロック解除部８３９は、利用ロック額がロック中の決済方法に対応する管理サーバ３〜７の何れかへ、割振額の利用がロックされた対象のユーザのユーザＩＤ、当該割振額の利用がロックされた決済方法、及び当該割振額を含む利用ロック解除要求をネットワークＮＷを介して送信する。なお、ストアド型電子マネー決済に支払金額が割り振られた場合、ウォレット機能により当該ユーザのユーザＩＤに対応付けられて管理されているチャージ額のうち利用ロック額分が電子マネー決済に利用されることを禁止する設定を解除する。

［２．電子決済システムＳの動作］
次に、本実施形態に係る電子決済システムＳの動作について説明する。

（２−１．割振の可否及び優先順位設定時の動作）
先ず、図９等を参照して、割振の可否及び優先順位設定時の動作について説明する。図９は、割振の可否及び優先順位設定時におけるユーザ端末１及びウォレットサーバ８の処理例を示すシーケンス図である。

例えばユーザａのユーザ端末１においてユーザ側仮決済用プログラムが起動してウォレットサーバ８へアクセスしてログインが完了した後、制御部１１は、操作・表示部１３に表示されたメニュー（図示せず）から、ユーザａにより設定開始ボタンの指定を受け付けると、取得要求をネットワークＮＷを介してウォレットサーバ８へ送信する（ステップＳ１）。この取得要求には、例えばユーザａのユーザＩＤが含まれる。

次いで、ウォレットサーバ８のシステム制御部８３は、ユーザ端末１からの取得要求を受信すると、ユーザａのユーザＩＤに対応付けられている決済方法毎の割振の可否及び優先順位を決済方法情報データベース８２ｃから取得する（ステップＳ２）。なお、例えば、割振の可否は、設定前の初期状態では「否」に設定されており、割振の優先順位は、設定前の初期状態では「無」に設定されている。次いで、ウォレットサーバ８のシステム制御部８３は、ステップＳ２で取得した決済方法毎の割振の可否及び優先順位を含むデータをネットワークＮＷを介してユーザ端末１へ送信する（ステップＳ３）。

次いで、ユーザ端末１の制御部１１は、ウォレットサーバ８からの割振の可否及び優先順位を含むデータを受信すると、割振の可否及び優先順位を記憶し、割振可否設定画面を操作・表示部１３に表示する（ステップＳ４）。図１０は、ユーザ端末１における割振可否設定画面の表示例を示す図である。図１０に示す割振可否設定画面には、ユーザａが利用可能な決済方法の割振の可否を選択するためのチェックボックス５１と、ユーザａが利用可能な決済方法の割振の優先順位を指定するための入力欄５２と、設定ボタン５３とが設けられている。

このような表示状態で、ユーザａは、チェックボックス５１の全部または一部をチェック（選択）することができる。制御部１１は、チェックボックス５１へのチェックを受け付けると（ステップＳ５：ＹＥＳ）、チェックされた決済方法の割振を「可」に更新する（ステップＳ６）。なお、図示しないが、チェックボックス５１へのチェックを外すと、その決済方法の割振が「否」に更新される。また、ユーザａは、入力欄５２の全部または一部に優先順位（数値）を入力（指定）することができる。制御部１１は、入力欄５２への入力を受け付けると（ステップＳ７：ＹＥＳ）、元の優先順位を、入力された優先順位に更新する（ステップＳ８）。そして、制御部１１は、ユーザａによる設定ボタン５３の指定を受け付けると（ステップＳ９：ＹＥＳ）、設定要求をネットワークＮＷを介してウォレットサーバ８へ送信する（ステップＳ１０）。この設定要求には、上記更新された割振の可否及び優先順位、並びにユーザａのユーザＩＤが含まれる。

次いで、ウォレットサーバ８のシステム制御部８３は、ユーザ端末１からの設定要求を受信すると、受信された設定要求に含まれる割振の可否及び優先順位に基づいて、決済方法情報データベース８２ｃに格納されている割振の可否及び優先順位であってユーザａのユーザＩＤに対応付けられている決済方法毎の割振の可否及び優先順位を更新（最新に設定）する（ステップＳ１１）。

（２−２．仮決済時の動作）
次に、図１１を参照して、仮決済時の動作について説明する。図１１は、仮決済時におけるユーザ端末１、店舗端末２、及びウォレットサーバ８の処理例を示すシーケンス図である。例えば、店舗で提供された取引対象に対する決済を求めるユーザａは、当該店舗のレジにおいて、自身が携帯するユーザ端末１のユーザ側仮決済用プログラムが起動させると、ユーザ端末１は、店舗側仮決済用プログラムが起動中の店舗端末２との間で近距離無線通信を開始する（ステップＳ２１）。このとき、上述した割振の可否及び優先順位設定が行われてもよい。次いで、ユーザ端末１の制御部１１は、ユーザａによる操作・表示部１３からの仮決済指示を受け付けると（ステップＳ２２：ＹＥＳ）、記憶部１２からユーザＩＤを取得する（ステップＳ２３）。次いで、ユーザ端末１の制御部１１は、ステップＳ２３で取得されたユーザＩＤを含む仮決済要求を、近距離無線通信部１５を介して店舗端末２へ送信する（ステップＳ２４）。

次いで、店舗端末２の制御部２１は、ユーザ端末１からの仮決済要求を受信すると、当該仮決済要求からユーザＩＤを取得する（ステップＳ２５）。なお、ユーザａは、自身が所持するカードを店舗の店員に提示してもよい。この場合、カードに記憶されているカード番号等の情報がリーダライタＲＷにより読み取られて店舗端末２により取得される。この場合、ユーザ端末１から送信される仮決済要求には、ユーザＩＤは含まれなくともよい。また、ユーザ端末１内にカード番号等の情報が記憶されている場合、ユーザ端末１の制御部１１は、カード番号等の情報を含む仮決済要求を、近距離無線通信部１５を介して店舗端末２へ送信してもよい（この場合、カードの提示は不要である）。

次いで、店舗端末２の制御部２１は、店員の操作によって入力された、上記取引対象の支払金額を取得する（ステップＳ２６）。次いで、店舗端末２の制御部２１は、記憶部２２から店舗ＩＤを取得する（ステップＳ２７）。次いで、店舗端末２の制御部２１は、信用承認要求を、通信部２４及びネットワークＮＷを介してウォレットサーバ８へ送信する（ステップＳ２８）。この信用承認要求には、ステップＳ２５で取得されたユーザＩＤと、ステップＳ２６で取得された支払金額と、ステップＳ２７で取得された店舗ＩＤとが含まれる。

なお、ユーザ端末１またはカードからカード番号等の情報が取得された場合、信用承認要求には、ユーザＩＤの代わりに当該カード番号等の情報が含まれる。

次いで、ウォレットサーバ８のシステム制御部８３（ＩＤ取得部８３１）は、店舗端末２からの信用承認要求を受信すると、当該信用承認要求からユーザＩＤ、支払金額、及び店舗ＩＤを取得する（ステップＳ２９）。なお、信用承認要求に、ユーザＩＤの代わりに当該カード番号等の情報が含まれる場合、システム制御部８３は、当該カード番号等の情報をキーとして、ユーザ情報データベース８２ｂから、カード番号等に対応付けられたユーザＩＤを取得することになる。

次いで、システム制御部８３は、決済方法情報データベース８２ｃを参照して、ステップＳ２９で取得されたユーザＩＤに対応付けられた決済方法のうち割振の可否が「可」である決済方法があるか否かを判定する（ステップＳ３０）。システム制御部８３は、割振の可否が「可」である決済方法がないと判定した場合（ステップＳ３０：ＮＯ）、処理をステップＳ３５へ進める。ステップＳ３５では、システム制御部８３は、信用承認ＮＧメッセージを、通信部８１及びネットワークＮＷを介して店舗端末２へ送信する。

一方、システム制御部８３は、割振の可否が「可」である決済方法があると判定した場合（ステップＳ３０：ＹＥＳ）、処理をステップＳ３１に進める。ステップＳ３１では、システム制御部８３（決済方法情報取得部８３２）は、割振の可否が「可」である決済方法の情報（例えば、利用可能額、及び入出金履歴）を決済方法情報データベース８２ｃから取得する。なお、ステップＳ２９で取得されたユーザＩＤに複数の決済方法が対応付けられている場合、それぞれの決済方法の情報が取得される。次いで、システム制御部８３は、実決済の実行予定日を設定する（ステップＳ３２）。例えば、実決済の実行予定日は、現時点から１週間〜３週間以内の日、或いは現時点を含む月の末日に設定される。

次いで、システム制御部８３（信用承認額算出部８３３）は、ステップＳ３１で取得された、割振の可否が「可」である決済方法の情報に基づいて、仮決済で許容する信用承認額を算出する（ステップＳ３３）。例えば、上述したように、システム制御部８３（信用承認額算出部８３３）は、当該信用承認額の算出時点（現時点）から実決済の実行予定日までの間に入出金が予測される金額を、当該決済方法の利用可能額から増減した信用根拠額を算出し、算出された信用根拠額に基づいて信用承認額を算出する。例えば、ステップＳ３１で、複数の決済方法のそれぞれの情報が取得された場合、システム制御部８３（信用承認額算出部８３３）は、各決済方法の信用根拠額を算出し、算出された信用根拠額を合計した合計値（または、合計値の所定割合）を信用承認額として算出する。別の例として、上述したように、システム制御部８３（信用承認額算出部８３３）は、ステップＳ３１で取得された、複数の決済方法のそれぞれの情報から、決済方法全体の過去所定期間（例えば、信用承認額の算出時点から過去４ヶ月前まで）における利用可能額の推移を特定し、当該決済方法全体の利用可能額の推移に基づいて信用承認額を算出してもよい。なお、ステップＳ３１で、１つの決済方法の情報が取得された場合、システム制御部８３（信用承認額算出部８３３）は、当該決済方法の信用根拠額を信用承認額として算出する。

次いで、システム制御部８３（仮決済判定部８３４）は、ステップＳ２９で取得された支払金額と、ステップＳ３３で算出された信用承認額とを比較して、当該信用承認額が支払金額以上であるか否かを判定する（ステップＳ３４）。システム制御部８３（仮決済判定部８３４）は、信用承認額が支払金額以上でないと判定した場合（ステップＳ３４：ＮＯ）、処理をステップＳ３５へ進める。システム制御部８３（仮決済判定部８３４）は、信用承認額が支払金額以上であると判定した場合（ステップＳ３４：ＹＥＳ）、ユーザａに対して仮決済を許可することを決定する（ステップＳ３６）。

こうして、仮決済を許可することが決定された場合、システム制御部８３（仮決済部８３５）は、ステップＳ２９で取得されたユーザＩＤ（つまり、仮決済が許可されたユーザａのユーザＩＤ）と支払金額、利用可能額が信用承認額の算出に利用された決済方法（例えば、決済方法を識別する決済種別ＩＤ）、当該決済方法の信用根拠額、当該決済方法の割振の優先順位（設定されている場合に限る）、及びステップＳ３２で設定された実決済の実行予定日を仮決済対象リストに登録する（ステップＳ３７）。次いで、システム制御部８３（仮決済部８３２）は、信用承認ＯＫメッセージを通信部８１及びネットワークＮＷを介して店舗端末２へ送信する（ステップＳ３８）。

次いで、システム制御部８３（仮決済部８３５）は、信用承認ＯＫメッセージの送信から所定時間内（例えば、２４時間以内）に、ステップＳ２９で取得された店舗ＩＤの店舗へ当該支払金額を立て替えて支払うための処理を実行する（ステップＳ３９）。例えば、システム制御部８３（仮決済部８３５）は、ステップＳ２９で取得された店舗ＩＤに対応付けられている店舗口座情報を店舗情報データベース８２ａから取得し、支払金額の移動要求（店舗口座情報、ウォレットサーバ８の運営者により用意された口座の口座番号、及び支払金額等を含む）を口座管理サーバ７または金融機関システム９へ送信する。これにより、当該支払金額がウォレットサーバ８の運営者により用意された口座（口座の残高）から引き落とされて当該店舗の口座に振り込まれる。

一方、店舗端末２の制御部２１は、ウォレットサーバ８からの信用承認ＯＫメッセージを受信すると、信用承認ＯＫを操作・表示部１３に表示し、当該取引対象の支払金額についての売上を計上する処理を行う（ステップＳ４０）。こうしてユーザａと店舗との取引が完了する。

（２−３．支払金額割振時の動作）
次に、図１２を参照して、支払金額割振時の動作について説明する。図１２は、支払金額割振時におけるウォレットサーバ８、及び管理サーバ４〜７の処理例を示すシーケンス図である。例えば、上記ステップＳ３９の処理後ただちに、或いは上記ステップＳ３９の処理から実決済の実行予定日までの間の何れかの日に、システム制御部８３は、上記仮決済対象リストから、ユーザＩＤ、決済方法、信用根拠額、割振の優先順位（設定されている場合に限る）、支払金額、及び実決済の実行予定日を含むレコード（１レコード）を１つ取得する（ステップＳ４１）。なお、システム制御部８３は、上記仮決済対象リストから取得されたユーザＩＤをキーとして、決済方法情報データベース８２ｃから決済方法、利用可能額、入出金履歴、及び割振の優先順位（設定されている場合に限る）を取得してもよい。この場合、システム制御部８３は、利用可能額、及び入出金履歴から信用根拠額を算出する。

次いで、システム制御部８３は、ステップＳ４１で、決済方法の割振の優先順位が取得されたか否かを判定する（ステップＳ４２）。システム制御部８３は、決済方法の割振の優先順位が取得されたと判定した場合（ステップＳ４２：ＹＥＳ）、処理をステップＳ４３に進める。一方、システム制御部８３は、決済方法の割振の優先順位が取得されていないと判定した場合（ステップＳ４２：ＮＯ）、処理をステップＳ４４に進める。

ステップＳ４３では、上述したように、システム制御部８３（支払金額割振部８３６）は、ステップＳ４１で取得された支払金額（つまり、仮決済された支払金額）をステップＳ４１で取得された各決済方法の割振の優先順位に応じて少なくとも１つの決済方法に割り振る。一方、ステップＳ４４では、上述したように、システム制御部８３（支払金額割振部８３６）は、ステップＳ４１で取得された支払金額をステップＳ４１で取得された決済方法に割り振る（決済方法が複数ある場合、当該支払金額をそれぞれの決済方法の信用根拠額に応じた割合で分割して当該決済方法に割り振る）。

次いで、システム制御部８３は、ステップＳ４１で取得されたユーザＩＤ、ステップＳ４３またはＳ４４で割り振られた決済方法、当該決済方法に割り振られた割振額、及びステップＳ４１取得された実決済の実行予定日を実決済対象リストに登録する（ステップＳ４５）。次いで、システム制御部８３（利用ロック部８３７）は、実決済対象リストに登録された決済方法への割振額を、ステップＳ４１で取得されたユーザＩＤに対応付けて利用ロック額として決済方法情報データベース８２ｃに格納し（ステップＳ４６）、当該割振額が割り振られた決済方法に対応する管理サーバ（図１２の例では、管理サーバ４〜７）へ利用ロック要求（ステップＳ４１で取得されたユーザＩＤ及び割振額を含む）をネットワークＮＷを介して送信する（ステップＳ４７）。このとき、上記仮決済対象リストからステップＳ４１で取得されたユーザＩＤを含むレコードが削除される。また、仮決済対象リストにユーザＩＤを含む別のレコードが登録されている場合、当該レコードについてステップＳ４１以降の処理が行われる。

第２電子マネー管理サーバ４は、ウォレットサーバ８からの利用ロック要求を受信すると、当該利用ロック要求に含まれるユーザＩＤに対応付けて、割振額を利用ロック額として記憶し、当該ユーザＩＤに対応付けられた電子バリューの残高のうち当該利用ロック額分がサーバ型電子マネー決済に利用されることを禁止する設定（利用ロック額の禁止設定）を行う（ステップＳ４８）。次いで、第２電子マネー管理サーバ４は、利用ロック完了メッセージをウォレットサーバ８へ返信し（ステップＳ４９）、ウォレットサーバ８は、当該利用ロック完了メッセージを受信する。

一方、クレジットカード管理サーバ５は、ウォレットサーバ８からの利用ロック要求を受信すると、当該利用ロック要求に含まれるユーザＩＤに対応付けて、割振額を利用ロック額として記憶し、当該ユーザＩＤに対応付けられた利用可能額のうち利用ロック額分がクレジット決済に利用されることを禁止する設定（利用ロック額の禁止設定）を行う（ステップＳ５０）。つまり、クレジットカード管理サーバ５は、利用可能額から利用ロック額を差し引いた金額を超える支払金額の与信照会を承認しない。次いで、クレジットカード管理サーバ５は、利用ロック完了メッセージをウォレットサーバ８へ返信し（ステップＳ５１）、ウォレットサーバ８は、当該利用ロック完了メッセージを受信する。

一方、ポイント管理サーバ６は、ウォレットサーバ８からの利用ロック要求を受信すると、当該利用ロック要求に含まれるユーザＩＤに対応付けて、割振額を利用ロック額として記憶し、当該ユーザＩＤに対応付けられた残りポイント数のうち利用ロック額に対応するポイント分がポイント決済に利用されることを禁止する設定（利用ロック額の禁止設定）を行う（ステップＳ５２）。次いで、ポイント管理サーバ６は、利用ロック完了メッセージをウォレットサーバ８へ返信し（ステップＳ５３）、ウォレットサーバ８は、当該利用ロック完了メッセージを受信する。

一方、口座管理サーバ７は、ウォレットサーバ８からの利用ロック要求を受信すると、当該利用ロック要求に含まれるユーザＩＤに対応付けて、割振額を利用ロック額として記憶し、当該ユーザＩＤに対応付けられた口座の残高のうち利用ロック額分が即時引落決済に利用されることを禁止する設定（利用ロック額の禁止設定）を行う（ステップＳ５４）。次いで、口座管理サーバ７は、利用ロック完了メッセージをウォレットサーバ８へ返信し（ステップＳ５５）、ウォレットサーバ８は、当該利用ロック完了メッセージを受信する。

（２−４．実決済時の動作）
次に、図１３を参照して、実決済時の動作について説明する。図１３は、実決済時におけるウォレットサーバ８、及び管理サーバ４〜７の処理例を示すシーケンス図である。例えば、予め設定された時刻（例えば、毎日午前０時）になると、システム制御部８３は、実決済の実行予定日が到来したユーザＩＤを含むレコードが実決済対象リストに登録されているか否かを判定する（ステップＳ６１）。システム制御部８３は、実決済の実行予定日が到来したユーザＩＤを含むレコードが実決済対象リストに登録されていると判定した場合（ステップＳ６１：ＹＥＳ）、ステップＳ６２へ処理を進める。一方、システム制御部８３は、実決済の実行予定日が到来したユーザＩＤを含むレコードが実決済対象リストに登録されていないと判定した場合（ステップＳ６１：ＮＯ）、処理を終了する。

ステップＳ６２では、システム制御部８３は、実決済の実行予定日が到来したユーザＩＤ、決済方法、及び割振額を含むレコードを実決済対象リストから１つ取得する。次いで、システム制御部８３（実決済部８３８）は、ステップＳ６２で取得された決済方法に対応する管理サーバ（図１３の例では、管理サーバ４〜７）へ決済要求（ステップＳ６２で取得されたユーザＩＤ及び割振額を含む）をネットワークＮＷを介して送信する（ステップＳ６３）。

第２電子マネー管理サーバ４は、ウォレットサーバ８からの決済要求を受信すると、当該決済要求に含まれるユーザＩＤに対応付けられた電子バリューの残高が、割振額以上である場合（なお、電子バリューの残高が割振額未満である場合、サーバ型電子マネー決済は行われない）、当該電子バリューの残高を割振額だけ減らす処理（決済処理）を行う（ステップＳ６４）。次いで、第２電子マネー管理サーバ４は、決済完了メッセージをウォレットサーバ８へ返信し（ステップＳ６５）、ウォレットサーバ８は、当該決済完了メッセージを受信する。

一方、クレジットカード管理サーバ５は、ウォレットサーバ８からの決済要求を受信すると、クレジット決済が可能であるか否かの与信照会を行い（ステップＳ６６）、例えば有効期限が過ぎておらず、且つ当該決済要求に含まれる割振額が、当該決済要求に含まれるユーザＩＤに対応付けられた利用可能額を超えていない場合（なお、割振額が利用可能額を超えている場合、クレジット決済は行われない）に、与信承認ＯＫメッセージ（完了メッセージに相当）をウォレットサーバ８へ返信し（ステップＳ６７）、ウォレットサーバ８は、当該与信承認ＯＫメッセージを受信する。そして、与信承認ＯＫメッセージが受信された場合、クレジット決済が行われる。すなわち、割振額を請求する請求データ（ステップＳ６２で取得されたユーザＩＤ、ウォレットサーバ８の運営者により用意された口座の口座番号、及び割振額を含む）がクレジットカード管理サーバ５へ送信され、さらに、クレジットカード管理サーバ５から金融機関システム９へ資金移動要求が送信される。これにより、当該割振額が立替払取次業者（例えば、クレジットカード会社）の口座（口座の預金残高）から引き落とされてウォレットサーバ８の運営者（立替払取次業者と同一の場合もある）により用意された口座に振り込まれる。その後、当該割振額及び手数料が当該ユーザの口座から引き落とされる。

一方、ポイント管理サーバ６は、ウォレットサーバ８からの決済要求を受信すると、当該決済要求に含まれるユーザＩＤに対応付けられた残りポイント数が、割振額を所定の換算率で換算したポイント数以上である場合（なお、当該残りポイント数が当該ポイント数未満である場合、ポイント決済は行われない）、当該残りポイント数を減らす（つまり、割振額を所定の換算率で換算したポイント分だけ減らす）処理（決済処理）を行う（ステップＳ６８）。次いで、ポイント管理サーバ６は、決済完了メッセージをウォレットサーバ８へ返信し（ステップＳ６９）、ウォレットサーバ８は、当該決済完了メッセージを受信する。

一方、口座管理サーバ７は、ウォレットサーバ８からの決済要求を受信すると、当該決済要求に含まれるユーザＩＤに対応付けられたユーザの口座の残高が、割振額以上である場合（当該残高が割振額未満である場合、即時引落決済は行われない）、当該割振額の移動要求（当該決済要求に含まれるユーザＩＤ、ウォレットサーバ８の運営者により用意された口座の口座番号、及び割振額を含む）を金融機関システム９へ送信する（ステップＳ７０）。これにより、当該割振額がユーザの口座（口座の残高）から引き落とされてウォレットサーバ８の運営者により用意された口座に振り込まれる。次いで、口座管理サーバ７は、決済完了メッセージをウォレットサーバ８へ返信し（ステップＳ７１）、ウォレットサーバ８は、当該決済完了メッセージを受信する。

以上のように、ウォレットサーバ８が上記決済要求の送信先となった全ての管理サーバ（図１３の例では、管理サーバ４〜７）から上記決済完了メッセージを受信した場合に、実決済が完了する（ステップＳ７２）。そして、システム制御部８３（利用ロック解除部８３９）は、ステップＳ６２で取得されたユーザＩＤ及び決済方法に対応付けられている利用ロック額（決済方法情報データベース８２ｃに登録中）から、ステップＳ６２で取得された割振額を差し引いた金額を決済方法情報データベース８２ｃに格納する。次いで、システム制御部８３（利用ロック解除部８３９）は、ステップＳ６２で取得された決済方法に対応する管理サーバ（図１３の例では、管理サーバ４〜７）へ利用ロック解除要求（ステップＳ６２で取得されたユーザＩＤ及び割振額を含む）をネットワークＮＷを介して送信する（ステップＳ７３）。なお、利用ロック解除要求の送信は、決済要求の送信と同時に行われてもよい。

第２電子マネー管理サーバ４は、ウォレットサーバ８からの利用ロック解除要求を受信すると、当該利用ロック解除要求に含まれるユーザＩＤに対応付けられた利用ロック額から当該割振額を減額し、当該ユーザＩＤに対応付けられた電子バリューの残高のうち当該割振額分がサーバ型電子マネー決済に利用されることを禁止する設定を解除（利用ロック額の禁止設定解除）する（ステップＳ７４）。次いで、第２電子マネー管理サーバ４は、利用ロック解除完了メッセージをウォレットサーバ８へ返信し（ステップＳ７５）、ウォレットサーバ８は、当該利用ロック解除完了メッセージを受信する。

一方、クレジットカード管理サーバ５は、ウォレットサーバ８からの利用ロック解除要求を受信すると、当該利用ロック解除要求に含まれるユーザＩＤに対応付けられた利用ロック額から当該割振額を減額し、当該ユーザＩＤに対応付けられた利用可能額のうち当該割振額分がクレジット決済に利用されることを禁止する設定を解除（利用ロック額の禁止設定解除）する（ステップＳ７６）。次いで、クレジットカード管理サーバ５は、利用ロック解除完了メッセージをウォレットサーバ８へ返信し（ステップＳ７７）、ウォレットサーバ８は、当該利用ロック解除完了メッセージを受信する。

一方、ポイント管理サーバ６は、ウォレットサーバ８からの利用ロック解除要求を受信すると、当該利用ロック解除要求に含まれるユーザＩＤに対応付けられた利用ロック額から当該割振額を減額し、当該ユーザＩＤに対応付けられた残りポイント数のうち当該割振額に対応するポイント分がポイント決済に利用されることを禁止する設定を解除（利用ロック額の禁止設定解除）する（ステップＳ７８）。次いで、ポイント管理サーバ６は、利用ロック解除完了メッセージをウォレットサーバ８へ返信し（ステップＳ７９）、ウォレットサーバ８は、当該利用ロック解除完了メッセージを受信する。

一方、口座管理サーバ７は、ウォレットサーバ８からの利用ロック解除要求を受信すると、当該利用ロック解除要求に含まれるユーザＩＤに対応付けられた利用ロック額から当該割振額を減額し、当該ユーザＩＤに対応付けられた口座の残高のうち当該割振額分が即時引落決済に利用されることを禁止する設定を解除（利用ロック額の禁止設定解除）する（ステップＳ８０）。次いで、口座管理サーバ７は、利用ロック解除完了メッセージをウォレットサーバ８へ返信し（ステップＳ８１）、ウォレットサーバ８は、当該利用ロック解除完了メッセージを受信する。

以上のように、ウォレットサーバ８が上記利用ロック解除要求の送信先となった全ての管理サーバ（図１３の例では、管理サーバ４〜７）から上記利用ロック解除メッセージを受信した場合、上記実決済対象リストからステップＳ６２で取得されたユーザＩＤを含むレコードが削除され、上記実決済対象リストに、実決済の実行予定日が到来したユーザＩＤを含む別のレコードが登録されている場合、当該別のレコードについてステップＳ６２以降の処理が行われる。

以上説明したように、上記実施形態によれば、システム制御部８３は、取引対象に対する決済を求めるユーザが利用可能な複数の決済方法のそれぞれの情報を取得し、当該複数の決済方法のそれぞれの情報に基づいて仮決済で許容する信用承認額を算出し、当該信用承認額と当該取引対象の支払金額とに基づいて当該ユーザに対して仮決済を許可するかを決定するように構成したので、当該ユーザが利用可能な複数の決済方法による全体的な支払い能力を考慮することができ、より実質的なユーザの支払能力に応じた信用承認を行うことができる。その結果、ユーザの利便性を高め、店舗の販売機会の損失を回避することができる。

なお、上記実施形態においては、ウォレットサーバ８のシステム制御部８３が決済用プログラムを実行することにより、ＩＤ取得部８３１、決済方法情報取得部８３２、信用承認額算出部８３３、仮決済判定部８３４、仮決済部８３５、支払金額割振部８３６、利用ロック部８３７、実決済部８３８、及び利用ロック解除部８３９として機能するように構成した。しかし、ユーザ端末１の制御部１１が、ＩＤ取得部８３１、決済方法情報取得部８３２、信用承認額算出部８３３、仮決済判定部８３４、仮決済部８３５、及び支払金額割振部８３６のうちの全部または一部として機能するように構成してもよい。例えば、ユーザ端末１の制御部１１は、取引対象に対する決済を求めるユーザのユーザＩＤ及び当該取引対象の支払金額を取得し、取得したユーザＩＤに付けられている複数の決済方法のそれぞれの情報（例えば、利用可能額、及び入出金履歴）をウォレットサーバ８からネットワークＮＷを介して取得する。ユーザ端末１の制御部１１は、取得された複数の決済方法のそれぞれの情報に基づいて、上述したように、仮決済で許容する信用承認額を算出し、算出された信用承認額と、当該取引対象の支払金額とに基づいて当該仮決済を許可するかを決定する。そして、ユーザ端末１の制御部１１は、仮決済を許可することを決定した場合、信用承認ＯＫメッセージをウォレットサーバ８へ送信する。或いは、ユーザ端末１の制御部１１は、取得された複数の決済方法のそれぞれの情報に基づいて仮決済で許容する信用承認額を算出し、算出された信用承認額及び支払金額をウォレットサーバ８へ送信してもよい。この場合、ウォレットサーバ８が信用承認額と支払金額とに基づいて当該仮決済を許可するかを決定し、仮決済を許可することを決定した場合、仮決済を行う。

或いは、店舗端末２の制御部２１が、ＩＤ取得部８３１、決済方法情報取得部８３２、信用承認額算出部８３３、仮決済判定部８３４、仮決済部８３５、及び支払金額割振部８３６のうちの全部または一部として機能するように構成してもよい。例えば、店舗端末２の制御部２１は、取引対象に対する決済を求めるユーザのユーザＩＤ及び当該取引対象の支払金額を取得し、取得したユーザＩＤに付けられている複数の決済方法のそれぞれの情報（例えば、利用可能額、及び入出金履歴）をウォレットサーバ８からネットワークＮＷを介して取得する。店舗端末２の制御部２１は、取得された複数の決済方法のそれぞれの情報に基づいて、仮決済で許容する信用承認額を算出し、算出された信用承認額と、当該取引対象の支払金額とに基づいて当該仮決済を許可するかを決定する。そして、店舗端末２の制御部２１は、仮決済を許可することを決定した場合、信用承認ＯＫメッセージをウォレットサーバ８へ送信する。或いは、店舗端末２の制御部２１は、取得された複数の決済方法のそれぞれの情報に基づいて仮決済で許容する信用承認額を算出し、算出された信用承認額及び支払金額をウォレットサーバ８へ送信してもよい。この場合、ウォレットサーバ８が信用承認額と支払金額とに基づいて当該仮決済を許可するかを決定し、仮決済を許可することを決定した場合、仮決済を行う。

１ ユーザ端末
２ 店舗端末
３ 第１電子マネー管理サーバ
４ 第２電子マネー管理サーバ
５ クレジットカード管理サーバ
６ ポイント管理サーバ
７ 口座管理サーバ
８ ウォレットサーバ
８１ 通信部
８２ 記憶部
８３ システム制御部
８３１ ＩＤ取得部
８３２ 決済方法情報取得部
８３３ 信用承認額算出部
８３４ 仮決済判定部
８３５ 仮決済部
８３６ 支払金額割振部
８３７ 利用ロック部
８３８ 実決済部
８３９ 利用ロック解除部
ＮＷ ネットワーク
Ｓ 電子決済システム

Claims (13)

1. 取引対象に対する決済を求めるユーザの識別情報を取得する第１取得手段と、
   前記ユーザが利用可能な複数の決済方法であって前記識別情報に対応付けられている前記複数の決済方法のそれぞれの情報を取得する第２取得手段と、
   前記複数の決済方法のそれぞれの情報に基づいて、前記複数の決済方法のうち少なくとも１つの決済方法による実決済の前段階で暫定的に行われる仮決済で許容する信用承認額を算出する算出手段と、
   前記信用承認額と前記取引対象の支払金額とに基づいて、前記ユーザに対して前記仮決済を許可するかを決定する決定手段と、
   を備えることを特徴とする情報処理システム。
2. 前記算出手段は、前記決済方法の情報に含まれる前記決済方法の利用履歴及び利用可能額に基づいて前記利用可能額から利用せずに残すべき金額を差し引いた残金額を算出し、当該残金額を用いて前記信用承認額を算出することを特徴とする請求項１に記載の情報処理システム。
3. 前記算出手段は、前記複数の決済方法のそれぞれの情報から、前記決済方法全体の過去所定期間における利用可能額の推移を特定し、当該決済方法全体の利用可能額の推移に基づいて、前記信用承認額を算出することを特徴とする請求項１に記載の情報処理システム。
4. 前記算出手段は、前記複数の決済方法のうちから前記実決済に利用する候補として当該ユーザにより選択された複数の決済方法のそれぞれの情報に基づいて、前記信用承認額を算出することを特徴とする請求項１乃至３の何れか一項に記載の情報処理システム。
5. 前記仮決済される前記支払金額を、前記複数の決済方法のうち少なくとも１つの決済方法に割り振る割振手段を更に備えることを特徴とする請求項１乃至４の何れか一項に記載の情報処理システム。
6. 前記割振手段は、前記仮決済される前記支払金額を、前記複数の決済方法のうち前記ユーザにより予め指定された優先順位に応じて割り振ることを特徴とする請求項５に記載の情報処理システム。
7. 前記割振手段は、前記仮決済される前記支払金額を分割して前記複数の決済方法に割り振ることを特徴とする請求項５または６に記載の情報処理システム。
8. 前記割振手段は、前記仮決済される前記支払金額を、前記複数の決済方法のうちから前記実決済に利用する候補として前記ユーザにより選択された複数の決済方法の一部または全部に割り振ることを特徴とする請求項５または６に記載の情報処理システム。
9. 前記割振手段は、前記分割される前記支払金額が、前記決済方法の情報に含まれる前記決済方法の利用可能額から利用せずに残すべき金額を差し引いた残金額以下になるように割り振ることを特徴とする請求項７に記載の情報処理システム。
10. 前記決定手段により前記仮決済を許可することが決定された場合、前記支払金額を仮決済する仮決済手段と、
    前記仮決済された前記支払金額が割り振られた前記決済方法の利用可能額のうち当該割り振られた分の金額の利用をロックするロック手段と、
    前記仮決済された前記支払金額を、前記割り振られた前記決済方法により実決済する実決済手段と、
    前記実決済された前記支払金額の利用のロックを解除するロック解除手段と、
    を備えることを特徴とする請求項１乃至８の何れか一項に記載の情報処理システム。
11. 取引対象に対する決済を求めるユーザの識別情報を取得する第１取得手段と、
    前記ユーザが利用可能な複数の決済方法であって前記識別情報に対応付けられている前記複数の決済方法のそれぞれの情報を取得する第２取得手段と、
    前記複数の決済方法のそれぞれの情報に基づいて、前記複数の決済方法のうち少なくとも１つの決済方法による実決済の前段階で暫定的に行われる仮決済で許容する信用承認額を算出する算出手段と、
    前記信用承認額と前記取引対象の支払金額とに基づいて、前記ユーザに対して前記仮決済を許可するかを決定する決定手段と、
    を含むことを特徴とするサーバ装置。
12. １つ以上のコンピュータにより実行される情報処理方法であって、
    取引対象に対する決済を求めるユーザの識別情報を取得する第１取得ステップと、
    前記ユーザが利用可能な複数の決済方法であって前記識別情報に対応付けられている前記複数の決済方法のそれぞれの情報を取得する第２取得ステップと、
    前記複数の決済方法のそれぞれの情報に基づいて、前記複数の決済方法のうち少なくとも１つの決済方法による実決済の前段階で暫定的に行われる仮決済で許容する信用承認額を算出する算出ステップと、
    前記信用承認額と前記取引対象の支払金額とに基づいて、前記ユーザに対して前記仮決済を許可するかを決定する決定ステップと、
    を含むことを特徴とする情報処理方法。
13. コンピュータを、
    取引対象に対する決済を求めるユーザの識別情報を取得する第１取得手段と、
    前記ユーザが利用可能な複数の決済方法であって前記識別情報に対応付けられている前記複数の決済方法のそれぞれの情報を取得する第２取得手段と、
    前記複数の決済方法のそれぞれの情報に基づいて、前記複数の決済方法のうち少なくとも１つの決済方法による実決済の前段階で暫定的に行われる仮決済で許容する信用承認額を算出する算出手段と、
    前記信用承認額と前記取引対象の支払金額とに基づいて、前記ユーザに対して前記仮決済を許可するかを決定する決定手段として機能させることを特徴とする情報処理プログラム。