JP2020154868A - 情報処理システムおよびプログラム - Google Patents

Abstract

【課題】ユーザ情報を管理して各ユーザに複数のサービスを提供するシステムにおいて、サービスの機能の重要度や変更されたユーザ情報の種類に応じて、ユーザ情報の変更の通知を制御する。【解決手段】ネットワーク上でサービスを提供する複数のサーバがサービスを提供する際に用いるユーザ情報を管理するユーザ情報管理ＤＢ１１０と、ユーザ情報の変更要求を受け付けると、この変更要求に係るユーザ情報を用いるサービスの種類および変更要求によるユーザ情報の変更内容により、少なくともサービスごとに特定される通知先および通知時期を含む、ユーザ情報の変更の通知方法を変化させる制御を行う通知方法管理ＤＢ１２０、個別通知管理ＤＢ１３０、通知制御部１４０および通知処理部１５０と、を備える。【選択図】図１

Description

本発明は、情報処理システムおよびプログラムに関する。

ユーザ情報を管理して各ユーザに複数のサービスを提供するシステム（例えば、マルチテナント型のクラウドサービス）では、ユーザ情報の変更があった場合、承認権限のある管理者に通知すると共に、各サービスに反映させる必要がある。

特許文献１には、ユーザ情報として電子メールの本文から抽出した組織名と当該電子メールの送信先ドメインとの組み合わせ毎に送信履歴を管理しておき、送信指示された電子メールから抽出した組織名と送信先ドメインとの組み合わせが管理された組み合わせに存在しない場合、送信指示された電子メールの送信を保留すると共に、保留された電子メールについて、送信を許可するか否かの監査を行うことが開示されている。

特許文献２には、ユーザが利用する機能に応じて送信先メールアドレスの有効性を提示する仕組みを導入し、送信先メールアドレスを必要とする場合のみユーザは送信先メールアドレスの有効性を確認できるようにする技術が開示されている。

特開２０１８−５４１５号公報 特開２０１８−１９６０５８号公報

サービスの機能の重要度や変更されたユーザ情報の種類に応じて、ユーザ情報が変更された場合の通知先や通知のタイミングを制御することが求められる場合がある。

本発明は、ユーザ情報を管理して各ユーザに複数のサービスを提供するシステムにおいて、サービスの機能の重要度や変更されたユーザ情報の種類に応じて、ユーザ情報の変更の通知を制御することを目的とする。

請求項１に係る本発明は、
ネットワーク上でサービスを提供する複数のサーバがサービスを提供する際に用いるユーザ情報を管理するユーザ情報管理手段と、
前記ユーザ情報の変更要求を受け付けると、当該変更要求に係るユーザ情報を用いるサービスの種類および当該変更要求による当該ユーザ情報の変更内容により、少なくともサービスごとに特定される通知先および通知時期を含む、当該ユーザ情報の変更の通知方法を変化させる制御を行う制御手段と、
を備えることを特徴とする、情報処理システムである。
請求項２に係る本発明は、
前記制御手段は、前記ユーザ情報の変更の通知先に当該変更の承認者が含まれるか否かを判断し、当該通知先に当該承認者が含まれる場合、まず当該承認者に通知を行い、当該ユーザ情報の変更が承認された後に、当該承認者以外の通知先へ通知するように当該ユーザ情報の通知を制御することを特徴とする、請求項１に記載の情報処理システムである。
請求項３に係る本発明は、
前記制御手段は、前記ユーザ情報の変更に対する承認者が複数ある場合、当該複数の承認者のうち、当該ユーザ情報を用いる各サービスに対して予め定められた重要度が最も高いサービスに係る承認者の承認結果を採用することを特徴とする、請求項２に記載の情報処理システムである。
請求項４に係る本発明は、
前記制御手段は、前記ユーザ情報を用いる各サービスに対して予め定められた重要度が最も高いサービスが複数あり、当該複数のサービスに係る承認者の承認結果が異なる場合、当該複数の承認者に対して上位の権限を有する者を特別承認者とし、当該特別承認者の承認結果を採用することを特徴とする、請求項３に記載の情報処理システムである。
請求項５に係る本発明は、
前記制御手段は、前記変更要求による前記ユーザ情報の変更内容のうち、当該変更要求の変更対象である当該ユーザ情報の項目に基づいて、前記通知方法を決定することを特徴とする、請求項１に記載の情報処理システムである。
請求項６に係る本発明は、
前記制御手段は、前記変更要求による前記ユーザ情報の変更内容のうち、当該変更要求の変更対象である当該ユーザ情報の項目および変更対象以外の当該ユーザ情報の項目の内容に基づいて前記通知方法を決定することを特徴とする、請求項５に記載の情報処理システムである。
請求項７に係る本発明は、
コンピュータに、
ネットワーク上でサービスを提供する複数のサーバがサービスを提供する際に用いるユーザ情報を管理する機能と、
前記ユーザ情報の変更要求を受け付けると、当該変更要求に係るユーザ情報を用いるサービスの種類および当該変更要求による当該ユーザ情報の変更内容に基づいて、少なくともサービスごとに特定される通知先および通知時期を含む、当該ユーザ情報の変更の通知方法を変化させる制御を行う機能と、
を実現させることを特徴とする、プログラムである。

請求項１の発明によれば、ユーザ情報を管理して各ユーザに複数のサービスを提供するシステムにおいて、ユーザ情報の変更を一律に管理者等に通知する構成と比較して、サービスの機能の重要度や変更されたユーザ情報の種類に応じて、ユーザ情報の変更の通知を制御することができる。
請求項２の発明によれば、ユーザ情報の変更を一律に管理者等に通知する構成と比較して、承認者による承認を経て確定した変更について通知することができる。
請求項３の発明によれば、複数の承認者の承認結果を同等に扱う構成と比較して、重要度の高いサービスにおける承認結果を優先することで、変更の承認に対する混乱を回避することができる。
請求項４の発明によれば、複数の承認者の承認結果を同等に扱う構成と比較して、上位の権限を有する承認者の承認結果を優先することで、変更の承認に対する混乱を回避することができる。
請求項５の発明によれば、ユーザ情報の変更を一律に管理者等に通知する構成と比較して、変更内容に基づいて通知先および通知時期を設定することができる。
請求項６の発明によれば、ユーザ情報の変更を一律に管理者等に通知する構成と比較して、変更対象であるユーザ情報自体の内容に基づいて通知先および通知時期を設定することができる。
請求項７の発明によれば、本発明のプログラムをインストールしたコンピュータによりユーザ情報を管理して各ユーザに複数のサービスを提供するシステムにおいて、ユーザ情報の変更を一律に管理者等に通知する構成と比較して、サービスの機能の重要度や変更されたユーザ情報の種類に応じて、ユーザ情報の変更の通知を制御することができる。

本実施形態が適用される情報処理システムの構成を示す図である。 ユーザ情報管理ＤＢの構成例を示す図である。 通知方法管理ＤＢの構成例を示す図である。 個別通知管理ＤＢの構成例を示す図である。 通知制御部および通知処理部の動作を示すフローチャートである。 承認者が複数ある場合における通知制御部による承認結果の選択方法を示すフローチャートである。 本実施形態による通知制御の適用例を示す図であり、図７（Ａ）は、重要度の異なるサービスに関する複数の承認者がいる状態を示す図であり、図７（Ｂ）は、同じ重要度のサービスに関する複数の承認者がいる状態を示す図であり、図７（Ｃ）は、サービスが複数のテナントの業務に利用され、各テナントに承認者がいる状態を示す図である。

以下、添付図面を参照して、本発明の実施の形態について詳細に説明する。
＜システム構成＞
本実施形態の情報処理システムは、テナントから処理要求を受け付け、受け付けた処理要求に応じた処理を実行することによりサービスを提供する。テナントとは、論理的に分割された、情報処理システムによるサービスを利用する利用者の単位である。すなわち、テナントが情報処理システムに対して処理要求を行い、情報処理システムによる処理が実行される。複数のテナントが情報処理システムによるサービスを共有する形式のサービスを、マルチテナント型サービスと呼ぶ。

サービスを利用するユーザは、何れかのテナントに属している。そして、各ユーザは、自身が属するテナントから割り当てられた権限によりサービスを要求する。テナントは、企業や企業内の部署、その他の組織に対応付けて設定したり、顧客ごとに設定したりする等、情報処理システムが提供するサービスの内容や運用方法、仕様等に応じて様々に設定し得る。一例として、本実施形態では、ユーザが所属する会社ごとにテナントが設定されているものとする。

図１は、本実施形態が適用される情報処理システムの構成を示す図である。本実施形態の情報処理システムは、テナントを管理する管理サーバ１００として実現される。管理サーバ１００は、ユーザ情報管理データベース（ＤＢ）１１０と、通知方法管理データベース（ＤＢ）１２０と、個別通知管理データベース（ＤＢ）１３０と、通知制御部１４０と、通知処理部１５０とを備える。

管理サーバ１００には、管理サーバ１００により管理されるテナントからの要求に応じてサービスを提供するサービス提供手段としての外部サーバ２００が接続されている。外部サーバ２００は、提供するサービスにおいて、テナントに属す個々のユーザの情報を使用する。サービスを提供するために使用されるユーザ情報の種類は、サービスの種類に応じて個別に定められる。なお、図１には、一つの外部サーバ２００が記載されているが、実際には、サービスの種類等に応じて複数の外部サーバ２００が存在する。

ユーザ情報管理ＤＢ１１０は、管理サーバ１００により管理されるテナントに属して、外部サーバ２００によるサービスを利用するユーザのユーザ情報を一元管理するデータベースである。外部サーバ２００は、ユーザ情報管理ＤＢ１１０に保持されているユーザ情報を、サービスを提供するために用いる。

図２は、ユーザ情報管理ＤＢ１１０の構成例を示す図である。図２に示すユーザ情報管理ＤＢ１１０には、ユーザごとに、「ユーザＩＤ」、「名前」、「メールアドレス」、「電話番号」、「所属会社名」の各項目に該当する情報が登録されて保持されている。図２に示すユーザ情報管理ＤＢ１１０には、ユーザＩＤ「ｆｘ９９９９９」のユーザ（名前「富士 太郎」）およびユーザＩＤ「ｆｘ９９９９１」のユーザ（名前「富士 花子」）のユーザ情報が例示されている。上述したように、本実施形態ではユーザ個人が所属する会社ごとにテナントが設定されている。したがって、図２に示すユーザ情報管理ＤＢ１１０の「所属会社名」は、テナントに対応する。

通知方法管理ＤＢ１２０は、ユーザ情報が変更された場合の通知方法を管理するデータベースである。通知方法管理ＤＢ１２０には、少なくとも、通知先および通知時期を特定する情報が登録される。ここで、ユーザ情報の変更に対する承認者がいる場合、かかる承認者も通知先に含まれる。承認者は、変更されるユーザ情報の項目ごとに異なる場合がある。

図３は、通知方法管理ＤＢ１２０の構成例を示す図である。図３に示す通知方法管理ＤＢ１２０には、通知方法の種別に応じて、「通知レベル」、「通知時期」、「通知媒体」、「通知先」、「付随処理」の各項目の情報が記録されている。図３に示す通知方法管理ＤＢ１２０において、「通知レベル」は、通知方法の種別を示す項目である。図３に示す通知方法管理ＤＢ１２０には、通知レベル１〜５までの種別が例示されている。なお、図示の例では通知レベルを５段階としているが、これは例示に過ぎず、４段階以下や６段階以上としても良い。

「通知時期」は、通知レベル１、２ではユーザ情報が変更された時（図では「ユーザ情報変更時」と記載）に設定されている。また、通知レベル３、４ではサービスが利用された時（図では「サービス利用時」と記載）に設定されている。また、通知レベル５では、通知を行わないことが設定されている。

「通知媒体」としては、通知レベル１〜３では電子メールによる通知（図では「メール通知」と記載）が設定されている。また、通知レベル４ではサービス利用時にユーザの情報端末に表示されるＵＩ（ユーザ・インターフェイス）画面上での表示による通知（図では「ＵＩ表示」と記載）が設定されている。

「通知先」には、通知レベル１ではテナント管理者が、通知レベル２ではサービス管理者が、通知レベル３ではキャビネット管理者が、通知レベル４ではサービスを利用するユーザ（図では「利用者」と記載）が、それぞれ設定されている。ここで、テナント管理者とは、ユーザ情報が変更されたユーザが属すテナントの管理者である。また、サービス管理者とは、変更されたユーザ情報を使用するサービスの管理者である。また、キャビネット管理者とは、ユーザ情報が変更されたユーザが属すキャビネットの管理者である。キャビネットとは、テナントにおいてサービスを利用するユーザのグループを表す。一のテナントにおいて複数のサービスを利用可能である場合、サービスごとにキャビネットが設定される。

「付随処理」とは、通知が行われた際に、付随して実行される処理である。この「付随処理」に基づき、通知先が承認者であるか否かが示される。通知レベル１では、変更されたユーザ情報を使用するサービスの提供機能が停止される。そして、通知先であるテナント管理者の承認があった場合に機能が再実行され、サービスの提供が再開される。したがって、通知レベル１の通知先は承認者である。また、通知レベル２では、変更されたユーザ情報を使用するサービスの提供機能が停止される。そして、通知先であるサービス管理者の承認があった場合に機能が再実行され、サービスの提供が再開される。したがって、通知レベル２の通知先は承認者である。また、通知レベル３では、通知先であるキャビネット管理者の承認または再設定を要求する。ここで、再設定とは、ユーザ情報の変更に伴って必要となるサービスの提供における設定変更を行うことである。したがって、通知レベル３の通知先は承認者である。通知レベル４および通知レベル５では、通知先の承認を必要とする処理が設定されておらず、これらの通知の通知先は承認者ではない。

個別通知管理ＤＢ１３０は、ユーザ情報の変更が行われた場合に、この変更に基づく通知を個別に管理するデータベースである。ユーザ情報の変更が行われると、通知制御部１４０により、このユーザ情報の変更を通知するための通知方法が特定される。そして、特定された通知方法と、ユーザ情報の変更内容と、変更されるユーザ情報を使用するサービスに応じて特定される業務重要度の情報とが関連付けられ、個別通知管理ＤＢ１３０に格納されて管理される。

図４は、個別通知管理ＤＢ１３０の構成例を示す図である。図４に示す個別通知管理ＤＢ１３０には、ユーザ情報の変更に応じて行われる通知ごとに、「テナント」、「サービス」、「業務重要度」、「ユーザＩＤ」、「使用中のユーザ情報」、「確認日」、「更新日」、「通知レベル」の各項目の情報が記録されている。図４に示す個別通知管理ＤＢ１３０において、「テナント」は、ユーザ情報が変更されたユーザが属すテナントであり、「サービス」は、変更されたユーザ情報を使用するサービスである。「業務重要度」は、「サービス」項目に登録されているサービスを利用する業務の重要度を示す。図示の例では、「業務重要度」として「大」、「中」、「小」の３段階が示されている。「ユーザＩＤ」は、ユーザ情報が変更されたユーザのＩＤ（識別情報）であり、「使用中のユーザ情報」は、変更対象となったユーザ情報である。「確認日」は、ユーザ情報の変更の通知が行われた（通知先で確認された）日であり、「更新日」は、ユーザ情報の変更が有効となった日である。「通知レベル」は、採用された通知方法の種別を示し、通知方法管理ＤＢ１２０の「通知レベル」に対応する。

通知制御部１４０は、ユーザ情報の変更要求を受け付け、このユーザ情報の変更の通知方法を決定する。具体的には、通知制御部１４０は、ユーザ情報の変更要求を受け付けると、変更要求に基づき変更の内容を特定する。また、通知制御部１４０は、変更されるユーザ情報を使用するサービスの種類を特定する。いずれのサービスがユーザ情報の何れの情報（項目）を使用するかは、各サービスを提供する外部サーバ２００から取得し得る。また、通知制御部１４０は、変更されるユーザ情報に該当するユーザが属するテナントと、変更されるユーザ情報を使用するサービスの種類とに基づき、このサービスを利用する業務の重要度を特定する。そして、通知制御部１４０は、これらの情報に基づき、このユーザ情報の変更の通知方法を決定する。また、通知制御部１４０は、これらの情報と決定した通知方法とを関連付けて、個別通知管理ＤＢ１３０に格納する。

ここで、サービスを利用する業務の重要度は、同じサービスであっても、テナントである組織全体の事業内容や、対象の業務においてどのようにサービスを利用しているか等の具体的な状況に応じて異なる場合がある。したがって、テナントおよびサービスごとに、変更されるユーザ情報の種類に対応させて業務重要度を予め定めておき、通知制御部１４０は、受け付けた変更要求により変更されるユーザ情報の種類に業務重要度を特定するようにしても良い。

また、ユーザ情報の変更内容に関しては、変更される情報（項目）の種類に応じて、選択するべき通知時期や通知媒体が異なる。例えば、電子メールアドレスの変更は、サービスの提供先に影響する可能性があるため、通知制御部１４０が変更要求を受け付けてから速やかに電子メール等の手段により通知先へ通知し、承認を得る必要がある。一方、ユーザ情報にユーザの使用言語がある場合、この使用言語の変更は、サービスの提供時に用いられる言語に対して影響があるものの、サービスを提供するための処理自体に対する影響は小さいと考えられる。したがって、実際にサービスが利用される際に、ＵＩ表示等により利用者に対して通知するとしても良い。このように、通知制御部１４０は、変更される項目に基づいて、通知方法を決定する。

この他、通知制御部１４０は、変更される項目以外の項目の内容に基づいて通知方法を決定する場合もある。一例として、ユーザ情報が変更されるユーザのテナントにおける立場等によっても、ユーザ情報が変更された場合に、このユーザ情報を使用するサービスの業務に対する影響度が異なることが考えらえる。例えば、テナントの組織において役職についているユーザのユーザ情報が変更された場合と、組織における単なる構成員のユーザ情報が変更された場合とでは、前者の方が業務に対する影響が大きい場合があり得る。そこで、例えば、図２に示したユーザ情報管理ＤＢ１１０には記載していないが、ユーザ情報の一項目としてテナント（組織）におけるユーザの立場（役職の有無等）が登録されているものとする。そして、通知制御部１４０は、変更される項目だけでなく、変更されるユーザ情報の主体であるユーザの立場等の情報も考慮して通知方法を決定しても良い。

通知処理部１５０は、通知制御部１４０により決定された通知方法にしたがって、ユーザ情報の変更要求があったことを各々の通知先へ通知する。具体的には、通知処理部１５０は、通知制御部１４０からユーザ情報の変更要求を取得し、取得した変更要求に関する情報を個別通知管理ＤＢ１３０から読み出す。また、通知処理部１５０は、個別通知管理ＤＢ１３０から読み出した通知レベルの情報により通知方法管理ＤＢ１２０を参照し、対応する通知レベルの通知方法（通知時期、通知媒体、通知先）にしたがって通知を行う。

ユーザ情報のある項目が変更される場合、その項目の情報を使用するサービスが複数存在する場合がある。この場合、通知処理部１５０は、該当する全てのサービスに関して、対応する通知方法で通知を行う。このとき、何れかの通知の通知レベルが図３に示した通知方法管理ＤＢ１２０に示す通知レベル１〜３の何れかであった場合、ユーザ情報の変更が有効となるためには、通知先である承認者による承認を得る必要がある。したがって、通知処理部１５０は、まず承認者である通知先に通知を行い、承認者によりユーザ情報の変更が承認された後に残りの通知先に通知を行う。

また、複数の通知先において、図３に示した通知方法管理ＤＢ１２０に示す通知レベル１または２の承認者が複数ある場合を考える。この場合、複数の通知における通知レベルが１または２である場合、通知時期が同じ「ユーザ情報変更時」であり、何れも通知先の承認を必要とする。したがって、通知処理部１５０は、複数の承認者からの承認結果を得ることになる。しかし、一の承認者がユーザ情報の変更を承認し、他の一の承認者がユーザ情報の変更を非承認とすると、複数の承認結果が矛盾してしまう。そこで、通知処理部１５０は、通知先に複数の承認者がある場合、変更されるユーザ情報を使用するサービスのうち、業務重要度（そのサービスを利用する業務の重要度）が最も高いサービスに関する通知先である承認者の承認結果を採用する。すなわち、業務重要度が最も高いサービスに関する承認者がユーザ情報の変更を承認すれば、通知処理部１５０は、他の承認者の承認結果に関わらず、ユーザ情報の変更を有効とし、他の未通知の通知先へ通知する。反対に、業務重要度が最も高いサービスに関する承認者がユーザ情報の変更を非承認とすれば、通知処理部１５０は、他の承認者の承認結果に関わらず、ユーザ情報の変更を無効とする。この場合、他の未通知の通知先へは通知しなくても良い。

また、複数の通知先がある場合であって、業務重要度が最も高いサービスが複数ある場合を考える。この場合、上記の業務重要度を用いる方法では優先する承認結果を特定できない。そこで、通知処理部１５０は、かかる複数の承認者に対し、テナントの組織において上位の権限を有する者を特別承認者とし、この特別承認者の承認結果を採用する。すなわち、特別承認者がユーザ情報の変更を承認すれば、他の承認者の承認結果に関わらず、ユーザ情報の変更を有効とし、他の未通知の通知先へ通知する。反対に、特別承認者がユーザ情報の変更を非承認とすれば、他の承認者の承認結果に関わらず、ユーザ情報の変更を無効とする。

また、変更されるユーザ情報を使用するサービスが複数のテナントの業務に利用される場合を考える。各テナントにおけるこのサービスを利用する業務の業務重要度は同じであるとする。この場合、上記の業務重要度を用いる方法では優先する承認結果を特定できず、複数のテナントのそれぞれにテナント管理者がいるため、より上位の権限を有する者も存在しない。そこで、通知処理部１５０は、ユーザ情報が変更されるユーザ自身が属しているテナントのサービスに関する通知先である承認者の承認結果を採用する。すなわち、このユーザが属するテナントのサービスに関する承認者がユーザ情報の変更を承認すれば、通知処理部１５０は、他の承認者の承認結果に関わらず、ユーザ情報の変更を有効とし、他の未通知の通知先へ通知する。反対に、このユーザが属するテナントのサービスに関する承認者がユーザ情報の変更を非承認とすれば、通知処理部１５０は、他の承認者の承認結果に関わらず、ユーザ情報の変更を無効とする。

以上、いくつかの例を挙げて説明したが、承認者が複数ある場合に何れの承認結果を採用するかは、上記の方法に限定されることなく、業務の運用方針等に応じて具体的に定め得る。例えば、複数の承認者により異なる承認結果が得られた場合、特定の承認者の承認結果を優先するのではなく、承認者どうしの協議により承認結果を決定しても良い。また、上記の方法では、承認者が複数ある場合に、各承認者による承認結果のうちの一つを採用することとした。これに対し、複数の承認者のうちの一人（２番目の方法では特別承認者）のみに通知を行って承認結果を得るようにしても良い。

上記のように構成された管理サーバ１００は、例えば、ネットワーク上に構築されたサーバにより実現される。管理サーバ１００は、単一のサーバマシンにより実現しても良いし、複数のサーバにより機能を分散して実現しても良い。管理サーバ１００によるサービスをいわゆるクラウドサービスとして提供しても良い。いずれの場合であっても、管理サーバ１００は、演算手段であるＣＰＵ（Central Processing Unit）と、記憶手段である主記憶装置（メイン・メモリ）および外部記憶装置を備える。ＣＰＵは、外部記憶装置に格納されたプログラムを主記憶装置に読み込んで実行する。主記憶装置としては、例えばＲＡＭ（Random Access Memory）が用いられる。外部記憶装置としては、例えば磁気ディスク装置やＳＳＤ（Solid State Drive）等が用いられる。一例として、この外部記憶装置により、ユーザ情報管理ＤＢ１１０、通知方法管理ＤＢ１２０および個別通知管理ＤＢ１３０が実現される。また、ＣＰＵがプログラムを実行することにより、通知制御部１４０および通知処理部１５０の各機能が実現される。ユーザ情報管理ＤＢ１１０は、ユーザ情報管理手段の一例である。上述した通知方法管理ＤＢ１２０、個別通知管理ＤＢ１３０、通知制御部１４０および通知処理部１５０は、制御手段の一例である。

＜通知制御部および通知処理部の動作＞
図５は、通知制御部１４０および通知処理部１５０の動作を示すフローチャートである。通知制御部１４０は、ユーザ情報の変更要求を受信すると（Ｓ５０１）、ユーザ情報管理ＤＢ１１０および通知方法管理ＤＢ１２０を参照して通知先を決定する（Ｓ５０２）。通知先に承認者がない場合（Ｓ５０３でＮＯ）、通知処理部１５０は、決定された通知先へユーザ情報が変更されることを通知する（Ｓ５０８）。

一方、通知先に承認者がある場合（Ｓ５０３でＹＥＳ）、通知処理部１５０は、まず、決定された通知先のうちの承認者に対してユーザ情報が変更されることを通知する（Ｓ５０４）。承認者によりユーザ情報の変更が承認されたならば（Ｓ５０５でＹＥＳ）、通知制御部１４０は、個別通知管理ＤＢ１３０を更新して変更内容を反映させる（Ｓ５０６）。そして、承認者以外の通知先がない場合は（Ｓ５０７でＮＯ）、処理を終了する。また、承認者以外に通知先がある場合は（Ｓ５０７でＹＥＳ）、通知処理部１５０が残りの通知先へユーザ情報が変更されることを通知した後（Ｓ５０８）、処理を終了する。

承認者へユーザ情報が変更されることを通知した後、承認者の承認が得られなかった場合（Ｓ５０５でＮＯ）、通知制御部１４０による個別通知管理ＤＢ１３０の更新は行われない。また、承認者以外に通知先があっても通知は行われない。

図６は、承認者が複数ある場合における通知制御部１４０による承認結果の選択方法を示すフローチャートである。承認者が複数ある場合、承認者ごとに承認結果が得られるため、図５のＳ５０５の判断を行うために採用する一つの承認結果を選択することが必要となる。

通知制御部１４０は、まず、承認者が属すテナント（図では「対象テナント」と記載）が複数か否かを判断する。対象テナントが複数である場合（Ｓ６０１でＹＥＳ）、通知制御部１４０は、採用する承認結果として、ユーザ情報が変更されるユーザの所属先の対象テナントにおける承認者の承認結果を選択する（Ｓ６０２）。

対象テナントが一つであるか（Ｓ６０１でＮＯ）、またはＳ６０２の選択が行われた後、その対象テナントにおいて、承認者が複数である場合、（Ｓ６０３でＹＥＳ）、通知制御部１４０は、採用する承認結果として、業務重要度が最も高いサービスに関する通知先である承認者の承認結果を選択する（Ｓ６０４）。

業務重要度が最も高いサービスに関する承認者が複数である場合（Ｓ６０５でＹＥＳ）、通知制御部１４０は、特別承認者を設定して通知を行い（Ｓ６０６）、この特別承認者の承認結果を選択する（Ｓ６０７）。Ｓ６０３およびＳ６０５で承認者が複数でない場合、該当する承認者の承認結果が採用されるため、承認結果の選択は行われずに処理を終了する（Ｓ６０３でＮＯ、Ｓ６０５でＮＯ）。以上のようにして選択された一つの承認結果に基づき、図５のＳ５０５の判断が行われる。

＜適用例＞
図７は、本実施形態による通知制御の適用例を示す図である。図７（Ａ）は、重要度の異なるサービスに関する複数の承認者がいる状態を示す図であり、図７（Ｂ）は、同じ重要度のサービスに関する複数の承認者がいる状態を示す図であり、図７（Ｃ）は、サービスが複数のテナントの業務に利用され、各テナントに承認者がいる状態を示す図である。以下、図７を参照して、通知制御において採用する承認結果の選択の例を説明する。

図７（Ａ）に示す例では、ユーザＩＤ「ｆｘ９９９９９」のユーザのユーザ情報について変更要求が行われ、変更されるユーザ情報がサービス「ＴＳ」とサービス「ＥＴ」で使用されるものとする。図７（Ａ）を参照すると、何れのサービスもテナントＡの業務で利用されている。また、サービス「ＴＳ」の通知レベルは「１」であり、サービス「ＥＴ」の通知レベルは「２」である。したがって、図３に示す通知方法管理ＤＢ１２０を参照すると、どちらの通知レベルにおいても通知先が承認者である。また、サービス「ＴＳ」の業務重要度は「大」であり、サービス「ＥＴ」の業務重要度は「中」であって、サービス「ＴＳ」の業務重要度の方が高い。すなわち、図６に示した選択方法では、Ｓ６０１でＮＯ、Ｓ６０３でＹＥＳ、Ｓ６０５でＮＯである。そこで、通知制御部１４０は、ユーザ情報の変更に対する承認結果として、業務重要度が最も高いサービス「ＴＳ」（通知レベル１）の通知先であるテナントＡの管理者の承認結果を採用する。

図７（Ｂ）に示す例では、ユーザＩＤ「ｆｘ９９９９９」のユーザのユーザ情報について変更要求が行われ、変更されるユーザ情報がサービス「ＣＰ」とサービス「ＥＴ」で使用されるものとする。図７（Ｂ）を参照すると、何れのサービスもテナントＡの業務で利用されている。また、サービス「ＣＰ」およびサービス「ＥＴ」の通知レベルは、何れも「２」であり、何れの通知先も承認者である。そして、サービス「ＣＰ」およびサービス「ＥＴ」の業務重要度は、何れも「中」であり等しい。すなわち、図６に示した選択方法では、Ｓ６０１でＮＯ、Ｓ６０３でＹＥＳ、Ｓ６０５でＹＥＳである。そこで、通知処理部１５０は、両サービスの通知先である各々のサービスの管理者に対する上位の権限を有する者としてテナントＡの管理者を特別承認者に設定し、通知を行う。そして、通知制御部１４０は、ユーザ情報の変更に対する承認結果として、特別管理者であるテナントＡの管理者の承認結果を採用する。

図７（Ｃ）に示す例では、テナントＡに属するユーザＩＤ「ｆｘ９９９９９」のユーザのユーザ情報について変更要求が行われ、変更されるユーザ情報がサービス「ＴＳ」で使用されるものとする。そして、この例では、図７（Ｃ）に示すように、このユーザのユーザ情報を使用するサービス「ＴＳ」がテナントＡおよびテナントＢで利用されている。また、サービス「ＴＳ」の通知レベルは「１」である。したがって、通知先はテナント管理者であり、承認者である。すなわち、図６に示した選択方法では、Ｓ６０１でＹＥＳ、Ｓ６０３でＮＯ、Ｓ６０５でＮＯである。そこで、通知処理部１５０は、ユーザ情報の変更に対する承認結果として、ユーザＩＤ「ｆｘ９９９９９」のユーザが属するテナントＡの管理者の承認結果を採用する。

以上、本発明の実施形態について説明したが、本発明の技術的範囲は上記実施形態には限定されない。例えば、図２に示したユーザ情報管理ＤＢ１１０、図３に示した通知方法管理ＤＢ１２０、図４に示した個別通知管理ＤＢ１３０に管理される各情報の項目は例示に過ぎず、これ以外の項目を含んでいても良い。その他、本発明の技術思想の範囲から逸脱しない様々な変更や構成の代替は、本発明に含まれる。

１００…管理サーバ、１１０…ユーザ情報管理データベース（ＤＢ）、１２０…通知方法管理データベース（ＤＢ）、１３０…個別通知管理データベース（ＤＢ）、１４０…通知制御部、１５０…通知処理部、２００…外部サーバ

Claims (7)

1. ネットワーク上でサービスを提供する複数のサーバがサービスを提供する際に用いるユーザ情報を管理するユーザ情報管理手段と、
   前記ユーザ情報の変更要求を受け付けると、当該変更要求に係るユーザ情報を用いるサービスの種類および当該変更要求による当該ユーザ情報の変更内容により、少なくともサービスごとに特定される通知先および通知時期を含む、当該ユーザ情報の変更の通知方法を変化させる制御を行う制御手段と、
   を備えることを特徴とする、情報処理システム。
2. 前記制御手段は、前記ユーザ情報の変更の通知先に当該変更の承認者が含まれるか否かを判断し、当該通知先に当該承認者が含まれる場合、まず当該承認者に通知を行い、当該ユーザ情報の変更が承認された後に、当該承認者以外の通知先へ通知するように当該ユーザ情報の通知を制御することを特徴とする、請求項１に記載の情報処理システム。
3. 前記制御手段は、前記ユーザ情報の変更に対する承認者が複数ある場合、当該複数の承認者のうち、当該ユーザ情報を用いる各サービスに対して予め定められた重要度が最も高いサービスに係る承認者の承認結果を採用することを特徴とする、請求項２に記載の情報処理システム。
4. 前記制御手段は、前記ユーザ情報を用いる各サービスに対して予め定められた重要度が最も高いサービスが複数あり、当該複数のサービスに係る承認者の承認結果が異なる場合、当該複数の承認者に対して上位の権限を有する者を特別承認者とし、当該特別承認者の承認結果を採用することを特徴とする、請求項３に記載の情報処理システム。
5. 前記制御手段は、前記変更要求による前記ユーザ情報の変更内容のうち、当該変更要求の変更対象である当該ユーザ情報の項目に基づいて、前記通知方法を決定することを特徴とする、請求項１に記載の情報処理システム。
6. 前記制御手段は、前記変更要求による前記ユーザ情報の変更内容のうち、当該変更要求の変更対象である当該ユーザ情報の項目および変更対象以外の当該ユーザ情報の項目の内容に基づいて前記通知方法を決定することを特徴とする、請求項５に記載の情報処理システム。
7. コンピュータに、
   ネットワーク上でサービスを提供する複数のサーバがサービスを提供する際に用いるユーザ情報を一元管理する機能と、
   前記ユーザ情報の変更要求を受け付けると、当該変更要求に係るユーザ情報を用いるサービスの種類および当該変更要求による当該ユーザ情報の変更内容に基づいて、少なくともサービスごとに特定される通知先および通知時期を含む、当該ユーザ情報の変更の通知方法を変化させる制御を行う機能と、
   を実現させることを特徴とする、プログラム。

Images