(57)【要約】【課題】メールアドレスが間違って登録された初期ユーザーは、ログイン情報を受信できずサービスにログインすることができないが、マルチテナントアーキテクチャにおいてはテナント外からログイン情報の取得やメールアドレスの修正を実行できない。さらに初期ユーザーがサービスを利用開始したあとは初期ユーザーにログイン情報を通知する必要はなくなっているため、再通知を禁止する処理も必要である。【解決手段】初期ユーザーがシステムの利用を開始していない場合にメールアドレスの修正依頼を受け付け、一意な値を発行しメールアドレスと紐付けて一時的に記憶する。またシステムへの初回ログイン時、前記初回ログインに含まれる前記一意の値からメールアドレスを取得し、前記初期ユーザーの権限で前記初期ユーザーのメールアドレスを更新するとともに利用状況も更新する。【選択図】  図６
2015103194.tif 000002
【特許請求の範囲】
【請求項１】
テナント分離されたシステムで、テナント作成時に初期ユーザーを作成するとともに前記作成した初期ユーザーのメールアドレスを設定し管理するシステムであって、
前記作成した初期ユーザーがシステムの利用を開始したかを管理する利用状況管理手段（３０６、Ｓ６０３、Ｓ８０８）と、
前記作成した初期ユーザーがシステムの利用を開始していない場合（Ｓ６０３）に
前記作成した初期ユーザーに設定されたメールアドレスの修正依頼を受け付ける修正依頼受付手段（３０１、Ｓ６０４）と、
一意な値を発行する発行手段（３０４、Ｓ５０３）と、
前記一意な値を、前記初期ユーザーを識別するユーザー識別子および前記受付手段で受け付けた新たなメールアドレスを紐付けて一時的に記憶する記憶手段（３０５、Ｓ５０４）と、
システムへの初回ログインを受け付ける初回ログイン受付手段（３５１、Ｓ７０１）と、
を備え、
前記初回ログイン受付手段は、前記初回ログインに含まれる前記一意の値を取得する取得手段（３５１、Ｓ７０４）と、
前記記憶手段に含まれる、前記取得した一意の値に対応するメールアドレスを用いて、前記取得した一意の値に対応する前記初期ユーザーの権限で（３５１、Ｓ８０３）前記初期ユーザーのメールアドレスを更新する更新手段（３５１、Ｓ８０５）と、
前記初期ユーザーがシステムの利用を開始したとして利用状況を更新する利用状況更新手段（３５１、Ｓ８０８）と、
を備えることを特徴とするメールアドレス管理システム。
【請求項２】
前記メールアドレス管理システムは、
ユーザーに設定されたパスワードをリセットするパスワードリセット手段（３５２、Ｓ９０１）を持ち、
前記パスワードリセット手段はパスワードリセットのためにユーザー識別子およびメールアドレスを受け付けるリセット情報受付手段（３５２、Ｓ９０２）と、
パスワードリセットに先立ち前記リセット情報受付手段で受け付けた情報が妥当か確認するリセット情報確認手段（３５２、Ｓ９０３）と、
を備えるとともに、
前記リセット情報受付手段で受け付けたユーザー識別子に対応するユーザーがシステムの利用を開始している場合にパスワードリセットを許可するリセット許可手段（３５２、Ｓ９０４）と、
を備えることを特徴とする請求項１に記載のメールアドレス管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチテナント環境におけるメールアドレスを管理システムで、特に初期ユーザのメールアドレスを管理する方法に関する。
【背景技術】
【０００２】
近年クラウド型サービスを始めとした、インターネット上に設置されたサーバーにより顧客にサービスを提供するビジネスが多く存在する。このようなサービスでは、サーバーは複数の顧客企業のデータを管理することになるため、マルチテナントアーキテクチャを採用している。マルチテナントアーキテクチャを採用したサービスが、ある顧客企業にサービスを提供する場合、サービス提供側はテナントを新規に作成しその顧客企業に割り当てる。また新規作成したテナントを顧客企業側で管理するための初期ユーザーを作成し、テナントに登録する。顧客企業側の管理者は、作成された初期ユーザーとしてサービスにログインし、割り当てられたテナントにユーザーを追加するほか、必要な設定を行うことで、顧客企業がサービスの利用を開始できる。
【０００３】
顧客企業側の管理者がサービスにログインするためには初期ユーザーのログイン情報が必要になる。ログイン情報とはたとえば、ＩＤとパスワードのペアや、ユーザーの初回ログイン時のみ利用可能な初回ログインＵＲＬなどがある。これらの情報をサービス提供側が入手すると、本来顧客企業側しかアクセスできないはずのテナント内の情報に、サービス提供側からもアクセスできることになってしまう。
【０００４】
このような問題を回避するため、初期ユーザー作成時にそのユーザーのメールアドレスを登録し、登録されたメールアドレスにログイン情報を送信することがある。こうすることでサービス提供側がログイン情報を知ることなく、顧客企業側の管理者がサービスにログインできるようになる。
【０００５】
ここでユーザーに登録されたメールアドレスが間違っていた場合を考える。このような場合、ユーザーはサービスが送信するメールを受信できない。そこで従来、ユーザーに登録されたメールアドレスが誤っていた場合、ユーザーがログインした際にメールアドレスが間違っている旨を通知することで正しいメールアドレスへの変更を促す方式（特許文献１）があった。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開2002-351785号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら従来の方法には以下の問題があった。すなわち、初期ユーザーのログイン情報を通知するメールアドレスが間違って登録されていた場合、顧客企業側の管理者はサービスにログインすることができずメールアドレスを修正できない。またマルチテナントアーキテクチャにおいては、サービス提供側であったとしても、顧客企業側のテナント内の情報を修正できず、ログイン情報を知ることもない。そのため顧客企業用に作成したテナントおよび初期ユーザーを利用できなくなってしまう。
【０００８】
なお初期ユーザーがサービスを利用開始したあとは初期ユーザーにログイン情報を通知する必要はなくなっているため、再通知を禁止する処理も必要である。利用開始されたテナントには顧客企業の情報が多数保存されているが、ログイン情報の再通知を禁止していないと顧客企業に属さないユーザーにログイン情報を通知できてしまい、情報漏えいの可能性もある。
【０００９】
本発明は前述の課題をかんがみてなされたものである。
【課題を解決するための手段】
【００１０】
テナント分離されたシステムで、テナント作成時に初期ユーザーを作成するとともに前記作成した初期ユーザーのメールアドレスを設定し管理するシステムであって、
前記作成した初期ユーザーがシステムの利用を開始したかを管理する利用状況管理手段（３０６、Ｓ６０３、Ｓ８０８）と、
前記作成した初期ユーザーがシステムの利用を開始していない場合（Ｓ６０３）に
前記作成した初期ユーザーに設定されたメールアドレスの修正依頼を受け付ける修正依頼受付手段（３０１、Ｓ６０４）と、
一意な値を発行する発行手段（３０４、Ｓ５０３）と、
前記一意な値を、前記初期ユーザーを識別するユーザー識別子および前記受付手段で受け付けた新たなメールアドレスを紐付けて一時的に記憶する記憶手段（３０５、Ｓ５０４）と、
システムへの初回ログインを受け付ける初回ログイン受付手段（３５１、Ｓ７０１）と、
を備え、
前記初回ログイン受付手段は、前記初回ログインに含まれる前記一意の値を取得する取得手段（３５１、Ｓ７０４）と、
前記記憶手段に含まれる、前記取得した一意の値に対応するメールアドレスを用いて、前記取得した一意の値に対応する前記初期ユーザーの権限で（３５１、Ｓ８０３）前記初期ユーザーのメールアドレスを更新する更新手段（３５１、Ｓ８０５）と、
前記初期ユーザーがシステムの利用を開始したとして利用状況を更新する利用状況更新手段（３５１、Ｓ８０８）と、
を備えることを特徴とするメールアドレス管理システム。
【発明の効果】
【００１１】
本発明によれば、作成時にメールアドレスを間違えて登録してしまった初期ユーザーに対してログイン情報を再通知することができ、初期ユーザーがサービスにログインできるようになる。また通知に際してはメールアドレスを修正することができ、正しいメールアドレスをユーザー情報として設定できる。
【００１２】
さらにユーザーが利用開始するとサービス提供側から再通知ができないようになるため、利用開始されたテナントに意図しない第三者がログインすることを防げる。
【図面の簡単な説明】
【００１３】
【図１】ネットワーク構成を示す図である。
【図２】本発明の実施の形態に係るＰＣの構成図である。
【図３】本実施の形態に係るモジュール構成図である。
【図４】本実施の形態に係るテナント作成のフローである。
【図５】本実施の形態に係るログイン情報を通知するフローである。
【図６】本実施の形態に係る初期ユーザーがサービスに初めてログインするフローである。
【図７】本実施の形態に係るサービス提供側ユーザー向けの画面の例である。
【図８】本実施の形態に係る初期ユーザー向けの画面の例である。
【図９】本実施の形態に係るデータ例である。
【図１０】本実施の第２の形態に係るモジュール構成図である。
【図１１】本実施の第２の形態に係るパスワードリセットのフローである。
【図１２】本実施の第２の形態に係るパスワードリセットの画面の例である。
【発明を実施するための形態】
【００１４】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【００１５】
本実施の形態に係るメールアドレス管理システムは、図１に示すような構成のネットワーク上に実現される。
【００１６】
１００は、Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＷＡＮ１００）であり、本発明ではＷｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ（ＷＷＷ）システムが構築されている。１０１は各構成要素を接続するＬｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＬＡＮ１０１）である。
【００１７】
２００はユーザーが操作するクライアントＰＣであり、３００はテナントおよびテナントに属するユーザーを管理するテナント管理サーバー、３５０はユーザーを認証する認証サーバーである。
【００１８】
またクライアントＰＣ２００、テナント管理サーバー３００、認証サーバー３５０はそれぞれＷＡＮネットワーク１００およびＬＡＮ１０１を介して接続されている。なおクライアントＰＣ２００およびそれぞれのサーバー、それぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また同一のＰＣまたはサーバーコンピューター上に構成されていてもよい。例えばテナント管理サーバー３００が構成されるサーバーコンピューター上に、認証サーバー３５０が構成されていてもよい。
【００１９】
テナント管理サーバー３００、認証サーバー３５０はそれぞれ、後述のサーバーコンピューター上で動作する。
【００２０】
図２は本実施の形態に係るクライアントＰＣ２００の構成を示す図である。またテナント管理サーバー３００、認証サーバー３５０のサーバーコンピューターの構成も同様である。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態のクライアントＰＣ２００およびサーバーコンピューターには一般的な情報処理装置のハードウェア構成を適用できる。
【００２１】
図２において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、或いはハードディスク２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各フローチャートの処理はこのプログラムの実行により実現できる。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。
【００２２】
キーボードコントローラ（ＫＢＣ）２０５は、キーボード（ＫＢ）２０９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は各種データを記憶するハードディスク（ＨＤ）２１１やフロッピー（登録商標）ディスク（ＦＤ）等におけるデータアクセスを制御する。ＮＣ２１２はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。
【００２３】
尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体はハードディスク（ＨＤ）２１１にインストールされたアプリケーションプログラムである。
【００２４】
図３は本実施の形態に係る、テナント管理サーバー３００、認証サーバー３５０それぞれのモジュール構成を示す図である。図３の（ａ）はテナント管理サーバー３００を、図３の（ｂ）は認証サーバー３５０のモジュール構成を、それぞれ示す。テナント管理サーバー３００はテナント管理モジュール３０１、メールアドレス記憶モジュール３０２、メール通知モジュール３０３を持つ。またＵＲＬ生成モジュール３０４、ＵＲＬ記憶モジュール３０５、利用状況管理モジュール３０６を持つ。認証サーバー３５０は初回ログイン処理モジュール３５１を持つ。
【００２５】
図４の（ａ）は本実施の形態に係る、テナント管理サーバー３００がサービス提供側ユーザーの操作に応じてテナント作成を行う処理のフローである。本フローはユーザーがテナント管理サーバー３００を操作することで開始される。
【００２６】
ステップＳ４０１でテナント管理モジュール３０１は、作成するテナントの初期ユーザー情報を受け付ける。またテナント作成が完了したと同時にユーザーに通知メールを送信するか否かの指定も受け付ける。ここで初期ユーザーの情報にはユーザーＩＤとメールアドレスを含む。なおメールアドレスは省略してもよい。ステップＳ４０１で表示する画面は、たとえば図７の（ａ）の１００１で示すようなテナント作成画面である。
【００２７】
ステップＳ４０２でテナント管理モジュール３０１は、指定された情報でユーザーを作成する。
【００２８】
ステップＳ４０３でテナント管理モジュール３０１はテナントを作成する。またステップＳ４０２で作成したユーザーを初期ユーザーとして、作成したテナントに登録する。
【００２９】
ステップＳ４０４でメールアドレス記憶モジュール３０２は、ステップＳ４０１で指定されたメールアドレスを、同じく指定されたユーザーＩＤに紐付けて一時的に記憶する。これはステップＳ４０２で作成されたユーザーのユーザー情報とは異なる領域で記憶する。なおステップＳ４０１でメールアドレスの指定が省略されていた場合は、省略されていた旨を記憶する。ステップＳ４０４で記憶する情報は、たとえば図９の（ａ）の１５００で示すような、メールアドレス一時記憶テーブルで記憶する。
【００３０】
ステップＳ４０５でテナント管理モジュール３０１は、ステップＳ４０１で初期ユーザーのメールアドレスが指定されていたかを判断する。判断の結果、メールアドレスが指定されていた場合はステップＳ４０６に遷移する。またメールアドレスが省略されていた場合はフローを終了する。
【００３１】
ステップＳ４０６でテナント管理モジュール３０１は、ステップＳ４０１で通知メールを送信する指定をされていたか判断する。判断の結果、通知が指定されていた場合はステップＳ４０７に遷移する。また通知が指定されていなかった場合はフローを終了する。
【００３２】
ステップＳ４０７でメール通知モジュール３０３は、ステップＳ４０４で一時的に記憶したメールアドレスに対し、初期ユーザーのログイン情報を通知する。通知が完了するとフローを終了する。
【００３３】
図４の（ｂ）は本実施の形態に係る、サービス提供側ユーザーの操作に応じて初期ユーザーにログイン情報を通知する処理の例である。このフローは図４の（ａ）のステップＳ４０７の詳細なフローである。また図５のステップＳ６０８の詳細なフローも同様である。
【００３４】
ステップＳ５０１でメール通知モジュール３０３は、ログイン情報の通知先となる初期ユーザーのユーザーＩＤを取得する。
【００３５】
ステップＳ５０２でメール通知モジュール３０３は、メールアドレス記憶モジュール３０２から、ステップＳ５０１で取得したユーザーＩＤに紐付けて一時的に記憶されたメールアドレスを取り出す。
【００３６】
ステップＳ５０３でＵＲＬ生成モジュール３０４は、ログイン情報の通知先となる初期ユーザー用に、初回ログインＵＲＬを生成する。
【００３７】
ステップＳ５０４でＵＲＬ記憶モジュール３０５は、ステップＳ５０３で生成したＵＲＬを、ステップＳ５０２で取り出したユーザーＩＤとメールアドレスのペアに紐付けて記憶する。またその際はＵＲＬの有効期限も設定する。ステップＳ４０４で記憶する情報は、たとえば図９の（ｂ）の１５５０で示すような、初回ログインＵＲＬ一時記憶テーブルで記憶する。
【００３８】
ステップＳ５０５でメールアドレス記憶モジュール３０２は、ステップＳ５０２で取り出したメールアドレスに、ステップＳ５０１で取得したユーザーＩＤとステップＳ５０３で生成した初回ログインＵＲＬを送信してフローを終了する。
【００３９】
図５は本実施の形態に係る、サービス提供側ユーザーの操作に応じて、作成済みテナントの初期ユーザーに対してログイン情報を通知する処理の例である。このフローはたとえば初期ユーザーに登録されたメールアドレスにログイン情報を通知しようとしたがメールアドレスが間違っていた場合に、正しいメールアドレスにログイン情報を通知する場合に実施される。その他、図４の（ａ）のフローでユーザーに通知を行わなかった場合（ステップＳ４０５やステップＳ４０６でＮｏとなった場合）にも実施される。
【００４０】
ステップＳ６０１でテナント管理モジュール３０１は、ログイン情報を通知するテナントの指定を受け付ける。ここで表示する画面は、たとえば図７の（ｂ）の１１０１で示すようなテナント指定画面である。
【００４１】
ステップＳ６０２でテナント管理モジュール３０１は、ステップＳ６０１で指定されたテナントの初期ユーザーを取得する。
【００４２】
ステップＳ６０３で利用状況管理モジュール３０６は、ステップＳ６０３で取得した初期ユーザーが、サービスの利用を開始しているか判断する。ここで利用を開始していないと判断された場合はステップＳ６０４に遷移する。また利用を開始していると判断された場合はステップＳ６５０に遷移する。
【００４３】
ステップＳ６０４でテナント管理モジュール３０１は、通知先となるメールアドレスの指定を受け付ける。ここで表示する画面は、たとえば図７の（ｃ）の１１０２で示すようなメールアドレス指定画面である。なおメールアドレス指定画面１１０２を画面表示させる際に、ステップＳ６０２で取得した初期ユーザーに紐付けられたメールアドレスを表示してもよい。
【００４４】
ステップＳ６０５でメールアドレス記憶モジュール３０２は、ステップＳ６０２で取得した初期ユーザーに紐付いたメールアドレスを記憶しているか判断する。ここでメールアドレスを紐付けて記憶していると判断された場合はステップＳ６０６に遷移する。またメールアドレスを紐付けて記憶していないと判断された場合はステップＳ６０７に遷移する。
【００４５】
ステップＳ６０６でメールアドレス記憶モジュール３０２は、ステップＳ６０２で取得した初期ユーザーに紐付けて一時的に記憶しているメールアドレスを記憶から削除する。
【００４６】
ステップＳ６０７でメールアドレス記憶モジュール３０２は、ステップＳ６０４で指定されたメールアドレスを、ステップＳ６０２で取得したユーザーＩＤに紐付けて一時的に記憶する。
【００４７】
ステップＳ６０８でメール通知モジュール３０３は、ステップＳ６０７で一時的に記憶したメールアドレスに対し、初期ユーザーのログイン情報を通知する。通知が完了するとフローを終了する。
【００４８】
ステップＳ６５０でテナント管理モジュール３０１は、対象としたユーザーが利用開始済みのため通知操作を行えない旨を表示し、フローを終了する。
【００４９】
図６の（ａ）は本実施の形態に係る、通知を受けた初期ユーザーがサービスに初めてログインする際の初回ログインフローの処理の例である。
【００５０】
ステップＳ７０１で初回ログイン処理モジュール３５１は、初期ユーザーによる初回ログインＵＲＬへのアクセスを受け付ける。
【００５１】
ステップＳ７０２で初回ログイン処理モジュール３５１は、ＵＲＬ記憶モジュール３０５に問い合わせ、アクセスされたＵＲＬが有効なものか判断する。有効なＵＲＬだと判断された場合はステップＳ７０３に遷移する。また無効なＵＲＬと判断された場合はステップＳ７５０に遷移する。ここでＵＲＬの有効性は、ＵＲＬ記憶モジュール３０５の記憶に含まれるか否かと、その有効期限内であるかを確認することで判断される。
【００５２】
ステップＳ７０３で初回ログイン処理モジュール３５１は、図８の（ａ）に示すような初回ログイン画面１２０１を表示し、ユーザーＩＤの入力を受け付ける。
【００５３】
ステップＳ７０４で初回ログイン処理モジュール３５１は、ＵＲＬ記憶モジュール３０５に問い合わせ、アクセスされた初回ログインＵＲＬに対応するユーザーＩＤを取り出す。
【００５４】
ステップＳ７０５で初回ログイン処理モジュール３５１は、ステップＳ７０３で受け付けたユーザーＩＤと、ステップＳ７０４で取得したユーザーＩＤを比較する。比較の結果、両者が一致した場合はステップＳ７０６に遷移する。また両者が不一致だった場合はステップＳ７５０に遷移する。
【００５５】
ステップＳ７０６で初回ログイン処理モジュール３５１は、ステップＳ７０５で一致したユーザーＩＤの状態を利用開始状態にしてフローを終了する。
【００５６】
ステップＳ７５０で初回ログイン処理モジュール３５１は、不正なアクセスである旨をユーザーに通知し、フローを終了する。
【００５７】
図６の（ｂ）は本実施の形態に係る、通知を受けた初期ユーザーの操作に応じて、ユーザーＩＤを利用開始状態にする処理の例である。このフローは図６の（ａ）のステップＳ７０６の詳細なフローである。
【００５８】
ステップＳ８０１で初回ログイン処理モジュール３５１は、図８の（ｂ）に示すようなパスワード設定画面１２０２を表示し、新しいパスワードの入力を受け付ける。
【００５９】
ステップＳ８０２で初回ログイン処理モジュール３５１は、ステップＳ８０１で受け付けたパスワードを、処理対象とするユーザーＩＤのパスワードとして登録する。
【００６０】
ステップＳ８０３で初回ログイン処理モジュール３５１は、ステップ８０１で受け付けたパスワードを用いて、対象となるユーザーＩＤのユーザーとしてサービスにログインする。
【００６１】
ステップＳ８０４で初回ログイン処理モジュール３５１は、ＵＲＬ記憶モジュール３０５およびメールアドレス記憶モジュール３０２に問い合わせ、アクセスされた初回ログインＵＲＬに対応するメールアドレスを取得する。
【００６２】
ステップＳ８０５で初回ログイン処理モジュール３５１は、ステップＳ８０３でログインしたユーザーの権限を用いて、対象となるユーザーのメールアドレスをステップＳ８０４で取得したメールアドレスに書き換える。
【００６３】
ステップＳ８０６で初回ログイン処理モジュール３５１は、ＵＲＬ記憶モジュール３０５から、対象となるユーザーのユーザーＩＤに紐付けられた初回ログインＵＲＬの一時的な記憶を削除する。
【００６４】
ステップＳ８０７で初回ログイン処理モジュール３５１は、メールアドレス記憶モジュール３０２から、対象となるユーザーのユーザーＩＤに紐付けられたメールアドレスの一時的な記憶を削除する。
【００６５】
ステップＳ８０８で初回ログイン処理モジュール３５１は、利用状況管理モジュール３０６に依頼し、対象となるユーザーＩＤを利用開始状態に変更してフローを終了する。
【００６６】
図７は本実施の形態に係る、サービス提供側ユーザーの操作に応じて表示される画面の例である。
【００６７】
図７の（ａ）は作成するテナントの初期ユーザー情報を受け付けるテナント作成画面１００１である。サービス提供側ユーザーは本画面を操作し、作成するテナントの初期ユーザー情報としてユーザーＩＤとメールアドレスを指定する。またテナント作成が完了したと同時にユーザーに通知メールを送信するか否かの指定も行う。
【００６８】
図７の（ｂ）はログイン情報を通知するテナントを指定する、テナント指定画面１１０１である。サービス提供側ユーザーは本画面でテナントＩＤを入力することで、ログイン情報を通知するテナントを指定する。
【００６９】
図７の（ｃ）は通知先となるメールアドレスの指定を指定する、メールアドレス指定画面１１０２である。サービス提供側ユーザーは本画面でメールアドレスを入力することで、入力したメールアドレスに対し、対象となるテナントの初期ユーザーのログイン情報を送信できる。
【００７０】
図８は本実施の形態に係る、通知を受けた初期ユーザーの操作に応じて表示される画面の例である。
【００７１】
図８の（ａ）はユーザーＩＤの入力を受け付ける初回ログイン画面１２０１である。本画面では、ユーザーがアクセスした初回ログインＵＲＬが意図したユーザーであるかを確認するために、ユーザーＩＤの入力を求める。
【００７２】
図８の（ｂ）は新しいパスワードを設定するパスワード設定画面１２０２である。初回ログイン画面１２０１でユーザーが入力したユーザーＩＤが正しければ本画面が表示され、ユーザーは自分自身でパスワードを設定することができる。またここで設定したパスワードを用いて、ユーザーはサービスにログインすることができるようになる。
【００７３】
図９は本実施の形態に係るデータの例である。
【００７４】
図９の（ａ）はメールアドレス一時記憶テーブル１５００である。本テーブルはユーザーＩＤと、そのユーザーＩＤのログイン情報を通知する通知先メールアドレスを一時的に記憶する。サービス提供側ユーザーが初期ユーザーにログイン情報を通知する操作を行うと、本テーブルにユーザーＩＤとメールアドレスが登録される。また初期ユーザーが初回ログインＵＲＬにアクセスした際には本テーブルに登録されたメールアドレスが参照され、そのユーザーに登録されたメールアドレスが更新される。
【００７５】
図９の（ｂ）は初回ログインＵＲＬ一時記憶テーブル１５５０である。本テーブルはメールアドレス一時記憶テーブル１５００に記憶されたユーザーＩＤとメールアドレスのペアに紐付けて、初回ログインＵＲＬおよびＵＲＬの有効期限を一時的に記憶する。サービス提供側ユーザーが初期ユーザーにログイン情報を通知する操作を行うと、本テーブルに初回ログインＵＲＬが登録される。また初期ユーザーが初回ログインＵＲＬにアクセスした際には本テーブルが参照され、ＵＲＬの有効性が確認される。
【００７６】
本実施の形態によれば、作成時にメールアドレスを間違えて登録してしまった初期ユーザーに対してログイン情報を再通知することができ、初期ユーザーがサービスにログインできるようになる。また通知に際してはメールアドレスを修正することができ、正しいメールアドレスをユーザー情報として設定できる。
【００７７】
さらにユーザーが利用開始するとサービス提供側から再通知ができないようになるため、利用開始されたテナントに意図しない第三者がログインすることを防げる。
【００７８】
次に、本発明を実施するための第２の形態について図面を用いて説明する。なお第１の実施の形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。
【００７９】
ログイン情報を受け取ったユーザーは、メールの文面からユーザーＩＤを、メールの宛先からメールアドレスをそれぞれ入手できる。ここでユーザーがユーザーＩＤとメールアドレスを用いてパスワードリセットできてしまうと、そのユーザーは初回ログインＵＲＬにアクセスせずにサービスを利用できてしまう。そのためサービス提供側ユーザーによるログイン情報の再通知が禁止されないままの状態となってしまう。そこで以下では、利用開始されていないユーザーはパスワードリセットできなくする方式について説明する。
【００８０】
図１０は本実施の第２の形態に係る、認証サーバー３５０のモジュール構成図である。認証サーバー３５０は初回ログイン処理モジュール３５１、パスワードリセットモジュール３５２を持つ。パスワードリセットモジュール３５２はユーザーＩＤとメールアドレスを受け付け、それらの対応が正しい場合にはユーザーＩＤのパスワードをリセットするもので、ユーザーがパスワードを忘れた場合などに利用される。
【００８１】
図１１は本実施の第２の形態に係る、パスワードリセットフローである。本フローはユーザーが、パスワードを忘れた場合のために提供された操作を行うことで開始される。
【００８２】
ステップＳ９０１でパスワードリセットモジュール３５２は、パスワードリセット画面へのアクセスを受け付ける。ここで表示されるのは、図１２で示すようなパスワードリセット画面２００１である。
【００８３】
ステップＳ９０２でパスワードリセットモジュール３５２は、パスワードをリセットしたいユーザーのユーザーＩＤと、そのユーザーに登録されたメールアドレスの入力を受け付ける。
【００８４】
ステップＳ９０３でパスワードリセットモジュール３５２は、ステップＳ９０２で入力されたユーザーＩＤとメールアドレスの対応を確認する。確認の結果、入力されたメールアドレスがそのユーザーＩＤのものであると判断されればステップＳ９０４に遷移する。また入力されたメールアドレスがそのユーザーＩＤのものでないと判断されればステップＳ９５０に遷移する。
【００８５】
ステップＳ９０４でパスワードリセットモジュール３５２は、利用状況管理モジュール３０６に問い合わせて、ステップＳ９０２で入力されたユーザーＩＤが利用開始済みか確認する。ユーザーＩＤが利用開始済みでなければステップＳ９０５に遷移する。またユーザーＩＤが利用開始済みであればステップＳ９５０に遷移する。
【００８６】
ステップＳ９０５でパスワードリセットモジュール３５２は、ステップＳ９０２で入力されたユーザーＩＤのパスワードをリセットするための情報を、同じくステップＳ９０２で入力されたメールアドレスに送信し、フローを終了する。
【００８７】
ステップＳ９５０でパスワードリセットモジュール３５２は、不正な操作である旨をユーザーに通知し、フローを終了する。
【００８８】
図１２は本実施の第２の形態に係る、ユーザーがパスワードリセット操作した際に表示される画面の例である。パスワードリセット画面２００１はパスワードをリセットしたいユーザーのユーザーＩＤと、そのユーザーに登録されたメールアドレスの入力を求める。また入力されたユーザーＩＤとメールアドレスの対応が正しければパスワードリセット処理を行う。
【００８９】
本実施の第２の形態によれば、利用開始していないユーザーはパスワードリセットできなくなり、サービス提供側ユーザーによるログイン情報の再通知が禁止されないままサービスが利用されることを防げる。
【符号の説明】
【００９０】
１００  ＷＡＮ
１０１  ＬＡＮ
２００  クライアントＰＣ
３００  テナント管理サーバー
３０２  メールアドレス記憶モジュール
３０５  ＵＲＬ記憶モジュール
３０６  利用状況管理モジュール
３５０  認証サーバー
３５１  初回ログイン処理モジュール３５１
【図１】
2015103194.tif 000003
【図２】
2015103194.tif 000004
【図３】
2015103194.tif 000005
【図４】
2015103194.tif 000006
【図５】
2015103194.tif 000007
【図６】
2015103194.tif 000008
【図７】
2015103194.tif 000009
【図８】
2015103194.tif 000010
【図９】
2015103194.tif 000011
【図１０】
2015103194.tif 000012
【図１１】
2015103194.tif 000013
【図１２】
2015103194.tif 000014