以下、本願の開示するWebコンテンツ共有システム及びWebコンテンツ共有方法の実施例を詳細に説明する。なお、以下の実施例により本発明が限定されるものではない。
[実施例1に係るWebコンテンツ共有システムの概要]
まず、図1を用いて、実施例1に係るWebコンテンツ共有システムの概要を説明する。図1は、実施例1に係るWebコンテンツ共有システムの概要を説明するための図である。
図1に示すように、実施例1に係るWebコンテンツ共有システムは、セッション連携サーバとプロキシサーバとを備える。また、プロキシサーバは、利用者(以下、ユーザという)の情報表示端末と既存のWebサーバ群との間に介在し、複数のユーザ間におけるWebコンテンツの共有を実現する。
ここで、実施例1に係るWebコンテンツ共有システムは、複数のユーザ間でWebコンテンツに係る情報を連携することで、Webコンテンツを共有する。Webコンテンツに係る情報とは、例えば、Webコンテンツを閲覧するためのURL(Uniform Resource Locator)情報である。すなわち、実施例1に係るWebコンテンツ共有システムは、複数のユーザ間でURL情報を連携することで、一方のユーザにおいて閲覧するWebコンテンツのページが遷移した場合には、他方のユーザにおいても閲覧するWebコンテンツのページが追従するように制御する。この結果、複数のユーザ間におけるWebコンテンツの共有を実現する。
具体的には、まず、Webコンテンツ共有システムにおいて、複数のユーザ間で通話が行われる。例えば、図1に示すように、ユーザ1のSIP(Session Initiation Protocol)フォンとユーザ2のSIPフォンとの間でSIPによって通信が確立され、ユーザ1とユーザ2との間で通話が行われる。
次に、セッション連携サーバが、通話を行っているユーザ間でWebコンテンツに係る情報を連携するための連携情報を情報表示端末それぞれに対して発行する。例えば、図1に示すように、セッション連携サーバは、ユーザ1の情報表示端末及びユーザ2の情報表示端末それぞれに対して発着間紐付けID(識別情報:Identification)を発行する。
ここで、ユーザが、情報表示端末を用いて、既存のWebサーバが発信するWebコンテンツを閲覧しようとしたとする。すると、プロキシサーバは、Webコンテンツを要求するWebコンテンツ要求を連携情報とともに情報表示端末から受け付ける。例えば、図1に示すように、プロキシサーバは、ユーザ1の情報表示端末から、Webコンテンツ要求を発着間紐付けIDとともに受け付ける。
続いて、プロキシサーバは、Webコンテンツ要求にて指定された既存のWebサーバからWebコンテンツを取得し、取得したWebコンテンツを加工する。具体的には、プロキシサーバは、他のWebコンテンツに遷移するための遷移情報が指定されることによりWebコンテンツの所在情報が情報表示端末において変更された場合に、他のWebコンテンツの所在情報を連携情報とともにプロキシサーバに通知するように、取得したWebコンテンツを加工する。例えば、プロキシサーバは、他のWebコンテンツに遷移するためのリンク情報が指定されることによりWebコンテンツのURL情報が情報表示端末において変更された場合に、他のWebコンテンツのURL情報を発着間紐付けIDとともにプロキシサーバに通知するように、取得したWebコンテンツを加工する。
次に、プロキシサーバは、Webコンテンツ要求を送信した送信元の情報表示端末に、加工済みのWebコンテンツを返信する。例えば、図1に示すように、プロキシサーバは、ユーザ1の情報表示端末に、加工済みのWebコンテンツを返信する。
続いて、プロキシサーバ及びセッション連携サーバは、連携情報に基づいて、Webコンテンツ要求の送信元と通話を行っているユーザの情報表示端末を特定し、この情報表示端末においてWebコンテンツ要求に係るWebコンテンツが閲覧されるように制御する。
例えば、図1に示すように、プロキシサーバが、Webコンテンツ要求にて指定されたURL情報を発着間紐付けIDとともにセッション連携サーバに通知する。すると、セッション連携サーバが、発着間紐付けIDに基づきユーザ1と通話を行っているユーザ2の情報表示端末を特定し、ユーザ2の情報表示端末に対して、プロキシサーバから通知されたURL情報を通知する。すると、例えば、図1に示すように、ユーザ2の情報表示端末は、通知されたURL情報を指定するWebコンテンツ要求を発着間紐付けIDとともにプロキシサーバに送信する。すると、ユーザ2の情報表示端末には、ユーザ1が閲覧しているWebコンテンツが表示され、ユーザ1とユーザ2との間で既存のWebコンテンツを共有することができる。
ここで、上記したように、情報表示端末に返信されたWebコンテンツは、他のWebコンテンツに遷移するための遷移情報が指定されることによりWebコンテンツの所在情報が情報表示端末において変更された場合に、他のWebコンテンツの所在情報を連携情報とともにプロキシサーバに通知するように加工されたものである。したがって、プロキシサーバは、Webコンテンツの所在情報が端末において変更された場合に、他のWebコンテンツの所在情報を連携情報とともに情報表示端末から受け付ける。例えば、ユーザ1の情報表示端末においてリンク情報が指定されることによりWebコンテンツのURL情報が情報表示端末において変更された場合に、プロキシサーバは、指定されたリンク先のURL情報を発着間紐付けIDとともに受け付ける。
すると、プロキシサーバは、再び、Webコンテンツの所在情報にて指定されたWebサーバからWebコンテンツを取得し、取得したWebコンテンツを加工する。例えば、プロキシサーバは、再び、他のWebコンテンツに遷移するためのリンク情報が指定されることによりWebコンテンツのURL情報が情報表示端末において変更された場合に、他のWebコンテンツのURL情報を発着間紐付けIDとともにプロキシサーバに通知するように、取得したWebコンテンツを加工する。そして、プロキシサーバは、所在情報を送信した送信元の情報表示端末に、加工済みのWebコンテンツを返信する。
また、プロキシサーバ及びセッション連携サーバが、Webコンテンツの所在情報及び連携情報に基づいて、Webコンテンツの所在情報の送信元の情報表示端末と、送信元と通話を行っている利用者の情報表示端末との間において、Webコンテンツの所在情報が連携されるように制御する。
例えば、プロキシサーバは、URL情報を発着間紐付けIDとともにセッション連携サーバに通知する。すると、セッション連携サーバが、発着間紐付けIDに基づきユーザ1と通話を行っているユーザ2の情報表示端末を特定し、ユーザ2の情報表示端末に対して、プロキシサーバから通知されたURL情報を通知する。すると、ユーザ2の情報表示端末は、通知されたURL情報を指定するWebコンテンツ要求を発着間紐付けIDとともにプロキシサーバに送信する。すると、ユーザ2の情報表示端末には、ユーザ1が閲覧しているWebコンテンツが表示され、ユーザ1とユーザ2との間で既存のWebコンテンツを共有することができる。
このように、実施例1に係るWebコンテンツ共有システムは、既存のWebコンテンツを共有することを可能にし、ユーザの情報表示端末において閲覧するWebコンテンツのページが遷移した場合には、遷移に追従してWebコンテンツを共有することを可能にする。
つまり、実施例1に係るWebコンテンツ共有システムは、既存のWebコンテンツを要求されると、既存のWebコンテンツを取得するとともにこれを加工し、加工済みのWebコンテンツを情報表示端末に返信することで、ページ遷移の同期を可能にする。仮に、Webコンテンツを加工することなく情報表示端末に返信してしまうと、情報表示端末においてその後ページ遷移があったとしても、Webコンテンツ要求はプロキシサーバに送信されることなく直接Webサーバに送信されてしまい、その後のページ遷移の同期は不可能になってしまう。
[実施例1に係るWebコンテンツ共有システムの構成]
次に、図2〜図12を用いて、実施例1に係るWebコンテンツ共有システムの構成を説明する。以下、セッション連携サーバ100、プロキシサーバ200、HGW(Home Gate Way)10、SIPフォン30、情報表示端末20の順に説明する。
[セッション連携サーバ100]
図2〜図4を用いて、セッション連携サーバ100の構成を説明する。図2は、セッション連携サーバの構成を示すブロック図である。セッション連携サーバ100は、以下に説明する各部が汎用的なサーバなどに備えられることによって実現され、図2に示すように、通信部110と、記憶部120と、制御部130とを備える。
通信部110は、HTTP(Hyper Text Transfer Protocol)通信用の一般的なインタフェース及びライブラリを有し、HGW10、情報表示端末20、プロキシサーバ200との間で情報を送受信する。記憶部120は、制御部130における各種制御に用いられる情報を記憶し、図2に示すように、制御用セッション情報管理テーブル121と、発着間紐付けID管理テーブル122とを有する。例えば、記憶部120は、RAM(Random Access Memory)、ROM(Read Only Memory)、フラッシュメモリ(flash memory)などの半導体メモリ素子、または、ハードディスク、光ディスクなどである。
制御用セッション情報管理テーブル121は、制御用セッション情報を管理する。具体的には、制御用セッション情報管理テーブル121は、制御用セッション情報を記憶し、制御用セッション情報管理テーブル121が記憶する制御用セッション情報は、後述する発着間紐付けID発行部122による処理に利用される。
図3は、制御用セッション情報管理テーブルを説明するための図である。例えば、制御用セッション情報管理テーブル121は、図3に示すように、制御用セッション情報と、callセッション情報と、発着判定フラグと、通話履歴情報とを対応付けて記憶する。
ここで、制御用セッション情報は、情報表示端末20とセッション連携サーバ100との間で確立されたセッション毎に生成され、情報表示端末20とセッション連携サーバ100との間で確立されたセッションを一意に識別する情報である。制御用セッション情報は、後述するcallセッション情報収集部131によって発行され、制御用セッション情報管理テーブル121に格納される。例えば、制御用セッション情報は、『セッションID』(CookieのIDなど)で実現される。なお、図3において、説明の便宜上、制御用セッション情報として規則的な数値が例示されているが、一般的には乱数などが格納される。
また、callセッション情報は、SIPフォン30間でSIPによって確立されたセッションを一意に識別する情報である。callセッション情報は、後述するcallセッション情報収集部131によって収集され、制御用セッション情報管理テーブル121に格納される。例えば、callセッション情報は、SIP通信に含まれる情報である『Call−ID』もしくは『isub』、または、『From』、『To』、『tag』、IPアドレス、もしくは、これらを組合せて実現される。また、callセッション情報は、SIP通信に含まれるその他の情報(例えば『Date』など)を組合せて実現される。なお、SIPによって確立されたセッションを一意に識別することが可能な情報を用いる手法であれば、どのような手法で実現してもよい。また、図3において、説明の便宜上、callセッション情報の『Call−ID』として規則的な数値が例示されているが、一般的には乱数などが格納される。
また、発着判定フラグは、SIPフォン30間でSIPによって確立されたセッションについて、SIPフォン30が発側であるのか着側であるのかを示すフラグである。後述するcallセッション情報収集部131によって収集され、制御用セッション情報管理テーブル121に格納される。
通話履歴情報は、callセッション情報によって一意に識別されるセッションの開始時刻と終了時刻とを示す情報である。開始時刻は、例えば、後述するcallセッション情報収集部131が情報表示端末20からサービス開始要求を受け付けた際に、callセッション情報収集部131によって制御用セッション情報管理テーブル121に格納される。また、終了時刻は、例えば、セッション連携サーバ100がセッションの切断を検知した際に、セッション連携サーバ100によって制御用セッション情報管理テーブル121に格納される。
図2に戻り、発着間紐付けID管理テーブル122は、発着間紐付けIDを管理する。具体的には、発着間紐付けID管理テーブル122は、発着間紐付けIDを記憶し、発着間紐付けID管理テーブル122が記憶する発着間紐付けIDは、後述するURL通知部133による処理に利用される。
図4は、発着間紐付けID管理テーブルを説明するための図である。例えば、発着間紐付けID管理テーブル122は、図4に示すように、制御用セッション情報と、発着間紐付けIDとを対応付けて記憶する。
ここで、発着間紐付けIDは、SIPによって確立されたセッションを一意に識別するcallセッション情報の仮名情報であり、通話を行っている利用者間でWebコンテンツに係る情報を連携するための連携情報である。発着間紐付けIDは、後述する発着間紐付けID発行部132によって発行され、発着間紐付けID管理テーブル122に格納される。なお、図4に示すように、一般的には乱数などが格納される。
図2に戻り、制御部130は、callセッション情報収集部131と、発着間紐付けID発行部132と、URL通知部133とを有する。
callセッション情報収集部131は、callセッション情報及び発着判定フラグを収集する。具体的には、callセッション情報収集部131は、SIPフォン30間でSIPによってセッションが確立されると、callセッション情報及び発着判定フラグを収集し、制御用セッション情報管理テーブル121に格納する。
発着間紐付けID発行部132は、発着間紐付けIDを発行する。具体的には、発着間紐付けID発行部132は、制御用セッション情報管理テーブル121に記憶されている複数のcallセッション情報の中から同一のセッションを示すcallセッション情報を特定する。次に、発着間紐付けID発行部132は、特定したcallセッション情報と対応付けて記憶されている2つの制御用セッション情報を特定する。そして、発着間紐付けID発行部132は、発着間紐付けIDを発行し、発行した発着間紐付けIDと特定した制御用セッション情報とを対応付けて発着間紐付けID管理テーブル122に格納する。
URL通知部133は、Webコンテンツに係る情報であってWebコンテンツを閲覧するためのURL情報を通知する。具体的には、URL通知部133は、Webコンテンツを閲覧するためのURL情報、発着間紐付けID、及び発着判定フラグをプロキシサーバ200から受信する。次に、URL通知部133は、プロキシサーバ200から受信した発着間紐付けIDを用いて発着間紐付けID管理テーブル122を参照し、発着間紐付けIDに対応付けて記憶されている制御用セッション情報を特定する。なお、ここで特定される制御用セッション情報は、発着双方の情報表示端末20が用いる2つの制御用セッション情報である。
続いて、URL通知部133は、特定した2つの制御用セッション情報及び発着判定フラグ(例えば「発」側)を用いて制御用セッション情報管理テーブル121を参照し、1つの制御用セッション情報を特定する。そして、URL通知部133は、特定した制御用セッション情報とは異なるもう一方の制御用セッション情報を、URL情報を通知する情報表示端末20が用いる制御用セッション情報として特定する。すなわち、URL通知部133は、例えば「着」側の情報表示端末20が用いる制御用セッション情報を特定する。次に、URL通知部133は、特定した制御用セッション情報を用いる情報表示端末20に対して、プロキシサーバ200から受信したURL情報を送信する。
[プロキシサーバ200]
次に、図5〜図8を用いて、プロキシサーバ200の構成を説明する。図5は、プロキシサーバの構成を示すブロック図である。プロキシサーバ200は、以下に説明する各部が汎用的なサーバなどに備えられることによって実現され、図5に示すように、通信部210と、記憶部220と、制御部230とを備える。
通信部210は、HTTP通信用の一般的なインタフェース及びライブラリを有し、HGW10、情報表示端末20、セッション連携サーバ100との間で情報を送受信する。記憶部220は、制御部230における各種制御に用いられる情報を記憶する。例えば、記憶部220は、RAM、ROM、フラッシュメモリなどの半導体メモリ素子、または、ハードディスク、光ディスクなどである。
制御部230は、図5に示すように、Webコンテンツ要求受付部231と、Webコンテンツ取得部232と、Webコンテンツ加工部233と、加工済Webコンテンツ返信部234と、閲覧制御部235とを備える。
Webコンテンツ要求受付部231は、Webコンテンツ要求を発着間紐付けIDとともに情報表示端末20から受け付ける。具体的には、Webコンテンツ要求受付部231は、Webコンテンツ要求を情報表示端末20から受け付け、受け付けたWebコンテンツ要求から、WebサーバのURL情報、発着間紐付けID及び発着判定フラグを抽出し、Webコンテンツ取得部232に送る。
ここで、Webコンテンツ要求受付部231が受け付けるWebコンテンツ要求には、初回のWebコンテンツ要求として受け付ける場合と、2回目以降のWebコンテンツ要求として受け付ける場合とがある。後述するように、加工済Webコンテンツ返信部234によって情報表示端末20に返信されたWebコンテンツは、他のWebコンテンツに遷移するためのリンク情報が指定されることによりWebコンテンツのURL情報が情報表示端末20において変更された場合に、他のWebコンテンツのURL情報を発着間紐付けIDとともにWebコンテンツ要求受付部231に通知するように加工されたものである。したがって、例えば、情報表示端末20においてリンク情報が指定されると、指定されたリンク先のWebコンテンツのURL情報が発着間紐付けIDとともに再びWebコンテンツ要求受付部231によって受け付けられる。この場合が、Webコンテンツ要求受付部231が、2回目以降のWebコンテンツ要求として受け付ける場合である。
Webコンテンツ取得部232は、Webコンテンツ要求によって指定されたWebサーバからWebコンテンツを取得する。具体的には、Webコンテンツ取得部232は、WebサーバのURL情報、発着間紐付けID及び発着判定フラグをWebコンテンツ要求受付部231から受け付け、受け付けたWebサーバのURLにアクセスしてWebコンテンツを取得する。また、Webコンテンツ取得部232は、取得したWebコンテンツ、発着間紐付けID及び発着判定フラグをWebコンテンツ加工部233に送る。
Webコンテンツ加工部233は、Webコンテンツに他のWebコンテンツに遷移するためのリンク情報が含まれている場合には、Webコンテンツを加工する。具体的には、Webコンテンツ加工部233は、Webコンテンツ、発着間紐付けID及び発着判定フラグをWebコンテンツ取得部232から受け付け、受け付けたWebコンテンツを加工する。また、Webコンテンツ加工部233は、加工済みのWebコンテンツを加工済Webコンテンツ返信部234に送り、加工済みのWebコンテンツを閲覧するためのURL情報、発着間紐付けID及び発着判定フラグを閲覧制御部235に送る。
ここで、Webコンテンツ加工部233は、他のWebコンテンツに遷移するためのリンク情報が指定されることによりWebコンテンツのURL情報が情報表示端末20において変更された場合に、他のWebコンテンツのURL情報を発着間紐付けIDとともにWebコンテンツ要求受付部231に通知するように、Webコンテンツを加工する。図6〜図8は、Webコンテンツ加工処理を説明するための図である。
例えば、Webコンテンツ加工部233は、Webコンテンツ取得部232によって取得されたWebコンテンツのHTML(Hyper Text Markup Language)タグを解析し、図6の(A)に示すように、Webコンテンツの遷移に関するタグである『aタグ href属性』が記述された箇所を特定する。ここで、例えば、図6の(A)の符号aは、Webコンテンツに含まれるリンク情報であり、情報表示端末20において符号aに示すリンク情報が指定されると、情報表示端末20は、『http://www.a-site.ne.jp/mailmagazine/』のWebコンテンツを要求する。
次に、Webコンテンツ加工部233は、例えば、図6の(B)に示すように、特定した箇所を加工する。ここで、例えば、図6の(B)の符号bは、プロキシサーバ200のURL情報である。また、符号cは、Webコンテンツ取得部232から受け付けた発着間紐付けIDである。また、符号dは、Webコンテンツ取得部232から受け付けた発着判定フラグである。また、符号eは、図6の(A)の符号aと同一のリンク情報である。
また、例えば、Webコンテンツ加工部233は、Webコンテンツ取得部232によって取得されたWebコンテンツのHTMLタグを解析し、図7の(A)に示すように、Webコンテンツの遷移に関するタグである『formタグ action属性』が記述された箇所を特定する。ここで、例えば、図7の(A)の符号aは、Webコンテンツに含まれるリンク情報であり、情報表示端末20において符号aに示すリンク情報が指定されると、情報表示端末20は、『http://green.search.a-site.ne.jp/search/』のWebコンテンツを要求する。
次に、Webコンテンツ加工部233は、例えば、図7の(B)に示すように、特定した箇所を加工する。ここで、例えば、図7の(B)の符号bは、プロキシサーバ200のURL情報である。また、符号cは、Webコンテンツ取得部232から受け付けた発着間紐付けIDである。また、符号dは、Webコンテンツ取得部232から受け付けた発着判定フラグである。また、符号eは、図7の(A)の符号aと同一のリンク情報である。
なお、Webコンテンツ加工部233は、画像データなどを示すURI(Uniform Resource Identifier)が相対値で記述されている場合には絶対値で記述し直すなど、細かい調整を行う。例えば、Webコンテンツ加工部233は、図8の(A)に示すように相対値で記述されているURI(符号a)を、図8の(B)に示すようにフルパス(符号b)で記述する。
図5に戻り、加工済Webコンテンツ返信部234は、Webコンテンツ要求を送信した送信元の情報表示端末20に、加工済みのWebコンテンツを返信する。具体的には、加工済Webコンテンツ返信部234は、加工済みのWebコンテンツをWebコンテンツ加工部233から受け付け、受け付けた加工済みのWebコンテンツを送信元の情報表示端末20に返信する。
閲覧制御部235は、Webコンテンツ要求の送信元と通話を行っている利用者の情報表示端末20においてWebコンテンツ要求に係るWebコンテンツが閲覧されるように制御する。具体的には、閲覧制御部235は、加工済みのWebコンテンツを閲覧するためのURL情報、発着間紐付けID及び発着判定フラグをWebコンテンツ加工部233から受け付け、受け付けたURL情報、発着間紐付けID及び発着判定フラグをセッション連携サーバ100に送信する。
[HGW10]
次に、図9及び図10を用いて、HGW10の構成を説明する。図9は、HGWの構成を示すブロック図であり、図10は、ブラウザセッション情報管理テーブルを説明するための図である。図9に示すHGW10は、以下に説明する各部が汎用的なゲートウェイ装置などに備えられることによって実現され、図9に示すように、SIP通信部/HTTP通信部11と、記憶部12と、制御部13とを備える。
SIP通信部/HTTP通信部11は、SIP用及びHTTP通信用の一般的なインタフェースおよびライブラリを備える。SIP通信部/HTTP通信部11は、SIPフォン30とSIPプロキシ(図示を省略)との間の通信、情報表示端末20とプロキシサーバ200との間の通信、HGW10とセッション連携サーバ100との間の通信、HGW10とSIPプロキシ(図示を省略)との間の通信、HGW10とプロキシサーバ200との間の通信などを制御する。制御部13は、HGW10における各種処理を制御する。
記憶部12は、制御部13における各種制御に用いられる情報を記憶し、図9に示すように、ブラウザセッション情報管理テーブル12aを備える。例えば、記憶部12は、RAM、ROM、フラッシュメモリなどの半導体メモリ素子、または、ハードディスク、光ディスクなどである。
ブラウザセッション情報管理テーブル12aは、配下の情報表示端末20に割り当てられたブラウザセッション情報を予め記憶する。例えば、ブラウザセッション情報管理テーブル12aは、図10に示すように、SIPフォン30を一意に識別する『SIPフォンID』と、SIPフォン30と組で利用される情報表示端末20を一意に識別する『情報表示端末ID』と、情報表示端末20を特定するための『ブラウザセッション情報』とを対応づけて予め記憶する。また、ブラウザセッション情報管理テーブル12aは、callセッション情報と、発着判定フラグとを対応付けて記憶している。ブラウザセッション情報管理テーブル12aが記憶するこれらの情報の内、callセッション情報は、例えば、HGW10が収集し、登録したものである。発着判定フラグは、HGW10が、SIPによって確立された通信に含まれる情報から自ら生成した情報である。HGW10は、配下に接続するSIPフォン30を把握しているので、該当する呼が、発信であるのか、着信であるのかを判断することができる。
[SIPフォン30]
次に、図11を用いて、SIPフォン30の構成を説明する。図11は、SIPフォンの構成を示すブロック図である。SIPフォン30は、汎用的なSIPフォンによって実現され、図11に示すように、入力部32と、出力部33と、入出力制御I/F部34と、SIP通信部31とを備える。
いずれも汎用的なSIPフォンと同様であるので簡単に説明すると、入力部32は、SIPフォン30に用いられる情報や、各種処理をするための操作指示などを、番号キーやマイクなどによって入力する。出力部33は、SIPフォン30による各種処理の結果や、各種処理をするための操作指示などを、ディスプレイやスピーカに出力する。入出力制御I/F部34は、入力部32と、出力部33と、SIP通信部31との間における情報転送を制御する。SIP通信部31は、SIP用の一般的なインタフェースおよびライブラリを備え、他方のSIPフォン30との間で(HGW10を介して)情報を送受信する。
[情報表示端末20]
次に、図12を用いて、情報表示端末20の構成を説明する。図12は、情報表示端末の構成を示すブロック図である。情報表示端末20は、以下に説明する各部が汎用的なPCや情報家電などに備えられることによって実現され、図12に示すように、入力部22と、出力部23と、入出力制御I/F部24と、HTTP通信部21と、制御部25とを備える。
入力部22は、情報表示端末20に用いられる情報や、各種処理をするための操作指示などを、キーボード、マウス、リモコンなどによって入力する。出力部23は、情報表示端末20による各種処理の結果や、各種処理をするための操作指示などを、ディスプレイやプリンタなどに出力する。入出力制御I/F部24は、入力部22と、出力部23と、HTTP通信部21と、制御部25との間における情報転送を制御する。HTTP通信部21は、HTTP通信用の一般的なインタフェースおよびライブラリを備え、プロキシサーバ200との間でHGW10を介して情報を送受信する。
制御部25は、図12に示すように、Webコンテンツ閲覧部25aを備える。Webコンテンツ閲覧部25aは、プロキシサーバ200から送信された加工済みのWebコンテンツを閲覧する。また、Webコンテンツ閲覧部25aは、セッション連携サーバ100から送信された加工済みのWebコンテンツを閲覧するためのURL情報にアクセスし、加工済みのWebコンテンツを閲覧する。
[実施例1に係るWebコンテンツ共有システムによる処理手順]
続いて、図13〜図17を用いて、実施例1に係るWebコンテンツ共有システムによる処理手順を説明する。図13及び図16は、実施例1に係るWebコンテンツ共有システムによる処理手順を説明するための図である。図14、図15及び図17は、情報表示端末の出力画面を説明するための図である。
図13に示すように、Webコンテンツ共有システムにおいて、まず、複数のユーザ間で通話が行われる(ステップS101)。例えば、ユーザ1(発側)とユーザ2(着側)との間でSIPフォン30を用いた通話が行われる。すなわち、まず、両SIPフォン30間でSIP通信が行われ、その結果、ステップS101において、両SIPフォン30間でSIPによって通信が確立される。
両SIPフォン30間でSIPによって通信が確立されると、HGW10は、SIPによって確立された通信を一意に識別するcallセッション情報を自ら収集し、また、発着判定フラグを生成する(ステップS102)。例えば、HGW10は、callセッション情報としての『Call−ID』、『From(SIP−URI)』及び『To(SIP−URI)』を、SIPによって確立された通信に含まれる情報から自ら収集する。また、HGW10は、両SIPフォン30が発側であるのか着側であるのかを示す『発着判定フラグ』を、SIPによって確立された通信に含まれる情報から自ら生成する。
なお、ステップS102に続いて、HGW10は、配下のSIPフォン30を一意に識別する情報であるSIPフォンIDを、SIP通信に含まれる情報から収集する。SIPフォンIDとは、例えば、SIPフォン30の内線番号のことである。HGW10の配下に複数のSIPフォン30が接続される構成の場合、SIP−URIはHGW10に対して付与され、HGW10配下のSIPフォン30各々には、内線番号が付与される。
そして、HGW10は、ステップS101においてSIPによって通信を確立したSIPフォン30と組で利用される情報表示端末20を特定する。具体的には、HGW10は、まず、SIPフォンIDをキーとしてブラウザセッション情報管理テーブル12aを検索することで情報表示端末20を特定し、特定した情報表示端末20のブラウザセッション情報と、HGW10に対してポーリングを行う複数の情報表示端末20各々のブラウザセッション情報とを比較し、ブラウザセッション情報の一致によって、SIPによって通信を確立したSIPフォン30と組で利用される情報表示端末20を特定する。
図13に戻り、HGW10は、アクセス先変更指示を、特定した情報表示端末20に対して行う。具体的には、特定した情報表示端末20に対して、セッション連携サーバ100のURLにアクセス先を変更するよう指示するリダイレクト指示を、callセッション情報及び発着判定フラグとともに行う(ステップS103)。なお、実施例1においては、HGW10がセッション連携サーバ100のURL情報を予め記憶部に記憶していることで、セッション連携サーバ100のURLにアクセス先を変更するようリダイレクト指示を行うことができる。この結果、情報表示端末20は、リダイレクト指示を受け、HGW10のURLからセッション連携サーバ100のURLにアクセス先を変更する。
すると、情報表示端末20はリダイレクトされ、接続先をセッション連携サーバ100に変更する(ステップS103)。この時、情報表示端末20は、callセッション情報及び発着判定フラグを、セッション連携サーバ100に送信することになる。
一方、セッション連携サーバ100のcallセッション情報収集部131は、制御用セッション情報を発行し、発行した制御用セッション情報を制御用セッション情報管理テーブル121に格納する(ステップS104)。具体的には、callセッション情報収集部131は、情報表示端末20から送信されたcallセッション情報及び発着判定フラグを受信すると、callセッション情報、発着判定フラグ、及び通話履歴情報としての開始時刻を制御用セッション情報管理テーブル121に格納する。そして、callセッション情報収集部131は、制御用セッション情報を発行し、発行した制御用セッション情報を制御用セッション情報管理テーブル121に格納する。
なお、ステップS104に続いて、callセッション情報収集部131は、制御ページを生成し、情報表示端末20に対して、ステップS104で発行した制御用セッション情報と、生成した制御ページとを送信する。
すると、情報表示端末20は、セッション連携サーバ100から送信された制御ページをWebブラウザから表示する(ステップS105)。例えば、情報表示端末20は、図14の(A)に示す制御ページをWebブラウザから表示する。図14は、情報表示端末の出力画面を説明するための図である。なお、着側の情報表示端末20についても同様の処理が行われ、例えば、着側の情報表示端末20は、図14の(B)に示す制御ページをWebブラウザから表示する。
続いて、図14の(A)に示すように、情報表示端末20のユーザが、Webブラウザに表示された制御ページの中からサービス(『Webでいっしょ』)を選択することで(ステップS106)、情報表示端末20のWebコンテンツ閲覧部25aは、Webコンテンツの共有サービス開始要求をセッション連携サーバ100に対して送信する(ステップS107)。この時、Webコンテンツ閲覧部25aは、ステップS104において送信された制御用セッション情報を用いて、選択したサービス(『Webでいっしょ』)のサービスIDをセッション連携サーバ100に対して送信する。
すると、セッション連携サーバ100の発着間紐付けID発行部132は、情報表示端末20から送信された制御用セッション情報が、制御用セッション情報管理テーブル121に登録されているものであることを確認し、発着間紐付けIDを発行する(ステップS108)。
次に、発着間紐付けID発行部132は、情報表示端末20に対して、プロキシサーバ200のURL情報、発着間紐付けID及び発着判定フラグを送信する(ステップS109)。すると、例えば、情報表示端末20は、図15の(A)に示すページをWebブラウザから表示する。図15は、情報表示端末の出力画面を説明するための図である。なお、着側の情報表示端末20は、図15の(B)に示すように、図14の(B)に示す制御ページをWebブラウザから表示したままである。
続いて、図15の(A)に示すように、情報表示端末20のユーザが、Webブラウザに表示されたページに、Webコンテンツの閲覧を要求するWebサイトのURL情報(『http://www.a-site.ne.jp』)を入力する。すると、情報表示端末20のWebコンテンツ閲覧部25aは、セッション連携サーバ100から送信されたプロキシサーバ200のURLにアクセスし、Webコンテンツ要求を発着間紐付けIDとともにプロキシサーバ200に送信する(ステップS110)。例えば、Webコンテンツ閲覧部25aは、WebサイトのURL情報、セッション連携サーバ100から送信された発着間紐付けID、発着判定フラグ、及び通知モードの指定を、プロキシサーバ200に送信する。
ここで、通知モードの指定とは、情報表示端末20において相互にWebコンテンツを共有させるモード(両者モード)とするか、あるいは、一方の情報表示端末20のページ遷移に他方の情報表示端末20のページ遷移を追従させるがその反対は追従させないモード(一方モード)とするかを指定するものである。両者モードが指定された場合には、他方の情報表示端末20においても加工済みのWebコンテンツが閲覧されるように制御される。一方モードが指定された場合には、他方の情報表示端末20においては直接Webサーバにアクセスして通常のWebコンテンツが閲覧されるように制御される。実施例1においては、両者モードを指定するものとして説明する。なお、通知モードの指定は、発着判定フラグを用いて行ってもよい。
すると、プロキシサーバ200のWebコンテンツ要求受付部231が、Webコンテンツ要求を情報表示端末20から受け付け、Webコンテンツ取得部232が、Webコンテンツ要求によって指定されたWebサーバからWebコンテンツを取得する(ステップS111)。
次に、Webコンテンツ加工部233が、Webコンテンツに他のWebコンテンツに遷移するためのリンク情報が含まれている場合には、Webコンテンツを加工する(ステップS112)。
そして、加工済Webコンテンツ返信部234が、Webコンテンツ要求を送信した送信元の情報表示端末20に、加工済みのWebコンテンツを返信する(ステップS113)。この時、送信元の情報表示端末20のブラウザには、例えば、図17の(A)に示すWebコンテンツが表示される。
また、閲覧制御部235が、ステップS110において受け付けた通知モードを判定する(ステップS114)。ここで、実施例1においては、通知モードとして『両者モード』が指定されているので、閲覧制御部235は、Webコンテンツ要求の送信元と通話を行っている利用者の情報表示端末20におけるWebコンテンツの閲覧も共有の対象となるように制御する。
まず、閲覧制御部235は、加工済みのWebコンテンツを閲覧するためのURL情報、発着間紐付けID及び発着判定フラグをセッション連携サーバ100に送信する(ステップS115)。すると、セッション連携サーバ100のURL通知部133が、プロキシサーバ200から受信した発着間紐付けID及び発着間紐付けIDに基づきWebコンテンツ要求の送信元と通話を行っているユーザの情報表示端末20を特定する(ステップS116)。
そして、URL通知部133は、特定した情報表示端末20に対して、プロキシサーバ200から受信したURL情報を送信する(ステップS117)。こうして、URL情報を受信した情報表示端末20が、受信したURLにアクセスしてWebコンテンツを取得すると、情報表示端末20のブラウザには、例えば、図17の(B)に示すWebコンテンツが表示される。
なお、ステップS117においてURL情報を受信した情報表示端末20によるWebコンテンツ要求が、既に同期された側の情報表示端末20によるWebコンテンツ要求であることを区別するために、Webコンテンツ要求に何らかのパラメータを併せて送信するようにしてもよい。このようにすることで、ページ遷移が無限に繰り返される状態を回避することができる。
ここで、ステップS113において情報表示端末20に返信されたWebコンテンツや、ステップS117においてURL情報を受信した情報表示端末20が取得するWebコンテンツは、WebコンテンツのURL情報が情報表示端末20において変更された場合に、他のWebコンテンツのURL情報を発着間紐付けIDとともにプロキシサーバ200に通知するように加工されたものである。したがって、プロキシサーバ200のWebコンテンツ要求受付部231は、WebコンテンツのURL情報が情報表示端末20において変更された場合に、再び、他のWebコンテンツのURL情報を発着間紐付けIDとともに情報表示端末20から受け付ける。すなわち、ステップS111に処理は戻り、ステップS111〜ステップS117の処理が繰り返されることになる。なお、発着双方の情報表示端末20が対象となる。すなわち、例えば、ステップS117においてURL情報を受信した側の情報表示端末20においてWebコンテンツのURL情報が変更された場合には、今度は、ステップS113においてWebコンテンツを返信された側の情報表示端末20が、追従してページ遷移することになる。
[実施例1の効果]
上記したように、実施例1に係るWebコンテンツ共有システムにおいては、複数のユーザ間で通話が行われると、セッション連携サーバ100の発着間紐付けID発行部132が、ユーザ間でWebコンテンツのURL情報を連携するための発着間紐付けIDをユーザの情報表示端末20それぞれに対して発行する。また、プロキシサーバ200のWebコンテンツ要求受付部231が、所定のWebサーバが発信するWebコンテンツを要求するWebコンテンツ要求を、発着間紐付けID発行部132によって発行された発着間紐付けIDとともに情報表示端末20から受け付ける。また、Webコンテンツ取得部232及びWebコンテンツ加工部233が、所定のWebサーバが発信するWebコンテンツを取得し、他のWebコンテンツに遷移するためのリンク情報が指定されることによりWebコンテンツのURL情報が情報表示端末20において変更された場合に、WebコンテンツのURL情報を発着間紐付けIDとともにWebコンテンツ要求受付部231に通知するように、取得したWebコンテンツを加工する。また、加工済Webコンテンツ返信部234が、Webコンテンツ加工部233よって加工されたWebコンテンツを、Webコンテンツ要求の送信元の情報表示端末20に返信する。
また、プロキシサーバ200の閲覧制御部235及びセッション連携サーバ100のURL通知部133が、Webコンテンツ要求受付部231によって受け付けられた発着間紐付けIDに基づいて、Webコンテンツ要求の送信元と通話を行っているユーザの情報表示端末20を特定し、特定した情報表示端末20においてWebコンテンツ要求に係るWebコンテンツが閲覧されるように制御する。また、Webコンテンツ要求受付部231が、WebコンテンツのURL情報が通話を行っているユーザの情報表示端末20いずれか一方より変更された場合に、URL情報を発着間紐付けIDとともに情報表示端末20から受け付ける。また、プロキシサーバ200の閲覧制御部235及びセッション連携サーバ100のURL通知部133が、Webコンテンツ要求受付部231によって受け付けられたURL情報及び発着間紐付けIDに基づいて、URL情報の送信元の情報表示端末20と、送信元と通話を行っているユーザの情報表示端末20との間において、WebコンテンツのURL情報が連携されるように制御する。
このようなことから、実施例1に係るWebコンテンツ共有システムによれば、既存のWebコンテンツを共有することが可能になり、ユーザの情報表示端末において閲覧するWebコンテンツのページが遷移した場合には、遷移に追従してWebコンテンツを共有することが可能になる。
また、既存のWebコンテンツを共有することが可能になる結果、ユーザが共有することのできるWebコンテンツの数が飛躍的に増加する(現時点にて、Webサイトの数は、約2億4千万ほどである)。
また、図13のステップS109で説明したように、セッション連携サーバ100によってプロキシサーバ200のURL情報が通知されるので、ユーザは、情報表示端末20に対してプロキシサーバ200の設定をする必要がなく、また、ブラウザに新たな機能を追加する必要もない。
また、プロキシサーバ200は、発着間紐付けIDを用いて動作する仕組みであるので、発着間紐付けIDが発行されたユーザからのWebコンテンツ要求のみを受け付けることになる。
さて、実施例1においては、Webコンテンツ要求として受け付けたWebコンテンツ全てを共有の対象とする手法を説明した。この点、実施例2においては、既存のWebコンテンツのURL情報をホワイトリストに予め登録することで、Webコンテンツの共有可否を制御する手法を説明する。
[実施例2におけるプロキシサーバ200の構成]
まず、図18及び図19を用いて、実施例2におけるプロキシサーバ200の構成を説明する。図18は、プロキシサーバの構成を示すブロック図であり、図19は、ホワイトリストテーブルを説明するための図である。
図18に示すように、実施例2におけるプロキシサーバ200は、記憶部220に、特に、ホワイトリストテーブル221を備える。ホワイトリストテーブル221は、WebコンテンツのURL情報をリスト形式で記憶する。また、ホワイトリストテーブル221が記憶するURL情報は、Webコンテンツ取得部232による処理に利用される。なお、ホワイトリストテーブル221に対するURL情報の登録は、Webコンテンツ共有システムの運用者などによって事前に行われる。例えば、ホワイトリストテーブル221は、図19に示すように、URL情報を記憶する。なお、図19に示す『ID』は、リストの通し番号である。
実施例2におけるWebコンテンツ取得部232は、実施例1と同様、Webコンテンツ要求によって指定されたWebサーバからWebコンテンツを取得するが、実施例1と異なり、Webコンテンツ要求に係るWebコンテンツのURL情報がホワイトリストテーブル221に登録されているか否かをまず判定し、登録されている場合にのみ、Webコンテンツを取得する。
[実施例2に係るWebコンテンツ共有システムによる処理手順]
図20を用いて、実施例2に係るWebコンテンツ共有システムによる処理手順を説明する。図20は、実施例2に係るWebコンテンツ共有システムによる処理手順を説明するための図である。もっとも、図20は、実施例2に係るWebコンテンツ共有システムによる処理手順の一部を示すものである。すなわち、実施例2に係るWebコンテンツ共有システムにおいても、実施例1と同様、まず、図13のステップS101からS109までの処理手順が実行される。その後、実施例1のステップS110の代わりに、図20に示すステップS110−1、S110−2が実行され、その後は実施例1と同様に、ステップS111以降の処理手順が実行される。言い換えると、実施例2に係るWebコンテンツ共有システムにおいては、特に、ステップS110−2が実行される。
そこで、図20を用いて、ステップS110−1以降を説明すると、実施例1と同様、プロキシサーバ200のWebコンテンツ要求受付部231は、Webコンテンツ要求を発着間紐付けIDとともに情報表示端末20から受け付ける(ステップS110−1)。
ここで、実施例1においては、Webコンテンツ取得部232は、直ちにWebコンテンツ要求によって指定されたWebサーバからWebコンテンツを取得したが、実施例2においては、Webコンテンツを取得する前に、ステップS110−2の判定を行う。
具体的には、Webコンテンツ取得部232は、Webコンテンツ要求に係るWebコンテンツのURL情報がホワイトリストテーブル221に登録されているか否かをまず判定し(ステップS110−2)、登録されている場合にのみ、Webコンテンツを取得する(ステップS111)。
一方、Webコンテンツ要求に係るWebコンテンツのURL情報がホワイトリストテーブル221に登録されていない場合には、Webコンテンツ取得部232は、Webコンテンツの閲覧が許可されていない旨を通知する制御用ページを、Webコンテンツ要求の送信元の情報表示端末20に返信する。なお、閲覧制御部235は、同じ制御用ページが通話相手の情報表示端末20において閲覧されるように制御してもよい。
また、既存のWebコンテンツのURL情報をホワイトリストに登録する手法を説明してきたが、本発明はこれに限られるものではない。ブラックリストに登録する手法にも同様に適用することができる。この場合には、Webコンテンツ取得部232は、Webコンテンツ要求に係るWebコンテンツのURL情報がブラックリストテーブルに登録されているか否かをまず判定し、登録されていない場合にのみ、Webコンテンツを取得する。
[実施例2の効果]
上記してきたように、実施例2に係るWebコンテンツ共有システムにおいては、プロキシサーバ200が、WebコンテンツのURL情報をリスト形式で記憶するリストテーブルをさらに備える。そして、Webコンテンツ取得部232は、Webコンテンツ要求によって指定されたWebコンテンツのURL情報がリストテーブルに登録されているか否かをさらに判定し、判定結果が、Webコンテンツの閲覧を許可することを示す場合にのみ、所定のWebサーバからWebコンテンツを取得する。
このようなことから、実施例2によれば、既存のWebコンテンツのURL情報をリストに予め登録することで、Webコンテンツの共有可否を制御することが可能になる。例えば、既存のWebサイトの中には、フィッシングサイトなど悪意のあるサイトも存在する。ホワイトリストやブラックリストを予め登録することで、このような悪意のあるサイトが提供するWebコンテンツを閲覧しないように制御することが可能になる。言い換えると、安全なサイトが提供するWebコンテンツのみを閲覧するように制御することが可能になる。
さて、実施例2においては、既存のWebコンテンツのURL情報をリストに予め登録することで、Webコンテンツの共有可否を制御する手法を説明した。実施例3においては、単にURL情報をリストに登録するのみならず、リストの適用ユーザ範囲を指定するデータ(電話番号など)をさらに登録することで、Webコンテンツの共有可否をユーザ単位で制御する手法を説明する。
[実施例3におけるプロキシサーバ200の構成]
まず、図21及び図22を用いて、実施例3におけるプロキシサーバ200の構成を説明する。図21は、プロキシサーバの構成を示すブロック図であり、図22は、ユーザ情報付ホワイトリストテーブルを説明するための図である。
図21に示すように、実施例3におけるプロキシサーバ200は、記憶部220に、特に、ユーザ情報付ホワイトリストテーブル222を備える。ユーザ情報付ホワイトリストテーブル222は、WebコンテンツのURL情報とユーザの識別情報とを対応付けてリスト形式で記憶する。また、ユーザ情報付ホワイトリストテーブル222が記憶する情報は、Webコンテンツ取得部232による処理に利用される。なお、ユーザ情報付ホワイトリストテーブル222に対する情報の登録は、Webコンテンツ共有システムの運用者などによって事前に行われる。
例えば、ユーザ情報付ホワイトリストテーブル222は、図22に示すように、ユーザの電話番号(『userID』)とURL情報とを対応付けて記憶する。なお、図22に示す『ID』は、リストの通し番号である。また、ユーザを識別する情報は電話番号に限られず、他の情報であってもよい。
実施例3におけるWebコンテンツ取得部232は、実施例1と同様、Webコンテンツ要求によって指定されたWebサーバからWebコンテンツを取得するが、実施例1と異なり、Webコンテンツ要求によって指定されたWebコンテンツのURL情報がユーザ情報付ホワイトリストテーブル222に登録されているか否か、及び、Webコンテンツ要求を送信した送信元がURL情報に対応付けてユーザ情報付ホワイトリストテーブル222に登録されているか否かをまず判定する。そして、Webコンテンツ取得部232は、登録されている場合にのみ、Webコンテンツを取得する。
例えば、Webコンテンツ取得部232は、WebコンテンツのURL情報がユーザ情報付ホワイトリストテーブル222に登録されているか否か、及び、Webコンテンツ要求を送信した送信元の電話番号がURL情報に対応付けてユーザ情報付ホワイトリストテーブル222に登録されているか否かをまず判定する。ここで、Webコンテンツ取得部232がユーザの電話番号をどのように割り出すかであるが、例えば、Webコンテンツ要求とともに受け取った発着間紐付けID及び発着判定フラグを用いてセッション連携サーバ100に問い合わせを行い、セッション連携サーバ100から電話番号の回答を受け取ることで割り出してもよい。
なお、ユーザ情報付ホワイトリストテーブル222は、例えば、発着ユーザの電話番号の組合せとURL情報とを対応付けて記憶してもよい。この場合には、Webコンテンツ取得部232は、WebコンテンツのURL情報がユーザ情報付ホワイトリストテーブル222に登録されているか否か、及び、Webコンテンツ要求を送信した送信元の電話番号と通話相手の電話番号とがURL情報に対応付けてユーザ情報付ホワイトリストテーブル222に登録されているか否かを判定する。
また、ユーザ情報付ホワイトリストテーブル222は、例えば、Webコンテンツ要求の送信元の通話相手となるユーザの電話番号とURL情報とを対応付けて記憶してもよい。この場合には、Webコンテンツ取得部232は、WebコンテンツのURL情報がユーザ情報付ホワイトリストテーブル222に登録されているか否か、及び、Webコンテンツ要求を送信した送信元の通話相手の電話番号がURL情報に対応付けてユーザ情報付ホワイトリストテーブル222に登録されているか否かを判定する。
例えば、A社のコールセンタとユーザとの間で通話が行われる場合に、A社のコールセンタとユーザとの間で共有可能なWebコンテンツをA社が提供するWebコンテンツに限定する、といった通話者の関係に基づく制御が可能になる。すなわち、ユーザ情報付ホワイトリストテーブル222が、A社のコールセンタの電話番号と、A社が提供するWebコンテンツを閲覧するためのURL情報とを対応付けて記憶すればよい。
より具体的に例を挙げて説明する。例えば、ユーザ情報付ホワイトリストテーブル222が、2種類のホワイトリストを記憶するものとする。1つのホワイトリストは、A社のコールセンタの電話番号と、A社が提供するWebコンテンツを閲覧するためのURL情報『siteA』とが対応付けられたホワイトリストである。このホワイトリストは、発着ユーザの電話番号にA社のコールセンタの電話番号が含まれている場合には、『siteA』が提供するWebコンテンツの閲覧のみが許可されることを意味するものとする。また、もう1つのホワイトリストは、ユーザBの電話番号と、『siteB』、『siteC』とが対応付けられたホワイトリストである。後者のホワイトリストは、発着ユーザの電話番号にユーザBの電話番号が含まれている場合には、『siteB』、『siteC』が提供するWebコンテンツの閲覧が許可されていることを意味するものとする。また、2つのホワイトリスト間に優先度を設け、前者のホワイトリストが後者のホワイトリストに優先するものとして設定されているとする。
このような構成の下、例えば、A社のコールセンタとユーザBとの間で通話が行われるとする。すると、Webコンテンツ取得部232は、優先度の高い前者のホワイトリストに従って制御を行い、この結果、ユーザBは、A社のコールセンタとの通話中は、『siteA』が提供するWebコンテンツの閲覧しか許可されないことになる。
あるいは、例えば、後者のホワイトリストに、ユーザCの電話番号が登録されていなかったとする。すなわち、ユーザCは、すべてのWebコンテンツの閲覧が許可されていないことを意味するものとする。このような場合であっても、前者のホワイトリストが後者のホワイトリストに優先するものとして設定されていれば、例えば、A社のコールセンタとユーザCとの間で通話が行われた結果、ユーザCは、A社のコールセンタとの通話中は、『siteA』が提供するWebコンテンツの閲覧が許可されることになる。
なお、上述してきた例は一例に過ぎず、ホワイトリストの構成や優先度の設定方法などは任意に変更し得るものである。また、ホワイトリストに優先度を設ける手法を説明したが、例えばユーザの電話番号に優先度を設ける手法などでもよい。例えば、A社のコールセンタの電話番号が、一般のユーザBやユーザCの電話番号よりも優先度が高いものとして設定されているとする。すると、発着ユーザの電話番号に含まれている2つの電話番号を比較し、優先度の高いA社のコールセンタの電話番号に従ってホワイトリストを用いた制御を行う、といった手法が考えられる。
また、実施例3においては、既存のWebコンテンツのURL情報をホワイトリストに登録する手法を説明してきたが、本発明はこれに限られるものではない。ブラックリストに登録する手法にも同様に適用することができる。
[実施例3の効果]
上記してきたように、実施例3に係るWebコンテンツ共有システムにおいては、プロキシサーバ200が、WebコンテンツのURL情報とユーザの識別情報とを対応付けてリスト形式で記憶するユーザ情報付リストテーブルをさらに備える。そして、Webコンテンツ取得部232は、Webコンテンツ要求によって指定されたWebコンテンツのURL情報がユーザ情報付リストテーブルに登録されているか否か、及び、Webコンテンツ要求を送信した送信元がURL情報に対応付けてユーザ情報付リストテーブルに登録されているか否かをさらに判定し、判定結果が、Webコンテンツの閲覧を許可することを示す場合にのみ、所定のWebサーバからWebコンテンツを取得する。
このようなことから、実施例3によれば、単にURL情報をリストに登録するのみならず、リストの適用ユーザ範囲を指定するデータ(電話番号など)をさらに登録することで、Webコンテンツの共有可否をユーザ単位で制御することが可能になる。
さて、これまで実施例1〜3においては、既存のWebコンテンツを共有する形態として「ページ遷移の同期」を例に挙げて説明してきた。しかしながら本発明はこれに限られるものではなく、「ページ内での操作の同期」も実現できる。例えば、一方のユーザの情報表示端末においてマウスが操作されたり文字が入力されたりすると、他方のユーザの情報表示端末において閲覧されるWebコンテンツに、このマウスの移動や入力された文字が表示される形態である。
以下、実施例4として、マウス操作の同期を例に「ページ内での操作の同期」を説明する。実施例4に係るWebコンテンツ共有システムは、複数のユーザ間でWebコンテンツに係る情報を連携することで、Webコンテンツを共有する。Webコンテンツに係る情報とは、例えば、マウスポインタの座標情報である。すなわち、実施例4に係るWebコンテンツ共有システムは、複数のユーザ間でマウスポインタの座標情報を連携することで、ページ内での操作を同期する。
[実施例4におけるプロキシサーバ200の構成]
まず、図23〜図26を用いて、実施例4におけるプロキシサーバ200の構成を説明する。図23は、プロキシサーバの構成を示すブロック図であり、図24は、共有データテーブルを説明するための図であり、図25及び図26は、マウスポインタ共有プログラムを説明するための図である。
図23に示すように、実施例4におけるプロキシサーバ200は、記憶部220に、特に、共有データテーブル223を備える。また、プロキシサーバ200は、制御部230に、特に、共有データ受付部236と、共有データ要求受付部237と、共有データ返信部238とを備える。
共有データテーブル223は、ユーザの情報表示端末20において操作された操作情報を記憶する。具体的には、共有データテーブル223は、共有データ受付部236によって受け付けられた操作情報を発着間紐付けID及び発着判定フラグと対応付けて記憶する。また、共有データテーブル223が記憶する操作情報は、共有データ要求受付部237や共有データ返信部238による処理に利用される。
例えば、共有データテーブル223は、図24に示すように、IDと、マウスポインタの座標情報(『座標X』、『座標Y』)と、発着間紐付けIDと、発着判定フラグと、タイムスタンプ(『timestamp』)とを対応付けて記憶する。なお、実施例4においては、共有データ受付部236によって受け付けられたマウスポインタの座標情報をテーブル形式で記憶する手法を説明したが、これに限られるものではなく、例えば、発着間紐付けID及び発着判定フラグ毎のファイル形式で記憶する手法などでもよい。
共有データ受付部236は、操作情報を発着間紐付けID及び発着判定フラグとともに情報表示端末20から受け付け、共有データテーブル223に格納する。共有データ要求受付部237は、操作情報を要求する操作情報要求を発着間紐付けID及び発着判定フラグとともに情報表示端末20から受け付ける。
共有データ返信部238は、共有データ要求受付部237によって操作情報要求が受け付けられると、操作情報要求とともに受け付けた発着間紐付けID及び発着判定フラグを用いて共有データ受付部236を検索する。そして、共有データ返信部238は、操作情報要求の送信元と通話を行っているユーザの操作情報を、送信元の情報表示端末20に返信する。
また、実施例4におけるWebコンテンツ加工部233は、操作情報が情報表示端末20において変更された場合に、操作情報を発着間紐付けIDとともに共有データ受付部236に通知するように、Webコンテンツを加工する。具体的には、Webコンテンツ加工部233は、Webコンテンツを加工する際に、マウスポインタ共有プログラムを挿入する。ここで、マウスポインタ共有プログラムは、ユーザの情報表示端末20においてマウスポインタの座標情報を取得するとともに、取得したマウスポインタの座標情報が発着間紐付けID及び発着判定フラグとともに共有データ受付部236によって受け付けられるようにするためのプログラムである。また、マウスポインタ共有プログラムは、操作情報要求が発着間紐付けID及び発着判定フラグとともに共有データ要求受付部237によって受け付けられるようにするためのプログラムである。
例えば、マウスポインタ共有プログラムは、JavaScript(登録商標)などのスクリプトによって実現され、図25及び図26に示すように、Webコンテンツ加工部233によってWebコンテンツに挿入される。
例えば、Webコンテンツ加工部233は、Webコンテンツ取得部232によって取得されたWebコンテンツのHTMLタグを解析し、図25の(A)に示すように、headタグの終了(</head>)が記述された箇所を特定する。次に、Webコンテンツ加工部233は、図25の(B)に示すように、特定した箇所に、スクリプトファイルのパスを挿入する。
続いて、例えば、Webコンテンツ加工部233は、Webコンテンツ取得部232によって取得されたWebコンテンツのHTMLタグを解析し、図26の(A)に示すように、bodyタグの終了(</body>)が記述された箇所を特定する。そして、Webコンテンツ加工部233は、図26の(B)に示すように、特定した箇所に、マウスポインタ画像のURI(符号a)と、共有データ要求受付部237に定期的にポーリングするためのポーリングスクリプト(符号b)とを挿入する。なお、上述では、マウスポインタ共有プログラムがJavaScript(登録商標)によって実現される手法を説明したので、headタグの終了(</head>)やbodyタグの終了(</body>)が記述された箇所を特定し、特定した箇所に挿入する手法を説明したが、これに限られるものではない。スクリプトを動作させるための一般的なルールに沿って、然るべき箇所に挿入することが必要である。
[実施例4に係るWebコンテンツ共有システムによる処理手順]
続いて、図27を用いて、実施例4に係るWebコンテンツ共有システムによる処理手順を説明する。図27は、実施例4に係るWebコンテンツ共有システムによる処理手順を説明するための図である。
実施例4においては、例えば、図14の(A)や(B)に示す制御ページにおいて、情報表示端末20のユーザそれぞれが既に『Webでいっしょ』を選択し、さらに、図15の(A)に示す画面と同様の画面にて、情報表示端末20のユーザそれぞれがマウスポインタ共有を有効にする選択を既にしたことを想定している。
すると、情報表示端末20それぞれに加工済みのWebコンテンツが返信され、返信された加工済みのWebコンテンツには、上記したように、マウスポインタ共有プログラムが挿入されている。このため、加工済みのWebコンテンツを受信した情報表示端末20それぞれは、ポーリングスクリプトにより、図27のステップS201に示すように、例えば0.5秒間隔などで、プロキシサーバ200の共有データ要求受付部237にポーリングする。なお、図27において点線で示す矢印は、ポーリングであることを示す。
例えば、発側のユーザの情報表示端末20においてマウスが操作されたとする。すると、情報表示端末20は、スクリプトにより、マウスポインタの座標情報を発着間紐付けID及び発着判定フラグとともに送信し、プロキシサーバ200の共有データ受付部236がこれを受け付け、共有データテーブル223に格納する(ステップS202)。
一方、着側のユーザの情報表示端末20は、図27のステップS203に示すように、プロキシサーバ200の共有データ要求受付部237に、発着間紐付けID及び発着判定フラグとともにポーリングする。すると、共有データ返信部238は、発着間紐付けID及び発着判定フラグを用いて共有データ受付部236を検索し、ポーリング元と通話を行っているユーザのマウスポインタの座標情報が更新されている場合には、これを取得し(ステップS204)、送信元の情報表示端末20に返信する(ステップS205)。なお、座標情報が更新されているか否かは、例えば『timestamp』を用いて5秒以内に更新された情報であるか否かを判定するなどする。
すると、着側のユーザの情報表示端末20において閲覧されるWebコンテンツには、発側のユーザの情報表示端末20において操作されたマウスポインタが表示される(ステップS206)。
[実施例4の効果]
上記してきたように、実施例4に係るWebコンテンツ共有システムにおいては、実施例1と同様、複数のユーザ間で通話が行われると、セッション連携サーバ100の発着間紐付けID発行部132が、ユーザ間でWebコンテンツのURL情報を連携するための発着間紐付けIDをユーザの情報表示端末20それぞれに対して発行する。また、プロキシサーバ200のWebコンテンツ要求受付部231が、所定のWebサーバが発信するWebコンテンツを要求するWebコンテンツ要求を、発着間紐付けID発行部132によって発行された発着間紐付けIDとともに情報表示端末20から受け付ける。また、Webコンテンツ取得部232が、所定のWebサーバが発信するWebコンテンツを取得し、Webコンテンツ加工部233が、マウスポインタの座標情報が座標情報を発着間紐付けIDとともに共有データ受付部236に通知するように、取得したWebコンテンツを加工する。また、加工済Webコンテンツ返信部234が、Webコンテンツ加工部233によって加工されたWebコンテンツを、Webコンテンツ要求の送信元の情報表示端末20に返信する。
また、プロキシサーバ200の閲覧制御部235及びセッション連携サーバ100のURL通知部133が、Webコンテンツ要求受付部231によって受け付けられた発着間紐付けIDに基づいて、Webコンテンツ要求の送信元と通話を行っているユーザの情報表示端末20を特定し、特定した情報表示端末20においてWebコンテンツ要求に係るWebコンテンツが閲覧されるように制御する。
さらに、実施例4に係るWebコンテンツ共有システムにおいては、プロキシサーバ200が、ユーザの情報表示端末20において操作されたマウスポインタの座標情報を発着間紐付けIDと対応付けて記憶する共有データテーブル223をさらに備える。そして、共有データ受付部236が、マウスポインタの座標情報が通話を行っているユーザの情報表示端末20いずれか一方より変更された場合に、マウスポインタの座標情報を発着間紐付けIDとともに情報表示端末20から受け付け、共有データテーブル223に格納する。また、共有データ要求受付部237が、マウスポインタの座標情報を要求する操作情報要求を発着間紐付けIDとともに情報表示端末20から受け付ける。また、共有データ返信部238が、操作情報要求とともに受け付けた発着間紐付けIDを用いて共有データテーブル223を検索し、操作情報要求の送信元と通話を行っている利用者のマウスポインタの座標情報を送信元の情報表示端末20に返信する。
このようなことから、実施例4によれば、「ページ内での操作の同期」を実現することも可能になり、Webコンテンツを共有する時にユーザ間でやりとりする必要のあるデータを共有することが可能になる。
また、ユーザ間で共有するデータを記憶するテーブルはプロキシサーバ200に備えられるので、既存のWebサーバがデータを記憶する必要もない。
また、ユーザにとっては、ユーザビリティが下がらない。すなわち、仮に、マウスポインタのような共有機能がWebコンテンツごとに別々に実装されているとすると、マウスポインタの色や形がWebコンテンツによって異なるため、通話中に共有するWebコンテンツが替わるたびにマウスポインタの色や形が変わり、ユーザビリティの低下が起きると考えられる。これに対し、実施例4によれば、すべてのWebコンテンツに対して共通の方法でマウスポインタの共有機能を実現するので、ユーザビリティが低下するといった問題は起きない。
また、プロキシサーバ200が共有機能を追加するので、共有機能を管理できる。すなわち、仮に、Webサーバ側で共有機能を実現しようとすると、共有機能の安全性を保証することが困難になってしまう。これに対し、実施例4によれば、プロキシサーバ200が一元的に共有機能を追加するので、プロキシサーバ200が共有機能を管理でき、共有機能の安全性を保証することができる。
上記実施例1〜3においては、既存のWebコンテンツを共有する形態として「ページ遷移の同期」を例に挙げて説明したが、実施例5においては、更に、Webサイトと情報表示端末との間で行われるWebセッションの状態管理も実現する。ここで、状態管理とは、例えば、IETF(Internet Engineering Task Force)によって公開されたRFC(Request for Comments)2965で定義されたHTTP cookie(以下「Cookie」)による管理のことである。なお、以下では、状態管理を実現する状態管理情報としてCookieを一例に挙げるが、これに限られるものではない。Webサイトと情報表示端末との間で行われるWebセッションの状態管理を実現するための情報であれば、状態管理情報としてCookie以外の他の情報を用いてもよい。
また、実施例5では、Webセッションの状態管理を実現するにあたり、Webサイトにログインする手法を想定する。具体的には、プロキシサーバ専用のアカウント情報でログインする手法を基本形態及び変形例1で説明し、一方のユーザのアカウント情報でログインする手法を変形例2で説明し、双方のユーザそれぞれのアカウント情報でログインする手法を変形例3で説明する。それぞれの手法に応じて提供され得るサービスは異なるので、以下では、手法ごとのサービスイメージも併せて説明する。
[実施例5におけるプロキシサーバ200の構成]
まず、図28〜30を用いて、実施例5におけるプロキシサーバ200の構成を説明する。図28は、プロキシサーバの構成を示すブロック図であり、図29は、ID−PW(Password)管理テーブルを説明するための図であり、図30は、Cookie管理テーブルを説明するための図である。
図28に示すように、実施例5におけるプロキシサーバ200は、記憶部220に、特に、ID−PW管理テーブル224とCookie管理テーブル225とを備える。なお、実施例5においては、Webサイトにログインする手法を想定するので、プロキシサーバ200がアカウント情報を記憶する(ID−PW管理テーブル224を備える)ことを想定するが、これに限られるものではない。例えばCookieは、Webサイトにログインしない状態であってもWebサイトから発行されることがある。このような場合には、プロキシサーバ200は、必ずしもアカウント情報を記憶する必要はない。
ID−PW管理テーブル224は、Webサイトにログインするためのアカウント情報を記憶する。また、ID−PW管理テーブル224が記憶するアカウント情報は、Webコンテンツ取得部232による処理に利用される。なお、ID−PW管理テーブル224に対するアカウント情報の登録は、Webコンテンツ共有システムの運用者などによって事前に行われる。
例えば、ID−PW管理テーブル224は、図29に示すように、Webサイトの識別情報(『Webサイト』)とURL情報(『URL』)とID及びパスワード(『ID&PW』)とを対応付けて記憶する。例えば、Webサイト『siteA』、URL『siteA_URL』、及びID&PW『siteA_ID&PW』の行は、『siteA_URL』に所在するWebサイトにログインするためのID及びパスワードが『siteA_ID&PW』であることを示す。なお、実施例5においては、WebサイトにログインするためのID及びパスワードは、ユーザごとのID及びパスワードではなく、プロキシサーバ200専用のID及びパスワードである。プロキシサーバ200専用のアカウントをユーザ間で共有する。
Cookie管理テーブル225は、状態管理に関する情報を記憶する。具体的には、Cookie管理テーブル225は、Webコンテンツ取得部232やWebコンテンツ加工部233によって格納されることで、状態管理に関する情報を記憶する。また、Cookie管理テーブル225が記憶する状態管理に関する情報は、Webコンテンツ取得部232や加工済みWebコンテンツ返信部234による処理に利用される。
Cookie管理テーブル225は、図30に示すように、発着間紐付けIDと、発着判定フラグと、プロキシサーバ200によって発行されたCookie(『proxy_Cookie』、以下「プロキシCookie」)と、Webコンテンツと、Webサイトによって発行されたCookie(『サイトCookie』、以下「サイトCookie」)とを対応付けて記憶する。なお、それぞれの情報の格納タイミングなどについては、以下に記載する。
次に、実施例5におけるWebコンテンツ取得部232、Webコンテンツ加工部233、及び加工済みWebコンテンツ返信部234について、上記実施例と特に異なる点を説明する。
実施例5におけるWebコンテンツ取得部232は、WebサーバからWebコンテンツを取得する際に、アカウント情報を用いてWebサイトにログインし、Webコンテンツの他に、サイトCookieも取得する。具体的には、Webコンテンツ取得部232は、WebサーバのURL情報、発着間紐付けID及び発着判定フラグをWebコンテンツ要求受付部231から受け付けると、URL情報を用いてID−PW管理テーブル224を参照する。そして、Webコンテンツ取得部232は、URL情報に対応付けて記憶されたID及びパスワードをID−PW管理テーブル224から取得し、取得したID及びパスワードを用いてWebサイトにログインする。また、Webコンテンツ取得部232は、Webコンテンツ及びサイトCookieをWebサーバから取得し、取得したWebコンテンツ(未加工)及びサイトCookieと、発着間紐付けID及び発着判定フラグとを、Webコンテンツ加工部233に送る。また、Webコンテンツ取得部232は、発着間紐付けID、発着判定フラグ、Webコンテンツ(未加工)、及びサイトCookieをCookie管理テーブル225に格納する。
また、Webコンテンツ取得部232は、既にログイン済みのWebサイトに対するアクセスである場合(2回目以降)には、WebサーバからWebコンテンツを取得する際に、サイトCokkieを用いてWebサーバにアクセスする。具体的には、Webコンテンツ取得部232は、WebサーバのURL情報、発着間紐付けID及び発着判定フラグの他に、後述するWebコンテンツ加工部233によって発行されたプロキシCookieをWebコンテンツ要求受付部231から受け付けると、発着間紐付けIDやプロキシCookieを用いてCookie管理テーブル225を参照する。そして、Webコンテンツ取得部232は、これらの情報に対応付けて記憶されたサイトCookieを取得し、取得したサイトCookieを用いてWebサーバにアクセスする。なお、Webコンテンツ取得部232は、このアクセスにより新たなサイトCookieを取得すると、Cookie管理テーブル225に格納されているサイトCookieを、取得した新たなサイトCookieによって更新する。
また、Webコンテンツ取得部232は、ページ遷移を同期される側の情報表示端末20からのWebコンテンツ要求である場合には、Webサーバに対してアクセスすることなく、Cookie管理テーブル225に格納されたWebコンテンツ(未加工)を加工して要求元の情報表示端末20に送信するように、Webコンテンツ加工部233に通知する。
具体的には、Webコンテンツ取得部232は、WebサーバのURL情報、発着間紐付けID及び発着判定フラグの他に、ページ遷移を同期される側であることを示す同期済みパラメータをWebコンテンツ要求受付部231から受け付けると、発着間紐付けIDを用いてCookie管理テーブル225を参照する。そして、Webコンテンツ取得部232は、発着間紐付けIDに対応付けて記憶されたWebコンテンツ(未加工)及びプロキシCookieを取得する。続いて、Webコンテンツ取得部232は、取得したWebコンテンツ(未加工)及びプロキシCookieをWebコンテンツ加工部233に送る。
実施例5におけるWebコンテンツ加工部233は、Webコンテンツを加工する際に、プロキシCookieを発行する。具体的には、Webコンテンツ加工部233は、Webコンテンツ、サイトCookie、発着間紐付けID及び発着判定フラグをWebコンテンツ取得部232から受け付けると、受け付けたWebコンテンツを加工するとともに、プロキシCookieを発行する。そして、Webコンテンツ加工部233は、発行したプロキシCookieをサイトCookieに対応付けてCookie管理テーブル225に格納する。また、Webコンテンツ加工部233は、加工済みのWebコンテンツ及びプロキシCookieを加工済Webコンテンツ返信部234に送る。
また、Webコンテンツ加工部233は、ページ遷移を同期される側の情報表示端末20からのWebコンテンツ要求に対応して、Webコンテンツ(未加工)及びプロキシCookieをWebコンテンツ取得部232から受け付けると、受け付けたWebコンテンツを加工し、加工済みのWebコンテンツ及びプロキシCookieを加工済Webコンテンツ返信部234に送る。なお、この場合、Webコンテンツ加工部233は、ページ遷移を同期される側の情報表示端末20に相応しい内容に、Webコンテンツを加工する。例えば、Webコンテンツ加工部233は、発着判定フラグのパラメータを、ページ遷移を同期される側の情報表示端末20に対応する値に加工する。
実施例5における加工済Webコンテンツ返信部234は、加工済みのWebコンテンツをWebコンテンツ要求の要求元の情報表示端末20に返信する際に、加工済みのWebコンテンツとともに、Webコンテンツ加工部233によって発行されたプロキシCookieを送信する。
また、加工済Webコンテンツ返信部234は、同期される側の情報表示端末20に加工済みのWebコンテンツを送信する場合も同様に、Webコンテンツ取得部232から送られた加工済みのWebコンテンツ及びプロキシCookieを、該当する情報表示端末20に送信する。
なお、上記実施例においては、プロキシサーバ200が、Cookie管理テーブル225に未加工のWebコンテンツを記憶し、ページ遷移を同期される側の情報表示端末20からのWebコンテンツ要求を受け付けると、未加工のWebコンテンツを改めて加工して返信する手法を説明したが、本発明はこれに限られるものではない。例えば、プロキシサーバ200は、Cookie管理テーブル225に加工済みのWebコンテンツを記憶してもよい。この場合には、プロキシサーバ200は、Cookie管理テーブル225に記憶する加工済みのWebコンテンツのうち必要な部分を、ページ遷移を同期される側の情報表示端末20に対応する内容に加工し直して(置換して)返信すればよい。
[実施例5に係るWebコンテンツ共有システムによる処理手順]
続いて、図31−1〜図33−2を用いて、実施例5に係るWebコンテンツ共有システムによる処理手順を説明する。図31−1及び31−2は、実施例5に係るWebコンテンツ共有システムによる処理手順(初回アクセスから1回目の同期まで)を示すシーケンス図である。図32は、Cookieの設定を説明するための図である。図33−1及び33−2は、実施例5に係るWebコンテンツ共有システムによる処理手順(2回目アクセスから2回目の同期まで)を示すシーケンス図である。
さて、図31−1に示すステップS301は、図16(実施例1)に示したステップS110に対応する。なお、実施例5においては、説明の便宜上、実施例1において説明した通知モードを省略するが、実施例5においても、実施例1と同様、通知モードを利用することができる。
まず、情報表示端末20は、WebサイトのURL情報、セッション連携サーバ100から送信された発着間紐付けID及び発着判定フラグを、プロキシサーバ200に送信する(ステップS301)。例えば、発側の情報表示端末20は、siteAのURL、発着間紐付けID、及び発側であることを示す発着判定フラグをプロキシサーバ200に送信する。なお、図31−1においては、siteAに対するアクセスが初回であることを示すために、『siteAのURL(1)』と記載する。
すると、プロキシサーバ200のWebコンテンツ取得部232は、URL情報を用いてID−PW管理テーブル224を参照し、URL情報に対応付けて記憶されたID及びパスワードをID−PW管理テーブル224から取得する(ステップS302)。例えば、Webコンテンツ取得部232は、『siteA_ID&PW』を取得する。
次に、Webコンテンツ取得部232は、取得したID及びパスワードを用いてWebサーバにログインし、WebサーバからWebコンテンツ及びサイトCookieを取得する(ステップS303)。なお、図31−1においては、siteAから初回に取得したWebコンテンツであることを示すために、『Webコンテンツ(1)』と記載し、siteAから初回に取得したサイトCookieであることを示すために、『siteA_Cookie(1)』と記載する。
続いて、Webコンテンツ加工部233が、プロキシCookieを発行し(ステップS304)、Webコンテンツを加工し(ステップS305)、発行したプロキシCookieをサイトCookieに対応付けてCookie管理テーブルに格納する。
そして、加工済Webコンテンツ返信部234が、Webコンテンツ要求を送信した要求元の情報表示端末20に、加工済みのWebコンテンツ及びプロキシCookieを返信する(ステップS306)。ここで、情報表示端末20は、プロキシサーバ200から送信されたプロキシCookieをWebブラウザに設定する(ステップS307)。例えば、情報表示端末20は、図32の(A)に示すように、プロキシCookieをWebブラウザに設定する。
一方、プロキシサーバ200において、閲覧制御部235が、加工済みのWebコンテンツを閲覧するためのURL情報、発着間紐付けID及び発着判定フラグをセッション連携サーバ100に送信する(ステップS308)。すると、セッション連携サーバ100のURL通知部133が、プロキシサーバ200から受信した発着間紐付けID及び発着間判定フラグに基づきWebコンテンツ要求の送信元と通話を行っているユーザの情報表示端末20を特定する(ステップS309)。
そして、URL通知部133は、特定した情報表示端末20に対して、プロキシサーバ200から受信したURL情報を送信する(ステップS310)。
すると、図31−2に示すように、URL情報を受信した情報表示端末20が、セッション連携サーバ100から送信されたURL情報、発着間紐付けID、発着判定フラグ、及び同期済みパラメータを、プロキシサーバ200に送信する(ステップS311)。
プロキシサーバ200のWebコンテンツ取得部232は、ページ遷移を同期される側の情報表示端末20からのWebコンテンツ要求である場合であるので、発着間紐付けIDを用いてCookie管理テーブル225を参照する(ステップS312)。そして、Webコンテンツ取得部232は、発着間紐付けIDに対応付けて記憶されたWebコンテンツ(未加工)及びプロキシCookieを取得し、取得したWebコンテンツ(未加工)及びプロキシCookieをWebコンテンツ加工部233に送る。
そして、Webコンテンツ加工部233は、Webコンテンツ取得部232から送られたWebコンテンツ(未加工)を加工し、加工済Webコンテンツ返信部234が、加工済みのWebコンテンツ及びプロキシCookieを情報表示端末20に送信する(ステップS313)。なお、図31−2においては、siteAから初回に取得したWebコンテンツを加工した加工済みWebコンテンツであることを示すために、『加工済Webコンテンツ(1)』と記載する。すると、情報表示端末20は、プロキシサーバ200から送信されたプロキシCookieをWebブラウザに設定する(ステップS314)。
次に、情報表示端末20が、同じWebサイトに対する2回目アクセスを行うとする。なお、ここでいう2回目アクセスとは、Webサイトと情報表示端末20との間で行われるWebセッションがCookieによって状態管理された状況下でのアクセスである。
まず、情報表示端末20は、WebサイトのURL情報、セッション連携サーバ100から送信された発着間紐付けID及び発着判定フラグとともに、プロキシCookieを、プロキシサーバ200に送信する(ステップS315)。なお、図33−1においては、siteAに対するアクセスが2回目であることを示すために、『siteAのURL(2)』と記載する。
すると、プロキシサーバ200のWebコンテンツ取得部232は、既にログイン済みのWebサイトに対するアクセスである場合であるので、発着間紐付けIDやプロキシCookieを用いてCookie管理テーブル225を参照する(ステップS316)。
そして、Webコンテンツ取得部232は、これらの情報に対応付けて記憶されたサイトCookieを取得し、取得したサイトCookieを用いてWebサーバにアクセスする(ステップS317)。なお、Webコンテンツ取得部232は、このアクセスにより新たなサイトCookie(例えばsiteA_Cookie(2))を取得すると、Cookie管理テーブル225に格納されたサイトCookie(例えばsiteA_Cookie(1))を、取得した新たなサイトCookie(例えばsiteA_Cookie(2))によって更新する。
続いて、Webコンテンツ取得部232は、ステップS317において取得した新たなサイトCookieを解析し、Webサイトと情報表示端末20との間で行われるWebセッションがCookieによって状態管理された状況下で継続していることを確認する(ステップS318)。例えば、Webコンテンツ取得部232は、サイトCookieに含まれる有効期限(例えばexpires)が超過しているか否かを確認する。
また、Webコンテンツ取得部232は、通話が継続しているか否かを確認する(ステップS319)。例えば、Webコンテンツ取得部232は、発着間紐付けIDを用いてセッション連携サーバ100に対して問い合わせを行い、該当する通話が継続しているか否かを確認する。なお、セッション連携サーバ100は、例えば、制御用セッション情報管理テーブル121を参照し、発着間紐付けIDに対応付けて記憶されている通話履歴情報を用いて、通話が継続しているか否かを判断し、判断結果をWebコンテンツ取得部232に通知する。
Webコンテンツ取得部232は、WebセッションがCookieによって状態管理された状況下で継続していることを確認し、該当する通話が継続していることを確認すると、新たに取得したWebコンテンツ、新たに取得したサイトCookie、発着間紐付けID及び発着判定フラグを、Webコンテンツ加工部233に送る。
続いて、Webコンテンツ加工部233は、発行済みのプロキシCookieが既にCookie管理テーブル225に記憶されている場合であるので、プロキシCookieを発行することなくWebコンテンツを加工する(ステップS320)。なお、再びプロキシCookieを発行し、新たに発行したプロキシCookieを格納する手法であってもよい。
そして、加工済Webコンテンツ返信部234が、Webコンテンツ要求を送信した要求元の情報表示端末20に、加工済みのWebコンテンツ及びプロキシCookieを返信する(ステップS321)。
一方、閲覧制御部235が、加工済みのWebコンテンツを閲覧するためのURL情報、発着間紐付けID及び発着判定フラグをセッション連携サーバ100に送信する(ステップS322)。すると、セッション連携サーバ100のURL通知部133が、プロキシサーバ200から受信した発着間紐付けID及び発着判定フラグに基づきWebコンテンツ要求の送信元と通話を行っているユーザの情報表示端末20を特定する(ステップS323)。
そして、URL通知部133は、特定した情報表示端末20に対して、プロキシサーバ200から受信したURL情報を送信する(ステップS324)。
すると、URL情報を受信した情報表示端末20が、セッション連携サーバ100から送信されたURL情報、発着間紐付けID、発着判定フラグ、プロキシCookie、及び同期済みパラメータをプロキシサーバ200に送信する(ステップS325)。
プロキシサーバ200のWebコンテンツ取得部232は、ページ遷移を同期される側の情報表示端末20からのWebコンテンツ要求である場合であるので、発着間紐付けIDを用いてCookie管理テーブル225を参照する(ステップS326)。そして、Webコンテンツ取得部232は、発着間紐付けIDに対応付けて記憶されたWebコンテンツ(未加工)及びプロキシCookieを取得し、取得したWebコンテンツ(未加工)及びプロキシCookieをWebコンテンツ加工部233に送る。
そして、Webコンテンツ加工部233は、Webコンテンツ取得部232から送られたWebコンテンツ(未加工)を加工し、加工済Webコンテンツ返信部234が、加工済みのWebコンテンツ及びプロキシCookieを要求元の情報表示端末20に送信する(ステップS327)。なお、図33−2においては、siteAから2回目に取得したWebコンテンツを加工した加工済みWebコンテンツであることを示すために、『加工済Webコンテンツ(2)』と記載する。
なお、図示を省略したが、この後、通話が終了し、プロキシサーバ200が、通話が終了した旨を例えばセッション連携サーバ100から通知されると、プロキシサーバ200は、ログインしていたWebサイトからログアウトするように、Webサーバに対してログアウト処理を行ってもよい。また、プロキシサーバ200は、情報表示端末20が保持するプロキシCookieの無効化を情報表示端末20に対して通知してもよい。例えば、プロキシサーバ200は、プロキシCookieの有効期限(例えばexpires)を過去の日に設定して情報表示端末20に対して送信することで、プロキシCookieの無効化を情報表示端末20に対して通知する。情報表示端末20側では、例えばWebブラウザが、プロキシCookieの有効期限に基づきプロキシCookieを無効と判定し、プロキシCookieを削除する。
[変形例1]
さて、これまで実施例5に係るWebコンテンツ共有システムによる処理手順を説明してきたが、上記処理手順(以下、説明の便宜上「基本シーケンス」という)は一例に過ぎず、上記した処理手順以外にも種々の異なる形態にて実施されてよいものである。そこで、図34を用いて変形例1を説明する。図34は、変形例1の処理手順を説明するための図である。
図34に示すように、変形例1の処理手順は、ステップS401〜ステップS405は、図31−1に示した基本シーケンスのステップS301〜ステップ305と同様であり、ステップS406以降が特に異なる。
具体的には、基本シーケンスにおいて、加工済Webコンテンツ返信部234は、プロキシCookieを要求元の情報表示端末20に返信したが、変形例1では、サイトCookieとプロキシCookieとを合体したCookie(以下「合体Cookie」)を返信する(ステップS406)。また、加工済Webコンテンツ返信部234は、連携機能を実現するプログラムも併せて返信する。
すると、情報表示端末20は、プロキシサーバ200から送信された連携機能をインストールし、連携機能により合体Cookieを復号する(ステップS407)。すなわち、連携機能を実現するプログラムは、合体Cookieを解析し、サイトCookieとプロキシCookieとに分解する。また、プログラムは、サイトCookieの有効期限とプロキシCookieの有効期限とを一致させる。サイトCookieの有効期限とプロキシCookieの有効期限とを一致させる目的は、プロキシCookieの有効期限がサイトCookieの有効期限よりも短いと、通話終了後にもサイトCookieを利用できてしまうことになるからである。
その後、情報表示端末20は、プロキシCookieのみならず、サイトCookieもWebブラウザに設定する(ステップS408)。例えば、図32の(A)及び(B)に示すようにWebブラウザに設定する。なお、以降の処理は、基本シーケンスと同様、プロキシサーバ200と情報表示端末20との間の通信はプロキシCookieのみを用いて行ってもよい。この場合は、例えば、情報表示端末20に保持されたサイトCookieは、情報表示端末20が直接Webサイトにアクセスする場合に活用される。一方、基本シーケンスとは異なり、プロキシサーバ200と情報表示端末20との間の通信は合体Cookieを用いて行ってもよい。この場合は、プロキシサーバ200がサイトCookieの情報を記憶、管理する必要がない。
[基本形態及び変形例1のサービスイメージ]
図35を用いて、上記基本形態及び変形例1のサービスイメージを説明する。図35は、サービスイメージを説明するための図である。実施例5に係るWebコンテンツ共有システムやその変形例1では、例えば、図35に示すような会員制WebサイトのWebコンテンツを共有するシステムを実現することができる。プロキシサーバ200が、プロキシサーバ200専用のアカウント情報を用いて会員制Webサイトに代理でログインするので、ユーザは、個別に会員制Webサイトに契約する必要がない。すなわち、ユーザは、会員制Webサイトに契約することなく、通話中でさえあれば当該Webサイトを会員として閲覧することが可能になる。また、会員制Webサイトを運営する事業者は、既存のWebサイトを作り替える必要がなく、プロキシサーバ200用のアカウントを発行するだけでよい。
[変形例2]
続いて、図36〜40を用いて、変形例2を説明する。図36は、ID−PW管理テーブルを説明するための図である。図37〜39は、変形例2の処理手順を説明するための図である。
変形例2では、プロキシサーバ200専用のID及びパスワードを用いてWebサイトにログインするのではなく、一方のユーザにID及びパスワードを入力させ、そのID及びパスワードを用いてWebサイトにログインする。このため、例えば、図36に示すように、変形例2のID−PW管理テーブル224は、Webサイトにログインするためのアカウント情報を、発着間紐付けIDと、ユーザによって入力されたID及びパスワードとを対応付けて記憶することで管理する。
例えば、図37に示すように、情報表示端末20は、WebサイトのURL情報、セッション連携サーバ100から送信された発着間紐付けID及び発着判定フラグを、プロキシサーバ200に送信する際に、例えば、ID及びパスワードの入力フォームを要求するフラグをともに送信する(ステップS501)。なお、入力フォームの要求フラグは必須ではなく、要求フラグの有無にかかわらずプロキシサーバ200が入力フォームを送信する手順としてもよい。あるいは、情報表示端末20からの要求に応じて(情報表示端末20にインストールされた連携機能の要求に応じて)、入力フォームを送信する手順としてもよい。あるいは、プロキシサーバ200が、特定のURLの場合には入力フォームを送信することを判断して、入力フォームを送信する手順としてもよい。
すると、プロキシサーバ200は、入力フォームを情報表示端末20に送信し(ステップS502)、情報表示端末20が、入力フォームにID及びパスワードを入力して、プロキシサーバ200に返信する(ステップS503)。ところで、ステップS502においてプロキシサーバ200が情報表示端末20に送信する入力フォームには、IDを通話相手と共有するか否かを指定する「ID共有フラグ」の送信が可能な仕組みが備えられている。図37に示すように、例えば、情報表示端末20は、自己のID及びパスワードでログインすることになるので、このログインに用いたIDを通話相手と共有するか否かを指定するID共有フラグを併せて送信する。図37の例では、通話相手と共有することを指定する。
ここで、ID共有フラグについて説明する。ステップS503においてログインをした側の情報表示端末20は、ログイン状態でないと閲覧できないページ内でページ遷移をする度に、ID共有フラグを送信することができる。このため、例えばページ遷移毎に、当該IDを通話相手と共有するか否かを指定することができることになるので、情報表示端末20のユーザは、通話相手に許可する操作権を判断し、制御することが可能になる。ここにいう「IDを共有するか否か」は、「ページの共有を行うか否か」とは異なる意味である。「IDを共有するか否か」は、「通話相手に当該IDに基づく操作権を許可するか否か」を意味し、例えば「ページの共有は行うが、IDは共有しない」という状態も想定される。
例えば、プロキシサーバ200は、ログインを行った情報表示端末20からID共有フラグ(共有を指定)を受け取った場合には、通話相手となる情報表示端末20(ログインを行っていない側の情報表示端末20)が、Webコンテンツ上で当該IDに基づく操作を行った場合に、当該操作を有効なものとして受け付け、ログイン状態で行われた操作としてWebサーバ300に転送する。一方、例えば、プロキシサーバ200は、ログインを行った情報表示端末20からID共有フラグ(非共有を指定)を受け取った場合には、通話相手となる情報表示端末20(ログインを行っていない側の情報表示端末20)が、Webコンテンツ上で当該IDに基づく操作を行った場合に、当該操作を有効なものとして受け付けず、無効化する。例えば、プロキシサーバ200は、当該操作に対して、プロキシサーバ200が予め記憶するエラー画面などを情報表示端末20に対して送信する。あるいは、例えば、プロキシサーバ200は、ログイン状態ではなく、ログインされていない状態で行われた操作としてWebサーバ300に転送し、そのような操作に対する応答としてWebサーバ300から返信されたエラー画面などを、情報表示端末20に対して送信する。
図37に戻り、プロキシサーバ200は、情報表示端末20から送信されたID及びパスワードをID−PW管理テーブル224に格納し(ステップS504)、その後は基本シーケンスと同様に、Webコンテンツを取得するなど(ステップS505)、以降の処理を行う。
ところで、変形例2では、図38に示すように、ページ遷移の同期を一時的に非共有とすることを指定する非共有指定や、図39に示すように、非共有の指定を解除し、共有を復活する再共有指定も実行することができる。なお、これらの機能は必須のものではなく、サービスの形態などに応じて任意に適用すればよい。また、変形例2のみならず、例えば基本形態や変形例1、後述する変形例3など、他の形態にも適用することができる。
まず、図38に示すように、例えば、情報表示端末20は、通話相手と共有しないで閲覧したいWebサイトのURL情報(『非共有URL』)、発着間紐付けID、発着判定フラグ、及び共有を停止することを示す共有停止フラグを、プロキシサーバ200に送信する(ステップS601)。
図31−1を用いて説明したように、プロキシサーバ200は、このURL情報に従ってWebコンテンツの取得や加工などを基本シーケンスと同様に行うが、セッション連携サーバ100にURL情報を送信する際に、非共有URLそのものを送信するのではなく、非共有時に通話相手にアクセスさせるべき非共有時用のURL情報を送信する(ステップS602)。
その後、基本シーケンスと同様にステップS603〜ステップS605の処理が行われることになるが、プロキシサーバ200は、通話相手の情報表示端末20から非共有時用のURLにアクセスされると、発着間紐付けIDを用いてCookie管理テーブル225を参照し、通話相手の情報表示端末20が用いているプロキシCookie(もしくは合体Cookie)を特定する(ステップS606)。そして、プロキシサーバ200は、特定したプロキシCookie(もしくは合体Cookie)の無効化を情報表示端末20に対して通知する命令を生成し、情報表示端末20に送信する(ステップS607)。例えば、プロキシサーバ200は、プロキシCookie(もしくは合体Cookie)の有効期限(例えばexpires)を過去の日に設定して情報表示端末20に対して送信することで、プロキシCookieの無効化を情報表示端末20に対して通知する。情報表示端末20側では、例えばWebブラウザが、プロキシCookieの有効期限に基づきプロキシCookieを無効と判定し、プロキシCookieを削除する。
さて、図39に示すように、再共有したい場合には、情報表示端末20は、例えば、通話相手と共有して閲覧したいWebサイトのURL情報(『再共有URL』)、発着間紐付けID、発着判定フラグ、及び共有を復活することを示す共有復活フラグをプロキシサーバ200に送信する(ステップS701)。
図31−1を用いて説明したように、プロキシサーバ200は、このURL情報に従ってWebコンテンツの取得や加工などを基本シーケンスと同様に行うが、セッション連携サーバ100にURL情報を送信する際に、再共有URLそのものを送信するのではなく、再共有時に通話相手にアクセスさせるべき再共有時用URL情報を送信する(ステップS702)。
その後、基本シーケンスと同様にステップS703〜ステップS705の処理が行われることになるが、プロキシサーバ200は、通話相手の情報表示端末20から再共有時用のURLにアクセスされると、発着間紐付けIDを用いてCookie管理テーブル225を参照し、共有・非共有を制御している側の情報表示端末20が用いているプロキシCookie(もしくは合体Cookie)を特定する(ステップS706)。そして、プロキシサーバ200は、特定したプロキシCookie(もしくは合体Cookie)を有効なものとする命令を生成し、情報表示端末20に送信する(ステップS707)。情報表示端末20側に、例えばプロキシサーバ200からの指示に応じてCookieを有効化する連携機能を実現するプログラムが予めインストールされていればよい。なお、有効化とは、例えば、有効なプロキシCookie(もしくは合体Cookie)を新たに送信する処理や、Cookieに含まれる有効期限をプロキシサーバ200が保持する有効なCookieの日付に一致させる、といった処理などである。
[変形例2のサービスイメージ]
図40を用いて、上記変形例2のサービスイメージを説明する。図40は、サービスイメージを説明するための図である。変形例2では、例えば、図40に示すようなサービスを実現することができる。例えば、祖父と孫とが電話で話をしているとする。例えば、プロキシサーバ200は、祖父にID及びパスワードを入力させ、祖父のアカウントでEC(Electronic Commerce)サイトに代理でログインする。すると、通話相手である孫の情報表示端末は、ECサイトの閲覧を共有し、商品を選択することができるように制御される。もっとも、あくまでログインは祖父のアカウントであるので、商品の購入は祖父が行っていることになる。
例えば、ECサイトの商品閲覧ページにおいて、「買い物かごへ入れる」(購入対象として選択する)のアイコンを押下する操作は、IDに基づかずに実行可能な操作であるとする。一方、例えば、ECサイトの決済ページにおいて、「決済」(決済を行う)のアイコンを押下する操作は、IDに基づかなければ実行できない操作であるとする。例えば、祖父が、「決済の操作は孫には実行させたくない」と考えれば、祖父の情報表示端末20は、商品閲覧ページのURLをプロキシサーバ200に送信する際には、ID共有フラグ(共有を指定)を送信し、決済ページのURLをプロキシサーバ200に送信する際には、ID共有フラグ(非共有を指定)を送信すればよい。
すると、例えば孫が、商品閲覧ページにおいて「買い物かごへ入れる」のアイコンを押下した場合には、孫の情報表示端末20からプロキシサーバ200に送信されたこの操作情報は、プロキシサーバ200によって有効なものとして受け付けられ、プロキシサーバ200からECサイトに転送される。一方、例えば孫が、決済ページにおいて「決済」のアイコンを押下した場合には、孫の情報表示端末20からプロキシサーバ200に送信されたこの操作情報は、プロキシサーバ200によって無効なものとして受け付けられ、例えばプロキシサーバ200は、エラー画面を孫の情報表示端末20に対して送信する。このように、祖父は、通話相手(孫)に許可する操作権を判断し、制御することが可能になる。
次に、非共有フラグや再共有フラグのサービスイメージを説明する。例えば、祖父が、「決済ページは孫と共有したくない」と考えれば、祖父の情報表示端末20は、決済ページのURLをプロキシサーバ200に送信する際に非共有フラグを併せて送信すればよい。また、祖父が、「買い物完了ページから再び孫と共有したい」と考えれば、祖父の情報表示端末20は、再共有フラグをプロキシサーバ200に送信すればよい。
[変形例3]
続いて、図41〜44を用いて、変形例3を説明する。図41は、ID−PW管理テーブルを説明するための図であり、図42は、Cookie管理テーブルを説明するための図である。図43−1及び43−2は、変形例3の処理手順を説明するための図である。
変形例3では、一方のユーザのID及びパスワードを用いてWebサイトにログインするのではなく、ユーザそれぞれにID及びパスワードを入力させ、それぞれのID及びパスワードを用いてWebサイトにそれぞれログインさせる。すなわち、ユーザごとにログインした状態となるが、Webページの遷移は同期する状態である。
このため、例えば、図41に示すように、変形例3のID−PW管理テーブル224は、Webサイトにログインするためのアカウント情報を、発着間紐付けIDと、発着判定フラグと、ユーザによって入力されたID及びパスワードとを対応付けて記憶することで管理する。また、変形例3では、ユーザごとにログインし、サイトCookieがユーザごとに払い出されることになるので、Cookie管理テーブル225は、図42に示すように、ユーザごとにサイトCookieを管理する。なお、Webページの遷移は同期するものの、Webページの内容自体はユーザごとにカスタマイズされたものとなるので、図42に示すように、Cookie管理テーブル225は、ユーザごとに加工済みのWebコンテンツを管理する。
例えば、図43−1に示すように、プロキシサーバ200は、ステップS803において一方の情報表示端末20、例えば発側の情報表示端末20からID及びパスワードの入力を受け付ける。なお、変形例3においてはIDを共有しない指定が前提となる。
そして、プロキシサーバ200は、ステップS805において示すように、Webコンテンツを取得する際には、発側の情報表示端末20から入力されたID及びパスワードを用いる。
続いて、基本シーケンスと同様の処理が行われた後、図43−2に示すように、ステップS813において、他方の情報表示端末20、例えば着側の情報表示端末20からプロキシサーバ200に対するアクセスが行われるが、プロキシサーバ200は、着側の情報表示端末20に対しては、強制的に入力フォームを送信する(ステップS814)。すなわち、ステップS803においてIDを共有しないことが指定された場合であるので、プロキシサーバ200は、他方の情報表示端末20に対してはID及びパスワードの入力を強制的に求めるのである。
こうして、他方の情報表示端末20は、自らのID及びパスワードを送信するので(ステップS815)、プロキシサーバ200は、ステップS815において送信されたID及びパスワードを用いて新たにWebサーバにログインし、Webコンテンツを取得することになる(ステップS817)。
このような場合、同期させる側によって閲覧されたWebページのURL(例えば、siteAのURL(1))によって、同期される側のWebページのURL(siteAのURL(1))が決定するので、閲覧するWebページはユーザ間で共有される。
ところが、同期させる側と同期される側とは、それぞれ自己のID及びパスワードでWebサイトにログインしている。このため、プロキシサーバ200が、同期させる側の情報表示端末20用に取得するWebコンテンツ及びサイトCookieと、同期される側の情報表示端末20用に取得するWebコンテンツ及びサイトCookieとは異なる。例えば、図43−1のステップS805において取得したWebコンテンツ及びサイトCookieと、図43−2のステップS817において取得したWebコンテンツ及びサイトCookieとは異なるものである。また、図42に示したように、それぞれの情報表示端末20に返信される加工済みWebコンテンツも異なるものになる。
[変形例3のサービスイメージ]
図44を用いて、上記変形例3のサービスイメージを説明する。図44は、サービスイメージを説明するための図である。変形例3では、例えば、図44に示すようなサービスを実現することができる。例えば、SNS(Social Networking Service)サイトのように、自身のアカウントでログインすることが必要とされるサイトについては、ユーザは、それぞれのアカウントでログインしなければならない。もっとも、変形例3によれば、ログインは個々のアカウントでなされるが、Webページの遷移は同期されるので、ユーザは、自身のアカウントをいつも使っている感覚で、かつWebコンテンツを共有することが可能になる。アカウントごとにカスタマイズされたページを閲覧することになるので、双方で見た目は異なるが、ページ遷移は追従するイメージである。
[実施例5の効果]
上記してきたように、実施例5に係るWebコンテンツ共有システムにおいては、プロキシサーバ200は、Webコンテンツを取得する際に、該Webコンテンツに関して行われるWebセッションの状態を管理するための状態管理情報(例えばサイトCookie)も併せて取得する。また、プロキシサーバ200は、加工済みのWebコンテンツとともに、状態管理情報を識別する状態管理識別情報(例えばプロキシCookie、もしくは合体Cookieなど)も併せてWebコンテンツ要求の送信元の情報表示端末20に返信する。また、プロキシサーバ200は、送信元と通話を行っているユーザの情報表示端末20にも、状態管理識別情報を送信する。そして、プロキシサーバ200は、例えば遷移先のURL情報を発着間紐付けIDとともに情報表示端末20から受け付ける際に、状態管理識別情報も併せて受け付け、状態管理識別情報によりWebサーバから取得した状態管理情報を識別する。そして、プロキシサーバ200は、該Webコンテンツに関して行われるWebセッションの状態が該Webサーバによって管理されるように、識別した状態管理情報を用いて制御する。
このようなことから、実施例5によれば、ユーザ間でページ遷移を同期することができるのみならず、Webセッションの状態管理も実現することができる。
また、プロキシサーバ200は、状態管理情報を用いて制御する際に、通話が継続中であるか否かをさらに判定し、該通話が継続中であると判定した場合にのみ、該状態管理情報を用いて制御する。このようなことから、実施例5によれば、通話中にのみサービスを提供することが可能になる。すなわち、通話中でなければWebセッションを継続することができず、セキュリティを向上することが可能になる。
また、プロキシサーバ200は、Webコンテンツに係る情報の連携を停止することを指示する停止指示を、通話を行っているユーザの情報表示端末20いずれか一方より受け付けると、通話相手のユーザの情報表示端末20に対して、該情報表示端末20が保持する状態管理識別情報を無効にすることを指示する無効指示を送信する。
また、プロキシサーバ200は、停止指示を解除し、Webコンテンツに係る情報の連携を復活することを指示する復活指示を、停止指示を送信した情報表示端末20から受け付けると、通話相手のユーザの情報表示端末20に対して、復活指示を送信した情報表示端末20とWebサーバとの間で有効な状態管理情報を識別する状態管理識別情報を送信する。
このようなことから、実施例5によれば、アカウントの一時共有や復活が可能になり、アカウント共有の利便性を高めることが可能になる。
さて、これまで実施例1〜3においては、既存のWebコンテンツを共有する形態として「ページ遷移の同期」を例に挙げて説明した。また、実施例4においては、既存のWebコンテンツを共有する形態として「ページ内での操作の同期」を例に挙げ、特に『マウス操作の同期』を説明した。しかしながら、本発明はこれに限られるものではない。実施例6においては、「ページ内での操作の同期」の一例として『フォーム操作の同期』を説明する。
[フォーム操作の同期]
まず、図45及び図46を用いて、『フォーム操作の同期』の概要を説明する。図45及び図46は、実施例6の概要を説明するための図である。実施例6に係るWebコンテンツ共有システムにおいて、プロキシサーバは、Webコンテンツ(Webページ)を構成する情報のうちユーザによって変更され得る情報を、一元的に管理する。また、各ユーザは、プロキシサーバによって一元的に管理されたこの情報を、更新あるいは参照する。すると、各ユーザが閲覧するWebコンテンツには、プロキシサーバによって一元的に管理されたこの情報が反映され、複数のユーザ間で『フォーム操作の同期』が実現される。なお、かかる『フォーム操作の同期』は、いわば、共有関係にあるユーザ間で、仮想的に1つのブラウザを閲覧あるいは操作するイメージである。このため、以下では、プロキシサーバが一元的に管理する情報のことを『仮想共有ブラウザ情報』などと称する。
図45に示すように、実施例6におけるプロキシサーバは、WebコンテンツのHTMLタグを解析し、Webコンテンツを構成する情報のうちユーザによって変更され得る情報(以下、仮想共有ブラウザ情報)を、仮想共有ブラウザテーブルに格納する。仮想共有ブラウザ情報は、図45に示すように、例えば、ページ共通情報とページ固有情報とに分類することができる。
ページ共通情報は、マウスポインタ座標やウィンドウサイズなど、閲覧されるページが遷移しても継続して保持される情報である。一方、ページ固有情報は、閲覧されるページが遷移すると、更新あるいは破棄される情報である。ページ固有情報は、さらに、1ページに1つ含まれる情報と、1ページに任意の数含まれる情報とに分類することができる。前者の一例としては、例えば、URLやスクロール量などがある。また、後者の一例としては、例えば、HTMLのformタグによって作成されたテキストエリアやチェックボックスなどがある。なお、図45に示す点線の矢印は、Webコンテンツの構成要素と仮想共有ブラウザ情報との対応関係を概念的に示すものである。
図46に示すように、例えばユーザ1とユーザ2とが共有関係にある場合を想定する。ユーザ1が、自己が閲覧するWebブラウザ上で、Webコンテンツのフォームにテキストやチェックを入力すると、プロキシサーバは、仮想共有ブラウザテーブルに記憶された仮想共有ブラウザ情報を更新する。例えば、ユーザ1が、Webコンテンツのテキストエリア「テキスト2」に『テスト』と入力し、チェックボックスにチェックを入力する。すると、ユーザ1の情報表示端末は、これらの仮想共有ブラウザ情報をプロキシサーバに送信する。プロキシサーバは、仮想共有ブラウザテーブルに記憶された仮想共有ブラウザ情報のうち、「テキスト2」に対応する「テキストエリア2」のvalueに『テスト』を格納する。また、プロキシサーバは、仮想共有ブラウザテーブルに記憶された仮想共有ブラウザ情報のうち、「チェックボックス」のvalueに『on』を格納する。
一方、ユーザ2の情報表示端末は、プロキシサーバの仮想共有ブラウザテーブルを参照し、更新された仮想共有ブラウザ情報があれば、その仮想共有ブラウザ情報を、自身が閲覧するWebブラウザ上のWebコンテンツに反映する。例えば、ユーザ2の情報表示端末は、プロキシサーバに対してポーリングを行うなどして仮想共有ブラウザテーブルを参照し、更新された仮想共有ブラウザ情報として、「テキストエリア2」のvalue『テスト』と、「チェックボックス」のvalue『on』とを取得する。そして、ユーザ2の情報表示端末は、Webコンテンツのフォームのうち、「テキストエリア2」に対応する「テキスト2」に『テスト』を表示し、「チェックボックス」にチェックを表示する。
なお、図46においては、ユーザ1がフォームに対する入力を行い、ユーザ2が、ユーザ1によって更新されたWebコンテンツを閲覧する例を説明したが、本発明はこれに限られるものではない。例えば、ユーザ2がフォームに対する入力を行い、ユーザ1が、ユーザ2によって更新されたWebコンテンツを閲覧する場合や、双方のユーザが入力を行い、双方のユーザが更新されたWebコンテンツを閲覧する場合などにも、同様に適用することができる。
[実施例6におけるプロキシサーバ400の構成]
次に、図47及び図48を用いて、実施例6におけるプロキシサーバ400の構成を説明する。図47は、実施例6におけるプロキシサーバ400の構成を示すブロック図であり、図48は、仮想共有ブラウザテーブル421を説明するための図である。
図47に示すように、実施例6におけるプロキシサーバ400は、記憶部420に、仮想共有ブラウザテーブル421を備える。また、実施例6におけるプロキシサーバ400は、制御部430に、Webコンテンツ要求受付部431、Webコンテンツ取得部432、仮想共有ブラウザ生成部433、Webコンテンツ加工部434、加工済Webコンテンツ返信部435、閲覧制御部436、仮想共有ブラウザ情報受付部437、仮想共有ブラウザ情報要求受付部438、仮想共有ブラウザ情報返信部439を備える。
仮想共有ブラウザテーブル421は、情報表示端末20において操作された操作情報として、仮想共有ブラウザ情報を記憶する。具体的には、仮想共有ブラウザテーブル421は、仮想共有ブラウザ生成部433によって発着間紐付けID毎に生成される。また、仮想共有ブラウザテーブル421は、仮想共有ブラウザ情報受付部437によって受け付けられた仮想共有ブラウザ情報を、発着間紐付けID毎に記憶する。また、仮想共有ブラウザテーブル421が記憶する仮想共有ブラウザ情報は、仮想共有ブラウザ情報要求受付部438や仮想共有ブラウザ情報返信部439による処理に利用される。
例えば、仮想共有ブラウザテーブル421は、図48に示すように、発着間紐付けIDに対応付けて、ページ共通情報及びページ固有情報を記憶する。例えば、仮想共有ブラウザテーブル421は、ページ共通情報として、ユーザ毎に、マウスポインタ座標を記憶する。また、例えば、仮想共有ブラウザテーブル421は、ページ共通情報として、ウィンドウサイズ(横幅及び縦幅)を記憶する。
また、例えば、仮想共有ブラウザテーブル421は、ページ固有情報として、URLを記憶する。図48において、通番とは、仮想共有ブラウザテーブル421が生成された後、ユーザによって閲覧されたWebコンテンツに付与された通し番号である。また、図48において、名前とは、URL情報である。また、例えば、仮想共有ブラウザテーブル421は、ページ固有情報として、スクロール量(水平及び垂直)を記憶する。また、例えば、仮想共有ブラウザテーブル421は、ページ固有情報として、HTMLのformタグによって作成されたフォーム情報を記憶する。図48において、フォーム情報には、テキストエリアやチェックボックスが含まれる。なお、フォーム情報は、図48に示すものに限られず、例えばラジオボタンやセレクトボックスなど、ユーザによって変更され得る情報であれば他の情報であってもよい。フォーム情報は、図48に示すように、例えばname属性やvalue属性を有し、例えばname属性によって識別される。
なお、実施例6においては、仮想共有ブラウザ情報をテーブル形式で記憶する手法を説明したが、これに限られるものではなく、例えば、発着間紐付けID毎のファイル形式で記憶する手法などでもよい。
図47に戻り、制御部430のWebコンテンツ要求受付部431は、これまでの実施例で説明したWebコンテンツ要求受付部231と同様の機能を有する。また、Webコンテンツ取得部432は、これまでの実施例で説明したWebコンテンツ取得部232と同様の機能を有する。また、加工済Webコンテンツ返信部435は、これまでの実施例で説明した加工済Webコンテンツ返信部234と同様の機能を有する。また、閲覧制御部436は、これまでの実施例で説明した閲覧制御部235と同様の機能を有する。
以下では、仮想共有ブラウザ生成部433、Webコンテンツ加工部434、仮想共有ブラウザ情報受付部437、仮想共有ブラウザ情報要求受付部438、仮想共有ブラウザ情報返信部439を、順に説明する。
仮想共有ブラウザ生成部433は、仮想共有ブラウザテーブル421を生成する。具体的には、仮想共有ブラウザ生成部433は、Webコンテンツ取得部432から、Webコンテンツ及び発着間紐付けIDを受け取る。次に、仮想共有ブラウザ生成部433は、Webコンテンツ取得部432から受け取ったWebコンテンツのHTMLタグを解析し、Webコンテンツから仮想共有ブラウザ情報を抽出する。また、仮想共有ブラウザ生成部433は、抽出した仮想共有ブラウザ情報を、Webコンテンツ取得部432から受け取った発着間紐付けIDと対応付け、仮想共有ブラウザテーブル421を生成する。仮想共有ブラウザ生成部433は、例えば図48に示したような仮想共有ブラウザテーブル421を生成する。
Webコンテンツ加工部434は、Webコンテンツを加工する。具体的には、Webコンテンツ加工部434は、Webコンテンツ取得部432から、Webコンテンツ、発着間紐付けID及び発着判定フラグを受け取る。また、Webコンテンツ加工部434は、Webコンテンツ取得部432から受け取ったWebコンテンツを加工し、加工済みのWebコンテンツを加工済Webコンテンツ返信部435に送り、加工済みのWebコンテンツを閲覧するためのURL情報、発着間紐付けID及び発着判定フラグを閲覧制御部436に送る。
ここで、Webコンテンツ加工部434は、これまでの実施例で説明したWebコンテンツ加工部233と同様の機能を有する他、以下のような機能を有する。すなわち、Webコンテンツ加工部434は、仮想共有ブラウザ情報が情報表示端末20において変更された場合に、仮想共有ブラウザ情報を発着間紐付けIDとともに仮想共有ブラウザ情報受付部437に通知するように、Webコンテンツを加工する。
具体的には、Webコンテンツ加工部434は、Webコンテンツを加工する際に、仮想共有ブラウザプログラムを挿入する。ここで、仮想共有ブラウザプログラムは、情報表示端末20において、仮想共有ブラウザ情報を取得するとともに、取得した仮想共有ブラウザ情報が発着間紐付けIDとともに仮想共有ブラウザ情報受付部437によって受け付けられるようにするためのプログラムである。なお、マウスポインタ座標などのように、ユーザ(発着)の区別が必要な仮想共有ブラウザ情報については、仮想共有ブラウザプログラムは、取得した仮想共有ブラウザ情報が、発着間紐付けID及び発着判定フラグとともに仮想共有ブラウザ情報受付部437によって受け付けられるようにする。また、情報表示端末20における仮想共有ブラウザ情報の取得は、例えば文字が入力される毎に取得して仮想共有ブラウザ情報受付部437に送信する手法でもよい。あるいは、例えば確定ボタンが押下されることにより一連の文字の入力が確定した後に取得して、仮想共有ブラウザ情報受付部437に送信する手法でもよい。
また、仮想共有ブラウザプログラムは、仮想共有ブラウザ情報要求が、発着間紐付けID及び発着判定フラグとともに仮想共有ブラウザ情報要求受付部438によって受け付けられるようにするためのプログラムである。
例えば、仮想共有ブラウザプログラムは、JavaScript(登録商標)などのスクリプトによって実現され、Webコンテンツ加工部434によってWebコンテンツに挿入される。なお、スクリプトの挿入は、実施例4において説明したマウスポインタ共有プログラムと同様に行われる。
仮想共有ブラウザ情報受付部437は、仮想共有ブラウザ情報を情報表示端末20から受け付ける。具体的には、仮想共有ブラウザ情報受付部437は、仮想共有ブラウザ情報を、発着間紐付けID(必要に応じ、発着間紐付けID及び発着判定フラグ)とともに情報表示端末20から受け付ける。そして、仮想共有ブラウザ情報受付部437は、受け付けた仮想共有ブラウザ情報を、発着間紐付けIDが一致する仮想共有ブラウザテーブル421に格納する。
仮想共有ブラウザ情報要求受付部438は、仮想共有ブラウザ情報を要求する仮想共有ブラウザ情報要求を、情報表示端末20から受け付ける。具体的には、仮想共有ブラウザ情報要求受付部438は、仮想共有ブラウザ情報要求を、発着間紐付けID及び発着判定フラグとともに情報表示端末20から受け付ける。
仮想共有ブラウザ情報返信部439は、仮想共有ブラウザ情報要求に応答して、仮想共有ブラウザ情報を情報表示端末20に返信する。具体的には、仮想共有ブラウザ情報返信部439は、仮想共有ブラウザ情報要求受付部438によって仮想共有ブラウザ情報要求が受け付けられると、仮想共有ブラウザ情報要求とともに受け付けた発着間紐付けIDを用いて仮想共有ブラウザテーブル421を検索する。そして、仮想共有ブラウザ情報返信部439は、例えば、仮想共有ブラウザテーブル421に記憶された仮想共有ブラウザ情報から、前回の要求後に更新された仮想共有ブラウザ情報を抽出し、抽出した仮想共有ブラウザ情報を、仮想共有ブラウザ情報要求の送信元の情報表示端末20に返信する。
なお、更新された仮想共有ブラウザ情報の抽出は、例えば、各仮想共有ブラウザ情報にタイムスタンプを付すことによって実現することができる。例えば、仮想共有ブラウザ情報受付部437が仮想共有ブラウザテーブル421に仮想共有ブラウザ情報を格納する際に、タイムスタンプを付すこととする。一方、仮想共有ブラウザ情報要求を送信する情報表示端末20は、前回の要求がいつ行われたかを示す時刻情報を、仮想共有ブラウザ情報要求とともに送信することとする。すると、仮想共有ブラウザ情報返信部439は、情報表示端末20から送信された時刻情報と、各仮想共有ブラウザ情報に付されたタイムスタンプとを比較し、時刻情報が示す時刻以降のタイムスタンプが付された仮想共有ブラウザ情報を抽出する。
また、更新された仮想共有ブラウザ情報の抽出は、例えば、各仮想共有ブラウザ情報に発着判定フラグを付すことによっても実現することができる。例えば、仮想共有ブラウザ情報受付部437が仮想共有ブラウザテーブル421に仮想共有ブラウザ情報を格納する際に、発着判定フラグを付すこととする。すると、仮想共有ブラウザ情報返信部439は、情報表示端末20から送信された発着判定フラグを用いて、通話相手側の情報表示端末20によって更新された仮想共有ブラウザ情報を抽出する。この場合、仮想共有ブラウザ情報返信部439は、タイムスタンプと発着判定フラグとを併せて用いてもよい。
[実施例6に係るWebコンテンツ共有システムによる処理手順]
続いて、図49及び図50を用いて、実施例6に係るWebコンテンツ共有システムによる処理手順を説明する。図49及び図50は、実施例6に係るWebコンテンツ共有システムによる処理手順を示すシーケンス図である。
図49に示す処理手順は、例えば実施例1において図16を用いて説明した処理手順とほぼ同様であるが、ステップS912として、仮想共有ブラウザを生成する処理が含まれる点が異なる。すなわち、ステップS912において、仮想共有ブラウザ生成部433が、WebコンテンツのHTMLタグを解析し、Webコンテンツから抽出した仮想共有ブラウザ情報を発着間紐付けIDと対応付け、仮想共有ブラウザテーブル421を生成する。なお、図49においては、仮想共有ブラウザを生成する処理が、Webコンテンツを加工する処理の前に行われる例を示したが、これに限られるものではない。仮想共有ブラウザを生成する処理は、例えば、Webコンテンツを加工する処理と併行して行われてもよいなど、任意である。
さて、図50においては、図49に示す処理手順が既に行われ、情報表示端末20それぞれに、加工済みのWebコンテンツが送信されていることを想定する。加工済みのWebコンテンツには、仮想共有ブラウザプログラムが挿入されている。このため、加工済みのWebコンテンツを受信した情報表示端末20それぞれは、ポーリングスクリプトにより、図50のステップS1001に示すように、例えば0.5秒間隔などで、プロキシサーバ400にポーリングする。なお、図50において点線で示す矢印は、ポーリングであることを示す。
例えば、発側のユーザの情報表示端末20において、Webコンテンツ上で、仮想共有ブラウザ情報が入力されたとする。すると、情報表示端末20は、仮想共有ブラウザプログラムにより、仮想共有ブラウザ情報を、発着間紐付けID(必要に応じて、発着間紐付けID及び発着判定フラグ)とともに送信する(ステップS1002)。すると、プロキシサーバ400の仮想共有ブラウザ情報受付部437がこれを受け付け、仮想共有ブラウザテーブル421に格納する(ステップS1003)。
一方、着側のユーザの情報表示端末20は、図50のステップS1004に示すように、プロキシサーバ400の仮想共有ブラウザ情報要求受付部438に、発着間紐付けID及び発着判定フラグとともにポーリングする。すると、仮想共有ブラウザ情報返信部439は、発着間紐付けID及び発着判定フラグを用いて仮想共有ブラウザテーブル421を検索し、前回の要求後に更新された仮想共有ブラウザ情報を取得する(ステップS1005)。そして、仮想共有ブラウザ情報返信部439は、取得した仮想共有ブラウザ情報を、ポーリング元の情報表示端末20に返信する(ステップS1006)。
すると、着側のユーザの情報表示端末20において閲覧されるWebコンテンツには、発側のユーザの情報表示端末20において操作された仮想共有ブラウザ情報(例えば、更新されたフォーム情報など)が表示される(ステップS1007)。
[実施例6の効果]
上述したように、実施例6に係るWebコンテンツ共有システムにおいては、プロキシサーバ400が、情報表示端末20において操作された仮想共有ブラウザ情報(例えば、フォーム情報)を発着間紐付けIDと対応付けて記憶する仮想共有ブラウザテーブル421をさらに備える。そして、仮想共有ブラウザ情報受付部437が、仮想共有ブラウザ情報が通話を行っているユーザの情報表示端末20いずれか一方より変更された場合に、仮想共有ブラウザ情報を発着間紐付けIDとともに情報表示端末20から受け付け、仮想共有ブラウザテーブル421に格納する。また、仮想共有ブラウザ情報要求受付部438が、仮想共有ブラウザ情報を要求する仮想共有ブラウザ情報要求を発着間紐付けIDとともに情報表示端末20から受け付ける。また、仮想共有ブラウザ情報返信部439が、仮想共有ブラウザ情報要求とともに受け付けた発着間紐付けIDを用いて仮想共有ブラウザテーブル421を検索し、仮想共有ブラウザ情報要求の送信元と通話を行っているユーザの仮想共有ブラウザ情報を、送信元の情報表示端末20に返信する。
このようなことから、実施例6によれば、「ページ内での操作の同期」、例えばフォーム操作の同期を実現することも可能になる。また、ユーザ間で共有する仮想共有ブラウザ情報を記憶するテーブルはプロキシサーバ400に備えられるので、既存のWebサーバがデータを記憶する必要もない。
次に、実施例7に係るWebコンテンツ共有システムは、Webコンテンツの閲覧履歴を通話情報と関連付けて保存し、後に、この閲覧履歴を用いて再度の閲覧を制御する。
[閲覧履歴の保存及び閲覧履歴による閲覧の制御]
まず、図51を用いて、『閲覧履歴の保存及び閲覧履歴による閲覧の制御』の概要を説明する。図51は、実施例7の概要を説明するための図である。実施例7に係るWebコンテンツ共有システムにおいて、プロキシサーバは、Webコンテンツの閲覧履歴を全て保存する。また、各ユーザは、自身が閲覧したWebコンテンツについて、閲覧履歴として保存する際の属性を指定することができる。このため、実施例7におけるプロキシサーバは、各ユーザにおいて指定された属性も併せて保存し、この属性に基づいて閲覧を制御する。
図51に示すように、各ユーザは、閲覧履歴の属性として、例えば、『履歴フラグ』、『ひとりフラグ』、『保証フラグ』を指定することができる。プロキシサーバは、例えば『履歴フラグ』の属性が指定されたWebコンテンツについては、閲覧履歴として保存された際と同じユーザ間で通話している場合に、両ユーザによる再度の閲覧が可能となるように制御する(図51の(1)を参照)。また、プロキシサーバは、『ひとりフラグ』の属性が指定されたWebコンテンツについては、閲覧履歴として保存された際に『ひとりフラグ』の属性を指定した本人、あるいは、属性を指定した本人の通話相手のいずれかであれば、そのユーザによる再度の閲覧が可能となるように制御する(図51の(2)を参照)。例えば、Webコンテンツ共有システムは、閲覧履歴の閲覧用に予め定められた特定の番号(特番)を用意する。ユーザがその特番に電話すると、通話相手無しの状態(例えば音声自動応答の状態)となる。そして、Webコンテンツ共有システムは、ユーザが、その状態において、『ひとりフラグ』の属性が指定されたWebコンテンツを閲覧することができるように制御する。
また、プロキシサーバは、『保証フラグ』の属性が指定されたWebコンテンツについては、『保証フラグ』の属性を指定したユーザ(例えばユーザA)が、閲覧履歴として保存された際の通話相手(例えばユーザB)と異なる通話相手(例えばユーザC)と通話している場合に、両ユーザ(ユーザA及びユーザC)による再度の閲覧が可能となるように制御する(図51の(3)を参照)。この再度の閲覧には、通話相手(ユーザC)に対し、属性を指定した本人(ユーザA)とその際の通話相手(ユーザB)とが通話中に閲覧したことを保証する意味がある。
『保証フラグ』の活用方法について一例を挙げて説明する。例えば、ユーザAが患者、ユーザBが病院、ユーザCが保険会社であるとする。ユーザB(病院)とユーザC(保険会社)との間では、予め、ユーザC(保険会社)がユーザA(患者)との間で契約をする条件として、ユーザA(患者)とユーザB(病院)とが所定のWebコンテンツ(健康状態確認コンテンツ)を一緒に閲覧した上で、ユーザB(病院)がその健康状態確認コンテンツ上で『承認』を行うことを定めている。また、その健康状態確認コンテンツは、ユーザC(保険会社)を除いては、ユーザB(病院)との通話中でなければ閲覧できず、また『承認』も、ユーザB(病院)でなければできない仕組みとする。
このような場合に、例えば、ユーザA(患者)とユーザC(保険会社)とが通話することになり、閲覧可能なWebコンテンツとして健康状態確認コンテンツが提示されれば、ユーザC(保険会社)は、少なくともユーザA(患者)とユーザB(病院)とが通話中に健康状態確認コンテンツを閲覧した事実を確認することができる。また、ユーザC(保険会社)が、閲覧履歴の再度の閲覧としてこの健康状態確認コンテンツを閲覧し、『承認』を確認すれば、ユーザC(保険会社)は、ユーザB(病院)が、ユーザA(患者)の健康状態について『承認』を与えたという事実を確認することができる。
なお、『保証フラグ』の活用方法は上記例に限られない。例えば、汎用的に、あるユーザ間における通話中に閲覧されたWebページであることを第三者に保証したい場合には、プロキシサーバは、そのWebページに、例えば「ユーザ○○とユーザ○○との間における通話中に閲覧されたWebページである」との情報を表示するように制御すればよい。その際、プロキシサーバは、例えば発着間紐付けIDを用いてセッション連携サーバに問い合わせを行い、ユーザを特定する情報を取得し、取得した情報を用いて、閲覧履歴として提供するWebページを加工すればよい。
[実施例7におけるプロキシサーバ500の構成]
次に、図52〜54を用いて、実施例7におけるプロキシサーバ500の構成を説明する。図52は、実施例7におけるプロキシサーバ500の構成を示すブロック図であり、図53は、閲覧履歴テーブル521を説明するための図である。また、図54は、閲覧履歴リストを説明するための図である。
図52に示すように、実施例7におけるプロキシサーバ500は、記憶部520に、閲覧履歴テーブル521を備える。また、実施例7におけるプロキシサーバ500は、制御部530に、Webコンテンツ要求受付部531、Webコンテンツ取得部532、閲覧履歴保存部533、Webコンテンツ加工部534、加工済Webコンテンツ返信部535、閲覧制御部536、お気に入り指定受付部537、お気に入り閲覧制御部538を備える。
閲覧履歴テーブル521は、情報表示端末20において閲覧されたWebコンテンツを、通話情報と関連付けて記憶する。具体的には、閲覧履歴テーブル521は、履歴保存部533によって格納されることで、Webコンテンツの閲覧履歴を記憶する。また、閲覧履歴テーブル521が記憶する閲覧履歴は、お気に入り閲覧制御部538による処理に利用される。
例えば、閲覧履歴テーブル521は、図53に示すように、発着間紐付けIDに対応付けて、Webコンテンツの所在情報であるURLと、閲覧履歴が格納された時刻を示すタイムスタンプと、各種フラグとを記憶する。
図52に戻り、制御部530のWebコンテンツ要求受付部531は、これまでの実施例で説明したWebコンテンツ要求受付部231と同様の機能を有する。また、Webコンテンツ取得部532は、これまでの実施例で説明したWebコンテンツ取得部232と同様の機能を有する。また、加工済Webコンテンツ返信部535は、これまでの実施例で説明した加工済Webコンテンツ返信部234と同様の機能を有する。また、閲覧制御部536は、これまでの実施例で説明した閲覧制御部235と同様の機能を有する。
以下では、閲覧履歴保存部533、Webコンテンツ加工部534、お気に入り指定受付部537、お気に入り閲覧制御部538を、順に説明する。
閲覧履歴保存部533は、Webコンテンツの閲覧履歴を保存する。具体的には、閲覧履歴保存部533は、Webコンテンツ取得部532から、Webコンテンツ及び発着間紐付けIDを受け取る。次に、閲覧履歴保存部533は、Webコンテンツ取得部532から受け取った発着間紐付けIDに対応付けて、Webコンテンツ取得部532から受け取ったWebコンテンツのURLを、閲覧履歴テーブル521に格納する。また、閲覧履歴保存部533は、閲覧履歴を格納した時刻を示すタイムスタンプも格納する。なお、この段階において、『履歴フラグ』、『ひとりフラグ』、及び『保証フラグ』は空欄である。
ここで、閲覧履歴保存部533によって閲覧履歴テーブル521に格納されたタイムスタンプの活用方法について説明する。上述したように、閲覧履歴保存部533は、発着間紐付けIDに対応付けてWebコンテンツのURLを閲覧履歴テーブル521に格納する。セッション連携サーバ100は、発着間紐付けIDに対応付けて通話履歴情報(開始時刻及び終了時刻)を管理しているので、プロキシサーバ500は、例えばセッション連携サーバ100に問い合わせることで、発着間紐付けIDに対応付けて格納されたWebコンテンツの閲覧時刻を取得することができる。しかしながら、発着間紐付けIDに基づいて取得することができるこの閲覧時刻は、通話全体の時刻であって、各Webコンテンツ毎の閲覧時刻ではない。このようなことから、実施例7における閲覧履歴保存部533は、WebコンテンツのURLを格納する際に、各WebコンテンツのURLに対応付けてタイムスタンプを格納する。このようにして格納されたタイムスタンプは、「いつ閲覧されたか」といった時刻情報が契約に必要な場合など、各Webコンテンツの閲覧時刻が重要となる場合などに有効活用される。
なお、例えば、後述するお気に入り閲覧制御部538は、閲覧履歴として保存されたWebコンテンツの再度の閲覧を制御する際に、閲覧履歴テーブル521からタイムスタンプを取得し、Webコンテンツがいつ閲覧されたものであるかを示す情報として、Webコンテンツ上に閲覧時刻を表示してもよい。
Webコンテンツ加工部534は、Webコンテンツを加工する。具体的には、Webコンテンツ加工部534は、Webコンテンツ取得部532から、Webコンテンツ、発着間紐付けID及び発着判定フラグを受け取る。また、Webコンテンツ加工部534は、Webコンテンツ取得部532から受け取ったWebコンテンツを加工し、加工済みのWebコンテンツを加工済Webコンテンツ返信部535に送り、加工済みのWebコンテンツを閲覧するためのURL情報、発着間紐付けID及び発着判定フラグを閲覧制御部536に送る。
ここで、Webコンテンツ加工部534は、これまでの実施例で説明したWebコンテンツ加工部233と同様の機能を有する他、以下のような機能を有する。すなわち、Webコンテンツ加工部534は、閲覧履歴の属性の指定を受け付けるための情報を情報表示端末20のWebブラウザ上に表示するとともに、属性の指定が受け付けられた場合に、指定情報を発着間紐付けIDとともにお気に入り指定受付部537に通知するように、Webコンテンツを加工する。
具体的には、Webコンテンツ加工部534は、Webコンテンツを加工する際に、お気に入り指定閲覧プログラムを挿入する。ここで、お気に入り指定閲覧プログラムは、情報表示端末20において、閲覧履歴の属性の指定を受け付けるための情報(例えば、図51に示したチェックボックス付きのウィンドウなど)をWebブラウザ上に表示するとともに、属性の指定が受け付けられた場合に、指定情報を発着間紐付けIDとともにお気に入り指定受付部537に受け付けられるようにするためのプログラムである。
また、お気に入り指定閲覧プログラムは、お気に入りとして登録したWebコンテンツを再度閲覧することを要求する閲覧要求が、発着間紐付けID及び発着判定フラグとともにお気に入り閲覧制御部538によって受け付けられるようにするためのプログラムである。
例えば、お気に入り指定閲覧プログラムは、JavaScript(登録商標)などのスクリプトによって実現され、Webコンテンツ加工部534によってWebコンテンツに挿入される。なお、スクリプトの挿入は、実施例4において説明したマウスポインタ共有プログラムと同様に行われる。
お気に入り指定受付部537は、閲覧履歴の属性の指定を情報表示端末20から受け付ける。具体的には、お気に入り指定受付部537は、閲覧履歴の属性の指定、すなわち、『履歴フラグ』、『ひとりフラグ』、『保証フラグ』の指定情報を、発着間紐付けID(必要に応じ、発着間紐付けID及び発着判定フラグ)とともに情報表示端末20から受け付ける。そして、お気に入り指定受付部537は、受け付けた指定情報を、閲覧履歴テーブル521に記憶されたレコードのうち、発着間紐付けIDが一致するレコードに格納する。なお、属性の指定は、現に閲覧中のWebコンテンツに対して行われることを想定するので、お気に入り指定受付部537は、閲覧履歴テーブル521に記憶されたレコードのうち、現に閲覧中のWebコンテンツのレコードであって発着間紐付けIDが一致するレコードに格納する。
お気に入り閲覧制御部538は、閲覧履歴として保存されたWebコンテンツの再度の閲覧を制御する。具体的には、お気に入り閲覧制御部538は、閲覧履歴として保存されたWebコンテンツの閲覧要求を、発着間紐付けID及び発着判定フラグとともに情報表示端末20から受け付ける。
次に、お気に入り閲覧制御部538は、閲覧要求を受け付けると、発着間紐付けID及び発着判定フラグを用いて閲覧履歴テーブル521を参照し、閲覧要求の要求元に再度閲覧させることが可能な閲覧履歴のリストを取得する。そして、お気に入り閲覧制御部538は、閲覧履歴テーブル521から取得した閲覧履歴のリストを要求元の情報表示端末20に送信する。
その後、情報表示端末20においてURLが選択され、選択されたURLがプロキシサーバ500に送信された場合、Webコンテンツの閲覧をどのように制御するか、2つの手法が考えられる。ひとつの手法としては、プロキシサーバ500が、閲覧履歴としてWebコンテンツ自体も保存している場合、例えばお気に入り閲覧制御部538が、このWebコンテンツを取得し、URLの送信元の情報表示端末20に返信する手法が考えられる。
Webコンテンツ自体を保存する手法の中にも、加工済みのWebコンテンツを保存する手法、加工前のWebコンテンツを保存する手法、あるいはWebコンテンツを画像として保存する手法(スクリーンショットなど)などがある。加工済みのWebコンテンツを保存する手法では、お気に入り閲覧制御部538は、閲覧履歴として保存された際の過去の発着間紐付けIDが埋め込まれた加工済みのWebコンテンツを、URLの送信元の情報表示端末20に返信することになる。このため、閲覧履歴を閲覧した情報表示端末20において、例えばユーザがリンク情報をクリックしてページ遷移を試みたとしても、ページ遷移の同期などは適切には制御されない。
一方、加工前のWebコンテンツを保存する手法では、プロキシサーバ500は、改めてこのWebコンテンツをWebコンテンツ加工部534に加工させるなどした上で、URLの送信元の情報表示端末20に返信することができる。この際の加工として、Webコンテンツ加工部534は、例えば、閲覧履歴として保存された際と同じ状態に加工することができる。すなわち、Webコンテンツ加工部534は、過去の発着間紐付けIDが埋め込まれた加工済みのWebコンテンツに加工することができる。また、Webコンテンツ加工部534は、例えば、再度の閲覧時に適合した状態に加工することができる。すなわち、Webコンテンツ加工部534は、現在の発着間紐付けIDが埋め込まれた加工済みのWebコンテンツに加工することができる。この場合には、閲覧履歴を閲覧した情報表示端末20において、例えばユーザがリンク情報をクリックしてページ遷移を試みた場合には、ページ遷移の同期などが適切に制御される。さらに、Webコンテンツ加工部534は、例えば、ページ遷移の同期が不能となるように、Webコンテンツに含まれるリンク情報を無効化する、といった加工を行うこともできる。
また、もうひとつの手法としては、プロキシサーバ500が、閲覧履歴としてWebコンテンツ自体を保存していない場合、例えばWebコンテンツ要求受付部531が、通常のWebコンテンツの閲覧と同様に再度Webコンテンツの要求を受け付け、その後、Webコンテンツ取得部532がWebコンテンツを再度取得する手法が考えられる。再度取得されたWebコンテンツについて、Webコンテンツ加工部534がどのような加工を行うかについては、上述した通り、様々な手法が考えられる。
なお、実施例7に係るWebコンテンツ共有システムは、他の実施例で説明した各種機能を適宜合わせて備えることができるが、例えば、実施例6において説明した『フォーム操作の同期』機能を有する場合、プロキシサーバ500は、Webコンテンツの他に、仮想共有ブラウザ情報を保存しておいてもよい。この場合、お気に入り閲覧制御部538は、再度の閲覧時に、『フォーム』の最終状態を復元することができる。
上述したように、Webコンテンツの保存手法は、適宜選択することが可能であり、提供するサービスや、閲覧履歴の属性として何が指定されているかなどに応じて、適宜選択されればよいものである。例えば、閲覧履歴の属性として『保証フラグ』が指定されている場合に、プロキシサーバ500は、加工済みのWebコンテンツを保存するとともに『フォーム』の最終状態に対応する仮想共有ブラウザ情報を保存することができる。すると、ユーザは、『保証フラグ』が指定された閲覧履歴を再度閲覧する際に、『フォーム』の最終状態を閲覧することができる。
ここで、お気に入り閲覧制御部538は、閲覧要求の要求元に再度閲覧させることが可能な閲覧履歴のリストをどのように取得するかについて説明する。上述したように、お気に入り閲覧制御部538は、『履歴フラグ』の属性が指定されたWebコンテンツについては、閲覧履歴として保存された際と同じユーザ間で通話している場合に、両ユーザによる再度の閲覧が可能となるように制御する。また、お気に入り閲覧制御部538は、『ひとりフラグ』の属性が指定されたWebコンテンツについては、閲覧履歴として保存された際に『ひとりフラグ』の属性を指定した本人、あるいは、属性を指定した本人の通話相手のいずれかであれば、そのユーザによる再度の閲覧が可能となるように制御する。また、お気に入り閲覧制御部538は、『保証フラグ』の属性が指定されたWebコンテンツについては、『保証フラグ』の属性を指定したユーザ(例えばユーザA)が、閲覧履歴として保存された際の通話相手(例えばユーザB)と異なる通話相手(例えばユーザC)と通話している場合に、両ユーザ(ユーザA及びユーザC)による再度の閲覧が可能となるように制御する。
そこで、例えば、お気に入り閲覧制御部538は、閲覧履歴として保存されたWebコンテンツの閲覧要求を、発着間紐付けID及び発着判定フラグとともに情報表示端末20から受け付けると、発着間紐付けID及び発着判定フラグを用いてセッション連携サーバ100に対して問い合わせを行う。すると、セッション連携サーバ100は、閲覧の要求者とその通話相手とを特定する。
すなわち、セッション連携サーバ100は、制御用セッション情報管理テーブル121や発着間紐付けID管理テーブル122を備えているので、発着間紐付けID及び発着判定フラグから、閲覧の要求者とその通話相手とを特定することが可能である。次に、セッション連携サーバ100は、特定した要求者及びその通話相手の情報を用いて制御用セッション情報管理テーブル121及び発着間紐付けID管理テーブル122を参照し、両ユーザによって通話が行われた場合の発着間紐付けID、要求者によって通話が行われた場合の発着間紐付けIDの一覧を、特定した閲覧の要求者及びその通話相手の情報や、過去の通話情報などとともに、お気に入り閲覧制御部538に返信する。
すると、お気に入り閲覧制御部538は、セッション連携サーバ100から送信された発着間紐付けIDの一覧を用いて、閲覧要求の要求元に再度閲覧させることが可能な閲覧履歴を選択する。例えば、お気に入り閲覧制御部538は、両ユーザによって通話が行われた場合の発着間紐付けIDを用いて閲覧履歴テーブル521を参照し、該発着間紐付けIDに対応付けて履歴フラグ『OK』が記憶されていれば、両ユーザによる再度の閲覧が可能となるように制御するWebコンテンツであるとしてそのURLを取得する。
また、例えば、お気に入り閲覧制御部538は、要求者(例えばユーザA)によって通話が行われた場合の発着間紐付けIDを用いて閲覧履歴テーブル521を参照し、該発着間紐付IDに対応付けて保証フラグ『OK』が記憶されていれば、閲覧履歴として保存された際の通話相手(例えばユーザB)と異なる通話相手(例えばユーザC)と通話している場合であっても、両ユーザ(ユーザA及びユーザC)による再度の閲覧が可能となるように制御するWebコンテンツであるとしてそのURLを取得する。
また、例えば、お気に入り閲覧制御部538は、セッション連携サーバ100から送信された通話相手が、予め定められた特定の番号(閲覧履歴の閲覧用の特番)である場合には、要求者によって通話が行われた場合の発着間紐付けIDを用いて閲覧履歴テーブル521を参照し、該発着間紐付けIDに対応付けてひとりフラグ『OK』が記憶されていれば、そのユーザによる再度の閲覧が可能となるように制御するWebコンテンツであるとしてそのURLを取得する。
このように、お気に入り閲覧制御部538は、例えば図54の(A)に示すWebページにおいて、ユーザが『お気に入りを取得』のボタンを押下すると、『履歴フラグ』に対応する閲覧履歴のリストや、『保証フラグ』に対応する閲覧履歴のリストを取得し、要求元のユーザが操作する情報表示端末20に送信する。すると、例えば図54の(B)に示すようなWebページが、情報表示端末20において表示される。同様に、ユーザの通話相手が特番である場合には、お気に入り閲覧制御部538は、『ひとりフラグ』に対応する閲覧履歴のリストを取得し、要求元のユーザが操作する情報表示端末20に送信する。すると、例えば図54の(C)に示すようなWebページが、情報表示端末20において表示される。
なお、実施例7においては、お気に入り閲覧制御部538が、セッション連携サーバ100に問合せを行う手法を想定したが、これに限られるものではない。例えば、プロキシサーバ500が、セッション連携サーバ100と同期をとるなどして、制御用セッション情報管理テーブル121や発着間紐付けID管理テーブル122に相当する情報を記憶していてもよい。また、例えば、閲覧履歴保存部533が閲覧履歴を保存する際に、セッション連携サーバ100に問合せを行い、例えばcallセッション情報とともに閲覧履歴を保存してもよい。
なお、上述した閲覧履歴の属性は一例に過ぎず、閲覧条件などについて任意に変更することができる。例えば『ひとりフラグ』について、上述では、属性の指定者本人あるいはその通話相手のいずれかであれば再度の閲覧が可能となるように制御する、と説明した。しかしながら本発明はこれに限られるものではない。例えば、プロキシサーバ500は、『ひとりフラグ』の属性が指定されたWebコンテンツについては、閲覧履歴として保存された際に『ひとりフラグ』の属性を指定した本人に限定して、その本人であれば再度の閲覧が可能となるように制御してもよい。この場合には、閲覧履歴テーブル521は、『ひとりフラグ』として『発』や『着』を記憶すればよい。また、属性の指定や閲覧要求などにおいてもユーザ(発着)の区別が必要となるので、プロキシサーバ500は、その制御において、発着間紐付けIDとともに発着判定フラグを用いるようにすればよい。
また、例えば、プロキシサーバ500は、『ひとりフラグ』の属性が指定されたWebコンテンツについては、本人に限定して再度の閲覧を可能とするのか、あるいは、その際の通話相手に限定して再度の閲覧を可能とするのか、あるいは、双方による再度の閲覧を可能とするのか、を、属性を指定する本人にさらに指定させてもよい。
また、閲覧履歴の属性は、複数の属性を重複して指定することも可能である。また、初期値の属性を定めておくことで、例えばユーザによって属性の指定がなされなかった場合には、予め定められた初期値の属性を用いて運用することも可能である。
[実施例7に係るWebコンテンツ共有システムによる処理手順]
続いて、図55〜図57を用いて、実施例7に係るWebコンテンツ共有システムによる処理手順を説明する。図55及び図56は、実施例7に係るWebコンテンツ共有システムによる処理手順を示すシーケンス図である。図57は、実施例7に係るお気に入り閲覧制御部538による処理手順を示すフローチャートである。
図55に示す処理手順は、例えば実施例1において図16を用いて説明した処理手順とほぼ同様であるが、ステップS1102として、閲覧履歴を保存する処理が含まれる点が異なる。すなわち、ステップS1102において、閲覧履歴保存部533が、発着間紐付けIDに対応付けて、WebコンテンツのURLを閲覧履歴テーブル521に格納する。なお、図55においては、閲覧履歴を保存する処理が、Webコンテンツを加工する処理の前に行われる例を示したが、これに限られるものではない。閲覧履歴を保存する処理は、例えば、Webコンテンツを加工する処理と併行して行われるなど、任意である。
さて、図56においては、図55に示す処理手順が既に行われ、情報表示端末20それぞれに、加工済みのWebコンテンツが返信されていることを想定する。加工済みのWebコンテンツには、お気に入り指定閲覧プログラムが挿入されている。このため、加工済みのWebコンテンツを受信した情報表示端末20それぞれは、図56のステップS1201に示すように、閲覧履歴の属性の指定(お気に入りフラグ)を、発着間紐付けID(必要に応じ、発着間紐付けID及び発着判定フラグ)とともに送信する。一方、お気に入り指定受付部537は、ステップS1202に示すように、受け付けたお気に入りフラグを、閲覧履歴テーブル521に記憶されたレコードのうち、発着間紐付けIDが一致するレコードに格納する。
また、お気に入り閲覧制御部538は、図57に示すように、お気に入りの閲覧要求を受け付けたか否かを判定し(ステップS1)、受け付けた場合には(ステップS1肯定)、発着間紐付けIDを用いてセッション連携サーバ100に問合せを行うなどして、閲覧の要求者及び通話相手を確認する(ステップS2)。
そして、お気に入り閲覧制御部538は、閲覧の要求者及び通話相手に基づいて、閲覧履歴テーブル521から閲覧履歴のリストを取得し(ステップS3)、取得したリストを要求元の情報表示端末20に送信する(ステップS4)。
その後、お気に入り閲覧制御部538は、情報表示端末20においてURLが選択され、選択されたURLを受け付けると(ステップS5肯定)、選択されたWebコンテンツが再度閲覧されるように、Webコンテンツを送信する(ステップS6)。
なお、上述においては、Webコンテンツ共有システムが全ての閲覧履歴を保存した後に、各ユーザが閲覧履歴の属性を指定する手法を説明したが、本発明はこれに限られるものではない。例えば、Webコンテンツ共有システムは、閲覧履歴の保存を指示された場合にのみ、閲覧履歴を保存してもよい。また、各ユーザによる属性の指定も必ずしも必須ではなく、例えば、Webコンテンツ共有システムは、予め定められた属性で保存してもよい。
[実施例7の効果]
上述したように、実施例7に係るWebコンテンツ共有システムは、情報表示端末20それぞれにおいて閲覧されたWebコンテンツの履歴情報を、ユーザ間で行われた通話と関連付けて記憶する閲覧履歴テーブル521をさらに備える。また、実施例7に係るWebコンテンツ共有システムは、お気に入り閲覧制御部538をさらに備える。お気に入り閲覧制御部538は、閲覧履歴テーブル521によって記憶されたWebコンテンツの閲覧要求を、発着間紐付けIDとともに情報表示端末20のいずれかより受け付ける。また、お気に入り閲覧制御部538は、発着間紐付けIDに基づいて、閲覧要求の要求元の情報表示端末20を利用するユーザが行う通話を特定し、特定した通話と、Webコンテンツの履歴情報に関連付けられた通話とに基づいて、閲覧を制御する。
このようなことから、実施例7によれば、閲覧履歴として保存されたWebコンテンツの閲覧を、通話と関連付けて制御することが可能になる。
さて、これまでの実施例において、「ページ遷移の同期」や「ページ内での操作の同期」は、いずれもセッション連携サーバ100によって制御されていた。すなわち、例えば図16のステップS115〜S117を参照するとわかるように、プロキシサーバ200は、加工済みWebコンテンツを情報表示端末20に送信した後、URL情報を発着間紐付けIDとともにセッション連携サーバ100に通知した。すると、セッション連携サーバ100が、発着間紐付けIDに基づき通話相手を特定し、特定した通話相手の情報表示端末20に対して、プロキシサーバ200から通知されたURL情報を通知した。しかしながら、本発明はこれに限られるものではなく、プロキシサーバが、「ページ遷移の同期」や「ページ内での操作の同期」を制御してもよい。
図58は、実施例8に係るWebコンテンツ共有システムによる処理手順を示すシーケンス図である。図58のステップS1205に示すように、例えば、各情報表示端末20は、ポーリングスクリプトにより、例えば0.5秒間隔などで、発着間紐付けID及び発着判定フラグとともにプロキシサーバ600にポーリングするとする。
このようなポーリングスクリプトを、いつ情報表示端末20に設定するかであるが、例えば、図13のステップS109においてリダイレクトされることで、情報表示端末20がプロキシサーバ200との間で通信を開始すると、プロキシサーバ600は、最初の画面として、図15の(A)に示す画面を情報表示端末20に送信する。このとき、プロキシサーバ600は、上記ポーリングスクリプトを併せて送信すればよい。また、その後プロキシサーバ600が加工済みWebコンテンツを情報表示端末20に送信する際にも、加工済みWebコンテンツに上記ポーリングスクリプトを挿入すればよい。
図58において、プロキシサーバ600は、ステップS1200において受信した発着間紐付ID及び発着判定フラグと、加工済みWebコンテンツとを対応付けて管理するものとする。すると、プロキシサーバ600は、ステップS1203において加工済みWebコンテンツを情報表示端末20に送信した後に、ステップS1200において受信した発着間紐付IDと同一の発着間紐付ID、及び、ステップS1200において受信した発着判定フラグと異なる発着判定フラグによるポーリングを受け付けると(ステップS1205)、この情報表示端末20に対して、加工済みのWebコンテンツを閲覧するためのURLを送信する(ステップS1206)。
なお、上記手法に限られず、その他、例えば、プロキシサーバが、セッション連携サーバ100と同様の機能を有することで実現できる。
[実施例8の効果]
上述したように、実施例8によれば、プロキシサーバが、「ページ遷移の同期」や「ページ内での操作の同期」を制御する。このため、セッション連携サーバとプロキシサーバとの間で負荷を分散することが可能になる。例えばセッション連携サーバが途中でシステムダウンした場合であっても、プロキシサーバによってWebコンテンツ共有サービスを継続していくことが可能になる。
続いて、実施例9に係るWebコンテンツ共有システムを説明する。実施例9に係るWebコンテンツ共有システムは、各情報表示端末20からプロキシサーバ200に対するポーリングを利用して、通話相手が閲覧するWebページ上にオンライン表示を行う。すなわち、実施例9においては、各ユーザが閲覧するWebページ上に、通話相手がWebコンテンツ共有サービスを起動中であることを示す『オンラインマーク』が表示される。以下、図59及び図60を用いて、実施例9に係るWebコンテンツ共有システムを説明する。
まず、オンライン表示について説明する。図59は、オンライン表示を説明するための図である。図59に示すように、実施例9に係るWebコンテンツ共有システムにおいて、各情報表示端末20に表示されるWebページは、例えば『領域1』及び『領域2』に区分けされている。ここで、『領域1』及び『領域2』は、一般的なWebページでいうところのフレームに相当する。
ここで、実施例9に係るWebコンテンツ共有システムにおいては、例えば『領域1』に『オンラインマーク』が表示される。例えば図59の(A)に示すように、『領域1』に何も表示されていない場合、通話相手がWebコンテンツ共有サービスを起動中でないことを示す。すると、図59の(A)に示すWebページを閲覧したユーザは、通話相手と通話中にWebページの『領域1』を確認することで、通話相手がWebコンテンツ共有サービスを起動していないことを認識することができる。ユーザが、例えば通話によって通話相手にWebコンテンツ共有サービスの起動を促し、通話相手がWebコンテンツ共有サービスを起動したとする(例えば、通話相手が、制御ページの『領域2』に表示された複数のサービスの中から『Webでいっしょ』を選択したとする)。すると、例えば図59の(B)に示すように、『領域1』に、通話相手がWebコンテンツ共有サービスを起動中であることを示す『オンラインマーク』が表示される。
かかる仕組みがどのように実現されるかについて説明する。図13を用いて説明したように、セッション連携サーバ100は、制御ページを生成し、情報表示端末20は、セッション連携サーバ100から送信された制御ページをWebブラウザから表示する。この段階において、『領域1』及び『領域2』は、いずれも、セッション連携サーバ100の制御下にある。
ここで、ユーザが、制御ページの『領域2』に表示された複数のサービスの中から『Webでいっしょ』を選択したとする。すると、図13を用いて説明したように、セッション連携サーバ100からプロキシサーバ200のURLが通知され、情報表示端末20は、リダイレクトされ、プロキシサーバ200との間で通信を開始する。この段階において、『領域2』には、例えば図15の(A)に示す画面が表示され、『領域2』は、プロキシサーバ200の制御下となる。
さて、プロキシサーバ200に対するポーリングを行うためのポーリングスクリプトを、いつ情報表示端末20に設定するかであるが、例えば、図13のステップS109においてリダイレクトされることで、情報表示端末20がプロキシサーバ200との間で通信を開始すると、プロキシサーバ200は、最初の画面として、図15の(A)に示す画面を情報表示端末20に送信する。このとき、プロキシサーバ200は、上記ポーリングスクリプトを併せて送信すればよい。すなわち、ユーザが『Webでいっしょ』を選択し、Webコンテンツ共有サービスを起動すると、上記ポーリングスクリプトが情報表示端末20に設定され、情報表示端末20からプロキシサーバ200に対するポーリングが開始される。また、その後プロキシサーバ200が加工済みWebコンテンツを情報表示端末20に送信する際にも、加工済みWebコンテンツに上記ポーリングスクリプトを挿入すればよい。
図60は、オンライン表示の処理手順を示すシーケンス図である。上述したように、ユーザがWebコンテンツ共有サービスを起動すると、情報表示端末20は、プロキシサーバ200に対するポーリングが開始し、その後一定間隔で、プロキシサーバ200に対するポーリングを行う。例えば図60のステップS1300に示すように、情報表示端末20は、例えば0.5秒間隔などで、発着間紐付けID及び発着判定フラグとともに、プロキシサーバ200に対するポーリングを行う。
すると、プロキシサーバ200は、ポーリングスクリプトによって受信した発着間紐付けID及び発着判定フラグを、セッション連携サーバ100に通知する(ステップS1301)。一方、セッション連携サーバ100は、プロキシサーバ200から通知を受けると、発着間紐付けID及び発着判定フラグを用いて制御用セッション情報管理テーブル121及び発着間紐付けID管理テーブル122を参照し、通話相手(例えば図60において、発側のユーザ)を特定する(ステップS1302)。そして、セッション連携サーバ100は、特定した発側のユーザに関する『領域1』を生成する(ステップS1303)。例えば、発側のユーザのWebページの『領域1』に、通話相手である着側のユーザがWebコンテンツ共有サービスを起動中であることを示す情報が表示されるように、『領域1』を生成する。
そして、セッション連携サーバ100が、生成した『領域1』を発側のユーザの情報表示端末20に送信すると(ステップS1304)、情報表示端末20は、『領域1』を更新表示する(ステップS1305)。
例えば、情報表示端末20は、ステップS1305の更新表示を定期的に行うとする。すると、情報表示端末20は、セッション連携サーバ100から『領域1』の更新情報を受け取らずに更新表示のタイミングを迎えた場合には、例えば通話相手がWebコンテンツ共有サービスを起動していないことを示す情報が表示されるように(例えば図59の(A))、『領域1』を表示する。また、情報表示端末20は、セッション連携サーバ100から『領域1』の更新情報を受け取って更新表示のタイミングを迎えた場合には、例えば通話相手がWebコンテンツ共有サービスを起動中であることを示す情報が表示されるように(例えば図59の(B))、『領域1』を表示する。
あるいは、例えば、情報表示端末20は、セッション連携サーバ100から『領域1』の更新情報を受け取ったタイミングで、『領域1』を更新表示してもよい。
あるいは、例えば、情報表示端末20とセッション制御サーバ100との間で、定期的なポーリングを行ってもよい。例えば、図13のステップS104においてセッション連携サーバ100から情報表示端末20に対して送信される制御ページに、ポーリングスクリプトを挿入する。すると、例えば、情報表示端末20は、一定間隔で、セッション制御サーバ100に対するポーリングを行い、セッション連携サーバ100において『領域1』が新たに生成された場合には、その『領域1』を取得して、『領域1』を更新表示する。
なお、上記では、プロキシサーバ200を例に挙げて説明したが、他の実施例にて説明したプロキシサーバ400、プロキシサーバ500、プロキシサーバ600の場合も同様に、『オンライン表示』を実現することができる。
また、上記では、各情報表示端末20に表示されるWebページが、例えば『領域1』及び『領域2』に区分けされ、オンラインマークを『領域1』に表示する例を説明したが、本発明はこれに限られるものではない。例えば、オンラインマークは、『領域2』に表示されてもよい。この場合、『領域2』を制御する主体はプロキシサーバ200である。このため、ポーリングを検知したプロキシサーバ200自身がオンラインマークを生成すればよい。すなわち、例えばプロキシサーバ200は、ポーリングスクリプトによって発着間紐付けID及び発着判定フラグを受信し、その後、既に受信した発着間紐付けIDと同一の発着間紐付けID、及び、既に受信した発着判定フラグと異なる発着判定フラグによるポーリングを受け付ける。すると、プロキシサーバ200は、後者のポーリングを行った情報表示端末20に対して、通話相手のユーザがWebコンテンツ共有サービスを起動中であることを示す情報が表示されるように『領域2』(あるいはオンラインマーク)を生成し、送信する。また、領域が区分けされていない場合も同様に適用することができる。
また、上記では、各情報表示端末20からプロキシサーバ200に対するポーリングを利用してオンライン表示を行う例を説明したが、本発明はこれに限られるものではない。例えば、各情報表示端末20からセッション連携サーバ100に対するポーリングを利用してオンライン表示を行ってもよい。例えば、実施例1、図13のステップS104において、セッション連携サーバ100は、情報表示端末20に対して制御ページを送信すると説明した。セッション連携サーバ100は、例えばこの制御ページを送信する際に、情報表示端末20がセッション連携サーバ100に対してポーリングを行うためのポーリングスクリプトを挿入すればよい。すると、情報表示端末20は、その後、発着間紐付けID及び発着判定フラグとともにセッション連携サーバ100に対するポーリングを開始するので、セッション連携サーバ100は、このポーリングを契機として、例えば通話相手が閲覧する制御ページやWebページにオンラインマークが生成されるように制御すればよい。すなわち、例えばセッション連携サーバ100は、ポーリングスクリプトによって発着間紐付けID及び発着判定フラグを受信し、その後、既に受信した発着間紐付けIDと同一の発着間紐付けID、及び、既に受信した発着判定フラグと異なる発着判定フラグによるポーリングを受け付ける。すると、セッション連携サーバ100は、後者のポーリングを行った情報表示端末20に対して、通話相手のユーザが、少なくともセッション連携サーバ100に対するポーリングを開始中であることを示す情報が表示されるように制御ページやWebページを生成し、送信する。
さて、これまで本発明の実施例1〜9について説明したが、各実施例は、適宜組み合わせることが可能であり、また、本発明は、上記した実施例以外にも種々の異なる形態にて実施されてよいものである。
[ページ遷移の同期、及び、ページ内での操作の同期 双方を実現]
上記実施例1〜3においては、Webコンテンツ共有システムが、Webコンテンツに係る情報としてWebコンテンツのURL情報を連携することで「ページ遷移の同期」を実現する手法を説明した。一方、上記実施例4においては、Webコンテンツ共有システムが、Webコンテンツに係る情報としてマウスポインタの座標情報を連携することで「ページ内での操作の同期」を実現する手法を説明した。また、上記実施例6においては、Webコンテンツ共有システムが、Webコンテンツに係る情報としてフォーム情報などを連携することで「ページ内での操作の同期」を実現する手法を説明した。ここで、本発明に係るWebコンテンツ共有システムは、「ページ遷移の同期」及び「ページ内での操作の同期」の双方を同時に実現することができる。
例えば、Webコンテンツ共有システムのWebコンテンツ加工部233が、取得したWebコンテンツに対して2種類の加工を施す。具体的には、Webコンテンツ加工部233は、他のWebコンテンツに遷移するためのリンク情報が指定されることによりWebコンテンツのURL情報が情報表示端末20において変更された場合に、WebコンテンツのURL情報を発着間紐付けIDとともにWebコンテンツ要求受付部231に通知するように、取得したWebコンテンツを加工する。また、Webコンテンツ加工部233は、マウスポインタの座標情報が情報表示端末20において変更された場合に、座標情報を発着間紐付けIDとともに共有データ受付部236に通知するように、取得したWebコンテンツを加工する。
すると、リンク情報が指定されることによりWebコンテンツのURL情報が通話を行っているユーザの情報表示端末20いずれか一方より変更された場合には、Webコンテンツ要求受付部231が、WebコンテンツのURL情報及び発着間紐付けIDを受け付け、再び、Webコンテンツ取得部232がWebコンテンツを取得し、Webコンテンツ加工部233が、2種類の加工を施し、加工済Webコンテンツ返信部234が、加工されたWebコンテンツを、Webコンテンツ要求の送信元の情報表示端末20に返信する。
一方、マウスポインタの座標情報が通話を行っているユーザの情報表示端末20いずれか一方より変更された場合には、共有データ受付部236が、座標情報及び発着間紐付けIDを受け付け、共有データテーブル223に格納する。また、共有データ要求受付部237が、マウスポインタの座標情報を要求する操作情報要求を発着間紐付けIDとともに情報表示端末20から受け付け、共有データ返信部238が、マウスポインタの座標情報を送信元の情報表示端末20に返信する。
[通知モード]
また、上記した実施例においては、通知モードとして、両者モードが指定された場合を説明した。しかしながら、本発明はこれに限られるものではなく、一方モードが指定された場合にも、同様に適用することができる。この場合には、閲覧制御部235は、加工済みのWebコンテンツを閲覧するためのURL情報ではなく、Webコンテンツ要求として指定された本来のURL情報をセッション連携サーバ100に送信する。すると、セッション連携サーバ100のURL通知部133は、本来のURL情報を情報表示端末20に対して送信する。このため、情報表示端末20は、プロキシサーバ200にアクセスしてWebコンテンツを閲覧するのではなく、本来のURL情報にて指定されたWebサーバにアクセスしてWebコンテンツを閲覧することになる。
このような仕組みによれば、一方の情報表示端末20のページ遷移に他方の情報表示端末20のページ遷移を追従させるがその反対は追従させないことができる。例えば、学習塾の先生と生徒とが通話を行っている場合には、先生側のページ遷移に生徒側のページ遷移を追従させるが、生徒側のページ遷移に先生側のページ遷移を追従させないといった制御を行うことができる。言い換えると、例えば、生徒側が勝手に授業と関係のないサイトに遷移して閲覧していたとしても、先生側で閲覧するページは遷移せず、先生側でページ遷移をすれば、強制的に生徒側の閲覧ページが先生側のページと一致するように遷移することになる。
[Webコンテンツの記憶]
上記実施例5においては、プロキシサーバ200が未加工のWebコンテンツを記憶し、ページ遷移を同期される側の情報表示端末20からのWebコンテンツ要求を受け付けると、未加工のWebコンテンツを改めて加工して返信する手法や、プロキシサーバ200が加工済みのWebコンテンツを記憶し、ページ遷移を同期される側の情報表示端末20からのWebコンテンツ要求を受け付けると、加工済みのWebコンテンツのうち必要な部分を加工し直して返信する手法を説明した。この手法は、Webコンテンツ共有の高速化及び同一性の確保の観点において有効であり、実施例5に限られず、他の実施例にも同様に適用することができる。
例えば、実施例1においても、プロキシサーバ200は、未加工のWebコンテンツ(もしくは加工済みのWebコンテンツ)、例えば図16のステップS111で取得したWebコンテンツ(もしくはステップS112で加工した加工済みのWebコンテンツ)を記憶し、ページ遷移を同期される側の情報表示端末20からのWebコンテンツ要求を受け付けると、記憶しているWebコンテンツを加工(もしくは必要な部分を加工)して返信することができる。
[システム構成]
また、上記した実施例においては、プロキシサーバとセッション連携サーバとがそれぞれ物理的に異なる装置で実現され、プロキシサーバとセッション連携サーバとの間で相互に行われるデータ送受信は、ネットワーク経由の通信によって行われることを想定していた。しかしながら、本発明はこれに限られるものではなく、プロキシサーバとセッション連携サーバとは、物理的に同一の1つの装置で実現されてもよい。このような場合には、例えば図16を用いて説明した処理手順の内、ステップS116の処理(Webコンテンツ要求の送信元と通話を行っているユーザの情報表示端末20の特定)は、プロキシサーバ200にて実行することができる。
[端末側の構成]
また、本発明に係るWebコンテンツ共有システムにおいては、まず、端末側の構成という点で、端末側にHGWが設置されているか否か、端末が、SIPフォンと情報表示端末との分離型であるか、SIPフォン機能と情報表示機能との一体型であるか、といった選択肢がある。その他、発信側の構成と着信側の構成とが同一であるか、異なるか、といった選択肢や、情報表示端末がHGWの配下の端末として接続しているか否かといった選択肢もある。上記実施例は、これらの選択肢の内、一部の組み合わせを示したに過ぎず、本発明はこれらの構成に限られるものではない。すなわち、上記してきた手法や公知の手法を用いることで、その他の構成についても、本発明を同様に実現することができる。
また、本実施例において説明した各処理のうち、自動的に行われるとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPU(Central Processing Unit)および当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
なお、上記の実施例で説明したWebコンテンツ共有方法は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのIPネットワークを介して配布することができる。また、このプログラムは、ハードディスク、FD、CD−ROM(Compact Disk Read Only Memory)、MO(Magneto-Optical disk)、DVD(Digital Versatile Disk)などのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。