JP2016062413A - 決済管理装置、決済管理方法および決済管理プログラム - Google Patents

Abstract

【課題】商品やサービスを購入する際の決済処理における利便性を向上させる。【解決手段】実施形態の一態様に係る決済管理装置は、購入要求受付部と、支払候補者選択部と、一覧情報通知部と、選択情報取得部と、決済部とを備える。購入要求受付部は、利用者端末から送信される購入要求を受け付ける。支払候補者選択部は、購入要求に対応する購入対象の対価を利用者端末の利用者に代って支払う支払者の候補である複数の支払候補者を選択する。一覧情報通知部は、支払候補者の一覧の情報を利用者端末へ通知する。選択情報取得部は、支払候補者の一覧の中から選択された支払候補者の情報を選択候補者の情報として利用者端末から取得する。決済部は、選択候補者の情報に基づいて購入対象の決済処理を行う。【選択図】図１

Description

本発明は、決済管理装置、決済管理方法および決済管理プログラムに関する。

従来、店舗やインターネット上で商品やサービスを購入する際、クレジットカード払いや銀行口座振替などで決済する技術が知られている。かかる技術では、例えば、クレジットカード等を保有する利用者が、自己の決済情報（例えば、クレジットカード番号等の情報）をウェブページ等に入力する、あるいは、事前に決済管理装置に登録しておいた自己の決済情報を用いることで、決済処理が行われる。

ところで、利用者が商品を購入する際、自分に代わって商品の対価の支払いを、例えば、親など自分以外の人に依頼したい場合がある。そこで、近年、例えば、支払いを依頼する相手と利用者との関係に関する情報を決済管理装置に事前に登録しておき、決済管理装置が、登録した相手の決済情報を用いて決済を行うようにした技術が提案されている（例えば、特許文献１参照）。

特許第４２７８４０４号公報

しかしながら、上述の従来技術においては、事前に登録された関係にある者同士に限ってでしか決済処理を行うことができず、利便性の点で改善の余地があった。

本願は、上記に鑑みてなされたものであって、商品やサービスを購入する際の決済処理における利便性を向上させるようにした決済管理装置、決済管理方法および決済管理プログラムを提供することを目的とする。

本願に係る決済管理装置は、購入要求受付部と、支払候補者選択部と、一覧情報通知部と、選択情報取得部と、決済部とを備える。購入要求受付部は、利用者端末から送信される購入要求を受け付ける。支払候補者選択部は、前記購入要求受付部によって受け付けた前記購入要求に対応する購入対象の対価を前記利用者端末の利用者に代って支払う支払者の候補である複数の支払候補者を選択する。一覧情報通知部は、前記支払候補者選択部によって選択された前記支払候補者の一覧の情報を前記利用者端末へ通知する。選択情報取得部は、前記支払候補者の一覧の中から選択された前記支払候補者の情報を選択候補者の情報として前記利用者端末から取得する。決済部は、前記選択情報取得部によって取得された前記選択候補者の情報に基づいて前記購入対象の決済処理を行う。

実施形態の一態様によれば、商品やサービスを購入する際の決済処理における利便性を向上させることができる。

図１は、実施形態に係る決済管理装置が実行する処理の概要を示す図である。 図２は、実施形態に係る決済管理システムの構成例を示す図である。 図３は、実施形態に係る利用者端末の構成例を示す図である。 図４は、実施形態に係る選択候補者端末の構成例を示す図である。 図５は、実施形態に係る決済管理装置の構成例を示す図である。 図６は、ソーシャルグラフの一例を示す図である。 図７は、履歴テーブルの一例を示す図である。 図８は、支払承認ポリシーのテーブルの一例を示す図である。 図９は、支払承認拒否ポリシーのテーブルの一例を示す図である。 図１０は、利用者端末の表示部の画面に表示される選択画面の一例を示す図である。 図１１は、選択候補者端末の表示部の画面に表示される支払承認画面の一例を示す図である。 図１２は、決済管理装置による決済処理の流れの一例を説明するための図である。 図１３は、プログラムを実行するコンピュータのハードウェア構成の一例を示す図である。

以下に、本願に係る決済管理装置、決済管理方法および決済管理プログラムの実施形態について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る決済管理装置、決済管理方法および決済管理プログラムが限定されるものではない。また、以下の実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。

［１．決済管理装置の処理］
まず、図１を用いて、実施形態に係る決済管理装置１０が実行する処理の一例について説明する。図１は、実施形態に係る決済管理装置１０が実行する処理の概要を示す図である。

決済管理装置１０は、インターネット等を介して端末装置４０，５０と各種情報の送受信を行い、例えば、ＥＣ（Electronic Commerce）サイトのウェブページを提供するとともに、取引の決済処理を行うサーバ等である。かかるウェブページは、例えば、インターネットを介して商品を購入することができるショッピングサイトやオークションサイトのウェブページである。

なお、決済管理装置１０は、単体の処理装置である必要はなく、クラウドシステム等の複数の処理装置が協調して動作することで実現されてもよい。また、決済管理装置１０におけるＥＣサイトのウェブページを提供する機能と決済処理する機能とは、例えば、別々のサーバに分けて実現されてもよい。

端末装置４０，５０は、決済管理装置１０と通信を行うことができる機能を有する情報処理装置である。端末装置４０，５０は、スマートフォン、タブレット端末、ＰＤＡ（Personal Digital Assistant）、パーソナルコンピュータ、ゲーム機等、任意の情報処理装置が適用される。また、端末装置４０，５０は、３Ｇ（Generation）、４Ｇ、ＬＴＥ（Long Term Evolution）、ＧＳＭ（登録商標）（Global System for Mobile Communications）等の無線通信網や、Ｂｌｕｅｔｏｏｔｈ（登録商標）、無線ＬＡＮなどの近距離無線通信を介してネットワークＮ（図２参照）に接続し、決済管理装置１０と通信することができる。なお、端末装置４０と端末装置５０との間でも、ネットワークＮを介して通信することができる。

端末装置４０は、利用者Ｕによって使用される一方、端末装置５０は、選択候補者Ａ（後述）によって使用される。したがって、以下では、端末装置４０を「利用者端末４０」といい、端末装置５０を「選択候補者端末５０」ということがある。

ここで、利用者端末４０の利用者Ｕが、ＥＣサイトのウェブページを通じて商品の購入を所望しているものとする。その際、利用者Ｕは、自分に代わって商品の対価の支払いを、例えば、親や兄弟、親類、友人など自分以外の人に依頼したい場合がある。

上述のような場合、従来の技術にあっては、例えば、依頼する相手と利用者Ｕとの関係に関する情報を決済管理装置に事前に登録しておき、決済管理装置が、登録した相手の決済情報（例えばクレジットカードの情報等）を用いて決済を行うようにしていた。そのため、従来の技術では、事前に登録した相手にしか支払いの依頼を行うことができず、利便性の点で改善の余地があった。

そこで、決済管理装置１０は、利用者端末４０から購入要求を受け付けると、複数の支払候補者を選択して支払候補者の一覧の情報を利用者端末４０へ送信する。決済管理装置１０は、複数の支払候補者の中から利用者Ｕの操作によって選択された選択候補者Ａの情報を利用者端末４０から取得し、取得された選択候補者Ａの情報に基づいて決済処理を行うこととした。これにより、利用者Ｕの利用者端末４０においては、複数の支払候補者の中から支払って欲しい人を選択することが可能となり、決済処理の利便性を向上させることができる。

図１に示す例では、利用者Ｕが、例えば、ＥＣサイトのウェブページを通じて商品を購入しようとすると、利用者端末４０の画面４１には、購入の意思を確認する購入確認画面Ｗ１が表示される。なお、ここでは、商品を購入することとするが、サービスの購入としてもよい。また、これら商品およびサービスは、購入対象の一例である。

購入確認画面Ｗ１には、例えば、商品名、店舗名、商品の対価の額（以下「価格」ともいう）などの商品に関する情報が領域６０に表示される。さらに、購入確認画面Ｗ１には、利用者Ｕの購入の意思を確定させるボタン６１と、商品の購入をキャンセルするボタン６２とが表示される。

そして、例えば、利用者端末４０は、利用者Ｕによってボタン６１が押下されて購入の意思が示されると、商品の購入要求を決済管理装置１０へ送信し、決済管理装置１０は、送信された購入要求を受け付ける（ステップＳ１）。かかる購入要求には、例えば、商品の注文主（すなわち利用者Ｕ）や店舗名、価格などといった決済に関する各種の情報が含まれる。

続いて、決済管理装置１０は、購入要求に対応する商品の対価を利用者Ｕに代って支払う支払者の候補である複数の支払候補者Ａ，Ｂ，Ｃ，Ｄを選択する（ステップＳ２）。図１に示す例では、決済管理装置１０が、例えば、４人の利用者Ａ〜Ｄを支払候補者Ａ〜Ｄとして選んだものとするが、人数はこれに限定されるものではなく、１人以上であればよい。また、支払候補者のなかに、利用者Ｕが含まれるようにしてもよい。

決済管理装置１０における支払候補者の選択は、例えば、利用者Ｕと他人との関係性を示す関係情報や、過去の支払い実績などを示す履歴情報に基づいて行われる。例えば、決済管理装置１０は、関係情報から利用者Ｕと関連度の高い利用者を支払候補者として選択したり、履歴情報から過去に支払いを多く行った利用者を支払候補者として優先的に選択したりする。なお、関係情報や履歴情報については、後に詳しく説明する。

決済管理装置１０は、選択した複数の支払候補者Ａ〜Ｄの一覧の情報を利用者端末４０へ通知する（ステップＳ３）。これにより、利用者端末４０の画面４１には、支払候補者Ａ〜Ｄの一覧の中から支払者の選択を行う選択画面Ｗ２が表示される。

選択画面Ｗ２には、支払候補者Ａ〜Ｄの一覧と、支払候補者Ａ〜Ｄにそれぞれ関連する情報が領域６３に表示される。なお、支払候補者Ａ〜Ｄにそれぞれ関連する情報は、例えば、履歴情報などである。さらに、選択画面Ｗ２には、支払候補者Ａ〜Ｄにそれぞれ対応するチェックボックス６４と、利用者Ｕによる選択を決定する決定ボタン６５とが表示される。

図１の例では、利用者Ｕによって、支払候補者Ａに対応するチェックボックス６４が選択されるとともに、決定ボタン６５が押下されたものとする。したがって、利用者Ｕは、支払候補者Ａに商品の支払いを依頼したものとする。

これにより、利用者端末４０は、選択された支払候補者Ａの情報を選択候補者Ａの情報として決済管理装置１０へ送信し、決済管理装置１０は、送信された選択候補者Ａの情報を取得する（ステップＳ４）。したがって、選択候補者Ａは、支払候補者Ａと同一の人物である。

続いて、決済管理装置１０は、利用者Ｕに代わって選択候補者Ａが商品の対価の支払いを行う「支払承認」を要求する支払承認要求を、選択候補者Ａの選択候補者端末５０へ送信する（ステップＳ５）。これにより、選択候補者端末５０の画面５１には、支払承認画面Ｗ３が表示される。

支払承認画面Ｗ３には、商品名、店舗名、価格などの商品に関する情報が領域６６に表示される。さらに、支払承認画面Ｗ３には、選択候補者Ａの支払承認の意思を確定させるボタン６７と、支払承認を拒否するボタン６８とが表示される。

そして、選択候補者端末５０は、選択候補者Ａによってボタン６７が押下されて支払承認の意思が示されると、支払承認を示す情報を決済管理装置１０へ送信する（ステップＳ６）。

決済管理装置１０は、かかる支払承認を示す情報を受け付けた場合、選択候補者Ａの決済情報に基づいて、商品の決済処理を行う（ステップＳ７）。

なお、選択候補者端末５０は、選択候補者Ａによってボタン６８が押下された場合、支払承認を拒否する情報を決済管理装置１０へ送信する。そして、図示は省略するが、決済管理装置１０は、支払承認を拒否する情報を受け付けた場合、支払承認されなかった旨の情報を利用者端末４０へ送信し、決済処理を行わない。

このように、決済管理装置１０は、複数の支払候補者Ａ〜Ｄを選択して一覧の情報を利用者端末４０へ送信し、支払候補者Ａ〜Ｄの中から利用者Ｕによって選択された選択候補者Ａの情報に基づいて決済処理を行うこととした。これにより、利用者Ｕの利用者端末４０においては、複数の支払候補者Ａ〜Ｄの中から支払って欲しい人を選択することが可能となり、決済処理の利便性を向上させることができる。

また、決済管理装置１０は、選択候補者Ａの情報が取得された場合に、選択候補者端末５０に対して支払承認要求を送信し、選択候補者端末５０から支払承認を示す情報を受け付けた場合に、選択候補者Ａの情報に基づいて決済処理を行うようにした。これにより、決済管理装置１０は、選択候補者Ａの支払いの意思を確認してから、決済処理を行うことができる。

［２．決済管理システムの構成］
次に、図２を用いて、実施形態に係る決済管理システム１の構成について説明する。図２は、実施形態に係る決済管理システム１の構成例を示す図である。図２に示すように、実施形態に係る決済管理システム１は、決済管理装置１０と、利用者端末４０と、選択候補者端末５０とを含む。

決済管理装置１０、利用者端末４０および選択候補者端末５０は、上述したように、ネットワークＮを介して相互に通信可能に接続される。ネットワークＮは、例えば、インターネットなどのＷＡＮ（Wide Area Network）である。以下、利用者端末４０、選択候補者端末５０および決済管理装置１０の順にそれぞれの構成例を説明する。

［３．利用者端末４０の構成例］
図３は、実施形態に係る利用者端末４０の構成例を示す図である。図３に示すように、利用者端末４０は、通信部４２と、表示部４３と、入力部４４と、記憶部４５と、制御部４６とを備える。

［３．１．通信部４２の構成例］
通信部４２は、ネットワークＮを介して決済管理装置１０と通信するための通信インターフェイスであり、例えば、ＮＩＣ（Network Interface Card）等によって実現される。

［３．２．表示部４３の構成例］
表示部４３は、各種情報を表示する表示デバイスであり、上述した画面４１（図１参照）を含む。例えば、表示部４３は、ＬＣＤ（Liquid Crystal Display）や有機ＥＬディスプレイである。また、表示部４３は、タッチパネル式のディスプレイであってもよい。

［３．３．入力部４４の構成例］
入力部４４は、利用者Ｕから各種操作を受け付ける入力デバイスである。入力部４４は、例えば、文字や数字などを入力するためのボタン等を有する。また、表示部４３がタッチパネル式のディスプレイである場合、表示部４３の一部が入力部４４として機能する。

［３．４．記憶部４５の構成例］
記憶部４５は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。かかる記憶部４５には、各種プログラムや設定データなどが記憶される。また、記憶部４５には、決済管理装置１０から取得したその他の情報も記憶される。

［３．５．制御部４６の構成例］
制御部４６は、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、記憶部４５に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部４６は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

図３に示すように、制御部４６は、送信部４７と、受信部４８と、表示処理部４９とを有し、以下に説明する決済処理の機能や作用を実現または実行する。送信部４７は、利用者Ｕの入力部４４への操作に従って、商品の購入要求、および、利用者Ｕによって選択された選択候補者の情報を決済管理装置１０へ送信する。

受信部４８は、決済管理装置１０から送信される購入確認画面Ｗ１の情報や支払候補者の一覧の情報を受信し、受信した情報を記憶部４５に記憶させる。表示処理部４９は、記憶部４５に記憶された購入確認画面Ｗ１（図１参照）を表示部４３へ出力して表示させたり、支払候補者の一覧の情報に応じた選択画面Ｗ２（図１参照）を表示部４３へ出力して表示させたりする。

［４．選択候補者端末５０の構成例］
図４は、実施形態に係る選択候補者端末５０の構成例を示す図である。図４に示すように、選択候補者端末５０は、利用者端末４０と同様、通信部５２と、表示部５３と、入力部５４と、記憶部５５と、制御部５６とを備える。なお、ここでは、選択候補者端末５０と利用者端末４０とを同様な構成としたが、これに限られず、互いに異なる構成としてもよい。

［４．１．通信部５２の構成例］
通信部５２は、ネットワークＮを介して決済管理装置１０と通信するための通信インターフェイスである。例えば、通信部５２は、ＮＩＣ等によって実現される。

［４．２．表示部５３の構成例］
表示部５３は、各種情報を表示する表示デバイスである。表示部５３は、上述した画面５１（図１参照）を含み、例えば、ＬＣＤや有機ＥＬディスプレイである。また、表示部５３は、タッチパネル式のディスプレイであってもよい。

［４．３．入力部５４の構成例］
入力部５４は、選択候補者Ａから各種操作を受け付ける入力デバイスであり、例えば、文字や数字などを入力するためのボタン等を有する。また、表示部５３がタッチパネル式のディスプレイである場合、表示部５３の一部が入力部５４として機能する。

［４．４．記憶部５５の構成例］
記憶部５５は、例えば、ＲＡＭ、フラッシュメモリ等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。また、記憶部５５には、各種プログラムや設定データなどが記憶されるとともに、決済管理装置１０から取得したその他の情報も記憶される。

［４．５．制御部５６の構成例］
制御部５６は、例えば、ＣＰＵやＭＰＵ等によって、記憶部５５に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部５６は、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現される。

制御部５６は、送信部５７と、受信部５８と、表示処理部５９とを有し、以下に説明する決済処理の機能や作用を実現または実行する。受信部５８は、決済管理装置１０から送信される支払承認要求の情報を受信し、受信した情報を記憶部５５に記憶させる。表示処理部５９は、記憶部５５に記憶された支払承認要求の情報に応じた支払承認画面Ｗ３（図１参照）を表示部５３へ出力して表示させる。

送信部５７は、選択候補者Ａの入力部５４への操作に従って、例えば、支払承認画面Ｗ３を通じて選択された支払承認の情報、あるいは、支払承認を拒否する情報を決済管理装置１０へ送信する。

なお、上述した利用者端末４０の制御部４６および選択候補者端末５０の制御部５６の内部構成は、図３または図４に示した構成に限られず、決済処理を行う構成であれば他の構成であってもよい。また、制御部４６および制御部５６が有する各処理部の接続関係は、図３，４に示した接続関係に限られず、他の接続関係であってもよい。

［５．決済管理装置１０の構成例］
図５は、実施形態に係る決済管理装置１０の構成例を示す図である。なお、以下においては、「データベース」を「ＤＢ」と記載するものとする。図５に示すように、決済管理装置１０は、通信部１１と、記憶部１２と、制御部１３とを備える。

［５．１．通信部１１の構成例］
通信部１１は、ネットワークＮを介して利用者端末４０や選択候補者端末５０と通信するための通信インターフェイスであり、例えば、ＮＩＣ等のインターフェイスである。

［５．２．記憶部１２の構成例］
記憶部１２は、例えば、ＲＡＭ、フラッシュメモリ等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。また、記憶部１２は、関係ＤＢ１４、履歴ＤＢ１５、支払承認ポリシーＤＢ１６、支払承認拒否ポリシーＤＢ１７、および、証明ＤＢ１８を記憶する。

関係ＤＢ１４は、支払候補者を選択する処理で用いられる関係情報が登録されている。関係情報は、利用者Ｕと他人との関係性を示す情報であり、例えば、ソーシャルグラフの情報である。なお、関係情報は、ソーシャルグラフの情報に限定されるものではなく、例えば、利用者Ｕが所属する組織（例えば会社など）において、利用者Ｕと関係のある人や部署の情報を有するディレクトリ（以下、「会社ディレクトリ」ともいう）などであってもよい。

図６は、ソーシャルグラフの一例を示す図である。図６に示すように、ソーシャルグラフは、利用者Ｕと他人（例えば、利用者Ａ〜Ｄ）との関係性を示すグラフである。ソーシャルグラフは、利用者Ｕとの関係性を示す種々のパラメータによって算出される。例えば、ソーシャルグラフは、利用者Ｕとの所定の関係性（例えば、家族、友人、恋人など）、ＳＮＳ（Social Networking Service）の会員間のインターネット上における関係性（例えば、友人関係など）、年齢、職業、住所、趣味などの情報から算出される。

図６に示す例では、利用者ＡおよびＢは利用者Ｕの家族で関連度が最も高く、また、利用者ＣおよびＤは利用者Ｕの友人であり、利用者Ｃ，Ｄの順で関連度が低くなる場合を示しているものとする。

図５に戻って、説明を続ける。履歴ＤＢ１５には、過去に行われた支払承認など支払いの実績を示す履歴情報が登録されている。図７は、履歴ＤＢ１５に記憶された履歴テーブルの一例を示す図である。

図７に示すように、履歴テーブルは、「ユーザＩＤ」、「支払承認要求回数」、「支払承認回数」、「承認率」、「商品の種類・内容」、「価格」、「購入時期」および「店舗名・店舗種類」などの情報を含み、これらの情報は互いに関連付けられている。

「ユーザＩＤ」は、利用者毎に割り当てられる識別情報である。ここでは、例えば、ユーザＩＤ「Ａ」は利用者Ａの識別情報であり、ユーザＩＤ「Ｂ」、「Ｃ」、「Ｄ」はそれぞれ利用者Ｂ，Ｃ，Ｄの識別情報であるものとする。

「支払承認要求回数」は、支払承認要求を対応する利用者の端末装置が受け付けた回数を示す情報である。図７に示す例では、利用者Ａの端末装置（すなわち、選択候補者Ａの選択候補者端末５０）は、２０回の支払承認要求を受け付けたことを示している。

「支払承認回数」は、受け付けた支払承認要求に対し、対応する利用者の端末装置が支払承認を行った回数を示す情報である。図７に示す例では、利用者Ａの端末装置は、１８回の支払承認を行ったことを示している。

「承認率」は、支払承認要求回数に対する支払承認回数の割合を示す情報である。図７に示す例では、利用者Ａの端末装置における承認率が９０％であることを示している。

「商品の種類・内容」は、支払承認を行った商品の種類や内容を示す情報である。例えば、商品の種類は「本」や「楽器」など商品の属性の情報を含み、商品の内容は「本のタイトル」や「楽器名」など商品の具体的な情報を含むものとする。

「価格」は、支払承認が行われて決済処理された商品の価格を示す情報である。図７に示す例では、商品の最低価格から最高価格までの価格の範囲の情報を記憶するようにした。具体的には、例えば、利用者Ａの端末装置においては、1000〜20000円の価格範囲の商品が決済処理されたことを示している。なお、履歴情報における「価格」は、価格範囲に限定されるものではなく、例えば、決済処理された商品の価格の平均値や中央値などであってもよい。

「購入時期」は、支払承認が行われて決済処理した日付に関する情報である。また、「店舗名・店舗種類」は、商品を購入した店舗の名前や種類を示す情報である。なお、店舗の種類は、例えば、「書店」や「デパート」など店舗の業務形態の属性の情報を意味している。

図５の説明に戻ると、支払承認ポリシーＤＢ１６は、支払承認要求に対して支払承認を自動的に行う条件を示す支払承認ポリシーの情報が登録されている。すなわち、「支払承認ポリシー」とは、後述するように、選択候補者へ支払承認要求を送信したり、選択候補者から直接的な支払承認を得たりすることなく、購入要求からそのまま決済処理へ進むことができる条件である。したがって、例えば、支払候補者や選択候補者となり得る利用者Ａ，Ｂ，Ｃ，Ｄは、自身の端末装置などを通じて予め支払承認ポリシーを設定して、支払承認ポリシーＤＢ１６に登録しておくものとする。

図８は、支払承認ポリシーＤＢ１６に記憶された支払承認ポリシーのテーブルの一例を示す図である。

図８に示すように、支払承認ポリシーのテーブルは、「ユーザＩＤ」、「利用者名」、「商品の種類・内容」、「価格の上限額」、「購入時期」、「店舗名・店舗種類」および「支払承認期限」などの情報を含み、これらの情報は互いに関連付けられている。

「ユーザＩＤ」は、ここでは、支払承認ポリシーの情報を登録した利用者を示す情報である。すなわち、図８に示す例では、「ユーザＩＤ」は、支払候補者や選択候補者となり得る利用者Ａ〜Ｄを示している。

「利用者名」は、支払承認ポリシーを適用する利用者に関する情報である。なお、図８に示す例では、全て「利用者Ｕ」が登録されているものとする。

「商品の種類・内容」は、自動的に支払承認する商品の種類や内容の情報である。図８に示す例では、利用者Ａが商品の種類・内容を「本」に設定したことを示している。また、「価格の上限額」は、自動的に支払承認できる価格の上限額を示す情報である。図８に示す例では、利用者Ａが上限額を「10000円」に設定したことを示している。

「購入時期」は、自動的に支払承認する購入時期を示す情報であり、具体的には、例えば、定期的に発行される本の発行日などが登録される。また、「店舗名・店舗種類」は、自動的に支払承認できる店舗の名称や店舗の業務形態の属性を示す情報である。「支払承認期限」は、自動的に支払承認する期限を示す情報である。

このように、支払承認ポリシーの情報は、利用者、購入対象の種類および内容、購入対象の価格の上限額、購入対象を購入する時期、購入が行われる店舗および当該店舗の種類、および、支払承認を行う期間のうち少なくとも１以上の情報を含む。これにより、種々の条件を支払承認ポリシーとして設定することが可能となり、決済管理装置１０における決済処理の利便性を一層向上させることができる。

なお、ここでは、購入要求の内容が、例えば、上述した「商品の種類・内容」や「価格の上限額」などの各条件の全てを満たす場合に、自動的に支払承認を行うようにすることとするが、これに限定されるものではない。すなわち、例えば、購入要求の内容の一部が、上述した条件を満たす場合にも、自動的に支払承認を行うようにしてもよい。

図５に戻って、説明を続ける。支払承認拒否ポリシーＤＢ１７は、購入要求の内容で支払承認要求があった場合に、支払承認を拒否する条件を示す支払承認拒否ポリシーの情報が登録されている。すなわち、「支払承認拒否ポリシー」とは、支払候補者となり得る利用者Ａ，Ｂ，Ｃ，Ｄが支払承認をすることができない条件である。

したがって、例えば、支払候補者となり得る利用者Ａ〜Ｄは、自身の端末装置などを通じて予め支払承認拒否ポリシーを設定して、支払承認拒否ポリシーＤＢ１７に登録しておくものとする。そして、後述するように、利用者端末４０からの購入要求が、支払承認拒否ポリシーを満たす場合、当該支払承認拒否ポリシーを設定した利用者を支払候補者から除外するようにする。

図９は、支払承認拒否ポリシーＤＢ１７に記憶された支払承認拒否ポリシーテーブルの一例を示す図である。

図９に示すように、支払承認拒否ポリシーテーブルは、「ユーザＩＤ」、「利用者名」、「商品の種類・内容」、「価格」、「購入時期」、「店舗名・店舗種類」および「支払承認拒否期限」などの情報を含み、これらの情報は互いに関連付けられている。

「ユーザＩＤ」は、ここでは、支払承認拒否ポリシーの情報を登録した利用者を示す情報である。すなわち、図９に示す例では、「ユーザＩＤ」は、支払候補者となり得る利用者Ａ，Ｂ，Ｃ，Ｄを示している。

「利用者名」は、支払承認拒否ポリシーを適用する利用者に関する情報である。なお、図９に示す例では、全て「利用者Ｕ」が登録されているものとする。

「商品の種類・内容」は、支払承認することができない商品の種類や内容の情報である。図９に示す例では、利用者Ａが商品の種類・内容を「玩具」に設定したことを示している。

「価格」、「購入時期」、「店舗名・店舗種類」、「支払承認拒否期限」は、それぞれ支払承認することができない商品の価格、購入時期、店舗の名称や店舗の業務形態の属性、期限を示す情報である。

なお、ここでは、購入要求の内容が、例えば、上述した「商品の種類・内容」や「価格」などの各条件の全てを満たす場合に、かかる条件を設定した利用者を支払候補者から除外することとするが、これに限定されるものではない。すなわち、例えば、購入要求の内容の一部が、上述した支払承認拒否ポリシーの条件を満たす場合に、対応する利用者を支払候補者から除外するようにしてもよい。

図５に戻って、説明を続ける。証明ＤＢ１８は、利用者端末４０の正当性を証明する証明情報が登録されている。証明情報としては、例えば、利用者端末４０の電子署名などを用いることができる。

［５．３．制御部１３の構成例］
制御部１３は、例えば、ＣＰＵやＭＰＵ等によって、制御部１３内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１３は、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現される。

図５に示すように、制御部１３は、購入要求受付部２０、関係情報取得部２１、履歴情報取得部２２、支払承認ポリシー取得部２３、支払承認拒否ポリシー取得部２４、支払候補者選択部２５、一覧情報通知部２６、選択情報取得部２７、証明情報取得部２８、支払承認要求部２９、支払承認受付部３０、および、決済部３１を備える。なお、制御部１３の内部構成は、図５に示した構成に限られず、後述する決済処理を行う構成であれば他の構成であってもよい。また、制御部１３が有する各処理部の接続関係は、図５に示した接続関係に限られず、他の接続関係であってもよい。

購入要求受付部２０は、利用者端末４０から送信される購入要求を受け付ける。購入要求受付部２０は、受け付けた購入要求の情報を支払候補者選択部２５、支払承認要求部２９および決済部３１へ通知する。

関係情報取得部２１は、関係情報を関係ＤＢ１４から取得する。関係情報取得部２１は、取得した関係情報を、支払候補者選択部２５へ通知する。

履歴情報取得部２２は、履歴情報を履歴ＤＢ１５から取得する。履歴情報取得部２２は、取得した履歴情報を支払候補者選択部２５へ通知する。

支払承認ポリシー取得部２３は、支払承認ポリシーの情報を支払承認ポリシーＤＢ１６から取得する。支払承認ポリシー取得部２３は、取得した支払承認ポリシーの情報を支払候補者選択部２５、支払承認要求部２９および決済部３１へ通知する。

支払承認拒否ポリシー取得部２４は、支払承認拒否ポリシーの情報を支払承認拒否ポリシーＤＢ１７から取得する。支払承認拒否ポリシー取得部２４は、取得した支払承認拒否ポリシーの情報を支払候補者選択部２５へ通知する。

支払候補者選択部２５は、購入要求に対応する商品の対価を利用者端末４０の利用者Ｕに代って支払う複数の支払候補者Ａ〜Ｄを選択する。そして、一覧情報通知部２６は、支払候補者選択部２５によって選択された支払候補者Ａ〜Ｄの一覧の情報を利用者端末４０へ通知する。

これにより、利用者端末４０の表示部４３の画面４１には、支払候補者Ａ〜Ｄの一覧の情報が含まれる選択画面Ｗ２が表示される。図１０は、利用者端末４０の表示部４３の画面４１に表示される選択画面Ｗ２の一例を示す図である。

ここで、支払候補者選択部２５における支払候補者Ａ〜Ｄの選択について説明する。支払候補者選択部２５は、関係情報（例えば、ソーシャルグラフの情報）に基づいて、複数の支払候補者Ａ〜Ｄを選択するようにしてもよい。

すなわち、利用者Ｕの利用者端末４０からの支払承認要求に対し、支払承認を行う可能性が高いのは、利用者Ｕとの関係性が深い利用者であることが多い。また、上述したように、ソーシャルグラフは、利用者Ｕとの関係性を示すグラフである。

したがって、支払候補者選択部２５は、複数の利用者の中から、利用者Ｕとの関連度が高い順番、すなわち、利用者Ａ，Ｂ，Ｃ，Ｄをこの順番で、支払候補者Ａ，Ｂ，Ｃ，Ｄとして選択する。このように、決済管理装置１０は、利用者Ｕと関係のある人を支払候補者として選択することが可能となり、よって利用者Ｕの支払候補者を選択する手間を削減することができる。

そして、選択画面Ｗ２では、例えば、支払候補者選択部２５によって選択された順番で上から並べて一覧表示されるようにする。これにより、決済管理装置１０は、支払候補者Ａ，Ｂ，Ｃ，Ｄを、支払承認を行う可能性が高い順番に並べて表示させることができる。

なお、支払候補者Ａと支払候補者Ｂとは、利用者Ｕとの関連度が同じであるため、支払候補者Ａ，Ｂの順番を入れ替えて表示させてもよい。また、選択画面Ｗ２の表示手法は、上記のものに限定されない。すなわち、例えば、選択画面Ｗ２において、支払承認を行う可能性が高い順に、支払候補者の表示サイズを変えたり、色を変えたり、点滅させたりするなど他の手法で表示させるようにしてもよい。

また、支払候補者選択部２５は、例えば、履歴情報に基づいて、複数の支払候補者Ａ〜Ｄを選択するようにしてもよい。すなわち、利用者Ｕの利用者端末４０からの支払承認要求に対し、支払承認を行う可能性が高いのは、支払承認した回数など支払いの実績がある利用者であることが多い。

したがって、支払候補者選択部２５は、複数の利用者の中から、過去に支払いなどの履歴が多くある順番、すなわち、利用者Ａ，Ｂ，Ｃ，Ｄをこの順番で、支払候補者Ａ，Ｂ，Ｃ，Ｄとして選択する。このように、決済管理装置１０は、例えば、過去に支払い実績のある人を支払候補者として選択することが可能となり、よって利用者Ｕの支払候補者を選択する手間を削減することができる。

そして、選択画面Ｗ２では、例えば、支払候補者選択部２５によって選択された順番で並べて一覧表示されるようにする。これにより、決済管理装置１０は、支払候補者Ａ，Ｂ，Ｃ，Ｄを、支払承認を行う可能性が高い順番に並べて表示させることができる。

また、支払候補者選択部２５は、例えば、購入要求の内容が支払承認ポリシーを満たしている場合には、支払承認ポリシーに対応する支払候補者を優先的に選択するようにしてもよい。

すなわち、利用者Ｕの利用者端末４０からの購入要求の内容が支払承認ポリシーを満たしている場合、かかる支払承認ポリシーを設定している支払候補者が利用者Ｕによって支払者として選択されると、そのまま自動的に決済処理が行われる。このように、支払候補者選択部２５は、上述のような支払候補者を優先的に選択することで、購入要求から決済処理までを迅速に行わせることが可能となる。

また、支払候補者選択部２５は、例えば、利用者Ｕの利用者端末４０からの購入要求の内容が支払承認拒否ポリシーを満たしている場合には、当該支払承認拒否ポリシーに対応する支払候補者を除外するようにしてもよい。

すなわち、支払承認拒否ポリシーは、支払候補者が支払承認をすることができない条件であることから、かかる支払承認拒否ポリシーを満たす購入要求の内容で支払承認を要求しても、支払承認される可能性は少ない。

そこで、支払候補者選択部２５は、支払承認要求をしても支払承認される可能性が少ない支払候補者については、選択せずに除外するようにしてもよい。これにより、支払候補者選択部２５は、利用者Ｕの支払候補者を選択する手間を削減することができ、さらに、支払承認を行う可能性がより高い支払候補者を選択することができる。

図１０の説明を続けると、選択画面Ｗ２には、上述したように、支払候補者Ａ〜Ｄにそれぞれ関連する情報が領域６３に表示される。図１０に示すように、領域６３は、例えば、第１領域６３ａ、第２領域６３ｂおよび第３領域６３ｃに区画される。

第１領域６３ａには、例えば、ソーシャルグラフの情報に基づいて推定される支払承認の可能性に応じたランクの情報が表示される。

例えば、支払候補者選択部２５は、ソーシャルグラフの情報に基づいて支払承認の可能性を推定し、推定される可能性に応じたランク付けを支払候補者毎に行う。上述したように、支払承認を行う可能性が高いのは、利用者Ｕとの関係性が深い利用者であることが多いため、支払候補者選択部２５は、支払候補者Ａ，Ｂ，Ｃ，Ｄの順でランク付けを行う。

そして、支払候補者選択部２５は、ランク付けした情報を支払候補者の一覧の情報に含めて表示させる。図１０に示す例では、支払候補者Ａ，Ｂの支払承認の可能性を８０％、支払候補者Ｃの支払承認の可能性を４０％、支払候補者Ｄの支払承認の可能性を１０％と推定した場合を示している。なお、上述した例では、支払承認の可能性を「％」で表示するようにしたが、これに限定されるものではなく、例えば、グラフや絵、色を変えるなど別の手法で表示するようにしてもよい。

第２領域６３ｂには、例えば、履歴情報が表示されるようにしてもよい。また、第３領域６３ｃには、支払承認ポリシーの情報が表示されるようにしてもよい。このように、支払承認の可能性、履歴情報や支払承認ポリシーの情報を表示させることで、利用者Ｕは支払承認する可能性の高い支払候補者を容易に判断して選択し易くなり、よって決済管理装置１０の利便性をより一層向上させることができる。

図５に戻って、説明を続ける。選択情報取得部２７は、支払候補者の一覧の中から選択された支払候補者の情報を選択候補者の情報として利用者端末４０から取得する。選択情報取得部２７は、取得した選択候補者の情報を支払承認要求部２９および決済部３１へ通知する。なお、ここでは、支払候補者Ａ（図１０参照）が利用者Ｕによって選択されたものとする。

証明情報取得部２８は、証明情報を証明ＤＢ１８から取得する。証明情報取得部２８は、取得した証明情報を支払承認要求部２９へ通知する。

支払承認要求部２９は、購入要求の内容が、選択候補者Ａの支払承認ポリシーを満たすか否かを判定する。そして、支払承認要求部２９は、購入要求の内容が支払承認ポリシーを満たさないと判定した場合、選択候補者端末５０に対し、支払承認を要求する支払承認要求を送信する。

また、支払承認要求部２９は、選択候補者端末５０に対し、証明情報を支払承認要求に含めて送信する。これにより、選択候補者端末５０側の選択候補者Ａは、送信された支払承認要求が利用者Ｕの利用者端末４０から届いた正当な支払承認要求であることを確認することができる。

上述した支払承認要求の送信により、選択候補者端末５０の表示部５３の画面５１には、支払承認画面Ｗ３が表示される。図１１は、選択候補者端末５０の表示部５３の画面５１に表示される支払承認画面Ｗ３の一例を示す図である。

図１１に示すように、支払承認画面Ｗ３には、商品に関する情報が示される領域６６とともに、選択候補者Ａの支払承認の意思を確定させるボタン６７と、支払承認を拒否するボタン６８とが表示される。

なお、上述の例では、支払承認要求部２９は、電子署名を証明情報として支払承認要求に含ませるようにしたが、利用者端末４０の正当性を証明する証明情報はこれに限定されるものではない。

すなわち、例えば、支払承認要求部２９は、支払承認画面Ｗ３に、利用者Ｕの利用者端末４０へ連絡するための連絡ボタン６９を表示させるようにしてもよい。かかる連絡ボタン６９が選択候補者Ａによって押下されると、選択候補者端末５０から利用者端末４０へ電話や電子メール等がつながる。これにより、選択候補者Ａは、支払承認要求の正当性を、利用者Ｕに直接確認することも可能となる。

また、図示は省略するが、支払承認要求部２９は、例えば、利用者Ｕと選択候補者Ａとの間でのみ有効な秘密の情報（例えば、パスワードや合言葉など）を証明情報として支払承認要求に含ませるようにしてもよい。

また、図示は省略するが、支払承認要求部２９は、例えば、アクセスコードを証明情報として支払承認要求に含ませて選択候補者端末５０へ送信するようにしてもよい。選択候補者端末５０の選択候補者Ａは、アクセスコードを用いて認証サイトへログインし、購入要求の内容や支払承認要求した利用者の情報を確認するようにしてもよい。

さらには、図１１に示すように、支払承認要求部２９は、例えば、選択候補者Ａが支払承認することを支援する情報を支払承認画面Ｗ３に表示させるようにしてもよい。例えば、支払承認要求部２９は、「Ａさん（選択候補者Ａ）のポイントでのお支払いが可能です」や「電子マネーをご利用頂けます」など支払承認を支援するような文言を領域７０に表示させるようにしてもよい。これにより、選択候補者Ａに対して、支払承認の動機付けを行うことができ、商品の取引を成立させ易くすることができる。

なお、上述した「ポイント」は、例えば、決済管理装置１０などのサーバが提供するサービス（例えば、オンラインショッピング、オークション、オンラインゲームなど）に用いることができる仮想価値である。かかるポイントは、その他のサービスに用いることができる仮想価値であってもよい。

他方、支払承認要求部２９は、購入要求の内容が支払承認ポリシーを満たすと判定した場合には、選択候補者端末５０に対して支払承認要求の送信を行わない。

支払承認要求部２９が選択候補者端末５０へ支払承認要求を送信した場合、支払承認受付部３０は、支払承認要求に対して支払承認を示す情報を選択候補者端末５０から受け付ける。支払承認受付部３０は、受け付けた支払承認を示す情報を決済部３１へ通知する。

決済部３１は、支払承認受付部３０によって支払承認を示す情報を受け付けた場合に、選択候補者Ａの情報に基づいて商品の決済処理を行う。

なお、上述したように、購入要求の内容が支払承認ポリシーを満たす場合には、支払承認要求部２９で支払承認要求の送信が行われないことから、決済部３１は、支払承認を示す情報を受け付けることはない。そこで、決済部３１は、購入要求の内容が支払承認ポリシーを満たす場合に、選択候補者Ａを支払者として商品の決済処理を行うようにする。

このように、決済管理装置１０は、購入要求の内容が支払承認ポリシーを満たす場合、選択候補者端末５０へ支払承認要求を送信せずに、決済処理を行うことから、迅速な商品の取引を行うことが可能となる。また、選択候補者端末５０の選択候補者Ａにおける支払承認を行う手間を省略することができるため、決済管理装置１０の利便性をより一層向上させることができる。

［６．決済管理装置１０の処理フロー］
次に、決済管理装置１０による決済処理の手順の一例について説明する。図１２は、決済管理装置１０による決済処理の流れの一例を説明するための図である。図１２に示す決済処理は、決済管理装置１０の制御部１３によって繰り返し実行される。

図１２に示すように、制御部１３は、利用者端末４０から購入要求を受け付けたか否かを判定する（ステップＳ１１）。購入要求を受け付けていない場合（ステップＳ１１，Ｎｏ）、制御部１３はステップＳ１１の処理へ戻る。一方、購入要求を受け付けた場合（ステップＳ１１，Ｙｅｓ）、制御部１３は、関係情報、履歴情報、支払承認ポリシーの情報および支払承認拒否ポリシーの情報を取得する（ステップＳ１２）。

次いで、制御部１３は、購入要求の情報、関係情報、履歴情報および支払承認ポリシーの情報に基づいて、複数の支払候補者を選択する（ステップＳ１３）。続いて、制御部１３は、支払承認拒否ポリシーの情報に基づいて支払候補者を除外する（ステップＳ１４）。

制御部１３は、複数の支払候補者の一覧の情報を利用者端末４０へ通知する（ステップＳ１５）。そして、制御部１３は、支払候補者の一覧の中から選択された支払候補者の情報を選択候補者の情報として利用者端末４０から取得する（ステップＳ１６）。

次いで、制御部１３は、購入要求の内容が選択候補者の支払承認ポリシーを満たすか否かを判定する（ステップＳ１７）。購入要求の内容が支払承認ポリシーを満たさない場合（ステップＳ１７，Ｎｏ）、制御部１３は、証明情報を取得する（ステップＳ１８）。

制御部１３は、選択候補者端末５０に対し、証明情報を支払承認要求に含めて送信する（ステップＳ１９）。続いて、制御部１３は、選択候補者端末５０から支払承認を受け付けたか否かを判定する（ステップＳ２０）。

選択候補者端末５０から支払承認を受け付けた場合（ステップＳ２０，Ｙｅｓ）、制御部１３は、選択候補者Ａの情報に基づき、選択候補者Ａを支払者として商品の決済処理を行う（ステップＳ２１）。一方、選択候補者端末５０から支払承認を受け付けなかった場合（ステップＳ２０，Ｎｏ）、例えば、支払承認を拒否する情報を受け付けた場合、制御部１３は、支払承認されなかった旨の情報を利用者端末４０へ送信する（ステップＳ２２）。

他方、購入要求の内容が支払承認ポリシーを満たした場合（ステップＳ１７，Ｙｅｓ）、制御部１３は、選択候補者端末５０へ支払承認要求を送信せずに、決済処理を行う（ステップＳ２１）。

［７．変形例］
上述した実施形態に係る決済管理装置１０は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、決済管理装置１０の変形例について説明する。

［７．１．選択候補者について］
上述した決済管理装置１０では、複数の支払候補者Ａ〜Ｄの中から、例えば一人の支払候補者Ａが利用者Ｕによって選択される場合を例に挙げて説明したが、これに限定されるものではない。

すなわち、例えば、複数の支払候補者Ａ〜Ｄの一覧の中から、複数の支払候補者が利用者Ｕによって選択されるようにしてもよい。そして、決済管理装置１０の選択情報取得部２７は、選択された複数の支払候補者の情報を複数の選択候補者の情報として利用者端末４０から取得するようにしてもよい。

このように、複数の選択候補者の情報を取得した場合、決済管理装置１０の支払承認要求部２９は、複数の選択候補者の選択候補者端末に対してそれぞれ支払承認要求を送信することとなる。これにより、決済管理装置１０は、例えば、支払承認要求が送信された複数の選択候補者端末のうち、少なくとも一つの選択候補者端末から支払承認を受け付けた場合、決済処理を行うこととなるため、商品の取引を成立させ易くすることができる。また、決済管理装置１０の決済処理の利便性も向上させることができる。

また、決済管理装置１０は、支払承認要求が送信された複数の選択候補者端末のうち、例えば、複数の選択候補者端末から支払承認を受け付けた場合、商品の対価を、支払承認を受け付けた複数の選択候補者端末で分けて決済するようにしてもよい。これにより、決済管理装置１０の決済処理の利便性をより向上させることができる。

また、決済管理装置１０は、例えば、複数の選択候補者端末から支払承認を受け付けた場合に、最先に受け付けた支払承認を示す情報に対応する選択候補者を支払者として商品の決済処理を行うようにしてもよい。これにより、商品の取引を迅速に行うことが可能になるとともに、決済管理装置１０の決済処理の利便性もより一層向上させることができる。

［７．２．関係情報による支払候補者の選択について］
上述した決済管理装置１０では、関係情報としてソーシャルグラフを用いる場合を例に挙げて説明したが、これに限定されるものではない。例えば、上述した決済管理装置１０を、会社における経費や出張費の決済などに適用させる場合、ソーシャルグラフとは別の情報を関係情報として用いるようにしてもよい。

ここで、経費の決済を例にとって説明する。関係ＤＢ１４には、ソーシャルグラフの情報に加えて、あるいは、ソーシャルグラフの情報に代えて、上述した会社ディレクトリが関係情報として登録されているものとする。なお、会社ディレクトリには、例えば、利用者Ｕが所属する会社において、決済を担当する決済担当者や部署の情報が含まれているものとする。

関係情報取得部２１は、経費で購入すべき商品の購入要求を購入要求受付部２０で受け付けた場合、会社ディレクトリを関係ＤＢ１４から取得する。関係情報取得部２１は、取得した会社ディレクトリを支払候補者選択部２５へ通知する。

支払候補者選択部２５は、会社ディレクトリの情報に基づいて、例えば、決済担当者を支払候補者として選択する。これにより、利用者端末４０における選択画面Ｗ２には、支払候補者たる決済担当者の情報が表示される。

そして、選択画面Ｗ２において決済担当者が利用者Ｕによって選択されると、決済管理装置１０は、決済担当者に対して支払承認要求を送信し、決済担当者から支払承認を受け付けた場合に商品の決済処理を行う点は、上述と同様であるため、説明を省略する。

これにより、決済管理装置１０の決済処理の利便性をより一層向上させることができる。すなわち、例えば、従来、利用者Ｕは、経費で支払うべき商品を購入する場合、商品の対価を一旦支払い、その後会社で精算する、いわゆる立て替え払いを行っていた。これに対し、決済管理装置１０は、上述のように構成したことから、商品の支払時に会社側で決済が行われるため、利用者Ｕの会社での精算等の手間を減らすことができ、利便性を向上させることができる。

さらに、決済管理装置１０は、購入する商品、または、利用者Ｕからの指示などに応じて、関係情報として、ソーシャルグラフおよび会社ディレクトリのうちのいずれの情報を取得すべきかを選択し、選択して取得した情報によって支払候補者を切り替えるような構成としてもよい。

［８．ハードウェア構成］
なお、上述した実施形態における決済管理装置１０、利用者端末４０および選択候補者端末５０は、例えば、図１３に示すような構成のコンピュータ１００がプログラムを実行することによって実現される。図１３は、プログラムを実行するコンピュータ１００のハードウェア構成の一例を示す図である。コンピュータ１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ（Read Only Memory）１０３、ＨＤＤ（Hard Disk Drive）１０４、通信インターフェイス（Ｉ／Ｆ）１０５、入出力インターフェイス（Ｉ／Ｆ）１０６、およびメディアインターフェイス（Ｉ／Ｆ）１０７を備える。

ＣＰＵ１０１は、ＲＯＭ１０３またはＨＤＤ１０４に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１０３は、コンピュータ１００の起動時にＣＰＵ１０１によって実行されるブートプログラムや、コンピュータ１００のハードウェアに依存するプログラム等を格納する。

ＨＤＤ１０４は、ＣＰＵ１０１によって実行されるプログラムによって使用されるデータ等を格納する。通信インターフェイス１０５は、ネットワークＮを介して他の機器からデータを受信してＣＰＵ１０１へ送り、ＣＰＵ１０１が生成したデータを、ネットワークＮを介して他の機器へ送信する。

ＣＰＵ１０１は、入出力インターフェイス１０６を介して、ディスプレイやプリンタ等の出力装置、および、キーボードやマウス等の入力装置を制御する。ＣＰＵ１０１は、入出力インターフェイス１０６を介して、入力装置からデータを取得する。また、ＣＰＵ１０１は、生成したデータを、入出力インターフェイス１０６を介して出力装置へ出力する。

メディアインターフェイス１０７は、記録媒体１０８に格納されたプログラムまたはデータを読み取り、ＲＡＭ１０２を介してＣＰＵ１０１に提供する。ＣＰＵ１０１は、当該プログラムを、メディアインターフェイス１０７を介して記録媒体１０８からＲＡＭ１０２上にロードし、ロードしたプログラムを実行する。記録媒体１０８は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

コンピュータ１００が上述した実施形態に係る決済管理装置１０として機能する場合、コンピュータ１００のＣＰＵ１０１は、ＲＡＭ１０２上にロードされたプログラムを実行することにより、例えば、購入要求受付部２０、関係情報取得部２１、履歴情報取得部２２、支払承認ポリシー取得部２３、支払承認拒否ポリシー取得部２４、支払候補者選択部２５、一覧情報通知部２６、選択情報取得部２７、証明情報取得部２８、支払承認要求部２９、支払承認受付部３０、および、決済部３１の各機能を実現する。

また、コンピュータ１００が上述した実施形態に係る利用者端末４０として機能する場合、コンピュータ１００のＣＰＵ１０１は、ＲＡＭ１０２上にロードされたプログラムや決済管理装置１０から受信した決済管理プログラムを実行することにより、例えば、送信部４７、受信部４８および表示処理部４９の各機能を実現する。

また、コンピュータ１００が上述した実施形態に係る選択候補者端末５０として機能する場合、コンピュータ１００のＣＰＵ１０１は、ＲＡＭ１０２上にロードされたプログラムや決済管理装置１０から受信した決済管理プログラムを実行することにより、例えば、送信部５７、受信部５８および表示処理部５９の各機能を実現する。

コンピュータ１００のＣＰＵ１０１は、プログラムを、記録媒体１０８から読み取って実行するが、他の例として、他の装置から、ネットワークＮを介してこれらのプログラムを取得してもよい。

［９．効果］
実施形態に係る決済管理装置１０は、利用者端末４０から送信される購入要求を受け付け、購入要求に対応する商品の対価を利用者端末４０の利用者Ｕに代って支払う支払者の候補である複数の支払候補者を選択する。そして、決済管理装置１０は、支払候補者の一覧の情報を利用者端末４０へ通知し、支払候補者の一覧の中から選択された支払候補者の情報を選択候補者の情報として利用者端末４０から取得する。そして、決済管理装置１０は、選択候補者の情報に基づいて商品の決済処理を行う。

これにより、決済管理装置１０における決済処理の利便性を向上させることができる。すなわち、決済管理装置１０を上述のように構成することで、例えば、利用者Ｕは、簡単に自分以外の第三者（選択候補者）の支払いのもと、商品の購入を自分で行うことができる。また、例えば、利用者Ｕは、支払いを依頼したい相手との関係に関する情報を事前に決済管理装置に登録する作業をしたり、支払いをして欲しい相手に代理での商品購入を依頼したりする必要がないことから、利用者Ｕの手間を減らすことができる。

また、決済管理装置１０は、利用者Ｕと他者との関係性を示す関係情報を取得し、取得した関係情報に基づいて、複数の支払候補者を選択する。これにより、決済管理装置１０は、利用者Ｕと関係のある人を支払候補者として選択することが可能となり、よって利用者Ｕの支払候補者を選択する手間を削減することができる。

また、決済管理装置１０は、関係情報に基づいて推定される支払承認の可能性に応じたランク付けを支払候補者毎に行い、当該ランクの情報を支払候補者の一覧の情報に含めるようにした。これにより、決済管理装置１０は、例えば、支払候補者を、支払承認を行う可能性が高い順番に並べて表示させることが可能になるとともに、利用者Ｕは支払承認する可能性の高い支払候補者を容易に判断して選択し易くなり、よって決済管理装置１０の利便性をより一層向上させることができる。

また、決済管理装置１０は、選択候補者端末５０に対して支払承認要求を送信し、支払承認を示す情報を受け付けた場合に、選択候補者の情報に基づいて商品の決済処理を行うようにした。これにより、決済管理装置１０は、選択候補者Ａの支払いの意思を確認してから、決済処理を行うことができる。

また、決済管理装置１０は、支払承認の履歴情報に基づいて、複数の支払候補者を選択するようにした。これにより、決済管理装置１０は、例えば、過去に支払い実績のある人を支払候補者として選択することが可能となり、よって利用者Ｕの支払候補者を選択する手間を削減することができる。また、決済管理装置１０は、支払候補者を、支払承認を行う可能性が高い順番に並べて表示させることも可能になるとともに、利用者Ｕは支払承認する可能性の高い支払候補者を容易に判断して選択し易くなり、よって決済管理装置１０の利便性をより一層向上させることができる。

また、決済管理装置１０は、購入要求の内容が支払承認ポリシーを満たす場合には、選択候補者端末５０に対して支払承認要求の送信を行わず、選択候補者Ａを支払者として商品の決済処理を行うようにした。これにより、迅速な商品の取引を行うことが可能となる。また、選択候補者端末５０の選択候補者Ａにおける支払承認を行う手間を省略することができるため、決済管理装置１０の利便性をより一層向上させることができる。

また、支払承認ポリシーの情報は、利用者、商品の種類および内容、商品の対価の上限額、商品を購入する時期、購入が行われる店舗および当該店舗の種類、および、支払承認を行う期間のうち少なくとも１以上の情報を含む。これにより、種々の条件を支払承認ポリシーとして設定することが可能となり、決済管理装置１０における決済処理の利便性を一層向上させることができる。

また、決済管理装置１０は、購入要求の内容が支払承認ポリシーを満たしている場合には、当該支払承認ポリシーに対応する支払候補者を優先的に選択するようにした。これにより、購入要求から決済処理までを迅速に行わせることが可能となる。

また、決済管理装置１０は、購入要求の内容が支払承認拒否ポリシーを満たしている場合には、当該支払承認拒否ポリシーに対応する支払候補者を除外するようにした。これにより、決済管理装置１０は、例えば、支払承認要求をしても支払承認される可能性が少ない支払候補者については、選択せずに除外することが可能となり、よって利用者Ｕの支払候補者を選択する手間を削減することができる。さらに、決済管理装置１０は、例えば、支払承認を行う可能性がより高い支払候補者を選択することもできる。

また、決済管理装置１０は、選択候補者端末５０に対し、利用者端末４０の正当性を証明する証明情報を支払承認要求に含めて送信するようにした。これにより、選択候補者端末５０側の選択候補者Ａは、送信された支払承認要求が利用者Ｕの利用者端末４０から届いた正当な支払承認要求であることを確認することができる。

また、決済管理装置１０は、支払候補者の一覧の中から選択された複数の支払候補者の情報を複数の選択候補者の情報として利用者端末４０から取得するようにした。これにより、決済管理装置１０は、例えば、支払承認要求が送信された複数の選択候補者端末のうち、少なくとも一つの選択候補者端末から支払承認を受け付けた場合、決済処理を行うこととなるため、商品の取引を成立させ易くすることができる。また、決済管理装置１０の決済処理の利便性も向上させることができる。

また、決済管理装置１０は、複数の選択候補者端末５０から支払承認を示す情報を受け付けた場合に、最先に受け付けた支払承認を示す情報に対応する選択候補者を支払者として商品の決済処理を行うようにした。これにより、商品の取引を迅速に行うことが可能になるとともに、決済管理装置１０の決済処理の利便性もより一層向上させることができる。

［１０．その他］
上記実施形態において図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

また、上述した決済管理装置１０の各部２０〜３１の機能の全部または一部を、例えば、利用者端末４０の制御部４６および選択候補者端末５０の制御部５６の少なくともいずれかに実行させるように構成し、残りの機能を決済管理装置１０の制御部１３に実行させるような構成としてもよい。上述した例では、関係情報取得部２１などの各取得部２１，２２，２３，２４，２８が、それぞれ対応するＤＢ１４〜１８から各種情報を取得するようにしたが、これに限定されるものではなく、例えば、図示しない別のサーバから各種情報を取得するようにしてもよい。

上述した決済管理装置１０の支払候補者選択部２５においては、関係情報、履歴情報および支払承認ポリシーの情報のうち少なくとも１以上の情報に基づいて、複数の支払候補者を選択するようにしてもよい。

また、上述した決済管理装置１０では、利用者Ｕが商品を購入する場合を例に挙げて説明したが、これに限定されるものではなく、例えば、ギフトなどで友人へ支払いを依頼するような場合にも適用可能である。また、上述では、各ＤＢ１４〜１８に登録される情報を具体的に示したが、これらは例示であって、限定されるものではない。

さらなる効果や変形例は、当業者によって容易に導き出すことができる。このため、本発明のより広範な態様は、以上のように表しかつ記述した特定の詳細および代表的な実施形態に限定されるものではない。したがって、添付の特許請求の範囲およびその均等物によって定義される総括的な発明の概念の精神または範囲から逸脱することなく、様々な変更が可能である。

１ 決済管理システム
１０ 決済管理装置
１１ 通信部
１２ 記憶部
１３ 制御部
１４ 関係ＤＢ
１５ 履歴ＤＢ
１６ 支払承認ポリシーＤＢ
１７ 支払承認拒否ポリシーＤＢ
１８ 証明ＤＢ
２０ 購入要求受付部
２１ 関係情報取得部
２２ 履歴情報取得部
２３ 支払承認ポリシー取得部
２４ 支払承認拒否ポリシー取得部
２５ 支払候補者選択部
２６ 一覧情報通知部
２７ 選択情報取得部
２８ 証明情報取得部
２９ 支払承認要求部
３０ 支払承認受付部
３１ 決済部
４０ 利用者端末
５０ 選択候補者端末

Claims (14)

1. 利用者端末から送信される購入要求を受け付ける購入要求受付部と、
   前記購入要求受付部によって受け付けた前記購入要求に対応する購入対象の対価を前記利用者端末の利用者に代って支払う支払者の候補である複数の支払候補者を選択する支払候補者選択部と、
   前記支払候補者選択部によって選択された前記支払候補者の一覧の情報を前記利用者端末へ通知する一覧情報通知部と、
   前記支払候補者の一覧の中から選択された前記支払候補者の情報を選択候補者の情報として前記利用者端末から取得する選択情報取得部と、
   前記選択情報取得部によって取得された前記選択候補者の情報に基づいて前記購入対象の決済処理を行う決済部と
   を備えることを特徴とする決済管理装置。
2. 前記利用者と他者との関係性を示す関係情報を取得する関係情報取得部を備え、
   前記支払候補者選択部は、
   前記関係情報取得部によって取得された前記関係情報に基づいて、前記複数の支払候補者を選択する
   ことを特徴とする請求項１に記載の決済管理装置。
3. 前記支払候補者選択部は、
   前記関係情報に基づいて推定される支払承認の可能性に応じたランク付けを前記支払候補者毎に行い、当該ランクの情報を前記一覧の情報に含める
   ことを特徴とする請求項２に記載の決済管理装置。
4. 前記選択情報取得部によって前記選択候補者の情報が取得された場合に、前記選択候補者の端末である選択候補者端末に対し、支払承認を要求する支払承認要求を送信する支払承認要求部と、
   前記支払承認要求に対して支払承認を示す情報を前記選択候補者端末から受け付ける支払承認受付部と、を備え、
   前記決済部は、
   前記支払承認受付部によって前記支払承認を示す情報を受け付けた場合に、前記選択候補者の情報に基づいて前記購入対象の決済処理を行う
   ことを特徴とする請求項１〜３のいずれか１つに記載の決済管理装置。
5. 前記支払承認の履歴情報を記憶する履歴情報記憶部を備え、
   前記支払候補者選択部は、
   前記履歴情報記憶部に記憶された前記支払承認の前記履歴情報に基づいて、前記複数の支払候補者を選択する
   ことを特徴とする請求項４に記載の決済管理装置。
6. 前記支払承認を自動的に行う条件を支払承認ポリシーとして前記支払候補者に対応して記憶する支払承認ポリシー記憶部を備え、
   前記支払承認要求部は、
   前記購入要求の内容が前記支払承認ポリシーを満たす場合には、前記選択候補者端末に対して前記支払承認要求の送信を行わず、
   前記決済部は、
   前記購入要求の内容が前記支払承認ポリシーを満たす場合に、前記選択候補者を支払者として前記購入対象の決済処理を行う
   ことを特徴とする請求項４または５に記載の決済管理装置。
7. 前記支払承認ポリシーの情報は、
   前記利用者、前記購入対象の種類および内容、前記購入対象の対価の上限額、前記購入対象を購入する時期、前記購入が行われる店舗および当該店舗の種類、および、前記支払承認を行う期間のうち少なくとも１以上の情報を含む
   ことを特徴とする請求項６に記載の決済管理装置。
8. 前記支払候補者選択部は、
   前記購入要求の内容が前記支払承認ポリシーを満たしている場合には、当該支払承認ポリシーに対応する前記支払候補者を優先的に選択する
   ことを特徴とする請求項６または７に記載の決済管理装置。
9. 前記購入要求の内容で前記支払承認要求があった場合に、前記支払承認を拒否する条件を支払承認拒否ポリシーとして前記支払候補者に対応して記憶する支払承認拒否ポリシー記憶部を備え、
   前記支払候補者選択部は、
   前記購入要求の内容が前記支払承認拒否ポリシーを満たしている場合には、当該支払承認拒否ポリシーに対応する前記支払候補者を除外する
   ことを特徴とする請求項４〜８のいずれか１つに記載の決済管理装置。
10. 前記利用者端末の正当性を証明する証明情報を記憶する証明情報記憶部を備え、
    前記支払承認要求部は、
    前記選択候補者端末に対し、前記証明情報記憶部に記憶された前記証明情報を前記支払承認要求に含めて送信する
    ことを特徴とする請求項４〜９のいずれか１つに記載の決済管理装置。
11. 前記選択情報取得部は、
    前記支払候補者の一覧の中から選択された複数の前記支払候補者の情報を複数の前記選択候補者の情報として前記利用者端末から取得する
    ことを特徴とする請求項１〜１０のいずれか１つに記載の決済管理装置。
12. 前記選択情報取得部によって取得された前記複数の選択候補者の情報に基づいて、前記複数の選択候補者の端末である選択候補者端末に対してそれぞれ、支払承認を要求する支払承認要求を送信する支払承認要求部と、
    前記支払承認要求に対して支払承認を示す情報を前記選択候補者端末からそれぞれ受け付ける支払承認受付部と、を備え、
    前記決済部は、
    前記支払承認受付部によって前記選択候補者端末から前記支払承認を示す情報を受け付けた場合に、最先に受け付けた前記支払承認を示す情報に対応する前記選択候補者を支払者として前記購入対象の決済処理を行う
    ことを特徴とする請求項１１に記載の決済管理装置。
13. 利用者端末から送信される購入要求を受け付ける購入要求受付工程と、
    前記購入要求受付工程によって受け付けた前記購入要求に対応する購入対象の対価を前記利用者端末の利用者に代って支払う支払者の候補である複数の支払候補者を選択する支払候補者選択工程と、
    前記支払候補者選択工程によって選択された前記支払候補者の一覧の情報を前記利用者端末へ通知する一覧情報通知工程と、
    前記支払候補者の一覧の中から選択された前記支払候補者の情報を選択候補者の情報として前記利用者端末から取得する選択情報取得工程と、
    前記選択情報取得工程によって取得された前記選択候補者の情報に基づいて前記購入対象の決済処理を行う決済工程と
    を含むことを特徴とする決済管理方法。
14. コンピュータに、
    利用者端末から送信される購入要求を受け付ける購入要求受付手順と、
    前記購入要求受付手順によって受け付けた前記購入要求に対応する購入対象の対価を前記利用者端末の利用者に代って支払う支払者の候補である複数の支払候補者を選択する支払候補者選択手順と、
    前記支払候補者選択手順によって選択された前記支払候補者の一覧の情報を前記利用者端末へ通知する一覧情報通知手順と、
    前記支払候補者の一覧の中から選択された前記支払候補者の情報を選択候補者の情報として前記利用者端末から取得する選択情報取得手順と、
    前記選択情報取得手順によって取得された前記選択候補者の情報に基づいて前記購入対象の決済処理を行う決済手順と
    を実行させることを特徴とする決済管理プログラム。

Images