JPH0640331B2 - 予定表管理方法 - Google Patents

Description

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

Ｂ．参照出願 １．「対話方式下で入力された基準に基づいて他の複数
の異なる電子式予定表からの予定項目を同時に表示する
ための方法（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

Claims (1)

【特許請求の範囲】
1. 【請求項１】ホスト処理装置に直接又は間接に接続され
   た複数の対話型ワークステーションを備えるデータ処理
   システムで使用され、予定主が会議型行事を予定表にて
   予定する時点で、指定時間帯に特定の会議室で行なわれ
   る予定の会議型行事に他の予定主を出席要請するために
   前記システムを介して会議通知を特定のシステム・アド
   レスに対して発することができ、前記システム・アドレ
   スの１つには前記会議室の利用可能状態を維持するため
   の会議室予定表が割当てられ、会議通知を発した前記予
   定主に前記会議室が利用可能かどうか及び会議室ではど
   のような設備機器類が利用可能かを示す回答が前記会議
   室予定表が割当てられたシステム・アドレスにて自動的
   に発せられる、予定表管理方法であって、 (a) (a1)会議型行事を含む異なる型の予定事項を特定し、 (a2)前記システム中に対話方式下で入力され、予定事項
   の更に詳細な内容を特定して前記システムの処理を援助
   するデータを保持し、 (a3)会議通知の受信に応答して、前記会議室及び前記設
   備機器類の利用可能性を示す自動回答を発生させる、 複数のデータ構造体を形成するデータ構造体形成ステッ
   プと、 (b)予め設定されたシステム・アドレスにおいて、 会議室の利用可能状態を示すための複数の時間帯を含む
   指定された会議室に関する予定表を維持する会議室予定
   表維持ステップと、 (c)各々が前記自動回答が発生される前に会議通知に突
   き合わされる同じ判断基準を特定しかつ各々が異なる回
   答を指示する２つの同様な前記データ構造体から成る少
   なくとも１つのデータ構造体の組中に、データを前記シ
   ステム中に対話方式下で入力する判断基準入力ステップ
   と、 (d)前記会議室予定表上の会議時間に対応する時間帯が
   利用可能か否かによって前記データ構造体の組の１つの
   データ構造体を選択するデータ構造体選択ステップと、 を備えている前記予定表管理方法。