JP4475961B2 - 併合情報提供装置、情報提供装置、管理装置、併合情報提供方法、情報提供方法、管理方法、併合情報提供プログラム、情報提供プログラム、管理プログラム及び記録媒体 - Google Patents

Description

本発明は、併合情報提供装置、情報提供装置、管理装置、併合情報提供方法、情報提供方法、管理方法、併合情報提供プログラム、情報提供プログラム、管理プログラム及び記録媒体に関する。

認証プロバイダを利用してユーザの認証を行い、アプリケーションが提供するサービスを利用する従来例を、図１を用いて説明する。図１は、認証プロバイダを利用してユーザの認証を行い、アプリケーションが提供するサービスを利用する一例を説明するための図である。

図１のシステムは、Ｗｅｂブラウザ１と、Ｗｅｂポータル２と、アプリケーション３と、認証ディレクトリプロバイダ４とから構成される。

Ｗｅｂブラウザ１は、Ｗｅｂページを閲覧するソフトウェアである。

Ｗｅｂポータル２は、インターネットの入口となるＷｅｂサイトで、Ｗｅｂブラウザ１から利用できる様々なＷｅｂサービスを提供するＷｅｂサイトである。

アプリケーション３は、Ｗｅｂポータル２がＷｅｂブラウザ１に提供するサービスの１つである。

認証ディレクトリプロバイダ４は、登録されているユーザの認証及び該ユーザの所属するグループの情報などを提供するプロバイダである。

ステップＳ１では、Ｗｅｂブラウザ１が、ユーザによって入力されたログイン名とパスワードとをＷｅｂポータル２に送信する。

ステップＳ１に続いてステップＳ２に進み、Ｗｅｂポータル２は、ステップＳ１において受信したログイン名とパスワードとを含む後述する認証チケットの作成リクエストを認証ディレクトリプロバイダ４に送信する。

認証ディレクトリプロバイダ４では、受信した認証チケットの作成リクエストに含まれるログイン名とパスワードとに基づいて、登録されているユーザの正しいログイン名とパスワードとの組み合わせかどうかを判定し、登録されているユーザの正しい組み合わせであると判定した場合は、このことを認証する認証チケットを作成する。

ステップＳ２に続いてステップＳ３に進み、認証ディレクトリプロバイダ４は、前記作成した認証チケットのＩＤを含む認証チケットの作成レスポンスをＷｅｂポータル２に送信する。

ステップＳ３に続いてステップＳ４に進み、Ｗｅｂポータル２は、認証が成功した旨の情報をＷｅｂブラウザ１に送信する。

ステップＳ４に続いてステップＳ５に進み、Ｗｅｂブラウザ１は、アプリケーション３が提供するサービスの利用を開始する旨をＷｅｂポータル２に通知する。

ステップＳ５に続いてステップＳ６に進み、Ｗｅｂポータル２は、ステップＳ３において取得した認証チケットのＩＤを含むサービスの利用を許可するセッションチケットの作成リクエストをアプリケーション３に送信する。

ステップＳ６に続いてステップＳ７に進み、アプリケーション３は、当該アプリケーションの利用を許可しても良い、有効なユーザからのセッションチケットの作成リクエストかどうかを確認するために、前記認証チケットのＩＤを含むＩＤ確認リクエストをディレクトリプロバイダ４に送信する。

ステップＳ７に続いてステップＳ８に進み、認証ディレクトリプロバイダ４は、渡された認証チケットのＩＤが有効な認証チケットのＩＤかどうかを判定し、有効な認証チケットのＩＤであると判定した場合、該認証チケットのＩＤを作成したユーザの情報を含むＩＤ確認レスポンスを、アプリケーション３に送信する。

ステップＳ８に続いてステップＳ９に進み、アプリケーション３は、ステップＳ８において取得したユーザの情報から、ステップＳ６において取得したセッションチケットの作成リクエストは、当該アプリケーションの利用を許可しても良い、有効なユーザからのリクエストであると判定すると、セッションチケットを作成し、該セッションチケットのＩＤを含む、セッションチケットの作成レスポンスをＷｅｂポータル２に送信する。

ステップＳ９に続いてステップＳ１０に進み、Ｗｅｂポータル２は、Ｗｅｂブラウザ１に対してサービスの利用が許可された旨を通知する。

ステップＳ１０に続いてステップＳ１１に進み、Ｗｅｂブラウザ１は、アプリケーション３が提供するサービスを利用する旨をＷｅｂポータル２に通知する。

ステップＳ１１に続いてステップＳ１２に進み、Ｗｅｂポータル２は、ステップＳ９において取得したセッションチケットのＩＤを含むサービスの利用リクエストをアプリケーション３に送信する。

ステップＳ１２に続いてステップＳ１３に進み、アプリケーション３は、サービスの利用リクエストに含まれるセッションチケットのＩＤの有効性を判定し、有効なセッションチケットのＩＤであると判定すると、指定されたサービスをＷｅｂポータル２に送信する。

ステップＳ１３に続いてステップＳ１４に進み、Ｗｅｂポータル２は、ステップＳ１３において受信したサービスをＷｅｂブラウザ１に提供する。

図１を用いて説明したように、認証ディレクトリプロバイダ４は、Ｗｅｂポータル２より受信した認証チケットの作成リクエストに含まれるユーザ名とパスワードとを基に、登録されているユーザを認証する認証チケットを作成し、該認証チケットのＩＤを含む認証チケットの作成レスポンスをＷｅｂポータル２に送信する。また、認証ディレクトリプロバイダ４は、アプリケーション３より受信した認証チケットのＩＤの確認リクエストに含まれる前記認証チケットのＩＤを基に、ユーザの情報を含む認証チケットのＩＤの確認レスポンスをアプリケーション３に送信する。

しかしながら、一般的にＷｅｂポータル２は複数のＷｅｂサービスを提供するため、複数のアプリケーション及び該アプリケーションのユーザを認証する複数の認証プロバイダをサポートする。

図２は、１つのＷｅｂポータルが、複数のアプリケーションと複数の認証ディレクトリプロバイダとをサポートする一例を説明するための図である。

図２のシステムは、Ｗｅｂブラウザ１と、Ｗｅｂポータル２と、Windows（登録商標）アプリケーション５と、Ｎｏｔｅｓ（登録商標）アプリケーション６と、Windows（登録商標）認証ディレクトリプロバイダ７と、Ｎｏｔｅｓ（登録商標）認証ディレクトリプロバイダ８とから構成される。

図２は、図１に比べてＷｅｂポータル２が提供するアプリケーション及び該アプリケーションのユーザの認証を行う認証プロバイダがそれぞれ複数存在する。

図２に示すような構成を取ることによって、ユーザが、Windows（登録商標）認証ディレクトリプロバイダ７に登録されているユーザ名とパスワードとをＷｅｂブラウザ１に入力すれば、Windows（登録商標）認証ディレクトリプロバイダ７においてWindows（登録商標）のユーザとして認証され、Windows（登録商標）アプリケーション５を利用することができる。

また、ユーザが、Ｎｏｔｅｓ（登録商標）認証ディレクトリプロバイダ８に登録されているユーザのユーザ名とパスワードとをＷｅｂブラウザ１に入力すれば、Ｎｏｔｅｓ（登録商標）認証ディレクトリプロバイダ８においてＮｏｔｅｓ（登録商標）のユーザとして認証され、Ｎｏｔｅｓ（登録商標）アプリケーション６を利用することができる。

しかしながら、図２に示す構成の場合、Ｗｅｂポータル２に、Windows（登録商標）認証ディレクトリプロバイダ７にアクセスするアクセスモジュール１０_１と、Ｎｏｔｅｓ（登録商標）認証ディレクトリプロバイダ８にアクセスするアクセスモジュール１０_２とをそれぞれ別々に開発する必要があり、効率的ではない問題があった。

この問題を解決するためには、図３に示すような構成が考えられる。図３は、Ｗｅｂポータルにおけるアクセスモジュールを１つに統合した一例を説明するための図である。

図３のシステムは、Ｗｅｂブラウザ１と、Ｗｅｂポータル２と、Windows（登録商標）アプリケーション５と、Ｎｏｔｅｓ（登録商標）アプリケーション６と、Windows（登録商標）認証ディレクトリプロバイダ７と、Ｎｏｔｅｓ（登録商標）認証ディレクトリプロバイダ８と、プロバイダ９とから構成される。

図３は、図２に比べてＷｅｂポータル２におけるアクセスモジュール１０を１つに統合するために、プロバイダ９が新たに設けられている。

プロバイダ９は、Ｗｅｂブラウザ１及びＷｅｂポータル２を介して取得したユーザ名とパスワードとをWindows（登録商標）認証ディレクトリプロバイダ７及びＮｏｔｅｓ（登録商標）認証ディレクトリプロバイダ８それぞれに送信して、それぞれに認証チケット作成のリクエストを行う。

プロバイダ９は、どちらか一方のプロバイダから認証チケットのＩＤを含む認証チケットの作成レスポンスを受信した場合は、前記認証チケットのＩＤをＷｅｂポータル２に送信する。

図３に示すような構成を取ることによって、Ｗｅｂポータル２のアクセスモジュール１０を１つにすることができる。

しかしながら、図３に示すような構成において、新たなアプリケーションをＷｅｂポータル２に追加した場合、新たに追加したアプリケーションにおいて、例えばWindows（登録商標）認証ディレクトリプロバイダ７に登録されているWindows（登録商標）ユーザとＮｏｔｅｓ（登録商標）認証ディレクトリプロバイダ８に登録されているＮｏｔｅｓ（登録商標）ユーザとを区別しなくてはならない問題がある。

図３の構成に新たなアプリケーションを追加した一例を、図４を用いて説明する。

図４は、図３の構成に新たなアプリケーションを追加した一例を説明するための図である。

図４のシステムは、Ｗｅｂブラウザ１と、Ｗｅｂポータル２と、Windows（登録商標）認証ディレクトリプロバイダ７と、Ｎｏｔｅｓ（登録商標）認証ディレクトリプロバイダ８と、プロバイダ９と、アプリケーション１１とから構成される。

図４は、図３と比べてWindows（登録商標）アプリケーション５及びＮｏｔｅｓ（登録商標）アプリケーション６に変わってアプリケーション１１がＷｅｂポータル２に新たに追加された構成となっている。

このような構成において、例えばアプリケーション１１が、Windows（登録商標）認証ディレクトリプロバイダ７で認証されたWindows（登録商標）ユーザも、Ｎｏｔｅｓ（登録商標）認証ディレクトリプロバイダ８で認証されたＮｏｔｅｓ（登録商標）ユーザも両方利用可能であるとした場合、アプリケーション１１では、それぞれのユーザを識別するユーザＩＤを登録して、２つのユーザを管理しなくてはならなく、管理が煩雑になる問題があった。

例えば、Windows（登録商標）のユーザと、Ｎｏｔｅｓ（登録商標）のユーザとが同一人物で、該ユーザがWindows（登録商標）でもＮｏｔｅｓ（登録商標）でも同一のユーザＩＤを使用していたとしても、アプリケーション１１では、Windows（登録商標）のユーザとしてのユーザＩＤ、Ｎｏｔｅｓ（登録商標）のユーザとしてのユーザＩＤと、別々に管理しなくてはならない問題があった。

一方、Windows（登録商標）認証ディレクトリプロバイダ７と、Ｎｏｔｅｓ（登録商標）認証ディレクトリプロバイダ８以外に、Ｌｏｃａｌ認証ディレクトリプロバイダ１２を新たに導入する構成も考えられる。

図５は、Ｌｏｃａｌ認証ディレクトリプロバイダを導入した一例を説明するための図である。

図５のシステムは、Ｗｅｂブラウザ１と、Ｗｅｂポータル２と、Windows（登録商標）認証ディレクトリプロバイダ７と、Ｎｏｔｅｓ（登録商標）認証ディレクトリプロバイダ８と、プロバイダ９と、アプリケーション１１と、Ｌｏｃａｌ認証ディレクトリプロバイダ１２とから構成される。

図５は、図４と比べてＬｏｃａｌ認証ディレクトリプロバイダ１２が新たに導入されている。

図５に示すように、Windows（登録商標）認証ディレクトリプロバイダ７には、ユーザｋａｎａ、ｋｕｒｏｓｅ、ｍａｅｄａ、ａｉｔｏｈ、ｉｋｅｇａｍｉ、ｒｄｈｇｕｅｓｔが登録されており、Ｎｏｔｅｓ（登録商標）認証ディレクトリプロバイダ８には、ユーザｋａｎａ、ｋｕｒｏｓｅ、ｍａｅｄａ、ａｉｔｏｈ、ｉｋｅｇａｍｉが登録されている。

また、新たに導入されたＬｏｃａｌ認証ディレクトリプロバイダ１２には、ユーザｋａｎａ、ｋｕｒｏｓｅ、ｍａｅｄａ及びｇｒｏｕｐ１、ｇｒｏｕｐ２、が登録されている。

以下、図５に示したＬｏｃａｌ認証ディレクトリプロバイダ１２に登録されているグループのメンバーの一例を、図６を用いて説明する。図６は、図５に示したＬｏｃａｌ認証ディレクトリプロバイダ１２に登録されているグループのメンバーの一例を説明するための図である。

図６に示されるように、図５のＬｏｃａｌ認証ディレクトリプロバイダ１２は、当該自身のプロバイダ内のユーザやグループをグループのメンバーとして保持する。

しかしながら、このように当該自身のプロバイダ内のユーザやグループをグループのメンバーとして保持するＬｏｃａｌプロバイダ１２を導入したとしても、図５のアプリケーション１１は、Ｌｏｃａｌプロバイダ１２のユーザやグループ又は他のプロバイダのユーザやグループ等を別々に管理しなくてはならない問題があった。

また、従来例で示したシステムにおいては、例えばユーザがＷｅｂブラウザ１を介してログイン名とパスワードとを入力して認証を求めた場合、認証を行ったプロバイダ以外のプロバイダに登録されているユーザのユーザ情報及び／又はユーザの所属するグループ情報が取得できない問題があった。

図７は、従来のプロバイダの問題点を説明するための図である。例えば、Windows（登録商標）認証ディレクトリプロバイダ７で認証が行われた場合、Windows（登録商標）認証ディレクトリプロバイダ７に登録されているユーザｋａｎａの情報や、ユーザｋａｎａが所属するグループの情報は取得できても、Ｎｏｔｅｓ（登録商標）認証ディレクトリプロバイダ８に登録されているユーザｋａｎａの情報や、ユーザｋａｎａが所属するグループの情報は取得できない問題があった。

また、従来例では、プロバイダ９に接続されたWindows（登録商標）やＮｏｔｅｓ（登録商標）やＬｏｃａｌのプロバイダが認証とユーザ情報及び／又はユーザの所属するグループ情報の提供との両方を行う認証ディレクトリプロバイダについて説明したが、これらのプロバイダがユーザ情報及び／又はユーザの所属するグループ情報を提供するディレクトリプロバイダであっても、上記と同様ユーザによって入力されたログイン名とパスワードとに基づいて、利用が許可されたディレクトリプロバイダ以外のディレクトリプロバイダに登録されているユーザのユーザ情報及び／又はユーザの所属するグループ情報が取得できない問題があった。

本発明は、上記の点に鑑みなされたもので、認証及び／又は利用が許可されたプロバイダと共に、それ以外のプロバイダに登録されているユーザのユーザ情報及び／又はユーザの所属するグループ情報を取得することを目的とする。

そこで、上記問題を解決するため、本発明は、ユーザに係る情報を提供する複数のユーザ情報提供手段と、該ユーザ情報提供手段を下位のユーザ情報提供手段として管理対象とする併合ユーザ情報提供手段とを有し、ユーザ情報管理サービスを行う併合情報提供装置であって、前記併合ユーザ情報提供手段は、前記ユーザに係る情報を前記ユーザ情報提供手段より取得するユーザ情報取得手段と、前記ユーザ情報取得手段により取得した複数の前記ユーザに係る情報を併合するユーザ情報併合手段と、前記ユーザ情報提供手段の利用を許可する第一利用許可情報を前記ユーザ情報提供手段より取得し、取得した第一利用許可情報を含む前記併合ユーザ情報提供手段の利用を許可する第二利用許可情報を作成する利用許可情報作成手段とを有し、前記ユーザ情報取得手段は、前記第一利用許可情報を用いて前記ユーザ情報提供手段より前記ユーザに係る情報を取得し、前記ユーザ情報併合手段は、前記ユーザ情報取得手段により取得した複数の前記ユーザに係る情報を併合して提供することを特徴とする。

本発明によれば、利用が許可されたプロバイダと共に、それ以外のプロバイダに登録されているユーザのユーザ情報及び／又はユーザの所属するグループ情報を取得することができる。

また、本発明は、前記ユーザ情報提供手段は、前記ユーザに係る情報を提供すると共にユーザに係る認証サービスを提供することを特徴とする。

本発明によれば、認証されたプロバイダと共に、それ以外のプロバイダに登録されているユーザのユーザ情報及び／又はユーザの所属するグループ情報を取得することができる。

また、本発明は、前記下位のユーザ情報提供手段の設定に係る要求を送信する設定要求送信手段を有することを特徴とする。

本発明によれば、下位のユーザ情報提供手段の設定を変更したり、新たに追加したりすることができる。

なお、特許請求の範囲に記載の第一利用許可情報は、例えば、後述するサブプロバイダ１４におけるセッションチケット３００又は該セッションチケット３００のセッションチケットＩＤ３１０に相当する。

また、特許請求の範囲に記載の第二利用許可情報は、例えば、後述するＵｎｉｏｎマージプロバイダ１３におけるセッションチケット２００又は該セッションチケット２００のセッションチケットＩＤ２１０に相当する。

また、特許請求の範囲に記載の第一認証情報は、例えば、後述するサブプロバイダ１４における認証チケット６００又は該認証チケット６００の認証チケットＩＤ６１０に相当する。

また、特許請求の範囲に記載の第二認証情報は、例えば、後述するＵｎｉｏｎマージプロバイダ１３における認証チケット５００又は該認証チケット５００の認証チケットＩＤ５１０に相当する。

また、特許請求の範囲に記載のユーザ識別情報は、例えば、後述するＵＩＤに相当する。

本発明によれば、認証及び／又は利用が許可されたプロバイダと共に、それ以外のプロバイダに登録されているユーザのユーザ情報及び／又はユーザの所属するグループ情報を取得することができる。

以下、本発明の実施の形態について図面に基づいて説明する。図８は、本発明によるＵｎｉｏｎマージプロバイダを導入した一例を説明するための図である。

図８のシステムは、Ｗｅｂブラウザ１と、Ｗｅｂポータル２と、Windows（登録商標）認証ディレクトリプロバイダ７と、Ｎｏｔｅｓ（登録商標）認証ディレクトリプロバイダ８と、アプリケーション１１と、Ｌｏｃａｌ認証ディレクトリプロバイダ１２と、Ｕｎｉｏｎマージプロバイダ１３とから構成される。

図８は、従来の技術において説明した図５のプロバイダ９に変わって、Ｕｎｉｏｎマージプロバイダ１３が新たに導入されている。

本発明におけるＵｎｉｏｎマージプロバイダ１３は、後述するように、管理対象となるプロバイダ（以下、サブプロバイダともいう）が、登録されているユーザ情報及び／又はユーザの所属するグループ情報を提供するプロバイダであった場合は、ユーザによって入力されたログイン名とパスワードとによって、利用許可されたサブプロバイダ以外のサブプロバイダからもこれらのサブプロバイダに登録されているユーザ情報及び／又はユーザの所属するグループ情報を取得することができる。

また、Ｕｎｉｏｎマージプロバイダ１３は、接続されたサブプロバイダが、登録されているユーザ情報及び／又はユーザの所属するグループ情報を提供すると共にユーザに係る認証サービスを提供するプロバイダであった場合も、ユーザによって入力されたログイン名とパスワードとによって、認証されたサブプロバイダ以外のサブプロバイダに登録されているユーザ情報及び／又はユーザの所属するグループ情報を取得することができる。

なお、サブプロバイダは図８を例に取ると、Windows（登録商標）認証ディレクトリプロバイダ７、Ｌｏｃａｌ認証ディレクトリプロバイダ１２、Ｎｏｔｅｓ（登録商標）認証ディレクトリプロバイダ８である。

以下、図８に示したＬｏｃａｌ認証ディレクトリプロバイダ１２に登録されているグループのメンバーの一例を、図９を用いて説明する。図９は、図８に示したＬｏｃａｌ認証ディレクトリプロバイダに登録されているグループのメンバーの一例を説明するための図である。

図９に示されるように、図８のＬｏｃａｌ認証ディレクトリプロバイダ１２は、他のプロバイダのユーザやグループをＬｏｃａｌ認証ディレクトリプロバイダ１２のグループのメンバーとして保持する。

したがって、図８に示したＬｏｃａｌ認証ディレクトリプロバイダ１２のグループｇｒｏｕｐ１は、例えば、Windows（登録商標）認証ディレクトリプロバイダ７のユーザｋａｎａと、Windows（登録商標）認証ディレクトリプロバイダ７のユーザｍａｅｄａと、Ｎｏｔｅｓ（登録商標）認証ディレクトリプロバイダ８のユーザｋａｎａとをメンバーとして持つ。

また、図８に示したＬｏｃａｌ認証ディレクトリプロバイダ１２は、他のプロバイダのユーザ情報等をユーザＩＤとして保持する。

以下、図８に示したＬｏｃａｌ認証ディレクトリプロバイダ１２のユーザＩＤの構造の一例を、図１０を用いて説明する。図１０は、図８に示したＬｏｃａｌ認証ディレクトリプロバイダのユーザＩＤの構造の一例を説明するための図である。

図１０（Ａ）に示すように、図８のＬｏｃａｌ認証ディレクトリプロバイダ１２のユーザＩＤは、ＩＤタイプと、認証を行ったプロバイダの識別子と、認証を行ったプロバイダにおけるユーザの識別子とを含む。

ＩＤタイプはユーザかグループかを表し、認証を行ったプロバイダの識別子は、例えばWindows（登録商標）、Ｎｏｔｅｓ（登録商標）などを表す。また認証を行ったプロバイダにおけるユーザの識別子は、例えば、ｋａｎａ、ｋｕｒｏｓｅ、ｍａｅｄａなどを表す。

図１０（Ｂ）は、図１０（Ａ）のユーザＩＤの一例である。Ｌｏｃａｌ認証ディレクトリプロバイダ１２は、図１０（Ｂ）に示されるようなユーザＩＤを保持することによって、例えばWindows（登録商標）認証ディレクトリプロバイダ７のユーザとＮｏｔｅｓ（登録商標）認証ディレクトリプロバイダ８のユーザとを区別した形で登録することができる。

このようなユーザＩＤを保持するＬｏｃａｌプロバイダ１２を導入することによって、図８のアプリケーション１１は、Ｌｏｃａｌプロバイダ１２のユーザＩＤに対応することで、他のプロバイダのユーザを別々に管理することなく、統合して扱うことができる。

したがって、ユーザは、Windows（登録商標）認証ディレクトリプロバイダ７で認証しても、Ｎｏｔｅｓ（登録商標）認証ディレクトリプロバイダ８で認証してもアプリケーション１１を使用することができるようになる。

以下、図８において示したＵｎｉｏｎマージプロバイダ１３及び／又はサブプロバイダを実装する装置の一例を、図１１を用いて説明する。

図１１は、本発明による融合機の一実施例の構成図を示す。融合機１２０は、白黒ラインプリンタ１５と、カラーラインプリンタ１６と、スキャナやファクシミリなどのハードウェアリソース１７と、ソフトウェア群２０と、融合機起動部５０とを有するように構成される。また、ソフトウェア群２０はアプリケーション３０とプラットフォーム４０とを有するように構成される。

プラットフォーム４０は、アプリケーション３０からの処理要求を解釈してハードウェア資源の獲得要求を発生するコントロールサービスと、１つ以上のハードウェア資源の管理を行ってコントロールサービスからの獲得要求を調停するシステムリソースマネージャ（以下、ＳＲＭという）４３と、オペレーティングシステム（以下、ＯＳという）４１とを有するように構成されている。

コントロールサービスは、システムコントロールサービス（以下、ＳＣＳという）４２、エンジンコントロールサービス（以下、ＥＣＳという）４４、メモリコントロールサービス（以下、ＭＣＳという）４５、オペレーションパネルコントロールサービス（以下、ＯＣＳという）４６、ファックスコントロールサービス（以下、ＦＣＳという）４７、ネットワークコントロールサービス（以下、ＮＣＳという）４８、ユーザ情報管理サービス（以下、ＵＣＳという）４９など一つ以上のサービスモジュールを有するように構成されている。

なお、プラットフォーム４０は予め定義されている関数によりアプリケーション３０からの処理要求を受信可能とするアプリケーションプログラムインターフェース（以下、ＡＰＩという）を有するように構成されている。

ＯＳ４１は、ユニックス（ＵＮＩＸ（登録商標））などのオペレーティングシステムであって、プラットフォーム４０及びアプリケーション３０の各ソフトウェアをプロセスとして並列実行する。

ＳＲＭ４３のプロセスは、ＳＣＳ４２と共にシステムの制御及びリソースの管理を行うものである。例えばＳＲＭ４３のプロセスは、スキャナ部やプリンタ部などのエンジン、メモリ、ハードディスク装置（ＨＤＤ）ファイル、ホストＩ／Ｏ（セントロインターフェース、ネットワークインターフェース、ＩＥＥＥ１３９４インターフェース、ＲＳ２３２Ｃインターフェースなど）のハードウェア資源を利用する上位層からの要求に従って調停を行い、実行制御する。

例えば、ＳＲＭ４３は、要求されたハードウェア資源が利用可能であるか（他の要求により利用されていないかどうか）を判定し、利用可能であれば要求されたハードウェア資源が利用可能である旨を上位層に通知する。また、ＳＲＭ４３は、上位層からの要求に対してハードウェア資源の利用スケジューリングを行い、例えばプリンタエンジンによる紙搬送と作像動作、メモリ確保、ファイル生成などの要求内容を直接実施している。

ＳＣＳ４２のプロセスは、アプリケーション管理、操作部制御、システム画面表示、ＬＥＤ表示、リソース管理、割り込みアプリケーション制御を行う。ＥＣＳ４４のプロセスは、白黒ラインプリンタ１５、カラーラインプリンタ１６、ハードウェアリソース１７のエンジンの制御を行う。

ＭＣＳ４５のプロセスは、画像メモリの取得及び解放、ハードディスク装置（ＨＤＤ）の利用、画像データの圧縮及び伸張などを行う。ＯＣＳ４６のプロセスは、オペレータと本体制御との間の情報伝達手段となるオペレーションパネルの制御を行う。

ＦＣＳ４７のプロセスは、システムコントローラの各アプリケーション層からＰＳＴＮまたはＩＳＤＮ網を利用したファクシミリ送受信、ＢＫＭ（バックアップＳＲＡＭ）で管理されている各種ファクシミリデータの登録／引用、ファクシミリ読み取り、ファクシミリ受信印刷、融合送受信を行うためのアプリケーションを提供する。

ＮＣＳ４８のプロセスは、ネットワークＩ／Ｏを必要とするアプリケーションに対し、共通に利用できるサービスを提供するものであり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、アプリケーションからのデータをネットワーク側に送信する際の仲介を行ったりする。

ＵＣＳ４９のプロセスは、ユーザ情報及び／又はユーザの所属するグループ情報の管理を行うものであり、要求に応じたユーザ情報及び／又はユーザの所属するグループ情報が格納されている記憶装置及び／又はネットワークを介して接続された他の装置を判定し、判定した記憶装置及び／又はネットワークを介して接続された他の装置からユーザ情報及び／又はユーザの所属するグループ情報を取得して各アプリケーションに供給する。

また、ＵＣＳ４９のプロセスは、ユーザ情報及び／又はユーザの所属するグループ情報の管理を行うと共に、ユーザに係る認証サービスを提供するようにしてもよい。

図８において説明したＵｎｉｏｎマージプロバイダ１３及び／又は他のサブプロバイダ（例えば、Ｌｏｃａｌ認証ディレクトリプロバイダ１２など）は、ＵＣＳ４９に実装する。

また、アプリケーション３０は、プリンタ、コピー、ファクシミリ、スキャナなどの画像形成処理にかかるユーザサービスにそれぞれ固有の処理を行うものである。アプリケーション３０は、ページ記述言語（ＰＤＬ、ＰＣＬ）及びポストスクリプト（ＰＳ）を有するプリンタ用のアプリケーションであるプリンタアプリ３１と、コピー用アプリケーションであるコピーアプリ３２と、ファクシミリ用アプリケーションであるファックスアプリ３３と、スキャナ用アプリケーションであるスキャナアプリ３４と、ネットワークファイル用アプリケーションであるネットファイルアプリ３５と、工程検査用アプリケーションである工程検査アプリ３６とを有している。

融合機起動部５０は、融合機１２０の電源投入時に最初に実行され、アプリケーション３０やプラットフォーム４０を起動するものである。例えば融合機起動部５０は、コントロールサービスやアプリケーションのプログラムを後述するフラッシュメモリから読み出し、読み出した各プログラムをＳＲＡＭまたはＳＤＲＡＭ上に確保したメモリ領域に転送して起動するものである。

図１２は、本発明による融合機の一実施例のハードウェア構成図を示す。図１２の融合機１２０は、コントローラボード６０と、オペレーションパネル７０と、ファックスコントロールユニット（以下、ＦＣＵという）８０と、ＵＳＢデバイス９０と、ＩＥＥＥ１３９４デバイス１００と、ドライバＩ／Ｆ１０１と、エンジン部１１０と、を有するように構成される。

ここで、ドライバＩ／Ｆ１０１は、挿入された、Ｕｎｉｏｎマージプロバイダ１３及び／又はサブプロバイダ１４に対応するプログラム等が格納されている記録媒体から、Ｕｎｉｏｎマージプロバイダ１３及び／又はサブプロバイダ１４に対応するプログラム等を読み込んで、融合機１２０搭載するのに用いるＩ／Ｆである。なお、例えば記録媒体としては、ＳＤメモリカード、スマートメディア、マルチメディアカード、コンパクトフラッシュ（登録商標）等がある。

オペレーションパネル７０は、コントローラボード６０のＡＳＩＣ６２に直接接続されている。また、ＦＣＵ８０、ＵＳＢデバイス９０、ＩＥＥＥ１３９４デバイス１００、ドライバＩ／Ｆ１０１及びエンジン部１１０は、コントローラボード６０のＡＳＩＣ６２にＰＣＩバス（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ ｂｕｓ）などで接続されている。

また、コントローラボード６０は、ＣＰＵ６１と、ＡＳＩＣ６２と、ＳＲＡＭ（Ｓｔａｔｉｃ ＲＡＭ）６３と、ＳＤＲＡＭ（Ｓｙｎｃｈｒｏｎｏｕｓ ＤＲＡＭ）６４と、フラッシュメモリ６５と、ＨＤＤ６６とを有するように構成される。コントローラボード６０は、ＣＰＵ６１、ＳＲＡＭ６３、ＳＤＲＡＭ６４、フラッシュメモリ６５、ＨＤＤ６６などをＡＳＩＣ６２に接続するように構成されている。

ＣＰＵ６１は、融合機１２０の全体制御を行うものである。ＣＰＵ６１は、ＯＳ４１上でプラットフォーム４０を形成するＳＣＳ４２、ＳＲＭ４３、ＥＣＳ４４、ＭＣＳ４５、ＯＣＳ４６、ＦＣＳ４７及びＮＣＳ４８をそれぞれプロセスとして起動して実行させると共に、アプリケーション３０を形成するプリンタアプリ３１、コピーアプリ３２、ファックスアプリ３３、スキャナアプリ３４、ネットファイルアプリ３５及び工程検査アプリ３６を起動して実行させる。

ＡＳＩＣ６２は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣである。ＳＲＡＭ６３及びＳＤＲＡＭ６４の物理メモリ領域には、カーネルやプロセスなどの仮想メモリ領域がマッピングされる。

以下、図１３から図１５を用いて、ＵＣＳ４９の構成例について説明する。図１３は、ＵＣＳの構成を説明するための図（その１）である。

図１３に示すように、ＵＣＳ４９は、図８のＵｎｉｏｎマージプロバイダ１３と、１つ以上のサブプロバイダ１４とから構成される。

図１３に示される構成をとることによって、ＵＣＳ４９は、後述するように、サブプロバイダ１４が提供するユーザ情報及び／又はユーザの所属するグループ情報をＵｎｉｏｎマージプロバイダ１３において統合し、例えば、融合機１２０のアプリケーション３０などに、マージしたユーザ情報及び／又はユーザの所属するグループ情報を提供することができる。

図１４は、ＵＣＳの構成を説明するための図（その２）である。図１４に示すように、ＵＣＳ４９は、サブプロバイダ１４を含まず、図８のＵｎｉｏｎマージプロバイダ１３のみから構成される。

図１４に示される構成をとることによって、例えば他の装置に実装されているサブプロバイダ１４が提供するユーザ情報及び／又はユーザの所属するグループ情報をＵｎｉｏｎマージプロバイダ１３においてマージし、例えば、融合機１２０のアプリケーション３０などに、マージしたユーザ情報及び／又はユーザの所属するグループ情報を提供することができる。

図１５は、ＵＣＳの構成を説明するための図（その３）である。図１５に示すように、ＵＣＳ４９は、図８のＵｎｉｏｎマージプロバイダ１３を含まず、少なくとも１つ以上のサブプロバイダ１４から構成される。

図１５に示される構成をとることによって、例えば他の装置に実装されているＵｎｉｏｎマージプロバイダ１３からの要求に応じてユーザ情報及び／又はユーザの所属するグループ情報を提供することができる。

以下では、説明の簡略化のため、Ｕｎｉｏｎマージプロバイダ１３とサブプロバイダ１４とを用いて説明を行う。

図１６は、本発明の第一実施例におけるＵｎｉｏｎマージプロバイダとサブプロバイダとの機能ブロック図である。

なお、第一の実施例においては、説明の簡略化のため、Ｕｎｉｏｎマージプロバイダ１３及びサブプロバイダ１４は、ユーザ情報及び／又はユーザの所属するグループ情報を提供し、ユーザの認証は行わないものとする。

図１６に示すように、Ｕｎｉｏｎマージプロバイダ１３は、プロバイダＩ／Ｆ１３０と、マージ処理部１３３と、サブプロバイダ呼び出し部１３４と、マージプロバイダＸＭＬ処理部１３５と、サブプロバイダ登録部１３６と、セッション管理部１３７とから構成される。

また、プロバイダＩ／Ｆ１３０は、ＸＭＬ処理部１３１と、ＵＩＤ変換部１３２とから構成される。

プロバイダＩ／Ｆ１３０は、Ｕｎｉｏｎマージプロバイダ１３と他のプロバイダ及び／又は他のアプリケーションとをつなぐインターフェースである。なお、後述するように、サブプロバイダ１４も同様のプロバイダＩ／Ｆ１３０を有する。

ＸＭＬ処理部１３１は、他のアプリケーションやＷｅｂポータルなどから送信されてきたＸＭＬメッセージを解析して、Ｕｎｉｏｎマージプロバイダ１３内においてプログラムが利用可能な形に処理する。

また、逆に、ＵＩＤ変換部１３２から渡されたデータなどを基にＸＭＬメッセージを作成し、アプリケーションやＷｅｂポータルなどに送信する。

なお、アプリケーションやＷｅｂポータルは、図１１を用いて説明したアプリケーション３０であってもよいし、融合機１２０とネットワークを介して接続された他の融合機１２０又は他の装置のアプリケーションであってもよい。

ＵＩＤ変換部１３２は、必要があれば、ＸＭＬメッセージに含まれているユーザＩＤ（以下、ＵＩＤという）を変換する。

例えば、ＸＭＬメッセージに含まれていたＵＩＤが従来の技術の図１０において説明したＵ：Windows（登録商標）：ｋａｎａの構成であり、プロバイダ内部でのＵＩＤの構成がｋａｎａだった場合は、ＵＩＤ変換部１３２は、Ｕ：Windows（登録商標）：ｋａｎａからｋａｎａにＵＩＤを変換する。同様に、プロバイダからＸＭＬメッセージを送信する場合で、必要な場合は、ｋａｎａからＵ：Windows（登録商標）：ｋａｎａへのＵＩＤの変換も行う。

マージ処理部１３３は、後述するように、サブプロバイダ１４に登録されているユーザのユーザ情報及び／又はユーザの所属するグループ情報をマージする。

サブプロバイダ呼び出し部１３４は、サブプロバイダ１４に送信するＸＭＬメッセージを作成するのに必要なデータを、後述するマージプロバイダＸＭＬ処理部１３５に渡す。

また、サブプロバイダ呼び出し部１３４は、後述するマージプロバイダＸＭＬ処理部１３５を介してサブプロバイダ１４から取得したユーザ情報及び／又はユーザの所属するグループ情報を、マージ処理部１３３に渡す。

マージプロバイダＸＭＬ処理部１３５は、サブプロバイダ呼び出し部１３４より渡されたデータを基にＸＭＬメッセージを作成し、指定されたサブプロバイダ１４に送信する。

また、マージプロバイダＸＭＬ処理部１３５は、サブプロバイダ１４から送信されたＸＭＬメッセージを受信して、ＸＭＬメッセージに含まれているデータをサブプロバイダ呼び出し部１３４に渡す。

サブプロバイダ登録部１３６には、管理対象となるサブプロバイダ１４に関するデータが登録されている。サブプロバイダ登録部１３６には、例えば、サブプロバイダ１４の識別子、サブプロバイダ１４の名前、サブプロバイダ１４の管理用ＩＤ、サブプロバイダ１４の管理用パスワードなどがそれぞれサブプロバイダ１４ごとに登録されている。

例えば、新たなサブプロバイダ１４をＵｎｉｏｎマージプロバイダ１３に登録する際は、前記サブプロバイダ１４の識別子、サブプロバイダ１４の名前、サブプロバイダ１４の管理用ＩＤ、サブプロバイダ１４の管理用パスワードをそれぞれサブプロバイダ登録部１３６に登録する。

セッション管理部１３７は、Ｕｎｉｏｎマージプロバイダ１３と他のサブプロバイダ１４及び他のアプリケーションやＷｅｂポータルなどとのセッションを管理する。

例えば、ＸＭＬ処理部１３１において取得したＸＭＬメッセージに、Ｕｎｉｏｎプロバイダ１３の利用を許可した有効なセッションチケット２００のセッションチケットＩＤ２１０が含まれているかどうかを解析する。

また、セッション管理部１３７は、サブプロバイダ登録部１３６に登録されているサブプロバイダ１４の管理用ＩＤとサブプロバイダ１４の管理用パスワードとを用いて、サブプロバイダ１４から匿名のセッションチケット３００のセッションチケットＩＤ３１０を取得する。

セッション管理部１３７は、取得したサブプロバイダ１４のセッションチケットＩＤ３１０などを用いて、後述するＵｎｉｏｎマージプロバイダ１３のセッションチケット２００を作成する。

セッション管理部１３７は、例えば、ユーザがＵＩＤとパスワードとを用いてセッションチケット４００の作成を要求したサブプロバイダ１４以外のサブプロバイダ１４からも匿名のセッションチケット３００のセッションチケットＩＤ３１０を取得することができるため、Ｕｎｉｏｎマージプロバイダ１３は、管理対象としているサブプロバイダ１４全てからユーザ情報及び／又はユーザの所属するグループ情報を取得することができる。

図１７は、Ｕｎｉｏｎマージプロバイダのセッションチケットの構造を説明するための概念図である。

図１７に示すように、Ｕｎｉｏｎマージプロバイダ１３のセッションチケット２００は、セッションチケットＩＤ２１０と、プロバイダタイプと、公開するプロバイダ名と、１つ以上のサブプロバイダ名と、１つ以上のサブプロバイダのセッションチケット３００及び／又はセッションチケット４００とを構造として持つ。

セッションチケットＩＤ２１０は、当該セッションチケットを識別する識別子である。プロバイダタイプは、例えば「Ｕｎｉｏｎマージ」など、プロバイダのタイプである。

公開するプロバイダ名は、例えば「Ｕｎｉｏｎマージ１」など、公開するＵｎｉｏｎマージプロバイダ１３の名前である。

サブプロバイダ名は、登録されている１つ以上のサブプロバイダ１４の名前である。サブプロバイダのセッションチケットには、前記登録されている１つ以上のサブプロバイダ１４とＵｎｉｏｎマージプロバイダ１３とのセッションチケット３００及び／又はセッションチケット４００が格納されている。

また、セッションチケット４００は、ユーザによって入力されたＵＩＤとパスワードとを基に作成されたサブプロバイダ１４のセッションチケットであり、セッションチケット３００は、サブプロバイダ登録部１３６に格納されている管理者権限の管理用ＩＤと管理用パスワードと基に作成されたサブプロバイダ１４のセッションチケットである。

なお、以下では説明の簡略化のため、Ｕｎｉｏｎマージプロバイダ１３のセッションチケット２００に含まれるサブプロバイダ１４のセッションチケットは、匿名のセッションチケット３００のみであるとして説明を行う。

図１７に示すような階層構造を持つことによって、サブプロバイダ１４がＵｎｉｏｎマージプロバイダ１３となることも可能となる。

なお、図１７においては、サブプロバイダのセッションチケットには、前記登録されている１つ以上のサブプロバイダ１４とＵｎｉｏｎマージプロバイダ１３とのセッションチケット３００及び／又はセッションチケット４００が格納されている例を用いて説明を行ったが、デコードされたセッションチケット３００及び／又はセッションチケット４００が格納されていてもよい。

図１６のサブプロバイダ１４は、プロバイダＩ／Ｆ１３０と、ディレクトリ操作ラッパー１４１と、セッション管理部１４２とから構成される。

ディレクトリ操作ラッパー１４１は、サブプロバイダ１４内のデータをディレクトリ１５０のユーザ情報保存部１５２に保存されているユーザ情報やグループ情報保存部１５３に保存されているユーザの所属するグループ情報を操作可能なデータに変形し、前記ユーザ情報や前記ユーザの所属するグループ情報をディレクトリ１５０から取得する。

また、取得したユーザ情報やグループ情報をサブプロバイダ１４内において処理可能なデータに変形する。

ディレクトリ操作ラッパー１４１のデータの変形の一例は、後述する図１８を用いて説明する。

セッション管理部１４２は、サブプロバイダ１４とＵｎｉｏｎマージプロバイダ１３とのセッションを管理する。

例えば、ＸＭＬ処理部１３１において取得したＸＭＬメッセージに、サブプロバイダ１４の利用を許可した有効なセッションチケット３００のセッションチケットＩＤ３１０が含まれているかどうかを解析する。

また、セッション管理部１４２は、プロバイダＩ／Ｆ１３０を介して、Ｕｎｉｏｎマージプロバイダ１３から管理用ＩＤと管理用パスワードと含む匿名のセッションチケット３００の作成リクエストを取得すると、匿名のセッションチケット３００を作成する。

また、セッション管理部１４２は、前記作成した匿名のセッションチケット３００のセッションチケットＩＤ３１０をプロバイダＩ／Ｆ１３０に渡し、セッションチケットＩＤ３１０を含む匿名のセッションチケット３００の作成レスポンスをＵｎｉｏｎマージプロバイダ１３に送信する。

また、図１６のディレクトリ１５０は、ユーザ情報保存部１５２と、グループ情報保存部１５３とを含む。

ユーザ情報保存部１５２は、サブプロバイダ１４に登録されているユーザのユーザ情報が保存されている。例えば、ＵＩＤや、ユーザの名前、ユーザのパスワードなどが保存されている。

また、グループ情報保存部１５３には、サブプロバイダ１４に登録されているユーザが所属するグループ情報が保存されている。例えば、グループＩＤ、グループの名前、グループのメンバーなどが保存されている。

図１８は、ディレクトリ操作ラッパーのデータの変形の一例を説明するための図である。

図１８（Ａ）は、サブプロバイダ１４内のデータをディレクトリ１５０のユーザ情報保存部１５２に保存されているユーザ情報やグループ情報保存部１５３に保存されているユーザの所属するグループ情報を操作可能なデータに変形した一例である。

図１８（Ｂ）は、ディレクトリ１５０のユーザ情報保存部１５２に保存されているユーザ情報やグループ情報保存部１５３に保存されているユーザの所属するグループ情報のデータをサブプロバイダ１４内で処理可能なデータに変形した一例である。

図１９は、Ｕｎｉｏｎマージプロバイダにおけるユーザの所属グループ取得処理の一例のフローチャートである。

なお、以下では、説明の簡略化のため、Ｕｎｉｏｎマージプロバイダ１３にユーザが所属するグループ情報の取得リクエストを送信するアプリケーション又はＷｅｂポータルなどを単にクライアントという。

ステップＳ２０では、Ｕｎｉｏｎマージプロバイダ１３のＸＭＬ処理部１３１は、クライアントよりユーザの所属グループの取得リクエストを受信する。

クライアントからＵｎｉｏｎマージプロバイダ１３へのグループ取得リクエストの一例は、後述する図２１を用いて説明する。

ステップＳ２０に続いてステップＳ２１に進み、セッション管理部１３７は、ステップＳ２０において受信したユーザの所属グループの取得リクエストに含まれるＵｎｉｏｎマージプロバイダ１３のセッションチケット２００のセッションチケットＩＤ２１０が有効なセッションチケットＩＤ２１０であるかどうかを判定する。

有効なセッションチケット２００のセッションチケットＩＤ２１０であると判定すると（ステップＳ２１においてＹＥＳ）、ステップＳ２２に進み、無効なセッションチケット２００のセッションチケットＩＤ２１０であると判定すると（ステップＳ２１においてＮＯ）、ステップＳ２６に進む。

ステップＳ２２では、セッション管理部１３７は、Ｕｎｉｏｎマージプロバイダ１３のセッションチケット２００に含まれる全てのサブプロバイダ１４のセッションチケット３００のセッションチケットＩＤ３１０と、サブプロバイダ名とをサブプロバイダ呼び出し部１３４に渡す。

ステップＳ２２に続いてステップＳ２３に進み、マージプロバイダＸＭＬ処理部１３５は、サブプロバイダ呼び出し部１３４を介して取得した、サブプロバイダ１４のセッションチケット３００のセッションチケットＩＤ３１０を含む各サブプロバイダ１４に対するユーザの所属グループの取得リクエストを作成し、各サブプロバイダ１４に送信する。

Ｕｎｉｏｎマージプロバイダ１３から各サブプロバイダ１４へのグループ取得リクエストの一例は、後述する図２２を用いて説明する。

ステップＳ２３に続いてステップＳ２４に進み、サブプロバイダ呼び出し部１３４は、マージプロバイダＸＭＬ処理部１３５を介して、各サブプロバイダ１４からユーザの所属グループの取得リクエストに対する所属グループ取得レスポンスを受信する。

各サブプロバイダ１４からＵｎｉｏｎマージプロバイダ１３へのグループ取得レスポンスの一例は、後述する図２３を用いて説明する。

ステップＳ２４に続いてステップＳ２５に進み、サブプロバイダ呼び出し部１３４は、ステップＳ２４において受信した各サブプロバイダ１４からの所属グループ取得レスポンスに、指定したユーザの所属グループ情報が含まれているかどうかを判定する。

ユーザの所属グループ情報が１つでも含まれていると判定すると（ステップＳ２５においてＹＥＳ）、ステップＳ２７に進み、ユーザの所属グループが１つも含まれていないと判定すると（ステップＳ２５においてＮＯ）、ステップＳ２６に進む。

ステップＳ２６では、Ｕｎｉｏｎマージプロバイダ１３のＸＭＬ処理部１３１は、ユーザの所属グループの取得が失敗した旨のレスポンスを作成し、クライアントに送信する。

ステップＳ２７では、マージ処理部１３３が、ステップＳ２４において取得した各サブプロバイダ１４からの所属グループ取得レスポンスに含まれるユーザの所属グループをマージする。

ステップＳ２７に続いてステップＳ２８に進み、Ｕｎｉｏｎマージプロバイダ１３のＸＭＬ処理部１３１は、ステップＳ２７においてマージしたユーザの所属グループの情報を含む所属グループ取得レスポンスを作成し、クライアントに送信する。

Ｕｎｉｏｎマージプロバイダ１３からクライアントへのグループ取得レスポンスの一例は、後述する図２４を用いて説明する。

図２０は、サブプロバイダにおけるユーザの所属グループ取得処理の一例のフローチャートである。

サブプロバイダ１４は、図１９のステップＳ２３においてＵｎｉｏｎマージプロバイダ１３が、ユーザの所属グループの取得リクエストを各サブプロバイダ１４に送信すると、以下に示すステップＳ３０からの処理を開始する。

ステップＳ３０では、サブプロバイダ１４のＸＭＬ処理部１３１は、Ｕｎｉｏｎマージプロバイダ１３よりユーザの所属グループの取得リクエストを受信する。

上述したように、Ｕｎｉｏｎマージプロバイダ１３から各サブプロバイダ１４へのグループ取得リクエストの一例は、後述する図２２を用いて説明する。

ステップＳ３０に続いてステップＳ３１に進み、サブプロバイダ１４のＵＩＤ変換部１３２は、ステップＳ３０において受信したユーザの所属グループの取得リクエストに含まれるＵＩＤをディレクトリ１５０固有のＵＩＤに変換する。

ステップＳ３１に続いてステップＳ３２に進み、セッション管理部１４２は、ステップＳ３０において受信したユーザの所属グループの取得リクエストに含まれるサブプロバイダ１４のセッションチケット３００のセッションチケットＩＤ３１０が有効なセッションチケット３００のセッションチケットＩＤ３１０であるかどうかを判定する。

有効なセッションチケット３００のセッションチケットＩＤ３１０であると判定すると（ステップＳ３２においてＹＥＳ）、ステップＳ３４に進み、無効なセッションチケット３００のセッションチケットＩＤ３１０であると判定すると（ステップＳ３２においてＮＯ）、ステップＳ３３に進む。

ステップＳ３３では、サブプロバイダ１４のＸＭＬ処理部１３１は、ユーザの所属グループの取得が失敗した旨の所属グループ取得レスポンスを作成し、Ｕｎｉｏｎマージプロバイダ１３に送信する。

ステップＳ３４では、サブプロバイダ１４は、ディレクトリ操作ラッパー１４１を介してディレクトリ１５０からユーザの所属するグループ情報を取得する。

ステップＳ３４に続いてステップＳ３５に進み、サブプロバイダ１４のＵＩＤ変換部１３２は、ディレクトリ１５０固有のＵＩＤをＵｎｉｏｎマージプロバイダ１３が利用可能なＵＩＤに変換する。

ステップＳ３５に続いてステップＳ３６に進み、サブプロバイダ１４のＸＭＬ処理部１３１は、ユーザの所属グループの情報を含む所属グループ取得レスポンスを作成し、Ｕｎｉｏｎマージプロバイダ１３に送信する。

上述したように、各サブプロバイダ１４からＵｎｉｏｎマージプロバイダ１３へのグループ取得レスポンスの一例は、後述する図２３を用いて説明する。

なお、図１９のステップＳ２４は、図２０のステップＳ３３又はステップＳ３６において送信した所属グループ取得レスポンスを受信する。

図２１は、クライアントからＵｎｉｏｎマージプロバイダへのグループ取得リクエストの一例のＸＭＬメッセージである。

図２１に示すように、クライアントからＵｎｉｏｎマージプロバイダ１３へのユーザの所属するグループの取得リクエストには、＜ｓｅｓｓｉｏｎＴｉｃｋｅｔ＞＜／ｓｅｓｓｉｏｎＴｉｃｋｅｔ＞のタグに、Ｕｎｉｏｎマージプロバイダ１３のセッションチケット２００のセッションチケットＩＤ２１０が含まれている。

また、＜ｉｄ＞＜／ｉｄ＞のタグには、ユーザを特定するＵＩＤが含まれている。

クライアントは、ユーザのＵＩＤとＵｎｉｏｎマージプロバイダ１３のセッションチケット２００のセッションチケットＩＤ２１０とを含むユーザの所属するグループ取得リクエストをＵｎｉｏｎマージプロバイダ１３へ送信する。

図２２は、Ｕｎｉｏｎマージプロバイダからサブプロバイダへのグループ取得リクエストの一例のＸＭＬメッセージである。

図２２（Ａ）は、Ｕｎｉｏｎマージプロバイダ１３からサブプロバイダ１４の１つであるＬｏｃａｌディレクトリプロバイダ１６０へのグループ取得リクエストの一例のＸＭＬメッセージである。

図２２（Ａ）に示すように、Ｕｎｉｏｎマージプロバイダ１３からＬｏｃａｌディレクトリプロバイダ１６０へのユーザの所属するグループの取得リクエストには、＜ｓｅｓｓｉｏｎＴｉｃｋｅｔ＞＜／ｓｅｓｓｉｏｎＴｉｃｋｅｔ＞のタグに、Ｌｏｃａｌディレクトリプロバイダ１６０のセッションチケット３００のセッションチケットＩＤ３１０が含まれている。

また、＜ｉｄ＞＜／ｉｄ＞のタグには、ユーザを特定するＵＩＤが含まれている。なお、このＵＩＤは、図２１のＸＭＬメッセージに含まれるＵＩＤと同様のものである。

図２２（Ｂ）は、Ｕｎｉｏｎマージプロバイダ１３からサブプロバイダ１４の１つであるＷｉｎＮＴ４ディレクトリプロバイダ１６１へのグループ取得リクエストの一例のＸＭＬメッセージである。

図２２（Ｂ）に示すように、Ｕｎｉｏｎマージプロバイダ１３からＷｉｎＮＴ４ディレクトリプロバイダ１６１へのユーザの所属するグループの取得リクエストには、＜ｓｅｓｓｉｏｎＴｉｃｋｅｔ＞＜／ｓｅｓｓｉｏｎＴｉｃｋｅｔ＞のタグに、ＷｉｎＮＴ４ディレクトリプロバイダ１６１のセッションチケット３００のセッションチケットＩＤ３１０が含まれている。

また、＜ｉｄ＞＜／ｉｄ＞のタグには、ユーザを特定するＵＩＤが含まれている。なお、このＵＩＤは、図２１のＸＭＬメッセージに含まれるＵＩＤと同様のものである。

図２２（Ｃ）は、Ｕｎｉｏｎマージプロバイダ１３からサブプロバイダ１４の１つであるＮｏｔｅｓ（登録商標）Ｒ５ディレクトリプロバイダ１６２へのグループ取得リクエストの一例のＸＭＬメッセージである。

図２２（Ｃ）に示すように、Ｕｎｉｏｎマージプロバイダ１３からＮｏｔｅｓ（登録商標）Ｒ５ディレクトリプロバイダ１６２へのユーザの所属するグループの取得リクエストには、＜ｓｅｓｓｉｏｎＴｉｃｋｅｔ＞＜／ｓｅｓｓｉｏｎＴｉｃｋｅｔ＞のタグに、Ｎｏｔｅｓ（登録商標）Ｒ５ディレクトリプロバイダ１６２のセッションチケット３００のセッションチケットＩＤ３１０が含まれている。

また、＜ｉｄ＞＜／ｉｄ＞のタグには、ユーザを特定するＵＩＤが含まれている。なお、このＵＩＤは、図２１のＸＭＬメッセージに含まれるＵＩＤと同様のものである。

Ｕｎｉｏｎマージプロバイダ１３は、図１７において説明したように、セッションチケットを階層的な構造で管理しているため、クライアントから送信されたユーザのグループの取得リクエストに含まれるＵｎｉｏｎマージプロバイダ１３のセッションチケット２００のセッションチケットＩＤ２１０を基に、サブプロバイダ１４であるＬｏｃａｌディレクトリプロバイダ１６０や、ＷｉｎＮＴ４ディレクトリプロバイダ１６１及びＮｏｔｅｓ（登録商標）Ｒ５ディレクトリプロバイダ１６２のセッションチケット３００のセッションチケットＩＤ３１０を取得し、該セッションチケットＩＤ３１０をそれぞれへのＸＭＬメッセージに含めることができる。

図２３は、サブプロバイダからＵｎｉｏｎマージプロバイダへのグループ取得レスポンスの一例のＸＭＬメッセージである。

図２３（Ａ）は、サブプロバイダ１４の１つであるＬｏｃａｌディレクトリプロバイダ１６０からＵｎｉｏｎマージプロバイダ１３へのグループ取得レスポンスの一例のＸＭＬメッセージである。

図２３（Ａ）に示すように、Ｌｏｃａｌディレクトリプロバイダ１６０からＵｎｉｏｎマージプロバイダ１３へのユーザの所属するグループの取得レスポンスには、＜ｇｒｏｕｐＬｉｓｔ＞＜／ｇｒｏｕｐＬｉｓｔ＞のタグに含まれる各＜ｉｔｅｍ＞＜／ｉｔｅｍ＞のタグに、指定されたユーザのＬｏｃａｌディレクトリプロバイダ１６０における所属するグループ情報が含まれている。

図２３（Ｂ）は、サブプロバイダ１４の１つであるＷｉｎＮＴ４ディレクトリプロバイダ１６１からＵｎｉｏｎマージプロバイダ１３へのグループ取得レスポンスの一例のＸＭＬメッセージである。

図２３（Ｂ）に示すように、ＷｉｎＮＴ４ディレクトリプロバイダ１６１からＵｎｉｏｎマージプロバイダ１３へのユーザの所属するグループの取得レスポンスには、＜ｇｒｏｕｐＬｉｓｔ＞＜／ｇｒｏｕｐＬｉｓｔ＞のタグに含まれる各＜ｉｔｅｍ＞＜／ｉｔｅｍ＞のタグに、指定されたユーザのＷｉｎＮＴ４ディレクトリプロバイダ１６１における所属するグループ情報が含まれている。

図２３（Ｃ）は、サブプロバイダ１４の１つであるＮｏｔｅｓ（登録商標）Ｒ５ディレクトリプロバイダ１６２からＵｎｉｏｎマージプロバイダ１３へのグループ取得レスポンスの一例のＸＭＬメッセージである。

図２３（Ｃ）に示すように、Ｎｏｔｅｓ（登録商標）Ｒ５ディレクトリプロバイダ１６１は、指定されたユーザが所属するグループ情報が存在しない場合には、＜ｉｔｅｍ＞＜／ｉｔｅｍ＞のタグを含まない取得レスポンスを、Ｕｎｉｏｎマージプロバイダ１３へ送信する。

各サブプロバイダ１４は、指定されたユーザが所属するグループが存在する場合は、該所属するグループの情報をディレクトリ１５０から取得し、Ｕｎｉｏｎマージプロバイダ１３に送信する。

図２４は、Ｕｎｉｏｎマージプロバイダからクライアントへのグループ取得レスポンスの一例のＸＭＬメッセージである。

図２４に示されるように、Ｕｎｉｏｎマージプロバイダ１３は、１つの＜ｇｒｏｕｐＬｉｓｔ＞＜／ｇｒｏｕｐＬｉｓｔ＞のタグに、各サブプロバイダ１４から取得した、グループ情報が含まれる＜ｉｔｅｍ＞＜／ｉｔｅｍ＞のタグをマージして格納し、クライアントへ送信する。

クライアントは、Ｕｎｉｏｎマージプロバイダ１３のセッションチケット２００のセッションチケットＩＤ２１０とユーザを特定するＵＩＤとを含むユーザの所属するグループの取得リクエストを、Ｕｎｉｏｎマージプロバイダ１３に送信することによって、Ｕｎｉｏｎマージプロバイダ１３が管理している、ディレクトリ１５０に係るサービスを提供する各サブプロバイダ１４に登録されているユーザの所属するグループの情報を、Ｕｎｉｏｎマージプロバイダ１３から取得することができる。

例えば、図２４の＜ｉｔｅｍ＞Ｇ：Ｌｏｃａｌ：ｇｒｏｕｐ１＜／ｉｔｅｍ＞と＜ｉｔｅｍ＞Ｇ：Ｌｏｃａｌ：ｇｒｏｕｐ２＜／ｉｔｅｍ＞とは、ＷｉｎＮＴ４ディレクトリプロバイダ１６１のユーザとしてＬｏｃａｌディレクトリプロバイダ１６０に登録されているユーザ３２３−５３４５４２４４が所属するグループの情報であり、図２４の＜ｉｔｅｍ＞Ｇ：ＷｉｎＮＴ４：ｇｒｏｕｐ１＜／ｉｔｅｍ＞と＜ｉｔｅｍ＞Ｇ：ＷｉｎＮＴ４：ｇｒｏｕｐ２＜／ｉｔｅｍ＞とは、ＷｉｎＮＴ４ディレクトリプロバイダ１６１のユーザとしてＷｉｎＮＴ４ディレクトリプロバイダ１６１に登録されているユーザ３２３−５３４５４２４４が所属するグループの情報である。

なお、第一の実施例の説明においては、Ｕｎｉｏｎマージプロバイダ１３とサブプロバイダ１４との間、及びＵｎｉｏｎマージプロバイダ１３とクライアントとの間は、セッションチケットＩＤ２１０及び／又はセッションチケットＩＤ３１０を送受信する場合を例にとって説明したが、これは本実施を制限するものではなく、セッションチケット２００及び／又はセッションチケット３００を送受信してもよい。

以上、第一の実施例においては、サブプロバイダ１４が、認証を必要としない場合について説明を行ったが、以下に示す第二の実施例においては、サブプロバイダ１４が認証を必要とする場合について説明する。

図２５は、本発明の第二実施例におけるＵｎｉｏｎマージプロバイダとサブプロバイダとの機能ブロック図である。

なお、上述したように、第二の実施例においては、サブプロバイダ１４は、ユーザ情報及び／又はユーザの所属するグループ情報を提供すると共に、ユーザに係る認証サービスを提供するものとする。

図２５に示すように、Ｕｎｉｏｎマージプロバイダ１３は、プロバイダＩ／Ｆ１３０と、マージ処理部１３３と、サブプロバイダ呼び出し部１３４と、マージプロバイダＸＭＬ処理部１３５と、サブプロバイダ登録部１３６と、セッション管理部１３７と、ＩＤパスワード解析部１３８と、認証チケット管理部１３９とから構成される。

また、プロバイダＩ／Ｆ１３０は、ＸＭＬ処理部１３１と、ＵＩＤ変換部１３２とから構成される。

図２５の第二実施例におけるＵｎｉｏｎマージプロバイダ１３の構成は、図１６の第一実施例におけるＵｎｉｏｎマージプロバイダ１３の構成と比べて、ＩＤパスワード解析部１３８と、認証チケット管理部１３９とが新たに追加されている。

ＩＤパスワード解析部１３８は、クライアント（例えば、Ｗｅｂポータル）から送信されたＵｎｉｏｎマージプロバイダ１３におけるユーザを認証する認証チケット５００の作成リクエストに含まれるＩＤとパスワードとを取得して、サブプロバイダ呼び出し部１３４に渡す。

サブプロバイダ呼び出し部１３４は、ＩＤパスワード解析部１３８より渡されたＩＤとパスワードとを後述するマージプロバイダＸＭＬ処理部１３５に渡す。

また、サブプロバイダ呼び出し部１３４は、後述するように、マージプロバイダＸＭＬ処理部１３５を介して、認証に成功した１つのサブプロバイダ１４から取得した該サブプロバイダ１４におけるユーザを認証する認証チケット６００の認証チケットＩＤ６１０を、認証チケット管理部１３９に渡す。

マージプロバイダＸＭＬ処理部１３５は、サブプロバイダ呼び出し部１３４より渡されたデータを基にＸＭＬメッセージを作成し、サブプロバイダ登録部１３６に登録されている全てのサブプロバイダ１４に対して送信する。

また、マージプロバイダＸＭＬ処理部１３５は、サブプロバイダ１４からのＸＭＬメッセージを受信して、データをサブプロバイダ呼び出し部１３４に渡す。

例えば、認証に成功した１つのサブプロバイダ１４からの認証レスポンスを受信すると、該サブプロバイダ１４におけるユーザを認証する認証チケット６００の認証チケットＩＤ６１０をサブプロバイダ呼び出し部１３４に渡す。

認証チケット管理部１３９は、認証に成功したサブプロバイダ１４より取得した認証チケット６００の認証チケットＩＤ６１０を基に、Ｕｎｉｏｎマージプロバイダ１３におけるユーザを認証する認証チケット５００を作成し、管理する。

また、認証チケット管理部１３９は、前記作成したＵｎｉｏｎマージプロバイダ１３におけるユーザを認証する認証チケット５００の認証チケットＩＤ５１０を、Ｕｎｉｏｎマージプロバイダ１３のプロバイダＩ／Ｆ１３０を介して、認証の要求を行ったクライアント（例えば、Ｗｅｂポータル）に送信する。

図２６は、Ｕｎｉｏｎマージプロバイダの認証チケットの構造を説明するための概念図である。

図２６に示すように、Ｕｎｉｏｎマージプロバイダ１３の認証チケット５００は、認証チケットＩＤ５１０と、プロバイダタイプと、公開するプロバイダ名と、サブプロバイダ名と、サブプロバイダの認証チケット６００とを構造として持つ。

認証チケットＩＤ５１０は、当該認証チケットを識別する識別子である。プロバイダタイプは、例えば「Ｕｎｉｏｎマージ」など、プロバイダのタイプである。

公開するプロバイダ名は、例えば「Ｕｎｉｏｎマージ１」など、公開するＵｎｉｏｎマージプロバイダ１３の名前である。

サブプロバイダ名は、登録されているサブプロバイダ１４の内、認証が成功し、認証チケット６００の送信があったサブプロバイダ１４の名前である。サブプロバイダの認証チケットは、認証が成功し、認証チケット６００の送信があったサブプロバイダ１４の認証チケット６００である。

図２６に示すような構造を持つことによって、ユーザは認証を一回で終えることが可能となる。

なお、サブプロバイダの認証チケットとして、認証が成功し、認証チケット６００の送信があったサブプロバイダ１４の認証チケット６００をデコードしたものを含むようにしてもよい。

図２５のサブプロバイダ１４は、プロバイダＩ／Ｆ１３０と、ディレクトリ操作ラッパー１４１と、セッション管理部１４２と、ＩＤパスワード解析部１４３と、認証チケット管理部１４４とから構成される。

図２５の第二実施例におけるサブプロバイダ１４の構成は、図１６の第一実施例におけるサブプロバイダ１４の構成に比べて、ＩＤパスワード解析部１４３と、認証チケット管理部１４４とが新たに追加されている。

ＩＤパスワード解析部１４３は、Ｕｎｉｏｎマージプロバイダ１３から送信された認証チケット６００の作成リクエストに含まれるＩＤとパスワードとを取得して、ディレクトリ操作ラッパー１４１を介して、ＩＤとパスワードとが正しい組み合わせであるかどうかをディレクトリ１５０のユーザ情報保存部１５２を参照して確認する。

また、ＩＤパスワード解析部１４３は、ＩＤとパスワードとが正しい組み合わせであった場合は、ディレクトリ操作ラッパー１４１を介して、対応するユーザのユーザ情報をディレクトリ１５０から取得して、認証チケット管理部１４４に渡す。

認証チケット管理部１４４は、ＩＤパスワード解析部１４３から渡されたユーザ情報を基に、サブプロバイダ１４におけるユーザを認証する認証チケット６００を作成する。

図２７は、Ｕｎｉｏｎマージプロバイダにおける認証チケット作成処理の一例のフローチャートである。

ステップＳ４０では、Ｕｎｉｏｎマージプロバイダ１３のＸＭＬ処理部１３１は、クライアント（例えば、Ｗｅｂポータル）よりＵｎｉｏｎマージプロバイダ１３におけるユーザを認証する認証チケット５００の作成リクエストを受信する。

クライアント（例えば、Ｗｅｂポータル）からＵｎｉｏｎマージプロバイダ１３への認証チケット作成リクエストの一例は、後述する図２９を用いて説明する。

ステップＳ４０に続いてステップＳ４１に進み、ＩＤパスワード解析部１３８は、ステップＳ４０においてクライアント（例えば、Ｗｅｂポータル）から受信した認証チケットの作成リクエストに含まれるＩＤとパスワードとをサブプロバイダ呼び出し部１３４に渡す。

ステップＳ４１に続いてステップＳ４２に進み、サブプロバイダ呼び出し部１３４は、サブプロバイダ登録部１３６に登録されているサブプロバイダ１４の一覧を取得する。

ステップＳ４２に続いてステップＳ４３に進み、マージプロバイダＸＭＬ処理部１３５は、サブプロバイダ呼び出し部１３４を介して取得したＩＤとパスワードとを含む、サブプロバイダ１４におけるユーザを認証する認証チケット６００の作成リクエストを作成し、サブプロバイダ１４の一覧に登録されている各サブプロバイダ１４に対して送信する。

Ｕｎｉｏｎマージプロバイダ１３からサブプロバイダ１４への認証チケット作成リクエストの一例は、後述する図３０を用いて説明する。

ステップＳ４３に続いてステップＳ４４に進み、サブプロバイダ呼び出し部１３４は、マージプロバイダＸＭＬ処理部１３５を介して、各サブプロバイダ１４から認証チケット６００の作成リクエストに対する認証チケット作成レスポンスを受信する。

サブプロバイダ１４からＵｎｉｏｎマージプロバイダ１３への認証チケット作成レスポンスの一例は、後述する図３１を用いて説明する。

ステップＳ４４に続いてステップＳ４５に進み、サブプロバイダ呼び出し部１３４は、ステップＳ４４において受信した各サブプロバイダ１４からの認証チケット作成レスポンスの１つに、認証チケット６００を識別する認証チケットＩＤ６１０が含まれているかどうかを判定する。

認証チケット作成レスポンスの１つに、認証チケット６００を識別する認証チケットＩＤ６１０が含まれていると判定すると（ステップＳ４５においてＹＥＳ）、ステップＳ４７に進み、認証チケット６００を識別する認証チケットＩＤ６１０が含まれていないと判定すると（ステップＳ４５においてＮＯ）、ステップＳ４６に進む。

ステップＳ４６では、Ｕｎｉｏｎマージプロバイダ１３のＸＭＬ処理部１３１は、認証チケット５００の作成が失敗した旨のレスポンスを作成し、クライアント（例えば、Ｗｅｂポータル）に送信する。

ステップＳ４７では、認証チケット管理部１３９が、サブプロバイダ１４の認証チケットＩＤ６１０を用いて図２６において説明したＵｎｉｏｎマージプロバイダ１３におけるユーザを認証する認証チケット５００を作成する。

ステップＳ４７に続いてステップＳ４８に進み、Ｕｎｉｏｎマージプロバイダ１３のＸＭＬ処理部１３１は、ステップＳ４７において作成した認証チケット５００の認証チケットＩＤ５１０を含む認証チケット作成レスポンスを作成し、クライアント（例えば、Ｗｅｂポータル）に送信する。

Ｕｎｉｏｎマージプロバイダ１３からクライアント（例えば、Ｗｅｂポータル）への認証チケット作成レスポンスの一例は、後述する図３２を用いて説明する。

図２８は、サブプロバイダにおける認証チケット作成処理の一例のフローチャートである。

サブプロバイダ１４は、図２７のステップＳ４３においてＵｎｉｏｎマージプロバイダ１３が、サブプロバイダ１４におけるユーザを認証する認証チケット６００の作成リクエストを各サブプロバイダ１４に送信すると、以下に示すステップＳ５０からの処理を開始する。

ステップＳ５０では、サブプロバイダ１４のＸＭＬ処理部１３１は、Ｕｎｉｏｎマージプロバイダ１３よりサブプロバイダ１４におけるユーザを認証する認証チケット６００の作成リクエストを受信する。

上述したように、Ｕｎｉｏｎマージプロバイダ１３からサブプロバイダ１４への認証チケット作成リクエストの一例は、後述する図３０を用いて説明する。

ステップＳ５０に続いてステップＳ５１に進み、ＩＤパスワード解析部１４３は、ステップＳ５０において受信した認証チケット６００の作成リクエストに含まれるＩＤとパスワードとが正しい組み合わせかどうかを、ディレクトリ操作ラッパー１４１を介してディレクトリ１５０に確認し、判定する。

正しい組み合わせであると判定すると（ステップＳ５１においてＹＥＳ）、ステップＳ５３に進み、正しい組み合わせではないと判定すると（ステップＳ５１においてＮＯ）、ステップＳ５２に進む。

ステップＳ５２では、サブプロバイダ１４のＸＭＬ処理部１３１は、認証チケット６００の作成が失敗した旨の認証チケット作成レスポンスを作成し、Ｕｎｉｏｎマージプロバイダ１３に送信する。

ステップＳ５３では、認証チケット管理部１４４は、ディレクトリ操作ラッパー１４１を介してディレクトリ１５０からＩＤに対応したユーザ情報を取得する。

ステップＳ５３に続いてステップＳ５４に進み、認証チケット管理部１４４は、サブプロバイダ１４におけるユーザを認証する認証チケット６００を作成する。

ステップＳ５４に続いてステップＳ５５に進み、サブプロバイダ１４のＸＭＬ処理部１３１は、ステップＳ５４において作成した認証チケット６００の認証チケットＩＤ６１０を含む認証チケット作成レスポンスを作成し、Ｕｎｉｏｎマージプロバイダ１３に送信する。

上述したように、サブプロバイダ１４からＵｎｉｏｎマージプロバイダ１３への認証チケット作成レスポンスの一例は、後述する図３１を用いて説明する。

なお、図２７のステップＳ４４は、図２８のステップＳ５２又はステップＳ５５において送信した認証チケット作成レスポンスを受信する。

図２９は、クライアントからＵｎｉｏｎマージプロバイダへの認証チケット作成リクエストの一例のＸＭＬメッセージである。

図２９に示すように、クライアント（例えば、Ｗｅｂポータル）からＵｎｉｏｎマージプロバイダ１３への認証チケット５００の作成リクエストには、＜ｄｏｍａｉｎＮａｍｅ＞＜／ｄｏｍａｉｎＮａｍｅ＞のタグにドメインネームが、＜Ｎａｍｅ＞＜／Ｎａｍｅ＞のタグにユーザの名前が、＜ｐａｓｓｗｄ＞＜／ｐａｓｓｗｄ＞のタグにパスワードが含まれている。

クライアント（例えば、Ｗｅｂポータル）は、ドメインネームとユーザ名とパスワードとを含む認証チケット５００の作成リクエストをＵｎｉｏｎマージプロバイダ１３へ送信する。

図３０は、Ｕｎｉｏｎマージプロバイダからサブプロバイダへの認証チケット作成リクエストの一例のＸＭＬメッセージである。

図３０に示すように、Ｕｎｉｏｎマージプロバイダ１３は、クライアント（例えば、Ｗｅｂポータル）から送信された認証チケット５００の作成リクエストに含まれるドメインネームとユーザ名とパスワードとをそのまま含むサブプロバイダ１４におけるユーザを認証する認証チケット６００の作成リクエストをサブプロバイダ１４へ送信する。

図３１は、サブプロバイダからＵｎｉｏｎマージプロバイダへの認証チケット作成レスポンスの一例のＸＭＬメッセージである。

図３１に示すように、サブプロバイダ１４からＵｎｉｏｎマージプロバイダ１３への認証チケット作成レスポンスには、＜ａｕｔｈＴｉｃｋｅｔ＞＜／ａｕｔｈＴｉｃｋｅｔ＞のタグに、サブプロバイダ１４において作成した認証チケット６００の認証チケットＩＤ６１０が含まれる。

サブプロバイダ１４は、認証が成功すると、サブプロバイダ１４におけるユーザを認証する認証チケット６００を作成し、該認証チケット６００の認証チケットＩＤ６１０を含む認証チケット作成レスポンスをＵｎｉｏｎマージプロバイダ１３に送信する。

図３２は、Ｕｎｉｏｎマージプロバイダからクライアントへの認証チケット作成レスポンスの一例のＸＭＬメッセージである。

図３２に示すように、Ｕｎｉｏｎマージプロバイダ１３からクライアント（例えば、Ｗｅｂポータル）への認証チケット作成レスポンスには、＜ａｕｔｈＴｉｃｋｅｔ＞＜／ａｕｔｈＴｉｃｋｅｔ＞のタグに、Ｕｎｉｏｎマージプロバイダ１３において作成した認証チケット５００の認証チケットＩＤ５１０が含まれる。

Ｕｎｉｏｎマージプロバイダ１３は、サブプロバイダ１４から図３１において説明したように、サブプロバイダ１４において作成した認証チケット６００の認証チケットＩＤ６１０を取得すると、図２６において説明したＵｎｉｏｎマージプロバイダ１３におけるユーザを認証する認証チケット５００を作成し、該認証チケット５００の認証チケットＩＤ５１０を含んだ認証チケット作成レスポンスをクライアント（例えば、Ｗｅｂポータル）に送信する。

以下、前記認証チケット作成レスポンスにおいて送信した認証チケットＩＤ５１０の確認リクエストが、クライアント（例えば、アプリケーション）から送信された場合のＵｎｉｏｎマージプロバイダ１３及びサブプロバイダ１４の処理を以下において説明する。

図３３は、Ｕｎｉｏｎマージプロバイダにおける認証チケットＩＤ確認処理の一例のフローチャートである。

ステップＳ６０では、Ｕｎｉｏｎマージプロバイダ１３のＸＭＬ処理部１３１は、クライアント（例えば、アプリケーション）より認証チケットＩＤ５１０の確認リクエストを受信する。

クライアント（例えば、アプリケーション）からＵｎｉｏｎマージプロバイダ１３への認証チケットＩＤ確認リクエストの一例は、後述する図３５を用いて説明する。

ステップＳ６０に続いてステップＳ６１に進み、認証チケット管理部１３９は、ステップＳ６０において受信した認証チケットＩＤ５１０の確認リクエストに含まれる認証チケットＩＤ５１０を取得する。

ステップＳ６１に続いてステップＳ６２に進み、認証チケット管理部１３９は、ステップＳ６１において取得した認証チケットＩＤ５１０が正しい認証チケットＩＤ５１０かどうかを判定する。

正しい認証チケットＩＤ５１０であると判定すると（ステップＳ６２においてＹＥＳ）、ステップＳ６３に進み、正しい認証チケットＩＤ５１０でないと判定すると（ステップＳ６２においてＮＯ）、ステップＳ６７に進む。

ステップＳ６３では、認証チケット管理部１３９は、Ｕｎｉｏｎマージプロバイダ１３の認証チケット５００に含まれるサブプロバイダ１４の認証チケット６００の認証チケットＩＤ６１０と、サブプロバイダ名とをサブプロバイダ呼び出し部１３４に渡す。

ステップＳ６３に続いてステップＳ６４に進み、マージプロバイダＸＭＬ処理部１３５は、サブプロバイダ呼び出し部１３４を介して取得したサブプロバイダ１４の認証チケット６００の認証チケットＩＤ６１０を用いて、認証チケットＩＤ６１０を含むサブプロバイダ１４に対する認証チケットＩＤ確認リクエストを作成し、サブプロバイダ１４に対して送信する。

Ｕｎｉｏｎマージプロバイダ１３からサブプロバイダ１４への認証チケットＩＤ確認リクエストの一例は、後述する図３６を用いて説明する。

ステップＳ６４に続いてステップＳ６５に進み、サブプロバイダ呼び出し部１３４は、マージプロバイダＸＭＬ処理部１３５を介して、前記認証チケットＩＤ確認リクエストを送信したサブプロバイダ１４から、認証チケットＩＤ６１０の確認レスポンスを受信する。

サブプロバイダ１４からＵｎｉｏｎマージプロバイダ１３への認証チケットＩＤ確認レスポンスの一例は、後述する図３７を用いて説明する。

ステップＳ６５に続いてステップＳ６６に進み、サブプロバイダ呼び出し部１３４は、ステップＳ６５において受信した認証チケットＩＤ６１０の確認レスポンスに、ユーザ情報が含まれているかどうかを判定する。

ユーザ情報が含まれていると判定すると（ステップＳ６６においてＹＥＳ）、ステップＳ６８に進み、ユーザ情報が含まれていないと判定すると（ステップＳ６６においてＮＯ）、ステップＳ６７に進む。

ステップＳ６７では、Ｕｎｉｏｎマージプロバイダ１３のＸＭＬ処理部１３１は、認証チケットＩＤ５１０の確認が失敗した旨のレスポンスを作成し、クライアント（例えば、アプリケーション）に送信する。

ステップＳ６８では、サブプロバイダ呼び出し部１３４は、ステップＳ６６において取得したユーザ情報に含まれるＵＩＤと、セッション管理部１３７において管理されている各サブプロバイダ１４のセッションチケット３００のセッションチケットＩＤ３１０と、サブプロバイダ名とを取得して、マージプロバイダＸＭＬ処理部１３５に提供する。

ステップＳ６９では、マージプロバイダＸＭＬ処理部１３５は、第一実施例において説明したように、ユーザを特定するＵＩＤと各サブプロバイダ１４のセッションチケット３００のセッションチケットＩＤ３１０と含むユーザの所属するグループの取得リクエストを作成し、各サブプロバイダ１４に送信する。

ステップＳ６９に続いてステップＳ７０に進み、サブプロバイダ呼び出し部１３４は、マージプロバイダＸＭＬ処理部１３５を介して、各サブプロバイダ１４から所属グループの取得リクエストに対する所属グループ取得レスポンスを受信する。

ステップＳ７０に続いてステップＳ７１に進み、マージ処理部１３３は、ステップＳ６６において取得したユーザ情報と、ステップＳ７０において取得した所属グループ取得レスポンスに含まれるユーザの所属するグループ情報をマージする。

ステップＳ７１に続いてステップＳ７２に進み、Ｕｎｉｏｎマージプロバイダ１３のＸＭＬ処理部１３１は、ステップＳ７１においてマージしたユーザ情報とユーザの所属するグループ情報とを含む認証チケットＩＤ確認レスポンスを作成し、クライアント（例えば、アプリケーション）に送信する。

Ｕｎｉｏｎマージプロバイダ１３からクライアントへの認証チケットＩＤ確認レスポンスの一例は、後述する図３８を用いて説明する。

図３４は、サブプロバイダにおける認証チケットＩＤ確認処理の一例のフローチャートである。

サブプロバイダ１４は、図３３のステップＳ６４においてＵｎｉｏｎマージプロバイダ１３が、認証チケットＩＤ６１０の確認リクエストをサブプロバイダ１４に送信すると、以下に示すステップＳ８０からの処理を開始する。

ステップＳ８０では、サブプロバイダ１４のＸＭＬ処理部１３１は、Ｕｎｉｏｎマージプロバイダ１３より認証チケットＩＤ６１０の確認リクエストを受信する。

上述したように、Ｕｎｉｏｎマージプロバイダ１３からサブプロバイダ１４への認証チケットＩＤ確認リクエストの一例は、後述する図３６を用いて説明する。

ステップＳ８０に続いてステップＳ８１に進み、サブプロバイダ１４のＵＩＤ変換部１３２は、ステップＳ８０において受信した認証チケットＩＤ６１０の確認リクエストに含まれるＵＩＤをディレクトリ１５０固有のＵＩＤに変換する。

ステップＳ８１に続いてステップＳ８２に進み、認証チケット管理部１４４は、ステップＳ８０において受信した認証チケットＩＤ６１０の確認リクエストに含まれる認証チケットＩＤ６１０が有効な認証チケット６００の認証チケットＩＤ６１０であるかどうかを判定する。

有効な認証チケット６００の認証チケットＩＤ６１０であると判定すると（ステップＳ８２においてＹＥＳ）、ステップＳ８４に進み、無効な認証チケット６００の認証チケットＩＤ６１０であると判定すると（ステップＳ８２においてＮＯ）、ステップＳ８３に進む。

ステップＳ８３では、サブプロバイダ１４のＸＭＬ処理部１３１は、認証チケットＩＤ６１０の確認が失敗した旨の認証チケットＩＤ確認レスポンスを作成し、Ｕｎｉｏｎマージプロバイダ１３に送信する。

ステップＳ８４では、サブプロバイダ１４は、ディレクトリ操作ラッパー１４１を介してディレクトリ１５０からユーザ情報を取得する。

ステップＳ８４に続いてステップＳ８５に進み、サブプロバイダ１４のＵＩＤ変換部１３２は、ディレクトリ１５０固有のＵＩＤをＵｎｉｏｎマージプロバイダ１３が利用可能なＵＩＤに変換する。

ステップＳ８５に続いてステップＳ８６に進み、サブプロバイダ１４のＸＭＬ処理部１３１は、ステップＳ８４において取得したユーザ情報を含む認証チケットＩＤ確認レスポンスを作成し、Ｕｎｉｏｎマージプロバイダ１３に送信する。

上述したように、サブプロバイダ１４からＵｎｉｏｎマージプロバイダ１３への認証チケットＩＤ確認レスポンスの一例は、後述する図３７を用いて説明する。

なお、図３３のステップＳ６５は、図３４のステップＳ８３又はステップＳ８６において送信した認証チケットＩＤ確認レスポンスを受信する。

図３５は、クライアントからＵｎｉｏｎマージプロバイダへの認証チケットＩＤ確認リクエストの一例のＸＭＬメッセージである。

図３５に示すように、クライアント（例えば、アプリケーション）からＵｎｉｏｎマージプロバイダ１３への認証チケットＩＤ確認リクエストには、＜ａｕｔｈＴｉｃｋｅｔ＞＜／ａｕｔｈＴｉｃｋｅｔ＞のタグに、Ｕｎｉｏｎマージプロバイダ１３におけるユーザを認証する認証チケット５００の認証チケットＩＤ５１０が含まれている。

クライアント（例えば、アプリケーション）は、Ｕｎｉｏｎマージプロバイダ１３におけるユーザを認証する認証チケット５００の認証チケットＩＤ５１０を含む認証チケットＩＤ５１０の確認リクエストをＵｎｉｏｎマージプロバイダ１３へ送信する。

図３６は、Ｕｎｉｏｎマージプロバイダからサブプロバイダへの認証チケットＩＤ確認リクエストの一例のＸＭＬメッセージである。

図３６に示すように、Ｕｎｉｏｎマージプロバイダ１３からサブプロバイダ１４への認証チケットＩＤ確認リクエストには、＜ａｕｔｈＴｉｃｋｅｔ＞＜／ａｕｔｈＴｉｃｋｅｔ＞のタグに、サブプロバイダ１４におけるユーザを認証する認証チケット６００の認証チケットＩＤ６１０が含まれている。

Ｕｎｉｏｎマージプロバイダ１３は、図２６において説明したように、認証に成功したサブプロバイダ１４の認証チケット６００を当該Ｕｎｉｏｎマージプロバイダ１３の認証チケット５００に含めて管理しているため、クライアント（例えば、アプリケーション）から送信された認証チケット確認リクエストに含まれるＵｎｉｏｎマージプロバイダ１３の認証チケット５００の認証チケットＩＤ５１０を基に、認証に成功したサブプロバイダ１４の認証チケット６００の認証チケットＩＤ６１０を取得し、該認証チケットＩＤ６１０をＸＭＬメッセージに含めることができる。

図３７は、サブプロバイダからＵｎｉｏｎマージプロバイダへの認証チケットＩＤ確認レスポンスの一例のＸＭＬメッセージである。

図３７に示すように、サブプロバイダ１４からＵｎｉｏｎマージプロバイダ１３への認証チケットＩＤ６１０の確認レスポンスには、＜ｎａｍｅ＞＜／ｎａｍｅ＞のタグにユーザの名前が含まれ、＜ｉｄ＞＜／ｉｄ＞のタグにユーザのＵＩＤが含まれ、＜ｇｒｏｕｐＬｉｓｔ＞＜／ｇｒｏｕｐＬｉｓｔ＞のタグに含まれる各＜ｉｔｅｍ＞＜／ｉｔｅｍ＞のタグに、ユーザの該サブプロバイダ１４における所属するグループ情報が含まれている。

サブプロバイダ１４は、ユーザ情報と、該ユーザが所属するグループが存在する場合は、該ユーザが所属するグループ情報とをディレクトリ１５０から取得し、Ｕｎｉｏｎマージプロバイダ１３に送信する。

図３８は、Ｕｎｉｏｎマージプロバイダからクライアントへの認証チケットＩＤ確認レスポンスの一例のＸＭＬメッセージである。

図３８に示されるように、Ｕｎｉｏｎマージプロバイダ１３は、＜ｎａｍｅ＞＜／ｎａｍｅ＞のタグにユーザの名前を、＜ｉｄ＞＜／ｉｄ＞のタグにユーザのＵＩＤを、１つの＜ｇｒｏｕｐＬｉｓｔ＞＜／ｇｒｏｕｐＬｉｓｔ＞のタグに含まれる１つ以上の＜ｉｔｅｍ＞＜／ｉｔｅｍ＞のタグに各サブプロバイダ１４から取得したグループ情報を格納し、クライアントへ送信する。

Ｕｎｉｏｎマージプロバイダ１３は、図３７において説明したように、１つのサブプロバイダ１４からＵＩＤを取得することができるので、第一の実施例において説明したように、前記ＵＩＤと、登録しているサブプロバイダ１４のセッションチケット３００のセッションＩＤ３１０とを用いて、各サブプロバイダ１４からユーザの所属するグループ情報を取得することができる。

第二の実施例において説明したように、サブプロバイダ１４が認証を必要とした場合でも、ユーザはＵｎｉｏｎマージプロバイダ１３に対してユーザ名とパスワードとを一度送信して認証を行うだけで、全てのサブプロバイダ１４からユーザの所属するグループ情報を取得することができる。

なお、第二の実施例の説明においては、Ｕｎｉｏｎマージプロバイダ１３とサブプロバイダ１４との間、及びＵｎｉｏｎマージプロバイダ１３とクライアントとの間は、認証チケットＩＤ５１０及び／又は認証チケットＩＤ６１０を送受信する場合を例にとって説明したが、これは本実施を制限するものではなく、認証チケット５００及び／又は認証チケット６００を送受信してもよい。これは以下においても、同様である。

また、第一の実施例、第二の実施例共にディレクトリ１５０は、サブプロバイダ１４とは独立させて説明を行ったが、各サブプロバイダ１４は、ディレクトリ１５０をその内部に含む構成としてもよい。

以下では説明の簡略化のため、ディレクトリ１５０は、各サブプロバイダ１４内に含まれているとして説明を行う。

以下に、Ｕｎｉｏｎマージプロバイダ１３を導入した場合の一例を、図３９を用いて説明する。

図３９は、Ｕｎｉｏｎマージプロバイダを利用してユーザの認証を行い、リポジトリサービスが蓄積している蓄積文書を取得する一例を説明するための図である。

ステップＳ１００では、Ｗｅｂブラウザ１が、ユーザによって入力されたログイン名とパスワードとをＷｅｂポータル２に送信する。

ステップＳ１００に続いてステップＳ１０１に進み、Ｗｅｂポータル２は、ステップＳ１において受信したログイン名とパスワードとを含むＵｎｉｏｎマージプロバイダ１３における認証チケット５００の作成リクエストをＵｎｉｏｎマージプロバイダ１３に送信する。

ステップＳ１０１に続いてステップＳ１０２に進み、Ｕｎｉｏｎマージプロバイダ１３は、サブプロバイダ１４であるＷｉｎＮＴ認証ディレクトリプロバイダ７とＮｏｔｅｓ（登録商標）Ｒ５認証ディレクトリプロバイダ１２とＬｏｃａｌ認証ディレクトリプロバイダ８とに前記ログイン名とパスワードとを含むサブプロバイダ１４における認証チケット６００の作成のリクエストを送信する。

サブプロバイダ１４であるＷｉｎＮＴ認証ディレクトリプロバイダ７とＮｏｔｅｓ（登録商標）Ｒ５認証ディレクトリプロバイダ１２とＬｏｃａｌ認証ディレクトリプロバイダ８とは、前記ログイン名とパスワードとを用いて認証を行い、認証が成功した場合は、認証チケット６００の作成を行う。

ステップＳ１０２に続いてステップＳ１０３に進み、サブプロバイダ１４であるＷｉｎＮＴ認証ディレクトリプロバイダ７とＮｏｔｅｓ（登録商標）Ｒ５認証ディレクトリプロバイダ１２とＬｏｃａｌ認証ディレクトリプロバイダ８とは、認証チケット作成リクエストに対する認証チケット作成レスポンスを作成し、Ｕｎｉｏｎマージプロバイダ１３に送信する。

例えば、ユーザがＷｉｎＮＴのログイン名とパスワードとをＷｅｂブラウザ１に入力した場合は、ＷｉｎＮＴ認証ディレクトリプロバイダ７で認証が成功し、認証チケット６００が作成される。

この場合、ＷｉｎＮＴ認証ディレクトリプロバイダ７からＵｎｉｏｎマージプロバイダ１３に送信された認証チケット作成レスポンスには、作成された認証チケット６００の認証チケットＩＤ６１０が含まれ、他のサブプロバイダ１４からＵｎｉｏｎマージプロバイダ１３に送信された認証チケット作成レスポンスには、認証チケット６００の作成が失敗した旨の情報が含まれる。

ステップＳ１０３に続いてステップＳ１０４に進み、Ｕｎｉｏｎマージプロバイダ１３は、サブプロバイダ１４の１つから認証チケットＩＤ６１０が含まれた認証チケット作成レスポンスを取得すると、Ｕｎｉｏｎマージプロバイダ１３におけるユーザを認証する認証チケット５００を作成し、該作成した認証チケット５００の認証チケットＩＤ５１０を含んだ認証チケット作成レスポンスをＷｅｂポータル２に送信する。

ステップＳ１０４に続いてステップＳ１０５に進み、Ｗｅｂポータル２は、認証が成功した旨をＷｅｂブラウザ１に送信する。

ステップＳ１０５に続いてステップＳ１０６に進み、Ｗｅｂブラウザ１は、リポジトリサービス１７０が提供するサービスを利用する旨の利用開始リクエストをＷｅｂポータル２に送信する。

ステップＳ１０６に続いてステップＳ１０７に進み、Ｗｅｂポータル２は、ステップＳ１０４において取得したＵｎｉｏｎマージプロバイダ１３におけるユーザを認証する認証チケット５００の認証チケットＩＤ５１０を含むサービスの利用を許可するセッションチケット７００の作成リクエストを、リポジトリサービス１７０に送信する。

ステップＳ１０７に続いてステップＳ１０８に進み、リポジトリサービス１７０は、ステップＳ１０７において受信したセッションチケット７００の作成リクエストが、有効なユーザからのリクエストかどうかを確認するために、前記セッションチケット７００の作成リクエストに含まれる認証チケットＩＤ５１０を含む認証チケットＩＤ確認リクエストをＵｎｉｏｎマージプロバイダ１３に送信する。

ステップＳ１０８に続いてステップＳ１０９に進み、Ｕｎｉｏｎマージプロバイダ１３は、ステップＳ１０３においてサブプロバイダ１４の内の１つから取得した認証チケットＩＤ６１０の確認リクエストをサブプロバイダ１４に送信する。

なお、Ｕｎｉｏｎマージプロバイダ１３は、ステップＳ１０３において、どのサブプロバイダ１４において認証が成功したかの情報を保持しているため、該認証が成功したサブプロバイダ１４に対してのみ、認証チケットＩＤ６１０の確認リクエストを送信するようにしてもよい。

ステップＳ１０９に続いてステップＳ１１０に進み、サブプロバイダ１４であるＷｉｎＮＴ認証ディレクトリプロバイダ７とＮｏｔｅｓ（登録商標）Ｒ５認証ディレクトリプロバイダ１２とＬｏｃａｌ認証ディレクトリプロバイダ８とは、認証チケットＩＤ６１０の確認リクエストに対する認証チケットＩＤ６１０の確認レスポンスをＵｎｉｏｎマージプロバイダ１３に送信する。

例えば、前記認証が成功したサブプロバイダ１４がＷｉｎＮＴ認証ディレクトリプロバイダ７であった場合は、ＷｉｎＮＴ認証ディレクトリプロバイダ７は、認証チケットＩＤ６１０に対応するユーザのＵＩＤを含む認証チケットＩＤ６１０の確認レスポンスをＵｎｉｏｎマージプロバイダ１３に送信する。

ステップＳ１１０に続いてステップＳ１１１に進み、Ｕｎｉｏｎマージプロバイダ１３は、ステップＳ１１０において取得したＵＩＤと、各サブプロバイダ１４のセッションチケット３００のセッションチケットＩＤ３１０とを含んだ、ＵＩＤに対応するユーザの所属するグループ情報の取得リクエストを各サブプロバイダ１４に送信する。

ステップＳ１１１に続いてステップＳ１１２に進み、各サブプロバイダ１４は、取得したＵＩＤに対応するユーザの所属するグループ情報を含む取得レスポンスを作成し、Ｕｎｉｏｎマージプロバイダ１３に送信する。

ステップＳ１１２に続いてステップＳ１１３に進み、Ｕｎｉｏｎマージプロバイダ１３は、ステップＳ１１０において取得したユーザ情報及びステップＳ１１２において取得したユーザの所属するグループ情報をマージして、該マージした情報を含む認証チケットＩＤ確認レスポンスを作成し、リポジトリサービス１７０に送信する。

ステップＳ１１３に続いてステップＳ１１４に進み、例えば、リポジトリサービス１７０は、ステップＳ１１３において取得したグループの中に当該リポジトリサービス１７０が提供するサービスの利用を許可しているグループが存在した場合は、サービスの利用を許可するセッションチケット７００を作成し、該セッションチケット７００のセッションチケットＩＤ７１０を含むセッションチケットの作成レスポンスをＷｅｂポータル２に送信する。

ステップＳ１１４に続いてステップＳ１１５に進み、Ｗｅｂポータル２は、Ｗｅｂブラウザ１に対してサービスの利用開始が許可された旨のレスポンスを送信する。

ステップＳ１１５に続いてステップＳ１１６に進み、Ｗｅｂブラウザ１は、リポジトリサービス１７０が蓄積している蓄積文書を取得する旨のリクエストをＷｅｂポータル２に送信する。

ステップＳ１１６に続いてステップＳ１１７に進み、Ｗｅｂポータル２は、ステップＳ１１４において取得したセッションチケット７００のセッションチケットＩＤ７１０を含む蓄積文書の取得リクエストをリポジトリサービス１７０に送信する。

ステップＳ１１７に続いてステップＳ１１８に進み、リポジトリサービス１７０は、ステップＳ１１７において取得した蓄積文書の取得リクエストに含まれるセッションチケットＩＤ７１０が有効なセッションチケット７００のセッションチケットＩＤ７１０かどうかを判定し、有効なセッションチケットＩＤ７１０であると判定した場合には、指定された蓄積文書を含む蓄積文書の取得レスポンスをＷｅｂポータル２に送信する。

ステップＳ１１８に続いてステップＳ１１９に進み、Ｗｅｂポータル２は、ステップＳ１１８において取得した蓄積文書をＷｅｂブラウザ１に送信する。

上述したように、Ｕｎｉｏｎマージプロバイダ１３を導入することによって、例えばリポジトリサービス１７０に蓄積されている文書を取得する権限がＬｏｃａｌ認証ディレクトリプロバイダ８に登録されているグループにしか与えられていない場合であっても、Ｕｎｉｏｎマージプロバイダ１３は、ユーザの所属する他のサブプロバイダ１４のグループの情報もマージして管理するため、ＷｉｎＮＴ認証ディレクトリプロバイダ７で認証したユーザであっても、同一のユーザがＬｏｃａｌ認証ディレクトリプロバイダ８の前記グループに属していた場合は、リポジトリサービス１７０に蓄積されている文書を取得することができる。

図４０は、Ｕｎｉｏｎマージプロバイダが複数存在する場合の統合の一例を説明するための図である。

図１７を用いて説明したように、Ｕｎｉｏｎマージプロバイダ１３は、セッションチケット２００を階層的な構造で有しているため、図４０に示すように、Ｕｎｉｏｎマージプロバイダ１３を有する既存のシステムが複数存在している場合も、これらのシステムを統合するＵｎｉｏｎマージプロバイダ１３（図４０のＵｎｉｏｎマージプロバイダ０）を導入し、新たなグループに統合することができる。

以下、Ｕｎｉｏｎマージプロバイダ１３と、サブプロバイダ１４と、の構成に係る情報（構成情報）を、Ｕｎｉｏｎマージプロバイダ１３の外に出して、後述するコンフィグレーションマネージャ２２で保持、管理するようにした例を、以下の実施例において説明する。

図４１は、ＵＣＳの構成を説明するための図（その４）である。なお、図４１では、説明の簡略化のため、図１３において説明したように、ＵＣＳ４９内に、Ｕｎｉｏｎマージプロバイダ１３も、サブプロバイダ１４の全ても含まれているものとして説明を行う。但し、上述したように、例えばサブプロバイダ１４の一部又は全ては、他の融合機１２０に含まれていてもよい。

図４１に示されるＵＣＳ４９は、ディスパッチャー２１と、コンフィグレーションマネージャ２２と、Ｕｎｉｏｎマージプロバイダ１３と、サブプロバイダ１４_１から１４_ｎと、を含む。

ディスパッチャー２１は、クライアントからの要求を受け取って、コンフィグレーションマネージャ２２やＵｎｉｏｎマージプロバイダ１３等に要求を振り分けたり、振り分けた要求に応じてコンフィグレーションマネージャ２２又はＵｎｉｏｎマージプロバイダ１３等が処理した処理結果をクライアントに送信したりする。

コンフィグレーションマネージャ２２は、Ｕｎｉｏｎマージプロバイダ１３と、サブプロバイダ１４_１〜１４_ｎと、の構成を管理する管理部であり、構成情報等を格納部に保持する。

なお、Ｕｎｉｏｎマージプロバイダ１３及びサブプロバイダ１４は上述した実施例１又は実施例２において説明したのと同様である。

以下、プロバイダ一覧取得シーケンスの一例を、図４２を用いて説明する。図４２は、プロバイダ一覧取得シーケンスの一例を説明するための図である。

図４２に示されるように、クライアントは、例えばＵｎｉｏｎマージプロバイダ１３のサブプロバイダ１４として新たなプロバイダを追加する場合、該新たに追加するプロバイダを選択するため、ディスパッチャー２１に対して、ディスパッチャー２１のｇｅｔＰｒｏｖｉｄｅｒＬｉｓｔメソッドを含むプロバイダ一覧取得リクエストを送信する（シーケンスＳＱ１）。なお、プロバイダ一覧取得リクエストの一例は、後述する図４３を用いて示す。

プロバイダ一覧取得リクエストを受信したディスパッチャー２１は、コンフィグレーションマネージャ２２のｅｎｕｍｅｒａｔｅＰｒｏｖｉｄｅｒＮａｍｅメソッドを呼び出す（シーケンスＳＱ２）。

ｅｎｕｍｅｒａｔｅＰｒｏｖｉｄｅｒＮａｍｅメソッドを呼び出されたコンフィグレーションマネージャ２２は、格納部よりプロバイダ名等を取得し、プロバイダ一覧としてディスパッチャー２１に返す。

ディスパッチャー２１は、プロバイダ一覧を含むプロバイダ一覧取得レスポンスを作成し、要求元のクライアントに送信する。なお、プロバイダ一覧取得レスポンスの一例は、後述する図４４を用いて示す。

図４２に示すような処理を行うことによって、例えばクライアントはプロバイダの一覧を表示し、ユーザはプロバイダの一覧の中からＵｎｉｏｎマージプロバイダ１３のサブプロバイダ１４として新たに追加するプロバイダを選択することができる。

以下、プロバイダ一覧取得リクエストの一例を、図４３を用いて示す。図４３は、クライアントからディスパッチャーへのプロバイダ一覧取得リクエストの一例のＸＭＬメッセージである。

図４３に示されるように、プロバイダ一覧取得リクエストには、ｇｅｔＰｒｏｖｉｄｅｒＬｉｓｔメソッドが含まれている。

以下、プロバイダ一覧取得レスポンスの一例を、後述する図４４を用いて示す。図４４は、ディスパッチャーからクライアントへのプロバイダ一覧取得レスポンスの一例のＸＭＬメッセージである。

図４４に示されるように、＜ｉｔｅｍ＞＜／ｉｔｅｍ＞のタグには、プロバイダの名前（又はプロバイダを識別する識別子）が格納されている。

以下、サブプロバイダ追加シーケンスの一例を、図４５を用いて説明する。図４５は、サブプロバイダ追加シーケンスの一例を説明するための図である。

図４５に示されるように、クライアントは、例えば後述するＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）等を用いて、ユーザが、プロバイダ一覧から追加するプロバイダを選択すると、ディスパッチャー２１に対して、ディスパッチャー２１のｃｒｅａｔｅＰｒｏｖｉｄｅｒメソッドを含むサブプロバイダ追加リクエストを送信する（シーケンスＳＱ１０）。なお、サブプロバイダ追加リクエストの一例は、後述する図４６を用いて示す。図４５では、省略してあるが、サブプロバイダ追加リクエストには、例えば、どのＵｎｉｏｎマージプロバイダ１３に、どのサブプロバイダ１４を追加するか等の情報が含まれる。

サブプロバイダ追加リクエストを受信したディスパッチャー２１は、コンフィグレーションマネージャ２２のｃｒｅａｔｅＰｒｏｖｉｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎメソッドを呼び出す（シーケンスＳＱ１１）。

ｃｒｅａｔｅＰｒｏｖｉｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎメソッドを呼び出されたコンフィグレーションマネージャ２２は、構成情報を格納するための新たな領域を格納部において確保し、該領域に係る格納領域情報（例えば、新たに確保した領域の先頭アドレス等）をディスパッチャー２１に返す。

格納領域情報を取得したディスパッチャー２１は、該格納領域情報を引数として、追加するサブプロバイダ１４のｃｒｅａｔｅＰｒｏｖｉｄｅｒメソッドを呼び出す（シーケンスＳＱ１２）。

ｃｒｅａｔｅＰｒｏｖｉｄｅｒメソッドを呼び出されたサブプロバイダ１４は、ｃｒｅａｔｅＰｒｏｖｉｄｅｒメソッドの引数として渡された格納領域情報と、例えば当該サブプロバイダ１４の識別子及びサブプロバイダ１４の名前等のデフォルトの構成情報と、を引数として、コンフィグレーションマネージャ２２のｓｅｔＡｔｔｒｉｂｕｔｅメソッドを呼び出す（シーケンスＳＱ１３）。

ｓｅｔＡｔｔｒｉｂｕｔｅメソッドを呼び出されたコンフィグレーションマネージャ２２は、ｓｅｔＡｔｔｒｉｂｕｔｅメソッドの引数として渡されたサブプロバイダ１４のデフォルトの構成情報を含む構成情報を、ｓｅｔＡｔｔｒｉｂｕｔｅメソッドの引数として渡された格納領域情報に基づいて、対応する格納領域に、格納する。

コンフィグレーションマネージャ２２より構成情報を格納した旨の情報を受け取ったディスパッチャー２１は、プロバイダの追加が正常に終了した旨の情報を含むサブプロバイダ追加レスポンスを作成し、要求元のクライアントに送信する。なお、サブプロバイダ追加レスポンスの一例は、後述する図４７を用いて示す。

図４５に示されるような処理を行うことによって、プロバイダをＵｎｉｏｎマージプロバイダ１３のサブプロバイダ１４として新たに追加することができる。

以下、サブプロバイダ追加リクエストの一例を、図４６を用いて説明する。図４６は、クライアントからディスパッチャーへのサブプロバイダ追加リクエストの一例のＸＭＬメッセージである。

図４６に示されるように、サブプロバイダ追加リクエストには、ｃｒｅａｔｅＰｒｏｖｉｄｅｒメソッドが含まれている。また、ｃｒｅａｔｅＰｒｏｖｉｄｅｒメソッドの引数として、＜ｕｎｉｏｎＭｅｒｇｅｐｒｏｖｉｄｅｒＮａｍｅ＞＜／ｕｎｉｏｎＭｅｒｇｅｐｒｏｖｉｄｅｒＮａｍｅ＞のタグには、Ｕｎｉｏｎマージプロバイダの識別子又は名前が含まれている。また、＜ｉｔｅｍ＞＜／ｉｔｅｍ＞のタグの、＜ｓｕｂｐｒｏｖｉｄｅｒＮａｍｅ＞＜／ｓｕｂｐｒｏｖｉｄｅｒＮａｍｅ＞には、新たに追加するサブプロバイダの識別子又は名前が含まれている。

以下、サブプロバイダ追加レスポンスの一例を、図４７を用いて説明する。図４７は、ディスパッチャーからクライアントへのサブプロバイダ追加レスポンスの一例のＸＭＬメッセージである。

図４７に示されるように、サブプロバイダ追加レスポンスの＜ｒｅｔｕｒｎＶａｌｕｅ＞＜／ｒｅｔｕｒｎＶａｌｕｅ＞のタグには、サブプロバイダの追加が成功したかどうかを表す情報（図４７の例においてはＯＫ）が含まれている。

以下、クライアントの一例のハードウェア構成を、図４８を用いて説明する。図４８は、クライアントの一例のハードウェア構成図である。

図４８に示されるクライアントのハードウェア構成は、それぞれバスで相互に接続されている入力装置５１と、表示装置５２と、ドライブ装置５３と、記録媒体５４と、ＲＯＭ５５と、ＲＡＭ５６と、ＣＰＵ５７と、インターフェース装置５８と、ＨＤＤ５９と、から構成されている。

入力装置５１は、クライアントの利用者が操作するキーボード及びマウス等で構成され、クライアントに各種操作信号を入力するのに用いられる。表示装置５２は、クライアントの利用者が利用するディスプレイ等で構成され、各種情報を表示する。インターフェース装置５８は、クライアントをネットワーク５等に接続するインターフェースである。

クライアントにおける各処理を実行するアプリケーションプログラム等は、例えば、ＣＤ−ＲＯＭ等の記録媒体５４によってクライアントに提供されるか、ネットワーク５を通じてダウンロードされる。記録媒体５４は、ドライブ装置５３にセットされ、アプリケーションプログラムが記録媒体５４からドライブ装置５３を介してＨＤＤ５９にインストールされる。

ＲＯＭ５５は、データ等を格納する。ＲＡＭ５６は、クライアントの起動時にＨＤＤ５９からアプリケーションプログラム等を読み出して格納する。ＣＰＵ５７は、ＲＡＭ５６に読み出され格納されたアプリケーションプログラム等に従って処理を実行する。また、ＨＤＤ５９は、データやファイル等を格納する。

なお、上述した実施例においては、Ｕｎｉｏｎマージプロバイダ１３及び／又はサブプロバイダ１４が実装される装置の例として融合機１２０を用いて説明を行ったが、図４８に示したようなＰＣ（パーソナルコンピュータ）に実装するようにしてもよい。

以下、クライアントの機能の一例を、図４９を用いて説明する。図４９は、クライアントの機能ブロック図である。

図４９に示されるように、クライアントは、ＧＵＩ表示部７１と、制御部７２と、サーバ呼び出し部７３と、ＸＭＬ生成解析部７４と、を含む。

ＧＵＩ表示部７１は、後述するＧＵＩを作成し、クライアントのディスプレイ等に表示する表示部である。制御部７２は、クライアント全体の処理を制御する制御部である。サーバ呼び出し部７３は、Ｕｎｉｏｎマージプロバイダ１３等を含むサーバを呼び出す呼び出し部である。ＸＭＬ生成解析部７４は、ＸＭＬを生成し、サーバに送信すると共に、サーバ等から受信したＸＭＬメッセージを解析し、該ＸＭＬメッセージに含まれるデータ等を取得する。

以下、クライアントにおけるプロバイダの設定に係るＧＵＩの一例を、図５０に示す。図５０は、クライアントにおけるプロバイダの設定に係るＧＵＩを示す図（その１）である。

クライアントは、例えば図４４に示されるようなプロバイダ一覧取得レスポンスを受信すると、該プロバイダ一覧取得レスポンスに含まれるプロバイダの一覧に基づいて、図５０（Ａ）に示されるように、プロバイダの一覧をドロップダウンメニューの中に含むユーザ認証プロバイダ設定画面を作成し、表示する。

なお、図５０（Ａ）に示されるユーザ認証プロバイダ設定画面のドロップダウンメニューの下に表示されているグループボックス内は、ユーザが、ドロップダウンメニューの中から選択したプロバイダによって変化する。

例えば、ユーザが、図５０（Ａ）において「認証サービス参照」を選択して「参照」ボタンをクリックすると、クライアントは、図５０（Ｂ）に示されるような外部認証の参照画面を表示する。なお、外部認証とは、実際の認証を行う認証エンジン（図２５の例では、例えばＩＤパスワード解析部１４３及び認証チケット管理部１４４等）を外部のサーバ等で行わせる認証である。

ユーザが図５０（Ｂ）において「参照」ボタンをクリックすると、クライアントは、図５０（Ｃ）に示されるようなユーザ認証サービス管理参照画面を表示する。

以下、クライアントにおけるプロバイダの設定に係るＧＵＩの他の例を、図５１に示す。図５１は、クライアントにおけるプロバイダの設定に係るＧＵＩを示す図（その２）である。

図５１には、ユーザが、ドロップダウンメニューの中からWindows（登録商標）ＮＴ認証を選んだ場合の、一例の画面が示されている。なお、図５１の「ドメインコントローラの設定」ボタンは、ユーザが「自認証設定」を選択した場合のみ有効となる。

以下、クライアントにおけるプロバイダの設定に係るＧＵＩの他の例を、図５２に示す。図５２は、クライアントにおけるプロバイダの設定に係るＧＵＩを示す図（その３）である。

図５２には、ユーザが、ドロップダウンメニューの中からＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙ（登録商標）認証を選んだ場合の、一例の画面が示されている。なお、図５２の「ドメインコントローラの設定」ボタンは、ユーザが「自認証設定」を選択した場合のみ有効となる。

以下、クライアントにおけるプロバイダの設定に係るＧＵＩの他の例を、図５３に示す。図５３は、クライアントにおけるプロバイダの設定に係るＧＵＩを示す図（その４）である。

図５３には、ユーザが、ドロップダウンメニューの中からＮｏｔｅｓ（登録商標）認証を選んだ場合の、一例の画面が表示されている。

以下、リモートプロバイダの一例を、図５４を用いて説明する。図５４は、リモートプロバイダの一例を説明するための図である。

Ｕｎｉｏｎマージプロバイダ１３及び／又はサブプロバイダ１４は、例えば定義ファイル等にｉｓ＿ｅｘｐｏｒｔｅｄ属性が真に設定されていると、後述するようなリモートプロバイダとして処理を行うようにしてもよい。ここで、リモートプロバイダとは、例えば、プロバイダが、認証プロバイダであった場合、上述したように、認証エンジンを自身では持たず、他のプロバイダ等に含まれる認証エンジンを利用して、クライアント等からの要求に応じて処理を行うプロバイダのことである。なお、定義ファイルは、例えばコンフィグレーションマネージャ２２等に含まれる。

例えば、サブプロバイダ１４_１は、クライアント又はＵｎｉｏｎマージプロバイダ１３等よりサービス（例えば、認証サービス等）の利用要求を受け取ると（シーケンスＳＱ２０）、例えば定義ファイル等を参照し、ｉｓ＿ｅｘｐｏｒｔｅｄ属性が真かどうかを判定する。

サブプロバイダ１４_１は、ｉｓ＿ｅｘｐｏｒｔｅｄ属性が真であると判定すると、当該自身はリモートプロバイダであるとして、レジストリ等に格納されている接続先情報を取得し、該接続先に対してサービスの利用要求を転送する（シーケンスＳＱ２１）。

サービスの利用要求を受け取ったサブプロバイダ１４_ｎは、例えば定義ファイル等を参照し、ｉｓ＿ｓｈａｒｅｄ属性が真かどうかを判定する。

サブプロバイダ１４_ｎは、ｉｓ＿ｓｈａｒｅｄ属性が真であると判定すると、サービスの利用要求に応じて、処理を行って実行結果をリモートプロバイダ（サブプロバイダ１４_１）に返す。

リモートプロバイダ（サブプロバイダ１４_１）は、サブプロバイダ１４_ｎより実行結果を受け取ると、該実行結果に必要な後処理を加え、該後処理を加えた実行結果を要求元のクライアント又はＵｎｉｏｎマージプロバイダ１３等に返す。

以下、リモートプロバイダに係る処理の一例を、図５５を用いて説明する。図５５は、リモートプロバイダに係る処理の一例を説明するための図である。

ステップＳ２００において、例えばサブプロバイダ１４_１は、クライアント又はＵｎｉｏｎマージプロバイダ１３等よりサービスの利用要求を受け取る。

ステップＳ２００に続いてステップＳ２０１に進み、サブプロバイダ１４_１は、定義ファイル等を参照し、ｉｓ＿ｅｘｐｏｒｔｅｄ属性が真かどうかを判定する。サブプロバイダ１４_１は、ｉｓ＿ｅｘｐｏｒｔｅｄ属性が真であると判定すると、ステップＳ２０２に進み、ｉｓ＿ｅｘｐｏｒｔｅｄ属性が偽であると判定すると、例えばｉｓ＿ｓｈａｒｅｄ属性が真であるかどうか判定する。なお、説明の簡略化のため、ｉｓ＿ｅｘｐｏｒｔｅｄ属性が偽であると判定した場合の処理は図５５では省略してある。

ステップＳ２０２では、サブプロバイダ１４_１は、リモートプロバイダであるとして、レジストリ等に格納されている接続先情報を取得する。

ステップＳ２０２に続いてステップＳ２０３に進み、サブプロバイダ１４_１は、ステップＳ２００において受け取ったサービスの利用要求をステップＳ２０２において取得した接続先に転送する。

ステップＳ２０３に続いてステップＳ２０４に進み、接続先のサブプロバイダ１４_ｎは、リモートプロバイダより、サービスの利用要求の転送を受け取る。

ステップＳ２０４に続いてステップＳ２０５に進み、接続先のサブプロバイダ１４_ｎは、定義ファイル等を参照し、ｉｓ＿ｓｈａｒｅｄ属性が真かどうかを判定する。接続先のサブプロバイダ１４_ｎは、ｉｓ＿ｓｈａｒｅｄ属性が真であると判定すると、ステップＳ２０６に進み、ｉｓ＿ｓｈａｒｅｄ属性が偽であると判定すると、ＮＧをリモートプロバイダに返す。

ステップＳ２０６では、接続先のサブプロバイダ１４_ｎが、コンフィグレーションマネージャ２２より、要求元のリモートプロバイダの信頼関係を読み出す。

ステップＳ２０６に続いてステップＳ２０７に進み、接続先のサブプロバイダ１４_ｎは、当該サブプロバイダ１４_ｎと、要求元のリモートプロバイダと、に信頼関係が有るかどうかを判定する。接続先のサブプロバイダ１４_ｎは、当該サブプロバイダ１４_ｎと、要求元のリモートプロバイダと、に信頼関係が有ると判定すると、ステップＳ２０８に進み、当該サブプロバイダ１４_ｎと、要求元のリモートプロバイダと、に信頼関係は無いと判定すると、ＮＧをリモートプロバイダに返す。

ステップＳ２０８では、接続先のサブプロバイダ１４_ｎが、要求に応じて処理を実行する。

ステップＳ２０８に続いてステップＳ２０９に進み、接続先のサブプロバイダ１４_ｎは、実行結果を要求元のリモートプロバイダに返す。

ステップＳ２０９に続いてステップＳ２１０に進み、リモートプロバイダは、接続先のサブプロバイダ１４_ｎより実行結果を受け取る。

ステップＳ２１０に続いてステップＳ２１１に進み、リモートプロバイダは、ステップＳ２１０において受け取った実行結果に、必要な後処理を加える。

ステップＳ２１１に続いてステップＳ２１２に進み、リモートプロバイダは、ステップＳ２１１において必要な後処理を加えた実行結果を、要求元のクライアント又はＵｎｉｏｎマージプロバイダ１３に返す。

なお、実施例３においては、サブプロバイダ１４の追加を例にとって説明を行ったが、サブプロバイダ１４が１つも登録されていない場合の、サブプロバイダ１４の登録等も同様である。

以上、本発明の好ましい実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

認証プロバイダを利用してユーザの認証を行い、アプリケーションが提供するサービスを利用する一例を説明するための図である。 １つのＷｅｂポータルが、複数のアプリケーションと複数の認証ディレクトリプロバイダとをサポートする一例を説明するための図である。 Ｗｅｂポータルにおけるアクセスモジュールを１つに統合した一例を説明するための図である。 図３の構成に新たなアプリケーションを追加した一例を説明するための図である。 Ｌｏｃａｌ認証ディレクトリプロバイダを導入した一例を説明するための図である。 図５に示したＬｏｃａｌ認証ディレクトリプロバイダ１２に登録されているグループのメンバーの一例を説明するための図である。 従来のプロバイダの問題点を説明するための図である。 本発明によるＵｎｉｏｎマージプロバイダを導入した一例を説明するための図である。 図８に示したＬｏｃａｌ認証ディレクトリプロバイダのグループのメンバーの一例を説明するための図である。 図８に示したＬｏｃａｌ認証ディレクトリプロバイダのユーザＩＤの構造を説明するための図である。 本発明による融合機の一実施例の構成図である。 本発明による融合機の一実施例のハードウェア構成図である。 ＵＣＳの構成を説明するための図（その１）である。 ＵＣＳの構成を説明するための図（その２）である。 ＵＣＳの構成を説明するための図（その３）である。 本発明の第一実施例におけるＵｎｉｏｎマージプロバイダとサブプロバイダとの機能ブロック図である。 Ｕｎｉｏｎマージプロバイダのセッションチケットの構造を説明するための概念図である。 ディレクトリ操作ラッパーのデータの変形の一例を説明するための図である。 Ｕｎｉｏｎマージプロバイダにおけるユーザの所属グループ取得処理の一例のフローチャートである。 サブプロバイダにおけるユーザの所属グループ取得処理の一例のフローチャートである。 クライアントからＵｎｉｏｎマージプロバイダへのグループ取得リクエストの一例のＸＭＬメッセージである。 Ｕｎｉｏｎマージプロバイダからサブプロバイダへのグループ取得リクエストの一例のＸＭＬメッセージである。 サブプロバイダからＵｎｉｏｎマージプロバイダへのグループ取得レスポンスの一例のＸＭＬメッセージである。 Ｕｎｉｏｎマージプロバイダからクライアントへのグループ取得レスポンスの一例のＸＭＬメッセージである。 本発明の第二実施例におけるＵｎｉｏｎマージプロバイダとサブプロバイダとの機能ブロック図である。 Ｕｎｉｏｎマージプロバイダの認証チケットの構造を説明するための概念図である。 Ｕｎｉｏｎマージプロバイダにおける認証チケット作成処理の一例のフローチャートである。 サブプロバイダにおける認証チケット作成処理の一例のフローチャートである。 クライアントからＵｎｉｏｎマージプロバイダへの認証チケット作成リクエストの一例のＸＭＬメッセージである。 Ｕｎｉｏｎマージプロバイダからサブプロバイダへの認証チケット作成リクエストの一例のＸＭＬメッセージである。 サブプロバイダからＵｎｉｏｎマージプロバイダへの認証チケット作成レスポンスの一例のＸＭＬメッセージである。 Ｕｎｉｏｎマージプロバイダからクライアントへの認証チケット作成レスポンスの一例のＸＭＬメッセージである。 Ｕｎｉｏｎマージプロバイダにおける認証チケットＩＤ確認処理の一例のフローチャートである。 サブプロバイダにおける認証チケットＩＤ確認処理の一例のフローチャートである。 クライアントからＵｎｉｏｎマージプロバイダへの認証チケットＩＤ確認リクエストの一例のＸＭＬメッセージである。 Ｕｎｉｏｎマージプロバイダからサブプロバイダへの認証チケットＩＤ確認リクエストの一例のＸＭＬメッセージである。 サブプロバイダからＵｎｉｏｎマージプロバイダへの認証チケットＩＤ確認レスポンスの一例のＸＭＬメッセージである。 Ｕｎｉｏｎマージプロバイダからクライアントへの認証チケットＩＤ確認レスポンスの一例のＸＭＬメッセージである。 Ｕｎｉｏｎマージプロバイダを利用してユーザの認証を行い、リポジトリサービスが蓄積している蓄積文書を取得する一例を説明するための図である。 Ｕｎｉｏｎマージプロバイダが複数存在する場合の統合の一例を説明するための図である。 ＵＣＳの構成を説明するための図（その４）である。 プロバイダ一覧取得シーケンスの一例を説明するための図である。 クライアントからディスパッチャーへのプロバイダ一覧取得リクエストの一例のＸＭＬメッセージである。 ディスパッチャーからクライアントへのプロバイダ一覧取得レスポンスの一例のＸＭＬメッセージである。 サブプロバイダ追加シーケンスの一例を説明するための図である。 クライアントからディスパッチャーへのサブプロバイダ追加リクエストの一例のＸＭＬメッセージである。 ディスパッチャーからクライアントへのサブプロバイダ追加レスポンスの一例のＸＭＬメッセージである。 クライアントの一例のハードウェア構成図である。 クライアントの機能ブロック図である。 クライアントにおけるプロバイダの設定に係るＧＵＩを示す図（その１）である。 クライアントにおけるプロバイダの設定に係るＧＵＩを示す図（その２）である。 クライアントにおけるプロバイダの設定に係るＧＵＩを示す図（その３）である。 クライアントにおけるプロバイダの設定に係るＧＵＩを示す図（その４）である。 リモートプロバイダの一例を説明するための図である。 リモートプロバイダに係る処理の一例を説明するための図である。

符号の説明

１ Ｗｅｂブラウザ
２ Ｗｅｂポータル
３ アプリケーション
４ 認証ディレクトリプロバイダ
５ Windows（登録商標）アプリケーション
６ Ｎｏｔｅｓ（登録商標）アプリケーション
７ Windows（登録商標）認証ディレクトリプロバイダ
８ Ｎｏｔｅｓ（登録商標）認証ディレクトリプロバイダ
９ プロバイダ
１０ アクセスモジュール
１１ アプリケーション
１２ Ｌｏｃａｌ認証ディレクトリプロバイダ
１３ Ｕｎｉｏｎマージプロバイダ
１４ サブプロバイダ
１５ 白黒ラインプリンタ
１６ カラーラインプリンタ
１７ ハードウェアリソース
２０ ソフトウェア群
３０ アプリケーション
３１ プリンタアプリ
３２ コピーアプリ
３３ ファックスアプリ
３４ スキャナアプリ
３５ ネットファイルアプリ
３６ 工程検査アプリ
４０ プラットフォーム
４１ オペレーティングシステム（ＯＳ）
４２ システムコントロールサービス（ＳＣＳ）
４３ システムリソースマネージャ（ＳＲＭ）
４４ エンジンコントロールサービス（ＥＣＳ）
４５ メモリコントロールサービス（ＭＣＳ）
４６ オペレーションパネルコントロールサービス（ＯＣＳ）
４７ ファックスコントロールサービス（ＦＣＳ）
４８ ネットワークコントロールサービス（ＮＣＳ）
４９ ユーザ情報管理サービス（ＵＣＳ）
５０ 融合機起動部
５１ 入力装置
５２ 表示装置
５３ ドライブ装置
５４ 記録媒体
５５ ＲＯＭ
５６ ＲＡＭ
５７ ＣＰＵ
５８ インターフェース装置
５９ ＨＤＤ
６０ コントローラボード
６１ ＣＰＵ
６２ ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）
６３ ＳＲＡＭ（Ｓｔａｔｉｃ ＲＡＭ）
６４ ＳＤＲＡＭ（Ｓｙｎｃｈｒｏｎｏｕｓ ＤＲＡＭ）
６５ フラッシュメモリ
６６ ハードディスク装置（ＨＤＤ）
７０ オペレーションパネル
７１ ＧＵＩ表示部
７２ 制御部
７３ サーバ呼び出し部
７４ ＸＭＬ生成解析部
８０ ファックスコントロールユニット（ＦＣＵ）
９０ ＵＳＢデバイス
１００ ＩＥＥＥ１３９４デバイス
１１０ エンジン部
１２０ 融合機
１３０ プロバイダＩ／Ｆ
１３１ ＸＭＬ処理部
１３２ ＵＩＤ変換部
１３３ マージ処理部
１３４ サブプロバイダ呼び出し部
１３５ マージプロバイダＸＭＬ処理部
１３６ サブプロバイダ登録部
１３７ セッション管理部
１４１ ディレクトリ操作ラッパー
１４２ セッション管理部
１５０ ディレクトリ
１５２ ユーザ情報保存部
１５３ グループ情報保存部
１６０ Ｌｏｃａｌディレクトリプロバイダ
１６１ ＷｉｎＮＴ４ディレクトリプロバイダ
１６２ Ｎｏｔｅｓ（登録商標）Ｒ５ディレクトリプロバイダ
１７０ リポジトリサービス
２００ セッションチケット（Ｕｎｉｏｎマージプロバイダのセッションチケット）
２１０ セッションチケットＩＤ（ＵｎｉｏｎマージプロバイダのセッションチケットのＩＤ）
３００ セッションチケット（サブプロバイダの匿名のセッションチケット）
３１０ セッションチケットＩＤ（サブプロバイダの匿名のセッションチケットのＩＤ）
４００ セッションチケット（サブプロバイダのセッションチケット）
４１０ セッションチケットＩＤ（サブプロバイダのセッションチケットのＩＤ）
５００ 認証チケット（Ｕｎｉｏｎマージプロバイダの認証チケット）
５１０ 認証チケットＩＤ（Ｕｎｉｏｎマージプロバイダの認証チケットのＩＤ）
６００ 認証チケット（サブプロバイダの認証チケット）
６１０ 認証チケットＩＤ（サブプロバイダの認証チケットのＩＤ）
７００ セッションチケット（リポジトリサービスのセッションチケット）
７１０ セッションチケットＩＤ（リポジトリサービスのセッションチケットのＩＤ）

Claims (15)

1. ユーザに係る情報を提供する複数のユーザ情報提供手段と、該ユーザ情報提供手段を下位のユーザ情報提供手段として管理対象とする併合ユーザ情報提供手段とを有し、ユーザ情報管理サービスを行う併合情報提供装置であって、
   前記併合ユーザ情報提供手段は、
   前記ユーザに係る情報を前記ユーザ情報提供手段より取得するユーザ情報取得手段と、
   前記ユーザ情報取得手段により取得した複数の前記ユーザに係る情報を併合するユーザ情報併合手段と、
   前記ユーザ情報提供手段の利用を許可する第一利用許可情報を前記ユーザ情報提供手段より取得し、取得した第一利用許可情報を含む前記併合ユーザ情報提供手段の利用を許可する第二利用許可情報を作成する利用許可情報作成手段とを有し、
   前記ユーザ情報取得手段は、前記第一利用許可情報を用いて前記ユーザ情報提供手段より前記ユーザに係る情報を取得し、前記ユーザ情報併合手段は、前記ユーザ情報取得手段により取得した複数の前記ユーザに係る情報を併合して提供することを特徴とする併合情報提供装置。
2. 前記併合情報提供装置と接続される外部装置を用いたユーザからの要求に応じて、前記下位のユーザ情報提供手段を設定する設定手段を更に有することを特徴とする請求項１に記載の併合情報提供装置。
3. 前記ユーザ情報提供手段は、前記ユーザに係る情報を提供すると共にユーザに係る認証サービスを提供することを特徴とする請求項１又は２に記載の併合情報提供装置。
4. 前記併合ユーザ情報提供手段は、前記ユーザ情報提供手段における前記ユーザを認証する第一認証情報を、前記ユーザ情報提供手段より取得し、取得した第一認証情報を含む前記併合ユーザ情報提供手段における前記ユーザを認証する第二認証情報を作成する認証情報作成手段を更に有することを特徴とする請求項１乃至３の何れか一項に記載の併合情報提供装置。
5. 前記併合ユーザ情報提供手段は、前記ユーザを識別するユーザ識別情報を、前記ユーザ情報提供手段より取得するユーザ識別情報取得手段を更に有することを特徴とする請求項１乃至４の何れか一項に記載の併合情報提供装置。
6. 前記ユーザ識別情報取得手段は、前記第二認証情報に含まれる前記第一認証情報を用いて、前記ユーザ識別情報を、前記ユーザ情報提供手段より取得することを特徴とする請求項５に記載の併合情報提供装置。
7. 前記ユーザ情報提供手段は、前記ユーザに係る情報を保存するユーザ情報保存手段を有することを特徴とする請求項１乃至６の何れか一項に記載の併合情報提供装置。
8. 前記ユーザに係る情報は、ユーザ情報及び／又はユーザが所属するグループ情報であり、該グループ情報には、他のユーザ情報提供手段のユーザ情報及び／又はグループ情報が含まれることを特徴とする請求項１乃至７の何れか一項に記載の併合情報提供装置。
9. 前記下位のユーザ情報提供手段の設定に係る要求を送信する設定要求送信手段を有することを特徴とする請求項１乃至８の何れか一項に記載の併合情報提供装置。
10. 前記併合ユーザ情報提供手段と、前記下位のユーザ情報提供手段と、の設定に係る画面を表示する設定画面表示手段を更に有することを特徴とする請求項１乃至９の何れか一項に記載の併合情報提供装置。
11. ユーザに係る情報を提供する複数のユーザ情報提供手段と、該ユーザ情報提供手段を下位のユーザ情報提供手段として管理対象とする併合ユーザ情報提供手段とを有し、ユーザ情報管理サービスを行う併合情報提供装置により実行される併合情報提供方法であって、
    前記併合ユーザ情報提供手段は、
    前記ユーザに係る情報を前記ユーザ情報提供手段より取得するユーザ情報取得段階と、
    前記ユーザ情報取得段階により取得した複数の前記ユーザに係る情報を併合するユーザ情報併合段階と、
    前記ユーザ情報提供手段の利用を許可する第一利用許可情報を前記ユーザ情報提供手段より取得し、取得した第一利用許可情報を含む前記併合ユーザ情報提供手段の利用を許可する第二利用許可情報を作成する利用許可情報作成段階とを有し、
    前記ユーザ情報取得段階は、前記第一利用許可情報を用いて前記ユーザに係る情報を前記ユーザ情報提供手段より取得し、前記ユーザ情報併合段階は、前記ユーザ情報取得段階により取得した複数の前記ユーザに係る情報を併合して提供することを特徴とする併合情報提供方法。
12. 前記ユーザ情報提供手段は、前記ユーザに係る情報を提供すると共にユーザに係るユーザ認証サービスを提供することを特徴とする請求項１１に記載の併合情報提供方法。
13. 前記併合ユーザ情報提供手段からの要求に応じて、指定されたユーザのユーザに係る情報を前記併合ユーザ情報提供手段に提供するユーザ情報提供段階を有することを特徴とする請求項１１又は１２に記載の併合情報提供方法。
14. 請求項１１乃至１３の何れか一項に記載の併合情報提供方法をコンピュータに実行させるための併合情報提供プログラム。
15. 請求項１４に記載の併合情報提供プログラムを記録したコンピュータ読み取り可能な記録媒体。
    

Images