JP3935986B2 - ネットワークにおける情報資源の変化を通知するネットワーク情報資源監視システム - Google Patents
ネットワークにおける情報資源の変化を通知するネットワーク情報資源監視システム Download PDFInfo
- Publication number
- JP3935986B2 JP3935986B2 JP33968795A JP33968795A JP3935986B2 JP 3935986 B2 JP3935986 B2 JP 3935986B2 JP 33968795 A JP33968795 A JP 33968795A JP 33968795 A JP33968795 A JP 33968795A JP 3935986 B2 JP3935986 B2 JP 3935986B2
- Authority
- JP
- Japan
- Prior art keywords
- monitoring
- notification
- url
- destination url
- network
- 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/04—Network management architectures or arrangements
- H04L41/046—Network management architectures or arrangements comprising network management agents or mobile agents therefor
-
- 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/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
- H04L43/106—Active monitoring, e.g. heartbeat, ping or trace-route using time related information in packets, e.g. by adding timestamps
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/12—Network monitoring probes
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Human Computer Interaction (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、複数の情報資源が接続された通信ネットワークに係り、ネットワーク上の情報資源の変化を監視するネットワーク資源監視システムおよびその方法に関する。
【０００２】
【従来の技術】
近年、低コストで情報発信が可能な通信ネットワークであるインターネットのユーザ数が世界的な規模で増大している。このインターネットフィーバにより、通信ネットワークは発信者が発信する膨大な量の情報で溢れている。このような情報の供給過剰は、サイバーグラト（cyberglut ）と呼ばれる。サイバーグラトの状況下で情報を受信するユーザは、ネットワーク上で好みの情報を見つけ出すために非常な苦労を強いられている。
【０００３】
一方、情報の発信者は、自分の情報に興味を持ってくれそうなユーザを探し出して、それを伝えたいという欲求を持っている。そのために、雑誌、広告などの他のメディアを利用したり、電子出版システムを用いて契約者に情報を送ったりしている。
【０００４】
【発明が解決しようとする課題】
上述のようなインターネットのユーザにとって、従来より次のような問題がある。
【０００５】
現状のネットワーク上では、ユーザが希望する情報を効率的に探し出す手段が提供されておらず、発信者がただ漫然と情報を流し続けることが多い。また、もし発信者が情報を変更したとしても、ユーザはその資源に再アクセスしない限り、変更に気付かない。このため、情報が一方的に流される傾向が強く、マルチメディアの特色といわれる双方向性にやや欠けている。
【０００６】
また、受信者は必要とする情報資源に定期的にアクセスして、変化したかどうかをチェックする必要があり、通信コストが増大するという問題がある。特に、ネットワーク的に遠い資源を利用する場合、この傾向は著しい。これではネットワークの容量を無駄使いしており、場合によってはネットワークのスループットが下がったり、接続の弱いサイトでは実質上通信不能になる可能性も出てくる。
【０００７】
もし、何等かの方法でユーザが既知の情報資源の変更を知ることができれば、チェックのために何度も再アクセスする手間が省ける。したがって、新しい情報発掘のために多くの時間をさくことができるという大きなメリットがある。しかし、従来は、受信者側の立場に立ったこのような変更通知サービスは存在しない。
【０００８】
本発明は、通信ネットワーク上の情報の変化をユーザに代わって監視することによりユーザのアクセス回数を削減し、ネットワークの負荷を低減することの可能なネットワーク資源監視システムおよびその方法を提供することを目的とする。
【０００９】
【課題を解決するための手段】
図１は、本発明のネットワーク資源監視システムの原理図である。図１のネットワーク資源監視システムは、監視手段１、出力手段２、通知手段３、および管理手段４を備え、通信ネットワーク５上の情報資源６を監視する。
【００１０】
監視手段１は、ユーザからの依頼に基づいて、通信ネットワーク５上の資源６の状態を監視する。
そして、出力手段２は、資源６の状態に変化があったことを示す変化情報を出力する。
【００１１】
資源６は、例えばインターネット上のホームページのように、発信者が作成して発信する画像情報やテキスト情報等であり、発信者により更新されることがある。通信ネットワーク５上のどの資源を監視対象とするかは、ユーザにより依頼時に指定される。ユーザからの監視依頼は、例えば管理手段４から監視手段１に送られる。
【００１２】
監視手段１は、例えば定期的に資源６にアクセスしてその状態を調べ、更新されたことが分かると、資源６の状態が変化したことを出力手段２に伝える。これを受けて、出力手段２は、資源６の識別情報等を含む変化情報を通信ネットワーク５に出力する。
【００１３】
この変化情報は、通信ネットワーク５を介して例えば通知手段３に送られ、最終的にユーザに通知される。これにより、ユーザは指定した資源６の情報が更新されたことを知ることができる。
【００１４】
この構成によれば、監視手段１がユーザに代わって資源６を監視するので、ユーザが自ら資源６にアクセスする必要がなくなる。したがって、資源６へのユーザのアクセス回数を最小限に抑えることが可能になる。監視手段１は、１人のユーザの代理を果たすだけでなく、複数のユーザを代表して資源６を監視することもできる。
【００１５】
また、監視手段１および出力手段２を通信ネットワーク５上で資源６に近い場所に配置すれば、監視に伴う通信コストが低く抑えられるため、ネットワークの負荷を低減することも可能になる。
【００１６】
また、管理手段４は、通信ネットワーク５上の資源６の状態の監視を依頼する監視依頼をユーザから受け取り、資源６の状態に変化があった時の通知先を管理する。
【００１７】
そして、通知手段３は、資源６の状態に変化があったことを示す変化情報を、上記通知先に通知する。
ユーザからの監視依頼は、例えば監視対象の資源６を指定する識別情報と、変化情報の通知先とを含んでおり、通信ネットワーク５を介して管理手段４に送られる。監視依頼の送信には電子メール等が用いられ、通知先としてはユーザの電子メールアドレス等が指定される。
【００１８】
管理手段４は、例えばデータベース等の記憶装置に、資源６の識別情報と通知先とを対応付けて格納しておく。通知手段３は、通信ネットワーク５から変化情報を受け取ると、変化のあった資源６に対応する通知先を管理手段４に問い合せ、その通知先に変化情報を送る。
【００１９】
通知先がユーザの電子メールアドレスの場合は、資源６の識別情報を含むメールがユーザの端末に送られる。これにより、ユーザは指定した資源６の情報が更新されたことを知る。
【００２０】
この構成によれば、管理手段４が変化情報の通知先を管理するので、資源６が更新されたことが自動的にユーザに通知される。このため、ユーザは自ら資源６にアクセスする必要がなくなり、資源６へのユーザのアクセス回数を最小限に抑えることが可能になる。また、資源６の監視を依頼したユーザが複数いる場合は、それらのすべてのユーザに変化情報が通知される。
【００２１】
図１の構成において、監視手段１および出力手段２を通信ネットワーク５上で資源６に近い場所に配置し、通知手段３および管理手段４をユーザの端末に近い場所に配置すれば、監視に伴う通信コストとユーザとの通信コストをともに低く抑えることができる。したがって、ネットワークの負荷が低減される。
【００２２】
例えば、図１の監視手段１と出力手段２は、実施形態の図２におけるＵＲＬ監視システム１３に対応し、通知手段３と管理手段４は通知手段管理システム１２に対応する。
【００２３】
【発明の実施の形態】
以下、図面を参照しながら本発明の実施の形態を詳細に説明する。
今日、インターネットへのアクセス方法は様々である。これらの様々なアクセス方法には、流行中のインターネット情報探索ツールであるＷＷＷブラウザ（world wide web browser）、Ｅ−ｍａｉｌによる方法、ＰＤＡ（Personal Digial Assistant ：新個人情報端末）による方法などがある。ＰＤＡは、マイクロコンピュータ、ディスプレイ、ペン入力機能、および通信機能を合わせ持つ小型の携帯情報端末である。
【００２４】
しかし、各アクセス方法の性格は大きく異なっており、それぞれが特徴的な形態を有するので、それらの情報収集能力は一様ではない。例えば、ＷＥＢブラウザは、ハイパーテキスト風の構成で文書間のリンクをたどることで、ネットワーク上の情報資源にアクセスできる点が特徴である。
【００２５】
こうした多様なアクセス方法でアクセスしてくるユーザに対して、資源の変化を通知するサービスを提供することを考える。この場合、サービスプロバイダに資源の監視を依頼するための監視要求の出し方、およびプロバイダからの変更通知の出し方は、ユーザのアクセス方法によって異なる。したがって、このサービスに対するユーザのニーズは多様である。
【００２６】
上述のようにアクセス方法は多様であるが、幸いネットワーク上の資源を統一的に表現する識別情報としてＵＲＬ（uniform resource locator）がある。そこで、以下の実施形態においては、資源の存在場所をＵＲＬにより一般化して表現し、監視要求の出し方および更新情報（変化情報）の受信方法と分離する。これにより、多様な通信手段に個別に対応する場合に予想されるプロトコルの乱立を防ぐことができる。さらに、新たに導入される他の通信手段に対応するのが容易になる。
【００２７】
図２は、このようなネットワーク資源監視システムの構成図である。図２のネットワーク資源監視システムは、監視要求入力インタフェース１０、通知インタフェース１１、通知手段管理システム１２、およびＵＲＬ監視システム１３を備える。そして、ユーザから指定された特定のＵＲＬの資源を監視し、その変化をユーザに通知する。監視要求入力インタフェース１０および通知インタフェース１１としては、例えば、ＷＥＢブラウザ端末、Ｅ−ｍａｉｌ端末、ＰＤＡなどが用いられる。
【００２８】
監視要求入力インタフェース１０は、ユーザから入力された監視対象のＵＲＬと通知手段とを、監視要求とともに通知手段管理システム１２に伝える。通知手段管理システム１２は、例えばインターネットへの接続サービスを行うプロバイダのサーバであり、監視要求をＵＲＬ監視システム１３に伝える。ＵＲＬ監視システム１３は指定されたＵＲＬの資源１４の状態を監視し、それが変化した時直ちに、その情報を通知手段管理システム１２に知らせる。
【００２９】
通知手段管理システム１２は、通知インタフェース１１に対して監視結果を通知する通知手段を管理しており、ＵＲＬ監視システム１３から受け取った情報を、対応する通知手段により通知インタフェース１１に通知する。これにより、ユーザは資源１４の状態に変化があったことを知り、その資源１４にアクセスして変化した情報を得ることができる。
【００３０】
図２のネットワーク資源監視システムにおいて、ＵＲＬ監視システム１３はＵＲＬで一般化された世界に属し、システムのバックボーンとして動作する。そして、通知手段管理システム１２は、インタフェース依存性のある世界と一般化された世界の境界上に位置し、バックボーンからの更新情報を元にした監視サービスを展開することが可能である。各サービスプロバイダはバックボーンのプロトコルを公開し、ユーザに対する各通知手段をサポートした監視サービスを展開する。
【００３１】
図３は、通知手段管理システム１２およびＵＲＬ監視システム１３の一例として用いられる情報処理装置の構成図である。図３の情報処理装置は、ＣＰＵ（中央処理装置）１５、メモリ１６、通信部１８、データベース２０、およびそれらを結ぶバス１９を有し、通信部１８を介して通信ネットワーク１７に接続されている。
【００３２】
ＣＰＵ１５はメモリ１６を利用して、監視サービスを提供するために必要なプロセスを生成し、データベース２０のデータを参照しながら処理を行う。通信部１８は、通信ネットワーク１７との間で情報の送受信を行う。
【００３３】
このような監視サービスを利用して、ユーザの管理するＦＴＰ（file transfer protocol）サイトのメンテナンスをしようとした場合、変更があったことを知るだけでなく、物理的なファイルの転送および削除などのアクションをとることができれば便利なことがある。
【００３４】
そこで、プロバイダに能力があれば、例えばＦＴＰサイト管理デーモンなどのプロセスを通知手段管理システム１２内に作成し、ＦＴＰサイトのファイルの管理を行わせる。これにより、監視サービスがオープンワールドでも受け入れられていく可能性がある。このＦＴＰサイトのファイル操作については、後述することにする。
【００３５】
ところで、資源１４の監視においては、それを定期的にアクセスすることが必要なため、通信のためのコストが非常に高くなることが予想される。前述したように、この傾向は、ネットワーク的に遠い資源の監視をする場合に特に顕著となる。したがって、世界的な規模を持つインターネットの場合、ネットワークの負荷が著しく増大する可能性がある。
【００３６】
そこで、ＵＲＬを監視するバックボーンでは、デリゲーション（delegation）を有効に使うことを考える。デリゲーションは、インターネットに接続された個々のネットワークを保護するためのアクセス制限であるファイアウォールの構築でよく使われた手法である。
【００３７】
多くの場合、ローカルネットワークはゲートウェイを介してインターネットに接続され、ゲートウェイに収容された処理装置が外部からのアクセスを制限する。この場合、ゲートウェイの処理装置は、ローカルネットワーク内の各情報処理装置を代表して、外部からのアクセスを制御している。このような手法がデリゲーションと呼ばれる。
【００３８】
以下の実施形態では、このデリゲーションをネットワーク負荷の低減のために転用し、ＵＲＬ監視システム１３をデリゲーション・バックボーンとする。ＵＲＬ監視システム１３は、個々のユーザを代表して資源１４を監視する機能を持つ。これにより、各ユーザが資源１４をチェックするために頻繁にアクセスする必要がなくなり、ネットワーク負荷を減少させることができる。
【００３９】
このようなデリゲーションシステムは、監視資源をＵＲＬで一般化したことによって、より現実的なものになる。もし一般化されていなければ、多様なプロトコルで管理された資源に応じて、多数のデリゲーションシステムを用意しなければならなくなるが、ＵＲＬで監視する場合は、１つのデリゲーションシステムで対応可能である。
【００４０】
また、図２のネットワーク資源監視システム内における情報の伝達は任意の通信処理により実現可能であるが、本実施形態では、一例としてリモートプログラミングに基づく言語であるテレスクリプト（Telescript）による方法を用いることにする。
【００４１】
テレスクリプトによるリモートプログラミングにおいては、データを保持するプロセスの一種であるエージェント（Agent ）が用いられる。この場合には、各ユーザの監視要求情報を各エージェントに持たせることが可能であるため、複数のユーザの要求を独立に処理することができる。さらに、エージェントは自律的に機能して、処理が終了すれば自動的に消滅するため、不特定多数のユーザが利用するネットワーク上の処理に適している。
【００４２】
テレスクリプトによるリモートプログラミングについては、「リモートプログラミングの実施方法」（特願平６−１７９７６７、特開平７−１８２１７４）に詳述されているが、ここでその手法について説明する。
【００４３】
このリモートプログラミングは、複数の計算機システムを結ぶ通信ネットワーク上での処理を記述する方法の一種で、ネットワークを渡り歩く移動可能なプロセスであるエージェントと、エージェントが入ってくる固定プロセスであるプレイス（Place ）により実現される。
【００４４】
図４は、プレイスの構成を示している。プレイスは、他のプロセスと識別可能なテレネーム（telename）を持ち、任意有限個の子プロセスを持つことができる。また、プレイスは、自己および他のプロセスより参照可能な任意有限個のデータと、自己および他のプロセスより呼出し可能な任意有限個の手続きとを有する。
【００４５】
さらに、メインルーチンとして手続きliveを持ち、作成されたプレイスはｌｉｖｅを実行する。プレイスは、ｌｉｖｅが実行されている間だけ存在し、ｌｉｖｅが終了すると消滅する。プレイスが消滅すると、その子プロセスも終了し、消滅する。
【００４６】
図５は、エージェントの構成を示している。エージェントは、他のプロセスと識別可能なテレネームを持ち、あるプレイスの中の子プロセスとしてのみ存在する。また、エージェントは、自己および他のプロセスより参照可能な任意有限個のデータと、自己および他のプロセスより呼出し可能な任意有限個の手続きとを有する。
【００４７】
さらに、メインルーチンとして手続きｌｉｖｅを持ち、作成されたエージェントはｌｉｖｅを実行する。エージェントは、ｌｉｖｅが実行されている間だけ存在し、ｌｉｖｅが終了すると消滅する。エージェントの手続きｌｉｖｅの中でコマンドｇｏが実行されると、そのエージェントはネットワークを介して指定された行き先へ移動する。
【００４８】
図６は、コマンドｇｏによるオペレーションの例を示している。図６において、プレイス２１内のエージェント２２は、ｇｏの実行により、行き先のプレイス２４を指定するデータであるチケット（Ticket）２３を得て、指定されたプレイス２４に移動する。
【００４９】
このとき、エージェント２２は、ｇｏによりｌｉｖｅの実行を一時中断し、保持したデータとともに凍結（圧縮）され、パック化される。そして、チケット２３に示されたプレイス２４に送られ、プレイス２４により受け入れをチェックされる。プレイス２４に受け入れられると、その中に子プロセスとして置かれた後、解凍（伸張）され、ｇｏの次のコマンドからｌｉｖｅの実行を再開する。
【００５０】
また、エージェントは、手続きｌｉｖｅの中で自己の置かれているプレイス内にある他のエージェントを求めるコマンドｍｅｅｔを呼出すことができる。コマンドｍｅｅｔの実行時には、エージェントは相手のエージェントを指定するデータであるペティション（Petition）を用いる。
【００５１】
図７は、コマンドｍｅｅｔによるオペレーションの例を示している。図７において、プレイス３１内のエージェント３２は、コマンドｍｅｅｔによりあるペティションを指定する。プレイス３１は、ペティションにより指定された条件に該当するエージェントを探す。そして、プレイス３１内に該当するエージェントがなければ、そのようなエージェントが入ってくるまで待つ。
【００５２】
プレイス３１内のエージェント３３がペティションの条件に該当すれば、プレイス３１は、エージェント３２が相互作用を希望していることをエージェント３３に伝える。そして、エージェント３３がエージェント３２の希望を受け入れる旨の戻り値を返すと、プレイス３１は、エージェント３３へのポインタをｍｅｅｔの戻り値としてエージェント３２に返す。その後、エージェント３２は、エージェント３３へ直接アクセスして、情報交換等を行うことが可能になる。
【００５３】
以下では、コマンドｇｏによりエージェントが移動することを単に「ｇｏする」と記述し、コマンドｍｅｅｔにより他のエージェントと相互作用を行うことを単に「ｍｅｅｔする」と記述する。
【００５４】
図８は、上述のようなリモートプログラミングを用いたネットワーク資源監視システムの構成図である。図８において、監視サービスプレイス４６とデリゲートプレイス（delegate place）５１は、それぞれ決められた機能を有するプレイスであり、フォームエージェント（form agent）４８、監視エージェント５３、通知エージェント５４、５４′、リポートエージェント５５、５６、５７、５８は、それぞれ決められたデータと機能を有するエージェントである。
【００５５】
Magic Cap ４１、ＭＵＡ（Mail User Agent ）４２、およびＷＥＢブラウザ４３は、図２の監視要求入力インタフェース１０に対応し、ユーザが監視要求を入力する際に用いる。これらの具体的な違いについては後述する。通知手段管理システム１２は、例えばプロバイダ毎に設けられ、監視データベース（ＤＢ）４７を備え、ユーザに監視サービスを提供する監視サービスプレイス４６を保持する。
【００５６】
また、ＵＲＬ監視システム１３は、デリゲートデータベース（ＤＢ）５２を備え、ユーザに代わって資源を監視するためのデリゲートプレイス５１を保持する。監視に伴う通信コストの低減を図るため、このＵＲＬ監視システム１３は通信的に近いＵＲＬのグループ毎に設けられる。通信的に近いＵＲＬとは、比較的低い通信コストでアクセス可能なＵＲＬを意味する。例えば、インターネットに接続する各国毎に１つのＵＲＬ監視システム１３を設けてもよく、よりローカルな地域のサーバ毎に設けてもよい。
【００５７】
通知手段管理システム１２とＵＲＬ監視システム１３は通信ネットワーク４９を介して接続され、情報交換を行うことができる。また、通信ネットワーク４９にはＵＲＬで識別される資源５０−１、５０−２、５０−３も接続されている。尚、接続される資源の数は任意である。以下では、このような資源のことを単に“ＵＲＬ”と記述することもある。
【００５８】
監視要求が監視要求入力インタフェース１０に入力されると、監視サービスプレイス４６内にフォームエージェント４８が現れる。フォームエージェント４８は監視ＤＢ４７を更新した後、通信ネットワーク４９を介してデリゲートプレイス５１にｇｏし、デリゲートＤＢ５２を更新する。監視ＤＢ４７には、監視結果の通知先であるユーザのＵＲＬが格納され、デリゲートＤＢ５２には、通知先の監視サービスプレイス４６のアドレス情報が格納される。
【００５９】
監視エージェント５３は、デリゲートＤＢ５２を参照して監視先ＵＲＬを監視し、それが更新されると通知エージェント５４を作成する。通知エージェント５４はコマンドｓｅｎｄを実行して、通知エージェント５４′を監視サービスプレイス４６に送る。
【００６０】
ｓｅｎｄは、エージェントの手続きｌｉｖｅの中で実行され、そのエージェントの複製を作って他のプレイスに送るコマンドである。ここでは、通知エージェント５４′は、通知エージェント５４の分身（クローンエージェント）として生成される。
【００６１】
通知エージェント５４′は、監視ＤＢ４７の通知先ＵＲＬに応じて、適したリポートエージェント５５、５６、５７、５８を作成する。リポートエージェント５５、５６、５７、５８は、それぞれの通知インタフェース１１の種類に応じた通知手段でユーザに結果を報告する。これらのリポートエージェントの処理の詳細については後述する。
【００６２】
以上の構成により、ユーザは更新された監視先ＵＲＬの情報を自動的に通知されるので、ユーザ自身が資源のチェックを行う必要はなくなる。また、通知手段管理システム１２とＵＲＬ監視システム１３が分離して設けられ、監視先に近いＵＲＬ監視システム１３が複数のユーザを代表して、ＵＲＬを監視する。
【００６３】
したがって、多数のユーザによる資源監視のための頻繁なアクセスをなくして、ネットワークの負荷を大幅に軽減することができる。
次に、図９から図１４までを参照しながら、図８のネットワーク資源監視システムにおける具体的な処理について説明する。
【００６４】
ネットワーク資源監視システムに対する監視要求の発行は、各種のデバイスおよびプログラムから行うことができる。例えば、図８におけるＷＥＢブラウザ４３はハイパーテキストベースでインターネット上に分散配置された情報を探索するソフトウェアツールであり、ＭＵＡ４２はＥ−ｍａｉｌを発行するソフトウェアツールである。また、Magic Cap ４１はエージェントを利用したＰＤＡ端末の一種である。ＷＥＢブラウザ４３およびＭＵＡ４２は、ユーザの端末計算機内に収容されている。
【００６５】
監視要求の出し方は、勿論、各デバイスおよびプログラムの種類によって異なるが、次の２つの条件を満たす必要がある。
（１）何等かの方法で、フォームエージェント４８を監視サービスプレイス４６上に作成すること。
（２）フォームエージェント４８には、次のデータを与えること。
【００６６】
・監視先ＵＲＬ
・通知先ＵＲＬ
・依頼主ＩＤ、パスワード
・コメント
・備考データ
監視先ＵＲＬは監視対象の資源のＵＲＬであり、通知先ＵＲＬは監視結果を通知するＵＲＬであり、依頼主ＩＤおよびパスワードは依頼主の識別情報である。通知先ＵＲＬは、通常、依頼主ＩＤ毎に割り振られる。また、コメントと備考データは必ずしも必須ではなく、必要に応じて付加される。
【００６７】
このように、監視入力インタフェースの形態に依らないフォームエージェント４８を作成することで、各種のプログラム等による監視要求を受け付けることが可能になり、システムの拡張性が高まる。
【００６８】
次に、監視要求の入力例について説明する。入力機器としては、マウス等のポインティングデバイスやキーボードが用いられる。ＷＥＢブラウザ４３を用いる場合、ユーザはまず監視依頼フォーム（Form）のＨＴＭＬ（hypertext markup language ）文書をｏｐｅｎし、そのフォームの空欄の穴うめをする。ＨＴＭＬとは他文書へのリンクを持つハイパーテキスト文書を記述する言語で、これにより記述された文書はＨＴＭＬ文書と呼ばれる。
【００６９】
図９は、ユーザ端末のディスプレイ上に表示された監視依頼フォームの入力例を示している。図９の監視依頼フォーム７０において、ｌｏｏｋ ＵＲＬ７１は監視先ＵＲＬを表し、Ｒｅｐｏｒｔ ＵＲＬ７２は通知先ＵＲＬを表し、ＩＤ７３およびＰａｓｓｗｄ７４は、それぞれ依頼主ＩＤおよびパスワードを表す。これらの情報を入力した後、Ｃｏｎｆｉｒｍボタン７５をクリックすると、図８のＣＧＩ（ common gateway interface ）プロセス４５が起動される。
【００７０】
ＣＧＩプロセス４５は、ＩＤ７３毎に決まったＨＴＭＬ文書７６をｏｐｅｎする。ＨＴＭＬ文書７６は、指定された監視対象の資源へのリンク（ＵＲＬ）のリストを表示するために用いられる。ここでは、指定された監視先ＵＲＬがＨＴＭＬ文書７６内にリンクとして書き込まれ、リンクのリストがディスプレイに表示される。
【００７１】
次に、ＣＧＩプロセス４５は、クラウド（cloud ）との間にコネクションを確立する。クラウドとは、ネットワーク上でプログラム言語を解釈して実行するためのソフトウェア環境を表し、ここでは監視サービスプレイス４６に相当する。ＣＧＩプロセス４５は、確立されたコネクションを通じてプロセス間通信を行い、監視依頼フォーム７０に入力されたパラメータを監視サービスプレイス４６へ送る。
【００７２】
そして、監視サービスプレイス４６は、送られたパラメータを元にフォームエージェント４８を作成する。
また、監視要求入力インタフェース１０としてＭＵＡ４２を用いる場合は、ユーザは一定のフォーマットのＥ−ｍａｉｌ（コントロールメール：control mail）４４を監視サービスプレイス４６宛に送る。
【００７３】
図１０は、ＭＵＡ４２により作成されるコントロールメール４４の例を示している。コントロールメール４４には、監視依頼フォーム７０と同様に、ｌｏｏｋＵＲＬ（監視先ＵＲＬ）、Ｒｅｐｏｒｔ ＵＲＬ（通知先ＵＲＬ）、ＩＤ、Ｐａｓｓｗｏｒｄ等の情報が記述される。
【００７４】
監視サービスプレイス４６は、通知手段管理システム１２内に設けられたsendmailポートで通信をlistenしており、sendmailのプロトコルを認識することができる。そして、送られてきたコントロールメール４４を受信し、それをパース（parse ）して、メールの構成要素を分析する。次に、その結果を元にフォームエージェント４８を作成する。
【００７５】
また、監視要求入力インタフェース１０としてMagic Cap ４１を用いる場合は、ユーザは専用のフォームでマジックメール（Magicmail ）を作成し、監視サービスプレイス４６へ送信する。マジックメールとは、メールの内容をデータとして持つエージェントが他の計算機等に移動することで、メッセージを伝えるメールの形態を指す。
【００７６】
ここでは、マジックメールの送信処理により、Magic Cap ４１上で、監視先ＵＲＬ、通知先ＵＲＬ、依頼主ＩＤ、パスワード等のデータを持つフォームエージェント４８が生成される。そして、直接監視サービスプレイス４６へｇｏする。
【００７７】
次に、このようにして作成されたフォームエージェント４８が行う処理を説明する。フォームエージェント４８は、監視ＤＢ４７に通知先ＵＲＬを登録し、デリゲートＤＢ５２に通知先プレイスのアドレスを登録して、結果を通知する際の経路を通知エージェント５４、５４′に伝える役割を果たす。このため、フォームエージェント４８は、監視ＤＢ４７とデリゲートＤＢ５２にレコードを追加したり、それらのレコードを変更したりする機能を持つ。
【００７８】
図１１は、監視ＤＢ４７のデータ構造の例を示している。図１１において、ハッシュ表８１には、キー（key ）として用いられる監視先ＵＲＬ毎にレコードを指すポインタが格納されている。例えば、１番目の監視先ＵＲＬ“ｈｔｔｐ：／／〜”に対応するポインタはレコード８２−１を指しており、２番目の“ｆｔｐ：／／〜”に対応するポインタはレコード８２−２を指している。監視先ＵＲＬの中で、“ｈｔｔｐ：”や“ｆｔｐ：”は接続形態を表すプロトコル部に相当する。
【００７９】
レコード８２−１および８２−２は、Ｔａｒｇｅｔ１、Ｔａｒｇｅｔ２、Ｔａｒｇｅｔ３の３つのエントリを持ち、これらのエントリはそれぞれ、最終更新履歴、通知先ＵＲＬのリストへのポインタ、備考データを表す。
【００８０】
最終更新履歴は、監視先ＵＲＬの最終更新日時のタイムスタンプと更新後の情報のファイルサイズを含む。Ｔａｒｇｅｔ２のポインタが指すＵＲＬのリストの最後の（ｎｉｌ）は空白データを表し、リストの終端であることを示している。フォームエージェント４８が備考データを持っている場合、それはＴａｒｇｅｔ３として格納される。
【００８１】
通知エージェント５４′は、この監視ＤＢ４７から監視先ＵＲＬをキーとして、監視先ＵＲＬの最終更新のタイムスタンプとファイルサイズ、および通知先ＵＲＬのリストを引くことができる。
【００８２】
フォームエージェント４８は、持っている監視先ＵＲＬがハッシュ表８１の中にないとき、それをハッシュ表８１のエントリとして追加し、対応するレコードを登録する。このとき、タイムスタンプとしては登録時の日時を用い、ファイルサイズは０としておく。また、通知先ＵＲＬリストにはフォームエージェント４８が持つ通知先ＵＲＬを登録する。
【００８３】
フォームエージェント４８の監視先ＵＲＬがハッシュ表８１の中にキーとして存在するときは、対応するレコードのエントリを変更する。ただし、タイムスタンプとファイルサイズは変更せず、通知先ＵＲＬリストにフォームエージェント４８の通知先ＵＲＬを追加する。
【００８４】
その後、フォームエージェント４８はデリゲートプレイス５１へｇｏして、デリゲートＤＢ５２にレコードを追加したり、またはレコードを変更したりする。
図１２は、デリゲートＤＢ５２のデータ構造の例を示している。図１２において、ハッシュ表９１にはハッシュ表８１と同様に、監視先ＵＲＬ毎にポインタが格納されている。例えば、１番目の監視先ＵＲＬ“ｈｔｔｐ：／／〜”に対応するポインタはレコード９２−１を指しており、２番目の“ｆｔｐ：／／〜”に対応するポインタはレコード９２−２を指している。
【００８５】
レコード９２−１および９２−２は、Ｔａｒｇｅｔ１、Ｔａｒｇｅｔ２、Ｔａｒｇｅｔ３の３つのエントリを持ち、Ｔａｒｇｅｔ１とＴａｒｇｅｔ２の内容は図１１の場合と同様である。
【００８６】
Ｔａｒｇｅｔ２は通知先リストへのポインタを表し、各通知先としてはフォームエージェント４８を送り出した監視サービスプレイス４６のＴｅｌｅａｄｄｒｅｓｓとＷａｙが用いられる。ここで、Ｔｅｌｅａｄｄｒｅｓｓはプレイスを一意に識別する識別子であり、Ｗａｙはそのプレイスまでの移動方法を表す。これらの情報は、フォームエージェント４８のｇｏの返り値であるＴｉｃｋｅｔＳｔｕｂに記述されている。
【００８７】
通知エージェント５４は、このデリゲートＤＢ５２から監視先ＵＲＬをキーとして、監視先ＵＲＬの最終更新のタイムスタンプとファイルサイズ、および通知先監視サービスプレイス４６のアドレスリストを引くことができる。
【００８８】
また、デリゲートＤＢ５２は、フォームエージェント４８により監視ＤＢ４７と同様のレコードの追加、変更を受ける。ただし、通知先としては、通知先ＵＲＬではなく、フォームエージェント４８のＴｉｃｋｅｔＳｔｕｂの情報が用いられる。
【００８９】
監視サービスプレイス４６は、監視要求の出し方および通知の方法から資源の監視方法を分離し、ＵＲＬで表現できる資源の監視という形態に一般化する役割を果たす。これにより、多様なユーザインタフェースを持つ複数のユーザを代表してＵＲＬを監視するサービスを提供することが可能になる。
【００９０】
デリゲートプレイス５１は、監視先ＵＲＬの更新履歴をチェックして、その変化を監視するために設けられる。ユーザに対する通知方法等は、監視サービスプレイス４６により隠蔽されているので、デリゲートプレイス５１が関知する必要はない。
【００９１】
監視エージェント５３はデリゲートプレイス５１内にあって、ＦＴＰプロトコルにより、デリゲートＤＢ５２内の監視先ＵＲＬのタイムスタンプおよびファイルサイズを定期的にチェックする。
【００９２】
図１３は、監視エージェント５３が行う監視処理のフローチャートである。図１３において処理が開始されると、監視エージェント５３はループ処理を開始し（ステップＳ１）、デリゲートＤＢ５２のハッシュ表９１を用いて、次の監視先ＵＲＬに対応するレコードを取得する（ステップＳ２）。
【００９３】
次に、取得したレコードのキーである監視先ＵＲＬへＦＴＰプロトコルによりconnect する（ステップＳ３）。そして、監視先ＵＲＬのタイムスタンプとファイルサイズを取得し（ステップＳ４）、それらをデリゲートＤＢ５２のレコードの対応するエントリと比較する（ステップＳ５）。ここで、監視先ＵＲＬのタイムスタンプやファイルサイズに変化があるかどうかが調べられる。
【００９４】
両者のタイムスタンプやファイルサイズが異なり、監視先ＵＲＬに変更があると判断できる場合、通知エージェント５４をデリゲートプレイス５１上に作成し、デリゲートＤＢ５２のレコードを初期化引数として通知エージェント５４に渡す（ステップＳ６）。
【００９５】
次に、ループ処理を終了するかどうか判定する（ステップＳ７）。この判定は、あらかじめ決められた適当な終了条件が成立するかどうかをチェックすることにより行われる。通常は終了条件が成立することはないので、ステップＳ２以降の処理を半永久的に繰り返す。また、ステップＳ５において監視先ＵＲＬに変更なしと判断できる場合も、ステップＳ２以降の処理を繰り返す。そして、ステップＳ７において終了条件が成立すれば、処理を終了する。
【００９６】
図１３の監視処理においては、監視先ＵＲＬへＦＴＰ接続して更新情報（更新履歴）を取得する構成となっている。これ以外に、監視先ＵＲＬの管理者が更新情報を持たせた更新（Update）エージェントをデリゲートプレイス５１に送る方法を用いることもできる。この場合は、更新エージェントがデリゲートプレイス５１内で監視エージェント５３にｍｅｅｔし、更新情報を伝える。これにより、監視エージェント５３は、より積極的に監視先ＵＲＬから発信された更新情報を受け付けることになる。
【００９７】
監視処理においては、その性質上何等かの方法で監視先ＵＲＬの更新情報を取得する必要があるので、監視先ＵＲＬとの定期的な通信が必要になる。このため、デリゲートプレイス５１からネットワーク的に近い所だけを監視対象にした方が効率がよい。
【００９８】
デリゲートプレイス５１から遠い所を監視する場合は、監視先ＵＲＬの近くに、デリゲートプレイス５１等を代表する別のデリゲートプレイスを設けて、それに監視させることも考えられる。つまり、デリゲートのデリゲートを設けることになる。
【００９９】
監視エージェント５３により作成された通知エージェント５４は、更新されたＵＲＬについて、デリゲートＤＢ５２および監視ＤＢ４７のレコードを変更する。
【０１００】
図１４は、通知エージェント５４の処理のフローチャートである。図１４において処理が開始されると、通知エージェント５４は、まず初期化引数として渡されたデリゲートＤＢ５２のレコードのタイムスタンプとファイルサイズを、監視先ＵＲＬのものに更新する（ステップＳ１１）。
【０１０１】
次に、対応する通知先リストに格納されたＴｅｌｅａｄｄｒｅｓｓとＷａｙを用いてコマンドｓｅｎｄを実行し、各監視サービスプレイスに分身の通知エージェント５４′を送る（ステップＳ１２）。
【０１０２】
通知エージェント５４′は最新の更新履歴のデータを持っており、例えば監視サービスプレイス４６に移動する。そして、監視ＤＢ４７内の対応するレコードのタイムスタンプとファイルサイズを最新のものに更新する（ステップＳ１３）。
【０１０３】
次に、そのレコードの通知先ＵＲＬリストを参照し、各通知先ＵＲＬに適したリポートエージェントを作成し（ステップＳ１４）、処理を終了する。リポートエージェントのクラスは、通知の方法、すなわちＵＲＬに含まれるプロトコル部毎に異なっており、例えば次のようなものがある。ここで、クラスとはオブジェクトの構造の定義に相当する。
（ａ）プロトコル部が“ｍａｉｌｔｏ：”の場合は、そのクラスはＥ−ｍａｉｌによる通知方法を定義する。
（ｂ）プロトコル部が“ｈｔｔｐ：”の場合は、そのクラスはＨＴＭＬ文書のリンクリストのページを更新して通知する方法を定義する。
（ｃ）プロトコル部が“ｆｔｐ：”の場合は、そのクラスはファイルシステムのメンテナンス方法を定義する。
【０１０４】
したがって、通知エージェント５４′は通知先ＵＲＬのプロトコル部を参照することで、作成すべきリポートエージェントのクラスを決定し、そのインスタンスを作成することができる。ここで、インスタンスとはクラスにより定義されたオブジェクトの具体例を意味し、今の場合はリポートエージェント５５、５６、５７、５８等を指す。
【０１０５】
次に、各クラスのリポートエージェントの処理について説明する。ｍａｉｌｔｏリポートエージェントは、リポートエージェント５５および５６に対応する。リポートエージェント５６は、更新のあったＵＲＬをＥ−ｍａｉｌ５９で通知先ＵＲＬに送信する。
【０１０６】
また、その発展形であるリポートエージェント５５の場合は、マジックメールをMagic Cap ４１に送る。マジックメールをＵＲＬで記述する方法はＲＦＣ（Requests For Comments ）１７３８に記載されている。このほかに、マジックメールのためのゲートウェイを通過させる方法もある。
【０１０７】
ｈｔｔｐリポートエージェントはリポートエージェント５７に対応し、通知先ＵＲＬに存在するＨＴＭＬ文書６０内のリンクリストに、更新されたＵＲＬを付け加える。
【０１０８】
このＨＴＭＬ文書６０は、例えば図９のＨＴＭＬ文書７６と同様のフォーマットを持ち、更新されたＵＲＬのリストをリンクリストとして持っている。ＨＴＭＬ文書６０のリンクリストは監視の依頼時には空白のままであるが、リポートエージェント５７により、更新のあったＵＲＬが１つずつ追加されていく。
【０１０９】
そして、端末上に表示されたリンクリスト内の１つのリンクをユーザがクリックすれば、対応するページへ飛ぶことができる。これにより、ユーザは更新された情報を実際に確認することができる。
【０１１０】
ｆｔｐリポートエージェントはリポートエージェント５８に対応し、通知先ＵＲＬにあるＦＴＰサイト６１のファイルシステムのメンテナンスを行う。リポートエージェント５８は、例えば、更新ＵＲＬのファイル名からどのアプリケーション・ソフトウェアのどのバージョンかを判断し、ＦＴＰサイト６１内の対応する古いバージョンを削除する。そして、更新ＵＲＬから新しいバージョンを取得し、ＦＴＰサイト６１内のファイルシステムに追加する。
【０１１１】
このように、リポートエージェントは更新ＵＲＬを通知するのみではなく、ファイルシステムの物理的な変更を行うこともできる。また、監視要求の入力時にユーザが通知先ＵＲＬを２つ以上指定した場合、それらのＵＲＬ毎にリポートエージェントが作成され、更新されたＵＲＬの報告をメール等で同時に行う。通知先として、ユーザのページャ（ポケットベル等）を指定することも考えられる。
【０１１２】
次に、図１５から図２０までを参照しながら、監視要求入力インタフェース１０および通知インタフェース１１としてＷＥＢブラウザ４３を用いた場合の入力処理と通知処理について説明する。
【０１１３】
以下では、ユーザが指定した監視先ＵＲＬのリストを表示するためのＨＴＭＬ文書７６が存在するＵＲＬを、指定リスト表示ＵＲＬと呼ぶことにする。また、更新された監視先ＵＲＬのリストを表示するためのＨＴＭＬ文書６０が存在するＵＲＬを、更新リスト表示ＵＲＬと呼ぶことにする。後述するように、この更新リスト表示ＵＲＬは監視ＤＢ４７の通知先ＵＲＬに一致する。
【０１１４】
図１５は新規監視依頼時の処理の概要を示しており、図１６はその処理のフローチャートである。図１５において、加入者管理データベース（ＤＢ）１０１はユーザ端末から参照可能な場所に設けられ、加入者のＩＤ毎に指定リスト表示ＵＲＬを格納している。新規監視要求の入力時には、ＣＧＩプロセス４５およびＨＴＭＬエージェント１０２が作成される。
【０１１５】
図１６において処理が開始されると、ユーザは、まず図９の監視依頼フォーム７０を穴うめし、Ｃｏｎｆｉｒｍボタン７５をクリックする（ステップＳ２１）。これにより、ＣＧＩプロセス４５が生成される（ステップＳ２２）。
【０１１６】
ＣＧＩプロセス４５は、加入者管理ＤＢ１０１から、入力されたＩＤに対応する指定リスト表示ＵＲＬを引き（ステップＳ２３）、それを初期化パラメータとしてＨＴＭＬエージェント１０２を作成する（ステップＳ２４）。
【０１１７】
ＨＴＭＬエージェント１０２は、例えば図９のＨＴＭＬ文書７６の雛形となるスケルトンデータを保持している。また、既存のＨＴＭＬ文書を解釈してリンクを抽出するオペレータと、与えられたリンクのリストをスケルトンデータにはめ込んで新たなＨＴＭＬ文書を作成するオペレータとを持つ。
【０１１８】
ＨＴＭＬエージェント１０２は、これらのオペレータを用いて指定リスト表示ＵＲＬのＨＴＭＬ文書７６を書き換える（ステップＳ２５）。これにより、新たに入力された１つ以上の監視先ＵＲＬが、リンクリストとしてＨＴＭＬ文書７６に書き込まれる。
【０１１９】
そして、ＣＧＩプロセス４５は、ユーザにＨＴＭＬ文書７６の内容を示して（ステップＳ２６）、処理を終了する。このとき、同時に監視先ＵＲＬや通知先ＵＲＬ等の入力情報が監視サービスプレイス４６に送られる。
図１７は監視資源更新時の処理の概要を示しており、図１８はその処理のフローチャートである。監視資源の更新時には、デリゲートプレイス５１から監視サービスプレイス４６へ通知エージェント５４′が送られ、更新情報が伝えられる。
【０１２０】
図１８において処理が開始されると、通知エージェント５４′はリポートエージェント５７を作成する（ステップＳ３１）。リポートエージェント５７は、その通知先ＵＲＬを更新リスト表示ＵＲＬとみなし、これを引数にしてＨＴＭＬエージェント１０２を作成する（ステップＳ３２）。
【０１２１】
ＨＴＭＬエージェント１０２は、更新リスト表示ＵＲＬに存在するＨＴＭＬ文書６０内のリンクリストに、更新のあった監視先ＵＲＬを加えて、新しいＨＴＭＬ文書６０を作成する（ステップＳ３３）。そして、処理を終了する。
【０１２２】
その後、ＨＴＭＬ文書６０の内容がユーザに示され、更新のあったＵＲＬが報告される。
図１９はユーザがＨＴＭＬ文書６０のリンクを参照したときの処理の概要を示しており、図２０はその処理のフローチャートである。リンク参照時には、ＣＧＩプロセス４５が起動され、ＨＴＭＬ文書６０が更新される。
【０１２３】
図２０において処理が開始されると、まずユーザが更新リスト表示ＵＲＬのＨＴＭＬ文書６０のリンクリストを見て、１つのリンクをクリックする（ステップＳ４１）。これにより、ＣＧＩプロセス４５が起動される。ＣＧＩプロセス４５は、更新リスト表示ＵＲＬを引数としてＨＴＭＬエージェント１０２を作成する（ステップＳ４２）。
【０１２４】
ＨＴＭＬエージェント１０２は、クリックされたリンクをリンクリストから削除し、新しいＨＴＭＬ文書６０を書き出す（ステップＳ４３）。ＣＧＩプロセス４５は、クリックされたリンクのＵＲＬに表示画面をジャンプさせて（ステップＳ４４）、処理を終了する。
【０１２５】
こうして、ユーザはリンクされたページを参照することができ、参照操作はＨＴＭＬ文書６０に反映される。
以上のようなリモートプログラミングを用いた実施形態によれば、各エージェントの自律性を利用することにより、複数のユーザの監視要求を独立に処理することができる。また、監視サービスプレイス４６とデリゲートプレイス５１を別々に設けることにより、インタフェースに依存する処理と、ＵＲＬにより一般化された監視処理とが分離される。このため、資源を近くから監視することが可能になり、効率の良いデリゲーションシステムが構築される。
【０１２６】
尚、通知手段管理システム１２が監視資源とネットワーク的に近い場所にある場合は、デリゲートプレイス５１を通知手段管理システム１２内に設けても差し支えない。その場合は、通知手段管理システム１２はＵＲＬ監視システム１３の役割をも果たすことになる。また、監視先の資源を必ずしもＵＲＬで記述する必要はなく、他の任意の識別情報を用いてもよい。
【０１２７】
また、監視要求入力インタフェース１０および通知インタフェース１１としては、図８に示されたもののみならず、任意のデバイスやプログラムを用いることができる。
【０１２８】
さらに、本発明を実施する際に、必ずしもエージェントやプレイスを用いる必要はなく、それぞれの処理を普通のプロセスにより行ってもよい。この場合は、ネットワークを介したやりとりは、例えばＲＰＣ（remote procedure call ）等により実行される。
【０１２９】
【発明の効果】
本発明によれば、通信ネットワーク上の情報資源の変化をユーザに代わって監視することが可能になり、ユーザによる情報チェックのための多数のアクセスがなくなることが期待される。したがって、ネットワークの通信負荷が大幅に低減され、ユーザは、ネットワークを他の目的のためにより多く利用することができるようになる。
【図面の簡単な説明】
【図１】本発明の原理図である。
【図２】ネットワーク資源監視システムの構成図である。
【図３】情報処理装置の構成図である。
【図４】プレイスの構成を示す図である。
【図５】エージェントの構成を示す図である。
【図６】オペレーションｇｏを示す図である。
【図７】オペレーションｍｅｅｔを示す図である。
【図８】エージェントを用いたネットワーク資源監視システムを示す図である。
【図９】監視依頼フォームの入力例を示す図である。
【図１０】コントロールメールを示す図である。
【図１１】監視データベースのデータ構造を示す図である。
【図１２】デリゲートデータベースのデータ構造を示す図である。
【図１３】監視エージェントの処理のフローチャートである。
【図１４】通知エージェントの処理のフローチャートである。
【図１５】新規依頼時の処理を示す図である。
【図１６】新規依頼時の処理のフローチャートである。
【図１７】監視資源更新時の処理を示す図である。
【図１８】監視資源更新時の処理のフローチャートである。
【図１９】リンク参照時の処理を示す図である。
【図２０】リンク参照時の処理のフローチャートである。
【符号の説明】
１ 監視手段
２ 出力手段
３ 通知手段
４ 管理手段
５，１７，４９ 通信ネットワーク
６，１４ 資源
１０ 監視要求インタフェース
１１ 通知インタフェース
１２ 通知手段管理システム
１３ ＵＲＬ監視システム
１５ ＣＰＵ
１６ メモリ
１８ 通信部
１９ バス
２０ データベース
２１，２４，３１ プレイス
２２，３２，３３ エージェント
２３ チケット
４１ Magic Cap
４２ ＭＵＡ
４３ ＷＥＢブラウザ
４４，５９ Ｅ−ｍａｉｌ
４５ ＣＧＩプロセス
４６ 監視サービスプレイス
４７ 監視データベース
４８ フォームエージェント
５０−１，５０−２，５０−３ ＵＲＬ
５１ デリゲートプレイス
５２ デリゲートデータベース
５３ 監視エージェント
５４，５４′ 通知エージェント
５５，５６，５７，５８ リポートエージェント
６０，７６ ＨＴＭＬ文書
６１ ＦＴＰサイト
７０ 監視依頼フォーム
７１ ｌｏｏｋ ＵＲＬ
７２ Ｒｅｐｏｒｔ ＵＲＬ
７３ ＩＤ
７４ Ｐａｓｓｗｄ
７５ Ｃｏｎｆｉｒｍボタン
８１，９１ ハッシュ表
８２−１，８２−２，９２−１，９２−２ レコード
１０１ 加入者管理データベース
１０２ ＨＴＭＬエージェント
【発明の属する技術分野】
本発明は、複数の情報資源が接続された通信ネットワークに係り、ネットワーク上の情報資源の変化を監視するネットワーク資源監視システムおよびその方法に関する。
【０００２】
【従来の技術】
近年、低コストで情報発信が可能な通信ネットワークであるインターネットのユーザ数が世界的な規模で増大している。このインターネットフィーバにより、通信ネットワークは発信者が発信する膨大な量の情報で溢れている。このような情報の供給過剰は、サイバーグラト（cyberglut ）と呼ばれる。サイバーグラトの状況下で情報を受信するユーザは、ネットワーク上で好みの情報を見つけ出すために非常な苦労を強いられている。
【０００３】
一方、情報の発信者は、自分の情報に興味を持ってくれそうなユーザを探し出して、それを伝えたいという欲求を持っている。そのために、雑誌、広告などの他のメディアを利用したり、電子出版システムを用いて契約者に情報を送ったりしている。
【０００４】
【発明が解決しようとする課題】
上述のようなインターネットのユーザにとって、従来より次のような問題がある。
【０００５】
現状のネットワーク上では、ユーザが希望する情報を効率的に探し出す手段が提供されておらず、発信者がただ漫然と情報を流し続けることが多い。また、もし発信者が情報を変更したとしても、ユーザはその資源に再アクセスしない限り、変更に気付かない。このため、情報が一方的に流される傾向が強く、マルチメディアの特色といわれる双方向性にやや欠けている。
【０００６】
また、受信者は必要とする情報資源に定期的にアクセスして、変化したかどうかをチェックする必要があり、通信コストが増大するという問題がある。特に、ネットワーク的に遠い資源を利用する場合、この傾向は著しい。これではネットワークの容量を無駄使いしており、場合によってはネットワークのスループットが下がったり、接続の弱いサイトでは実質上通信不能になる可能性も出てくる。
【０００７】
もし、何等かの方法でユーザが既知の情報資源の変更を知ることができれば、チェックのために何度も再アクセスする手間が省ける。したがって、新しい情報発掘のために多くの時間をさくことができるという大きなメリットがある。しかし、従来は、受信者側の立場に立ったこのような変更通知サービスは存在しない。
【０００８】
本発明は、通信ネットワーク上の情報の変化をユーザに代わって監視することによりユーザのアクセス回数を削減し、ネットワークの負荷を低減することの可能なネットワーク資源監視システムおよびその方法を提供することを目的とする。
【０００９】
【課題を解決するための手段】
図１は、本発明のネットワーク資源監視システムの原理図である。図１のネットワーク資源監視システムは、監視手段１、出力手段２、通知手段３、および管理手段４を備え、通信ネットワーク５上の情報資源６を監視する。
【００１０】
監視手段１は、ユーザからの依頼に基づいて、通信ネットワーク５上の資源６の状態を監視する。
そして、出力手段２は、資源６の状態に変化があったことを示す変化情報を出力する。
【００１１】
資源６は、例えばインターネット上のホームページのように、発信者が作成して発信する画像情報やテキスト情報等であり、発信者により更新されることがある。通信ネットワーク５上のどの資源を監視対象とするかは、ユーザにより依頼時に指定される。ユーザからの監視依頼は、例えば管理手段４から監視手段１に送られる。
【００１２】
監視手段１は、例えば定期的に資源６にアクセスしてその状態を調べ、更新されたことが分かると、資源６の状態が変化したことを出力手段２に伝える。これを受けて、出力手段２は、資源６の識別情報等を含む変化情報を通信ネットワーク５に出力する。
【００１３】
この変化情報は、通信ネットワーク５を介して例えば通知手段３に送られ、最終的にユーザに通知される。これにより、ユーザは指定した資源６の情報が更新されたことを知ることができる。
【００１４】
この構成によれば、監視手段１がユーザに代わって資源６を監視するので、ユーザが自ら資源６にアクセスする必要がなくなる。したがって、資源６へのユーザのアクセス回数を最小限に抑えることが可能になる。監視手段１は、１人のユーザの代理を果たすだけでなく、複数のユーザを代表して資源６を監視することもできる。
【００１５】
また、監視手段１および出力手段２を通信ネットワーク５上で資源６に近い場所に配置すれば、監視に伴う通信コストが低く抑えられるため、ネットワークの負荷を低減することも可能になる。
【００１６】
また、管理手段４は、通信ネットワーク５上の資源６の状態の監視を依頼する監視依頼をユーザから受け取り、資源６の状態に変化があった時の通知先を管理する。
【００１７】
そして、通知手段３は、資源６の状態に変化があったことを示す変化情報を、上記通知先に通知する。
ユーザからの監視依頼は、例えば監視対象の資源６を指定する識別情報と、変化情報の通知先とを含んでおり、通信ネットワーク５を介して管理手段４に送られる。監視依頼の送信には電子メール等が用いられ、通知先としてはユーザの電子メールアドレス等が指定される。
【００１８】
管理手段４は、例えばデータベース等の記憶装置に、資源６の識別情報と通知先とを対応付けて格納しておく。通知手段３は、通信ネットワーク５から変化情報を受け取ると、変化のあった資源６に対応する通知先を管理手段４に問い合せ、その通知先に変化情報を送る。
【００１９】
通知先がユーザの電子メールアドレスの場合は、資源６の識別情報を含むメールがユーザの端末に送られる。これにより、ユーザは指定した資源６の情報が更新されたことを知る。
【００２０】
この構成によれば、管理手段４が変化情報の通知先を管理するので、資源６が更新されたことが自動的にユーザに通知される。このため、ユーザは自ら資源６にアクセスする必要がなくなり、資源６へのユーザのアクセス回数を最小限に抑えることが可能になる。また、資源６の監視を依頼したユーザが複数いる場合は、それらのすべてのユーザに変化情報が通知される。
【００２１】
図１の構成において、監視手段１および出力手段２を通信ネットワーク５上で資源６に近い場所に配置し、通知手段３および管理手段４をユーザの端末に近い場所に配置すれば、監視に伴う通信コストとユーザとの通信コストをともに低く抑えることができる。したがって、ネットワークの負荷が低減される。
【００２２】
例えば、図１の監視手段１と出力手段２は、実施形態の図２におけるＵＲＬ監視システム１３に対応し、通知手段３と管理手段４は通知手段管理システム１２に対応する。
【００２３】
【発明の実施の形態】
以下、図面を参照しながら本発明の実施の形態を詳細に説明する。
今日、インターネットへのアクセス方法は様々である。これらの様々なアクセス方法には、流行中のインターネット情報探索ツールであるＷＷＷブラウザ（world wide web browser）、Ｅ−ｍａｉｌによる方法、ＰＤＡ（Personal Digial Assistant ：新個人情報端末）による方法などがある。ＰＤＡは、マイクロコンピュータ、ディスプレイ、ペン入力機能、および通信機能を合わせ持つ小型の携帯情報端末である。
【００２４】
しかし、各アクセス方法の性格は大きく異なっており、それぞれが特徴的な形態を有するので、それらの情報収集能力は一様ではない。例えば、ＷＥＢブラウザは、ハイパーテキスト風の構成で文書間のリンクをたどることで、ネットワーク上の情報資源にアクセスできる点が特徴である。
【００２５】
こうした多様なアクセス方法でアクセスしてくるユーザに対して、資源の変化を通知するサービスを提供することを考える。この場合、サービスプロバイダに資源の監視を依頼するための監視要求の出し方、およびプロバイダからの変更通知の出し方は、ユーザのアクセス方法によって異なる。したがって、このサービスに対するユーザのニーズは多様である。
【００２６】
上述のようにアクセス方法は多様であるが、幸いネットワーク上の資源を統一的に表現する識別情報としてＵＲＬ（uniform resource locator）がある。そこで、以下の実施形態においては、資源の存在場所をＵＲＬにより一般化して表現し、監視要求の出し方および更新情報（変化情報）の受信方法と分離する。これにより、多様な通信手段に個別に対応する場合に予想されるプロトコルの乱立を防ぐことができる。さらに、新たに導入される他の通信手段に対応するのが容易になる。
【００２７】
図２は、このようなネットワーク資源監視システムの構成図である。図２のネットワーク資源監視システムは、監視要求入力インタフェース１０、通知インタフェース１１、通知手段管理システム１２、およびＵＲＬ監視システム１３を備える。そして、ユーザから指定された特定のＵＲＬの資源を監視し、その変化をユーザに通知する。監視要求入力インタフェース１０および通知インタフェース１１としては、例えば、ＷＥＢブラウザ端末、Ｅ−ｍａｉｌ端末、ＰＤＡなどが用いられる。
【００２８】
監視要求入力インタフェース１０は、ユーザから入力された監視対象のＵＲＬと通知手段とを、監視要求とともに通知手段管理システム１２に伝える。通知手段管理システム１２は、例えばインターネットへの接続サービスを行うプロバイダのサーバであり、監視要求をＵＲＬ監視システム１３に伝える。ＵＲＬ監視システム１３は指定されたＵＲＬの資源１４の状態を監視し、それが変化した時直ちに、その情報を通知手段管理システム１２に知らせる。
【００２９】
通知手段管理システム１２は、通知インタフェース１１に対して監視結果を通知する通知手段を管理しており、ＵＲＬ監視システム１３から受け取った情報を、対応する通知手段により通知インタフェース１１に通知する。これにより、ユーザは資源１４の状態に変化があったことを知り、その資源１４にアクセスして変化した情報を得ることができる。
【００３０】
図２のネットワーク資源監視システムにおいて、ＵＲＬ監視システム１３はＵＲＬで一般化された世界に属し、システムのバックボーンとして動作する。そして、通知手段管理システム１２は、インタフェース依存性のある世界と一般化された世界の境界上に位置し、バックボーンからの更新情報を元にした監視サービスを展開することが可能である。各サービスプロバイダはバックボーンのプロトコルを公開し、ユーザに対する各通知手段をサポートした監視サービスを展開する。
【００３１】
図３は、通知手段管理システム１２およびＵＲＬ監視システム１３の一例として用いられる情報処理装置の構成図である。図３の情報処理装置は、ＣＰＵ（中央処理装置）１５、メモリ１６、通信部１８、データベース２０、およびそれらを結ぶバス１９を有し、通信部１８を介して通信ネットワーク１７に接続されている。
【００３２】
ＣＰＵ１５はメモリ１６を利用して、監視サービスを提供するために必要なプロセスを生成し、データベース２０のデータを参照しながら処理を行う。通信部１８は、通信ネットワーク１７との間で情報の送受信を行う。
【００３３】
このような監視サービスを利用して、ユーザの管理するＦＴＰ（file transfer protocol）サイトのメンテナンスをしようとした場合、変更があったことを知るだけでなく、物理的なファイルの転送および削除などのアクションをとることができれば便利なことがある。
【００３４】
そこで、プロバイダに能力があれば、例えばＦＴＰサイト管理デーモンなどのプロセスを通知手段管理システム１２内に作成し、ＦＴＰサイトのファイルの管理を行わせる。これにより、監視サービスがオープンワールドでも受け入れられていく可能性がある。このＦＴＰサイトのファイル操作については、後述することにする。
【００３５】
ところで、資源１４の監視においては、それを定期的にアクセスすることが必要なため、通信のためのコストが非常に高くなることが予想される。前述したように、この傾向は、ネットワーク的に遠い資源の監視をする場合に特に顕著となる。したがって、世界的な規模を持つインターネットの場合、ネットワークの負荷が著しく増大する可能性がある。
【００３６】
そこで、ＵＲＬを監視するバックボーンでは、デリゲーション（delegation）を有効に使うことを考える。デリゲーションは、インターネットに接続された個々のネットワークを保護するためのアクセス制限であるファイアウォールの構築でよく使われた手法である。
【００３７】
多くの場合、ローカルネットワークはゲートウェイを介してインターネットに接続され、ゲートウェイに収容された処理装置が外部からのアクセスを制限する。この場合、ゲートウェイの処理装置は、ローカルネットワーク内の各情報処理装置を代表して、外部からのアクセスを制御している。このような手法がデリゲーションと呼ばれる。
【００３８】
以下の実施形態では、このデリゲーションをネットワーク負荷の低減のために転用し、ＵＲＬ監視システム１３をデリゲーション・バックボーンとする。ＵＲＬ監視システム１３は、個々のユーザを代表して資源１４を監視する機能を持つ。これにより、各ユーザが資源１４をチェックするために頻繁にアクセスする必要がなくなり、ネットワーク負荷を減少させることができる。
【００３９】
このようなデリゲーションシステムは、監視資源をＵＲＬで一般化したことによって、より現実的なものになる。もし一般化されていなければ、多様なプロトコルで管理された資源に応じて、多数のデリゲーションシステムを用意しなければならなくなるが、ＵＲＬで監視する場合は、１つのデリゲーションシステムで対応可能である。
【００４０】
また、図２のネットワーク資源監視システム内における情報の伝達は任意の通信処理により実現可能であるが、本実施形態では、一例としてリモートプログラミングに基づく言語であるテレスクリプト（Telescript）による方法を用いることにする。
【００４１】
テレスクリプトによるリモートプログラミングにおいては、データを保持するプロセスの一種であるエージェント（Agent ）が用いられる。この場合には、各ユーザの監視要求情報を各エージェントに持たせることが可能であるため、複数のユーザの要求を独立に処理することができる。さらに、エージェントは自律的に機能して、処理が終了すれば自動的に消滅するため、不特定多数のユーザが利用するネットワーク上の処理に適している。
【００４２】
テレスクリプトによるリモートプログラミングについては、「リモートプログラミングの実施方法」（特願平６−１７９７６７、特開平７−１８２１７４）に詳述されているが、ここでその手法について説明する。
【００４３】
このリモートプログラミングは、複数の計算機システムを結ぶ通信ネットワーク上での処理を記述する方法の一種で、ネットワークを渡り歩く移動可能なプロセスであるエージェントと、エージェントが入ってくる固定プロセスであるプレイス（Place ）により実現される。
【００４４】
図４は、プレイスの構成を示している。プレイスは、他のプロセスと識別可能なテレネーム（telename）を持ち、任意有限個の子プロセスを持つことができる。また、プレイスは、自己および他のプロセスより参照可能な任意有限個のデータと、自己および他のプロセスより呼出し可能な任意有限個の手続きとを有する。
【００４５】
さらに、メインルーチンとして手続きliveを持ち、作成されたプレイスはｌｉｖｅを実行する。プレイスは、ｌｉｖｅが実行されている間だけ存在し、ｌｉｖｅが終了すると消滅する。プレイスが消滅すると、その子プロセスも終了し、消滅する。
【００４６】
図５は、エージェントの構成を示している。エージェントは、他のプロセスと識別可能なテレネームを持ち、あるプレイスの中の子プロセスとしてのみ存在する。また、エージェントは、自己および他のプロセスより参照可能な任意有限個のデータと、自己および他のプロセスより呼出し可能な任意有限個の手続きとを有する。
【００４７】
さらに、メインルーチンとして手続きｌｉｖｅを持ち、作成されたエージェントはｌｉｖｅを実行する。エージェントは、ｌｉｖｅが実行されている間だけ存在し、ｌｉｖｅが終了すると消滅する。エージェントの手続きｌｉｖｅの中でコマンドｇｏが実行されると、そのエージェントはネットワークを介して指定された行き先へ移動する。
【００４８】
図６は、コマンドｇｏによるオペレーションの例を示している。図６において、プレイス２１内のエージェント２２は、ｇｏの実行により、行き先のプレイス２４を指定するデータであるチケット（Ticket）２３を得て、指定されたプレイス２４に移動する。
【００４９】
このとき、エージェント２２は、ｇｏによりｌｉｖｅの実行を一時中断し、保持したデータとともに凍結（圧縮）され、パック化される。そして、チケット２３に示されたプレイス２４に送られ、プレイス２４により受け入れをチェックされる。プレイス２４に受け入れられると、その中に子プロセスとして置かれた後、解凍（伸張）され、ｇｏの次のコマンドからｌｉｖｅの実行を再開する。
【００５０】
また、エージェントは、手続きｌｉｖｅの中で自己の置かれているプレイス内にある他のエージェントを求めるコマンドｍｅｅｔを呼出すことができる。コマンドｍｅｅｔの実行時には、エージェントは相手のエージェントを指定するデータであるペティション（Petition）を用いる。
【００５１】
図７は、コマンドｍｅｅｔによるオペレーションの例を示している。図７において、プレイス３１内のエージェント３２は、コマンドｍｅｅｔによりあるペティションを指定する。プレイス３１は、ペティションにより指定された条件に該当するエージェントを探す。そして、プレイス３１内に該当するエージェントがなければ、そのようなエージェントが入ってくるまで待つ。
【００５２】
プレイス３１内のエージェント３３がペティションの条件に該当すれば、プレイス３１は、エージェント３２が相互作用を希望していることをエージェント３３に伝える。そして、エージェント３３がエージェント３２の希望を受け入れる旨の戻り値を返すと、プレイス３１は、エージェント３３へのポインタをｍｅｅｔの戻り値としてエージェント３２に返す。その後、エージェント３２は、エージェント３３へ直接アクセスして、情報交換等を行うことが可能になる。
【００５３】
以下では、コマンドｇｏによりエージェントが移動することを単に「ｇｏする」と記述し、コマンドｍｅｅｔにより他のエージェントと相互作用を行うことを単に「ｍｅｅｔする」と記述する。
【００５４】
図８は、上述のようなリモートプログラミングを用いたネットワーク資源監視システムの構成図である。図８において、監視サービスプレイス４６とデリゲートプレイス（delegate place）５１は、それぞれ決められた機能を有するプレイスであり、フォームエージェント（form agent）４８、監視エージェント５３、通知エージェント５４、５４′、リポートエージェント５５、５６、５７、５８は、それぞれ決められたデータと機能を有するエージェントである。
【００５５】
Magic Cap ４１、ＭＵＡ（Mail User Agent ）４２、およびＷＥＢブラウザ４３は、図２の監視要求入力インタフェース１０に対応し、ユーザが監視要求を入力する際に用いる。これらの具体的な違いについては後述する。通知手段管理システム１２は、例えばプロバイダ毎に設けられ、監視データベース（ＤＢ）４７を備え、ユーザに監視サービスを提供する監視サービスプレイス４６を保持する。
【００５６】
また、ＵＲＬ監視システム１３は、デリゲートデータベース（ＤＢ）５２を備え、ユーザに代わって資源を監視するためのデリゲートプレイス５１を保持する。監視に伴う通信コストの低減を図るため、このＵＲＬ監視システム１３は通信的に近いＵＲＬのグループ毎に設けられる。通信的に近いＵＲＬとは、比較的低い通信コストでアクセス可能なＵＲＬを意味する。例えば、インターネットに接続する各国毎に１つのＵＲＬ監視システム１３を設けてもよく、よりローカルな地域のサーバ毎に設けてもよい。
【００５７】
通知手段管理システム１２とＵＲＬ監視システム１３は通信ネットワーク４９を介して接続され、情報交換を行うことができる。また、通信ネットワーク４９にはＵＲＬで識別される資源５０−１、５０−２、５０−３も接続されている。尚、接続される資源の数は任意である。以下では、このような資源のことを単に“ＵＲＬ”と記述することもある。
【００５８】
監視要求が監視要求入力インタフェース１０に入力されると、監視サービスプレイス４６内にフォームエージェント４８が現れる。フォームエージェント４８は監視ＤＢ４７を更新した後、通信ネットワーク４９を介してデリゲートプレイス５１にｇｏし、デリゲートＤＢ５２を更新する。監視ＤＢ４７には、監視結果の通知先であるユーザのＵＲＬが格納され、デリゲートＤＢ５２には、通知先の監視サービスプレイス４６のアドレス情報が格納される。
【００５９】
監視エージェント５３は、デリゲートＤＢ５２を参照して監視先ＵＲＬを監視し、それが更新されると通知エージェント５４を作成する。通知エージェント５４はコマンドｓｅｎｄを実行して、通知エージェント５４′を監視サービスプレイス４６に送る。
【００６０】
ｓｅｎｄは、エージェントの手続きｌｉｖｅの中で実行され、そのエージェントの複製を作って他のプレイスに送るコマンドである。ここでは、通知エージェント５４′は、通知エージェント５４の分身（クローンエージェント）として生成される。
【００６１】
通知エージェント５４′は、監視ＤＢ４７の通知先ＵＲＬに応じて、適したリポートエージェント５５、５６、５７、５８を作成する。リポートエージェント５５、５６、５７、５８は、それぞれの通知インタフェース１１の種類に応じた通知手段でユーザに結果を報告する。これらのリポートエージェントの処理の詳細については後述する。
【００６２】
以上の構成により、ユーザは更新された監視先ＵＲＬの情報を自動的に通知されるので、ユーザ自身が資源のチェックを行う必要はなくなる。また、通知手段管理システム１２とＵＲＬ監視システム１３が分離して設けられ、監視先に近いＵＲＬ監視システム１３が複数のユーザを代表して、ＵＲＬを監視する。
【００６３】
したがって、多数のユーザによる資源監視のための頻繁なアクセスをなくして、ネットワークの負荷を大幅に軽減することができる。
次に、図９から図１４までを参照しながら、図８のネットワーク資源監視システムにおける具体的な処理について説明する。
【００６４】
ネットワーク資源監視システムに対する監視要求の発行は、各種のデバイスおよびプログラムから行うことができる。例えば、図８におけるＷＥＢブラウザ４３はハイパーテキストベースでインターネット上に分散配置された情報を探索するソフトウェアツールであり、ＭＵＡ４２はＥ−ｍａｉｌを発行するソフトウェアツールである。また、Magic Cap ４１はエージェントを利用したＰＤＡ端末の一種である。ＷＥＢブラウザ４３およびＭＵＡ４２は、ユーザの端末計算機内に収容されている。
【００６５】
監視要求の出し方は、勿論、各デバイスおよびプログラムの種類によって異なるが、次の２つの条件を満たす必要がある。
（１）何等かの方法で、フォームエージェント４８を監視サービスプレイス４６上に作成すること。
（２）フォームエージェント４８には、次のデータを与えること。
【００６６】
・監視先ＵＲＬ
・通知先ＵＲＬ
・依頼主ＩＤ、パスワード
・コメント
・備考データ
監視先ＵＲＬは監視対象の資源のＵＲＬであり、通知先ＵＲＬは監視結果を通知するＵＲＬであり、依頼主ＩＤおよびパスワードは依頼主の識別情報である。通知先ＵＲＬは、通常、依頼主ＩＤ毎に割り振られる。また、コメントと備考データは必ずしも必須ではなく、必要に応じて付加される。
【００６７】
このように、監視入力インタフェースの形態に依らないフォームエージェント４８を作成することで、各種のプログラム等による監視要求を受け付けることが可能になり、システムの拡張性が高まる。
【００６８】
次に、監視要求の入力例について説明する。入力機器としては、マウス等のポインティングデバイスやキーボードが用いられる。ＷＥＢブラウザ４３を用いる場合、ユーザはまず監視依頼フォーム（Form）のＨＴＭＬ（hypertext markup language ）文書をｏｐｅｎし、そのフォームの空欄の穴うめをする。ＨＴＭＬとは他文書へのリンクを持つハイパーテキスト文書を記述する言語で、これにより記述された文書はＨＴＭＬ文書と呼ばれる。
【００６９】
図９は、ユーザ端末のディスプレイ上に表示された監視依頼フォームの入力例を示している。図９の監視依頼フォーム７０において、ｌｏｏｋ ＵＲＬ７１は監視先ＵＲＬを表し、Ｒｅｐｏｒｔ ＵＲＬ７２は通知先ＵＲＬを表し、ＩＤ７３およびＰａｓｓｗｄ７４は、それぞれ依頼主ＩＤおよびパスワードを表す。これらの情報を入力した後、Ｃｏｎｆｉｒｍボタン７５をクリックすると、図８のＣＧＩ（ common gateway interface ）プロセス４５が起動される。
【００７０】
ＣＧＩプロセス４５は、ＩＤ７３毎に決まったＨＴＭＬ文書７６をｏｐｅｎする。ＨＴＭＬ文書７６は、指定された監視対象の資源へのリンク（ＵＲＬ）のリストを表示するために用いられる。ここでは、指定された監視先ＵＲＬがＨＴＭＬ文書７６内にリンクとして書き込まれ、リンクのリストがディスプレイに表示される。
【００７１】
次に、ＣＧＩプロセス４５は、クラウド（cloud ）との間にコネクションを確立する。クラウドとは、ネットワーク上でプログラム言語を解釈して実行するためのソフトウェア環境を表し、ここでは監視サービスプレイス４６に相当する。ＣＧＩプロセス４５は、確立されたコネクションを通じてプロセス間通信を行い、監視依頼フォーム７０に入力されたパラメータを監視サービスプレイス４６へ送る。
【００７２】
そして、監視サービスプレイス４６は、送られたパラメータを元にフォームエージェント４８を作成する。
また、監視要求入力インタフェース１０としてＭＵＡ４２を用いる場合は、ユーザは一定のフォーマットのＥ−ｍａｉｌ（コントロールメール：control mail）４４を監視サービスプレイス４６宛に送る。
【００７３】
図１０は、ＭＵＡ４２により作成されるコントロールメール４４の例を示している。コントロールメール４４には、監視依頼フォーム７０と同様に、ｌｏｏｋＵＲＬ（監視先ＵＲＬ）、Ｒｅｐｏｒｔ ＵＲＬ（通知先ＵＲＬ）、ＩＤ、Ｐａｓｓｗｏｒｄ等の情報が記述される。
【００７４】
監視サービスプレイス４６は、通知手段管理システム１２内に設けられたsendmailポートで通信をlistenしており、sendmailのプロトコルを認識することができる。そして、送られてきたコントロールメール４４を受信し、それをパース（parse ）して、メールの構成要素を分析する。次に、その結果を元にフォームエージェント４８を作成する。
【００７５】
また、監視要求入力インタフェース１０としてMagic Cap ４１を用いる場合は、ユーザは専用のフォームでマジックメール（Magicmail ）を作成し、監視サービスプレイス４６へ送信する。マジックメールとは、メールの内容をデータとして持つエージェントが他の計算機等に移動することで、メッセージを伝えるメールの形態を指す。
【００７６】
ここでは、マジックメールの送信処理により、Magic Cap ４１上で、監視先ＵＲＬ、通知先ＵＲＬ、依頼主ＩＤ、パスワード等のデータを持つフォームエージェント４８が生成される。そして、直接監視サービスプレイス４６へｇｏする。
【００７７】
次に、このようにして作成されたフォームエージェント４８が行う処理を説明する。フォームエージェント４８は、監視ＤＢ４７に通知先ＵＲＬを登録し、デリゲートＤＢ５２に通知先プレイスのアドレスを登録して、結果を通知する際の経路を通知エージェント５４、５４′に伝える役割を果たす。このため、フォームエージェント４８は、監視ＤＢ４７とデリゲートＤＢ５２にレコードを追加したり、それらのレコードを変更したりする機能を持つ。
【００７８】
図１１は、監視ＤＢ４７のデータ構造の例を示している。図１１において、ハッシュ表８１には、キー（key ）として用いられる監視先ＵＲＬ毎にレコードを指すポインタが格納されている。例えば、１番目の監視先ＵＲＬ“ｈｔｔｐ：／／〜”に対応するポインタはレコード８２−１を指しており、２番目の“ｆｔｐ：／／〜”に対応するポインタはレコード８２−２を指している。監視先ＵＲＬの中で、“ｈｔｔｐ：”や“ｆｔｐ：”は接続形態を表すプロトコル部に相当する。
【００７９】
レコード８２−１および８２−２は、Ｔａｒｇｅｔ１、Ｔａｒｇｅｔ２、Ｔａｒｇｅｔ３の３つのエントリを持ち、これらのエントリはそれぞれ、最終更新履歴、通知先ＵＲＬのリストへのポインタ、備考データを表す。
【００８０】
最終更新履歴は、監視先ＵＲＬの最終更新日時のタイムスタンプと更新後の情報のファイルサイズを含む。Ｔａｒｇｅｔ２のポインタが指すＵＲＬのリストの最後の（ｎｉｌ）は空白データを表し、リストの終端であることを示している。フォームエージェント４８が備考データを持っている場合、それはＴａｒｇｅｔ３として格納される。
【００８１】
通知エージェント５４′は、この監視ＤＢ４７から監視先ＵＲＬをキーとして、監視先ＵＲＬの最終更新のタイムスタンプとファイルサイズ、および通知先ＵＲＬのリストを引くことができる。
【００８２】
フォームエージェント４８は、持っている監視先ＵＲＬがハッシュ表８１の中にないとき、それをハッシュ表８１のエントリとして追加し、対応するレコードを登録する。このとき、タイムスタンプとしては登録時の日時を用い、ファイルサイズは０としておく。また、通知先ＵＲＬリストにはフォームエージェント４８が持つ通知先ＵＲＬを登録する。
【００８３】
フォームエージェント４８の監視先ＵＲＬがハッシュ表８１の中にキーとして存在するときは、対応するレコードのエントリを変更する。ただし、タイムスタンプとファイルサイズは変更せず、通知先ＵＲＬリストにフォームエージェント４８の通知先ＵＲＬを追加する。
【００８４】
その後、フォームエージェント４８はデリゲートプレイス５１へｇｏして、デリゲートＤＢ５２にレコードを追加したり、またはレコードを変更したりする。
図１２は、デリゲートＤＢ５２のデータ構造の例を示している。図１２において、ハッシュ表９１にはハッシュ表８１と同様に、監視先ＵＲＬ毎にポインタが格納されている。例えば、１番目の監視先ＵＲＬ“ｈｔｔｐ：／／〜”に対応するポインタはレコード９２−１を指しており、２番目の“ｆｔｐ：／／〜”に対応するポインタはレコード９２−２を指している。
【００８５】
レコード９２−１および９２−２は、Ｔａｒｇｅｔ１、Ｔａｒｇｅｔ２、Ｔａｒｇｅｔ３の３つのエントリを持ち、Ｔａｒｇｅｔ１とＴａｒｇｅｔ２の内容は図１１の場合と同様である。
【００８６】
Ｔａｒｇｅｔ２は通知先リストへのポインタを表し、各通知先としてはフォームエージェント４８を送り出した監視サービスプレイス４６のＴｅｌｅａｄｄｒｅｓｓとＷａｙが用いられる。ここで、Ｔｅｌｅａｄｄｒｅｓｓはプレイスを一意に識別する識別子であり、Ｗａｙはそのプレイスまでの移動方法を表す。これらの情報は、フォームエージェント４８のｇｏの返り値であるＴｉｃｋｅｔＳｔｕｂに記述されている。
【００８７】
通知エージェント５４は、このデリゲートＤＢ５２から監視先ＵＲＬをキーとして、監視先ＵＲＬの最終更新のタイムスタンプとファイルサイズ、および通知先監視サービスプレイス４６のアドレスリストを引くことができる。
【００８８】
また、デリゲートＤＢ５２は、フォームエージェント４８により監視ＤＢ４７と同様のレコードの追加、変更を受ける。ただし、通知先としては、通知先ＵＲＬではなく、フォームエージェント４８のＴｉｃｋｅｔＳｔｕｂの情報が用いられる。
【００８９】
監視サービスプレイス４６は、監視要求の出し方および通知の方法から資源の監視方法を分離し、ＵＲＬで表現できる資源の監視という形態に一般化する役割を果たす。これにより、多様なユーザインタフェースを持つ複数のユーザを代表してＵＲＬを監視するサービスを提供することが可能になる。
【００９０】
デリゲートプレイス５１は、監視先ＵＲＬの更新履歴をチェックして、その変化を監視するために設けられる。ユーザに対する通知方法等は、監視サービスプレイス４６により隠蔽されているので、デリゲートプレイス５１が関知する必要はない。
【００９１】
監視エージェント５３はデリゲートプレイス５１内にあって、ＦＴＰプロトコルにより、デリゲートＤＢ５２内の監視先ＵＲＬのタイムスタンプおよびファイルサイズを定期的にチェックする。
【００９２】
図１３は、監視エージェント５３が行う監視処理のフローチャートである。図１３において処理が開始されると、監視エージェント５３はループ処理を開始し（ステップＳ１）、デリゲートＤＢ５２のハッシュ表９１を用いて、次の監視先ＵＲＬに対応するレコードを取得する（ステップＳ２）。
【００９３】
次に、取得したレコードのキーである監視先ＵＲＬへＦＴＰプロトコルによりconnect する（ステップＳ３）。そして、監視先ＵＲＬのタイムスタンプとファイルサイズを取得し（ステップＳ４）、それらをデリゲートＤＢ５２のレコードの対応するエントリと比較する（ステップＳ５）。ここで、監視先ＵＲＬのタイムスタンプやファイルサイズに変化があるかどうかが調べられる。
【００９４】
両者のタイムスタンプやファイルサイズが異なり、監視先ＵＲＬに変更があると判断できる場合、通知エージェント５４をデリゲートプレイス５１上に作成し、デリゲートＤＢ５２のレコードを初期化引数として通知エージェント５４に渡す（ステップＳ６）。
【００９５】
次に、ループ処理を終了するかどうか判定する（ステップＳ７）。この判定は、あらかじめ決められた適当な終了条件が成立するかどうかをチェックすることにより行われる。通常は終了条件が成立することはないので、ステップＳ２以降の処理を半永久的に繰り返す。また、ステップＳ５において監視先ＵＲＬに変更なしと判断できる場合も、ステップＳ２以降の処理を繰り返す。そして、ステップＳ７において終了条件が成立すれば、処理を終了する。
【００９６】
図１３の監視処理においては、監視先ＵＲＬへＦＴＰ接続して更新情報（更新履歴）を取得する構成となっている。これ以外に、監視先ＵＲＬの管理者が更新情報を持たせた更新（Update）エージェントをデリゲートプレイス５１に送る方法を用いることもできる。この場合は、更新エージェントがデリゲートプレイス５１内で監視エージェント５３にｍｅｅｔし、更新情報を伝える。これにより、監視エージェント５３は、より積極的に監視先ＵＲＬから発信された更新情報を受け付けることになる。
【００９７】
監視処理においては、その性質上何等かの方法で監視先ＵＲＬの更新情報を取得する必要があるので、監視先ＵＲＬとの定期的な通信が必要になる。このため、デリゲートプレイス５１からネットワーク的に近い所だけを監視対象にした方が効率がよい。
【００９８】
デリゲートプレイス５１から遠い所を監視する場合は、監視先ＵＲＬの近くに、デリゲートプレイス５１等を代表する別のデリゲートプレイスを設けて、それに監視させることも考えられる。つまり、デリゲートのデリゲートを設けることになる。
【００９９】
監視エージェント５３により作成された通知エージェント５４は、更新されたＵＲＬについて、デリゲートＤＢ５２および監視ＤＢ４７のレコードを変更する。
【０１００】
図１４は、通知エージェント５４の処理のフローチャートである。図１４において処理が開始されると、通知エージェント５４は、まず初期化引数として渡されたデリゲートＤＢ５２のレコードのタイムスタンプとファイルサイズを、監視先ＵＲＬのものに更新する（ステップＳ１１）。
【０１０１】
次に、対応する通知先リストに格納されたＴｅｌｅａｄｄｒｅｓｓとＷａｙを用いてコマンドｓｅｎｄを実行し、各監視サービスプレイスに分身の通知エージェント５４′を送る（ステップＳ１２）。
【０１０２】
通知エージェント５４′は最新の更新履歴のデータを持っており、例えば監視サービスプレイス４６に移動する。そして、監視ＤＢ４７内の対応するレコードのタイムスタンプとファイルサイズを最新のものに更新する（ステップＳ１３）。
【０１０３】
次に、そのレコードの通知先ＵＲＬリストを参照し、各通知先ＵＲＬに適したリポートエージェントを作成し（ステップＳ１４）、処理を終了する。リポートエージェントのクラスは、通知の方法、すなわちＵＲＬに含まれるプロトコル部毎に異なっており、例えば次のようなものがある。ここで、クラスとはオブジェクトの構造の定義に相当する。
（ａ）プロトコル部が“ｍａｉｌｔｏ：”の場合は、そのクラスはＥ−ｍａｉｌによる通知方法を定義する。
（ｂ）プロトコル部が“ｈｔｔｐ：”の場合は、そのクラスはＨＴＭＬ文書のリンクリストのページを更新して通知する方法を定義する。
（ｃ）プロトコル部が“ｆｔｐ：”の場合は、そのクラスはファイルシステムのメンテナンス方法を定義する。
【０１０４】
したがって、通知エージェント５４′は通知先ＵＲＬのプロトコル部を参照することで、作成すべきリポートエージェントのクラスを決定し、そのインスタンスを作成することができる。ここで、インスタンスとはクラスにより定義されたオブジェクトの具体例を意味し、今の場合はリポートエージェント５５、５６、５７、５８等を指す。
【０１０５】
次に、各クラスのリポートエージェントの処理について説明する。ｍａｉｌｔｏリポートエージェントは、リポートエージェント５５および５６に対応する。リポートエージェント５６は、更新のあったＵＲＬをＥ−ｍａｉｌ５９で通知先ＵＲＬに送信する。
【０１０６】
また、その発展形であるリポートエージェント５５の場合は、マジックメールをMagic Cap ４１に送る。マジックメールをＵＲＬで記述する方法はＲＦＣ（Requests For Comments ）１７３８に記載されている。このほかに、マジックメールのためのゲートウェイを通過させる方法もある。
【０１０７】
ｈｔｔｐリポートエージェントはリポートエージェント５７に対応し、通知先ＵＲＬに存在するＨＴＭＬ文書６０内のリンクリストに、更新されたＵＲＬを付け加える。
【０１０８】
このＨＴＭＬ文書６０は、例えば図９のＨＴＭＬ文書７６と同様のフォーマットを持ち、更新されたＵＲＬのリストをリンクリストとして持っている。ＨＴＭＬ文書６０のリンクリストは監視の依頼時には空白のままであるが、リポートエージェント５７により、更新のあったＵＲＬが１つずつ追加されていく。
【０１０９】
そして、端末上に表示されたリンクリスト内の１つのリンクをユーザがクリックすれば、対応するページへ飛ぶことができる。これにより、ユーザは更新された情報を実際に確認することができる。
【０１１０】
ｆｔｐリポートエージェントはリポートエージェント５８に対応し、通知先ＵＲＬにあるＦＴＰサイト６１のファイルシステムのメンテナンスを行う。リポートエージェント５８は、例えば、更新ＵＲＬのファイル名からどのアプリケーション・ソフトウェアのどのバージョンかを判断し、ＦＴＰサイト６１内の対応する古いバージョンを削除する。そして、更新ＵＲＬから新しいバージョンを取得し、ＦＴＰサイト６１内のファイルシステムに追加する。
【０１１１】
このように、リポートエージェントは更新ＵＲＬを通知するのみではなく、ファイルシステムの物理的な変更を行うこともできる。また、監視要求の入力時にユーザが通知先ＵＲＬを２つ以上指定した場合、それらのＵＲＬ毎にリポートエージェントが作成され、更新されたＵＲＬの報告をメール等で同時に行う。通知先として、ユーザのページャ（ポケットベル等）を指定することも考えられる。
【０１１２】
次に、図１５から図２０までを参照しながら、監視要求入力インタフェース１０および通知インタフェース１１としてＷＥＢブラウザ４３を用いた場合の入力処理と通知処理について説明する。
【０１１３】
以下では、ユーザが指定した監視先ＵＲＬのリストを表示するためのＨＴＭＬ文書７６が存在するＵＲＬを、指定リスト表示ＵＲＬと呼ぶことにする。また、更新された監視先ＵＲＬのリストを表示するためのＨＴＭＬ文書６０が存在するＵＲＬを、更新リスト表示ＵＲＬと呼ぶことにする。後述するように、この更新リスト表示ＵＲＬは監視ＤＢ４７の通知先ＵＲＬに一致する。
【０１１４】
図１５は新規監視依頼時の処理の概要を示しており、図１６はその処理のフローチャートである。図１５において、加入者管理データベース（ＤＢ）１０１はユーザ端末から参照可能な場所に設けられ、加入者のＩＤ毎に指定リスト表示ＵＲＬを格納している。新規監視要求の入力時には、ＣＧＩプロセス４５およびＨＴＭＬエージェント１０２が作成される。
【０１１５】
図１６において処理が開始されると、ユーザは、まず図９の監視依頼フォーム７０を穴うめし、Ｃｏｎｆｉｒｍボタン７５をクリックする（ステップＳ２１）。これにより、ＣＧＩプロセス４５が生成される（ステップＳ２２）。
【０１１６】
ＣＧＩプロセス４５は、加入者管理ＤＢ１０１から、入力されたＩＤに対応する指定リスト表示ＵＲＬを引き（ステップＳ２３）、それを初期化パラメータとしてＨＴＭＬエージェント１０２を作成する（ステップＳ２４）。
【０１１７】
ＨＴＭＬエージェント１０２は、例えば図９のＨＴＭＬ文書７６の雛形となるスケルトンデータを保持している。また、既存のＨＴＭＬ文書を解釈してリンクを抽出するオペレータと、与えられたリンクのリストをスケルトンデータにはめ込んで新たなＨＴＭＬ文書を作成するオペレータとを持つ。
【０１１８】
ＨＴＭＬエージェント１０２は、これらのオペレータを用いて指定リスト表示ＵＲＬのＨＴＭＬ文書７６を書き換える（ステップＳ２５）。これにより、新たに入力された１つ以上の監視先ＵＲＬが、リンクリストとしてＨＴＭＬ文書７６に書き込まれる。
【０１１９】
そして、ＣＧＩプロセス４５は、ユーザにＨＴＭＬ文書７６の内容を示して（ステップＳ２６）、処理を終了する。このとき、同時に監視先ＵＲＬや通知先ＵＲＬ等の入力情報が監視サービスプレイス４６に送られる。
図１７は監視資源更新時の処理の概要を示しており、図１８はその処理のフローチャートである。監視資源の更新時には、デリゲートプレイス５１から監視サービスプレイス４６へ通知エージェント５４′が送られ、更新情報が伝えられる。
【０１２０】
図１８において処理が開始されると、通知エージェント５４′はリポートエージェント５７を作成する（ステップＳ３１）。リポートエージェント５７は、その通知先ＵＲＬを更新リスト表示ＵＲＬとみなし、これを引数にしてＨＴＭＬエージェント１０２を作成する（ステップＳ３２）。
【０１２１】
ＨＴＭＬエージェント１０２は、更新リスト表示ＵＲＬに存在するＨＴＭＬ文書６０内のリンクリストに、更新のあった監視先ＵＲＬを加えて、新しいＨＴＭＬ文書６０を作成する（ステップＳ３３）。そして、処理を終了する。
【０１２２】
その後、ＨＴＭＬ文書６０の内容がユーザに示され、更新のあったＵＲＬが報告される。
図１９はユーザがＨＴＭＬ文書６０のリンクを参照したときの処理の概要を示しており、図２０はその処理のフローチャートである。リンク参照時には、ＣＧＩプロセス４５が起動され、ＨＴＭＬ文書６０が更新される。
【０１２３】
図２０において処理が開始されると、まずユーザが更新リスト表示ＵＲＬのＨＴＭＬ文書６０のリンクリストを見て、１つのリンクをクリックする（ステップＳ４１）。これにより、ＣＧＩプロセス４５が起動される。ＣＧＩプロセス４５は、更新リスト表示ＵＲＬを引数としてＨＴＭＬエージェント１０２を作成する（ステップＳ４２）。
【０１２４】
ＨＴＭＬエージェント１０２は、クリックされたリンクをリンクリストから削除し、新しいＨＴＭＬ文書６０を書き出す（ステップＳ４３）。ＣＧＩプロセス４５は、クリックされたリンクのＵＲＬに表示画面をジャンプさせて（ステップＳ４４）、処理を終了する。
【０１２５】
こうして、ユーザはリンクされたページを参照することができ、参照操作はＨＴＭＬ文書６０に反映される。
以上のようなリモートプログラミングを用いた実施形態によれば、各エージェントの自律性を利用することにより、複数のユーザの監視要求を独立に処理することができる。また、監視サービスプレイス４６とデリゲートプレイス５１を別々に設けることにより、インタフェースに依存する処理と、ＵＲＬにより一般化された監視処理とが分離される。このため、資源を近くから監視することが可能になり、効率の良いデリゲーションシステムが構築される。
【０１２６】
尚、通知手段管理システム１２が監視資源とネットワーク的に近い場所にある場合は、デリゲートプレイス５１を通知手段管理システム１２内に設けても差し支えない。その場合は、通知手段管理システム１２はＵＲＬ監視システム１３の役割をも果たすことになる。また、監視先の資源を必ずしもＵＲＬで記述する必要はなく、他の任意の識別情報を用いてもよい。
【０１２７】
また、監視要求入力インタフェース１０および通知インタフェース１１としては、図８に示されたもののみならず、任意のデバイスやプログラムを用いることができる。
【０１２８】
さらに、本発明を実施する際に、必ずしもエージェントやプレイスを用いる必要はなく、それぞれの処理を普通のプロセスにより行ってもよい。この場合は、ネットワークを介したやりとりは、例えばＲＰＣ（remote procedure call ）等により実行される。
【０１２９】
【発明の効果】
本発明によれば、通信ネットワーク上の情報資源の変化をユーザに代わって監視することが可能になり、ユーザによる情報チェックのための多数のアクセスがなくなることが期待される。したがって、ネットワークの通信負荷が大幅に低減され、ユーザは、ネットワークを他の目的のためにより多く利用することができるようになる。
【図面の簡単な説明】
【図１】本発明の原理図である。
【図２】ネットワーク資源監視システムの構成図である。
【図３】情報処理装置の構成図である。
【図４】プレイスの構成を示す図である。
【図５】エージェントの構成を示す図である。
【図６】オペレーションｇｏを示す図である。
【図７】オペレーションｍｅｅｔを示す図である。
【図８】エージェントを用いたネットワーク資源監視システムを示す図である。
【図９】監視依頼フォームの入力例を示す図である。
【図１０】コントロールメールを示す図である。
【図１１】監視データベースのデータ構造を示す図である。
【図１２】デリゲートデータベースのデータ構造を示す図である。
【図１３】監視エージェントの処理のフローチャートである。
【図１４】通知エージェントの処理のフローチャートである。
【図１５】新規依頼時の処理を示す図である。
【図１６】新規依頼時の処理のフローチャートである。
【図１７】監視資源更新時の処理を示す図である。
【図１８】監視資源更新時の処理のフローチャートである。
【図１９】リンク参照時の処理を示す図である。
【図２０】リンク参照時の処理のフローチャートである。
【符号の説明】
１ 監視手段
２ 出力手段
３ 通知手段
４ 管理手段
５，１７，４９ 通信ネットワーク
６，１４ 資源
１０ 監視要求インタフェース
１１ 通知インタフェース
１２ 通知手段管理システム
１３ ＵＲＬ監視システム
１５ ＣＰＵ
１６ メモリ
１８ 通信部
１９ バス
２０ データベース
２１，２４，３１ プレイス
２２，３２，３３ エージェント
２３ チケット
４１ Magic Cap
４２ ＭＵＡ
４３ ＷＥＢブラウザ
４４，５９ Ｅ−ｍａｉｌ
４５ ＣＧＩプロセス
４６ 監視サービスプレイス
４７ 監視データベース
４８ フォームエージェント
５０−１，５０−２，５０−３ ＵＲＬ
５１ デリゲートプレイス
５２ デリゲートデータベース
５３ 監視エージェント
５４，５４′ 通知エージェント
５５，５６，５７，５８ リポートエージェント
６０，７６ ＨＴＭＬ文書
６１ ＦＴＰサイト
７０ 監視依頼フォーム
７１ ｌｏｏｋ ＵＲＬ
７２ Ｒｅｐｏｒｔ ＵＲＬ
７３ ＩＤ
７４ Ｐａｓｓｗｄ
７５ Ｃｏｎｆｉｒｍボタン
８１，９１ ハッシュ表
８２−１，８２−２，９２−１，９２−２ レコード
１０１ 加入者管理データベース
１０２ ＨＴＭＬエージェント
Claims (3)
- ネットワーク上の発信元での情報資源の変化を監視するネットワーク情報資源監視システムであって、該ネットワークは情報資源を発信する複数の発信元と複数の利用者端末と情報資源監視装置とから構成されており、
利用者端末から発信元の監視先ＵＲＬと通知先ＵＲＬを受け付ける手段と、
複数の発信元の監視先ＵＲＬの各々に対して一つまたは複数の通知先ＵＲＬを対応付けて管理する監視ＤＢと、
通知先ＵＲＬの中で使用可能な複数のプロトコルの各々に対応した、データの更新の検出を通知する複数の通知手段と、
前記監視ＤＢに登録されている発信元の監視先ＵＲＬのデータの更新を監視し、更新を検出した発信元の監視先ＵＲＬに対応する一つまたは複数の通知先ＵＲＬの各々に対し、当該通知先ＵＲＬ中に含まれるプロトコル情報に対応する通知手段に対してデータの更新の検出の通知を依頼する手段と、
を有するネットワーク情報資源監視システム。 - ネットワーク上の発信元での情報資源の変化を監視するネットワーク情報資源監視システムであって、該ネットワークは情報資源を発信する複数の発信元と複数の利用者端末と情報資源監視装置とから構成されており、
前記ネットワークで接続された通知手段管理システムとＵＲＬ監視システムとからなり、
前記通知手段管理システムは、
利用者から発信元の監視先ＵＲＬと通知先ＵＲＬを受け付ける手段と、
複数の発信元の監視先ＵＲＬの各々に対して一つまたは複数の通知先ＵＲＬを対応付けて管理する監視ＤＢと、
利用者から受け付けた発信元の監視先ＵＲＬと通知先ＵＲＬを前記監視ＤＢへ登録するとともに前記ＵＲＬ監視システムに対して当該発信元の監視先ＵＲＬのデータの更新の監視を要求する手段と、
前記ＵＲＬ監視システムから発信元の監視先ＵＲＬのデータの更新の検出の通知を受け付ける手段と、
通知先ＵＲＬの中で使用可能な複数のプロトコルの各々に対応した、データの更新を通知する複数の通知手段と,
前記ＵＲＬ監視システムからのデータの更新の検出の通知に応じて、データが更新された発信元の監視先ＵＲＬに対応する一つまたは複数の通知先ＵＲＬの各々に対して、当該通知先ＵＲＬ中に含まれるプロトコル情報に対応する通知手段に対してデータの更新の検出の通知を依頼する手段と、
を有し、
前記ＵＲＬ監視システムは、
前記通知手段管理システムから発信元の監視先ＵＲＬのデータの更新の検出の要求を受け付ける手段と、
複数の監視対象ＵＲＬの各々に対してデータの更新を検出した際の通知先を一つまたは複数対応付けて管理するデリゲートＤＢと、
前記デリゲートＤＢに登録されている発信元の監視先ＵＲＬのデータの更新を監視し、更新を検出した発信元の監視先ＵＲＬに対応する一つまたは複数の通知先の各々に対してデータの更新の検出を通知する手段と、
を有する、
ことを特徴とするネットワーク情報資源監視システム。 - 前記複数の通知手段の何れかは、
ＨＴＴＰプロトコルに対応し、
通知先ＵＲＬとして指定されているＨＴＭＬ文書にデータが更新された監視先ＵＲＬへのリンク情報を追加する手段と、
データが更新された監視先ＵＲＬのデータを利用者が参照した場合に当該監視先ＵＲＬへのリンク情報を通知先ＵＲＬとして指定されているＨＴＭＬ文書から削除する手段と
を有する、請求項１または２記載のネットワーク情報資源監視システム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP33968795A JP3935986B2 (ja) | 1995-12-26 | 1995-12-26 | ネットワークにおける情報資源の変化を通知するネットワーク情報資源監視システム |
| US08/744,310 US5933604A (en) | 1995-12-26 | 1996-11-05 | Network resource monitoring system and method for providing notice of changes in resources in a network |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP33968795A JP3935986B2 (ja) | 1995-12-26 | 1995-12-26 | ネットワークにおける情報資源の変化を通知するネットワーク情報資源監視システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH09181723A JPH09181723A (ja) | 1997-07-11 |
| JP3935986B2 true JP3935986B2 (ja) | 2007-06-27 |
Family
ID=18329851
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP33968795A Expired - Fee Related JP3935986B2 (ja) | 1995-12-26 | 1995-12-26 | ネットワークにおける情報資源の変化を通知するネットワーク情報資源監視システム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US5933604A (ja) |
| JP (1) | JP3935986B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2020231396A1 (en) * | 2019-05-13 | 2020-11-19 | Hewlett-Packard Development Company, L.P. | Data monitoring |
Families Citing this family (127)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020004812A1 (en) * | 1997-06-26 | 2002-01-10 | Tetsuro Motoyama | Method and system for diagnosis and control of machines using connectionless modes having delivery monitoring and an alternate communication mode |
| US6188869B1 (en) | 1994-04-07 | 2001-02-13 | Hark C. Chan | Information distribution and processing system |
| US7991347B1 (en) | 1994-04-07 | 2011-08-02 | Data Innovation Llc | System and method for accessing set of digital data at a remote site |
| US6021307A (en) | 1994-04-07 | 2000-02-01 | Chan; Hark C. | Information distribution and processing system |
| US7181758B1 (en) | 1994-07-25 | 2007-02-20 | Data Innovation, L.L.C. | Information distribution and processing system |
| US6289200B1 (en) | 1994-07-25 | 2001-09-11 | Hark C. Chan | Information distribution system which intermittaly transmits radio frequency signal digital data |
| US6604103B1 (en) * | 1994-09-02 | 2003-08-05 | Mark A. Wolfe | System and method for information retrieval employing a preloading procedure |
| US7467137B1 (en) | 1994-09-02 | 2008-12-16 | Wolfe Mark A | System and method for information retrieval employing a preloading procedure |
| GB9603582D0 (en) | 1996-02-20 | 1996-04-17 | Hewlett Packard Co | Method of accessing service resource items that are for use in a telecommunications system |
| US6078942A (en) * | 1996-04-25 | 2000-06-20 | Microsoft Corporation | Resource management for multimedia devices in a computer |
| JP3612185B2 (ja) * | 1996-09-13 | 2005-01-19 | 株式会社東芝 | 文書情報更新監視装置 |
| US7020700B1 (en) * | 1997-02-28 | 2006-03-28 | International Business Machines Corporation | Client side socks server for an internet client |
| JP3139408B2 (ja) * | 1997-03-17 | 2001-02-26 | カシオ計算機株式会社 | ホームページ更新通知装置 |
| US8626763B1 (en) | 1997-05-22 | 2014-01-07 | Google Inc. | Server-side suggestion of preload operations |
| US6760746B1 (en) * | 1999-09-01 | 2004-07-06 | Eric Schneider | Method, product, and apparatus for processing a data request |
| US6944658B1 (en) * | 1997-07-25 | 2005-09-13 | Eric Schneider | Content notification method, product, and apparatus |
| US7257604B1 (en) | 1997-11-17 | 2007-08-14 | Wolfe Mark A | System and method for communicating information relating to a network resource |
| US6728712B1 (en) * | 1997-11-25 | 2004-04-27 | International Business Machines Corporation | System for updating internet address changes |
| US6269362B1 (en) * | 1997-12-19 | 2001-07-31 | Alta Vista Company | System and method for monitoring web pages by comparing generated abstracts |
| US6360263B1 (en) * | 1998-02-25 | 2002-03-19 | International Business Machines Corporation | Dynamic resource allocation for user management in multi-processor time shared computer systems |
| US6275944B1 (en) * | 1998-04-30 | 2001-08-14 | International Business Machines Corporation | Method and system for single sign on using configuration directives with respect to target types |
| US6457063B1 (en) * | 1998-04-30 | 2002-09-24 | Sun Microsystems, Inc. | Method, apparatus & computer program product for dynamic administration, management and monitoring of daemon processes |
| US9374435B2 (en) | 1998-05-29 | 2016-06-21 | Blackberry Limited | System and method for using trigger events and a redirector flag to redirect messages |
| US20030120775A1 (en) * | 1998-06-15 | 2003-06-26 | Compaq Computer Corporation | Method and apparatus for sending address in the message for an e-mail notification action to facilitate remote management of network devices |
| JP2000010892A (ja) * | 1998-06-19 | 2000-01-14 | Nippon Telegr & Teleph Corp <Ntt> | 情報提供方法、システム、および情報提供プログラムを記録した記録媒体 |
| US6424966B1 (en) * | 1998-06-30 | 2002-07-23 | Microsoft Corporation | Synchronizing crawler with notification source |
| JP3492249B2 (ja) * | 1998-08-25 | 2004-02-03 | キヤノン株式会社 | 印刷装置および印刷システムおよびその制御方法 |
| US6734985B1 (en) | 1998-08-25 | 2004-05-11 | Canon Kabushiki Kaisha | Printing apparatus, printing system and method of controlling same |
| US6237143B1 (en) * | 1998-09-17 | 2001-05-22 | Unisys Corp. | Method and system for monitoring and capturing all file usage of a software tool |
| US6321251B1 (en) * | 1998-10-01 | 2001-11-20 | Unisys Corporation | Gateway for dynamically providing web site status information |
| CA2306083A1 (en) | 1998-10-28 | 2000-05-04 | Verticalone Corporation | Apparatus and method for automated aggregation and delivery of electronic personal information or data |
| US6289375B1 (en) * | 1998-10-30 | 2001-09-11 | International Business Machines Corporation | Method and apparatus for invoking network agent functions using a hash table |
| US7672879B1 (en) | 1998-12-08 | 2010-03-02 | Yodlee.Com, Inc. | Interactive activity interface for managing personal data and performing transactions over a data packet network |
| US7085997B1 (en) | 1998-12-08 | 2006-08-01 | Yodlee.Com | Network-based bookmark management and web-summary system |
| US8069407B1 (en) | 1998-12-08 | 2011-11-29 | Yodlee.Com, Inc. | Method and apparatus for detecting changes in websites and reporting results to web developers for navigation template repair purposes |
| JP3408984B2 (ja) | 1999-01-28 | 2003-05-19 | パナソニック コミュニケーションズ株式会社 | ネットワークファクシミリ装置 |
| US6338082B1 (en) | 1999-03-22 | 2002-01-08 | Eric Schneider | Method, product, and apparatus for requesting a network resource |
| USRE43690E1 (en) | 1999-03-22 | 2012-09-25 | Esdr Network Solutions Llc | Search engine request method, product, and apparatus |
| US8037168B2 (en) | 1999-07-15 | 2011-10-11 | Esdr Network Solutions Llc | Method, product, and apparatus for enhancing resolution services, registration services, and search services |
| US7188138B1 (en) | 1999-03-22 | 2007-03-06 | Eric Schneider | Method, product, and apparatus for resource identifier registration and aftermarket services |
| US9141717B2 (en) * | 1999-03-22 | 2015-09-22 | Esdr Network Solutions Llc | Methods, systems, products, and devices for processing DNS friendly identifiers |
| US7424712B1 (en) * | 1999-04-30 | 2008-09-09 | Sun Microsystems Inc | System and method for controlling co-scheduling of processes of parallel program |
| US7752535B2 (en) | 1999-06-01 | 2010-07-06 | Yodlec.com, Inc. | Categorization of summarized information |
| JP3195778B2 (ja) * | 1999-06-02 | 2001-08-06 | 株式会社次世代情報放送システム研究所 | 受信装置、送受信装置および受信方法 |
| JP3347100B2 (ja) * | 1999-07-30 | 2002-11-20 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 表示情報確定方法及び装置、表示情報確定のためのソフトウエア・プロダクトを格納した記憶媒体 |
| JP2001051928A (ja) * | 1999-08-11 | 2001-02-23 | Nec Corp | 情報配信システム及びその配信方法 |
| USRE44207E1 (en) | 1999-09-01 | 2013-05-07 | Esdr Network Solutions Llc | Network resource access method, product, and apparatus |
| US6260041B1 (en) * | 1999-09-30 | 2001-07-10 | Netcurrents, Inc. | Apparatus and method of implementing fast internet real-time search technology (first) |
| US6631363B1 (en) * | 1999-10-11 | 2003-10-07 | I2 Technologies Us, Inc. | Rules-based notification system |
| WO2001027787A1 (en) * | 1999-10-13 | 2001-04-19 | Watchwire, Inc. | Event monitoring and closed-loop response system |
| US6968360B1 (en) * | 1999-12-21 | 2005-11-22 | Bellsouth Intellectual Property Corporation | Automatic status notification |
| WO2001052084A1 (en) * | 2000-01-10 | 2001-07-19 | Juno Online Services, Inc. | Method and system for optimizing access to a communications network |
| US20010047404A1 (en) * | 2000-05-24 | 2001-11-29 | Takashi Suda | Apparatus for managing web site addresses |
| US7580996B1 (en) * | 2000-05-31 | 2009-08-25 | International Business Machines Corporation | Method and system for dynamic update of an application monitoring agent using a non-polling mechanism |
| AU2001278873A1 (en) * | 2000-07-06 | 2002-01-21 | Broadbeam Corporation | System and method for the remote creation of notification agents for wireless devices |
| US9252955B2 (en) * | 2000-08-18 | 2016-02-02 | United States Postal Service | Apparatus and methods for the secure transfer of electronic data |
| US7302582B2 (en) * | 2000-08-21 | 2007-11-27 | United States Postal Service | Delivery point validation system |
| JP2007249994A (ja) * | 2000-10-23 | 2007-09-27 | Fujitsu Ltd | アクセス誘導方法及び装置、コンピュータプログラム並びに記憶媒体 |
| US20020069250A1 (en) * | 2000-12-06 | 2002-06-06 | Sedta Boorananut | Electronic specification change awareness method and system |
| JP2002175213A (ja) * | 2000-12-06 | 2002-06-21 | Nec Mobiling Ltd | Ｗｅｂページ自動更新チェックサービスシステム及びＷｅｂページ自動更新チェックサービス方法 |
| JP2002236626A (ja) * | 2000-12-06 | 2002-08-23 | Site Rock Corp | サイト監視方法、および、サイト監視システム |
| JP3313359B2 (ja) * | 2001-01-23 | 2002-08-12 | 松下電送システム株式会社 | 複合機及びステータス通知方法 |
| US6950820B2 (en) * | 2001-02-23 | 2005-09-27 | International Business Machines Corporation | Maintaining consistency of a global resource in a distributed peer process environment |
| US7555561B2 (en) * | 2001-03-19 | 2009-06-30 | The Aerospace Corporation | Cooperative adaptive web caching routing and forwarding web content data broadcasting method |
| JP4294912B2 (ja) * | 2001-08-13 | 2009-07-15 | ブラザー工業株式会社 | 端末情報通知システム、端末情報通知方法及びネットワーク端末装置 |
| US20030084095A1 (en) * | 2001-10-26 | 2003-05-01 | Hayden Douglas Todd | Method to preserve web page links using registration and notification |
| US20030135618A1 (en) * | 2002-01-17 | 2003-07-17 | Ravikumar Pisupati | Computer network for providing services and a method of providing services with a computer network |
| CA2476865A1 (en) * | 2002-02-22 | 2003-09-04 | Iplocks, Inc. | Method and apparatus for monitoring a database system |
| JP4206673B2 (ja) * | 2002-03-04 | 2009-01-14 | セイコーエプソン株式会社 | 画像または音声の入出力制御 |
| AU2003213722A1 (en) * | 2002-03-21 | 2003-10-08 | David J. Payne | Method and system for storing and retrieving data using hash-accessed multiple data stores |
| US7664731B2 (en) * | 2002-03-21 | 2010-02-16 | United States Postal Service | Method and system for storing and retrieving data using hash-accessed multiple data stores |
| US7010576B2 (en) * | 2002-05-30 | 2006-03-07 | International Business Machines Corporation | Efficient method of globalization and synchronization of distributed resources in distributed peer data processing environments |
| AU2003245447B2 (en) * | 2002-09-06 | 2009-08-27 | United States Postal Service | Method and system for efficiently retrieving secured data by securely pre-processing provided access information |
| US7159119B2 (en) * | 2002-09-06 | 2007-01-02 | United States Postal Service | Method and system for efficiently retrieving secured data by securely pre-processing provided access information |
| US7219143B1 (en) * | 2002-12-04 | 2007-05-15 | Unisys Corporation | Automatic notification using specific log file for environmental condition via FTP server |
| US7890427B1 (en) * | 2003-01-09 | 2011-02-15 | Hewlett-Packard Development Company, L.P. | Authentication of notifications received in an electronic device in a mobile services network |
| US7953860B2 (en) | 2003-08-14 | 2011-05-31 | Oracle International Corporation | Fast reorganization of connections in response to an event in a clustered computing system |
| US7747717B2 (en) * | 2003-08-14 | 2010-06-29 | Oracle International Corporation | Fast application notification in a clustered computing system |
| US7664847B2 (en) | 2003-08-14 | 2010-02-16 | Oracle International Corporation | Managing workload by service |
| US8365193B2 (en) | 2003-08-14 | 2013-01-29 | Oracle International Corporation | Recoverable asynchronous message driven processing in a multi-node system |
| US20060064400A1 (en) * | 2004-09-21 | 2006-03-23 | Oracle International Corporation, A California Corporation | Methods, systems and software for identifying and managing database work |
| US7904895B1 (en) | 2004-04-21 | 2011-03-08 | Hewlett-Packard Develpment Company, L.P. | Firmware update in electronic devices employing update agent in a flash memory card |
| US8526940B1 (en) | 2004-08-17 | 2013-09-03 | Palm, Inc. | Centralized rules repository for smart phone customer care |
| US7801925B2 (en) * | 2004-12-22 | 2010-09-21 | United States Postal Service | System and method for electronically processing address information |
| US7779418B2 (en) * | 2004-12-30 | 2010-08-17 | Oracle International Corporation | Publisher flow control and bounded guaranteed delivery for message queues |
| US7818386B2 (en) * | 2004-12-30 | 2010-10-19 | Oracle International Corporation | Repeatable message streams for message queues in distributed systems |
| US20060200469A1 (en) * | 2005-03-02 | 2006-09-07 | Lakshminarayanan Chidambaran | Global session identifiers in a multi-node system |
| US20060224719A1 (en) * | 2005-03-30 | 2006-10-05 | Integrated Informatics, Inc. | Operator simulator and non-invasive interface engine |
| US8165909B2 (en) | 2005-05-17 | 2012-04-24 | The United States Postal Service | System and method for automated management of an address database |
| US20060282318A1 (en) * | 2005-06-10 | 2006-12-14 | Emergency 24, Inc. | Method of suspending an internet advertising campaign for an advertised web site when the web site is inaccessible |
| US8196150B2 (en) * | 2005-10-07 | 2012-06-05 | Oracle International Corporation | Event locality using queue services |
| US7526409B2 (en) | 2005-10-07 | 2009-04-28 | Oracle International Corporation | Automatic performance statistical comparison between two periods |
| US8230487B2 (en) | 2005-12-21 | 2012-07-24 | International Business Machines Corporation | Method and system for controlling access to a secondary system |
| JP5000999B2 (ja) * | 2006-02-08 | 2012-08-15 | 美恵子 露崎 | 情報更新システム及び情報取得システム |
| WO2007146710A2 (en) | 2006-06-08 | 2007-12-21 | Hewlett-Packard Development Company, L.P. | Device management in a network |
| WO2008014454A2 (en) | 2006-07-27 | 2008-01-31 | Hewlett-Packard Development Company, L.P. | User experience and dependency management in a mobile device |
| US7606752B2 (en) | 2006-09-07 | 2009-10-20 | Yodlee Inc. | Host exchange in bill paying services |
| JP2008176376A (ja) * | 2007-01-16 | 2008-07-31 | Kddi Corp | データ管理システムおよびデータ管理装置 |
| JP4391536B2 (ja) * | 2007-02-27 | 2009-12-24 | 富士通株式会社 | 通信装置制御プログラム、通信装置 |
| US9027025B2 (en) | 2007-04-17 | 2015-05-05 | Oracle International Corporation | Real-time database exception monitoring tool using instance eviction data |
| JP2009129017A (ja) * | 2007-11-20 | 2009-06-11 | Ricoh Co Ltd | 文書移行支援システム、監視装置、文書移行支援装置、方法、およびプログラム |
| JP5684447B2 (ja) * | 2008-03-21 | 2015-03-11 | 株式会社三共 | サーバシステム |
| US8261334B2 (en) | 2008-04-25 | 2012-09-04 | Yodlee Inc. | System for performing web authentication of a user by proxy |
| EP2141860B1 (en) * | 2008-07-04 | 2016-02-24 | Alcatel Lucent | Method for monitoring events in a communication network |
| US9128895B2 (en) | 2009-02-19 | 2015-09-08 | Oracle International Corporation | Intelligent flood control management |
| US8555359B2 (en) | 2009-02-26 | 2013-10-08 | Yodlee, Inc. | System and methods for automatically accessing a web site on behalf of a client |
| US8238538B2 (en) | 2009-05-28 | 2012-08-07 | Comcast Cable Communications, Llc | Stateful home phone service |
| US9165086B2 (en) | 2010-01-20 | 2015-10-20 | Oracle International Corporation | Hybrid binary XML storage model for efficient XML processing |
| JP5454201B2 (ja) * | 2010-02-15 | 2014-03-26 | 富士通株式会社 | データストア切替装置、データストア切替方法およびデータストア切替プログラム |
| US8458530B2 (en) | 2010-09-21 | 2013-06-04 | Oracle International Corporation | Continuous system health indicator for managing computer system alerts |
| US9697238B2 (en) | 2012-03-01 | 2017-07-04 | Microsoft Technology Licensing, Llc | Drift detection and notification |
| US20130346589A1 (en) * | 2012-06-21 | 2013-12-26 | Microsoft Corporation | Notification-based monitoring of web resources |
| JP6179321B2 (ja) * | 2013-09-27 | 2017-08-16 | 富士通株式会社 | ストレージ管理装置、制御方法及び制御プログラム |
| JP6273966B2 (ja) | 2014-03-27 | 2018-02-07 | 富士通株式会社 | ストレージ管理装置、性能調整方法及び性能調整プログラム |
| US9449346B1 (en) | 2014-05-21 | 2016-09-20 | Plaid Technologies, Inc. | System and method for programmatically accessing financial data |
| US9595023B1 (en) | 2014-05-21 | 2017-03-14 | Plaid Technologies, Inc. | System and method for facilitating programmatic verification of transactions |
| US10104059B2 (en) | 2015-09-08 | 2018-10-16 | Plaid Technologies, Inc. | Secure permissioning of access to user accounts, including secure deauthorization of access to user accounts |
| US10726491B1 (en) | 2015-12-28 | 2020-07-28 | Plaid Inc. | Parameter-based computer evaluation of user accounts based on user account data stored in one or more databases |
| US10984468B1 (en) | 2016-01-06 | 2021-04-20 | Plaid Inc. | Systems and methods for estimating past and prospective attribute values associated with a user account |
| EP3482554B1 (en) * | 2016-07-08 | 2021-07-07 | Convida Wireless, LLC | Methods and servers to monitor resources through http/2 |
| US10540217B2 (en) | 2016-09-16 | 2020-01-21 | Oracle International Corporation | Message cache sizing |
| US10474653B2 (en) | 2016-09-30 | 2019-11-12 | Oracle International Corporation | Flexible in-memory column store placement |
| US11468085B2 (en) | 2017-07-22 | 2022-10-11 | Plaid Inc. | Browser-based aggregation |
| US10878421B2 (en) | 2017-07-22 | 2020-12-29 | Plaid Inc. | Data verified deposits |
| US11316862B1 (en) | 2018-09-14 | 2022-04-26 | Plaid Inc. | Secure authorization of access to user accounts by one or more authorization mechanisms |
| US11887069B2 (en) | 2020-05-05 | 2024-01-30 | Plaid Inc. | Secure updating of allocations to user accounts |
| US11327960B1 (en) | 2020-10-16 | 2022-05-10 | Plaid Inc. | Systems and methods for data parsing |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS6267950A (ja) * | 1985-09-19 | 1987-03-27 | Toshiba Corp | フアクシミリ伝送方式 |
| JPH0713888A (ja) * | 1993-02-18 | 1995-01-17 | Matsushita Electric Ind Co Ltd | 電子掲示板 |
| JP2713325B2 (ja) * | 1993-02-24 | 1998-02-16 | 日本電信電話株式会社 | 管理情報分配収集方式 |
| US5603031A (en) * | 1993-07-08 | 1997-02-11 | General Magic, Inc. | System and method for distributed computation based upon the movement, execution, and interaction of processes in a network |
| JPH0744482A (ja) * | 1993-07-30 | 1995-02-14 | Fuji Xerox Co Ltd | サーバ状態管理システム |
| JPH08242229A (ja) * | 1995-03-01 | 1996-09-17 | Fujitsu Ltd | ネットワーク監視における状態整合処理システム |
| US5678041A (en) * | 1995-06-06 | 1997-10-14 | At&T | System and method for restricting user access rights on the internet based on rating information stored in a relational database |
| JPH0991232A (ja) * | 1995-09-27 | 1997-04-04 | Nippon Telegr & Teleph Corp <Ntt> | リソース変更通知方法 |
| JP2814965B2 (ja) * | 1995-09-29 | 1998-10-27 | 日本電気株式会社 | サーバアクセス装置 |
-
1995
- 1995-12-26 JP JP33968795A patent/JP3935986B2/ja not_active Expired - Fee Related
-
1996
- 1996-11-05 US US08/744,310 patent/US5933604A/en not_active Expired - Lifetime
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2020231396A1 (en) * | 2019-05-13 | 2020-11-19 | Hewlett-Packard Development Company, L.P. | Data monitoring |
Also Published As
| Publication number | Publication date |
|---|---|
| JPH09181723A (ja) | 1997-07-11 |
| US5933604A (en) | 1999-08-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3935986B2 (ja) | ネットワークにおける情報資源の変化を通知するネットワーク情報資源監視システム | |
| US20080104258A1 (en) | System and method for dynamic data discovery in service oriented networks with peer-to-peer based communication | |
| US7277914B2 (en) | Proxy server apparatus and method for providing service using the same | |
| KR101161520B1 (ko) | 알림 전달 아키텍처를 위한 방법 및 시스템 | |
| CA2457511C (en) | Method, apparatus, and user interface for managing electronic mail and alert messages | |
| US7277896B2 (en) | File sharing system and client apparatus | |
| KR100465582B1 (ko) | 네트워크를 통한 이벤트-트리거 통지 | |
| US6944658B1 (en) | Content notification method, product, and apparatus | |
| US8069246B2 (en) | Relay server and relay communication system including a relay group information registration unit, a shared resource information registration unit, and a control unit | |
| US7376730B2 (en) | Method for characterizing and directing real-time website usage | |
| US10637910B1 (en) | Method for dynamically generating information objects based on a restful subscription request | |
| US20030163552A1 (en) | Document distribution and storagre system | |
| KR19980041908A (ko) | 컴퓨터화된 자원 명칭 도출 메카니즘 | |
| JP2006185409A (ja) | 代行処理システム及び代行処理方法 | |
| US10326859B2 (en) | Internet-wide scheduling of transactions | |
| JPH1115716A (ja) | 文書更新通知装置および文書更新通知方法 | |
| CN100580665C (zh) | 对文件共享应用的索引服务器支持的方法及索引服务器 | |
| JP2005500741A (ja) | ペイロード検査を介したパケット・ルート付け、及び発行−申し込みネットワークにおける申し込み処理 | |
| JP4689867B2 (ja) | サーバシステム，クライアントシステムおよび差分更新システムならびに差分更新プログラム | |
| US20060123107A1 (en) | Web link management systems and methods | |
| JP2000089996A (ja) | 情報処理装置およびデータベースシステム | |
| JP2000122912A (ja) | 資源収集方法及び資源収集装置 | |
| JP2003271647A (ja) | 閲覧ファイルデータ提供方法、閲覧頻度データ提供方法、そのための中継装置、プログラム及び記録媒体 | |
| JPH11259354A (ja) | インターネット上の情報更新確認方法 | |
| JP4893712B2 (ja) | ウェブサービスシステム及びウェブサービス提供方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20031215 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040106 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040305 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040713 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040913 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20041214 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050210 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20050216 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20050408 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070322 |
|
| 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: 20100330 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110330 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110330 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120330 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130330 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130330 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140330 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |