(57)【要約】  ハンドヘルドＰＤＡ（１１０）アプリケーション用およびハンドヘルドアプリケーションのユーザ用のシステム、方法、ソフトウェアアーキテクチャ／プログラム（１０）が、物理的に離れた通信装置とのリアルタイムの無線コラボレーション会議を実行する。有利なことに、プログラム（１０）はハンドヘルドアプリケーションに大きな変更を与えることなく無線コラボレーション会議を提供する。ハンドヘルドアプリケーションは内部状態を更新し、他の参加者の装置の内部状態をコピーする。無線コラボレーションソフトウェアは、データ通信帯域幅に対して最適化され、本質的にハンドヘルドのアプリケーションを用い、それらの動作とハンドヘルド装置のメトリックスに適合し、小さな情報パケットを用いて通信し、ピアツーピア、ピアツーマルチピア、ピアツーマシンアプリケーション会議にとって共通のプログラミング可能なユーザインタフェースを提供し、そのソフトウェアは、エンドユーザがそのような会議を計画、共有、管理し、そして請求されることを可能とする無線コラボレーション会議方法を実施する。
2005509960.tif 000002
【特許請求の範囲】
【請求項１】
ＰＤＡ読取り可能な媒体上で実行可能な無線コラボレーションソフトウェアプログラムであって、
ほとんどリアルタイムに、物理的に離れた通信装置に常駐する他の無線コラボレーションソフトウェアプログラムと無線で通信することが可能な会議及びコラボレーションプロトコル（ＣＣＰ）を備える
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項２】
請求項１に記載の無線コラボレーションソフトウェアプログラムであって、
ＣＣＰが、ＰＤＡアプリケーションへの大きな変更なしに、物理的に離れた装置上で動作している共通のアプリケーションとともに、ＰＤＡ上で動作するアプリケーションのデータを無線でコラボレーションし得る
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項３】
請求項２に記載の無線コラボレーションソフトウェアプログラムであって、
ＣＣＰが、物理的に離れた通信装置の内部状態を再現するため、ＰＤＡの内部状態を更新し得る
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項４】
請求項３に記載の無線コラボレーションソフトウェアプログラムであって、
ＣＣＰが、データ及びスクリーン情報をコラボレーションし得る
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項５】
請求項４に記載の無線コラボレーションソフトウェアプログラムであって、
ＣＣＰが、受信したデータ情報を処理している間に、受信したスクリーン情報が選択的にフィルタリングされることを可能にする
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項６】
請求項１に記載の無線コラボレーションソフトウェアプログラムであって、さらに、
ＣＣＰに実行されるアプリケーションプログラムインタフェース（ＡＰＩ）を備える
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項７】
請求項６に記載の無線コラボレーションソフトウェアプログラムであって、
ＣＣＰが、離れた通信装置と非同期的に交換データを通信できる
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項８】
請求項６に記載の無線コラボレーションソフトウェアプログラムであって、さらに、
ＡＰＩによって実行されるＣＣＰシステムライブラリを備える
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項９】
請求項８に記載の無線コラボレーションソフトウェアプログラムであって、
ＣＣＰシステムライブラリが離れた通信装置と通信するＣＣＰの会議メッセージを処理する
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項１０】
請求項９に記載の無線コラボレーションソフトウェアプログラムであって、
会議メッセージが、会議プロトコルメッセージ、システム更新メッセージ、システム編集メッセージ及びシステム更新メッセージから構成される
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項１１】
請求項１０に記載の無線コラボレーションソフトウェアプログラムであって、
会議メッセージが構造化されたバイトセットで構成される
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項１２】
請求項８に記載の無線コラボレーションソフトウェアプログラムであって、さらに、
ＣＣＰシステムライブラリによって生成される特定のイベントを処理するＣＣＰイベントハンドラを備える
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項１３】
請求項１２に記載の無線コラボレーションソフトウェアプログラムであって、
複数の機能ブロックを備え、
ＣＣＰイベントハンドラが、既存のそして新たな前記機能ブロックに対する特定イベントを処理する
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項１４】
請求項１に記載の無線コラボレーションソフトウェアプログラムであって、
無線コラボレーションソフトウェアプログラムが、通信の際に、自動的に他の無線コラボレーションソフトウェアプログラムに文書を送信することができ、
その文書は、ＰＤＡ及び物理的に離れた通信装置双方によって編集可能である
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項１５】
請求項１に記載の無線コラボレーションソフトウェアプログラムであって、
アプリケーションが既製のアプリケーションである
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項１６】
請求項１に記載の無線コラボレーションソフトウェアプログラムであって、
離れた通信装置が他のＰＤＡである
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項１７】
請求項１に記載の無線コラボレーションソフトウェアプログラムであって、
離れた通信装置がデスクトップコンピュータである
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項１８】
請求項１に記載の無線コラボレーションソフトウェアプログラムであって、
離れた通信装置がライブフィードゲートウェイである
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項１９】
離れた通信装置と、ほとんどリアルタイムに無線でコラボレーションすることができるＰＤＡであって、
メモリ、ＣＰＵ、ＰＤＡオペレーティングシステムと、
ＰＤＡによってロードされ、実行される無線コラボレーションソフトウェアプログラムであって、
物理的に離れた通信装置上に常駐する他の無線コラボレーションソフトウェアプログラムと無線で通信する会議及びコラボレーションプロトコル（ＣＣＰ）を備える無線コラボレーションソフトウェアプログラムとを備える
ことを特徴とするＰＤＡ。
【請求項２０】
請求項１９に記載の無線コラボレーションソフトウェアプログラムであって、
ＣＣＰが、ＰＤＡアプリケーションへの大きな変更なしに、物理的に離れた装置上で動作している共通のアプリケーションとともに、ＰＤＡ上で動作するアプリケーションのデータを無線でコラボレーションし得る
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項２１】
請求項１９に記載の無線コラボレーションソフトウェアプログラムであって、
ＣＣＰが、物理的に離れた通信装置の内部状態を再現するために、ＰＤＡの内部状態を更新し得る
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項２２】
請求項２０に記載の無線コラボレーションソフトウェアプログラムであって、
ＣＣＰが、データ及びスクリーン情報をコラボレーションし得る
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項２３】
請求項２１に記載の無線コラボレーションソフトウェアプログラムであって、
ＣＣＰが、受信したデータ情報を処理している間に、受信したスクリーン情報が選択的にフィルタリングされることを可能にする
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項２４】
請求項１９に記載の無線コラボレーションソフトウェアプログラムであって、さらに、
ＣＣＰによって実行されるアプリケーションプログラムインタフェース（ＡＰＩ）を備える
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項２５】
請求項１９に記載の無線コラボレーションソフトウェアプログラムであって、
ＣＣＰが、離れた通信装置と非同期的に交換データを通信できる
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項２６】
請求項２４に記載の無線コラボレーションソフトウェアプログラムであって、
ＡＰＩによって実行されるＣＣＰシステムライブラリを備える
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項２７】
請求項２６に記載の無線コラボレーションソフトウェアプログラムであって、
ＣＣＰシステムライブラリが、離れた通信装置と通信するＣＣＰの会議メッセージを処理する
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項２８】
請求項２７に記載の無線コラボレーションソフトウェアプログラムであって、
会議メッセージが、会議プロトコルメッセージ、システム更新メッセージ、システム編集メッセージ及びシステム更新メッセージから構成される
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項２９】
請求項２７に記載の無線コラボレーションソフトウェアプログラムであって、
会議メッセージが構造化されたバイトセットで構成される
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項３０】
請求項２６に記載の無線コラボレーションソフトウェアプログラムであって、さらに、
ＣＣＰシステムライブラリによって生成される特定のイベントを処理するＣＣＰイベントハンドラを備える
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項３１】
請求項３０に記載の無線コラボレーションソフトウェアプログラムであって、さらに、
多数の機能ブロックを備え、
そのＣＣＰイベントハンドラは既存のそして新たな前記機能ブロックに対する特定のイベントを処理する
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項３２】
請求項１９に記載の無線コラボレーションソフトウェアプログラムであって、
ＣＣＰが、通信の際に、離れた通信装置上に常駐する別の無線コラボレーションソフトウェアプログラムに自動的に文書を送信できる
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項３３】
請求項１９に記載の無線コラボレーションソフトウェアプログラムであって、
アプリケーションが既製のアプリケーションである
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項３４】
請求項１９に記載のＰＤＡであって、
無線コラボレーションソフトウェアプログラムが、ほとんどリアルタイムに他の離れたＰＤＡとコラボレーションし得る
ことを特徴とするＰＤＡ。
【請求項３５】
請求項１９に記載のＰＤＡであって、
無線コラボレーションソフトウェアプログラムが、ほとんどリアルタイムにデスクトップコンピュータとコラボレーションし得る
ことを特徴とするＰＤＡ。
【請求項３６】
請求項１９に記載のＰＤＡであって、
無線コラボレーションソフトウェアプログラムが、ほとんどリアルタイムにライブフィードゲートウェイとコラボレーションし得る
ことを特徴とするＰＤＡ。
【請求項３７】
ＰＤＡと物理的に離れた通信装置との間でほとんどリアルタイムに無線コラボレーティングする方法であって、
ＰＤＡが、最初の常駐プログラムを実行して、ほとんどリアルタイムに無線でコラボレーションするために、同じく最初の常駐プログラムを実行する物理的に離れた通信装置とコラボレーションする
ことを特徴とする無線コラボレーティング方法。
【請求項３８】
請求項３７に記載の無線コラボレーティング方法であって、
各ＰＤＡと物理的に離れた通信装置が、共通のアプリケーションを走らせ、前記無線コラボレーションが、ＰＤＡまたは物理的に離れた通信装置のアプリケーションを大きく変更させることなく行われる
ことを特徴とする無線コラボレーティング方法。
【請求項３９】
ＰＤＡがそのＰＤＡ上で実行可能な無線コラボレーションソフトウェアプログラムを備える請求項３７に記載の無線コラボレーティング方法であって、
会議及びコラボレーションプロトコル（ＣＣＰ）が、離れた通信装置上に常駐する他の前記無線コラボレーションソフトウェアプログラムとほとんどリアルタイムに通信できる
ことを特徴とする無線コラボレーティング方法。
【請求項４０】
請求項３９に記載の無線コラボレーティング方法であって、
コラボレーションソフトウェアプログラムが、離れた通信装置上に常駐し、離れた通信装置によって実行される
ことを特徴とする無線コラボレーティング方法。
【請求項４１】
請求項３７に記載の無線コラボレーティング方法であって、
ＰＤＡが、物理的に離れた通信装置の内部状態を再現するためにその内部状態を更新し得る
ことを特徴とする無線コラボレーティング方法。
【請求項４２】
請求項３８に記載の無線コラボレーティング方法であって、
ＰＤＡがデータ及びスクリーン情報をコラボレートできる
ことを特徴とする無線コラボレーティング方法。
【請求項４３】
請求項３９に記載の無線コラボレーティング方法であって、
ＰＤＡが、受信したスクリーン情報が、受信したデータ情報を処理している間に選択的にフィルタリングされるようにし得る
ことを特徴とする無線コラボレーティング方法。
【請求項４４】
請求項３９に記載の無線コラボレーティング方法であって、
無線コラボレーションソフトウェアプログラムが、ＣＣＰに実行されるアプリケーションプログラムインタフェース（ＡＰＩ）を備える
ことを特徴とする無線コラボレーティング方法。
【請求項４５】
請求項３５に記載の無線コラボレーションソフトウェアプログラムであって、
ＣＣＰが、離れた通信装置と非同期的に交換データを通信し得る
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項４６】
請求項３９に記載の無線コラボレーションソフトウェアプログラムであって、
コラボレーションソフトウェアプログラムが、さらにＡＰＩによって実行されるＣＣＰシステムライブラリを備える
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項４７】
請求項４６に記載の無線コラボレーションソフトウェアプログラムであって、
ＣＣＰシステムライブラリが、離れた通信装置と通信するＣＣＰの会議メッセージを処理する
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項４８】
請求項４７に記載の無線コラボレーションソフトウェアプログラムであって、
会議メッセージが、会議プロトコルメッセージ、システム更新メッセージ、システム編集メッセージ及びシステム更新メッセージから構成される
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項４９】
請求項４８に記載の無線コラボレーションソフトウェアプログラムであって、
会議メッセージが構造化されたバイトセットから構成される
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項５０】
請求項３９に記載の無線コラボレーションソフトウェアプログラムであって、
コラボレーションソフトウェアプログラムが、さらにＣＣＰシステムライブラリによって生成される特定のイベントを処理するＣＣＰイベントハンドラを備える
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項５１】
請求項３９に記載の無線コラボレーションソフトウェアプログラムであって、
コラボレーションソフトウェアプログラムが、さらに多数の機能ブロックを備え、
ＣＣＰイベントハンドラが、既存のそして新たな前記機能ブロックの呼び出しを行う  
ことを特徴とする無線コラボレーションソフトウェアプログラム。
【請求項５２】
請求項３７に記載の無線コラボレーティング方法であって、さらに、
ホストとして定義されるＰＤＡが、無線コラボレーションを開始するために物理的に離れた通信装置に対して自動的に最初の文書を送信するステップを有する
ことを特徴とする無線コラボレーティング方法。
【請求項５３】
請求項３７に記載の無線コラボレーティング方法であって、さらに、
物理的に離れた通信装置がホストとして定義され、無線コラボレーティングを開始するためにＰＤＡに対して自動的に最初の文書を送信する
ことを特徴とする無線コラボレーティング方法。
【請求項５４】
請求項３７に記載の無線コラボレーティング方法であって、
共通のアプリケーションが既製のアプリケーションである
ことを特徴とする無線コラボレーティング方法。
【請求項５５】
請求項３７に記載の無線コラボレーティング方法であって、
離れた通信装置が他のＰＤＡである
ことを特徴とする無線コラボレーティング方法。
【請求項５６】
請求項３７に記載の無線コラボレーティング方法であって、
離れた通信装置がデスクトップコンピュータである
ことを特徴とする無線コラボレーティング方法。
【請求項５７】
請求項３７に記載の無線コラボレーティング方法であって、
離れた通信装置がライブフィードゲートウェイである
ことを特徴とする無線コラボレーティング方法。
【請求項５８】
請求項５２に記載の無線コラボレーティング方法であって、
最初の文書が、ＰＤＡと物理的に離れた通信装置双方によって編集可能である
ことを特徴とする無線コラボレーティング方法。
【請求項５９】
請求項５３に記載の無線コラボレーティング方法であって、
最初の文書が、ＰＤＡと物理的に離れた通信装置双方によって編集可能である
ことを特徴とする無線コラボレーティング方法。
【請求項６０】
請求項３７に記載の無線コラボレーティング方法であって、さらに、
ＰＤＡが、コラボレーション中に、物理的に離れた通信装置と非同期的に音声通信を行う
ことを特徴とする無線コラボレーティング方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、無線会議（ｗｉｒｅｌｅｓｓ  ｃｏｎｆｅｒｅｎｃｉｎｇ）に関し、特に、無線の情報交換を実現するハンドヘルドコンピュータ（ｈａｎｄｈｅｌｄ  ｃｏｍｐｕｔｅｒ）、２またはより多くのユーザの間で無線プラットホームを通じてリアルタイムあるいはほとんどリアルタイムに同時に情報を交換、処理そして参照するシステム、ソフトウェアプログラムおよび方法に関する。
【背景技術】
【０００２】
会議システムは、別々の場所にいる複数の人々に一つのあるいは様々な議題についてコラボレーション（ｃｏｌｌａｂｏｒａｔｅ）することを可能にする現在では、少々ありふれたメカニズムである。電話会社及び他の業者は、伝統的な電話線に基づいて、声による電話会議を提供する。ビデオ会議も用いられるが、ビデオ器材のコスト及び帯域幅の問題のため予想されたほど急速には主流になっていない。シマンテック社のｐｃＡｎｙｗｈｅｒｅやマイクロソフト社のＮｅｔｍｅｅｔｉｎｇのようなコンピュータベースの会議も何年も前から存在し、共有のソフトやファイルを通じて、ＰＣユーザのコラボレーションを可能にしてきた。その結果、ウェブコラボレーション会議（ｗｅｂ  ｃｏｌｌａｂｏｒａｔｉｏｎ  ｃｏｎｆｅｒｅｎｃｉｎｇ）が可能になり、標準ウェブプロトコル及びインターネット接続を通じてアプリケーション及び内容のコラボレーションがなされることを可能にしている。
【０００３】
コラボレーション会議は、２またはより多くの参加者の間で同時的に通信することができる。通信メディアは、ワープロ、スプレッドシートまたはプレゼンテーションといった、あらゆる可能なソフトアプリケーションである。会議の複数の参加者は、スライドのセットを用いたプレゼンテーションのようなメディアを通じて会話することが可能である。各参加者は同時にスライドをみることになる。次の段階の通信では、参加者が変更を加え、全ての参加者のコンピュータに再生することが可能となる。スプレッドシート上で作業する参加者がその例である。
【０００４】
いくつかの会社は、音声とデータの両方を含んだ有線コラボレーション会議を開発している。コラボレーション会議は、３つあるいはそれ以上の理由からモバイルのハンドヘルドコンピュータへの参加を排除してきた。帯域幅の制限はデスクトップを用いた会議方式は、通常アプリケーションそのものよりもスクリーンシェアリングに依存していることを理由とする。スクリーンサイズの問題は、デスクトップメタファーは典型的なハンドヘルドの２×３インチスクリーン、そして、高速ネットワーク及び会議を同期させる最適切り替えに依存する有線コラボレーション通信に適合しないからである。
【０００５】
帯域幅による制限は、広域ネットワークのインフラの制限によるものである。無線広域ネットワークデータ送信には、複数の競合する標準が存在する。現在の最大限広い帯域幅は毎秒９８００から１９２００ビットの間である。通称３Ｇ下のこれらのグループのようなより高速の技術も、時には開発されたが、未だ広く使われるにはいたっておらず、限られた地域で使用可能になりつつある。さらに最も待望された３Ｇシステムは、最適且つ最大の帯域幅及び無線帯域幅のキャパシティが限られてきたときのための最小送信速度を提供する。
【０００６】
スクリーンサイズの問題は、モバイルハンドヘルドコンピュータのフォーム要素に起因する。これらの装置は典型的にはおおよそ２×２から２×４のスクリーンを持っている。モバイルハンドヘルドコンピュータ上に表示されるどんな情報も小さなスクリーンサイズに合うようにフォーマットされる。有線のコラボレーション通信方法は、参加者たちが共有された情報を参照可能にするために構築されている。
【０００７】
そのアプリケーションは実際には参加者たちのコンピュータ上で動作していない。実際には、参加者たちはホストマシン上で動作するアプリケーションの概要を見ている。その情報は各参加者のコンピュータに局所的に格納されるのではない。スクリーンがプレゼンテ−ション中に、次のスライドに移るなど変化した時、参加者は次のスライドを見せられる。こうしたタイプのコラボレーションは、大きな帯域幅、信頼性のあるコネクション、そして複雑なスイッチングを要する。
【０００８】
無線ハンドヘルドコンピュータの制約問題に対処しつつ、コラボレーション会議を実現するハンドヘルドアプリケーションを実現するシステム、方法、そしてソフトウェアキテクチャ／プログラムが望まれる。更に、スクリーンディスプレイ／シェアリングを超えてハンドヘルドオペレーティングシステムを強化し、会議の前、会議中、会議の後に有用である豊富な機能を限られた帯域量またはビット量で提供し、そのようなコラボレーションが実現されたアプリケーションを発展させる共通の方法を提供するアプリケーションを実現するソフトウェアプログラムとインタフェースが望まれる。これは、ハンドヘルドアプリケーションを用いて、１または複数のユーザまたはマシンを無線的に関連付けることができるようにする。本発明はそのようなシステム、ソフトウェアプログラムそして方法を提供する。
【発明の開示】
【０００９】
（発明の要旨）
本発明はハンドヘルドアプリケーションおよびハンドヘルドアプリケーションのユーザに、無線ハンドヘルドコンピュータの制約問題に対処し、アプリケーション自体に大きな変更を加えることなくサービスを提供するためのシステム、方法、そしてソフトウェアアーキテクチャ／プログラムを実現するという技術上の有利な点を有する。
【００１０】
ソフトウェアプログラム、アーキテクチャそしてインタフェースは、既製のアプリケーションをして、データを処理し、オンラインおよびオフラインで表示するハンドヘルドのオペレーティングシステムを強化し得るようにし、限られた帯域量またはビット量を用いて、会議の前、会議中、そして会議後に役立つ豊富な機能を提供し、そのようなコラボレーションを実現できるアプリケーションを発展させる共通の方法を提供する。
【００１１】
このシステムは、データ通信の帯域に適合し、ハンドヘルドの動作そしてメトリックスに合った本質的にハンドヘルドのアプリケーションを用い、小さな情報パケットを用いて通信し、ピアツーピア、ピアツーマルチピア、そしてピアツーマシンアプリケーション会議のための共通のプログラミング可能なユーザインタフェースとエンドユーザがそのような会議活動をスケジュールでき、共有でき、管理でき、請求されるシステムを提供する無線コラボレーション会議方法を実現する。
【００１２】
このアーキテクチャは、２つの明らかに相互関係のある会議モードを実現する。１つのモードでは、全てのユーザは文書を修正する平等の権利を有し、コラボレーションしてその修正を行う。ハンドヘルド装置は、本発明によって他の参加者たちの装置上の内部状態とデータ構造を再現するために内部状態とデータ構造を更新できるようにするデータ編集メッセージを受信する。別のモードでは、全ての参加者たちからプレゼンテーションの権利を許可された“プレゼンター”のみが、各参加者たちのハンドヘルド装置が単一のプレゼンターによって制御されるようにするためのディスプレイ更新メッセージを制御する。このモードでは、ハンドヘルド装置は全てプレゼンターのふるまい、スクリーンロケーション、スクローリング、そして表示を再現する。双方のケースにおいて、本発明はこれらの状態を制御し、調整できる明確なメカニズムを提供する。
【発明を実施するための最良の形態】
【００１３】
図１に、無線環境における本発明によってもたらされる１０で示されるいくつかの無線コラボレーション会議のブロックが図示される。このシステムは、データ通信帯域を最適化する無線コラボレーション会議方法を実現し、ハンドヘルドの動作とメトリックスに適合する本質的にハンドヘルドなアプリケーションを用い、小さな情報パケットを用いて通信し、ピアツーピア、ピアツーマルチピア、そしてピアツーマシンのアプリケーション会議にとって共通のプログラミング可能なユーザインタフェースと、エンドユーザがそのような会議活動のために計画、共有、管理でき、そして請求されるシステムを提供する。
【００１４】
アプリケーションプログラミングインタフェース（ＡＰＩ）として具現化される本発明の第１の実施の形態は、そのようなインタフェースを複数の単一ソフトウェアベンダー（ＩＳＶＳ）が利用して、無線会議がそれらのアプリケーションを利用できるようにする。共通のプログラミングされたインタフェース、共通のユーザインタフェース、共通のイベント、そして、内部メカニズム／アーキテクチャは、ＩＳＶＳが、エンドユーザに共通の使用モデルを与えるスタンドアローンアプリケーション中に組み込まれたそのような機能を内蔵できるようにする。この使用の一例は、スタンドアロンに記述されたアプリケーションを発展させたＩＳＶである。有用なことに、ユーザ１２は、本発明を用いることによって、それらのアプリケーションが１又は複数のユーザ間の無線通信を実現できるようにし、全てのユーザが１４および１６において示される図形を見ることができ、修正できるようにする。
【００１５】
本発明の第２の実施の形態は、データを提供しているマシン１８と会議システムを用いて無線通信をしているハンドヘルドコンピュータ１２上で動作するソフトウェアプログラムからなる。ユーザ１２はその複数のマシンの共通のインタフェースによって生成され、そしてそのようなユーザを安全にし、あるいは公にアクセスできるように配置されたゲートウェイ経由で会議サーバに送信されるリアルタイムまたはほとんどリアルタイムの情報を監視できる。ハンドヘルドのアプリケーションは、コンテンツをグラフィカルに表示し、データ操作を許し、そして、そのマシンに入力と制御を戻すことさえ行うソフトウェアプログラムを用いて、そのデータストリームを表示する。有用なことに、そのような使用は、例えば、医者に、電話を通じて病院と通信して、リアルタイムに患者のＥＫＧと重大なサインを監視させることができ、その結果、より正確な診断と治療を行うことができるようになる。別の例では、建築物管理者が空調および電気設備に連絡して、建築物の重大なサインを監視し、設定調整のための入力をそれらの機器に行わせる。
【００１６】
ソフトウェアプログラムとして構成される本発明の第３の実施の形態は、実行情報が行き交うように構成されたハンドヘルドコンピュータにおいて動作する。そのソフトウェアはスプレッドシートのようなハンドヘルドの生産アプリケーションを含む。無線ハンドヘルド会議の参加者たちは、それぞれ“ホスト”１６と呼ばれる参加者からハンドヘルドコンピュータに自動的に送信されたスプレッドシートのコピーを持っている。会議の参加者たちは、スプレッドシートを変更することができる。全ての参加者たちは各参加者たちのハンドヘルドコンピュータからの全ての入力を受信する。スプレッドシートの再計算は各参加者たちの装置の処理力の一部を利用することにより実行される。有用なことに、今日広く利用できる限られた帯域技術を用いてアプリケーション会議動作を行うハンドヘルドコンピュータ間では入力のみが伝送される。“コラボレーション”モードでは、会議の参加者たちはワークブックのどこでも、ワークブック内のセパレートシート上においても変更を加えることができる。全ての変更は会議に参加している全ての装置に送信される。“プレゼンター”モードにおいては、１人の参加者がプレゼンテーションを制御できる。そのプレゼンターは、会議の参加者全員に情報を提示するために、上下左右にスクロールでき、シートを変更でき、ズームを変更できる。あるいは、１または複数のユーザ１２、１４と１６との間の会議が、ｗｅｂＥＸ２４のソフトウェア、チャセラル２６のソフトウェアあるいはマイクロソフトネットミーティング２８のソフトウェアを用いてデスクトップゲートウェイ２０経由でＰＣリンクを持つユーザ２２との会議と同様に実現される。
【００１７】
ソフトウェアプログラムからなる本発明の第４の実施の形態は、実行情報が行き交うように構成されたハンドヘルドコンピュータにおいて動作する。そのソフトウェアはワードプロセッサのようなハンドヘルドの生産アプリケーションを含む。それぞれの無線ハンドヘルド会議の参加者たちは、“ホスト”としての参加者から自動的にハンドヘルドコンピュータに送信された文書のコピーを有する。会議の参加者たちは、その文書に変更を加えることができる。全ての参加者たちは、各参加者たちのハンドヘルドコンピュータから全ての入力を受信する。再フォーマットのためのその文書の再計算が、各参加者たちの装置の処理力を一部利用して実行される。有利なことに、今日広く利用できる限られた帯域技術を用いて会議活動を行う特殊なアプリケーションを提供するハンドヘルドコンピュータ間では、入力のみが伝送される。“コラボレーション”モードでは、会議の参加者たちはその文書のどこでも、その文書の分割された部分においてでさえ変更を加えることができる。全ての変更は、会議に参加している全ての装置に送信される。“プレゼンター”モードでは、１人の参加者がプレゼンテーションを制御する。プレゼンターは、会議の参加者全員に情報を“提示”するために上下にスクロールすることができる。
【００１８】
ソフトウェアプログラムからなる本発明の第５の実施の形態は、実行情報が行き交うように構成されたハンドヘルドコンピュータにおいて動作する。そのソフトウェアはスライドプレゼンテーション（例えばＰＣ用のマイクロソフトパワーポイント）のようなハンドヘルドの生産アプリケーションを含む。無線ハンドヘルド会議の参加者たちは、それぞれ、当初の“ホスト”である参加者から自動的にそれらのハンドヘルドコンピュータに送信された文書のコピーを有する。会議の参加者たちは、そのプレゼンテーションに変更を加えることができる。全ての参加者たちは、各参加者たちのハンドヘルドコンピュータからの全ての入力を受信する。プレゼンテーションスライドの表示のための描写は、各参加者たちの装置の処理力を一部利用して実行される。有利なことに、今日の広く利用可能な限られた帯域幅技術を用いた会議活動を行う特殊なアプリケーションを提供するハンドヘルドコンピュータの間では、入力のみが送信される。“コラボレーション”モードでは、会議参加者はプレゼンテーションのどこでも、分割されたスライドの中でも変更を行うことができる。全ての変更は、会議参加の装置全てに送信される。“プレゼンター”モードにおいては、一人の参加者がプレゼンテーションを主導する。プレゼンターは、会議参加者全てに対して情報を提供するために、上下にスクロールしたり、ズームインまたはズームアウトをし、アウトラインやノートのような異なる画面を見たり、スライドを転換したりすることができる。
【００１９】
本発明の第６の実施の形態は、２またはより多くのハンドヘルドユーザの無線会議のために、スケジューリング、設定確立、管理そして請求のためのシステムを提供する。このシステムは、典型的にはＴＣＰ／ＩＰを用いて、インターネットに通じていくサーバと接続することをハンドヘルドコンピュータに可能にするだけの送信能力をもったハンドヘルドコンピュータを用いてサーバと通信するクライアントのために、サーバ上で実施される。２またはより多くの参加者たちは、会議ＩＤ、ユーザネーム、そしてシステムが許可するパスワードを通じて、サーバに接続し、そして、自動的に会議文書を入手し、コラボレーション会議を開始する。
【００２０】
本発明の第７の実施の形態は、データ会議と共同作用する同時音声通信を提供する。これを発展させると、この発明に多用な商業的適用をもたらす。ハードウェアおよびソフトウェア形態のデータ運搬部により提供される同時音声およびデータ（ＳＶＤ）は、これからの２、３年で商業的に展開され、本発明をして現在の有線会議システムのように、同時に話し、データを共有してユーザの経験を高めることを可能にすることが期待される。
【００２１】
図２に言及すると、本発明による無線コラボレーション会議は、ＰＤＡ１００を含む無線コラボレーション会議動作を行う各装置に常駐するアプリケーションプログラム１１０により可能となる。アプリケーションモジュール１１０は、最初に概括的に次に詳しく説明される様々なモジュールを含んでいる。
【００２２】
パーソナルデジタルアシスタント／ハンドヘルドコンピュータ（ＰＤＡ）１００は、システムおよびユーザインタフェース機能、ストレージ、プログラム実行のためのメモリー、中央処理装置、オペレーティングシステムを内蔵している。
【００２３】
アプリケーションプログラム１１０は、コラボレーションまたは会議技術によって高まる機能を実行する。
【００２４】
デスクトップコンピュータ２００は、システムおよびユーザインタフェース機能のためのメモリー、中央処理装置、オペレーティングシステムを内蔵している。
【００２５】
イベントループ１１１は、プログラム１１０により実行されるキューの活動を処理する。
【００２６】
会議コラボレーションプロトコル（ＣＣＰ）イベントハンドラ１２０は、ＣＣＰシステムライブラリ１６０により生成される特定のイベントを処理し、そしてまたプログラム内の既存または新しい機能ブロック１３０を呼び出す。
【００２７】
アプリケーションプログラム機能ブロック１３０は、アプリケーションプログラム内で活動するコード部分である。
【００２８】
ＣＣＰシステムライブラリ１６０は、ＣＣＰＡＰＩ１７０を実行し、会議プロトコルメッセージ（１６１）、データ編集フィルタメッセージ（ＤＥＭｓ）（１６２）、ディスプレイ更新メッセージ（ＤＵＭｓ）（１６３）を処理し、コネクションを管理する。
【００２９】
ＣＣＰＡＰＩ１７０は、アプリケーションプログラムが実行し、プログラム内にＣＣＰの機能を内蔵するために用いる会議及びコラボレーションアプリケーションプログラミングインタフェースである。
【００３０】
会議及びコラボレーションセッション３００は、２またはより多くの接続されたＰＤＡ１００またはＣＣＰＡＰＩ１７０を実行するデスクトップコンピュータの間で非同期的にデータ送信を行う。
【００３１】
またさらに図２に言及すると、ＣＣＰシステムメッセージ１６１は、その全体に簡潔に提供された会議及びコラボレーションプロトコル中に記述されたフォームを引き継ぐ。
【００３２】
ＣＣＰデータ編集メッセージ（ＤＥＭ）１６２及びＣＣＰディスプレイ更新メッセージ（ＤＵＭ）１６３も、会議及びコラボレーションプロトコルの中で記述されたフォームを引き継いでいる。データ編集メッセージ１６２（ＤＥＭ）は遠隔のコンピュータによってデータの状態を更新するために用いられるデータブロックを分類するのに用いられ、これに対して、ＣＣＰティスプレイ更新メッセージ（ＤＥＭ）１６３は、そのビューの状態の更新に用いられる。その違いは、遠隔のユーザが、ユーザがコラボレーションデータに変更を加えた場合もユーザのディスプレイが一貫するように、ＤＵＭｓ１６３の受信をフィルタリングし得るところにある。ＣＣＰアプリケーションプログラムインタフェース（ＡＰＩ）１７０は、その全体に簡潔に提供された会議及びコラボレーションＡＰＩの中で記述されたフォームを引き継いでいる。
【００３３】
ＰＤＡ１００上で動作する各アプリケーションプログラム１１０は、独自に有益なプログラムとなるための適当な動作及び機能を有するスタンドアロンのプログラムである。  ＣＣＰシステムライブラリ１６０によって、拡張され高められることによって、ＣＣＰシステムライブラリ１６０が実行するＴＣＰ／ＩＰ，赤外線、ＢＬＵＥＴＯＯＴＨあるいは、他の全ての通信プロトコルを経由して、遠隔接続しているＰＤＡ１００上の同じアプリケーションプログラム１１０と非同期的に通信することが可能となる。ＣＣＰシステムライブラリ１６０が、そのようにするために、ＣＣＰＡＰＩ１７０を規定しているので、低いレベルの通信は、その存在が意識されない。
【００３４】
ＣＣＰイベントハンドラ１２０は、データ編集メッセージ（ＤＥＭ）１６２をデコードし、アプリケーションプログラム機能ブロック１３０を呼び出す。有利なことに、このようにすることで、各アプリケーションプログラム１１０は、作動中のデータは局地的に発生したものであると信じられ、そしてまた、アプリケーションプログラム１１０をして更なる変更をすることなく必要な動作を実行することを可能にするのである。例えば、ＣＣＰライブラリ１６０は、スプレッドシートのセル上での動作をもたらす内部のアプリケーションプログラム１１０のメモリ構造をラップするためのＣＣＰＡＰＩ１７０の実行によってコード化されるデータ編集メッセージ１６２を受け取る。ＣＣＰイベントハンドラ１２０は、このＤＥＭ１６２を解凍し、ローカルメモリ内の同じ構造に適合させる、そして、そのデータ上で動作するため、アプリケーションプログラム機能ブロック１３０を呼び出す。その結果、既存のアプリケーションプログラムをほとんど変更することなく、あるいは全く変更することなく、遠隔地で発生したデータ上で作動する。このような簡潔さは、強力なユーザーインタフェース動作によって変更されたデータを送信し、逆処理を通じて複数の参加者たちのハンドヘルド上で同様のインタプリタを行い、したがって、プログラムがユーザが入ったデータ上またはユーザインタフェースの入力上で既に動作しているのと同様のあるいは同じ方法で、変更されたデータ上でのみ動作することによってもたらされる。どのデータを入力し、どのインタフェースイベントを送信し、そして応答すべきかは、発明の構成、技術の先導及びほとんどこれらプログラムが既に処理していたのと同じ動作とのみ関係するＣＣＰＡＰＩ１７０の実施により簡潔化される。
【００３５】
ＣＣＰイベントハンドラ１２０は、ディスプレイ更新メッセージ１６３をデコードし、アプリケーションプログラム機能ブロック１３０を呼び出す。このようにすることで、各アプリケーションプログラムは、そのアプリケーションプログラムが動作しているデータは、局地的に発生していると信じられ、アプリケーションプログラムをしてそれ以上の変更をすることなく必要な動作を遂行することを可能にする。例えば、スクリーンタップのようにディスプレイ上での動作をもたらす内部のアプリケーションプログラム１１０のメモリー構造をラップするためのＣＣＰＡＰＩ１７０の実施によってコード化されるディスプレイ更新メッセージ１６３をＣＣＰライブラリ１６０が受け取ると、ＣＣＰイベントハンドラ１２０は、このＤＵＭ１６３を解凍し、同じローカルメモリ構造に適合させ、そのデータ上で動作するためアプリケーションプログラム機能ブロック１３０を呼び出す。その結果、既存のアプリケーションプログラムをほとんど変更することなく、あるいは全く変更することなく、遠隔で発生したデータ上で動作し、アプリケーションプログラムをして遠隔ユーザーがローカルアプリケーションプログラム１１０のユーザを管理するような方法で動作せしめる。このような簡潔さは、強力なユーザーインタフェース動作によって変更されたデータを送信し、逆処理を通じて複数の参加者たちのハンドヘルド上で同様のインタプリタを行い、したがって、プログラムがユーザが入ったデータ上またはユーザインタフェースの入力上で既に動作しているのと同様のあるいは同じ方法で、変更されたデータ上でのみ動作することによってもたらされる。どのデータを入力し、どのインタフェースイベントを送信し、そして応答すべきかは、発明の構成、技術の先導及びほとんどこれらプログラムが既に処理していたのと同じ動作とのみ関係するＣＣＰＡＰＩ１７０の実行により簡潔化される。
【００３６】
ＣＣＰシステムライブラリ１６０は、ＣＣＰ１７０を実行する他のＰＤＡ１００上で走る遠隔のアプリケーションプログラム１１０とコネクトし、そしてアプリケーションプログラム１１０からコネクションを受け取ることができるように会議システムメッセージ１６１を処理する。有利なことに、アプリケーションプログラム１１０は、遠隔の装置とＴＣＰ／ＩＰ，ＩＲ、ＢＬＵＥＴＯＯＴＨのコネクションを行う方法を認識する必要はないし、そのようなコネクションを切断する方法についても認識する必要はない、さらに、そのようなプロトコルとの特別な通信ルールの実施についても認識する必要はない。むしろ、アプリケーションプログラム１１０は、アプリケーションプログラム１１０に転送され通常のＣＣＰイベントハンドラ１２１によって処理されるＣＣＰシステムライブラリ１６０からメッセージを受け取る方法を認識していれば足りる。
【００３７】
ＣＣＰシステムライブラリ１６０は、遠隔のアプリケーションプログラム１１０がデータのみを処理すべきか、表示イベントも処理すべきかを決定することを可能にするためディスプレイ更新メッセージ１６３をフィルタリングすることができる。有利なことに、これによって、遠隔のアプリケーションプログラム１１０のユーザが、コラボレーションおよび会議セッション３００に参加しつつ、同時にＰＤＡ１００あるいはデスクトップコンピュータ２１０上のデータに入りそして変更することを可能にする。
【００３８】
各々のデスクトップコンピュータ２１０は、上記のＰＤＡ１００と同じ方法でＣＣＰＡＰＩ１７０を実行することができる。さらに、デスクトップコンピュータ２１０はハートモニター、ＨＶＡＣシステムあるいは製造装置のような固定のデータ生成装置の形をとることができる。この方法によると、これらの装置は、データ編集メッセージ１６１のみを実施し、遠隔監視をし、図３で示されるように前記装置やハードウェアを制御しさえする。
【００３９】
ＣＣＰＡＰＩ１７０にリンクし、実行する現在のアプリケーションは、適当な起動方法を呼び出しＣＣＰシステムライブラリ１６０にコネクトするかコネクション待ち（リスン）するかを伝える。コネクションがされると、アプリケーションプログラム１１０はこれをＣＣＰイベントハンドラ１２０によって処理されるイベントを介して認識する。
【００４０】
ＣＣＰイベントマネジャ１７０は、構造化されたバイト形式でメッセージを受け取る。これらのバイトは、図４で示されるとおり、アプリケーションに一意のメッセージｉｄとペイロードに翻訳される文書化されたプログラム構造の上に重ねられる。ペイロードは、プログラムあるいは特定のデータのメッセージを有する。システムメッセージ１６１は、会議を開催し、閉会し、会議に新しい対象を受け入れ、テキストメッセージを送り、エラーメッセージを送ったり受信したりし、通信ブロックをエンキューしたりデキューしたりし、会議文書や会議及びコラボレーションプロトコルに記述されているような他の様々なプロトコル関連の実施をするために、全体に簡潔に述べられるように双方のＣＣＰシステムライブラリ１６０間に送られる。
【００４１】
ＤＥＭ１６２及びＤＵＭ１６３メッセージのようなアプリケーションの特定イベントは図５に示されているように実際の無線コラボレーションセッションに属するので最も興味深い。各データ編集メッセージ１６２は強力なデータ編集動作に対応するように設計されている。例えば、スプレッドシートコラボレーションの場合、セルの形式が編集されれば、送信元のアプリケーションクライアントは、新しく編集されたセルのための列、コラム、そして形式を持つＤＥＭ１６２を生成し、パッケージする。宛先のクライアントアプリケーションは、このＤＥＭ１６２を受け取り、会議メッセージｉｄとアプリケーションに一意のメッセージｉｄを形式編集のものとマッチングし、ペイロードを解凍し、セル形式編集を取り扱うために適当なアプリケーションレベル機能あるいは、サブルーチンを呼び出す。有利なことに、このことが、クライアントプログラムが、そのデータが局地的に発生したと考えられるようにし、アプリケーションプログラムの再デザインあるいは既に試されたアプリケーションコード上での大きな追加プログラミングを回避する。
【００４２】
ディスプレイ更新メッセージ１６３はユーザインタフェースを管理する。例えばスクローリングである。送信元クライアントアプリケーションがスクロールされたことを会議に知らせる必要がある場合、スクロールイベントをまとめ上げ、ＤＵＭとして送る。受信クライアントから受信したときは、ＤＵＭはメッセージＩＤに対してマッチングされ、次にスクロールイベントが解析される。その後、このスクロールイベントは、そのクライアントアプリケーションが内部で生成するように各受信クライアントにおいて生成され、各受信クライアントプログラムが、イベントが局地的に起動されたと考えるように、適当な機能呼び出しが行われる。有利なことに、このことがクライアントプログラムの大きな再設計を回避し、既に慎重に試験されたコードに触れることを回避する。
【００４３】
ＤＵＭ１６３は、受信クライアントアプリケーションが指示した場合には、ＣＣＰシステムライブラリ１６０がＤＵＭメッセージ１６３を選択的にフィルタリングし得る点で独自性がある。この長所は、受信クライアントアプリケーションを会議におけるデータ参加者とすることを可能にするが、まだ同時的編集の困難性に対処するスクリーンユーザーインタフェースは持たない。会議及びコラボレーションプロトコル１６０及び会議及びコラボレーションＡＰＩ１７０は、どのようにしてＤＵＭイベントを可能あるいは不可能にする適当な機能呼び出しを行うかについてここで詳しく説明する。
【００４４】
コラボレーションプロトコル仕様（ＣＣＰ）
導入
コラボレーションプロトコルは、様々な形式のコンテンツを交換するべく、ピア装置を相互にコネクトすること及びクライアントをサーバにコネクトすることの双方を可能にするためのトランスポート独立のプロトコルである。実際のコンテンツ交換の形式はこの文書の中で記述されているが、プロトコルを用いるアプリケーションの機能として考慮されている。このプロトコルが、トランスポートニュートラル及びコンテンツニュートラルの両方であることは強調する価値がある。プロトコルそのものは、追加のコンテンツフォーマットのために拡張可能である。
【００４５】
この文書の中において、ターム受信装置がタームリレーサーバを用いる場合には常に、クライアントサーバ状態に代替される。
【００４６】
プロトコルの最初のバージョンは２つのトランスポート（ｉｒＤＡ及びＴＣＰ／ＩＰ）に言及するが、他のプロトコルの追加的サポートはこの文書に影響を与えないと仮定する。
【００４７】
プロトコルヘッダ中の全ての１６ビット及び３２ビットのインテジャーは、ピア装置に送られる前に、ネットワークバイト順に変換される。
【００４８】
全ての構造定義、コンスタンツ及び列挙されたタイプについては、Collab.hファイルを参照する。ＡＰＩ定義については、Collaboration_ptcl_spec.docを参照する。
【００４９】
以下は、２つの通信中の装置の枠組みに存在するコラボレーションプロトコルの概観である。
【表１】
2005509960.tif 000003
【００５０】
この文書は、以下のコラボレーションプロトコルＡＰＩ及びトランスポートニュートラルＡＰＩの間のデータを説明する。
【００５１】
メッセージ概観
この部では、コラボレーションプロトコルメッセージの完全な詳細について定義する。
【００５２】
全てのコラボレーションプロトコルメッセージにおいて、始めの１６バイトの領域は同じである。
【表２】
2005509960.tif 000004
・メッセージ中のバイト−ヘッダを含んだコラボレーションプロトコルメッセージ全体のバイト数。受信装置は、アプリケーションに届けられる前に、メッセージ中の全てのバイトを受信するまで、この値を利用してトランスポート上で読み取り続けることでができる。メモ：全ての１６及び３２ビットのインテジャーはネットワークバイト順に送られる。
・メッセージタイプ−メッセージには４つのグループがあり、あるメッセージがどのグループに属するかはビットマスクによって決定される。
・0x------01から0x------FF：システムメッセージ（もしmsg & 0x000000FFなら）
・0x----01--から 0x----FF--：会議メッセージ、典型的には他の全ての会議参加者に中継される。（もしmsg & 0x0000FF00なら）
・0x--01----から 0x--FF----：ユーザ定義メッセージ（もしmsg & 0x00FF0000なら）
・0x01------ から0xFF------：予備
【００５３】
システムメッセージについては以下が定義される。
【表３】
2005509960.tif 000005
会議メッセージについては以下のように定義される。
・プロトコルバージョン−最も重大なバイトは主要なバージョン数を含んでいる。最も重要でないバイトは、副次的なバージョン数を含んでいる。１．０２バージョンでは、この値は0x0102である。
・会議ＩＤ−この値はコラボレーションセッションの開始前にユーザに通信され、クライアント装置上の入力メソッドを介してユーザから入力されていなくてはならない。ピアツーピアの会議ではこの値は0xFFFFでなくてはならない。例外はclbSysConfIDRequest及びclbSysConfIDResponseメッセージで、その値は、0xFFFFでなくてはならない。
・  ユーザＩＤ−この値はコラボレーションセッションの開始前にユーザに通信され、クライアント装置上の入力メソッドを介してユーザから入力されていなくてはならない。ピアーツーピアの会議ではこの値は0xFFFFでなくてはならない。この値は２つの目的で用いられる。
・  このユーザーが特定の会議に属することを確認する。
・  この装置からのメッセージに従ってこのユーザ／装置を確認する。
【００５４】
リレーサーバ（あるいは受信装置）はこの値を確認して蓄積し、特定のクライアントを認識するために用いなくてはならない。これは、ユーザネームに類似している。
【００５５】
システムメッセージ
システムメッセージはクライアントからリレーサーバに、リレーサーバからクライアントへ、あるいはピアーツーピアに送信される。システムメッセージは、自動的には、リレーサーバによって他のクライアント装置に送られない。これらは、特定のクライアントとリレーサーバの間の関係にとってのある特有な相互関係を示すために用いられる。
【００５６】
システムメッセージは、３２ビットメッセージタイプ（ホストバイト順に転換後）のうち上位２４ビットをマスクすることで決定される。
例えば、
【数１】
2005509960.tif 000006
【００５７】
clbSysConnectRequest(0x00000001)
このメッセージはトランスポートコネクションが起動した後、アクティブ装置（トランスポートコネクションを開始するもの）から受信装置に送られる。これが、交換された最初のメッセージであるはずである。
【００５８】
このメッセージのための、メッセージペイロードは以下の通りである。
【表４】
2005509960.tif 000007
・  アプリケーションタイプは、アプリケーションがサポートされない場合または会議に適合しない場合には受信装置がセッションを拒絶するようにConnectRequestメッセージ中にある。以下にアプリケーションタイプが定義される。
・clbAppTypeIM=1
・clbAppTypeQuickWord=2
・clbAppTypeQuickSheet=3
・  パスワードは符号化されずに送られる。
【００５９】
clbSysConnectResponse(0x00000002)
このメッセージは、clbSysConfIDRequestメッセージの受信に応えて、受信（リスニング）装置からアクティブ装置に送られる。受信装置は会議ＩＤ、参加者ＩＤ及びパスワードを認証し、このメッセージを応答として送信する。その目的は、情報が有効であるかどうかを示し、そして、可能であれば、アクティブ装置を別のアドレスにそして／または別のポート番号に切り替えることにある。
【００６０】
このメッセージのためのメッセージペイロードは以下のとおりである。
【表５】
2005509960.tif 000008
応答コードは以下のうちの一つである。
・ETClbResponseAcceptNoRedirect(0x0001)：有効な会議及びユーザＩＤ。この会議はこの装置により開催される。
・ETClbResponseAcceptRedirect(0x0002)：有効な会議及びユーザＩＤ。クライアントは与えられたアドレスからディスコネクトし、再コネクトしなくてはならない。
・ETClbResponseRejectBadConfID(0x0003)：未知の会議
・ETClbResponseRejectBadConfTime(0x0004)：既知だが現在は進行していない会議
・ETClbResponseRejectBadUserID(0x0005)：この会議についてはユーザｉｄが有効でない。
・ETClbResponseRejectBadPassword(0x0006)：ユーザ名は有効だが、パスワードは有効でない。
・ETClbResponseRejectUnsupportedApp(0x0007)：受信装置によってサポートされていない要求されたアプリケーション
・ETClbResponseRejectMaxClients(0x0008)：クライアントの最大数が既にコネクトしている。
・ETClbResponseRejectByUser(0x0009)：ユーザによって拒絶されている。
・ETClbResponseRejectOther(0x000A)：未特定の拒絶
【００６１】
拒絶のいくつかを受信すると、アクティブ側はトランスポートコネクションを閉じなければならない。トランスポートコネクションが閉じられていないイベントでは受信側はコネクションで受信されたどのさらなるメッセージも無視する。
【００６２】
ETClbResponseAcceptRedirectメッセージを受信すると、アクティブ側はコネクションを閉じ、新しいアドレスを解析し、そして新しいトランスポートにコネクトを試みなくてはならない。トランスポートは現在のトランスポートと同じであると仮定される。アドレスは、ＴＣＰ／ＩＰのための以下の構造、すなわち、‘：’という文字に続くＮＵＬＬ値で終了するポート番号を伴うホスト名またはＩＰアドレスオクテットを伴うＡＳＣＩＩフォーマット内に存在する。例えば、“yahoo.com:9800”、あるいは、”192.168.1.3:9778”である。
【００６３】
clbSysConfIDRequest(0x00000003)
このメッセージの目的は、ピアツーピアの会議中の受信装置に、アクティブ側にそのＩＰアドレスを持つことを要求しない方法を提供することにある。代わりに、会議ＩＤが受信装置をアドレス付けするのに用いられる。受信装置は会議ＩＤとＩＰアドレスを結びつける役割を持つサーバにコネクトし、このメッセージを最初メッセージとして送る。サーバは、新しい会議ＩＤを伴うclbSysConfIDResponseメッセージに応答する。サーバは、会議ＩＤ及びＩＰアドレスをログし、アクティブピアが良く知られたサーバに接続しようとしたときには、受信装置に切り替えられる。
【００６４】
メッセージヘッダ中の会議ＩＤは、0xFFFFでなければならない。
このメッセージのメッセージペイロードは以下のとおりである。
【表６】
2005509960.tif 000009
・  ＩＰアドレスはネットワークバイト順に送信される。
・  パスワードは符号化されずに送信され、ＮＵＬＬ値で終了する。
【００６５】
clbSysConfIDResponse(0x00000004)
このメッセージは、ClbSysConfIDRequestを受信した際に会議ＩＤサーバからクライアントに送信される。
メッセージヘッダ中の会議ＩＤは0xFFFFである。
このメッセージに対するメッセージペイロードは以下のとおりである。 
【表７】
2005509960.tif 000010
・  ペイロード内の会議ＩＤはネットワークバイト順でなければならない。
【００６６】
clbSysJoinConference(0x00000005)
このメッセージは、コラボレーションセッションが確立された後直ちに、アクティブ装置（トランスポートコネクションを開始するもの）から受信装置に送られる。受信ピア装置は、メッセージを無視することができる。リレーサーバは、以下のことをしなければならない。
・  もし、これがこの会議の最初のユーザである場合には、会議が開始される。
・  もし、これがこの会議の最初のユーザではなく、この会議が「公の」会議として設定されていなければ、リレーサーバは、このユーザが会議に参加することを知らせるために、clbSysUserStatusメッセージを生成し、全ての既存の会議参加者に送信する。
【００６７】
このメッセージのメッセージペイロードは以下のとおりである。
【表８】
2005509960.tif 000011
・  装置のタイプは以下のうちの一つである。
・0x0001:PalmOS PDA
・0x0002:PocketPC PDA
・0x0003:J2ME ディスプレイ装置
・(必要に応じて追加)
・  自ら与えた記述名は、ユーザが会議に参加したり離脱した時に、他の会議参加者に送られる。これは、ＮＵＬＬ値で終了しなければならない。リレーサーバは、この内部構造の中で、この領域をこのユーザに結びつける。
【００６８】
clbSysLeaveConference(0x00000006)
このメッセージは、会議を離れるときにクライアントからリレーサーバに送られる。通常は、直ちに、クライアント装置によるトランスポートコネクションの閉鎖に進む。受信ピア装置はメッセージを無視することができる。リレーサーバは、以下のことをしなくてはならない。
・  もし、これが、この会議の最後のユーザであれば、この会議は閉鎖される。
・  もし、これがこの会議の最後のユーザではなく、この会議が「公の」会議として設定されていなければ、リレーサーバは、このユーザが会議を離脱することを知らせるために、clbSysUserStatusメッセージを生成し、全ての既存の会議参加者に送る。
このメッセージのためのメッセージペイロードはない。
【００６９】
clbSysUserStatus(0x00000007)
このメッセージは、ユーザが会議に参加したり離脱したときにクライアント装置からリレーサーバに送られる。
このメッセージのメッセージペイロードは以下のとおりである。
【表９】
2005509960.tif 000012
・  状態は、以下のいずれかである。
・  0x0001:ユーザが会議に参加した。
・  0x0002:ユーザが会議を離れた。
・  記述名は、clbSysJoinConferenceメッセージ内で、このクライアントによって与えられたものと同じである。
【００７０】
clbSysNewDocument(0x00000008)
このメッセージは、クライアントの一つからclbSyssSetDocumentメッセージを受信すると、リレーサーバからクライアント装置に送られる。この目的は、残りのクライアントに会議文書が検索可能であることを知らせることにある。普通は、クライアント装置は文書を得るために、clbSysGetDocumentメッセージをリレーサーバに送る。
【００７１】
このメッセージはピアツーピアのコラボレーションセッションでは有効でなく、この状況では、受信装置によって無視される。
このメッセージのペイロードは以下を含む。
【表１０】
2005509960.tif 000013
【００７２】
clbSysGetDocument(0x00000009)
このメッセージは、クライアントから、リレーサーバに、またはピアツーピアに送られる。目的は、会議文書を得ることである。
【００７３】
このメッセージを受け取ると、リレーサーバあるいは受信ピア装置がclbSysSetDocumentメッセージにおいて、クライアントに文書を送らなくてはならない。
このメッセージのペイロードは、以下を含む。
【表１１】
2005509960.tif 000014
【００７４】
もし、メッセージ中に、何の文書名もない場合（ペイロードにバイトが全くないあるいは、単に０バイト（エンプティストリング）であると示される）には、受信装置は、どの文書が会議文書であるか知っていると推定され、clbSysSetDocumentメッセージ内でこれに応答する。
【００７５】
clbSysSetDocument(0x0000000A)
このメッセージが送られる状況は、３つある。
・  ピア装置が、他のクライアントにこれを届けるために、会議文書をリレーサーバに送りたいとき。
・  リレーサーバが、会議文書をクライアントに送りたいとき。
・  ２つのピア装置が会議をしていて、一方が他方に会議文書を送りたいとき。
【００７６】
このメッセージを受信すると、受信クライアントは、メッセージ全体を読んで、文書本体を取得し、その文書を“ディスク”に保存する。
【００７７】
リレーサーバがこのメッセージを受信すると、他のすべてのクライアントに、新しい会議文書がclbSysNewDocumentメッセージを介して入手可能であることを知らせる。クライアントは、clbSysGetDocumentメッセージによって、新しい文書を入手する選択をすることが可能である。
このメッセージのペイロードは、以下を含む。
【表１２】
2005509960.tif 000015
・  その文書を受信した装置は、メッセージヘッダのトータルバイトフィールドを用いて、いつ文書全体が受信されたかを決定する。一旦文書全体が受信され、蓄積されると、そのアプリケーションはその文書上で（それをロードすることによって）動作する。
【００７８】
clbSysSetDocumentResponse(0x0000000B)
このメッセージはクライアントからリレーサーバまたはピアツーピアに送信される。その目的は他の側にclbSysSetDocumentメッセージ中において送信された会議文書を受信したことを知らせることである。
このメッセージのペイロードは以下を含む。
【表１３】
2005509960.tif 000016
その状態は、以下のいずれかである。
・  CLB_SETDOCRESPONSE_OK(1):エラーなし
・  CLB_SETDOCRESPONSE_ERR(2):文書は受信されていないままである
【００７９】
clbMsgSetDisplayUpdateState(0x0000000C)
このメッセージはそれを送信した装置がディスプレイ更新メッセージ（ＤＵＭｓ）の受信を必要とするか必要としないかを特定するために使用される。
２バイトのペイロードが含まれる。
【表１４】
2005509960.tif 000017
この状態は、以下のいずれかである。
・  CLB_DISPLAYUPDATE_ENABLE(1)-はい、ＤＵＭｓを送信してください。
・  CLB_DISPLAYUPDATE_DISABLE(2)-いいえ、ＤＵＭｓを送信しないでください。
【００８０】
clbMsgBaton(0x0000000D)
このメッセージはバトンを要求するためにリクエストと応答を通信するために用いられる。会議が“プロジェクター”モードであるときは、１つの装置のみがディスプレイ更新メッセ−ジ（ＤＵＭｓ）とデータ編集メッセージ（ＤＥＭｓ）を送信することができる。それは、これらのメッセージを送信するためのバトンを所有する。
このメッセージのペイロードは以下を含む。
【表１５】
2005509960.tif 000018
そのバトンアクションは以下のうちの一つである。
・  CLB_BATON_REQUEST(1)-送信者はバトンを要求している。
・  CLB_BATON_GRANTED(2)-送信者はバトンの所有を許可している。
・  CLB_BATON_GRANTED_DUE_TO_TIMEOUT(3)-バトンを所有する装置はそのバトンリクエストへ応答せず、そのためバトンの所有を断念する。
・  CLB_BATON_DENIED(4)-送信者はバトンを断念するリクエストを拒否する。
・  CLB_PROJECTOR_MODE_CANCELLED(5)-会議はプロジェクターモードを離れている。
【００８１】
会議メッセージ
会議メッセージはクライアントからリレーサーバ、リレーサーバからクライアントまたはピアツーピアに送信される。会議メッセージはリレーサーバによって他のクライアント装置に向けて自動的に送信される（しかし元の装置に戻ることはない）。
【００８２】
ある会議メッセージは３２ビットメッセージタイプの上位１６ビットそして下位８ビットをマスクすることによって決定される。例えば、
【数２】
2005509960.tif 000019
【００８３】
（リレーサーバによってクライアントに中継されたものでなく）クライアントから発した会議メッセージにとって、ヘッダ中のユーザＩＤは固有のユーザＩＤである。リレーサーバによってクライアントに中継された会議メッセージにとって、ヘッダ中のユーザＩＤは起点のユーザＩＤである。
【００８４】
clbConfDataUpdate  
このメッセージは会議文書中のいくつかのタイプの変更を示している。それはクライアントからリレーサーバ、リレーサーバからクライアントあるいはピアツーピアに送信される。このメッセージを受信すると、リレーサーバはその変更されていないメッセージを別のクライアントへ送信する。リレーサーバはまた、マスタ文書を更新する[最初のバージョンにおいてではない]。
【００８５】
このメッセージのペイロードは会議中のアプリケーションに依存する。このメッセージのためにデータをフォーマットすることは、そのアプリケーションの責任である。そのプロトコルはメッセージヘッダ中のメッセージタイプをclbConfDataUpdateに設定し、そのデータを受信者に配信する。
【００８６】
そのアプリケーションがそのデータを解釈、処理し得るかを決定するため、そのプロトコルはそのメッセージの最初の２バイトがそのメッセージに含まれるデータのバージョン情報領域を含むように明記する。
【表１６】
2005509960.tif 000020
【００８７】
clbConfDisplayUpdate
このメッセージは会議文書のディスプレイ中におけるいくつかのタイプの変更を示す。それはクライアントからリレーサーバ、リレーサーバからクライアント、ピアツーピアに送信される。このメッセージを受信すると、そのリレーサーバは、その変更されないメッセージを別のクライアントに送信する。
【００８８】
このメッセージのペイロードは会議中のアプリケーションに依存する。このメッセージのためにデータをフォーマットすることは、そのアプリケーションの責任である。そのプロトコルはメッセージヘッダ中のメッセージタイプをclbConfDisplayUpdateに設定し、そのデータを受信者に配信する。
【００８９】
そのアプリケーションがそのデータを解釈、処理し得るかを決定するため、そのプロトコルはそのメッセージの最初の４バイトがそのメッセージに含まれるデータのアプリケーションタイプ情報領域とバージョン情報領域を含むように明記する。
【表１７】
2005509960.tif 000021
【００９０】
clbConfText
このメッセージは、会議セッションがオープンされた後にいつでも、クライアント装置からリレーサーバ、リレーサーバからクライアント装置、またはピアツーピアセッションにあるいずれかのピアから送信される。  
【００９１】
前に記述したメッセージヘッダに加えて、clbConfTextMsgはメッセージのためのＮＵＬＬ値で終了する以下のヘッダに続くＡＳＣＩＩテキストを含む。
【表１８】
2005509960.tif 000022
・  そのテキストが１人のユーザに配信されるなら、ユーザＩＤは最初の２バイト中に設置される。そのメッセージが全てのユーザに配信されるなら、またはピアツーピアの会議なら、0xFFFF値は最初の２バイトに存在する。
【００９２】
セッション閉鎖
受信装置またはアクティブ装置のいずれかは単にトランスポートコネクションを閉じることによっていつでも会議セッションを閉じることができる。
【００９３】
会議及びコラボレーションプロトコルＡＰＩ（ＣＣＰ  ＡＰＩ）
コントロールブロック
コントロールブロックと呼ばれる構造は、コラボレーションレイヤーの全ての機能に入力され、そのコラボレーションレイヤーによって、トランスポートモジュールに入力される。それは、プロトコルスタック全体のマスタ構造と思われる。それは、状態、アドレス、コネクションタイプ、現在の入力メッセージについての受信したバイト数、その他を追跡する。この構造は、メインモジュールにおいては、コラボレーションレイヤーとのインタフェースとなり、メインアプリケーションイベントループを含むモジュールにおいては、エキスターンとして活用できる。
【００９４】
アプリケーションが、コントロールブロック構造における変数を読み込むか変更しなければならない理由は少ない。これらのインスタンスは、この文書において示される。
【数３】
2005509960.tif 000023
【００９５】
説明：コラボレーションライブラリのバージョン情報を取得する。これは、コラボレーションプロトコルのバージョンと独立しているものとする。
例：
【数４】
2005509960.tif 000024
【００９６】
説明：保留中イベントをチェックする。任意の保留中出力メッセージを記述し、そして、ＳＲ（トランスポート）レイヤーにＣＰＵ時間を与える。この機能は、アプリケーションのメインイベントループ中のループから呼び出される。
例：
【数５】
2005509960.tif 000025
【００９７】
説明：コラボレーションセッションを確立するプロセスを開始する。アプリケーションはこのルーチンの呼び出しを行う前に望まれるコネクションの型を設定する。それは、ＴＣＰ／ＩＰコネクションを確立する際に、呼び出しの前にctlBlock内でＩＰアドレスとポートを設定する。呼び出し元は、イベントキュー上のCLB_CONNECTION_UPイベントを介してコネクションを通知される。
パラメータ：
ctlBlock    マスタコントロールブロックへのポインタ
xPort      トランスポートタイプ（ＩＲまたはＴＣＰ／ＩＰ、ｓｒ．ｈ参照）  
confID     会議ｉｄ。ＵＩを介してユーザにより入力
userID     ユーザｉｄ。ＵＩを介してユーザにより入力
appType    アプリケーション。アプリケーションにより知られる。例えばＱｕｉｃｋＷｏｒｄ  
passＷord   このユーザのパスワード。Ｎｕｌｌ値で終了。  
例：
【数６】
2005509960.tif 000026
【００９８】
説明:
特定のコネクションタイプ上で“リスニング”を開始する。コネクションタイプはctlBlock.connType領域において特定される。この呼び出しを行う前にそれを希望するトランスポートに設定する。これは非同期呼び出しである。１個のコネクションが確立したら、呼び出し元はイベントキュー上のCLB_CONNECTION_UPイベントを介して通知される。
パラメータ：ctlBlock        コネクションコントロールブロックへのポインタ
acceptSessCB    セッション承認のためのコールバック機能へのポインタ
例：
【数７】
2005509960.tif 000027
【００９９】
説明：新たな会議のための会議ＩＤを取得する処理を開始する。ピアツーピアの会議では、受信装置はそのＩＰアドレスを良く知られたサーバに登録するためにこの機能を呼び出す。アクティブクライアントは、その良く知られたサーバにコネクトし、宛名が書き換えられることによって、受信装置に返された会議ＩＤを用いて受信装置にコネクトすることができる。
この呼び出しの結果は、evtData３２が新たな会議ＩＤを有するCLB_CONFIDを介してそのアプリケーションに渡される。そのアプリケーションはclbListenを呼び出してリスンモードに入る。
パラメータ：
cltBlock      マスタコントロールブロックへのポインタ
xPort         トランスポートタイプ（ＩＲまたはＴＣＰ／ＩＰ。ｓｒ．ｈ参照）  
userID       ＵＩを介してユーザにより入力されたユーザｉｄ
passWord     このユーザに対するパスワード。Ｎｕｌｌ値で終了。
例：
【数８】
2005509960.tif 000028
【０１００】
説明：現在のコネクションに対するコラボレーションメッセージ中にデータを書き込む。呼び出し元はclbCreate呼び出しを用いてそのメッセージを生成し、バッファ中にデータをコピーし、この機能を呼び出してその書き込みを行う。これは非同期呼び出しである。呼び出し元はイベントキュー上のイベントを介して書き込みがうまくなされたことを通知される。
パラメータ：
ctlBlock      コネクションコントロールブロックへのポインタ
outBuf       書き込まれるバッファへのポインタ
返却：
【表１９】
2005509960.tif 000029
例：
【数９】
2005509960.tif 000030
【０１０１】
説明：オープンコネクションをディスコネクトする。これは非同期呼び出しである。呼び出し元はイベントキュー上のイベントを介してそのコネクションが閉じられたことを通知される。１つのclbMsgLeaveConference メッセージが、そのコネクションを閉じる前に出力される。
パラメータ：
ctlBlock      マスタコントロ−ルブロックへのポインタ
【数１０】
2005509960.tif 000031
【０１０２】
説明：満たされたヘッダと、満たされる用意がなされたペイロードを有するコラボレーションメッセージを生成する。バイト数は、ペイロードのみに必要とされる数である。この機能はヘッダ領域のために自動的に計算される。それは、そのメッセージヘッダ（そしてそのメッセージそのもの）へのポインタを返す。その“ペイロード”アドレスにアクセスするためにCLB_BUF_ADDRマクロを使用する。
パラメータ：
Message type    例：clbMsgConfText,clbMsgConfDataUpdate  
Conference ID   サーバへ望ましい会議を認識させる一意のＩＤ
User ID         サーバへこのユーザを認識させる一意のＩＤ
Number of bytes  ペイロードのみ。メッセージヘッダを算入しない。
例: (例えば、clbSendMsgのコメント参照)
【数１１】
2005509960.tif 000032
パラメータ:
ctlBlock         コネクションコントロールブロックへのポインタ
docName        送信する文書名（ＮULL値で終了）
conferenceID    現在の会議の会議ＩＤ
userID          ユーザＩＤ
【０１０３】
説明：
正しいヘッダ情報を持つclbSysSetDocumentメッセージを生成し、そのメッセージを送信し、文書データベースを見つけ、それを送信する。
例:
【数１２】
2005509960.tif 000033
注意:これは非同期メッセージであり、受信装置がclbMsgSetDocumentResponseメッセージによって文書の受信を認識した後にそのアプリケーションに送信されるCLB_WRITEDOC_COMPLETEイベントを発生させる。
【数１３】
2005509960.tif 000034
【０１０４】
説明:コントロールブロックの様々な要素の状態を新しい状態に変える。有効な状態はTStatusType typedefによって定義される。
【数１４】
2005509960.tif 000035
そのアプリケーションはETConnStatusDown、ETConnStatusUp、ETConnStatusListenPending、そしてETConnStatusListeningのみを用いる。別の状態は内部においてコラボレーションモジュールに使用される。例えば、
そのアプリケーションは、
・CLB_CONNECTION_UPイベントを受信すると状態をETConnStatusUpに設定する。 
・CLB_CONNECTION_DOWNイベントを受信すると状態をETConnStatusDownに設定する。    
・  新たなコネクションを開始する直前に状態をETConnStatusDownに設定する。
・  clbListenを呼び出す直前に状態をETConnStatusListenPendingに設定する。
・  リスンをキャンセルしたときに状態をETConnStatusDownに設定する。
パラメータ:
ctlBlock     コントロールブロックへのポインタ
new state    有効状態を参照
例：
【数１５】
2005509960.tif 000036
【０１０５】
説明:トランスポート（ＳＲ）層を呼出し、コネクトされた装置のストリングフォーマット中の名称を取得する。peerName中のＮＵＬＬ値で終了するフォームを返す。その名称はそのトランスポートに依存する。例えば、ＴＣＰ／ＩＰについては、それは“192.168.1.1”の形のＩＰアドレスを返す。
パラメータ:
ctlBlock                 コントロールブロックへのポインタ
peerName               結果を設定するバッファ
maxchars of peerName   バッファサイズ
【数１６】
2005509960.tif 000037
【０１０６】
説明：トランスポート（ＳＲ）層を呼び出し、このローカル装置のストリングフォーマット中の名称を取得する。それはlocalAddr中のＮＵＬＬ値で終了するフォームを返す。その名称はそのトランスポートに依存する。例えば、ＴＣＰ／ＩＰについては、それは“192.168.1.1”の形のＩＰアドレスを返す。
パラメータ:
ctlBlock                  コントロールブロックへのポインタ
localAddr                 結果を設定するバッファ
maxchars of localAddr     バッファサイズ
【数１７】
2005509960.tif 000038
【０１０７】
説明：アプリケーションはアプリケーションが始まったセッションを受け入れたいかを証するための機能をコールバックする。これはパラメータとしてclbListen呼び出しへ入力される。ＮＵＬＬ値の入力は全てのセッションの承認を意味する。開始したセッションが入ってくると、そのライブラリはこの機能を呼び出し、リターンコードによって示される応答に従って反応する。
【数１８】
2005509960.tif 000039
【０１０８】
説明：以下を追跡する内部変数を返す。
・  会議がプロジェクターモード(PROJECTOR_MODE)か否か
・  この装置がバトンを持つ(HAVE_BATON)か否か
パラメータ:
ctlBlock       コネクションコントロールブロックへのポインタ
例：
【数１９】
2005509960.tif 000040
【０１０９】
説明:メッセージペイロード中のCLB_BATON_REQUESTを持つclbMsgBatonメッセージを生成し、送信する。他の側がBATON_REQUEST_TIMEOUT時間内に反応しない場合に、スタックがGRANTED状態のCLB_BATON_STATUSイベントを送信するようにタイマを開始させる。
パラメータ:
ctlBlock         コネクションコントロールブロックへのポインタ
返却：
【表２０】
2005509960.tif 000041
例：
【数２０】
2005509960.tif 000042
【０１１０】
説明：そのスタックがアプリケーションに送信するためのイベントを持っているときに呼び出されるコールバック機能を登録する。その送信されるイベントはEventsセクション中に列挙される。
パラメータ:
callbackFuncPtr      そのイベントを処理するコールバック機能へのポインタ。この機能は以下のプロトタイプを有する。
【数２１】
2005509960.tif 000043
そのコールバック機能は、そのイベントを処理したら真を返し、そうでなければ偽を返す。
例：
【数２２】
2005509960.tif 000044
【０１１１】
コンスタンツ
このセクションは会議プロトコル中で用いられるコンスタンツ（＃defines）そしてタイプ(typedefs) を列挙する。
【０１１２】
CLB_VERSION
単一のバージョン値。２バイト。最も重要なバイトは主要バージョンである。最も重要でないバイトは副次的バージョンである。この値はコラボレーション層によって全ての会議メッセージヘッダに設定される。
【数２３】
2005509960.tif 000045
【０１１３】
CLB_LIB_VERSION
ライブラリバージョン数。２バイト。最も重要なバイトは主要バージョンである。最も重要でないバイトは副次的バージョンである。このライブラリバージョンはプロトコルバージョンと独立である。
【数２４】
2005509960.tif 000046
【０１１４】
エラーコード  
これらはＡＰＩ呼び出しからの返却値として用いられ、イベントを介してアプリケーションに送信される。
【数２５】
2005509960.tif 000047
【０１１５】
メッセージタイプ
アプリケーションは、clbMsgConnectRequest、clbMsgJoinConference、clbMsgLeaveConference、clbMsgUserStatus、またはclbMsgConnectResponseメッセージを送信も受信もしない。それらはコラボレーション層によって送信され処理される。アプリケーションは別の有効なタイプの１つをclbCreate呼び出し中に入力する。
【数２６】
2005509960.tif 000048
【０１１６】
COLLABORATION_PORT
コラボレーションプロトコルに対するＴＣＰポート。受信装置はこのポート上でリスンを行う。アクティブ装置はこのポートに対してコネクトする。このプロトコルがプロダクトの一部となると、１つのポートがＬＡＮＡ（インターネット認証番号機関）に登録される。
【数２７】
2005509960.tif 000049
【０１１７】
CLB_HEADER_BYTES
コラボレーションメッセージヘッダ中のバイト数
【数２８】
2005509960.tif 000050
【０１１８】
CLB_BUF_ADDR
コラボレーションメッセージ中の“ペイロード”へのポインタに速くそして簡単にアクセスするためのマクロ
【数２９】
2005509960.tif 000051
【０１１９】
CLB_EVT_XXX_BASE
この値はユニークなイベント番号を取得するためにある値が付加される基礎値である。
【数３０】
2005509960.tif 000052
【０１２０】
CLB_Message Constants
これらの値は有線上で送信されるメッセージに関する。それらが関連するそのメッセージはコンスタンツ名から確かめられる。
【数３１】
2005509960.tif 000053
【０１２１】
登録名
このセクションはコラボレーションプロトコルに対する登録タイプを列挙する。
【０１２２】
コネクト要求に対する応答
これらの値はclbConnectResponseメッセージ中において、受信側によってアクティブ側に戻される。
【数３２】
2005509960.tif 000054
【０１２３】
アプリケーションタイプ
そのスペックは“アプリケーションタイプ”を含むようにコネクション要求を呼び出す。
【数３３】
2005509960.tif 000055
【０１２４】
タイプ
このセクションはコラボレーションプロトコルによって用いられるタイプを記述する。実際のメッセージの構造はここに列挙される。アプリケーションはめったにこれらの構造を扱わない。そのほとんどはコラボレーション層によって取り扱われる。
アプリケーションレベルでは、１６ビットと３２ビットのインテジャーはホストバイト順である。
【０１２５】
コラボレーションメッセージヘッダ
このデータは全てのコラボレーションメッセージの開始点にある。これらの値はclbCreate呼び出しの中にコラボレーション層によって設定される。アプリケーションはこれらの値を設定しない。
【数３４】
2005509960.tif 000056
【０１２６】
コラボレーションコネクト要求メッセージ
このメッセージは一旦トランスポートコネクションが完了したらアクティブ装置によって送信される。それはヘッダとパスワードを含む。パスワードはＮＵＬＬ値で終了するＡＳＣＩＩストリングである。
【数３５】
2005509960.tif 000057
【０１２７】
コラボレーションコネクト応答メッセージ
このメッセージはConnectRequestメッセージを受信した後に受信装置によって送信される。それはパスワードを認証し、応答コードと、コネクトするアクティブ側の新たなアドレスとポートを送信する。
【数３６】
2005509960.tif 000058
【０１２８】
コラボレーション会議ＩＤ要求メッセージ
このメッセージは会議ＩＤを取得するために良く知られたサーバに対して近々受信装置になる装置によって送信される。ヘッダ中の会議ＩＤの値は0xFFFFに設定される。ＩＰアドレスはネットワークバイト順である。パスワードはＮＵＬＬ値で終了するＡＳＣＩＩストリングである。
【数３７】
2005509960.tif 000059
【０１２９】
コラボレーション会議ＩＤ応答メッセージ
このメッセージはよく知られたサーバによって近々受信装置になる装置に対してそれに新たな会議ＩＤを与えるために送信される。ヘッダ中の会議ＩＤの値は0xFFFFに設定される。ペイロード中の会議ＩＤ領域はネットワークバイト順である。
【数３８】
2005509960.tif 000060
【０１３０】
コラボレーション設定文書メッセージ
このメッセージの目的は、会議文書が送られたことを示すことにある。典型的には、新バージョンの会議文書が利用可能になると、リレーサーバはclbMsgNewDocumentメッセージを全てのクライアントに送る。それから、クライアントはclbMsgGetDocumentメッセージをサーバに送り、サーバは、文書を伴ったclbMsgSetDocumentメッセージに対し応答する。
【数３９】
2005509960.tif 000061
【０１３１】
コラボレーション新文書メッセージ
このメッセージの目的は、新バージョンの会議文書が存在することを示すことにある。典型的には、新バージョンの会議文書が利用可能になると、リレーサーバはclbMsgNewDocumentメッセージを全てのクライアントに送る。それから、クライアントはclbMsgGetDocumentメッセージをサーバに送り、サーバは、文書を伴ったclbMsgSetDocumentメッセージに対し応答する。
【数４０】
2005509960.tif 000062
【０１３２】
コラボレーション取得文書メッセージ
このメッセージの目的は、送信者が新バージョンの会議文書が送付されることを希望することを示すことにある。典型的には、新バージョンの会議文書が利用可能になると、リレーサーバがclbMsgNewDocumentメッセージを全てのクライアントに送る。それから、クライアントはclbMsgGetDocumentメッセージをサーバに送り、サーバは、文書を伴ったclbMsgSetDocumentメッセージに対し応答する。もし、メッセージの送信者が文書名を知らない場合は、文書名は省略する、あるいはエンプティストリング（“”）とすることが可能で、デフォルトの会議文書が送り返される。
【数４１】
2005509960.tif 000063
【０１３３】
コラボレーション設定文書準備メッセージ
このメッセージの目的は、他のピアまたはリレーサーバに対し会議文書がオープンされたことを知らせることにある。このようにして、文書が受信されてからオープンされるまでどれくらい時間がかかったかが明らかになる。リレーサーバは、メッセージをバッファリングしてクライアントが準備状態になるまでどれくらいの時間がかかるかを知ることができる。
クライアントは、clbSetDocumentReadyメッセージを送り、ピアあるいはリレーがそれを取り扱う。メッセージは文書名を要求する。
【数４２】
2005509960.tif 000064
【０１３４】
コラボレーションテキストメッセージ
これは、単純なテキストメッセージで、コラボレーションヘッダ、ユーザＩＤそしてＮＵＬＬ値で終了するテキストである。仮にテキストが全ての接続ユーザにブロードキャストされるのであれば、ユーザＩＤを0xFFFFに設定する。そうでない場合は、メッセージは指定された特定のユーザにのみ送られる。この領域は、ピア会議については無視される。
【数４３】
2005509960.tif 000065
【０１３５】
コラボレーションユーザーメッセージ
全てのユーザーメッセージ（メッセージタイプセクション参照）は、自由形式である。アプリケーションは、メッセージを作成するためにclbCreateを呼び出し、ペイロードを書き込み、メッセージを送るためにclbSendを呼び出す。ライブラリは、これらのメッセージの内容を無視し、単純にそれらを送り出し、あるいは、受信したそれらをアプリケーションに転送する。
【０１３６】
イベント
これらのコンスタンツは、コラボレーションプロトコルがアプリケーションに送り返すことのできるイベントを定義する。アプリケーションは、これらのイベントのためにイベントハンドラを持つ。
イベントに関連したデータは、送られてきたイベントの“一般的な”部分に含まれる。イベントの“一般的な”部分はＩｎｔ１６の配列である。いくつかのイベントについては、これらは、アドレスを含むためオーバーロードになる。各メッセージについて、メッセージとともに送られた関連データはコメントの中で与えられる。
【０１３７】
CLB_EVT_XXX_BASE
これらの値は、独自のイベント識別子の同一性を判断するために値が追加される基礎値にすぎない。システムイベントは、０から９９９、会議イベントは１０００から１９９９であり、ユーザイベントは２０００から２９９９である。
【数４４】
2005509960.tif 000066
【０１３８】
CLB_CONNECTION_UP
このイベントは、clbConnectあるいはclbListen呼び出しの結果として、アプリケーションに送られる。
関連データ：
event.evtData16     エラーコード
【数４５】
2005509960.tif 000067
【０１３９】
CLB_CONNECTION_DOWN
このイベントは、clbDiscount呼び出しの結果として、あるいは、他の側がトランスポートコネクションを終了したらアプリケーションに送られる。
関連データ：
event.evtData16     エラーコード
【数４６】
2005509960.tif 000068
【０１４０】
CLB_WRITEMSG_COMPLETE
このイベントは、clbWrite呼び出しの結果としてアプリケーションに送られる。それは、全てのデータがトランスポートに書き込まれたことを示す。
関連データ：
event.evtData16     エラーコード
このライブラリは、出て行くメッセージによって使われたメモリを開放する。
【数４７】
2005509960.tif 000069
【０１４１】
CLB_WRITEDOC_COMPLETE
ClbSendDocument呼び出しの結果アプリケーションに送られる。全ての文書が送られたことを示す。
関連データ：
event.evtData16     エラーコード
【数４８】
2005509960.tif 000070
【０１４２】
CLB_DATA_RCVD
このイベントは、全てのコラボレーションメッセージが受信された時、アプリケーションに送られる。コラボレーション層は、トランスポート層から来るメッセージフラグメント群を取り扱う。
関連データ：
event.evtData16    エラーコード
event.evtData32    TClbMsgへのポインタ。そのヘッダから全てが決定される。  
注：evtData32によって指定されたメモリを解放するのはアプリケーションの責任である。         
【数４９】
2005509960.tif 000071
メモリにアクセスするためにポインタ表示はこのようなことをする。
【数５０】
2005509960.tif 000072
注：この例は、コラボレーションテキストメッセージのデータにどのようにアクセスするかを示す。
【０１４３】
CLB_NEWDOC_ARRIVED
新しい会議文書が到着すると、アプリケーションに送られる。コラボレーション層はストレージヒープへの文書の書き込み処理を行う。アプリケーションはこのメッセージから文書名を入手し、それを読み込む。
関連データ：
event.evtData16    エラーコード
event.evtData32    文書名へのポインタ
【数５１】
2005509960.tif 000073
注：evtData32においてポインタを開放しない。これは、ctlBlock構造の固定要素である。
【０１４４】
CLB_NEWDOC_EXISTS
入手準備ができた新バージョンの会議文書があることを誰かが公表すると、アプリケーションに送られる。アプリケーションは、clbGetDocumentメッセージを送り出すことで応答する。このメッセージには添付文書はない。それは、全ての参加者に、文書を入手すべきだということを知らせる一つの方法である。
アプリケーションは、evtData32によって指定されるメモリを解放する。
関連データ：
event.evtData16    エラーコード
event.evtData32    文書名へのポインタ
【数５２】
2005509960.tif 000074
【０１４５】
CLB_REQUEST_NETDOC
誰かが、最新バージョンの会議文書を要求した時に、おそらく、clbMsgNewDocumentメッセージが送り出された結果として、アプリケーションに送られる。
スタックは、clbSysGetDocumentメッセージが到着したとき、このメッセージをアプリケーションまで送る。このメッセージには、添付文書はない。
アプリケーションは、evtData32によって指定されるメモリを解放する。
関連データ：
event.evtData16    エラーコード
event.evtData32    文書名へのポインタ
【数５３】
2005509960.tif 000075
【０１４６】
CLB_BATON_STATUS
以下の場合に、バトンを要求するアプリケーションに応答して、アプリケーションに送られる。
・  clbMsgBatonメッセージに対して他の装置がバトンを許容する又は否定するかを応答した。
・  タイムアウトが終了した。
・  バトンが放棄された。
関連データ：
event.evtData16   バトン状態。CLB_BATON_GRANTED、CLB_BATON_GRANTED_DUE_TO_TIMEOUT、CLB_BATON_DENIEDあるいはCLB_BATON_LOSTのいずれか。
【数５４】
2005509960.tif 000076
【０１４７】
CLB_NEWDOC_READY
文書がオープンされた時、アプリケーションに送られる。ピアあるいはリレーからのclbSetDocumentReadyMsgの結果である。
アプリケーションは、evtData32によって指定されるメモリを解放する。
関連データ：
event.evtData16    エラーコード
event.evtData32    文書名へのポインタ
【数５５】
2005509960.tif 000077
【０１４８】
CLB_CONFID
（clbGetConfID呼び出しに応答して）clbSysConfIDResponseメッセージが受信されると、新しい会議ＩＤとともに、アプリケーションに送られる。
関連データ：
event.evtData16    エラーコード
event.evtData32    新しい会議ＩＤ。これは３２ビット変数中の１６ビットの値となる。
【数５６】
2005509960.tif 000078
【０１４９】
アプリケーションのメインイベントループ
EvtGetEventが呼び出され処理される、アプリケーションのメインイベントループにおいて、３つの変更がなされなくてはならない。サンプルイベントループはこのセクションの最後にある。
【０１５０】
clbRun
この機能は、３つの役割を果たす。
・  送信待ちの出て行くメッセージがあるかどうかを調査し、もしあれば、送信する。
・  コラボレーション層あるいはアプリケーションのいずれかによって処理されるユーザイベントを調査する。もし、キューのなかにイベントがあれば、最初の一つを取得し、処理できるかを調べるために、clbHandleEventを呼び出す。もし処理できなければ、アプリケーションが処理できるかを調べるために、clbRegisterEventCB呼び出しに登録された呼び出し機能を呼び出す。この２つの機能のうちのどちらか一つは、ユーザイベントキューから抽出されたどのようなイベントも認識し、処理することができなくてはならない。
・  トランスポート層にＣＰＵ時間を与えるためにsrRunを呼び出す。ユーザ入力に対して責任を果たすために、トランスポート機能への呼び出しがノンブロッキングモードでなされる。これは、ある機能が呼び出されたことを意味し、もし、何もすることがなければ、単に返却される。例えば、ＴＣＰポート上でのリスニングは通常ブロッキング呼び出しである。ソケットの「受容」呼び出しをおこなうNetLibの実施は、タイムアウトをパラメタとして行われ、そして、ポーリング形式で行われる。したがって、ループ中にこの機能が呼び出される方法がなくてはならない。srRun機能は、この機能を果たす。clbRunは、アプリケーションのメインイベントループの中で呼び出されなければならない。
【０１５１】
EvtGetEvent（）へのタイムアウト
アプリケーション層及び通信層の双方において、望ましい責任を果たすためには、アプリケーションのメインイベントループの中で、EvtGetEventに小さいタイムアウトを入れるべきである。以下の例を参照せよ。
【０１５２】
メインイベントループの例
【数５７】
2005509960.tif 000079
【０１５３】
どの機能がイベントを処理するかをスタックへ通知する。
スタックからイベントを取り出すために、アプリケーションは、スタックとともに、コールバック機能を登録しなくてはならない。典型的なコールバック機能は以下である。
【数５８】
2005509960.tif 000080
コールバック機能を登録するために、clbRegisterEventCB API呼び出しを用いる。これを行うのに最適な場所はアクティブフォームのための初期化機能中にある。
【０１５４】
エラーアラートリソース
コラボレーション層及び通信層は双方とも、ＩＤ１０００を持ったアラートリソースを利用する。このリソースは、Alert.h.に設定されている。１つのパラメータ(“＾”)を採るアラートリソースに対する値を変更する。
【０１５５】
ログファイルのクローズ
LOGLOSEへの呼び出しが、ログファイルをクローズするためにアプリケーションのAppStop()機能の最後になされる。ロギングが可能でない場合はLOGLOSEマクロは何も決意しない。ロギングが可能な場合はLOGLOSEはLogClose()を決意し、従って挿入語は必要としない。そのログをオープンする必要はない。それはロギング呼び出しがなされたときに最初にオープンされる。
【０１５６】
アプリケーションに対するコラボレーションメッセージのハンドリング
コラボレーション層は以下のイベントをアプリケーションに送信する。
・  CLB_CONNECTION_UP
・  CLB_CONNECTION_DOWN
・  CLB_WRITEMSG_COMPLETE
・  CLB_WRITEDOC_COMPLETE
・  CLB_DATA_RCVD
・  CLB_NEWDOC_ARRIVED
・  CLB_NEWDOC_EXISTS
・  CLB_REQUEST_NEWDOC
・  CLB_BATON_STATUS
・  CLB_CONFID
アプリケーションは、clbRegisterEventCBのＡＰＩの呼び出しを介して入力された機能中のこれらのイベントを処理する。ここにサンプル機能を示す（注意：これはイベントを処理する実際のコードを持つものではなく、単にその構造を示すに過ぎない)。
【数５９】
2005509960.tif 000081
【０１５７】
本発明は好適な実施の形態に関して説明されてきたが、本発明のアプリケーションを読めば、多くの変形や修正がこの技術分野の当業者にとって理解できる。従って、先行技術の観点からできるだけ広く解釈される、添付されたクレームは、そのような変形や修正の全てを含むことを意図している。
【図面の簡単な説明】
【０１５８】
【図１】本発明のソフトウェアによって実現されるＰＤＡと物理的に離れた通信装置によりほとんどリアルタイムに実現され得る様々な無線コラボレーション会議のブロック図である。
【図２】あるＰＤＡが、システムメッセージ、データ編集メッセージ、ディスプレイ更新メッセージを、デスクトップコンピュータのような物理的に離れた通信装置と交換する無線コラボレーション会議プロトコルセッションのブロック図である。
【図３】別の装置とコネクションを確立しているか、そのようなコネクションを待っている状態であるＰＤＡのブロック図である。
【図４】構造化されたビットセットの形でメッセージを受信するＣＣＰイベントマネジャのブロック図である。
【図５】無線コラボレーションセッションにおいて交換されるＤＥＭおよびＤＵＭメッセージのブロック図である。
【図１】
2005509960.tif 000082
【図２】
2005509960.tif 000083
【図３】
2005509960.tif 000084
【図４】
2005509960.tif 000085
【図５】
2005509960.tif 000086
【国際調査報告】
2005509960.tif 000087
2005509960.tif 000088
2005509960.tif 000089