JP3943636B2 - コンピュータ制御型ディスプレイシステム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、セッションのマルチメディアキャプチャ、再生、及び、編集の分野に関する。
【０００２】
【従来の技術】
グループの大部分の仕事は、構造化されたミーティングような整理されたセッティングが行われている場合でさえ、会話による言葉のやりとりのようなカジュアルな相互作用の形態を採っており、これにより、グループは、彼らの仕事の技術、プロセス、関係がある様相を共通に理解することができる。このカジュアルな活動は、そのような活動の結果に焦点が合っており、グループがどのようにそれらの結果に達したかということについては殆ど無視するコンピュータ使用のツールによっては十分にはサポートされてはいない。更に、そのような情報を収集する試みは、かれらの自然な仕事の慣例をサポートするより、むしろ、活動を公式なものとして、参加者を情報収集ツールに都合が良い方法に従わせる結果となっている。
【０００３】
ミーティングのオーディオ、ビデオ、及び、コンピュータ記録を収集することは、グループプロセスの十分な検討可能な記録を提供する。残念ながら、そのような記録の利点は、しばしば必要とされたシーケンシャルなアクセスのために扱い難い傾向があった。そのような情報のデジタル記録の出現で、そのような情報に即時にアクセスすることが可能である。しかしながら、即時アクセスは、行くべき場所が判っているときのみ有用である。従って、意味を持つ要素かイベントに基づいて、そのような記録にインデックスを付けることは、必要であり望ましいことである。
【０００４】
インデックスを付けることへの一つのアプローチは、リアルタイムノートテーキング（Ｒｅａｌ−Ｔｉｍｅ ｎｏｔｅｔａｋｉｎｇ）と称される。そして、そこで、人は，ノートの種々の個々の要素にタイムスタンプするシステムを使用して、ミーティングの間にノートを取る。これは、ミーティングの記録への理解可能なインデックスを提供する。ノートの任意の要素を単に選択することによって、システムはノート要素のタイムスタンプに対応するＡＶ記録の部分を、検索して再生することができる。
【０００５】
最も簡単な例は、文の書写システムであり、そこでは、ユーザは、ミーティングが進むに従ってテキストを単にタイプするだけである（テキストは、発言されたことの文字通りの書写或いはミーティングに関する任意のノートとすることができる）。ノートは、テキストのストリングから成り、タイムスタンプされたノート要素は、テキストの個々の文字である。ノートテーキングが完成した後に、ユーザは、文字を選択することができ、ミーティング記録の対応する部分が検索されて再生されることになる。
【０００６】
ノートテーキングシステムは、ユーザが視覚的な表現（すなわちノート）を構成するのを可能にする。そして、その可視の要素はミーティング記録へのインデックスとして機能を果たす。各々のインデックス要素は、それと関連づけられた時間を有する。この時間は、ユーザがそれを生成した時間である。各々のインデックス要素が可視なので、ユーザは、単に指示によってそれにそれを選択することができ、また、それは関連づけられた時間を有するので、ミーティング記録へアドレスを得ることができる。
【０００７】
ノートテーキングシステムは、視覚的な表現の構造が、イベントを生成する要素のシーケンスのみから成っている限りは良好に動作する。表現がミーティングのコースの間に編集されるのを許されると、すなわち、要素変更及び要素−削除イベントも同様に存在すると、問題が起こる。問題の原因は、インデックスが可視の要素であって、イベントではないことである。
【０００８】
【発明が解決しようとする課題】
ノートテーキングによるアプローチの不利な点は、人がノートテーキングの仕事に専念しなければならないことである。従って、人を、自然なミーティング活動それ自身の副作用であるノートテーキングの仕事に専念させないで、ミーティング記録中へインデックスを生成することは望ましい。
【０００９】
【課題を解決するための手段】
本発明は、ミーティングのような共同作業を表現する時間的データの再生を制御するためのユーザーインターフェースを目指すものである。そのような時間的データは、一つ或いはそれ以上のキャプチャ装置（例えばオーディオ記録か電子ホワイトボード）によって獲得される。時間的データは、タイムストリームとイベントから成る。タイムストリームは、ミーティングの或る記録可能な局面を表現するタイムスタンプされたデータのセットである。オーディオ及びビデオの記録、或いは、電子ホワイトボードの上の行動の蓄積された履歴は、タイムストリームの例である。イベントは、タイムストリームの中の出来事である。イベントは、共同作業の間の時間の点またはスパンへの直接的なアクセス提供するインデックスを生成するために使われる。タイムストリームは、イベントを固有に定義するかもしれない。または、イベントを識別するために、分析される場合がある。イベント情報は、タイムスタンプ、イベント型、及び、イベントのインスタンスの様々な特性のリストから成る。
【００１０】
セッションの再生は、セッションアクセス装置の制御の下で行なわれる。
セッションアクセス装置に連結されるのは、タイムストリームを再生するための複数のプレーヤである。セッションアクセス装置は、セッション再生を制御するためのユーザーインターフェースを生成するためにイベント情報を利用する。ユーザーインターフェースは、複数のウィンドウから成る。各々のウィンドウは、プレーヤ、再生制御装置、または、ユーザーが追加のタイムストリーム情報を生成することを許すエディターを表現することができる。本発明においては、共有表現メディア（例えば電子ホワイトボード）のためにタイムストリームを再生するためのプレーヤとして振舞うウィンドウは、同じくセッションの再生を制御するために使われる。ウィンドウで表示された各々のグラフィックオブジェクトは、一つ或いはそれ以上のイベント（例えば削除個所イベント）と関連づけられる。グラフィックオブジェクトの選択は、再生時間を関連づけられたイベントの一つの時間へ移動することを可能にする。選択は、ウィンドウのエリアの上で行われる場合もある。これは、ユーザーが、選択されたエリアで行われたマーキングと関連している全てのイベントを見ることを可能にする（幾つかのマーキングは、消したり移動されたりするので）。
【００１１】
【発明の実施の形態】
図１は、本発明の現時点での好適な実施態様における時間的データの獲得及び再生のためのシステムのブロック図である。図２は、本発明の現時点での好適な実施態様において利用することができるセッションアクセスワークステーションのブロック図である。図３は、本発明の現時点での好適な実施態様のセッションアクセスワークステーションの動作の単純化された疑似状態である。図４は、本発明の現時点での好適な実施態様のセッションアクセスワークステーションに連結されるディスプレイのビジュアルユーザインターフェースの図である。図５は、本発明の現時点での好適な実施態様のセッションのためのタイムラインユーザインターフェースディスプレイの図である。図６は、概観時間トラックディスプレイエリアと焦点時間トラックディスプレイエリアの関係をハイライトするタイムラインインターフェースの単純化された図である。図７は、図６の焦点バーが引き伸ばされこれに従って焦点時間トラックディスプレイエリアの寸法が変えられている動作の結果を示す図である。図８は、二つのセッションの再生を制御するためのタイムラインユーザインターフェースディスプレイシステムの図である。図９は、二つの不連続な焦点セグメントが概観時間トラックエリアに表示され、焦点時間トラックエリアが各々の焦点セグメントの詳細を含むタイムラインインターフェースの図である。図１０は、図９の焦点時間トラックエリアのサイズ修正の結果を示すタイムラインインターフェースの図である。図１１は、ＬｉｖｅＢｏａｒｄウィンドウの選択動作の結果として生じたトラックセクションを含む複数のキャプチャ装置で記録したセッションの再生のためのタイムラインインターフェースの例である。図１２は、一つのトラックの上で図１１のオーディオのトラックを併合した結果を示すタイムラインユーザインターフェースディスプレイの更なる図である。図１３は、ノートトラックの上にノートを開けた結果を示す図１１のタイムラインユーザインターフェースディスプレイの更なる図である。図１４は、図１１のタイムラインユーザインターフェースを生成するのに使用した同じセッションについてのミーティングプレーヤの図である。図１５は、本発明の現時点での好適な実施態様におけるＬｉｖｅＢｏａｒｄウィンドウの図である。図１６は、ＬｉｖｅＢｏａｒｄウィンドウとタイムラインインターフェースの間の相関性の図である。すなわち、グラフィックオブジェクトからタイムラインへのインデックス付けである。図１７は、Ｌｉｖｅｂｏａｒｄウィンドウとタイムラインインターフェースの間の相関性の図である。すなわち、ＬｉｖｅＢｏａｒｄウィンドウとタイムラインインターフェースの両方が同時に同じものを反映する同期化されたディスプレイ状態である。図１８は、Ｌｉｖｅｂｏａｒｄウィンドウとタイムラインインターフェースの間の相関性の図である。すなわち、時間的なものから空間のへのインデックス付けである。図１９は、ＬｉｖｅＢｏａｒｄウィンドウとタイムラインインターフェースの間の相関性の図である。すなわち、グラフィックオブジェクトにつき多数のイベントである。図２０は、ＬｉｖｅＢｏａｒｄウィンドウとタイムラインインターフェースの間の相関性の図表である。すなわち、オブジェクトエリアの位置選定によってインデックスを付ける。図２１及び図２２は、ＬｉｖｅＢｏａｒｄウィンドウが編集された前後の“バウンシング−ボール”再生モードにおけるＬｉｖｅＢｏａｒｄウィンドウの例を提供する。
【００１２】
本発明は、ミーティングのような共同作業、及び、他の非共同作業の記録の再生の提供する。
【００１３】
本発明の目的は、作業そのものの自然な副産物である共同作業のミーティング記録へインデックスを生成することである。これは、人々が記録されたセッションの一部への直接アクセスを得る直観的な方法を提供する。話者の変更、ホワイトボードへの書き込み及びマーキング操作、ノートを取ることのようなイベントは、有益なインデックスポイントを提供するミーティングの自然の副産物の例である。
【００１４】
本発明のシステムは、ソフトウェアに基づいたタイムストリームアーキテクチャ及びシステムアーキテクチャを参照して述べられる。タイムストリームアーキテクチャは、現時点での好適な実施態様が実行されるソフトウェアフレームワークを述べる。システムアーキテクチャは、本発明の機能の構成要素を述べる。
【００１５】
タイムストリーム及びシステムアーキテクチャの記述で使われる用語は、ここで定義される。
【００１６】
タイムストリーム（Ｔｉｍｅｓｔｒｅａｍ）は、キャプチャ装置で獲得されたタイムスタンプされたメディアデータを意味し、プレーヤーで再生することができる。
【００１７】
イベント（Ｅｖｅｎｔｓ）は、獲得される活動の間の或る点または間隔で発生する出来事、例えば、話者の交代或いはホワイトボードへの書き込みである。
【００１８】
時間的データ（Ｔｅｍｐｏｒａｌ Ｄａｔａ）は、タイムストリームとイベントの結合を意味する。
【００１９】
セッション（Ｓｅｓｓｉｏｎｓ）は、ミーティングのように密着して獲得された活動を表現する時間的データの収集物に名前が付けられる。
【００２０】
プレーヤ（Ｐｌａｙｅｒｓ）は、その元の形態で、または、タイムストリームのダイナミックスを示す形態で、タイムストリームを再生することができる。
【００２１】
エディタ（Ｅｄｉｔｏｒｓ）は、ビジュアルインジケータを変化させることができる、或いは、イベントとタイムストリームをセッションに付加することができるユーザインターフェースを意味する。
【００２２】
再生制御装置（Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌｌｅｒｓ）は、セッションの再生が制御されるユーザインターフェースを意味する。
【００２３】
キャプチャ装置（Ｃａｐｔｕｒｅ Ｄｅｖｉｃｅｓ）は、時間的データを獲得して蓄積する装置である。異なった型のキャプチャ装置は、セッションの異なったメディア（例えば、オーディオ、ビデオ、ホワイトボード上の書き込み）を獲得する。
【００２４】
タイムストリームアーキテクチャは、調和した記録と再生のための拡張性があるセットのツールの使用をサポートする。これは、特定のマシンの一つのアドレス空間に存在するが、ネットワーク内の同一の或いは他のマシンの同一の或いは異なったアドレス空間に存在する“代理”オブジェクトを有するオブジェクトを、ユーザが容易に構築することを可能にする分散型オブジェクトシステムに基づいている。この分散型オブジェクトシステムは、言語間統一（Ｉｎｔｅｒ−Ｌａｎｇｕａｇｅ Ｕｎｉｆｉｃａｔｉｏｎ）（ＩＬＵ）と称され、Ｊａｎｓｓｅｎによる“ＩＬＵマニュアル”、ゼロックス技術報告書、ＩＳＴＬ−ＣＳＡ−９４−０１−０２、１９９４年１月に述べられている。タイムストリームアーキテクチャの基本的なデータ構成要素は、イベント、タイムストリーム、及び、セッションである。
【００２５】
イベントは、開始時間、期間（’ポイント’イベントについては多分ゼロ）、型、及び、型に依存することがある可能のある特性からなる。（例えば、ＬｉｖｅＢｏａｒｄページイベントは、’ページ数’と’ページ表題’特性を有するかもしれない。）イベントオブジェクトへのインターフェースは、以下のようになる。
ＴＹＰＥ Ｅｖｅｎｔ＝ＣＬＡＳＳ
ＳＵＰＥＲＣＬＡＳＳ ＰｅｒｓｉｓｔｅｎｔＯｂｊｅｃｔ ＥＮＤ
ＭＥＴＨＯＤＳ
ｇｅｔＴｙｐｅ（）：Ｓｔｒｉｎｇ，
ｇｅｔＳｔａｒｔＴｉｍｅ（）：Ｔｉｍｅ，
ｇｅｔＤｕｒａｔｉｏｎ（）：Ｔｉｍｅ
ＥＮＤ
【００２６】
ここで述べられたインターフェース仕様は、上述したＩＬＵシステムの指定言語のスタイルをしているが、文字通りそのままであることを意図するものではなく、オブジェクト指向プログラミングを熟知している者によって、容易に翻訳することができる。データ型ストリングと時間の意味は自明である。付加的に、ＰｅｒｓｉｓｔｅｎｔＯｂｊｅｃｔのサブクラスとして、イベントは以下の方法を受け継ぐ
ｇｅｔＰｒｏｐｅｒｔｙＮａｍｅｓ（）：ＳｔｒｉｎｇＳｅｑｕｅｎｃｅ
ｓｅｔＰｒｏｐｅｒｔｙ（ｎａｍｅ：Ｓｔｒｉｎｇ，ｖａｌｕｅ：Ｓｔｒｉｎｇ）
ｇｅｔＰｒｏｐｅｒｔｙ（ｎａｍｅ：Ｓｔｒｉｎｇ）：Ｓｔｒｉｎｇ
【００２７】
イベントは、以下に述べたように、セッションオブジェクトへのコールによって生成される。
【００２８】
タイムストリームオブジェクトは、所定のメディア型のために蓄積されたデータを参照するために使用される。一般的に言えば、タイムストリームと関連したデータは、記録されたメディアの時間に基づいたアクセスを可能にする。記録されたオーディオのように、多くのデジタルメディアの関しては、これは、イベントと見なすことができたデータ時間サンプルデータから成るけれども、大量で大きくメディア（また、装置にも）に依存するサンプルされたデータの翻訳は、タイムストリームを’不透明’と見ることを一層実際的にする。すなわち、タイムストリームデータは、タイムストリームのメディアとフォーマットと関連している特別なツールによってのみ正常に操作される。特に、データは、レコーダオブジェクトによって生成され、プレーヤオブジェクトによって再生される。同様に、イベントを作り出すために、メディアの特定のツールによって分析することもできる。（例えば話者セグメント、沈黙／中断、場面変化など）タイムストリームオブジェクトを不透明として取り扱うことにより、アーキテクチャがアナログメディアに適応することができることに注意すべきである。（例えば、レコーダとプレーヤは、コンピュータソフトウェアで制御されるビデオテープレコーダかもしれず、タイムストリームは、テープが使われるべきである情報を備えたソフトウェアと、テープの初めと関連付けられるべき絶対時間を提供するかもしれない。）タイムストリームオブジェクトへのインターフェースは、以下の通りである。
ＴＹＰＥ Ｔｉｍｅｓｔｒｅａｍ＝ＣＬＡＳＳ
ＳＵＰＥＲＣＬＡＳＳ ＰｅｒｓｉｓｔｅｎｔＯｂｊｅｃｔ ＥＮＤ
ＭＥＴＨＯＤＳ
ｍｅｄｉａＴｙｐｅ（）：Ｓｔｒｉｎｇ， ｅ．ｇ． ａｕｄｉｏ
ｆｏｒｍａｔ（）：Ｓｔｒｉｎｇ， ｅ．ｇ． ｓｕｎ ａｕ
ｓｔａｒｔＴｉｍｅ（）：Ｔｉｍｅ，
ｄｕｒａｔｉｏｎ（）：Ｔｉｍｅ，
ＥＮＤ
【００２９】
セッションは、イベント、タイムストリーム、及び、他のセッションを含むかもしれない階層構造の収集物である。用語’セッション’のこの使用は、時々遭遇するものよりも広義であり、例えば、所定のミーティング或いは討論と関連するデータの狭い意味の’セッション’は特別な場合であることに注意すべきである。セッションは、本質的にタイムストリームデータを組織するための汎用の簿記機構である。セッションオブジェクトへのインターフェースは、以下のようなものである。
ＴＹＰＥ Ｓｅｓｓｉｏｎ ＝ ＣＬＡＳＳ
ＳＵＰＥＲＣＬＡＳＳ ＰｅｒｓｉｓｔｅｎｔＯｂｊｅｃｔ ＥＮＤ
ＭＥＴＨＯＤＳ
ｇｅｔＴｉｍｅｓｔｒｅａｍＢｙＮａｍｅ（ｎａｍｅ：Ｓｔｒｉｎｇ）：Ｔｉｍｅｓｔｒｅａｍ，
ｇｅｔＡｌｌＴｉｍｅｓｔｒｅａｍｓ（）：Ｔｉｍｅｓｔｒｅａｍ Ｓｅｑｕｅｎｃｅ，
ｇｅｔＳｅｓｓｉｏｎＢｙＮａｍｅ（ｎａｍｅ：Ｓｅｓｓｉｏｎ）：Ｓｅｓｓｉｏｎ，
ｇｅｔＡｌｌＳｅｓｓｉｏｎｓ（）：Ｓｅｓｓｉｏｎ Ｓｅｑｕｅｎｃｅ，
ｃｒｅａｔｅＥｖｅｎｔ（ｓｔａｒｔ：Ｔｉｍｅ，ｄｕｒ：Ｔｉｍｅ，ｔｙｐｅ：Ｓｔｒｉｎｇ，ｐｒｏｐｓ：
ＰｒｏｐｅｒｔｙＬｉｓｔ）：Ｅｖｅｎｔ
ＥＮＤ
【００３０】
タイムストリームアーキテクチャは、プレーヤとレコーダオブジェクトがメディア型から独立している共通のインターフェースを共有しており、また、サポートされたメディアの型のセットが固定されていないという意味で拡張性がある。プレーヤとレコーダオブジェクトへの単純化されたインターフェースは、以下の通りである。
ＴＹＰＥ Ｐｌａｙｅｒ＝ＣＬＡＳＳ
ＭＥＴＨＯＤＳ
ｓｅｅｋ（ｔ：Ｔｉｍｅ）， 再生時間をｔに変更する
ｌｏｃａｔｉｏｎ（）：Ｔｉｍｅ， 最新の再生時間に戻る
ｐｌａｙ（ｓ：Ｓｐｅｅｄ）， 速度係数ｓで再生する（１＝通常）
ｓｔｏｐ（）， 再生を停止する
．．．
ａｔｔａｃｈ（ｔｉｍｅｓｔｒｅａｍ：Ｔｉｍｅｓｔｒｅａｍ） 所定のタイムストリームを再生するためにプレーヤをセットする
ＥＮＤ；
ＴＹＰＥ Ｒｅｃｏｒｄｅｒ＝ＣＬＡＳＳ
ＭＥＴＨＯＤＳ
ｒｅｃｏｒｄ（），
ｐａｕｓｅ（），
ｃｒｅａｔｅＲｅｃｏｒｄｉｎｇ（ｓｅｓｓｉｏｎ：Ｓｅｓｓｉｏｎ，ｎａｍｅ：Ｎａｍｅ）：Ｔｉｍｅｓｔｒｅａｍ，
ｆｉｎｉｓｈＲｅｃｏｒｄｉｎｇ（），
ＥＮＤ；
【００３１】
所定のメディア型についてのプレーヤとレコーダオブジェクトは、そのメディア型と関連した’ＭｅｄｉａＳｅｒｖｅｒ’によって実施される。当然、新しいメディア型をサポートすることは、新しいＭｅｄｉａＳｅｒｖｅｒの実施を必要とするが、アーキテクチャへ（すなわち、レコーダとプレーヤを作り出すか制御するために必要なインターフェースへ）の変化は必要とされない。これは、汎用のアプリケーション（例えば、記録制御プログラム、或いは、アクセス及び再生制御プログラム）を書き込むことができ、新しいメディア型、或いは、存在するメディア型についての新しいサービスの実施を自動的にサポートすることになることを意味する。ＭｅｄｉａＳｅｒｖｅｒオブジェクトへのインターフェースの単純化された記述は、下式により与えられる。
ＴＹＰＥ ＭｅｄｉａＳｅｒｖｅｒ＝ ＣＬＡＳＳ
ＭＥＴＨＯＤＳ
ｇｅｔＲｅｃｏｒｄｅｒ（ｆｏｒｍａｔ：Ｓｔｒｉｎｇ，ｃｏｎｔｅｘｔ：Ｓｔｒｉｎｇ）：Ｒｅｃｏｒｄｅｒ，
ｇｅｔＰｌａｙｅｒ（ｆｏｒｍａｔ：Ｓｔｒｉｎｇ，ｃｏｎｔｅｘｔ：Ｓｔｒｉｎｇ）：Ｐｌａｙｅｒ
ＥＮＤ
【００３２】
文脈の引数は、プレーヤ或いはレコーダに関する情報を指定する。例えば、オーディオ入力／出力のために使われたホスト及び装置名を指定することができる。
【００３３】
アナライザは、一つ或いはそれ以上のタイムストリームと関連したデータを処理して、イベントを作り出すために使うことができる。
現時点での好適な実施態様で使われた二つのそのようなアナライザが、以下に述べられる。
アナライザへのインターフェースの単純化された記述は、下式で与えられる。
ＴＹＰＥ Ａｎａｌｙｚｅｒ＝ＣＬＡＳＳ
ＭＥＴＨＯＤＳ
ｐｒｏｄｕｃｅＥｖｅｎｔｓ（ｓｅｓｓｉｏｎ：Ｓｅｓｓｉｏｎ，ｓｐｅｃｓ：Ｓｔｒｉｎｇ）
ＥＮＤ
【００３４】
アナライザは、所定のセッションのタイムストリームのデータにアクセスし、セッションと関連したイベントを生成する。どの型のタイムストリーム（例えば、オーディオ、ビデオなど）が、アナライザの型に依存してアナライザによりアクセスされる。’ｓｐｅｃｓ’の議論は、分析が行なわれる方法についてのあらゆる必要な情報を提供する。例えば、アナライザは、所定のワード（ｓｐｅｃｓストリングの一部である）が話される度にイベントを生成するオーディオのワード監視器とすることができる。アナライザは、セッションが記録された後に、或いは、記録プロセスの間にリアルタイムで動作させることができることに注意すべきである。リアルタイムの場合には、アナライザによって作り出されたイベントは、ユーザインターフェースを実施するプロセスのような他のプロセス（以下に述べるイベント通知を参照のこと）により’観察’することができる。
【００３５】
この拡張性を更に促進するために、アーキテクチャは、指定された型のメディアをサポートするための適切なＭｅｄｉａＳｅｒｖｅｒｓを配置するブローカオブジェクトを提供する。ブローカは、同様にアナライザのような他の種類のオブジェクトを配置するのを補助することができる。ブローカは、共有されたネットワークファイルに蓄積される情報を使って、実行プロセスが所定のオブジェクト型（例えばオーディオのＭｅｄｉａＳｅｒｖｅｒ）を実施し、及び／又は、これらのプロセスを生成するために実行しなければならないトラックを維持することができる。他のネットワークベースのネームサービスも同様に使うことができた。ブローカへのインターフェースの単純化された記述は、下式で与えられる
Ｔｙｐｅ Ｂｒｏｋｅｒ＝ＣＬＡＳＳ
ＭＥＴＨＯＤＳ
ｇｅｔＭｅｄｉａＳｅｒｖｅｒ（ｍｅｄｉａ：Ｓｔｒｉｎｇ）：ＭｅｄｉａＳｅｒｖｅｒ
ｇｅｔＡｎａｌｙｚｅｒ（ｔｙｐｅ：Ｓｔｒｉｎｇ）：Ａｎａｌｙｚｅｒ
ＥＮＤ
【００３６】
イベント、タイムストリーム、及び、セッションデータは、タイムストリームデータベースに蓄積される。タイムストリームデータベースを使うアプリケーションプログラムは、他のオブジェクトを作り出すか配置する方法を有するタイムストリームマスターオブジェクトを最初に得る。マスターオブジェクトは、上述したブローカによって使われたものと同じ機構を使用する（多分別のホストの上の）別のプロセスで実行されるタイムストリームサーバから得ることができる。または、タイムストリームサーバ（及び、マスターオブジェクト）を実施するプログラムコードは、アプリケーションプロセスに直接に含ませることができる。
【００３７】
疑似コードによる簡単な記録アプリケーションのために必要な基本的なステップは、以下の通りである。
．．．’マスター’ と呼ばれるトップレベルタイムストリームオブジェクトを得る．．．
ｓｅｓｓｉｏｎ＝ｍａｓｔｅｒ．ｇｅｔＳｅｓｓｉｏｎＢｙＮａｍｅ（’Ｒｅｃｏｒｄｉｎｇｓ’ ）
ｂｒｏｋｅｒ＝ｍａｓｔｅｒ．ｇｅｔＢｒｏｋｅｒ（）
ｍｓｅｒｖｅｒ＝ｂｒｏｋｅｒ．ｇｅｔＭｅｄｉａＳｅｒｖｅｒ（’ａｕｄｉｏ’）
ｒｅｃｏｒｄｅｒ＝ｍｓｅｒｖｅｒ．ｇｅｔＲｅｃｏｒｄｅｒ（’ｍｕ ｌａｗ’， ’ｄｅｆａｕｌｔ ａｕｄｉｏ ｄｅｖｉｃｅ’）
ｒｅｃｏｒｄｅｒ．ｃｒｅａｔｅＲｅｃｏｒｄｉｎｇ（ｓｅｓｓｉｏｎ， ’ｒｅｃｏｒｄｉｎｇ１’）
ｒｅｃｏｒｄｅｒ．ｒｅｃｏｒｄ（）
．．． あるコードは、記録がポーズ、レジューム、或いは、完了であるべきことを示すユーザインターフェースイベントを探す。
．．． 記録を閉じるためのルーチンをコールする。
ｒｅｃｏｒｄｉｎｇ．ｆｉｎｉｓｈＲｅｃｏｒｄｉｎｇ（）
ｅｘｉｔ
【００３８】
前述の疑似コードフラグメントは、記録と呼ばれる現存するセッションの’ｒｅｃｏｒｄｉｎｇ１’と名付けられたオーディオ記録を生成するために必要とされるステップを述べる。
【００３９】
記録を再生するために必要な疑似コードは、以下の通りである。
．．． マスターと呼ばれるトップレベルタイムストリームオブジェクトを得る。
ｓｅｓｓｉｏｎ＝ｍａｓｔｅｒ．ｇｅｔＳｅｓｓｉｏｎＢｙＮａｍｅ（’Ｒｅｃｏｒｄｉｎｇｓ’）
ｔｉｍｅｓｔｒｅａｍ＝ｓｅｓｓｉｏｎ．ｇｅｔＴｉｍｅｓｔｒｅａｍＢｙＮａｍｅ（’ｒｅｃｏｒｄｉｎｇ１’）
ｂｒｏｋｅｒ＝ｍａｓｔｅｒ．ｇｅｔＢｒｏｋｅｒ（）
ｍｓｅｒｖｅｒ＝ｂｒｏｋｅｒ．ｇｅｔＭｅｄｉａＳｅｒｖｅｒ（’ａｕｄｉｏ’）
ｐｌａｙｅｒ＝ｍｓｅｒｖｅｒ．ｇｅｔＰｌａｙｅｒ（’ｍｕ ｌａｗ’，’ｄｅｆａｕｌｔ ａｕｄｉｏ ｄｅｖｉｃｅ’） ｐｌａｙｅｒ．ｐｌａｙ（１）
再生が停止されるべきこと、或いは、異なった時間の探索がコールされるべきことを示すユーザインタフェースイベントを待つ。
【００４０】
タイムストリームアーキテクチャは、一般に互いに協調するアプリケーションを補助し、特に、多数のプレーヤとレコーダに対する協調制御を補助するいくつかの機構を提供する。１つの機構は、単一のプレーヤ及び／又はレコーダとして動作するプレーヤ及び／又はレコーダの収集体である連合（Ｃｏｎｆｅｄｅｒａｔｉｏｎ）オブジェクトである。プレーヤ或いはレコーダは、動的に連合に付加され、或いは、連合から削除することができる。連合へのインターフェースの単純化された記述は、下式により与えられる。
ＴＹＰＥ Ｃｏｎｆｅｄｅｒａｔｉｏｎ＝ＣＬＡＳＳ
ＳＵＰＥＲＣＬＡＳＳＥＳ Ｐｌａｙｅｒ， Ｒｅｃｏｒｄｅｒ ＥＮＤ
ＭＥＴＨＯＤＳ
ｒｅｇｉｓｔｅｒＰｌａｙｅｒ（ｐｌａｙｅｒ：Ｐｌａｙｅｒ），
ｕｎｒｅｇｉｓｔｅｒＰｌａｙｅｒ（ｐｌａｙｅｒ：Ｐｌａｙｅｒ），
ｒｅｇｉｓｔｅｒＲｅｃｏｒｄｅｒ（ｒｅｃｏｒｄｅｒ：Ｒｅｃｏｒｄｅｒ），
ｕｎｒｅｇｉｓｔｅｒＲｅｃｏｒｄｅｒ（ｒｅｃｏｒｄｅｒ：Ｒｅｃｏｒｄｅｒ），
．．．
ＥＮＤ
【００４１】
プレーヤとレコーダのサブクラスとして、連合は、再生と記録のようなそれらのクラスの方法をサポートすることが暗示される。また連合は、時間範囲のシーケンスの再生として振る舞い（ｂｅｈａｖｉｏｒｓ）を実施する付加的な方法もサポートする。
【００４２】
連合を使って、’ＰｒｏｊｅｃｔＭｅｅｔｉｎｇ＃３’と呼ばれるセッションについて、記録された全ての媒体の再生をセットして制御するための単純化されたコードは、以下のようになる。
マスターと呼ばれるトップレベルタイムストリームオブジェクト
．．．ｓｅｓｓｉｏｎ＝ｍａｓｔｅｒ．ｇｅｔＳｅｓｓｉｏｎＢｙＮａｍｅ（’ＰｒｏｊｅｃｔＭｅｅｔｉｎｇ＃３ ’）
．．．ｂｒｏｋｅｒ＝ｍａｓｔｅｒ．ｇｅｔＢｒｏｋｅｒ（）
．．．ｃｏｎｆ＝ｍａｓｔｅｒ．ｇｅｔＣｏｎｆｅｄｅｒａｔｉｏｎ（’ｘｙｚ’）
．．ｔｉｍｅｓｔｒｅａｍｓ＝ｓｅｓｓｉｏｎ．ｇｅｔＡｌｌＳｔｒｅａｍｓ（） ｆｏｒ ｅａｃｈ ｔｉｍｅｓｔｒｅａｍ ｉｎ ｔｉｍｅｓｔｒｅａｍｓ ｄｏ
ｂｅｇｉｎ
．．．ｍｓｅｒｖｅｒ＝ｂｒｏｋｅｒ．ｇｅｔＭｅｄｉａＳｅｒｖｅｒ（ｔｉｍｅｓｔｒｅａｍ．ｍｅｄｉａＴｙｐｅ（））
．．．ｐｌａｙｅｒ＝ｍｓｅｒｖｅｒ．ｇｅｔＰｌａｙｅｒ（ｔｉｍｅｓｔｒｅａｍ．ｆｏｒｍａｔ（），’ｈｏｓｔ１’）
．．．ｃｏｎｆ．ｒｅｇｉｓｔｅｒＰｌａｙｅｒ（ｐｌａｙｅｒ）
ｅｎｄ
ｃｏｎｆ．ｐｌａｙ（）．．．
．．．
どのように再生が制御されるかを示すユーザインターフェースイベントを待つ。
【００４３】
連合には’ｘｙｚ’という名前が与えられることに注意すべきである。他のプログラムは、マスターオブジェクトからこの連合を得、これを使用して再生を制御するができる。これは、同じホストの上でいくつかのプログラムを実行することを可能とするが、しかし再生を共同して制御するために、多分、非常に異なったインターフェースを必要とする。なお、上述したのと同じであるが、異なったホストの上で実行されるプログラムは、そのホストと関連してプレーヤを生成することができ、それらを’ｘｙｚ’構成と共に登録することができる。結果は、実施するための追加のプログラミング負担を本質的に必要としない共有分散型の再生ツールとなる。
【００４４】
別の整合機構は、イベント通知である。プログラムは、’ｎｏｔｉｃｅＥｖｅｎｔ’に呼ばれる方法を有するオブジェクトであるＥｖｅｎｔＮｏｔｉｆｉｅｒを実施することができる。ノティファイアは、セッションオブジェクトと共に登録することができ、ついで、イベントがそのセッションに付け加えられる度に、その時イベントで引数としてイベントと共にコールされる。例えば、ＬｉｖｅＢｏａｒｄウィンドウにおいて、いくつかのオブジェクトが選択されるときに、選択されたオブジェクトに関連した時間を示すイベントを生成することができ、登録されたＥｖｅｎｔｎｏｔｉｆｉｅｒを備えたタイムラインインターフェースに接触することができ（すなわち、コールされたｎｏｔｉｃｅＥｖｅｎｔ方法）、これらの時間をグラフィック的に示すことができる。この例が、以下に詳細に述べられる。
【００４５】
同期の問題は、種々の接合点で、また、種々の形態で発生する。最初に、キャプチャの間、エラーが再生の間知覚的に苛立たせていないように、タイムストリームを十分に整列した状態にしておくという必要性がある。オーディオとビデオの場合には、これは、ビデオと音が約１／３０秒で（例えば、苛立たしい唇同期の問題が発生する前に）整列させ続けなければならないことを意味する。二つのタイムストリームは、異なったマシン上で独立して獲得される場合があるので、各種のソースの間で或る共通のクロックを使う（または再建する）ことが必要である。現時点での好適な実施態様においては、完全に接続されて実行しているときには、ＲＦＣ−１７６９で述べられたネットワーク時間プロトコール（ＮＴＰ）が、クロックをミリ秒以内に精密に維持するために分散型マシンの間で使用される（これは適応型のプロトコールであり、単に共通の標準に再同期させることによってではなく、マシンのドリフトにどの様に適合するかを学習することによって、通常より良い結果が得られる。好適には、タイムストリームのデータの各々の量はタイムスタンプされるが（ビデオではリアルタイムプロトコールパケットを使ったので）、データが正確なクロックレートでサンプルされるというシステムの確実性も同様に十分である。
【００４６】
他の場合には、例えば、他のメディアタイムストリームにインデックスを付ける文の注釈の場合には、そのような厳密な同期のための要求を緩和することができる。再び、どのようなエラーも再生の間に苛立たせなることがない十分な正確さを必要とした測定基準が適用される。文のノートについては、これは、マークが記録された材料へ機能的なポインタであるように、ノートは、ユーザが意図したものに十分に近い位置で、タイムストリームにインデックスを付けなければならないことを意味する。或る状況の下では、何秒かのこぼれは許容可能であるが、他の場合には１秒の端数でも許容できない場合がある。もしユーザが注釈ソフトウェアを走らせているハードウェアの上に、ＮＴＰを走らせていれば、その測定は、一般に十分な正確さを提供するだろう。他のオプションは、注釈がされる度に、ＮＴＰ装備マシンから現在の時間を得るために、時間サーバをコールするか、または、注釈マシンとＮＴＰ時間のと間のオフセットを計算するために、ミーティングの開始にクロックを同期させることを含む。この最後の形態の訂正は、特別な“同期イベント”の形態を使用するかもしれない。これは、分散型の資源の二つ或いはそれ以上のデータ内に注記されている、或いは、それから分析することができる。
【００４７】
要求される同期の正確さの程度に殆ど無関係に、種々のキャプチャ装置を完全に切り離した状態で動作させる準備ができる。これは、接続（コンピュータ、オーディオ、ビデオ等）が望ましくないか不可能なセッティングにおいて記録が行われる場合には望ましいことである。装置の異種のクロックを最終的に整列させるための手段が提供されるとすれば、ハンドヘルドコンピュータ或いは商用のカムコーダは、受け入れることができるキャプチャ装置である。切り離されたラップトップをオーディオの記録と一列に整列する技術の例は、騒々しくラップトップキーを打つことであり、有効な同期イベントである。キーストロークは、ラップトップによってピックアップされ、そのクロックによってタイムスタンプされ、オーディオは、キーヒットを表現するオーディオイベントを見つけ出すために分析され、このイベントは、オーディオレコーダのクロックによりタイムスタンプされる。これから、二つのクロックの間のオフセットを計算することができる。そして、タイムスタンプのセットの一方が他方に合わせられる。
【００４８】
ドリフト（非常に低い周波数エラー）は、記録するセッションの間、同様に問題である。独立したクロックが採用されたセッションにおいて必要とされる正確さの程度に依存して、システム的な利得或いは損失を補正するために、或いは、オフセット補正のためにクロックを繰り返しチェックするために、セッションの開始と終了を読み取ることが必要かもしれない。もし調整的な動作（例えば、通常速度再生が所望のときは、８０５７／８０００で再生））を提案するためにデータを収集することができれば、それら自身がクロック動作するシステム（例えば、８０５７サンプル／秒となるべきであるが８０００サンプル／秒で動作しているとされたオーディオ装置）のこれらの要素におけるドリフトは、再生の間に付加的な微調整を必要とするかもしれない。
【００４９】
ジッター（一層高い周波数エラー）は、一般にシステムの適切な場所でバッファすることによって処理される。
【００５０】
タイムストリーム再生セッション（キャプチャセッションとしばしば同時に発生したり、または、キャプチャのセッティングにおいてある種の“入れ子状態”となるかもしれない）における同期の問題は、マルチメディアシステムにおいて典型的に取り扱われるものに一層接近している。
【００５１】
文脈をセットするために、各種のメディアタイムストリーム（オーディオ、ビデオ、計算ログ）が獲得され、獲得された活動が再体験できるように、密接に同期してこれらのタイムストリームの全部或いは所望のサブセットを再生しながら蓄積されると仮定する。更に、全て記録が完全なデータを備えており、補正すべきドリフト、ジッター、または、オフセットがない状態で獲得されたと仮定する。
【００５２】
現時点での好適な実施態様においては、種々のタイムストリームプレーヤは、適度に接近して同期させるために、十分に同期した無ドリフトシステムクロックを使用して、フリーホイールモードで動作する。これは、各々のプレーヤが、システム時間の経過に合う方法で、そのタイムストリームを再生する責任があることを意味する。普通の再生スピードにおいては、これは再生（及び、システム時間経過）の１秒が、オリジナルディスク記録の各々の秒毎に正確に発生すべきであることを意味し、一層速い及び一層遅い再生レートは、再生される記録が一層多いか一層少ないことを単に表す。これらの高い及び低いスピード再生の最も良い表現は、ユーザの必要に応じてカスタマイズすることができることに注意すべきであり、高速のピッチ保存スピーチは、ミーティングをざっと知るために望まれる場合があり、或いは、適切な間隔から連鎖する４分の１秒のビデオクリップは、非常に高速のビデオ再生を最もよく伝えるかもしれない。
【００５３】
フリーホイール同期を使うことの二つの局面は、記するに値するものあり、それは良好な開始と休止の機会である。第１のものは、伝送時間、バッファリング等に無関係に、そのようなアプローチの訂正動作は、全てが同時に開始するプレーヤに単に依存することである。これは、プレーヤが予定された開始についての依頼を受け取るべきであることを意味する（例えば、Ｙシステム時間で記録された材料の１００％の通常速度でＸシステム時間（少ないけれども未来への十分な時間（秒の端数）に再生を開始する）。開始のこのモードは、次に続くリアルタイムクロック固守（Ａｄｈｅｒｅｎｃｅ）が所望の動作を生み出す調和した開始を保証する。休止の機会は、単に、特定のユーザ行動がプレーヤに分同期補正（例えば、マスターであるべき一つのプレーヤを宣言し、ユーザが再生を停止或いは休止する度に、全てのチャイルドプレーヤをそれに同期させる。
【００５４】
本発明のハードウェアアーキテクチャのブロック図は、図１を参照して説明される。図１を参照すると、セッション始動モジュール１０１は、セッションを記録する準備として種々の“ハウスキーピング”機能を行なう。セッション始動モジュールは、好適には、種々の記録構成要素に連結されるコンピュータに基づいたシステム上で実行されるソフトウェアとして具体化される。そのタスクの間で、セッション始動モジュールは、セッション蓄積装置１０３が生成することができる時間的データを蓄積するための十分な利用することができる蓄積容量を有することを確かめなければならない。これは、記録されるセッションの長さ、及び、使用されるキャプチャ装置の数／型に関する推定を行うことにより達成される。キャプチャセッション始動モジュール１０１は、各々のキャプチャ装置１０２ａ−ｃによって“記録”の開始を同様に同期させる。各々のキャプチャ装置は、同時に、或いは、異なった時間に記録を開始することができる。
【００５５】
キャプチャ装置１０２ａ−ｃは、種々のメディアのタイムストリームを獲得し、或るインスタンスにおいてはイベントを生成する。キャプチャ装置１０２ａは、タイムストリームとイベントデータ１０７を発生させる。現時点での好適な実施態様においては、キャプチャ装置１０２ａの例は、カリフォルニア州、サンホセのゼロックスカンパニー（Ｘｅｒｏｘ Ｃｏｍｐａｎｙ）のＬｉｖｅＷｏｒｋｓ（商標）から入手可能な市販の製品ＬｉｖｅＢｏａｒｄ（商標）のような電子ホワイトボードである。相互作用が発生するに従って、ＬｉｖｅＢｏａｒｄから獲得されたタイムストリームデータは、非同期的に発生する。イベントも、所定の機能（例えば、ＬｉｖｅＢｏａｒｄの上でページの変更）の呼び出しによって同様に発生させられる場合がある。
【００５６】
キャプチャ装置１０２ｂは、タイムストリーム１０８を発生させる。そのような型のキャプチャ装置においては、キャプチャ装置は絶えずタイムストリームデータを獲得するモードにある。キャプチャ装置１０２ｂの典型的な例は、ビデオ及びオーディオのレコーダである。そのようなキャプチャ装置１０２ｂの別の例は、ポインタである。ポインタキャプチャ装置は、ポインタ、例えば、投影されたスライド或いは他の視覚部材の上で何かを指し示すために、プレゼンテーションの間に典型的に使われるレーザーポインタの動きを獲得するものである。ポインタキャプチャ装置は、一般的に見られる材料が前もって用意されているときに、正式のプレゼンテーションのために特に有益である。ポインタタイムストリームの再生は、このようにプレゼンテーションの再生の間のポインタの動きを示す。
【００５７】
キャプチャ装置１０２ｃは、イベント１０９を単に発生させる。キャプチャ装置１０２ｃの例は、ボタンである。ボタンは、ボタンタイムストリームのイベントの生成を、ボタンを操作するユーザと関連づける装置である。ボタンイベントは、興味があるトピックの開始、特に有益な対話、トピックの切り換わりのような種々の活動を指し示すために、ユーザによって生成される場合がある。別の例は、スライドプロジェクタである。スライドプロジェクタタイムストリームにおけるイベントは、スライドの変更を指し示す。
【００５８】
キャプチャ装置１０２ａ−ｂは、好適には、デジタルフォーマットでタイムストリームを獲得する。タイムストリームの種々の部分への直接的且つランダムなアクセスを容易にするため、デジタルフォーマットでタイムストリームを蓄積することは望ましい。しかしながら、アナログフォーマットでタイムストリームデータを獲得して蓄積することは、本発明の範囲内である。タイムストリームのフォーマットは、タイムストリームを生成するために使用されるキャプチャ装置に対応する。例えば、オーディオのタイムストリームは、或る規則的な間隔で取られた一組のオーディオのサンプルから成るが、一方、ＬｉｖｅＢｏａｒｄタイムストリームがタイムスタンプされたプリミティブな動作（以下よりの詳細に説明される）の履歴ファイルである。獲得されたタイムストリームデータの管理は、どのような方法であるにせよ、それらが最も適切であると見做す方法で、それらのデータを蓄積するために選択することができる種々のメディアサーバによって行なわれる。
【００５９】
生成された時間的データは、セッション蓄積装置１０３に蓄積される。セッション蓄積装置１０３は、データの異なった型、すなわち、セッションデータ、イベントデータ、及び、タイムストリームデータについて永久的な蓄積装置を提供する。セッション蓄積装置１０３は、実際には、異なった物理的な蓄積装置に分散され、タイムストリームアーキテクチャ（以下に述べる）の異なった構成要素によって管理される。
【００６０】
同様に、セッション蓄積装置１０３に連結されているのは、時間的データアナライザ１０４である。時間的データアナライザ１０４は、イベント１１０を識別するために、時間的データ１１１を分析するために使われる処理手段（例えば、コンピュータに基づいたシステム）である。イベント情報は、セッション蓄積装置１０３に同様に蓄積される。
【００６１】
記録されたセッションへのアクセスは、セッションアクセスワークステーション１０５により達成される。このアクセスは、ネットワーク（例えばクライアント−サーバアーキテクチャで）を介して、或いは、直接接続とすることができる。アクセスセッション始動モジュール１０９は、セッションを再生するために必要な種々の“ハウスキーピング”機能を行う。アクセスセッション始動モジュールの機能性は、典型的にはセッションアクセスワークステーション１０５によって行なわれる。セッションアクセスワークステーション１０５は、典型的にはコンピュータ制御型ディスプレイシステムであり、そこでは、セッション再生に対する制御は、ディスプレイ上に表示されたグラフィックユーザインターフェースにより達成される。そのようなグラフィックユーザインターフェースは、以下に述べられる。現時点での好適な実施態様においては、セッションアクセスワークステーションは、カリフォルニア州、マウンテンビューのＳＵＮ Ｍｉｃｒｏｓｙｓｔｅｍｓ Ｉｎｃ．から入手可能なＸ−Ｗｉｎｄｏｗｓグラフィックユーザインターフェースを備えたＳｕｎ ＯＳ ４．１オペレーティングシステムが実行されるＳＵＮ ＳｐａｒｃＳｔａｔｉｏｎ−１０である。
【００６２】
更に、セッションアクセスワークステーション１０５に連結されているのは、プレーヤ１０６、再生制御装置１０７、及び、エディタ１０８である。種々のプレーヤ、再生制御装置、及びエディタの各々は、セッションアクセスワークステーションの中で統合される。そこで、電子ホワイトボードタイムストリームの再生は、ワークステーションのディスプレイ上の第１のウィンドウにより達成され、ビデオタイムストリームはワークステーションのディスプレイ上の第２のウィンドウにより達成され、オーディオタイムストリームは、ワークステーションのオーディオサブシステムにより達成される。しかしながら、プレーヤはセッションアクセスワークステーションの中で統合される必要がなく、個別の再生装置とすることができることは当業者にとって明白だろう。更に、現時点での好適な実施態様においては、単一のウィンドウが、プレーヤ、再生制御装置、及び、エディタの機能を行なうことができる。現時点での好適な実施態様におけるウィンドウの組織及びそれらに付随する機能性は、図３を参照して以下に詳細に述べられる。
【００６３】
最後に、エディタの使用により生成された新しい時間的データ１１２は、セッション蓄積装置１０３に蓄積される。
【００６４】
共同作業におけるＬｉｖｅＢｏａｒｄの主要な機能は、各々のユーザが見ることができて、相互に作用することができる“共有表現”を提供することである。ＬｉｖｅＢｏａｒｄとそのオペレーティンングソフトウェアは、そのような“共有表現”が単一のＬｉｖｅＢｏａｒｄ装置の上にある必要がないように設計されることに注意すべきである。実際の共同作業が異なった物理的な位置で行われるように、多数のＬｉｖｅＢｏａｒｄｓがネットワーク経由で一緒に連結することができる。
【００６５】
現時点での好適な実施態様において使われたようなＬｉｖｅＢｏａｒｄは、主にセッション記録へインデックスを生成するための手段であるようには意図されていない。しかしながら、以下に一層詳細に議論されるように、ＬｉｖｅＢｏａｒｄは、それを記録されたセッションの次の再生を制御するための有益なツールにする独特の能力を有する。ＬｉｖｅＢｏａｒｄは、Ｔｉｖｏｌｉアプリケーションの制御の下で動作する。Ｔｉｖｏｌｉアプリケーションは、Ｐｅｄｅｒｓｅｎ、Ｅ．、Ｋ．ＭｃＣａｌｌ、Ｔ．Ｍｏｒａｎ、及び、Ｆ．Ｈａｌａｓｚによる““Ｔｉｖｏｌｉ：Ａｎ Ｅｌｅｃｔｒｏｎｉｃ Ｗｈｉｔｅｂｏａｒｄ ｆｏｒ Ｉｎｆｏｒｍａｌ Ｗｏｒｋｇｒｏｕｐ Ｍｅｅｔｉｎｇｓ”，Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ｌＮＴＥＲＣＨＩ’９３ Ｃｏｎｆｅｒｅｎｃｅｏｎ Ｈｕｍａｎ Ｆａｃｔｏｒｓ ｉｎ Ｃｏｍｐｕｔｉｎｇ Ｓｙｓｔｅｍｓ，ｐｐ．３９１−３８９，Ａｐｒｉｌ １９９３に詳細に説明されている。
【００６６】
Ｔｉｖｏｌｉは、“描画”プログラムと知られている画像生成プログラムのクラスに似ているユーザインターフェースを有している。描画プログラムは、グラフィックオブジェクトの収集物のような画像を生成し操作する。Ｔｉｖｏｌｉ図面は、グラフィックオブジェクトとして描かれる。グラフィックオブジェクトは、以下のものを含む。
−ストローク：ペン入力装置により生成された“デジタルインク”オブジェク。
−文字：キーボード経由で生成されるか、テキストファイルから持ち込まれた。
−画像／アイコンオブジェクト：持ち込まれた或いはコピーされた。
−構造化オブジェクト：データベースから持ち込まれた。
−クロック：クロックジェスチャーと共に生成される。クロックは、その生成時間を表す丸いアナログ時計文字盤として現れるＬｉｖｅＢｏａｒｄの上で生成される特別なマークである。
【００６７】
Ｔｉｖｏｌｉは、実行されたプリミティブな動作の履歴リストを維持する。例えば、オブジェクトを付け加える、オブジェクトを削除する、オブジェクトを生成する、オブジェクトを変える、オブジェクトを選択する、または、ページを変える。履歴リストの全てのプリミティブな動作は、タイムスタンプされてオブジェクトと関連付けられる。以下に詳細に述べられるように、イベントを識別するために分析されるのがこの履歴リストである。
【００６８】
ＬｉｖｅＢｏａｒｄに現れるグラフィックオブジェクトは、ミーティングのコースの間に作られるか、或いは、パーソナルコンピュータ上のワードプロセッシングファイルを開ける操作に似た方法で、或るメモリ媒体（例えば、フロッピーディスク）からロードされるかのいずれかとすることができる。この後者のインスタンスは、セッションが正式のプレゼンテーションであるときに、特に有益である。
【００６９】
ＬｉｖｅＢｏａｒｄの動作の別の重要な局面は、ジェスチャーの使用である。ジェスチャーは、例えば他の任意の“インクストローク（ｉｎｋｓｔｒｏｋｅ）”のように生成されるが、コマンド（例えば編集コマンド）として解釈されるＬｉｖｅＢｏａｒｄとの相互作用である。例えば、もし特定のオブジェクトが“削除”されるべきであれば、オブジェクトはペンにより囲むジェスチャーと、呼び出された削除コマンド（例えば、ピグテールジェスチャー）で選択される。削除が生じた後、ジェスチャーによって引き起こされたマーキングは、もはやＬｉｖｅＢｏａｒｄには現れないしかしながら、後で述べられるように、本発明においては、セッションが再生されるとき、“ゴースト”画像が残る場合がある）。
【００７０】
上述したように、セッション蓄積装置は、異なった型のデータ、すなわち、セッションデータ、イベントデータ、及び、タイムストリームデータについての永久的な蓄積を提供するタイムストリームアーキテクチャの機能構成要素である。セッション蓄積装置は、実際には、異なった物理的な蓄積装置に分散され、タイムストリームアーキテクチャの異なった構成要素によって管理される。セッション蓄積装置を、タイムストリームデータベース（セッションとイベントデータ用）、及び、バルクタイムストリーム蓄積装置（タイムストリームデータ用）に分けることが最も実際的である。
【００７１】
バルクタイムストリーム蓄積装置は、タイムストリームの実際のデータが蓄積され管理されるところである。ビデオの場合には、これは、デジタル化されて圧縮されデジタル化されたビデオフレームの長いかさばったシーケンスから成る。タイムストリームアーキテクチャにおいては、タイムストリームデータの管理は、どのような方法であれ、それらが最も適切であると見做す方法でそれらのデータを蓄積するために選択することができる種々のメディアサーバに任される。現時点での好適な実施態様においては、大部分のメディアサーバは、それらのデータを通常のＵｎｉｘファイルに蓄積するが、他の蓄積機構（例えばオーディオ／ビデオタイムストリームのアナログ蓄積のためのコンピュータ制御型ＶＣＲ）のためのメディアサーバも同様に実施された。メディアサーバについては、断続した少容量データ（例えば、ラップトップコンピュータによって作り出された文のノート）を備えたタイムストリームのための最も便宜的な機構とすることができる、そのタイムストリームデータのためのタイムストリームデータベースを使うことも可能である。
【００７２】
タイムストリームデータベースは、セッションとイベントデータ、すなわち、全ての情報をセッションに組織化し、セッションの要素を記述するデータ、を蓄積して検索するための蓄積場所である。タイムストリームデータベースは、ユーザが、所望のセッションを位置決めし、どのタイムストリームがそのセッションに関連付けられているのかを決定し、セッションとそのタイムストリームに連付けられているイベントを見つけ出すことをサポートする。タイムストリームデータベースは、セッションデータの閲覧をサポートするだけでなく、セッションとイベントの選択的な検索を可能と質問能力を有するデータベースであるべきである。セッションとイベント情報は、数ヶ月、数年にわたって持続しなければならず、したがって、不揮発性装置（通常はディスク）に蓄積されなければならない。タイムストリームアーキテクチャはオブジェクト志向であるので、オブジェクト志向のデータベースが、タイムストリームデータベースのための持続性があるオブジェクト蓄積装置として適切である。現時点での好適な実施態様においては、タイムストリームデータベースは、Ｕｎｉｘファイルシステム上で実施される。
【００７３】
時間的データ分析は、抽出すべきタイムストリームと所望のイベントによって獲得された情報に対して特定のものである。オーディオの情報のタイムストリームの場合には、イベントの一つの有益な形態は、特定の人がいつ話しているかを知ることである。従って、１）異なった人がいつ話しているかを表すためにタイムストリームをセグメント化し、２）話している人に種々のセグメントを割り当てて、オーディオストリームを分析することが望ましい。したがって、これらのセグメントは、タイムストリームにおけるイベントを表現することになる。オーディオストリーム上でそのような分析を行なうための技術は、両方とも本出願と同じ譲受人に譲渡されている“Ｕｎｓｕｐｅｒｖｉｓｅｄ Ｓｐｅａｋｅｒ Ｃｌｕｓｔｅｒｉｎｇ Ｆｏｒ Ａｕｔｏｍａｔｉｃ Ｓｐｅａｋｅｒ Ｉｎｄｅｘｉｎｇ Ｏｆ Ｒｅｃｏｒｄｅｄ Ａｕｄｉｏ Ｄａｔａ”と題された、同時継続中の出願番号０８／２２６，５２５号、及び、“Ｓｅｇｍｅｎｔａｔｉｏｎ Ｏｆ Ａｕｄｉｏ Ｄａｔａ Ｆｏｒ Ｉｎｄｅｘｉｎｇ Ｏｆ Ｃｏｎｖｅｒｓａｔｉｎａｌ Ｓｐｅｅｃｈ Ｆｏｒ Ｒｅａｌ−Ｔｉｍｅ Ｏｒ Ｐｏｓｔｐｒｏｃｅｓｓｉｎｇ Ａｐｐｌｉｃａｔｉｏｎｓ”と題された出願番号８／２２６，５１９号に説明されている。いずれの場合でも、いったんそのような分析が行なわれると、オーディオのタイムストリームのためのイベントのリストは、それぞれがタイムスタンプ、期間、及び、話者識別子を含む複数のデータ項目から成ることになる。
【００７４】
ＬｉｖｅＢｏａｒｄによって獲得されたタイムストリームの分析の場合には、イベントは、図面の描画或いは言葉の書き込み、ページ変更、図面或いは言葉の消去、既存のマーキングに対してなされた注記、或いは、特定のコマンドのＬｉｖｅＢｏａｒｄユーザインターフェースへの入力とすることができる。上述したように、ＬｉｖｅＢｏａｒｄは、Ｔｉｖｏｌｉアプリケーションの制御の下で動作する。Ｔｉｖｏｌｉによって発生させられたタイムストリームは、時間的な順序で記録されたタイムスタンプされたプリミティブな動作の履歴リストである。そのようなタイムストリームの分析は、意味のあるイベントを識別するための、プリミティブな動作のシーケンスを構文解析することを伴う。
【００７５】
ＬｉｖｅＢｏａｒｄ上の各々のマーキングは、オブジェクトと呼ばれる。各々のオブジェクトは、それと関連づけられた一つ或いはそれ以上のイベントを有する。本発明にとって、オブジェクトと関連している全てのイベントが識別され、セッションの中へのインデックスとしてユーザに提供されることが必要である。セッションの中へのインデックスとしてユーザに確認され、提供されることが、必要である。従って、本発明における時間的データ分析は、オブジェクト上の種々のイベントを識別し、そのイベントを蓄積する。全てのオブジェクトについて、オブジェクト生成イベントが存在する。オブジェクトは、オブジェクト変更イベントとオブジェクト削除イベントを同様に有することができる。ＬｉｖｅＢｏａｒｄタイムストリームの更なる局面は、ＬｉｖｅＢｏａｒｄウィンドウに関して以下に議論される。
【００７６】
現時点での好適な実施態様においては、セッションアクセスワークステーションは、蓄積媒体上に蓄積されるプログラムインストラクションの制御の下で動作するコンピュータ制御型ディスプレイシステムであり、図２を参照して述べられる。図２を参照すると、コンピュータに基づいたシステムは、バス２０１経由で連結される複数の構成要素から成る。ここで説明されるバス２０１は、本発明を不明瞭にしないために、単純化される。バス２０１は、（例えば、プロセッサーバス、ローカルバス、及び、Ｉ／Ｏバス）の階層構造と同様に、複数のパラレルバス（例えば、アドレスバス、データバス、及び、ステータスバス）から構成することができる。いずれの場合でも、コンピュータシステムは、内部メモリー２０３（内部メモリー２０３は、典型的には、ランダムアクセスメモリー或いはかリードオンリーメモリーの組み合わせであることに注意すべきである）からバス２０１経由で提供されるインストラクションを実行するためのプロセッサー２０２を更に含んでいる。動作中に、本発明の種々の機能構成要素を実行するためのプログラムインストラクションは、内部メモリー２０３に蓄積される。プロセッサー２０２と内部メモリー２０３は、個別の構成要素、或いは、用途特定集積回路（ＡＳＩＣ）チップのような単一の集積装置とすることができる。プロセッサー２０２と内部メモリー２０３は、ここに述べられる種々の処理機能を行なうための電気回路から成る。
【００７７】
同様に、バス２０１へ、英数字を入力するためのキーボード２０４、データを蓄積するための外部蓄積装置２０５、カーソルを操作するためのカーソル制御装置２０６、及び、視覚的出力を表示するためのディスプレイ２０７が連結される。キーボード２０４は、典型的には標準のＱＷＥＲＴＹキーボードであるが、同様に、電話機のようなキーパッドにすることもできる。外部蓄積装置２０５は、固定の或いはリムーバブルの磁気或いは光学ディスク装置とすることができる。カーソル制御装置２０６は、典型的には、或る機能の実行をプログラムすることができるそれと関連したボタン或いはスイッチを有する。更に、バス２０１へ、オーディオ出力手段２０８が連結される。オーディオ出力手段２０８は、典型的には、何らかのオーディオ信号発生手段（例えば、デジタル・アナログ変換器）及びスピーカーから成る。オーディオ出力手段２０８は、プレーヤとしても動作することができる。最後に、バス２０１に連結されるのが、ビデオ出力手段２０９である。ビデオ出力手段は、典型的には、ビデオ信号をディスプレイ２０７に表示できるようにするための市販の処理手段、例えば、ビデオボードである。
【００７８】
セッションアクセスワークステーションが、蓄積媒体に蓄積されたプログラムされたインストラクションに従って動作するコンピュータに基づいたシステム上で具体化されているが、本発明は、固定機能のターミナル或いはＬｉｖｅＢｏａｒｄのような任意のコンピュータ制御型ディスプレイシステム上で実行することができる。
【００７９】
セッションアクセスワークステーションは、上述したように、タイムストリームアーキテクチャを参照し、再生と制御のためのプログラムインストラクションを使って動作する。図３は、セッションアクセスワークステーションの基本的なローレベル動作を説明する単純化された状態図である。図３を参照すると、セッションアクセスワークステーションは、セッションを再生する依頼が受信されるとき、最初は、開始状態３０１にある。次いで、セッション始動状態３０２に入る。セッション始動状態３０２の間、再生されるべきセッションがユーザによって選択される。選択されたセッションの時間的データは検索され、種々のプレーヤ、制御装置、及び、エディタが同期化される。種々のプレーヤは、セッションアクセスワークステーションとして同じ物理的な装置に統合することができる、或いは、それらを分離した装置とすることもできることに注意すべきである。次いで、種々のウィンドウ（すなわち、プレーヤ、再生制御装置、及び、エディタ）は、セッションアクセスワークステーションに連結されたディスプレイに表示される。この時点において、“作動”状態３０３と名付けられた状態に入る。ここで述べられた作動状態３０３は、セッションアクセスワークステーションが相互作用を行っており、セッションアクセスワークステーションについてのユーザインタフェースの種々の機能を何時でも呼び出すことができるという意図を伝えるために使われる。いずれの場合でも、最初に“作動”状態３０３に入ったときに、セッションには、初めからセッションを再生するためのキューが与えられる。“作動”状態３０３にある間は、ユーザ入力に応じて種々のプリミティブな機能が行なわれる。“再生”コマンド、または、等価なグラフィックユーザインターフェース入力（例えば特定のアイコンの上でクリックすること）の呼び出しは、セッションの開始を引き起こすことになる（ボックス３０４）。これにより、再生状態は“再生”にセットされる。“停止”コマンドの呼び出しは、セッションの再生を停止させ、再生状態は“停止”にセットされる（ボックス３０５）。特定のウィンドウにおける“ディスプレイ修正”コマンド或いは制御の呼び出しは、ウィンドウを修正させる（ボックス３０６）。そのような修正は、タイムラインインターフェースで表示されたトラックを変えることができる。再生制御の呼び出しは、再生点を変更させる（ボックス３０７）。これは、新しい点でキューを与えてセッションの再生を引き起こす。編集コマンドの呼び出しは、既存の時間的データへの修正、或いは、新しい時間的データの生成のいずれかを引き起こす（ボックス３０８）。種々の状態における動作の開始により、作動状態３０３への復帰が生じる。
【００８０】
そのような多数の動作は、セッションアクセスワークステーション上で特定の機能を達成するために、呼び出される場合があることに注意すべきである。
例えば、ＬｉｖｅＢｏａｒｄウィンドウのオブジェクトを選択する動作は、“停止”に続いて“ディスプレイを修正”を呼び出すことができる。
【００８１】
最後に、動作状態３０３にある間、“退去”コマンドの呼び出しは、アクセスセッションを停止させることになる（停止状態３０９）。
【００８２】
図４は、セッションアクセスワークステーションのスクリーンディスプレイを説明する。図４のスクリーンディスプレイは、同時に開いている複数のウィンドウを示す。ほとんどのグラフィックユーザインターフェース指向のウィンドウに関しては、ウィンドウのサイズと配置はユーザの選択事項である。図４を参照すると、同時に表示されているのは、ＬｉｖｅＢｏａｒｄウィンドウ４０１、ビデオウィンドウ４０２、タイムラインインターフェースウィンドウ４０３、ノートウィンドウ４０４−４０５、オーディオのウィンドウ４０６、マルチメディア編集ウィンドウ４０７、及び、ミーティングプレーヤウィンドウ４０８である。ＬｉｖｅＢｏａｒｄウィンドウ４０１は、プレーヤ、再生制御装置として、或いは、エディタとして動作することができる。プレーヤとして、それはＬｉｖｅＢｏａｒｄタイムストリームを再生するために使用される。制御装置として、それは、そこに表示されたオブジェクトとの相互作用を通してセッションの再生に対する制御を可能にする（以下に詳細に述べる）。エディタとして、ユーザは、新しいオブジェクトを生成するか、或いは、セッションの次の再生で表示されるセッションに関する特定の注釈を作ることができる。
【００８３】
ビデオウィンドウ４０２は、ビデオのタイムストリームを再生するために使用されるプレーヤである。ノートウィンドウ４０４と４０５は、ミーティングのコースの間のキャプチャ装置として使用可能なラップトップコンピュータ或いは同様な装置とすることができるノートを再生するために使用されるプレーヤである。
【００８４】
ミーティングプレーヤウィンドウ４０８は、プレーヤと再生制御装置である。ミーティングプレーヤウィンドウ４０８は、種々な他の時間的データのイベントを使って、それが再生されるにつれてミーティングのダイナミックスのシミュレーションを提供する。再生は、ミーティングプレーヤウィンドウ４０８に現れる種々のアイコンとの相互作用により制御される。ミーティングプレーヤウィンドウは、以下に詳細に述べられる。
【００８５】
オーディオウィンドウ４０６は、オーディオのタイムストリームの再生、特にセッションのオーディオ再生のための話者の音量を制御するために使用される制御装置である。
【００８６】
マルチメディアエディタ４０７は、タイムストリームとしてセッションに導入して戻すことができるノート、イベント、或いは、他の情報を生成するために使用されるエディタである。更に、マルチメディアエディタ４０７は、見ためのセッションアクセスワークステーションを必要としないマルチメディア文書を生成するために使うことができる。
【００８７】
タイムラインインターフェースウィンドウ４０３は、再生制御装置である。タイムラインインターフェースウィンドウ４０３は、イベントの時間的なものに基づいたビューを、それらがセッションの間に発生するに従って具体的に表現する。タイムラインインターフェースウィンドウ４０３は、以下に詳細に述べられる。
【００８８】
本発明の現時点で好適な実施態様のタイムラインインターフェースは、タイムラインに沿ったイベントの表現との相互作用により再生制御を提供する。イベントは、固定期間、或いは、期間不定（生成時間だけが重要である）のいずれでもよい。セッション始動の間、イベントデータはセッションアクセスワークステーションの中へロードされる。イベントデータは、タイムライン上で縮尺調整されたビジュアルインジケータを生成するために使われる。これらのビジュアルインジケータは、再生をセッションの対応する時間に直接移動させるインデックス点として使用することができる。イベントデータをタイムライン表現に組織するための内部構造がここで述べられる。
【００８９】
ロードされたイベントデータは、ユーザにイベントデータを簡単な方法で制御させるために組織される。この組織は、型マップ、イベントメニュー、及び、トラックマップにより定義される。全てのイベント型は、Ｈｔｙｐｅｓと呼ばれる階層構造の名前を有する。例えば：
Ｓｐｅａｋｅｒ／Ａｄａｍ
ＬｉｖｅＢｏａｒｄ／Ｅｄｉｔ／Ｍｏｖｅ
Ｂｕｔｔｏｎ／Ｂｅｔｔｙ
Ｎｏｔｅ／Ｌａｐｔｏｐ／Ｃｈａｒｌｉｅ
ユーザが定義した型マップは、そのようなＨｔｙｐｅｓを生成するために使われる。型マップは、各々のイベントのパラメータを使用し、Ｈｔｙｐｅを作り出すルールのセットである。次いで、Ｈｔｙｐｅｓのセットは、時間トラックエリアのラベルエリア内でユーザに対して示される簡単な階層構造のイベントメニューの中へ整えられる。全てのイベントは、トラック上でユーザに表示することができる。レイアウトは、トラックマップにより定義される。トラックマップは、各々が対応するトラック上に表現されるＨｔｙｐｅｓのリストを持つ複数のトラックのリストである。
【００９０】
ビジュアルインジケータは、各々のＨｔｙｐｅｓについて生成される。ビジュアルインジケータは、どのようなグラフィックスタイルでもよいが、ビジュアルインジケータの二つの概略のクラスが最も一般的に使われる。第１のクラスは、セグメントと称される。セグメントは、イベントが生じる期間に対応するために、タイムラインの上でサイズ調整され、縮尺調整された長方形のボックスとして表示される。第２のクラスは、開始点と称される。これらは、左端がイベントが始まった時間の点に垂直に位置し、右端がイベントに対応する活動が無期限に続くことを表すために、右を“指す”三角形として表示される。そのようなイベントについては、イベント（例えば、人がノートを取りはじめることを示すイベント）の期間についての関心はない。種々の動作は、ビジュアルインジケータに関して行うことができる。ビジュアルインジケータの動作は、以下のものを含む。
−ビジュアルインジケータを生成する（所定の型又はデフォルトによる型）。
−ビジュアルインジケータを選択する。
−ビジュアルインジケータを選択から外す。
−異なったトラックへビジュアルインジケータを動かす（時間は同じまま）。
−異なったトラックへビジュアルインジケータをコピーする（時間は同じまま）。
−ビジュアルインジケータにより表現されたイベントに関する一層多くの情報を見る。
−選択されたビジュアルインジケータのディスプレイパラメータを編集する。
−ビジュアルインジケータ時間を編集する。
−ビジュアルインジケータ開始時間を調整する。
−ビジュアルインジケータ（セグメント）終了時間を調整する。
−ビジュアルインジケータ時間位置を調整する。
【００９１】
図５は、タイムラインウィンドウ内の基本的なエリアを説明する。図５を参照すると、タイムラインウィンドウ５０１は、複数のディスプレイエリアから成る。概観時間トラックエリア５０２は、セッションの概観を提供するために使われ、焦点時間トラックエリア５０３は、全体のセッションより少ないか等しい期間にわたって一層詳細な情報を提供する。各々のトラックエリアの動作が、同じ型の時間的な情報を提供することができることは注意すべきである。違いは、情報が意図する詳細さ（すなわち、全体のセッション対セッションの一部）のスケールである。
【００９２】
概観トラックエリア５０２内に定義されたのはクロックエリア５１２であり、焦点時間トラック５０３内に定義されたのはクロックエリア５１３である。対応する時間トラックエリアの時間スパンとスケールを示すために、各々のクロックエリア５１２と５１３は、クロック時間と印マークを現す。概観時間トラックエリア５０２は、その中に、焦点トラック５０８と称される特別なトラックを定義した。焦点トラック５０８の上にあるのは、焦点セグメント５０９である。焦点セグメント５０９は、焦点時間トラックエリア５０３に詳述されるセッションの期間に対応する。更に、それぞれのトラックエリアに関連するのは、ラベルエリアである。各々のラベルエリアは、対応する時間トラックエリアで表示される“トラック”を識別するためにのものである。ラベルエリア５０４は概観時間トラックエリア５０２に対応し、ラベルエリア５０５は焦点時間トラックエリア５０３に対応する。概観時間トラックエリア５０２と焦点時間トラックエリア５０３の間の関係は、焦点エリア５０７で示される。この関係は、焦点セグメント５０９の終わりから焦点時間トラックエリア５０３の終わりへ広がるアーム５１０と５１１により、明白に目で見えるようにされる。
【００９３】
同様に、図５で説明したのはボタンエリア５０６である。ボタンエリア５０６は、種々の再生制御機能を呼び出すための“ソフト”ボタンを含む静的なエリアである。そのようなボタンは、カーソル制御装置を使うことにより、ポイントしてクリックする方法で呼び出される。ボタンの配置と機能は、例示的なものであり、特定の一般に使用される機能への簡単なアクセスを提供することを意図している。
【００９４】
ボタン５２０は、再生を１０秒スキップして戻させるために使用され、ボタン５２１は、再生を１０秒スキップして先送りさせる。ボタングループ５２２の方向を示す矢は、文脈に応じた移動或いはスクロールのために用意される。ボタン５２３は、セッションの再生を停止するために用意される。ボタン５２４は、セッションの再生を始める。ボタン５２５は、選択されたトラック或いは選択されたトラックのセットの上の次のイベントへスキップすることを可能とする。ボタン５２６は、編集モードに入って、タイムラインインターフェース、或いは、その上に表示されたビジュアルインジケータを修正するために用意される。ボタングループ５２７は、文脈に応じた削除或いはコピー（例えば、ビジュアルインジケータをコピー或いは削除する）のために用意される。ボタングループ５２８は、文脈に応じた拡張或いは折り畳み（例えば、トラックのセットを単一のトラックの中へ折り畳むか、または、折り畳まれたトラックのセットを拡大する）のために用意される。ボタン５２９は、セッションメニューを表示するために使われる。セッションメニューは、ユーザが、セッションのためにデータをロードし、セッションをセーブし、或いは、セッションを止めることを可能にする。
【００９５】
上記されたように、焦点時間トラックディスプレイエリアに示されるセッションの一部は、概観時間トラックエリアの焦点トラックの上に含まれる焦点セグメントにより示される。焦点時間トラックエリアにおいて焦点のスパンを変えるために、焦点セグメントはユーザによりサイズが修正される。これは、図６−７で説明される。図６において、焦点セグメント６０１は、焦点トラックエリア６０２に示されるセッションの一部を示す。この関係を識別する他のビジュアルキューは、それぞれのクロックエリア６０３と６０４に対する変化、すなわち、時間トラックエリアについての印マークとそれぞれの開始及び終了時間のサイズ修正、及び、時間インジケータ６０５と６０６の相対位置決めを含む。同様に、図６に示されるには、現在の再生時間を示す再生時間インジケータ６０７である。
【００９６】
焦点セグメントのサイズ修正は、種々のカーソル制御動作により達成される。現時点で好適な実施態様においては、カーソルが焦点セグメントの右端の上に位置している間にマウスのボタンが押されると、焦点セグメントはカーソルの移動の方向に引き伸ばされる。焦点セグメントの左側も、同じ方法で操作される。
【００９７】
図７は、焦点時間トラックエリアに示されたスパンを増加するために、右に引き伸ばされた焦点セグメント７０１の右側の結果の図である。この増加したスパンは、クロックエリア７０２と７０３の変化によりも同様に反映される（印マークの縮尺修正と焦点時間トラックエリアについての終了時間の変化）。
【００９８】
タイムラインインターフェースは、多数のセッションの再生を制御するために、或いは、単一のセッションの多数のスパンに焦点を合わせるために使用することができる。図８は、二つのセッションのためのタイムラインインターフェースの図である。二つのセッションは、一日中のミーティングの午前半分と午後半分を表現するかもしれない。または、それらは、毎週のプロジェクト検討ミーティングのような定期的に予定されたミーティングの異なった出来事を表現するかもしれない。典型的には、二つのセッションは或る共通性を有する。図８を参照すると、タイムラインインターフェースウィンドウ８０１は、二つの概観時間トラックエリア８０２と８０３と、対応する焦点時間トラックエリア８０４と８０５から成る。焦点セグメント８０６は、概観時間トラックエリア８０２に対応するセッションにおけるスパンと、焦点時間トラックエリア８０４におけるそのスパンについての詳細を示す。同様に、焦点セグメント８０７は、概観時間トラックエリア８０３に対応するセッションにおけるスパンと、焦点時間トラックエリア８０５におけるそのスパンについての詳細を示す。実際のトラックは、それぞれの焦点時間トラックエリア８０４と８０５で同一である必要はないことを示す。もしそれらが異なっていれば、分離ラベルエリアが必要とされる。ディスプレイエリアで非常に多くのスペースを使用するので、これは望ましくない。
【００９９】
図９は、単一のセッションの多数のスパンの詳細が焦点時間トラックエリアに表示される場合があることを表す更なる図である。これは、多数の焦点セグメントを概観時間トラックエリアの焦点トラックの上に表示させる。図９を参照すると、第１の焦点セグメント９０１は、焦点時間トラックエリア内の対応するエリア９０３に示された詳細を有する一方、第２の焦点セグメント９０２は、焦点時間トラックエリア内の対応するエリア９０４を有する。そのようなディスプレイは、再生する興味がない或るエリアが存在することが判っているときには望ましい（例えば、ＬｉｖｅＢｏａｒｄ上の特定のページに関する議論を検討したいだけということが前もって判っている場合）。デフォルトにより、焦点時間トラックエリアは、同じスケールの上で二つの焦点セグメントに均等に分けられる。しかしながら、図１０で説明したように、セッション期間に割り当てられた焦点時間トラックディスプレイの一部を修正することができる。ここでは、図９のエリア９０４は、図１０のエリア１００１へ増加され、図９のエリア９０３は図１０のエリア１００２へ減少させられた。サイズのこの増加は、エリア９０４の左側を左に移動するドラッグ動作により行うことができる。
【０１００】
図１１−図１４は、以下のキャプチャ装置、すなわち、Ｌｉｖｅｂｏａｒｄ、オーディオレコーダ、パーソナルコンピュータによる二つのユーザテーキングノート、ビデオレコーダ、及び、各ユーザ毎のボタン、から成るシステムについてのタイムラインインターフェースディスプレイ上で変化を示す。勿論、キャプチャ装置の他の組み合わせが利用される場合があり、また、幾つかのキャプチャ装置からのイベントは省略され、これにより、異なったタイムラインインターフェースディスプレイとなる。この例についてのセッション参加者は、アダム、ベティ、及び、チャーリーと名付けられる。
【０１０１】
図１１を参照すると、概観時間トラックエリアの１１０１は、全体のセッションについての情報を表示し、全体のセッションを示す焦点セグメントを有する。このようにして、焦点時間トラックエリア１１０２は、全体のセッションの詳細を表示する。再生インジケータ１１１３と１１１４は、それらのそれぞれの期間の中の現在の再生位置を示す。
【０１０２】
更に、セッションエリア１１０１と関連があるのが、セッション識別子１１０３である。セッション識別子は、再生されるセッションを識別する。
【０１０３】
概観セッション時間トラックエリアと関連している情報が提供され、従って、全体のセッションは、セッション開始時間１１０４とセッション終了時間１１０５を含む。セッション開始時間１１０４とセッション終了時間１１０５の各々は、セッションが起きた日の実際の時間を示すことができ、或いは、０：０：０に対する相対時間である（図１１で説明したように）。
【０１０４】
焦点時間トラックエリア１１０２と関連している情報は、スパン開始時間１１０６とスパン終了時間１１０７を含む。スパン開始時間１１３４とスパン終了時間１１３５の各々は、特定のスパンの日の実際の時間によるか、または、セッション開始時間０に対するものである。
【０１０５】
焦点時間トラックエリア１１０２は、各トラックが何を表すかの情報を提供するためのトラックラベルセクション１１１１を含む。トラック１１１７と１１１８は、ＬｉｖｅＢｏａｒｄ上で行なわれた編集イベントを表す。トラック１１１８は、ＬｉｖｅＢｏａｒｄウィンドウで行なわれる選択動作に応じて発生するものであり、以下に詳細に述べられる。トラック１１１７は、ＬｉｖｅＢｏａｒｄ上のオブジェクトで行なった種々の編集動作を表す。トラック１１１７において、各々の編集動作は独特にカラーコード化されたビジュアルインジケータを有する。そこで、赤色はオブジェクトの削除を表し、緑色はオブジェクトの付加を表し、青色はオブジェクトの移動を表す。
【０１０６】
トラック１１１９−１１２１は、オーディオのイベントを示す。トラック１１１９は、“アダム”が話しているセグメントを示し、トラック１１２０は“ベティ”が話しているセグメントを示し、トラック１１２１は“チャーリー”が話しているセグメントを示す。参加者が話しているとき、セグメントの各々のビジュアルインジケータは、視覚的に区別される（典型的には、色かテクスチャにより）。
【０１０７】
トラック１１２２−１１２３は、ミーティングの参加者であるアダムとチャーリーにより取られたノートの開始点を示す。ノートは、キャプチャ装置として動作しているパーソナルコンピュータ、または、他のテキスト生成装置で取られた。
【０１０８】
トラック１１２４は、“ボタン”押圧のイベントのインスタンスを示す。各々のミーティング参加者は、参加者が何か重要なものが議論されていると感じるときに押すことができるボタンを持っている。再び、ビジュアルインジケータは、ボタンを押圧した人を識別するために、カラーコード化される。そこで、例えば、青はベティが彼女のボタンを押圧したことを表し、緑はチャーリーが彼のボタンを押圧したことを表す。
【０１０９】
トラック１１２５は、ビデオタイムストリームに関するイベントのインスタンスを示す。そのようなイベントは、人が話すために立ち上がること、或いは、ホワイトボードに関しての何らかの型の身振りをすることを含むことができる。そのようなイベントは、ビデオタイムストリームの分析により識別される。
【０１１０】
上述したように、選択トラック１１１８は、ＬｉｖｅＢｏａｒｄウィンドウ内の選択相互作用の結果として自動的に発生させられる。選択相互作用は、ＬｉｖｅＢｏａｒｄ上に表示される種々のオブジェクト（例えば、言葉或いは図）が選択されるところである。次いで、選択されたオブジェクトに関するイベントは、タイムラインウィンドウ上に表示される。同様に、選択が空間的エリアに関して生じるかもしれないことは、注意すべきである。そのような選択においては、エリアが選択され、選択されたエリアに配置されたオブジェクトについてのイベントは、タイムラインの上に表示される。これは、特にマーキングがＬｉｖｅＢｏａｒｄから消されたセッションの一部の再生するために有用である（例えば、再生のプロセスの間、スキップが行われ、オブジェクトが消されたことに気付くか、または、それが別のオブジェクトと取り替えられた。）。図１１に戻って参照すると、種々の選択イベントが説明される。再び、好適には、ビジュアルインジケータは、イベントの型を示すためにカラーコード化される。生成イベント１１２７は、オブジェクトが生成された時間の点を示し、移動イベント１１２８は、オブジェクトがＬｉｖｅＢｏａｒｄ上で動かされた時間の点を示し、カラー変化イベント１１２９は、オブジェクトカラーが変えられたことを示し、削除イベント１１３０は、オブジェクトが削除されたことを示す。
【０１１１】
各々の時間トラックエリアの内容は、ユーザが修正可能である。トラックは、併合し、付加し、隠蔽し、或いは、移動することができる。時間トラックエリアの内容を修正するために、動作は対応するラベルセクションの中で行なわれる。例えば、図１１を参照すると、オーディオトラック１１１９−１１２１は、選択され、併合される場合がある。そのような併合されたトラックの結果は、図１２で説明され、そこでは併合されたトラック１２０１が生成されている。トラックの選択は、カーソル制御装置を操作して、カーソル制御装置に関連したスイッチをスイッチを押圧し、カーソルをトラックのラベルを通過するように移動させることにより、達成することができる。ラベルの選択の指示は、逆のビデオモードで選択されたラベルを表すような、或る視覚的な刺激により達成される。選択されたラベルの識別は、スイッチを離すことにより達成される。この時点で、種々のトラック動作オプションが表示される。次いで、ユーザは所望の動作（この場合は、併合動作）を選択する。しかし、これはトラックディスプレイ動作を実行することができる一つの方法である。他の技術は、プルダウンメニューにより、或いは、コマンドラインから入力されたコマンドにより呼び出すことができる。
−トラックの動作は、以下のものを含む
−トラックを選択する
−トラックを選択から外す
−トラックを生成する（所定のＨｔｙｐｅｓ）
−選択されたトラックを再配置する
−選択されたトラックを削除する
−選択されたトラックを（一つのトラックの中へ）折り畳む
−選択されたトラックを（そのＨｔｙｐｅｓに基づいてトラックのシーケンスの中へ）拡張する
−選択されたトラックのディスプレイパラメータを編集する
−トラックラベルを編集する
【０１１２】
異なったビジュアルインジケータの上のポイントとクリック動作は、異なった事を生じさせる。各々の場合において、タイムストリームの次の再生は、ビジュアルインジケータの始まりに対応する時間にセットされる。ノート（Ｎｏｔｅｓ）の場合には、ノート内のテキストを含むウィンドウが開けられる。そのような動作の発生は、図１３で説明される。図１３を参照すると、ビジュアルインジケータ１３０１がポイントされ、カーソル制御装置上のスイッチがクリックされた。これは、ミーティングの間に生成されたテキストを含んだテキストウィンドウ１３０２を開けさせる（ここでは、テキスト“ベティにより有用な指摘がなされた。上司とのミーティングにおいてこの議論を使う必要あり。”）。テキストウィンドウは、時間トラックディスプレイエリアの外の異なった位置で同様に現れる場合があることに注意すべきである。
【０１１３】
タイムラインは、垂直或いは水平方向に表示することができ、または、連続したデータの長いストリングを示すために他の視覚化技術と組み合わせて使うことができることに注意すべきである。
【０１１４】
プレーヤのフォームは、セッションの時間的データの、それが生成されたときと全く同じ形態で再生されることに限定されるものではない。そのようなプレーヤの例は、ミーティングプレーヤである。ミーティングプレーヤは、種々のミーティングダイナミックスを目に見えるように表現するために使われる。これは例えば人が再生される声を認識することができないが、話者を識別したいときに有用である。本発明のミーティングプレーヤは、ミーティングの間に発生する活動をシミュレートする。図１４は、ミーティングプレーヤを表示するウィンドウ１４００を説明する。図１４を参照すると、ミーティングは、各々が、ミーティング参加者を表現するビジュアルインジケータ１４０１−１４０３を含み、ビジュアルインジケータ１４０４と１４０５はノートテーキング装置（例えばラップトップコンピュータ）を表現し、ビジュアルインジケータ１４０６−１４０８は“ボタン”を表現する。再生の間、生じている現在のイベントを表現するアイコンはハイライトされる。ここでは、アイコン１４０１により表現された話者が話しているので、アイコン１４０１がハイライトされる。同様に、だれかがボタンを押したときに、対応するボタンアイコンはハイライトされて表示される。
【０１１５】
話者のアイコンの中に話者のごく小さい画像を含ませることは可能であることに注意すべきである。各々の関連づけられたアイコンが、タイムライン上の対応するトラックと同じ視覚的特徴を維持できることも同様に望ましい。そこで、もし、話者アイコン１４０１、ボタンアイコン１４０６、及び、コンピュータアイコン１４０４が、青の視覚的特徴を有するアダムと関連していれば、これらのアイコンは青となる。しかしながら、表示可能な色或いは他の要因の制限のために、これが不可能である状況もあり得ることが認められる。
【０１１６】
更に、ミーティングプレーヤウィンドウに表示されているのが、ＬｉｖｅＢｏａｒｄページとタイトルインジケータ１４１０とクロック１４１１である。ページとタイトルインジケータ１４１０は、再生のこの瞬間にＬｉｖｅＢｏａｒｄの上で現在見られている“ページ”を示す。クロック１４１１は、再生時間を示す。テーブル１４０９は、セッションがミーティングを表現するという事実に関して、ビジュアルキューを提供するために同様に表示される。
【０１１７】
ミーティングプレーヤは、再生を異なった話者に変えるために使う事もできる。これは、ユーザが特定の話者によりミーティングを容易に横切ることを可能にする。異なった話者への切り替えは、所望の話者のアイコンに対して“ポイントしてクリックする”動作により達成される。これは、選択された話者に関して時間的に次の点へ再生をジャンプさせることになる。更に、この動作はあらゆるアイコンに対して作用し、そこでは、選択されたアイコンと関連づけられたイベントの次のインスタンスへのジャンプが行われる（例えば、ページとタイトルインジケータ１４１０は、ＬｉｖｅＢｏａｒｄの次のページの始まりに再生をスキップするために、“ポイントしてクリックする”動作が行われる。）。このように、この例のミーティングプレーヤは、セッションの再生を制御するために更に動作する。
【０１１８】
ミーティングプレーヤは、分析することができる種々の他のイベントを示すように設計される場合がある。例えば、笑い或いは拍手がいつ生じているかを表すために、または、笑い或いは拍手の次の時間的な出来事へスキップするために、“笑い”アイコン１４１２或いは“拍手かっさい”アイコン１４１３を提供することができる。更に、好適な実施態様は、ミーティングを表現するために使われるが、同様の方法で、他の型の活動、例えば、プレゼンテーションを表現することができる。
【０１１９】
現時点で好適な実施態様のＬｉｖｅＢｏａｒｄウィンドウは、ＬｉｖｅＢｏａｒｄタイムストリーム、再生制御装置、及び、エディタのプレーヤとして同時に動作する。ＬｉｖｅＢｏａｒｄウィンドウは、前述のＴｉｖｏｌｉソフトウェアに基づく。ＬｉｖｅＢｏａｒｄウィンドウは、異なった再生モードで動作する。すなわち、過去の状態の正確な外観を再構築するアニメーテッドモード、カーソルがマーキング／編集が起きているエリアをポイントする“バウンシング−ボール”モード、及び、“ナル（ｎｕｌｌ）”モードである。アニメーテッドモードにおいては、ＬｉｖｅＢｏａｒｄウィンドウは、記録された順序でで、ＬｉｖｅＢｏａｒｄタイムストリーム（すなわちタイムスタンプされた履歴リスト）を再生する。“バウンシング−ボール”モードにおいては、セッションの終わり（またはページの終了状態）におけるＬｉｖｅＢｏａｒｄの状態が表示され、オブジェクトに関係したイベントが起き、オブジェクトがハイライトされ、カーソルによりポイントされる。“バウンシング−ボール”モードにおいては、カーソルの形はイベント（例えば、オブジェクトを生成するためのペン、オブジェクトを動かすための手、オブジェクトを削除するための消しゴム）の型を示すために変化する。“ナル”モードにおいては、セッション（またはページの終了状態）の終りにおけるＬｉｖｅＢｏａｒｄの終了状態が表示される。ナルモードは、ＬｉｖｅＢｏａｒｄウィンドウの更新が望ましくないときに使用される（例えば、それはユーザを当惑させる）。
【０１２０】
各々の再生モードにおいては、ゴーストと呼ばれる追加の特徴は、それが削除される後でも、ディスプレイ上にオブジェクトのかすかなバージョン（そのゴースト）を残す。この特徴は、ユーザによりオン・オフすることができる。ゴーストオブジェクトは、セッションの中へのインデックスとして使うことができる。
【０１２１】
アニメーションモードとバウンシング−ボールモードは、各々特定の時間に生じるイベントの型を示す。バウンシングボールモードにおいては、カーソルはイベントの型を知らせるが、フルアニメーションモードにおいては、アニメーションが、それがどのようにアニメートされたかによりイベントの型を示す。
【０１２２】
再生制御は、再生の間に表示されたオブジェクトとの相互作用により生じる。簡単な例として、ユーザはオブジェクトを選択して、ＬｉｖｅＢｏａｒｄ上で再生コマンドを直接呼び出すことができる（例えば、ＬｉｖｅＢｏａｒｄ上に書かれた時間）。他の再生制御の特徴は、以下に述べられる。
【０１２３】
全てのＬｉｖｅＢｏａｒｄの機能を利用することができるので、ＬｉｖｅＢｏａｒｄウィンドウは、エディタとして動作することができる。そこで、ユーザは、表示されたオブジェクトのそれら自身の操作を行なうことができ、或いは、図面を付加することができる。そのような操作は、それら自身のタイムストリームを発生させることになる。
【０１２４】
ＬｉｖｅＢｏａｒｄウィンドウが、プレーヤと再生制御装置の両方として動作することは重要である。既知のノートテーキングシステムとは反対に、ＬｉｖｅＢｏａｒｄウィンドウは、ノートテーキング媒体の終了状態には厳密には基づかない再生制御手段を提供する。ユーザは、再生の間のあらゆる点でＬｉｖｅＢｏａｒｄと相互に作用することができる。そこで、例えば、ユーザはセッションを再生して、セッションの先方の点にスキップし（例えばクロック上のポイント及びクリック動作により）、言葉がＬｉｖｅＢｏａｒｄから消されたことに気付くことができる。これは、言葉の削除に関連している再生の一部を詳細に検討するためにユーザをトリガーすることができる。
【０１２５】
図１５は、現時点で好適な実施態様のＬｉｖｅＢｏａｒｄウィンドウを説明する。図１５を参照すると、ＬｉｖｅＢｏａｒｄウィンドウ１５０１は、セッションアクセスワークステーション上で実行されＴｉｖｏｌｉアプリケーションのためのユーザインターフェースのインスタンスである。ＬｉｖｅＢｏａｒｄウィンドウは、両側が、オブジェクトエリア１５０３に境を接する制御エリア１５０２から成る。制御エリア１５０２の種々の制御は、ＬｉｖｅＢｏａｒｄウィンドウ１５０１でアクティブである。アクティブで選択可能なオブジェクトは、オブジェクトエリア１５０３に表示されたマーキングである。同様に、再生ツール１５０４が説明される。再生ツール１５０４は、選択されたオブジェクトに関連がある点において、再生を始めるために使われる。
【０１２６】
生成された履歴リストの故に、オブジェクトを選択して最も早い点を聞くためのＬｉｖｅＢｏａｒｄとの相互作用の例が可能である。上述したように、履歴リストは実行されたプリミティブ動作のリストであり、各々のプリミティブ動作はタイムスタンプされ、オブジェクトと関連づけられる。オブジェクトは、典型的には、空間的に定義され、機能として実行された。例えば、点Ｘ１，Ｙ１からＸ２，Ｙ２へ線を引く。そこで、オブジェクトの選択がされるとき、空間的な位置を見て、その位置のオブジェクトを見つけ出し、オブジェクトに関連したプリミティブオブジェクトを見つけ出し、次いで、もっとも顕著なイベントの時間を選ぶことは簡単なことである。一般的な場合には、もっとも顕著なイベントは“生成”イベントである。しかしながら、他の時間がユーザに興味を起こさせるかもしれないので、ユーザがもっとも顕著なイベント（以下に説明される）を選択できる選択動作が提供される。
【０１２７】
ＬｉｖｅＢｏａｒｄタイムストリームは、概して二つの型、すなわち、単調と非単調に分類することができる。単調タイムストリームは、主に“生成”イベントを有する。起こる唯一の事は、新しいオブジェクトが生成される（移動、変更、消去はない）ことである。単調タイムストリームにおいては、圧倒的な大多数のオブジェクトは、それ（その生成イベント）と関連したたった一つのイベントを有する。
【０１２８】
非単調タイムストリームは、生成、変更、移動、及び、削除イベントから成る。このように、各々のオブジェクトは、それに関連した一つ以上のイベントを有することができる。オブジェクトの位置が変化する変化（すなわち、移動）と、そうではない変化を区別することは有用である。もしタイムストリームが、どのような位置変化イベントも有していなければ、各々のオブジェクトはディスプレイの上で唯一の位置を有する。もし移動イベントがあれば、オブジェクトはセッションの間、多数の位置を占めるかもしれない。最後に、もしタイムストリームが削除イベントを有すれば、オブジェクトはセッションの間に、或る時間で消えるかもしれない。
【０１２９】
Ｌｉｖｅｂｏａｒｄウィンドウは、スタンドアローンの、或いは、タイムラインインターフェースと相関した再生制御装置として使用することができる。
タイムラインインターフェースとの相関は、以下に述べられる。
スタンドアローンモードにおいては、単調タイムストリームについて、オブジェクトの選択及び再生ツール（ｐｌａｙｔｏｏｌ）の呼び出しは、オブジェクトについての“生成”イベントの時間における再生を引き起こすことになる（なぜなら、これはオブジェクトと関連している唯一のイベントであるからである）。
【０１３０】
非単調タイムストリームの場合においては、問題は選択されたオブジェクトの再生時間を開始するために、何の“イベント”を使うかである。ユーザが再生ツールでオブジェクトをポイントすると、システムは、オブジェクトと関連したもっとも早いイベントの時期のセッションを再生する。しかしながら、オブジェクトについての他の時間が重要かもしれない。例えば、オブジェクトが移動された時間が重要かもしれない。オブジェクトについて他のイベント時間にアクセスする別の方法がある。例えば、オブジェクトと関連した全てのイベントを表にしたイベントメニューが提供される。ユーザは、単に所望のイベントを選択する、再生はイベントと関連した時間で始まる。
【０１３１】
別の技術は、再生時間を現在のオブジェクトに関連した次のイベントにスキップする次イベント再生ボタンを使うことである。タイムライン相関性を使う更に別の技術が以下に述べられる。
【０１３２】
ＬｉｖｅＢｏａｒｄ上の、また、Ｌｉｖｅｂｏａｒｄウィンドウ内のクロックの観念は、上述された。クロックは、Ｌｉｖｅｂｏａｒｄウィンドウで何時活動が起きたかの時間的な参照を提供するので、セッションの再生の際に有用である。クロックがクロックジェスチャーにより生成されたグラフィックオブジェクトであることを思い出すべきである。クロックは、全てのグラフィックアートオブジェクトと同じやり方で操作して編集することができる。しかし、クロックオブジェクトは特別であり、それは、それ自身の自分の“内部”時間を表現するそのデータ構造に、特別な特性を含む。再生ツールがクロックに触れると、再生点は、クロックの内部時間にセットされ、クロックと関連した幾つかのイベントの時間（例えばその生成時間）へセットされない。従って、クロックはそれ自身の履歴から独立した時間として取り扱うために使用することができる。デフォルトにより、クロックの内部時間は、クロックの生成動作と同じ時間である。しかし、そうである必要はなく、これは種々の有用な機能を導く。
【０１３３】
クロックの内部時間は変えることができる。現時点で好適な実施態様においては、クロック上で編集ジェスチャー（現在、ポイントして保持している）が行われると、ユーザがクロックの内部時間を変えることができるメニューがポップアップする。これらの変化は、相対的（例えば、内部時間をＮ秒だけ前方或いは後方へ移動する）、或いは、絶対的（すなわち、内部時間を特定の時間Ｔに移動する）のいずれかとすることができる。前者は、インデックスを付けるためにクロックの内部時間僅かに調整するときに一層正確であるので、もっとも有用である。
【０１３４】
例えば、ミーティングにおいては、興味ある問題は取り上げられて議論される。ＬｉｖｅＢｏａｒｄのユーザは、クロックを生成して、ノートを書くことにより、この討論にインデックスを付けることができる。しかし、通常、討論が始まってからある程度後に、クロックは生成される。従って、討論の開始に一層正確にインデックスを付けるために、その時間を僅かに逆方向に調整するために、クロックを編集することができる。この編集は、ミーティングの間、或いは、後でアクセスセッションへの間にすることができる。後者は、セッティングが正確かどうかを判別するために、現在のクロックセッティングからミーティングを再生するのに便利であるので、もっとも有用である。現在の実施においては、編集が行われた後に再生を開始させて、ユーザに時間セッティングの妥当性をユーザに即時にフィードバックすることにより、ユーザに利便を計っている。
【０１３５】
ユーザは、ＬｉｖｅＢｏａｒｄウィンドウ（以下、エディタとしてＬｉｖｅＢｏａｒｄウィンドウを参照）経由でクロックを付加することによりアクセスセッションの間に、クロックを生成することができる。しかし、この状況においては、クロックの内部時間は、再生ツールの現在の再生点にセットされるものであり、アクセスセッションにおける（全く有用ではない）その生成時間にではない。例えば、一層早いミーティングをアクセスするユーザを考える。彼は、ミーティングのオーディオを聞き、ミーティングの間にインデックスを付けられなかった重要なアイディアを聞く。そこで、再生のこの点で、彼はクロックを生成し、次いでその隣にノートをタイプする。このクロックは、ミーティングへの新しいインデックスである。従って、オリジナルのミーティングにおける時間を保持するオブジェクトを生成することができるようにすることにより、インデックス付加の質と量を、アクセス時間において強化することができる。
【０１３６】
オブジェクトと関連した全てのイベントを見ることは、しばしば望ましい。
例えば、ユーザは、オブジェクトの変更或いは削除の有無及び時期を知ることを望むかもしれない。上述したように、ＬｉｖｅＢｏａｒｄで選択したオブジェクトに関連した全てのイベントは、タイムラインインターフェースの選択トラックの上に表示される。これは、ＬｉｖｅＢｏａｒｄとタイムラインインターフェースの間の相関性により、ユーザが特定した関連があるセッションの中へのインデックスを表示するための手段を提供する。
【０１３７】
ＬｉｖｅＢｏａｒｄウィンドウとの相互作用による相互関係の他の特徴は、図１６−図２０に関して述べられる以下のシナリオで説明される。ＬｉｖｅＢｏａｒｄウィンドウとタイムラインインターフェースの表現は、単純化されていることに注意すべきである。特に、ＬｉｖｅＢｏａｒｄウィンドウ上の制御エリアと、タイムラインインターフェースの概観時間トラックエリアは、図には示されていない。
【０１３８】
図１６を参照すると、ユーザはＬｉｖｅＢｏａｒｄウィンドウ１６０１で言葉を見て、この言葉が書かれた時の会話の再生することを欲する。ユーザは、適当な選択技術（ここでは、ペン／マウスを使用して言葉を円で囲むジェスチャーにより））を利用して、言葉１６０２の“冗長”を選択する。次いで、タイムラインインターフェース１６０３は、選択された言葉と関連している全てのイベントを示すために、選択トラック上で更新される。ここでは、ビジュアルインジケータ１６０４は、選択トラック１６０５に表示される。ビジュアルインジケータ１６０４は、言葉を書き込むイベントを表現する。この例では、他のイベントは、言葉“冗長”と関連づけられない
【０１３９】
同様に、タイムラインインターフェース１６０３で説明されているのは、再生時間インジケータ１６０６である。そこで、今度は、再生は言葉“冗長”が書かれた“後”の点であることに注意すべきである。
【０１４０】
図１７は、ＬｉｖｅＢｏａｒｄウィンドウとタイムラインインターフェースの間の同期を説明する。ユーザは、タイムラインインターフェース１７０２内の再生時間インジケータ１７０３をビジュアルインジケータ１６０４の直前に移動する。次いで、ＬｉｖｅＢｏａｒｄウィンドウ１７０１は、ちょうどその時にＬｉｖｅＢｏａｒｄの上にあったものを表示するために、更新される。特に、図１６と比較された時、言葉“冗長”はＬｉｖｅＢｏａｒｄウィンドウに現れないことに注意すべきである。
【０１４１】
再生コマンドが呼び出されると、ＬｉｖｅＢｏａｒｄウィンドウとタイムラインインターフェースの両方は、同期して更新される。しばらくして、言葉“冗長”は、ＬｉｖｅＢｏａｒｄに現れる。
【０１４２】
ここで、ユーザは、選択トラックの上のイベントの直前に、タイムラインの上にいくつかのイベントがあったことに気がつく。ユーザは、タイムラインの上のこれらのイベントを表現するビジュアルインジケータを選択し、すぐに、図面の対応している要素はＬｉｖｅＢｏａｒｄウィンドウでハイライトされる。すなわち、図面とタイムラインの相互関係は双方向性である。
【０１４３】
これは、図１８で説明される。ビジュアルインジケータ１８０４は、タイムラインインターフェース１８０３から選択される。ＬｉｖｅＢｏａｒｄウィンドウ１８０１において、言葉“ルーター（ｒｏｕｔｅｒ）”１８０２はハイライトされる（ここでは点線の円で示した）。従って、ビジュアルインジケータ１８０４に対応するイベントは、言葉“ルーター”と関連づけられる。
【０１４４】
次に、ユーザは、Ｌｉｖｅｂｏａｒｄウィンドウの図の上で太いボックスを見る。そして、ボックスを選択する。三つのビジュアルインジケータは、タイムラインインターフェース（または、三つのビジュアルインジケータは、編集トラック上でハイライトすることができる）の選択トラック上に表示される。第１の型のビジュアルインジケータは、ボックスのための生成イベントを示し、第２の型のビジュアルインジケータは、ボックスが太くされた時にライン幅変更イベントを示し、第３の型のビジュアルインジケータは、図面上のボックスの移動のイベントを示す。上記されたように、タイムラインインターフェースの上のビジュアルインジケータは、それらが表現するイベントの種類を示すために視覚的に区別される。ユーザは、ボックスが太い理由に興味があり、時間マーカーをライン幅変更イベントへ移動し、再生ツールを使って再生を呼び出す。
【０１４５】
これは、図１９で説明される。ボックス１９０２は、ＬｉｖｅＢｏａｒｄウィンドウ１９０１でハイライトされる。ビジュアルインジケータ１９０４−１９０６は、タイムラインインターフェース１９０３でハイライトされる。上述したように、これらのビジュアルインジケータの各々は、オブジェクトと関連したイベントの特定の型を表現する。更に、現時点で好適な実施態様においては、各々のビジュアルインジケータは、イベントの型へ対応する或る視覚的な特性、典型的には色を有する。
【０１４６】
ユーザは、どちらから再生を開始するかビジュアルインジケータ１９０４を選択する。
【０１４７】
次に、ユーザは、図面の別のページの上の図を考える。この図は、ミーティングの間に、何度も描かれ、消され、描き直されたものであり、ユーザは、以前のバージョンが正しいと思われなかった理由を聞きたい。ユーザは、図が位置している図面のエリアを選択する。ここで、タイムラインの幾つかのセクションがハイライトされ、削除或いは移動されたオブジェクトを含む、図のそのエリアにあった全てのオブジェクトについてのイベントが明らかになる。ユーザは、時間マーカーを、第１のハイライトされた削除のビジュアルインジケータに移動し、なぜ第１のバージョンが変更されたかの議論を見つける。
【０１４８】
特定の位置でオブジェクトがなる、或いは、なったビジュアルキューは、ゴーストオブジェクトである。ゴーストオブジェクトは、セッションの間の或る時間の点において、オブジェクトがこの特定の位置に存在したことを示すために使用されるオブジェクトのかすかな輪郭である。ユーザは、種々のオブジェクトゴーストに気がつくことができ、そこに何が有ったのか、或いは、有ることになるのかを知ることを欲する（例えば、セッションの終わりにおいて項目が消されたことがゴーストオブジェクトにより明らかになる項目のリスト）。
【０１４９】
これは、図２０で説明される。図２０を参照すると、ユーザは、ＬｉｖｅＢｏａｒｄウィンドウ２００１の図のエリア２００２を選択した。簡単に図１６を参照すると、エリア２００１は、言葉のリスト、“付加”、“ルーター”、及び、“冗長”を含むエリアに対応する。タイムラインインターフェース２００３は、ここでハイライトされた多数のビジュアルインジケータ２００４−２００６を有する。これらは、エリア２００２と関連したイベントに対応するイベント、すなわち、言葉“付加”、“ルーター”、及び、“冗長”に関連するイベントに関係する。これは、単に空間的な相関であること、すなわち、リストから消された言葉を表現するイベントも同様にハイライトされたことに注意すべきである。更に、図２０に説明されているのは、“ゴースト”オブジェクト２００７である。再生のこの点で、“ゴースト”オブジェクト２００７により示された位置のオブジェクトは２００７は消された。
【０１５０】
上述したように、エディタは、ユーザが事実の後にタイムストリームとイベントデータを付加することを許す。ＬｉｖｅＢｏａｒｄウィンドウがエディタとしていつ使われるか、何が編集されるかは、ＬｉｖｅＢｏａｒｄ（または、付加された新しいマーキング）の上のマーキングである。この場合には、ＬｉｖｅＢｏａｒｄタイムストリームへの付加及び／又は削除は、そのような編集の結果として行われる。また、別のタイムストリームを生成することもできる。
【０１５１】
エディタとして使われるとき、ＬｉｖｅＢｏａｒｄウィンドウは、非参加者が記録されたセッションを効率的に検討することができる非常に有効な手段を提供する。これは、部分的には、ＬｉｖｅＢｏａｒｄの全ての基本的な能力がセッションの再生の間利用することができるからである。これは、編集セッションの前後の両方のセッションの終わりにおけるＬｉｖｅＢｏａｒｄウィンドウを示す図２１と図２２に関して、もっともよく述べられる。この例のＬｉｖｅＢｏａｒｄは、バウンシングボール再生モードで動作している。
【０１５２】
図２１を参照すると、種々の手書きのマーキングがＬｉｖｅＢｏａｒｄウィンドウ２１０１に現れている。上述したように、各々のこれらの手書きのマーキングは、セッションの中へインデックスを付けるために使うことができる。しかしながら、或るミーティングの間、マーキングのいくつかは無関係（例えば、マーク２１０２）であったり、判読し難い（例えば、マーク２１０３）場合がある。更に、議論された重要な点があるがＬｉｖｅＢｏａｒｄに対してはなにも成されていないような場合もある。
【０１５３】
図２２は、だれかが編集した後の、図２１のＬｉｖｅＢｏａｒｄウィンドウを説明する。図２２を参照すると、編集されたＬｉｖｅＢｏａｒｄウィンドウ２２０１は、エディタにより成された注記に適応させるために拡張された。編集されたＬｉｖｅＢｏａｒｄウィンドウ２２０１はクロックを使用してテキストを挿入し、一層多くのインデックスと情報を提供する。図２２において、何がその点で議論されているかを表すために、テキストは各々のクロックと関連づけられた。そこで、例えば、テキスト２２０３は、マーク２１０３が何を意味するかを表すために使うことができる。クロック／テキスト２２０２は、マーキングの収集が何を表すか、そして、何時マーキングの生成が始まったかを表す。明らかに、編集されたＬｉｖｅＢｏａｒｄウィンドウは、次の視聴者が再生制御装置としてＬｉｖｅＢｏａｒｄウィンドウを一層効果的に使うことを可能にする。
【０１５４】
エディタとして、ＬｉｖｅＢｏａｒｄウィンドウの上に存在するマーキングを変えることができる。これは、例えば、ウィンドウの次の視聴者の注意がそらされないように、無関係なマーキング、例えば、図２１のマーキング２１０２を消すために行うことができる。
【０１５５】
タイムストリームアーキテクチャの別の局面は、獲得されたタイムストリームに対する制御である。ユーザは、獲得されたタイムストリーム、特に、オーディオとビデオのように“文字通り”の記録であるタイムストリームに非常に関心がある。彼らは、彼らの活動及び会話の文字通りの記録に誰がアクセスしたかに関心がある。彼らは、彼らが何時記録されたを知ることに関心があり、彼らはこれに対する制御を望む。他方では、興味はあるが記録されなかった議論の後で、ユーザはし彼らがそれを記録していたらとばしば望む。
【０１５６】
ユーザ制御は、タイムストリームアーキテクチャでサポートされる。しかしながら、実施は、セッションのキャプチャの間とその後の両方で、ユーザに制御を効果的に与えるためのユーザインターフェースツールを必要とする。
【０１５７】
タイムストリームアーキテクチャは、“制御イベント”の特別な取扱いの提供する。制御イベントは、以下のものを指定する
−時間スパン（時間と期間を開始させる）
−制御すべきタイムストリーム
−制御の種類（保護のパージレベル）
−制御が有効になるとき
【０１５８】
獲得されたセッションが多数のタイムストリームを有することができるとすると、制御イベントはそれらを選択的に制御することができる。例えば、議論の微妙なスパンの間のオーディオだけを制御することが有用である。制御イベントは、セッションの全てのタイムストリームを特定することもできる。
【０１５９】
いくつかの種類の制御がある。
記録された資料を、データベースから物理的にパージすることができる。記録された資料を聞くか見ることへのアクセスは、拒否したり、特定のユーザ或いはユーザのグループに与えることができる。アクセスは、読むことのみが可能なアクセス、新しい資料をアペンドすることが可能なアクセス、資料を完全に編集することが可能なアクセス、或いは、アクセス制御を変更することが可能なアクセスのような、異なった型とすることができる。
例えば、制御イベントは、ミーティングの議長だけがミーティング記録を編集することができ、グループのマネージャーだけがアクセス制御を変えることができ、ミーティングの参加者だけが新しい資料を獲得された資料にアペンドすることができ、特定の組の他の個人のみが獲得されたオーディオを聞くことができきるように特定することができる。
【０１６０】
最後に、制御のタイミングを指定することができる。これは、パージするためにもっとも有用である。獲得された記録は、明細を記すと直ちに（例えば、総員の議論を消すために）、セッションの直後に（例えば、興味をそそらないミーティングを消すために）、或いは、何日か何ヵ月後に（例えば、文書整理と保管管理のために）のように、異なった時間にパージすることができる。しかし、非参加者に対してはミーティング記録へのアクセスを１週間拒否して、議長に記録を編集するという時間を与えるように指定することもできる。
【０１６１】
タイムストリームアーキテクチャは、制御イベントが種々の制御を指定するのを可能にするが、アーキテクチャはそれらを直接には実施せず、アーキテクチャの種々の構成要素への制御を代表する。指定の多くは、それらを実施するために、データベースでコード化することができる。タイムストリームプレーヤとタイムラインインターフェースも、同様に或るアクセス制御を実施する補助となる。パージすることは、レコーダにより、または、特定のタイムストリームのデータフォーマットを理解しているなんらかのプロセスにより通常実施されなければならない。パージするプロセスは、パージすべきデータを重ね書きするか（“ゼロで埋める”）、或いは、実際に再度書き込んでパージすべきデータを外部に出したままにしておくことにより記録を圧縮するかのいずれかとすることができる。タイムストリームアーキテクチャは、それ自身は制御イベントの完全な実施を保証しないが、与えられた状況の中で利用可能な構成要素により行うことができる最善のことを行う。
【０１６２】
時間に基づいた方法でアクセス制御を提供することは、一般に非常に微妙であることが判っている。例えば、微妙な決定を取り扱っているので、或る１０分のスパンの議論のオーディオ／ビデオ記録をパージすることを考え、また、ビデオ記録が壁のホワイトボードを示していると考える。たとえ、１０分のスパンがビデオからパージされるとしても、そのスパンの後に、その討論の残部がホワイトボードの上に残らないという保証はない。しかしながら、実際的な問題として、時間に基づいた制御は、殆どの時間で有用である。
【０１６３】
制御イベントは、ユーザがそれらを容易に生成して編集することができる場合にのみ有用である。ユーザにとっては、セッションの後にタイムラインインターフェースで制御イベントを指定することが自然である。
【０１６４】
現時点で好適な実施態様においては、ユーザにセッションの間のオーディオの記録に対する控え目の制御を与えるために、ユーザインターフェースツールの簡単なセットが提供される。ユーザに何時記録が開始されたかを気付かせることは重要である。ビデオカメラの上の赤い光がこれを行う。Ｌｉｖｅｂｏａｒｄについては、記録が行われている間に、点滅する“記録中”が表示される。両方とも物理的な装置の上のハードボタンであるポーズボタン及び記録ボタンと、ＬｉｖｅＢｏａｒｄ或いはコンピュータディスプレイの上のソフトボタンにより、ユーザがレコーダをオン・オフすることができる。しかし、この制御は予期されなければならない。すなわち、ユーザは、記録またポーズのいずれとするために、興味があるか微妙であるかのいずかであるかを前もって知っていなければならない。実際には、これは有効ではない。すなわち、それらが始まってから十分あとになるまでは、ユーザはこれらの状況をしばしば認識できない。従って、ポストホック（ｐｏｓｔ−ｈｏｃ）制御が必要とされる。
【０１６５】
我々のユーザインターフェースは、“記録オン”と“記録オフ”（ポーズと記録に加えて）の概念を実施することにより、これを提供するものであり、これは、セッション中に適当な方法により、ユーザが事実の後の記録を制御することを可能にするものである。このアイディアは、全体のセッションが実際に記録されることであり、ユーザは、セッションの部分に記録オンである或いは記録オフであるかをマークすることができ、セッションの後で記録の記録オフの部分はパージされる。
【０１６６】
セッションが記録するために開始させられると、点滅する“記録オン”注意が、記録オフボタンと一緒に表示される。記録オフボタンが押されると、ユーザは、現時点で或いはＮ分前の時点で、セッションに記録がオフであることをマークすることができる。例えば、もし議論が微妙な話題に移って、討議者が数分後にノートに書き込むと、彼らは、記録オフとなる最後の、例えば、５分間にセットすることができる。同様に、セッションが記録されていないときには、点滅する“記録オフ”が、記録オンボタンと一緒に表示され、これにより、ユーザがセッションに記録がオンであることをマークすることができる。例えば、討論が面白くなったときに、記録の上に最後の１０分を元へ戻すことができる。これらの制御は、ユーザが全体のセッションを記録すべきか否かを決定することができるセッションの終わりへ固執する。
【０１６７】
これらのユーザインターフェースツールが行うことは、セッションの間に制御イベントを生成させることである（記録オフセグメントはパージされたとしてマークされ、記録オンセグメントはアクセスを許可するとしてマークされる。）。セッションが閉会した後、プロセスは、矛盾する指定（すなわち、セッションのスパンが記録オンとオフの両方にマークされている）について作りだされた制御イベントを分析するプロセスが実行され、次いで、記録をパージするためにレコーダがコールされる。対立解決のための一つの技術は、一層最近の制御イベントに優先権を与えることである。しかしながら、ユーザは、タイムラインインターフェース経由で制御イベントを見て、パージをコールする前にそれらを編集するように頼むことができる。
【０１６８】
このユーザインターフェースの一つの困難な点は、記録を変えるために何分戻るのかを知ることがユーザにとって困難であることである。これに対する一つの改良は、ユーザに一層意味がある時間点を与える我々のオーディオ分析ツールを使うことだろう。例えば、記録オフボタンを押した後に、最近のオーディオのポーズに対するバックアップ点或いは話者の変化のメニューを現すことができる。ユーザは、正しい時間点を決定するために、これらから再生することができた。
【図面の簡単な説明】
【図１】 本発明の現時点での好適な実施態様における時間的データの捕獲及び再生のためのシステムのブロック図である。
【図２】 本発明の現時点での好適な実施態様において利用することができるセッションアクセスワークステーションのブロック図である。
【図３】 本発明の現時点での好適な実施態様のセッションアクセスワークステーションの動作の単純化された疑似状態である。
【図４】 本発明の現時点での好適な実施態様のセッションアクセスワークステーションに連結されるディスプレイのビジュアルユーザインターフェースの図である。
【図５】 本発明の現時点での好適な実施態様のセッションのためのタイムラインユーザインターフェースディスプレイの図である。
【図６】 概観時間トラックディスプレイエリアと焦点時間トラックディスプレイエリアの関係をハイライトするタイムラインインターフェースの単純化された図である。
【図７】 図６の焦点バーが引き伸ばされこれに従って焦点時間トラックディスプレイエリアの寸法が変えられている動作の結果を示す図である。
【図８】 二つのセッションの再生を制御するためのタイムラインユーザインターフェースディスプレイシステムの図である。
【図９】 二つの不連続な焦点セグメントが概観時間トラックエリアに表示され、焦点時間トラックエリアが各々の焦点セグメントの詳細を含むタイムラインインターフェースの図である。
【図１０】 図９の焦点時間トラックエリアのサイズ修正の結果を示すタイムラインインターフェースの図である。
【図１１】 ＬｉｖｅＢｏａｒｄウィンドウの選択動作の結果として生じたトラックセクションを含む複数のキャプチャ装置で記録したセッションの再生のためのタイムラインインターフェースの例である。
【図１２】 一つのトラックの上で図１１のオーディオのトラックを併合した結果を示すタイムラインユーザインターフェースディスプレイの更なる図である。
【図１３】 ノートトラックの上にノートを開けた結果を示す図１１のタイムラインユーザインターフェースディスプレイの更なる図である。
【図１４】 図１１のタイムラインユーザインターフェースを生成するのに使用した同じセッションについてのミーティングプレーヤの図である。
【図１５】 本発明の現時点での好適な実施態様におけるＬｉｖｅＢｏａｒｄウィンドウの図である。
【図１６】 ＬｉｖｅＢｏａｒｄウィンドウとタイムラインインターフェースの間の相関性の図である。すなわち、グラフィックオブジェクトからタイムラインへのインデックス付けである。
【図１７】 Ｌｉｖｅｂｏａｒｄウィンドウとタイムラインインターフェースの間の相関性の図である。すなわち、ＬｉｖｅＢｏａｒｄウィンドウとタイムラインインターフェースの両方が同時に同じものを反映する同期化されたディスプレイ状態である。
【図１８】 Ｌｉｖｅｂｏａｒｄウィンドウとタイムラインインターフェースの間の相関性の図である。すなわち、時間的なものから空間のへのインデックス付けである。
【図１９】 ＬｉｖｅＢｏａｒｄウィンドウとタイムラインインターフェースの間の相関性の図である。すなわち、グラフィックオブジェクトにつき多数のイベントである。
【図２０】 ＬｉｖｅＢｏａｒｄウィンドウとタイムラインインターフェースの間の相関性の図表である。すなわち、オブジェクトエリアの位置選定によってインデックスを付ける。
【図２１】 ＬｉｖｅＢｏａｒｄウィンドウが編集された前の“バウンシング−ボール”再生モードにおけるＬｉｖｅＢｏａｒｄウィンドウの例を提供する。
【図２２】 ＬｉｖｅＢｏａｒｄウィンドウが編集された後の“バウンシング−ボール”再生モードにおけるＬｉｖｅＢｏａｒｄウィンドウの例を提供する。
【符号の説明】
１０１ キャプチャセッション始動モジュール、１０２ａ キャプチャ装置、１０２ｂ キャプチャ装置、１０２ｃ キャプチャ装置、１０３ セッション蓄積装置、１０４ 時間的データ分析器、１０５ セッションアクセスワークステーション、１０６ プレーヤ、１０７ 再生制御装置、１０８ エディタ、１０７ タイムストリーム／イベント、１０８ タイムストリーム／イベント、１０９ タイムストリーム／イベント、１１０ イベント、１１１ 時間的データ

Claims (1)

1. 複数のメディアキャプチャ装置で獲得されたセッションの再生を制御するためのコンピュータ制御型ディスプレイシステムであって、前記複数のメディアキャプチャ装置の少なくとも一つが共有表現メディアであり、前記共有表現メディアはグラフィックオブジェクトを生成して表示し、その表示されたグラフィックオブジェクトは獲得セッションの参加者に共有されたものであり、前記コンピュータ制御型ディスプレイシステムは前記セッションを再生するために一つ或いはそれ以上のプレーヤに連結されており、前記コンピュータ制御型ディスプレイシステムが、
   ディスプレイと、
   前記獲得されたセッションの時間的データを受け取るためのセッション入力手段であって、前記時間的データがタイムストリームとイベントから成るものと、
   ユーザーが前記コンピュータ制御型ディスプレイシステムと相互に作用できるようにするためのユーザ入力手段と、
   前記一つ或いはそれ以上のプレーヤによって前記セッションの再生を同期させるための同期手段と、
   前記共有表現メディアで実行されたタイムストリーム表現動作からディスプレイ情報を発生させるための処理回路であって、前記ディスプレイ情報は前記ディスプレイのウィンドウに表示するためのものであり、前記ウィンドウは前記共有表現メディアで実行された動作の時間的な順序を再生するためのプレーヤとして動作し、前記再生が一つ或いはそれ以上のグラフィックオブジェクトを前記ウィンドウに表示させるものであり、前記ウィンドウは更に前記セッションの再生を制御するためのユーザインターフェースとして動作するものと、
   前記ウィンドウの一つ或いはそれ以上のグラフィックオブジェクトへのユーザの相互作用を検出し前記同期手段への再生制御信号を発生させるウィンドウ制御回路であって、前記再生制御信号が前記ユーザの相互作用に対応しているものとを含み、
   前記共有表現メディア上で実行される前記動作の１つが、後にゴーストグラフィカルオブジェクトとして表されるグラフィカルオブジェクトを消去するための消去動作であるコンピュータ制御型ディスプレイシステム。

Images