JP7404888B2 - 決済管理装置、制御方法、及びプログラム - Google Patents

Description

本発明は認証を伴う決済に関する。

セキュリティを向上するための認証技術が開発されている。例えば特許文献１は、ユーザがネットワークを介して提供されるサービスを利用する際に、ユーザのサービス利用に先立って、ユーザに対応づけられた特定の人物（例えば親など）が認証を行ってユーザによるサービスの利用を許可しなければ、ユーザがサービスを利用できないようにするシステムを開示している。

また、特許文献２は、商品の決済において、通常の商品については簡易な１段階の個人認証を要求し、特定の商品についてはさらにもう１段階の個人認証を要求する決済装置を開示している。

特開２０１７－１０５５５０号公報 特開２０１５－２１９７５５号公報

決済に要する認証を厳しくすることには、決済の待ち時間が長くなるという問題がある。例えば特許文献１の決済装置では、決済のタイミングで２段階の認証を求められるため、決済の待ち時間が長くなる。特に、店舗での決済では、各顧客の決済に要する時間が長くなると、決済待ちの列に並ぶ時間も長くなってしまう。また、特許文献２のシステムでは、ユーザの利用に先立って特定の他者による認証が行われる必要があるため、ユーザはその他者による認証が終わるのを待つ必要がある。

本願発明は上記の課題に鑑みてなされたものであり、その目的の一つは、決済に要する時間が長くなることを防ぎつつ、安全性の高い決済を実現できる技術を提供することである。

本発明の決済管理装置は、１）店舗で取得された購入者の第１認証情報を用いて、店舗における決済を実行するための認証を行う認証処理部と、２）第１認証情報を用いた認証に成功した場合、決済が実行された後に、購入者に対応づけられた承認者の端末に対して、決済の承認処理に利用する第２認証情報を要求する要求部と、３）承認者の端末から取得した第２認証情報を用いて、決済の承認処理を行う承認処理部と、を有する。

本発明の制御方法はコンピュータによって実行される。当該制御方法は、１）店舗で取得された購入者の第１認証情報を用いて、店舗における決済を実行するための認証を行う認証処理ステップと、２）第１認証情報を用いた認証に成功した場合、決済が実行された後に、購入者に対応づけられた承認者の端末に対して、決済の承認処理に利用する第２認証情報を要求する要求ステップと、３）承認者の端末から取得した第２認証情報を用いて、決済の承認処理を行う承認処理ステップと、を有する。

本発明のプログラムは、本発明の制御方法が有する各ステップをコンピュータに実行させる。

本発明によれば、決済に要する時間が長くなることを防ぎつつ、安全性の高い決済を実現できる技術を提供することである。

実施形態１に係る決済管理装置の動作を概念的に例示する図である。 決済管理装置の機能構成を例示するブロック図である。 決済管理装置を実現するための計算機を例示する図である。 実施形態１の決済管理装置によって実行される処理の流れを例示するフローチャートである。 決済管理装置の利用環境を例示する図である。 承認端末における画面遷移を例示する図である。 実施形態２の決済管理装置の機能構成を例示するブロック図である。 実施形態２の決済管理装置によって実行される処理の流れを例示するフローチャートである。

以下、本発明の実施の形態について、図面を用いて説明する。尚、すべての図面において、同様な構成要素には同様の符号を付し、適宜説明を省略する。また、特に説明する場合を除き、各ブロック図において、各ブロックは、ハードウエア単位の構成ではなく、機能単位の構成を表している。以下の説明において、特に説明しない限り、各種所定の値（閾値など）は、その値を利用する機能構成部からアクセス可能な記憶装置に予め記憶させておく。

［実施形態１］
＜概要＞
図１は、実施形態１に係る決済管理装置２０００の動作を概念的に例示する図である。ここで、図１を用いて説明する決済管理装置２０００の動作は、決済管理装置２０００の理解を容易にするための例示であり、決済管理装置２０００の動作を限定するものではない。決済管理装置２０００の動作の詳細やバリエーションについては後述する。

決済管理装置２０００は、店舗５０における商品やサービス（以下、商品等）の購入に係る決済の実行と承認に利用される。決済管理装置２０００を利用した決済では、決済の実行のための第１認証と、決済の承認のための第２認証が行われる。第１認証に成功した段階で決済は実行されるため、第２認証が行われる前に、購入者１０に対して商品等を提供することができる。なお、ここでいう「商品の提供」には、その場で商品を直接購入者１０に引き渡すことだけでなく、商品の取り寄せや配送の手配なども含まれる。以下、第１認証の対象となった決済を、対象決済と呼ぶ。

決済管理装置２０００が導入されている店舗５０で商品等を購入するためには、まず、店舗５０において決済の実行が行われる。そして、店舗５０において決済を実行する際に、購入者１０について、決済管理装置２０００を利用した第１認証が行われる。決済を実行するためには、第１認証に成功する必要がある。

第１認証は、店舗５０で取得される第１認証情報２０を利用して行われる。例えば第１認証情報２０は、店舗５０に設けられている店舗端末５２によって取得される。店舗端末５２は、対象決済に利用されるレジ端末などである。第１認証情報２０には、購入者１０を認証するために必要な情報が含まれている。例えば第１認証は、購入者１０の生体情報を用いて行われる。生体情報としては、例えば、顔、指紋、静脈などといった購入者１０の特徴を表す画像や、これらの画像から抽出される特徴量を利用することができる。以下、購入者１０の特徴を表す画像やその画像から抽出される特徴量のことを、特徴情報とも表記する。第１認証に購入者１０の特徴情報を利用する場合、第１認証情報２０には、購入者１０の特徴情報が含まれる。ただし、第１認証に利用される購入者１０の生体情報は、前述した特徴情報には限定されない。また、第１認証は、生体情報を用いた認証には限定されない。

第１認証に成功したら、対象決済が実行される。対象決済が実行されたら、決済管理装置２０００は、購入者１０に対応づけられている承認端末４２に対し、対象決済の承認に利用する第２認証情報３０を要求する。後述するように、第２認証情報３０の要求は、承認端末４２に対して所定の通知（以下、要求通知）を送信することによって行われる。承認端末４２は、対象決済の承認を行う承認者４０が利用する端末である。承認者４０は、購入者１０自身であってもよいし、購入者１０以外の他人（例えば購入者１０の家族）であってもよい。なお、後述するように、承認者４０は複数であってもよい。

決済管理装置２０００は、承認端末４２から提供された第２認証情報３０を用いて、対象決済の承認処理を行う。対象決済の承認処理には、前述した第２認証が含まれる。例えば決済管理装置２０００は、第２認証情報３０を用いた第２認証に成功したら、対象決済が承認されたと判定する。一方、決済管理装置２０００は、承認端末４２から第２認証情報３０が得られなかった場合や、第１認証情報２０を用いた第２認証に失敗した場合に、対象決済が承認されなかったと判定する。

その他にも例えば、決済管理装置２０００は、第２認証情報３０を用いた第２認証に成功した後、承認端末４２から、対象決済を承認するか否かを選択する情報（以下、承認情報）を取得し、承認情報に基づいて、対象決済が承認されたか否かを判定してもよい。承認処理についてのより詳細な説明は後述する。

＜代表的な作用効果＞
本実施形態の決済管理装置２０００によれば、購入者１０の認証を行うことで対象決済が実行され、その後、承認者４０の認証を行うことで対象決済の承認が行われる。このように、対象決済の実行後に対象決済の承認が行われるため、対象決済を承認する前に、購入者１０に対して商品等を提供することができる。よって、購入者１０に対する商品等の提供を迅速に行うことができる。

一方で、承認者４０は、対象決済の実行後に、対象決済の承認を行うことができる。そのため、対象決済が不正に行われたものであったとしても、承認者４０が対象決済を承認しないことにより、そのような不正な決済の存在を把握することができる。そして、このように不正な決済が行われたことを把握できれば、不正な決済が行われたことを購入者１０へ通知したり、対象決済をキャンセルしたりなどといった種々の処置を行うことができる。よって、決済管理装置２０００によれば、決済の安全性を向上できる。

ここで、決済管理装置２０００は、第１認証情報２０として購入者１０の生体情報を利用する場合に特に有効である。生体情報には、文字列のパスワードなどとは違い、変更することが難しいものがある。例えば購入者１０の顔画像を第１認証情報２０として利用するとする。そして、この場合に、顔画像から購入者１０の顔の特徴量を抽出し、その特徴量を用いて認証を行うとする。このように顔の特徴量を利用して認証が行われる場合、たとえ購入者１０の識別情報と対応づけて登録しておく購入者１０の顔画像を別のものに変更したとしても、顔画像から抽出される購入者１０の顔の特徴量は、以前の顔画像から抽出された特徴量と類似する可能性が高い。よって、購入者１０の顔画像が一度流出してしまうと、購入者１０の顔画像を用いた認証の安全性が低下してしまう。

この点、決済管理装置２０００によれば、たとえ購入者１０の生体情報が流出してしまい、購入者１０を装った他者によって不正な決済が行われてしまったとしても、承認者４０による承認を通じて、このような不正な決済を把握することができる。そのため、決済の安全性をより向上させることができる。

以上のように、決済管理装置２０００によれば、決済を安全なものにしつつ、購入者１０に対する商品等の提供を迅速に行うことができる。

以下、決済管理装置２０００についてより詳細に説明する。

＜機能構成の例＞
図２は、決済管理装置２０００の機能構成を例示するブロック図である。決済管理装置２０００は、認証処理部２０２０、要求部２０４０、及び承認処理部２０６０を有する。認証処理部２０２０は、購入者１０についての第１認証情報２０を用いて、対象決済を実行するための第１認証を行う。要求部２０４０は、対象決済の実行後に、承認端末４２に対して、対象決済の承認に利用する第２認証情報３０を要求する。承認処理部２０６０は、第２認証情報３０を用いて、対象決済の承認処理を行う。

＜決済管理装置２０００のハードウエア構成の例＞
決済管理装置２０００の各機能構成部は、各機能構成部を実現するハードウエア（例：ハードワイヤードされた電子回路など）で実現されてもよいし、ハードウエアとソフトウエアとの組み合わせ（例：電子回路とそれを制御するプログラムの組み合わせなど）で実現されてもよい。以下、決済管理装置２０００の各機能構成部がハードウエアとソフトウエアとの組み合わせで実現される場合について、さらに説明する。

図３は、決済管理装置２０００を実現するための計算機１０００を例示する図である。計算機１０００は、任意の計算機である。例えば計算機１０００は、PC（Personal Computer）やサーバマシンなどといった、据え置き型の計算機である。その他にも例えば、計算機１０００は、スマートフォンやタブレット端末などといった可搬型の計算機である。また、計算機１０００は、任意の物理計算機上で動作している仮想マシンであってもよい。

計算機１０００は、決済管理装置２０００を実現するために設計された専用の計算機であってもよいし、汎用の計算機であってもよい。後者の場合、例えば、計算機１０００に対して所定のアプリケーションをインストールすることにより、計算機１０００で、決済管理装置２０００の各機能が実現される。上記アプリケーションは、決済管理装置２０００の機能構成部を実現するためのプログラムで構成される。

計算機１０００は、バス１０２０、プロセッサ１０４０、メモリ１０６０、ストレージデバイス１０８０、入出力インタフェース１１００、及びネットワークインタフェース１１２０を有する。バス１０２０は、プロセッサ１０４０、メモリ１０６０、ストレージデバイス１０８０、入出力インタフェース１１００、及びネットワークインタフェース１１２０が、相互にデータを送受信するためのデータ伝送路である。ただし、プロセッサ１０４０などを互いに接続する方法は、バス接続に限定されない。

プロセッサ１０４０は、CPU（Central Processing Unit）、GPU（Graphics Processing Unit）、FPGA（Field－Programmable Gate Array）などの種々のプロセッサである。メモリ１０６０は、RAM（Random Access Memory）などを用いて実現される主記憶装置である。ストレージデバイス１０８０は、ハードディスク、SSD（Solid State Drive）、メモリカード、又は ROM（Read Only Memory）などを用いて実現される補助記憶装置である。

入出力インタフェース１１００は、計算機１０００と入出力デバイスとを接続するためのインタフェースである。例えば入出力インタフェース１１００には、キーボードなどの入力装置や、ディスプレイ装置などの出力装置が接続される。

ネットワークインタフェース１１２０は、計算機１０００を通信網に接続するためのインタフェースである。この通信網は、例えば LAN（Local Area Network）や WAN（Wide Area Network）である。

ストレージデバイス１０８０は、決済管理装置２０００の各機能構成部を実現するプログラム（前述したアプリケーションを実現するプログラム）を記憶している。プロセッサ１０４０は、このプログラムをメモリ１０６０に読み出して実行することで、決済管理装置２０００の各機能構成部を実現する。

ここで、承認端末４２も、決済管理装置２０００と同様に、図３に示したハードウエア構成を持つ計算機で実現することができる。

＜処理の流れ＞
図４は、実施形態１の決済管理装置２０００によって実行される処理の流れを例示するフローチャートである。認証処理部２０２０は第１認証情報２０を取得する（Ｓ１０２）。認証処理部２０２０は、第１認証情報２０を用いて第１認証を行う（Ｓ１０４）。第１認証に成功した場合（Ｓ１０６：成功）、店舗端末５２によって対象決済が実行された後、要求部２０４０は、承認端末４２に対して要求通知を送信する（Ｓ１０８）。承認処理部２０６０は、第２認証情報３０を取得する（Ｓ１１０）。承認処理部２０６０は、取得した第２認証情報３０を用いて対象決済の承認処理を行う（Ｓ１１２）。

なお、対象決済は決済管理装置２０００によって実行されてもよいし、決済管理装置２０００以外の装置（例えば店舗端末５２）によって行われてもよい。後者の場合、決済管理装置２０００は、例えば、対象決済を行った装置から、対象決済が実行されたことを示す通知を受信することで、対象決済が実行されたことを把握する。なお、決済を実行する具体的な方法については、既存の技術を利用することができる。

第１認証に失敗した場合に行われる処理は任意である。決済管理装置２０００が対象決済を行う場合、例えば決済管理装置２０００は、第１認証に失敗したら、対象決済を実行しないと判定する。またこの際、店舗端末５２に対して第１認証に失敗したことを通知する。店舗端末５２は、店員又は購入者１０が閲覧するディスプレイ装置に、第１認証に失敗した旨を表示する。

店舗端末５２が対象決済を行う場合、決済管理装置２０００は、第１認証に失敗したことを店舗端末５２へ通知する。この通知を受けた店舗端末５２は、対象決済を実行しないと判定する。また、前述したように、第１認証に失敗した旨をディスプレイ装置に表示する。

＜利用環境の例＞
決済管理装置２０００の理解をより容易にするため、決済管理装置２０００の利用環境をより具体的に例示する。ここで説明する決済管理装置２０００の利用環境はあくまで例示であり、決済管理装置２０００の利用環境はここで示した例に限定されない。

図５は、決済管理装置２０００の利用環境を例示する図である。図５において、決済管理装置２０００はサーバマシン６０で実現されている。第１記憶装置７０は、第１認証に利用される記憶装置であり、購入者の識別情報とその購入者の第１認証情報とを対応づけて格納している。第２記憶装置８０は、要求通知の送信先とする承認端末４２を特定するために利用される記憶装置であり、購入者の識別情報と承認端末の識別情報とを対応づけて格納している。第３記憶装置９０は、第２認証に利用される記憶装置であり、承認者の識別情報とその承認者の第２認証情報とを対応づけて格納している。

購入者１０が１つ以上の商品等を購入する際、店舗端末５２によって、その商品等が精算対象として登録される。そして、精算対象として登録された商品等についての決済が行われる。

ここで、購入者１０が所定の方法で決済を行おうとすると、その支払いが対象決済として扱われる。ここでいう所定の方法の決済とは、例えば、予め購入者１０について生成されているアカウントを利用した、キャッシュレスの決済である。より具体的には、例えば、クレジットカード、デビットカード、又は電子マネーなどといった所定のカードを利用した決済や、携帯端末を利用可能な決済サービスを利用した決済（二次元コード決済など）などである。なお、カードを利用した決済と同様の決済を、携帯端末に内蔵されている IC チップで実現してもよい。

上述した所定の方法で決済が行われる場合、店舗端末５２によって第１認証情報２０の取得が行われる。例えば本例の店舗端末５２にはカメラ５４が設けられている。カメラ５４は、購入者１０を撮像することで購入者１０の画像を生成する。この画像が、第１認証情報２０として取得される。第１認証情報２０は、購入者１０の識別情報（クレジット番号など）と共にサーバマシン６０へ送信される。

サーバマシン６０は、店舗端末５２から、購入者１０の識別情報と第１認証情報２０のペアを取得し、取得したペアで第１記憶装置７０を検索することで、第１認証を行う。第１認証に成功した場合、対象決済が実行される。ここで、前述した種々の方法による決済を実行する具体的な技術には、既存の技術を利用することができる。

対象決済の実行後、サーバマシン６０は、購入者１０に対応づけられている承認端末４２を特定し、その承認端末４２へ要求通知を送信する。購入者１０に対応づけられている承認端末４２は、第２記憶装置８０を用いて特定される。

承認者４０は、承認端末４２に対して所定の操作を行うことで、第２認証情報３０を提供する。例えば、要求通知には、第２認証情報３０を入力するための web ページへのリンクが示されている。承認端末４２のディスプレイ装置に表示されたこのリンクに対して承認者４０が操作を加えることで、上記 web ページが承認端末４２に提供される。承認者４０がこの web ページに対して第２認証情報３０を入力することで、承認端末４２からサーバマシン６０へ第２認証情報３０が提供される。この際、承認者４０の識別情報も第２認証情報３０と共にサーバマシン６０へ送信されるようにする。承認者４０の識別情報としては、承認端末４２の識別情報を利用してもよいし、それ以外の情報を利用してもよい。

サーバマシン６０は、承認端末４２から送信された承認者４０の識別情報と第２認証情報３０のペアを受信する。サーバマシン６０は、このペアで第３記憶装置９０を検索することで、第２認証を行う。そして、サーバマシン６０は、第２認証の結果に基づいて、承認処理を行う。

＜第１認証情報２０の取得：Ｓ１０２＞
認証処理部２０２０は、店舗端末５２から、購入者１０の識別情報と第１認証情報２０とのペアを取得する（Ｓ１０２）。購入者１０の識別情報は、購入者１０を認証するために購入者１０を特定できる種々の情報である。例えば購入者１０の識別情報は、種々のカード（クレジットカード、デビットカード、電子マネーカード、ポイントカード、又は会員カードなど）の識別番号や、購入者１０の携帯端末で利用可能な決済サービスにおいて購入者１０に割り与えられている識別情報などである。

第１認証情報２０は、購入者１０の識別情報と予め対応づけておくことで購入者１０を認証することができる任意の情報である。例えば第１認証情報２０は、前述した購入者１０の生体情報（購入者１０の特徴情報など）や、パスワードなどである。また、第１認証情報２０は、購入者１０以外を表す画像（例えば、購入者１０の所持する物の画像）であってもよい。

前述したように、認証処理部２０２０は、店舗端末５２から、購入者１０の識別情報と第１認証情報２０のペアを取得する。ここで、店舗端末５２が購入者１０の識別情報を取得する方法は様々である。例えば購入者１０の識別情報がカードの識別番号である場合、店舗端末５２は、カードリーダによってそのカードの識別番号を読み取る。その他にも例えば、購入者１０の識別情報が、決済サービスにおいて購入者１０に割り与えられた識別情報である場合、例えば店舗端末５２は、その決済サービスを介して対象決済を行うための情報の一部として、購入者１０の携帯端末から購入者１０の識別情報を読み取る。例えばコード決済の場合、店舗端末５２に設けられているコードリーダで購入者１０の携帯端末からコードを読み取ることにより、購入者１０の識別情報を得ることができる。

店舗端末５２が第１認証情報２０を取得する方法も様々である。例えば第１認証情報２０が店舗端末５２に設けられているカメラによって生成される画像である場合、店舗端末５２は、そのカメラから第１認証情報２０を取得する。その他にも例えば、店舗端末５２は、購入者１０の携帯端末と通信することで、予め購入者１０の携帯端末に格納されている画像を第１認証情報２０として受信してもよい。その他にも例えば、第１認証情報２０がパスワードである場合、購入者１０が、店舗端末５２に設けられている入力インタフェースを利用してパスワードの入力を行う。そこで認証処理部２０２０は、このようにして入力されたパスワードを、第１認証情報２０として取得する。

＜第１認証の実行：Ｓ１０４＞
認証処理部２０２０は、取得した購入者１０の識別情報と第１認証情報２０のペアを利用して、第１認証を行う（Ｓ１０４）。より具体的には、認証処理部２０２０は、取得したペアで第１記憶装置７０を検索する。取得した購入者１０のペアとマッチするペアが第１記憶装置７０に格納されている場合、第１認証は成功となる。一方で、取得した購入者１０のペアとマッチするペアが第１記憶装置７０に格納されていない場合、第１認証は失敗となる。なお、認証のために取得した識別情報と認証情報（パスワードや画像など）のペアと、予め記憶装置に格納されている識別情報と認証情報とのペアとを用いて認証を行うより具体的な方法には、既存の方法を利用することができる。

第１記憶装置７０には、購入者１０の識別情報と第１認証情報２０のペアが予め格納されている。第１記憶装置７０にこのペアを予め格納しておく方法は任意である。例えば、ユーザに対し、識別情報と第１認証情報２０のペアを登録するための web ページなどを提供する。この場合、ユーザは、予めこの web ページを利用して、自身の識別情報と第１認証情報２０の対応付けを登録しておく。また、ユーザが上記ペアを更新できるようにしておくことが好ましい。なお、上記 web ページなどといった、購入者１０の識別情報と第１認証情報２０のペアを登録するためのインタフェースは、決済管理装置２０００によって提供されてもよいし、決済管理装置２０００以外の装置によって提供されてもよい。

＜第２認証情報３０の要求：Ｓ１０８＞
要求部２０４０は、購入者１０に対応づけられている承認端末４２に対して要求通知（第２認証情報３０を要求する通知）を送信する（Ｓ１０８）。そのために、要求部２０４０は、購入者１０の識別情報に対応づけられている承認端末４２の識別情報を特定する。この特定には、前述した第２記憶装置８０を利用する。具体的には、要求部２０４０は、第２記憶装置８０から、認証処理部２０２０によって取得された購入者１０の識別情報と対応づけられている承認端末４２の識別情報を取得する。

承認端末４２の識別情報は、要求通知をその承認端末４２に到達させるために必要な情報である。例えば承認端末４２の識別情報には、メールアドレスを利用することができる。その他にも例えば、承認端末４２の識別情報には、いわゆるプッシュ通知を実現するシステムにおいて、通知先の端末の識別情報として用いられる任意の情報を利用できる。

要求通知には、対象決済に関する情報が含まれる。対象決済に関する情報には、例えば、購入者１０に関する情報（購入者１０の識別情報や名前など）、対象決済が行われた店舗５０に関する情報（店舗の名称や住所など）、購入された各商品等に関する情報（商品等の名前や価格など）、及び支払金額などが含まれる。また、対象決済に対する承認に期限を設ける場合、要求通知には、その期限を表す情報も含めることが好ましい。

なお、前述した対象決済に関する種々の情報を要求通知に含める代わりに、それらの情報を閲覧するための情報を要求通知に含めてもよい。例えば要求通知の中に、対象決済に関する情報が含まれる web ページへのリンクを含めておく。この場合、承認者４０は、承認端末４２でそのリンクをタップ等してその web ページを閲覧することで、対象決済に関する情報を閲覧できる。なお、この web ページを提供する web サーバは、決済管理装置２０００によって実現されてもよいし、決済管理装置２０００以外の装置によって実現されてもよい。

また、対象決済に関する情報の一部又は全部は、第２認証に成功した後にのみ閲覧できるようにしてもよい。例えば要求通知には、対象決済に関する情報を含めず、「承認が必要な決済があるため、まずは第２認証を行って下さい」という旨のメッセージを含めることで、第２認証情報３０の提供を促す。その後、第２認証に成功したら、対象決済に関する情報を承認端末４２へ別途送信する。このようにすることで、対象決済の承認に関係ない第３者に誤って対象決済に関する情報が見られてしまうことを防げるため、購入者１０のプライバシーをより確実に守ることができる。

要求通知は、例えば、メールや特定のアプリケーションへの通知として実現される。後者の場合、要求通知を受信可能な特定のアプリケーションを、予め承認端末４２にインストールしておく。以下、このアプリケーションを承認用アプリケーションと呼ぶ。なお、特定のアプリケーションへの通知を実現する技術には、既存の技術を利用することができる。

＜第２認証情報３０の取得：Ｓ１１０＞
承認処理部２０６０は、要求通知への応答として承認端末４２から提供される第２認証情報３０を取得する（Ｓ１１０）。第２認証情報３０は、承認者４０の識別情報と予め対応づけておくことで承認者４０を認証することができる任意の情報である。第２認証情報３０は、例えば、承認者４０の生体情報（承認者４０の特徴情報など）や、パスワードなどである。また、第２認証情報３０は、承認者４０以外を表す画像であってもよい。

ここで、第２認証は対象決済の実行後に行われるため、第２認証情報３０には、店舗で行う認証では利用することが難しい情報も利用することができる。そのため、例えば、第２認証情報３０としては、家の外には持ち出せないような物の画像（例えば、家の壁、柱、又は床の一部を表す画像など）を利用することができる。このような物の画像を第２認証情報３０として利用することで、第２認証に利用する画像を第３者が取得できる蓋然性を低くすることができる。

なお、購入者１０と承認者４０が同一人物である場合、第１認証情報２０が示す情報の種類と、第２認証情報３０が示す情報の種類とは、異なる種類の情報であることが好ましい。このようにすることで、例えば、第１認証に利用する情報が第３者に漏洩してしまった場合でも、その情報を利用して第２認証を行うことはできないため、認証の安全性が向上する。

例えば、第１認証と第２認証において、互いに異なる特徴情報を利用するようにする（前者では顔の画像を利用し、後者では指紋の画像を利用するなど）。その他にも例えば、第１認証では購入者１０の特徴情報を利用し、第２認証では購入者１０の特徴情報以外（例えば購入者１０の家の中の一部を表す画像）を利用するようにする。

承認者４０が購入者１０以外の人物である場合、第１認証情報２０が示す情報の種類と第１認証情報２０が示す情報の種類は、同一であってもよいし異なっていてもよい。前者の場合、例えば、第１認証情報２０として購入者１０の特徴情報を利用し、第２認証情報３０として承認者４０の特徴情報を利用する。

承認端末４２から決済管理装置２０００へ第２認証情報３０を提供する方法は様々である。例えば決済管理装置２０００は、第２認証情報３０を入力するための web ページを提供する。要求通知には、この web ページへのリンクを含めておく。承認者４０は、承認端末４２で要求通知を閲覧してこのリンクをクリックすることで、上記 web ページを閲覧する。なお、この web ページを提供する web サーバは、決済管理装置２０００によって実現されてもよいし、決済管理装置２０００以外の装置によって実現されてもよい。

この web ページには、第２認証情報３０を入力するための入力インタフェースが含まれる。この入力インタフェースを用いて入力された情報は、前述した web サーバへ送信される。決済管理装置２０００は、web サーバが受信した情報を、第２認証情報３０として取得する。

入力インタフェースとしては、第２認証情報３０の種類に応じた適切なものが用意される。例えば第２認証情報３０が画像であるとする。この場合、例えば入力インタフェースは、「既に承認端末４２に格納されている画像を選択してアップロードする」という操作を実現するものや、「承認端末４２に設けられているカメラを起動し、そのカメラによって撮像が行われたら、生成された画像をアップロードする」という操作を実現するものである。その他にも例えば、第２認証情報３０がパスワードなどの文字入力によって提供されるものである場合、入力インタフェースは、文字入力を行うためのものである。

第２認証情報３０を提供する方法は、前述した web ページを利用する方法に限定されない。例えば前述したように、承認端末４２に承認用アプリケーションが予めインストールされているとする。この場合、このアプリケーションに、決済管理装置２０００へ第２認証情報３０を提供するための機能を持たせてもよい。例えば、当該アプリケーションは、ユーザ（承認者４０）が要求通知を閲覧する際、要求通知の内容と共に、第２認証情報３０を提供するための入力インタフェースを表示するようにする。入力インタフェースとしては、前述した web ページに設けるものと同様のものを利用できる。

＜承認処理：Ｓ１１２＞
承認処理部２０６０は、承認端末４２から受信した第２認証情報３０を利用して、対象決済の承認処理を実行する（Ｓ１１２）。承認処理では、承認者４０によって対象決済が承認されたか否かの判定が行われる。例えば承認処理部２０６０は、第２認証に成功したら、対象決済が承認者４０によって承認されたと判定する。一方で、承認処理部２０６０は、第２認証に成功しない場合に、対象決済が承認者４０によって承認されなかったと判定する。すなわちこのケースにおいて、承認者４０は、第２認証を行うこと自体により、「対象決済を承認する」という意思を示すことができる。

承認処理部２０６０が第２認証を行う方法は、認証処理部２０２０が第１認証を行う方法と同様である。具体的には、承認処理部２０６０は、承認者４０の識別情報と第２認証情報３０のペアを取得し、そのペアで第３記憶装置９０を検索する。取得したペアとマッチするペアが第３記憶装置９０に格納されている場合、第２認証は成功となる。一方で、取得したペアとマッチするペアが第３記憶装置９０に格納されていない場合、第２認証は失敗となる。

なお、第３記憶装置９０には、承認者４０の識別情報と第２認証情報３０のペアが予め格納されている。第３記憶装置９０にこのペアを予め格納しておく方法には、例えば、第１記憶装置７０に購入者１０の識別情報と第１認証情報２０のペアを予め格納しておく方法と同様を利用できる。

ここで、第２認証の実行に制限回数を設けてもよい。この場合、承認処理部２０６０は、制限回数以内に第２認証に成功したら、対象決済が承認者４０によって承認されたと判定する。一方、承認処理部２０６０は、制限回数以内に第２認証に成功しなかったら（制限回数の第２認証が全て失敗したら）、対象決済が承認者４０によって承認されなかったと判定する。このようにすることで、承認者４０のミスにより第２認証に失敗した場合などに、承認者４０が再度第２認証を行うことができるようになる。

同様に、第２認証の実行に制限時間を設けてもよい。制限時間は、例えば、対象決済が行われた時点から所定の時間が経過するまでや、要求通知が行われた時点から所定の時間が経過するまでなどに設定される。この場合、承認処理部２０６０は、制限時間以内に第２認証に成功したら、対象決済が承認者４０によって承認されたと判定する。一方、承認処理部２０６０は、制限時間以内に第２認証に成功しなかったら（制限時間内に行われた第２認証が全て失敗した場合や、制限時間内に第２認証が行われない場合）、対象決済が承認者４０によって承認されなかったと判定する。

承認処理部２０６０は、承認端末４２から承認情報（対象決済を承認するか否かを示す情報）を取得し、承認情報の内容に基づいて、対象決済が承認されたか否かを判定してもよい。承認情報は、第２認証情報３０と共に取得されてもよいし、第２認証情報３０とは別途取得されてもよい。

承認情報を利用する場合、承認処理部２０６０は、第２認証に成功し、なおかつ、承認情報が対象決済を承認することを示している場合に、対象決済が承認者４０によって承認されたと判定する。一方、それ以外の場合には、対象決済が承認者４０によって承認されなかったと判定される。

承認端末４２から決済管理装置２０００へ承認情報を提供する方法には、承認端末４２から決済管理装置２０００へ第２認証情報３０を提供する方法と同様の方法を利用できる。例えば、「承認する」と「承認しない」のいずれか一方を選択可能な入力インタフェースを持つ web ページを承認端末４２へ提供したり、承認端末４２にインストールされている承認用アプリケーションで同様のインタフェースを提供したりする。承認処理部２０６０は、この入力インタフェースへの入力結果を表す情報を、承認情報として取得する。

承認情報が第２認証情報３０と共に提供されるようにする場合、第２認証情報３０を入力するための入力インタフェースと共に、承認情報を入力するための入力インタフェースが提供されるようにする。一方、承認情報が第２認証情報３０とは別途のタイミングで提供されるようにする場合、承認処理部２０６０は、第２認証に成功した後に、承認情報を入力するための入力インタフェースを提供する。

＜承認端末４２に表示される画面の例＞
図６は、承認端末４２に表示される画面１００を例示する図である。図６の画面１００は、例えば、要求通知を受信したことに応じて、承認端末４２のディスプレイ装置に表示される。画面１００には、対象決済の内容、第２認証情報３０を提供するための入力インタフェース、及び承認情報を提供するための入力インタフェースが含まれている。そのため、この例では、第２認証情報３０と承認情報が同時に決済管理装置２０００へ提供される。なお、本例において、第２認証情報３０には画像が利用される。

画面１００は、エリア１１０、エリア１２０、エリア１３０、及びボタン１４０を有する。エリア１１０は、対象決済の内容を示す。具体的には、決済の識別情報（決済 No.）、決済場所、決済日時、購入者１０の氏名、及び支払金額が示されている。なお、この例において、エリア１１０には、購入した商品等についての情報が含まれていない。ユーザがボタン１１２を押すことにより、購入した商品の一覧が別途表示される。

エリア１１０は、第２認証情報３０を提供するための入力インタフェースを含む。エリア１２２は、承認者４０の識別情報が入力されるエリアである。エリア１２４は、第２認証情報３０として提供される画像のサムネイルが表示されるエリアである。承認者４０は、第２認証情報３０として提供する画像を、その場でカメラを使用して生成するか、又は既存の画像から選択できる。

承認者４０がボタン１２６を押すと、承認端末４２のカメラが起動される。承認端末４２のカメラを用いて撮像が行われると、その結果として生成された画像が、第２認証情報３０として利用される。また、その画像のサムネイルがエリア１２４に表示される。

一方、承認者４０がボタン１２８を押すと、既に存在する画像から、第２認証情報３０として提供する画像を選択することができる。そして、選択された画像のサムネイルがエリア１２４に表示される。

エリア１３０は、承認情報を提供するための入力インタフェースを含む。承認者４０は、「承認する」と「承認しない」のいずれか一方を選択できる。この選択結果が、承認情報として決済管理装置２０００へ提供される。

決済内容の確認、認証のための情報の入力、及び承認するか否かの選択を終了した承認者４０は、ボタン１４０を押す。これに応じ、承認端末４２から決済管理装置２０００へ、承認者４０の識別情報、第２認証情報３０、及び承認情報が送信される。

＜複数の承認者４０による承認＞
１つの対象決済について承認を行う承認者４０は、複数であってもよい。この場合、第２記憶装置には、購入者１０の識別情報に対応づけて、複数の承認者４０それぞれが利用する承認者４０の識別情報を格納される。また、要求通知は複数の承認端末４２それぞれに対して送信される。そして、第２認証情報３０や承認情報も複数の承認端末４２それぞれから提供される。

このように複数の承認者４０によって対象決済の承認が行われる場合、承認処理部２０６０は、各承認者４０それぞれによる承認の結果に基づいて、対象決済が承認されたか否かを総合的に判断する。例えば承認処理部２０６０は、全ての承認者４０によって対象決済が承認された場合のみ、対象決済が承認されたと判定する。一方、少なくとも一人の承認者４０によって対象決済が承認されなかった場合、承認処理部２０６０は、対象決済が承認されなかったと判定する。

その他にも例えば、承認処理部２０６０は、所定数以上の承認者４０によって対象決済が承認された場合、対象決済が承認されたと判定する。一方、対象決済を承認した承認者４０が所定数未満である場合、承認処理部２０６０は、対象決済が承認されなかったと判定する。なお、所定数は１であってもよい。また、所定数の代わりに所定割合を用いてもよい。

＜承認処理の結果の利用方法＞
承認処理の結果を利用する方法は様々である。例えば、承認処理によって対象決済が承認されないと判定された場合、対象決済が取り消されるようにする。例えばクレジットカード決済などでは、対象決済の代金が実際に購入者１０から提供されるタイミングが、対象決済の実行よりも後になる。この場合、例えば、対象決済が承認されなかったら、購入者１０からの代金の徴収を行わないようにする。その他にも例えば、対象決済の実行時に購入者１０から代金が徴収される（例えば、電子マネーカードの残高から支払金額が差し引かれる）場合、購入者１０に対して対象決済の代金が返還されるようにする。またこれらの場合、承認されなかった対象決済で利用された決済方法を、少なくとも一時的に利用できなくすることが好ましい。

また、対象決済が承認されなかった場合、決済管理装置２０００は、その旨を購入者１０の端末に通知することが好ましい。このようにすることで、購入者１０は、自分のアカウントを利用して不正な決済が行われた可能性があることを把握することができる。なお、購入者１０の端末の識別情報は、予め登録しておく（例えば、第１記憶装置に格納しておく）。

＜変形例＞
実施形態１の決済管理装置２０００は、対象決済が実行されるごとに承認者４０に承認を要求する代わりに、複数の対象決済についてまとめて承認を要求してもよい。例えば要求部２０４０は、所定の期間（例えば、週や月）の終了時に、その期間内に行われた各対象決済についての承認を求めるために、承認端末４２へ要求通知を送信する。このようにすることで、承認する対象決済が複数あっても、第２認証については一度行えばよいため、認証の手間が軽減される。

承認端末４２から承認情報を提供する場合、対象決済を承認するか否かは、複数の対象決済それぞれについて選択できるようにしてもよいし、複数の対象決済についてまとめて選択されるようにしてもよい。前者の場合、前述した承認情報を入力するための入力インタフェースは、複数の対象決済それぞれについて提供される。

［実施形態２］
図７は、実施形態２の決済管理装置２０００の機能構成を例示するブロック図である。以下で説明する点を除き、実施形態２の決済管理装置２０００は、実施形態１の決済管理装置２０００と同様の機能を有する。

実施形態２の決済管理装置２０００は判定部２０８０を有する。判定部２０８０は、対象決済の承認処理が必要であるか否か（承認者４０へ承認を要求するか否か）を判定する。ここで、対象決済の承認処理を必要とするか否かを判定するために利用する条件を、要求条件と呼ぶ。判定部２０８０は、対象決済が要求条件を満たしているか否かを判定する。対象決済が要求条件を満たしている場合、判定部２０８０は、承認処理が必要であると判定する。一方、対象決済が要求条件を満たされていない場合、判定部２０８０は、承認処理が必要でないと判定する。そして、実施形態２の要求部２０４０は、承認処理が必要であると判定された場合に、承認端末４２に対し、第２認証情報３０を要求する（要求通知を送信する）。そのため、要求条件が満たされた場合のみ、対象決済についての承認が行われるようにすることができる。

このように、所定の条件が満たされた場合のみ承認が行われるようにすることで、承認者４０による承認の手間を減らしつつ、承認を行うべき決済については承認が行われるようにすることができる。すなわち、承認者４０の手間の軽減と、決済の安全性の向上とを、両立させることができる。

承認者４０が購入者１０自身である場合、例えば、購入者１０が通常行う決済では満たされないような要求条件を定めておくことで、購入者１０以外の人物によって不正な決済が行われた可能性がある場合に、承認が必要となるようにすることができる。また、承認者４０が購入者１０以外の人物である場合、例えば、事前に認めておいた決済では該当しないような要求条件を定めておくことで、購入者１０以外の人物によって不正な決済が行われた可能性がある場合や、購入者１０が事前に認めておいた条件には当てはまらない決済をした可能性がある場合に、承認が必要となるようにすることができる。

要求条件としては、様々な条件を用いることができる。例えば、対象決済の金額に関する条件、対象決済で購入された商品等に関する条件、対象決済が行われた店舗５０に関する条件、又は対象決済が行われた時間に関する条件などを利用することが考えられる。

対象決済の金額に関する条件としては、例えば、「対象決済における支払金額が閾値以上である」などといった条件を用いることができる。これにより、例えば、「事前に認められた金額以上の高額の決済をした場合のみ、承認者４０によって承認が行われるようにする」といったことが可能となる。

対象決済で購入された商品等に関する条件としては、例えば、「対象決済で購入された商品等が、所定の商品等に該当しない」といった条件を用いることができる。これにより、例えば、「事前に認められていない商品等が購入された場合のみ、承認者４０によって承認が行われるにようにする」といったことが可能となる。その他にも例えば、「対象決済で購入された商品等が、所定の商品等に該当する」などといった条件が用いられてもよい。

対象決済が行われた店舗５０に関する条件としては、例えば、「店舗５０が所定の店舗でない」といった条件を用いることができる。これにより、例えば、「事前に認められている店舗（所定の店舗）以外の店舗で決済が行われた場合のみ、承認者４０によって承認が行われるようにする」といったことが可能となる。その他にも例えば、「店舗５０が所定の領域内に位置しない」といった条件を用いることができる。これにより、例えば、「購入者１０の通常の行動範囲（所定の領域）とは異なる場所にある店舗で決済が行われた場合のみ、承認者４０によって承認が行われるようにする」といったことが可能となる。その他にも例えば、「店舗５０が所定の店舗に該当しない」や「店舗５０が所定の領域内に位置する」などといった条件が用いられてもよい。

対象決済が行われた時間に関する条件としては、例えば、「対象決済が行われた時間が所定の時間範囲内でない」といった条件を用いることができる。これにより、例えば、「購入者１０の通常の行動時間でない（所定の時間範囲内でない）時間に決済が行われた場合のみ、承認者４０によって承認が行われるようにすることができる」といったことが可能となる。

ここで、前述した所定の商品等、所定の店舗、所定の領域、及び所定の時間範囲などは、承認者によって手動で設定されてもよいし、購入者１０の行動履歴から自動的に設定されてもよい。この場合、例えば「所定の商品等」には、購入者１０がこれまでに購入したことがある商品等やそれに類似する商品等に設定される。また、所定の店舗には、例えば、購入者１０がこれまでに利用したことがある店舗や、これまれに利用したことがある店舗の系列店などが設定される。また、所定の領域には、購入者１０がこれまでに移動したことがある場所及びその周辺が設定される。また、所定の時間範囲には、例えば、購入者１０が家や仕事場の外にいることが多い時間（例えば通勤時間）が設定される。

＜ハードウエア構成の例＞
実施形態２の決済管理装置２０００のハードウエア構成は、実施形態１の決済管理装置２０００と同様に、例えば図３で表される。ただし、実施形態２のストレージデバイス１０８０には、実施形態２の決済管理装置２０００の機能を実現するためのプログラムが格納されている。

＜処理の流れ＞
図８は、実施形態２の決済管理装置２０００によって実行される処理の流れを例示するフローチャートである。図８のフローチャートは、Ｓ２０２を有する点を除き、図４のフローチャートと同様である。Ｓ２０２において、判定部２０８０は、要求条件が満たされているか否かを判定する。

＜変形例＞
実施形態２の決済管理装置２０００も、実施形態１の決済管理装置２０００と同様に、複数の対象決済の承認がまとめて行われるようにしてもよい。この場合、例えば判定部２０８０は、所定期間内に行われた各対象決済について、要求条件を満たすか否かを判定する。要求条件を満たす対象決済が１つ以上存在する場合、要求部２０４０は、要求通知を送信する。要求条件を満たす対象決済が１つも存在しない場合、要求部２０４０は、要求通知を送信しない。

また、承認端末４２から承認情報を取得する場合、承認処理部２０６０は、要求条件を満たす対象決済についてのみ、承認情報を取得する。各対象決済について承認するか否かを判定させる場合、例えば承認処理部２０６０は、要求条件を満たす対象決済に関する情報のみを承認端末４２に提供し、それらの対象決済それぞれについて、承認するか否かを選択させる。

上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
１． 店舗で取得された購入者の第１認証情報を用いて、前記店舗における決済を実行するための認証を行う認証処理部と、
前記第１認証情報を用いた認証に成功した場合、前記決済が実行された後に、前記購入者に対応づけられた承認者の端末に対して、前記決済の承認処理に利用する第２認証情報を要求する要求部と、
前記承認者の端末から取得した前記第２認証情報を用いて、前記決済の承認処理を行う承認処理部と、を有する決済管理装置。
２． 前記承認処理部は、前記第２認証情報を用いた認証に失敗した場合に、前記決済が承認されなかったと判定する、１．に記載の決済管理装置。
３． 前記承認処理部は、
前記承認者の端末から、前記決済を承認するか否かを示す承認情報を取得し、
前記第２認証情報を用いた認証に成功し、なおかつ、前記決済を承認しないことを示す前記承認情報を取得した場合、前記決済が承認されなかったと判定する、２．に記載の決済管理装置。
４． 前記承認者は前記購入者とは異なる人であり、
前記決済が承認されなかった場合、前記購入者の端末に対して前記決済に関する情報を送信する、１．から３いずれか一つに記載の決済管理装置。
５． 前記決済の承認を要求する条件が満たされているか否かを判定する判定部を有し、
前記要求部は、前記条件が満たされている場合に前記第２認証情報を要求し、
前記条件は、前記決済の対象となった商品又はサービス、前記店舗、及び前記決済が行われた時間のいずれか１つ以上に関する条件である、１．から４いずれか一つに記載の決済管理装置。
６． 前記要求部は、所定期間に行われた複数の前記決済の承認に利用する第２認証情報を前記承認者の端末に要求し、
前記承認処理部は、前記取得した第２認証情報を用いて、複数の前記決済についての承認処理を行う、１．から５いずれか一つに記載の決済管理装置。
７． 前記承認処理部は、前記第２認証情報と、複数の前記決済それぞれについて、その決済を承認するか否かを示す承認情報を取得し、
前記第２認証情報を用いた認証に成功した場合、前記承認情報を用いて、複数の前記決済それぞれについて、その決済が承認されたか否かを判定する、６．に記載の決済管理装置。
８． 前記第１認証情報と前記第２認証情報の少なくとも一方は生体情報である、１．から７いずれか一つに記載の決済管理装置。
９． コンピュータによって実行される制御方法であって、
店舗で取得された購入者の第１認証情報を用いて、前記店舗における決済を実行するための認証を行う認証処理ステップと、
前記第１認証情報を用いた認証に成功した場合、前記決済が実行された後に、前記購入者に対応づけられた承認者の端末に対して、前記決済の承認処理に利用する第２認証情報を要求する要求ステップと、
前記承認者の端末から取得した前記第２認証情報を用いて、前記決済の承認処理を行う承認処理ステップと、を有する制御方法。
１０． 前記承認処理ステップにおいて、前記第２認証情報を用いた認証に失敗した場合に、前記決済が承認されなかったと判定する、９．に記載の制御方法。
１１． 前記承認処理ステップにおいて、
前記承認者の端末から、前記決済を承認するか否かを示す承認情報を取得し、
前記第２認証情報を用いた認証に成功し、なおかつ、前記決済を承認しないことを示す前記承認情報を取得した場合、前記決済が承認されなかったと判定する、１０．に記載の制御方法。
１２． 前記承認者は前記購入者とは異なる人であり、
前記決済が承認されなかった場合、前記購入者の端末に対して前記決済に関する情報を送信する、９．から１１いずれか一つに記載の制御方法。
１３． 前記決済の承認を要求する条件が満たされているか否かを判定する判定ステップを有し、
前記要求ステップにおいて、前記条件が満たされている場合に前記第２認証情報を要求し、
前記条件は、前記決済の対象となった商品又はサービス、前記店舗、及び前記決済が行われた時間のいずれか１つ以上に関する条件である、９．から１２いずれか一つに記載の制御方法。
１４． 前記要求ステップにおいて、所定期間に行われた複数の前記決済の承認に利用する第２認証情報を前記承認者の端末に要求し、
前記承認処理ステップにおいて、前記取得した第２認証情報を用いて、複数の前記決済についての承認処理を行う、９．から１３いずれか一つに記載の制御方法。
１５． 前記承認処理ステップにおいて、前記第２認証情報と、複数の前記決済それぞれについて、その決済を承認するか否かを示す承認情報を取得し、
前記第２認証情報を用いた認証に成功した場合、前記承認情報を用いて、複数の前記決済それぞれについて、その決済が承認されたか否かを判定する、１４．に記載の制御方法。
１６． 前記第１認証情報と前記第２認証情報の少なくとも一方は生体情報である、７．から１５いずれか一つに記載の制御方法。
１７． ９．から１６いずれか一つに記載の制御方法をコンピュータに実行させるプログラム。

１０ 購入者
２０ 第１認証情報
３０ 第２認証情報
４０ 承認者
４２ 承認端末
５０ 店舗
５２ 店舗端末
５４ カメラ
６０ サーバマシン
７０ 第１記憶装置
８０ 第２記憶装置
９０ 第３記憶装置
１０００ 計算機
１０２０ バス
１０４０ プロセッサ
１０６０ メモリ
１０８０ ストレージデバイス
１１００ 入出力インタフェース
１１２０ ネットワークインタフェース
２０００ 決済管理装置
２０２０ 認証処理部
２０４０ 要求部
２０６０ 承認処理部
２０８０ 判定部

Claims (10)

1. 店舗で取得された購入者の第１認証情報を用いて、前記店舗における決済を実行するための認証を行う認証処理部と、
   前記第１認証情報を用いた認証に成功した場合、前記決済が実行された後に、前記購入者に対応づけられた承認者の端末に対して、前記決済の承認処理に利用する第２認証情報を要求する要求部と、
   前記承認者の端末から取得した前記第２認証情報を用いて、前記決済の承認処理を行う承認処理部と、を有する決済管理装置。
2. 前記承認処理部は、前記第２認証情報を用いた認証に失敗した場合に、前記決済が承認されなかったと判定する、請求項１に記載の決済管理装置。
3. 前記承認処理部は、
   前記承認者の端末から、前記決済を承認するか否かを示す承認情報を取得し、
   前記第２認証情報を用いた認証に成功し、なおかつ、前記決済を承認しないことを示す前記承認情報を取得した場合、前記決済が承認されなかったと判定する、請求項２に記載の決済管理装置。
4. 前記承認者は前記購入者とは異なる人であり、
   前記決済が承認されなかった場合、前記購入者の端末に対して前記決済に関する情報を送信する、請求項１から３いずれか一項に記載の決済管理装置。
5. 前記決済の承認を要求する条件が満たされているか否かを判定する判定部を有し、
   前記要求部は、前記条件が満たされている場合に前記第２認証情報を要求し、
   前記条件は、前記決済の対象となった商品又はサービス、前記店舗、及び前記決済が行われた時間のいずれか１つ以上に関する条件である、請求項１から４いずれか一項に記載の決済管理装置。
6. 前記要求部は、所定期間に行われた複数の前記決済の承認に利用する第２認証情報を前記承認者の端末に要求し、
   前記承認処理部は、前記取得した第２認証情報を用いて、複数の前記決済についての承認処理を行う、請求項１から５いずれか一項に記載の決済管理装置。
7. 前記承認処理部は、前記第２認証情報と、複数の前記決済それぞれについて、その決済を承認するか否かを示す承認情報を取得し、
   前記第２認証情報を用いた認証に成功した場合、前記承認情報を用いて、複数の前記決済それぞれについて、その決済が承認されたか否かを判定する、請求項６に記載の決済管理装置。
8. 前記第１認証情報と前記第２認証情報の少なくとも一方は生体情報である、請求項１から７いずれか一項に記載の決済管理装置。
9. コンピュータによって実行される制御方法であって、
   店舗で取得された購入者の第１認証情報を用いて、前記店舗における決済を実行するための認証を行う認証処理ステップと、
   前記第１認証情報を用いた認証に成功した場合、前記決済が実行された後に、前記購入者に対応づけられた承認者の端末に対して、前記決済の承認処理に利用する第２認証情報を要求する要求ステップと、
   前記承認者の端末から取得した前記第２認証情報を用いて、前記決済の承認処理を行う承認処理ステップと、を有する制御方法。
10. 請求項９に記載の制御方法をコンピュータに実行させるプログラム。

Images