JPH11184813A - データ通信システム - Google Patents

Abstract

(57)【要約】 【課題】 サーバの管理するデータの更新に関するデー
タのクライアントへの配信を適切に実行し、特定データ
を複数のクライアント装置によって共有可能な構成とす
る。 【解決手段】 サーバ中で起動させるメソッドを指定す
るメソッド識別子と、グループを識別するグループ識別
子とをデータリクエストの修飾名としてクライアントか
ら出力する。サーバは、リクエスト中からデータファイ
ル名を取り出し、修飾名からメソッド識別子とグループ
識別子とを取り出す。メソッドにはグループ登録をする
レジスト、更新処理に関するリフレッシュ、通知に関す
るノーティファイがあり、サーバはグループ管理を行う
クライアント管理テーブルを参照してグループのメンバ
・アドレスを取得し、メソッドに定義された必要な通知
等の処理を実行する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数のクライアン
ト装置およびサーバを有するデータ通信ネットワークシ
ステムにおいて、ネットワークに接続されたサーバ等に
分散的に存在するデータに対するクライアント装置から
のアクセス構成に関し、特にサーバの管理するデータの
更新および更新データの特定クライアントへの配信、ま
たは特定のデータを複数のクライアント装置によって共
有する構成に関する。

【０００２】

【従来の技術】データ通信の可能なネットワークに接続
された複数のクライアント装置およびサーバを有するシ
ステムにおいて、サーバに記憶されたデータをクライア
ント装置からアクセスし、該アクセスデータに対してク
ライアントが更新、変更等の処理を行い、更新データを
新たにサーバに記憶し保管したり、各種のデータをネッ
トワークに接続されたクライアント装置間で送受信する
等の構成が従来から利用されている。

【０００３】複数のクライアントが、サーバに保管され
た特定データを随時アクセスする環境において、特定の
クライアントにより、あるいは所定の管理システムによ
って不定期にデータが更新されるような場合、データ更
新の有無に関する情報のクライアントへの通知や、更新
データのクライアントへの配信タイミングの確立が問題
となる。

【０００４】このような問題を扱った従来技術として特
開平２−２４７７６８で開示される分散処理システムが
ある。この特開平２−２４７７６８で開示される分散処
理システムは、ホストプロセッサ（サーバ）と、ホスト
に接続される複数のワークステーション（クライアン
ト）からなるシステムであり、サーバは、クライアント
からのデータ要求に対する返答としてデータを送信する
のに加え、サーバが、クライアントの将来のデータ要求
発生を予測し、要求に対応したデータをあらかじめクラ
イアントに送信する手段を持つ。

【０００５】クライアントは、利用者の操作に応じてサ
ーバにデータアクセス要求を出すが、要求に対応するデ
ータが前述の手続きにより、すでに自クライアント内に
送信されていた場合は、要求を出さずに自クライアント
内のデータに対してアクセスすることが可能となる。

【０００６】この方式によって、サーバ上のデータに対
する複数のクライアントからのアクセスが一定時間に集
中することを避け、ネットワークトラフィックを平均化
させることが可能となるが、サーバとクライアントの関
係は固定的であり、このように設定された特定のサーバ
に対するクライアンが固定化された環境でのみ有効であ
り、上記の機構をもつサーバ以外のデータに対するアク
セス環境の整備の仕組みについては言及されていない。

【０００７】さらに、従来技術として、「ｈｔｔｐ：／
／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ＮＯＴＥ−ＣＤＦ ｓ
ｕｂｍｉｔ．ｈｔｍｌ」において開示される「 Ｃｈａ
ｎｎｅｌ Ｄｅｆｉｎｉｔｏｎ Ｆｏｒｍａｔ（ＣＤ
Ｆ）」がある。ここでは、ＨＴＴＰによりアクセスでき
る複数の分散データに対するメタ情報を記述するための
フォーマットについて開示している。ＣＤＦファイルに
はデータの集合であるデータの定義や、各データの最終
更新日時、各データの更新のスケジュールなどが記述可
能であり、ＣＤＦに対応したＷＷＷクライアントにより
ダウンロードされる。

【０００８】この構成において、ＣＤＦファイルをダウ
ンロードしたクライアントはＣＤＦに記述されたデータ
について自動的に更新データの取得のためのアクセスを
行なうことが可能となる。

【０００９】この方式によって、クライアントを使用す
るユーザが定期的に変更されるデータの最新の状態を継
続的に入手したい場合、更新の都度、クライアントは手
動でアクセスする必要がなくなり、ＷＷＷサーバ管理者
の設定した更新スケジュールにしたがってデータの自動
的な取得が可能になる。また、特定のデータを継続的に
入手する設定を複数のクライアントのユーザが行なうこ
とにより、それら、設定済みのクライアント間では、同
時に更新されたデータをうけとることが可能になる。た
だし、ＣＤＦの記述はサーバ管理者が事前に行なう必要
があり、サーバ上のデータの更新にともなって自動的に
クライアントにデータをアクセスさせることはできな
い。

【００１０】すなわち、クライアントからの変更要求に
より変化する可能性のあるデータの場合、更新が不定期
に行なわれることになり、前もってその時期をＣＤＦと
して記述することができないため、不定期なデータ変更
に応じてのクライアントに対する自動的なデータ取得を
可能とする仕組みは実現できない。

【００１１】

【発明が解決しようとする課題】以上、説明した従来技
術は、情報を提供するサーバと、その情報提供サーバに
対して情報取得のリクエストを行うクライアントの間
で、利用者が明示的にデータリクエストを行う操作をす
ることなしに、クライアントがサーバ上にある情報を取
得する方法を説明するが、特開平２−２４７７６８は、
特定のデータを共有しようとするメンバによって構成さ
れるグループ内でファイルを共有するために独自のサー
バおよびクライアントからなる特別なデータアクセスプ
ロトコルが必要になる。

【００１２】また、「ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏ
ｒｇ／ＴＲ／ＮＯＴＥ−ＣＤＦｓｕｂｍｉｔ．ｈｔｍ
ｌ」において開示される「Ｃｈａｎｎｅｌ Ｄｅｆｉｎ
ｉｔｏｎ Ｆｏｒｍａｔ（ＣＤＦ）」に関する技術は、
サーバ上のデータに対して不定期的な変更が実行された
場合の情報取得に関しては、何ら解決手段を提供するも
のではない。

【００１３】このように、上述のような従来の技術で
は、分散したサーバ上に存在する情報に対し、複数のク
ライアントがグループを構成し、グループ内でサーバ上
の特定のファイルを共有し、共有したファイルのファイ
ル名を指定して通常のファイルアクセスプロトコルによ
りアクセスしデータを取得する際、グループのメンバで
あるクライアントが任意のタイミングでそのデータの更
新を実行した場合、その更新された最新のデータをグル
ープの他のメンバとともに共有することが困難であっ
た。

【００１４】

【課題を解決するための手段】本発明のデータ通信シス
テムは、上記従来技術における問題点を解決するもので
あり、複数のデータファイルを管理するサーバと、デー
タ通信手段によってサーバに接続可能な構成を有し、サ
ーバの管理する複数のデータファイルから特定のデータ
ファイルを指定したリクエストをサーバに対して出力
し、該データファイルを閲覧可能な複数のクライアント
装置とを有するデータ通信システムにおいて、クライア
ントは、サーバの管理するデータファイル中、特定のデ
ータファイルを共有する１以上のクライアントによって
グループを構成し、クライアントは、サーバに対するデ
ータファイルリクエストにおいて、サーバ中で起動可能
な１以上の処理フローである１以上のメソッド中から特
定の実行メソッドを指定するメソッド識別子と、グルー
プを識別するグループ識別子とを該データファイル・リ
クエストの修飾名として出力する構成を有し、サーバ
は、クライアントから受領したデータファイル・リクエ
スト中からデータファイル名を取り出すとともに、修飾
名からメソッド識別子とグループ識別子とを取り出すフ
ァイル名解析手段と、１以上のクライアントの各々の識
別子を該クライアントによって構成されるグループのグ
ループ識別子に対応させて登録したクライアント管理テ
ーブルを有し、グループの管理を行うグループ管理手段
と、クライアントからのデータファイル・リクエストに
応答して、予め登録された複数のメソッドから起動メソ
ッドを決定するメソッド選択手段とを有することを特徴
とする。

【００１５】さらに、本発明のデータ通信システムにお
いて、サーバは、グループ識別子によって識別されたグ
ループに属するクライアント装置に前記データファイル
名を送信する送信手段を有することを特徴とする。

【００１６】さらに、本発明のデータ通信システムにお
いて、送信手段は、データファイル名に加えて前記メソ
ッド識別子および前記グループ識別子を送信する構成を
有することを特徴とする。

【００１７】さらに、本発明のデータ通信システムにお
いて、サーバは、データファイル名に対して、メソッド
識別子およびグループ識別子を修飾させて修飾名を生成
する修飾手段を有し、送信手段は、修飾手段によってメ
ソッド識別子およびグループ識別子が修飾されたデータ
ファイル名をメッセージ・データとして送信する構成を
有することを特徴とする。

【００１８】さらに、本発明のデータ通信システムにお
いて、サーバは、クライアントをグループのメンバとし
て登録するレジスト・メソッドを実行する構成を有し、
サーバは、クライアントから受領するデータファイル・
リクエストの修飾名としてレジスト・メソッドの指定が
ある場合に、該レジスト・メソッドを実行し、クライア
ントを識別するクライアント識別データをクライアント
管理テーブル中に登録する構成を有することを特徴とす
る。

【００１９】さらに、本発明のデータ通信システムにお
いて、サーバは、クライアントからのデータファイル・
リクエストによって指定されたデータ・ファイルの更新
処理を可能とするリフレッシュ・メソッドを実行する構
成を有し、サーバは、クライアントから受領するデータ
ファイル・リクエストの修飾名としてリフレッシュ・メ
ソッドの指定がある場合に、該リフレッシュ・メソッド
を実行し、指定されたデータ・ファイルの更新を可能と
するとともに、該更新データ・ファイルを、クライアン
トのデータファイル・リクエストにおける修飾名として
指定されたグループ識別子に対応するグループに属する
クライアントに送信する構成を有することを特徴とす
る。

【００２０】さらに、本発明のデータ通信システムにお
いて、サーバは、クライアント管理テーブルに登録され
たグループに属するクライアントにメッセージを通知す
るノーティファイ・メソッドを実行する構成を有し、サ
ーバは、クライアントから受領するデータファイル・リ
クエストの修飾名としてノーティファイ・メソッドの指
定がある場合に、該ノーティファイ・メソッドを実行
し、クライアントからのデータファイル・リクエストに
よって指定されたデータファイルに関する処理の実行
を、クライアントのデータファイル・リクエストにおけ
る修飾名として指定されたグループ識別子に対応するグ
ループに属するクライアントに通知する構成を有するこ
とを特徴とする。

【００２１】さらに、本発明のデータ通信システムにお
いて、サーバは、さらにノーティファイ・メソッドの実
行において、修飾手段において、クライアントからのデ
ータ・リクエスト中の修飾名として指定されたノーティ
ファイ・メソッドのリフレッシュ・メソッドへの書き換
えを実行し、該書き換えの完了したメッセージ・データ
をクライアントのデータファイル・リクエストにおける
修飾名として指定されたグループ識別子に対応するグル
ープに属するクライアントに通知する構成を有すること
を特徴とする。

【００２２】さらに、本発明のデータ通信システムにお
いて、サーバの修飾手段において書き換えられたメッセ
ージ・データを受領したクライアントは、該書き換えメ
ッセージ・データをサーバに対するデータファイル・リ
クエストとして出力し、サーバは該リクエストを受領す
ることにより、リフレッシュ・メソッドを実行する構成
を有することを特徴とする。

【００２３】さらに、本発明のデータ通信システムにお
いて、サーバは、さらにリフレッシュ・メソッドの実行
において、修飾手段において、クライアントからのデー
タ・リクエスト中の修飾名として指定されたリフレッシ
ュ・メソッドのノーティファイ・メソッドへの書き換え
を実行し、該書き換えの完了したメッセージ・データを
クライアントのデータファイル・リクエストにおける修
飾名として指定されたグループ識別子に対応するグルー
プに属するクライアントに通知する構成を有することを
特徴とする。

【００２４】さらに、本発明のデータ通信システムにお
いて、サーバの修飾手段において書き換えられたメッセ
ージ・データを受領したクライアントは、該書き換えメ
ッセージ・データをサーバに対するデータファイル・リ
クエストとして出力し、サーバは該リクエストを受領す
ることにより、ノーティファイ・メソッドを実行する構
成を有することを特徴とする。

【００２５】さらに、本発明のデータ通信システムにお
いて、サーバは、クライアント管理テーブルに登録され
たグループ内情報の編集処理を可能とするエディット・
メソッドを実行可能な構成を有し、サーバは、クライア
ントから受領するデータファイル・リクエストの修飾名
としてエディット・メソッドの指定がある場合に、該エ
ディット・メソッドを実行し、グループ内情報の編集
し、編集内容を新たなグループ内情報として登録すると
ともに、該新たなグループ内情報に関するノーティファ
イ・メソッドを起動する構成を有することを特徴とす
る。

【００２６】さらに、本発明のデータ通信システムにお
いて、サーバおよびクライアント装置は、マルチキャス
トルータ及びネットワークを介して接続可能な構成を有
し、サーバは、クライアント管理テーブル中に登録され
たグループに対応してマルチキャストグループ・アドレ
スを登録データとして有し、クライアントによって構成
されるグループ内のクライアントとサーバ間のデータ通
信は、グループ識別子に対して一意的に決定されるマル
チ・キャスト・アドレスに基づいて実行されることを特
徴とする。

【００２７】さらに、本発明のデータ通信システムにお
いて、クライアントの指定するデータファイルは、ＨＴ
ＭＬページによって構成され、該クライアントおよびサ
ーバ間でのデータ転送はＨＴＴＰに従って実行する構成
を有し、サーバの有する修飾手段はＵＲＬ修飾手段によ
って構成され、データファイル名に対するメソッド識別
子およびグループ識別子の修飾はＵＲＬの書き換えによ
って実行する構成であることを特徴とする。

【００２８】さらに、本発明のデータ通信システムにお
いて、サーバの実行するリフレッシュ・メソッドにおけ
るデータファイルの編集はＨＴＭＬページの編集であ
り、サーバは該編集ＨＴＭＬページ中に他のサーバの管
理するリンクデータが含まれる場合、該他のサーバの管
理するリンクデータのＵＲＬにノーティファイ・メソッ
ドを呼び出す識別子を付加するＵＲＬの書き換えを実行
する構成を有することを特徴とする。

【００２９】

【発明の実施の形態】以下、図面を参照して本発明のデ
ータ通信システムに関する複数の実施例について詳細に
説明する。

【００３０】［基本構成の説明］図１は、本発明の概念
を説明するための本発明のデータ通信システムを構成す
る要素を示すブロック図である。

【００３１】図１に示すように本発明のデータ通信シス
テムは、ファイルを保持するファイルサーバ１０１と、
ファイルサーバ１０１に対するアクセスを行う複数のク
ライアント装置を有する。図１に示すように、複数のク
ライアント装置はグループを構成しており、グループ
Ａ、１０２とグループＢ、１０３とにグループ化されて
いる。これらのグループは、ファイルサーバ１上の特定
のファイルを共通にアクセスまたは使用するグループと
して構成されるものである。

【００３２】具体的には、ファイルサーバ１０１上のフ
ァイル（ファイル１）の読み出し・書き込みをするクラ
イアント（クライアント１−１、１−２．．．１−ｋ）
と、（ファイル２）の読み出し・書き込みをするクライ
アント（クライアント２−１、２−２．．．２−ｎ）と
を有する。ここでｋ、ｎは、自然数である。

【００３３】クライアントのグループがファイルを共有
するとは、例えばクライアント・グループＡに属する１
つのクライアントが、ファイルサーバ１０１のファイル
１を読み出して、このファイルを更新したとき、その更
新ファイルを読み出すように構成された関係である。

【００３４】図１中の実線はファイルを更新するときの
データの書き込みを示し、破線は、データの読み出しを
示す。

【００３５】ファイルサーバ１０１はクライアントがグ
ループへの加入をリクエストした時、それぞれクライア
ントが指定したグループへ加入させる。グループに属す
るいずれかのクライアントがサーバに対しファイルを変
更する操作をリクエストした時、グループに属するクラ
イアントに対しファイル名を配信する。クライアントは
配信されたファイル名を用いてサーバにファイルの読み
出しをリクエストし、サーバからファイルを受信する。
このような手順により、同じグループに属するクライア
ント利用者の間でファイルを共有し、指定したファイル
の最新の状態をクライアントが自動的に取得する情報配
信手段を開示する。

【００３６】情報配信をおこなうサーバおよびクライア
ントそれぞれの基本構成ブロック図を図２に示す。図２
のブロック図においては、１つのクライアントが示され
ているが、同様の構成を有する複数のクライアント装置
がサーバに対してアクセス可能に接続されている。図２
では代表的に１つのクライアント装置を示したものであ
る。

【００３７】図２のサーバ２００は、受信部２０１、フ
ァイル名解析手段２０２、ディスパッチ手段２０３、グ
ループ管理手段２０４、修飾手段２０５、送信部２０
６、２０７、ファイルサーバ２０８を有する。また、ク
ライアント装置２２０は、送信部２２１、受信部２２
２、２２３、および表示部２２４を有する。

【００３８】サーバ２００の受信部２０１と、クライア
ント装置２２０の送信部２２１とによってリクエスト手
段２４１が構成され、サーバ２００の送信部２０６と、
クライアント装置２２０の受信部２２２とによってプッ
シュ手段２４２が構成され、サーバ２００の送信部２０
７と、クライアント装置２２０の受信部２２３とによっ
てレスポンス手段２４３が構成される。

【００３９】クライアント装置２２０がサーバ２００に
対しファイルアクセスのリクエストを行なうのがリクエ
スト手段２４１であり、クライアント装置２２０側では
送信部２２１においてリクエストの送信を行ない、サー
バ２００側では受信部２０１においてリクエストの受信
を行なう。

【００４０】サーバ２００はリクエストされたファイル
のデータをクライアント装置２２０に送信する。この送
信を実行するのがレスポンス手段２４３であり、サーバ
２００側では送信部２０７においてレスポンスの送信を
行ない、クライアント２２０側では受信部２２３におい
てレスポンスの受信を行なう。

【００４１】サーバ２００からクライアント装置２２０
にファイル名を配信するのがプッシュ手段２４２であ
り、サーバー２００からファイル名を送信する送信部２
０６とクライアント装置２２０においてファイル名を受
信する受信部２２２によって構成される。

【００４２】リクエスト手段３０１中の受信部２０１お
よび、レスポンス手段３０３の送信部１０７は、例え
ば、サーバ１０がクライアント装置２０からのＨＴＴＰ
リクエストを受けとり、レスポンスをクライアント装置
２０に送信するＷＷＷサーバプログラムの機能を利用し
て実現される。

【００４３】サーバ２００には、分散ファイルアクセス
を行なう際に用いられるファイル名を修飾する修飾手段
２０５が存在する。修飾手段２０５はサーバ２００上で
の処理を指定するメソッド名、情報を共有するクライア
ントを管理するためのグループ名の情報を付加して修飾
されたファイル名を生成する。

【００４４】クライアント装置２２０から出力されたデ
ータファイル・リクエストに用いられた修飾されたファ
イル名からグループ名、メソッド名の情報を抽出するの
がファイル名解析手段２０２である。ファイル名解析手
段２０２によって解析されたメソッドに従ったメソッド
名に対応するメソッドを起動するのがディスパッチ手段
２０３である。

【００４５】クライアント装置２２０からのファイルア
クセス要求は、サーバ２００の受信部２０１において受
信され、受信データはファイル名解析手段２０２に転送
される。ファイル名解析手段は、受信されたリクエスト
データから修飾名を分離し、さらにメソッド識別子とグ
ループ識別子と被修飾名を検出する。このように各修飾
データを解析するファイル名解析手段２０２は、例えば
ＵＲＬパーザとして実現される。ファイル名解析手段２
０２は与えられたＵＲＬを文字列として扱い、文法的に
解析して、プログラムの動作を指定するメソッド名、情
報配信をコントロールするためのグループ名、およびク
ライアントの情報を取り出す構成を有する。

【００４６】図１に示すクライアントのグループＡ、１
０２またはグループＢ、１０３のような各グループを識
別するグループ識別子に対応するグループごとにクライ
アントの情報をメンバとして保持するのがグループ管理
手段２０４である。グループ管理手段２０４の中の参加
メソッド、配信メソッド、読み出しメソッドはメソッド
のディスパッチ手段２０３により起動される。

【００４７】［実施例１］以下、本発明のデータ通信シ
ステムの実施例として、ネットワークにおける情報配信
をｗｗｗサーバーおよびクライアント上で実現する方法
を説明する。本実施例のデータ通信システムにおいて
は、複数のｗｗｗクライアント間で同一の情報を共有す
ることが可能になる。また、複数のクライアントでグル
ープを形成し、そのグループに属するクライアント間
で、同時に同じＨＴＭＬページを閲覧することを可能と
する。さらに、グループに属するいずれかのクライアン
トがＨＴＭＬ中のリンクをたどる操作を行なった場合
に、そのグループに属する他のクライアントにおいても
同様のリンクをたどったのと同じＨＴＭＬページを表示
させることが可能となる。

【００４８】本実施例のデータ通信システムは、ネット
ワークに接続されたｗｗｗサーバーの動作する計算機お
よびｗｗｗクライアントの動作する複数の計算機によっ
て構成される。

【００４９】図３に本実施例のサーバ３００、クライア
ント装置３２０の構成ブロック図を示す。以下、説明す
る本実施例においては分散ファイルに対するアクセス
は、ＨＴＴＰによるアクセスとして実行されるものとし
て説明する。

【００５０】図３に示す構成は、基本的に図２に示す構
成と同様のものであるが、ｗｗｗサーバ、クライアント
におけるＵＲＬ送受信による構成となっている。サーバ
３００は、ＵＲＬ受信部３０１、ファイル名解析手段と
してのＵＲＬパーザ３０２、ディスパッチ手段としての
メソッドインタプリタ３０３、グループ管理手段３０
４、修飾手段３０５、ＵＲＬ送信部３０６、登録結果生
成部３０７、ＨＴＭＬ入力部３０８、ＨＴＭＬ処理部３
０９、ＨＴＭＬ送信部３１０を有し、グループ管理手段
３０４は、メンバチェック部３０４１、メンバ登録部３
０４２、メンバ配信部３０４３、クライアント管理テー
ブル３０４４を有し、またＨＴＭＬ入力部３０８は、フ
ァイルサーバ３３０にアクセス可能な構成となってい
る。クライアント装置３２０は、ＵＲＬ送信部３２１、
ＵＲＬ受信部３２２、ＨＴＭＬ受信・表示部３２３を有
する。

【００５１】分散ファイルアクセスにおけるファイル名
はＵＲＬであり、ファイル名の修飾はクライアント装置
３２０がアクセスするサーバのホスト名、およびサーバ
３００が起動するメソッド名、グループ名をＣＧＩキュ
エリとしてファイル名に付加したＵＲＬである。クライ
アント装置３２０は、サーバ３００に対してアクセスを
要求するファイルをＵＲＬによって指定するとともに、
必要な修飾情報、例えばサーバのホスト名、およびサー
バが起動するメソッド名、グループ名をＣＧＩキュエリ
として付加して生成し、ＵＲＬ送信部３２１からサーバ
３００のＵＲＬ受信部３０１に送信する。

【００５２】

【数１】例えば、アクセスを行うファイル名が、「ｈｔ
ｔｐ：／／ａａ．ｂｂ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍ
ｌ」の場合、修飾されたファイル名は、 「ｈｔｔｐ：／／ｈｏｓｔ．ｄｏｍａｉｎ．ｃｏｍ／Ｐ
ｕｓｈ？ ｍｅｔｈｏｄ＝ｒｅｆｒｅｓｈ ＆ｇｉｄ＝０ ＆ｉｎｐｕｔ＝ｈｔｔｐ：／／ａａ．ｂｂ．ｃｏｍ／ｉ
ｎｄｅｘ．ｈｔｍｌ」 のようになる。

【００５３】上記式において、「ｍｅｔｈｏｄ」はメソ
ッドを指定し、「ｇｉｄ」はグループ識別子（グループ
ＩＤ）を指定する。ファイル名を修飾して修飾名を生成
する手段はＵＲＬに対する文字列処理をおこなうプログ
ラムにより実現できる。

【００５４】サーバ３００上にはＷＷＷサーバが起動で
きるプログラムが予め組み込まれてある。このようなプ
ログラムは例えばＷＷＷサーバとしてＪａｖａ Ｗｅｂ
Ｓｅｒｖｅｒを用いた場合、Ｊａｖａのクラスである
Ｊａｖａ Ｓｅｒｖｌｅｔとして実現される。

【００５５】クライアント装置３２０からのファイルア
クセス要求は、サーバ３００のＵＲＬ受信部３０１にお
いて受信され、受信データはファイル解析手段であるＵ
ＲＬパーザ３０２に転送される。ＵＲＬパーザ３０２
は、受信されたリクエストデータから修飾名を分離し、
さらにメソッド識別子とグループ識別子と被修飾名を検
出する。ＵＲＬパーザ３０２は与えられたＵＲＬを文字
列として扱い、文法的に解析して、プログラムの動作を
指定するメソッド名、情報配信をコントロールするため
のグループ名、およびクライアントの情報を取り出す構
成を有する。上記の式に示す例であればメソッド名はレ
ジスト（ｒｅｇｉｓｔ）、グループ名は０が取り出され
る。

【００５６】また、ＵＲＬパーザ３０２は、クライアン
ト装置３２０中のＵＲＬ受信部３２２の、アドレスを表
す情報がＵＲＬ中に含まれている場合には、その情報も
取り出す。

【００５７】クライアント装置３２０のＩＰアドレスと
ＵＤＰポート番号の情報がＵＲＬに含まれる場合とは、
以下のような構成である。

【００５８】

【数２】ｈｔｔｐ：／／ｈｏｓｔ．ｄｏｍａｉｎ．ｃｏ
ｍ／Ｐｕｓｈ？ ｍｅｔｈｏｄ＝ｒｅｇｉｓｔ ＆ｇｉｄ＝０ ＆ＩＰ＝１９２．１６８．１１．１ ＆ｐｏｒｔ＝２００２

【００５９】上記の指定がある場合は、ファイル名解析
手段であるＵＲＬパーザ３０２は、ＩＰアドレス「１９
２．１６８．１１．１」とＵＤＰポート番号「２００
２」を取り出すことが可能となる。

【００６０】また、同様の手法により、クライアント
は、要求したい他の種類の情報も付加できる。例えば、
あるＵＲＬについての情報を送信したい場合、例えば以
下のように指定することが可能である。

【００６１】

【数３】ｈｔｔｐ：／／ｈｏｓｔ．ｄｏｍａｉｎ．ｃｏ
ｍ／Ｐｕｓｈ？ ｍｅｔｈｏｄ＝ｎｏｔｉｆｙ ＆ｇｉｄ＝０ ＆ｉｎｐｕｔ＝ｈｔｔｐ：／／ａａ．ｂｂ．ｃｏｍ／ｉ
ｎｄｅｘ．ｈｔｍｌ

【００６２】上記のような指定を行うことで、ＵＲＬと
してｈｔｔｐ：／／ａａ．ｂｂ．ｃｏｍ／ｉｎｄｅｘ．
ｈｔｍｌが取り出される。これらの取り出された情報
は、メソッドインタプリタ３０３に渡される。

【００６３】メソッドに関するディスパッチ手段として
構成されるメソッドインタプリタ３０３は、ＵＲＬパー
ザ３０２から得たメソッド名によって指定されたメソッ
ドの起動を行なう。ＵＲＬパーザ３０２が取り出したグ
ループ名やファイル名など、メソッドが必要とする情報
をメソッドに対する引数として渡す。

【００６４】サーバ３００のグループ管理手段３０４
は、グループ名をキーとして、グループに属する複数の
クライアントへの通信チャネルのハンドルを取り出すこ
とができるクライアント管理テーブル３０４４と、グル
ープ名を利用した操作をおこなうメソッドをもつプログ
ラムとして実現される。

【００６５】クライアント管理テーブル３０４４の例を
図４に示す。グループ名を一つの整数ＩＤとして表し、
そのグループに属するクライアントへの通信チャネルの
ハンドルをクライアントの＜ＩＰアドレス、ＵＤＰソケ
ットのポート番号＞で表し、一つのグループ名をキーと
して、複数のクライアントへのハンドルを格納するよう
なテーブルとして実現される。

【００６６】グループ管理手段３０４の参加メソッドお
よび配信メソッドおよび読み出し（更新）・メソッド
は、それぞれグループ管理プログラム内のレジスト（ｒ
ｅｇｉｓｔ）・メソッドと、ノーティファイ（ｎｏｔｉ
ｆｙ）・メソッドと、リフレッシュ（ｒｅｆｒｅｓｈ）
・メソッドに対応する。以下、これらの各メソッドにつ
いて説明する。

【００６７】レジスト（ｒｅｇｉｓｔ）・メソッドは、
メソッド・ディスパッチャからクライアントを登録する
グループ名と、クライアントのアドレス、ポート番号を
受けとって起動する。リクエストを発したクライアント
をグループ名で表されるグループに登録するため、テー
ブルの指定されたグループ名の列に、クライアントの＜
ＩＰアドレス、ＵＤＰソケットのポート番号＞を追加す
る。

【００６８】その後、ＨＴＴＰレスポンスとして実行の
終了を表すＨＴＭＬページを作成し、クライアントに送
信する。

【００６９】ノーティファイ（ｎｏｔｉｆｙ）・メソッ
ドは、メソッドディスパッチャからグループ名と、原料
のＵＲＬを受けとって起動し、前記修飾手段の実現であ
るＵＲＬ生成部によりクライアントに配信するＵＲＬと
して、リフレッシュ（ｒｅｆｒｅｓｈ）・メソッドを呼
び出すＵＲＬを生成する。

【００７０】

【数４】例えばクライアントからのリクエストに含まれ
た原料のＵＲＬが、ｈｔｔｐ：／／ａａ．ｂｂ．ｃｏｍ
／ｉｎｄｅｘ．ｈｔｍｌであり、グループ名が０であっ
たばあい、 ｈｔｔｐ：／／ｈｏｓｔ．ｄｏｍａｉｎ．ｃｏｍ／Ｐｕ
ｓｈ？ ｍｅｔｈｏｄ＝ｒｅｆｒｅｓｈ ＆ｇｉｄ＝０ ＆ｉｎｐｕｔ＝ｈｔｔｐ：／／ａａ．ｂｂ．ｃｏｍ／ｉ
ｎｄｅｘ．ｈｔｍｌ というＵＲＬを生成する。

【００７１】次にクライアント情報のテーブルから指定
されたグループに属するクライアントの＜ＩＰアドレ
ス、ＵＤＰソケットのポート番号＞を得る。生成したＵ
ＲＬをデータとして含むＵＤＰパケットを生成し、ＵＲ
Ｌ送信チャネルからそれぞれのクライアントに送信す
る。

【００７２】サーバは、メソッドの実行終了を表す情報
と、ＦＯＲＭの記述を含むＨＴＭＬページを生成してレ
スポンスとしてクライアントに送信する。ＦＯＲＭの中
には、メソッド名、グループＩＤ、ＵＲＬが埋め込まれ
ており、クライアント側ではユーザがＦＯＲＭの“ｓｕ
ｂｍｉｔ”を実行することでＵＲＬをメソッド名とグル
ープＩＤで修飾して送信することができる。本実施例に
おいては、リフレッシュ（ｒｅｆｒｅｓｈ）メソッドを
呼び出す修飾されたＵＲＬを生成するＦＯＲＭを作成し
て送信する。以下に例を示す。

【００７３】

【数５】<HTML> <H1> notify method invoked.</H1> <FORM METHOD=“GET”ACTION=“Push”> <INPUT TYPE=HIDDEN NAME=“method”value=“refres
h”> <HIDDEN NAME=“gid”value=“0”> <HIDDEN NAME=“input”value=“http://aa.bb.com/ind
ex.html”> <INPUT TYPE=“submit”VALUE=“refresh”> </FORM> </HTML>

【００７４】

【数６】ＵＤＰパケットの受信に失敗した場合にはこの
ＦＯＲＭのｓｕｂｍｉｔを実行することで、 ｈｔｔｐ：／／ｈｏｓｔ．ｄｏｍａｉｎ．ｃｏｍ／Ｐｕ
ｓｈ？ ｍｅｔｈｏｄ＝ｒｅｆｒｅｓｈ ＆ｇｉｄ＝０ ＆ｉｎｐｕｔ＝ｈｔｔｐ：／／ａａ．ｂｂ．ｃｏｍ／ｉ
ｎｄｅｘ．ｈｔｍｌ に対するアクセスを行うことができる。

【００７５】リフレッシュ（ｒｅｆｒｅｓｈ）・メソッ
ドは、メソッドディスパッチャからグループ名と、原料
のＵＲＬを受けとって起動する。メンバチェック部３０
４１に対し、リクエストを出力したクライアントがグル
ープに参加していることを確認するよう指示を出す。メ
ンバチェック部３０４１は、クライアント管理テーブル
３０４４からグループ名でクライアントを検索し、リク
エストを出力したクライアントのアドレスがテーブル上
に存在するかどうかを調べる。

【００７６】メンバチェック部３０４１により、クライ
アントがグループに参加していることが確認された場
合、ＨＴＭＬ入力部３０８を介してファイルサーバ３３
０から原料のＵＲＬに相当するＨＴＭＬページを取得す
る。

【００７７】ＨＴＭＬ処理部３０９において、ファイル
サーバ３３０から取得したＨＴＭＬページを処理し、Ｈ
ＴＭＬ送信部３１０によりレスポンスとして返す。な
お、ファイルサーバは３３０はサーバ３００内部に構成
してもよく、外部に構成されたものでもよい。

【００７８】メンバチェック部３０４１により、クライ
アントがグループに参加していることが確認されない場
合、ＨＴＭＬ入力部３０８は入力を行わず、ＨＴＭＬ処
理部３０９は、チェックに失敗したことを表すＨＴＭＬ
ページを作成し、ＨＴＭＬ送信部３１０によりレスポン
スとして返す。

【００７９】ＨＴＭＬ処理部３０９の処理例を図５に示
す。図５に示すように、ＨＴＭＬ処理部３０９において
は、ＨＴＭＬの中のリンク部分を加工する処理をおこな
う。ＨＴＴＰ入力部３０８から渡されたＨＴＭＬページ
をＨＴＭＬパーザにより解析（５０１）し、内部データ
形式の解析木に変換する。さらに変換された解析木から
リンク抽出（５０２）により、ＨＴＭＬデータ中に存在
する複数のリンク部分を取り出す。取り出されたリンク
部分は、５０３においてリンクの書き換えが実行され
る。リンク書き換えは、リンク部の列の中のそれぞれの
リンクのＵＲＬをＵＲＬ修飾部５０４を用いて修飾し変
更されたリンクの列を作成する。ＵＲＬ修飾部５０４は
ＵＲＬをノーティファイ（ｎｏｔｉｆｙ）・メソッドを
呼び出すような新しいＵＲＬへのリンクにする。具体的
には、例えば以下に示すような変更が実行される。

【００８０】

【数７】ＵＲＬがｈｔｔｐ：／／ａａ．ｂｂ．ｃｏｍ／
ｉｎｄｅｘ．ｈｔｍｌであり、グループ名が０の場合、
変更後のリンクは、 ｈｔｔｐ：／／ｈｏｓｔ．ｄｏｍａｉｎ．ｃｏｍ／Ｐｕ
ｓｈ？ ｍｅｔｈｏｄ＝ｎｏｔｉｆｙ ＆ｇｉｄ＝０ ＆ｉｎｐｕｔ＝ｈｔｔｐ：／／ａａ．ｂｂ．ｃｏｍ／ｉ
ｎｄｅｘ．ｈｔｍｌ とする。

【００８１】ＨＴＭＬ生成部５０５は変更されたリンク
を含むＨＴＭＬページを生成する。このように修飾され
たファイル名をＨＴＭＬページ中に埋め込んで送信する
ことにより、クライアントが最初に指定して呼び出した
ＨＴＭＬページ中から、該ＨＴＭＬページにある他のサ
ーバの管理するリンク先データを呼び出した場合でも、
元のＨＴＭＬページを管理するサーバの制御から離れる
ことを防止でき、常にグループ管理を実行するサーバに
よる制御が可能となる。

【００８２】クライアント装置３２０にはファイル名を
含むリクエストを送信するリクエスト手段としてのＵＲ
Ｌ送信部３２１、およびレスポンスを受信するレスポン
ス手段のＵＲＬ受信部３２２がある。これは一般的なＷ
ＷＷブラウザを利用することで実現できる。ＵＲＬ生成
部はファイル名としてＵＲＬを用い、ＷＷＷクライアン
トが持つＦＯＲＭを扱う機能を利用して、ＦＯＲＭの書
式の中に埋め込まれた情報またはユーザが入力した情報
を付加してファイル名を修飾する。

【００８３】サーバー３００のＵＲＬ送信部３０６から
のファイル名の受信は、クライアント装置３２０中のＵ
ＲＬ受信部３２２によって行われる。ＵＲＬ受信部３２
２は、例えばソケットを持ちＵＤＰパケットの受信を待
つＪａｖａ Ａｐｐｌｅｔである。

【００８４】クライアント装置３２０のＵＲＬ送信部３
２１と、サーバ３００のＵＲＬ受信部によって構成され
るリクエスト手段と、サーバ装置３００のＵＲＬ送信部
３０６と、クライアント装置３２０のＵＲＬ受信部３２
２によって構成されるプッシュ手段の連係は、Ｊａｖａ
ＡｐｐｌｅｔとＪａｖａ Ｓｃｒｉｐｔなど、ＷＷＷ
クライアントとプログラムの連係手段を用いて実現され
る。

【００８５】サーバ３００からファイル名を受信したＪ
ａｖａ Ａｐｐｌｅｔは、ファイル名を含むリクエスト
をサーバ３００に対して送出するよう、ＷＷＷクライア
ントに対してＪａｖａ Ｓｃｒｉｐｔ命令を送ることが
できる。これは、例えば図６に示すようなコードをもつ
Ｊａｖａ Ａｐｐｌｅｔとして実現できる。

【００８６】サーバ３００がクライアント装置３２０か
らのリクエストを受けとって処理を実行し、クライアン
ト装置３２０にレスポンスを返す手順のフローチャート
を図７に示す。以下、図７のフローについて説明する。

【００８７】ステップ７０１において、クライアント装
置３２０のＵＲＬ送信部３２１から出力されたｈｔｔｐ
リクエストがサーバ３００のＵＲＬ受信部３０１におい
て受信される。受信されたｈｔｔｐリクエストは、ＵＲ
Ｌパーザ３０２に渡され、ＵＲＬパーザはリクエストか
らクライアントによって指定されたメソッド名、グルー
プ名を抽出する（ステップ７０２）。さらに、ステップ
７０３において、ＵＲＬパーザ３０２は、クライアント
・アドレスまたは原料ＵＲＬのいずれかを抽出する。

【００８８】ステップ７０４では、メソッドデイスパッ
チャがステップ７０２で抽出されたメソッド名に対応す
るメソッドを起動する。メソッドには、前述のようにレ
ジスト（ｒｅｇｉｓｔ）、リフレッシュ（ｒｅｆｒｅｓ
ｈ）、ノーティファイ（ｎｏｔｉｆｙ）があり、これら
のいずれかが起動される。

【００８９】レジスト（ｒｅｇｉｓｔ）が起動された場
合は、ステップ７０５以降において、クライアントのグ
ループ登録がなされる。まず、ステップ７０５において
ｈｔｔｐリクエスト中で指定され、ステップ７０２で抽
出されたグループ名に対応するグループに対してクライ
アントのアドレスおよびポートが加えられる。これは具
体的には、図４に示すクライアント管理テーブル中の指
定グループにクライアントのアドレスおよびポートを書
き込んで登録するものである。この登録は、図３中のメ
ンバ登録部３０４２において実行される。これらの登録
が終了すると、ステップ７０６でクライアント管理テー
ブルへの登録の実行終了を示すＨＴＭＬページが作成さ
れ、ステップ７０７で作成されたＨＴＭＬページがクラ
イアントに対して送信される。

【００９０】リフレッシュ（ｒｅｆｒｅｓｈ）が起動さ
れた場合は、まずステップ７０８において、ｈｔｔｐリ
クエストを送信したクライアントがグループのメンバで
あるかがチェックされる。これは、図３のメンバチェッ
ク部３０４１において行われる。グループのメンバであ
ることが確認されると、クライアントがｈｔｔｐリクエ
スト中で指定したＨＴＭＬページを取得する。これは、
図３のＨＴＭＬ入力部がファイルサーバ３３０からｈｔ
ｔｐリクエスト中のフィル名に従って抽出するものであ
る。

【００９１】さらに、ステップ７１０において取得ＨＴ
ＭＬのパーズ(解析)を実行し、ＨＴＭＬページ中のリン
ク部のＵＲＬを抽出する（ステップ７１１）。次にステ
ップ７１２においてステップ７１１で抽出されたＨＴＭ
Ｌページ中のリンク部のＵＲＬの修飾部の変更を行いノ
ーティファイ（ｎｏｔｉｆｙ）・メソッドを呼び出すよ
うに変更を加え、リンクのＵＲＬを変更したＨＴＭＬペ
ージを生成する（ステップ７１３）。このリンク部ＵＲ
Ｌの変更は、前述の図５において説明した変更処理であ
り、例えば先に説明した数５のごとき変更がリンクＵＲ
Ｌに実行される。この処理によってクライアントが呼び
出したＨＴＭＬページ中から、該ＨＴＭＬページにある
他のサーバの管理するリンク先データを呼び出した場合
でも、元のＨＴＭＬページを管理するサーバの制御から
離れることを防止でき、常にグループ管理を実行するサ
ーバによる制御が可能となる。このようにして生成され
たＨＴＭＬページがレスポンスとしてＨＴＭＬ送信部３
１０からクライアントのＨＴＭＬ受信・表示部３２３に
送信される。

【００９２】ノーティファイ（ｎｏｔｉｆｙ）が起動さ
れた場合は、まず、ステップ７１５において、リフレッ
シュ（ｒｅｆｒｅｓｈ）・メソッドを呼び出すＵＲＬが
生成され、さらに、ステップ７１６においてｈｔｔｐリ
クエストを出力したクライアントの属するグループ中の
他のクライアントのアドレス、およびポートを獲得す
る。これは図３のメンバ配信部３０４３においてクライ
アント管理テーブル３０４４（図４参照）を検索するこ
とによって実行される。次にステップ７１７において、
獲得されたアドレスおよびポートを指定してＵＲＬを含
むパケットの送信を行う。これらの処理が終了すると、
ステップ７１８において実行終了を示すＨＴＭＬページ
が作成され、ステップ７１９で作成されたＨＴＭＬペー
ジがクライアントに対して送信される。ステップ７１５
でリフレッシュ（ｒｅｆｒｅｓｈ）・メソッドを呼び出
すＵＲＬが生成されており、サーバはこのＵＲＬの受信
により、さらにステップ７０８以降の処理を行うことに
なる。

【００９３】一方、クライアント装置３２０がサーバ３
００から配信された情報にしたがってＨＴＴＰアクセス
を行なう手順のフローチャートを図８に示す。ステップ
８０１ではクライアント装置においてＵＤＰパケットが
受信され、ステップ８０２において受信されたＵＤＰパ
ケットからＵＲＬ文字列が抽出され、ステップ８０３に
おいてＵＲＬロードのＪａｖａ Ｓｃｒｉｐｔ命令が実
行される。さらに、ステップ８０４でブラウザが命令を
実行し、ステップ８０２で抽出された ＵＲＬに対す
るＨＴＴＰリクエストがなされる。ステップ８０５で
は、ステップ８０４のリクエストに応答して送信された
ＨＴＭＬを受信する。

【００９４】上述したサーバおよびクライアント間のメ
ッセージおよびデータのながれを時系列的に示したのが
図９である。図９では１つのサーバに対し、複数のクラ
イアントがアクセスし、サーバの各メソッドを呼び出し
て、情報配信を行なう際の、メッセージおよびデータの
流れを示している。図の上部から下方に向かって時間的
に経過している。

【００９５】図９に示すように、１つのサーバとｎ個の
クライアントがあり、その間でＨＴＴＰのリクエスト、
レスポンスおよびＵＲＬをふくんだＵＤＰ ｐａｃｋｅ
ｔにより情報がやりとりされる。

【００９６】図９中の上部の各クライアントからのＨＴ
ＴＰリクエスト：ＵＲＬ１、ＵＲＬ１’は、図９下のＵ
ＲＬ説明に示すようにレジスト（ｒｅｇｉｓｔ）・メソ
ッドの起動を指定するものであり、各クライアントから
のリクエストに対して、サーバは、図７におけるステッ
プ７０５〜７０７の処理を実行し、登録処理を行って結
果ページをそれぞれのクライアントに送信している。

【００９７】クライアントをグループに登録する手順
は、以下のように行われる。クライアント１がグループ
０に加入する際には、サーバに対して、クライアント１
のアドレス、ポートおよびグループ名０を含んだＵＲＬ
１でＨＴＴＰリクエストを送信する。サーバ上ではレジ
スト（ｒｅｇｉｓｔ）・メソッドが実行される。また、
その他のクライアントがグループ０に加入する際には、
各クライアントからサーバに対して、それぞれのクライ
アントのアドレス、ポートおよびグループ名０を含んだ
ＵＲＬ１’でＨＴＴＰリクエストを送信する。サーバ上
ではレジスト（ｒｅｇｉｓｔ）・メソッドが実行され
る。ｒｅｇｉｓｔメソッドの実行後、サーバから実行終
了を表す結果ページがレスポンスとしてグループに加入
したクライアントに送信される。

【００９８】図９中の中段に示すＵＲＬ２は、図９下の
ＵＲＬ説明に示すようにノーティファイ（ｎｏｔｉｆ
ｙ）・メソッドの起動をＵＲＬ中で指定するものであ
り、クライアント１からのリクエストに対して、サーバ
は、図７におけるステップ７１５〜７１９の処理を実行
する。ステップ７１７に対応する処理は、グループに属
するクライアントに対してのパケット送信（図９中、配
信用ＵＤＰ ｐａｃｋｅｔＵＲＬ３を含む）である。さ
らに、それぞれのパケット送信を受けたクライアントか
らＨＴＴＰリクエストＵＲＬ３がサーバに対して実行さ
れる。このリクエストは、図７のステップ７１５におい
てリフレッシュ（ｒｅｆｒｅｓｈ）・メソッドを起動す
るように設定されたＵＲＬ（図９下欄のＵＲＬ３参照）
であり、サーバはそれぞれのＨＴＴＰリクエストＵＲＬ
３に応答してリフレッシュ（ｒｅｆｒｅｓｈ）・メソッ
ドを起動して図７のステップ７０８〜７１４を実行す
る。その結果としてそれぞれのリクエストクライアント
に対してＨＴＭＬページが配信される。

【００９９】図９の中段に示すクライアント１からのＵ
ＲＬ２の送信以降の処理をまとめると以下のようにな
る。クライアント１からサーバに対して、グループ名
０、配信対象のＵＲＬを含むＵＲＬ２が送られ、サーバ
上ではリクエストに従ってノーティファイ（ｎｏｔｉｆ
ｙ）・メソッドが実行される。サーバから実行終了を表
す結果ページがレスポンスとしてクライアント１に送信
される。サーバーは、さらにメソッド名リフレッシュ
（ｒｅｆｒｅｓｈ）、グループ名０、および対象ページ
のＵＲＬを含むＵＲＬ３を作成し、ＵＲＬ３をデータと
して持つＵＤＰパケットを作成する。作成されたパケッ
トは、グループ０に属する各クライアントに対して送信
される。ＵＤＰパケットを受信した各クライアントはＵ
ＲＬ３を使ってＨＴＴＰリクエストを送信し、サーバで
はリフレッシュ（ｒｅｆｒｅｓｈ）・メソッドが実行さ
れる。サーバではリフレッシュ（ｒｅｆｒｅｓｈ）・メ
ソッドが起動し、リンク部に修飾名を埋め込んだＨＴＭ
Ｌページを作成し、レスポンスとしてクライアントに送
信する。

【０１００】以上、本発明の通信ネットワークシステム
の一実施例を説明したが、この実施例によれば、あるグ
ループに属するユーザがＷＷＷクライアントを用いて閲
覧するＨＴＭＬページを、同じグループに参加する複数
のユーザの間で共有することが可能となる。つまり、あ
るユーザがサーバに管理されたあるＨＴＭＬページを閲
覧した際に、同じグループに属する他のクライアントも
同じページを閲覧することが可能となる。

【０１０１】さらにあるグループに属するクライアント
が共有するファイル（ＨＴＭＬページ）について、任意
のタイミングでクライアントによって更新がなされた場
合、グループに属するクライアントは、その更新タイミ
ングが不定期であってもサーバからの通知を随時受領す
ることが可能であり、情報更新に関してグループに属す
るクライアントは特別な操作をする必要がなく、また、
クライアントからサーバーに対するＨＴＴＰリクエスト
を出す回数は必要最低限におさえられる。また、グルー
プ内で共有するＨＴＭＬページが保持されている場所に
関して制限がなく、ネットワークで接続可能な多数のＷ
ＷＷサーバー上の情報が扱える。

【０１０２】なお、上述の実施例１で述べた構成以外に
も、ＷＷＷサーバーとして他のものを用いることも可能
であり、サーバー上のプログラムの起動方法はＣＧＩを
用いることが可能である。また、クライアント側におい
ては、Ｊａｖａ Ａｐｐｌｅｔ以外の形態のプログラム
をＷＷＷクライアントと連係させることによっても実現
が可能である。

【０１０３】［実施例２］以下、クライアントがグルー
プに参加する際にグループ内で共通のマルチキャストグ
ループに参加し、サーバからクライアントに対して情報
配信をおこなう際にはマルチキャストを用いて配信する
実施例について説明する。

【０１０４】図１０に本実施例の通信ネットワークシス
テムのブロック図を示す。本実施例の構成は図３に示し
た実施例１の構成にマルチキャストルータ及びネットワ
ーク１００１、サーバ側のマルチキャストグループ参加
部１００２、およびクライアント側のマルチキャストグ
ループ参加部１００３を付加したものである。

【０１０５】グループ管理プログラムのクライアント管
理テーブルには、グループごとにクライアントが参加し
ているマルチキャストグループのアドレスが保持されて
いる。このクライアント管理テーブルの例を図１１に示
す。図１１に示すようにテーブルにはクライアント・ア
ドレスの他にグループ個々に対応してマルチキャストグ
ループのアドレスが登録されている。

【０１０６】サーバの有するグループ管理プログラムに
は、指定したグループ名に属するクライアントに情報を
送るため、マルチキャストをつかって情報を送信するノ
ーティファイ（ｎｏｔｉｆｙ）・メソッドが予め設定さ
れている。グループ管理プログラムの実行の際には、グ
ループを生成したときにＩＧＭＰ（ＩｎｔｅｒｎｅｔＧ
ｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）
メッセージを送信してサーバ自体をマルチキャストグル
ープに参加させるマルチキャストグループ参加部１００
２が利用される。サーバ内のグループにクライアントを
追加する手段は、クライアントのアドレスをグループ管
理テーブルに追加し、グループのメンバのチェックに用
いる。クライアントはグループに参加する際に、ＩＧＭ
Ｐメッセージを送信してマルチキャストグループに参加
するためにマルチキャストグループ参加部１００３を有
する。他の構成は図３に示す実施例１と同様であり、前
述した実施例１と同様の効果を得ることができ、サーバ
からクライアントにＵＲＬを配信する際にマルチキャス
トを利用する構成が可能となる。

【０１０７】また、１つのサーバに対し、複数のクライ
アントがアクセスし、サーバの各メソッドを呼び出し
て、情報配信を行なう際の、メッセージおよびデータの
ながれを図１２に示す。

【０１０８】図１２に示すように、１つのサーバとｎ個
のクライアントがあり、それぞれはマルチキャストルー
タに接続されている。サーバ、クライアント間ではＨＴ
ＴＰのリクエスト、レスポンスおよびＵＲＬをふくんだ
ＵＤＰ ｐａｃｋｅｔにより情報がやりとりされる。

【０１０９】クライアントを、あるグループに加入させ
る手順は、以下のように実行される。前述したようにサ
ーバの有するクライアント管理テーブルは、各グループ
名とマルチキャストグループのアドレスが対応づけられ
て登録されている(図１１参照)。すなわち、クライアン
トおよびサーバ間では、各グループ名とマルチキャスト
グループのアドレスの対応が共有されている。

【０１１０】サーバは、グループ生成時にルータに対し
てＩＧＭＰメッセージを送信し、マルチキャストグルー
プに参加する。

【０１１１】クライアント１がグループ０に加入する際
には、ルータに対してＩＧＭＰメッセージを送信し、グ
ループ０に対応するマルチキャストグループに参加す
る。次にサーバに対して、クライアント１のアドレスお
よびグループ名０を含んだＵＲＬ１（メソッドとしてレ
ジストを指定：図１２の下欄のＵＲＬ説明参照）でＨＴ
ＴＰリクエストを送信する。サーバ上ではリクエストに
従って、レジスト（ｒｅｇｉｓｔ）・メソッドが実行さ
れる。

【０１１２】また、その他のクライアント２−ｎがグル
ープ０に加入する際には、ルータに対してＩＧＭＰメッ
セージを送信することで、各クライアント２−ｎはグル
ープ０に対応するマルチキャストグループに参加するこ
とが可能となる。次にサーバに対して、それぞれのクラ
イアントのアドレスおよびグループ名０を含んだＵＲＬ
１’でＨＴＴＰリクエストを送信する。サーバ上ではレ
ジスト（ｒｅｇｉｓｔ）・メソッドが実行される。

【０１１３】サーバにおけるレジスト（ｒｅｇｉｓｔ）
・メソッドの実行後、サーバから実行終了を表す結果ペ
ージがレスポンスとしてグループに加入したクライアン
トに送信される。以上が図１２の上段に示すＨＴＴＰリ
クエストＵＲＬ１、ＵＲＬ１’に対する処理である。

【０１１４】図１２の中段以降のＨＴＴＰリクエストＵ
ＲＬ２に対する処理、すなわちクライアントが指定した
ＨＴＭＬの情報を配信する手順は、以下のようにおこな
われる。クライアント１が配信の要求を出すとすると、
クライアント１からサーバに対して、グループ名０、配
信対象のＵＲＬを含むＵＲＬ２が送られ、サーバ上では
ＵＲＬ２に指定されたメソッド（図１２の下欄のＵＲＬ
２の詳細参照）に従ってノーティファイ（ｎｏｔｉｆ
ｙ）・メソッドが実行され、サーバから実行終了を表す
結果ページがレスポンスとしてクライアント１に送信さ
れる。

【０１１５】さらに、サーバーは、メソッド名リフレッ
シュ（ｒｅｆｒｅｓｈ）、グループ名０、および対象ペ
ージのＵＲＬを含むＵＲＬ３を作成し、ＵＲＬ３をデー
タとして持つＵＤＰパケットを作成する。さらに、グル
ープ０に対応するマルチキャストグループのアドレスに
対して作成してＵＤＰパケットを送信する。

【０１１６】本実施例では、マルチキャストを用いて、
各クライアントに上記のＵＤＰパケットが配信される。
ＵＤＰパケットを受信した各クライアントはＵＲＬ３を
使ってＨＴＴＰリクエストを送信し、サーバではＵＲＬ
３（図１２の下欄のＵＲＬ３の詳細参照）に指定された
リフレッシュ（ｒｅｆｒｅｓｈ）・メソッドが実行され
る。サーバではリフレッシュ（ｒｅｆｒｅｓｈ）・メソ
ッドが起動し、作成したＨＴＭＬページがレスポンスと
して送信される。

【０１１７】図１３にサーバがクライアント装置からの
リクエストを受けとって処理を実行し、クライアント装
置にレスポンスを返す手順のフローチャートを示す。図
１３のフローは、多くの部分が図７に共通するものであ
り、図７と異なる部分を中心として説明する。

【０１１８】ステップ１３０１において、サーバは、マ
ルチキャストグループの指定をおこなってグループへの
参加を行う。このマルチキャストグループは、図１１に
示すクライアント管理テーブルに登録されたグループの
いずれかである。ステップ１３０２では、クライアント
からのＨＴＴＰリクエストを待機する。以降のステップ
１３０３〜１３０６は、図７のステップ７０１〜７０４
と同様である。

【０１１９】レジスト（ｒｅｇｉｓｔ）・メソッドが起
動された場合の処理ステップ１３０７〜１３０９、およ
びリフレッシュ（ｒｅｆｒｅｓｈ）・メソッドが起動さ
れた場合の処理ステップ１３１０〜１３１６は図７と同
様である。ノーティファイ（ｎｏｔｉｆｙ）・メソッド
が起動された場合は、ステップ１３１７において、クラ
イアント管理テーブルからグループに対するマルチキャ
ストグループを得る処理が実行される。これは、ステッ
プ１３１９で実行されるマルチキャストを介するパケッ
ト配信のために行われる。マルチキャストの利用によ
り、図７のステップ７１６のグループに属するメンバア
ドレスの取得は省略される。その他の処理ステップ１３
１８、１３２０、１３２１は図７のステップ７１５、７
１８、７１９と対応する。

【０１２０】一方、本実施例においてクライアント装置
がサーバから配信された情報に従ってＨＴＴＰアクセス
を行なう手順のフローチャートを図１４に示す。図１４
のフローは、多くの部分が図８に共通するものであり、
図８と異なる部分を中心として説明する。

【０１２１】まず、クライアント装置はステップ１４０
１においてマルチキャストグループの指定および参加を
実行し、ステップ１４０２においてマルチキャストを介
したパケットの受信を待機する。以降の処理ステップ１
４０３〜１４０７は、図８のステップ８０１〜８０５と
同様の処理である。

【０１２２】［実施例３］次に、サーバのグループ管理
手段がグループごとにグループの状態を保持する状態デ
ータを持つ実施例について説明する。この実施例におい
ては、同じグループ内で共有し、かつグループ外のクラ
イアントからはアクセスされない内部情報をグループ内
の各クライアントが変更することと、該変更をグループ
内の各クライアントに対して通知することが可能にな
る。

【０１２３】本実施例に係る構成ブロック図を図１５に
示す。基本的構成は前述の実施例１の構成と同様であ
り、異なる部分を中心として説明する。グループの状態
を保持するグループ管理手段１５０１は、実施例１にお
いて述べたと同様、クライアント管理テーブル１５０６
を有している。本実施例のクライアント管理テーブル１
５０６は、内部情報保持部１５０７を有している。

【０１２４】図１６に本実施例中のクライアント管理テ
ーブル１５０６の例を示す。図１６に示すようにクライ
アント管理テーブルは、登録されたグループ名ごとに、
複数のクライアント情報（ＩＰアドレス、ポートアドレ
ス）と一つの内部情報（グループ内情報）を保持する。
内部情報としてはＨＴＭＬ文書を用いる。

【０１２５】本実施例においては、メソッドインタプリ
タから起動されるメソッドとして、指定したグループの
内部情報のＨＴＭＬ文書を変更するメソッドとしてエデ
ィット（ｅｄｉｔ）・メソッドが新たに加えられてい
る。

【０１２６】エディット（ｅｄｉｔ）・メソッドは、ク
ライアント管理テーブルからグループ名に対応するＨＴ
ＭＬファイルを取得し、取得したＨＴＭＬファイルに変
更処理をおこない、テーブルに登録する。その後、ノー
ティファイ（ｎｏｔｉｆｙ）・メソッドを起動する。

【０１２７】ノーティファイ（ｎｏｔｉｆｙ）・メソッ
ドは、実施例１と同様に、修飾したＵＲＬを生成し、ク
ライアントに配信するが、この実施例では、サーバ上に
保持されているグループ固有のＨＴＭＬ文書を参照する
リフレッシュ（ｒｅｆｒｅｓｈ）・メソッドを起動する
ＵＲＬを生成する。

【０１２８】クライアントは第１の実施例と同様に、配
信されたＵＲＬをもちいてリクエストを送出する。グル
ープの状態を参照するメソッドが、リフレッシュ（ｒｅ
ｆｒｅｓｈ）・メソッドとして実現される。リフレッシ
ュ（ｒｅｆｒｅｓｈ）・メソッドは、グループ名からＨ
ＴＭＬ文書を取得する部分と、ＨＴＭＬ文書をＨＴＴＰ
レスポンスとしてクライアントへ送信する部分からな
る。

【０１２９】以上の構成により、あるグループに属する
クライアントが、グループが持つＨＴＭＬ文書を変更す
る要求をサーバに送った場合に、グループの他のクライ
アントは変更された文書を取得する。

【０１３０】本実施例におけるサーバの処理フローを図
１７に示す。図１７において、最初のｈｔｔｐリクエス
ト受信ステップからメソッドディスパッチャによるメソ
ッド起動までのステップと、レジスト（ｒｅｇｉｓｔ）
・メソッドの実行ステップは、前述の実施例１と同様で
あり説明を省略する。

【０１３１】本実施例においてリフレッシュ（ｒｅｆｒ
ｅｓｈ）・メソッドが起動された場合は、ステップ１７
０１、１７０２、１７０３においてグループのメンバの
であるかのチェック、共有ＨＴＭＬページの取得、取得
ＨＴＭＬページの送信が実行される。これらの処理は、
図１５のメンバチェック部１５０３、およびＨＴＭＬ入
力部１５１０、およびＨＴＭＬ送信部において実行され
る。

【０１３２】本実施例特有のエディット（ｅｄｉｔ）・
メソッドが起動されると、ステップ１７１１以降の処理
が実行される。ステップ１７１１では、グループ内のメ
ンバであるかについてチェックされ、ステップ１７１２
において当グループの共有ＨＴＭＬページが取得され
る。これは、クライアント管理テーブルにグループ内情
報として登録されたＨＴＭＬページ(図１６参照)であ
る。ステップ１７１３において取得されたＨＴＭＬペー
ジがクライアントの要求に従って編集されると、ステッ
プ１７１４においてノーティファイ（ｎｏｔｉｆｙ）・
メソッドが呼び出される。以降のステップ１７１５〜１
７１９は、実施例１で示した図７のステップ７１５〜７
１９の処理と同様である。

【０１３３】上述したように、エディット（ｅｄｉｔ）
・メソッドの起動が可能な本実施例の構成によれば、グ
ループに対応する特定の情報を同じグループ内で共有
し、かつグループ外のクライアントからはアクセスされ
ない状態で保持することが可能であり、この内部情報を
グループ内の各クライアントが変更し、該変更をグルー
プ内の各クライアントに対して通知することが可能にな
る。

【０１３４】本実施例におけるサーバおよびクライアン
ト間のメッセージおよびデータのながれを時系列的に示
したのが図１８である。図１８では１つのサーバに対
し、複数のクライアントがアクセスし、サーバの各メソ
ッドを呼び出して、情報配信を行なう際の、メッセージ
およびデータの流れを示している。図の上部から下方に
向かって時間的に経過している。

【０１３５】図１８における上段のレジスト（ｒｅｇｉ
ｓｔ）・メソッドの処理は、前述した実施例で説明した
図９の処理と同様であるので説明を省略する。図１８中
の中段に示すＵＲＬ２は、図１８下欄のＵＲＬの説明に
示すようにエディット（ｅｄｉｔ）・メソッドの起動を
指定するものであり、クライアント１からのリクエスト
に対して、サーバは、図１７におけるステップ１７１１
以下の処理を実行することとなる。ステップ１７１７に
対応する処理は、グループに属するクライアントに対し
てのパケット送信（図１７中、配信用ＵＤＰ ｐａｃｋ
ｅｔ ＵＲＬ３を含む）である。さらに、それぞれのパ
ケット送信を受けたクライアントからＨＴＴＰリクエス
トＵＲＬ３がサーバに対して実行される。このリクエス
トは、図１７のステップ１７１５においてリフレッシュ
（ｒｅｆｒｅｓｈ）・メソッドを起動するように設定さ
れたＵＲＬ（図１８下欄のＵＲＬ３参照）であり、サー
バはそれぞれのＨＴＴＰリクエストＵＲＬ３に応答して
リフレッシュ（ｒｅｆｒｅｓｈ）・メソッドを起動して
図１７のステップ１７０１〜１７０３を実行する。その
結果としてそれぞれのリクエストクライアントに対して
ＨＴＭＬページが配信される。

【０１３６】以上説明したエディット（ｅｄｉｔ）・メ
ソッドの起動による処理をまとめると以下のようにな
る。クライアント１がＨＴＭＬページの編集の要求を出
すと、クライアント１からサーバに対して、グループ名
０を含むＵＲＬ２が送られ、サーバ上でエディット（ｅ
ｄｉｔ）・メソッドが起動し、グループ名０に対応した
ＨＴＭＬの編集が行なわれる。エディット（ｅｄｉｔ）
・メソッドによるＨＴＭＬページの編集が終了した後、
サーバ上でノーティファイ（ｎｏｔｉｆｙ）・メソッド
が実行される。

【０１３７】サーバーは、メソッド名としてリフレッシ
ュ（ｒｅｆｒｅｓｈ）、グループ名として０を含むＵＲ
Ｌ３を作成し、ＵＲＬ３をデータとして持つＵＤＰパケ
ットを作成する。グループ０に属する各クライアントに
対してＵＤＰパケットを送信する。

【０１３８】ＵＤＰパケットを受信した各クライアント
はＵＲＬ３を使ってＨＴＴＰリクエストを送信し、サー
バではリフレッシュ（ｒｅｆｒｅｓｈ）・メソッドが実
行される。サーバにおけるリフレッシュ（ｒｅｆｒｅｓ
ｈ）・メソッドの起動により作成されたＨＴＭＬページ
がレスポンスとして送信される。

【０１３９】実施例１においては分散したＷＷＷサーバ
上のアクセスが公開された情報についての共有を可能と
したが、この実施例においては、グループに属する複数
のユーザー間で共有する内部データを、各ユーザがＷＷ
Ｗクライアントを用いて変更するなどの処理を行ない、
サーバ上に保持される共有データが変更された際にはユ
ーザーはその結果を自動的に受けとることが可能にな
る。

【０１４０】［実施例４］次に、本発明の他の実施例と
して、リフレッシュ（ｒｅｆｒｅｓｈ）・メソッドの起
動により、ノーティファイ（ｎｏｔｉｆｙ）・メソッド
が自動的に実行される実施例にいて説明する。本実施例
においても、上述の他の実施例と同様に基本構成は、ネ
ットワークに接続されたｗｗｗサーバーの動作する計算
機およびｗｗｗクライアントの動作する複数の計算機に
よって構成される。

【０１４１】情報配信をおこなうサーバおよびクライア
ントの構成を図１９に示す。この例においても分散ファ
イルアクセスは、ＨＴＴＰによるアクセスであるものと
して説明する。図１９の構成は基本的に前述の実施例１
で説明した図３の構成と同様の構成を有し、異なる部分
についてのみ説明する。

【０１４２】図１９のメソッドインタプリタ１９０１に
よって起動されるメソッドは、基本的にリフレッシュ
（ｒｅｆｒｅｓｈ）・メソッドと、レジスト（ｒｅｇｉ
ｓｔ）・メソッドである。ノーティファイ（ｎｏｔｉｆ
ｙ）・メソッドは、リフレッシュ（ｒｅｆｒｅｓｈ）・
メソッドの実行に引き続いて実行されるように構成され
ている。

【０１４３】リフレッシュ（ｒｅｆｒｅｓｈ）・メソッ
ドは、メソッドインタプリタ１９０１からグループ名
と、原料のＵＲＬを受けとって起動する。メンバチェッ
ク部１９０３に対し、リクエストを出力したクライアン
トがグループに参加していることを確認するよう指示を
出す。メンバチェック部１９０３は、クライアント管理
テーブル１９０６からグループ名でクライアントを検索
し、リクエストを出力したクライアントのアドレスがテ
ーブル上に存在するかどうかを調べる。本実施例で使用
されるクライアント管理テーブルは、上述の各実施例に
おける各種のテーブルが適用できるが、実施例１のテー
ブル（図４参照）を使用したものとして以下、説明す
る。

【０１４４】メンバチェック部１９０６によるクライア
ント管理テーブル１９０６の検索の結果、クライアント
がグループに参加していることが確認されない場合は、
チェックに失敗したことを表すＨＴＭＬページを作成
し、ＨＴＭＬ送信部によりレスポンスとして返す。

【０１４５】メンバチェック部１９０６によるクライア
ント管理テーブル１９０６の検索の結果、クライアント
がグループに参加していることが確認された場合、ノー
ティファイ（ｎｏｔｉｆｙ）・メソッドを起動する。ノ
ーティファイ（ｎｏｔｉｆｙ）・メソッドは、グループ
名と、原料のＵＲＬを受けとって起動する。

【０１４６】サーバにおけるメンバ配信部１９０５は、
クライアント管理テーブル１９０６から指定されたグル
ープに属するクライアントの＜ＩＰアドレス、ＵＤＰソ
ケットのポート番号＞を得る。ＵＲＬをデータとして含
むＵＤＰパケットを生成し、ＵＲＬ送信部からそれぞれ
のクライアントに送信する。

【０１４７】サーバがクライアント装置からのリクエス
トを受けとって処理を実行し、クライアント装置にレス
ポンスを返す手順のフローチャートを図２０に示す。以
下、図２０のフローについて説明する。

【０１４８】図２０において、最初のｈｔｔｐリクエス
ト受信ステップからメソッドディスパッチャによるメソ
ッド起動までのステップと、レジスト（ｒｅｇｉｓｔ）
・メソッドの実行ステップは、前述の実施例１で説明し
た図７と同様のステップであり説明を省略する。

【０１４９】本実施例においてリフレッシュ（ｒｅｆｒ
ｅｓｈ）・メソッドが起動された場合は、ステップ２０
０１においてグループのメンバのであるかのチェックが
実行され、引き続いてステップ２００２において、ノー
ティファイ（ｎｏｔｉｆｙ）・メソッドが呼び出され
る。

【０１５０】以降、ステップ２００３以降ステップ２０
０６まで実施例１で説明した図７のステップ７１６から
ステップ７１９と同様のステップが実行される。本実施
例の構成によればリフレッシュ（ｒｅｆｒｅｓｈ）・メ
ソッドの起動が自動的にノーティファイ（ｎｏｔｉｆ
ｙ）を起動するので、クライアントによるリフレッシュ
（ｒｅｆｒｅｓｈ）・メソッドの指定を修飾してＵＲＬ
指定を行った場合、自動的なＵＤＰパケット配信がグル
ープ内のクライアントに行われる。

【０１５１】本実施例における、１つのサーバと複数の
クライアント間でのメッセージおよびデータのながれを
時系列的に示すと図２１のようになる。図２１では１つ
のサーバに対し、複数のクライアントがアクセスし、サ
ーバの各メソッドを呼び出して、情報配信を行なう際
の、メッセージおよびデータの流れを示している。図の
上部から下方に向かって時間的に経過している。

【０１５２】図２１における上段のレジスト（ｒｅｇｉ
ｓｔ）・メソッドの処理は、前述した実施例で説明した
図９の処理と同様であるので説明を省略する。図２１中
の中段に示すＵＲＬ２は、図２１下欄のＵＲＬの説明に
示すようにリフレッシュ（ｒｅｆｒｅｓｈ）・メソッド
の起動を指定するものであり、クライアント１からのリ
クエストに対して、サーバは、図２０におけるステップ
２００１以下を実行する。

【０１５３】図２１中の中段に示すＵＲＬ２によるリク
エストに対する処理であるクライアントが指定したＨＴ
ＭＬの情報を配信する手順は、以下のようにおこなわれ
る。クライアント１があるＵＲＬで表されるファイルを
読み出す要求を出すとき、クライアント１からサーバに
対して、グループ名０、配信対象のＵＲＬを含むＵＲＬ
２を送る。サーバ上ではＵＲＬ２の指定に従ってリフレ
ッシュ（ｒｅｆｒｅｓｈ）・メソッドが実行される。図
２０で説明したようにリフレッシュ（ｒｅｆｒｅｓｈ）
・メソッドの起動により、サーバは、自動的にノーティ
ファイ（ｎｏｔｉｆｙ）・メソッドを起動する。

【０１５４】さらに、サーバーは、読みだし対象となる
ＵＲＬ（ＵＲＬ３）をデータとして持つＵＤＰパケット
を作成する。次いでグループ０に属する各クライアント
に対してＵＤＰパケットを送信する。

【０１５５】ＵＤＰパケットを受信した各クライアント
はＵＲＬ３を使ってＨＴＴＰリクエストをサーバに対し
て送信し、ファイルサーバからページがレスポンスとし
て各クライアントに送信される。

【０１５６】本実施例においては、サーバの管理するグ
ループに属する１つのクライアントが、あるＨＴＭＬペ
ージを閲覧した時、同じグループに参加する複数のクラ
イアントは、同じＨＴＭＬを表示することが可能とな
る。また、対象となるＨＴＭＬページが保持されている
場所に関して制限がなく、ネットワークで接続可能な多
数のＷＷＷサーバー上の情報が扱える。

【０１５７】ここで述べた実現の方法は情報配信を行な
う装置の実装の一例である。ＷＷＷサーバーとして他の
ものを用いることも可能であり、サーバー上のプログラ
ムの起動方法はＣＧＩを用いることが可能である。

【０１５８】また、クライアント側においては、、Ｊａ
ｖａ Ａｐｐｌｅｔ以外の形態のプログラムをＷＷＷク
ライアントと連係させることによっても実現が可能であ
る。

【０１５９】

【発明の効果】以上説明したように、本発明のデータ通
信システムによれば、所定のグループに属するクライア
ントからのファイルアクセス要求を受領したサーバは、
該クライアントからのファイル要求に伴って指定された
メソッドを起動して、ファイルアクセス要求を実行した
クライアントと同一のグループに属する他のクライアン
トに対する処理を実行するように構成したので、複数の
クライアントが共有するファイルに対する更新、閲覧処
理に等に対して、所定の必要な通知を最適なタイミング
で実行することが可能となる。

【図面の簡単な説明】

【図１】 本発明のデータ通信システムの全体概要を示
すブロック図である。

【図２】 本発明のデータ通信システムの基本構成を示
すブロック図である。

【図３】 本発明のデータ通信システムの実施例１にお
ける構成を示すブロック図である。

【図４】 本発明のデータ通信システムの実施例１にお
けるクライアント管理テーブルの例を示す図である。

【図５】 本発明のデータ通信システムにおけるＨＴＭ
Ｌ処理部の処理を説明する図である。

【図６】 本発明のデータ通信システムにおいて、ファ
イル名を受信したサーバにおける処理実行プログラムの
例である。

【図７】 本発明のデータ通信システムの実施例１にお
けるサーバの処理フローを説明する図である。

【図８】 本発明のデータ通信システムの実施例１にお
けるクライアントの処理フローを説明する図である。

【図９】 本発明のデータ通信システムの実施例１にお
けるサーバおよびクライアント間のメッセージおよびデ
ータの流れを説明する図である。

【図１０】 本発明のデータ通信システムの実施例２に
おける構成を示すブロック図である。

【図１１】 本発明のデータ通信システムの実施例２に
おけるクライアント管理テーブルの例を示す図である。

【図１２】 本発明のデータ通信システムの実施例２に
おけるサーバおよびクライアント間のメッセージおよび
データの流れを説明する図である。

【図１３】 本発明のデータ通信システムの実施例２に
おけるサーバの処理フローを説明する図である。

【図１４】 本発明のデータ通信システムの実施例２に
おけるクライアントの処理フローを説明する図である。

【図１５】 本発明のデータ通信システムの実施例３に
おける構成を示すブロック図である。

【図１６】 本発明のデータ通信システムの実施例３に
おけるクライアント管理テーブルの例を示す図である。

【図１７】 本発明のデータ通信システムの実施例３に
おけるサーバの処理フローを説明する図である。

【図１８】 本発明のデータ通信システムの実施例３に
おけるサーバおよびクライアント間のメッセージおよび
データの流れを説明する図である。

【図１９】 本発明のデータ通信システムの実施例４に
おける構成を示すブロック図である。

【図２０】 本発明のデータ通信システムの実施例４に
おけるサーバの処理フローを説明する図である。

【図２１】 本発明のデータ通信システムの実施例４に
おけるサーバおよびクライアント間のメッセージおよび
データの流れを説明する図である。

【符号の説明】

１０１ ファイルサーバ １０２ クライアント・グループＡ １０３ クライアント・グループＢ ２００ サーバ ２０１ 受信部 ２０２ ファイル解析手段 ２０３ デイスパッチ手段 ２０４ グループ管理手段 ２０５ 修飾手段 ２０６，２０７ 送信部 ２０８ ファイルサーバ ２２０ クライアント装置 ２２１ 送信部 ２２２，２２３ 受信部 ２２４ 表示部 ２４１ リクエスト手段 ２４２ プッシュ手段 ２４３ レスポンス手段 ３００ サーバ ３０１ ＵＲＬ受信部 ３０２ ＵＲＬパーザ ３０３ メソッドインタプリタ ３０４ クループ管理手段 ３０５ ＵＲＬ修飾部 ３０６ ＵＲＬ送信部 ３０７ 登録結果生成部 ３０８ ＨＴＭＬ入力部 ３０９ ＨＴＭＬ処理部 ３１０ ＨＴＭＬ送信部 ３２０ クライアント装置 ３２１ ＵＲＬ送信部 ３２２ ＵＲＬ受信部 ３２３ ＨＴＭＬ受信・表示部 ３３０ ファイルサーバ １００１ マルチキャストルータ及びネットワーク １００２，１００３ マルチキャストグループ参加部 １５０１ グループ管理手段 １５０２，１５０３ メンバチェック部 １５０４ メンバ登録部 １５０５ メンバ配信部 １５０６ クライアント管理テーブル １５０７ 内部情報保持部 １５０８，１５１０ ＨＴＭＬ入力部 １５０９ ＨＴＭＬ編集部 １５１１ 登録結果生成部 １５１２ ＵＲＬ修飾部 １５１３ ＵＲＬ送信部 １９０１ メソッドインタプリタ １９０２ グループ管理手段 １９０３ メンバチェック部 １９０４ メンバ登録部 １９０５ メンバ配信部 １９０６ クライアント管理テーブル

Claims (15)

【特許請求の範囲】
1. 【請求項１】 複数のデータファイルを管理するサーバ
   と、 データ通信手段によって前記サーバに接続可能な構成を
   有し、前記サーバの管理する複数のデータファイルから
   特定のデータファイルを指定したリクエストを前記サー
   バに対して出力し、該データファイルを閲覧可能な複数
   のクライアント装置とを有するデータ通信システムにお
   いて、 前記クライアントは、前記サーバの管理するデータファ
   イル中、特定のデータファイルを共有する１以上のクラ
   イアントによってグループを構成し、 前記クライアントは、前記サーバに対するデータファイ
   ルリクエストにおいて、前記サーバ中で起動可能な１以
   上の処理フローである１以上のメソッド中から特定の実
   行メソッドを指定するメソッド識別子と、前記グループ
   を識別するグループ識別子とを該データファイル・リク
   エストの修飾名として出力する構成を有し、 前記サーバは、 前記クライアントから受領したデータファイル・リクエ
   スト中からデータファイル名を取り出すとともに、前記
   修飾名からメソッド識別子とグループ識別子とを取り出
   すファイル名解析手段と、 １以上のクライアントの各々の識別子を該クライアント
   によって構成されるグループのグループ識別子に対応さ
   せて登録したクライアント管理テーブルを有し、グルー
   プの管理を行うグループ管理手段と、 前記クライアントからのデータファイル・リクエストに
   応答して、予め登録された複数のメソッドから起動メソ
   ッドを決定するメソッド選択手段と、を有することを特
   徴とするデータ通信システム。
2. 【請求項２】 前記サーバは、前記グループ識別子によ
   って識別されたグループに属するクライアント装置に前
   記データファイル名を送信する送信手段を有することを
   特徴とする請求項１記載のデータ通信システム。
3. 【請求項３】 前記送信手段は、前記データファイル名
   に加えて前記メソッド識別子および前記グループ識別子
   を送信する構成を有することを特徴とする請求項２記載
   のデータ通信システム。
4. 【請求項４】 前記サーバは、前記データファイル名に
   対して、メソッド識別子およびグループ識別子を修飾さ
   せて修飾名を生成する修飾手段を有し、 前記送信手段は、前記修飾手段によってメソッド識別子
   およびグループ識別子が修飾されたデータファイル名を
   メッセージ・データとして送信する構成を有することを
   特徴とする請求項３記載のデータ通信システム。
5. 【請求項５】 前記サーバは、前記クライアントをグル
   ープのメンバとして登録するレジスト・メソッドを実行
   する構成を有し、 前記サーバは、前記クライアントから受領するデータフ
   ァイル・リクエストの修飾名としてレジスト・メソッド
   の指定がある場合に、該レジスト・メソッドを実行し、
   前記クライアントを識別するクライアント識別データを
   前記クライアント管理テーブル中に登録する構成を有す
   ることを特徴とする請求項１乃至４いずれかに記載のデ
   ータ通信システム。
6. 【請求項６】 前記サーバは、クライアントからのデー
   タファイル・リクエストによって指定されたデータ・フ
   ァイルの更新処理を可能とするリフレッシュ・メソッド
   を実行する構成を有し、 前記サーバは、前記クライアントから受領するデータフ
   ァイル・リクエストの修飾名としてリフレッシュ・メソ
   ッドの指定がある場合に、該リフレッシュ・メソッドを
   実行し、前記指定されたデータ・ファイルの更新を可能
   とするとともに、該更新データ・ファイルを、前記クラ
   イアントのデータファイル・リクエストにおける修飾名
   として指定されたグループ識別子に対応するグループに
   属するクライアントに送信する構成を有することを特徴
   とする請求項１乃至５いずれかに記載のデータ通信シス
   テム。
7. 【請求項７】 前記サーバは、前記クライアント管理テ
   ーブルに登録されたグループに属するクライアントにメ
   ッセージを通知するノーティファイ・メソッドを実行す
   る構成を有し、 前記サーバは、前記クライアントから受領するデータフ
   ァイル・リクエストの修飾名としてノーティファイ・メ
   ソッドの指定がある場合に、該ノーティファイ・メソッ
   ドを実行し、クライアントからのデータファイル・リク
   エストによって指定されたデータファイルに関する処理
   の実行を、前記クライアントのデータファイル・リクエ
   ストにおける修飾名として指定されたグループ識別子に
   対応するグループに属するクライアントに通知する構成
   を有することを特徴とする請求項１乃至６いずれかに記
   載のデータ通信システム。
8. 【請求項８】 前記サーバは、さらに前記ノーティファ
   イ・メソッドの実行において、前記修飾手段において、
   クライアントからのデータ・リクエスト中の修飾名とし
   て指定されたノーティファイ・メソッドのリフレッシュ
   ・メソッドへの書き換えを実行し、該書き換えの完了し
   たメッセージ・データを前記クライアントのデータファ
   イル・リクエストにおける修飾名として指定されたグル
   ープ識別子に対応するグループに属するクライアントに
   通知する構成を有することを特徴とする請求項７記載の
   データ通信システム。
9. 【請求項９】 前記サーバの修飾手段において書き換え
   られたメッセージ・データを受領したクライアントは、
   該書き換えメッセージ・データを前記サーバに対するデ
   ータファイル・リクエストとして出力し、前記サーバは
   該リクエストを受領することにより、前記リフレッシュ
   ・メソッドを実行する構成を有することを特徴とする請
   求項８記載のデータ通信システム。
10. 【請求項１０】 前記サーバは、さらに前記リフレッシ
    ュ・メソッドの実行において、前記修飾手段において、
    クライアントからのデータ・リクエスト中の修飾名とし
    て指定されたリフレッシュ・メソッドのノーティファイ
    ・メソッドへの書き換えを実行し、該書き換えの完了し
    たメッセージ・データを前記クライアントのデータファ
    イル・リクエストにおける修飾名として指定されたグル
    ープ識別子に対応するグループに属するクライアントに
    通知する構成を有することを特徴とする請求項７記載の
    データ通信システム。
11. 【請求項１１】 前記サーバの修飾手段において書き換
    えられたメッセージ・データを受領したクライアント
    は、該書き換えメッセージ・データを前記サーバに対す
    るデータファイル・リクエストとして出力し、前記サー
    バは該リクエストを受領することにより、前記ノーティ
    ファイ・メソッドを実行する構成を有することを特徴と
    する請求項１０記載のデータ通信システム。
12. 【請求項１２】 前記サーバは、前記クライアント管理
    テーブルに登録されたグループ内情報の編集処理を可能
    とするエディット・メソッドを実行可能な構成を有し、 前記サーバは、前記クライアントから受領するデータフ
    ァイル・リクエストの修飾名としてエディット・メソッ
    ドの指定がある場合に、該エディット・メソッドを実行
    し、前記グループ内情報の編集し、編集内容を新たなグ
    ループ内情報として登録するとともに、該新たなグルー
    プ内情報に関するノーティファイ・メソッドを起動する
    構成を有することを特徴とする請求項７乃至１１いずれ
    かに記載のデータ通信システム。
13. 【請求項１３】 前記サーバおよび前記クライアント装
    置は、マルチキャストルータ及びネットワークを介して
    接続可能な構成を有し、 前記サーバは、前記クライアント管理テーブル中に登録
    されたグループに対応してマルチキャストグループ・ア
    ドレスを登録データとして有し、 前記クライアントによって構成されるグループ内のクラ
    イアントと前記サーバ間のデータ通信は、グループ識別
    子に対して一意的に決定されるマルチ・キャスト・アド
    レスに基づいて実行されることを特徴とする請求項１乃
    至１２いずれかに記載のデータ通信システム。
14. 【請求項１４】 前記クライアントの指定するデータフ
    ァイルは、ＨＴＭＬページによって構成され、該クライ
    アントおよび前記サーバ間でのデータ転送はＨＴＴＰに
    従って実行する構成を有し、 前記サーバの有する前記修飾手段はＵＲＬ修飾手段によ
    って構成され、データファイル名に対するメソッド識別
    子およびグループ識別子の修飾はＵＲＬの書き換えによ
    って実行する構成であることを特徴とする請求項１乃至
    １３いずれかに記載のデータ通信システム。
15. 【請求項１５】 前記サーバの実行するリフレッシュ・
    メソッドにおけるデータファイルの編集はＨＴＭＬペー
    ジの編集であり、サーバは該編集ＨＴＭＬページ中に他
    のサーバの管理するリンクデータが含まれる場合、該他
    のサーバの管理するリンクデータのＵＲＬにノーティフ
    ァイ・メソッドを呼び出す識別子を付加するＵＲＬの書
    き換えを実行する構成を有することを特徴とする請求項
    １４記載のデータ通信システム。