JP5500385B2 - ネットワークを介したリアルタイムメディア同期の方法およびシステム - Google Patents

Description

本発明は通信に関し、特に音声通信の準リアルタイム同期の方法および装置に関する。

音声通信は、慣性の影響を受けるのが現状である。自動切換え、高帯域幅ネットワーク、さらに衛星通信、光ファイバー通信、ＩＰネットワーク通信（ＶｏＩＰ）、無線通信および携帯電話ネットワーク等の技術にもかかわらず、人々の電話の使い方にほとんど変化が見られない。いまだに、電話機を持ち上げ、相手にダイアルし、繋がるまで待ち、挙句にダイアルした相手と同期二重会話を強いられている。もし受信側が応答しなければ、接続はできず、会話も始まらない。

受信側がボイスメールを持っていれば、せいぜい一方通行の非同期の音声メッセージを残せるぐらいである。しかし、ボイスメールをレンダリングする手順は煩わしく時間もかかる。呼出し側は、相手方の電話の呼び出しリンが鳴り止み、ボイスメールシステムに遷移するのを待ち、音声メッセージの挨拶を聞き、それからメッセージを残さなければならない。現在のボイスメールシステムは、受信側にとっても不便である。受信側は、コードにダイアルして音声メールにアクセスし、一連のプロンプトをナビゲートし、待ち行列の中に先着の音声メッセージあればそれを聞き、それからやっと当の送信側のメッセージを聞かなければならない。

典型的なボイスメールシステムの他の短所は、音声メッセージを組織化すなわち永久にアーカイブすることができないことである。ボイスメールシステムの中には、ユーザがメッセージを記憶できるものもあるが、予め決められた時間が経過すると、自動的に削除され永久に失われてしまう。

さらに、現在のボイスメールシステムの別の問題は、メッセージを残す前に呼出し側とボイスメールシステムで接続をしなければならないということである。もし接続ができなければ、呼出し側にとってはメッセージを残す手立てはない。

現在の電話システムは、リアルタイムの通話、バラバラの音声メッセージといった比較的単純な利用パターンに基づいており、それらは、たいていは聞き終われば削除される。これらの音声通信形式は、音声通信で可能な真価を発揮していない、または現在可能なネットワークの速度および回線容量の進歩を活用できていない。また、もし電話回線がダウンしてしまった場合、すなわち利用不能な場合（例えば、携帯電話のユーザがサービス圏外にいる、または悪天候のために電話回線がダウンした）、通信は起こりえない。

一般に、電話ベースの通信はテキストベースの通信の進歩に追いついていない。インスタントメッセージ、Ｅメール、ファックス、グループチャット、テキストメッセージをアーカイブすることなどは、テキストベースの通信ではすべて当前のことである。音声メールのほかには、音声メッセージを管理および／またはアーカイブできる現在利用可能なツールはほとんどない。テキスト通信と比較すると、現在利用できる電話通信を管理するツールはまだ初歩的な段階にある。

企業環境は、現在の音声通信ツールにおける弱点の良い例を示している。今のところ、音声通信を法人資産として管理する統一された方法はない。従業員は普通、自分たちの電話での会話を録音したり永久保存したりすることはない。ビジネス関連の音声通信資産は、ほとんど言葉が話されると同時に即座に消えてしまい、これらの会話の内容を何らかの管理可能な形式で管理または保存する方法はない。

実例として、ある会社の営業幹部の例を考えてみよう。多忙な一日の流れの中で、この幹部はたくさんの電話をかけ、顧客から電話で幾つかの販売契約をとる場合がある。これらの会話を編集、保存、後に検索する手立てがないので、この幹部にとっては、ある取引と他の取引との条件についてのリコール、あるいは先に結んだ販売合意の条件に異議を唱える顧客に対しその根拠の説明を求める、といった後に発生することが予想される問題を解決する方法はない。もしこの幹部が会話を簡単に取出し、レビューすることが可能であれば、このような問題は簡単にかつ良好に解決することができるであろうと思われる。

現在、軍隊、消防、警察、救急医療隊、レスキュー隊、および第一応答者等に使用されている戦術的無線システムも、多くの不便をこうむっている。戦術的無線通信は、ほとんどの場合、メッセージの送信側と受信側の間で「ライブ」の無線接続で行われるに違いない。両者間に無線接続なければ、通信は成り立たつはずがない。もし、送信側または受信側が自分の無線にアクセスできない、あるいは無線回路の接続ができなければ、緊急メッセージを送ることは不可能だ。したがって、戦術的通信は、次のような幾つかの基本的な問題に悩まされている。（ｉ）メッセージが送達される保証がない、（ｉｉ）受信側は、リアルタイムで聞きそこねたメッセージに戻ったり聞いたりできない、（ｉｉｉ）会話参加者の情報粒度をコントロールすることができない、（ｉｖ）ライブ会話を行うための信号品位に欠ける場合、システムは対処できない。もしメッセージをライブで聴けなければ、そのメッセージは失われてしまう。送信側または受信側にとって、以前送られた会話のメッセージを管理する、優先順位をつける、アーカイブする、後で検索する（すなわち、タイムシフトする）のいずれかができるツールはない。

さらに、戦術的無線通信システムに関する別の短所は、１チャンネルにつき一時に一個のメッセージしか送信できないということである。大きなビル火災を例にとって見ると、そこでは、消防士、警察および救急救命士等の複数のチームが同時にビルに取り残された被害者を救助したり、消火活動したり、被害者に医療援護を提供したり、野次馬を整理したりしている。もし、各チームが同じチャンネルを使用しているとしたら、通信は混雑し大混乱に陥るかもしれない。一人以上の人が同時に送信していたら、通信は「踏倒し」がおこる。また、高い優先順位のメッセージと低い優先順位のメッセージとを区別する方法もない。燃え盛るビルの中で消火活動または取り残された被害者の救助活動をしているチームが、当然、野次馬の整理にあたっている他のチームより高い優先順位を持つ。もし、高い優先順位のメッセージが低い優先順位のメッセージによって踏倒されたら、重要な通信が妨害されるだけでなく、ビルの中にいる消防士と被害者の命に危険が及ぶことになる。

メッセージに優先順位をつけることができないことに対する、考えられるひとつの解決策としては、複数のチャンネルを使い、それぞれのチームに異なるチャンネルを割り当てることである。しかしながら、この解決策はそれ自体一連の問題を生じる。また、消防隊長は、どのチャンネルをどの時点で聞けば間に合うのかをどうやって判断するのか。複数のチームの全員がそれぞれ異なるチャンネルと接続していたら、どうやってたがいに通信をかわすのか。一つのチームが緊急援助を求めたとき、他のチームが別のチャンネルを聞いていたら、どうやってそれを知るのか。複数のチャンネルが幾つかの問題を軽く扱った場合、それが混乱を引き起こし、チャンネルが一つのとき以上にさらなる問題を生じる可能性がある。

効果的にメッセージに優先順位をつける、マルチ会話が同時に行える、メッセージのタイムシフトを行い、送達を確実にする、あるいは後の検索・レビューのためにマルチ会話をアーカイブすることをサポートする管理ツールがないことが、戦術的無線の問題に結びついている。軍隊、警察、消防のような第一応答者の立場においては、有効な通信ツールの有無が、文字通り生死、任務の成否を分かつ。上記の燃え盛るビルの例が、戦術的無線通信に係わる現在の幾つかの問題をわかりやすく例示している。戦術的通信を使用する軍隊、警察、第一応答者、その他にも同様な問題が存在する。

パケット方式のネットワークでは、共通に使用されるプロトコルとして、通信制御プロトコル（ＴＣＰ）およびユーザ・データグラム・プロトコル（ＵＤＰ）がある。ＵＤＰは、データの高速送達という利点はあるが、完全性を犠牲にする。パケットがデータ送信中に脱落する可能性があり、またデータを即座に宛先に届けようとする場合は使用できない。ＵＤＰは、幾つかの欠陥があるにもかかわらず、その速度属性のゆえにヴォイス・オーバ・インターネット・プロトコル（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ：ＶｏＩＰ）通信の標準になっている。一方、ＴＣＰは完全なデータ（すなわち、送信データの正確なコピー）の送達を保証するが、待ち時間を代償とする。どれほど時間がかかろうとも、全てのパケットが送達される。この遅延の問題が、ＴＣＰを「ライブ」通話に適さないものとしている。今のところ、ＴＣＰ、ＵＤＰの両者に機能の進化をもたらし、「十分に良い」メディアの完全なコピーを即座に送信できる、究極の送達が可能なプロトコルは知られていない。ネットワーク上の受信側の存在と、ライブまたはタイムシフトモードでデータを届けようとする意図に基づいて、どれだけの量の情報をネットワークを通じて送るべきか、を判断できるプロトコルはない。さらに、どれだけの量のデータを送信すべきか判断する際に共通に考慮されるその他のファクタとしては、例えば、ネットワーク待ち時間、ネットワークの劣化、パケット損失、パケットダメージ、一般的な回線容量の状態等がある。しかしながら、従来技術のシステムは、受信側のプレゼンスと意図を考慮しない。その結果、データが受信側によってリアルタイムで届けられるということが大前提となる。従来技術のシステムでは、受信側が即座にデータをレンダリングするつもりがなければ、不必要に回線容量を使い、ネットワーク全体のパフォーマンスを引き下げてしまう。

上記の理由により、電話、音声メールおよび戦術的音声通信システムは十分とはいい難い。したがって、送信と受信の双方の通信デバイスおよびこの２つの通信デバイス間のネットワーク上の各ホップにおける音声その他のメディアのストレージの準リアルタイム同期を含み、音声およびメディア通信の管理システムおよび方法の改良、パケット方式のネットワーク上の音声その他のメディアの改良が必要である。

本発明は、ネットワーク上のノード間で送信されたメディアを保存したコピーのリアルタイムの漸次的同期の方法およびシステムに向けられる。この方法とシステムは、インデックスされたメディアの準リアルタイムのレンダリングを可能とするのに十分なパケットサイズおよびパケット化間隔で送信ノードから受信ノードへ利用可能なインデックスされたメディアを漸次送信するステップを含み、インデックスされたメディアを準リアルタイムにレンダリングすることによって送信されたメディアをライブでレビューする機能（ｅｘｐｅｒｉｅｎｃｅ）を受信側に提供する。受信ノードでは、送信されたインデックス済みのメディアが漸次受信され、受信ノードでローカルにまだ保存されていない任意のインデックスされたメディアが記録される。この方法とシステムはまた、ネットワークを通じて２つの通信デバイス間の会話のメディアのリアルタイム同期を含む。音声その他のメディアが任意の通信デバイスで生成されるとき、このメディアのコピーがネットワークを介してリアルタイムで同期される。この方法とシステムはまた、実装するのが簡単であり、ネットワークトラフィックと待ち時間を減少させる最適化されたルーティングプロトコルを含む。

本発明の特定の実施例を示す付属の図面とあわせて以下の説明を読めば、本発明は最良の理解が得られるであろう。

図１は本発明の通信およびメディア管理システムのアーキテクチャを示す図である。 図２Ａは本発明の通信および管理システムのデバイス上で実行するクライアントのブロック図である。 図２Ｂは本発明の通信および管理システムのデバイス上で実行するクライアントのブロック図である。 図３は本発明の通信および管理システムで使われるサーバのブロック図である。 図４Ａないし４Ｄは本発明の通信および管理システムで使われるデータペイロードの種々の実施例を示す。 図５は本発明に係わる共用ＩＰネットワーク上を送信されるデータを示す図である。 図６は本発明に係わる回路ベースのネットワーク上を送信されるデータを示す図である。 図７は本発明に係わるセルラーネットワークおよびインターネットの両者上を送信されるデータを示す図である。 図８Ａは本発明の通信および管理システムの記憶およびストリーミング機能を示す一連のフロー図である。 図８Ｂは本発明の通信および管理システムの記憶およびストリーミング機能を示す一連のフロー図である。 図８Ｃは本発明の通信および管理システムの記憶およびストリーミング機能を示す一連のフロー図である。 図８Ｄは本発明の通信および管理システムの記憶およびストリーミング機能を示す一連のフロー図である。 図８Ｅは本発明の通信および管理システムの記憶およびストリーミング機能を示す一連のフロー図である。 図８Ｆは本発明の通信および管理システムの記憶およびストリーミング機能を示す一連のフロー図である。 図９Ａはペイロード品質管理部（ＰＱＭ）の動作を示すフロー図であり、本発明のクライアントおよびサーバに使用されるものである。 図９Ｂはペイロード品質管理部（ＰＱＭ）の動作を示すフロー図であり、本発明のクライアントおよびサーバに使用されるものである。 図９Ｃはペイロード品質管理部（ＰＱＭ）の動作を示すフロー図であり、本発明のクライアントおよびサーバに使用されるものである。 図９Ｄはデータ品質管理部（ＤＱＭ）を示すフロー図であり、本発明のクライアントおよびサーバに使用されるものである。 図９Ｅはデータ品質管理部（ＤＱＭ）を示すフロー図であり、本発明のクライアントおよびサーバに使用されるものである。 図９Ｆはデータ品質管理部（ＤＱＭ）を示すフロー図であり、本発明のクライアントおよびサーバに使用されるものである。 図１０は、本発明に従って２つの通信デバイス間の会話のメディアの準リアルタイム同期を示すダイアグラムである。 図１１は、本発明による２つの通信デバイス間のインデックスされたメディアのリアルタイム同期のシーケンスを示すフローダイアグラムである。 図１２は、本発明による分散型サービスアーキテクチャの一例を示す図である。 図１３は、本発明によるルーティングプロトコルを示す分散型サービスアーキテクチャの別の例を示す図である。 図１４は、本発明によるネットワークを介した各ホップでのメディアの準リアルタイム同期を示す別の分散型サービスアーキテクチャの別の例を示す図である。 図１５Ａは、本発明のクライアントおよびサーバアプリケーションを実行するのに用いられたハードウェアを示すブロック図である。 図１５Ｂは、本発明のクライアントおよびサーバアプリケーションを実行するのに用いられたハードウェアを示すブロック図である。

図において同じ付番は同じ要素を示すものとする。

付属の図面に示す種々の実施例を参照して本発明を詳細に説明する。以下の説明では、本発明の完全な理解に資するために、特定の実施例について詳細に記載する。しかしながら、当業者にとっては、ここに記載する実施例の幾つかの細部を使用することなく本発明が実施可能であることは明らかである。不要な混乱を避けるために、周知の動作等については詳しい説明を控えたことは、理解できよう。

［Ａ．機能の概要］
本通信メディアの管理方法およびシステムは、音声、ビデオ、テキスト、ロケーション、センサ情報、その他のデータ等の様々なタイプのメディアを使って、音声会話に参加するためのモードをサポートする、および／または多人数による同時会話を管理する新しいモードをサポートする。ユーザは、指定する受信者に音声メッセージを送ることによって会話に加わることができる。受信者は、好みや優先度によってリアルタイムで会話に参加したり、メッセージが検索できることを単に通知だけを受けたりすることもできる。後者の場合は、受信者は都合のよいときに記録されたメッセージを見なおしたり返信したりすることによって、タイムシフトモードで会話に参加する。

ユーザは、次の通信を行う権利を与えられる。すなわち、（ｉ）ほぼ同期性の「ライブ」会話：これは、ユーザに標準的全二重通話と同じ体験をレンダリングする、または（ｉｉ）タイムシフトモード：すなわち、一連の時間差通信。さらに、会話に参加したユーザは、ライブモードからタイムシフトモードに切目なく遷移し、再度ライブモードに戻ることもできる。また、この属性により、ユーザは、会話ごとに優先順位をつけたり二つのモード間を移動したりして、マルチ会話に参加することを可能にする。したがって、このシステム使用する二人の個人は、互いに記録した音声メッセージをやり取りしたり、都合のよいときにそのメッセージをレビューしたりすることができる。また、メッセージをある速度で送り基本的にライブに合流させ、音声同時通話を実現する。この新しい通信の形式は、本発明の目的から、「ヴォクシング：Ｖｏｘｉｎｇ」と呼ばれる。

誰かと「ヴォクス：Ｖｏｘ」すると、その会話は一連の不連続な記録されたメッセージで構成され、沢山のロケーションに記録される。また、「ヴォクス」には、送信側のエンコードデバイス（例えば、電話またはコンピュータ）を含み、ネットワーク上の複数の送信ホップ上のサーバ、さらに受信側のレンダリングデバイスが含まれる。標準的な通話または音声メールとは異なり、このシステムは次のような機能と利点を提供する。（ｉ）会話がライブとタイムシフトまたはその逆を遷移できる。（ｉｉ）会話の不連続なメッセージは、意味論的に束ねられアーカイブされる。（ｉｉｉ）メッセージは記録され後で検索できるから、注意を一時的に会話からそらしても、後で都合のよいときに会話をレビューすることができる。（ｉｖ）会話は数秒、数分、数時間または数日間中座し、そこから再開することができる。（ｖ）進行中の会話に再度加わることができる、見損ねたメッセージを即座にレビューすることができる、または現在のメッセージにキャッチアップすることができる（すなわち、ライブメッセージ）。（ｖｉ）従来の通話のように、会話をするのに特別の回路を必要としない。（ｖｉｉ）個人またはグループに送信するだけで会話が始められる。メッセージを受信していることに気がついたら、相手方の人は、リアルタイムでレビューし会話を行うか、後にレビューか自由に選択することができる。

また、通信メディア管理システムは、ネットワークを通じてのデータ送信を最適化する新しいモードをサポートする。ネットワークの状態が理想より悪い場合は、システムはペイロードを会話に参加している受信側に送達するのをアクティブにリアルタイムで管理する。例えば、ネットワークの状態が悪いときは、システムは送信用のデータの質を、受信側が受け取ったときにレンダリングするのに「十分に良い」レベルまで意図的に引き下げ、リアルタイムの会話に参加できるようにする。また、システムは、メッセージの「正確な」コピーを長い時間をかけて最終的に送達することを保証する。したがって、本システムおよび方法は速度と精度の両方の利点を提供する。受信側の存在および受信側がリアルタイムで即座にメッセージを見る意思があるかどうか、ネットワーク待ち時間、ネットワークの劣化、パケットの損失またはダメージおよび／または現在の回線容量の状態の測定に基づいて適時性とメディアの質との間でトレードオフを行うことによって、ネットワーク回線容量が最適に利用できるようにする。

ここで、会話のメッセージが含むことができるのは、音声のみ、または音声、ビデオおよびセンサ情報、その他のデータである。メッセージがレビューされるとき、メッセージに含まれるメディアのタイプによって、耳で聞かれる、視覚的にレビューされる、または、その組み合わせである。本発明の申請段階では、ほとんどの会話は音声のみであるが、ここに記載する通信システムおよび方法は、例えば、音声およびビデオ等の複数のメディアタイプを含む会話を広く含むことを意図している。

次の特徴や機能のうちの一またはそれ以上を提供する、改良型音声その他のメディア通信、管理システムおよび方法を開示する。
ｉ．ユーザが、ライブ通話、会議通話、音声メッセージ、継続的または同時通信等を含む多くのタイプの会話に参加可能にする。
ｉｉ．ユーザが、会話のメッセージをライブモードまたはタイムシフトモードのどちらかのモードでレビュー可能にする（音声メッセージ）。
ｉｉｉ．ユーザが、同時「ライブ」モードとタイムシフトモードの間で会話を切目なく遷移することを可能にする。
ｉｖ．他の参加者またはネットワークとの接続が確立されるのを待たずにユーザが会話に参加することを可能にする。この属性は、利用できるネットワークがない、ネットワークの質が悪い、他の参加者が参加できない場合でも、ユーザに会話を始める、会話に参加する、以前に受信しタイムシフトされた会話のメッセージをレビューすることを可能にする。
ｖ．システムに、送信側のメディアのペイロードデータの記憶を可能とし、ネットワーク送信後、全ての受信側にメディアのペイロードデータの記憶を可能とする。
ｖｉ．システムに、所定の会話において、各メッセージが識別でき、かつ所定の参加者に結びつけることができる、意味論的に有意味の会話にスレッディングすることによって、メッセージを組織化できるようにする。
ｖｉｉ．ユーザに、一組のユーザコントロール機能を使って、「ライブ」をレビュー、レビューするのに都合がいい時まで会話を休止またはタイムシフトする、様々なモードで再生する（例えば、早送り、ライブにキャッチアップする、会話の頭にジャンプする）、会話を管理する方法（アーカイブする、タグ付けする、検索する、アーカイブから取り出す）等、各会話を管理可能にする。
ｖｉｉｉ．システムに、オンラインの状態、所定のメッセージをライブかタイムシフトモードのどちらかでレビューする意図、メッセージに対する現在の注意、レンダリングの方法、および送信側と受信側の間のネットワークの状態を含む、参加データの管理を可能にし、全ての会話参加者と共有化可能とする。
ｉｘ．下記の場合は、ユーザが、マルチ会話を同時に管理することが可能にする。（ａ）１つの会話を進行、その他の全てを休止とする、（ｂ）戦術的通信のような（これに限らず）マルチ会話を継続してレンダリングする、（ｃ）株取引すなわち取引フロア環境などのマルチ会話は、アクティブかつ同時にレンダリングする。
ｘ．ユーザに、全ての会話を記憶可能にし、望むなら、有形の表現媒体に持続的にアーカイブし、必要に応じ組織化、インデックス付け、検索、転記、翻訳および／またはレビューできる資産をレンダリングする。
ｘｉ．システムが、即座にレンダリングする上で「十分に良い」速度でメッセージを送達するうえで最善のモードを使って、リアルタイム通話機能をレンダリング可能にする（ＵＤＰと同様）。また、もともと記憶された完全なコピーから、紛失あるいは欠陥のあるデータの再送を要求し、最終的にメッセージの完全なコピーの送達を保証する（ＴＣＰと同様）。
ｘｉｉ．受信側のプレセンスおよび意図（すなわち、リアルタイムまたはタイムシフトモードでのメディアのレビュー）を使うと同時にネットワーク待ち時間、ネットワークの劣化、パケットの損失あるいはダメージおよび／または現在の回線容量の状態を測定し、システムに、適時性とメディアの質の間でトレードオフを行いネットワーク回線容量の利用を最適化することを可能とする。

種々の実施例において、上に挙げた様々な特徴や機能の一部又は全部が実施可能である。しかしながら、本発明の別の実施例においては、上に列挙した特徴や機能の全てを組み込む必要がないことは理解できよう。

［Ｂ．用語の解説］
本発明の詳細を説明するに先立ち、本明細書全体を通じて使用される幾つかの用語と略語を定義する。この用語解説は、システム構成、メディア、メディア管理、人と会話管理のグループに分類できる。

［Ｂ．１．システム構成］
クライアント：クライアントは、通信システムの中のユーザアプリケーションを意味し、ユーザインタフェース、持続的データ記憶装置、および「ヴォクシング（Ｖｏｘｉｎｇ）」機能を含む。ユーザは、クライアントアプリケーションと情報のやりとりをし、クライアントアプリケーションは、ネットワークを通じて送受信される全ての通信（メッセージおよび信号）およびペイロード（メディア）転送を管理する。クライアントは、メディアのエンコード（例えば、音声、ビデオまたは他のデータのコンテンツの取得）、メディアのレンダリングをサポートし、セキュリティ、暗号化、認証およびネットワーク上のデータ送信の最適化をサポートする。クライアントは１個ないし複数のユーザ（すなわち、マルチテナント）によって使用することもできる。

デバイス：クライアントアプリケーションを実行する物理的デバイス。ユーザは、一個のデバイスまたは複数のデバイスによって、所定のいずれの時点でもアクティブにログインすることができる。種々の実施例において、デバイスは、汎用コンピュータ、携帯計算機、プログラマブル電話機、プログラマブルラジオまたはその他のどんなプログラマブル通信装置であってもよい。

サーバ：通信ネットワーク上のコンピュータノード。サーバは、ネットワーク上のユーザ間でやり取りされる送信メッセージのルーティングおよびメディアペイロードの持続的記憶とアーカイブの役割を持つ。サーバは、ルーティング、トランスコーディング、セキュリティ、暗号化と認証およびネットワーク上のデータ送信の最適化を提供する。

［Ｂ．２．メディア］
メッセージ：あるユーザから他のユーザへの個々の通信単位。各メッセージは音声またはビデオ等の何らかのメディアからなる。各メッセージは、以下の属性のどれかを割り当てられる。（ｉ）メッセージ送信側のユーザ、（ｉｉ）所属している会話（ｉｉｉ）、オプション、またはユーザ作成の重要タグ、（ｉｖ）タイムスタンプ、（ｖ）メディアペイロード

メディア：音声、ビデオ、テキスト、位置、温度等のセンサの読取り値、その他のデータ。

会話：デバイス上で２人以上のユーザ間の一連の（識別され、持続的に記憶されグループ化され優先順位をつけられた）メッセージ。ユーザは、一般にデバイスを用いてリアルタイムまたはタイムシフトモードでメッセージをレビューするか、望みに応じて会話のメッセージを作成、送信することによって会話に参加する。新しいメッセージを作成すると、新しい会話を定義するか、既存の会話に加えられる。

会話のヘッド：直近の話者によってエンコードされた会話の直近のメッセージ。「ライブ」をレビューするとき、会話においてユーザが存在しているところ、すなわち「ライブへジャンプ」機能を使用する場合、ジャンプするところ。

多者間会話管理システム（ＭＣＭＳ）：クライアントアプリケーションの一部として実行するアプリケーションで、ユーザが様々なタイプのメディアを用いてマルチ会話に参加することを可能にする。現在の会話のメッセージのみがレンダリングされている場合、ユーザはＭＣＭＳアプリケーションを用いて、現時点として、マルチ会話の中から１つの会話を選択することができる。選択された現在の会話については、ユーザはタイムシフトモードでのメッセージの一連のやり取りから、標準的な電話会話と同様のほぼ同期性の「ライブ」モードに遷移でき、またタイムシフトモードに戻ることができる。選択されなかった会話のメッセージは休止状態に置かれる。他の人がまだこれらの会話参加している場合は、選択されなかった会話に関するメッセージは、蓄積されていく。ユーザは、マルチ会話の中から現在の会話に選択的に遷移し、選択された現在の会話の蓄積されたメッセージをレビューすることができる。

継続的多者間会話管理システム（ＭＣＭＳ−Ｃ）：付加されたレンダリング機能によって、システムによって自動的に管理される優先順位とタイムシフトの階層的なシステムを通じて、ＭＣＭＳと同様にユーザにマルチ会話を管理し継続して参加することを可能にする機能。現在選択されている会話メッセージのみをレンダリングできるＭＣＭＳとは異なり、ＭＣＭＳ−Ｃアプリケーションは、継続する会話のメッセージを、優先順位をつけた順序でレンダリングすることができる。ＭＣＭＳ−Ｃは特に次のような状況で利用できる。すなわち、継続する会話のメッセージを、優先順位をつけた順序でレンダリングすることが重要な場合、および／または低い優先順位の会話に属していても、全てのメッセージを受信することがリアルタイムでメッセージを受信するよりも重要な場合。ＭＣＭＳ−Ｃが適する状況の例としては、病院、タクシー全車両管理、戦術的通信などがあるが、これに限定されるものではない。

同時多者間会話管理システム（ＭＣＭＳ−Ｓ）：ＭＣＭＳと同様、選択された現在の会話だけのメッセージがレンダリングされるＭＣＭＳとは対照的に、追加機能によってＭＣＭＳ−Ｓを使って同時レンダリングするマルチ会話を選択可能にする。ＭＣＭＳ−Ｓアプリケーションは、一人のトレーダーが異なる為替について複数のブローカーに聞いており、一人ないし複数のブローカーに取引要請を時折送信しているような、１個のユーザがマルチ会話を同時に聞いている状況に、特に適用できる。また、ＭＣＭＳ−Ｓは戦術的通信にも適している。

優先順位：ユーザがＭＣＭＳ−Ｃに参加しているときに、つぎにどのメッセージをレンダリングするかシステムが決める機構。優先順位はシステムによって自動的に管理される。ユーザは、デフォルトで優先順位を設定できる、または予め決められた一組のシステム優先順位を使うこともできる。衝突が生じた場合、すなわち、１個以上のメッセージが同時にレンダリングされようとしているときは、システムは、少なくとも部分的に優先順位に基づいて衝突を解決し、どのメッセージを即座にレンダリングし、どのメッセージをタイムシフトするか決める。

タグ：ユーザまたはシステムが、会話またはメッセージに割り当てることができる一組の属性で、それによってデータを検索したり組織化したりできる、トピック（会社名）、命令（「動作項目」）、標識（「会話のサマリー」）、その他ラベル等。

重要タグ：他の優先順位の設定にかかわりなく、あるメッセージがレンダリングされるべきときに、送信側に指定可能とする特別のメッセージ属性。例えば、「緊急」の重要タグは、他の優先順位を無効にする。この機能は、戦術的なシステムにとっては重要な意味を持つが、どんなシステムでも、この機能を使えるようにしたり、無効にしたり設定することができる。

パケット：コンピュータネットワークを通じてルートを決めることができるバイナリデータの単位。各パケットは、ヘッダ（メタデータ）およびペイロード（メディアデータ）からなる。インターネットプロトコル（ＩＰ）、ＥｖＤＯ、ＵＭＴＳその他のパケットベースのネットワーク、無線、光ファイバー、有線のいずれかの標準的なパケットプロトコルが含まれるが、これに限定されものではない。

ヘッダまたはパケットヘッダ：パケットを記述するパケットの部分、ペイロードに関するメタデータ、エンコードのタイプおよび宛先。

Ｖｏｘパケット：システムと方法をさらに精緻化し、メッセージメディア、その他の信号情報の送達を最適化することを可能にする専用パケット。

メディアペイロード（またはペイロード）：パケットの実のメディア部分。

［Ｂ．３．メディアの管理］
タイムシフト遅延（ＴＳＤ）：Ｖｏｘパケットの着信とパケットのデバイス上でのレンダリングとの間の時間の量。ＴＳＤは最小タイムシフト遅延を上回らなければならない。ＴＳＤは、主として、受信後のユーザが会話のメッセージをレビュー選択しようとする動作によって決められる。

最小タイムシフト遅延（ＭＴＳＤ）：クライアントによって強制されるタイムシフト遅延で、ジッタバッファ技術を用いてジッタ加工することができるようにする。これは、使用可能なメディアストリーム作るのに適当な数のパケットが到着するまで、システムにレンダリングの遅延を行わせる。システムは、時間の経過に応じてＭＴＳＤを順応的に調節し、主としてネットワークにおける変動条件を補正する。

レンダリング：ユーザの消費に適した形式でユーザにメディアストリームを送達すること（例えば、音声、テキスト、グラフィック表示、ビデオ、またはそれらの組み合わせ）。

ミキシング：一またはそれ以上のメディアストリームをレンダリングすること。例えば、レンダリングするとき、会話の二人の参加者からのメディアストリームをミックスし、複数の人が同時に話しているのと同じ会話感覚をユーザに作ること。

エンコード：ユーザ作成の（音声またはビデオ）メディアか、デバイス上で別途生成される（ＧＰＳまたはその他のセンサデータ）メディアを翻訳し、クライアントによって処理されるようにメディアをデジタルデータに変換するプロセス。

適応ジッタバッファ：ジッタバッファまたはデジッタバッファを使い、ネットワークを切り換えたパケットによって導入されたジッタ（すなわち、シーケンスから外れたパケットの着信またはパケットの遅延着信）に対抗し、ネットワーク上を送信される音声（またはビデオ）信号の連続レンダリングが途切れずに行われるようにする。レンダリングする前に、データはバッファに記憶され、適当なサイズにされたメディアのバッファが着信できるようにする。質と流れのトレードオフを行うことによって、全てのパケットが受信される前にメディアをレンダリングすることができる。適応ジッタバッファは、サイズをダイナミックに変え、遅延−質トレードオフを最適化することができる。

無限連続メッセージバッファ（ＰＩＭＢ）：ＰＩＭＢは、タイムベースのメディアを記憶する記憶部の管理システムであり、「ライブ」データのジッタの削除とアーカイブされたデータの保存と取出しの両方を行う。さらに、ＰＩＭＢは付加的属性として、潜在的に無限にメディアの継続保存をおこなう。ＰＩＭＢは、一部又は全ての参加者のデバイスおよび／またはサーバにて、メッセージと会話のＶｏｘパケットを、「完全な」すなわちフルコピーで維持する。

パケット損失補償または隠蔽（ＰＬＣ）：メディアストリームをレンダリングする間に、ＰＬＣコンポーネントは、紛失パケットの補償を行い、結果を補間し、閲覧者にストリームを提供する。紛失パケットは沈黙としてレンダリングするか、近接するパケットからの情報を使い、補間した音またはイメージ提供することもできる。使用される個々の方法は、メディア、使用コードおよびその他一般に既知のパラメータによる。

［Ｂ．４．人］
ユーザ：システムを使う権限を与えられた人。

コンタクト：システムのユーザまたは非ユーザの記録。ユーザは、主としてコンタクトのリスト上のメンバーとともに会話に参加する。従来の電話、ラジオ又はその他の非クライアント１２が使用可能なデバイスを使ってシステムにアクセスまたはシステムを使うユーザは、非ユーザである。

グループ：多数のコンタクトの集まり。コンタクトは、グループに選択的に加えられたり、グループから削除したりできる。グループの中で会話が始まれば、グループの全てのメンバーは参加することもしないこともできる。

チャンネル：主として戦術的通信システムに使われる。チャンネルはグループと同様、チャンネルで多数のコンタクトを結び付ける。

参加者：会話のメンバーとして識別される人。ユーザまたは非ユーザが参加者になりうる。

［Ｂ．５．会話の管理］
タイムシフト：タイムシフトは、メッセージを受信した後、ユーザ受信者の判断によって、随時実行できる。タイムシフトによって、ユーザは、メッセージを下記の方法でレビューすることができる。（ｉ）ＭＴＳＤ後、オンデマンドで、即座にレンダリングする、（ｉｉ）ユーザの裁量により、タイムシフトモードでメッセージをレビューする、（ｉｉｉ）古い会話を検索、再構成のためにアーカイブから、（ｉｖ）別の優先順位の高いメッセージ（会話）のレビューに便宜を図るために一定の遅延時間の後、および／または、（ｖ）メッセージを再度聞いたり理解したりすることが必要な場合は繰り返して。言い換えれば、タイムシフトは、システムによってＭＴＳＤが強制された後、ユーザがメッセージを随時レンダリングできることである。

レビュー：メッセージの中のメディアのコンテンツを聞く、見る、読む、または閲覧すること。レビューは、ほぼ同期性のリアルタイム「ライブモード」かタイムシフトモードのいずれかで行うことができる。

意図：以下を把握するユーザ定義の属性；（ｉ）ユーザが会話のメッセージを即座にレビューしたいと望んでいるか、タイムシフトモードでメッセージをレビューしたいと望んでいるか、（ｉｉ）ユーザの動作に含まれている意思、または（ｉ）と（ｉｉ）の組み合わせ。

注意：現瞬間にユーザが所与の会話のメッセージをレビューしているか否かを把握するためのユーザの属性。

ライブにキャッチアップ（ＣＴＬ）：「ライブにキャッチアップ」ために、会話の頭にないユーザが、先行するメッセージをより早くレビューすることができる（すなわち、会話の頭に）、レンダリングモード。ＣＴＬ機能は、メッセージの早送り、メッセージのメディアの中にあるギャップの除去、躊躇粒子の除去等数多くあるキャッチアップ技術のうちどれを使っても良い。ユーザがライブに追いついたらシステムは途切れずにライブ会話に遷移する。これは、会議通話、例えばユーザが出席者の注意を一時的に会話から引き離し、再び戻ったときに全体の会話を聞きたい、といった状況のときに非常に役立つ機能である。

キャッチアップモード：ユーザ設定あるいは予め設定されたモードで、どのようにしてＣＴＬプロセスがキャッチアップするか決める（すなわち、もっと早く実行する、沈黙、躊躇粒子の除去またはそれらの組み合わせ）。

ライブへジャンプ（ＪＴＬ）：この機能により、ユーザは現在の位置から会話の頭へジャンプすることができる。ユーザが、会話における現在の位置と頭の間にある全てのメッセージをレビューすることを望まないとき主としてこのＪＴＬ機能を使う。ＪＴＬ機能を実行すると、ユーザは途中にある全てのメッセージをスキップし、会話の頭にある「ライブ」メッセージのレンダリングを開始する。

ＭＣＭＳ参加者の属性：所定の会話を行うためにユーザが定義し、ユーザの動作からシステムが解釈する、管理者が割り当てる一組の属性か、または、その組み合わせで受信側の意図、注意、優先順位、レンダリングの好みを定義する。属性には以下のものが含まれるが、これに限定されない。（ｉ）受信側が会話のメッセージに対してレンダリングしたいときの意図。可能性のある意図値には以下のものが含まれる：「今」、「タイムシフト」、「ライブにキャッチアップ」（ＣＴＬ）、「休止」、「決してない」など。（ｉｉ）キャッチアップモード。ＣＴＬプロセスがどのようにして受信側をライブにキャッチアップさせるかを決める設定（すなわち、早く実行する、沈黙ギャップ又は躊躇をスキップするまたは常用速度で実行する）。（ｉｉｉ）タイムシフト遅延（ＴＳＤ）、会話における受信側の現在位置が会話の頭からどれだけ離れているかを定義する。（ｉｖ）受信側における他の会話に関するメッセージの優先順位。

［Ｃ．システムアーキテクチャ］
図１は、本発明の一実施例に係わる通信とメディアの管理システムのブロック図を示す。システム１０は、デバイス１３_１ないし１３_ｎ上でそれぞれ動作する複数のクライアント１２_１ないし１２_ｎを含む。デバイス１３は、一またはそれ以上のサーバ１６を含む通信サービスネットワーク１４上で互いに通信を行う。一またはそれ以上のネットワーク１８_１ないし１８_ｎがレンダリングされて、複数のデバイス１３_１ないし１３_ｎを通信サービスネットワーク１４に連結する。様々な実施例において、ネットワーク１８は、公衆交換電話網ネットワーク（ＰＳＴＮ）、セルラーネットワークに基づくＣＤＭＡ又はＧＳＭ、例えば、インターネット、戦術的な無線ネットワーク、その他の通信ネットワーク、またはその組み合わせであっても良い。通信サービスネットワーク１４は、いろいろなネットワーク１８_１ないし１８_ｎとの通信のトップあるいはその中のネットワーク層である。様々な実施例においては、ネットワーク層１４は、異機種環境か同機種環境である。クライアント１２_１ないし１２_ｎは、「Ｖｏｘパケット」と呼ばれる以下に詳述する個人メッセージ装置を使って、ネットワーク１８_１ないし１８_ｎ上のサーバ１６、およびネットワーク１４と互いに通信を行う。

［Ｄ．クライアントアーキテクチャ］
図２Ａおよび２Ｂは、デバイス１３上で動作するクライアント１２のブロック図を示す。図２Ａに示すように、クライアント１２は、多者間会話管理システム（ＭＣＭＳ）アプリケーション２０、レンダリング−エンコードモジュール２１およびＭＣＭＳアプリケーションデータベース２２を含む。図２Ｂに示すように、クライアント１２は、永続的無限メッセージバッファ（ＰＩＭＢ）リーダ２６が付いた記憶・ストリーム（ＳＡＳ）モジュール２４、ＰＩＭＢ書込み部２８、ＰＩＭＢデータベース３０、データ・ネットワーク品質（ＤＮＱＳ）記憶部３２およびメディアドライバ・エンコダハードウェア３４をさらに含む。ＭＣＭＳアプリケーション２０と記憶・ストリームモジュール２４は、それぞれメッセージハンドリングモジュール２５ａおよび２５ｂを介して互いに通信を行う。クライアント１２は、さらに、認証−暗号化セキュリティモジュール４０および通信プロトコルモジュール４４を含む。

モジュール４０は、クライアント１２との間で「ヴォクス（Ｖｏｘ）」パケットの送受信を行う間、認証、暗号化およびセキュリティのサービスをレンダリングする。通信プロトコルモジュール４４は、Ｖｏｘパケットを、データを送信するときにクライアント１２を作動させ、データを受信するときにネイティブパケットからＶｏｘパケットをカプセルから取り出すデバイス１３に接続された下層のネットワーク１８によって使われるネイティブパケットにカプセル化する。モジュール４０および４４は、クライアント１２間での、マルチ端末同士の認証、暗号化およびセキュリティをレンダリングする。メッセージは、ネットワーク１８_１ないし１８_ｎとネットワーク１４上で、第一の送信デバイス１３から第二の受信デバイス１３まで、認証され、暗号化され、保全される。

［Ｄ．１．１．ＭＣＭＳデータベース］
データベース２２は、コンタクトおよび参加者、会話およびメッセージ（ライブ、保存済み）、初期設定の優先順位、およびサーバ１６に関する情報を含む、システム１０内の多くの要素のための永続性のメタデータを記憶、管理する。さらに、ＭＣＭＳデータベース２２は、ユーザの会話、プレゼンス、およびステータス等の逐次オペレーションデータやユーザと話をしている全ての参加者、およびユーザのコンタクトリスト上のオペレーションデータなどを記憶する。例えば、会話とメッセージに関しては、データベース２２は、会話のどのメッセージをユーザがレビューしたかまたはしなかったか、クライアント１２が参加者であった会話ごとの優先順位、およびライブ−キャッチアップステータスなどのステータス追跡情報を保持する。それには、プレゼンス、全ての参加者のステータス、および他のネットワークおよびシステムの管理データが含まれる。

［Ｄ．１．２．ＭＣＭＳアプリケーション］
ＭＣＭＳアプリケーション２０は、いろいろなメディアおよびデータタイプ（音声、ビデオ、テキスト、ロケーション、データなど）を用いて、参加している会話および／または管理しているマルチ会話のいろいろなヴォクシングモードサポートする。ユーザは、クライアント１２を可能にしたデバイス１３を使って指定された受信側にメッセージを送信することにより、会話に参加する。好み、優先順位よって、受信側は、リアルタイムでメッセージをレビューする、あるいは単にメッセージがレビューできる状態にあることに気がつく。ユーザは、タイムシフト（音声メッセージ）モードまたはほぼ同期性でレビューした一連のメッセージのやり取りから全二重の会話（標準的な「ライブ」通話と同じ）に遷移し、再び音声メッセージに戻ることができる。ＭＣＭＳアプリケーション２０は、別の進行中の会話の中のどのメッセージも失うことなく、ユーザがリアルタイムで最も重要な会話との相互作用をコントロールできるようにする。例えば、ＭＣＭＳアプリケーション２０は、現在レビューしていない会話の中から、緊急の通信すなわち優先順位の高い通信をユーザに通知する。また、ＭＣＭＳアプリケーション２０は、随時レビューができるように、後の検索のために全ての会話の全てのメッセージを記憶することを可能とする。

種々の実施例によれば、ＭＣＭＳアプリケーション２０には、以下のような幾つかの異なった動作モードがある。すなわち、それぞれメッセージの連続的なレンダリングと同時レンダリングをサポートする、ＭＣＭＳ−継続（ＭＣＭＳ−Ｃ）とＭＣＭＳ−同時（ＭＣＭＳ−Ｓ）である。それぞれの実施例について、以下詳細に説明する。特に断らない限り、用語「ＭＣＭＳ」は、一般に前記異なる２つのモードを含むＭＣＭＳアプリケーション２０を意味する。

ＭＣＭＳアプリケーション２０は、多くのモジュールとサービスを含む多層構造のアーキテクチャである。モジュールとサービスには、以下のものが含まれる。すなわち、ＭＣＭＳデータベースモジュール２０ａ、ＳＡＳサービスモジュール２０ｂ、メッセージ／信号サービスモジュール２０ｃ、ユーザインタフェースアプリケーション・プログラミングインタフェース（ＡＰＩ）２０ｄ、ユーザインタフェースモジュール２０ｅ、会話／メッセージ管理サービス部２０ｆ、優先順位サービス部２０ｇ、コンタクトサービス部２０ｈ、プレゼンス／ステータスサービス部２０ｉ、およびメッセージ／信号サービス２０ｊである。

［Ｄ．１．２．１ ＭＣＭＳデータベースモジュール］
ＭＣＭＳデータベースモジュール２０ａは、ＭＣＭＳアプリケーション２０がＭＣＭＳデータベース２２にアクセスするために必要な全ての機能コールを管理するサービスモジュールである。

［Ｄ．１．２．２ ＳＡＳサービスモジュール］
ＳＡＳサービスモジュール２０ｂは、ＭＣＭＳアプリケーション２０と記憶・ストリームモジュール２４との間の通信と調整を可能にする、それぞれメッセージハンドリングモジュール２５ａ、２５ｂを介してやり取りする一組の機能コールを含む。一組の機能コールは、ＭＣＭＳアプリケーション２０と記憶・ストリームモジュール２４の両者に必要に応じてユーザに呼び出されたときにいろいろなヴォクシング機能を動作させ、および／またはネットワークの状態によって指示されたように実行することを可能にする。ＳＡＳサービスモジュール２０ｂによって実行される機能の中にはメッセージ通信およびメッセージ認識のステータス、メッセージをレンダリングするための命令、およびユーザのステータスとプレゼンスの維持と通信が含まれる。

［Ｄ．１．２．３ メッセージ／信号サービスモジュール］
メッセージ／信号サービスモジュール２０ｃは、クライアント１２とサーバ１６の両者の上で動作し、システム１０のクライアント１２とサーバ１６との間で通信を可能とする。この通信は、メッセージ、データおよびその他の信号を含み、クライアント１２とシステム１０が、通信、ネットワークステータス、ユーザ、およびユーザステータスの追跡と管理ができるようにする。サーバ１６上で動作するクライアント１２とメッセージ／信号サービスモジュール２０ｃの間で送られるメッセージと信号のタイプは、例えば、以下を含む。すなわち、ユーザのネットワーク利用可能性、メッセージ全体またはメッセージの一部が失われていないか判断するためにサーバ１６がクライアント１２に送ったメッセージ（恐らく「高水位マーク」を含む）の追跡（例えば、「作成中の」クライアントによって作成された会話につき参加者当りのシーケンス番号）、ユーザが所定の会話のメッセージを話しているかまたはレビューしているかどうか、どこでユーザが会話の頭に関わっているか、いつ参加者が会話のライブをレビューしていないか、などである。これらは、クライアント１２上のメッセージ／信号サービスモジュールとサーバ１６との間で送られるメッセージと信号の多くのタイプの中の２、３の例であって、本発明はこれに限定されると解釈すべきではない。

［Ｄ．１．２．４ ユーザインタフェースＡＰＩ］
ユーザインタフェースＡＰＩ２０ｄは、ＭＣＭＳアプリケーション２０のユーザインタフェースモジュール２０ｅと下層サービスとの間のプログラミングインタフェースを定義する、一組の機能コールを定義するモジュールである。ユーザインタフェースＡＰＩ２０ｄは、ＵＩアプリケーションサポート、ユーザインタフェースがＭＣＭＳアプリケーション２０を作動させるために必要な全ての機能コールなどの汎用的方法サポートする。種々の実施例において、ユーザインタフェースＡＰＩ２０ｄは、クライアント１２が、以下にあげるの広範囲のユーザインタフェースとデバイスタイプをサポートすることを可能とする。すなわち、アドビフラッシュベースのアプリケーションおよび／またはマイクロソフト社のＷｉｎｄｏｗｓ（登録商標）アプリケーション、セルラーまたはモバイルホンデバイス、トーンで駆動されるＰＳＴＮデバイス、音声ユーザインタフェース（ＶＵＩ）、および物理的無線通信インタフェース等。種々の実施例において、ユーザインタフェースＡＰＩモジュール２０ｄは、高度のフレキシビリティと高度に制約されたユーザインタフェースの設計によってＭＣＭＳアプリケーション２０の機能性をサポートすることを可能とする。

［Ｄ．１．２．５ ＭＣＭＳユーザインタフェースモジュール］
ＭＣＭＳユーザインタフェースモジュール２０ｅは、クライアント１２の音声・ビデオユーザインタフェースの動作および機能をサポートする。ユーザインタフェースモジュール２０ｅは、ユーザ相互作用のホストをサポートし、下記のさまざまな相互作用媒体で実現することができる。すなわち、デバイス１３上のグラフィカルユーザインタフェース・スクリーン、音声／ＤＴＭＦインタフェース、音声ユーザインタフェースで、その全てのがユーザに、システム１０とインタフェースで接続することを可能にする。サポートされるユーザ相互作用の一部リストは以下を含む。例えば、機能する；ログインする；会話を管理する、参加する、モニタする；会話のレンダリングをコントロールする；優先順位を管理する；会話をアーカイブしたレビューすることを要求する。このリストは、例示としてあげたものであり、本発明を限定するものと解釈されるべきではない。

［Ｄ．１．２．６ 会話／メッセージ管理サービス］
会話／メッセージ管理サービス部２０ｆは、一組の機能を定義するモジュールである。これは、ユーザが会話の参加者間で送受信したメディア（例えば、音声またはビデオコンテンツメッセージ）の受信とレビューを管理するうえで必要とする全ての情報を管理、保持する役目のデータ構造および処理を管理する。メッセージは、会話に組織される。アプリケーション１２を実行しているデバイス１３によって送受信されたメディアは、受信中に即座にレビューすることができる。また、受信メディアは、タイムシフトモードでレビューするため、会話管理、およびアーカイブする目的で、記録される。他の実施例においては、メッセージまたは会話は、希望の保持条件を指定して、オプションとして一時的にマーク付けすることもできる（例えば、一部のメッセージは、即座のレンダリング要求を無視して、保持または記憶されない）。さらに他の実施例においては、メディアはタイムシフトモードだけでレビューする目的でオプションとしてマーク付けされ、受信後即座にレビューすることはできない。

会話／メッセージ管理サービス部２０ｆは、さらにユーザの現在の会話すなわち進行中の会話をそれぞれ随時受信中のクライアント１２にメディアを送信可能にし、受信側の動作に関わらず、受信中のクライアント１２は、これらのメッセージを適当な会話を切れ目なく結び付ける。

会話／メッセージ管理サービス部２０ｆにより、全ての会話は基本的に非同期性となる。もし、二つのユーザが所定の会話にアクティブに加わり、および通信間のユーザ制御の遅延が最小であれば、現在の電話またはＶｏＩＰ会話と同じく、非同期の全二重の会話となる。もし、どちらか一方のユーザの参加が遅れた場合、理由のいかんを問わず、会話は非同期の音声（またはその他のメディア）メッセージにドリフトする。代替的な実施例においては、会話は、非同期のメッセージのみあるいは同期メッセージのみとしてオプション的にタグ付けすることができる。これらのケースのどちらか一方においては、タグ付けがリセットされない限り、会話は二つのモードの間でドリフトすることはできない。タグ付けのリセット後は、会話は、ほぼ同期性（すなわち、ライブまたはリアルタイム）と非同期（すなわち、タイムシフトされたメッセージまたは音声メッセージ）モードの間で再度流れることができる。

会話／メッセージ管理サービス部２０ｆは、漸次メッセージの送受信の処理を行う。送信するとき、メディアが作成されても良く、メッセージは同時にエンコード、記憶され、送信される。すなわち、メッセージの送信は、ユーザによるメディアの生成と同時に（すなわち、デバイス１３に話す間、またはビデオ生成中に）始まっても良い。受信サイドでは、メッセージの受信、記憶およびレンダリングの全てのが漸次行われる。メッセージは、レンダリングされる前は、完全に受信される必要はない。メッセージのレンダリングは、メッセージがＭＴＳＤまで送達されると同時に始まっても良い。さらに、サービス２０ｆは、出力メッセージの送信と入力メッセージのレンダリングを同時に行うことができる。サービス２０ｆの漸次性により、ユーザは後の検索とレビューのために会話のメディアの記憶とストリーム中に、ここに記述するその他機能も同様、ライブ会話に参加することができる。

会話／メッセージ管理サービス部２０ｆによるメッセージのタイムシフトによって、もし、先行するメッセージを逃したときまたは他の会話に加わっていたとき、ユーザは、会話に「ライブにキャッチアップ」することができる。このタイムシフト処理により、ユーザは、グループ全体またはチャンネル全体にメッセージを繰り返してくれるように要求を出す必要がなくなる。古いメッセージは、時間を節約するために、可能性として高速で随時再生することができる。ユーザはメンバーのメッセージや個人のメッセージを簡単に行ったり来たりスキップできる。レビュープロセスは、低い優先順位のメッセージを潜在的にスキップするようにメッセージ優先順位ベースで構成することもできる。

一実施例において、会話／メッセージ管理サービス部２０ｆは、特定の参加者（話者）によってメッセージを識別し、同時に送達された会話のメッセージをデフォルトで混合する（ＭＣＭＳ−Ｓ）。任意の実施例において、ユーザは異なる会話の参加話者の通信を別個にレビューすることもできる。

さらに会話／メッセージ管理モジュール２０ｆは、参加者同士で会話を共有することができ、その参加者をアクティブ会話またはアーカイブの会話に加えることができる。一実施例において、会話に加えられた参加者は、会話へのアクセスが与えられ、その会話の先行のメッセージを取り出しレビューすることができる。他の実施例においては、加えた参加者は、その会話のメッセージに対してのみ、その新しい参加者が加わるポイントからアクセスが与えられ、その会話先行するメッセージに対するアクセスは与えられない。

また、会話／メッセージ管理モジュール２０ｆは、記憶・ストリームモジュール２４によって実行される全てのレンダリングするタスクをコントロールするために使う機能を管理する役割を持つ。これらのタスクには、アプリケーション１２を実行するデバイス１３に適切にメディア（すなわち、音声、ビデオ等）をレンダリングすることが含まれる。これらのレンダリングタスクには以下が含まれるがそれに限定されない。すなわち、ミックスしたメッセージ（すなわち、メッセージのオーバラップ）をレンダリングするとともに、ユーザ定義の基準に従い、早送り、ライブへキャッチアップ、沈黙の除去、躊躇粒子の除去、周波数シフトをレンダリングすること、およびマルチ会話における個人の送信側に対する独立のゲインコントロール適用すること。

［Ｄ．１．２．７ 優先順位サービス］
優先順位サービス部２０ｇは、一組の機能を定義するモジュールである。この一組の機能は、ユーザが、ユーザが関与する継続する会話（すなわち、ＭＣＭＳ−Ｃ）の優先順位を管理するうえで必要な全ての情報を管理保持する役割を持つデータ構造および処理を管理する。ユーザが継続的な多角ライブ会話に参加するときは、ユーザはその会話に優先順位をつけることを求められる。異なる会話のメッセージが同時にレンダリングできる状態になると、問題が起こる。アルゴリズムを使い、メッセージがレンダリングされる順序を判断し、レンダリングされるメッセージの利用可能性とユーザによってセットされた優先順位を考慮する。アルゴリズムは、最も高い優先順位をもった利用可能なメッセージを決めて最初にレンダリングし、一方、同時に利用可能なメッセージは、自動的にタイムシフトされ、高い優先順位のメッセージレンダリングできるようにする。レンダリングが可能になれば、システムは、タイムシフトされたメッセージを、ユーザの優先順位に従い自動的にレンダリングする。

［Ｄ．１．２．８ コンタクトサービス］
コンタクトサービス部２０ｈは、一組の機能を定義するモジュールである。この一組の機能は、一またはそれ以上のコンタクトを認証し、会話と関連づけるうえで必要な全ての情報を管理、保持する役割のデータ構造および処理を管理する。多数のコンタクトと関連づけられた会話の部分としてメッセージを送信するときは、全てのコンタクトがメッセージを受信する。

［Ｄ．１．２．９ プレゼンス／ステータスサービス］
プレゼンス／ステータスサービス部２０ｉは、一組の機能を定義するモジュールである。この一組の機能は、プレゼンス情報とステータス情報を管理し、システムの特定のユーザおよび／または 非ユーザと共有する役割のデータの構造と処理を維持する。種々の実施例において、プレゼンス情報とステータス情報は、クライアント１２のユーザに関わる会話に参加する全てのユーザと非ユーザ、コンタクトリストの全てのユーザと非ユーザ、または、予め定義するされたドメイン内のユーザ（例えば、会社またはその他の組織のメンバー）のために維持される。これらの例は、単に例示として挙げたものであり、限定と解釈されるべきではない。プレゼンス／ステータスサービス部２０ｉモジュールは、ユーザおよび／または非ユーザの組を定義するプレゼンス情報とステータス情報を管理、共有することもできる。

プレゼンス／ステータスサービス部２０ｉは、他のユーザの意図のステータス、注意、および所定の会話のタイムシフト遅延（すなわち、ライブの会話のメッセージをレビューすることからどれだけ遅れているか）をユーザにモニタすることを可能とする。一実施例において、プレゼンスとデータ状態の利用可能性について、プライバシーコントロールが提供されている。さらにプレゼンス／ステータスサービス部２０ｉは、システム１０が、ユーザの動作と意図にマッチするメッセージを送達することを可能とするデータをコントロールする。例えば、ユーザは、会話のライブをレビューするかしないか意図を指定することによって自分のステータスを示すことができる。応答として、プレゼンス／ステータスサービス部２０ｉは、ユーザの意図に従って、「ライブ」またはタイムシフトでメッセージをレンダリングさせるコマンドを発する。さらに、ユーザの意図は、その会話の他の参加者と共有される。また、サービス２０ｉは、ユーザの動作からその他のステータス値を推論することが可能である。プレゼンス情報およびステータス情報は、以下に詳しく記述するように、ネットワークのトラフィックと帯域幅を最適化する目的で使われる。

［Ｄ．１．２．１０ メッセージ／信号サービス］
メッセージ／信号サービス２０ｊは、一組の機能を定義するモジュールである。この機能は、システム１０のユーザに特別のメッセージまたは聞こえる音を使ってシステム１０のユーザにメッセージと信号を発する役目のデータ構造と処理を管理する。特別のメッセージまたは音は、例えば一個または複数のメッセージがライブかタイムシフトかの指示、どこからのメッセージか、優先度、その他のファクタを含んでも良い。メッセージ／信号サービス２０ｊは、さらに以下の能力を持つ。（ｉ）ネットワーク上にユーザが存在しているか否かを信号で知らせる。またもしユーザがもう会話のメッセージをアクティブにレビューしていないときは、通知することができる。（ｉｉ）ユーザが別の会話に注意を奪われているときまたは自分のデバイス１３に全く注意払っていないとき、「リング」または別の方法で通知する。（ｉｉｉ）ユーザがネットワーク１８上にいない場合はメッセージを残し、次回ユーザがネットワーク１８に接続したときに即座にメッセージをレビューすることを促す。（ｉｖ）音響または視覚のフィードバックを生成し、送ったメッセージが受信側に受信されなかったことを送信側に警告する、メッセージが受信側に受信されたときおよび／またはメッセージが受信側に聞かれたときは、確認を生成する。（ｖ）会議または戦術的なコールに加わっている人々が当コールに即座に注意を払う必要がある場合、優先順位スキームを実行する。この表示は、受信側による様々なレベルの緊急性または何らかの確認を伝達しても良い。

［Ｄ．１．２．１１ レンダリング・エンコード］
レンダリング−エンコードモジュール２１は、ＭＣＭＳアプリケーション２０のための全てのレンダリングタスクを実行する役割をもつ。これらのタスクには、アプリケーション１２を実行するデバイス１３に適したレンダリングメディアが含まれる。

［Ｄ．２ 記憶・ストリームモジュール］
記憶・ストリームモジュール２４は、以下に説明するように多くの機能とパフォーマンス属性をサポートする。

記憶・ストリームモジュール２４は、メッセージは基本的に「全二重」で送信され、相手方もメッセージを送信中であっても、また、もし相手が出られないまたは別の通信に加わっていても、何れの当事者にも随時メッセージを送信可能にする。記憶・ストリームモジュールは、ライブのＰＳＴＮまたはＶｏＩＰコールと同じように、メッセージをレンダリングし、タイムシフトメッセージモードのためのメッセージを送達することができる。ユーザの希望に従い、送信を最適化し、レンダリングをコントロールすることができる。

記憶・ストリームモジュール２４は、下層のネットワーク１８上の全てのターゲットの受信側（例えば、サーバ１６、その他のデバイス１３）との接続性を維持し、全てのメッセージ、信号、およびメディアの通信を管理し、ネットワーク１８の送達速度と帯域幅を最適化し、ネットワークの品質と容量を管理しながらユーザの現下のパフォーマンス必要条件を満足する。モジュール２４は、下層のネットワーク１８の質と容量と釣り合いのとれたメディアの送達を調節し、最適化する。下層のネットワークための資源が不十分な場合は、送信するメディアストリームの質を下げることができる。帯域幅の回復しだい、送信するメディアストリームの質を上げることもできる。メディアの質のトレードオフに加え、記憶・ストリームの機能により、以下に記述するように、データをリアルタイムでレンダリングしようとするユーザの意図に基づいて、各パケットで送信するメディアの量をトレードオフすることができる。

下層のネットワーク１８の状態に基づいて、メディアの送達速度を動的にコントロールすることにより、記憶・ストリームモジュール２４は最適化され、受信したときにレンダリングする上で「十分に良い」時間的制約のあるメディアの送達を行い、紛失、質が低い、またはダメージを受けたパケットの再送を要求するバックグラウンドのプロセスを通じて、アーカイブする目的のそのメディアの正確なすなわち完全なコピーが最終的に送達されることを保証する。最低限のメディアの品質レベルを満足するだけのネットワーク資源がある限り、この再送は、ライブコールでのメディアのレンダリングを妨げることはない。このように、システム１０のクライアント１２は、相当な潜在的待ち時間を犠牲にしたメディアの正確なすなわち完全なコピーの送達と完全性の保証はないがメディア素早い送達との間のパフォーマンスギャップを橋渡しするように設計されている。本アプリケーションの文脈において、用語「十分に良い」とは、メディアの質が、レンダリングされたときに理解できる、ということを意味する。したがって、「十分に良い」の概念は主観的なものであって、絶対的な用語として解釈されるべきではない。例えば、あるメディアの十分に良い質のレベルは、メディアのタイプ、状況、その他のファクタによって変わりうる。

さらに、記憶・ストリームモジュール２４は、デバイス１３を使って別途生成された、または、ネットワーク１８上で別のデバイス１３および／またはユーザから受信された全てのメディアを持続的に記憶する。クライアント１２を実行するデバイス１３上でこのメディアを記憶することは幾つかの大きな利点がある。（ｉ）送信側および／または受信側が出られないまたはネットワーク接続性が貧弱である場合でも、ユーザは相手方にメッセージを残すことが可能となる。帯域幅が不十分なケースでは、メッセージは帯域幅が効果的に使える限り早く送信される。接続性が不要のケースでは、メッセージは、送信待ちのキューに並び、ネットワークの接続が使用可能になると即座にタイムシフトの送達がおこなわれる。（ｉｉ）ユーザは、ポーズ、リプレイ、早送り、ライブの進行中の会話にキャッチアップができると同時に、アーカイブされた先行する会話のメッセージを取り出しレビューすることができる。（ｉｉｉ）時々起こるネットワーク回線容量および接続性の問題にたいしてシステム１０上のデータペイロードの最適化とシステムの復元力を向上することが可能となる。

また、記憶・ストリームモジュール２４は、下記の役割をもつ。多数の参加者が話している実際の会話をシミュレートして、メッセージを適切にミキシングし、オーバラップメッセージ（会話における話者等の通常のオーバラップまたはバックグラウンドのノイズで生成される）を作成する、音声メディアの解説または翻訳をレンダリングすること、早送り、発話間の沈黙ギャップの除去、躊躇粒子の除去、周波数シフトをを含む多数のユーザ定義の基準に従ってメディアのレンダリングを調節すること、マルチ会話における個人の送信側に対する個別のゲインコントロールを適用すること能力を持つこと及び潜在的なレンダリングオプションをもつ。

記憶・ストリームモジュール２４は、それ自身とＭＣＭＳとの間のコントロールおよび情報メッセージを管理する。

［Ｄ．２．１ 永続的無限メッセージバッファ（ＰＩＭＢ）］
永続的無限メッセージバッファ又はＰＩＭＢ３０は、一組のインデックスされた（すなわち、タイムスタンプ付け、順番に番号付け）メディアペイロードデータの構造、およびその記憶と取出しのためのシステムである。一実施例において、ＰＩＭＢ３０内のデータは、永久にあるいは少なくともシステムの記憶装置がいっぱいになるまで、使用可能であるという意味で、実質的に永続性をもつ。記憶資源を有効利用するために、様々な保持率と方策を採用することができる。ＰＩＭＢ３０の物理的記憶を実施するには下記のような様々な方法があるが、これに限定されない。すなわち、ＲＡＭ、フラッシュメモリ、ハードドライブ、光学メディア、またはその幾つかの組み合わせ。ＰＩＭＢ３０も、ＰＩＭＢ３０に記憶できるデータの量は本質的に限定されないという意味で、サイズ的に「限定」である。この限定がないということは、レンダリング後即座にデータを廃棄する現在のジッタバッファ技術との比較の上でのことである。特定の実施例において、ＰＩＭＢ３０は、持続的記憶用のハードドライブと連結された小さくて比較的早いＲＡＭキャシュメモリを使って実現することもできる。ＰＩＭＢ３０の物理的記憶容量を超えた場合、オンデマンドでの後の検索のために、データはサーバ１６に保持される（以下に記述する）。何れの時点でも、ＰＩＭＢ３０に記憶された実際のデータまたはサーバ１６、またはアーカイブされたデータは、ユーザ基準または「最も古く使われた」、又は、「先入れ後出し」等の入れ替えアルゴリズムを使ってコントロールされる。さらに、ＰＩＭＢ３０は、ファイルシステム保存の属性およびランダムアクセスの属性のレンダリングをおこなう。それぞれのメッセージの期間または数にかかわらず、どんな数の会話でも記憶でき、後で検索してレビューすることができる。さらに、作成源、長さといった、会話のメッセージと関係するメタデータもＰＩＭＢ３０に記憶することができる。他の実施例においては、インデックスかされたメディアペイロードおよび他のデータは、指定の期間（例えば、３０日）記憶することができる。メディアが指定の期間を超えると、ペイロードとデータは廃棄される。別の実施例においては、ペイロードを含むメッセージの送信側および／または受信側、またはペイロードに関わる会話またはメッセージのトピックに基づいてペイロードは廃棄することができる。さらにその他実施例においては、ペイロードおよびデータは一時的にマーク付けされ、メッセージは、即座のレンダリングの要件を超えて、ＰＩＭＢ３０に記憶されない。

［Ｄ．２．２ データ・ネットワーク品質記憶部］
データ・ネットワーク品質記憶部（ＤＮＱＳ）３２は、ＰＩＭＢ３０から読み取られ、ＰＩＭＢ３０に書き込まれるメディアペイロードとＶｏｘパケットに関する情報を記憶するためのデータ記憶部である。

［Ｄ．２．３ ＰＩＭＢ書込み部］
ＰＩＭＢ書込み部２８は、二つの基本的目的のためにデータをＰＩＭＢ３０に書込む。ＰＩＭＢ書込み部２８は、クライアント１２を実行するデバイス１３上のメディア取得デバイス（例えば、マイクまたはカメラ）からのデータを書込む（「エンコード受信」）。また、ＰＩＭＢ書込み部２８は、他のクライアント１２からネットワーク１８を通じて受信したデータを書込むＰＩＭＢ３０（「ネット受信」）。

［Ｄ．２．３．１ エンコード受信］
デバイス１３からメディアを取得するために、ＰＩＭＢ書込み部２８は、エンコーダ受信部２８ａとデータ記憶部２８ｃを含む。例えば、あるユーザがマイクに話かける、あるいは、デバイス１３でビデオメッセージを生成すると、ハードウェア３４が生の音声および／またはビデオ信号を受信し、それをインデックスされたメディアペイロードにエンコードするエンコーダ受信部２８ａにレンダリングする（以下、単に「ペイロード」と称する場合もある）。データ記憶部２８ｃはそのペイロードをＰＩＭＢ３０に記憶する。センサデータ等のその他のタイプのメディアは、同様の仕方でペイロードに変換される。

［Ｄ．２．３．２ ネット受信］
ネットワーク１８を通じて受信メディアをＰＩＭＢ３０に記憶するため、ＰＩＭＢ書込み部２８のネット受信機能は、ネットワーク受信部２８ｄ、データバッファ部２８ｅ、データ記憶部２８ｆ、データ品質管理部２８ｇおよびネットワーク品質管理部２８ｈを含む。ネットワーク受信部２８ｄは、ネットワーク１８を通じてＶｏｘパケットを受信する。データバッファ部２８ｅは、受信したＶｏｘパケットを正しい順序に置き、入ってくるＶｏｘパケットのレンダリングの少なくとも最小タイムシフト遅延（ＭＴＳＤ）を防ぐ。データ記憶部２８ｆは、パケットをインデックスされたメディアペイロードに変換し、インデックスされたメディアペイロードをＰＩＭＢ３０に記憶する。ペイロードが記憶されと、データ品質管理部（ＤＱＭ）２８ｇは、紛失パケットあるいは欠陥パケットがないか監視する。もし紛失パケットや欠陥があるがある場合は、ＤＱＭ２８ｇはネットワーク１８を通じて再送要求を予約する。送信側のデバイスは、これに応えて紛失パケットまたは欠陥パケットを再送する。最終的にはこれらのパケットは、インデックスされたメディアペイロードに変換され、ＰＩＭＢ３０に記憶される。紛失パケットまたは欠陥パケットを取出すことによって、送信側のメッセージの「正確な」コピーは最終的にはＰＩＭＢ３０に記憶される。紛失パケットおよび／または欠陥パケットの再送によって、メッセージのリアルタイムのレンダリングに遅延を生じることはなく、送達されレンダリングされたパケットは「十分に良い」品質と量となる。新しい「ライブ」データと再送サポートするだけの十分なネットワーク資源がない場合は、ＤＱＭ２８ｇによって再送要求が遅延される場合もある。

［Ｄ．２．４ ＰＩＭＢ読取り部］
ＰＩＭＢ読取り部２６は、二つの基本的目的のためにＰＩＭＢ３０からデータを読取る。データがローカルクライアント１２向けにレンダリングされる場合は（「レンダリングする」）、ＰＩＭＢ読取り部２６はＰＩＭＢ３０にアクセスする。データがクライアント１２によってネットワーク１８を通じて送信される場合も（「送信」）、データはＰＩＭＢ３０から読取撮られる。

［Ｄ．２．４．１ レンダリング］
クライアント１２上のメッセージをレンダリングするために、ＰＩＭＢ読取り部２６は、データ優先順位付与部２６ａ、データ取出し部２６ｂ、パケット損失補償／補間部（「ＰＬＣ／補間部」）２６ｃ、データミックス部２６ｄおよびデータレンダ部２６ｅを含む。データ優先順位付与部２６ａは、レンダリングされるデータに優先順位をつけ、潜在的にレンダリングされる可能性のあるメッセージを順序付けられたキューを作る。これは、ユーザ設定の優先順位を使い、継続会話（ＭＣＭＳ−Ｃ）をレンダリングする。さらに、データ優先順位付与部はメディアデータの利用可能性を使い、ＭＴＳＤ、ユーザの現在の注意、ユーザが定義、含意する意図によって強制される制限内にレンダリングする。データ取出し部２６ｂは、ＰＩＭＢ３０から優先順位付けされたインデックスされたメディアペイロードを取り出す。ＰＬＣ／補間部２６ｃは、既知のパケット損失補償と補間アルゴリズムを使って取り出したペイロードにパケット損失補償および補間を実行する。使われる個々の方法は現在使われているメディアコーデックおよびその他既知のパラメータによる。ミックス部２６ｄは、適切にミックスして一個の会話のなかの多数のメッセージを使って同時データストリームを作るのに使われる。例えば、もし、二人以上の会話参加者が同時に話しているときは、ミックス部２６ｄは、同時に話している参加者の効果も作成してメッセージミックスする。代替的な実施例においては、ユーザは、オプションとして、一人の参加者の多数のストリームを一時にレビューすることもできる。もし、会話の中の一人の参加者のみが話している場合は、ミックス部２６ｄは、ミキシングを行なわずに一個ののメッセージストリームをパスしても良い。レンダ部２６ｅは、ミックス部モジュール２６ｄからデータを取り出し、それをハードウェアドライバ３４に適したフォームに変換する。ハードウェア３４は、メディアのタイプ、作成する音声、ビデオ、その他デバイス１３上の音響および／または視覚警報装置によって、デバイス１３のスピーカーまたはビデオ表示部を駆動する。

［Ｄ．２．４．２ 送信］
ネットワーク１８を通じてクライアント１２から送信するメッセージを作成するために、ＰＩＭＢ読取り部２６はデータ優先順位付与部２６ｆ、パケット品質管理部（ＰＱＭ）２６ｇ、データ読取り部２６ｈ、パケット部２６ｉ、送信部２６ｊおよび認証部２６ｋを含む。データ優先順位付与部２６ｆは、ネットワーク１８を通じて送信するメッセージに優先順位をつける。優先順位は、送信できるペイロードに関するＭＣＭＳ参加者の属性、ネットワークの接続性と回線容量の状態、およびライブまたはタイムシフトでレンダリングする次のホップの向こう側にいるおよびユーザの意図、そして、幾つかの実施例においては、次の所定のネットワークホップに対する多数のパケットが利用できる場合には、送信組立の可能な最適化、を使って判断される。次に、以下に詳述するように、優先順位をつけられたパケットは、ライブメッセージを行ううえで「十分に良い」品質のデータをタイムリーに送達することを確実にするＰＱＭ２６ｇを使ってリアルタイムの帯域幅を最小化しながら最適化される。データ読取り部２６ｈは、ＰＩＭＢ３０から適切なペイロードを取り出す。パケット部２６ｉは、ペイロードをＶｏｘパケットに組立て、Ｖｏｘパケットは次にネットワーク１８を通じて送信部モジュール２６ｊによって送信される。受信側がＶｏｘパケットを受信すると、ネットワーク１８を通じて認証部２６ｋに確認が送られ、メッセージが宛先に着信したことを送信側のユーザに通知する。

［Ｄ．２．５ パケット品質管理部］
ＰＱＭ２６ｇには、以下の最適化目標がある。（ｉ）時間的制約のあるメディアの適切なコピー（レンダリングするうえで「即座に、十分に良い」）をタイムリーに送達すること；（ｉｉ）最適な送信周波数、ペイロードの品質、および下層のネットワークのための最適なパケットサイズを使って使用可能な帯域幅を有効に使うこと；および（ｉｉｉ）送信周波数、ペイロードのコンテンツ、ペイロードの品質、パケットのサイズ等をネットワークの状態変化に応じて動的に調節する、または変更すること。

［Ｄ．２．６ ネットワーク品質管理部］
ネットワーク送信の受信サイドにはネットワーク品質管理部２８ｈ（ＮＱＭ）がある。ＮＱＭは、実際値に対するジッタ、損失、および処理量の期待値を比較して、クライアント１２にメディアを送った各送信側のためのネットワークのパフォーマンスの特定の特性を監視する役割を持つ。全ての送信側のネットワーク品質レート（ＮＱＲ）を計算するために使われる。ＮＱＲは受信側のデバイスのユーザに送信側の利用可能性および会話のライブ度を示すために使われる。

［Ｄ．２．７ データ品質管理部］
データ品質管理部２８ｇは、パケット損失、ジッタ、処理量を監視して、ネットワークを通じて受信中のデータの品質を測定する。ＤＱＭ２８ｇはこれらの測定値を３つ目的のために使う：（ｉ）送信側に受信レポートを送り返す；（ｉｉ）オプションとして、これらの受信レポートを使って特定のデータの再送を要求する；および（ｉｉｉ）これらの測定値をＮＱＭ２８ｈが利用できるようにする。

［Ｅ．サーバアーキテクチャ］
図３はサーバ１６上で実行するアプリケーション７８のブロック図である。アプリケーション７８は、多くの点でクライアントアプリケーション１２と同様であり、以下を含む。すなわち、ＭＣＭＳサーバアプリケーション８０、ＭＣＭＳデータベース８２、記憶・ストリームモジュール８４、ＰＩＭＢ８５、データ・ネットワーク品質記憶部（ＤＮＱＳ）８６、ＭＣＭＳサーバアプリケーション８０と記憶・ストリームモジュール８４の間を行き来するメッセージと信号を管理するＭＣＭＳ−ＳＡＳメッセージハンドリングモジュール８７ａ、８７ｂ、アーカイブ／取出し部８８、およびアーカイブ部８９。さらに、アプリケーション７８は、認証−暗号化セキュリティモジュール４０および通信プロトコルモジュール４４を含む。

ＭＣＭＳサーバアプリケーション８０は多層構造のアーキテクチャであって、以下を含む。すなわち、ＭＣＭＳデータベースモジュール２０ａ、記憶・ストリーム（ＳＡＳ）モジュール２０ｂ、メッセージ・信号モジュール２０ｃ、会話／メッセージ管理サービス部２０ｆ、優先順位サービス部２０ｇ、コンタクト（ユーザと認証を含む）サービス部２０ｈ、プレゼンス／ステータスサービス部２０ｉおよびメッセージ／信号サービス部２０を含む。クライアント１２と同じ参照番号を持つアプリケーション７８の前記モジュールおよびサービス部はクライアント１２の同じ参照番号を持つモジュールおよびサービス部と同様もしくは同じであり、したがって注意すべき例外を除きここでは詳しい記述を省く。種々の実施例において、ＭＣＭＳデータベース８２を含むＭＣＭＳサーバアプリケーション８０および記憶・ストリームモジュール８４は、アプリケーションの一例として、多数のユーザをサポートするように構成されている。さらに、この例は、ユーザのグループとして定義される多数のドメインをサポートするように構成されてもよい（例えば、会社または共通の組織に所属するユーザその他のグループ）。このアーキテクチャは、サーバ１６上の各アプリケーション７８が、各ユーザ（またはドメイン）が他のユーザには見えない多数のユーザ（またはドメイン）に使えるようにしてもよい。この区切り方は「マルチテナント」と呼ばれる。

記憶・ストリームモジュール８４はネット受信と送信の機能を実行する。ネット受信機能用として、モジュール８４は、ネットワーク受信部２８ｄ、データバッファ部２８ｅ、データ記憶部２８ｆ、データ品質管理部（ＤＱＭ）２８ｇ、およびネットワーク品質管理部２８ｈを含む。送信機能用として、モジュール８４は、データ優先順位付与部２６ｆ、パケット最適化部２６ｇ、データ読取り部２６ｈ、パケット部２６ｉ、送信部２６ｊおよび認証部２６ｋを含む。記憶・ストリームモジュール８４の上記の構成要素は、クライアント１２の同じ参照番号を持つ構成要素と同様又は同じである。したがって、それらの詳しい記述は割愛する。

サーバ１６はユーザと直接情報のやりとりはしないので、クライアント１２の記憶・ストリームモジュール２４に与えられたエンコードとレンダリング機能は、必要としない。ＭＣＭＳアプリケーション８０は、サーバ１６上で動作するときは、ユーザと直接やり取りはしない。したがって、ユーザインタフェース、および ユーザインタフェースＡＰＩモジュールおよびサービス部２０ｅ、２０ｄは必要ない。

各サーバ１６上のアプリケーション７８は、潜在的に多数のテナントに関与する。つまり、システム１０の多数のユーザに関与する。サーバアプリケーション７８のＰＩＭＢ８５は、したがって、一個ののユーザのみの生成されたまたは受信したペイロードだけを記憶するために使われるＰＩＭＢ３０とは異なり、相当に大きく、また、多数のユーザのメディアペイロードを記憶するために使われる。記憶・ストリームモジュール８４の主な目的は、クライアント１２によって送信されるメッセージを受信することと他のクライアント１２にメッセージを送信することである。メッセージが受信されると、ＰＩＭＢ８５に記憶されるとともに、目的の受信側またはシステムの構成に直接依存する受信側への経路に沿って、ネットワーク層１４の次のサーバ１６（すなわち、ネット「ホップ」）へ送信される。アーカイブ／取出し部８８は、アーカイブ部８９内のＰＩＭＢ８５に記憶されたメディアのペイロードをアーカイブする役割を持つ。ＰＩＭＢ８５内の物理的スペースがなくなると、ＰＩＭＢ８５内のメディアのペイロードは大量記憶デバイスであるアーカイブ部８９へ移される。種々の実施例においては、ＰＩＭＢ８５に記憶されたペイロードは、ユーザ定義の基準および／または先入れ先出し（ＦＩＦＯ）または最後に使われた（ＬＲＵ）等の既知の入れ替えアルゴリズムに従ってアーカイブされる。解りやすくするために、図１には、一個のサーバ１６のみが示されている。実際の実施例においては、複数のサーバまたは「サーバファーム」は、多数のユーザとのネットワークのために使われる。

ＰＩＭＢ３０およびＰＩＭＢ８５を記述するために使われる用語「永続性の」と「限定」は、厳密な用語として文字通り解釈すべきではない。ユーザは、重要とおもわれる幾つかのメッセージは、いつまでも記憶したいと望む。二人の友達間の普段のおしゃべり等のその他の状況では、スペースを節約するために、一定の時間が経過したら、メッセージは削除しても良い。本発明の種々の実施例によれば、システム１０によって設定されるかユーザによって設定されるか、異なる保持ポリシが使われても良い。「限定」の用語は、ＰＩＭＢによって強制される時間的区切りがないという意味で使用される。このことは、現在のジッタバッファシステムでは、メディアはレンダリングされた後は、廃棄されるのとは対照的である。「永続性」および「限定」の用語は、したがって、ＰＩＭＢ３０およびＰＩＭＢ８５は、時間の範囲とそこに記憶されるメッセージの量については何ら内的制限がない、ということを意味すると広く解釈されるべきである。

持続的記憶媒体に会話のメッセージをアーカイブすることには多くの利点がある。音声メッセージおよびその他のメディアは、必要に応じ組織化され、インデックスされ、検索され、転記され、翻訳され、レビューすることができる。音声およびその他のメディアは、したがって、ユーザおよび組織によって管理することのできる資産となる。これらのメディア資産は、軍隊同様、会社、第一応答者、警察および消防署にとっても価値がある。

［Ｆ．Ｖｏｘプロトコルおよびインデックスメディアペイロード］
上記したように、Ｖｏｘプロトコルは、ペイロードの送信、記憶、および最適化の全ての面をサポートするために、記憶・ストリームモジュール２４によって使われる。Ｖｏｘパケットは、ネットワーク１８の下層の技術における一個または複数の搬送パケットの内部のカプセル化のために設計された構造化されたメッセージフォーマットである。これによりシステム１０の自由度が大きく改善される。搬送パケットの中にＶｏｘパケットを埋め込むことによって、「ヴォクシング（Ｖｏｘｉｎｇ）」アプリケーションのために新しい搬送層を定義するのとは対照的に、システム１０は、現存する通信インフラを通じて動作する通信ネットワークに基づいて現在のパケットを利用する。Ｖｏｘパケットを扱うための新しいネットワークインフラは、したがって、ここに記載するシステムおよび方法の全ての利点を利用する必要はない。

図４Ａを参照すると、Ｖｏｘパケット９５の一般的なフォーマットの構造が示されている。Ｖｏｘパケット９５のフォーマットは、タイプ、サブタイプ、長さ、およびペイロードを含む。Ｖｏｘパケットの別のタイプは、認証、信号発信、メディアペイロード、メディア多重化（一個のメッセージ）、およびメディア多重化（多数のメッセージ）を含む。サブタイプのフィールドは、異なるタイプの認証、信号発信、メディアタイプメッセージを指定するために使われる。認証メッセージのための可能なサブタイプとしては、キー交換および認証に必要なフィールドが含まれる。信号発信メッセージのための可能なサブタイプとしては、登録、ルーティング、メッセージのセットアップおよびネットワークの管理が含まれる。メディアメッセージのための可能なサブタイプとしては、コーデックの型と異なるペイロード集約技術が含まれる。長さフィールドはペイロードの全長すなわちサイズを定義する。ペイロードフィールドは、パケット９５の実際のペイロードすなわちメディアを含む。

図４Ｂはネットワーク１８によって使われるカプセル化せれたＶｏｘパケット９５のプロトコルの例を示す図である。この例では、ＵＤＰ、ＩＰおよびイーサネット（登録商標）の搬送パケット９６の下層にそれぞれ埋め込まれたＶｏｘパケット９５を示す。この方法においては、Ｖｏｘパケット９５は、ネットワーク１８の下層のＵＤＰ、ＩＰおよびイーサネット（登録商標）層を通じて搬送できる。これは、パケットネットワークによって使われる標準的なプロトコルカプセル化の技術である。

図４Ｃは、ＵＤＰ、ＩＰ、およびイーサネット（登録商標）９７内でカプセル化されたメディア多重化Ｖｏｘパケット９５を示す図である。この例では、Ｖｏｘパケット９５は、メディアタイプフィールド、メディアサブタイプフィールド、長さフィールド、メッセージＩＤフィールド、タイムスタンプフィールド、シーケンスＩＤフィールドおよびメディアペイロードフィールドを含む。

図４Ｄは、インデックスされたメディアペイロード９８のフォーマットを示す。インデックスされたメディアペイロードは、サブタイプフィールド、長さフィールド、メッセージ識別子（ＩＤ）フィールド、タイムスタンプフィールド、シーケンス識別子（ＩＤ）フィールド、およびメディアペイロード用のフィールドを含む。

Ｖｏｘパケット９５を搬送パケット下層のネットワークのカプセル化することによって、メディア、メッセージおよび会話を多数の属性によってそれぞれ定義することができる。

メディアがデバイス１３上に作成または生成されると、それは、主としてタイムベースのものとなり、時間経過とともに意味のある形で変化する。ある人が会話に参加すると、例えば、時間の経過とともに、話し言葉はセンテンスまたは発言につなぎ合わされて、結果としてのデータ（ストリームおよびパケット）は、同じ相違を長い時間維持する。同様に、ＧＰＳその他センサデータ同様、ビデオ（スチール写真とは対照的に）は、時間の経過とともに変化する。タイプや生成のされ方にかかわらず、メディアはセグメント化され、複数のＶｏｘパケット９５のペイロード中に置かれる。続いてパケットは記憶され、送信され、受信され、記憶され、送信側と受信側のデバイス１３のそれぞれでストリーム（すなわち、ストリーム中のメディア）にレンダリングされる。各パケット９５は、インデックスされ、タイムスタンプ処理され、シーケンス識別子が付与されているので、個々のパケットは、メッセージにセグメント化することができる。個人のメッセージを順番にスレッディングすることによって会話を構成することができる。

システム１０の固有の側面として、クライアント１２によって生成されたメディアペイロードは多くのロケーションに記憶されるということである。ペイロードは、生成側のデバイス１３のＰＩＭＢ３０に記憶されるだけでなく、受信側のサーバ１６のＰＩＭＢ８５およびデバイス１３のＰＩＭＢ３０にも記憶される。この基本的な機能によって、Ｖｏｘｉｎｇ機能の多くを可能とし、ネットワークの状態が不良であっても、あるいは会話の参加者がネットワークに接続されていなくても、システム１０に復元力と操作性を提供する。

［Ｇ．下層通信プロトコルとの相互操作性］
システム１０は、インターネット、固定ＰＳＴＮタイプ回路ネットワーク、およびモバイルまたはセルラーホンネットワークまたはその組み合わせのようないろいろな現存する通信ネットワーク１８を通じて、実行する、あるいはそれらと層化することを意図している。システム１０は、システム１０内の異なるクライアント１２とサーバ１６間を移動する多数の小さな情報の単位（すなわち、Ｖｏｘパケット）のコンセプトの周辺に設計されている。Ｖｏｘパケットは、機能およびペイロードによってサイズは異なるが下層のネットワーク層にとっては、全て同じ種類のデータとして見える。一実施例において、システム１０は、インターネット等のＩＰｖ４ネットワークが設計されて最適化されたものだが、その他のタイプのネットワークもサポートする。本ドキュメントの目的に照らして、用語「ＩＰ」は、ＩＰｖ４、ＩＰｖ６あるいはその他現在または未来に実施されるであろうインターネットプロトコルを意味すると理解されるべきである。

図５は、デバイス１３上で実行し、共用ＩＰネットワーク１００を通じてサーバ１６と通信するクライアント１２を示す。図に示すように、クライアント１２は、第一のインターネットサーヴィスプロバイダＡを介して共用ＩＰネットワーク１００に連結され、サーバ１６は、第二のインターネットサーヴィスプロバイダＢによって共用ＩＰネットワーク１００と連結されている。通信中に、Ｖｏｘパケット９５（図では「ＶＰ」と表記）はＵＤＰ／ＩＰパケットにカプセル化され、ついで当該技術では周知のように、他のＩＰプロトコルパケットにインタリーブされ、共用ＩＰネットワーク１００を通じてクライアント１２からサーバ１６等へ送信される。周知の如く、低いパケット層はすぐ上の層のパケットの全てをカプセル化する。また、パケットは、同様のやり方で２個のサーバ１６間でやり取りされる。メッセージは、共用ＩＰネットワーク１００を通じてクライアント１２が許可したデバイス１３から他のクライアントへ送られる。Ｖｏｘパケット９５は、ターゲットの宛先に到達するまで各ホップで下層のＩＰプロトコルに埋め込まれ送信される。

図５は、説明のために、ネットワーク１００接続された一個のクライアント１２とサーバ１６を例示的に示す。実施例における実際のシステム１０は、多くのクライアント１２と一またはそれ以上のサーバ１６が主として共用ＩＰネットワーク１００に接続されている。また、クライアント１２およびサーバ１６は、ＩＰネットワーク１００を排他的に使うものではないことに注意されたい。図示の例では、インターネットプロバイダＡを介してネットワーク１００と連結されたＨＴＴＰクライアントは、ネットワーク１００に連結されたＨＴＴＰサーバとの間で、第３のインターネットプロバイダＣを経由してパケットをやり取りすることができる。システム１０は、ＩＰパケットに埋め込まれたＶＰがネットワーク１００を横断する方法についてコントロールはしない。ネットワーク１００を共有し横断する全てのパケットは、下層の共用ＩＰネットワーク１００の標準的な手順に従って動く。

図６は、ネットワーク１０４にベースを置くＧＳＭモバイルホンネットワーク等の「回路」を示す。回路ネットワーク１０４は、デバイス１３上で動作するクライアント１２とサーバ１６の間で連結されている。一旦クライアント１２とサーバ１６の間で回路が確立されると、システム１０はネットワーク１０４が使う下層のパケットの上にＶｏｘパケット（ＶＰ１、ＶＰ２、ＶＰ３、ＶＰ４、ＶＰ５等）を積み重ね、「バーチャルＶｏｘ」回路を作りネットワーク１０４を通じてそれらを送信する。Ｖｏｘパケットは、データを送信する技術において知られているように、主として間隔をあけるかデータを形成して回路ネットワークを通じて回路ネットワーク１０４を順番に横断する。さらに、ペイロードのサイズおよび含まれるヘッダフィールドの数等のパケット構成パラメータを使い、パケットごとのオーバヘッドがないことを利用することもでき、またネットワーク１０４を通じてデータを送信する速度および／または効率を向上させることもできる。単純化の目的で、一個のクライアント１２とサーバ１６のみがネットワーク１０４に接続されて示していることに再度注意を促したい。しかしながら、クライアント１２とサーバ１６およびその他のコンポーネントとの間の付加的回路は、ネットワーク１０４を介して一斉に確立することができることについては理解できよう。したがって、ネットワーク１０４は、Ｖｏｘパケットを送信するための専用ではなく、むしろ他のタイプのネットワークトラフィックと共有してもよい。

図７は、第一のネットワークＡにつながる第一クライアント１２Ａによって動くデバイス１３Ａと第二のネットワークＢにつながる第二のクライアント１２Ｂによって動くデバイス１３Ｂとの間の通信を示す図が示される。さらに、ネットワークＡ、Ｂはそれぞれ、ゲートウェイサーバ１６Ａおよび１６Ｂを含む。ゲートウェイサーバの組１６Ａ、１６Ｂは、二つのネットワークＡ、Ｂ間の通信を促進し、デバイス１３Ａ、１３Ｂに互いに通信を可能にする。種々の実施例において、二つのネットワークＡ、Ｂそれぞれどのようなタイプのネットワークでもよい。例えば、各ネットワークＡおよび／またはＢは、ＩＰネットワーク、回路タイプのネットワーク、無線通信またはセルラーネットワーク（すなわち、ＣＤＭＡ、ＧＳＭ、ＴＤＭＡ等）でもよい。サーバ１６は、二つのネットワーク間のトラフィックのルートを決めたり「ゲート」として機能したりするので、二つのネットワークＡ、Ｂにまたがるゲートウェイサーバとも考えられる。

システム１０によって、システムのパフォーマンスを最適化するための、いくつかの基本的なネットワークの相互作用に関する考え方がある。これらの考え方には、Ｖｏｘパケット９５が送られる下層のアドレスの分解法、送られたＶｏｘパケットの統合、および所定のネットワークまたはネットワークの組み合わせを通じて送られる一個のメッセージの最大送信単位（ＭＴＵ）の管理などのファクタが含まれる。

下層のネットワークがＶｏｘパケット９５を正しいロケーションに送達できるように、ターゲットクライアント１２のアドレスを知る必要がある。ＩＰｖ４ネットワークでは、アドレスは主としてＩＰｖ４アドレス、ネットワーク内のホストを一意的に識別する３２ビット数である。別のネットワーク技術においては、アドレスは別のタイプの識別子である場合もある。ＩＰネットワークではドメインネームシステム（ＤＮＳ）を使い、人間が読み取り可能なネームをＩＰアドレスに変換し、アドレス変換プロトコル（ＡＲＰ）でＩＰアドレスを物理アドレスに変換する。下層のネットワーク技術に関わりなく、システム１０は、上記のスキームのうちの一つまたは他の既知のアドレススキームを使ってＶｏｘパケット９５を正しいロケーションに送達する。

パケットベースの通信システムにおいては、もし、下層のネットワークがＶｏｘパケットがカプセル化されたパケットを送達できなければ、送信されたＶｏｘパケットがアドレスされたロケーションに送達されない場合もある。ほとんどのパケットネットワークは、パケットが欠落しても送信側へ通知しない。これとは逆に、パケットは送信側と受信側に依存し、欠落したパケットを通知し、補正する。システム１０はこれらの受信側の受信レポートメッセージを使いパケット損失管理を調整するように設計されている。もし、下層のネットワークが欠落し紛失パケットを送信側に通知することができれば、システム１０はこの情報をプロトコルの再送信に使用できる。

ＭＴＵの管理とは、ネットワークを通じて送ることのできる最大送信単位（すなわち、一個のメッセージの最大サイズ）を決定することである。パケット方式のネットワークでは、下層のネットワークがＭＴＵを付与する。回路切り換え型ネットワークでは、ネットワーク効率とパフォーマンスのために、ＭＴＵは調節可能なパラメータである場合もある。このように、多くのケースでは、Ｖｏｘパケット９５が効率的に送信されるように、下層のネットワークがＶｏｘパケット９５の最大サイズを与えたり決めたりする。例えば、ＩＰネットワークでは、ペイロードがＭＴＵを超えた場合は、相当なパフォーマンスを犠牲にして、パケットは細分化ができる。イーサネット（登録商標）ネットワークを通じたＩＰでは、送信側のデバイスは、イーサネット（登録商標）が実行するものとして、１５１８バイトのＭＴＵである。最大ＩＰパケットは、イーサネット（登録商標）ヘッダのための余地を残さなければならない。最大ＵＤＰパケットは、ＩＰとイーサネット（登録商標）のヘッダのための余地を残さなければならない。およびイーサネット（登録商標）で生成される最大Ｖｏｘプロトコルは、例えば、イーサネット（登録商標）ＭＴＵ（１５１８）−ＩＰヘッダ（２０）−ＵＤＰヘッダ（８）＝１４９０バイトである。Ｖｏｘプロトコルは、それ自身のヘッダを持つので、実際のＶｏｘメディアペイロードはイーサネット（登録商標）ネットワーク上では１４９０バイト以下である。ギガバイトイーサネット（登録商標）の場合は、ＭＴＵははるかに大きくてもよいが、同様の計算式を使って判断される。

純粋にパケットベースネットワークにおいては、ＭＴＵ用に二個の潜在的値、すなわち、ローカルリンクＭＴＵおよび経路ＭＴＵがある。ローカルリンクＭＴＵは、ローカルネットワークインタフェースに効率的に送られるように、Ｖｏｘパケット用に最大サイズが決定する。経路ＭＴＵは、遠隔地のノードまで全行程完全な状態で送られるように最大サイズのＶｏｘパケットを出す。送信側がイーサネット（登録商標）を介して接続されている場合は、小さなＭＴＵで、Ｖｏｘパケットは様々な別のシステムを経由して、受信側までの道順を決められる。宛先までの経路上の最も小さなＭＴＵの場合は、送信側によって決定され通知される必要がある。ＩＰの世界では、「経路ＭＴＵディスカバリ」と呼ばれる最も小さいＭＴＵを見つけるための標準的な手順がある。その他の種類のネットワークには、同様な手順が使われてもよい。改めて言うと、システム１０は、別のネットワークの上に重ねられているので、上記のどのＭＴＵアルゴリズムでも使うことができる。

［Ｈ．動作フロー図］
［Ｈ．１ 記憶及びストリーム］
図８Ａないし８Ｆは一連のフロー図であり、クライアント１２とサーバ１６上の記憶・ストリームモジュール２４、８４のそれぞれの動作を示す。図８Ａは、第二のクライアント１２_２にメッセージを送信する第一のクライアント１２_１のための動作シーケンスを示す。図８Ｂと８Ｃは送信側クライアント１２_１上のＰＩＭＢ書込み部２８とＰＩＭＢリーダ２８の動作を示す。図８Ｄと８Ｅは、受信側クライアント１２_２上のＰＩＭＢ書込み部２８とＰＩＭＢ読取り部２６の動作を示す。図１０Ｆは、サーバ１６上の記憶・ストリームモジュール８４のフロー図を示す。

図８Ａにおいて、デバイス１３_１上で動作するクライアント１２_１のユーザが、送信すべきメディアを生成する。メディアは、デバイス１３の側で、ユーザがマイクに話すことによってメディアを作成する、自分のデバイス１３上でビデオコンテンツを作成する等、多くの異なる方法で作ることができる。また、メディアはデバイス１３によってＧＰＳ情報、温度読取り値等の受信側センサデータを受信することによって生成される。メディアがどのように生成されたかにかかわらず、メディアは、ＰＩＭＢ書込み部２８（囲み１３０）によってエンコードされ、ＰＩＭＢ書込み部２８は、メディアをインデックスされたメディアペイロードに変換し、クライアント１２_１上のＰＩＭＢ３０（囲み１３２）に記憶する。クライアント１２_１上のＰＩＭＢ読取り部２６は、ＰＩＭＢ３０からペイロードを読取り、Ｖｏｘパケットを作成し、ネットワーク１８を通じてパケットを受信側クライアント１２_２（囲み１３４）に送信する。経路に沿う送信側クライアント１２_１と受信側クライアント１２_２の間の各サーバ１６は、送信されたペイロードをＰＩＭＢ８５に記憶し、Ｖｏｘパケットを次のホップ（囲み１３３）に送信する。受信側クライアント１２_２にて、ＰＩＭＢ書込み部２８のネット受信機能がＶｏｘパケットをインデックスされたメディアペイロード（囲み１３６）に変換し、ペイロードをクライアント１２_２（囲み１３８）のＰＩＭＢ３０に記憶する。クライアント１２_２上のＰＩＭＢ読取り部２６のレンダリングモジュールは、ＰＩＭＢ３０から読取ったペイロード情報を音声またはビデオ（囲み１４０）等の媒体にレンダリングする。これらのステップについては、図８Ｂないし８Ｅを参照してさらに詳しく記述する。

図８Ｂに、ＰＩＭＢ書込み部２８（図８Ａのステップ１３０）によって実行されるエンコード受信機能のシーケンスを詳しく示す。最初のステップ１３０_１にて、クライアント１２_１を操作するデバイス１３のユーザが、送信すべきメディアを生成する。上記したように、メディアは、マイクに話す、カメラを使う、センサデータを受信する、その他メディアを生成するためのコンポーネントによって、得ることができる。次のステップ１３０_２にて、エンコードレシーバ２８ａはメディアをエンコードし、インデックスされたメディアペイロード（ステップ１３０_３）を作成し、メディアはデータ記憶部２８ｃによってＰＩＭＢ３０（ステップ１３２）に記憶される。

図８Ｃは、送信側のクライアント１２_１のＰＩＭＢ読取り部２６によって実行される送信機能のシーケンスを示す（図８Ａ、ステップ１３４）。決定ループ１３４_１において、ＰＩＭＢ読取り部２６の送信機能は、送信されるべきインデックスされたメディアペイロードがＰＩＭＢ３０に書き込まれているか、それは送信可能かどうか常にチェックする。もし、使用可能なペイロードがＰＩＭＢ３０にあれば、データ優先順位付与部２６ｆは、ステップ１３４_２に示すように、ＭＣＭＳの参加者属性情報を使って、最初に送るべきペイロードに優先順位をつける。最も高い優先順位のペイロードに関する情報は、図９Ａないし９Ｃに詳述するように、ＰＱＭ（ステップ１３４_３）を実行するパケット最適化部２６ｇに渡される。次に、データ読取り部２６ｈによって適切なペイロードがＰＩＭＢ３０から取り出され（ステップ１３４_４）、パケット部２６ｉによってＶｏｘパケット９５に変換される（ステップ１３４_５）。ついで、Ｖｏｘパケット９５は、送信部２６ｊによって、ネットワーク１８を通じて受信クライアント１２_２に送信される（ステップ１３４_６）。受信クライアント１２_２は、受信したパケットの特性（損失、ジッタ、処理量）を反映した受信レポートを返す。これらの受信レポートは、ＰＱＭが所与の受信側のＭＡＢＲを計算するのに必要な情報を提供する。プロセスは、戻り矢印で示すように、送信ループごとに送信ステップからフロー図のトップに繰り返される。

上記の実施例では、メディアは、一連の流れの中で、エンコードされ、ＰＩＭＢ３０に記憶され、ネットワーク上に送信される。代替的な実施例においては、エンコードされたメディアは、ＰＩＭＢ３０に記憶されネットワーク上を平行に送信される。すなわち、二つの機能はほぼ同時に起こる。

図８Ｄは、受信側のクライアント１２_２上のＰＩＭＢ書込み部２８のネット受信機能（図８Ａ、ステップ１３６）のシーケンスを示す。最初のステップ１３６_１で、ネットワーク受信部２８ｄがネットワーク１８を通じてＶｏｘパケット９５を受信する。データ記憶部２８ｆはパケットをインデックスされたメディアペイロードに変換し（ステップ１３６_３）、ＰＩＭＢ３０に記憶する（ステップ１３６_４）。ペイロードが記憶されると、データ品質管理部（ＤＱＭ）２８ｇが実行される。ＤＱＭ２８ｇは、紛失、壊れたりしたパケットがないかチェックし、送信されたデータの正確なコピーが最終的に記憶されることを確実にする。そして、ネットワークの状態に関する受信レポートを送信側に送信する。ＤＱＭ２８ｇのこれらの機能については、図９Ｄないし９Ｆを参照してさらに詳しく説明する。

図８Ｅは、受信側クライアント１２_２上のＰＩＭＢ読取り部２６（図８Ａ、囲み１４０）のレンダリング機能のシーケンスを示す。最初のステップ１４０_１において、データ優先順位付与部２６ａが、ＭＴＳＤ情報、ユーザステータス、プレゼンス情報を含むユーザの意図および注意のステータスを使って、ＭＣＭＳアプリケーション２０によって、レンダリングすると判断されたインデックスされたメディアペイロードに優先順位をつける。優先順位をつけられたペイロードは、データ取出し部２６ｂによってＰＩＭＢ３０（ステップ１４０_２）から読取られる。ＰＬＣ／補間部２６ｃは、どちらのコーデックを使うかによって既知のパケット損失補償および補間アルゴリズムを使って、取り出したペイロードにパケット損失補償および補間（ステップ１４０_３）を実行する。次のステップで、二人以上の参加者が同じ会話の中で同時にメディアを生成した場合（例えば、両者が同時に話している）は、ミックス部２６ｄは、会話の多数のメッセージをミックスする（ステップ１４０_４）。レンダ部２６ｅは、ミックス部２６ｄからのデータストリームをレンダリングし（ステップ １４０_５）、受信側ユーザに音、ビデオ、その他のメディアを生成する（ステップ１４０_６）。

図８Ｆは、サーバ１６が、ネットワーク１８上の前のホップからＶｏｘパケットを受信し、記憶し、アーカイブし、Ｖｏｘパケットを次のホップに送信するシーケンスを示す。最初のステップで、サーバ１６は、ＰＩＭＢ書込み部のネット受信機能を実行し（図８Ｄと同様）、受信したデータのインデックスされたメディアペイロードを、サーバ１６のＰＩＭＢ８５とアーカイブ部８９に保存する。また、サーバ１６は、ＰＩＭＢ書込み部の送信機能を実行し（図８Ｃと同様）、ネットワーク１８上の次のホップに受信したパケットを転送する。この方法においては、送信側クライアント１２_１によって生成されたメディアのコピーが、受信側クライアント１２_２までの経路に沿って各ホップで受信され、記憶され、送信される。

上記の実施例においては、受信したインデックスされたメディアの書き込みは、サーバ１６のＰＩＭＢ９１に記憶され、次のホップに連続的に送信される。代替的な実施例においては、受信したインデックスされたメディアペイロードが、ＰＩＭＢ９１に記憶し、ほぼ同時に次のホップに送信される。送信側、受信側両者のデバイス１３のＰＩＭＢ３０にメディアを記憶することにより、メディアの漸次送信とレンダリングが可能となる。送信側においては、送信側のデバイスで生成されたメディアは、それが受信されると、漸次ネットワーク上に送信することができる。種々の実施例においては、エンコードされたメディア（どのように生成されたかにかかわらず）は、ＰＩＭＢ３０に記憶される前、後、またはほぼ同時に漸次送信することができる。また、受信側では、入ってくるメディアは、ネットワークを通じて受信されごとに漸次レンダリングすることもでき、ユーザが望めば、ほぼリアルタイムモードでメディアをレビューすることができる。種々の実施例においては、入ってくるメディアは、受信側のデバイス１３のＰＩＭＢ３０に記憶されるごとに、記憶される前、後、またはほぼ同時に漸次レンダリングするこができる。受信メディアをタイムシフトモードでレビューするつもりであれば、後でメディアをＰＩＭＢ３０（または、ローカルＰＩＭＢ３０に置き換えられた場合は、サーバ１６上のＰＩＭＢ８５でも可）から取り出し、ユーザが指定する時にレビューすることもできる。

本アプリケーションの文脈において、「漸次的」または「漸次」という用語は、広く解釈されることを意図し、一般にデータの利用可能性に基づいてデータストリームを継続加工することを意味する。例えば、メディアが作成またはデバイス１３上で生成されるに従い、メディアが入手可能な限り、メディアの漸次的エンコード、記憶、パッケージ化および送信は継続する。人が話すと、その人が話している間、メディアは、漸次的すなわち継続的にエンコードされ、記憶され、パッケージ化され、送信される。その人がポーズすなわち、話すのを止めると漸次プロセスするメディアはない。その人が再び話すことを再開すれば、メディアの漸次的処理は再開する。また、受信側では、メディアが受信されている限り（すなわち、入手可能な限り）、メディアは、漸次処理される。メディアが受信されると、そのメディアは継続的に記憶される。メディアが受信されている限り、ほぼリアルタイムモードの場合は、継続的にレンダリングされ、タイムシフトモードでは、記憶装置から継続的にレンダリングされる。上記説明は音声の文脈で述べたが、全てのタイプのメディアが同様に漸次処理することができる。また、メディアの漸次的加工は、必ずしもインデックスされた順序で漸次処理される必要はない。むしろ、メディアは受信された順序で、またはその他のインデックススキームによって処理される。もし、メディアがインデックスの順序から外れて受信されたら、一実施例においては、受信されたメディアは受信された順序で漸次処理される。そして、ＰＩＭＢ３０の中で、インデックスされたシーケンスに組織化される。代替的な実施例においては、受信メディアはインデックスされたシーケンスで組織化され、漸次レンダリングされる。

［Ｈ．２ ＰＱＭの動作フロー図］
ＰＱＭ２６ｇは、継続的に計算される、送信側と受信側のノードのペアの間の実際の送信容量すなわち帯域幅の近似値（すなわち、所定の時点でのネットワークの能力の測定）、すなわち最大可能ビットレート（ＭＡＢＲ）と呼ばれる計量に依存する。瞬時にネットワークの状態が変化するごとに、ＭＡＢＲは更新される。ネットワークの処理量、パケット損失、およびジッタの定期的測定値が、ＭＡＢＲを計算することによって考慮される。また、他の実施例においては、ＭＡＢＲは、時刻、ネットワークのタイプ、その他の条件またはパラメータに基づいて手動でセットまたは制限してもよい。

また、ＰＱＭは、受信側の意図を考慮し、時間依存型の送信を最適化する。下記のいずれかの場合、送信は時間依存型であるとみなされる。すなわち、（ｉ）受信側の意図が、送信を「ライブ」すなわちほぼリアルタイムモードでレビューしようとしている、または（ｉｉ）受信側が、なんらかの理由で（例えば、メッセージは先にアーカイブ部８９に保存された）、デバイス１３には現在記憶されていないメッセージを即座にレビューしたいと望んでいる。受信側の意図は、受信側の動作によって推論するか、受信側が自分の意図を設定するか別途指定してもよい。一方、受信側の意図がタイムシフトモードでメッセージをレビューすることであれば、送信は時間依存型でないとみなされる。受信側が、ライブモード（すなわちリアルタイムモード）かタイムシフトモードかどちらかで送信をレビューしようという意図が、少なくとも部分的には、送信の「適時性要件」を定義する。その他の種々の実施例においては、通信の緊急性または優先順位といったファクタも、送信の適時性要件を定義するときに考慮される。

送信側と受信側のペアの間のネットワーク経路のノードもまた、受信側の意図のステータスに関して一貫性のあることが必要である。もし、一個のターゲット受信側が適時性を指示したら、すなわち、送信を即座にすなわちライブでレビューしたいと望んだ場合、送信側と受信側の経路に沿うネットワーク上の全ての中間ノードは、その他の受信側要件にもかかわらず、同じ適時性要件を持たなければならない。したがって、各中間ノード適時性要件は、送信が送られた受信側ノードに依存する。この依存性は、ネットワーク送信経路におけるターゲットノードのための「要件の融合」と言われる場合もある。

さらに、ＰＱＭは、予約されたメッセージペイロードの送信のための理想ビットレート「ＩＢＲ」を考慮する。時間依存型の通信のために、ＩＢＲは、ほぼリアルタイムまたはライブ通信に必要とされるパケット化レート（以下、リアルタイムビットレート（ＲＴＢＲ）という）に基づいて計算される。例えば、音声場合、２０ミリ秒の音声データを含む２０ミリ秒毎のパケット化レートは、ライブ会話を行うための許容ＩＢＲが考慮される。キロバイト毎秒のシステムのためのＲＴＢＲは、１秒の音声ペイロードデータに送信するために生成される全てのネットワークヘッダのサイズを加えたサイズとなる。ビデオメディアまたは音声とビデオの組み合わせのためのＲＴＢＲは、単なる音声よりも実質的に高くなる。センサまたはＧＰＳ位置測定データ等のその他のタイプのメディアのためには、音声よりも低くなると思われる。非時間依存型の通信のためには、ＩＢＲは、ネットワークを通じての通信の使用量すなわち効率を最適化するために最大効率ビットレート（ＭＥＢＲ）に設定される。ＭＥＢＲは、パケット化レートを調節することによって、下層のネットワークのために最大可能な値に計算される。送信側と受信側のペアの間で、多数のメッセージまたはペイロードが送られ場合は、統合ＩＢＲ（ＡＩＢＲ）が送信のために考慮される。

ＰＱＭは、各送信側と受信側ペアのための一連の送信ループのデータを送信することによって動作する。各送信側と受信側ペア用の送信ループは、単独のものである。ネットワーク上のいかなる送信もその他送信側・受信側ペアのＭＡＢＲに影響を与えうる。従って、ＭＡＢＲは、全ての受信側について継続的に計算されることが望ましい。

図９Ａないし９Ｃは、一組の送信側と受信側ペアのためのＰＱＭの動作シーケンスを示すフロー図である。図９Ａは、一組の送信側と受信側ペア間のＭＡＢＲを決定するステップを示す。図９Ｂは、一個の送信側と受信側ペアの各送信ループのためのＡＩＢＲを計算するステップを示すフロー図である。図９Ｃは、送信側と受信側ペア間で送信するデータのループ当たりの量を決定するシーケンスを示す。三つの図に示す処理は、以下に詳述するように、同時に実行され互いに情報のやりとりをする。

図９Ａにおいて、フロー図５０は、送信側と受信側ペア間のネットワークインタフェースのためのＭＡＢＲの計算を示す。最初のステップ５０_１において、送信側と受信側のペア間のネットワークインタフェースをモニタする。ステップ５０_２で、送信側は、受信側におけるネットワーク接続のステータスに関する情報を含むレポートを定期的に受信する。レポートは、受信側によって観測されたネットワークインタフェースでのデータ処理量５０_３、パケット損失５０_４、およびジッタ５０_５の現在のステータスに関する情報を含む。ステップ５０_６で、このレポートに含まれるこれらの観測に基づいて送信側でＭＡＢＲが計算される。これらのレポートのデータをモニタすなわち監視することによって、送信側と受信側のペア間の現在のネットワーク性能または状態に基づいてＭＡＢＲ値が継続的に調節される。ネットワーク性能がデータ送信にとってさらに好適になるので、ＭＡＢＲが向上する。もしネットワーク性能が送信にとって好適以下となれば、ＭＡＢＲが低下し、潜在的に結果としてゼロとなり使用不能なネットワークとなる。このレポートは、ＴＣＰネットワークのノードによって生成されるパケット損失レポートと同様のものであるが、さらに処理量情報とジッタ情報を含む。

送信側と受信側のペア間に複数のネットワークインタフェースがある場合は、ＭＡＢＲは、受信レポートが受信されるインタフェース毎に計算される。直近にネットワーク上にトラフィックが送られていない場合、または、受信レポートが受信されていない場合は、ＭＡＢＲには現在のネットワークの状態が反映されないことがある。しかしながら、データが送信されているかぎり、受信側によって受信レポートが継続的に生成されるので、送信側のＭＡＢＲ計量はさらに正確な値に速やかに収束する。

図９Ｂは送信ループのためのＡＩＢＲを計算するステップを示すフロー図５２である。最初のステップ５２_１において、メディアを有するメッセージ（メッセージに所属する時間でインデックスされたメディアの部分）が現在のループの送信側と受信側のペア間で送信される準備ができていることが確認される。つぎに、メディアを有するメッセージのリストが、作られる（５２_２）。リスト５２_３の各メッセージについて、各メッセージの時間的制約すなわち適時性要件が考慮される（５２_４）。もし、個々のメッセージに時間的制約がなければ、ＩＢＲは最大効率ビットレート（ＭＥＢＲ）にセットされる（５２_５）。一方、メッセージに時間的制約があるばあいは、リアルタイムビットレート（ＲＴＢＲ）にセットされる（５２_６）。次のステップ５２_７において、リストのメッセージ毎に先に計算されたＩＢＲは、合計されて、送信ループのための統合理想ビットレート（ＡＩＢＲ）５２_８となる。戻り矢印５２_９にて示すように、上記のプロセスは、送信ループ毎に送信側と受信側のペア間で繰り返される。

図９Ｃにおいて、フロー図５４は、送信ループ毎に送信側と受信側のペア間で送信するデータのレートを決定するシーケンスを示す。最初のステップ５４_１において、ＭＡＢＲ（図９Ａで計算された）は、次の送信のためにＡＩＢＲ（図９Ｂで判断された）と比較される。

ＭＡＢＲがＡＩＢＲ以下であれば、ループ内の送信の準備ができていると識別されている全てのメッセージが、ＩＢＲレートでパケット化され（５４_２）、送信される（５４_３）。

一方、ＭＡＢＲがＡＩＢＲ未満のときは、一連の手順が適用されて、ＰＱＭが以下の目標が満足されるように調節される。すなわち、データの適切なコピーをタイムリーに送達すること、利用可能な帯域幅を有効に使うこと、および／またはペイロードコンテンツおよび現在のネットワーク条件を満足する品質、パケットサイズおよび送信レート。言いかえれば、ＭＡＢＲがＡＩＢＲ未満のとき送信されたメディアを表すのに用いるビット数は、データ損失量（すなわちスループット）が許容できる水準になるまで減らされる。

最初のステップにおいて、リストのメッセージは、時間的制約がないかレビューされる（５４_４）。時間的制約のあるメッセージがなければ、ビットレートは、ＭＡＢＲに設定されて（５４_５）、メッセージが送信される（５４_３）。

リストに時間的制約のあるメッセージが含まれる場合は、時間的制約のないメッセージに割り当てられたビットレートは、ＭＡＢＲの制限が満足されるまで引き下げられる（５４_６）。ビットレートをゼロになるまで引き下げても、ＭＡＢＲを満足しないときは、これらの時間的制約のないメッセージは、ループに送信されるメッセージのリストから除去される。ビットレートがＭＡＢＲ以下になるまで引き下げられ、残ったメッセージはパケット化され、送信される（５４_３）。

時間的制約がないメッセージを削除してもＭＡＢＲを満足しない場合、次にちょうど時間的制約があるメッセージのＩＢＲバージョンと比べて引き下げられたビットバージョンを送信する手順が受信の際にメッセージをレビューする受信側の機能を向上する目的で実行されるので、会話がほぼリアルタイムモードで継続する。一実施例では、時間的制約があるメッセージの引き下げられたビットバージョンを生成するということは、送信すべき時間的制約があるメッセージのメディアをパケット化にするときにＩＢＲと比べて少ないビットを用いるということである。例えば、ネットワーク上で利用可能な帯域幅が満足するまでペイロード当たりに用いられるビット数を徐々に減少させる。この手順は、コーデックの設定を調節することによって、異なる品質や低い品質のコーデック（または複数のコーデック）を用いることによって、またはその任意の組み合わせによって行われる。別の実施例では、送信すべきメッセージに含まれる時間的制約があるメディアの引き下げられたビットバージョンを生成するということは、任意の多くの既知圧縮アルゴリズムを用いるということである。ビット数を十分に減らす場合、すなわちＭＡＢＲの制限を満足する場合、次にメッセージが送信される（５４_３）。どの実施例を用いるかに拘わらず、送信ループ中で少ないビットを送信することによって、ペイロードデータをできるだけ速く送信する試みがなされる。所定の周期の時間に少ないビットを送信することによるペイロード品質、送信品質を引き下げることによって、会話はほぼリアルタイムモードに維持される。

上述した技術の何れかを用いてビットレートを引き下げても、まだＭＡＢＲを満足しない場合は、時間的制約のあるメッセージを送信するためのパケット化間隔を増やす（５４_８）。この手順によりヘッダ対ペイロードの比率が上げられ、これにより全体のビットレートが引き下げられるが、待ち時間（すなわち、受信側への送信の送達遅延）が導入される。この手順によってＡＩＢＲがＭＡＢＲ以下になれば、送信５４_３がはじまる。

もし、パケット化の間隔変更後も、まだＭＡＢＲが満たされない場合は、ビットレートがＭＡＢＲ制限内になるまで漸次引き下げられる（５４_９）。この方法でビットレートが引き下げられると、時間的制約のあるメッセージは、ライブ会話の維持ができないレートで送られる。したがって、会話は、「ライブ」から強制的にはずされてしまう。ネットワークがダウンまたは非常に悪い状態のときはデータの送信が始まらない場合もある。再度、上記のシーケンスが送信側と受信側のペア間で送信ループ５４_１０毎に繰り返される。ネットワーク上の条件が改善する際に、パケット化間隔を減少することによって、および／またはネットワーク条件を満たすメディアを表すビットを多く用いることによって、会話がライブモードまたはほぼリアルタイムモードで再開する。

送信側と受信側のペア間に、多数のネットワークインタフェースがある場合は、図９Ｃを参照して記述したシーケンスが、受信レポートが可能なインタフェース毎に実行される。種々の実施例において、送信側は、多数のインタフェースの中を、送信ロードを送達するためのロジックを含むことができる。別の例においては、ペイロードは、一個のインタフェースにのみ送ることができ、別の実施例においては、幾つかの又は全てのインタフェースを使うことができる。

上記の説明は、システム１０の送信側と受信側ペアの全てに当てはまる。ほとんどの状況において、送信側と受信側ペアには、クライアント１２、可動デバイス１３およびサーバ１６、二個のサーバ１６、デバイス１３を可動する一個のサーバ１６とクライアント１２または二個のクライアント１２がそれぞれ含まれる。送信側のノードが２つ以上の受信側ノードに同時に送信している場合は、図９Ａないし９Ｃを参照して説明した上記のシーケンスが受信側と送信側ペア毎に一斉に起こる。

［Ｈ．３ ＤＱＭ動作フロー図］
ＤＱＭ２８ｇは、クライアント１２で受信したデータが壊れているまたはパケットが失われていないか判断する。さらに、受信側クライアント１２のＤＱＭ２８ｇは、受信レポートを生成し、ネットワーク上の送信側ノードに送り返す。また、ＤＱＭ２８ｇは、バックグラウンドの処理を行い、送信されるデータの正確または完全なコピーが最終的に受信され記憶されることを確実にする。これらの機能について、図９Ｄないし９Ｆを参照して説明する。

図９Ｄは、紛失データおよび／または壊れたデータがないかチェックするＤＱＭ２８ｇの動作を示すフロー図である。最初のステップ５６_１にて、ＤＱＭ２８ｇは、ＣＲＣあるいは同様の完全性チェック機構等の既知の技術を使って、壊れたパケットがないかチェックする。もしパケットが壊れていると、紛失したものとみなされる（５６_２）。次に、ＤＱＭ２８ｇは、紛失パケットがないか確かめる（５６_３）。もし、予め決められた時間が過ぎてもシーケンスのずれたパケットが受信されなければ、それは紛失したものとみなされる。ＤＱＭ２８ｇは、紛失あるいは壊れたパケットをＤＮＱＳ３２にメモする（５６_４）。一方、紛失あるいは壊れたパケットが検出されなかった場合、ＤＱＭ２８ｇは、帯域幅をセーブするために、送信側が意図的に受信したデータの品質をひき下げたのかどうか（すなわち引き下げられたメディアのビットレート表示）を判断する（５６_５）。引き下げられた品質は、ＤＮＱＳ３２にメモされる（５６_６）。受信したデータの品質が引き下げられたかどうかにかかわらず、データの受信情報（例えば、パケットのシーケンス番号、タイムスタンプ、およびそのパケットが送られるネットワークの次のノードのネットワークアドレス）が、ＤＮＱＳ３２に記憶される（５６_７）。上記のプロセスは、フロー図の戻り矢印で示されるように最初から継続的に繰り返される。

図９Ｄに詳細に示すプロセスの結果、質が引き下げられていないパケット（すなわちメディアのフルビットレート表示）の受信、品質が引き下げられたパケット（すなわち引き下げられたメディアのビットレート表示）の欠陥、および紛失または壊れたパケットに関する情報は、全てＤＮＱＳ３２に記憶される。メディアを受信すると、ＤＮＱＳ３２は、メディアのステータスに関する最新情報を維持する。

図９Ｅは、ＤＱＭ２８ｇの受信レポート生成機能の動作を示すフロー図である。最初のステップにて、ＤＮＱＳ３２は定期的にスキャンされ（５８_１）、受信レポートを生成する必要があるメディアかどうか判断される（５８_２）。ＮＯの回答の場合、上記のスキャンプロセスが繰り返される。一方、メディアが識別された場合は、プロセスにおいて、そのメディアが、時間的制約があるかどうか、すなわち、ユーザはメディアをライブでレビューしようとしているのか、それともデバイス１３に記憶する必要のない、メディアを即座にレビューしようとしているのか、判断する（５８_３）。

時間的制約がない場合は、受信側は、送信側に再送優先順位を（以下に定義する如く）低にセットするよう通知する（５８_４）。時間的制約がある場合は、パケット損失の量が考慮される（５８_５）。パケット損失の量が使用可能な品質の範囲を超えていれば、再送優先順位は、高にセットされる（５８_６）。上記のようにパケット損失の量が大きすぎる場合は、受信側は、受信と同時にそのメディアをレビューすることはできない。品質が許容範囲内であれば、すなわち、送信品質（すなわち引き下げられたメディアのビットレート表示）がレンダリングしたときに十分理解可能であれば、受信レポート送信の優先順位が低にセットされる（５８_４）。受信側が、受信と同時にレビューしているかどうかにかかわらず、受信レポートが送られ（５８_７）、ＤＮＱＳ３２が更新され（５８_８）、ネットワーク品質管理部（ＮＱＭ）２８ｈが更新される（５８_９）。したがって、ステップ５８_４で定義される再送要求は、時間的制約に基づく条件である。ステップ５８_６で定義される送信要求は、時間的制約と品質の両方に基づく条件である。

再送優先順位は、送信側のＰＱＭ２６ｇに、再送が必要なメディアの送信レートに正しく優先順位をつけるように通知する。例えば、再送優先順位が高にセットされると、送信側ＰＱＭ２６ｇは、どの新しいメディアよりも先に再送しなければならない。優先順位が低の場合は、ＰＱＭ２６ｇは、新しいメディアの後に再送信メディアを送信しなければならない。

上記プロセスは、メディアが受信される毎に受信レポートが生成されるように、継続的に繰り返される。もし、送信側がタイムリーに受信レポートを受信しない場合、送信側のＰＱＭ２６ｇは、送信レートを引き下げ、受信レポートが受信されない場合は、最終的には送信を停止する。

図９Ｆは、紛失または品質を引き下げられたメディアを要求するシーケンスを示すフロー図である。最初のステップ６０_１にて、ＤＮＱＳ３２は紛失メディアまたは品質を引き下げられたメディアがないか、定期的にスキャンされる（６０_２）。紛失メディアも品質を引き下げられたメディアもない場合は、上に定義したスキャンが定期的に繰り返される。一実施例では、高い優先順位の要求は早急な再送信要求を意味し、低い優先順位の要求は一般に高い優先順位の再送信および／または時間的制約のあるメディアに必要とされる帯域幅を超える帯域幅が利用可能になるまで据置きした再送信要求を意味する。さらに、送信ノードで競合する低い優先順位の要求を完了するのに、多くの異なるスキームの何れか１つに従って処理してもよい。例えば、低い優先順位のメディアの再送信要求は、先着順で実行されてもよいし、時間的制約がないメディアの前に常に時間的制約があるメディアを実行してもよいし、またはその逆で実行してもよい。

予め決められた閾値の時間が経過しても、シーケンス外のパケットが着信しない場合は、メディアは紛失したものとみなされる（６０_３）。パケットが閾値の前に着信すれば、紛失とはみなされない。一方、パケットが閾値を越えても着信しない場合は、そのパケットは紛失したとみなされる。紛失パケットについて、再送を要求する低優先順位が作られ（６０_４）、要求の時間がＤＮＱＳ３２にメモされる（６０_５）。このプロセスは、紛失パケットが受信されるまで繰り返される。紛失パケットが着信し、ＰＩＭＢ３０の中に対応するメディアがある場合は、紛失メディアのステータスはＤＮＱＳ３２から除去される。したがって、ステップ６０_４で定義される再送信要求は、メディアが紛失したかどうかの判断に基づく条件である。

もし、メディアが引き下げられたビットレート表示に下げられたならば、ＤＱＭ３２は、そのメディアがライブまたはリアルタイムの会話の一部かどうか判断する（６０_６）。品質を引き下げられたメディアでない場合は、品質を引き下げられたメディアの完全な品質またはビットレートのコピーを求める要求が作られ（６０_７）、完全な品質のメディアが紛失したと認定され（６０_８）、要求した時間がＤＮＱＳ３２にメモされる（６０_９）。そのメディアがライブの会話の一部分である場合は、ネットワーク回線容量を残すために、即座には動作はおこなわれない。会話がライブモードから遷移する場合は、６０_７ないし６０_９のステップが実行され、最終的には品質を引き下げられたメディアの完全な品質の（すなわち正確または完全な）コピーが確実に受信される。受信側クライアント１２のＰＩＭＢ３０にデータが入手可能になると、関係するメディアの品質引き下げのステータスはＤＱＮＳ３２から取り除かれる。したがって、ステップ６０_７で定義される送信要求は、品質の引き下げとライブ会話の一部でないことの二つに依存する条件である。

上記のプロセスは、戻り矢印で示すように、フロー図の６０_５および６０_９からトップの６０_１へ、継続的に繰り返される。図９Ｆに示すプロセスを繰り返すことによって、送信される全てのメディアの完全なコピーが、最終的に受信側デバイス１３のＰＩＭＢ３０に記憶される。このように、送信されるメディアの完全なコピーの記憶が受信側デバイス１３で保証される。

［Ｉ．音声通信のリアルタイム同期］
図１０を参照すると、デバイス１３Ａを用いる第１の参加者とデバイス１３Ｂを用いる第２の参加者の間の会話のメディアのリアルタイム同期を示すダイアグラムが示されている。記憶・ストリームモジュール２４の漸次性は、メディアが生成されるときに会話のメディアがデバイス１３Ａまたはデバイス１３Ｂの双方で漸次保存されることを保証する。送信側では、ＰＱＭ２６ｇ（図９Ａ乃至９Ｃ）の動作は、メディアが生成されるときに送信デバイス１３を用いて生成された任意のメディアを漸次送信して、ローカルのＰＩＭＢ３０に保存することである。受信するデバイス１３では、これを受信してレンダリングするときに、ＤＱＭ２８ｇが任意の受信されたメディアをローカルのＰＩＭＢ３０に漸次保存する。その結果、メディアが生成されているときに、会話の参加者の双方が会話のメディアのコピーを同期する。

明瞭にするため、図１０は会話を行っていた２つのデバイス１３Ａと１３Ｂのみを示す。会話の参加者の数に拘わらず、メディアのリアルタイム同期が実現されてもよいことを理解されたい。さらに、図のネットワーク１４は単純にするために総称的なネットワークの雲として示されている。また、ネットワーク１４が一またはそれ以上のサーバー１６を含んでもよく、記憶・ストリームモジュール８４および２つのデバイス１３Ａと１３Ｂ間の各中間ホップであるＰＩＭＢ８５は会話のメディアのコピーを保存し、デバイス１３Ａと１３Ｂと共にリアルタイム同期を任意に行うことを理解されたい。

図１１を参照すると、デバイス１３Ａとデバイス１３Ｂ間の会話のメディアの準リアルタイム同期のシーケンスを示すフローチャートが示されている。この実施例では、準リアルタイムモードの会話にデバイスＡとデバイスＢのユーザが携わっていると想定されている。デバイス１３Ａと１３Ｂは、直接的または１以上の中間サーバ１６（図示せず）を介して会話を行ってもよい。

会話が開始された後（１１０２）、デバイス１３Ａとデバイス１３Ｂのユーザは各々典型的にメディアを生成するだろう。図の左側に、デバイス１３ＡのＰＩＭＢ３０を同期するためのシーケンスが示されている。右側に、デバイス１３ＢのＰＩＭＢ３０を同期するためのシーケンスが示されている。このシーケンスは、ダイアグラムの両側で本質的に同じである。

会話の最中にデバイス１３Ａのユーザが音声メディア（１１０４Ａ）を生成するだろう。このメディアが生成されるとき、それは図８Ｂに関して上述したようにインデックスフォーマットでエンコードされて、デバイス１３ＡのローカルのＰＩＭＢ３０に保存される（１１０６Ａ）。

デバイス１３Ｂは、会話に関係するデバイス１３Ｂで始まるローカルに作成された全ての音声メディアのステータスをデバイス１３Ａに通知する（１１０８Ａ）。様々な実施例では、新しいメディアの通知は様々な異なる形態をとってもよい。例えば、通知は：（ｉ）デバイス１３Ｂが会話に関連したメディアを最初に生成して送信し始めるとき；（ｉｉ）デバイス１３Ｂがログインするとき；（ｉｉｉ）会話に関係するメディアがデバイス１３Ｂで作成され、デバイス１３Ａに送信される都度；（ｉｖ）デバイス１３Ｂが会話に関係するデバイス１３Ｂを用いて作成された全てのメディアの状態をデバイス１３Ａに周期的に通知するとき；（ｖ）デバイス１３Ａがデバイス１３Ｂで作成され、保存されたメディアの状態をデバイス１３Ｂに周期的に尋ねるとき、または（ｖｉ）メディアがメディアの送信にまさに先立って、または送信と同時に利用可能であるという同期更新メッセージをデバイス１３Ｂがデバイス１３Ａに通知するとき、に発生してもよい。さらに別の実施例では、（ｖｉｉ）会話のメディアがデバイス１３Ａとデバイス１３Ｂ間の１以上のサーバー１６ホップで保存されてもよい。（ｉ）乃至（ｖｉ）に関して上述した様々な通知は、直接デバイス１３Ａと１３Ｂ間ではなく、サーバー１６とデバイス１３Ａおよび／または１３Ｂの間で発生してもよい。最終的に、通知は（ｉ）乃至（ｖｉｉ）のいくつかの組み合わせを含んでもよい。メディアが送信されるとき（図８Ｃに関して上述したように）、これは配列されてタイムスタンプされ、デバイス１３Ａがどのメディアを既に受信したか、およびどのメディアが紛失しているかを判定することができる。

通知に応じて、デバイス１３Ａはデバイス１３ＡのＰＩＭＢ３０にまだ保存されない会話に関連した音声メディアを全て要求する（１１１０Ａ）。これは、図８Ｄに関する上述したルーチンに続いて行われ、図９Ｄ乃至９Ｆに関して記載されるようなＤＱＭ２８ｇの実行を含む。状況によって、要求されたメディアは特定のタイムスタンプを持った、またはタイムスタンプ範囲内のメディアとすることができる。例えば、デバイスＡが以前に送信されたメディアの不完全なコピーを受信中である場合、次に、この要求が埋め戻しに必要とされるメディアのみを特定し、デバイスＡでメディアのコピーを終える。あるいは、進行中の会話の最中では、要求は特定のエンドポイントを持たなくてもよい。代わりに、デバイスＡからデバイスＢへの要求は無制限であり、これが作成されているときにデバイスＢは新しいメディアを送信する。

応答でデバイス１３Ｂは、図８Ｃに関して上述したシーケンスを用いて、作成されている会話に関連した任意の新しいメディアと共に要求されたメディアを送信する（１１１２Ａ）。これを受けて、デバイス１３Ａは、そのＰＩＭＢで受信されたメディアを全てローカルに保存する。その結果、メディアがデバイス１３Ｂで作成されるとき、デバイス１３Ａは会話のメディアの完全なコピーを保持することができる。

デバイス１３Ｂが音声メディアを作成するときに、シーケンス１１０４Ｂ乃至１１１４Ｂが実行される。シーケンス１１０４Ｂ乃至１１１４Ｂは１１０４Ａ乃至１１１４Ａの補集合であるため、本書で詳細に記載しない。２つのシーケンス（１１０４Ａ乃至１１１４Ａ）と（１１０４Ｂ乃至１１１４Ｂ）の最終結果は、会話がリアルタイムに発生するときにデバイス１３Ａとデバイス１３Ｂの双方が各々会話のメディアの同期されたコピーを保持するということである。

ＭＡＢＲがＡＩＢＲ未満であるときでさえ、デバイス１３Ａとデバイス１３Ｂの会話のメディアの同期が始まる。図９Ｃに関して上述されるように、ＭＡＢＲがＡＩＢＲ未満であるとき、多くの手順は「ライブでない」会話を維持するために実行され、単位時間当たりのメディアを表すのに少ないビットを用いて時間的制約があるメディアのみを送信するステップと、パケット化間隔を増加させるステップと、ネットワーク１４の条件を満たすためにメディアが送信されるレートを引き下げるステップとを含む。これらの手順は、ライブでない会話を維持する機能を拡張するという利点を有するが、これが最初にエンコードされたときにメディアの正確または完全なコピーを送信しないという犠牲がある。その結果、同期は維持されるが、受信するデバイスで最初にエンコードされたメディアの正確なコピーではない。受信するデバイスでＤＱＭと共に（図９Ｄ乃至９Ｆ）、紛失した、壊れた、およびフルビットレートバージョンでないメディアが最終的に送信され、受信するデバイスで保存される。この埋め戻し手順は、デバイス１３Ａと１３Ｂの会話のメディアの完全な同期を最終的にもたらす。したがって、ある条件下では、送信されたメディアの完全または正確なコピーのリアルタイム同期は不可能であろう。もっと正確に言えば、この同期は進行中の作業であり、埋め戻しプロセスが完了した後にだけメディアの完全なコピーが受信される。

上記説明は音声会話に関して記載されたが、会話のメディアはビデオ、ＧＰＳ情報または他のセンサデータを含む音声に加えて、任意の種類のメディアを含むことができることを理解されたい。さらに、必ずしも２人のユーザまたは参加者に会話を限定する必要はない。会話のメディアの準リアルタイム同期は、会話に参加するデバイス１３の数に拘わらず発生する。

［Ｊ．分散型サービスアーキテクチャ］
上記の議論では、ネットワークインフラ１４がデバイス１３を使用可能にされた複数のクライアント１２に仕える１つのサーバ１６として表された。他の実施例では、ネットワークインフラはサーバ１６の分散ネットワークである。

図１２を参照して、本発明による分散型サービスネットワーク１４の一例を示す。分散ネットワーク１４は複数のサーバ１６を含む。サーバ１６の各々は１以上の分散ネットワークに関連した機能を実装するように構成されてもよい。所定のサーバ１６は、ホームサーバ、ゲートウェイクライアントサーバ、ゲートウェイサーバ、ディレクトリサーバ、アクセスサーバ、またはその任意の組み合わせとして構成されてもよい。いくつが機能するかに拘わらず、特別のサーバ１６が実行するように構成され、各々は図３に示されるようなアーキテクチャを共有し、１つの可能な例外を除いて、記憶・ストリームモジュール８４とＰＩＭＢ８５を含む。サーバ１６が単にディレクトリサーバとして構成される場合、記憶・ストリームモジュール８４とＰＩＭＢ８５は必要ではない。

各ユーザは彼らのホームサーバとして特定のサーバ１６を割り当てられる。ホームサーバは、ユーザの会話の各々のメディアがネットワーク１４に保存される場所である。各会話に対して、保存されたメディアはユーザの寄付を含む全ての参加者のメディアの寄付を含む。

一実施例では、ホームデバイス１３は彼らのホームサーバ１６を検出するため、および他のユーザのホームサーバ１６を検出するために周知のドメインネームシステム（ＤＮＳ）に依頼する。他の実施例では、ライトウェイトディレクトリアクセスプロトコル（ＬＤＡＰ）が用いられる。当業者に自明であるように、任意の種類のネットワークにつながれたディレクトリルックアップシステムがホームサーバ１６を検出するために用いられてもよい。

ホームサーバ１６はまた、ホームサーバマイグレーションを管理し実行する。ユーザが通常ネットワーク１４にアクセスするのに便利な場所にあるネットワーク１４トポロジにホームサーバ１６が通常配置される。どういう理由であれ、ユーザがいくつかの期間にネットワークトポロジの異なる部分からネットワーク１４にアクセスする場合、そのユーザ用のホームサーバ１６はそのユーザ用のネットワークトポロジに最適な別のサーバ１６に移動されてもよい。これが起こると、永久的に保存されたユーザのメディアがネットワーク１４を通じて以前のものから新しいホームサーバ１６に移動される。ユーザが移動した後所定時間後に、この移動プロセスは自動的に開始されてもよいし、または手動で実行することができる。

例えば図７に示されるように、ゲートウェイサーバ１６はネットワーク１４と他の通信ネットワークの間のゲートウェイである。ゲートウェイサーバ１６は２つのネットワークにまたがり、２つのネットワークドメイン間のトラフィックをルーティングするとき必要に応じて、任意のマッピング、トランスコーディング、再カプセル化、セキュリティ、または他の変換機能を実行する役割を担う。例えば２つのネットワークに異なるパケット化の条件がある場合、ゲートウェイサーバ１６は１つのネットワークで用いられるフォーマットから第２のネットワークおよびその逆で用いられるフォーマットにパケットを再パケット化する。

ゲートウェイクライアントサーバ１６は、分散型サービスアーキテクチャ１４と通信デバイス１２０２を使用可能にされた非クライアント１２の間の仲介機能を提供する。ゲートウェイクライアントサーバ１６は、デバイス１２０２に代わって、（ｉ）ＭＣＭＳアプリケーション２０（ＭＣＭＳ、および任意にＭＣＭＳ−Ｓおよび／またはＭＣＭＳ−Ｃを含む）と、（ｉｉ）モジュール８４の記憶・ストリームと持続的な記憶動作とＰＩＭＢ８５と、の機能をネットワーク１４上で実行する。具体的には、ゲートウェイクライアントサーバは「ＰＩＭＢの読み取り部とレンダリング部」の機能（図８Ｅ）、「ＰＩＭＢの書込み部のネット受信」の機能（図８Ｄ）、「ＰＩＭＢの書込み部のエンコード受信」の機能（図８Ｂ）、および「ＰＩＭＢの読取り部の送信」の機能を実行し、デバイス１２０２を使用可能にされた非クライアント１２に代わってサーバ１６のＰＩＭＢ８５に会話のメディアが保存される（図８Ｃ）。デバイスを使用可能にされた非クライアント１２の実施例は、標準地上通信線もしくはＰＳＴＮ電話、モバイルもしくは衛星電話、戦術的無線、または他の既知の遺産である通信デバイスを含んでもよい。さらに、通信デバイス１２０２を使用可能にされた非クライアント１２は、ゲートウェイクライアントサーバ１６と協働して動作するために特別に作成された非レガシーデバイスを含んでもよい。ゲートウェイクライアントサーバについてのより詳細については、２００８年９月８日に各々提出された米国出願第１２／２０６，５３７号および第１２／２０６，５４８号を参照し、各々は「Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ ａｎｄ Ｍｕｌｔｉｍｅｄｉａ Ｍａｎａｇｅｍｅｎｔ Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ」とタイトルされており、この双方はあらゆる目的のために本書に組込まれる。

ユーザが内在ネットワーク１８を介してネットワーク１４に接続するアクセスポイントは、アクセスサーバ１６と呼ばれる。ユーザのアクセスサーバ１６は変化してもよい。例えば、ユーザはネットワーク１４から切断し、新しい物理的位置に移動し、次に異なるサーバ１６を介して再接続してもよい。また、ユーザのアクセスサーバ１６はあるアクセスサーバ１６から別のアクセスサーバに移行するかもしれない。例えば、ユーザが自動車で移動中に内在ネットワーク１８の第１のノードを介してネットワーク１４にアクセスするワイヤレスを持っている場合、ユーザがワイヤレスネットワーク１８の第１のノードの範囲からワイヤレスネットワーク１８の第２のノードの範囲へ移動するとき、アクセスサーバ１６が変化するかもしれない。内在ワイヤレスネットワーク１８の２つのノードのネットワーク１４へのアクセスポイントが異なる場合、次いでそのユーザのアクセスサーバ１６が変わるだろう。ユーザが任意のアクセスサーバ１６を介してネットワーク１４にアクセスする機能は、ユーザとネットワーク１４上の他のノード間の通信を最適化することによってネットワーク効率を改良する。

ディレクトリサーバ１６は残りのネットワーク１２にルーティング情報を提供する。ユーザがネットワーク１４に参加するときに、アクセスサーバは（ｉ）ユーザが参加したディレクトリサーバ１６に通知し、（ｉｉ）そのユーザのアクセスサーバ１６としてそれ自体を特定する。ディレクトリサーバ１６は、（ｉｉｉ）各ユーザのホームサーバ１２０２と共に、ネットワーク１４に接続された全てのユーザについて（ｉ）と（ｉｉ）をディレクトリに集める。ディレクトリサーバ１６は継続的に更新される。ユーザが参加するか、ネットワークを去るとき、またはアクセスサーバ１６および／またはユーザのホームサーバー１６が変わるとき、ディレクトリが更新される。このようにディレクトリは、ゲートウェイサーバ１６を介して他のネットワークに配置されたユーザ、またはネットワーク１４を介したユーザ間のルーチングメッセージと他のネットワークトラフィックについての現在または最新の情報を常に提供する。

ユーザのホームサーバ１６とアクセスサーバ１６が同じである場合、次にそのサーバ１６はそのユーザによって送信または受信されたメディアを全て永久的に保存する。送信用にユーザによって作成されたメディア、およびユーザへ送信されたメディアについては、サーバ１６は、ＰＱＭ（図９Ａ乃至９Ｃ）とＰＱＭ（図９Ｄ乃至９Ｆ）の動作を含み、図８Ｆに関して上述した機能を実行する。このようにユーザによって送信または受信されたメディアのコピーは、ユーザのホームサーバ１６で永久的に保存される。さらに、メディアの任意の不完全もしくは完全なコピー、紛失もしくは壊れたコピーは、ＰＱＭ２６ｇとＤＱＭ２８ｇの埋め戻し動作を介して最終的に受信される。

アクセスサーバ１６がユーザのホームサーバ１６でない場合、ＰＱＭ（図９Ａ乃至９Ｃ）とＰＱＭ（図９Ｄ乃至９Ｆ）の動作を含み、図８Ｆに関して記載された同一の動作を用いて、送受信されたメディアがアクセスサーバ１６で少なくとも一時的に保存される。一実施例では、ユーザのホームサーバ１６とデバイス１３へのメディアの配信が確認され、持続的な保存がなされる間のみ、メディアがアクセスサーバ１６に保存される。他の実施例では、メディアの配信が確認された後でも、メディアがアクセスサーバ１６とホームサーバ１６に永久的に保存される。ホームサーバ１６および／またはデバイス１３への配信確認の後に、アクセスサーバ１６でメディアを削除する異なるスキームは、アプリケーションとネットワークトポロジによって使用されてもよい。

ホームサーバ１６は、そのアーカイブ８９に会話のメディアをアーカイブする役割も担う。メディアは、ローカルで削除された後にデバイス１３へメディアを再保存したり、そのデバイス１３上でユーザ認証された後に新しいデバイス１３へメディアを送信するなど、多くの理由でアーカイブされてもよい。

図１２に示された実施例では、デバイス１３を使用可能にされた多くのクライアント１２は、様々なアクセスサーバ、ホームサーバ、およびゲートウェイサーバ１６を介してネットワーク１４に接続される。さらに、デバイス１２０２を使用可能にされた非クライアント１２もゲートウェイクライアントサーバ１６を介してネットワーク１４に接続される。上述したように、各サーバ１６は上記列挙された機能の１以上を実装してもよい。例えば、デバイス１３がそのホームサーバ１６を介してネットワーク１４に接続する状況では、次いでそのサーバがそのデバイスのアクセスサーバとホームサーバであるという二元的役割を行う。デバイス１３がそのホームサーバ１６以外にサーバ１６を介してネットワーク１４にアクセスする状況では、次いでそのデバイスのアクセスサーバとホームサーバ１６が異なる。さらに他の状況では、ホームサーバおよび／またはアクセスサーバ１６は、ゲートウェイサーバ、ゲートウェイクライアントサーバ、および／または同様にディレクトリサーバとしても機能する。サーバ１６がメッセージを送信するためにネットワーク１４上のホップとして動作するときに、ＰＱＭ（図９Ａ乃至９Ｃ）とＰＱＭ（図９Ｄ乃至９Ｆ）の動作（恐らく単にディレクトリサーバとして構成されたサーバ１６を除く）を実行することを含み、図８Ｆに関して上述したようにサーバ１６がメディアを保存し送信する。サーバ１６の各々は、実行される機能または複数の機能に拘わらず複数のテナントでもあり、すなわちこれらは同時に複数のユーザを各々サポートもしくは仕えることができる。

上述もしくは図１２に示されるサーバ１６の特定の配置と機能もしくは複数の機能は、単なる例示であり、説明のために提供される。実際の実施例では、サーバ１６の数と、各々によって実行された１以上の機能と、分散ネットワーク１４の実際の構成とは、ほぼ無限数の変形例に変更されてもよい。

他の実施例では、ネットワーク１４が専用のディレクトリサーバ１６なしで構成されてもよい。そのような実施例では、アクセスサーバ１６がディレクトリとルーティング機能の幾つかまたは全てを想定して構成される。ネットワーク１４のアクセスサーバ１６の幾つかまたは全ては、他のアクセスサーバとホームサーバ１６とユーザを検出してメッセージを送信するために「デフォルト」ルートを含むルーティングテーブルを保持するように構成されてもよい。

別の実施例では、デバイス１３を使用可能にされたクライアント１２が他のデバイス１３もしくは１２０２のサーバ１６として動作してもよい。例えば、無線デバイス１３を使用可能にされた自動車型のクライアント１２は、自動車のドライバのクライアントや全ての近くの無線サーバとすることができる。別の実施例では、コンピュータはローカルユーザのクライアント１２だけでなく、ローカルネットワーク上に接続されるコンピュータを使用可能にされた他のクライアント１２のサーバとして動作することができる。

さらに他の実施例では、ホームサーバおよび／またはディレクトリサーバへのネットワーク接続が引き下げられるか、利用不可能なときに、アクセスサーバ１６はホームサーバ１６および／またはディレクトリサーバ１６へアクセスするプロキシを提供してもよい。アクセスサーバは、適切なホームサーバと、その他のアクセスサーバと、デバイス１３を使用可能にされたクライアントとを検出することによって現在の最適なルーティング情報を提供し、デバイス１２を使用可能にされたクライアントとこれらのサーバ１６間に最も効率的なパスをマッピングする。

［Ｋ．ネットワークルーティング］
デバイス１３を使用可能にされた様々なクライアント１２および／またはデバイス１２０２を使用可能にされた非クライアント１２の間で会話が発生するとき、１以上のデバイス１３および／または１２０２から１以上サーバ１６に、分散ネットワーク１４を介してサーバ１６からサーバ１６に、および次にサーバ１６から１以上のデバイス１３および／または１２０２へ、個人メッセージが一般に送信される。メッセージはＶｏｘパケット９５の形式でネットワーク１４を行き来し、内在ネットワークもしくは複数のネットワークで用いられるパケットの種類は何でも埋め込まれる。様々な実施例では、内在ネットワークは、ネットワークトラフィックを送信するためにインターネットプロトコル（ＩＰ）、実時間プロトコル（ＲＴＰ）、または他の種類のプロトコルを利用してもよい。分散型アーキテクチャ１４を介して個人メッセージをルーティングする上では、単純さを維持する一方でトラフィックと待ち時間を減らす手順が好適である。

図１３を参照すると、本発明の一実施例で用いられるルーティング手順を示す単純な分散ネットワーク１４が示されている。この実施例では、ネットワーク１４は「アクセスサーバ１」と「アクセスサーバ２」とラベルを付けられたアクセスサーバ１６と、デバイス１３_（１）乃至１３_（５）を使用可能にされたクライアント１２と、多くのホームサーバ１６と、ディレクトリサーバ１６とを含む。デバイス１３_（１）乃至１３_（４）は、アクセスサーバ１を介してネットワーク１４に接続される。デバイス１３_（５）は、アクセスサーバ２を介してネットワーク１４に接続される。ホームサーバ１、２および５は、それぞれデバイス１３_（１）、１３_（２）、および１３_（５）のホームサーバ１６である。デバイス１３_（３）および１３_（４）はホームサーバ１６を共有する。また、第６のホームサーバ１６は第６のデバイス１３_（６）に提供され、これは今この実施例のネットワーク１４から切断されているので、これは意図的に示されていない。

デバイス１３_（１）がデバイス１３_（２）乃至１３_（６）と会話を開始するとき、これはデバイス１３_（２）乃至１３_（４）と既に接続していることを記録するアクセスサーバ１へ要求を送信する。アクセスサーバ１はまた、デバイス１３_（５）と１３_（６）およびデバイス１３_（１）乃至１３_（６）のホームサーバのステータスをディレクトリサーバ１６から要求する。ディレクトリサーバ１６は、デバイス１３_（５）がアクセスサーバ２を介してオンラインであり、デバイス１３_（６）はオンラインではないことをアクセスサーバ１に通知することによって応答する。ディレクトリサーバ１６はまた、参加者１３_（１）、１３_（２）、１３_（３）−１３_（４）、１３_（５）、および１３_（６）のホームサーバがそれぞれホームサーバ１、２、３−４、５、および６であることをアクセスサーバ１に通知する。

デバイス１３_（１）が会話と関係するメッセージを送信するとき、メッセージはアクセスサーバ１へ送信される。次いでこれらのデバイスがアクセスサーバ１に接続されるので、メッセージはデバイス１３_（２）乃至１３_（４）へ直接転送される。さらにアクセスサーバ１は、残っている送信宛先、特にホームサーバー５と６およびデバイス１３_（５）が同一の次のホップであるアクセスサーバ２を有していることを記録する。これらの宛先が全て同一の次のホップを共有するので、アクセスサーバ１は各メッセージのコピーを１つだけアクセスサーバ２に送信する。次にメッセージは、アクセスサーバ２によってデバイス１３_（５）と、ホームサーバ５と、ホームサーバ６とに送信される。ホームサーバ１乃至６の各々は、それぞれデバイス１３_（１）乃至１３_（６）のメッセージを保持する。デバイス１３_（６）がオンラインになるとき、ホームサーバ６が会話のメディアを受信するデバイスを使用可能にして、デバイス１３_（６）にメッセージを転送する。もしデバイス１３_（５）と１３_（６）がネットワーク１４上に異なる次のホップを有している場合、次いでメッセージのコピーを１つだけが各次のホップに送信されるだろう。他のデバイス１３_（２）乃至１３_（６）の何れかによって生成されたメッセージは、上述したように類似の手法でネットワーク１４をルーティングされる。

上記ルーティング手順は多くの利点を提供している。同一のアクセスサーバを介して同一のアクセスサーバ１６で特定されたデバイス１３間で直接メッセージをルーティングすることによって、ネットワークトラフィックと待ち時間が減少される。また、ネットワーク上の同一の次のホップを共有する複数の受信側へ複数のコピーを転送するのとは対照的に、メッセージのコピーを１つだけ転送することによって、ネットワークトラフィックと待ち時間が再び減少される。同一のホップに沿った複数の受信側へのメッセージの送信を１つの送信に統合して複製することによって、または複数の次のホップがあるときにだけメッセージを「散布する（ｆａｎｎｉｎｇ ｏｕｔ）」ことによって、全体的なネットワークトラフィックと待ち時間が著しく減少される。

他の実施例では、同一のアクセスサーバ１６を介してネットワーク１４に接続されたデバイス１３が互いに直接通信することができるようにアクセスサーバ１６が構成されてもよい。この実施例では、２つ（またはそれ以上の）デバイス１３間で直接送信された任意のメッセージが共用アクセスサーバ１６にさらに送信されなければならず、これは次に同一のデバイス１３のホームサーバへメッセージを転送する。この配置は、同一のアクセスサーバ１６に接続されたデバイス１３間の通信の待ち時間を改良するが、デバイス１３とアクセスサーバ１６の双方に複雑さを増加させる犠牲を伴う。さらにアクセスサーバ１６へメッセージを全て送信しなければならないので、ネットワークトラフィックが本質的に２倍になる。

［Ｌ．分散型サービスアーキテクチャを介したリアルタイム同期］
サーバ１６を用いるという１つの利点は、分散ネットワーク１４を介して送信されたメディアの準リアルタイム同期を維持する機能である。図１４を参照すると、１以上のネットワーク１８（図示せず）上に構成されるネットワーク１４の一例が示されている。この実施例では、デバイス１３_（１）、１３_（２）を使用可能にされた２つのクライアントと、デバイス１２０２を使用可能にされた非クライアント１２が、ネットワーク１４を介して音声（および任意にその他の種類のメディアの）会話に携わっている。ネットワーク１４はアクセスサーバ１６_（１）と１６_（２）を含み、これらはデバイス１３_（１）と１３_（２）それぞれにネットワークアクセスを提供する。デバイス１２０２を使用可能にされた非クライアント１２は、ゲートウェイクライアントとして構成されたサーバ１６を介してネットワーク１４に接続する。さらに、ディレクトリサーバ１６が提供される。サーバ１６の各々は、任意にモジュール８４およびＰＩＭＢ８５を含むディレクトリサーバ１６を恐らく除いて、記憶・ストリームモジュール８４とＰＩＭＢ８５を含む。

会話のメッセージがネットワーク上の各送受信ペアの間で送信されるとき、記憶・ストリームモジュール２４（デバイス１３_（１）と１３_（２）用）と８４（サーバ１６の各々用）は、図１１に関して上述したシーケンスを実行する。その結果、会話のメディアは、レガシーデバイス１２０２およびデバイス１３_（１）と１３_（２）の間のネットワーク１４上の各サーバ１６ホップのＰＩＭＢ８５に同期して保存される。メディアはまた、デバイス１３_（１）と１３_（２）のＰＩＭＢ３０に同期して保存される。

一実施例では、メディアはネットワーク１４上の各サーバ１６ホップで同期して永久的に保存される。他の実施例では、会話のメディアは、レガシーデバイス１２０２のゲートウェイクライアントサーバ１６と、アクセスサーバ１６_（１）と１６_（２）ではなくデバイス１３_（１）と１３_（２）それぞれのホームサーバ１６_（１）と１６_（２）とにのみネットワーク１４上で永久的に保存される。後者の実施例では、一旦ホームサーバ１６_（１）と１６_（２）および／またはデバイス１３_（１）と１３_（２）それぞれにメディアが永久的に保存されたことが確認された場合、メディアはもはやアクセスサーバ１６_（１）と１６_（２）に保存されない。

メディアがその転送元から宛先へネットワーク１４を介して移動するとき、メディアは各送受信ペア間で同期される。デバイス１３_（１）、１３_（２）を使用可能にされたクライアントおよび各中間サーバ１６を含むネットワーク上の各ノードは、「ホップバイホップ」で同期される。ネットワーク１４上で送受信する各ホップ間のメディアの同期を実行することによって、単なる送受信する通信デバイス１３_（１）と１３_（２）とは対照的に、ネットワーク１４を介したメディアの弾力性と冗長性が増加される。

ネットワーク１４を介した同期は音声会話に関して記載されたが、会話のメディアが音声、ビデオ、ＧＰＳ情報、またはその他のセンサデータを含む任意の種類のメディアを含むことができることを理解されたい。さらに上述したように、会話を必ずしも３人の参加者に限定する必要はない。会話のメディアの準リアルタイム同期は、参加者の人数に拘わらず発生する。また、メディアを会話との関連で送信してはならない。会話に関係しないメディアは、ネットワーク１４を介して同期することができる。最後に、図１４に示される特別のネットワーク構成はネットワークを介したリアルタイム同期を説明するための単なる例示であることを再び理解されたい。特別の構成は、任意の方法に制限されると解すべきでない。

図８Ａ乃至８Ｆと、図９Ａ乃至９Ｆと、図１０乃至１４とに関する上記の議論では、メディアがタイムベースのフォーマットでインデックスされるように記載されたことに注意されたい。メディアを時間でインデックスすることは例示であり、本発明を限定するものと解すべきでないことを理解されたい。それどころか、任意のインデックスフォーマットは、ビットもしくはバイト列によるインデックス、ハッシュタイプのインデックス、２分木タイプのインデックス、ファイルディレクトリベースのインデックス、またはその任意の組み合わせを用いてもよい。したがって用語「インデクシング」は、任意のインデックススキームをカバーするために広く解すべきである。

［Ｍ．クライアントおよびサーバハードウェア］
図１５Ａは、クライアントアプリケーション１２を記憶し実行するために使われるデバイス１３のハードウェアを示すブロック図１４０である。ハードウェアは、ＣＰＵ１４２、メインメモリ１４４および大容量記憶装置１４６を有する。技術的には周知のことだが、クライアントアプリケーション１２はメインメモリ１４４と大容量記憶装置１４６に搭載され記憶されて、ＣＰＵ１４２によって実行される。

図１５Ｂは、サーバアプリケーション７８を記憶し実行するために使われるサーバ１６（サーバ１２０２乃至１２１０の何れか）のハードウェアを示すブロック図１５０である。ハードウェアは、ＣＰＵ１５２、メインメモリ１５４、大容量記憶装置１５６、およびアーカイブ部８９を有する。技術的には周知のことだが、サーバアプリケーション７８は、メインメモリ１５４および大容量記憶装置１５６に搭載、保存されＣＰＵ１５２によって実行される。上記のように、一またはそれ以上のユーザのインデックスされたメディアペイロードは、アーカイブ部８９に保存される。

便宜上、多くのコンポーネントと処理について一個の事例で記述したが、当業者には正しく理解されるように、多くのコンポーネントと繰り返しの処理をここに説明したシステムおよび方法の技術は実施する上で使用できる。さらに、本発明は、特定の実施例を参照して特別に示し記述したが、当業者には正しく理解されるように、本発明の精神と範囲を超えずに、開示した実施例のフォームおよび細部の変更が可能である。例えば、本発明の実施例は、様々なコンポーネントとともに採用でき、かつ上記のものに限定されない。したがって、本発明は、全ての変形例及び同等物は本発明の精神と範囲に入ると理解されるべきものである。

Claims (11)

1. 第１の通信デバイスと第２の通信デバイスとの間でネットワークを通じて行われた会話の音声メディアを同期する方法において、
   前記第１の通信デバイスを用いて前記音声メディアが作成されているときに、前記第１の通信デバイスを用いて作成された前記会話に関係する音声メディアを前記第１の通信デバイスに関連する第１の記憶部に漸次保存するステップと；
   前記音声メディアが作成され前記第１の記憶部に漸次保存されているときに、第１のネットワーク接続を通じて前記第２の通信デバイスに前記第１の通信デバイスを用いて作成された音声メディアを漸次送信するステップと；
   前記音声メディアが前記第２の通信デバイスを用いて作成されているときに、前記第２の通信デバイスを用いて作成された前記会話に関係する音声メディアを前記第２の通信デバイスに関連する第２の記憶部に漸次保存するステップと；
   前記音声メディアが作成され前記第２の記憶部に漸次保存されているときに、第２のネットワーク接続を通じて前記第１の通信デバイスに前記第２の通信デバイスを用いて作成された音声メディアを漸次送信するステップと；
   前記第２の通信デバイスによって送信され前記第２の通信デバイスに関連する前記第２の記憶部に保存された前記会話に関係する音声メディアを漸次受信して前記第１の記憶部に保存するステップと；
   前記第１の通信デバイスによって送信され前記第１の通信デバイスに関連する前記第１の記憶部に保存された前記会話に関係する音声メディアを漸次受信して前記第２の記憶部に保存するステップと；
   前記第１の記憶部にはなく、前記第２の記憶部に保存された前記会話に関係する送信された音声メディアと、前記第２の記憶部にはなく、前記第１の記憶部に保存された前記会話に関係する送信された音声メディアとを確認するステップと；
   前記第１の記憶部にはなく、前記第２の記憶部に保存された前記確認された音声メディアと、前記第２の記憶部にはなく、前記第１の記憶部に保存された前記確認された音声メディアとの１以上の再送信の要求を生成するステップと；
   前記第１のネットワーク接続を通じて前記第１の通信デバイスから前記第２の通信デバイスに、および前記第２のネットワーク接続を通じて前記第２の通信デバイスから前記第１の通信デバイスに前記確認された音声メディアを再送信するステップと；
   １以上の再送信の要求に応じて前記第２の通信デバイスから前記第１の記憶部に、および前記第１の通信デバイスから前記第２の記憶部に前記再送信された音声メディアを保存するステップとを具え、
   これによって前記再送信の要求が満たされるとき、前記第１の記憶部と前記第２の記憶部の音声メディアが同期されることを特徴とする方法。
2. 請求項１に記載の方法であって、前記第１のネットワーク接続を通じて前記第２の通信デバイスに前記第１の通信デバイスを用いて作成された前記音声メディアを漸次送信するステップは、
   （ｉ）送信ループを規定するステップと；
   （ｉｉ）前記規定された送信ループ中に前記第１の通信デバイスを用いて作成された利用可能な音声メディアを確認するステップと；
   （ｉｉｉ）前記規定された送信ループ中に前記ネットワークで利用可能な有効ビットレートを確認するステップと；
   （ｉｖ）前記送信ループ中に前記ネットワークで利用可能な前記確認された有効ビットレートが最初にエンコードされた前記確認された利用可能な音声メディアのフルビットレート表示を送信するのに十分かどうかを判定するステップと；
   （ｖ）前記確認されたビットレートが十分である場合に、前記利用可能なメディアのフルビットレート表示を送信するステップと；
   （ｖｉ）前記確認されたネットワーク上のビットレートが前記フルビットレート表示を送信するのに十分でないときに、前記利用可能な音声メディアの引き下げられたビットレートバージョンを生成するステップであって、前記利用可能な音声メディアの引き下げられたビットレートバージョンは、前記第１の通信デバイスと前記第２の通信デバイスがリアルタイムに会話を行う機能を良くするステップと；
   （ｖｉｉ）前記送信ループ中に前記ネットワーク上で利用可能な前記確認された有効ビットレートが十分でないときに、前記利用可能な音声メディアの引き下げられたビットレートバージョンを送信するステップと、をさらに具えることを特徴とする方法。
3. 請求項２に記載の方法が、
   連続的な送信ループを規定するステップと；
   前記確認されたネットワーク上の有効ビットレートが各規定された連続ループそれぞれに対して十分であるかないかに依存して（ｉ）乃至（ｉｉｉ）と、（ｖ）または（ｖｉ）の何れかと、（ｖｉｉ）とを実行するステップと、をさらに具えることを特徴とする方法。
4. 請求項２に記載の方法であって、前記利用可能な音声メディアの引き下げたビットレート表示を生成するステップは、前記利用可能な音声メディアを送信用にパケット化する場合に（ａ）１以上の異なるコーデック設定、（ｂ）１以上の異なるコーデック、（ｃ）圧縮アルゴリズム、または（ｄ）（ａ）乃至（ｃ）の任意の組み合わせを用いるステップを具えることを特徴とする方法。
5. 請求項１に記載の方法であって、前記第１の記憶部にはないが前記第２の記憶部に保存された会話に関係する音声メディアを確認するステップは、
   （ｉ）前記第１の通信デバイスでデータ品質ストアを保持するステップと；
   （ｉｉ）前記第２の通信デバイスを用いて作成され、前記第１の通信デバイスに送信された音声メディアの全ての紛失した、壊れた、または引き下げたビットレートバージョンを前記データ品質ストアに記録するステップと、をさらに具えることを特徴とする方法。
6. 請求項５に記載の方法であって、前記１以上の再送信の要求を前記第１の通信デバイスで生成し、前記第２の通信デバイスへ送信するステップは、
   （ｉｉ）データ品質ストアに記録された前記音声メディアの１以上の再送信の要求を生成するステップと；
   （ｉｉｉ）対応する１以上の再送信の要求が満たされるとき、前記データ品質ストアに記録された音声メディアの記録を削除するステップと、をさらに具えることを特徴とする方法。
7. 請求項６に記載の方法であって、前記１以上の再送信の要求に応じて前記第２の通信デバイスから前記第１の通信デバイスで受信されたメディアを前記第１の記憶部に保存するステップは、
   （ｉｖ）前記１以上の再送信に応じて前記第１の記憶部に前記再送信された音声メディアを保存するステップと；
   （ｖ）前記第２の通信デバイスによって生成され、前記第２の記憶部に保存された音声メディアの完全なコピーが受信され、前記第１の記憶部に保存されるまでに（ｉ）乃至（ｉｖ）を繰り返すステップと、をさらに具えることを特徴とする方法。
8. 請求項１〜７の何れかに記載の方法であって、（ｉ）前記ネットワークを通じて前記音声メディアを受信しているときに前記音声メディアをレンダリングすることによって準リアルタイムモードで、又は（ｉｉ）前記第１の記憶部および前記第２の記憶部以外の音声メディアをそれぞれレンダリングすることによってタイムシフトモードで、前記第１の通信デバイスおよび前記第２の通信デバイス上の会話の音声メディアを選択的にレンダリングするステップを、さらに具えることを特徴とする方法。
9. 請求項１〜８の何れかに記載の方法であって、前記第１の通信デバイスは、固定電話、無線電話、携帯電話、衛星電話、コンピュータ、無線、サーバ、衛星ラジオ、戦術的無線、または戦術的電話の１つを具えることを特徴とする方法。
10. 第１の永続的なコンピュータ読み取り可能な媒体に組み込まれ、第１の通信デバイスで実行するための第１のコピーのコンピュータコードと、第２の永続的なコンピュータ読み取り可能な媒体に組み込まれ、第２の通信デバイスで実行するための第２のコピーのコンピュータコードとであって、前記第１および第２の通信デバイスは、前記第１のコピー及び第２のコピーのコンピュータコードをそれぞれ実行するときに、請求項１〜９の何れかに記載されたステップを実行するよう構成されていることを特徴とするコンピュータコード。
11. 第１の通信デバイス及び第２の通信デバイスであって、前記第１の通信デバイスと第２の通信デバイスは、請求項１〜９の何れかに記載されたステップをそれぞれ実行するよう構成されていることを特徴とする第１及び第２の通信デバイス。

Images