特許第6979979号(P6979979)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ヤフー株式会社の特許一覧

特許6979979アカウント管理装置、アカウント管理方法およびアカウント管理プログラム
<>
  • 特許6979979-アカウント管理装置、アカウント管理方法およびアカウント管理プログラム 図000002
  • 特許6979979-アカウント管理装置、アカウント管理方法およびアカウント管理プログラム 図000003
  • 特許6979979-アカウント管理装置、アカウント管理方法およびアカウント管理プログラム 図000004
  • 特許6979979-アカウント管理装置、アカウント管理方法およびアカウント管理プログラム 図000005
  • 特許6979979-アカウント管理装置、アカウント管理方法およびアカウント管理プログラム 図000006
  • 特許6979979-アカウント管理装置、アカウント管理方法およびアカウント管理プログラム 図000007
  • 特許6979979-アカウント管理装置、アカウント管理方法およびアカウント管理プログラム 図000008
  • 特許6979979-アカウント管理装置、アカウント管理方法およびアカウント管理プログラム 図000009
  • 特許6979979-アカウント管理装置、アカウント管理方法およびアカウント管理プログラム 図000010
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6979979
(24)【登録日】2021年11月18日
(45)【発行日】2021年12月15日
(54)【発明の名称】アカウント管理装置、アカウント管理方法およびアカウント管理プログラム
(51)【国際特許分類】
   G06F 21/32 20130101AFI20211202BHJP
   G06Q 50/26 20120101ALI20211202BHJP
【FI】
   G06F21/32
   G06Q50/26 300
【請求項の数】13
【全頁数】17
(21)【出願番号】特願2019-49198(P2019-49198)
(22)【出願日】2019年3月15日
(65)【公開番号】特開2020-149647(P2020-149647A)
(43)【公開日】2020年9月17日
【審査請求日】2020年12月16日
(73)【特許権者】
【識別番号】319013263
【氏名又は名称】ヤフー株式会社
(74)【代理人】
【識別番号】110002147
【氏名又は名称】特許業務法人酒井国際特許事務所
(72)【発明者】
【氏名】五味 秀仁
(72)【発明者】
【氏名】井上 昌洋
(72)【発明者】
【氏名】國友 康恵
(72)【発明者】
【氏名】田平 章人
(72)【発明者】
【氏名】有地 正太
(72)【発明者】
【氏名】安藤 文紀
【審査官】 宮司 卓佳
(56)【参考文献】
【文献】 米国特許出願公開第2011/0107400(US,A1)
【文献】 特開2005−031884(JP,A)
【文献】 特開2015−215843(JP,A)
【文献】 国際公開第2017/146229(WO,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 21/32
G06Q 50/26
(57)【特許請求の範囲】
【請求項1】
所定のサービスにおいて第1ユーザが有するアカウントの手続きの実行要求を受け付ける受付部と、
前記受付部によって前記実行要求が受け付けられた場合に、遺伝情報に基づき推定される前記第1ユーザと血族関係にある第2ユーザに対して、前記手続きの承認要求を行う承認部と
を備えることを特徴とするアカウント管理装置。
【請求項2】
前記受付部は、
前記アカウントのリカバリ要求を前記実行要求として受け付け、
前記承認部は、
前記第2ユーザに対して、リカバリの承認要求を行うこと
を特徴とする請求項1に記載のアカウント管理装置。
【請求項3】
前記受付部は、
前記アカウントのクローズ処理要求を前記実行要求として受け付け、
前記承認部は、
前記第2ユーザに対して、クローズ処理の承認要求を行うこと
を特徴とする請求項1または2に記載のアカウント管理装置。
【請求項4】
前記承認部は、
前記第1ユーザのユーザ情報を含む本人確認要求および前記承認要求を前記第2ユーザに対して送信し、前記第2ユーザから前記第1ユーザ本人であることを示す応答があった場合に、前記手続きを実行すること
を特徴とする請求項1〜3のいずれか1つに記載のアカウント管理装置。
【請求項5】
前記承認部は、
前記第1ユーザのユーザ情報を含む血族確認要求および前記承認要求を前記第2ユーザに対して送信し、前記第2ユーザから前記第1ユーザと血族関係であることを示す応答があった場合に、前記手続きを実行すること
を特徴とする請求項1〜4のいずれか1つに記載のアカウント管理装置。
【請求項6】
前記承認部は、
前記第1ユーザの画像情報、音声情報および予め登録された登録情報のうち、少なくとも1つの情報を含む前記ユーザ情報を前記第2ユーザに対して送信すること
を特徴とする請求項4または5に記載のアカウント管理装置。
【請求項7】
前記承認部は、
前記受付部によって前記実行要求が受け付けられた場合に、前記ユーザ情報を取得すること
を特徴とする請求項4〜6のいずれか1つに記載のアカウント管理装置。
【請求項8】
前記承認部は、
親等数に応じた数の前記第2ユーザから前記手続きを承認する応答があった場合に、前記手続きを実行すること
を特徴とする請求項1〜7のいずれか1つに記載のアカウント管理装置。
【請求項9】
ユーザ毎の前記遺伝情報を取得する取得部と、
前記取得部によって取得された前記遺伝情報に基づいて前記血族関係を推定する推定部と
を備えることを特徴とする請求項1〜8のいずれか1つに記載のアカウント管理装置。
【請求項10】
前記推定部は、
前記実行要求を受け付ける以前に前記血族関係を予め推定するとともに、前記血族関係にあると推定したユーザに対して事前認定要求を送信し、前記血族関係を認定することを示す応答が前記ユーザからあった場合に、前記血族関係を示す血族情報を記憶部に記憶し、
前記承認部は、
前記記憶部に記憶された前記血族情報に基づき前記血族関係と認定された前記第2ユーザに対して前記承認要求を行うこと
を特徴とする請求項9に記載のアカウント管理装置。
【請求項11】
前記取得部は、
前記遺伝情報を記憶部に記憶し、
前記推定部は、
前記受付部によって前記実行要求が受け付けられた場合に、前記記憶部に記憶された前記遺伝情報に基づいて前記血族関係を推定すること
を特徴とする請求項9に記載のアカウント管理装置。
【請求項12】
コンピュータが実行するアカウント管理方法であって、
所定のサービスにおいて第1ユーザが有するアカウントの手続きの実行要求を受け付ける受付工程と、
前記受付工程によって前記実行要求が受け付けられた場合に、遺伝情報に基づき推定される前記第1ユーザと血族関係にある第2ユーザに対して、前記手続きの承認要求を行う承認工程と
を含むことを特徴とするアカウント管理方法。
【請求項13】
所定のサービスにおいて第1ユーザが有するアカウントの手続きの実行要求を受け付ける受付手順と、
前記受付手順によって前記実行要求が受け付けられた場合に、遺伝情報に基づき推定される前記第1ユーザと血族関係にある第2ユーザに対して、前記手続きの承認要求を行う承認手順と
をコンピュータに実行させることを特徴とするアカウント管理プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、アカウント管理装置、アカウント管理方法およびアカウント管理プログラムに関する。
【背景技術】
【0002】
従来、所定のサービスの利用時に作成したユーザのアカウントが失効した場合に、かかるアカウントをリカバリするアカウント管理装置が知られている。例えば、アカウント管理装置には、ユーザの行動履歴に基づいて本人性を検証することで、リカバリを実行する技術がある(例えば、特許文献1参照)。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特許第6342035号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、従来の技術では、ユーザにとって利便性の高いリカバリを行う点で改善の余地があった。具体的には、従来技術では、複数の端末装置を所持することを前提とするため、端末装置を1つしか持たないユーザによっては利便性が高いとは言えなかった。
【0005】
また、ユーザ自身が突然、不慮の事故で死亡した場合、当該ユーザのアカウントの利用を停止するなどのアカウントのクローズ処理を代理で親族が実施する場合、親族であるか否かの真偽判定を実施することは容易ではなく、利便性が高いとは言えなかった。
【0006】
本願は、上記に鑑みてなされたものであって、アカウントの手続きに関してユーザの利便性を向上させることができるアカウント管理装置、アカウント管理方法およびアカウント管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【0007】
本願に係るアカウント管理装置は、受付部と、承認部とを備える。前記受付部は、所定のサービスにおいて第1ユーザが有するアカウントの手続きの実行要求を受け付ける。前記承認部は、前記受付部によって前記実行要求が受け付けられた場合に、遺伝情報に基づき推定される前記第1ユーザと血族関係にある第2ユーザに対して、前記手続きの承認要求を行う。
【発明の効果】
【0008】
実施形態の一態様によれば、アカウントの手続きに関してユーザの利便性を向上させることができるという効果を奏する。
【図面の簡単な説明】
【0009】
図1図1は、実施形態に係るアカウントのリカバリ処理の一例を示す図である。
図2図2は、実施形態に係る管理システムの構成を示す図である。
図3図3は、実施形態に係るアカウント管理装置の構成例を示すブロック図である。
図4図4は、ユーザ情報の一例を示す図である。
図5図5は、アカウント情報の一例を示す図である。
図6図6は、血族情報の一例を示す図である。
図7図7は、承認部の処理内容を示す図である。
図8図8は、実施形態に係る管理システムが実行する処理の手順を示すフローチャートである。
図9図9は、実施形態に係るアカウント管理装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。
【発明を実施するための形態】
【0010】
以下に、本願に係るアカウント管理装置、アカウント管理方法およびアカウント管理プログラムを実施するための形態(以下、「実施形態」と記載する)について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係るアカウント管理装置、アカウント管理方法およびアカウント管理プログラムが限定されるものではない。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。
【0011】
まず、図1を用いて、実施形態に係るアカウント管理プログラムにより実現されるアカウントのリカバリ処理の一例について説明する。図1は、実施形態に係るアカウントのリカバリ処理の一例を示す図である。図1では、第1ユーザのアカウント失効時において、第1ユーザと血族関係にある第2ユーザにアカウントのリカバリ承認要求を行うリカバリ処理(アカウントの手続きの一例)を説明する。
【0012】
なお、アカウントが失効する状態とは、例えば、サービスへのログイン時にパスワード入力を規定回数以上誤った場合等に、該当するアカウントが一時的に利用できなくなる状態である。
【0013】
図1に示すように、実施形態に係るアカウント管理装置は、まず、第1ユーザおよび第2ユーザから遺伝子検査依頼を受け付ける(S1)。遺伝子検査は、例えば、ユーザから唾液、皮膚の一部、毛髪等を採取し、専用の検査端末により行う。
【0014】
実施形態に係るアカウント管理装置は、遺伝子検査の解析結果として、ユーザ毎に遺伝情報を生成する(S2)。遺伝情報には、例えば、ユーザの健康リスクに関する情報や、ユーザの体質に関する情報等が含まれる。なお、遺伝情報には、例えば、ユーザの塩基配列やアミノ酸配列等の遺伝暗号に関する情報が含まれてもよい。なお、アカウント管理装置は、他の検査機関で生成された遺伝情報を取得してもよい。
【0015】
つづいて、実施形態に係るアカウント管理装置は、遺伝情報に基づいて第1ユーザおよび第2ユーザの血族関係を推定し、血族情報を生成する(S3)。なお、血族関係の推定処理は、事前に行ってもよく、あるいは、ユーザからのリカバリ要求を受け付けたタイミングで行ってもよい。
【0016】
ここで、実施形態に係るアカウント管理装置は、アカウントを失効した第1ユーザからアカウントのリカバリを要求するリカバリ要求(実行要求の一例)を受け付けたとする(S4)。実施形態に係るアカウント管理装置は、リカバリ要求を受け付けると、血族情報に基づいて、第1ユーザと血族関係にある第2ユーザを特定する(S5)。
【0017】
そして、実施形態に係るアカウント管理装置は、第1ユーザと血族関係にある第2ユーザに対して、第1ユーザが有するアカウントのリカバリの実行を承認する承認要求を行う(S6)。
【0018】
そして、実施形態に係るアカウント管理装置は、第2ユーザが承認要求に対してリカバリを承認する旨の応答を受け付けた場合(S7)、リカバリを実行する(S8)。
【0019】
そして、実施形態に係るアカウント管理装置は、リカバリ完了後、第1ユーザに対してリカバリ完了を示すリカバリ通知を行う(S9)。
【0020】
このように、実施形態に係るアカウント管理装置は、遺伝情報に基づいて推定した第1ユーザの血族者に対してリカバリの承認要求を行うことで、リカバリを実行する際に、従来技術のように、複数の端末装置を必要としない。
【0021】
従って、実施形態に係るアカウント管理方法によれば、ユーザにとって利便性の高いリカバリを行うことができる。また、実施形態に係るアカウント管理方法は、アカウントのリカバリ以外にもクローズ処理等の他の手続きを行う際にも適用できる。すなわち、実施形態に係るアカウント管理方法によれば、アカウントの手続きに関してユーザの利便性を向上させることができる。
【0022】
また、リカバリの承認要求の対象を血族者とすることで、アカウントを失効した第1ユーザにとって信頼できる第2ユーザに承認要求を送信できるため、第1ユーザのサービスに対する満足度を向上させることができる。
【0023】
また、遺伝情報を基に血族関係を推定するため、リカバリの承認要求が血族者以外のユーザに誤送信されることを低減できるため、見ず知らずの第3者にユーザのアカウントが漏れることを低減できる。
【0024】
次に、図2を用いて、実施形態に係る管理システムのシステム構成について説明する。図2は、実施形態に係る管理システムの構成を示す図である。
【0025】
図2に示すように、実施形態に係る管理システムSは、アカウント管理装置1と、複数の端末装置10−1〜10−nと、複数のサービスサーバ100−1〜100−mとを備える。これらアカウント管理装置1、複数の端末装置10−1〜10−nおよび複数のサービスサーバ100−1〜100−mは、ネットワークNを介して有線または無線により互いに通信可能に接続される。ネットワークNは、例えば、LAN(Local Area Network)や、インターネットなどのWAN(Wide Area Network)である。端末装置10−1〜10−nは、ユーザU−1〜U−nによって操作される。
【0026】
以下においては、端末装置10−1〜10−nの各々を区別せずに示す場合、端末装置10と記載する。また、サービスサーバ100−1〜100−mの各々を区別せずに示す場合、サービスサーバ100と記載し、ユーザU−1〜U−nの各々を区別せずに示す場合、ユーザUと記載する。
【0027】
端末装置10は、ユーザUの端末装置であり、スマートフォン、タブレット型端末、PDA(Personal Digital Assistant)、パーソナルコンピュータなどのスマートデバイス(通信端末)である。端末装置10は、ブラウザや、各種のアプリケーション等が実行可能である。端末装置10は、ブラウザやアプリケーションから、サービスサーバ100にネットワークNを介してアクセスし、サービスサーバ100が提供するサービスを利用することができる。また、端末装置10は、ユーザUの操作に従って、リカバリ要求や、承認応答等の各種情報をアカウント管理装置1へ送信することができる。
【0028】
サービスサーバ100は、所定のサービスを提供するサーバ装置である。サービスサーバ100が提供するサービスには、例えば、検索サービスや、ショッピングサービス、情報提供サービス(例えばニュースサービスや天気予報サービス)等が含まれる。
【0029】
なお、複数のサービスサーバ100−1〜100−mは、1つの事業者によって管理されてもよく、それぞれ異なる複数の事業者によって管理されてもよい。
【0030】
また、アカウント管理装置1は、複数のサービスサーバ100−1〜100−mそれぞれが有するアカウントを一元的に管理する1つのサーバ装置であってもよく、複数のサービスサーバ100それぞれに対応する複数のサーバ装置であってもよい。
【0031】
次に、図3を用いて、実施形態に係るアカウント管理装置1の構成について説明する。図3は、実施形態に係るアカウント管理装置1の構成例を示すブロック図である。
【0032】
図3に示すように、アカウント管理装置1は、通信部2と、制御部3と、記憶部4とを備える。
【0033】
通信部2は、たとえば、NIC(Network Interface Card)等によって実現される。通信部2は、ネットワークNと有線または無線で接続され、ネットワークNを介して、端末装置10やサービスサーバ100との間で情報の送受信を行う。
【0034】
記憶部4は、たとえば、RAM(Random Access Memory)、フラッシュメモリ(Flash Memory)等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。図3に示すように、記憶部4は、ユーザ情報DB40と、アカウント情報DB41と、血族情報DB42とを記憶する。
【0035】
ユーザ情報DB40は、ユーザUの情報であるユーザ情報を含む。図4は、ユーザ情報の一例を示す図である。ユーザ情報は、例えば、アカウント作成時にユーザによって入力される情報である。
【0036】
図4に示すように、ユーザ情報には、「ユーザID」、「属性」および「遺伝情報」といった項目を含む。「ユーザID」は、ユーザUを識別する識別情報である。「属性」は、ユーザUの属性に関する情報であり、例えば、デモグラフィック属性や、サイコグラフィック属性を含む。「遺伝情報」は、例えば、ユーザUの唾液等を採取して抽出されるユーザUの遺伝子に関する情報であり、例えば、ユーザUの健康リスクに関する情報や、ユーザUの体質に関する情報、ユーザUの塩基配列やアミノ酸配列等の遺伝暗号に関する情報が含まれる。なお、遺伝情報は、他の検査機関で生成された遺伝情報を含んでもよい。
【0037】
なお、図4に示すユーザ情報は、一例であって、例えば、後述のリカバリ要求の際に取得するユーザの画像情報を含んでもよい。
【0038】
アカウント情報DB41は、サービスを利用するユーザのアカウントに関するアカウント情報を含む。図5は、アカウント情報の一例を示す図である。図5に示すように、アカウント情報には、「ユーザID」、「アカウントID」、「パスワード」、「アカウント状態」および「承認状態」といった項目が含まれる。
【0039】
「アカウントID」は、ユーザU毎にサービスサーバ100によって発行される識別情報であり、サービスにログインするためのログインIDである。なお、「アカウントID」は、「ユーザID」であってもよい。
【0040】
「パスワード」は、サービスにログインするためのパスワードである。「パスワード」は、ユーザUによって指定されてもよく、サービスサーバ100によって指定されてもよい。「アカウント状態」は、アカウントの現在の状態である。「有効」は、利用可能な状態を示し、「失効中」は、一時的に利用不可な状態で、「有効」に復帰可能な状態であることを示し、「停止」は、「有効」に復帰不可能な状態であることを示す。「停止」は、例えば、第2ユーザからリカバリ承認が得られなかった状態や、サービスが一定期間以上利用されていない状態である。
【0041】
「承認状態」は、第2ユーザによるリカバリの承認に関する状態を示し、「要求有無」および「要求者ID」を含む。「要求有無」は、第2ユーザに対してリカバリの承認要求が行われたか否かを示す情報である。「要求者ID」は、リカバリの承認要求を行った第2ユーザの識別情報(ユーザID)である。
【0042】
血族情報DB42は、ユーザU間での血族関係を示す血族情報を含む。図6は、血族情報の一例を示す図である。血族情報は、後述の推定部31によって推定される血族関係の情報である。図6に示すように、血族情報は、「ユーザID」、「血族者ID」および「血族関係」といった項目を含む。「血族者ID」は、血族者の識別情報(ユーザID)である。「血族関係」は、血族者との血族関係を示す図である。
【0043】
制御部3は、コントローラ(controller)であり、たとえば、CPU(Central Processing Unit)やMPU(Micro Processing Unit)等によって、アカウント管理装置1内部の記憶装置に記憶されている各種プログラムがRAMを作業領域として実行されることにより実現される。また、制御部3は、たとえば、コントローラであり、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)等の集積回路により実現される。
【0044】
取得部30は、各種情報を取得する。例えば、取得部30は、遺伝情報を取得する。例えば、取得部30は、ユーザUから唾液や、皮膚の一部、毛髪等を採取し、専用の検査装置により遺伝情報を抽出してもよい。あるいは、取得部30は、ユーザUが他の検査機関に依頼して得た遺伝情報を取得してもよい。取得部30は、取得した遺伝情報を記憶部4のユーザ情報DB40に記憶する。
【0045】
また、取得部30は、アカウント作成の際にユーザUが入力したユーザ情報を取得し、ユーザ情報DB40に格納する。また、取得部30は、ユーザUがリカバリ要求を行う際に、ユーザUの顔を含む画像情報を取得する。
【0046】
推定部31は、取得部30によって取得された遺伝情報に基づいてユーザU間での血族関係を推定する。例えば、推定部31は、ユーザ間での遺伝情報の類似度を算出し、かかる類似度に基づいて血族関係を推定する。類似度は、例えば、塩基配列やアミノ酸配列、健康リスク、体質の一致度を基に算出可能である。
【0047】
例えば、推定部31は、後述の受付部33によりリカバリ要求が受け付けられる以前に血族関係を予め推定するとともに、血族関係にあると推定したユーザUに対して事前認定要求を送信する。そして、推定部31は、事前認定要求を送信したユーザUから血族関係を認定することを示す応答があった場合に、血族関係を示す血族情報を記憶部4の血族情報DB42に記憶する。
【0048】
このように、推定部31は、血族関係を事前に推定しておくことで、処理負荷を分散させることができる。また、血族関係にあるユーザUに対して事前認定要求を送信して、血族関係を事前に確認させることで、リカバリの承認要求時に第2ユーザUが戸惑うことを低減することができる。
【0049】
また、推定部31は、血族関係を事前に推定する場合に限らず、リカバリ要求があったタイミングで血族関係を推定してもよい。具体的には、推定部31は、後述の受付部33によってリカバリ要求が受け付けられた場合に、記憶部4に記憶された遺伝情報に基づいて血族関係を推定する。
【0050】
このように、リカバリ要求があった場合にのみ血族関係を推定することで、不要な推定処理を省略できるため、全体の処理量を減らすことができる。
【0051】
管理部32は、ユーザUのアカウントを管理する。具体的には、管理部32は、ユーザUがアカウントを作成した際に、アカウントIDおよびパスワードを発行する。また、管理部32は、ユーザUのログイン状況に応じて記憶部4に記憶されたアカウント情報のアカウント状態を変更する。
【0052】
例えば、管理部32は、ログイン時にアカウントIDまたはパスワードを規定回数以上誤入力した場合に、アカウント状態を「有効」から「失効中」に変更する。そして、管理部32は、後述の承認部34によってアカウントのリカバリが承認された場合には、アカウント状態を「失効中」から「有効」に変更する、すなわちリカバリを実行する。
【0053】
なお、管理部32は、アカウント状態が「失効中」である場合において、リカバリが承認されない場合には、「失効中」から「停止」に変更する。あるいは、管理部32は、アカウント状態が「有効」である場合において、ログインが一定期間以上されてない場合や、アカウントを不正使用した場合には、「有効」から「停止」に変更する。つまり、リカバリの権限を与えることなく、アカウントを利用不可の状態とする。
【0054】
受付部33は、所定のサービスにおいて第1ユーザが有するアカウントのリカバリ要求を受け付ける。例えば、受付部33は、アカウント状態を「有効」から「失効中」となった場合に、第1ユーザUに対してリカバリを実行するか否かの確認要求を送信し、リカバリを実行する旨の応答をリカバリ要求として受け付ける。
【0055】
承認部34は、受付部33によってリカバリ要求が受け付けられた場合に、第1ユーザと血族関係にある第2ユーザに対して、第1ユーザのリカバリの承認要求を行う。例えば、承認部34は、記憶部4に記憶された血族情報に基づき血族関係と認定された第2ユーザに対して承認要求を行う。
【0056】
また、承認部34は、リカバリ要求を受け付ける毎に、推定部31が血族関係の推定処理を行う場合、推定部31から推定された血族関係の第2ユーザに対して承認要求を送信する。
【0057】
また、承認部34は、承認要求を送信する第2ユーザの数を、親等数に応じて変更する。親等数は、第1ユーザの世代を基準にした第2ユーザとの世代差である。例えば、両親および子は親等数が「1」で、兄弟、祖父母および孫は親等数が「2」で、叔父および叔母は親等数が「3」である。
【0058】
そして、承認部34は、親等数に応じた数の第2ユーザからリカバリを承認する応答があった場合に、管理部32にリカバリを実行する指示を出す。
【0059】
なお、承認部34は、リカバリの承認要求を送信する場合、親等数が小さい(血族関係が近い)第2ユーザを優先する制御を行ってもよい。さらに、承認部34は、複数の第2ユーザの親等数が同じ場合には、年齢が高い第2ユーザを優先する等のように、承認ポリシーに基づいて承認を制御してもよい。
【0060】
また、承認部34は、リカバリの承認要求を行う際、第2ユーザに対して第1ユーザの本人確認を要求する。かかる点について、図7を用いて説明する。
【0061】
図7は、承認部34の処理内容を示す図である。図7に示すように、承認部34は、まず、受付部33によってリカバリ要求が受け付けられた場合に、第1ユーザの顔を含む画像情報を取得する。
【0062】
そして、承認部34は、第1ユーザの画像情報を含む確認要求および承認要求を第2ユーザに対して送信する。図7に示す例では、確認要求には、「この人はあなたの兄である○○さんですか?」といった本人を確認する内容や、血族関係を確認する内容等が含まれる。なお、承認部34は、図7に示す確認要求に対して、第2ユーザが、確認要求が確かに第1ユーザから送信されていることを確認できる手段を備えてもよい。具体的には、承認部34は、例えば、確認要求に、第1ユーザの署名が付与されていたり、第1ユーザおよび第2ユーザの両者しか知り得ない秘密の情報が付与されていてもよい。
【0063】
そして、承認部34は、第2ユーザによって「はい」が選択された場合、すなわち、第2ユーザから第1ユーザ本人であることや、第1ユーザと血族関係にあることを示す応答があった場合に、リカバリの承認要求を送信する。
【0064】
一方、承認部34は、第2ユーザによって「いいえ」が選択された場合、すなわち、第2ユーザから第1ユーザ本人ではないことや、第1ユーザと血族関係にないことを示す応答があった場合に、リカバリの承認要求を送信しない。
【0065】
このように、承認部34は、第2ユーザに対して第1ユーザの本人確認や血族確認を行った後に、承認要求を送信することで、血族関係にない第2ユーザに承認要求が誤送信されることや、他人になりすました第1ユーザによる不正なリカバリを防止することができる。
【0066】
また、承認部34は、リカバリ要求を受け付けた場合に、画像情報を取得することで、第1ユーザの現在の顔を画像情報として取得できるため、第2ユーザによる本人確認を容易化できる。
【0067】
なお、リカバリ要求の際に取得する情報は、第1ユーザの画像情報に限らず、第1ユーザの発話を録音した音声情報等といったユーザ情報であってもよい。あるいは、承認部34は、第1ユーザおよび第2ユーザ間で予め取り決めた情報等の予め登録された登録情報を確認要求として第2ユーザに対して送信してもよい。
【0068】
また、図7では、承認部34は、第2ユーザに対して第1ユーザの本人確認および血族確認を含む確認要求を送信したが、本人確認および血族確認の確認要求を分けて送信してもよい。
【0069】
具体的には、承認部34は、第1ユーザのユーザ情報を含む本人確認要求を第2ユーザに対して送信する。そして、承認部34は、第2ユーザから第1ユーザ本人であることを示す応答があった場合に、血族確認要求を第2ユーザに対して送信し、第2ユーザから第1ユーザと血族関係であることを示す応答があった場合に、リカバリの承認要求を送信する。なお、承認部34は、血族確認要求を本人確認要求よりも先に送信してもよい。また、承認部34は、本人確認要求および血族確認要求のうち、いずれか一方のみを送信してもよい。
【0070】
次に、図8を用いて、実施形態に係る管理システムSが実行する処理の手順について説明する。図8は、実施形態に係る管理システムSが実行する処理の手順を示すフローチャートである。なお、図8に示す「第1ユーザ」は、第1ユーザが所持する端末装置10の処理を示し、「第2ユーザ」は、第2ユーザが所持する端末装置10の処理を示す。
【0071】
図8に示すように、まず、第1ユーザ(端末装置10)は、アカウント管理装置1に対してリカバリ要求を送信する(S101)。このとき、第1ユーザは、アカウント管理装置1の指示に従って、顔を撮像した画像情報をリカバリ要求とともに送信する。
【0072】
つづいて、アカウント管理装置1は、遺伝情報に基づいて血族関係を推定する(S102)。
【0073】
つづいて、アカウント管理装置1は、推定の結果、第1ユーザと血族関係にある第2ユーザ(端末装置10)に対して、第1ユーザと血族関係にあることを確認する血族確認要求を送信する(S103)。このとき、アカウント管理装置1は、第1ユーザの画像情報等といったユーザ情報を血族確認要求とともに送信する。
【0074】
そして、第2ユーザは、第1ユーザと血族関係である場合には、第1ユーザと血族関係にあることを示す応答(承認応答)を送信する(S104)。
【0075】
つづいて、アカウント管理装置1は、第2ユーザ(端末装置10)に対して、第1ユーザ本人であることを確認する本人確認要求を送信する(S105)。
【0076】
そして、第2ユーザは、第1ユーザ本人である場合には、第1ユーザ本人であることを示す応答(承認応答)を送信する(S106)。なお、血族確認要求(S103)および本人確認要求(S105)は、処理順が入れ替わってもよい。
【0077】
つづいて、アカウント管理装置1は、第2ユーザに対してリカバリの承認要求を送信する(S107)。
【0078】
そして、第2ユーザは、第1ユーザのアカウントのリカバリを承認する場合、承認応答を送信する(S108)。
【0079】
つづいて、アカウント管理装置1は、第1ユーザのアカウントのリカバリを実行し(S109)、第1ユーザに対してリカバリが完了したことを示すリカバリ通知を送信し(S110)、処理を終了する。
【0080】
また、上述してきた実施形態にかかるアカウント管理装置1は、例えば図9に示すような構成のコンピュータ1000によって実現される。図9は、実施形態に係るアカウント管理装置1の機能を実現するコンピュータ1000の一例を示すハードウェア構成図である。コンピュータ1000は、CPU1100、RAM1200、ROM1300、HDD1400、通信インターフェイス(I/F)1500、入出力インターフェイス(I/F)1600、及びメディアインターフェイス(I/F)1700を有する。
【0081】
CPU1100は、ROM1300又はHDD1400に格納されたプログラムに基づいて動作し、各部の制御を行う。ROM1300は、コンピュータ1000の起動時にCPU1100によって実行されるブートプログラムや、コンピュータ1000のハードウェアに依存するプログラム等を格納する。
【0082】
HDD1400は、CPU1100によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を格納する。通信インターフェイス1500は、ネットワークNを介して他の機器からデータを受信してCPU1100へ送り、CPU1100が生成したデータを、ネットワークNを介して他の機器へ送信する。
【0083】
CPU1100は、入出力インターフェイス1600を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。CPU1100は、入出力インターフェイス1600を介して、入力装置からデータを取得する。また、CPU1100は、生成したデータを、入出力インターフェイス1600を介して出力装置へ出力する。
【0084】
メディアインターフェイス1700は、記録媒体1800に格納されたプログラム又はデータを読み取り、RAM1200を介してCPU1100に提供する。CPU1100は、かかるプログラムを、メディアインターフェイス1700を介して記録媒体1800からRAM1200上にロードし、ロードしたプログラムを実行する。記録媒体1800は、例えばDVD(Digital Versatile Disc)、PD(Phase change rewritable Disk)等の光学記録媒体、MO(Magneto-Optical disk)等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。
【0085】
例えば、コンピュータ1000が実施形態にかかるアカウント管理装置1として機能する場合、コンピュータ1000のCPU1100は、RAM1200上にロードされたプログラムを実行することにより、制御部3の機能を実現する。また、HDD1400には、記憶部4内のデータが格納される。コンピュータ1000のCPU1100は、これらのプログラムを、記録媒体1800から読み取って実行するが、他の例として、他の装置から、ネットワークNを介してこれらのプログラムを取得してもよい。
【0086】
なお、上述した実施形態では、実施形態に係るアカウント管理装置1がアカウントのリカバリを実行する場合について説明したが、例えば、アカウントのクローズ処理であってもよい。
【0087】
具体的には、実施形態に係るアカウント管理装置1の受付部33は、アカウントのクローズ処理要求を実行要求として受け付ける。アカウントのクローズ処理要求は、例えば、第1ユーザ自身が死亡した場合に、第3者のユーザや、第2ユーザ等の第1ユーザ以外の他のユーザから受け付ける。なお、第1ユーザの端末装置10が死亡等により解約される場合に、クローズ処理要求が自動で送信されるように設定されてもよい。
【0088】
そして、承認部34は、クローズ処理要求を受け付けた場合に、第1ユーザと血族関係にある第2ユーザに対して、クローズ処理の承認要求を行う。そして、管理部32は、第2ユーザからクローズ処理を承認する旨の通知を受け付けた場合、クローズ処理を実行する。
【0089】
このように、遺伝情報を基に血族関係を推定することで、例えば、第1ユーザ自身が突然、不慮の事故で死亡した場合、当該第1ユーザのアカウントのクローズ処理を代理で親族(第2ユーザ)が実施する場合、親族であるか否かの真偽判定に要する労力を低減することができる。
【0090】
なお、リカバリやクローズ処理以外にも、アカウントの登録情報の変更処理や、アカウントの新規登録、アカウントの削除等の他の手続きであってもよい。
【0091】
上述してきたように、実施形態に係るアカウント管理装置1は、受付部33と、承認部34とを備える。受付部33は、所定のサービスにおいて第1ユーザが有するアカウントの手続きの実行要求を受け付ける。承認部34は、受付部33によって実行要求が受け付けられた場合に、遺伝情報に基づき推定される第1ユーザと血族関係にある第2ユーザに対して、手続きの承認要求を行う。
【0092】
これにより、アカウントの手続きに関してユーザUの利便性を向上させることができる。
【0093】
また、上述した実施形態に係るアカウント管理装置1において、受付部33は、アカウントのリカバリ要求を実行要求として受け付ける。承認部34は、第2ユーザに対して、リカバリの承認要求を行う。
【0094】
これにより、ユーザUにとって利便性の高いリカバリを行うことができる。
【0095】
また、上述した実施形態に係るアカウント管理装置1において、受付部33は、アカウントのクローズ処理要求を実行要求として受け付ける。承認部34は、第2ユーザに対して、クローズ処理の承認要求を行う。
【0096】
これにより、例えば、第1ユーザ自身が突然、不慮の事故で死亡した場合、当該第1ユーザのアカウントのクローズ処理を代理で親族(第2ユーザ)が実施する場合、親族であるか否かの真偽判定に要する労力を低減することができる。
【0097】
また、上述した実施形態に係るアカウント管理装置1において、承認部34は、第1ユーザのユーザ情報を含む本人確認要求および承認要求を第2ユーザに対して送信し、第2ユーザから第1ユーザ本人であることを示す応答があった場合に、手続きを実行する。
【0098】
これにより、第3者が第1ユーザになりすまして実行要求したとしても、第2ユーザが第1ユーザの本人確認を行うことで、誤ってアカウントの手続きが実行されることを防止できる。
【0099】
また、上述した実施形態に係るアカウント管理装置1において、承認部34は、第1ユーザのユーザ情報を含む血族確認要求および承認要求を第2ユーザに対して送信し、第2ユーザから第1ユーザと血族関係であることを示す応答があった場合に、手続きを実行する。
【0100】
これにより、第2ユーザ本人から血族者であることを確認できるため、血族者である第2ユーザに対して手続きの承認要求を確実に送信できる。
【0101】
また、上述した実施形態に係るアカウント管理装置1において、承認部34は、第1ユーザの画像情報、音声情報および予め登録された登録情報のうち、少なくとも1つの情報を含むユーザ情報を第2ユーザに対して送信する。
【0102】
これにより、第2ユーザによる第1ユーザの確認を容易化できる。
【0103】
また、上述した実施形態に係るアカウント管理装置1において、承認部34は、受付部33によって実行要求が受け付けられた場合に、ユーザ情報を取得する。
【0104】
これにより、最新のユーザ情報を取得できるため、第2ユーザによる第1ユーザの確認を容易化できる。
【0105】
また、上述した実施形態に係るアカウント管理装置1において、承認部34は、親等数に応じた数の第2ユーザから手続きを承認する応答があった場合に、手続きを実行する。
【0106】
これにより、例えば、親等数が高い、すなわち、第1ユーザとの世代差が大きくなり信頼性が低下するほど承認数を多く設定できるため、手続きの承認精度を向上させることができる。
【0107】
また、上述した実施形態に係るアカウント管理装置1は、取得部30と、推定部31とを備える。取得部30は、ユーザ毎の遺伝情報を取得する。推定部31は、取得部30によって取得された遺伝情報に基づいて血族関係を推定する。
【0108】
これにより、ユーザの血族関係を高精度に推定できるため、血族者である第2ユーザを高精度に特定することができる。
【0109】
また、上述した実施形態に係るアカウント管理装置1において、推定部31は、実行要求を受け付ける以前に血族関係を予め推定するとともに、血族関係にあると推定したユーザに対して事前認定要求を送信し、血族関係を認定することを示す応答がユーザからあった場合に、血族関係を示す血族情報を記憶部4に記憶する。承認部34は、記憶部4に記憶された血族情報に基づき血族関係と認定された第2ユーザに対して承認要求を行う。
【0110】
これにより、血族関係を推定する推定処理を分散して行うことができるため、アカウント管理装置1の処理負荷を軽減できる。
【0111】
また、上述した実施形態に係るアカウント管理装置1において、取得部30は、遺伝情報を記憶部4に記憶する。推定部31は、受付部33によって実行要求が受け付けられた場合に、記憶部4に記憶された遺伝情報に基づいて血族関係を推定する。
【0112】
これにより、必要最小限の推定処理を行えばよいため、アカウント管理装置1の全体の処理量が嵩むことを防止できる。
【0113】
以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。
【0114】
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。
【0115】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
【0116】
また、上述してきた実施形態に記載した各処理は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【0117】
また、上記してきた「部(section、module、unit)」は、「手段」や「回路」などに読み替えることができる。例えば、承認部34は、承認手段や承認回路に読み替えることができる。
【符号の説明】
【0118】
1 アカウント管理装置
2 通信部
3 制御部
4 記憶部
10 端末装置
30 取得部
31 推定部
32 管理部
33 受付部
34 承認部
100 サービスサーバ
U ユーザ
図1
図2
図3
図4
図5
図6
図7
図8
図9