(57)【要約】【課題】既存のＷｅｂコンテンツを共有することを課題とする。【解決手段】ユーザ間で通話が行われると、セッション連携サーバは、発着間紐付けＩＤを情報表示端末それぞれに対して発行する。プロキシサーバは、Ｗｅｂコンテンツ要求を受け付けると、Ｗｅｂコンテンツを取得し、ＷｅｂコンテンツのＵＲＬ情報が情報表示端末において変更された場合に、ＷｅｂコンテンツのＵＲＬ情報を発着間紐付けＩＤとともにプロキシサーバに通知するように、Ｗｅｂコンテンツを加工し、加工済みのＷｅｂコンテンツを送信元の情報表示端末に返信する。一方、セッション連携サーバは、プロキシサーバから送信された発着間紐付けＩＤに基づき通話相手の情報表示端末を特定し、Ｗｅｂコンテンツ要求に係るＷｅｂコンテンツが閲覧されるようにＵＲＬを通知する。なお、情報表示端末に返信されたＷｅｂコンテンツは加工されているので、上記手順が繰り返される。【選択図】図１
2011238201.tif 000002
【特許請求の範囲】
【請求項１】
利用者間で通話が行われると、当該利用者間でＷｅｂコンテンツに係る情報を連携するための連携情報を当該利用者の端末それぞれに対して発行する発行手段と、
所定のＷｅｂサーバが発信するＷｅｂコンテンツを要求するＷｅｂコンテンツ要求を、前記発行手段によって発行された連携情報とともに前記利用者のいずれかの端末より受け付ける第一受付手段と、
前記第一受付手段によってＷｅｂコンテンツ要求が受け付けられると、前記所定のＷｅｂサーバが発信するＷｅｂコンテンツを取得し、Ｗｅｂコンテンツに係る情報が当該Ｗｅｂコンテンツ要求の送信元の端末において変更された場合に、Ｗｅｂコンテンツに係る情報が変更されたことを示す変更情報を前記発行手段によって発行された連携情報とともに第二受付手段に通知するように、取得したＷｅｂコンテンツを加工する加工手段と、
前記加工手段によって加工されたＷｅｂコンテンツを、前記Ｗｅｂコンテンツ要求の送信元の端末に返信する返信手段と、
前記第一受付手段によって受け付けられた連携情報に基づいて、前記Ｗｅｂコンテンツ要求の送信元の端末を利用する利用者と通話を行っている利用者の端末を特定し、特定した端末において前記Ｗｅｂコンテンツ要求に係るＷｅｂコンテンツが閲覧されるように制御する第一制御手段と、
前記Ｗｅｂコンテンツに係る情報が前記通話を行っている利用者のいずれかの端末より変更された場合に、前記変更情報を前記連携情報とともに当該変更を行った端末から受け付ける前記第二受付手段と、
前記第二受付手段によって受け付けられた変更情報及び連携情報に基づいて、当該変更情報の送信元の端末と、当該送信元と通話を行っている利用者の端末との間において、前記Ｗｅｂコンテンツに係る情報が連携されるように制御する第二制御手段と
を備えたことを特徴とするＷｅｂコンテンツ共有システム。
【請求項２】
前記加工手段は、他のＷｅｂコンテンツに遷移するための遷移情報が指定されることにより前記Ｗｅｂコンテンツの所在情報が前記Ｗｅｂコンテンツ要求の送信元の端末において変更された場合に、当該他のＷｅｂコンテンツの所在情報を連携情報とともに前記第二受付手段に通知するように、取得したＷｅｂコンテンツを加工し、
前記第二制御手段は、前記第二受付手段によって受け付けられた所在情報及び連携情報に基づいて、当該所在情報の送信元の端末を利用する利用者と通話を行っている利用者の端末を特定し、特定した端末において当該所在情報に係るＷｅｂコンテンツが閲覧されるように制御することを特徴とする請求項１に記載のＷｅｂコンテンツ共有システム。
【請求項３】
Ｗｅｂコンテンツの所在情報をリストで記憶する所在情報記憶手段をさらに備え、
前記第二制御手段は、前記第二受付手段によって受け付けられた所在情報を用いて前記所在情報記憶手段を参照し、当該所在情報記憶手段に記憶された前記リストに基づいて当該所在情報に係るＷｅｂコンテンツの閲覧を許可するか否かを判定し、許可すると判定した場合にのみ、当該所在情報に係るＷｅｂコンテンツが閲覧されるように制御することを特徴とする請求項２に記載のＷｅｂコンテンツ共有システム。
【請求項４】
Ｗｅｂコンテンツの所在情報と利用者の識別情報とを対応付けてリストで記憶する利用者対応所在情報記憶手段をさらに備え、
前記第二制御手段は、前記第二受付手段によって受け付けられた所在情報を用いて前記利用者対応所在情報記憶手段を参照し、当該利用者対応所在情報記憶手段に記憶された前記リストに基づいて当該所在情報に係るＷｅｂコンテンツの閲覧を許可するか否かを判定し、許可すると判定した場合にのみ、当該所在情報に係るＷｅｂコンテンツが閲覧されるように制御することを特徴とする請求項２に記載のＷｅｂコンテンツ共有システム。
【請求項５】
前記加工手段は、操作情報が端末において変更された場合に、当該操作情報を連携情報とともに前記第二受付手段に通知するように、取得したＷｅｂコンテンツを加工し、
前記第二制御手段は、前記第二受付手段によって受け付けられた操作情報と連携情報とを対応付けて記憶手段に格納するように制御するとともに、操作情報を要求する操作情報要求を連携情報とともに端末から受け付けると、当該操作情報要求とともに受け付けた連携情報を用いて前記記憶手段を検索し、当該操作情報要求の送信元の端末を利用する利用者と通話を行っている利用者の端末の操作情報を当該送信元の端末に返信するように制御することを特徴とする請求項１〜４のいずれか一つに記載のＷｅｂコンテンツ共有システム。
【請求項６】
前記加工手段は、前記所定のＷｅｂサーバが発信するＷｅｂコンテンツを取得する際に、当該Ｗｅｂコンテンツに関して行われるＷｅｂセッションの状態を管理するための状態管理情報も併せて取得し、
前記返信手段は、前記加工手段によって加工されたＷｅｂコンテンツとともに、前記状態管理情報を識別する状態管理識別情報も併せて前記Ｗｅｂコンテンツ要求の送信元の端末に返信し、
前記第一制御手段は、前記送信元の端末を利用する利用者と通話を行っている利用者の端末として特定した端末においてＷｅｂコンテンツ要求に係るＷｅｂコンテンツが閲覧されるように制御する際に、前記状態管理識別情報を当該特定した端末に送信し、
前記第二受付手段は、前記変更情報を前記連携情報とともに前記変更を行った端末から受け付ける際に、前記状態管理識別情報も併せて受け付け、
前記第二制御手段は、前記第二受付手段によって受け付けられた変更情報及び連携情報に基づいて前記Ｗｅｂコンテンツに係る情報が連携されるように制御するとともに、前記第二受付手段によって受け付けられた前記状態管理識別情報により前記Ｗｅｂサーバから取得した状態管理情報を識別し、当該Ｗｅｂコンテンツに関して行われるＷｅｂセッションの状態が当該Ｗｅｂサーバによって管理されるように、識別した状態管理情報を用いて制御することを特徴とする請求項１〜５のいずれか一つに記載のＷｅｂコンテンツ共有システム。
【請求項７】
前記第二制御手段は、前記状態管理情報を用いて制御する際に、前記通話が継続中であるか否かをさらに判定し、当該通話が継続中であると判定した場合にのみ、当該状態管理情報を用いて制御することを特徴とする請求項６に記載のＷｅｂコンテンツ共有システム。
【請求項８】
前記Ｗｅｂコンテンツに係る情報の連携を停止することを指示する停止指示を前記通話を行っている利用者のいずれかの端末より受け付ける停止指示受付手段と、
前記停止指示受付手段によって停止指示が受け付けられると、当該停止指示を送信した端末の利用者と通話を行っている利用者の端末に対して、当該端末が保持する状態管理識別情報を無効にすることを指示する無効指示を送信する無効指示送信手段と
を備えたことを特徴とする請求項６または７に記載のＷｅｂコンテンツ共有システム。
【請求項９】
前記停止指示を解除し、前記Ｗｅｂコンテンツに係る情報の連携を復活することを指示する復活指示を、前記停止指示を送信した端末から受け付ける復活指示受付手段と、
前記復活指示受付手段によって復活指示が受け付けられると、当該復活指示を送信した端末の利用者と通話を行っている利用者の端末に対して、当該復活指示を送信した端末と前記Ｗｅｂサーバとの間で有効な状態管理情報を識別する状態管理識別情報を送信する有効情報送信手段と
を備えたことを特徴とする請求項８に記載のＷｅｂコンテンツ共有システム。
【請求項１０】
前記利用者の端末それぞれにおいて閲覧されたＷｅｂコンテンツの履歴情報を、前記利用者間で行われた通話と関連付けて記憶する履歴情報記憶手段と、
前記履歴情報記憶手段によって記憶されたＷｅｂコンテンツの閲覧要求を、前記発行手段によって発行された連携情報とともに前記利用者のいずれかの端末より受け付けると、当該連携情報に基づいて当該閲覧要求の要求元の端末を利用する利用者が行う通話を特定し、特定した通話と、当該Ｗｅｂコンテンツの履歴情報に関連付けられた通話とに基づいて、閲覧を制御する履歴閲覧制御手段と
を備えたことを特徴とする請求項１〜９のいずれか一つに記載のＷｅｂコンテンツ共有システム。
【請求項１１】
コンピュータが、
利用者間で通話が行われると、当該利用者間でＷｅｂコンテンツに係る情報を連携するための連携情報を当該利用者の端末それぞれに対して発行する発行工程と、
所定のＷｅｂサーバが発信するＷｅｂコンテンツを要求するＷｅｂコンテンツ要求を、前記発行工程によって発行された連携情報とともに前記利用者のいずれかの端末より受け付ける第一受付工程と、
前記第一受付工程によってＷｅｂコンテンツ要求が受け付けられると、前記所定のＷｅｂサーバが発信するＷｅｂコンテンツを取得し、Ｗｅｂコンテンツに係る情報が当該Ｗｅｂコンテンツ要求の送信元の端末において変更された場合に、Ｗｅｂコンテンツに係る情報が変更されたことを示す変更情報を前記発行工程によって発行された連携情報とともに第二受付工程に通知するように、取得したＷｅｂコンテンツを加工する加工工程と、
前記加工工程によって加工されたＷｅｂコンテンツを、前記Ｗｅｂコンテンツ要求の送信元の端末に返信する返信工程と、
前記第一受付工程によって受け付けられた連携情報に基づいて、前記Ｗｅｂコンテンツ要求の送信元の端末を利用する利用者と通話を行っている利用者の端末を特定し、特定した端末において前記Ｗｅｂコンテンツ要求に係るＷｅｂコンテンツが閲覧されるように制御する第一制御工程と、
前記Ｗｅｂコンテンツに係る情報が前記通話を行っている利用者のいずれかの端末より変更された場合に、前記変更情報を前記連携情報とともに当該変更を行った端末から受け付ける前記第二受付工程と、
前記第二受付工程によって受け付けられた変更情報及び連携情報に基づいて、当該変更情報の送信元の端末と、当該送信元と通話を行っている利用者の端末との間において、前記Ｗｅｂコンテンツに係る情報が連携されるように制御する第二制御工程と
を含んだことを特徴とするＷｅｂコンテンツ共有方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂコンテンツ共有システム及びＷｅｂコンテンツ共有方法に関する。
【背景技術】
【０００２】
従来、インターネットなどのＩＰ（Internet  Protocol）ネットワークを利用する利用者は、ＩＰネットワークに接続する端末を用いてＷｅｂ（World  Wide  Webの略称）サーバにアクセスし、Ｗｅｂサーバが発信するＷｅｂコンテンツを閲覧する。近年では、複数の利用者間でＷｅｂコンテンツを共有するサービスも登場しており、例えば、予め登録された会員間でＷｅｂコンテンツを共有するように、Ｗｅｂサーバが制御する技術がある（特許文献１など）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−２２８１２２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記した従来の技術では、Ｗｅｂサーバ側にＷｅｂコンテンツを共有するための仕組みが新たに必要になるなど、既存のＷｅｂコンテンツを共有することができないという課題があった。
【０００５】
そこで、本発明は、上記した従来の技術の課題を解決するためになされたものであり、既存のＷｅｂコンテンツを共有することが可能なＷｅｂコンテンツ共有システム及びＷｅｂコンテンツ共有方法を提供することを目的とする。
【課題を解決するための手段】
【０００６】
本願の開示するＷｅｂコンテンツ共有システム及びＷｅｂコンテンツ共有方法は、一つの態様において、複数の利用者間で通話が行われると、当該利用者間でＷｅｂコンテンツに係る情報を連携するための連携情報を当該利用者の端末それぞれに対して発行する発行手段と、所定のＷｅｂサーバが発信するＷｅｂコンテンツを要求するＷｅｂコンテンツ要求を、前記発行手段によって発行された連携情報とともに端末から受け付ける第一受付手段と、前記第一受付手段によってＷｅｂコンテンツ要求が受け付けられると、前記所定のＷｅｂサーバが発信するＷｅｂコンテンツを取得し、Ｗｅｂコンテンツに係る情報が端末において変更された場合に、Ｗｅｂコンテンツに係る情報が変更されたことを示す変更情報を前記発行手段によって発行された連携情報とともに第二受付手段に通知するように、取得したＷｅｂコンテンツを加工する加工手段と、前記加工手段によって加工されたＷｅｂコンテンツを、前記Ｗｅｂコンテンツ要求の送信元の端末に返信する返信手段と、前記第一受付手段によって受け付けられた連携情報に基づいて、当該Ｗｅｂコンテンツ要求の送信元と通話を行っている利用者の端末を特定し、特定した端末において前記Ｗｅｂコンテンツ要求に係るＷｅｂコンテンツが閲覧されるように制御する第一制御手段と、前記Ｗｅｂコンテンツに係る情報が前記通話を行っている利用者の端末いずれか一方より変更された場合に、前記変更情報を前記連携情報とともに当該端末から受け付ける第二受付手段と、前記第二受付手段によって受け付けられた変更情報及び連携情報に基づいて、当該変更情報の送信元の端末と、当該送信元と通話を行っている利用者の端末との間において、前記Ｗｅｂコンテンツに係る情報が連携されるように制御する第二制御手段とを備えたことを特徴とする。
【発明の効果】
【０００７】
本願の開示するＷｅｂコンテンツ共有システム及びＷｅｂコンテンツ共有方法の一つの態様によれば、既存のＷｅｂコンテンツを共有することが可能になるという効果を奏する。
【図面の簡単な説明】
【０００８】
【図１】図１は、実施例１に係るＷｅｂコンテンツ共有システムの概要を説明するための図である。
【図２】図２は、セッション連携サーバの構成を示すブロック図である。
【図３】図３は、制御用セッション情報管理テーブルを説明するための図である。
【図４】図４は、発着間紐付けＩＤ管理テーブルを説明するための図である。
【図５】図５は、プロキシサーバの構成を示すブロック図である。
【図６】図６は、Ｗｅｂコンテンツ加工処理を説明するための図である。
【図７】図７は、Ｗｅｂコンテンツ加工処理を説明するための図である。
【図８】図８は、Ｗｅｂコンテンツ加工処理を説明するための図である。
【図９】図９は、ＨＧＷの構成を示すブロック図である。
【図１０】図１０は、ブラウザセッション情報管理テーブルを説明するための図である。
【図１１】図１１は、ＳＩＰフォンの構成を示すブロック図である。
【図１２】図１２は、情報表示端末の構成を示すブロック図である。
【図１３】図１３は、実施例１に係るＷｅｂコンテンツ共有システムによる処理手順を説明するための図である。
【図１４】図１４は、情報表示端末の出力画面を説明するための図である。
【図１５】図１５は、情報表示端末の出力画面を説明するための図である。
【図１６】図１６は、実施例１に係るＷｅｂコンテンツ共有システムによる処理手順を説明するための図である。
【図１７】図１７は、情報表示端末の出力画面を説明するための図である。
【図１８】図１８は、プロキシサーバの構成を示すブロック図である。
【図１９】図１９は、ホワイトリストテーブルを説明するための図である。
【図２０】図２０は、実施例２に係るＷｅｂコンテンツ共有システムによる処理手順を説明するための図である。
【図２１】図２１は、プロキシサーバの構成を示すブロック図である。
【図２２】図２２は、ユーザ情報付ホワイトリストテーブルを説明するための図である。
【図２３】図２３は、プロキシサーバの構成を示すブロック図である。
【図２４】図２４は、共有データテーブルを説明するための図である。
【図２５】図２５は、マウスポインタ共有プログラムを説明するための図である。
【図２６】図２６は、マウスポインタ共有プログラムを説明するための図である。
【図２７】図２７は、実施例４に係るＷｅｂコンテンツ共有システムによる処理手順を説明するための図である。
【図２８】図２８は、プロキシサーバの構成を示すブロック図である。
【図２９】図２９は、ＩＤ−ＰＷ（Password）管理テーブルを説明するための図である。
【図３０】図３０は、Ｃｏｏｋｉｅ管理テーブルを説明するための図である。
【図３１−１】図３１−１は、実施例５に係るＷｅｂコンテンツ共有システムによる処理手順（初回アクセスから１回目の同期まで）を示すシーケンス図である。
【図３１−２】図３１−２は、実施例５に係るＷｅｂコンテンツ共有システムによる処理手順（初回アクセスから１回目の同期まで）を示すシーケンス図である。
【図３２】図３２は、Ｃｏｏｋｉｅの設定を説明するための図である。
【図３３−１】図３３−１は、実施例５に係るＷｅｂコンテンツ共有システムによる処理手順（２回目アクセスから２回目の同期まで）を示すシーケンス図である。
【図３３−２】図３３−２は、実施例５に係るＷｅｂコンテンツ共有システムによる処理手順（２回目アクセスから２回目の同期まで）を示すシーケンス図である。
【図３４】図３４は、変形例１の処理手順を説明するための図である。
【図３５】図３５は、サービスイメージを説明するための図である。
【図３６】図３６は、ＩＤ−ＰＷ管理テーブルを説明するための図である。
【図３７】図３７は、変形例２の処理手順を説明するための図である。
【図３８】図３８は、変形例２の処理手順を説明するための図である。
【図３９】図３９は、変形例２の処理手順を説明するための図である。
【図４０】図４０は、サービスイメージを説明するための図である。
【図４１】図４１は、ＩＤ−ＰＷ管理テーブルを説明するための図である。
【図４２】図４２は、Ｃｏｏｋｉｅ管理テーブルを説明するための図である。
【図４３−１】図４３−１は、変形例３の処理手順を説明するための図である。
【図４３−２】図４３−２は、変形例３の処理手順を説明するための図である。
【図４４】図４４は、サービスイメージを説明するための図である。
【図４５】図４５は、実施例６の概要を説明するための図である。
【図４６】図４６は、実施例６の概要を説明するための図である。
【図４７】図４７は、実施例６におけるプロキシサーバの構成を示すブロック図である。
【図４８】図４８は、仮想共有ブラウザテーブルを説明するための図である。
【図４９】図４９は、実施例６に係るＷｅｂコンテンツ共有システムによる処理手順を示すシーケンス図である。
【図５０】図５０は、実施例６に係るＷｅｂコンテンツ共有システムによる処理手順を示すシーケンス図である。
【図５１】図５１は、実施例７の概要を説明するための図である。
【図５２】図５２は、実施例７におけるプロキシサーバの構成を示すブロック図である。
【図５３】図５３は、閲覧履歴テーブルを説明するための図である。
【図５４】図５４は、閲覧履歴リストを説明するための図である。
【図５５】図５５は、実施例７に係るＷｅｂコンテンツ共有システムによる処理手順を示すシーケンス図である。
【図５６】図５６は、実施例７に係るＷｅｂコンテンツ共有システムによる処理手順を示すシーケンス図である。
【図５７】図５７は、実施例７に係るお気に入り閲覧制御部による処理手順を示すフローチャートである。
【図５８】図５８は、実施例８に係るＷｅｂコンテンツ共有システムによる処理手順を示すシーケンス図である。
【図５９】図５９は、オンライン表示を説明するための図である。
【図６０】図６０は、オンライン表示の処理手順を示すシーケンス図である。
【発明を実施するための形態】
【０００９】
以下、本願の開示するＷｅｂコンテンツ共有システム及びＷｅｂコンテンツ共有方法の実施例を詳細に説明する。なお、以下の実施例により本発明が限定されるものではない。
【実施例１】
【００１０】
［実施例１に係るＷｅｂコンテンツ共有システムの概要］
まず、図１を用いて、実施例１に係るＷｅｂコンテンツ共有システムの概要を説明する。図１は、実施例１に係るＷｅｂコンテンツ共有システムの概要を説明するための図である。
【００１１】
図１に示すように、実施例１に係るＷｅｂコンテンツ共有システムは、セッション連携サーバとプロキシサーバとを備える。また、プロキシサーバは、利用者（以下、ユーザという）の情報表示端末と既存のＷｅｂサーバ群との間に介在し、複数のユーザ間におけるＷｅｂコンテンツの共有を実現する。
【００１２】
ここで、実施例１に係るＷｅｂコンテンツ共有システムは、複数のユーザ間でＷｅｂコンテンツに係る情報を連携することで、Ｗｅｂコンテンツを共有する。Ｗｅｂコンテンツに係る情報とは、例えば、Ｗｅｂコンテンツを閲覧するためのＵＲＬ（Uniform  Resource  Locator）情報である。すなわち、実施例１に係るＷｅｂコンテンツ共有システムは、複数のユーザ間でＵＲＬ情報を連携することで、一方のユーザにおいて閲覧するＷｅｂコンテンツのページが遷移した場合には、他方のユーザにおいても閲覧するＷｅｂコンテンツのページが追従するように制御する。この結果、複数のユーザ間におけるＷｅｂコンテンツの共有を実現する。
【００１３】
具体的には、まず、Ｗｅｂコンテンツ共有システムにおいて、複数のユーザ間で通話が行われる。例えば、図１に示すように、ユーザ１のＳＩＰ（Session  Initiation  Protocol）フォンとユーザ２のＳＩＰフォンとの間でＳＩＰによって通信が確立され、ユーザ１とユーザ２との間で通話が行われる。
【００１４】
次に、セッション連携サーバが、通話を行っているユーザ間でＷｅｂコンテンツに係る情報を連携するための連携情報を情報表示端末それぞれに対して発行する。例えば、図１に示すように、セッション連携サーバは、ユーザ１の情報表示端末及びユーザ２の情報表示端末それぞれに対して発着間紐付けＩＤ（識別情報：Identification）を発行する。
【００１５】
ここで、ユーザが、情報表示端末を用いて、既存のＷｅｂサーバが発信するＷｅｂコンテンツを閲覧しようとしたとする。すると、プロキシサーバは、Ｗｅｂコンテンツを要求するＷｅｂコンテンツ要求を連携情報とともに情報表示端末から受け付ける。例えば、図１に示すように、プロキシサーバは、ユーザ１の情報表示端末から、Ｗｅｂコンテンツ要求を発着間紐付けＩＤとともに受け付ける。
【００１６】
続いて、プロキシサーバは、Ｗｅｂコンテンツ要求にて指定された既存のＷｅｂサーバからＷｅｂコンテンツを取得し、取得したＷｅｂコンテンツを加工する。具体的には、プロキシサーバは、他のＷｅｂコンテンツに遷移するための遷移情報が指定されることによりＷｅｂコンテンツの所在情報が情報表示端末において変更された場合に、他のＷｅｂコンテンツの所在情報を連携情報とともにプロキシサーバに通知するように、取得したＷｅｂコンテンツを加工する。例えば、プロキシサーバは、他のＷｅｂコンテンツに遷移するためのリンク情報が指定されることによりＷｅｂコンテンツのＵＲＬ情報が情報表示端末において変更された場合に、他のＷｅｂコンテンツのＵＲＬ情報を発着間紐付けＩＤとともにプロキシサーバに通知するように、取得したＷｅｂコンテンツを加工する。
【００１７】
次に、プロキシサーバは、Ｗｅｂコンテンツ要求を送信した送信元の情報表示端末に、加工済みのＷｅｂコンテンツを返信する。例えば、図１に示すように、プロキシサーバは、ユーザ１の情報表示端末に、加工済みのＷｅｂコンテンツを返信する。
【００１８】
続いて、プロキシサーバ及びセッション連携サーバは、連携情報に基づいて、Ｗｅｂコンテンツ要求の送信元と通話を行っているユーザの情報表示端末を特定し、この情報表示端末においてＷｅｂコンテンツ要求に係るＷｅｂコンテンツが閲覧されるように制御する。
【００１９】
例えば、図１に示すように、プロキシサーバが、Ｗｅｂコンテンツ要求にて指定されたＵＲＬ情報を発着間紐付けＩＤとともにセッション連携サーバに通知する。すると、セッション連携サーバが、発着間紐付けＩＤに基づきユーザ１と通話を行っているユーザ２の情報表示端末を特定し、ユーザ２の情報表示端末に対して、プロキシサーバから通知されたＵＲＬ情報を通知する。すると、例えば、図１に示すように、ユーザ２の情報表示端末は、通知されたＵＲＬ情報を指定するＷｅｂコンテンツ要求を発着間紐付けＩＤとともにプロキシサーバに送信する。すると、ユーザ２の情報表示端末には、ユーザ１が閲覧しているＷｅｂコンテンツが表示され、ユーザ１とユーザ２との間で既存のＷｅｂコンテンツを共有することができる。
【００２０】
ここで、上記したように、情報表示端末に返信されたＷｅｂコンテンツは、他のＷｅｂコンテンツに遷移するための遷移情報が指定されることによりＷｅｂコンテンツの所在情報が情報表示端末において変更された場合に、他のＷｅｂコンテンツの所在情報を連携情報とともにプロキシサーバに通知するように加工されたものである。したがって、プロキシサーバは、Ｗｅｂコンテンツの所在情報が端末において変更された場合に、他のＷｅｂコンテンツの所在情報を連携情報とともに情報表示端末から受け付ける。例えば、ユーザ１の情報表示端末においてリンク情報が指定されることによりＷｅｂコンテンツのＵＲＬ情報が情報表示端末において変更された場合に、プロキシサーバは、指定されたリンク先のＵＲＬ情報を発着間紐付けＩＤとともに受け付ける。
【００２１】
すると、プロキシサーバは、再び、Ｗｅｂコンテンツの所在情報にて指定されたＷｅｂサーバからＷｅｂコンテンツを取得し、取得したＷｅｂコンテンツを加工する。例えば、プロキシサーバは、再び、他のＷｅｂコンテンツに遷移するためのリンク情報が指定されることによりＷｅｂコンテンツのＵＲＬ情報が情報表示端末において変更された場合に、他のＷｅｂコンテンツのＵＲＬ情報を発着間紐付けＩＤとともにプロキシサーバに通知するように、取得したＷｅｂコンテンツを加工する。そして、プロキシサーバは、所在情報を送信した送信元の情報表示端末に、加工済みのＷｅｂコンテンツを返信する。
【００２２】
また、プロキシサーバ及びセッション連携サーバが、Ｗｅｂコンテンツの所在情報及び連携情報に基づいて、Ｗｅｂコンテンツの所在情報の送信元の情報表示端末と、送信元と通話を行っている利用者の情報表示端末との間において、Ｗｅｂコンテンツの所在情報が連携されるように制御する。
【００２３】
例えば、プロキシサーバは、ＵＲＬ情報を発着間紐付けＩＤとともにセッション連携サーバに通知する。すると、セッション連携サーバが、発着間紐付けＩＤに基づきユーザ１と通話を行っているユーザ２の情報表示端末を特定し、ユーザ２の情報表示端末に対して、プロキシサーバから通知されたＵＲＬ情報を通知する。すると、ユーザ２の情報表示端末は、通知されたＵＲＬ情報を指定するＷｅｂコンテンツ要求を発着間紐付けＩＤとともにプロキシサーバに送信する。すると、ユーザ２の情報表示端末には、ユーザ１が閲覧しているＷｅｂコンテンツが表示され、ユーザ１とユーザ２との間で既存のＷｅｂコンテンツを共有することができる。
【００２４】
このように、実施例１に係るＷｅｂコンテンツ共有システムは、既存のＷｅｂコンテンツを共有することを可能にし、ユーザの情報表示端末において閲覧するＷｅｂコンテンツのページが遷移した場合には、遷移に追従してＷｅｂコンテンツを共有することを可能にする。
【００２５】
つまり、実施例１に係るＷｅｂコンテンツ共有システムは、既存のＷｅｂコンテンツを要求されると、既存のＷｅｂコンテンツを取得するとともにこれを加工し、加工済みのＷｅｂコンテンツを情報表示端末に返信することで、ページ遷移の同期を可能にする。仮に、Ｗｅｂコンテンツを加工することなく情報表示端末に返信してしまうと、情報表示端末においてその後ページ遷移があったとしても、Ｗｅｂコンテンツ要求はプロキシサーバに送信されることなく直接Ｗｅｂサーバに送信されてしまい、その後のページ遷移の同期は不可能になってしまう。
【００２６】
［実施例１に係るＷｅｂコンテンツ共有システムの構成］
次に、図２〜図１２を用いて、実施例１に係るＷｅｂコンテンツ共有システムの構成を説明する。以下、セッション連携サーバ１００、プロキシサーバ２００、ＨＧＷ（Home  Gate  Way）１０、ＳＩＰフォン３０、情報表示端末２０の順に説明する。
【００２７】
［セッション連携サーバ１００］
図２〜図４を用いて、セッション連携サーバ１００の構成を説明する。図２は、セッション連携サーバの構成を示すブロック図である。セッション連携サーバ１００は、以下に説明する各部が汎用的なサーバなどに備えられることによって実現され、図２に示すように、通信部１１０と、記憶部１２０と、制御部１３０とを備える。
【００２８】
通信部１１０は、ＨＴＴＰ（Hyper  Text  Transfer  Protocol）通信用の一般的なインタフェース及びライブラリを有し、ＨＧＷ１０、情報表示端末２０、プロキシサーバ２００との間で情報を送受信する。記憶部１２０は、制御部１３０における各種制御に用いられる情報を記憶し、図２に示すように、制御用セッション情報管理テーブル１２１と、発着間紐付けＩＤ管理テーブル１２２とを有する。例えば、記憶部１２０は、ＲＡＭ（Random  Access  Memory）、ＲＯＭ（Read  Only  Memory）、フラッシュメモリ（flash  memory）などの半導体メモリ素子、または、ハードディスク、光ディスクなどである。
【００２９】
制御用セッション情報管理テーブル１２１は、制御用セッション情報を管理する。具体的には、制御用セッション情報管理テーブル１２１は、制御用セッション情報を記憶し、制御用セッション情報管理テーブル１２１が記憶する制御用セッション情報は、後述する発着間紐付けＩＤ発行部１２２による処理に利用される。
【００３０】
図３は、制御用セッション情報管理テーブルを説明するための図である。例えば、制御用セッション情報管理テーブル１２１は、図３に示すように、制御用セッション情報と、ｃａｌｌセッション情報と、発着判定フラグと、通話履歴情報とを対応付けて記憶する。
【００３１】
ここで、制御用セッション情報は、情報表示端末２０とセッション連携サーバ１００との間で確立されたセッション毎に生成され、情報表示端末２０とセッション連携サーバ１００との間で確立されたセッションを一意に識別する情報である。制御用セッション情報は、後述するｃａｌｌセッション情報収集部１３１によって発行され、制御用セッション情報管理テーブル１２１に格納される。例えば、制御用セッション情報は、『セッションＩＤ』（CookieのＩＤなど）で実現される。なお、図３において、説明の便宜上、制御用セッション情報として規則的な数値が例示されているが、一般的には乱数などが格納される。
【００３２】
また、ｃａｌｌセッション情報は、ＳＩＰフォン３０間でＳＩＰによって確立されたセッションを一意に識別する情報である。ｃａｌｌセッション情報は、後述するｃａｌｌセッション情報収集部１３１によって収集され、制御用セッション情報管理テーブル１２１に格納される。例えば、ｃａｌｌセッション情報は、ＳＩＰ通信に含まれる情報である『Ｃａｌｌ−ＩＤ』もしくは『ｉｓｕｂ』、または、『Ｆｒｏｍ』、『Ｔｏ』、『ｔａｇ』、ＩＰアドレス、もしくは、これらを組合せて実現される。また、ｃａｌｌセッション情報は、ＳＩＰ通信に含まれるその他の情報（例えば『Ｄａｔｅ』など）を組合せて実現される。なお、ＳＩＰによって確立されたセッションを一意に識別することが可能な情報を用いる手法であれば、どのような手法で実現してもよい。また、図３において、説明の便宜上、ｃａｌｌセッション情報の『Ｃａｌｌ−ＩＤ』として規則的な数値が例示されているが、一般的には乱数などが格納される。
【００３３】
また、発着判定フラグは、ＳＩＰフォン３０間でＳＩＰによって確立されたセッションについて、ＳＩＰフォン３０が発側であるのか着側であるのかを示すフラグである。後述するｃａｌｌセッション情報収集部１３１によって収集され、制御用セッション情報管理テーブル１２１に格納される。
【００３４】
通話履歴情報は、ｃａｌｌセッション情報によって一意に識別されるセッションの開始時刻と終了時刻とを示す情報である。開始時刻は、例えば、後述するｃａｌｌセッション情報収集部１３１が情報表示端末２０からサービス開始要求を受け付けた際に、ｃａｌｌセッション情報収集部１３１によって制御用セッション情報管理テーブル１２１に格納される。また、終了時刻は、例えば、セッション連携サーバ１００がセッションの切断を検知した際に、セッション連携サーバ１００によって制御用セッション情報管理テーブル１２１に格納される。
【００３５】
図２に戻り、発着間紐付けＩＤ管理テーブル１２２は、発着間紐付けＩＤを管理する。具体的には、発着間紐付けＩＤ管理テーブル１２２は、発着間紐付けＩＤを記憶し、発着間紐付けＩＤ管理テーブル１２２が記憶する発着間紐付けＩＤは、後述するＵＲＬ通知部１３３による処理に利用される。
【００３６】
図４は、発着間紐付けＩＤ管理テーブルを説明するための図である。例えば、発着間紐付けＩＤ管理テーブル１２２は、図４に示すように、制御用セッション情報と、発着間紐付けＩＤとを対応付けて記憶する。
【００３７】
ここで、発着間紐付けＩＤは、ＳＩＰによって確立されたセッションを一意に識別するｃａｌｌセッション情報の仮名情報であり、通話を行っている利用者間でＷｅｂコンテンツに係る情報を連携するための連携情報である。発着間紐付けＩＤは、後述する発着間紐付けＩＤ発行部１３２によって発行され、発着間紐付けＩＤ管理テーブル１２２に格納される。なお、図４に示すように、一般的には乱数などが格納される。
【００３８】
図２に戻り、制御部１３０は、ｃａｌｌセッション情報収集部１３１と、発着間紐付けＩＤ発行部１３２と、ＵＲＬ通知部１３３とを有する。
【００３９】
ｃａｌｌセッション情報収集部１３１は、ｃａｌｌセッション情報及び発着判定フラグを収集する。具体的には、ｃａｌｌセッション情報収集部１３１は、ＳＩＰフォン３０間でＳＩＰによってセッションが確立されると、ｃａｌｌセッション情報及び発着判定フラグを収集し、制御用セッション情報管理テーブル１２１に格納する。
【００４０】
発着間紐付けＩＤ発行部１３２は、発着間紐付けＩＤを発行する。具体的には、発着間紐付けＩＤ発行部１３２は、制御用セッション情報管理テーブル１２１に記憶されている複数のｃａｌｌセッション情報の中から同一のセッションを示すｃａｌｌセッション情報を特定する。次に、発着間紐付けＩＤ発行部１３２は、特定したｃａｌｌセッション情報と対応付けて記憶されている２つの制御用セッション情報を特定する。そして、発着間紐付けＩＤ発行部１３２は、発着間紐付けＩＤを発行し、発行した発着間紐付けＩＤと特定した制御用セッション情報とを対応付けて発着間紐付けＩＤ管理テーブル１２２に格納する。
【００４１】
ＵＲＬ通知部１３３は、Ｗｅｂコンテンツに係る情報であってＷｅｂコンテンツを閲覧するためのＵＲＬ情報を通知する。具体的には、ＵＲＬ通知部１３３は、Ｗｅｂコンテンツを閲覧するためのＵＲＬ情報、発着間紐付けＩＤ、及び発着判定フラグをプロキシサーバ２００から受信する。次に、ＵＲＬ通知部１３３は、プロキシサーバ２００から受信した発着間紐付けＩＤを用いて発着間紐付けＩＤ管理テーブル１２２を参照し、発着間紐付けＩＤに対応付けて記憶されている制御用セッション情報を特定する。なお、ここで特定される制御用セッション情報は、発着双方の情報表示端末２０が用いる２つの制御用セッション情報である。
【００４２】
続いて、ＵＲＬ通知部１３３は、特定した２つの制御用セッション情報及び発着判定フラグ（例えば「発」側）を用いて制御用セッション情報管理テーブル１２１を参照し、１つの制御用セッション情報を特定する。そして、ＵＲＬ通知部１３３は、特定した制御用セッション情報とは異なるもう一方の制御用セッション情報を、ＵＲＬ情報を通知する情報表示端末２０が用いる制御用セッション情報として特定する。すなわち、ＵＲＬ通知部１３３は、例えば「着」側の情報表示端末２０が用いる制御用セッション情報を特定する。次に、ＵＲＬ通知部１３３は、特定した制御用セッション情報を用いる情報表示端末２０に対して、プロキシサーバ２００から受信したＵＲＬ情報を送信する。
【００４３】
［プロキシサーバ２００］
次に、図５〜図８を用いて、プロキシサーバ２００の構成を説明する。図５は、プロキシサーバの構成を示すブロック図である。プロキシサーバ２００は、以下に説明する各部が汎用的なサーバなどに備えられることによって実現され、図５に示すように、通信部２１０と、記憶部２２０と、制御部２３０とを備える。
【００４４】
通信部２１０は、ＨＴＴＰ通信用の一般的なインタフェース及びライブラリを有し、ＨＧＷ１０、情報表示端末２０、セッション連携サーバ１００との間で情報を送受信する。記憶部２２０は、制御部２３０における各種制御に用いられる情報を記憶する。例えば、記憶部２２０は、ＲＡＭ、ＲＯＭ、フラッシュメモリなどの半導体メモリ素子、または、ハードディスク、光ディスクなどである。
【００４５】
制御部２３０は、図５に示すように、Ｗｅｂコンテンツ要求受付部２３１と、Ｗｅｂコンテンツ取得部２３２と、Ｗｅｂコンテンツ加工部２３３と、加工済Ｗｅｂコンテンツ返信部２３４と、閲覧制御部２３５とを備える。
【００４６】
Ｗｅｂコンテンツ要求受付部２３１は、Ｗｅｂコンテンツ要求を発着間紐付けＩＤとともに情報表示端末２０から受け付ける。具体的には、Ｗｅｂコンテンツ要求受付部２３１は、Ｗｅｂコンテンツ要求を情報表示端末２０から受け付け、受け付けたＷｅｂコンテンツ要求から、ＷｅｂサーバのＵＲＬ情報、発着間紐付けＩＤ及び発着判定フラグを抽出し、Ｗｅｂコンテンツ取得部２３２に送る。
【００４７】
ここで、Ｗｅｂコンテンツ要求受付部２３１が受け付けるＷｅｂコンテンツ要求には、初回のＷｅｂコンテンツ要求として受け付ける場合と、２回目以降のＷｅｂコンテンツ要求として受け付ける場合とがある。後述するように、加工済Ｗｅｂコンテンツ返信部２３４によって情報表示端末２０に返信されたＷｅｂコンテンツは、他のＷｅｂコンテンツに遷移するためのリンク情報が指定されることによりＷｅｂコンテンツのＵＲＬ情報が情報表示端末２０において変更された場合に、他のＷｅｂコンテンツのＵＲＬ情報を発着間紐付けＩＤとともにＷｅｂコンテンツ要求受付部２３１に通知するように加工されたものである。したがって、例えば、情報表示端末２０においてリンク情報が指定されると、指定されたリンク先のＷｅｂコンテンツのＵＲＬ情報が発着間紐付けＩＤとともに再びＷｅｂコンテンツ要求受付部２３１によって受け付けられる。この場合が、Ｗｅｂコンテンツ要求受付部２３１が、２回目以降のＷｅｂコンテンツ要求として受け付ける場合である。
【００４８】
Ｗｅｂコンテンツ取得部２３２は、Ｗｅｂコンテンツ要求によって指定されたＷｅｂサーバからＷｅｂコンテンツを取得する。具体的には、Ｗｅｂコンテンツ取得部２３２は、ＷｅｂサーバのＵＲＬ情報、発着間紐付けＩＤ及び発着判定フラグをＷｅｂコンテンツ要求受付部２３１から受け付け、受け付けたＷｅｂサーバのＵＲＬにアクセスしてＷｅｂコンテンツを取得する。また、Ｗｅｂコンテンツ取得部２３２は、取得したＷｅｂコンテンツ、発着間紐付けＩＤ及び発着判定フラグをＷｅｂコンテンツ加工部２３３に送る。
【００４９】
Ｗｅｂコンテンツ加工部２３３は、Ｗｅｂコンテンツに他のＷｅｂコンテンツに遷移するためのリンク情報が含まれている場合には、Ｗｅｂコンテンツを加工する。具体的には、Ｗｅｂコンテンツ加工部２３３は、Ｗｅｂコンテンツ、発着間紐付けＩＤ及び発着判定フラグをＷｅｂコンテンツ取得部２３２から受け付け、受け付けたＷｅｂコンテンツを加工する。また、Ｗｅｂコンテンツ加工部２３３は、加工済みのＷｅｂコンテンツを加工済Ｗｅｂコンテンツ返信部２３４に送り、加工済みのＷｅｂコンテンツを閲覧するためのＵＲＬ情報、発着間紐付けＩＤ及び発着判定フラグを閲覧制御部２３５に送る。
【００５０】
ここで、Ｗｅｂコンテンツ加工部２３３は、他のＷｅｂコンテンツに遷移するためのリンク情報が指定されることによりＷｅｂコンテンツのＵＲＬ情報が情報表示端末２０において変更された場合に、他のＷｅｂコンテンツのＵＲＬ情報を発着間紐付けＩＤとともにＷｅｂコンテンツ要求受付部２３１に通知するように、Ｗｅｂコンテンツを加工する。図６〜図８は、Ｗｅｂコンテンツ加工処理を説明するための図である。
【００５１】
例えば、Ｗｅｂコンテンツ加工部２３３は、Ｗｅｂコンテンツ取得部２３２によって取得されたＷｅｂコンテンツのＨＴＭＬ（Hyper  Text  Markup  Language）タグを解析し、図６の（Ａ）に示すように、Ｗｅｂコンテンツの遷移に関するタグである『ａタグ  ｈｒｅｆ属性』が記述された箇所を特定する。ここで、例えば、図６の（Ａ）の符号ａは、Ｗｅｂコンテンツに含まれるリンク情報であり、情報表示端末２０において符号ａに示すリンク情報が指定されると、情報表示端末２０は、『http://www.a-site.ne.jp/mailmagazine/』のＷｅｂコンテンツを要求する。
【００５２】
次に、Ｗｅｂコンテンツ加工部２３３は、例えば、図６の（Ｂ）に示すように、特定した箇所を加工する。ここで、例えば、図６の（Ｂ）の符号ｂは、プロキシサーバ２００のＵＲＬ情報である。また、符号ｃは、Ｗｅｂコンテンツ取得部２３２から受け付けた発着間紐付けＩＤである。また、符号ｄは、Ｗｅｂコンテンツ取得部２３２から受け付けた発着判定フラグである。また、符号ｅは、図６の（Ａ）の符号ａと同一のリンク情報である。
【００５３】
また、例えば、Ｗｅｂコンテンツ加工部２３３は、Ｗｅｂコンテンツ取得部２３２によって取得されたＷｅｂコンテンツのＨＴＭＬタグを解析し、図７の（Ａ）に示すように、Ｗｅｂコンテンツの遷移に関するタグである『ｆｏｒｍタグ  ａｃｔｉｏｎ属性』が記述された箇所を特定する。ここで、例えば、図７の（Ａ）の符号ａは、Ｗｅｂコンテンツに含まれるリンク情報であり、情報表示端末２０において符号ａに示すリンク情報が指定されると、情報表示端末２０は、『http://green.search.a-site.ne.jp/search/』のＷｅｂコンテンツを要求する。
【００５４】
次に、Ｗｅｂコンテンツ加工部２３３は、例えば、図７の（Ｂ）に示すように、特定した箇所を加工する。ここで、例えば、図７の（Ｂ）の符号ｂは、プロキシサーバ２００のＵＲＬ情報である。また、符号ｃは、Ｗｅｂコンテンツ取得部２３２から受け付けた発着間紐付けＩＤである。また、符号ｄは、Ｗｅｂコンテンツ取得部２３２から受け付けた発着判定フラグである。また、符号ｅは、図７の（Ａ）の符号ａと同一のリンク情報である。
【００５５】
なお、Ｗｅｂコンテンツ加工部２３３は、画像データなどを示すＵＲＩ（Uniform  Resource  Identifier）が相対値で記述されている場合には絶対値で記述し直すなど、細かい調整を行う。例えば、Ｗｅｂコンテンツ加工部２３３は、図８の（Ａ）に示すように相対値で記述されているＵＲＩ（符号ａ）を、図８の（Ｂ）に示すようにフルパス（符号ｂ）で記述する。
【００５６】
図５に戻り、加工済Ｗｅｂコンテンツ返信部２３４は、Ｗｅｂコンテンツ要求を送信した送信元の情報表示端末２０に、加工済みのＷｅｂコンテンツを返信する。具体的には、加工済Ｗｅｂコンテンツ返信部２３４は、加工済みのＷｅｂコンテンツをＷｅｂコンテンツ加工部２３３から受け付け、受け付けた加工済みのＷｅｂコンテンツを送信元の情報表示端末２０に返信する。
【００５７】
閲覧制御部２３５は、Ｗｅｂコンテンツ要求の送信元と通話を行っている利用者の情報表示端末２０においてＷｅｂコンテンツ要求に係るＷｅｂコンテンツが閲覧されるように制御する。具体的には、閲覧制御部２３５は、加工済みのＷｅｂコンテンツを閲覧するためのＵＲＬ情報、発着間紐付けＩＤ及び発着判定フラグをＷｅｂコンテンツ加工部２３３から受け付け、受け付けたＵＲＬ情報、発着間紐付けＩＤ及び発着判定フラグをセッション連携サーバ１００に送信する。
【００５８】
［ＨＧＷ１０］
次に、図９及び図１０を用いて、ＨＧＷ１０の構成を説明する。図９は、ＨＧＷの構成を示すブロック図であり、図１０は、ブラウザセッション情報管理テーブルを説明するための図である。図９に示すＨＧＷ１０は、以下に説明する各部が汎用的なゲートウェイ装置などに備えられることによって実現され、図９に示すように、ＳＩＰ通信部／ＨＴＴＰ通信部１１と、記憶部１２と、制御部１３とを備える。
【００５９】
ＳＩＰ通信部／ＨＴＴＰ通信部１１は、ＳＩＰ用及びＨＴＴＰ通信用の一般的なインタフェースおよびライブラリを備える。ＳＩＰ通信部／ＨＴＴＰ通信部１１は、ＳＩＰフォン３０とＳＩＰプロキシ（図示を省略）との間の通信、情報表示端末２０とプロキシサーバ２００との間の通信、ＨＧＷ１０とセッション連携サーバ１００との間の通信、ＨＧＷ１０とＳＩＰプロキシ（図示を省略）との間の通信、ＨＧＷ１０とプロキシサーバ２００との間の通信などを制御する。制御部１３は、ＨＧＷ１０における各種処理を制御する。
【００６０】
記憶部１２は、制御部１３における各種制御に用いられる情報を記憶し、図９に示すように、ブラウザセッション情報管理テーブル１２ａを備える。例えば、記憶部１２は、ＲＡＭ、ＲＯＭ、フラッシュメモリなどの半導体メモリ素子、または、ハードディスク、光ディスクなどである。
【００６１】
ブラウザセッション情報管理テーブル１２ａは、配下の情報表示端末２０に割り当てられたブラウザセッション情報を予め記憶する。例えば、ブラウザセッション情報管理テーブル１２ａは、図１０に示すように、ＳＩＰフォン３０を一意に識別する『ＳＩＰフォンＩＤ』と、ＳＩＰフォン３０と組で利用される情報表示端末２０を一意に識別する『情報表示端末ＩＤ』と、情報表示端末２０を特定するための『ブラウザセッション情報』とを対応づけて予め記憶する。また、ブラウザセッション情報管理テーブル１２ａは、ｃａｌｌセッション情報と、発着判定フラグとを対応付けて記憶している。ブラウザセッション情報管理テーブル１２ａが記憶するこれらの情報の内、ｃａｌｌセッション情報は、例えば、ＨＧＷ１０が収集し、登録したものである。発着判定フラグは、ＨＧＷ１０が、ＳＩＰによって確立された通信に含まれる情報から自ら生成した情報である。ＨＧＷ１０は、配下に接続するＳＩＰフォン３０を把握しているので、該当する呼が、発信であるのか、着信であるのかを判断することができる。
【００６２】
［ＳＩＰフォン３０］
次に、図１１を用いて、ＳＩＰフォン３０の構成を説明する。図１１は、ＳＩＰフォンの構成を示すブロック図である。ＳＩＰフォン３０は、汎用的なＳＩＰフォンによって実現され、図１１に示すように、入力部３２と、出力部３３と、入出力制御Ｉ／Ｆ部３４と、ＳＩＰ通信部３１とを備える。
【００６３】
いずれも汎用的なＳＩＰフォンと同様であるので簡単に説明すると、入力部３２は、ＳＩＰフォン３０に用いられる情報や、各種処理をするための操作指示などを、番号キーやマイクなどによって入力する。出力部３３は、ＳＩＰフォン３０による各種処理の結果や、各種処理をするための操作指示などを、ディスプレイやスピーカに出力する。入出力制御Ｉ／Ｆ部３４は、入力部３２と、出力部３３と、ＳＩＰ通信部３１との間における情報転送を制御する。ＳＩＰ通信部３１は、ＳＩＰ用の一般的なインタフェースおよびライブラリを備え、他方のＳＩＰフォン３０との間で（ＨＧＷ１０を介して）情報を送受信する。
【００６４】
［情報表示端末２０］
次に、図１２を用いて、情報表示端末２０の構成を説明する。図１２は、情報表示端末の構成を示すブロック図である。情報表示端末２０は、以下に説明する各部が汎用的なＰＣや情報家電などに備えられることによって実現され、図１２に示すように、入力部２２と、出力部２３と、入出力制御Ｉ／Ｆ部２４と、ＨＴＴＰ通信部２１と、制御部２５とを備える。
【００６５】
入力部２２は、情報表示端末２０に用いられる情報や、各種処理をするための操作指示などを、キーボード、マウス、リモコンなどによって入力する。出力部２３は、情報表示端末２０による各種処理の結果や、各種処理をするための操作指示などを、ディスプレイやプリンタなどに出力する。入出力制御Ｉ／Ｆ部２４は、入力部２２と、出力部２３と、ＨＴＴＰ通信部２１と、制御部２５との間における情報転送を制御する。ＨＴＴＰ通信部２１は、ＨＴＴＰ通信用の一般的なインタフェースおよびライブラリを備え、プロキシサーバ２００との間でＨＧＷ１０を介して情報を送受信する。
【００６６】
制御部２５は、図１２に示すように、Ｗｅｂコンテンツ閲覧部２５ａを備える。Ｗｅｂコンテンツ閲覧部２５ａは、プロキシサーバ２００から送信された加工済みのＷｅｂコンテンツを閲覧する。また、Ｗｅｂコンテンツ閲覧部２５ａは、セッション連携サーバ１００から送信された加工済みのＷｅｂコンテンツを閲覧するためのＵＲＬ情報にアクセスし、加工済みのＷｅｂコンテンツを閲覧する。
【００６７】
［実施例１に係るＷｅｂコンテンツ共有システムによる処理手順］
続いて、図１３〜図１７を用いて、実施例１に係るＷｅｂコンテンツ共有システムによる処理手順を説明する。図１３及び図１６は、実施例１に係るＷｅｂコンテンツ共有システムによる処理手順を説明するための図である。図１４、図１５及び図１７は、情報表示端末の出力画面を説明するための図である。
【００６８】
図１３に示すように、Ｗｅｂコンテンツ共有システムにおいて、まず、複数のユーザ間で通話が行われる（ステップＳ１０１）。例えば、ユーザ１（発側）とユーザ２（着側）との間でＳＩＰフォン３０を用いた通話が行われる。すなわち、まず、両ＳＩＰフォン３０間でＳＩＰ通信が行われ、その結果、ステップＳ１０１において、両ＳＩＰフォン３０間でＳＩＰによって通信が確立される。
【００６９】
両ＳＩＰフォン３０間でＳＩＰによって通信が確立されると、ＨＧＷ１０は、ＳＩＰによって確立された通信を一意に識別するｃａｌｌセッション情報を自ら収集し、また、発着判定フラグを生成する（ステップＳ１０２）。例えば、ＨＧＷ１０は、ｃａｌｌセッション情報としての『Ｃａｌｌ−ＩＤ』、『Ｆｒｏｍ（ＳＩＰ−ＵＲＩ）』及び『Ｔｏ（ＳＩＰ−ＵＲＩ）』を、ＳＩＰによって確立された通信に含まれる情報から自ら収集する。また、ＨＧＷ１０は、両ＳＩＰフォン３０が発側であるのか着側であるのかを示す『発着判定フラグ』を、ＳＩＰによって確立された通信に含まれる情報から自ら生成する。
【００７０】
なお、ステップＳ１０２に続いて、ＨＧＷ１０は、配下のＳＩＰフォン３０を一意に識別する情報であるＳＩＰフォンＩＤを、ＳＩＰ通信に含まれる情報から収集する。ＳＩＰフォンＩＤとは、例えば、ＳＩＰフォン３０の内線番号のことである。ＨＧＷ１０の配下に複数のＳＩＰフォン３０が接続される構成の場合、ＳＩＰ−ＵＲＩはＨＧＷ１０に対して付与され、ＨＧＷ１０配下のＳＩＰフォン３０各々には、内線番号が付与される。
【００７１】
そして、ＨＧＷ１０は、ステップＳ１０１においてＳＩＰによって通信を確立したＳＩＰフォン３０と組で利用される情報表示端末２０を特定する。具体的には、ＨＧＷ１０は、まず、ＳＩＰフォンＩＤをキーとしてブラウザセッション情報管理テーブル１２ａを検索することで情報表示端末２０を特定し、特定した情報表示端末２０のブラウザセッション情報と、ＨＧＷ１０に対してポーリングを行う複数の情報表示端末２０各々のブラウザセッション情報とを比較し、ブラウザセッション情報の一致によって、ＳＩＰによって通信を確立したＳＩＰフォン３０と組で利用される情報表示端末２０を特定する。
【００７２】
図１３に戻り、ＨＧＷ１０は、アクセス先変更指示を、特定した情報表示端末２０に対して行う。具体的には、特定した情報表示端末２０に対して、セッション連携サーバ１００のＵＲＬにアクセス先を変更するよう指示するリダイレクト指示を、ｃａｌｌセッション情報及び発着判定フラグとともに行う（ステップＳ１０３）。なお、実施例１においては、ＨＧＷ１０がセッション連携サーバ１００のＵＲＬ情報を予め記憶部に記憶していることで、セッション連携サーバ１００のＵＲＬにアクセス先を変更するようリダイレクト指示を行うことができる。この結果、情報表示端末２０は、リダイレクト指示を受け、ＨＧＷ１０のＵＲＬからセッション連携サーバ１００のＵＲＬにアクセス先を変更する。
【００７３】
すると、情報表示端末２０はリダイレクトされ、接続先をセッション連携サーバ１００に変更する（ステップＳ１０３）。この時、情報表示端末２０は、ｃａｌｌセッション情報及び発着判定フラグを、セッション連携サーバ１００に送信することになる。
【００７４】
一方、セッション連携サーバ１００のｃａｌｌセッション情報収集部１３１は、制御用セッション情報を発行し、発行した制御用セッション情報を制御用セッション情報管理テーブル１２１に格納する（ステップＳ１０４）。具体的には、ｃａｌｌセッション情報収集部１３１は、情報表示端末２０から送信されたｃａｌｌセッション情報及び発着判定フラグを受信すると、ｃａｌｌセッション情報、発着判定フラグ、及び通話履歴情報としての開始時刻を制御用セッション情報管理テーブル１２１に格納する。そして、ｃａｌｌセッション情報収集部１３１は、制御用セッション情報を発行し、発行した制御用セッション情報を制御用セッション情報管理テーブル１２１に格納する。
【００７５】
なお、ステップＳ１０４に続いて、ｃａｌｌセッション情報収集部１３１は、制御ページを生成し、情報表示端末２０に対して、ステップＳ１０４で発行した制御用セッション情報と、生成した制御ページとを送信する。
【００７６】
すると、情報表示端末２０は、セッション連携サーバ１００から送信された制御ページをＷｅｂブラウザから表示する（ステップＳ１０５）。例えば、情報表示端末２０は、図１４の（Ａ）に示す制御ページをＷｅｂブラウザから表示する。図１４は、情報表示端末の出力画面を説明するための図である。なお、着側の情報表示端末２０についても同様の処理が行われ、例えば、着側の情報表示端末２０は、図１４の（Ｂ）に示す制御ページをＷｅｂブラウザから表示する。
【００７７】
続いて、図１４の（Ａ）に示すように、情報表示端末２０のユーザが、Ｗｅｂブラウザに表示された制御ページの中からサービス（『Ｗｅｂでいっしょ』）を選択することで（ステップＳ１０６）、情報表示端末２０のＷｅｂコンテンツ閲覧部２５ａは、Ｗｅｂコンテンツの共有サービス開始要求をセッション連携サーバ１００に対して送信する（ステップＳ１０７）。この時、Ｗｅｂコンテンツ閲覧部２５ａは、ステップＳ１０４において送信された制御用セッション情報を用いて、選択したサービス（『Ｗｅｂでいっしょ』）のサービスＩＤをセッション連携サーバ１００に対して送信する。
【００７８】
すると、セッション連携サーバ１００の発着間紐付けＩＤ発行部１３２は、情報表示端末２０から送信された制御用セッション情報が、制御用セッション情報管理テーブル１２１に登録されているものであることを確認し、発着間紐付けＩＤを発行する（ステップＳ１０８）。
【００７９】
次に、発着間紐付けＩＤ発行部１３２は、情報表示端末２０に対して、プロキシサーバ２００のＵＲＬ情報、発着間紐付けＩＤ及び発着判定フラグを送信する（ステップＳ１０９）。すると、例えば、情報表示端末２０は、図１５の（Ａ）に示すページをＷｅｂブラウザから表示する。図１５は、情報表示端末の出力画面を説明するための図である。なお、着側の情報表示端末２０は、図１５の（Ｂ）に示すように、図１４の（Ｂ）に示す制御ページをＷｅｂブラウザから表示したままである。
【００８０】
続いて、図１５の（Ａ）に示すように、情報表示端末２０のユーザが、Ｗｅｂブラウザに表示されたページに、Ｗｅｂコンテンツの閲覧を要求するＷｅｂサイトのＵＲＬ情報（『http://www.a-site.ne.jp』）を入力する。すると、情報表示端末２０のＷｅｂコンテンツ閲覧部２５ａは、セッション連携サーバ１００から送信されたプロキシサーバ２００のＵＲＬにアクセスし、Ｗｅｂコンテンツ要求を発着間紐付けＩＤとともにプロキシサーバ２００に送信する（ステップＳ１１０）。例えば、Ｗｅｂコンテンツ閲覧部２５ａは、ＷｅｂサイトのＵＲＬ情報、セッション連携サーバ１００から送信された発着間紐付けＩＤ、発着判定フラグ、及び通知モードの指定を、プロキシサーバ２００に送信する。
【００８１】
ここで、通知モードの指定とは、情報表示端末２０において相互にＷｅｂコンテンツを共有させるモード（両者モード）とするか、あるいは、一方の情報表示端末２０のページ遷移に他方の情報表示端末２０のページ遷移を追従させるがその反対は追従させないモード（一方モード）とするかを指定するものである。両者モードが指定された場合には、他方の情報表示端末２０においても加工済みのＷｅｂコンテンツが閲覧されるように制御される。一方モードが指定された場合には、他方の情報表示端末２０においては直接Ｗｅｂサーバにアクセスして通常のＷｅｂコンテンツが閲覧されるように制御される。実施例１においては、両者モードを指定するものとして説明する。なお、通知モードの指定は、発着判定フラグを用いて行ってもよい。
【００８２】
すると、プロキシサーバ２００のＷｅｂコンテンツ要求受付部２３１が、Ｗｅｂコンテンツ要求を情報表示端末２０から受け付け、Ｗｅｂコンテンツ取得部２３２が、Ｗｅｂコンテンツ要求によって指定されたＷｅｂサーバからＷｅｂコンテンツを取得する（ステップＳ１１１）。
【００８３】
次に、Ｗｅｂコンテンツ加工部２３３が、Ｗｅｂコンテンツに他のＷｅｂコンテンツに遷移するためのリンク情報が含まれている場合には、Ｗｅｂコンテンツを加工する（ステップＳ１１２）。
【００８４】
そして、加工済Ｗｅｂコンテンツ返信部２３４が、Ｗｅｂコンテンツ要求を送信した送信元の情報表示端末２０に、加工済みのＷｅｂコンテンツを返信する（ステップＳ１１３）。この時、送信元の情報表示端末２０のブラウザには、例えば、図１７の（Ａ）に示すＷｅｂコンテンツが表示される。
【００８５】
また、閲覧制御部２３５が、ステップＳ１１０において受け付けた通知モードを判定する（ステップＳ１１４）。ここで、実施例１においては、通知モードとして『両者モード』が指定されているので、閲覧制御部２３５は、Ｗｅｂコンテンツ要求の送信元と通話を行っている利用者の情報表示端末２０におけるＷｅｂコンテンツの閲覧も共有の対象となるように制御する。
【００８６】
まず、閲覧制御部２３５は、加工済みのＷｅｂコンテンツを閲覧するためのＵＲＬ情報、発着間紐付けＩＤ及び発着判定フラグをセッション連携サーバ１００に送信する（ステップＳ１１５）。すると、セッション連携サーバ１００のＵＲＬ通知部１３３が、プロキシサーバ２００から受信した発着間紐付けＩＤ及び発着間紐付けＩＤに基づきＷｅｂコンテンツ要求の送信元と通話を行っているユーザの情報表示端末２０を特定する（ステップＳ１１６）。
【００８７】
そして、ＵＲＬ通知部１３３は、特定した情報表示端末２０に対して、プロキシサーバ２００から受信したＵＲＬ情報を送信する（ステップＳ１１７）。こうして、ＵＲＬ情報を受信した情報表示端末２０が、受信したＵＲＬにアクセスしてＷｅｂコンテンツを取得すると、情報表示端末２０のブラウザには、例えば、図１７の（Ｂ）に示すＷｅｂコンテンツが表示される。
【００８８】
なお、ステップＳ１１７においてＵＲＬ情報を受信した情報表示端末２０によるＷｅｂコンテンツ要求が、既に同期された側の情報表示端末２０によるＷｅｂコンテンツ要求であることを区別するために、Ｗｅｂコンテンツ要求に何らかのパラメータを併せて送信するようにしてもよい。このようにすることで、ページ遷移が無限に繰り返される状態を回避することができる。
【００８９】
ここで、ステップＳ１１３において情報表示端末２０に返信されたＷｅｂコンテンツや、ステップＳ１１７においてＵＲＬ情報を受信した情報表示端末２０が取得するＷｅｂコンテンツは、ＷｅｂコンテンツのＵＲＬ情報が情報表示端末２０において変更された場合に、他のＷｅｂコンテンツのＵＲＬ情報を発着間紐付けＩＤとともにプロキシサーバ２００に通知するように加工されたものである。したがって、プロキシサーバ２００のＷｅｂコンテンツ要求受付部２３１は、ＷｅｂコンテンツのＵＲＬ情報が情報表示端末２０において変更された場合に、再び、他のＷｅｂコンテンツのＵＲＬ情報を発着間紐付けＩＤとともに情報表示端末２０から受け付ける。すなわち、ステップＳ１１１に処理は戻り、ステップＳ１１１〜ステップＳ１１７の処理が繰り返されることになる。なお、発着双方の情報表示端末２０が対象となる。すなわち、例えば、ステップＳ１１７においてＵＲＬ情報を受信した側の情報表示端末２０においてＷｅｂコンテンツのＵＲＬ情報が変更された場合には、今度は、ステップＳ１１３においてＷｅｂコンテンツを返信された側の情報表示端末２０が、追従してページ遷移することになる。
【００９０】
［実施例１の効果］
上記したように、実施例１に係るＷｅｂコンテンツ共有システムにおいては、複数のユーザ間で通話が行われると、セッション連携サーバ１００の発着間紐付けＩＤ発行部１３２が、ユーザ間でＷｅｂコンテンツのＵＲＬ情報を連携するための発着間紐付けＩＤをユーザの情報表示端末２０それぞれに対して発行する。また、プロキシサーバ２００のＷｅｂコンテンツ要求受付部２３１が、所定のＷｅｂサーバが発信するＷｅｂコンテンツを要求するＷｅｂコンテンツ要求を、発着間紐付けＩＤ発行部１３２によって発行された発着間紐付けＩＤとともに情報表示端末２０から受け付ける。また、Ｗｅｂコンテンツ取得部２３２及びＷｅｂコンテンツ加工部２３３が、所定のＷｅｂサーバが発信するＷｅｂコンテンツを取得し、他のＷｅｂコンテンツに遷移するためのリンク情報が指定されることによりＷｅｂコンテンツのＵＲＬ情報が情報表示端末２０において変更された場合に、ＷｅｂコンテンツのＵＲＬ情報を発着間紐付けＩＤとともにＷｅｂコンテンツ要求受付部２３１に通知するように、取得したＷｅｂコンテンツを加工する。また、加工済Ｗｅｂコンテンツ返信部２３４が、Ｗｅｂコンテンツ加工部２３３よって加工されたＷｅｂコンテンツを、Ｗｅｂコンテンツ要求の送信元の情報表示端末２０に返信する。
【００９１】
また、プロキシサーバ２００の閲覧制御部２３５及びセッション連携サーバ１００のＵＲＬ通知部１３３が、Ｗｅｂコンテンツ要求受付部２３１によって受け付けられた発着間紐付けＩＤに基づいて、Ｗｅｂコンテンツ要求の送信元と通話を行っているユーザの情報表示端末２０を特定し、特定した情報表示端末２０においてＷｅｂコンテンツ要求に係るＷｅｂコンテンツが閲覧されるように制御する。また、Ｗｅｂコンテンツ要求受付部２３１が、ＷｅｂコンテンツのＵＲＬ情報が通話を行っているユーザの情報表示端末２０いずれか一方より変更された場合に、ＵＲＬ情報を発着間紐付けＩＤとともに情報表示端末２０から受け付ける。また、プロキシサーバ２００の閲覧制御部２３５及びセッション連携サーバ１００のＵＲＬ通知部１３３が、Ｗｅｂコンテンツ要求受付部２３１によって受け付けられたＵＲＬ情報及び発着間紐付けＩＤに基づいて、ＵＲＬ情報の送信元の情報表示端末２０と、送信元と通話を行っているユーザの情報表示端末２０との間において、ＷｅｂコンテンツのＵＲＬ情報が連携されるように制御する。
【００９２】
このようなことから、実施例１に係るＷｅｂコンテンツ共有システムによれば、既存のＷｅｂコンテンツを共有することが可能になり、ユーザの情報表示端末において閲覧するＷｅｂコンテンツのページが遷移した場合には、遷移に追従してＷｅｂコンテンツを共有することが可能になる。
【００９３】
また、既存のＷｅｂコンテンツを共有することが可能になる結果、ユーザが共有することのできるＷｅｂコンテンツの数が飛躍的に増加する（現時点にて、Ｗｅｂサイトの数は、約２億４千万ほどである）。
【００９４】
また、図１３のステップＳ１０９で説明したように、セッション連携サーバ１００によってプロキシサーバ２００のＵＲＬ情報が通知されるので、ユーザは、情報表示端末２０に対してプロキシサーバ２００の設定をする必要がなく、また、ブラウザに新たな機能を追加する必要もない。
【００９５】
また、プロキシサーバ２００は、発着間紐付けＩＤを用いて動作する仕組みであるので、発着間紐付けＩＤが発行されたユーザからのＷｅｂコンテンツ要求のみを受け付けることになる。
【実施例２】
【００９６】
さて、実施例１においては、Ｗｅｂコンテンツ要求として受け付けたＷｅｂコンテンツ全てを共有の対象とする手法を説明した。この点、実施例２においては、既存のＷｅｂコンテンツのＵＲＬ情報をホワイトリストに予め登録することで、Ｗｅｂコンテンツの共有可否を制御する手法を説明する。
【００９７】
［実施例２におけるプロキシサーバ２００の構成］
まず、図１８及び図１９を用いて、実施例２におけるプロキシサーバ２００の構成を説明する。図１８は、プロキシサーバの構成を示すブロック図であり、図１９は、ホワイトリストテーブルを説明するための図である。
【００９８】
図１８に示すように、実施例２におけるプロキシサーバ２００は、記憶部２２０に、特に、ホワイトリストテーブル２２１を備える。ホワイトリストテーブル２２１は、ＷｅｂコンテンツのＵＲＬ情報をリスト形式で記憶する。また、ホワイトリストテーブル２２１が記憶するＵＲＬ情報は、Ｗｅｂコンテンツ取得部２３２による処理に利用される。なお、ホワイトリストテーブル２２１に対するＵＲＬ情報の登録は、Ｗｅｂコンテンツ共有システムの運用者などによって事前に行われる。例えば、ホワイトリストテーブル２２１は、図１９に示すように、ＵＲＬ情報を記憶する。なお、図１９に示す『ＩＤ』は、リストの通し番号である。
【００９９】
実施例２におけるＷｅｂコンテンツ取得部２３２は、実施例１と同様、Ｗｅｂコンテンツ要求によって指定されたＷｅｂサーバからＷｅｂコンテンツを取得するが、実施例１と異なり、Ｗｅｂコンテンツ要求に係るＷｅｂコンテンツのＵＲＬ情報がホワイトリストテーブル２２１に登録されているか否かをまず判定し、登録されている場合にのみ、Ｗｅｂコンテンツを取得する。
【０１００】
［実施例２に係るＷｅｂコンテンツ共有システムによる処理手順］
図２０を用いて、実施例２に係るＷｅｂコンテンツ共有システムによる処理手順を説明する。図２０は、実施例２に係るＷｅｂコンテンツ共有システムによる処理手順を説明するための図である。もっとも、図２０は、実施例２に係るＷｅｂコンテンツ共有システムによる処理手順の一部を示すものである。すなわち、実施例２に係るＷｅｂコンテンツ共有システムにおいても、実施例１と同様、まず、図１３のステップＳ１０１からＳ１０９までの処理手順が実行される。その後、実施例１のステップＳ１１０の代わりに、図２０に示すステップＳ１１０−１、Ｓ１１０−２が実行され、その後は実施例１と同様に、ステップＳ１１１以降の処理手順が実行される。言い換えると、実施例２に係るＷｅｂコンテンツ共有システムにおいては、特に、ステップＳ１１０−２が実行される。
【０１０１】
そこで、図２０を用いて、ステップＳ１１０−１以降を説明すると、実施例１と同様、プロキシサーバ２００のＷｅｂコンテンツ要求受付部２３１は、Ｗｅｂコンテンツ要求を発着間紐付けＩＤとともに情報表示端末２０から受け付ける（ステップＳ１１０−１）。
【０１０２】
ここで、実施例１においては、Ｗｅｂコンテンツ取得部２３２は、直ちにＷｅｂコンテンツ要求によって指定されたＷｅｂサーバからＷｅｂコンテンツを取得したが、実施例２においては、Ｗｅｂコンテンツを取得する前に、ステップＳ１１０−２の判定を行う。
【０１０３】
具体的には、Ｗｅｂコンテンツ取得部２３２は、Ｗｅｂコンテンツ要求に係るＷｅｂコンテンツのＵＲＬ情報がホワイトリストテーブル２２１に登録されているか否かをまず判定し（ステップＳ１１０−２）、登録されている場合にのみ、Ｗｅｂコンテンツを取得する（ステップＳ１１１）。
【０１０４】
一方、Ｗｅｂコンテンツ要求に係るＷｅｂコンテンツのＵＲＬ情報がホワイトリストテーブル２２１に登録されていない場合には、Ｗｅｂコンテンツ取得部２３２は、Ｗｅｂコンテンツの閲覧が許可されていない旨を通知する制御用ページを、Ｗｅｂコンテンツ要求の送信元の情報表示端末２０に返信する。なお、閲覧制御部２３５は、同じ制御用ページが通話相手の情報表示端末２０において閲覧されるように制御してもよい。
【０１０５】
また、既存のＷｅｂコンテンツのＵＲＬ情報をホワイトリストに登録する手法を説明してきたが、本発明はこれに限られるものではない。ブラックリストに登録する手法にも同様に適用することができる。この場合には、Ｗｅｂコンテンツ取得部２３２は、Ｗｅｂコンテンツ要求に係るＷｅｂコンテンツのＵＲＬ情報がブラックリストテーブルに登録されているか否かをまず判定し、登録されていない場合にのみ、Ｗｅｂコンテンツを取得する。
【０１０６】
［実施例２の効果］
上記してきたように、実施例２に係るＷｅｂコンテンツ共有システムにおいては、プロキシサーバ２００が、ＷｅｂコンテンツのＵＲＬ情報をリスト形式で記憶するリストテーブルをさらに備える。そして、Ｗｅｂコンテンツ取得部２３２は、Ｗｅｂコンテンツ要求によって指定されたＷｅｂコンテンツのＵＲＬ情報がリストテーブルに登録されているか否かをさらに判定し、判定結果が、Ｗｅｂコンテンツの閲覧を許可することを示す場合にのみ、所定のＷｅｂサーバからＷｅｂコンテンツを取得する。
【０１０７】
このようなことから、実施例２によれば、既存のＷｅｂコンテンツのＵＲＬ情報をリストに予め登録することで、Ｗｅｂコンテンツの共有可否を制御することが可能になる。例えば、既存のＷｅｂサイトの中には、フィッシングサイトなど悪意のあるサイトも存在する。ホワイトリストやブラックリストを予め登録することで、このような悪意のあるサイトが提供するＷｅｂコンテンツを閲覧しないように制御することが可能になる。言い換えると、安全なサイトが提供するＷｅｂコンテンツのみを閲覧するように制御することが可能になる。
【実施例３】
【０１０８】
さて、実施例２においては、既存のＷｅｂコンテンツのＵＲＬ情報をリストに予め登録することで、Ｗｅｂコンテンツの共有可否を制御する手法を説明した。実施例３においては、単にＵＲＬ情報をリストに登録するのみならず、リストの適用ユーザ範囲を指定するデータ（電話番号など）をさらに登録することで、Ｗｅｂコンテンツの共有可否をユーザ単位で制御する手法を説明する。
【０１０９】
［実施例３におけるプロキシサーバ２００の構成］
まず、図２１及び図２２を用いて、実施例３におけるプロキシサーバ２００の構成を説明する。図２１は、プロキシサーバの構成を示すブロック図であり、図２２は、ユーザ情報付ホワイトリストテーブルを説明するための図である。
【０１１０】
図２１に示すように、実施例３におけるプロキシサーバ２００は、記憶部２２０に、特に、ユーザ情報付ホワイトリストテーブル２２２を備える。ユーザ情報付ホワイトリストテーブル２２２は、ＷｅｂコンテンツのＵＲＬ情報とユーザの識別情報とを対応付けてリスト形式で記憶する。また、ユーザ情報付ホワイトリストテーブル２２２が記憶する情報は、Ｗｅｂコンテンツ取得部２３２による処理に利用される。なお、ユーザ情報付ホワイトリストテーブル２２２に対する情報の登録は、Ｗｅｂコンテンツ共有システムの運用者などによって事前に行われる。
【０１１１】
例えば、ユーザ情報付ホワイトリストテーブル２２２は、図２２に示すように、ユーザの電話番号（『ｕｓｅｒＩＤ』）とＵＲＬ情報とを対応付けて記憶する。なお、図２２に示す『ＩＤ』は、リストの通し番号である。また、ユーザを識別する情報は電話番号に限られず、他の情報であってもよい。
【０１１２】
実施例３におけるＷｅｂコンテンツ取得部２３２は、実施例１と同様、Ｗｅｂコンテンツ要求によって指定されたＷｅｂサーバからＷｅｂコンテンツを取得するが、実施例１と異なり、Ｗｅｂコンテンツ要求によって指定されたＷｅｂコンテンツのＵＲＬ情報がユーザ情報付ホワイトリストテーブル２２２に登録されているか否か、及び、Ｗｅｂコンテンツ要求を送信した送信元がＵＲＬ情報に対応付けてユーザ情報付ホワイトリストテーブル２２２に登録されているか否かをまず判定する。そして、Ｗｅｂコンテンツ取得部２３２は、登録されている場合にのみ、Ｗｅｂコンテンツを取得する。
【０１１３】
例えば、Ｗｅｂコンテンツ取得部２３２は、ＷｅｂコンテンツのＵＲＬ情報がユーザ情報付ホワイトリストテーブル２２２に登録されているか否か、及び、Ｗｅｂコンテンツ要求を送信した送信元の電話番号がＵＲＬ情報に対応付けてユーザ情報付ホワイトリストテーブル２２２に登録されているか否かをまず判定する。ここで、Ｗｅｂコンテンツ取得部２３２がユーザの電話番号をどのように割り出すかであるが、例えば、Ｗｅｂコンテンツ要求とともに受け取った発着間紐付けＩＤ及び発着判定フラグを用いてセッション連携サーバ１００に問い合わせを行い、セッション連携サーバ１００から電話番号の回答を受け取ることで割り出してもよい。
【０１１４】
なお、ユーザ情報付ホワイトリストテーブル２２２は、例えば、発着ユーザの電話番号の組合せとＵＲＬ情報とを対応付けて記憶してもよい。この場合には、Ｗｅｂコンテンツ取得部２３２は、ＷｅｂコンテンツのＵＲＬ情報がユーザ情報付ホワイトリストテーブル２２２に登録されているか否か、及び、Ｗｅｂコンテンツ要求を送信した送信元の電話番号と通話相手の電話番号とがＵＲＬ情報に対応付けてユーザ情報付ホワイトリストテーブル２２２に登録されているか否かを判定する。
【０１１５】
また、ユーザ情報付ホワイトリストテーブル２２２は、例えば、Ｗｅｂコンテンツ要求の送信元の通話相手となるユーザの電話番号とＵＲＬ情報とを対応付けて記憶してもよい。この場合には、Ｗｅｂコンテンツ取得部２３２は、ＷｅｂコンテンツのＵＲＬ情報がユーザ情報付ホワイトリストテーブル２２２に登録されているか否か、及び、Ｗｅｂコンテンツ要求を送信した送信元の通話相手の電話番号がＵＲＬ情報に対応付けてユーザ情報付ホワイトリストテーブル２２２に登録されているか否かを判定する。
【０１１６】
例えば、Ａ社のコールセンタとユーザとの間で通話が行われる場合に、Ａ社のコールセンタとユーザとの間で共有可能なＷｅｂコンテンツをＡ社が提供するＷｅｂコンテンツに限定する、といった通話者の関係に基づく制御が可能になる。すなわち、ユーザ情報付ホワイトリストテーブル２２２が、Ａ社のコールセンタの電話番号と、Ａ社が提供するＷｅｂコンテンツを閲覧するためのＵＲＬ情報とを対応付けて記憶すればよい。
【０１１７】
より具体的に例を挙げて説明する。例えば、ユーザ情報付ホワイトリストテーブル２２２が、２種類のホワイトリストを記憶するものとする。１つのホワイトリストは、Ａ社のコールセンタの電話番号と、Ａ社が提供するＷｅｂコンテンツを閲覧するためのＵＲＬ情報『ｓｉｔｅＡ』とが対応付けられたホワイトリストである。このホワイトリストは、発着ユーザの電話番号にＡ社のコールセンタの電話番号が含まれている場合には、『ｓｉｔｅＡ』が提供するＷｅｂコンテンツの閲覧のみが許可されることを意味するものとする。また、もう１つのホワイトリストは、ユーザＢの電話番号と、『ｓｉｔｅＢ』、『ｓｉｔｅＣ』とが対応付けられたホワイトリストである。後者のホワイトリストは、発着ユーザの電話番号にユーザＢの電話番号が含まれている場合には、『ｓｉｔｅＢ』、『ｓｉｔｅＣ』が提供するＷｅｂコンテンツの閲覧が許可されていることを意味するものとする。また、２つのホワイトリスト間に優先度を設け、前者のホワイトリストが後者のホワイトリストに優先するものとして設定されているとする。
【０１１８】
このような構成の下、例えば、Ａ社のコールセンタとユーザＢとの間で通話が行われるとする。すると、Ｗｅｂコンテンツ取得部２３２は、優先度の高い前者のホワイトリストに従って制御を行い、この結果、ユーザＢは、Ａ社のコールセンタとの通話中は、『ｓｉｔｅＡ』が提供するＷｅｂコンテンツの閲覧しか許可されないことになる。
【０１１９】
あるいは、例えば、後者のホワイトリストに、ユーザＣの電話番号が登録されていなかったとする。すなわち、ユーザＣは、すべてのＷｅｂコンテンツの閲覧が許可されていないことを意味するものとする。このような場合であっても、前者のホワイトリストが後者のホワイトリストに優先するものとして設定されていれば、例えば、Ａ社のコールセンタとユーザＣとの間で通話が行われた結果、ユーザＣは、Ａ社のコールセンタとの通話中は、『ｓｉｔｅＡ』が提供するＷｅｂコンテンツの閲覧が許可されることになる。
【０１２０】
なお、上述してきた例は一例に過ぎず、ホワイトリストの構成や優先度の設定方法などは任意に変更し得るものである。また、ホワイトリストに優先度を設ける手法を説明したが、例えばユーザの電話番号に優先度を設ける手法などでもよい。例えば、Ａ社のコールセンタの電話番号が、一般のユーザＢやユーザＣの電話番号よりも優先度が高いものとして設定されているとする。すると、発着ユーザの電話番号に含まれている２つの電話番号を比較し、優先度の高いＡ社のコールセンタの電話番号に従ってホワイトリストを用いた制御を行う、といった手法が考えられる。
【０１２１】
また、実施例３においては、既存のＷｅｂコンテンツのＵＲＬ情報をホワイトリストに登録する手法を説明してきたが、本発明はこれに限られるものではない。ブラックリストに登録する手法にも同様に適用することができる。
【０１２２】
［実施例３の効果］
上記してきたように、実施例３に係るＷｅｂコンテンツ共有システムにおいては、プロキシサーバ２００が、ＷｅｂコンテンツのＵＲＬ情報とユーザの識別情報とを対応付けてリスト形式で記憶するユーザ情報付リストテーブルをさらに備える。そして、Ｗｅｂコンテンツ取得部２３２は、Ｗｅｂコンテンツ要求によって指定されたＷｅｂコンテンツのＵＲＬ情報がユーザ情報付リストテーブルに登録されているか否か、及び、Ｗｅｂコンテンツ要求を送信した送信元がＵＲＬ情報に対応付けてユーザ情報付リストテーブルに登録されているか否かをさらに判定し、判定結果が、Ｗｅｂコンテンツの閲覧を許可することを示す場合にのみ、所定のＷｅｂサーバからＷｅｂコンテンツを取得する。
【０１２３】
このようなことから、実施例３によれば、単にＵＲＬ情報をリストに登録するのみならず、リストの適用ユーザ範囲を指定するデータ（電話番号など）をさらに登録することで、Ｗｅｂコンテンツの共有可否をユーザ単位で制御することが可能になる。
【実施例４】
【０１２４】
さて、これまで実施例１〜３においては、既存のＷｅｂコンテンツを共有する形態として「ページ遷移の同期」を例に挙げて説明してきた。しかしながら本発明はこれに限られるものではなく、「ページ内での操作の同期」も実現できる。例えば、一方のユーザの情報表示端末においてマウスが操作されたり文字が入力されたりすると、他方のユーザの情報表示端末において閲覧されるＷｅｂコンテンツに、このマウスの移動や入力された文字が表示される形態である。
【０１２５】
以下、実施例４として、マウス操作の同期を例に「ページ内での操作の同期」を説明する。実施例４に係るＷｅｂコンテンツ共有システムは、複数のユーザ間でＷｅｂコンテンツに係る情報を連携することで、Ｗｅｂコンテンツを共有する。Ｗｅｂコンテンツに係る情報とは、例えば、マウスポインタの座標情報である。すなわち、実施例４に係るＷｅｂコンテンツ共有システムは、複数のユーザ間でマウスポインタの座標情報を連携することで、ページ内での操作を同期する。
【０１２６】
［実施例４におけるプロキシサーバ２００の構成］
まず、図２３〜図２６を用いて、実施例４におけるプロキシサーバ２００の構成を説明する。図２３は、プロキシサーバの構成を示すブロック図であり、図２４は、共有データテーブルを説明するための図であり、図２５及び図２６は、マウスポインタ共有プログラムを説明するための図である。
【０１２７】
図２３に示すように、実施例４におけるプロキシサーバ２００は、記憶部２２０に、特に、共有データテーブル２２３を備える。また、プロキシサーバ２００は、制御部２３０に、特に、共有データ受付部２３６と、共有データ要求受付部２３７と、共有データ返信部２３８とを備える。
【０１２８】
共有データテーブル２２３は、ユーザの情報表示端末２０において操作された操作情報を記憶する。具体的には、共有データテーブル２２３は、共有データ受付部２３６によって受け付けられた操作情報を発着間紐付けＩＤ及び発着判定フラグと対応付けて記憶する。また、共有データテーブル２２３が記憶する操作情報は、共有データ要求受付部２３７や共有データ返信部２３８による処理に利用される。
【０１２９】
例えば、共有データテーブル２２３は、図２４に示すように、ＩＤと、マウスポインタの座標情報（『座標Ｘ』、『座標Ｙ』）と、発着間紐付けＩＤと、発着判定フラグと、タイムスタンプ（『timestamp』）とを対応付けて記憶する。なお、実施例４においては、共有データ受付部２３６によって受け付けられたマウスポインタの座標情報をテーブル形式で記憶する手法を説明したが、これに限られるものではなく、例えば、発着間紐付けＩＤ及び発着判定フラグ毎のファイル形式で記憶する手法などでもよい。
【０１３０】
共有データ受付部２３６は、操作情報を発着間紐付けＩＤ及び発着判定フラグとともに情報表示端末２０から受け付け、共有データテーブル２２３に格納する。共有データ要求受付部２３７は、操作情報を要求する操作情報要求を発着間紐付けＩＤ及び発着判定フラグとともに情報表示端末２０から受け付ける。
【０１３１】
共有データ返信部２３８は、共有データ要求受付部２３７によって操作情報要求が受け付けられると、操作情報要求とともに受け付けた発着間紐付けＩＤ及び発着判定フラグを用いて共有データ受付部２３６を検索する。そして、共有データ返信部２３８は、操作情報要求の送信元と通話を行っているユーザの操作情報を、送信元の情報表示端末２０に返信する。
【０１３２】
また、実施例４におけるＷｅｂコンテンツ加工部２３３は、操作情報が情報表示端末２０において変更された場合に、操作情報を発着間紐付けＩＤとともに共有データ受付部２３６に通知するように、Ｗｅｂコンテンツを加工する。具体的には、Ｗｅｂコンテンツ加工部２３３は、Ｗｅｂコンテンツを加工する際に、マウスポインタ共有プログラムを挿入する。ここで、マウスポインタ共有プログラムは、ユーザの情報表示端末２０においてマウスポインタの座標情報を取得するとともに、取得したマウスポインタの座標情報が発着間紐付けＩＤ及び発着判定フラグとともに共有データ受付部２３６によって受け付けられるようにするためのプログラムである。また、マウスポインタ共有プログラムは、操作情報要求が発着間紐付けＩＤ及び発着判定フラグとともに共有データ要求受付部２３７によって受け付けられるようにするためのプログラムである。
【０１３３】
例えば、マウスポインタ共有プログラムは、ＪａｖａＳｃｒｉｐｔ（登録商標）などのスクリプトによって実現され、図２５及び図２６に示すように、Ｗｅｂコンテンツ加工部２３３によってＷｅｂコンテンツに挿入される。
【０１３４】
例えば、Ｗｅｂコンテンツ加工部２３３は、Ｗｅｂコンテンツ取得部２３２によって取得されたＷｅｂコンテンツのＨＴＭＬタグを解析し、図２５の（Ａ）に示すように、ｈｅａｄタグの終了（＜／ｈｅａｄ＞）が記述された箇所を特定する。次に、Ｗｅｂコンテンツ加工部２３３は、図２５の（Ｂ）に示すように、特定した箇所に、スクリプトファイルのパスを挿入する。
【０１３５】
続いて、例えば、Ｗｅｂコンテンツ加工部２３３は、Ｗｅｂコンテンツ取得部２３２によって取得されたＷｅｂコンテンツのＨＴＭＬタグを解析し、図２６の（Ａ）に示すように、ｂｏｄｙタグの終了（＜／ｂｏｄｙ＞）が記述された箇所を特定する。そして、Ｗｅｂコンテンツ加工部２３３は、図２６の（Ｂ）に示すように、特定した箇所に、マウスポインタ画像のＵＲＩ（符号ａ）と、共有データ要求受付部２３７に定期的にポーリングするためのポーリングスクリプト（符号ｂ）とを挿入する。なお、上述では、マウスポインタ共有プログラムがＪａｖａＳｃｒｉｐｔ（登録商標）によって実現される手法を説明したので、ｈｅａｄタグの終了（＜／ｈｅａｄ＞）やｂｏｄｙタグの終了（＜／ｂｏｄｙ＞）が記述された箇所を特定し、特定した箇所に挿入する手法を説明したが、これに限られるものではない。スクリプトを動作させるための一般的なルールに沿って、然るべき箇所に挿入することが必要である。
【０１３６】
［実施例４に係るＷｅｂコンテンツ共有システムによる処理手順］
続いて、図２７を用いて、実施例４に係るＷｅｂコンテンツ共有システムによる処理手順を説明する。図２７は、実施例４に係るＷｅｂコンテンツ共有システムによる処理手順を説明するための図である。
【０１３７】
実施例４においては、例えば、図１４の（Ａ）や（Ｂ）に示す制御ページにおいて、情報表示端末２０のユーザそれぞれが既に『Ｗｅｂでいっしょ』を選択し、さらに、図１５の（Ａ）に示す画面と同様の画面にて、情報表示端末２０のユーザそれぞれがマウスポインタ共有を有効にする選択を既にしたことを想定している。
【０１３８】
すると、情報表示端末２０それぞれに加工済みのＷｅｂコンテンツが返信され、返信された加工済みのＷｅｂコンテンツには、上記したように、マウスポインタ共有プログラムが挿入されている。このため、加工済みのＷｅｂコンテンツを受信した情報表示端末２０それぞれは、ポーリングスクリプトにより、図２７のステップＳ２０１に示すように、例えば０．５秒間隔などで、プロキシサーバ２００の共有データ要求受付部２３７にポーリングする。なお、図２７において点線で示す矢印は、ポーリングであることを示す。
【０１３９】
例えば、発側のユーザの情報表示端末２０においてマウスが操作されたとする。すると、情報表示端末２０は、スクリプトにより、マウスポインタの座標情報を発着間紐付けＩＤ及び発着判定フラグとともに送信し、プロキシサーバ２００の共有データ受付部２３６がこれを受け付け、共有データテーブル２２３に格納する（ステップＳ２０２）。
【０１４０】
一方、着側のユーザの情報表示端末２０は、図２７のステップＳ２０３に示すように、プロキシサーバ２００の共有データ要求受付部２３７に、発着間紐付けＩＤ及び発着判定フラグとともにポーリングする。すると、共有データ返信部２３８は、発着間紐付けＩＤ及び発着判定フラグを用いて共有データ受付部２３６を検索し、ポーリング元と通話を行っているユーザのマウスポインタの座標情報が更新されている場合には、これを取得し（ステップＳ２０４）、送信元の情報表示端末２０に返信する（ステップＳ２０５）。なお、座標情報が更新されているか否かは、例えば『timestamp』を用いて５秒以内に更新された情報であるか否かを判定するなどする。
【０１４１】
すると、着側のユーザの情報表示端末２０において閲覧されるＷｅｂコンテンツには、発側のユーザの情報表示端末２０において操作されたマウスポインタが表示される（ステップＳ２０６）。
【０１４２】
［実施例４の効果］
上記してきたように、実施例４に係るＷｅｂコンテンツ共有システムにおいては、実施例１と同様、複数のユーザ間で通話が行われると、セッション連携サーバ１００の発着間紐付けＩＤ発行部１３２が、ユーザ間でＷｅｂコンテンツのＵＲＬ情報を連携するための発着間紐付けＩＤをユーザの情報表示端末２０それぞれに対して発行する。また、プロキシサーバ２００のＷｅｂコンテンツ要求受付部２３１が、所定のＷｅｂサーバが発信するＷｅｂコンテンツを要求するＷｅｂコンテンツ要求を、発着間紐付けＩＤ発行部１３２によって発行された発着間紐付けＩＤとともに情報表示端末２０から受け付ける。また、Ｗｅｂコンテンツ取得部２３２が、所定のＷｅｂサーバが発信するＷｅｂコンテンツを取得し、Ｗｅｂコンテンツ加工部２３３が、マウスポインタの座標情報が座標情報を発着間紐付けＩＤとともに共有データ受付部２３６に通知するように、取得したＷｅｂコンテンツを加工する。また、加工済Ｗｅｂコンテンツ返信部２３４が、Ｗｅｂコンテンツ加工部２３３によって加工されたＷｅｂコンテンツを、Ｗｅｂコンテンツ要求の送信元の情報表示端末２０に返信する。
【０１４３】
また、プロキシサーバ２００の閲覧制御部２３５及びセッション連携サーバ１００のＵＲＬ通知部１３３が、Ｗｅｂコンテンツ要求受付部２３１によって受け付けられた発着間紐付けＩＤに基づいて、Ｗｅｂコンテンツ要求の送信元と通話を行っているユーザの情報表示端末２０を特定し、特定した情報表示端末２０においてＷｅｂコンテンツ要求に係るＷｅｂコンテンツが閲覧されるように制御する。
【０１４４】
さらに、実施例４に係るＷｅｂコンテンツ共有システムにおいては、プロキシサーバ２００が、ユーザの情報表示端末２０において操作されたマウスポインタの座標情報を発着間紐付けＩＤと対応付けて記憶する共有データテーブル２２３をさらに備える。そして、共有データ受付部２３６が、マウスポインタの座標情報が通話を行っているユーザの情報表示端末２０いずれか一方より変更された場合に、マウスポインタの座標情報を発着間紐付けＩＤとともに情報表示端末２０から受け付け、共有データテーブル２２３に格納する。また、共有データ要求受付部２３７が、マウスポインタの座標情報を要求する操作情報要求を発着間紐付けＩＤとともに情報表示端末２０から受け付ける。また、共有データ返信部２３８が、操作情報要求とともに受け付けた発着間紐付けＩＤを用いて共有データテーブル２２３を検索し、操作情報要求の送信元と通話を行っている利用者のマウスポインタの座標情報を送信元の情報表示端末２０に返信する。
【０１４５】
このようなことから、実施例４によれば、「ページ内での操作の同期」を実現することも可能になり、Ｗｅｂコンテンツを共有する時にユーザ間でやりとりする必要のあるデータを共有することが可能になる。
【０１４６】
また、ユーザ間で共有するデータを記憶するテーブルはプロキシサーバ２００に備えられるので、既存のＷｅｂサーバがデータを記憶する必要もない。
【０１４７】
また、ユーザにとっては、ユーザビリティが下がらない。すなわち、仮に、マウスポインタのような共有機能がＷｅｂコンテンツごとに別々に実装されているとすると、マウスポインタの色や形がＷｅｂコンテンツによって異なるため、通話中に共有するＷｅｂコンテンツが替わるたびにマウスポインタの色や形が変わり、ユーザビリティの低下が起きると考えられる。これに対し、実施例４によれば、すべてのＷｅｂコンテンツに対して共通の方法でマウスポインタの共有機能を実現するので、ユーザビリティが低下するといった問題は起きない。
【０１４８】
また、プロキシサーバ２００が共有機能を追加するので、共有機能を管理できる。すなわち、仮に、Ｗｅｂサーバ側で共有機能を実現しようとすると、共有機能の安全性を保証することが困難になってしまう。これに対し、実施例４によれば、プロキシサーバ２００が一元的に共有機能を追加するので、プロキシサーバ２００が共有機能を管理でき、共有機能の安全性を保証することができる。
【実施例５】
【０１４９】
上記実施例１〜３においては、既存のＷｅｂコンテンツを共有する形態として「ページ遷移の同期」を例に挙げて説明したが、実施例５においては、更に、Ｗｅｂサイトと情報表示端末との間で行われるＷｅｂセッションの状態管理も実現する。ここで、状態管理とは、例えば、ＩＥＴＦ（Internet  Engineering  Task  Force）によって公開されたＲＦＣ（Request  for  Comments）２９６５で定義されたＨＴＴＰ  ｃｏｏｋｉｅ（以下「Ｃｏｏｋｉｅ」）による管理のことである。なお、以下では、状態管理を実現する状態管理情報としてＣｏｏｋｉｅを一例に挙げるが、これに限られるものではない。Ｗｅｂサイトと情報表示端末との間で行われるＷｅｂセッションの状態管理を実現するための情報であれば、状態管理情報としてＣｏｏｋｉｅ以外の他の情報を用いてもよい。
【０１５０】
また、実施例５では、Ｗｅｂセッションの状態管理を実現するにあたり、Ｗｅｂサイトにログインする手法を想定する。具体的には、プロキシサーバ専用のアカウント情報でログインする手法を基本形態及び変形例１で説明し、一方のユーザのアカウント情報でログインする手法を変形例２で説明し、双方のユーザそれぞれのアカウント情報でログインする手法を変形例３で説明する。それぞれの手法に応じて提供され得るサービスは異なるので、以下では、手法ごとのサービスイメージも併せて説明する。
【０１５１】
［実施例５におけるプロキシサーバ２００の構成］
まず、図２８〜３０を用いて、実施例５におけるプロキシサーバ２００の構成を説明する。図２８は、プロキシサーバの構成を示すブロック図であり、図２９は、ＩＤ−ＰＷ（Password）管理テーブルを説明するための図であり、図３０は、Ｃｏｏｋｉｅ管理テーブルを説明するための図である。
【０１５２】
図２８に示すように、実施例５におけるプロキシサーバ２００は、記憶部２２０に、特に、ＩＤ−ＰＷ管理テーブル２２４とＣｏｏｋｉｅ管理テーブル２２５とを備える。なお、実施例５においては、Ｗｅｂサイトにログインする手法を想定するので、プロキシサーバ２００がアカウント情報を記憶する（ＩＤ−ＰＷ管理テーブル２２４を備える）ことを想定するが、これに限られるものではない。例えばＣｏｏｋｉｅは、Ｗｅｂサイトにログインしない状態であってもＷｅｂサイトから発行されることがある。このような場合には、プロキシサーバ２００は、必ずしもアカウント情報を記憶する必要はない。
【０１５３】
ＩＤ−ＰＷ管理テーブル２２４は、Ｗｅｂサイトにログインするためのアカウント情報を記憶する。また、ＩＤ−ＰＷ管理テーブル２２４が記憶するアカウント情報は、Ｗｅｂコンテンツ取得部２３２による処理に利用される。なお、ＩＤ−ＰＷ管理テーブル２２４に対するアカウント情報の登録は、Ｗｅｂコンテンツ共有システムの運用者などによって事前に行われる。
【０１５４】
例えば、ＩＤ−ＰＷ管理テーブル２２４は、図２９に示すように、Ｗｅｂサイトの識別情報（『Ｗｅｂサイト』）とＵＲＬ情報（『ＵＲＬ』）とＩＤ及びパスワード（『ＩＤ＆ＰＷ』）とを対応付けて記憶する。例えば、Ｗｅｂサイト『ｓｉｔｅＡ』、ＵＲＬ『ｓｉｔｅＡ＿ＵＲＬ』、及びＩＤ＆ＰＷ『ｓｉｔｅＡ＿ＩＤ＆ＰＷ』の行は、『ｓｉｔｅＡ＿ＵＲＬ』に所在するＷｅｂサイトにログインするためのＩＤ及びパスワードが『ｓｉｔｅＡ＿ＩＤ＆ＰＷ』であることを示す。なお、実施例５においては、ＷｅｂサイトにログインするためのＩＤ及びパスワードは、ユーザごとのＩＤ及びパスワードではなく、プロキシサーバ２００専用のＩＤ及びパスワードである。プロキシサーバ２００専用のアカウントをユーザ間で共有する。
【０１５５】
Ｃｏｏｋｉｅ管理テーブル２２５は、状態管理に関する情報を記憶する。具体的には、Ｃｏｏｋｉｅ管理テーブル２２５は、Ｗｅｂコンテンツ取得部２３２やＷｅｂコンテンツ加工部２３３によって格納されることで、状態管理に関する情報を記憶する。また、Ｃｏｏｋｉｅ管理テーブル２２５が記憶する状態管理に関する情報は、Ｗｅｂコンテンツ取得部２３２や加工済みＷｅｂコンテンツ返信部２３４による処理に利用される。
【０１５６】
Ｃｏｏｋｉｅ管理テーブル２２５は、図３０に示すように、発着間紐付けＩＤと、発着判定フラグと、プロキシサーバ２００によって発行されたＣｏｏｋｉｅ（『ｐｒｏｘｙ＿Ｃｏｏｋｉｅ』、以下「プロキシＣｏｏｋｉｅ」）と、Ｗｅｂコンテンツと、Ｗｅｂサイトによって発行されたＣｏｏｋｉｅ（『サイトＣｏｏｋｉｅ』、以下「サイトＣｏｏｋｉｅ」）とを対応付けて記憶する。なお、それぞれの情報の格納タイミングなどについては、以下に記載する。
【０１５７】
次に、実施例５におけるＷｅｂコンテンツ取得部２３２、Ｗｅｂコンテンツ加工部２３３、及び加工済みＷｅｂコンテンツ返信部２３４について、上記実施例と特に異なる点を説明する。
【０１５８】
実施例５におけるＷｅｂコンテンツ取得部２３２は、ＷｅｂサーバからＷｅｂコンテンツを取得する際に、アカウント情報を用いてＷｅｂサイトにログインし、Ｗｅｂコンテンツの他に、サイトＣｏｏｋｉｅも取得する。具体的には、Ｗｅｂコンテンツ取得部２３２は、ＷｅｂサーバのＵＲＬ情報、発着間紐付けＩＤ及び発着判定フラグをＷｅｂコンテンツ要求受付部２３１から受け付けると、ＵＲＬ情報を用いてＩＤ−ＰＷ管理テーブル２２４を参照する。そして、Ｗｅｂコンテンツ取得部２３２は、ＵＲＬ情報に対応付けて記憶されたＩＤ及びパスワードをＩＤ−ＰＷ管理テーブル２２４から取得し、取得したＩＤ及びパスワードを用いてＷｅｂサイトにログインする。また、Ｗｅｂコンテンツ取得部２３２は、Ｗｅｂコンテンツ及びサイトＣｏｏｋｉｅをＷｅｂサーバから取得し、取得したＷｅｂコンテンツ（未加工）及びサイトＣｏｏｋｉｅと、発着間紐付けＩＤ及び発着判定フラグとを、Ｗｅｂコンテンツ加工部２３３に送る。また、Ｗｅｂコンテンツ取得部２３２は、発着間紐付けＩＤ、発着判定フラグ、Ｗｅｂコンテンツ（未加工）、及びサイトＣｏｏｋｉｅをＣｏｏｋｉｅ管理テーブル２２５に格納する。
【０１５９】
また、Ｗｅｂコンテンツ取得部２３２は、既にログイン済みのＷｅｂサイトに対するアクセスである場合（２回目以降）には、ＷｅｂサーバからＷｅｂコンテンツを取得する際に、サイトＣｏｋｋｉｅを用いてＷｅｂサーバにアクセスする。具体的には、Ｗｅｂコンテンツ取得部２３２は、ＷｅｂサーバのＵＲＬ情報、発着間紐付けＩＤ及び発着判定フラグの他に、後述するＷｅｂコンテンツ加工部２３３によって発行されたプロキシＣｏｏｋｉｅをＷｅｂコンテンツ要求受付部２３１から受け付けると、発着間紐付けＩＤやプロキシＣｏｏｋｉｅを用いてＣｏｏｋｉｅ管理テーブル２２５を参照する。そして、Ｗｅｂコンテンツ取得部２３２は、これらの情報に対応付けて記憶されたサイトＣｏｏｋｉｅを取得し、取得したサイトＣｏｏｋｉｅを用いてＷｅｂサーバにアクセスする。なお、Ｗｅｂコンテンツ取得部２３２は、このアクセスにより新たなサイトＣｏｏｋｉｅを取得すると、Ｃｏｏｋｉｅ管理テーブル２２５に格納されているサイトＣｏｏｋｉｅを、取得した新たなサイトＣｏｏｋｉｅによって更新する。
【０１６０】
また、Ｗｅｂコンテンツ取得部２３２は、ページ遷移を同期される側の情報表示端末２０からのＷｅｂコンテンツ要求である場合には、Ｗｅｂサーバに対してアクセスすることなく、Ｃｏｏｋｉｅ管理テーブル２２５に格納されたＷｅｂコンテンツ（未加工）を加工して要求元の情報表示端末２０に送信するように、Ｗｅｂコンテンツ加工部２３３に通知する。
【０１６１】
具体的には、Ｗｅｂコンテンツ取得部２３２は、ＷｅｂサーバのＵＲＬ情報、発着間紐付けＩＤ及び発着判定フラグの他に、ページ遷移を同期される側であることを示す同期済みパラメータをＷｅｂコンテンツ要求受付部２３１から受け付けると、発着間紐付けＩＤを用いてＣｏｏｋｉｅ管理テーブル２２５を参照する。そして、Ｗｅｂコンテンツ取得部２３２は、発着間紐付けＩＤに対応付けて記憶されたＷｅｂコンテンツ（未加工）及びプロキシＣｏｏｋｉｅを取得する。続いて、Ｗｅｂコンテンツ取得部２３２は、取得したＷｅｂコンテンツ（未加工）及びプロキシＣｏｏｋｉｅをＷｅｂコンテンツ加工部２３３に送る。
【０１６２】
実施例５におけるＷｅｂコンテンツ加工部２３３は、Ｗｅｂコンテンツを加工する際に、プロキシＣｏｏｋｉｅを発行する。具体的には、Ｗｅｂコンテンツ加工部２３３は、Ｗｅｂコンテンツ、サイトＣｏｏｋｉｅ、発着間紐付けＩＤ及び発着判定フラグをＷｅｂコンテンツ取得部２３２から受け付けると、受け付けたＷｅｂコンテンツを加工するとともに、プロキシＣｏｏｋｉｅを発行する。そして、Ｗｅｂコンテンツ加工部２３３は、発行したプロキシＣｏｏｋｉｅをサイトＣｏｏｋｉｅに対応付けてＣｏｏｋｉｅ管理テーブル２２５に格納する。また、Ｗｅｂコンテンツ加工部２３３は、加工済みのＷｅｂコンテンツ及びプロキシＣｏｏｋｉｅを加工済Ｗｅｂコンテンツ返信部２３４に送る。
【０１６３】
また、Ｗｅｂコンテンツ加工部２３３は、ページ遷移を同期される側の情報表示端末２０からのＷｅｂコンテンツ要求に対応して、Ｗｅｂコンテンツ（未加工）及びプロキシＣｏｏｋｉｅをＷｅｂコンテンツ取得部２３２から受け付けると、受け付けたＷｅｂコンテンツを加工し、加工済みのＷｅｂコンテンツ及びプロキシＣｏｏｋｉｅを加工済Ｗｅｂコンテンツ返信部２３４に送る。なお、この場合、Ｗｅｂコンテンツ加工部２３３は、ページ遷移を同期される側の情報表示端末２０に相応しい内容に、Ｗｅｂコンテンツを加工する。例えば、Ｗｅｂコンテンツ加工部２３３は、発着判定フラグのパラメータを、ページ遷移を同期される側の情報表示端末２０に対応する値に加工する。
【０１６４】
実施例５における加工済Ｗｅｂコンテンツ返信部２３４は、加工済みのＷｅｂコンテンツをＷｅｂコンテンツ要求の要求元の情報表示端末２０に返信する際に、加工済みのＷｅｂコンテンツとともに、Ｗｅｂコンテンツ加工部２３３によって発行されたプロキシＣｏｏｋｉｅを送信する。
【０１６５】
また、加工済Ｗｅｂコンテンツ返信部２３４は、同期される側の情報表示端末２０に加工済みのＷｅｂコンテンツを送信する場合も同様に、Ｗｅｂコンテンツ取得部２３２から送られた加工済みのＷｅｂコンテンツ及びプロキシＣｏｏｋｉｅを、該当する情報表示端末２０に送信する。
【０１６６】
なお、上記実施例においては、プロキシサーバ２００が、Ｃｏｏｋｉｅ管理テーブル２２５に未加工のＷｅｂコンテンツを記憶し、ページ遷移を同期される側の情報表示端末２０からのＷｅｂコンテンツ要求を受け付けると、未加工のＷｅｂコンテンツを改めて加工して返信する手法を説明したが、本発明はこれに限られるものではない。例えば、プロキシサーバ２００は、Ｃｏｏｋｉｅ管理テーブル２２５に加工済みのＷｅｂコンテンツを記憶してもよい。この場合には、プロキシサーバ２００は、Ｃｏｏｋｉｅ管理テーブル２２５に記憶する加工済みのＷｅｂコンテンツのうち必要な部分を、ページ遷移を同期される側の情報表示端末２０に対応する内容に加工し直して（置換して）返信すればよい。
【０１６７】
［実施例５に係るＷｅｂコンテンツ共有システムによる処理手順］
続いて、図３１−１〜図３３−２を用いて、実施例５に係るＷｅｂコンテンツ共有システムによる処理手順を説明する。図３１−１及び３１−２は、実施例５に係るＷｅｂコンテンツ共有システムによる処理手順（初回アクセスから１回目の同期まで）を示すシーケンス図である。図３２は、Ｃｏｏｋｉｅの設定を説明するための図である。図３３−１及び３３−２は、実施例５に係るＷｅｂコンテンツ共有システムによる処理手順（２回目アクセスから２回目の同期まで）を示すシーケンス図である。
【０１６８】
さて、図３１−１に示すステップＳ３０１は、図１６（実施例１）に示したステップＳ１１０に対応する。なお、実施例５においては、説明の便宜上、実施例１において説明した通知モードを省略するが、実施例５においても、実施例１と同様、通知モードを利用することができる。
【０１６９】
まず、情報表示端末２０は、ＷｅｂサイトのＵＲＬ情報、セッション連携サーバ１００から送信された発着間紐付けＩＤ及び発着判定フラグを、プロキシサーバ２００に送信する（ステップＳ３０１）。例えば、発側の情報表示端末２０は、ｓｉｔｅＡのＵＲＬ、発着間紐付けＩＤ、及び発側であることを示す発着判定フラグをプロキシサーバ２００に送信する。なお、図３１−１においては、ｓｉｔｅＡに対するアクセスが初回であることを示すために、『ｓｉｔｅＡのＵＲＬ（１）』と記載する。
【０１７０】
すると、プロキシサーバ２００のＷｅｂコンテンツ取得部２３２は、ＵＲＬ情報を用いてＩＤ−ＰＷ管理テーブル２２４を参照し、ＵＲＬ情報に対応付けて記憶されたＩＤ及びパスワードをＩＤ−ＰＷ管理テーブル２２４から取得する（ステップＳ３０２）。例えば、Ｗｅｂコンテンツ取得部２３２は、『ｓｉｔｅＡ＿ＩＤ＆ＰＷ』を取得する。
【０１７１】
次に、Ｗｅｂコンテンツ取得部２３２は、取得したＩＤ及びパスワードを用いてＷｅｂサーバにログインし、ＷｅｂサーバからＷｅｂコンテンツ及びサイトＣｏｏｋｉｅを取得する（ステップＳ３０３）。なお、図３１−１においては、ｓｉｔｅＡから初回に取得したＷｅｂコンテンツであることを示すために、『Ｗｅｂコンテンツ（１）』と記載し、ｓｉｔｅＡから初回に取得したサイトＣｏｏｋｉｅであることを示すために、『ｓｉｔｅＡ＿Ｃｏｏｋｉｅ（１）』と記載する。
【０１７２】
続いて、Ｗｅｂコンテンツ加工部２３３が、プロキシＣｏｏｋｉｅを発行し（ステップＳ３０４）、Ｗｅｂコンテンツを加工し（ステップＳ３０５）、発行したプロキシＣｏｏｋｉｅをサイトＣｏｏｋｉｅに対応付けてＣｏｏｋｉｅ管理テーブルに格納する。
【０１７３】
そして、加工済Ｗｅｂコンテンツ返信部２３４が、Ｗｅｂコンテンツ要求を送信した要求元の情報表示端末２０に、加工済みのＷｅｂコンテンツ及びプロキシＣｏｏｋｉｅを返信する（ステップＳ３０６）。ここで、情報表示端末２０は、プロキシサーバ２００から送信されたプロキシＣｏｏｋｉｅをＷｅｂブラウザに設定する（ステップＳ３０７）。例えば、情報表示端末２０は、図３２の（Ａ）に示すように、プロキシＣｏｏｋｉｅをＷｅｂブラウザに設定する。
【０１７４】
一方、プロキシサーバ２００において、閲覧制御部２３５が、加工済みのＷｅｂコンテンツを閲覧するためのＵＲＬ情報、発着間紐付けＩＤ及び発着判定フラグをセッション連携サーバ１００に送信する（ステップＳ３０８）。すると、セッション連携サーバ１００のＵＲＬ通知部１３３が、プロキシサーバ２００から受信した発着間紐付けＩＤ及び発着間判定フラグに基づきＷｅｂコンテンツ要求の送信元と通話を行っているユーザの情報表示端末２０を特定する（ステップＳ３０９）。
【０１７５】
そして、ＵＲＬ通知部１３３は、特定した情報表示端末２０に対して、プロキシサーバ２００から受信したＵＲＬ情報を送信する（ステップＳ３１０）。
【０１７６】
すると、図３１−２に示すように、ＵＲＬ情報を受信した情報表示端末２０が、セッション連携サーバ１００から送信されたＵＲＬ情報、発着間紐付けＩＤ、発着判定フラグ、及び同期済みパラメータを、プロキシサーバ２００に送信する（ステップＳ３１１）。
【０１７７】
プロキシサーバ２００のＷｅｂコンテンツ取得部２３２は、ページ遷移を同期される側の情報表示端末２０からのＷｅｂコンテンツ要求である場合であるので、発着間紐付けＩＤを用いてＣｏｏｋｉｅ管理テーブル２２５を参照する（ステップＳ３１２）。そして、Ｗｅｂコンテンツ取得部２３２は、発着間紐付けＩＤに対応付けて記憶されたＷｅｂコンテンツ（未加工）及びプロキシＣｏｏｋｉｅを取得し、取得したＷｅｂコンテンツ（未加工）及びプロキシＣｏｏｋｉｅをＷｅｂコンテンツ加工部２３３に送る。
【０１７８】
そして、Ｗｅｂコンテンツ加工部２３３は、Ｗｅｂコンテンツ取得部２３２から送られたＷｅｂコンテンツ（未加工）を加工し、加工済Ｗｅｂコンテンツ返信部２３４が、加工済みのＷｅｂコンテンツ及びプロキシＣｏｏｋｉｅを情報表示端末２０に送信する（ステップＳ３１３）。なお、図３１−２においては、ｓｉｔｅＡから初回に取得したＷｅｂコンテンツを加工した加工済みＷｅｂコンテンツであることを示すために、『加工済Ｗｅｂコンテンツ（１）』と記載する。すると、情報表示端末２０は、プロキシサーバ２００から送信されたプロキシＣｏｏｋｉｅをＷｅｂブラウザに設定する（ステップＳ３１４）。
【０１７９】
次に、情報表示端末２０が、同じＷｅｂサイトに対する２回目アクセスを行うとする。なお、ここでいう２回目アクセスとは、Ｗｅｂサイトと情報表示端末２０との間で行われるＷｅｂセッションがＣｏｏｋｉｅによって状態管理された状況下でのアクセスである。
【０１８０】
まず、情報表示端末２０は、ＷｅｂサイトのＵＲＬ情報、セッション連携サーバ１００から送信された発着間紐付けＩＤ及び発着判定フラグとともに、プロキシＣｏｏｋｉｅを、プロキシサーバ２００に送信する（ステップＳ３１５）。なお、図３３−１においては、ｓｉｔｅＡに対するアクセスが２回目であることを示すために、『ｓｉｔｅＡのＵＲＬ（２）』と記載する。
【０１８１】
すると、プロキシサーバ２００のＷｅｂコンテンツ取得部２３２は、既にログイン済みのＷｅｂサイトに対するアクセスである場合であるので、発着間紐付けＩＤやプロキシＣｏｏｋｉｅを用いてＣｏｏｋｉｅ管理テーブル２２５を参照する（ステップＳ３１６）。
【０１８２】
そして、Ｗｅｂコンテンツ取得部２３２は、これらの情報に対応付けて記憶されたサイトＣｏｏｋｉｅを取得し、取得したサイトＣｏｏｋｉｅを用いてＷｅｂサーバにアクセスする（ステップＳ３１７）。なお、Ｗｅｂコンテンツ取得部２３２は、このアクセスにより新たなサイトＣｏｏｋｉｅ（例えばｓｉｔｅＡ＿Ｃｏｏｋｉｅ（２））を取得すると、Ｃｏｏｋｉｅ管理テーブル２２５に格納されたサイトＣｏｏｋｉｅ（例えばｓｉｔｅＡ＿Ｃｏｏｋｉｅ（１））を、取得した新たなサイトＣｏｏｋｉｅ（例えばｓｉｔｅＡ＿Ｃｏｏｋｉｅ（２））によって更新する。
【０１８３】
続いて、Ｗｅｂコンテンツ取得部２３２は、ステップＳ３１７において取得した新たなサイトＣｏｏｋｉｅを解析し、Ｗｅｂサイトと情報表示端末２０との間で行われるＷｅｂセッションがＣｏｏｋｉｅによって状態管理された状況下で継続していることを確認する（ステップＳ３１８）。例えば、Ｗｅｂコンテンツ取得部２３２は、サイトＣｏｏｋｉｅに含まれる有効期限（例えばｅｘｐｉｒｅｓ）が超過しているか否かを確認する。
【０１８４】
また、Ｗｅｂコンテンツ取得部２３２は、通話が継続しているか否かを確認する（ステップＳ３１９）。例えば、Ｗｅｂコンテンツ取得部２３２は、発着間紐付けＩＤを用いてセッション連携サーバ１００に対して問い合わせを行い、該当する通話が継続しているか否かを確認する。なお、セッション連携サーバ１００は、例えば、制御用セッション情報管理テーブル１２１を参照し、発着間紐付けＩＤに対応付けて記憶されている通話履歴情報を用いて、通話が継続しているか否かを判断し、判断結果をＷｅｂコンテンツ取得部２３２に通知する。
【０１８５】
Ｗｅｂコンテンツ取得部２３２は、ＷｅｂセッションがＣｏｏｋｉｅによって状態管理された状況下で継続していることを確認し、該当する通話が継続していることを確認すると、新たに取得したＷｅｂコンテンツ、新たに取得したサイトＣｏｏｋｉｅ、発着間紐付けＩＤ及び発着判定フラグを、Ｗｅｂコンテンツ加工部２３３に送る。
【０１８６】
続いて、Ｗｅｂコンテンツ加工部２３３は、発行済みのプロキシＣｏｏｋｉｅが既にＣｏｏｋｉｅ管理テーブル２２５に記憶されている場合であるので、プロキシＣｏｏｋｉｅを発行することなくＷｅｂコンテンツを加工する（ステップＳ３２０）。なお、再びプロキシＣｏｏｋｉｅを発行し、新たに発行したプロキシＣｏｏｋｉｅを格納する手法であってもよい。
【０１８７】
そして、加工済Ｗｅｂコンテンツ返信部２３４が、Ｗｅｂコンテンツ要求を送信した要求元の情報表示端末２０に、加工済みのＷｅｂコンテンツ及びプロキシＣｏｏｋｉｅを返信する（ステップＳ３２１）。
【０１８８】
一方、閲覧制御部２３５が、加工済みのＷｅｂコンテンツを閲覧するためのＵＲＬ情報、発着間紐付けＩＤ及び発着判定フラグをセッション連携サーバ１００に送信する（ステップＳ３２２）。すると、セッション連携サーバ１００のＵＲＬ通知部１３３が、プロキシサーバ２００から受信した発着間紐付けＩＤ及び発着判定フラグに基づきＷｅｂコンテンツ要求の送信元と通話を行っているユーザの情報表示端末２０を特定する（ステップＳ３２３）。
【０１８９】
そして、ＵＲＬ通知部１３３は、特定した情報表示端末２０に対して、プロキシサーバ２００から受信したＵＲＬ情報を送信する（ステップＳ３２４）。
【０１９０】
すると、ＵＲＬ情報を受信した情報表示端末２０が、セッション連携サーバ１００から送信されたＵＲＬ情報、発着間紐付けＩＤ、発着判定フラグ、プロキシＣｏｏｋｉｅ、及び同期済みパラメータをプロキシサーバ２００に送信する（ステップＳ３２５）。
【０１９１】
プロキシサーバ２００のＷｅｂコンテンツ取得部２３２は、ページ遷移を同期される側の情報表示端末２０からのＷｅｂコンテンツ要求である場合であるので、発着間紐付けＩＤを用いてＣｏｏｋｉｅ管理テーブル２２５を参照する（ステップＳ３２６）。そして、Ｗｅｂコンテンツ取得部２３２は、発着間紐付けＩＤに対応付けて記憶されたＷｅｂコンテンツ（未加工）及びプロキシＣｏｏｋｉｅを取得し、取得したＷｅｂコンテンツ（未加工）及びプロキシＣｏｏｋｉｅをＷｅｂコンテンツ加工部２３３に送る。
【０１９２】
そして、Ｗｅｂコンテンツ加工部２３３は、Ｗｅｂコンテンツ取得部２３２から送られたＷｅｂコンテンツ（未加工）を加工し、加工済Ｗｅｂコンテンツ返信部２３４が、加工済みのＷｅｂコンテンツ及びプロキシＣｏｏｋｉｅを要求元の情報表示端末２０に送信する（ステップＳ３２７）。なお、図３３−２においては、ｓｉｔｅＡから２回目に取得したＷｅｂコンテンツを加工した加工済みＷｅｂコンテンツであることを示すために、『加工済Ｗｅｂコンテンツ（２）』と記載する。
【０１９３】
なお、図示を省略したが、この後、通話が終了し、プロキシサーバ２００が、通話が終了した旨を例えばセッション連携サーバ１００から通知されると、プロキシサーバ２００は、ログインしていたＷｅｂサイトからログアウトするように、Ｗｅｂサーバに対してログアウト処理を行ってもよい。また、プロキシサーバ２００は、情報表示端末２０が保持するプロキシＣｏｏｋｉｅの無効化を情報表示端末２０に対して通知してもよい。例えば、プロキシサーバ２００は、プロキシＣｏｏｋｉｅの有効期限（例えばｅｘｐｉｒｅｓ）を過去の日に設定して情報表示端末２０に対して送信することで、プロキシＣｏｏｋｉｅの無効化を情報表示端末２０に対して通知する。情報表示端末２０側では、例えばＷｅｂブラウザが、プロキシＣｏｏｋｉｅの有効期限に基づきプロキシＣｏｏｋｉｅを無効と判定し、プロキシＣｏｏｋｉｅを削除する。
【０１９４】
［変形例１］
さて、これまで実施例５に係るＷｅｂコンテンツ共有システムによる処理手順を説明してきたが、上記処理手順（以下、説明の便宜上「基本シーケンス」という）は一例に過ぎず、上記した処理手順以外にも種々の異なる形態にて実施されてよいものである。そこで、図３４を用いて変形例１を説明する。図３４は、変形例１の処理手順を説明するための図である。
【０１９５】
図３４に示すように、変形例１の処理手順は、ステップＳ４０１〜ステップＳ４０５は、図３１−１に示した基本シーケンスのステップＳ３０１〜ステップ３０５と同様であり、ステップＳ４０６以降が特に異なる。
【０１９６】
具体的には、基本シーケンスにおいて、加工済Ｗｅｂコンテンツ返信部２３４は、プロキシＣｏｏｋｉｅを要求元の情報表示端末２０に返信したが、変形例１では、サイトＣｏｏｋｉｅとプロキシＣｏｏｋｉｅとを合体したＣｏｏｋｉｅ（以下「合体Ｃｏｏｋｉｅ」）を返信する（ステップＳ４０６）。また、加工済Ｗｅｂコンテンツ返信部２３４は、連携機能を実現するプログラムも併せて返信する。
【０１９７】
すると、情報表示端末２０は、プロキシサーバ２００から送信された連携機能をインストールし、連携機能により合体Ｃｏｏｋｉｅを復号する（ステップＳ４０７）。すなわち、連携機能を実現するプログラムは、合体Ｃｏｏｋｉｅを解析し、サイトＣｏｏｋｉｅとプロキシＣｏｏｋｉｅとに分解する。また、プログラムは、サイトＣｏｏｋｉｅの有効期限とプロキシＣｏｏｋｉｅの有効期限とを一致させる。サイトＣｏｏｋｉｅの有効期限とプロキシＣｏｏｋｉｅの有効期限とを一致させる目的は、プロキシＣｏｏｋｉｅの有効期限がサイトＣｏｏｋｉｅの有効期限よりも短いと、通話終了後にもサイトＣｏｏｋｉｅを利用できてしまうことになるからである。
【０１９８】
その後、情報表示端末２０は、プロキシＣｏｏｋｉｅのみならず、サイトＣｏｏｋｉｅもＷｅｂブラウザに設定する（ステップＳ４０８）。例えば、図３２の（Ａ）及び（Ｂ）に示すようにＷｅｂブラウザに設定する。なお、以降の処理は、基本シーケンスと同様、プロキシサーバ２００と情報表示端末２０との間の通信はプロキシＣｏｏｋｉｅのみを用いて行ってもよい。この場合は、例えば、情報表示端末２０に保持されたサイトＣｏｏｋｉｅは、情報表示端末２０が直接Ｗｅｂサイトにアクセスする場合に活用される。一方、基本シーケンスとは異なり、プロキシサーバ２００と情報表示端末２０との間の通信は合体Ｃｏｏｋｉｅを用いて行ってもよい。この場合は、プロキシサーバ２００がサイトＣｏｏｋｉｅの情報を記憶、管理する必要がない。
【０１９９】
［基本形態及び変形例１のサービスイメージ］
図３５を用いて、上記基本形態及び変形例１のサービスイメージを説明する。図３５は、サービスイメージを説明するための図である。実施例５に係るＷｅｂコンテンツ共有システムやその変形例１では、例えば、図３５に示すような会員制ＷｅｂサイトのＷｅｂコンテンツを共有するシステムを実現することができる。プロキシサーバ２００が、プロキシサーバ２００専用のアカウント情報を用いて会員制Ｗｅｂサイトに代理でログインするので、ユーザは、個別に会員制Ｗｅｂサイトに契約する必要がない。すなわち、ユーザは、会員制Ｗｅｂサイトに契約することなく、通話中でさえあれば当該Ｗｅｂサイトを会員として閲覧することが可能になる。また、会員制Ｗｅｂサイトを運営する事業者は、既存のＷｅｂサイトを作り替える必要がなく、プロキシサーバ２００用のアカウントを発行するだけでよい。
【０２００】
［変形例２］
続いて、図３６〜４０を用いて、変形例２を説明する。図３６は、ＩＤ−ＰＷ管理テーブルを説明するための図である。図３７〜３９は、変形例２の処理手順を説明するための図である。
【０２０１】
変形例２では、プロキシサーバ２００専用のＩＤ及びパスワードを用いてＷｅｂサイトにログインするのではなく、一方のユーザにＩＤ及びパスワードを入力させ、そのＩＤ及びパスワードを用いてＷｅｂサイトにログインする。このため、例えば、図３６に示すように、変形例２のＩＤ−ＰＷ管理テーブル２２４は、Ｗｅｂサイトにログインするためのアカウント情報を、発着間紐付けＩＤと、ユーザによって入力されたＩＤ及びパスワードとを対応付けて記憶することで管理する。
【０２０２】
例えば、図３７に示すように、情報表示端末２０は、ＷｅｂサイトのＵＲＬ情報、セッション連携サーバ１００から送信された発着間紐付けＩＤ及び発着判定フラグを、プロキシサーバ２００に送信する際に、例えば、ＩＤ及びパスワードの入力フォームを要求するフラグをともに送信する（ステップＳ５０１）。なお、入力フォームの要求フラグは必須ではなく、要求フラグの有無にかかわらずプロキシサーバ２００が入力フォームを送信する手順としてもよい。あるいは、情報表示端末２０からの要求に応じて（情報表示端末２０にインストールされた連携機能の要求に応じて）、入力フォームを送信する手順としてもよい。あるいは、プロキシサーバ２００が、特定のＵＲＬの場合には入力フォームを送信することを判断して、入力フォームを送信する手順としてもよい。
【０２０３】
すると、プロキシサーバ２００は、入力フォームを情報表示端末２０に送信し（ステップＳ５０２）、情報表示端末２０が、入力フォームにＩＤ及びパスワードを入力して、プロキシサーバ２００に返信する（ステップＳ５０３）。ところで、ステップＳ５０２においてプロキシサーバ２００が情報表示端末２０に送信する入力フォームには、ＩＤを通話相手と共有するか否かを指定する「ＩＤ共有フラグ」の送信が可能な仕組みが備えられている。図３７に示すように、例えば、情報表示端末２０は、自己のＩＤ及びパスワードでログインすることになるので、このログインに用いたＩＤを通話相手と共有するか否かを指定するＩＤ共有フラグを併せて送信する。図３７の例では、通話相手と共有することを指定する。
【０２０４】
ここで、ＩＤ共有フラグについて説明する。ステップＳ５０３においてログインをした側の情報表示端末２０は、ログイン状態でないと閲覧できないページ内でページ遷移をする度に、ＩＤ共有フラグを送信することができる。このため、例えばページ遷移毎に、当該ＩＤを通話相手と共有するか否かを指定することができることになるので、情報表示端末２０のユーザは、通話相手に許可する操作権を判断し、制御することが可能になる。ここにいう「ＩＤを共有するか否か」は、「ページの共有を行うか否か」とは異なる意味である。「ＩＤを共有するか否か」は、「通話相手に当該ＩＤに基づく操作権を許可するか否か」を意味し、例えば「ページの共有は行うが、ＩＤは共有しない」という状態も想定される。
【０２０５】
例えば、プロキシサーバ２００は、ログインを行った情報表示端末２０からＩＤ共有フラグ（共有を指定）を受け取った場合には、通話相手となる情報表示端末２０（ログインを行っていない側の情報表示端末２０）が、Ｗｅｂコンテンツ上で当該ＩＤに基づく操作を行った場合に、当該操作を有効なものとして受け付け、ログイン状態で行われた操作としてＷｅｂサーバ３００に転送する。一方、例えば、プロキシサーバ２００は、ログインを行った情報表示端末２０からＩＤ共有フラグ（非共有を指定）を受け取った場合には、通話相手となる情報表示端末２０（ログインを行っていない側の情報表示端末２０）が、Ｗｅｂコンテンツ上で当該ＩＤに基づく操作を行った場合に、当該操作を有効なものとして受け付けず、無効化する。例えば、プロキシサーバ２００は、当該操作に対して、プロキシサーバ２００が予め記憶するエラー画面などを情報表示端末２０に対して送信する。あるいは、例えば、プロキシサーバ２００は、ログイン状態ではなく、ログインされていない状態で行われた操作としてＷｅｂサーバ３００に転送し、そのような操作に対する応答としてＷｅｂサーバ３００から返信されたエラー画面などを、情報表示端末２０に対して送信する。
【０２０６】
図３７に戻り、プロキシサーバ２００は、情報表示端末２０から送信されたＩＤ及びパスワードをＩＤ−ＰＷ管理テーブル２２４に格納し（ステップＳ５０４）、その後は基本シーケンスと同様に、Ｗｅｂコンテンツを取得するなど（ステップＳ５０５）、以降の処理を行う。
【０２０７】
ところで、変形例２では、図３８に示すように、ページ遷移の同期を一時的に非共有とすることを指定する非共有指定や、図３９に示すように、非共有の指定を解除し、共有を復活する再共有指定も実行することができる。なお、これらの機能は必須のものではなく、サービスの形態などに応じて任意に適用すればよい。また、変形例２のみならず、例えば基本形態や変形例１、後述する変形例３など、他の形態にも適用することができる。
【０２０８】
まず、図３８に示すように、例えば、情報表示端末２０は、通話相手と共有しないで閲覧したいＷｅｂサイトのＵＲＬ情報（『非共有ＵＲＬ』）、発着間紐付けＩＤ、発着判定フラグ、及び共有を停止することを示す共有停止フラグを、プロキシサーバ２００に送信する（ステップＳ６０１）。
【０２０９】
図３１−１を用いて説明したように、プロキシサーバ２００は、このＵＲＬ情報に従ってＷｅｂコンテンツの取得や加工などを基本シーケンスと同様に行うが、セッション連携サーバ１００にＵＲＬ情報を送信する際に、非共有ＵＲＬそのものを送信するのではなく、非共有時に通話相手にアクセスさせるべき非共有時用のＵＲＬ情報を送信する（ステップＳ６０２）。
【０２１０】
その後、基本シーケンスと同様にステップＳ６０３〜ステップＳ６０５の処理が行われることになるが、プロキシサーバ２００は、通話相手の情報表示端末２０から非共有時用のＵＲＬにアクセスされると、発着間紐付けＩＤを用いてＣｏｏｋｉｅ管理テーブル２２５を参照し、通話相手の情報表示端末２０が用いているプロキシＣｏｏｋｉｅ（もしくは合体Ｃｏｏｋｉｅ）を特定する（ステップＳ６０６）。そして、プロキシサーバ２００は、特定したプロキシＣｏｏｋｉｅ（もしくは合体Ｃｏｏｋｉｅ）の無効化を情報表示端末２０に対して通知する命令を生成し、情報表示端末２０に送信する（ステップＳ６０７）。例えば、プロキシサーバ２００は、プロキシＣｏｏｋｉｅ（もしくは合体Ｃｏｏｋｉｅ）の有効期限（例えばｅｘｐｉｒｅｓ）を過去の日に設定して情報表示端末２０に対して送信することで、プロキシＣｏｏｋｉｅの無効化を情報表示端末２０に対して通知する。情報表示端末２０側では、例えばＷｅｂブラウザが、プロキシＣｏｏｋｉｅの有効期限に基づきプロキシＣｏｏｋｉｅを無効と判定し、プロキシＣｏｏｋｉｅを削除する。
【０２１１】
さて、図３９に示すように、再共有したい場合には、情報表示端末２０は、例えば、通話相手と共有して閲覧したいＷｅｂサイトのＵＲＬ情報（『再共有ＵＲＬ』）、発着間紐付けＩＤ、発着判定フラグ、及び共有を復活することを示す共有復活フラグをプロキシサーバ２００に送信する（ステップＳ７０１）。
【０２１２】
図３１−１を用いて説明したように、プロキシサーバ２００は、このＵＲＬ情報に従ってＷｅｂコンテンツの取得や加工などを基本シーケンスと同様に行うが、セッション連携サーバ１００にＵＲＬ情報を送信する際に、再共有ＵＲＬそのものを送信するのではなく、再共有時に通話相手にアクセスさせるべき再共有時用ＵＲＬ情報を送信する（ステップＳ７０２）。
【０２１３】
その後、基本シーケンスと同様にステップＳ７０３〜ステップＳ７０５の処理が行われることになるが、プロキシサーバ２００は、通話相手の情報表示端末２０から再共有時用のＵＲＬにアクセスされると、発着間紐付けＩＤを用いてＣｏｏｋｉｅ管理テーブル２２５を参照し、共有・非共有を制御している側の情報表示端末２０が用いているプロキシＣｏｏｋｉｅ（もしくは合体Ｃｏｏｋｉｅ）を特定する（ステップＳ７０６）。そして、プロキシサーバ２００は、特定したプロキシＣｏｏｋｉｅ（もしくは合体Ｃｏｏｋｉｅ）を有効なものとする命令を生成し、情報表示端末２０に送信する（ステップＳ７０７）。情報表示端末２０側に、例えばプロキシサーバ２００からの指示に応じてＣｏｏｋｉｅを有効化する連携機能を実現するプログラムが予めインストールされていればよい。なお、有効化とは、例えば、有効なプロキシＣｏｏｋｉｅ（もしくは合体Ｃｏｏｋｉｅ）を新たに送信する処理や、Ｃｏｏｋｉｅに含まれる有効期限をプロキシサーバ２００が保持する有効なＣｏｏｋｉｅの日付に一致させる、といった処理などである。
【０２１４】
［変形例２のサービスイメージ］
図４０を用いて、上記変形例２のサービスイメージを説明する。図４０は、サービスイメージを説明するための図である。変形例２では、例えば、図４０に示すようなサービスを実現することができる。例えば、祖父と孫とが電話で話をしているとする。例えば、プロキシサーバ２００は、祖父にＩＤ及びパスワードを入力させ、祖父のアカウントでＥＣ（Electronic  Commerce）サイトに代理でログインする。すると、通話相手である孫の情報表示端末は、ＥＣサイトの閲覧を共有し、商品を選択することができるように制御される。もっとも、あくまでログインは祖父のアカウントであるので、商品の購入は祖父が行っていることになる。
【０２１５】
例えば、ＥＣサイトの商品閲覧ページにおいて、「買い物かごへ入れる」（購入対象として選択する）のアイコンを押下する操作は、ＩＤに基づかずに実行可能な操作であるとする。一方、例えば、ＥＣサイトの決済ページにおいて、「決済」（決済を行う）のアイコンを押下する操作は、ＩＤに基づかなければ実行できない操作であるとする。例えば、祖父が、「決済の操作は孫には実行させたくない」と考えれば、祖父の情報表示端末２０は、商品閲覧ページのＵＲＬをプロキシサーバ２００に送信する際には、ＩＤ共有フラグ（共有を指定）を送信し、決済ページのＵＲＬをプロキシサーバ２００に送信する際には、ＩＤ共有フラグ（非共有を指定）を送信すればよい。
【０２１６】
すると、例えば孫が、商品閲覧ページにおいて「買い物かごへ入れる」のアイコンを押下した場合には、孫の情報表示端末２０からプロキシサーバ２００に送信されたこの操作情報は、プロキシサーバ２００によって有効なものとして受け付けられ、プロキシサーバ２００からＥＣサイトに転送される。一方、例えば孫が、決済ページにおいて「決済」のアイコンを押下した場合には、孫の情報表示端末２０からプロキシサーバ２００に送信されたこの操作情報は、プロキシサーバ２００によって無効なものとして受け付けられ、例えばプロキシサーバ２００は、エラー画面を孫の情報表示端末２０に対して送信する。このように、祖父は、通話相手（孫）に許可する操作権を判断し、制御することが可能になる。
【０２１７】
次に、非共有フラグや再共有フラグのサービスイメージを説明する。例えば、祖父が、「決済ページは孫と共有したくない」と考えれば、祖父の情報表示端末２０は、決済ページのＵＲＬをプロキシサーバ２００に送信する際に非共有フラグを併せて送信すればよい。また、祖父が、「買い物完了ページから再び孫と共有したい」と考えれば、祖父の情報表示端末２０は、再共有フラグをプロキシサーバ２００に送信すればよい。
【０２１８】
［変形例３］
続いて、図４１〜４４を用いて、変形例３を説明する。図４１は、ＩＤ−ＰＷ管理テーブルを説明するための図であり、図４２は、Ｃｏｏｋｉｅ管理テーブルを説明するための図である。図４３−１及び４３−２は、変形例３の処理手順を説明するための図である。
【０２１９】
変形例３では、一方のユーザのＩＤ及びパスワードを用いてＷｅｂサイトにログインするのではなく、ユーザそれぞれにＩＤ及びパスワードを入力させ、それぞれのＩＤ及びパスワードを用いてＷｅｂサイトにそれぞれログインさせる。すなわち、ユーザごとにログインした状態となるが、Ｗｅｂページの遷移は同期する状態である。
【０２２０】
このため、例えば、図４１に示すように、変形例３のＩＤ−ＰＷ管理テーブル２２４は、Ｗｅｂサイトにログインするためのアカウント情報を、発着間紐付けＩＤと、発着判定フラグと、ユーザによって入力されたＩＤ及びパスワードとを対応付けて記憶することで管理する。また、変形例３では、ユーザごとにログインし、サイトＣｏｏｋｉｅがユーザごとに払い出されることになるので、Ｃｏｏｋｉｅ管理テーブル２２５は、図４２に示すように、ユーザごとにサイトＣｏｏｋｉｅを管理する。なお、Ｗｅｂページの遷移は同期するものの、Ｗｅｂページの内容自体はユーザごとにカスタマイズされたものとなるので、図４２に示すように、Ｃｏｏｋｉｅ管理テーブル２２５は、ユーザごとに加工済みのＷｅｂコンテンツを管理する。
【０２２１】
例えば、図４３−１に示すように、プロキシサーバ２００は、ステップＳ８０３において一方の情報表示端末２０、例えば発側の情報表示端末２０からＩＤ及びパスワードの入力を受け付ける。なお、変形例３においてはＩＤを共有しない指定が前提となる。
【０２２２】
そして、プロキシサーバ２００は、ステップＳ８０５において示すように、Ｗｅｂコンテンツを取得する際には、発側の情報表示端末２０から入力されたＩＤ及びパスワードを用いる。
【０２２３】
続いて、基本シーケンスと同様の処理が行われた後、図４３−２に示すように、ステップＳ８１３において、他方の情報表示端末２０、例えば着側の情報表示端末２０からプロキシサーバ２００に対するアクセスが行われるが、プロキシサーバ２００は、着側の情報表示端末２０に対しては、強制的に入力フォームを送信する（ステップＳ８１４）。すなわち、ステップＳ８０３においてＩＤを共有しないことが指定された場合であるので、プロキシサーバ２００は、他方の情報表示端末２０に対してはＩＤ及びパスワードの入力を強制的に求めるのである。
【０２２４】
こうして、他方の情報表示端末２０は、自らのＩＤ及びパスワードを送信するので（ステップＳ８１５）、プロキシサーバ２００は、ステップＳ８１５において送信されたＩＤ及びパスワードを用いて新たにＷｅｂサーバにログインし、Ｗｅｂコンテンツを取得することになる（ステップＳ８１７）。
【０２２５】
このような場合、同期させる側によって閲覧されたＷｅｂページのＵＲＬ（例えば、ｓｉｔｅＡのＵＲＬ（１））によって、同期される側のＷｅｂページのＵＲＬ（ｓｉｔｅＡのＵＲＬ（１））が決定するので、閲覧するＷｅｂページはユーザ間で共有される。
【０２２６】
ところが、同期させる側と同期される側とは、それぞれ自己のＩＤ及びパスワードでＷｅｂサイトにログインしている。このため、プロキシサーバ２００が、同期させる側の情報表示端末２０用に取得するＷｅｂコンテンツ及びサイトＣｏｏｋｉｅと、同期される側の情報表示端末２０用に取得するＷｅｂコンテンツ及びサイトＣｏｏｋｉｅとは異なる。例えば、図４３−１のステップＳ８０５において取得したＷｅｂコンテンツ及びサイトＣｏｏｋｉｅと、図４３−２のステップＳ８１７において取得したＷｅｂコンテンツ及びサイトＣｏｏｋｉｅとは異なるものである。また、図４２に示したように、それぞれの情報表示端末２０に返信される加工済みＷｅｂコンテンツも異なるものになる。
【０２２７】
［変形例３のサービスイメージ］
図４４を用いて、上記変形例３のサービスイメージを説明する。図４４は、サービスイメージを説明するための図である。変形例３では、例えば、図４４に示すようなサービスを実現することができる。例えば、ＳＮＳ（Social  Networking  Service）サイトのように、自身のアカウントでログインすることが必要とされるサイトについては、ユーザは、それぞれのアカウントでログインしなければならない。もっとも、変形例３によれば、ログインは個々のアカウントでなされるが、Ｗｅｂページの遷移は同期されるので、ユーザは、自身のアカウントをいつも使っている感覚で、かつＷｅｂコンテンツを共有することが可能になる。アカウントごとにカスタマイズされたページを閲覧することになるので、双方で見た目は異なるが、ページ遷移は追従するイメージである。
【０２２８】
［実施例５の効果］
上記してきたように、実施例５に係るＷｅｂコンテンツ共有システムにおいては、プロキシサーバ２００は、Ｗｅｂコンテンツを取得する際に、該Ｗｅｂコンテンツに関して行われるＷｅｂセッションの状態を管理するための状態管理情報（例えばサイトＣｏｏｋｉｅ）も併せて取得する。また、プロキシサーバ２００は、加工済みのＷｅｂコンテンツとともに、状態管理情報を識別する状態管理識別情報（例えばプロキシＣｏｏｋｉｅ、もしくは合体Ｃｏｏｋｉｅなど）も併せてＷｅｂコンテンツ要求の送信元の情報表示端末２０に返信する。また、プロキシサーバ２００は、送信元と通話を行っているユーザの情報表示端末２０にも、状態管理識別情報を送信する。そして、プロキシサーバ２００は、例えば遷移先のＵＲＬ情報を発着間紐付けＩＤとともに情報表示端末２０から受け付ける際に、状態管理識別情報も併せて受け付け、状態管理識別情報によりＷｅｂサーバから取得した状態管理情報を識別する。そして、プロキシサーバ２００は、該Ｗｅｂコンテンツに関して行われるＷｅｂセッションの状態が該Ｗｅｂサーバによって管理されるように、識別した状態管理情報を用いて制御する。
【０２２９】
このようなことから、実施例５によれば、ユーザ間でページ遷移を同期することができるのみならず、Ｗｅｂセッションの状態管理も実現することができる。
【０２３０】
また、プロキシサーバ２００は、状態管理情報を用いて制御する際に、通話が継続中であるか否かをさらに判定し、該通話が継続中であると判定した場合にのみ、該状態管理情報を用いて制御する。このようなことから、実施例５によれば、通話中にのみサービスを提供することが可能になる。すなわち、通話中でなければＷｅｂセッションを継続することができず、セキュリティを向上することが可能になる。
【０２３１】
また、プロキシサーバ２００は、Ｗｅｂコンテンツに係る情報の連携を停止することを指示する停止指示を、通話を行っているユーザの情報表示端末２０いずれか一方より受け付けると、通話相手のユーザの情報表示端末２０に対して、該情報表示端末２０が保持する状態管理識別情報を無効にすることを指示する無効指示を送信する。
【０２３２】
また、プロキシサーバ２００は、停止指示を解除し、Ｗｅｂコンテンツに係る情報の連携を復活することを指示する復活指示を、停止指示を送信した情報表示端末２０から受け付けると、通話相手のユーザの情報表示端末２０に対して、復活指示を送信した情報表示端末２０とＷｅｂサーバとの間で有効な状態管理情報を識別する状態管理識別情報を送信する。
【０２３３】
このようなことから、実施例５によれば、アカウントの一時共有や復活が可能になり、アカウント共有の利便性を高めることが可能になる。
【実施例６】
【０２３４】
さて、これまで実施例１〜３においては、既存のＷｅｂコンテンツを共有する形態として「ページ遷移の同期」を例に挙げて説明した。また、実施例４においては、既存のＷｅｂコンテンツを共有する形態として「ページ内での操作の同期」を例に挙げ、特に『マウス操作の同期』を説明した。しかしながら、本発明はこれに限られるものではない。実施例６においては、「ページ内での操作の同期」の一例として『フォーム操作の同期』を説明する。
【０２３５】
［フォーム操作の同期］
まず、図４５及び図４６を用いて、『フォーム操作の同期』の概要を説明する。図４５及び図４６は、実施例６の概要を説明するための図である。実施例６に係るＷｅｂコンテンツ共有システムにおいて、プロキシサーバは、Ｗｅｂコンテンツ（Ｗｅｂページ）を構成する情報のうちユーザによって変更され得る情報を、一元的に管理する。また、各ユーザは、プロキシサーバによって一元的に管理されたこの情報を、更新あるいは参照する。すると、各ユーザが閲覧するＷｅｂコンテンツには、プロキシサーバによって一元的に管理されたこの情報が反映され、複数のユーザ間で『フォーム操作の同期』が実現される。なお、かかる『フォーム操作の同期』は、いわば、共有関係にあるユーザ間で、仮想的に１つのブラウザを閲覧あるいは操作するイメージである。このため、以下では、プロキシサーバが一元的に管理する情報のことを『仮想共有ブラウザ情報』などと称する。
【０２３６】
図４５に示すように、実施例６におけるプロキシサーバは、ＷｅｂコンテンツのＨＴＭＬタグを解析し、Ｗｅｂコンテンツを構成する情報のうちユーザによって変更され得る情報（以下、仮想共有ブラウザ情報）を、仮想共有ブラウザテーブルに格納する。仮想共有ブラウザ情報は、図４５に示すように、例えば、ページ共通情報とページ固有情報とに分類することができる。
【０２３７】
ページ共通情報は、マウスポインタ座標やウィンドウサイズなど、閲覧されるページが遷移しても継続して保持される情報である。一方、ページ固有情報は、閲覧されるページが遷移すると、更新あるいは破棄される情報である。ページ固有情報は、さらに、１ページに１つ含まれる情報と、１ページに任意の数含まれる情報とに分類することができる。前者の一例としては、例えば、ＵＲＬやスクロール量などがある。また、後者の一例としては、例えば、ＨＴＭＬのｆｏｒｍタグによって作成されたテキストエリアやチェックボックスなどがある。なお、図４５に示す点線の矢印は、Ｗｅｂコンテンツの構成要素と仮想共有ブラウザ情報との対応関係を概念的に示すものである。
【０２３８】
図４６に示すように、例えばユーザ１とユーザ２とが共有関係にある場合を想定する。ユーザ１が、自己が閲覧するＷｅｂブラウザ上で、Ｗｅｂコンテンツのフォームにテキストやチェックを入力すると、プロキシサーバは、仮想共有ブラウザテーブルに記憶された仮想共有ブラウザ情報を更新する。例えば、ユーザ１が、Ｗｅｂコンテンツのテキストエリア「テキスト２」に『テスト』と入力し、チェックボックスにチェックを入力する。すると、ユーザ１の情報表示端末は、これらの仮想共有ブラウザ情報をプロキシサーバに送信する。プロキシサーバは、仮想共有ブラウザテーブルに記憶された仮想共有ブラウザ情報のうち、「テキスト２」に対応する「テキストエリア２」のｖａｌｕｅに『テスト』を格納する。また、プロキシサーバは、仮想共有ブラウザテーブルに記憶された仮想共有ブラウザ情報のうち、「チェックボックス」のｖａｌｕｅに『ｏｎ』を格納する。
【０２３９】
一方、ユーザ２の情報表示端末は、プロキシサーバの仮想共有ブラウザテーブルを参照し、更新された仮想共有ブラウザ情報があれば、その仮想共有ブラウザ情報を、自身が閲覧するＷｅｂブラウザ上のＷｅｂコンテンツに反映する。例えば、ユーザ２の情報表示端末は、プロキシサーバに対してポーリングを行うなどして仮想共有ブラウザテーブルを参照し、更新された仮想共有ブラウザ情報として、「テキストエリア２」のｖａｌｕｅ『テスト』と、「チェックボックス」のｖａｌｕｅ『ｏｎ』とを取得する。そして、ユーザ２の情報表示端末は、Ｗｅｂコンテンツのフォームのうち、「テキストエリア２」に対応する「テキスト２」に『テスト』を表示し、「チェックボックス」にチェックを表示する。
【０２４０】
なお、図４６においては、ユーザ１がフォームに対する入力を行い、ユーザ２が、ユーザ１によって更新されたＷｅｂコンテンツを閲覧する例を説明したが、本発明はこれに限られるものではない。例えば、ユーザ２がフォームに対する入力を行い、ユーザ１が、ユーザ２によって更新されたＷｅｂコンテンツを閲覧する場合や、双方のユーザが入力を行い、双方のユーザが更新されたＷｅｂコンテンツを閲覧する場合などにも、同様に適用することができる。
【０２４１】
［実施例６におけるプロキシサーバ４００の構成］
次に、図４７及び図４８を用いて、実施例６におけるプロキシサーバ４００の構成を説明する。図４７は、実施例６におけるプロキシサーバ４００の構成を示すブロック図であり、図４８は、仮想共有ブラウザテーブル４２１を説明するための図である。
【０２４２】
図４７に示すように、実施例６におけるプロキシサーバ４００は、記憶部４２０に、仮想共有ブラウザテーブル４２１を備える。また、実施例６におけるプロキシサーバ４００は、制御部４３０に、Ｗｅｂコンテンツ要求受付部４３１、Ｗｅｂコンテンツ取得部４３２、仮想共有ブラウザ生成部４３３、Ｗｅｂコンテンツ加工部４３４、加工済Ｗｅｂコンテンツ返信部４３５、閲覧制御部４３６、仮想共有ブラウザ情報受付部４３７、仮想共有ブラウザ情報要求受付部４３８、仮想共有ブラウザ情報返信部４３９を備える。
【０２４３】
仮想共有ブラウザテーブル４２１は、情報表示端末２０において操作された操作情報として、仮想共有ブラウザ情報を記憶する。具体的には、仮想共有ブラウザテーブル４２１は、仮想共有ブラウザ生成部４３３によって発着間紐付けＩＤ毎に生成される。また、仮想共有ブラウザテーブル４２１は、仮想共有ブラウザ情報受付部４３７によって受け付けられた仮想共有ブラウザ情報を、発着間紐付けＩＤ毎に記憶する。また、仮想共有ブラウザテーブル４２１が記憶する仮想共有ブラウザ情報は、仮想共有ブラウザ情報要求受付部４３８や仮想共有ブラウザ情報返信部４３９による処理に利用される。
【０２４４】
例えば、仮想共有ブラウザテーブル４２１は、図４８に示すように、発着間紐付けＩＤに対応付けて、ページ共通情報及びページ固有情報を記憶する。例えば、仮想共有ブラウザテーブル４２１は、ページ共通情報として、ユーザ毎に、マウスポインタ座標を記憶する。また、例えば、仮想共有ブラウザテーブル４２１は、ページ共通情報として、ウィンドウサイズ（横幅及び縦幅）を記憶する。
【０２４５】
また、例えば、仮想共有ブラウザテーブル４２１は、ページ固有情報として、ＵＲＬを記憶する。図４８において、通番とは、仮想共有ブラウザテーブル４２１が生成された後、ユーザによって閲覧されたＷｅｂコンテンツに付与された通し番号である。また、図４８において、名前とは、ＵＲＬ情報である。また、例えば、仮想共有ブラウザテーブル４２１は、ページ固有情報として、スクロール量（水平及び垂直）を記憶する。また、例えば、仮想共有ブラウザテーブル４２１は、ページ固有情報として、ＨＴＭＬのｆｏｒｍタグによって作成されたフォーム情報を記憶する。図４８において、フォーム情報には、テキストエリアやチェックボックスが含まれる。なお、フォーム情報は、図４８に示すものに限られず、例えばラジオボタンやセレクトボックスなど、ユーザによって変更され得る情報であれば他の情報であってもよい。フォーム情報は、図４８に示すように、例えばｎａｍｅ属性やｖａｌｕｅ属性を有し、例えばｎａｍｅ属性によって識別される。
【０２４６】
なお、実施例６においては、仮想共有ブラウザ情報をテーブル形式で記憶する手法を説明したが、これに限られるものではなく、例えば、発着間紐付けＩＤ毎のファイル形式で記憶する手法などでもよい。
【０２４７】
図４７に戻り、制御部４３０のＷｅｂコンテンツ要求受付部４３１は、これまでの実施例で説明したＷｅｂコンテンツ要求受付部２３１と同様の機能を有する。また、Ｗｅｂコンテンツ取得部４３２は、これまでの実施例で説明したＷｅｂコンテンツ取得部２３２と同様の機能を有する。また、加工済Ｗｅｂコンテンツ返信部４３５は、これまでの実施例で説明した加工済Ｗｅｂコンテンツ返信部２３４と同様の機能を有する。また、閲覧制御部４３６は、これまでの実施例で説明した閲覧制御部２３５と同様の機能を有する。
【０２４８】
以下では、仮想共有ブラウザ生成部４３３、Ｗｅｂコンテンツ加工部４３４、仮想共有ブラウザ情報受付部４３７、仮想共有ブラウザ情報要求受付部４３８、仮想共有ブラウザ情報返信部４３９を、順に説明する。
【０２４９】
仮想共有ブラウザ生成部４３３は、仮想共有ブラウザテーブル４２１を生成する。具体的には、仮想共有ブラウザ生成部４３３は、Ｗｅｂコンテンツ取得部４３２から、Ｗｅｂコンテンツ及び発着間紐付けＩＤを受け取る。次に、仮想共有ブラウザ生成部４３３は、Ｗｅｂコンテンツ取得部４３２から受け取ったＷｅｂコンテンツのＨＴＭＬタグを解析し、Ｗｅｂコンテンツから仮想共有ブラウザ情報を抽出する。また、仮想共有ブラウザ生成部４３３は、抽出した仮想共有ブラウザ情報を、Ｗｅｂコンテンツ取得部４３２から受け取った発着間紐付けＩＤと対応付け、仮想共有ブラウザテーブル４２１を生成する。仮想共有ブラウザ生成部４３３は、例えば図４８に示したような仮想共有ブラウザテーブル４２１を生成する。
【０２５０】
Ｗｅｂコンテンツ加工部４３４は、Ｗｅｂコンテンツを加工する。具体的には、Ｗｅｂコンテンツ加工部４３４は、Ｗｅｂコンテンツ取得部４３２から、Ｗｅｂコンテンツ、発着間紐付けＩＤ及び発着判定フラグを受け取る。また、Ｗｅｂコンテンツ加工部４３４は、Ｗｅｂコンテンツ取得部４３２から受け取ったＷｅｂコンテンツを加工し、加工済みのＷｅｂコンテンツを加工済Ｗｅｂコンテンツ返信部４３５に送り、加工済みのＷｅｂコンテンツを閲覧するためのＵＲＬ情報、発着間紐付けＩＤ及び発着判定フラグを閲覧制御部４３６に送る。
【０２５１】
ここで、Ｗｅｂコンテンツ加工部４３４は、これまでの実施例で説明したＷｅｂコンテンツ加工部２３３と同様の機能を有する他、以下のような機能を有する。すなわち、Ｗｅｂコンテンツ加工部４３４は、仮想共有ブラウザ情報が情報表示端末２０において変更された場合に、仮想共有ブラウザ情報を発着間紐付けＩＤとともに仮想共有ブラウザ情報受付部４３７に通知するように、Ｗｅｂコンテンツを加工する。
【０２５２】
具体的には、Ｗｅｂコンテンツ加工部４３４は、Ｗｅｂコンテンツを加工する際に、仮想共有ブラウザプログラムを挿入する。ここで、仮想共有ブラウザプログラムは、情報表示端末２０において、仮想共有ブラウザ情報を取得するとともに、取得した仮想共有ブラウザ情報が発着間紐付けＩＤとともに仮想共有ブラウザ情報受付部４３７によって受け付けられるようにするためのプログラムである。なお、マウスポインタ座標などのように、ユーザ（発着）の区別が必要な仮想共有ブラウザ情報については、仮想共有ブラウザプログラムは、取得した仮想共有ブラウザ情報が、発着間紐付けＩＤ及び発着判定フラグとともに仮想共有ブラウザ情報受付部４３７によって受け付けられるようにする。また、情報表示端末２０における仮想共有ブラウザ情報の取得は、例えば文字が入力される毎に取得して仮想共有ブラウザ情報受付部４３７に送信する手法でもよい。あるいは、例えば確定ボタンが押下されることにより一連の文字の入力が確定した後に取得して、仮想共有ブラウザ情報受付部４３７に送信する手法でもよい。
【０２５３】
また、仮想共有ブラウザプログラムは、仮想共有ブラウザ情報要求が、発着間紐付けＩＤ及び発着判定フラグとともに仮想共有ブラウザ情報要求受付部４３８によって受け付けられるようにするためのプログラムである。
【０２５４】
例えば、仮想共有ブラウザプログラムは、ＪａｖａＳｃｒｉｐｔ（登録商標）などのスクリプトによって実現され、Ｗｅｂコンテンツ加工部４３４によってＷｅｂコンテンツに挿入される。なお、スクリプトの挿入は、実施例４において説明したマウスポインタ共有プログラムと同様に行われる。
【０２５５】
仮想共有ブラウザ情報受付部４３７は、仮想共有ブラウザ情報を情報表示端末２０から受け付ける。具体的には、仮想共有ブラウザ情報受付部４３７は、仮想共有ブラウザ情報を、発着間紐付けＩＤ（必要に応じ、発着間紐付けＩＤ及び発着判定フラグ）とともに情報表示端末２０から受け付ける。そして、仮想共有ブラウザ情報受付部４３７は、受け付けた仮想共有ブラウザ情報を、発着間紐付けＩＤが一致する仮想共有ブラウザテーブル４２１に格納する。
【０２５６】
仮想共有ブラウザ情報要求受付部４３８は、仮想共有ブラウザ情報を要求する仮想共有ブラウザ情報要求を、情報表示端末２０から受け付ける。具体的には、仮想共有ブラウザ情報要求受付部４３８は、仮想共有ブラウザ情報要求を、発着間紐付けＩＤ及び発着判定フラグとともに情報表示端末２０から受け付ける。
【０２５７】
仮想共有ブラウザ情報返信部４３９は、仮想共有ブラウザ情報要求に応答して、仮想共有ブラウザ情報を情報表示端末２０に返信する。具体的には、仮想共有ブラウザ情報返信部４３９は、仮想共有ブラウザ情報要求受付部４３８によって仮想共有ブラウザ情報要求が受け付けられると、仮想共有ブラウザ情報要求とともに受け付けた発着間紐付けＩＤを用いて仮想共有ブラウザテーブル４２１を検索する。そして、仮想共有ブラウザ情報返信部４３９は、例えば、仮想共有ブラウザテーブル４２１に記憶された仮想共有ブラウザ情報から、前回の要求後に更新された仮想共有ブラウザ情報を抽出し、抽出した仮想共有ブラウザ情報を、仮想共有ブラウザ情報要求の送信元の情報表示端末２０に返信する。
【０２５８】
なお、更新された仮想共有ブラウザ情報の抽出は、例えば、各仮想共有ブラウザ情報にタイムスタンプを付すことによって実現することができる。例えば、仮想共有ブラウザ情報受付部４３７が仮想共有ブラウザテーブル４２１に仮想共有ブラウザ情報を格納する際に、タイムスタンプを付すこととする。一方、仮想共有ブラウザ情報要求を送信する情報表示端末２０は、前回の要求がいつ行われたかを示す時刻情報を、仮想共有ブラウザ情報要求とともに送信することとする。すると、仮想共有ブラウザ情報返信部４３９は、情報表示端末２０から送信された時刻情報と、各仮想共有ブラウザ情報に付されたタイムスタンプとを比較し、時刻情報が示す時刻以降のタイムスタンプが付された仮想共有ブラウザ情報を抽出する。
【０２５９】
また、更新された仮想共有ブラウザ情報の抽出は、例えば、各仮想共有ブラウザ情報に発着判定フラグを付すことによっても実現することができる。例えば、仮想共有ブラウザ情報受付部４３７が仮想共有ブラウザテーブル４２１に仮想共有ブラウザ情報を格納する際に、発着判定フラグを付すこととする。すると、仮想共有ブラウザ情報返信部４３９は、情報表示端末２０から送信された発着判定フラグを用いて、通話相手側の情報表示端末２０によって更新された仮想共有ブラウザ情報を抽出する。この場合、仮想共有ブラウザ情報返信部４３９は、タイムスタンプと発着判定フラグとを併せて用いてもよい。
【０２６０】
［実施例６に係るＷｅｂコンテンツ共有システムによる処理手順］
続いて、図４９及び図５０を用いて、実施例６に係るＷｅｂコンテンツ共有システムによる処理手順を説明する。図４９及び図５０は、実施例６に係るＷｅｂコンテンツ共有システムによる処理手順を示すシーケンス図である。
【０２６１】
図４９に示す処理手順は、例えば実施例１において図１６を用いて説明した処理手順とほぼ同様であるが、ステップＳ９１２として、仮想共有ブラウザを生成する処理が含まれる点が異なる。すなわち、ステップＳ９１２において、仮想共有ブラウザ生成部４３３が、ＷｅｂコンテンツのＨＴＭＬタグを解析し、Ｗｅｂコンテンツから抽出した仮想共有ブラウザ情報を発着間紐付けＩＤと対応付け、仮想共有ブラウザテーブル４２１を生成する。なお、図４９においては、仮想共有ブラウザを生成する処理が、Ｗｅｂコンテンツを加工する処理の前に行われる例を示したが、これに限られるものではない。仮想共有ブラウザを生成する処理は、例えば、Ｗｅｂコンテンツを加工する処理と併行して行われてもよいなど、任意である。
【０２６２】
さて、図５０においては、図４９に示す処理手順が既に行われ、情報表示端末２０それぞれに、加工済みのＷｅｂコンテンツが送信されていることを想定する。加工済みのＷｅｂコンテンツには、仮想共有ブラウザプログラムが挿入されている。このため、加工済みのＷｅｂコンテンツを受信した情報表示端末２０それぞれは、ポーリングスクリプトにより、図５０のステップＳ１００１に示すように、例えば０．５秒間隔などで、プロキシサーバ４００にポーリングする。なお、図５０において点線で示す矢印は、ポーリングであることを示す。
【０２６３】
例えば、発側のユーザの情報表示端末２０において、Ｗｅｂコンテンツ上で、仮想共有ブラウザ情報が入力されたとする。すると、情報表示端末２０は、仮想共有ブラウザプログラムにより、仮想共有ブラウザ情報を、発着間紐付けＩＤ（必要に応じて、発着間紐付けＩＤ及び発着判定フラグ）とともに送信する（ステップＳ１００２）。すると、プロキシサーバ４００の仮想共有ブラウザ情報受付部４３７がこれを受け付け、仮想共有ブラウザテーブル４２１に格納する（ステップＳ１００３）。
【０２６４】
一方、着側のユーザの情報表示端末２０は、図５０のステップＳ１００４に示すように、プロキシサーバ４００の仮想共有ブラウザ情報要求受付部４３８に、発着間紐付けＩＤ及び発着判定フラグとともにポーリングする。すると、仮想共有ブラウザ情報返信部４３９は、発着間紐付けＩＤ及び発着判定フラグを用いて仮想共有ブラウザテーブル４２１を検索し、前回の要求後に更新された仮想共有ブラウザ情報を取得する（ステップＳ１００５）。そして、仮想共有ブラウザ情報返信部４３９は、取得した仮想共有ブラウザ情報を、ポーリング元の情報表示端末２０に返信する（ステップＳ１００６）。
【０２６５】
すると、着側のユーザの情報表示端末２０において閲覧されるＷｅｂコンテンツには、発側のユーザの情報表示端末２０において操作された仮想共有ブラウザ情報（例えば、更新されたフォーム情報など）が表示される（ステップＳ１００７）。
【０２６６】
［実施例６の効果］
上述したように、実施例６に係るＷｅｂコンテンツ共有システムにおいては、プロキシサーバ４００が、情報表示端末２０において操作された仮想共有ブラウザ情報（例えば、フォーム情報）を発着間紐付けＩＤと対応付けて記憶する仮想共有ブラウザテーブル４２１をさらに備える。そして、仮想共有ブラウザ情報受付部４３７が、仮想共有ブラウザ情報が通話を行っているユーザの情報表示端末２０いずれか一方より変更された場合に、仮想共有ブラウザ情報を発着間紐付けＩＤとともに情報表示端末２０から受け付け、仮想共有ブラウザテーブル４２１に格納する。また、仮想共有ブラウザ情報要求受付部４３８が、仮想共有ブラウザ情報を要求する仮想共有ブラウザ情報要求を発着間紐付けＩＤとともに情報表示端末２０から受け付ける。また、仮想共有ブラウザ情報返信部４３９が、仮想共有ブラウザ情報要求とともに受け付けた発着間紐付けＩＤを用いて仮想共有ブラウザテーブル４２１を検索し、仮想共有ブラウザ情報要求の送信元と通話を行っているユーザの仮想共有ブラウザ情報を、送信元の情報表示端末２０に返信する。
【０２６７】
このようなことから、実施例６によれば、「ページ内での操作の同期」、例えばフォーム操作の同期を実現することも可能になる。また、ユーザ間で共有する仮想共有ブラウザ情報を記憶するテーブルはプロキシサーバ４００に備えられるので、既存のＷｅｂサーバがデータを記憶する必要もない。
【実施例７】
【０２６８】
次に、実施例７に係るＷｅｂコンテンツ共有システムは、Ｗｅｂコンテンツの閲覧履歴を通話情報と関連付けて保存し、後に、この閲覧履歴を用いて再度の閲覧を制御する。
【０２６９】
［閲覧履歴の保存及び閲覧履歴による閲覧の制御］
まず、図５１を用いて、『閲覧履歴の保存及び閲覧履歴による閲覧の制御』の概要を説明する。図５１は、実施例７の概要を説明するための図である。実施例７に係るＷｅｂコンテンツ共有システムにおいて、プロキシサーバは、Ｗｅｂコンテンツの閲覧履歴を全て保存する。また、各ユーザは、自身が閲覧したＷｅｂコンテンツについて、閲覧履歴として保存する際の属性を指定することができる。このため、実施例７におけるプロキシサーバは、各ユーザにおいて指定された属性も併せて保存し、この属性に基づいて閲覧を制御する。
【０２７０】
図５１に示すように、各ユーザは、閲覧履歴の属性として、例えば、『履歴フラグ』、『ひとりフラグ』、『保証フラグ』を指定することができる。プロキシサーバは、例えば『履歴フラグ』の属性が指定されたＷｅｂコンテンツについては、閲覧履歴として保存された際と同じユーザ間で通話している場合に、両ユーザによる再度の閲覧が可能となるように制御する（図５１の（１）を参照）。また、プロキシサーバは、『ひとりフラグ』の属性が指定されたＷｅｂコンテンツについては、閲覧履歴として保存された際に『ひとりフラグ』の属性を指定した本人、あるいは、属性を指定した本人の通話相手のいずれかであれば、そのユーザによる再度の閲覧が可能となるように制御する（図５１の（２）を参照）。例えば、Ｗｅｂコンテンツ共有システムは、閲覧履歴の閲覧用に予め定められた特定の番号（特番）を用意する。ユーザがその特番に電話すると、通話相手無しの状態（例えば音声自動応答の状態）となる。そして、Ｗｅｂコンテンツ共有システムは、ユーザが、その状態において、『ひとりフラグ』の属性が指定されたＷｅｂコンテンツを閲覧することができるように制御する。
【０２７１】
また、プロキシサーバは、『保証フラグ』の属性が指定されたＷｅｂコンテンツについては、『保証フラグ』の属性を指定したユーザ（例えばユーザＡ）が、閲覧履歴として保存された際の通話相手（例えばユーザＢ）と異なる通話相手（例えばユーザＣ）と通話している場合に、両ユーザ（ユーザＡ及びユーザＣ）による再度の閲覧が可能となるように制御する（図５１の（３）を参照）。この再度の閲覧には、通話相手（ユーザＣ）に対し、属性を指定した本人（ユーザＡ）とその際の通話相手（ユーザＢ）とが通話中に閲覧したことを保証する意味がある。
【０２７２】
『保証フラグ』の活用方法について一例を挙げて説明する。例えば、ユーザＡが患者、ユーザＢが病院、ユーザＣが保険会社であるとする。ユーザＢ（病院）とユーザＣ（保険会社）との間では、予め、ユーザＣ（保険会社）がユーザＡ（患者）との間で契約をする条件として、ユーザＡ（患者）とユーザＢ（病院）とが所定のＷｅｂコンテンツ（健康状態確認コンテンツ）を一緒に閲覧した上で、ユーザＢ（病院）がその健康状態確認コンテンツ上で『承認』を行うことを定めている。また、その健康状態確認コンテンツは、ユーザＣ（保険会社）を除いては、ユーザＢ（病院）との通話中でなければ閲覧できず、また『承認』も、ユーザＢ（病院）でなければできない仕組みとする。
【０２７３】
このような場合に、例えば、ユーザＡ（患者）とユーザＣ（保険会社）とが通話することになり、閲覧可能なＷｅｂコンテンツとして健康状態確認コンテンツが提示されれば、ユーザＣ（保険会社）は、少なくともユーザＡ（患者）とユーザＢ（病院）とが通話中に健康状態確認コンテンツを閲覧した事実を確認することができる。また、ユーザＣ（保険会社）が、閲覧履歴の再度の閲覧としてこの健康状態確認コンテンツを閲覧し、『承認』を確認すれば、ユーザＣ（保険会社）は、ユーザＢ（病院）が、ユーザＡ（患者）の健康状態について『承認』を与えたという事実を確認することができる。
【０２７４】
なお、『保証フラグ』の活用方法は上記例に限られない。例えば、汎用的に、あるユーザ間における通話中に閲覧されたＷｅｂページであることを第三者に保証したい場合には、プロキシサーバは、そのＷｅｂページに、例えば「ユーザ○○とユーザ○○との間における通話中に閲覧されたＷｅｂページである」との情報を表示するように制御すればよい。その際、プロキシサーバは、例えば発着間紐付けＩＤを用いてセッション連携サーバに問い合わせを行い、ユーザを特定する情報を取得し、取得した情報を用いて、閲覧履歴として提供するＷｅｂページを加工すればよい。
【０２７５】
［実施例７におけるプロキシサーバ５００の構成］
次に、図５２〜５４を用いて、実施例７におけるプロキシサーバ５００の構成を説明する。図５２は、実施例７におけるプロキシサーバ５００の構成を示すブロック図であり、図５３は、閲覧履歴テーブル５２１を説明するための図である。また、図５４は、閲覧履歴リストを説明するための図である。
【０２７６】
図５２に示すように、実施例７におけるプロキシサーバ５００は、記憶部５２０に、閲覧履歴テーブル５２１を備える。また、実施例７におけるプロキシサーバ５００は、制御部５３０に、Ｗｅｂコンテンツ要求受付部５３１、Ｗｅｂコンテンツ取得部５３２、閲覧履歴保存部５３３、Ｗｅｂコンテンツ加工部５３４、加工済Ｗｅｂコンテンツ返信部５３５、閲覧制御部５３６、お気に入り指定受付部５３７、お気に入り閲覧制御部５３８を備える。
【０２７７】
閲覧履歴テーブル５２１は、情報表示端末２０において閲覧されたＷｅｂコンテンツを、通話情報と関連付けて記憶する。具体的には、閲覧履歴テーブル５２１は、履歴保存部５３３によって格納されることで、Ｗｅｂコンテンツの閲覧履歴を記憶する。また、閲覧履歴テーブル５２１が記憶する閲覧履歴は、お気に入り閲覧制御部５３８による処理に利用される。
【０２７８】
例えば、閲覧履歴テーブル５２１は、図５３に示すように、発着間紐付けＩＤに対応付けて、Ｗｅｂコンテンツの所在情報であるＵＲＬと、閲覧履歴が格納された時刻を示すタイムスタンプと、各種フラグとを記憶する。
【０２７９】
図５２に戻り、制御部５３０のＷｅｂコンテンツ要求受付部５３１は、これまでの実施例で説明したＷｅｂコンテンツ要求受付部２３１と同様の機能を有する。また、Ｗｅｂコンテンツ取得部５３２は、これまでの実施例で説明したＷｅｂコンテンツ取得部２３２と同様の機能を有する。また、加工済Ｗｅｂコンテンツ返信部５３５は、これまでの実施例で説明した加工済Ｗｅｂコンテンツ返信部２３４と同様の機能を有する。また、閲覧制御部５３６は、これまでの実施例で説明した閲覧制御部２３５と同様の機能を有する。
【０２８０】
以下では、閲覧履歴保存部５３３、Ｗｅｂコンテンツ加工部５３４、お気に入り指定受付部５３７、お気に入り閲覧制御部５３８を、順に説明する。
【０２８１】
閲覧履歴保存部５３３は、Ｗｅｂコンテンツの閲覧履歴を保存する。具体的には、閲覧履歴保存部５３３は、Ｗｅｂコンテンツ取得部５３２から、Ｗｅｂコンテンツ及び発着間紐付けＩＤを受け取る。次に、閲覧履歴保存部５３３は、Ｗｅｂコンテンツ取得部５３２から受け取った発着間紐付けＩＤに対応付けて、Ｗｅｂコンテンツ取得部５３２から受け取ったＷｅｂコンテンツのＵＲＬを、閲覧履歴テーブル５２１に格納する。また、閲覧履歴保存部５３３は、閲覧履歴を格納した時刻を示すタイムスタンプも格納する。なお、この段階において、『履歴フラグ』、『ひとりフラグ』、及び『保証フラグ』は空欄である。
【０２８２】
ここで、閲覧履歴保存部５３３によって閲覧履歴テーブル５２１に格納されたタイムスタンプの活用方法について説明する。上述したように、閲覧履歴保存部５３３は、発着間紐付けＩＤに対応付けてＷｅｂコンテンツのＵＲＬを閲覧履歴テーブル５２１に格納する。セッション連携サーバ１００は、発着間紐付けＩＤに対応付けて通話履歴情報（開始時刻及び終了時刻）を管理しているので、プロキシサーバ５００は、例えばセッション連携サーバ１００に問い合わせることで、発着間紐付けＩＤに対応付けて格納されたＷｅｂコンテンツの閲覧時刻を取得することができる。しかしながら、発着間紐付けＩＤに基づいて取得することができるこの閲覧時刻は、通話全体の時刻であって、各Ｗｅｂコンテンツ毎の閲覧時刻ではない。このようなことから、実施例７における閲覧履歴保存部５３３は、ＷｅｂコンテンツのＵＲＬを格納する際に、各ＷｅｂコンテンツのＵＲＬに対応付けてタイムスタンプを格納する。このようにして格納されたタイムスタンプは、「いつ閲覧されたか」といった時刻情報が契約に必要な場合など、各Ｗｅｂコンテンツの閲覧時刻が重要となる場合などに有効活用される。
【０２８３】
なお、例えば、後述するお気に入り閲覧制御部５３８は、閲覧履歴として保存されたＷｅｂコンテンツの再度の閲覧を制御する際に、閲覧履歴テーブル５２１からタイムスタンプを取得し、Ｗｅｂコンテンツがいつ閲覧されたものであるかを示す情報として、Ｗｅｂコンテンツ上に閲覧時刻を表示してもよい。
【０２８４】
Ｗｅｂコンテンツ加工部５３４は、Ｗｅｂコンテンツを加工する。具体的には、Ｗｅｂコンテンツ加工部５３４は、Ｗｅｂコンテンツ取得部５３２から、Ｗｅｂコンテンツ、発着間紐付けＩＤ及び発着判定フラグを受け取る。また、Ｗｅｂコンテンツ加工部５３４は、Ｗｅｂコンテンツ取得部５３２から受け取ったＷｅｂコンテンツを加工し、加工済みのＷｅｂコンテンツを加工済Ｗｅｂコンテンツ返信部５３５に送り、加工済みのＷｅｂコンテンツを閲覧するためのＵＲＬ情報、発着間紐付けＩＤ及び発着判定フラグを閲覧制御部５３６に送る。
【０２８５】
ここで、Ｗｅｂコンテンツ加工部５３４は、これまでの実施例で説明したＷｅｂコンテンツ加工部２３３と同様の機能を有する他、以下のような機能を有する。すなわち、Ｗｅｂコンテンツ加工部５３４は、閲覧履歴の属性の指定を受け付けるための情報を情報表示端末２０のＷｅｂブラウザ上に表示するとともに、属性の指定が受け付けられた場合に、指定情報を発着間紐付けＩＤとともにお気に入り指定受付部５３７に通知するように、Ｗｅｂコンテンツを加工する。
【０２８６】
具体的には、Ｗｅｂコンテンツ加工部５３４は、Ｗｅｂコンテンツを加工する際に、お気に入り指定閲覧プログラムを挿入する。ここで、お気に入り指定閲覧プログラムは、情報表示端末２０において、閲覧履歴の属性の指定を受け付けるための情報（例えば、図５１に示したチェックボックス付きのウィンドウなど）をＷｅｂブラウザ上に表示するとともに、属性の指定が受け付けられた場合に、指定情報を発着間紐付けＩＤとともにお気に入り指定受付部５３７に受け付けられるようにするためのプログラムである。
【０２８７】
また、お気に入り指定閲覧プログラムは、お気に入りとして登録したＷｅｂコンテンツを再度閲覧することを要求する閲覧要求が、発着間紐付けＩＤ及び発着判定フラグとともにお気に入り閲覧制御部５３８によって受け付けられるようにするためのプログラムである。
【０２８８】
例えば、お気に入り指定閲覧プログラムは、ＪａｖａＳｃｒｉｐｔ（登録商標）などのスクリプトによって実現され、Ｗｅｂコンテンツ加工部５３４によってＷｅｂコンテンツに挿入される。なお、スクリプトの挿入は、実施例４において説明したマウスポインタ共有プログラムと同様に行われる。
【０２８９】
お気に入り指定受付部５３７は、閲覧履歴の属性の指定を情報表示端末２０から受け付ける。具体的には、お気に入り指定受付部５３７は、閲覧履歴の属性の指定、すなわち、『履歴フラグ』、『ひとりフラグ』、『保証フラグ』の指定情報を、発着間紐付けＩＤ（必要に応じ、発着間紐付けＩＤ及び発着判定フラグ）とともに情報表示端末２０から受け付ける。そして、お気に入り指定受付部５３７は、受け付けた指定情報を、閲覧履歴テーブル５２１に記憶されたレコードのうち、発着間紐付けＩＤが一致するレコードに格納する。なお、属性の指定は、現に閲覧中のＷｅｂコンテンツに対して行われることを想定するので、お気に入り指定受付部５３７は、閲覧履歴テーブル５２１に記憶されたレコードのうち、現に閲覧中のＷｅｂコンテンツのレコードであって発着間紐付けＩＤが一致するレコードに格納する。
【０２９０】
お気に入り閲覧制御部５３８は、閲覧履歴として保存されたＷｅｂコンテンツの再度の閲覧を制御する。具体的には、お気に入り閲覧制御部５３８は、閲覧履歴として保存されたＷｅｂコンテンツの閲覧要求を、発着間紐付けＩＤ及び発着判定フラグとともに情報表示端末２０から受け付ける。
【０２９１】
次に、お気に入り閲覧制御部５３８は、閲覧要求を受け付けると、発着間紐付けＩＤ及び発着判定フラグを用いて閲覧履歴テーブル５２１を参照し、閲覧要求の要求元に再度閲覧させることが可能な閲覧履歴のリストを取得する。そして、お気に入り閲覧制御部５３８は、閲覧履歴テーブル５２１から取得した閲覧履歴のリストを要求元の情報表示端末２０に送信する。
【０２９２】
その後、情報表示端末２０においてＵＲＬが選択され、選択されたＵＲＬがプロキシサーバ５００に送信された場合、Ｗｅｂコンテンツの閲覧をどのように制御するか、２つの手法が考えられる。ひとつの手法としては、プロキシサーバ５００が、閲覧履歴としてＷｅｂコンテンツ自体も保存している場合、例えばお気に入り閲覧制御部５３８が、このＷｅｂコンテンツを取得し、ＵＲＬの送信元の情報表示端末２０に返信する手法が考えられる。
【０２９３】
Ｗｅｂコンテンツ自体を保存する手法の中にも、加工済みのＷｅｂコンテンツを保存する手法、加工前のＷｅｂコンテンツを保存する手法、あるいはＷｅｂコンテンツを画像として保存する手法（スクリーンショットなど）などがある。加工済みのＷｅｂコンテンツを保存する手法では、お気に入り閲覧制御部５３８は、閲覧履歴として保存された際の過去の発着間紐付けＩＤが埋め込まれた加工済みのＷｅｂコンテンツを、ＵＲＬの送信元の情報表示端末２０に返信することになる。このため、閲覧履歴を閲覧した情報表示端末２０において、例えばユーザがリンク情報をクリックしてページ遷移を試みたとしても、ページ遷移の同期などは適切には制御されない。
【０２９４】
一方、加工前のＷｅｂコンテンツを保存する手法では、プロキシサーバ５００は、改めてこのＷｅｂコンテンツをＷｅｂコンテンツ加工部５３４に加工させるなどした上で、ＵＲＬの送信元の情報表示端末２０に返信することができる。この際の加工として、Ｗｅｂコンテンツ加工部５３４は、例えば、閲覧履歴として保存された際と同じ状態に加工することができる。すなわち、Ｗｅｂコンテンツ加工部５３４は、過去の発着間紐付けＩＤが埋め込まれた加工済みのＷｅｂコンテンツに加工することができる。また、Ｗｅｂコンテンツ加工部５３４は、例えば、再度の閲覧時に適合した状態に加工することができる。すなわち、Ｗｅｂコンテンツ加工部５３４は、現在の発着間紐付けＩＤが埋め込まれた加工済みのＷｅｂコンテンツに加工することができる。この場合には、閲覧履歴を閲覧した情報表示端末２０において、例えばユーザがリンク情報をクリックしてページ遷移を試みた場合には、ページ遷移の同期などが適切に制御される。さらに、Ｗｅｂコンテンツ加工部５３４は、例えば、ページ遷移の同期が不能となるように、Ｗｅｂコンテンツに含まれるリンク情報を無効化する、といった加工を行うこともできる。
【０２９５】
また、もうひとつの手法としては、プロキシサーバ５００が、閲覧履歴としてＷｅｂコンテンツ自体を保存していない場合、例えばＷｅｂコンテンツ要求受付部５３１が、通常のＷｅｂコンテンツの閲覧と同様に再度Ｗｅｂコンテンツの要求を受け付け、その後、Ｗｅｂコンテンツ取得部５３２がＷｅｂコンテンツを再度取得する手法が考えられる。再度取得されたＷｅｂコンテンツについて、Ｗｅｂコンテンツ加工部５３４がどのような加工を行うかについては、上述した通り、様々な手法が考えられる。
【０２９６】
なお、実施例７に係るＷｅｂコンテンツ共有システムは、他の実施例で説明した各種機能を適宜合わせて備えることができるが、例えば、実施例６において説明した『フォーム操作の同期』機能を有する場合、プロキシサーバ５００は、Ｗｅｂコンテンツの他に、仮想共有ブラウザ情報を保存しておいてもよい。この場合、お気に入り閲覧制御部５３８は、再度の閲覧時に、『フォーム』の最終状態を復元することができる。
【０２９７】
上述したように、Ｗｅｂコンテンツの保存手法は、適宜選択することが可能であり、提供するサービスや、閲覧履歴の属性として何が指定されているかなどに応じて、適宜選択されればよいものである。例えば、閲覧履歴の属性として『保証フラグ』が指定されている場合に、プロキシサーバ５００は、加工済みのＷｅｂコンテンツを保存するとともに『フォーム』の最終状態に対応する仮想共有ブラウザ情報を保存することができる。すると、ユーザは、『保証フラグ』が指定された閲覧履歴を再度閲覧する際に、『フォーム』の最終状態を閲覧することができる。
【０２９８】
ここで、お気に入り閲覧制御部５３８は、閲覧要求の要求元に再度閲覧させることが可能な閲覧履歴のリストをどのように取得するかについて説明する。上述したように、お気に入り閲覧制御部５３８は、『履歴フラグ』の属性が指定されたＷｅｂコンテンツについては、閲覧履歴として保存された際と同じユーザ間で通話している場合に、両ユーザによる再度の閲覧が可能となるように制御する。また、お気に入り閲覧制御部５３８は、『ひとりフラグ』の属性が指定されたＷｅｂコンテンツについては、閲覧履歴として保存された際に『ひとりフラグ』の属性を指定した本人、あるいは、属性を指定した本人の通話相手のいずれかであれば、そのユーザによる再度の閲覧が可能となるように制御する。また、お気に入り閲覧制御部５３８は、『保証フラグ』の属性が指定されたＷｅｂコンテンツについては、『保証フラグ』の属性を指定したユーザ（例えばユーザＡ）が、閲覧履歴として保存された際の通話相手（例えばユーザＢ）と異なる通話相手（例えばユーザＣ）と通話している場合に、両ユーザ（ユーザＡ及びユーザＣ）による再度の閲覧が可能となるように制御する。
【０２９９】
そこで、例えば、お気に入り閲覧制御部５３８は、閲覧履歴として保存されたＷｅｂコンテンツの閲覧要求を、発着間紐付けＩＤ及び発着判定フラグとともに情報表示端末２０から受け付けると、発着間紐付けＩＤ及び発着判定フラグを用いてセッション連携サーバ１００に対して問い合わせを行う。すると、セッション連携サーバ１００は、閲覧の要求者とその通話相手とを特定する。
【０３００】
すなわち、セッション連携サーバ１００は、制御用セッション情報管理テーブル１２１や発着間紐付けＩＤ管理テーブル１２２を備えているので、発着間紐付けＩＤ及び発着判定フラグから、閲覧の要求者とその通話相手とを特定することが可能である。次に、セッション連携サーバ１００は、特定した要求者及びその通話相手の情報を用いて制御用セッション情報管理テーブル１２１及び発着間紐付けＩＤ管理テーブル１２２を参照し、両ユーザによって通話が行われた場合の発着間紐付けＩＤ、要求者によって通話が行われた場合の発着間紐付けＩＤの一覧を、特定した閲覧の要求者及びその通話相手の情報や、過去の通話情報などとともに、お気に入り閲覧制御部５３８に返信する。
【０３０１】
すると、お気に入り閲覧制御部５３８は、セッション連携サーバ１００から送信された発着間紐付けＩＤの一覧を用いて、閲覧要求の要求元に再度閲覧させることが可能な閲覧履歴を選択する。例えば、お気に入り閲覧制御部５３８は、両ユーザによって通話が行われた場合の発着間紐付けＩＤを用いて閲覧履歴テーブル５２１を参照し、該発着間紐付けＩＤに対応付けて履歴フラグ『ＯＫ』が記憶されていれば、両ユーザによる再度の閲覧が可能となるように制御するＷｅｂコンテンツであるとしてそのＵＲＬを取得する。
【０３０２】
また、例えば、お気に入り閲覧制御部５３８は、要求者（例えばユーザＡ）によって通話が行われた場合の発着間紐付けＩＤを用いて閲覧履歴テーブル５２１を参照し、該発着間紐付ＩＤに対応付けて保証フラグ『ＯＫ』が記憶されていれば、閲覧履歴として保存された際の通話相手（例えばユーザＢ）と異なる通話相手（例えばユーザＣ）と通話している場合であっても、両ユーザ（ユーザＡ及びユーザＣ）による再度の閲覧が可能となるように制御するＷｅｂコンテンツであるとしてそのＵＲＬを取得する。
【０３０３】
また、例えば、お気に入り閲覧制御部５３８は、セッション連携サーバ１００から送信された通話相手が、予め定められた特定の番号（閲覧履歴の閲覧用の特番）である場合には、要求者によって通話が行われた場合の発着間紐付けＩＤを用いて閲覧履歴テーブル５２１を参照し、該発着間紐付けＩＤに対応付けてひとりフラグ『ＯＫ』が記憶されていれば、そのユーザによる再度の閲覧が可能となるように制御するＷｅｂコンテンツであるとしてそのＵＲＬを取得する。
【０３０４】
このように、お気に入り閲覧制御部５３８は、例えば図５４の（Ａ）に示すＷｅｂページにおいて、ユーザが『お気に入りを取得』のボタンを押下すると、『履歴フラグ』に対応する閲覧履歴のリストや、『保証フラグ』に対応する閲覧履歴のリストを取得し、要求元のユーザが操作する情報表示端末２０に送信する。すると、例えば図５４の（Ｂ）に示すようなＷｅｂページが、情報表示端末２０において表示される。同様に、ユーザの通話相手が特番である場合には、お気に入り閲覧制御部５３８は、『ひとりフラグ』に対応する閲覧履歴のリストを取得し、要求元のユーザが操作する情報表示端末２０に送信する。すると、例えば図５４の（Ｃ）に示すようなＷｅｂページが、情報表示端末２０において表示される。
【０３０５】
なお、実施例７においては、お気に入り閲覧制御部５３８が、セッション連携サーバ１００に問合せを行う手法を想定したが、これに限られるものではない。例えば、プロキシサーバ５００が、セッション連携サーバ１００と同期をとるなどして、制御用セッション情報管理テーブル１２１や発着間紐付けＩＤ管理テーブル１２２に相当する情報を記憶していてもよい。また、例えば、閲覧履歴保存部５３３が閲覧履歴を保存する際に、セッション連携サーバ１００に問合せを行い、例えばｃａｌｌセッション情報とともに閲覧履歴を保存してもよい。
【０３０６】
なお、上述した閲覧履歴の属性は一例に過ぎず、閲覧条件などについて任意に変更することができる。例えば『ひとりフラグ』について、上述では、属性の指定者本人あるいはその通話相手のいずれかであれば再度の閲覧が可能となるように制御する、と説明した。しかしながら本発明はこれに限られるものではない。例えば、プロキシサーバ５００は、『ひとりフラグ』の属性が指定されたＷｅｂコンテンツについては、閲覧履歴として保存された際に『ひとりフラグ』の属性を指定した本人に限定して、その本人であれば再度の閲覧が可能となるように制御してもよい。この場合には、閲覧履歴テーブル５２１は、『ひとりフラグ』として『発』や『着』を記憶すればよい。また、属性の指定や閲覧要求などにおいてもユーザ（発着）の区別が必要となるので、プロキシサーバ５００は、その制御において、発着間紐付けＩＤとともに発着判定フラグを用いるようにすればよい。
【０３０７】
また、例えば、プロキシサーバ５００は、『ひとりフラグ』の属性が指定されたＷｅｂコンテンツについては、本人に限定して再度の閲覧を可能とするのか、あるいは、その際の通話相手に限定して再度の閲覧を可能とするのか、あるいは、双方による再度の閲覧を可能とするのか、を、属性を指定する本人にさらに指定させてもよい。
【０３０８】
また、閲覧履歴の属性は、複数の属性を重複して指定することも可能である。また、初期値の属性を定めておくことで、例えばユーザによって属性の指定がなされなかった場合には、予め定められた初期値の属性を用いて運用することも可能である。
【０３０９】
［実施例７に係るＷｅｂコンテンツ共有システムによる処理手順］
続いて、図５５〜図５７を用いて、実施例７に係るＷｅｂコンテンツ共有システムによる処理手順を説明する。図５５及び図５６は、実施例７に係るＷｅｂコンテンツ共有システムによる処理手順を示すシーケンス図である。図５７は、実施例７に係るお気に入り閲覧制御部５３８による処理手順を示すフローチャートである。
【０３１０】
図５５に示す処理手順は、例えば実施例１において図１６を用いて説明した処理手順とほぼ同様であるが、ステップＳ１１０２として、閲覧履歴を保存する処理が含まれる点が異なる。すなわち、ステップＳ１１０２において、閲覧履歴保存部５３３が、発着間紐付けＩＤに対応付けて、ＷｅｂコンテンツのＵＲＬを閲覧履歴テーブル５２１に格納する。なお、図５５においては、閲覧履歴を保存する処理が、Ｗｅｂコンテンツを加工する処理の前に行われる例を示したが、これに限られるものではない。閲覧履歴を保存する処理は、例えば、Ｗｅｂコンテンツを加工する処理と併行して行われるなど、任意である。
【０３１１】
さて、図５６においては、図５５に示す処理手順が既に行われ、情報表示端末２０それぞれに、加工済みのＷｅｂコンテンツが返信されていることを想定する。加工済みのＷｅｂコンテンツには、お気に入り指定閲覧プログラムが挿入されている。このため、加工済みのＷｅｂコンテンツを受信した情報表示端末２０それぞれは、図５６のステップＳ１２０１に示すように、閲覧履歴の属性の指定（お気に入りフラグ）を、発着間紐付けＩＤ（必要に応じ、発着間紐付けＩＤ及び発着判定フラグ）とともに送信する。一方、お気に入り指定受付部５３７は、ステップＳ１２０２に示すように、受け付けたお気に入りフラグを、閲覧履歴テーブル５２１に記憶されたレコードのうち、発着間紐付けＩＤが一致するレコードに格納する。
【０３１２】
また、お気に入り閲覧制御部５３８は、図５７に示すように、お気に入りの閲覧要求を受け付けたか否かを判定し（ステップＳ１）、受け付けた場合には（ステップＳ１肯定）、発着間紐付けＩＤを用いてセッション連携サーバ１００に問合せを行うなどして、閲覧の要求者及び通話相手を確認する（ステップＳ２）。
【０３１３】
そして、お気に入り閲覧制御部５３８は、閲覧の要求者及び通話相手に基づいて、閲覧履歴テーブル５２１から閲覧履歴のリストを取得し（ステップＳ３）、取得したリストを要求元の情報表示端末２０に送信する（ステップＳ４）。
【０３１４】
その後、お気に入り閲覧制御部５３８は、情報表示端末２０においてＵＲＬが選択され、選択されたＵＲＬを受け付けると（ステップＳ５肯定）、選択されたＷｅｂコンテンツが再度閲覧されるように、Ｗｅｂコンテンツを送信する（ステップＳ６）。
【０３１５】
なお、上述においては、Ｗｅｂコンテンツ共有システムが全ての閲覧履歴を保存した後に、各ユーザが閲覧履歴の属性を指定する手法を説明したが、本発明はこれに限られるものではない。例えば、Ｗｅｂコンテンツ共有システムは、閲覧履歴の保存を指示された場合にのみ、閲覧履歴を保存してもよい。また、各ユーザによる属性の指定も必ずしも必須ではなく、例えば、Ｗｅｂコンテンツ共有システムは、予め定められた属性で保存してもよい。
【０３１６】
［実施例７の効果］
上述したように、実施例７に係るＷｅｂコンテンツ共有システムは、情報表示端末２０それぞれにおいて閲覧されたＷｅｂコンテンツの履歴情報を、ユーザ間で行われた通話と関連付けて記憶する閲覧履歴テーブル５２１をさらに備える。また、実施例７に係るＷｅｂコンテンツ共有システムは、お気に入り閲覧制御部５３８をさらに備える。お気に入り閲覧制御部５３８は、閲覧履歴テーブル５２１によって記憶されたＷｅｂコンテンツの閲覧要求を、発着間紐付けＩＤとともに情報表示端末２０のいずれかより受け付ける。また、お気に入り閲覧制御部５３８は、発着間紐付けＩＤに基づいて、閲覧要求の要求元の情報表示端末２０を利用するユーザが行う通話を特定し、特定した通話と、Ｗｅｂコンテンツの履歴情報に関連付けられた通話とに基づいて、閲覧を制御する。
【０３１７】
このようなことから、実施例７によれば、閲覧履歴として保存されたＷｅｂコンテンツの閲覧を、通話と関連付けて制御することが可能になる。
【実施例８】
【０３１８】
さて、これまでの実施例において、「ページ遷移の同期」や「ページ内での操作の同期」は、いずれもセッション連携サーバ１００によって制御されていた。すなわち、例えば図１６のステップＳ１１５〜Ｓ１１７を参照するとわかるように、プロキシサーバ２００は、加工済みＷｅｂコンテンツを情報表示端末２０に送信した後、ＵＲＬ情報を発着間紐付けＩＤとともにセッション連携サーバ１００に通知した。すると、セッション連携サーバ１００が、発着間紐付けＩＤに基づき通話相手を特定し、特定した通話相手の情報表示端末２０に対して、プロキシサーバ２００から通知されたＵＲＬ情報を通知した。しかしながら、本発明はこれに限られるものではなく、プロキシサーバが、「ページ遷移の同期」や「ページ内での操作の同期」を制御してもよい。
【０３１９】
図５８は、実施例８に係るＷｅｂコンテンツ共有システムによる処理手順を示すシーケンス図である。図５８のステップＳ１２０５に示すように、例えば、各情報表示端末２０は、ポーリングスクリプトにより、例えば０．５秒間隔などで、発着間紐付けＩＤ及び発着判定フラグとともにプロキシサーバ６００にポーリングするとする。
【０３２０】
このようなポーリングスクリプトを、いつ情報表示端末２０に設定するかであるが、例えば、図１３のステップＳ１０９においてリダイレクトされることで、情報表示端末２０がプロキシサーバ２００との間で通信を開始すると、プロキシサーバ６００は、最初の画面として、図１５の（Ａ）に示す画面を情報表示端末２０に送信する。このとき、プロキシサーバ６００は、上記ポーリングスクリプトを併せて送信すればよい。また、その後プロキシサーバ６００が加工済みＷｅｂコンテンツを情報表示端末２０に送信する際にも、加工済みＷｅｂコンテンツに上記ポーリングスクリプトを挿入すればよい。
【０３２１】
図５８において、プロキシサーバ６００は、ステップＳ１２００において受信した発着間紐付ＩＤ及び発着判定フラグと、加工済みＷｅｂコンテンツとを対応付けて管理するものとする。すると、プロキシサーバ６００は、ステップＳ１２０３において加工済みＷｅｂコンテンツを情報表示端末２０に送信した後に、ステップＳ１２００において受信した発着間紐付ＩＤと同一の発着間紐付ＩＤ、及び、ステップＳ１２００において受信した発着判定フラグと異なる発着判定フラグによるポーリングを受け付けると（ステップＳ１２０５）、この情報表示端末２０に対して、加工済みのＷｅｂコンテンツを閲覧するためのＵＲＬを送信する（ステップＳ１２０６）。
【０３２２】
なお、上記手法に限られず、その他、例えば、プロキシサーバが、セッション連携サーバ１００と同様の機能を有することで実現できる。
【０３２３】
［実施例８の効果］
上述したように、実施例８によれば、プロキシサーバが、「ページ遷移の同期」や「ページ内での操作の同期」を制御する。このため、セッション連携サーバとプロキシサーバとの間で負荷を分散することが可能になる。例えばセッション連携サーバが途中でシステムダウンした場合であっても、プロキシサーバによってＷｅｂコンテンツ共有サービスを継続していくことが可能になる。
【実施例９】
【０３２４】
続いて、実施例９に係るＷｅｂコンテンツ共有システムを説明する。実施例９に係るＷｅｂコンテンツ共有システムは、各情報表示端末２０からプロキシサーバ２００に対するポーリングを利用して、通話相手が閲覧するＷｅｂページ上にオンライン表示を行う。すなわち、実施例９においては、各ユーザが閲覧するＷｅｂページ上に、通話相手がＷｅｂコンテンツ共有サービスを起動中であることを示す『オンラインマーク』が表示される。以下、図５９及び図６０を用いて、実施例９に係るＷｅｂコンテンツ共有システムを説明する。
【０３２５】
まず、オンライン表示について説明する。図５９は、オンライン表示を説明するための図である。図５９に示すように、実施例９に係るＷｅｂコンテンツ共有システムにおいて、各情報表示端末２０に表示されるＷｅｂページは、例えば『領域１』及び『領域２』に区分けされている。ここで、『領域１』及び『領域２』は、一般的なＷｅｂページでいうところのフレームに相当する。
【０３２６】
ここで、実施例９に係るＷｅｂコンテンツ共有システムにおいては、例えば『領域１』に『オンラインマーク』が表示される。例えば図５９の（Ａ）に示すように、『領域１』に何も表示されていない場合、通話相手がＷｅｂコンテンツ共有サービスを起動中でないことを示す。すると、図５９の（Ａ）に示すＷｅｂページを閲覧したユーザは、通話相手と通話中にＷｅｂページの『領域１』を確認することで、通話相手がＷｅｂコンテンツ共有サービスを起動していないことを認識することができる。ユーザが、例えば通話によって通話相手にＷｅｂコンテンツ共有サービスの起動を促し、通話相手がＷｅｂコンテンツ共有サービスを起動したとする（例えば、通話相手が、制御ページの『領域２』に表示された複数のサービスの中から『Ｗｅｂでいっしょ』を選択したとする）。すると、例えば図５９の（Ｂ）に示すように、『領域１』に、通話相手がＷｅｂコンテンツ共有サービスを起動中であることを示す『オンラインマーク』が表示される。
【０３２７】
かかる仕組みがどのように実現されるかについて説明する。図１３を用いて説明したように、セッション連携サーバ１００は、制御ページを生成し、情報表示端末２０は、セッション連携サーバ１００から送信された制御ページをＷｅｂブラウザから表示する。この段階において、『領域１』及び『領域２』は、いずれも、セッション連携サーバ１００の制御下にある。
【０３２８】
ここで、ユーザが、制御ページの『領域２』に表示された複数のサービスの中から『Ｗｅｂでいっしょ』を選択したとする。すると、図１３を用いて説明したように、セッション連携サーバ１００からプロキシサーバ２００のＵＲＬが通知され、情報表示端末２０は、リダイレクトされ、プロキシサーバ２００との間で通信を開始する。この段階において、『領域２』には、例えば図１５の（Ａ）に示す画面が表示され、『領域２』は、プロキシサーバ２００の制御下となる。
【０３２９】
さて、プロキシサーバ２００に対するポーリングを行うためのポーリングスクリプトを、いつ情報表示端末２０に設定するかであるが、例えば、図１３のステップＳ１０９においてリダイレクトされることで、情報表示端末２０がプロキシサーバ２００との間で通信を開始すると、プロキシサーバ２００は、最初の画面として、図１５の（Ａ）に示す画面を情報表示端末２０に送信する。このとき、プロキシサーバ２００は、上記ポーリングスクリプトを併せて送信すればよい。すなわち、ユーザが『Ｗｅｂでいっしょ』を選択し、Ｗｅｂコンテンツ共有サービスを起動すると、上記ポーリングスクリプトが情報表示端末２０に設定され、情報表示端末２０からプロキシサーバ２００に対するポーリングが開始される。また、その後プロキシサーバ２００が加工済みＷｅｂコンテンツを情報表示端末２０に送信する際にも、加工済みＷｅｂコンテンツに上記ポーリングスクリプトを挿入すればよい。
【０３３０】
図６０は、オンライン表示の処理手順を示すシーケンス図である。上述したように、ユーザがＷｅｂコンテンツ共有サービスを起動すると、情報表示端末２０は、プロキシサーバ２００に対するポーリングが開始し、その後一定間隔で、プロキシサーバ２００に対するポーリングを行う。例えば図６０のステップＳ１３００に示すように、情報表示端末２０は、例えば０．５秒間隔などで、発着間紐付けＩＤ及び発着判定フラグとともに、プロキシサーバ２００に対するポーリングを行う。
【０３３１】
すると、プロキシサーバ２００は、ポーリングスクリプトによって受信した発着間紐付けＩＤ及び発着判定フラグを、セッション連携サーバ１００に通知する（ステップＳ１３０１）。一方、セッション連携サーバ１００は、プロキシサーバ２００から通知を受けると、発着間紐付けＩＤ及び発着判定フラグを用いて制御用セッション情報管理テーブル１２１及び発着間紐付けＩＤ管理テーブル１２２を参照し、通話相手（例えば図６０において、発側のユーザ）を特定する（ステップＳ１３０２）。そして、セッション連携サーバ１００は、特定した発側のユーザに関する『領域１』を生成する（ステップＳ１３０３）。例えば、発側のユーザのＷｅｂページの『領域１』に、通話相手である着側のユーザがＷｅｂコンテンツ共有サービスを起動中であることを示す情報が表示されるように、『領域１』を生成する。
【０３３２】
そして、セッション連携サーバ１００が、生成した『領域１』を発側のユーザの情報表示端末２０に送信すると（ステップＳ１３０４）、情報表示端末２０は、『領域１』を更新表示する（ステップＳ１３０５）。
【０３３３】
例えば、情報表示端末２０は、ステップＳ１３０５の更新表示を定期的に行うとする。すると、情報表示端末２０は、セッション連携サーバ１００から『領域１』の更新情報を受け取らずに更新表示のタイミングを迎えた場合には、例えば通話相手がＷｅｂコンテンツ共有サービスを起動していないことを示す情報が表示されるように（例えば図５９の（Ａ））、『領域１』を表示する。また、情報表示端末２０は、セッション連携サーバ１００から『領域１』の更新情報を受け取って更新表示のタイミングを迎えた場合には、例えば通話相手がＷｅｂコンテンツ共有サービスを起動中であることを示す情報が表示されるように（例えば図５９の（Ｂ））、『領域１』を表示する。
【０３３４】
あるいは、例えば、情報表示端末２０は、セッション連携サーバ１００から『領域１』の更新情報を受け取ったタイミングで、『領域１』を更新表示してもよい。
【０３３５】
あるいは、例えば、情報表示端末２０とセッション制御サーバ１００との間で、定期的なポーリングを行ってもよい。例えば、図１３のステップＳ１０４においてセッション連携サーバ１００から情報表示端末２０に対して送信される制御ページに、ポーリングスクリプトを挿入する。すると、例えば、情報表示端末２０は、一定間隔で、セッション制御サーバ１００に対するポーリングを行い、セッション連携サーバ１００において『領域１』が新たに生成された場合には、その『領域１』を取得して、『領域１』を更新表示する。
【０３３６】
なお、上記では、プロキシサーバ２００を例に挙げて説明したが、他の実施例にて説明したプロキシサーバ４００、プロキシサーバ５００、プロキシサーバ６００の場合も同様に、『オンライン表示』を実現することができる。
【０３３７】
また、上記では、各情報表示端末２０に表示されるＷｅｂページが、例えば『領域１』及び『領域２』に区分けされ、オンラインマークを『領域１』に表示する例を説明したが、本発明はこれに限られるものではない。例えば、オンラインマークは、『領域２』に表示されてもよい。この場合、『領域２』を制御する主体はプロキシサーバ２００である。このため、ポーリングを検知したプロキシサーバ２００自身がオンラインマークを生成すればよい。すなわち、例えばプロキシサーバ２００は、ポーリングスクリプトによって発着間紐付けＩＤ及び発着判定フラグを受信し、その後、既に受信した発着間紐付けＩＤと同一の発着間紐付けＩＤ、及び、既に受信した発着判定フラグと異なる発着判定フラグによるポーリングを受け付ける。すると、プロキシサーバ２００は、後者のポーリングを行った情報表示端末２０に対して、通話相手のユーザがＷｅｂコンテンツ共有サービスを起動中であることを示す情報が表示されるように『領域２』（あるいはオンラインマーク）を生成し、送信する。また、領域が区分けされていない場合も同様に適用することができる。
【０３３８】
また、上記では、各情報表示端末２０からプロキシサーバ２００に対するポーリングを利用してオンライン表示を行う例を説明したが、本発明はこれに限られるものではない。例えば、各情報表示端末２０からセッション連携サーバ１００に対するポーリングを利用してオンライン表示を行ってもよい。例えば、実施例１、図１３のステップＳ１０４において、セッション連携サーバ１００は、情報表示端末２０に対して制御ページを送信すると説明した。セッション連携サーバ１００は、例えばこの制御ページを送信する際に、情報表示端末２０がセッション連携サーバ１００に対してポーリングを行うためのポーリングスクリプトを挿入すればよい。すると、情報表示端末２０は、その後、発着間紐付けＩＤ及び発着判定フラグとともにセッション連携サーバ１００に対するポーリングを開始するので、セッション連携サーバ１００は、このポーリングを契機として、例えば通話相手が閲覧する制御ページやＷｅｂページにオンラインマークが生成されるように制御すればよい。すなわち、例えばセッション連携サーバ１００は、ポーリングスクリプトによって発着間紐付けＩＤ及び発着判定フラグを受信し、その後、既に受信した発着間紐付けＩＤと同一の発着間紐付けＩＤ、及び、既に受信した発着判定フラグと異なる発着判定フラグによるポーリングを受け付ける。すると、セッション連携サーバ１００は、後者のポーリングを行った情報表示端末２０に対して、通話相手のユーザが、少なくともセッション連携サーバ１００に対するポーリングを開始中であることを示す情報が表示されるように制御ページやＷｅｂページを生成し、送信する。
【実施例１０】
【０３３９】
さて、これまで本発明の実施例１〜９について説明したが、各実施例は、適宜組み合わせることが可能であり、また、本発明は、上記した実施例以外にも種々の異なる形態にて実施されてよいものである。
【０３４０】
［ページ遷移の同期、及び、ページ内での操作の同期  双方を実現］
上記実施例１〜３においては、Ｗｅｂコンテンツ共有システムが、Ｗｅｂコンテンツに係る情報としてＷｅｂコンテンツのＵＲＬ情報を連携することで「ページ遷移の同期」を実現する手法を説明した。一方、上記実施例４においては、Ｗｅｂコンテンツ共有システムが、Ｗｅｂコンテンツに係る情報としてマウスポインタの座標情報を連携することで「ページ内での操作の同期」を実現する手法を説明した。また、上記実施例６においては、Ｗｅｂコンテンツ共有システムが、Ｗｅｂコンテンツに係る情報としてフォーム情報などを連携することで「ページ内での操作の同期」を実現する手法を説明した。ここで、本発明に係るＷｅｂコンテンツ共有システムは、「ページ遷移の同期」及び「ページ内での操作の同期」の双方を同時に実現することができる。
【０３４１】
例えば、Ｗｅｂコンテンツ共有システムのＷｅｂコンテンツ加工部２３３が、取得したＷｅｂコンテンツに対して２種類の加工を施す。具体的には、Ｗｅｂコンテンツ加工部２３３は、他のＷｅｂコンテンツに遷移するためのリンク情報が指定されることによりＷｅｂコンテンツのＵＲＬ情報が情報表示端末２０において変更された場合に、ＷｅｂコンテンツのＵＲＬ情報を発着間紐付けＩＤとともにＷｅｂコンテンツ要求受付部２３１に通知するように、取得したＷｅｂコンテンツを加工する。また、Ｗｅｂコンテンツ加工部２３３は、マウスポインタの座標情報が情報表示端末２０において変更された場合に、座標情報を発着間紐付けＩＤとともに共有データ受付部２３６に通知するように、取得したＷｅｂコンテンツを加工する。
【０３４２】
すると、リンク情報が指定されることによりＷｅｂコンテンツのＵＲＬ情報が通話を行っているユーザの情報表示端末２０いずれか一方より変更された場合には、Ｗｅｂコンテンツ要求受付部２３１が、ＷｅｂコンテンツのＵＲＬ情報及び発着間紐付けＩＤを受け付け、再び、Ｗｅｂコンテンツ取得部２３２がＷｅｂコンテンツを取得し、Ｗｅｂコンテンツ加工部２３３が、２種類の加工を施し、加工済Ｗｅｂコンテンツ返信部２３４が、加工されたＷｅｂコンテンツを、Ｗｅｂコンテンツ要求の送信元の情報表示端末２０に返信する。
【０３４３】
一方、マウスポインタの座標情報が通話を行っているユーザの情報表示端末２０いずれか一方より変更された場合には、共有データ受付部２３６が、座標情報及び発着間紐付けＩＤを受け付け、共有データテーブル２２３に格納する。また、共有データ要求受付部２３７が、マウスポインタの座標情報を要求する操作情報要求を発着間紐付けＩＤとともに情報表示端末２０から受け付け、共有データ返信部２３８が、マウスポインタの座標情報を送信元の情報表示端末２０に返信する。
【０３４４】
［通知モード］
また、上記した実施例においては、通知モードとして、両者モードが指定された場合を説明した。しかしながら、本発明はこれに限られるものではなく、一方モードが指定された場合にも、同様に適用することができる。この場合には、閲覧制御部２３５は、加工済みのＷｅｂコンテンツを閲覧するためのＵＲＬ情報ではなく、Ｗｅｂコンテンツ要求として指定された本来のＵＲＬ情報をセッション連携サーバ１００に送信する。すると、セッション連携サーバ１００のＵＲＬ通知部１３３は、本来のＵＲＬ情報を情報表示端末２０に対して送信する。このため、情報表示端末２０は、プロキシサーバ２００にアクセスしてＷｅｂコンテンツを閲覧するのではなく、本来のＵＲＬ情報にて指定されたＷｅｂサーバにアクセスしてＷｅｂコンテンツを閲覧することになる。
【０３４５】
このような仕組みによれば、一方の情報表示端末２０のページ遷移に他方の情報表示端末２０のページ遷移を追従させるがその反対は追従させないことができる。例えば、学習塾の先生と生徒とが通話を行っている場合には、先生側のページ遷移に生徒側のページ遷移を追従させるが、生徒側のページ遷移に先生側のページ遷移を追従させないといった制御を行うことができる。言い換えると、例えば、生徒側が勝手に授業と関係のないサイトに遷移して閲覧していたとしても、先生側で閲覧するページは遷移せず、先生側でページ遷移をすれば、強制的に生徒側の閲覧ページが先生側のページと一致するように遷移することになる。
【０３４６】
［Ｗｅｂコンテンツの記憶］
上記実施例５においては、プロキシサーバ２００が未加工のＷｅｂコンテンツを記憶し、ページ遷移を同期される側の情報表示端末２０からのＷｅｂコンテンツ要求を受け付けると、未加工のＷｅｂコンテンツを改めて加工して返信する手法や、プロキシサーバ２００が加工済みのＷｅｂコンテンツを記憶し、ページ遷移を同期される側の情報表示端末２０からのＷｅｂコンテンツ要求を受け付けると、加工済みのＷｅｂコンテンツのうち必要な部分を加工し直して返信する手法を説明した。この手法は、Ｗｅｂコンテンツ共有の高速化及び同一性の確保の観点において有効であり、実施例５に限られず、他の実施例にも同様に適用することができる。
【０３４７】
例えば、実施例１においても、プロキシサーバ２００は、未加工のＷｅｂコンテンツ（もしくは加工済みのＷｅｂコンテンツ）、例えば図１６のステップＳ１１１で取得したＷｅｂコンテンツ（もしくはステップＳ１１２で加工した加工済みのＷｅｂコンテンツ）を記憶し、ページ遷移を同期される側の情報表示端末２０からのＷｅｂコンテンツ要求を受け付けると、記憶しているＷｅｂコンテンツを加工（もしくは必要な部分を加工）して返信することができる。
【０３４８】
［システム構成］
また、上記した実施例においては、プロキシサーバとセッション連携サーバとがそれぞれ物理的に異なる装置で実現され、プロキシサーバとセッション連携サーバとの間で相互に行われるデータ送受信は、ネットワーク経由の通信によって行われることを想定していた。しかしながら、本発明はこれに限られるものではなく、プロキシサーバとセッション連携サーバとは、物理的に同一の１つの装置で実現されてもよい。このような場合には、例えば図１６を用いて説明した処理手順の内、ステップＳ１１６の処理（Ｗｅｂコンテンツ要求の送信元と通話を行っているユーザの情報表示端末２０の特定）は、プロキシサーバ２００にて実行することができる。
【０３４９】
［端末側の構成］
また、本発明に係るＷｅｂコンテンツ共有システムにおいては、まず、端末側の構成という点で、端末側にＨＧＷが設置されているか否か、端末が、ＳＩＰフォンと情報表示端末との分離型であるか、ＳＩＰフォン機能と情報表示機能との一体型であるか、といった選択肢がある。その他、発信側の構成と着信側の構成とが同一であるか、異なるか、といった選択肢や、情報表示端末がＨＧＷの配下の端末として接続しているか否かといった選択肢もある。上記実施例は、これらの選択肢の内、一部の組み合わせを示したに過ぎず、本発明はこれらの構成に限られるものではない。すなわち、上記してきた手法や公知の手法を用いることで、その他の構成についても、本発明を同様に実現することができる。
【０３５０】
また、本実施例において説明した各処理のうち、自動的に行われるとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【０３５１】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵ（Central  Processing  Unit）および当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【０３５２】
なお、上記の実施例で説明したＷｅｂコンテンツ共有方法は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのＩＰネットワークを介して配布することができる。また、このプログラムは、ハードディスク、ＦＤ、ＣＤ−ＲＯＭ（Compact  Disk  Read  Only  Memory）、ＭＯ（Magneto-Optical  disk）、ＤＶＤ（Digital  Versatile  Disk）などのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。
【符号の説明】
【０３５３】
２００  プロキシサーバ
２３０  制御部
２３１  Ｗｅｂコンテンツ要求受付部
２３２  Ｗｅｂコンテンツ取得部
２３３  Ｗｅｂコンテンツ加工部
２３４  加工済Ｗｅｂコンテンツ返信部
２３５  閲覧制御部
【図１】
2011238201.tif 000003
【図２】
2011238201.tif 000004
【図３】
2011238201.tif 000005
【図４】
2011238201.tif 000006
【図５】
2011238201.tif 000007
【図６】
2011238201.tif 000008
【図７】
2011238201.tif 000009
【図８】
2011238201.tif 000010
【図９】
2011238201.tif 000011
【図１０】
2011238201.tif 000012
【図１１】
2011238201.tif 000013
【図１２】
2011238201.tif 000014
【図１３】
2011238201.tif 000015
【図１４】
2011238201.tif 000016
【図１５】
2011238201.tif 000017
【図１６】
2011238201.tif 000018
【図１７】
2011238201.tif 000019
【図１８】
2011238201.tif 000020
【図１９】
2011238201.tif 000021
【図２０】
2011238201.tif 000022
【図２１】
2011238201.tif 000023
【図２２】
2011238201.tif 000024
【図２３】
2011238201.tif 000025
【図２４】
2011238201.tif 000026
【図２５】
2011238201.tif 000027
【図２６】
2011238201.tif 000028
【図２７】
2011238201.tif 000029
【図２８】
2011238201.tif 000030
【図２９】
2011238201.tif 000031
【図３０】
2011238201.tif 000032
【図３１−１】
2011238201.tif 000033
【図３１−２】
2011238201.tif 000034
【図３２】
2011238201.tif 000035
【図３３−１】
2011238201.tif 000036
【図３３−２】
2011238201.tif 000037
【図３４】
2011238201.tif 000038
【図３５】
2011238201.tif 000039
【図３６】
2011238201.tif 000040
【図３７】
2011238201.tif 000041
【図３８】
2011238201.tif 000042
【図３９】
2011238201.tif 000043
【図４０】
2011238201.tif 000044
【図４１】
2011238201.tif 000045
【図４２】
2011238201.tif 000046
【図４３−１】
2011238201.tif 000047
【図４３−２】
2011238201.tif 000048
【図４４】
2011238201.tif 000049
【図４５】
2011238201.tif 000050
【図４６】
2011238201.tif 000051
【図４７】
2011238201.tif 000052
【図４８】
2011238201.tif 000053
【図４９】
2011238201.tif 000054
【図５０】
2011238201.tif 000055
【図５１】
2011238201.tif 000056
【図５２】
2011238201.tif 000057
【図５３】
2011238201.tif 000058
【図５４】
2011238201.tif 000059
【図５５】
2011238201.tif 000060
【図５６】
2011238201.tif 000061
【図５７】
2011238201.tif 000062
【図５８】
2011238201.tif 000063
【図５９】
2011238201.tif 000064
【図６０】
2011238201.tif 000065