メッセージ送受信システム、メッセージ送受信方法、メッセージ中継サーバ及びメッセージ送受信用プログラム
【課題】Ｗｅｂブラウザがキャッチアップ時にキャッシュに保存されているメッセージを取得することができるメッセージ送受信システムを提供することを目的とする。
【解決手段】ブラウザを用いたメッセージの送受信を中継するメッセージ中継サーバを備え、メッセージ中継サーバは、メッセージ取得用のリクエストに対するレスポンスとリクエストに含まれるＵＲＬとを対応づけて記憶するレスポンス記憶手段１０と、新たなリクエストを受信すると、受信したリクエストに対応するレスポンスと対応づけられたＵＲＬをレスポンス記憶手段１０から抽出するＵＲＬ抽出手段２０とを含み、ＵＲＬ抽出手段２０が抽出したＵＲＬを用いて、メッセージ取得用のリクエストを生成するリクエスト生成手段３０を備えたことを特徴とする。
【解決手段】ブラウザを用いたメッセージの送受信を中継するメッセージ中継サーバを備え、メッセージ中継サーバは、メッセージ取得用のリクエストに対するレスポンスとリクエストに含まれるＵＲＬとを対応づけて記憶するレスポンス記憶手段１０と、新たなリクエストを受信すると、受信したリクエストに対応するレスポンスと対応づけられたＵＲＬをレスポンス記憶手段１０から抽出するＵＲＬ抽出手段２０とを含み、ＵＲＬ抽出手段２０が抽出したＵＲＬを用いて、メッセージ取得用のリクエストを生成するリクエスト生成手段３０を備えたことを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メッセージを送受信するメッセージ送受信システム、メッセージ送受信方法及びメッセージ送受信信用プログラムに関し、特にメッセージを中継できるメッセージ送受信システム、メッセージ送受信方法及びメッセージ送受信用プログラムに関する。また、本発明は、メッセージ送受信システムが備えるメッセージ中継サーバに関する。
【背景技術】
【０００２】
インターネットの発展により、一般の利用者が、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）上に配置されたＷｅｂページを、コンピュータ上で動作するＷｅｂブラウザを用いて閲覧することが、一般的に行われている。Ｗｅｂブラウザは、様々なコンピュータ上で実装されている。そのため、ユーザが、コンピュータとして一般的なＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）のみならず携帯電話機やゲーム端末、テレビジョン受信機、ビデオ機器などで簡単にＷｅｂブラウザを利用できるようになってきている。
【０００３】
また一般に、遠隔に離れたユーザ同士がネットワークを介して共同で作業を実施するための遠隔協働システムが提案されており、遠隔会議としてユーザ同士が同じ資料や図を同時に参照、描画したり、ファイルを互いに送受信したりするシステムが提案されている。このような遠隔会議システムでは、予めまたは一時的にユーザ同士がある期間一つのグループを形成する。そして、そのグループに属しているユーザ間で、各端末上で行った操作を操作メッセージとしてやりとりし、各端末で操作メッセージに対応した操作を再現することで遠隔での会議を実現している。また、このようなグループへの参加メンバ及び期間をセッションとして管理する。そして、セッションが継続している間はそのセッションに参加しているメンバが操作メッセージをやりとりできるように制御する。一般的にこのような遠隔協働システムにおいてユーザが利用する端末で動作を制御するプログラムは、上り通信として端末で行われた操作を、操作メッセージとして他の端末に送信するように制御する。そして、上記のプログラムは、逆に、下り通信を行うことによって他のプログラムから送信された操作メッセージを受信して、受信したメッセージに記述されている操作内容を自端末上で実行するように制御する。
【０００４】
このような遠隔協働システムとして、Ｗｅｂブラウザをクライアントプログラムとして用いた遠隔協働システムが提案されている。例えば、特許文献１に記載されたシステムでは、サーバ上に配置された表データが更新されるたびに、そのＵＲＬをメッセージとして各端末に送信する。そして、メッセージを受信した各端末がＷｅｂブラウザを用いてそのＵＲＬを表示することで、更新された表データを各ユーザに対して見せることができる。
【０００５】
また、特許文献２に記載されたシステムでは、Ｗｅｂブラウザで表示しているＷｅｂページに対してユーザが行ったスクロールやクリック、テキスト入力などの操作をメッセージとして他のＷｅｂブラウザ（具体的には、Ｗｅｂブラウザを搭載した端末）に送信する。そして、メッセージを受信した他のＷｅｂブラウザがそのメッセージに記述されている内容に従って操作を再現することで、Ｗｅｂブラウザに表示されるＷｅｂページを同期させている。
【０００６】
このようなＷｅｂブラウザを用いた遠隔協働システムにおいて、操作の同期を実現するためには、メッセージの送信処理（上り通信）及び受信処理（下り通信）をＷｅｂブラウザ上で実装する必要がある。この時、Ｗｅｂブラウザ同士で直接通信する機能がＷｅｂブラウザには備わっていないため、Ｗｅｂブラウザは必ずＷｅｂサーバと通信する必要がある。そして、このＷｅｂサーバ上にメッセージを中継する手段を実装することにより、Ｗｅｂブラウザ間のメッセージ交換が可能となる。
【０００７】
この時ＷｅｂブラウザとＷｅｂサーバとが通信するために利用するＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）プロトコルについては、Ｗｅｂブラウザがリクエストの送信元となる。そして、Ｗｅｂサーバは、Ｗｅｂブラウザからのリクエストを受け取ってから、そのリクエストに応じた処理を実施する。よって、前述したメッセージの上り、下り通信のうち、上り通信では、通常通りＷｅｂブラウザからのＨＴＴＰを利用したリクエスト（以下、ＨＴＴＰリクエスト）を用いればＷｅｂサーバに届けることが可能であるが、下り通信では、Ｗｅｂサーバから能動的にＷｅｂブラウザに向かって通信を開始する手段がないため、通常の手段では実現できない。
【０００８】
これを可能とするための手段として、特許文献２に記載されたシステムでは、永続的ポーリングという手法を提案している。これは、下り通信用にある間隔でＷｅｂブラウザからメッセージ中継用のサーバにリクエストを送信し、メッセージ中継サーバにメッセージが存在する場合に、そのレスポンスでメッセージを受信することで、完全なリアルタイムではないが、ある間隔の遅延をおいてメッセージを随時取得するという手法である。
【０００９】
また、遠隔協働システムにおいて動作しているセッションに対し、途中で新たにユーザがメンバとして加わった場合、新たに加わったメンバが操作するＷｅｂブラウザは、当該セッションに参加している他のメンバのＷｅｂブラウザと表示及び内部状態を合わせるため、キャッチアップと呼ぶ追随処理を実施する。これは当該セッションにおいてメッセージ中継サーバを介して送受信されたメッセージを最初から順に取得し、そのメッセージに従って操作を再現することで、他のメンバが操作するＷｅｂブラウザと表示及び内部状態を同一にすることで実現する。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００３−２５９３２３号公報
【特許文献２】特表２００２−５１４３３２号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
ある期間継続しているセッションがあり、そのセッションに参加しているユーザがＷｅｂブラウザの操作を繰り返した場合、当該セッションにおける送受信メッセージがメッセージ中継サーバに順次蓄積されていく。そして、当該セッションに対し新たにユーザが参加した場合、Ｗｅｂブラウザは、キャッチアップにより最初から順にメッセージ中継サーバからメッセージを取得するが、この時なるべく早期に他のブラウザと同じ状態に追いつく必要があるため、できる限りの早さでメッセージを連続して取得する。その際、メッセージ中継サーバには、一時的に通信と負荷とが集中することになり、全体的なパフォーマンスの低下やサービスの一時停止が発生する可能性がある。
【００１２】
これを回避するため、メッセージ中継サーバにおいてキャッシュを利用したり、メッセージ中継サーバとＷｅｂブラウザとの通信経路の途中にプロキシサーバを設置して、そのキャッシュを利用したりする。例えば、メッセージ中継サーバから一度送信されたメッセージをキャッシュ上に保存し、キャッチアップによる再度の取得時にそのキャッシュに保存されたメッセージを送信することによりメッセージ中継サーバの負荷を軽減するという方法が考えられる。
【００１３】
一般的にキャッシュは、リクエストの内容としてブラウザから送信されたＵＲＬとサーバから返信されたレスポンスとを関連づけて保存しておき、再度ブラウザから送信されたＵＲＬが以前に保存したＵＲＬと同じであれば、保存したレスポンスを即座に返信するという仕組みを持つ。
【００１４】
しかし、前述したようにＷｅｂブラウザによるメッセージ取得要求は、ポーリングによって実現される。通常ポーリングによるメッセージ取得要求は、Ｗｅｂブラウザからリクエストを送信する際、各リクエストのＵＲＬを以前に送信したリクエストとは異なるＵＲＬで送信される。これは、送信済みのリクエストと同じＵＲＬで送信した場合、前述したキャッシュにおいて過去のリクエストと同等であると判定され、メッセージ中継サーバにリクエストが到達せずにキャッシュに保存されたメッセージを返信し続けることとなる。そのため、メッセージ中継サーバにおいて新しいメッセージが蓄積されていても、それをＷｅｂブラウザに返信することができなくなるからである。
【００１５】
さらに、ポーリングによるメッセージ取得のリクエスト送信時にメッセージ中継サーバ側に送信すべき新規のメッセージがなかった場合、そのレスポンスは中身が空のものになり、ブラウザからの各リクエストに対して、全て意味のある返信が返されているとは限らない。
【００１６】
これにより、あるＷｅｂブラウザが他のＷｅｂブラウザが送信したリクエストのＵＲＬを知ることは一概には容易ではなく、また、例え知ることができたとしても、そのリクエストに対してメッセージ中継サーバからメッセージが返信されたかどうかを知ることができない。そのため、他のＷｅｂブラウザに対して返信されたメッセージがキャッシュに残っていたとしても、キャッチアップ時のＷｅｂブラウザが、キャッシュからメッセージを取得することは一概に容易ではない。
【００１７】
そこで、本発明は、Ｗｅｂブラウザがキャッチアップ時にキャッシュに保存されているメッセージを取得することができるメッセージ送受信システム、メッセージ送受信方法、メッセージ中継サーバ及びメッセージ送受信用プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１８】
本発明によるメッセージ送受信システムは、複数のブラウザを用いたメッセージの送受信を中継するメッセージ中継サーバを備え、メッセージ中継サーバは、メッセージ取得用のリクエストに対するレスポンスとリクエストに含まれるＵＲＬとを対応づけて記憶するレスポンス記憶手段と、新たなリクエストを受信すると、受信したリクエストに対応するレスポンスと対応づけられたＵＲＬをレスポンス記憶手段から抽出するＵＲＬ抽出手段とを含み、ＵＲＬ抽出手段が抽出したＵＲＬを用いて、メッセージ取得用のリクエストを生成するリクエスト生成手段を備えたことを特徴とする。
【００１９】
本発明によるメッセージ中継サーバは、複数のブラウザを用いたメッセージの送受信を中継するメッセージ中継サーバであって、メッセージ取得用のリクエストに対するレスポンスとリクエストに含まれるＵＲＬとを対応づけて記憶するレスポンス記憶手段と、新たなリクエストを受信すると、受信したリクエストに対応するレスポンスと対応づけられたＵＲＬをレスポンス記憶手段から抽出するＵＲＬ抽出手段とを備えたことを特徴とする。
【００２０】
本発明によるメッセージ送受信方法は、メッセージ取得用のリクエストに対するレスポンスとリクエストに含まれるＵＲＬとを対応づけて記憶部に記憶するレスポンス記憶ステップと、新たなリクエストを受信すると、受信したリクエストに対応するレスポンスと対応づけられたＵＲＬを記憶部から抽出するＵＲＬ抽出ステップと、抽出したＵＲＬを用いて、メッセージ取得用のリクエストを生成するリクエスト生成ステップとを含むことを特徴とする。
【００２１】
本発明によるメッセージ送受信用プログラムは、複数のブラウザを用いてメッセージの送受信を中継するコンピュータに、メッセージ取得用のリクエストに対するレスポンスとリクエストに含まれるＵＲＬとを対応づけて記憶部に記憶する記憶処理と、新たなリクエストを受信すると、受信したリクエストに対応するレスポンスと対応づけられたＵＲＬを記憶部から抽出するＵＲＬ抽出処理と、抽出したＵＲＬを用いて、メッセージ取得用のリクエストを生成するリクエスト生成処理とを実行させることを特徴とする。
【発明の効果】
【００２２】
本発明によれば、Ｗｅｂブラウザがキャッチアップ時にキャッシュに保存されているメッセージを取得することができる。
【図面の簡単な説明】
【００２３】
【図１】本発明によるメッセージ送受信システムの構成の一例を示すブロック図である。
【図２】Ｗｅｂブラウザを搭載したユーザ端末の構成の一例を示すブロック図である。
【図３】メッセージ中継サーバでのセッションの開始処理例を示す流れ図である。
【図４】アプリケーション処理開始時におけるＷｅｂブラウザでの処理例を示す流れ図である。
【図５】Ｗｅｂブラウザ及びメッセージ中継サーバでの上り通信処理例を示す流れ図である。
【図６】Ｗｅｂブラウザでの下り通信処理例を示す流れ図である。
【図７】メッセージ送信手段での処理例を示す流れ図である。
【図８】送信メッセージ選択手段での処理例を示す流れ図である。
【図９】メッセージ送信手段に置いてメッセージを返信する際のレスポンス管理手段での処理例を示す流れ図である。
【図１０】履歴ＵＲＬを返信する時のレスポンス管理手段での処理例を示す流れ図である。
【図１１】メッセージ送受信システムの最小の構成例を示すブロック図である。
【発明を実施するための形態】
【００２４】
以下、本発明の実施形態について図１及び図２を用いて説明する。図１は、本発明によるメッセージ送受信システムの構成の一例を示すブロック図である。図１に示すように、メッセージ送受信システムは、ユーザ同士が遠隔で協働作業をするためのユーザインターフェイスとして利用するＷｅｂブラウザ１と、前述したＨＴＴＰプロトコルを利用して、Ｗｅｂブラウザ間のメッセージの送受信を中継するＷｅｂサーバ上に実装されたメッセージ中継サーバ２と、一般的なキャッシュ機能を有するプロキシサーバ３とを含む。なお、プロキシサーバ３と同等のキャッシュ機能をメッセージ中継サーバ２が備えている場合には、プロキシサーバ３が無くても構わない。
【００２５】
Ｗｅｂブラウザ１は、具体的には、プログラムに従って動作するパーソナルコンピュータ等の情報処理装置に搭載される。図２は、Ｗｅｂブラウザを搭載したユーザ端末の構成の一例を示すブロック図である。図２に示すように、Ｗｅｂブラウザ１が搭載された端末は、協働作業をするための処理を実装した１つ又は複数のアプリケーション１０１と、Ｗｅｂブラウザ１上で動作するアプリケーション１０１が実施する通信を制御するための通信管理手段１０２と、アプリケーション１０１で生成されたメッセージを上り通信としてメッセージ中継サーバ２に送信するための上り通信手段１０３と、メッセージ中継サーバ２に下り通信（キャッチアップ処理を行うためのリクエスト）を送信してメッセージを取得するための下り通信手段１０４と、取得したメッセージのメッセージ中継サーバ２上のキュー中の位置情報をそのメッセージを処理するアプリケーション１０１と関連（対応）づけて蓄積（記憶）するポインタ記憶手段１０５とを含む。なお、本実施形態において、上り通信とは、他のブラウザに対してメッセージを送信することであり、下り通信とは、他のブラウザからのメッセージを受信することである。
【００２６】
前述したＷｅｂブラウザ上で動作する各手段は、一般にＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）と呼ばれる記述方法で定義され、さらにはＪａｖａＳｃｒｉｐｔ、ＡｃｔｉｖｅＸ、Ｆｌａｓｈなどと一般的に呼称されるＷｅｂブラウザ上でプログラムを動作させる仕組みを用いて実装する。Ｊａｖａは、登録商標である。なお、以下、Ｗｅｂブラウザ１やアプリケーション１０１が処理を実行する、送受信する等の表現を用いるが、具体的には、Ｗｅｂブラウザを搭載した情報処理端末がＷｅｂブラウザやアプリケーション１０１に従って処理を実行することである。
【００２７】
メッセージ中継サーバ２は、具体的には、プログラムに従って動作する情報処理装置によって実現される。図１に示すように、メッセージ中継サーバ２は、セッション管理手段２０１と、メッセージ受信手段２０２と、メッセージ蓄積制御手段２０３と、キュー記憶手段２０４と、メッセージ送信手段２０５と、送信メッセージ選択手段２０６と、レスポンス情報記憶手段２０７と、レスポンス管理手段２０８とを含む。
【００２８】
セッション管理手段２０１は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵによって実現される。セッション管理手段２０１は、ユーザ同士の遠隔協働作業のセッションを管理し、そのセッションとキューとの関係を示す情報を保持（記憶又は管理）する機能を備えている。
【００２９】
メッセージ受信手段２０２は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵ及びネットワークインターフェース部によって実現される。メッセージ受信手段２０２は、利用者が操作するＷｅｂブラウザ１から上り通信を行うことによって送信されたメッセージを受信する機能を備えている。
【００３０】
メッセージ蓄積制御手段２０３は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵによって実現される。メッセージ蓄積制御手段２０３は、メッセージ受信手段２０２が受信したメッセージをキュー方式でキュー記憶手段２０４に記憶させる機能を備えている。
【００３１】
キュー記憶手段２０４は、具体的には、光ディスク装置や磁気ディスク装置などの記憶装置によって実現される。キュー記憶手段２０４は、セッション毎に用意されたキューを用いて実際にデータを記憶する。
【００３２】
メッセージ送信手段２０５は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵ及びネットワークインターフェース部によって実現される。メッセージ送信手段２０５は、Ｗｅｂブラウザから下り通信によりリクエストを受信して、リクエストで要求されたメッセージ又は既にキャッシュされているメッセージを取得するためのＵＲＬを返信する機能を備えている。
【００３３】
送信メッセージ選択手段２０６は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵによって実現される。送信メッセージ選択手段２０６は、Ｗｅｂブラウザ１から受信した下り通信によるリクエストに応じて、キュー記憶手段２０４に蓄積されたメッセージの中から、Ｗｅｂブラウザ１に返信するべきメッセージを検索して、キュー中の位置情報（例えば、シーケンス番号）と共にメッセージを取得（抽出）する機能を備えている。
【００３４】
レスポンス情報記憶手段２０７は、具体的には、光ディスク装置や磁気ディスク装置などの記憶装置によって実現される。レスポンス情報記憶手段２０７は、メッセージ送信手段２０５から送信されたメッセージのキュー中の位置情報（例えば、シーケンス番号）と、そのキューのセッションＩＤと、メッセージ送信手段２０５がＷｅｂブラウザから受信したリクエストＵＲＬとを対応づけてレスポンス情報として記憶する。
【００３５】
レスポンス管理手段２０８は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵによって実現される。レスポンス管理手段２０８は、Ｗｅｂブラウザからメッセージ取得のためのリクエストを受信した際に、該当するメッセージを既に送信済みかどうか判断し、送信済みの場合には、その時のリクエストＵＲＬを履歴ＵＲＬとしてメッセージ送信手段２０５に伝える（出力する）機能を備えている。
【００３６】
なお、図１では、２つのＷｅｂブラウザがメッセージ中継サーバに接続されているが、２つに限らず、例えば、３つ以上接続しても構わない。
【００３７】
次に、メッセージ送受信システムの動作について説明する。図３は、メッセージ中継サーバでのセッションの開始処理例を示す流れ図である。
【００３８】
最初に図３を用いてメッセージ中継サーバ２でのセッションの開始処理について述べる。例えば、遠隔会議をするために、ユーザがシステムを起動する操作を行うと、セッション管理手段２０１は、ユーザの操作に従って、ユーザ同士の遠隔協働作業のセッションを作成する。この時、セッション管理手段２０１は、セッションの開始方法として、任意の手法を用いて良い。例えば、セッション管理手段２０１と電話回線交換機とを接続し、電話による通話の開始をセッションの開始とし、通話者同士をセッションの参加者として構わない。また、別途Ｗｅｂブラウザとセッション管理手段２０１とを接続し、Ｗｅｂブラウザの操作によって、セッションの開始とセッションの参加者とを定義しても構わない。
【００３９】
次に、セッション管理手段２０１は、セッションを示すＩＤ（セッションＩＤ）とユーザを識別するためのＩＤ（ユーザＩＤ）とを関連（対応）づけて管理する。セッション管理手段２０１は、この関連づけを示す情報をセッション管理手段２０１で記憶しても構わないし、メッセージ中継サーバ２外のデータベースサーバといった別のサーバ上で記憶しても構わない。以下、セッション管理手段２０１が管理するセッションＩＤとユーザＩＤとの例を示す。
【００４０】
【表１】
【００４１】
表１に示す例では、「Ｕｓｅｒ１」及び「Ｕｓｅｒ２」が、セッション「０００００１」に参加しており、「Ａ」、「Ｂ」及び「Ｃ」が、セッション「０００００２」に参加している。
【００４２】
セッション管理手段２０１は、セッションを開始すると（ステップＳ１０１）、セッションＩＤに基づいて、そのセッションに対応したキューを作成し、作成したキューをキュー記憶手段２０４に記憶させる（ステップＳ１０２）。なお、本実施形態では、ステップＳ１０２でセッション管理手段２０１が作成するセッション毎にキュー方式でメッセージを格納するための箱（例えば、ファイルなど。なお、記憶装置内にキュー方式で記憶するための所定の記憶領域を確保したようなものでもよい）を単に「キュー」とも表現する。以下、この時作成されるキューの例を示す。
【００４３】
【表２】
【００４４】
表２は、セッションＩＤが”０００００１”で表されるセッションに対するキューの一例である。表２に示すキューの中の各行は、Ｗｅｂブラウザ上で動作するアプリケーションから送信されたメッセージを表す。
【００４５】
１列目のシーケンス番号は、該当するセッション中にメッセージ中継サーバで受信したメッセージの順番を示す。本実施形態では、このシーケンス番号に、０から始まり１ずつ増加する整数を用いる。
【００４６】
２列目の一時ＩＤは、メッセージを送信したＷｅｂブラウザ上で動作するアプリケーションを示すＩＤであり、詳細については後述する。
【００４７】
３列目のメッセージタイプは、そのメッセージを用いるアプリケーションの種別を表しており、任意の文字列を持つ。
【００４８】
４列目のメッセージ内容は、メッセージの本体であり、文字だけでなく任意のデータを値として持つ。表２に示す例では、シーケンス番号「０」のメッセージは、一時ＩＤ「Ａ０００１」を持つアプリケーションから送信されており、メッセージタイプが「ＣＨＡＴ」で、メッセージ内容として「ＨＥＬＬＯ」が指定されている。また、シーケンス番号「３」のメッセージは、一時ＩＤ「Ｂ０００１」を持つアプリケーションから送信されており、メッセージタイプが「ＦＩＬＥ」で、メッセージ内容として「ＦＩＬＥ＝ＢＣＤ．ＢＩＮ」が指定されている。
【００４９】
なお、表２では既にキュー中にメッセージが蓄積されているが、キューは、セッション管理手段２０１がキューを作成した初期段階では、メッセージを一つも含まない空の状態で作成される。
【００５０】
次に、図４を用いてアプリケーション処理開始時におけるＷｅｂブラウザ１での処理について述べる。図４は、アプリケーション処理開始時におけるＷｅｂブラウザでの処理例を示す流れ図である。
【００５１】
遠隔協動システム等に参加するために、ユーザがＷｅｂブラウザ１を起動する操作すると、Ｗｅｂブラウザ１は、ユーザの操作に従って、アプリケーション１０１、通信管理手段１０２、上り通信手段１０３、下り通信手段１０４及びポインタ記憶手段１０５を起動する（ステップＳ２０１）。
【００５２】
これらの起動については、一般的なＷｅｂブラウザと同様に、Ｗｅｂブラウザ１にＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を指定することで、指定したＵＲＬに関連づけられたＨＴＭＬが読み込まれ、ＨＴＭＬ上で定義された１０１〜１０５の各手段が動作する。この仕組みは通常のＷｅｂブラウザを利用した操作と同等であり、ここではその詳細を省略する。
【００５３】
次に、Ｗｅｂブラウザ１上で各手段（１０１〜１０５）が動作すると、通信管理手段１０２は、Ｗｅｂブラウザ１を利用しているユーザのユーザＩＤを取得する（ステップＳ２０２）。通信管理手段１０２がユーザＩＤを取得する方法として、例えば、ＨＴＭＬ中に記述されている文字列を取得（抽出）する方法や、Ｗｅｂブラウザに一般的に備えられているＣｏｏｋｉｅという仕組みを利用して取得する方法、ユーザに入力を促すなど多種の方法が考えられるが、取得可能であれば、どのような方法を用いてもよい。
【００５４】
次に、通信管理手段１０２は、Ｗｅｂブラウザ１上で動作するアプリケーションを初期化する。この時、通信管理手段１０２は、Ｗｅｂブラウザ１上で動作しているアプリケーション１０１を一意に識別するための一時ＩＤを作成する（ステップＳ２０３）。
【００５５】
そして、通信管理手段１０２は、作成した一時ＩＤを各アプリケーションに渡す（出力する）（ステップＳ２０４）。この一時ＩＤについては、各アプリケーションを識別できれば、どのような値を用いても構わない。
【００５６】
次に、各アプリケーション１０１は、通信管理手段１０２から出力された一時ＩＤをメモリ等の記憶装置に記憶させる。そして、各アプリケーション１０１は、それぞれ固有の初期化処理を実施して通信管理手段１０２に初期化の完了を通知すると共に、各アプリケーション１０１がそれぞれ使用するメッセージタイプを通知する（ステップＳ２０５）。このメッセージタイプは文字列であればどのようなものでも良い。ただし、異なるアプリケーション１０１間において、同じメッセージタイプを利用しないようにする。
【００５７】
次で、通信管理手段１０２は、メッセージタイプを受け取る（入力する）と、ポインタ記憶手段１０５に、メッセージタイプと各アプリケーション１０１の一時ＩＤと共に、初期ポイントとして「−１」を記憶させる（ステップＳ２０６）。以下、ポインタ記憶手段１０５に記憶させる情報の例を示す。
【００５８】
【表３】
【００５９】
表３に示す例は、メッセージタイプとして「ＣＨＡＴ」と「ＤＯＣ」とが登録されており、「ＣＨＡＴ」に対応する一時ＩＤが「Ａ０００１」であり、「ＤＯＣ」に対応する一時ＩＤが「Ａ０００２」であり、それぞれのポインタが「−１」であることを示している。
【００６０】
（上り通信）
次に、図５を用いて上り通信処理について説明する。図５は、Ｗｅｂブラウザ及びメッセージ中継サーバでの上り通信処理例を示す流れ図である。ユーザが、Ｗｅｂブラウザ１上で動作するアプリケーション１０１上においてメッセージを送信する操作を行うと、アプリケーション１０１は、ユーザの操作に従って、一時ＩＤ、自分のメッセージタイプ及びメッセージの内容を通信管理手段１０２に渡す（出力する）。そして、通信管理手段１０２は、ユーザＩＤ、一時ＩＤ、メッセージタイプ及びメッセージの内容を記述したＨＴＴＰを利用したリクエスト（以下、ＨＴＴＰリクエスト）を生成し、上り通信手段１０３を利用して、メッセージ中継サーバ２のメッセージ受信手段２０２に対して送信する。この時、上り通信手段１０３は、メッセージ送信する。以下、上り通信用のＨＴＴＰリクエストの例を示す。
【００６１】
ＰＯＳＴ ／Ｕｐ
ＵＩＤ＝Ｕｓｅｒ１＆ＭＴ＝ＣＨＡＴ＆ＴＩＤ＝Ｃ０００１＆ＭＳＧ＝こんばんは
【００６２】
上記の例は、メッセージ中継サーバ２のメッセージ受信手段２０２を示す「／Ｕｐ」に対して、ユーザＩＤとして「Ｕｓｅｒ１」、メッセージタイプとして「ＣＨＡＴ」、一時ＩＤとして「Ｃ０００１」、メッセージ内容として「こんばんは」を送信していることを示している。
【００６３】
メッセージ中継サーバ２のメッセージ受信手段２０２は、前述した上り通信用のＨＴＴＰリクエストを受信する（ステップＳ３０１）。
【００６４】
次に、メッセージ受信手段２０２は、受信したＨＴＴＰリクエストからユーザＩＤ、メッセージタイプ及び一時ＩＤを抽出して（ステップＳ３０２）、メッセージ蓄積制御手段２０３に渡す（出力する）。
【００６５】
次に、メッセージ蓄積制御手段２０３は、セッション管理手段２０１に問い合わせて、受け取った（受信した）ユーザＩＤが参加しているセッションのセッションＩＤを取得（例えば、セッション管理手段２０１が記憶部からユーザＩＤと対応づけて記憶されているセッションＩＤを抽出し、メッセージ蓄積制御手段２０３に出力する）する（ステップＳ３０３）。
【００６６】
次に、メッセージ蓄積制御手段２０３は、キュー記憶手段２０４から、取得したセッションＩＤと関連づけられているキューを取得（抽出）する（ステップＳ３０４）。
【００６７】
次に、メッセージ蓄積制御手段２０３は、取得（抽出）したキューに含まれるシーケンス番号のうち、最後の値（すなわち、一番大きな番号であり、時間的に新しいもの）を取得（抽出）する（ステップＳ３０５）。
【００６８】
次に、メッセージ蓄積制御手段２０３は、取得（抽出）したシーケンス番号に１を加える（ステップＳ３０６）。
【００６９】
次に、メッセージ蓄積制御手段２０３は、１を加えたシーケンス番号と、一時ＩＤ、メッセージタイプ及びメッセージ内容を、追加して、キュー記憶手段２０４が記憶するキューを更新する（ステップＳ３０７）。以下、更新後のキューを示す例を表４に示す。
【００７０】
【表４】
【００７１】
（下り通信）
次に、図６、図７、図８、図９及び図１０を用いて下り通信処理について述べる。図６は、Ｗｅｂブラウザでの下り通信処理例を示す流れ図である。図７は、メッセージ送信手段での処理例を示す流れ図である。図８は、送信メッセージ選択手段での処理例を示す流れ図である。図９は、メッセージ送信手段においてメッセージを返信する際のレスポンス管理手段での処理例を示す流れ図である。図１０は、履歴ＵＲＬを返信する時のレスポンス管理手段での処理例を示す流れ図である。例えば、セッションに遅れて参加した場合に、ユーザがキャッチアップを実行するための操作を行うと、Ｗｅｂブラウザ１の通信管理手段１０２は、下り通信手段１０４にユーザＩＤと共に、下り通信を開始する旨の指示を出力する（ステップＳ４０１）。
【００７２】
下り通信手段１０４は、まず履歴ＵＲＬ（詳細については後述する）の送信中かどうかを判断する（ステップＳ４０２）。
【００７３】
ステップＳ４０２において、履歴ＵＲＬを送信中であると判断した場合には、下り通信手段１０４は、その履歴ＵＲＬを用いて、さらにＨＴＴＰリクエストの付加情報としてユーザＩＤを指定して、下り通信用のＨＴＴＰリクエストを生成し、メッセージ中継サーバ２に送信する（ステップＳ４０３）。付加情報の指定方法として、任意のＨＴＴＰヘッダーを利用する方法や、Ｃｏｏｋｉｅを利用するなどの方法が考えられるが、以下に示す例では、Ｃｏｏｋｉｅを利用する方法を用いる。この時のＨＴＴＰリクエストは、例えば、下記に示す例のようになる（以下に示す例はＨＴＴＰリクエストの主要部分のみ記述）
【００７４】
ＧＥＴ／Ｄｏｗｎ？ＵＩＤ＝Ｕｓｅｒ１＆ＭＴ１＝ＣＨＡＴ＆ＴＩＤ１＝Ｃ０００１＆ＰＴ１＝−１＆ＭＴ２＝ＤＯＣ＆ＴＩＤ２＝Ｃ０００２＆ＰＴ２＝−１
Ｃｏｏｋｉｅ：ＵＩＤ＝Ｕｓｅｒ３
【００７５】
上記のＨＴＴＰリクエストは、ＵＲＬ中にメッセージ中継サーバ２のメッセージ送信手段２０５を示す「／Ｄｏｗｎ」と、ユーザＩＤとして「Ｕｓｅｒ１」とを含み、さらに、一つめのメッセージタイプ、一時ＩＤ及びポインタとして、「ＣＨＡＴ」、「Ｃ０００１」及び「−１」を含む。また、ＨＴＴＰリクエストは、二つめのメッセージタイプ、一時ＩＤ及びポインタとして、「ＤＯＣ」、「Ｃ０００２」及び「−１」を含む。また、ＣｏｏｋｉｅとしてユーザＩＤが「Ｕｓｅｒ３」であることを示している。
【００７６】
ステップＳ４０２において、履歴ＵＲＬを送信中でないと判断した場合には、所定期間経過後（ステップＳ４０４）、下り通信手段１０４は、ポインタ記憶手段１０５から、登録されているメッセージタイプとそれぞれのポインタとを取得（抽出）する（ステップＳ４０５）。
【００７７】
そして、下り通信手段１０４は、ステップＳ４０３と同じように、付加情報を追加して、下り通信用のＨＴＴＰリクエストを生成し、メッセージ中継サーバ２に送信する（ステップＳ４０６）。
【００７８】
次に、メッセージ中継サーバ２のメッセージ送信手段２０５は、前述した下り通信用のＨＴＴＰリクエストを受信する（ステップＳ５０１）。
【００７９】
次に、メッセージ送信手段２０５は、受信した下り通信用のＨＴＴＰリクエストから、ユーザＩＤ、メッセージタイプ、一時ＩＤ及びポインタをそれぞれ抽出する（ステップＳ５０２）。以下、下り通信用のＨＴＴＰリクエストに含まれるメッセージタイプ、一時ＩＤ、ポインタを、それぞれリクエストメッセージタイプ、リクエスト一時ＩＤ、リクエストポインタと呼ぶ。
【００８０】
次に、メッセージ送信手段２０５は、まずＣｏｏｋｉｅに指定されているユーザＩＤに基づいて、セッション管理手段２０１から該当するユーザＩＤが参加しているセッションのセッションＩＤを取得する（ステップＳ５０３）。
【００８１】
次に、メッセージ送信手段２０５は、ＵＲＬ中のユーザＩＤとＣｏｏｋｉｅのユーザＩＤとを比較する（ステップＳ５０４）。そして、このユーザＩＤが異なる場合、メッセージ送信手段２０５は、送信メッセージ選択手段２０６に対して、セッションＩＤ、リクエストメッセージタイプ、リクエスト一時ＩＤ及びリクエストポインタを渡す（出力する）。
【００８２】
次に、送信メッセージ選択手段２０６は、キュー記憶手段２０４から、メッセージ送信手段２０５から出力されたセッションＩＤと関連づけられているキューを取得（抽出）する（ステップＳ６０１）。
【００８３】
次に、送信メッセージ選択手段２０６は、メッセージ送信手段２０５から出力されたリクエストポインタの中で一番小さい値を取得ポインタとする（ステップＳ６０２）。
【００８４】
次に、送信メッセージ選択手段２０６は、取得ポインタが示す値よりも大きいシーケンス番号を持つメッセージが取得（抽出）したキューにあるか否かを判定する（ステップＳ６０３）。
【００８５】
該当するメッセージがあると判定した場合、送信メッセージ選択手段２０６は、取得ポインタに１を加え（ステップＳ６０４）、キューから、その取得ポインタと同じシーケンス番号のメッセージを取得（抽出）する（ステップＳ６０５）。
【００８６】
次に、送信メッセージ選択手段２０６は、取得（抽出）したメッセージのメッセージタイプが、リクエストメッセージタイプに含まれているか否かを判定する（ステップＳ６０６）。
【００８７】
ステップＳ６０６において、含まれていないと判定した場合には、送信メッセージ選択手段２０６は、ステップＳ６０３に処理を戻す。
【００８８】
一方、ステップ６０６において、含まれていると判定した場合には、送信メッセージ選択手段２０６は、リクエストメッセージタイプに対するリクエスト一時ＩＤと、取得（抽出）したメッセージの一時ＩＤと比較し、同一であるか否かを判定する（ステップＳ６０７）。
【００８９】
ステップＳ６０７において、同一であると判定した場合には、送信メッセージ選択手段２０６は、ステップＳ６０３に処理を戻す。
【００９０】
一方、ステップＳ６０７において、同一でないと判定した場合には、送信メッセージ選択手段２０６は、リクエストメッセージタイプに対するリクエストポインタと、取得（抽出）したメッセージのシーケンス番号とを比較し、リクエストポインタがシーケンス番号より小さいか否かを判定する（ステップＳ６０８）。
【００９１】
リクエストポインタよりシーケンス番号の方が小さいと判定した場合、又は、リクエストポインタとシーケンス番号とが同じ値であると判定した場合には、送信メッセージ選択手段２０６は、ステップＳ６０３に処理を戻す。
【００９２】
リクエストポインタよりシーケンス番号の方が大きい値であると判定した場合には、送信メッセージ選択手段２０６は、該当するシーケンス番号を選択シーケンス番号として記憶する（ステップＳ６０９）。その後、送信メッセージ選択手段２０６は、ステップＳ６０３に処理を戻す。
【００９３】
ステップＳ６０３において、取得ポインタよりも大きいシーケンス番号を持つメッセージがキューにない（ステップＳ６０４〜６０９の処理によってなくなった）と判定した場合、送信メッセージ選択手段２０６は、記憶している選択シーケンス番号があるか否かを判定する（ステップＳ６１０）。
【００９４】
ステップＳ６１０において、選択シーケンス番号が一つでもあると判定した場合には、送信メッセージ選択手段２０６は、記憶している選択シーケンス番号に該当するメッセージをキューから取得（抽出）し（ステップＳ６１１）、メッセージ送信手段２０５に渡す（出力する）。
【００９５】
一方、ステップＳ６１０において、選択シーケンス番号が一つもないと判定した場合には、送信メッセージ選択手段２０６は、何もメッセージ送信手段２０５に渡さない（出力しない）（ステップＳ６１２）。
【００９６】
次に、メッセージ送信手段２０５は、送信メッセージ選択手段２０６から出力されたメッセージがあるか否かを判定する（ステップＳ５０５）。
【００９７】
ステップＳ５０５において、出力されたメッセージがない、すなわち、下り通信用のＨＴＴＰリクエストに対するＨＴＴＰを利用したレスポンス（以下、ＨＴＴＰレスポンス）に対し、メッセージが一つもないと判定した場合には、メッセージ送信手段２０５は、Ｗｅｂブラウザ１に空のレスポンスを返す（送信する）（ステップＳ５０６）。
【００９８】
一方、ステップＳ５０５において、該当するメッセージがあると判定した場合には、メッセージ送信手段２０５は、シーケンス番号が小さい順にメッセージを並べ、それぞれのメッセージのシーケンス番号、メッセージタイプ及びメッセージ内容を含むＨＴＴＰレスポンスを生成し、Ｗｅｂブラウザ１に返す（送信する）（ステップＳ５０７）。この時、ＵＲＬ中のユーザＩＤとＣｏｏｋｉｅのユーザＩＤとが違っている場合には、メッセージ送信手段２０５は、ＨＴＴＰレスポンスに対し付加情報として、異なるユーザＩＤでのレスポンスを示すキャッシュミス文字列を挿入（付加）する（ステップＳ５０８）。これは、例えば、ＨＴＴＰヘッダーとして挿入（付加）することで実現できる。
【００９９】
例えば、キュー記憶手段２０４に表４に示すようなメッセージが蓄積されている場合に、前述した例のような下り通信用のリクエストを受信した場合には、送信メッセージ選択手段２０６が抽出する選択シーケンス番号は、「０」、「１」及び「２」となる。この時、Ｗｅｂブラウザ１に返される（送信される）メッセージは以下のようになる。
【０１００】
ＨＴＴＰ／１．１ ２００ ＯＫ
Ｘ−ＳＴＡＴＵＳ： ＩＤＩＬＬＥＧＡＬ
<−− 区切り −−>
０
ＣＨＡＴ
ＨＥＬＬＯ
<−− 区切り −−>
１
ＤＯＣ
ＦＩＬＥ＝ＡＢＣ．ＤＯＣ
<−− 区切り −−>
２
ＣＨＡＴ
こんにちは
<−− 区切り −−>
【０１０１】
上記の例において、「Ｘ−ＳＴＡＵＳ： ＩＤＩＬＬＥＧＡＬ」は、キャッシュミス文字列である。また、<−− 区切り −−>は、メッセージの区切りを表す文字列である。なお、この文字列に限らず、区切りであることがわかれば任意の文字列で構わない。
【０１０２】
さらに、メッセージ送信手段２０５は、Ｗｅｂブラウザ１に返した（送信した）メッセージの情報を、Ｗｅｂブラウザ１から送信されてきた下り通信用のＨＴＴＰリクエストのＵＲＬと共に、レスポンス管理手段２０８に渡す（出力する）。
【０１０３】
次に、レスポンス管理手段２０８は、セッションＩＤ、一時ＩＤ、メッセージのシーケンス番号及びメッセージタイプが同じである項目（レスポンス情報）が、レスポンス情報記憶手段２０７に既に記憶されているか否か判定する（Ｓ７０１）。
【０１０４】
同じものが記憶されていないと判定した場合には、レスポンス管理手段２０８は、レスポンス情報記憶手段２０７に、新しく項目を作成し、下り通信用のＨＴＴＰリクエストのＵＲＬと共に、レスポンス情報として記憶させる（ステップＳ７０２）。
【０１０５】
一方、同じものが記憶されていると判定した場合には、レスポンス管理手段２０８は、該当するレスポンス情報のうち、ＵＲＬの項目のみ新しいＵＲＬで書き換える（ステップＳ７０３）。以下にレスポンス情報記憶手段２０７が記憶する情報の例を示す。
【０１０６】
【表５】
【０１０７】
表５に示す例では、セッションＩＤ「０００００１」に対してシーケンス番号０，１，２のメッセージが返信されており、それぞれの一時ＩＤ及びメッセージタイプが表の値の通りである。表５に示す例では、シーケンス番号０及び１のメッセージがＷｅｂブラウザに返信された時のＵＲＬが、「／Ｄｏｗｎ？ＵＩＤ＝Ｕｓｅｒ２＆ＭＴ１＝ＣＨＡＴ＆ＴＩＤ１＝Ｂ０００１＆ＰＴ１＝−１＆ＭＴ２＝ＤＯＣ＆ＴＩＤ２＝Ｂ０００２＆ＰＴ２＝−１」であることを示している。また、シーケンス番号２のメッセージがＷｅｂブラウザに返信された時のＵＲＬが、「／Ｄｏｗｎ？ＵＩＤ＝Ｕｓｅｒ１＆ＭＴ１＝ＣＨＡＴ＆ＴＩＤ１＝Ａ０００１＆ＰＴ１＝１」であることを示している。
【０１０８】
また、表５に示す例では、セッションＩＤ「０００００２」に対してシーケンス番号０のメッセージが返信されており、その一時ＩＤが「Ｃ０００２」、メッセージタイプが「ＦＩＬＥ」であり、そのメッセージがＷｅｂブラウザに返信された時のＵＲＬが「／Ｄｏｗｎ？ＵＩＤ＝Ａ＆ＭＴ１＝ＦＩＬＥ＆ＴＩＤ１＝Ａ０１＆ＰＴ１＝−１」であることを示している。
【０１０９】
なお、レスポンス情報記憶手段２０７は、蓄積する下り通信用のＨＴＴＰリクエストに関する情報として、ＵＲＬ以外のリクエスト情報を蓄積しても構わない。また、レスポンス情報記憶手段２０７は、下り通信用のＨＴＴＰリクエストに関する情報として、例えば、受信した日時などを蓄積しても構わない。
【０１１０】
ステップＳ５０４において、ＣｏｏｋｉｅとＵＲＬとのユーザＩＤ指定が一致した場合、メッセージ送信手段２０５は、レスポンス管理手段２０８に対して、取得したセッションＩＤに関するレスポンス情報があるか否か確認する（ステップＳ５０９）。
【０１１１】
ステップＳ５０９において、レスポンス情報がないと判定した場合には、以降の処理は、ステップＳ６０１と同じである。
【０１１２】
一方、ステップＳ５０９において、レスポンス情報があると判定した場合、レスポンス管理手段２０８は、レスポンス情報記憶手段２０９が記憶するレスポンス情報のうち、取得したセッションＩＤを持つレスポンス情報を対象レスポンス情報として取得（抽出）する（ステップＳ８０１）。
【０１１３】
次に、レスポンス管理手段２０８は、受信したリクエストポインタの中で一番小さい値を取得ポインタとし（ステップＳ８０２）、取得ポインタが示す値よりも大きいシーケンス番号を持つレスポンス情報が対象レスポンス情報にあるか否かを判定する（ステップＳ８０３）。
【０１１４】
該当するレスポンス情報があると判定した場合には、レスポンス管理手段２０８は、取得ポインタに１を加え（ステップＳ８０４）、レスポンス情報記憶手段２０９から、その取得ポインタと同じレスポンス情報を取得（抽出）する（ステップＳ８０５）。レスポンス情報を取得（抽出）できない場合には、レスポンス管理手段２０８は、ステップＳ８０３に処理を戻す。
【０１１５】
取得（抽出）できた場合には、レスポンス管理手段２０８は、取得（抽出）したレスポンス情報のメッセージタイプが、リクエストメッセージタイプに含まれているか否か判定する（ステップＳ８０６）。
【０１１６】
含まれていないと判定した場合には、レスポンス管理手段２０８は、ステップＳ８０３に処理を戻す。一方、含まれていると判定した場合には、レスポンス管理手段２０８は、リクエストメッセージタイプに対するリクエスト一時ＩＤと、取得（抽出）したレスポンス情報の一時ＩＤと比較する。そして、レスポンス管理手段２０８は、リクエスト一時ＩＤとレスポンス情報の一時ＩＤとが同一であるか否か判定する（ステップＳ８０７）。
【０１１７】
ステップＳ８０７において、同一であると判定した場合には、レスポンス管理手段２０８は、ステップＳ８０３に処理を戻す。一方、同一でないと判定した場合には、レスポンス管理手段２０８は、リクエストメッセージタイプに対するリクエストポインタと、取得（抽出）したレスポンス情報のシーケンス番号とを比較する（ステップＳ８０８）。
【０１１８】
リクエストポインタよりシーケンス番号の方が小さい場合、又は同じ値である場合、レスポンス管理手段２０８は、ステップＳ８０３に処理を戻す。
【０１１９】
リクエストポインタよりシーケンス番号の方が大きい値である場合、レスポンス管理手段２０８は、取得（抽出）したレスポンス情報に含まれるＵＲＬを履歴ＵＲＬとして、そのシーケンス番号と対応付けて記憶する（ステップＳ８０９）。その後、レスポンス管理手段２０８は、ステップＳ８０３に処理を戻す。
【０１２０】
ステップＳ８０３において、取得ポインタよりも大きいシーケンス番号を持つレスポンス情報が対象レスポンス情報になくなったと判定した場合、レスポンス管理手段２０８は、記憶している履歴ＵＲＬがあるか否かを判定する（ステップＳ８１０）。あると判定した場合、レスポンス管理手段２０８は、記憶している履歴ＵＲＬをメッセージ送信手段２０５に渡す（出力する）（ステップＳ８１１）。一方、ないと判定した場合には、レスポン管理手段２０８は、何も返さない（出力しない）（ステップＳ８１２）。
【０１２１】
次に、メッセージ送信手段２０５は、レスポンス管理手段２０８から履歴ＵＲＬが返された（出力された）か否かを判定する（ステップＳ５１０）。返されて（出力されて）いないと判定した場合には、メッセージ送信手段２０５は、空のレスポンスをＷｅｂブラウザに返信する（ステップＳ５０６）。
【０１２２】
返されて（出力されて）いると判定した場合には、メッセージ送信手段２０５は、重複している履歴ＵＲＬを一つにまとめる（ステップＳ５１１）。そして、メッセージ送信手段２０５は、それらの履歴ＵＲＬ及びシーケンス番号から履歴ＵＲＬレスポンスを生成し、Ｗｅｂブラウザに返信する。例えば、Ｕｓｅｒ３のユーザＩＤを持つＷｅｂブラウザが、以下に示す下り通信用のＨＴＴＰリクエストを送信したとする。
【０１２３】
／Ｄｏｗｎ？ＵＩＤ＝Ｕｓｅｒ３＆ＭＴ１＝ＣＨＡＴ＆ＴＩＤ１＝Ａ０００１＆ＰＴ１＝−１＆ＭＴ２＝ＤＯＣ＆ＴＩＤ２＝Ａ０００２＆ＰＴ２＝−１
Ｃｏｏｋｉｅ： Ｕｓｅｒ３
【０１２４】
この時の履歴ＵＲＬレスポンスは以下のようになる。
【０１２５】
０，１：／Ｄｏｗｎ？ＵＩＤ＝Ｕｓｅｒ２＆ＭＴ１＝ＣＨＡＴ＆ＴＩＤ１＝Ｂ０００１＆ＰＴ１＝−１＆ＭＴ２＝ＤＯＣ＆ＴＩＤ２＝Ｂ０００２＆ＰＴ２＝−１
２：／Ｄｏｗｎ？ＵＩＤ＝Ｕｓｅｒ１＆ＭＴ１＝ＣＨＡＴ＆ＴＩＤ１＝Ａ０００１＆ＰＴ１＝１
【０１２６】
履歴ＵＲＬレスポンスは、各履歴ＵＲＬで取得できるメッセージのシーケンス番号と、そのＵＲＬ文字列とを含む。
【０１２７】
次に、Ｗｅｂブラウザ１の下り通信手段１０４は、ＨＴＴＰレスポンス（又は履歴ＵＲＬレスポンス）を受信する（ステップＳ４０７）。そして、下り通信手段１０４は、受信したレスポンスが空か（すなわち、メッセージも履歴ＵＲＬも含まれていない）否か判定する（ステップＳ４０８）。空であると判定すると、下り通信手段１０４は、ステップＳ４０２に処理を戻す。
【０１２８】
また、ＨＴＴＰレスポンス（又は履歴ＵＲＬレスポンス）が空でないと判定した場合、下り通信手段１０４は、ＨＴＴＰレスポンス（又は履歴ＵＲＬレスポンス）を解析して、メッセージが含まれているか、又は履歴ＵＲＬが含まれているか判別する（ステップＳ４０９）。
【０１２９】
メッセージが含まれていると判定した場合、下り通信手段１０４は、レスポンスからメッセージを一つずつ抽出し（ステップＳ４１０）、抽出したメッセージを通信管理手段１０８に渡す（出力する）。
【０１３０】
次に、通信管理手段１０８は、下り通信手段１０４から受け取った（出力された）メッセージのシーケンス番号及びメッセージタイプを取得（抽出）する。そして、通信管理手段１０８は、ポインタ記憶装置１０５に記憶されている同じメッセージタイプを持つポインタの値を、取得（抽出）シーケンス番号で書き換える（ステップＳ４１１）。以下、シーケンス番号が書き換えられたポインタ記憶手段１０５が記憶する情報の例について示す。
【０１３１】
【表６】
【０１３２】
次に、通信管理手段１０８は、ポインタ記憶装置１０５の同じ行に記憶されている一時ＩＤを取得（抽出）し、抽出した一時ＩＤを持つアプリケーションに対して、メッセージに含まれるメッセージ内容を渡す（出力する）（ステップＳ４１２）。そして、各アプリケーションは、メッセージの内容に従って、それぞれ処理を実行する。
【０１３３】
また、ステップＳ４０９において、履歴ＵＲＬが含まれている（すなわち、履歴ＵＲＬレスポンスを受信した）と判定した場合には、Ｗｅｂブラウザ１は、履歴ＵＲＬの送信を開始する（ステップＳ４１３）。その後、Ｗｅｂブラウザ１は、ステップＳ４０３以下を実行する。ただし、ステップＳ４１０において、履歴ＵＲＬレスポンスに含まれているシーケンス番号以外のメッセージを受信した場合には、Ｗｅｂブラウザ１は、それを除外する。
【０１３４】
この時、下り通信用のＨＴＴＰリクエストで示されるＵＲＬは、以前他のＷｅｂブラウザが送信したものである。そして、Ｗｅｂブラウザとメッセージ中継サーバとの間にプロキシサーバなどのキャッシュ装置が存在する場合、そこにリクエストに対するレスポンスがキャッシュされている可能性が高い。
【０１３５】
キャッシュ装置にキャッシュされている場合には、キャッシュ装置は、そのキャッシュに含まれるメッセージをＷｅｂブラウザに返信する。また、キャッシュに含まれていない場合には、メッセージ中継サーバにリクエストが送信される。この場合、ＵＲＬに含まれるユーザＩＤとＣｏｏｋｉｅのユーザＩＤとが異なるため、ステップＳ６０１以降の処理が実行され、メッセージがＷｅｂブラウザに返信される。
【０１３６】
そして、Ｗｅｂブラウザ１は、メッセージを取得（受信）すると、ステップＳ４１０以降の処理を実行し、メッセージをアプリケーションに渡す（出力する）。
【０１３７】
次に、Ｗｅｂブラウザ１は、この時に、受信したＨＴＴＰレスポンスの付加情報として、キャッシュミス文字列が指定されているか否かを判定する（ステップＳ４１４）。そして、指定されていないと判定した場合には、Ｗｅｂブラウザ１は、次の履歴ＵＲＬが指定されていれば、それに基づいて再度下り通信用のリクエストを送信する。一方、キャッシュミス文字列が指定されていると判定した場合には、Ｗｅｂブラウザ１は、履歴ＵＲＬの送信を停止し（ステップＳ４１５）、通常の処理に戻す。
【０１３８】
以上のように、本実施形態では、メッセージ中継サーバは、ＨＴＴＰリクエストに対応するＨＴＴＰレスポンスを、ＨＴＴＰリクエストに含まれるＵＲＬと対応づけて履歴情報としてレスポンス情報記憶手段２０７に記憶する。そして、メッセージ中継サーバは、Ｗｅｂブラウザから新たなＨＴＴＰリクエストを受信すると、受信したリクエストに対応するＨＴＴＰレスポンスと対応付けて記憶されているＵＲＬを抽出し、Ｗｅｂブラウザに返信する。そのため、Ｗｅｂブラウザがメッセージを取得する際に、返信されたＵＲＬを用いることで、キャッシュに蓄積されたメッセージを取得できるようになる。また、キャッシュを有効に利用することにより、メッセージ中継サーバにおいて、Ｗｅｂブラウザ１から受信したリクエストに応じてメッセージを抽出し、抽出したメッセージをＷｅｂブラウザ１に返信する処理を省略することができるため、負荷を減少させることが可能となる。
【０１３９】
次に、本発明によるメッセージ送受信システムの最小構成について説明する。図１１は、メッセージ送受信システムの最小の構成例を示すブロック図である。図１１に示すように、メッセージ送受信システムは、最小の構成要素として、レスポンス記憶手段１０、ＵＲＬ抽出手段２０及びリクエスト生成手段３０を含む。
【０１４０】
図１１に示す最小構成のメッセージ送受信システムでは、メッセージ取得用のリクエストに対するレスポンスとリクエストに含まれるＵＲＬとを対応づけて記憶するレスポンス記憶手段１０を備えている。そして、新たなリクエストを受信すると、ＵＲＬ抽出手段２０は、受信したリクエストに対応するレスポンスと対応づけられたＵＲＬをレスポンス記憶手段１０から抽出する。そして、リクエスト生成手段３０は、ＵＲＬ抽出手段２０が抽出したＵＲＬを用いて、メッセージ取得用のリクエストを生成する。
【０１４１】
従って、図１１に示す最小構成のメッセージ送受信システムによれば、キャッチアップ時に、過去にメッセージを取得したＵＲＬを用いることができるため、キャッシュに蓄積されたメッセージを取得することができる。また、このことによって、メッセージ中継サーバにおいて、Ｗｅｂブラウザから受信したリクエストに応じてメッセージを抽出し、抽出したメッセージをＷｅｂブラウザに返信する処理を省略することができるため、負荷を減少させることが可能となる。
【０１４２】
なお、本実施形態では、以下の（１）〜（８）に示すようなメッセージ送受信システムの特徴的構成が示されている。
【０１４３】
（１）メッセージ送受信システムは、複数のＷｅｂブラウザ（例えば、Ｗｅｂブラウザ１によって実現される）と、複数のＷｅｂブラウザ間でのメッセージの送受信を中継するメッセージ中継サーバ（例えば、メッセージ中継サーバ２によって実現される）とを備え、メッセージ中継サーバは、メッセージ取得用のリクエスト（例えば、ＨＴＴＰリクエストによって実現される）に対するレスポンス（例えば、セッションＩＤやシーケンス番号、一時ＩＤ、メッセージタイプ）とリクエストに含まれるＵＲＬ（例えば、履歴ＵＲＬとして記憶する）とを対応づけて記憶するレスポンス記憶手段（例えば、レスポンス情報記憶手段２０７によって実現される）と、新たなリクエストを受信すると、受信したリクエストに対応するレスポンスと対応づけられたＵＲＬをレスポンス記憶手段から抽出するＵＲＬ抽出手段（例えば、レスポンス管理手段２０８によって実現される）とを含み、ＵＲＬ抽出手段が抽出したＵＲＬを用いて、メッセージ取得用のリクエストを送信するリクエスト生成手段（例えば、下り通信手段１０４によって実現される）を備えたことを特徴とする。
【０１４４】
（２）メッセージ送受信システムにおいて、メッセージ中継サーバは、リクエストを受信すると、受信したリクエストに対応するレスポンスがレスポンス記憶手段に記憶されているか否かを判定する判定手段（例えば、レスポンス管理手段２０８によって実現される）と、判定手段が記憶されていないと判定すると、送信されたメッセージを記憶する記憶部（例えば、キュー記憶手段２０４によって実現される）から、受信したリクエストに基づいてメッセージを抽出するメッセージ抽出手段（例えば、送信メッセージ選択手段２０６によって実現される）とを含み、ＵＲＬ抽出手段は、判定手段が記憶されていると判定すると、受信したリクエストに対応するレスポンスと対応づけられたＵＲＬをレスポンス記憶手段から抽出するように構成されていてもよい。
【０１４５】
（３）メッセージ送受信システムは、ユーザ同士が遠隔で協働作業をするためのブラウザを搭載したユーザ端末と、ユーザ端末と通信するサーバ装置上に実装されたメッセージの送受信を中継するメッセージ中継サーバと、キャッシュ機能を有するプロキシサーバ（例えば、プロキシサーバ３によって実現される）とを備え、ユーザ端末は、協働作業をするための処理を実行するためのアプリケーション（例えば、アプリケーション１０１によって実現される）と、アプリケーションに従って実行される通信を制御する通信管理手段（例えば、通信管理手段１０２によって実現される）と、ユーザ端末が生成したメッセージをメッセージ送信要求（例えば、上り通信用のＨＴＴＰリクエスト）としてメッセージ中継サーバに送信する上り通信手段（例えば、上り通信手段１０３によって実現される）と、メッセージ中継サーバにメッセージ取得要求を送信して他のユーザ端末が生成したメッセージを受信する下り通信手段（例えば、下り通信手段１０４によって実現される）と、メッセージ中継サーバ上のキュー中の受信したメッセージが存在する一の位置情報（例えば、シーケンス番号）と、メッセージを処理するアプリケーションを特定する情報（例えば、一時ＩＤ）とを関連づけて記憶するポインタ記憶手段（例えば、ポインタ記憶手段１０５によって実現される）とを含み、メッセージ中継サーバは、ユーザ同士の遠隔協働作業のセッションを管理し、セッションとセッションにおけるキューとの関係を管理するセッション管理手段（例えば、セッション管理手段２０１によって実現される）と、ユーザ端末からメッセージ送信要求として送信されたメッセージを受信するメッセージ受信手段（例えば、メッセージ受信手段２０２によって実現される）と、メッセージをキューに蓄積するメッセージ蓄積制御手段（例えば、メッセージ蓄積制御手段２０３によって実現される）と、メッセージ蓄積制御手段に従って、セッション毎に用意されたキューにメッセージを記憶するキュー記憶手段（例えば、キュー記憶手段２０４によって実現される）と、ユーザ端末からのメッセージ取得要求を受信して、メッセージ取得要求で示されるメッセージ又は過去にメッセージを返信した時のメッセージ取得要求の内容（例えば、履歴ＵＲＬ）を返信するメッセージ送信手段（例えば、メッセージ送信手段２０５によって実現される）と、ユーザ端末からのメッセージ取得要求に応じて、キュー記憶手段に蓄積されたメッセージの中からユーザ端末に返信するべきメッセージを検索して、メッセージのメッセージ中継サーバ内での管理情報と共にメッセージを取得する送信メッセージ選択手段（例えば、送信メッセージ選択手段２０６によって実現される）と、メッセージ送信手段が送信したメッセージのメッセージ中継サーバ内での管理情報と、メッセージ送信手段が受信したユーザ端末からのメッセージ取得要求の内容とをレスポンス情報として記憶するレスポンス情報記憶手段（例えば、レスポンス情報記憶手段２０７によって実現される）と、ユーザ端末からメッセージ取得要求を受信する際、メッセージ取得要求で示されるメッセージを既に送信済みかどうか判断し、送信済みの場合には、メッセージ取得要求の内容をメッセージ送信手段に出力するレスポンス管理手段（例えば、レスポンス管理手段２０８によって実現される）とを含むことを特徴とする。
【０１４６】
（４）メッセージ送受信システムにおいて、メッセージ送信手段は、ユーザ端末からのメッセージ取得要求に対してメッセージを返信する際、メッセージのメッセージ中継サーバでの管理情報（例えば、セッションＩＤやシーケンス番号、一時ＩＤ、メッセージタイプ）と共にメッセージ取得要求の内容（例えば、ＵＲＬ）をレスポンス情報記憶手段に記憶させるように構成されていてもよい。
【０１４７】
（５）メッセージ送受信システムにおいて、レスポンス管理手段は、メッセージ送信手段においてユーザ端末からのメッセージ取得要求に対してメッセージを返信する際、取得要求されているメッセージが既に過去に返信されているか否かを判定し、過去に返信していると判定した場合、メッセージを返信した時に受信した下り通信要求の内容（例えば、履歴ＵＲＬ）を取得し、メッセージ送信手段は、レスポンス管理手段が取得したメッセージ取得要求の内容をユーザ端末に送信するように構成されていてもよい。
【０１４８】
（６）メッセージ送受信システムにおいて、下り通信手段は、メッセージ中継サーバからメッセージ取得要求の内容（例えば、履歴ＵＲＬ）が返信された場合、返信されたメッセージ取得要求の内容に従ってメッセージ取得要求を再度生成し、メッセージ取得要求にユーザ端末を操作しているユーザを示すユーザ情報（例えば、ユーザＩＤ）を付加情報として指定するように構成されていてもよい。
【０１４９】
（７）メッセージ送受信システムにおいて、メッセージ送信手段は、ユーザ端末からのメッセージ取得要求を受信した際、メッセージ取得要求の内容に含まれるユーザ情報とメッセージ取得要求に付加情報として指定されているユーザ情報とを比較し、ユーザ情報が合致しなければ、メッセージ蓄積制御手段によって蓄積されているメッセージを返信する際に、メッセージにキャッシュにミスしたことを示す付加情報（例えば、キャッシュミス文字列）を追加するように構成されていてもよい。
【０１５０】
（８）メッセージ送受信システムにおいて、下り通信手段は、メッセージ中継サーバからメッセージが返信されてきた場合、返信の付加情報にキャッシュに失敗したことを示す情報が付加されているか否かを確認し、付加されていれば、メッセージ中継サーバから取得したメッセージ取得要求の内容に従ったメッセージ取得要求の再生成を中止するように構成されていてもよい。
【産業上の利用可能性】
【０１５１】
本発明は、遠隔会議等をする用途に適用可能である。
【符号の説明】
【０１５２】
１ Ｗｅｂブラウザ
２ メッセージ中継サーバ
３ プロキシサーバ
１０ レスポンス記憶手段
２０ ＵＲＬ抽出手段
３０ リクエスト生成手段
１０１ アプリケーション
１０２ 通信管理手段
１０３ 上り通信手段
１０４ 下り通信手段
１０５ ポインタ記憶手段
２０１ セッション管理手段
２０２ メッセージ受信手段
２０３ メッセージ蓄積制御手段
２０４ キュー記憶手段
２０５ メッセージ送信手段
２０６ 送信メッセージ選択手段
２０７ レスポンス情報記憶手段
２０８ レスポンス管理手段
【技術分野】
【０００１】
本発明は、メッセージを送受信するメッセージ送受信システム、メッセージ送受信方法及びメッセージ送受信信用プログラムに関し、特にメッセージを中継できるメッセージ送受信システム、メッセージ送受信方法及びメッセージ送受信用プログラムに関する。また、本発明は、メッセージ送受信システムが備えるメッセージ中継サーバに関する。
【背景技術】
【０００２】
インターネットの発展により、一般の利用者が、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）上に配置されたＷｅｂページを、コンピュータ上で動作するＷｅｂブラウザを用いて閲覧することが、一般的に行われている。Ｗｅｂブラウザは、様々なコンピュータ上で実装されている。そのため、ユーザが、コンピュータとして一般的なＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）のみならず携帯電話機やゲーム端末、テレビジョン受信機、ビデオ機器などで簡単にＷｅｂブラウザを利用できるようになってきている。
【０００３】
また一般に、遠隔に離れたユーザ同士がネットワークを介して共同で作業を実施するための遠隔協働システムが提案されており、遠隔会議としてユーザ同士が同じ資料や図を同時に参照、描画したり、ファイルを互いに送受信したりするシステムが提案されている。このような遠隔会議システムでは、予めまたは一時的にユーザ同士がある期間一つのグループを形成する。そして、そのグループに属しているユーザ間で、各端末上で行った操作を操作メッセージとしてやりとりし、各端末で操作メッセージに対応した操作を再現することで遠隔での会議を実現している。また、このようなグループへの参加メンバ及び期間をセッションとして管理する。そして、セッションが継続している間はそのセッションに参加しているメンバが操作メッセージをやりとりできるように制御する。一般的にこのような遠隔協働システムにおいてユーザが利用する端末で動作を制御するプログラムは、上り通信として端末で行われた操作を、操作メッセージとして他の端末に送信するように制御する。そして、上記のプログラムは、逆に、下り通信を行うことによって他のプログラムから送信された操作メッセージを受信して、受信したメッセージに記述されている操作内容を自端末上で実行するように制御する。
【０００４】
このような遠隔協働システムとして、Ｗｅｂブラウザをクライアントプログラムとして用いた遠隔協働システムが提案されている。例えば、特許文献１に記載されたシステムでは、サーバ上に配置された表データが更新されるたびに、そのＵＲＬをメッセージとして各端末に送信する。そして、メッセージを受信した各端末がＷｅｂブラウザを用いてそのＵＲＬを表示することで、更新された表データを各ユーザに対して見せることができる。
【０００５】
また、特許文献２に記載されたシステムでは、Ｗｅｂブラウザで表示しているＷｅｂページに対してユーザが行ったスクロールやクリック、テキスト入力などの操作をメッセージとして他のＷｅｂブラウザ（具体的には、Ｗｅｂブラウザを搭載した端末）に送信する。そして、メッセージを受信した他のＷｅｂブラウザがそのメッセージに記述されている内容に従って操作を再現することで、Ｗｅｂブラウザに表示されるＷｅｂページを同期させている。
【０００６】
このようなＷｅｂブラウザを用いた遠隔協働システムにおいて、操作の同期を実現するためには、メッセージの送信処理（上り通信）及び受信処理（下り通信）をＷｅｂブラウザ上で実装する必要がある。この時、Ｗｅｂブラウザ同士で直接通信する機能がＷｅｂブラウザには備わっていないため、Ｗｅｂブラウザは必ずＷｅｂサーバと通信する必要がある。そして、このＷｅｂサーバ上にメッセージを中継する手段を実装することにより、Ｗｅｂブラウザ間のメッセージ交換が可能となる。
【０００７】
この時ＷｅｂブラウザとＷｅｂサーバとが通信するために利用するＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）プロトコルについては、Ｗｅｂブラウザがリクエストの送信元となる。そして、Ｗｅｂサーバは、Ｗｅｂブラウザからのリクエストを受け取ってから、そのリクエストに応じた処理を実施する。よって、前述したメッセージの上り、下り通信のうち、上り通信では、通常通りＷｅｂブラウザからのＨＴＴＰを利用したリクエスト（以下、ＨＴＴＰリクエスト）を用いればＷｅｂサーバに届けることが可能であるが、下り通信では、Ｗｅｂサーバから能動的にＷｅｂブラウザに向かって通信を開始する手段がないため、通常の手段では実現できない。
【０００８】
これを可能とするための手段として、特許文献２に記載されたシステムでは、永続的ポーリングという手法を提案している。これは、下り通信用にある間隔でＷｅｂブラウザからメッセージ中継用のサーバにリクエストを送信し、メッセージ中継サーバにメッセージが存在する場合に、そのレスポンスでメッセージを受信することで、完全なリアルタイムではないが、ある間隔の遅延をおいてメッセージを随時取得するという手法である。
【０００９】
また、遠隔協働システムにおいて動作しているセッションに対し、途中で新たにユーザがメンバとして加わった場合、新たに加わったメンバが操作するＷｅｂブラウザは、当該セッションに参加している他のメンバのＷｅｂブラウザと表示及び内部状態を合わせるため、キャッチアップと呼ぶ追随処理を実施する。これは当該セッションにおいてメッセージ中継サーバを介して送受信されたメッセージを最初から順に取得し、そのメッセージに従って操作を再現することで、他のメンバが操作するＷｅｂブラウザと表示及び内部状態を同一にすることで実現する。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００３−２５９３２３号公報
【特許文献２】特表２００２−５１４３３２号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
ある期間継続しているセッションがあり、そのセッションに参加しているユーザがＷｅｂブラウザの操作を繰り返した場合、当該セッションにおける送受信メッセージがメッセージ中継サーバに順次蓄積されていく。そして、当該セッションに対し新たにユーザが参加した場合、Ｗｅｂブラウザは、キャッチアップにより最初から順にメッセージ中継サーバからメッセージを取得するが、この時なるべく早期に他のブラウザと同じ状態に追いつく必要があるため、できる限りの早さでメッセージを連続して取得する。その際、メッセージ中継サーバには、一時的に通信と負荷とが集中することになり、全体的なパフォーマンスの低下やサービスの一時停止が発生する可能性がある。
【００１２】
これを回避するため、メッセージ中継サーバにおいてキャッシュを利用したり、メッセージ中継サーバとＷｅｂブラウザとの通信経路の途中にプロキシサーバを設置して、そのキャッシュを利用したりする。例えば、メッセージ中継サーバから一度送信されたメッセージをキャッシュ上に保存し、キャッチアップによる再度の取得時にそのキャッシュに保存されたメッセージを送信することによりメッセージ中継サーバの負荷を軽減するという方法が考えられる。
【００１３】
一般的にキャッシュは、リクエストの内容としてブラウザから送信されたＵＲＬとサーバから返信されたレスポンスとを関連づけて保存しておき、再度ブラウザから送信されたＵＲＬが以前に保存したＵＲＬと同じであれば、保存したレスポンスを即座に返信するという仕組みを持つ。
【００１４】
しかし、前述したようにＷｅｂブラウザによるメッセージ取得要求は、ポーリングによって実現される。通常ポーリングによるメッセージ取得要求は、Ｗｅｂブラウザからリクエストを送信する際、各リクエストのＵＲＬを以前に送信したリクエストとは異なるＵＲＬで送信される。これは、送信済みのリクエストと同じＵＲＬで送信した場合、前述したキャッシュにおいて過去のリクエストと同等であると判定され、メッセージ中継サーバにリクエストが到達せずにキャッシュに保存されたメッセージを返信し続けることとなる。そのため、メッセージ中継サーバにおいて新しいメッセージが蓄積されていても、それをＷｅｂブラウザに返信することができなくなるからである。
【００１５】
さらに、ポーリングによるメッセージ取得のリクエスト送信時にメッセージ中継サーバ側に送信すべき新規のメッセージがなかった場合、そのレスポンスは中身が空のものになり、ブラウザからの各リクエストに対して、全て意味のある返信が返されているとは限らない。
【００１６】
これにより、あるＷｅｂブラウザが他のＷｅｂブラウザが送信したリクエストのＵＲＬを知ることは一概には容易ではなく、また、例え知ることができたとしても、そのリクエストに対してメッセージ中継サーバからメッセージが返信されたかどうかを知ることができない。そのため、他のＷｅｂブラウザに対して返信されたメッセージがキャッシュに残っていたとしても、キャッチアップ時のＷｅｂブラウザが、キャッシュからメッセージを取得することは一概に容易ではない。
【００１７】
そこで、本発明は、Ｗｅｂブラウザがキャッチアップ時にキャッシュに保存されているメッセージを取得することができるメッセージ送受信システム、メッセージ送受信方法、メッセージ中継サーバ及びメッセージ送受信用プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１８】
本発明によるメッセージ送受信システムは、複数のブラウザを用いたメッセージの送受信を中継するメッセージ中継サーバを備え、メッセージ中継サーバは、メッセージ取得用のリクエストに対するレスポンスとリクエストに含まれるＵＲＬとを対応づけて記憶するレスポンス記憶手段と、新たなリクエストを受信すると、受信したリクエストに対応するレスポンスと対応づけられたＵＲＬをレスポンス記憶手段から抽出するＵＲＬ抽出手段とを含み、ＵＲＬ抽出手段が抽出したＵＲＬを用いて、メッセージ取得用のリクエストを生成するリクエスト生成手段を備えたことを特徴とする。
【００１９】
本発明によるメッセージ中継サーバは、複数のブラウザを用いたメッセージの送受信を中継するメッセージ中継サーバであって、メッセージ取得用のリクエストに対するレスポンスとリクエストに含まれるＵＲＬとを対応づけて記憶するレスポンス記憶手段と、新たなリクエストを受信すると、受信したリクエストに対応するレスポンスと対応づけられたＵＲＬをレスポンス記憶手段から抽出するＵＲＬ抽出手段とを備えたことを特徴とする。
【００２０】
本発明によるメッセージ送受信方法は、メッセージ取得用のリクエストに対するレスポンスとリクエストに含まれるＵＲＬとを対応づけて記憶部に記憶するレスポンス記憶ステップと、新たなリクエストを受信すると、受信したリクエストに対応するレスポンスと対応づけられたＵＲＬを記憶部から抽出するＵＲＬ抽出ステップと、抽出したＵＲＬを用いて、メッセージ取得用のリクエストを生成するリクエスト生成ステップとを含むことを特徴とする。
【００２１】
本発明によるメッセージ送受信用プログラムは、複数のブラウザを用いてメッセージの送受信を中継するコンピュータに、メッセージ取得用のリクエストに対するレスポンスとリクエストに含まれるＵＲＬとを対応づけて記憶部に記憶する記憶処理と、新たなリクエストを受信すると、受信したリクエストに対応するレスポンスと対応づけられたＵＲＬを記憶部から抽出するＵＲＬ抽出処理と、抽出したＵＲＬを用いて、メッセージ取得用のリクエストを生成するリクエスト生成処理とを実行させることを特徴とする。
【発明の効果】
【００２２】
本発明によれば、Ｗｅｂブラウザがキャッチアップ時にキャッシュに保存されているメッセージを取得することができる。
【図面の簡単な説明】
【００２３】
【図１】本発明によるメッセージ送受信システムの構成の一例を示すブロック図である。
【図２】Ｗｅｂブラウザを搭載したユーザ端末の構成の一例を示すブロック図である。
【図３】メッセージ中継サーバでのセッションの開始処理例を示す流れ図である。
【図４】アプリケーション処理開始時におけるＷｅｂブラウザでの処理例を示す流れ図である。
【図５】Ｗｅｂブラウザ及びメッセージ中継サーバでの上り通信処理例を示す流れ図である。
【図６】Ｗｅｂブラウザでの下り通信処理例を示す流れ図である。
【図７】メッセージ送信手段での処理例を示す流れ図である。
【図８】送信メッセージ選択手段での処理例を示す流れ図である。
【図９】メッセージ送信手段に置いてメッセージを返信する際のレスポンス管理手段での処理例を示す流れ図である。
【図１０】履歴ＵＲＬを返信する時のレスポンス管理手段での処理例を示す流れ図である。
【図１１】メッセージ送受信システムの最小の構成例を示すブロック図である。
【発明を実施するための形態】
【００２４】
以下、本発明の実施形態について図１及び図２を用いて説明する。図１は、本発明によるメッセージ送受信システムの構成の一例を示すブロック図である。図１に示すように、メッセージ送受信システムは、ユーザ同士が遠隔で協働作業をするためのユーザインターフェイスとして利用するＷｅｂブラウザ１と、前述したＨＴＴＰプロトコルを利用して、Ｗｅｂブラウザ間のメッセージの送受信を中継するＷｅｂサーバ上に実装されたメッセージ中継サーバ２と、一般的なキャッシュ機能を有するプロキシサーバ３とを含む。なお、プロキシサーバ３と同等のキャッシュ機能をメッセージ中継サーバ２が備えている場合には、プロキシサーバ３が無くても構わない。
【００２５】
Ｗｅｂブラウザ１は、具体的には、プログラムに従って動作するパーソナルコンピュータ等の情報処理装置に搭載される。図２は、Ｗｅｂブラウザを搭載したユーザ端末の構成の一例を示すブロック図である。図２に示すように、Ｗｅｂブラウザ１が搭載された端末は、協働作業をするための処理を実装した１つ又は複数のアプリケーション１０１と、Ｗｅｂブラウザ１上で動作するアプリケーション１０１が実施する通信を制御するための通信管理手段１０２と、アプリケーション１０１で生成されたメッセージを上り通信としてメッセージ中継サーバ２に送信するための上り通信手段１０３と、メッセージ中継サーバ２に下り通信（キャッチアップ処理を行うためのリクエスト）を送信してメッセージを取得するための下り通信手段１０４と、取得したメッセージのメッセージ中継サーバ２上のキュー中の位置情報をそのメッセージを処理するアプリケーション１０１と関連（対応）づけて蓄積（記憶）するポインタ記憶手段１０５とを含む。なお、本実施形態において、上り通信とは、他のブラウザに対してメッセージを送信することであり、下り通信とは、他のブラウザからのメッセージを受信することである。
【００２６】
前述したＷｅｂブラウザ上で動作する各手段は、一般にＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）と呼ばれる記述方法で定義され、さらにはＪａｖａＳｃｒｉｐｔ、ＡｃｔｉｖｅＸ、Ｆｌａｓｈなどと一般的に呼称されるＷｅｂブラウザ上でプログラムを動作させる仕組みを用いて実装する。Ｊａｖａは、登録商標である。なお、以下、Ｗｅｂブラウザ１やアプリケーション１０１が処理を実行する、送受信する等の表現を用いるが、具体的には、Ｗｅｂブラウザを搭載した情報処理端末がＷｅｂブラウザやアプリケーション１０１に従って処理を実行することである。
【００２７】
メッセージ中継サーバ２は、具体的には、プログラムに従って動作する情報処理装置によって実現される。図１に示すように、メッセージ中継サーバ２は、セッション管理手段２０１と、メッセージ受信手段２０２と、メッセージ蓄積制御手段２０３と、キュー記憶手段２０４と、メッセージ送信手段２０５と、送信メッセージ選択手段２０６と、レスポンス情報記憶手段２０７と、レスポンス管理手段２０８とを含む。
【００２８】
セッション管理手段２０１は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵによって実現される。セッション管理手段２０１は、ユーザ同士の遠隔協働作業のセッションを管理し、そのセッションとキューとの関係を示す情報を保持（記憶又は管理）する機能を備えている。
【００２９】
メッセージ受信手段２０２は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵ及びネットワークインターフェース部によって実現される。メッセージ受信手段２０２は、利用者が操作するＷｅｂブラウザ１から上り通信を行うことによって送信されたメッセージを受信する機能を備えている。
【００３０】
メッセージ蓄積制御手段２０３は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵによって実現される。メッセージ蓄積制御手段２０３は、メッセージ受信手段２０２が受信したメッセージをキュー方式でキュー記憶手段２０４に記憶させる機能を備えている。
【００３１】
キュー記憶手段２０４は、具体的には、光ディスク装置や磁気ディスク装置などの記憶装置によって実現される。キュー記憶手段２０４は、セッション毎に用意されたキューを用いて実際にデータを記憶する。
【００３２】
メッセージ送信手段２０５は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵ及びネットワークインターフェース部によって実現される。メッセージ送信手段２０５は、Ｗｅｂブラウザから下り通信によりリクエストを受信して、リクエストで要求されたメッセージ又は既にキャッシュされているメッセージを取得するためのＵＲＬを返信する機能を備えている。
【００３３】
送信メッセージ選択手段２０６は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵによって実現される。送信メッセージ選択手段２０６は、Ｗｅｂブラウザ１から受信した下り通信によるリクエストに応じて、キュー記憶手段２０４に蓄積されたメッセージの中から、Ｗｅｂブラウザ１に返信するべきメッセージを検索して、キュー中の位置情報（例えば、シーケンス番号）と共にメッセージを取得（抽出）する機能を備えている。
【００３４】
レスポンス情報記憶手段２０７は、具体的には、光ディスク装置や磁気ディスク装置などの記憶装置によって実現される。レスポンス情報記憶手段２０７は、メッセージ送信手段２０５から送信されたメッセージのキュー中の位置情報（例えば、シーケンス番号）と、そのキューのセッションＩＤと、メッセージ送信手段２０５がＷｅｂブラウザから受信したリクエストＵＲＬとを対応づけてレスポンス情報として記憶する。
【００３５】
レスポンス管理手段２０８は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵによって実現される。レスポンス管理手段２０８は、Ｗｅｂブラウザからメッセージ取得のためのリクエストを受信した際に、該当するメッセージを既に送信済みかどうか判断し、送信済みの場合には、その時のリクエストＵＲＬを履歴ＵＲＬとしてメッセージ送信手段２０５に伝える（出力する）機能を備えている。
【００３６】
なお、図１では、２つのＷｅｂブラウザがメッセージ中継サーバに接続されているが、２つに限らず、例えば、３つ以上接続しても構わない。
【００３７】
次に、メッセージ送受信システムの動作について説明する。図３は、メッセージ中継サーバでのセッションの開始処理例を示す流れ図である。
【００３８】
最初に図３を用いてメッセージ中継サーバ２でのセッションの開始処理について述べる。例えば、遠隔会議をするために、ユーザがシステムを起動する操作を行うと、セッション管理手段２０１は、ユーザの操作に従って、ユーザ同士の遠隔協働作業のセッションを作成する。この時、セッション管理手段２０１は、セッションの開始方法として、任意の手法を用いて良い。例えば、セッション管理手段２０１と電話回線交換機とを接続し、電話による通話の開始をセッションの開始とし、通話者同士をセッションの参加者として構わない。また、別途Ｗｅｂブラウザとセッション管理手段２０１とを接続し、Ｗｅｂブラウザの操作によって、セッションの開始とセッションの参加者とを定義しても構わない。
【００３９】
次に、セッション管理手段２０１は、セッションを示すＩＤ（セッションＩＤ）とユーザを識別するためのＩＤ（ユーザＩＤ）とを関連（対応）づけて管理する。セッション管理手段２０１は、この関連づけを示す情報をセッション管理手段２０１で記憶しても構わないし、メッセージ中継サーバ２外のデータベースサーバといった別のサーバ上で記憶しても構わない。以下、セッション管理手段２０１が管理するセッションＩＤとユーザＩＤとの例を示す。
【００４０】
【表１】
【００４１】
表１に示す例では、「Ｕｓｅｒ１」及び「Ｕｓｅｒ２」が、セッション「０００００１」に参加しており、「Ａ」、「Ｂ」及び「Ｃ」が、セッション「０００００２」に参加している。
【００４２】
セッション管理手段２０１は、セッションを開始すると（ステップＳ１０１）、セッションＩＤに基づいて、そのセッションに対応したキューを作成し、作成したキューをキュー記憶手段２０４に記憶させる（ステップＳ１０２）。なお、本実施形態では、ステップＳ１０２でセッション管理手段２０１が作成するセッション毎にキュー方式でメッセージを格納するための箱（例えば、ファイルなど。なお、記憶装置内にキュー方式で記憶するための所定の記憶領域を確保したようなものでもよい）を単に「キュー」とも表現する。以下、この時作成されるキューの例を示す。
【００４３】
【表２】
【００４４】
表２は、セッションＩＤが”０００００１”で表されるセッションに対するキューの一例である。表２に示すキューの中の各行は、Ｗｅｂブラウザ上で動作するアプリケーションから送信されたメッセージを表す。
【００４５】
１列目のシーケンス番号は、該当するセッション中にメッセージ中継サーバで受信したメッセージの順番を示す。本実施形態では、このシーケンス番号に、０から始まり１ずつ増加する整数を用いる。
【００４６】
２列目の一時ＩＤは、メッセージを送信したＷｅｂブラウザ上で動作するアプリケーションを示すＩＤであり、詳細については後述する。
【００４７】
３列目のメッセージタイプは、そのメッセージを用いるアプリケーションの種別を表しており、任意の文字列を持つ。
【００４８】
４列目のメッセージ内容は、メッセージの本体であり、文字だけでなく任意のデータを値として持つ。表２に示す例では、シーケンス番号「０」のメッセージは、一時ＩＤ「Ａ０００１」を持つアプリケーションから送信されており、メッセージタイプが「ＣＨＡＴ」で、メッセージ内容として「ＨＥＬＬＯ」が指定されている。また、シーケンス番号「３」のメッセージは、一時ＩＤ「Ｂ０００１」を持つアプリケーションから送信されており、メッセージタイプが「ＦＩＬＥ」で、メッセージ内容として「ＦＩＬＥ＝ＢＣＤ．ＢＩＮ」が指定されている。
【００４９】
なお、表２では既にキュー中にメッセージが蓄積されているが、キューは、セッション管理手段２０１がキューを作成した初期段階では、メッセージを一つも含まない空の状態で作成される。
【００５０】
次に、図４を用いてアプリケーション処理開始時におけるＷｅｂブラウザ１での処理について述べる。図４は、アプリケーション処理開始時におけるＷｅｂブラウザでの処理例を示す流れ図である。
【００５１】
遠隔協動システム等に参加するために、ユーザがＷｅｂブラウザ１を起動する操作すると、Ｗｅｂブラウザ１は、ユーザの操作に従って、アプリケーション１０１、通信管理手段１０２、上り通信手段１０３、下り通信手段１０４及びポインタ記憶手段１０５を起動する（ステップＳ２０１）。
【００５２】
これらの起動については、一般的なＷｅｂブラウザと同様に、Ｗｅｂブラウザ１にＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を指定することで、指定したＵＲＬに関連づけられたＨＴＭＬが読み込まれ、ＨＴＭＬ上で定義された１０１〜１０５の各手段が動作する。この仕組みは通常のＷｅｂブラウザを利用した操作と同等であり、ここではその詳細を省略する。
【００５３】
次に、Ｗｅｂブラウザ１上で各手段（１０１〜１０５）が動作すると、通信管理手段１０２は、Ｗｅｂブラウザ１を利用しているユーザのユーザＩＤを取得する（ステップＳ２０２）。通信管理手段１０２がユーザＩＤを取得する方法として、例えば、ＨＴＭＬ中に記述されている文字列を取得（抽出）する方法や、Ｗｅｂブラウザに一般的に備えられているＣｏｏｋｉｅという仕組みを利用して取得する方法、ユーザに入力を促すなど多種の方法が考えられるが、取得可能であれば、どのような方法を用いてもよい。
【００５４】
次に、通信管理手段１０２は、Ｗｅｂブラウザ１上で動作するアプリケーションを初期化する。この時、通信管理手段１０２は、Ｗｅｂブラウザ１上で動作しているアプリケーション１０１を一意に識別するための一時ＩＤを作成する（ステップＳ２０３）。
【００５５】
そして、通信管理手段１０２は、作成した一時ＩＤを各アプリケーションに渡す（出力する）（ステップＳ２０４）。この一時ＩＤについては、各アプリケーションを識別できれば、どのような値を用いても構わない。
【００５６】
次に、各アプリケーション１０１は、通信管理手段１０２から出力された一時ＩＤをメモリ等の記憶装置に記憶させる。そして、各アプリケーション１０１は、それぞれ固有の初期化処理を実施して通信管理手段１０２に初期化の完了を通知すると共に、各アプリケーション１０１がそれぞれ使用するメッセージタイプを通知する（ステップＳ２０５）。このメッセージタイプは文字列であればどのようなものでも良い。ただし、異なるアプリケーション１０１間において、同じメッセージタイプを利用しないようにする。
【００５７】
次で、通信管理手段１０２は、メッセージタイプを受け取る（入力する）と、ポインタ記憶手段１０５に、メッセージタイプと各アプリケーション１０１の一時ＩＤと共に、初期ポイントとして「−１」を記憶させる（ステップＳ２０６）。以下、ポインタ記憶手段１０５に記憶させる情報の例を示す。
【００５８】
【表３】
【００５９】
表３に示す例は、メッセージタイプとして「ＣＨＡＴ」と「ＤＯＣ」とが登録されており、「ＣＨＡＴ」に対応する一時ＩＤが「Ａ０００１」であり、「ＤＯＣ」に対応する一時ＩＤが「Ａ０００２」であり、それぞれのポインタが「−１」であることを示している。
【００６０】
（上り通信）
次に、図５を用いて上り通信処理について説明する。図５は、Ｗｅｂブラウザ及びメッセージ中継サーバでの上り通信処理例を示す流れ図である。ユーザが、Ｗｅｂブラウザ１上で動作するアプリケーション１０１上においてメッセージを送信する操作を行うと、アプリケーション１０１は、ユーザの操作に従って、一時ＩＤ、自分のメッセージタイプ及びメッセージの内容を通信管理手段１０２に渡す（出力する）。そして、通信管理手段１０２は、ユーザＩＤ、一時ＩＤ、メッセージタイプ及びメッセージの内容を記述したＨＴＴＰを利用したリクエスト（以下、ＨＴＴＰリクエスト）を生成し、上り通信手段１０３を利用して、メッセージ中継サーバ２のメッセージ受信手段２０２に対して送信する。この時、上り通信手段１０３は、メッセージ送信する。以下、上り通信用のＨＴＴＰリクエストの例を示す。
【００６１】
ＰＯＳＴ ／Ｕｐ
ＵＩＤ＝Ｕｓｅｒ１＆ＭＴ＝ＣＨＡＴ＆ＴＩＤ＝Ｃ０００１＆ＭＳＧ＝こんばんは
【００６２】
上記の例は、メッセージ中継サーバ２のメッセージ受信手段２０２を示す「／Ｕｐ」に対して、ユーザＩＤとして「Ｕｓｅｒ１」、メッセージタイプとして「ＣＨＡＴ」、一時ＩＤとして「Ｃ０００１」、メッセージ内容として「こんばんは」を送信していることを示している。
【００６３】
メッセージ中継サーバ２のメッセージ受信手段２０２は、前述した上り通信用のＨＴＴＰリクエストを受信する（ステップＳ３０１）。
【００６４】
次に、メッセージ受信手段２０２は、受信したＨＴＴＰリクエストからユーザＩＤ、メッセージタイプ及び一時ＩＤを抽出して（ステップＳ３０２）、メッセージ蓄積制御手段２０３に渡す（出力する）。
【００６５】
次に、メッセージ蓄積制御手段２０３は、セッション管理手段２０１に問い合わせて、受け取った（受信した）ユーザＩＤが参加しているセッションのセッションＩＤを取得（例えば、セッション管理手段２０１が記憶部からユーザＩＤと対応づけて記憶されているセッションＩＤを抽出し、メッセージ蓄積制御手段２０３に出力する）する（ステップＳ３０３）。
【００６６】
次に、メッセージ蓄積制御手段２０３は、キュー記憶手段２０４から、取得したセッションＩＤと関連づけられているキューを取得（抽出）する（ステップＳ３０４）。
【００６７】
次に、メッセージ蓄積制御手段２０３は、取得（抽出）したキューに含まれるシーケンス番号のうち、最後の値（すなわち、一番大きな番号であり、時間的に新しいもの）を取得（抽出）する（ステップＳ３０５）。
【００６８】
次に、メッセージ蓄積制御手段２０３は、取得（抽出）したシーケンス番号に１を加える（ステップＳ３０６）。
【００６９】
次に、メッセージ蓄積制御手段２０３は、１を加えたシーケンス番号と、一時ＩＤ、メッセージタイプ及びメッセージ内容を、追加して、キュー記憶手段２０４が記憶するキューを更新する（ステップＳ３０７）。以下、更新後のキューを示す例を表４に示す。
【００７０】
【表４】
【００７１】
（下り通信）
次に、図６、図７、図８、図９及び図１０を用いて下り通信処理について述べる。図６は、Ｗｅｂブラウザでの下り通信処理例を示す流れ図である。図７は、メッセージ送信手段での処理例を示す流れ図である。図８は、送信メッセージ選択手段での処理例を示す流れ図である。図９は、メッセージ送信手段においてメッセージを返信する際のレスポンス管理手段での処理例を示す流れ図である。図１０は、履歴ＵＲＬを返信する時のレスポンス管理手段での処理例を示す流れ図である。例えば、セッションに遅れて参加した場合に、ユーザがキャッチアップを実行するための操作を行うと、Ｗｅｂブラウザ１の通信管理手段１０２は、下り通信手段１０４にユーザＩＤと共に、下り通信を開始する旨の指示を出力する（ステップＳ４０１）。
【００７２】
下り通信手段１０４は、まず履歴ＵＲＬ（詳細については後述する）の送信中かどうかを判断する（ステップＳ４０２）。
【００７３】
ステップＳ４０２において、履歴ＵＲＬを送信中であると判断した場合には、下り通信手段１０４は、その履歴ＵＲＬを用いて、さらにＨＴＴＰリクエストの付加情報としてユーザＩＤを指定して、下り通信用のＨＴＴＰリクエストを生成し、メッセージ中継サーバ２に送信する（ステップＳ４０３）。付加情報の指定方法として、任意のＨＴＴＰヘッダーを利用する方法や、Ｃｏｏｋｉｅを利用するなどの方法が考えられるが、以下に示す例では、Ｃｏｏｋｉｅを利用する方法を用いる。この時のＨＴＴＰリクエストは、例えば、下記に示す例のようになる（以下に示す例はＨＴＴＰリクエストの主要部分のみ記述）
【００７４】
ＧＥＴ／Ｄｏｗｎ？ＵＩＤ＝Ｕｓｅｒ１＆ＭＴ１＝ＣＨＡＴ＆ＴＩＤ１＝Ｃ０００１＆ＰＴ１＝−１＆ＭＴ２＝ＤＯＣ＆ＴＩＤ２＝Ｃ０００２＆ＰＴ２＝−１
Ｃｏｏｋｉｅ：ＵＩＤ＝Ｕｓｅｒ３
【００７５】
上記のＨＴＴＰリクエストは、ＵＲＬ中にメッセージ中継サーバ２のメッセージ送信手段２０５を示す「／Ｄｏｗｎ」と、ユーザＩＤとして「Ｕｓｅｒ１」とを含み、さらに、一つめのメッセージタイプ、一時ＩＤ及びポインタとして、「ＣＨＡＴ」、「Ｃ０００１」及び「−１」を含む。また、ＨＴＴＰリクエストは、二つめのメッセージタイプ、一時ＩＤ及びポインタとして、「ＤＯＣ」、「Ｃ０００２」及び「−１」を含む。また、ＣｏｏｋｉｅとしてユーザＩＤが「Ｕｓｅｒ３」であることを示している。
【００７６】
ステップＳ４０２において、履歴ＵＲＬを送信中でないと判断した場合には、所定期間経過後（ステップＳ４０４）、下り通信手段１０４は、ポインタ記憶手段１０５から、登録されているメッセージタイプとそれぞれのポインタとを取得（抽出）する（ステップＳ４０５）。
【００７７】
そして、下り通信手段１０４は、ステップＳ４０３と同じように、付加情報を追加して、下り通信用のＨＴＴＰリクエストを生成し、メッセージ中継サーバ２に送信する（ステップＳ４０６）。
【００７８】
次に、メッセージ中継サーバ２のメッセージ送信手段２０５は、前述した下り通信用のＨＴＴＰリクエストを受信する（ステップＳ５０１）。
【００７９】
次に、メッセージ送信手段２０５は、受信した下り通信用のＨＴＴＰリクエストから、ユーザＩＤ、メッセージタイプ、一時ＩＤ及びポインタをそれぞれ抽出する（ステップＳ５０２）。以下、下り通信用のＨＴＴＰリクエストに含まれるメッセージタイプ、一時ＩＤ、ポインタを、それぞれリクエストメッセージタイプ、リクエスト一時ＩＤ、リクエストポインタと呼ぶ。
【００８０】
次に、メッセージ送信手段２０５は、まずＣｏｏｋｉｅに指定されているユーザＩＤに基づいて、セッション管理手段２０１から該当するユーザＩＤが参加しているセッションのセッションＩＤを取得する（ステップＳ５０３）。
【００８１】
次に、メッセージ送信手段２０５は、ＵＲＬ中のユーザＩＤとＣｏｏｋｉｅのユーザＩＤとを比較する（ステップＳ５０４）。そして、このユーザＩＤが異なる場合、メッセージ送信手段２０５は、送信メッセージ選択手段２０６に対して、セッションＩＤ、リクエストメッセージタイプ、リクエスト一時ＩＤ及びリクエストポインタを渡す（出力する）。
【００８２】
次に、送信メッセージ選択手段２０６は、キュー記憶手段２０４から、メッセージ送信手段２０５から出力されたセッションＩＤと関連づけられているキューを取得（抽出）する（ステップＳ６０１）。
【００８３】
次に、送信メッセージ選択手段２０６は、メッセージ送信手段２０５から出力されたリクエストポインタの中で一番小さい値を取得ポインタとする（ステップＳ６０２）。
【００８４】
次に、送信メッセージ選択手段２０６は、取得ポインタが示す値よりも大きいシーケンス番号を持つメッセージが取得（抽出）したキューにあるか否かを判定する（ステップＳ６０３）。
【００８５】
該当するメッセージがあると判定した場合、送信メッセージ選択手段２０６は、取得ポインタに１を加え（ステップＳ６０４）、キューから、その取得ポインタと同じシーケンス番号のメッセージを取得（抽出）する（ステップＳ６０５）。
【００８６】
次に、送信メッセージ選択手段２０６は、取得（抽出）したメッセージのメッセージタイプが、リクエストメッセージタイプに含まれているか否かを判定する（ステップＳ６０６）。
【００８７】
ステップＳ６０６において、含まれていないと判定した場合には、送信メッセージ選択手段２０６は、ステップＳ６０３に処理を戻す。
【００８８】
一方、ステップ６０６において、含まれていると判定した場合には、送信メッセージ選択手段２０６は、リクエストメッセージタイプに対するリクエスト一時ＩＤと、取得（抽出）したメッセージの一時ＩＤと比較し、同一であるか否かを判定する（ステップＳ６０７）。
【００８９】
ステップＳ６０７において、同一であると判定した場合には、送信メッセージ選択手段２０６は、ステップＳ６０３に処理を戻す。
【００９０】
一方、ステップＳ６０７において、同一でないと判定した場合には、送信メッセージ選択手段２０６は、リクエストメッセージタイプに対するリクエストポインタと、取得（抽出）したメッセージのシーケンス番号とを比較し、リクエストポインタがシーケンス番号より小さいか否かを判定する（ステップＳ６０８）。
【００９１】
リクエストポインタよりシーケンス番号の方が小さいと判定した場合、又は、リクエストポインタとシーケンス番号とが同じ値であると判定した場合には、送信メッセージ選択手段２０６は、ステップＳ６０３に処理を戻す。
【００９２】
リクエストポインタよりシーケンス番号の方が大きい値であると判定した場合には、送信メッセージ選択手段２０６は、該当するシーケンス番号を選択シーケンス番号として記憶する（ステップＳ６０９）。その後、送信メッセージ選択手段２０６は、ステップＳ６０３に処理を戻す。
【００９３】
ステップＳ６０３において、取得ポインタよりも大きいシーケンス番号を持つメッセージがキューにない（ステップＳ６０４〜６０９の処理によってなくなった）と判定した場合、送信メッセージ選択手段２０６は、記憶している選択シーケンス番号があるか否かを判定する（ステップＳ６１０）。
【００９４】
ステップＳ６１０において、選択シーケンス番号が一つでもあると判定した場合には、送信メッセージ選択手段２０６は、記憶している選択シーケンス番号に該当するメッセージをキューから取得（抽出）し（ステップＳ６１１）、メッセージ送信手段２０５に渡す（出力する）。
【００９５】
一方、ステップＳ６１０において、選択シーケンス番号が一つもないと判定した場合には、送信メッセージ選択手段２０６は、何もメッセージ送信手段２０５に渡さない（出力しない）（ステップＳ６１２）。
【００９６】
次に、メッセージ送信手段２０５は、送信メッセージ選択手段２０６から出力されたメッセージがあるか否かを判定する（ステップＳ５０５）。
【００９７】
ステップＳ５０５において、出力されたメッセージがない、すなわち、下り通信用のＨＴＴＰリクエストに対するＨＴＴＰを利用したレスポンス（以下、ＨＴＴＰレスポンス）に対し、メッセージが一つもないと判定した場合には、メッセージ送信手段２０５は、Ｗｅｂブラウザ１に空のレスポンスを返す（送信する）（ステップＳ５０６）。
【００９８】
一方、ステップＳ５０５において、該当するメッセージがあると判定した場合には、メッセージ送信手段２０５は、シーケンス番号が小さい順にメッセージを並べ、それぞれのメッセージのシーケンス番号、メッセージタイプ及びメッセージ内容を含むＨＴＴＰレスポンスを生成し、Ｗｅｂブラウザ１に返す（送信する）（ステップＳ５０７）。この時、ＵＲＬ中のユーザＩＤとＣｏｏｋｉｅのユーザＩＤとが違っている場合には、メッセージ送信手段２０５は、ＨＴＴＰレスポンスに対し付加情報として、異なるユーザＩＤでのレスポンスを示すキャッシュミス文字列を挿入（付加）する（ステップＳ５０８）。これは、例えば、ＨＴＴＰヘッダーとして挿入（付加）することで実現できる。
【００９９】
例えば、キュー記憶手段２０４に表４に示すようなメッセージが蓄積されている場合に、前述した例のような下り通信用のリクエストを受信した場合には、送信メッセージ選択手段２０６が抽出する選択シーケンス番号は、「０」、「１」及び「２」となる。この時、Ｗｅｂブラウザ１に返される（送信される）メッセージは以下のようになる。
【０１００】
ＨＴＴＰ／１．１ ２００ ＯＫ
Ｘ−ＳＴＡＴＵＳ： ＩＤＩＬＬＥＧＡＬ
<−− 区切り −−>
０
ＣＨＡＴ
ＨＥＬＬＯ
<−− 区切り −−>
１
ＤＯＣ
ＦＩＬＥ＝ＡＢＣ．ＤＯＣ
<−− 区切り −−>
２
ＣＨＡＴ
こんにちは
<−− 区切り −−>
【０１０１】
上記の例において、「Ｘ−ＳＴＡＵＳ： ＩＤＩＬＬＥＧＡＬ」は、キャッシュミス文字列である。また、<−− 区切り −−>は、メッセージの区切りを表す文字列である。なお、この文字列に限らず、区切りであることがわかれば任意の文字列で構わない。
【０１０２】
さらに、メッセージ送信手段２０５は、Ｗｅｂブラウザ１に返した（送信した）メッセージの情報を、Ｗｅｂブラウザ１から送信されてきた下り通信用のＨＴＴＰリクエストのＵＲＬと共に、レスポンス管理手段２０８に渡す（出力する）。
【０１０３】
次に、レスポンス管理手段２０８は、セッションＩＤ、一時ＩＤ、メッセージのシーケンス番号及びメッセージタイプが同じである項目（レスポンス情報）が、レスポンス情報記憶手段２０７に既に記憶されているか否か判定する（Ｓ７０１）。
【０１０４】
同じものが記憶されていないと判定した場合には、レスポンス管理手段２０８は、レスポンス情報記憶手段２０７に、新しく項目を作成し、下り通信用のＨＴＴＰリクエストのＵＲＬと共に、レスポンス情報として記憶させる（ステップＳ７０２）。
【０１０５】
一方、同じものが記憶されていると判定した場合には、レスポンス管理手段２０８は、該当するレスポンス情報のうち、ＵＲＬの項目のみ新しいＵＲＬで書き換える（ステップＳ７０３）。以下にレスポンス情報記憶手段２０７が記憶する情報の例を示す。
【０１０６】
【表５】
【０１０７】
表５に示す例では、セッションＩＤ「０００００１」に対してシーケンス番号０，１，２のメッセージが返信されており、それぞれの一時ＩＤ及びメッセージタイプが表の値の通りである。表５に示す例では、シーケンス番号０及び１のメッセージがＷｅｂブラウザに返信された時のＵＲＬが、「／Ｄｏｗｎ？ＵＩＤ＝Ｕｓｅｒ２＆ＭＴ１＝ＣＨＡＴ＆ＴＩＤ１＝Ｂ０００１＆ＰＴ１＝−１＆ＭＴ２＝ＤＯＣ＆ＴＩＤ２＝Ｂ０００２＆ＰＴ２＝−１」であることを示している。また、シーケンス番号２のメッセージがＷｅｂブラウザに返信された時のＵＲＬが、「／Ｄｏｗｎ？ＵＩＤ＝Ｕｓｅｒ１＆ＭＴ１＝ＣＨＡＴ＆ＴＩＤ１＝Ａ０００１＆ＰＴ１＝１」であることを示している。
【０１０８】
また、表５に示す例では、セッションＩＤ「０００００２」に対してシーケンス番号０のメッセージが返信されており、その一時ＩＤが「Ｃ０００２」、メッセージタイプが「ＦＩＬＥ」であり、そのメッセージがＷｅｂブラウザに返信された時のＵＲＬが「／Ｄｏｗｎ？ＵＩＤ＝Ａ＆ＭＴ１＝ＦＩＬＥ＆ＴＩＤ１＝Ａ０１＆ＰＴ１＝−１」であることを示している。
【０１０９】
なお、レスポンス情報記憶手段２０７は、蓄積する下り通信用のＨＴＴＰリクエストに関する情報として、ＵＲＬ以外のリクエスト情報を蓄積しても構わない。また、レスポンス情報記憶手段２０７は、下り通信用のＨＴＴＰリクエストに関する情報として、例えば、受信した日時などを蓄積しても構わない。
【０１１０】
ステップＳ５０４において、ＣｏｏｋｉｅとＵＲＬとのユーザＩＤ指定が一致した場合、メッセージ送信手段２０５は、レスポンス管理手段２０８に対して、取得したセッションＩＤに関するレスポンス情報があるか否か確認する（ステップＳ５０９）。
【０１１１】
ステップＳ５０９において、レスポンス情報がないと判定した場合には、以降の処理は、ステップＳ６０１と同じである。
【０１１２】
一方、ステップＳ５０９において、レスポンス情報があると判定した場合、レスポンス管理手段２０８は、レスポンス情報記憶手段２０９が記憶するレスポンス情報のうち、取得したセッションＩＤを持つレスポンス情報を対象レスポンス情報として取得（抽出）する（ステップＳ８０１）。
【０１１３】
次に、レスポンス管理手段２０８は、受信したリクエストポインタの中で一番小さい値を取得ポインタとし（ステップＳ８０２）、取得ポインタが示す値よりも大きいシーケンス番号を持つレスポンス情報が対象レスポンス情報にあるか否かを判定する（ステップＳ８０３）。
【０１１４】
該当するレスポンス情報があると判定した場合には、レスポンス管理手段２０８は、取得ポインタに１を加え（ステップＳ８０４）、レスポンス情報記憶手段２０９から、その取得ポインタと同じレスポンス情報を取得（抽出）する（ステップＳ８０５）。レスポンス情報を取得（抽出）できない場合には、レスポンス管理手段２０８は、ステップＳ８０３に処理を戻す。
【０１１５】
取得（抽出）できた場合には、レスポンス管理手段２０８は、取得（抽出）したレスポンス情報のメッセージタイプが、リクエストメッセージタイプに含まれているか否か判定する（ステップＳ８０６）。
【０１１６】
含まれていないと判定した場合には、レスポンス管理手段２０８は、ステップＳ８０３に処理を戻す。一方、含まれていると判定した場合には、レスポンス管理手段２０８は、リクエストメッセージタイプに対するリクエスト一時ＩＤと、取得（抽出）したレスポンス情報の一時ＩＤと比較する。そして、レスポンス管理手段２０８は、リクエスト一時ＩＤとレスポンス情報の一時ＩＤとが同一であるか否か判定する（ステップＳ８０７）。
【０１１７】
ステップＳ８０７において、同一であると判定した場合には、レスポンス管理手段２０８は、ステップＳ８０３に処理を戻す。一方、同一でないと判定した場合には、レスポンス管理手段２０８は、リクエストメッセージタイプに対するリクエストポインタと、取得（抽出）したレスポンス情報のシーケンス番号とを比較する（ステップＳ８０８）。
【０１１８】
リクエストポインタよりシーケンス番号の方が小さい場合、又は同じ値である場合、レスポンス管理手段２０８は、ステップＳ８０３に処理を戻す。
【０１１９】
リクエストポインタよりシーケンス番号の方が大きい値である場合、レスポンス管理手段２０８は、取得（抽出）したレスポンス情報に含まれるＵＲＬを履歴ＵＲＬとして、そのシーケンス番号と対応付けて記憶する（ステップＳ８０９）。その後、レスポンス管理手段２０８は、ステップＳ８０３に処理を戻す。
【０１２０】
ステップＳ８０３において、取得ポインタよりも大きいシーケンス番号を持つレスポンス情報が対象レスポンス情報になくなったと判定した場合、レスポンス管理手段２０８は、記憶している履歴ＵＲＬがあるか否かを判定する（ステップＳ８１０）。あると判定した場合、レスポンス管理手段２０８は、記憶している履歴ＵＲＬをメッセージ送信手段２０５に渡す（出力する）（ステップＳ８１１）。一方、ないと判定した場合には、レスポン管理手段２０８は、何も返さない（出力しない）（ステップＳ８１２）。
【０１２１】
次に、メッセージ送信手段２０５は、レスポンス管理手段２０８から履歴ＵＲＬが返された（出力された）か否かを判定する（ステップＳ５１０）。返されて（出力されて）いないと判定した場合には、メッセージ送信手段２０５は、空のレスポンスをＷｅｂブラウザに返信する（ステップＳ５０６）。
【０１２２】
返されて（出力されて）いると判定した場合には、メッセージ送信手段２０５は、重複している履歴ＵＲＬを一つにまとめる（ステップＳ５１１）。そして、メッセージ送信手段２０５は、それらの履歴ＵＲＬ及びシーケンス番号から履歴ＵＲＬレスポンスを生成し、Ｗｅｂブラウザに返信する。例えば、Ｕｓｅｒ３のユーザＩＤを持つＷｅｂブラウザが、以下に示す下り通信用のＨＴＴＰリクエストを送信したとする。
【０１２３】
／Ｄｏｗｎ？ＵＩＤ＝Ｕｓｅｒ３＆ＭＴ１＝ＣＨＡＴ＆ＴＩＤ１＝Ａ０００１＆ＰＴ１＝−１＆ＭＴ２＝ＤＯＣ＆ＴＩＤ２＝Ａ０００２＆ＰＴ２＝−１
Ｃｏｏｋｉｅ： Ｕｓｅｒ３
【０１２４】
この時の履歴ＵＲＬレスポンスは以下のようになる。
【０１２５】
０，１：／Ｄｏｗｎ？ＵＩＤ＝Ｕｓｅｒ２＆ＭＴ１＝ＣＨＡＴ＆ＴＩＤ１＝Ｂ０００１＆ＰＴ１＝−１＆ＭＴ２＝ＤＯＣ＆ＴＩＤ２＝Ｂ０００２＆ＰＴ２＝−１
２：／Ｄｏｗｎ？ＵＩＤ＝Ｕｓｅｒ１＆ＭＴ１＝ＣＨＡＴ＆ＴＩＤ１＝Ａ０００１＆ＰＴ１＝１
【０１２６】
履歴ＵＲＬレスポンスは、各履歴ＵＲＬで取得できるメッセージのシーケンス番号と、そのＵＲＬ文字列とを含む。
【０１２７】
次に、Ｗｅｂブラウザ１の下り通信手段１０４は、ＨＴＴＰレスポンス（又は履歴ＵＲＬレスポンス）を受信する（ステップＳ４０７）。そして、下り通信手段１０４は、受信したレスポンスが空か（すなわち、メッセージも履歴ＵＲＬも含まれていない）否か判定する（ステップＳ４０８）。空であると判定すると、下り通信手段１０４は、ステップＳ４０２に処理を戻す。
【０１２８】
また、ＨＴＴＰレスポンス（又は履歴ＵＲＬレスポンス）が空でないと判定した場合、下り通信手段１０４は、ＨＴＴＰレスポンス（又は履歴ＵＲＬレスポンス）を解析して、メッセージが含まれているか、又は履歴ＵＲＬが含まれているか判別する（ステップＳ４０９）。
【０１２９】
メッセージが含まれていると判定した場合、下り通信手段１０４は、レスポンスからメッセージを一つずつ抽出し（ステップＳ４１０）、抽出したメッセージを通信管理手段１０８に渡す（出力する）。
【０１３０】
次に、通信管理手段１０８は、下り通信手段１０４から受け取った（出力された）メッセージのシーケンス番号及びメッセージタイプを取得（抽出）する。そして、通信管理手段１０８は、ポインタ記憶装置１０５に記憶されている同じメッセージタイプを持つポインタの値を、取得（抽出）シーケンス番号で書き換える（ステップＳ４１１）。以下、シーケンス番号が書き換えられたポインタ記憶手段１０５が記憶する情報の例について示す。
【０１３１】
【表６】
【０１３２】
次に、通信管理手段１０８は、ポインタ記憶装置１０５の同じ行に記憶されている一時ＩＤを取得（抽出）し、抽出した一時ＩＤを持つアプリケーションに対して、メッセージに含まれるメッセージ内容を渡す（出力する）（ステップＳ４１２）。そして、各アプリケーションは、メッセージの内容に従って、それぞれ処理を実行する。
【０１３３】
また、ステップＳ４０９において、履歴ＵＲＬが含まれている（すなわち、履歴ＵＲＬレスポンスを受信した）と判定した場合には、Ｗｅｂブラウザ１は、履歴ＵＲＬの送信を開始する（ステップＳ４１３）。その後、Ｗｅｂブラウザ１は、ステップＳ４０３以下を実行する。ただし、ステップＳ４１０において、履歴ＵＲＬレスポンスに含まれているシーケンス番号以外のメッセージを受信した場合には、Ｗｅｂブラウザ１は、それを除外する。
【０１３４】
この時、下り通信用のＨＴＴＰリクエストで示されるＵＲＬは、以前他のＷｅｂブラウザが送信したものである。そして、Ｗｅｂブラウザとメッセージ中継サーバとの間にプロキシサーバなどのキャッシュ装置が存在する場合、そこにリクエストに対するレスポンスがキャッシュされている可能性が高い。
【０１３５】
キャッシュ装置にキャッシュされている場合には、キャッシュ装置は、そのキャッシュに含まれるメッセージをＷｅｂブラウザに返信する。また、キャッシュに含まれていない場合には、メッセージ中継サーバにリクエストが送信される。この場合、ＵＲＬに含まれるユーザＩＤとＣｏｏｋｉｅのユーザＩＤとが異なるため、ステップＳ６０１以降の処理が実行され、メッセージがＷｅｂブラウザに返信される。
【０１３６】
そして、Ｗｅｂブラウザ１は、メッセージを取得（受信）すると、ステップＳ４１０以降の処理を実行し、メッセージをアプリケーションに渡す（出力する）。
【０１３７】
次に、Ｗｅｂブラウザ１は、この時に、受信したＨＴＴＰレスポンスの付加情報として、キャッシュミス文字列が指定されているか否かを判定する（ステップＳ４１４）。そして、指定されていないと判定した場合には、Ｗｅｂブラウザ１は、次の履歴ＵＲＬが指定されていれば、それに基づいて再度下り通信用のリクエストを送信する。一方、キャッシュミス文字列が指定されていると判定した場合には、Ｗｅｂブラウザ１は、履歴ＵＲＬの送信を停止し（ステップＳ４１５）、通常の処理に戻す。
【０１３８】
以上のように、本実施形態では、メッセージ中継サーバは、ＨＴＴＰリクエストに対応するＨＴＴＰレスポンスを、ＨＴＴＰリクエストに含まれるＵＲＬと対応づけて履歴情報としてレスポンス情報記憶手段２０７に記憶する。そして、メッセージ中継サーバは、Ｗｅｂブラウザから新たなＨＴＴＰリクエストを受信すると、受信したリクエストに対応するＨＴＴＰレスポンスと対応付けて記憶されているＵＲＬを抽出し、Ｗｅｂブラウザに返信する。そのため、Ｗｅｂブラウザがメッセージを取得する際に、返信されたＵＲＬを用いることで、キャッシュに蓄積されたメッセージを取得できるようになる。また、キャッシュを有効に利用することにより、メッセージ中継サーバにおいて、Ｗｅｂブラウザ１から受信したリクエストに応じてメッセージを抽出し、抽出したメッセージをＷｅｂブラウザ１に返信する処理を省略することができるため、負荷を減少させることが可能となる。
【０１３９】
次に、本発明によるメッセージ送受信システムの最小構成について説明する。図１１は、メッセージ送受信システムの最小の構成例を示すブロック図である。図１１に示すように、メッセージ送受信システムは、最小の構成要素として、レスポンス記憶手段１０、ＵＲＬ抽出手段２０及びリクエスト生成手段３０を含む。
【０１４０】
図１１に示す最小構成のメッセージ送受信システムでは、メッセージ取得用のリクエストに対するレスポンスとリクエストに含まれるＵＲＬとを対応づけて記憶するレスポンス記憶手段１０を備えている。そして、新たなリクエストを受信すると、ＵＲＬ抽出手段２０は、受信したリクエストに対応するレスポンスと対応づけられたＵＲＬをレスポンス記憶手段１０から抽出する。そして、リクエスト生成手段３０は、ＵＲＬ抽出手段２０が抽出したＵＲＬを用いて、メッセージ取得用のリクエストを生成する。
【０１４１】
従って、図１１に示す最小構成のメッセージ送受信システムによれば、キャッチアップ時に、過去にメッセージを取得したＵＲＬを用いることができるため、キャッシュに蓄積されたメッセージを取得することができる。また、このことによって、メッセージ中継サーバにおいて、Ｗｅｂブラウザから受信したリクエストに応じてメッセージを抽出し、抽出したメッセージをＷｅｂブラウザに返信する処理を省略することができるため、負荷を減少させることが可能となる。
【０１４２】
なお、本実施形態では、以下の（１）〜（８）に示すようなメッセージ送受信システムの特徴的構成が示されている。
【０１４３】
（１）メッセージ送受信システムは、複数のＷｅｂブラウザ（例えば、Ｗｅｂブラウザ１によって実現される）と、複数のＷｅｂブラウザ間でのメッセージの送受信を中継するメッセージ中継サーバ（例えば、メッセージ中継サーバ２によって実現される）とを備え、メッセージ中継サーバは、メッセージ取得用のリクエスト（例えば、ＨＴＴＰリクエストによって実現される）に対するレスポンス（例えば、セッションＩＤやシーケンス番号、一時ＩＤ、メッセージタイプ）とリクエストに含まれるＵＲＬ（例えば、履歴ＵＲＬとして記憶する）とを対応づけて記憶するレスポンス記憶手段（例えば、レスポンス情報記憶手段２０７によって実現される）と、新たなリクエストを受信すると、受信したリクエストに対応するレスポンスと対応づけられたＵＲＬをレスポンス記憶手段から抽出するＵＲＬ抽出手段（例えば、レスポンス管理手段２０８によって実現される）とを含み、ＵＲＬ抽出手段が抽出したＵＲＬを用いて、メッセージ取得用のリクエストを送信するリクエスト生成手段（例えば、下り通信手段１０４によって実現される）を備えたことを特徴とする。
【０１４４】
（２）メッセージ送受信システムにおいて、メッセージ中継サーバは、リクエストを受信すると、受信したリクエストに対応するレスポンスがレスポンス記憶手段に記憶されているか否かを判定する判定手段（例えば、レスポンス管理手段２０８によって実現される）と、判定手段が記憶されていないと判定すると、送信されたメッセージを記憶する記憶部（例えば、キュー記憶手段２０４によって実現される）から、受信したリクエストに基づいてメッセージを抽出するメッセージ抽出手段（例えば、送信メッセージ選択手段２０６によって実現される）とを含み、ＵＲＬ抽出手段は、判定手段が記憶されていると判定すると、受信したリクエストに対応するレスポンスと対応づけられたＵＲＬをレスポンス記憶手段から抽出するように構成されていてもよい。
【０１４５】
（３）メッセージ送受信システムは、ユーザ同士が遠隔で協働作業をするためのブラウザを搭載したユーザ端末と、ユーザ端末と通信するサーバ装置上に実装されたメッセージの送受信を中継するメッセージ中継サーバと、キャッシュ機能を有するプロキシサーバ（例えば、プロキシサーバ３によって実現される）とを備え、ユーザ端末は、協働作業をするための処理を実行するためのアプリケーション（例えば、アプリケーション１０１によって実現される）と、アプリケーションに従って実行される通信を制御する通信管理手段（例えば、通信管理手段１０２によって実現される）と、ユーザ端末が生成したメッセージをメッセージ送信要求（例えば、上り通信用のＨＴＴＰリクエスト）としてメッセージ中継サーバに送信する上り通信手段（例えば、上り通信手段１０３によって実現される）と、メッセージ中継サーバにメッセージ取得要求を送信して他のユーザ端末が生成したメッセージを受信する下り通信手段（例えば、下り通信手段１０４によって実現される）と、メッセージ中継サーバ上のキュー中の受信したメッセージが存在する一の位置情報（例えば、シーケンス番号）と、メッセージを処理するアプリケーションを特定する情報（例えば、一時ＩＤ）とを関連づけて記憶するポインタ記憶手段（例えば、ポインタ記憶手段１０５によって実現される）とを含み、メッセージ中継サーバは、ユーザ同士の遠隔協働作業のセッションを管理し、セッションとセッションにおけるキューとの関係を管理するセッション管理手段（例えば、セッション管理手段２０１によって実現される）と、ユーザ端末からメッセージ送信要求として送信されたメッセージを受信するメッセージ受信手段（例えば、メッセージ受信手段２０２によって実現される）と、メッセージをキューに蓄積するメッセージ蓄積制御手段（例えば、メッセージ蓄積制御手段２０３によって実現される）と、メッセージ蓄積制御手段に従って、セッション毎に用意されたキューにメッセージを記憶するキュー記憶手段（例えば、キュー記憶手段２０４によって実現される）と、ユーザ端末からのメッセージ取得要求を受信して、メッセージ取得要求で示されるメッセージ又は過去にメッセージを返信した時のメッセージ取得要求の内容（例えば、履歴ＵＲＬ）を返信するメッセージ送信手段（例えば、メッセージ送信手段２０５によって実現される）と、ユーザ端末からのメッセージ取得要求に応じて、キュー記憶手段に蓄積されたメッセージの中からユーザ端末に返信するべきメッセージを検索して、メッセージのメッセージ中継サーバ内での管理情報と共にメッセージを取得する送信メッセージ選択手段（例えば、送信メッセージ選択手段２０６によって実現される）と、メッセージ送信手段が送信したメッセージのメッセージ中継サーバ内での管理情報と、メッセージ送信手段が受信したユーザ端末からのメッセージ取得要求の内容とをレスポンス情報として記憶するレスポンス情報記憶手段（例えば、レスポンス情報記憶手段２０７によって実現される）と、ユーザ端末からメッセージ取得要求を受信する際、メッセージ取得要求で示されるメッセージを既に送信済みかどうか判断し、送信済みの場合には、メッセージ取得要求の内容をメッセージ送信手段に出力するレスポンス管理手段（例えば、レスポンス管理手段２０８によって実現される）とを含むことを特徴とする。
【０１４６】
（４）メッセージ送受信システムにおいて、メッセージ送信手段は、ユーザ端末からのメッセージ取得要求に対してメッセージを返信する際、メッセージのメッセージ中継サーバでの管理情報（例えば、セッションＩＤやシーケンス番号、一時ＩＤ、メッセージタイプ）と共にメッセージ取得要求の内容（例えば、ＵＲＬ）をレスポンス情報記憶手段に記憶させるように構成されていてもよい。
【０１４７】
（５）メッセージ送受信システムにおいて、レスポンス管理手段は、メッセージ送信手段においてユーザ端末からのメッセージ取得要求に対してメッセージを返信する際、取得要求されているメッセージが既に過去に返信されているか否かを判定し、過去に返信していると判定した場合、メッセージを返信した時に受信した下り通信要求の内容（例えば、履歴ＵＲＬ）を取得し、メッセージ送信手段は、レスポンス管理手段が取得したメッセージ取得要求の内容をユーザ端末に送信するように構成されていてもよい。
【０１４８】
（６）メッセージ送受信システムにおいて、下り通信手段は、メッセージ中継サーバからメッセージ取得要求の内容（例えば、履歴ＵＲＬ）が返信された場合、返信されたメッセージ取得要求の内容に従ってメッセージ取得要求を再度生成し、メッセージ取得要求にユーザ端末を操作しているユーザを示すユーザ情報（例えば、ユーザＩＤ）を付加情報として指定するように構成されていてもよい。
【０１４９】
（７）メッセージ送受信システムにおいて、メッセージ送信手段は、ユーザ端末からのメッセージ取得要求を受信した際、メッセージ取得要求の内容に含まれるユーザ情報とメッセージ取得要求に付加情報として指定されているユーザ情報とを比較し、ユーザ情報が合致しなければ、メッセージ蓄積制御手段によって蓄積されているメッセージを返信する際に、メッセージにキャッシュにミスしたことを示す付加情報（例えば、キャッシュミス文字列）を追加するように構成されていてもよい。
【０１５０】
（８）メッセージ送受信システムにおいて、下り通信手段は、メッセージ中継サーバからメッセージが返信されてきた場合、返信の付加情報にキャッシュに失敗したことを示す情報が付加されているか否かを確認し、付加されていれば、メッセージ中継サーバから取得したメッセージ取得要求の内容に従ったメッセージ取得要求の再生成を中止するように構成されていてもよい。
【産業上の利用可能性】
【０１５１】
本発明は、遠隔会議等をする用途に適用可能である。
【符号の説明】
【０１５２】
１ Ｗｅｂブラウザ
２ メッセージ中継サーバ
３ プロキシサーバ
１０ レスポンス記憶手段
２０ ＵＲＬ抽出手段
３０ リクエスト生成手段
１０１ アプリケーション
１０２ 通信管理手段
１０３ 上り通信手段
１０４ 下り通信手段
１０５ ポインタ記憶手段
２０１ セッション管理手段
２０２ メッセージ受信手段
２０３ メッセージ蓄積制御手段
２０４ キュー記憶手段
２０５ メッセージ送信手段
２０６ 送信メッセージ選択手段
２０７ レスポンス情報記憶手段
２０８ レスポンス管理手段
【特許請求の範囲】
【請求項１】
複数のブラウザを用いたメッセージの送受信を中継するメッセージ中継サーバを備え、
前記メッセージ中継サーバは、
メッセージ取得用のリクエストに対するレスポンスと前記リクエストに含まれるＵＲＬとを対応づけて記憶するレスポンス記憶手段と、
新たなリクエストを受信すると、受信した前記リクエストに対応するレスポンスと対応づけられたＵＲＬを前記レスポンス記憶手段から抽出するＵＲＬ抽出手段とを含み、
前記ＵＲＬ抽出手段が抽出した前記ＵＲＬを用いて、メッセージ取得用のリクエストを生成するリクエスト生成手段を備えた
ことを特徴とするメッセージ送受信システム。
【請求項２】
メッセージ中継サーバは、リクエストを受信すると、受信した前記リクエストに対応するレスポンスがレスポンス記憶手段に記憶されているか否かを判定する判定手段と、
前記判定手段が記憶されていないと判定すると、送信されたメッセージを記憶する記憶部から、受信した前記リクエストに基づいてメッセージを抽出するメッセージ抽出手段とを備え、
ＵＲＬ抽出手段は、前記判定手段が記憶されていると判定すると、受信した前記リクエストに対応するレスポンスと対応づけられたＵＲＬを前記レスポンス記憶手段から抽出する
請求項１記載のメッセージ送受信システム。
【請求項３】
ユーザ同士が遠隔で協働作業をするためのブラウザを搭載したユーザ端末と、
前記ユーザ端末と通信するサーバ装置上に実装されたメッセージの送受信を中継するメッセージ中継サーバと、
キャッシュ機能を有するプロキシサーバとを備え、
前記ユーザ端末は、
前記協働作業をするための処理を実行するためのアプリケーションと、
前記アプリケーションに従って実行される通信を制御する通信管理手段と、
当該ユーザ端末が生成したメッセージをメッセージ送信要求として前記メッセージ中継サーバに送信する上り通信手段と、
前記メッセージ中継サーバにメッセージ取得要求を送信して他のユーザ端末が生成したメッセージを受信する下り通信手段と、
前記メッセージ中継サーバ上のキュー中の受信したメッセージが存在する位置の位置情報と、前記メッセージを処理するアプリケーションを特定する情報とを関連づけて記憶するポインタ記憶手段とを含み、
前記メッセージ中継サーバは、
ユーザ同士の遠隔協働作業のセッションを管理し、前記セッションと前記セッションにおけるキューとの関係を管理するセッション管理手段と、
前記ユーザ端末からメッセージ送信要求として送信されたメッセージを受信するメッセージ受信手段と、
前記メッセージをキューに蓄積するメッセージ蓄積制御手段と、
前記メッセージ蓄積制御手段に従って、セッション毎に用意されたキューにメッセージを記憶するキュー記憶手段と、
前記ユーザ端末からのメッセージ取得要求を受信して、該メッセージ取得要求で示されるメッセージ又は過去に当該メッセージを返信した時のメッセージ取得要求の内容を返信するメッセージ送信手段と、
前記ユーザ端末からのメッセージ取得要求に応じて、前記キュー記憶手段に蓄積されたメッセージの中から前記ユーザ端末に返信するべきメッセージを検索して、当該メッセージのメッセージ中継サーバ内での管理情報と共にメッセージを取得する送信メッセージ選択手段と、
前記メッセージ送信手段が送信したメッセージの当該メッセージ中継サーバ内での管理情報と、前記メッセージ送信手段が受信した前記ユーザ端末からのメッセージ取得要求の内容とをレスポンス情報として記憶するレスポンス情報記憶手段と、
前記ユーザ端末からメッセージ取得要求を受信する際、該メッセージ取得要求で示されメッセージを既に送信済みかどうか判断し、送信済みの場合には、メッセージ取得要求の内容を前記メッセージ送信手段に出力するレスポンス管理手段とを
含むことを特徴とするメッセージ送受信システム。
【請求項４】
メッセージ送信手段は、ユーザ端末からのメッセージ取得要求に対してメッセージを返信する際、メッセージのメッセージ中継サーバでの管理情報と共に当該メッセージ取得要求の内容をレスポンス情報記憶手段に記憶させる
請求項３記載のメッセージ送受信システム。
【請求項５】
レスポンス管理手段は、メッセージ送信手段においてユーザ端末からのメッセージ取得要求に対してメッセージを返信する際、取得要求されているメッセージが既に過去に返信されているか否かを判定し、過去に返信していると判定した場合、当該メッセージを返信した時に受信した下り通信要求の内容を取得し、
メッセージ送信手段は、前記レスポンス管理手段が取得した前記メッセージ取得要求の内容をユーザ端末に送信する
請求項３記載のメッセージ送受信システム。
【請求項６】
下り通信手段は、メッセージ中継サーバからメッセージ取得要求の内容が返信された場合、返信された前記メッセージ取得要求の内容に従ってメッセージ取得要求を再度生成し、メッセージ取得要求に当該ユーザ端末を操作しているユーザを示すユーザ情報を付加情報として指定する
請求項３記載のメッセージ送受信システム。
【請求項７】
メッセージ送信手段は、ユーザ端末からのメッセージ取得要求を受信した際、前記メッセージ取得要求の内容に含まれるユーザ情報と前記メッセージ取得要求に付加情報として指定されているユーザ情報とを比較し、ユーザ情報が合致しなければ、メッセージ蓄積制御手段によって蓄積されているメッセージを返信する際に、前記メッセージにキャッシュにミスしたことを示す付加情報を追加する
請求項３記載のメッセージ送受信システム。
【請求項８】
下り通信手段は、メッセージ中継サーバからメッセージが返信されてきた場合、返信の付加情報にキャッシュに失敗したことを示す情報が付加されているか否かを確認し、付加されていれば、前記メッセージ中継サーバから取得したメッセージ取得要求の内容に従ったメッセージ取得要求の再生成を中止する
請求項３記載のメッセージ送受信システム。
【請求項９】
複数のブラウザを用いたメッセージの送受信を中継するメッセージ中継サーバであって、
メッセージ取得用のリクエストに対するレスポンスと前記リクエストに含まれるＵＲＬとを対応づけて記憶するレスポンス記憶手段と、
新たなリクエストを受信すると、受信した前記リクエストに対応するレスポンスと対応づけられたＵＲＬを前記レスポンス記憶手段から抽出するＵＲＬ抽出手段とを
備えたことを特徴とするメッセージ中継サーバ。
【請求項１０】
リクエストを受信すると、受信した前記リクエストに対応するレスポンスがレスポンス記憶手段に記憶されているか否かを判定する判定手段と、
前記判定手段が記憶されていないと判定すると、送信されたメッセージを記憶する記憶部から、受信した前記リクエストに基づいてメッセージを抽出するメッセージ抽出手段とを備え、
ＵＲＬ抽出手段は、前記判定手段が記憶されていると判定すると、受信した前記リクエストに対応するレスポンスと対応づけられたＵＲＬを前記レスポンス記憶手段から抽出する
請求項９記載のメッセージ中継サーバ。
【請求項１１】
メッセージ取得用のリクエストに対するレスポンスと前記リクエストに含まれるＵＲＬとを対応づけて記憶部に記憶するレスポンス記憶ステップと、
新たなリクエストを受信すると、受信した前記リクエストに対応するレスポンスと対応づけられたＵＲＬを前記記憶部から抽出するＵＲＬ抽出ステップと、
抽出した前記ＵＲＬを用いて、メッセージ取得用のリクエストを生成するリクエスト生成ステップとを
含むことを特徴とするメッセージ送受信方法。
【請求項１２】
リクエストを受信すると、受信した前記リクエストに対応するレスポンスが記憶部に記憶されているか否かを判定する判定ステップと、
記憶されていないと判定すると、送信されたメッセージを記憶する記憶部から、受信した前記リクエストに基づいてメッセージを抽出するメッセージ抽出ステップとを含み、
ＵＲＬ抽出ステップで、記憶されていると判定すると、受信した前記リクエストに対応するレスポンスと対応づけられたＵＲＬを前記レスポンス記憶手段から抽出する
請求項１１記載のメッセージ送受信方法。
【請求項１３】
複数のブラウザを用いたメッセージの送受信を中継するコンピュータに、
メッセージ取得用のリクエストに対するレスポンスと前記リクエストに含まれるＵＲＬとを対応づけて記憶部に記憶する記憶処理と、
新たなリクエストを受信すると、受信した前記リクエストに対応するレスポンスと対応づけられたＵＲＬを前記記憶部から抽出するＵＲＬ抽出処理と、
抽出した前記ＵＲＬを用いて、メッセージ取得用のリクエストを生成するリクエスト生成処理とを
実行させるためのメッセージ送受信用プログラム。
【請求項１４】
コンピュータに、
リクエストを受信すると、受信した前記リクエストに対応するレスポンスが記憶部に記憶されているか否かを判定する判定処理と、
記憶されていないと判定すると、送信されたメッセージを記憶する記憶部から、受信した前記リクエストに基づいてメッセージを抽出するメッセージ抽出処理とを実行させ、
ＵＲＬ抽出処理で、記憶されていると判定すると、受信した前記リクエストに対応するレスポンスと対応づけられたＵＲＬを前記レスポンス記憶手段から抽出する処理を実行させる
請求項１３記載のメッセージ送受信用プログラム。
【請求項１】
複数のブラウザを用いたメッセージの送受信を中継するメッセージ中継サーバを備え、
前記メッセージ中継サーバは、
メッセージ取得用のリクエストに対するレスポンスと前記リクエストに含まれるＵＲＬとを対応づけて記憶するレスポンス記憶手段と、
新たなリクエストを受信すると、受信した前記リクエストに対応するレスポンスと対応づけられたＵＲＬを前記レスポンス記憶手段から抽出するＵＲＬ抽出手段とを含み、
前記ＵＲＬ抽出手段が抽出した前記ＵＲＬを用いて、メッセージ取得用のリクエストを生成するリクエスト生成手段を備えた
ことを特徴とするメッセージ送受信システム。
【請求項２】
メッセージ中継サーバは、リクエストを受信すると、受信した前記リクエストに対応するレスポンスがレスポンス記憶手段に記憶されているか否かを判定する判定手段と、
前記判定手段が記憶されていないと判定すると、送信されたメッセージを記憶する記憶部から、受信した前記リクエストに基づいてメッセージを抽出するメッセージ抽出手段とを備え、
ＵＲＬ抽出手段は、前記判定手段が記憶されていると判定すると、受信した前記リクエストに対応するレスポンスと対応づけられたＵＲＬを前記レスポンス記憶手段から抽出する
請求項１記載のメッセージ送受信システム。
【請求項３】
ユーザ同士が遠隔で協働作業をするためのブラウザを搭載したユーザ端末と、
前記ユーザ端末と通信するサーバ装置上に実装されたメッセージの送受信を中継するメッセージ中継サーバと、
キャッシュ機能を有するプロキシサーバとを備え、
前記ユーザ端末は、
前記協働作業をするための処理を実行するためのアプリケーションと、
前記アプリケーションに従って実行される通信を制御する通信管理手段と、
当該ユーザ端末が生成したメッセージをメッセージ送信要求として前記メッセージ中継サーバに送信する上り通信手段と、
前記メッセージ中継サーバにメッセージ取得要求を送信して他のユーザ端末が生成したメッセージを受信する下り通信手段と、
前記メッセージ中継サーバ上のキュー中の受信したメッセージが存在する位置の位置情報と、前記メッセージを処理するアプリケーションを特定する情報とを関連づけて記憶するポインタ記憶手段とを含み、
前記メッセージ中継サーバは、
ユーザ同士の遠隔協働作業のセッションを管理し、前記セッションと前記セッションにおけるキューとの関係を管理するセッション管理手段と、
前記ユーザ端末からメッセージ送信要求として送信されたメッセージを受信するメッセージ受信手段と、
前記メッセージをキューに蓄積するメッセージ蓄積制御手段と、
前記メッセージ蓄積制御手段に従って、セッション毎に用意されたキューにメッセージを記憶するキュー記憶手段と、
前記ユーザ端末からのメッセージ取得要求を受信して、該メッセージ取得要求で示されるメッセージ又は過去に当該メッセージを返信した時のメッセージ取得要求の内容を返信するメッセージ送信手段と、
前記ユーザ端末からのメッセージ取得要求に応じて、前記キュー記憶手段に蓄積されたメッセージの中から前記ユーザ端末に返信するべきメッセージを検索して、当該メッセージのメッセージ中継サーバ内での管理情報と共にメッセージを取得する送信メッセージ選択手段と、
前記メッセージ送信手段が送信したメッセージの当該メッセージ中継サーバ内での管理情報と、前記メッセージ送信手段が受信した前記ユーザ端末からのメッセージ取得要求の内容とをレスポンス情報として記憶するレスポンス情報記憶手段と、
前記ユーザ端末からメッセージ取得要求を受信する際、該メッセージ取得要求で示されメッセージを既に送信済みかどうか判断し、送信済みの場合には、メッセージ取得要求の内容を前記メッセージ送信手段に出力するレスポンス管理手段とを
含むことを特徴とするメッセージ送受信システム。
【請求項４】
メッセージ送信手段は、ユーザ端末からのメッセージ取得要求に対してメッセージを返信する際、メッセージのメッセージ中継サーバでの管理情報と共に当該メッセージ取得要求の内容をレスポンス情報記憶手段に記憶させる
請求項３記載のメッセージ送受信システム。
【請求項５】
レスポンス管理手段は、メッセージ送信手段においてユーザ端末からのメッセージ取得要求に対してメッセージを返信する際、取得要求されているメッセージが既に過去に返信されているか否かを判定し、過去に返信していると判定した場合、当該メッセージを返信した時に受信した下り通信要求の内容を取得し、
メッセージ送信手段は、前記レスポンス管理手段が取得した前記メッセージ取得要求の内容をユーザ端末に送信する
請求項３記載のメッセージ送受信システム。
【請求項６】
下り通信手段は、メッセージ中継サーバからメッセージ取得要求の内容が返信された場合、返信された前記メッセージ取得要求の内容に従ってメッセージ取得要求を再度生成し、メッセージ取得要求に当該ユーザ端末を操作しているユーザを示すユーザ情報を付加情報として指定する
請求項３記載のメッセージ送受信システム。
【請求項７】
メッセージ送信手段は、ユーザ端末からのメッセージ取得要求を受信した際、前記メッセージ取得要求の内容に含まれるユーザ情報と前記メッセージ取得要求に付加情報として指定されているユーザ情報とを比較し、ユーザ情報が合致しなければ、メッセージ蓄積制御手段によって蓄積されているメッセージを返信する際に、前記メッセージにキャッシュにミスしたことを示す付加情報を追加する
請求項３記載のメッセージ送受信システム。
【請求項８】
下り通信手段は、メッセージ中継サーバからメッセージが返信されてきた場合、返信の付加情報にキャッシュに失敗したことを示す情報が付加されているか否かを確認し、付加されていれば、前記メッセージ中継サーバから取得したメッセージ取得要求の内容に従ったメッセージ取得要求の再生成を中止する
請求項３記載のメッセージ送受信システム。
【請求項９】
複数のブラウザを用いたメッセージの送受信を中継するメッセージ中継サーバであって、
メッセージ取得用のリクエストに対するレスポンスと前記リクエストに含まれるＵＲＬとを対応づけて記憶するレスポンス記憶手段と、
新たなリクエストを受信すると、受信した前記リクエストに対応するレスポンスと対応づけられたＵＲＬを前記レスポンス記憶手段から抽出するＵＲＬ抽出手段とを
備えたことを特徴とするメッセージ中継サーバ。
【請求項１０】
リクエストを受信すると、受信した前記リクエストに対応するレスポンスがレスポンス記憶手段に記憶されているか否かを判定する判定手段と、
前記判定手段が記憶されていないと判定すると、送信されたメッセージを記憶する記憶部から、受信した前記リクエストに基づいてメッセージを抽出するメッセージ抽出手段とを備え、
ＵＲＬ抽出手段は、前記判定手段が記憶されていると判定すると、受信した前記リクエストに対応するレスポンスと対応づけられたＵＲＬを前記レスポンス記憶手段から抽出する
請求項９記載のメッセージ中継サーバ。
【請求項１１】
メッセージ取得用のリクエストに対するレスポンスと前記リクエストに含まれるＵＲＬとを対応づけて記憶部に記憶するレスポンス記憶ステップと、
新たなリクエストを受信すると、受信した前記リクエストに対応するレスポンスと対応づけられたＵＲＬを前記記憶部から抽出するＵＲＬ抽出ステップと、
抽出した前記ＵＲＬを用いて、メッセージ取得用のリクエストを生成するリクエスト生成ステップとを
含むことを特徴とするメッセージ送受信方法。
【請求項１２】
リクエストを受信すると、受信した前記リクエストに対応するレスポンスが記憶部に記憶されているか否かを判定する判定ステップと、
記憶されていないと判定すると、送信されたメッセージを記憶する記憶部から、受信した前記リクエストに基づいてメッセージを抽出するメッセージ抽出ステップとを含み、
ＵＲＬ抽出ステップで、記憶されていると判定すると、受信した前記リクエストに対応するレスポンスと対応づけられたＵＲＬを前記レスポンス記憶手段から抽出する
請求項１１記載のメッセージ送受信方法。
【請求項１３】
複数のブラウザを用いたメッセージの送受信を中継するコンピュータに、
メッセージ取得用のリクエストに対するレスポンスと前記リクエストに含まれるＵＲＬとを対応づけて記憶部に記憶する記憶処理と、
新たなリクエストを受信すると、受信した前記リクエストに対応するレスポンスと対応づけられたＵＲＬを前記記憶部から抽出するＵＲＬ抽出処理と、
抽出した前記ＵＲＬを用いて、メッセージ取得用のリクエストを生成するリクエスト生成処理とを
実行させるためのメッセージ送受信用プログラム。
【請求項１４】
コンピュータに、
リクエストを受信すると、受信した前記リクエストに対応するレスポンスが記憶部に記憶されているか否かを判定する判定処理と、
記憶されていないと判定すると、送信されたメッセージを記憶する記憶部から、受信した前記リクエストに基づいてメッセージを抽出するメッセージ抽出処理とを実行させ、
ＵＲＬ抽出処理で、記憶されていると判定すると、受信した前記リクエストに対応するレスポンスと対応づけられたＵＲＬを前記レスポンス記憶手段から抽出する処理を実行させる
請求項１３記載のメッセージ送受信用プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１１−３４５１１（Ｐ２０１１−３４５１１Ａ）
【公開日】平成２３年２月１７日（２０１１．２．１７）
【国際特許分類】
【出願番号】特願２００９−１８２７４５（Ｐ２００９−１８２７４５）
【出願日】平成２１年８月５日（２００９．８．５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＦＬＡＳＨ
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２３年２月１７日（２０１１．２．１７）
【国際特許分類】
【出願日】平成２１年８月５日（２００９．８．５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＦＬＡＳＨ
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]