JP4095352B2 - 情報処理装置、情報処理装置の制御方法、及び当該制御方法を実行するためのコンピュータプログラム - Google Patents
情報処理装置、情報処理装置の制御方法、及び当該制御方法を実行するためのコンピュータプログラム Download PDFInfo
- Publication number
- JP4095352B2 JP4095352B2 JP2002174245A JP2002174245A JP4095352B2 JP 4095352 B2 JP4095352 B2 JP 4095352B2 JP 2002174245 A JP2002174245 A JP 2002174245A JP 2002174245 A JP2002174245 A JP 2002174245A JP 4095352 B2 JP4095352 B2 JP 4095352B2
- Authority
- JP
- Japan
- Prior art keywords
- notification
- terminal
- received
- update notification
- advertisement
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0893—Assignment of logical groups to network elements
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、情報処理装置、情報処理装置の制御方法、及び当該制御方法を実行するためのコンピュータプログラムに関する。
【０００２】
【従来の技術】
近年、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）を利用した情報の提供が急速な普及を見せている。ユーザーはＷＷＷで提供される様々な情報にアクセスし、必要な情報を選択して利用している。
【０００３】
ＷＷＷでは、情報提供者が非同期にかつ不定期に情報を更新する。そのためユーザーは、常に最新の情報を手にするためにいくつものＷｅｂサーバーに能動的にアクセスして、新たな情報が追加されていないか、以前提供された情報が変更されていないかなど、自ら確認する必要がある。
【０００４】
ここで、例えば新種のウィルスやセキュリティーホールの発見に関する情報や、あるいはオークションサイトに登録される新商品の情報など、ユーザーにとって緊急性を要する情報を入手するためには、その緊急度に応じた頻度でＷｅｂサーバーにアクセスする必要があり、ユーザーにとって負担となっていた。
【０００５】
この負担を軽減するために、Ｗｅｂサイトの情報の更新を検知してユーザーに通知するシステムが従来より存在している。例えば特開平１０−１７１７００号公報で提案されているシステムは、ＷＷＷサーバー自体がサーバー上のファイルの更新を検知してそれをユーザーに通知するものである。また、特開２００１−６７２８３号公報で提案されているようにユーザーの登録した文書が更新されたときにメールで通知するものなどが存在する。
【０００６】
【発明が解決しようとする課題】
しかしながら、上記従来のシステムは、いずれも更新検知や通知を行うシステムが一つのサーバー上で運用されているため、ユーザー数の増加に伴い膨大な処理が一極集中するサーバーに対して過度の負荷が発生するという問題があった。さらに、システムを運用するサーバーが停止した場合には一切のサービスが停止してしまうという脆弱さに問題があった。
【０００７】
これに対して、ＵＳＰ５９７８８４２に提案されるシステムには、更新検知の処理は当該文書の更新通知を受ける個々のクライアントに行わせて、サーバーでは更新検知結果の集計と通知のみを行う手法が開示されている。この方法によれば、サーバーにかかる負荷を軽減するという目的においては効果を発揮することが期待できる。しかし、通知に関する処理は依然としてサーバーに集中しており、先に述べた脆弱性に対する改善は図られていない。
【０００８】
本発明は、更新されたデータを所有する装置以外の装置からデータの更新通知を受信した場合であっても、適切な装置から更新されたデータを取得できるようにすることを目的とする。
【０００９】
【課題を解決するための手段】
上記目的を達成するために、本発明は、情報処理装置であって、データが更新されたことを示す更新通知を互いに通知する通知先のアドレスを記憶する記憶手段と、複数の他の装置から更新通知を受信する受信手段と、前記受信手段により受信した更新通知が、更新されたデータを所有する第１の装置以外の装置を経由して送信されてきたか否かを判別すると共に、該更新通知と同じデータの更新通知を既に受信済みか否かを判別する判別手段と、前記判別手段により受信した更新通知と同じデータの更新通知を既に受信済みと判別された場合には、受信した更新通知の送り元が前記第１の装置であれば前記第１の装置のアドレスを記憶し、受信した更新通知の送り元が前記第１の装置でなければ更新通知の送り元の装置の中で前記第１の装置までのホップ数が最小の装置のアドレスを記憶する記憶処理を行い、前記受信手段により受信した更新通知と同じデータの更新通知を受信していない場合には、前記更新通知が前記第１の装置以外の装置を経由して送信されてきたと判別した場合、前記第１の装置のアドレスが前記記憶手段により記憶している通知先アドレスに登録されているときは、前記第１の装置に対して更新されたデータの送信を要求し、前記第１の装置のアドレスが前記記憶手段により記憶している通知先アドレスに登録されていないときは、前記更新通知の送信元である複数の他の装置の中から前記記憶処理により選択される第２の装置に対して、更新されたデータの送信を要求する要求手段と、を有することを特徴とする。
【００１０】
また、本発明は、データが更新されたことを示す更新通知を互いに通知する通知先のアドレスを記憶する記憶手段を有する情報処理装置が実行する制御方法であって、複数の他の装置から更新通知を受信する受信工程と、前記受信工程において受信した更新通知が、更新されたデータを所有する第１の装置以外の装置を経由して送信されてきたか否かを判別すると共に、該更新通知と同じデータの更新通知を既に受信済みか否かを判別する判別工程と、前記判別工程において受信した更新通知と同じデータの更新通知を既に受信済みと判別された場合には、受信した更新通知の送り元が前記第１の装置であれば前記第１の装置のアドレスを記憶し、受信した更新通知の送り元が前記第１の装置でなければ更新通知の送り元の装置の中で前記第１の装置までのホップ数が最小の装置のアドレスを記憶する記憶処理を行い、前記受信工程により受信した更新通知と同じデータの更新通知を受信していない場合には、前記更新通知が前記第１の装置以外の装置を経由して送信されてきたと判別した場合、前記第１の装置のアドレスが前記記憶手段により記憶している通知先アドレスに登録されているときは、前記第１の装置に対して更新されたデータの送信を要求し、前記第１の装置のアドレスが前記記憶手段により記憶している通知先アドレスに登録されていないときは、前記更新通知の送信元である複数の他の装置の中から前記記憶処理により選択される第２の装置に対して、更新されたデータの送信を要求する要求工程と、を有することを特徴とする。
【００１３】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて説明する。
【００１４】
［第一実施形態］
＜ネットワークシステムの構成＞
図１は、本発明の第一実施形態に係るネットワークシステムの全体構成を示す図である。
【００１５】
このネットワークシステムは情報通知端末１〜５で構成されている。端末１〜端末５はいずれもネットワークに接続されていて、各々の端末上のデータＤ１〜Ｄ５の更新を別の端末に対して通知すると同時に、他の端末からの通知を受信する機能を有している。各端末１〜５は互いのアドレスを登録しており直接通信を行う。
【００１６】
初めにこのシステムの動作を、端末１が通知を行う場合を例に簡単に説明する。端末１はデータＤ１の更新を端末２及び端末３に対して通知する。端末１より通知を受けた端末２及び端末３は、端末１に対して更新されたデータの取得を要求し、端末２は端末３、４へ、端末３は端末２、４へそれぞれ端末１からの通知を転送する。端末２及び端末３から通知を受信した端末４は、端末２または３に対して更新されたデータの取得を要求し、また端末５へ通知を転送する。
【００１７】
端末４からデータ取得の要求を受けた端末２または３は、端末１より取得した更新データを端末４に転送する。端末４より通知を受けた端末５は端末４に対して更新されたデータの取得を要求する。端末４は端末２または３より取得した更新データを端末５に転送する。以上により、端末１での更新通知を他の全ての端末が取得することで本システムは機能する。
【００１８】
本実施形態では、これら端末群が構成する仮想ネットワーク（ネットワークシステム）のことを通知グループと呼び、通知グループを形成する端末（及び端末の利用者）のことを参加者と呼ぶこととする。一つの通知グループは参加者間で共有される一つのグループ管理番号を有し、複数の通知グループに参加する参加者はグループ管理番号によっていずれのグループに向けられた通知であるかを識別する。グループ管理番号の詳細については後述する。
【００１９】
＜情報通知端末の構成＞
図２は、図１に示した通知グループを形成する情報通知端末の構成図であり、端末１を例にとって説明するが、他の端末２〜５も同様の構成である。
【００２０】
２０２が本システムを利用するユーザーであり、端末１を介して更新通知の情報を参加者２１７に発信すると同時に、参加者２１７からの更新通知情報を受信する。２０３の通知対象はユーザーが更新を通知しようとしているデータの集合であり、端末１上の記憶装置２０４に記録されている。通知対象２０３はユーザーが通知対象登録部２０５によって登録する。更新検知部２０６は、通知対象２０３に登録されているデータを監視して更新を検知する。
【００２１】
通知先アドレス記憶部２０７には更新の通知先である参加者２１７のアドレスが記録されている。広告送信部２０８は更新が行われたことを参加者２１７に通知する広告を作成し、ネットワークインターフェイス２１２を通じてこれを送信する。広告受信部２０９は参加者２１７からの広告を受信する。
【００２２】
更新データ送信部２１０は、参加者２１７に対して実際の更新データをネットワークインターフェイス２１２を通じて送信する。更新データ受信部２１１は参加者２１７から更新データを受信する。ルート探索部２１４は参加者２１７より受信した広告や更新データを別の参加者に転送する際の転送先や更新データの取得先を決定する。広告保存部２１５は受信した広告を一定期間保存する。通知部２１６は参加者２１７から受けた更新通知をユーザーに通知する。
【００２３】
＜通知グループへの参加＞
初めに、通知グループへの参加について図３のシーケンス図を参照して説明する。
【００２４】
まず、通知を行いたいユーザーの端末上で通知グループを一つ作成する（３０１）。ここでは端末１とするが、どの端末であっても構わない。通知グループにはユニークなＩＤ（例えば端末１のグローバルＩＰアドレスとグループ作成日時の組み合わせ等）が割り振られる。グループの作成が終わった端末１では他端末からの接続を受け付け可能な状態となる。
【００２５】
続いて、通知を受けたいユーザーの端末２が端末１に対してＩｎｑｕｉｒｅ広告を送信する（３０２）。図４にＩｎｑｕｉｒｅ広告を示す。同図において、広告タイプ（４０１）はこの広告の種類で、Ｉｎｑｕｉｒｅが記されている。送信元アドレス（４０２）はこの広告の送信元アドレス（ここでは端末２）である。
【００２６】
Ｉｎｑｕｉｒｅ広告を受信した端末１は端末２に対してＰｒｏｐｏｓａｌ広告を送信して端末１で提供している通知グループのＩＤを通知する（３０３）。図５にＰｒｏｐｏｓａｌ広告を示す。同図において、広告タイプ（５０１）はこの広告の種類で、Ｐｒｏｐｏｓａｌが記されている。送信元アドレス（５０２）はこの広告の送信元アドレス（ここでは端末１）である。グループＩＤリスト（５０３）は端末１で提供している通知グループの識別子である。
【００２７】
端末２のユーザーは参加するグループＩＤリストから参加したいグループを選択し、端末１に対してＪｏｉｎ広告を送信する（３０４）。図６にＪｏｉｎ広告を示す。図６において、広告タイプ（６０１）はこの広告の種類で、Ｊｏｉｎが記されている。送信元アドレス（６０２）はこの広告の送信元アドレス（ここでは端末２）である。グループＩＤ（６０３）は端末２が参加を希望している通知グループの識別子である。
【００２８】
Ｊｏｉｎ広告を受信した端末１は端末２に対してＡｃｃｅｐｔ広告を送信する（３０５）。図７にＡｃｃｅｐｔ広告を示す。図７において、広告タイプ（７０１）はこの広告の種類で、Ａｃｃｅｐｔが記されている。送信元アドレス（７０２）はこの広告の送信元アドレス（ここでは端末１）である。グループＩＤ（７０３）は端末１が端末２に対して参加を認めた通知グループの識別子である。Ａｃｃｅｐｔ広告の送受信が終わると、端末１、２はそれぞれ相手のアドレスを通知先アドレス記憶部に登録する（３０６、３０７）。これにより端末１、２の間に仮想的な経路が張られ、通知グループへの参加手続きが完了する。
【００２９】
通知グループに参加している各端末は、通知グループを作成した端末と同様に他の端末からの参加を受け付けることができる。この場合の参加の手順も図３に示すものと同様である。また、一つの端末が同じ通知グループに属する複数の端末に対して参加を申し込むことも可能である。例えば端末３が端末２に対して参加を申し込んだ後で端末１に参加を申し込むことがあってもよい。そうすることで端末３からは、端末１及び端末２の両端末への仮想的な経路が張られ、明にその存在を知らしめることができる。
【００３０】
なお、通知グループへの参加に際し、何らかの認証を行うことも可能であるが、それについては本発明の規定するところではない。以上が通知グループへの参加手順の説明である。
【００３１】
＜通知グループからの脱退＞
次に、通知グループからの脱退について図８のシーケンス図を参照して説明する。ここでは図１において端末４が脱退する場合を例に説明する。
【００３２】
まず、端末４は通知先アドレス記憶部に登録されている全ての端末（ここでは端末２、３、５）に対してＤｉｓＪｏｉｎ広告を送信する（８０１）。図９にＤｉｓＪｏｉｎ広告を示す。同図において、広告タイプ（９０１）はこの広告の種類で、ＤｉｓＪｏｉｎが記されている。送信元アドレス（９０２）はこの広告の送信元アドレス（ここでは端末４）である。グループＩＤ（９０３）は端末４が脱退を希望している通知グループの識別子である。
【００３３】
ＤｉｓＪｏｉｎ広告を受信した各端末は、通知先アドレス記憶部に登録されているアドレスからＤｉｓＪｏｉｎ広告の送信元アドレスを削除する（８０２）。ここで、通知先アドレスにＤｉｓＪｏｉｎ広告の送信元アドレスしか登録されておらず、別の通知先アドレスが必要となる端末（例えば図１の端末５のように端末４にしか参加していない場合）は、ＤｉｓＪｏｉｎ広告の送信元に対してＡｌｔ広告を送信して別アドレスを要求する（８０３）。図１０にＡｌｔ広告を示す。同図において、広告タイプ（１００１）はこの広告の種類で、Ａｌｔが記されている。送信元アドレス（１００２）はこの広告の送信元アドレス（ここでは端末５）である。グループＩＤ（１００３）はＤｉｓＪｏｉｎ広告に記されていた通知グループの識別子である。
【００３４】
Ａｌｔ広告を受信した端末は通知先アドレス記憶部に登録しているアドレスの内、Ａｌｔ広告の送信元アドレス以外のアドレスをＡｌｔＡｄｄｒ広告に含めてＡｌｔ広告の送信元（端末５）に送信する（８０４）。図１１にＡｌｔＡｄｄｒ広告を示す。同図において、広告タイプ（１１０１）はこの広告の種類で、ＡｌｔＡｄｄｒが記されている。グループＩＤ（１１０２）はＤｉｓＪｏｉｎ広告に記されていた通知グループの識別子である。アドレスリスト（１１０３）は通知先アドレス記憶部に登録されているアドレスのリストである。
【００３５】
ＤｉｓＪｏｉｎまたはＡｌｔ広告を送信しかつＡｌｔＡｄｄｒ広告を受信した端末は、ＤｉｓＪｏｉｎ広告の送信元に対してＢｙｅ広告を送信する（８０５）。ＤｉｓＪｏｉｎ広告を送信した全ての送信先からＢｙｅ広告を受信した段階で端末５の脱退が完了する（８０６）。以上が脱退の手順についての説明である。
【００３６】
＜通知グループの消滅＞
続いて通知グループの消滅について説明する。
【００３７】
通知グループの消滅は参加者数が２（端末Ａ、Ｂとする）の時に一方の端末（端末Ｂとする）が脱退した場合に生じる。初めに端末Ｂが端末Ａに対してＤｉｓＪｏｉｎ広告を送信する。端末Ａでは通知先アドレスに端末Ｂしか登録されていないので、前記通知グループからの脱退手続きに従って端末ＢにＡｌｔ広告を送信して代替アドレスを要求する。
【００３８】
ここで、端末Ｂにおいても通知先アドレスに端末Ａしか登録されていないのでＡｌｔＡｄｄｒ広告で通知できる代替アドレスが存在しない。この場合に端末ＢはＡｌｔＡｄｄｒ広告をアドレスリストに何も記載せずに送信する。アドレスリストが空のＡｌｔＡｄｄｒ広告を受信した端末Ａは端末Ｂに対してＢｙｅ広告を送信して脱退を許可する。Ｂｙｅ広告を受信した端末Ｂでは脱退手続きを完了する。この時点で通知グループの参加者は端末Ａのみとなり、通知グループを消滅させることが可能となる。
【００３９】
なお、最後の参加者は当該グループを維持してもよい。この方法によれば通知グループ作成者が途中で通知グループを脱退しても、参加者数が１となるまでは残りの参加者によって通知グループを維持することが可能である。
【００４０】
＜データの更新を通知する手順＞
図１及び図２で示したシステムにおいて、端末１上のデータＤ１の更新を他の端末（端末２〜端末５）に対して通知する手順を、図１２のシーケンス図を参照して説明する。
【００４１】
端末１を利用しているユーザーがデータＤ１の更新を通知グループの参加者に通知する場合、まずユーザーは通知対象登録部２０５を通じてデータＤ１を通知対象２０３に登録する（１２０１）。
【００４２】
通知対象登録部２０５はデータＤ１に対してユニークな管理番号を割り当ててこれを管理する。通知対象２０３に割り当てられる管理番号は各端末の内部においてユニークである必要があるが、他の端末とは無関係に設定可能である。端末１では更新検知部２０６は通知対象２０３を監視している（１２０２）。ここでユーザーがデータＤ１を更新すると（１２０３）、更新検知部２０６がこれを検知し（１２０４）、広告送信部２０８にその管理番号を通知する（１２０５）。更新検知部２０６から通知を受けた広告送信部２０８は、通知先アドレス記憶部２０７から端末１に登録されている参加者のアドレスを取得する（１２０６）。図１の例では端末１に登録されている参加者は端末２及び端末３である。
【００４３】
続いて、広告送信部２０８は登録されている各参加者に対してＮｏｔｉｃｅ広告を送信する（１２０７）。Ｎｏｔｉｃｅ広告の内容を図１３に示す。同図において広告タイプ（１３０１）はこの広告の種類でＮｏｔｉｃｅが記されている。グループＩＤ（１３０２）はこの広告を受信する通知グループの識別子、広告番号（１３０３）は通知元がこの通知グループに送信した広告を一意に特定可能な番号、送信元アドレス（１３０４）はこの広告の送信元アドレス（ここでは端末１のアドレス）、通知元アドレス（１３０５）は更新されたデータを所有する端末のアドレス（ここでは端末１のアドレス）、通知対象ＩＤ（１３０６）は端末１において識別可能な通知対象の識別子、ホップ数（１３０７）は通知元から数えてこの広告が何回転送されているか（ここでは０）、広告有効期限（１３０８）はこの広告の有効期限を、それぞれ示すものである。
【００４４】
＜Ｎｏｔｉｃｅ広告受信処理＞
次に、端末２におけるＮｏｔｉｃｅ広告受信処理について図１４のフローチャートを用いて説明する。なお、端末３は端末２と同等であるためここでは端末２について説明する。
【００４５】
本システムにおいて、端末２がデータＤ１の更新に関するＮｏｔｉｃｅ広告を受信する経路には、
（１）端末１から
（２）端末３から
（３）端末４から
の３パターンが存在し、パターン（１）とそれ以外の場合で処理が異なる。
【００４６】
初めに、端末１から広告を受信した場合（パターン（１））について説明する。 広告受信部２０９で広告を受信した端末２は、まず広告タイプを抽出する（ステップＳ１）。広告タイプがＮｏｔｉｃｅであれば（ステップＳ２）、次にグループＩＤを抽出する（ステップＳ３）。自分の所属する通知グループのＩＤと比較し（ステップＳ４）、異なるグループＩＤであればこの広告は誤って送信されたものであるので端末２は直ちにこの広告を破棄して処理を終える（ステップＳ５）。
【００４７】
自分の属する通知グループを示すグループＩＤであった場合は続いて広告有効期限を抽出する（ステップＳ６）。現在時刻が広告有効期限を過ぎていればこの広告を破棄して処理を終える（ステップＳ７，ステップＳ５）。広告が有効期限内であれば広告をルート探索部２１４に引き渡す。
【００４８】
ルート探索部２１４はまず広告番号と通知元アドレスを抽出する（ステップＳ８）。抽出した通知元アドレスと広告番号を広告保存部２１５に保存されているＮｏｔｉｃｅ広告のそれと比較する。保存されているＮｏｔｉｃｅ広告に一致するものが見つかった場合（つまり端末３〜４からのＮｏｔｉｃｅ広告を既に受信している場合）は（ステップＳ９）、保存されているＮｏｔｉｃｅ広告を今回受信した端末１からのＮｏｔｉｃｅ広告（すなわち送信元と通知元が同一な広告）で置き換えた後（ステップＳ１０、ステップＳ１１）、処理を終了する。
【００４９】
いずれのＮｏｔｉｃｅ広告とも一致しなかった場合はこのＮｏｔｉｃｅ広告を新規に広告保存部２１５に保存し（ステップＳ２１）、更新データ取得処理（Ａ）に進む。
【００５０】
更新データ取得処理ではまず、ホップ数を抽出する（ステップＳ２２）。端末１からのＮｏｔｉｃｅ広告ではホップ数が０であるので（ステップＳ２３）、通知元から直接Ｎｏｔｉｃｅ広告を受信したことが分かる。その場合は通知元アドレスを抽出し、通知元アドレスに対して直接更新データ要求メッセージを送信する（ステップＳ２４）。更新データ要求メッセージは図１５に示すように、受信したＮｏｔｉｃｅ広告と同一のグループＩＤ（１４０１）、広告番号（１４０２）、通知対象ＩＤ（１４０３）、及びこのメッセージの送信元アドレス（１４０４）が含まれる。
【００５１】
更新データ要求メッセージを送信したら続いて広告転送処理を行う（ステップＳ２５）。各端末は受信したＮｏｔｉｃｅ広告を通知先アドレス記憶部２０７に記録されている参加者に対して転送する。端末２において記録されている参加者は端末１、３、４であるが、このうち端末１はＮｏｔｉｃｅ広告の送信元であるので、これを除いた端末３、４に対して転送する。転送されるＮｏｔｉｃｅ広告の内容は図１６に示すように、送信元アドレスが端末２のアドレスである点、及びホップ数が１増加されている点を除いて、端末１より受信したＮｏｔｉｃｅ広告と同一である。
【００５２】
次に端末２が端末３、４からＮｏｔｉｃｅ広告を受信した場合（パターン（２），（３））について説明する。
【００５３】
受信から有効期限の判定までの処理（ステップＳ１〜ステップＳ１０）は前記パターン（１）と同様であるので、ここでの説明は省略する。続く広告の保存処理であるが、広告保存部２１５に今回受信した広告と一致するＮｏｔｉｃｅ広告が保存されていた場合は、両者のホップ数を比較し（ステップＳ２６）、今回の広告の方がホップ数が小さければ保存データを置き換える（ステップＳ１１）。この例では端末４からの広告（ホップ数＝２）を受信した後に端末３からの広告（ホップ数＝１）を受信した場合に端末３からの広告を保存することになる。これにより、広告保存部２１５には常に通知元までのホップ数が最少のＮｏｔｉｃｅ広告が保存されていることになる。Ｎｏｔｉｃｅ広告を保存した後は処理を終了する。
【００５４】
一方、一致するＮｏｔｉｃｅ広告が見つからなかった場合は、今回受信したＮｏｔｉｃｅ広告を新規に保存して（ステップＳ２１）、更新データ取得処理（Ａ）に進む。更新データ取得処理では、まずホップ数を取得する（ステップＳ２２）。ここで受信したＮｏｔｉｃｅ広告はいずれかの端末において１回以上転送されているため、ホップ数が１以上になっている（ステップＳ２３）。ホップ数が１以上のＮｏｔｉｃｅ広告を受信した端末は通知元アドレスを抽出し、自分の通知先アドレス記憶部２０７に登録されている参加者のアドレスと比較する（ステップＳ２７）。
【００５５】
抽出した通知元アドレスが参加者アドレスのいずれかに一致がみられた場合（この例で端末２は端末１を登録している）、この端末はいずれ通知元から直接Ｎｏｔｉｃｅ広告が受信されることが期待される。したがって、ホップ数が０のＮｏｔｉｃｅ広告を受信した場合と同一とみなし、通知元アドレスに対して直接更新データ要求メッセージを送信する（ステップＳ２４）。最後に広告の転送処理を行う（ステップＳ２５）。
【００５６】
端末３から広告を受信した場合、端末１が通知元であり、また端末３は広告の送信元であるので、これらを除いた端末４に対してＮｏｔｉｃｅ広告を転送する。端末４から受信した場合も同様に、通知元とＮｏｔｉｃｅ広告の送信元を除いた参加者に対してＮｏｔｉｃｅ広告を転送する。Ｎｏｔｉｃｅ広告の内容は前記パターン１の場合と同一である。
【００５７】
以上はＮｏｔｉｃｅ広告の通知元アドレスが通知先アドレス記憶部２０７に登録されている端末における広告受信処理である。
【００５８】
続いて、通知元アドレスが通知先アドレス記憶部２０７に登録されていない端末（端末４、５）におけるデータＤ１の更新に関するＮｏｔｉｃｅ広告の受信処理を説明する。
【００５９】
受信から広告保存までの処理（ステップＳ１〜ステップＳ２１）は前記パターン（２）と同様であるので説明は省略し、更新データ取得処理（Ａ）の説明から始める。ここで受信したＮｏｔｉｃｅ広告はいずれかの端末において１回以上転送されているため、ホップ数が１以上になっている（ステップＳ２３）。ホップ数が１以上のＮｏｔｉｃｅ広告を受信した端末は通知元アドレスを抽出し、自分の通知先アドレス記憶部２０７に登録されている参加者のアドレスと比較する（ステップＳ２７）。いずれのアドレスとも一致しなかった場合（端末４、５においては端末１は通知先アドレスに登録されていない）、端末４、５は２つの方法を選択することができる（ステップＳ３０）。
【００６０】
一つ目は、通知元アドレスに対して直接更新データ要求メッセージを送り（ステップＳ３１）、同時に通知元アドレスを通知先アドレス記憶部２０７に追加する方法である（ステップＳ３２）。これにより、端末４は端末１との間に仮想的な経路を張ることができ、これ以降、端末１からのＮｏｔｉｃｅ広告を直接受信することができるようになる。
【００６１】
２つ目は、広告保存部２１５に保存されているＮｏｔｉｃｅ広告の送信元端末（端末１への最短ホップを実現する。以下、最適端末と呼ぶ）に対して更新データ要求メッセージを送信する方法である。この方法では、端末４は端末１に対して自身のアドレスを秘匿することが可能である。そのかわり、端末１からの通知を直接受信することはできない。また、受信したＮｏｔｉｃｅ広告の送信元と最適端末とは必ずしも一致しない。
【００６２】
そこで、まず最適端末に対して更新データ要求メッセージを送信し（ステップＳ３３）、応答が得られなかった場合は（ステップＳ３４）、今回受信したＮｏｔｉｃｅ広告の送信元に更新データ要求メッセージを送信する（ステップＳ３５）。いずれかの方法で更新データ要求メッセージを送信したら、最後にＮｏｔｉｃｅ広告の転送処理を行う（ステップＳ２５）。既に述べたように通知先アドレス記憶部２０７に登録されているものから通知元と広告の送信元を除いた参加者に対してＮｏｔｉｃｅ広告を転送する。Ｎｏｔｉｃｅ広告の内容は前記パターン（１）と同様である。
【００６３】
以上がＮｏｔｉｃｅ広告受信処理の説明である。
【００６４】
＜更新データ要求メッセージ受信処理＞
次に、更新データ要求メッセージ受信処理について図１７のフローチャートを参照して説明する。
【００６５】
初めに通知元（端末１）における処理を説明する。端末１では、受信した更新データ要求メッセージ（ステップＳ７１）から、グループＩＤ、広告番号、及び通知対象ＩＤをそれぞれ抽出し（ステップＳ７２）、送信したＮｏｔｉｃｅ広告の内容と相違ないことを確認する（ステップＳ７３、ステップＳ７４）。メッセージの内容に不正がなければメッセージの送信元アドレスに対して更新データを送信する（ステップＳ７５，ステップＳ７６）。
【００６６】
続いて、メッセージの送信元アドレスを通知先アドレス記憶部２０７に登録されている参加者のアドレスと比較し（ステップＳ７７）、未登録であればこれを追加する（ステップＳ７８）。
【００６７】
次に、通知元アドレスが通知先アドレス記憶部２０７に登録されている端末（端末２または３）における処理を説明する。端末２（または３）が端末４から更新データ要求メッセージを受信したら（ステップＳ７１）、メッセージからグループＩＤ、広告番号、及び通知対象ＩＤをそれぞれ抽出し（ステップＳ７２）、広告保存部２１５に内容の一致するＮｏｔｉｃｅ広告が保存されているかを検証する（ステップＳ７３、ステップＳ７９）。
【００６８】
一致するＮｏｔｉｃｅ広告が見つかった場合は要求が正当であるとし、通知元より受信した更新データをメッセージの送信元アドレスに転送する（ステップＳ８０〜ステップＳ８２）。通知元から更新データを受信できていない場合は、更新データを受信するまで端末４に対してＫｅｅｐＡｌｉｖｅ広告を送信する（ステップＳ８３）。ＫｅｅｐＡｌｉｖｅ広告の内容を図１８に示す。
【００６９】
最後に通知元アドレスが通知先アドレス記憶部２０７に登録されていない端末（端末４）における処理を説明する。端末５より更新データ要求メッセージを受信した端末４は、メッセージからグループＩＤ、広告番号、及び通知対象ＩＤをそれぞれ抽出し、広告保存部２１５に内容の一致するＮｏｔｉｃｅ広告が保存されているかを検証する。一致するＮｏｔｉｃｅ広告が見つかった場合は要求が正当であるとし、通知元またはＮｏｔｉｃｅ広告送信元から受信した更新データをメッセージの送信元アドレスに転送する（ステップＳ８０、ステップＳ８４）。通知元から更新データを受信できていない場合は、更新データを受信するまで端末５に対してＫｅｅｐＡｌｉｖｅ広告を送信する（ステップＳ８３）。
【００７０】
以上述べたように本実施形態によれば、ネットワークに接続された複数の端末が情報の更新通知やデータ取得を分散処理する分散型ネットワークを構築することができるので、サーバーを必要としない情報通知ネットワークシステムを構成することが可能になる。これにより、従来のようなサーバーへの負荷の一極集中といった問題を回避することができ、さらには、情報提供者が自ら、情報の更新を通知メッセージで送信して、ネットワークを構成するユーザー間で通知メッセージを転送することにより、全てのユーザーが更新された情報を即座に入手することが可能である。
【００７１】
［第二実施形態］
図１９は、本発明の第二実施形態に係るネットワークシステムの全体構成を示す図であり、図２０は、第二実施形態に係る情報通知端末の構成を示すブロック図である。
【００７２】
このネットワークシステムは情報通知端末１〜３で構成され、端末１〜端末３は順次ネットワークに接続されている。各端末１〜３の構成は、図２０に示すように、通知選択部１８０３、通知対象保存部１８０４、通知部１８０５、及び広告受信部１８０６を備えている。
【００７３】
以上の構成において、端末１のユーザーがデータＤ１を通知対象に指定して、端末２及び端末３に更新の通知を行う場合について説明する。
【００７４】
まず、データＤ１を初めて更新検知した際のＮｏｔｉｃｅ広告の送受信処理は第一実施形態に準じる。Ｎｏｔｉｃｅ広告の受信に続いて更新データ要求メッセージを送信し、更新データを受信した端末２（及び端末３）では、ユーザーが当該データの更新通知の要／不要を判定する。
【００７５】
図２１に通知選択部１８０３のユーザーインターフェイスの例を示す。図中の表示部２００１に今回受信した更新データが表示されている。この内容に応じてユーザーは通知が望まれるデータであれば「通知する」ボタン２００２を、通知が不要であると判断した場合は「通知しない」ボタン２００３を押下する。通知選択部１８０３では、受信したＮｏｔｉｃｅ広告に、通知する／しないを示すフラグを追加して通知対象保存部１８０４に保存する。ここまでが初めての更新通知における処理である。
【００７６】
続いて、端末１において再びデータＤ１が更新された場合の処理について述べる。
【００７７】
＜ケース（１）＞
まず、端末２ではデータＤ１の更新通知が不要であり、端末３では必要な場合を説明する。データＤ１の更新を検知した端末１は端末２に対してＮｏｔｉｃｅ広告を送信する。端末２では、通知対象保存部１８０４に保存されているＮｏｔｉｃｅ広告から今回受信したＮｏｔｉｃｅ広告と同一の通知対象識ＩＤを持つ広告を検索する。端末１では通知しないに設定された広告が保存されているので、ユーザーに対する通知は行わず、Ｎｏｔｉｃｅ広告を端末３に向けて転送する。
【００７８】
また、端末１に対する更新データ要求メッセージは直ちには送信しない。端末３は端末２からのＮｏｔｉｃｅ広告を受信すると、端末２に対して更新データ要求メッセージを送信する。端末３からの更新データ要求メッセージを受信した端末２は、端末３に対してＫｅｅｐＡｌｉｖｅ広告を送信し、ここで初めて端末１に対して更新データ要求メッセージを送信する。そして、端末１から更新データを受信したら、これを端末３に向けて転送する。以上により端末３がデータＤ１の更新通知を受けることができる。
【００７９】
＜ケース（２）＞
端末２、端末３ともにデータＤ１の更新通知が不要な場合の処理について説明する。ここでは、端末２が端末３にＮｏｔｉｃｅ広告を転送するまでの処理はケース（１）と同様である。
【００８０】
端末２からのＮｏｔｉｃｅ広告を受信した端末３では、データＤ１の更新通知は不要であり、かつ端末３に登録されている通知先端末はＮｏｔｉｃｅ広告の送信元である端末２のみであるので、このＮｏｔｉｃｅ広告を破棄する。端末２では、Ｎｏｔｉｃｅ広告に記載されている有効期限を過ぎても、他のどの端末からも更新データ要求メッセージを受信しなかったら、この広告を破棄し、端末１から更新データの取得は行わない。以上の処理により、ユーザーの不要な通知や不必要な更新データをネットワークに送出することを抑制することができる。
【００８１】
＜ケース（３）＞
端末２ではデータＤ１の更新通知が必要であり、端末３では不要な場合である。このケースでは第一実施形態と同様の処理が行われる。すなわち、端末１からＮｏｔｉｃｅ広告を受信した端末２は広告を端末３に転送すると共に、端末１に対して更新データ要求メッセージを送信する。端末３では、この広告の示す通知対象の通知は不要であるので広告を破棄して処理を終了する。端末２ではＮｏｔｉｃｅ広告に記載されている有効期限まで他の端末からの更新データ要求メッセージを待ち受け、有効期限が過ぎた時点でこの広告を破棄する。
【００８２】
このように、本実施形態においても、上記第一実施形態と同様の効果を奏することができる。
【００８３】
なお、上述した図１４及び図１７のフローチャートに従ったプログラムを情報通知端末内の記憶装置に格納し動作することにより、上述の制御方法を実現させることが可能となる。
【００８４】
本発明は、上述した実施形態の装置に限定されず、複数の機器から構成されるシステムに適用しても、一つの機器から成る装置に適用してもよい。前述した実施形態の機能を実現するソフトウェアのプログラムコードを記憶した記憶媒体をシステムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、完成されることは言うまでもない。
【００８５】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。プログラムコードを供給するための記憶媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭを用いることができる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけではなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００８６】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、次のプログラムコードの指示に基づき、その拡張機能を拡張ボードや拡張ユニットに備わるＣＰＵなどが処理を行って実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
以上詳細に説明したように、上記各実施形態によれば、ネットワークに接続された複数の装置が情報の更新通知及びデータ取得を分散処理する分散型ネットワークを構築でき、サーバーを必要としない情報通知ネットワークシステムを構成することが可能になる。これにより、従来のようなサーバーへの負荷の一極集中といった問題を回避することができ、全ての装置が更新された情報を速やかに入手することが可能となる。
【００８７】
【発明の効果】
本発明によれば、更新されたデータを所有する装置以外の装置を経由して、データの更新通知が送信されてきた場合であっても、更新されたデータの送信を要求する要求先装置を適応的に選択することができる。従って、各装置は、更新されたデータを所有する装置と直接通信できない場合であっても、更新されたデータを取得することができると共に、更新されたデータを所有する装置が集中的に複数の装置からデータ送信を要求されることを防ぐことができる。
【図面の簡単な説明】
【図１】本発明の第一実施形態に係るネットワークシステムの全体構成を示す図である。
【図２】図１に示した通知グループを形成する情報通知端末の構成図である。
【図３】通知グループへの参加手順を示すシーケンス図である。
【図４】Ｉｎｑｕｉｒｅ広告の構成図である。
【図５】Ｐｒｏｐｏｓａｌ広告の構成図である。
【図６】Ｊｏｉｎ広告の構成図である。
【図７】Ａｃｃｅｐｔ広告の構成図である。
【図８】通知グループからの脱退手順を示すシーケンス図である。
【図９】ＤｉｓＪｏｉｎ広告の構成図である。
【図１０】Ａｌｔ広告の構成図である。
【図１１】ＡｌｔＡｄｄｒ広告の構成図である。
【図１２】通知対象の登録からＮｏｔｉｃｅ広告送信までの手順を示すシーケンス図である。
【図１３】Ｎｏｔｉｃｅ広告の構成図である。
【図１４】広告の受信処理手順を示すフローチャートである。
【図１５】更新データ要求メッセージの構成図である。
【図１６】転送されるＮｏｔｉｃｅ広告の構成図である。
【図１７】更新データ要求メッセージと更新データの送受信処理手順を示すフローチャートである。
【図１８】ＫｅｅｐＡｌｉｖｅ広告の構成図である。
【図１９】本発明の第二実施形態に係るネットワークシステムの全体構成を示す図である。
【図２０】第二実施形態に係る情報通知端末の構成を示すブロック図である。
【図２１】通知選択を行うユーザーインターフェイスの例を示す図である。
【符号の説明】
１〜５ 端末
２０３ 通知対象
２０４ 記憶装置
２０５ 通知対象登録部
２０６ 更新検知部
２０７ 通知先アドレス記憶部
２０８ 広告送信部
２０９ 広告受信部
２１０ 更新データ送信部
２１１ 更新データ受信部
２１２ ネットワークインターフェイス
２１４ ルート探索部
２１５ 広告保存部
２１６ 通知部
【発明の属する技術分野】
本発明は、情報処理装置、情報処理装置の制御方法、及び当該制御方法を実行するためのコンピュータプログラムに関する。
【０００２】
【従来の技術】
近年、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）を利用した情報の提供が急速な普及を見せている。ユーザーはＷＷＷで提供される様々な情報にアクセスし、必要な情報を選択して利用している。
【０００３】
ＷＷＷでは、情報提供者が非同期にかつ不定期に情報を更新する。そのためユーザーは、常に最新の情報を手にするためにいくつものＷｅｂサーバーに能動的にアクセスして、新たな情報が追加されていないか、以前提供された情報が変更されていないかなど、自ら確認する必要がある。
【０００４】
ここで、例えば新種のウィルスやセキュリティーホールの発見に関する情報や、あるいはオークションサイトに登録される新商品の情報など、ユーザーにとって緊急性を要する情報を入手するためには、その緊急度に応じた頻度でＷｅｂサーバーにアクセスする必要があり、ユーザーにとって負担となっていた。
【０００５】
この負担を軽減するために、Ｗｅｂサイトの情報の更新を検知してユーザーに通知するシステムが従来より存在している。例えば特開平１０−１７１７００号公報で提案されているシステムは、ＷＷＷサーバー自体がサーバー上のファイルの更新を検知してそれをユーザーに通知するものである。また、特開２００１−６７２８３号公報で提案されているようにユーザーの登録した文書が更新されたときにメールで通知するものなどが存在する。
【０００６】
【発明が解決しようとする課題】
しかしながら、上記従来のシステムは、いずれも更新検知や通知を行うシステムが一つのサーバー上で運用されているため、ユーザー数の増加に伴い膨大な処理が一極集中するサーバーに対して過度の負荷が発生するという問題があった。さらに、システムを運用するサーバーが停止した場合には一切のサービスが停止してしまうという脆弱さに問題があった。
【０００７】
これに対して、ＵＳＰ５９７８８４２に提案されるシステムには、更新検知の処理は当該文書の更新通知を受ける個々のクライアントに行わせて、サーバーでは更新検知結果の集計と通知のみを行う手法が開示されている。この方法によれば、サーバーにかかる負荷を軽減するという目的においては効果を発揮することが期待できる。しかし、通知に関する処理は依然としてサーバーに集中しており、先に述べた脆弱性に対する改善は図られていない。
【０００８】
本発明は、更新されたデータを所有する装置以外の装置からデータの更新通知を受信した場合であっても、適切な装置から更新されたデータを取得できるようにすることを目的とする。
【０００９】
【課題を解決するための手段】
上記目的を達成するために、本発明は、情報処理装置であって、データが更新されたことを示す更新通知を互いに通知する通知先のアドレスを記憶する記憶手段と、複数の他の装置から更新通知を受信する受信手段と、前記受信手段により受信した更新通知が、更新されたデータを所有する第１の装置以外の装置を経由して送信されてきたか否かを判別すると共に、該更新通知と同じデータの更新通知を既に受信済みか否かを判別する判別手段と、前記判別手段により受信した更新通知と同じデータの更新通知を既に受信済みと判別された場合には、受信した更新通知の送り元が前記第１の装置であれば前記第１の装置のアドレスを記憶し、受信した更新通知の送り元が前記第１の装置でなければ更新通知の送り元の装置の中で前記第１の装置までのホップ数が最小の装置のアドレスを記憶する記憶処理を行い、前記受信手段により受信した更新通知と同じデータの更新通知を受信していない場合には、前記更新通知が前記第１の装置以外の装置を経由して送信されてきたと判別した場合、前記第１の装置のアドレスが前記記憶手段により記憶している通知先アドレスに登録されているときは、前記第１の装置に対して更新されたデータの送信を要求し、前記第１の装置のアドレスが前記記憶手段により記憶している通知先アドレスに登録されていないときは、前記更新通知の送信元である複数の他の装置の中から前記記憶処理により選択される第２の装置に対して、更新されたデータの送信を要求する要求手段と、を有することを特徴とする。
【００１０】
また、本発明は、データが更新されたことを示す更新通知を互いに通知する通知先のアドレスを記憶する記憶手段を有する情報処理装置が実行する制御方法であって、複数の他の装置から更新通知を受信する受信工程と、前記受信工程において受信した更新通知が、更新されたデータを所有する第１の装置以外の装置を経由して送信されてきたか否かを判別すると共に、該更新通知と同じデータの更新通知を既に受信済みか否かを判別する判別工程と、前記判別工程において受信した更新通知と同じデータの更新通知を既に受信済みと判別された場合には、受信した更新通知の送り元が前記第１の装置であれば前記第１の装置のアドレスを記憶し、受信した更新通知の送り元が前記第１の装置でなければ更新通知の送り元の装置の中で前記第１の装置までのホップ数が最小の装置のアドレスを記憶する記憶処理を行い、前記受信工程により受信した更新通知と同じデータの更新通知を受信していない場合には、前記更新通知が前記第１の装置以外の装置を経由して送信されてきたと判別した場合、前記第１の装置のアドレスが前記記憶手段により記憶している通知先アドレスに登録されているときは、前記第１の装置に対して更新されたデータの送信を要求し、前記第１の装置のアドレスが前記記憶手段により記憶している通知先アドレスに登録されていないときは、前記更新通知の送信元である複数の他の装置の中から前記記憶処理により選択される第２の装置に対して、更新されたデータの送信を要求する要求工程と、を有することを特徴とする。
【００１３】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて説明する。
【００１４】
［第一実施形態］
＜ネットワークシステムの構成＞
図１は、本発明の第一実施形態に係るネットワークシステムの全体構成を示す図である。
【００１５】
このネットワークシステムは情報通知端末１〜５で構成されている。端末１〜端末５はいずれもネットワークに接続されていて、各々の端末上のデータＤ１〜Ｄ５の更新を別の端末に対して通知すると同時に、他の端末からの通知を受信する機能を有している。各端末１〜５は互いのアドレスを登録しており直接通信を行う。
【００１６】
初めにこのシステムの動作を、端末１が通知を行う場合を例に簡単に説明する。端末１はデータＤ１の更新を端末２及び端末３に対して通知する。端末１より通知を受けた端末２及び端末３は、端末１に対して更新されたデータの取得を要求し、端末２は端末３、４へ、端末３は端末２、４へそれぞれ端末１からの通知を転送する。端末２及び端末３から通知を受信した端末４は、端末２または３に対して更新されたデータの取得を要求し、また端末５へ通知を転送する。
【００１７】
端末４からデータ取得の要求を受けた端末２または３は、端末１より取得した更新データを端末４に転送する。端末４より通知を受けた端末５は端末４に対して更新されたデータの取得を要求する。端末４は端末２または３より取得した更新データを端末５に転送する。以上により、端末１での更新通知を他の全ての端末が取得することで本システムは機能する。
【００１８】
本実施形態では、これら端末群が構成する仮想ネットワーク（ネットワークシステム）のことを通知グループと呼び、通知グループを形成する端末（及び端末の利用者）のことを参加者と呼ぶこととする。一つの通知グループは参加者間で共有される一つのグループ管理番号を有し、複数の通知グループに参加する参加者はグループ管理番号によっていずれのグループに向けられた通知であるかを識別する。グループ管理番号の詳細については後述する。
【００１９】
＜情報通知端末の構成＞
図２は、図１に示した通知グループを形成する情報通知端末の構成図であり、端末１を例にとって説明するが、他の端末２〜５も同様の構成である。
【００２０】
２０２が本システムを利用するユーザーであり、端末１を介して更新通知の情報を参加者２１７に発信すると同時に、参加者２１７からの更新通知情報を受信する。２０３の通知対象はユーザーが更新を通知しようとしているデータの集合であり、端末１上の記憶装置２０４に記録されている。通知対象２０３はユーザーが通知対象登録部２０５によって登録する。更新検知部２０６は、通知対象２０３に登録されているデータを監視して更新を検知する。
【００２１】
通知先アドレス記憶部２０７には更新の通知先である参加者２１７のアドレスが記録されている。広告送信部２０８は更新が行われたことを参加者２１７に通知する広告を作成し、ネットワークインターフェイス２１２を通じてこれを送信する。広告受信部２０９は参加者２１７からの広告を受信する。
【００２２】
更新データ送信部２１０は、参加者２１７に対して実際の更新データをネットワークインターフェイス２１２を通じて送信する。更新データ受信部２１１は参加者２１７から更新データを受信する。ルート探索部２１４は参加者２１７より受信した広告や更新データを別の参加者に転送する際の転送先や更新データの取得先を決定する。広告保存部２１５は受信した広告を一定期間保存する。通知部２１６は参加者２１７から受けた更新通知をユーザーに通知する。
【００２３】
＜通知グループへの参加＞
初めに、通知グループへの参加について図３のシーケンス図を参照して説明する。
【００２４】
まず、通知を行いたいユーザーの端末上で通知グループを一つ作成する（３０１）。ここでは端末１とするが、どの端末であっても構わない。通知グループにはユニークなＩＤ（例えば端末１のグローバルＩＰアドレスとグループ作成日時の組み合わせ等）が割り振られる。グループの作成が終わった端末１では他端末からの接続を受け付け可能な状態となる。
【００２５】
続いて、通知を受けたいユーザーの端末２が端末１に対してＩｎｑｕｉｒｅ広告を送信する（３０２）。図４にＩｎｑｕｉｒｅ広告を示す。同図において、広告タイプ（４０１）はこの広告の種類で、Ｉｎｑｕｉｒｅが記されている。送信元アドレス（４０２）はこの広告の送信元アドレス（ここでは端末２）である。
【００２６】
Ｉｎｑｕｉｒｅ広告を受信した端末１は端末２に対してＰｒｏｐｏｓａｌ広告を送信して端末１で提供している通知グループのＩＤを通知する（３０３）。図５にＰｒｏｐｏｓａｌ広告を示す。同図において、広告タイプ（５０１）はこの広告の種類で、Ｐｒｏｐｏｓａｌが記されている。送信元アドレス（５０２）はこの広告の送信元アドレス（ここでは端末１）である。グループＩＤリスト（５０３）は端末１で提供している通知グループの識別子である。
【００２７】
端末２のユーザーは参加するグループＩＤリストから参加したいグループを選択し、端末１に対してＪｏｉｎ広告を送信する（３０４）。図６にＪｏｉｎ広告を示す。図６において、広告タイプ（６０１）はこの広告の種類で、Ｊｏｉｎが記されている。送信元アドレス（６０２）はこの広告の送信元アドレス（ここでは端末２）である。グループＩＤ（６０３）は端末２が参加を希望している通知グループの識別子である。
【００２８】
Ｊｏｉｎ広告を受信した端末１は端末２に対してＡｃｃｅｐｔ広告を送信する（３０５）。図７にＡｃｃｅｐｔ広告を示す。図７において、広告タイプ（７０１）はこの広告の種類で、Ａｃｃｅｐｔが記されている。送信元アドレス（７０２）はこの広告の送信元アドレス（ここでは端末１）である。グループＩＤ（７０３）は端末１が端末２に対して参加を認めた通知グループの識別子である。Ａｃｃｅｐｔ広告の送受信が終わると、端末１、２はそれぞれ相手のアドレスを通知先アドレス記憶部に登録する（３０６、３０７）。これにより端末１、２の間に仮想的な経路が張られ、通知グループへの参加手続きが完了する。
【００２９】
通知グループに参加している各端末は、通知グループを作成した端末と同様に他の端末からの参加を受け付けることができる。この場合の参加の手順も図３に示すものと同様である。また、一つの端末が同じ通知グループに属する複数の端末に対して参加を申し込むことも可能である。例えば端末３が端末２に対して参加を申し込んだ後で端末１に参加を申し込むことがあってもよい。そうすることで端末３からは、端末１及び端末２の両端末への仮想的な経路が張られ、明にその存在を知らしめることができる。
【００３０】
なお、通知グループへの参加に際し、何らかの認証を行うことも可能であるが、それについては本発明の規定するところではない。以上が通知グループへの参加手順の説明である。
【００３１】
＜通知グループからの脱退＞
次に、通知グループからの脱退について図８のシーケンス図を参照して説明する。ここでは図１において端末４が脱退する場合を例に説明する。
【００３２】
まず、端末４は通知先アドレス記憶部に登録されている全ての端末（ここでは端末２、３、５）に対してＤｉｓＪｏｉｎ広告を送信する（８０１）。図９にＤｉｓＪｏｉｎ広告を示す。同図において、広告タイプ（９０１）はこの広告の種類で、ＤｉｓＪｏｉｎが記されている。送信元アドレス（９０２）はこの広告の送信元アドレス（ここでは端末４）である。グループＩＤ（９０３）は端末４が脱退を希望している通知グループの識別子である。
【００３３】
ＤｉｓＪｏｉｎ広告を受信した各端末は、通知先アドレス記憶部に登録されているアドレスからＤｉｓＪｏｉｎ広告の送信元アドレスを削除する（８０２）。ここで、通知先アドレスにＤｉｓＪｏｉｎ広告の送信元アドレスしか登録されておらず、別の通知先アドレスが必要となる端末（例えば図１の端末５のように端末４にしか参加していない場合）は、ＤｉｓＪｏｉｎ広告の送信元に対してＡｌｔ広告を送信して別アドレスを要求する（８０３）。図１０にＡｌｔ広告を示す。同図において、広告タイプ（１００１）はこの広告の種類で、Ａｌｔが記されている。送信元アドレス（１００２）はこの広告の送信元アドレス（ここでは端末５）である。グループＩＤ（１００３）はＤｉｓＪｏｉｎ広告に記されていた通知グループの識別子である。
【００３４】
Ａｌｔ広告を受信した端末は通知先アドレス記憶部に登録しているアドレスの内、Ａｌｔ広告の送信元アドレス以外のアドレスをＡｌｔＡｄｄｒ広告に含めてＡｌｔ広告の送信元（端末５）に送信する（８０４）。図１１にＡｌｔＡｄｄｒ広告を示す。同図において、広告タイプ（１１０１）はこの広告の種類で、ＡｌｔＡｄｄｒが記されている。グループＩＤ（１１０２）はＤｉｓＪｏｉｎ広告に記されていた通知グループの識別子である。アドレスリスト（１１０３）は通知先アドレス記憶部に登録されているアドレスのリストである。
【００３５】
ＤｉｓＪｏｉｎまたはＡｌｔ広告を送信しかつＡｌｔＡｄｄｒ広告を受信した端末は、ＤｉｓＪｏｉｎ広告の送信元に対してＢｙｅ広告を送信する（８０５）。ＤｉｓＪｏｉｎ広告を送信した全ての送信先からＢｙｅ広告を受信した段階で端末５の脱退が完了する（８０６）。以上が脱退の手順についての説明である。
【００３６】
＜通知グループの消滅＞
続いて通知グループの消滅について説明する。
【００３７】
通知グループの消滅は参加者数が２（端末Ａ、Ｂとする）の時に一方の端末（端末Ｂとする）が脱退した場合に生じる。初めに端末Ｂが端末Ａに対してＤｉｓＪｏｉｎ広告を送信する。端末Ａでは通知先アドレスに端末Ｂしか登録されていないので、前記通知グループからの脱退手続きに従って端末ＢにＡｌｔ広告を送信して代替アドレスを要求する。
【００３８】
ここで、端末Ｂにおいても通知先アドレスに端末Ａしか登録されていないのでＡｌｔＡｄｄｒ広告で通知できる代替アドレスが存在しない。この場合に端末ＢはＡｌｔＡｄｄｒ広告をアドレスリストに何も記載せずに送信する。アドレスリストが空のＡｌｔＡｄｄｒ広告を受信した端末Ａは端末Ｂに対してＢｙｅ広告を送信して脱退を許可する。Ｂｙｅ広告を受信した端末Ｂでは脱退手続きを完了する。この時点で通知グループの参加者は端末Ａのみとなり、通知グループを消滅させることが可能となる。
【００３９】
なお、最後の参加者は当該グループを維持してもよい。この方法によれば通知グループ作成者が途中で通知グループを脱退しても、参加者数が１となるまでは残りの参加者によって通知グループを維持することが可能である。
【００４０】
＜データの更新を通知する手順＞
図１及び図２で示したシステムにおいて、端末１上のデータＤ１の更新を他の端末（端末２〜端末５）に対して通知する手順を、図１２のシーケンス図を参照して説明する。
【００４１】
端末１を利用しているユーザーがデータＤ１の更新を通知グループの参加者に通知する場合、まずユーザーは通知対象登録部２０５を通じてデータＤ１を通知対象２０３に登録する（１２０１）。
【００４２】
通知対象登録部２０５はデータＤ１に対してユニークな管理番号を割り当ててこれを管理する。通知対象２０３に割り当てられる管理番号は各端末の内部においてユニークである必要があるが、他の端末とは無関係に設定可能である。端末１では更新検知部２０６は通知対象２０３を監視している（１２０２）。ここでユーザーがデータＤ１を更新すると（１２０３）、更新検知部２０６がこれを検知し（１２０４）、広告送信部２０８にその管理番号を通知する（１２０５）。更新検知部２０６から通知を受けた広告送信部２０８は、通知先アドレス記憶部２０７から端末１に登録されている参加者のアドレスを取得する（１２０６）。図１の例では端末１に登録されている参加者は端末２及び端末３である。
【００４３】
続いて、広告送信部２０８は登録されている各参加者に対してＮｏｔｉｃｅ広告を送信する（１２０７）。Ｎｏｔｉｃｅ広告の内容を図１３に示す。同図において広告タイプ（１３０１）はこの広告の種類でＮｏｔｉｃｅが記されている。グループＩＤ（１３０２）はこの広告を受信する通知グループの識別子、広告番号（１３０３）は通知元がこの通知グループに送信した広告を一意に特定可能な番号、送信元アドレス（１３０４）はこの広告の送信元アドレス（ここでは端末１のアドレス）、通知元アドレス（１３０５）は更新されたデータを所有する端末のアドレス（ここでは端末１のアドレス）、通知対象ＩＤ（１３０６）は端末１において識別可能な通知対象の識別子、ホップ数（１３０７）は通知元から数えてこの広告が何回転送されているか（ここでは０）、広告有効期限（１３０８）はこの広告の有効期限を、それぞれ示すものである。
【００４４】
＜Ｎｏｔｉｃｅ広告受信処理＞
次に、端末２におけるＮｏｔｉｃｅ広告受信処理について図１４のフローチャートを用いて説明する。なお、端末３は端末２と同等であるためここでは端末２について説明する。
【００４５】
本システムにおいて、端末２がデータＤ１の更新に関するＮｏｔｉｃｅ広告を受信する経路には、
（１）端末１から
（２）端末３から
（３）端末４から
の３パターンが存在し、パターン（１）とそれ以外の場合で処理が異なる。
【００４６】
初めに、端末１から広告を受信した場合（パターン（１））について説明する。 広告受信部２０９で広告を受信した端末２は、まず広告タイプを抽出する（ステップＳ１）。広告タイプがＮｏｔｉｃｅであれば（ステップＳ２）、次にグループＩＤを抽出する（ステップＳ３）。自分の所属する通知グループのＩＤと比較し（ステップＳ４）、異なるグループＩＤであればこの広告は誤って送信されたものであるので端末２は直ちにこの広告を破棄して処理を終える（ステップＳ５）。
【００４７】
自分の属する通知グループを示すグループＩＤであった場合は続いて広告有効期限を抽出する（ステップＳ６）。現在時刻が広告有効期限を過ぎていればこの広告を破棄して処理を終える（ステップＳ７，ステップＳ５）。広告が有効期限内であれば広告をルート探索部２１４に引き渡す。
【００４８】
ルート探索部２１４はまず広告番号と通知元アドレスを抽出する（ステップＳ８）。抽出した通知元アドレスと広告番号を広告保存部２１５に保存されているＮｏｔｉｃｅ広告のそれと比較する。保存されているＮｏｔｉｃｅ広告に一致するものが見つかった場合（つまり端末３〜４からのＮｏｔｉｃｅ広告を既に受信している場合）は（ステップＳ９）、保存されているＮｏｔｉｃｅ広告を今回受信した端末１からのＮｏｔｉｃｅ広告（すなわち送信元と通知元が同一な広告）で置き換えた後（ステップＳ１０、ステップＳ１１）、処理を終了する。
【００４９】
いずれのＮｏｔｉｃｅ広告とも一致しなかった場合はこのＮｏｔｉｃｅ広告を新規に広告保存部２１５に保存し（ステップＳ２１）、更新データ取得処理（Ａ）に進む。
【００５０】
更新データ取得処理ではまず、ホップ数を抽出する（ステップＳ２２）。端末１からのＮｏｔｉｃｅ広告ではホップ数が０であるので（ステップＳ２３）、通知元から直接Ｎｏｔｉｃｅ広告を受信したことが分かる。その場合は通知元アドレスを抽出し、通知元アドレスに対して直接更新データ要求メッセージを送信する（ステップＳ２４）。更新データ要求メッセージは図１５に示すように、受信したＮｏｔｉｃｅ広告と同一のグループＩＤ（１４０１）、広告番号（１４０２）、通知対象ＩＤ（１４０３）、及びこのメッセージの送信元アドレス（１４０４）が含まれる。
【００５１】
更新データ要求メッセージを送信したら続いて広告転送処理を行う（ステップＳ２５）。各端末は受信したＮｏｔｉｃｅ広告を通知先アドレス記憶部２０７に記録されている参加者に対して転送する。端末２において記録されている参加者は端末１、３、４であるが、このうち端末１はＮｏｔｉｃｅ広告の送信元であるので、これを除いた端末３、４に対して転送する。転送されるＮｏｔｉｃｅ広告の内容は図１６に示すように、送信元アドレスが端末２のアドレスである点、及びホップ数が１増加されている点を除いて、端末１より受信したＮｏｔｉｃｅ広告と同一である。
【００５２】
次に端末２が端末３、４からＮｏｔｉｃｅ広告を受信した場合（パターン（２），（３））について説明する。
【００５３】
受信から有効期限の判定までの処理（ステップＳ１〜ステップＳ１０）は前記パターン（１）と同様であるので、ここでの説明は省略する。続く広告の保存処理であるが、広告保存部２１５に今回受信した広告と一致するＮｏｔｉｃｅ広告が保存されていた場合は、両者のホップ数を比較し（ステップＳ２６）、今回の広告の方がホップ数が小さければ保存データを置き換える（ステップＳ１１）。この例では端末４からの広告（ホップ数＝２）を受信した後に端末３からの広告（ホップ数＝１）を受信した場合に端末３からの広告を保存することになる。これにより、広告保存部２１５には常に通知元までのホップ数が最少のＮｏｔｉｃｅ広告が保存されていることになる。Ｎｏｔｉｃｅ広告を保存した後は処理を終了する。
【００５４】
一方、一致するＮｏｔｉｃｅ広告が見つからなかった場合は、今回受信したＮｏｔｉｃｅ広告を新規に保存して（ステップＳ２１）、更新データ取得処理（Ａ）に進む。更新データ取得処理では、まずホップ数を取得する（ステップＳ２２）。ここで受信したＮｏｔｉｃｅ広告はいずれかの端末において１回以上転送されているため、ホップ数が１以上になっている（ステップＳ２３）。ホップ数が１以上のＮｏｔｉｃｅ広告を受信した端末は通知元アドレスを抽出し、自分の通知先アドレス記憶部２０７に登録されている参加者のアドレスと比較する（ステップＳ２７）。
【００５５】
抽出した通知元アドレスが参加者アドレスのいずれかに一致がみられた場合（この例で端末２は端末１を登録している）、この端末はいずれ通知元から直接Ｎｏｔｉｃｅ広告が受信されることが期待される。したがって、ホップ数が０のＮｏｔｉｃｅ広告を受信した場合と同一とみなし、通知元アドレスに対して直接更新データ要求メッセージを送信する（ステップＳ２４）。最後に広告の転送処理を行う（ステップＳ２５）。
【００５６】
端末３から広告を受信した場合、端末１が通知元であり、また端末３は広告の送信元であるので、これらを除いた端末４に対してＮｏｔｉｃｅ広告を転送する。端末４から受信した場合も同様に、通知元とＮｏｔｉｃｅ広告の送信元を除いた参加者に対してＮｏｔｉｃｅ広告を転送する。Ｎｏｔｉｃｅ広告の内容は前記パターン１の場合と同一である。
【００５７】
以上はＮｏｔｉｃｅ広告の通知元アドレスが通知先アドレス記憶部２０７に登録されている端末における広告受信処理である。
【００５８】
続いて、通知元アドレスが通知先アドレス記憶部２０７に登録されていない端末（端末４、５）におけるデータＤ１の更新に関するＮｏｔｉｃｅ広告の受信処理を説明する。
【００５９】
受信から広告保存までの処理（ステップＳ１〜ステップＳ２１）は前記パターン（２）と同様であるので説明は省略し、更新データ取得処理（Ａ）の説明から始める。ここで受信したＮｏｔｉｃｅ広告はいずれかの端末において１回以上転送されているため、ホップ数が１以上になっている（ステップＳ２３）。ホップ数が１以上のＮｏｔｉｃｅ広告を受信した端末は通知元アドレスを抽出し、自分の通知先アドレス記憶部２０７に登録されている参加者のアドレスと比較する（ステップＳ２７）。いずれのアドレスとも一致しなかった場合（端末４、５においては端末１は通知先アドレスに登録されていない）、端末４、５は２つの方法を選択することができる（ステップＳ３０）。
【００６０】
一つ目は、通知元アドレスに対して直接更新データ要求メッセージを送り（ステップＳ３１）、同時に通知元アドレスを通知先アドレス記憶部２０７に追加する方法である（ステップＳ３２）。これにより、端末４は端末１との間に仮想的な経路を張ることができ、これ以降、端末１からのＮｏｔｉｃｅ広告を直接受信することができるようになる。
【００６１】
２つ目は、広告保存部２１５に保存されているＮｏｔｉｃｅ広告の送信元端末（端末１への最短ホップを実現する。以下、最適端末と呼ぶ）に対して更新データ要求メッセージを送信する方法である。この方法では、端末４は端末１に対して自身のアドレスを秘匿することが可能である。そのかわり、端末１からの通知を直接受信することはできない。また、受信したＮｏｔｉｃｅ広告の送信元と最適端末とは必ずしも一致しない。
【００６２】
そこで、まず最適端末に対して更新データ要求メッセージを送信し（ステップＳ３３）、応答が得られなかった場合は（ステップＳ３４）、今回受信したＮｏｔｉｃｅ広告の送信元に更新データ要求メッセージを送信する（ステップＳ３５）。いずれかの方法で更新データ要求メッセージを送信したら、最後にＮｏｔｉｃｅ広告の転送処理を行う（ステップＳ２５）。既に述べたように通知先アドレス記憶部２０７に登録されているものから通知元と広告の送信元を除いた参加者に対してＮｏｔｉｃｅ広告を転送する。Ｎｏｔｉｃｅ広告の内容は前記パターン（１）と同様である。
【００６３】
以上がＮｏｔｉｃｅ広告受信処理の説明である。
【００６４】
＜更新データ要求メッセージ受信処理＞
次に、更新データ要求メッセージ受信処理について図１７のフローチャートを参照して説明する。
【００６５】
初めに通知元（端末１）における処理を説明する。端末１では、受信した更新データ要求メッセージ（ステップＳ７１）から、グループＩＤ、広告番号、及び通知対象ＩＤをそれぞれ抽出し（ステップＳ７２）、送信したＮｏｔｉｃｅ広告の内容と相違ないことを確認する（ステップＳ７３、ステップＳ７４）。メッセージの内容に不正がなければメッセージの送信元アドレスに対して更新データを送信する（ステップＳ７５，ステップＳ７６）。
【００６６】
続いて、メッセージの送信元アドレスを通知先アドレス記憶部２０７に登録されている参加者のアドレスと比較し（ステップＳ７７）、未登録であればこれを追加する（ステップＳ７８）。
【００６７】
次に、通知元アドレスが通知先アドレス記憶部２０７に登録されている端末（端末２または３）における処理を説明する。端末２（または３）が端末４から更新データ要求メッセージを受信したら（ステップＳ７１）、メッセージからグループＩＤ、広告番号、及び通知対象ＩＤをそれぞれ抽出し（ステップＳ７２）、広告保存部２１５に内容の一致するＮｏｔｉｃｅ広告が保存されているかを検証する（ステップＳ７３、ステップＳ７９）。
【００６８】
一致するＮｏｔｉｃｅ広告が見つかった場合は要求が正当であるとし、通知元より受信した更新データをメッセージの送信元アドレスに転送する（ステップＳ８０〜ステップＳ８２）。通知元から更新データを受信できていない場合は、更新データを受信するまで端末４に対してＫｅｅｐＡｌｉｖｅ広告を送信する（ステップＳ８３）。ＫｅｅｐＡｌｉｖｅ広告の内容を図１８に示す。
【００６９】
最後に通知元アドレスが通知先アドレス記憶部２０７に登録されていない端末（端末４）における処理を説明する。端末５より更新データ要求メッセージを受信した端末４は、メッセージからグループＩＤ、広告番号、及び通知対象ＩＤをそれぞれ抽出し、広告保存部２１５に内容の一致するＮｏｔｉｃｅ広告が保存されているかを検証する。一致するＮｏｔｉｃｅ広告が見つかった場合は要求が正当であるとし、通知元またはＮｏｔｉｃｅ広告送信元から受信した更新データをメッセージの送信元アドレスに転送する（ステップＳ８０、ステップＳ８４）。通知元から更新データを受信できていない場合は、更新データを受信するまで端末５に対してＫｅｅｐＡｌｉｖｅ広告を送信する（ステップＳ８３）。
【００７０】
以上述べたように本実施形態によれば、ネットワークに接続された複数の端末が情報の更新通知やデータ取得を分散処理する分散型ネットワークを構築することができるので、サーバーを必要としない情報通知ネットワークシステムを構成することが可能になる。これにより、従来のようなサーバーへの負荷の一極集中といった問題を回避することができ、さらには、情報提供者が自ら、情報の更新を通知メッセージで送信して、ネットワークを構成するユーザー間で通知メッセージを転送することにより、全てのユーザーが更新された情報を即座に入手することが可能である。
【００７１】
［第二実施形態］
図１９は、本発明の第二実施形態に係るネットワークシステムの全体構成を示す図であり、図２０は、第二実施形態に係る情報通知端末の構成を示すブロック図である。
【００７２】
このネットワークシステムは情報通知端末１〜３で構成され、端末１〜端末３は順次ネットワークに接続されている。各端末１〜３の構成は、図２０に示すように、通知選択部１８０３、通知対象保存部１８０４、通知部１８０５、及び広告受信部１８０６を備えている。
【００７３】
以上の構成において、端末１のユーザーがデータＤ１を通知対象に指定して、端末２及び端末３に更新の通知を行う場合について説明する。
【００７４】
まず、データＤ１を初めて更新検知した際のＮｏｔｉｃｅ広告の送受信処理は第一実施形態に準じる。Ｎｏｔｉｃｅ広告の受信に続いて更新データ要求メッセージを送信し、更新データを受信した端末２（及び端末３）では、ユーザーが当該データの更新通知の要／不要を判定する。
【００７５】
図２１に通知選択部１８０３のユーザーインターフェイスの例を示す。図中の表示部２００１に今回受信した更新データが表示されている。この内容に応じてユーザーは通知が望まれるデータであれば「通知する」ボタン２００２を、通知が不要であると判断した場合は「通知しない」ボタン２００３を押下する。通知選択部１８０３では、受信したＮｏｔｉｃｅ広告に、通知する／しないを示すフラグを追加して通知対象保存部１８０４に保存する。ここまでが初めての更新通知における処理である。
【００７６】
続いて、端末１において再びデータＤ１が更新された場合の処理について述べる。
【００７７】
＜ケース（１）＞
まず、端末２ではデータＤ１の更新通知が不要であり、端末３では必要な場合を説明する。データＤ１の更新を検知した端末１は端末２に対してＮｏｔｉｃｅ広告を送信する。端末２では、通知対象保存部１８０４に保存されているＮｏｔｉｃｅ広告から今回受信したＮｏｔｉｃｅ広告と同一の通知対象識ＩＤを持つ広告を検索する。端末１では通知しないに設定された広告が保存されているので、ユーザーに対する通知は行わず、Ｎｏｔｉｃｅ広告を端末３に向けて転送する。
【００７８】
また、端末１に対する更新データ要求メッセージは直ちには送信しない。端末３は端末２からのＮｏｔｉｃｅ広告を受信すると、端末２に対して更新データ要求メッセージを送信する。端末３からの更新データ要求メッセージを受信した端末２は、端末３に対してＫｅｅｐＡｌｉｖｅ広告を送信し、ここで初めて端末１に対して更新データ要求メッセージを送信する。そして、端末１から更新データを受信したら、これを端末３に向けて転送する。以上により端末３がデータＤ１の更新通知を受けることができる。
【００７９】
＜ケース（２）＞
端末２、端末３ともにデータＤ１の更新通知が不要な場合の処理について説明する。ここでは、端末２が端末３にＮｏｔｉｃｅ広告を転送するまでの処理はケース（１）と同様である。
【００８０】
端末２からのＮｏｔｉｃｅ広告を受信した端末３では、データＤ１の更新通知は不要であり、かつ端末３に登録されている通知先端末はＮｏｔｉｃｅ広告の送信元である端末２のみであるので、このＮｏｔｉｃｅ広告を破棄する。端末２では、Ｎｏｔｉｃｅ広告に記載されている有効期限を過ぎても、他のどの端末からも更新データ要求メッセージを受信しなかったら、この広告を破棄し、端末１から更新データの取得は行わない。以上の処理により、ユーザーの不要な通知や不必要な更新データをネットワークに送出することを抑制することができる。
【００８１】
＜ケース（３）＞
端末２ではデータＤ１の更新通知が必要であり、端末３では不要な場合である。このケースでは第一実施形態と同様の処理が行われる。すなわち、端末１からＮｏｔｉｃｅ広告を受信した端末２は広告を端末３に転送すると共に、端末１に対して更新データ要求メッセージを送信する。端末３では、この広告の示す通知対象の通知は不要であるので広告を破棄して処理を終了する。端末２ではＮｏｔｉｃｅ広告に記載されている有効期限まで他の端末からの更新データ要求メッセージを待ち受け、有効期限が過ぎた時点でこの広告を破棄する。
【００８２】
このように、本実施形態においても、上記第一実施形態と同様の効果を奏することができる。
【００８３】
なお、上述した図１４及び図１７のフローチャートに従ったプログラムを情報通知端末内の記憶装置に格納し動作することにより、上述の制御方法を実現させることが可能となる。
【００８４】
本発明は、上述した実施形態の装置に限定されず、複数の機器から構成されるシステムに適用しても、一つの機器から成る装置に適用してもよい。前述した実施形態の機能を実現するソフトウェアのプログラムコードを記憶した記憶媒体をシステムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、完成されることは言うまでもない。
【００８５】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。プログラムコードを供給するための記憶媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭを用いることができる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけではなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００８６】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、次のプログラムコードの指示に基づき、その拡張機能を拡張ボードや拡張ユニットに備わるＣＰＵなどが処理を行って実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
以上詳細に説明したように、上記各実施形態によれば、ネットワークに接続された複数の装置が情報の更新通知及びデータ取得を分散処理する分散型ネットワークを構築でき、サーバーを必要としない情報通知ネットワークシステムを構成することが可能になる。これにより、従来のようなサーバーへの負荷の一極集中といった問題を回避することができ、全ての装置が更新された情報を速やかに入手することが可能となる。
【００８７】
【発明の効果】
本発明によれば、更新されたデータを所有する装置以外の装置を経由して、データの更新通知が送信されてきた場合であっても、更新されたデータの送信を要求する要求先装置を適応的に選択することができる。従って、各装置は、更新されたデータを所有する装置と直接通信できない場合であっても、更新されたデータを取得することができると共に、更新されたデータを所有する装置が集中的に複数の装置からデータ送信を要求されることを防ぐことができる。
【図面の簡単な説明】
【図１】本発明の第一実施形態に係るネットワークシステムの全体構成を示す図である。
【図２】図１に示した通知グループを形成する情報通知端末の構成図である。
【図３】通知グループへの参加手順を示すシーケンス図である。
【図４】Ｉｎｑｕｉｒｅ広告の構成図である。
【図５】Ｐｒｏｐｏｓａｌ広告の構成図である。
【図６】Ｊｏｉｎ広告の構成図である。
【図７】Ａｃｃｅｐｔ広告の構成図である。
【図８】通知グループからの脱退手順を示すシーケンス図である。
【図９】ＤｉｓＪｏｉｎ広告の構成図である。
【図１０】Ａｌｔ広告の構成図である。
【図１１】ＡｌｔＡｄｄｒ広告の構成図である。
【図１２】通知対象の登録からＮｏｔｉｃｅ広告送信までの手順を示すシーケンス図である。
【図１３】Ｎｏｔｉｃｅ広告の構成図である。
【図１４】広告の受信処理手順を示すフローチャートである。
【図１５】更新データ要求メッセージの構成図である。
【図１６】転送されるＮｏｔｉｃｅ広告の構成図である。
【図１７】更新データ要求メッセージと更新データの送受信処理手順を示すフローチャートである。
【図１８】ＫｅｅｐＡｌｉｖｅ広告の構成図である。
【図１９】本発明の第二実施形態に係るネットワークシステムの全体構成を示す図である。
【図２０】第二実施形態に係る情報通知端末の構成を示すブロック図である。
【図２１】通知選択を行うユーザーインターフェイスの例を示す図である。
【符号の説明】
１〜５ 端末
２０３ 通知対象
２０４ 記憶装置
２０５ 通知対象登録部
２０６ 更新検知部
２０７ 通知先アドレス記憶部
２０８ 広告送信部
２０９ 広告受信部
２１０ 更新データ送信部
２１１ 更新データ受信部
２１２ ネットワークインターフェイス
２１４ ルート探索部
２１５ 広告保存部
２１６ 通知部
Claims (15)
- 情報処理装置であって、
データが更新されたことを示す更新通知を互いに通知する通知先のアドレスを記憶する記憶手段と、
複数の他の装置から更新通知を受信する受信手段と、
前記受信手段により受信した更新通知が、更新されたデータを所有する第１の装置以外の装置を経由して送信されてきたか否かを判別すると共に、該更新通知と同じデータの更新通知を既に受信済みか否かを判別する判別手段と、
前記判別手段により受信した更新通知と同じデータの更新通知を既に受信済みと判別された場合には、受信した更新通知の送り元が前記第１の装置であれば前記第１の装置のアドレスを記憶し、受信した更新通知の送り元が前記第１の装置でなければ更新通知の送り元の装置の中で前記第１の装置までのホップ数が最小の装置のアドレスを記憶する記憶処理を行い、前記受信手段により受信した更新通知と同じデータの更新通知を受信していない場合には、前記更新通知が前記第１の装置以外の装置を経由して送信されてきたと判別した場合、前記第１の装置のアドレスが前記記憶手段により記憶している通知先アドレスに登録されているときは、前記第１の装置に対して更新されたデータの送信を要求し、前記第１の装置のアドレスが前記記憶手段により記憶している通知先アドレスに登録されていないときは、前記更新通知の送信元である複数の他の装置の中から前記記憶処理により選択される第２の装置に対して、更新されたデータの送信を要求する要求手段と、
を有することを特徴とする情報処理装置。 - 前記更新通知には、前記更新通知が装置間で転送された回数を示すホップ数が含まれ、
前記判別手段は、前記ホップ数により前記第１の装置以外の装置を経由して送信されたか否かを判別することを特徴とする請求項１に記載の情報処理装置。 - 前記要求手段は、前記第１の装置のアドレスが前記記憶手段により記憶している通知先アドレスに登録されていないときは、前記ホップ数が最小の更新通知を送信した装置を前記第２の装置として選択し、更新されたデータの送信を要求することを特徴とする請求項２に記載の情報処理装置。
- 前記要求手段は、前記判別手段により前記更新通知が前記第１の装置以外の装置を経由して送信されてきたと判別した場合、前記第１の装置のアドレスが前記記憶手段により記憶している通知先アドレスに登録されていないときは、前記第１の装置と前記第２の装置のいずれか一方に対して、更新されたデータの送信を要求することを特徴とする請求項１から３のいずれか１項に記載の情報処理装置。
- 前記要求手段は、前記判別手段により前記更新通知が前記第１の装置から直接送信されてきたと判別した場合、前記第１の装置に対して更新されたデータの送信を要求することを特徴とする請求項１から４のいずれか１項に記載の情報処理装置。
- 前記受信手段により前記更新通知を受信した場合に、前記記憶手段により記憶している通知先アドレスを有する装置に対して、前記更新通知を転送する転送手段を有することを特徴とする請求項１から５のいずれか１項に記載の情報処理装置。
- 更新されたデータの送信要求を受信する要求受信手段を有し、前記要求受信手段により更新されたデータの送信要求を受信した場合は、前記送信要求の送信元装置に対して、更新されたデータを送信することを特徴とする請求項１から６のいずれか１項に記載の情報処理装置。
- 前記要求受信手段により更新されたデータの送信要求を受信した場合に、前記情報処理装置が更新されたデータを受信済みでない場合は、前記送信要求の送信元装置に対して、更新されたデータの受信が済むまで待機するよう指示することを特徴とする請求項７に記載の情報処理装置。
- 前記記憶手段は、更新通知の通知先となるグループに参加している装置のアドレスを通知先アドレスとして記憶することを特徴とする請求項１から８のいずれか１項に記載の情報処理装置。
- 前記グループに参加していない外部装置からのグループへの参加要求に応じて、前記外部装置のアドレスを前記通知先アドレスに登録することを特徴とする請求項９に記載の情報処理装置。
- 前記グループからの脱退要求を受信した場合に、前記通知先アドレスに前記脱退要求の送信元装置のアドレスのみ登録されている場合は、前記脱退要求の送信元装置から、前記グループに参加している装置のアドレスを取得し、取得したアドレスを前記通知先アドレスとして登録することを特徴とする請求項９又は１０に記載の情報処理装置。
- 前記更新通知は、通知先となるグループを識別するための識別子を含むことを特徴とする請求項９から１１のいずれか１項に記載の情報処理装置。
- 前記更新通知は、更新されたデータを識別するための識別子を含むことを特徴とする請求項１から１２のいずれか１項に記載の情報処理装置。
- データが更新されたことを示す更新通知を互いに通知する通知先のアドレスを記憶する記憶手段を有する情報処理装置が実行する制御方法であって、
複数の他の装置から更新通知を受信する受信工程と、
前記受信工程において受信した更新通知が、更新されたデータを所有する第１の装置以外の装置を経由して送信されてきたか否かを判別すると共に、該更新通知と同じデータの更新通知を既に受信済みか否かを判別する判別工程と、
前記判別工程において受信した更新通知と同じデータの更新通知を既に受信済みと判別された場合には、受信した更新通知の送り元が前記第１の装置であれば前記第１の装置のアドレスを記憶し、受信した更新通知の送り元が前記第１の装置でなければ更新通知の送り元の装置の中で前記第１の装置までのホップ数が最小の装置のアドレスを記憶する記憶処理を行い、前記受信工程により受信した更新通知と同じデータの更新通知を受信していない場合には、前記更新通知が前記第１の装置以外の装置を経由して送信されてきたと判別した場合、前記第１の装置のアドレスが前記記憶手段により記憶している通知先アドレスに登録されているときは、前記第１の装置に対して更新されたデータの送信を要求し、前記第１の装置のアドレスが前記記憶手段により記憶している通知先アドレスに登録されていないときは、前記更新通知の送信元である複数の他の装置の中から前記記憶処理により選択される第２の装置に対して、更新されたデータの送信を要求する要求工程と、
を有することを特徴とする情報処理装置の制御方法。 - 請求項１４に記載の制御方法をコンピュータに実行させるためのコンピュータプログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002174245A JP4095352B2 (ja) | 2002-06-14 | 2002-06-14 | 情報処理装置、情報処理装置の制御方法、及び当該制御方法を実行するためのコンピュータプログラム |
| US10/452,308 US7457840B2 (en) | 2002-06-14 | 2003-06-03 | Communicating method of information sharing network, information processing apparatus, and its control method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002174245A JP4095352B2 (ja) | 2002-06-14 | 2002-06-14 | 情報処理装置、情報処理装置の制御方法、及び当該制御方法を実行するためのコンピュータプログラム |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2004021502A JP2004021502A (ja) | 2004-01-22 |
| JP2004021502A5 JP2004021502A5 (ja) | 2005-04-07 |
| JP4095352B2 true JP4095352B2 (ja) | 2008-06-04 |
Family
ID=29727957
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002174245A Expired - Fee Related JP4095352B2 (ja) | 2002-06-14 | 2002-06-14 | 情報処理装置、情報処理装置の制御方法、及び当該制御方法を実行するためのコンピュータプログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7457840B2 (ja) |
| JP (1) | JP4095352B2 (ja) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| TWI370979B (en) * | 2004-05-14 | 2012-08-21 | Ibm | Grid computing system, information processing unit, job execution request generation unit, control method, program, and recording medium |
| JP4635615B2 (ja) * | 2005-01-17 | 2011-02-23 | 富士ゼロックス株式会社 | 情報処理装置、システム、データ同期方法及びプログラム |
| JP2006319909A (ja) * | 2005-05-16 | 2006-11-24 | Konica Minolta Holdings Inc | データ通信の方法、ピアツーピア型のネットワーク、および情報処理装置 |
| KR100782856B1 (ko) * | 2006-09-26 | 2007-12-06 | 삼성전자주식회사 | 디지털 방송 수신기의 소프트웨어 업그레이드 방법 및 장치 |
| JP4613246B2 (ja) * | 2007-03-16 | 2011-01-12 | 富士通株式会社 | ネットワーク管理のための管理ネットワーク、その管理方法、およびそれに使用されるネットワーク要素 |
| JP2011096275A (ja) * | 2010-12-17 | 2011-05-12 | Fujitsu Ltd | ファイル管理システム |
| JP5736972B2 (ja) * | 2011-05-30 | 2015-06-17 | 富士ゼロックス株式会社 | 蓄積装置及び通信システム |
| KR20130038734A (ko) * | 2011-10-10 | 2013-04-18 | 한국전자통신연구원 | 단말의 응용프로그램을 관리하는 방법 및 장치, 단말에서 응용프로그램을 관리하는 방법 및 장치 |
| CN106209926B (zh) * | 2015-04-30 | 2019-06-21 | 阿里巴巴集团控股有限公司 | 一种数据更新方法和设备 |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2503362B2 (ja) | 1993-04-30 | 1996-06-05 | 株式会社富士通ソーシアルサイエンスラボラトリ | 同期型情報交換システムにおける情報交換方法と情報交換装置の作成方法 |
| DE69527948T2 (de) * | 1994-03-15 | 2003-01-02 | Digi International, Inc. | System und verfahren zur kommunikation mit einem entfernten netzwerk-apparatus |
| US6240451B1 (en) * | 1995-05-25 | 2001-05-29 | Punch Networks Corporation | Method and apparatus for automatically disseminating information over a network |
| JP3062104B2 (ja) | 1996-12-06 | 2000-07-10 | 中部日本電気ソフトウェア株式会社 | Ｗｗｗ更新通知システム |
| US5978842A (en) | 1997-01-14 | 1999-11-02 | Netmind Technologies, Inc. | Distributed-client change-detection tool with change-detection augmented by multiple clients |
| US5976842A (en) * | 1997-10-30 | 1999-11-02 | Clontech Laboratories, Inc. | Methods and compositions for use in high fidelity polymerase chain reaction |
| JP2001067283A (ja) | 1999-08-26 | 2001-03-16 | Dokomo Eng Kk | ホームページ配信装置 |
| JP3571616B2 (ja) * | 2000-05-23 | 2004-09-29 | エヌ・ティ・ティ・コムウェア株式会社 | データの共有方法、端末装置および記録媒体 |
| US7086050B2 (en) * | 2000-08-04 | 2006-08-01 | Mcafee, Inc. | Updating computer files |
| JP3503592B2 (ja) | 2000-11-22 | 2004-03-08 | 日本電気株式会社 | ネットワークシステム及び情報機器 |
| US6839769B2 (en) * | 2001-05-31 | 2005-01-04 | Intel Corporation | Limiting request propagation in a distributed file system |
| US7013347B1 (en) * | 2001-10-16 | 2006-03-14 | Cisco Technology, Inc. | Distance vector extension to the address resolution protocol |
-
2002
- 2002-06-14 JP JP2002174245A patent/JP4095352B2/ja not_active Expired - Fee Related
-
2003
- 2003-06-03 US US10/452,308 patent/US7457840B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004021502A (ja) | 2004-01-22 |
| US20030233442A1 (en) | 2003-12-18 |
| US7457840B2 (en) | 2008-11-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8909710B2 (en) | Method for discovering and discriminating devices on local collaborative networks to facilitate collaboration among users | |
| JP4786882B2 (ja) | ピアツーピア名前解決ワイヤプロトコルで使用するデータ構造を格納したコンピュータ可読媒体 | |
| JP5048684B2 (ja) | 通信ネットワークに対する選択的なサービス更新方法 | |
| US7437126B2 (en) | Radio terminal, communication control method and computer program | |
| JP5902820B2 (ja) | ピアツーピアコンテンツ配信システムにおけるピアによって受信されたコンテンツの完全性の確認 | |
| WO2006068365A1 (en) | P2p overlay network construction method and apparatus | |
| JPH09511115A (ja) | スケーラブル分散計算環境 | |
| US8909790B2 (en) | Method, server and system for controlling a virtual role | |
| JP2006236344A (ja) | ピアツーピアネットワークを利用したコミュニティ形成方法 | |
| JP2005501311A (ja) | 分散コンピュータ・ネットワーク内の資源要求に応答するシステムおよび方法 | |
| JP2015204110A (ja) | コンテンツ中心ネットワークにおける簡単なサービス検出のためのシステム及び方法 | |
| JP4095352B2 (ja) | 情報処理装置、情報処理装置の制御方法、及び当該制御方法を実行するためのコンピュータプログラム | |
| JP2013542681A (ja) | コンテンツ中心のネットワーク環境でグループ変更に関する情報を用いるコンテンツ共有方法及び装置 | |
| JP4607764B2 (ja) | モバイルピアツーピアネットワーク構築 | |
| US8051157B2 (en) | Discovery apparatus and method | |
| JP4604142B2 (ja) | ネットワークを用いた通信システム及びその通信システムに用いられる通信装置及びプログラム | |
| WO2007119422A1 (ja) | 情報通信システム、情報通信方法、情報通信システムに含まれるノード装置および情報処理プログラムが記録された記録媒体 | |
| JP2002269059A (ja) | クライアントサーバシステム、中継サーバ、クライアント端末装置の接続先サーバ決定方法 | |
| JP2006186526A (ja) | 通信中継装置、通信端末装置、通信システム、および通信方法 | |
| JP3616129B2 (ja) | 通信制御装置及び通信制御方法 | |
| JP3609624B2 (ja) | 移動計算機装置、移動計算機管理装置、モバイル情報管理装置及び通信制御方法 | |
| JP2004129159A (ja) | パケット変換方法、パケット通信システム、パケット変換装置、パケット変換プログラムおよび記録媒体 | |
| JP2006171917A (ja) | 無線マルチホップアドホックネットワークのためのプロトコル | |
| JP2005252900A (ja) | 通信システム、同システムにおけるアドレス重複検出方法、アドホックノード、プログラム | |
| US7904506B2 (en) | Context information management system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040528 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040528 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20060415 |
|
| RD05 | Notification of revocation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7425 Effective date: 20070626 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070807 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071009 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071106 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080107 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080228 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080307 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110314 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120314 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130314 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140314 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |