JP2020149648A - アカウント管理装置、アカウント管理方法およびアカウント管理プログラム - Google Patents

Abstract

【課題】アカウントの手続きに関してユーザの利便性を向上させること。【解決手段】本願に係るアカウント管理装置は、受付部と、承認部とを備える。受付部は、所定のサービスにおいて第１ユーザが有するアカウントの手続きの実行要求を受け付ける。承認部は、受付部によって実行要求が受け付けられた場合に、発話情報に基づき推定される第１ユーザと血族関係にある第２ユーザに対して、手続きの承認要求を行う。【選択図】図３

Description

本発明は、アカウント管理装置、アカウント管理方法およびアカウント管理プログラムに関する。

従来、所定のサービスの利用時に作成したユーザのアカウントが失効した場合に、かかるアカウントをリカバリするアカウント管理装置が知られている。例えば、アカウント管理装置には、ユーザの行動履歴に基づいて本人性を検証することで、リカバリを実行する技術がある（例えば、特許文献１参照）。

特許第６３４２０３５号公報

しかしながら、従来の技術では、ユーザにとって利便性の高いリカバリを行う点で改善の余地があった。具体的には、従来技術では、複数の端末装置を所持することを前提とするため、端末装置を１つしか持たないユーザによっては利便性が高いとは言えなかった。

また、ユーザ自身が突然、不慮の事故で死亡した場合、当該ユーザのアカウントの利用を停止するなどのアカウントのクローズ処理を代理で親族が実施する場合、親族であるか否かの真偽判定を実施することは容易ではなく、利便性が高いとは言えなかった。

本願は、上記に鑑みてなされたものであって、アカウントの手続きに関してユーザの利便性を向上させることができるアカウント管理装置、アカウント管理方法およびアカウント管理プログラムを提供することを目的とする。

本願に係るアカウント管理装置は、受付部と、承認部とを備える。前記受付部は、所定のサービスにおいて第１ユーザが有するアカウントの手続きの実行要求を受け付ける。前記承認部は、前記受付部によって前記実行要求が受け付けられた場合に、前記第１ユーザの発話特徴を示す発話情報に基づき推定される前記第１ユーザと血族関係にある第２ユーザに対して、前記手続きの承認要求を行う。

実施形態の一態様によれば、アカウントの手続きに関してユーザの利便性を向上させることができるという効果を奏する。

図１は、実施形態に係るアカウントのリカバリ処理の一例を示す図である。 図２は、実施形態に係る管理システムの構成を示す図である。 図３は、実施形態に係るアカウント管理装置の構成例を示すブロック図である。 図４は、ユーザ情報の一例を示す図である。 図５は、アカウント情報の一例を示す図である。 図６は、血族情報の一例を示す図である。 図７は、承認部の処理内容を示す図である。 図８は、実施形態に係る管理システムが実行する処理の手順を示すフローチャートである。 図９は、実施形態に係るアカウント管理装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

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

まず、図１を用いて、実施形態に係るアカウント管理プログラムにより実現されるアカウントのリカバリ処理の一例について説明する。図１は、実施形態に係るアカウントのリカバリ処理の一例を示す図である。図１では、第１ユーザのアカウント失効時において、第１ユーザと血族関係にある第２ユーザにアカウントのリカバリ承認要求を行うリカバリ処理（アカウントの手続きの一例）を説明する。

なお、アカウントが失効する状態とは、例えば、サービスへのログイン時にパスワード入力を規定回数以上誤った場合等に、該当するアカウントが一時的に利用できなくなる状態である。

図１に示すように、実施形態に係るアカウント管理装置は、まず、第１ユーザおよび第２ユーザから音声入力を受け付ける（Ｓ１）。音声入力は、例えば、ユーザがマイク等の集音装置に発話することで行う。

実施形態に係るアカウント管理装置は、音声入力の解析結果として、ユーザ毎に発話特徴を示す発話情報を生成する（Ｓ２）。発話情報には、例えば、音声入力が抽出されたユーザの音声の特徴を示す情報等が含まれる。具体的には、発話情報には、音響パターンや、音響パターンに基づく身体的特徴（咽喉や口の大きさ等）の情報や、発話スピード、イントネーション等といった生活環境に起因する特徴の情報等が含まれる。なお、アカウント管理装置は、他の解析機関で生成された発話情報を取得してもよい。

つづいて、実施形態に係るアカウント管理装置は、発話情報に基づいて第１ユーザおよび第２ユーザの血族関係を推定し、血族情報を生成する（Ｓ３）。アカウント管理装置は、例えば、発話情報を基にモデル（話者モデル）を生成し、話者モデルに基づいて血族関係を推定する。なお、血族関係の推定処理は、事前に行ってもよく、あるいは、ユーザからのリカバリ要求を受け付けたタイミングで行ってもよい。

ここで、実施形態に係るアカウント管理装置は、アカウントを失効した第１ユーザからアカウントのリカバリを要求するリカバリ要求（実行要求の一例）を受け付けたとする（Ｓ４）。実施形態に係るアカウント管理装置は、リカバリ要求を受け付けると、例えば、話者モデルに基づいて、第１ユーザと血族関係にある第２ユーザを特定する（Ｓ５）。

そして、実施形態に係るアカウント管理装置は、第１ユーザと血族関係にある第２ユーザに対して、第１ユーザが有するアカウントのリカバリの実行を承認する承認要求を行う（Ｓ６）。

そして、実施形態に係るアカウント管理装置は、第２ユーザが承認要求に対してリカバリを承認する旨の応答を受け付けた場合（Ｓ７）、リカバリを実行する（Ｓ８）。

そして、実施形態に係るアカウント管理装置は、リカバリ完了後、第１ユーザに対してリカバリ完了を示すリカバリ通知を行う（Ｓ９）。

このように、実施形態に係るアカウント管理装置は、発話情報に基づいて推定した第１ユーザの血族者に対してリカバリの承認要求を行うことで、リカバリを実行する際に、従来技術のように、複数の端末装置を必要としない。

従って、実施形態に係るアカウント管理方法によれば、ユーザにとって利便性の高いリカバリを行うことができる。また、実施形態に係るアカウント管理方法は、アカウントのリカバリ以外にもクローズ処理等の他の手続きを行う際にも適用できる。すなわち、実施形態に係るアカウント管理方法によれば、アカウントの手続きに関してユーザの利便性を向上させることができる。

また、リカバリの承認要求の対象を血族者とすることで、アカウントを失効した第１ユーザにとって信頼できる第２ユーザに承認要求を送信できるため、第１ユーザのサービスに対する満足度を向上させることができる。

また、発話情報を基に血族関係を推定するため、リカバリの承認要求が血族者以外のユーザに誤送信されることを低減できるため、見ず知らずの第３者にユーザのアカウントが漏れることを低減できる。

次に、図２を用いて、実施形態に係る管理システムのシステム構成について説明する。図２は、実施形態に係る管理システムの構成を示す図である。

図２に示すように、実施形態に係る管理システムＳは、アカウント管理装置１と、複数の端末装置１０−１〜１０−ｎと、複数のサービスサーバ１００−１〜１００−ｍとを備える。これらアカウント管理装置１、複数の端末装置１０−１〜１０−ｎおよび複数のサービスサーバ１００−１〜１００−ｍは、ネットワークＮを介して有線または無線により互いに通信可能に接続される。ネットワークＮは、例えば、ＬＡＮ（Local Area Network）や、インターネットなどのＷＡＮ（Wide Area Network）である。端末装置１０−１〜１０−ｎは、ユーザＵ−１〜Ｕ−ｎによって操作される。

以下においては、端末装置１０−１〜１０−ｎの各々を区別せずに示す場合、端末装置１０と記載する。また、サービスサーバ１００−１〜１００−ｍの各々を区別せずに示す場合、サービスサーバ１００と記載し、ユーザＵ−１〜Ｕ−ｎの各々を区別せずに示す場合、ユーザＵと記載する。

端末装置１０は、ユーザＵの端末装置であり、スマートフォン、タブレット型端末、ＰＤＡ（Personal Digital Assistant）、パーソナルコンピュータなどのスマートデバイス（通信端末）である。端末装置１０は、ブラウザや、各種のアプリケーション等が実行可能である。端末装置１０は、ブラウザやアプリケーションから、サービスサーバ１００にネットワークＮを介してアクセスし、サービスサーバ１００が提供するサービスを利用することができる。また、端末装置１０は、ユーザＵの操作に従って、リカバリ要求や、承認応答等の各種情報をアカウント管理装置１へ送信することができる。

サービスサーバ１００は、所定のサービスを提供するサーバ装置である。サービスサーバ１００が提供するサービスには、例えば、検索サービスや、ショッピングサービス、情報提供サービス（例えばニュースサービスや天気予報サービス）等が含まれる。

なお、複数のサービスサーバ１００−１〜１００−ｍは、１つの事業者によって管理されてもよく、それぞれ異なる複数の事業者によって管理されてもよい。

また、アカウント管理装置１は、複数のサービスサーバ１００−１〜１００−ｍそれぞれが有するアカウントを一元的に管理する１つのサーバ装置であってもよく、複数のサービスサーバ１００それぞれに対応する複数のサーバ装置であってもよい。

次に、図３を用いて、実施形態に係るアカウント管理装置１の構成について説明する。図３は、実施形態に係るアカウント管理装置１の構成例を示すブロック図である。

図３に示すように、アカウント管理装置１は、通信部２と、制御部３と、記憶部４とを備える。

通信部２は、たとえば、ＮＩＣ（Network Interface Card）等によって実現される。通信部２は、ネットワークＮと有線または無線で接続され、ネットワークＮを介して、端末装置１０やサービスサーバ１００との間で情報の送受信を行う。

記憶部４は、たとえば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。図３に示すように、記憶部４は、ユーザ情報ＤＢ４０と、アカウント情報ＤＢ４１と、血族情報ＤＢ４２とを記憶する。

ユーザ情報ＤＢ４０は、ユーザＵの情報であるユーザ情報を含む。図４は、ユーザ情報の一例を示す図である。ユーザ情報は、例えば、アカウント作成時にユーザによって入力される情報である。

図４に示すように、ユーザ情報には、「ユーザＩＤ」、「属性」および「発話情報」といった項目を含む。「ユーザＩＤ」は、ユーザＵを識別する識別情報である。「属性」は、ユーザＵの属性に関する情報であり、例えば、デモグラフィック属性や、サイコグラフィック属性を含む。「発話情報」は、例えば、音声入力が抽出されたユーザの音声の特徴を示す情報等が含まれる。具体的には、発話情報には、音響パターンや、音響パターンに基づく身体的特徴（咽喉や口の大きさ等）の情報や、発話スピード、イントネーション等といった生活環境に起因する特徴の情報等が含まれる。

なお、図４に示すユーザ情報は、一例であって、例えば、後述のリカバリ要求の際に取得するユーザの画像情報を含んでもよい。

アカウント情報ＤＢ４１は、サービスを利用するユーザのアカウントに関するアカウント情報を含む。図５は、アカウント情報の一例を示す図である。図５に示すように、アカウント情報には、「ユーザＩＤ」、「アカウントＩＤ」、「パスワード」、「アカウント状態」および「承認状態」といった項目が含まれる。

「アカウントＩＤ」は、ユーザＵ毎にサービスサーバ１００によって発行される識別情報であり、サービスにログインするためのログインＩＤである。なお、「アカウントＩＤ」は、「ユーザＩＤ」であってもよい。

「パスワード」は、サービスにログインするためのパスワードである。「パスワード」は、ユーザＵによって指定されてもよく、サービスサーバ１００によって指定されてもよい。「アカウント状態」は、アカウントの現在の状態である。「有効」は、利用可能な状態を示し、「失効中」は、一時的に利用不可な状態で、「有効」に復帰可能な状態であることを示し、「停止」は、「有効」に復帰不可能な状態であることを示す。「停止」は、例えば、第２ユーザからリカバリ承認が得られなかった状態や、サービスが一定期間以上利用されていない状態である。

「承認状態」は、第２ユーザによるリカバリの承認に関する状態を示し、「要求有無」および「要求者ＩＤ」を含む。「要求有無」は、第２ユーザに対してリカバリの承認要求が行われたか否かを示す情報である。「要求者ＩＤ」は、リカバリの承認要求を行った第２ユーザの識別情報（ユーザＩＤ）である。

血族情報ＤＢ４２は、ユーザＵ間での血族関係を示す血族情報を含む。図６は、血族情報の一例を示す図である。血族情報は、後述の推定部３１によって推定される血族関係の情報である。図６に示すように、血族情報は、「ユーザＩＤ」、「血族者ＩＤ」および「血族関係」といった項目を含む。「血族者ＩＤ」は、血族者の識別情報（ユーザＩＤ）である。「血族関係」は、血族者との血族関係を示す図である。

制御部３は、コントローラ（controller）であり、たとえば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、アカウント管理装置１内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部３は、たとえば、コントローラであり、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

取得部３０は、各種情報を取得する。例えば、取得部３０は、発話情報を取得する。例えば、取得部３０は、ユーザＵの音声入力に基づく解析結果として、発話情報を抽出してもよい。あるいは、取得部３０は、ユーザＵが他の解析機関に依頼して得た発話情報を取得してもよい。取得部３０は、取得した発話情報を記憶部４のユーザ情報ＤＢ４０に記憶する。

また、取得部３０は、アカウント作成の際にユーザＵが入力したユーザ情報を取得し、ユーザ情報ＤＢ４０に格納する。また、取得部３０は、ユーザＵがリカバリ要求を行う際に、ユーザＵの顔を含む画像情報を取得する。

推定部３１は、取得部３０によって取得された発話情報に基づいてユーザＵ間での血族関係を推定する。例えば、推定部３１は、ユーザ毎の発話情報に基づいてユーザ毎の話者モデルを生成し、かかる話者モデルに基づいて血族関係を推定する。

具体的には、推定部３１は、発話情報を含むユーザ情報を用いた機械学習を実行し、血族関係であるか否かを示す学習モデルである話者モデルを生成する。より具体的には、推定部３１は、ユーザ間の血族関係の正否を目的変数とし、発話情報を含むユーザ情報から抽出される発話特徴の情報を説明変数とする回帰モデルを学習モデルとして求めることができる。

また、例えば、推定部３１は、後述の受付部３３によりリカバリ要求が受け付けられる以前に血族関係を予め推定するとともに、血族関係にあると推定したユーザＵに対して事前認定要求を送信する。そして、推定部３１は、事前認定要求を送信したユーザＵから血族関係を認定することを示す応答があった場合に、血族関係を示す血族情報を記憶部４の血族情報ＤＢ４２に記憶する。

このように、推定部３１は、血族関係を事前に推定しておくことで、処理負荷を分散させることができる。また、血族関係にあるユーザＵに対して事前認定要求を送信して、血族関係を事前に確認させることで、リカバリの承認要求時に第２ユーザＵが戸惑うことを低減することができる。

また、推定部３１は、血族関係を事前に推定する場合に限らず、リカバリ要求があったタイミングで血族関係を推定してもよい。具体的には、推定部３１は、後述の受付部３３によってリカバリ要求が受け付けられた場合に、記憶部４に記憶された発話情報および話者モデルに基づいて血族関係を推定する。

このように、リカバリ要求があった場合にのみ血族関係を推定することで、不要な推定処理を省略できるため、全体の処理量を減らすことができる。

管理部３２は、ユーザＵのアカウントを管理する。具体的には、管理部３２は、ユーザＵがアカウントを作成した際に、アカウントＩＤおよびパスワードを発行する。また、管理部３２は、ユーザＵのログイン状況に応じて記憶部４に記憶されたアカウント情報のアカウント状態を変更する。

例えば、管理部３２は、ログイン時にアカウントＩＤまたはパスワードを規定回数以上誤入力した場合に、アカウント状態を「有効」から「失効中」に変更する。そして、管理部３２は、後述の承認部３４によってアカウントのリカバリが承認された場合には、アカウント状態を「失効中」から「有効」に変更する、すなわちリカバリを実行する。

なお、管理部３２は、アカウント状態が「失効中」である場合において、リカバリが承認されない場合には、「失効中」から「停止」に変更する。あるいは、管理部３２は、アカウント状態が「有効」である場合において、ログインが一定期間以上されてない場合や、アカウントを不正使用した場合には、「有効」から「停止」に変更する。つまり、リカバリの権限を与えることなく、アカウントを利用不可の状態とする。

受付部３３は、所定のサービスにおいて第１ユーザが有するアカウントのリカバリ要求を受け付ける。例えば、受付部３３は、アカウント状態を「有効」から「失効中」となった場合に、第１ユーザＵに対してリカバリを実行するか否かの確認要求を送信し、リカバリを実行する旨の応答をリカバリ要求として受け付ける。

承認部３４は、受付部３３によってリカバリ要求が受け付けられた場合に、第１ユーザと血族関係にある第２ユーザに対して、第１ユーザのリカバリの承認要求を行う。例えば、承認部３４は、記憶部４に記憶された血族情報に基づき血族関係と認定された第２ユーザに対して承認要求を行う。

また、承認部３４は、リカバリ要求を受け付ける毎に、推定部３１が血族関係の推定処理を行う場合、推定部３１から推定された血族関係の第２ユーザに対して承認要求を送信する。

また、承認部３４は、承認要求を送信する第２ユーザの数を、親等数に応じて変更する。親等数は、第１ユーザの世代を基準にした第２ユーザとの世代差である。例えば、両親および子は親等数が「１」で、兄弟、祖父母および孫は親等数が「２」で、叔父および叔母は親等数が「３」である。

そして、承認部３４は、親等数に応じた数の第２ユーザからリカバリを承認する応答があった場合に、管理部３２にリカバリを実行する指示を出す。

なお、承認部３４は、リカバリの承認要求を送信する場合、親等数が小さい（血族関係が近い）第２ユーザを優先する制御を行ってもよい。さらに、承認部３４は、複数の第２ユーザの親等数が同じ場合には、年齢が高い第２ユーザを優先する等のように、承認ポリシーに基づいて承認を制御してもよい。

また、承認部３４は、リカバリの承認要求を行う際、第２ユーザに対して第１ユーザの本人確認を要求する。かかる点について、図７を用いて説明する。

図７は、承認部３４の処理内容を示す図である。図７に示すように、承認部３４は、まず、受付部３３によってリカバリ要求が受け付けられた場合に、第１ユーザの顔を含む画像情報を取得する。

そして、承認部３４は、第１ユーザの画像情報を含む確認要求および承認要求を第２ユーザに対して送信する。図７に示す例では、確認要求には、「この人はあなたの兄である○○さんですか？」といった本人を確認する内容や、血族関係を確認する内容等が含まれる。なお、承認部３４は、図７に示す確認要求に対して、第２ユーザが、確認要求が確かに第１ユーザから送信されていることを確認できる手段を備えてもよい。具体的には、承認部３４は、例えば、確認要求に、第１ユーザの署名が付与されていたり、第１ユーザおよび第２ユーザの両者しか知り得ない秘密の情報が付与されていてもよい。

そして、承認部３４は、第２ユーザによって「はい」が選択された場合、すなわち、第２ユーザから第１ユーザ本人であることや、第１ユーザと血族関係にあることを示す応答があった場合に、リカバリの承認要求を送信する。

一方、承認部３４は、第２ユーザによって「いいえ」が選択された場合、すなわち、第２ユーザから第１ユーザ本人ではないことや、第１ユーザと血族関係にないことを示す応答があった場合に、リカバリの承認要求を送信しない。

このように、承認部３４は、第２ユーザに対して第１ユーザの本人確認や血族確認を行った後に、承認要求を送信することで、血族関係にない第２ユーザに承認要求が誤送信されることや、他人になりすました第１ユーザによる不正なリカバリを防止することができる。

また、承認部３４は、リカバリ要求を受け付けた場合に、画像情報を取得することで、第１ユーザの現在の顔を画像情報として取得できるため、第２ユーザによる本人確認を容易化できる。

なお、リカバリ要求の際に取得する情報は、第１ユーザの画像情報に限らず、第１ユーザの発話を録音した音声情報等といったユーザ情報であってもよい。あるいは、承認部３４は、第１ユーザおよび第２ユーザ間で予め取り決めた情報等の予め登録された登録情報を確認要求として第２ユーザに対して送信してもよい。

また、図７では、承認部３４は、第２ユーザに対して第１ユーザの本人確認および血族確認を含む確認要求を送信したが、本人確認および血族確認の確認要求を分けて送信してもよい。

具体的には、承認部３４は、第１ユーザのユーザ情報を含む本人確認要求を第２ユーザに対して送信する。そして、承認部３４は、第２ユーザから第１ユーザ本人であることを示す応答があった場合に、血族確認要求を第２ユーザに対して送信し、第２ユーザから第１ユーザと血族関係であることを示す応答があった場合に、リカバリの承認要求を送信する。なお、承認部３４は、血族確認要求を本人確認要求よりも先に送信してもよい。また、承認部３４は、本人確認要求および血族確認要求のうち、いずれか一方のみを送信してもよい。

次に、図８を用いて、実施形態に係る管理システムＳが実行する処理の手順について説明する。図８は、実施形態に係る管理システムＳが実行する処理の手順を示すフローチャートである。なお、図８に示す「第１ユーザ」は、第１ユーザが所持する端末装置１０の処理を示し、「第２ユーザ」は、第２ユーザが所持する端末装置１０の処理を示す。

図８に示すように、まず、第１ユーザ（端末装置１０）は、アカウント管理装置１に対してリカバリ要求を送信する（Ｓ１０１）。このとき、第１ユーザは、アカウント管理装置１の指示に従って、顔を撮像した画像情報をリカバリ要求とともに送信する。

つづいて、アカウント管理装置１は、発話情報に基づいて血族関係を推定する（Ｓ１０２）。

つづいて、アカウント管理装置１は、推定の結果、第１ユーザと血族関係にある第２ユーザ（端末装置１０）に対して、第１ユーザと血族関係にあることを確認する血族確認要求を送信する（Ｓ１０３）。このとき、アカウント管理装置１は、第１ユーザの画像情報等といったユーザ情報を血族確認要求とともに送信する。

そして、第２ユーザは、第１ユーザと血族関係である場合には、第１ユーザと血族関係にあることを示す応答（承認応答）を送信する（Ｓ１０４）。

つづいて、アカウント管理装置１は、第２ユーザ（端末装置１０）に対して、第１ユーザ本人であることを確認する本人確認要求を送信する（Ｓ１０５）。

そして、第２ユーザは、第１ユーザ本人である場合には、第１ユーザ本人であることを示す応答（承認応答）を送信する（Ｓ１０６）。なお、血族確認要求（Ｓ１０３）および本人確認要求（Ｓ１０５）は、処理順が入れ替わってもよい。

つづいて、アカウント管理装置１は、第２ユーザに対してリカバリの承認要求を送信する（Ｓ１０７）。

そして、第２ユーザは、第１ユーザのアカウントのリカバリを承認する場合、承認応答を送信する（Ｓ１０８）。

つづいて、アカウント管理装置１は、第１ユーザのアカウントのリカバリを実行し（Ｓ１０９）、第１ユーザに対してリカバリが完了したことを示すリカバリ通知を送信し（Ｓ１１０）、処理を終了する。

また、上述してきた実施形態にかかるアカウント管理装置１は、例えば図９に示すような構成のコンピュータ１０００によって実現される。図９は、実施形態に係るアカウント管理装置１の機能を実現するコンピュータ１０００の一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。

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

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

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

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

例えば、コンピュータ１０００が実施形態にかかるアカウント管理装置１として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部３の機能を実現する。また、ＨＤＤ１４００には、記憶部４内のデータが格納される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを、記録媒体１８００から読み取って実行するが、他の例として、他の装置から、ネットワークＮを介してこれらのプログラムを取得してもよい。

なお、上述した実施形態では、実施形態に係るアカウント管理装置１がアカウントのリカバリを実行する場合について説明したが、例えば、アカウントのクローズ処理であってもよい。

具体的には、実施形態に係るアカウント管理装置１の受付部３３は、アカウントのクローズ処理要求を実行要求として受け付ける。アカウントのクローズ処理要求は、例えば、第１ユーザ自身が死亡した場合に、第３者のユーザや、第２ユーザ等の第１ユーザ以外の他のユーザから受け付ける。なお、第１ユーザの端末装置１０が死亡等により解約される場合に、クローズ処理要求が自動で送信されるように設定されてもよい。

そして、承認部３４は、クローズ処理要求を受け付けた場合に、第１ユーザと血族関係にある第２ユーザに対して、クローズ処理の承認要求を行う。そして、管理部３２は、第２ユーザからクローズ処理を承認する旨の通知を受け付けた場合、クローズ処理を実行する。

このように、遺伝情報を基に血族関係を推定することで、例えば、第１ユーザ自身が突然、不慮の事故で死亡した場合、当該第１ユーザのアカウントのクローズ処理を代理で親族（第２ユーザ）が実施する場合、親族であるか否かの真偽判定に要する労力を低減することができる。

なお、リカバリやクローズ処理以外にも、アカウントの登録情報の変更処理や、アカウントの新規登録、アカウントの削除等の他の手続きであってもよい。

上述してきたように、実施形態に係るアカウント管理装置１は、受付部３３と、承認部３４とを備える。受付部３３は、所定のサービスにおいて第１ユーザが有するアカウントの手続きの実行要求を受け付ける。承認部３４は、受付部３３によって実行要求が受け付けられた場合に、発話情報に基づき推定される第１ユーザと血族関係にある第２ユーザに対して、手続きの承認要求を行う。

これにより、アカウントの手続きに関してユーザＵの利便性を向上させることができる。

また、上述した実施形態に係るアカウント管理装置１において、受付部３３は、アカウントのリカバリ要求を実行要求として受け付ける。承認部３４は、第２ユーザに対して、リカバリの承認要求を行う。

これにより、ユーザＵにとって利便性の高いリカバリを行うことができる。

また、上述した実施形態に係るアカウント管理装置１において、受付部３３は、アカウントのクローズ処理要求を実行要求として受け付ける。承認部３４は、第２ユーザに対して、クローズ処理の承認要求を行う。

これにより、例えば、第１ユーザ自身が突然、不慮の事故で死亡した場合、当該第１ユーザのアカウントのクローズ処理を代理で親族（第２ユーザ）が実施する場合、親族であるか否かの真偽判定に要する労力を低減することができる。

また、上述した実施形態に係るアカウント管理装置１において、承認部３４は、第１ユーザのユーザ情報を含む本人確認要求および承認要求を第２ユーザに対して送信し、第２ユーザから第１ユーザ本人であることを示す応答があった場合に、手続きを実行する。

これにより、第３者が第１ユーザになりすましてリカバリ要求したとしても、第２ユーザが第１ユーザの本人確認を行うことで、誤ってアカウントの手続きが実行されることを防止できる。

また、上述した実施形態に係るアカウント管理装置１において、承認部３４は、第１ユーザのユーザ情報を含む血族確認要求および承認要求を第２ユーザに対して送信し、第２ユーザから第１ユーザと血族関係であることを示す応答があった場合に、手続きを実行する。

これにより、第２ユーザ本人から血族者であることを確認できるため、血族者である第２ユーザに対して手続きの承認要求を確実に送信できる。

また、上述した実施形態に係るアカウント管理装置１において、承認部３４は、第１ユーザの画像情報、音声情報および予め登録された登録情報のうち、少なくとも１つの情報を含むユーザ情報を第２ユーザに対して送信する。

これにより、第２ユーザによる第１ユーザの確認を容易化できる。

また、上述した実施形態に係るアカウント管理装置１において、承認部３４は、受付部３３によって実行要求が受け付けられた場合に、ユーザ情報を取得する。

これにより、最新のユーザ情報を取得できるため、第２ユーザによる第１ユーザの確認を容易化できる。

また、上述した実施形態に係るアカウント管理装置１において、承認部３４は、親等数に応じた数の第２ユーザから手続きを承認する応答があった場合に、手続きを実行する。

これにより、例えば、親等数が高い、すなわち、第１ユーザとの世代差が大きくなり信頼性が低下するほど承認数を多く設定できるため、手続きの承認精度を向上させることができる。

また、上述した実施形態に係るアカウント管理装置１は、推定部３１を備える。推定部３１は、ユーザ毎の発話情報に基づき生成されるユーザ毎の話者モデルに基づいて血族関係を推定する。

これにより、ユーザの血族関係を高精度に推定できるため、血族者である第２ユーザを高精度に特定することができる。

また、上述した実施形態に係るアカウント管理装置１において、推定部３１は、実行要求を受け付ける以前に血族関係を予め推定するとともに、血族関係にあると推定したユーザに対して事前認定要求を送信し、血族関係を認定することを示す応答がユーザからあった場合に、血族関係を示す血族情報を記憶部４に記憶する。承認部３４は、記憶部４に記憶された血族情報に基づき血族関係と認定された第２ユーザに対して承認要求を行う。

これにより、血族関係を推定する推定処理を分散して行うことができるため、アカウント管理装置１の処理負荷を軽減できる。

また、上述した実施形態に係るアカウント管理装置１において、取得部３０は、発話情報を記憶部４に記憶する。推定部３１は、受付部３３によって実行要求が受け付けられた場合に、記憶部４に記憶された発話情報に基づいて血族関係を推定する。

これにより、必要最小限の推定処理を行えばよいため、アカウント管理装置１の全体の処理量が嵩むことを防止できる。

以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。

また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

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

また、上述してきた実施形態に記載した各処理は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

また、上記してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、承認部３４は、承認手段や承認回路に読み替えることができる。

１ アカウント管理装置
２ 通信部
３ 制御部
４ 記憶部
１０ 端末装置
３０ 取得部
３１ 推定部
３２ 管理部
３３ 受付部
３４ 承認部
１００ サービスサーバ
Ｕ ユーザ

Claims (13)

1. 所定のサービスにおいて第１ユーザが有するアカウントの手続きの実行要求を受け付ける受付部と、
   前記受付部によって前記実行要求が受け付けられた場合に、前記第１ユーザの発話特徴を示す発話情報に基づき推定される前記第１ユーザと血族関係にある第２ユーザに対して、前記手続きの承認要求を行う承認部と
   を備えることを特徴とするアカウント管理装置。
2. 前記受付部は、
   前記アカウントのリカバリ要求を前記実行要求として受け付け、
   前記承認部は、
   前記第２ユーザに対して、リカバリの承認要求を行うこと
   を特徴とする請求項１に記載のアカウント管理装置。
3. 前記受付部は、
   前記アカウントのクローズ処理要求を前記実行要求として受け付け、
   前記承認部は、
   前記第２ユーザに対して、クローズ処理の承認要求を行うこと
   を特徴とする請求項１または２に記載のアカウント管理装置。
4. 前記承認部は、
   前記第１ユーザのユーザ情報を含む本人確認要求および前記承認要求を前記第２ユーザに対して送信し、前記第２ユーザから前記第１ユーザ本人であることを示す応答があった場合に、前記手続きを実行すること
   を特徴とする請求項１〜３のいずれか１つに記載のアカウント管理装置。
5. 前記承認部は、
   前記第１ユーザのユーザ情報を含む血族確認要求および前記承認要求を前記第２ユーザに対して送信し、前記第２ユーザから前記第１ユーザと血族関係であることを示す応答があった場合に、前記手続きを実行すること
   を特徴とする請求項１〜４のいずれか１つに記載のアカウント管理装置。
6. 前記承認部は、
   前記第１ユーザの画像情報、音声情報および予め登録された登録情報のうち、少なくとも１つの情報を含む前記ユーザ情報を前記第２ユーザに対して送信すること
   を特徴とする請求項４または５に記載のアカウント管理装置。
7. 前記承認部は、
   前記受付部によって前記実行要求が受け付けられた場合に、前記ユーザ情報を取得すること
   を特徴とする請求項４〜６のいずれか１つに記載のアカウント管理装置。
8. 前記承認部は、
   親等数に応じた数の前記第２ユーザから前記手続きを承認する応答があった場合に、前記手続きを実行すること
   を特徴とする請求項１〜７のいずれか１つに記載のアカウント管理装置。
9. ユーザ毎の前記発話情報に基づき生成されるユーザ毎の話者モデルに基づいて前記血族関係を推定する推定部
   を備えることを特徴とする請求項１〜８のいずれか１つに記載のアカウント管理装置。
10. 前記推定部は、
    前記実行要求を受け付ける以前に前記血族関係を予め推定するとともに、前記血族関係にあると推定したユーザに対して事前認定要求を送信し、前記血族関係を認定することを示す応答が前記ユーザからあった場合に、前記血族関係を示す血族情報を記憶部に記憶し、
    前記承認部は、
    前記記憶部に記憶された前記血族情報に基づき前記血族関係と認定された前記第２ユーザに対して前記承認要求を行うこと
    を特徴とする請求項９に記載のアカウント管理装置。
11. 前記発話情報を取得して記憶部に記憶する取得部を備え、
    前記推定部は、
    前記受付部によって前記実行要求が受け付けられた場合に、前記記憶部に記憶された前記発話情報に基づいて前記血族関係を推定すること
    を特徴とする請求項９に記載のアカウント管理装置。
12. コンピュータが実行するアカウント管理方法であって、
    所定のサービスにおいて第１ユーザが有するアカウントの手続きの実行要求を受け付ける受付工程と、
    前記受付工程によって前記実行要求が受け付けられた場合に、前記第１ユーザの発話特徴を示す発話情報に基づき推定される前記第１ユーザと血族関係にある第２ユーザに対して、前記手続きの承認要求を行う承認工程と
    を含むことを特徴とするアカウント管理方法。
13. 所定のサービスにおいて第１ユーザが有するアカウントの手続きの実行要求を受け付ける受付手順と、
    前記受付手順によって前記実行要求が受け付けられた場合に、前記第１ユーザの発話特徴を示す発話情報に基づき推定される前記第１ユーザと血族関係にある第２ユーザに対して、前記手続きの承認要求を行う承認手順と
    をコンピュータに実行させることを特徴とするアカウント管理プログラム。

Images