JP2018181074A - リカバリ装置、リカバリ方法及びリカバリプログラム - Google Patents

Abstract

【課題】ユーザにとって利便性の高いアカウントリカバリを行うリカバリ装置、リカバリ方法及びリカバリプログラムを提供する。【解決手段】リカバリ装置１００は、第１取得部と、第２取得部と、検証部と、実行部とを備える。第１取得部は、第１のサービスにおけるユーザの行動履歴に関する情報である第１情報を取得する。第２取得部は、第１情報以外の情報であって、ユーザの行動履歴に関する情報である第２情報を取得する。検証部は、第１情報と第２情報との照合に基づいて、ユーザの本人性を検証する。実行部は、検証部によってユーザの本人性が検証された場合に、第１のサービスにおいて当該ユーザが有していたアカウントのリカバリを実行する。【選択図】図１

Description

本発明は、リカバリ装置、リカバリ方法及びリカバリプログラムに関する。

一般に、ネットワークを介してサービスを利用する場合、ユーザは、各サービスに自身のアカウントを作成する。また、ユーザは、例えば端末を新しく買い替えた場合や、パスワード等の認証情報を失念した場合など、何らかの理由でアカウントを利用することができなくなる事態に備えて、アカウントをリカバリするための設定を行う。例えば、ユーザは、自身しか知り得ない質問と答えのペア（一般に、「秘密の質問」等と称される）を予めサービスに登録する。そして、ユーザは、リカバリを必要とする際には、その質問に回答を行うことで、自身がアカウントの所有者であることを証明する。これにより、サービス側によって、アカウントのリカバリが行われる。

上記した秘密の質問のような、ユーザの本人性の検証（本人認証）に関する技術として、ユーザのライフログを取得するとともに、ライフログに関する質問を自動的に生成し、ユーザからの回答を得ることで本人認証を行う技術が知られている。

特開２００９−９３２７３号公報

しかしながら、上記の従来技術では、ユーザにとって利便性の高いアカウントリカバリを行うことは難しい。具体的には、従来技術では、ユーザが、ライフログに基づいて生成された質問に対して行うことが必須となる。また、秘密の質問のような手法で認証を行う場合には、ユーザは事前に質問と回答を登録しなければならない。このため、いずれの手法であっても、ユーザにとって利便性の高いアカウントリカバリを行うことができるとは言い難い。

本願は、上記に鑑みてなされたものであって、ユーザにとって利便性の高いアカウントリカバリを行うことができるリカバリ装置、リカバリ方法及びリカバリプログラムを提供することを目的とする。

本願に係るリカバリ装置は、第１のサービスにおけるユーザの行動履歴に関する情報である第１情報を取得する第１取得部と、前記第１情報以外の情報であって、前記ユーザの行動履歴に関する情報である第２情報を取得する第２取得部と、前記第１情報と前記第２情報との照合に基づいて、前記ユーザの本人性を検証する検証部と、前記検証部によってユーザの本人性が検証された場合に、前記第１のサービスにおいて当該ユーザが有していたアカウントのリカバリを実行する実行部と、を備えることを特徴とする。

実施形態の一態様によれば、ユーザにとって利便性の高いアカウントリカバリを行うことができるという効果を奏する。

図１は、実施形態に係るリカバリ処理の一例を示す図（１）である。 図２は、実施形態に係るリカバリ処理の一例を示す図（２）である。 図３は、実施形態に係るリカバリシステムの構成例を示す図である。 図４は、実施形態に係るリカバリ装置の構成例を示す図である。 図５は、実施形態に係る第１サービス情報記憶部の一例を示す図である。 図６は、実施形態に係る検証情報記憶部の一例を示す図である。 図７は、実施形態に係る定義情報記憶部の一例を示す図である。 図８は、実施形態に係る第１端末の構成例を示す図である。 図９は、実施形態に係る第２サービス提供サーバの構成例を示す図である。 図１０は、実施形態に係る第２サービス情報記憶部の一例を示す図である。 図１１は、実施形態に係るリカバリ装置の処理手順を示すフローチャートである。 図１２は、実施形態に係るユーザ端末の処理手順を示すフローチャートである。 図１３は、リカバリ装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下に、本願に係るリカバリ装置、リカバリ方法及びリカバリプログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係るリカバリ装置、リカバリ方法及びリカバリプログラムが限定されるものではない。また、各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。

〔１．リカバリ処理の一例〕
まず、図１を用いて、実施形態に係るリカバリ処理の一例について説明する。図１は、実施形態に係るリカバリ処理の一例を示す図（１）である。図１では、本願に係るリカバリ装置１００によって、所定のサービスのアカウントをリカバリする処理が実行される一例を示す。なお、以下では、アカウントがリカバリされる対象となるサービスを「第１のサービス」と表記する場合がある。

図１に示すリカバリ装置１００は、実施形態に係るリカバリ処理を実行するサーバ装置である。また、実施形態では、リカバリ装置１００は、第１のサービスを提供するサービスサーバとしての機能を兼ねる。例えば、リカバリ装置１００は、第１のサービスとして、ポータルサイトに係るサービスを提供する。具体的には、リカバリ装置１００は、アカウントを登録したユーザからログインを受け付けた場合には、当該ユーザ向けにカスタマイズされたポータルサイトを提供するようなサービスを提供する。なお、リカバリ装置１００が提供する第１のサービスは、ポータルサイトにおいて提供される検索サービスや、ポータルサイトからリンクされたショッピングサービスや、情報提供サービス（例えばニュースサービスや天気予報サービス）等を含んでもよい。

図１に示すユーザＵ０１は、第１のサービスを利用するユーザの一例である。すなわち、ユーザＵ０１は、リカバリ装置１００が提供する第１のサービスにおいてアカウントを有する。また、図１に示す例では、ユーザＵ０１は、複数の情報処理端末（デバイス）を所持する。例えば、ユーザＵ０１は、スマートフォン２０や、手首等に装着可能なウェアラブルデバイス（wearable device）の一例であるウェアラブルデバイス３０（各デバイスを区別する必要のない場合は、これらを「ユーザ端末１０」と総称する場合がある）を所持する。なお、以下では、ユーザをユーザ端末１０等と読み替える場合がある。例えば、「ユーザがリカバリの要求を送信する」という記載は、実際には、「ユーザが利用するユーザ端末１０がリカバリの要求を送信する」という状況を示す場合がある。

図１に示す例では、所定の理由によって第１のサービスにおいてユーザＵ０１が保持していたアカウントが、利用不可能な状態になっているものとする。例えば、ユーザＵ０１が、第１のサービスにログインするための認証情報（例えばパスワード）を忘れたり、これまで第１のサービスへのアクセスに利用していた端末を買い替えたり、誤ってアカウントを削除したりした場合に、ユーザＵ０１が保持していたアカウントは、利用不可能な状態になる場合がある。

第１のサービスの提供者は、利用不可能となったアカウントについて、ユーザＵ０１本人がリカバリを所望している場合には、所定の条件に基づいてアカウントをリカバリすることができる。このとき、第１のサービスの提供者は、アカウントのリカバリを所望しているユーザが、真にユーザＵ０１本人であるかを検証する。そして、第１のサービスの提供者は、リカバリを所望するユーザが、ユーザＵ０１本人と検証された場合にアカウントをリカバリする。一般に、このようなリカバリを行うためには、ユーザＵ０１が、第１のサービスに対してリカバリに関する設定を予め登録しておく必要がある。例えば、ユーザＵ０１は、自身しか知り得ない情報で構成される「秘密の質問と答えのペア」を第１のサービスに予め登録する。そして、リカバリが必要になった場合、ユーザＵ０１は、秘密の質問に対する答えを第１のサービスに送信することで、自身の本人性を証明する。

しかしながら、上記の手法では、ユーザＵ０１が事前に秘密の質問と答えを登録していない場合には、アカウントのリカバリ処理を実行することができない。そこで、実施形態に係るリカバリ装置１００は、以下に説明する手法を用いることで、事前の登録処理を必要とせずに、アカウントのリカバリ処理を実行する。具体的には、リカバリ装置１００は、第１のサービスにおけるユーザＵ０１の行動履歴に関する情報（以下、「第１情報」と表記する場合がある）と、第１情報以外のユーザＵ０１の行動履歴に関する情報（以下、「第２情報」と表記する場合がある）との照合に基づいて、ユーザＵ０１の本人性を検証し、本人性が検証された場合に、第１のサービスにおいてユーザＵ０１が有していたアカウントのリカバリを実行する。以下、図１を用いて、実施形態に係るリカバリ処理の流れについて説明する。

なお、図１の例では、ユーザＵ０１は、スマートフォン２０を介して、第１のサービスを利用するものとする。このように、第１のサービスにログインしたり、第１のサービスに対してアカウントのリカバリを要求したりするために利用される端末を「第１端末」と表記する場合がある。また、ウェアラブルデバイス３０のように、第１端末以外の端末であって、実施形態に係るリカバリ処理に利用される情報（すなわち、上記した第２情報）を提供する端末を「第２端末」と表記する場合がある。

まず、第１のサービスにおいて保持していたアカウントが利用不可能となったユーザＵ０１は、スマートフォン２０を介して、アカウントのリカバリの要求をリカバリ装置１００に送信する（ステップＳ１１）。

リカバリ装置１００は、アカウントのリカバリの要求を受信した場合には、リカバリするアカウントを特定するための情報を要求する。具体的には、リカバリ装置１００は、アカウントに設定されていたユーザＩＤの入力をユーザＵ０１に要求する（ステップＳ１２）。

ユーザＵ０１は、スマートフォン２０を介して、ユーザＩＤをリカバリ装置１００に送信する（ステップＳ１３）。リカバリ装置１００は、スマートフォン２０から送信されたユーザＩＤを検証する（ステップＳ１４）。リカバリ装置１００は、送信されたユーザＩＤと、リカバリしようとするアカウントに設定されたユーザＩＤとを照合して、リカバリが要求されたアカウントを特定する。

続いて、リカバリ装置１００は、アカウントをリカバリしようとするユーザＵ０１が、ユーザＩＤで特定されるユーザＵ０１本人であるかの検証を試みる。言い換えれば、リカバリ装置１００は、ユーザＵ０１の本人確認を行う。これは、例えば第三者が不正に取得したユーザＩＤを利用し、ユーザＵ０１に成りすますことによって不正にアカウントを取得するような事態を防止するためである。なお、リカバリ装置１００は、ステップＳ１２において、ユーザＵ０１の本人性を確認できる情報であれば、ユーザＩＤ以外の識別子を要求してもよい。例えば、リカバリ装置１００は、ユーザＵ０１から登録を受け付けていた電話番号やメールアドレス等を要求してもよい。

ここで、実施形態に係るリカバリ装置１００は、ユーザＵ０１の本人確認に用いるための情報を特定する（ステップＳ１５）。例えば、リカバリ装置１００は、ユーザＵ０１の本人性を検証するために利用することのできる情報であって、第１のサービスに蓄積されている第１情報を参照する。そして、リカバリ装置１００は、参照した第１情報のうち、検証処理に用いることのできる第１情報の種別を特定する。すなわち、リカバリ装置１００は、過去の第１のサービスの行動履歴に基づき、ユーザＵ０１の本人性を検証するために利用可能である情報の種別を特定する。

例えば、リカバリ装置１００は、第１のサービスの運用において、ユーザＵ０１が第１のサービスにログインした時点における位置情報を取得し、取得した位置情報を蓄積しているものとする。具体的には、リカバリ装置１００は、スマートフォン２０が有するＧＰＳ（Global Positioning System）機能によって取得された位置情報を、ログインが行われた時点や、ログイン中の所定時間ごと（例えば１０分ごと）に取得する。なお、リカバリ装置１００が取得する位置情報は、ＧＰＳ機能によって取得される位置情報に限られず、例えば、第１のサービスにアクセスしたスマートフォン２０のＩＰアドレス等から推定される位置情報であってもよい。また、位置情報は、経度や緯度を示す具体的な数値であってもよいし、ある地域を示す住所情報等であってもよい。

すなわち、リカバリ装置１００は、リカバリ要求を受信する前までに、ユーザＵ０１が過去に第１のサービスを利用していた期間におけるユーザＵ０１（すなわちスマートフォン２０）の位置情報を相当数取得し、取得した情報を所定の記憶装置に蓄積しているものとする。

第１情報として位置情報が蓄積されていることを参照したリカバリ装置１００は、ユーザＵ０１の本人性の検証において、過去の所定時点における位置情報を用いることが可能であると判定する。すなわち、リカバリ装置１００は、ユーザＵ０１の本人確認に用いる情報の種別を「位置情報」に特定する。例えば、リカバリ装置１００は、第１情報として蓄積されている情報のうち、情報量の多い情報の種別を優先的に用いて、本人確認を行ってもよい。

なお、検証に用いる情報の種別や検証の手法は、例えばリカバリ装置１００の管理者によって設定される定義情報によって、様々に定められてもよい。例えば、リカバリ装置１００は、第１情報を参照せずとも、予めアカウントのリカバリにおいて位置情報を用いること等が定義された情報を参照し、かかる定義情報に従って本人確認を行ってもよい。このような定義情報について、詳しくは後述する。

情報を特定したリカバリ装置１００は、スマートフォン２０に対して本人確認要求を送信する（ステップＳ１６）。リカバリ装置１００から送信される本人確認要求は、例えば、アカウントのリカバリにおいてユーザＵ０１の本人確認を行うために必要とする第２情報の送信要求を含む。具体的には、リカバリ装置１００は、第１のサービスで保持されている行動履歴（図１の例では、第１のサービスにログインした時点等に取得された位置情報）と照合するための情報であって、第１のサービス以外における行動履歴（図１の例では、第１のサービス以外で保持される位置情報）を、スマートフォン２０に対して要求する。

要求を受信したスマートフォン２０は、第１のサービス以外に保持されている、ユーザＵ０１の行動履歴の取得を試みる。例えば、スマートフォン２０は、第１端末であるスマートフォン２０以外のデバイスを介して、ユーザＵ０１の行動履歴に関する情報を取得する。例えば、スマートフォン２０は、自身の近傍にあるデバイスを検出する処理を行う。例えば、スマートフォン２０は、Ｗｉｆｉ（登録商標）や、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の電波を検知したり、同じアクセスポイントを利用しているデバイスを検出したりすることにより、近傍のデバイスを検出する。図１の例では、スマートフォン２０は、ウェアラブルデバイス３０を検出する。

実施形態において、ウェアラブルデバイス３０は、ユーザＵ０１の手首等に装着されるデバイスであり、定期的（例えば５分ごと）に位置情報を取得するデバイスであるものとする。また、ウェアラブルデバイス３０は、所定の期間（例えば数か月）におけるユーザＵ０１の位置情報の履歴をキャッシュしているものとする。

そこで、スマートフォン２０は、ウェアラブルデバイス３０に対して、ウェアラブルデバイス３０によってキャッシュされているデータ（図１の例では、位置情報）を要求する（ステップＳ１７）。ウェアラブルデバイス３０は、スマートフォン２０に対して、キャッシュされている位置情報を送信する（ステップＳ１８）。これにより、スマートフォン２０は、リカバリ装置１００から要求された第２情報である、第１のサービス以外における位置情報を取得する。

そして、スマートフォン２０は、リカバリ装置１００から送信された本人確認要求に応答して、ウェアラブルデバイス３０によってキャッシュされていた位置情報を送信する（ステップＳ１９）。この場合、スマートフォン２０は、送信する位置情報が、自装置ではなくウェアラブルデバイス３０によって取得された位置情報であることを識別する情報を付与してもよい。

リカバリ装置１００は、送信された位置情報を用いて、ユーザＵ０１の本人性を検証する（ステップＳ２０）。上述のように、リカバリ装置１００は、第１のサービスにおけるユーザＵ０１の行動履歴（第１情報）と、第１情報以外のユーザＵ０１の行動履歴に関する情報（第２情報）とを照合する。具体的には、リカバリ装置１００は、第１情報の一例である「所定日時における第１のサービスへのログイン時点のユーザＵ０１の位置情報」と、第２情報の一例である「同一の所定日時における、ウェアラブルデバイス３０によって取得されたユーザＵ０１の位置情報」とを照合する。なお、リカバリ装置１００は、ある１つの時点の位置情報同士を照合するのみならず、より多くの時点の位置情報同士を照合してもよい。

すなわち、リカバリ装置１００は、ユーザＵ０１の本人確認として、第１情報と第２情報とにおける位置情報が一致しているか否かを検証する。これにより、リカバリ装置１００は、過去に第１のサービスへのログインに利用された際のスマートフォン２０と、スマートフォン２０以外の他のデバイスであるウェアラブルデバイス３０とが、当該ログインの時点において、同じ位置に所在していたことを検証できる。

このことは、リカバリ装置１００がユーザＵ０１に対して「所定時間にあなたがいた場所は？」という質問を送信し、ユーザＵ０１がその質問に回答したことに対応する状況を示している。すなわち、リカバリ装置１００は、第１のサービスの行動履歴を用いて、ユーザＵ０１にしか回答することのできない、いわゆる「秘密の質問」を作成することと同等の処理を行う。また、ユーザＵ０１は、ウェアラブルデバイス３０という第１端末以外のデバイスを用いて、その回答となる情報をリカバリ装置１００に送信することと同等の処理を行っている。そして、リカバリ装置１００が保持する位置情報と、同時間に対応する位置情報であって、ユーザＵ０１から送信された位置情報が示す内容とが、およそ同じ位置を示す情報であるとするならば、送信された位置情報を保持するユーザＵ０１とは、ユーザＵ０１本人である蓋然性が高いと判定される。かかる処理によって、リカバリ装置１００は、ユーザＵ０１の本人性を検証する。

リカバリ装置１００は、ユーザＵ０１の本人性を検証した場合には、リカバリの要求に従い、ユーザＵ０１が保持していたアカウントのリカバリを実行する（ステップＳ２１）。そして、リカバリ装置１００は、アカウントがリカバリされた旨をユーザＵ０１に通知する（ステップＳ２２）。なお、リカバリ装置１００は、ユーザＵ０１の本人性が検証できない場合には、アカウントのリカバリができない旨をユーザＵ０１に通知してもよい。

このように、リカバリ装置１００は、第１のサービスにおけるユーザＵ０１の行動履歴と、例えばウェアラブルデバイス３０のような第１のサービス以外において保持されている行動履歴とを照合することで、ユーザＵ０１の本人性を検証する。これにより、リカバリ装置１００は、事前の登録を要さずとも、第１のサービスにおける行動履歴というユーザＵ０１しか知り得ない情報と、第１のサービス以外における行動履歴という、ユーザＵ０１しか回答できない情報とを照合することができる。そして、リカバリ装置１００は、照合の結果に基づいて、ユーザＵ０１のアカウントをリカバリする。すなわち、リカバリ装置１００は、秘密の質問などの事前登録がなくともリカバリ処理を実行できるため、ユーザにとって利便性の高いリカバリ処理を提供することができる。

なお、リカバリ装置１００は、第２情報として、ウェアラブルデバイス３０にキャッシュされた行動履歴のみならず、第１のサービス以外のサービス（以下、「第２のサービス」と表記する場合がある）に保持された第２情報を用いてもよい。この点について、図２を用いて説明する。図２は、実施形態に係るリカバリ処理の一例を示す図（２）である。

図２に示した例において、ウェアラブルデバイス３０は、定期的に取得するユーザＵ０１の行動履歴に関する情報（例えば、位置情報や、位置情報を取得した日時など）を、第２サービス提供サーバ２００に送信するものとする。なお、第２サービス提供サーバ２００は、第２サービスとして、ユーザＵ０１からアクセスされた場合に、例えばユーザＵ０１の一日の移動距離や、歩行数や、移動による消費カロリー等の情報を提示するサービスを提供するサーバ装置である。

図２に示した例では、リカバリ装置１００は、図１においてウェアラブルデバイス３０から取得していた第２情報を、第２サービス提供サーバ２００から取得する。以下、図２における処理の流れについて説明する。なお、図２に示したステップＳ３１〜Ｓ３６は、図１に示したステップＳ１１〜Ｓ１６に各々対応するため、説明を省略する。

図２に示すステップＳ３６に続いて、スマートフォン２０は、第２情報として、第１のサービス以外に保持されているユーザＵ０１の行動履歴の取得を試みる。具体的には、スマートフォン２０は、ウェアラブルデバイス３０に対して、検証に使用する情報を要求する（ステップＳ３７）。

図２に示す例では、ウェアラブルデバイス３０は、スマートフォン２０に要求される情報を、自装置内に保持していないものとする。具体的には、スマートフォン２０が要求した行動履歴の日時が、ウェアラブルデバイス３０に保持されている行動履歴の日時よりも過去のものであり、ウェアラブルデバイス３０は、スマートフォン２０の要求に対応する行動履歴（位置情報）をキャッシュしていないものとする。

そこで、ウェアラブルデバイス３０は、自装置が定期的にアップロードしている情報の利用を第２サービス提供サーバ２００に要求する（ステップＳ３８）。具体的には、ウェアラブルデバイス３０は、過去にアップロードしたユーザＵ０１の位置情報に関する情報の利用許可を、第２サービス提供サーバ２００に要求する。なお、第２サービス提供サーバ２００は、例えば、ウェアラブルデバイス３０から送信されるデバイスＩＤによって、第２のサービスにおけるユーザＵ０１のアカウントを特定する。そして、第２サービス提供サーバ２００は、特定されたアカウントに対応付けられている位置情報等を、ユーザＵ０１に提供すべき情報として特定する。

要求を受信した第２サービス提供サーバ２００は、例えば、自装置に保持している情報にアクセスするためのアクセストークン（Access Token）を発行する（ステップＳ３９）。そして、第２サービス提供サーバ２００は、発行したアクセストークンをウェアラブルデバイス３０に送信する。ウェアラブルデバイス３０は、受信したアクセストークンをスマートフォン２０に送信する（ステップＳ４０）。ユーザ端末１０は、受信したアクセストークンをリカバリ装置１００に送信する（ステップＳ４１）。なお、後述するように、アクセストークンは、スマートフォン２０を介さずに、ウェアラブルデバイス３０からリカバリ装置１００に送信されてもよい。

アクセストークンを受信したリカバリ装置１００は、第２サービス提供サーバ２００にアクセスする（ステップＳ４２）。そして、リカバリ装置１００は、アクセストークンによって利用が許可されたユーザＵ０１の位置情報等の、検証に用いる情報を取得する（ステップＳ４３）。

リカバリ装置１００は、第２サービス提供サーバ２００から取得した情報と、第１のサービスにおけるユーザＵ０１の行動履歴とを照合することで、ユーザＵ０１の本人性を検証する（ステップＳ４４）。かかる検証は、図１のステップＳ２０と同様の処理によって行われる。そして、リカバリ装置１００は、ユーザＵ０１の本人性を検証した場合には、ユーザＵ０１が保持していたアカウントのリカバリを実行する（ステップＳ４５）。そして、リカバリ装置１００は、アカウントがリカバリされた旨をユーザＵ０１に通知する（ステップＳ４６）。

このように、リカバリ装置１００は、第１のサービス以外のサービスである第２のサービス側から取得するユーザＵ０１の行動履歴と、第１のサービスにおける行動履歴とを照合することによって、ユーザＵ０１の本人性を検証してもよい。かかる処理によれば、リカバリ装置１００は、第２のサービスによって保持される情報という、ユーザＵ０１が改竄することが困難な情報を利用して検証を行うことになるため、不正ユーザによる成りすまし等を高い精度で防止することのできる、より安全性の高いリカバリ処理を行うことができる。

なお、図１及び図２の例では、リカバリ処理に用いる行動履歴として位置情報を例に挙げたが、リカバリ装置１００は、位置情報に限らず、第１のサービスで保持する種々の種別の行動履歴を利用してもよい。例えば、リカバリ装置１００は、第１のサービスでユーザＵ０１が商品を購買した購買履歴を利用してもよい。具体的には、リカバリ装置１００は、ユーザＵ０１が購買した商品の配送先に関する情報を取得する。また、リカバリ装置１００は、第２のサービスとして、当該商品を配送する配送会社から、当該商品を配送先に配送した配送履歴を取得する。そして、リカバリ装置１００は、取得した２つの情報を照合し、配送された配送先の所在地や配送日時が一致するか否かを判定する。リカバリ装置１００は、配送先の所在地や配送日時が一致した場合には、当該購買を行ったユーザＵ０１と、リカバリを要求したユーザＵ０１とが同一のユーザである蓋然性が高いと推定する。かかる処理により、リカバリ装置１００は、ユーザＵ０１の本人性を検証し、アカウントのリカバリを行うことができる。

また、ユーザＵ０１は、実施形態に係るリカバリ処理に先立ち、第１のサービスと第２のサービスとを連携させる処理を行っていてもよい。例えば、ユーザＵ０１に提供されるサービスには、複数のサービスでアカウントを作成したユーザが本人であることを事前に確認することで、サービス同士で共通したＩＤを利用するといった、いわゆるＩＤ連携を行うことができるサービスが存在する場合がある。

図１及び図２で示した例において、第１のサービスと第２のサービスの間で上記のようなＩＤ連携が行われている場合、リカバリ装置１００は、ステップＳ１４において、必ずしも第１のサービスに関するユーザＩＤをスマートフォン２０から受信することを要しない。例えば、リカバリ装置１００は、ユーザＵ０１が第１のサービスと第２のサービスとの間で本人確認に用いられる仮ＩＤの発行を第２のサービスから受けることができる場合には、かかる仮ＩＤに基づいて、第１のサービスにおけるアカウントを特定してもよい。

また、第１のサービスと第２のサービスの間でＩＤ連携が行われている場合、リカバリ装置１００は、ステップＳ４０において、スマートフォン２０を介さず、ウェアラブルデバイス３０から直接にアクセストークンを受信してもよい。すなわち、リカバリ装置１００は、ウェアラブルデバイス３０から直接にアクセストークンを受信した場合でも、連携したＩＤに基づいて第２のサービスに保持されているユーザＵ０１の第２情報を特定することができるため、第１のサービスにおけるユーザＵ０１のアカウントリカバリに用いる情報を正確に取得することができる。

〔２．リカバリシステムの構成〕
次に、図３を用いて、実施形態に係るリカバリ装置１００が含まれるリカバリシステム１の構成について説明する。図３は、実施形態に係るリカバリシステム１の構成例を示す図である。図３に例示するように、実施形態に係るリカバリシステム１には、ユーザ端末１０と、リカバリ装置１００と、第２サービス提供サーバ２００が含まれる。また、ユーザ端末１０には、スマートフォン２０等の第１端末と、ウェアラブルデバイス３０等の第２端末とが含まれる。これらの各種装置は、ネットワークＮを介して、有線又は無線により通信可能に接続される。

ユーザ端末１０は、例えば、デスクトップ型ＰＣ（Personal Computer）や、ノート型ＰＣや、タブレット型端末や、スマートフォンを含む携帯電話機、ＰＤＡ（Personal Digital Assistant）等の情報処理端末（デバイス）である。また、ユーザ端末１０には、時計型端末や、眼鏡型端末などのウェアラブルデバイス（wearable device）も含まれる。さらに、ユーザ端末１０には、情報処理機能を有する種々のスマート機器が含まれてもよい。例えば、ユーザ端末１０には、ＴＶ（Television）などのスマート家電や、自動車などのスマートビークル（Smart vehicle）や、ドローン（drone）、家庭用ロボットなどが含まれてもよい。

リカバリ装置１００は、第１のサービスにおいてユーザが保持するアカウントをリカバリするサーバ装置である。なお、実施形態では、リカバリ装置１００は、第１のサービスを提供するウェブサーバの機能を兼ねるものとしているが、リカバリ装置１００と、第１のサービスを提供するウェブサーバとは、別々の装置であってもよい。

第２サービス提供サーバ２００は、第２のサービスをユーザに提供するサーバ装置である。例えば、第２サービス提供サーバ２００は、ユーザ端末１０から送信される各種情報を蓄積し、蓄積した情報に基づいてユーザに有用な情報を送信するようなサービスを提供する。具体的には、第２サービス提供サーバ２００は、取得した位置情報に基づいて、ユーザの一日の移動距離や、歩行数や、移動による消費カロリー等の情報を提示するサービスを提供する。また、第２サービス提供サーバ２００は、所定の場合には、実施形態に係るリカバリ処理においてユーザの検証に用いられる情報を、リカバリ装置１００に提供する。

〔３．リカバリ装置の構成〕
次に、図４を用いて、実施形態に係るリカバリ装置１００の構成について説明する。図４は、実施形態に係るリカバリ装置１００の構成例を示す図である。図４に示すように、リカバリ装置１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。なお、リカバリ装置１００は、リカバリ装置１００を利用する管理者等から各種操作を受け付ける入力部（例えば、キーボードやマウス等）や、各種情報を表示するための表示部（例えば、液晶ディスプレイ等）を有してもよい。

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

（記憶部１２０について）
記憶部１２０は、例えば、ＲＡＭ（Random Access Memory)、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。記憶部１２０は、第１サービス情報記憶部１２１と、検証情報記憶部１２２と、定義情報記憶部１２３とを有する。

（第１サービス情報記憶部１２１について）
第１サービス情報記憶部１２１は、第１のサービスに関する情報を記憶する。ここで、図５に、実施形態に係る第１サービス情報記憶部１２１の一例を示す。図５は、実施形態に係る第１サービス情報記憶部１２１の一例を示す図である。図５に示した例では、第１サービス情報記憶部１２１は、「アカウントＩＤ」、「登録デバイスＩＤ」、「登録ユーザ」、「ユーザＩＤ」、「認証情報」、「第１サービス行動履歴」といった項目を有する。また、第１サービス行動履歴は、「利用ログＩＤ」、「行動履歴」、「行動日時」、「位置情報」といった小項目を有する。

「アカウントＩＤ」は、第１のサービスにおけるアカウントを識別する識別情報を示す。「登録デバイスＩＤ」は、第１のサービスで利用するデバイスとして登録されているデバイスを識別する識別情報を示す。「登録ユーザ」は、アカウントを保持するユーザを示す。なお、実施形態において、アカウントＩＤ等の識別情報は、説明で用いる参照符号と一致するものとする。例えば、登録デバイスＩＤが「２０」であるデバイスは、スマートフォン２０を示す。

「ユーザＩＤ」は、アカウントを利用するユーザを識別するために用いられる識別情報である。例えば、ユーザＩＤは、第１のサービスにおいてユーザがアカウントを作成する際にユーザによって選択される任意の文字列によって構成される。なお、ユーザＩＤは、例えば登録デバイスであるスマートフォン２０に登録されるメールアドレス等が利用されてもよい。

「認証情報」は、第１のサービスにログインするために用いられる認証情報を示す。図５に示した例では、認証情報は、ユーザＵ０１が任意に設定する文字列によって構成されるパスワードであるものとする。例えば、ユーザは、アカウントに対応付けられたユーザＩＤとパスワードのペアを入力して、第１のサービスにログインする。

「第１サービス行動履歴」は、第１のサービスにおける行動履歴を示す。「利用ログＩＤ」は、ユーザが第１のサービスを利用するためにログインした際のログを識別するための識別情報を示す。図５に示す例では、利用ログＩＤは、ユーザが第１のサービスにログインしてからログアウトするまでの１つのセッションごとに付与されるものとする。

「行動履歴」は、ユーザの行動履歴を示す。なお、図５では図示を省略しているが、行動履歴の項目には、例えばユーザがポータルサイト内の記事をクリックした行動や、商品を購買した行動や、クエリを入力して検索を行なった行動など、具体的な行動が記憶されてもよい。

「行動日時」は、ユーザの行動履歴に対応する日時を示す。図５に示した例では、行動日時は、１０分ごとに記憶されることを示しているが、行動日時は、より細かい単位（１分や１秒など）で記憶されてもよい。「位置情報」は、行動履歴に対応する位置情報を示す。例えば、リカバリ装置１００は、ユーザが第１のサービスにログインした時点や、ログインを継続している間、継続的に第１端末（スマートフォン２０）が検知する位置情報を取得し、行動履歴と対応付けて第１サービス情報記憶部１２１に記憶する。なお、図５では、位置情報の項目に「Ｇ０１１」といった概念的な情報が記憶される例を示しているが、実際には、位置情報の項目には、経度や緯度などの具体的な数値や、位置情報を推定することが可能な情報（例えば、スマートフォン２０のＩＰアドレス等）等が記憶される。

すなわち、図５の例では、アカウントＩＤ「Ａ０１」で識別されるアカウントＡ０１には、登録デバイスＩＤ「２０」で識別されるデバイスであるスマートフォン２０が登録されており、登録ユーザは「Ｕ０１」であることを示している。また、アカウントＡ０１に対応するユーザＩＤは「ＸＸＸＸ」であり、認証情報（パスワード）は「ＹＹＹＹ」であることを示している。また、アカウントＡ０１には、利用ログＩＤ「Ｂ０１」や「Ｂ０２」で識別されるログが蓄積されており、例えば、利用ログＢ０１では、行動履歴として「ログイン」が、「２０１７年３月１日１２：００」に行われており、その時点のスマートフォン２０の位置情報が「Ｇ０１１」であることを示している。

（検証情報記憶部１２２について）
検証情報記憶部１２２は、ユーザの本人性の検証に用いる情報（すなわち、第２情報）を記憶する。ここで、図６に、実施形態に係る検証情報記憶部１２２の一例を示す。図６は、実施形態に係る検証情報記憶部１２２の一例を示す図である。図６に示した例では、検証情報記憶部１２２は、「検証対象ユーザ」、「第２情報」といった項目を有する。また、第２情報の項目は、「第２情報ログＩＤ」、「行動日時」、「位置情報」といった小項目を有する。

「検証対象ユーザ」は、リカバリ処理において本人性が検証される対象となるユーザを示す。なお、図６の例では、検証対象ユーザを「Ｕ０１」といった参照符号で示しているが、検証対象ユーザは、図５に示したユーザＩＤ等を用いて示されてもよい。

「第２情報」は、第１のサービスの行動履歴との照合に用いられる、第１のサービス以外において取得されたユーザの行動履歴を示す。「第２情報ログＩＤ」は、第２情報である各々の行動履歴（ログ）を識別する識別情報を示す。「行動日時」は、各ログに対応する日時を示す。「位置情報」は、第２情報の一例である位置情報を示す。なお、図５と同様に、図６における位置情報を「Ｈ０１１」のような概念で示す。なお、図５に示した位置情報と、図６に示した位置情報とは、異なるデバイスによって取得される情報であるため、ファイルフォーマット等が異なる場合もありうる。しかし、いずれの位置情報も、内包する情報としては、経度や緯度を示す情報であったり、住所を示す情報であったりすることから、リカバリ装置１００が、両者の一致や類似を判定することは可能であるものとする。

すなわち、図６の例では、検証対象ユーザ「Ｕ０１」を検証するために取得された第２情報を示している。例えば、第２情報ログＩＤ「Ｃ０１」で識別される第２情報ログＣ０１は、「２０１７年３月１日１２：００」における第２情報（行動履歴）であり、位置情報「Ｈ０１１」であることを示している。

なお、図６の例では、第２情報の一例として位置情報を示しているが、第２情報は位置情報に限られない。例えば、第２情報は、第２端末が取得可能な種々の情報や、第２のサービスにおいて取得される種々の情報であってもよい。これら第２情報のバリエーションに関して、詳しくは後述する。

（定義情報記憶部１２３について）
定義情報記憶部１２３は、検証手法に関する定義を記憶する。ここで、図７に、実施形態に係る定義情報記憶部１２３の一例を示す。図７は、実施形態に係る定義情報記憶部１２３の一例を示す図である。図７に示した例では、定義情報記憶部１２３は、「定義情報ＩＤ」、「検証レベル」、「検証情報」、「検証内容」といった項目を有する。

「定義情報ＩＤ」は、定義情報を識別するための識別情報を示す。なお、定義情報とは、ユーザを検証するための情報の種別や、検証手法や、ある検証手法でユーザを検証した場合の信頼性を示すレベルを定義した情報である。定義情報は、ユーザの本人性を検証し、ユーザを本人として認証するための条件と読み替えることもできる。

「検証レベル」は、ユーザの本人性の検証に関する信頼性を示すレベルである。実施形態では、検証レベルは、５段階の数値で示されるものとし、「５」が最も信頼性が高く、「１」が最も信頼性が低いものとする。例えば、リカバリ装置１００は、リカバリしようとするアカウントの種別に応じて、どのような検証レベルでユーザを検証するかを判定してもよい。一例として、第１のサービスが金融機関等の提供するサービスであり、リカバリに関して極めて高い信頼性が要求される場合には、リカバリ装置１００は、検証レベルが「５」と定義された検証手法を用いてユーザを検証されない限り、リカバリを実行しないと判定してもよい。一方、第１のサービスが高い信頼性を要求するサービスでない場合には、リカバリ装置１００は、検証レベルが「３」と定義された検証手法を用いてユーザを検証した場合であっても、アカウントのリカバリを実行してもよい。すなわち、リカバリ装置１００は、リカバリに際して要求される信頼性のレベルに応じて、異なる検証手法によってユーザを検証するようにしてもよい。例えば、検証に用いる情報の種別を増加させたり、照合させる情報を増加させたりするほど、定義される検証レベルは高くなるものとする。

「検証情報」は、ユーザの検証に用いる第１情報及び第２情報の種別を示す。「検証内容」は、ユーザの検証において第１情報と第２情報とを照合する際に、どのような条件を満たせばユーザの本人性が検証されるかを定義付けた内容を示す。

すなわち、図７の例では、定義情報ＩＤ「Ｅ０１」で識別される定義情報は、検証レベルが「３」の検証手法に関する定義を示したものであることを示している。定義情報Ｅ０１とは、具体的な検証手法として、検証情報として「位置情報」を用いるものであり、検証内容として「任意の３時点の位置情報の一致」を判定するものであることを示している。具体的には、定義情報Ｅ０１では、第１情報と第２情報とを照合した場合に「任意の３時点の位置情報の一致」がみられた場合には、リカバリを要求したユーザがアカウントに登録されていたユーザ本人であると検証される、ということを示している。

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

図４に示すように、制御部１３０は、受信部１３１と、第１取得部１３２と、特定部１３３と、第２取得部１３４と、検証部１３５と、実行部１３６と、送信部１３７とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部１３０の内部構成は、図４に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部１３０が有する各処理部の接続関係は、図４に示した接続関係に限られず、他の接続関係であってもよい。

（受信部１３１について）
受信部１３１は、各種情報を受信する。例えば、受信部１３１は、ユーザ端末１０の一例であるスマートフォン２０から、リカバリ装置１００へのリカバリの要求を受信する。

また、受信部１３１は、リカバリの要求に対応するアカウントを特定する情報を受信する。例えば、受信部１３１は、アカウントを特定するための情報であるユーザＩＤを受信する。受信部１３１は、受信した情報を第１取得部１３２に送る。

（第１取得部１３２について）
第１取得部１３２は、第１のサービスにおけるユーザの行動履歴に関する情報である第１情報を取得する。

具体的には、第１取得部１３２は、受信部１３１によってリカバリの要求が受信された場合に、第１サービス情報記憶部１２１に蓄積されている第１情報のうち、当該ユーザに関する第１情報を取得する。なお、第１取得部１３２は、第１のサービスを提供する提供者がリカバリ装置１００でない場合には、第１のサービスを提供する提供者（サービスサーバ）から第１情報を取得してもよい。この場合、第１取得部１３２は、スマートフォン２０を利用するユーザのアカウントを特定し、特定したユーザに関する第１情報をサービスサーバから取得する。

例えば、第１取得部１３２は、第１情報として、ユーザが第１のサービスにログインした日時等の日時情報や、ログインした時点やログインしている間のユーザの位置情報を取得する。

また、第１取得部１３２は、第１のサービスが提供するサービスの種別に応じて、様々な第１情報を取得してもよい。例えば、第１取得部１３２は、第１のサービスがショッピングサービスやオークションサービスである場合には、第１情報として、ユーザの購買情報や決済情報等を取得してもよい。なお、第１取得部１３２は、商品を購買したユーザの住所情報や、受付に対して商品が配送される日時等の情報をさらに取得してもよい。

また、第１取得部１３２は、第１のサービスがニュースサービス等の情報提供サービスである場合、第１情報として、コンテンツの閲覧情報や、コンテンツの検索情報等を取得してもよい。

また、第１取得部１３２は、第１のサービスが旅行予約サービスや、交通機関の乗換案内サービス等である場合、ユーザが予約した施設や日時の情報等を取得してもよい。また、第１取得部１３２は、第１のサービスがＳＮＳ（Social Networking service）である場合、第１情報として、ユーザがテキスト（例えばツイート等）を投稿した日時や、投稿の内容や、投稿した画像等を含む投稿情報を取得してもよい。

また、第１取得部１３２は、ユーザが第１のサービスを利用する際に第１のサービス側に取得される情報を第１情報として取得してもよい。例えば、第１取得部１３２は、第１のサービスへの通信接続情報（スマートフォン２０が利用するアクセスポイントに関する情報や、第１のサービスの利用に用いるデバイスのデバイスＩＤ等）や、ユーザの属性情報（ユーザの性別や年齢等）を取得してもよい。

（特定部１３３について）
特定部１３３は、ユーザから取得する第２情報を特定する。例えば、特定部１３３は、第２情報として取得する情報の種別を特定する。

具体的には、特定部１３３は、リカバリを要求したユーザの本人性を検証する処理において、当該ユーザに対応する第１情報と照合可能な情報を特定する。例えば、特定部１３３は、第１のサービスにおいて当該ユーザから位置情報が取得されている場合には、第２情報として位置情報が取得されることにより、第１情報と第２情報とを照合可能であると判定する。この場合、特定部１３３は、取得すべき第２情報の種別を「位置情報」と特定する。

なお、特定部１３３は、第１のサービスにおいて取得された第１情報の種別に応じて、様々な種別の情報を、取得すべき第２情報として特定してもよい。例えば、特定部１３３は、上記した決済情報や、コンテンツの閲覧情報や、検索情報や、予約情報や、ＳＮＳ投稿情報や、通信接続情報や、ユーザの属性情報等を、取得すべき第２情報として特定する。また、特定部１３３は、必ずしも第１情報と同じ種別の情報を第２情報として特定しなくてもよい。例えば、特定部１３３は、第１情報と第２情報の種別が異なる場合であっても、異なる種別の情報がユーザにおける共通した所定の行動を示すことにより、ユーザの本人性を検証できるのであれば、第１情報とは異なる種別の情報を特定してもよい。

（第２取得部１３４について）
第２取得部１３４は、第１情報以外の情報であって、ユーザの行動履歴に関する情報である第２情報を取得する。例えば、第２取得部１３４は、リカバリの要求を送信した第１端末に対して本人確認要求を送信するとともに、特定部１３３によって特定された種別に関する情報を送信する。そして、第２取得部１３４は、第２端末や、第２のサービスを介して第２情報を取得した第１端末から、第２情報を取得する。

第２取得部１３４は、第２情報として、第１のサービスの提供者以外の提供者から提供されるサービスである第２のサービスにおける、ユーザの行動履歴に関する情報を取得する。

具体的には、第２取得部１３４は、第２情報として、第１のサービスの利用において用いられる端末装置（第１端末）以外の他端末（第２端末）によって取得された、ユーザの行動履歴に関する情報を取得する。図１に示した例では、第２取得部１３４は、第２情報として、第２端末であるウェアラブルデバイス３０に蓄積されたユーザＵ０１の行動履歴を取得する。なお、図２に示したように、第２取得部１３４は、第２端末からではなく、第２のサービスを提供する第２サービス提供サーバ２００等から第２情報を取得してもよい。

第２取得部１３４は、第２情報として、第１情報と同様に様々な種別の情報を取得してもよい。例えば、第２取得部１３４は、位置情報、決済情報、コンテンツの閲覧情報、検索情報、予約情報、ＳＮＳ投稿情報、通信接続情報、及びユーザの属性情報の少なくともいずれか一つを取得する。

第２取得部１３４は、取得した第２情報を検証情報記憶部１２２に格納する。なお、第２取得部１３４は、取得した第２情報の全てを検証情報記憶部１２２に格納してもよいし、特定部１３３によって特定された種別の第２情報のみを検証情報記憶部１２２に格納してもよい。

（検証部１３５について）
検証部１３５は、第１取得部１３２によって取得された第１情報と、第２取得部１３４によって取得された第２情報との照合に基づいて、ユーザの本人性を検証する。

例えば、検証部１３５は、第１情報と第２情報とで共通する種別の情報を抽出し、抽出した情報同士の一致度もしくは類似度に基づいて、ユーザの本人性を検証する。

具体的には、検証部１３５は、定義情報記憶部１２３に記憶されている定義情報に従って、ユーザの本人性を検証する。例えば、検証部１３５は、リカバリしようとするアカウントに要求される検証レベルを参照する。検証部１３５は、例えば第１のサービスの提供者によって予め設定された検証レベルを参照することで、リカバリしようとするアカウントの検証レベルを特定する。なお、検証部１３５は、リカバリしようとするアカウントに検証レベルが設定されていない場合には、任意に選択したいずれかの定義情報に基づいてユーザを検証するようにしてもよい。

以下に、検証部１３５が、図７に示す定義情報Ｅ０１を用いてユーザの本人性を検証する場合について例示する。検証部１３５は、第１情報のうち、任意の３時点の位置情報を抽出する。また、検証部１３５は、第２情報のうち、第１情報から抽出された３時点に対応する時点の位置情報を特定する。なお、検証部１３５は、第１情報と第２情報の時点が完全に一致しなくとも、例えば所定範囲内（例えば１分以内など）の時点の第２情報（行動履歴）を抽出するなど、柔軟に処理を行ってもよい。

そして、検証部１３５は、抽出された３時点における位置情報の一致を検証する。具体的には、検証部１３５は、抽出された時点において、第１情報の位置情報が示す位置と、第２情報の位置情報が示す位置とが、所定範囲内で一致するか否かを検証する。そして、検証部１３５は、検証した３時点において、位置情報の示す位置が一致している場合には、リカバリを要求したユーザが、当該アカウントを保持していたユーザ本人であると判定する。なお、位置情報は、完全に一致した位置を示すものでなくとも、所定の類似範囲であればよい。かかる類似範囲は、例えば、予め設定された所定範囲や所定距離内であるか否か等によって柔軟に判定されてもよい。

また、上記では、位置情報を３時点で照合する例を示したが、検証部１３５は、時点で照合を行うのではなく、ある時間長における位置情報を照合してもよい。例えば、検証部１３５は、ある過去の１０分間における位置情報の推移について、第１情報と第２情報とを照合してもよい。

上記のように、比較する情報が位置情報である場合、検証部１３５は、第１情報と第２情報とに含まれる位置情報を抽出し、所定数もしくは所定の時間長における位置情報同士の一致度もしくは類似度に基づいて、ユーザの本人性を検証する。

また、検証部１３５は、第１情報と第２情報とから互いに異なる種別の情報を抽出し、抽出した異なる種別の情報が、ユーザにおける共通した所定の行動を示すか否かに基づいて、ユーザの本人性を検証してもよい。

例えば、検証部１３５は、第１情報の購買情報と、第２情報の位置情報とを抽出し、ユーザにおける共通した所定の行動を示すか否かに基づいて、ユーザの本人性を検証してもよい。具体的には、検証部１３５は、第１のサービスにおけるユーザの購買履歴に含まれる、当該商品の配送日時及び配送先を参照する。また、検証部１３５は、第２情報のうち、当該商品が配送される日時におけるユーザの位置情報を参照する。そして、検証部１３５は、当該商品の配送先が示す位置と、当該商品が配送される日時におけるユーザの位置情報とが一致するか否かを判定する。

検証部１３５は、かかる情報が一致する場合、第１のサービスにおいて商品を購入したユーザは、当該商品を配送先で受け取ったユーザである蓋然性が高いと判定する。すなわち、検証部１３５は、第１情報と第２情報とにおいて、情報の種別は異なるものの、それらの情報が、ユーザにおける共通した所定の行動を示すと判定される場合には、当該ユーザを本人であると検証することができる。かかる処理を介して、検証部１３５は、ユーザの本人性を検証する。なお、これらの照合に関する情報（いずれの情報を比較するか、あるいは、どのような情報が比較対象となりうるかといった情報など）については、予め保持した定義情報に記載されてもよいし、リカバリ装置１００の管理者等によって適宜入力されてもよい。

検証部１３５は、種々の情報に基づいて検証を行ってもよい。具体的には、検証部１３５は、第１情報及び第２情報の種別として、位置情報、決済情報、コンテンツの閲覧情報、検索情報、予約情報、ＳＮＳ投稿情報、通信接続情報、ユーザの属性情報の少なくともいずれか一つを用いて、ユーザの本人性を検証してもよい。

また、検証部１３５は、照合した１つだけの情報でなく、複数の情報の照合結果に基づいて、ユーザの本人性を検証してもよい。すなわち、検証部１３５は、共通する所定時間の行動履歴を示す第１情報と第２情報とを一つの組として、少なくとも２以上の組における照合に基づいて、ユーザの本人性を検証してもよい。このように、検証部１３５は、多要素情報に基づいて本人性を検証することで、検証の精度を向上させることができる。

また、検証部１３５は、ユーザによって選択された種別の第１情報と第２情報との照合に基づいてユーザの本人性を検証してもよい。例えば、受信部１３１は、リカバリの要求を受信した場合に、どのような情報で検証を行うかといった選択をユーザに委ねてもよい。例えば、ユーザは、検証に用いる情報のうち、自身がリカバリ装置１００に送信することが可能な情報の種別を選択するようにしてもよい。具体的には、ユーザは、位置情報を取得可能なウェアラブルデバイス３０を所有している場合には、情報の種別として「位置情報」を選択してもよい。これにより、検証部１３５は、ユーザの要望に沿った検証処理を行うことができる。具体的には、検証部１３５は、ユーザがリカバリ装置１００に提供し易い情報を優先的に用いて検証処理を行うことで、ユーザの負担を軽減することができる。

なお、検証部１３５は、上記したような類似や一致の判定の設定等については、人為的に設定を受け付けてもよいし、例えば、どの時間帯の範囲のデータ同士を照合するのかを決定する照合データ範囲の導出機能を備えていてもよい。例えば、位置情報が照合処理に用いられる場合、第１情報と第２情報において、どの時刻における緯度や経度情報が近似するのかを特定することは困難な場合がある。また、完全に同時刻の位置情報が第１情報と第２情報との双方で存在していたとしても、検知される情報の精度はデバイスの機能や性能等に依存するため、双方の位置情報が完全に一致する可能性は低い。このため、検証部１３５は、どの時間帯の範囲におけるデータ同士を照合するか、あるいは、どのくらいの誤差を許容するかといった、照合データ範囲の導出を行い、照合しようとするデータの抽出を適切に行うようにしてもよい。

また、検証部１３５は、例えば、ウェアラブルデバイス３０から取得したアクセストークンに基づいて取得する第２情報の範囲についても、上記のように、適宜、設定を行ってもよい。例えば、検証部１３５は、図５に示したように、ユーザＵ０１の位置情報として位置情報Ｇ０１１や位置情報Ｇ０１２や位置情報Ｇ０１３が保持されている場合には、第２サービス提供サーバ２００へのアクセストークンを取得した場合には、上記の位置情報に対応する時間帯の範囲の位置情報を取得すること等を決定してもよい。

また、検証部１３５は、照合するデータを曖昧化や概念化したうえで、互いのデータを照合する処理を行ってもよい。位置情報を例として挙げると、検証部１３５は、所定の幅のある時間間隔(time window)の中でのある位置情報を、例えば所定の地域（市町村など）を示す住所情報等に曖昧化してもよい。そして、検証部１３５は、第１情報と第２情報において、市町村などの所定の地域を示す情報が一致する場合に、双方の位置情報が一致したと判定してもよい。このような情報の曖昧化を行うことにより、検証部１３５は、必ずしも完全に一致する情報のみならず、所定の許容範囲内において、第１情報と第２情報についての照合処理を行うことができる。

（実行部１３６について）
実行部１３６は、検証部１３５によってユーザの本人性が検証された場合に、第１のサービスにおいてユーザが有していたアカウントのリカバリを実行する。

例えば、実行部１３６は、検証部１３５が定義情報において定義された条件が満たされたことを検証した場合に、ユーザの本人性が検証されたと判定し、当該ユーザが有していたアカウントのリカバリを実行する。

また、実行部１３６は、検証部１３５によってユーザの本人性が検証されなかった場合にはアカウントのリカバリを実行しない。この場合、実行部１３６は、リカバリが失敗した旨を送信部１３７に送り、リカバリが失敗した旨の通知をユーザに送信させてもよい。

（送信部１３７について）
送信部１３７は、各種情報を送信する。例えば、送信部１３７は、実行部１３６によるアカウントのリカバリの結果を、リカバリを要求したユーザに送信する。また、送信部１３７は、アカウントのリカバリを実行した旨を送信する場合には、例えば新たな認証情報に関わる情報（例えば、パスワードの再設定に関する通知など）をあわせて送信してもよい。

また、送信部１３７は、アカウントのリカバリが実行されなかった旨を送信する場合には、例えば、リカバリに要する第２情報が不足していたこと等を通知する旨をあわせて送信してもよい。また、送信部１３７は、新たな第２情報をユーザが送信した場合にアカウントのリカバリが実行される可能性がある場合には、検証に要する第２情報を新たに送信することの要求をユーザに送信してもよい。

〔４．ユーザ端末の構成〕
次に、図８を用いて、実施形態に係るユーザ端末１０の構成について説明する。図８は、実施形態に係るユーザ端末１０の構成例を示す図である。図８に示すように、ユーザ端末１０は、通信部１１と、入力部１２と、表示部１３と、検知部１４と、記憶部１５と、制御部１６とを有する。なお、実施形態に係るユーザ端末１０は、例えばスマートフォン２０やウェアラブルデバイス３０が該当する。ただし、ユーザ端末１０は、必ずしも図８に示す全ての構成を備えていなくてもよい。例えば、ウェアラブルデバイス３０は、液晶ディスプレイ等の表示部を必ずしも備えていなくてもよい。

（通信部１１について）
通信部１１は、例えば、ＮＩＣ等によって実現される。かかる通信部１１は、ネットワークＮと有線又は無線で接続され、ネットワークＮを介して、リカバリ装置１００や、第２サービス提供サーバ２００や、任意のデバイス等との間で情報の送受信を行う。

（入力部１２及び表示部１３について）
入力部１２は、ユーザから各種操作を受け付ける入力装置である。例えば、入力部１２は、ユーザ端末１０に備えられた操作キー等によって実現される。表示部１３は、各種情報を表示するための表示装置である。例えば、表示部１３は、液晶ディスプレイ等によって実現される。なお、ユーザ端末１０にタッチパネルが採用される場合には、入力部１２の一部と表示部１３とは一体化される。

（検知部１４について）
検知部１４は、ユーザ端末１０に関する各種情報を検知する。具体的には、検知部１４は、ユーザ端末１０に対するユーザの操作や、ユーザ端末１０の所在する位置情報や、ユーザ端末１０と接続されている機器に関する情報や、ユーザ端末１０における環境等を検知する。

例えば、検知部１４は、入力部１２に入力された情報に基づいて、ユーザの操作を検知する。すなわち、検知部１４は、入力部１２に画面をタッチする操作の入力があったことや、音声の入力があったこと等を検知する。また、検知部１４は、ユーザによって所定のアプリケーションプログラム（以下、単に「アプリ」と表記する）が起動されたことを検知してもよい。かかるアプリがユーザ端末１０内の撮像機能（例えば、カメラ）を動作させるアプリである場合、検知部１４は、ユーザによって撮像機能が利用されていることを検知する。また、検知部１４は、ユーザ端末１０内に備えられた加速度センサやジャイロセンサ等で検知されたデータに基づき、ユーザ端末１０自体が動かされているといった操作を検知してもよい。

また、検知部１４は、ユーザ端末１０の現在位置を検知する。具体的には、検知部１４は、ＧＰＳ（Global Positioning System）衛星から送出される電波を受信し、受信した電波に基づいてユーザ端末１０の現在位置を示す位置情報（例えば、緯度及び経度）を取得する。

また、検知部１４は、種々の手法により位置情報を取得してもよい。例えば、ユーザ端末１０が駅改札や商店等で使用される非接触型ＩＣカードと同等の機能を備えている場合（もしくは、ユーザ端末１０が非接触型ＩＣカードの履歴を読み取る機能を備えている場合）、ユーザ端末１０によって駅での乗車料金の決済等が行われた情報とともに、使用された位置が記録される。検知部１４は、かかる情報を検知し、位置情報として取得する。また、検知部１４は、ユーザ端末１０が特定のアクセスポイントと通信を行う際には、アクセスポイントから取得可能な位置情報を検知してもよい。また、位置情報は、ユーザ端末１０が備える光学式センサや、赤外線センサや、磁気センサ等によって取得されてもよい。また、ＩＰアドレス等によってユーザ端末１０の位置を推定可能な場合には、検知部１４は、位置情報の一例として、ＩＰアドレス等を取得してもよい。

また、検知部１４は、ユーザ端末１０に接続される外部装置を検知する。なお、外部装置とは、対象となるユーザ端末１０以外の装置であり、対象とは異なる他のユーザ端末１０が含まれてもよい。例えば、スマートフォン２０からみた場合、ウェアラブルデバイス３０は、外部装置として認識される。

検知部１４は、例えば、外部装置との相互の通信パケットのやり取りや、外部装置が発する信号等に基づいて、外部装置を検知する。具体的には、検知部１４は、外部装置が利用しているＷｉｆｉやＢｌｕｅｔｏｏｔｈ等の電波を検知する。また、検知部１４は、外部装置と通信が確立する場合に、外部装置との接続の種類を検知してもよい。例えば、検知部１４は、外部装置と有線で接続されているか、無線通信で接続されているかを検知する。また、検知部１４は、無線通信で用いられている通信方式等を検知してもよい。また、検知部１４は、外部装置が発する電波を検知する電波センサや、電磁波を検知する電磁波センサ等によって取得される情報に基づいて、外部装置を検知してもよい。

また、検知部１４は、ユーザ端末１０における環境を検知する。検知部１４は、ユーザ端末１０に備えられた各種センサや機能を利用し、環境に関する情報を検知する。例えば、検知部１４は、ユーザ端末１０の周囲の音を収集するマイクロフォンや、ユーザ端末１０の周囲の照度を検知する照度センサや、ユーザ端末１０の物理的な動きを検知する加速度センサ（又は、ジャイロセンサなど）や、ユーザ端末１０の周囲の湿度を検知する湿度センサや、ユーザ端末１０の所在位置における磁場を検知する地磁気センサ等を利用する。そして、検知部１４は、各種センサを用いて、種々の情報を検知する。例えば、検知部１４は、ユーザ端末１０の周囲における騒音レベルや、ユーザ端末１０の周囲がユーザの虹彩を撮像に適する照度であるか等を検知する。さらに、検知部１４は、カメラで撮影された写真や映像に基づいて周囲の環境情報を検知してもよい。

また、ユーザ端末１０は、検知部１４によって検知された情報に基づいて、ユーザ端末１０のコンテキスト（context）を示すコンテキスト情報を取得するようにしてもよい。上述のように、ユーザ端末１０は、内蔵された各種センサ（検知部１４）により、位置、加速度、温度、重力、回転（角速度）、照度、地磁気、圧力、近接、湿度、回転ベクトルといった、種々の物理量をコンテキスト情報として取得する。また、ユーザ端末１０は、内蔵する通信機能を利用して、各種装置との接続状況（例えば、通信の確立に関する情報や、利用している通信規格）などを、コンテキスト情報として取得してもよい。

（記憶部１５について）
記憶部１５は、各種情報を記憶する。記憶部１５は、例えば、ＲＡＭ、フラッシュメモリ等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。

例えば、記憶部１５は、検知部１４によって検知された位置情報等を、検知された日時と対応付けて記憶する。また、記憶部１５は、第１のサービスや第２のサービスに関する利用履歴や、第１のサービスや第２のサービスにおけるユーザの行動履歴等を記憶してもよい。

（制御部１６について）
制御部１６は、コントローラであり、例えば、ＣＰＵやＭＰＵ等によって、ユーザ端末１０内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１６は、コントローラであり、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現される。

図８に示すように、制御部１６は、取得部１６１と、受信部１６２と、送信部１６３とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部１６の内部構成は、図８に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。

（取得部１６１について）
取得部１６１は、各種情報を取得する。例えば、取得部１６１は、検知部１４によって検知された各種情報を取得する。

（受信部１６２について）
受信部１６２は、各種情報を受信する。例えば、受信部１６２は、アカウントのリカバリの要求を受け付けた旨の通知をリカバリ装置１００から受信する。また、受信部１６２は、第２情報をリカバリ装置１００に送信する旨の通知を受信する。また、受信部１６２は、リカバリ装置１００によるリカバリの結果を受信する。

送信部１６３は、各種情報を送信する。例えば、送信部１６３は、ユーザの操作に従って、第１のサービスにおけるアカウントのリカバリの要求をリカバリ装置１００に送信する。また、送信部１６３は、リカバリするアカウントを特定するための情報（ユーザＩＤ等）をリカバリ装置１００に送信する。また、送信部１６３は、アカウントのリカバリが行われた場合には、リカバリされたアカウントに新たに設定する認証情報（パスワード等）をリカバリ装置１００に送信する。

〔５．第２サービス提供サーバの構成〕
次に、図９を用いて、実施形態に係る第２サービス提供サーバ２００の構成について説明する。図９は、実施形態に係る第２サービス提供サーバ２００の構成例を示す図である。図９に示すように、第２サービス提供サーバ２００は、通信部２１０と、記憶部２２０と、制御部２３０とを有する。なお、以下の説明では、第２サービス提供サーバ２００とリカバリ装置１００とにおいて共通する構成については説明を省略する。

（第２サービス情報記憶部２２１について）
第２サービス情報記憶部２２１は、第２のサービスに関する情報を記憶する。ここで、図１０に、実施形態に係る第２サービス情報記憶部２２１の一例を示す。図１０は、実施形態に係る第２サービス情報記憶部２２１の一例を示す図である。図１０に示した例では、第２サービス情報記憶部２２１は、「第２サービスアカウントＩＤ」、「登録デバイスＩＤ」、「登録ユーザ」、「第２サービス行動履歴」といった項目を有する。また、第２サービス行動履歴の項目は、「第２情報ログＩＤ」、「行動日時」、「位置情報」といった小項目を有する。

「第２サービスアカウントＩＤ」は、第２のサービスにおけるアカウントを識別する識別情報を示す。「登録デバイスＩＤ」は、第２のサービスに利用するデバイスとして登録されているデバイスを識別する識別情報を示す。「登録ユーザ」は、アカウントを保持するユーザを示す。「第２サービス行動履歴」は、第２のサービスにおける行動履歴を示す。なお、実施形態では、第２サービス提供サーバ２００は、ウェアラブルデバイス３０と連動して、ユーザの位置情報を蓄積したり、ユーザの一日の行動量を分析したりする第２のサービスを提供するものとする。

すなわち、図１０の例では、第２サービスアカウントＩＤ「Ｆ０１」で識別されるアカウントＦ０１には、登録デバイスＩＤ「３０」で識別されるデバイスであるウェアラブルデバイス３０が登録されており、登録ユーザは「Ｕ０１」であることを示している。また、第２情報ログＩＤ「Ｃ０１」で識別される第２情報（行動履歴）は、「２０１７年３月１日１２：００」において、その時点のウェアラブルデバイス３０の位置情報が「Ｈ０１１」であることを示している。

（制御部２３０について）
制御部２３０は、例えば、コントローラであり、ＣＰＵやＭＰＵ等によって、第２サービス提供サーバ２００内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部２３０は、コントローラであり、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現される。

図９に示すように、制御部２３０は、受信部２３１と、取得部２３２と、送信部２３３とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部２３０の内部構成は、図９に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部２３０が有する各処理部の接続関係は、図９に示した接続関係に限られず、他の接続関係であってもよい。

（受信部２３１について）
受信部２３１は、各種情報を受信する。例えば、受信部２３１は、ユーザ端末１０の一例であり、また、第２端末の一例であるウェアラブルデバイス３０から、第２のサービスの利用に関する要求を受信する。具体的には、受信部２３１は、第２のサービスに関するアカウントの作成要求や、アカウントへのログイン要求を受信する。例えば、受信部２３１は、ウェアラブルデバイス３０から送信されるデバイスＩＤ等に基づいて、アカウントへのログイン要求を受け付ける。

また、受信部２３１は、第２サービス情報記憶部２２１へのアクセス許可を求める要求を受信する。例えば、受信部２３１は、ユーザから送信される要求であって、第２サービスに関する情報へアクセスするためのアクセストークンの発行を求める要求を受信する。

（取得部２３２について）
取得部２３２は、各種情報を取得する。例えば、取得部２３２は、第２のサービスを利用するユーザ端末１０から第２情報を取得する。具体的には、取得部２３２は、第２情報として、ウェアラブルデバイス３０等が検知する位置情報を定期的に取得する。また、取得部２３２は、第２情報として、第２のサービスを利用するユーザの行動履歴を適宜取得する。

（送信部２３３について）
送信部２３３は、各種情報を送信する。例えば、送信部２３３は、ユーザからアクセストークンの発行を求める要求を受信した場合には、要求に対応するアクセストークンを送信する。例えば、アクセストークンは、第２サービス情報記憶部２２１に蓄積される第２情報のうち、要求を送信したユーザに対応する第２情報にアクセスすることを可能とする一時的に有効なトークンである。アクセストークンを取得したリカバリ装置１００は、第２サービス提供サーバ２００にアクセスし、検証処理に利用する第２情報を取得する。

なお、リカバリ装置１００が第２情報を取得する手法は、上記のようなアクセストークンを用いた処理に限られない。例えば、リカバリ装置１００は、第２サービス提供サーバ２００に第２情報に関する利用の要求を送信してもよい。また、送信部２３３は、かかる要求に応答して、リカバリ装置１００に第２情報を送信してもよい。

〔６．処理手順〕
次に、図１１及び図１２を用いて、実施形態に係るリカバリ処理の手順について説明する。まず、図１１を用いて、リカバリ装置１００に関する処理の手順について説明する。図１１は、実施形態に係るリカバリ装置１００の処理手順を示すフローチャートである。

図１１に示すように、リカバリ装置１００は、第１端末からアカウントのリカバリの要求を受信したか否かを判定する（ステップＳ１０１）。リカバリの要求を受信していない場合（ステップＳ１０１；Ｎｏ）、リカバリ装置１００は、リカバリの要求を受信するまで待機する。

一方、リカバリの要求を受信した場合（ステップＳ１０１；Ｙｅｓ）、リカバリ装置１００は、リカバリするアカウントを特定するための情報（例えば、当該アカウントに対応するユーザＩＤ）を取得する（ステップＳ１０２）。

続けて、リカバリ装置１００は、リカバリしようとするアカウントにおける第１情報を取得する（ステップＳ１０３）。リカバリ装置１００は、取得した第１情報に基づいて、検証に用いる情報の種別（例えば、位置情報等）を特定する（ステップＳ１０４）。

その後、リカバリ装置１００は、第１端末に対して本人確認要求を送信する（ステップＳ１０５）。なお、本人確認要求とは、特定した第２情報の種別に関する情報と、第２情報をリカバリ装置１００側に送信するよう要求する旨の通知とを含む。すなわち、第１端末は、かかる要求を受信することで、リカバリ装置１００に送信すべき第２情報を特定する。

そして、リカバリ装置１００は、検証に用いることのできる第２情報を取得したか否かを判定する（ステップＳ１０６）。検証に用いることのできる第２情報を取得していない場合（ステップＳ１０６；Ｎｏ）、リカバリ装置１００は、第２情報を取得するまで待機する。

一方、検証に用いることのできる第２情報を取得した場合（ステップＳ１０６；Ｙｅｓ）、リカバリ装置１００は、定義情報に従い、第１情報と第２情報とを照合する（ステップＳ１０７）。

リカバリ装置１００は、照合の結果に基づいて、ユーザの本人性が検証されたか否かを判定する（ステップＳ１０８）。ユーザの本人性が検証された場合（ステップＳ１０８；Ｙｅｓ）、リカバリ装置１００は、アカウントのリカバリを実行する（ステップＳ１０９）。一方、ユーザの本人性が検証されなかった場合（ステップＳ１０８；Ｎｏ）、リカバリ装置１００は、アカウントのリカバリを実行しない（ステップＳ１１０）。そして、リカバリ装置１００は、ステップＳ１０９又はステップＳ１１０の結果をユーザに送信する（ステップＳ１１１）。

次に、図１２を用いて、ユーザ端末１０のうち第１端末に関する処理の手順について説明する。図１２は、実施形態に係る第１端末の処理手順を示すフローチャートである。

図１２に示すように、第１端末は、第１のサービスにおけるアカウントのリカバリをリカバリ装置１００に要求する（ステップＳ２０１）。さらに、第１端末は、アカウントを特定するための情報（ユーザＩＤ等）の送信をリカバリ装置１００に要求された場合には、アカウントを特定するための情報をリカバリ装置１００に送信する（ステップＳ２０２）。

その後、第１端末は、リカバリ装置１００から送信された本人確認要求を受信する（ステップＳ２０３）。かかる本人確認要求は、第１端末がリカバリ装置１００に送信すべき第２情報の種別に関する情報を含む。第１端末は、リカバリ装置１００に送信すべき第２情報を取得するため、第２端末へアクセスする（ステップＳ２０４）。

第１端末は、第２情報を取得したか否かを判定する（ステップＳ２０５）。第２情報を取得していない場合（ステップＳ２０５；Ｎｏ）、第１端末は、第２情報を取得するまで待機する。

一方、第２情報を取得した場合（ステップＳ２０５；Ｙｅｓ）、第１端末は、第２情報をリカバリ装置１００に送信する（ステップＳ２０６）。なお、第１端末は、第２情報に代えて、第２情報に対してリカバリ装置１００がアクセス可能とするためのアクセストークン等を取得した場合には、取得したアクセストークン等をリカバリ装置１００に送信してもよい。その後、第１端末は、アカウントのリカバリの結果を受信する（ステップＳ２０７）。

〔７．変形例〕
上述したリカバリ装置１００によるリカバリ処理は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、リカバリ装置１００やリカバリ処理に関する他の実施形態について説明する。

〔７−１．第２情報の取得〕
上記実施形態では、第１端末が、第２端末や第２サービス提供サーバ２００を介して第２情報を取得する例を示した。ここで、第２情報は、第１端末から取得されてもよい。

第１端末がスマートフォン２０である場合について説明する。スマートフォン２０には、第１のサービスを利用するためのアプリ（以下、「第１アプリ」と表記する）と、第２のサービスを利用するためのアプリ（以下、「第２アプリ」と表記する）とがインストールされている。ユーザは、第１アプリを利用して第１のサービスを利用し、第２アプリを利用して第２のサービスを利用しているものとする。なお、第２アプリは、スマートフォン２０の位置情報を定期的に取得する機能を有するアプリであり、図１及び図２で示したウェアラブルデバイス３０と同等の機能を実現するものとする。

ここで、リカバリ要求において、リカバリ装置１００が、スマートフォン２０に本人確認要求を送信し、第２情報の送信を求めたものとする。このとき、スマートフォン２０は、第２アプリの機能によって、スマートフォン２０内部に保持されている情報であって、第２のサービスにおける行動履歴を第２情報として取得する。そして、スマートフォン２０は、第２アプリによって取得された第２情報をリカバリ装置１００に送信する。

すなわち、リカバリ装置１００は、第２情報として、第１のサービスの利用において用いられるスマートフォン２０によって取得された情報であって、第１のサービスの利用において用いられる第１アプリとは異なる第２アプリによって取得された、ユーザの行動履歴に関する情報を取得する。

このように、リカバリ装置１００は、必ずしも第１端末とは異なるデバイスによって取得された情報を第２情報として取得することを要さず、第１端末が、第１のサービスによって利用される第１情報とは異なる情報を取得する機能を備えている場合（この例の場合は第２アプリ）には、第１端末から第２情報を取得してもよい。

なお、上記のようなアプリが利用される態様は、スマートフォン２０やウェアラブルデバイス３０自体にアプリがインストールされる態様に限られない。例えば、ユーザは、スマートフォン２０にインストールされて動作するアプリと同様の処理を実現するようなプログラムであって、ネットワークを介して利用されるプログラムを利用する場合もありうる。具体的には、ユーザは、スマートフォン２０等を利用してネットワークに接続し、ネットワークを介して、所定のサーバに置かれたエミュレータプログラムを操作する場合もありうる。すなわち、実施形態に係るアプリは、必ずしもユーザ端末１０上に存在する態様に限らず、ネットワーク上の所定のサーバ上に置かれたエミュレータプログラム等、ユーザ端末１０上に存在するアプリと同様の処理を実現することができるプログラムであれば、いずれの態様により実現されてもよい。

〔７−２．検証処理〕
リカバリ装置１００は、第１情報と第２情報との一致や類似に基づいて、ユーザの本人性を示すスコアを算出するような処理を行ってもよい。例えば、リカバリ装置１００は、第１情報と第２情報における位置情報が一致した数に応じてスコアを算出する。そして、リカバリ装置１００は、算出したスコアが所定の閾値を超える場合に、ユーザの本人性が検証されたと判定してもよい。この場合、リカバリ装置１００は、位置情報に限らず、種々の情報による照合を行い、総合して算出されたスコアが所定の閾値を超えた場合にユーザの本人性を検証するなど、柔軟な処理を行うようにしてもよい。

〔７−３．デバイス間の協調処理〕
上記実施形態では、第２端末がウェアラブルデバイス３０である例を示した。しかし、第２端末は、複数であってもよい。すなわち、ユーザは、ウェアラブルデバイス３０以外の他端末を利用して第２のサービスを利用している場合や、当該他端末によってユーザの行動履歴（位置情報や、ユーザの身体的な情報や、第２のサービスにおける利用履歴など）が取得されている場合には、他端末を第２端末とみなして、上記実施形態に係る処理を実行してもよい。

また、第２情報は、一つの第２端末から取得される情報に限られず、複数の第２端末から集計された情報であってもよい。第１端末は、複数の第２端末から取得された情報を第２情報として、リカバリ装置１００に送信してもよい。これにより、ユーザは、より多くの手段によって第２情報を取得することができるため、検証に用いる情報を容易に取得しやすくなる。結果として、リカバリ装置１００は、ユーザにとって利便性の高いリカバリを行うことができる。

〔７−４．特定処理〕
リカバリ装置１００は、第１端末から取得する第２情報について、種別や情報量を特定しなくてもよい。例えば、リカバリ装置１００は、第２端末によって蓄積されているすべての第２情報を取得してもよい。あるいは、リカバリ装置１００は、第２端末によって蓄積されている第２情報のうち、いくつかの第２情報を無作為に取得してもよい。そして、リカバリ装置１００は、取得した第２情報のうち、第１情報と照合することのできる情報を抽出して、検証処理を行ってもよい。

〔７−５．取得処理〕
リカバリ装置１００は、図５で示した第１情報等を取得したり保持したりする処理において、常に取得処理を継続するのではなく、所定のタイミングで取得処理を行うようにしてもよい。例えば、リカバリ装置１００は、所定のタイミングとして、スマートフォン２０において所定のアプリが起動されたときを契機として、第１情報を取得してもよい。また、リカバリ装置１００は、所定の閾値を超えるようなコンテキストの変化が観測されたときに、その変化した情報をログとして保持するようにしてもよい。また、リカバリ装置１００は、特定の位置情報が観測された場合（ユーザＵ０１の自宅や会社などの拠点となる位置や、事前に設定された所定のスポット等）にのみ、その位置情報をログとして保持するようにしてもよい。また、リカバリ装置１００は、スマートフォン２０において所定のチェックイン機能を有するアプリが起動され、ユーザからのチェックインが確認された場合に、かかるタイミングにおける位置情報を取得するようにしてもよい。なお、この場合のチェックインとは、例えば、ＳＮＳやオンラインゲーム等において、自身が他ユーザに対して何らかの提案を行ったり、提案に対して他ユーザへの参加を促したりする行動を示す。なお、リカバリ装置１００は、チェックインに係るサービスを第２のサービスとして取り扱い、かかるサービスから提供される第２情報を用いて実施形態に係るリカバリ処理を行ってもよい。

このように、リカバリ装置１００は、各種情報を取得するタイミングや、保持する情報について、適宜、取捨選択することができる。これにより、リカバリ装置１００は、実施形態に係る処理負荷を軽減させたり、情報を保持するための記憶装置に関する負担を軽減させたり、処理に係る電力量や通信量のコストを削減することができる。

〔７−６．処理のバリエーション〕
上記実施形態の各処理において、リカバリ装置１００が行う各処理には、種々のバリエーションが存在してもよい。

例えば、第１のサービスがショッピングサービスであり、第２のサービスが金融機関による決済サービスであるものとする。このとき、リカバリ装置１００は、第１情報としてユーザの購買履歴を取得するとともに、第２情報として、第１情報の購買履歴に対応する決済履歴を取得する。

そして、リカバリ装置１００は、例えば、第１のサービスにおける購買履歴と同じ日時に、第１のサービスの購買額と同じ金額が第２のサービスにおいて決済されていた場合に、両者の情報が、ある共通したユーザの行動を示す情報であるとして、ユーザの本人性を検証してもよい。

あるいは、第１のサービスが通信網を提供する通信サービスであり、第２のサービスが金融機関による決済サービスであるものとする。そして、リカバリ装置１００は、第１情報としてユーザのスマートフォン２０の利用額を取得するとともに、第２情報として、スマートフォン２０の利用額の決済履歴を取得する。

そして、リカバリ装置１００は、例えば、第１のサービスにおけるスマートフォン２０の利用額と、第２のサービスにおける決済額が同じ場合に、両者の情報が、ある共通したユーザの行動を示す情報であるとして、ユーザの本人性を検証してもよい。

また、上記実施形態における位置情報は、ユーザ端末１０が取得する各種環境情報と置き換えてもよい。例えば、リカバリ装置１００は、ユーザがある行動を実行した場合の気温情報や、湿度情報や、照度情報や、通信環境情報等を利用してもよい。

〔７−７．第３のサービス〕
リカバリ装置１００は、アカウントのリカバリを行う第１のサービス以外の情報を用いて、リカバリ処理を実行してもよい。例えば、リカバリ装置１００は、第２のサービスと、第１及び第２のサービス以外のサービスである第３のサービスとにおけるユーザの行動履歴に基づいてリカバリ処理を実行してもよい。

例えば、ユーザは、予め第１のサービスと、第２のサービスや第３のサービスとでユーザＩＤを連携しているものとする。この場合、第２のサービスや、第３のサービスを利用する場合に、ユーザは、第１のサービスにおけるユーザＩＤを利用することができる。

そして、ユーザが、第１のサービスにおけるアカウントのリカバリを要求したものとする。この場合、リカバリ装置１００は、例えば、第２のサービスにおける行動履歴と、第３のサービスにおける行動履歴との一致又は類似に基づいて、ユーザの本人性を検証してもよい。

例えば、第２のサービスが位置情報サービスであり、第３のサービスがＳＮＳであるものとする。例えば、位置情報サービスでは、定期的にユーザの位置情報を取得する。また、ＳＮＳサービスでは、ユーザが投稿を行った際に、当該ユーザの位置情報を取得する。そして、リカバリ装置１００は、第２のサービスにおける位置情報と、第３のサービスにおける位置情報とが一致している場合に、両サービスを利用したユーザは、同一のユーザである蓋然性が高いと判定する。すなわち、リカバリ装置１００は、第１のサービスにおける第１情報を用いずとも、第１のサービスと連携されているサービスであって、かつ、複数のサービス間における行動履歴がある共通したユーザの行動を示していると推定される場合には、当該ユーザの本人性が検証されたと判定してもよい。

すなわち、リカバリ装置１００は、リカバリしようとするアカウントに対応した行動履歴を必ずしも用いなくても、他のサービスにおける行動履歴の共通性を判定することで、ユーザの本人性を検証してもよい。このように、リカバリ装置１００は、柔軟なリカバリ処理を実行することができる。

〔７−８．ユーザ端末〕
上記実施形態では、図８を用いてユーザ端末１０の構成例を示したが、ユーザ端末１０は、図８で示した構成を必ずしも全て有していなくてもよい。ユーザ端末１０には、上述のように、スマートフォン２０やウェアラブルデバイス３０のようなスマートデバイスのみならず、通信機能を有する眼鏡型端末や、あるいは、ユーザの心拍を記憶する心拍測定器など、種々のウェアラブルデバイスが含まれる。この場合、ユーザ端末１０は、必ずしもユーザから入力を受け付けるのではなく、自動的にユーザの情報を取得し、かかる情報を通信ネットワークに送信するなどの機能を持ちうる。すなわち、ユーザ端末１０は、いわゆるＩｏＴ（Internet of Things）を実現するような、所定の通信機能を有するデバイスであれば、必ずしも図８で示した構成を有していなくてもよい。

〔８．ハードウェア構成〕
上述してきた実施形態に係るリカバリ装置１００や、ユーザ端末１０や、第２サービス提供サーバ２００は、例えば図１３に示すような構成のコンピュータ１０００によって実現される。以下、リカバリ装置１００を例に挙げて説明する。図１３は、リカバリ装置１００の機能を実現するコンピュータ１０００の一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。

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

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

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

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

例えば、コンピュータ１０００が実施形態に係るリカバリ装置１００として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラム（リカバリプログラム）を実行することにより、制御部１３０の機能を実現する。また、ＨＤＤ１４００には、記憶部１２０内のデータが記憶される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを記録媒体１８００から読み取って実行するが、他の例として、他の装置から通信網５００を介してこれらのプログラムを取得してもよい。

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

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、図４に示した特定部１３３と、検証部１３５は統合されてもよい。また、例えば、記憶部１２０に記憶される情報は、ネットワークＮを介して、外部に備えられた記憶装置に記憶されてもよい。

また、例えば、上記実施形態では、リカバリ装置１００が、第１情報及び第２情報を取得する取得処理と、ユーザの本人性を検証する検証処理と、アカウントのリカバリを実行する実行処理とを行う例を示した。しかし、上述したリカバリ装置１００は、取得処理を行う取得装置と、検証処理を行う検証装置と、リカバリ処理を実行する実行装置とに分離されてもよい。この場合、実施形態に係るリカバリ装置１００による処理は、取得装置と、検証装置と、実行装置とを有するリカバリシステム１によって実現される。

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

〔１０．効果〕
上述してきたように、実施形態に係るリカバリ装置１００は、第１取得部１３２と、第２取得部１３４と、検証部１３５と、実行部１３６とを有する。第１取得部１３２は、第１のサービスにおけるユーザの行動履歴に関する情報である第１情報を取得する。第２取得部１３４は、第１情報以外の情報であって、ユーザの行動履歴に関する情報である第２情報を取得する。検証部１３５は、第１情報と第２情報との照合に基づいて、ユーザの本人性を検証する。実行部１３６は、検証部１３５によってユーザの本人性が検証された場合に、第１のサービスにおいて当該ユーザが有していたアカウントのリカバリを実行する。

このように、実施形態に係るリカバリ装置１００は、第１のサービスに保持されている第１情報と、第１情報以外の情報である第２情報との照合によってユーザの本人性を検証する。これにより、リカバリ装置１００は、事前の登録を要さずとも、第１のサービスにおける行動履歴というユーザしか知り得ない情報と、第１のサービス以外における行動履歴という、ユーザしか回答できない情報とを照合することができる。これにより、リカバリ装置１００は、秘密の質問などの事前登録がなくともリカバリ処理を実行できるため、ユーザにとって利便性の高いリカバリ処理を提供することができる。

また、第２取得部１３４は、第２情報として、第１のサービスの提供者以外の提供者から提供されるサービスである第２のサービスにおける、ユーザの行動履歴に関する情報を取得する。

このように、実施形態に係るリカバリ装置１００は、第２のサービスから取得するユーザの行動履歴と、第１のサービスにおける行動履歴とを照合することで、ユーザの本人性を検証する。これにより、リカバリ装置１００は、ユーザＵ０１が改竄することが困難な情報を利用して検証を行うことができるため、不正ユーザによる成りすまし等を高い精度で防止し、より安全性の高いリカバリ処理を行うことができる。

また、第２取得部１３４は、第２情報として、第１のサービスの利用において用いられる端末装置以外の他端末（実施形態では、第２端末に対応する）によって取得された、ユーザの行動履歴に関する情報を取得する。

このように、実施形態に係るリカバリ装置１００は、ユーザが日常的に利用していると想定される第２端末に蓄積された情報を利用して、リカバリ処理を実行することができる。すなわち、リカバリ装置１００は、第２情報を準備する手間や、事前に第２端末を登録しておくといった手間をユーザに掛けさせずともリカバリ処理を実行できる。これにより、リカバリ装置１００は、リカバリ処理におけるユーザビリティを向上させることができる。

また、第２取得部１３４は、第２情報として、第１のサービスの利用において用いられる端末装置によって取得された情報であって、第１のサービスの利用において用いられるアプリケーションプログラムとは異なるアプリケーションプログラムによって取得された、ユーザの行動履歴に関する情報を取得する。

このように、実施形態に係るリカバリ装置１００は、同一端末であっても、異なるアプリケーションプログラムによって取得される情報であれば、その情報を第２情報とみなして処理を行ってもよい。これにより、リカバリ装置１００は、複数の端末を所持していないユーザに関しても支障なくリカバリ処理を実行することができる。

また、検証部１３５は、第１情報と第２情報とで共通する種別の情報を抽出し、抽出した情報同士の一致度もしくは類似度に基づいて、ユーザの本人性を検証する。

このように、実施形態に係るリカバリ装置１００は、共通した種別の情報を用いてユーザの検証を行う。これにより、リカバリ装置１００は、照合した情報同士が、同一のユーザにおける共通した行動履歴を示すものであるか否かを正確に判定できるため、検証の精度を向上させることができる。

また、検証部１３５は、第１情報と第２情報とに含まれる位置情報を抽出し、所定数もしくは所定の時間長における位置情報同士の一致度もしくは類似度に基づいて、ユーザの本人性を検証する。

このように、実施形態に係るリカバリ装置１００は、位置情報に基づいてユーザの本人性を検証する。異なるサービスや端末間において、同じ日時に取得された位置情報が共通した位置を示す場合には、両者の情報を有しているユーザは、同一のユーザである蓋然性が高いと想定される。このため、リカバリ装置１００は、位置情報を用いることで、精度よくユーザの本人性を検証することができる。

また、検証部１３５は、第１情報と第２情報とから互いに異なる種別の情報を抽出し、抽出した異なる種別の情報が、ユーザにおける共通した所定の行動を示すか否かに基づいて、ユーザの本人性を検証する。

このように、実施形態に係るリカバリ装置１００は、異なる種別の情報を用いて検証を行ってもよい。例えば、リカバリ装置１００は、位置情報と、配送先情報を用いて検証を行うことができる。すなわち、リカバリ装置１００は、多様な情報を処理に用いることで、柔軟なリカバリ処理を実現することができる。

また、検証部１３５は、第１情報及び第２情報の種別として、位置情報、決済情報、コンテンツの閲覧情報、検索情報、予約情報、ＳＮＳ投稿情報、通信接続情報、ユーザの属性情報の少なくともいずれか一つを用いて、ユーザの本人性を検証する。

このように、実施形態に係るリカバリ装置１００は、様々な種別の情報を用いて検証を行ってもよい。これにより、リカバリ装置１００は、特定の情報に限定されない、柔軟なリカバリ処理を実現することができる。

また、検証部１３５は、共通する所定時間の行動履歴を示す第１情報と第２情報とを一つの組として、少なくとも２以上の組における照合に基づいて、ユーザの本人性を検証する。

このように、実施形態に係るリカバリ装置１００は、複数の情報が一致することを条件として、ユーザの本人性の検証を行ってもよい。一般に、照合する情報の数が多いほど、検証処理の精度は向上するといえる。すなわち、リカバリ装置１００は、多要素認証のように、多くの情報を用いて検証処理を行うことで、検証処理の精度を向上させることができる。

また、検証部１３５は、ユーザによって選択された種別の第１情報と第２情報との照合に基づいて、当該ユーザの本人性を検証する。

このように、実施形態に係るリカバリ装置１００は、照合に用いる情報を、ユーザの選択に委ねてもよい。これにより、リカバリ装置１００は、ユーザの状況に即したリカバリ処理を実行することができる。

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

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

１ リカバリシステム
１０ ユーザ端末
２０ スマートフォン
３０ ウェアラブルデバイス
１００ リカバリ装置
１１０ 通信部
１２０ 記憶部
１２１ 第１サービス情報記憶部
１２２ 検証情報記憶部
１２３ 定義情報記憶部
１３０ 制御部
１３１ 受信部
１３２ 第１取得部
１３３ 特定部
１３４ 第２取得部
１３５ 検証部
１３６ 実行部
１３７ 送信部

Claims (12)

1. 第１のサービスにおけるユーザの行動履歴に関する情報である第１情報を取得する第１取得部と、
   前記第１情報以外の情報であって、前記ユーザの行動履歴に関する情報である第２情報を取得する第２取得部と、
   前記第１情報と前記第２情報との照合に基づいて、前記ユーザの本人性を検証する検証部と、
   前記検証部によってユーザの本人性が検証された場合に、前記第１のサービスにおいて当該ユーザが有していたアカウントのリカバリを実行する実行部と、
   を備えたことを特徴とするリカバリ装置。
2. 前記第２取得部は、
   前記第２情報として、前記第１のサービスの提供者以外の提供者から提供されるサービスである第２のサービスにおける、前記ユーザの行動履歴に関する情報を取得する、
   ことを特徴とする請求項１に記載のリカバリ装置。
3. 前記第２取得部は、
   前記第２情報として、前記第１のサービスの利用において用いられる端末装置以外の他端末によって取得された、前記ユーザの行動履歴に関する情報を取得する、
   ことを特徴とする請求項１又は２に記載のリカバリ装置。
4. 前記第２取得部は、
   前記第２情報として、前記第１のサービスの利用において用いられる端末装置によって取得された情報であって、前記第１のサービスの利用において用いられるアプリケーションプログラムとは異なるアプリケーションプログラムによって取得された、前記ユーザの行動履歴に関する情報を取得する、
   ことを特徴とする請求項１又は２に記載のリカバリ装置。
5. 前記検証部は、
   前記第１情報と前記第２情報とで共通する種別の情報を抽出し、抽出した情報同士の一致度もしくは類似度に基づいて、前記ユーザの本人性を検証する、
   ことを特徴とする請求項１〜４のいずれか一つに記載のリカバリ装置。
6. 前記検証部は、
   前記第１情報と前記第２情報とに含まれる位置情報を抽出し、所定数もしくは所定の時間長における位置情報同士の一致度もしくは類似度に基づいて、前記ユーザの本人性を検証する、
   ことを特徴とする請求項５に記載のリカバリ装置。
7. 前記検証部は、
   前記第１情報と前記第２情報とから互いに異なる種別の情報を抽出し、抽出した異なる種別の情報が、前記ユーザにおける共通した所定の行動を示すか否かに基づいて、前記ユーザの本人性を検証する、
   ことを特徴とする請求項１〜４のいずれか一つに記載のリカバリ装置。
8. 前記検証部は、
   前記第１情報及び前記第２情報の種別として、位置情報、決済情報、コンテンツの閲覧情報、検索情報、予約情報、ＳＮＳ（Social Networking service）投稿情報、通信接続情報、前記ユーザの属性情報の少なくともいずれか一つを用いて、前記ユーザの本人性を検証する、
   ことを特徴とする請求項５〜７のいずれか一つに記載のリカバリ装置。
9. 前記検証部は、
   共通する所定時間の行動履歴を示す前記第１情報と前記第２情報とを一つの組として、少なくとも２以上の組における照合に基づいて、前記ユーザの本人性を検証する、
   ことを特徴とする請求項１〜８のいずれか一つに記載のリカバリ装置。
10. 前記検証部は、
    前記ユーザによって選択された種別の第１情報と第２情報との照合に基づいて、当該ユーザの本人性を検証する、
    ことを特徴とする請求項１〜９のいずれか一つに記載のリカバリ装置。
11. コンピュータが実行するリカバリ方法であって、
    第１のサービスにおけるユーザの行動履歴に関する情報である第１情報を取得する第１取得工程と、
    前記第１情報以外の情報であって、前記ユーザの行動履歴に関する情報である第２情報を取得する第２取得工程と、
    前記第１情報と前記第２情報との照合に基づいて、前記ユーザの本人性を検証する検証工程と、
    前記検証工程によってユーザの本人性が検証された場合に、前記第１のサービスにおいて当該ユーザが有していたアカウントのリカバリを実行する実行工程と、
    を含んだことを特徴とするリカバリ方法。
12. 第１のサービスにおけるユーザの行動履歴に関する情報である第１情報を取得する第１取得手順と、
    前記第１情報以外の情報であって、前記ユーザの行動履歴に関する情報である第２情報を取得する第２取得手順と、
    前記第１情報と前記第２情報との照合に基づいて、前記ユーザの本人性を検証する検証手順と、
    前記検証手順によってユーザの本人性が検証された場合に、前記第１のサービスにおいて当該ユーザが有していたアカウントのリカバリを実行する実行手順と、
    をコンピュータに実行させることを特徴とするリカバリプログラム。

Images