JP6657364B1 - 情報処理装置、支払管理方法、プログラム、管理方法、及びユーザ機器 - Google Patents

Abstract

【課題】より利便性の高い非現金決済の仕組みを提供すること。【解決手段】少なくとも１つの支払手段が設定された第１のユーザアカウントと、少なくとも１つの支払手段についての利用権限が与えられうる第２のユーザアカウントとを紐付ける紐付け情報と、利用権限の内容を示す権限情報とが格納される記憶部と、少なくとも１つの支払手段の中から選択された支払手段の利用が第２のユーザアカウントから要求されたとき、紐付け情報に基づいて第１のユーザアカウントと第２のユーザアカウントとの間の関係を確認すると共に、要求された支払手段の利用が利用権限の範囲内であるかを権限情報に基づいて確認し、関係及び利用権限についての確認が取れたとき、要求された支払手段の利用についての処理を実行する取引処理部と、を有する、情報処理装置が提供される。【選択図】図３

Description

本発明は、情報処理装置、支払管理方法、プログラム、管理方法、及びユーザ機器に関する。

近年、電子マネーやクレジットカードを用いた非現金決済が広く利用されるようになってきている。さらに、非現金決済をスマートフォンなどの情報端末で行えるようにするアプリケーション（以下、決済アプリ）が普及してきている。また、電子商取引における非現金決済の場面では、クレジットカードや銀行振込以外に、プリペイドカードも広く利用されている。プリペイド方式では、シリアルナンバーの入力により、プリペイドカードの購入金額に応じたポイントが決済に利用できるようになる。

プリペイド方式と似た仕組みとして電子財布がある。電子財布方式では、インターネット上のお財布機能（電子財布）にチャージした金額に応じて利用可能になるポイントを決済に利用する。プリペイド方式ではプリペイドカード毎のシリアルナンバーを入力する必要があったが、電子財布方式では、ユーザが自ら設定した識別情報（ＩＤ）を利用して電子財布に蓄えたポイントを利用することができる（特許文献１を参照）。電子財布に蓄えたポイントを送金に利用する方法も提案されている（特許文献２を参照）。

上記のように、最近では、非現金決済を利用しやすくするための様々な仕組みが提案され、その一部は実際に広く利用されているが、その利用に制限が課される場面も少なくない。例えば、利用可能な支払手段（電子マネー、クレジットカード、インターネットバンクなど）の種類が制限されている場面に遭遇する場合がある。こうした状況に対し、利用者が保有している支払手段で特定の電子マネーを購入し、その特定の電子マネーを利用してユーザが所望する商品を購入する仕組みが提案されている（特許文献３を参照）。

特開2005-327050号公報 特開2002-197389号公報 特開2008-027155号公報

上記の仕組みはいずれも非現金決済の普及に有益ではある。しかしながら、非現金決済に利用する支払手段を保有すること自体に制限がある人が存在するし、その支払手段を用意するために現金の移動が生じることがある。

例えば、安定した収入のない未成年者は、自らのクレジットカードを保有することが難しい。また、そのような未成年者が親のクレジットカードを使用することはクレジットカードの利用規則に反することがある。インターネットバンクについても同様の課題がある。

未成年者が電子マネーを利用する場合、未成年者は、電子マネーにチャージするための現金を親から貰う必要がある。つまり、結局は、親から子への現金支払が生じている。未成年者がプリペイドカードを自ら購入する場合も同様の現金支払が生じうる。プリペイドカードを親が購入して未成年者に渡す方法もあるが、わざわざプリペイドカードを買って未成年者に手渡すのは親にとって大変面倒である。

上記のような課題は、未成年者に限らず、安定した一定の収入を得ていない成人にも生じうる。こうした人々（以下、未成年者等）が容易に非現金決済を利用できるようにする仕組みがあれば、非現金決済の普及率が更に高まるものと期待される。なお、こうした仕組みを広く普及させるには、親などの監督者が安心して未成年者等に利用させられる仕組みであることが要求されるであろう。さらに、未成年者等ではない人も便利に利用できる仕組みであれば、さらに広く普及するだろう。

上記のような事情に鑑み、本発明の一態様によれば、本発明の目的は、より利便性の高い非現金決済の仕組みを提供することが可能な情報処理装置、支払管理方法、プログラム、管理方法、及びユーザ機器を提供することにある。

なお、「ユーザ」とは、実際の人物を指す意味で用いられる場合もあるし、システムに登録された識別情報（ＩＤなど）で識別されるシステム上の人物を指す意味で用いられる場合もある。後者の場合、複数のユーザが一人の実際の人物に対応することがある。本明細書において「ユーザ」という用語を用いる場合には、主に後者の意味で用いることとし、各ユーザと実際の人物との対応関係については必要に応じて付記する。

本発明の一態様によれば、少なくとも１つの支払手段が設定された第１のユーザアカウントと、少なくとも１つの支払手段についての利用権限が与えられうる第２のユーザアカウントとを紐付ける紐付け情報と、利用権限の内容を示す権限情報とが格納される記憶部と、少なくとも１つの支払手段の中から選択された支払手段の利用が第２のユーザアカウントから要求されたとき、紐付け情報に基づいて第１のユーザアカウントと第２のユーザアカウントとの間の関係を確認すると共に、要求された支払手段の利用が利用権限の範囲内であるかを権限情報に基づいて確認し、関係及び利用権限についての確認が取れたとき、要求された支払手段の利用についての処理を実行する取引処理部と、を有する、情報処理装置が提供される。また、本発明の他の一態様によれば、上記の情報処理装置が有する機能をコンピュータに実現させることが可能なプログラム、及びそのプログラムが格納されたコンピュータにより読み取り可能な記録媒体が提供されうる。

本発明によれば、より利便性の高い非現金決済の仕組みを提供することができる。

本実施形態に係る決済管理システムの構成例を示した模式図である。 本実施形態に係る管理サーバの機能を実現可能な情報処理装置のハードウェア構成例を示したブロック図である。 本実施形態に係る管理サーバが有する機能の一例を示したブロック図である。 本実施形態に係る紐付け情報及び権限情報の一例を示した図表である。 本実施形態に係るユーザ機器が有する機能の一例を示したブロック図である。 本実施形態に係る決済管理システムの構成例を適用することで実現されうるユースケースについて説明するための図表である。 本実施形態に係る決済管理システムにおける親子関係の設定（子アカウントを登録済みの場合）に関する処理の流れを示したシーケンス図である。 本実施形態に係る決済管理システムにおける親子関係の設定（子アカウントが未登録の場合）に関する処理の流れを示したシーケンス図である。 本実施形態に係る決済管理システムにおける子アカウントの履歴参照に関する処理の流れを示したシーケンス図である。 本実施形態に係る決済管理システムにおける支払処理の流れを示したシーケンス図である。 本実施形態に係る子アカウントの登録支援機能及び登録用ＵＩについて説明するための第１の説明図である。 本実施形態に係る子アカウントの登録支援機能及び登録用ＵＩについて説明するための第２の説明図である。 本実施形態に係る子アカウントの登録支援機能及び登録用ＵＩについて説明するための第３の説明図である。 本実施形態の一変形例（孫アカウント利用枠の設定）について説明するための説明図である。

以下に添付図面を参照しながら、本発明の実施形態（以下、本実施形態）について説明する。なお、本明細書及び図面において実質的に同一の機能を有する要素については、同一の符号を付することにより重複説明を省略する場合がある。

＜１．実施形態＞
本実施形態に係る技術は、決済サービスの利用者に与えられるユーザアカウントに親子関係を設定し、親として設定されたユーザアカウント（以下、親アカウント）が保有する支払手段の利用権限を、子として設定されたユーザアカウント（以下、子アカウント）に対して付与する仕組みを提供する。

本明細書において「親」、「子」という表現は、単に上位、下位の区別を表すものであり、戸籍上の親子関係とは無関係であってもよい。「孫」という表現についても同様であり、「親」、「子」、「孫」という表現は、上位から順に「親」、「子」、「孫」の関係にあることを表す。但し、「孫」という表現は、親アカウント及び子アカウントが既に設定され、その子アカウントがさらに下位のユーザアカウント（孫アカウント）を設定する場面で用いる。

「アカウント」という用語は、一般に銀行口座を表す意味で用いられることもあるが、本明細書では、システムがユーザを識別するための識別情報又はその識別情報で特定されるユーザ或いは当該ユーザに関連する付帯的な属性情報を表すために用いる。但し、銀行口座も利用者個人に紐付けられており、同一人物が複数の銀行口座を保有することもあるため、銀行口座もユーザアカウントの１つと考えられうる。その他にも、例えば、クレジットカードの番号、システムやアプリケーションのログインＩＤ、携帯電話番号などは、ユーザアカウントの例と考えられうる。

［１−１．システム］
図１を参照しながら、本実施形態に係る決済管理システムについて説明する。図１は、本実施形態に係る決済管理システムの構成例を示した模式図である。なお、図１に示した決済管理システム５は、本実施形態に係る決済管理システムの一例である。

図１に示すように、決済管理システム５は、管理サーバ１０、及びユーザ機器２１、２２を含む。なお、説明の都合上、図１には２台のユーザ機器（ユーザ機器２１、２２）しか明示されていないが、決済管理システム５に含まれるユーザ機器の台数は３台以上であってもよい。ユーザ機器２１、２２は、ネットワークＮＷを介して管理サーバ１０に接続され、管理サーバ１０と通信することができる。

ユーザ機器２１、２２には、それぞれ決済アプリ２１ａ、２２ａがインストールされる。決済アプリ２１ａ、２２ａは、管理サーバ１０を介して取引（支払、送金、チャージ、口座入金、貸金など）を実行するためのアプリケーションプログラムである。なお、以下では、説明の都合上、取引として、商品や役務の提供に対する代金の支払を例に説明を進めるが、送金、チャージなどの代金支払以外の取引についても同様に本実施形態の技術を適用可能である。

図１の例では、説明の都合上、ユーザ機器２１にインストールされた決済アプリ２１ａのユーザが親アカウント（ＡＣ＃１）を保有し、ユーザ機器２２にインストールされた決済アプリ２２ａのユーザが子アカウント（ＡＣ＃２）を保有している。なお、表記の都合上、本明細書及び図面では、アカウントをＡＣと表記する場合がある。

管理サーバ１０は、親アカウントの支払手段を利用して子アカウントの支払を実行する支払機能を提供する。支払手段としては、例えば、電子マネー、電子財布、銀行口座、クレジットカード、プリペイドカード、クーポン、仮想通貨などがある。また、親アカウントのユーザが、商品の購入時に購入者に対して付与されるポイント（交換価値のあるポイント）を保有している場合、そのポイントを支払手段として利用することも可能である。

なお、管理サーバ１０が電子マネーサービスの提供者、電子財布サービスの提供者、カードサービス（クレジットカード、プリペイドカードなどのサービス）の提供者と異なる者により運用されている場合、管理サーバ１０は、各種サービスの提供者又はその代行者などが管理するシステムにアクセスして支払を実行する機能を提供してもよい。

［１−２．ハードウェア］
ここで、図２を参照しながら、管理サーバ１０のハードウェアについて説明する。図２は、本実施形態に係る管理サーバの機能を実現可能な情報処理装置のハードウェア構成例を示したブロック図である。

管理サーバ１０が有する機能は、例えば、図２に示すハードウェア資源の一部又は全部を用いて実現することが可能である。つまり、管理サーバ１０が有する機能は、コンピュータプログラムを用いて図２に示すハードウェアを制御することにより実現される。

図２に示すように、このハードウェアは、主に、プロセッサ１０ａ、メモリ１０ｂ、表示Ｉ／Ｆ（Interface）１０ｃ、通信Ｉ／Ｆ１０ｄ、及び接続Ｉ／Ｆ１０ｅを有する。

プロセッサ１０ａは、例えば、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）などである。メモリ１０ｂは、例えば、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリなどの記憶装置である。

表示Ｉ／Ｆ１０ｃは、ＬＣＤ（Liquid Crystal Display）、ＥＬＤ（Electro-Luminescence Display）などのディスプレイデバイスを接続するためのインターフェースである。例えば、表示Ｉ／Ｆ１０ｃは、プロセッサ１０ａや表示Ｉ／Ｆ１０ｃに搭載されたＧＰＵ（Graphic Processing Unit）により表示制御を実施する。

通信Ｉ／Ｆ１０ｄは、有線及び／又は無線のネットワークに接続するためのインターフェースである。通信Ｉ／Ｆ１０ｄは、例えば、有線ＬＡＮ（Local Area Network）、無線ＬＡＮ、光通信ネットワーク、携帯電話ネットワークなどに接続されうる。

接続Ｉ／Ｆ１０ｅは、外部デバイスを接続するためのインターフェースである。接続Ｉ／Ｆ１０ｅは、例えば、ＵＳＢ（Universal Serial Bus）ポート、ＩＥＥＥ１３９４ポート、ＳＣＳＩ（Small Computer System Interface）などである。

接続Ｉ／Ｆ１０ｅには、例えば、キーボード、マウス、タッチパネル、タッチパッドなどの入力インターフェースが接続されうる。また、接続Ｉ／Ｆ１０ｅには、可搬性の記録媒体１０ｆが接続されうる。記録媒体１０ｆは、例えば、磁気記録媒体、光ディスク、光磁気ディスク、半導体メモリなどである。

上述したプロセッサ１０ａは、記録媒体１０ｆに格納されたプログラムを読み出してメモリ１０ｂに格納し、メモリ１０ｂから読み出したプログラムに従って管理サーバ１０の動作を制御することができる。なお、管理サーバ１０の動作を制御するプログラムは、メモリ１０ｂに予め格納されていてもよいし、通信Ｉ／Ｆ１０ｄを介してネットワークからダウンロードされてもよい。

なお、ユーザ機器２１、２２の機能も、図２に例示したハードウェアの一部又は全部を利用して実現することが可能である。そのため、ユーザ機器２１、２２のハードウェア構成例については図２を参照することとして詳細な説明を省略する。

［１−３．機能ブロック］
次に、管理サーバ１０及びユーザ機器２１、２２の機能について説明する。

（管理サーバ）
図３を参照しながら、管理サーバ１０の機能について説明する。図３は、本実施形態に係る管理サーバが有する機能の一例を示したブロック図である。

図３に示すように、管理サーバ１０は、記憶部１０１、アカウント設定処理部１０２、及び取引処理部１０３を有する。記憶部１０１の機能は、上述したメモリ１０ｂを用いて実現可能である。アカウント設定処理部１０２及び取引処理部１０３の機能は、主に、上述したプロセッサ１０ａを用いて実現可能である。

記憶部１０１には、紐付け情報１０１ａ及び権限情報１０１ｂが格納される。紐付け情報１０１ａは、親アカウントと子アカウントとを紐付けるための情報である。権限情報１０１ｂは、親アカウントの支払手段を利用して子アカウントが支払を行う際の制限（支払手段の利用権限）に関する情報、親アカウントによる子アカウントの管理権限、及び子アカウントの操作制限に関する情報を含む。

なお、権限情報１０１ｂは、親アカウントの上位に位置するユーザアカウント（祖父母ＡＣ）に付与されている権限に関する情報、及び孫アカウントについて子アカウントに付与される権限に関する情報（変形例として後述）が含まれていてもよい。

図４に示すように、紐付け情報１０１ａ及び権限情報１０１ｂは対応付けて管理される。複数の親子関係が設定されている場合、各親子関係について紐付け情報１０１ａと権限情報１０１ｂとの組（図４の鎖線が一組）が記憶部１０１に格納される。図４は、本実施形態に係る紐付け情報及び権限情報の一例を示した図表である。

図４の例では、紐付け情報１０１ａにおいて、親アカウントとして「ヤマダタロウ（ＡＣ＃１）」が登録され、子アカウントとして「ヤマダユウト（ＡＣ＃２）」が登録されている。なお、親アカウントのユーザと子アカウントのユーザとは戸籍上の親子関係になくてもよいし、親アカウント及び子アカウントが同一人物により登録されたユーザアカウントであってもよい。また、紐付け情報１０１ａには、ユーザの姓名が記載されなくてもよい。

図４に示した権限情報１０１ｂには、親アカウントの支払手段として、支払手段（金額制限）の欄に、電子財布、電子マネー、クレジットカード（クレカ）が登録されている。この欄には、他にも、銀行口座、プリペイドカード、クーポン、仮想通貨などが支払手段として登録されていてもよい。また、登録される支払手段の数はこの例に限定されない。この欄には、各支払手段の利用可否及び利用可能金額に関する情報が記載される。なお、利用約款で利用者が本人に限定されているクレジットカードなどの支払手段は利用不可に設定されるか、或いは、権限情報１０１ｂに登録されない。

図４の例では、電子財布及び電子マネーが利用可（可）に設定され、クレジットカードが利用不可（不可）に設定されている。電子財布の利用可能金額は、１日あたり１０００円、１月あたり６０００円に設定されている。また、電子マネーの利用可能金額は、１日あたり５００円、１月あたり２０００円に設定されている。

なお、利用可能金額の制限方法は上記の例に限定されず、例えば、時間帯の制限（例えば、午前７時から午後１０時までは合計１５００円、それ以外は合計５００円）などを設定してもよい。また、支払手段毎に利用可能な時間帯が設定されてもよい。

図４に示した権限情報１０１ｂのうち取引種別の欄には、親アカウントの支払手段を利用して実行可能な取引種別に関する情報が記載される。図４の例では、支払のみが許可（可）、それ以外の取引（送金、貸金…）は不許可（不可）に設定されている。この場合、子アカウントは、親アカウントの支払手段を利用して実行可能な取引が支払のみに制限される。

図４に示した権限情報１０１ｂのうち支払先の欄には、親アカウントの支払手段を利用して支払うことが可能な支払先に関する情報が記載される。図４の例では、食料品店、雑貨店、書店、交通機関などへの支払が許可（可）されている。なお、支払先の欄には、実店舗、ネットショップ、個人サイトなどの運営形態が設定されてもよいし、食料品店、雑貨店、書店などの商品取り扱い種別が設定されてもよいし、具体的な店舗名（ＸＸＸ書店など）が設定されてもよい。

図４に示した権限情報１０１ｂのうち商品／役務の欄には、親アカウントの支払手段を利用して購入することが可能な商品又は役務に関する情報が記載される。図４の例では、食料品、雑貨、書籍、電車／バス（運輸サービス）などの購入が許可（可）されている。なお、商品／役務の欄には、商品又は役務の種類が設定されてもよいし、具体的な商品名又は役務名が設定されてもよい。

図４に示した権限情報１０１ｂのうち総支払限度額の欄には、親アカウントの支払手段を利用した総支払限度額に関する情報が記載される。なお、上述した支払手段の欄において金額制限に関する情報が記載されているため、総支払限度額の欄が省略されても、その金額制限により支払可能な金額は制限される。但し、各支払手段の金額制限一杯まで利用させたくない場合、総支払限度額を別途制限することで、所望の金額制限を子アカウントに課すことが可能になる。

権限情報１０１ｂには、上述した金額制限（支払手段、総支払限度額の欄）及び用途制限（取引種別、支払先、商品／役務の欄）に関する情報に加え、親アカウントによる子アカウントの管理権限に関する情報が含まれる。管理権限としては、例えば、取引履歴の参照、登録情報の参照、登録情報の追加／削除／変更、子アカウント宛て各種通知の参照、アカウント一時停止、アカウント削除などがある。

取引履歴の参照を許可すると、親アカウントは、子アカウントの取引履歴を参照することが可能になる。登録情報の参照を許可すると、親アカウントは、子アカウントの作成時に登録されたプロフィールなどの登録情報を参照することが可能になる。登録情報の追加／削除／変更を許可すると、親アカウントは、子アカウントの登録情報を編集することが可能になる。子アカウント宛ての各種情報の参照を許可すると、親アカウントは、子アカウントが取引先などから受信した通知などの各種情報を参照することが可能になる。

アカウント一時停止を許可すると、親アカウントは、親アカウントの支払手段を利用した取引だけでなく、子アカウントの使用自体を一時停止することが可能になる。アカウント削除を許可すると、親アカウントは、子アカウントを削除することが可能になる。図４の例では、親アカウントによる子アカウントの管理権限が全て許可（可）されている。

権限情報１０１ｂには、さらに、子アカウントの操作制限に関する情報が含まれる。操作制限としては、例えば、親子関係の解消、登録情報の追加／削除／変更、アカウント一時停止／再開、アカウント削除、孫アカウントの作成などがある。

親子関係の解消を許可すると、子アカウントは、親アカウントとの間の紐付け（親子関係）を解消することが可能になる。登録情報の追加／削除／変更を許可すると、子アカウントは、子アカウントの作成時に登録されたプロフィールなどの登録情報を編集することが可能になる。

アカウント一時停止／再開を許可すると、子アカウントは、その子アカウントを自ら一時停止すること、及び子アカウントを再開することが可能になる。アカウント削除を許可すると、子アカウントは、その子アカウントを自ら削除することが可能になる。孫アカウントの作成を許可すると、子アカウントは、孫アカウント（子アカウントを上位（親の立場）のユーザアカウントとする下位（子の立場）のユーザアカウント）を作成することが可能になる。

上記の権限情報１０１ｂを利用することで、上述した金額制限（支払手段、総支払限度額の欄）だけでなく、用途制限（取引種別、支払先、商品／役務の欄）も可能になる。そのため、子アカウントのユーザが行う消費行動に一定の制限を課すことが可能になり、親アカウントのユーザが安心して支払手段を子アカウントのユーザに提供することができるようになる。これらの利点については、後述するユースケースの説明において述べる。

再び図３を参照する。アカウント設定処理部１０２は、ユーザアカウントの設定処理及び親子関係の設定処理を実行する。取引処理部１０３は、親アカウントの支払手段を利用して子アカウントが行う取引についての処理を実行する。

取引処理部１０３は、関係確認部１０３ａ、金額確認部１０３ｂ、内容確認部１０３ｃ、及び支払実行部１０３ｄを有する。関係確認部１０３ａは、紐付け情報１０１ａを参照して、親子関係を確認する機能を提供する。

金額確認部１０３ｂは、権限情報１０１ｂを参照して、支払金額が上記の金額制限に関する条件を満たすか否かを確認する機能を提供する。内容確認部１０３ｃは、権限情報１０１ｂを参照して、支払要求の内容が、上記の用途制限に関する条件を満たすか否かを確認する機能を提供する。支払実行部１０３ｄは、金額確認部１０３ｂ及び内容確認部１０３ｃで条件を満たすことが確認された場合に、親アカウントの支払手段による支払を実行する機能を提供する。

（ユーザ機器）
次に、図５を参照しながら、ユーザ機器２１、２２の機能について説明する。図５は、本実施形態に係るユーザ機器が有する機能の一例を示したブロック図である。

なお、ユーザ機器２１、２２の機能は一部重複する。そのため、ここでは説明の都合上、ユーザ機器２１の機能について具体的に説明し、その中でユーザ機器２１、２２の差異について述べることで、ユーザ機器２２についての詳細な説明を省略する。

図５に示すように、ユーザ機器２１は、ＵＩ表示部２１１、取引部２１２、及び登録処理部２１３を有する。ＵＩ表示部２１１の機能は、主に、上述したプロセッサ１０ａ及び表示Ｉ／Ｆ１０ｃを用いて実現可能である。取引部２１２及び登録処理部２１３の機能は、主に、上述したプロセッサ１０ａを用いて実現可能である。なお、決済アプリ２１ａは、取引部２１２及び登録処理部２１３の機能を提供する。

ＵＩ表示部２１１は、決済アプリ２１ａのユーザインターフェース（ＵＩ）を表示する。例えば、ＵＩ表示部２１１は、子アカウントの登録画面、親子関係の設定画面、登録済みの支払手段を利用した取引の実行画面などを表示し、パスワード入力欄、項目選択用オブジェクト、ボタンオブジェクトなどのオブジェクトを画面上に表示する。

取引部２１２は、登録済みの支払手段を用いた取引に関する処理を実行する。なお、図１の例ではユーザ機器２１が親アカウントで利用されているため、登録済みの支払手段は、親アカウントが自ら保有する支払手段である。子アカウントで利用されているユーザ機器２２の場合、取引部２１２に対応するユーザ機器２２の機能部は、親アカウントの支払手段を用いた取引に関する処理を実行する。

取引部２１２は、手段確認部２１２ａ、選択受付部２１２ｂ、及び支払要求部２１２ｃを含む。

手段確認部２１２ａは、利用可能な支払手段の情報を管理サーバ１０に問い合わせ、管理サーバ１０から取得した支払手段の情報をＵＩ表示部２１１に表示させる。選択受付部２１２ｂは、ＵＩ表示部２１１により表示された支払手段の中から、取引に利用する支払手段の選択を受け付ける。

支払要求部２１２ｃは、選択された支払手段による支払要求を管理サーバ１０に送信する。支払要求には、選択された支払手段及び支払金額を示す情報が含まれる。また、支払要求には、権限情報１０１ｂに含まれる金額制限及び用途制限の項目に関する情報が含まれていてもよい。例えば、支払要求には、取引種別（支払など）、支払先、商品／役務についての情報が含まれていてもよい。これらの情報は、例えば、購入店舗のＵＲＬや、商品に付与されているタグ情報、購入店舗が提示する２次元バーコードなどのコード、ショッピングサイトが保持する属性情報、商品番号、商品コードなどから取得可能である。

登録処理部２１３は、子アカウントの登録及び親子関係の設定に関する処理を実行する。なお、子アカウントとして利用されるユーザアカウントは、事前に登録されていてもよいし、親アカウントによる操作をトリガーとして新規に登録されてもよい。新規に子アカウントが登録する場合、登録処理部２１３は、子アカウントの登録を支援する機能を提供する。

登録処理部２１３は、入力ＩＦ部２１３ａ、登録要求部２１３ｂ、及び登録支援部２１３ｃを含む。

入力ＩＦ部２１３ａは、ＵＩ表示部２１１を介して、情報入力用のインターフェースを表示させる。登録要求部２１３ｂは、入力ＩＦ部２１３ａを介して入力されたユーザの登録情報を含む登録要求を管理サーバ１０に送信し、ユーザアカウントの登録を要求する。登録支援部２１３ｃは、子アカウントの新規登録を行う際の登録支援機能を提供する。なお、子アカウントで利用されているユーザ機器２２においては、図５に示した機能ブロックのうち、登録支援部２１３ｃの機能が省略される。

［１−４．ユースケース］
ここで、図６を参照しながら、上述した管理サーバ１０及びユーザ機器２１、２２の機能（決済管理システム５の構成例）を利用して実現可能なユースケースについて説明する。図６は、本実施形態に係る決済管理システムの構成例を適用することで実現されうるユースケースについて説明するための図表である。

図６（Ａ）は、１つの親アカウントを１つの子アカウントに紐付ける基本的な構成（構成＃１）を示している。構成＃１は、例えば、（１）子供の小遣い、（２）老親の生活費、（３）自分の小遣い管理などに適用することができる。

（Ａ−１）子供の小遣いに適用する場合、父親（又は母親）が親アカウントを保持し、子供が子アカウントを保持する。これにより、子供は、子アカウントを用いて、親アカウントの支払手段を利用した支払を実行できるようになる。一方、父親（又は母親）は、金額制限及び用途制限の機能を利用して月々の利用可能金額や支払先などを管理できるようになると共に、現在の利用金額や使途などの利用状況を含む取引履歴の情報（以下、履歴情報）を参照することができるようになる。

なお、上述した紐付け情報１０１ａ及び権限情報１０１ｂの組は複数設定することができる。そのため、構成＃１の変形例として、１つの親アカウントを複数の子アカウントのそれぞれに紐付け、複数の子供にそれぞれ子アカウントを保持させることで、子供が１人のケースと同じ仕組みで父親（又は母親）が各子供の小遣いを管理することができる。

構成＃１の更なる変形例として、両親のそれぞれが保持する親アカウントに、各子供の子アカウントを紐付けることも可能である。例えば、父親の親アカウントに登録された支払手段を利用して各子アカウントの支払を行うように設定し、母親の親アカウントでは各子アカウントの履歴情報を参照できるように設定すれば、小遣いの提供を父親が行い、使途の管理を母親が行う管理形態を実現することができる。もちろん、この例に限らず、権限情報１０１ｂの設定を工夫することで、各家庭の状況に合った利用形態が実現できる。

（Ａ−２）老親の生活費に適用する場合、子供（例えば、主計者）が親アカウントを保持し、老親（例えば、被後見人）が子アカウントを保持する。この場合、子供は、例えば、銀行口座やクレジットカードを保有する成人である。この利用形態は、例えば、独居、入院中、介護施設入居などの状況にある老親に対し、生活費を提供すると共に、老親の支払状況や使途を管理する場面などで有用である。さらに、履歴状況を参照することで老親の活動状況を把握することができるため、離れて生活する老親の健康状態を知るのに役立つ。

（Ａ−３）自分の小遣い管理に適用する場合、同一人が登録した２つのユーザアカウントのうち、一方が親アカウントに設定され、他方が子アカウントに設定される。このケースでは、権限情報１０１ｂで限度額を設定しておき、小遣いから支出するときに子アカウントを利用することで、使いすぎを防止したり、生活費と分けて小遣いの利用状況を把握したりすることが可能になる。なお、同一の支払手段を複数のユーザアカウントで使用（複数回登録／共用）することが禁止されている場合にも有効に機能する可能性がある。

図６（Ｂ）は、２つのユーザアカウントに対して親子の立場を入れ替えた２つの親子関係を設定し、履歴情報の相互参照を可能にする構成（構成＃２）を示している。構成＃２は、例えば、世帯の家計管理（夫婦間における支払明細の共有）などに適用できる。この場合、妻を親アカウントとし、夫を子アカウントとする第１の親子関係を設定すると共に、妻を子アカウントとし、夫を親アカウントとする第２の親子関係を設定する。

いずれの親アカウントからも子アカウントの履歴情報を参照できるように設定することで、家計全体の支出状況を管理することが可能になる。これにより、支払明細の実質的な共有が実現され、家計管理の容易化に寄与する。例えば、家計簿の作成が容易になる。

図６（Ｃ）は、複数の親アカウントに１つの子アカウントを紐付け、子アカウントを共用アカウントとして利用する構成（構成＃３）を示している。構成＃３は、例えば、（１）家族が利用する家計アカウント、（２）サークル組織などで利用する会計アカウントなどに適用することができる。

（Ｃ−１）家計アカウントに適用する場合、夫婦のそれぞれが親アカウントを保持すると共に、一つの独立したユーザアカウントに対して子アカウントを設定する。これにより、公共料金や家賃などの家計支出を子アカウントで行うことで、家計支出の一元管理が可能になる。

（Ｃ−２）会計アカウントに適用する場合、各サークルメンバが親アカウントを保持し、一つの独立したユーザアカウントに対して子アカウントを設定する。これにより、会計用に設定した子アカウントの履歴情報を各メンバが参照することができ、サークル活動などに伴う支出の明細をリアルタイムで共有することができるようになる。

上記のユースケースは一例であり、図４に示した紐付け情報１０１ａ及び権限情報１０１ｂの設定により様々なケースに本実施形態の技術を適用することが可能である。

［１−５．処理フロー］
次に、決済管理システム５において実行される処理の流れについて説明する。

以下では、説明の都合上、決済アプリ２１ａ（ユーザ機器２１）による処理を親アカウント（ＡＣ＃１）のプログラムによる処理、決済アプリ２２ｂ（ユーザ機器２２）による処理を子アカウント（ＡＣ＃２）のプログラムによる処理として表現する場合がある。また、明示的に記載した場合を除き、各処理は人による操作ではなく、コンピュータ（ユーザ機器２１、２２）のハードウェア資源を用いて実行される処理である。

（親子関係の設定＃１：子アカウント有り）
図７を参照しながら、親子関係の設定に関する処理の流れについて説明する。図７は、本実施形態に係る決済管理システムにおける親子関係の設定（子アカウントが登録済みの場合）に関する処理の流れを示したシーケンス図である。

親子関係の設定は、既存のユーザアカウントに親子関係を設定する方法（親子関係の設定＃１）と、子アカウントとして利用するユーザアカウントを新規に登録してから親子関係を設定する方法（親子関係の設定＃２）とがありうる。親子関係の設定＃１は、例えば、上述したユースケースの構成＃２などに適しており、親子関係の設定＃２は、上述したユースケースの構成＃１、＃３などに適している。

図７のシーケンスは、親子関係の設定＃１に関する処理の流れを示している。

（Ｓ１０１）親アカウントＡＣ＃１のユーザは、子アカウントとして登録する既存のユーザアカウントを指定する。例えば、既存のユーザアカウントは、ユーザアカウントを管理するためのアカウントＩＤ又はユーザＩＤ、携帯電話番号、メールアドレスなどの識別情報を用いて指定することができる。この指定のために、親アカウントＡＣ＃１のプログラムは、識別情報の入力欄を画面上に表示し、入力欄への情報入力を受け付ける。

（Ｓ１０２）親アカウントＡＣ＃１のユーザは、子アカウントに設定する支払手段、権限、制限内容など、図４に示した権限情報１０１ｂに含まれる少なくとも一部の項目に関する情報を設定する。親アカウントＡＣ＃１のユーザは、例えば、子アカウントに利用させる支払手段の情報、各支払手段の利用可能限度額、総支払限度額、取引種別などの用途制限に関する情報などを設定する。また、親アカウントＡＣ＃１のユーザは、子アカウントの管理権限や子アカウントの操作権限などについて図４の例のように設定してもよい。

上記設定のために、親アカウントＡＣ＃１のプログラムは、各種情報を入力するための入力欄を画面上に表示し、入力欄への情報入力を受け付ける。このとき、親アカウントＡＣ＃１のプログラムは、支払手段の種類や利用可否に関する入力欄に選択肢を表示したり、選択用のチェックボックスやボタンオブジェクトを表示したりしてもよい。例えば、親アカウントＡＣ＃１のプログラムは、図４に示した権限情報１０１ｂの枠及び項目名を画面上に表示し、入力欄及び各種オブジェクトを表示してユーザに入力を促してもよい。

（Ｓ１０３）親アカウントＡＣ＃１のユーザは、子アカウントとして指定したユーザアカウントの情報及び子アカウントに設定する上記制限などの内容を確認し、確認した内容に問題がない場合には決定操作を行う。

上記の確認及び決定操作のために、親アカウントＡＣ＃１のプログラムは、Ｓ１０１で指定されたユーザアカウントに関する情報及びＳ１０２で受け付けた権限などの情報を画面上に表示し、確認を促すメッセージと共に決定操作のためのボタンオブジェクト（ＯＫボタンなど）及び処理をＳ１０１又はＳ１０２へ戻すためのボタンオブジェクト（戻るボタンなど）を表示する。以下では説明の都合上、ボタンオブジェクトについて、ＯＫボタン、戻るボタン、ＮＧボタンなどの呼称を用いて説明を進めるが、本実施形態の技術的範囲はこれらに限定されない。ユーザがＯＫボタンを押下（タップ、クリックなど）した場合、処理はＳ１０４へと進む。

（Ｓ１０４）親アカウントＡＣ＃１のプログラムは、管理サーバ１０に対して親子関係の登録要求を送信し、Ｓ１０１で指定されたユーザアカウントに対する親子関係の設定を要求する。親子関係の登録要求には、Ｓ１０１で指定されたユーザアカウントの識別情報と、Ｓ１０２で受け付けた子アカウントの権限などの情報とが含まれる。

（Ｓ１０５）管理サーバ１０は、親アカウントＡＣ＃１のプログラムにより送信された親子関係の登録要求を受信し、登録要求に基づいて仮登録用の紐付け情報１０１ａ及び権限情報１０１ｂを生成し、記憶部１０１に格納する。Ｓ１０５の処理が完了すると、親子関係が仮登録された状態になる。

（Ｓ１０６）管理サーバ１０は、子アカウントとして仮登録されたユーザアカウント（以下、子アカウントＡＣ＃２）のユーザ又はそのユーザアカウントのプログラムに対して親子関係の承認要求を送信する。親子関係の承認要求には、仮登録された親子関係の承認を促すメッセージと共に、その親子関係及び権限情報１０１ｂの設定内容を示す情報が含まれる。

承認要求の送信方法としては、電子メールによるメール通知、ショートメッセージサービス（ＳＭＳ）によるＳＭＳ通知、決済アプリのＰＵＳＨ機能によるＰＵＳＨ通知、決済アプリの立ち上げ時に表示されるメッセージによる通知などが適用されうる。但し、これらの例に限定されず、任意の通信手段による承認要求の送信が適用されうる。

（Ｓ１０７）子アカウントＡＣ＃２のユーザは、親子関係の承認要求が示す親子関係及び権限情報１０１ｂの設定内容を確認する。この確認のために、子アカウントＡＣ＃２のプログラムは、親子関係の承認要求が示す親子関係及び権限情報１０１ｂの設定内容を画面上に表示すると共に、表示内容の確認を促すメッセージを表示する。なお、子アカウントＡＣ＃２のプログラムは、表示内容の一部を変更できるようにする編集用オブジェクトを併せて表示してもよい。

（Ｓ１０８）子アカウントＡＣ＃２のユーザは、Ｓ１０７で確認した内容に問題がない場合には決定操作（承認）を行う。なお、一部の内容を拒絶できるようにしてもよい。上記の決定操作のために、子アカウントＡＣ＃２のプログラムは、決定操作のためのボタンオブジェクト（ＯＫボタン）及び拒否操作のためのボタンオブジェクト（ＮＧボタン）を表示する。子アカウントＡＣ＃２のユーザがＯＫボタンを押下（タップ、クリックなど）した場合、処理はＳ１０９へと進む。

ＮＧボタンが押下された場合、親子関係の設定処理は終了する。例えば、承認拒否の通知が管理サーバ１０へ送信され、仮登録された紐付け情報１０１ａ及び権限情報１０１ｂが記憶部１０１から削除され、親子関係の登録失敗が親アカウントＡＣ＃１のプログラムに通知される。そして、親アカウントＡＣ＃１のプログラムが親子関係の登録失敗を示すメッセージを画面上に表示し、親子関係の設定に関する一連の処理が終了する。

（Ｓ１０９）子アカウントＡＣ＃２のプログラムは、親子関係の承認通知を管理サーバ１０に送信する。親子関係の承認通知には、仮登録された親子関係及び権限情報１０１ｂの内容で本登録を行うことを承認する旨のメッセージが含まれる。なお、親子関係の承認要求が示す権限などの内容が一部拒絶され、その内容が変更されている場合、変更後の内容が親子関係の承認通知に含まれる。

（Ｓ１１０）管理サーバ１０は、親子関係の承認通知を受信し、仮登録の状態で管理していた紐付け情報１０１ａ及び権限情報１０１ｂの内容を確定済みの内容として管理（有効化）し、親アカウントＡＣ＃１と子アカウントＡＣ＃２との間の親子関係に基づく運用を開始する（親子関係の本登録）。

（Ｓ１１１）管理サーバ１０は、親子関係の登録要求に対する応答として、親子関係の登録完了通知を親アカウントＡＣ＃１のプログラムに送信する。親子関係の登録完了通知には、親子関係の設定が完了した旨のメッセージが含まれる。なお、登録完了通知は、メール通知やＳＭＳ通知などの手段で親アカウントＡＣ＃１のユーザに伝達されてもよい。

（Ｓ１１２）親アカウントＡＣ＃１のプログラムは、登録完了通知の内容（親子関係の登録が完了した旨のメッセージ）を画面上に表示する。Ｓ１１２の処理が完了すると、図７に示した一連の処理は終了する。

（親子関係の設定＃２：子アカウント無し）
次に、図８を参照しながら、親子関係の設定に関する処理の流れについて説明する。図８は、本実施形態に係る決済管理システムにおける親子関係の設定（子アカウントが未登録の場合）に関する処理の流れを示したシーケンス図である。図８のシーケンスは、上述した親子関係の設定＃２に関する処理の流れを示している。

（Ｓ１２１）親アカウントＡＣ＃１のユーザは、新規に登録する子アカウントを生成する。このとき、親アカウントＡＣ＃１のユーザは、新規のユーザアカウント登録に必要な登録情報（プロフィールなど）を設定する。例えば、親アカウントＡＣ＃１のユーザは、登録情報として、利用者の姓名、携帯電話番号、メールアドレス、生年月日、性別、住所、アカウントＩＤ、及び初期パスワードなどを親アカウントＡＣ＃１のプログラムに入力する。

親アカウントＡＣ＃１のプログラムは、設定された登録情報を子アカウントのユーザとなる利用者に伝達する。例えば、親アカウントＡＣ＃１のプログラムは、登録情報に含まれる携帯電話番号を用いたＳＭＳ通知又はメールアドレスを用いたメール通知により登録情報を伝達する。なお、登録情報に含まれる携帯電話番号、メールアドレス、初期パスワードは、第三者による子アカウントの不正利用防止に利用されうるため、これを使用する際は相当の認証処理が必要とされる。

（Ｓ１２２）親アカウントＡＣ＃１のユーザは、子アカウントに設定する属性、権限、制限内容など、図４に示した権限情報１０１ｂに含まれる少なくとも一部の項目に関する情報を設定する。親アカウントＡＣ＃１のユーザは、例えば、子アカウントに利用させる支払手段の情報、各支払手段の利用可能限度額、総支払限度額、取引種別などの用途制限に関する情報などを設定する。また、親アカウントＡＣ＃１のユーザは、子アカウントの管理権限や子アカウントの操作権限などについて図４の例のように設定してもよい。

上記設定のために、親アカウントＡＣ＃１のプログラムは、各種情報を入力するための入力欄を画面上に表示し、入力欄への情報入力を受け付ける。このとき、親アカウントＡＣ＃１のプログラムは、支払手段の種類や利用可否に関する入力欄に選択肢を表示したり、選択用のチェックボックスやボタンオブジェクトを表示したりしてもよい。例えば、親アカウントＡＣ＃１のプログラムは、図４に示した権限情報１０１ｂの枠及び項目名を画面上に表示し、入力欄及び各種オブジェクトを表示してユーザに入力を促してもよい。

（Ｓ１２３）親アカウントＡＣ＃１のユーザは、新規に登録する子アカウントの情報及びその子アカウントに設定する上記制限などの内容を確認し、確認した内容に問題がない場合には決定操作を行う。

上記の確認及び決定操作のために、親アカウントＡＣ＃１のプログラムは、新規に登録する子アカウントの情報及びＳ１２２で受け付けた権限などの情報を画面上に表示し、確認を促すメッセージと共に決定操作のためのボタンオブジェクト（ＯＫボタン）及び処理をＳ１２１又はＳ１２２へ戻すためのボタンオブジェクト（戻るボタン）を表示する。ユーザがＯＫボタンを押下（タップ、クリックなど）した場合、処理はＳ１２４へと進む。

（Ｓ１２４）親アカウントＡＣ＃１のプログラムは、管理サーバ１０に対して子アカウントの登録要求を送信する。子アカウントの登録要求には、子アカウントの新規登録及び親子関係の登録を要求する旨のメッセージと共に、Ｓ１２１で設定された登録情報及びＳ１２２で設定された権限などの情報が含まれる。

（Ｓ１２５）管理サーバ１０は、親アカウントＡＣ＃１のプログラムから登録要求を受信し、その登録要求に含まれる情報に基づいて子アカウントとして利用するユーザアカウントを作成し、ユーザアカウントを管理するためのデータベースに仮登録する。この仮登録は、データベースに情報が登録されているが有効化されていない状態を意味する。

（Ｓ１２６）管理サーバ１０は、新規登録した子アカウント（子アカウントＡＣ＃２）の利用者又はその利用者が利用しているプログラムに対し、子アカウントの仮登録を通知するメッセージ及び子アカウントの本登録（有効化）を承認するように求めるメッセージを含む承認要求を送信する。承認要求には、Ｓ１２１で親アカウントＡＣ＃１のユーザにより設定された子アカウント用の登録情報（プロフィールなど）が含まれる。

子アカウントの承認要求は、例えば、Ｓ１２１で親アカウントＡＣ＃１のユーザが設定した登録情報に含まれるメールアドレスに対して送信されてもよい。この場合、承認要求の内容と共に決済アプリの起動用リンクテキストを電子メールに含めておくことにより、その起動用リンクテキストを操作（タップ、クリックなど）するだけで決済アプリを自動起動することが可能になる。その後は決済アプリを利用して登録処理を行うことができるようになる。

（Ｓ１２７）子アカウントＡＣ＃２のプログラムは、管理サーバ１０から受信した承認要求に含まれる登録情報の内容を画面上に表示すると共に、表示内容の確認と修正、及び不足している情報の追加を促すメッセージを表示する。このとき、子アカウントＡＣ＃２のプログラムは、画面上に追加情報（プロフィールの不足箇所など）の入力欄を表示し、子アカウントＡＣ＃２のユーザによる追加情報の入力を受け付ける。

（Ｓ１２８）子アカウントＡＣ＃２のユーザは、登録情報の内容を確認し、その内容で問題ない場合に決定操作（承認）を行う。この決定操作を受け、子アカウントＡＣ＃２のプログラムは、Ｓ１２７で入力された入力情報、及び登録情報を承認した旨のメッセージを含む登録要求を管理サーバ１０に送信する。

（Ｓ１２９）管理サーバ１０は、仮登録の状態にあった子アカウントＡＣ＃２を有効化して本登録の状態に設定する。また、管理サーバ１０は、親アカウントＡＣ＃１のプログラムにより送信された登録要求が示す権限などの情報に基づいて仮登録用の紐付け情報１０１ａ及び権限情報１０１ｂを生成し、記憶部１０１に格納する。この処理により、親子関係が仮登録された状態になる。

（Ｓ１３０）管理サーバ１０は、子アカウントとして仮登録されたユーザアカウント（以下、子アカウントＡＣ＃２）のユーザ又はそのユーザアカウントのプログラムに対して親子関係の承認要求を送信する。親子関係の承認要求には、仮登録された親子関係の承認を促すメッセージと共に、その親子関係及び権限情報１０１ｂの設定内容を示す情報が含まれる。承認要求は、メール通知、ＳＭＳ通知、ＰＵＳＨ通知、決済アプリの立ち上げ時に表示されるメッセージによる通知などにより伝達されうる。

（Ｓ１３１）子アカウントＡＣ＃２のユーザは、親子関係の承認要求が示す親子関係及び権限情報１０１ｂの設定内容を確認する。この確認のために、子アカウントＡＣ＃２のプログラムは、親子関係の承認要求が示す親子関係及び権限情報１０１ｂの設定内容を画面上に表示すると共に、表示内容の確認を促すメッセージを表示する。なお、子アカウントＡＣ＃２のプログラムは、表示内容の一部を変更できるようにする編集用オブジェクトを併せて表示してもよい。

（Ｓ１３２）子アカウントＡＣ＃２のユーザは、Ｓ１３１で確認した内容に問題がない場合には決定操作（承認）を行う。なお、一部の内容を拒絶できるようにしてもよい。上記の決定操作のために、子アカウントＡＣ＃２のプログラムは、決定操作のためのボタンオブジェクト（ＯＫボタン）及び拒否操作のためのボタンオブジェクト（ＮＧボタン）を表示する。子アカウントＡＣ＃２のユーザがＯＫボタンを押下（タップ、クリックなど）した場合、処理はＳ１３３へと進む。

ＮＧボタンが押下された場合、親子関係の設定処理は終了する。例えば、承認拒否の通知が管理サーバ１０へ送信され、仮登録された紐付け情報１０１ａ及び権限情報１０１ｂが記憶部１０１から削除され、親子関係の登録失敗が親アカウントＡＣ＃１のプログラムに通知される。この場合、新規に登録された子アカウントは一時停止又は削除され、子アカウントの登録要求に対する応答としてエラー通知が送信される。

（Ｓ１３３）子アカウントＡＣ＃２のプログラムは、親子関係の承認通知を管理サーバ１０に送信する。親子関係の承認通知には、仮登録された親子関係及び権限情報１０１ｂの内容で本登録を行うことを承認する旨のメッセージが含まれる。なお、親子関係の承認要求が示す権限などの内容が一部拒絶され、その内容が変更されている場合、変更後の内容が親子関係の承認通知に含まれる。

（Ｓ１３４）管理サーバ１０は、親子関係の承認通知を受信し、仮登録の状態で管理していた紐付け情報１０１ａ及び権限情報１０１ｂの内容を確定済みの内容として管理（有効化）し、親アカウントＡＣ＃１と子アカウントＡＣ＃２との間の親子関係に基づく運用を開始する（親子関係の本登録）。

（Ｓ１３５）管理サーバ１０は、親子関係の登録要求に対する応答として、登録完了通知を親アカウントＡＣ＃１のプログラムに送信する。この登録完了通知には、子アカウントの新規登録及び親子関係の設定が完了した旨のメッセージが含まれる。なお、登録完了通知は、メール通知やＳＭＳ通知などの手段で親アカウントＡＣ＃１のユーザに伝達されてもよい。

（Ｓ１３６）親アカウントＡＣ＃１のプログラムは、登録完了通知の内容（子アカウントの新規登録及び親子関係の登録が完了した旨のメッセージ）を画面上に表示する。Ｓ１３６の処理が完了すると、図８に示した一連の処理は終了する。

（親アカウントによる子アカウントの履歴参照）
次に、図９を参照しながら、親アカウントによる履歴情報の参照に関する処理の流れについて説明する。図９は、本実施形態に係る決済管理システムにおける子アカウントの履歴参照に関する処理の流れを示したシーケンス図である。

（Ｓ２０１）親アカウントＡＣ＃１のユーザは、履歴情報の参照先となる子アカウントを指定する。

上記の指定のために、例えば、親アカウントＡＣ＃１のプログラムは、記憶部１０１に格納されている紐付け情報１０１ａに基づいて本登録されている子アカウントを特定し、特定した子アカウントのリストを画面上に表示する。そして、親アカウントＡＣ＃１のプログラムは、履歴情報の参照先となる子アカウントを指定するように促すメッセージと共に、選択用のボタンオブジェクトや子アカウントの識別情報を入力する入力欄などを表示する。

なお、変形例として、親アカウントＡＣ＃１のユーザが事前に設定した子アカウントの履歴情報が決済アプリ２１ａの画面に自動表示されるようにしてもよい。この場合、上記の指定は省略されうる。また、親アカウントＡＣ＃１のユーザが自分の履歴情報を参照する際に、事前に設定した子アカウントの履歴情報が併せて表示されるようにしてもよい。これらの変形についても本実施形態の技術的範囲に属する。

（Ｓ２０２）親アカウントＡＣ＃１のプログラムは、管理サーバ１０に対して子アカウントの履歴情報を要求する。このとき、親アカウントＡＣ＃１のプログラムは、Ｓ２０１で指定された子アカウントの識別情報を管理サーバ１０に送信し、その識別情報に対応する履歴情報の提供を要求する。なお、上記変形例の場合には、事前に設定された子アカウントの識別情報が管理サーバ１０に送信される。

（Ｓ２０３）管理サーバ１０は、親アカウントＡＣ＃１のプログラムから受け付けた要求が示す子アカウントの識別情報及び記憶部１０１に格納されている紐付け情報１０１ａに基づいて、親アカウントＡＣ＃１と子アカウントとの間の親子関係を確認する。

（Ｓ２０４）Ｓ２０３で親子関係の確認が取れた場合、管理サーバ１０は、その親子関係に対応する権限情報１０１ｂを参照し、親アカウントＡＣ＃１に履歴情報の参照権限があること（図４の例では「取引履歴の参照」が「可」であること）を確認する。

（Ｓ２０５）Ｓ２０４で履歴情報の参照権限があることについて確認が取れた場合、管理サーバ１０は、子アカウントの履歴情報を取得する。なお、子アカウントの履歴情報は、例えば、子アカウントが支払を行う度に記憶部１０１に蓄積される。この場合、管理サーバ１０は、記憶部１０１から履歴情報を取得する。

（Ｓ２０６）管理サーバ１０は、取得した子アカウントの履歴情報を親アカウントＡＣ＃１のプログラムに送信する。

（Ｓ２０７）親アカウントＡＣ＃１のプログラムは、管理サーバ１０から受信した子アカウントの履歴情報を画面上に表示する。Ｓ２０７の処理が完了すると、図９に示した一連の処理は終了する。なお、後述する変形例のように、子アカウントが孫アカウントを作成し、孫アカウントの履歴情報を親アカウントが参照する場合の処理も図９に示したシーケンスと実質的に同じ（子アカウントを孫アカウントに読み替えるだけ）である。

（子アカウントによる支払）
次に、図１０を参照しながら、親アカウントの支払手段を利用して子アカウントが支払を行うために実行される処理の流れについて説明する。図１０は、本実施形態に係る決済管理システムにおける支払処理の流れを示したシーケンス図である。

なお、図１０の例では、親アカウントＡＣ＃１と子アカウントＡＣ＃２との間に親子関係が設定され、図４に例示した紐付け情報１０１ａ及び権限情報１０１ｂが設定されているものとする。また、子アカウントＡＣ＃２が親アカウントＡＣ＃１の支払手段を利用して支払を実行する際の処理シーケンスを例に説明を進める。

（Ｓ３０１）子アカウントＡＣ＃２のユーザは、取引（各種支払、購入、チャージ、送金など）の内容を指定する。ここでは説明の都合上、取引が商品購入による支払である場合を例に説明を進めるが、その他の取引種別の場合についても同様である。

（Ｓ３０２）子アカウントＡＣ＃２のプログラムは、Ｓ３０１で指定された取引に伴う支払先などの情報を取得する。例えば、子アカウントＡＣ＃２のプログラムは、商品を販売する店舗の情報（ＵＲＬ、店舗コード、タグ情報、購入店舗が提示する２次元バーコードなどのコード、ショッピングサイトが保持する属性情報など）や、購入した商品の情報（商品種別やタグ情報、商品番号や商品コードなど）を取得する。

（Ｓ３０３）子アカウントＡＣ＃２のプログラムは、子アカウントＡＣ＃２が利用可能な親アカウントＡＣ＃１の支払手段一覧を管理サーバ１０に要求する。なお、子アカウントＡＣ＃２側（ユーザ機器２２）に親アカウントＡＣ＃１の支払手段を示す情報が保持されている場合、保持されている情報を利用してＳ３０３〜Ｓ３０５の処理を省略する変形が可能である。

（Ｓ３０４、Ｓ３０５）管理サーバ１０は、子アカウントＡＣ＃２から支払手段一覧の要求を受け付けると、記憶部１０１に格納されている権限情報１０１ｂを参照し、子アカウントＡＣ＃２が利用可能な親アカウントＡＣ＃１の支払手段を全て特定する。そして、管理サーバ１０は、特定した全ての支払手段を一覧にして子アカウントＡＣ＃２のプログラムに送信する。

（Ｓ３０６）子アカウントＡＣ＃２のプログラムは、管理サーバ１０から受信した支払手段の一覧を画面上に表示する。なお、既に当月の限度額に達しているなどの理由により子アカウントＡＣ＃２が利用できる支払手段がない場合、子アカウントＡＣ＃２のプログラムには、支払手段がない、又は限度額に達している旨のメッセージが通知される。この場合、子アカウントＡＣ＃２のプログラムは、支払手段がない、又は限度額に達している旨のメッセージを画面上に表示し、支払に関する一連の処理を終了する。

（Ｓ３０７）子アカウントＡＣ＃２のプログラムは、支払手段の一覧を表示するとき、支払手段の一覧から今回利用する支払手段を指定するように促すメッセージを表示する。また、子アカウントＡＣ＃２のプログラムは、支払手段を選択するための選択用のオブジェクトを表示する。なお、利用可能な支払手段が１つの場合、子アカウントＡＣ＃２のプログラムは、その支払手段を自動的に選択してもよい。子アカウントＡＣ＃２のユーザが支払手段を選択すると、処理はＳ３０８へと進む。

（Ｓ３０８）子アカウントＡＣ＃２のユーザは、支払の実行を指示する。この指示のために、子アカウントＡＣ＃２のプログラムは、例えば、実行を指示するための実行ボタンを表示すると共に、暗証番号やパスワードなどの認証情報を入力するための入力欄を表示する。例えば、認証情報が入力され、子アカウントＡＣ＃２のプログラムにより認証の成功が確認された場合、実行ボタンが有効（押下可能な状態）になる。実行ボタンが押下（タップ、クリックなど）されると、処理はＳ３０９へと進む。

（Ｓ３０９）子アカウントＡＣ＃２のプログラムは、管理サーバ１０に対して支払実行要求を送信する。支払実行要求には、例えば、支払の実行を要求する旨のメッセージに加え、支払金額の情報、Ｓ３０１で指定された取引内容の情報、Ｓ３０２で取得された支払先などの情報、及びＳ３０７で選択された支払手段の情報が含まれうる。

（Ｓ３１０）管理サーバ１０は、支払実行要求を受信すると、紐付け情報１０１ａを参照して親アカウントＡＣ＃１と子アカウントＡＣ＃２との親子関係を確認する。

（Ｓ３１１）管理サーバ１０は、Ｓ３１０で確認が取れた親子関係に対応する権限情報１０１ｂを参照して金額制限の確認を実施する。例えば、管理サーバ１０は、権限情報１０１ｂを参照して、支払実行要求が示す支払手段の金額制限と、総支払限度額とを特定する。そして、管理サーバ１０は、支払実行要求が示す支払金額が、特定した金額制限及び総支払限度額の条件を満たすことを確認する。確認が取れた場合、処理はＳ３１２へと進む。

（Ｓ３１２）管理サーバ１０は、支払実行要求に含まれる取引内容や支払先などの情報に基づいて、権限情報１０１ｂによる用途制限で制限されている支払内容に該当しないことを確認する。制限されている支払内容に該当しないことが確認された場合、処理はＳ３１３へと進む。

（Ｓ３１３）管理サーバ１０は、支払実行要求で指定された支払手段による支払処理を実行する。なお、支払手段の種類によっては、この段階で、電子財布の残高、銀行口座の残高、電子マネーの残高、クレジットカードの与信枠などがチェックされる。そして、チェック結果に問題がない場合には、その支払手段による支払処理が実行される。

（Ｓ３１４）管理サーバ１０は、支払処理が完了したとき、支払完了通知を子アカウントＡＣ＃２のプログラム（決済アプリ）に通知する。

（Ｓ３１５）管理サーバ１０は、Ｓ３１４とは異なる通知手段を用いて、支払が完了したことを子アカウントＡＣ＃２の利用者に通知する（支払通知）。この支払通知の手段としては、例えば、メール通知、ＳＭＳ通知、ＰＵＳＨ通知、決済アプリの立ち上げ時に表示されるメッセージによる通知などが利用されうる。Ｓ３１４とは異なる通知手段を利用して支払通知を行うことで、子アカウントＡＣ＃２側で決済アプリが立ち上がっていない場合であっても、直ちに支払が完了したことを利用者に知らせることができる。

（Ｓ３１６）管理サーバ１０は、親アカウントＡＣ＃１の支払手段を利用した支払が完了したことを親アカウントＡＣ＃１の利用者に通知する（支払通知）。この支払通知の手段としては、例えば、メール通知、ＳＭＳ通知、ＰＵＳＨ通知、決済アプリの立ち上げ時に表示されるメッセージによる通知などが利用されうる。Ｓ３１６の処理が完了すると、図１０に示した一連の処理は終了する。

上述した処理シーケンスは一例であり、一部の処理を省略したり、新たな処理を追加する変形が可能である。また、一部の処理について処理順序を入れ替える変形が可能である。こうした変形についても当然に本実施形態の技術的範囲に属する。

［１−６．子アカウントの登録用インターフェース］
ここで、図１１〜図１３を参照しながら、親アカウントが子アカウントの登録を支援する機能（登録支援機能）及び登録用ＵＩ（User Interface）について説明する。ここで説明する登録支援機能は、例えば、図８に示した親子関係の設定＃２に適用される。

図１１は、本実施形態に係る子アカウントの登録支援機能及び登録用ＵＩについて説明するための第１の説明図である。図１２は、本実施形態に係る子アカウントの登録支援機能及び登録用ＵＩについて説明するための第２の説明図である。図１３は、本実施形態に係る子アカウントの登録支援機能及び登録用ＵＩについて説明するための第３の説明図である。

（登録用ＵＲＬを利用する方式）
登録支援機能を利用する場合、図１１に示すように、子アカウントの仮登録（Ｓｔｅｐ．１）が済んだ後で、子アカウントの利用者（以下、登録対象者）が保有するユーザ機器２２に対して、管理サーバ１０から登録用ＵＲＬが通知される（Ｓｔｅｐ．２）。登録用ＵＲＬの通知には、ＳＭＳ通知やメール通知などが利用されうる。

登録用ＵＲＬは、ユーザ機器２２の画面２２ｂに表示される（Ｓｔｅｐ．３）。表示された登録用ＵＲＬを登録対象者がタップすると登録処理が開始される。このとき、ユーザ機器２２は、決済アプリ２２ａがダウンロード済みかを判定し（Ｓｔｅｐ．４）、ダウンロード済みの場合には登録情報の入力画面を表示する（Ｓｔｅｐ．６）。

決済アプリ２２ａがダウンロードされていない場合、ユーザ機器２２は、決済アプリ２２ａを提供するアプリストアへ自動リダイレクトしてダウンロードを開始する（Ｓｔｅｐ．５）。決済アプリ２２ａのダウンロードが完了すると、ユーザ機器２２は、登録情報の入力画面を表示する（Ｓｔｅｐ．６）。

登録情報の入力画面には、親アカウントのユーザ名が登録者として表示され、仮登録の際に親アカウントにより設定された子アカウントのプロフィール名がさらに表示される。プロフィール名は、例えば、Ｓｔｅｐ．３で登録対象者が登録用ＵＲＬをタップしたことをトリガーとしてユーザ機器２２が管理サーバ１０から取得する。また、登録情報の入力画面には、パスワードの入力を促すメッセージと共に、パスワードの入力欄２２ｃが表示される。なお、この場合の認証方法はパスワードに限らず、他の認証方法が適用されてもよい。また、虹彩認証や指紋認証などの生体認証を利用する場合には、その操作を促すメッセージや操作方法の説明などの情報が表示されてもよい。

上記のように、決済アプリ２２ａのダウンロードを自動化することで、ユーザ機器２２の操作が苦手な登録対象者の操作を少なくすることができる。なお、登録情報の入力画面でプロフィール名を変更できるようにしてもよい。パスワードの入力欄２２ｃにパスワードが入力され、ＯＫボタンが押下されると、処理は図１２のＳｔｅｐ．７へと進む。

Ｓｔｅｐ．７では、子アカウントの登録情報を確認するための登録確認画面が表示される。登録確認画面には、仮登録の際に親アカウントにより設定された子アカウントの登録情報が表示される。子アカウントの登録情報は、例えば、登録情報の入力画面でＯＫボタンが押下されたことをトリガーとしてユーザ機器２２が管理サーバ１０から取得する。登録対象者は、登録確認画面で登録情報の変更や追加が可能である。

登録確認画面のＯＫボタンが押下されると、登録確認画面の内容が管理サーバ１０に送信され、その内容で管理サーバ１０により子アカウントが本登録される。表示された登録情報に修正がない場合、登録対象者はＯＫボタンを押下するだけで済み、ユーザ機器２２の操作が苦手でも子アカウントの本登録を容易に完了することができる。本登録が完了すると、処理はＳｔｅｐ．８へと進む。

Ｓｔｅｐ．８では、親子関係の設定画面が表示される。親子関係の設定画面には、仮登録の際に親アカウントにより設定された金額制限及び用途制限、親アカウントによる子アカウントの管理権限、及び子アカウントの操作制限に関する情報（権限情報１０１ｂの内容）が表示される。権限情報１０１ｂの内容は、例えば、登録確認画面でＯＫボタンが押下されたことをトリガーとしてユーザ機器２２が管理サーバ１０から取得する。

親子関係の設定画面で登録対象者がＯＫボタンを押下すると、親子関係の設定画面の内容が管理サーバ１０に送信され、その内容で管理サーバ１０により親子関係が本登録される。表示された権限情報１０１ｂの内容に修正がない場合、登録対象者はＯＫボタンを押下するだけで済み、ユーザ機器２２の操作が苦手でも親子関係の本登録を容易に完了することができる。これにより、子アカウント及び親子関係の登録に関する一連の処理が完了する。

（二次元バーコードの利用）
これまでは仮登録後に登録用ＵＲＬを利用して子アカウントの本登録及び親子関係の本登録を行う仕組みについて説明したが、ここでは、図１３を参照しながら、二次元バーコードを利用して本登録を進められるようにする仕組みについて説明する。なお、ここでは二次元バーコードの一例であるＱＲコード（登録商標）を用いるケースについて説明する。また、決済アプリ２２ａがユーザ機器２２に既にダウンロードされているものとする。

図１３の例では、決済アプリ２２ａの初期画面（Ｓｔｅｐ．５ａ）で仕組みを選択できるようにしている。画面２２ｂのボタン２２ｄは、親アカウントが事前登録したプロフィールを使用して本登録を行う処理（図１１及び図１２を参照）を開始するためのボタンオブジェクトである。また、画面２２ｂのボタン２２ｅは、ＱＲコードを利用して本登録を行う処理を開始するためのボタンオブジェクトである。

ボタン２２ｅが押下されると、ユーザ機器２２は、ＱＲコードの読み取りモードになる。親アカウントのユーザ機器２１は、画面上にＱＲコードを表示する。ＱＲコードには、親アカウントの情報及び仮登録された子アカウントの登録情報（親アカウント情報等２１ｂ）などが含まれる。ユーザ機器２２は、ＱＲコードを読み取って親アカウント情報等２１ｂを取得する。ユーザ機器２２は、取得した親アカウント情報等２１ｂを用いて、図１１のＳｔｅｐ．６へと処理を進める。Ｓｔｅｐ．６以降の処理は、既に説明したＳｔｅｐ．７及びＳｔｅｐ．８の処理と同じである。

上記のようにＱＲコードを利用することで、親アカウントが入力した子アカウントの登録情報を容易に得ることが可能になり登録対象者の操作負担を低減することができる。

＜２．変形例（孫アカウント利用枠の設定）＞
ここで、図１４を参照しながら、孫アカウントについて説明する。図１４は、本実施形態の一変形例（孫アカウント利用枠の設定）について説明するための説明図である。

これまでは主にユーザアカウント間の親子関係について説明してきたが、本実施形態の仕組みは、親−子（２段の階層）、親−子−孫（３段の階層）、親−子−孫−ひ孫（４段の階層）…と、多段の階層に容易に拡張することが可能である。例えば、４段の階層を例にとると、親−子の関係、子−孫の関係、孫−ひ孫の関係は、いずれも図４に示した紐付け情報１０１ａ及び権限情報１０１ｂで規定されうる。そのため、各関係の設定及び運用は既に説明した仕組みを利用して行うことができる。

ここでは、本実施形態の一変形例として、親アカウントが子アカウントに付与した支払手段の利用枠の中に、孫アカウントが利用可能な枠（以下、孫アカウント利用枠）を設定する仕組みについて説明する。孫アカウント利用枠を設定する場合、図１４に示すように権限情報１０１ｂに孫アカウント利用枠の欄が追加される。

図１４の例では、子アカウントが利用可能な支払手段である電子財布及び電子マネーの利用枠（金額制限）に、孫アカウント利用枠が設定されている。この例では、子アカウントが電子財布から１日に１０００円、１月に６０００円を利用することができる。この電子財布については、１月当たり２０００円の孫アカウント利用枠が設定されている。この場合、子アカウントは、１月に２０００円を超えない範囲で、親アカウントの電子財布に蓄えられたポイントを孫アカウントに利用させることができる。

孫アカウント利用枠を利用することで、親アカウントは孫アカウントへの支払手段を提供するだけで、孫アカウントの管理は子アカウントに任せるという運用形態が実現されうる。例えば、祖父や祖母が孫に小遣いを与えるような場面では、このような運用形態が便利なこともある。なお、ひ孫アカウントを設定する場合も同様の方法で、ひ孫アカウント利用枠を設定することができる。

図１４の例では孫アカウント利用枠を設定する方法について説明したが、孫アカウントへの権限付与を子アカウントの裁量とする場合、孫アカウント利用枠を省略してもよい。この場合、権限情報１０１ｂの内容は図４と同じになる。図４に例示した権限情報１０１ｂにおいても孫アカウントの作成に関する項目が含まれており、子アカウントが孫アカウントを作成することについては親アカウントの管理に従うようにすることができる。また、親アカウントから孫アカウントの利用履歴を参照することができるように設定することも可能であるため、親アカウントの目が届く運用形態は実現されうる。

以上、添付図面を参照しながら本発明に係る好適な実施形態について説明したが、本発明はここで開示した構成例に限定されない。当業者であれば、特許請求の範囲に記載された範疇において、各種の変更例又は修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属する。

例えば、上記の説明では、スマートフォンなどのユーザ機器で動作するアプリケーション（決済アプリ）を利用するシステム構成を例示したが、上述した決済アプリの機能は、ブラウザなどを利用するＷｅｂベースのアプリケーションによって実現することもできる。また、管理サーバ１０は、複数のコンピュータを接続して構成される分散処理システムでもよい。また、ユーザ機器は、スマートフォンや携帯電話などの携帯型情報機器に限らず、ＰＣ（Personal Computer）や専用端末などであってもよい。

また、上記の説明では、金額制限に関する条件を現金の単位で表現したが、商品や役務などとの交換価値があるポイントの単位で表現されていてもよい。また、支払手段の例として、電子財布（ウォレット）、銀行口座、電子マネー、クレジットカード、プリペイドカード、クーポン、仮想通貨などを例に多くの説明を行ったが、原理的にはインターネットバンクや仮想通貨などを支払手段として利用することも可能である。また、様々なユースケースを例示して具体的な適用例を示したが、本実施形態に係る技術の適用範囲はこれに限定されないことは言うまでもない。

１０ 管理サーバ
１０１ 記憶部
１０１ａ 紐付け情報
１０１ｂ 権限情報
１０２ アカウント設定処理部
１０３ 取引処理部
１０３ａ 関係確認部
１０３ｂ 金額確認部
１０３ｃ 内容確認部
１０３ｄ 支払実行部
２１、２２ ユーザ機器
２１ａ、２２ａ 決済アプリ
２１１ ＵＩ表示部
２１２ 取引部
２１２ａ 手段確認部
２１２ｂ 選択受付部
２１２ｃ 支払要求部
２１３ 登録処理部
２１３ａ 入力ＩＦ部
２１３ｂ 登録要求部
２１３ｃ 登録支援部

Claims (12)

1. 少なくとも１つの支払手段が設定された第１のユーザアカウントと、前記少なくとも１つの支払手段についての利用権限が与えられうる第２のユーザアカウントとを紐付ける紐付け情報と、前記利用権限の内容を示す権限情報とが格納される記憶部と、
   前記少なくとも１つの支払手段の中から選択された支払手段の利用が前記第２のユーザアカウントから要求されたとき、前記紐付け情報に基づいて前記第１のユーザアカウントと前記第２のユーザアカウントとの間の関係を確認すると共に、要求された前記支払手段の利用が前記利用権限の範囲内であるかを前記権限情報に基づいて確認し、前記関係及び前記利用権限についての確認が取れたとき、要求された前記支払手段の利用についての処理を実行する取引処理部と、
   を有する、情報処理装置。
2. 前記利用権限の内容は、前記少なくとも１つの支払手段のそれぞれについて独立に設定された価額に関する第１の制限を含む、
   請求項１に記載の情報処理装置。
3. 前記利用権限の内容は、前記少なくとも１つの支払手段を利用した支払の用途に関する第２の制限を含む、
   請求項１又は２に記載の情報処理装置。
4. 前記第２の制限は、支払先及び支払の対象物のうち少なくとも１つに関する制限を含む、
   請求項３に記載の情報処理装置。
5. 前記少なくとも１つの支払手段は、電子マネー、クレジットカード、電子財布、プリペイドカード、仮想通貨、銀行口座、クーポン、及び、ポイントのうち少なくとも１つを含む、
   請求項１〜４のいずれか１項に記載の情報処理装置。
6. 前記権限情報は、前記第２のユーザアカウントに設定された他の支払手段についての利用権限が与えられうる第３のユーザアカウントに対して、前記少なくとも１つの支払手段についての利用権限を与えるための利用枠情報を含む、
   請求項１〜５のいずれか１項に記載の情報処理装置。
7. 前記権限情報は、前記第２のユーザアカウントによる支払履歴を前記第１のユーザアカウントが参照できるようにする第１の参照設定と、前記第１のユーザアカウントによる支払履歴を前記第２のユーザアカウントが参照できるようにする第２の参照設定とを含み、
   前記情報処理装置は、前記第１の参照設定及び前記第２の参照設定に基づいて前記第１のユーザアカウントと前記第２のユーザアカウントとによる支払履歴の相互参照を可能にする参照処理部をさらに有する、
   請求項１〜６のいずれか１項に記載の情報処理装置。
8. コンピュータが、
   少なくとも１つの支払手段が設定された第１のユーザアカウントと、前記少なくとも１つの支払手段についての利用権限が与えられうる第２のユーザアカウントとを紐付ける紐付け情報と、前記利用権限の内容を示す権限情報とを取得し、
   前記少なくとも１つの支払手段の中から選択された支払手段の利用が前記第２のユーザアカウントから要求されたとき、前記紐付け情報に基づいて前記第１のユーザアカウントと前記第２のユーザアカウントとの間の関係を確認すると共に、要求された前記支払手段の利用が前記利用権限の範囲内であるかを前記権限情報に基づいて確認し、前記関係及び前記利用権限についての確認が取れたとき、要求された前記支払手段の利用についての処理を実行する
   処理を実行する、支払管理方法。
9. 少なくとも１つの支払手段が設定された第１のユーザアカウントと、前記少なくとも１つの支払手段についての利用権限が与えられうる第２のユーザアカウントとを紐付ける紐付け情報と、前記利用権限の内容を示す権限情報とを取得し、
   前記少なくとも１つの支払手段の中から選択された支払手段の利用が前記第２のユーザアカウントから要求されたとき、前記紐付け情報に基づいて前記第１のユーザアカウントと前記第２のユーザアカウントとの間の関係を確認すると共に、要求された前記支払手段の利用が前記利用権限の範囲内であるかを前記権限情報に基づいて確認し、前記関係及び前記利用権限についての確認が取れたとき、要求された前記支払手段の利用についての処理を実行する
   処理をコンピュータに実行させる、プログラム。
10. 少なくとも１つの支払手段が設定された第１のユーザアカウントと、前記少なくとも１つの支払手段についての利用権限が与えられうる第２のユーザアカウントとを紐付ける紐付け情報と、前記利用権限の内容を示す権限情報とが格納される記憶部と、
    前記少なくとも１つの支払手段の中から選択された支払手段の利用が前記第２のユーザアカウントから要求されたとき、前記紐付け情報に基づいて前記第１のユーザアカウントと前記第２のユーザアカウントとの間の関係を確認すると共に、要求された前記支払手段の利用が前記利用権限の範囲内であるかを前記権限情報に基づいて確認し、前記関係及び前記利用権限についての確認が取れたとき、要求された前記支払手段の利用についての処理を実行する取引管理部と、
    を有する、管理サーバと；
    前記第２のユーザアカウントのユーザが前記少なくとも１つの支払手段の中から支払手段を選択し、選択された前記支払手段の利用を指示するための入力部と、
    選択された前記支払手段の利用を前記管理サーバに要求する要求部と、
    を有する、ユーザ機器と；
    を含む、管理システム。
11. 少なくとも１つの支払手段が設定された第１のユーザアカウントと、前記少なくとも１つの支払手段についての利用権限が与えられうる第２のユーザアカウントとを紐付ける紐付け情報と、前記利用権限の内容を示す権限情報とを保持し、前記少なくとも１つの支払手段の中から選択された支払手段の利用が前記第２のユーザアカウントから要求されたとき、前記紐付け情報に基づいて前記第１のユーザアカウントと前記第２のユーザアカウントとの間の関係を確認すると共に、要求された前記支払手段の利用が前記利用権限の範囲内であるかを前記権限情報に基づいて確認し、前記関係及び前記利用権限についての確認が取れたとき、要求された前記支払手段の利用についての処理を実行する、管理サーバに対し、
    前記第２のユーザアカウントのユーザが前記少なくとも１つの支払手段の中から選択した支払手段の情報と、選択された前記支払手段の利用を要求する情報とを送信する、
    ユーザ機器。
12. 少なくとも１つの支払手段が設定された第１のユーザアカウントと、前記少なくとも１つの支払手段についての利用権限が与えられうる第２のユーザアカウントとを紐付ける紐付け情報と、前記利用権限の内容を示す権限情報とを保持し、前記少なくとも１つの支払手段の中から選択された支払手段の利用が前記第２のユーザアカウントから要求されたとき、前記紐付け情報に基づいて前記第１のユーザアカウントと前記第２のユーザアカウントとの間の関係を確認すると共に、要求された前記支払手段の利用が前記利用権限の範囲内であるかを前記権限情報に基づいて確認し、前記関係及び前記利用権限についての確認が取れたとき、要求された前記支払手段の利用についての処理を実行する、管理サーバに対し、
    前記第２のユーザアカウントのユーザが前記少なくとも１つの支払手段の中から選択した支払手段の情報と、選択された前記支払手段の利用を要求する情報とを送信する、
    処理をコンピュータに実行させる、プログラム。

Images