(57)【要約】【課題】認証コスト、システム構築コストを削減する。【解決手段】ユーザ装置が、代理装置に統合サービス利用要求を行い、代理装置が、統合サービスを構成するサービスソースを提供するサービス装置それぞれにソース要求をし、サービス装置が、代理装置に認証要求をし、代理装置が、受信した認証要求情報を認証装置に送信し、認証装置が、認証結果情報を代理装置に送信し、代理装置が、認証結果情報を受信すると、当該受信した認証結果情報をサービス装置に送信し、サービス装置が、認証結果情報の判定が認証済みであれば、サービスソースを代理装置に送信し、代理装置が、統合サービスを構成するサービスソースを受信すると、当該サービスソースを統合し、当該統合サービスをユーザ装置に送信する。【選択図】図５
2010165306.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ装置と、認証装置と、代理装置と、複数のサービス装置と、で構成されるサービス提供システムを用いたサービス提供方法であって、
（Ａ）前記ユーザ装置が、前記代理装置に統合サービスを利用するための利用要求情報を送信する過程と、
（Ｂ）前記代理装置が、前記利用要求情報を受信すると、認証要求情報を前記認証装置に送信する過程と、
（Ｃ）前記認証装置が、前記認証要求情報を受信すると、認証結果情報を前記代理装置に送信する過程と、
（Ｄ）前記代理装置が、前記認証結果情報を受信すると、当該受信した認証結果情報を前記サービス装置に送信する過程と、
（Ｅ）前記サービス装置が、前記認証結果情報を受信すると、当該認証結果情報を検証し、認証済みであれば、前記サービスソースを前記代理装置に送信する過程と、
（Ｆ）前記代理装置が、前記統合サービスを構成するサービスソースを受信すると、受信した当該サービスソースを統合し、当該統合サービスを前記ユーザ装置に送信する過程と、を有するサービス提供方法。
【請求項２】
請求項１記載のサービス提供方法であって、
前記代理装置は、コンテナ装置と、統合装置に分かれており、
前記（Ａ）過程は、ユーザ装置が、前記利用要求情報を前記統合装置に送信し、
前記（Ｂ）過程は、
前記統合装置が、前記利用要求情報を受信すると、前記コンテナ装置に依頼情報を送信する（Ｂ−１）ステップと、
前記コンテナ装置が、前記依頼情報を受信すると、前記認証要求情報を認証装置に送信する（Ｂ−２）ステップと、
前記（Ｃ）過程は、前記認証装置が、認証要求情報を受信すると、前記認証結果情報を、前記コンテナ装置に送信し、
前記（Ｄ）過程は、前記コンテナ装置が、前記認証結果情報を受信すると、当該受信した認証結果情報を前記サービス装置に送信し、
前記（Ｅ）過程は、
前記サービス装置が、前記認証結果情報を受信すると、当該認証結果情報を検証し、認証済みであれば、前記サービスソースを前記コンテナ装置に送信する（Ｅ−１）ステップと、
前記コンテナ装置が、前記サービスソースを受信すると、当該受信したサービスソースを統合装置に送信する（Ｅ−２）ステップと、を有し、
前記（Ｆ）過程は、前記統合装置が、前記統合サービスを構成するサービスソースを受信すると、受信した当該サービスソースを統合し、当該統合サービスを前記ユーザ装置に送信することを特徴とするサービス提供方法。
【請求項３】
請求項１記載のサービス提供方法であって、
前記（Ａ）過程の後に、
（Ｇ）前記代理装置が、前記利用要求情報を受信すると、ソース要求情報をそれぞれの前記サービス装置に送信する過程と、
（Ｈ）前記サービス装置が、前記ソース要求情報を受信すると、前記認証要求情報を前記代理装置に送信する過程と、を有し、
前記（Ｂ）過程は、前記代理装置が、前記認証要求情報を受信すると、当該受信した認証要求情報を前記認証装置に送信することを特徴とするサービス提供方法。
【請求項４】
請求項２記載のサービス提供方法であって、
前記（Ｂ−１）ステップの後に、
（Ｇ）前記コンテナ装置が、前記依頼情報を受信すると、ソース要求情報をそれぞれの前記サービス装置に送信する過程と、
（Ｈ）前記サービス装置が、前記ソース要求情報を受信すると、前記認証要求情報を前記コンテナ装置に送信する過程と、を有し、
前記（Ｂ−２）ステップは、
前記コンテナ装置が、前記認証要求情報を受信すると、当該受信した認証要求情報を認証装置に送信することを特徴とするサービス提供方法。
【請求項５】
ユーザ装置と、認証装置と、代理装置と、複数のサービス装置と、で構成されるサービス提供システムであって、
前記ユーザ装置は、利用要求情報を代理装置に送信し、当該代理装置から統合サービスを受信する送受信部を有し、
前記認証装置は、
ユーザ認証を行う認証部と、
前記代理装置から認証要求情報を受信し、認証結果情報を前記代理装置に送信する送受信部と、を有し、
前記サービス装置は、
前記認証結果情報を判定する判定部と、
前記代理装置から認証結果情報を受信し、前記判定の結果が認証済みであればサービスソースを前記代理装置に送信する送受信部と、
を有し、
前記代理装置は、
前記統合サービスを構成するサービスソースを受信すると、受信した当該サービスソースを統合することで前記統合サービスを生成する統合部と、
ユーザ装置から前記利用要求情報を受信し、認証要求情報を前記認証装置に送信し、前記認証装置から認証結果情報を受信し、当該受信した認証結果情報を前記サービス装置に送信し、前記サービス装置からサービスソースを受信し、前記統合サービスを前記ユーザ装置に送信する送受信部と、を有するサービス提供システム。
【請求項６】
請求項５記載のサービス提供システムであって、
前記代理装置は、コンテナ装置と、統合装置とに分かれており、
前記統合装置は、
依頼情報を生成する情報生成部と、
前記統合部と、
前記ユーザ装置から利用要求情報を受信し、前記依頼情報を前記コンテナ装置に送信し、前記コンテナ装置からサービスソースを受信し、前記統合サービスを前記ユーザ装置に送信する送受信部と、を有し、
前記コンテナ装置は、
前記コンテナ装置から前記依頼情報を受信し、認証要求情報を前記認証装置に送信し、前記認証装置から認証結果情報を受信し、当該受信した認証結果情報を前記サービス装置に送信し、前記サービス装置からサービスソースを受信し、当該受信したサービスソースを前記統合装置に送信する送受信部と、を有することを特徴とするサービス提供システム。
【請求項７】
請求項５記載のサービス提供システムであって、
前記代理装置の送受信部は、ソース要求情報をそれぞれの前記サービス装置に送信し、前記サービス装置から認証要求情報を受信し、当該受信した認証要求情報を前記認証装置に送信するものであることを特徴とするサービス提供システム。
【請求項８】
請求項６記載のサービス提供システムであって、
前記コンテナ装置の送受信部は、ソース要求情報を前記サービス装置に送信し、前記サービス装置から認証要求情報を受信し、当該受信した認証要求情報を前記認証装置に送信するものであることを特徴とするサービス提供システム。
【請求項９】
統合サービスを要求するユーザ装置と、当該統合サービスを構成するサービスソースを提供する複数のサービス装置と、ユーザ認証を行う認証装置と、で構成されるサービス提供システムに用いられる代理装置であって、
サービスソースを受信すると、受信した当該サービスソースを統合することで前記統合サービスを生成する統合部と、
前記ユーザ装置から利用要求情報を受信し、認証要求情報を前記認証装置に送信し、前記認証装置から認証結果情報を受信し、当該受信した認証結果情報を前記サービス装置に送信し、サービス装置からサービスソースを受信し、前記統合サービスを前記ユーザ装置に送信する送受信部と、を有する代理装置。
【請求項１０】
請求項９記載の代理装置であって、
当該代理装置はコンテナ装置と、統合装置とに分かれており、
前記統合装置は、
依頼情報を生成する情報生成部と、
前記統合部と、
前記ユーザ装置から利用要求情報を受信し、前記依頼情報を前記コンテナ装置に送信し、前記コンテナ装置からサービスソースを受信し、統合サービスを前記ユーザ装置に送信する送受信部と、を有し、
前記コンテナ装置は、
前記統合装置から依頼情報を受信し、認証要求情報を前記認証装置に送信し、前記認証装置から認証結果情報を受信し、当該受信した認証結果情報を前記サービス装置に送信し、前記サービス装置からサービスソースを受信し、当該受信したサービスソースを前記統合装置に送信する送受信部と、を有することを特徴とする代理装置。
【請求項１１】
請求項９記載の代理装置であって、
前記送受信は、ソース要求情報を前記サービス装置に送信し、前記サービス装置から認証要求情報を受信し、当該受信した認証要求情報を前記認証装置に送信するものであることを特徴とする代理装置。
【請求項１２】
請求項１０記載の代理装置であって、
前記コンテナ装置の送受信部は、
ソース要求情報を前記サービス装置に送信し、前記サービス装置から認証要求情報を受信し、当該受信した認証要求情報を前記認証装置に送信するものであることを特徴とする代理装置。
【請求項１３】
請求項９〜１２何れかに記載の代理装置としてコンピュータを動作させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は例えば、複数のサービスソースを統合して統合サービスを提供するサービス提供方法、サービス提供システム、代理装置、そのプログラムに関する。
【背景技術】
【０００２】
従来、複数のサービスソース（マッシュアップソース）を統合（マッシュアップ）させて統合サービスを提供する手法がある（非特許文献１などを参照）。図１に統合サービスの例を示す。図１に示す統合サービスは、時刻の情報についてのサービスソースＸ、天気の情報についてのサービスソースＹ、ニュースの情報についてのサービスソースＺ、背景の情報についてのサービスソースＶ、これら４つのサービスソースからなるものである。
【０００３】
図２に、ユーザ装置１００が統合サービスを受けるためシステム構成の例を示す。図２に示すように、サービスソースを提供するサービス装置がＮ個あり、サービス装置４００ｎ（ｎ＝１、．．．、Ｎ）とする。図１の例では、４個のサービス装置４００１〜４００４がそれぞれサービスソースＸ、Ｙ、Ｚ、Ｖを提供する。サービス装置４００１〜４００４よりのサービスソースＸ、Ｙ、Ｚ、Ｖは統合装置５０に送信される。そして、統合装置５０が４個のサービスソースＸ、Ｙ、Ｚ、Ｖを統合することで、統合サービスを生成し、ユーザ装置１００に送信する。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】川崎有亮、” WebサービスAPI＋マッシュアップことはじめ”［ｏｎｌｉｎｅ］２００６年１１月１０日、Ｉｔｐｒｏ、［平成２１年１月１３日検索］、インターネット〈ＵＲＬ：http://itpro.nikkeibp.co.jp/article/COLUMN/20061020/251301/〉
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来の統合サービス提供手法の場合に、ユーザ（ユーザ装置１００を利用する者）がＮ個全てのサービス装置４００ｎとユーザ認証を行わなければならない場合、Ｎ回のユーザ認証を行わなければならず、認証コストが高かった。
【０００６】
ところで、シングルサインオンという技術がある。この技術は、１回のユーザ認証を受けるだけで、許可されているサービス装置から全てのサービスを受けることができるものであり、認証コストを下げるものである。図３にシングルサインオンの処理フローの例を示し、図３を用いて、簡単にシングサインオンを説明する。また、シングルサインオンの代表的な例として、ＳＡＭＬについては、［平成２１年１月１３日検索］、インターネット〈ＵＲＬ：http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security〉に記載されている。また、オープンＩＤについては、［平成２１年１月１３日検索］、インターネット〈ＵＲＬ：http://openid.net/〉に記載されている。
【０００７】
ユーザ装置１００がサービス利用を要求するための利用要求情報を生成し、サービス装置７００に送信する（ステップＳ３０２）サービス装置７００が、利用要求情報を受信すると、認証処理を要求するための認証要求情報をユーザ装置１００に送信し、リダイレクトで、当該認証要求情報を認証装置２００に送信する（ステップＳ３０４）。
【０００８】
認証装置２００が、認証要求情報を受信すると、認証装置２００がユーザ認証を行う。ユーザは認証装置２００にアカウントを予め持っているとし、ユーザが共有している認証情報（例えば、パスワード）をユーザ装置１００が認証装置２００に送信し、認証装置２００が送信された認証情報が正当なものか否かを判断する。
【０００９】
認証装置２００の判断結果（ユーザが認証されたか否か）である認証結果情報がサービス装置７００に送信される。サービス装置７００が受信した認証結果情報を検証した結果、ユーザが認証された旨のものであれば、サービス装置７００はユーザ装置１００にサービスを送信（提供）する。そして、一度、ユーザが認証されれば、認証装置２００に許可されている他のサービス装置からサービスを受けることができ、結果として認証コストを削減できる。
【００１０】
このシングルサインオンを統合サービス提供手法に適用して、認証コストを低減できるとも考えられる。しかし、シングルサインオンのプロトコルに準拠して適用することは容易ではない。理由を説明すると、シングルサインオンプロトコルに従うと、サービス装置４００ｎからのサービスソースＢｎは、ユーザ認証の起点（つまり、ユーザ装置１００）に送信され、統合装置５０に送信されなくなる。そうすると、サービスソースは統合装置５０を通して、提供されない。また、サービスソースを統合装置５０に送信するように設計し直すとすると、シングルサインオンプロトコルを崩すことになり、システム構築コスト、システム導入コストなどがかかる。
【課題を解決するための手段】
【００１１】
上記の課題を解決するために、以下の方法でサービス提供を行う。ユーザ装置が、代理装置に統合サービスを利用するための利用要求情報を送信する。代理装置が、利用要求情報を受信すると、認証要求情報を認証装置に送信する。認証装置が、認証要求情報を受信すると、認証結果情報を代理装置に送信する。代理装置が、認証結果情報を受信すると、当該受信した認証結果情報をサービス装置に送信する。サービス装置が、認証結果情報を受信すると、当該認証結果情報を判定し、認証済みであれば、サービスソースを代理装置に送信する。代理装置が、統合サービスを構成するサービスソースを受信すると、当該サービスソースを統合し、当該統合サービスをユーザ装置に送信する。
【発明の効果】
【００１２】
本発明のサービス提供方法によれば、従来のシングルサインオンのプロトコルに準拠して、統合サービス提供手法に適用できることから、認証コスト、システム構築コストなどを軽減できるという効果がある。
【図面の簡単な説明】
【００１３】
【図１】統合サービスの一例を示した図。
【図２】従来の統合サービス提供システムの機能構成例を示した図。
【図３】シングルサインオンの処理フローの一例を示した図。
【図４】本実施例のサービス提供システムの構成例を示した図。
【図５】本実施例の処理フローを示した図。
【図６】本実施例のユーザ装置などの機能構成例を示した図。
【図７】宛先リストの一例を示した図。
【図８】別の実施例の処理フローの前編を示した図。
【図９】別の実施例の処理フローの後編を示した図。
【図１０】コンテナ装置、統合装置の機能構成例を示した図。
【図１１】ＨＴＴＰ  Ａｒｔｉｆａｃｔ  Ｂｉｎｄｉｎｇ方式を適用した場合の処理フローの前編を示した図。
【図１２】ＨＴＴＰ  Ａｒｔｉｆａｃｔ  Ｂｉｎｄｉｎｇ方式を適用した場合の処理フローの中編を示した図。
【図１３】ＨＴＴＰ  Ａｒｔｉｆａｃｔ  Ｂｉｎｄｉｎｇ方式を適用した場合の処理フローの後編を示した図。
【発明を実施するための形態】
【００１４】
以下、本発明の実施の形態について、詳細に説明する。
【実施例１】
【００１５】
図４にサービス提供システムの構成例を示し、図５に処理フローを示し、図６にユーザ装置１００など機能構成例を示す。図４に示すように、本実施例のサービス提供システムは、ユーザ装置１００、認証装置２００、代理装置３００、それぞれがサービスソースＢｎを提供するＮ個のサービス装置４００ｎ（ｎ＝１、．．．、Ｎ）とで構成され、ユーザ装置１００、認証装置２００、代理装置３００は、ネットワーク７０で接続されている。Ｎ個のサービス装置４００ｎは代理装置３００に接続されている。
【００１６】
前提条件として、ユーザ装置１００は認証装置２００のアカウントを持っており、代理装置３００から見て、認証装置２００、サービス装置４００ｎは信頼関係がある（お互いにサーバ認証されている）なものであるとする。また、ユーザ装置１００は、統合サービスＷを要求しているものとし、統合サービスＷは、Ｎ個のサービスソースＢｎ（ｎ＝１、．．．、Ｎ）により構成されているものとする。サービス装置４００ｎが、それぞれ対応するサービスソースＢｎを提供しているものとする。
【００１７】
まず、ユーザ装置１００の情報生成部１０４が、統合サービスを利用するための利用要求情報Ａを生成して、送受信部１０２が利用要求情報Ａを代理装置３００に送信する（ステップＳ１０２）。代理装置３００の送受信部３０２が、利用要求情報Ａを受信すると、サービスソースＢｎを要求するための情報であるソース要求情報Ｃを、対応するサービス装置４００ｎに送信する（ステップＳ１０４）。サービス装置４００ｎの送受信部４０２が、ソース要求情報Ｃを受信すると、サービス装置４００ｎの情報生成部４０４は、ユーザ認証を要求するための情報である認証要求情報Ｄを生成し、送受信部４０２が代理装置３００に認証要求情報Ｄを送信する（ステップＳ１０６）。当該ステップＳ１０６の送受信部４０２の認証要求情報Ｄの送信処理は、シングルサインオンプロトコルに基づいて、ソース要求情報Ｃの送信元である代理装置３００に対して行われる。
【００１８】
代理装置３００の送受信部３０２が、認証要求情報Ｄを受信する。ここで、代理装置３００は認証要求情報Ｄの宛先を変換して、当該受信した認証要求情報Ｄを変えずに認証装置２００に送信する。
【００１９】
ここで宛先変換の第１の手法として、ステップＳ１０６において、サービス装置４００ｎは認証装置２００の宛先情報（例えば、ＵＲＬ）を含ませた認証要求情報Ｄを代理装置３００に送信する。そして、代理装置の送受信部３０２は、当該含まれた認証装置２００の宛先情報を用いて認証要求情報Ｄを認証装置２００に送信する。
【００２０】
第２の手法として、代理装置３００の記憶部３０６に宛先リストを格納させる。図７に宛先リストの例を示す。図７に示すように、宛先リストとは、一例として、サービス装置の宛先αと認証装置の宛先βとを対応付けたものである。代理装置３００の変換部３０８が宛先リストを参照して、認証要求情報Ｄの送信元のサービス装置４００ｎの宛先αと対応する認証装置の宛先βを取り出し、当該宛先βに対して、受信した認証要求情報Ｄを送信する。つまり、代理装置３００は認証要求情報Ｄの宛先変換を行い、受信した認証要求情報Ｄそのまま（同一性を変えずに）、認証装置２００に対して送信する。図５に示すように、ユーザ装置１００に送信し、リダイレクトにより認証装置２００に送信してもよい。認証要求情報Ｄの宛先変換手法は第１、第２の手法に限られない。
【００２１】
また、以下の［具体例］で説明する「Ｕｎｓｏｌｉｃｉｔｅｄ  Ｒｅｓｐｏｎｓｅ」方式を適用すれば、ステップＳ１０４とステップＳ１０６とを省略できる。この場合は、代理装置３００の情報生成部３０４が認証要求情報Ｄを生成し、当該認証要求情報Ｄを認証装置２００に送信すればよい。
【００２２】
認証装置２００が、認証要求情報Ｄを受信すると、認証装置２００はユーザ認証を行う（ステップＳ１０９）。ユーザ認証の一例として、ユーザが認証装置２００に予めパスワードを設定し、ユーザ装置１００は当該パスワードを認証装置２００に送信し、認証装置２００が受信したパスワードが正当であるか否かを判定する。また、このユーザ認証処理は事前（ステップＳ１０２の前）に行っていても良い。そして、ユーザの認証状態（認証済みか否か）は認証装置２００の記憶部２０６に記憶する。
【００２３】
認証装置２００の送受信部２０２は認証結果情報Ｅを代理装置３００に対して、送信すし（ステップＳ１１０）、代理装置３００の送受信部３０２が認証結果情報Ｅを受信する。代理装置３００は当該受信した認証結果情報Ｅをそのまま（同一性を変えずに）に、認証結果情報Ｅと対応する認証要求情報Ｄの送信元のサービス装置４００ｎに送信する。
【００２４】
サービス装置４００ｎの送受信部４０２が認証結果情報Ｅを受信すると、判定部４１０が、認証結果情報Ｅを判定し、認証結果が検証できなければ、処理を終了させるなどをすれば良い。また、認証結果が検証できれば、サービス装置４００ｎはサービスソースＢｎを代理装置３００に送信する（ステップＳ１１４）。
【００２５】
そして、代理装置３００が、統合サービスＷを構成するためのサービスソースＢｎを収集すると、サービスソースＢｎを統合することで統合サービスＷを生成し、統合サービスＷをユーザ装置１００に送信する。
【００２６】
このように、本実施例であれば、シングルサインオンプロトコルに準拠して統合サービス提供手法に適用できる。図５に示すように、本実施例のサービス提供方法であれば、代理装置３００が利用要求情報Ａを一旦、受信して（ステップＳ１０２）、サービス装置４００ｎにソース要求情報Ｃを送信している。また、代理装置３００が認証結果情報Ｅを一旦、受信して（ステップＳ１１２）認証結果情報Ｅをサービス装置４００ｎに送信している。従って、シングルサインオンプロトコルに基づいて、サービス要求の起点である代理装置３００にサービスソースＢｎは送信されることになり、代理装置３００でサービスソースＢｎを統合して、統合サービスＷを生成し当該統合サービスＷをユーザ装置１００に対して送信できる。
【実施例２】
【００２７】
実施例２は、セキュリティ性向上のため、代理装置３００をコンテナ装置５００と統合装置６００とに分けた構成である。統合装置６００は、マッシュアッププログラムをコンピュータにダウンロードしたものであり、統合装置６００には、サービスソースＢｎの統合処理以外の処理をさせたくないという開発実情がある。そこで、統合装置６００が呼び出せる共通機能として、コンテナ装置５００を設け、統合装置６００は当該コンテナ装置５００に対して依頼情報Ｆを送信することで呼び出せるようにする。そして、統合処理以外の処理をコンテナ装置５００にさせることで、統合装置６００の負荷を軽減でき、開発実情にあわせることができつつ、実施例１の効果を得ることができる。図８、図９にそれぞれに実施例２のサービス提供方法の前編、後編の処理フローを示し、図１０にコンテナ装置５００と統合装置６００の機能構成例を示す。また、図８、９は図５と対応するステップの参照番号には「−１」や「−２」を付けて表現する。例えば、実施例１で説明したステップＳ１０２は、実施例２では、ステップＳ１０２−１と対応し、実施例１で説明したステップＳ１０４は、実施例２では、ステップＳ１０４−１とステップＳ１０４−２とで構成される。また、ユーザ装置１００、認証装置２００、サービス装置４００ｎは図６（実施例１）と同様である。
【００２８】
ステップＳ１０２−１として、ユーザ装置１００が、利用要求情報Ａを統合装置６００に送信する。
【００２９】
ステップＳ１０４−１として、統合装置６００の情報生成部６０４はコンテナ装置５００を呼び出すための依頼情報Ｆを生成し、コンテナ装置５００に送信する。ステップＳ１０４−２として、コンテナ装置５００の情報生成部５０４は、ソース要求情報Ｃを生成し、送受信部５０２がソース要求情報Ｃを各サービス装置４００ｎに送信する。
【００３０】
ステップＳ１０６−１として、サービス装置４００ｎは認証要求情報Ｄをコンテナ装置５００に送信する。ステップＳ１０８−１として、コンテナ装置５００の変換部５０８が前記第１の手法または第２の手法などを用いて認証要求情報Ｄの宛先を変換して、送受信部５０２が、受信した認証要求情報Ｄを認証装置２００に送信する。変換部５０８は実施例１で説明した変換部３０８と同一のものである。また、以下の［具体例］で説明する「Ｕｎｓｏｌｉｃｉｔｅｄ  Ｒｅｓｐｏｎｓｅ」方式であれば、ステップＳ１０４−２とステップＳ１０６−１とを省略できる。この場合は、コンテナ装置５００の情報生成部５０６が認証要求情報Ｄを生成し、送受信部５０２が当該認証要求情報Ｄを認証装置２００に送信すればよい。そして、ステップＳ１０９により、認証装置２００はユーザ認証を行う。
【００３１】
ステップＳ１１０−１として、認証結果情報Ｅは、ユーザ装置１００およびコンテナ装置５００に送信される。ステップＳ１１２−１として、コンテナ装置５００の変換部３０８は認証結果情報Ｅについて宛先変換して、送受信部５０２は、受信した認証結果情報Ｅをそのままサービス装置４００ｎに送信する。
【００３２】
判定部４１０が認証結果情報Ｅを判定し、認証状態（当該判定が認証済みであるか否かの状態）を記憶部４０６に記憶させる。そして、情報生成部４０４が、認証キーＧと認証済み情報Ｈとを生成する。認証キーＧとは、コンテナ装置５００とサービス装置４００とのセッション情報であり、認証済み情報Ｈとは、認証結果情報Ｅの判定処理が終了したことを示すものである。ステップＳ２１８として、送受信部４０２が、認証キーＧと認証済み情報Ｈとをコンテナ装置５００に送信する。認証キーＧは、一旦、コンテナ装置５００の記憶部５０６に記憶される。ステップＳ２２０として、コンテナ装置５００の送受信部５０２が受信した認証済み情報Ｈを統合装置６００に送信する。
【００３３】
ステップＳ２２２として、統合装置６００の送受信部６０２が、認証済み情報Ｈを受信すると、情報生成部６０４がソース依頼情報Ｊを生成し、コンテナ装置５００に送信する。ソース依頼情報Ｊとは、コンテナ装置５００にサービスソースＢｎの受信を依頼するための情報である。
【００３４】
コンテナ装置５００の送受信部５０２がソース依頼情報Ｊを受信すると、情報生成部５０４が、ソース要求情報Ｃを生成する。そして、ステップＳ２２４として、当該ソース要求情報Ｃと記憶部５０６に記憶させていた認証キーＧをサービス装置４００ｎに送信する。サービス装置４００ｎの送受信部４０２が、ソース要求情報Ｃと認証キーＧと受信すると、判定部４１０が認証キーＧが正当であるか否かを判定する。ステップＳ２２６として、判定部４１０の判定が正当であれば、サービス装置４００ｎはサービスソースＢｎをコンテナ装置５００に送信する。ステップＳ２２８として、コンテナ装置５００は受信したサービスソースＢｎを統合装置６００に送信する。
【００３５】
ステップＳ１１６−１として、統合装置６００はサービスソースＢｎを収集すると当該サービスソースＢｎを統合して、統合サービスＷを生成する。送受信部６−２は生成された統合サービスＷをユーザ装置１００に送信する。
また、コンテナ装置５００、統合装置６００を１つの筺体内に具備させ、代理装置３００’としてもよい。
【００３６】
実施例２では、セキュリティ性を向上させるために、サービス装置４００ｎの情報生成部４０４が認証キーを生成した。また、この認証キーを用いる手法は公知であり、実施例１で適用しても良い。
【００３７】
上記説明、図８、９から明らかなように、統合装置６００は、ユーザ装置１００との情報のやりとり（ステップＳ１０２−１とステップＳ１１６−１）と、コンテナ装置５００との情報のやりとり（ステップＳ１１４−１など）しか行わず、かつ、サービスソースＢｎの統合処理以外の処理は全てコンテナ装置５００に行わせている。従って、統合装置６００の負荷をコンテナ装置５００に分担させることができ、結果として、統合装置６００を構成しやすくなるという顕著な効果を有することができる。
【実施例３】
【００３８】
ユーザは提供された統合サービスＷをカスタマイズしたい場合がある。ここで、カスタマイズとは、図１の例で説明すると、例えば、サービスソースＸについての時刻情報、サービスソースＹについての天気情報Ｙ、サービスソースＺについてのニュース情報の位置を変えることである。ユーザが統合サービスＷのカスタマイズを所望する場合には、ユーザ装置１００の情報生成部１０４はカスタマイズ所望情報Ｋを生成し、統合装置６００に送信する。従って、統合装置６００とユーザ装置１００との通信手段を確保しなければならないという実情がある。図８、９の例では、当該通信手段は確保されている。
【００３９】
一方、実施例２で説明したとおり、コンテナ装置５００は、重要な情報や機能を有する。重要な情報とは例えば、記憶部５０６に記憶されている宛名リストであり、重要な機能とは、例えばステップＳ１１２−１での受信した認証結果情報をそのまま、サービス装置４００ｎに送信する機能である。また、認証装置２００、サービス装置４００ｎ、統合装置６００はコンテナ装置５００からみて、信頼関係があるものとする。しかし、ユーザ装置１００に悪意があれば、コンテナ装置５００の重要な情報や機能を攻撃する場合があるが、実施例２のサービス提供システムの場合であると、ステップＳ１１２−１で示したとおり、コンテナ装置５００とユーザ装置１００との通信手段が確保されており、コンテナ装置５００が攻撃される可能性がある。
【００４０】
そこで、実施例３のサービス提供システムでは、コンテナ装置５００の送受信部５０２に判断手段５０２０を設ける（図１０では破線で示す）。判断手段５０２０は、ユーザ装置１００からの情報については、アイデンティティ情報Ｌのみを受信し、それ以外の情報については受信しない。アイデンティティ情報Ｌとは、ユーザの認証情報や認可情報や認証結果情報などを示す。
【００４１】
このように、コンテナ装置５００の送受信部５０２に判断手段５０２０を設けることで、実施例２のサービス提供システムと比較して、よりセキュリティ性を向上させたサービス提供システムを構築できる。
【００４２】
［具体例］  
実施例１〜３で説明したサービス提供方法の具体的な例として、［１］ＳＡＭＬ利用方式の場合には、（１）ＨＴＴＰ（Ｒｅｄｉｒｅｃｔ／ＰＯＳＴ）Ｂｉｎｄｉｎｇ方式（２）ＨＴＴＰ  Ａｒｔｉｆａｃｔ  Ｂｉｎｄｉｎｇ方式（３）Ｕｎｓｏｌｉｃｉｔｅｄ  Ｒｅｓｐｏｎｓｅ方式などがあり、そのほか［２］Ｏｐｅｎ  ＩＤ利用方式等がある。以下、それぞれ簡単に説明する。
［１］ＳＡＭＬ利用方式の場合には、以下を前提条件とする。
・認証装置２００は、ＳＡＭＬ  Ｉｄｐに相当
・サービス装置４００ｎはＳＡＭＬ  ＳＰに相当
・サービス装置４００ｎはＩｄｐのＣｏＴ（Ｃｉｒｃｌｅ  ｏｆ  Ｔｒｕｓｔ）に属する
・認証装置とサービス装置のユーザアカウントはＩＤ連携済
【００４３】
ここで、ＣｏＴとは、ユーザのアイデンティティ情報の運用協定に基づく信頼関係を持っているサービス装置４００ｎと認証装置の連携を示す。
（１）ＨＴＴＰ（Ｒｅｄｉｒｅｃｔ／ＰＯＳＴ）Ｂｉｎｄｉｎｇ方式について説明する。シーケンス図は図８、９である。ＨＴＴＰＢｉｎｄｉｎｇ方式は、最も一般的に用いられる通信方式である。リダイレクトの場合にはＵＲＬパラメータとして、ＰＯＳＴの場合にはＨＴＭＬのボディを利用して、ＳＡＭＬメッセージを交換する。ＳＡＭＬリクエストに対するレスポンスのＨＴＴＰ電文としてＡｓｓｅｒｔｉｏｎを送りあう方式である。
【００４４】
この方式では、上述のように、コンテナ装置５００は、統合装置６００に代わって、サービス装置４００ｎへのサービス要求と認証処理、データ取得の処理を行う。また、コンテナ装置５００は、認証装置２００とサービス装置４００ｎの間でＳＡＭＬリクエストとレスポンスを代理する機能を提供する必要がある。
【００４５】
認証装置に対するＳＡＭＬリクエストを生成する場合には、サービス装置４００ｎはユーザの認証装置を認識する必要がある。通常は、認証装置のトップ画面で選択するなどの方法で実現されているが、この場合、ユーザ装置１００からサービス装置４００ｎには直接アクセスしない。取れる手段としては、サービス装置４００ｎが認証装置を固定的に設定しておくか、サービス装置４００ｎのインターフェースとしてユーザの認証装置を指定してできるようなものを用意する必要がある。前記の場合には、ユーザやサービス装置４００ｎが利用できる認証装置は限られてしまい、後者の場合にはサービス装置の開発者が上記のインターフェースを実装する必要がある。
【００４６】
また、ＳＡＭＬメッセージのエンドポイント（認証装置−サービス装置）と実際に通信が発生する対象（認証装置−コンテナ装置、コンテナ装置−サービス装置）が異なる点には注意が必要である。ここでＳＡＭＬ仕様ではリクエストプロトコルの中で、ＳＡＭＬレスポンスのエンドポイントを明示的に指定する要素としてＡｓｓｅｒｔｉｏｎ  Ｃｏｎｓｕｍｅｒ  Ｓｅｒｖｉｃｅ  ＵＲＬという属性が規定されている。よって認証装置はこの値として、サービス装置のアドレスを設定しておけば、ＳＡＭＬリクエストの送信元（コンテナ装置）に関わらず、指定されたエンドポイント（サービス装置）に充てたＡｓｓｅｒｔｉｏｎを生成することは可能である。また、ＳＡＭＬレスポンスプロトコルには、レスポンスの宛先をしている要素としてＤｅｓｔｉｎａｔｉｏｎという属性が規定されている。よって認証装置はこの値としてサービス装置のアドレスを設定しておけば、ＳＡＭＬ、レスポンスの送信先（コンテナ装置）にかかわらず、指定したエンドポイント（サービス装置）にＡｓｓｅｒｔｉｏｎを返信することは可能である。
【００４７】
（２）ＨＴＴＰ  Ａｒｔｉｆａｃｔ  Ｂｉｎｄｉｎｇ方式について説明する。図１１〜図１３に、この方式のシーケンス図の前編、中編、後編を示す。実施例２と比較して主に違っている点は、ステップＳ５０２、Ｓ５０４、Ｓ５０６、Ｓ５０８が追加されている点である。
【００４８】
Ａｒｔｉｆａｃｔとは、ＳＡＭＬリクエストやレスポンスを参照するための情報（以下、「参照情報Ｍという。」）である。Ａｒｔｉｆａｃｔ方式とは、ユーザ装置を介した認証装置とサービス装置とのやり取りにおいて、ＳＡＭＬメッセージの代わりにＡｒｔｉｆａｃｔと呼ばれる参照情報Ｍのみを利用する方式であり、ユーザ装置を介してやり取りされるデータ量を抑えることができる。参照情報Ｍを受信したサービス装置４００ｎや認証装置２００は、ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）などの通信手段を使って、直接ＳＡＭＬメッセージをやり取りする。
【００４９】
この場合にステップＳ１０６において、コンテナ装置５００が代理するのは、認証要求情報Ｄ、認証結果情報Ｅとして、ＳＡＭＬメッセージではなく、Ａｒｔｉｆａｃｔ（参照情報Ｍ）という短いデータになる。逆に、認証装置２００とサービス装置４００ｎは直接通信して認証情報を取得する必要があるため、ＳＯＡＰのインターフェースを備える必要がある。また、実施例２と同様にサービス装置４００ｎが参照情報Ｍを送信する時点で、認証装置２００の宛先（ＵＲＬ）を認識する必要があり、認証装置２００を特定する何らかの手段が必要である。また、この場合も、ＳＡＭＬメッセージのエンドポイント（つまり、認証装置２００−サービス装置４００ｎ）と、実際に通信が発生する対象（認証装置２００−コンテナ装置５００、コンテナ装置５００−サービス装置４００ｎ）が異なる点に注意が必要であるが、上記（１）同様に認証装置２００に対する認証要求にＡｓｓｅｒｔｉｏｎ  Ｃｏｎｓｕｍｅｒ  Ｓｅｒｖｉｃｅ  ＵＲＬとしてサービス装置４００ｎのアドレスを設定しておけばよい。
【００５０】
（３）Ｕｎｓｏｌｉｃｉｔｅｄ  Ｒｅｓｐｏｎｓｅ方式について説明する。当該方式のシーケンス図の前編は図８のステップＳ１０４−２とステップＳ１０６−１を削除したものであり、後編は図９と同様である。
通常、Ａｓｓｅｒｔｉｏｎ（認証要求情報Ｄ）は、認証要求に対するレスポンスの形式で送られるが、この方式を用いると、サービス装置４００からのリクエストなしに、認証装置２００から一方的にＡｓｓｅｒｔｉｏｎを送ることができる。
【００５１】
この場合に、ＳＡＭＬリクエストを生成する時点で、コンテナ装置５００は認証装置２００のＵＲＬを認識する必要があるため、統合装置６００の開発者は、統合装置６００に認証装置２００を指定するためのインターフェースを用意する必要がある。また、ＳＡＭＬリクエストを生成し送信するサーバ（コンテナ装置５００）とＳＡＭＬＡｓｓｅｒｔｉｏｎの発行先となるサーバ（サービス装置４００ｎ）は異なる点に注意が必要であるが、実施例２と同様、コンテナ装置５００が認証装置２００に要求するリクエストとにＡｓｓｅｒｔｉｏｎ  Ｃｏｎｓｕｍｅｒ  Ｓｅｒｖｉｃｅ  ＵＲＬとしてサービス装置４００ｎのアドレスを設定しておけば良い。また、この場合に、ステップＳ１１２−１で送信される認証結果情報Ｅは、Ｕｎｓｏｌｉｃｉｔｅｄ  Ｒｅｓｐｏｎｓｅになり、サービス装置４００ｎは必須仕様ではないＵｎｓｏｌｉｃｉｔｅｄ  Ｒｅｓｐｏｎｓｅに対応している必要があり、サービス装置４００ｎの実装上の敷居が高い。
【００５２】
［２］Ｏｐｅｎ  ＩＤ利用方式
次に、Ｏｐｅｎ  ＩＤ利用方式を説明すると、以下を前提条件とする。シーケンス図は図８、９になる。
・認証装置２００は、ＯｐｅｎＩｄ  Ｏｐに相当
・サービス装置４００ｎはＯｐｅｎＩＤ  ＲＰに相当
・サービス装置４００ｎは認証装置２００が提供するＯｐｅｎＩＤを受け入れる。
【００５３】
まずユーザ装置１００は、サービス装置に対して、ユーザのＯｐｅｎＩＤを送信する。サービス装置はそのＵＲＬに対して、認証要求を行い、当該認証要求を受けた認証装置は、ユーザ認証すると、認証結果情報ＥをＰｏｓｉｔｉｖｅ  Ａｓｓｅｒｔｉｏｎという形式で、サービス装置４００ｎに通知する。
【００５４】
この方式では、コンテナ装置５００は、認証装置２００とサービス装置４００ｎ間でＯＰＲｅｑｕｅｓｔとＲｅｓｐｏｎｓｅを代理する機能を必要とする。つまり、ステップＳ１０６−１、ステップＳ１０８−１で用いられる認証要求情報ＤはＯＰＲｅｑｕｅｓｔになり、認証結果情報Ｅは、Ｒｅｓｐｏｎｓｅ（Ｐｏｓｉｔｉｖｅ  Ａｓｓｅｒｔｉｏｎ）になる。
【００５５】
通常、ユーザはサービス装置４００ｎに自分のＯｐｅｎＩＤを入力するが、この場合には統合装置６００にＯｐｅｎＩＤを入力する必要があり（ユーザ装置１００は利用要求情報とＯｐｅｎＩＤを統合装置６００に送信する必要がある）、統合装置６００の開発者はＯｐｅｎＩＤを入力するためのインターフェースを用意する必要がある。
【００５６】
通常、認証装置２００のリクエストには、認証が完了した際のリダイレクト先として定義される「ｏｐｅｎｉｄ  ｒｅｔｕｒｎ＿ｔｏ」というパラメータが含まれる。仕様上、認証装置２００は認証のステータスを示すレスポンスをこのＵＲＬに戻すべきだと規定されているが、この方式の場合、認証結果は一度コンテナ装置５００にリダイレクトされた後にサービス装置に返されるため、ｒｅｔｕｒｎ＿ｔｏパラメータを無視にする必要がある。つまり認証装置は標準仕様に親和性の低い実装にすることが望まれる。
【００５７】
＜ハードウェア構成＞
本発明は上述の実施の形態に限定されるものではない。また、上述の各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。その他、本発明の趣旨を逸脱しない範囲で適宜変更が可能であることはいうまでもない。
また、上述の構成をコンピュータによって実現する場合、代理装置３００が有すべき機能の処理内容はプログラムによって記述される。そして、このプログラムをコンピュータで実行することにより、処理機能がコンピュータ上で実現される。
【００５８】
この処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記憶しておくことができる。コンピュータで読み取り可能な記録媒体としては、例えば、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリ等どのようなものでもよいが、具体的には、例えば、磁気記憶装置として、ハードディスク装置、フレキシブルディスク、磁気テープ等を、光ディスクとして、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）等を、光磁気記録媒体として、ＭＯ（Magneto-Optical disc）等を、半導体メモリとしてＥＥＰ−ＲＯＭ（Electronically Erasable and Programmable-Read Only Memory）等を用いることができる。
【００５９】
また、このプログラムの流通は、例えば、そのプログラムを記憶したＤＶＤ、ＣＤ−ＲＯＭ等の可搬型記録媒体を販売、譲渡、貸与等することによって行う。さらに、このプログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することにより、このプログラムを流通させる構成としてもよい。
【００６０】
このようなプログラムを実行するコンピュータは、例えば、まず、可搬型記録媒体に記憶されたプログラムもしくはサーバコンピュータから転送されたプログラムを、一旦、自己の記憶装置に格納する。そして、処理の実行時、このコンピュータは、自己の記録媒体に格納されたプログラムを読み取り、読み取ったプログラムに従った処理を実行する。また、このプログラムの別の実行形態として、コンピュータが可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することとしてもよく、さらに、このコンピュータにサーバコンピュータからプログラムが転送されるたびに、逐次、受け取ったプログラムに従った処理を実行することとしてもよい。また、サーバコンピュータから、このコンピュータへのプログラムの転送は行わず、その実行指示と結果取得のみによって処理機能を実現する、いわゆるＡＳＰ（Application Service Provider）型のサービスによって、上述の処理を実行する構成としてもよい。なお、本形態におけるプログラムには、電子計算機による処理の用に供する情報であってプログラムに準ずるもの（コンピュータに対する直接の指令ではないがコンピュータの処理を規定する性質を有するデータ等）を含むものとする。
また、この形態では、コンピュータ上で所定のプログラムを実行させることにより、本装置を構成することとしたが、これらの処理内容の少なくとも一部をハードウェア的に実現することとしてもよい。
【００６１】
また、本実施例で説明した代理装置３００は、ＣＰＵ（Central Processing Unit）、入力部、出力部、補助記憶装置、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）及びバスを有している（何れも図示せず）。
【００６２】
ＣＰＵは、読み込まれた各種プログラムに従って様々な演算処理を実行する。補助記憶装置は、例えば、ハードディスク、ＭＯ（Magneto-Optical disc）、半導体メモリ等であり、ＲＡＭは、ＳＲＡＭ(Static Random Access Memory)、ＤＲＡＭ (Dynamic Random Access Memory)等である。また、バスは、ＣＰＵ、入力部、出力部、補助記憶装置、ＲＡＭ及びＲＯＭを通信可能に接続している。
【００６３】
＜ハードウェアとソフトウェアとの協働＞
本実施例の単語追加装置は、上述のようなハードウェアに所定のプログラムが読み込まれ、ＣＰＵがそれを実行することによって構築される。以下、このように構築される各装置の機能構成を説明する。
代理装置３００の送受信部３０２は、所定のプログラムが読み込まれたＣＰＵの制御のもと駆動するＬＡＮカード、モデム等の通信装置である。その他の構成部は、所定のプログラムがＣＰＵに読み込まれ、実行されることによって構築される演算部である。記憶部３０６は前記補助記憶装置として機能する。
【図１】
2010165306.tif 000003
【図２】
2010165306.tif 000004
【図３】
2010165306.tif 000005
【図４】
2010165306.tif 000006
【図５】
2010165306.tif 000007
【図６】
2010165306.tif 000008
【図７】
2010165306.tif 000009
【図８】
2010165306.tif 000010
【図９】
2010165306.tif 000011
【図１０】
2010165306.tif 000012
【図１１】
2010165306.tif 000013
【図１２】
2010165306.tif 000014
【図１３】
2010165306.tif 000015