Calendar management method

【発明の詳細な説明】 Ａ． 産業上の利用分野 本発明は予定表管理方法（予定表法）に関し、更に詳しくは、予定されている行事（催事）をサポートするための資源（会議室や備品、設備等）の使用可能性が、行事（催事）を予定する時に、自動的に確認されるという電子式予定表管理方法に関するものである。

Ｂ． 参照出願 １． 「対話方式下で入力された基準に基づいて他の複数の異なる電子式予定表からの予定項目を同時に表示するための方法（Method For Concurrently Displaying Ent
ries From a Plurality of Different Electronic Cale
ndars Based on Interactively Entered Criteria）」
に関する本出願人の同時係属特許出願（社内整理番号Ａ
Ｔ−９−８６−０４６）は、対話方式下でシステムに入力されたデータによって予定主が特定した相互関係を有する他の異なる予定表からの一組の予定項目を予定主が表示できる電子式予定表管理方法に関するものである。

２． 「予定事項および処理に対する予定表管理浮動トリガを設定するための電子式予定表管理方法（Electronic
Calendaring Method to Establish Calendar Floating
Triggers for Calendared Events and Processes）」
に関する同時係属特許出願（ＡＴ−９−８６−０４３）
は、予定主が定義済みアクションを選択的にトリガすることができ、事前に定義されてシステムに入力された予定事項に関連する１つまたは複数の基準の検出に応答することができる電子式予定表管理方法に関するものである。

３． 「別々に維持された電子式予定表の２つのコピー上の項目を自動的に調整するための方法（Method For Aut
omatically Reconciling Entries on Two Copies of In
dependently Maintained Electronic Calendars）」に関する同時係属特許出願（ＡＴ−９−８６−０４８）
は、自分の主予定表（マスタ・予定表）の分離した個人用コピーを保持する予定主が、分離したコピーが最後に作成されて以来互いに独立に各予定表コピー上に作成された予定項目を自動的に調整することができ、かつ予定行事の衝突を対話方式下で解決することができる電子式予定表管理方法に関するものである。

４． 「対話型電子式予定表管理システムにおける自動回答発生方法（Method For Developing Automatic Replie
s in an Interactive Electronic Calendaring Syste
m）」に関する同時係属特許出願（ＡＴ−９−８６−０
４４）は、予定主が他の予定主から出席要求された予定事項に対して自動回答する方法を示している。 回答の内容は、出席を要求した予定主の要求内容中のパラメータを分析して定まり、その際には予め確立されている優先度が考慮される。

５． 「参加要請された行事への代理人の自動指名を行なう電子式予定表管理方法（Electronic Calendaring Met
hod Which Provides For Automatic Assignment of Alt
ernates In Requested Events）」に関する同時係属特許出願（ＡＴ−９−８６−０４９）は、別の予定主が作成した予定行事への参加要求を受け取った予定主が、その参加要求に付随する情報と、潜在的な各代理人に対して予定主が事前に設定した基準との関係に基づいて、その予定行事への代理人の指名を示す自動回答を作成できる電子式予定表管理方法に関するものである。

Ｃ． 従来の技術 従来技術は種々の対話式予定表管理システムおよび方法を開示している。 これら全てのシステムの第一義的目的は、将来の行事に関する種々の情報をその行事の時期と関連させて記入（入力）するような行事の予定表を利用する人（通常は予定主である。）を、何らかの意味で、
支援することである。

最近のパーソナル・コンピュータおよび知能ワークステーションの増加により、予定主がこられの対話型データ処理システム上で自分の予定を確立し、維持（メンテナンス）することが可能になった。

大別して２種の対話式予定管理システムが既に発展している。 一方の種類の予定表管理システムでは、予定主は一般にワークステーションのユーザでもあり、そのワークステーションは一般に大きなネットワークの一部ではない。 一般的に、こうした種類のシステムでは、予定表管理機能は、一日が複数の時間期間即ちタイム・スロットに分割された予定表を表す画面をユーザに提示する。

各期間には、ユーザが入力した一定量のテキストを表示することができる。 ある種のシステムでは、日毎の予定表は垂直に画面移動して、一層多くの時間期間をユーザに提示したり、水平に画面移動して、一層長いテキスト項目を提示することができる。 操作員は一般に前進または後退「ページング」を行なうことができ、大部分の機構では、要求されたデータを表示することができる。 こうした予定表管理機構は一般に、予定される行事の種類や入力時点で使用される用語を制限せず、その限りで、
通常の（電子式でない）予定表やアポイントメント・ブックと同じ方式で機能する。 電子式予定表管理方法およびシステムは、ユーザが多数の日を含む時間期間を走査し、予定行事を極めて迅速に識別することができる点で、通常の予定表に比べて有利である。

従来発展してきたもう１種の予定表管理機構は、ユーザが互いに対話し、さらにデータ処理システム上に維持されたデータと対話することを可能にするように確立された、大きな通信ネットワークの一部である多数の端末またはワークステーションを有するマルチユーザ環境に関するものである。 この環境では、端末またはワークステーションのユーザがネットワーク上の他の１人または複数のユーザにメッセージを送ることができ、受信人がメッセージを受け取って読んだとき通知を受けることができる。

こうした大部分の環境では、各ユーザは個々に予定表を維持しており、相互に対話する目的がそれぞれの予定表を参照するためであることがしばしばである。 したがって、多くの組織でかなりの時間を費して人々は会議、発表等の種々の行事を調整するために自分の予定表をチェックし、再調整を行なっている。 この環境では、会議を召集しようとする人物が安全保護システムの範囲内で招待しようとする他のユーザの予定表を調べて、所定の時間期間が各出席予定者の予定表で空いているかどうか判断することができるところまで、予定表管理システムおよび方法が進歩してきた。 しかし、一度会議の時間が設定され、出席予定者に会議の日時と議題が通知されると、各加入者は自分の電子式予定表を更新し、会議の要求に応答しなければならない。 このシステムは要求および応答メッセージ処理を容易にすることができるものの、否定の応答を伝えなければならないときは、互いに都合のよい時間に電話で連絡する方が失敗が少ないことがときにはある。 その結果、予定主が他の人達が予定している行事への参加要求に回答するのに、かなりの時間と労力が費やされる。 本発明は、従来技術のシステムの上記の問題が解消された電子式予定表管理方法を提供する。

前出の各特許出願には、予定表が手動操作状態に保持されていたとき、予定主が期待していた機能をもたらすことにより、生産性を高め、システム全体を予定主にとってもっと魅力あるものにする電子式予定表管理方法に対する種々の改善が記載されている。

多くの場合、個々の予定主が、予定している行事で使用するつもりの資源を予約できることが望ましい。 予定主が会議室等の会議場所を要求することを可能にする電子式予定表管理システムが幾つかあるが、会議室および会議室に関連する資源の使用可能性は、行事を予定する時点では確保されない。 したがって、会議室が使用できないので会議時間を変更しなければならず、その結果、既に出席が確立していた招待者の１人または複数が以前から約束していた別の予定のために出席できない場合には、また初めから同様の手順で反復処理を行なわなければならなくなる。 たとえば、会議の発起人がスライド映写機、ビデオ・プレーヤおよびモニタ、または遠隔会議装置等の会議用の特殊装置を必要とし、それらが壊れているか、または幾つかの妥当な理由で使用できないことを会議の直前になって知らされたときも、同様の状況が生じる。

Ｄ． 発明が解決しようとする問題及び解決するための手段 本発明は、行事を予定する時点で、予定される行事をサポートするための資源を予定主が要求し、設備および資源が使用可能であるという確認をその時点で受け取ることができる方法を提供することにより、従来技術の上記問題および制限を克服する。

設備および資源を必要とする行事を予定する際に予定主が費やす時間および労力を最少にするため、会議通知で示される時間および場所における必要な設備の使用可能性の自動確認が電子式予定表管理方法で行なわれる。

この方法は、会議を予定し、システムを介して会議通知を他の予定主に送る予定主に対する、会議設備および装置についての応答を自動化するためにシステムが使用するデータを記憶するための資源データ構造（体）を確立する。 会議場所と、予定された会議時間に使用可能な装置ならびに要求された資源を定義できるようにするため、資源データ構造と一緒にシステムが使用する一対のトリプレット形式のデータ構造が確立される。

前出の特許出願（ＡＴ９−９６−０４４）に記載された電子式予定表管理システムの自動応答機能は、会議室に割り当てられたシステム上のノードからの自動応答の発生に適応するように変更される。 会議の召集者は、会議形式の行事を予定する過程の一部として画面を提示され、この画面を使って、召集者が希望する会議室、それを使用する時間期間、会議で使用するため予約したい装置を召集者が識別することができる。 会議通知は、会議の招待者（招待を受けた者のこと。）に送られる通知に先立って、またはそれと同時に、会議室ノードに送られる。

会議室ノードでその通知を受け取ると、その要求が分析され、部屋が使用可能な場合は、部屋が彼のために予約されることを知らせる、確認が召集者に送り返される。
要求された装置のリストも使用可能な装置と突き合わせて分析され、その会議期間の間予約されているという表示が各項目ごとに行なわれる。 要求された項目が使用可能でないときも、表示が行なわれる。

要求された部屋のすぐ近辺に同様な会議室がある場合は、要求を満たすならば代りの部屋を自動的に割り当てることができる。 これは、予定主が招待された会議に代理人を送ることができる前出の特許出願（ＡＴ９−５６
−０４４）における動作と非常に似ている。 したがって、会議の召集者は、どの部屋が予約されているか、および自分が必要とする装置は全て予約されているかどうかを知っている。

したがって、本発明の目的は改善された電子式予定表管理方法を提供することである。

本発明の他の目的は、会議の時点で使用できない可能性がある設備および装置を必要とする予定行事を計画する際に、電子式予定表の予定主を助けることである。

本発明の他の目的は、予定されている行事をサポートするための共通設備および共通装置の使用要求に対する応答に、特定の要求項目が使用可能、または使用可能でないことを反映させることができるようになった、改善された電子式予定表管理方法を提供することである。

本発明のさらに他の目的は、会議をサポートするための装置または設備を要求した予定主に対する自動応答で、
要求の全要素を満たすことのできる代りの場所を指定することができるようになった、または応答の性質および内容に初めに指定され要求された場所よりも提案された代りの場所の方がもっとよく要求を満たすことが反映されるようになった電子式予定表管理方法を提供することである。

Ｅ． 実施例 第２図は本発明の電子式予定表管理方法を使用すると好都合な対話型データ処理端末の機能要素を示す。 この端末は処理装置１１を含み、処理装置１１はマイクロプロセッサ・ブロック１２、半導体メモリ１３、および制御ブロック１４を備え、制御ブロック１４は、マイクロプロセッサ・ブロック１２と記憶装置１３との間の相互作用に加えて入出力動作をも制御する。

端末はさらに、表示装置１６、キーボード１７、印刷装置１８、ディスク記憶装置１９およびモデム２０を含む一群の通常の周辺装置を備える。 上述の機能ブロックの詳細は本発明の特徴を示すものではなく、しかも従来技術に見出すことができるので、当業者が本発明を理解するに足るだけの簡単な機能説明のみを以下に示す。

処理装置１１は、ＩＢＭ ＸＴまたはＩＢＭ ＡＴシステム等のパーソナル・コンピュータ・システムの「システム・ユニット」に対応する。 装置１１はオペレーティング・システム・プログラムを備え、このオペレーティング・システム・プログラムは、システムを走らせるため通常使用されるＤＯＳ（ディスク・オペレーティング・システム）の多数のバージョンの１つでよい。 オペレーティング・システム・プログラムは、ユーザが実行すべく選択した１つまたは複数のアプリケーション・プログラムと共にメモリ１３に記憶される。 メモリ１３の容量とアプリケーション・プログラムの大きさに応じて、
これらのプログラムの一部分を、必要に応じて、ディスク記憶装置１９からメモリ１３に転送することができ、
ディスク記憶装置１９は、例えば、３０メガバイトのハード・ディスク駆動機構およびディスケット駆動機構を備えることができる。 ディスク記憶装置の基本的機能は、必要なときにメモリ装置１３に容易に転送可能なプログラムおよびデータを記憶することである。 ディスケット駆動機構の機能は、プログラムおよびデータをシステムに入力するための着脱可能な記憶機能と、他の端末またはシステムで使用するため容易に輸送可能な形でデータを記憶するための媒体を提供することである。

表示装置１６およびキーボード１７は協働して端末の対話機能をもたらし、通常操作では、操作員による特定のキーストロークをシステムがどう解釈するかは、ほぼ全ての場合、その時点で操作員に何が表示されているかによって決まる。

場合によっては、操作員がコマンドをシステムに入力することにより、システムが特定の機能を実行する。 他の場合には、システムは、通常プロンプト型のメニュー／
メッセージ画面を表示することにより、特定のデータの入力を要求する。 操作員とシステムの間の対話の深さは、オペレーティング・システムとアプリケーション・
プログラムの種類によって変わるが、これは本発明の方法を使用できる端末の必要な特性である。

第２図に示す端末は、さらに印刷装置１８を備え、印刷装置１８は、端末で発生または記憶されたデータのハード・コピー出力をもたらす働きをする。 最後に、モデム２０は、１つまたは複数の通信リンクを介して、データを第１図の端末からホスト・システムに転送する働きをする。 通信リンクは商用型リンクでも、専用通信リンクでもよい。

第３図は、第２図に示す対話型ワークステーションのネットワーク２１を示す。 図のように、ネットワークは、
互いに相互接続されかつホスト中央処理装置２３に相互接続された複数の端末を含み、中央処理装置２３は通信リンク２４を介して第２のホスト処理装置２５に接続され、ホスト処理装置２５も対話型ワークステーションの別のネットワーク２６に接続している。 機能的には、このシステムは確立された通信プロトコルを使って、１台の端末が１台または複数の他の端末と通信できるように働き、直列接続された様々な通信リンクは操作員にとって透過性を有する構成となっている。 そのようなシステムは当技術分野では周知であり、現在、商業的に広く使用されている。 これらの通信リンク自体は本発明の特徴部分ではないので、本発明の予定表管理方法を理解するために必要な細部についてのみ説明する。 したがって、
以下の説明では、ネットワーク上の各ワークステーションは、システム・ノード・アドレスおよび「郵便局」アドレスを有し、さらに、説明を簡単にするため、ネットワーク上の各ノードにはただ１台のワークステーションのみが割り当てられていると仮定する。 さらに、個々の予定主の住所録や会議室等の共用資源などの予定を立てるために必要な通常の通信サービスがシステムによって提供されるものとする。

第３図に示すシステムは、情報をテキスト・データ・オブジェクト、図形データ・オブジェクト、および予定表管理データ・オブジェクト等の種々の形式のデータ・オブジェクトとして処理する。 これらのデータ・オブジェクトの各々は、一連の構造化フィールドから成るデータ・ストリームによって表わされる。

予定表管理オブジェクト・データ・ストリームは、以下の構造シーケンスを有する。

ドキュメント開始（ＢＤＴ） ページ開始（ＢＰＧ） 予定表データ開始（ＢＣＬ） 予定表データ記述子（ＣＤＤ） （任意選択） 予定表データＳＦ（ＣＡＤ） 予定表構造（ＣＯＣＡ） 予定表データ終了（ＥＣＬ） ページ終了（ＥＰＧ） ドキュメント終了（ＥＤＴ） 他の予定表データのデータ・オブジェクトに対するデータ・ストリームの形式は文書開始、ページ開始、ページ終了、および文書終了のデータ構造を含む。 予定表オブジェクトに対して上に列挙したフィールドに対応する構造化フィールドは他のオブジェクトにも使用される。

構造化フィールドは自己記述エンティティであり、パラメータ値およびトリプレットの関連したグループを含む。 構造化フィールドは、下に示すように、２つの部分、すなわち、構造化フィールド導入子および構造化フィールド内容を有する。

構造化フィールド導入子の構文および意味は、その構造化フィールドが属するデータ・ストリームを規定するアーキテクチャによって定義される。 構造化フィールド導入子は、最初の２バイトとして、構造化フィールドの長さを定義するパラメータを含む。 構造化フィールドを一意的に識別する識別コードをも含む。

各構造化フィールドの構造内容の部分は、構造化フィールドにその意味を与える構造およびトリプレットを含む。 トリプレット内のパラメータは予定表オブジェクトの属性を定義する。 全てのパラメータは、データ・ストリーム階層中の制御構造から受け取ったトリプレット中に明示的に現われる値、または省略時に暗示的に定義される値を有する。 この省略時の値は代替の活動値であってもよい。 全ての構造は必須または任意選択である。

必須の構造はオブジェクト中に現われる。 なぞならば、
その構造の機能は必須であり、その機能の正しい遂行のためにある値が必要だからである。

任意選択の構造は、オブジェクト中に現われない。 なぜならば、その構造の機能が必須でないか、または、機能は必須であるが、全てのパラメータにとって省略時の値が受入れ可能だからである。

上で示したように、予定表（管理）データ（ＣＡＤ）フィールドは実際の予定表（管理）データに先行する。 予定表（管理）データ記述子（ＣＤＤ）フィールドはＣＡ
Ｄフィールドに先行し、後続するデータに対する様式化情報をもたらすことができる。

予定表（管理）データは、命名された構造および命名されたトリプレットを含み、これらの構造及びトリプレットはパラメータを含む。 パラメータとは、ある値が割り当てられた変数である。 パラメータは任意選択のものも、また必須のものもある。 パラメータはまた、末端か非末端かで分類される。 末端パラメータとは、パラメータ・ストリング（パラメータ列）中の最後のパラメータにすぎない。

パラメータは、割り当てられた３つの種類の値のうちの１つをとることができる。

１． ＮＵＭ−これは数または数値である。

２． ＣＯＤ−これは、特定の意味を割り当てられたコードである。

３． ＢＳＴ−これは２進要素から成るビット・ストリング（ビット列）であり、通常その各々は他のビットから独立している。

以下の考察では、１バイトは、左から右に０−７と番号を付けた８つのビット位置から成り、位置０が高位位置であるものと仮定する。 ビット位置０は＊７（２の７
乗）を表わし、ビット７は２＊０（２の０乗）を表わす。

種々の予定表構造化フィールドおよび予定表トリプレットが以下の形式のテーブルで定義される。

−パラメータ名欄はそのパラメータの名前を示す。

−型式欄は「型式」によってパラメータの構文を示す。
体系化された型式ＮＵＭ、ＣＯＤおよびＢＳＴは前に説明した。

−長さ欄は正確なバイト数または許容される最大バイト数で表わしたフィールドの長さを示す。

−ＯＰＴ欄は構造またはトリプレット内でのパラメータの出現の任意選択性を指す。

Ｏはそのパラメータが任意選択であることを意味する。

Ｒはそのパラメータの出現が必須であることを意味する。

必須のパラメータが見つからない場合は、例外条件が存在する。 代替的活動は見つからなかったパラメータが属する構造、自己定義フィールド、または、トリプレットを無視することである。

本発明に関連する予定表（管理）データ構造および予定表（管理）トリプレットについて、上記の形式を使って説明する。 前記データ構造について説明した後、予定主が予定表管理機能を実行しようとするとき情報を要求するためシステムが予定主に提示する表示画面について説明する。 次に、本発明の方法の詳細なステップを示すフローチャートについて、対話型端末のプログラミングに習熟した人が本発明を実施するのを助ける擬似コードのプログラム・リストと関連づけて説明する。

自動回答機能は別の予定主が予定表中に管理している行事への招待に応答して働くので、予定主がある行事を自分の予定表中に組み入れる過程でシステムが使用するデータ構造を詳細に説明する必要がある。 好ましい実施例では、予定表記入事項は複数の異なる型式に分類される。 このシステムは、第３図に示す端末のように遠隔接続された端末を含めて、システム全体に渡って予定表データを交換することを意図しているので、項目の型式および提示言語は、定義されたアーキテクチャによって制御される。

同じ表示画面を使って複数の異なる種類の行事に対するデータを送信要求することができるが、データ構造およびトリプレットは、必須のものであれ、任意選択のものであれ、行事の種類によって変わる。

ここで説明する種々の予定表（管理）オブジェクト・データ構造は、下記に示す予定表（管理）データ構造の後にくる。

Ｆは、例えば、最大３２７６７バイトまでの予定表（管理）データ構造を有し、また、予定表（管理）トリプレット（「予定表（管理）データ」と呼ぶ）を含む。 予定表（管理）データは、オブジェクトの発生機構が使用する機能に応じて変わる。

主要な予定表（管理）データ構造の説明 次に、本発明で用いる主要なデータ構造について説明する。 これらのデータ構造は予定表（管理）トリプレットの結合体から成る。 トリプレットについては、この項の次の予定表（管理）トリプレットの説明の項で説明する。

予定表（管理）データ構造は予定表（管理）データ構造化フィールド（ＣＡＤ）により先行される。 システムにより指定されたパラメータ値を予定表（管理）データ中で指定されるパラメータによって重ね書きすることができる。 例えば、データを表示、印刷するための記号のコード・ページ等である。

構造の説明では、ビットには０から始まって、左から右に連続番号を付ける。

全ての構造に対する形式は同じである。 その形式を下記に示す。

長さに関する制約のためにトリプレット内の任意選択パラメータの全部または一部が排除されるならば、そのパラメータおよびそれに続く任意のパラメータに対する値は変更されない。 すなわち、長さフィールドは指定された通り使用される。

データ構造が無効、すなわち、サポートされていない場合は、例外条件が生じる。

長さフィールドが必須パラメータまたはトリプレットを排除する場合は、例外条件が生じる。

データ構造が無効なパラメータ、すなわち、サポートされていないパラメータまたはトリプレットを含む場合は、例外条件が生じる。

アポイントメント（ＡＰＰ）構造 アポイントメント（面会、約束）構造を以下に示す。

項目選択（ＥＮＳ）構造 予定表注釈構造を以下に示す。

会議（ＭＴＧ）項目のデータ構造

ＭＴＧ構造（会議項目のデータ構造）は、会議情報の交換、会議の予定作成、および会議情報の要求に必要なフィールドをもたらす。 ＭＴＧ構造はまた、指定された予定主リストに対する複合予定表の作成を可能にする特定の探索分類を指定する。

名前リスト（ＮＭＬ）データ構造 名前リスト・データ構造を下記に示す。

は、名前（ＮＭＥ）、アドレス（ＡＤＲ）およびユーザ状況（ＵＳＴ）シーケンスを連結することにより、招待者リスト等の項目リストを含むことができる。 このリストは１つまたは複数の名前および関連情報を含むことができる。

トリガ（ＴＧＲ）構造 トリガ構造を以下に示す。

ビュー（表示）選択（ＶＳＬ）データ構造 ビュー（表示）選択データ構造を下記に示す。

予定表プロファイル（ＣＰＬ）データ構造 予定表プロファイル・データ構造を以下に示す。

日時マップ（ＤＴＭ）データ構造 日時マップ・データ構造を以下に示す。

自動回答（ＡＲＳ）データ構造 自動回答データく構造を下記に示す。

資源（ＲＳＲ）データ構造 資源データ構造を以下に示す。

予定表（管理）トリプレットの詳細な説明 この項では、前の項で説明したものも含めて、システムの予定表（管理）データ構造が使用されるように設計された構成要素である予定表（管理）トリプレット・セットについて詳細に説明する。

前項では、これらのトリプレットがどこで（どのデータ構造中で）有効であるかを示した。

トリプレットはアルファベット順に説明する。

トリプレットの説明では、ビットは０から始めて左から右に連続番号が付けられる。

トリプレットの全ての形式は同じであり、下記に示す。

追加の値はサポートされていないパラメータとみなされるので、例外条件が生じる。 また、長さフィールドのために必須のパラメータが排除される場合は、例外条件が生じる。

全てのトリプレットのバイト１および２は同じであるので、各トリプレットについてそれらを示すことはしない。 バイト２ないしｎのみについて説明する。

収容能力（ＣＰＣ）トリプレット・データ構造 ＣＰＣデータ構造を以下に示す。

ＣＰＣパラメータ 収容能力−収容される人数を指定する。

値 １−２５５ 資源形式（ＲＳＴ）トリプレット・データ構造 ＲＳＴデータ構造を以下に示す。

ＲＳＴパラメータ 形式−資源形式を指定する。

ビット ０＝会議室 １＝映写スクリーン ２＝映写機 ３＝スライド映写機 ４＝ビデオ・レコーダ ５＝テレビジョン ６＝フリップチャート紙 ７＝フリップチャート・イーゼル ８＝表示装置 ９＝会議電話 １０＝電話 １１＝ライティング・ボード １２＝オーバヘッド・プロジェクタ １３−３１ 留保 予定管理範囲（ＣＳＣ）トリプレット・データ構造 ＣＳＣデータ構造を下記に示す。

ＣＳＣパラメータ 予定（管理）開始日−予定（管理）時間期間が開始する通算日。

予定（管理）開始年−これは、予定表でサポートされている時間期間の開始年であるる。

予定（管理）終了日−予定（管理）時間期間が終了する通算日。

予定（管理）終了年−これは、予定表でサポートされている時間期間の終了年である。

予定表管理型式（ＣＴＰ）トリプレット・データ構造 ＣＴＰデータ構造を下記に示す。

ＣＴＰパラメータ 型式−グレゴリオ暦、ユリウス暦、イスラム暦、ユダヤ暦、大陰暦、ショップ暦等の予定表型式を指定する。

日時（ＤＴＴ）トリプレット・データ構造 ＤＴＴデータ構造を下記に示す。

ＤＤＴパラメータ 夏時間標識−夏時間にあることを指定する。 このパラメータは、時間域と関連して、時間域を識別し、正しい時間域ラベル（すなわち、ＣＳＴまたはＣＤＴ）が時間に適用されることを可能にする。

時間域標識−時間域標識は、指定された時刻に対するグリニッジ標準時（ＧＭＴ）からのずれである。 半時間域を処理するため、値はＧＭＴからの半時間で指定される。

開始日−行事が始まる通算日。

開始年−行事が始まる年。

開始時刻−開始時刻は、行事開始時刻を秒で指定する。

終了日−行事が終了する通算日。

終了年−行事が終了する年。

終了時刻−終了時刻を秒で指定する。

日付は２つの２バイト・パラメータ（通算日および年）
の組合せとして指定できる。 時刻は、真夜中から始まる秒表示の地域時である。 各ＤＴＴトリプレット中で１つの開始日および開始時刻が必要とされる。 追加の開始日および終了日と開始時刻および終了時刻が必要な場合は、開始および終了、日時シーケンスを反復することができる。

１つのＤＴＴトリプレットで送ることができるより多くの日時が必要な場合は、追加のＤＴＴトリプレットを予定表管理データ構造に含めることができる。 唯一の制限はバイト構造長である。

詳細（ＤＴＬ）データ構造 ＤＴＬデータ構造を下記に示す。

ＤＴＬパラメータ 文字列−予定表入力事項に関連するテキスト情報。 値は、活動コード・ページまたは選択されたコード・ページの有効文字である。

文字ストリング中でコード化図形文字セット大域ＩＤ設定（ＳＣＧ）が変更される場合は、ＤＴＬトリプレットを打ち切り、ＳＣＧの挿入後、別のＤＴＬトリプレットを作成しなければならない。

入力事項類別（ＥＣＴ）データ構造 ＥＣＴデータ構造を下記に示す。

ＣＴトリプレットを使用して、日時マップ（ＤＴＭ）および点検選択（ＶＳＬ）構造の両方に対する要求および応答で予定表入力事項の類別を指定する。

ＥＣＴパラメータ 類別−４バイトのビット・コード化値。 複数の類別ビットの組合せが可能である。 類別は、日時マップ（ＤＴ
Ｍ）データ構造およびビュー選択（ＶＳＬ）データ構造の両方に対する要求類別および応答類別を指定する。 ビット０−２０は、ＤＴＭ類別およびＶＳＬ類別の両方に対して使用することができる。 ビット２１−２４はビュー選択のみで使用される。 それらが日時マップ中で使用された場合は、無視される。

各ビット重みのコード化 ０＝休日（一般）−予定主の休日には働く。

１＝休日（確定）−予定主の確定した休日。

２＝休日（暫定）−予定主は暫定の休日。

３＝休暇（確定）−予定主の確定した休暇。

４＝休暇（暫定）−予定主の暫定の休暇。

５＝不在（確定）−予定主は通常の仕事場所におらず、
会うことができない。

６＝不在（暫定）−予定主は通常の仕事場所から離れた活動を予定しているが未確定である。

７＝通常仕事時間外−通常仕事行なわない時間。

８＝会議についての確定した予定（欠席）−予定主は出席しない。

９＝会議についての確立した予定（出席）−予定主は出席する。

１０＝会議についての確定した予定（多分出席）−この会議に帯する予定主の予定は暫定的である。

１１＝会議についての暫定的な予定（欠席）−予定主は出席しない。

１２＝会議についての暫定的な予定（出席）−確定した場合は、予定主はこの会議に出席する。

１３＝会議についての暫定的な予定（多分出席）−この会議に対する予定主の予定は未確定である。

１４＝面会についての確定した予定（欠席）−予定主は出席しない。

１５＝面会についての確定した予定（出席）−予定主は出席する。

１６＝面会についての確定した予定（多分出席）−この面会に対する予定主の状況は暫定的である。

１７＝面会についての暫定的な予定（欠席）−予定主は出席しない。

１８＝面会についての暫定的な予定（出席）−確定した場合、予定主はこの面会に出席する。

１９＝面会についての暫定的な予定（多分出席）−この面会に対する予定主の状況は暫定的である。

２０＝予定がない時間−予定表の空いている時間を識別する。 単独で使用する場合、この類別は最も効果的である。

２１＝日時のみ（ビュー選択のみ）−ビュー選択で特に要求されていない全ての類別に対して、日時を選択する。

２２＝個人的項目（ビュー選択のみ）−予定表ビュー選択要求に応答して、日時のみを指定することができる。

２３＝予定表注釈（ビュー選択のみ）−文字データ項目。

２４＝トリガ（ビュー選択のみ）−処理を開始または通知する項目。

２５−３１＝留保 日時マップに対する要求中で全ての類別ビットが１にセットされた場合は、返される情報は、予定がある時間と予定がない時間の両方を含むので無意味である。 「予定がない時間」ビットは、意味のあるデータを得るため他のビットと共に使用する場合、慎重に使用しなければならない。 「通常の仕事時間外」ビットも同様の理由で慎重に使用しなければならない。

項目分類（ＥＮＣ）データ構造 ＥＮＣデータ構造を下記に示す。

ＥＮＣパラメータ 分類−２バイトのビット・コード化値。 複数の分類ビットの組合せは許容されない。

各ビット重みのコード化 ０＝休日−（一般）予定主はこの休日は働く。

１＝休日−（確定）確定した予定主の確定した休日。

２＝休日−（暫定）予定主の暫定的な休日。

３＝休暇−（確定）予定主の確定した休暇。

４＝休暇−（暫定）予定主の暫定的な休暇。

５＝不在−（確定）予定主は通常の仕事場所におらず、
会うことができない。

６＝不在−（暫定）予定主は、通常の仕事場所から離れた活動を予定しているが暫定的である。

７＝通常仕事時間外−予定主が働かない時間。

項目安全保護レベル（ＥＳＬ）構造 ＥＳＬデータ構造は以下の通りである。

ＥＳＬパラメータ 安全保護−０−２の１バイト値。

０＝公開（省略時）予定表を、どの予定主でも見ることができる。

１＝共有−予定表は、選択されたグループが共有することができる。

２＝専用（秘密）−日時は見ることができるが、関連する予定表データの内容は見ることができない。

エラー・アクション（ＥＡＣ）データ構造 ＥＡＣデータ構造は以下の通りである。

ＥＡＣパラメータ アクション−エラ−・アクション仕様 各ビット重みのコード化 ビット重み ０＝０−（省略時）例外を報告し、指定された代りのアクションをとり、続行する。

０ １−例外を無視し、指定された代りのアクションをとり、続行する。

１−７ 留保 行事状況（ＥＶＳ）データ構造 ＥＶＳデータ構造は以下の通りである。

ＥＶＳパラメータ 行事状況−行事の状況 各ビット重みのコード化 ０＝確定（会議の時間が確定した） １＝暫定的（会議の予定は暫定的である） ２＝取消し（会議は取り消された） ３＝延期（新しい日時は設定されていない） ４＝予定立て直し（会議の予定が立て直された） ５＝保管（項目が参照用に保管される） 名前（ＮＭＥ）データ構造 ＮＭＥデータ構造は以下の通りである。

ＮＭＥパラメータ 名前の型式−名前の型式を指定する。 ビット１および２
は相互に排他的である。 これらのビットは一方のみを１
にセットすることができる。

各ビット重みのコード化 ０＝（０−名前が個人名である）。

（１−名前が予定表名である） １＝１−名前は、ネットワーク内で一意的でない原始名である。

２＝１−名前が、ネットワーク内で一意的な記述名である。

３−７＝留保 関連トリプレット−１にセットされたビットは、ユーザ状況（ＵＳＴ）、ネットワーク・アドレス（ＮＡＤ）および郵便アドレス（ＰＡＤ）トリプレットが任意の順序でＮＭＥトリプレットに続くことを指定する。

０＝名前の付けられた項目の役割および状況を指定するユーザ状況（ＵＳＴ）トリプレットが続く。

１＝名前の付けられた項目のネットワーク・アドレスを指定するネットワーク・アドレス（ＮＡＤ）トリプレットが続く。

２＝名前の付けられた項目の郵便アドレスを指定する郵便アドレス（ＰＡＤ）トリプレットが続く。

項目名−個人または予定表の名前を指定する。

値は、活動コード・ページまたは選択されたコード・ページの有効文字である。 最大の名前サイズは２５１バイトである。

ＮＭＥトリプレットによって名前の付けられた項目は、
ユーザ状況（ＵＳＴ）、郵便アドレス（ＰＡＤ）およびネットワーク・アドレス（ＮＡＤ）トリプレットを使ってさらに識別することができる。

使用される文字が活動コード・ページにない場合は、Ｎ
ＭＥトリプレットの前にＳＣＧトリプレットが来なければならない。

名前リスト形式（ＮＬＴ）データ構造 ＮＬＴデータ構造は以下の通りである。

ＮＬＴパラメータ リスト形式−リスト形式を指定する。 ビットの組合せは許される。 郵便アドレスを追加または代用することができる。

各ビット重みのコード化 ０＝リストは名前および関連するネットワーク・アドレスを含む。

１＝リストはニックネームおよび関連するネットワーク・アドレスを含む。

２−１５ 留保 リストは任意選択として郵便アドレスおよびユーザ状況を含むことができる。 ＮＬＴトリプレットは、特定のリスト型式に対するリスト内容を記述する。 ＮＬＴを含むリストは指定された内容に限定される。 ＮＬＴが省略された場合、リストは名前、ユーザ状況およびアドレスの任意の有効な組合せを含むことができる。

ネットワーク・アドレス（ＮＡＤ）トリプレット・データ構造 ＮＡＤトリプレット・データ構造を以下に示す。

ＮＡＤアドレスは以下のものを含む。

ネットワーク・アドレス−これは個人のネットワーク・
アドレスである。

バイト２−９ ＝ユーザＩＤ バイト１０−１７＝ノードＩＤ 場所（ＰＬＣ）データ構造 ＰＬＣデータ構造は以下の通りである。

ＰＬＣパラメータ 場所−場所は行事の場所を指定する。

郵便アドレス（ＰＡＤ）トリプレット・データ構造 ＰＡＤトリプレット・データ構造を以下に示す。

ＮＡＤパラメータは以下のものを含む。

郵便アドレス−これは個人の郵便アドレスである。 有効な値は活動コード・ページまたは選択されたコード・ページにおける有効文字である。

処理ＩＤ（ＰＲＤ）トリプレット・データ構造 ＰＲＤトリプレット・データ構造を以下に示す。

ＰＲＤパラメータ 処理−１−１６バイトの識別子。 有効な値は活動コード・ぺージまたは選択されたコード・ページにおける有効文字である。

応答（ＲＳＰ）データ構造 ＲＳＰデータ構造は以下の通りである。

ＲＳＰパラメータ 応答−どのような応答が送られるかを指定する。 代理の指示は他のどのビットを使用してもよい。

各ビット重みのコード化 ０＝アクションなし−自動応答は非活動化される。

１＝確定−招待者は出席する。

２＝暫定−招待者は多分出席する。

３＝欠席−招待者は出席しない。

４＝招待を受けたこと自体の確認−予定要求を受け取った。

５＝代理−応答は招待者の代理人からである。

ＲＳＶＰ（ＲＶＰ）データ構造 ＲＶＰデータ構造は以下の通りである。

ＲＶＰパラメータ ＲＳＶＰ−会議計画要求に対する応答の必要性を指定する。

各ビット重みのコード化 ０＝出席応答は要求されない。

１＝ＮＭＬ構造を使った出席応答が要求される。

コード化図形文字セット大域ＩＤ設定（ＳＣＧ）データ構造 ＳＣＧデータ構造は以下の通りである。

システムによって指定されたＣＧＣＳＧＩＤが活動状態の文字セットおよびコード・ページを選択する。 ＳＧＣ
ＳＧＩＤが指定されていない場合は、指定された省略時の文字セットおよびコード・ページが使用される。

ＳＣＧパラメータ ＣＧＣＳＧＩＤ−コード化図形文字セット大域ＩＤ。 ２
つの２バイト数の連結。 最初の２バイトは、２進値として表わされた図形文字セット大域ＩＤ（ＧＣＳＧＩＤ）
を識別する。 次の２バイトは、２進値として表わされたコード・ページ大域ＩＤ（ＣＰＧＩＤ）を識別する。

ＧＣＳＧＩＤ−図形文字セット大域ＩＤ。

ＣＰＧＩＤ−コード・ページ大域ＩＤ。

ＧＣＳＧＩＤおよびＣＰＧＩＤは、コード化テキスト文字が提示すべき図形文字にどのように変換されるかを決定するために使用される。

ＳＣＧは、ＳＣＧの直後のトリプレットに対するコード・ページを選択するだけである。 省略時コード・ページとは異なるコード・ページ上のテキスト文字を含む構造が連結された場合は、各構造に先行する個別のＳＣＧが必要である。

ＳＣＧはＵＤＦトリプレットのネットワーク・アドレスおよびＵＤＦトリプレットのユーザ・コードには影響を及ぼさない。

構造ＩＤ（ＳＩＤ）データ構造 ＳＩＤデータ構造は以下の通りである。

ＳＩＤパラメータ ＩＤ形式−ＩＤの形式を指定する。

各ビット重みのコード化 ０＝項目ＩＤ−予定項目を識別する。

１＝名前リストＩＤ−名前のリストを識別する。

２＝トリガ−トリガを識別する。

３＝プロファイルＩＤ−予定表・プロファイルを識別する。

４＝自動応答−自動応答を識別する。

５＝資源−資源データ構造を識別する。

識別子−１−４４文字の識別子。

ＳＩＤは、知能ワークステーションからホストへの予定表内容更新を実現し、会議通知に対する応答を会議名リストと相関させ、関係する人々のリストの通知を会議またはリストと相関させるため、相関ＩＤをもたらす。

主題（ＳＢＪ）データ構造 ＳＢＪデータ構造を以下に示す。

主題はテキスト文字を使って記述される。

ＳＢＪパラメータ 行事の主題−このパラメータは行事の主題を指定する。

トリガ形式（ＴＴＰ）データ構造 ＴＴＰデータ構造は以下の通りである。

ＴＴＰパラメータ 形式−このパラメータは、形式がメッセージ（伝言）
が、音声処理か、それとも結合トリガであるかを指定する。

ビット ０＝メッセージ・トリガ（省略時） １＝音声トリガ ２＝処理トリガ−処理ＩＤにより識別される処理が開始される。

３−７＝留保。

時間マップ（ＴＭＡ）データ構造 ＴＭＡデータ構造は以下の通りである。

ＴＭＡパラメータ 時間スケール−時間スケールは、時間バイト内の各ビットで表わされる時間増分である。

許容される値は１−８６４００秒である。

時間バイト−時間バイトの各ビット位置は、時間スケールに等しい時間期間を表わす。 ビット０は、開始時刻から始まる時間期間を表わす。

タイム・スタンプ（ＴＭＳ）データ構造 ＴＭＳデータ構造は以下の通りである。

ＴＭＳパラメータ 夏時間インジケータ−夏時間が活動状態にあることを指定する。 このパラメータは、時間帯と一緒に、時間帯を識別し、正しい時間帯ラベル（すなわち、ＣＳＴまたはＤＴ）が時間に適用できるようにする。

時間帯インジケータ−時間帯インジケータは、指定された時間のグリニッジ標準時（ＧＭＴ）からのずれである。 値は、半時間帯を処理するため、ＧＭＴから半時間単位で指定される。

開始年−行事が始まる年。

開始時刻−開始時刻は行事開始時刻を指定する。

ネットワーク・アドレス長−ネットワーク・アドレスの長さ。

ネットワーク・アドレス−システム・アドレス バイト１２−１９＝ユーザＩＤ−ＣＰ２５６、 ＣＳ９３０の有効文字。

バイト２０−２７＝ノードＩＤ−ＣＰ２５６、 ＣＳ９３０の有効文字。

バイト２８−１３９＝追加アドレスをサポート するため留保。

ユーザ状況（ＵＳＴ）データ構造 ＵＳＴデータ構造は以下の通りである。

ＵＳＴパラメータ 役割−行事に関する個人の役割を指定する。

値 ０＝召集者−個人が行事を召集した。

１＝手配者−個人が行事を手配する。

２＝招待者（省略時）−個人が会議に招待された。

３＝強制招待者−会議に出席しなければならない人物。

４＝代理人−臨時に招待者の代りに出席する人物。

５＝追加出席者−グループ会議に関連する配布リストに自分を追加する人物。

６＝コピー受取り−行事情報を受け取る人物。

７＝ブラインド・コピー受取り−行事情報のみを受け取る人物で、その名前は配布リストに現われない。

８＝恒常的代理人−恒常的に招待者に代わって出席する人物。

個人状況−名前と関連する状況。

値 ０＝何もしない（状況を受け取らなかった） １＝確定（この人物は出席する） ２＝暫定（この人物は多分出席する） ３＝欠席（この人物は出席しない） ４＝招待受信の確認応答（招待を受け取った） ５＝代理（招待者は出席しないが、代理人が多分出席する） ユーザ定義フィールド（ＵＤＦ）データ構造 ＵＤＦデータ構造は以下の通りである。

ＷＴＭパラメータ 夏時間インジケータ−夏時間が活動状態にあることを指定する。 このパラメータは、時間帯と一緒に時間帯を識別し、正しい時間帯ラベル（すなわち、ＣＳＴまたはＣ
ＤＴ）が時間に適用できるようにする。

時間帯インジケータ−時間帯インジケータは、指定された時間のグリニッジ標準時（ＧＭＴ）からのずれである。 値は、半時間帯を処理するため、ＧＭＴから半時間ごとに指定される。

開始時刻−開始時刻は時間ブロック開始を秒で指定する。

終了時刻−終了時刻は時間ブロック終了を秒で指定する。

一組の開始時刻および終了時刻が各ＷＴＭトリプレットで必要とされる。 追加の開始および終了時刻が必要な場合は、開始および終了時刻シーケンスを反復することができる。

作業週パターン（ＷＷＰ）データ構造 ＷＷＰデータ構造は以下の通りである。

ＷＷＰパラメータ パターン−このパラメータは曜日を指定する。

０＝日曜 １＝月曜 ２＝火曜 ３＝水曜 ４＝木曜 ５＝金曜 ６＝土曜 ７＝留保 表１にトリプレットと主要データ構造との関係を要約する。 表で、文字Ｏは、トリプレットがそのデータ構造にとって任意選択であることを示し、文字Ｒは、
トリプレットがそのデータ構造にとって必須であることを示し、記号−は、トリプレットがそのデータ構造に適用されないことを示す。

行事の種類を識別するには、カーソルは行事、例えば、

第４図の画面上の「会議」に自動的に合っているので、

操作員は内部キーを押すだけでよい。 図で次のデータ入力は、この行事に優先順位を割り当てることである。 入力すべき値は、その行のその値に対するブランクの後に示されている１−１０のうちの１つの値である。 優先順位の役割は、計画または予想されている他の約束と比べたこの行事の相対的重要度を設定することである。 システムは、全ての予定主に対して設定された、または各々の特定所有者に対する一意的な省略をもたらす、ある所定の基準に従って、行事に対して省略時の優先順位を設定するので、この優先順位の値の入力は任意選択である。

予定主が明示的に、またシステムによって暗示的に予定行事に優先順位を割り当てることは、同時係属特許出願（ＡＴ９−８６−０４６）に記載された方法に従ってビュー選択処理を実施する際の必要なステップである。 優先順位値の役割は、上記の出願に詳細に記載されている。

第４図に示すユーザ定義フィールドは、この例では使用しない。 その機能は、ユーザまたはユーザ共同体がある所定の目的のために使用することができるフィールドを提供することである。 行事識別子は会議の公式名である。 次に会議の日時を入力する。

画面上の次の項目は名前リストである。 会議に出席するよう招待されている全ての人物が、そのユーザＩＤ、ネットワーク・アドレスまたは郵便アドレスあるいはその両方とも共に名前リストにリストされており、そのリストに名前が割り当てられている。 この情報は前述の名前リスト・データ構造に記憶されているので、定期的に予定された会議の場合は、会議の招集者は名前リストの名前を識別するだけでよい。

会議室および装置についての要求に対する自動応答をもたらすための方法を理解するための背景として、前出の特許出願（ＡＴ９−８６−０４４）に記載されている予定主による自動応答を発生するための処理について要約する。

招待された予定主がこの通知に対する自動回答を確立していない場合は、手動で回答を入力しなければならない。 招待者が会議通知に手動で回答するための従来技術の方法はどれでも使用することができる。 例えば、行事を予定に入れるために使用される画面またはそれに類似した画面が、招待された者の回答を入力するようプログラミングされたプログラム・ファンション・キーと共に招待された者に提示される。 別法として、その行事に対する回答フィールドをもたらす特別画面を提示することもできる。 入力された回答は、名前リストの招待者名と関連したユーザ状況トリプレットの個人状況フィールドに記憶される。 そのデータ構造は会議招集者に返され、
識別された会議に対する名前リスト・データ構造として記憶される。

以下の考察では、幾つかの理由で、特定の予定主または特定の会議および面会または他の基準によって行事への招待または参加要求に対して自動的に回答するようにと、予定主が決定したものと仮定する。 自動回答を確立するために、予定主は、第５図に示すマスター・メニューから項目５を選択する。 第７図に示す自動回答画面が次に示される。 「Ｄ３５会議Ａ１」で識別される会議に常に出席することを決定した場合、そのＩＤを第７図の会議名という説明語の後にライン上に入力する。

招待者は送りたい回答を入力する。 最初の仮定では、招待者が常に出席したいという回答である。 自動回答画面の表示中に対話的にシステムに入力されたデータは、前記の自動回答データ構造ＡＲＳに記憶される。 プログラム・ファンクション・キーＰＦ１２を押すことにより、
自動回答に対するもう１つのデータ・セットを入力することができる。 システムは妥当な数の基準セットを収容するよう設計されている。 フレーム３に複数の基準が入力されると、システムによって「論理積」状況と解釈され、応答が自動的に送られる前に１つの画面で入力された全ての基準を通知に含めなければならないことになる。

システムは、ホストが各予定主の予定表を維持するよう構成されているので、予定主のワークステーションがオンになっていないときでも、彼の予定表はシステム上の他の個人にとって利用可能である。 会議通知が招待者に送られると、システムはまず、招待者である所有者がいずれかの自動回答項目を確立しているかどうか知るため検査する。 自動回答データ構造が存在することをシステムが検出した場合、会議通知に含まれるデータと、自動回答データ構造に基準として入力されたデータとの間で比較が行なわれる。 具体的には、会議名、すなわち、会議通知に対する行事識別子が、ＡＲＳデータ構造のＳＩ
Ｄトリプレットの識別子フィールドに入力されたデータと比較される。 同様に、名前リストと関連するユーザ状況トリプレットは、そのトリプレットの列のフィールドに０を入れることにより、会議招集者を識別する。 次に会議招集者の名前が、ＡＲＳデータと関連する名前およびユーザ状況トリプレットと比較される。 この名前は、
招待者が自動回答フレームに基準を入力していたとき、
このデータ構造に予め記憶されたものである。 比較処理で一致を示すときは、ＡＲＳ構造と関連するユーザ状況データ構造の個人状況フィールドに記憶された回答が、
自動的に会議招集者に送られる。

会議室および装置についての要求に対する自動応答を発生するための処理について以下に説明する。

会議招集者は、第５図に示すマスター・メニュー上でオプション６を選択し、その結果、第８図に示す会議室画面が表示される。 会議招集者は、適当な名前を打鍵入力することにより、部屋の１つを選択する。 次に第９図の画面が表示され、その部屋の詳細の全てが、その部屋で使用可能な装置と共に示される。 第９図の２つの月予定表は、その会議室に対して少なくとも１つの会議が予定されている日を示す。 会議室のネットワーク・アドレスも示される。 希望するなら、召集者は、日およびＰＦ４
キーを入力して、指示された日にその会議室に対して予約された時間を知ることもできる。 そうでない場合は、
会議通知にリストされた会議の日時が用いられる。

会議召集者は第９図の装置リストの中の項目の前のブランクにＸを入力することにより、会議のために使用したい装置を指定する。 全てのデータが入力された後で、予定主はＰＦ９キーを押し、データはデータ構造に記憶される。 これらのデータ構造は、会議に招待される予定主に通知が送られるのと同じ方法で、システムにより会議室ノードに送られる。

会議室形式画面からシステムに入力されるデータは資源データ構造、および資源形式（ＲＳＴ）トリプレット、
容量トリプレット、日時トリプレット等の適当なトリプレットに記憶される。

名前リストは会議通知に関連し、招待者の会議に限定することを想起されたい。 会議召集者が同じ人々による会議を召集したいと考える度に全ての名前を反復するのではなく、リストを呼び出すことができるように、名前リストに名前が付与される。 招待者は名前トリプレットにより識別され、名前トリプレットはまた、当該の関連アドレス・トリプレット中の各個人に対するアドレスを含む。 これらのアドレスは、会議通知がどこに送られるかを決定し、関連するユーザ状況トリプレット中に各フィールドは、招待者が会議での状況に関する自分の応答、
すなわち、出席することを意味する「確定（確認）」を記録することを可能にする。

名前により会議を識別するため名前トリプレットの１つが使用され、関連するネットワーク・アドレス・トリプレットは、会議データ構造、名前リスト・データ構造、
資源データ構造、および種々のトリプレット・データ構造が送られるＣＲノードを指定する。 資源形式（ＲＳ
Ｔ）トリプレットは、要求された装置の各々について使用され、ＲＳＲデータ構造と関連付けられ、ＲＳＲデータ構造は会議通知データ構造と関連付けられる。

会議室および使用可能な装置の目録も、個々の予定表項目を維持するのに使用されるのと同様なデータ構造を使ってシステムにより維持される。

これらの部屋および装置目録を管理する責任がある個人はＣＲ主と呼ばれる。 ＣＲノードは、ある予定主が会議を予定する際に上記データ構造を受け取るとき、自動的に応答するようセットアップされる。 応答は、部屋が使用可能かどうかを示す。 要求された部屋が使用可能でない場合は、応答は、要求された時間スロットの間に使用可能な代りの部屋があるかどうか示す。

ＣＲノードからの応答はまた、要求された装置項目の各々が使用可能かどうかを示す。 本発明の好ましい実施例では、適当なデータ構造が会議召集者に返されるので、
第９図と同様な画面が構成されることが可能である。 その画面には会議室の名前が示され、使用可能という語の後に「はい」または「いいえ」という表示が現われ、項目が予約されたときは、予約されていることを示すＲ
が装置リストのＸに置き換わる。 代りの部屋が割り当てられた場合は、空白行に部屋の名前が入る。 使用可能な部屋がない場合は、要求された項目の状況は変わらない。

ＣＲノードで自動応答を発生させるには、部屋および装置の予約された状況、および代りの部屋は現状に維持されねばならないので、特定の時間および装置セットに対する要求を受け取ったとき、システムは論理的処理に従うことにより、正しいデータで自動的に応答することができる。

前出の特許出願番号（ＡＴ９−８６−０４４）に記載された自動応答を発生するための方法と関連して使用される自動応答データ構造が、部屋が使用可能か否かを示す自動応答をもたらすのに必要なデータを記憶するために、変更された形で使用される。

予約を要求する各会議通知への自動応答のため会議室ノードをセットアップする際、自動応答データ構造が使用される。 そのデータ構造では、会議通知により満たされた場合は事前設定された応答が会議召集者に返されるという基準が設定される。

返されるべき応答は、画面上に表示された複数の可能な応答から予定主が選択する。 この画面は第７図に示す画面と同様であり、ノードにおいて自動応答機能を確立するのを助けるために使用される。

この方法では、状況に応じてオプション１、３および５
が使用される。 ノードからの２つの潜在的な応答に対して、２つのＡＲＳデータ構造がノードで使用される。 別の状況は、通知および関連の構造が代りのノードに転送されることを必要とするだけである。 ＡＲＳ構造で使用される基準は１０またはそれより高い優先順位基準だけであり、したがって１０はシステムにおける可能な最低の優先順位であるので、全ての通知が受け入れられる。

システムは、システム上の個人が使用する予定表と同じように会議室用の予定表を維持する。 この会議室用予定表は、通常の動作過程で、１つの行事形式、すなわち、
会議のみが許される点が個人用予定表と異なる。

会議通知を受け取ったとき、ＣＲノードで行なわれる処理は、まず、それが１０またはそれより高い優先順位を有する会議データ構造であることを確認することである。 次のステップは、会議の日時期間に対応する予定表上の時間スロットを検査することである。 その時間スロットが空いている場合は、要求は尊重され、会議通知がＣＲ予定表上のその時間スロットと関連付けられる。 会議に割り当てられ、会議通知と関連付けられた名前トリプレットは、ノードにある論理的処理によって選択されたＡＲＳデータ構造からの正しい応答で更新される。

時間スロットの競合があった場合は、代りの部屋が識別されていない限り、論理処理は「ユーザ肯定応答」をもたらす。 代りの部屋が識別された場合は、データ構造は代りの部屋のアドレスに転送され、そこで、部屋が見つかるか、または否定形の応答が送られるまで、上記処理が反復される。 システムは、何が起きたかを召集者が知りたい場合に検査された会議室名のリストを維持する。

装置の要求に関連したノードで行なわれる特定の論理処理は部分的に、装置が物理的意味でどのように管理されているかによって決まる。 ある種の状況では、装置は永久的に記憶され、特定の部屋に割り当てられる。 その場合は、その部屋に対してなされた予約により、部屋の全ての装置が自動的に予約されることになる。 考えなければならない唯一の事態は、装置が動作不能であるか、または修理のためそこにない場合である。 この場合、ＣＲ
ノード主は、第９図に示すのと同様の画面を呼び出して、その項目に対する対応するＲＳＴデータ構造に反映される項目または他の適当なアクションを消去することにより、その部屋で使用不能な項目を示す。 したがって、ＣＲノードに関連するＲＳＲデータ構造はＲＳＲ構造を介して装置の状況を常に示すことができる。

したがって、論理処理は対応するＲＳＲ構造を単に比較し、それらが一致した場合は、召集者ノードで通知が再作成されるときに、ＸがＲに変更される。 したがって、召集者の要求は直ちに、かつ自動的に確認される。 ある装置項目が動作不能になった場合、システムは、前に応答された各通知を新しい状況で更新することができる。

論理処理の他の機能は、装置プールが一群の会議室に対して維持され、誰かが部屋の間の装置の移動を臨機に管理する責任を負っている状況に関するものである。 この状況では、各装置項目はそれ自体の予定表を有し、会議室用予定表と同じ方法でシステムによって管理される。

会議室ノードでの論理処理は、会議通知で指定された時間スロットについてＲＳＴトリプレットによって指定された項目の名前に対応する名前を有する装置用予定表を探索する。 その時間スロットが使用可能な場合は、会議データ構造および関連するデータ構造を参照して、項目が予定表上で作成される。 次に、論理処理は、召集者の会議通知と関連するＲＳＲデータ構造を更新し、次の構造が処理される。 プールは複数の同じ形式の項目を含むことができるので、各項目毎に異なる予定表が存在することになる。 １つの予定表上で時間スロットがふさがっている場合、他の予定表が検査される。

装置および補給を管理する人物は、どの装置がいつどこに属しているかを示す印刷出力をシステムによって規則的に供給されることができる。 もう１つの追加的な利点は、装置使用ログを作成できることであり、このログは、もっと装置が必要かどうか、および各項目にダウン時間があるかどうかを知る際の助けになる。

第１図および第１０図は、上述の処理を要約したフローチャートである。

会議室または装置により、両方の機能を選択的に１つのシステムに組み込むことももちろん可能である。

【図面の簡単な説明】 第１図および第１０図は要求された設備および装置の使用可能度を示す応答の発生に含まれる改善された電子式予定表管理方法の詳細ステップの互いに異なる部分を示すフローチャート、 第２図は本発明の方法を好適に使用することができる対話式データ処理端末を示すブロック図、 第３図は第２図に示した端末を複数備えたネットワークを示すブロック図、 第４図、第５図および第６図は行事を予定に入れている間に、情報を対話的にシステムに入力するため本発明の方法で階段的に使用される場合の互いに異なる段階における表示画面を示す平面図、 第７図は会議室の予定作成、装置の目録および自動応答に対して責任を負う人物により使用される表示画面を示す平面図、 第８図および第９図は会議室の要求が、予定された会議のために特定の装置を予約するための要求と共に入力される場合に段階的に使用される場合の互いに異なる段階における表示画面を示す平面図である。 １１……処理装置、１２……マイクロプロセッサ、１３
……メモリ、１４……制御装置、１６……表示装置、１
７……キーボード、１８……印刷装置、１９……ディスク記憶装置、２０……モデム、２１、２６……対話式ワークステーション・ネットワーク、２３、２５……ホスト中央処理装置、２４……通信リンク。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ハリンダー・エス・スイング アメリカ合衆国フロリダ州ボカ・ラトン、 カリカルデイ・レーン10722番地 (56)参考文献 特開 昭59−200557（ＪＰ，Ａ) 特開 昭60−103479（ＪＰ，Ａ) 特開 昭61−267163（ＪＰ，Ａ) 特開 昭62−260264（ＪＰ，Ａ) ＩＢＭ Ｔｅｃｈｎｉｃａｌ Ｄｉｓｃ ｌｏｓｕｒｅ Ｂｕｌｌｅｔｉｎ Ｖｏ ｌ． 26 Ｎｏ． 12 Ｍａｙ1984 ＰＰ. 6447−6449 ＩＢＭ Ｔｅｃｈｎｉｃａｌ Ｄｉｓｃ ｌｏｓｕｒｅ Ｂｕｌｌｅｔｉｎ Ｖｏ ｌ． 29 Ｎｏ． ８ Ｊａｎ． 1987 ＰＰ. 3392−3394