JPH09179911A - 電子秘書システムおよび方法 - Google Patents

Abstract

(57)【要約】 【課題】 ユーザのスケジュールを妨げる障害情報を、
予定時刻以前にユーザに通知することが課題である。 【解決手段】 スケジュール管理機構６３に入力された
スケジュール情報は、秘書装置６２によりスケジュール
データベース６１に格納される。このとき、秘書装置６
２は交通機関の特定の路線を監視する秘書エージェント
７１を生成し、イベントプレイス機構６５に送り込む。
イベント抽出機構６４から入力されたイベント情報が監
視対象の路線に関係する場合は、秘書エージェント７１
は、連絡エージェント７２を連絡機構６６に送る。連絡
機構６６は住所録データベースを参照して、指定された
連絡方法でイベント情報をユーザに通知する。これによ
り、ユーザは、利用する交通機関の障害情報を外出先で
も迅速に得ることができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、スケジュールを管
理し、障害が発生した場合にそれをスケジュールに従っ
て行動している人に通知する電子秘書システムおよびそ
の方法に関する。

【０００２】

【従来の技術とその問題点】現代社会において生活する
人間は、大抵の場合、各自のスケジュールに従って行動
する。このスケジュールには、少なくとも、何かアクシ
ョンを起こす場合に出発点から終点までどのように移動
すればよいかという情報が含まれている。

【０００３】例えば、会社員の場合は、このような移動
経路に関する情報は秘書により管理されている場合が多
い。したがって、スケジュールに含まれる鉄道路線に事
故等の障害が生じている場合、現状では秘書からの連絡
がない限り、それを事前に知ることは困難である。ま
た、秘書も常に交通機関の事故発生を監視しているわけ
ではなく、実際にはスケジュールの遂行後に事故発生を
知ることが多い。

【０００４】このように、スケジュール中に障害が発生
している場合でも、それを知るための手段が乏しいた
め、実際に障害に出会った後に移動経路の変更等の対策
を講じるている。このため、人の行動が障害発生の後手
に回ってしまっているという問題がある。

【０００５】もし、スケジュール中の障害等の情報を先
に得ることができれば、上述のように対策が後手に回る
ようなことが起こりにくくなる。したがって、障害が発
生していても、その状況の下で、先手を打って最善の行
動をとることが可能となる。

【０００６】本発明は、個人または団体のスケジュール
を妨げる障害情報を、予定時刻以前に通知することがで
きる電子秘書システムおよびその方法を提供することを
目的とする。

【０００７】

【課題を解決するための手段】図１は、本発明の電子秘
書システムの原理図である。図１の電子秘書システム
は、管理手段１、検出手段２、および通知手段３を備え
る。

【０００８】管理手段１は、ユーザのスケジュール情報
を管理する。検出手段２は、上記ユーザの利用する資源
に関するイベント情報の入力を検出する。

【０００９】通知手段３は、上記スケジュール情報と検
出手段２により検出された上記イベント情報とに基づい
て、そのスケジュール情報に含まれる資源に関するイベ
ント情報を上記ユーザに通知する。

【００１０】管理手段１は、例えばユーザが移動する際
に利用する交通機関を資源とみなし、その利用予定をス
ケジュール情報として管理する。例えば、このスケジュ
ール情報には、利用する交通機関の路線名や利用日時等
のデータが含まれる。

【００１１】検出手段２は、外部から入力される交通情
報などのイベント情報を検出して、それを通知手段３に
伝える。イベント情報としては、大きく分けて、交通事
故などの障害が発生したことを示す情報とそれが回復し
たことを示す情報の２種類がある。

【００１２】通知手段３は、スケジュール情報に含まれ
る資源名とイベント情報に含まれる資源名を比較し、そ
れらが一致した場合にイベント情報をユーザに通知す
る。これにより、検出されたイベントがユーザのスケジ
ュールに影響を及ぼすかどうかが自動的に判定され、影
響のあるイベントの情報だけがユーザに通知される。

【００１３】このように、利用予定のある資源に発生し
た障害等のイベント情報が、検出後直ちにユーザに通知
されるので、ユーザは障害に遭遇する前にスケジュール
を変更することが可能になる。

【００１４】例えば、図１の管理手段１は、実施形態の
図９における秘書装置６２およびスケジュール管理機構
６３に対応し、検出手段２はイベント抽出機構６４に対
応し、通知手段３はイベントプレイス機構６５および連
絡機構６６に対応する。

【００１５】

【発明の実施の形態】以下、図面を参照しながら、本発
明の実施の形態を詳細に説明する。以下の実施形態にお
いては、イベントの発生場所の解釈を簡単にするため
に、スケジュール管理の対象となる資源の場所からイベ
ントの発生場所がＯ（１）の探索時間で分かるような機
構を用意しておく。ここで、Ｏ（ａ）は、値ａのオーダ
ーの数量を表す。言い換えれば、スケジュールで利用さ
れる交通機関等の各資源毎に、その状態を監視するプロ
セス等の監視機構を用意する。

【００１６】図２は、スケジュールを一括して管理する
スケジュール管理システムの構成図である。図２のスケ
ジュール管理システムは、管理機構１１、スケジュール
データベース（スケジュールＤＢ）１２、判定ルールＤ
Ｂ１３を備える。

【００１７】スケジュールＤＢ１２には、スケジュール
の各要素毎の使用交通機関や路線名、使用開始時刻、終
了時刻等を含む複数のスケジュールデータが、一括して
格納されている。また、判定ルールＤＢ１３には、発生
した障害等のイベントがスケジュールに及ぼす影響の大
きさを判定するための複数の判定ルールが、各スケジュ
ールデータ毎に一括して格納されている。

【００１８】管理機構１１は、例えば計算機を含む情報
処理装置であり、各スケジュールデータを管理するプロ
セスを生成して、障害発生時に必要な処理を行う。各プ
ロセスは、例えばある路線上で事故が発生したとういう
情報を、外出先のユーザがその路線を利用する前に携帯
電話等に通知する。

【００１９】しかし、このような一括管理システムで
は、イベントが発生する毎にスケジュールデータとその
判定ルールをそれぞれ探索しなければならない。このた
め、スケジュールデータがｎ件、それぞれのスケジュー
ルに対するルールがｍ件ある場合には、最悪Ｏ（ｎｍ）
の探索時間を必要とすることになる。そこで、探索の手
間を削減するために、スケジュールデータを分散させる
ことを考える。

【００２０】図３は、スケジュールをプロセス毎に分散
させて管理する第１の分散管理システムの構成図であ
る。図３の分散管理システムは、管理機構２１と判定ル
ールＤＢ２２を備える。管理機構２１は、例えば計算機
を含む情報処理装置であり、各プロセスは図２のプロセ
スと同様の通知処理を行う。

【００２１】この管理システムにおいては、管理機構２
１上の各プロセスにスケジュールデータを分散させ、イ
ベント発生時には、対応するスケジュールデータを持つ
プロセスが判定ルールＤＢ２２から判定ルールを取得す
る。

【００２２】しかし、このような分散管理システムにお
いても、やはり各スケジュールデータに対するｍ件の判
定ルールを探索する必要があるため、探索時間はｍに依
存してＯ（ｍ）となる。

【００２３】図４は、さらに判定ルールも分散させて管
理する第２の分散管理システムの構成図である。図４の
分散管理システムにおいて、管理機構３１は、例えば計
算機を含む情報処理装置であり、各プロセスは図２のプ
ロセスと同様の通知処理を行う。

【００２４】管理機構３１上の各プロセスは、スケジュ
ールデータおよび判定ルールを組にして持つ。したがっ
て、スケジュールデータに対応するイベントが発生した
時にデータベースを探索する必要がなく、その判定ルー
ルを用いて直ちにイベントの重要性を判定することがで
きる。また、スケジュールデータの一部を入力パラメー
タとする評価関数で判定ルールを表すことにより、さら
に処理が簡単化される。

【００２５】しかし、イベント発生時には、通知等の次
の動作を発生させる機構が必要になるため、実施の際に
管理機構とは別の機構を加えなければならない。そこ
で、図４の分散管理システムに、リモートプログラミン
グに基づく言語であるテレスクリプト（Telescript）に
よる方法を適用することを考える。

【００２６】テレスクリプトによるリモートプログラミ
ングにおいては、データを保持するプロセスの一種であ
るエージェント（Agent ）が用いられる。この場合に
は、スケジュールデータとそれに対する判定ルールを各
エージェントに分散させて持たせることが可能であるた
め、分散管理の形態を取ることができる。

【００２７】さらに、エージェントは自律的に機能する
という特徴があるため、スケジュールに対応するイベン
トが発生した場合にも、次の処理を自主的に行うことが
できる。したがって、次の動作を発生させる別の機構を
必ずしも必要としない。

【００２８】このテレスクリプトによるリモートプログ
ラミングについては、「リモートプログラミングの実施
方法」（特願平６−１７９７６７、特開平７−１８２１
７４）に詳述されているが、ここでその手法について説
明する。

【００２９】このリモートプログラミングは、複数の計
算機システムを結ぶ通信ネットワーク上での処理を記述
する方法の一種で、ネットワークを渡り歩く移動可能な
プロセスであるエージェントと、エージェントが入って
くる固定プロセスであるプレイス（Place ）により実現
される。

【００３０】図５は、プレイスの構成を示している。プ
レイスは、他のプロセスと識別可能なテレネーム（tele
name）を持ち、任意有限個の子プロセスを持つことがで
きる。また、プレイスは、自己および他のプロセスより
参照可能な任意有限個のデータと、自己および他のプロ
セスより呼出し可能な任意有限個の手続きとを有する。

【００３１】さらに、メインルーチンとして手続きlive
を持ち、作成されたプレイスはｌｉｖｅを実行する。プ
レイスは、ｌｉｖｅが実行されている間だけ存在し、ｌ
ｉｖｅが終了すると消滅する。プレイスが消滅すると、
その子プロセスも終了し、消滅する。

【００３２】図６は、エージェントの構成を示してい
る。エージェントは、他のプロセスと識別可能なテレネ
ームを持ち、あるプレイスの中の子プロセスとしてのみ
存在する。また、エージェントは、自己および他のプロ
セスより参照可能な任意有限個のデータと、自己および
他のプロセスより呼出し可能な任意有限個の手続きとを
有する。

【００３３】さらに、メインルーチンとして手続きｌｉ
ｖｅを持ち、作成されたエージェントはｌｉｖｅを実行
する。エージェントは、ｌｉｖｅが実行されている間だ
け存在し、ｌｉｖｅが終了すると消滅する。エージェン
トの手続きｌｉｖｅの中でコマンドｇｏが実行される
と、そのエージェントはネットワークを介して指定され
た行き先へ移動する。

【００３４】図７は、コマンドｇｏによるオペレーショ
ンの例を示している。図７において、プレイス４１内の
エージェント４２は、ｇｏの実行により、行き先のプレ
イス４４を指定するデータであるチケット（Ticket）４
３を得て、指定されたプレイス４４に移動する。

【００３５】このとき、エージェント４２は、ｇｏによ
りｌｉｖｅの実行を一時中断し、保持したデータととも
に凍結（圧縮）され、パック化される。そして、チケッ
ト４３に示されたプレイス４４に送られ、プレイス４４
により受け入れをチェックされる。プレイス４４に受け
入れられると、その中に子プロセスとして置かれた後、
解凍（伸張）され、ｇｏの次のコマンドからｌｉｖｅの
実行を再開する。

【００３６】また、エージェントは、手続きｌｉｖｅの
中で自己の置かれているプレイス内にある他のエージェ
ントを求めるコマンドｍｅｅｔを呼出すことができる。
コマンドｍｅｅｔの実行時には、エージェントは相手の
エージェントを指定するデータであるペティション（Pe
tition）を用いる。

【００３７】図８は、コマンドｍｅｅｔによるオペレー
ションの例を示している。図８において、プレイス５１
内のエージェント５２は、コマンドｍｅｅｔによりある
ペティションを指定する。プレイス５１は、ペティショ
ンにより指定された条件に該当するエージェントを探
す。そして、プレイス５１内に該当するエージェントが
なければ、そのようなエージェントが入ってくるまで待
つ。

【００３８】プレイス５１内のエージェント５３がペテ
ィションの条件に該当すれば、プレイス５１は、エージ
ェント５２が相互作用を希望していることをエージェン
ト５３に伝える。そして、エージェント５３がエージェ
ント５２の希望を受け入れる旨の戻り値を返すと、プレ
イス５１は、エージェント５３へのポインタをｍｅｅｔ
の戻り値としてエージェント５２に返す。その後、エー
ジェント５２は、エージェント５３へ直接アクセスし
て、情報交換等を行うことが可能になる。

【００３９】以下では、このようなリモートプログラミ
ングの手法を用いてスケジュールの分散管理を行う実施
形態について説明する。本実施例では、スケジュール中
に発生する障害を先手を打って知るために、スケジュー
ルデータと１対１に対応し、そのスケジュールデータに
関する障害等を自律的に判断するエージェントが用いら
れる。自律性を持つプロセスであるエージェントを用い
ることにより、スケジュール中の個々の要素を独立に自
動的に管理することができる。

【００４０】このエージェントは、緊急の度合いを考慮
して連絡手段を自動的に判別し、スケジュールに従って
行動するユーザに障害等の内容を伝える。これにより、
障害が発生していても、ユーザはそのような事象の下で
最善の行動を取ることが可能になる。

【００４１】また、本実施形態では、事象の重要度を判
定する判定ルールをスケジュールデータ毎に関数の形で
持たせるため、スケジュールデータに対応した判定ルー
ルを探索する手間が省ける。また、判定ルールを関数化
することで、その変更が簡単になり、判定ルールを容易
に拡張することが可能になる。

【００４２】図９は、本実施形態の電子秘書システムの
構成図である。図９の電子秘書システムは、秘書装置６
２、スケジュール管理機構６３、イベント抽出機構６
４、イベントプレイス機構６５、連絡機構６６、スケジ
ュールＤＢ６１、および住所録ＤＢ６７を備え、スケジ
ュールを管理する秘書の役割を果たす。

【００４３】例えば、秘書装置６２、スケジュール管理
機構６３、イベント抽出機構６４、イベントプレイス機
構６５、および連絡機構６６は、それぞれ計算機を有す
る情報処理装置により実現され、通信ネットワークによ
り互いに接続されている。

【００４４】図１０は、これらの装置または機構の一例
である情報処理装置の構成図である。図１０の情報処理
装置は、ＣＰＵ（中央処理装置）８２、メモリ８３、通
信部８４、データベース８６、入出力装置８７、および
それらを結ぶバス８５を有し、通信部８４を介して通信
ネットワーク８１に接続されている。

【００４５】ＣＰＵ８２はメモリ８３を利用してエージ
ェントやプレイス等のプロセスを生成し、データベース
８６のデータを参照しながら必要な処理を行う。生成さ
れたエージェントは通信部８４を介して、通信ネットワ
ーク８１上の他の情報処理装置内のプレイスに移動する
ことが可能である。入出力装置８７は、例えばキーボー
ド等の入力機器を備えたディスプレイ端末である。

【００４６】例えば、秘書装置６２の場合はデータベー
ス８６はスケジュールＤＢ６１に相当し、連絡機構６６
のの場合はデータベース８６は住所録ＤＢ６７に相当す
る。その他の機構については、必ずしもデータベース８
６を備える必要はない。

【００４７】図９において、スケジュール管理機構６３
はユーザにより操作され、スケジュール情報の入力を受
け付けてそれを秘書装置６２に伝える。秘書装置６２
は、受け取ったスケジュール情報に基づいてスケジュー
ル変更処理を行い、スケジュールＤＢ６１内の各個人の
スケジュールデータを更新する。スケジュールデータ
は、例えば交通機関の路線のような、ユーザが利用する
資源毎に作成される。

【００４８】スケジュール変更処理においてスケジュー
ルデータが追加された場合は、秘書装置６２は、その利
用資源の状態を監視する秘書エージェント７１を作成
し、イベントプレイス機構６５に送り込む。イベントプ
レイス機構６５には、各利用資源に対応するプレイスで
あるイベントプレイス７３が、利用資源の数に応じてあ
らかじめ複数用意されている。利用資源が移動手段に対
応する場合は、例えば、利用する可能性のある全交通機
関のすべての路線について、イベントプレイス７３が作
成される。

【００４９】秘書エージェント７１は行き先のイベント
プレイス７３に到着すると、イベントチェック処理を行
って、対応するイベントプレイス７３の状態を監視す
る。各イベントプレイス７３の状態は、対応する資源に
関するイベント情報がイベント抽出機構６４に入力され
た時に更新される。イベント情報は、例えば特定の交通
機関に発生した事故等の情報である。イベント抽出機構
６４はイベント抽出処理によりイベント情報の文字デー
タ等を解析し、解析結果に基づくイベント変更処理を行
って、対応するイベントプレイス７３の状態を更新す
る。

【００５０】イベントプレイス７３の状態は、例えば、
対応する資源に障害が発生して利用不可能な状態と、通
常の利用可能な状態のうちのいずれかを表す。交通機関
の場合は、利用不可能な状態は不通状態である。

【００５１】イベントプレイス７３の更新により秘書エ
ージェント７１はインタラプトを受け、イベントプレイ
ス７３が例えば不通または通常という２つの状態のいず
れに相当するかを判断することができる。

【００５２】また、秘書エージェント７１は、秘書装置
６２からイベントプレイス機構６５に送り込まれた時、
すなわちスケジュールＤＢ６１が更新された直後に、監
視対象のイベントプレイス７３が既に不通状態にあれ
ば、そのことを連絡機構６６を介してユーザに通知す
る。イベントプレイス７３の状態の更新があっても、例
えばそれが不通区間の路線上でさらに別の事故が起こっ
た場合のように、結果的に状態に変化がない時は、秘書
エージェント７１は何もしない。

【００５３】また、秘書エージェント７１は、状態に実
質的な変化があった時に、その事象の入力時刻と資源を
利用する予定時刻との差により事象の重要度を判定する
判定ルールを持っている。この判定ルールは秘書エージ
ェント７１の作成時に渡されるので、秘書装置６２にお
いて判定ルールを動的に変更することも可能である。

【００５４】イベントプレイス７３の状態変化と判定ル
ールは、秘書エージェント７１が作成する連絡エージェ
ント７２により連絡機構６６に伝えられる。秘書エージ
ェント７１は、スケジュールデータに記された資源の利
用終了時刻を過ぎると、自発的に消滅する。

【００５５】連絡機構６６は、連絡エージェント７２か
ら状態変化と判定ルールを受け取ると、住所録ＤＢ６７
にあらかじめ格納されている連絡手段データに記述され
たユーザの連絡先に、対応する資源の状態を連絡する。
例えば、このとき使用される連絡手段は、現在時刻から
利用開始時刻までの時間的余裕から判定ルールを用いて
算出された重要度に基づいて、切り換えられる。

【００５６】次に、図１１から図１５までを参照しなが
ら、図９の電子秘書システムで用いられるデータの構造
について説明する。図１１は、スケジュールＤＢ６１に
格納されるスケジュールデータの構造の例を示してい
る。図１１のスケジュールデータは、ｗｈｏ、ｆｒｏ
ｍ、ｔｏ、ｗｈｅｒｅ、ｂｙ、および判定ルールを要素
として有する。ｗｈｏはスケジュールに従って行動する
主体を表し、例えば個人や団体等のユーザがこれに該当
する。

【００５７】ｂｙは利用する資源を表し、移動手段の場
合は交通機関の路線名等がこれに該当する。ｆｒｏｍと
ｔｏはそれぞれ利用開始日時と利用終了日時を表し、ｗ
ｈｅｒｅは行動主体が存在する場所を表す。例えば、ｂ
ｙは山手線や中央線等であり、ｗｈｅｒｅは東京や神奈
川等であるが、ｗｈｅｒｅは省略することもできる。

【００５８】また、判定ルールは、このスケジュールデ
ータに記された資源に障害が発生したり、それが障害か
ら回復したりした場合に、その状態変化がスケジュール
に及ぼす影響の重要度を判定するために用いられる。ま
た、その重要度に基づいて行う具体的なオペレーション
も記述している。

【００５９】図１２は、イベント抽出機構６４からイベ
ントプレイス機構６５に渡されるイベントデータの構造
の例を示している。図１２のイベントデータは、ｂｙ、
ｗｈｅｎ、ａｃｃｉｄｅｎｔ、およびｆｌａｇを要素と
して有する。ｂｙはスケジュールデータの場合と同様で
ある。

【００６０】ｗｈｅｎは障害や回復等のイベントの発生
日時を表すが、代わりに、イベント抽出機構６４にイベ
ント情報が入力した日時をｗｈｅｎとして用いてもよ
い。ａｃｃｉｄｅｎｔは事故や渋滞等のイベント名を表
し、ｆｌａｇはイベントの種別を表す。ここでは、イベ
ントが発生した場合にｆｌａｇの値をＯＮとし、終了し
た場合にＯＦＦとする。

【００６１】図１３は、住所録ＤＢ６７に格納される連
絡手段データの構造の例を示している。図１３の連絡手
段データは、ｗｈｏ、複数の連絡手段のアドレス、およ
び重要度／連絡手段対応表を要素として有する。ｗｈｏ
はスケジュールデータの場合と同様である。

【００６２】連絡手段のアドレスとしては、電子メール
アドレス、ページャ呼出番号、携帯電話呼出番号などが
記述される。ページャは、例えばポケットベルのことを
指す。重要度／連絡手段対応表には、判定ルールにより
算出された重要度に応じて、用いられる連絡手段が記載
されている。

【００６３】図１４は、各イベントプレイス７３が保持
するデータの構造の例を示している。図１４のデータ
は、ｂｙ、秘書エージェント在中場所、および事象の並
びを要素として有する。ｂｙはスケジュールデータの場
合と同様である。

【００６４】秘書エージェント在中場所は、イベントプ
レイス７３内に送り込まれた秘書エージェント７１の存
在場所を特定する情報で、例えば秘書エージェント７１
へのポインタ等がこれに該当する。一般に、イベントプ
レイス７３内には、複数の秘書エージェントが存在する
ことができる。事象の並びには、イベント抽出機構６４
から渡されたイベントデータが格納される。

【００６５】図１５は、秘書エージェント７１が保持す
るデータの構造の例を示している。図１５のデータは、
ｆｒｏｍ、ｔｏ、判定ルール、およびｗｈｏを要素とし
て有する。これらの情報は、秘書エージェント７１の作
成時にスケジュールデータからコピーされる。

【００６６】次に、図１６から図２１までを参照しなが
ら、図９の電子秘書システムにおいて行われる各処理に
ついて説明する。図１６は、秘書装置６２およびイベン
トプレイス機構６５により行われるスケジュール変更処
理のフローチャートである。図１６において処理が開始
されると、秘書装置６２は、まずスケジュール管理機構
６３からスケジュールデータとコマンドの対または並び
を受け取る（ステップＳ１）。コマンドは、スケジュー
ルデータの“追加”または“削除”のいずれかを表す。

【００６７】次に、受け取ったコマンドが“追加”かど
うかを判定し（ステップＳ２）、“追加”であればスケ
ジュールデータをスケジュールＤＢ６１に追加する（ス
テップＳ３）。そして、スケジュールデータ中のｂｙに
より行き先を指定したコマンドｇｏを持つ秘書エージェ
ント７１を作成する（ステップＳ４）。このとき、同時
にスケジュールデータ中のｗｈｏ、ｆｒｏｍ、ｔｏ、お
よび判定ルールを秘書エージェント７１に与えておく。

【００６８】作成された秘書エージェント７１は、ｇｏ
により凍結され、イベントプレイス機構６５内の指定さ
れたｂｙを持つイベントプレイス７３に移動する（ステ
ップＳ５）。このとき、該当するイベントプレイス７３
があるかどうかが調べられ（ステップＳ６）、それが存
在すれば、秘書エージェント７１はそこでイベントプレ
イス機構６５により解凍される（ステップＳ７）。解凍
された秘書エージェント７１は、次にイベントチェック
処理を行って（ステップＳ８）、処理を終了する。

【００６９】ステップＳ６において、該当するイベント
プレイス７３が存在しなければ、例外処理を行って（ス
テップＳ９）、処理を終了する。例外処理においては、
例えば、エラーメッセージがスケジュール管理機構６３
のディスプレイに表示される。この場合、秘書エージェ
ント７１はイベントプレイス７３には送られない。例外
処理は、該当するイベントプレイス７３がイベントプレ
イス機構６５に用意されていなかった場合に行われる。

【００７０】また、ステップＳ２においてコマンドが
“削除”であれば、秘書装置６２は受け取ったスケジュ
ールデータと一致するものをスケジュールＤＢ６１内で
探してそれを削除し、イベントプレイス機構６５にその
スケジュールデータを送る（ステップＳ１０）。

【００７１】イベントプレイス機構６５は、送られたス
ケジュールデータのｂｙに一致するｂｙを持つイベント
プレイス７３を探し（ステップＳ１１）、その秘書エー
ジェント在中場所を参照する。そして、スケジュールデ
ータのｗｈｏ、ｆｒｏｍ、ｔｏと一致するデータを持つ
秘書エージェント７１を探す（ステップＳ１２）。

【００７２】該当する秘書エージェント７１があるかど
うかを調べ（ステップＳ１３）、それが存在すればその
秘書エージェント７１を殺して（終了させて）（ステッ
プＳ１４）、処理を終了する。終了した秘書エージェン
ト７１は、自動的に削除される。該当する秘書エージェ
ント７１が存在しなければ、そのまま処理を終了する。
これは、秘書エージェント７１が既に自発的に消滅して
いる場合に相当する。

【００７３】図１７は、イベント抽出機構６４により行
われるイベント抽出処理のフローチャートである。図１
７において処理が開始されると、イベント抽出機構６４
はイベント入力待ちのループ処理を開始し（ステップＳ
２１）、イベント情報が入力されたかどうかを判定する
（ステップＳ２２）。イベント情報が入力されなけれ
ば、ステップＳ２２の判定を繰り返す。

【００７４】交通情報の文字データなどのイベント情報
が外部から入力されると、それを解析して図１２のよう
なイベントデータを作成し（ステップＳ２３）、イベン
トプレイス機構６５に送付する（ステップＳ２４）。イ
ベント情報は通信ネットワーク８１から入力する場合も
あり、入出力装置８７からオペレータにより入力される
場合もある。

【００７５】作成されたイベントデータのｆｌａｇは、
新たなイベントの発生時にはＯＮに設定され、既に発生
していたイベントの終了時にはＯＦＦに設定される。例
えば、事故の発生時にはｆｌａｇはＯＮに設定され、そ
の回復時にはＯＦＦに設定される。したがって、１つの
ａｃｃｉｄｅｎｔに対しては、ｆｌａｇ＝ＯＮのイベン
トデータとｆｌａｇ＝ＯＦＦのイベントデータの２つが
作成されることになり、最終的には必ず対になる。

【００７６】次に、ループ処理を終了するかどうかを判
定し（ステップＳ２５）、終了しない場合はステップＳ
２２以降の処理を繰り返す。実際には、このループ処理
はイベント入力待ちの無限ループとして設定され、通常
は終了しない。ただし、システム自体に異常をきたした
ような場合には、処理を終了する。

【００７７】図１８は、イベントデータを受け取ったイ
ベントプレイス機構６５が行うイベント変更処理のフロ
ーチャートである。図１８において処理が開始される
と、イベントプレイス機構６５は、まず受け取ったイベ
ントデータのｂｙに一致するｂｙを持つイベントプレイ
ス７３を探す（ステップＳ３１、Ｓ３２）。該当するイ
ベントプレイス７３があれば、次に、イベントデータの
ｆｌａｇがＯＮかどうかを調べる（ステップＳ３３）。

【００７８】そして、ｆｌａｇがＯＮであれば、そのイ
ベントプレイス７３の事象の並びにイベントデータを追
加する（ステップＳ３４）。次に、イベントプレイス７
３の秘書エージェント在中場所にあるすべての秘書エー
ジェント７１に、そのイベントデータを引数とする割り
込みを送り（ステップＳ３５）、処理を終了する。

【００７９】ステップＳ３３においてｆｌａｇがＯＦＦ
であれば、そのイベントプレイス７３の事象の並びから
イベントデータのａｃｃｉｄｅｎｔと一致するａｃｃｉ
ｄｅｎｔを持つものを探し、それを削除して（ステップ
Ｓ３６）、ステップＳ３５の処理を行う。

【００８０】また、ステップＳ３２において該当するイ
ベントプレイス７３がなければ、例外処理を行って（ス
テップＳ３７）、処理を終了する。例外処理において
は、例えば、エラーメッセージがイベント抽出機構６４
のディスプレイに表示される。

【００８１】図１８のイベント変更処理により、イベン
トが発生した時にイベントプレイス７３に事象が追加さ
れ、終了すると削除されるので、イベントプレイス７３
内の事象の並びをチェックすることにより、対応する資
源に障害が発生しているかどうかを知ることができる。

【００８２】図１９は、イベントプレイス７３において
解凍された秘書エージェント７１が行うイベントチェッ
ク処理のフローチャートである。秘書エージェント７１
は、解凍されると同時に起動される。図１９において処
理が開始されると、秘書エージェント７１は、まず自己
が存在するイベントプレイス７３の事象の並びに事象
（イベントデータ）があるかどうかを調べる（ステップ
Ｓ４１）。

【００８３】イベントデータがあれば、そのｂｙと、文
字列“事故発生中”と、（ｆｒｏｍ−現在時刻）の値
と、判定ルールと、ｗｈｏとをデータとして保持する連
絡エージェント７２を作成し、連絡機構６６に送付する
（ステップＳ４２）。連絡エージェント７２は、例えば
コマンドｓｅｎｄを用いて生成され、送付される。

【００８４】ｓｅｎｄは、エージェントの手続きｌｉｖ
ｅの中で実行され、そのエージェントの複製を作って他
のプレイスに送るコマンドである。ここでは、連絡エー
ジェント７２は、秘書エージェント７１のクローンエー
ジェントとして生成される。

【００８５】連絡エージェント７２が保持するデータの
中で、ｆｒｏｍ、判定ルール、およびｗｈｏは秘書エー
ジェント７１から複写されて用いられる。また、現在時
刻としては、イベントプレイス機構６５内のタイマ機構
（不図示）から得た日時を用いる。ただし、イベントデ
ータのｗｈｅｎの値と現在時刻とがあまり違わない場合
には、現在時刻の代わりにｗｈｅｎを用いてもよい。

【００８６】連絡エージェント７２を連絡機構６６に送
ることにより、ｗｈｏに記されたユーザに“事故発生
中”という文字列情報が自動的に伝達される。ステップ
Ｓ４１でイベントプレイス７３にイベントデータがなけ
れば、そのままステップＳ４３以降の処理を行う。

【００８７】次に、秘書エージェント７１はループ処理
を開始し（ステップＳ４３）、現在時刻が自己の保持す
るｔｏを過ぎているかどうかをチェックする（ステップ
Ｓ４４）。それがｔｏを過ぎていなければ、次にイベン
トプレイス機構６５からの割り込みがあるかどうかをチ
ェックする（ステップＳ４５）。

【００８８】割り込みがあれば、イベントプレイス機構
６５から渡されたイベントデータを用いて割り込み処理
を行い、イベントの内容を連絡機構６６に通知して（ス
テップＳ４６）、ステップＳ４４以降の処理を繰り返
す。割り込みがなければそのままステップＳ４４以降の
処理を繰り返す。

【００８９】ステップＳ４４、Ｓ４５、Ｓ４６のループ
処理は、一定時間毎に繰り返される。そして、ステップ
Ｓ４４において現在時刻がｔｏを過ぎれば、もはや該当
する資源の状態を監視する必要はなくなるので、自律的
に処理を終了して（ステップＳ４７）、消滅する。この
ように、秘書エージェント７１は不要になれば自主的に
消滅するので、システム内の計算機資源が効率的に運用
される。

【００９０】図２０は、図１９のステップＳ４６におい
て行われる割り込み処理のフローチャートである。図２
１において処理が開始されると、秘書エージェント７１
は、まず自己が存在するイベントプレイス７３の事象の
並びに事象（イベントデータ）があるかどうかを調べる
（ステップＳ５１）。

【００９１】イベントデータがあれば、ステップＳ４２
と同様にして、ｂｙと、文字列“事故発生中”と、（ｆ
ｒｏｍ−現在時刻）の値と、判定ルールと、ｗｈｏとを
データとして保持する連絡エージェント７２を作成し
て、連絡機構６６に送付し（ステップＳ５３）、処理を
終了する。

【００９２】また、イベントデータがなければ、引数と
して渡されたイベントデータのｂｙと、文字列“回復”
と、（ｆｒｏｍ−現在時刻）の値と、判定ルールと、ｗ
ｈｏとをデータとして保持する連絡エージェント７２を
作成して、連絡機構６６に送付し（ステップＳ５２）、
処理を終了する。

【００９３】こうして、イベントプレイス７３内の事象
の並びが空かどうかに応じて、文字列“回復”または
“事故発生中”が連絡機構６６に伝えられる。尚、イベ
ントプレイス７３の事象の並びにイベントデータが複数
ある場合は、文字列を“多重事故発生中”としてもよ
い。また、イベントデータの個数が多くなるほど重要度
が大きくなるようなオペレーションを、判定ルールとし
て用意しておいてもよい。

【００９４】図２１は、連絡エージェント７２を受け入
れた連絡機構６６が行う連絡処理のフローチャートであ
る。図２１において処理が開始されると、連絡機構６６
は、まず連絡エージェント７２からｂｙ、文字列、（ｆ
ｒｏｍ−現在時刻）の値、判定ルール、およびｗｈｏを
受け取る（ステップＳ６１）。連絡エージェント７２
は、連絡機構６６にこれらのデータを渡すと自律的に消
滅する。

【００９５】次に、連絡機構６６は（ｆｒｏｍ−現在時
刻）をパラメータＴとする判定ルールを用いて、そのイ
ベントの重要度を計算する（ステップＳ６２）。重要度
は、Ｔが小さいほど、すなわち現在時刻から開始時刻ま
での時間的余裕が少ないほど大きくなるように定義す
る。

【００９６】ここでは、例えば、Ｔの逆数またはＴ² の
逆数を重要度を表す関数として用いる。そのほかに、Ｔ
が一日以内なら重要度を大、Ｔが一週間以内なら重要度
を中、Ｔが一週間を超えるなら重要度を小とするような
関数を用いてもよい。

【００９７】次に、住所録ＤＢ６７からｗｈｏに対応す
る図１３のような連絡手段データを取得し（ステップＳ
６３）、その重要度／連絡手段対応表を参照する（ステ
ップＳ６４）。そして、求めた重要度の値に対応する連
絡手段を選択し、そのアドレスを連絡手段データから取
得する。次に、そのアドレスを用いて、選択した連絡手
段でユーザに連絡して（ステップＳ６５）、処理を終了
する。

【００９８】例えば、ｗｈｏに記されたユーザが携帯電
話、ページャ、および電子メールを連絡手段として登録
している場合は、重要度に適当な閾値を設けて、重要度
が大きければ携帯電話、中くらいならばページャ、小さ
ければ電子メールが選択されるようにしておく。携帯電
話には、例えば音声合成で生成された音声により自動的
に連絡される。こうしておけば、緊急度の高いイベント
の変化ほど迅速な連絡手段でユーザに通知されることに
なる。

【００９９】連絡する内容は、連絡エージェント７２か
ら受け取ったｂｙと文字列を用いて、例えば“山手線に
事故発生中”または“山手線が回復”のように構成され
る。連絡を受けたユーザは、その情報に基づいてスケジ
ュールの変更をスケジュール管理機構６３に指示するな
どの適当な対策を講じることができる。

【０１００】以上説明したリモートプログラミングによ
る電子秘書システムにおいて、秘書装置６２、スケジュ
ール管理機構６３、イベント抽出機構６４、イベントプ
レイス機構６５、および連絡機構６６のうちのいくつか
または全部を、同一の情報処理装置上で実現してもよ
い。また、イベントプレイス機構６５から連絡機構６６
へは、連絡エージェント７２によりデータが伝えられて
いるが、その代わりに秘書エージェント７１がデータの
みを直接送付するようにしてもよい。

【０１０１】また、スケジューリングされる資源の例と
して交通機関を用いて説明したが、本発明はこれに限ら
ず、例えば会議室、備品、設備等の他の資源についても
同様に適用できる。この場合、対応する資源の識別情報
がスケジュールデータ等のｂｙとして用いられる。そし
て、その資源が何等かの理由で利用不可能となった時
に、イベントデータのｆｌａｇがＯＮに設定され、再び
利用可能となった時にそれがＯＦＦに設定される。

【０１０２】さらに、図９の実施形態において、必ずし
もエージェントやプレイスを用いる必要はなく、それぞ
れの処理を普通のプロセスにより行ってもよい。この場
合は、ネットワークを介したやりとりは、例えばＲＰＣ
（remote procedure call ）により実行される。

【０１０３】

【発明の効果】本発明によれば、スケジュールされた利
用資源に発生した障害等のイベント情報を、その利用予
定日時より前にユーザに通知することが可能になる。こ
れにより、連絡を受けたユーザは障害の発生した資源の
利用予定をキャンセルして、代わりに他のスケジュール
を優先させるなどの処置を取ることができる。したがっ
て、障害に遭遇する前に先手を打って、最善の行動をと
ることが可能となる。

【図面の簡単な説明】

【図１】本発明の原理図である。

【図２】一括管理システムの構成図である。

【図３】第１の分散管理システムの構成図である。

【図４】第２の分散管理システムの構成図である。

【図５】プレイスの構成を示す図である。

【図６】エージェントの構成を示す図である。

【図７】オペレーションｇｏを示す図である。

【図８】オペレーションｍｅｅｔを示す図である。

【図９】電子秘書システムの構成図である。

【図１０】情報処理装置の構成図である。

【図１１】スケジュールデータの構造を示す図である。

【図１２】イベントデータの構造を示す図である。

【図１３】連絡手段データの構造を示す図である。

【図１４】イベントプレイスの持つデータの構造を示す
図である。

【図１５】秘書エージェントの持つデータの構造を示す
図である。

【図１６】スケジュール変更処理のフローチャートであ
る。

【図１７】イベント抽出処理のフローチャートである。

【図１８】イベント変更処理のフローチャートである。

【図１９】イベントチェック処理のフローチャートであ
る。

【図２０】割り込み処理のフローチャートである。

【図２１】連絡処理のフローチャートである。

【符号の説明】

１ 管理手段 ２ 検出手段 ３ 通知手段 １１，２１，３１ 管理機構 １２，６１ スケジュールデータベース １３，２２ 判定ルールデータベース ４１，４４，５１ プレイス ４２，５２，５３ エージェント ４３ チケット ６２ 秘書装置 ６３ スケジュール管理機構 ６４ イベント抽出機構 ６５ イベントプレイス機構 ６６ 連絡機構 ６７ 住所録データベース ７１ 秘書エージェント ７２ 連絡エージェント ７３ イベントプレイス ８１ 通信ネットワーク ８２ ＣＰＵ ８３ メモリ ８４ 通信部 ８５ バス ８６ データベース ８７ 入出力装置

Claims (13)

【特許請求の範囲】
1. 【請求項１】 スケジュール管理を行う情報処理システ
   ムにおいて、 ユーザのスケジュール情報を管理する管理手段と、 前記ユーザの利用する資源に関するイベント情報の入力
   を検出する検出手段と、 前記スケジュール情報と前記検出手段により検出された
   前記イベント情報とに基づいて、前記スケジュール情報
   に含まれる資源に関するイベント情報を前記ユーザに通
   知する通知手段と、 を備えることを特徴とする電子秘書システム。
2. 【請求項２】 前記検出手段は、前記ユーザが利用する
   交通機関に関する障害情報を、前記ユーザの利用する資
   源に関するイベント情報として検出し、前記通知手段
   は、前記スケジュール情報に含まれる交通機関に関する
   障害情報を前記ユーザに通知することを特徴とする請求
   項１記載の電子秘書システム。
3. 【請求項３】 前記管理手段は、前記スケジュール情報
   を資源毎に管理し、前記通知手段は、前記検出されたイ
   ベント情報を資源毎に該スケジュール情報と比較して、
   該検出されたイベント情報が前記スケジュール情報に含
   まれる資源に関係するかどうかを判定することを特徴と
   する請求項１記載の電子秘書システム。
4. 【請求項４】 前記通知手段は、前記検出されたイベン
   ト情報の緊急度に応じて、前記ユーザに通知する連絡方
   法を変更することを特徴とする請求項１記載の電子秘書
   システム。
5. 【請求項５】 前記通知手段は、前記スケジュール情報
   に対応する判定ルールを用いて、前記検出されたイベン
   ト情報の重要度を計算し、該重要度が大きいイベント情
   報ほど前記緊急度が高いと解釈することを特徴とする請
   求項４記載の電子秘書システム。
6. 【請求項６】 前記通知手段は、前記重要度と連絡方法
   の対応表を備え、該対応表から該重要度に応じた連絡方
   法を認識することを特徴とする請求項５記載の電子秘書
   システム。
7. 【請求項７】 前記通知手段は、エージェントプロセス
   を用いて、前記スケジュール情報に含まれる資源に関す
   るイベント情報を前記ユーザに通知することを特徴とす
   る請求項１記載の電子秘書システム。
8. 【請求項８】 前記エージェントプロセスは、前記ユー
   ザの利用する資源毎に生成され、不要になれば自律的に
   消滅することを特徴とする請求項７記載の電子秘書シス
   テム。
9. 【請求項９】 スケジュール管理を行う情報処理システ
   ムにおいて、 ユーザのスケジュール情報を管理する管理手段と、 前記ユーザの利用する交通機関に関する障害情報の入力
   を検出する検出手段と、 前記スケジュール情報と前記検出手段により検出された
   前記障害情報とに基づいて、前記スケジュール情報に含
   まれる交通機関に関する障害情報を前記ユーザに通知す
   る通知手段と、 を備えることを特徴とする電子秘書システム。
10. 【請求項１０】 前記管理手段は、前記スケジュール情
    報を路線毎に管理し、前記通知手段は、前記検出された
    障害情報を路線毎に該スケジュール情報と比較して、該
    検出されたイベント情報が前記スケジュール情報に含ま
    れる路線に関係するかどうかを判定することを特徴とす
    る請求項９記載の電子秘書システム。
11. 【請求項１１】 スケジュール管理を行う情報処理シス
    テムにおいて、 ユーザのスケジュール情報および住所情報を管理する管
    理手段と、 前記ユーザの利用する資源に関するイベント情報の入力
    を検出する検出手段と、 前記スケジュール情報と住所情報と前記検出手段により
    検出された前記イベント情報とを用いて、該イベント情
    報を前記ユーザに通知する通知手段と、 を備えることを特徴とする電子秘書システム。
12. 【請求項１２】 スケジュール管理を行う情報処理装置
    により用いられる記憶媒体であって、 該情報処理装置が、 ユーザのスケジュール情報を管理し、 前記ユーザの利用する資源に関するイベント情報の入力
    を検出し、 前記スケジュール情報と前記検出手段により検出された
    前記イベント情報とに基づいて、前記スケジュール情報
    に含まれる資源に関するイベント情報を前記ユーザに通
    知するように導くことを特徴とする記憶媒体。
13. 【請求項１３】 情報処理装置を用いてスケジュールを
    管理する方法において、 ユーザのスケジュール情報を管理し、 前記ユーザの利用する資源に関するイベント情報の入力
    を検出し、 前記スケジュール情報と前記検出手段により検出された
    前記イベント情報とに基づいて、前記スケジュール情報
    に含まれる資源に関するイベント情報を前記ユーザに通
    知することを特徴とするイベント通知方法。