(57)【要約】      （修正有）【課題】ポリシー等を承認しないユーザーを適切に削除可能な情報処理装置を提供する。【解決手段】ユーザー通知部１００は、ユーザーＤＢ２００に登録されたユーザーに対して、承諾を求める通知を行う。回答取得部１１０は、ユーザーの回答情報２１０を取得する。再通知送信部１２０は、承諾の回答情報２１０が取得されなかった場合、ユーザーに対して、再通知２２０を別途送信する。再通知２２０は、承諾又は非承諾の再回答情報２３０を送信するための送信情報を含む。再回答取得部１３０は、再通知２２０において、送信情報に対応した再回答情報２３０を取得する。ユーザー削除部１４０は、再回答情報２３０が承諾でなかった場合、ユーザーをユーザーＤＢ２００から削除する。【選択図】図３
2019079399.tif 000002
【特許請求の範囲】
【請求項１】
データベースに登録されたユーザーに対して、承諾を求める通知を行うユーザー通知部と、
前記ユーザー通知部により行われた前記通知に対する前記ユーザーの回答情報を取得する回答取得部と、
前記回答取得部により承諾の前記回答情報が取得されなかった場合、前記ユーザーに対して、承諾又は非承諾の再回答情報を送信するための送信情報を含む再通知を別途送信する再通知送信部と、
前記再通知送信部により送信された前記再通知において、前記送信情報に対応した前記再回答情報を取得する再回答取得部と、
前記再回答取得部により取得された前記再回答情報が承諾でなかった場合、前記ユーザーを前記データベースから削除するユーザー削除部とを備える
ことを特徴とする情報処理装置。
【請求項２】
承諾を求める前記通知は、前記ユーザーのプライバシーポリシーの更新の通知であり、
前記再通知送信部は、リンクを含むメールにより前記再通知を別途送信する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記ユーザー削除部は、
前記ユーザーが、グループ内で他のユーザーを管理する管理者であった場合に、グループ内で前記他のユーザーのいずれかを新たな管理者として設定してから前記ユーザーを削除する
ことを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記ユーザー削除部は、
前記新たな管理者を設定する場合、削除する前記ユーザーの通知設定を前記新たな管理者へ引き継ぎ、
前記新たな管理者を設定しない場合、削除する前記ユーザーの通知設定をそのままにして、前記ユーザーへのその後の通知を一時保存する旨を前記管理者へ通知する
ことを特徴とする請求項３に記載の情報処理装置。
【請求項５】
情報処理装置により実行される情報処理方法であって、前記情報処理装置は、
データベースに登録されたユーザーに対して、承諾を求める通知を行い、
前記通知に対する前記ユーザーの回答情報を取得し、
承諾の前記回答情報が取得されなかった場合、前記ユーザーに対して、承諾又は非承諾の再回答情報を送信するための送信情報を含む再通知を別途送信し、
送信された前記再通知において、前記送信情報に対応した前記再回答情報を取得し、
取得された前記再回答情報が承諾でなかった場合、前記ユーザーを前記データベースから削除する
ことを特徴とする情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置及び情報処理方法に係り、特に画像形成装置の保守管理を行う情報処理装置及び情報処理方法に関する。
【背景技術】
【０００２】
従来から、文書や画像を印刷可能な複合機（Multifunctional Peripheral, MFP）等の画像形成装置が存在する。
また、これらの画像形成装置を保守管理するためのサーバーを含む画像形成システムも存在する。
【０００３】
従来の画像形成システムのサーバーの例として、特許文献１を参照すると、顧客サイトにある数多くの画像形成装置を保守管理するためのライセンスを容易に管理できるライセンス管理サーバーが開示されている。特許文献１のライセンス管理サーバーは、顧客サイトに設置された一つ以上の画像形成装置に対してリモート保守等を行うためのライセンスに関する情報を記憶したライセンス管理ＤＢと、ライセンスの内容を定めるための契約を結ぶ組織を表す委任グループおよび一つ以上の画像形成装置が所属する通常グループに関する情報を記憶したグループ管理ＤＢと、グループ管理ＤＢから委任グループを抽出する委任グループ認識部と、抽出された委任グループに対し、ライセンスを付与するライセンス管理部とを備える。
【０００４】
一方、近年、ビッグデータの活用等の観点から、ユーザーのデータの扱いについてのプライバシーポリシーの更新等が必要になってきている。
通常、このようにプライバシーポリシーを更新する場合には、各ユーザーに承諾を求める必要があった。また、国や地域によっては、この承諾を拒否したユーザーについて、ユーザーのデータ自体をシステムから削除する権利を認めることを求められていた。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１６−９９８０６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上述の特許文献１の技術においては、ユーザーを削除することは想定されていなかった。
【０００７】
本発明は、このような状況に鑑みてなされたものであって、上述の問題点を解消する情報処理装置を提供することを課題とする。
【課題を解決するための手段】
【０００８】
本発明の情報処理装置は、データベースに登録されたユーザーに対して、承諾を求める通知を行うユーザー通知部と、前記ユーザー通知部により行われた前記通知に対する前記ユーザーの回答情報を取得する回答取得部と、前記回答取得部により承諾の前記回答情報が取得されなかった場合、前記ユーザーに対して、承諾又は非承諾の再回答情報を送信するための送信情報を含む再通知を別途送信する再通知送信部と、前記再通知送信部により送信された前記再通知において、前記送信情報に対応した前記再回答情報を取得する再回答取得部と、前記再回答取得部により取得された前記再回答情報が承諾でなかった場合、前記ユーザーを前記データベースから削除するユーザー削除部とを備えることを特徴とする。
本発明の情報処理装置は、承諾を求める前記通知は、前記ユーザーのプライバシーポリシーの更新の通知であり、前記再通知送信部は、リンクを含むメールにより前記再通知を別途送信することを特徴とする。
本発明の情報処理装置は、前記ユーザー削除部は、前記ユーザーが、グループ内で他のユーザーを管理する管理者であった場合に、グループ内で前記他のユーザーのいずれかを新たな管理者として設定してから前記ユーザーを削除することを特徴とする。
本発明の情報処理装置は、前記ユーザー削除部は、前記新たな管理者を設定する場合、削除する前記ユーザーの通知設定を前記新たな管理者へ引き継ぎ、前記新たな管理者を設定しない場合、削除する前記ユーザーの通知設定をそのままにして、前記ユーザーへのその後の通知を一時保存する旨を前記管理者へ通知することを特徴とする。
本発明の情報処理方法は、情報処理装置により実行される情報処理方法であって、前記情報処理装置は、データベースに登録されたユーザーに対して、承諾を求める通知を行い、前記通知に対する前記ユーザーの回答情報を取得し、承諾の前記回答情報が取得されなかった場合、前記ユーザーに対して、承諾又は非承諾の再回答情報を送信するための送信情報を含む再通知を別途送信し、送信された前記再通知において、前記送信情報に対応した前記再回答情報を取得し、取得された前記再回答情報が承諾でなかった場合、前記ユーザーを前記データベースから削除することを特徴とする。
【発明の効果】
【０００９】
本発明によれば、データベースに登録されたユーザーに対して、承諾を求める通知を行い回答情報を取得し、承諾の回答情報が取得されなかった場合、承諾又は非承諾の再回答情報を送信するための送信情報を含む再通知を別途送信し、この再通知により取得された再回答情報が承諾でなかった場合、ユーザーをデータベースから削除することで、ユーザーの意図に沿って適切にデータベースからユーザーを削除することが可能な情報処理装置を提供することができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施の形態に係る画像形成システムのシステム構成図である。
【図２】図１に示すサーバーの制御構成を示すブロック図である。
【図３】本発明の実施の形態に係る画像形成システムの機能構成を示すブロック図である。
【図４】本発明の実施の形態に係るユーザー回答削除処理のフローチャートである。
【図５】図４に示すユーザー回答削除処理の概念図である。
【図６】図４に示すユーザー回答削除処理の概念図である。
【図７】図４に示す削除されたユーザーへのその後の各種通知の概念図である。
【発明を実施するための形態】
【００１１】
＜実施の形態＞
〔画像形成システムＸのシステム構成〕
まず、図１を参照して、本発明の実施の形態に係る画像形成システムＸのシステム構成について説明する。
画像形成システムＸは、顧客環境に設置された複数の画像形成装置２と、管理用の端末３とが、ネットワーク５を介して、遠隔管理を行うサーバー１に接続されて構成される。
【００１２】
サーバー１は、ＰＣ（Personal Computer）や汎用機等の情報処理装置である。サーバー１は、各画像形成装置２を遠隔管理し、主に課金、保守、サービス対応を行う。サーバー１は、いわゆる「クラウド」上のサーバーであってもよい。このため、サーバー１は、ＷＷＷ（World Wide Web）サーバー等を含んでおり、端末３からアクセスされた管理者に対して、ＣＧＩ（Common Gateway Interface）やＡＳＰ等により専用の管理画面を提供してもよい。なお、サーバー１は、この管理画面を、端末３へインストールされた、専用のアプリケーションソフトウェア（Application Software、以下、単に「アプリ」という。）用の画面情報として提供することも可能である。
また、本実施形態において、サーバー１は、顧客に対する通知を行う電子メールや各種メッセンジャー（以下、単に「メール」という。）の送信や受信を行うサービス（service、daemon）を含んでいる。
なお、サーバー１は、画像処理、ＯＣＲ（Optical Character Recognition）処理、分類処理、及び、電子メールや共有フォルダー（文書ボックス、保存フォルダー）や業務若しくは事務用のＤＭＳ（Document Management System）等への送信処理を実行してもよい。
また、サーバー１は、イントラネット内のサーバーであってもよい。
【００１３】
画像形成装置２は、ＭＦＰ、ネットワークスキャナー、ドキュメントスキャナー、ネットワークＦＡＸ、スキャナー機能付きのプリンター等のドキュメント機器である。また、画像形成装置２は、保守管理用のアプリを実行することが可能であってもよい。
また、画像形成装置２は、カラー又は白黒印刷、ファクシミリ送受信、ネットワークファクシミリ送受信、複写、スキャンによる電子文書化、ネットワークスキャン、電子文書を格納する文書ボックス等の各種の機能を備えていてもよい。また、画像形成装置２は、印刷機能を有するＭＦＰやプリンター等の場合、感光体ドラム、露光部、現像部、転写部、及び定着部等を備えている。これにより、画像形成装置２は、帯電、露光、現像、転写、定着からなる画像形成プロセスを実行することで、記録紙にトナー像を記録し、印刷することが可能である。
【００１４】
端末３は、ユーザーの使用するＰＣ、スマートフォン、ＰＤＡ（Personal Data Assistant）、携帯電話等の端末である。端末３は、各種汎用のＯＳ（Operating System）が動作している。
また、端末３は、アプリをインストール（install）することが可能であってもよい。このアプリは、画像形成装置２の管理用の専用アプリ、メール送受信用のアプリ、ＷＷＷブラウザー等の管理画面へアクセスするためのアプリ等を含んでいてもよい。
また、端末３は、これらのアプリを用いて、サーバー１でプライバシーポリシーの更新等の承諾を求める通知（以下、「承諾依頼通知」という。）を受信し、ユーザーによる回答や再回答をサーバー１へ送信することが可能である。
【００１５】
また、端末３は、専用アプリやメールやブラウザー等を介して、顧客環境における画像形成装置２の課金、使用、故障、保守等の状況についての各種通知を受信することが可能である。この各種通知は、サーバー１の管理画面上で表示されるリストやフォームやダイアログボックス等の表示、各種情報をまとめた文章等のレポート、メールや専用アプリによるプッシュ（push）通知等であってもよい。
また、ユーザーは、端末３の専用アプリやブラウザー等により、ＧＵＩ（Graphical Interface）を用いて、サーバー１の管理画面から、画像形成装置２の各種通知、課金、使用、故障、保守等の情報を閲覧することも可能である。また、下記で説明するように、ユーザーの権限等によっては、サーバー１の管理画面から、各種設定を変更することも可能である。
【００１６】
ここで、本実施形態の画像形成システムＸにおいては、各ユーザーは、顧客の会社や組織等のグループに所属している。この上で、画像形成システムＸでは、各ユーザーは、顧客であるユーザーの権限により、「管理者（manager）」「サービスパーソン（service）」「一般顧客（customer）」のような役職（role）に階層的に分類されて管理される。
このうち、管理者は、顧客のグループ内で他のユーザーを管理する。また、管理者は、管理画面から、画像形成装置２の課金、使用、故障、保守等の情報の設定を変更すること等が可能であってもよい。また、管理者は、当該管理者が含まれるグループのユーザーの削除、作成、設定変更等が可能であってもよい。また、管理者は、端末３により、自身を含む通知等の設定も管理可能である。このように、管理者は、グループ内で最上位の権限をもつユーザーである。
また、サービスパーソンは、顧客のグループ内の画像形成装置２を保守管理する担当者等のユーザーである。サービスパーソンは、端末３により、管理者の下で各種管理等を行う比較的上位の権限をもつ、上位階層のユーザーであってもよい。
また、一般顧客は、その他の一般的な顧客のユーザーである。一般顧客は、端末３にて、主に管理画面から各種情報を閲覧可能で、メール等で各種通知を受け取ることが可能であってもよい。しかしながら、一般顧客は、設定や変更等はできなくてもよい。すなわち、一般顧客は、権限の低い下位階層のユーザーであってもよい。
なお、このグループ内のユーザーの分類（役職）とは別に、画像形成システムＸのシステム側のアドミニストレーター等が、別途存在していてもよい。
【００１７】
ネットワーク５は、ＬＡＮ（Local Area Network）等のイントラネット（Intranet）、インターネットや携帯電話網等のＷＡＮ（Wide Area Network）等のネットワークである。
サーバー１及び各画像形成装置２は、ルーター（Router）やゲートウェイ（Gateway）等を介して、ネットワーク５に接続されていてもよい。また、ネットワーク５は、ＶＰＮ（Virtual Private Network）を構成していてもよい。
【００１８】
次に、図２により、サーバー１の構成について説明する。
サーバー１は、制御部１０、ネットワーク送受信部１５、及び記憶部１９を含んでいる。
【００１９】
制御部１０は、ＧＰＰ（General Purpose Processor）、ＣＰＵ（Central Processing Unit、中央処理装置）、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＧＰＵ（Graphics Processing Unit）、ＡＳＩＣ（Application Specific Processor、特定用途向けプロセッサー）等の情報処理手段である。
制御部１０は、記憶部１９のＲＯＭやＳＳＤやＨＤＤに記憶されている制御プログラムを読み出して、この制御プログラムをＲＡＭに展開させて実行することで、後述する機能部として動作させられる。
【００２０】
ネットワーク送受信部１５は、ネットワーク５に接続するためのＬＡＮボードや無線送受信機等を含むネットワーク接続手段である。
【００２１】
記憶部１９は、一時的でない記録媒体を用いた記憶手段である。記憶部１９は、主記憶部として、ＲＡＭ（Random Access Memory）等を含んでいてもよい。また、記憶部１９は、補助記憶部として、ＲＯＭ（Read Only Memory）、ｅＭＭＣ（embedded Multi Media Card）、ＳＳＤ（Solid State Drive）等のフラッシュメモリー、及びＨＤＤ（Hard Disk Drive）等含んでいてもよい。この場合、記憶部１９の補助記憶部には、サーバー１の動作制御を行うための制御プログラムが格納されていてもよい。
【００２２】
なお、制御部１０は、ＲＡＭやＲＯＭやフラッシュメモリー等を内蔵していてもよい。
【００２３】
〔画像形成システムＸの機能構成〕
ここで、図３を参照し、本発明の実施の形態に係る画像形成システムＸの主にサーバー１の機能構成について説明する。
サーバー１の制御部１０は、機能部として、ユーザー通知部１００、回答取得部１１０、再通知送信部１２０、再回答取得部１３０、及びユーザー削除部１４０を備えている。
記憶部１９は、ユーザーＤＢ２００、回答情報２１０、再通知２２０、及び再回答情報２３０を格納する。
【００２４】
ユーザー通知部１００は、ユーザーＤＢ２００に登録されたユーザーに対して、承諾依頼通知を通知する。また、ユーザー通知部１００は、例えば、端末３に表示される管理画面において、ダイアログボックスを表示させることで、この承諾依頼通知を行ってもよい。また、この承諾依頼通知は、ユーザーのプライバシーポリシーの更新の通知であってもよい。
【００２５】
回答取得部１１０は、ユーザー通知部１００により行われた通知に対するユーザーの回答情報２１０を取得する。
また、回答取得部１１０は、例えば、端末３に表示される管理画面において、ユーザー通知部１００により表示されたダイアログボックスへの入力データを、この回答情報２１０として取得してもよい。
【００２６】
再通知送信部１２０は、回答取得部１１０により承諾の回答情報２１０が取得されなかった場合、ユーザーに対して、再通知２２０を別途送信する。また、再通知送信部１２０は、再通知２２０を作成し、ユーザー通知部１００の通知とは別途、送信してもよい。また、この再通知２２０には、後述するように、ユーザーの再回答のための送信情報を含んでいてもよい。また、再通知送信部１２０は、サーバー１へアクセスするためのＵＲＬとエンコードされたデータを含むリンクを送信情報として作成し、このリンクを含むメールを再通知２２０として送信してもよい。
【００２７】
再回答取得部１３０は、再通知送信部１２０により送信された再通知２２０において、送信情報に対応した再回答情報２３０を取得する。
また、再回答取得部１３０は、この再回答情報２３０を、サーバー１へアクセスするためのＵＲＬとエンコードされたデータとして取得してもよい。また、再回答取得部１３０は、端末３のブラウザーや専用アプリ等からサーバー１へのこの再回答の際に、管理画面を表示する際と同様のユーザー認証を実行させてもよい。これにより、ユーザーの詐称やリンクの誤押下等による再回答を取得しにくくなり、ユーザーの意図に沿った再回答情報２３０を取得可能となる。
【００２８】
ユーザー削除部１４０は、再回答取得部１３０により取得された再回答情報２３０が承諾でなかった場合、ユーザーをユーザーＤＢ２００から削除する。
また、ユーザー削除部１４０は、承諾を求める対象となるユーザーが管理者であった場合、グループ内で他のユーザーのいずれかを新たな管理者として設定してからユーザーを削除する。
また、ユーザー削除部１４０は、ユーザーの削除に際して、グループ内で新たな管理者を設定する場合、削除するユーザーの通知設定を、新たな管理者へ引き継ぐ。
また、ユーザー削除部１４０は、グループ内で新たな管理者を設定しない場合、削除するユーザーの通知設定をそのままにして、ユーザーへのその後の通知を一時保存する。また、ユーザー削除部１４０は、その旨をグループ内の管理者へ通知する。
【００２９】
ユーザーＤＢ２００は、画像形成システムＸのユーザーのデータベースである。
本実施形態においては、ユーザーＤＢ２００は、ユーザー毎に、プライバシーポリシー等の承諾の有無を示すポリシー設定、所属グループ、メールの送信先であるメールアドレス、ユーザーのＩＤ（Identification）であるユーザーＩＤ、ユーザーの名前、グループ内の権限による分類（役職）等の設定の情報を含んでいてもよい。また、ユーザーＤＢ２００は、ユーザー毎に、ユーザー認証用のパスワード等、各種通知の通知設定、承諾依頼通知を行ってからの経過時間等の情報を含んでいてもよい。この通知設定は、課金、使用、故障、保守等の情報のうち、どのような種類の情報の通知を行うかについての設定を含んでいてもよい。また、この通知設定は、各種通知のどの種類をレポートにまとめるのか、特定のユーザーについての課金や使用の情報を通知するか、故障や保守等についての情報をサービスパーソンに直接連絡するか等の情報を含んでいてもよい。すなわち、通知設定は、ユーザーの役職等又は管理者等の設定により、どのような各種通知を取得するかについて、ユーザー毎に異なる設定を含んでいてもよい。
【００３０】
回答情報２１０は、ユーザー通知部１００により行われた通知に対するユーザーの回答を含む情報である。回答情報２１０は、端末３の管理画面において表示される、承諾依頼通知のダイアログボックスにおけるボタン等の入力データであってもよい。また、回答情報２１０は、承諾又は非承諾の情報を含んでいてもよい。
【００３１】
再通知２２０は、承諾又は非承諾の再回答を送信するための送信情報を含む通知である。
また、再通知２２０は、サーバー１のサービスにより送信されるメールのメッセージであってもよい。また、送信情報は、このメール内の承諾又は非承諾の再回答情報２３０を送信するためのリンクであってもよい。このリンクは、サーバー１にアクセスするためのＵＲＬ（Uniform Resource Locator）と、エンコードされた承認又は非承認の情報を含んでいてもよい。また、このリンクは、端末３のメールのアプリ等からクリック等することで、サーバー１へ送信可能に設定されていてもよい。
【００３２】
再回答情報２３０は、通知に対する承諾又は非承諾の再回答の情報である。再回答情報２３０は、例えば、サーバー１のＷＷＷサーバーのＣＧＩやＡＳＰ等で取得される、ＵＲＬとエンコードされた承認又は非承認の情報であってもよい。
【００３３】
ここで、サーバー１の制御部１０は、記憶部１９に記憶された制御プログラムを実行することで、ユーザー通知部１００、回答取得部１１０、再通知送信部１２０、再回答取得部１３０、及びユーザー削除部１４０として機能させられる。
また、上述のサーバー１の各部は、本発明の画像形成方法を実行するハードウェア資源となる。
なお、上述の機能構成の一部又は任意の組み合わせをＩＣやプログラマブルロジック等でハードウェア的に構成してもよい。
【００３４】
〔サーバー１によるユーザー回答削除処理〕
次に、図４〜図７を参照して、本発明の実施の形態に係る画像形成システムＸのサーバー１によるユーザー回答削除処理の説明を行う。
本実施形態のユーザー回答削除処理では、ユーザーＤＢ２００に登録されたユーザーに対して、承諾依頼通知を行う。また、通知に対するユーザーの回答情報２１０を取得する。ここで、承諾の回答情報２１０が取得されなかった場合、ユーザーに対して再通知２２０を別途送信する。また、送信された再通知２２０において、再回答情報２３０を取得する。そして、取得された再回答情報２３０が承諾でなかった場合、ユーザーをユーザーＤＢ２００から削除する。
本実施形態のユーザー回答削除処理は、主に制御部１０が、記憶部１９に記憶されたプログラムを、各部と協働し、ハードウェア資源を用いて実行する。
以下で、図４のフローチャートを参照して、ユーザー回答削除処理の詳細をステップ毎に説明する。
【００３５】
（ステップＳ１０１）
まず、ユーザー通知部１００が、ユーザー通知処理を行う。
ユーザー通知部１００は、ユーザーＤＢ２００に登録されたユーザーに対して、承諾依頼通知を行う。
具体的には、本実施形態において、ユーザー通知部１００は、例えば、ユーザーが端末３にて、サーバー１の管理画面を開く際に、ユーザー認証を行う。ユーザー通知部１００は、ユーザーＩＤやパスワード等をユーザーに入力させて、ユーザー認証を行ってもよい。
ここで、ユーザー通知部１００は、プライバシーポリシーの更新等によりユーザーに承諾を求める必要が生じた場合には、この承諾依頼通知のダイアログボックスを端末３へ表示させる。ユーザー通知部１００は、このダイアログボックスにおいて、当該プライバシーポリシー等と、「承諾」「非承諾」を示すボタンとを表示させてもよい。
【００３６】
（ステップＳ１０２）
次に、回答取得部１１０が、回答取得処理を行う。
回答取得部１１０は、ユーザー通知部１００により行われた通知に対するユーザーの回答情報２１０を取得して、記憶部１９に格納する。
回答取得部１１０は、例えば、上述のダイアログボックスにおいて、「承諾」又は「非承諾」を示すボタンが押下された場合、どちらが押下されたのかの結果を入力データとして取得する。つまり、この入力データには、承諾又は非承諾の情報を含む。
【００３７】
（ステップＳ１０３）
次に、再通知送信部１２０が、承諾の回答を取得したか否かを判断する。再通知送信部１２０は、回答情報２１０を参照し、承諾の情報を含む場合に、Ｙｅｓと判断する。再通知送信部１２０は、それ以外の場合には、Ｎｏと判断する。この「それ以外の場合」には、回答情報２１０に非承諾の情報を含む場合、回答が拒否されたりダイアログボックスが閉じられたりした場合、及び回答を求めてから特定の時間が経過したりした場合等が含まれてもよい。
Ｙｅｓの場合、再通知送信部１２０は、ユーザー回答削除処理を終了する。この際、再通知送信部１２０は、ユーザーＤＢ２００のポリシー設定を「承諾」に変更してもよい。
Ｎｏの場合、再通知送信部１２０は、処理をステップＳ１０４に進める。
【００３８】
（ステップＳ１０４）
承諾の回答を取得しなかった場合、再通知送信部１２０が、再通知送信処理を行う。
再通知送信部１２０は、ユーザーに対して、再通知２２０を別途送信する。再通知送信部１２０は、例えば、ユーザーＤＢ２００を参照し、承諾依頼通知を行ってからの経過時間が特定時間を超えた場合、承諾又は非承諾の再回答情報２３０を送信するための送信情報のＵＲＬ等を作成し、これを含めたメールを作成する。この上で、再通知送信部１２０は、ユーザーのメールアドレス宛に、承諾の再回答を求める再通知２２０として、作成したメールを送信する。
【００３９】
（ステップＳ１０５）
次に、回答取得部１１０が、再回答取得処理を行う。
再回答取得部１３０は、再通知２２０の送信情報に対応した再回答情報２３０を取得する。
具体的には、再回答取得部１３０は、再通知２２０のメールのリンク等が押下された際に、ユーザーの端末３からサーバー１へのアクセスをＷＷＷサーバー等で取得する。これにより、再回答取得部１３０は、ＵＲＬとエンコードされたデータを取得して、これをデコードしたものを、再回答情報２３０として記憶部１９に格納する。また、このアクセスの際に、再回答取得部１３０は、ユーザーＩＤやパスワード等をユーザーに入力させて、ユーザー認証を行ってもよい。
なお、ユーザー削除部１４０は、再回答を特定の期間、取得できなかった場合には、グループの管理者にメール等で通知してもよい。また、この場合、再通知送信部１２０は、再度、再回答のメールを作成して、再回答を求めるユーザーに送信してもよい。
【００４０】
（ステップＳ１０６）
次に、ユーザー削除部１４０が、承諾の再回答を取得したか否かを判断する。ユーザー削除部１４０は、再回答情報２３０に承認の情報が含まれていた場合に、Ｙｅｓと判断する。ユーザー削除部１４０は、再回答情報２３０に非承認の情報が含まれていた場合には、Ｎｏと判断する。
Ｙｅｓの場合、ユーザー削除部１４０は、ユーザー回答削除処理を終了する。この際、ユーザー削除部１４０は、ユーザーＤＢ２００のポリシー設定を「承諾」に変更してもよい。
Ｎｏの場合、ユーザー削除部１４０は、処理をステップＳ１０７に進める。この際、ユーザー削除部１４０は、ユーザーＤＢ２００のポリシー設定を「非承諾」に変更してもよい。
【００４１】
（ステップＳ１０７）
承諾の再回答を取得しなかった場合、ユーザー削除部１４０が、当該非承諾のユーザーは管理者であるか否かを判断する。ユーザー削除部１４０は、承諾の再回答をしなかった当該ユーザーが管理者であった場合に、Ｙｅｓと判断する。ユーザー削除部１４０は、それ以外の場合には、Ｎｏと判断する。
Ｙｅｓの場合、ユーザー削除部１４０は、処理をステップＳ１０８に進める。
Ｎｏの場合、ユーザー削除部１４０は、処理をステップＳ１１０に進める。
【００４２】
（ステップＳ１０８）
管理者であった場合、ユーザー削除部１４０が、新管理者設定処理を行う。
ユーザー削除部１４０は、グループ内で他のユーザーのいずれかを新たな管理者として設定する。また、この際、ユーザー削除部１４０は、削除するユーザーの通知設定を、新たな管理者へ引き継ぎ、ユーザーＤＢ２００に設定する。
なお、ユーザー削除部１４０は、当該ユーザーが個人ユーザー等であり、他にグループに所属しているユーザーがいなかった等の場合には、アドミニストレーター等に通知してもよい。
【００４３】
図５の例により、この処理の詳細について説明する。図５の各表は、ユーザーＤＢ２００の一部を示す例である。この表において、「Ｐ」はポリシー設定の状態、「Ｇ」は所属グループ、メールアドレス、ユーザーＩＤ、ユーザーの名前、ユーザーの分類（役職）を示している。
ここで、図５（ａ）は、ポリシー設定の状態が三角で「非承諾」のユーザーが、グループ「Ａ」に所属し、当該ユーザーのユーザーＩＤが「ａｔ−ｋｄｃ」であり、管理者（Manager）である例を示す。
図５（ｂ）によると、この場合、ユーザー削除部１４０は、同じグループ「Ａ」に所属しており、より上位階層のサービスパーソン（service）であるユーザーＩＤ「ａｔ−ｋｄｃ−ｓｅｒｖｉｃｅ」のユーザーを、新たな管理者（Manager）に設定する。また、ユーザー削除部１４０は、元の管理者であった当該非承諾のユーザー「ａｔ−ｋｄｃ」の通知設定を、「ａｔ−ｋｄｃ−ｓｅｒｖｉｃｅ」に設定する。これにより、「ａｔ−ｋｄｃ−ｓｅｒｖｉｃｅ」は、「ａｔ−ｋｄｃ」と同様の種類の情報の通知を取得するようになる。
【００４４】
（ステップＳ１０９）
次に、ユーザー削除部１４０が、新管理者通知処理を行う。
ユーザー削除部１４０は、設定された新たな管理者に対して、新たな管理者に設定されて通知設定を引き継いだ旨を通知する。ユーザー削除部１４０は、この通知について、メールを作成して行ってもよい。
その後、ユーザー削除部１４０は、処理をステップＳ１１２に進める。
【００４５】
（ステップＳ１１０）
管理者でなかった場合、ユーザー削除部１４０が、通知一時保存設定処理を行う。
ユーザー削除部１４０は、非承諾のユーザーへのその後の各種通知を送信等せず、一時保存するようにユーザーＤＢ２００に設定する。この際、ユーザー削除部１４０は、削除するユーザーの通知設定をそのままにしておいてもよい。
【００４６】
図６の例により説明する。図６（ａ）においては、「非承諾」のユーザーが、グループ「Ａ」に所属し、当該ユーザーのユーザーＩＤが「ｔｏＭｏｖｅ．Ｕｓｅｒ」であり、一般顧客（Customer）である例を示す。
【００４７】
（ステップＳ１１１）
次に、ユーザー削除部１４０が、管理者通知処理を行う。
ユーザー削除部１４０は、非承諾のユーザーの所属するグループの管理者へ、ユーザーへのその後の通知を一時保存する旨を、メールで通知する。ユーザー削除部１４０は、図６（ａ）の例では、グループ「Ａ」の管理者である「ａｔ−ｋｄｃ」へ、このメールを送信する。
図７により説明すると、管理者は、端末３により、削除される非承諾のユーザー宛であった、一時保存された各種通知を閲覧可能である。図７の各種通知例３００は、管理画面に表示された各種通知の例である。この例では、削除された「ｔｏＭｏｖｅ．Ｕｓｅｒ」は、ペーパージャムのイベント、印刷ページ数のページカウント、トナー量低下等の保守の情報を各種通知として受信している。管理者は、この一時保存された各種通知を閲覧することで、適切な対応を行うことが可能となる。また、管理者は、この一時保存された各種通知を参照して、適切なユーザーに通知設定を引き継がせることも可能となる。
【００４８】
（ステップＳ１１２）
ここで、ユーザー削除部１４０が、ユーザー削除処理を行う。
ユーザー削除部１４０は、再回答取得部１３０により取得された再回答情報２３０が承諾でなかった場合、ユーザーをユーザーＤＢ２００から削除する。
図５（ｂ）の例では、ユーザー削除部１４０は、「ａｔ−ｋｄｃ」の各データをユーザーＤＢ２００から削除する。また、図６（ｂ）の例では、ユーザー削除部１４０は、「ｔｏＭｏｖｅ．Ｕｓｅｒ」の各データをユーザーＤＢ２００から削除する。
以上により、本発明の実施の形態に係るユーザー回答削除処理を終了する。
【００４９】
以上のように構成することで、以下のような効果を得ることができる。
従来、特許文献１のような従来の画像形成システムのサーバー（情報処理装置）では、システムによるユーザーの削除は想定されていなかった。このため、プライバシーポリシー等を承諾しなかったユーザーのデータを単純に削除すると、各種の通知が即時にできなくなり、不具合が生じることがあった。
これに対して、本発明の実施の形態に係るサーバー１は、ユーザーＤＢ２００に登録されたユーザーに対して、承諾依頼通知を行うユーザー通知部１００と、ユーザー通知部１００により行われた通知に対するユーザーの回答情報２１０を取得する回答取得部１１０と、回答取得部１１０により承諾の回答情報２１０が取得されなかった場合、ユーザーに対して、承諾又は非承諾の再回答情報２３０を送信するための送信情報を含む再通知２２０を別途送信する再通知送信部１２０と、再通知送信部１２０により送信された再通知２２０において、送信情報に対応した再回答情報２３０を取得する再回答取得部１３０と、再回答取得部１３０により取得された再回答情報２３０が承諾でなかった場合、ユーザーをユーザーＤＢ２００から削除するユーザー削除部１４０とを備える情報処理装置であることを特徴とする。
このように構成することで、ユーザーの意図に沿ってユーザーを削除することが可能となる。また、承諾を得られなかった場合に再通知２２０を別途送信することで、非承諾のユーザーについて確認を取ってから削除することが可能となる。つまり、何らかの原因により、承諾依頼通知にて承諾の回答が得られなかった場合に、再度の承諾が得られる可能性が高まる。また、はっきりと非承諾の再回答を得ることで、ユーザーの誤削除を確実に防止することができる。
【００５０】
また、本発明の実施の形態に係るサーバー１において、承諾依頼通知は、ユーザーのプライバシーポリシーの更新の通知であり、再通知送信部１２０は、リンクを含むメールにより再通知２２０を別途送信することを特徴とする。
このように構成することで、プライバシーポリシーの更新を拒否するユーザーに対して、ユーザーの「削除される権利」を具体的に行使させることが可能となる。
また、リンクを含むメールにより再通知２２０を別途送信することで、ユーザーは、メールのリンクをクリック等すれば、このプライバシーポリシーの更新の承諾の可否をサーバー１へ送信することができ、ユーザーの手間を減らすことができる。
【００５１】
また、本発明の実施の形態に係るサーバー１において、ユーザー削除部１４０は、ユーザーが、グループ内で他のユーザーを管理する管理者であった場合に、グループ内で他のユーザーのいずれかを新たな管理者として設定してからユーザーを削除することを特徴とする。
このように構成することで、たとえグループ内で管理者が削除されても、グループ内の他のユーザーは、画像形成システムＸを支障なく利用可能となる。
また、グループ内で他のユーザーを階層的な役割の順番で新たな管理者として選択することも可能となる。よって、管理者不在による不具合等を避けることができる。
【００５２】
また、本発明の実施の形態に係るサーバー１において、ユーザー削除部１４０は、新たな管理者を設定する場合、削除するユーザーの通知設定を新たな管理者へ引き継ぎ、新たな管理者を設定しない場合、削除するユーザーの通知設定をそのままにして、ユーザーへのその後の通知を一時保存する旨を管理者へ通知することを特徴とする。
このように構成することで、グループ内で設定された新たな管理者に、元の管理者の通知設定を引き継ぐことが可能となる。これにより、管理者向けに特定の各種通知が行われていた場合に、新たな管理者が、特に設定等を必要とせずに、この特定の各種通知を引き継いで取得することが可能となる。
また、グループ内で新たな管理者を設定しなくてもよい場合、つまり、管理者以外のユーザーを削除する場合には、管理者が、この削除されるユーザーの各種通知を適切に他のユーザーに引き継がせることが可能となる。この際に、管理者は、一時保存された各種通知を閲覧して、引き継がせる他のユーザーを選択することも可能となる。
【００５３】
なお、本発明は、画像形成システムのサーバー１以外の情報処理装置にも適用できる。この場合、画像形成装置２以外のネットワークスキャナー、スキャナーをＵＳＢ等で別途接続したサーバー等の管理を行う情報処理装置に適用することも可能である。
また、本発明は、ユーザーのプライバシーポリシーの更新時以外にも、ユーザーの削除を行う他の種類の各種情報処理装置に適用可能である。つまり、ユーザーが承諾しないと使用を継続させられず、当該ユーザーをデータベースから削除させなければならないような、各種のシチュエーションについて適用可能である。
【００５４】
また、上記実施の形態の構成及び動作は例であって、本発明の趣旨を逸脱しない範囲で適宜変更して実行することができることは言うまでもない。
【符号の説明】
【００５５】
１  サーバー
２  画像形成装置
３  端末
５  ネットワーク
１０  制御部
１５  ネットワーク送受信部
１９  記憶部
１００  ユーザー通知部
１１０  回答取得部
１２０  再通知送信部
１３０  再回答取得部
１４０  ユーザー削除部
２００  ユーザーＤＢ
２１０  回答情報
２２０  再通知
２３０  再回答情報
３００  各種通知例
Ｘ  画像形成システム
【図１】
2019079399.tif 000003
【図２】
2019079399.tif 000004
【図３】
2019079399.tif 000005
【図４】
2019079399.tif 000006
【図５】
2019079399.tif 000007
【図６】
2019079399.tif 000008
【図７】
2019079399.tif 000009