JP7095429B2 - 情報処理装置 - Google Patents

Description

本発明は、サービスの提供を受けるためのアカウントの管理を行う情報処理装置に関する。

複数の認証システムがＳＳＯ（シングルサインオン）連携する環境が提供されている。このような環境は、多くのシステムを連続して使用するユーザにとって便利なものであるが、不使用のアカウントが放置され易いという問題がある。そこで、不要なアカウントを削除する手段が求められる。

不要なアカウントの削除に関する技術文献として、特許文献１および２がある。特許文献１では、認証システムが管理しているアカウントについて、アカウント存続のための制約条件を満たすか否かを判定し、この判定結果に基づきアカウントを削除することで、不要となった無料アカウントの削除を実現している。また、特許文献２では、２段階の判定基準を設けてアカウントを自動的に削除する。具体的には、１段階目においてユーザが特定権限を有しているか否かを判定し、特定権限を有していない場合、２段階目において、アカウントの利用履歴から特定の属性情報を確認し、属性情報がある閾値より少ないかどうかの判定を行うことによりアカウントを削除している。

特許第５７５９３０５号 特開２０１１－１９８０９４号公報

本発明は、連携する認証システムが複数ある場合において、あるアカウント群を削除する場合に、削除されるアカウントの代わりとなる移行先のアカウントを提案する技術を提供する。

請求項１に係る情報処理装置は、アカウント認証において連携する複数のシステムの各々について、当該システムから与えられたアカウント群を管理する管理部と、前記複数のシステムにおけるアカウント群のうち削除条件を満たす特定アカウント群について、前記複数のシステムのアカウント群のうち当該特定アカウント群を除いたアカウント群の中から選択された少なくとも１つのアカウントを移行先として提案する提案部とを有する。
請求項２に係る情報処理装置は、請求項１に係る情報処理装置において、前記複数のシステムのアカウント群に含まれる各アカウントについて、当該アカウントの属性を取得する取得部を有し、前記削除条件は、前記属性に関する条件である。
請求項３に係る情報処理装置は、請求項２に係る情報処理装置において、あるアカウントについての前記属性は、当該アカウントに対応するシステムにおける当該アカウントの使用履歴を含む。
請求項４に係る情報処理装置は、請求項２に係る情報処理装置において、あるアカウントについての前記属性は、前記複数のシステムのうち当該アカウントに対応するシステムの優先度を含む。
請求項５に係る情報処理装置は、請求項２に係る情報処理装置において、あるアカウントについての前記属性は、当該アカウントに対応するシステムが他のシステムへの同期元となっているか否かの情報を含む。
請求項６に係る情報処理装置は、請求項１乃至３のいずれか一項に係る情報処理装置において、削除条件の候補の入力を受け付ける候補受け付け部と、前記削除条件に該当するアカウント群の数を出力する出力部とを有する。
請求項７に係る情報処理装置は、請求項１乃至３のいずれか一項に係る情報処理装置において、削除するアカウント数の入力を受け付ける受け付け部と、前記アカウント数のアカウントが対象となる削除条件の候補を出力する出力部とを有する。

請求項１に係る情報処理装置によれば、削除されるアカウントの代わりとなる移行先のアカウントを提案することができる。
請求項２に係る情報処理装置によれば、アカウントが削除される条件を、アカウントの属性に応じて決めることができる。
請求項３に係る情報処理装置によれば、アカウントの使用履歴に応じてアカウントを削除することができる。
請求項４に係る情報処理装置によれば、アカウントの優先度に応じてアカウントを削除することができる。
請求項５に係る情報処理装置によれば、他のシステムへの同期元となっているか否かに応じてアカウントを削除することができる。
請求項６に係る情報処理装置によれば、削除条件とその条件に該当するアカウント数との関係を知ることができる。
請求項７に係る情報処理装置によれば、所望の数のアカウントを削除するのに要する削除条件を知ることができる。

一実施形態に係る認証管理システムの構成を示すブロック図。 認証管理サーバ１００の構成例を示すブロック図。 履歴管理用テーブルを例示する図。 制約条件管理用テーブルを例示する図。 認証システムと制約条件管理用テーブルとの関連用テーブルを例示する図。 管理端末３００の表示部に表示される制約条件入力画面を例示する図。 削除候補監視処理を示すフローチャート。 管理端末３００に表示される削除候補一覧画面を例示する図。 管理端末３００に表示される削除候補詳細画面を例示する図。 管理端末３００に表示される通知先設定画面を例示する図。 管理端末３００に表示される制約条件確認画面を例示する図。 管理端末３００に表示される削減効果確認画面を例示する図。

１．構成
図１は、一実施形態に係る認証管理システムの構成を示すブロック図である。認証管理システムは、認証管理サーバ１００（情報処理装置の一例）を含む。図１には、システムＡを利用するためのアカウントの認証を行う認証システム１と、システムＢおよびクラウドサービスＣを利用するためのアカウントの認証を行う認証システム２と、クラウドサービスＤを利用するためのアカウントの認証を行う認証システム３が例示されている。認証管理サーバ１００は、これら複数の認証システムによる認証の対象となるアカウントの管理を行うサーバである。認証管理サーバ１００は、アカウントの管理を行うためにＤＢ２００を使用する。管理者は、管理端末３００により認証管理サーバ１００にアクセスし、不要なアカウントの削除等のアカウントの管理を行わせることが可能である。

図２は、認証管理サーバ１００の構成例を示すブロック図である。認証管理サーバ１００は、プロセッサ１０１と、揮発性記憶部および不揮発性記憶部からなる記憶部１０２と、ネットワークを介した通信機能を有する通信部１０３と、表示部１０４と、操作部１０５とを有するコンピュータ装置である。記憶部１０２の不揮発性記憶部にはプロセッサ１０１により実行される各種のプログラムが格納される。

図１において、認証管理サーバ１００を示すブロックの中には、ＳＳＯ（Single Sign On）管理部１１０と、履歴管理部１２０と、制約条件管理部１３０と、候補受け付け部１４０と、取得部１５０と、提案部１６０と、出力部１７０とが示されている。これらは図２のプロセッサ１０１が記憶部１０２の不揮発性記憶部に記憶されたプログラムを実行することにより実現される機能である。

ＳＳＯ管理部１１０は、アカウント認証において連携する複数のシステムの各々について、当該システムから与えられたアカウント群を管理する手段である。

履歴管理部１２０は、複数のシステムにおいて認証対象となる各アカウントについて使用履歴を収集して管理する手段である。

図３は、履歴管理用テーブルを例示する図である。この履歴管理用テーブルは履歴管理部１２０によってＤＢ２００内に作成される。この履歴管理用テーブルは、システムへのログインに使用されたユーザＩＤ毎に、ログインに当たっての認証を行った認証システムのＩＤ、ログイン先のシステムのＩＤ、最終ログイン日時を記録したテーブルである。

取得部１５０は、複数のシステムのアカウント群に含まれる各アカウントについて、当該アカウントの属性を取得する手段である。ここで、アカウントの属性には、当該アカウントに対応するシステムにおける当該アカウントの使用履歴が含まれる。この使用履歴は、履歴管理部１２０により管理される情報である。また、アカウントの属性は、複数のシステムのうち当該アカウントに対応するシステムの優先度を含む。また、アカウントの属性は、当該アカウントに対応するシステムが他のシステムへの同期元となっているか否かの情報を含む。

制約条件管理部１３０は、アカウント存続のための制約条件を管理する手段である。この制約条件は、存続させるアカウントが有すべきアカウントの属性に関する条件である。

図４は、制約条件管理用テーブルを例示する図である。この制約条件テーブルは、制約条件管理部１３０によりＤＢ２００内において管理される。この制約条件管理用テーブルは、制約条件ＩＤに対応付けて、制約条件を定義したテーブルである。この制約条件管理テーブルに定義された全ての制約条件を満たすアカウントが存続の対象となる。逆にこの制約条件管理テーブルに定義された少なくとも１つの制約条件を満たさないアカウントは削除の対象となる。すなわち、制約条件は、裏を返せばアカウントの削除条件でもある。

図４に示すように、制約条件管理用テーブルでは、制約条件の充足の判断に用いられるアカウントの属性と、アカウントを存続させるために属性が充足すべき条件が定義されている。例えば制約条件ＩＤが１である制約条件は、属性・priority（優先度）が２以上（数値としては２以下）である場合に充足される。従って、優先度の数値が３以上であれば削除対象となる。また、制約条件ＩＤが２である制約条件は、属性・LastLogin（最終ログイン日時）が３カ月以内である場合に充足される。従って、最終ログイン日時が３カ月より前であれば削除対象となる。また、制約条件ＩＤが３である制約条件は、属性・provisioning（プロビジョニング）がtrue、すなわち、プロビジョニング対象である場合に充足される。従って、プロビジョニング対象でなければ削除対象となる。ここで、プロビジョニングとは、データの同期をすることをいう。プロビジョニング対象であるとは、データの同期元であることをいう。

また、ＤＢ２００には、認証システムと制約条件管理用テーブルとの関連用テーブルも記憶される。

図５は、認証システムと制約条件管理用テーブルとの関連用テーブルを例示する図である。この関連テーブルでは、認証システムＩＤがauth1である認証システムには、制約条件ＩＤが１、２である制約条件が適用されるという具合に、認証システムとその認証システムのアカウントについて設定されている制約条件との対応付けを行っている。この対応付けは、制約条件の設定時に定まる。なお、この制約条件の設定の動作については後述する。

提案部１６０は、複数のシステムにおけるアカウント群のうち制約条件管理部１３０が管理する制約条件により削除の対象となる特定アカウント群について、複数のシステムのアカウント群のうち当該特定アカウント群を除いたアカウント群の中から選択された少なくとも１つのアカウントを移行先として提案する手段である。

候補受け付け部１４０は、削除条件の候補の入力を受け付け、あるいは削除するアカウント数の入力を受け付ける。

候補受け付け部１４０が削除条件の候補の入力を受け付けた場合、出力部１７０は、削除条件に該当するアカウント群の数を出力する。また、候補受け付け部１４０が削除するアカウント数の入力を受け付けた場合、出力部１７０は、アカウント数のアカウントが削除の対象となる削除条件の候補を出力する。

２．動作
次に本実施形態の動作を説明する。本実施形態において、管理者は、管理端末３００を操作して認証管理サーバ１００にアクセスし、制約条件の設定を要求する。認証管理サーバ１００では、制約条件の入力画面を管理端末３００の表示部に表示させ、制約条件の入力を受け付ける。

図６は、管理端末３００の表示部に表示される制約条件入力画面を例示する図である。この削除条件入力画面において、管理者は、マウスやキーボード等の操作子を操作することにより、制約条件の適用対象となる認証システム名、アカウント存続に関する判断の対象となるアカウントの属性、アカウントを存続させるために当該属性が満たすべき条件を指定する。図６に示す例では、認証システム１において、優先度が３以上（優先度の数値が３以下）のアカウントを存続させる制約条件が設定されている。

このように制約条件が設定されると、認証管理サーバ１００では、取得部１５０が、制約条件に関する判断に用いるアカウントの属性を取得し、提案部１６０が、制約条件を満たさないアカウントの個数を求める。そして、管理端末３００の制約条件入力画面にこの個数が削除候補予測数として表示される。

管理者は、制約条件入力画面に表示された制約条件でよい場合は、画面下方の「設定」の文字列を含むソフトボタンを指示する。これにより画面に表示された制約条件が制約条件管理部１３０によってＤＢ２００内の制約条件管理用テーブル（図４参照）に登録される。また、画面に表示された制約条件に不満がある場合、管理者は、「キャンセル」の文字列を含むソフトボタンを指示し、制約条件の入力をやり直す。

図７は、認証管理サーバ１００において実行される削除候補監視処理を示すフローチャートである。この削除候補監視処理は、管理端末３００から実行指示が与えられることにより実行される。なお、管理者は、管理端末３００からの設定により、この削除候補監視処理を定期的に実行させることも可能である。

まず、認証管理サーバ１００では、取得部１５０が、履歴管理部１２０の管理する履歴管理用テーブル（図３参照）を確認する（ステップＳ１０１）。そして、提案部１６０は、利用頻度が閾値α未満であるアカウントが存在しないかどうかを判断する（ステップＳ１０２）。

ステップＳ１０２の判断結果が「ＹＥＳ」である場合、削除候補監視処理は終了となる。これに対し、ステップＳ１０２の判断結果が「ＮＯ」、すなわち、利用頻度が閾値α未満であるアカウントが存在する場合、処理はステップＳ１１１に進む。

次にステップＳ１１１に進むと、未処理アカウント、すなわち、利用頻度が閾値α未満のアカウントであって、ステップＳ１１２以降の処理を経ていないアカウントがあるか否かを判断する。この判断結果が「ＹＥＳ」である場合、処理はステップＳ１１２に進む。

次にステップＳ１１２に進むと、提案部１６０は、制約条件管理部１３０が管理する制約条件管理用テーブル（図４参照）を確認する。次にステップＳ１１３に進むと、提案部１６０は、利用頻度が閾値α未満のアカウントが、制約条件管理用テーブルに定められた制約条件を満たさないかどうか、すなわち、削除可能かどうかを判断する。

ステップＳ１１３の判断結果が「ＮＯ」である場合、提案部１６０は、処理をステップＳ１１１に戻す。これに対し、ステップＳ１１３の判断結果が「ＹＥＳ」である場合、提案部１６０は、当該アカウントを削除候補に追加し（ステップＳ１１４）、処理をステップＳ１１１に戻す。

このようにして、利用頻度が閾値α未満である全てのアカウントについて、ステップＳ１１１～Ｓ１１４の処理が実行される。この結果、ステップＳ１１１の判断結果が「ＮＯ」となってステップＳ１２１に進む。

次にステップＳ１２１に進むと、提案部１６０は、削除候補を利用中アカウントとし（すなわち、削除候補として蓄積したアカウントを利用中アカウントという容器に移し替え）、削除候補をクリアする。

次にステップＳ１２２に進むと、未処理アカウント、すなわち、ステップＳ１２３以降の処理を経ていない利用中アカウントがあるか否かを判断する。この判断結果が「ＹＥＳ」である場合、処理はステップＳ１２３に進む。

次にステップＳ１２３に進むと、提案部１６０は、利用中アカウントの１つについて、移行対象システム、すなわち、削除が望まれている認証システムのアカウントでないかどうか判断する。この判断結果が「ＹＥＳ」である場合、処理はステップＳ１２２に戻る。一方、ステップＳ１２３の判断結果が「ＮＯ」である場合にはステップＳ１２４に進む。

次にステップＳ１２４に進むと、提案部１６０は、移行先となる最優先システムのアカウント、すなわち、移行対象システム以外の認証システムのアカウントの中から利用中アカウントとＳＳＯ連携しているアカウントを抽出する。次にステップＳ１２５に進むと、提案部１６０は、抽出したアカウントを移行先候補とする。

次にステップＳ１２６に進むと、提案部１６０は、利用中アカウントを削除候補に追加する。これにより処理はステップＳ１２２に戻る。

このようにして、全ての利用中アカウントについて、ステップＳ１２２～Ｓ１２６の処理が実行される。この結果、ステップＳ１２２の判断結果が「ＮＯ」となって削除候補監視処理が終了する。

本実施形態において、管理者は、削除候補監視処理の実行結果を管理端末３００により確認することができる。

図８は、管理端末３００に表示される削除候補一覧画面を例示する図である。図８に示すように、削除候補一覧画面には、削除候補監視処理（図７）のステップＳ１２６において削除候補となったアカウントであるユーザＩＤおよびその認証システムと、ステップＳ１２５において移行先とされたアカウントの認証システムが表示される。削除候補および移行先の表示の左隣にはチェックボックスが表示されている。

管理者は、所望の削除候補の左隣のチェックボックスをチェックし、「削除」の文字列を含むソフトボタンを指示することにより、その削除候補を削除することができる。

また、管理者は、所望の削除候補および移行先の左隣のチェックボックスをチェックし、「詳細」の文字列を含むソフトボタンを指示することにより、その削除候補および移行先に関する詳細な情報を管理端末３００に表示させることができる。

また、管理者は、所望の削除候補および移行先の左隣のチェックボックスをチェックし、「通知」の文字列を含むソフトボタンを指示することにより、その削除候補および移行先に関する情報を所望の相手（一般的には当該アカウントを所有するユーザ）に通知することができる。

図９は、管理端末３００に表示される削除候補詳細画面を例示する図である。図９では、図８におけるユーザＩＤ＝１２３４５により特定される削除候補についての詳細な情報が表示されている。この例では、優先度の数値が２より大きく（優先度が低く）、最終ログイン日時から３カ月以上経過している点が削除の理由として示されている。この削除の理由は、削除候補監視処理（図７）のステップＳ１１３において判断されたものである。

図１０は、管理端末３００に表示される通知先設定画面を例示する図である。この例では、図８の削除候補一覧画面が表示された状態において、ユーザＩＤ＝hoge@fx.comの左隣のチェックボックスがチェックされ、「通知」の文字列を含むソフトボタンが指示された場合の通知先設定画面が示されている。この通知先設定画面は、削除候補に関する情報を通知する電子メールを示している。この電子メールの宛先は、通常は、削除候補となったアカウントを所有するユーザである。しかし、管理者は、「アドレス帳」の文字列を含むソフトボタンを指示することによりアドレス帳を利用し、ユーザの上司や当該アカウントの認証を行う認証システムの管理者等、所望の宛先にこの電子メールを送信することも可能である。本文は、削除候補となったアカウントとその認証システムに関する情報、削除の理由を含む。管理者は、メールの内容に問題ない場合、「送信」の文字列を含むソフトボタンを指示する。これにより認証管理サーバ１００では、出力部１７０が当該電子メールを宛先に送信する。

図１１は、管理端末３００に表示される制約条件確認画面を例示する図である。本実施形態において、制約条件管理用テーブルに定義された現状の制約条件では、十分な個数のアカウントを削除することができない場合が起こり得る。この制約条件確認画面は、このような場合に配慮して提供されるものであり、管理者から目標とするアカウントの削減効果の入力を受け付け、そのような削減効果を実現することが可能な制約条件の候補を管理者に提供する画面である。

図１１において、制約条件確認画面の上半分には、目標とする削減効果を入力するためのフィールドが示されている。「削減候補数」フィールドは、削除候補とするアカウントの目標個数を指定するフィールドであり、必須入力フィールドである。「認証システム名」フィールドは、アカウントの削除を行う認証システム名を入力するフィールドであり、任意入力フィールドである。このフィールドの入力がない場合、全ての認証システムを対象として削除候補アカウントを見つける処理を実行する。「制約対象属性」フィールドは、アカウントを削除するか否かの判断に用いるアカウントの属性を入力するフィールドであり、任意入力フィールドである。このフィールドの入力がない場合、認証管理サーバ１００は、属性に関する任意の条件を各種試行してアカウントを削除するか否かの判断を行う。図１１に示す例では、認証システム２を対象とし、１０００アカウントを目標に削除候補を見つけるべき旨が要求されている。

管理者が「計算」の文字列を含むソフトボタンを指示すると、制約条件確認画面の上半分に表示された目標削減効果に関する情報は、認証管理サーバ１００によって受信される。これにより認証管理サーバ１００では、提案部１６０が目標削減効果を実現することができる制約条件の候補を求める。

この制約条件の候補を求めるための方法に関しては、各種の方法があり得る。第１の方法では、予め設定された複数種類の制約条件の各々について、図７の削除候補監視処理と同様な処理により削除候補アカウントを求め、削除候補アカウントの個数が目標削減効果に近い順に、制約条件候補として選択する方法である。第２の方法は、既存で入力されている「制約条件」から優先度が低いシステムから優先的に表示する方法である。

認証管理サーバ１００では、提案部１６０が求めた制約条件候補を出力部１７０が管理端末３００の制約条件確認画面に表示する。図１１における候補１、候補２は、このようにして表示された制約条件候補である。管理者が制約条件候補の右側にある「一覧」の文字列を含むソフトボタンを指示すると、出力部１７０は、当該制約条件において削除候補となるアカウントを示す前掲図８の削除候補一覧画面を管理端末３００の表示部に表示する。

管理者が所望の制約条件候補の左側のチェックボックスを指示し、「制約条件追加」の文字列を含むソフトボタンを指示すると、認証管理サーバ１００では、制約条件管理部１３０が、チェックボックスのチェックされた制約条件候補（図１１の例では候補１）を制約条件管理用テーブル（図４参照）に追加する。

また、管理者が所望の制約条件候補の左側のチェックボックスをチェックし、「効果確認リストに追加」の文字列を含むソフトボタンを指示すると、チェックされた制約条件が管理端末３００の一時記憶メモリに蓄積される。管理者は、この操作を複数回行うことも可能である。そして、管理者が「効果確認」の文字列を含むソフトボタンを指示すると、認証管理サーバ１００は管理端末３００の一時記憶メモリに蓄積された制約条件を受信する。そして、認証管理サーバ１００では、提案部１６０が当該制約条件において得られるアカウントの削減効果を求め、出力部１７０が管理端末３００の表示部に削減効果確認画面を表示する。

図１２は、管理端末３００に表示される削減効果確認画面を例示する図である。この削減効果確認画面は、管理者により指示された制約条件候補を制約条件管理用テーブル（図４参照）に追加した場合に得られるアカウントの削減効果を詳細に示す画面である。図１２に示すように、削減効果確認画面には、管理者によって選択された制約条件が表示されると共に、それらの制約条件を制約条件管理用テーブル（図４参照）に追加した場合に得られるアカウントの削減効果が認証システム毎に示される。

なお、図示の例では、制約条件の追加の実施前におけるアカウント数と実施後のアカウント数を棒グラフで示しているが、グラフの種類をシステム設定により変化させてもよい。

削減効果確認画面において、「通知」の文字列を含むソフトボタンが指示されると、認証管理サーバ１００では、出力部１７０が前掲図１０の通知先設定画面と同様な画面を管理端末３００の表示部に表示する。この状態において、管理端末３００を操作する管理者が各認証システムの管理者を指定し、「通信」ソフトボタンを指示すると、削減効果確認画面の内容を示すメールが各管理者に送信される。なお、各認証システムの管理者のメールアドレスは、認証管理サーバ１００に予め記憶されたものが用いられる。

以上説明したように、本実施形態によれば、利用頻度が低いアカウントのうち優先度が低い認証システムのアカウントや最終ログイン日時からの経過時間が長いアカウントを削除候補とし、プロビジョニング元のアカウントは削除候補にしないという具合に、アカウントの属性に基づいて削除候補のアカウントを選択することができる。その際、本実施形態において提案部１６０は、複数のシステムにおけるアカウント群のうち削除候補となった特定アカウント群を除いたアカウント群の中から選択された少なくとも１つのアカウント、具体的にはＳＳＯ連携しているアカウントを移行先として提案するので、削除するアカウントについての移行先を管理者側で誘導することができる。また、ユーザは、どのアカウントを移行先とすればよいか分かる。また、本実施形態によれば、候補受け付け部１４０が制約条件の候補の入力を受け付け、出力部１７０が制約条件により削除対象となるアカウント群の数を出力するので、管理者は、どのように制約条件の候補を選べば、どの程度のアカウントを削除できるかを確認することができる。また、本実施形態によれば、候補受け付け部１４０が削除するアカウント数の入力を受け付け、出力部１７０がこのアカウント数の削減効果の得られる制約条件の候補を出力するので、管理者は、所望のアカウント数の削除をするための制約条件を容易に決定することができる。

３．変形例
本発明は上述の実施形態に限定されるものではなく、種々の変形実施が可能である。以下、変形例をいくつか説明する。以下の変形例のうち２つ以上のものが組み合わせて用いられてもよい。

認証管理システムにおける機能要素とハードウェア要素との関係は実施形態において例示したものに限定されない。例えば、物理的に複数の装置からなる装置群が、認証管理サーバ１００としての機能を有していてもよい。

実施形態において示したＵＩ画面、並びに各種の条件及び情報はあくまで例示である。例えば、実施形態で示した画面のうち、一部のＵＩ要素は省略されてもよい。また、プロセッサ１０１等により実行されるプログラムは、ＣＤ－ＲＯＭ等の記録媒体に記録されて提供されてもよいし、ネットワーク上のサーバ装置に記憶された状態で提供されてもよい。

１００…認証管理サーバ、２００…ＤＢ、３００…管理端末、１１０…ＳＳＯ管理部、１２０…履歴管理部、１３０…制約条件管理部、１４０…候補受け付け部、１５０…取得部、１６０…提案部、１７０…出力部、１０１…プロセッサ、１０２…記憶部、１０３…通信部、１０４…表示部、１０５…操作部。

Claims (7)

1. アカウント認証において連携する複数のシステムの各々について、当該システムから与えられたアカウント群を管理する管理部と、
   前記複数のシステムにおけるアカウント群のうち削除条件を満たす特定アカウント群について、前記複数のシステムのアカウント群のうち当該特定アカウント群を除いたアカウント群の中から選択された少なくとも１つのアカウントを移行先として、前記移行先とされたアカウントの当該システムを提案する提案部と
   を有する情報処理装置。
2. 前記複数のシステムのアカウント群に含まれる各アカウントについて、当該アカウントの属性を取得する取得部を有し、
   前記削除条件は、前記属性に関する条件である
   請求項１に記載の情報処理装置。
3. あるアカウントについての前記属性は、当該アカウントに対応するシステムにおける当該アカウントの使用履歴を含む
   請求項２に記載の情報処理装置。
4. あるアカウントについての前記属性は、前記複数のシステムのうち当該アカウントに対応するシステムの優先度を含む
   請求項２に記載の情報処理装置。
5. あるアカウントについての前記属性は、当該アカウントに対応するシステムが他のシステムへの同期元となっているか否かの情報を含む
   請求項２に記載の情報処理装置。
6. 削除条件の候補の入力を受け付ける候補受け付け部と、
   前記削除条件に該当するアカウント群の数を出力する出力部と
   を有する請求項１乃至３のいずれか一項に記載の情報処理装置。
7. 削除するアカウント数の入力を受け付ける受け付け部と、
   前記アカウント数のアカウントが対象となる削除条件の候補を出力する出力部と
   を有する請求項１乃至３のいずれか一項に記載の情報処理装置。

Images