JP2795857B2

JP2795857B2 - ハイパーメディアシステムにおける埋め込まれたリファレンスを管理及び編集するためのサーバに基づいた設備

Info

Publication number: JP2795857B2
Application number: JP63278499A
Authority: JP
Inventors: ダニエル・シー・スイネハート; ダグラス・ビー・テリー
Original assignee: Xerox Corp
Current assignee: Xerox Corp
Priority date: 1987-11-06
Filing date: 1988-11-01
Publication date: 1998-09-10
Anticipated expiration: 2013-09-10
Also published as: EP0315425A2; EP0315425A3; JPH01156842A

Description

【発明の詳細な説明】〔発明の分野〕本発明は、分散型ディジタルコンピュータシステム
（異なった動作環境を有するシステムを含む）に関し、
特に、（１）そのようなシステムのユーザがたとえば、
ディジタル音声及び音楽のファイル、「走査により読み
込まれた」画像ファイル及びアニメーション或いはフル
モーションビデオファイルのようなデータが集中したフ
ァイルを仮想的に無制限に生成し、操作し、共有し、作
り出すことを可能にするが、（２）そのようなファイル
の多数コピーを作成したり、蓄積したり、取り扱ったり
する必要をなくすための方法及び装置に関する。

〔発明の背景〕

音声，ビデオ或いは場合によっては音楽メディアは、
人と人との間の通信の場合にしばしば有効且つ効果的な
ものであるけれども、典型的な分散型コンピュータシス
テムにおいては、ユーザは英数字や簡単なグラフィック
通信（これらを総合して「テキストによる通信と呼ぶ」
に制限されていた。また、テキストによる通信に代え
て、或いは、それを補足するものとして非テキスト通信
をサポートするためには、そのようなシステムを充分に
拡張する必要が認識されている。たとえば、音声により
注釈するマルチメディアシステムの開発と同様に、音声
メッセージシステムの開発に大変な労力と費用が費やさ
れてきた。音声は、分散型コンピュータシステムに使用
するために最も広く調査されてきた非テキスト通信メデ
ィアであるので、本発明は一つの代表例を提供するよう
に説明がなされている。しかしながら、本発明の総括的
な観点は、また、分散型計算システムにおける他のデー
タが集中した非テキスト通信にも適用できることは理解
されるであろう。

いくつかの興味ある非常に重要な利点は、分散型計算
環境のデータとして、音声やその他の非テキストメディ
アを処理することから生じる。ニコルソン（Nicholso
n）による「オフィス環境における音声の統合（Integra
ting Voice in the Office World）」バイト（Byte），
第８巻,No.12,1983年12月，第177〜184ページを参照の
こと。それは、非テキストメディアを、電子メイルメッ
セージへ、また、通常のテキストファイルに適用された
注釈（annotation）へと容易に組み込むことができ、ま
た、計算環境のユーザインターフェースにより提供され
るプロンプトやその他の対話（interactive）メッセー
ジに組み込むことができる。端的に言って、そのような
処理により、ユーザは、通常のテキストファイルを取り
扱うのと全く同じ方法でこれらの非テキストデータファ
イルを生成し、操作し、共有することができ、また、プ
ログラマは、テキストファイルを含む機能を実施するの
と略同じ方法で、そのような非テキストデータファイル
を含む機能を実施することができる。

しかしながら、音声やその他の非テキストデータファ
イルは、通常のテキストデータファイルとは大変異なっ
ている。たとえば、標準のワークステーションは、アナ
ログの形態では音声データファイルを記録したり、再生
したりすることはできないので、その目的のためには、
特殊な装置が必要である。よりはっきり言えば、音声デ
ータファイルは、典型的なものでは、同じワード数を含
むテキストファイルよりずっと大きくなる。実際、標準
の電話品質の非圧縮音声の記録は、概略で毎秒64Kビッ
トで蓄積を消費し、これは、等価なタイプされたテキス
トのパッセージに必要とされる蓄積容量より数倍大き
い。考慮すべきもうひとつの要素は、音声を転送する際
の厳しいリアルタイム要求である。なぜなら、音声を再
生する際の意図しない語の休止や途切れが知覚問題を生
じさせ、これは、通信のための努力を妨害したり、更に
は無効にすることがある。

ユーザが、共有されたファイルサービスに存在する非
テキストメディアオブジェトに対して埋め込まれたリフ
ァレンスを含む文書を共有し、これらのオブジェトに対
して「ガベジコレクション」を行なうために、リファレ
ンスを含む文書又は文書ホルダがもはや必要でなくなっ
たとき、それに割り当てられていた蓄積空間を取り戻す
ことが可能となるようなシステムがある。トーマス（Th
omas）らによる「ダイヤモンド：分散型アーキテクチャ
に構築されたマルチメディアメッセージシステム（Diam
ond:A Multimedia Message System Built on a Distrib
uted Architecture）」，コンピュータ，第18巻,No.12,
1985年，第65〜78ページを参照のこと。テキスト的に埋
め込まれたリファレンスを使用して、音声，ビデオ及び
その他の種々の型の非テキストデータを参照するダイヤ
モンドシステムのようなシステムは、「ハイパーメディ
アシステム」と呼ばれることがある。ヤンケロビッチ
（Yankelovich）らによる「エレクトロニックブックの
読み出し及び書き込み（Reading and Writing the Elct
ronic Book）」，コンピュータ，第18巻,No.10,1985年1
0月，第15〜50ページを参照のこと。これまで提案され
てきたその他のシステムの殆どの場合とは異なり、ダイ
ヤモンドシステムが使用している埋め込みリファレンス
は、関連する各文書ファイル中の非テキストデータファ
イル（すなわち音声ファイル）のコピーを包含する必要
がない。

まだ、少なくとも二つの問題が解決されなければなら
ない。大部分の非常に大きなサイズの非テキストのデー
タファイル（たとえば、音声データファイル）を考える
と、ファイルを移動したり、コピーしたり、（ファイル
が符号化された形態で保管されていれば）符号化したり
する必要なしに、これらのファイルを簡単なデータベー
スを使用することによって編集し、その編集操作の結果
を説明するための技術が開発されることは重要なことで
ある。また、簡単なデータベースを使用して、不要にな
った非テキストデータファイルに割り当てられている蓄
積空間を自動的に取り戻すためのガベジコレクタをサポ
ートする改良された技術が必要である。そこで本出願
は、ガベジコレクション問題に関する。

〔発明の概要〕

本発明によれば、独特の名称が付けられらピーステー
ブル形式の持続性のあるデータ構造に対する埋め込まれ
たリファレンスが使用され、ディジタル音声，音楽，走
査された画像或いはビデオファイルのような、共有され
た非テキストメディアファイルに対する制御されたアク
セスを、そのようなファイルを複写したり移動したりす
る必要なにし、分散型計算環境にあるワークステーショ
ンのユーザに与える。独特の識別を備えた新しいピース
テーブルは、新しい非テキストメディアファイルが記録
される度に、そのようなファイルを名称及び長さにより
識別するために、リファレンスデータベースに入力され
る。ユーザは、かれらのワークステーションを使用し、
現存するピーステーブルを編集し、生成し、一つ以上の
現存する非テキストメディアファイルの、一つ以上の指
定インターバルを参照するリファレンスデータベースの
付加的なピーステーブルに入力する。このとき、これら
のいずれのファイルのいずれの部分のどのような複写も
必要としない。これらのピーステーブルに対する名称リ
ファレンスは、通常のテキストファイル及びメッセージ
に埋め込まれ、下にある非テキストメディアファイルに
対するアクセスをユーザに与える。

本発明の更に他の特徴及び利点は、添付図面に関連し
て説明された以下の詳細な説明から明らかになるであろ
う。

〔好ましい実施態様の詳細な説明〕

以下、本発明を一つの図示の実施態様に関連しながら
或る程度詳細に説明するけれども、本発明をこの実施態
様に限定しようとするものではないことを理解すべきで
ある。反対に、本発明は、請求項に規定されているよう
に、本発明の精神と範囲に含まれる全ての変形例，修正
例及び等価例を包含するものである。

ここで、図面に移れば、特に第１図を参照すれば、分
散型コンピュータシステム21（関係ある部分のみを示し
ている）は、ローカルエリアネットワーク（「LAN」）2
2を有し、このローカルエリアネットワークは、他のLAN
（図示せず）に直接、或いは、スイッチ式通信設備を介
してインターフェースされるゲートウェイ23を備えてい
る。通常の構成のCSMA/CD（すなわち、イーサネット（E
thernet））ネットワークを維持する際、LAN22は複数の
ワークステーション24a,24bをリンクするための線型ト
ポロジーを有するが、そのLAN22或いはこれにインター
フェースされる他のLANは、たとえば、環状トポロジー
のような異なったトポロジーを有することができること
は明らかである。市販されているワークステーションや
LANの種々の特性を備えた更に他の異なった環境の例は
明らかであるので、ゲートウェイ23が、或る通信プロト
コルにしたがって動作するLANから、異なった通信プロ
トコルにしたがって動作する他のLANへデータを転送す
るために必要とされるリフォーマット機能及びリタイミ
ング機能を行うことは理解されるべきである。システム
21を拡張してより多くのLAN（図示せず）を包含させた
い場合には、ゲートウェイをより多く備えることができ
る。

ワークステーション24a,24bを介して交換できるよう
な通常のテキストメッセージ及びデータファイルの他
に、或いは、それらの代わりに、LAN22を介して音声メ
ッセージをユーザが送信し受信することができるよう
に、マイクロプロセッサを使用したディジタル電話装置
31a,31bを備えている。これらはワークステーション24
a,24bの近くに配置されるが、それぞれ物理的にはそれ
には接続されていない。これらの電話装置は、これらが
接続されるLANの通信プロトコルを満足させるために必
要とされるディジタルデータフォーマットへ音声を変換
する。たとえば、電話装置31a,31bは、イーサネット形
式のLAN22へ直接送信するために、電話品質の音声をデ
ィジタル化し、パケット化し、符号化する。その達成方
法の詳細な説明についてはスイネハート（Swinehart）
らによる「オフィスコンピュータネットワークへの音声
の付加（Adding Voice to an Office Computer Networ
k）」,IEEEグローブコム'83会報（Proceedings IEEE Gl
obeCom'83））,1983年11月及び、スイネハート（Swineh
art）らによる「音声システム開発のための実験環境（A
n Experimental Environment for Voice System Develo
pment）,IEEEオフィスナレッジエンジニアリングニュー
ズレター（IEEE Office Knowledge Engineering Newsle
tter）,1987年２月を参照のこと。これらの参考文献の
両方とも、引用文献としてここに組み込まれる。前に指
摘したように、電話装置31a,31bは、ワークステーショ
ン24a,24bには直接取り付けられてはおらず、異なった
環境にある場合のような、種々のワークステーションと
ともに使用される電話装置と同様である。

本発明によれば、システム21は音声マネージャ34を有
し、この音声マネージャ34は、LAN22とインターフェー
スされ、適度な高忠実度で記録された音声，電話会話，
音楽及びその他の音のための蓄積装置を提供する。所望
であれば、音声マネージャ34内で、一つ以上の電話装置
31a,31bを介して再生するため、文字ストリングを受け
取り、等価な音声データファイルを戻す、たとえば、テ
キストから音声への変換器（図示せず）のような、その
他の特殊な音のソース或いはシンクを使用することがで
きる。

音声制御サーバ35は、通常のビジネス電話システムの
機能と同様な制御機能を果たし、システム21の他の構成
要素が音声に関して動作するとき、その構成要素間の相
互作用を管理する。この普通の電話システムの機能にし
たがって、音声制御サーバ35は、ユーザの電話装置31a,
31b,LAN22及び適切であればゲートウェイ23を介して、
二人以上のユーザ間で、また、同様に、どのユーザと音
声ファイルサーバ36との間でも迅速に達成されるべき音
声による会話を可能とする。更に、そのような会話が行
われるとき、制御サーバ35は、ユーザの電話装置及びワ
ークステーションを含むその会話に参加しているもの全
てに、また、その会話を記録するために音声ファイルサ
ーバ36が動作可能とされている場合には、音声ファイル
サーバ36にも、通信路識別子すなわちConversationIDを
分配する。以下に判るように、このConversationIDは、
音声制御サーバ35から発行される要求や報告の中の会
話、或いは、その会話が終結した後に続く参加者を識別
するために使用される。

音声による通信のために必要な制御の全ては、リモー
トプロシージャコール（RPC），プロトコル望ましくは
確実なプロトコルを介して行われる。たとえば、ビレル
（Birrel）らによる「リモートプロシージャコールの実
施（Implementing Remote Procedure Calls）」，コン
ピュータシステムに関するACMトランザクション（ACM T
ransactions on Computer Systems），第２巻,No.1,198
4年２月，第39〜59ページ、及び、ビレル（Birrel）ら
による「リモートプロシージャコールを使用した確実な
通信（Secure Communications Using Remote Procedure
Calls）」，コンピュータシステムに関するACMトラン
ザクション，第３巻,No.1,1985年２月，第１〜14ページ
を参照のこと。RPCプロトコルを複数実施することは、
たとえば、プログラムを実行し、異なったプログラミン
グ環境を使用してプログラムされた音声アプリケーショ
ンを実行する場合でさえ、音声動作のためのワークステ
ーション24a,24bの統合を可能にする。以下判るよう
に、会話の途中で受信されたRPCのプロトコルに応答し
て音声制御サーバ35により発行される報告は、その会話
をサポートする関係あるシステム活動について、参加者
に情報を与え続ける。

会話に実際に参加している参加者は、適切な音声送信
プロトコルを使用して音声を交換する。再度、前記のス
イネハートらによる文献「オフィスコンピュータネット
ワークへの音声の付加」を参照のこと。各会話中、全て
の送信された音声は、望ましくは、音声制御サーバ35に
より発行されるランダムに生成された符号化キーに基づ
くDES電子コードブック（ECB）符号化のような確実な符
号化を使用してエンコードされる。たとえば、米国規格
局，「データ符号化規格（Data Encryption Standar
d」，連邦情報処理規格（FIP），米国商務省，出版番号
46,1977年１月を参照のこと。このキーは、会話の参加
者が発行するRPCのプロトコルに応答して、その会話の
参加者に分配され、それによって、電話装置31a,31bが
会話を復号化することができる。

本発明の最も重要な特徴の一つによれば、ワークステ
ーション24a,24bは、ユーザに、システム21の音声能力
に関して強化された制御を与える。第２図は、ユーザが
二つのウィンドウ42,43を開いたときに現れるワークス
テーション24aのような典型的なワークステーションの
スクリーン41を示し、片方は、符号42のところで示すよ
うに、音声パッセージに関するリファレンスが注釈され
るテキストを見るためのものであり、他方は、符号43の
ところで示すように、所定の音声パッセージのグラフィ
ック表示を見るためのものである。これらの音声リファ
レンスは、典型的には、符号44のところで示すように、
注釈された文書のテキスト中に埋め込まれた風船状アイ
コンによって示されるので、それらのアイコンの選択さ
れた任意の一つは、それを再生及び／又は編集しなが
ら、符号43のところで示すように、グラフィック表示を
見るために「開かれる」。望ましくは、音声のグラフィ
ック表示は、音声と無音に比例した長さの間隔を示すた
めに、交互に生じる暗バーと明バーの線型ストリングを
使用する。音声のエネルギレベルが予め決められた閾値
レベル以下に低下するとき、無音は閾値動作により検出
されるので、そのような期間は、ここでは、その相対的
意味で使用されることが理解されるであろう。

ユーザが、ワークステーション24a,24bを使用して実
行することができる音声及びその他の音の編集機能を説
明する前置きとして、ユーザが求めることができる基本
的な「記録（RECORD）」，「再生（PLAY）」及び「停止
（STOP）」機能を簡単に見直しておくことは有用であろ
う。ユーザが「記録」命令を発行するとき、音声制御サ
ーバ35は、ユーザの電話装置を音声ファイルサーバ36に
接続させるための通信路を規定するConversationIDを発
行する。音声マネージャ34は、新しい音声ファイルVFを
記録するために、蓄積空間を音声ファイルサーバ36に分
配するとともに、独特の名称、すなわち、VoiceRopeID
をそのようなファイルに割り当てることによってConver
sationIDに応答する。その後、ユーザが「停止」命令を
発行するまで記録が続く。更に、記録が行われている
間、音声マネージャ34は計数を累積して、単位当たり1/
8000秒のような適切な時間単位で音声ロープ（rope）VR
の長さを決定する。「停止」命令に応答して、所定のCo
nversationIDにより識別されるセッションのための、次
に進むすなわち行列待ちの全ての記録或いは再生動作
は、直ちに停止する。「再生」命令は「記録」命令と同
様であるが、ユーザが、VoiceRopeID、及び、音声ロー
プ全体を規定する特定のインターバル或いは適切な分解
能（この場合、約0.1msの分解能）で特定のインターバ
ルを発行することによって起動される点が異なる。

音声制御サーバ35は、ConversationIDを発行すること
によって「再生」命令に応答し、音声ファイルサーバ36
からユーザの電話装置への通信路を設定し、音声マネー
ジャ34は、音声ファイルサーバ36に、ユーザ指定のVR
（ID,interval）によって決定されるような選択されたV
Fの選択されたインターバルをユーザへ送信させる。

典型的には、「記録」及び「再生」動作は、音声ファ
イルサーバ36により行列待ちが行われた後に戻るリモー
トプロシージャコールに対して非同期的に実行される。
行列待ち動作は、一般に、順を追って実行されるので、
それによって、音声マネージャ34は、報告を生成するた
めの素直なプロシージャを利用して、ユーザが彼らの要
求状態に遅れないようにできるようになる。たとえば、
音声マネージャ34は、各行列待ち動作が開始されそして
完了したときに、適切にRequestIDを戻し、それによっ
て、そのような動作に係わった各ユーザにコールを行わ
せることができ、そのコールは、典型的には次のように
表される。

REPORT［RequestID,｛started/finished/flushed｝］記録された音声ファイルVF又はその一部分及びその組
み合わせを識別する音声ロープVRは不変であるが、ワー
クステーション24a,24bの通常の編集機能を適用するこ
とによって、新しい不変のVRを作り出すために、ユーザ
がそれを使用することができる。編集を補助するために
DESCRIBE（VoiceRopeID）動作により、音声マネージャ3
4が、指定VRの非無音トークスパート（talk−spurts）
（ここで使用されているように、「トークスパート」
は、所定の最短無音インターバルにより境界が付けられ
た一連の音声サンプルである）を表示したタイムインタ
ーバルのリストを、要求者のワークステーションへ戻す
ようにさせる。このトークスパートリストは順次使用さ
れ、第２図のウィンドウ43に示すように、トークスパー
トとその間に介在する選択されたVRの無音インターバル
のグラフィック表示を生成する。望ましくは、所定の音
声ロープのためのトークスパートリストを組み立てるの
に伴って生じる過負荷を軽減するために、音声ファイル
サーバ36に記録された全ての音声ファイルVFに関連した
トークスパートのルックアップテーブルが維持される。

音声ロープ編集編集に直接適用することができる一般
のテキスト編集動作は、以下の通りである。

−CONCATENATE［VoiceRopeID₁,VoiceRopeID₂,...］−新
しい音声IDを戻し、現存のVRの連結体（concatenatio
n）である新しいVRを生じさせる。

−SUBSTRING［VoiceRopeID₁,Interval］−新しいVoiceR
opeIDを戻し、現存のVRの指定インターバルからなる新
しいVRを生じさせる。

−REPLACE［VoiceRopeID₁,Interval,VoiceRopeID₂］−
新しいVoiceRopeIDを戻し、現存のVoiceRopeID₁の指定
インターバルを置き換えた現存のVoiceRopeID₂を有する
新しいVRを生じさせ、それによって「連結（CONCATENAT
E）」及び「サブストリング（SUBSTRING）」動作の複合
動作を行う。

−LENGTH［VoiceRopeID］−長さを戻し、現存のVRの長
さを、ミリセカンドのような適切な時間単位で決定す
る。

典型的には、これらの動作は、音声マネージャ34への
RPCコールを介して利用することができる。

VRにアクセス制御を重畳することにより、その下にあ
るVFの再生アクセスを制御し、VRの編集を制限する。こ
れらのアクセス制御リストは、個人名や団体名を包含す
ることができる。ビレル（Birrel）らによる「グレープ
バイン：分散型計算における実践（Grapevine:An Exerc
ise in Distributed Computing）」ACMコミュニケーシ
ョン（Communication of the ACM），第25巻,No.4,1982
年４月，第260〜274ページ参照のこと。たとえば、PERM
IT［VoiceRopeID,players,editors］をコールして、指
定VRへのアクセスを指名プレーヤ及び指名エディタに制
限することにより、所定のVRの生成者が、いつでもこの
ようなアクセス制御を設定し或いは変更することができ
る。アクセス制御機構に対して適当なデフォルト設定を
行うと、VRに対するアクセスの制限が行われなかった
り、また、アクセスをその生成者だけに制限することに
なる。

以下判るように、VRは、これらのデータが集中した非
テキストVFを、多数個所でコピーしたり、移動したり、
蓄積したりする必要なしに、多数のユーザが分け合うこ
とができ、また、多数の標準テキスト文書に組み込むこ
とができ、正当なユーザがその下に位置するVFへアクセ
スできるようにするという重要な効果を有する。更に、
本発明の重要な特徴によれば、ユーザは、かれらの個々
の必要や要望に応じて、VRを含む文書をオンラインに或
いはオフラインに自由に蓄積できる。

このような自由度をユーザに与えるために、使用され
なくなったVFにより占有されるファイルサーバ36の空間
を、適時に取り戻すことを確実にしながら、以下に更に
詳細に述べるように、使用されなくなったVFを識別して
それを削除するためのインタレストに基づいたガベジコ
レクタがある。望ましくは、これらのユーザインタレス
トは、ユーザやクラスによって異なるので、それらは各
ユーザの通常のディレクトリ動作に基づいて自動的に生
成されたり削除されたりすることができ、各ユーザは、
所定のクラスにおいて、その人自身の個人的なインタレ
ストを個別に識別する責任がある。たとえば、ユーザ
が、VRを含む文書をその人自身の書類ディレクトリ或い
はメイルディレクトリに入力すると、RPCは、ユーザの
インタレストを音声マネージャ34のVRに次のような形式
で登録し始める。

RETAIN［VoiceRopeID,class,interest,userID］このプロシージャは、指定ユーザのインタレストを、
所定のクラス（たとえば、「ファイル注釈」或いは「メ
ッセージ」）により、所定のVRに登録する。この動作は
上と同様なので、同じようにして後続するコールは、た
だ一つのインタレストを所定の音声ロープに登録する。
更に、FORGET［VoiceRopeID,class,interest］プロシー
ジャがあって、これは、ユーザがVRを含む文書或いはメ
ッセージをその人のディレクトリから削除するとき（そ
れを別のオンライン或いはオフラインディレクトリに移
動するときとは反対に）音声マネージャ34へ発行される
PRCによって要求されることがあり、ときには以下に説
明するガベジコレクション処理の結果、要求されること
もある。また、LOOKUP［class,interest］プロシージャ
は、通常のシステムの管理機能を補助するために、特定
のインタレストに関連した音声ロープの順不同リストを
戻すためのものである。

典型的には、ユーザが要求したインタレスト機構のイ
ンタレスト及びクラスのアトリビュートは、任意のテキ
ストストリングの値である。しかしながら、望ましく
は、インタレスト値の形は、クラスに特有のものである
ので、各クラスは、そのインタレスト値に対する階層的
な形や平坦な形或いはその他の所定の形の識別子を使用
して、インタレストのそれ自体の名称空間（name spac
e）を制御する。他方、インタレストのクラスは、通
常、特定のアプリケーションのために音声ロープが使用
される方法を識別する。たとえば、「ファイル注釈（Fi
leAnnotation）」クラスは、インタレストフィールド
が、ファイル名を与えるために使用されるということと
共に、指名ファイルにおいて共有された文書が、一組の
音声ロープにより注釈されるということを示すために使
用される。同様に、「メッセージ」クラスは、インタレ
ストフィールドがメッセージシステムによって供給され
る独特の消印を含み、特定のメイルメッセージにはその
ようなリファレンスが埋め込まれていることと共に、電
子メイルメッセージが記録音声を参照することを示して
いる。

音声マネージャ34（第１図）は、典型的には、第３図
に示すように、論理的な層を形成し、前述の音声ロープ
編集特徴を実施し、また、そのような音声ロープとその
下にある音声ファイルとにおいてユーザインタレストを
管理するために、簡単ではあるがしっかりとした設備を
提供する。音声ファイルサーバ36は、音声の場合、64k
ビット／秒の持続したデータ転送率を維持することがで
きなければならず、また、連続シーケンス間に認知可能
な休止を作らないように適切なバッファリングを備えた
状態で、音声ファイルインターバルの任意の行列待ちシ
ーケンスの再生に適応することができなければならない
が、これらの要件は、比較的緩やかなものであって、現
在の技術水準で容易に満足されるものである。

音声ロープ及びこれに関連するインタレストの使用の
ために、簡単なデータベースシステム41が備わってい
る。この目的のために、データベースシステム41は、不
変のファイル及び／又はファイルセグメントを参照する
不変のピーステーブルとして音声ロープ（VR）を蓄積
し、基本的な行列待ち及び更新能力を提供し、その下に
ある音声ファイルに関連して、それらを使用する多くの
ユーザ間のVRの共有をサポートする。これらの緩やかな
要求を満足させるものであれば、どのようなデータベー
スシステムでも充分である。たとえば、一つのそのよう
なシステムは、ベイヤー（Bayer）らによるオペレーテ
ィングシステム上級コース（Operating System an Adva
nced Course），スプリンガ−フェアビーク（Springer
−Verbig）,1978年，第393〜481ページに示された「デ
ータベースオペレーティングシステムに関するノート
（Note on Database Operating System）」にグレイ（G
ray）により示されるように、ライトアヘッドログ（wri
te ahead log）において、キーと値との対として表され
た特性シーケンスとして各エントリを蓄積する。しかし
ながら、データがより永久的な位置に書き留められまた
書き込まれるまでしかそのデータが記録されない殆どの
データベースシステムとは異なって、データベースシス
テム41内のライトアヘッドログは、永久的なデータのソ
ース（すなわち、一旦書き込まれるとそのデータは決し
て移動されない）である。このようにして、ログファイ
ルの対応する位置に一つ以上のキーの値をマッピングす
るために、前記ライトアヘッドログに対する直接のリフ
ァレンスによってＢツリーインデックスを作り出すこと
ができる。電子メイルシステムに対してログを構成する
ためにも、同様の技術が使用されてきた。ドナヒュー
（Donahue）らによる「ウォールナット：データベース
に電子メイルを蓄積する（Walnut:Storing Electronic
Mail in a Database）」，ゼロックスパロアルトリサー
チセンタ（Xerox Palo Alto Research Center），テク
ニカルレポートCSL−85−9,1985年11月を参照のこと。
更にまた、ランソン（Lampson）による「コンピュータ
システム設計のためのヒント（Hint for Computer Syst
em Design）」，オペレーティングシステムの原理に関
する第９回シンポジウム会報（Proceedings Ninth Symp
osium on Operating System Principle），ニューハン
プシャー，ブレトンウッド,1983年10月，第33〜48ペー
ジを参照のこと。

音声ロープを表すための最低限のデータ構造は、［Vo
iceRopeID,key,interval］の三つ組からなっている。そ
の他の付加的特性が、VoiceRopeID,生成者の識別，アク
セス制御リスト及び音声ロープの全長のために包含され
ることもある。このことは、音声ロープに対する典型的
なデータベースのログエントリが次の形を有することを
意味する。

VoiceRopeID:Terry.pa＃575996078 Creator:Terry.pa Length:80000 PlayAccess:VoiceProject↑.pa EditAccess:none VoiceFileID:235 Key:17401121062B 10300460457B Interval:0 80000 このようなエントリは、音声ロープ構造が、それらの
VoiceRopeIDによって効率的に検索することができるよ
うなインデックスを構成するために使用することができ
る。これはまた、VoiceFileIDのインデックスを維持さ
せることができ、これは以下に充分に説明するガベジコ
レクションにとって有用である。

前述の音声ロープ編集処理を使用することによって、
より複雑な音声ロープを構成することができる。たとえ
ば、第４図に示すように、二つの簡単な音声ロープVR₁,
VR₂があり、これらは次のような構造を有する。

VR₁＝〈VoiceFileID:VF₁,Key:K₁,Interval: ［start:0,length:4000］〉 VR₂＝〈VoiceFileID:VF₂,Key:K₂,Interval: ［start:500,length:2000］〉この場合の動作 Replace［base:VR₁,interval:［start:1000, length:1000］,with:VR₂］は、新しい音声ロープVR₃を生じさせる。その構造は、 VR₃＝〈VoiceFileID:VF₁,Key:K₁,Interval: ［start:0,length:1000］， VoiceFileID:VF₂,Key:K₂,Interval: ［start:500,length:2000］ VoiceFileID:VF₁,Key:K₁,Interval: ［start:2000,length:2000］〉管理を簡単に検討し、ディジタル的に記録された音声
と、本発明が利用されるデータが集中した非テキストデ
ータのその他のデータを編集することによって、音声が
記録されるとき、音声マネージャ34が音声ファイルサー
バ36をコールし、新しいVFを作り出し、この新しいVFの
内容としての所定のConversationIDとの指定の会話を通
して到達した音声を蓄積する。記録の完了時、音声マネ
ージャ34は、新しく記録されたVFを表すために簡単なVR
をデータベースシステム41内の音声ロープデータベース
に付加する。会話をエンコードするための音声制御サー
バ32により割り当てられた符号化キーは、音声ロープデ
ータベースエントリに蓄積されるので、このキーは、VR
の一つ以上のインターバルを伴う全ての後続する編集動
作中、VoiceFileIDに伴って移動する。音声データファ
イルは、一旦VF₁に記録されると、編集中でさえ移動さ
れることもコピーされることもない。

VRを再生するとき、音声マネージャ34は、始めにデー
タベースシステム41からVRの構造を検索する。VRの再生
時に、全ての参加者の正当な識別が、VRに関連したいず
れかのアクセス制御と一致している場合、音声マネージ
ャ34は、所定のVRに関連したVFの指定インターバルのた
めに一つ或いは複数の符号化キーを参加者に分配するこ
とにより、また、音声ファイルサーバ36に適切な順序で
これらのVFインターバルを再生させることにより、再生
処理を継続する。前に指摘したように、音声ファイルサ
ーバ36は、望ましくは充分に大きな出力バッファを有
し、二つ以上のVFインターバルを、それらの間にどのよ
うな休止も引き起こすことなく再生させることができ
る。

好適には、VRは、再生性能を強化するために平坦構造
を有する（すなわち、各VRはその関連するVFを直接参照
するので、単一のデータベースアクセスは、所定のVRの
完全な構造を決定するのに充分である）。また、複合VR
は、VFのインターバルを表すVRを有するツリー構造のデ
ータベースにおいて、ツリーの葉のところで、他のVRの
インターバルとして共有することができる。この方法
は、VRを編集する処理コストを低減させるが、同じ或い
は異なるVFの二つ以上の指定インターバルを表す複合VR
を再生するのに必要なデータベースのアクセスの数を増
やしてしまうことになる。換言すれば、特定の使用パタ
ーンに対して、VRデータベース構造を最適にするために
は、妥協点がある。

以下、判るように、所定のVFを参照する全てのVRが一
旦削除されると、VRは再び特定のVFを参照することはな
いので、そのVFに割り当てられた音声ファイルサーバ36
の蓄積空間は、VFを削除することにより、後続する再使
用のために取り戻される。所定のVFを参照するVRが未だ
存在するかどうかを決定するためには、データベースシ
ステム41に対して真っ直ぐに行列待ちする音声ロープデ
ータベースで充分である。しかしながら、所定のVRを削
除できるか否かを決定することはより困難である。この
ように、前述の「インタレスト（interest）」動作は、
VRとこれに関連するVFの自動的な取り戻しを可能にする
キーである。

ユーザは、データベースシステム41内のインタレスト
データベース内のような既知の場所に、かれらのVRイン
タレストを記録する必要がある。そして、これらの記録
されたインタレストは、ユーザが通過するVRリファレン
スに対する代替物として作用するので、これによって、
有効に参照された活性VRと、無効的に参照された、すな
わち、非参照の使用されなくなったVRとを区別するため
の論理的根拠を提供する。所望であれば、たとえば、特
定のタイムアウト期間のようなリファレンス無効化機構
を、適切に参照されたインタレストへ組み込むことがで
きるので、所定のVR（期間内のタイムアウトを含む）に
対する有効なリファレンスが存在しないときには、VRの
不要化が生じることは理解されるべきである。

前述のように、RETAINプロシージャがコールされたと
き、そこに既にエントリがなければ、インタレストデー
タベースにエントリが付加される。このデータベースエ
ントリは、VoiceRopeID,インタレストのクラス，インタ
レスト値及びユーザの識別とを包含し、それによって、
これらの属性のいずれかに基づいてインタレストのデー
タベースに問い合わせることができる。残念ながら、VR
に対するリファレンスを含む文書或いはメッセージがユ
ーザのディレクトリに入力されたり、そこから削除され
るとき、所定のVRにユーザのインタレストを記録したり
それを削除するために、RETAINプロシージャ及びその相
補であるFORGETプロシージャをコールするように現存の
ワークステーション及びファイルサーバを変更すること
が不可能な場合もある。しかしながら、ユーザが、一時
的なワークステーションの蓄積から、より永久的な蓄積
のためのファイルサーバへ、VRリファレンスを含むファ
イルを移動させるときに、自動的に求められる付加的プ
ログラムを各ユーザのオペレーティングシステムへ組み
入れることが可能であり、それよって、そのようなファ
イルで参照された各音声ロープに対して次の形のコール
が発行される。

RETAIN［VRID:VoiceRopeID,class, “File Annotation,"Interest:“Annotated File Name Name",User:Authenticated Name］このように、それ以後はいつでも、どのような所定の
ユーザのインタレストに対しても、所定のインタレスト
が属するVRリファレンスを含むファイル（たとえば、
「注釈されたファイル名」）のユーザが名付けた要求が
未だ存在するか否かを決定するために、標準のファイル
サーバディレクトリの計数動作を実行することができ
る。各ユーザアプリケーションは、そのようなユーザに
よって登録されたインタレストのクラスを決定し、その
ようなインタレストには、ユーザが決定した値（たとえ
ば、インタレストのクラス、たとえば、すなわち「ファ
イル注釈」に対する「注釈されたファイル名」）が与え
られる。このことは、個々のユーザが、たとえば、種々
異なる版数のような独特の値を、所定のインタレストの
クラス内に記録することが望まれるような異なったイン
タレストに割り当てる責任があることを意味する。

インタレストデータベースに、不要となったインタレ
ストを自動的に位置付け、そこから削除するために、イ
ンタレストクラスの実施者が次の形式のプロシージャを
音声マネージャ34に登録する。

IS GARBAGE［VoiceRopeID,Interest］−｛Yes,No｝このプロシージャは、クラス指定を行う方法で、所定
のインタレストが未だ特定のVRに適用されているか否か
を決定する。たとえば、前述のファイル注釈クラスの場
合、このプロシージャは、インタレストパラメータのユ
ーザの指定値が分散型コンピュータシステム21内のいず
れかにあるファイルサーバにもはや存在しない場合にだ
け「YES」を戻す。

好適には、第５図に示すように、音声マネージャ34
は、符号51〜55のところで示すように、インタレストの
データベースを定期的に数え上げ、更に、符号55〜56の
ところで示すように、各インタレストに対してクラス指
定のIS GARBAGEプロシージャ（それが登録されている場
合）をコールするインタレスト照合器（verifier）を有
する。どのインタレストのクラスに対しても適するIS G
ARBAGEプロシージャは、符号57のところで示すように、
所定のクラス内のエントリが有効か否かを決定するため
に種々の基準を利用する。たとえば、このプロシージャ
は、たとえば予め決められたタイムアウト期間の満了
や、アクセス制御リストに対する一貫性のような、本質
的な無効基準に対してエントリをチェックする。それは
また、検査されるエントリに対して指定されたインタレ
スト値（たとえば、「注釈されたファイル名」）がまだ
ファイルサーバ上に存在するか否かを決定するために、
分散型コンピュータシステム21のためのファイルサーバ
へディレクトリの問い合わせを発行することもできる。
所定のインタレストが何らかの原因で無効と決定された
場合には、符号58のところで示すように、プロシージャ
FORGET［VoiceRopeID,class,interest］がコールされ、
符号59のところで示すように、それがインタレストのデ
ータベースから削除される。

第６図を参照すると、音声マネージャ34は、また、符
号71〜74のところで示すように、音声ロープデータベー
スを定期的に数え上げるための音声ロープガベジコレク
タを有するので、孤立したVRは符号75のところで示すよ
うに、そこから削除される。望ましくは、符号76のとこ
ろで示すように、或るクラス或いは全てのクラスのVR
を、それらが生成された後、少なくとも或る有限の時間
は本質的に保護する手段が備えられるので、関係を有す
るユーザは、それらの中にインタレストを登録する正当
な機会を有する。

しかしながら、そのような本質的な保護がなされない
とき、検査されるVRがインタレストデータベース内の少
なくとも１個の有効なインタレストにより参照されてい
ることが符号77のところで示されるように決定されない
限り、所定のVRは、音声ロープデータベースから削除さ
れる。

第７図に示すように、別の音声ファイルガベジコレク
タが、符号81〜84のところで示すように音声ファイルデ
ータベースを定期的に数え上げるための音声マネージャ
34に包含されるので、符号85のところで示すように、も
はやそれらを参照しないVRは、符号86のところで示すよ
うに削除され、これによって、これらに割り当てられた
音声ファイルサーバ36（第１図）上に蓄積空間を取り戻
すことができる。

しかしながら、第８図に示すように、音声ファイルガ
ベジコレクタは、音声ロープガベジコレクタと統合され
るので、これらの機能は同時に実行される。たとえば、
第６図の符号77のところで示すように、所定のVRが孤立
していることが決定されるとき、その孤立したVRにより
参照されたVFは、符号91〜93のところで示すように数え
上げられる。これにより、これらのVFの各々が音声ロー
プデータベースに対してチェックされ、符号94のところ
で示すように、それらが他のVRにより参照されるかどう
かを決定するので、孤立したVFを、符号95のところで示
すように削除することが可能となる。孤立したVRにより
参照された全部のVFが検査された後、VRは符号75のとこ
ろで示すように削除され、第６図の符号72のところで示
すように、次のVRとともにこのVRを計数し続けるため
に、この処理が循環する。

同様に、第９図に示すように、音声ロープガベジコレ
クタは、インタレストガベジコレクタと統合することが
できる。インタレストデータベースにおける各エントリ
は、単一のVRを参照するので、第５図の符号57のところ
で示すように、所定のインタレストが無効であることが
決定されると、第９図の符号96のところで示すように、
インタレストデータベースが検査され、これが、符号97
のところで示すように、無効インタレストに関連したVR
を参照する他のインタレストをまだ含んでいるか否かを
決定する。所定のVRへのその他のリファレンスが見当た
らなければ、このVRと無効インタレストエントリの双方
が、それぞれ、符号98,99のところで示すように削除さ
れる。他方、VRを参照する他のインタレストが存在する
場合、第５図の符号52のところで示すように、次のイン
タレストとともにインタレストデータベースの計数を継
続するために循環して戻る前に無効インタレストだけを
削除する。

〔結論〕

以上のことから、本発明は、分散型計算環境にあるワ
ークステーションのユーザが、データが集中した非テキ
ストメディアファイルの多数のコピーを作ったりそのよ
うなファイルを移動したり修正したりする必要なしに、
この非テキストメディアファイルを編集し共有すること
ができる効率的で柔軟性のある方法及び手段を提供する
ことが判るであろう。

【図面の簡単な説明】

第１図は、ゲートウェイ及び通信チャンネルにより命令
でリンクされる一対のローカルエリアネットワークを示
す概略図であって、そのローカルエリアネットワーク
は、本発明にしたがって、通常のテキストによる通信の
他に音声による通信をサポートするように構成されてい
る。第２図は、音声ファイルを記録し、編集し、再生す
るための適切なユーザインターフェースを示すワークス
テーションのスクリーンである。第３図は、ローカルエ
リアネットワークのための音声マネージャの論理的に層
が形成された図である。第４図は、音声ファイルと、そ
れらを参照するために使用されるデータ構造の関係を示
す概略図である。第５図は、インタレストガベジコレク
タの単純化された機能フロー線図である。第６図は、音
声ロープガベジコレクタの単純化された機能フロー線図
である。第７図は、音声ファイルガベジコレクタの単純
化された機能フロー線図である。第８図は、統合された
音声ロープ／音声ファイルガベジコレクタの単純化され
た部分的機能フロー線図である。第９図は、統合された
インタレスト／音声ロープガベジコレクタの単純化され
た部分的機能フロー線図である。 21:分散型コンピュータシステム 22:ローカルエリアネットワーク 23:ゲートウェイ 24a,24b:ワークステーション 34:音声マネージャ 35:音声制御サーバ 36:音声ファイルサーバ 41:データベースシステム 42,43:ウィンドウ

───────────────────────────────────────────────────── フロントページの続き (58)調査した分野(Int.Cl.⁶，ＤＢ名) G06F 12/00

Claims

(57)【特許請求の範囲】

【請求項１】通信メディアと、ユーザが各ワークステーション間でディジタルテキスト
データを相互に転送することを可能にするために前記通
信メディアに接続された複数のワークステーションと、人が認識できる情報内容を含むディジタル非テキストデ
ータファイルを蓄積するために前記通信メディアに接続
されたファイルサーバと、前記ワークステーションの少なくともどれかの近くに配
置された変換手段であって、該変換手段は、前記ワーク
ステーションとは独立に前記通信メディアに接続され、
アクセスの認可に従って、ユーザが、非テキストデータ
ファイルを前記ファイルサーバに記録し、そのようなフ
ァイルを再生することができるようにされたものとを包
含するハイパーメディア分散型コンピュータシステムに
おいて、新しい非テキストデータファイルが記録される度に、前
記ファイルサーバに独特の名称が付けられた蓄積空間を
割り当てるために、また、その記録の終結時に前記各フ
ァイルの長さを決定するために、前記ファイルサーバ及
び前記通信メディアに接続された管理手段を備え、該管理手段は、新しい非テキストデータファイルが前記
ファイルサーバに記録される度に、前記管理手段が、そ
のようなファイルを名称及び長さにより参照する独特の
名称が付けられた不変のエントリを作るリファレンスデ
ータベースを有するデータベースシステムを包含し、前記ワークステーションは、ユーザが、前記リファレン
スデータベースのエントリを操作し、ユーザが選択した
非テキストデータファイルのユーザが選択したインター
バルを参照する前記リファレンスデータベースのための
付加的な独特の名称が付けられた不変のエントリを生成
することを可能にするための編集手段を包含し、これにより、前記リファレンスの名称はユーザに分配さ
れたテキストデータに埋め込まれ、ユーザに、前記非テ
キストデータファイルのいずれも複写したり移動したり
する必要なしに、任意に指定された順序で前記非テキス
トデータファイルの選択されたもの及び前記ファイルの
選択された部分に対するアクセスを与えることを特徴と
するハイパーメディア分散型コンピュータシステム。