アクセス制御システム及びアクセス制御方法
【課題】一時的な信頼関係をオンデマンドに結ぶことを課題とする。
【解決手段】セッション連携サーバは、複数の利用者間で通信が確立されると、この通信を識別する通信情報を取得し、通信中の利用者同士をＷｅｂサーバにおいて紐付けるための発着間紐付けＩＤを、署名付証明書を添付して発行する。Ｗｅｂサーバは、セッション連携サーバによって発行された発着間紐付けＩＤを受信すると、その正当性を検証する。そして、Ｗｅｂサーバは、正当性が検証された発着間紐付けＩＤとともに、ＨＧＷにアクセスする。すると、ＨＧＷは、Ｗｅｂサーバからのアクセスが発着間紐付けＩＤとともに行われたことを条件として、アクセスを受け付ける。Ｗｅｂサーバは、発着間紐付けＩＤに基づいて複数の情報表示端末間でＷｅｂセッションを連携するとともに、アクセスの結果をこのＷｅｂセッションに反映する。
【解決手段】セッション連携サーバは、複数の利用者間で通信が確立されると、この通信を識別する通信情報を取得し、通信中の利用者同士をＷｅｂサーバにおいて紐付けるための発着間紐付けＩＤを、署名付証明書を添付して発行する。Ｗｅｂサーバは、セッション連携サーバによって発行された発着間紐付けＩＤを受信すると、その正当性を検証する。そして、Ｗｅｂサーバは、正当性が検証された発着間紐付けＩＤとともに、ＨＧＷにアクセスする。すると、ＨＧＷは、Ｗｅｂサーバからのアクセスが発着間紐付けＩＤとともに行われたことを条件として、アクセスを受け付ける。Ｗｅｂサーバは、発着間紐付けＩＤに基づいて複数の情報表示端末間でＷｅｂセッションを連携するとともに、アクセスの結果をこのＷｅｂセッションに反映する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アクセス制御システム及びアクセス制御方法に関する。
【背景技術】
【０００２】
近年、ＩＰ（Internet Protocol）ネットワークに接続するＷｅｂサーバ間において、「サークル・オブ・トラスト（信頼の輪）」と称される信頼関係が結ばれることがある。「サークル・オブ・トラスト」が結ばれると、例えば、利用者の認証情報がＷｅｂサーバ間で交換され、ＳＳＯ（Single Sign On）の実現が可能になる。かかる「サークル・オブ・トラスト」は、従来、事前に結ばれるものであり、例えば、第１の事業体と第２の事業体との間で証明書などを事前に交換することで結ばれる。
【０００３】
なお、事前に信頼関係を結ぶ必要のない「ＯｐｅｎＩＤ」という概念がある。利用者は、初めてＷｅｂサイトにアクセスする場合であっても、「ＯｐｅｎＩＤ」を入力するだけで、そのＷｅｂサイトにログインすることが可能である。もっとも、Ｗｅｂサイトが「ＯｐｅｎＩＤ」に対応していることが前提となる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−３５５０７３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、このような信頼関係は、必ずしもＷｅｂサーバ間において結ばれなければならないものではなく、また、必ずしも事前に結ばれなければならないものでもない。すなわち、信頼関係は、例えば、ＷｅｂサーバとＨＧＷ（Home Gate Way）との間において結ばれてもよい。また、例えば、Ｗｅｂサービスの利用中に限るなど、一時的な信頼関係がオンデマンド（On Demand）に結ばれてもよい。しかしながら、証明書などを事前に交換する従来の技術では、一時的な信頼関係をオンデマンドに結ぶことはできない。
【０００６】
本発明は、上記に鑑みてなされたものであって、一時的な信頼関係をオンデマンドに結ぶことが可能なアクセス制御システム及びアクセス制御方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上述した課題を解決し、目的を達成するために、アクセス制御システムは、セッション連携サーバ、Ｗｅｂサーバ、及び通信制御装置を含む。セッション連携サーバは、取得手段と、発行手段とを備える。取得手段は、複数の利用者間で通信が確立されると、該通信を識別する通信情報を取得する。発行手段は、前記通信情報を取得すると、該通信情報が示す複数の利用者が利用する複数の端末間でＷｅｂセッションを連携するための連携情報を発行し、発行した連携情報を、該連携情報の正当性を検証することが可能な形式でＷｅｂサーバに送信する。Ｗｅｂサーバは、検証手段と、アクセス手段と、連携手段とを備える。検証手段は、前記連携情報を受信すると、該連携情報の正当性を検証する。アクセス手段は、前記端末と前記Ｗｅｂサーバとの間の通信を制御する通信制御装置に、前記正当性が検証された連携情報とともにアクセスする。連携手段は、前記正当性が検証された連携情報に基づいて前記複数の端末間でＷｅｂセッションを連携するとともに前記アクセスの結果を該Ｗｅｂセッションに反映する。通信制御装置は、アクセス制御手段を備える。アクセス制御手段は、前記Ｗｅｂサーバからのアクセスが前記連携情報とともに行われたことを条件として、該アクセスを受け付ける。
【０００８】
上述した課題を解決し、目的を達成するために、アクセス制御方法は、セッション連携サーバ、Ｗｅｂサーバ、及び通信制御装置において、以下の工程を含む。セッション連携サーバは、取得工程と、発行工程とを含む。取得工程は、複数の利用者間で通信が確立されると、該通信を識別する通信情報を取得する。発行工程は、前記通信情報を取得すると、該通信情報が示す複数の利用者が利用する複数の端末間でＷｅｂセッションを連携するための連携情報を発行し、発行した連携情報を、該連携情報の正当性を検証することが可能な形式でＷｅｂサーバに送信する。Ｗｅｂサーバは、検証工程と、アクセス工程と、連携工程とを含む。検証工程は、前記連携情報を受信すると、該連携情報の正当性を検証する。アクセス工程は、前記端末と前記Ｗｅｂサーバとの間の通信を制御する通信制御装置に、前記正当性が検証された連携情報とともにアクセスする。連携工程は、前記正当性が検証された連携情報に基づいて前記複数の端末間でＷｅｂセッションを連携するとともに前記アクセスの結果を該Ｗｅｂセッションに反映する。通信制御装置は、アクセス制御工程を含む。アクセス制御工程は、前記Ｗｅｂサーバからのアクセスが前記連携情報とともに行われたことを条件として、該アクセスを受け付ける。
【発明の効果】
【０００９】
本発明によれば、一時的な信頼関係をオンデマンドに結ぶことが可能になるという効果を奏する。
【図面の簡単な説明】
【００１０】
【図１】図１は、実施例１に係るアクセス制御システムの概要を説明するための図である。
【図２】図２は、実施例１に係るアクセス制御システムによる処理手順を示すシーケンス図である。
【図３】図３は、実施例１に係るＨＧＷの構成を示すブロック図である。
【図４】図４は、実施例１に係るＳＩＰフォンの構成を示すブロック図である。
【図５】図５は、実施例１に係る情報表示端末の構成を示すブロック図である。
【図６】図６は、実施例１に係るセッション連携サーバの構成を示すブロック図である。
【図７】図７は、制御用セッション情報管理テーブルを説明するための図である。
【図８】図８は、発着間紐付けＩＤ管理テーブルを説明するための図である。
【図９】図９は、実施例１に係るＷｅｂサーバの構成を示すブロック図である。
【図１０】図１０は、実施例２に係るアクセス制御システムによる処理手順を示すシーケンス図である。
【図１１】図１１は、実施例３に係るセッション連携サーバの構成を示すブロック図である。
【図１２】図１２は、実施例３に係るアクセス制御システムによる処理手順を示すシーケンス図である。
【発明を実施するための形態】
【００１１】
以下、本発明に係るアクセス制御システム及びアクセス制御方法の実施例を説明する。なお、以下の実施例により本発明が限定されるものではない。
【実施例１】
【００１２】
［実施例１に係るアクセス制御システムの概要］
実施例１に係るアクセス制御システムの概要を説明する。まず、実施例１に係るアクセス制御システムは、通話中の利用者間でＷｅｂセッションの連携が行われるシステムを前提としている。すなわち、利用者は、通話中であれば、Ｗｅｂページの閲覧を通話相手と連携することができる。例えば、通話中、一方の利用者が、自身が閲覧するＷｅｂページをリンク先に遷移させると、他方の利用者が閲覧するＷｅｂページも、リンク先のＷｅｂページに自動的に遷移する。
【００１３】
さて、実施例１に係るアクセス制御システムは、このようなシステムを前提に、「通話中である」という事実に基づいて、Ｗｅｂサーバと、利用者が所属するネットワークのＨＧＷ（通信制御装置とも称する）との間に、一時的な信頼関係をオンデマンドに結ぶ。ＷｅｂサーバとＨＧＷとの間に一時的な信頼関係が結ばれた結果、ＷｅｂサーバからＨＧＷへのアクセスが一時的に許容される。すると、例えば、Ｗｅｂサーバは、ＨＧＷに記憶された情報を取得し、取得した情報を用いたＷｅｂページを利用者に提供する。
【００１４】
サービスイメージの一例を挙げる。例えば、一方の利用者は、Ａ社のコールセンタであり、他方の利用者は、Ａ社のＰＣ（Personal Computer）を購入した顧客である。例えば、Ａ社のＰＣがＤＬＮＡ（Digital Living Network Alliance）などの規格に準拠しており、顧客のネットワークにＰＣが接続された際に、顧客側のＨＧＷに、Ａ社のＰＣに関する情報（型番、仕様など）が自動で格納されたとする。そして、ＰＣの操作中、不具合が発生したため、顧客が、コールセンタに電話をかけたとする。両者が通話中、コールセンタが運用するＷｅｂサーバと、顧客側のＨＧＷとの間には、一時的な信頼関係がオンデマンドに結ばれる。すると、コールセンタが運用するＷｅｂサーバは、ＨＧＷにアクセスし、ＰＣに関する情報（型番、仕様など）を取得する。そして、Ｗｅｂサーバは、例えば取得した情報に基づいて、そのＰＣに合致する取り扱い説明書を選択し、選択した取り扱い説明書のＷｅｂページの閲覧が、コールセンタと顧客との間で連携されるように、Ｗｅｂセッションを制御する。なお、上記サービスイメージは一例に過ぎず、アクセスの結果、どのようにサービスが提供され、どのようにＷｅｂセッションが連携されるかは、任意に変更され得るものである。
【００１５】
図１は、実施例１に係るアクセス制御システムの概要を説明するための図である。図１に示すように、実施例１に係るアクセス制御システムは、セッション連携サーバと、Ｗｅｂサーバとを備える。ここで、セッション連携サーバとＷｅｂサーバとの間においては、事前に信頼関係が結ばれている（図１において点線の枠で示す）。
【００１６】
上述したように、実施例１に係るアクセス制御システムは、「通話中である」という事実に基づいて、ＷｅｂサーバとＨＧＷとの間に一時的な信頼関係をオンデマンドに結ぶ。セッション連携サーバは、この「通話中である」という事実を管理する役割を担う。
【００１７】
具体的には、図１に示すように、セッション連携サーバは、複数の利用者間で通話が確立されると、この通話を識別する通話情報（通信情報とも称する）を取得する。例えば、セッション連携サーバは、各ＨＧＷによって収集された通話情報を各ＨＧＷから取得する。また、例えば、セッション連携サーバは、通話情報を、通話を制御するＳＩＰ（Session Initiation Protocol）サーバ（図１において図示を省略）から直接取得してもよい。
【００１８】
次に、セッション連携サーバは、通話情報を取得すると、この通話情報が示す複数の利用者が利用する複数の情報表示端末間でＷｅｂセッションを連携するための連携情報（以下、発着間紐付けＩＤ）を発行する。すなわち、Ｗｅｂセッションの連携はＷｅｂサーバにおいて行われるが、Ｗｅｂサーバは、どの情報表示端末が、互いに通話中の利用者が利用する情報表示端末であるかを識別することができない。そこで、セッション連携サーバは、通話中の利用者同士を紐付けるための発着間紐付けＩＤを発行し、Ｗｅｂサーバは、発着間紐付けＩＤを用いることで、互いに通話中の利用者が利用する情報表示端末を識別する。なお、発着間紐付けＩＤがどのように用いられるかという点については後述する。
【００１９】
さて、セッション連携サーバは、発行した発着間紐付けＩＤを、その正当性を検証することが可能な形式で、Ｗｅｂサーバに送信する。例えば、セッション連携サーバは、発着間紐付けＩＤに、セッション連携サーバ自身の署名付証明書を添付する。
【００２０】
一方、Ｗｅｂサーバは、発着間紐付けＩＤを受信すると、発着間紐付けＩＤの正当性を検証する。例えば、Ｗｅｂサーバは、証明書に含まれるセッション連携サーバの公開鍵（認証局によって真正な公開鍵であることは証明されている）を利用して署名を復号することで、発着間紐付けＩＤの正当性を検証する。
【００２１】
そして、Ｗｅｂサーバは、正当性が検証された発着間紐付けＩＤとともに、ＨＧＷに対してアクセスする。すると、ＨＧＷは、Ｗｅｂサーバからのアクセスが発着間紐付けＩＤとともに行われたことを条件として、アクセスを受け付ける。
【００２２】
こうして、Ｗｅｂサーバは、発着間紐付けＩＤに基づいて複数の情報表示端末間でＷｅｂセッションを連携するとともに、ＨＧＷにアクセスした結果をＷｅｂセッションに反映する。
【００２３】
［実施例１に係るアクセス制御システムによる処理手順］
次に、図２を用いて、実施例１に係るアクセス制御システムによる処理手順を説明する。図２は、実施例１に係るアクセス制御システムによる処理手順を示すシーケンス図である。なお、図２に示す点線の枠は、利用者が所属するネットワークを示し、点線の枠の外は、インターネットなどの広域ネットワークを示す。図２に示すように、利用者が所属するネットワークにはＨＧＷ１０が設置され、ＨＧＷ１０が、ネットワーク内の情報表示端末２０やＳＩＰフォン３０による通信を制御する。また、広域ネットワークには、セッション連携サーバ１００、Ｗｅｂサーバ２００、及びＳＩＰサーバが設置される。
【００２４】
図２に示すように、アクセス制御システムにおいて、まず、複数の利用者間で通話が確立される（ステップＳ１０１）。すなわち、ＳＩＰフォン３０間で通信が確立される。なお、ＳＩＰサーバが、ＳＩＰフォン３０間の通信を制御する。
【００２５】
複数の利用者間で通話が確立されると、実施例１に係るＨＧＷ１０は、この通話を識別するｃａｌｌセッション情報を収集する（ステップＳ１０２）。例えば、ＨＧＷ１０は、ＳＩＰによって確立された通信に含まれる情報から、『Ｃａｌｌ−ＩＤ』、『Ｆｒｏｍ（ＳＩＰ−ＵＲＩ（Uniform Resource Identifier））』及び『Ｔｏ（ＳＩＰ−ＵＲＩ）』を収集する。なお、実施例１に係るＨＧＷ１０は、ｃａｌｌセッション情報を収集する他に、確立された通話の発側であるか着側であるかを判定し、発着を示す発着判定フラグを生成する。この発着判定フラグは、例えば、Ｗｅｂサーバ２００がＨＧＷ１０にアクセスする際や情報表示端末２０にサービスを提供する際に、発着を区別するために用いられるものであり、必ずしも必須なものではない。
【００２６】
続いて、ＨＧＷ１０は、自ＨＧＷ１０にポーリングを行う配下の情報表示端末２０に対して、セッション連携サーバ１００のＵＲＬ（Uniform Resource Locator）に接続先を変更するよう指示するリダイレクト指示を、ｃａｌｌセッション情報及び発着判定フラグとともに行う（ステップＳ１０３）。
【００２７】
すると、情報表示端末２０はリダイレクトされ、接続先を、ＨＧＷ１０からセッション連携サーバ１００に変更する（ステップＳ１０３）。このとき、情報表示端末２０は、ｃａｌｌセッション情報及び発着判定フラグを、セッション連携サーバ１００に送信する。
【００２８】
一方、セッション連携サーバ１００は、ｃａｌｌセッション情報及び発着判定フラグを受信すると、同じ通話を識別するｃａｌｌセッション情報の送信元である複数の情報表示端末２０間でＷｅｂセッションを連携するための発着間紐付けＩＤを発行する（ステップＳ１０４）。
【００２９】
そして、セッション連携サーバ１００は、発着間紐付けＩＤを、その正当性を検証することが可能な形式で、Ｗｅｂサーバ２００に送信する（ステップＳ１０５）。例えば、セッション連携サーバ１００は、発着間紐付けＩＤに、セッション連携サーバ１００自身の署名付証明書を添付する。また、実施例１に係るセッション連携サーバ１００は、発着間紐付けＩＤとともに発着判定フラグも送信する。なお、発着判定フラグの送信は、上述したように、必ずしも必須なものではない。
【００３０】
また、セッション連携サーバ１００は、発着間紐付けＩＤ及び発着判定フラグを、情報表示端末２０にてリダイレクトされるようにＷｅｂサーバ２００に送信する。情報表示端末２０にてリダイレクトされてＷｅｂサーバ２００に送信されることによって、Ｗｅｂサーバ２００は、ＨＧＷ１０のＩＰアドレス、並びに、情報表示端末２０（情報表示端末２０のＷｅｂブラウザに付与されたブラウザセッション情報）と発着間紐付けＩＤ及び発着判定フラグとの対応関係を把握することができる。
【００３１】
Ｗｅｂサーバ２００は、情報表示端末２０にてリダイレクトされて送信された発着間紐付けＩＤ及び発着判定フラグを受信すると、この発着間紐付けＩＤの正当性を検証する（ステップＳ１０６）。例えば、Ｗｅｂサーバ２００は、添付された証明書に含まれるセッション連携サーバ１００の公開鍵を利用して署名を復号することで、発着間紐付けＩＤの正当性を検証する。
【００３２】
そして、Ｗｅｂサーバ２００は、正当性が検証された発着間紐付けＩＤとともに、ＨＧＷ１０に対してアクセスする（ステップＳ１０７）。このアクセスには、ステップＳ１０５において取得されたＨＧＷ１０のＩＰアドレスが用いられる。また、Ｗｅｂサーバ２００は、必要に応じて、どちらのＨＧＷ１０にアクセスすべきかなどについて、発着判定フラグを用いて判定する。なお、図２においては、ステップＳ１０７のアクセス時にも、発着間紐付けＩＤに署名付証明書が添付されている。この場合、例えばＨＧＷ１０側においても、発着間紐付けＩＤの正当性を検証することが可能である。もっとも、ステップＳ１０７のアクセス時には、署名付証明書を添付しなくてもよい。
【００３３】
すると、ＨＧＷ１０は、Ｗｅｂサーバ２００からのアクセスが発着間紐付けＩＤとともに行われたことを条件として、アクセスを受け付け、例えば、Ｗｅｂサーバ２００は、ＨＧＷ１０に記憶された個人情報を取得する（ステップＳ１０８）。
【００３４】
こうして、Ｗｅｂサーバ２００は、発着間紐付けＩＤに基づいて複数の情報表示端末２０間でＷｅｂセッションを連携するとともに、ＨＧＷ１０にアクセスした結果をＷｅｂセッションに反映する（ステップＳ１０９）。例えば、Ｗｅｂサーバ２００は、情報表示端末２０からＷｅｂページ取得要求を受け付けると（ステップＳ１１０）、ＨＧＷ１０から取得した個人情報を用いたＷｅｂページを返信する（ステップＳ１１１）。なお、Ｗｅｂサーバ２００は、ステップＳ１０５において、情報表示端末２０のＷｅｂブラウザに付与されたブラウザセッション情報と、発着間紐付けＩＤ及び発着判定フラグとの対応関係を把握している。このため、Ｗｅｂサーバ２００は、その後、発着間紐付けＩＤが一致する複数の情報表示端末２０間でＷｅｂコンテンツを連携するように制御することができる。
【００３５】
なお、上述した処理手順は一例に過ぎない。例えば、ステップＳ１０９のＷｅｂコンテンツの連携が開始された後に、ステップＳ１０７及びＳ１０８のアクセスが行われてもよい。
【００３６】
［実施例１に係るアクセス制御システムの構成］
次に、図３〜図９を用いて、実施例１に係るアクセス制御システムの構成を説明する。以下、ＨＧＷ１０、ＳＩＰフォン３０、情報表示端末２０、セッション連携サーバ１００、Ｗｅｂサーバ２００の順に説明する。
【００３７】
［ＨＧＷ１０］
図３は、実施例１に係るＨＧＷ１０の構成を示すブロック図である。ＨＧＷ１０は、図２を用いて説明した処理手順などを実行する各部が、汎用的なゲートウェイ装置などに備えられることによって実現される。ＨＧＷ１０は、例えば、ＳＩＰ通信部／ＨＴＴＰ（Hyper Text Transfer Protocol）通信部１１と、記憶部１２と、制御部１３とを備える。
【００３８】
ＳＩＰ通信部／ＨＴＴＰ通信部１１は、ＳＩＰ用及びＨＴＴＰ通信用の一般的なインタフェース及びライブラリを備える。ＳＩＰ通信部／ＨＴＴＰ通信部１１は、ＳＩＰフォン３０とＳＩＰサーバとの間の通信、情報表示端末２０とＷｅｂサーバ２００との間の通信、ＨＧＷ１０とＳＩＰサーバとの間の通信、ＨＧＷ１０とセッション連携サーバ１００との間の通信、ＨＧＷ１０とＷｅｂサーバ２００との間の通信などを制御する。
【００３９】
記憶部１２は、制御部１３における各種制御に用いられる情報を記憶し、個人情報等記憶部１２ａを有する。個人情報等記憶部１２ａは、例えば利用者の個人情報などを記憶する。例えば、記憶部１２は、ＲＡＭ（Random Access Memory）、フラッシュメモリ、ハードディスク、光ディスクなどで実現される。
【００４０】
制御部１３は、ＨＧＷ１０における各種制御を行い、ｃａｌｌセッション情報通知部１３ａと、アクセス受付部１３ｂとを有する。
【００４１】
ｃａｌｌセッション情報通知部１３ａは、ｃａｌｌセッション情報を収集し、収集したｃａｌｌセッション情報を、セッション連携サーバ１００に通知する。具体的には、ｃａｌｌセッション情報通知部１３ａは、ＳＩＰによって確立された通信に含まれる情報から、『Ｃａｌｌ−ＩＤ』、『Ｆｒｏｍ』及び『Ｔｏ（ＳＩＰ−ＵＲＩ）』を収集する。また、実施例１に係るｃａｌｌセッション情報通知部１３ａは、ｃａｌｌセッション情報を収集する他に、確立された通話の発側であるか着側であるかを判定し、発着を示す発着判定フラグを生成する。なお、ｃａｌｌセッション情報は、上述の情報に限られず、例えば、『Ｃａｌｌ−ＩＤ』もしくは『ｉｓｕｂ』、又は、『Ｆｒｏｍ』、『Ｔｏ』、『ｔａｇ』、ＩＰアドレス、もしくは、これらを組合せて実現される。また、ｃａｌｌセッション情報は、ＳＩＰ通信に含まれるその他の情報（例えば『Ｄａｔｅ』など）を組合せて実現される。なお、ＳＩＰによって確立された通信を一意に識別することが可能な情報を用いる手法であれば、どのような手法で実現してもよい。
【００４２】
そして、ｃａｌｌセッション情報通知部１３ａは、自ＨＧＷ１０にポーリングを行う情報表示端末２０に対して、セッション連携サーバ１００のＵＲＬに接続先を変更するよう指示するリダイレクト指示を、ｃａｌｌセッション情報及び発着判定フラグとともに行う。なお、ｃａｌｌセッション情報通知部１３ａは、例えば、セッション連携サーバ１００のＵＲＬ情報を予め記憶部１２に記憶することで、このリダイレクト指示を行う。
【００４３】
なお、ｃａｌｌセッション情報通知部１３ａがｃａｌｌセッション情報を収集する手法としては各種手法が考えられる。例えば、ｃａｌｌセッション情報通知部１３ａが、ＨＴＴＰ通信によってＳＩＰサーバにアクセスし、プル型でｃａｌｌセッション情報を収集する手法などでもよい。もっとも、この場合には、ＳＩＰサーバが、ｃａｌｌセッション情報の取得を希望するＨＧＷ１０について、ＩＰアドレスベースや回線ベースの認証など、何らかの認証手段によって認証することが望ましい。
【００４４】
アクセス受付部１３ｂは、Ｗｅｂサーバ２００からのアクセスが発着間紐付けＩＤとともに行われたことを条件として、Ｗｅｂサーバ２００からのアクセスを受け付ける。具体的には、アクセス受付部１３ｂは、Ｗｅｂサーバ２００からのアクセスを受け付けると、そのアクセスが、発着間紐付けＩＤとともに行われているか否かを判定する。そして、発着間紐付けＩＤとともに行われていると判定した場合に、アクセス受付部１３ｂは、Ｗｅｂサーバ２００とＨＧＷ１０との間に一時的な信頼関係が結ばれたものとして、Ｗｅｂサーバ２００からのアクセスを許容する。アクセス受付部１３ｂは、例えば個人情報等記憶部１２ａに記憶された情報の取得を許容する。
【００４５】
なお、アクセス受付部１３ｂは、Ｗｅｂサーバ２００からのアクセス時、発着間紐付けＩＤに署名付証明書が添付されている場合には、発着間紐付けＩＤの正当性を検証してもよい。例えば、アクセス受付部１３ｂは、証明書に含まれるセッション連携サーバ１００の公開鍵（認証局によって真正な公開鍵であることは証明されている）を利用して署名を復号し、発着間紐付けＩＤのハッシュ値を取り出す。また、アクセス受付部１３ｂは、発着間紐付けＩＤ自体からハッシュ値を算出する。そして、アクセス受付部１３ｂは、署名から取り出したハッシュ値と算出したハッシュ値とを照合することで、発着間紐付けＩＤが真正な情報であることを検証する。すなわち、署名から取り出したハッシュ値と算出したハッシュ値とを照合した結果、両者が一致すれば、(a)発着間紐付けＩＤが、確かにセッション連携サーバ１００から発行された情報であること、(b)発着間紐付けＩＤが、改竄されていないこと、(c)セッション連携サーバ１００が発着間紐付けＩＤを送信した事実を否認しないことなどの事実を検証することができ、発着間紐付けＩＤが真正な情報であることを検証することができる。
【００４６】
［ＳＩＰフォン３０］
図４は、実施例１に係るＳＩＰフォン３０の構成を示すブロック図である。ＳＩＰフォン３０は、例えば、入力部３２と、出力部３３と、入出力制御Ｉ／Ｆ部３４と、ＳＩＰ通信部３１とを備える。
【００４７】
いずれも汎用的なＳＩＰフォン３０と同様であるので簡単に説明すると、入力部３２は、ＳＩＰフォン３０に用いられる情報や、各種処理をするための操作指示などを、番号キーやマイクなどによって入力する。出力部３３は、ＳＩＰフォン３０による各種処理の結果や、各種処理をするための操作指示などを、ディスプレイやスピーカに出力する。入出力制御Ｉ／Ｆ部３４は、入力部３２と、出力部３３と、ＳＩＰ通信部３１との間における情報転送を制御する。ＳＩＰ通信部３１は、ＳＩＰ用の一般的なインタフェース及びライブラリを備え、他方のＳＩＰフォン３０との間で情報を送受信する。
【００４８】
［情報表示端末２０］
図５は、実施例１に係る情報表示端末２０の構成を示すブロック図である。情報表示端末２０は、図２を用いて説明した処理手順などを実行する各部が、汎用的なＰＣや情報家電などに備えられることによって実現される。情報表示端末２０は、例えば、入力部２２と、出力部２３と、入出力制御Ｉ／Ｆ部２４と、ＨＴＴＰ通信部２１と、制御部２５とを備える。
【００４９】
入力部２２は、情報表示端末２０に用いられる情報や、各種処理をするための操作指示などを、キーボード、マウス、リモコンなどによって入力する。出力部２３は、情報表示端末２０による各種処理の結果や、各種処理をするための操作指示などを、ディスプレイやプリンタなどに出力する。入出力制御Ｉ／Ｆ部２４は、入力部２２と、出力部２３と、ＨＴＴＰ通信部２１と、制御部２５との間における情報転送を制御する。ＨＴＴＰ通信部２１は、ＨＴＴＰ通信用の一般的なインタフェース及びライブラリを備え、Ｗｅｂサーバ２００との間で情報を送受信する。
【００５０】
制御部２５は、Ｗｅｂコンテンツ閲覧部２５ａを有する。例えば、Ｗｅｂコンテンツ閲覧部２５ａは、いわゆるＷｅｂブラウザによって実現され、ＨＧＷ１０に対してポーリングを行っている。また、Ｗｅｂコンテンツ閲覧部２５ａは、ＨＧＷ１０からリダイレクト指示を受けると、ＨＧＷ１０から受信したｃａｌｌセッション情報及び発着判定フラグをセッション連携サーバ１００に送信する。また、Ｗｅｂコンテンツ閲覧部２５ａは、セッション連携サーバ１００からリダイレクトされると、セッション連携サーバ１００から受信した発着間紐付けＩＤ及び発着判定フラグをＷｅｂサーバ２００に送信する。
【００５１】
このとき、Ｗｅｂコンテンツ閲覧部２５ａを実現するＷｅｂブラウザには、Ｗｅｂブラウザを識別するブラウザセッション情報が付与されており、Ｗｅｂサーバ２００は、ブラウザセッション情報を用いて情報表示端末２０を識別する。すなわち、ブラウザセッション情報は、情報表示端末２０とＷｅｂサーバ２００との間で確立されたＷｅｂセッション毎に生成され、情報表示端末２０とＷｅｂサーバ２００との間で確立されたＷｅｂセッションを一意に識別する情報である。ブラウザセッション情報は、例えばＷｅｂサーバ２００によって発行され、例えば『セッションＩＤ』（CookieのＩＤなど）で実現される。
【００５２】
また、Ｗｅｂコンテンツ閲覧部２５ａは、Ｗｅｂサーバ２００から送信されたＷｅｂページを出力部２３に出力する。
【００５３】
［セッション連携サーバ１００］
図６は、実施例１に係るセッション連携サーバ１００の構成を示すブロック図である。セッション連携サーバ１００は、図２を用いて説明した処理手順などを実行する各部が、汎用的なサーバなどに備えられることによって実現される。セッション連携サーバ１００は、例えば、通信部１１０と、記憶部１２０と、制御部１３０とを備える。
【００５４】
通信部１１０は、ＨＴＴＰ通信用の一般的なインタフェース及びライブラリを有し、ＨＧＷ１０、情報表示端末２０、Ｗｅｂサーバ２００との間で情報を送受信する。記憶部１２０は、制御部１３０における各種制御に用いられる情報を記憶する。記憶部１２０は、制御用セッション情報管理テーブル１２１と、発着間紐付けＩＤ管理テーブル１２２とを有する。例えば、記憶部１２０は、ＲＡＭ、フラッシュメモリ、ハードディスク、光ディスクなどで実現される。
【００５５】
制御用セッション情報管理テーブル１２１は、制御用セッション情報を管理する。具体的には、制御用セッション情報管理テーブル１２１は、制御用セッション情報を記憶し、制御用セッション情報管理テーブル１２１が記憶する制御用セッション情報は、後述する発着間紐付けＩＤ発行部１３２による処理に利用される。
【００５６】
図７は、制御用セッション情報管理テーブルを説明するための図である。例えば、制御用セッション情報管理テーブル１２１は、図７に示すように、制御用セッション情報と、ｃａｌｌセッション情報と、発着判定フラグとを対応付けて記憶する。
【００５７】
制御用セッション情報は、情報表示端末２０とセッション連携サーバ１００との間で確立されたセッション毎に生成され、情報表示端末２０とセッション連携サーバ１００との間で確立されたセッションを一意に識別する情報である。制御用セッション情報は、後述するｃａｌｌセッション情報収集部１３１によって発行され、制御用セッション情報管理テーブル１２１に格納される。例えば、制御用セッション情報は、『セッションＩＤ』（CookieのＩＤなど）で実現される。なお、図７において、説明の便宜上、制御用セッション情報として規則的な数値が例示されているが、一般的には乱数などが格納される。
【００５８】
また、ｃａｌｌセッション情報は、ＳＩＰフォン３０間でＳＩＰによって確立された通信を一意に識別する情報である。ｃａｌｌセッション情報は、後述するｃａｌｌセッション情報収集部１３１によって収集され、制御用セッション情報管理テーブル１２１に格納される。また、図７において、説明の便宜上、ｃａｌｌセッション情報の『Ｃａｌｌ−ＩＤ』として規則的な数値が例示されているが、一般的には乱数などが格納される。
【００５９】
また、発着判定フラグは、ＳＩＰフォン３０間でＳＩＰによって確立された通信について、ＳＩＰフォン３０が発側であるのか着側であるのかを示すフラグである。後述するｃａｌｌセッション情報収集部１３１によって収集され、制御用セッション情報管理テーブル１２１に格納される。
【００６０】
発着間紐付けＩＤ管理テーブル１２２は、発着間紐付けＩＤを管理する。具体的には、発着間紐付けＩＤ管理テーブル１２２は、発着間紐付けＩＤを記憶する。
【００６１】
図８は、発着間紐付けＩＤ管理テーブルを説明するための図である。例えば、発着間紐付けＩＤ管理テーブル１２２は、図８に示すように、制御用セッション情報と、発着間紐付けＩＤとを対応付けて記憶する。
【００６２】
発着間紐付けＩＤは、ＳＩＰによって確立された通信を一意に識別するｃａｌｌセッション情報の仮名情報であり、通話を行っている利用者間でＷｅｂセッションを連携するための連携情報である。発着間紐付けＩＤは、後述する発着間紐付けＩＤ発行部１３２によって発行され、発着間紐付けＩＤ管理テーブル１２２に格納される。なお、図８に示すように、一般的には乱数などが格納される。
【００６３】
図６に戻り、制御部１３０は、ｃａｌｌセッション情報収集部１３１と、発着間紐付けＩＤ発行部１３２とを有する。
【００６４】
ｃａｌｌセッション情報収集部１３１は、ｃａｌｌセッション情報及び発着判定フラグを収集する。具体的には、ｃａｌｌセッション情報収集部１３１は、ＨＧＷ１０のｃａｌｌセッション情報通知部１３ａによって通知されることで、ｃａｌｌセッション情報及び発着判定フラグを収集する。そして、ｃａｌｌセッション情報収集部１３１は、制御用セッション情報を発行し、収集したｃａｌｌセッション情報及び発着判定フラグを、発行した制御用セッション情報と対応付けて、制御用セッション情報管理テーブル１２１に格納する。
【００６５】
発着間紐付けＩＤ発行部１３２は、発着間紐付けＩＤを発行し、発行した発着間紐付けＩＤを、その正当性を検証することが可能な形式でＷｅｂサーバ２００に送信する。具体的には、発着間紐付けＩＤ発行部１３２は、制御用セッション情報管理テーブル１２１に記憶されている複数のｃａｌｌセッション情報の中から同一の通信を示すｃａｌｌセッション情報を特定する。次に、発着間紐付けＩＤ発行部１３２は、特定したｃａｌｌセッション情報と対応付けて記憶されている２つの制御用セッション情報を特定する。そして、発着間紐付けＩＤ発行部１３２は、発着間紐付けＩＤを発行し、発行した発着間紐付けＩＤと特定した制御用セッション情報とを対応付けて発着間紐付けＩＤ管理テーブル１２２に格納する。
【００６６】
続いて、発着間紐付けＩＤ発行部１３２は、発行した発着間紐付けＩＤに、セッション連携サーバ１００の署名付証明書を添付する。ここで、発着間紐付けＩＤ発行部１３２は、署名付証明書を添付することにより、例えば、(a)発着間紐付けＩＤが、確かにセッション連携サーバ１００から発行された情報であること、(b)発着間紐付けＩＤが、改竄されていないこと、(c)セッション連携サーバ１００が発着間紐付けＩＤを送信した事実を否認しないことを保証する。これらをＷｅｂサーバ２００において検証することができれば、Ｗｅｂサーバ２００は、取得した発着間紐付けＩＤが信用できる情報（真正な情報）であることを確認することができる。
【００６７】
また、例えば、実施例１に係る発着間紐付けＩＤ発行部１３２は、署名付証明書を、ＳＡＭＬ（Security Assertion Markup Language）に規定する形式で記述する。ここで、ＳＡＭＬ形式とは、認証のための情報をＸＭＬ（Extensible Markup Language）で記述されたデータで交換することを目的として策定されたプロトコルであり、署名によって検証可能な形式である。発着間紐付けＩＤ発行部１３２は、セッション連携サーバ１００の公開鍵が真正であることを証明する認証局発行の証明書と、セッション連携サーバ１００の秘密鍵で発着間紐付けＩＤ（ハッシュ値）を暗号化した署名とを、ＳＡＭＬ形式で記述する。
【００６８】
［Ｗｅｂサーバ２００］
図９は、実施例１に係るＷｅｂサーバ２００の構成を示すブロック図である。Ｗｅｂサーバ２００は、図２を用いて説明した処理手順などを実行する各部が、汎用的なサーバなどに備えられることによって実現される。Ｗｅｂサーバ２００は、例えば、通信部２１０と、制御部２３０とを備える。
【００６９】
通信部２１０は、ＨＴＴＰ通信用の一般的なインタフェース及びライブラリを備え、セッション連携サーバ１００との間や、情報表示端末２０との間などで情報を送受信する。
【００７０】
制御部２３０は、発着間紐付けＩＤ検証部２３１と、ＨＧＷアクセス部２３２と、Ｗｅｂセッション連携部２３３とを有する。
【００７１】
発着間紐付けＩＤ検証部２３１は、セッション連携サーバ１００によって発行された発着間紐付けＩＤを検証する。具体的には、発着間紐付けＩＤ検証部２３１は、情報表示端末２０から発着間紐付けＩＤ及び発着判定フラグを受信する。発着間紐付けＩＤは、確立された通話毎に新しく払い出されるものであるので、発着間紐付けＩＤ検証部２３１は、各情報表示端末２０から発着間紐付けＩＤを受信した結果、２つの情報表示端末２０からは同じ発着間紐付けＩＤを受信することになる。
【００７２】
また、発着間紐付けＩＤ検証部２３１は、発着間紐付けＩＤに添付された署名付証明書を検証することで、発着間紐付けＩＤの正当性を検証する。例えば、発着間紐付けＩＤ検証部２３１は、証明書に含まれるセッション連携サーバ１００の公開鍵（認証局によって真正な公開鍵であることは証明されている）を利用して署名を復号し、発着間紐付けＩＤのハッシュ値を取り出す。また、発着間紐付けＩＤ検証部２３１は、発着間紐付けＩＤ自体からハッシュ値を算出する。そして、発着間紐付けＩＤ検証部２３１は、署名から取り出したハッシュ値と算出したハッシュ値とを照合することで、発着間紐付けＩＤが真正な情報であることを検証する。すなわち、署名から取り出したハッシュ値と算出したハッシュ値とを照合した結果、両者が一致すれば、(a)発着間紐付けＩＤが、確かにセッション連携サーバ１００から発行された情報であること、(b)発着間紐付けＩＤが、改竄されていないこと、(c)セッション連携サーバ１００が発着間紐付けＩＤを送信した事実を否認しないことなどの事実を検証することができ、発着間紐付けＩＤが真正な情報であることを検証することができる。
【００７３】
ＨＧＷアクセス部２３２は、正当性が検証された発着間紐付けＩＤとともに、ＨＧＷ１０にアクセスする。具体的には、ＨＧＷアクセス部２３２は、発着間紐付けＩＤ検証部２３１によって発着間紐付けＩＤが真正な情報であることが検証された場合には、この発着間紐付けＩＤとともに、ＨＧＷ１０にアクセスする。なお、ＨＧＷアクセス部２３２は、各情報表示端末２０から発着間紐付けＩＤ及び発着判定フラグを受信した際に取得されたＨＧＷ１０のＩＰアドレスを用いて、ＨＧＷ１０にアクセスする。また、ＨＧＷアクセス部２３２は、必要に応じて、どちらのＨＧＷ１０にアクセスすべきかなどについて、発着判定フラグを用いて判定する。
【００７４】
Ｗｅｂセッション連携部２３３は、正当性が検証された発着間紐付けＩＤに基づいて複数の情報表示端末２０間でＷｅｂセッションを連携するとともに、ＨＧＷアクセス部２３２によるアクセスの結果をＷｅｂセッションに反映する。具体的には、Ｗｅｂセッション連携部２３３は、発着間紐付けＩＤ検証部２３１によって正当性が検証された複数の発着間紐付けＩＤの中から、Ｗｅｂセッションを連携することを示す発着間紐付けＩＤ（同一の発着間紐付けＩＤ）を特定し、特定した発着間紐付けＩＤの送信元である情報表示端末２０各々に提供するＷｅｂコンテンツを連携するように、サービス提供を制御する。なお、Ｗｅｂセッション連携部２３３は、情報表示端末２０に付与されたブラウザセッション情報と、発着間紐付けＩＤ及び発着判定フラグとの対応関係を把握しているので、特定した発着間紐付けＩＤの送信元である情報表示端末２０各々に提供するＷｅｂセッションを連携するように、サービス提供を制御することができる。
【００７５】
［実施例１の効果］
上述したように、実施例１に係るアクセス制御システムは、セッション連携サーバ１００、Ｗｅｂサーバ２００、及びＨＧＷ１０を含む。セッション連携サーバ１００は、ｃａｌｌセッション情報収集部１３１と、発着間紐付けＩＤ発行部１３２とを備える。ｃａｌｌセッション情報収集部１３１は、複数の利用者間で通話が確立されると、この通話を識別するｃａｌｌセッション情報を取得する。発着間紐付けＩＤ発行部１３２は、ｃａｌｌセッション情報を取得すると、このｃａｌｌセッション情報が示す複数の利用者が利用する複数の情報表示端末２０間でＷｅｂセッションを連携するための発着間紐付けＩＤを発行し、発行した発着間紐付けＩＤを、この発着間紐付けＩＤの正当性を検証することが可能な形式でＷｅｂサーバ２００に送信する。Ｗｅｂサーバ２００は、発着間紐付けＩＤ検証部２３１と、ＨＧＷアクセス部２３２と、Ｗｅｂセッション連携部２３３とを備える。発着間紐付けＩＤ検証部２３１は、発着間紐付けＩＤを受信すると、この発着間紐付けＩＤの正当性を検証する。ＨＧＷアクセス部２３２は、情報表示端末２０とＷｅｂサーバ２００との間の通信を制御するＨＧＷ１０に、正当性が検証された発着間紐付けＩＤとともにアクセスする。Ｗｅｂセッション連携部２３３は、正当性が検証された発着間紐付けＩＤに基づいて複数の情報表示端末２０間でＷｅｂセッションを連携するとともに、アクセスの結果をＷｅｂセッションに反映する。ＨＧＷ１０は、アクセス受付部１３ｂを備える。アクセス受付部１３ｂは、Ｗｅｂサーバ２００からのアクセスが発着間紐付けＩＤとともに行われたことを条件として、アクセスを受け付ける。
【００７６】
このようなことから、実施例１によれば、「通話中である」という事実に基づいて、Ｗｅｂサーバ２００と、利用者が所属するネットワークのＨＧＷ１０との間に、一時的な信頼関係をオンデマンドに結ぶことが可能になる。
【実施例２】
【００７７】
次に、実施例２に係るアクセス制御システムを説明する。実施例２に係るアクセス制御システムは、実施例１に係るアクセス制御システムと同様の処理手順に加え、ＨＧＷ１０に対するＷｅｂサーバ２００からのアクセスを許容するか否かを利用者に確認する。すなわち、アクセス制御システムにおいて、Ｗｅｂサーバ２００からのアクセスが発着間紐付けＩＤとともに行われた場合には、ＨＧＷ１０は、無条件に、このアクセスを受け付ける。このようなことから、実施例２においては、利用者に事前確認をとることとする。
【００７８】
図１０は、実施例２に係るアクセス制御システムによる処理手順を示すシーケンス図である。図１０に示すように、セッション連携サーバ１００の発着間紐付けＩＤ発行部１３２は、発着間紐付けＩＤを発行する際に、ＨＧＷ１０に対するＷｅｂサーバ２００からのアクセスを許容するか否かを確認する確認画面を、情報表示端末２０に送信する（ステップＳ２０４）。例えば、発着間紐付けＩＤ発行部１３２は、「ホームゲートウェイにアクセスしますが、よろしいですか？」といった確認画面を送信する。
【００７９】
例えば、利用者が、情報表示端末２０の出力部２３に出力された確認画面を確認し、これに了承して例えばボタンを押下すると、その情報がセッション連携サーバ１００に送信される（ステップＳ２０５）。すると、発着間紐付けＩＤ発行部１３２は、利用者による確認が得られたとして、発着間紐付けＩＤを発行する。一方、利用者による確認が得られなかった場合には、発着間紐付けＩＤ発行部１３２は、発着間紐付けＩＤを発行しない。
【００８０】
なお、利用者に事前確認をとる処理手順は、図１０に例示した処理手順に限られない。図１０に例示した処理手順の場合、利用者による確認が得られなければ、発着間紐付けＩＤ発行部１３２は発着間紐付けＩＤを発行しないことになり、Ｗｅｂサーバ２００は、Ｗｅｂセッションの連携もできなくなってしまう。そこで、例えば、発着間紐付けＩＤ発行部１３２は、利用者による確認が得られなければ、その旨を情報として添付した発着間紐付けＩＤを発行してもよい。この場合、Ｗｅｂサーバ２００のＨＧＷアクセス部２３２は、ＨＧＷ１０へのアクセスを行わないようにする。一方、Ｗｅｂセッション連携部２３３は、Ｗｅｂセッションの連携を行うことができる。
【００８１】
また、図１０に例示した処理手順の場合、利用者のうち、発信者は、ＨＧＷ１０に対するアクセスを許容することを前提とし、着信者に、確認画面を送信した。しかしながらこれに限られるものではなく、発信者及び着信者の両者に確認画面を送信するようにしてもよい。
【００８２】
また、確認画面において、単にアクセスを許容するか否かを確認するだけでなく、アクセスに関する情報、例えば、アクセスすることを許容するディレクトリ、フォルダ、あるいは、実行を許容するコマンドの種別などを利用者に入力させてもよい。この場合、発着間紐付けＩＤ発行部１３２は、これらの情報を添付して、発着間紐付けＩＤを発行する。一方、ＨＧＷアクセス部２３２は、ＨＧＷ１０へアクセスする前に、発着間紐付けＩＤに添付されたこれらの情報を確認し、例えば、アクセスすることが許容されたディレクトリ、フォルダのみにアクセスする、また、例えば、実行を許容されたコマンドのみを実行する、といったように、アクセスを制御する。
【００８３】
また、図１０に例示した処理手順の場合、利用者に事前確認をとる処理手順は、セッション連携サーバ１００によって行われたが、Ｗｅｂサーバ２００に行わせてもよい。例えば、ＨＧＷアクセス部２３２は、ＨＧＷ１０へアクセスする前に、アクセスを許容するか否かを確認する確認画面を情報表示端末２０に対して送信し、利用者による確認が得られた場合にのみ、アクセスしてもよい。また、確認画面において、単にアクセスを許容するか否かを確認するだけでなく、アクセスに関する情報、例えば、アクセスすることを許容するディレクトリ、フォルダ、あるいは、実行を許容するコマンドの種別などを利用者に入力させてもよい。さらに、Ｗｅｂサーバ２００自身が送信する確認画面であるので、例えば、どのような情報を取得したいか、具体的に記載して、その情報の取得のために必要な情報（ディレクトリ、フォルダ、許容するコマンドの種別など）を入力してもらうようにしてもよい。
【実施例３】
【００８４】
次に、実施例３に係るアクセス制御システムを説明する。実施例３に係るアクセス制御システムは、実施例１に係るアクセス制御システムや実施例２に係るアクセス制御システムと同様の機能を有する他に、発着間紐付けＩＤを失効させる機能を有する。
【００８５】
図１１は、実施例３に係るセッション連携サーバ１００の構成を示すブロック図であり、図１２は、実施例３に係るアクセス制御システムによる処理手順を示すシーケンス図である。図１１に示すように、実施例３に係るセッション連携サーバ１００は、制御部１３０に、発着間紐付けＩＤ失効部１３３をさらに備える。発着間紐付けＩＤ失効部１３３は、複数の利用者間で確立された通話が切断されると、この通話を識別するｃａｌｌセッション情報を取得する。また、発着間紐付けＩＤ失効部１３３は、切断された通話を識別するｃａｌｌセッション情報を取得すると、このｃａｌｌセッション情報に関連付けて発行された発着間紐付けＩＤの失効を、Ｗｅｂサーバ２００に通知する。
【００８６】
例えば、図１２に示すように、複数の利用者間で確立された通話が切断されると（ステップＳ３０１）、ＨＧＷ１０が、切断された通話を識別するｃａｌｌセッション情報を収集し（ステップＳ３０２）、収集したｃａｌｌセッション情報を、セッション連携サーバ１００に送信する（ステップＳ３０３）。なお、ＨＧＷ１０は、例えば図２のステップＳ１０２及びＳ１０３と同様の手法で、これらの処理手順を実行することができる。また、ＨＧＷ１０は、切断された通話を識別するｃａｌｌセッション情報と、確立された通話を識別するｃａｌｌセッション情報とを区別するために、ｃａｌｌセッション情報に、何らかのフラグを付与すればよい。
【００８７】
そして、発着間紐付けＩＤ失効部１３３は、ｃａｌｌセッション情報を受信すると、受信したｃａｌｌセッション情報を用いて制御用セッション情報管理テーブル１２１を検索し、受信したｃａｌｌセッション情報に対応付けて記憶されている制御用セッション情報を特定する。また、発着間紐付けＩＤ失効部１３３は、特定した制御用セッション情報を用いて発着間紐付けＩＤ管理テーブル１２２を検索し、特定した制御用セッション情報に対応付けて記憶されている発着間紐付けＩＤを特定する。そして、発着間紐付けＩＤ失効部１３３は、特定した発着間紐付けＩＤは、失効すべき発着間紐付けＩＤであるとして、Ｗｅｂサーバ２００に通知する。
【００８８】
すると、Ｗｅｂサーバ２００のＨＧＷアクセス部２３２は、発着間紐付けＩＤ失効部１３３から所定の発着間紐付けＩＤの失効を通知されると、該当するＨＧＷ１０に対するアクセスを終了する。また、Ｗｅｂセッション連携部２３３は、発着間紐付けＩＤの失効を通知されると、通知された発着間紐付けＩＤを用いたＷｅｂセッションの連携を終了する。
【００８９】
このように、実施例３によれば、通話の切断とともに発着間紐付けＩＤの失効がＷｅｂサーバ２００に通知され、Ｗｅｂサーバ２００によるＨＧＷ１０へのアクセスも終了するので、「通話中である」との事実に基づいて一時的に結ばれた信頼関係を、通話中以外は確実に解除することが可能になる。
【実施例４】
【００９０】
これまでいくつかの実施例を説明したが、本発明は、これらの実施例に限定されるものではない。本発明は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。
【００９１】
例えば、上記実施例１〜３においては、ＨＧＷが、通話中の利用者双方のネットワークに設置される例を説明したが、これに限られるものではなく、ＨＧＷは、いずれか一方の利用者のネットワークに設置される場合であってもよい。
【００９２】
また、例えば、上記実施例１〜３においては、通話が、２者間で行われる例を説明したが、これに限られるものではなく、通話が、例えば３者間など、２者よりも多人数の間で行われる場合にも、開示の技術を同様に適用することができる。更に、上記実施例１〜３においては、ＳＩＰフォン間で行われる通話の例を説明したが、必ずしもこれに限られるものではなく、いわゆる音声通話としての「通話」のみならず、一般的な「通信」の場合にも、開示の技術を同様に適用することができる。すなわち、セッション連携サーバは、複数の利用者間で通信が確立されると、この通信を識別する通信情報を取得し、取得した通信情報が示す複数の利用者が利用する複数の端末間でＷｅｂセッションを連携するための連携情報を発行し、発行した連携情報を、その正当性を検証することが可能な形式でＷｅｂサーバに送信してもよい。
【符号の説明】
【００９３】
１００ セッション連携サーバ
１１０ 通信部
１２０ 記憶部
１２１ 制御用セッション情報管理テーブル
１２２ 発着間紐付けＩＤ管理テーブル
１３０ 制御部
１３１ ｃａｌｌセッション情報収集部
１３２ 発着間紐付けＩＤ発行部
２００ Ｗｅｂサーバ
２１０ 通信部
２３０ 制御部
２３１ 発着間紐付けＩＤ検証部
２３２ ＨＧＷアクセス部
２３３ Ｗｅｂセッション連携部
【技術分野】
【０００１】
本発明は、アクセス制御システム及びアクセス制御方法に関する。
【背景技術】
【０００２】
近年、ＩＰ（Internet Protocol）ネットワークに接続するＷｅｂサーバ間において、「サークル・オブ・トラスト（信頼の輪）」と称される信頼関係が結ばれることがある。「サークル・オブ・トラスト」が結ばれると、例えば、利用者の認証情報がＷｅｂサーバ間で交換され、ＳＳＯ（Single Sign On）の実現が可能になる。かかる「サークル・オブ・トラスト」は、従来、事前に結ばれるものであり、例えば、第１の事業体と第２の事業体との間で証明書などを事前に交換することで結ばれる。
【０００３】
なお、事前に信頼関係を結ぶ必要のない「ＯｐｅｎＩＤ」という概念がある。利用者は、初めてＷｅｂサイトにアクセスする場合であっても、「ＯｐｅｎＩＤ」を入力するだけで、そのＷｅｂサイトにログインすることが可能である。もっとも、Ｗｅｂサイトが「ＯｐｅｎＩＤ」に対応していることが前提となる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−３５５０７３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、このような信頼関係は、必ずしもＷｅｂサーバ間において結ばれなければならないものではなく、また、必ずしも事前に結ばれなければならないものでもない。すなわち、信頼関係は、例えば、ＷｅｂサーバとＨＧＷ（Home Gate Way）との間において結ばれてもよい。また、例えば、Ｗｅｂサービスの利用中に限るなど、一時的な信頼関係がオンデマンド（On Demand）に結ばれてもよい。しかしながら、証明書などを事前に交換する従来の技術では、一時的な信頼関係をオンデマンドに結ぶことはできない。
【０００６】
本発明は、上記に鑑みてなされたものであって、一時的な信頼関係をオンデマンドに結ぶことが可能なアクセス制御システム及びアクセス制御方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上述した課題を解決し、目的を達成するために、アクセス制御システムは、セッション連携サーバ、Ｗｅｂサーバ、及び通信制御装置を含む。セッション連携サーバは、取得手段と、発行手段とを備える。取得手段は、複数の利用者間で通信が確立されると、該通信を識別する通信情報を取得する。発行手段は、前記通信情報を取得すると、該通信情報が示す複数の利用者が利用する複数の端末間でＷｅｂセッションを連携するための連携情報を発行し、発行した連携情報を、該連携情報の正当性を検証することが可能な形式でＷｅｂサーバに送信する。Ｗｅｂサーバは、検証手段と、アクセス手段と、連携手段とを備える。検証手段は、前記連携情報を受信すると、該連携情報の正当性を検証する。アクセス手段は、前記端末と前記Ｗｅｂサーバとの間の通信を制御する通信制御装置に、前記正当性が検証された連携情報とともにアクセスする。連携手段は、前記正当性が検証された連携情報に基づいて前記複数の端末間でＷｅｂセッションを連携するとともに前記アクセスの結果を該Ｗｅｂセッションに反映する。通信制御装置は、アクセス制御手段を備える。アクセス制御手段は、前記Ｗｅｂサーバからのアクセスが前記連携情報とともに行われたことを条件として、該アクセスを受け付ける。
【０００８】
上述した課題を解決し、目的を達成するために、アクセス制御方法は、セッション連携サーバ、Ｗｅｂサーバ、及び通信制御装置において、以下の工程を含む。セッション連携サーバは、取得工程と、発行工程とを含む。取得工程は、複数の利用者間で通信が確立されると、該通信を識別する通信情報を取得する。発行工程は、前記通信情報を取得すると、該通信情報が示す複数の利用者が利用する複数の端末間でＷｅｂセッションを連携するための連携情報を発行し、発行した連携情報を、該連携情報の正当性を検証することが可能な形式でＷｅｂサーバに送信する。Ｗｅｂサーバは、検証工程と、アクセス工程と、連携工程とを含む。検証工程は、前記連携情報を受信すると、該連携情報の正当性を検証する。アクセス工程は、前記端末と前記Ｗｅｂサーバとの間の通信を制御する通信制御装置に、前記正当性が検証された連携情報とともにアクセスする。連携工程は、前記正当性が検証された連携情報に基づいて前記複数の端末間でＷｅｂセッションを連携するとともに前記アクセスの結果を該Ｗｅｂセッションに反映する。通信制御装置は、アクセス制御工程を含む。アクセス制御工程は、前記Ｗｅｂサーバからのアクセスが前記連携情報とともに行われたことを条件として、該アクセスを受け付ける。
【発明の効果】
【０００９】
本発明によれば、一時的な信頼関係をオンデマンドに結ぶことが可能になるという効果を奏する。
【図面の簡単な説明】
【００１０】
【図１】図１は、実施例１に係るアクセス制御システムの概要を説明するための図である。
【図２】図２は、実施例１に係るアクセス制御システムによる処理手順を示すシーケンス図である。
【図３】図３は、実施例１に係るＨＧＷの構成を示すブロック図である。
【図４】図４は、実施例１に係るＳＩＰフォンの構成を示すブロック図である。
【図５】図５は、実施例１に係る情報表示端末の構成を示すブロック図である。
【図６】図６は、実施例１に係るセッション連携サーバの構成を示すブロック図である。
【図７】図７は、制御用セッション情報管理テーブルを説明するための図である。
【図８】図８は、発着間紐付けＩＤ管理テーブルを説明するための図である。
【図９】図９は、実施例１に係るＷｅｂサーバの構成を示すブロック図である。
【図１０】図１０は、実施例２に係るアクセス制御システムによる処理手順を示すシーケンス図である。
【図１１】図１１は、実施例３に係るセッション連携サーバの構成を示すブロック図である。
【図１２】図１２は、実施例３に係るアクセス制御システムによる処理手順を示すシーケンス図である。
【発明を実施するための形態】
【００１１】
以下、本発明に係るアクセス制御システム及びアクセス制御方法の実施例を説明する。なお、以下の実施例により本発明が限定されるものではない。
【実施例１】
【００１２】
［実施例１に係るアクセス制御システムの概要］
実施例１に係るアクセス制御システムの概要を説明する。まず、実施例１に係るアクセス制御システムは、通話中の利用者間でＷｅｂセッションの連携が行われるシステムを前提としている。すなわち、利用者は、通話中であれば、Ｗｅｂページの閲覧を通話相手と連携することができる。例えば、通話中、一方の利用者が、自身が閲覧するＷｅｂページをリンク先に遷移させると、他方の利用者が閲覧するＷｅｂページも、リンク先のＷｅｂページに自動的に遷移する。
【００１３】
さて、実施例１に係るアクセス制御システムは、このようなシステムを前提に、「通話中である」という事実に基づいて、Ｗｅｂサーバと、利用者が所属するネットワークのＨＧＷ（通信制御装置とも称する）との間に、一時的な信頼関係をオンデマンドに結ぶ。ＷｅｂサーバとＨＧＷとの間に一時的な信頼関係が結ばれた結果、ＷｅｂサーバからＨＧＷへのアクセスが一時的に許容される。すると、例えば、Ｗｅｂサーバは、ＨＧＷに記憶された情報を取得し、取得した情報を用いたＷｅｂページを利用者に提供する。
【００１４】
サービスイメージの一例を挙げる。例えば、一方の利用者は、Ａ社のコールセンタであり、他方の利用者は、Ａ社のＰＣ（Personal Computer）を購入した顧客である。例えば、Ａ社のＰＣがＤＬＮＡ（Digital Living Network Alliance）などの規格に準拠しており、顧客のネットワークにＰＣが接続された際に、顧客側のＨＧＷに、Ａ社のＰＣに関する情報（型番、仕様など）が自動で格納されたとする。そして、ＰＣの操作中、不具合が発生したため、顧客が、コールセンタに電話をかけたとする。両者が通話中、コールセンタが運用するＷｅｂサーバと、顧客側のＨＧＷとの間には、一時的な信頼関係がオンデマンドに結ばれる。すると、コールセンタが運用するＷｅｂサーバは、ＨＧＷにアクセスし、ＰＣに関する情報（型番、仕様など）を取得する。そして、Ｗｅｂサーバは、例えば取得した情報に基づいて、そのＰＣに合致する取り扱い説明書を選択し、選択した取り扱い説明書のＷｅｂページの閲覧が、コールセンタと顧客との間で連携されるように、Ｗｅｂセッションを制御する。なお、上記サービスイメージは一例に過ぎず、アクセスの結果、どのようにサービスが提供され、どのようにＷｅｂセッションが連携されるかは、任意に変更され得るものである。
【００１５】
図１は、実施例１に係るアクセス制御システムの概要を説明するための図である。図１に示すように、実施例１に係るアクセス制御システムは、セッション連携サーバと、Ｗｅｂサーバとを備える。ここで、セッション連携サーバとＷｅｂサーバとの間においては、事前に信頼関係が結ばれている（図１において点線の枠で示す）。
【００１６】
上述したように、実施例１に係るアクセス制御システムは、「通話中である」という事実に基づいて、ＷｅｂサーバとＨＧＷとの間に一時的な信頼関係をオンデマンドに結ぶ。セッション連携サーバは、この「通話中である」という事実を管理する役割を担う。
【００１７】
具体的には、図１に示すように、セッション連携サーバは、複数の利用者間で通話が確立されると、この通話を識別する通話情報（通信情報とも称する）を取得する。例えば、セッション連携サーバは、各ＨＧＷによって収集された通話情報を各ＨＧＷから取得する。また、例えば、セッション連携サーバは、通話情報を、通話を制御するＳＩＰ（Session Initiation Protocol）サーバ（図１において図示を省略）から直接取得してもよい。
【００１８】
次に、セッション連携サーバは、通話情報を取得すると、この通話情報が示す複数の利用者が利用する複数の情報表示端末間でＷｅｂセッションを連携するための連携情報（以下、発着間紐付けＩＤ）を発行する。すなわち、Ｗｅｂセッションの連携はＷｅｂサーバにおいて行われるが、Ｗｅｂサーバは、どの情報表示端末が、互いに通話中の利用者が利用する情報表示端末であるかを識別することができない。そこで、セッション連携サーバは、通話中の利用者同士を紐付けるための発着間紐付けＩＤを発行し、Ｗｅｂサーバは、発着間紐付けＩＤを用いることで、互いに通話中の利用者が利用する情報表示端末を識別する。なお、発着間紐付けＩＤがどのように用いられるかという点については後述する。
【００１９】
さて、セッション連携サーバは、発行した発着間紐付けＩＤを、その正当性を検証することが可能な形式で、Ｗｅｂサーバに送信する。例えば、セッション連携サーバは、発着間紐付けＩＤに、セッション連携サーバ自身の署名付証明書を添付する。
【００２０】
一方、Ｗｅｂサーバは、発着間紐付けＩＤを受信すると、発着間紐付けＩＤの正当性を検証する。例えば、Ｗｅｂサーバは、証明書に含まれるセッション連携サーバの公開鍵（認証局によって真正な公開鍵であることは証明されている）を利用して署名を復号することで、発着間紐付けＩＤの正当性を検証する。
【００２１】
そして、Ｗｅｂサーバは、正当性が検証された発着間紐付けＩＤとともに、ＨＧＷに対してアクセスする。すると、ＨＧＷは、Ｗｅｂサーバからのアクセスが発着間紐付けＩＤとともに行われたことを条件として、アクセスを受け付ける。
【００２２】
こうして、Ｗｅｂサーバは、発着間紐付けＩＤに基づいて複数の情報表示端末間でＷｅｂセッションを連携するとともに、ＨＧＷにアクセスした結果をＷｅｂセッションに反映する。
【００２３】
［実施例１に係るアクセス制御システムによる処理手順］
次に、図２を用いて、実施例１に係るアクセス制御システムによる処理手順を説明する。図２は、実施例１に係るアクセス制御システムによる処理手順を示すシーケンス図である。なお、図２に示す点線の枠は、利用者が所属するネットワークを示し、点線の枠の外は、インターネットなどの広域ネットワークを示す。図２に示すように、利用者が所属するネットワークにはＨＧＷ１０が設置され、ＨＧＷ１０が、ネットワーク内の情報表示端末２０やＳＩＰフォン３０による通信を制御する。また、広域ネットワークには、セッション連携サーバ１００、Ｗｅｂサーバ２００、及びＳＩＰサーバが設置される。
【００２４】
図２に示すように、アクセス制御システムにおいて、まず、複数の利用者間で通話が確立される（ステップＳ１０１）。すなわち、ＳＩＰフォン３０間で通信が確立される。なお、ＳＩＰサーバが、ＳＩＰフォン３０間の通信を制御する。
【００２５】
複数の利用者間で通話が確立されると、実施例１に係るＨＧＷ１０は、この通話を識別するｃａｌｌセッション情報を収集する（ステップＳ１０２）。例えば、ＨＧＷ１０は、ＳＩＰによって確立された通信に含まれる情報から、『Ｃａｌｌ−ＩＤ』、『Ｆｒｏｍ（ＳＩＰ−ＵＲＩ（Uniform Resource Identifier））』及び『Ｔｏ（ＳＩＰ−ＵＲＩ）』を収集する。なお、実施例１に係るＨＧＷ１０は、ｃａｌｌセッション情報を収集する他に、確立された通話の発側であるか着側であるかを判定し、発着を示す発着判定フラグを生成する。この発着判定フラグは、例えば、Ｗｅｂサーバ２００がＨＧＷ１０にアクセスする際や情報表示端末２０にサービスを提供する際に、発着を区別するために用いられるものであり、必ずしも必須なものではない。
【００２６】
続いて、ＨＧＷ１０は、自ＨＧＷ１０にポーリングを行う配下の情報表示端末２０に対して、セッション連携サーバ１００のＵＲＬ（Uniform Resource Locator）に接続先を変更するよう指示するリダイレクト指示を、ｃａｌｌセッション情報及び発着判定フラグとともに行う（ステップＳ１０３）。
【００２７】
すると、情報表示端末２０はリダイレクトされ、接続先を、ＨＧＷ１０からセッション連携サーバ１００に変更する（ステップＳ１０３）。このとき、情報表示端末２０は、ｃａｌｌセッション情報及び発着判定フラグを、セッション連携サーバ１００に送信する。
【００２８】
一方、セッション連携サーバ１００は、ｃａｌｌセッション情報及び発着判定フラグを受信すると、同じ通話を識別するｃａｌｌセッション情報の送信元である複数の情報表示端末２０間でＷｅｂセッションを連携するための発着間紐付けＩＤを発行する（ステップＳ１０４）。
【００２９】
そして、セッション連携サーバ１００は、発着間紐付けＩＤを、その正当性を検証することが可能な形式で、Ｗｅｂサーバ２００に送信する（ステップＳ１０５）。例えば、セッション連携サーバ１００は、発着間紐付けＩＤに、セッション連携サーバ１００自身の署名付証明書を添付する。また、実施例１に係るセッション連携サーバ１００は、発着間紐付けＩＤとともに発着判定フラグも送信する。なお、発着判定フラグの送信は、上述したように、必ずしも必須なものではない。
【００３０】
また、セッション連携サーバ１００は、発着間紐付けＩＤ及び発着判定フラグを、情報表示端末２０にてリダイレクトされるようにＷｅｂサーバ２００に送信する。情報表示端末２０にてリダイレクトされてＷｅｂサーバ２００に送信されることによって、Ｗｅｂサーバ２００は、ＨＧＷ１０のＩＰアドレス、並びに、情報表示端末２０（情報表示端末２０のＷｅｂブラウザに付与されたブラウザセッション情報）と発着間紐付けＩＤ及び発着判定フラグとの対応関係を把握することができる。
【００３１】
Ｗｅｂサーバ２００は、情報表示端末２０にてリダイレクトされて送信された発着間紐付けＩＤ及び発着判定フラグを受信すると、この発着間紐付けＩＤの正当性を検証する（ステップＳ１０６）。例えば、Ｗｅｂサーバ２００は、添付された証明書に含まれるセッション連携サーバ１００の公開鍵を利用して署名を復号することで、発着間紐付けＩＤの正当性を検証する。
【００３２】
そして、Ｗｅｂサーバ２００は、正当性が検証された発着間紐付けＩＤとともに、ＨＧＷ１０に対してアクセスする（ステップＳ１０７）。このアクセスには、ステップＳ１０５において取得されたＨＧＷ１０のＩＰアドレスが用いられる。また、Ｗｅｂサーバ２００は、必要に応じて、どちらのＨＧＷ１０にアクセスすべきかなどについて、発着判定フラグを用いて判定する。なお、図２においては、ステップＳ１０７のアクセス時にも、発着間紐付けＩＤに署名付証明書が添付されている。この場合、例えばＨＧＷ１０側においても、発着間紐付けＩＤの正当性を検証することが可能である。もっとも、ステップＳ１０７のアクセス時には、署名付証明書を添付しなくてもよい。
【００３３】
すると、ＨＧＷ１０は、Ｗｅｂサーバ２００からのアクセスが発着間紐付けＩＤとともに行われたことを条件として、アクセスを受け付け、例えば、Ｗｅｂサーバ２００は、ＨＧＷ１０に記憶された個人情報を取得する（ステップＳ１０８）。
【００３４】
こうして、Ｗｅｂサーバ２００は、発着間紐付けＩＤに基づいて複数の情報表示端末２０間でＷｅｂセッションを連携するとともに、ＨＧＷ１０にアクセスした結果をＷｅｂセッションに反映する（ステップＳ１０９）。例えば、Ｗｅｂサーバ２００は、情報表示端末２０からＷｅｂページ取得要求を受け付けると（ステップＳ１１０）、ＨＧＷ１０から取得した個人情報を用いたＷｅｂページを返信する（ステップＳ１１１）。なお、Ｗｅｂサーバ２００は、ステップＳ１０５において、情報表示端末２０のＷｅｂブラウザに付与されたブラウザセッション情報と、発着間紐付けＩＤ及び発着判定フラグとの対応関係を把握している。このため、Ｗｅｂサーバ２００は、その後、発着間紐付けＩＤが一致する複数の情報表示端末２０間でＷｅｂコンテンツを連携するように制御することができる。
【００３５】
なお、上述した処理手順は一例に過ぎない。例えば、ステップＳ１０９のＷｅｂコンテンツの連携が開始された後に、ステップＳ１０７及びＳ１０８のアクセスが行われてもよい。
【００３６】
［実施例１に係るアクセス制御システムの構成］
次に、図３〜図９を用いて、実施例１に係るアクセス制御システムの構成を説明する。以下、ＨＧＷ１０、ＳＩＰフォン３０、情報表示端末２０、セッション連携サーバ１００、Ｗｅｂサーバ２００の順に説明する。
【００３７】
［ＨＧＷ１０］
図３は、実施例１に係るＨＧＷ１０の構成を示すブロック図である。ＨＧＷ１０は、図２を用いて説明した処理手順などを実行する各部が、汎用的なゲートウェイ装置などに備えられることによって実現される。ＨＧＷ１０は、例えば、ＳＩＰ通信部／ＨＴＴＰ（Hyper Text Transfer Protocol）通信部１１と、記憶部１２と、制御部１３とを備える。
【００３８】
ＳＩＰ通信部／ＨＴＴＰ通信部１１は、ＳＩＰ用及びＨＴＴＰ通信用の一般的なインタフェース及びライブラリを備える。ＳＩＰ通信部／ＨＴＴＰ通信部１１は、ＳＩＰフォン３０とＳＩＰサーバとの間の通信、情報表示端末２０とＷｅｂサーバ２００との間の通信、ＨＧＷ１０とＳＩＰサーバとの間の通信、ＨＧＷ１０とセッション連携サーバ１００との間の通信、ＨＧＷ１０とＷｅｂサーバ２００との間の通信などを制御する。
【００３９】
記憶部１２は、制御部１３における各種制御に用いられる情報を記憶し、個人情報等記憶部１２ａを有する。個人情報等記憶部１２ａは、例えば利用者の個人情報などを記憶する。例えば、記憶部１２は、ＲＡＭ（Random Access Memory）、フラッシュメモリ、ハードディスク、光ディスクなどで実現される。
【００４０】
制御部１３は、ＨＧＷ１０における各種制御を行い、ｃａｌｌセッション情報通知部１３ａと、アクセス受付部１３ｂとを有する。
【００４１】
ｃａｌｌセッション情報通知部１３ａは、ｃａｌｌセッション情報を収集し、収集したｃａｌｌセッション情報を、セッション連携サーバ１００に通知する。具体的には、ｃａｌｌセッション情報通知部１３ａは、ＳＩＰによって確立された通信に含まれる情報から、『Ｃａｌｌ−ＩＤ』、『Ｆｒｏｍ』及び『Ｔｏ（ＳＩＰ−ＵＲＩ）』を収集する。また、実施例１に係るｃａｌｌセッション情報通知部１３ａは、ｃａｌｌセッション情報を収集する他に、確立された通話の発側であるか着側であるかを判定し、発着を示す発着判定フラグを生成する。なお、ｃａｌｌセッション情報は、上述の情報に限られず、例えば、『Ｃａｌｌ−ＩＤ』もしくは『ｉｓｕｂ』、又は、『Ｆｒｏｍ』、『Ｔｏ』、『ｔａｇ』、ＩＰアドレス、もしくは、これらを組合せて実現される。また、ｃａｌｌセッション情報は、ＳＩＰ通信に含まれるその他の情報（例えば『Ｄａｔｅ』など）を組合せて実現される。なお、ＳＩＰによって確立された通信を一意に識別することが可能な情報を用いる手法であれば、どのような手法で実現してもよい。
【００４２】
そして、ｃａｌｌセッション情報通知部１３ａは、自ＨＧＷ１０にポーリングを行う情報表示端末２０に対して、セッション連携サーバ１００のＵＲＬに接続先を変更するよう指示するリダイレクト指示を、ｃａｌｌセッション情報及び発着判定フラグとともに行う。なお、ｃａｌｌセッション情報通知部１３ａは、例えば、セッション連携サーバ１００のＵＲＬ情報を予め記憶部１２に記憶することで、このリダイレクト指示を行う。
【００４３】
なお、ｃａｌｌセッション情報通知部１３ａがｃａｌｌセッション情報を収集する手法としては各種手法が考えられる。例えば、ｃａｌｌセッション情報通知部１３ａが、ＨＴＴＰ通信によってＳＩＰサーバにアクセスし、プル型でｃａｌｌセッション情報を収集する手法などでもよい。もっとも、この場合には、ＳＩＰサーバが、ｃａｌｌセッション情報の取得を希望するＨＧＷ１０について、ＩＰアドレスベースや回線ベースの認証など、何らかの認証手段によって認証することが望ましい。
【００４４】
アクセス受付部１３ｂは、Ｗｅｂサーバ２００からのアクセスが発着間紐付けＩＤとともに行われたことを条件として、Ｗｅｂサーバ２００からのアクセスを受け付ける。具体的には、アクセス受付部１３ｂは、Ｗｅｂサーバ２００からのアクセスを受け付けると、そのアクセスが、発着間紐付けＩＤとともに行われているか否かを判定する。そして、発着間紐付けＩＤとともに行われていると判定した場合に、アクセス受付部１３ｂは、Ｗｅｂサーバ２００とＨＧＷ１０との間に一時的な信頼関係が結ばれたものとして、Ｗｅｂサーバ２００からのアクセスを許容する。アクセス受付部１３ｂは、例えば個人情報等記憶部１２ａに記憶された情報の取得を許容する。
【００４５】
なお、アクセス受付部１３ｂは、Ｗｅｂサーバ２００からのアクセス時、発着間紐付けＩＤに署名付証明書が添付されている場合には、発着間紐付けＩＤの正当性を検証してもよい。例えば、アクセス受付部１３ｂは、証明書に含まれるセッション連携サーバ１００の公開鍵（認証局によって真正な公開鍵であることは証明されている）を利用して署名を復号し、発着間紐付けＩＤのハッシュ値を取り出す。また、アクセス受付部１３ｂは、発着間紐付けＩＤ自体からハッシュ値を算出する。そして、アクセス受付部１３ｂは、署名から取り出したハッシュ値と算出したハッシュ値とを照合することで、発着間紐付けＩＤが真正な情報であることを検証する。すなわち、署名から取り出したハッシュ値と算出したハッシュ値とを照合した結果、両者が一致すれば、(a)発着間紐付けＩＤが、確かにセッション連携サーバ１００から発行された情報であること、(b)発着間紐付けＩＤが、改竄されていないこと、(c)セッション連携サーバ１００が発着間紐付けＩＤを送信した事実を否認しないことなどの事実を検証することができ、発着間紐付けＩＤが真正な情報であることを検証することができる。
【００４６】
［ＳＩＰフォン３０］
図４は、実施例１に係るＳＩＰフォン３０の構成を示すブロック図である。ＳＩＰフォン３０は、例えば、入力部３２と、出力部３３と、入出力制御Ｉ／Ｆ部３４と、ＳＩＰ通信部３１とを備える。
【００４７】
いずれも汎用的なＳＩＰフォン３０と同様であるので簡単に説明すると、入力部３２は、ＳＩＰフォン３０に用いられる情報や、各種処理をするための操作指示などを、番号キーやマイクなどによって入力する。出力部３３は、ＳＩＰフォン３０による各種処理の結果や、各種処理をするための操作指示などを、ディスプレイやスピーカに出力する。入出力制御Ｉ／Ｆ部３４は、入力部３２と、出力部３３と、ＳＩＰ通信部３１との間における情報転送を制御する。ＳＩＰ通信部３１は、ＳＩＰ用の一般的なインタフェース及びライブラリを備え、他方のＳＩＰフォン３０との間で情報を送受信する。
【００４８】
［情報表示端末２０］
図５は、実施例１に係る情報表示端末２０の構成を示すブロック図である。情報表示端末２０は、図２を用いて説明した処理手順などを実行する各部が、汎用的なＰＣや情報家電などに備えられることによって実現される。情報表示端末２０は、例えば、入力部２２と、出力部２３と、入出力制御Ｉ／Ｆ部２４と、ＨＴＴＰ通信部２１と、制御部２５とを備える。
【００４９】
入力部２２は、情報表示端末２０に用いられる情報や、各種処理をするための操作指示などを、キーボード、マウス、リモコンなどによって入力する。出力部２３は、情報表示端末２０による各種処理の結果や、各種処理をするための操作指示などを、ディスプレイやプリンタなどに出力する。入出力制御Ｉ／Ｆ部２４は、入力部２２と、出力部２３と、ＨＴＴＰ通信部２１と、制御部２５との間における情報転送を制御する。ＨＴＴＰ通信部２１は、ＨＴＴＰ通信用の一般的なインタフェース及びライブラリを備え、Ｗｅｂサーバ２００との間で情報を送受信する。
【００５０】
制御部２５は、Ｗｅｂコンテンツ閲覧部２５ａを有する。例えば、Ｗｅｂコンテンツ閲覧部２５ａは、いわゆるＷｅｂブラウザによって実現され、ＨＧＷ１０に対してポーリングを行っている。また、Ｗｅｂコンテンツ閲覧部２５ａは、ＨＧＷ１０からリダイレクト指示を受けると、ＨＧＷ１０から受信したｃａｌｌセッション情報及び発着判定フラグをセッション連携サーバ１００に送信する。また、Ｗｅｂコンテンツ閲覧部２５ａは、セッション連携サーバ１００からリダイレクトされると、セッション連携サーバ１００から受信した発着間紐付けＩＤ及び発着判定フラグをＷｅｂサーバ２００に送信する。
【００５１】
このとき、Ｗｅｂコンテンツ閲覧部２５ａを実現するＷｅｂブラウザには、Ｗｅｂブラウザを識別するブラウザセッション情報が付与されており、Ｗｅｂサーバ２００は、ブラウザセッション情報を用いて情報表示端末２０を識別する。すなわち、ブラウザセッション情報は、情報表示端末２０とＷｅｂサーバ２００との間で確立されたＷｅｂセッション毎に生成され、情報表示端末２０とＷｅｂサーバ２００との間で確立されたＷｅｂセッションを一意に識別する情報である。ブラウザセッション情報は、例えばＷｅｂサーバ２００によって発行され、例えば『セッションＩＤ』（CookieのＩＤなど）で実現される。
【００５２】
また、Ｗｅｂコンテンツ閲覧部２５ａは、Ｗｅｂサーバ２００から送信されたＷｅｂページを出力部２３に出力する。
【００５３】
［セッション連携サーバ１００］
図６は、実施例１に係るセッション連携サーバ１００の構成を示すブロック図である。セッション連携サーバ１００は、図２を用いて説明した処理手順などを実行する各部が、汎用的なサーバなどに備えられることによって実現される。セッション連携サーバ１００は、例えば、通信部１１０と、記憶部１２０と、制御部１３０とを備える。
【００５４】
通信部１１０は、ＨＴＴＰ通信用の一般的なインタフェース及びライブラリを有し、ＨＧＷ１０、情報表示端末２０、Ｗｅｂサーバ２００との間で情報を送受信する。記憶部１２０は、制御部１３０における各種制御に用いられる情報を記憶する。記憶部１２０は、制御用セッション情報管理テーブル１２１と、発着間紐付けＩＤ管理テーブル１２２とを有する。例えば、記憶部１２０は、ＲＡＭ、フラッシュメモリ、ハードディスク、光ディスクなどで実現される。
【００５５】
制御用セッション情報管理テーブル１２１は、制御用セッション情報を管理する。具体的には、制御用セッション情報管理テーブル１２１は、制御用セッション情報を記憶し、制御用セッション情報管理テーブル１２１が記憶する制御用セッション情報は、後述する発着間紐付けＩＤ発行部１３２による処理に利用される。
【００５６】
図７は、制御用セッション情報管理テーブルを説明するための図である。例えば、制御用セッション情報管理テーブル１２１は、図７に示すように、制御用セッション情報と、ｃａｌｌセッション情報と、発着判定フラグとを対応付けて記憶する。
【００５７】
制御用セッション情報は、情報表示端末２０とセッション連携サーバ１００との間で確立されたセッション毎に生成され、情報表示端末２０とセッション連携サーバ１００との間で確立されたセッションを一意に識別する情報である。制御用セッション情報は、後述するｃａｌｌセッション情報収集部１３１によって発行され、制御用セッション情報管理テーブル１２１に格納される。例えば、制御用セッション情報は、『セッションＩＤ』（CookieのＩＤなど）で実現される。なお、図７において、説明の便宜上、制御用セッション情報として規則的な数値が例示されているが、一般的には乱数などが格納される。
【００５８】
また、ｃａｌｌセッション情報は、ＳＩＰフォン３０間でＳＩＰによって確立された通信を一意に識別する情報である。ｃａｌｌセッション情報は、後述するｃａｌｌセッション情報収集部１３１によって収集され、制御用セッション情報管理テーブル１２１に格納される。また、図７において、説明の便宜上、ｃａｌｌセッション情報の『Ｃａｌｌ−ＩＤ』として規則的な数値が例示されているが、一般的には乱数などが格納される。
【００５９】
また、発着判定フラグは、ＳＩＰフォン３０間でＳＩＰによって確立された通信について、ＳＩＰフォン３０が発側であるのか着側であるのかを示すフラグである。後述するｃａｌｌセッション情報収集部１３１によって収集され、制御用セッション情報管理テーブル１２１に格納される。
【００６０】
発着間紐付けＩＤ管理テーブル１２２は、発着間紐付けＩＤを管理する。具体的には、発着間紐付けＩＤ管理テーブル１２２は、発着間紐付けＩＤを記憶する。
【００６１】
図８は、発着間紐付けＩＤ管理テーブルを説明するための図である。例えば、発着間紐付けＩＤ管理テーブル１２２は、図８に示すように、制御用セッション情報と、発着間紐付けＩＤとを対応付けて記憶する。
【００６２】
発着間紐付けＩＤは、ＳＩＰによって確立された通信を一意に識別するｃａｌｌセッション情報の仮名情報であり、通話を行っている利用者間でＷｅｂセッションを連携するための連携情報である。発着間紐付けＩＤは、後述する発着間紐付けＩＤ発行部１３２によって発行され、発着間紐付けＩＤ管理テーブル１２２に格納される。なお、図８に示すように、一般的には乱数などが格納される。
【００６３】
図６に戻り、制御部１３０は、ｃａｌｌセッション情報収集部１３１と、発着間紐付けＩＤ発行部１３２とを有する。
【００６４】
ｃａｌｌセッション情報収集部１３１は、ｃａｌｌセッション情報及び発着判定フラグを収集する。具体的には、ｃａｌｌセッション情報収集部１３１は、ＨＧＷ１０のｃａｌｌセッション情報通知部１３ａによって通知されることで、ｃａｌｌセッション情報及び発着判定フラグを収集する。そして、ｃａｌｌセッション情報収集部１３１は、制御用セッション情報を発行し、収集したｃａｌｌセッション情報及び発着判定フラグを、発行した制御用セッション情報と対応付けて、制御用セッション情報管理テーブル１２１に格納する。
【００６５】
発着間紐付けＩＤ発行部１３２は、発着間紐付けＩＤを発行し、発行した発着間紐付けＩＤを、その正当性を検証することが可能な形式でＷｅｂサーバ２００に送信する。具体的には、発着間紐付けＩＤ発行部１３２は、制御用セッション情報管理テーブル１２１に記憶されている複数のｃａｌｌセッション情報の中から同一の通信を示すｃａｌｌセッション情報を特定する。次に、発着間紐付けＩＤ発行部１３２は、特定したｃａｌｌセッション情報と対応付けて記憶されている２つの制御用セッション情報を特定する。そして、発着間紐付けＩＤ発行部１３２は、発着間紐付けＩＤを発行し、発行した発着間紐付けＩＤと特定した制御用セッション情報とを対応付けて発着間紐付けＩＤ管理テーブル１２２に格納する。
【００６６】
続いて、発着間紐付けＩＤ発行部１３２は、発行した発着間紐付けＩＤに、セッション連携サーバ１００の署名付証明書を添付する。ここで、発着間紐付けＩＤ発行部１３２は、署名付証明書を添付することにより、例えば、(a)発着間紐付けＩＤが、確かにセッション連携サーバ１００から発行された情報であること、(b)発着間紐付けＩＤが、改竄されていないこと、(c)セッション連携サーバ１００が発着間紐付けＩＤを送信した事実を否認しないことを保証する。これらをＷｅｂサーバ２００において検証することができれば、Ｗｅｂサーバ２００は、取得した発着間紐付けＩＤが信用できる情報（真正な情報）であることを確認することができる。
【００６７】
また、例えば、実施例１に係る発着間紐付けＩＤ発行部１３２は、署名付証明書を、ＳＡＭＬ（Security Assertion Markup Language）に規定する形式で記述する。ここで、ＳＡＭＬ形式とは、認証のための情報をＸＭＬ（Extensible Markup Language）で記述されたデータで交換することを目的として策定されたプロトコルであり、署名によって検証可能な形式である。発着間紐付けＩＤ発行部１３２は、セッション連携サーバ１００の公開鍵が真正であることを証明する認証局発行の証明書と、セッション連携サーバ１００の秘密鍵で発着間紐付けＩＤ（ハッシュ値）を暗号化した署名とを、ＳＡＭＬ形式で記述する。
【００６８】
［Ｗｅｂサーバ２００］
図９は、実施例１に係るＷｅｂサーバ２００の構成を示すブロック図である。Ｗｅｂサーバ２００は、図２を用いて説明した処理手順などを実行する各部が、汎用的なサーバなどに備えられることによって実現される。Ｗｅｂサーバ２００は、例えば、通信部２１０と、制御部２３０とを備える。
【００６９】
通信部２１０は、ＨＴＴＰ通信用の一般的なインタフェース及びライブラリを備え、セッション連携サーバ１００との間や、情報表示端末２０との間などで情報を送受信する。
【００７０】
制御部２３０は、発着間紐付けＩＤ検証部２３１と、ＨＧＷアクセス部２３２と、Ｗｅｂセッション連携部２３３とを有する。
【００７１】
発着間紐付けＩＤ検証部２３１は、セッション連携サーバ１００によって発行された発着間紐付けＩＤを検証する。具体的には、発着間紐付けＩＤ検証部２３１は、情報表示端末２０から発着間紐付けＩＤ及び発着判定フラグを受信する。発着間紐付けＩＤは、確立された通話毎に新しく払い出されるものであるので、発着間紐付けＩＤ検証部２３１は、各情報表示端末２０から発着間紐付けＩＤを受信した結果、２つの情報表示端末２０からは同じ発着間紐付けＩＤを受信することになる。
【００７２】
また、発着間紐付けＩＤ検証部２３１は、発着間紐付けＩＤに添付された署名付証明書を検証することで、発着間紐付けＩＤの正当性を検証する。例えば、発着間紐付けＩＤ検証部２３１は、証明書に含まれるセッション連携サーバ１００の公開鍵（認証局によって真正な公開鍵であることは証明されている）を利用して署名を復号し、発着間紐付けＩＤのハッシュ値を取り出す。また、発着間紐付けＩＤ検証部２３１は、発着間紐付けＩＤ自体からハッシュ値を算出する。そして、発着間紐付けＩＤ検証部２３１は、署名から取り出したハッシュ値と算出したハッシュ値とを照合することで、発着間紐付けＩＤが真正な情報であることを検証する。すなわち、署名から取り出したハッシュ値と算出したハッシュ値とを照合した結果、両者が一致すれば、(a)発着間紐付けＩＤが、確かにセッション連携サーバ１００から発行された情報であること、(b)発着間紐付けＩＤが、改竄されていないこと、(c)セッション連携サーバ１００が発着間紐付けＩＤを送信した事実を否認しないことなどの事実を検証することができ、発着間紐付けＩＤが真正な情報であることを検証することができる。
【００７３】
ＨＧＷアクセス部２３２は、正当性が検証された発着間紐付けＩＤとともに、ＨＧＷ１０にアクセスする。具体的には、ＨＧＷアクセス部２３２は、発着間紐付けＩＤ検証部２３１によって発着間紐付けＩＤが真正な情報であることが検証された場合には、この発着間紐付けＩＤとともに、ＨＧＷ１０にアクセスする。なお、ＨＧＷアクセス部２３２は、各情報表示端末２０から発着間紐付けＩＤ及び発着判定フラグを受信した際に取得されたＨＧＷ１０のＩＰアドレスを用いて、ＨＧＷ１０にアクセスする。また、ＨＧＷアクセス部２３２は、必要に応じて、どちらのＨＧＷ１０にアクセスすべきかなどについて、発着判定フラグを用いて判定する。
【００７４】
Ｗｅｂセッション連携部２３３は、正当性が検証された発着間紐付けＩＤに基づいて複数の情報表示端末２０間でＷｅｂセッションを連携するとともに、ＨＧＷアクセス部２３２によるアクセスの結果をＷｅｂセッションに反映する。具体的には、Ｗｅｂセッション連携部２３３は、発着間紐付けＩＤ検証部２３１によって正当性が検証された複数の発着間紐付けＩＤの中から、Ｗｅｂセッションを連携することを示す発着間紐付けＩＤ（同一の発着間紐付けＩＤ）を特定し、特定した発着間紐付けＩＤの送信元である情報表示端末２０各々に提供するＷｅｂコンテンツを連携するように、サービス提供を制御する。なお、Ｗｅｂセッション連携部２３３は、情報表示端末２０に付与されたブラウザセッション情報と、発着間紐付けＩＤ及び発着判定フラグとの対応関係を把握しているので、特定した発着間紐付けＩＤの送信元である情報表示端末２０各々に提供するＷｅｂセッションを連携するように、サービス提供を制御することができる。
【００７５】
［実施例１の効果］
上述したように、実施例１に係るアクセス制御システムは、セッション連携サーバ１００、Ｗｅｂサーバ２００、及びＨＧＷ１０を含む。セッション連携サーバ１００は、ｃａｌｌセッション情報収集部１３１と、発着間紐付けＩＤ発行部１３２とを備える。ｃａｌｌセッション情報収集部１３１は、複数の利用者間で通話が確立されると、この通話を識別するｃａｌｌセッション情報を取得する。発着間紐付けＩＤ発行部１３２は、ｃａｌｌセッション情報を取得すると、このｃａｌｌセッション情報が示す複数の利用者が利用する複数の情報表示端末２０間でＷｅｂセッションを連携するための発着間紐付けＩＤを発行し、発行した発着間紐付けＩＤを、この発着間紐付けＩＤの正当性を検証することが可能な形式でＷｅｂサーバ２００に送信する。Ｗｅｂサーバ２００は、発着間紐付けＩＤ検証部２３１と、ＨＧＷアクセス部２３２と、Ｗｅｂセッション連携部２３３とを備える。発着間紐付けＩＤ検証部２３１は、発着間紐付けＩＤを受信すると、この発着間紐付けＩＤの正当性を検証する。ＨＧＷアクセス部２３２は、情報表示端末２０とＷｅｂサーバ２００との間の通信を制御するＨＧＷ１０に、正当性が検証された発着間紐付けＩＤとともにアクセスする。Ｗｅｂセッション連携部２３３は、正当性が検証された発着間紐付けＩＤに基づいて複数の情報表示端末２０間でＷｅｂセッションを連携するとともに、アクセスの結果をＷｅｂセッションに反映する。ＨＧＷ１０は、アクセス受付部１３ｂを備える。アクセス受付部１３ｂは、Ｗｅｂサーバ２００からのアクセスが発着間紐付けＩＤとともに行われたことを条件として、アクセスを受け付ける。
【００７６】
このようなことから、実施例１によれば、「通話中である」という事実に基づいて、Ｗｅｂサーバ２００と、利用者が所属するネットワークのＨＧＷ１０との間に、一時的な信頼関係をオンデマンドに結ぶことが可能になる。
【実施例２】
【００７７】
次に、実施例２に係るアクセス制御システムを説明する。実施例２に係るアクセス制御システムは、実施例１に係るアクセス制御システムと同様の処理手順に加え、ＨＧＷ１０に対するＷｅｂサーバ２００からのアクセスを許容するか否かを利用者に確認する。すなわち、アクセス制御システムにおいて、Ｗｅｂサーバ２００からのアクセスが発着間紐付けＩＤとともに行われた場合には、ＨＧＷ１０は、無条件に、このアクセスを受け付ける。このようなことから、実施例２においては、利用者に事前確認をとることとする。
【００７８】
図１０は、実施例２に係るアクセス制御システムによる処理手順を示すシーケンス図である。図１０に示すように、セッション連携サーバ１００の発着間紐付けＩＤ発行部１３２は、発着間紐付けＩＤを発行する際に、ＨＧＷ１０に対するＷｅｂサーバ２００からのアクセスを許容するか否かを確認する確認画面を、情報表示端末２０に送信する（ステップＳ２０４）。例えば、発着間紐付けＩＤ発行部１３２は、「ホームゲートウェイにアクセスしますが、よろしいですか？」といった確認画面を送信する。
【００７９】
例えば、利用者が、情報表示端末２０の出力部２３に出力された確認画面を確認し、これに了承して例えばボタンを押下すると、その情報がセッション連携サーバ１００に送信される（ステップＳ２０５）。すると、発着間紐付けＩＤ発行部１３２は、利用者による確認が得られたとして、発着間紐付けＩＤを発行する。一方、利用者による確認が得られなかった場合には、発着間紐付けＩＤ発行部１３２は、発着間紐付けＩＤを発行しない。
【００８０】
なお、利用者に事前確認をとる処理手順は、図１０に例示した処理手順に限られない。図１０に例示した処理手順の場合、利用者による確認が得られなければ、発着間紐付けＩＤ発行部１３２は発着間紐付けＩＤを発行しないことになり、Ｗｅｂサーバ２００は、Ｗｅｂセッションの連携もできなくなってしまう。そこで、例えば、発着間紐付けＩＤ発行部１３２は、利用者による確認が得られなければ、その旨を情報として添付した発着間紐付けＩＤを発行してもよい。この場合、Ｗｅｂサーバ２００のＨＧＷアクセス部２３２は、ＨＧＷ１０へのアクセスを行わないようにする。一方、Ｗｅｂセッション連携部２３３は、Ｗｅｂセッションの連携を行うことができる。
【００８１】
また、図１０に例示した処理手順の場合、利用者のうち、発信者は、ＨＧＷ１０に対するアクセスを許容することを前提とし、着信者に、確認画面を送信した。しかしながらこれに限られるものではなく、発信者及び着信者の両者に確認画面を送信するようにしてもよい。
【００８２】
また、確認画面において、単にアクセスを許容するか否かを確認するだけでなく、アクセスに関する情報、例えば、アクセスすることを許容するディレクトリ、フォルダ、あるいは、実行を許容するコマンドの種別などを利用者に入力させてもよい。この場合、発着間紐付けＩＤ発行部１３２は、これらの情報を添付して、発着間紐付けＩＤを発行する。一方、ＨＧＷアクセス部２３２は、ＨＧＷ１０へアクセスする前に、発着間紐付けＩＤに添付されたこれらの情報を確認し、例えば、アクセスすることが許容されたディレクトリ、フォルダのみにアクセスする、また、例えば、実行を許容されたコマンドのみを実行する、といったように、アクセスを制御する。
【００８３】
また、図１０に例示した処理手順の場合、利用者に事前確認をとる処理手順は、セッション連携サーバ１００によって行われたが、Ｗｅｂサーバ２００に行わせてもよい。例えば、ＨＧＷアクセス部２３２は、ＨＧＷ１０へアクセスする前に、アクセスを許容するか否かを確認する確認画面を情報表示端末２０に対して送信し、利用者による確認が得られた場合にのみ、アクセスしてもよい。また、確認画面において、単にアクセスを許容するか否かを確認するだけでなく、アクセスに関する情報、例えば、アクセスすることを許容するディレクトリ、フォルダ、あるいは、実行を許容するコマンドの種別などを利用者に入力させてもよい。さらに、Ｗｅｂサーバ２００自身が送信する確認画面であるので、例えば、どのような情報を取得したいか、具体的に記載して、その情報の取得のために必要な情報（ディレクトリ、フォルダ、許容するコマンドの種別など）を入力してもらうようにしてもよい。
【実施例３】
【００８４】
次に、実施例３に係るアクセス制御システムを説明する。実施例３に係るアクセス制御システムは、実施例１に係るアクセス制御システムや実施例２に係るアクセス制御システムと同様の機能を有する他に、発着間紐付けＩＤを失効させる機能を有する。
【００８５】
図１１は、実施例３に係るセッション連携サーバ１００の構成を示すブロック図であり、図１２は、実施例３に係るアクセス制御システムによる処理手順を示すシーケンス図である。図１１に示すように、実施例３に係るセッション連携サーバ１００は、制御部１３０に、発着間紐付けＩＤ失効部１３３をさらに備える。発着間紐付けＩＤ失効部１３３は、複数の利用者間で確立された通話が切断されると、この通話を識別するｃａｌｌセッション情報を取得する。また、発着間紐付けＩＤ失効部１３３は、切断された通話を識別するｃａｌｌセッション情報を取得すると、このｃａｌｌセッション情報に関連付けて発行された発着間紐付けＩＤの失効を、Ｗｅｂサーバ２００に通知する。
【００８６】
例えば、図１２に示すように、複数の利用者間で確立された通話が切断されると（ステップＳ３０１）、ＨＧＷ１０が、切断された通話を識別するｃａｌｌセッション情報を収集し（ステップＳ３０２）、収集したｃａｌｌセッション情報を、セッション連携サーバ１００に送信する（ステップＳ３０３）。なお、ＨＧＷ１０は、例えば図２のステップＳ１０２及びＳ１０３と同様の手法で、これらの処理手順を実行することができる。また、ＨＧＷ１０は、切断された通話を識別するｃａｌｌセッション情報と、確立された通話を識別するｃａｌｌセッション情報とを区別するために、ｃａｌｌセッション情報に、何らかのフラグを付与すればよい。
【００８７】
そして、発着間紐付けＩＤ失効部１３３は、ｃａｌｌセッション情報を受信すると、受信したｃａｌｌセッション情報を用いて制御用セッション情報管理テーブル１２１を検索し、受信したｃａｌｌセッション情報に対応付けて記憶されている制御用セッション情報を特定する。また、発着間紐付けＩＤ失効部１３３は、特定した制御用セッション情報を用いて発着間紐付けＩＤ管理テーブル１２２を検索し、特定した制御用セッション情報に対応付けて記憶されている発着間紐付けＩＤを特定する。そして、発着間紐付けＩＤ失効部１３３は、特定した発着間紐付けＩＤは、失効すべき発着間紐付けＩＤであるとして、Ｗｅｂサーバ２００に通知する。
【００８８】
すると、Ｗｅｂサーバ２００のＨＧＷアクセス部２３２は、発着間紐付けＩＤ失効部１３３から所定の発着間紐付けＩＤの失効を通知されると、該当するＨＧＷ１０に対するアクセスを終了する。また、Ｗｅｂセッション連携部２３３は、発着間紐付けＩＤの失効を通知されると、通知された発着間紐付けＩＤを用いたＷｅｂセッションの連携を終了する。
【００８９】
このように、実施例３によれば、通話の切断とともに発着間紐付けＩＤの失効がＷｅｂサーバ２００に通知され、Ｗｅｂサーバ２００によるＨＧＷ１０へのアクセスも終了するので、「通話中である」との事実に基づいて一時的に結ばれた信頼関係を、通話中以外は確実に解除することが可能になる。
【実施例４】
【００９０】
これまでいくつかの実施例を説明したが、本発明は、これらの実施例に限定されるものではない。本発明は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。
【００９１】
例えば、上記実施例１〜３においては、ＨＧＷが、通話中の利用者双方のネットワークに設置される例を説明したが、これに限られるものではなく、ＨＧＷは、いずれか一方の利用者のネットワークに設置される場合であってもよい。
【００９２】
また、例えば、上記実施例１〜３においては、通話が、２者間で行われる例を説明したが、これに限られるものではなく、通話が、例えば３者間など、２者よりも多人数の間で行われる場合にも、開示の技術を同様に適用することができる。更に、上記実施例１〜３においては、ＳＩＰフォン間で行われる通話の例を説明したが、必ずしもこれに限られるものではなく、いわゆる音声通話としての「通話」のみならず、一般的な「通信」の場合にも、開示の技術を同様に適用することができる。すなわち、セッション連携サーバは、複数の利用者間で通信が確立されると、この通信を識別する通信情報を取得し、取得した通信情報が示す複数の利用者が利用する複数の端末間でＷｅｂセッションを連携するための連携情報を発行し、発行した連携情報を、その正当性を検証することが可能な形式でＷｅｂサーバに送信してもよい。
【符号の説明】
【００９３】
１００ セッション連携サーバ
１１０ 通信部
１２０ 記憶部
１２１ 制御用セッション情報管理テーブル
１２２ 発着間紐付けＩＤ管理テーブル
１３０ 制御部
１３１ ｃａｌｌセッション情報収集部
１３２ 発着間紐付けＩＤ発行部
２００ Ｗｅｂサーバ
２１０ 通信部
２３０ 制御部
２３１ 発着間紐付けＩＤ検証部
２３２ ＨＧＷアクセス部
２３３ Ｗｅｂセッション連携部
【特許請求の範囲】
【請求項１】
セッション連携サーバは、
複数の利用者間で通信が確立されると、該通信を識別する通信情報を取得する取得手段と、
前記通信情報を取得すると、該通信情報が示す複数の利用者が利用する複数の端末間でＷｅｂセッションを連携するための連携情報を発行し、発行した連携情報を、該連携情報の正当性を検証することが可能な形式でＷｅｂサーバに送信する発行手段とを備え、
前記Ｗｅｂサーバは、
前記連携情報を受信すると、該連携情報の正当性を検証する検証手段と、
前記端末と前記Ｗｅｂサーバとの間の通信を制御する通信制御装置に、前記正当性が検証された連携情報とともにアクセスするアクセス手段と、
前記正当性が検証された連携情報に基づいて前記複数の端末間でＷｅｂセッションを連携するとともに前記アクセスの結果を該Ｗｅｂセッションに反映する連携手段とを備え、
前記通信制御装置は、
前記Ｗｅｂサーバからのアクセスが前記連携情報とともに行われたことを条件として、該アクセスを受け付けるアクセス制御手段と
を備えたことを特徴とするアクセス制御システム。
【請求項２】
前記セッション連携サーバは、
前記通信制御装置に対する前記Ｗｅｂサーバからのアクセスを許容するか否かを確認する情報を前記利用者が利用する端末に送信する確認手段をさらに備えたことを特徴とする請求項１に記載のアクセス制御システム。
【請求項３】
前記セッション連携サーバは、
前記複数の利用者間で確立された通信が切断されると、該通信を識別する通信情報を取得する切断時取得手段と、
切断された通信を識別する前記通信情報を取得すると、該通信情報に関連付けて発行された前記連携情報の失効を前記Ｗｅｂサーバに通知する通知手段とをさらに備え、
前記アクセス手段は、前記連携情報の失効を通知されると、前記通信制御装置に対するアクセスを終了し、
前記連携手段は、前記連携情報の失効を通知されると、前記Ｗｅｂセッションの連携を終了することを特徴とする請求項１又は２に記載のアクセス制御システム。
【請求項４】
セッション連携サーバが、
複数の利用者間で通信が確立されると、該通信を識別する通信情報を取得する取得工程と、
前記通信情報を取得すると、該通信情報が示す複数の利用者が利用する複数の端末間でＷｅｂセッションを連携するための連携情報を発行し、発行した連携情報を、該連携情報の正当性を検証することが可能な形式でＷｅｂサーバに送信する発行工程とを含み、
前記Ｗｅｂサーバが、
前記連携情報を受信すると、該連携情報の正当性を検証する検証工程と、
前記端末と前記Ｗｅｂサーバとの間の通信を制御する通信制御装置に、前記正当性が検証された連携情報とともにアクセスするアクセス工程と、
前記正当性が検証された連携情報に基づいて前記複数の端末間でＷｅｂセッションを連携するとともに前記アクセスの結果を該Ｗｅｂセッションに反映する連携工程とを含み、
前記通信制御装置は、
前記Ｗｅｂサーバからのアクセスが前記連携情報とともに行われたことを条件として、該アクセスを受け付けるアクセス制御工程と
を含むことを特徴とするアクセス制御方法。
【請求項１】
セッション連携サーバは、
複数の利用者間で通信が確立されると、該通信を識別する通信情報を取得する取得手段と、
前記通信情報を取得すると、該通信情報が示す複数の利用者が利用する複数の端末間でＷｅｂセッションを連携するための連携情報を発行し、発行した連携情報を、該連携情報の正当性を検証することが可能な形式でＷｅｂサーバに送信する発行手段とを備え、
前記Ｗｅｂサーバは、
前記連携情報を受信すると、該連携情報の正当性を検証する検証手段と、
前記端末と前記Ｗｅｂサーバとの間の通信を制御する通信制御装置に、前記正当性が検証された連携情報とともにアクセスするアクセス手段と、
前記正当性が検証された連携情報に基づいて前記複数の端末間でＷｅｂセッションを連携するとともに前記アクセスの結果を該Ｗｅｂセッションに反映する連携手段とを備え、
前記通信制御装置は、
前記Ｗｅｂサーバからのアクセスが前記連携情報とともに行われたことを条件として、該アクセスを受け付けるアクセス制御手段と
を備えたことを特徴とするアクセス制御システム。
【請求項２】
前記セッション連携サーバは、
前記通信制御装置に対する前記Ｗｅｂサーバからのアクセスを許容するか否かを確認する情報を前記利用者が利用する端末に送信する確認手段をさらに備えたことを特徴とする請求項１に記載のアクセス制御システム。
【請求項３】
前記セッション連携サーバは、
前記複数の利用者間で確立された通信が切断されると、該通信を識別する通信情報を取得する切断時取得手段と、
切断された通信を識別する前記通信情報を取得すると、該通信情報に関連付けて発行された前記連携情報の失効を前記Ｗｅｂサーバに通知する通知手段とをさらに備え、
前記アクセス手段は、前記連携情報の失効を通知されると、前記通信制御装置に対するアクセスを終了し、
前記連携手段は、前記連携情報の失効を通知されると、前記Ｗｅｂセッションの連携を終了することを特徴とする請求項１又は２に記載のアクセス制御システム。
【請求項４】
セッション連携サーバが、
複数の利用者間で通信が確立されると、該通信を識別する通信情報を取得する取得工程と、
前記通信情報を取得すると、該通信情報が示す複数の利用者が利用する複数の端末間でＷｅｂセッションを連携するための連携情報を発行し、発行した連携情報を、該連携情報の正当性を検証することが可能な形式でＷｅｂサーバに送信する発行工程とを含み、
前記Ｗｅｂサーバが、
前記連携情報を受信すると、該連携情報の正当性を検証する検証工程と、
前記端末と前記Ｗｅｂサーバとの間の通信を制御する通信制御装置に、前記正当性が検証された連携情報とともにアクセスするアクセス工程と、
前記正当性が検証された連携情報に基づいて前記複数の端末間でＷｅｂセッションを連携するとともに前記アクセスの結果を該Ｗｅｂセッションに反映する連携工程とを含み、
前記通信制御装置は、
前記Ｗｅｂサーバからのアクセスが前記連携情報とともに行われたことを条件として、該アクセスを受け付けるアクセス制御工程と
を含むことを特徴とするアクセス制御方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１２−８３９１６（Ｐ２０１２−８３９１６Ａ）
【公開日】平成２４年４月２６日（２０１２．４．２６）
【国際特許分類】
【出願番号】特願２０１０−２２８９３８（Ｐ２０１０−２２８９３８）
【出願日】平成２２年１０月８日（２０１０．１０．８）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２４年４月２６日（２０１２．４．２６）
【国際特許分類】
【出願日】平成２２年１０月８日（２０１０．１０．８）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]