(57)【要約】  アプリケーション間でのシングルサインオンを可能とするために、クライアント機能を有する認証装置１とサーバ装置２間のつながりを示す連携ＩＤを前記複数のアプリケーション間で共有する。そのために、前記クライアント機能を有する認証装置１のＳＶ情報管理部Ａａが、前記連携ＩＤを所定の記憶部に記憶して管理する。ＡＰ情報管理部Ａｂが、アプリケーションに対応するアプリケーション名を含む、アプリケーション間のつながり情報を、所定の記憶部に記憶して管理する。そして、ＡＰ判定部Ａｄが、受領した連携ＩＤ要求に含まれるアプリケーション名が前記ＡＰ情報管理部Ａｂに登録されているか否かを判定し、該アプリケーション名がＡＰ情報管理部Ａｂに登録されていた場合、連携ＩＤをＳＶ情報管理部Ａａから取得し、該連携ＩＤ要求の送信元に対し該連携ＩＤを返信する。
2009107219.tif 000002
【特許請求の範囲】
【請求項１】
サーバ装置に対しシングルサインオンを行う複数のアプリケーションがインストールされ、ネットワークにおけるクライアント機能を有する認証装置であって、
前記クライアント機能を有する認証装置と前記サーバ装置間のつながりを示す連携ＩＤを前記複数のアプリケーション間で共有する連携ＩＤ共有手段、
を有することを特徴とする認証装置。
【請求項２】
請求項１に記載の認証装置であって、
前記連携ＩＤ共有手段が、
前記連携ＩＤをＳＶ情報記憶部に記憶するＳＶ情報管理部と、
前記複数のアプリケーションのうちの少なくとも１つのアプリケーションに対して、当該アプリケーションとは異なるアプリケーションのアプリケーション名を含む、アプリケーション間のつながり情報を、ＡＰ情報記憶部に記憶するＡＰ情報管理部と、
受領した連携ＩＤ要求に含まれるアプリケーション名が前記ＡＰ情報記憶部に記憶されているか否かを判定し、該アプリケーション名がＡＰ情報記憶部に記憶されていた場合、連携ＩＤを前記ＳＶ情報記憶部から取得し、該連携ＩＤ要求の送信元に対し該連携ＩＤを返信するＡＰ判定部と、を有する、
ことを特徴とする認証装置。
【請求項３】
請求項２に記載の認証装置であって、
前記複数のアプリケーション間で前記ＳＶ情報管理部とＡＰ情報管理部とＡＰ判定部を共有することを特徴とする認証装置。
【請求項４】
請求項１ないし３のうちいずれか1項に記載の認証装置において、
前記サーバ装置は、前記連携ＩＤを発行するシングルサインオン機能提供部を含み、前記認証装置は、
前記シングルサインオン機能提供部に対して認証要求を送信する手段と、
前記シングルサインオン機能提供部において前記認証要求に対する認証に成功した場合に、前記連携ＩＤを前記シングルサインオン機能提供部から受信する手段と
を有することを特徴とする認証装置。
【請求項５】
複数のアプリケーションがネットワークにおけるクライアント機能を有する装置にインストールされ、該インストールされた複数のアプリケーションがサーバ装置に対しシングルサインオンを行う認証方法であって、
前記クライアント機能を有する認証装置と前記サーバ装置間のつながりを示す連携ＩＤを前記複数のアプリケーション間で共有する連携ＩＤ共有ステップを、
を有することを特徴とする認証方法。
【請求項６】
請求項５に記載の認証方法であって、
前記連携ＩＤ共有ステップが、
前記連携ＩＤをＳＶ情報記憶部に記憶するＳＶ情報管理ステップと、
前記複数のアプリケーションのうちの少なくとも１つのアプリケーションに対して、当該アプリケーションとは異なるアプリケーションのアプリケーション名を含む、アプリケーション間のつながり情報を、ＡＰ情報記憶部に記憶するＡＰ情報管理ステップと、
受領した連携ＩＤ要求に含まれるアプリケーション名が前記ＡＰ情報記憶部に記憶されているか否かを判定し、該アプリケーション名がＡＰ情報記憶部に記憶されていた場合、連携ＩＤを前記ＳＶ情報記憶部から取得し、該連携ＩＤ要求の送信元に対し該連携ＩＤを返信するＡＰ判定ステップと、を有することを特徴とする認証方法。
【請求項７】
請求項６に記載の認証方法であって、
前記複数のアプリケーション間で前記ＳＶ情報管理ステップとＡＰ情報管理ステップとＡＰ判定ステップを共通に使用するステップを有することを特徴とする認証方法。
【請求項８】
請求項５ないし７のうちいずれか1項に記載の認証方法において、
前記サーバ装置は、前記連携ＩＤを発行するシングルサインオン機能提供部を含み、前記認証方法は、
前記シングルサインオン機能提供部に対して認証要求を送信するステップと、
前記シングルサインオン機能提供部において前記認証要求に対する認証に成功した場合に、前記連携ＩＤを前記シングルサインオン機能提供部から受信するステップと
を有することを特徴とする認証方法。
【請求項９】
サーバ装置に対しシングルサインオンを行う複数のアプリケーションがインストールされ、ネットワークにおけるクライアント機能を有するコンピュータを、
前記クライアント機能を有するコンピュータと前記サーバ装置間のつながりを示す連携ＩＤを前記複数のアプリケーション間で共有する連携ＩＤ共有手段、
として機能させるためのプログラム。
【請求項１０】
前記コンピュータは、前記連携ＩＤを記憶するＳＶ情報記憶部と、前記複数のアプリケーションのうちの少なくとも１つのアプリケーションに対して、当該アプリケーションとは異なるアプリケーションのアプリケーション名を含む、アプリケーション間のつながり情報を記憶するＡＰ情報記憶部とを有し、
前記連携ＩＤ共有手段は、
受領した連携ＩＤ要求に含まれるアプリケーション名が前記ＡＰ情報記憶部に記憶されているか否かを判定し、該アプリケーション名がＡＰ情報記憶部に記憶されていた場合、連携ＩＤを前記ＳＶ情報記憶部から取得し、該連携ＩＤ要求の送信元に対し該連携ＩＤを返信するＡＰ判定部を有することを特徴とする請求項９に記載のプログラム。
【請求項１１】
請求項９又は１０に記載のプログラムにおいて、
前記サーバ装置は、前記連携ＩＤを発行するシングルサインオン機能提供部を含み、前記プログラムは、前記コンピュータを、
前記シングルサインオン機能提供部に対して認証要求を送信する手段、
前記シングルサインオン機能提供部において前記認証要求に対する認証に成功した場合に、前記連携ＩＤを前記シングルサインオン機能提供部から受信する手段、
として更に機能させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、認証装置におけるシングルサインオン技術に関するものである。
【背景技術】
【０００２】
現在、一般的なＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）ブラウザは、同一サイトへ接続する場合にセッション管理を行うことができる（例えば、ＲＦＣ（Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ）  ２９６５にて規定されたＣｏｏｋｉｅ等の技術を利用して実現している）。また、ＨＴＭＬブラウザが複数サイトへ接続する場合には、当該複数のサイトを提供する複数のサーバ側で何らかの処理を実行する必要があり、例えば、そのサーバ側でセッション管理を行うことが可能であれば、複数サイトへの接続を実現できる（例えば、特許文献１参照）。【０００３】
単一のＨＴＭＬブラウザによってシングルサインオンを実現した既存技術としては、ＩＤ（Ｉｄｅｎｔｉｆｉｅｒ）を分散管理する方式として「Ｌｉｂｅｒｔｙ  Ａｌｌｉａｎｃｅ」やＩＤを集中管理する方式として「．Ｎｅｔ  Ｐａｓｓｐｏｒｔ」などが知られている。
【特許文献１】特開２００２−３３５２３９号公報（段落［００５３］〜［００５８］等）。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
実際のユーザは、単一アプリケーションのみで作業を行うということは少なく、セキュリティ要件やサーバ側の推奨アプリケーションによって複数のアプリケーションの中からあるアプリケーションを選択して使用することがある。【０００５】
また、市場には、放送受信機のようにＢＭＬ（Ｂｒｏａｄｃａｓｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）ブラウザ（放送用のコンテンツを表示するアプリケーション）とＨＴＭＬブラウザが搭載されている装置もあれば、携帯電話のように携帯電話用ＨＴＭＬブラウザとパーソナルコンピュータ用ブラウザ（いわゆるフルブラウザと呼称されるブラウザ）といったように複数のブラウザが搭載されている装置が存在する。【０００６】
以上のような既存技術では、複数ブラウザが搭載されていた場合にも各ブラウザ内でシングルサインオンが実現される。しかし、各ブラウザでサインオンする場合は、各ブラウザ毎に認証が必要になってしまうため、サインオンの手続きが増えて、ユーザの利便性を損なうことになる。【０００７】
特に、放送受信機や携帯電話では、ＨＴＭＬブラウザとは機能の異なるブラウザ（例えば、ＢＭＬブラウザや携帯用ＨＴＭＬブラウザ）が搭載されているため、サインオンの手続きが増える傾向にある。これは、実際のサイトに設置されたコンテンツにおいて、例えば、ＢＭＬブラウザで表示するＢＭＬコンテンツにＨＴＭＬブラウザで表示するＨＴＭＬコンテンツへのリンクが記述してあり、相互のブラウザを行き来するようなサイトが存在するためである。【０００８】
本発明は、前記課題に基づいてなされたものであって、クライアント装置内のアプリケーション間でシングルサインオンを行う認証装置，認証方法およびその方法を実装した認証プログラムを提供することにある。
【課題を解決するための手段】
【０００９】
本発明は、前記課題の解決を図るために、サーバ装置に対しシングルサインオンを行う複数のアプリケーションがインストールされ、ネットワークにおけるクライアント機能を有する認証装置であって、前記クライアント機能を有する認証装置と前記サーバ装置間のつながりを示す連携ＩＤを前記複数のアプリケーション間で共有する連携ＩＤ共有手段、を有する認証装置として構成される。【００１０】
本発明によれば、複数のアプリケーションが搭載されている認証装置において、複数のアプリケーション間で、シングルサインオンを行うことができる。【００１１】
上記認証装置において、前記連携ＩＤ共有手段が、前記連携ＩＤをＳＶ情報記憶部に記憶するＳＶ情報管理部と、前記複数のアプリケーションのうちの少なくとも１つのアプリケーションに対して、当該アプリケーションとは異なるアプリケーションのアプリケーション名を含む、アプリケーション間のつながり情報を、ＡＰ情報記憶部に記憶するＡＰ情報管理部と、受領した連携ＩＤ要求に含まれるアプリケーション名が前記ＡＰ情報記憶部に記憶されているか否かを判定し、該アプリケーション名がＡＰ情報記憶部に記憶されていた場合、連携ＩＤを前記ＳＶ情報記憶部から取得し、該連携ＩＤ要求の送信元に対し該連携ＩＤを返信するＡＰ判定部と、を有する、こととしてもよい。【００１２】
この構成では、ＡＰ情報管理部に記憶されたアプリケーションに対してのみ、連携ＩＤを返信でき、連携ＩＤを共有するアプリケーションを限定できる。【００１３】
また、上記の構成において、前記複数のアプリケーション間で前記ＳＶ情報管理部とＡＰ情報管理部とＡＰ判定部を共有することとしてもよい。これにより、複数のアプリケーション間で連携ＩＤを共通の部で管理できる。【００１４】
また、前記サーバ装置は、前記連携ＩＤを発行するシングルサインオン機能提供部を含み、前記認証装置は、前記シングルサインオン機能提供部に対して認証要求を送信する手段と、前記シングルサインオン機能提供部において前記認証要求に対する認証に成功した場合に、前記連携ＩＤを前記シングルサインオン機能提供部から受信する手段とを有することとしてもよい。【００１５】
また、本発明は、複数のアプリケーションがネットワークにおけるクライアント機能を有する装置にインストールされ、該インストールされた複数のアプリケーションがサーバ装置に対しシングルサインオンを行う認証方法であって、前記クライアント機能を有する認証装置と前記サーバ装置間のつながりを示す連携ＩＤを前記複数のアプリケーション間で共有する連携ＩＤ共有ステップを、を有する認証方法として構成してもよい。【００１６】
上記の構成において、前記連携ＩＤ共有ステップが、前記連携ＩＤをＳＶ情報記憶部に記憶するＳＶ情報管理ステップと、前記複数のアプリケーションのうちの少なくとも１つのアプリケーションに対して、当該アプリケーションとは異なるアプリケーションのアプリケーション名を含む、アプリケーション間のつながり情報を、ＡＰ情報記憶部に記憶するＡＰ情報管理ステップと、受領した連携ＩＤ要求に含まれるアプリケーション名が前記ＡＰ情報記憶部に記憶されているか否かを判定し、該アプリケーション名がＡＰ情報記憶部に記憶されていた場合、連携ＩＤを前記ＳＶ情報記憶部から取得し、該連携ＩＤ要求の送信元に対し該連携ＩＤを返信するＡＰ判定ステップと、を有することとしてもよい。【００１７】
また、上記の認証方法において、前記複数のアプリケーション間で前記ＳＶ情報管理ステップとＡＰ情報管理ステップとＡＰ判定ステップを共通に使用するステップを有することとしてもよい。【００１８】
また、本発明は、コンピュータを、上記認証装置の各機能部として機能させるプログラムとして構成することもできる。
【発明の効果】
【００１９】
本発明によれば、複数のアプリケーションが搭載されている認証装置において、複数のアプリケーション間で、シングルサインオンを行うことができる。また、アプリケーション毎にシングルサインオンを行わないため、ユーザの利便性を向上できる。また、本発明によれば、ネットワークサービス技術分野に貢献できる。
【図面の簡単な説明】
【００２０】
【図１】本実施形態における認証装置の構成図。
【図２】本実施形態におけるＡＰ情報管理部の初期登録処理の一例を示す図。
【図３】本実施形態におけるサーバ装置のシングルサインオン実行処理の一例を示す図。
【図４】サーバ側における構成の他の例を示す図。
【図５】図４に示す構成においてアカウント連携が行われるまでの処理の一例を示す図。
【図６】図４に示す構成においてシングルサインオンを行う処理の一例を示す図。
【図７】本実施形態におけるクライアント装置のアプリケーション間連携処理の一例を示す図。
【図８】本実施形態におけるアプリケーション側認証機能部をアプリケーションの外部に置き、複数アプリケーション間で共有した場合の構成図。
【符号の説明】
【００２１】
１…クライアント装置
２…サーバ装置
２ａ…認証情報管理部
２ｂ…連携ＩＤ管理部
２ｃ…認証部
２ｄ…ＩＤ検索部
２ｅ…受信部
２ｆ…コンテンツ部
１０…シングルサインオン機能提供サーバ
２０…サービス提供サーバ
Ａ，Ｂ…アプリケーション
Ａａ，Ｂａ，ａ…ＳＶ情報管理部
Ａｂ，Ｂｂ，ｂ…ＡＰ情報管理部
Ａｃ，Ｂｃ，ｃ…ＡＰ起動部
Ａｄ，Ｂｄ，ｄ…ＡＰ判定部
Ａｅ，Ｂｅ，ｅ…ＡＰ情報登録部
【発明を実施するための最良の形態】
【００２２】
以下、本発明の実施形態を図面等に基づいて詳細に説明する。まず、本実施形態における認証システムの構成を図１に基づいて説明する。本実施形態の認証システムは、基本的に、クライアント装置（即ち、本実施形態における認証装置；例えば、パーソナルコンピュータ）１，サーバ装置（例えば、サーバ用コンピュータ）２，クライアント装置１とサーバ装置２を接続する通信回線（例えば、インターネット等のネットワーク）を有する。【００２３】
図１中のクライアント装置１には、アプリケーションＡ及びＢがインストールされているものとする。例えば、アプリケーションＡ及びＢは、互いに異なる構造化言語を解釈実行するブラウザアプリケーションであって、アプリケーションＡがＢＭＬブラウザ、アプリケーションＢがＨＴＭＬブラウザである。【００２４】
図１に示す例では、アプリケーションＡ及びＢはそれぞれ、共通のアプリケーション側認証機能部として、ＳＶ（Ｓｅｒｖｅｒ）情報管理部，ＡＰ（Ａｐｐｌｉｃａｔｉｏｎ）情報管理部，ＡＰ起動部，ＡＰ判定部，ＡＰ情報登録部を備えている。なお、図１中では、アプリケーションＡに対応して備えられている認証機能部は、ＳＶ情報管理部Ａａ，ＡＰ情報管理部Ａｂ，ＡＰ起動部Ａｃ，ＡＰ判定部Ａｄ，ＡＰ情報登録部Ａｅを含む。同様に、アプリケーションＢに対応して備えられている認証機能部は、ＳＶ情報管理部Ｂａ，ＡＰ情報管理部Ｂｂ，ＡＰ起動部Ｂｃ，ＡＰ判定部Ｂｄ，ＡＰ情報登録部Ｂｅを含む。前記アプリケーション側認証機能部は、アプリケーション内部に備えていても良い。つまり、アプリケーション側認証機能部を、図１に示すようにアプリケーションとは別にクライアント装置内に備えてもよいし、アプリケーション自体を、アプリケーションとしての本来の機能（ブラウザ等）とアプリケーション側認証機能の両方を含むように構成し、そのアプリケーションをクライアント装置内に備えることとしてもよい。【００２５】
ＳＶ情報管理部Ａａ及びＢａのそれぞれは、サーバ装置２から発行された連携ＩＤ（クライアント装置１とサーバ装置２間のつながりを示す情報）を管理する機能部である。ＳＶ情報管理部Ａａ及びＢａのそれぞれは、例えば、クライアント装置１に予め備えられた記憶装置（例えば、メモリやハードディスク装置）における所定の記憶部を使用して、前記連携ＩＤを管理する。つまり、ＳＶ情報管理部Ａａ及びＢａのそれぞれは、連携ＩＤを格納する記憶部を有する。なお、ＳＶ情報管理部が連携ＩＤを管理するとは、外部から受信した連携ＩＤを記憶部に格納したり、外部からの要求に基づき連携ＩＤを記憶部から読み出すことを含む。【００２６】
ＡＰ情報管理部Ａｂ及びＢｂはそれぞれ、アプリケーション間（例えば、アプリケーションＡとＢ間）のつながり情報を管理する機能部である。設定する該つながり情報は、アプリケーション情報であって、例えば、アプリケーション名，アプリケーションの位置情報，アクセス権情報，アプリケーション種別などを有する。ＡＰ情報管理部Ａｂ及びＢｂは、それぞれクライアント装置１に予め備えられた記憶装置における所定の記憶部を使用して、つながり情報を管理する。つまり、ＡＰ情報管理部Ａｂ及びＢｂはそれぞれ、つながり情報を格納する記憶部を有する。なお、ＡＰ情報管理部がアプリケーション間のつながり情報を管理するとは、外部から受信したつなが利情報を記憶部に格納したり、要求に基づきつながり情報を記憶部から読み出すことを含む。【００２７】
なお、前記つながり情報は、アプリケーションごとに異なってよい。また、クライアント装置１は、前記つながり情報設定時にセキュリティ等を鑑みて認証等を行っても良い。ＡＰ情報管理部は、アプリケーションごとに備えられても良いし、クライアント装置にＡＰ情報管理部を1つ備え、ＡＰ情報管理部が複数のアプリケーションをまとめて管理しても良い。【００２８】
ＡＰ起動部Ａｃ及びＢｃはそれぞれ、サーバ装置２から送信される要求によって、当該要求を受信する実行中のアプリケーション以外のアプリケーションを起動させる機能部である。つまり、クライアント装置１において、ＡＰ起動部ＡｃはアプリケーションＢを起動させ、ＡＰ起動部ＢｃはアプリケーションＡを起動させる。【００２９】
ＡＰ判定部Ａｄ及びＢｄはそれぞれ、対応するアプリケーション以外のアプリケーションが、当該対応するアプリケーションに対して既に登録済みであるか否かを判定する機能部である。つまり、ＡＰ判定部ＡｄはアプリケーションＢがアプリケーションＡに対して登録済みであるか否かを判定し、ＡＰ判定部ＢｄはアプリケーションＡがアプリケーションＢに対して登録済みであるか否かを判定する。【００３０】
ＡＰ情報登録部Ａｅ及びＢｅはそれぞれ、アプリケーション情報を登録するためのインターフェース機能部である。【００３１】
なお、本明細書及び特許請求の範囲において、アプリケーションが実行する動作は、アプリケーションプログラムがコンピュータであるクライアント装置上で実行されることにより実現される機能に基づく動作である。【００３２】
サーバ装置２は、認証情報管理部２ａ，連携ＩＤ管理部２ｂ，認証部２ｃ，ＩＤ検索部２ｄ，受信部２ｅ，コンテンツ部２ｆを備えている。【００３３】
認証情報管理部２ａは、認証情報を自サーバ内で保持している場合に利用する機能部である。【００３４】
連携ＩＤ管理部２ｂは、連携ＩＤ（クライアント装置１とサーバ装置２間のつながりを示す情報）を発行する機能を有し、連携ＩＤを管理する機能部である。【００３５】
認証部２ｃは、要求元のクライアント装置１が認証済みであるか否かを、自サーバ内の認証機構（例えば、認証部２ｃ）、または、サーバ装置２が外部の認証機構を用いているときは外部の認証機構へ問い合わせ、結果を返却する機能部である。【００３６】
ＩＤ検索部２ｄは、連携ＩＤ要求に基づき、連携ＩＤを連携ＩＤ管理部２ｂへ問い合わせ、結果を返却する機能部である。【００３７】
受信部２ｅは、要求に応じて、認証部２ｃ又はコンテンツ部２ｆへ要求電文を振り分ける機能部である。【００３８】
コンテンツ部２ｆは、要求に応じて、コンテンツを提供する機能部である。【００３９】
本実施形態におけるＡＰ情報管理部に対する初期登録処理の一例を図２に基づいて説明する。【００４０】
ＡＰ情報登録部によりユーザに対して登録を要求する画面が表示され（Ｓ１０１）、ユーザが設定すべき項目の情報をクライアント装置１に入力することにより、アプリケーションごとに利用可能なアプリケーション一覧の設定が実施される（Ｓ１０２）。ステップＳ１０１及びＳ１０２の処理によって、連携可能なアプリケーション一覧が作成される。登録内容は、例えば、アプリケーション名，アプリケーションの位置情報（例えば、クライアント装置１内におけるアプリケーションの格納位置（ファイルパス）），アクセス権情報，アプリケーション種別などである。【００４１】
例えば、アプリケーションＡに対応するＡＰ情報管理部Ａｂには、アプリケーションＢがアプリケーションＡと連携可能なアプリケーションとして登録される。そして、この場合、アプリケーションＢの名前、アプリケーションＢの位置情報、アプリケーションＢのアクセス権情報、アプリケーションＢのアプリケーション種別などが登録される。また、アプリケーションＢに対応するＡＰ情報管理部Ｂｂには、アプリケーションＡがアプリケーションＢと連携可能なアプリケーションとして登録される。そして、この場合、アプリケーションＡの名前、アプリケーションＡの位置情報、アプリケーションＡのアクセス権情報、アプリケーションＡのアプリケーション種別などが登録される。なお、全てのアプリケーションに対してアプリケーション情報を登録する必要はなく、必要に応じて少なくとも１つのアプリケーションに関するアプリケーション情報を登録すればよい。【００４２】
つまり、例えば、アプリケーションＡからみて、アプリケーションＢやアプリケーションＣ（図示省略）が利用可能のように登録が行われる。例えば、アプリケーションＡがアクセスを受けたときに（連携ＩＤ要求を受領したときなどに）、回答すべき相手のアプリケーションをアプリケーションＢと登録する。【００４３】
また、例えば、アプリケーションＢに対してアプリケーションＡが登録されていた場合、アプリケーションＢがアプリケーションＡからアクセスされたときにアプリケーションＡに回答してよい、という意味である。また、アプリケーションＢに対してアプリケーションＡが登録されていることは、アプリケーションＢが連携ＩＤを得るために、アプリケーションＡにアクセスできる、という意味でもある。【００４４】
なお、アプリケーション種別とは、アプリケーションの処理内容を識別する識別子で、例えば、静止画処理のアプリケーションＡのアプリケーション種別を"<ｉｍａｇｅ>"タグを用いて登録しておくことで、当該"<ｉｍａｇｅ>"タグを指定してアプリケーションＡを起動できる。または、当該タグにアプリケーション種別が明記されていなければ、ＡＰ起動部は、アプリケーション種別をアプリケーションの起動パラメータに指定して起動するものである。【００４５】
また、設定ファイル（ＡＰ情報管理部に格納される登録情報）を書き換えることが可能である。各登録アプリケーションごとに設定ファイルを持っても良い。登録時に認証を行うなどして、勝手に外部から書き換えられないようにするなどの対応があってもよい。一方のアプリケーションで登録を実施したらもう一方のアプリケーションへ自動設定するような機構があってもよい。【００４６】
以上のように、本実施形態では、ＳＶ情報管理部，ＡＰ情報管理部，ＡＰ判定部を用いて連携ＩＤを複数アプリケーション間で共有する。【００４７】
本実施形態におけるサーバ装置２のシングルサインオン実行処理の一例を図３に基づいて説明する。なお、以下の説明で、図１中の符号と同じものの説明は省略する。【００４８】
まず、要求元のクライアント装置１から画面要求電文がサーバ装置２に対して発行される。サーバ装置２は画面（コンテンツ）要求電文を受信する（Ｓ２０１）。この時点でクライアント装置１とサーバ装置２間で連携がとれていれば、この要求電文には連携ＩＤが含まれる。【００４９】
次に、サーバ装置２は、要求元のクライアント装置１を特定するために、該クライアント装置１に応じた連携ＩＤを、ＩＤ検索部２ｄを使って連携ＩＤ管理部２ｂから検索し、その検索結果によって連携ＩＤの有無を判定する（Ｓ２０２）。連携ＩＤ管理部２ｂに前記連携ＩＤが有った場合、ステップＳ２０３へ進む。連携ＩＤが無かった場合、ステップＳ２０５へ進む。【００５０】
ステップＳ２０３では、認証部２ｃがクライアント装置１の認証状態を認証情報管理部２ａに確認する。クライアント装置１が認証済みの場合、ステップＳ２０４へ進む。クライアント装置１が未認証の場合、ステップＳ２０５へ進む。【００５１】
ステップＳ２０４では、サーバ装置２は要求された画面をコンテンツ部２ｆから取得し、それをクライアント装置１に対して返却する。【００５２】
ステップＳ２０５では、サーバ装置２の認証部２ｃは認証要求をクライアント装置１へ返却し、ステップＳ２０６へ進む。【００５３】
ステップＳ２０６では、サーバ装置２の認証部２ｃは認証情報（例えば、ログインメッセージなど）をクライアント装置１から受信する。【００５４】
次に、サーバ装置２の認証部２ｃは、受信した認証情報を用いて認証処理を行う（Ｓ２０７）。認証に成功した場合、ステップＳ２０４へ進む。認証に失敗した場合、ステップＳ２０５へ戻る。【００５５】
次に、サーバ側の装置に関する別の例について説明する。図４に本例におけるサーバ側のシステム構成を示す。本例では、サーバ側の装置として、シングルサインオンを実現するためのシングルサインオン機能提供サーバ１０と、コンテンツサービス等のサービス提供を行うサービス提供サーバ２０が備えられる。シングルサインオン機能提供サーバ１０とサービス提供サーバ２０とを含むシステムをサーバ装置と称してもよい。なお、シングルサインオン機能提供サーバ１０もコンテンツサービス提供等のサービスを提供してよいが、以下の説明では、シングルサインオン機能提供サーバ１０がコンテンツサービス提供等のサービスを提供する処理については示していない。【００５６】
次に、クライアント装置１、シングルサインオン機能提供サーバ１０、及びサービス提供サーバ２０間において、サービス提供サーバ２０がクライアント装置１にサービスを提供するまでの処理の例について、図５、図６のシーケンス図を用いて説明する。なお、以下に説明するサーバ側での処理自体は、例えば、Liberty Alliance Projectにより提案されている方式に基づくものである。【００５７】
また、以下、シングルサインオン機能提供サーバ１０には、シングルサインオン機能提供サーバ用にクライアント装置１のユーザのアカウント情報が登録され、サービス提供サーバ２０には、サービス提供サーバ用にユーザのアカウント情報が登録されているものとする。【００５８】
まず、シングルサインオン機能提供サーバ１０とサービス提供サーバ２０間でアカウント連携を行うまでの処理の一例を図５を参照して説明する。【００５９】
クライアント装置１は、ユーザ操作に基づき、シングルサインオン機能提供サーバ１０にアクセスし、シングルサインオン機能提供サーバ１０に対してアカウント情報を送信することにより、シングルサインオン機能提供サーバ１０に対してログインを行う（ステップＳ５０１）。シングルサインオン機能提供サーバ１０は、認証に成功し、シングルサインオン機能提供サーバ１０により認証が行われた状態にあることを示す情報であって、シングルサインオン機能提供サーバ１０を識別する識別情報を含む情報をユーザのアカウント情報とともに保持し、更に当該情報をクライアント装置１に送信する（ステップＳ５０２）。【００６０】
クライアント装置１では当該情報がＳＶ情報管理部における記憶部に格納される。この情報は、本発明に係る機能を使用しない場合、クライアント装置１において現在実行されているアプリケーションのみが使用可能であるように格納される情報である。この情報はクライアント装置１とシングルサインオン機能提供サーバ１０とのつながりを示す情報であり、これまでに説明している連携ＩＤに相当する情報である。以下、この情報を連携ＩＤと呼ぶことにする。【００６１】
その後、クライアント装置１は、サービス提供サーバ２０にアクセスし、アカウント情報を送信することによりサービス提供サーバ２０に対してログインを行う（ステップＳ５０３）。サービス提供サーバ２０は、認証（サービス提供サーバ２０における初期認証）を行い、認証に成功する。上記ログインのための情報には連携IDが含まれており、サービス提供サーバ２０は、当該連携IDを参照することによりシングルサインオン機能提供サーバ１０を識別し、そのシングルサインオン機能提供サーバ１０とアカウントの連携をするかどうかをユーザに伺うための画面をクライアント装置１に送信する（ステップＳ５０４）。【００６２】
クライアント装置１のユーザがアカウント連携を許可すると、その旨の情報がクライアント装置１からサービス提供サーバ２０に送信される（ステップＳ５０５）。その後、サービス提供サーバ２０と、シングルサインオン機能提供サーバ１０間にてアカウント連携処理がなされる（ステップＳ５０６）。【００６３】
なお、アカウント連携にあたっては、実際のユーザのアカウント情報のやりとりはなされず、ユーザ識別子（仮名）がやりとりされる。アカウント連携により、シングルサインオン機能提供サーバ１０は、ユーザのシングルサインオン機能提供サーバ１０におけるアカウント情報とユーザ識別子を対応付けて保持し、サービス提供サーバ２０はユーザのサービス提供サーバ２０におけるアカウント情報とユーザ識別子とを対応付けて保持する。【００６４】
その後、クライアント装置１はサービス提供サーバ２０のサービスを利用するための処理に進んでもよいし、他のサイトにアクセスしてもよい。【００６５】
次に、サービス提供サーバ２０により上記のようにしてユーザの初期認証が済み、アカウント連携が済んでいる場合に、クライアント装置１がサービス提供サーバ２０からサービスを受けるまでの処理の例を図６を参照して説明する。ここでの処理はいわゆるシングルサインオンに係る処理である。ユーザがシングルサインオン機能提供サーバ１０にログインするだけで、サービス提供サーバ２０にログイン認証を行うことなくサービス提供サーバ２０でのサービスを受けることができる。【００６６】
図６のステップＳ６０１において、図５のステップＳ５０１の処理と同様にして、クライアント装置１は、シングルサインオン機能提供サーバ１０にログインを行う。そして、図５のステップＳ５０２と同様にして、連携ＩＤがシングルサインオン機能提供サーバ１０からクライアント装置１に返される（ステップＳ６０２）。【００６７】
このとき、例えば、シングルサインオン機能提供サーバ１０がクライアント装置１に対して表示する画面にサービス提供サーバ２０へのリンクが記載されており、ユーザがそのリンクを選択することでクライアント装置１はサービス提供サーバ２０にアクセスする（ステップＳ６０３）。クライアント装置１からサービス提供サーバ２０に送信される情報には連携IDが含まれ、サービス提供サーバ２０は、その連携ＩＤにより識別されるシングルサインオン機能提供サーバ１０に対して認証要求を送信するよう指示するリダイレクト要求をクライアント装置１に送信する（ステップＳ６０４）。リダイレクト要求を受けたクライアント装置１は、連携ＩＤを含む認証要求をシングルサインオン機能提供サーバ１０に送信する（ステップＳ６０５）。【００６８】
シングルサインオン機能提供サーバ１０は、連携IDによりユーザのアカウントを識別し、ユーザ識別子（仮名）を取得して、ユーザ識別子を含む、認証が確認できたことを示す認証アサーション情報をクライアント装置１を介してサービス提供サーバ２０に送る（ステップＳ６０６、Ｓ６０７）。サービス提供サーバ２０は、認証アサーション情報により当該ユーザが認証されていることを確認して、サービスの提供を開始する（ステップＳ６０８）。【００６９】
上記の例において、クライアント装置１は、シングルサインオン機能提供サーバ１０に対して認証要求を送信する機能部と、シングルサインオン機能提供サーバ１０において前記認証要求に対する認証に成功した場合に、連携ＩＤをシングルサインオン機能提供サーバ１０から受信する機能部とを有する。これらの機能部は、クライアント装置１において実行される認証プログラムにより実現される。【００７０】
上記の図６の例において、例えば、クライアント装置１においてアプリケーションＡを用いてシングルサインオン機能提供サーバ１０でのログインを行い、連携ＩＤを取得したものとする。その連携ＩＤはアプリケーションＡに対応するＳＶ情報管理部により管理されている。そして、例えば、サービス提供サーバ２０が提供するサービスをアプリケーションＡが利用できない場合において、当該サービスを利用できるアプリケーションＢが起動され、アプリケーションＢがアプリケーションＡ側から連携ＩＤを取得する。そして、アプリケーションＢがサービス提供サーバ２０へのアクセスを行うことにより、アプリケーションＢはサービス提供サーバ２０へのログイン認証を行うことなくサービスの提供を受けることができる。なお、上記のアプリケーションＢの起動は、アプリケーションＡによりなされる場合がある。【００７１】
なお、いうまでもなく、本発明に適用できるシングルサインオンの方式は、これまでに説明した方式に限られるわけではない。本発明に適用できるシングルサインオンの方式としては、クライアント装置１とサーバ側との間のつながりを示す情報を用いてシングルサインオンを行う方式であればよい。【００７２】
本実施形態におけるクライアント装置のアプリケーション間連携処理の例を図７に基づいて説明する。なお、以下の説明で、図１中の符号と同じものの説明は省略する。【００７３】
例えば、上記のようにアプリケーションＢが、アプリケーションＡによって起動されている場合、アプリケーションＢが起動元のアプリケーションＡを判別できるものとする。そして、アプリケーションＢが、連携ＩＤが必要になったときに、サーバ装置２との認証を済ませているアプリケーション（即ち、サーバ装置２から既に連携ＩＤを取得しているアプリケーションＡ）に連携ＩＤ要求を通知するものとする。【００７４】
まず、クライアント装置１にインストールされたアプリケーションＡに対応するＡＰ判定部Ａｄは、アプリケーションＢ側からの連携ＩＤ要求を受領する（Ｓ３０１）。なお、アプリケーションＢ自身が連携ＩＤ要求を送出する機能を備えてもよいし、アプリケーションＢのアプリケーション側認証機能部内に連携ＩＤ要求を送出する機能を備えてもよい。そして、ＡＰ判定部Ａｄは、受領した連携ＩＤ要求に基づいてアプリケーションＢが登録済みか否かを判定する（Ｓ３０２）。例えば、ＡＰ情報管理部Ａｂに連携ＩＤ要求に含まれるアプリケーション名（即ち、アプリケーションＢのアプリケーション名）が登録されていれば、ＡＰ判定部Ａｄは、アプリケーションＢは登録済みと見做す。ＡＰ情報管理部Ａｂに連携ＩＤ要求に含まれるアプリケーション名が登録されていなければ、アプリケーションＢは未登録と見做す。登録済みであった（即ち、要求が登録済みのアプリケーション（例えば、アプリケーションＢ）からの要求であった）場合、ＡＰ判定部Ａｄは、ＳＶ情報管理部Ａａに対して検索要求を通知し、ステップＳ３０３へ進む。未登録であった（即ち、連携ＩＤ要求が未登録のアプリケーションからの要求であった）場合、当該処理を終了するか、若しくは、エラーを返却する。エラー返却の場合、例えば、ＡＰ判定部ＡｄがエラーをアプリケーションＢに通知し、アプリケーションＢがエラーを示すメッセージ等を表示する。【００７５】
ステップＳ３０３では、ＡＰ判定部Ａｄは、前記検索要求に対する結果（例えば、連携ＩＤ）を要求元のアプリケーション（例えば、アプリケーションＢ）へ返却する。【００７６】
そして、連携ＩＤを受け取ったアプリケーションＢは、それをＳＶ情報管理部Ｂａにおける記憶部に格納するとともに、サーバ装置２に対し、該連携ＩＤを送信し、サーバ装置２から認証済みを返信されると、サインオンを完了とする。【００７７】
なお、アプリケーション側認証機能部（即ち、ＳＶ情報管理部，ＡＰ情報管理部，ＡＰ判定部，ＡＰ起動部，ＡＰ情報登録部）は、アプリケーションごとに備えられていなくても良い。また、図１に示す例では、アプリケーション側認証機能部のすべての機能部をアプリケーション外部に置いたが、アプリケーション側認証機能の一部のみをアプリケーション外部に置き、残りをアプリケーションの内部に置くこととしてもよい。【００７８】
ここで、アプリケーション側認証機能部をアプリケーションの外部に置き、複数アプリケーション間で共有した場合の構成例を図８に基づいて説明する。この構成例では、ＳＶ情報管理部，ＡＰ情報管理部，ＡＰ判定部及び連携ＩＤを複数アプリケーション間で共有する。この場合、例えば、ＳＶ情報管理部における記憶部は、各アプリケーション毎に連携ＩＤが記憶され、ＡＰ情報管理部の記憶部には各アプリケーション毎にアプリケーション情報が記憶される。そして、例えば、アプリケーションＡに対する連携ＩＤがＳＶ情報管理部に格納されている場合において、アプリケーションＢが当該連携ＩＤを取得する場合には、ＡＰ判定部がアプリケーションＢからの連携ＩＤ要求を受領し、ＡＰ情報管理部の記憶部におけるアプリケーションＡに対応する領域を検索してアプリケーション情報を取得することになる。以降の処理は、前述した処理と同様である。【００７９】
また、例えば、ＳＶ情報管理部，ＡＰ情報管理部，ＡＰ判定部を別のアプリケーション（例えばアプリケーションＡとアプリケーションＢのうちのアプリケーションＡのみ）に備えさせ、そのアプリケーションに対して他のアプリケーションから連携ＩＤに関する手続きや通信を行うこととしてよい。【００８０】
図８中のクライアント装置１には、アプリケーションＡ及びＢがインストールされているものとする。例えば、クライアント装置１はセットトップボックスを想定できる。アプリケーションＡ及びＢは、互いに異なる構造化言語を解釈実行するブラウザアプリケーションであって、例えば、アプリケーションＡはＨＴＭＬブラウザ、アプリケーションＢはＢＭＬブラウザである。【００８１】
例えば、ＳＶ情報管理部ａ及びＡＰ情報管理部ｂにおけるそれぞれの記憶部として、ＩＣ（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）カード，ＳＤ（Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ）メモリーカード等の外部メモリ、もしくはＪＡＶＡ（登録商標）アプリケーションの内部メモリ領域などを用いることが可能である。【００８２】
なお、上記実施形態における認証システム及び認証装置、その認証システム及び認証装置における各部の一部もしくは全部の機能をコンピュータのプログラムで構成し、そのプログラムをコンピュータを用いて実行して本発明を実現することができる。また、上記実施形態における認証システム及び認証装置に関する処理の手順をコンピュータのプログラムで構成し、そのプログラムをコンピュータに実行させることができる。【００８３】
以上のように、本実施形態によれば、既存の放送サービス用のアプリケーションであるＢＭＬブラウザとＨＴＭＬブラウザ間の通信においてもシングルサインオンを実現することが可能になるため、ユーザの利便性を向上する。【００８４】
以上、本発明において、記載された具体例に対してのみ詳細に説明したが、本発明の技術思想の範囲で多彩な変形および修正が可能であることは、当業者にとって明白なことであり、このような変形および修正が特許請求の範囲に属することは当然のことである。【００８５】
例えば、本実施形態の変形として、ＳＶ情報管理部とＡＰ情報管理部のそれぞれを汎用的なデータベースで実現することもできる。
【図１】
2009107219.tif 000003
【図２】
2009107219.tif 000004
【図３】
2009107219.tif 000005
【図４】
2009107219.tif 000006
【図５】
2009107219.tif 000007
【図６】
2009107219.tif 000008
【図７】
2009107219.tif 000009
【図８】
2009107219.tif 000010
【国際調査報告】
2009107219.tif 000011
2009107219.tif 000012
2009107219.tif 000013
2009107219.tif 000014