JP2017033190A - 情報管理サーバ、および、決済システム - Google Patents

Abstract

【課題】クレジットカードの利用に対するセキュリティを高めることのできる情報管理サーバ、および、決済システムを提供する。【解決手段】情報管理サーバ１０は、クレジットカード番号に対応付けられた代替情報を含む固有情報と決済許可条件とを対応付けて条件データ１２ａとして記憶部に記憶させる登録部と、決済を要求する端末から、決済要求金額と、照合情報として固有情報に含まれる情報とを受け付けて、これに伴って、決済要求情報を取得する取得部と、条件データ１２ａにて照合情報に対応付けられている決済許可条件を特定し、決済要求情報を用いて、特定された決済許可条件が満たされているか否かを判定する判定部と、決済許可条件が満たされていると判定された場合における決済要求金額を、特定された決済許可条件に条件データにて対応付けられている代替情報と対応付けて出力する出力部とを備える。【選択図】図１

Description

本発明は、決済に用いられる情報管理サーバ、および、決済システムに関する。

近年、クレジットカードを利用したサービスの拡大に伴い、クレジットカード番号とともに管理される情報が多様化している。例えば、特許文献１に記載のサーバは、クレジットカード番号とともに、クレジットカードの所有者のメールアドレスや居住地に関する情報を記憶している。クレジットカード番号とともに管理される情報は、クレジットカードを用いた決済に付随して生じる処理に用いられる。例えば、特許文献１に記載の例では、クレジットカード番号とともに管理されている情報は、クレジットカードを用いた決済に際して、所有者への情報配信のために利用される。

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

ところで、サーバがクレジットカード番号を記憶していると、クレジットカード番号がサーバの外部へ流出して不正に利用される虞がある。したがって、決済処理を行うサーバのように、クレジットカード番号の記憶が必須であるサーバを除いて、他のサーバ、具体的には、上述のように、決済に付随して生じる処理に用いられる情報を記憶するサーバには、クレジットカード番号は記憶されないことが好ましい。
本発明は、クレジットカードの利用に対するセキュリティを高めることのできる情報管理サーバ、および、決済システムを提供することを目的とする。

上記課題を解決する情報管理サーバは、データを記憶する記憶部と、クレジットカード番号に対応付けられた代替情報を含む固有情報を受信する受信部と、前記固有情報と決済が許可される条件である決済許可条件とを対応付けて条件データとして前記記憶部に記憶させる登録部と、決済を要求する端末から、決済の要求される金額である決済要求金額と、照合情報として前記固有情報に含まれる情報とを受け付けて、これに伴って、決済の要求されている状況を示す決済要求情報を取得する取得部と、前記条件データにて前記照合情報に対応付けられている前記決済許可条件を特定し、前記決済要求情報を用いて、特定された前記決済許可条件が満たされているか否かを判定する判定部と、前記決済許可条件が満たされていると判定された場合における前記決済要求金額を、特定された前記決済許可条件に前記条件データにて対応付けられている前記代替情報と対応付けて出力する出力部と、を備える。

上記課題を解決する決済システムは、クレジットカード番号に対応付けられた代替情報を含む固有情報と、決済が許可される条件である決済許可条件に含まれる外部取得条件とを取得する登録端末と、決済の要求される金額である決済要求金額と、前記固有情報に含まれる照合情報とを取得する支払端末と、前記登録端末および前記支払端末とネットワークを介して接続される情報管理サーバと、を備える決済システムであって、前記情報管理サーバは、データを記憶する記憶部と、前記登録端末から前記固有情報と前記外部取得条件とを受信する受信部と、前記固有情報と前記決済許可条件とを対応付けて条件データとして前記記憶部に記憶させる登録部と、前記支払端末から、前記決済要求金額と前記照合情報とを受け付けて、これに伴って、決済の要求されている状況を示す決済要求情報を取得する取得部と、前記条件データにて前記照合情報に対応付けられている前記決済許可条件を特定し、前記決済要求情報を用いて、特定された前記決済許可条件が満たされているか否かを判定する判定部と、前記決済許可条件が満たされていると判定された場合における前記決済要求金額を、特定された前記決済許可条件に前記条件データにて対応付けられている前記代替情報と対応付けて出力する出力部と、を備える。

上記構成によれば、情報管理サーバは、決済を要求する端末からの決済の要求に対し、決済許可条件が満たされているか否か、すなわち、決済が許可されるか否かを判定するサーバであって、つまりは、決済に付随して生じる処理を行うサーバである。そして、こうした情報管理サーバには、決済に付随して生じる処理に用いられる情報である決済許可条件とともにクレジットカード番号の代替である代替情報が記憶され、クレジットカード番号は記憶されない。したがって、情報管理サーバにクレジットカード番号が記憶される場合と比較して、クレジットカード番号の流出が抑えられるため、クレジットカードの利用に対するセキュリティが高められる。
また、条件データにて、固有情報と決済許可条件とが対応付けられるため、固有情報ごと、すなわち、代替情報ごとの決済許可条件の設定が可能である。

上記情報管理サーバにおいて、前記決済許可条件は、決済が許可される期間を含み、前記決済要求情報は、決済の要求されている時を含むことが好ましい。
上記構成によれば、決済の要求されている時についての状況が、決済が許可される期間についての条件を満たすときに、決済許可条件が満たされていると判定され、すなわち、決済が許可される。したがって、決済の許可される期間を制限することができる。

上記情報管理サーバにおいて、前記決済許可条件は、決済が許可される上限金額を含み、前記決済要求情報は、前記決済要求金額を含むことが好ましい。
上記構成によれば、決済の要求されている金額についての状況が、決済が許可される上限金額についての条件を満たすときに、決済許可条件が満たされていると判定され、すなわち、決済が許可される。したがって、決済の許可される金額を制限することができる。

上記情報管理サーバにおいて、前記判定部は、前記決済許可条件が満たされていると判定したとき、前記決済要求金額を前記代替情報と対応付けて履歴データとして前記記憶部に記憶させ、前記取得部が新たな前記決済要求金額と前記照合情報とを受け付けたとき、当該照合情報を含む前記固有情報に含まれる前記代替情報と前記履歴データにて対応付けられている金額と、前記新たな決済要求金額との合計金額が、前記決済が許可される上限金額以下であるか否かを判定することによって、前記決済許可条件が満たされているか否かを判定することが好ましい。

上記構成によれば、決済許可条件が満たされているか否かの判定として、今回の決済の要求までに決済の許可された金額と、今回の決済の要求における決済要求金額との合計額が、決済が許可される上限金額以下であるか否かが判定される。したがって、過去の利用状況を含めて決済が許可される上限金額が満たされているか否かが判定されるため、決済の許可される金額の制限が的確に行われる。

上記情報管理サーバにおいて、前記受信部は、前記決済許可条件に含まれる条件の少なくとも一部を受信し、前記登録部は、前記固有情報と前記受信部が受信した条件である外部取得条件を含む前記決済許可条件とを対応付けて前記条件データとして前記記憶部に記憶させることが好ましい。

上記構成によれば、決済許可条件に含まれる条件の少なくとも一部は、情報管理サーバの外部の装置で設定された条件である。したがって、決済許可条件の設定の自由度が高められる。

上記情報管理サーバにおいて、前記登録部は、前記受信部が、前記固有情報と新たな前記外部取得条件とを受信したとき、当該固有情報に前記条件データにて対応付けられている前記外部取得条件を、前記新たな外部取得条件に変更することが好ましい。
上記構成によれば、決済許可条件に含まれる条件の変更が可能であるため、決済許可条件の設定の自由度が高められる。

上記情報管理サーバにおいて、前記外部取得条件は、決済が許可される上限金額であり、前記登録部は、前記判定部が前記上限金額の超過によって前記決済許可条件が満たされていないと判定したとき、前記外部取得条件の変更を受け付けることが好ましい。

上記構成によれば、上限金額の超過によって決済許可条件が満たされていないと判定されたとき、条件データとして記憶されている上限金額の変更が可能である。したがって、決済の要求されている金額についての状況が上限金額の超過に該当する場合に上限金額の引き上げが可能であるため、利用者の利便性が高められる。

上記情報管理サーバにおいて、前記固有情報は、利用者ごとに固有の認証情報を含み、前記受信部は、前記決済を要求する端末を含む端末から所定の処理の要求を受けることに伴って、前記決済を要求する端末を含む端末に入力された前記認証情報を当該端末から受信し、前記受信部が受信した前記認証情報と、前記条件データに含まれる前記認証情報との一致を確認することに基づいて、前記所定の処理の実行を許容する認証部をさらに備えることが好ましい。

上記構成によれば、情報管理サーバの外部から受信した認証情報と情報管理サーバが記憶している認証情報との一致を確認することに基づいて、所定の処理の実行が許容されるため、所定の処理の実行に対するセキュリティが高められる。

上記情報管理サーバにおいて、前記所定の処理には、一致が確認された前記認証情報に前記条件データにて対応付けられている前記決済許可条件の前記決済を要求する端末を含む端末への送信、当該決済許可条件の変更、および、当該決済許可条件を用いた処理の禁止の少なくとも１つが含まれる。

上記構成によれば、決済許可条件の端末への送信、条件データに含まれる決済許可条件の変更、および、決済許可条件を用いた処理の禁止の少なくとも１つの実行に対するセキュリティが高められる。
上記情報管理サーバにおいて、前記照合情報は、前記代替情報であってもよい。
上記情報管理サーバにおいて、前記照合情報は、前記認証情報であってもよい。
上記構成によれば、判定部による決済許可条件の特定が的確に実現される。

上記情報管理サーバにおいて、前記条件データにて、複数の前記固有情報の各々に前記決済許可条件が対応付けられ、前記複数の固有情報には、同一のクレジットカード番号に対応付けられた互いに異なる代替情報を含む前記固有情報が含まれることが好ましい。

上記構成によれば、１つのクレジットカード番号に対応付けられた複数の代替情報の各々に、決済許可条件が対応付けられる。したがって、利用者ごとに代替情報を設定することによって、１つのクレジットカードを利用した決済を複数の利用者が利用することが可能である。また、こうした複数の利用者による決済の各々に対して、互いに異なる決済許可条件を課すことも可能である。
上記情報管理サーバにおいて、前記代替情報は、トークンを含む数列を示すことが好ましい。

上記構成によれば、代替情報が、クレジットカード番号が暗号化された情報である場合と比較して、仮に代替情報が情報管理サーバから流出した場合にも、代替情報に基づいてクレジットカード番号が算出されることが抑えられる。したがって、クレジットカードの利用に対するセキュリティが特に高められる。

本発明によれば、クレジットカードの利用に対するセキュリティを高めることができる。

決済システムの第１実施形態について、決済システムの全体構成とともに情報管理サーバの構成を示す図である。 第１実施形態における条件データのデータ構成の一例を示す図である。 第１実施形態における代替情報および決済許可条件の登録の手順を示すシーケンス図である。 第１実施形態における代金の支払いの手順を示すシーケンス図である。 第２実施形態における条件データのデータ構成の一例を示す図である。 第２実施形態における代替情報、認証情報、および、決済許可条件の登録の手順の一部を示すシーケンス図である。 第２実施形態における代金の支払いの手順の一部を示すシーケンス図である。 第２実施形態における決済許可条件の確認の手順を示すシーケンス図である。 第２実施形態における決済許可条件を用いた処理を禁止する手順を示すシーケンス図である。

（第１実施形態）
図１〜図４を参照して、情報管理サーバ、および、決済システムの第１実施形態について説明する。第１実施形態の決済システムは、例えば、所定の期間内のみ開催されるイベントにおいて、イベントの参加者がイベントに出店している店舗にて商品やサービスに対する支払いを行うときに利用される。

［決済システムの構成］
図１を参照して、決済システムの構成、および、決済システムを構成する装置の構成について説明する。

図１が示すように、決済システムは、情報管理サーバ１０と、１以上の登録端末２０と、１以上の支払端末３０とを備えている。情報管理サーバ１０と登録端末２０と支払端末３０とは、インターネット等の汎用通信回線や専用通信回線等のネットワークＮＷに接続され、情報管理サーバ１０は、登録端末２０および支払端末３０の各々と、ネットワークＮＷを通じて相互にデータの送信および受信を行う。

また、ネットワークＮＷには、トークン化サーバ４０と決済サーバ５０とが接続されている。トークン化サーバ４０は、情報管理サーバ１０、登録端末２０、および、決済サーバ５０の各々と、ネットワークＮＷを通じて相互にデータの送信および受信を行う。また、決済サーバ５０は、登録端末２０およびトークン化サーバ４０の各々と、ネットワークＮＷを通じて相互にデータの送信および受信を行う。

なお、ネットワークＮＷは複数のネットワークを含んでいてもよい。すなわち、上記各装置の通信に用いられるネットワークは、共通した１つのネットワークであってもよいし、互いに異なるネットワークであってもよい。

トークン化サーバ４０は、トークナイゼーションによって代替情報を生成する機能を有する。トークン化サーバ４０は、クレジットカード番号に対してトークナイゼーションを行うことによって、代替情報の一例である代替ＩＤを生成する。代替ＩＤは、クレジットカード番号の一部もしくは全部をトークンである他の数列と置き換えた数列である。代替ＩＤは、トークン化サーバ４０にて、トークンに置き換えられる前のクレジットカード番号と対応付けられている。

決済サーバ５０は、クレジットカードによる決済の処理を行うサーバであって、クレジットカード会社の有するシステムに含まれるサーバである。決済サーバ５０は、クレジットカードの契約ごとに、有効期限や利用限度額や利用額や、暗証番号等のカード認証情報を記憶しており、クレジットカード番号を含むクレジットカード情報に基づいて、そのクレジットカード情報に対応するクレジットカードが利用可能であるか否かを判定する。また、決済サーバ５０は、クレジットカード番号と決済の対象である金額との通知を受けて、決済処理を行う。決済処理には、通知を受けたクレジットカード番号に対応する契約の利用額に決済の対象である金額を加える等の処理が含まれる。なお、決済サーバ５０による処理として説明される処理は、複数のサーバによって行われてもよい。また、決済サーバ５０と、登録端末２０およびトークン化サーバ４０の各々との情報の授受は、決済代行事業者等が管理するサーバであってゲートウェイとして機能するサーバを介して行われてもよい。

登録端末２０は、例えばイベント会場の入口等に設置され、イベントの参加者である利用者によって利用される。
登録端末２０は、ネットワークＮＷを通じた通信機能に加え、クレジットカード６０から情報を読み取る機能と、ＮＦＣ（ニア・フィールド・コミュニケーション）等の近距離無線通信によってＩＣタグ７０と通信を行う機能とを有している。すなわち、登録端末２０は、磁気カードリーダとしての機能とＩＣタグのリーダライタとしての機能とを備えている。また、登録端末２０は、利用者の操作を受け付ける操作部や、情報を表示する表示部や、登録端末２０の各部の処理を制御する制御部や、制御部による処理内容を規定するプログラムを記憶する記憶部を備えている。制御部は、登録端末２０と他の装置との通信の制御や、登録端末２０が他の装置から取得した情報および操作部の操作を通じて登録端末２０に入力された情報の処理を行う。

登録端末２０は、クレジットカード６０から、クレジットカード情報を取得する。そして、登録端末２０は、決済サーバ５０にクレジットカード情報を送信して、そのクレジットカード情報に対応するクレジットカードが利用可能であるか否かの判定結果を決済サーバ５０から受信する。判定結果が利用可能であった場合に、登録端末２０は、トークン化サーバ４０にクレジットカード番号を送信して、このクレジットカード番号に対応付けられた代替ＩＤをトークン化サーバ４０から受信する。そして、登録端末２０は、代替ＩＤをＩＣタグ７０に送信してＩＣタグ７０の備える記憶部に記憶させる。

登録端末２０は、操作部を通じて、決済が許可される条件である決済許可条件に含まれる条件の入力を受け付け、入力された条件を代替ＩＤとともに情報管理サーバ１０に送信する。

ＩＣタグ７０は、ＩＣチップやアンテナを備え、近距離無線通信によるデータの送受信が可能な装置である。ＩＣタグ７０は、例えば、リストバンド形状やペンダント形状を有し、利用者に携帯される。

支払端末３０は、イベント会場内の店舗に設置され、利用者が商品やサービスに対する支払いを行うときに利用される。支払端末３０は決済を要求する端末の一例である。

支払端末３０は、ネットワークＮＷを通じた通信機能に加え、ＮＦＣ等の近距離無線通信によってＩＣタグ７０と通信を行う機能を有している。すなわち、支払端末３０は、ＩＣタグのリーダライタとしての機能を備えている。また、支払端末３０は、利用者の操作を受け付ける操作部や、情報を表示する表示部や、支払端末３０の各部の処理を制御する制御部や、制御部による処理内容を規定するプログラムを記憶する記憶部を備えている。制御部は、支払端末３０と他の装置との通信の制御や、支払端末３０が他の装置から取得した情報および操作部の操作を通じて支払端末３０に入力された情報の処理を行う。なお、支払端末３０は、店舗が利用するＰＯＳシステムを管理するサーバにネットワークを介して接続されていてもよい。

支払端末３０は、操作部を通じて決済の要求される金額である決済要求金額の入力を受け付ける。決済要求金額は、商品やサービスの代金である。なお、決済要求金額の支払端末３０への入力方法は、操作部を通じた入力に限られない。例えば、支払端末３０がバーコードから情報を読み取る機能を備え、商品に付されたバーコードから商品の代金に相当する決済要求金額が支払端末３０に読み取られてもよい。

支払端末３０は、ＩＣタグ７０から代替ＩＤを読み取り、代替ＩＤと決済要求金額とを情報管理サーバ１０に送信して、決済を要求する。なお、支払端末３０は、代替ＩＤおよび決済要求金額に加えて、商品等を販売した店舗を示す情報である店舗情報や利用者が購入した商品やサービスを示す情報である商品情報等、支払端末３０に記憶されている情報もしくは支払端末３０が取得可能な情報を情報管理サーバ１０に送信してもよい。

情報管理サーバ１０は、通信部１１と、記憶部１２と、制御部１３とを備えている。
通信部１１は、ネットワークＮＷを通じて、情報管理サーバ１０と、登録端末２０、支払端末３０、および、トークン化サーバ４０の各装置との接続処理を実行する。また、通信部１１は、情報管理サーバ１０と、上記各装置との間でデータの送信および受信を行う。通信部１１は、受信部および出力部として機能する。

記憶部１２は、ハードディスクドライブ等の不揮発性メモリから構成され、制御部１３が実行する処理に必要なプログラムやデータを記憶している。記憶部１２は、データの一例として条件データ１２ａと履歴データ１２ｂとを記憶している。

条件データ１２ａは、代替ＩＤと決済許可条件とが対応付けられたデータである。決済許可条件には、決済が許可される期間である決済可能期間と決済が許可される金額の上限である上限金額とが含まれる。上限金額は、例えば、イベントおける支払いのために使用する予定の金額の上限として利用者によって決定される。決済可能期間は、例えば、イベントが開催されている期間とされる。

履歴データ１２ｂは、代替ＩＤごとに、決済の要求された履歴である決済要求履歴を示すデータである。決済要求履歴には、支払端末３０からの決済の要求ごとの決済要求金額が含まれる。また、決済要求履歴には、支払端末３０からの決済の要求ごとの、決済の要求された日時である決済要求時や、店舗情報や商品等情報が含まれてもよい。なお、履歴データ１２ｂは、決済が許可された場合における決済要求履歴のみを含んでいてもよいし、決済が許可された場合の決済要求履歴と決済が許可されなかった場合の決済要求履歴とを、各履歴について決済の可否を示す情報とともに含んでいてもよい。

制御部１３は、ＣＰＵや、ＲＡＭなどの揮発性メモリを含む。制御部１３は、記憶部１２に記憶されたプログラムやデータに基づいて、通信部１１による通信の制御、記憶部１２における情報の読み出しや書き込み、各種の演算処理など、情報管理サーバ１０が備える各機能部の制御を行う。
制御部１３は、登録部として機能する条件データ管理部１３ａと取得部および判定部として機能する決済可否判定部１３ｂとを備えている。

条件データ管理部１３ａは、通信部１１が登録端末２０から受信した代替ＩＤと、決済許可条件とを対応付けて記憶部１２に記憶させ、条件データ１２ａを構築する。

代替ＩＤと対応付けられる決済許可条件には、登録端末２０に入力された条件に限らず、登録端末２０が予め記憶していた条件や、情報管理サーバ１０が予め記憶していた条件が含まれてもよい。例えば、決済可能期間は、予め設定されて情報管理サーバ１０に記憶されており、条件データ管理部１３ａは、登録端末２０から受信した上限金額と、記憶部１２に記憶されている決済可能期間とを、決済許可条件として代替ＩＤと対応付けて、記憶部１２に記憶させてもよい。決済許可条件に含まれる条件のうち、情報管理サーバ１０が登録端末２０から受信した条件が、外部取得条件である。

決済可否判定部１３ｂは、通信部１１を通じて支払端末３０から代替ＩＤと決済要求金額とを受け付け、これに伴って決済の要求されている状況を示す決済要求情報を取得する。決済要求情報には、決済要求金額と決済要求時とが含まれる。

決済可否判定部１３ｂは、例えば、下記の手順で決済要求時を取得する。すなわち、支払端末３０が、代替ＩＤと決済要求金額とを情報管理サーバ１０に送信するときの日時を取得して、この日時を決済要求時として、代替ＩＤと決済要求金額とともに情報管理サーバ１０に送信する。これにより、決済可否判定部１３ｂは、通信部１１を通じて、決済要求時を取得する。あるいは、情報管理サーバ１０が日付および時刻を計測する時計部を備え、通信部１１が支払端末３０から代替ＩＤと決済要求金額とを受信したときの日時が、決済要求時として決済可否判定部１３ｂに取得される。

決済可否判定部１３ｂは、支払端末３０から受け付けた代替ＩＤに条件データ１２ａにて対応付けられている決済許可条件を特定する。そして、取得した決済要求情報を用いて、特定した決済許可条件が満たされているか否かを判定する。すなわち、決済可否判定部１３ｂは、決済要求時が決済可能期間に含まれているか否かを判断する。また、決済可否判定部１３ｂは、今回の決済要求で受け付けた決済要求金額と、今回の決済要求金額の受付時までに同一の代替ＩＤについて決済の許可された金額との合計の金額である決済要求合計金額が上限金額以下であるか否かを判断する。

決済可否判定部１３ｂは、下記の手順で決済要求合計金額を算出する。すなわち、履歴データ１２ｂにて、支払端末３０から受け付けた代替ＩＤに対応付けられた決済要求履歴であって、決済が許可された決済要求履歴を参照する。そして、決済可否判定部１３ｂは、この決済要求履歴に含まれる決済要求金額と、今回受け付けた決済要求金額とを合算することによって、決済要求合計金額を算出する。

決済許可条件が満たされていると判定されるとき、すなわち、決済要求合計金額が上限金額以下であり、かつ、決済要求時が決済可能期間に含まれている場合、決済可否判定部１３ｂは、決済が許可されると判定する。一方、決済許可条件が満たされないとき、すなわち、決済要求合計金額が上限金額を超えているか、または、決済要求時が決済可能期間に含まれていない場合、決済可否判定部１３ｂは、決済が許可されないと判定する。

決済が許可されると判定したとき、決済可否判定部１３ｂは、履歴データ１２ｂにて、支払端末３０から受け付けた代替ＩＤについての決済要求履歴に、今回受け付けた決済要求金額等、今回の決済要求についての情報を加える。すなわち、決済可否判定部１３ｂは、代替ＩＤと決済要求金額等を対応付けて記憶部１２に記憶させる。

なお、履歴データ１２ｂとして、決済が許可されなかった場合の決済要求履歴も記憶される場合には、決済可否判定部１３ｂは下記の処理を行えばよい。すなわち、決済が許可されないと判定された場合にも、決済可否判定部１３ｂは、履歴データ１２ｂにて、支払端末３０から受け付けた代替ＩＤについての決済要求履歴に、今回の決済要求についての情報を、決済が許可されなかった決済要求履歴として加える。

また、決済が許可されると判定したとき、決済可否判定部１３ｂは、今回の決済要求にて支払端末３０から受信した代替ＩＤと決済要求金額とを、通信部１１を介してトークン化サーバ４０に送信する。トークン化サーバ４０は、受信した代替ＩＤにトークン化サーバ４０にて対応付けられているクレジットカード番号と、受信した決済要求金額とを決済サーバ５０に送信し、決済サーバ５０は、受信したこれらの情報に基づいて決済処理を行う。なお、情報管理サーバ１０は、決済サーバ５０による決済処理での必要に応じて、代替ＩＤおよび決済要求金額に加えて、店舗情報や商品情報等をトークン化サーバ４０に送信してもよく、これらの情報は、トークン化サーバ４０から決済サーバ５０に送られる。

条件データ管理部１３ａおよび決済可否判定部１３ｂは、複数のＣＰＵや、ＲＡＭなどからなるメモリなどの各種のハードウェアと、これらを機能させるソフトウェアとによって各別に具体化されてもよく、あるいは、共通する１つのハードウェアに複数の機能を与えるソフトウェアによって具体化されてもよい。
［条件データの構成］
図２を参照して、条件データ１２ａにおける代替ＩＤと決済許可条件との対応関係について説明する。
図２が示すように、条件データ１２ａにおいて、１つの代替ＩＤには、決済許可条件として、１つの上限金額と１つの決済可能期間とが対応付けられている。

例えば、「１２３４−３３３３−５６７８−７７７７」という代替ＩＤには、「７月１２日９時〜７月１２日２０時」を示す決済可能期間と、「３万円」を示す上限金額とが対応付けられている。また、「６３８８−５６８９−９９９９−００１１」という代替ＩＤには、「７月１２日９時〜７月１２日２０時」を示す決済可能期間と、「１万５千円」を示す上限金額とが対応付けられている。すなわち、「１２３４−３３３３−５６７８−７７７７」という代替ＩＤについて決済要求が行われた場合には、決済要求時が「７月１２日９時〜７月１２日２０時」の期間内に含まれ、かつ、決済要求合計金額が「３万円」以下である場合に、決済が許可される。また、「６３８８−５６８９−９９９９−００１１」という代替ＩＤについて決済要求が行われた場合には、決済要求時が「７月１２日９時〜７月１２日２０時」の期間内に含まれ、かつ、決済要求合計金額が「１万５千円」以下である場合に、決済が許可される。

互いに異なる代替ＩＤには、互いに異なる上限金額や決済可能期間が対応付けられていてもよいし、同一の上限金額や決済可能期間が対応付けられていてもよい。
このように、条件データ１２ａにおいては、複数の代替ＩＤの各々に、決済許可条件が対応付けられている。

また、条件データ１２ａに含まれる複数の代替ＩＤには、同一のクレジットカード番号に対応付けられている複数の代替ＩＤが含まれてもよい。同一のクレジットカード番号に対応付けられている複数の代替ＩＤの各々には、互いに異なる上限金額や決済可能期間が対応付けられていてもよいし、同一の上限金額や決済可能期間が対応付けられていてもよい。

［決済システムの処理手順］
第１実施形態の決済システムによって決済が行われる手順について説明する。決済システムによる処理には、代替ＩＤおよび決済許可条件の登録の処理と、代金の支払いの処理とが含まれる。

まず、図３を参照して、代替ＩＤおよび決済許可条件の登録の手順について説明する。代替ＩＤおよび決済許可条件の登録は、例えば、利用者のイベントへの参加に先立って、イベント会場の入り口等で行われる。登録には、登録端末２０とクレジットカード６０とＩＣタグ７０とが用いられる。クレジットカード６０は、利用者の所有するクレジットカードであって、イベントにおける代金の支払に利用されるクレジットカードである。ＩＣタグ７０は、イベント会場にて利用者に配られる。

図３が示すように、クレジットカード６０が、登録端末２０のクレジットカード情報の読み取り部に通されることによって、登録端末２０がクレジットカード情報を読み取る（ステップＳ１０）。また、登録端末２０は、登録端末２０へのカード認証情報の入力を利用者に要求する。カード認証情報は、例えば、クレジットカード６０の暗証番号である。

登録端末２０は、読み取ったクレジットカード情報と登録端末２０に入力されたカード認証情報とを決済サーバ５０に送信して、そのクレジットカード情報に対応するクレジットカード、すなわちクレジットカード６０が利用可能であるか否かの判定を要求する（ステップＳ１１）。

決済サーバ５０は、登録端末２０から受信したクレジットカード情報とカード認証情報とに基づいて、クレジットカード６０が利用可能であるか否かを判定し、判定結果を登録端末２０に送信する（ステップＳ１２）。すなわち、決済サーバ５０は、決済サーバ５０に記憶されている情報を用いて、カード認証情報の照合を行うとともに、判定を要求された時点が有効期限内であるかや、判定を要求された時点における利用額が利用限度額に達していないか等を判断することによって、クレジットカード６０が利用可能であるか否かを判定する。

登録端末２０は、クレジットカード６０が利用可能であることを示す判定結果を決済サーバ５０から受信すると、クレジットカード番号をトークン化サーバ４０に送信して、代替ＩＤの生成を要求する（ステップＳ１３）。なお、登録端末２０が、クレジットカード６０が利用できないことを示す判定結果を決済サーバ５０から受信した場合には、登録端末２０は、その旨を表示部に表示することによって、クレジットカード６０が利用できないことを利用者に通知する。

トークン化サーバ４０は、登録端末２０から受信したクレジットカード番号に対して、代替ＩＤを生成する（ステップＳ１４）。代替ＩＤは、トークン化サーバ４０にてクレジットカード番号と対応付けられている。トークン化サーバ４０は、生成した代替ＩＤを登録端末２０に送信する（ステップＳ１５）。

代替ＩＤを受信すると、登録端末２０は、ＩＣタグ７０を、登録端末２０におけるＩＣタグへの情報の書き込み部へ配置することを要求する。そして、登録端末２０は、ＩＣタグ７０に代替ＩＤを送信して、ＩＣタグ７０に代替ＩＤを記憶させる（ステップＳ１６）。

登録端末２０は、決済許可条件に含まれる条件の登録端末２０への入力を利用者に要求する。具体的には、登録端末２０は、上限金額の入力を要求する。利用者が登録端末２０の操作部を操作することによって、登録端末２０に上限金額が入力される（ステップＳ１７）。なお、登録端末２０は、上限金額が、クレジットカード６０の利用可能額を超えないように、上限金額の入力を制限する。上限金額が利用可能額を超えないか否かは、登録端末２０が決済サーバ５０から必要な情報を取得することによって判断されればよい。
登録端末２０は、トークン化サーバ４０から受信した代替ＩＤと、入力された上限金額とを、情報管理サーバ１０に送信する（ステップＳ１８）。

情報管理サーバ１０の条件データ管理部１３ａは、登録端末２０から受信した代替ＩＤと、上限金額と決済可能期間とを含む決済許可条件とを対応付けて、条件データ１２ａとして記憶部１２に記憶させる（ステップＳ１９）。決済可能期間は、記憶部１２に記憶されていて、条件データ管理部１３ａは記憶部１２から決済可能期間を取得してもよい。あるいは、決済可能期間は、登録端末２０に記憶されていて代替ＩＤおよび上限金額とともに情報管理サーバ１０に送信されてもよい。すなわち、条件データ管理部１３ａは通信部１１を介して登録端末２０から決済可能期間を取得してもよい。これにより、代替ＩＤと決済許可条件とが情報管理サーバ１０に登録される。

なお、決済可能期間も、利用者による操作部の操作を通じて登録端末２０に入力され、登録端末２０から情報管理サーバ１０に送信されてもよい。決済許可条件は、そのすべてが登録端末２０から情報管理サーバ１０に送信されてもよいし、そのすべてが記憶部１２に記憶されていてもよいし、決済許可条件の一部が登録端末２０から情報管理サーバ１０に送信され、決済許可条件の残部が記憶部１２に記憶されていてもよい。すなわち、決済許可条件に含まれる条件のすべてが外部取得条件であってもよいし、すべてが外部取得条件でなくてもよいし、一部が外部取得条件であってもよい。
また、登録端末２０から情報管理サーバ１０への代替ＩＤ等の送信が行われた後に、ＩＣタグ７０への代替ＩＤの書き込みが行われてもよい。

なお、１つのクレジットカード６０を用いて、ステップＳ１０〜ステップＳ１９の処理が繰り返されることによって、同一のクレジットカード番号に対応付けられた複数の代替ＩＤと、これらの複数の代替ＩＤの各々に対応付けられた決済許可条件とを含む条件データ１２ａが構築される。１つのクレジットカード６０が用いられる場合、２回目以降の処理については、ステップＳ１３以降の処理が繰り返されてもよい。これらの場合、登録端末２０は、同一のクレジットカード番号に対応付けられた複数の代替ＩＤの各々に対応付けられる上限金額の合計が、クレジットカード６０の利用可能額を超えないように、上限金額の入力を制限する。

続いて、図４を参照して、利用者がイベント会場内の店舗で商品やサービスを購入した際に行われる代金の支払いの手順について説明する。支払いには、支払端末３０とＩＣタグ７０とが用いられる。利用者は、代替ＩＤを記憶したＩＣタグ７０を携帯してイベントに参加し、商品等を購入する。

図４が示すように、商品等の代金を支払おうとする利用者が、ＩＣタグ７０を、支払端末３０におけるＩＣタグからの情報の読み取り部にかざすことによって、支払端末３０はＩＣタグ７０から代替ＩＤを読み取る（ステップＳ２０）。

また、支払端末３０には、支払端末３０における操作部の操作等を通じて、決済要求金額が入力される（ステップＳ２１）。なお、決済要求金額の入力の後に、代替ＩＤの読み取りが行われてもよい。
支払端末３０は、代替ＩＤと決済要求金額とを情報管理サーバ１０に送信する（ステップＳ２２）。

情報管理サーバ１０の通信部１１が、支払端末３０から代替ＩＤと決済要求金額とを受信することに基づき、決済可否判定部１３ｂは、代替ＩＤと決済要求金額とを受け付け、決済要求情報を取得する。決済可否判定部１３ｂは、受け付けた代替ＩＤと条件データ１２ａにて対応付けられている決済許可条件を特定する（ステップＳ２３）。

そして、決済可否判定部１３ｂは、取得した決済要求情報を用いて、特定した決済許可条件が満たされているか否かを判定する（ステップＳ２４）。すなわち、決済可否判定部１３ｂは、決済要求時が、条件データ１２ａにて特定された決済可能期間に含まれているか否かを判断する。また、決済可否判定部１３ｂは、受け付けた決済要求金額と、受け付けた代替ＩＤと履歴データ１２ｂにて対応付けられている決済要求履歴とを用いて、決済要求合計金額を算出し、決済要求合計金額が条件データ１２ａにて特定された上限金額以下であるか否かを判断する。

決済可否判定部１３ｂは、決済許可条件が満たされていると判定したとき、今回の決済要求で受け付けた代替ＩＤと、今回の決済要求についての情報のうちの少なくとも決済要求金額とを対応付けて、履歴データ１２ｂとして記憶部１２に記憶させる（ステップＳ２５）。

さらに、決済可否判定部１３ｂは、決済許可条件が満たされていると判定したとき、今回の決済要求で受け付けた代替ＩＤと、今回の決済要求で受け付けた決済要求金額とを対応付けて、通信部１１を介してトークン化サーバ４０に送信する（ステップＳ２６）。なお、決済可否判定部１３ｂは、代替ＩＤと決済要求金額とをトークン化サーバ４０に送信した後に、履歴データ１２ｂの登録を行ってもよい。

トークン化サーバ４０は、情報管理サーバ１０から受信した代替ＩＤとトークン化サーバ４０にて対応付けられているクレジットカード番号を特定する（ステップＳ２７）。そして、トークン化サーバ４０は、特定したクレジットカード番号と情報管理サーバ１０から受信した決済要求金額とを決済サーバ５０に送信する（ステップＳ２８）。

決済サーバ５０は、トークン化サーバ４０から受信したクレジットカード番号と決済要求金額とに基づいて、クレジットカード６０についての決済処理を行う（ステップＳ２９）。

なお、決済可否判定部１３ｂは、決済許可条件が満たされていないと判定したときには、決済が許可されないことを支払端末３０に通知する。これを受けて、支払端末３０では、決済が許可されないことが表示部に表示されて、利用者に通知される。

また、情報管理サーバ１０からトークン化サーバ４０への代替ＩＤと決済要求金額との送信は、決済可否判定部１３ｂによる決済許可条件が満たされているとの判定の都度行われなくてもよい。例えば、情報管理サーバ１０からトークン化サーバ４０へは、一定の期間ごとに、その期間内に決済が許可されると判定された決済要求における代替ＩＤと決済要求金額とが、まとめて送信されてもよい。要は、決済許可条件が満たされていると判定された場合における決済要求金額が、その決済可否の判定に用いられた決済許可条件に条件データ１２ａにて対応付けられている代替ＩＤと対応付けて出力されればよい。

［作用］
第１実施形態の作用について説明する。第１実施形態の決済システムでは、情報管理サーバ１０にはクレジットカード番号に代えて代替ＩＤが記憶されており、代金の支払いに際して、情報管理サーバ１０と支払端末３０とは、代替ＩＤを授受し、クレジットカード番号の授受は行わない。

このように、支払端末３０からの決済の要求に対し、決済が許可されるか否かを判定するサーバ、すなわち、決済に付随して生じる処理を行うサーバである情報管理サーバ１０には、決済に付随して生じる処理に用いられる情報である決済許可条件とともに代替ＩＤが記憶され、クレジットカード番号は記憶されない。したがって、こうしたサーバにクレジットカード番号が記憶される場合と比較して、クレジットカード番号の流出が抑えられるため、クレジットカードの利用に対するセキュリティが高められる。また、支払いに際して、支払端末３０にクレジットカード番号を入力する必要もないため、支払時に店舗にて用いられる端末からクレジットカード番号が流出することも抑えられる。

また、利用者が携帯するＩＣタグ７０には代替ＩＤが記憶され、クレジットカード番号は記憶されないため、ＩＣタグ７０を紛失することがあったとしても、クレジットカード番号が流出することが抑えられる。さらには、ＩＣタグ７０の携帯によって代金の支払いが可能であるため、クレジットカードの紛失の虞が低減され、また、利用者が財布から現金やカードを取り出す手間も削減される。

なお、ＩＣタグ７０の利用される範囲は、イベント会場内等の限定された状況にとどめられるため、ＩＣタグ７０の準拠する通信規格は特に限定されず、ＩＣタグ７０と登録端末２０および支払端末３０との間で同一の通信規格が用いられていればよい。したがって、通信規格の選択の自由度が高まるため、決済システムの導入に要する費用を抑えることもできる。

また、第１実施形態では、情報管理サーバ１０が、代替ＩＤごとに決済許可条件を記憶し、代替ＩＤごとの決済許可条件に応じて決済が許可されるか否かを判定する。したがって、代替ＩＤごとに、クレジットカードによる決済に際しての細かな条件を設定して、こうした条件に基づいて決済を進めることが可能である。具体的には、クレジットカードの契約における有効期限とは異なる細かい単位、例えば、日単位や分単位での決済可能期間が設定され、上記契約における利用限度額とは異なる細かい単位、例えば、千円単位での上限金額が設定される。これによって、利用者は、決済可能期間内において上限金額まで利用可能な、一時的な決済手段を得ることができる。決済の許可される期間と金額とが制限されることによって、ＩＣタグ７０の紛失や盗難に起因して不正な決済が行われたとしても、利用者が受ける不利益は小さく留められる。また、決済の許可される金額が制限されることによって、利用者による金銭の使い過ぎも抑えられる。

また、決済許可条件のうちの外部取得条件は、登録端末２０から情報管理サーバ１０に送信される条件であり、登録端末２０にて外部取得条件の設定が可能である。具体的には、利用者が任意に上限金額を決定することができる。したがって、決済許可条件の設定についての自由度が高められる。

そして、上述のような、情報管理サーバ１０における代替ＩＤと決済許可条件との対応付けは、情報管理サーバ１０が登録端末２０から代替ＩＤを受信したときに行われる。したがって、簡易な手順で代替ＩＤと決済許可条件とが登録され、一時的な決済手段の利用が可能となる。例えば、イベントの参加者は、イベントの前に予め登録を行わずとも、イベント会場にて、既に所有しているクレジットカードを用いて代替ＩＤと決済許可条件との登録を行えば、一時的な決済手段の利用を開始することができる。したがって、例えば、海外からの来訪者等、事前に手続きを行うことが煩雑である利用者も、容易に、一時的な決済手段を得ることができる。

このように、第１実施形態の決済システムを利用することによって、利用者は、事前の登録や、長期に渡るカード等の媒体の管理や、入金の処理等を要することなく、簡易に、一時的な決済手段を得ることができる。またクレジットカードであれば、その種類に関わりなく、代替ＩＤと対応付けることによって、第１実施形態の決済システムに利用可能である。

このように代替ＩＤと決済許可条件との登録に際して事前の審査等が行われなかったとしても、登録時には、カード認証情報を用いて利用者の提示するクレジットカード６０の認証が行われるため、クレジットカードによる決済に際しての利用者の本人確認は可能である。また、決済システムによって提供される決済手段は、決済可能期間と上限金額とが制限された一時的な決済手段であるため、この決済手段の不正な利用が行われたとしても、上述のように、不利益は小さく留められる。

また、同一のクレジットカード番号に対して、利用者ごとに代替ＩＤが生成され、条件データ１２ａにて、同一のクレジットカード番号に対応付けられた複数の代替ＩＤの各々に、決済許可条件が対応付けられている構成では、１つのクレジットカードを利用した決済を、例えば家族等のように、複数の利用者が利用することが可能である。また、こうした複数の利用者による決済の各々に対して、互いに異なる決済許可条件を課すことができる。例えば、利用者ごとの代替ＩＤに対応付ける決済許可条件として、互いに異なる上限金額を設定することもできる。したがって、決済に１つのクレジットカードを利用する場合であっても、利用者ごとに細かな条件を設定して、こうした条件に基づいて決済を進めることが可能である。したがって、利用者の利便性が高められる。

なお、情報管理サーバ１０にて決済許可条件と対応付けられる情報が固有情報であり、第１実施形態において、固有情報は代替情報のみを含む。また、支払端末３０から決済要求金額とともに情報管理サーバ１０に送信されて、条件データ１２ａにおける決済許可条件の特定に用いられる情報が照合情報であり、第１実施形態において、照合情報は代替情報である。すなわち、照合情報は固有情報に含まれる情報である。

以上説明したように、第１実施形態によれば、以下に列挙する効果を得ることができる。
（１）決済に付随して生じる処理として、決済が許可されるか否かを判定する情報管理サーバ１０には、決済に付随して生じる処理に用いられる情報である決済許可条件とともにクレジットカード番号の代替である代替ＩＤが記憶され、クレジットカード番号は記憶されない。したがって、情報管理サーバ１０にクレジットカード番号が記憶される場合と比較して、クレジットカード番号の流出が抑えられるため、クレジットカードの利用に対するセキュリティが高められる。また、条件データ１２ａにて、固有情報と決済許可条件とが対応付けられるため、固有情報ごと、すなわち、代替ＩＤごとの決済許可条件の設定が可能である。

（２）決済許可条件が決済可能期間を含み、決済要求情報が決済要求時を含む。すなわち、決済の要求されている時についての状況が、決済が許可される期間についての条件を満たすときに、具体的には、決済要求時が決済可能期間に含まれるときに、決済が許可される。したがって、決済の許可される期間を制限することができる。

（３）決済許可条件が上限金額を含み、決済要求情報が決済要求金額を含む。すなわち、決済の要求されている金額についての状況が、決済が許可される上限金額についての条件を満たすときに、決済が許可される。したがって、決済の許可される金額を制限することができる。

具体的には、決済許可条件が満たされていると判定されたとき、決済要求金額は代替ＩＤと対応付けられて履歴データ１２ｂとして記憶される。そして、決済可否判定部１３ｂは、新たな決済要求金額と代替ＩＤとを受け付けたとき、この代替ＩＤと履歴データ１２ｂにて対応付けられている金額と、新たな決済要求金額との合計金額が、上限金額以下であるか否かを判定することによって、決済許可条件が満たされているか否かを判定する。すなわち、決済許可条件が満たされているか否かの判定として、今回の決済要求までに決済の許可された金額と、今回の決済要求における決済要求金額との合計額が、決済が許可される上限金額以下であるか否かが判定される。したがって、過去の利用状況を含めて決済が許可される上限金額が満たされているか否かが判定されるため、決済の許可される金額の制限が的確に行われる。

（４）決済許可条件に含まれる条件の少なくとも一部が、登録端末２０から情報管理サーバ１０が受信した外部設定条件である。すなわち、決済許可条件に含まれる条件の少なくとも一部は、情報管理サーバ１０の外部の装置で設定された条件であるため、決済許可条件の設定の自由度が高められる。

（５）条件データ１２ａにて、複数の代替ＩＤの各々に決済許可条件が対応付けられ、複数の代替ＩＤには、同一のクレジットカード番号に対応付けられた互いに異なる代替ＩＤが含まれる。こうした構成によれば、１つのクレジットカードを利用した決済を複数の利用者が利用することが可能である。また、こうした複数の利用者による決済の各々に対して、互いに異なる決済許可条件を課すことも可能である。

（６）代替ＩＤが、トークンを含む数列を示すため、代替情報が、クレジットカード番号が暗号化された情報である場合と比較して、仮に代替情報が情報管理サーバ１０から流出した場合にも、代替情報に基づいてクレジットカード番号が算出されることが抑えられる。したがって、クレジットカードの利用に対するセキュリティが特に高められる。

（第２実施形態）
図５〜図９を参照して、情報管理サーバ、および、決済システムの第２実施形態について説明する。第２実施形態の決済システムは、第１実施形態の決済システムと比較して、情報管理サーバ１０にて条件データ１２ａとして対応付けられている情報が異なり、こうした情報を利用した処理が異なる。以下では、第１実施形態との相違点を中心に説明し、第１実施形態と同様の構成については同じ符号を付してその説明を省略する。

［決済システムの構成］
第２実施形態において、登録端末２０は、指紋や虹彩や静脈等の、生体認証に利用可能な情報である生体情報を読み取る機能を備えている。生体情報は、利用者ごとに固有の認証情報の一例である。登録端末２０は、情報管理サーバ１０への代替ＩＤの登録に際して、代替ＩＤと決済許可条件に含まれる外部取得条件と利用者の生体情報とを情報管理サーバ１０に送信する。

また、登録端末２０は、代替ＩＤと生体情報とを情報管理サーバ１０に送信して、決済許可条件や決済要求履歴の送信、あるいは、決済許可条件を用いた処理の禁止を要求する。

支払端末３０は、登録端末２０と同様に、生体情報を読み取る機能を備えている。支払端末３０は、決済の要求の結果、情報管理サーバ１０から、決済要求合計金額が上限金額を超えているために決済許可条件が満たされず、決済が許可されない旨の通知を受けたとき、生体情報と新たな上限金額との入力を受け付け、入力された生体情報と新たな上限金額とを情報管理サーバ１０に送信する。

情報管理サーバ１０の条件データ管理部１３ａは、通信部１１が登録端末２０から受信した代替ＩＤおよび生体情報と、決済許可条件とを対応付けて記憶部１２に記憶させ、条件データ１２ａを構築する。すなわち、第２実施形態において、条件データ１２ａでは、代替ＩＤと生体情報と決済許可条件とが対応付けられている。

条件データ管理部１３ａは、通信部１１が支払端末３０から生体情報と新たな上限金額とを受信したとき、受信した生体情報と、今回の決済要求で受け付けた代替ＩＤに条件データ１２ａにて対応付けられている生体情報との照合を行う。そして、条件データ管理部１３ａは、これらの生体情報が一致すると判定したとき、今回の決済要求で受け付けた代替ＩＤに条件データ１２ａにて対応付けられている上限金額を、支払端末３０から受信した新たな上限金額に変更する。すなわち、条件データ管理部１３ａは、決済可否判定部１３ｂが上限金額の超過によって決済許可条件が満たされていないと判定したとき、上限金額の変更を受け付ける。

また、条件データ管理部１３ａは、通信部１１が登録端末２０から代替ＩＤと生体情報とを受信したとき、登録端末２０から決済許可条件の送信を要求されている場合には、登録端末２０から受信した代替ＩＤに条件データ１２ａにて対応付けられている生体情報および決済許可条件を特定する。そして、条件データ管理部１３ａは、登録端末２０から受信した生体情報と、条件データ１２ａにて特定された生体情報との照合を行い、これらの生体情報が一致すると判定したとき、特定した決済許可条件を、通信部１１を介して登録端末２０に送信する。

また、条件データ管理部１３ａは、通信部１１が登録端末２０から代替ＩＤと生体情報とを受信したとき、登録端末２０から決済要求履歴の送信を要求されている場合には、登録端末２０から受信した代替ＩＤに条件データ１２ａにて対応付けられている生体情報を特定する。そして、条件データ管理部１３ａは、登録端末２０から受信した生体情報と、条件データ１２ａにて特定された生体情報との照合を行う。条件データ管理部１３ａは、これらの生体情報が一致すると判定したとき、登録端末２０から受信した代替ＩＤに履歴データ１２ｂにて対応付けられている決済要求履歴を特定し、特定した決済要求履歴を、通信部１１を介して登録端末２０に送信する。

また、条件データ管理部１３ａは、通信部１１が登録端末２０から生体情報を受信したとき、登録端末２０から決済許可条件を用いた処理の禁止を要求されている場合には、条件データ１２ａが含む生体情報のなかから、登録端末２０から受信した生体情報と一致すると判定される生体情報を特定する。そして、特定された生体情報に条件データ１２ａにて対応付けられている決済許可条件を用いた処理を禁止する。すなわち、この決済許可条件を用いた決済可否判定部１３ｂによる判定や、決済許可条件の変更が禁止される。具体的には、条件データ管理部１３ａは、決済許可条件を用いた処理を禁止する処理として、条件データ１２ａにおける決済許可条件や代替ＩＤを消去してもよいし、条件データ１２ａにおける決済許可条件や代替ＩＤに、これらの決済許可条件や代替ＩＤが無効であって、処理に用いることができないことを示す情報を付してもよい。

このように、第２実施形態において、条件データ管理部１３ａは、認証部として機能し、登録端末２０や支払端末３０から所定の処理の要求を受けたとき、通信部１１が受信した生体情報と、条件データ１２ａに含まれる生体情報との一致を確認することに基づいて、所定の処理の実行を許容する。所定の処理には、上述のように、決済許可条件の変更や、決済許可条件や決済要求履歴の送信や、決済許可条件を用いた処理の禁止が含まれる。生体情報の照合には、公知の生体認証技術が用いられればよい。
［条件データの構成］
図５を参照して、条件データ１２ａにおける代替ＩＤと生体情報と決済許可条件との対応関係について説明する。

図５が示すように、条件データ１２ａにおいて、１つの代替ＩＤと１つの生体情報とが対応付けられている。そして、１つの代替ＩＤと１つの生体情報とに、決済許可条件として、１つの上限金額と１つの決済可能期間とが対応付けられている。

例えば、「１２３４−３３３３−５６７８−７７７７」という代替ＩＤと、「指紋Ａ」を示す生体情報と、「７月１２日９時〜７月１２日２０時」を示す決済可能期間と、「３万円」を示す上限金額とが対応付けられている。

互いに異なる代替ＩＤには、互いに異なる生体情報が対応付けられている。条件データ１２ａは、１つの代替ＩＤと１つの生体情報との組を複数含み、これらの組の各々には、互いに異なる上限金額や決済可能期間が対応付けられていてもよいし、同一の上限金額や決済可能期間が対応付けられていてもよい。

［決済システムの処理手順］
第２実施形態の決済システムによって決済が行われる手順について説明する。決済システムによる処理には、代替ＩＤ、生体情報、および、決済許可条件の登録の処理と、代金の支払いの処理と、決済許可条件や決済要求履歴の確認の処理と、決済許可条件を用いた処理の禁止の処理とが含まれる。
まず、図６を参照して、代替ＩＤ、生体情報、および、決済許可条件の登録の手順について説明する。

代替ＩＤ、生体情報、および、決済許可条件の登録の手順は、第１実施形態における代替ＩＤおよび決済許可条件の登録の手順と、登録端末２０がトークン化サーバ４０から代替ＩＤを取得するまでは同じである。すなわち、第２実施形態においても、先の図３に示したステップＳ１０〜ステップＳ１５と同様の手順で、クレジットカード６０が利用可能であることの確認と、代替ＩＤの取得とが行われる。登録端末２０がトークン化サーバ４０から代替ＩＤを取得した後の処理について、図６を参照して説明する。
図６が示すように、代替ＩＤを受信すると、登録端末２０は、ＩＣタグ７０に代替ＩＤを送信して、ＩＣタグ７０に代替ＩＤを記憶させる（ステップＳ３０）。

登録端末２０は、生体情報の登録端末２０への入力を利用者に要求する。利用者が登録端末２０における生体情報の読み取り部に対して、例えば生体情報が指紋を示す情報である場合には指を置く等の所定の操作を行うことによって、登録端末２０は利用者の生体情報を読み取り、登録端末２０に生体情報が入力される（ステップＳ３１）。

また、登録端末２０は、決済許可条件に含まれる条件の登録端末２０への入力を利用者に要求する。具体的には、登録端末２０は、上限金額の入力を要求する。利用者が登録端末２０の操作部を操作することによって、登録端末２０に上限金額が入力される（ステップＳ３２）。なお、生体情報の入力よりも前に、決済許可条件の入力が行われてもよい。

登録端末２０は、トークン化サーバ４０から受信した代替ＩＤと、入力された生体情報および上限金額とを、情報管理サーバ１０に送信する（ステップＳ３３）。

情報管理サーバ１０の条件データ管理部１３ａは、登録端末２０から受信した代替ＩＤおよび生体情報と、上限金額および決済可能期間を含む決済許可条件とを対応付けて、条件データ１２ａとして記憶部１２に記憶させる（ステップＳ３４）。これにより、代替ＩＤと生体情報と決済許可条件とが情報管理サーバ１０に登録される。なお、登録端末２０から情報管理サーバ１０への代替ＩＤ等の送信が行われた後に、ＩＣタグ７０への代替ＩＤの書き込みが行われてもよい。

続いて、図７を参照して、代金の支払いの手順について説明する。以下では、決済要求合計金額が上限金額を超えているために決済許可条件が満たされないと判定される場合の処理について説明する。

図７が示すように、ステップＳ４０〜ステップＳ４４の処理は、第１実施形態にて説明した先の図４のステップＳ２０〜ステップＳ２４の処理と同様の処理である。

ここで、ステップＳ４４の処理において、決済可否判定部１３ｂが、決済要求合計金額が上限金額を超えているために決済許可条件が満たされないと判定したとする。このとき、決済可否判定部１３ｂは、決済要求合計金額が上限金額を超えているために決済が許可されない旨の通知を支払端末３０に送信する（ステップＳ４５）。

通知を受けた支払端末３０は、決済要求合計金額が上限金額を超えているために決済が許可されないことを表示部に表示して利用者に通知し、上限金額の変更を行うか否かの選択を利用者に要求する。上限金額の変更が選択されたとき、支払端末３０は、生体情報の登録端末２０への入力を利用者に要求する。利用者が支払端末３０における生体情報の読み取り部に対して所定の操作を行うことによって、支払端末３０は利用者の生体情報を読み取り、支払端末３０に生体情報が入力される（ステップＳ４６）。

また、支払端末３０は、新たな上限金額の入力を利用者に要求し、利用者が操作部を操作することによって、支払端末３０に新たな上限金額が入力される（ステップＳ４７）。新たな上限金額は、条件データ１２ａとして情報管理サーバ１０に記憶されている上限金額よりも高い金額である。なお、生体情報の入力よりも前に、新たな上限金額の入力が行われてもよい。

支払端末３０は、入力された生体情報と新たな上限金額とを情報管理サーバ１０に送信する（ステップＳ４８）。これにより、情報管理サーバ１０に上限金額の変更が要求される。

情報管理サーバ１０にて、通信部１１が支払端末３０から生体情報と新たな上限金額とを受信すると、条件データ管理部１３ａは、受信した生体情報と、ステップＳ４３にて特定された決済許可条件に条件データ１２ａにて対応付けられている生体情報とを照合することによって、認証処理を行う（ステップＳ４９）。換言すれば、条件データ管理部１３ａは、支払端末３０から受信した生体情報と、決済要求金額とともに支払端末３０から受信した代替ＩＤに条件データ１２ａにて対応付けられている生体情報とが一致するか否かを判定する。

認証が成立したとき、すなわち、生体情報が一致すると判定されたとき、条件データ管理部１３ａは、決済要求金額とともに支払端末３０から受信した代替ＩＤに条件データ１２ａにて対応付けられている上限金額、すなわち、ステップＳ４３にて特定された上限金額を、新たな上限金額に変更する（ステップＳ５０）。なお、認証が成立しない場合、すなわち、生体情報が一致しないと判定される場合には、認証が成立しない旨の通知が情報管理サーバ１０から支払端末３０に送信される。

以後、第１実施形態にて説明した先の図４のステップＳ２４〜ステップＳ２９と同様の処理が行われる。すなわち、決済可否判定部１３ｂは、変更された上限金額を含む決済許可条件が満たされているか否かを判定し、決済許可条件が満たされていると判定したとき、代替ＩＤと決済要求金額とを対応付けて、履歴データ１２ｂとして記憶部１２に記憶させ、かつ、トークン化サーバ４０に送信する。そして、トークン化サーバ４０から代替ＩＤに対応するクレジットカード番号と決済要求金額とが決済サーバ５０に送信されて、決済サーバ５０で決済処理が行われる。

なお、上述の手順では、生体情報と新たな上限金額とが一度に情報管理サーバ１０に送信されたが、これらの情報は順に送信されてもよい。すなわち、まず、支払端末３０から情報管理サーバ１０に生体情報が送信され、情報管理サーバ１０にて認証処理が行われて認証が成立したことが支払端末３０に通知された後に、支払端末３０から情報管理サーバ１０に新たな上限金額が送信されて、条件データ１２ａにおける上限金額の変更が行われてもよい。

続いて、図８を参照して、決済許可条件や決済要求履歴の確認の手順について説明する。決済許可条件や決済要求履歴の確認は、例えば、利用者が、イベントに参加している途中に、上限金額や決済が許可された金額等を確認したい場合に行われる。図８は、決済許可条件の確認の手順を示している。

図８が示すように、利用者が、ＩＣタグ７０を、登録端末２０におけるＩＣタグからの情報の読み取り部にかざすことによって、登録端末２０はＩＣタグ７０から代替ＩＤを読み取る（ステップＳ６０）。

また、利用者が、登録端末２０における生体情報の読み取り部に対して、所定の操作を行うことによって、登録端末２０は、利用者の生体情報を読み取り、登録端末２０に生体情報が入力される（ステップＳ６１）。なお、代替ＩＤの読み取りよりも前に、生体情報の入力が行われてもよい。
登録端末２０は、取得した代替ＩＤと生体情報とを情報管理サーバ１０に送信して、決済許可条件の送信を要求する（ステップＳ６２）。

登録端末２０から決済許可条件の送信の要求を受けると、情報管理サーバ１０の条件データ管理部１３ａは、登録端末２０から受信した代替ＩＤに条件データ１２ａにて対応付けられている生体情報および決済許可条件を特定する（ステップＳ６３）。条件データ管理部１３ａは、登録端末２０から受信した生体情報と、特定した生体情報とを照合することによって、認証処理を行う（ステップＳ６４）。

認証が成立したとき、すなわち、生体情報が一致すると判定されるとき、条件データ管理部１３ａは、特定した決済許可条件を、通信部１１を介して登録端末２０に送信する（ステップＳ６５）。なお、認証が成立しない場合、すなわち、生体情報が一致しないと判定される場合には、認証が成立しない旨の通知が情報管理サーバ１０から登録端末２０に送信される。

情報管理サーバ１０から決済許可条件を受信すると、登録端末２０は、表示部に決済許可条件を表示する（ステップＳ６６）。これにより、利用者は、決済可能期間や上限金額を確認することができる。

なお、登録端末２０は、決済許可条件の一部、例えば上限金額のみの送信を情報管理サーバ１０に要求してもよく、情報管理サーバ１０は要求に応じた条件を登録端末２０に送信すればよい。登録端末２０がいずれの条件の送信を要求するかは、利用者によって選択されて、登録端末２０の操作部を通じて指定されればよい。

また、上述の手順では、代替ＩＤと生体情報とが一度に情報管理サーバ１０に送信されたが、これらの情報は順に送信されてもよい。すなわち、まず、支払端末３０から情報管理サーバ１０に代替ＩＤが送信され、情報管理サーバ１０にて生体情報および決済許可条件が特定された後に、登録端末２０への生体情報の入力が要求され、登録端末２０から情報管理サーバ１０に生体情報が送信されて、認証処理が行われてもよい。

また、ステップＳ６２の処理にて、登録端末２０が、決済許可条件に代えて決済要求履歴の送信を情報管理サーバ１０に要求することによって、決済要求履歴の確認が可能である。この場合、条件データ管理部１３ａは、登録端末２０から受信した生体情報と、登録端末２０から受信した代替ＩＤに条件データ１２ａにて対応付けられている生体情報とを照合することによって、認証処理を行う。そして、認証が成立したとき、条件データ管理部１３ａは、登録端末２０から受信した代替ＩＤに履歴データ１２ｂにて対応付けられている決済要求履歴を登録端末２０に送信する。登録端末２０が、表示部に決済要求履歴を表示することによって、利用者は、その時点までに決済が許可された金額等を確認することができる。なお、登録端末２０は、決済要求履歴の一部のみの送信を情報管理サーバ１０に要求してもよく、情報管理サーバ１０は要求に応じた情報を登録端末２０に送信すればよい。

登録端末２０が、決済許可条件と決済要求履歴とのいずれの送信を情報管理サーバ１０に要求するかは、利用者によって選択されて、登録端末２０の操作部を通じて指定されればよい。また、登録端末２０は、決済許可条件と決済要求履歴との両方の送信を情報管理サーバ１０に要求してもよい。

なお、上述の手順では、登録端末２０への代替ＩＤと生体情報との入力を通じて決済許可条件や決済要求履歴の確認が行われたが、登録端末２０に代えて、支払端末３０が用いられてもよい。また、登録端末２０や支払端末３０とは異なる端末であって、ＩＣタグからの情報の読み取り機能や生体情報の読み取り機能を備える端末が、決済許可条件や決済要求履歴の確認のために用いられてもよい。

続いて、図９を参照して、決済許可条件を用いた処理を禁止する手順について説明する。決済許可条件を用いた処理の禁止は、利用者がイベント会場にてＩＣタグ７０を紛失し、このＩＣタグ７０を第三者が利用して不正に決済を行うことを防ぎたい場合に行われる。

図９が示すように、利用者が、登録端末２０における生体情報の読み取り部に対して、所定の操作を行うことによって、登録端末２０は、利用者の生体情報を読み取り、登録端末２０に生体情報が入力される（ステップＳ７０）。

登録端末２０は、入力された生体情報を情報管理サーバ１０に送信して、決済許可条件を用いた処理の禁止を要求する（ステップＳ７１）。登録端末２０が決済許可条件を用いた処理の禁止を要求することは、例えば、利用者がこうした処理を求めていることが、操作部を通じて登録端末２０に入力されることに基づいて行われる。

登録端末２０から決済許可条件を用いた処理の禁止の要求を受けると、情報管理サーバ１０の条件データ管理部１３ａは、条件データ１２ａが含む生体情報のなかから、登録端末２０から受信した生体情報と一致すると判定される生体情報を特定する（ステップＳ７２）。そして、条件データ管理部１３ａは、特定された生体情報と条件データ１２ａにて対応付けられている決済許可条件を用いた処理を禁止する処理を行う（ステップＳ７３）。

なお、上述の手順では、登録端末２０への生体情報の入力を通じて決済許可条件を用いた処理の禁止が行われたが、登録端末２０に代えて、支払端末３０が用いられてもよい。また、登録端末２０や支払端末３０とは異なる端末であって、生体情報の読み取り機能を備える端末が、決済許可条件を用いた処理の禁止のために用いられてもよい。

［作用］
第２実施形態の作用について説明する。第２実施形態の決済システムでは、条件データ１２ａにおける決済許可条件の変更が行われる。したがって、決済許可条件の設定の自由度が高められ、決済の利用の程度に応じて条件の変更を行うこともできるため、利用者の利便性が高められる。

特に、上限金額の超過によって決済許可条件が満たされていないと判定されたとき、上限金額の変更が可能であるため、利用者が上限金額を変更したいと望むことが多い状況において上限金額の引き上げが可能である。したがって、利用者の利便性がより高められる。

また、第２実施形態の決済システムでは、条件データ１２ａにて、代替ＩＤと生体情報と決済許可条件とが対応付けられており、情報管理サーバ１０が行う各処理に先立って、生体情報を用いた認証処理が行われる。すなわち、これらの処理に先立って、各処理を求める利用者が、生体情報の登録を行った本人であることが確認され、これによって、各処理が利用者本人の了承が得られた処理であることが確認される。したがって、情報管理サーバ１０が行う処理の実行に対するセキュリティが高められる。

そして、こうした認証後に行われる処理には、決済許可条件や決済要求履歴の登録端末２０や支払端末３０への送信が含まれる。利用者は、決済許可条件や決済要求履歴の確認が可能であるため、こうした情報を参照しつつ商品やサービスを購入することができる。したがって、利用者の利便性が高められる。

また、ＩＣタグ７０の紛失によって代替ＩＤが不明である場合であっても、生体情報の照合によって、この生体情報と対応付けられている代替ＩＤや決済許可条件の特定が可能である。そして、特定された決済許可条件を用いた処理が禁止されることによって、紛失したＩＣタグ７０が不正に利用されて決済が行われることが抑えられる。
なお、第２実施形態において、固有情報は代替情報と認証情報とを含む。また、第２実施形態においても、照合情報は代替情報である。

以上説明したように、第２実施形態によれば、第１実施形態の（１）〜（６）の効果に加えて、以下に列挙する効果を得ることができる。
（７）情報管理サーバ１０が代替ＩＤと新たな決済許可条件とを受信したとき、すなわち、新たな外部取得条件を受信したとき、当該代替ＩＤに条件データ１２ａにて対応付けられている外部取得条件が、新たな外部取得条件に変更される。こうした構成によれば、決済許可条件に含まれる条件の変更が可能であるため、決済許可条件の設定の自由度が高められる。

特に、上記外部取得条件は上限金額であり、上限金額の超過によって決済許可条件が満たされていないと判定されたとき、外部取得条件の変更が受け付けられる。したがって、決済の要求されている金額についての状況が上限金額の超過に該当する場合に上限金額の引き上げが可能であるため、利用者の利便性が高められる。

（８）条件データ１２ａにて、代替ＩＤと生体情報と決済許可条件とが対応付けられ、情報管理サーバ１０が、登録端末２０や支払端末３０から所定の処理の要求を受けたとき、これらの端末から情報管理サーバ１０が受信した生体情報と、条件データ１２ａに含まれる生体情報との一致が確認されることに基づいて、所定の処理の実行が許容される。こうした構成によれば、情報管理サーバ１０の外部から受信した生体情報と情報管理サーバ１０が記憶している生体情報との一致の確認に基づいて、所定の処理の実行が許容されるため、所定の処理の実行に対するセキュリティが高められる。

特に、上記所定の処理に、一致が確認された生体情報と条件データ１２ａにて対応付けられている決済許可条件の登録端末２０や支払端末３０への送信、当該決済許可条件の変更、および、当該決済許可条件を用いた処理の禁止が含まれるため、これらの処理の実行に対するセキュリティが高められる。

（変形例）
上記各実施形態は、以下のように変更して実施することが可能である。
・第２実施形態において、決済要求合計金額が上限金額を超えた場合以外にも、条件データ１２ａにおける上限金額の変更が可能であってもよい。例えば、登録端末２０から、代替ＩＤ、生体情報、および、登録端末２０に入力された新たな上限金額が情報管理サーバ１０に送信され、上限金額の変更が要求される。情報管理サーバ１０の条件データ管理部１３ａは、受信した代替ＩＤに条件データ１２ａにて対応付けられている生体情報と上限金額とを特定し、生体情報の照合を行って認証が成立した場合には、特定した上限金額を新たな上限金額に変更する。
また、変更可能な条件は、決済許可条件に含まれる条件であれば、上限金額に限られない。

・第２実施形態において、生体情報を用いた認証を経て行われる処理は、決済許可条件の変更、決済許可条件や決済要求履歴の送信、および、決済許可条件を用いた処理の禁止の処理のうちのいずれか１つ、もしくは、これらの処理のうちの２つであってもよい。また、生体情報を用いた認証を経て行われる処理には、これらの処理以外の処理が含まれてもよく、例えば、決済可否の判定が含まれてもよい。この場合、代金の支払いの処理に際して、支払端末３０から、代替ＩＤと生体情報と決済要求金額とが情報管理サーバ１０に送信され、情報管理サーバ１０の条件データ管理部１３ａは、受信した代替ＩＤに条件データ１２ａにて対応付けられている生体情報と決済許可条件とを特定し、生体情報の照合を行う。そして、認証が成立した場合に、決済可否判定部１３ｂは、特定された決済許可条件を用いて決済可否の判定を行う。

・第２実施形態において、代金の支払いの処理に代替ＩＤが用いられなくてもよい。すなわち、支払端末３０から、生体情報と決済要求金額とが情報管理サーバ１０に送信され、情報管理サーバ１０の決済可否判定部１３ｂは、条件データ１２ａにて、受信した生体情報と一致すると判定される生体情報を特定し、この生体情報に対応付けられている決済許可条件を特定する。そして、決済可否判定部１３ｂは、特定された決済許可条件を用いて決済可否の判定を行う。この場合、照合情報は生体情報、すなわち、認証情報である。

また同様に、決済許可条件の登録端末２０や支払端末３０への送信に際しても、代替ＩＤが用いられずに、生体情報によって条件データ１２ａにおける決済許可条件が特定されてもよい。

こうした場合、ＩＣタグ７０は利用されなくてよいため、利用者は物品を携帯せずとも代金の支払いを行うことが可能であり。利用者の利便性が高められる。また、ＩＣタグ７０の紛失の虞もなくなるため、不正な決済が行われる可能性も低減できる。

・生体情報を用いた認証を経ずに、決済許可条件の変更や、決済許可条件や決済要求履歴の登録端末２０や支払端末３０への送信が行われてもよい。すなわち、第１実施形態において、登録端末２０から代替ＩＤが送信されて決済許可条件や決済要求履歴の送信の要求が行われ、情報管理サーバ１０は、代替ＩＤに基づいて決済許可条件や決済要求履歴を特定し、これらの情報を登録端末２０に送信してもよい。また、決済要求合計金額が上限金額を超えた場合には、支払端末３０に入力された新たな上限金額が情報管理サーバ１０に送信されて、生体情報の認証が行われずに、上限金額が変更されてもよい。

・上記実施形態において、決済要求時は日時を示したが、決済要求時は、決済の要求されている時であればよく、例えば時刻を示してもよい。同様に、決済可能期間は、所定の期間であればよく、例えば、１日のなかの特定の時刻から特定の時刻までの間の期間に限らず、特定の日から特定の日までの期間であってもよい。要は、決済可能期間のなかに決済要求時が含まれるか否かが判定可能なように、決済要求時の示す情報と決済可能期間の示す情報とが規定されればよい。

・決済許可条件に含まれる条件は、決済可能期間や上限金額に限られない。例えば、決済許可条件には、決済の可能な店舗が含まれてもよい。この場合、情報管理サーバ１０は、決済要求に際して支払端末３０から決済要求情報として店舗情報を取得し、店舗情報の示す店舗が決済の可能な店舗であるか否かを判断することによって、決済許可条件が満たされているか否かを判定する。なお、決済許可条件には、決済可能期間および上限金額の一方のみが含まれてもよいし、決済可能期間および上限金額の双方が含まれなくてもよい。

・第２実施形態において、認証情報は、利用者ごとに固有の情報であればよく、例えば、暗証番号やパスワード等であってもよいし、利用者がＩＣタグ７０を紛失した際に決済許可条件を用いた処理の禁止を行わない前提であれば、利用者が携帯するＩＣタグ７０が記憶しているＩＣタグ７０の識別情報であってもよい。ただし、認証情報が生体情報である構成では、情報管理サーバ１０の処理に際して利用者の的確な本人確認が可能であるため、処理の実行に対するセキュリティが的確に高められる。

・代替情報は、クレジットカード番号に対応付けられた情報であれば、トークンを含む数列を示す情報でなくてもよく、例えば、クレジットカード番号が暗号化された情報であってもよい。

・上記各実施形態では、決済システムがイベント内での支払いに用いられる例を説明したが、決済システムの利用される状況はこれに限られない。決済システムは、例えば、レジャースポット等における商品やサービスの代金の支払いに用いられてもよい。特に、現金やクレジットカードの紛失や盗難の虞の高い状況にて、上記各実施形態の決済システムが用いられると、こうした虞を低減することができるため、有益である。

１０…情報管理サーバ、１１…通信部、１２…記憶部、１２ａ…条件データ、１２ｂ…履歴データ、１３…制御部、１３ａ…条件データ管理部、１３ｂ…決済可否判定部、２０…登録端末、３０…支払端末、４０…トークン化サーバ、５０…決済サーバ、６０…クレジットカード、７０…ＩＣタグ。

Claims (14)

1. データを記憶する記憶部と、
   クレジットカード番号に対応付けられた代替情報を含む固有情報を受信する受信部と、
   前記固有情報と決済が許可される条件である決済許可条件とを対応付けて条件データとして前記記憶部に記憶させる登録部と、
   決済を要求する端末から、決済の要求される金額である決済要求金額と、照合情報として前記固有情報に含まれる情報とを受け付けて、これに伴って、決済の要求されている状況を示す決済要求情報を取得する取得部と、
   前記条件データにて前記照合情報に対応付けられている前記決済許可条件を特定し、前記決済要求情報を用いて、特定された前記決済許可条件が満たされているか否かを判定する判定部と、
   前記決済許可条件が満たされていると判定された場合における前記決済要求金額を、特定された前記決済許可条件に前記条件データにて対応付けられている前記代替情報と対応付けて出力する出力部と、
   を備える情報管理サーバ。
2. 前記決済許可条件は、決済が許可される期間を含み
   前記決済要求情報は、決済の要求されている時を含む
   請求項１に記載の情報管理サーバ。
3. 前記決済許可条件は、決済が許可される上限金額を含み
   前記決済要求情報は、前記決済要求金額を含む
   請求項１または２に記載の情報管理サーバ。
4. 前記判定部は、
   前記決済許可条件が満たされていると判定したとき、前記決済要求金額を前記代替情報と対応付けて履歴データとして前記記憶部に記憶させ、
   前記取得部が新たな前記決済要求金額と前記照合情報とを受け付けたとき、当該照合情報を含む前記固有情報に含まれる前記代替情報と前記履歴データにて対応付けられている金額と、前記新たな決済要求金額との合計金額が、前記決済が許可される上限金額以下であるか否かを判定することによって、前記決済許可条件が満たされているか否かを判定する
   請求項３に記載の情報管理サーバ。
5. 前記受信部は、前記決済許可条件に含まれる条件の少なくとも一部を受信し、
   前記登録部は、前記固有情報と前記受信部が受信した条件である外部取得条件を含む前記決済許可条件とを対応付けて前記条件データとして前記記憶部に記憶させる
   請求項１〜４のいずれか一項に記載の情報管理サーバ。
6. 前記登録部は、前記受信部が、前記固有情報と新たな前記外部取得条件とを受信したとき、当該固有情報に前記条件データにて対応付けられている前記外部取得条件を、前記新たな外部取得条件に変更する
   請求項５に記載の情報管理サーバ。
7. 前記外部取得条件は、決済が許可される上限金額であり、
   前記登録部は、前記判定部が前記上限金額の超過によって前記決済許可条件が満たされていないと判定したとき、前記外部取得条件の変更を受け付ける
   請求項６に記載の情報管理サーバ。
8. 前記固有情報は、利用者ごとに固有の認証情報を含み、
   前記受信部は、前記決済を要求する端末を含む端末から所定の処理の要求を受けることに伴って、前記決済を要求する端末を含む端末に入力された前記認証情報を当該端末から受信し、
   前記受信部が受信した前記認証情報と、前記条件データに含まれる前記認証情報との一致を確認することに基づいて、前記所定の処理の実行を許容する認証部をさらに備える
   請求項１〜７のいずれか一項に記載の情報管理サーバ。
9. 前記所定の処理には、一致が確認された前記認証情報に前記条件データにて対応付けられている前記決済許可条件の前記決済を要求する端末を含む端末への送信、当該決済許可条件の変更、および、当該決済許可条件を用いた処理の禁止の少なくとも１つが含まれる
   請求項８に記載の情報管理サーバ。
10. 前記照合情報は、前記代替情報である
    請求項１〜９のいずれか一項に記載の情報管理サーバ。
11. 前記照合情報は、前記認証情報である
    請求項８または９に記載の情報管理サーバ。
12. 前記条件データにて、複数の前記固有情報の各々に前記決済許可条件が対応付けられ、前記複数の固有情報には、同一のクレジットカード番号に対応付けられた互いに異なる代替情報を含む前記固有情報が含まれる
    請求項１〜１１のいずれか一項に記載の情報管理サーバ。
13. 前記代替情報は、トークンを含む数列を示す
    請求項１〜１２のいずれか一項に記載の情報管理サーバ。
14. クレジットカード番号に対応付けられた代替情報を含む固有情報と、決済が許可される条件である決済許可条件に含まれる外部取得条件とを取得する登録端末と、
    決済の要求される金額である決済要求金額と、前記固有情報に含まれる照合情報とを取得する支払端末と、
    前記登録端末および前記支払端末とネットワークを介して接続される情報管理サーバと、を備える決済システムであって、
    前記情報管理サーバは、
    データを記憶する記憶部と、
    前記登録端末から前記固有情報と前記外部取得条件とを受信する受信部と、
    前記固有情報と前記決済許可条件とを対応付けて条件データとして前記記憶部に記憶させる登録部と、
    前記支払端末から、前記決済要求金額と前記照合情報とを受け付けて、これに伴って、決済の要求されている状況を示す決済要求情報を取得する取得部と、
    前記条件データにて前記照合情報に対応付けられている前記決済許可条件を特定し、前記決済要求情報を用いて、特定された前記決済許可条件が満たされているか否かを判定する判定部と、
    前記決済許可条件が満たされていると判定された場合における前記決済要求金額を、特定された前記決済許可条件に前記条件データにて対応付けられている前記代替情報と対応付けて出力する出力部と、を備える
    決済システム。