(57)【要約】【課題】  情報通知装置の負荷を低減し、また、ネットワークのトラフィックを低減して、情報の通知遅延や通知不達の発生を低減する。【解決手段】  通知保留時間登録手段１ａは、更新される情報の通知先端末３のユーザへの通知を保留する通知保留時間と、通知先端末３のユーザの状態とが対応付けられて登録される。更新情報受信手段１ｂは、情報更新端末２から更新された情報を受信する。通知先状態受信手段１ｃは、更新された情報の通知先である通知先端末３のユーザの状態を通知先端末３から受信する。通知保留時間取得手段１ｄは、通知先状態受信手段１ｃによって受信された通知先の状態に対応する通知保留時間を、通知保留時間登録手段１ａから取得する。情報通知手段１ｅは、通知保留時間取得手段１ｄより取得した通知保留時間保留して、情報更新端末２から受信した更新された最新の情報を、更新された情報の通知先である通知先端末３に送信する。【選択図】  図１
2005222225.tif 000002
【特許請求の範囲】
【請求項１】
更新情報を通知先に通知する情報通知装置において、
前記更新情報の前記通知先への通知を保留する通知保留時間と前記通知先の状態とが対応付けて登録された通知保留時間登録手段と、
前記更新情報を受信する更新情報受信手段と、
前記通知先の状態を受信する通知先状態受信手段と、
受信された前記通知先の状態に対応する前記通知保留時間を前記通知保留時間登録手段から取得する通知保留時間取得手段と、
前記通知保留時間保留して、受信された前記更新情報を前記通知先に通知する情報通知手段と、
を有することを特徴とする情報通知装置。
【請求項２】
前記通知先の識別子が登録された識別子登録手段をさらに有し、
前記情報通知手段は、前記識別子が登録されている前記通知先に対して前記更新情報を通知することを特徴とする請求項１記載の情報通知装置。
【請求項３】
前記更新情報を前記通知先に通知するための通知条件が登録された通知条件登録手段をさらに有し、
前記情報通知手段は、前記更新情報が前記通知条件を満たしている場合に前記更新情報を通知することを特徴とする請求項１記載の情報通知装置。
【請求項４】
前記更新情報の前記通知先への保留中に、前記更新情報が前記通知条件を満たさなくなったとき、前記情報通知手段は、前記更新情報を通知しないことを特徴とする請求項３記載の情報通知装置。
【請求項５】
前記通知保留時間取得手段は、前記更新情報の通知保留中に前記通知先の状態が更新されたとき、更新された状態に対応する前記通知保留時間を前記通知保留時間登録手段から取得することを特徴とする請求項１記載の情報通知装置。
【請求項６】
前記通知保留時間登録手段は、前記更新情報の更新元ごとに前記通知保留時間と前記通知先の状態とが登録されることを特徴とする請求項１記載の情報通知装置。
【請求項７】
前記更新情報に緊急に通知する必要があることを示す緊急通知情報が付加されている場合、前記情報通知手段は、前記更新情報を保留せずに通知することを特徴とする請求項１記載の情報通知装置。
【請求項８】
前記緊急通知情報は、前記更新情報を更新する情報更新端末において付加されることを特徴とする請求項７記載の情報通知装置。
【請求項９】
許可された情報更新端末によって、前記更新情報に前記緊急通知情報が付加されたか否かを判断する緊急通知情報判断手段を有することを特徴とする請求項７記載の情報通知装置。
【請求項１０】
更新情報を通知先に通知する情報通知プログラムにおいて、
コンピュータに、
前記更新情報の前記通知先への通知を保留する通知保留時間と前記通知先の状態とが対応付けて登録された通知保留時間登録手段、
前記更新情報を受信する更新情報受信手段、
前記通知先の状態を受信する通知先状態受信手段、
受信された前記通知先の状態に対応する前記通知保留時間を前記通知保留時間登録手段から取得する通知保留時間取得手段、
前記通知保留時間保留して、受信された前記更新情報を前記通知先に通知する情報通知手段、
として機能させることを特徴とする情報通知プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報通知装置に関し、特に更新される情報を通知先の状態に応じて通知する情報通知装置に関する。
【背景技術】
【０００２】
ある情報が更新された場合、その情報を通知してほしい場合がある。例えば、株を売買する者は、株を売買するための好タイミングを得るため、株価が更新されたときに株価の情報を通知してほしい。そこで従来、情報が更新されたときにその情報を提供するシステムとして、データベース監視システムがある（例えば、特許文献１参照）。このデータベース監視システムでは、複数の情報を管理し、情報に対して予め通知条件登録をしておく。そして、情報に対し通知条件を満たすような更新が行われた場合に、登録したユーザ端末に情報を通知する。よって、例えば、株価などを情報としてサーバ側で管理しておき、クライアント側の通知条件を登録しておく。クライアント側は、特定の銘柄が特定の株価になった場合に、サーバから通知を受けるということが可能となる。
【０００３】
また、株価などの情報だけでなく、人の在席状態を示す情報をサーバ側で管理しておけば、例えば、あるユーザが在席になった場合に、その旨を他のユーザに通知することにより、他のユーザがあるユーザとコミュニケーションを行うことができるというサービスも可能である。このような人の在席状態を扱う情報通知システムでは、ユーザがバディリストと呼ばれるユーザリストを設定すると、バディリストに登録したあるユーザの状態、例えば、インターネットへの「接続状態」、「在席」、「多忙」などが、他のユーザに通知される。他のユーザは、通知されたあるユーザの状態を参照し、適切なコミュニケーションを行うことができる。これら人の在席状態を扱う情報通知サービスは、一般的にＩＭ（インスタントメッセージ）と呼ばれ、すでにサービスとしてインターネット上で急速に普及している。
【０００４】
これらの情報通知サービスでは、ユーザ数の増加、情報の高精度化、詳細化、ならびに情報の更新頻度の増加によって、情報が頻繁かつ多数通知されるようになる。それに伴って情報通知サーバの負荷やネットワークのトラフィックが増大し、通知の遅延や不達が発生する可能性が高まってくる。例えば、人の位置情報がＧＰＳで測定できるようになると、情報の高精度化、詳細化、ならびに更新頻度の増加が進み、また、利便性の向上によりユーザ数もさらに増加すると予測される。これにより前述の情報通知サーバの負荷やネットワークのトラフィックがますます増大し、通知の遅延や不達が発生する可能性がさらに高まる。
【０００５】
このような通知の遅延や不達を回避する手段として、高速ネットワーク回線を導入し、情報通知サーバを複数設置することにより、情報通知サーバの負荷を分散することが可能となる。しかし、情報通知サーバを複数設置し、高速ネットワーク回線の導入などを行うと、運用コストが増大してしまう。
【０００６】
また、複数の宛て先に情報を通知する際、個々の通知先ユーザの状態と情報の優先度に基づいて、通知の余裕時間を算出する情報配信方法がある（例えば、特許文献２参照）。この方法によれば、余裕時間の短いユーザから優先して通知することで遅延を回避できるが、装置に一定の処理能力が要求される。
【０００７】
また、インターネットから受信したメールの着信通知を行うシステムにおいて、メール配信装置が、端末へメール着信通知を送信する条件を、送信に失敗した理由に基づいて変化させるシステムがある（例えば、特許文献３参照）。このシステムによれば、端末の待ち受け状態に応じたきめ細かな着信通知を行い、着信の失敗率を低減している。なお、このシステムは、送信に失敗した理由に基づいて、端末が圏外にいる場合は再送までの時間を長くしたり、端末が話中の場合には再送までの時間を短くしたりしている。
【０００８】
また、メールの再送機能を有する電子メールシステムにおいて、各メールの再送パラメータをユーザ側で自由に、かつ容易に設定できるようにした電子メールシステムがある（例えば、特許文献４参照）。
【０００９】
また、到着通知禁止時間帯であっても、重要度の高い電子メールでかつ特定の相手からの電子メールの場合は、情報を通知するようにした電子メール到着通知方法がある（例えば、特許文献５参照）。
【特許文献１】特開平９−２８２２１０号公報（段落番号〔００１３〕〜〔００１８〕、図１、図６）
【特許文献２】特開２００２−３１４６１０号公報（段落番号〔００３０〕〜〔００６２〕、図３〜図７）
【特許文献３】特開２００２−１１１７０７号公報（段落番号〔００４４〕、図１２）
【特許文献４】特開平１１−６５９６１号公報（段落番号〔００２４〕、図４）
【特許文献５】特開２０００−２０４１８号公報（段落番号〔００１３〕〜〔００１７〕、図１〜図３）
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかし上述した従来の方法では、頻繁かつ多数発生する情報の通知に対し、物理的な改善策によって遅延や不達を回避しており、装置自体の処理能力やネットワークの上限伝送速度などの物理的な限界値を超える通知が発生するケースには適用できないという問題点がある。
【００１１】
本発明はこのような点に鑑みてなされたものであり、装置自体の処理能力やネットワークの伝送速度を上げるなどの物理的な解決手段によらず、通知遅延や通知不達が発生する可能性を低減することができる情報通知装置を提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明では上記問題を解決するために、更新情報を通知先に通知する情報通知装置１において、更新情報の通知先への通知を保留する通知保留時間と通知先の状態とが対応付けて登録された通知保留時間登録手段１ａと、更新情報を受信する更新情報受信手段１ｂと、通知先の状態を受信する通知先状態受信手段１ｃと、受信された通知先の状態に対応する通知保留時間を通知保留時間登録手段１ａから取得する通知保留時間取得手段１ｄと、通知保留時間保留して、受信された更新情報を通知先に通知する情報通知手段１ｅと、を有することを特徴とする情報通知装置１が提供される。
【００１３】
このような情報通知装置１によれば、通知保留時間登録手段１ａを参照することにより通知保留時間が得られるため、装置自体の処理能力を上げるなどの物理的な解決手段によらずに情報通知装置１の負荷が低減される。また、更新情報が保留されて通知先に通知されるため、ネットワークの伝送速度を上げるなどの物理的な解決手段によらずにネットワークのトラフィックが低減される。
【発明の効果】
【００１４】
本発明の情報通知装置では、更新情報の通知先の状態に応じた通知保留時間を通知保留時間登録手段より取得する。そして、取得した通知保留時間保留して、更新された最新の更新情報を通知先に通知するようにした。これによって、情報通知装置の負荷が低減され、また、ネットワークのトラフィックが低減されるので、装置自体の処理能力やネットワークの伝送速度を上げるなどの物理的な解決手段によらずに、情報の通知遅延や通知不達が発生する可能性を低減することができる。
【発明を実施するための最良の形態】
【００１５】
以下、本発明の原理を図面を参照して詳細に説明する。
図１は、本発明の原理を説明する原理図である。
図に示すように、情報通知装置１は、情報更新端末２と通知先端末３と接続されている。情報更新端末２は、例えば、株価などの更新される情報を、情報通知装置１を介して通知先端末３に提供する端末である。通知先端末３は、更新される情報の通知を受ける端末である。通知先端末３を使用するユーザは、更新される情報を通知先端末３で受信することによって、更新される情報を受けることができる。
【００１６】
情報通知装置１は、情報更新端末２から送られてくる更新される情報を、通知先（通知先端末３を使用するユーザ）の状態に応じて保留し、通知先端末３に送信する。情報通知装置１は、通知保留時間登録手段１ａ、更新情報受信手段１ｂ、通知先状態受信手段１ｃ、通知保留時間取得手段１ｄ、および情報通知手段１ｅを有している。
【００１７】
通知保留時間登録手段１ａには、更新される情報の通知先への通知を保留する通知保留時間と、通知先端末３のユーザの状態とが対応付けて登録されている。例えば、在席中、離席中、電話中というそれぞれのユーザの状態に対し、通知保留時間が決められ、それらが対応付けられて登録されている。
【００１８】
更新情報受信手段１ｂは、情報更新端末２から更新された情報を受信する。
通知先状態受信手段１ｃは、更新された情報の通知先の状態、すなわち、通知先端末３のユーザの状態を、通知先端末３から受信する。
【００１９】
通知保留時間取得手段１ｄは、通知先状態受信手段１ｃによって受信された通知先の状態に対応する通知保留時間を、通知保留時間登録手段１ａを参照して取得する。
情報通知手段１ｅは、通知保留時間取得手段１ｄが取得した通知保留時間保留して、更新情報受信手段１ｂが受信した更新された最新の情報を、通知先である通知先端末３に送信する。
【００２０】
以下、原理図の動作について説明する。
情報更新端末２は、例えば株価など、情報が更新されると、更新された情報を情報通知装置１に送信する。
【００２１】
情報通知装置１の更新情報受信手段１ｂは、情報更新端末２から更新された情報を受信する。通知先状態受信手段１ｃは、更新された情報の通知先である通知先端末３のユーザの状態を、通知先端末３から受信する。
【００２２】
通知保留時間取得手段１ｄは、通知先状態受信手段１ｃによって受信された通知先の状態に対応する通知保留時間を、通知保留時間登録手段１ａを参照して取得する。
情報通知手段１ｅは、通知保留時間取得手段１ｄが取得した通知保留時間保留して、情報更新端末２から更新された最新の情報を、通知先である通知先端末３に送信する。また、保留中に新たに情報更新が発生したときは、通知先端末３に送信せず抑制する。
【００２３】
このように、情報通知装置１は、情報の通知先の状態に応じた通知保留時間を、通知保留時間登録手段１ａを参照して取得する。そして、取得した保留時間保留して、情報更新端末２から更新された最新の情報を、通知先に送信する。また、保留中に発生する情報更新は通知先に送信せず抑制する。従って、通知保留時間内に発生する情報更新の通知が抑制されるため、情報通知装置１の負荷とネットワークのトラフィックが低減される。よって、装置自体の処理能力やネットワークの伝送速度を上げるなどの物理的な解決手段によらずに、情報の通知遅延や通知不達が発生する可能性を低減することができる。
【００２４】
次に、本発明の第１の実施の形態を図面を参照して詳細に説明する。
図２は、第１の実施の形態に係る情報通知サーバのシステム構成例を示した図である。
図に示すように、情報通知サーバ１０は、例えば、インターネットであるネットワーク４０を介して、情報更新端末２１および通知先端末３１，３２と接続されている。
【００２５】
情報更新端末２１は、情報を提供する端末であり、情報が更新されたとき、更新された情報を情報通知サーバ１０に送信する。情報には、例えば、情報更新端末２１を使用するユーザの状態を示す情報、例えば、電話中、在席中、離席中などを示す情報がある。情報更新端末２１は、ユーザの状態が更新されたとき（変化があったとき）、ユーザの状態を示す情報を情報通知サーバ１０に送信する。また、情報の他の例として、株価がある。株価が更新されたとき、情報更新端末２１は、株価を情報通知サーバ１０に送信する。
【００２６】
情報通知サーバ１０は、情報更新端末２１から情報を受信すると、情報の通知先であるユーザの通知先端末３１，３２に受信した情報を送信する。このとき情報通知サーバ１０は、送信する情報を所定時間保留して送信する。
【００２７】
送信する情報の保留時間は、通知先端末３１，３２を使用するユーザの状態に関連付けられ、情報通知サーバ１０の有するテーブルに登録されている。情報通知サーバ１０は、通知先端末３１，３２を使用するユーザの状態に応じた保留時間を、テーブルを参照して取得する。例えば、通知先端末３１を使用しているユーザが離席中のとき、電話中のときとで異なった保留時間を取得する。
【００２８】
通知先端末３１，３２は、情報通知サーバ１０から情報を受信し、モニタに情報を表示する。これによって、通知先端末３１，３２を使用するユーザは、情報更新端末２１から情報を得ることができる。
【００２９】
このように、情報通知サーバ１０は、情報の通知先である通知先端末３１，３２のユーザの状態に応じた保留時間を、テーブルを参照して取得する。そして、取得した保留時間保留して、更新された最新の情報を通知先端末３１，３２に送信する。これによって、情報通知サーバ１０の装置自体の負荷やネットワーク４０のトラフィックを低減することができ、情報の通知遅延や通知不達が発生する可能性を低減することができる。
【００３０】
なお、情報更新端末２１、通知先端末３１，３２は、図２に示した台数に限られるものではなく、複数であってよい。
次に、情報通知サーバ１０のハードウェア構成について説明する。
【００３１】
図３は、情報通知サーバのハードウェア構成を示したブロック図である。
図に示す情報通知サーバ１０は、ＣＰＵ(Central Processing Unit)１０ａによって装置全体が制御されている。ＣＰＵ１０ａには、バス１０ｇを介してＲＡＭ(Random Access Memory)１０ｂ、ハードディスクドライブ(ＨＤＤ:Hard Disk Drive)１０ｃ、グラフィック処理装置１０ｄ、入力インターフェース１０ｅ、および通信インターフェース１０ｆが接続されている。
【００３２】
ＲＡＭ１０ｂには、ＣＰＵ１０ａに実行させるＯＳ(Operating System)のプログラム、情報を保留して通知するためのアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０ｂには、ＣＰＵ１０ａによる処理に必要な各種データが保存される。ＨＤＤ１０ｃには、ＯＳやアプリケーションプログラムなどが格納される。
【００３３】
グラフィック処理装置１０ｄには、モニタ１０ｈが接続されている。グラフィック処理装置１０ｄは、ＣＰＵ１０ａからの命令に従って、画像をモニタ１０ｈの表示画面に表示させる。入力インターフェース１０ｅには、キーボード１０ｉと、マウス１０ｊとが接続されている。入力インターフェース１０ｅは、キーボード１０ｉやマウス１０ｊから送られてくる信号を、バス１０ｇを介してＣＰＵ１０ａに送信する。
【００３４】
通信インターフェース１０ｆは、ネットワーク４０と接続される。通信インターフェース１０ｆは、ＣＰＵ１０ａからの命令に従って、ネットワーク４０に接続されている他のコンピュータと通信することができる。
【００３５】
以上のようなハードウェア構成によって、情報通知サーバ１０は、情報通知処理を実行することができる。なお、情報更新端末２１および通知先端末３１，３２も図３と同様のハードウェア構成を有する。
【００３６】
次に、情報通知サーバ１０の機能について説明する。
図４は、情報通知サーバの機能ブロック図である。
図に示すように情報通知サーバ１０は、状態情報更新受付け部１１、通知保留制御部１２、状態情報通知部１３、通知条件管理テーブル１４、状態情報管理テーブル１５、通知保留時間管理テーブル１６、および保留制御管理テーブル１７を有している。通知条件管理テーブル１４、状態情報管理テーブル１５、通知保留時間管理テーブル１６、および保留制御管理テーブル１７は、図３に示したＨＤＤ１０ｃまたはＲＡＭ１０ｂの記憶装置に構築される。なお、以下では、情報更新端末２１から送られてくる情報として、情報更新端末２１を使用するユーザの状態を示す情報（状態情報）が送られてくるとする。
【００３７】
まず、情報通知サーバ１０の各テーブルのデータ構成例について説明する。
図５は、通知条件管理テーブルのデータ構成例を示した図である。
通知条件管理テーブル１４には、状態情報を更新するユーザのユーザ識別子と、状態情報が通知されるユーザのユーザ識別子が格納される。図に示すように通知条件管理テーブル１４は、更新者ユーザＩＤ、通知先ユーザＩＤの欄を有している。更新者ユーザＩＤの欄には、状態情報を提供、更新するユーザ（情報更新端末２１を使用するユーザ）に付与されているユーザ識別子が格納される。通知先ユーザＩＤの欄には、状態情報の通知を受けるユーザ（通知先端末３１，３２を使用するユーザ）に付与されているユーザ識別子が格納される。なお、以下では、情報更新端末２１を使用するユーザのユーザ識別子をＵｓｅｒ−Ｃ、通知先端末３１，３２を使用するユーザのユーザ識別子をＵｓｅｒ−Ａ，Ｕｓｅｒ−Ｂとする。
【００３８】
図５の例では、通知条件管理テーブル１４の更新者ユーザＩＤの欄には、Ｕｓｅｒ−Ｃの識別子が格納されている。通知先ユーザＩＤの欄には、Ｕｓｅｒ−Ａ，Ｕｓｅｒ−Ｂの識別子が格納されている。よって、情報更新端末２１を使用するユーザによって更新される状態情報は、通知先端末３１，３２を使用するユーザに通知されることがわかる。
【００３９】
図６は、状態情報管理テーブルのデータ構成例を示した図である。
状態情報管理テーブル１５には、状態情報を更新するユーザと、状態情報の通知を受けるユーザの現在の状態が格納される。図に示すように状態情報管理テーブル１５は、ユーザＩＤ、状態、位置の欄を有している。ユーザＩＤの欄には、ユーザ識別子が格納される。ユーザＩＤの欄には、状態情報を更新するユーザ、状態情報の通知を受けるユーザの両方のユーザ識別子が格納される。状態の欄には、ユーザＩＤに対応したユーザの状態が格納される。位置の欄には、ユーザが所在している位置が格納される。
【００４０】
図６の例では、ユーザＩＤの欄には、Ｕｓｅｒ−Ａ，Ｕｓｅｒ−Ｂ，Ｕｓｅｒ−Ｃが格納されている。ユーザＩＤのＵｓｅｒ−Ａに対応する状態の欄には、在席中が格納されている。ユーザＩＤのＵｓｅｒ−Ａに対応する位置の欄には、事務所が格納されている。これによって、通知先端末３１を使用するユーザの現在の状態は在席中であり、その位置は事務所であることがわかる。また、ユーザＩＤのＵｓｅｒ−Ｃに対応する状態の欄には、電話中が格納されている。ユーザＩＤのＵｓｅｒ−Ｃに対応する位置の欄には、事務所が格納されている。これによって、情報更新端末２１を使用するユーザの現在の状態は電話中であり、その位置は事務所であることがわかる。
【００４１】
図７は、通知保留時間管理テーブルのデータ構成例を示した図である。
通知保留時間管理テーブル１６には、状態情報の通知を受けるための条件となるユーザの状態と、状態情報の通知を保留する通知保留時間が対応付けて格納される。図に示すように通知保留時間管理テーブル１６は、通知先ユーザＩＤの欄、状態条件の欄、通知保留時間の欄を有している。通知先ユーザＩＤの欄には、状態情報の通知を受けるユーザのユーザ識別子が格納される。状態条件の欄には、状態情報の通知を受けるユーザに対する通知保留時間を決定するための状態条件が格納される。通知保留時間の欄には、状態情報の通知を保留する時間が格納される。
【００４２】
図７の例では、通知先ユーザＩＤの欄には、Ｕｓｅｒ−Ａ，Ｕｓｅｒ−Ｂが格納されている。Ｕｓｅｒ−Ａに対する状態条件の欄には、在席中、電話中、離席中が格納されている。Ｕｓｅｒ−Ａの状態条件が在席中に対する通知保留時間の欄には、１０秒が格納されている。Ｕｓｅｒ−Ａの状態条件が電話中に対する通知保留時間の欄には、１分が格納されている。Ｕｓｅｒ−Ａの状態条件が離席中に対する通知保留時間の欄には、６０分が格納されている。また、Ｕｓｅｒ−Ｂの状態条件が在席中に対する通知保留時間の欄には、０秒が格納されている。Ｕｓｅｒ−Ｂの状態条件が電話中に対する通知保留時間の欄には、３０秒が格納されている。Ｕｓｅｒ−Ｂの状態条件が離席中に対する通知保留時間の欄には、３０分が格納されている。これによって、通知先端末３１，３２を使用するユーザの状態に対する、状態情報を保留する時間がわかる。
【００４３】
なお、通知保留時間は、状態情報をユーザに通知すると、その状態情報が参照される可能性が高い状態、例えば、在席状態にあるときには、短くするように設定する。そして、状態情報をユーザに通知しても参照されない可能性が高い状態、例えば、離席状態にあるときには、長くするように設定する。
【００４４】
図８は、保留制御管理テーブルのデータ構成例を示した図である。
保留制御管理テーブル１７には、状態情報の通知が保留されているユーザを管理するために必要なデータが格納される。状態情報の通知の保留が終了したときには、通知が保留されていたユーザのデータは、保留制御管理テーブル１７から削除される。図に示すように保留制御管理テーブル１７は、通知先ユーザＩＤ、通知保留開始日時、および更新者ユーザＩＤの欄を有している。通知先ユーザＩＤの欄には、状態情報が通知されるユーザのユーザ識別子が格納される。通知保留開始日時の欄には、状態情報の通知の保留が開始された日時が格納される。更新者ユーザＩＤの欄には、状態情報を更新するユーザのユーザ識別子が格納される。
【００４５】
図８の例では、通知先ユーザＩＤの欄には、Ｕｓｅｒ−Ａ，Ｕｓｅｒ−Ｂが格納されている。Ｕｓｅｒ−Ａに対応する通知保留開始日時の欄には、２００３／０３／２６／１２：００：００が格納されている。Ｕｓｅｒ−Ａに対応する更新者ユーザＩＤの欄には、Ｕｓｅｒ−Ｃが格納されている。また、Ｕｓｅｒ−Ｂに対応する通知保留開始日時の欄には、２００３／０３／２６／１２：００：００が格納されている。Ｕｓｅｒ−Ｂに対応する更新者ユーザＩＤの欄には、Ｕｓｅｒ−Ｃが格納されている。これによって、Ｕｓｅｒ−Ａ，Ｕｓｅｒ−Ｂのユーザ識別子を有するユーザが、現在、状態情報の通知が保留されていることがわかる。また、通知の保留が開始された日時と、状態情報を更新しているユーザのユーザ識別子がわかる。
【００４６】
図４の説明に戻る。
状態情報更新受付け部１１は、ネットワーク４０を介して、情報更新端末２１から更新された状態情報と、情報更新端末２１を使用するユーザの所在している位置とを受信する。また、状態情報更新受付け部１１は、ネットワーク４０を介して、通知先端末３１，３２を使用するユーザの状態（状態情報）と、そのユーザの所在している位置とを受信する。状態情報更新受付け部１１は、情報更新端末２１、通知先端末３１，３２から受信した状態情報および位置を、図６に示したように状態情報管理テーブル１５に格納する。
【００４７】
通知保留制御部１２は、通知条件管理テーブル１４を参照し、状態情報更新受付け部１１が受信した、更新された状態情報に対する通知先を取得する。例えば、更新された状態情報が、Ｕｓｅｒ−Ｃによって送信されたものであるとすると、通知保留制御部１２は、通知条件管理テーブル１４より、通知先のユーザ識別子であるＵｓｅｒ−Ａ，Ｕｓｅｒ−Ｂを取得することができる。
【００４８】
また、通知保留制御部１２は、保留制御管理テーブル１７を参照し、更新された状態情報の通知先のユーザが、通知の保留中の状態にあるユーザであるか否かを判断する。例えば、保留制御管理テーブル１７の通知先ユーザＩＤの欄にユーザ識別子が格納されているユーザは、通知の保留中の状態にあるユーザと判断することができる。また、通知先ユーザＩＤの欄にユーザ識別子が格納されていないユーザは、通知の保留中の状態にないユーザと判断することができる。通知保留制御部１２は、状態情報が通知されるユーザが、通知の保留中の状態にないユーザであった場合には、そのユーザ識別子と、通知保留開始日時（現在の日時）と、状態情報を更新した更新ユーザのユーザ識別子とを、保留制御管理テーブル１７に格納する。
【００４９】
また、通知保留制御部１２は、状態情報管理テーブル１５を参照して通知先のユーザの状態を取得し、取得した通知先のユーザの状態に対応する通知保留時間を、通知保留時間管理テーブル１６を参照して取得する。そして、通知保留制御部１２は、保留制御管理テーブル１７より、通知先のユーザの通知保留開始日時を取得して、通知保留時間を加算した保留日時を算出し、現在日時が保留日時を経過したか否かを判断する。すなわち、通知保留制御部１２は、現在日時が、状態情報を保留すべき日時を経過したか否かを判断することによって、状態情報が通知保留時間保留されたかを判断する。通知保留制御部１２は、現在日時が保留日時を経過した場合、状態情報の通知が保留されるユーザのデータを保留制御管理テーブル１７から削除する。
【００５０】
状態情報通知部１３は、通知保留制御部１２より、状態情報を保留すべき日時が経過したと判断された場合、状態情報管理テーブル１５から通知先に通知する状態情報を取得し、ネットワーク４０を介して、通知先の通知先端末３１，３２に送信する。すなわち、状態情報通知部１３は、状態情報が通知保留時間保留されてから、通知先である通知先端末３１，３２に状態情報を送信する。
【００５１】
次に、情報更新端末２１の機能について説明する。
図９は、情報更新端末の機能ブロック図である。
図に示すように情報更新端末２１は、状態変化検出部２１ａ、状態情報更新要求部２１ｂを有している。
【００５２】
状態変化検出部２１ａは、ユーザの状態の変化を検出する。ユーザの状態の変化、例えば、在席中や離席中の状態の変化は、キーボードやマウスなどの入力装置への入力の有無、ネットワーク４０への接続の有無により、検出することができる。また、電話中の状態変化は、例えば、ユーザが使用する電話の回線より信号を検出することにより可能である。また、ユーザに直接キーボードまたはマウスから状態を入力させることにより、状態の変化を検出（取得）することができる。また、状態変化検出部２１ａは、同様にしてユーザの所在する位置も検出する。
【００５３】
状態情報更新要求部２１ｂは、ネットワーク４０を介して、情報通知サーバ１０に対し状態情報、位置を送信し、状態情報の更新を要求する。情報通知サーバ１０の状態情報更新受付け部１１は、情報更新端末２１の更新要求に応じて状態情報、位置を受信し、状態情報管理テーブル１５の状態、位置の欄を更新する。
【００５４】
次に、通知先端末３１の機能について説明する。
図１０は、通知先端末の機能ブロック図である。
図に示すように通知先端末３１は、状態変化検出部３１ａ、状態情報更新要求部３１ｂ、状態情報受信部３１ｃ、および状態情報表示部３１ｄを有している。
【００５５】
状態変化検出部３１ａは、ユーザの状態の変化を検出する。ユーザの状態の変化、例えば、在席中や離席中の状態の変化は、キーボードやマウスなどの入力装置への入力の有無、ネットワーク４０への接続の有無により、検出することができる。また、電話中の状態変化は、例えば、ユーザが使用する電話の回線より信号を検出することにより可能である。また、ユーザに直接キーボードまたはマウスから状態を入力させることにより、状態の変化を検出（取得）することができる。また、状態変化検出部３１ａは、同様にしてユーザの所在する位置も検出する。
【００５６】
状態情報更新要求部３１ｂは、ネットワーク４０を介して、情報通知サーバ１０に対し状態情報、位置を送信し、状態情報の更新を要求する。情報通知サーバ１０の状態情報更新受付け部１１は、情報更新端末２１の更新要求に応じて状態情報、位置を受信し、状態情報管理テーブル１５の状態、位置の欄を更新する。
【００５７】
状態情報受信部３１ｃは、情報通知サーバ１０から送信されてくる状態情報を受信する。状態情報表示部３１ｄは、状態情報受信部３１ｃより受信された状態情報をモニタに表示する。ここで、モニタに表示される状態情報の画面例について説明する。
【００５８】
図１１は、通知先端末のモニタに表示される画面例である。
通知先端末のモニタには、図に示すようなユーザ状態一覧の画面３１ｅが表示される。画面３１ｅに示すようにモニタには、ユーザＩＤ、状態、および位置の欄が表示される。ユーザＩＤの欄には、状態情報を提供、更新する情報更新端末２１を使用するユーザのユーザ識別子が表示される。なお、Ｕｓｅｒ−Ｄ，Ｕｓｅｒ−Ｅは、情報更新端末２１を使用するユーザのユーザ識別子である。状態の欄には、各ユーザの状態が表示される。位置の欄には、各ユーザの所在している位置が表示される。これによって、例えば、通知先端末３１を使用するユーザは、情報更新端末２１を使用しているユーザがコミュニケーションを取れる状況にあるか否かを判断することができる。
【００５９】
なお、通知先端末３２も図１０と同様の機能を有している。
次に、フローチャートを用いて、情報通知サーバ１０、情報更新端末２１、通知先端末の処理の流れを説明する。
【００６０】
まず、情報更新端末２１の処理の流れについて説明する。
図１２は、情報更新端末の処理の流れを示したフローチャートである。
ステップＳ１において、情報更新端末２１の状態変化検出部２１ａは、ユーザの状態が変化したか否かを検出する。ユーザの状態が変化しない場合、ステップＳ１を繰り返す。ユーザの状態が変化した場合、ステップＳ２に進む。
【００６１】
ステップＳ２において、情報更新端末２１の状態情報更新要求部２１ｂは、情報通知サーバ１０に対し状態情報および位置を送信し、状態情報の更新を要求する。
このように、情報更新端末２１は、ユーザの状態の変化を検出し、情報通知サーバ１０に対し状態情報の更新を要求する。
【００６２】
次に、通知先端末３１の処理の流れについて説明する。
図１３は、通知先端末の処理の流れを示したフローチャートである。
ステップＳ１１において、通知先端末３１の状態情報受信部３１ｃは、情報通知サーバ１０から送信されてくる状態情報の受信待ちをする。状態情報が情報通知サーバ１０より送信されて来ない間は、状態情報の受信待ちを繰り返す。状態情報が情報通知サーバ１０より送信されて来た場合には、ステップＳ１２へ進む。
【００６３】
ステップＳ１２において、通知先端末３１の状態情報表示部３１ｄは、状態情報受信部３１ｃより受信された状態情報をモニタに表示する。これによって、通知先端末３１のモニタには、図１１に示すような画面３１ｅを表示することができ、通知先端末３１を使用するユーザは、例えば、情報更新端末２１を使用しているユーザとコミュニケーションを取ることができるか否かを判断することができる。
【００６４】
なお、通知先端末３１においても、ユーザの状態の変化を検出し、情報通知サーバ１０に対し状態情報の更新を要求する。この処理の流れは、図１２に示したフローチャートと同様であり、その説明を省略する。
【００６５】
次に、情報通知サーバ１０の処理の流れについて説明する。
図１４は、情報通知サーバの処理の流れを示したフローチャートである。
ステップＳ３１において、情報通知サーバ１０の状態情報更新受付け部１１は、情報更新端末２１、通知先端末３１，３２から状態情報の更新要求があったか否かを判断する。情報更新端末２１、通知先端末３１，３２から状態情報の更新要求があった場合、ステップＳ３２へ進む。状態情報の更新要求がなかった場合、状態情報の更新要求を待ち続ける。
【００６６】
ステップＳ３２において、情報通知サーバ１０の状態情報更新受付け部１１は、情報更新端末２１、通知先端末３１，３２からユーザの状態情報、位置を受信し、状態情報管理テーブル１５を更新する。これにより、状態情報管理テーブル１５には、状態情報を更新するユーザと、状態情報の通知を受けるユーザの現在の状態、位置が格納される。
【００６７】
ステップＳ３３において、情報通知サーバ１０の通知保留制御部１２は、通知条件管理テーブル１４より、更新された状態情報を通知する通知先のユーザＩＤ（識別子）を検索する。
【００６８】
ステップＳ３４において、情報通知サーバ１０の通知保留制御部１２は、通知条件管理テーブル１４より、更新された状態情報を通知する通知先のユーザＩＤを検索できたか否かを判断する。通知条件管理テーブル１４よりユーザＩＤが検索できた場合は、状態情報を通知すべき通知先があるとして、ステップＳ３５へ進む。なお、ステップＳ３５以下のステップでは、通知先ごとに処理が実行される。通知条件管理テーブル１４よりユーザＩＤが検索できなかった場合は、状態情報を通知すべき通知先がないとして、ステップＳ３１へ進む。
【００６９】
ステップＳ３５において、情報通知サーバ１０の通知保留制御部１２は、通知先のユーザが保留制御管理テーブル１７に登録されているか検索する。
ステップＳ３６において、情報通知サーバ１０の通知保留制御部１２は、保留制御管理テーブル１７から通知先のユーザが検索できたか否かを判断する。保留制御管理テーブル１７から通知先のユーザが検索できた場合、すなわち、通知先のユーザが通知の保留中にあるユーザである場合は、ステップＳ３１へ進む。保留制御管理テーブル１７から通知先のユーザが検索できなかった場合、すなわち、通知先のユーザが通知の保留中にないユーザである場合は、ステップＳ３７へ進む。
【００７０】
ステップＳ３７において、情報通知サーバ１０の通知保留制御部１２は、保留制御管理テーブル１７に、通知先のユーザのユーザＩＤと、現在の日時（通知保留開始日時）と、状態情報を更新した更新ユーザのユーザＩＤとを登録する。
【００７１】
ステップＳ３８において、情報通知サーバ１０の通知保留制御部１２は、状態情報管理テーブル１５から通知先のユーザの状態を取得する。
ステップＳ３９において、情報通知サーバ１０の通知保留制御部１２は、通知保留時間管理テーブル１６を参照し、ステップＳ３８において取得した通知先のユーザの状態に対応する通知保留時間を取得する。そして、通知保留制御部１２は、保留制御管理テーブル１７より、通知先のユーザの通知保留開始日時を取得して、通知保留時間を加算した保留日時を算出し、現在日時が保留日時を経過したか否かを判断する。現在日時が保留日時を過ぎていた場合は、ステップＳ４１へ進む。現在日時が保留日時を過ぎていない場合は、ステップＳ３８へ進む。
【００７２】
ステップＳ４１において、情報通知サーバ１０の通知保留制御部１２は、現在日時が保留日時を過ぎたユーザのデータを保留制御管理テーブル１７から削除する。すなわち、状態情報の通知を保留する必要のなくなったユーザのデータを保留制御管理テーブル１７から削除する。
【００７３】
ステップＳ４２において、情報通知サーバ１０の状態情報通知部１３は、状態情報管理テーブル１５から通知する状態情報を取得し、通知先の通知先端末３１，３２に送信する。すなわち、通知の保留が解除された通知先のユーザの通知先端末３１，３２に、状態情報が送信される。
【００７４】
次に、情報通知サーバ１０、情報更新端末２１、および通知先端末３１，３２の間で行われる処理シーケンスについて説明する。
図１５は、従来の情報通知サーバ、情報更新端末、および通知先端末の間で行われる処理シーケンスを示した図である。
【００７５】
図に示すように情報更新端末は、３０秒周期で状態情報の更新を情報通知サーバに要求するものとする。また、情報通知サーバが行う状態情報更新処理と更新通知処理は、図１５の右下に示すように模様によって分けてある。
【００７６】
情報通知サーバは、情報更新端末から状態情報の更新要求を受けると、状態情報更新処理を行う。そして、２つの通知先端末に更新通知処理を行う。従来では、通知の保留が行われないため、２つの通知先端末の両方に常に３０秒周期で更新通知が行われ、状態情報が送信される。つまり、通知先端末のユーザが離席中である場合にも、常に３０秒周期で状態情報が送信され、情報通知サーバの処理能力が無駄に使用されていることになる。また、ネットワークのトラフィックも無駄に使用されていることになる。また、情報更新端末の更新間隔が短くなる、あるいは、通知先端末の数が増加すると、状態情報の通知が増加し、それに伴って情報通知サーバの負荷やネットワークのトラフィックが増大し、通知の遅延や不達が発生する可能性が高まる。
【００７７】
図１６は、本発明の情報通知サーバ、情報更新端末、および通知先端末の間で行われる処理シーケンスを示した図である。
図に示すように情報更新端末２１は、図１５で示したのと同様に３０秒周期で状態情報の更新を情報通知サーバ１０に要求するものとする。また、情報通知サーバ１０が行う状態情報更新処理、更新通知処理、および通知保留処理は、図１６の右下に示すように模様によって分けてある。また、通知先端末３１を使用するユーザの状態は電話中にあるとし、通知先端末３２を使用するユーザの状態は離席中の状態にあるとする。そうすると、通知保留時間管理テーブル１６より、通知先端末３１を使用するユーザに対する通知の保留時間は１分である。通知保留時間管理テーブル１６より、通知先端末３２を使用するユーザに対する通知の保留時間は３０分である。
【００７８】
図に示すように情報通知サーバ１０は、通知保留処理を行うことにより、状態情報更新の契機ごとには通知先端末に対して状態情報の通知を行わない。「電話中」状態である通知先端末３１のユーザに対しては、通知が１分間保留されることにより１分３０秒周期で通知が行われる。また「離席中」である通知先端末３２のユーザに対しては、通知が３０分間保留されることにより３０分３０秒周期で通知が行われる。通知保留処理中に発生する状態情報の更新に対し、通知処理が抑制されることにより、通知先端末３１のユーザに対しては、３回の状態情報更新で１回の通知を行う。すなわち、２回の通知が抑制される。また、通知先端末３２のユーザに対しては、６０回の状態情報更新で１回の通知が行われる。すなわち、５９回の通知が抑制される。
【００７９】
なお、図１５、図１６では、説明を簡単にするために情報更新装置が状態情報を更新する間隔を一定時間周期としているが、実際には情報更新装置が状態情報を更新する間隔は不定期である。
【００８０】
このように、情報通知サーバ１０は、状態情報の通知先である通知先端末３１，３２のユーザの状態に応じた保留時間を、保留制御管理テーブル１７を参照して取得する。そして、取得した保留時間保留して、情報更新端末２１から更新された最新の情報を、通知先端末３１，３２に送信する。また、通知先のユーザの状態が状態情報の通知を行っても参照されない可能性が高い状態のときに通知保留時間を長くし、保留中に発生する情報更新は通知先に送信しないようにすることにより、無駄な状態情報の通知を抑制することができる。これによって、情報通知サーバ１０の負荷が低減され、また、ネットワーク４０のトラフィックが低減されるので、装置自体の処理能力やネットワークの伝送速度を上げるなどの物理的な解決手段によらずに、情報の通知遅延や通知不達が発生する可能性を低減することができる。
【００８１】
また、図１４のステップＳ３８〜Ｓ４０で説明したように、情報通知サーバ１０は、状態情報管理テーブル１５から通知先ユーザの状態を取得し、取得した通知先のユーザの状態に対応する通知保留時間を、通知保留時間管理テーブル１６から取得する。そして、保留制御管理テーブル１７より、通知先のユーザの通知保留開始日時を取得して通知保留時間を加算した保留日時を算出し、現在日時が保留日時を経過したか否かの判断を行う。情報通知サーバ１０は、これらのステップを現在日時が保留日時を過ぎるまで繰り返す。
【００８２】
これによって、情報の通知保留中に通知先の状態が更新されたとき、更新された状態に対応する通知保留時間が取得される。よって、通知先のユーザの状態に即座に対応して、通知保留時間が変更されるので、通知先のユーザは有効に状態情報の通知を受けることができる。
【００８３】
また、状態情報が所定の通知条件を満たした場合に、状態情報を保留して通知先に通知することもできる。
図１７は、通知条件管理テーブルのデータ構成例の他の例を示した図である。
【００８４】
図に示すように通知条件管理テーブル１４ａは、図５に示した通知条件管理テーブル１４に対し、更新者位置条件の欄が設けられている。更新者位置条件の欄には、情報を通知するための、更新者（情報更新端末２１を使用するユーザ）が所在する位置の条件が格納される。通知保留制御部１２は、通知条件管理テーブル１４ａを参照し、状態情報とともに送られてくる更新者の位置が、更新者位置条件に合致するか否かを判断する。通知保留制御部１２は、更新者の位置が更新者位置条件に合致した場合、状態情報の通知を保留する。図１７の例では、Ｕｓｅｒ−Ｃのユーザ識別子を有するユーザが事務所に居る場合に、更新された状態情報が保留されて通知先に通知されることになる。
【００８５】
このように、全ての状態情報を通知先に通知するのではなく、通知条件を満たす状態情報のみを通知先に通知するようにする。これによって、通知条件を満たした必要な状態情報のみを通知先に通知することができ、状態情報の通知を抑制することができる。他の例として、更新される情報を株価とすると、株価が特定の値になったときに、株価を通知先に通知するということができる。なお、上記では、更新者の位置もユーザの状態情報とみなして説明している。
【００８６】
また、状態情報の保留中に、状態情報が通知条件を満たさなくなったとき、状態情報を通知先に通知しないようにする。例えば、通知保留中に通知条件管理テーブル１４が更新され、更新された状態情報が通知条件を満たさなくなったとき、保留制御管理テーブル１７から、通知条件を満たさなくなった情報に対応するデータを削除することで、通知を行わないようにする。
【００８７】
具体的には、図５の通知条件管理テーブル１４において、「Ｕｓｅｒ−Ｃ」の状態情報が更新され、「Ｕｓｅｒ−Ａ」への通知が保留中になったとする。このとき、通知条件管理テーブル１４の１行目（更新者ユーザＩＤが「Ｕｓｅｒ−Ｃ」、通知先ユーザＩＤが「Ｕｓｅｒ−Ａ」の行）が削除されたとすると、「Ｕｓｅｒ−Ｃ」から「Ｕｓｅｒ−Ａ」に対する状態情報の通知条件がなくなったことになる。この場合、この状態情報に対応するデータを保留制御管理テーブル１７から削除し、通知が行われないようにする。
【００８８】
このように、保留中において、通知条件を満たさなくなった状態情報を通知先に通知しないようにすることにより、無駄な状態情報の通知を抑制することができる。
なお、図１７に示した通知条件管理テーブル１４ａの場合、「Ｕｓｅｒ−Ｃ」の位置情報が「事務所」以外に変化したとき、状態情報（ユーザの位置も含むとする）は通知条件を満たさなくなる。この場合も上記と同様に、通知条件を満たさなくなった状態情報に対応するデータを保留制御管理テーブル１７から削除することにより、通知を行わないようにする。
【００８９】
また、通知先の状態に対する通知保留時間を、状態情報の更新元ごとに設定することも可能である。
図１８は、通知保留時間テーブルのデータ構成例の他の例を示した図である。
【００９０】
図に示すように通知保留時間管理テーブル１６ａは、図７に示した通知保留時間管理テーブル１６に対し、更新者ユーザＩＤの欄が設けられている。更新者ユーザＩＤの欄には、情報を更新する更新元のユーザ識別子が格納される。
【００９１】
通知保留時間は、更新元のユーザによって異なっている。図１８の例では、Ｕｓｅｒ−Ａの在席中の通知保留時間は、更新元のユーザがＵｓｅｒ−Ｃである場合には１０秒、更新元のユーザがＵｓｅｒ−Ｄである場合には０秒である。
【００９２】
このように、状態情報の更新元ごとに通知保留時間と通知先の状態とを登録することにより、更新元ごとに異なる状態情報の価値において、通知保留時間を決めることが可能となる。
【００９３】
また、通知保留制御部１２において、最後に通知先のユーザの状態が更新された時点からの経過時間に応じて通知保留時間を変更するようにしてもよい。例えば、通知先ユーザの状態が「離席中」であるとき、「離席中」の状態が長く続いていれば、このまま状態情報の通知を保留して行っても参照されない可能性が高いと予想される。このとき、「離席中」の状態の経過時間に応じて、通知保留時間を延長する(例えば、単純に通知保留時間に経過時間を加算する)ことで、無駄な状態情報の通知を抑制することができる。
【００９４】
次に、本発明の第２の実施の形態を図面を参照して詳細に説明する。
図１９は、第２の実施の形態に係る情報通知のシステム構成例を示した図である。
図に示す第２の実施の形態に係る株価通知サービス会社５１は、証券会社５２から株価更新の通知を受けると、株価をユーザ５３に通知する。このとき、株価通知サービス会社５１は、第１の実施の形態と同様に、ユーザ５３の状態に応じて株価の通知を保留するが、ユーザ５３によって、通知保留時間を変更することができるようになっている。
【００９５】
株価情報は、多くのユーザにとって早く入手したい情報である。ユーザが株によって利益を得るのに、より最新の株価情報を必要とするからである。しかし、ユーザの多くが通知保留時間を短くすると、株価通知サービス会社５１のサービスを提供する装置自体の負荷が増加し、また、ネットワークのトラフィックが増加する。そこで、通知保留時間の変更を許可されたユーザのみが、通知保留時間を変更できるようにする。例えば、株価の更新を短い保留時間で通知して欲しいユーザは、株価通知サービス会社５１に対価を支払うことによって通知を受けることができるようにする。これにより、ユーザは、対価を払って、短い保留時間で株価の通知を受けるというメリットを享受することができる。また、株価通知サービス会社５１は、ユーザから対価を受けることによって、設備の増強ができ、情報通知サーバの負荷、トラフィックの低減を図ることが可能となる。また、証券会社５２においては、ユーザから株取引の手数料を受けることによって、メリットを享受できる。
【００９６】
次に、株価通知サービス会社５１に設置される第２の実施の形態に係る情報通知サーバの機能について説明する。
図２０は、情報通知サーバの機能ブロック図である。
【００９７】
図に示す情報通知サーバ６０は、図１９で示した株価通知サービス会社５１において設置されるサーバである。情報通知サーバ６０は、図４に示した情報通知サーバ１０に対し、通知保留時間登録受付け部６１および通知保留時間登録許可管理テーブル６２をさらに有しているところが異なる。なお、図２０において、図４と同じものには同じ符号を付し、その説明を省略する。
【００９８】
通知保留時間登録受付け部６１は、情報の通知を受けるユーザ５３が使用する通知先端末から通知保留時間登録要求を受付け、通知先端末から送られてくる通知保留時間を通知保留時間管理テーブル１６に登録する。このとき、通知保留時間登録受付け部６１は、通知保留時間登録許可管理テーブル６２に登録されているユーザからの登録要求のみを受付け、登録されていないユーザからの登録要求は無効とする。
【００９９】
通知保留時間登録許可管理テーブル６２には、通知保留時間の登録を許可する通知先端末を識別するために必要なデータが格納される。
図２１は、通知保留時間登録許可管理テーブルのデータ構成例を示した図である。
【０１００】
図に示すように通知保留時間登録許可管理テーブル６２は、通知保留時間登録許可ユーザＩＤの欄を有している。通知保留時間登録許可ユーザＩＤの欄には、通知保留時間を変更することができるユーザのユーザ識別子が格納される。
【０１０１】
図２１の例では、通知保留時間登録許可ユーザＩＤの欄にＵｓｅｒ−Ａ，Ｕｓｅｒ−Ｂが格納されている。よって、通知保留時間登録受付け部６１は、ユーザ識別子Ｕｓｅｒ−Ａ，Ｕｓｅｒ−Ｂを持ったユーザが、通知先端末より通知保留時間の登録要求を行った場合のみ、その登録要求と変更される通知保留時間を受付け、通知保留時間管理テーブル１６に登録する。
【０１０２】
なお、情報通知サーバ６０の所有者と契約して登録料を支払ったユーザに対し、通知保留時間を変更することができる許可を与え、通知保留時間登録許可管理テーブル６２に登録されるようにしてもよい。ユーザが、より短い通知保留時間により、情報が通知されることによって利益が得られると期待できる場合、情報通知サーバ６０の所有者と契約して登録料を支払えば、より短い通知保留時間により情報の通知を受けることができる。これにより、ユーザは、登録料を支払って、短い通知保留時間で情報を通知してもらうことで利益を得ることができる。一方、情報通知サーバ６０側は、ユーザからの登録料により利益を得ることができ、設備の増強ができる。
【０１０３】
次に、通知先端末の機能について説明する。
図２２は、通知先端末の機能ブロック図である。
図に示す通知先端末７１は、図１９で示したユーザ５３が使用する端末である。通知先端末７１は、図１０に示した通知先端末３１に対し、通知保留時間登録要求部７２を有しているところが異なる。なお、図２２において、図１０と同じものには同じ符号を付し、その説明を省略する。
【０１０４】
通知保留時間登録要求部７２は、ユーザから通知保留時間を受付け、情報通知サーバ６０に通知保留時間の登録要求を行う。
なお、証券会社５２で使用される情報更新端末は、図９に示した情報更新端末２１と同様の機能ブロックを有し、その説明を省略する。
【０１０５】
このように、通知保留時間を通知先によって変更、登録できるようにすることによって、通知先のユーザは、重要な情報に対しては早く情報を入手でき、重要でない情報に対しては遅く情報を入手するようにすることができる。
【０１０６】
また、例えば、対価を払ったユーザのみというように、許可されたユーザのみ通知保留時間の変更、登録を行えるようにすることによって、情報通知サーバ６０の負荷の低減、トラフィックの低減を図ることが可能となる。
【０１０７】
さらに、情報通知サーバ６０は、通知保留時間に下限値を設け、多くの対価を支払うユーザに対しては、通知保留時間をより短い下限値を設定できるようにしてもよい。
次に、本発明の第３の実施の形態を図面を参照して詳細に説明する。
【０１０８】
図２３は、第３の実施の形態に係る情報通知のシステム構成例を示した図である。
図に示す第３の実施の形態に係る販売価格通知サービス会社８１は、商品販売者８２から商品の販売価格の更新要求を受けると、商品の販売価格をユーザ８３に通知する。このとき、販売価格通知サービス会社８１は、第１の実施の形態と同様に、ユーザ８３の状態に応じて商品の販売価格の通知を保留するが、商品販売者８２によって、保留時間なしに商品の販売価格を通知することができるようになっている。
【０１０９】
商品販売者８２は、例えば、目玉商品の販売価格を値下げした場合、通知保留時間なしに、すばやくユーザ８３に通知したい。これは、多くのユーザから商品の受注を受ける可能性が高まるからである。しかし、商品販売者が通知保留時間をなしにすると、販売価格通知サービス会社８１のサービスを提供する装置自体の負荷が増加し、また、ネットワークのトラフィックが増加する。そこで、予め許可された商品販売者のみが、通知保留時間をなしにすることができるようになっている。例えば、商品の販売価格の更新を保留時間なしで通知して欲しい商品販売者は、販売価格通知サービス会社８１に対価を支払うことによって、商品の販売価格を保留することなく通知できるようにする。これにより、商品販売者は、対価を払って、保留時間なしで商品の販売価格の通知をユーザ８３に行え、ユーザから商品の発注を受けることによりメリットを享受することができる。また、販売価格通知サービス会社８１は、商品販売者から対価を受けることによって、設備の増強ができ、情報通知サーバの負荷、トラフィックの低減を図ることが可能となる。また、ユーザ８３においては、より安い価格で商品を購入することが可能となる。
【０１１０】
次に、販売価格通知サービス会社８１に設置される第３の実施の形態に係る情報通知サーバの機能について説明する。
図２４は、情報通知サーバの機能ブロック図である。
【０１１１】
図に示す情報通知サーバ９０は、図２３で示した販売価格通知サービス会社８１において設置されるサーバである。情報通知サーバ９０は、図４に示した情報通知サーバ１０に対し、通知保留制御部１２がさらに緊急通知制御処理部９１を有しているところが異なる。また、緊急通知許可管理テーブル９２を有しているところが異なる。なお、図２４において、図４と同じものには同じ符号を付し、その説明を省略する。
【０１１２】
緊急通知制御処理部９１は、情報を更新する商品販売者８２が使用する情報更新端末からの情報更新要求を受信する。このとき、更新される情報に要緊急通知情報が付加されている場合、通知保留制御部１２は、通知保留処理を行わずに即座に通知処理を行う。このとき、緊急通知制御処理部９１は、通知保留処理を行わずに通知処理を行う対象を、緊急通知許可管理テーブル９２に登録されている情報更新元からの情報のみとする。緊急通知許可管理テーブル９２に登録されていない情報更新元が付加する要緊急通知情報は無効として通知保留処理を行う。
【０１１３】
緊急通知許可管理テーブル９２には、緊急通知の利用を許可する情報更新端末を識別するために必要なデータが格納される。
図２５は、緊急通知許可管理テーブルのデータ構成例を示した図である。
【０１１４】
図に示すように緊急通知許可管理テーブル９２は、緊急通知許可更新元ＩＤの欄を有している。緊急通知許可更新元ＩＤの欄には、通知保留時間をなしにすることができる更新元の端末識別子が格納される。
【０１１５】
図２５の例では、緊急通知許可更新元ＩＤの欄に情報更新端末Ａ，Ｂが格納されている。よって、緊急通知制御処理部９１は、情報更新端末Ａ，Ｂの端末識別子を持った端末が、要緊急通知情報を付加して登録要求を行った場合のみ、その登録要求と通知保留時間のなしを受付け、緊急通知許可管理テーブル９２に登録する。
【０１１６】
なお、情報通知サーバ９０の所有者と契約して登録料を支払った情報更新端末を使用する商品販売者に対し、保留なしに情報を通知できる許可を与え、緊急通知許可管理テーブル９２に登録されるようにしてもよい。情報更新端末を使用する商品販売者が、情報を保留なしで通知先のユーザに提供することによって利益が得られると期待できる場合、情報通知サーバ９０の所有者と契約して登録料を支払えば、通知を保留することなく情報を通知先のユーザに提供することができる。これにより、情報更新端末を使用する商品販売者は、登録料を支払って、情報を保留なしで通知先のユーザに提供することにより、例えば、通知先のユーザからの商品の受注が増え、利益を得ることができる。一方、情報通知サーバ９０側は、情報更新端末を使用する商品販売者からの登録料により利益を得ることができ、設備の増強ができる。
【０１１７】
また、情報通知サーバ９０側は、第２の実施の形態で述べた通知先のユーザが登録する登録料を割り引くことによって、通知先のユーザ数の増大を期待することができる。そして、ユーザ数が増大することにより、情報更新端末を使用する商品販売者が情報通知サーバ９０を介してユーザに情報を通知するメリットも増大するので、情報通知サーバ９０側は、情報更新端末を使用する商品販売者の新たな獲得による登録料の収入増加がさらに期待できる。
【０１１８】
次に、情報更新端末の機能について説明する。
図２６は、情報更新端末の機能ブロック図である。
図に示す情報更新端末１０１は、図２３で示した商品販売者８２が使用する端末である。情報更新端末１０１は、図９に示した情報更新端末２１に対し、状態情報更新要求部２１ｂが要緊急通知情報付加処理部１０２を有しているところが異なる。なお、図２６において、図９と同じものには同じ符号を付し、その説明を省略する。
【０１１９】
要緊急通知情報付加処理部１０２は、商品販売者から緊急通知情報の付加要求を受付ける。この場合、状態情報更新要求部２１ｂは、更新された情報を情報通知サーバ９０に送信するとき、要緊急通知情報を、更新された情報に付加して送信する。
【０１２０】
なお、ユーザ８３が使用する通知先端末は、図１０に示した通知先端末３１と同様の機能ブロックを有し、その説明を省略する。
このように、更新された情報の通知の保留を、更新元によって無効にできるようにすることによって、更新元のユーザは、通知先のユーザに早く知らせたい重要な情報に対しては早く情報を通知先のユーザに提供でき、重要でない情報に対しては保留して提供することができる。
【０１２１】
また、例えば、対価を払った更新元のみというように、許可された更新元のみ通知の保留を無効にできるようにすることによって、情報通知サーバ９０の負荷の低減、トラフィックの低減を図ることが可能となる。
【０１２２】
なお、コンピュータが有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。
【０１２３】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。
【０１２４】
（付記１）  更新情報を通知先に通知する情報通知装置において、
前記更新情報の前記通知先への通知を保留する通知保留時間と前記通知先の状態とが対応付けて登録された通知保留時間登録手段と、
前記更新情報を受信する更新情報受信手段と、
前記通知先の状態を受信する通知先状態受信手段と、
受信された前記通知先の状態に対応する前記通知保留時間を前記通知保留時間登録手段から取得する通知保留時間取得手段と、
前記通知保留時間保留して、受信された前記更新情報を前記通知先に通知する情報通知手段と、
を有することを特徴とする情報通知装置。
【０１２５】
（付記２）  前記通知先の識別子が登録された識別子登録手段をさらに有し、
前記情報通知手段は、前記識別子が登録されている前記通知先に対して前記更新情報を通知することを特徴とする付記１記載の情報通知装置。
【０１２６】
（付記３）  前記更新情報を前記通知先に通知するための通知条件が登録された通知条件登録手段をさらに有し、
前記情報通知手段は、前記更新情報が前記通知条件を満たしている場合に前記更新情報を通知することを特徴とする付記１記載の情報通知装置。
【０１２７】
（付記４）  前記更新情報の前記通知先への保留中に、前記更新情報が前記通知条件を満たさなくなったとき、前記情報通知手段は、前記更新情報を通知しないことを特徴とする付記３記載の情報通知装置。
【０１２８】
（付記５）  前記通知保留時間取得手段は、前記更新情報の通知保留中に前記通知先の状態が更新されたとき、更新された状態に対応する前記通知保留時間を前記通知保留時間登録手段から取得することを特徴とする付記１記載の情報通知装置。
【０１２９】
（付記６）  前記通知保留時間登録手段は、前記更新情報の更新元ごとに前記通知保留時間と前記通知先の状態とが登録されることを特徴とする付記１記載の情報通知装置。
（付記７）  前記通知先の同じ状態が続いている時間に応じて、前記通知保留時間を変更する通知保留時間変更手段をさらに有することを特徴とする付記１記載の情報通知装置。
【０１３０】
（付記８）  前記通知保留時間は、前記通知先によって登録されることを特徴とする付記１記載の情報通知装置。
（付記９）  前記通知先は、登録することが予め許可されていることを特徴とする付記８記載の情報通知装置。
【０１３１】
（付記１０）  前記通知保留時間には、下限値が決められていることを特徴とする付記８記載の情報通知装置。
（付記１１）  前記更新情報に緊急に通知する必要があることを示す緊急通知情報が付加されている場合、前記情報通知手段は、前記更新情報を保留せずに通知することを特徴とする付記１記載の情報通知装置。
【０１３２】
（付記１２）  前記緊急通知情報は、前記更新情報を更新する情報更新端末において付加されることを特徴とする付記１１記載の情報通知装置。
（付記１３）  許可された情報更新端末によって、前記更新情報に前記緊急通知情報が付加されたか否かを判断する緊急通知情報判断手段を有することを特徴とする付記１１記載の情報通知装置。
【０１３３】
（付記１４）  更新情報を通知先に通知する情報通知プログラムにおいて、
コンピュータに、
前記更新情報の前記通知先への通知を保留する通知保留時間と前記通知先の状態とが対応付けて登録された通知保留時間登録手段、
前記更新情報を受信する更新情報受信手段、
前記通知先の状態を受信する通知先状態受信手段、
受信された前記通知先の状態に対応する前記通知保留時間を前記通知保留時間登録手段から取得する通知保留時間取得手段、
前記通知保留時間保留して、受信された前記更新情報を前記通知先に通知する情報通知手段、
として機能させることを特徴とする情報通知プログラム。
【図面の簡単な説明】
【０１３４】
【図１】本発明の原理を説明する原理図である。
【図２】第１の実施の形態に係る情報通知サーバのシステム構成例を示した図である。
【図３】情報通知サーバのハードウェア構成を示したブロック図である。
【図４】情報通知サーバの機能ブロック図である。
【図５】通知条件管理テーブルのデータ構成例を示した図である。
【図６】状態情報管理テーブルのデータ構成例を示した図である。
【図７】通知保留時間管理テーブルのデータ構成例を示した図である。
【図８】保留制御管理テーブルのデータ構成例を示した図である。
【図９】情報更新端末の機能ブロック図である。
【図１０】通知先端末の機能ブロック図である。
【図１１】通知先端末のモニタに表示される画面例である。
【図１２】情報更新端末の処理の流れを示したフローチャートである。
【図１３】通知先端末の処理の流れを示したフローチャートである。
【図１４】情報通知サーバの処理の流れを示したフローチャートである。
【図１５】従来の情報通知サーバ、情報更新端末、および通知先端末の間で行われる処理シーケンスを示した図である。
【図１６】本発明の情報通知サーバ、情報更新端末、および通知先端末の間で行われる処理シーケンスを示した図である。
【図１７】通知条件管理テーブルのデータ構成例の他の例を示した図である。
【図１８】通知保留時間テーブルのデータ構成例の他の例を示した図である。
【図１９】第２の実施の形態に係る情報通知のシステム構成例を示した図である。
【図２０】情報通知サーバの機能ブロック図である。
【図２１】通知保留時間登録許可管理テーブルのデータ構成例を示した図である。
【図２２】通知先端末の機能ブロック図である。
【図２３】第３の実施の形態に係る情報通知のシステム構成例を示した図である。
【図２４】情報通知サーバの機能ブロック図である。
【図２５】緊急通知許可管理テーブルのデータ構成例を示した図である。
【図２６】情報更新端末の機能ブロック図である。
【符号の説明】
【０１３５】
１  情報通知装置
１ａ  通知保留時間登録手段
１ｂ  更新情報受信手段
１ｃ  通知先状態受信手段
１ｄ  通知保留時間取得手段
１ｅ  情報通知手段
２，２１  情報更新端末
３，３１，３２  通知先端末
１０，６０，９０  情報通知サーバ
１１  状態情報更新受付け部
１２  通知保留制御部
１３  状態情報通知部
１４  通知条件管理テーブル
１５  状態情報管理テーブル
１６  通知保留時間管理テーブル
１７  保留制御管理テーブル
６１  通知保留時間登録受付け部
６２  通知保留時間登録許可管理テーブル
９１  緊急通知制御処理部
９２  緊急通知許可管理テーブル
【図１】
2005222225.tif 000003
【図２】
2005222225.tif 000004
【図３】
2005222225.tif 000005
【図４】
2005222225.tif 000006
【図５】
2005222225.tif 000007
【図６】
2005222225.tif 000008
【図７】
2005222225.tif 000009
【図８】
2005222225.tif 000010
【図９】
2005222225.tif 000011
【図１０】
2005222225.tif 000012
【図１１】
2005222225.tif 000013
【図１２】
2005222225.tif 000014
【図１３】
2005222225.tif 000015
【図１４】
2005222225.tif 000016
【図１５】
2005222225.tif 000017
【図１６】
2005222225.tif 000018
【図１７】
2005222225.tif 000019
【図１８】
2005222225.tif 000020
【図１９】
2005222225.tif 000021
【図２０】
2005222225.tif 000022
【図２１】
2005222225.tif 000023
【図２２】
2005222225.tif 000024
【図２３】
2005222225.tif 000025
【図２４】
2005222225.tif 000026
【図２５】
2005222225.tif 000027
【図２６】
2005222225.tif 000028