JPH10268957A - 情報処理装置及びその方法 - Google Patents

Abstract

(57)【要約】 【課題】 実行すべき事柄をユーザに思い出させるため
の通知を、適切な状況で実行する。 【解決手段】 スケジュールの更新後に、更新されたス
ケジュールに関連する用事が、実行すべき処理が登録さ
れたTo Do Listやスケジュールにあるかどうかをチェッ
クするステップS648と、関連する用事があれば、その用
事をユーザに通知して思い出させるための通知タスクを
タスクテーブル追加するステップS649とを備える。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ユーザに通知を行
なう情報処理装置及びその方法に関するものである。

【０００２】

【従来の技術】ユーザのスケジュールを記憶・管理する
スケジュール管理ソフトを利用することによって、記憶
されたスケジュールを通知させることができる。

【０００３】図32では、ユーザがスケジュール操作画面
322で、「10:30-12:00 新製品レビュー」323を指定し、
通知時刻を開始時刻15分前に指定324した時の一例を示
している。

【０００４】ユーザが上記指定後、ＯＫ325を押すと、
上記で行われた指定が有効になる。

【０００５】上記操作によって、スケジュール開始15分
前の10:15:00には、通知画面326が表示され、スケジュ
ールの存在を知る事ができる。

【０００６】

【発明が解決しようとする課題】しかし、従来技術で
は、ユーザはあらかじめ通知時刻を指定する必要があ
り、その時々の状況に合わせた、対応を行うことができ
なかった。

【０００７】また、従来技術を利用して通知時刻を指定
した場合に、指定された通知時刻以前に離席した場合に
は通知は無意味になってしまう。また時刻以外の通知条
件を指定することができなかった。

【０００８】その為、スケジュールなどの情報を十分に
活用できていなかった。

【０００９】つまり、従来技術では、ユーザが装置から
スケジュールなどの通知を受けるためには、あらかじめ
通知時刻を指定しなければならず、状況に対応した柔軟
な通知が行われない、時刻以外の通知条件を利用できな
いといった問題があった。

【００１０】そこで、本発明の目的は、上記課題を解決
し、状況に応じた適切な通知を行うことにある。

【００１１】

【課題を解決するための手段】上記課題を解決するため
に、本発明によれば、情報処理装置に、所定の通知条件
が満足されたか否かを判定する判定手段と、該判定手段
により前記通知条件が満足されたと判定された場合に、
ユーザが実行すべき事柄を通知する通知手段とを備え
る。

【００１２】また、他の態様によれば、情報処理方法
に、所定の通知条件が満足されたか否かを判定する判定
工程と、該判定工程により前記通知条件が満足されたと
判定された場合に、ユーザが実行すべき事柄を通知する
通知工程とを備える。

【００１３】

【発明の実施の形態】

（実施形態 1）図1は、本実施形態の機能構成を示す図
であり、図6は、システム構成の一例を示す図である。

【００１４】図1の情報処理装置1は、例えば、図6のプ
リンタ61であり、図1の情報処理装置2は、図6において
プリンタ61と関連して処理を行うＰＣ62及び63や電話64
である。

【００１５】図6は、情報処理装置1の１実施形態である
プリンタ61において、情報処理装置2の１実施形態であ
るＰＣ62及び63や電話64からのアクションや、プリンタ
61の後述する操作部11の操作や、ＰＣ62の存在の検出な
どの履歴を、履歴情報65としてプリンタ61内に記憶して
いることを示している。この履歴情報については、図5
につき後述する。

【００１６】なお、後述する各実施形態において、情報
処理装置１及び２は、履歴情報を記憶し、必要な機能を
備えていれば、どのような種類の装置であってもよく、
例えば、プリンタ、スキャナ、ＦＡＸ、デスクトップＰ
Ｃ、ファイルサーバ、デジタルカメラなどでもよい。

【００１７】操作部11は、操作情報12に格納されている
情報に従って、ユーザの操作に必要な画面の表示等を行
い、ユーザが行った操作や指示の情報を、タスク受信部
13及び履歴情報管理部18に渡す。

【００１８】例えば、図6において、ユーザが、情報処
理装置1の１実施形態であるプリンタ61に、情報処理装
置2の１実施形態であるＰＣ62が持つファイル"abc.doc"
の印刷を指示したとすると、図5の507に示すような情報
が、履歴情報管理部18によって履歴情報19に追加され、
同情報がタスク受信部13に渡される。

【００１９】操作情報12は、上記操作部11で参照される
情報・知識であり、操作部11での動作を規定している。
本実施形態では、操作情報12を、タスク受信部13で受信
された情報を元に、後述する処理実行部17により変更・
更新することで、柔軟な操作手順の実現を可能にしてい
る。

【００２０】このように、操作情報12を用いることで、
柔軟な操作手順の実現を可能にし、特に状況のうち、通
信状況に着目することで、通信状況に対応した柔軟な操
作手順の実現を可能にし、ユーザの指示の内容に着目す
ることで定型処理以外の命令に対応した操作手順の実現
を可能にし、操作対象となる内容の優先度に着目するこ
とで優先度に対応した操作手順の実現を可能にし、操作
対象となる内容の項目数に着目することで項目数に対応
した操作手順の実現を可能にしている。

【００２１】例えば、情報処理装置1で、情報処理装置2
を操作する為の方法の１つには、情報処理装置2の操作
情報12を取得して、情報処理装置1の操作情報12を変更
・更新する方法がある。

【００２２】あるいは、操作対象の情報処理装置2との
通信に失敗した時には、通信の失敗に対応して第３の情
報処理装置3から操作情報12を取得することで、通信状
況に対応した操作手順の実現も可能である。あるいは、
ユーザが情報処理装置1の持つ元々の操作情報12が示す
操作部11の操作では、処理不可能な処理の実行を指示し
た時に、対応する処理を実現する為の操作情報12を他の
情報処理装置から取得することで、定型処理以外の命令
に対応した操作手順の実現も可能である。

【００２３】また他の例では、操作情報12が示す、操作
部11の操作対象となる情報の優先度から、それぞれの情
報の優先度に対応した操作が行えるように操作情報12を
変更することで、優先度に対応した操作手順の実現も可
能である。あるいは、同様に操作対象となる情報の数に
応じて操作情報12を変更することで、項目数に対応した
操作手順の実現も可能である。

【００２４】タスク受信部13は、前述の操作部11からの
情報だけでなく、情報処理装置1が置かれた環境の変化
や、情報処理装置2等の他の機器からのタスク等を、状
況の変化として受信する。例えば、ネットワークで接続
されている場合には、ネットワーク上に新たな機器が接
続されたことを検知したり、他機器からの印刷指示をタ
スクとして受信したり、あるいは一定時間の間、何の処
理も行われていないこと等の検知も、ここで行われる。

【００２５】その結果、受信した情報を新たなタスクと
して、タスクテーブル14に追加し、履歴情報管理部18に
渡す。上記タスク受信部13は、後述する処理実行部17と
ともに、異なる機器の間でコミュニケーションを行う為
に必要なものである。

【００２６】例えば、図6において、情報処理装置1の１
実施形態であるプリンタ61とネットワーク等で接続され
た、情報処理装置2の１実施形態であるＰＣ62の電源が
入れられた場合、ＰＣ62の存在を検知し、図5の504に示
すような情報が履歴情報管理部18によって履歴情報19に
追加される。

【００２７】図4は、タスクテーブル14の一例を表す図
である。

【００２８】タスクテーブル14は、図4に示すように、
起動条件と内容、及びそれぞれのタスクが実行される元
になった処理の履歴情報19中の履歴番号を持ったタスク
を格納しているテーブルである。図4では、タスクを、
優先すべき順にテーブルの上位から並べている。タスク
テーブル14へのタスクの追加は、前述のタスク受信部13
及び後述する処理実行部17により行われ、タスクテーブ
ル14からのタスクの取り出しは、後述するタスク解析部
15により行われる。

【００２９】例えば、図4のタスクテーブル14中のタス
ク42で示されたANALYZEは、図5の履歴情報19中の履歴情
報507で示された、履歴No.7のユーザの操作「Print "ab
c.doc" from PC 62」がきっかけとなった生成されたタ
スクなので、元履歴の欄に 7が格納されており、起動条
件は無条件で、内容は上記ユーザの操作の解析となって
いる。また、上記タスク42自体は、履歴No.8の履歴とし
て履歴情報19に追加されるので、これが元になって生成
されたタスク43の元履歴に8が設定され、同様にタスク4
4の元履歴は9に設定される。

【００３０】タスク解析部15は、前述のタスクテーブル
14から最優先タスクを取り出し、そのタスクの目的を解
析する。このタスク解析部15により、目的を解析するこ
とで、後述するプランニング決定部16及び処理実行部17
での効率の悪い処理の実行を避け、最適な処理を行える
ようになる。

【００３１】例えば、図4に示したタスクテーブル14に
格納されたタスク43からは、直接的な目的は印刷するこ
とあり、最終的には印刷された文書をユーザに渡すこと
にあると解析される。これにより、もしより効率的な方
法で最終目的を達することができれば、印刷を実行する
ことさえ不要であることが理解され、それに従ってプラ
ンニングされることになる。

【００３２】プランニング決定部16は、前述のタスク解
析部15の解析結果を受けて、プランニングの知識を参照
して、解析されたタスクの目的に対して行うべき処理を
プランニングする。例えば、図4に示したタスクテーブ
ル14に格納されたタスク43からは、Objectを印刷する前
に、機器BからObjectをPULLすることが、プランニング
される。

【００３３】処理実行部17は、前述のプランニング決定
部16により、決定された内容に従って処理を実行すると
ともに、その処理内容を履歴情報管理部18に渡す。例え
ば、印刷処理を実行した場合には、図5の511に示すよう
な情報が履歴情報管理部18によって履歴情報19に追加さ
れる。

【００３４】履歴情報管理部18は、検索・編集・削除・
条件／設定変更等の操作者が行った操作や、他の情報処
理装置からの指示あるいは情報の入力・受信や、状況検
出や、情報の読み込み・印刷・表示・送信・保存・保留
等の自分自身が行った処理等に対応して、操作部11やタ
スク受信部13や処理実行部17の指示により、操作者・指
示者・処理者など行為者の情報や、操作・指示・処理な
ど行われた行為の情報や、操作・指示・処理の行われた
時刻などの情報や、操作・指示・処理などの行われた場
所又は機器の情報や、行われた操作・指示・処理の対象
の情報等の内容を履歴情報19に、それぞれの履歴情報に
関連を持たせて追加する。また、追加された履歴情報に
関して履歴番号を出力する。

【００３５】また、上記履歴情報19に追加された、操作
・指示・処理の行われた対象の情報等は、ファイル情報
・スケジュール情報・処理が保留された情報・データベ
ース（住所録等）・ある情報から抽出された情報・メー
ル・デバイス管理情報等、他のアプリケーションで扱わ
れる情報と関連付けて記憶することで、それぞれのアプ
リケーションからの利用が容易となる。

【００３６】また、操作部11やタスク受信部13や処理実
行部17等の指示により実行される、履歴条件指定操作等
により、操作や指示や処理に対応した履歴情報を残すか
どうか、対象の実体を残すかどうか、履歴を参照可能な
人等の指定が可能であり、それぞれの指定に従って履歴
情報19に追加される。

【００３７】また、操作部11やタスク受信部13や処理実
行部17等の指示により実行される履歴情報利用処理によ
り、それまでに追加された、複数機器が持つそれぞれの
履歴情報19を元に、以前行なった処理の再実行や、以前
行なった処理の処理対象に対して、印刷・表示・送信・
保存・検索・保留・編集・削除などの新たな処理を施し
たり、履歴の保存に関して、保存期間の変更・保存条件
の設定変更などを行なったり、操作や処理などに関する
知識の更新が行われる。

【００３８】図5は、履歴情報19の一例を表す図であ
る。

【００３９】履歴情報19は、図5に示されるように、履
歴Noと、それぞれの履歴が表す処理が生成されたきっか
けとなった処理の履歴情報の履歴Noを示す前履歴番号
と、それぞれの履歴が表す処理がきっかけとなって生成
された処理の履歴情報の履歴Noを示す後履歴番号と、そ
れぞれの履歴が表す処理の実行時刻と、処理の行為の種
類と、処理の行為者と、処理の行為対象と、処理の行為
元や行為先や行為を行った場所などのその他の情報を持
つ情報から構成される。

【００４０】例えば、図5の507が示す〔No＝7〕は、こ
の履歴情報の履歴番号が7であることを示している。ま
た、〔前＝頭〕は、この履歴が表す処理自体が一連の処
理のきっかけであり、先頭の処理であることを示してい
る。また、〔後＝8〕は、この履歴が表す処理がきっか
けとなって生成された処理の履歴番号が、8であること
を示している。

【００４１】また、〔Time＝2/5 9:30:00〕は、この履
歴が表す処理が2/5 9:30:00に行われたことを示してい
る。また、〔Action＝Operate〕は、この履歴が表す処
理とは、操作であったことを示している。また、〔Acto
r＝Operator〕は、この履歴が表す処理を、操作者が行
ったことを示している。また、〔Object＝「Print "ab
c.doc" from PC 62」〕は、この履歴が表す処理の対象
とは、「Print "abc.doc"from PC 62」という指示であ
ったことを示している。また、〔その他＝操作部11〕
は、この履歴が表す処理を、操作部11を介して行ったこ
とを示している。

【００４２】図2は、本実施形態の処理を実現するため
の各装置のハードウェア構成図である。

【００４３】Ｉ／Ｏ21は、装置外部との入出力を行な
う。ＣＰＵ22は、プログラムを実行するとともに、装置
各部を制御する。ＲＯＭ23は、後述する各フローチャー
トに対応するＣＰＵ22の実行すべきプログラムや固定デ
ータなどを記憶する。ＲＡＭ24は、図1につき後述する
タスクテーブル14や、操作情報12、履歴情報19など、処
理の実行中に発生する各種変数や中間データなどを一時
的に記憶する。また、ＲＡＭ24に、装置外部などからプ
ログラムをロードして記憶させるようにしてもよい。

【００４４】図3は、本実施形態の全体処理の流れを表
す図である。

【００４５】情報処理装置1が起動されると、図4の(a)
のようにステップS31でタスクテーブル14が初期化され
る。

【００４６】続く、ステップS32では、前述の操作部11
から取得されたユーザが行った操作指示の情報や、環境
の変化や、他の機器からのタスク等が状況の変化として
タスク受信部13が受信したかどうかチェックされる。こ
こで、タスクが受信されたと判断された場合、ステップ
S33に進み、情報を受信したという記録が履歴情報19に
図5の504に示すように追加され、図4の(b)に示したよう
に受信情報の解析タスク42がタスクテーブル14の先頭に
追加される。

【００４７】続く、ステップS34で、実行可能なタスク
がタスクテーブル14に存在するかどうかがチェックさ
れ、存在しない場合、ステップS32にもどり、再びタス
クの受信がチェックされる。ここで、タスクが存在する
場合、ステップS35に進み、最優先のタスクがタスクテ
ーブル14から取り出される。

【００４８】続く、ステップS36でタスクの目的が解析
され、ステップS37で行うべき処理がプランニングさ
れ、決定される。タスクテーブル14が図4の(b)に示した
状態の場合、最優先タスク42のANALYZEが取り出され、
その目的が受信情報を解析することにあると理解され、
解析を実行するようにプランニングされる。

【００４９】続く、ステップS38で、上記プランニング
に従った処理を実行し、その記録が履歴情報19に図5の5
08に示すように追加され、必要であれば新たなタスクが
タスクテーブル14に追加される。

【００５０】例えば、図4の(b)に示したタスク42のANAL
YZEからプランニングされた通り、受信情報を解析する
と、ユーザが操作部11により指示した内容「Print "ab
c.doc" from PC 62」が解析され、新たなタスク43のPRI
NTが図4の(c)のように追加される。

【００５１】次に、再びステップS32に戻るが、新たな
タスクが受信されていないので、そのままステップS34
に進み、処理が繰り返される。その結果、前回のステッ
プS38で追加された図4の(c)に示したタスク43のPRINTが
取り出され、解析され、プランニングされる。この場
合、タスクPRINTを実行する為には、Objectが情報処理
装置1に存在しなければならないことが解析され、新た
なタスク44のPULLと、そのPULLされたObjectを利用する
タスク45のPRINTが、図4の(d)のように追加される。

【００５２】更に、処理が繰り返されると、図4の(d)に
示したタスク44のPULLが実行される。更に、処理が繰り
返されると、上記タスクPULLの結果取得されたObjectを
利用して、図4の(e)で示したタスク45が実行される。

【００５３】その結果、タスクテーブル14は、図4の(f)
で示すように、初期化された時と同じ状態に戻る。

【００５４】（実施形態 2）図8は、通信先との通信状
況に応じて、操作手順を決定する情報処理装置の一例を
表す図である。

【００５５】情報処理装置1の１実施形態であるリモコ
ン801の操作部11により実現される操作手順（ＵＩ：Use
r Interfaceの略）は、リモコン801自身が元々持ってい
る操作情報12を参照して実行される場合と、リモコン80
1が、ネットワーク等で接続されている他の情報処理装
置2の１実施形態である複写機804、又はサーバ802の制
御下にある通信施設806から取得した操作情報12を参照
して実行される場合とがある。

【００５６】図8のリモコン801の操作画面のように、操
作開始時にはリモコン801自身が持っている操作情報12
を参照して、「操作したい機械に向けて下さい」という
メッセージを表示している。

【００５７】その指示に従って、ユーザがリモコン801
を複写機804に向けると、リモコン801から複写機804に
向けて、操作情報送信要求を発信する。その結果、送信
された操作情報807を参照して、表示された複写機操作
用の画面が図8の809である。

【００５８】ところが、赤外線通信の場合に、リモコン
801と複写機804の間に障害物があるなどの何らかの原因
で、通信を行うことができなかった場合、携帯電話回線
などを利用して、通信施設806を介してサーバ802と通信
を行う。それにより、今度はサーバ802から操作情報808
を受信し、図8の810のようなネットワーク上から機器を
選択して操作するための画面を表示する。

【００５９】以上のように、本実施形態によれば、通信
状況に応じて最適な操作手順を実現することが可能であ
る。

【００６０】なお、処理の流れの詳細については、上記
処理を実現する為の、通信状況対応処理の流れの一例を
示すフローチャートである図43等を用いて後述する。

【００６１】（実施形態 3）図9は、ユーザが操作しよ
うとしている情報処理装置自身で本来操作可能な処理以
外の処理の実行を指示した場合にも、最適な操作手順を
提供することができる情報処理装置の一例を表す図であ
る。

【００６２】操作部11により実現される操作手順（Ｕ
Ｉ）は、情報処理装置1の１実施形態である複写機901自
身が元々持っている操作情報12を参照して実行される場
合と、ネットワーク等で接続されている他の情報処理装
置2の１実施形態であるサーバ902から取得された操作情
報12を参照して実行される場合がある。

【００６３】図9の複写機901の操作画面905のように、
操作開始時には複写機901自身が持っている操作情報12
を参照して、「複写したい枚数を決めて下さい」等の複
写機901に対する操作を促すメッセージを表示してい
る。通常、ユーザはその指示に従って、複写したい文書
をセットして、枚数を決めて複写を行っている。

【００６４】ところが、図9の907のように、操作画面90
5に無い操作である「ａさんに、送って」という指示を
音声などにより入力すると、情報処理装置1の１実施形
態である複写機901は、操作部11により受け取った上記
ユーザの指示を理解する為に、タスク受信部13を介して
上記指示の解析タスクを生成する。

【００６５】その結果、タスク解析部15及びプランニン
グ決定部16、処理実行部17により、指示の内容を理解
し、その結果、新たに生成された定型処理外命令対応処
理タスクを、図45につき後述するような手順で行われる
処理実行部17の処理として実行する。

【００６６】定型処理外命令対応処理では、情報処理装
置1の１実施形態である複写機901自身で行うべき処理か
どうか判断し、複写機901自身で行うべき処理ではない
と判断されたならば、ネットワーク等で接続された第２
の情報処理装置2の１実施形態であるサーバ902へ、操作
情報12の送信要求を行い、その結果送信された操作情報
12を参照して、複写機901自身の操作情報12を更新し、
図9の操作画面906を表示している。

【００６７】以上のように、本実施形態によれば、ユー
ザが定型処理以外を指示した場合であっても、最適な操
作手順を実現することが可能である。

【００６８】なお、処理の流れの詳細な説明について
は、上記処理を実現する為の、定型処理外命令対応処理
の流れの一例を示すフローチャートである図45等を用い
て後述する。

【００６９】（実施形態 4）図10は、それぞれの出力内
容の優先度に応じて、出力態様を決定・更新する情報処
理装置の一例を表す図である。

【００７０】操作部11により実現される操作手順（Ｕ
Ｉ）は、情報処理装置自身が元々持っている操作情報12
を、操作対象となる情報それぞれの優先度に応じて、決
定・更新された結果を用いて処理されている。

【００７１】図10に示した情報処理装置では、104のよ
うに優先度が高いほど、強調して表示している。

【００７２】例えば、現在の時刻108と比較して、105の
ように時間が迫っている15:00からのABC Meetingの方
を、17:00からのXYZ Meetingより、強調して表示101し
ている。また、ユーザが行わなければならない複数のタ
スクのうち、それぞれのタスクに関連する人について、
106のように一般常識から、同僚である Johnより優先さ
れるべきと判断された社長の仕事「reserve Train for
President」を、強調して表示102している。

【００７３】一方、ユーザに送信された情報のうち、10
7のようにユーザのタスク等の知識から、最も関係が深
いと判断したJohnからのFAXを、強調して表示103してい
る。

【００７４】以上のように、本実施形態によれば、操作
対象となる情報それぞれの優先度に応じて、最適な操作
手順を実現することが可能である。

【００７５】なお、処理の流れの詳細な説明について
は、上記処理を実現する為の、優先度・項目数対応処理
の流れの一例を示すフローチャートである図46等を用い
て後述する。

【００７６】（実施形態 5）図11は、それぞれの出力内
容の優先度に応じて、出力態様を決定・更新する情報処
理装置の一例を表す図である。

【００７７】操作部11により実現される操作手順（Ｕ
Ｉ）は、情報処理装置自身が元々持っている操作情報12
を、操作対象となる情報それぞれの優先度に応じて、決
定・更新された結果を用いて処理されている。

【００７８】図11に示した情報処理装置には、情報処理
装置が参照可能なユーザのスケジュール112が存在す
る。

【００７９】ユーザのスケジュール112に記憶されてい
るそれぞれの予定には、開始時刻、終了時刻、内容、場
所、優先度があり、及び図には記載されていないが、そ
れぞれの予定に関係する出席者や、主催者などの情報が
含まれている。また、優先度はユーザが指定することも
可能であり、値が少ないほど優先度が高いものとして管
理している。

【００８０】図11の場合、現在の時刻113と比較して、
予定114が最も緊急性が高いが、ユーザが設定した優先
度は 5であり、他の予定と比較すると相対的に優先度が
低かったので、表示画面111では、強調して表示してい
ない。

【００８１】また、予定115及び116は、ユーザが設定し
た優先度が同じ 3ではあるが、15:00からの予定115の方
が、緊急性が高いので、表示画面111では、強調して表
示している。

【００８２】一方、予定117は、ユーザが設定した優先
度が 5であり、他の予定と比較して相対的に優先度が低
かっただけでなく、緊急性も低いので、表示画面111で
は表示すらしていない。

【００８３】また、予定118は、ユーザが設定した優先
度は 3であり、他の予定と比較しても相対的に優先度が
低いわけではないが、予定自体が翌日の予定であり、他
の予定と比較して緊急度が特別低いので、表示111すら
していない。

【００８４】以上のように、本実施形態によれば、表示
対象となるスケジュール情報それぞれの優先度に応じ
て、強調表示などの最適な表示形態を実現することが可
能である。

【００８５】なお、処理の流れの詳細な説明について
は、上記処理を実現する為の、優先度・項目数対応処理
の流れの一例を示すフローチャートである図46や、それ
ぞれの情報の優先度を求める為の、優先度取得処理の流
れの一例を示すフローチャートである図48等を用いて後
述する。

【００８６】（実施形態 6）図12は、タスク及び人物の
優先度に応じて、出力態様を決定・更新する情報処理装
置の一例を表す図である。

【００８７】操作部11により実現される操作手順（Ｕ
Ｉ）は、情報処理装置自身が元々持っている操作情報12
を、操作対象となる情報それぞれの優先度に応じて、決
定・更新された結果を用いて処理されている。

【００８８】図12に示した情報処理装置には、ユーザの
実行すべきタスクが登録された ToDo List 等の情報処
理装置が参照可能なタスク122と、人毎の優先度を定義
した情報127とが存在する。

【００８９】ユーザの To Do List等のタスク122に記憶
されているそれぞれのタスクには、期限、内容、関係
者、優先度があり、図12には記載されていないが、それ
ぞれのタスクに関係するスケジュールなどの情報が含ま
れている。また、優先度はユーザが指定することも可能
であり、値が少ないほど優先度が高いものとして管理し
ている。また、人毎の優先度を定義した情報127には、
人物の名前に対して各人の優先度が定義されている。

【００９０】図12の場合、タスク124及び125は、現在の
日付123と比較すると同じ緊急度であり、ユーザが設定
した優先度も同じ 3ではあるが、それぞれのタスクに関
係している人が異なっている。そこで、ユーザが設定し
た人毎の優先度情報127を参照した結果、Mary129より J
ohn128の方が優先度が高いので、表示画面121では、Joh
nが関係するタスク124の「reserve Hotel for John」
を、より強調して表示している。

【００９１】一方、タスク126は、ユーザが設定した優
先度が 5であり、他のタスクと比較して相対的に優先度
が低かっただけでなく、緊急性も低いので、表示画面12
1では、表示すらしていない。

【００９２】以上のように、表示対象となるタスク情報
それぞれの優先度に応じて、強調表示などの最適な表示
形態を実現することが可能である。

【００９３】なお、処理の流れの詳細な説明について
は、上記処理を実現する為の、優先度・項目数対応処理
の流れの一例を示すフローチャートである図46や、それ
ぞれの情報の優先度を求める為の、優先度取得処理の流
れの一例を示すフローチャートである図48等を用いて後
述する。

【００９４】（実施形態 7）図13は、タスク及び人物の
地位の優先度に応じて、出力態様を決定・更新する情報
処理装置の一例を表す図である。

【００９５】図46は、上記処理を実現する為の、優先度
・項目数対応処理の流れの一例を示したものである。

【００９６】図48は、それぞれの情報の優先度を求める
為の、優先度取得処理の流れの一例を示したものであ
る。

【００９７】操作部11により実現される操作手順（Ｕ
Ｉ）は、情報処理装置自身が元々持っている操作情報12
を、操作対象となる情報それぞれの優先度に応じて、決
定・更新された結果を用いて処理されている。

【００９８】図13に示した情報処理装置には、情報処理
装置が参照可能なユーザの To Do List 等のタスク132
と、人の地位や役職などの一般常識による優先度を定義
した情報137とが存在する。

【００９９】ユーザの To Do List等のタスク132に記憶
されているそれぞれのタスクには、期限、内容、関係
者、優先度があり、図には記載されていないが、それぞ
れのタスクに関係するスケジュールなどの情報が含まれ
ている。また、優先度はユーザが指定することも可能で
あり、値が少ないほど優先度が高いものとして管理して
いる。また、人の地位や役職などの一般常識による優先
度を定義した情報137には、人の地位や役職などとそれ
ぞれの優先度が定義されている。

【０１００】図13の場合、タスク134及び135は、現在の
日付133と比較すると同じ緊急度であり、ユーザが設定
した優先度も同じ 3ではあるが、それぞれのタスクに関
係している人が異なっている。そこで、一般常識である
人の地位や役職による優先度情報137を参照した結果、
同僚139より社長138の方が優先度が高いので、表示画面
131では、社長が関係するタスク135の「reserve Train
for President」を、より強調して表示している。

【０１０１】一方、タスク136は、ユーザが設定した優
先度が 5であり、他のタスクと比較して相対的に優先度
が低かっただけでなく、緊急性も低いので、表示画面13
1では、表示すらしていない。

【０１０２】以上のように、本実施形態によれば、表示
対象となるタスク情報のそれぞれの優先度に応じて、強
調表示などの最適な表示形態を実現することが可能であ
る。

【０１０３】なお、処理の流れの詳細な説明について
は、上記処理を実現する為の、優先度・項目数対応処理
の流れの一例を示すフローチャートである図46や、それ
ぞれの情報の優先度を求める為の、優先度取得処理の流
れの一例を示すフローチャートである図48等を用いて後
述する。

【０１０４】（実施形態 8）図14は、タスクとの関係度
に応じて、出力態様を決定・更新する情報処理装置の一
例を表す図である。

【０１０５】操作部11により実現される操作手順（Ｕ
Ｉ）は、情報処理装置自身が元々持っている操作情報12
を、操作対象となる情報それぞれの優先度に応じて、決
定・更新された結果を用いて処理されている。

【０１０６】図14に示した情報処理装置には、情報処理
装置が参照可能なユーザの To Do List 等のタスク142
が存在する。ユーザの To Do List等のタスク142に記憶
されているそれぞれのタスクには、期限、内容、関係
者、優先度があり、図には記載されていないが、それぞ
れのタスクに関係するスケジュールなどの情報が含まれ
ている。また、優先度はユーザが指定することも可能で
あり、値が少ないほど優先度が高いものとして管理して
いる。

【０１０７】このようなタスク142を持っている状態
で、JohnからのＦＡＸ147、KeikoからのEmail 148、Tan
akaからの電話149を受信した場合、それぞれの受信情報
についてユーザとの関係度を考慮して、より関係の深い
情報を強調して表示141する。

【０１０８】図14の例の場合、受信した３つの情報の送
信元であるJohn、Keiko、Tanakaのうち、Johnだけがタ
スク142に記憶されているタスク144の関係者Johnと一致
している。よって、この例の場合、タスク144の「reser
ve Hotel for John」と関係する情報が受信された可能
性があると推測し、ホテルの予約を変更する必要がある
かもしれないと判断し、表示画面147では、Johnから受
信したＦＡＸ147の存在をより強調して表示している。

【０１０９】なお、ユーザに対する関係度は、上記のよ
うなタスク情報だけでなく、スケジュール情報や、履歴
など各種情報を参照して求められる。

【０１１０】以上のように、本実施形態によれば、表示
対象となる受信情報とタスクとの関係度に応じて、強調
表示などの最適な表示形態を実現することが可能であ
る。

【０１１１】なお、処理の流れの詳細な説明について
は、上記処理を実現する為の、優先度・項目数対応処理
の流れの一例を示すフローチャートである図46や、それ
ぞれの情報の優先度を求める為の、優先度取得処理の流
れの一例を示すフローチャートである図48等を用いて後
述する。

【０１１２】（実施形態 9）図15は、緊急度に応じて、
出力態様を決定・更新する情報処理装置の一例を表す図
である。

【０１１３】操作部11により実現される操作手順（Ｕ
Ｉ）は、情報処理装置自身が元々持っている操作情報12
を、操作対象となる情報それぞれの優先度に応じて、決
定・更新された結果を用いて処理されている。

【０１１４】図15に示した情報処理装置には、情報処理
装置が参照可能なユーザのスケジュール151が存在す
る。

【０１１５】ユーザのスケジュール151に記憶されてい
るそれぞれの予定には、開始終了時刻、内容、場所、優
先度、それぞれの予定に関係する出席者や、主催者など
の情報が含まれている。また、優先度はユーザが指定す
ることも可能であり、値が少ないほど優先度が高いもの
として管理している。

【０１１６】図15の場合、同じ15:00からの予定の表示
が、時刻に対応した緊急度に応じてどのように変化する
かを示している。

【０１１７】152のように、予定時刻まで余裕があり、
しかも極端に先の予定ではない場合、通常のレベルで
「You have meeting at 15:00」と、ユーザに通知して
いる。一方、153のように、予定時刻直前には、強調し
て「You have meeting soon!」と通知している。

【０１１８】更に、154のように、予定時刻ちょうどに
は、最大限の強調レベルで「NOW! Meeting!!」と通知
し、155のように、それでもユーザがまだ会議に出席し
ていない時には、会議が終了するまで「PAST! Meeting!
!」と通知する。その後、156のように、ユーザに予定さ
れていた会議があったことを、「You had meeting toda
y」と通知し、必要ならば後日の調整をすべきことを知
らせる。

【０１１９】以上のように、本実施形態によれば、時刻
に応じた緊急度に対応して、表示対象となるスケジュー
ル情報の強調表示などの度合いを変更することが可能で
ある。

【０１２０】なお、処理の流れの詳細な説明について
は、上記処理を実現する為の、優先度・項目数対応処理
の流れの一例を示すフローチャートである図46や、それ
ぞれの情報の優先度を求める為の、優先度取得処理の流
れの一例を示すフローチャートである図48、それぞれの
情報の優先度に応じて、強調表示する為の方法を定義し
た情報の一例を示す図51等を用いて後述する。

【０１２１】（実施形態 10）図16は、処理対象の情報
量に応じて、出力態様を決定・更新する情報処理装置の
一例を表す図である。

【０１２２】操作部11により実現される操作手順（Ｕ
Ｉ）は、情報処理装置自身が元々持っている操作情報12
を、操作対象となる情報量に応じて、決定・更新された
結果を用いて処理されている。

【０１２３】図16に示した情報処理装置では、表示しよ
うとしている情報の項目数が多い時には、161のよう
に、１項目当たりに表示する情報量を少なくして表示
し、項目数が少ない時には、162のように、１項目当た
りに表示する情報量を増やして表示し、表示画面の大き
さ又はユーザが認識可能な表示領域の大きさと比較し
て、項目数が十分少ない時には、163のように、項目の
内容そのものを表示する。

【０１２４】以上のように、本実施形態によれば、処理
対象となる情報量に応じて、最適な操作手順を実現する
ことが可能である。

【０１２５】なお、処理の流れの詳細な説明について
は、上記処理を実現する為の、優先度・項目数対応処理
の流れの一例を示すフローチャートである図46等を用い
て後述する。

【０１２６】（実施形態 11）図17は、処理対象の情報
量に応じて、処理方法を決定・更新する情報処理装置の
一例を表す図である。

【０１２７】処理実行部17の検索処理では、図17に示し
たような操作画面1701を用いてユーザが指示した内容に
従って、情報の検索を行う。

【０１２８】ユーザは、図17の1702に示すキーワードリ
ストから、検索に用いられるキーワードを複数指定する
ことができる。もちろん、それぞれのキーワードはユー
ザが１つ１つ入力しても良いし、あらかじめ指定した文
書から自動的に抽出させるようにしてもよい。

【０１２９】また、それぞれのキーワードは優先度を持
っている。もちろん、それぞれのキーワードの優先度は
ユーザが１つ１つ入力しても良いし、あらかじめ指定し
た文書から自動的に抽出する時に、出現頻度や出現個所
の前後関係から優先度が決定されるようにしてもよい。

【０１３０】このようにして、キーワードを指定した
後、検索範囲1703を指定して、ユーザの検索開始1704の
指示に従って、検索処理を実行する。そこで、図52に示
す検索対象数対応処理では、検索対象件数に応じて、検
索に用いるキーワードの数を増減させ、決定された検索
キーワード数に応じて、リスト1702の優先度上位のキー
ワードを用いて、検索を実行する。

【０１３１】例えば、ユーザが検索範囲1703の指定で、
ローカルＰＣを指定した場合、1708のように検索対象件
数を100件以上と判断して、検索キーワードの100%用い
て検索を実行する。

【０１３２】一方、検索範囲1703の指定で、ドメイン内
全ＰＣを指定した場合、1709のように検索対象件数を10
000件以上と判断して、検索キーワードの10%用いて検索
を実行する。

【０１３３】一方、全世界を指定した場合、1710のよう
に検索対象件数を1,000,000件以上と判断して、検索キ
ーワードの1%用いて検索を実行する。

【０１３４】以上のように、本実施形態によれば、検索
対象数に応じて、検索に用いる情報を増減させること
で、最適な検索を実現することが可能である。

【０１３５】なお、処理の流れの詳細な説明について
は、上記処理を実現する為の、検索対象数対応処理の流
れの一例を示したフローチャートである図52等を用いて
後述する。

【０１３６】（実施形態 12）次に、情報処理装置1の操
作部11の処理について説明する。

【０１３７】図38は、操作部11の処理の流れを表すフロ
ーチャートである。図39は、操作部11により表示される
操作画面の一例を表す図である。図40は、操作部11で音
声により指示をした場合の一例を表す図である。

【０１３８】情報処理装置1の操作部11では、ユーザの
操作に対応して、操作部11内部の処理だけで完結する操
作と、タスク受信部13を介して処理を行わなければなら
ない操作を切り分けて、処理を行っている。

【０１３９】例えば、図39の操作画面393の入力ボック
ス394への文字列の入力・削除などの操作に対応した、
表示文字列の変更や操作部11内変数の更新などの処理
は、操作部11内部の処理だけで完結する。一方、印刷指
示ボタン395が押された後の実際の印刷処理は、操作部1
1の内部では処理できない為、タスク受信部13を介して
外部で処理を行うようにしている。

【０１４０】以降、操作部11の処理の流れについて説明
する。

【０１４１】操作部11が起動されると、ステップS3801
において、操作情報12で定義されている情報を参照し
て、表示される操作画面の内容も含めた操作手順を決定
する。

【０１４２】続くステップS3802で、文字列の入力など
実際にユーザが操作を行ったかどうかをチェックし、操
作が行われていなければ、操作が行われるまでステップ
S3802を繰り返す。

【０１４３】次のステップS3803では、ユーザが行った
操作内容を解析し、続くステップS3804で操作部11内部
の処理だけで完結すると判断された場合にはステップS3
805に進み、操作部11外部の処理が必要と判断された場
合にはステップS3813に進む。

【０１４４】ステップS3805では、ユーザが行った操作
の内容が図39の397に示すような履歴条件の指定操作の
実行を指示しているかどうか判断し、実行を指示されて
いると判断された場合にはステップS3808に進み、それ
以外の場合にはステップS3806に進む。

【０１４５】ステップS3806では、履歴条件の指定操作
の実行の指示以外のユーザが行った操作に対応した処理
を実行し、表示文字列の変更や操作部11内変数の更新な
どを行い、続くステップS3807で操作部11内履歴情報に
操作の情報等を追加する。この操作部11内履歴情報を利
用することで、ユーザが行った操作を取り消したり(UND
O)、繰り返したり(REDO)することが可能になる。その
後、再びステップS3802に戻り、ユーザの操作を受け付
ける。

【０１４６】ここで、ステップS3805で、履歴条件の指
定操作の実行が指示されていると判断された場合には、
ステップS3808に進み、履歴条件指定操作部が実行され
る。履歴条件指定操作部が起動されると、ステップS380
8で、文字列の入力など実際にユーザが操作を行ったか
どうかをチェックし、操作が行われていなければ、操作
が行われるまでステップS3808を繰り返す。

【０１４７】次のステップS3809では、ユーザが行った
操作内容を解析し、続くステップS3810で、履歴条件指
定操作部の内部の処理だけで完結すると判断された場合
にはステップS3811に進み、履歴条件指定操作部外部の
処理が必要と判断された場合にはステップS3807に進
む。

【０１４８】ステップS3811では、ユーザが行った操作
に対応した処理を実行し、表示文字列の変更や履歴条件
指定操作部内変数の更新などを行い、続くステップS381
2で履歴条件指定操作部内履歴情報に操作の情報を追加
する。この履歴条件指定操作部内履歴情報を利用するこ
とで、ユーザが行った操作を取り消したり(UNDO)、繰り
返したり(REDO)することが可能になる。その後、再びス
テップS3808に戻り、ユーザの操作を受け付ける。

【０１４９】一方、ステップS3804で、操作部11外部の
処理が必要と判断された場合にはステップS3813に進
み、前述の履歴条件指定操作部等により、あるいはユー
ザの標準的な設定等により、履歴情報を残すように指定
されているかどうか判断する。

【０１５０】その結果、履歴を残すと判断された場合に
はステップS3814に進み、履歴情報管理部18を介して履
歴情報19に操作内容を追加し、そこで取得された履歴番
号を返して、終了する。なお、上記履歴情報19に追加し
た操作内容は、今後実行される処理のきっかけとなるも
のなので、一連の履歴情報の先頭であることを明示して
追加される。

【０１５１】また、実際に履歴情報を追加した場合に
は、履歴情報管理部18から追加された履歴番号が返され
るので、その値を操作部11外部に返すが、履歴を残す必
要が無い場合には履歴を残す必要が無いという意味で、
履歴番号として無効値を返して終了する。

【０１５２】次に、図39を用いて、操作部11の具体的な
処理の流れについて詳細に説明する。

【０１５３】操作部11が起動されると、ステップS3801
において操作情報12で定義されている情報を参照して、
操作手順を決定した結果、図39の393に示すような操作
画面を表示される。

【０１５４】ここで、ユーザが操作画面393の指示に従
って、格納場所を指定する入力ボックス394に文字列「F
iling Server 392」を入力すると、ステップS3802で文
字列が入力されたことを検出し、ステップS3803でユー
ザが行った操作内容を解析する。

【０１５５】その結果、ステップS3804で操作部11内部
の処理だけで完結すると判断され、ステップS3805で履
歴条件の指定操作の実行を指示していないと判断され
る。そこで、ステップS3806で、ユーザの行った文字列
の入力に対応して操作画面の表示を変更し、操作部11内
変数を更新し、続くステップS3807で、操作部11内履歴
情報に文字列を入力したという情報を追加する。この操
作部11内履歴情報を利用することで、ユーザが入力ミス
などに気づいた場合、簡単に修正することができる。

【０１５６】一方、ユーザが履歴条件の指定操作の実行
を指示するためのボタン397を押すと、履歴条件指定操
作画面398が表示される。ここで、履歴条件指定操作画
面398の指示に従って、項目〔履歴を残す〕のチェック
マークをチェックする（白丸を黒丸に変更する）よう操
作を行うと、ステップS3808で何らかの操作がされたこ
とを検出し、ステップS3809でユーザが行った操作内容
を解析する。

【０１５７】その結果、ステップS3810で履歴条件指定
操作部内部の処理だけで完結すると判断され、ステップ
S3811で、ユーザの行った操作に対応して履歴条件指定
操作画面398の表示を変更し、履歴を残すように指定を
変更し、続くステップS3812で履歴条件指定操作部内履
歴情報に指定を変更したという情報を追加する。この履
歴条件指定操作部内履歴情報を利用することで、ユーザ
が操作ミスなどに気づいた場合、簡単に修正することが
できる。

【０１５８】上述した操作により、必要な条件の指定を
すべて行った後、ユーザがこれら指定を有効にすること
を指示するためのボタン399を押すと、ステップS3810で
履歴条件指定操作部内部の処理だけでは完結しないと判
断され、設定内容を有効にした上で、ステップS3807に
進む。

【０１５９】更に、操作部11においても、必要な処理実
行の指定をすべて行った後、ユーザがこれら処理の実行
を促す為のボタン395を押すと、ステップS3804で操作部
11内部の処理だけでは完結しないと判断され、ステップ
S3813に進み、履歴情報を残すように指定されているこ
とが判断される。

【０１６０】その結果、ステップS3814に進み、履歴情
報管理部18を介して、一連の履歴情報の先頭であること
を明示して履歴情報19に操作内容を追加し、そこで取得
された履歴番号を返して、終了する。

【０１６１】なお、キャンセルを指定するボタンが押さ
れた場合には、それまでの操作が無効になるだけであ
る。よって、説明が複雑になるのを避ける為に、上記の
説明及び図では詳細な説明を省略している。

【０１６２】次に、図40を用いて、音声により指示をし
た場合の操作部11の具体的な処理の流れについて詳細に
説明する。

【０１６３】ユーザが情報処理装置1の１実施形態であ
るプリンタ401に、音声で「Print "abc.doc" from Fili
ng Server402」と指示すると、ステップS3802で音声が
入力されたことを検出し、ステップS3803でユーザが行
った操作内容を解析する。

【０１６４】その結果、例えば操作部11では音声の入力
を理解することができないとすると、ステップS3804
で、操作部11内部の処理だけで完結しないと判断され、
ステップS3813に進み、履歴情報を残すように指定され
ているか判断される。

【０１６５】例えば、この時点の標準設定で履歴を残す
ように設定してあったとすると、ステップS3814に進
み、履歴情報管理部18を介して、一連の履歴情報の先頭
であることを明示して履歴情報19に操作内容を追加し、
そこで取得された履歴番号を返して、終了する。

【０１６６】（実施形態 13）次に、情報処理装置1のタ
スク受信部1の処理について説明する。

【０１６７】図41は、タスク受信部13の処理の流れを表
すフローチャートである。

【０１６８】情報処理装置1のタスク受信部13では、操
作部11で取得されたユーザの操作内容及びその履歴番号
や、情報処理装置1とネットワーク等で接続された情報
処理装置2からの指示やデータや情報などの受信情報
や、情報処理装置1自ら検知した外部の状況の情報や、
情報処理装置1自らの入力部から入力された文書などの
情報等、情報処理装置1が関連するあらゆる情報が、受
信タスクとして扱われる。

【０１６９】タスク受信部13では、これら受信タスクに
対応して、タスク受信部13内部の処理だけで完結する受
信タスクと、タスクテーブル14にタスクを追加して、タ
スク受信部13外部で処理を行わなければならない受信タ
スクを切り分けて、処理を行っている。

【０１７０】例えば、情報処理装置1とネットワーク等
で接続された情報処理装置2とのTCP/IPやHTTPなどの基
本となる通信にともなう受信タスクに対応した、プロト
コルに従った単純なやり取りなどの処理は、タスク受信
部13内部の処理だけで完結する。一方、操作部11で取得
されたユーザの操作内容及びその履歴番号や、情報処理
装置1とネットワーク等で接続された情報処理装置2から
の何らかの処理実行の指示等はタスク受信部13内部では
処理できない為、タスクテーブル14にタスクを追加し
て、タスク受信部13の外部で処理を行うようにしてい
る。

【０１７１】以降、タスク受信部13の具体的な処理の流
れについて説明する。

【０１７２】タスク受信部11が起動されると、ステップ
S411で、タスクが受信されたかどうかチェックし、受信
されていなければ、タスクが受信されるまでステップS4
11を繰り返す。

【０１７３】次のステップS412では、受信タスクの内容
を解析し、続くステップS413では、タスク受信部13内部
の処理だけで完結するか否かを判断し、完結すると判断
された場合には、ステップS414に進み、タスク受信部13
外部の処理が必要と判断された場合にはステップS416に
進む。

【０１７４】ステップS414では、受信タスクに対応した
処理を実行し、プロトコルに従った単純なやり取りなど
の処理を行い、続くステップS415でタスク受信部13内履
歴情報に受信タスクの情報等を追加する。このタスク受
信部13内履歴情報を利用することで、ノイズ等による通
信手続きの混乱を回避する等の為に、取り消したり(UND
O)、繰り返したり(REDO)することが可能になる。

【０１７５】その後、再びステップS411に戻り、受信タ
スクを受け付ける。

【０１７６】一方、ステップS413でタスク受信部13外部
の処理が必要と判断された場合にはステップS416に進
み、前述の操作部11の履歴条件指定操作部等により、あ
るいはユーザの標準的な設定等により、あるいは受信タ
スク自体の設定などにより、履歴情報を残すように指定
されているかどうか判断する。

【０１７７】その結果、履歴を残すと判断された場合に
はステップS417に進み、上記受信タスクが操作部11から
受信したものか判断する。その結果、操作部11から受信
したものである場合には、既に操作部11で履歴情報19に
追加されているので、履歴情報19に追加せずにステップ
S419に進む。

【０１７８】上記受信タスクを操作部11以外から受信し
た場合には、ステップS418に進み、履歴情報管理部18を
介して、履歴情報19に受信タスクの内容を追加し、履歴
番号を取得する。なお、上記履歴情報19に追加した受信
タスクの内容は、今後実行される処理のきっかけとなる
ものなので、一連の履歴情報の先頭であることを明示し
て追加される。

【０１７９】続くステップS419では、操作部11から渡さ
れた履歴番号、又はステップS418で履歴情報を追加した
場合には履歴情報管理部18から返された履歴番号を、タ
スクの元履歴番号にセットして、タスクテーブル14に追
加する。一方、ステップS416で履歴を残す必要が無いと
判断された場合には、履歴を残す必要が無いという意味
で、タスクの元履歴番号として無効値をセットして、タ
スクテーブル14に追加する。

【０１８０】（実施形態 14）次に、情報処理装置1の処
理実行部17の処理について説明する。

【０１８１】図42は、処理実行部17の処理の流れを表す
フローチャートである。

【０１８２】情報処理装置1の処理実行部17では、実行
される処理内容に対応して、処理実行部17内部の処理だ
けで完結する処理と、タスクテーブル14に新たなタスク
を追加して、処理実行部17外部で処理を行わなければな
らない処理を切り分けて、処理を行っている。

【０１８３】以降、処理実行部17の具体的な処理の流れ
について説明する。

【０１８４】処理実行部17が起動されると、ステップS4
21で処理内容を解析し、続くステップS422で、処理実行
部17内部の処理だけで完結すると判断された場合にはス
テップS423に進み、処理実行部17外部の処理が必要と判
断された場合にはステップS425に進む。

【０１８５】ステップS423では、処理内容に対応した処
理を実行し、続くステップS424で処理実行部17内履歴情
報に処理内容の情報等を追加する。この処理実行部17内
履歴情報を利用することで、取り消したり(UNDO)、繰り
返したり(REDO)することが可能になる。その後、再びス
テップS421に戻り、残る処理を続行する。

【０１８６】一方、ステップS422で処理実行部17外部の
処理が必要と判断された場合にはステップS425に進み、
実行された処理に対応するタスクに指定された元履歴番
号が、履歴を残すことを意味する有効な元履歴番号かど
うかチェックし、履歴を残すかどうか判断する。

【０１８７】その結果、履歴を残すと判断された場合に
はステップS426に進み、履歴情報管理部18を介して、履
歴情報19に処理内容を追加し、履歴番号を取得する。

【０１８８】続くステップS427では、ステップS426で履
歴情報を追加した場合には、履歴情報管理部18から返さ
れた履歴番号をタスクの元履歴番号にセットして、タス
クテーブル14に追加する。一方、ステップS425で履歴を
残す必要が無いと判断された場合には、履歴を残す必要
が無いという意味で、タスクの元履歴番号として無効値
をセットして、タスクテーブル14に追加する。

【０１８９】（実施形態 15）次に、通信状況対応処理
の流れを説明する。

【０１９０】図43は、処理部17の通信状況対応処理の流
れを表すフローチャートである。

【０１９１】図44は、処理部17の通信状況対応処理、又
は定型処理外命令対応処理により、受信され、更新され
る操作情報12の一例を表す図である。図44に示したよう
に、操作情報12には、操作部11で実行される処理の種類
と、それぞれの処理で参照される情報の内容が含まれて
いる。

【０１９２】図8は、処理部17の通信状況対応処理が起
動されるような操作をユーザが行い、その結果、対応す
る操作情報12を受信し、操作画面を変化させている一例
を表す図である。

【０１９３】操作部11により実現される操作手順（Ｕ
Ｉ）は、情報処理装置1の１実施形態であるリモコン801
自身が元々持っている操作情報12を参照して実行される
場合と、ネットワーク等で接続されている他の情報処理
装置2の１実施形態である複写機804、又はサーバ802の
制御下にある通信施設806から取得された操作情報12を
参照して実行される場合がある。

【０１９４】図8のリモコン801の操作画面のように、操
作開始時にはリモコン801自身が持っている操作情報12
を参照して、「操作したい機械に向けて下さい」という
メッセージを表示している。

【０１９５】その指示に従って、ユーザがリモコン801
を複写機804に向けると、操作部11でその操作を受け付
け、タスク受信部13により通信状況対応処理タスクとし
てタスクテーブル14に追加される。その後、タスク解析
部15及びプランニング決定部16を介して、処理部17によ
り図43で示した通信状況対応処理が起動される。

【０１９６】通信状況対応処理が起動されると、まずス
テップS4301で操作対象機器に操作情報送信要求を発信
する。続くステップS4302で、要求に対して操作情報が
受信できたか否かを判断し、受信できた場合にはステッ
プS4305に進み、受信できなかった場合にはステップS43
03に進む。

【０１９７】ステップS4303では、操作対象機器の代り
に、サーバ機器に操作情報送信要求を発信し、次のステ
ップS4304で、操作情報の受信に成功した場合にはステ
ップS4305に進み、失敗した場合にはステップS4306でエ
ラーメッセージを表示した後、終了する。

【０１９８】ステップS4305では、受信した操作情報を
元に、リモコン801自身が持つ操作情報12を更新し、保
存して、終了する。その結果、図8の809又は810のよう
に、通信状況に対応した操作画面の表示が可能になる。

【０１９９】以降、図8及び図44を用いて詳細に説明す
る。

【０２００】まず、リモコン801が、複写機804と正常に
通信できた場合、下記のように処理が実行される。

【０２０１】通信状況対応処理が起動されると、まずス
テップS4301で複写機804に操作情報送信要求を発信す
る。その結果、ステップS4302で図44の(a)に示すよう
な、操作情報807を受信できたので、ステップS4305に進
む。図に示したように、操作情報807には、操作部11で
実行される処理の種類として、初期表示及び枚数指定操
作対応処理の指定と、それぞれの処理で参照される「複
写したい枚数を決めて下さい」等の複写機804の操作に
必要な情報の内容が含まれている。

【０２０２】ステップS4305では、受信した操作情報807
を元に、リモコン801自身が持つ操作情報12を更新し、
保存して、終了する。その結果、図8の809のように、複
写機804に対応した操作画面809の表示が可能になる。

【０２０３】一方、リモコン801が、複写機804と正常に
通信できなかった場合、以下のように処理が実行され
る。

【０２０４】通信状況対応処理が起動されると、まずス
テップS4301で複写機804に操作情報送信要求を発信す
る。その結果、ステップS4302で操作情報を受信できな
かったので、ステップS4303に進む。

【０２０５】ステップS4303では、サーバ802の制御下に
ある通信施設806に操作情報送信要求を発信する。その
結果、ステップS4304で図44の(b)に示すような、操作情
報808を受信できたので、ステップS4305に進む。図44の
(b)に示したように、操作情報808には、操作部11で実行
される処理の種類として、初期表示及び機能指定操作対
応処理の指定と、それぞれの処理で参照される「行いた
い機能を選んで下さい」等のサーバ802の操作に必要な
情報の内容が含まれている。

【０２０６】ステップS4305では、受信した操作情報808
を元に、リモコン801自身が持つ、操作情報12を更新
し、保存して、終了する。その結果、図8に示すよう
に、サーバ802に対応した操作画面810の表示が可能にな
る。

【０２０７】（実施形態 16）次に、定型処理外命令対
応処理の流れを説明する。

【０２０８】図45は、処理部17の定型処理外命令対応処
理の流れを表すフローチャートである。

【０２０９】図9は、処理部17の定型処理外命令処理が
起動されるような操作をユーザが行い、その結果、対応
する操作情報12を受信し、操作画面を変化させている一
例を表す図である。

【０２１０】操作部11により実現される操作手順（Ｕ
Ｉ）は、情報処理装置1の１実施形態である複写機901自
身が元々持っている操作情報12を参照して実行される場
合と、ネットワーク等で接続されている他の情報処理装
置2の１実施形態であるサーバ902から取得された操作情
報12を参照して実行される場合がある。

【０２１１】図9の複写機901の操作画面905のように、
操作開始時には複写機901自身が持っている操作情報12
を参照して、「複写したい枚数を決めて下さい」という
メッセージを表示している。

【０２１２】そこで、ユーザが複写機901に対して何ら
かの操作を行うと、操作部11でその操作を受け付け、タ
スク受信部13により定型処理外命令対応処理タスクとし
てタスクテーブル14に追加される。その後、タスク解析
部15及びプランニング決定部16を介して、処理部17によ
り、図45のフローチャートに手順を示す定型処理以外命
令対応処理が起動される。

【０２１３】定型処理外命令対応処理が起動されると、
まずステップS4501でユーザが指示した処理を自ら行う
べき処理かどうかが判断される。その結果、自ら行うべ
き処理でなければ、ステップS4502に進み、自ら行うべ
き処理ならばステップS4506に進み、対応する処理を実
行して終了する。

【０２１４】ステップS4502では、上記処理に対応する
操作情報を取得する為に、サーバ機器に操作情報送信要
求を発信し、次のステップS4503で操作情報の受信に成
功した場合にはステップS4504に進み、失敗した場合に
はステップS4505でエラーメッセージを表示した後、終
了する。

【０２１５】ステップS4504では、受信した操作情報を
元に、複写機901自身が持つ、操作情報12を更新し、保
存して、終了する。

【０２１６】その結果、図9の906のように、定型処理以
外の命令に対応した操作画面の表示が可能になる。

【０２１７】以降、図9及び図45を用いて詳細に説明す
る。

【０２１８】ユーザが、複写機901で、本来処理可能な
複写を指示した場合、下記のように処理が実行される。

【０２１９】定型処理外命令対応処理が起動されると、
まずステップS4501でユーザが指示した複写処理は、自
ら行うべき処理だと判断される。そこで、ステップS450
6に進み、複写処理を実行して終了する。

【０２２０】ユーザが、複写機901で、本来処理不可能
な送信を指示した場合、下記のように処理が実行され
る。定型処理外命令対応処理が起動されると、まずステ
ップS4501でユーザが指示した送信処理は自ら行うべき
処理ではないと判断される。そこで、ステップS4502に
進み、送信処理に対応する操作情報を取得する為に、サ
ーバ機器902に操作情報送信要求を発信する。その結
果、次のステップS4503で操作情報909の受信に成功し、
ステップS4504で、受信した操作情報を元に、複写機901
自身が持つ操作情報12を更新し、保存して、終了する。

【０２２１】その結果、図9の906のように、送信処理の
命令に対応した操作画面906の表示が可能になる。

【０２２２】（実施形態 17）次に、優先度・項目数対
応処理の流れを説明する。

【０２２３】図46は、処理部17の優先度・項目数対応処
理の流れを表すフローチャートである。

【０２２４】図47は、処理部17の優先度・項目数対応処
理の、処理対象項目の一例を表した図である。それぞれ
の処理対象項目には、処理対象の種類、内容、優先度な
どが含まれている。

【０２２５】図51は、処理部17の優先度・項目数対応処
理の、それぞれの処理項目の優先度に対応した、強調表
示方法の定義の一例を表した図である。図51に示した強
調表示方法定義では、処理対象となるスケジュール、タ
スク、到着情報それぞれの優先度に対応して、どのよう
な表示方法を取るべきかについて定義されている。

【０２２６】図10は、処理部17の優先度・項目数対応処
理による、スケジュール、タスク、到着情報の表示結果
と、それぞれの表示を行った理由の一例を表した図であ
る。

【０２２７】操作部11により実現される操作手順（Ｕ
Ｉ）は、情報処理装置1自身が元々持っている操作情報1
2を参照して実行される場合と、処理対象となる情報の
優先度を考慮して更新された操作情報12を参照して実行
される場合がある。

【０２２８】図10では明示的に表していないが、ユーザ
の指示や、情報処理装置1自らがプランニングした結果
にしたがって、優先度・項目数対応処理が起動される。

【０２２９】優先度・項目数対応処理が起動されると、
まずステップS4601でユーザのスケジュール、To Do Lis
t等のタスク、Ｅｍａｉｌ、ＦＡＸ、電話などの受信・
到着情報が、図47の(a)のように処理対象項目に格納さ
れる。

【０２３０】その結果、ステップS4602で、処理対象項
目に情報が存在するかどうかチェックされ、存在する場
合ステップS4603に進み、存在しない場合終了する。ス
テップS4603では、後述する優先度取得処理により、処
理対象項目に格納されているすべての処理対象につい
て、優先度を取得する。その結果、求められた値が、図
47の(b)で表されている。

【０２３１】次のステップS4604で、処理対象項目数が
１かどうかチェックし、１つしかない場合、ステップS4
605に進み、項目の内容を表示した後、終了する。

【０２３２】一方、処理対象項目が２つ以上存在する場
合には、ステップS4606に進み、表示画面の大きさ又は
ユーザが認識可能な表示領域の大きさと、表示しようと
している処理対象項目数を比較し、１項目当りの最適な
表示領域の大きさを決定する。

【０２３３】続くステップS4607では、上記で決定され
た１項目当りの表示領域に納まる範囲での、最大限の情
報を、図51の定義を参照してそれぞれの処理対象の優先
度に合わせて表示する。その際、表示領域に対して項目
数が十分少ない場合には、それぞれの処理対象の情報の
内容そのものを表示する。

【０２３４】以降、図10、図47及び図51を用いて詳細に
説明する。

【０２３５】まず、処理対象がスケジュールの場合につ
いて、説明する。

【０２３６】優先度・項目数対応処理が起動されると、
まずステップS4601でユーザのスケジュールが、図47の
(a)のように処理対象項目に格納される。その結果、ス
テップS4602で、処理対象項目に情報が存在するので、
ステップS4603で、後述する優先度取得処理により、処
理対象項目に格納されているすべての処理対象につい
て、図47の(b)のように優先度を取得する。

【０２３７】次のステップS4604で、処理対象項目数が
２つ以上存在すると判断し、ステップS4606に進み、表
示画面の大きさ又はユーザが認識可能な表示領域の大き
さと、表示しようとしている処理対象項目数を比較し、
１項目当りの最適な表示領域の大きさを決定する。続く
ステップS4607で、上記で決定された１項目当りの表示
領域に納まる範囲での、最大限の情報を、図51の定義を
参照してそれぞれの処理対象の優先度に合わせて表示す
る。

【０２３８】例えば、図47の処理対象項目4713のスケジ
ュールは、図11のスケジュール115の「ABC Meeting」を
示し、優先度＝12であり、図51の定義を参照した結果、
表示色＝赤で２０ポイントで表示するように定義されて
いる。

【０２３９】一方、処理対象項目4714のスケジュール
は、図11のスケジュール116の「XYZ Meeting」を示し、
優先度＝13であり、図51の定義を参照した結果、表示色
＝黒で１６ポイントで表示するように定義されている。

【０２４０】また、処理対象項目4715のスケジュール
は、図11のスケジュール117の「Dinner」を示し、優先
度＝15であり、図51の定義を参照した結果、非表示と定
義されている。

【０２４１】上記のように、それぞれの処理対象項目に
ついて、表示方法を決定し、実行した結果表示されたも
のが、図10の101に示されている。

【０２４２】次に、処理対象が To Do List等のタスク
の場合について、説明する。

【０２４３】優先度・項目数対応処理が起動されると、
まずステップS4601でユーザのタスクが、図47の(a)のよ
うに処理対象項目に格納され、前述のスケジュールと同
様に処理される。

【０２４４】例えば、図47の処理対象項目4717のタスク
は、図13のタスク134の「reserve Hotel」を示し、優先
度＝17であり、図51の定義を参照した結果、表示色＝黒
で１４ポイントで表示するように定義されている。

【０２４５】一方、処理対象項目4718のタスクは、図13
のタスク135の「reserve Train」を示し、優先度＝12で
あり、図51の定義を参照した結果、表示色＝赤で２０ポ
イントで表示するように定義されている。

【０２４６】また、処理対象項目4719のタスクは、図13
のタスク136の「check Progress」を示し、優先度＝20
であり、図51の定義を参照した結果、非表示と定義され
ている。

【０２４７】上記のように、それぞれの処理対象項目に
ついて、表示方法を決定し、実行した結果表示されたも
のが、図10の102で示されている。

【０２４８】次に、処理対象が Ｅｍａｉｌ、ＦＡＸ、
電話などの受信・到着情報の場合について、説明する。

【０２４９】優先度・項目数対応処理が起動されると、
まずステップS4601で受信・到着情報が、図47の(a)のよ
うに処理対象項目に格納され、前述のスケジュールと同
様に処理される。

【０２５０】例えば、図47の処理対象項目4720の到着情
報は、図14のＦＡＸ147の「ＦＡＸfrom John」を示し、
優先度＝12であり、図51の定義を参照した結果、表示色
＝赤で２０ポイントで表示するように定義されている。

【０２５１】一方、処理対象項目4721の到着情報は、図
14のＥｍａｉｌ148の「Email fromKeiko」を示し、優先
度＝15であり、図51の定義を参照した結果、表示色＝黒
で１６ポイントで表示するように定義されている。

【０２５２】また、処理対象項目4722の到着情報は、図
14の電話149の「電話 from Tanaka」を示し、優先度＝1
5であり、図51の定義を参照した結果、表示色＝黒で１
６ポイントで表示するように定義されている。

【０２５３】上記のように、それぞれの処理対象項目に
ついて、表示方法を決定し、実行した結果表示されたも
のが、図10の表示画面103に示されている。

【０２５４】（実施形態 18）図15は、処理部17の優先
度・項目数対応処理によって、同じスケジュールの表示
形態が、時間によってどのように変化していくかの一例
を表した図である。

【０２５５】以降、図15を用いて詳細に説明する。

【０２５６】優先度・項目数対応処理が起動されると、
まずステップS4601でユーザのスケジュールが、図47の
(a)のように処理対象項目に格納される。その結果、ス
テップS4602で、処理対象項目に情報が存在するので、
ステップS4603で、後述する優先度取得処理により、処
理対象項目に格納されているすべての処理対象につい
て、図47の(b)のように優先度を取得する。

【０２５７】図15ではわかりやすくする為に、１つのス
ケジュールしかユーザに通知していないが、次のステッ
プS4604で、処理対象項目数が２つ以上存在すると判断
し、ステップS4606に進み、ユーザが認識可能な通知時
間の長さと、通知しようとしている処理対象項目数を比
較し、１項目当りの最適な通知時間の長さを決定する。
続くステップS4607で、上記で決定された１項目当りの
通知時間に納まる範囲での、最大限の情報を、図51の定
義を参照してそれぞれの処理対象の優先度に合わせて通
知する。

【０２５８】例えば、同じ図15のスケジュール151の「1
5:00 Meeting」であっても、時間の変化に対応した緊急
度の変化により、以下のように通知の態様が変化する。

【０２５９】図49の緊急度・優先度対応定義情報によれ
ば、図15の152に示した8:05時点では、開始まで1日未満
で３時間以上前なので緊急度は4である。一方、153に示
した14:50では、開始まで1時間未満で５分以上前なので
緊急度は2である。更に、154に示した15:00では、開始
前後５分以内なので緊急度は1である。また、155に示し
た16:05では、開始後で終了前なので緊急度は1である。
更に、156に示した19:15では、終了後１時間以上３時間
以内なので緊急度は3である。

【０２６０】上記のように、それぞれの緊急度の差が、
優先度の差として表れ、通知の強調の度合いの違いとな
る。なお、図15の例では、通知文の内容も、時間によっ
て変化させているが、これは、例えば、スケジュールの
時刻及び内容と、スケジュールの時刻と通知を行なう時
刻との差に基づいて、通知文を適宜作成すればよい。

【０２６１】（実施形態 19）図16は、処理対象となる
項目数による、１項目当りの情報量の変化の一例を表し
た図である。

【０２６２】以降、図16を用いて詳細に説明する。

【０２６３】優先度・項目数対応処理が起動されると、
まずステップS4601で処理対象が、図47の(a)のように処
理対象項目に格納される。その結果、ステップS4602
で、処理対象項目に情報が存在するので、ステップS460
3で、後述する優先度取得処理により、処理対象項目に
格納されているすべての処理対象について、図47の(b)
のように優先度を取得する。

【０２６４】次のステップS4604で、処理対象項目数が
２つ以上存在すると判断し、ステップS4606に進み、表
示画面の大きさ又はユーザが認識可能な表示領域の大き
さと、表示しようとしている処理対象項目数を比較し、
１項目当りの最適な表示領域の大きさを決定する。続く
ステップS4607で、上記で決定された１項目当りの表示
領域に納まる範囲での、最大限の情報を、図51の定義を
参照してそれぞれの処理対象の優先度に合わせて表示す
る。

【０２６５】例えば、図16の161のように、項目数が多
い時には、１項目当たりに表示可能な情報量は少なくな
り、この例ではスケジュールには開始時間と内容しか表
示されていない。

【０２６６】また、図16の162のように、項目数が少な
い時には、１項目当たりに表示可能な情報量は多くな
り、この例ではスケジュールには開始時間と内容と場所
が表示されている。

【０２６７】また、図16の163のように、表示領域に対
して項目数が十分少ない場合には、それぞれの項目のす
べての内容そのものを表示する。この例では、開始時間
と内容、場所、テーマ、出席者などスケジュールに関す
るすべての情報を表示している。

【０２６８】（実施形態 20）図48は、処理部17の優先
度・項目数対応処理等から利用される、優先度取得処理
の流れを表す図である。

【０２６９】図49は、処理部17の優先度・項目数対応処
理等から利用される、優先度取得処理で参照される、緊
急度から優先度を求める為の定義の一例を表した図であ
る。ここでは、処理対象に含まれる開始時刻や終了期限
などの時間に関する情報と、現在の時刻とを比較して得
られる緊急度から、優先度を求める為の対応が定義され
ている。

【０２７０】図50は、処理部17の優先度・項目数対応処
理等から利用される、優先度取得処理で参照される、地
位・役職・ユーザとの関係から優先度を求める為の定義
の一例を表した図である。ここでは、処理対象に含まれ
る出席者や主催者、指示者などの人に関する情報から、
優先度を求める為の対応が定義されている。

【０２７１】図11は、処理部17の優先度・項目数対応処
理による、スケジュールと、対応する表示結果の一例を
表した図である。スケジュールには、開始終了時刻、内
容、場所、優先度、及び図には記載されていないが、そ
れぞれの予定に関係する出席者や、主催者などの情報が
含まれている。また、優先度はユーザが指定することも
可能であり、値が少ないほど優先度が高いものとして管
理している。

【０２７２】優先度取得処理が起動されると、まずステ
ップS4801で処理対象にユーザが指定した優先度が有効
かどうか、チェックされる。無効な場合にはステップS4
802に進み標準値(=3)が優先度にセットされ、有効な場
合にはユーザが指定した優先度をセットする。

【０２７３】続いて、ステップS4804で処理対象の開始
時刻や終了期限の指定が有効かどうかチェックされる。
無効な場合にはステップS4805に進み標準値(=4)が優先
度に加えられ、有効な場合には図49の緊急度・優先度対
応定義情報を参照して求められた優先度を加える。

【０２７４】続いて、ステップS4807で処理対象に関連
する、出席者や主催者、指示者などの人の指定が有効か
どうか、チェックされる。無効な場合にはステップS480
8に進み標準値(=3)が優先度に加えられ、有効な場合に
はステップS4809に進み、ユーザが指定した人毎の優先
度が有効かどうかチェックされる。

【０２７５】ステップS4810では、処理対象に関連する
人の情報の中から、図12の127に示したような人毎の優
先度の定義情報を参照することで、ユーザが指定した人
毎の優先度の最大値が、優先度に加えられる。

【０２７６】ステップS4811では、処理対象に関連する
人の情報の中から、図13の137や図50に示したような地
位や役職などの一般常識による優先度の定義情報を参照
することで、地位や役職などの一般常識による優先度の
最大値が、優先度に加えられる。

【０２７７】続いて、ステップS4812で処理対象に含ま
れる人や時間や場所その他の情報から、関連する情報が
存在しないかどうか検索される。その結果、次のステッ
プS4813で関連する情報が見つからなければ、ステップS
4814に進み、標準値(=3)が優先度に加えられる。

【０２７８】上記の処理手順により、求められた優先度
が、出力され、処理が終了する。以降、図11及び図49を
用い、処理対象として図11の115に示したスケジュール
が指定された場合について、具体的に説明する。

【０２７９】優先度取得処理が起動されると、ステップ
S4801でユーザが指定した優先度は有効な値(=3)である
と判断し、優先度に3をセットする。

【０２８０】続いて、ステップS4804で処理対象の開始
時刻は15:00であり有効である。そこで、現在の時刻113
が示す12:40と比較して緊急度を求め、図49の緊急度・
優先度対応定義情報を参照して求められた値(=3)を優先
度に加え、合計(=6)を求める。

【０２８１】続いて、スケジュールに関連する人の情報
が指定されていないとすると、ステップS4807でチェッ
クされ、ステップS4808に進み標準値(=3)が優先度に加
えられ、合計(=9)を求める。

【０２８２】続いて、ステップS4812で検索した結果、
スケジュールに関連する情報が存在しなかったと、ステ
ップS4814に進み、標準値(=3)が優先度に加えられ、合
計(=12)が求められる。

【０２８３】上記の処理手順により、求められた優先度
(=12)が、図47の(b)の4713のように出力され、処理が終
了する。

【０２８４】（実施形態 21）図12は、処理部17の優先
度・項目数対応処理による、タスク及び人毎の優先度を
定義した情報と、対応する表示結果の一例を表した図で
ある。

【０２８５】タスクには、期限、内容、関係者、優先
度、及び図には記載されていないが、それぞれのタスク
に関係するスケジュールなどの情報が含まれている。ま
た、優先度はユーザが指定することも可能であり、値が
少ないほど優先度が高いものとして管理している。ま
た、人毎の優先度を定義した情報127には、人とそれぞ
れの優先度が定義されている。

【０２８６】以降、図12及び図49を用い、処理対象とし
て図12の124に示したタスクが指定された場合につい
て、具体的に説明する。

【０２８７】優先度取得処理が起動されると、ステップ
S4801でユーザが指定した優先度は有効な値(=3)である
と判断し、優先度に3をセットする。

【０２８８】続いて、ステップS4804で処理対象の終了
期限は3/4 18:00であり有効である。そこで、現在の日
付123が示す3/1と比較して緊急度を求め、図49の緊急度
・優先度対応定義情報を参照して求められた値(=6)を優
先度に加え、合計(=9)を求める。

【０２８９】続いて、Johnがタスクに関連する人として
指定されているので、ステップS4807及びステップS4809
でチェックされ、ステップS4810に進み図12のユーザ指
定人優先度定義情報128で指定された値(=3)が優先度に
加えられ、合計(=12)を求める。

【０２９０】続いて、ステップS4812で検索した結果、
タスクに関連する情報が存在しなかったと、ステップS4
814に進み、標準値(=3)が優先度に加えられ、合計(=15)
が求められる。

【０２９１】上記の処理手順により、求められた優先度
(=15)が、出力され、処理が終了する。

【０２９２】（実施形態 22）図13は、処理部17の優先
度・項目数対応処理による、タスク及び人の地位や役職
毎の優先度を定義した情報と、対応する表示結果の一例
を表した図である。

【０２９３】タスクには、期限、内容、関係者、優先
度、及び図には記載されていないが、それぞれのタスク
に関係するスケジュールなどの情報が含まれている。ま
た、優先度はユーザが指定することも可能であり、値が
少ないほど優先度が高いものとして管理している。ま
た、人の地位や役職などの一般常識による優先度を定義
した情報137には、人の地位や役職などとそれぞれの優
先度が定義されている。

【０２９４】以降、図13、図49及び図50を用い、処理対
象として図13の135に示したタスクが指定された場合に
ついて、具体的に説明する。

【０２９５】優先度取得処理が起動されると、ステップ
S4801でユーザが指定した優先度は有効な値(=3)である
と判断し、優先度に3をセットする。

【０２９６】続いて、ステップS4804で処理対象の終了
期限は3/4 18:00であり有効である。そこで、現在の日
付123が示す3/1と比較して緊急度を求め、図49の緊急度
・優先度対応定義情報を参照して求められた値(=6)を優
先度に加え、合計(=9)を求める。

【０２９７】続いて、Presidentがタスクに関連する人
として指定されているので、ステップS4807及びステッ
プS4809でチェックされ、ステップS4811に進み図50の地
位や役職などの一般常識による優先度の定義情報を参照
し、社長5002の優先度を示す値(=0)が優先度に加えら
れ、合計(=9)を求める。

【０２９８】続いて、ステップS4812で検索した結果、
タスクに関連する情報が存在しなかったと、ステップS4
814に進み、標準値(=3)が優先度に加えられ、合計(=12)
が求められる。

【０２９９】上記の処理手順により、求められた優先度
(=12)が、図47の(b)の4718のように出力され、処理が終
了する。

【０３００】（実施形態 23）図14は、処理部17の優先
度・項目数対応処理による、受信・到着した情報及びタ
スクと、対応する表示結果の一例を表した図である。受
信・到着した情報には、誰から受信したものかを示す情
報が含まれている。また、タスクには、期限、内容、関
係者、優先度、及び図には記載されていないが、それぞ
れのタスクに関係するスケジュールなどの情報が含まれ
ている。また、優先度はユーザが指定することも可能で
あり、値が少ないほど優先度が高いものとして管理して
いる。

【０３０１】以降、図14及び図49を用い、処理対象とし
て図14の147に示した受信・到着情報が指定された場合
について、具体的に説明する。

【０３０２】優先度取得処理が起動されると、優先度が
指定されていないので、ステップS4801でチェックさ
れ、ステップS4802に進み、標準値(=3)が優先度にセッ
トされる。

【０３０３】続いて、ステップS4804でも時刻に関する
指定もされていないので、標準値(=4)が優先度に加えら
れ、合計(=7)が求められる。

【０３０４】続いて、Johnがタスクに関連する人として
指定されているので、ステップS4807及びステップS4809
でチェックされ、ステップS4811に進み図50の地位や役
職などの一般常識による優先度の定義情報を参照し、同
僚5008の優先度を示す値(=5)が優先度に加えられ、合計
(=12)を求める。

【０３０５】続いて、ステップS4812で検索した結果、
受信・到着情報に関連する情報として、図14のタスク14
4の関係者Johnが、受信・到着情報の発信元と同じ John
であることから、検索される。

【０３０６】上記の処理手順により、求められた優先度
(=12)が、図47の(b)の4720のように出力され、処理が終
了する。

【０３０７】（実施形態 24）検索対象数に対応して検
索処理手順を変更する例を説明する。

【０３０８】図52は、処理部17の検索対象数対応処理の
流れを示すフローチャートである。

【０３０９】図17は、処理部17の検索対象数対応処理に
よる、検索を行う為のユーザの操作画面と、検索対象範
囲の一例を表した図である。

【０３１０】図17に示したような操作画面1701により、
ユーザが指定した検索条件などの情報は、操作部11によ
り受け付けられ、タスク受信部13を介してタスクテーブ
ル14に追加される。その後、タスク解析部及びプランニ
ング決定部を介して処理実行部17の検索対象数対応処理
が起動される。

【０３１１】検索対象数対応処理が起動されると、まず
ステップS5201で、図17の1703でユーザが指定した検索
範囲の情報が、検索対象項目に格納される。その結果、
ステップS5202で、検索対象項目に情報が存在するかど
うかチェックされ、存在する場合ステップS5203に進
み、存在しない場合終了する。ステップS5203では、検
索対象項目数が10,000以下かどうかチェックし、10,000
以下の場合、図17の1702でユーザが指定した全キーワー
ドで検索を行い終了する。

【０３１２】一方、10,000より検索対象項目数が多い場
合、ステップS5205に進み、100,000を検索対象項目数で
割った大きさの割合で、検索キーワード数を絞り込む。
その結果、ステップS5206で検索キーワード数が全体の1
%以下になったと判断された場合、最低限の検索効果を
維持する為に、ステップS5207で検索キーワード数を1%
に設定し直す。

【０３１３】続く、ステップS5208で、上記検索キーワ
ード数分だけの、図17の1702でユーザが指定した優先度
上位のキーワードを用いて、検索対象を検索し、終了す
る。

【０３１４】上記のような過程で、処理をした結果、図
17の1708に示すようなローカルＰＣ内をユーザが指定し
た場合には、例えば検索対象数が１００件程度とすれ
ば、図17の1702でユーザが指定した全キーワードで検索
を行う。

【０３１５】また、図17の1709に示すようなドメイン内
全ＰＣをユーザが指定した場合には、例えば検索対象数
が10,000件程度とすれば、図17の1702でユーザが指定し
た全キーワードの優先度上位１０％で検索を行う。

【０３１６】また、図17の1710に示すような全世界をユ
ーザが指定した場合には、例えば検索対象数が膨大なの
で、図17の1702でユーザが指定した全キーワードの優先
度上位１％で検索を行う。

【０３１７】（実施形態 25）以下では、ユーザの在席
状態に応じて対応する処理を実行する例を説明する。ま
ず、在席しているかどうかについて、ユーザから明示的
な指示があった場合について説明する。

【０３１８】図19は、在席しているかどうかについての
ユーザによる明示的な指示に対応して、実行される処理
を決定する情報処理装置の一例を表す図である。図19の
(a)は、ユーザ191が情報処理装置192に表示されている
操作画面193の指示に従って、項目「See you tomorro
w」を指定し、離席した場合の例である。図19の(b)は、
ユーザ194が情報処理装置195に向かって、音声で「Hell
o」196と話しかけて、帰席した場合の例である。

【０３１９】ユーザ191が情報処理装置192に表示されて
いる操作画面193の指示に従って行った、項目「See you
tomorrow」の指定操作の情報は、操作部11により受け
付けられ、タスク受信部13によってタスクテーブル14に
追加される。

【０３２０】その後、タスク解析部15及びプランニング
決定部16を介して、図53につき後述する処理実行部17の
ユーザ在席判断・在席モード変換処理が起動され、そこ
でモードが「在席」から「離席」に変更される。

【０３２１】一方、ユーザ194が情報処理装置195に行っ
た、音声「Hello」の指示操作の情報は、操作部11によ
り受け付けられ、タスク受信部13によってタスクテーブ
ル14に追加される。

【０３２２】その後、タスク解析部15及びプランニング
決定部16を介して、図53に示した処理実行部17のユーザ
在席判断・在席モード変換処理が起動され、そこでモー
ドが「不在」から「帰席」に変更される。

【０３２３】以上のように、本実施形態によれば、ユー
ザの明示的な指示により、ユーザが在席しているかどう
かを判断し、対応する処理の実行を可能としている。

【０３２４】なお、処理の流れの詳細な説明について
は、上記処理を実現する為の、ユーザ在席判断・在席モ
ード変換処理の流れの一例を示すフローチャートである
図53等を用いて後述する。

【０３２５】（実施形態 26）次に、ユーザのスケジュ
ール情報等を参照して、在席かどうかを推測する例につ
いて説明する。

【０３２６】図20は、ユーザのスケジュール情報等を参
照して、在席かどうかを推測し、実行される処理を決定
する情報処理装置の一例を表す図である。図20の情報処
理装置201には、参照可能なユーザのスケジュール情報2
02が存在しており、このスケジュール情報を参照するこ
とで、ユーザが在席しているかどうかを推測する。

【０３２７】ユーザ在席推測処理は、ユーザの操作が一
定時間無い場合に実行されるように指定されたタスク
が、タスクテーブル14に格納されていた場合や、他の情
報処理装置2からユーザが在席しているかの問い合せを
タスク受信部13により受信し、対応するタスクをタスク
テーブル14に追加された場合などに、実行される。

【０３２８】そこで、タスク解析部15及びプランニング
決定部16を介して、図53に示した処理実行部17のユーザ
在席判断・在席モード変換処理及び、更に図57に示した
ユーザ在席推論処理が起動され、在席かどうかの推論が
実行され、対応するモードに変更される。

【０３２９】図20の例の場合には、実行時の日付203が3
/12であり、対応するスケジュール202を参照すると、
「新川崎に外出」とあるので、ユーザ204は外出先の新
川崎にいることが推論される。よって、情報処理装置20
1の近くにはユーザは不在205であると推論され、モード
が「不在」に変更される。または、他の情報処理装置2
に、ユーザが近くにいないことを通知する。

【０３３０】以上のように、本実施形態によれば、参照
可能なユーザの情報から推論することで、ユーザが在席
しているかどうかを判断し、対応する処理の実行を可能
としている。

【０３３１】なお、処理の流れの詳細な説明について
は、上記処理を実現する為の、ユーザ在席推論処理の流
れの一例を示すフローチャートである図57等を用いて後
述する。

【０３３２】（実施形態 27）次に、受信情報に基づい
てユーザが在席しているかどうか判断する例を説明す
る。

【０３３３】図21は、他の情報処理装置2からの在席情
報の受信を受けて、ユーザが在席しているかどうか判断
し、実行される処理を決定する情報処理装置の一例を表
す図である。

【０３３４】図21の(a)は、ユーザ214が大阪にある情報
処理装置211の近くにいるという在席情報を、東京にあ
る情報処理装置212が受信した場合に、同じユーザが東
京と大阪に同時に存在することは不可能だという、一般
常識を利用して、ユーザが不在215であると判断した場
合の例である。一方、図21の(b)は、ユーザ219が東京の
6F居室にある情報処理装置216の近くにいるという在席
情報を、同じ東京の6F居室にある情報処理装置217が受
信した場合に、同じ東京の6F居室なので同時に存在する
という、一般常識を利用して、ユーザが在席219である
と判断した場合の例である。

【０３３５】前述のように、ユーザ214が大阪にある情
報処理装置211に明示的に在席していることを指示した
り、逆に後述するように情報処理装置211がユーザ214を
検出することで、情報処理装置211はユーザ214が在席し
ていることを知る事ができる。そこで、得られたユーザ
在席情報を、自主的にあるいはユーザ214の指示に従っ
て、東京にある情報処理装置212に送信すると、情報処
理装置212はタスク受信部13により、ユーザ在席情報を
受信するので、図53に示した処理実行部17のユーザ在席
判断・在席モード変換処理を起動するタスクを、タスク
テーブル14に追加する。

【０３３６】その後、タスク解析部15及びプランニング
決定部16を介して、図53のフローチャートに手順を示し
た処理実行部17のユーザ在席判断・在席モード変換処理
が起動され、そこでモードが「不在」に変更される。

【０３３７】一方、ユーザ219が東京6F居室にある情報
処理装置216に明示的に在席していることを指示した
り、逆に後述するように情報処理装置216がユーザ219を
検出することで、情報処理装置216はユーザ219が在席し
ていることを知る事ができる。そこで、得られたユーザ
在席情報を、自主的にあるいはユーザ219の指示に従っ
て、同じ東京6F居室にある情報処理装置217に送信する
と、同じ東京6F居室にある情報処理装置217はタスク受
信部13により、ユーザ在席情報を受信するので、図53に
示した処理実行部17のユーザ在席判断・在席モード変換
処理を起動するタスクを、タスクテーブル14に追加す
る。

【０３３８】その後、タスク解析部15及びプランニング
決定部16を介して、図53に示した処理実行部17のユーザ
在席判断・在席モード変換処理が起動され、そこでモー
ドが「在席」に変更される。

【０３３９】以上のように、本実施形態によれば、受信
した在席情報と、どこから受信した在席情報であるかと
いうことから、ユーザが在席しているかどうかを判断
し、対応する処理の実行を可能としている。

【０３４０】なお、処理の流れの詳細な説明について
は、ユーザ在席判断・在席モード変換処理のフローチャ
ートである図53等を用いて後述する。

【０３４１】（実施形態 28）次に、ユーザが近くにい
るかどうかを検出した結果を参照して、ユーザが在席し
ているかどうか判断する例について説明する。

【０３４２】図22は、ユーザが近くにいるかどうかを検
出した結果を参照し、ユーザが在席しているかどうか判
断し、実行される処理を決定する情報処理装置の一例を
表す図である。

【０３４３】図22の(a)は、情報処理装置211で制御可能
なカメラ222により、入力された映像を元に、ユーザが
近くにいるかどうかを検出する場合の例である。一方、
図22の(b)は、情報処理装置224が、ユーザ226が携帯す
る情報処理装置225が発信する情報227を検出すること
で、ユーザが近くにいるかどうかを検出する場合の例で
ある。

【０３４４】情報処理装置221で制御可能なカメラ222の
撮影範囲223の、撮影された映像情報がタスク受信部13
により受信され、この映像の解析タスクがタスクテーブ
ル14に追加される。その後、タスク解析部15及びプラン
ニング決定部16を介して、映像を解析した結果、ユーザ
がいるかどうかがわかり、図53に手順を示した処理実行
部17のユーザ在席判断・在席モード変換処理を起動する
タスクを、新たにタスクテーブル14に追加する。

【０３４５】その後、タスク解析部15及びプランニング
決定部16を介して、図53に手順を示した処理実行部17の
ユーザ在席判断・在席モード変換処理が起動され、そこ
で検出結果が現在のモードと異なれば、モードが変更さ
れる。ここで、例えば、検出時の在席モードが「在席」
であり、撮影された映像情報にユーザがいなかったとす
ると、モードが「離席」に変更されることになる。

【０３４６】一方、ユーザ226が携帯する情報処理装置2
25が発信する情報227を、情報処理装置224が検出した場
合、受信情報がタスク受信部13により受信され、受信情
報の解析タスクとしてタスクテーブル14に追加される。
その後、タスク解析部15及びプランニング決定部16を介
して、受信情報を解析した結果、ユーザがいるかどうか
がわかり、新たに図53に示した処理実行部17のユーザ在
席判断・在席モード変換処理を起動するタスクを、タス
クテーブル14に追加する。

【０３４７】その後、タスク解析部15及びプランニング
決定部16を介して、図53に示した処理実行部17のユーザ
在席判断・在席モード変換処理が起動され、そこでモー
ドが変更される。ここで、例えば、検出時の在席モード
が「不在」であり、受信された受信情報がユーザがいる
ことを示すものだったとすると、モードが「在席」に変
更されることになる。

【０３４８】以上のように、本実施形態によれば、情報
処理装置の制御下にあるカメラで撮影された情報や、ユ
ーザが携帯する他の情報処理装置から送信された情報を
受信することで、ユーザが在席しているかどうかを判断
し、対応する処理の実行を可能としている。

【０３４９】なお、処理の流れの詳細な説明について
は、ユーザ在席判断・在席モード変換処理のフローチャ
ートである図53等を用いて後述する。

【０３５０】（実施形態 29）次に、ユーザが在席して
いると判断された場合の処理について説明する。

【０３５１】図23は、ユーザが在席していると判断され
た時に、対応する処理を実行可能な情報処理装置の一例
を表す図である。図23は、ユーザが在席していると判断
された場合に、緊急の情報をユーザに通知する表示画面
の一例を示したものである。

【０３５２】図53に手順を示す処理実行部17のユーザ在
席判断・在席モード変換処理により起動された、図59に
手順を示すユーザ在席モード変換処理により、「在席」
モードに変更された場合に、図23に示したようなユーザ
在席処理が実行可能である。

【０３５３】そこで、ユーザ231が在席している時に、
情報処理装置232が、緊急と判断されるメールを受信し
た場合、タスク受信部13によってタスクテーブル14に追
加される。

【０３５４】その後、タスク解析部15及びプランニング
決定部16を介して、処理実行部17の緊急通知タスクが起
動され、図23の233のような通知画面が表示される。

【０３５５】これは、ユーザが在席していなければ、意
味の無い表示であり、緊急通知の目的を果たすことがで
きない。よって、「在席」モード以外ならば別の方法に
より通知する必要がある。

【０３５６】以上のように、本実施形態によれば、ユー
ザが在席している場合、緊急通知などの在席に対応した
処理の実行を可能としている。

【０３５７】なお、処理の流れの詳細な説明について
は、上記処理を実現する為の、ユーザ在席モード変換処
理の流れの一例を示すフローチャートである図59等を用
いて後述する。

【０３５８】（実施形態 30）次に、ユーザが不在だと
判断された場合の処理について説明する。

【０３５９】図24は、ユーザが不在だと判断された時
に、対応する処理を実行可能な情報処理装置の一例を表
す図である。図24は、ユーザが不在と判断された場合
に、ユーザの来客に対する伝言の表示と、来客のユーザ
に対する伝言を受け付ける為の表示画面の一例を示した
ものである。

【０３６０】図53に示した処理実行部17のユーザ在席判
断・在席モード変換処理により起動された、図59に示し
たユーザ在席モード変換処理により、「不在」モードに
変更された場合に、図24に示したようなユーザ不在処理
が実行可能である。

【０３６１】そこで、情報処理装置242は、図24に示す
ような処理の実行を、ユーザ241が不在の時に実行され
るよう、あらかじめタスクテーブル14に追加しておく。

【０３６２】その後、タスク解析部15及びプランニング
決定部16を介して、処理実行部17の伝言表示・受け付け
タスクが起動され、図24に示す操作画面243が表示され
る。

【０３６３】これは、ユーザが不在だからこそ意味のあ
る表示であり、伝言表示・受け付けの目的を果たすこと
ができる。よって、「不在」モード以外ならば実行する
必要が無い。

【０３６４】以上のように、本実施形態によれば、ユー
ザが不在の場合、伝言表示・受け付けなどの不在に対応
した処理の実行を可能としている。

【０３６５】なお、処理の流れの詳細な説明について
は、上記処理を実現する為の、ユーザ在席モード変換処
理の流れの一例を示したフローチャートである図59等を
用いて後述する。

【０３６６】（実施形態 31）次に、ユーザが離席しよ
うとしていると判断された時に、対応する処理を実行す
る例を説明する。

【０３６７】図25は、ユーザが離席しようとしていると
判断された場合に、ユーザが思い出した方が良い情報を
通知する為の通知動作の一例を示したものである。

【０３６８】図53に示した処理実行部17のユーザ在席判
断・在席モード変換処理により起動された、図59に示し
たユーザ在席モード変換処理により、「離席」モードに
変更された場合に、図25に示したようなユーザ離席処理
が実行可能である。

【０３６９】そこで、前述のような方法でユーザが離席
しようとしていることを検出すると、「離席」モードに
変更すると共に、「離席」モードで実行可能な、図25に
示したユーザが思い出した方が良い情報を通知する為の
通知処理のタスク等をタスクテーブル14に追加する。

【０３７０】その後、タスク解析部15及びプランニング
決定部16を介して、処理実行部17のユーザが思い出した
方が良い情報を通知する為の通知処理タスクが起動さ
れ、図25の操作画面254が表示される。

【０３７１】例えば、図25の例の場合、現在の時刻253
の示す14:50と、ユーザ251のスケジュール「15:00 チー
フミーティング」を比較し、ユーザの離席の理由がミー
ティングに参加する為のものであれば問題無いが、それ
以外の場合忘れている危険があることを理解する。そこ
で、ユーザ251に「15:00からA111会議室で、チーフミー
ティングです」254と通知する。

【０３７２】これは、ユーザが離席しようとしているタ
イミングだからこそ効果的な通知であり、ユーザが思い
出した方が良い情報の通知の目的を果たすことができ
る。よって、「離席」モード以外ならば別の方法により
通知する必要がある。

【０３７３】また、上記「離席」モードの処理を実行
後、「不在」モードに変換するなどの処理を続行する。

【０３７４】以上のように、本実施形態によれば、ユー
ザが離席しようとしている場合、ユーザが思い出した方
が良い情報の通知などの、離席に対応した処理の実行を
可能としている。

【０３７５】なお、処理の流れの詳細な説明について
は、上記処理を実現する為の、ユーザ在席モード変換処
理の流れの一例を示したフローチャートである図59等を
用いて後述する。

【０３７６】（実施形態 32）次に、ユーザが帰席した
と判断された時に、対応する処理を実行する例を説明す
る。

【０３７７】図26は、ユーザが帰席したと判断された場
合に、不在中の伝言などの受信情報を通知する為の通知
動作の一例を示したものである。

【０３７８】図53に示した処理実行部17のユーザ在席判
断・在席モード変換処理により起動された、図59に示し
たユーザ在席モード変換処理により、「帰席」モードに
変更された場合に、図26に示したようなユーザ帰席処理
が実行可能である。

【０３７９】そこで、前述のような方法でユーザが帰席
したことを検出すると、「帰席」モードに変更すると共
に、「帰席」モードで実行可能な、図26に示した不在中
の伝言などの受信情報を通知する為の通知処理のタスク
等をタスクテーブル14に追加する。

【０３８０】その後、タスク解析部15及びプランニング
決定部16を介して、処理実行部17の不在中の伝言などの
受信情報を通知する為の通知処理タスクが起動され、図
26の264のような操作画面が表示される。例えば、図26
の例の場合、直接来客が入力した伝言も含めて、不在中
に５件の情報を受信しており、その一覧を表示してい
る。

【０３８１】これは、ユーザが帰席したタイミングだか
らこそ効果的な通知であり、不在中の伝言などの受信情
報の通知の目的を果たすことができる。よって、「帰
席」モード以外ならば別の方法により通知する必要があ
る。また、上記「帰席」モードの処理を実行後、「在
席」モードに変換するなどの処理を続行する。

【０３８２】以上のように、本実施形態によれば、ユー
ザが帰席した場合、不在中の伝言などの受信情報の通知
などの、帰席に対応した処理の実行を可能としている。

【０３８３】なお、処理の流れの詳細な説明について
は、上記処理を実現する為の、ユーザ在席モード変換処
理の流れの一例を示したフローチャートである図59等を
用いて後述する。

【０３８４】（実施形態 33）次に、ユーザが在席して
いるかどうか不明であると判断された時に、対応する処
理を実行する例を説明する。

【０３８５】図27は、ユーザが在席しているかどうか不
明であると判断された場合に、近くにユーザがいるかど
うか確認する為に、パスワードの確認を求める操作画面
の一例を示したものである。

【０３８６】図53に示した処理実行部17のユーザ在席判
断・在席モード変換処理により起動された、図59に示し
たユーザ在席モード変換処理により、「在席不明」モー
ドに変更された場合に、図27に示したようなユーザ在席
不明処理が実行可能である。

【０３８７】そこで、前述のような方法で検出してもユ
ーザが在席しているかどうか不明である場合、「在席不
明」モードに変更すると共に、「在席不明」モードで実
行可能な、図27に示したパスワードの確認を求める操作
処理のタスク等をタスクテーブル14に追加する。

【０３８８】その後、タスク解析部15及びプランニング
決定部16を介して、処理実行部17のパスワードの確認を
求める操作処理タスクが起動され、図27の273のような
操作画面が表示される。

【０３８９】例えば、図27の例の場合、一定時間(３０
分)、ユーザの操作が無く、しかもユーザが在席してい
るかどうかが不明の為、パスワードの確認を要求してい
る。

【０３９０】これは、ユーザが在席しているかどうか不
明であるからこそ効果的な通知であり、パスワードの確
認を求める操作の目的を果たすことができる。よって、
「在席不明」モード以外ならば別の方法によりパスワー
ド確認操作をする必要がある。

【０３９１】以上のように、本実施形態によれば、ユー
ザが在席しているかどうか不明の場合、パスワードの確
認を求める操作などの、在席不明時に対応した処理の実
行を可能としている。

【０３９２】なお、処理の流れの詳細な説明について
は、上記処理を実現する為の、ユーザ在席モード変換処
理の流れの一例を示したフローチャートである図59等を
用いて後述する。

【０３９３】（実施形態 34）次に、ユーザが在席して
いるかどうかに矛盾があると判断された時に、対応する
処理を実行する例を説明する。

【０３９４】図28は、ユーザが在席しているかどうかに
矛盾があると判断された場合に、情報処理装置のユーザ
の操作をロックして不正な使用をできないようにし、更
に前述のパスワード確認操作を実行する等の処理の一例
を示したものである。

【０３９５】図53に示した処理実行部17のユーザ在席判
断・在席モード変換処理により起動された、図59に示し
たユーザ在席モード変換処理により、「在席矛盾」モー
ドに変更された場合に、図28に示したようなユーザ在席
矛盾処理が実行可能である。

【０３９６】そこで、前述のような方法で検出した結
果、ユーザが在席しているかどうかに矛盾がある場合、
「在席矛盾」モードに変更すると共に、「在席矛盾」モ
ードで実行可能な、図28に示したユーザの操作をロック
して不正な使用をできないようにし、更に前述のパスワ
ードの確認を求める操作処理のタスク等をタスクテーブ
ル14に追加する。

【０３９７】その後、タスク解析部15及びプランニング
決定部16を介して、処理実行部17のユーザの操作をロッ
クして不正な使用をできないようにし、更に前述のパス
ワードの確認を求める操作処理タスクが起動される。

【０３９８】例えば、図28の例の場合、東京と大阪の情
報処理装置から、同時に同じユーザが近くにいるとい
う、存在情報が送信された場合に、矛盾を発見し、ユー
ザの操作をロックして不正な使用をできないようにし、
更に前述のパスワードの確認を要求している。

【０３９９】これは、ユーザが在席しているかどうかに
矛盾があるからこそ効果的な処理であり、上記処理の目
的を果たすことができる。よって、「在席矛盾」モード
以外ならば別の方法により上記処理を実行をする必要が
ある。

【０４００】以上のように、本実施形態によれば、ユー
ザが在席しているかどうかに矛盾がある場合、上記処理
のような、在席矛盾時に対応した処理の実行を可能とし
ている。

【０４０１】なお、処理の流れの詳細な説明について
は、上記処理を実現する為の、ユーザ在席モード変換処
理の流れの一例を示したフローチャートである図59等を
用いて後述する。

【０４０２】（実施形態 35）次に、情報処理装置に、
他の場所にいるユーザの在席場所を表示する例を説明す
る。

【０４０３】図29は、グループメンバーなどそれぞれの
ユーザの在席場所を表示可能な、情報処理装置の一例を
表す図である。図29は、ＡさんとＢさんの在席場所を、
情報処理装置297が表示している一例を示したものであ
る。

【０４０４】前述のように、図53に示した処理実行部17
のユーザ在席判断・在席モード変換処理により起動され
た、図59に示したユーザ在席モード変換処理により、変
更されたそれぞれのモードの処理により、ユーザの在席
情報が情報処理装置297に送信される。

【０４０５】例えば、図29の例の場合、東京の情報処理
装置293はＡさん291が近くにいることを検出し、情報処
理装置297に送信295している。また、大阪の情報処理装
置294はＢさん292が近くにいることを検出し、情報処理
装置297に送信296している。一方、Ａさん291とＢさん2
92の在席情報295,296を受信した情報処理装置297は、ユ
ーザが指示した時に表示可能なように、それら在席情報
を記憶して管理する。

【０４０６】ここで、ユーザが情報処理装置297に対し
て、グループメンバー全員の在席情報の表示を指示する
と、操作部11により指示を受け付け、タスク受信部13に
より処理実行部17のユーザ在席場所表示処理タスクをタ
スクテーブル14に追加する。その後、タスク解析部15及
びプランニング決定部16を介して、処理実行部17のユー
ザ在席場所表示処理タスクが起動され、図29の298のよ
うな在席場所一覧が表示される。

【０４０７】以上のように、本実施形態によれば、グル
ープメンバーなどそれぞれのユーザの在席場所を表示可
能である。

【０４０８】なお、処理の流れの詳細な説明について
は、上記処理を実現する為の、ユーザ在席場所表示処理
の流れの一例を示すフローチャートである図61等を用い
て後述する。

【０４０９】（実施形態 36）ユーザが在席するかを判
断し、必要なら在席モードを変換する処理の流れを説明
する。

【０４１０】図53は、処理部17のユーザ在席判断・在席
モード変換処理の流れを表すフローチャートである。

【０４１１】図54は、処理部17のユーザ在席判断・在席
モード変換処理の、ユーザの指示に対する在席モード変
換の定義の一例を表した図である。それぞれの定義情報
には、ユーザの指示に対する、在席モード変換の定義だ
けでなく、それぞれの指示を行った後に推測される予測
が記載されている。後述するユーザ在席推論処理では、
ユーザのスケジュールなどの情報のほかに、上記ユーザ
の指示からの予測も利用して、在席かどうかの推論を行
っている。

【０４１２】図55は、処理部17のユーザ在席判断・在席
モード変換処理の、受信情報に対する在席モード変換の
定義の一例を表した図である。それぞれの定義情報に
は、受信情報と、情報の発信元に対する、在席モード変
換の定義だけでなく、それぞれの受信情報を受信した後
に推測される予測が記載されている。

【０４１３】図56は、処理部17のユーザ在席判断・在席
モード変換処理の、検出結果に対する在席モード変換の
定義の一例を表した図である。それぞれの定義情報に
は、検出結果と、検出時の在席モードに対する、在席モ
ード変換の定義だけでなく、それぞれの検出結果を取得
した後に推測される予測が記載されている。

【０４１４】図19は、処理部17のユーザ在席判断・在席
モード変換処理に対する、ユーザのユーザ在席指示方法
の例である。図19の(a)は、操作画面193の指示に従っ
て、ユーザが項目を指示した場合である。図19の(b)
は、ユーザが音声で話しかけた場合である。

【０４１５】操作部11により受け付けられたユーザの指
示操作や、受信情報や、検出情報は、タスク受信部13に
よってタスクテーブル14に追加され、タスク解析部15及
びプランニング決定部16を介して、図53に示した処理実
行部17のユーザ在席判断・在席モード変換処理が起動さ
れる。

【０４１６】ユーザ在席判断・在席モード変換処理が起
動されると、まずステップS5301でユーザの指示がある
かどうか判断され、ユーザの指示がある場合、ステップ
S5302に進む。

【０４１７】ステップS5302では、図54のユーザの指示
に対する在席モード変換の定義情報を参照し、モード変
換情報を取得する。また、続くステップS5303で後述す
るユーザ在席推論処理で参照される情報として、予測情
報を取得する。

【０４１８】一方、ステップS5301でユーザの指示が無
かったと判断された場合には、ステップS5304に進み、
在席情報を受信したかどうか判断され、受信した場合、
ステップS5305に進む。

【０４１９】ステップS5305では、図55の受信情報に対
する在席モード変換の定義情報を参照し、モード変換情
報を取得する。また、続くステップS5306で後述するユ
ーザ在席推論処理で参照される情報として、予測情報を
取得する。

【０４２０】一方、ステップS5304で在席情報を受信し
なかったと判断された場合には、ステップS5307に進
み、在席情報を検出したかどうか判断され、検出した場
合、ステップS5308に進む。

【０４２１】ステップS5308では、図56の検出情報に対
する在席モード変換の定義情報を参照し、モード変換情
報を取得する。また、続くステップS5309で後述するユ
ーザ在席推論処理で参照される情報として、予測情報を
取得する。

【０４２２】一方、ステップS5307で在席情報を検出し
なかったと判断された場合には、ステップS5310に進
み、後述するユーザ存在推論処理を実行し、モード変換
情報を取得する。

【０４２３】次のステップS5311では、上記で取得され
たモード変換情報に矛盾が無いかどうか判断し、矛盾が
発見された場合、ステップS5312に進み、モード変換情
報に「ユーザ存在矛盾」の指定をセットする。

【０４２４】その後、ステップS5313で、ユーザ存在情
報に、上記で取得された在席モード変換情報をセット
し、続くステップS5314で後述する在席モード変換処理
により、在席モードに対応する処理を実行し、終了す
る。

【０４２５】以降、図19の(a)及び図54を用いて詳細に
説明する。

【０４２６】ユーザ191が情報処理装置192に表示されて
いる操作画面193の指示に従って行った、項目「See you
tommorrow」の指定操作の情報は、操作部11により受け
付けられ、タスク受信部13によってタスクテーブル14に
追加され、タスク解析部15及びプランニング決定部16を
介して、図53に示した処理実行部17のユーザ在席判断・
在席モード変換処理が起動される。

【０４２７】ユーザ在席判断・在席モード変換処理が起
動されると、ステップS5301でユーザの指示があると判
断され、ステップS5302及びステップS5303で、図54のユ
ーザの指示「See you tommorrow」に対する在席モード
変換の定義情報5403を参照し、モード変換情報「在席→
離席」及び予測情報「明日まで、不在」を取得する。

【０４２８】次のステップS5311で上記で取得されたモ
ード変換情報に矛盾が無いかどうか判断した結果、矛盾
がないのでステップS5313に進み、ユーザ存在情報に上
記で取得された在席モード変換情報「在席→離席」をセ
ットし、続くステップS5314で後述する在席モード変換
処理により、在席モードに対応する処理を実行し、終了
する。

【０４２９】その結果、図60の604に示した離席に対応
した処理が決定され、適切なタイミングで起動されるよ
う、タスクテーブル14に追加される。

【０４３０】次に、図19の(b)及び図54を用いて詳細に
説明する。

【０４３１】ユーザ194が情報処理装置195に行った、音
声「Hello」の指示操作の情報は、操作部11により受け
付けられ、タスク受信部13によってタスクテーブル14に
追加され、タスク解析部15及びプランニング決定部16を
介して、図53に示した処理実行部17のユーザ在席判断・
在席モード変換処理が起動される。

【０４３２】ユーザ在席判断・在席モード変換処理が起
動されると、ステップS5301でユーザの指示があると判
断され、ステップS5302及びステップS5303で、図54のユ
ーザの音声による指示「Hello」に対する在席モード変
換の定義情報5401を参照し、モード変換情報「不在→帰
席」を取得する。

【０４３３】次のステップS5311で上記で取得されたモ
ード変換情報に矛盾が無いかどうか判断した結果、矛盾
がないのでステップS5313に進み、ユーザ存在情報に上
記で取得された在席モード変換情報「不在→帰席」をセ
ットし、続くステップS5314で後述する在席モード変換
処理により、在席モードに対応する処理を実行し、終了
する。

【０４３４】その結果、図60の605に示した帰席に対応
した処理が決定され、適切なタイミングで起動されるよ
う、タスクテーブル14に追加される。

【０４３５】（実施形態 37）他の装置からユーザ在席
情報を受信する例について説明する。

【０４３６】図21は、処理部17のユーザ在席判断・在席
モード変換処理に対する、ユーザ在席情報受信の例であ
る。

【０４３７】図21の(a)は、ユーザ214が大阪にある情報
処理装置211の近くにいるという在席情報を、東京にあ
る情報処理装置212が受信した場合の例である。図21の
(b)は、ユーザ219が東京の6F居室にある情報処理装置21
6の近くにいるという在席情報を、同じ東京の6F居室に
ある情報処理装置217が受信した場合の例である。

【０４３８】以降、図21の(a)及び図55を用いて詳細に
説明する。

【０４３９】ユーザ214が大阪にある情報処理装置211に
明示的に在席していることを指示したり、逆に情報処理
装置211がユーザ214を検出することで、情報処理装置21
1はユーザ214が在席していることを知る事ができる。

【０４４０】そこで、上記で知ったユーザ在席情報を、
自主的にあるいはユーザ214の指示に従って、東京にあ
る情報処理装置212に送信すると、東京にある情報処理
装置212はタスク受信部13によってユーザ在席情報を受
信するので、タスクテーブル14に追加し、タスク解析部
15及びプランニング決定部16を介して、図53に示した処
理実行部17のユーザ在席判断・在席モード変換処理を起
動する。

【０４４１】ユーザ在席判断・在席モード変換処理が起
動されると、ステップS5301及びステップS5304で在席情
報を受信したと判断され、ステップS5305及びステップS
5306で、図55の受信情報「帰席」及び発信元「大阪」に
対する在席モード変換の定義情報5501を参照し、モード
変換情報「不在」を取得する。

【０４４２】次のステップS5311で上記で取得されたモ
ード変換情報に矛盾が無いかどうか判断した結果、矛盾
がないのでステップS5313に進み、ユーザ存在情報に上
記で取得された在席モード変換情報「不在」をセット
し、続くステップS5314で後述する在席モード変換処理
により、在席モードに対応する処理を実行し、終了す
る。

【０４４３】その結果、図60の602及び603に示した不在
に対応した処理が決定され、適切なタイミングで起動さ
れるよう、タスクテーブル14に追加される。

【０４４４】次に、図21の(b)及び図55を用いて詳細に
説明する。

【０４４５】ユーザ219が東京6F居室にある情報処理装
置216に明示的に在席していることを指示したり、逆に
情報処理装置216がユーザ219を検出することで、情報処
理装置216はユーザ219が在席していることを知る事がで
きる。

【０４４６】そこで、上記で知ったユーザ在席情報を、
自主的にあるいはユーザ219の指示に従って、同じ東京6
F居室にある情報処理装置217に送信すると、同じ東京6F
居室にある情報処理装置217はタスク受信部13によって
ユーザ在席情報を受信するので、タスクテーブル14に追
加し、タスク解析部15及びプランニング決定部16を介し
て、図53に示した処理実行部17のユーザ在席判断・在席
モード変換処理が起動する。

【０４４７】ユーザ在席判断・在席モード変換処理が起
動されると、ステップS5301及びステップS5304で在席情
報を受信したと判断され、ステップS5305及びステップS
5306で、図55の受信情報「帰席」及び発信元「東京6F居
室」に対する在席モード変換の定義情報5502を参照し、
モード変換情報「現状のまま」を取得する。

【０４４８】次のステップS5311で上記で取得されたモ
ード変換情報に矛盾が無いかどうか判断した結果、矛盾
がないのでステップS5313に進み、ユーザ存在情報に上
記で取得された在席モード変換情報「現状のまま」をセ
ットし、続くステップS5314で後述する在席モード変換
処理により、在席モードに対応する処理を実行し、終了
する。

【０４４９】その結果、現状のまま、新たな処理を行わ
ない。

【０４５０】（実施形態 38）ユーザ在席情報を検出す
る例について説明する。

【０４５１】図22は、処理部17のユーザ在席判断・在席
モード変換処理に対する、ユーザ在席情報検出の例であ
る。

【０４５２】図22の(a)は、情報処理装置211で制御可能
なカメラ222により、入力された映像を元に、ユーザが
近くにいるかどうかを検出する場合の例である。図22の
(b)は、情報処理装置224が、ユーザ226が携帯する情報
処理装置225が発信する情報227を検出することで、ユー
ザが近くにいるかどうかを検出する場合の例である。

【０４５３】以降、図22の(a)及び図56を用いて詳細に
説明する。

【０４５４】情報処理装置221で制御可能なカメラ222の
撮影範囲223の、撮影された映像情報がタスク受信部13
により受信され、映像の解析タスクとしてタスクテーブ
ル14に追加される。その後、タスク解析部15及びプラン
ニング決定部16を介して、映像を解析した結果、ユーザ
がいないことがわかり、新たにタスクをタスクテーブル
14に追加し、タスク解析部15及びプランニング決定部16
を介して、図53に示した処理実行部17のユーザ在席判断
・在席モード変換処理を起動する。

【０４５５】ユーザ在席判断・在席モード変換処理が起
動されると、ステップS5301、ステップS5304及びステッ
プS5307で在席情報を検出したと判断され、ステップS53
08及びステップS5309で、検出時の在席モードが「在
席」だったとすると、図56の検出情報「不在」及び検出
時のモード「在席」に対する在席モード変換の定義情報
5604を参照し、モード変換情報「離席」を取得する。

【０４５６】次のステップS5311で上記で取得されたモ
ード変換情報に矛盾が無いかどうか判断した結果、矛盾
がないのでステップS5313に進み、ユーザ存在情報に上
記で取得された在席モード変換情報「離席」をセット
し、続くステップS5314で後述する在席モード変換処理
により、在席モードに対応する処理を実行し、終了す
る。

【０４５７】その結果、図60の604に示した離席に対応
した処理が決定され、適切なタイミングで起動されるよ
う、タスクテーブル14に追加される。

【０４５８】（実施形態 39）ユーザが在席しているか
どうかを推論する処理の流れを説明する。

【０４５９】図57は、処理部17のユーザ在席判断・在席
モード変換処理から利用される、ユーザ在席推論処理の
流れを表すフローチャートである。

【０４６０】図58は、上記ユーザ在席推論処理により参
照される、ユーザ在席推論知識データの一例である。そ
れぞれのユーザ在席推論知識データには、推論知識が示
す状況に対する、推論結果であるモード変換情報が定義
されている。

【０４６１】図20は、上記ユーザ在席推論処理により、
ユーザのスケジュール情報202を参照し、ユーザが不在2
05であると推論した場合の例である。

【０４６２】操作部11により受け付けられたユーザの指
示操作や、受信情報や、検出情報は、タスク受信部13に
よってタスクテーブル14に追加され、タスク解析部15及
びプランニング決定部16を介して、図53に示した処理実
行部17のユーザ在席判断・在席モード変換処理が起動さ
れ、更にユーザ在席推論処理が起動される。

【０４６３】ユーザ在席推論処理が起動されると、まず
ステップS5701で一定時間が経過しているかどうか判断
される。この判断により、常に推論処理を行うことによ
る、処理効率の低下を避けることができる。

【０４６４】ここで、一定時間経過していないと判断さ
れた場合、ステップS5702に進み、モード変換情報に
「無処理」をセットして、終了する。

【０４６５】一方、一定時間経過していると判断された
場合、ステップS5703に進み、図58に示したユーザ在席
推論知識データを参照して、ユーザ在席推論処理実行時
の状況に対する、推論結果であるモード変換情報を取得
する。

【０４６６】続いて、ステップS5704で、上記推論が成
功したかどうか判断し、推論に成功した場合、ステップ
S5705に進み、モード変換情報に上記推論結果をセット
し、推論に失敗した場合、ステップS5706に進み、モー
ド変換情報に「不明」をセットして終了する。

【０４６７】以降、図20及び図58を用いて詳細に説明す
る。

【０４６８】ユーザ在席推測処理は、例えば、ユーザの
操作が一定時間無い場合に実行されるように指定された
タスクが、タスクテーブル14に格納されていた場合や、
他の情報処理装置2からユーザが在席しているかの問い
合せをタスク受信部13により受信し、対応するタスクを
タスクテーブル14に追加された場合などに、実行され
る。

【０４６９】そこで、タスク解析部15及びプランニング
決定部16を介して、図53に示した処理実行部17のユーザ
在席判断・在席モード変換処理及び、更に図57に示した
ユーザ在席推論処理が起動される。

【０４７０】ユーザ在席推論処理が起動され、ステップ
S5701で一定時間が経過していると判断された場合、ス
テップS5703に進み、図58に示したユーザ在席推論知識
データを参照して、ユーザ在席推論処理実行時の状況に
対する、推論結果であるモード変換情報を取得する。図
20の例の場合には、実行時の日付203が3/12であり、対
応するスケジュール202を参照すると、「新川崎に外
出」とあるので、図58の5807を参照し、「不在」である
と推論される。

【０４７１】続いて、ステップS5704で、上記推論が成
功したと判断されるので、ステップS5705に進み、モー
ド変換情報に上記推論結果をセットし、終了する。

【０４７２】（実施形態 40）ユーザ在席モード変換処
理の流れを説明する。

【０４７３】図59は、処理部17のユーザ在席判断・在席
モード変換処理から利用される、ユーザ在席モード変換
処理の流れを表すフローチャートである。

【０４７４】図60は、上記ユーザ在席モード変換処理に
より参照される、ユーザ在席モード変換データの一例で
ある。それぞれのユーザ在席モード変換データには、変
換後の在席モードと、対応して実行可能であると決定さ
れる処理の種類が定義されている。

【０４７５】図23から28は、上記ユーザ在席モード変換
処理により、実行可能であると決定された処理の例を表
したものである。

【０４７６】操作部11により受け付けられたユーザの指
示操作や、受信情報や、検出情報は、タスク受信部13に
よってタスクテーブル14に追加され、タスク解析部15及
びプランニング決定部16を介して、図53に示した処理実
行部17のユーザ在席判断・在席モード変換処理が起動さ
れ、更にユーザ在席モード変換処理が起動される。

【０４７７】ユーザ在席モード変換処理が起動される
と、まずステップS5901で在席変換モードが「無処理」
かどうか判断される。「無処理」が指定されている場
合、在席モードの変更にともなう処理を実行せずに、無
処理で終了する。

【０４７８】在席変換モードが「無処理」以外の場合、
ステップS5902に進み、図60のユーザ在席モード変換デ
ータを参照して、指定された在席変換モードに対応して
決定される処理の種類を取得する。続く、ステップS590
3で上記取得された処理に決定し、次のステップS5904で
必要な処理を実行した後、更に必要であればタスクテー
ブル14にタスクを追加した後、終了する。

【０４７９】例えば、在席変換モードが、「帰席」の場
合、図60のユーザ在席モード変換データを参照して、
「帰席」に対応して決定される処理の種類605を取得す
る。その結果、図26に示したような各種処理が、実行又
はタスクテーブル14への追加が行われる。

【０４８０】（実施形態 41）ユーザ在席場所表示処理
の流れを説明する。

【０４８１】図61は、処理部17のユーザ在席場所表示処
理の流れを表すフローチャートである。

【０４８２】図62は、上記ユーザ在席場所表示処理によ
り参照される、ユーザ在席場所情報の一例である。それ
ぞれのユーザ在席場所情報には、表示対象となるユーザ
のユーザ名と、在席場所が記憶されている。

【０４８３】図29は、上記ユーザ在席場所表示処理を用
いて、ユーザの在席場所を表示可能な、情報処理装置の
一例を表す図である。図29では、ＡさんとＢさんの在席
場所を、情報処理装置297が表示している一例を示した
ものである。

【０４８４】前述のように、図53に示した処理実行部17
のユーザ在席判断・在席モード変換処理により起動され
た、図59に示したユーザ在席モード変換処理により、変
更されたそれぞれのモードの処理により、ユーザの在席
情報が情報処理装置297に送信される。

【０４８５】例えば、図29の例の場合、東京の情報処理
装置293はＡさん291が近くにいることを検出し、情報処
理装置297に送信295している。また、大阪の情報処理装
置294はＢさん292が近くにいることを検出し、情報処理
装置297に送信296している。

【０４８６】一方、Ａさん291とＢさん292の在席情報29
5,296を、受信した情報処理装置297は、ユーザが指示し
た時に表示可能なように、それら在席情報を記憶して管
理する。

【０４８７】ここで、ユーザが情報処理装置297に対し
て、グループメンバー全員の在席情報の表示を指示する
と、操作部11により指示を受け付け、タスク受信部13に
より処理実行部17のユーザ在席場所表示処理タスクをタ
スクテーブル14に追加する。その後、タスク解析部15及
びプランニング決定部16を介して、処理実行部17のユー
ザ在席場所表示処理タスクが起動される。

【０４８８】ユーザ在席場所表示処理が起動されると、
まずステップS6101で図62のユーザ在席場所情報に記憶
された全ユーザを表示したかどうか、判断される。その
結果、全ユーザの表示を終えたと判断されたならば、終
了する。

【０４８９】一方、まだ表示していないユーザがあれ
ば、ステップS6102に進み、図62のユーザ在席場所情報
に記憶されたそれぞれのユーザの情報を取り出し、在席
場所が分かるかどうか判断される。在席場所が分からな
ければステップS6103に進み、「在席場所不明」と表示
し、在席場所が分かればステップS6104に進み、在席場
所を表示する。

【０４９０】その後、再びステップS6101に戻り、処理
を繰り返し、図29の298のような在席場所一覧が表示さ
れる。例えば、Ａさんの在席場所は、図62のユーザ在席
場所情報621を参照することで、「東京／ｘｘｘｘ」と
わかるので、図29のように表示されることになる。

【０４９１】（実施形態 42）次に、情報処理装置1で中
断された作業を、情報処理装置2で復帰させる例を説明
する。

【０４９２】図31は、ネットワーク等で接続された複数
の情報処理装置を利用可能なユーザが、情報処理装置1
での作業を中断して、情報処理装置2での作業を開始し
た時に、中断された情報処理装置1での作業を、情報処
理装置2で復帰させた時の例である。

【０４９３】前述のように、ユーザが情報処理装置311
で行った「離席」の指定操作の情報は、操作部11により
受け付けられ、タスク受信部13によってタスクテーブル
14に追加され、タスク解析部15及びプランニング決定部
16を介して、図53に示した処理実行部17のユーザ在席判
断・在席モード変換処理が起動され、そこでモードが
「在席」から「離席」に変更される。

【０４９４】この時、実行された離席処理により、離席
時のユーザの作業中の情報が記憶されると共に、情報処
理装置312にユーザが離席したという情報が在席情報313
として、送信される。

【０４９５】一方、同一ユーザが情報処理装置312で行
った「帰席」の指定操作の情報は、操作部11により受け
付けられ、タスク受信部13によってタスクテーブル14に
追加され、タスク解析部15及びプランニング決定部16を
介して、図53に示した処理実行部17のユーザ在席判断・
在席モード変換処理が起動され、そこでモードが「不
在」から「帰席」に変更される。

【０４９６】この時、実行された帰席処理により、以前
に同一ユーザが情報処理装置311から離席していること
が分かり、離席時のユーザの作業中の情報を情報処理装
置311から取得することで、異なる情報処理装置での作
業状態を復帰することができる。

【０４９７】この例では、情報処理装置312に帰席する
前に、情報処理装置311を離席していたので、情報処理
装置311の作業状態を復帰させたが、帰席する前にユー
ザがどこの情報処理装置も使用していなければ、以前に
情報処理装置312を離席した時の作業状態に復帰させ
る。

【０４９８】以上のように、本実施形態によれば、ネッ
トワーク等で接続された複数の情報処理装置を利用可能
なユーザが、情報処理装置1での作業を中断して、情報
処理装置2での作業を開始した時に、中断された情報処
理装置1での作業を、情報処理装置2で復帰させることが
可能であるだけでなく、その間他の情報処理装置を利用
していなければ利用しようとしている情報処理装置自身
の以前の作業状態を復帰させることを可能にしている。

【０４９９】次に、上記処理を実現する為の、遠隔作業
復帰処理の流れを説明する。

【０５００】図63は、本発明の処理部17の遠隔作業復帰
処理の流れを表すフローチャートである。

【０５０１】前述のように、ユーザが情報処理装置311
の近くを離席することで、図53に示した処理実行部17の
ユーザ在席判断・在席モード変換処理により起動され
た、図59に示したユーザ在席モード変換処理によって決
定された離席処理により、ユーザが離席したという在席
情報313が情報処理装置312に送信される。

【０５０２】その後、同一ユーザが情報処理装置312の
近くに帰席することで、図53に示した処理実行部17のユ
ーザ在席判断・在席モード変換処理により起動された、
図59に示したユーザ在席モード変換処理によって決定さ
れた帰席処理により、図63の遠隔作業復帰処理が起動さ
れる。

【０５０３】遠隔作業復帰処理が起動されると、まずス
テップS6301で、帰席したユーザと同じユーザの離席情
報を受信したことがあるか、チェックされる。

【０５０４】その結果、離席情報を受信したことがあれ
ば、ステップS6302に進み、受信したことがなければ、
ステップS6305に進み、本情報処理装置自身が持ってい
る以前ユーザが離席した時の作業情報を元に復帰し、終
了する。

【０５０５】ステップS6302では、以前に受信した離席
情報の発信元に、離席時のユーザの作業状態の情報の送
信を依頼し、離席時の作業情報を受信する。その結果、
ステップS6303で作業情報の受信が成功したと判断され
た場合、ステップS6304に進み、失敗したと判断された
場合、ステップS6305に進む。

【０５０６】ステップS6304では、受信した作業情報を
元に、ユーザの離席時の作業状態を復帰し、終了する。
図31の例では、ユーザの離席時に、情報処理装置311は
作業状態314を記憶すると共に、離席したという在席情
報313を、情報処理装置312に送信しているので、情報処
理装置312にユーザが帰席した場合には、ステップS6301
で以前に離席したという在席情報を受信していたと判断
される。その結果、ステップS6302で離席時の作業状態3
14を受信し、ステップS6304でその作業状態に復帰し、
終了する。

【０５０７】この時、どこからも離席したという在席情
報を受信していなかったとすると、ステップS6305に進
み、本情報処理装置312をユーザが以前に使っていた離
席時の状態に、作業情報を復帰して終了する。

【０５０８】（実施形態43）次に、状況に応じた最適な
情報の通知を行なう例を説明する。

【０５０９】図33は、状況に応じた最適な情報の通知を
行った時の一例である。

【０５１０】図33の例では、受信したＥｍａｉｌ3301か
らスケジュール情報を抽出し、スケジュール3302に記憶
されている以前からのスケジュールとの重複を検出3303
している。

【０５１１】そこで、個人情報3305を参照しながら、優
先度評価の知識3306に従って、用件の優先度を評価3304
してユーザに問い合せている3309。

【０５１２】その後、ユーザの応答3310を受け取り、指
示に従って、応答3311、スケジュールの更新3312、新し
いプランの学習3314、第三者への連絡などその他処理33
13を実行する。

【０５１３】この時、後述の処理実行部17の思い出し処
理により、ユーザの To Do Listに記憶されている情報3
307を参照し、同じ下丸子で可能な仕事をピックアップ
し、上記応答3311で同時にユーザに思い出させる為に通
知している。

【０５１４】図64は、上記処理を実現する為の、処理実
行部17の思い出し処理の流れの一例を示したフローチャ
ートである。

【０５１５】上記のように、処理実行部17のスケジュー
ル更新3312等の処理が実行されると同時に、本実施形態
の重要要素である、思い出し処理が実行される。

【０５１６】このように、本実施形態によれば、状況に
応じてユーザが思い出した方が良い、関連する情報を通
知することで、ユーザの操作性を飛躍的に向上させよう
としている。

【０５１７】次に、図64のフローチャートを参照して、
処理の流れを説明する。

【０５１８】図64は、上記処理を実現する為の、処理実
行部17の思い出し処理の流れの一例を示すフローチャー
トである。

【０５１９】図33の例では、受信したＥｍａｉｌ3301か
らスケジュール情報を抽出し、スケジュール3302に記憶
されている以前からのスケジュールとの重複を検出3303
している。

【０５２０】そこで、個人情報3305を参照しながら、優
先度評価の知識3306に従って、用件の優先度を評価3304
してユーザに問い合せている3309。

【０５２１】その後、ユーザの応答3310を受け取り、指
示に従って、応答3311、スケジュールの更新3312、新し
いプランの学習3314、第三者への連絡などその他処理33
13を実行する。

【０５２２】この時、後述の処理実行部17の思い出し処
理により、ユーザの To Do Listに記憶されている情報3
307を参照し、同じ下丸子で可能な仕事をピックアップ
し、上記応答3311で同時にユーザに思い出させる為に通
知している。

【０５２３】以降、処理実行部17のスケジュール更新33
12等の処理が実行されると同時に、思い出し処理が実行
された場合の具体的な処理の流れについて説明する。

【０５２４】処理実行部17が起動されると、ステップS6
41で処理内容を解析し、続くステップS642で処理実行部
17内部の処理だけで完結すると判断された場合にはステ
ップS643に進み、処理実行部17外部の処理が必要と判断
された場合にはステップS645に進む。

【０５２５】ステップS643では、処理内容に対応した処
理を実行し、続くステップS644で処理実行部17内履歴情
報に処理内容の情報等を追加する。この処理実行部17内
履歴情報を利用することで、取り消したり(UNDO)、繰り
返したり(REDO)することが可能になる。その後、再びス
テップS641に戻り、残る処理を続行する。

【０５２６】一方、ステップS642で処理実行部17外部の
処理が必要と判断された場合にはステップS645に進み、
実行された処理に対応するタスクに指定された元履歴番
号が、履歴を残すことを意味する有効な元履歴番号かど
うかチェックし、履歴を残すかどうか判断する。

【０５２７】その結果、履歴を残すと判断された場合に
はステップS646に進み、履歴情報管理部18を介して、履
歴情報19に処理内容を追加し、履歴番号を取得する。続
くステップS647では、ステップS646で履歴情報を追加し
た場合には履歴情報管理部18から返された履歴番号を、
タスクの元履歴番号にセットして、タスクテーブル14に
追加する。一方、ステップS645で履歴を残す必要が無い
と判断された場合には、履歴を残す必要が無いという意
味で、タスクの元履歴番号として無効値をセットして、
タスクテーブル14に追加する。

【０５２８】上記説明した流れによりスケジュール更新
処理実行後、ステップS648で上記処理に関連する情報
が、To Do Listやスケジュールにあるかどうかチェック
し、あればステップS649でユーザへの思い出しの為の通
知タスクをタスクテーブル14に追加して、終了する。

【０５２９】図33の例の場合、場所が同じ下丸子で可能
な仕事、「加藤さんと打合せ」について通知するタスク
がタスクテーブル14に追加される。

【０５３０】図25の離席処理の例の場合、現在の時刻25
3の示す14:50と、ユーザ251のスケジュール「15:00 チ
ーフミーティング」を比較し、ユーザの離席の理由がミ
ーティングに参加する為のものであれば問題無いが、そ
れ以外の場合忘れている危険があることを理解する。そ
こで、ユーザ251に「15:00からA111会議室で、チーフミ
ーティングです」254と通知するタスクをタスクテーブ
ル14に追加する。

【０５３１】また、上述の例では、場所が一致するもの
や時間の近いものを通知したが、相手が一致する行動
（会議に出席する際に、会議の内容とは別に、出席者の
1人にたずねるべき質問)や、時間が連続する行動（会議
に出席する際に、その会議に続いて出席するべき別の会
議）などを通知するようにしてもよい。

【０５３２】（実施形態44）図35は、ユーザが保留指示
を行ったという状況に応じて最適なタスクの追加・記憶
を行った時の一例である。

【０５３３】図35の例では、情報処理装置351に表示さ
れたメール一覧352から、メール「3/3 10:29:30 from i
chiro」353を指定して、メールの内容を表示354した状
態で、そのメールに対する参照や修正やその他の操作を
中断する為にHOLD355を押した場合について表してい
る。

【０５３４】本実施形態によれば、図35の356のよう
に、To Do Listに「ichiroさんから来たメールを読む」
という、作業再開のタスクが追加・記憶される。

【０５３５】図65は、上記処理を実現する為の、処理実
行部17の保留処理の流れの一例を示したものである。

【０５３６】上記のように、処理実行部17のメール参照
354等の処理の実行中に、保留指示を行うと、本実施形
態の重要要素である、保留処理が実行され、ユーザのTo
DoList等にタスクが追加される。

【０５３７】このように、本実施形態によれば、ユーザ
が保留指示を行ったという、状況に応じて最適なタスク
の追加・記憶を行うことで、ユーザの操作性を飛躍的に
向上させようとしている。

【０５３８】図65は、上記処理を実現する為の、処理実
行部17の保留処理の流れの一例を示したフローチャート
である。

【０５３９】図35は、ユーザが保留指示を行ったとい
う、状況に応じて最適なタスクの追加・記憶を行った時
の一例である。

【０５４０】図35の例では、情報処理装置351に表示さ
れたメール一覧352から、メール「3/3 10:29:30 from i
chiro」353を指定して、メールの内容を表示354した状
態で、そのメールに対する参照や修正やその他の操作を
中断する為にHOLD355を押した場合について表してい
る。

【０５４１】本実施形態によれば、図35の356のよう
に、To Do Listに「ichiroさんから来たメールを読む」
という、作業再開のタスクが追加・記憶される。

【０５４２】以降、処理実行部17のメール参照354等の
処理が実行されると同時に、保留処理が実行された場合
の具体的な処理の流れについて説明する。

【０５４３】処理実行部17が起動されると、ステップS6
51で処理内容を解析し、続くステップS652で処理実行部
17内部の処理だけで完結すると判断された場合にはステ
ップS653に進み、処理実行部17外部の処理が必要と判断
された場合にはステップS655に進む。

【０５４４】ステップS653では、処理内容に対応した処
理を実行し、続くステップS654で処理実行部17内履歴情
報に処理内容の情報等を追加する。この処理実行部17内
履歴情報を利用することで、取り消したり(UNDO)、繰り
返したり(REDO)することが可能になる。

【０５４５】その後、再びステップS651に戻り、残る処
理を続行する。

【０５４６】一方、ステップS652で処理実行部17外部の
処理が必要と判断された場合にはステップS655に進み、
実行された処理に対応するタスクに指定された元履歴番
号が、履歴を残すことを意味する有効な元履歴番号かど
うかチェックし、履歴を残すかどうか判断する。

【０５４７】その結果、履歴を残すと判断された場合に
はステップS656に進み、履歴情報管理部18を介して、履
歴情報19に処理内容を追加し、履歴番号を取得する。

【０５４８】続くステップS657では、ステップS656で履
歴情報を追加した場合には履歴情報管理部18から返され
た履歴番号を、タスクの元履歴番号にセットして、タス
クテーブル14に追加する。一方、ステップS655で履歴を
残す必要が無いと判断された場合には、履歴を残す必要
が無いという意味で、タスクの元履歴番号として無効値
をセットして、タスクテーブル14に追加する。

【０５４９】上述した流れによりメール参照処理実行
後、ステップS658でユーザが保留を指示したと判断され
たならば、ステップS659で上記処理を再開する為のタス
クを、ユーザのTo Do List等に追加して、終了する。

【０５５０】図35の例の場合、ichiroさんからのＥｍａ
ｉｌを参照中に、保留を指示したので、「ichiroさんか
ら来たメールを読む」というタスクが、ユーザのTo Do
Listに追加される。

【０５５１】図66は、本実施形態に係わる、状況に応じ
て最適なタスクを追加・記憶することが可能な情報処理
装置の全体構成図である。

【０５５２】スキャナー6605、音声6606、電話6607、Ｅ
ｍａｉｌ6608、ＦＡＸ6609など、各種入力デバイスから
の入力を、入力解析部6602により解析し、検索、編集、
参照、削除等の処理6603を実行し、必要に応じて出力を
生成6604し、ファイル6610、印刷6611、Ｅｍａｉｌ661
2、ＦＡＸ6613など、各種出力デバイスへの出力を実行
する。

【０５５３】上記入力、解析、処理、生成、出力の各過
程で、実行された処理により、必要と推論される処理を
タスクテーブル14に追加し、またユーザに関連するタス
クならば、ユーザが認識可能なTo Do List等にタスクと
して追加する。

【０５５４】このようにして、状況に応じて最適なタス
クを追加・記憶することができる。

【０５５５】図67は、本実施形態に係わる、状況に応じ
て最適なタスクを追加・記憶することが可能な情報処理
装置の操作画面の一例である。

【０５５６】図67では、Ｅｍａｉｌ一覧表示指示6702、
Ｅｍａｉｌ概要表示6703、時計6704、ヘルプ6705、ニュ
ース表示6706〜6708、スケジュール6709、住所録6710、
キャビネット6711、ファイリング6712、各種情報の検索
6713、保留6714、メモ6715、各種情報表示・操作6716、
読み込み6717、新規作成6718、送信6719、印刷6720、電
話6721、その他アプリケーションの起動6722〜6723、通
知情報表示6724、自然言語入力6725、音声操作6726、音
声応答6727、削除6728、終了6729等の、各種操作ボタン
などが表示されている。

【０５５７】上記指示操作により、実行された処理また
は指示そのものにより、必要と推論される処理をタスク
テーブル14に追加し、またユーザに関連するタスクなら
ば、ユーザが認識可能なTo Do List等にタスクとして追
加する。

【０５５８】このように、上記各種の処理について、状
況に応じて最適なタスクを追加・記憶することができ
る。

【０５５９】（実施形態45）図37は、ファイルの各種属
性を元にしたダイナミックなツリー表示を行うと共に、
表示上の移動・複写にともなってファイルの各種属性を
更新する為の処理、インデックス自動付与移動・複写処
理を行った時の一例である。

【０５６０】図37の例では、スキャナ371で読み込まれ
たファイル「1997.4.5 file-abc」372に、ユーザの入力
指示操作又は読み込まれた画像の所定の位置に書き込ま
れた文字やコードを読み取ることで、キーワード373を
付与する。

【０５６１】上記のような手順により、情報処理装置37
4で記憶・管理されたファイルの一覧を、375のようなキ
ーワードによる自由なツリー表示で、表示される。

【０５６２】その後、ユーザが、表示されているファイ
ルの中から、「1997.4.5 file-abc」を指定し、移動又
は複写指示376の操作を行うと、377のように移動又は複
写先のキーワードがファイル「1997.4.5 file-abc」に
追加される。

【０５６３】図68は、上記処理を実現する為の、処理実
行部17のインデックス自動付与移動・複写処理の流れの
一例を示したフローチャートである。

【０５６４】上記のように、図37のキーワード・ツリー
375で、移動・複写操作を行うだけで、移動・複写先の
キーワードなどの属性を追加することができる。

【０５６５】このように、本実施形態によれば、ファイ
ルの各種属性を元にしたダイナミックなツリー表示を行
うと共に、表示上の移動・複写にともなってファイルの
各種属性を更新することで、ユーザの操作性を飛躍的に
向上させようとしている。

【０５６６】次に、図68のフローチャートを参照して、
処理の流れを詳細に説明する。

【０５６７】図68は、上記処理を実現する為の、処理実
行部17のインデックス自動付与移動・複写処理の流れの
一例を示したものである。

【０５６８】図37は、ファイルの各種属性を元にしたダ
イナミックなツリー表示を行うと共に、表示上の移動・
複写にともなってファイルの各種属性を更新する為の処
理、インデックス自動付与移動・複写処理を行った時の
一例である。

【０５６９】図37の例では、スキャナ371で読み込まれ
たファイル「1997.4.5 file-abc」372に、ユーザの指示
操作又は自動的抽出することで、373のようなキーワー
ドを付与する。

【０５７０】上記のような手順により、情報処理装置37
4で記憶・管理されたファイルの一覧を、375のようなキ
ーワードによる自由なツリー表示で、表示される。

【０５７１】その後、ユーザが、表示されているファイ
ルの中から、「1997.4.5 file-abc」を指定し、移動又
は複写指示376の操作を行うと、377のように移動又は複
写先のキーワードがファイル「1997.4.5 file-abc」に
追加される。

【０５７２】以降、処理実行部17のインデックス自動付
与移動・複写処理の具体的な処理の流れについて説明す
る。

【０５７３】インデックス自動付与移動・複写処理が起
動されると、まずステップS681でユーザが移動又は複写
を指定した元ファイルを取得する。続くステップS682で
ユーザが指定した元ファイルと、移動又は複写先が有効
かどうかチェックされ、有効な場合ステップS683に進
み、無効な場合ステップS688でエラー表示を行った後、
終了する。

【０５７４】ステップS683では、移動又は複写先のイン
デックスを取得し、続くステップS684で取得されたイン
デックスを元ファイルのインデックスに追加する。

【０５７５】次のステップS685では、実際に移動又は複
写先にファイルを格納し、続くステップS686でユーザが
移動を指定していたかどうかがチェックされ、移動を指
定していた場合にはステップS687に進み、元ファイルを
削除して終了する。

【０５７６】図37の例の場合、移動又は複写元ファイル
は、「1997.4.5 file-abc」であり、そのファイルが元
々持っていたキーワード又はインデックス情報「請求
書、1997年」373に、移動又は複写先のキーワード又は
インデックス情報「他社情報、Ｂ社」を追加し、377の
ようなキーワード又はインデックス情報に更新する。

【０５７７】上記処理により、ユーザは記憶・管理され
ているファイルの全体像を眺めながら、必要なキーワー
ドを追加・削除・更新することが可能であり、ユーザの
操作性を著しく向上させることが可能である。

【０５７８】（実施形態46）図69は、異なるファイル形
式間の移動・複写も可能にする為の処理である異形式フ
ァイル混在処理を行った時の一例である。

【０５７９】図69の例では、692のような画像形式のフ
ァイル管理と、693のようなテキスト形式のファイル管
理のような複数の異なるファイル形式で記憶・管理され
た可能な情報処理装置691において、ファイルの一覧を
ツリー表示で表示している。

【０５８０】その後、ユーザが、表示されているファイ
ルの中から、「file-abc」を指定し、移動又は複写指示
694の操作を行うと、移動又は複写元のファイル形式で
あるテキスト形式から、移動又は複写先のファイル形式
である画像情報形式に、変換後、「1997.4.5 file-ab
c」に移動又は複写される。

【０５８１】図70は、上記処理を実現する為の、処理実
行部17の異形式ファイル混在処理の流れの一例を示した
ものである。

【０５８２】上記のように、図69の操作画面で移動・複
写操作を行うだけで、移動・複写先のファイル形式に変
換することができる。

【０５８３】このように、本実施形態によれば、異なる
ファイル形式間の移動・複写を可能にすることで、ユー
ザの操作性を飛躍的に向上させようとしている。

【０５８４】次に、図70のフローチャートを用いて、処
理の流れについて説明述する。

【０５８５】図70は、上記処理を実現する為の、処理実
行部17の異形式ファイル混在処理の流れの一例を示すフ
ローチャートである。

【０５８６】図69は、異なるファイル形式間の移動・複
写も可能にする為の処理、異形式ファイル混在処理を行
った時の一例である。

【０５８７】図69の例では、692のような画像形式のフ
ァイル管理と、693のようなテキスト形式のファイル管
理のような複数の異なるファイル形式で記憶・管理され
た可能な情報処理装置691において、ファイルの一覧を
ツリー表示で表示している。

【０５８８】その後、ユーザが、表示されているファイ
ルの中から、「file-abc」を指定し、移動又は複写指示
694の操作を行うと、移動又は複写元のファイル形式で
あるテキスト形式から、移動又は複写先のファイル形式
である画像情報形式に、変換後、「1997.4.5 file-ab
c」に移動又は複写される。

【０５８９】以降、処理実行部17の異形式ファイル混在
処理の具体的な処理の流れについて説明する。

【０５９０】異形式ファイル混在処理が起動されると、
まずステップS701でユーザが移動又は複写を指定した元
ファイルを取得する。続くステップS702でユーザが指定
した元ファイルと、移動又は複写先が有効かどうかチェ
ックされ、有効な場合ステップS703に進み、無効な場合
ステップS708でエラー表示を行った後、終了する。

【０５９１】ステップS703では、移動又は複写先のファ
イル形式などのフォーマットを取得し、続くステップS7
04で取得されたフォーマットに元ファイルを変換する。

【０５９２】次のステップS705では、実際に移動又は複
写先にファイルを格納し、続くステップS706でユーザが
移動を指定していたかどうかがチェックされ、移動を指
定していた場合にはステップS707に進み、元ファイルを
削除して終了する。

【０５９３】図37の例の場合、移動又は複写元ファイル
は、「file-abc」であり、そのファイルが元々のファイ
ル形式はテキストフォーマットである。一方、移動又は
複写先のファイル形式は画像情報フォーマットなので、
ステップS704でファイルを変換した後、移動又は複写を
実行する。

【０５９４】上記処理により、ユーザは記憶・管理され
ているファイルの全体像を眺めながら、必要なファイル
のフォーマットの変換を実行させることが可能であり、
ユーザの操作性を著しく向上させることが可能である。

【０５９５】なお、本発明は、上記実施形態の機能が実
現できる範囲において、複数の機器（例えばコンピュー
タ本体、インターフェイス機器、ディスプレイなど）か
ら構成されるシステムに適用しても、単一の機器からな
る装置に適用してもよい。

【０５９６】また、前述した実施形態の機能を実現する
ように各種デバイスを動作させることを目的として、該
各種デバイスと接続された装置あるいはシステム内のコ
ンピュータに、前述した実施形態の機能を実現するソフ
トウェアのプログラムコードを供給し、供給されたプロ
グラムにしたがって、そのシステムあるいは装置のコン
ピュータ（またはＣＰＵやＭＰＵ）により、前記各種デ
バイスを動作させることによって実施したものも、本願
発明の範囲に含まれる。またこの場合、記憶媒体から読
み出されたプログラムコード自体が前述した実施形態の
機能を実現することになり、そのプログラムコード自
体、そのプログラムコードをコンピュータに供給する手
段、例えばかかるプログラムコードを記憶した記憶媒体
は、本発明を構成することになる。

【０５９７】かかるプログラムコードを供給する為の記
憶媒体としては、例えば、フロッピーディスク、ハード
ディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯ
Ｍ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、
ＲＯＭ等を使用できる。

【０５９８】また、コンピュータが読み出したプログラ
ムコードを実行することにより、前述した実施形態の機
能が実現されるだけでなく、そのプログラムコードの指
示に基づき、コンピュータ上で稼動しているＯＳ（オペ
レーティングシステム）、あるいは他のアプリケーショ
ンソフトなどと協働して前述の実施形態の機能が実現さ
れる場合にも、かかるプログラムコードは本願発明の範
囲に含まれることは言うまでもない。

【０５９９】更に、記憶媒体から読み出されたプログラ
ムコードが、コンピュータに挿入された機能拡張ボード
やコンピュータに接続された機能拡張ユニットに備わる
メモリに書き込まれた後、そのプログラムコードの指示
に基づき、その機能拡張ボードや機能拡張ユニットに備
わるＣＰＵ等が実際の処理の一部または全部を行い、そ
の処理によって前述した実施形態の機能が実現される場
合も含まれることは言うまでもない。

【０６００】本願発明を上記記憶媒体に適用する場合、
その記憶媒体には、先に説明したフローチャートに対応
するプログラムコードを格納すればよい。

【０６０１】

【発明の効果】以上説明したように、本発明によれば、
状況に応じた適切な通知を行なうことができるという効
果がある。

【０６０２】また、ユーザがあらかじめ通知時刻を指定
する必要がなくなり、操作性が向上する。ユーザが席を
離れるときに通知するなど、時刻以外の通知条件を利用
することで、状況に応じて柔軟な通知を行なうことがで
きる。

【図面の簡単な説明】

【図１】実施形態の機能構成を示す図である。

【図２】実施形態の各装置のハードウェア構成を表す図
である。

【図３】実施形態の全体処理の流れを示したフローチャ
ートである。

【図４】タスクテーブルの一例を表す図である。

【図５】履歴情報の一例を表す図である。

【図６】システム構成の一例を示す図である。

【図７】従来技術を説明する図である。

【図８】通信先との通信状況に応じて、操作手順を決定
する例を説明する図である。

【図９】本来の処理以外の処理の操作手順を提供する例
を説明する図である。

【図１０】優先度に応じて、出力態様を決定・更新する
例を表す図である。

【図１１】内容の優先度に応じて、出力態様を決定・更
新する例を表す図である。

【図１２】タスク及び人物の優先度に応じて、出力態様
を決定・更新する例を表す図である。

【図１３】タスク及び人物の地位の優先度に応じて、出
力態様を決定・更新する例を表す図である。

【図１４】タスクとの関係度に応じて、出力態様を決定
・更新する例を表す図である。

【図１５】緊急度に応じて、出力態様を決定・更新する
例を表す図である。

【図１６】処理対象項目数による、１項目当りの情報量
の変化の例を表した図である。

【図１７】処理対象の情報量に応じて、処理方法を決定
・更新する例を表す図である。

【図１８】従来技術を説明する図である。

【図１９】ユーザによる在席指示に対応して実行される
処理を決定する例を表す図である。

【図２０】在席かどうかを推測して実行される処理を決
定する例を表す図である。

【図２１】在席情報を受信して、ユーザが在席している
かを判断する例を表す図である。

【図２２】在籍状態を検出して、ユーザが在席している
かを判断する例を表す図である。

【図２３】ユーザが在席していると判断された場合の処
理例を示した図である。

【図２４】ユーザが不在だと判断された場合の処理例を
示した図である。

【図２５】ユーザが離席しようとしていると判断された
場合の処理例を示した図である。

【図２６】ユーザが帰席したと判断された場合の処理例
を示した図である。

【図２７】ユーザが在席しているかどうか不明であると
判断された場合の処理例を示した図である。

【図２８】ユーザが在席しているかどうかに矛盾がある
と判断された場合の処理例を示した図である。

【図２９】ユーザの在席場所を表示する例を示した図で
ある。

【図３０】従来技術を説明する図である。

【図３１】情報処理装置1で中断された作業を、情報処
理装置2で復帰させた例を説明する図である。

【図３２】従来技術を説明する図である。

【図３３】状況に応じた最適な情報の通知を行った時の
一例を説明する図である。

【図３４】従来技術を説明する図である。

【図３５】ユーザが保留指示を行ったという状況に応じ
て最適なタスクの追加・記憶を行った時の一例を表す図
である。

【図３６】従来技術を説明する図である。

【図３７】インデックス自動付与移動・複写処理を行っ
た時の例を表す図である。

【図３８】操作部の処理の流れを表すフローチャートで
ある。

【図３９】操作画面の一例を表す図である。

【図４０】音声により指示をした場合の一例を表す図で
ある。

【図４１】タスク受信部の処理の流れを表すフローチャ
ートである。

【図４２】処理実行部の処理の流れを表すフローチャー
トである。

【図４３】通信状況対応処理の流れの一例を示すフロー
チャートである。

【図４４】操作情報の一例を表す図である。

【図４５】定型処理外命令対応処理の流れの一例を示す
フローチャートである。

【図４６】優先度・項目数対応処理の流れの一例を示す
フローチャートである。

【図４７】処理対象項目の一例を表した図である。

【図４８】優先度取得処理の流れの一例を示すフローチ
ャートである。

【図４９】緊急度から優先度を求める為の定義の一例を
表した図である。

【図５０】地位・役職・ユーザとの関係から優先度を求
める為の定義の一例を表した図である。

【図５１】優先度に応じた強調表示方法を定義した情報
の一例を示す図である。

【図５２】検索対象数対応処理の流れを示すフローチャ
ートである。

【図５３】ユーザ在席判断・在席モード変換処理の流れ
を表すフローチャートである。

【図５４】ユーザの指示に対する在席モード変換の定義
の一例を表した図である。

【図５５】受信情報に対する在席モード変換の定義の一
例を表した図である。

【図５６】検出結果に対する在席モード変換の定義の一
例を表した図である。

【図５７】ユーザ在席推論処理の流れを表すフローチャ
ートである。

【図５８】ユーザ在席推論知識データの一例を表した図
である。

【図５９】ユーザ在席モード変換処理の流れを表すフロ
ーチャートである。

【図６０】ユーザ在席モード変換データの一例を示す図
である。

【図６１】ユーザ在席場所表示処理の流れを表すフロー
チャートである。

【図６２】ユーザ在席場所情報の一例を示す図である。

【図６３】遠隔作業復帰処理の流れの一例を示すフロー
チャートである。

【図６４】思い出し処理の流れの一例を示すフローチャ
ートである。

【図６５】保留処理の流れの一例を示したフローチャー
トである。

【図６６】状況に応じて最適なタスクを追加・記憶可能
な情報処理装置の全体構成を示す図である。

【図６７】操作画面の一例を示す図である。

【図６８】インデックス自動付与移動・複写処理の流れ
を表すフローチャートである。

【図６９】異形式ファイル混在処理を行った例を表す図
である。

【図７０】異形式ファイル混在処理の流れを表すフロー
チャートである。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 茨木 正一 東京都大田区下丸子３丁目30番２号キヤノ ン株式会社内 (72)発明者 須田 アルナ・ローラ 東京都大田区下丸子３丁目30番２号キヤノ ン株式会社内

Claims (20)

【特許請求の範囲】
1. 【請求項１】 所定の通知条件が満足されたか否かを判
   定する判定手段と、 該判定手段により前記通知条件が満足されたと判定され
   た場合に、ユーザが実行すべき事柄を通知する通知手段
   とを有することを特徴とする情報処理装置。
2. 【請求項２】 前記所定の通知条件が時刻に関する情報
   であることを特徴とする請求項１に記載の情報処理装
   置。
3. 【請求項３】 前記所定の通知条件が、前記事柄を実行
   すべき時刻と現在の時刻との差であることを特徴とする
   請求項２に記載の情報処理装置。
4. 【請求項４】 前記通知手段が、前記差の値に応じて通
   知内容を決定する決定手段を含むことを特徴とする請求
   項３に記載の情報処理装置。
5. 【請求項５】 前記所定の通知条件が、ユーザの離席の
   時点であることを特徴とする請求項１に記載の情報処理
   装置。
6. 【請求項６】 前記所定の通知条件が場所に関する情報
   であることを特徴とする請求項１に記載の情報処理装
   置。
7. 【請求項７】 前記所定の通知条件が、前記事柄を実行
   すべき場所とユーザの行き先との関連性であることを特
   徴とする請求項６に記載の情報処理装置。
8. 【請求項８】 前記所定の通知条件が人物に関する情報
   であることを特徴とする請求項１に記載の情報処理装
   置。
9. 【請求項９】 前記所定の通知条件が、前記事柄に係わ
   る人物とユーザの会う人物との関連性であることを特徴
   とする請求項８に記載の情報処理装置。
10. 【請求項１０】 前記所定の通知条件がスケジュールの
    更新であることを特徴とする請求項１に記載の情報処理
    装置。
11. 【請求項１１】 所定の通知条件が満足されたか否かを
    判定する判定工程と、 該判定工程により前記通知条件が満足されたと判定され
    た場合に、ユーザが実行すべき事柄を通知する通知工程
    とを有することを特徴とする情報処理方法。
12. 【請求項１２】 前記所定の通知条件が時刻に関する情
    報であることを特徴とする請求項１１に記載の情報処理
    方法。
13. 【請求項１３】 前記所定の通知条件が、前記事柄を実
    行すべき時刻と現在の時刻との差であることを特徴とす
    る請求項１２に記載の情報処理方法。
14. 【請求項１４】 前記通知工程が、前記差の値に応じて
    通知内容を決定する決定工程を含むことを特徴とする請
    求項１３に記載の情報処理方法。
15. 【請求項１５】 前記所定の通知条件が、ユーザの離席
    の時点であることを特徴とする請求項１１に記載の情報
    処理方法。
16. 【請求項１６】 前記所定の通知条件が場所に関する情
    報であることを特徴とする請求項１１に記載の情報処理
    方法。
17. 【請求項１７】 前記所定の通知条件が、前記事柄を実
    行すべき場所とユーザの行き先との関連性であることを
    特徴とする請求項１６に記載の情報処理方法。
18. 【請求項１８】 前記所定の通知条件が人物に関する情
    報であることを特徴とする請求項１１に記載の情報処理
    方法。
19. 【請求項１９】 前記所定の通知条件が、前記事柄に係
    わる人物とユーザの会う人物との関連性であることを特
    徴とする請求項１８に記載の情報処理方法。
20. 【請求項２０】 前記所定の通知条件がスケジュールの
    更新であることを特徴とする請求項１１に記載の情報処
    理方法。