JP2016224498A - プリペイドカード管理システム及びプリペイドカード管理方法 - Google Patents

Abstract

【課題】プリペイドカード会社を介した契約関係を結ばなくても、プリペイドカードの保有者間で簡単に決済処理が実行できるプリペイドカード管理システム及びプリペイドカード管理方法を提供する。【解決手段】第２のユーザＡ２が保有するプリペイドカード口座から第１のユーザＡ１が保有するプリペイドカード口座への送金処理をネットワーク上で行うに際し、第１のユーザＡ１から第２のユーザＡ２に対して発行された送金要求を取得し、送金要求と送金処理の条件とを比較する。この比較結果が所定の条件に該当するときには、前記第２のユーザＡ２に問い合わせることなく送金処理を実行する。【選択図】図３

Description

この発明は、ネットワーク上で行われる取引に用いられるプリペイドカード管理システム及びプリペイドカード管理方法に関し、特に、プリペイドカード保有者間の送金処理を容易化できるプリペイドカード管理システム及びプリペイドカード管理方法に関する。

従来、店舗での小口の決済方法としてプリペイド型の電子マネーが用いられている（例えば特許文献１参照）。従来のプリペイド型の電子マネーは、商品購入者が一般小売店などでプリペイドカード購入し、このプリペイドカードを商品販売店で使用し、残高に応じた買い物をする方法が一般的である。

また、こうしたプリペイドカードには、残高が少なくなったときにチャージして残高を増やせるもの、例えばインターネットバンキングなどの送金処理によってチャージできるものが存在する。

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

上記したように、プリペイドカードは小口の決済方法に適しているが、従来は一般ユーザが店舗等で決済を行うことを前提としたものであった。すなわち、商品購入者がプリペイドカードを使用すると、その金額を商品販売店がプリペイドカード会社に請求し、後日、プリペイドカード会社が商品販売店の金融機関に購入額を振り込むシステムであった。

しかしながら、このようなプリペイドカード会社を介した契約関係を結ばずに、より簡単に決済処理ができるようになれば、プリペイドカードの利用範囲は格段に拡大する。例えば、社内の経費精算や、クラウドソーシングのような個人への金銭の支払いを前提としたようなサービスにもプリペイドカードを使用することができる。このような簡易な決済処理にプリペイドカードを使用する場合、手続きの煩雑さをどの程度軽減できるかが重要となる。

そこで、本発明は、プリペイドカードの保有者間の決済処理を簡便に実行することができるプリペイドカード管理システム及びプリペイドカード管理方法を提供することを課題とする。

本発明は、上記した課題を解決するためになされたものであり、以下を特徴とする。

請求項１記載の発明は、第２のユーザが保有するプリペイドカード口座から第１のユーザが保有するプリペイドカード口座への送金処理をネットワーク上で行うためのプリペイドカード管理システムであって、第１のユーザから第２のユーザに対して発行された送金要求を取得する送金要求取得部と、前記送金要求に基づき送金処理を実行する送金処理部と、送金処理部による送金処理の条件を登録するための送金条件登録部と、を備え、前記送金処理部は、前記送金要求と前記送金条件登録部において指定された送金処理の条件とを比較し、この比較結果が所定の条件に該当するときには、前記第２のユーザに問い合わせることなく送金処理を実行することを特徴とする。

請求項２に記載の発明は、上記した請求項１に記載の発明の特徴点に加え、前記送金条件登録部は、前記送金処理の条件として、１回の送金処理における送金限度額を登録可能であることを特徴とする。

請求項３に記載の発明は、上記した請求項１又は２に記載の発明の特徴点に加え、前記送金条件登録部は、前記送金処理の条件として、一定期間における送金限度額を登録可能であることを特徴とする。

請求項４に記載の発明は、上記した請求項１〜３のいずれかに記載の発明の特徴点に加え、前記送金処理部は、前記送金要求と前記送金条件登録部において指定された送金処理の条件とを比較し、この比較結果が所定の条件に該当しないときには、前記第２のユーザが許可した場合に限り送金処理を実行することを特徴とする。

請求項５に記載の発明は、第２のユーザが保有するプリペイドカード口座から第１のユーザが保有するプリペイドカード口座への送金処理をネットワーク上で行うためのプリペイドカード管理方法であって、送金処理の条件を登録するステップと、第１のユーザから第２のユーザに対して発行された送金要求を取得するステップと、前記送金要求に基づき送金処理を実行するステップと、を備え、前記送金要求と前記送金処理の条件とを比較し、この比較結果が所定の条件に該当するときには、前記第２のユーザに問い合わせることなく送金処理を実行することを特徴とする。

請求項６に記載の発明は、上記した請求項５記載の発明の特徴点に加え、前記送金処理の条件として、１回の送金処理における送金限度額を登録可能であることを特徴とする。

請求項７に記載の発明は、上記した請求項５又は６記載の発明の特徴点に加え、前記送金処理の条件として、一定期間における送金限度額を登録可能であることを特徴とする。

請求項８に記載の発明は、上記した請求項５〜７のいずれかに記載の発明の特徴点に加え、前記送金要求と前記送金処理の条件とを比較し、この比較結果が所定の条件に該当しないときには、前記第２のユーザが許可した場合に限り送金処理を実行することを特徴とする。

請求項１及び５に記載の発明は上記の通りであり、第１のユーザから第２のユーザに対して発行された送金要求を取得し、送金要求と送金処理の条件とを比較し、この比較結果が所定の条件に該当するときには、前記第２のユーザに問い合わせることなく送金処理を実行する。すなわち、他のプリペイドカードの保有者から送金要求があったときに、その送金要求が予め定めた条件に合致する場合には自動的に送金が完了するようになっている。このような処理を実行すれば、社内の経費精算やクラウドソーシングのような小口の決済処理において、煩わしい承認をしなくても決済処理が自動的に実行され、処理を効率化することができる。なお、送金処理の条件としては、例えば送金額や送金回数を指定することができ、この送金額や送金回数を個別に承認しなくても問題がない程度の数値にしておけば、不正な送金処理が自動的に行われることを防止したり、仮に被害が生じても被害を最小限とすることができる。また、プリペイドカードを使用しているため、プリペイドカードの残高以上の送金が実行されないので、高額の不正送金を防止することができる。

また、請求項２及び６に記載の発明は上記の通りであり、前記送金処理の条件として、１回の送金処理における送金限度額を登録可能であるので、不正に多額の送金が行われることを防止できる。

また、請求項３及び７に記載の発明は上記の通りであり、前記送金処理の条件として、一定期間における送金限度額を登録可能であるので、例えば「月額の限度額」などを設定して、不正に多額の送金が行われることを防止できる。

また、請求項４及び８に記載の発明は上記の通りであり、前記送金要求と前記送金処理の条件とを比較し、この比較結果が所定の条件に該当しないときには、前記第２のユーザが許可した場合に限り送金処理を実行する。すなわち、送金処理の条件に合わない場合でも、エラーにするのではなく、送金の可否を問い合わせるようにすることで、多額の送金がやむを得ず必要になった場合でも対応することができる。

本実施形態に係るプリペイドカード管理システムの概念図である。 送金条件登録処理のフロー図である。 送金処理のフロー図である。 プリペイドカード管理システムを経費清算において使用する場合の使用例を示すシーケンス図である。 プリペイドカード管理システムをクラウドソーシングにおいて使用する場合の使用例を示すシーケンス図である。

本発明の実施形態について、図を参照しながら説明する。

（システム構成について）
図１は、本実施形態に係るプリペイドカード管理システムの概念図である。このプリペイドカード管理システムは、プリペイドカード管理サーバ１０により管理されている。このプリペイドカード管理サーバ１０は、カード情報データベース２０及びユーザ（具体的にはパソコンや携帯電話などのユーザ端末）と、インターネット等の通信手段を介して接続されている。

なお、図１においては、ユーザとして、第１のユーザＡ１と、第２のユーザＡ２と、を図示している。実際には更に多数のユーザが存在するが、ここではこの２人のユーザを例に説明する。

この第１のユーザＡ１及び第２のユーザＡ２は、それぞれプリペイドカードＢを所持している。プリペイドカードＢは、繰り返しチャージが可能なプリペイドカードＢである。プリペイドカード管理サーバ１０は、カード情報データベース２０を参照して、プリペイドカードＢの残高等の管理を行う。カード情報データベース２０には、ユーザ情報２１、カード情報２４、使用履歴情報２２、残高情報２３等が記憶されている。

なお、本実施形態においては説明のためにシステム構成を単純化しているが、実際のシステム構成は図１と異なっていてもよい。すなわち、実際の運用においては、プリペイドカードＢのカード情報２４や残高情報２３はカード発行業者側のサーバによって管理され、ユーザ情報２１や使用履歴情報２２はカード加盟店側のサーバによって管理されていてもよい。このように、サーバやデータベースの構成を適宜変更しても本発明を実施することは可能である。

カード情報データベース２０に記憶されるユーザ情報２１は、ユーザごとに管理される情報であり、ユーザを識別するために各ユーザに割り当てられた固有のユーザＩＤ、ユーザＩＤに関連付けられたユーザ名やパスワードなどを含む。プリペイドカードＢのユーザは、プリペイドカードＢを使用するにあたりユーザ登録を行う。ユーザ登録を行うと、ユーザが指定したユーザ名やパスワードがユーザＩＤと関連付けられてユーザ情報２１が作成され、このユーザ情報２１がカード情報データベース２０に登録される。

カード情報データベース２０に記憶されるカード情報２４は、プリペイドカードＢごとに管理される情報であり、プリペイドカードＢを識別するためにプリペイドカードＢごとに割り当てられた固有のカードＩＤ、カードＩＤに関連付けられたカード名やパスワードなどの情報を含む。本実施形態に係るプリペイドカード管理システムにおいては、１つのユーザＩＤで複数のプリペイドカードＢを持つことができるようになっているため、ユーザは、自分のユーザＩＤ（もしくはユーザ名などの固有の識別情報）を指定して任意の数だけプリペイドカードＢを作成することができる。プリペイドカードＢを作成すると、ユーザが指定したカード名やパスワードが、カードＩＤ及びユーザＩＤと関連付けられてカード情報２４が作成され、このカード情報２４がカード情報データベース２０に登録される。これにより、プリペイドカードＢを特定するカードＩＤが、当該プリペイドカードＢを保有するユーザのユーザＩＤと関連付けられ、当該プリペイドカードＢに関する情報（後述する送金条件を含む）の変更は、当該ユーザＩＤを使用しなければ実行できないようになる。

また、上記したカード情報２４は、プリペイドカードＢの送金処理の条件を規定する送金条件テーブル２５を含む。この送金条件テーブル２５は、後述する送金条件登録処理によって登録される。送金条件登録処理を実行すると、ユーザごとに送金条件に係る情報が作成され、この情報が送金条件テーブル２５に登録される。

なお、本実施形態においては、送金条件テーブル２５はカード情報２４に含まれているが、これに限らず、送金条件テーブル２５は特定のプリペイドカードＢに係るカード情報２４に関連付けられてさえいればよい。言い換えると、送金条件テーブル２５は特定のプリペイドカードＢに対して１対１の関係で関連付けられてさえいればよい。

また、この送金条件テーブル２５は複数のユーザに関する情報を含んでおり、このため、１つのカード情報２４に対して複数のユーザに関する送金条件を指定できる。言い換えると、１つのプリペイドカードＢに対して複数のユーザに関する送金条件を登録可能である。

カード情報データベース２０に記憶される使用履歴情報２２は、プリペイドカードＢごとに管理される情報であり、対象となるプリペイドカードＢのカードＩＤ、カードＩＤに関連付けられた使用履歴の詳細な情報を含む。ユーザがプリペイドカードＢで決済処理や入出金処理を実行すると、その内容は使用履歴情報２２に付加されて記憶される。

カード情報データベース２０に記憶される残高情報２３は、プリペイドカードＢごとに管理される情報であり、対象となるプリペイドカードＢのカードＩＤ、カードＩＤに関連付けられた使用残高に関する情報を含む。ユーザがプリペイドカードＢで決済処理や入出金処理を実行すると、その結果に応じてプリペイドカードの残高を変更し、その内容が残高情報２３に記憶される。

次に、プリペイドカード管理サーバ１０は、コンピュータから構成され、コンピュータプログラムを実行することで、送金条件登録部１１、送金要求取得部１２、送金処理部１３として機能する。送金条件登録部１１は、ユーザからの要求に従って送金条件登録処理を実行する。また、送金要求取得部１２、送金処理部１３は、ユーザからの要求に従って送金処理を実行する。

（送金条件登録処理について）
送金条件登録処理は、送金元のプリペイドカードＢ２から他のユーザに送金する際の送金条件を登録する処理である。送金条件を登録しておくことで、後述する送金処理において指定された送金要求が送金条件を満たす場合に、送金元に問い合わせることなく自動的に送金を実行することができる。この送金条件登録処理について、図２のフローを参照しながら説明する。

まず、図２に示すステップＳ１００において、送金条件登録部１１が、送金元のプリペイドカードＢ２の保有者である第２のユーザＡ２から、条件登録要求を取得する。例えば、第２のユーザＡ２がインターネットを介してプリペイドカード管理システムにアクセスし、送金元のプリペイドカードＢ２の「カードＩＤ」と、送金先のプリペイドカードＢ１の「カードＩＤ」（または送金先のプリペイドカードＢ１の保有者である第１のユーザＡ１を特定する「ユーザＩＤ」）と、任意の送金処理条件と、を指定して、条件登録要求を送信する。このように第２のユーザＡ２が送信した条件登録要求を取得したら、ステップＳ１０１に進む。

ステップＳ１０１では、第２のユーザＡ２に送金条件を登録する権限が有るか否かをチェックする。例えば、第２のユーザＡ２に対して、ユーザＩＤやパスパードなどの入力を求め、第２のユーザＡ２が送金元のプリペイドカードＢ２の保有者であることを認証する。そして、ステップＳ１０２に進む。

ステップＳ１０２では、ステップＳ１０１における認証結果を確認し、認証に成功したら、ステップＳ１０３に進む。一方、認証に失敗したら、ステップＳ１０５に進み、第２のユーザＡ２にエラーを通知して送金条件登録処理を終了する。

ステップＳ１０３に進んだ場合、送金条件登録部１１が、条件登録要求において指定された送金処理条件を基に、送金条件を作成する。そして、ステップＳ１０４に進む。

ステップＳ１０４では、送金条件登録部１１が、送金元のプリペイドカードＢ２のカードＩＤを基にカード情報データベース２０からカード情報２４を取得する。そして、当該カード情報２４に関連付けられた送金条件テーブル２５に対して、新しく作成した送金条件を登録する。なお、送金条件テーブル２５にすでに同じユーザＩＤを持つ送金条件が存在する場合には、当該送金条件を上書きすればよい。以上で送金条件登録処理が完了する。

なお、本実施形態においては、送金条件テーブル２５に登録できる送金条件として、１回の送金処理における送金限度額と、月額の送金限度額と、を設けている。例えば、図１に示す送金条件テーブル２５においては、この送金条件テーブル２５に関連付けられた送金元のプリペイドカードＢ２から、カードＩＤが「０」の送金先のプリペイドカードＢ１へと送金する場合には、１回の送金の限度額が１０００円であり、累計月額の送金の限度額が１００００円となっている。この例では、後述する送金処理において指定された送金額が１０００円以下であり、かつ、月額累計の送金額が１００００円以下の場合には、自動送金が実行されることになる。

なお、図１に示す送金条件テーブル２５では、限度額をプリペイドカードＢごとに指定しているが、これに限らず、限度額をユーザＡ１，Ａ２ごとに指定してもよい。また、上記した例では、月額の送金限度額を登録しているが、これに限らず、異なる期間、例えば年間の送金限度額を登録できるようにしてもよい。また、上記した例では送金の額のみを条件として登録しているが、これに限らず、別の条件を登録できるようにしてもよい。例えば、一定期間の送金限度回数を登録できるようにしてもよい。具体的には、送金限度回数を月５回以内とするなどの条件を登録できるようにしてもよい。

このように送金条件登録処理を実行することで、後述するように、第２のユーザＡ２が保有する送金元のプリペイドカードＢ２の口座から、第１のユーザＡ１が保有する送金先のプリペイドカードＢ１の口座への送金処理を自動化することができる。

なお、上記フローではとくに説明していないが、特定のユーザに付与した送金条件を削除したい場合には、第２のユーザＡ２が所定の手続きを行うことで、カード情報２４に関連付けた送金条件テーブル２５から、任意のユーザに係る送金条件を削除したり書き換えたりすることができる。

また、上記した送金条件登録処理においては、プリペイドカードＢごとに送金条件登録処理を実行する処理の流れについて説明したが、これに限らず、送金元のユーザが複数のプリペイドカードＢを保有している場合には、これらの複数の送金元のプリペイドカードＢ２に対して、一括で送金条件登録処理を実行できるようにしてもよい。同様に、複数の送金先のプリペイドカードＢ１に対して、一括で送金条件登録処理を実行できるようにしてもよい。また、複数のユーザを指定して一括で送金条件登録処理を実行できるようにしてもよい。

（送金処理について）
次に、送金処理は、自分が保有するプリペイドカード口座の残額を他のユーザが保有するプリペイドカード口座へと移行して送金するための処理である。この送金処理について、図３のフローを参照しながら説明する。この例では、送金先のプリペイドカードＢ１を保有するユーザを第１のユーザＡ１、送金元のプリペイドカードＢ２を保有するユーザを第２のユーザＡ２として説明する。

まず、図３に示すステップＳ２００において、送金要求取得部１２が、送金要求を取得する。送金要求は、第２のユーザＡ２（または送金元のプリペイドカードＢ２）を指定して、第１のユーザＡ１（または送金先のプリペイドカードＢ１）のアカウントから実行される。例えば、第１のユーザＡ１がインターネットを介してプリペイドカード管理システムにアクセスし、送金を依頼したい送金元のプリペイドカードＢ２の「カードＩＤ」と、送金先のプリペイドカードＢ１の「カードＩＤ」と、送金額と、を指定して送金要求を送信する。このように第１のユーザＡ１が送信した送金要求を取得したら、ステップＳ２０１に進む。

ステップＳ２０１では、送金処理部１３が、ステップＳ２００で取得した送金要求に基づき、カード情報データベース２０からカード情報２４を取得する。具体的には、送金要求に含まれるカードＩＤをキーにしてカード情報データベース２０からカード情報２４を抽出する。そして、ステップＳ２０２に進む。

ステップＳ２０２では、送金処理部１３が、ステップＳ２０１で取得したカード情報２４に基づき、送金条件を確認する。具体的には、送金先のプリペイドカードＢ１のカードＩＤと、ステップＳ２０１で取得したカード情報２４に関連付けられた送金条件テーブル２５とを比較し、送金先のプリペイドカードＢ１のカードＩＤをキーにして送金条件テーブル２５から送金条件を抽出する。そして、ステップ２０３に進む。

ステップＳ２０３では、ステップＳ２００で取得した送金要求と、ステップＳ２０２で抽出した送金条件と、を比較し、自動的に送金処理を実行可能かをチェックする。本実施形態においては、送金条件として「１回の送金処理における送金限度額」と「一定期間における送金限度額（月額）」とが登録可能であるため、これらの限度額と送金要求で指定された送金額とが比較される。送金要求で指定された送金額が「１回の送金処理における送金限度額」以下であり、かつ、送金要求で指定された送金額を加算した累計の月額送金額が「一定期間における送金限度額（月額）」以下である場合には、予め登録された送金条件を満たしていると判断する。それ以外の場合は、予め登録された送金条件を満たしていないと判断する。送金条件を満たしている場合には、第２のユーザＡ２への問い合わせを実行することなく送金処理を実行するため、ステップＳ２０７に進む。送金条件を満たしていない場合には、第２のユーザＡ２が許可した場合に限り送金処理を実行するため、ステップＳ２０４に進む。

ステップＳ２０４に進んだ場合、すなわち、予め登録された送金条件を満たしていない送金要求であった場合には、送金処理部１３は、第２のユーザＡ２に対して送金許可確認要求を送信する。例えば、第２のユーザＡ２に対してインターネットを介して（例えばＥメールなどで）第１のユーザＡ１から送金条件を満たさない送金要求があったことを通知し、当該送金要求を許可するか否かを問い合わせる。そして、ステップＳ２０５に進む。

ステップＳ２０５では、第２のユーザＡ２から送金許可確認応答を取得するまで待機する。第２のユーザＡ２からの送金許可確認応答を取得したら、ステップＳ２０６に進む。

ステップＳ２０６では、送金処理部１３が、第２のユーザＡ２から取得した送金許可確認応答の内容をチェックする。すなわち、第２のユーザＡ２が、第１のユーザＡ１からの送金要求を承認したのか拒否したのかがチェックされる。取得した送金許可確認応答が「送金可」の場合には、ステップＳ２０７へ進む。一方、送金許可確認応答が「送金不可」の場合には、ステップＳ２０８に進む。

ステップＳ２０７に進んだ場合、送金処理部１３が、送金元のプリペイドカードＢ２から送金先のプリペイドカードＢ１へと送金を実行する。具体的には、カード情報データベース２０の残高情報２３を書き換えることで、残高の移し替えを実行する。以上で送金処理が終了する。

また、ステップＳ２０８に進んだ場合、送金処理部１３が、第１のユーザＡ１に対して送金エラーを通知する。例えばＥメールやウェブ画面上で、送金が拒否されたことを通知する。以上で送金処理が終了する。

このように、本実施形態に係る送金処理によれば、予め登録された送金条件を満たしている場合には、送金元（第２のユーザＡ２）に問い合わせすることなく送金処理が実行される。このため、個別承認の必要性が低いような小口清算などにおいて、送金元が逐一承認する必要がなく、入金処理を効率化することができる。

なお、上記した送金処理においては、送金条件として「１回の送金処理における送金限度額」と「一定期間における送金限度額（月額）」とを登録可能としたが、別の条件を設けてもよいことは既に説明したとおりである。また、送金条件を複数登録可能な場合において、その一部のみを登録できるようにしてもよい。例えば、「１回の送金処理における送金限度額」のみを登録し、「一定期間における送金限度額（月額）」については登録しない（条件を設定しない）というような使用方法を許可してもよい。

また、上記した送金処理においては、送金条件を満たしていない場合には、第２のユーザＡ２が許可した場合に限り送金処理を実行するようにしたが、これに限らず、送金条件を満たしていない場合には、第２のユーザＡ２に問い合わせることなく送金エラーにするようにしてもよい。

また、送金条件を段階的に設定できるようにしてもよい。例えば、「自動送金条件」と「要確認条件」とを登録できるようにしてもよい。この場合、送金要求が「自動送金条件」を満たしている場合には自動送金を実行し、「自動送金条件」を満たしていないが「要確認条件」を満たしている場合には第２のユーザＡ２に送金の可否を問合わせるようにしてもよい。

（経費清算において使用する場合の使用例）
上記したプリペイドカード管理システム及びプリペイドカード管理方法を、企業内の経費清算において使用する場合の使用例について、図４を参照しつつ説明する。

この例では、企業の経理担当者（第２のユーザＡ２）が企業の従業員（第１のユーザＡ１）にプリペイドカードＢ（送金先のプリペイドカードＢ１）を渡すケースを想定している。送金先のプリペイドカードＢ１には最初から一定金額がチャージされており、従業員が備品等を購入する際にはこの送金先のプリペイドカードＢ１を使用する。送金先のプリペイドカードＢ１の残額が少なくなった場合には、従業員は経理担当者（送金元のプリペイドカードＢ２）に送金要求を発行する。このように発行された送金要求は、社内で決定された送金条件に従って処理される。例えば、送金要求が送金条件に合致する場合には送金先のプリペイドカードＢ１に自動的にチャージが実行されるが、送金要求が送金条件に合致しない場合には、社内承認を得た上で送金先のプリペイドカードＢ１にチャージが実行される。

具体的には、まず経理担当者が送金条件登録処理を実行し、送金先のプリペイドカードＢ１への送金条件を設定する。そして、この送金先のプリペイドカードＢ１を従業員に渡す。

従業員は、経理担当者から渡された送金先のプリペイドカードＢ１を使用し、企業活動に伴う経費を支払う。例えば備品等を購入する。そして、送金先のプリペイドカードＢ１の残額が少なくなるなど、チャージの必要が生じた場合には、経理担当者に対して（送金元のプリペイドカードＢ２を指定して）送金要求を行う。

この送金要求が送金条件に合致していれば、経理担当者の承認を得ることなく自動的に送金処理が実行される。一方、送金要求が送金条件に合致しない場合には、経理担当者の承認を得た上で（経理担当者の手動操作により）送金処理が実行される。

このように送金処理が実行されることで、送金先のプリペイドカードＢ１への入金が行われるため、少額であれば経理担当者の手を煩わせることなく自動的に処理されるとともに、高額であれば経理担当者のチェックを経たうえで入金が行われる。

なお、この場合において、従業員の保有する送金先のプリペイドカードＢ１の使用履歴情報２２を、経理担当者が参照できるようにしてもよい。このように、経理担当者が使用履歴を参照できるようにすれば、従業員が金銭を適切に使用しているかどうかをチェックすることができる。また、経費精算を行う際に使用履歴情報２２を流用することも可能となる。

また、送金先のプリペイドカードＢ１の使用履歴情報２２を経理担当者が参照できるようにした場合、送金先のプリペイドカードＢ１の利用停止を実行する権限を、経理担当者（使用履歴の参照権限者）に対して付与可能としてもよい。すなわち、経理担当者に対して、送金先のプリペイドカードＢ１の利用状況を確認するだけではなく、強制的に送金先のプリペイドカードＢ１の使用を停止させることができるようにしてもよい。このように、経理担当者に対して利用停止を実行する権限を付与することで、経理担当者が使用履歴を参照した結果、送金先のプリペイドカードＢ１が適切に使用されていないと判断した場合には、送金先のプリペイドカードＢ１をそれ以上使用できないようにすることができる。

（クラウドソーシングにおいて使用する場合の使用例）
上記したプリペイドカード管理システム及びプリペイドカード管理方法をクラウドソーシングにおいて使用する場合の使用例について、図５を参照しつつ説明する。

この例では、クラウドソーシングの依頼元である業務依頼者（第２のユーザＡ２）から、クラウドソーシングの依頼先である業務遂行者（第１のユーザＡ１）への報酬をプリペイドカードＢで支払うケースを想定している。業務依頼者及び業務遂行者は、それぞれプリペイドカードＢを保有しており、業務依頼者の保有するプリペイドカードＢが送金元のプリペイドカードＢ２であり、業務遂行者の保有するプリペイドカードＢが送金先のプリペイドカードＢ１である。
この例では、まず業務依頼者からの依頼を受けた業務遂行者が業務を遂行する。

業務が完了したことを業務依頼者が確認したら、送金条件登録処理を実行し、業務遂行者が報酬を受け取れる状態とする。例えば、送金条件として今回の業務に係る報酬額を登録する。例えば、報酬額を「１回の送金処理における送金限度額」として登録し、かつ、送金回数を１回のみに限定する送金条件を登録する。

送金条件が登録されたら、業務遂行者は、業務依頼者（送金元のプリペイドカードＢ２）に対して送金要求を行う。このとき、予め設定されていた報酬額を指定する。これにより、自動的に送金処理が実行される。

このような送金処理によれば、インターネットバンキングと同様の処理がプリペイドカードＢによって実現できるので、ユーザ間の匿名性をある程度維持しつつ少額の金銭のやり取りを行うこともできる。
なお、上記した例では、業務完了後に送金条件登録処理を実行するようにしたが、業務完了前に送金条件登録処理を実行してもよいことは言うまでもない。

（まとめ）
以上説明したように、本実施形態によれば、第１のユーザＡ１から第２のユーザＡ２に対して発行された送金要求を取得し、送金要求と送金処理の条件とを比較し、この比較結果が所定の条件に該当するときには、前記第２のユーザＡ２に問い合わせることなく送金処理を実行する。すなわち、他のプリペイドカードＢの保有者から送金要求があったときに、その送金要求が予め定めた条件に合致する場合には自動的に送金が完了するようになっている。このような処理を実行すれば、社内の経費精算やクラウドソーシングのような小口の決済処理において、煩わしい承認をしなくても決済処理が自動的に実行され、処理を効率化することができる。なお、送金処理の条件としては、例えば送金額や送金回数を指定することができ、この送金額や送金回数を個別に承認しなくても問題がない程度の数値にしておけば、不正な送金処理が自動的に行われることを防止したり、仮に被害が生じても被害を最小限とすることができる。また、プリペイドカードＢを使用しているため、プリペイドカードＢの残高以上の送金が実行されないので、高額の不正送金を防止することができる。
また、前記送金処理の条件として、１回の送金処理における送金限度額を登録可能とすれば、不正に多額の送金が行われることを防止できる。

また、前記送金処理の条件として、一定期間における送金限度額を登録可能とすれば、例えば「月額の限度額」などを設定して、不正に多額の送金が行われることを防止できる。

また、前記送金要求と前記送金処理の条件とを比較し、この比較結果が所定の条件に該当しないときには、前記第２のユーザＡ２が許可した場合に限り送金処理を実行すれば、多額の送金がやむを得ず必要になった場合でも対応することができる。

なお、上記した説明においては、プリペイドカードＢが金銭を扱うこととしたが、本発明の実施形態としてはこれに限らず、金銭に準じる価値を有するもの、例えばポイントサービスのポイントを扱うようにしてもよい。

１０ プリペイドカード管理サーバ
１１ 送金条件登録部
１２ 送金要求取得部
１３ 送金処理部
２０ カード情報データベース
２１ ユーザ情報
２２ 使用履歴情報
２３ 残高情報
２４ カード情報
２５ 送金条件テーブル
Ａ１ 第１のユーザ
Ａ２ 第２のユーザ
Ｂ プリペイドカード
Ｂ１ 送金先のプリペイドカード
Ｂ２ 送金元のプリペイドカード

Claims (8)

1. 第２のユーザが保有するプリペイドカード口座から第１のユーザが保有するプリペイドカード口座への送金処理をネットワーク上で行うためのプリペイドカード管理システムであって、
   第１のユーザから第２のユーザに対して発行された送金要求を取得する送金要求取得部と、
   前記送金要求に基づき送金処理を実行する送金処理部と、
   送金処理部による送金処理の条件を登録するための送金条件登録部と、
   を備え、
   前記送金処理部は、前記送金要求と前記送金条件登録部において指定された送金処理の条件とを比較し、この比較結果が所定の条件に該当するときには、前記第２のユーザに問い合わせることなく送金処理を実行することを特徴とする、プリペイドカード管理システム。
2. 前記送金条件登録部は、前記送金処理の条件として、１回の送金処理における送金限度額を登録可能であることを特徴とする、請求項１記載のプリペイドカード管理システム。
3. 前記送金条件登録部は、前記送金処理の条件として、一定期間における送金限度額を登録可能であることを特徴とする、請求項１又は２記載のプリペイドカード管理システム。
4. 前記送金処理部は、前記送金要求と前記送金条件登録部において指定された送金処理の条件とを比較し、この比較結果が所定の条件に該当しないときには、前記第２のユーザが許可した場合に限り送金処理を実行することを特徴とする、請求項１〜３のいずれか１項に記載のプリペイドカード管理システム。
5. 第２のユーザが保有するプリペイドカード口座から第１のユーザが保有するプリペイドカード口座への送金処理をネットワーク上で行うためのプリペイドカード管理方法であって、
   送金処理の条件を登録するステップと、
   第１のユーザから第２のユーザに対して発行された送金要求を取得するステップと、
   前記送金要求に基づき送金処理を実行するステップと、
   を備え、
   前記送金要求と前記送金処理の条件とを比較し、この比較結果が所定の条件に該当するときには、前記第２のユーザに問い合わせることなく送金処理を実行することを特徴とする、プリペイドカード管理方法。
6. 前記送金処理の条件として、１回の送金処理における送金限度額を登録可能であることを特徴とする、請求項５記載のプリペイドカード管理方法。
7. 前記送金処理の条件として、一定期間における送金限度額を登録可能であることを特徴とする、請求項５又は６記載のプリペイドカード管理方法。
8. 前記送金要求と前記送金処理の条件とを比較し、この比較結果が所定の条件に該当しないときには、前記第２のユーザが許可した場合に限り送金処理を実行することを特徴とする、請求項５〜７のいずれか１項に記載のプリペイドカード管理方法。

Images