【事件の表示】
　平成１１年特許願第２２７０５７号「情報配信システム及びその配信方法並びに配信サーバ」拒絶査定不服審判事件〔平成１３年　２月２３日出願公開、特開２００１−　５１９２８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１１年８月１１日の出願であって、 平成１６年６月３０日付けで拒絶査定がされ、これに対し、平成１６年８月５日に拒絶査定不服審判が請求されるとともに、同日付けで手続補正がなされたものである。
　
　
２．平成１６年８月５日付けの手続補正についての補正却下の決定
　
　［補正却下の決定の結論］
　
　　平成１６年８月５日付けの手続補正（以下、「本件補正」という。）を却下する。
　
　［理由］
　
　（１）補正後の本願発明
　
　本件補正により、特許請求の範囲の請求項１は、
　
　「情報端末と配信サーバとが第１ネットワークを介して接続され、かつ前記配信サーバと１個または複数個のコンテンツサーバとが第２ネットワークを介して接続され、前記情報端末にて選択された前記コンテンツサーバの有するコンテンツが前記配信サーバを介して前記情報端末へ配信される情報配信システムであって、
　前記配信サーバは前記情報端末がアクセスした前記コンテンツを監視対象コンテンツとして特定し、各コンテンツサーバが有する当該監視対象コンテンツの更新を確認し、更新された当該監視対象コンテンツのリストを前記情報端末に送信する更新確認手段を含むことを特徴とする情報配信システム。」と補正された。
　
　上記補正は、本件補正前の請求項１に係る発明を特定するために必要な事項である「配信サーバ」について、「前記配信サーバは前記情報端末がアクセスした前記コンテンツを監視対象コンテンツとして特定し」との限定を付加し、同じく「コンテンツのリスト」について「監視対象コンテンツのリスト」との限定を付加するものであって、特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　
　そこで、本件補正後の前記請求項１に係る発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）について以下に検討する。
　
　（２）引用刊行物
　
　特開平９−１８１７２３号公報（原査定において慣用技術として引用された。以下、「引用刊行物１」という。）には、図面と共に、
　
「【請求項１】　複数の発信源から発信された情報が流れる通信ネットワーク上の情報処理システムにおいて、
　ユーザからの依頼に基づいて、前記通信ネットワーク上の資源の状態を監視する監視手段と、
　前記資源の状態に変化があったことを示す変化情報を出力する出力手段とを備えることを特徴とするネットワーク資源監視システム。
【請求項２】　前記変化情報を受け取って前記ユーザに通知する通知手段をさらに備えることを特徴とする請求項１記載のネットワーク資源監視システム。
【請求項３】　前記監視手段および出力手段は、前記通信ネットワークを用いて比較的低コストで前記資源にアクセスできる第１の場所に配置され、前記通知手段は、前記ユーザの情報端末に前記変化情報を提供できる第２の場所に配置されることを特徴とする請求項２記載のネットワーク資源監視システム。
【請求項４】　前記出力手段は、前記通知手段のアドレス情報を前記変化情報の出力先として格納するデータベース手段を備えることを特徴とする請求項２記載のネットワーク資源監視システム。
【請求項５】　前記通知手段は、通知先への通知方法に応じたエージェントプロセスを用いて、前記変化情報を前記ユーザに通知することを特徴とする請求項２記載のネットワーク資源監視システム。
【請求項６】　前記監視手段は、複数のユーザからの依頼に基づき、該複数のユーザを代表して前記資源の状態を監視することを特徴とする請求項１記載のネットワーク資源監視システム。
【請求項７】　前記監視手段は、エージェントプロセスを用いて前記資源の状態を監視することを特徴とする請求項６記載のネットワーク資源監視システム。
【請求項８】　前記監視手段は、前記通信ネットワーク上の資源を統一的に記述する識別情報であって、監視対象の資源に対応する該識別情報を受け取り、該識別情報により指定された該監視対象の資源を監視することを特徴とする請求項１記載のネットワーク資源監視システム。
【請求項９】　前記監視手段は、前記識別情報として監視先ＵＲＬ（uniform resource locator）を受け取り、該監視先ＵＲＬの資源を監視することにより、ユーザへの通知機能から監視機能を分離することを特徴とする請求項８記載のネットワーク資源監視システム。
【請求項１０】　複数の発信源から発信された情報が流れる通信ネットワーク上の情報処理システムにおいて、
　前記通信ネットワーク上の資源の状態の監視を依頼する監視依頼をユーザから受け取り、該資源の状態に変化があった時の通知先を管理する管理手段と、
　前記資源の状態に変化があったことを示す変化情報を、前記通知先に通知する通知手段と
　を備えることを特徴とするネットワーク資源監視システム。
【請求項１１】　前記通知手段は、前記ユーザが前記資源の変化後の状態を参照できるように、前記変化情報に含まれる該資源の識別情報を前記通知先のユーザ端末に表示させることを特徴とする請求項１０記載のネットワーク資源監視システム。
【請求項１２】　前記通知手段は、前記通知先への通知方法に応じたエージェントプロセスを用いて、前記変化情報を通知することを特徴とする請求項１０記載のネットワーク資源監視システム。
【請求項１３】　複数の発信源から発信された情報が流れる通信ネットワーク上の情報処理システムにおいて、
　前記通信ネットワーク上の資源の状態の監視を依頼する監視依頼を入力する入力インタフェース手段と、
　前記資源の状態に変化があったことを示す変化情報を受け取る通知インタフェース手段と
　を備えることを特徴とする情報処理端末。
【請求項１４】　前記通知インタフェース手段は、ユーザが前記資源の変化後の状態を参照できるように、前記変化情報に含まれる該資源の識別情報を表示することを特徴とする請求項１３記載の情報処理端末。
【請求項１５】　計算機により使用された時、
　ユーザからの依頼に基づいて、通信ネットワーク上の資源の状態を監視する機能と、
　前記資源の状態に変化があったことを示す変化情報を出力する機能と
を前記計算機に行わせることを特徴とする読み出し可能媒体。
【請求項１６】　計算機により使用された時、
　通信ネットワーク上の資源の状態の監視を依頼する監視依頼をユーザからを受け取り、該資源の状態に変化があった時の通知先を管理する機能と、
　前記資源の状態に変化があったことを示す変化情報を、前記通知先に通知する機能と
　を前記計算機に行わせることを特徴とする読み出し可能媒体。
【請求項１７】　計算機により使用された時、
　通信ネットワーク上の資源の状態の監視を依頼する監視依頼を入力する機能と、
　前記資源の状態に変化があったことを示す変化情報を受け取る機能とを前記計算機に行わせることを特徴とする読み出し可能媒体。
【請求項１８】　ユーザからの依頼に基づいて、前記通信ネットワーク上の資源の状態を監視し、
　前記資源の状態に変化があった時、該変化があったことを示す変化情報を出力する　ことを特徴とするネットワーク資源監視方法。
【請求項１９】　通信ネットワーク上の資源の状態の監視を依頼する監視依頼をユーザからを受け取り、
　前記資源の状態に変化があった時の通知先を管理し、
　前記資源の状態に変化があった時、該変化があったことを示す変化情報を前記通知先に通知する
　ことを特徴とするネットワーク資源監視方法。
【請求項２０】　通信ネットワーク上の資源の状態の監視を依頼する監視依頼を送り、
　前記資源の状態に変化があったことを示す変化情報を受け取り、
　該変化情報に基づいて前記資源の変化後の状態を参照することを特徴とする資源参照方法。」（【特許請求の範囲】）
　
「【０００７】もし、何等かの方法でユーザが既知の情報資源の変更を知ることができれば、チェックのために何度も再アクセスする手間が省ける。したがって、新しい情報発掘のために多くの時間をさくことができるという大きなメリットがある。しかし、従来は、受信者側の立場に立ったこのような変更通知サービスは存在しない。
【０００８】本発明は、通信ネットワーク上の情報の変化をユーザに代わって監視することによりユーザのアクセス回数を削減し、ネットワークの負荷を低減することの可能なネットワーク資源監視システムおよびその方法を提供することを目的とする。
【０００９】
【課題を解決するための手段】図１は、本発明のネットワーク資源監視システムの原理図である。図１のネットワーク資源監視システムは、監視手段１、出力手段２、通知手段３、および管理手段４を備え、通信ネットワーク５上の情報資源６を監視する。
【００１０】監視手段１は、ユーザからの依頼に基づいて、通信ネットワーク５上の資源６の状態を監視する。そして、出力手段２は、資源６の状態に変化があったことを示す変化情報を出力する。
【００１１】資源６は、例えばインターネット上のホームページのように、発信者が作成して発信する画像情報やテキスト情報等であり、発信者により更新されることがある。通信ネットワーク５上のどの資源を監視対象とするかは、ユーザにより依頼時に指定される。ユーザからの監視依頼は、例えば管理手段４から監視手段１に送られる。
【００１２】監視手段１は、例えば定期的に資源６にアクセスしてその状態を調べ、更新されたことが分かると、資源６の状態が変化したことを出力手段２に伝える。これを受けて、出力手段２は、資源６の識別情報等を含む変化情報を通信ネットワーク５に出力する。
【００１３】この変化情報は、通信ネットワーク５を介して例えば通知手段３に送られ、最終的にユーザに通知される。これにより、ユーザは指定した資源６の情報が更新されたことを知ることができる。
【００１４】この構成によれば、監視手段１がユーザに代わって資源６を監視するので、ユーザが自ら資源６にアクセスする必要がなくなる。したがって、資源６へのユーザのアクセス回数を最小限に抑えることが可能になる。監視手段１は、１人のユーザの代理を果たすだけでなく、複数のユーザを代表して資源６を監視することもできる。
【００１５】また、監視手段１および出力手段２を通信ネットワーク５上で資源６に近い場所に配置すれば、監視に伴う通信コストが低く抑えられるため、ネットワークの
負荷を低減することも可能になる。
【００１６】また、管理手段４は、通信ネットワーク５上の資源６の状態の監視を依頼する監視依頼をユーザから受け取り、資源６の状態に変化があった時の通知先を管理する。
【００１７】そして、通知手段３は、資源６の状態に変化があったことを示す変化情報を、上記通知先に通知する。ユーザからの監視依頼は、例えば監視対象の資源６を指定する識別情報と、変化情報の通知先とを含んでおり、通信ネットワーク５を介して管理手段４に送られる。監視依頼の送信には電子メール等が用いられ、通知先としてはユーザの電子メールアドレス等が指定される。
【００１８】管理手段４は、例えばデータベース等の記憶装置に、資源６の識別情報と通知先とを対応付けて格納しておく。通知手段３は、通信ネットワーク５から変化情報を受け取ると、変化のあった資源６に対応する通知先を管理手段４に問い合せ、その通知先に変化情報を送る。
【００１９】通知先がユーザの電子メールアドレスの場合は、資源６の識別情報を含むメールがユーザの端末に送られる。これにより、ユーザは指定した資源６の情報が更新されたことを知る。
【００２０】この構成によれば、管理手段４が変化情報の通知先を管理するので、資源６が更新されたことが自動的にユーザに通知される。このため、ユーザは自ら資源６にアクセスする必要がなくなり、資源６へのユーザのアクセス回数を最小限に抑えることが可能になる。また、資源６の監視を依頼したユーザが複数いる場合は、それらのすべてのユーザに変化情報が通知される。
【００２１】図１の構成において、監視手段１および出力手段２を通信ネットワーク５上で資源６に近い場所に配置し、通知手段３および管理手段４をユーザの端末に近い抑えることができる。したがって、ネットワークの負荷が低減される。
【００２２】例えば、図１の監視手段１と出力手段２は、実施形態の図２におけるＵＲＬ監視システム１３に対応し、通知手段３と管理手段４は通知手段管理システム１２に対応する。」（第３頁第３欄第４８行〜第４頁第５欄第３４行）
　
「【００２７】図２は、このようなネットワーク資源監視システムの構成図である。図２のネットワーク資源監視システムは、監視要求入力インタフェース１０、通知インタフェース１１、通知手段管理システム１２、およびＵＲＬ監視システム１３を備える。そして、ユーザから指定された特定のＵＲＬの資源を監視し、その変化をユーザに通知する。監視要求入力インタフェース１０および通知インタフェース１１としては、例えば、ＷＥＢブラウザ端末、Ｅ−ｍａｉｌ端末、ＰＤＡなどが用いられる。
【００２８】監視要求入力インタフェース１０は、ユーザから入力された監視対象のＵＲＬと通知手段とを、監視要求とともに通知手段管理システム１２に伝える。通知手段管理システム１２は、例えばインターネットへの接続サービスを行うプロバイダのサーバであり、監視要求をＵＲＬ監視システム１３に伝える。ＵＲＬ監視システム１３は指定されたＵＲＬの資源１４の状態を監視し、それが変化した時直ちに、その情報を通知手段管理システム１２に知らせる。
【００２９】通知手段管理システム１２は、通知インタフェース１１に対して監視結果を通知する通知手段を管理しており、ＵＲＬ監視システム１３から受け取った情報を、対応する通知手段により通知インタフェース１１に通知する。これにより、ユーザは資源１４の状態に変化があったことを知り、その資源１４にアクセスして変化した情報を得ることができる。
【００３０】図２のネットワーク資源監視システムにおいて、ＵＲＬ監視システム１３はＵＲＬで一般化された世界に属し、システムのバックボーンとして動作する。そして、通知手段管理システム１２は、インタフェース依存性のある世界と一般化された世界の境界上に位置し、バックボーンからの更新情報を元にした監視サービスを展開することが可能である。各サービスプロバイダはバックボーンのプロトコルを公開し、ユーザに対する各通知手段をサポートした監視サービスを展開する。」（第４頁第６欄第１９行〜第５頁第７欄第３行）
　
「【００３５】ところで、資源１４の監視においては、それを定期的にアクセスすることが必要なため、通信のためのコストが非常に高くなることが予想される。前述したように、この傾向は、ネットワーク的に遠い資源の監視をする場合に特に顕著となる。したがって、世界的な規模を持つインターネットの場合、ネットワークの負荷が著しく増大する可能性がある。
【００３６】そこで、ＵＲＬを監視するバックボーンでは、デリゲーション（delegation）を有効に使うことを考える。デリゲーションは、インターネットに接続された個々のネットワークを保護するためのアクセス制限であるファイアウォールの構築でよく使われた手法である。
【００３７】多くの場合、ローカルネットワークはゲートウェイを介してインターネットに接続され、ゲートウェイに収容された処理装置が外部からのアクセスを制限する。この場合、ゲートウェイの処理装置は、ローカルネットワーク内の各情報処理装置を代表して、外部からのアクセスを制御している。このような手法がデリゲーションと呼ばれる。
【００３８】以下の実施形態では、このデリゲーションをネットワーク負荷の低減のために転用し、ＵＲＬ監視システム１３をデリゲーション・バックボーンとする。ＵＲＬ監視システム１３は、個々のユーザを代表して資源１４を監視する機能を持つ。これにより、各ユーザが資源１４をチェックするために頻繁にアクセスする必要がなくなり、ネットワーク負荷を減少させることができる。
【００３９】このようなデリゲーションシステムは、監視資源をＵＲＬで一般化したことによって、より現実的なものになる。もし一般化されていなければ、多様なプロトコルで管理された資源に応じて、多数のデリゲーションシステムを用意しなければならなくなるが、ＵＲＬで監視する場合は、１つのデリゲーションシステムで対応可能である。」（第５頁第７欄第２９行〜同頁第８欄第１３行）
　
「【００４０】また、図２のネットワーク資源監視システム内における情報の伝達は任意の通信処理により実現可能であるが、本実施形態では、一例としてリモートプログラミングに基づく言語であるテレスクリプト（Telescript）による方法を用いることにする。
【００４１】テレスクリプトによるリモートプログラミングにおいては、データを保持するプロセスの一種であるエージェント（Agent ）が用いられる。この場合には、各ユーザの監視要求情報を各エージェントに持たせることが可能であるため、複数のユーザの要求を独立に処理することができる。さらに、エージェントは自律的に機能して、処理が終了すれば自動的に消滅するため、不特定多数のユーザが利用するネットワーク上の処理に適している。
【００４２】テレスクリプトによるリモートプログラミングについては、「リモートプログラミングの実施方法」（特願平６−１７９７６７、特開平７−１８２１７４）に詳述されているが、ここでその手法について説明する。
【００４３】このリモートプログラミングは、複数の計算機システムを結ぶ通信ネットワーク上での処理を記述する方法の一種で、ネットワークを渡り歩く移動可能なプロセスであるエージェントと、エージェントが入ってくる固定プロセスであるプレイス（Place ）により実現される。
【００４４】図４は、プレイスの構成を示している。プレイスは、他のプロセスと識別可能なテレネーム（telename）を持ち、任意有限個の子プロセスを持つことができる。また、プレイスは、自己および他のプロセスより参照可能な任意有限個のデータと、自己および他のプロセスより呼出し可能な任意有限個の手続きとを有する。
【００４５】さらに、メインルーチンとして手続きliveを持ち、作成されたプレイスはｌｉｖｅを実行する。プレイスは、ｌｉｖｅが実行されている間だけ存在し、ｌｉｖｅが終了すると消滅する。プレイスが消滅すると、その子プロセスも終了し、消滅する。
【００４６】図５は、エージェントの構成を示している。エージェントは、他のプロセスと識別可能なテレネームを持ち、あるプレイスの中の子プロセスとしてのみ存在する。また、エージェントは、自己および他のプロセスより参照可能な任意有限個のデータと、自己および他のプロセスより呼出し可能な任意有限個の手続きとを有する。
【００４７】さらに、メインルーチンとして手続きｌｉｖｅを持ち、作成されたエージェントはｌｉｖｅを実行する。エージェントは、ｌｉｖｅが実行されている間だけ存在し、ｌｉｖｅが終了すると消滅する。エージェントの手続きｌｉｖｅの中でコマンドｇｏが実行されると、そのエージェントはネットワークを介して指定された行き先へ移動する。
【００４８】図６は、コマンドｇｏによるオペレーションの例を示している。図６において、プレイス２１内のエージェント２２は、ｇｏの実行により、行き先のプレイス２４を指定するデータであるチケット（Ticket）２３を得て、指定されたプレイス２４に移動する。
【００４９】このとき、エージェント２２は、ｇｏによりｌｉｖｅの実行を一時中断し、保持したデータとともに凍結（圧縮）され、パック化される。そして、チケット２３に示されたプレイス２４に送られ、プレイス２４により受け入れをチェックされる。プレイス２４に受け入れられると、その中に子プロセスとして置かれた後、解凍（伸張）され、ｇｏの次のコマンドからｌｉｖｅの実行を再開する。
【００５０】また、エージェントは、手続きｌｉｖｅの中で自己の置かれているプレイス内にある他のエージェントを求めるコマンドｍｅｅｔを呼出すことができる。コマンドｍｅｅｔの実行時には、エージェントは相手のエージェントを指定するデータであるペティション（Petition）を用いる。
【００５１】図７は、コマンドｍｅｅｔによるオペレーションの例を示している。図７において、プレイス３１内のエージェント３２は、コマンドｍｅｅｔによりあるペティションを指定する。プレイス３１は、ペティションにより指定された条件に該当するエージェントを探す。そして、プレイス３１内に該当するエージェントがなければ、そのようなエージェントが入ってくるまで待つ。
【００５２】プレイス３１内のエージェント３３がペティションの条件に該当すれば、プレイス３１は、エージェント３２が相互作用を希望していることをエージェント３３に伝える。そして、エージェント３３がエージェント３２の希望を受け入れる旨の戻り値を返すと、プレイス３１は、エージェント３３へのポインタをｍｅｅｔの戻り値としてエージェント３２に返す。その後、エージェント３２は、エージェント３３へ直接アクセスして、情報交換等を行うことが可能になる。
【００５３】以下では、コマンドｇｏによりエージェントが移動することを単に「ｇｏする」と記述し、コマンドｍｅｅｔにより他のエージェントと相互作用を行うことを単に「ｍｅｅｔする」と記述する。」（第５頁第８欄第１４行〜第６頁第１０欄第３行）
　
「【００５４】図８は、上述のようなリモートプログラミングを用いたネットワーク資源監視システムの構成図である。図８において、監視サービスプレイス４６とデリゲートプレイス（delegate place）５１は、それぞれ決められた機能を有するプレイスであり、フォームエージェント（form agent）４８、監視エージェント５３、通知エージェント５４、５４′、リポートエージェント５５、５６、５７、５８は、それぞれ決められたデータと機能を有するエージェントである。
【００５５】Magic Cap ４１、ＭＵＡ（Mail User Agent ）４２、およびＷＥＢブラウザ４３は、図２の監視要求入力インタフェース１０に対応し、ユーザが監視要求を入力する際に用いる。これらの具体的な違いについては後述する。通知手段管理システム１２は、例えばプロバイダ毎に設けられ、監視データベース（ＤＢ）４７を備え、ユーザに監視サービスを提供する監視サービスプレイス４６を保持する。
【００５６】また、ＵＲＬ監視システム１３は、デリゲートデータベース（ＤＢ）５２を備え、ユーザに代わって資源を監視するためのデリゲートプレイス５１を保持する。監視に伴う通信コストの低減を図るため、このＵＲＬ監視システム１３は通信的に近いＵＲＬのグループ毎に設けられる。通信的に近いＵＲＬとは、比較的低い通信コストでアクセス可能なＵＲＬを意味する。例えば、インターネットに接続する各国毎に１つのＵＲＬ監視システム１３を設けてもよく、よりローカルな地域のサーバ毎に設けてもよい。
【００５７】通知手段管理システム１２とＵＲＬ監視システム１３は通信ネットワーク４９を介して接続され、情報交換を行うことができる。また、通信ネットワーク４９にはＵＲＬで識別される資源５０−１、５０−２、５０−３も接続されている。尚、接続される資源の数は任意である。以下では、このような資源のことを単に“ＵＲＬ”と記述することもある。
【００５８】監視要求が監視要求入力インタフェース１０に入力されると、監視サービスプレイス４６内にフォームエージェント４８が現れる。フォームエージェント４８は監視ＤＢ４７を更新した後、通信ネットワーク４９を介してデリゲートプレイス５１にｇｏし、デリゲートＤＢ５２を更新する。監視ＤＢ４７には、監視結果の通知先であるユーザのＵＲＬが格納され、デリゲートＤＢ５２には、通知先の監視サービスプレイス４６のアドレス情報が格納される。
【００５９】監視エージェント５３は、デリゲートＤＢ５２を参照して監視先ＵＲＬを監視し、それが更新されると通知エージェント５４を作成する。通知エージェント５４はコマンドｓｅｎｄを実行して、通知エージェント５４′を監視サービスプレイス４６に送る。
【００６０】ｓｅｎｄは、エージェントの手続きｌｉｖｅの中で実行され、そのエージェントの複製を作って他のプレイスに送るコマンドである。ここでは、通知エージェント５４′は、通知エージェント５４の分身（クローンエージェント）として生成される。
【００６１】通知エージェント５４′は、監視ＤＢ４７の通知先ＵＲＬに応じて、適したリポートエージェント５５、５６、５７、５８を作成する。リポートエージェント５５、５６、５７、５８は、それぞれの通知インタフェース１１の種類に応じた通知手段でユーザに結果を報告する。これらのリポートエージェントの処理の詳細については後述する。
【００６２】以上の構成により、ユーザは更新された監視先ＵＲＬの情報を自動的に通知されるので、ユーザ自身が資源のチェックを行う必要はなくなる。また、通知手段管理システム１２とＵＲＬ監視システム１３が分離して設けられ、監視先に近いＵＲＬ監視システム１３が複数のユーザを代表して、ＵＲＬを監視する。
【００６３】したがって、多数のユーザによる資源監視のための頻繁なアクセスをなくして、ネットワークの負荷を大幅に軽減することができる。次に、図９から図１４までを参照しながら、図８のネットワーク資源監視システムにおける具体的な処理について説明する。」（第６頁第１０欄第４行〜第７頁第１１欄第２４行）
　
「【００６４】ネットワーク資源監視システムに対する監視要求の発行は、各種のデバイスおよびプログラムから行うことができる。例えば、図８におけるＷＥＢブラウザ４３はハイパーテキストベースでインターネット上に分散配置された情報を探索するソフトウェアツールであり、ＭＵＡ４２はＥ−ｍａｉｌを発行するソフトウェアツールである。また、Magic Cap ４１はエージェントを利用したＰＤＡ端末の一種である。ＷＥＢブラウザ４３およびＭＵＡ４２は、ユーザの端末計算機内に収容されている。
【００６５】監視要求の出し方は、勿論、各デバイスおよびプログラムの種類によって異なるが、次の２つの条件を満たす必要がある。
（１）何等かの方法で、フォームエージェント４８を監視サービスプレイス４６上に作成すること。
（２）フォームエージェント４８には、次のデータを与えること。
【００６６】・監視先ＵＲＬ
・通知先ＵＲＬ
・依頼主ＩＤ、パスワード
・コメント
・備考データ
　視先ＵＲＬは監視対象の資源のＵＲＬであり、通知先ＵＲＬは監視結果を通知するＵＲＬであり、依頼主ＩＤおよびパスワードは依頼主の識別情報である。通知先ＵＲＬは、通常、依頼主ＩＤ毎に割り振られる。また、コメントと備考データは必ずしも必須ではなく、必要に応じて付加される。
【００６７】このように、監視入力インタフェースの形態に依らないフォームエージェント４８を作成することで、各種のプログラム等による監視要求を受け付けることが
可能になり、システムの拡張性が高まる。
【００６８】次に、監視要求の入力例について説明する。入力機器としては、マウス等のポインティングデバイスやキーボードが用いられる。ＷＥＢブラウザ４３を用いる場合、ユーザはまず監視依頼フォーム（Form）のＨＴＭＬ（hypertext markup language ）文書をｏｐｅｎし、そのフォームの空欄の穴うめをする。ＨＴＭＬとは他文書へのリンクを持つハイパーテキスト文書を記述する言語で、これにより記述された文書はＨＴＭＬ文書と呼ばれる。
【００６９】図９は、ユーザ端末のディスプレイ上に表示された監視依頼フォームの入力例を示している。図９の監視依頼フォーム７０において、ｌｏｏｋ　ＵＲＬ７１は監視先ＵＲＬを表し、Ｒｅｐｏｒｔ　ＵＲＬ７２は通知先ＵＲＬを表し、ＩＤ７３およびＰａｓｓｗｄ７４は、それぞれ依頼主ＩＤおよびパスワードを表す。これらの情報を入力した後、Ｃｏｎｆｉｒｍボタン７５をクリックすると、図８のＣＧＩ（computer graphics interface ）プロセス４５が起動される。
【００７０】ＣＧＩプロセス４５は、ＩＤ７３毎に決まったＨＴＭＬ文書７６をｏｐｅｎする。ＨＴＭＬ文書７６は、指定された監視対象の資源へのリンク（ＵＲＬ）のリストを表示するために用いられる。ここでは、指定された監視先ＵＲＬがＨＴＭＬ文書７６内にリンクとして書き込まれ、リンクのリストがディスプレイに表示される。
【００７１】次に、ＣＧＩプロセス４５は、クラウド（cloud ）との間にコネクションを確立する。クラウドとは、ネットワーク上でプログラム言語を解釈して実行するためのソフトウェア環境を表し、ここでは監視サービスプレイス４６に相当する。ＣＧＩプロセス４５は、確立されたコネクションを通じてプロセス間通信を行い、監視依頼フォーム７０に入力されたパラメータを監視サービスプレイス４６へ送る。
【００７２】そして、監視サービスプレイス４６は、送られたパラメータを元にフォームエージェント４８を作成する。また、監視要求入力インタフェース１０としてＭＵＡ４２を用いる場合は、ユーザは一定のフォーマットのＥ−ｍａｉｌ（コントロールメール：control mail）４４を監視サービスプレイス４６宛に送る。
【００７３】図１０は、ＭＵＡ４２により作成されるコントロールメール４４の例を示している。コントロールメール４４には、監視依頼フォーム７０と同様に、ｌｏｏｋ　ＵＲＬ（監視先ＵＲＬ）、Ｒｅｐｏｒｔ　ＵＲＬ（通知先ＵＲＬ）、ＩＤ、Ｐａｓｓｗｏｒｄ等の情報が記述される。
【００７４】監視サービスプレイス４６は、通知手段管理システム１２内に設けられたsendmailポートで通信をlistenしており、sendmailのプロトコルを認識することができる。そして、送られてきたコントロールメール４４を受信し、それをパース（parse ）して、メールの構成要素を分析する。次に、その結果を元にフォームエージェント４８を作成する。
【００７５】また、監視要求入力インタフェース１０としてMagic Cap ４１を用いる場合は、ユーザは専用のフォームでマジックメール（Magicmail ）を作成し、監視サービスプレイス４６へ送信する。マジックメールとは、メールの内容をデータとして持つエージェントが他の計算機等に移動することで、メッセージを伝えるメールの形態を指す。
【００７６】ここでは、マジックメールの送信処理により、Magic Cap ４１上で、監視先ＵＲＬ、通知先ＵＲＬ、依頼主ＩＤ、パスワード等のデータを持つフォームエージェント４８が生成される。そして、直接監視サービスプレイス４６へｇｏする。
【００７７】次に、このようにして作成されたフォームエージェント４８が行う処理を説明する。フォームエージェント４８は、監視ＤＢ４７に通知先ＵＲＬを登録し、デリゲートＤＢ５２に通知先プレイスのアドレスを登録して、結果を通知する際の経路を通知エージェント５４、５４′に伝える役割を果たす。このため、フォームエージェント４８は、監視ＤＢ４７とデリゲートＤＢ５２にレコードを追加したり、それらのレコードを変更したりする機能を持つ。
【００７８】図１１は、監視ＤＢ４７のデータ構造の例を示している。図１１において、ハッシュ表８１には、キー（key ）として用いられる監視先ＵＲＬ毎にレコードを指すポインタが格納されている。例えば、１番目の監視先ＵＲＬ“ｈｔｔｐ：／／〜”に対応するポインタはレコード８２−１を指しており、２番目の“ｆｔｐ：／／〜”に対応するポインタはレコード８２−２を指している。監視先ＵＲＬの中で、“ｈｔｔｐ：”や“ｆｔｐ：”は接続形態を表すプロトコル部に相当する。
【００７９】レコード８２−１および８２−２は、Ｔａｒｇｅｔ１、Ｔａｒｇｅｔ２、Ｔａｒｇｅｔ３の３つのエントリを持ち、これらのエントリはそれぞれ、最終更新履歴、通知先ＵＲＬのリストへのポインタ、備考データを表す。
【００８０】最終更新履歴は、監視先ＵＲＬの最終更新日時のタイムスタンプと更新後の情報のファイルサイズを含む。Ｔａｒｇｅｔ２のポインタが指すＵＲＬのリストの最後の（ｎｉｌ）は空白データを表し、リストの終端であることを示している。フォームエージェント４８が備考データを持っている場合、それはＴａｒｇｅｔ３として格納される。
【００８１】通知エージェント５４′は、この監視ＤＢ４７から監視先ＵＲＬをキーとして、監視先ＵＲＬの最終更新のタイムスタンプとファイルサイズ、および通知先ＵＲＬのリストを引くことができる。
【００８２】フォームエージェント４８は、持っている監視先ＵＲＬがハッシュ表８１の中にないとき、それをハッシュ表８１のエントリとして追加し、対応するレコードを登録する。このとき、タイムスタンプとしては登録時の日時を用い、ファイルサイズは０としておく。また、通知先ＵＲＬリストにはフォームエージェント４８が持つ通知先ＵＲＬを登録する。
【００８３】フォームエージェント４８の監視先ＵＲＬがハッシュ表８１の中にキーとして存在するときは、対応するレコードのエントリを変更する。ただし、タイムスタンプとファイルサイズは変更せず、通知先ＵＲＬリストにフォームエージェント４８の通知先ＵＲＬを追加する。」（第７頁第１１欄第２５行〜第８頁第１４欄第１７行）
　
「【００８４】その後、フォームエージェント４８はデリゲートプレイス５１へｇｏして、デリゲートＤＢ５２にレコードを追加したり、またはレコードを変更したりする。　図１２は、デリゲートＤＢ５２のデータ構造の例を示している。図１２において、ハッシュ表９１にはハッシュ表８１と同様に、監視先ＵＲＬ毎にポインタが格納されている。例えば、１番目の監視先ＵＲＬ“ｈｔｔｐ：／／〜”に対応するポインタはレコード９２−１を指しており、２番目の“ｆｔｐ：／／〜”に対応するポインタはレコード９２−２を指している。
【００８５】レコード９２−１および９２−２は、Ｔａｒｇｅｔ１、Ｔａｒｇｅｔ２、Ｔａｒｇｅｔ３の３つのエントリを持ち、Ｔａｒｇｅｔ１とＴａｒｇｅｔ２の内容は図１１の場合と同様である。
【００８６】Ｔａｒｇｅｔ２は通知先リストへのポインタを表し、各通知先としてはフォームエージェント４８を送り出した監視サービスプレイス４６のＴｅｌｅａｄｄｒｅｓｓとＷａｙが用いられる。ここで、Ｔｅｌｅａｄｄｒｅｓｓはプレイスを一意に識別する識別子であり、Ｗａｙはそのプレイスまでの移動方法を表す。これらの情報は、フォームエージェント４８のｇｏの返り値であるＴｉｃｋｅｔＳｔｕｂに記述されている。
【００８７】通知エージェント５４は、このデリゲートＤＢ５２から監視先ＵＲＬをキーとして、監視先ＵＲＬの最終更新のタイムスタンプとファイルサイズ、および通知先監視サービスプレイス４６のアドレスリストを引くことができる。
【００８８】また、デリゲートＤＢ５２は、フォームエージェント４８により監視ＤＢ４７と同様のレコードの追加、変更を受ける。ただし、通知先としては、通知先ＵＲＬではなく、フォームエージェント４８のＴｉｃｋｅｔＳｔｕｂの情報が用いられる。
【００８９】監視サービスプレイス４６は、監視要求の出し方および通知の方法から資源の監視方法を分離し、ＵＲＬで表現できる資源の監視という形態に一般化する役割を果たす。これにより、多様なユーザインタフェースを持つ複数のユーザを代表してＵＲＬを監視するサービスを提供することが可能になる。
【００９０】デリゲートプレイス５１は、監視先ＵＲＬの更新履歴をチェックして、その変化を監視するために設けられる。ユーザに対する通知方法等は、監視サービスプレイス４６により隠蔽されているので、デリゲートプレイス５１が関知する必要はない。
【００９１】監視エージェント５３はデリゲートプレイス５１内にあって、ＦＴＰプロトコルにより、デリゲートＤＢ５２内の監視先ＵＲＬのタイムスタンプおよびファイルサイズを定期的にチェックする。
【００９２】図１３は、監視エージェント５３が行う監視処理のフローチャートである。図１３において処理が開始されると、監視エージェント５３はループ処理を開始し（ステップＳ１）、デリゲートＤＢ５２のハッシュ表９１を用いて、次の監視先ＵＲＬに対応するレコードを取得する（ステップＳ２）。
【００９３】次に、取得したレコードのキーである監視先ＵＲＬへＦＴＰプロトコルによりconnect する（ステップＳ３）。そして、監視先ＵＲＬのタイムスタンプとファイルサイズを取得し（ステップＳ４）、それらをデリゲートＤＢ５２のレコードの対応するエントリと比較する（ステップＳ５）。ここで、監視先ＵＲＬのタイムスタンプやファイルサイズに変化があるかどうかが調べられる。
【００９４】両者のタイムスタンプやファイルサイズが異なり、監視先ＵＲＬに変更があると判断できる場合、通知エージェント５４をデリゲートプレイス５１上に作成し、デリゲートＤＢ５２のレコードを初期化引数として通知エージェント５４に渡す（ステップＳ６）。
【００９５】次に、ループ処理を終了するかどうか判定する（ステップＳ７）。この判定は、あらかじめ決められた適当な終了条件が成立するかどうかをチェックすることにより行われる。通常は終了条件が成立することはないので、ステップＳ２以降の処理を半永久的に繰り返す。また、ステップＳ５において監視先ＵＲＬに変更なしと判断できる場合も、ステップＳ２以降の処理を繰り返す。そして、ステップＳ７において終了条件が成立すれば、処理を終了する。
【００９６】図１３の監視処理においては、監視先ＵＲＬへＦＴＰ接続して更新情報（更新履歴）を取得する構成となっている。これ以外に、監視先ＵＲＬの管理者が更新情報を持たせた更新（Update）エージェントをデリゲートプレイス５１に送る方法を用いることもできる。この場合は、更新エージェントがデリゲートプレイス５１内で監視エージェント５３にｍｅｅｔし、更新情報を伝える。これにより、監視エージェント５３は、より積極的に監視先ＵＲＬから発信された更新情報を受け付けることになる。
【００９７】監視処理においては、その性質上何等かの方法で監視先ＵＲＬの更新情報を取得する必要があるので、監視先ＵＲＬとの定期的な通信が必要になる。このため、デリゲートプレイス５１からネットワーク的に近い所だけを監視対象にした方が効率がよい。
【００９８】デリゲートプレイス５１から遠い所を監視する場合は、監視先ＵＲＬの近くに、デリゲートプレイス５１等を代表する別のデリゲートプレイスを設けて、それに監視させることも考えられる。つまり、デリゲートのデリゲートを設けることになる。
【００９９】監視エージェント５３により作成された通知エージェント５４は、更新されたＵＲＬについて、デリゲートＤＢ５２および監視ＤＢ４７のレコードを変更する。
」（第８頁第１４欄第１８行〜第９頁第１６欄第１６行）
　
「【０１００】図１４は、通知エージェント５４の処理のフローチャートである。図１４において処理が開始されると、通知エージェント５４は、まず初期化引数として渡されたデリゲートＤＢ５２のレコードのタイムスタンプとファイルサイズを、監視先ＵＲＬのものに更新する（ステップＳ１１）。
【０１０１】次に、対応する通知先リストに格納されたＴｅｌｅａｄｄｒｅｓｓとＷａｙを用いてコマンドｓｅｎｄを実行し、各監視サービスプレイスに分身の通知エージェント５４′を送る（ステップＳ１２）。
【０１０２】通知エージェント５４′は最新の更新履歴のデータを持っており、例えば監視サービスプレイス４６に移動する。そして、監視ＤＢ４７内の対応するレコードのタイムスタンプとファイルサイズを最新のものに更新する（ステップＳ１３）。
【０１０３】次に、そのレコードの通知先ＵＲＬリストを参照し、各通知先ＵＲＬに適したリポートエージェントを作成し（ステップＳ１４）、処理を終了する。リポートエージェントのクラスは、通知の方法、すなわちＵＲＬに含まれるプロトコル部毎に異なっており、例えば次のようなものがある。ここで、クラスとはオブジェクトの構造の定義に相当する。
（ａ）プロトコル部が“ｍａｉｌｔｏ：”の場合は、そのクラスはＥ−ｍａｉｌによる通知方法を定義する。
（ｂ）プロトコル部が“ｈｔｔｐ：”の場合は、そのクラスはＨＴＭＬ文書のリンクリストのページを更新して通知する方法を定義する。
（ｃ）プロトコル部が“ｆｔｐ：”の場合は、そのクラスはファイルシステムのメンテナンス方法を定義する。
【０１０４】したがって、通知エージェント５４′は通知先ＵＲＬのプロトコル部を参照することで、作成すべきリポートエージェントのクラスを決定し、そのインスタンスを作成することができる。ここで、インスタンスとはクラスにより定義されたオブジェクトの具体例を意味し、今の場合はリポートエージェント５５、５６、５７、５８等を指す。」（第９頁第１６欄第１７行〜第１０頁第１７欄第２行）
　
「【０１０５】　次に、各クラスのリポートエージェントの処理について説明する。ｍａｉｌｔｏリポートエージェントは、リポートエージェント５５および５６に対応する。リポートエージェント５６は、更新のあったＵＲＬをＥ−ｍａｉｌ５９で通知先ＵＲＬに送信する。
【０１０６】また、その発展形であるリポートエージェント５５の場合は、マジックメールをMagic Cap ４１に送る。マジックメールをＵＲＬで記述する方法はＲＦＣ（Requests For Comments ）１７３８に記載されている。このほかに、マジックメールのためのゲートウェイを通過させる方法もある。
【０１０７】ｈｔｔｐリポートエージェントはリポートエージェント５７に対応し、通知先ＵＲＬに存在するＨＴＭＬ文書６０内のリンクリストに、更新されたＵＲＬを付
け加える。
【０１０８】このＨＴＭＬ文書６０は、例えば図９のＨＴＭＬ文書７６と同様のフォーマットを持ち、更新されたＵＲＬのリストをリンクリストとして持っている。ＨＴＭＬ文書６０のリンクリストは監視の依頼時には空白のままであるが、リポートエージェント５７により、更新のあったＵＲＬが１つずつ追加されていく。
【０１０９】そして、端末上に表示されたリンクリスト内の１つのリンクをユーザがクリックすれば、対応するページへ飛ぶことができる。これにより、ユーザは更新され
た情報を実際に確認することができる。
【０１１０】ｆｔｐリポートエージェントはリポートエージェント５８に対応し、通知先ＵＲＬにあるＦＴＰサイト６１のファイルシステムのメンテナンスを行う。リポートエージェント５８は、例えば、更新ＵＲＬのファイル名からどのアプリケーション・ソフトウェアのどのバージョンかを判断し、ＦＴＰサイト６１内の対応する古いバージョンを削除する。そして、更新ＵＲＬから新しいバージョンを取得し、ＦＴＰサイト６１内のファイルシステムに追加する。
【０１１１】このように、リポートエージェントは更新ＵＲＬを通知するのみではなく、ファイルシステムの物理的な変更を行うこともできる。また、監視要求の入力時にユーザが通知先ＵＲＬを２つ以上指定した場合、それらのＵＲＬ毎にリポートエージェントが作成され、更新されたＵＲＬの報告をメール等で同時に行う。通知先として、ユーザのページャ（ポケットベル等）を指定することも考えられる。」（第１０頁第１７欄第３行〜同頁同欄第４４行）
　
「【０１２６】
　尚、通知手段管理システム１２が監視資源とネットワーク的に近い場所にある場合は、デリゲートプレイス５１を通知手段管理システム１２内に設けても差し支えない。その場合は、通知手段管理システム１２はＵＲＬ監視システム１３の役割をも果たすことになる。また、監視先の資源を必ずしもＵＲＬで記述する必要はなく、他の任意の識別情報を用いてもよい。」（第１１頁第１９欄第３５行〜同頁同欄第４１行）
　
　と、記載されている。
　
　これらの記載によれば、引用刊行物１には、
「監視要求入力インタフェース１０、通知インタフェース１１、通知手段管理システム１２、およびＵＲＬ監視システム１３を備えるネットワーク資源監視システムにおいて、
　資源（５０−１、５０−２、５０−３）は、インターネット上のホームページのように、発信者が作成して発信する画像情報やテキスト情報等であり、発信者により更新され、ＵＲＬで識別され、通信ネットワーク４９に接続されており、
　監視要求入力インタフェース１０、通知インタフェース１１は、ＷＥＢブラウザ端末であり、
　監視要求入力インタフェース１０は、ユーザから入力された監視対象の資源のＵＲＬと通知手段とを、監視要求とともに通知手段管理システム１２に伝え、
　通知手段管理システム１２は、インターネットへの接続サービスを行うプロバイダのサーバであり、監視データベース（ＤＢ）４７を備え、前記ユーザから入力された監視対象の資源のＵＲＬと前記通知手段とを監視データベース（ＤＢ）４７に登録し、前記監視要求、前記ユーザから入力された監視対象の資源１４のＵＲＬをＵＲＬ監視システム１３に伝え、
　ＵＲＬ監視システム１３は指定されたＵＲＬの資源１４に定期的にアクセスしてその状態を調べ、更新されたことが分かると、その情報を通知手段管理システム１２に知らせ、
　通知手段管理システム１２は、通知インタフェース１１に対して監視結果を通知する通知手段を監視データベース（ＤＢ）４７により管理しており、ＵＲＬ監視システム１３から受け取った情報を、対応する通知手段により通知インタフェース１１に通知し、通知インターフェース１１は、更新されたＵＲＬのリストを有し、
　ユーザは資源に更新があったことを知り、その資源にアクセスして更新した情報を得ることができ、
　通知手段管理システム１２は、通信ネットワーク４９に接続され、
　通知手段管理システム１２は、ＵＲＬ監視システム１３の役割をも果たすことができ、
　通知手段管理システム１２は、インタフェース依存性のある世界と通信ネットワーク４９の境界上に位置しているネットワーク資源監視システム。」の発明（以下「引用刊行物１発明」という。）が記載されているものと認めることができる。
　
　
　特開平１１−２１２９９５号公報（原査定の拒絶の理由に引用された。以下、「引用刊行物２」という。）には、図面と共に、
　
「【請求項１７】　通信ネットワークに接続されたユーザ端末であって、取得すべき情報、情報を取得すべきタイミングおよび取得した情報の送信先を特定して、通信ネットワークを介して、上記特定された種々の情報を示すデータを送信可能なユーザ端末と、
　通信ネットワークに接続され、前記ユーザ端末からのデータを受け入れるデータ受け入れ手段、前記タイミングにしたがって、取得すべき情報を得る情報取得手段、および、取得された情報を、所定の送信先に送信する送信手段を備えた送信サーバとを備えたことを特徴とする情報予約送信システム。
【請求項１８】　前記情報取得手段が、通信ネットワークを介して他のサーバから取得すべき情報を得ることを特徴とする請求項１７に記載の情報予約送信システム。
【請求項１９】　前記送信先を示すデータが、送信先である通信端末の機種名および通信端末の番号を示すデータを含み、
　前記送信手段が、通信端末又は通信端末に情報を伝達するための設備に、通信端末の番号あるいはこれに相当するデータを通知して、取得した情報の転送を依頼するように構成されたことを特徴とする請求項１７または請求項１８に記載の情報予約送信システム。
【請求項２０】　ユーザ端末から、取得すべき情報、情報を取得すべきタイミングおよび取得した情報の送信先を示すデータを、通信ネットワークを介して受け入れる、データ受け入れ手段、前記タイミングにしたがって、取得すべき情報を得る情報取得手段、および、取得された情報を、所定の送信先に送信する送信手段を備えたことを特徴とする送信サーバ。
【請求項２１】　前記情報取得手段が、通信ネットワークを介して他のサーバから取得すべき情報を得ることを特徴とする請求項２０に記載の送信サーバ。
【請求項２２】　前記送信先を示すデータが、送信先である通信端末の機種名および通信端末の番号あるいはこれに相当するデータを示すデータを含み、
　前記送信手段が、通信端末への情報サービスを行っているサービス設備に、通信端末の番号あるいはこれに相当するデータを通知して、取得した情報の転送を依頼するように構成されたことを特徴とする請求項２０または請求項２１に記載の送信サーバ。」（【特許請求の範囲】）
　
「【００２９】
【発明の実施の形態】発明の実施の形態１．以下、添付図面を参照して、本発明の実施の形態につき説明を加える。図１は、本発明の実施の形態にかかる情報予約送信システムの概略を示すブロックダイヤグラムである。図１に示すように、情報予約送信システムは、大きく分けて３つの部分から構成されている。
【００３０】第１の部分には、いわゆるインターネット３２を介して、それぞれサービスプロバイダ設備１０のサーバにアクセス可能なユーザ端末３０ａ〜３０ｃと、プロバイダなどのＷＷＷサーバ部４０ａ〜４０ｃとが含まれている。
【００３１】第２の部分は、ユーザ端末３０ａ〜３０ｃからの要求にしたがって、上記ＷＷＷサーバ部４０ａ〜４０ｃにアクセスして所望の情報を得るインターネットサービスプロバイダ設備１０から構成されている。このサービスプロバイダ１０が、送信サーバとして機能する。
【００３２】第３の部分には、ＰＳＴＮ（公衆電話交換網）やＩＳＤＮ(Integrated Service Digital Network)からなる公衆回線網５２と、公衆回線網５２に接続されたページャへの情報サービス会社の設備５０ａ〜５０ｃと、情報サービス会社の設備５０ａ〜５０ｃの何れかから情報サービスを受けるページャ６０ａ〜６０ｂとが含まれている。なお、ＰＳＴＮやＩＳＤＮの代わりに、専用線あるいはパケット交換網で直接接続するようにしてもよい。
【００３３】ユーザ端末３０ａ〜３０ｃは、たとえば、ＰＣ(Personal Computer)からなり、ユーザは、インターネット３２を介して、他のＷＷＷサーバ部１２、４０ａ〜４０ｃからの情報を入手することができる。また、プロバイダのＷＷＷサーバ部４０ａ〜４０ｃも主としてＰＣあるいはＷＳ（Work Station）にて構成することができる。
【００３４】サービスプロバイダ設備１０は、インターネット３２に接続されたＷＷＷサーバ部１２、ユーザ端末の画面上に出力される情報を制御したり、ユーザ端末から入力される情報を受け取るＭＭＩ(Man-Machine Interface)部１４、ユーザ端末３０ａ〜３０ｃにより設定されたスケジュール情報などを記憶するデータベース１６、データベース１６中のデータにしたがって必要な情報を収集する情報収集部１８、タイマを有し必要なスケジュールを管理する時間管理部２０、ページャ６０ａ、６０ｂに伝達すべきデータを作成する呼出サーバ部２２、および、モデム２４を備えている。
【００３５】情報収集部１８は後に詳述するように、時間管理部２０によるスケジュール管理の下、データベース中のデータにしたがって他のＷＷＷサーバ部４０ａ〜４０ｃからの情報を収集し、得られたデータと呼出サーバ部２２への命令とを呼出サーバ部２２に与える。
【００３６】呼出サーバ部２２は、情報収集部１８から与えられた所定の情報にしたがって、所定の命令およびデータを作成し、作成した信号をモデム２４に与える。また、呼出サーバ部２２は、各サービス会社ごとに固有のコードの変換テーブルを備え、上記命令にしたがって、データを伝達すべきページャにサービスを提供するサービス会社に受け入れ可能な信号にデータを変換するとともに、これをモデム２４に出力する。モデム２４は、変換されたデータをトーン信号列、あるいはモデムの変調信号及び各社の通信プロトコルに変換し、公衆回線網５２を介して、何れかのサービス会社の設備５０ａ〜５０ｃに信号を伝達する。」（第５頁第７欄第２行〜同頁第８欄第１３行）
　
「【００３７】このように構成された情報予約送信システムの動作につき、以下に説明する。図２は、この情報予約送信システムにおいて実行される処理の種別を示す図である。図２に示すように、このシステムにおいては、ユーザ端末３０からサービスプロバイダ設備１０への、情報の収集条件およびスケジュールの新規入力処理（ステップ２０１）、ユーザ端末３０からサービスプロバイダ設備１０への、スケジュールの変更処理（ステップ２０２）、サービスプロバイダ設備１０からページャ６０への情報の発信処理（ステップ２０３）が実行される。
【００３８】上記新規入力処理につき、より詳細に説明を加える。まず、ステップ２０１の新規入力処理につき説明を加える。図３は、新規入力処理の処理手順を示す図である。まず、ユーザが何れかのユーザ端末３０の入力装置（図示せず）を操作することにより、サービスプロバイダ設備１０のＷＷＷサーバ部１２にアクセスして、ＷＷＷサーバ部１２から送られてきた条件指定用のＨＴＭＬ(HyperText Markup Language)形式のファイルをユーザ端末３０に内蔵されたＷＷＷブラウザ（図示せず）が解釈し、その結果を画面上に表示する（ステップ３０１）。その際に、ユーザ名とパスワードをユーザが送信することにより、前記ＨＴＭＬファイルが端末に送られてくるようにすることもできる。
【００３９】図４は、ユーザ端末３０のディスプレイ（図示せず）の画面上に表示された、収集条件、スケジュールの新規入力に対応するＨＴＭＬ形式のファイルに対応する画像の一例を示す図である。図４に示すように、この画像に所望の文字列を入力することにより、ＵＲＬ(Universal Resource Locator)、検索方法、キー（先頭キーワード、末尾キーワードおよび出現の順番）、並びに、ページャに送信すべき文字列の最大の長さ（最大文字列長）を指定することができる。具体例については後述する。なお、最大文字列長は、ページャにより、表示可能な文字列に制限があるために、所定の値が設定されるようになっている。
【００４０】なお、ＵＲＬ選択において、アルファベットを直接入力する方法とともに、過去に使用したＵＲＬを選択する方法、サーバ側で予め用意したＵＲＬを選択する方法を採用することができる。また、ユーザが指定したＵＲＬが、閲覧は良いがコピーしたり転送したりすることが本サーバで禁止されているときに、その旨のエラーメッセージを表示して再入力を促すように構成してもよい。例えば、図４において、ＯＫボタンを押すと、その後に送信できない旨のメッセージが表示される。また、指定したＵＲＬが登録制の場合に、サーバーが、その管理者に自動的にメールを送り、許可を得てから使用するように構成してもよい。
【００４１】図４の画面の下部に設けられたボタン４０１を、ユーザがマウスでクリックするなど入力装置を操作することによりオンすると、表示された検索条件、ＵＲＬ、ユーザ名などが、ユーザ端末３０からサービスプロバイダ設備１０に与えられる。すると、ＷＷＷサーバ部１２が、与えられた検索条件およびＵＲＬにしたがって、インターネット３２を介して、他のＷＷＷサーバ４０ａ〜４０ｃにアクセスし、これらの何れかから、検索条件などに合致する文字列を、ＨＴＭＬ形式のファイルにて取得する。そして、取得された文字列をユーザ端末３０に伝達する。文字列が取得できなかったときは、エラー情報を返す（ステップ３０２）。
【００４２】これに応答して、ユーザ端末３０のディスプレイの画面上には、図５に示すような画像が表示される（ステップ３０３）。図５に示すように、ディスプレイの画面上には、ステップ３０１にて設定された検索条件やＵＲＬのほか、サービスプロバイダ１０により取得されて伝達された文字列（この例では、「0902　今日は何の日？　宝くじ日／誕生　○山×子　（１９＊＊年、タレント）」という情報）が表示される。
【００４３】このように文字列を表示し確認をとる（ステップ３０４）。図５に示すような画面が表示された際に、ユーザが検索条件の変更を求める場合には、入力装置（ブラウザでもよい。以下同じ）を所定のように操作することによりステップ３０１に戻るように構成することが可能である。同時に、図５の下部に示されたように、「文字列送信試験を（する）／文字列送信試験を（しない）」ボタン５０１、５０２を表示することにより、ページャへの送信試験の有無をユーザーに確認する。ボタン５０１がユーザによりオンされると「文字列送信試験をする」と判断され、ステップ３０５に進み、図６のような画面を表示する。
【００４４】ステップ３０５および３０６においては、ユーザ端末３０のディスプレイの画面上に、図６に示すような、情報を送信すべきページャの機種名、ポケットベル（ページャ）番号、設定されている場合に必要なパスワード、取得された文字列（送信メッセージ）および送信レポートが必要な場合に、該レポートを送信すべきメールアドレスを指定する欄を含む画像が表示される。
【００４５】ユーザは、入力装置を操作することにより、上記欄のそれぞれに必要な文字や数字を記入した後に、ボタン６０１をオンする。これにより、上記欄に設定された情報がサービスプロバイダ設備１０に、インターネット３２を介して伝達される。
【００４６】サービスプロバイダ設備１０においては、これに応答して、呼出サーバ部２２が起動され、取得した機種名にしたがってスプールファイルを作成する(ステップ３０７)。
【００４７】次いで、作成したスプールファイル３２を読み出して、設定されたポケットベル番号に従い、文字列を送信すべきページャのサービス会社の設備（５０ａ〜５０ｃのいずれか）に、送信先電話番号および文字列を、モデム２４及び公衆回線５２を介して転送する（ステップ３０８）。これにより、送信先であるページャ６０に、必要な文字列が伝達される。送信試験が完了したときに、そのことを知らせるために「送信試験を完了しました」というメッセージを表示するようにしてもよい。
【００４８】送信試験の結果、問題があるようであれば、設定をキャンセルし、ステップ３０５に戻り設定をやり直すように構成してもよい。
【００４９】このような送信試験が終了した後、或いは、図５に示す画像のボタン５０２がユーザによりオンされた場合には、ステップ３０９に進む。ステップ３０９にお
いては、ユーザ端末３０のディスプレイの画面上に、図７に示すような画像が表示される。図７に示すように、この画像には、図５に示した項目（ＵＲＬ、複数の検索条件、送信メッセージ）、図６に示す機種名、ポケットベル（ページャ）番号、パスワード、メールアドレスが含まれる。さらに、これに加えて、サービスプロバイダ設備１０が、上記検索条件に基づき、ＵＲＬおよび検索条件にしたがって、他のＷＷＷサーバ部４０ａ〜４０ｃから文字列を取得して、ポケットベル（ページャ）番号にて特定されるページャ６０に取得した文字列を伝達するための日付および時間を設定する欄（符号７０１など）が設けられている。
【００５０】ここで、曜日指定欄７０１の左側に設けられたボタン７０２をオンすると、図８に示すように、曜日およびこれらの組み合わせを含むウィンドウ８００（メニューウインドウ）が表示される。ユーザはマウスなどの入力装置を操作することにより、所望の曜日或いはこれらの組み合わせの何れかを選択することができる。或いは、曜日指定欄７０１の右側の日付指定欄に数値を入れて、曜日ではなく所望の日（例えば、９月２日）に、文字列を取得してこれを伝達するように設定することもできる。さらに、本実施の形態においては、文字列を取得してこれを伝達する時刻を指定することができる（符号７０３参照）。
【００５１】図７の画面において問題があるようであれば、設定をキャンセルし、ステップ３０１に戻り設定をやり直すように構成してもよい。
【００５２】このようにして、取得すべき文字列を送信すべき日時が設定され、ボタン７０５がオンされると、ユーザ名、検索条件、ＵＲＬ、ページャの機種名、ポケットベル（ページャ）番号、日時などが、インターネット３２を介して、サービスプロバイダ設備１０に伝達される。伝達された情報は、スケジュールファイルとして、データベース１６の所定の領域に記憶される（ステップ３１０）。
【００５３】以上が、図２の収集条件、スケジュールの新規入力処理２０１の詳細である。」（第５頁第８欄第１４行〜第７頁第１１欄第１１行）
「【００５４】次に、収集した情報の発信処理２０３について説明する。
【００５５】上述したようにしてデータベース１６に記憶されたスケジュールファイルは、図１のサービスプロバイダ設備からページャ６０への情報の発信処理にて使用される。
【００５６】図９は、この発信処理の処理手順を示す図である。図９に示すように、サービスプロバイダ設備１０の情報収集部１８は、時間管理部２０からの時間情報にしたがって、所定の時間ごと（たとえば、ｎ分ごと。ｎ＝１、５、１０、１５、３０、４５、６０、９０、１２０・・・）に、データベース１６中のスケジュールファイルを参照して、実行すべきジョブがあるか否かを判断する（ステップ９０１）。ここで、実行すべきジョブとは、スケジュールファイル中の日時が、現在の時間と略一致する場合（例えば、６０分間隔でジョブの有無を判断するときに、３０分以内に実行すべきであった過去のスケジュールがある、あるいは３０分未満内に実行すべき未来のスケジュールがあるとき）、他のＷＷＷサーバ部４０ａ〜４０ｃから必要な文字列を取得して、指定されたポケットベル（ページャ）番号のページャに取得した文字列を伝達することをいう。　　　【００５７】実行すべきジョブがあった場合には、情報収集部１８は、対応するスケジュールファイル中の検索条件、ＵＲＬなどを取出す。（ステップ９０２）。なお、ここで、電話番号がエイリアス(Alias)である、つまり、番号でなく名前である場合には、データベース１６中に予め設けられた電話帳を参照して、必要な電話番号を取得する（なお、電話番号は複数の場合もある）。次いで、情報収集部１８は、何れかのＷＷＷサーバ部４０ａ〜４０ｃから検索条件に合致する文字列を取得する（ステップ９０３）。
【００５８】このようにして所定の文字列が取得されると、情報収集部１８は、得られた文字列、対応するスケジュールファイル中の機種名、ポケットベル（ページャ）番号、メールアドレスなどを呼出サーバ部２２に伝達する（ステップ９０４）。
【００５９】呼出サーバ部２２は、これに応答して、与えられた機種名にしたがってスプールファイルを作成する（ステップ９０５）。
【００６０】次いで、作成したスプールファイルを読み出して、送信時間になったら、取得した文字列を送信すべきページャにサービスを提供している何れかのサービス会社の設備５０ａ〜５０ｃに、送信先電話番号および文字列を、公衆回線５２を介して転送するようにモデム２４を起動する（ステップ９０６）。これによりモデム２４、公衆回線５２、サービス会社の設備を介して、送信先であるページャ６０のディスプレイ（図示せず）の画面上に必要な文字列が表示される。
【００６１】このような処理が終了した後に、情報収集部１８は、スケジュールファイルを更新（あるいは消去）するとともに、ログファイルを出力する。これにより、図
２のステップ２０３の処理が終了する。」（第７頁第１１欄第１２行〜同頁第１２欄第１４行）
　
「【００６２】次に、図２のステップ２０２のスケジュールの変更処理につき説明を加える。この処理は、少なくとも一つの収集条件およびスケジュールを設定したユーザが、ユーザ端末３０の入力装置を操作して、スケジュールの変更を指定したことにより実行される。図１０は、この発信処理の処理手順を示す図である。ユーザが入力装置を操作して、ユーザ名をユーザ端末３０に入力することにより、インターネット３２を介して、サービスプロバイダ設備１０にユーザ名が与えられる（ステップ１００１）。ユーザプロバイダ設備１０のＷＷＷサーバ部１２は、これに応答して、データベース１６から、与えられたユーザ名を含むスケジューリングファイルを探し出し、このスケジューリングファイルに含まれる種々の情報（日時、検索条件、ＵＲＬ、ページャの機種名、ポケットベル（ページャ）番号など）をインターネット３２を介して、ユーザ端末３０に返送する。
【００６３】図１１は、このようにして、ユーザ端末３０のディスプレイの画面上に得られた画像の一例を示す図である。図１１に示すように、ディスプレイの画面上には、ユーザにより設定されたスケジューリングファイルのそれぞれに含まれる種々の情報を示す欄（たとえば、１１０１、１１０２など）が表示される。また、各欄の左側には、欄に対応してチェックボックス（たとえば、１１０３）が設けられている。ユーザがユーザ端末３０の入力装置を操作して、チェックボックスの何れかに印を付け、かつ、「削除」ボタン１１０４をオンすると、削除すべきスケジューリングファイルを示す情報が、インターネット３２を介して、サービスプロバイダ設備１０に与えられ、これに応答して、データベース１６中の対応するスケジューリングファイルが削除される（ステップ１００２）。
【００６４】また、本実施の形態においては、単なる削除に加えて、文字列を取得して所定のページャに送信すべき日時（曜日も含む）、ポケットベル（ページャ）番号（送信電話番号）およびメールアドレスを変更することが可能である。ユーザがユーザ端末３０の入力装置を操作して、日時やメールアドレスの対応する欄に必要な文字や数字を入力して、「登録」ボタン１１０５をオンすると、対応するスケジューリングファイルに関するユーザ名、日時、ポケットベル（ページャ）番号、メールアドレスが、インターネット３２を介してサービスプロバイダ設備１０に与えられる。サービスプロバイダ設備１０においては、これに応答して、データベース１６中の対応するスケジューリングファイルの内容が更新される（ステップ１００３）。更新された内容は、再度、インターネット３２を介して、ユーザ端末３０に返送され、ディスプレイの画面上に表示されるため、ユーザは、自己が変更した内容を確認することが可能である。
【００６５】このようにして、ユーザは、いったん登録したスケジュールを所望のように変更することができる。
【００６６】なお、図１１中の「やり直し」ボタンを操作することにより、一度入力したデータを、図１１の入力前に修正することが可能である。
【００６７】なお、図１１中の「スケジュール」「時間（２４Ｈ）」「メールアドレス」「送信電話番号」「ベルＰＷ」「ＵＲＬ」「検索種別」「キー１」「キー２」「キー３」「最大文字数」の各欄について簡単に説明する。
【００６８】「スケジュール」は情報収集部１８を起動するタイミングのうちの「日」を指定する欄である。例えば、「月火水木金」のようにウイークデーの指定や、「金」のように特定の曜日の指定や、「８月１５日」のように日付指定が可能である。また、「ＡＵＴＯ」という指定も可能である。これは目的とするホームページが変更されたことを自動的に検知し、変更されたときに自動的にデータをページャへ送信するものである。詳しくは後述の発明の実施の形態２で述べる。
【００６９】「時間（２４Ｈ）」は情報収集部１８を起動するタイミングのうちの「時刻」を指定する欄である。例えば、「１２：００」のような指定が可能である。この表示は２４時間表示でも、午前／午後の表示でもどちらでもよい。また、上記の場合と同様に「ＡＵＴＯ」という指定も可能である。
【００７０】「メールアドレス」は送信レポートの宛先のアドレスである。
【００７１】「送信電話番号」はデータを送信すべきページャの電話番号である。例えば直接電話番号を指定することが可能である。あるいは、電話番号及び／又はページャの機種を予め登録するとともに、登録されたものに固有の文字列（コード）を割り当て、この文字列を指定することも可能である。例えば、個人の名前を文字列に使用することが可能である。エイリアスあるいは特定の電話番号列をもつものであって特定のポケットベルの機種のものすべてに送信する、というような指定も可能である。このような指定方法は、文字列で複数の文字列等を表象することができるので、同報送信のように一度に多数の相手にメッセージを送信するときに便利である。このための登録機能は、例えばＭＭＩ及び呼出サーバ部の両方に持たせることが考えられる。なお、この場合において、情報処理部１８は同報先のページャの数と同じだけ、呼出サーバ部２２及びモデム２４を繰り返し動作させる。
【００７２】「ベルＰＷ」は、ポケベル（ページャ）のパスワード（ＰＷ）である。パスワードは不要のときがある。
【００７３】「ＵＲＬ」は、図３のステップ３０１、図４の画面で入力したＵＲＬである。
【００７４】「検索種別」は、「キー１」乃至「キー３」で指定された検索範囲の種別を示す。
【００７５】「キー１」乃至「キー３」は、図３のステップ３０１、図４の画面で入力した検索条件である。なお、これらの条件は図１１の画面において変更できない。これは、検索条件は、実際にホームページからデータが正しく取得されるかどうか確認しながら設定されるべきだからである。検索条件がむやみに変更されても正しいデータが得られるとは限らない。また、キーを与えただけでは取得試験ができないため、正しい情報が取得できなくなるかもしれない。例えば、ホームページの内容が変更されるときに、そのレイアウト（ＨＴＭＬソース）が変更されることがあり、この場合は過去の検索条件をそのまま使用したとしてもデータを正しく取得できない。「キー」の内容は、ＨＴＭＬソース中のタグである。例えば、「キー１」を＜title＞、「キー２」を＜/title＞に設定すると、そのホームページのタイトルのデータを取得することができる。同様に、＜ＢＲ＞を指定すれば、改行までつまり文字列の最後までのデータを、「%02m%02d」（これは2桁で構成される月データと２桁で構成される日データを指定する意味である）を指定すれば日付情報が、「time」を指定すれば時刻情報が、文字列「aa」から「bb」を指定すれば「aa」「bb」の間のデータをそれぞれ取得することができる。この場合において、該当する部分が複数ある場合には、これらのうちの何番目を取得するかも指定することができる。あるいは、何行の何文字目から何行の何文字目までのデータを取得するというような指定も可能である。あるいは、ＨＴＭＬソースに慣れていないユーザーは、ホームページの表示を直接見ながら指定することも可能である。この場合、ホームページの表示の指定からＨＴＭＬソースの指定に変換するソフトウエアをユーザ端末あるいはＷＷＷサーバ部のいずれかに備えるようにしてもよい。
【００７６】「最大文字数」は、図３のステップ３０１、図４の画面で入力した最大文字列長である。この単位は、例えばバイトである。
【００７７】なお、上記の説明において変更できないものは「キー１」乃至「キー３」であったが、これ以外にみだりに変更されてトラブルが生じるおそれがあるもの、例えば送信先の電話番号なども変更できないようにしてもよい。」（第７頁第１２欄第１５行〜第９頁第１５欄第４行）
　
「【００８１】発明の実施の形態２．次に、本発明の第２の実施の形態につき説明を加える。この実施の形態において、情報予約送信システムの構成および処理の概要は、図１、図２に示すものと同一である。特に、この実施の形態においては、サービスプロバイダ設備からページャへの情報の発信処理（図２のステップ２０３）において、取得した文字列に変化があったときに、これをページャに送信できるようになっている。なお、これを実現するために、スケジュールファイル中には、取得した文字列を格納するための領域が設けられている。
【００８２】図１２は、第２の実施の形態にかかる情報予約送信システム１０における発信処理（図２のステップ２０３）の処理手順の一部を示す図である。図１２に示すように、サービスプロバイダ設備１０の情報収集部１８は、時間管理部２０からの時間情報にしたがって、所定の時間ごと（たとえば、ｎ分ごと）に、データベース１６中のスケジュールファイルを参照して、実行すべきジョブがあるか否かを判断する（ステップ１２０１）。この処理は、図９のステップ９０１に略対応する。実行すべきジョブがあった場合には、情報収集部１８は、対応するスケジュールファイル中の前回検索された際の文字列を取り出す（ステップ１２０２）。次いで、情報収集部１８は、何れかのＷＷＷサーバ部４０ａ〜４０ｃから検索条件に合致する文字列を取得する（ステップ１２０３）。
【００８３】情報収集部１８は、取得された文字列を、対応するスケジュールファイル中の文字列のための領域に格納するとともに、この取得された文字列と、前回検索された際の文字列とを比較し、これが同一である場合には、処理を終了し、同一でない場合には、送信のための種々の処理（ステップ１２０５など）を実行する（ステップ１２０４）。なお、最初は「前回検索された文字列」がないが、同様に取り扱える。もちろんこのステップをスキップすることもできる。送信のための処理は、図９のステップ９０４ないし９０７と略同一である。
【００８４】なお、第２の実施の形態のように、取得された文字列が変更された場合にのみ、文字列を送信するように設定するために、図１３に示すように、日時や送信先を指定する画像（図７に一部を除き一致する）を、ユーザ端末３０のディスプレイの画面上に表示し、日付や送信時間の代わりに、ボタン１３０１をオンすることにより、文字列の変更を検知して図１２に示す処理が実行されるように設定しても良い。また、検知の時間範囲の指定ができるようにしてもよい。
【００８５】このように本実施の形態によれば、取得された文字列が、前回のものと変更されている場合に限り、これを所定のページャに送信する。したがって、無駄な情報の送信を防止しつつ、必要な情報を逃すことなく提供することが可能となる。例えば、プロ野球の情報をホームページから取得しページャに送信するとき、プロ野球の放送時間の変更（延長）のみ変更検知したり、得点が新たに加えられたり、回が変わったりするごとにデータを送信することができる。すなわち、汎用のページャを用いてプロ野球速報サービスを提供することができる。もちろんプロ野球などのスポーツ情報に限らず、常に最新の情報を必要とする用途、例えば、株価情報、為替相場情報、気象情報、選挙速報などの情報を提供することができる。従来、この種の情報提供は専用のサーバと専用の端末を必要としたが、この発明の実施の形態によれば、汎用のサーバ、汎用のページャ等の携帯無線端末によって実現可能となる。
【００８６】また、対象とするホームページへのアクセスが有料（例えば、時間に対する従量制）の場合、この発明の実施の形態のように間欠的にアクセスすることにより、情報受信のコストを低減することができる。また、アクセスする時間帯を限定することによりさらにコストを低減することが可能になる。例えば、プロ野球の最新情報を知りたいときにはプロ野球が行われている６時から１０時までの時間帯に限定し、株価情報であれば株式市場が開かれている時間帯に限定すればよい。
【００８７】以上、説明したように本実施の形態よれば、所望の情報を得るために、別個にＷＷＷサーバ部を参照する必要がなくなり処理が簡単になるとともに、定期的に情報を取得して、これをぺージャに伝達するため、情報の取り忘れを防止することが可能となる。
【００８８】また、取得した情報を、ページャに送信することにより、第三者にこれを伝達することが可能となる。この発明の実施の形態を適用することにより、携帯用無線端末の仕様を変更することなく、携帯用無線端末とインターネットなどの通信ネットワークとを結合することにより、さまざまなサービスの提供が可能となる。
【００８９】本発明は、以上の実施の形態に限定されることなく、特許請求の範囲に記載された発明の範囲内で、種々の変更が可能であり、それらも本発明の範囲内に包含
されるものであることは言うまでもない。
【００９０】たとえば、前記実施の形態においては、公衆回線を介してページャに取得した文字列を送信しているがこれに限定されるものではなく、他のユーザ端末に電子メールやファクシミリとして伝達しても良い。また、公衆回線を介して、無線端末（たとえば、携帯電話やＰＨＳ(Personal Handyphone System)）に取得した文字列を送信しても良い。
【００９１】また、前記実施の形態においては、他のＷＷＷサーバ部から情報を取得しているが、これに限定されるものではなく、電子ニュースなどであっても良い。さらに、取得する情報は文字列に限定されるものではなく、ビットマップなどの画像データや音声データが含まれていても良い。」（第９頁第１５欄第３３行〜第１０頁第１７欄第３０行）
　
　と、記載されている。
　
　これらの記載によれば、引用刊行物２には、
「インターネット３２を介して、それぞれサービスプロバイダ設備１０のサーバにアクセス可能なユーザ端末３０ａ〜３０ｃと、プロバイダなどのＷＷＷサーバ部４０ａ〜４０ｃとが含まれ、
　ユーザ端末３０ａ〜３０ｃからの要求にしたがって、上記ＷＷＷサーバ部４０ａ〜４０ｃにアクセスして所望の情報を得るインターネットサービスプロバイダ設備１０から構成され、このサービスプロバイダ設備１０が、送信サーバとして機能し、
　公衆回線網５２と、公衆回線網５２に接続されたＰＨＳ(Personal Handyphone System)への情報サービス会社の設備５０ａ〜５０ｃと、情報サービス会社の設備５０ａ〜５０ｃの何れかから情報サービスを受けるＰＨＳ(Personal Handyphone System)６０ａ〜６０ｂとが含まれている情報予約送信システムであって、
　ユーザ端末３０ａ〜３０ｃは、インターネット３２を介して、ＷＷＷサーバ部１２、４０ａ〜４０ｃからの情報を入手することができ、
　サービスプロバイダ設備１０は、インターネット３２に接続されたＷＷＷサーバ部１２、ユーザ端末の画面上に出力される情報を制御したり、ユーザ端末から入力される情報を受け取るＭＭＩ(Man-Machine Interface)部１４、ユーザ端末３０ａ〜３０ｃにより設定されたＵＲＬ(Universal Resource Locator)、検索条件、スケジュール情報などを記憶するデータベース１６、データベース１６中のデータにしたがって必要な文字列を収集する情報収集部１８、タイマを有し必要なスケジュールを管理する時間管理部２０、ＰＨＳ(Personal Handyphone System)６０ａ、６０ｂに伝達すべきデータを作成する呼出サーバ部２２、および、モデム２４を備えており、
　情報収集部１８は、時間管理部２０によるスケジュール管理の下、データベース中のＵＲＬ、検索条件にしたがって他のＷＷＷサーバ部４０ａ〜４０ｃから検索条件に合致する文字列を取得し、得られた文字列に変化があったときに、得られた文字列と呼出サーバ部２２への命令とを呼出サーバ部２２に与え
　呼出サーバ部２２は、情報収集部１８から与えられた所定の情報にしたがって、所定の命令および得られた文字列からなるデータを作成し、作成した信号をモデム２４に与え、モデム２４は、公衆回線網５２を介して、何れかのサービス会社の設備５０ａ〜５０ｃに信号を伝達し、ＰＨＳ(Personal Handyphone System)に得られた文字列からなるデータを送信する情報予約送信システム。」の発明（以下「引用刊行物２発明」という。）が記載されているものと認めることができる。
　
　
　（３）対比
　
　そこで、本願補正発明と引用刊行物１発明とを対比すると、引用刊行物１発明の「ＷＥＢブラウザ端末」は、本願補正発明の「情報端末」に相当する。以下同様に、「通信ネットワーク４９」は「第２ネットワーク」に、相当する。
　引用刊行物１発明の「資源」は、インターネット上のホームページのように、発信者が作成して発信する画像情報やテキスト情報等であり、発信者により更新されるものであるから、本願補正発明の「コンテンツ」を含むものである。
　引用刊行物１発明の「資源」は、ユーザがその資源にアクセスして更新した情報を得ることができるものであるから、サーバの機能を有すること、そして、１個または複数個あることは明らかであり、本願補正発明の「１個または複数個のコンテンツサーバ」に相当する。
　引用刊行物１発明の「通知手段管理システム１２」は、インタフェース依存性のある世界と通信ネットワーク４９の境界上に位置して、インターネットへの接続サービスを行うプロバイダのサーバであることから、本願補正発明の「配信サーバ」に対応する。
　引用刊行物１発明の「通知手段管理システム１２」と「ＷＥＢブラウザ端末」は、ネットワークで接続されていることは、明らかであり、当該ネットワークは、本願補正発明の「第１ネットワーク」に相当する。
　引用刊行物１発明の「ＷＥＢブラウザ端末」は、資源にアクセスして更新した情報を得ることができることから、ＷＥＢブラウザ端末にて選択された資源の有するコンテンツが通知手段管理システム１２（配信サーバ）を介してＷＥＢブラウザ端末へ配信されることは、明らかであるといえ、引用刊行物１発明の「ネットワーク資源監視システム」は、本願補正発明の「情報配信システム」に対応する。
　引用刊行物１発明の「通知手段管理システム１２」は、監視データベース（ＤＢ）４７を備え、ユーザから入力された監視対象の資源のＵＲＬを監視データベース（ＤＢ）４７に登録しており、資源には、発信者が作成して発信する画像情報やテキスト情報等があることから、ユーザから入力された監視対象の資源のＵＲＬのコンテンツを監視対象コンテンツとして登録して特定していることは、明らかである。そして、本願補正発明の「情報端末がアクセスしたコンテンツ」は、ユーザが携帯端末を操作して特定したコンテンツであることは明らかである。
　そうすると、引用刊行物１発明の「ユーザから入力された監視対象の資源のＵＲＬ」の「画像情報やテキスト情報等」と、本願補正発明の「情報端末がアクセスしたコンテンツ」とは、「ユーザにより特定したコンテンツ」という点で一致する。
　そして、引用刊行物１発明の「通知手段管理システム１２」と、本願補正発明の「配信サーバ」とは、ユーザにより特定したコンテンツを監視対象コンテンツとして特定している点で一致する。
　引用刊行物１発明の「ＵＲＬ監視システム１３」は、通知手段管理システム１２が、ＵＲＬ監視システム１３の役割をも果たすことができるものであるから、本願補正発明の「配信サーバ」に対応し、ＵＲＬ監視システム１３は指定されたＵＲＬの資源１４に定期的にアクセスしてその状態を調べ、更新されたことが分かることから、各コンテンツサーバが有する監視対象コンテンツの更新を確認することは明らかである。
　引用刊行物１発明の「通知手段管理システム１２」は、通知インタフェース１１に対して監視結果を通知する通知手段を監視データベース（ＤＢ）４７により管理しており、ＵＲＬ監視システム１３から受け取った情報を、対応する通知手段により通知インタフェース１１に通知し、通知インターフェース１１は、更新されたＵＲＬのリストを有することから、引用刊行物１発明の「通知手段管理システム１２」と、本願発明の「配信サーバ」とは、「更新された監視対象コンテンツのリストを情報端末に送信する更新確認手段」に対応する機能を有する点で一致する。
　
　以上を総合して、両者は、
「情報端末と配信サーバとが第１ネットワークを介して接続され、かつ前記配信サーバと１個または複数個のコンテンツサーバとが第２ネットワークを介して接続され、前記情報端末にて選択された前記コンテンツサーバの有するコンテンツが前記配信サーバを介して前記情報端末へ配信される情報配信システムであって、
　前記配信サーバは、ユーザにより特定したコンテンツを監視対象コンテンツとして特定し、各コンテンツサーバが有する当該監視対象コンテンツの更新を確認し、更新された当該監視対象コンテンツのリストを前記情報端末に送信する更新確認手段を含むことを特徴とする情報配信システム。」の点で一致し、以下の点で相違している。
　
　
［相違点］本願補正発明では、配信サーバが、情報端末がアクセスしたコンテンツを監視対象コンテンツとして特定するのに対して、引用刊行物１発明では、配信サーバである通知手段管理システム１２が、ユーザから入力された監視対象の資源のＵＲＬを監視データベース（ＤＢ）４７に登録し、監視対象コンテンツとして特定している点。
 　
　（４）当審の判断
　
　［相違点］について
　ユーザ端末がアクセスしたコンテンツについて、コンテンツが更新された場合、その更新されたコンテンツをアクセスしたユーザ端末に通知すること、すなわち、ユーザ端末からのアクセスにより、コンテンツを監視対象コンテンツとして特定することは、特開平６−１８８９０３号公報（段落【０００６】、段落【０００８】−段落【００１５】参照。）及び特開平７−２３４８１０号公報（段落【０００９】及び第３図参照。）に示されるように、周知技術である。
　そして、引用刊行物１発明の配信サーバは、ユーザから入力された監視対象の資源のＵＲＬを当該配信サーバの監視データベース（ＤＢ）４７に登録して、監視対象コンテンツを特定するものである。
　したがって、引用刊行物１発明において、配信サーバにおけるユーザによる監視対象コンテンツのＵＲＬの登録によって監視対象コンテンツを特定することにかえて、上記周知技術を適用して、ユーザ端末からのアクセスによって監視対象コンテンツを特定することとし、配信サーバにおいて情報端末がアクセスしたコンテンツを監視対象コンテンツとして特定することは、当業者が容易に想到し得ることである。
　　
　そして、本願補正発明の作用効果も、引用刊行物１発明及び周知技術から当業者が予測できる範囲のものである。
　
　したがって、本願補正発明は、引用刊行物１発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　
　
　（５）むすび
　
　以上のとおり、本件補正は、特許法第１７条の２第５項で準用する同法第１２６条第５項の規定に違反するものであり、同法第１５９条第１項で準用する同法第５３条第１項の規定により却下されるべきものである。
　
　
３．本願発明について
　
　平成１６年８月５日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１６年４月２６日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　
　「情報端末と配信サーバとが第１ネットワークを介して接続され、かつ前記配信サーバと１個または複数個のコンテンツサーバとが第２ネットワークを介して接続され、前記情報端末にて選択された前記コンテンツサーバの有するコンテンツが前記配信サーバを介して前記情報端末へ配信される情報配信システムであって、
　前記配信サーバは各コンテンツサーバが有するコンテンツの更新を確認し、更新されたコンテンツのリストを前記情報端末に送信する更新確認手段を含むことを特徴とする情報配信システム。」
　
　（１）引用刊行物
　
　原査定の拒絶の理由に引用された引用刊行物、原査定において慣用技術として引用された引用刊行物及びその記載事項は、前記「２．（２）」に記載したとおりである。　
　
　（２）対比
　
　そこで、本願発明と引用刊行物２発明とを対比すると、引用刊行物２発明の「公衆回線網５２」は、本願発明の「第１ネットワーク」に相当する。以下同様に、「インターネット３２」は「第２ネットワーク」に、「インターネットサービスプロバイダ設備１０」は「配信サーバ」に、「ＷＷＷサーバ部４０ａ〜４０ｃ」は「１個または複数個のコンテンツサーバ」に、「文字列」は「コンテンツ」に、「送信」は「配信」に、それぞれ相当する。
　引用刊行物２発明の「ＰＨＳ(Personal Handyphone System)」は、ＷＷＷサーバ部４０ａ〜４０ｃの文字列がサービスプロバイダ１０を介して送信されるものであるから、本願発明の「情報端末」に相当する
　引用刊行物２発明の「情報予約送信システム」は、ＷＷＷサーバ部４０ａ〜４０ｃの文字列をサービスプロバイダ１０を介してＰＨＳ(Personal Handyphone System)６０ａ、６０ｂに送信するものであるから、本願発明の「情報配信システム」に対応し、引用刊行物２発明の「情報予約送信システム」と本願発明の「情報配信システム」とは、コンテンツサーバの有するコンテンツが配信サーバを介して情報端末へ配信されるという点で一致する。
　引用刊行物２発明の「得られた文字列に変化があった」ときとは、以前に得られた文字列と比べて変化があったときのことであり、更新されたときであることは、明らかであるから、本願発明の「コンテンツの更新を確認」したときに相当する。
　引用刊行物２発明の「得られた文字列」と、本願発明の「コンテンツのリスト」とは、「コンテンツに関する情報」という点で一致する。
　引用刊行物２発明の「インターネットサービスプロバイダ設備１０」は、「情報収集部１８」を備え、時間管理部２０によるスケジュール管理の下、データベース中の検索条件にしたがって他のＷＷＷサーバ部４０ａ〜４０ｃから検索条件に合致する文字列を取得し、得られた文字列に変化があったときに、ＰＨＳ(Personal Handyphone System)に得られた文字列を送信するように、動作することから、引用刊行物２発明の「インターネットサービスプロバイダ設備１０」と、本願発明の「配信サーバ」とは、各コンテンツサーバが有するコンテンツの更新を確認し、更新されたコンテンツに関する情報を情報端末に送信する更新確認手段を含む点で一致する。
　
　以上を総合して、両者は、
「情報端末と配信サーバとが第１ネットワークを介して接続され、かつ前記配信サーバと複数個のコンテンツサーバとが第２ネットワークを介して接続され、コンテンツサーバの有するコンテンツが前記配信サーバを介して前記情報端末へ配信される情報配信システムであって、
　前記配信サーバは各コンテンツサーバが有するコンテンツの更新を確認し、更新されたコンテンツに関する情報を前記情報端末に送信する更新確認手段を含むことを特徴とする情報配信システム。」の点で一致し、以下の点で相違している。
　
　
［相違点１］本願発明は、情報端末にて選択されたコンテンツサーバの有するコンテンツが配信サーバを介して前記情報端末へ配信されるのに対して、引用刊行物２発明では、ＷＷＷサーバ部４０ａ〜４０ｃの有する、ユーザ端末で設定された検索条件に合致した文字列を、インターネットサービスプロバイダ設備１０を介して、情報端末に配信されている点。
　
［相違点２］本願発明では、配信サーバが、更新されたコンテンツのリストを情報端末に送信するのに対して、引用刊行物２発明では、インターネットサービスプロバイダ設備１０が、ＷＷＷサーバ部４０ａ〜４０ｃの有する文字列に変化があったときに、変化があった文字列を情報端末に送信している点。
　
　
　（３）当審の判断
　
［相違点１について］
　情報端末（ＰＨＳ(Personal Handyphone System)）にて選択されたコンテンツサーバの有するコンテンツを配信サーバを介して前記情報端末へ配信することは、特開平１１−６８８２３号公報（第２図及び段落【００４６】参照。）及び特開平１１−１３６３６５号公報（特に、第１図及び段落【００１５】参照。）に示されるように、周知技術である。
　したがって、引用刊行物２発明において、上記周知技術を用いて、情報端末にて選択されたコンテンツサーバの有するコンテンツを配信サーバを介して前記情報端末へ配信することは、当業者が容易に想到し得ることである。
　
［相違点２について］
　更新を通知するために、更新された情報のリストを示すことは、引用刊行物１発明及び特開平７−４４４４１公報（第１７図参照。）に示されるように慣用技術である。
　したがって、引用刊行物２発明において、上記慣用技術を用いて、更新されたコンテンツのリストを情報端末に送信することは、当業者が適宜なし得る事項である。
　
　そして、本願発明の作用効果も、引用刊行物２発明、周知技術及び慣用技術から当業者が予測できる範囲のものである。
　
　（４）むすび
　
　以上のとおり、本願発明は、引用刊行物２発明、周知技術及び慣用技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　
　よって、結論のとおり審決する。