JP3889076B2 - 電子秘書システムおよびスケジュール管理方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、スケジュールを管理し、障害が発生した場合にそれをスケジュールに従って行動している人に通知する電子秘書システムおよびその方法に関する。
【０００２】
【従来の技術とその問題点】
現代社会において生活する人間は、大抵の場合、各自のスケジュールに従って行動する。このスケジュールには、少なくとも、何かアクションを起こす場合に出発点から終点までどのように移動すればよいかという情報が含まれている。
【０００３】
例えば、会社員の場合は、このような移動経路に関する情報は秘書により管理されている場合が多い。したがって、スケジュールに含まれる鉄道路線に事故等の障害が生じている場合、現状では秘書からの連絡がない限り、それを事前に知ることは困難である。また、秘書も常に交通機関の事故発生を監視しているわけではなく、実際にはスケジュールの遂行後に事故発生を知ることが多い。
【０００４】
このように、スケジュール中に障害が発生している場合でも、それを知るための手段が乏しいため、実際に障害に出会った後に移動経路の変更等の対策を講じるている。このため、人の行動が障害発生の後手に回ってしまっているという問題がある。
【０００５】
もし、スケジュール中の障害等の情報を先に得ることができれば、上述のように対策が後手に回るようなことが起こりにくくなる。したがって、障害が発生していても、その状況の下で、先手を打って最善の行動をとることが可能となる。
【０００６】
本発明は、個人または団体のスケジュールを妨げる障害情報を、予定時刻以前に通知することができる電子秘書システムおよびその方法を提供することを目的とする。
【０００７】
【課題を解決するための手段】
図１は、本発明の電子秘書システムの原理図である。図１の電子秘書システムは、管理手段１、検出手段２、および通知手段３を備える。
【０００８】
管理手段１は、ユーザのスケジュール情報を管理する。
検出手段２は、上記ユーザの利用する資源に関するイベント情報の入力を検出する。
【０００９】
通知手段３は、上記スケジュール情報と検出手段２により検出された上記イベント情報とに基づいて、そのスケジュール情報に含まれる資源に関するイベント情報を上記ユーザに通知する。
【００１０】
管理手段１は、例えばユーザが移動する際に利用する交通機関を資源とみなし、その利用予定をスケジュール情報として管理する。例えば、このスケジュール情報には、利用する交通機関の路線名や利用日時等のデータが含まれる。
【００１１】
検出手段２は、外部から入力される交通情報などのイベント情報を検出して、それを通知手段３に伝える。イベント情報としては、大きく分けて、交通事故などの障害が発生したことを示す情報とそれが回復したことを示す情報の２種類がある。
【００１２】
通知手段３は、スケジュール情報に含まれる資源名とイベント情報に含まれる資源名を比較し、それらが一致した場合にイベント情報をユーザに通知する。これにより、検出されたイベントがユーザのスケジュールに影響を及ぼすかどうかが自動的に判定され、影響のあるイベントの情報だけがユーザに通知される。
【００１３】
このように、利用予定のある資源に発生した障害等のイベント情報が、検出後直ちにユーザに通知されるので、ユーザは障害に遭遇する前にスケジュールを変更することが可能になる。
【００１４】
また、本発明の別の電子秘書システムは、管理手段１、検出手段２、通知手段３、スケジュールデータベース、および緊急度と連絡方法の対応表とともに連絡方法毎のアドレスを格納するデータベースを備え、ユーザのスケジュールを管理する。スケジュールデータベースは、ユーザが利用する交通機関とその交通機関の利用開始日時の情報を含むスケジュール情報を交通機関の路線毎に格納し、管理手段１は、スケジュールデータベースのスケジュール情報を管理する。検出手段２は、交通機関の路線に関する障害情報の入力を検出する。通知手段３は、管理手段１からスケジュール情報を受け取り、検出手段２から障害情報を受け取り、その障害情報の路線と一致する路線のスケジュール情報に含まれる利用開始日時と現在時刻の差を求め、利用開始日時と現在時刻の差をパラメータとする関数を用いて障害情報の緊急度を計算し、得られた緊急度に応じた連絡方法を前記対応表から選択し、選択した連絡方法に対応するアドレスに対してその障害情報を通知する。
例えば、図１の管理手段１は、実施形態の図９における秘書装置６２およびスケジュール管理機構６３に対応し、検出手段２はイベント抽出機構６４に対応し、通知手段３はイベントプレイス機構６５および連絡機構６６に対応する。
【００１５】
【発明の実施の形態】
以下、図面を参照しながら、本発明の実施の形態を詳細に説明する。
以下の実施形態においては、イベントの発生場所の解釈を簡単にするために、スケジュール管理の対象となる資源の場所からイベントの発生場所がＯ（１）の探索時間で分かるような機構を用意しておく。ここで、Ｏ（ａ）は、値ａのオーダーの数量を表す。言い換えれば、スケジュールで利用される交通機関等の各資源毎に、その状態を監視するプロセス等の監視機構を用意する。
【００１６】
図２は、スケジュールを一括して管理するスケジュール管理システムの構成図である。図２のスケジュール管理システムは、管理機構１１、スケジュールデータベース（スケジュールＤＢ）１２、判定ルールＤＢ１３を備える。
【００１７】
スケジュールＤＢ１２には、スケジュールの各要素毎の使用交通機関や路線名、使用開始時刻、終了時刻等を含む複数のスケジュールデータが、一括して格納されている。また、判定ルールＤＢ１３には、発生した障害等のイベントがスケジュールに及ぼす影響の大きさを判定するための複数の判定ルールが、各スケジュールデータ毎に一括して格納されている。
【００１８】
管理機構１１は、例えば計算機を含む情報処理装置であり、各スケジュールデータを管理するプロセスを生成して、障害発生時に必要な処理を行う。各プロセスは、例えばある路線上で事故が発生したとういう情報を、外出先のユーザがその路線を利用する前に携帯電話等に通知する。
【００１９】
しかし、このような一括管理システムでは、イベントが発生する毎にスケジュールデータとその判定ルールをそれぞれ探索しなければならない。このため、スケジュールデータがｎ件、それぞれのスケジュールに対するルールがｍ件ある場合には、最悪Ｏ（ｎｍ）の探索時間を必要とすることになる。そこで、探索の手間を削減するために、スケジュールデータを分散させることを考える。
【００２０】
図３は、スケジュールをプロセス毎に分散させて管理する第１の分散管理システムの構成図である。図３の分散管理システムは、管理機構２１と判定ルールＤＢ２２を備える。管理機構２１は、例えば計算機を含む情報処理装置であり、各プロセスは図２のプロセスと同様の通知処理を行う。
【００２１】
この管理システムにおいては、管理機構２１上の各プロセスにスケジュールデータを分散させ、イベント発生時には、対応するスケジュールデータを持つプロセスが判定ルールＤＢ２２から判定ルールを取得する。
【００２２】
しかし、このような分散管理システムにおいても、やはり各スケジュールデータに対するｍ件の判定ルールを探索する必要があるため、探索時間はｍに依存してＯ（ｍ）となる。
【００２３】
図４は、さらに判定ルールも分散させて管理する第２の分散管理システムの構成図である。図４の分散管理システムにおいて、管理機構３１は、例えば計算機を含む情報処理装置であり、各プロセスは図２のプロセスと同様の通知処理を行う。
【００２４】
管理機構３１上の各プロセスは、スケジュールデータおよび判定ルールを組にして持つ。したがって、スケジュールデータに対応するイベントが発生した時にデータベースを探索する必要がなく、その判定ルールを用いて直ちにイベントの重要性を判定することができる。また、スケジュールデータの一部を入力パラメータとする評価関数で判定ルールを表すことにより、さらに処理が簡単化される。
【００２５】
しかし、イベント発生時には、通知等の次の動作を発生させる機構が必要になるため、実施の際に管理機構とは別の機構を加えなければならない。そこで、図４の分散管理システムに、リモートプログラミングに基づく言語であるテレスクリプト（Telescript）による方法を適用することを考える。
【００２６】
テレスクリプトによるリモートプログラミングにおいては、データを保持するプロセスの一種であるエージェント（Agent ）が用いられる。この場合には、スケジュールデータとそれに対する判定ルールを各エージェントに分散させて持たせることが可能であるため、分散管理の形態を取ることができる。
【００２７】
さらに、エージェントは自律的に機能するという特徴があるため、スケジュールに対応するイベントが発生した場合にも、次の処理を自主的に行うことができる。したがって、次の動作を発生させる別の機構を必ずしも必要としない。
【００２８】
このテレスクリプトによるリモートプログラミングについては、「リモートプログラミングの実施方法」（特願平６−１７９７６７、特開平７−１８２１７４）に詳述されているが、ここでその手法について説明する。
【００２９】
このリモートプログラミングは、複数の計算機システムを結ぶ通信ネットワーク上での処理を記述する方法の一種で、ネットワークを渡り歩く移動可能なプロセスであるエージェントと、エージェントが入ってくる固定プロセスであるプレイス（Place ）により実現される。
【００３０】
図５は、プレイスの構成を示している。プレイスは、他のプロセスと識別可能なテレネーム（telename）を持ち、任意有限個の子プロセスを持つことができる。また、プレイスは、自己および他のプロセスより参照可能な任意有限個のデータと、自己および他のプロセスより呼出し可能な任意有限個の手続きとを有する。
【００３１】
さらに、メインルーチンとして手続きliveを持ち、作成されたプレイスはｌｉｖｅを実行する。プレイスは、ｌｉｖｅが実行されている間だけ存在し、ｌｉｖｅが終了すると消滅する。プレイスが消滅すると、その子プロセスも終了し、消滅する。
【００３２】
図６は、エージェントの構成を示している。エージェントは、他のプロセスと識別可能なテレネームを持ち、あるプレイスの中の子プロセスとしてのみ存在する。また、エージェントは、自己および他のプロセスより参照可能な任意有限個のデータと、自己および他のプロセスより呼出し可能な任意有限個の手続きとを有する。
【００３３】
さらに、メインルーチンとして手続きｌｉｖｅを持ち、作成されたエージェントはｌｉｖｅを実行する。エージェントは、ｌｉｖｅが実行されている間だけ存在し、ｌｉｖｅが終了すると消滅する。エージェントの手続きｌｉｖｅの中でコマンドｇｏが実行されると、そのエージェントはネットワークを介して指定された行き先へ移動する。
【００３４】
図７は、コマンドｇｏによるオペレーションの例を示している。図７において、プレイス４１内のエージェント４２は、ｇｏの実行により、行き先のプレイス４４を指定するデータであるチケット（Ticket）４３を得て、指定されたプレイス４４に移動する。
【００３５】
このとき、エージェント４２は、ｇｏによりｌｉｖｅの実行を一時中断し、保持したデータとともに凍結（圧縮）され、パック化される。そして、チケット４３に示されたプレイス４４に送られ、プレイス４４により受け入れをチェックされる。プレイス４４に受け入れられると、その中に子プロセスとして置かれた後、解凍（伸張）され、ｇｏの次のコマンドからｌｉｖｅの実行を再開する。
【００３６】
また、エージェントは、手続きｌｉｖｅの中で自己の置かれているプレイス内にある他のエージェントを求めるコマンドｍｅｅｔを呼出すことができる。コマンドｍｅｅｔの実行時には、エージェントは相手のエージェントを指定するデータであるペティション（Petition）を用いる。
【００３７】
図８は、コマンドｍｅｅｔによるオペレーションの例を示している。図８において、プレイス５１内のエージェント５２は、コマンドｍｅｅｔによりあるペティションを指定する。プレイス５１は、ペティションにより指定された条件に該当するエージェントを探す。そして、プレイス５１内に該当するエージェントがなければ、そのようなエージェントが入ってくるまで待つ。
【００３８】
プレイス５１内のエージェント５３がペティションの条件に該当すれば、プレイス５１は、エージェント５２が相互作用を希望していることをエージェント５３に伝える。そして、エージェント５３がエージェント５２の希望を受け入れる旨の戻り値を返すと、プレイス５１は、エージェント５３へのポインタをｍｅｅｔの戻り値としてエージェント５２に返す。その後、エージェント５２は、エージェント５３へ直接アクセスして、情報交換等を行うことが可能になる。
【００３９】
以下では、このようなリモートプログラミングの手法を用いてスケジュールの分散管理を行う実施形態について説明する。本実施例では、スケジュール中に発生する障害を先手を打って知るために、スケジュールデータと１対１に対応し、そのスケジュールデータに関する障害等を自律的に判断するエージェントが用いられる。自律性を持つプロセスであるエージェントを用いることにより、スケジュール中の個々の要素を独立に自動的に管理することができる。
【００４０】
このエージェントは、緊急の度合いを考慮して連絡手段を自動的に判別し、スケジュールに従って行動するユーザに障害等の内容を伝える。これにより、障害が発生していても、ユーザはそのような事象の下で最善の行動を取ることが可能になる。
【００４１】
また、本実施形態では、事象の重要度を判定する判定ルールをスケジュールデータ毎に関数の形で持たせるため、スケジュールデータに対応した判定ルールを探索する手間が省ける。また、判定ルールを関数化することで、その変更が簡単になり、判定ルールを容易に拡張することが可能になる。
【００４２】
図９は、本実施形態の電子秘書システムの構成図である。図９の電子秘書システムは、秘書装置６２、スケジュール管理機構６３、イベント抽出機構６４、イベントプレイス機構６５、連絡機構６６、スケジュールＤＢ６１、および住所録ＤＢ６７を備え、スケジュールを管理する秘書の役割を果たす。
【００４３】
例えば、秘書装置６２、スケジュール管理機構６３、イベント抽出機構６４、イベントプレイス機構６５、および連絡機構６６は、それぞれ計算機を有する情報処理装置により実現され、通信ネットワークにより互いに接続されている。
【００４４】
図１０は、これらの装置または機構の一例である情報処理装置の構成図である。図１０の情報処理装置は、ＣＰＵ（中央処理装置）８２、メモリ８３、通信部８４、データベース８６、入出力装置８７、およびそれらを結ぶバス８５を有し、通信部８４を介して通信ネットワーク８１に接続されている。
【００４５】
ＣＰＵ８２はメモリ８３を利用してエージェントやプレイス等のプロセスを生成し、データベース８６のデータを参照しながら必要な処理を行う。生成されたエージェントは通信部８４を介して、通信ネットワーク８１上の他の情報処理装置内のプレイスに移動することが可能である。入出力装置８７は、例えばキーボード等の入力機器を備えたディスプレイ端末である。
【００４６】
例えば、秘書装置６２の場合はデータベース８６はスケジュールＤＢ６１に相当し、連絡機構６６の場合はデータベース８６は住所録ＤＢ６７に相当する。その他の機構については、必ずしもデータベース８６を備える必要はない。
【００４７】
図９において、スケジュール管理機構６３はユーザにより操作され、スケジュール情報の入力を受け付けてそれを秘書装置６２に伝える。秘書装置６２は、受け取ったスケジュール情報に基づいてスケジュール変更処理を行い、スケジュールＤＢ６１内の各個人のスケジュールデータを更新する。スケジュールデータは、例えば交通機関の路線のような、ユーザが利用する資源毎に作成される。
【００４８】
スケジュール変更処理においてスケジュールデータが追加された場合は、秘書装置６２は、その利用資源の状態を監視する秘書エージェント７１を作成し、イベントプレイス機構６５に送り込む。イベントプレイス機構６５には、各利用資源に対応するプレイスであるイベントプレイス７３が、利用資源の数に応じてあらかじめ複数用意されている。利用資源が移動手段に対応する場合は、例えば、利用する可能性のある全交通機関のすべての路線について、イベントプレイス７３が作成される。
【００４９】
秘書エージェント７１は行き先のイベントプレイス７３に到着すると、イベントチェック処理を行って、対応するイベントプレイス７３の状態を監視する。
各イベントプレイス７３の状態は、対応する資源に関するイベント情報がイベント抽出機構６４に入力された時に更新される。イベント情報は、例えば特定の交通機関に発生した事故等の情報である。イベント抽出機構６４はイベント抽出処理によりイベント情報の文字データ等を解析し、解析結果に基づくイベント変更処理を行って、対応するイベントプレイス７３の状態を更新する。
【００５０】
イベントプレイス７３の状態は、例えば、対応する資源に障害が発生して利用不可能な状態と、通常の利用可能な状態のうちのいずれかを表す。交通機関の場合は、利用不可能な状態は不通状態である。
【００５１】
イベントプレイス７３の更新により秘書エージェント７１はインタラプトを受け、イベントプレイス７３が例えば不通または通常という２つの状態のいずれに相当するかを判断することができる。
【００５２】
また、秘書エージェント７１は、秘書装置６２からイベントプレイス機構６５に送り込まれた時、すなわちスケジュールＤＢ６１が更新された直後に、監視対象のイベントプレイス７３が既に不通状態にあれば、そのことを連絡機構６６を介してユーザに通知する。イベントプレイス７３の状態の更新があっても、例えばそれが不通区間の路線上でさらに別の事故が起こった場合のように、結果的に状態に変化がない時は、秘書エージェント７１は何もしない。
【００５３】
また、秘書エージェント７１は、状態に実質的な変化があった時に、その事象の入力時刻と資源を利用する予定時刻との差により事象の重要度を判定する判定ルールを持っている。この判定ルールは秘書エージェント７１の作成時に渡されるので、秘書装置６２において判定ルールを動的に変更することも可能である。
【００５４】
イベントプレイス７３の状態変化と判定ルールは、秘書エージェント７１が作成する連絡エージェント７２により連絡機構６６に伝えられる。秘書エージェント７１は、スケジュールデータに記された資源の利用終了時刻を過ぎると、自発的に消滅する。
【００５５】
連絡機構６６は、連絡エージェント７２から状態変化と判定ルールを受け取ると、住所録ＤＢ６７にあらかじめ格納されている連絡手段データに記述されたユーザの連絡先に、対応する資源の状態を連絡する。例えば、このとき使用される連絡手段は、現在時刻から利用開始時刻までの時間的余裕から判定ルールを用いて算出された重要度に基づいて、切り換えられる。
【００５６】
次に、図１１から図１５までを参照しながら、図９の電子秘書システムで用いられるデータの構造について説明する。
図１１は、スケジュールＤＢ６１に格納されるスケジュールデータの構造の例を示している。図１１のスケジュールデータは、ｗｈｏ、ｆｒｏｍ、ｔｏ、ｗｈｅｒｅ、ｂｙ、および判定ルールを要素として有する。ｗｈｏはスケジュールに従って行動する主体を表し、例えば個人や団体等のユーザがこれに該当する。
【００５７】
ｂｙは利用する資源を表し、移動手段の場合は交通機関の路線名等がこれに該当する。ｆｒｏｍとｔｏはそれぞれ利用開始日時と利用終了日時を表し、ｗｈｅｒｅは行動主体が存在する場所を表す。例えば、ｂｙは山手線や中央線等であり、ｗｈｅｒｅは東京や神奈川等であるが、ｗｈｅｒｅは省略することもできる。
【００５８】
また、判定ルールは、このスケジュールデータに記された資源に障害が発生したり、それが障害から回復したりした場合に、その状態変化がスケジュールに及ぼす影響の重要度を判定するために用いられる。また、その重要度に基づいて行う具体的なオペレーションも記述している。
【００５９】
図１２は、イベント抽出機構６４からイベントプレイス機構６５に渡されるイベントデータの構造の例を示している。図１２のイベントデータは、ｂｙ、ｗｈｅｎ、ａｃｃｉｄｅｎｔ、およびｆｌａｇを要素として有する。ｂｙはスケジュールデータの場合と同様である。
【００６０】
ｗｈｅｎは障害や回復等のイベントの発生日時を表すが、代わりに、イベント抽出機構６４にイベント情報が入力した日時をｗｈｅｎとして用いてもよい。ａｃｃｉｄｅｎｔは事故や渋滞等のイベント名を表し、ｆｌａｇはイベントの種別を表す。ここでは、イベントが発生した場合にｆｌａｇの値をＯＮとし、終了した場合にＯＦＦとする。
【００６１】
図１３は、住所録ＤＢ６７に格納される連絡手段データの構造の例を示している。図１３の連絡手段データは、ｗｈｏ、複数の連絡手段のアドレス、および重要度／連絡手段対応表を要素として有する。ｗｈｏはスケジュールデータの場合と同様である。
【００６２】
連絡手段のアドレスとしては、電子メールアドレス、ページャ呼出番号、携帯電話呼出番号などが記述される。ページャは、例えばポケットベルのことを指す。重要度／連絡手段対応表には、判定ルールにより算出された重要度に応じて、用いられる連絡手段が記載されている。
【００６３】
図１４は、各イベントプレイス７３が保持するデータの構造の例を示している。図１４のデータは、ｂｙ、秘書エージェント在中場所、および事象の並びを要素として有する。ｂｙはスケジュールデータの場合と同様である。
【００６４】
秘書エージェント在中場所は、イベントプレイス７３内に送り込まれた秘書エージェント７１の存在場所を特定する情報で、例えば秘書エージェント７１へのポインタ等がこれに該当する。一般に、イベントプレイス７３内には、複数の秘書エージェントが存在することができる。事象の並びには、イベント抽出機構６４から渡されたイベントデータが格納される。
【００６５】
図１５は、秘書エージェント７１が保持するデータの構造の例を示している。図１５のデータは、ｆｒｏｍ、ｔｏ、判定ルール、およびｗｈｏを要素として有する。これらの情報は、秘書エージェント７１の作成時にスケジュールデータからコピーされる。
【００６６】
次に、図１６から図２１までを参照しながら、図９の電子秘書システムにおいて行われる各処理について説明する。
図１６は、秘書装置６２およびイベントプレイス機構６５により行われるスケジュール変更処理のフローチャートである。図１６において処理が開始されると、秘書装置６２は、まずスケジュール管理機構６３からスケジュールデータとコマンドの対または並びを受け取る（ステップＳ１）。コマンドは、スケジュールデータの“追加”または“削除”のいずれかを表す。
【００６７】
次に、受け取ったコマンドが“追加”かどうかを判定し（ステップＳ２）、“追加”であればスケジュールデータをスケジュールＤＢ６１に追加する（ステップＳ３）。そして、スケジュールデータ中のｂｙにより行き先を指定したコマンドｇｏを持つ秘書エージェント７１を作成する（ステップＳ４）。このとき、同時にスケジュールデータ中のｗｈｏ、ｆｒｏｍ、ｔｏ、および判定ルールを秘書エージェント７１に与えておく。
【００６８】
作成された秘書エージェント７１は、ｇｏにより凍結され、イベントプレイス機構６５内の指定されたｂｙを持つイベントプレイス７３に移動する（ステップＳ５）。このとき、該当するイベントプレイス７３があるかどうかが調べられ（ステップＳ６）、それが存在すれば、秘書エージェント７１はそこでイベントプレイス機構６５により解凍される（ステップＳ７）。解凍された秘書エージェント７１は、次にイベントチェック処理を行って（ステップＳ８）、処理を終了する。
【００６９】
ステップＳ６において、該当するイベントプレイス７３が存在しなければ、例外処理を行って（ステップＳ９）、処理を終了する。例外処理においては、例えば、エラーメッセージがスケジュール管理機構６３のディスプレイに表示される。この場合、秘書エージェント７１はイベントプレイス７３には送られない。例外処理は、該当するイベントプレイス７３がイベントプレイス機構６５に用意されていなかった場合に行われる。
【００７０】
また、ステップＳ２においてコマンドが“削除”であれば、秘書装置６２は受け取ったスケジュールデータと一致するものをスケジュールＤＢ６１内で探してそれを削除し、イベントプレイス機構６５にそのスケジュールデータを送る（ステップＳ１０）。
【００７１】
イベントプレイス機構６５は、送られたスケジュールデータのｂｙに一致するｂｙを持つイベントプレイス７３を探し（ステップＳ１１）、その秘書エージェント在中場所を参照する。そして、スケジュールデータのｗｈｏ、ｆｒｏｍ、ｔｏと一致するデータを持つ秘書エージェント７１を探す（ステップＳ１２）。
【００７２】
該当する秘書エージェント７１があるかどうかを調べ（ステップＳ１３）、それが存在すればその秘書エージェント７１を殺して（終了させて）（ステップＳ１４）、処理を終了する。終了した秘書エージェント７１は、自動的に削除される。該当する秘書エージェント７１が存在しなければ、そのまま処理を終了する。これは、秘書エージェント７１が既に自発的に消滅している場合に相当する。
【００７３】
図１７は、イベント抽出機構６４により行われるイベント抽出処理のフローチャートである。図１７において処理が開始されると、イベント抽出機構６４はイベント入力待ちのループ処理を開始し（ステップＳ２１）、イベント情報が入力されたかどうかを判定する（ステップＳ２２）。イベント情報が入力されなければ、ステップＳ２２の判定を繰り返す。
【００７４】
交通情報の文字データなどのイベント情報が外部から入力されると、それを解析して図１２のようなイベントデータを作成し（ステップＳ２３）、イベントプレイス機構６５に送付する（ステップＳ２４）。イベント情報は通信ネットワーク８１から入力する場合もあり、入出力装置８７からオペレータにより入力される場合もある。
【００７５】
作成されたイベントデータのｆｌａｇは、新たなイベントの発生時にはＯＮに設定され、既に発生していたイベントの終了時にはＯＦＦに設定される。例えば、事故の発生時にはｆｌａｇはＯＮに設定され、その回復時にはＯＦＦに設定される。したがって、１つのａｃｃｉｄｅｎｔに対しては、ｆｌａｇ＝ＯＮのイベントデータとｆｌａｇ＝ＯＦＦのイベントデータの２つが作成されることになり、最終的には必ず対になる。
【００７６】
次に、ループ処理を終了するかどうかを判定し（ステップＳ２５）、終了しない場合はステップＳ２２以降の処理を繰り返す。実際には、このループ処理はイベント入力待ちの無限ループとして設定され、通常は終了しない。ただし、システム自体に異常をきたしたような場合には、処理を終了する。
【００７７】
図１８は、イベントデータを受け取ったイベントプレイス機構６５が行うイベント変更処理のフローチャートである。図１８において処理が開始されると、イベントプレイス機構６５は、まず受け取ったイベントデータのｂｙに一致するｂｙを持つイベントプレイス７３を探す（ステップＳ３１、Ｓ３２）。該当するイベントプレイス７３があれば、次に、イベントデータのｆｌａｇがＯＮかどうかを調べる（ステップＳ３３）。
【００７８】
そして、ｆｌａｇがＯＮであれば、そのイベントプレイス７３の事象の並びにイベントデータを追加する（ステップＳ３４）。次に、イベントプレイス７３の秘書エージェント在中場所にあるすべての秘書エージェント７１に、そのイベントデータを引数とする割り込みを送り（ステップＳ３５）、処理を終了する。
【００７９】
ステップＳ３３においてｆｌａｇがＯＦＦであれば、そのイベントプレイス７３の事象の並びからイベントデータのａｃｃｉｄｅｎｔと一致するａｃｃｉｄｅｎｔを持つものを探し、それを削除して（ステップＳ３６）、ステップＳ３５の処理を行う。
【００８０】
また、ステップＳ３２において該当するイベントプレイス７３がなければ、例外処理を行って（ステップＳ３７）、処理を終了する。例外処理においては、例えば、エラーメッセージがイベント抽出機構６４のディスプレイに表示される。
【００８１】
図１８のイベント変更処理により、イベントが発生した時にイベントプレイス７３に事象が追加され、終了すると削除されるので、イベントプレイス７３内の事象の並びをチェックすることにより、対応する資源に障害が発生しているかどうかを知ることができる。
【００８２】
図１９は、イベントプレイス７３において解凍された秘書エージェント７１が行うイベントチェック処理のフローチャートである。秘書エージェント７１は、解凍されると同時に起動される。図１９において処理が開始されると、秘書エージェント７１は、まず自己が存在するイベントプレイス７３の事象の並びに事象（イベントデータ）があるかどうかを調べる（ステップＳ４１）。
【００８３】
イベントデータがあれば、そのｂｙと、文字列“事故発生中”と、（ｆｒｏｍ−現在時刻）の値と、判定ルールと、ｗｈｏとをデータとして保持する連絡エージェント７２を作成し、連絡機構６６に送付する（ステップＳ４２）。連絡エージェント７２は、例えばコマンドｓｅｎｄを用いて生成され、送付される。
【００８４】
ｓｅｎｄは、エージェントの手続きｌｉｖｅの中で実行され、そのエージェントの複製を作って他のプレイスに送るコマンドである。ここでは、連絡エージェント７２は、秘書エージェント７１のクローンエージェントとして生成される。
【００８５】
連絡エージェント７２が保持するデータの中で、ｆｒｏｍ、判定ルール、およびｗｈｏは秘書エージェント７１から複写されて用いられる。また、現在時刻としては、イベントプレイス機構６５内のタイマ機構（不図示）から得た日時を用いる。ただし、イベントデータのｗｈｅｎの値と現在時刻とがあまり違わない場合には、現在時刻の代わりにｗｈｅｎを用いてもよい。
【００８６】
連絡エージェント７２を連絡機構６６に送ることにより、ｗｈｏに記されたユーザに“事故発生中”という文字列情報が自動的に伝達される。ステップＳ４１でイベントプレイス７３にイベントデータがなければ、そのままステップＳ４３以降の処理を行う。
【００８７】
次に、秘書エージェント７１はループ処理を開始し（ステップＳ４３）、現在時刻が自己の保持するｔｏを過ぎているかどうかをチェックする（ステップＳ４４）。それがｔｏを過ぎていなければ、次にイベントプレイス機構６５からの割り込みがあるかどうかをチェックする（ステップＳ４５）。
【００８８】
割り込みがあれば、イベントプレイス機構６５から渡されたイベントデータを用いて割り込み処理を行い、イベントの内容を連絡機構６６に通知して（ステップＳ４６）、ステップＳ４４以降の処理を繰り返す。割り込みがなければそのままステップＳ４４以降の処理を繰り返す。
【００８９】
ステップＳ４４、Ｓ４５、Ｓ４６のループ処理は、一定時間毎に繰り返される。そして、ステップＳ４４において現在時刻がｔｏを過ぎれば、もはや該当する資源の状態を監視する必要はなくなるので、自律的に処理を終了して（ステップＳ４７）、消滅する。このように、秘書エージェント７１は不要になれば自主的に消滅するので、システム内の計算機資源が効率的に運用される。
【００９０】
図２０は、図１９のステップＳ４６において行われる割り込み処理のフローチャートである。図２１において処理が開始されると、秘書エージェント７１は、まず自己が存在するイベントプレイス７３の事象の並びに事象（イベントデータ）があるかどうかを調べる（ステップＳ５１）。
【００９１】
イベントデータがあれば、ステップＳ４２と同様にして、ｂｙと、文字列“事故発生中”と、（ｆｒｏｍ−現在時刻）の値と、判定ルールと、ｗｈｏとをデータとして保持する連絡エージェント７２を作成して、連絡機構６６に送付し（ステップＳ５３）、処理を終了する。
【００９２】
また、イベントデータがなければ、引数として渡されたイベントデータのｂｙと、文字列“回復”と、（ｆｒｏｍ−現在時刻）の値と、判定ルールと、ｗｈｏとをデータとして保持する連絡エージェント７２を作成して、連絡機構６６に送付し（ステップＳ５２）、処理を終了する。
【００９３】
こうして、イベントプレイス７３内の事象の並びが空かどうかに応じて、文字列“回復”または“事故発生中”が連絡機構６６に伝えられる。尚、イベントプレイス７３の事象の並びにイベントデータが複数ある場合は、文字列を“多重事故発生中”としてもよい。また、イベントデータの個数が多くなるほど重要度が大きくなるようなオペレーションを、判定ルールとして用意しておいてもよい。
【００９４】
図２１は、連絡エージェント７２を受け入れた連絡機構６６が行う連絡処理のフローチャートである。図２１において処理が開始されると、連絡機構６６は、まず連絡エージェント７２からｂｙ、文字列、（ｆｒｏｍ−現在時刻）の値、判定ルール、およびｗｈｏを受け取る（ステップＳ６１）。連絡エージェント７２は、連絡機構６６にこれらのデータを渡すと自律的に消滅する。
【００９５】
次に、連絡機構６６は（ｆｒｏｍ−現在時刻）をパラメータＴとする判定ルールを用いて、そのイベントの重要度を計算する（ステップＳ６２）。重要度は、Ｔが小さいほど、すなわち現在時刻から開始時刻までの時間的余裕が少ないほど大きくなるように定義する。
【００９６】
ここでは、例えば、Ｔの逆数またはＴ² の逆数を重要度を表す関数として用いる。そのほかに、Ｔが一日以内なら重要度を大、Ｔが一週間以内なら重要度を中、Ｔが一週間を超えるなら重要度を小とするような関数を用いてもよい。
【００９７】
次に、住所録ＤＢ６７からｗｈｏに対応する図１３のような連絡手段データを取得し（ステップＳ６３）、その重要度／連絡手段対応表を参照する（ステップＳ６４）。そして、求めた重要度の値に対応する連絡手段を選択し、そのアドレスを連絡手段データから取得する。次に、そのアドレスを用いて、選択した連絡手段でユーザに連絡して（ステップＳ６５）、処理を終了する。
【００９８】
例えば、ｗｈｏに記されたユーザが携帯電話、ページャ、および電子メールを連絡手段として登録している場合は、重要度に適当な閾値を設けて、重要度が大きければ携帯電話、中くらいならばページャ、小さければ電子メールが選択されるようにしておく。携帯電話には、例えば音声合成で生成された音声により自動的に連絡される。こうしておけば、緊急度の高いイベントの変化ほど迅速な連絡手段でユーザに通知されることになる。
【００９９】
連絡する内容は、連絡エージェント７２から受け取ったｂｙと文字列を用いて、例えば“山手線に事故発生中”または“山手線が回復”のように構成される。連絡を受けたユーザは、その情報に基づいてスケジュールの変更をスケジュール管理機構６３に指示するなどの適当な対策を講じることができる。
【０１００】
以上説明したリモートプログラミングによる電子秘書システムにおいて、秘書装置６２、スケジュール管理機構６３、イベント抽出機構６４、イベントプレイス機構６５、および連絡機構６６のうちのいくつかまたは全部を、同一の情報処理装置上で実現してもよい。また、イベントプレイス機構６５から連絡機構６６へは、連絡エージェント７２によりデータが伝えられているが、その代わりに秘書エージェント７１がデータのみを直接送付するようにしてもよい。
【０１０１】
また、スケジューリングされる資源の例として交通機関を用いて説明したが、本発明はこれに限らず、例えば会議室、備品、設備等の他の資源についても同様に適用できる。この場合、対応する資源の識別情報がスケジュールデータ等のｂｙとして用いられる。そして、その資源が何等かの理由で利用不可能となった時に、イベントデータのｆｌａｇがＯＮに設定され、再び利用可能となった時にそれがＯＦＦに設定される。
【０１０２】
さらに、図９の実施形態において、必ずしもエージェントやプレイスを用いる必要はなく、それぞれの処理を普通のプロセスにより行ってもよい。この場合は、ネットワークを介したやりとりは、例えばＲＰＣ（remote procedure call ）により実行される。
【０１０３】
【発明の効果】
本発明によれば、スケジュールされた利用資源に発生した障害等のイベント情報を、その利用予定日時より前にユーザに通知することが可能になる。これにより、連絡を受けたユーザは障害の発生した資源の利用予定をキャンセルして、代わりに他のスケジュールを優先させるなどの処置を取ることができる。したがって、障害に遭遇する前に先手を打って、最善の行動をとることが可能となる。
【図面の簡単な説明】
【図１】本発明の原理図である。
【図２】一括管理システムの構成図である。
【図３】第１の分散管理システムの構成図である。
【図４】第２の分散管理システムの構成図である。
【図５】プレイスの構成を示す図である。
【図６】エージェントの構成を示す図である。
【図７】オペレーションｇｏを示す図である。
【図８】オペレーションｍｅｅｔを示す図である。
【図９】電子秘書システムの構成図である。
【図１０】情報処理装置の構成図である。
【図１１】スケジュールデータの構造を示す図である。
【図１２】イベントデータの構造を示す図である。
【図１３】連絡手段データの構造を示す図である。
【図１４】イベントプレイスの持つデータの構造を示す図である。
【図１５】秘書エージェントの持つデータの構造を示す図である。
【図１６】スケジュール変更処理のフローチャートである。
【図１７】イベント抽出処理のフローチャートである。
【図１８】イベント変更処理のフローチャートである。
【図１９】イベントチェック処理のフローチャートである。
【図２０】割り込み処理のフローチャートである。
【図２１】連絡処理のフローチャートである。
【符号の説明】
１ 管理手段
２ 検出手段
３ 通知手段
１１，２１，３１ 管理機構
１２，６１ スケジュールデータベース
１３，２２ 判定ルールデータベース
４１，４４，５１ プレイス
４２，５２，５３ エージェント
４３ チケット
６２ 秘書装置
６３ スケジュール管理機構
６４ イベント抽出機構
６５ イベントプレイス機構
６６ 連絡機構
６７ 住所録データベース
７１ 秘書エージェント
７２ 連絡エージェント
７３ イベントプレイス
８１ 通信ネットワーク
８２ ＣＰＵ
８３ メモリ
８４ 通信部
８５ バス
８６ データベース
８７ 入出力装置

Claims (4)

1. ユーザのスケジュールを管理する電子秘書システムであって、
   前記ユーザが利用する交通機関と該交通機関の利用開始日時の情報を含むスケジュール情報を交通機関の路線毎に格納するスケジュールデータベースと、
   前記スケジュールデータベースのスケジュール情報を管理する管理手段と、
   交通機関の路線に関する障害情報の入力を検出する検出手段と、
   緊急度と連絡方法の対応表とともに連絡方法毎のアドレスを格納するデータベースと、
   前記管理手段から前記スケジュール情報を受け取り、前記検出手段から前記障害情報を受け取り、該障害情報の路線と一致する路線のスケジュール情報に含まれる利用開始日時と現在時刻の差を求め、該利用開始日時と現在時刻の差をパラメータとする関数を用いて該障害情報の緊急度を計算し、得られた緊急度に応じた連絡方法を前記対応表から選択し、選択した連絡方法に対応するアドレスに対して該障害情報を通知する通知手段と
   を備えることを特徴とする電子秘書システム。
2. ユーザのスケジュールを管理する電子秘書システムであって、
   入力されたイベント情報から交通機関の路線に関する障害情報を抽出するイベント抽出機構と、
   前記ユーザが利用する交通機関の状態を示すイベントデータを交通機関の路線毎に格納し、前記イベント抽出機構から前記障害情報を受け取ったとき、対応する交通機関の状態を障害発生に変更するイベントプレイス機構と、
   交通機関の利用開始日時の情報を保持し前記イベントデータが示す交通機関の状態を監視するプロセスである秘書エージェントを、交通機関の路線毎に生成する秘書装置と、
   緊急度と連絡方法の対応表とともに連絡方法毎のアドレスを格納するデータベースと、
   前記障害情報を前記ユーザに連絡する連絡機構とを備え、
   前記秘書エージェントは、前記イベントデータが示す交通機関の状態が障害発生を示しているとき、保持している利用開始日時と現在時刻の差を前記連絡機構に通知し、該連絡機構は、該利用開始日時と現在時刻の差をパラメータとする関数を用いて前記障害情報の緊急度を計算し、得られた緊急度に応じた連絡方法を前記対応表から選択し、選択した連絡方法に対応するアドレスに対して該障害情報を連絡することを特徴とする電子秘書システム。
3. 前記秘書エージェントは、交通機関の利用終了日時の情報をさらに保持し、現在時刻が該利用終了日時を過ぎていれば、前記イベントデータが示す交通機関の状態を監視する処理を自律的に終了することを特徴とする請求項２記載の電子秘書システム。
4. ユーザのスケジュールを管理するスケジュール管理方法であって、
   管理手段が、前記ユーザが利用する交通機関と該交通機関の利用開始日時の情報を含むスケジュール情報を交通機関の路線毎に格納するスケジュールデータベースを管理し、
   検出手段が、交通機関の路線に関する障害情報の入力を検出し、
   通知手段が、前記管理手段から前記スケジュール情報を受け取り、前記検出手段から前記障害情報を受け取り、該障害情報の路線と一致する路線のスケジュール情報に含まれる利用開始日時と現在時刻の差を求め、該利用開始日時と現在時刻の差をパラメータとする関数を用いて該障害情報の緊急度を計算し、得られた緊急度に応じた連絡方法を、緊急度と連絡方法の対応表とともに連絡方法毎のアドレスを格納するデータベースから選択し、選択した連絡方法に対応するアドレスに対して該障害情報を通知する
   ことを特徴とするスケジュール管理方法。

Images