JP2016173665A - クレジット管理サーバ、クレジット管理方法及びクレジット管理サーバ用プログラム - Google Patents

Abstract

【課題】決済依頼者が専用の機器や端末を導入せずに、決済処理を実行可能であり、デポジットしている金額以上の金額を支払うことを防止するクレジット管理サーバ、クレジット管理方法及びクレジット管理サーバ用プログラムを提供する。
【解決手段】クレジット管理サーバ１０は、ユーザ端末１００からユーザを識別するユーザＩＤを受信し、決済の種別を決める決済種別データと、この決済種別データに対応した決済の限度額を示す決済限度額データとを受信し、受信したユーザＩＤと、決済種別データと、決済限度額データとを対応付けて記憶し、ユーザＩＤによる決済リクエストであって、決済種別データを識別する決済種別認識コードと、決済種別データに対応する決済限度額データとを受信した際に、記憶した決済種別データと同一の決済種別であって、かつ決済種別データに対応した決済限度額データが記憶した決済限度額内である場合にのみ、決済を実行する。
【選択図】図１

Description

本発明は、決済を実行するクレジット管理サーバ、クレジット管理方法及びクレジット管理サーバ用プログラム。

従来、ネットワークを介して、端末からサーバにアクセスし、銀行決済を可能とする決済システムが知られている。この決済システムでは、所定のユーザにのみサーバへのアクセスを許可することで、セキュリティを確保する。また、このような決済システムでは、端末から決済システムの利用者を特定し、この利用者がサーバへのアクセスを許可された所定のユーザであるか否かを判定することで、サーバへの不正なアクセスを防止する。

しかしながら、このような決済システムでは、ユーザは、専用のカード等を用意し、このカード等を使用することにより、決済用の端末からサーバにアクセスし、銀行決済を可能とするものである。例えば、タクシーの乗車料金の支払いにおいて、非接触式カードと、非接触式カードリーダとを用いることで、乗車料金に対する決済処理を実行する料金決済システムが開示されている（例えば、特許文献１参照）。

特許文献１に記載の発明では、決済カード情報と、乗車料金情報とに基づいて、乗車料金に対する決済処理を実行し、外部の決済センターとの間で決済情報を通信することで、オンライン決済を実行することにより、ユーザの利便性を向上させている。

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

しかしながら、上述のような決済システムにおいては、決済依頼者は、用途に応じた専用の機器や端末が必要となり、導入する場合には、コストが上昇してしまう。また、上述の決済システムでは、実際に使用した料金を支払うことを目的とするものであり、事前にデポジットしている金額以上を支払うことになってしまうことも起こり得た。

本発明は、上述した課題に鑑み、決済依頼者が専用の機器や端末を導入せずに、決済処理を実行可能であり、デポジットしている金額以上の金額を支払うことを防止するクレジット管理サーバ、クレジット管理方法及びクレジット管理サーバ用プログラムを提供することを目的とする。

本発明では、以下のような解決手段を提供する。

第１の特徴に係る発明は、ユーザ端末からユーザを識別するユーザＩＤを受信するユーザＩＤ受信手段と、
決済の種別を決める決済種別データと、当該決済種別データに対応した決済の限度額を示す決済限度額データとを受信する決済データ受信手段と、
受信した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを対応付けて記憶する決済データ記憶手段と、
前記ユーザＩＤによる決済リクエストであって、前記決済種別データを識別する決済種別認識コードと、当該決済種別データに対応する決済限度額データとを受信した際に、前記決済データ記憶手段に記憶された決済種別データと同一の決済種別であって、かつ当該決済種別データに対応した決済限度額データが前記決済データ記憶手段に記憶された決済限度額内である場合にのみ、決済を実行する決済判断手段と、
を備えるクレジット管理サーバを提供する。

第１の特徴に係る発明によれば、ユーザ端末からユーザを識別するユーザＩＤを受信し、決済の種別を決める決済種別データと、当該決済種別データに対応した決済の限度額を示す決済限度額データとを受信し、受信した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを対応付けて記憶し、前記ユーザＩＤによる決済リクエストであって、前記決済種別データを識別する決済種別認識コードと、当該決済種別データに対応する決済限度額データとを受信した際に、前記決済データ記憶手段に記憶された決済種別データと同一の決済種別であって、かつ当該決済種別データに対応した決済限度額データが前記決済データ記憶手段に記憶された決済限度額内である場合にのみ、決済を実行する。

ここで、第１の特徴に係る発明は、クレジット管理サーバの発明であるが、クレジット管理方法及びクレジット管理サーバ用プログラムのカテゴリにおいても、同様の作用・効果を発揮する。

第２の特徴に係る発明は、前記データ記憶手段に記憶した前記決済種別データと、前記決済限度額データとを編集する編集手段と、
を備えた第１の特徴に係る発明であるクレジット管理サーバを提供する。

第２の特徴に係る発明によれば、第１の特徴に係る発明であるクレジット管理サーバは、記憶した前記決済種別データと、前記決済限度額データとを編集する。

第３の特徴に係る発明は、前記データ記憶手段に記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとに有効期限を設定する有効期限設定手段と、
前記有効期限設定手段により設定された有効期限を超えた場合、記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを削除する削除手段と、
を備えた第１又は第２のいずれかの特徴に係るクレジット管理サーバを提供する。

第３の特徴に係る発明によれば、第１又は第２のいずれかの特徴に係る発明であるクレジット管理サーバは、記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとに有効期限を設定し、設定された有効期限を超えた場合、記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを削除する。

第４の特徴に係る発明は、前記決済判断手段は、前記決済データ記憶手段に記憶された決済限度額データと同一の決済種別であって、かつ前記決済種別データに対応した決済限度額データが前記決済データ記憶手段に記憶された決済限度額外である場合、アラート通知を前記ユーザ端末に送信する、第１乃至第３のいずれかの特徴に係るクレジット管理サーバを提供する。

第４の特徴に係る発明によれば、第１乃至第３のいずれかの特徴に係る発明であるクレジット管理サーバは、記憶された決済限度額データと同一の決済種別であって、かつ前記決済種別データに対応した決済限度額データが記憶された決済限度額外である場合、アラート通知を前記ユーザ端末に送信する。

第５の特徴に係る発明は、ユーザ端末からユーザを識別するユーザＩＤを受信するステップと、
決済の種別を決める決済種別データと、当該決済種別データに対応した決済の限度額を示す決済限度額データとを受信するステップと、
受信した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを対応付けて記憶するステップと、
前記ユーザＩＤによる決済リクエストであって、前記決済種別データを識別する決済種別認識コードと、当該決済種別データに対応する決済限度額データとを受信した際に、前記決済データ記憶手段に記憶された決済種別データと同一の決済種別であって、かつ当該決済種別データに対応した決済限度額データが前記対応付けて記憶するステップにおいて記憶された決済限度額内である場合にのみ、決済を実行するステップと、
を備えるクレジット管理方法を提供する。

第６の特徴に係る発明は、ユーザ端末からユーザを識別するユーザＩＤを受信するステップ、
決済の種別を決める決済種別データと、当該決済種別データに対応した決済の限度額を示す決済限度額データとを受信するステップ、
受信した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを対応付けて記憶するステップ、
前記ユーザＩＤによる決済リクエストであって、前記決済種別データを識別する決済種別認識コードと、当該決済種別データに対応する決済限度額データとを受信した際に、前記決済データ記憶手段に記憶された決済種別データと同一の決済種別であって、かつ当該決済種別データに対応した決済限度額データが前記対応付けて記憶するステップにおいて記憶された決済限度額内である場合にのみ、決済を実行するステップ、
をクレジット管理サーバに実行させるクレジット管理サーバ用プログラムを提供する。

本発明によれば、決決済依頼者が専用の機器や端末を導入せずに、決済処理を実行可能であり、デポジットしている金額以上の金額を支払うことを防止するクレジット管理サーバ、クレジット管理方法及びクレジット管理サーバ用プログラムを提供することが可能となる。

図１は、クレジット管理システム１の概要を説明するための概念図である。 図２は、クレジット管理システム１の全体構成図である。 図３は、決済サーバ５、決済端末６、クレジット管理サーバ１０及びユーザ端末１００の機能ブロック図である。 図４は、決済サーバ５、決済端末６、クレジット管理サーバ１０及びユーザ端末１００が実行するクレジット管理処理のフローチャートである。 図５は、決済サーバ５、決済端末６、クレジット管理サーバ１０及びユーザ端末１００が実行する決済処理のフローチャートである。 図６は、決済サーバ５、決済端末６、クレジット管理サーバ１０及びユーザ端末１００が実行するアラート処理のフローチャートである。 図７は、クレジット管理サーバ１０が記憶するデポジット情報テーブルを示す図である。 図８は、クレジット管理サーバ１０が記憶する決済種別認識コードテーブルを示す図である。 図９は、クレジット管理サーバ１０が記憶する決済駅別テーブルを示す図である。 図１０は、クレジット管理サーバ１０が記憶する決済地域別テーブルを示す図である。 図１１は、ユーザ端末１００が表示するデポジット表示画面を示す図である。 図１２は、ユーザ端末１００が表示するデポジット表示画面を示す図である。 図１３は、ユーザ端末１００が表示するデポジット編集画面を示す図である。 図１４は、ユーザ端末１００が表示する決済完了画面を示す図である。 図１５は、ユーザ端末１００が表示するアラート表示画面を示す図である。 図１６は、ユーザ端末１００が表示するアラート表示画面を示す図である。 図１７は、ユーザ端末１００が表示するアラート表示画面を示す図である。

以下、本発明を実施するための最良の形態について図を参照しながら説明する。なお、これはあくまでも一例であって、本発明の技術的範囲はこれに限られるものではない。

本発明の概要は、クレジット管理サーバは、ユーザ端末からユーザを識別するユーザＩＤを受信し、決済の種別を決める決済種別データと、この決済種別データに対応した決済の限度額を示す決済限度額データとを受信し、この受信したユーザＩＤと、決済種別データと、決済限度額データとを対応付けて記憶する。そして、ユーザＩＤによる決済リクエストであって、決済種別データを識別する決済種別認識コードと、この決済種別データに対応する決済限度額データとを受信した際に、記憶した決済種別データと同一の決済種別であって、かつこの決済種別データに対応した決済限度額データが決済データ記憶手段に記憶された決済限度額内である場合にのみ、決済を実行する。また、クレジット管理サーバは、記憶した決済種別データと、決済限度額データとを編集する。また、記憶したユーザＩＤと、決済種別データと、決済限度額データとに有効期限を設定し、この行こう期限を超えた場合、記憶したユーザＩＤと、決済種別データと、決済限度額データとを削除する。また、受信した決済種別が、記憶した決済限度額データと同一の決済種別であり、かつ受信した決済限度額データが記憶した決済限度額外である場合、アラート通知をユーザ端末に送信する。

［クレジット管理システムの概要］
図１に基づいて、本発明の好適な実施形態であるクレジット管理システム１の概要について説明する。

最初に、クレジット管理サーバ１０は、ユーザ端末１００のユーザＩＤと、このユーザ端末１００により入力された決済の種別を決める決済種別データと、この決済種別データに対応した決済の限度額を示す決済限度額データとを、ユーザ端末１００から受信する（ステップＳ０１）。クレジット管理サーバ１０は、この受信したユーザＩＤと、決済種別データと、決済限度額データとを対応付けて記憶する。

次に、クレジット管理サーバ１０は、決済端末６に読み取られたユーザ端末１００のユーザＩＤを受信し、このユーザＩＤが記憶しているユーザＩＤであるか否かを判断することにより、記憶しているユーザＩＤからのリクエストであるか否かを判断する。受信したユーザＩＤが記憶しているユーザＩＤであると判断した場合、このユーザＩＤに対応するユーザ端末１００からのリクエストを受け付け、このリクエストに含まれる決済種別データを識別する決済種別認識コードと、この決済種別データに対応する決済限度額データとを受信した際に（ステップＳ０２）、記憶した決済種別データと同一の決済種別であって、かつこの決済種別データに対応した決済限度額データが記憶された決済限度額内であるか否かを判断する。

次に、クレジット管理サーバ１０は、今回のリクエストが、記憶した決済種別データと同一の決済種別であって、かつこの決済種別データに対応した決済限度額データが記憶された決済限度額内であると判断した場合、決済サーバ５に対して、決済の手続の依頼を送信する（ステップＳ０３）。

決済サーバ５は、クレジット管理サーバ１０からの依頼に基づいて、決済処理を実行する。

［クレジット管理処理のシステム構成］
図２は、クレジット管理システム１のシステム構成を示す図である。クレジット管理システム１は、決済サーバ５、決済端末６、クレジット管理サーバ１０、ユーザ端末１００と、インターネット網等の公衆回線網３から構成される。決済サーバ５、決済端末６、クレジット管理サーバ１０は、公衆回線網３を介して通信可能に接続されている。また、クレジット管理サーバ１０とユーザ端末１００とは、公衆回線網３を介して通信可能に接続されている。なお、クレジット管理サーバ１０は、ローカルエリアネットワークにより、決済サーバ５、決済端末６及びユーザ端末１００と通信可能に接続されていても良い。さらに、ローカルエリアネットワークが公衆回線網３と通信可能に接続されて、決済サーバ５及び決済端末６が、クレジット管理サーバ１０に通信可能に接続されていても良い。

決済サーバ５は、金融機関、クレジットカード会社又は電子マネーのサービス会社のサーバ等である。この決済サーバ５は、一般的なサーバや、クラウド型のサーバであっても良い。

決済端末６は、非接触式カードリーダ／ライタ、接触式カードリーダ／ライタ、ＩＣチップリーダ／ライタ又はマルチメディア端末等である。

クレジット管理サーバ１０及びユーザ端末１００は、ソフトウェア的又はハードウェア的な設定により、後述する機能を備える情報機器である。例えば、クレジット管理サーバ１０及びユーザ端末１００は、サーバ、パソコン、携帯電話、スマートフォン、スレート端末、表示機能付き電話機、ネットブック端末、電子書籍端末等の一般的な情報機器であって良い。

［各機能の説明］
図３に基づいて、各装置の構成について説明する。クレジット管理サーバ１０は、制御部１１として、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等を備え、通信部１２として、決済サーバ５、決済端末６及びユーザ端末１００と通信可能にするためのデバイス、例えば、ＩＥＥＥ８０２．１１に準拠したＷｉ−Ｆｉ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）対応デバイスを備える。加えて、クレジット管理サーバ１０は、データやファイルを記憶する記憶部１３として、ハードディスクや半導体メモリ、記録媒体、メモリカード等による、データのストレージ部を備える。記憶部１３は、後述するデポジット情報テーブル（図７参照）、決済種別認識コードテーブル（図８参照）、決済駅別テーブル（図９参照）及び決済地域別テーブル（図１０参照）を記憶する。

クレジット管理サーバ１０において、制御部１１が所定のプログラムを読み込むことで、通信部１２と協働して、ユーザＩＤ受信モジュール２０、決済データ受信モジュール２１、決済判断モジュール２２、編集データ送受信モジュール２３を実現する。また、クレジット管理サーバ１０において、制御部１１が所定のプログラムを読み込むことで、記憶部１３と協働して、決済データ記憶モジュール３０、編集モジュール３１、有効期限設定モジュール３２、削除モジュール３３を実現する。

ユーザ端末１００は、クレジット管理サーバ１０と同様に、制御部１１０として、ＣＰＵ、ＲＡＭ、ＲＯＭ等を備え、通信部１２０として、クレジット管理サーバ１０と通信可能にするためのデバイス、例えば、ＩＥＥＥ８０２．１１に準拠したＷｉ−Ｆｉ対応デバイスを備える。

ユーザ端末１００は、データやファイルを記憶する記憶部１２０として、ハードディスクや半導体メモリ、記録媒体、メモリカード等による、データのストレージ部を備える。記憶部１２０には、決済依頼するための設定データが記憶されており、例えば、決済依頼するためのアプリケーション設定に関するデータが記述されたアプリ設定データ、Ｗｉ−Ｆｉ等の通信設定に関するデータが記述された通信設定データ、オペレーティングシステム（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）の設定に関するデータが記述された設定データが記憶されている。また、ユーザ端末１００の決済依頼するための決済依頼プログラムが記憶されていても良い。

ユーザ端末１００は、表示部として、制御部１１０で制御したデータや画像、例えば、デポジット表示画面（図１１及び図１２参照）、デポジット編集画面（図１３参照）、決済完了画面（図１４参照）及びアラート表示画面（図１５、図１６及び図１７参照）を出力表示する出力部を備える。出力部としては、通常のモニタ、タッチパネル等であっても良い。ユーザ端末１００は、入力部として、ユーザの操作を受け付ける入力部を備える。入力部としては、通常のキーボード、マウス、タッチパネル等であっても良い。

ユーザ端末１００において、制御部１１０が所定のプログラムを読み込むことで、通信部１２０と協働して、ユーザＩＤ送信モジュール２００、決済データ送信モジュール２１０、アプリケーションモジュール２２０、決済データ編集モジュール２３０を実現する。

決済端末６は、クレジット管理サーバ１０やユーザ端末１００と同様に、制御部４０として、ＣＰＵ、ＲＡＭ、ＲＯＭ等を備え、通信部４１として、クレジット管理サーバ１０と通信可能にするためのデバイス、例えば、ＩＥＥＥ８０２．１１に準拠したＷｉ−Ｆｉ対応デバイスを備える。

決済端末６は、表示部として、制御部４０で制御したデータや画像を出力表示する出力部を備えていても良い。出力部としては、通常のモニタ、タッチパネル等であっても良い。入力部として、ユーザの操作を受け付ける入力部を備えていても良い。入力部としては、通常のキーボード、マウス、タッチパネル等であっても良い。

決済端末６は、データやファイルを記憶する記憶部として、ハードディスクや半導体メモリ、記録媒体、メモリカード等によるデータのストレージ部を備えていても良い。Ｗｉ−Ｆｉ等の通信設定に関するデータが記述された通信設定データ、オペレーティングシステム（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）の設定に関するデータが記述された設定データが記憶されていても良い。

決済端末６において、制御部４０が所定のプログラムを読み込むことで、通信部４１と協働して、リクエスト読取モジュール４００、リクエスト送信モジュール４１０を実現する。

なお、決済端末６は、マルチメディア端末や、リーダ／ライタと電子機器とが接続された端末であっても良い。この場合、リーダ／ライタで読み取った情報を電子機器に一度送信し、電子機器からクレジット管理サーバ１０に必要な情報を送信する構成にしても良い。また、リーダ／ライタで読み取った情報を直接クレジット管理サーバ１０に送信しても良い。

決済サーバ５は、クレジット管理サーバ１０、ユーザ端末１００及び決済端末６と同様に、制御部５０として、ＣＰＵ、ＲＡＭ、ＲＯＭ等を備え、通信部５１として、クレジット管理サーバ１０と通信可能にするためのデバイス、例えば、ＩＥＥＥ８０２．１１に準拠したＷｉ−Ｆｉ対応デバイスを備える。

決済サーバ５において、制御部５０が所定のプログラムを読み込むことで、通信部５１と協働して、決済実行モジュール５００を実現する。

［クレジット管理処理］
図４は、ユーザ端末１００、クレジット管理サーバ１０、決済端末６及び決済サーバ５が実行するクレジット管理処理のフローチャートである。ユーザは、ユーザ端末１００を操作することにより、デポジットする金額の限度額と決済種別とを指定するためのアプリケーションを起動する。ユーザ端末１００のアプリケーションモジュール２２０は、このアプリケーションを起動し、クレジット管理サーバ１０との通信を開始する（ステップＳ１０）。ユーザ端末１００のアプリケーションモジュール２２０は、このアプリケーションを、表示部に図１１及び図１２に示す画面として表示する。

ユーザは、ユーザ端末１００を操作し、「決済種別」の項目と、「預金額」の項目とを入力する（ステップＳ１１）。

図１１及び図１２は、デポジット表示画面を示す図である。図１１において、「決済種別」の項目には、「図書」が入力されている。また、「預金額」の項目には、「５０，０００円」が入力されている。図１２において、「決済種別」の項目には、「交通費」が入力されている。また、「預金額」の項目には、「６，０００円」が入力されている。なお、各項目の入力は、ユーザが直接入力しても良いし、各項目に用意された内容をユーザが選択しても良い。

本実施形態における「決済種別」とは、使用用途を意味する。具体的には、「決済種別」として「図書」である場合には、書店での使用や書籍類の購入のみに使用可能であることを意味し、それ以外の場合では使用できないことを意味する。また、「決済種別」として「交通費」である場合には、電車、タクシー、バス又は飛行機等の公共交通機関や、自家用車に使用するガソリン等の費用にのみ使用可能であることを意味し、それ以外の場合では使用できないことを意味する。また、「預金額」とは、限度額を意味する。具体的には、入力された金額以上の額を支払うことができないことを意味する。

すなわち、図１１の例では、「決済種別」が「図書」であり、「預金額」が「５０，０００円」であることから、書店での使用や書籍の購入のみに、５０，０００円を使用できることを意味する。また、図１２の例では、「決済種別」が「交通費」であり、「預金額」が「６，０００円」であることから、公共交通機関やガソリンの費用のみに、６，０００円を使用できることを意味する。

なお、「決済種別」に入力される内容は、他の項目であっても良く、例えば「医療費」、「食費」、「接待費」、「衣服費」といった項目であっても良い。また、入力される金額も、各内容に合わせて随時変更すれば良い。

ユーザ端末１００のユーザＩＤ送信モジュール２００は、自身のユーザＩＤをクレジット管理サーバ１０に送信する。同時に、ユーザ端末１００の決済データ送信モジュール２１０は、ステップＳ１１において入力された決済種別を示す決済種別データと、預金額として入力された決済の限度額を示す決済限度額データとをクレジット管理サーバ１０に送信する。すなわち、ユーザ端末１００のユーザＩＤ送信モジュール２００が、自身のユーザＩＤを送信するとともに、決済データ送信モジュール２１０が、決済種別データ及び決済限度額データをクレジット管理サーバ１０に送信する（ステップＳ１２）。

ステップＳ１２においてユーザＩＤ送信モジュール２００が送信するユーザＩＤとは、ユーザ端末１００の機種名、メーカ名等のユーザ端末１００の種別を識別する情報や、電話番号やＳＩＭ ＩＤ等のユーザ端末１００を識別する情報である。また、事前にユーザ端末１００毎に付与した、ユーザ端末１００を識別する情報であっても良い。すなわち、ユーザＩＤとは、各ユーザ端末１００を識別するための情報であれば良い。

次に、クレジット管理サーバ１０は、ユーザ端末１００から送信されたユーザＩＤ、決済種別データ及び決済限度額データを受信する（ステップＳ１３）。ステップＳ１３において、クレジット管理サーバ１０のユーザＩＤ受信モジュール２０は、ユーザ端末１００から送信されたユーザＩＤを受信する。また、ステップＳ１３において、クレジット管理サーバ１０の決済データ受信モジュール２１は、ユーザ端末１００から送信された決済種別データ及び決済限度額データを受信する。

クレジット管理サーバ１０の決済データ記憶モジュール３０は、ユーザ端末１００から受信したユーザＩＤと、決済種別データと、決済限度額データとを対応付けて記憶する。

［デポジット情報テーブル］
図７は、クレジット管理サーバ１０の決済データ記憶モジュール３０が記憶するデポジット情報テーブルである。デポジット情報テーブルは、ユーザＩＤと、決済種別データと、決済限度額データとを対応付けて登録している。図７において、クレジット管理サーバ１０の決済データ記憶モジュール３０は、ユーザＩＤに「Ａ０１−０００１」、決済種別データに「図書費」、決済限度額データに「５０，０００」を登録する。また、クレジット管理サーバ１０の決済データ記憶モジュール３０は、ユーザＩＤに「Ａ０１−０００１」、決済種別データに「交通費」、決済限度額データに「６，０００」を登録する。このように、クレジット管理サーバ１０の決済データ記憶モジュール３０は、単一のユーザが登録した決済種別データと決済限度額データとを登録する。なお、クレジット管理サーバ１０の決済データ記憶モジュール３０は複数のユーザが登録した決済種別データと決済限度額データとを各ユーザに対応付けて記憶させていても良い。

［編集処理］
ここで、ユーザ端末１００が行う決済種別データと決済限度額データとの編集処理について説明する。本処理は、ユーザが任意のタイミングで実行することができる。

ユーザ端末１００のアプリケーションモジュール２２０は、ユーザからの入力に基づいて、以前に登録した決済種別と決済限度額データとの編集要求が行われたか否かを判断する。ここで、アプリケーションモジュール２２０が、ユーザからの編集要求が行われていないと判断した場合、本処理を終了する。

アプリケーションモジュール２２０が、ユーザからの編集要求が行われたと判断した場合、ユーザ端末１００の決済データ編集モジュール２３０は、クレジット管理サーバ１０に対して編集要求を送信する。クレジット管理サーバ１０の編集データ送受信モジュール２３は、ユーザ端末１００からの編集要求を受信する。

クレジット管理サーバ１０の編集モジュール３１は、受信した編集要求に基づいて、この編集要求に含まれるユーザＩＤを取得する。同時に、この編集要求に含まれる決済種別又は決済限度額データの情報を取得する。クレジット管理サーバ１０の編集モジュール３１は、このユーザＩＤと、決済種別又は決済限度額データとに基づいて、編集対象とするデータをデポジット情報テーブルから検索する。クレジット管理サーバ１０の編集データ送受信モジュール２３は、検索した決済種別及び決済限度額データを編集データとしてユーザ端末１００に送信する。

ユーザ端末１００の決済データ編集モジュール２３０は、クレジット管理サーバ１０から編集データを受信し、図１３に示すデポジット編集画面をユーザ端末１００の出力部に表示する。

ユーザは、ユーザ端末１００に表示された、「決済種別」の項目又は「預金額」の項目を再度入力することにより編集することができる。編集が完了すると、ユーザ端末１００の決済データ編集モジュール２３０は、編集が完了した編集完了データをクレジット管理サーバ１０に送信する。

クレジット管理サーバ１０の編集データ送受信モジュール２３は、ユーザ端末１００から送信された編集完了データを受信する。クレジット管理サーバ１０の編集モジュール３１は、受信した編集完了データのユーザＩＤと、決済種別と、決済限度額データとを再度対応付けて記憶する。ここで、クレジット管理サーバ１０の編集モジュール３１は、編集が行われる以前のデータの、編集が行われた項目のみを上書きして記憶する。なお、編集が行われる以前のデータを削除して、編集完了データを新たに記憶しても良い。

［削除処理］
次に、クレジット管理サーバ１０が実行するユーザＩＤ、決済種別データ及び決済限度額データの削除処理について説明する。本処理は、後述するユーザ端末１００からの削除要求を受け付けた場合や、設定した有効期限を超過した場合に実行される

クレジット管理サーバ１０の編集データ送受信モジュール２３は、ユーザ端末１００の決済データ編集モジュール２３０から送信された削除要求を受け付ける。この削除要求には、削除要求を送信したユーザ端末１００のユーザＩＤが含まれる。

クレジット管理サーバ１０の削除モジュール３３は、受け付けた削除要求に含まれるユーザＩＤを取得する。クレジット管理サーバ１０の削除モジュール３３は、取得したユーザＩＤに対応付けられた決済種別データ及び決済限度額データをデポジット情報テーブルに基づいて検索する。クレジット管理サーバ１０の削除モジュール３３は、検索した決済種別データ及び決済限度額データをデポジット情報テーブルから削除する。

また、クレジット管理サーバ１０の有効期限設定モジュール３２は、デポジット情報テーブルにおいて、ユーザＩＤと、決済種別データと、決済限度額データとに加えて有効期限を対応付けて設定する。クレジット管理サーバ１０の削除モジュール３３は、この有効期限を超過したと判断した場合、この有効期限が設定されたユーザＩＤと、決済種別データと、決済限度額データとを削除する。なお、本実施形態における有効期限とは、例えば、所定の日時や、時間や、期間である。また、その他の期限であっても良い。

次に、ユーザは、電子決済を行う場合、アプリケーションを起動し、リクエストを送信する（ステップＳ１５）。ステップＳ１５において、ユーザ端末１００のアプリケーションモジュール２２０は、決済リクエストを決済端末６に対して送信する。アプリケーションモジュール２２０が送信する決済リクエストには、ユーザＩＤ、決済種別認識コード及び決済額データが含まれている。

この決済リクエストに含まれているユーザＩＤとは、上述したユーザＩＤと同様のものである。また、この決済リクエストに含まれている決済種別認識コードとは、後述する決済種別認識コードテーブルに登録されているコードデータである。また、この決済リクエストに含まれている決済額データとは、決済に必要な金額を示すデータである。

決済端末６のリクエスト読取モジュール４００は、ユーザ端末１００からの決済リクエストを受信し、決済リクエストの内容を読み取る（ステップＳ１６）。決済端末６のリクエスト送信モジュール４１０は、読み取った決済リクエストをクレジット管理サーバ１０に送信する（ステップＳ１７）。

次に、クレジット管理サーバ１０の決済判断モジュール２２は、決済端末６が送信した決済リクエストを受信する（ステップＳ１８）。

次に、クレジット管理サーバ１０の決済判断モジュール２２は、受信した決済リクエストに含まれているユーザＩＤ、決済種別認識コード及び決済額データが決済データ記憶モジュール３０に記憶している決済データ内であるか否かを判断する（ステップＳ１９）。ステップＳ１９において、クレジット管理サーバ１０の決済判断モジュール２２は、ユーザＩＤがデポジット情報テーブルに記録されているか否かを判断する。同時に、クレジット管理サーバ１０の決済判断モジュール２２は、決済種別認識コードが図８に示す決済種別認識コードテーブルに登録されているか否かを判断する。加えて、クレジット管理サーバ１０の決済判断モジュール２２は、決済額データが、デポジット情報テーブルにおいて、決済種別コードに対応する決済種別データに対応付けられた決済限度額データ内であるか否かを判断する。

［決済種別認識コードテーブル］
図８は、クレジット管理サーバ１０が記憶する決済種別認識コードテーブルを示す図である。図８において、カテゴリと決済種別認識コードとが対応付けて登録されている。具体的には、カテゴリが「図書」である決済種別認識コードは、「Ａ００００５」、「Ａ００００７」、「Ｂ００００８」及び「Ｂ４４５５５」である。また、カテゴリが「交通費」である決済種別認識コードは、「Ｃ１０００１」、「Ｃ１０００４」、「Ｄ１０００８」及び「Ｄ６６７７７」である。この決済種別認識コードは、商品やサービスに対して紐付けられたコードである。

ステップＳ１９において、クレジット管理サーバ１０の決済判断モジュール２２は、受信した決済リクエストに含まれるユーザＩＤが、デポジット情報テーブルに登録されたユーザＩＤであり、受信した決済リクエストに含まれる決済種別認識コードが、決済種別認識コードテーブルに登録されている決済種別認識コードであり、かつ、受信した決済リクエストに含まれる決済額データが、この決済種別認識コードに対応した決済種別データに対応付けられた決済限度額データ以内であると判断した場合（ステップＳ１９ ＹＥＳ）、後述する決済処理を実行する（ステップＳ２０）。

ステップＳ１９において、クレジット管理サーバ１０の決済判断モジュール２２は、受信した決済リクエストに含まれるユーザＩＤが、デポジット情報テーブルに登録されているユーザＩＤと異なると判断した場合（ステップＳ１９ ＮＯ）、後述するアラート処理を実行する（ステップＳ２１）。また、クレジット管理サーバ１０の決済判断モジュール２２は、受信した決済リクエストに含まれるユーザＩＤがデポジット情報テーブルに登録されているものの、受信した決済リクエストに含まれる決済種別認識コードが、決済種別認識コードテーブルに登録されている決済種別認識コードとは異なると判断した場合（ステップＳ１９ ＮＯ）、後述するアラート処理を実行する（ステップＳ２１）。また、クレジット管理サーバ１０の決済判断モジュール２２は、受信した決済リクエストに含まれるユーザＩＤがデポジット情報テーブルに登録されており、受信した決済リクエストに含まれる決済種別認識コードが、決済種別認識コードテーブルに登録されているものの、受信した決済リクエストに含まれる決済額データが、この決済種別認識コードに対応した決済種別データに対応付けられた決済限度額データよりも大きいと判断した場合（ステップＳ１９ ＮＯ）、後述するアラート処理を実行する（ステップＳ２１）。すなわち、クレジット管理サーバ１０の決済判断モジュール２２は、ユーザＩＤ、決済種別認識コード又は決済限度額データのいずれかを満たさない場合、アラート処理を実行する。

［決済処理］
図５は、ユーザ端末１００、クレジット管理サーバ１０、決済端末６及び決済サーバ５が実行する決済処理のフローチャートである。

クレジット管理サーバ１０の決済判断モジュール２３は、今回受信した決済リクエストに含まれるユーザＩＤ及び決済額データを決済処理依頼データとして決済サーバ５に送信するとともに、決済処理依頼を送信する（ステップＳ３０）。

決済サーバ５の決済実行モジュール５００は、クレジット管理サーバ１０が送信した決済依頼データに基づいて、ユーザ端末１００のユーザＩＤに対応するユーザへの決済処理を実行する（ステップＳ３２）。ステップＳ３２における、決済実行モジュール５００が実行する決済処理とは、例えば、対象とするユーザの銀行口座から今回の決済額を徴収する処理や、クレジットカード会社による与信払いを行う処理である。

決済サーバ５の決済実行モジュール５００は、決済処理が完了したことを示す決済完了通知をクレジット管理サーバ１０に送信する（ステップＳ３３）。

クレジット管理サーバ１０の決済判断モジュール２２は、決済完了通知を決済サーバ５から受信する（ステップＳ３４）。

次に、クレジット管理サーバ１０の決済判断モジュール２２は、ユーザ端末１００に決済完了通知を送信する（ステップＳ３５）。

ユーザ端末１００のアプリケーションモジュール２２０は、クレジット管理サーバ１０から決済完了通知を受信する（ステップＳ３６）。

ユーザ端末１００のアプリケーションモジュール２２０は、クレジット管理サーバ１０から受信した決済完了通知を図１４に示す決済完了通知画面として出力部に表示する（ステップＳ３７）。ステップＳ３７において、ユーザ端末１００のアプリケーションモジュール２２０は、決済が完了した旨を出力部に表示する。以上で、決済処理を終了する。ユーザ端末１００が、次に決済リクエストを送信するまで、クレジット管理サーバ１０、決済端末６及び決済サーバ５は、待機する。

［アラート処理］
図６は、ユーザ端末１００、クレジット管理サーバ１０、決済端末６及び決済サーバ５が実行するアラート処理のフローチャートである。

クレジット管理サーバ１０の決済判断モジュール２２は、決済処理を中止する（ステップＳ４０）。ステップＳ４０において、クレジット管理サーバ１０の決済判断モジュール２２は、決済依頼処理を決済サーバ５に対して送信せず、以降の決済を停止するとともに、決済停止通知を生成する。

ステップＳ４０において、クレジット管理サーバ１０の決済判断モジュール２２は、決済処理を中止した理由が、ユーザＩＤが登録されていないと判断した場合には、ユーザＩＤが登録されていないことを示す旨のユーザＩＤ未登録メッセージを生成する。また、クレジット管理サーバ１０の決済判断モジュール２２は、決済処理を中止した理由が、決済種別認識コードが登録されていないと判断した場合には、決済種別認識コードが登録されていないことを示す旨の決済種別認識コード未登録メッセージを生成する。また、クレジット管理サーバ１０の決済判断モジュール２２は、決済処理を中止した理由が、決済額データが、登録された決済限度額を超過していると判断した場合には、決済限度額を超過していることを示す旨の決済限度額超過メッセージを生成する。

次に、クレジット管理サーバ１０の決済判断モジュール２２は、生成した決済停止通知をユーザ端末１００に送信する（ステップＳ４１）。

ユーザ端末１００のアプリケーションモジュール２２０は、クレジット管理サーバ１０から決済停止通知を受信する（ステップＳ４２）。

ユーザ端末１００のアプリケーションモジュール２２０は、受信した決済停止通知を図１５、図１６及び図１７に示すアラート通知画面として表示部に表示する（ステップＳ４３）。ステップＳ４２において、受信した決済停止通知が、ユーザＩＤ未登録メッセージである場合、ステップＳ４３において、ユーザ端末１００の表示部は、図１５に示すユーザＩＤ未登録通知画面を表示する。ステップＳ４２において受信した決済停止通知が、決済種別認識コード未登録メッセージである場合には、ステップＳ４３において、ユーザ端末１００の表示部は、図１６に示す決済種別認識コード未登録通知画面を表示する。ステップＳ４２において受信した決済停止通知が、決済限度額超過メッセージである場合には、ステップＳ４３において、ユーザ端末１００の表示部は、図１７に示す決済限度額超過通知画面を表示する。以上で、アラート処理を終了する。ユーザ端末１００が、次に決済リクエストを送信するまで、クレジット管理サーバ１０、決済端末６及び決済サーバ５は、待機する。

また、上述したデポジット情報テーブルに加えて、図９及び図１０に示すテーブルをクレジット管理サーバ１０の決済データ記憶モジュール３０は記憶しても良い。

上述した実施形態において、クレジット管理サーバ１０の決済データ記憶モジュール３０が記憶するテーブルは、デポジット情報テーブルであったが、代わりに、後述する決済駅別テーブルを記憶していても良い。この場合について、説明する。

［決済駅別テーブル］
図９は、クレジット管理サーバ１０の決済データ記憶モジュール３０が記憶する決済駅別テーブルを示す図である。

クレジット管理サーバ１０の決済データ記憶モジュール２０が決済駅別テーブルを記憶する場合、ユーザ端末１００、クレジット管理サーバ１０、決済端末６及び決済サーバ５が実行する各処理は、上述したクレジット管理処理、決済処理及びアラート処理と略同様である。したがって、相違点について説明する。

ステップＳ１１において、ユーザは、ユーザ端末１００を操作し、「決済種別」の項目と、「最寄駅１」の項目と、「最寄駅２」の項目と、「決済限度額データ」の項目と、「上限回数」の項目とを入力する。

図９において、決済駅別テーブルには、ユーザＩＤと、決済種別データと、最寄駅１と、最寄駅２と、決済限度額データと、上限回数とが対応付けられて登録されている。図９において、「ユーザＩＤ」は、「Ａ０１−０００１」であり、「決済種別データ」は、「交通費」であり、「最寄駅１」は、「ＡＡＡＡＡ」であり、「最寄駅２」は、「ＢＢＢＢＢ」であり、「決済限度額データ」は、「１，０００」であり、「上限回数」は「２」である。

本実施形態における「決済種別」とは、上述した「決済種別」と同様である。また、「最寄駅１」及び「最寄駅２」とは、ユーザが指定する駅名を意味する。具体的には、指定した駅以外の駅での使用はできないことを意味する。また、「決済限度額データ」とは、上述した「決済限度額データ」と同様である。また、「上限回数」とは、所定の期間において使用できる回数を指定することを意味する。例えば、一日の使用回数や、一週間の使用回数や、一月の使用回数、あるいはそれ以外の期間であっても良い。

すなわち、図９の例では、駅名「ＡＡＡＡＡ」又は駅名「ＢＢＢＢＢ」においてのみ、所定の期間の間に「２」回まで限度額「１，０００」円まで使用できることを意味している。なお、各項目に入力される内容は、他の項目であっても良く、入力される金額も、各内容に合わせて随時変更して良い。また、単一のユーザＩＤが複数登録されていても良いし、複数のユーザＩＤが登録されていても良い。

ステップＳ１２において、ユーザ端末１００の決済データ送信モジュール２１０が、決済種別データ、決済限度額データに加え、最寄駅１のデータ、最寄駅２のデータ及び上限回数のデータをクレジット管理サーバ１０に送信する。ステップＳ１３において、クレジット管理サーバ１０は、受信した決済種別データ、決済限度額データ、最寄駅１のデータ、最寄駅２のデータ及び上限回数のデータを受信し、ステップＳ１４において、クレジット管理サーバ１０の決済データ記憶モジュール３０は、受信したこれらを対応付けて記憶する。

ステップＳ１５において、ユーザ端末１００のアプリケーションモジュール２２０が送信する決済リクエストには、ユーザＩＤ、決済種別認識コード、決済額データに加え、駅データ及び使用回数データが含まれている。ユーザＩＤ、決済種別認識コード及び決済額データは、上述したものと同様である。駅データとは、使用した駅名を含んだデータである。また、使用回数データとは、所定期間内における使用回数を含んだデータである。

ステップＳ１９において、クレジット管理サーバ１０の決済判断モジュール２２は、受信した決済リクエストに含まれているユーザＩＤ、決済種別認識コード及び決済額データに加えて、駅データ及び使用回数データが決済データ記憶モジュール３０に記憶している決済データ内であるか否かを判断する。

ステップＳ１９において、クレジット管理サーバ１０の決済判断モジュール２２は、ユーザＩＤが決済駅別テーブルに記録されているか否かを判断する。また、クレジット管理サーバ１０の決済判断モジュール２２は、決済種別認識コードが図８に示す決済種別認識コードテーブルに登録されているか否かを判断する。また、クレジット管理サーバ１０の決済判断モジュール２２は、決済額データが、決済限度額データ内であるか否かを判断する。さらに、クレジット管理サーバ１０の決済判断モジュール２２は、駅データが決済駅別テーブルに登録されている駅名と一致するか否かを判断する。さらに、クレジット管理サーバ１０の決済判断モジュール２２は、使用回数のデータが、決済駅別テーブルに登録されている上限回数以内であるか否かを判断する。

ステップＳ１９において、クレジット管理サーバ１０の決済判断モジュール２２は、受信した決済リクエストに含まれるユーザＩＤが、決済駅別テーブルに登録されたユーザＩＤであり、受信した決済リクエストに含まれる決済種別認識コードが、決済種別認識コードに登録されている決済種別認識コードであり、受信した決済リクエストに含まれる決済額データが、決済駅別テーブルに登録されている決済限度額データ内であり、受信した決済リクエストに含まれる駅データが、決済駅別テーブルに登録されている最寄駅１又は最寄駅２の駅名と一致し、かつ、受信した決済リクエストに含まれる使用回数データが決済駅別テーブルの上限回数以内であると判断した場合、上述した決済処理を実行する。

ステップＳ１９において、クレジット管理サーバ１０の決済判断モジュール２２は、受信した決済リクエストに含まれるユーザＩＤが、決済駅別テーブルに登録されているユーザＩＤと異なると判断した場合、上述したアラート処理を実行する。また、クレジット管理サーバ１０の決済判断モジュール２２は、受信した決済リクエストに含まれる決済種別認識コードが、決済種別認識コードテーブルに登録されている決済種別認識コードとは異なると判断した場合、上述したアラート処理を実行する。また、クレジット管理サーバ１０の決済判断モジュール２２は、受信した決済リクエストに含まれる決済額データが、決済駅別テーブルに登録された決済限度額データよりも大きい場合、上述したアラート処理を実行する。また、クレジット管理サーバ１０の決済判断モジュール２２は、受信した決済リクエストに含まれる駅データが、決済駅別テーブルに登録された最寄駅１及び最寄駅２とは異なる場合、上述したアラート処理を実行する。また、クレジット管理サーバ１０の決済判断モジュール２２は、受信した決済リクエストに含まれる使用回数データが、決済駅別テーブルに登録された上限回数を超過していた場合、上述したアラート処理を実行する。

なお、決済駅別テーブルに登録する項目は、図９の各項目に限らず他の項目であっても良い。例えば、最寄駅ではなく、バス停や住所等であっても良い。また、上限回数も自由に設定されていても良い。

また、上述した実施形態において、クレジット管理サーバ１０の決済データ記憶モジュール３０が記憶するテーブルは、デポジット情報テーブルであったが、代わりに、後述する決済駅地域別テーブルを記憶していても良い。この場合について、説明する。

［決済地域別テーブル］
図１０は、クレジット管理サーバ１０の決済データ記憶モジュール３０が記憶する決済地域別テーブルを示す図である。

クレジット管理サーバ１０の決済データ記憶モジュール２０が決済地域別テーブルを記憶する場合、ユーザ端末１００、クレジット管理サーバ１０、決済端末６及び決済サーバ５が実行する各処理は、上述したクレジット管理処理、決済処理及びアラート処理と略同様である。したがって、相違点について説明する。

ステップＳ１１において、ユーザは、ユーザ端末１００を操作し、「決済種別」の項目と、「地域１」の項目と、「地域２」の項目と、「決済限度額データ」の項目と、「日付」の項目とを入力する。

図１０において、決済地域別テーブルには、ユーザＩＤと、決済種別データと、地域１と、地域２と、決済限度額データと、日付とが対応付けられている。図１０において、「ユーザＩＤ」は、「Ａ０１−０００１」であり、「決済種別データ」は、「交通費」であり、「地域１」は、「ＣＣＣＣＣ」であり、「地域２」は、「ＤＤＤＤＤ」であり、「決済限度額データ」は、「１，０００」であり、「日付」は「２０１５／３／２４」である。

本実施形態における「決済種別」とは、上述した「決済種別」と同様である。また、「地域１」及び「地域２」とは、ユーザが指定する地域名を意味する。具体的には、指定した地域以外の地域での使用はできないことを意味する。また、「決済限度額データ」とは、上述した「決済限度額データ」と同様である。また、「日付」とは、使用可能な日付を指定することを意味する。なお、日付とは、特定の日付に限らず、所定の期間であっても良い。

すなわち、図９の例では、地域名「ＣＣＣＣＣ」又は地域名「ＤＤＤＤＤ」においてのみ、「２０１５／３／２４」のみ、限度額「５０，０００」円まで使用できることを意味している。なお、各項目に入力される内容は、他の項目であっても良く、入力される金額も、各内容に合わせて随時変更して良い。また、単一のユーザＩＤが複数登録されていても良いし、複数のユーザＩＤが登録されていても良い。

ステップＳ１２において、ユーザ端末１００の決済データ送信モジュール２１０が、決済種別データ、決済限度額データに加え、地域１データ、地域２データ及び日付データをクレジット管理サーバ１０に送信する。ステップＳ１３において、クレジット管理サーバ１０は、受信した決済種別データ、決済限度額データ、地域１データ、地域２データ及び日付データを受信し、ステップＳ１４において、クレジット管理サーバ１０の決済データ記憶モジュール３０は、受信したこれらを対応付けて記憶する。

ステップＳ１５において、ユーザ端末１００のアプリケーションモジュール２２０が送信する決済リクエストには、ユーザＩＤ、決済種別認識コード、決済額データに加え、使用地域データ及び使用日時データが含まれている。ユーザＩＤ、決済種別認識コード及び決済額データは、上述したものと同様である。使用地域データとは、使用した地域名を含んだデータである。また、使用日時データとは、使用した日時を含んだデータである。

ステップＳ１９において、クレジット管理サーバ１０の決済判断モジュール２２は、受信した決済リクエストに含まれているユーザＩＤ、決済種別認識コード及び決済額データに加えて、使用地域データ及び使用日時データが決済データ記憶モジュール３０に記憶している決済データ内であるか否かを判断する。

ステップＳ１９において、クレジット管理サーバ１０の決済判断モジュール２２は、ユーザＩＤが決済地域別テーブルに記録されているか否かを判断する。また、クレジット管理サーバ１０の決済判断モジュール２２は、決済種別認識コードが図８に示す決済種別認識コードテーブルに登録されているか否かを判断する。また、クレジット管理サーバ１０の決済判断モジュール２２は、決済額データが、決済限度額データ内であるか否かを判断する。さらに、クレジット管理サーバ１０の決済判断モジュール２２は、使用地域データが決済地域別テーブルに登録されている地域名と一致するか否かを判断する。さらに、クレジット管理サーバ１０の決済判断モジュール２２は、使用日時データが、決済地域別テーブルに登録されている日付であるか否かを判断する。

ステップＳ１９において、クレジット管理サーバ１０の決済判断モジュール２２は、受信した決済リクエストに含まれるユーザＩＤが、決済地域別テーブルに登録されたユーザＩＤであり、受信した決済リクエストに含まれる決済種別認識コードが、決済種別認識コードに登録されている決済種別認識コードであり、受信した決済リクエストに含まれる決済額データが、決済地域別テーブルに登録されている決済限度額データ内であり、受信した決済リクエストに含まれる使用地域データが、決済地域別テーブルに登録されている地域１又は地域２の地域名と一致し、かつ受信した決済リクエストに含まれる使用日時データが決済地域別テーブルの日付であると判断した場合、上述した決済処理を実行する。

ステップＳ１９において、クレジット管理サーバ１０の決済判断モジュール２２は、受信した決済リクエストに含まれるユーザＩＤが、決済地域別テーブルに登録されているユーザＩＤと異なると判断した場合、上述したアラート処理を実行する。また、クレジット管理サーバ１０の決済判断モジュール２２は、受信した決済リクエストに含まれる決済種別認識コードが、決済種別認識コードテーブルに登録されている決済種別認識コードとは異なると判断した場合、上述したアラート処理を実行する。また、クレジット管理サーバ１０の決済判断モジュール２２は、受信した決済リクエストに含まれる決済額データが、決済地域別テーブルに登録された決済限度額データよりも大きい場合、上述したアラート処理を実行する。また、クレジット管理サーバ１０の決済判断モジュール２２は、受信した決済リクエストに含まれる使用地域データが、決済地域別テーブルに登録された地域１又は地域２とは異なる場合、上述したアラート処理を実行する。また、クレジット管理サーバ１０の決済判断モジュール２２は、受信した決済リクエストに含まれる使用日時データが、決済地域別テーブルに登録された日付でない場合、上述したアラート処理を実行する。

なお、決済地域別テーブルに登録する項目は、図１０の各項目に限らず他の項目であっても良い。例えば、地域名として、都道府県名や、市町村名、地区名又は住所を登録しても良い。

なお、クレジット管理サーバ１０の決済データ記憶モジュール３０が上述した決済駅別テーブルや決済地域別テーブル以外の他のテーブルを記憶していても良い。この場合、クレジット管理サーバ１０の決済データ記憶モジュール３０は、使用用途と、限度額とに、日付、使用地域、使用場所等のいずれか又は複数を対応付けて記憶させれば良い。さらに、クレジット管理サーバ１０の決済判断モジュール２２が、上述したステップＳ１９の判断処理において、指定された日付であるか否かの判断や、使用地域が指定された使用地域であるか否かの判断や、使用場所が指定された使用場所であるか否かの判断を実行することにより、決済処理又はアラート処理を実行すれば良い。

また、クレジット管理サーバ１０の決済データ記憶モジュール３０が、使用用途と、限度額とに、上述した項目以外の項目を登録した場合、登録した項目を満たすか否かの判断を実行することにより、決済処理又はアラート処理を実行しても良い。

また、クレジット管理サーバ１０の決済データ記憶モジュール３０は、デポジット情報テーブルに加えて、決済駅別テーブルや、決済地域別テーブルや、他のテーブルを記憶していても良い。この場合、上述した指定した内容をすべて満たす場合、決済処理を実行し、上述した指定した内容のいずれか一つでも満たさない場合、アラート処理を実行すれば良い。

また、上述した編集処理は、決済駅別テーブルや、決済地域別テーブルや、他のテーブルに対しても実行されて良い。この場合、登録されている項目の各内容を編集すれば良い。また、削除処理も、編集処理と同様に実行されて良い。

上述した手段、機能は、コンピュータ（ＣＰＵ、情報処理装置、各種端末を含む）が、所定のプログラムを読み込んで、実行することによって実現される。プログラムは、例えば、フレキシブルディスク、ＣＤ（ＣＤ−ＲＯＭなど）、ＤＶＤ（ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭなど）等のコンピュータ読取可能な記録媒体に記録された形態で提供される。この場合、コンピュータはその記録媒体からプログラムを読み取って内部記憶装置又は外部記憶装置に転送し記憶して実行する。また、そのプログラムを、例えば、磁気ディスク、光ディスク、光磁気ディスク等の記憶装置（記録媒体）に予め記録しておき、その記憶装置から通信回線を介してコンピュータに提供するようにしてもよい。

以上、本発明の実施形態について説明したが、本発明は上述したこれらの実施形態に限るものではない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施形態に記載されたものに限定されるものではない。

５ 決済サーバ、６ 決済端末、１０ クレジット管理サーバ、１００ ユーザ端末

Claims (6)

1. ユーザ端末からユーザを識別するユーザＩＤを受信するユーザＩＤ受信手段と、
   決済の種別を決める決済種別データと、当該決済種別データに対応した決済の限度額を示す決済限度額データとを受信する決済データ受信手段と、
   受信した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを対応付けて記憶する決済データ記憶手段と、
   前記ユーザＩＤによる決済リクエストであって、前記決済種別データを識別する決済種別認識コードと、当該決済種別データに対応する決済限度額データとを受信した際に、前記決済データ記憶手段に記憶された決済種別データと同一の決済種別であって、かつ当該決済種別データに対応した決済限度額データが前記決済データ記憶手段に記憶された決済限度額内である場合にのみ、決済を実行する決済判断手段と、
   を備えるクレジット管理サーバ。
2. 前記データ記憶手段に記憶した前記決済種別データと、前記決済限度額データとを編集する編集手段と、
   を備えた請求項１に記載のクレジット管理サーバ。
3. 前記データ記憶手段に記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとに有効期限を設定する有効期限設定手段と、
   前記有効期限設定手段により設定された有効期限を超えた場合、記憶した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを削除する削除手段と、
   を備えた請求項１又は２に記載のクレジット管理サーバ。
4. 前記決済判断手段は、前記決済データ記憶手段に記憶された決済限度額データと同一の決済種別であって、かつ前記決済種別データに対応した決済限度額データが前記決済データ記憶手段に記憶された決済限度額外である場合、アラート通知を前記ユーザ端末に送信する、請求項１乃至３のいずれか一項に記載のクレジット管理サーバ。
5. ユーザ端末からユーザを識別するユーザＩＤを受信するステップと、
   決済の種別を決める決済種別データと、当該決済種別データに対応した決済の限度額を示す決済限度額データとを受信するステップと、
   受信した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを対応付けて記憶するステップと、
   前記ユーザＩＤによる決済リクエストであって、前記決済種別データを識別する決済種別認識コードと、当該決済種別データに対応する決済限度額データとを受信した際に、前記決済データ記憶手段に記憶された決済種別データと同一の決済種別であって、かつ当該決済種別データに対応した決済限度額データが前記対応付けて記憶するステップにおいて記憶された決済限度額内である場合にのみ、決済を実行するステップと、
   を備えるクレジット管理方法。
6. ユーザ端末からユーザを識別するユーザＩＤを受信するステップ、
   決済の種別を決める決済種別データと、当該決済種別データに対応した決済の限度額を示す決済限度額データとを受信するステップ、
   受信した前記ユーザＩＤと、前記決済種別データと、前記決済限度額データとを対応付けて記憶するステップ、
   前記ユーザＩＤによる決済リクエストであって、前記決済種別データを識別する決済種別認識コードと、当該決済種別データに対応する決済限度額データとを受信した際に、前記決済データ記憶手段に記憶された決済種別データと同一の決済種別であって、かつ当該決済種別データに対応した決済限度額データが前記対応付けて記憶するステップにおいて記憶された決済限度額内である場合にのみ、決済を実行するステップ、
   をクレジット管理サーバに実行させるクレジット管理サーバ用プログラム。