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